From boon.leong.ong at intel.com  Thu Apr  1 00:09:49 2021
From: boon.leong.ong at intel.com (Ong, Boon Leong)
Date: Wed, 31 Mar 2021 23:09:49 +0000
Subject: [PATCH net-next v3 5/6] net: stmmac: Add support for XDP_TX action
In-Reply-To: <20210331144235.799dea32@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210331154135.8507-1-boon.leong.ong@intel.com>
 <20210331154135.8507-6-boon.leong.ong@intel.com>
 <20210331144235.799dea32@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <DM6PR11MB27806DC9AA797C2AA8554581CA7C9@DM6PR11MB2780.namprd11.prod.outlook.com>

>> +static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
>> +				struct xdp_buff *xdp)
>> +{
>> +	struct xdp_frame *xdpf = xdp_convert_buff_to_frame(xdp);
>> +	int cpu = smp_processor_id();
>> +	struct netdev_queue *nq;
>> +	int queue;
>> +	int res;
>> +
>> +	if (unlikely(!xdpf))
>> +		return -EFAULT;
>
>Can you return -EFAULT here? looks like the function is otherwise
>returning positive STMMAC_XDP_* return codes/masks.

Good catch. Thanks. It should return STMMAC_XDP_CONSUMED. 

>
>> +	queue = stmmac_xdp_get_tx_queue(priv, cpu);
>> +	nq = netdev_get_tx_queue(priv->dev, queue);
>> +
>> +	__netif_tx_lock(nq, cpu);
>> +	/* Avoids TX time-out as we are sharing with slow path */
>> +	nq->trans_start = jiffies;
>> +	res = stmmac_xdp_xmit_xdpf(priv, queue, xdpf);
>> +	if (res == STMMAC_XDP_TX) {
>> +		stmmac_flush_tx_descriptors(priv, queue);
>> +		stmmac_tx_timer_arm(priv, queue);
>
>Would it make sense to arm the timer and flush descriptors at the end
>of the NAPI poll cycle? Instead of after every TX frame?
Agree. The Tx clean timer function can be scheduled once at the end of
the NAPI poll for better optimization. 


>
>> +	}
>> +	__netif_tx_unlock(nq);
>> +
>> +	return res;
>> +}
>
>> @@ -4365,16 +4538,26 @@ static int stmmac_rx(struct stmmac_priv *priv,
>int limit, u32 queue)
>>  			xdp.data_hard_start = page_address(buf->page);
>>  			xdp_set_data_meta_invalid(&xdp);
>>  			xdp.frame_sz = buf_sz;
>> +			xdp.rxq = &rx_q->xdp_rxq;
>>
>> +			pre_len = xdp.data_end - xdp.data_hard_start -
>> +				  buf->page_offset;
>>  			skb = stmmac_xdp_run_prog(priv, &xdp);
>> +			/* Due xdp_adjust_tail: DMA sync for_device
>> +			 * cover max len CPU touch
>> +			 */
>> +			sync_len = xdp.data_end - xdp.data_hard_start -
>> +				   buf->page_offset;
>> +			sync_len = max(sync_len, pre_len);
>>
>>  			/* For Not XDP_PASS verdict */
>>  			if (IS_ERR(skb)) {
>>  				unsigned int xdp_res = -PTR_ERR(skb);
>>
>>  				if (xdp_res & STMMAC_XDP_CONSUMED) {
>> -					page_pool_recycle_direct(rx_q-
>>page_pool,
>> -								 buf->page);
>> +					page_pool_put_page(rx_q-
>>page_pool,
>> +
>virt_to_head_page(xdp.data),
>> +							   sync_len, true);
>
>IMHO the dma_sync_size logic is a little question, but it's not really
>related to your patch, others are already doing the same thing, so it's
>fine, I guess.
Ok. We may leave it as it is now until a better/cleaner solution is found.

 


From adrien.grassein at gmail.com  Thu Apr  1 00:23:56 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Thu,  1 Apr 2021 01:23:56 +0200
Subject: [PATCH v3 4/4] arm64: defconfig: Enable LT8912B DRM bridge driver
In-Reply-To: <20210331232356.2204476-1-adrien.grassein@gmail.com>
References: <20210331232356.2204476-1-adrien.grassein@gmail.com>
Message-ID: <20210331232356.2204476-5-adrien.grassein@gmail.com>

This driver is used by the Nitrogen8 SBC.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 56398b55500a..ae981d3b1bc8 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -690,6 +690,7 @@ CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
 CONFIG_DRM_PANEL_SITRONIX_ST7703=m
 CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m
 CONFIG_DRM_DISPLAY_CONNECTOR=m
+CONFIG_DRM_LONTIUM_LT8912B=m
 CONFIG_DRM_NWL_MIPI_DSI=m
 CONFIG_DRM_LONTIUM_LT9611=m
 CONFIG_DRM_SII902X=m
-- 
2.25.1



From adrien.grassein at gmail.com  Thu Apr  1 00:23:52 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Thu,  1 Apr 2021 01:23:52 +0200
Subject: [PATCH v3 0/4] Add peripheral support to imx8mq-nitrogen board
Message-ID: <20210331232356.2204476-1-adrien.grassein@gmail.com>

Hi,

this patch set aims is to add support of multiple peripheral of the
Boundary8M board:
  - USB Host;
  - USB device;
  - DB_DSIHD sub board for MIPI-DSI to HDMI output (via lt8912b chip).


Updates in v2:
  - Use a GPIO hog to handle the USB HOST reset line;
  - Remove useless GPIO hog for lt8912b.

Update in v3:
  - Fix bad squash in git commits.

Thanks,

Adrien Grassein (4):
  arm64: dts: imx8mq-nitrogen: add USB OTG support
  arm64: dts: imx8mq-nitrogen: add USB HOST support
  arm64: dts: imx8mq-nitrogen: add lt8912 MIPI-DSI to HDMI
  arm64: defconfig: Enable LT8912B DRM bridge driver

 .../boot/dts/freescale/imx8mq-nitrogen.dts    | 185 ++++++++++++++++++
 arch/arm64/configs/defconfig                  |   1 +
 2 files changed, 186 insertions(+)

-- 
2.25.1



From adrien.grassein at gmail.com  Thu Apr  1 00:23:55 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Thu,  1 Apr 2021 01:23:55 +0200
Subject: [PATCH v3 3/4] arm64: dts: imx8mq-nitrogen: add lt8912 MIPI-DSI to
 HDMI
In-Reply-To: <20210331232356.2204476-1-adrien.grassein@gmail.com>
References: <20210331232356.2204476-1-adrien.grassein@gmail.com>
Message-ID: <20210331232356.2204476-4-adrien.grassein@gmail.com>

Add support of the lt8912b in the DTB.
This adds the support of the DB_DSIHD daugther board from
Boundary Devices.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 .../boot/dts/freescale/imx8mq-nitrogen.dts    | 120 ++++++++++++++++++
 1 file changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
index 04992cbba56e..4ffd23ea705f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
@@ -34,6 +34,19 @@ power {
 		};
 	};
 
+	hdmi-connector {
+		compatible = "hdmi-connector";
+		ddc-i2c-bus = <&ddc_i2c_bus>;
+		label = "hdmi";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&lt8912_out>;
+			};
+		};
+	};
+
 	reg_usb_otg_vbus: regulator-usb-otg-vbus {
 		compatible = "regulator-fixed";
 		pinctrl-names = "default";
@@ -81,6 +94,9 @@ reg_vref_5v: regulator-vref-5v {
 	};
 };
 
+&dphy {
+	status = "okay";
+};
 
 &fec1 {
 	pinctrl-names = "default";
@@ -193,6 +209,97 @@ rtc at 68 {
 	};
 };
 
+&i2c4 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c4>;
+	status = "okay";
+
+	pca9546: i2cmux9546 at 70 {
+		compatible = "nxp,pca9546";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c4 at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			clock-frequency = <100000>;
+
+			hdmi-bridge at 48 {
+				compatible = "lontium,lt8912b";
+				reg = <0x48> ;
+				reset-gpios = <&max7323 0 GPIO_ACTIVE_LOW>;
+
+				ports {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					port at 0 {
+						reg = <0>;
+
+						hdmi_out_in: endpoint {
+							data-lanes = <1 2 3 4>;
+							remote-endpoint = <&mipi_dsi_out>;
+						};
+					};
+
+					port at 1 {
+						reg = <1>;
+
+						lt8912_out: endpoint {
+							remote-endpoint = <&hdmi_connector_in>;
+						};
+					};
+				};
+			};
+		};
+
+		ddc_i2c_bus: i2c4 at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			clock-frequency = <100000>;
+		};
+
+		i2c4 at 3 {
+			reg = <3>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			clock-frequency = <100000>;
+
+			max7323: max7323 at 68 {
+				compatible = "maxim,max7323";
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_max7323>;
+				gpio-controller;
+				reg = <0x68>;
+				#gpio-cells = <2>;
+			};
+		};
+	};
+};
+
+&lcdif {
+	status = "okay";
+};
+
+&mipi_dsi {
+	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	ports {
+		port at 1 {
+			reg = <1>;
+			mipi_dsi_out: endpoint {
+				remote-endpoint = <&hdmi_out_in>;
+			};
+		};
+	};
+};
+
 &uart1 { /* console */
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1>;
@@ -368,6 +475,19 @@ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x49
 		>;
 	};
 
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_I2C4_SCL_I2C4_SCL			0x4000007f
+			MX8MQ_IOMUXC_I2C4_SDA_I2C4_SDA			0x4000007f
+		>;
+	};
+
+	pinctrl_max7323: max7323grp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x19
+		>;
+	};
+
 	pinctrl_reg_arm_dram: reg-arm-dramgrp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_SAI5_RXD3_GPIO3_IO24	0x16
-- 
2.25.1



From adrien.grassein at gmail.com  Thu Apr  1 00:23:54 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Thu,  1 Apr 2021 01:23:54 +0200
Subject: [PATCH v3 2/4] arm64: dts: imx8mq-nitrogen: add USB HOST support
In-Reply-To: <20210331232356.2204476-1-adrien.grassein@gmail.com>
References: <20210331232356.2204476-1-adrien.grassein@gmail.com>
Message-ID: <20210331232356.2204476-3-adrien.grassein@gmail.com>

Add the description for the USB host port.
This port is linked to a resettable USB HUB so handle
this reset signal with a GPIO hog.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 .../boot/dts/freescale/imx8mq-nitrogen.dts    | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
index b46f45a82be1..04992cbba56e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
@@ -102,6 +102,14 @@ ethphy0: ethernet-phy at 4 {
 	};
 };
 
+&gpio1 {
+	usb-host-reset-hog {
+		gpio-hog;
+		gpios = <14 GPIO_ACTIVE_HIGH>;
+		output-high;
+	};
+};
+
 &i2c1 {
 	clock-frequency = <400000>;
 	pinctrl-names = "default";
@@ -213,6 +221,22 @@ &usb3_phy0 {
 	status = "okay";
 };
 
+&usb_dwc3_1 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+/*
+ * On this board, USB host is connected to a resettable hub.
+ * The reset signal is connected to the GPIO <&gpio1 14 GPIO_ACTIVE_LOW>.
+ * You need to activate it in the bootloader or in the userspace.
+ */
+&usb3_phy1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb3_1>;
+};
+
 &usdhc1 {
 	assigned-clocks = <&clk IMX8MQ_CLK_USDHC1>;
 	assigned-clock-rates = <400000000>;
@@ -388,6 +412,12 @@ MX8MQ_IOMUXC_GPIO1_IO13_USB1_OTG_OC		0x16
 		>;
 	};
 
+	pinctrl_usb3_1: usb3-1grp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO14_GPIO1_IO14		0x16
+		>;
+	};
+
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK			0x83
-- 
2.25.1



From adrien.grassein at gmail.com  Thu Apr  1 00:23:53 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Thu,  1 Apr 2021 01:23:53 +0200
Subject: [PATCH v3 1/4] arm64: dts: imx8mq-nitrogen: add USB OTG support
In-Reply-To: <20210331232356.2204476-1-adrien.grassein@gmail.com>
References: <20210331232356.2204476-1-adrien.grassein@gmail.com>
Message-ID: <20210331232356.2204476-2-adrien.grassein@gmail.com>

Add the description for the USB OTG port.
The OTG port uses a dedicated regulator for vbus.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 .../boot/dts/freescale/imx8mq-nitrogen.dts    | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
index 81d269296610..b46f45a82be1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
@@ -34,6 +34,17 @@ power {
 		};
 	};
 
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_reg_usbotg_vbus>;
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
 	reg_vref_0v9: regulator-vref-0v9 {
 		compatible = "regulator-fixed";
 		regulator-name = "vref-0v9";
@@ -190,6 +201,18 @@ &uart2 {
 	status = "okay";
 };
 
+&usb_dwc3_0 {
+	dr_mode = "otg";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usb3_0>;
+	status = "okay";
+};
+
+&usb3_phy0 {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	status = "okay";
+};
+
 &usdhc1 {
 	assigned-clocks = <&clk IMX8MQ_CLK_USDHC1>;
 	assigned-clock-rates = <400000000>;
@@ -339,6 +362,12 @@ MX8MQ_IOMUXC_SD2_WP_GPIO2_IO20		0x16
 		>;
 	};
 
+	pinctrl_reg_usbotg_vbus: reg-usbotg-vbusgrp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12	0x16
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX		0x45
@@ -353,6 +382,12 @@ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX		0x45
 		>;
 	};
 
+	pinctrl_usb3_0: usb3-0grp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO13_USB1_OTG_OC		0x16
+		>;
+	};
+
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK			0x83
-- 
2.25.1



From cw00.choi at samsung.com  Thu Apr  1 01:16:30 2021
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 1 Apr 2021 09:16:30 +0900
Subject: [PATCH V8 1/8] PM / devfreq: Add cpu based scaling support to
 passive_governor
In-Reply-To: <1617195800.18432.3.camel@mtksdaap41>
References: <1616499241-4906-1-git-send-email-andrew-sh.cheng@mediatek.com>
 <CGME20210323113411epcas1p3b4367563007ca91c30201d7fc225bb67@epcas1p3.samsung.com>
 <1616499241-4906-2-git-send-email-andrew-sh.cheng@mediatek.com>
 <233a3bd6-7ab1-5da2-9184-a745eb253d86@samsung.com>
 <1617177820.15067.1.camel@mtksdaap41>
 <2ae8604d-0da6-4243-1b92-81b3917d7d48@samsung.com>
 <cad52436-b291-05bf-236f-7b7cb1fdbbff@samsung.com>
 <1617195800.18432.3.camel@mtksdaap41>
Message-ID: <fbb6c44b-eb77-14ce-9175-3f06030e6e0c@samsung.com>

On 3/31/21 10:03 PM, andrew-sh.cheng wrote:
> On Wed, 2021-03-31 at 17:35 +0900, Chanwoo Choi wrote:
>> On 3/31/21 5:27 PM, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 3/31/21 5:03 PM, andrew-sh.cheng wrote:
>>>> On Thu, 2021-03-25 at 17:14 +0900, Chanwoo Choi wrote:
>>>>> Hi,
>>>>>
>>>>> You are missing to add these patches to linux-pm mailing list.
>>>>> Need to send them to linu-pm ML.
>>>>>
>>>>> Also, before received this series, I tried to clean-up these patches
>>>>> on testing branch[1]. So that I add my comment with my clean-up case.
>>>>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!zIrzeDp9vPnm1_SDzVPuzqdHn3zWie9DnfBXaA-j9-CSrVc6aR9_rJQQiw81_CgAPh9XRRs$ 
>>>>>
>>>>> And 'Saravana Kannan <skannan at codeaurora.org>' is wrong email address.
>>>>> Please update the email or drop this email.
>>>>
>>>> Hi Chanwoo,
>>>>
>>>> Thank you for the advices.
>>>> I will resend patch v9 (add to linux-pm ML), remove this patch, and note
>>>> that my patch set base on
>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
>>>
>>> I has not yet test this patch[1] on devfreq-testing-passive-gov branch.
>>> So that if possible, I'd like you to test your patches with this patch[1] 
>>> and then if there is no problem, could you send the next patches with patch[1]?
>>>
>>> [1]https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing-passive-gov&id=39c80d11a8f42dd63ecea1e0df595a0ceb83b454__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJR2cQqZs$ 
>>
>>
>> Sorry for the confusion. I make the devfreq-testing-passive-gov[1]
>> branch based on latest devfreq-next branch.
>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
>>
>> First of all, if possible, I want to test them[1] with your patches in this series.
>> And then if there are no any problem, please let me know. After confirmed from you,
>> I'll send the patches of devfreq-testing-passive-gov[1] branch.
>> How about that?
>>
> Hi Chanwoo~
> 
> We will use this on Google Chrome project.
> Google Hsin-Yi has test your patch + my patch set v8 [2~8]
> 
>     make sure cci devfreqs runs with cpufreq.
>     suspend resume
>     speedometer2 benchmark
> It is okay.
> 
> Please send the patches of devfreq-testing-passive-gov[1] branch.
> 
> I will send patch v9 base on yours latter.

Thanks for your test. I'll send the patches today.

> 
> 
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 3/23/21 8:33 PM, Andrew-sh.Cheng wrote:
>>>>>> From: Saravana Kannan <skannan at codeaurora.org>
>>>>>>
>>>>>> Many CPU architectures have caches that can scale independent of the
>>>>>> CPUs. Frequency scaling of the caches is necessary to make sure that the
>>>>>> cache is not a performance bottleneck that leads to poor performance and
>>>>>> power. The same idea applies for RAM/DDR.
>>>>>>
>>>>>> To achieve this, this patch adds support for cpu based scaling to the
>>>>>> passive governor. This is accomplished by taking the current frequency
>>>>>> of each CPU frequency domain and then adjust the frequency of the cache
>>>>>> (or any devfreq device) based on the frequency of the CPUs. It listens
>>>>>> to CPU frequency transition notifiers to keep itself up to date on the
>>>>>> current CPU frequency.
>>>>>>
>>>>>> To decide the frequency of the device, the governor does one of the
>>>>>> following:
>>>>>> * Derives the optimal devfreq device opp from required-opps property of
>>>>>>   the parent cpu opp_table.
>>>>>>
>>>>>> * Scales the device frequency in proportion to the CPU frequency. So, if
>>>>>>   the CPUs are running at their max frequency, the device runs at its
>>>>>>   max frequency. If the CPUs are running at their min frequency, the
>>>>>>   device runs at its min frequency. It is interpolated for frequencies
>>>>>>   in between.
>>>>>>
>>>>>> Andrew-sh.Cheng change
>>>>>> dev_pm_opp_xlate_opp to dev_pm_opp_xlate_required_opp devfreq->max_freq
>>>>>> to devfreq->user_min_freq_req.data.freq.qos->min_freq.target_value
>>>>>> after kernel-5.7
>>>>>> Don't return -EINVAL in devfreq_passive_event_handler()
>>>>>> since it doesn't handle DEVFREQ_GOV_SUSPEND DEVFREQ_GOV_RESUME cases.
>>>>>>
>>>>>> Signed-off-by: Saravana Kannan <skannan at codeaurora.org>
>>>>>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>>>>>> Signed-off-by: Sibi Sankar <sibis at codeaurora.org>
>>>>>> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng at mediatek.com>
>>>>>> ---
>>>>>>  drivers/devfreq/Kconfig            |   2 +
>>>>>>  drivers/devfreq/governor_passive.c | 329 +++++++++++++++++++++++++++++++++++--
>>>>>>  include/linux/devfreq.h            |  29 +++-
>>>>>>  3 files changed, 342 insertions(+), 18 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>>>>> index 00704efe6398..f56132b0ae64 100644
>>>>>> --- a/drivers/devfreq/Kconfig
>>>>>> +++ b/drivers/devfreq/Kconfig
>>>>>> @@ -73,6 +73,8 @@ config DEVFREQ_GOV_PASSIVE
>>>>>>  	  device. This governor does not change the frequency by itself
>>>>>>  	  through sysfs entries. The passive governor recommends that
>>>>>>  	  devfreq device uses the OPP table to get the frequency/voltage.
>>>>>> +	  Alternatively the governor can also be chosen to scale based on
>>>>>> +	  the online CPUs current frequency.
>>>>>>  
>>>>>>  comment "DEVFREQ Drivers"
>>>>>>  
>>>>>> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
>>>>>> index b094132bd20b..9cc57b083839 100644
>>>>>> --- a/drivers/devfreq/governor_passive.c
>>>>>> +++ b/drivers/devfreq/governor_passive.c
>>>>>> @@ -8,11 +8,103 @@
>>>>>>   */
>>>>>>  
>>>>>>  #include <linux/module.h>
>>>>>> +#include <linux/cpu.h>
>>>>>> +#include <linux/cpufreq.h>
>>>>>> +#include <linux/cpumask.h>
>>>>>>  #include <linux/device.h>
>>>>>>  #include <linux/devfreq.h>
>>>>>> +#include <linux/slab.h>
>>>>>>  #include "governor.h"
>>>>>>  
>>>>>> -static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>>>> +struct devfreq_cpu_state {
>>>>>> +	unsigned int curr_freq;
>>>>>> +	unsigned int min_freq;
>>>>>> +	unsigned int max_freq;
>>>>>> +	unsigned int first_cpu;
>>>>>> +	struct device *cpu_dev;
>>>>>> +	struct opp_table *opp_table;
>>>>>> +};
>>>>>
>>>>> As I knew, the previous version has the description of structure
>>>>> as following:  I wan to add the description like below.
>>>>>
>>>>> And if you have no any objection, I'd like you to order
>>>>> the variables as following and use 'dev' instead of 'cpu_dev'
>>>>> because this patch use the 'cpu_state->cpu_dev' at the multiple points.
>>>>> I think that 'cpu_state->dev' is better than 'cpu_state->cpu_dev'.
>>>>> Also, I prefer to use 'cur_freq' instead of 'curr_freq'
>>>>> because devfreq subsystem uses 'cur_freq' for expressing the 'current frequency'.
>>>>>
>>>>> /**                                                                             
>>>>>  * struct devfreq_cpu_state - Hold the per-cpu data                              
>>>>>  * @dev:        reference to cpu device.                                        
>>>>>  * @first_cpu:  the cpumask of the first cpu of a policy.                       
>>>>>  * @opp_table:  reference to cpu opp table.                                     
>>>>>  * @cur_freq:   the current frequency of the cpu.                               
>>>>>  * @min_freq:   the min frequency of the cpu.                                   
>>>>>  * @max_freq:   the max frequency of the cpu.                                   
>>>>>  *                                                                              
>>>>>  * This structure stores the required cpu_data of a cpu.                        
>>>>>  * This is auto-populated by the governor.                                      
>>>>>  */                                                                             
>>>>> struct devfreq_cpu_state {                                                       
>>>>>          struct device *dev;                                                     
>>>>>          unsigned int first_cpu;                                                 
>>>>>
>>>>>          struct opp_table *opp_table;                                            
>>>>>          unsigned int cur_freq;                                                  
>>>>>          unsigned int min_freq;                                                  
>>>>>          unsigned int max_freq;                                                  
>>>>> };               
>>>>>
>>>>>
>>>>>> +
>>>>>> +static unsigned long xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data,
>>>>>> +					      unsigned int cpu)
>>>>>> +{
>>>>>> +	unsigned int cpu_min_freq, cpu_max_freq, cpu_curr_freq_khz, cpu_percent;
>>>>>> +	unsigned long dev_min_freq, dev_max_freq, dev_max_state;
>>>>>> +
>>>>>> +	struct devfreq_cpu_state *cpu_state = data->cpu_state[cpu];
>>>>>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>>>>>> +	unsigned long *dev_freq_table = devfreq->profile->freq_table;
>>>>>> +	struct dev_pm_opp *opp = NULL, *p_opp = NULL;
>>>>>> +	unsigned long cpu_curr_freq, freq;
>>>>>> +
>>>>>> +	if (!cpu_state || cpu_state->first_cpu != cpu ||
>>>>>> +	    !cpu_state->opp_table || !devfreq->opp_table)
>>>>>> +		return 0;
>>>>>> +
>>>>>> +	cpu_curr_freq = cpu_state->curr_freq * 1000;
>>>>>> +	p_opp = devfreq_recommended_opp(cpu_state->cpu_dev, &cpu_curr_freq, 0);
>>>>>> +	if (IS_ERR(p_opp))
>>>>>> +		return 0;
>>>>>> +
>>>>>> +	opp = dev_pm_opp_xlate_required_opp(cpu_state->opp_table,
>>>>>> +					    devfreq->opp_table, p_opp);
>>>>>> +	dev_pm_opp_put(p_opp);
>>>>>> +
>>>>>> +	if (!IS_ERR(opp)) {
>>>>>> +		freq = dev_pm_opp_get_freq(opp);
>>>>>> +		dev_pm_opp_put(opp);
>>>>>> +		goto out;
>>>>>> +	}
>>>>>> +
>>>>>> +	/* Use Interpolation if required opps is not available */
>>>>>> +	cpu_min_freq = cpu_state->min_freq;
>>>>>> +	cpu_max_freq = cpu_state->max_freq;
>>>>>> +	cpu_curr_freq_khz = cpu_state->curr_freq;
>>>>>> +
>>>>>> +	if (dev_freq_table) {
>>>>>> +		/* Get minimum frequency according to sorting order */
>>>>>> +		dev_max_state = dev_freq_table[devfreq->profile->max_state - 1];
>>>>>> +		if (dev_freq_table[0] < dev_max_state) {
>>>>>> +			dev_min_freq = dev_freq_table[0];
>>>>>> +			dev_max_freq = dev_max_state;
>>>>>> +		} else {
>>>>>> +			dev_min_freq = dev_max_state;
>>>>>> +			dev_max_freq = dev_freq_table[0];
>>>>>> +		}
>>>>>> +	} else {
>>>>>> +		dev_min_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>>>>>> +						     DEV_PM_QOS_MIN_FREQUENCY);
>>>>>> +		dev_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>>>>>> +						     DEV_PM_QOS_MAX_FREQUENCY);
>>>>>> +
>>>>>> +		if (dev_max_freq <= dev_min_freq)
>>>>>> +			return 0;
>>>>>> +	}
>>>>>> +	cpu_percent = ((cpu_curr_freq_khz - cpu_min_freq) * 100) / cpu_max_freq - cpu_min_freq;
>>>>>> +	freq = dev_min_freq + mult_frac(dev_max_freq - dev_min_freq, cpu_percent, 100);
>>>>>> +
>>>>>> +out:
>>>>>> +	return freq;
>>>>>> +}
>>>>>> +
>>>>>> +static int get_target_freq_with_cpufreq(struct devfreq *devfreq,
>>>>>> +					unsigned long *freq)
>>>>>> +{
>>>>>> +	struct devfreq_passive_data *p_data =
>>>>>> +				(struct devfreq_passive_data *)devfreq->data;
>>>>>> +	unsigned int cpu;
>>>>>> +	unsigned long target_freq = 0;
>>>>>> +
>>>>>> +	for_each_online_cpu(cpu)
>>>>>> +		target_freq = max(target_freq,
>>>>>> +				  xlate_cpufreq_to_devfreq(p_data, cpu));
>>>>>> +
>>>>>> +	*freq = target_freq;
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>
>>>>> As you knew, governor_passive.c was already used 
>>>>> both 'dev_pm_opp_xlate_required_opp' and 'devfreq_recommended_opp'
>>>>> to get the target from OPP. So, I wan to make the common function
>>>>> like 'get_taget_freq_by_required_opp' as following:
>>>>> If define 'get_taget_freq_by_required_opp' as following,
>>>>> it will be used for get_target_freq_with_devfreq().
>>>>> After finisied the review of this patch, I'll send the patch[2].
>>>>> [2] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing-passive-gov&id=101c5a087586ab2b5cf3370166a7e39227ca83cf__;!!CTRNKA9wMg0ARbw!zIrzeDp9vPnm1_SDzVPuzqdHn3zWie9DnfBXaA-j9-CSrVc6aR9_rJQQiw81_CgA6mp3Yqo$ 
>>>>>
>>>>> For example but this code is not tested,
>>>>> static unsigned long get_taget_freq_by_required_opp(struct device *p_dev,
>>>>> 						struct opp_table *p_opp_table,
>>>>> 						struct opp_table *opp_table,
>>>>> 						unsigned long freq)
>>>>> {
>>>>> 	struct dev_pm_opp *opp = NULL, *p_opp = NULL;
>>>>>
>>>>> 	if (!p_dev || !p_opp_table || !opp_table || !freq)
>>>>> 		return 0;
>>>>>
>>>>> 	p_opp = devfreq_recommended_opp(p_dev, &freq, 0);
>>>>> 	if (IS_ERR(p_opp))
>>>>> 		return 0;
>>>>>
>>>>> 	opp = dev_pm_opp_xlate_required_opp(p_opp_table, opp_table, p_opp);
>>>>> 	dev_pm_opp_put(p_opp);
>>>>>
>>>>> 	if (IS_ERR(opp))
>>>>> 		return 0;
>>>>>
>>>>> 	freq = dev_pm_opp_get_freq(opp);
>>>>> 	dev_pm_opp_put(opp);
>>>>>
>>>>> 	return freq;
>>>>> }
>>>>>
>>>>> static int get_target_freq_with_cpufreq(struct devfreq *devfreq,
>>>>> 					unsigned long *target_freq)
>>>>> {
>>>>> 	struct devfreq_passive_data *p_data =
>>>>> 				(struct devfreq_passive_data *)devfreq->data;
>>>>> 	struct devfreq_cpu_data *cpu_data;
>>>>> 	unsigned long cpu, cpu_cur, cpu_min, cpu_max, cpu_percent;
>>>>> 	unsigned long dev_min, dev_max;
>>>>> 	unsigned long freq = 0;
>>>>>
>>>>> 	for_each_online_cpu(cpu) {
>>>>> 		cpu_data = p_data->cpu_data[cpu];
>>>>> 		if (!cpu_data || cpu_data->first_cpu != cpu)
>>>>> 			continue;
>>>>>
>>>>> 		/* Get target freq via required opps */
>>>>> 		cpu_cur = cpu_data->cur_freq * HZ_PER_KHZ;
>>>>> 		freq = get_taget_freq_by_required_opp(cpu_data->dev,
>>>>> 					cpu_data->opp_table,
>>>>> 					devfreq->opp_table, cpu_cur);
>>>>> 		if (freq) {
>>>>> 			*target_freq = max(freq, *target_freq);
>>>>> 			continue;
>>>>> 		}
>>>>>
>>>>> 		/* Use Interpolation if required opps is not available */
>>>>> 		devfreq_get_freq_range(devfreq, &dev_min, &dev_max);
>>>>>
>>>>> 		cpu_min = cpu_data->min_freq;
>>>>> 		cpu_max = cpu_data->max_freq;
>>>>> 		cpu_cur = cpu_data->cur_freq;
>>>>>
>>>>> 		cpu_percent = ((cpu_cur - cpu_min) * 100) / cpu_max - cpu_min;
>>>>> 		freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100);
>>>>>
>>>>> 		*target_freq = max(freq, *target_freq);
>>>>> 	}
>>>>>
>>>>> 	return 0;
>>>>> }
>>>>>
>>>>>> +
>>>>>> +static int get_target_freq_with_devfreq(struct devfreq *devfreq,
>>>>>>  					unsigned long *freq)
>>>>>>  {
>>>>>>  	struct devfreq_passive_data *p_data
>>>>>> @@ -23,14 +115,6 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>>>>  	int i, count;
>>>>>>  
>>>>>>  	/*
>>>>>> -	 * If the devfreq device with passive governor has the specific method
>>>>>> -	 * to determine the next frequency, should use the get_target_freq()
>>>>>> -	 * of struct devfreq_passive_data.
>>>>>> -	 */
>>>>>> -	if (p_data->get_target_freq)
>>>>>> -		return p_data->get_target_freq(devfreq, freq);
>>>>>> -
>>>>>> -	/*
>>>>>>  	 * If the parent and passive devfreq device uses the OPP table,
>>>>>>  	 * get the next frequency by using the OPP table.
>>>>>>  	 */
>>>>>> @@ -98,6 +182,37 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>>>>  	return 0;
>>>>>>  }
>>>>>>  
>>>>>> +static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>>>> +					   unsigned long *freq)
>>>>>> +{
>>>>>> +	struct devfreq_passive_data *p_data =
>>>>>> +		(struct devfreq_passive_data *)devfreq->data;
>>>>>> +	int ret;
>>>>>> +
>>>>>> +	/*
>>>>>> +	 * If the devfreq device with passive governor has the specific method
>>>>>> +	 * to determine the next frequency, should use the get_target_freq()
>>>>>> +	 * of struct devfreq_passive_data.
>>>>>> +	 */
>>>>>> +	if (p_data->get_target_freq)
>>>>>> +		return p_data->get_target_freq(devfreq, freq);
>>>>>> +
>>>>>> +	switch (p_data->parent_type) {
>>>>>> +	case DEVFREQ_PARENT_DEV:
>>>>>> +		ret = get_target_freq_with_devfreq(devfreq, freq);
>>>>>> +		break;
>>>>>> +	case CPUFREQ_PARENT_DEV:
>>>>>> +		ret = get_target_freq_with_cpufreq(devfreq, freq);
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		ret = -EINVAL;
>>>>>> +		dev_err(&devfreq->dev, "Invalid parent type\n");
>>>>>> +		break;
>>>>>> +	}
>>>>>> +
>>>>>> +	return ret;
>>>>>> +}
>>>>>> +
>>>>>>  static int devfreq_passive_notifier_call(struct notifier_block *nb,
>>>>>>  				unsigned long event, void *ptr)
>>>>>>  {
>>>>>> @@ -130,16 +245,200 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
>>>>>>  	return NOTIFY_DONE;
>>>>>>  }
>>>>>>  
>>>>>> +static int cpufreq_passive_notifier_call(struct notifier_block *nb,
>>>>>> +					 unsigned long event, void *ptr)
>>>>>> +{
>>>>>> +	struct devfreq_passive_data *data =
>>>>>> +			container_of(nb, struct devfreq_passive_data, nb);
>>>>>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>>>>>> +	struct devfreq_cpu_state *cpu_state;
>>>>>> +	struct cpufreq_freqs *cpu_freq = ptr;
>>>>>
>>>>> Use 'freqs' variable name.  I prefer to use the same variable name
>>>>> for both devfreq_freqs and cpufreq_freqs instance.
>>>>>
>>>>>> +	unsigned int curr_freq;
>>>>>
>>>>> As I commented above, better to use 'cur_frq' instead of 'curr_freq'
>>>>> if there is no any special reason.
>>>>>
>>>>>> +	int ret;
>>>>>> +
>>>>>> +	if (event != CPUFREQ_POSTCHANGE || !cpu_freq ||
>>>>>> +	    !data->cpu_state[cpu_freq->policy->cpu])
>>>>>> +		return 0;
>>>>>> +
>>>>>> +	cpu_state = data->cpu_state[cpu_freq->policy->cpu];
>>>>>> +	if (cpu_state->curr_freq == cpu_freq->new)
>>>>>> +		return 0;
>>>>>> +
>>>>>> +	/* Backup current freq and pre-update cpu state freq*/
>>>>>
>>>>> I think that this commnet is not critial. So, please drop this comment.
>>>>>
>>>>>> +	curr_freq = cpu_state->curr_freq;
>>>>>> +	cpu_state->curr_freq = cpu_freq->new;
>>>>>> +
>>>>>> +	mutex_lock(&devfreq->lock);
>>>>>> +	ret = update_devfreq(devfreq);
>>>>>
>>>>> I recommend to use 'devfreq_update_target' instead of 'update_devfreq'
>>>>> as following:
>>>>> 	devfreq_update_target(devfreq, freqs->new);
>>>>>
>>>>>> +	mutex_unlock(&devfreq->lock);
>>>>>> +	if (ret) {
>>>>>> +		cpu_state->curr_freq = curr_freq;
>>>>>> +		dev_err(&devfreq->dev, "Couldn't update the frequency.\n");
>>>>>> +		return ret;
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int cpufreq_passive_register(struct devfreq_passive_data **p_data)
>>>>>
>>>>> In order to keep the consistent style of function name,
>>>>> please change the name as following because devfreq defines
>>>>> the function name as 'devfreq_regiter_notifier'
>>>>> - cpufreq_passive_register -> cpufreq_passive_register_notifier
>>>>>
>>>>>> +{
>>>>>> +	struct devfreq_passive_data *data = *p_data;
>>>>>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>>>>>> +	struct device *dev = devfreq->dev.parent;
>>>>>> +	struct opp_table *opp_table = NULL;
>>>>>> +	struct devfreq_cpu_state *cpu_state;
>>>>>> +	struct cpufreq_policy *policy;
>>>>>> +	struct device *cpu_dev;
>>>>>> +	unsigned int cpu;
>>>>>> +	int ret;
>>>>>> +
>>>>>> +	get_online_cpus();
>>>>>> +
>>>>>> +	data->nb.notifier_call = cpufreq_passive_notifier_call;
>>>>>> +	ret = cpufreq_register_notifier(&data->nb,
>>>>>> +					CPUFREQ_TRANSITION_NOTIFIER);
>>>>>> +	if (ret) {
>>>>>> +		dev_err(dev, "Couldn't register cpufreq notifier.\n");
>>>>>> +		data->nb.notifier_call = NULL;
>>>>>> +		goto out;
>>>>>> +	}
>>>>>> +
>>>>>> +	/* Populate devfreq_cpu_state */
>>>>>
>>>>> Don't need this comment. Please drop it.
>>>>>
>>>>>> +	for_each_online_cpu(cpu) {
>>>>>> +		if (data->cpu_state[cpu])
>>>>>> +			continue;
>>>>>> +
>>>>>> +		policy = cpufreq_cpu_get(cpu);
>>>>>> +		if (!policy) {
>>>>>> +			ret = -EINVAL;
>>>>>> +			goto out;
>>>>>> +		} else if (PTR_ERR(policy) == -EPROBE_DEFER) {
>>>>>> +			ret = -EPROBE_DEFER;
>>>>>> +			goto out;
>>>>>> +		} else if (IS_ERR(policy)) {
>>>>>> +			ret = PTR_ERR(policy);
>>>>>> +			dev_err(dev, "Couldn't get the cpufreq_poliy.\n");
>>>>>> +			goto out;
>>>>>> +		}
>>>>>
>>>>> Use dev_err_probe() funciotn to handle hte EPROBE_DEFER.
>>>>> It make code more simple.
>>>>>
>>>>>> +
>>>>>> +		cpu_state = kzalloc(sizeof(*cpu_state), GFP_KERNEL);
>>>>>> +		if (!cpu_state) {
>>>>>> +			ret = -ENOMEM;
>>>>>> +			goto out;
>>>>>> +		}
>>>>>> +
>>>>>> +		cpu_dev = get_cpu_device(cpu);
>>>>>> +		if (!cpu_dev) {
>>>>>> +			dev_err(dev, "Couldn't get cpu device.\n");
>>>>>> +			ret = -ENODEV;
>>>>>> +			goto out;
>>>>>> +		}
>>>>>> +
>>>>>> +		opp_table = dev_pm_opp_get_opp_table(cpu_dev);
>>>>>> +		if (IS_ERR(devfreq->opp_table)) {
>>>>>> +			ret = PTR_ERR(opp_table);
>>>>>> +			goto out;
>>>>>> +		}
>>>>>> +
>>>>>> +		cpu_state->cpu_dev = cpu_dev;
>>>>>> +		cpu_state->opp_table = opp_table;
>>>>>> +		cpu_state->first_cpu = cpumask_first(policy->related_cpus);
>>>>>> +		cpu_state->curr_freq = policy->cur;
>>>>>> +		cpu_state->min_freq = policy->cpuinfo.min_freq;
>>>>>> +		cpu_state->max_freq = policy->cpuinfo.max_freq;
>>>>>> +		data->cpu_state[cpu] = cpu_state;
>>>>>> +
>>>>>> +		cpufreq_cpu_put(policy);
>>>>>> +	}
>>>>>> +
>>>>>> +out:
>>>>>> +	put_online_cpus();
>>>>>> +	if (ret)
>>>>>> +		return ret;
>>>>>> +
>>>>>> +	/* Update devfreq */
>>>>>> +	mutex_lock(&devfreq->lock);
>>>>>> +	ret = update_devfreq(devfreq);
>>>>>
>>>>>> +	mutex_unlock(&devfreq->lock);
>>>>>> +	if (ret)
>>>>>> +		dev_err(dev, "Couldn't update the frequency.\n");
>>>>>> +
>>>>>> +	return ret;
>>>>>> +}
>>>>>> +
>>>>>> +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data)
>>>>>
>>>>> As I commented above, please change the name as following:
>>>>> - cpufreq_passive_unregister -> cpufreq_passive_unregister_notifier
>>>>>
>>>>>> +{
>>>>>> +	struct devfreq_passive_data *data = *p_data;
>>>>>> +	struct devfreq_cpu_state *cpu_state;
>>>>>> +	int cpu;
>>>>>> +
>>>>>> +	if (data->nb.notifier_call)
>>>>>> +		cpufreq_unregister_notifier(&data->nb,
>>>>>> +					    CPUFREQ_TRANSITION_NOTIFIER);
>>>>>> +
>>>>>> +	for_each_possible_cpu(cpu) {
>>>>>> +		cpu_state = data->cpu_state[cpu];
>>>>>> +		if (cpu_state) {
>>>>>> +			if (cpu_state->opp_table)
>>>>>> +				dev_pm_opp_put_opp_table(cpu_state->opp_table);
>>>>>> +			kfree(cpu_state);
>>>>>> +			cpu_state = NULL;
>>>>>> +		}
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>> +
>>>>>> +int register_parent_dev_notifier(struct devfreq_passive_data **p_data)
>>>>>> +{
>>>>>> +	struct notifier_block *nb = &(*p_data)->nb;
>>>>>> +	int ret = 0;
>>>>>> +
>>>>>> +	switch ((*p_data)->parent_type) {
>>>>>> +	case DEVFREQ_PARENT_DEV:
>>>>>> +		nb->notifier_call = devfreq_passive_notifier_call;
>>>>>> +		ret = devfreq_register_notifier((struct devfreq *)(*p_data)->parent, nb,
>>>>>> +						DEVFREQ_TRANSITION_NOTIFIER);
>>>>>> +		break;
>>>>>> +	case CPUFREQ_PARENT_DEV:
>>>>>> +		ret = cpufreq_passive_register(p_data);
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		ret = -EINVAL;
>>>>>> +		break;
>>>>>> +	}
>>>>>> +	return ret;
>>>>>> +}
>>>>>> +
>>>>>> +int unregister_parent_dev_notifier(struct devfreq_passive_data **p_data)
>>>>>> +{
>>>>>> +	int ret = 0;
>>>>>> +
>>>>>> +	switch ((*p_data)->parent_type) {
>>>>>> +	case DEVFREQ_PARENT_DEV:
>>>>>> +		WARN_ON(devfreq_unregister_notifier((struct devfreq *)(*p_data)->parent,
>>>>>> +						    &(*p_data)->nb,
>>>>>> +						    DEVFREQ_TRANSITION_NOTIFIER));
>>>>>> +		break;
>>>>>> +	case CPUFREQ_PARENT_DEV:
>>>>>> +		cpufreq_passive_unregister(p_data);
>>>>>> +		break;
>>>>>> +	default:
>>>>>> +		ret = -EINVAL;
>>>>>> +		break;
>>>>>> +	}
>>>>>> +	return ret;
>>>>>> +}
>>>>>
>>>>> I think that you don't need to define register_parent_dev_notifier
>>>>> and unregister_parent_dev_notifier as the separate functions.
>>>>>
>>>>> Instead of the separate functions, just add the code
>>>>> into devfreq_passive_event_handler.
>>>>>
>>>>>
>>>>>> +
>>>>>>  static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>>>>>  				unsigned int event, void *data)
>>>>>>  {
>>>>>>  	struct devfreq_passive_data *p_data
>>>>>>  			= (struct devfreq_passive_data *)devfreq->data;
>>>>>>  	struct devfreq *parent = (struct devfreq *)p_data->parent;
>>>>>> -	struct notifier_block *nb = &p_data->nb;
>>>>>>  	int ret = 0;
>>>>>>  
>>>>>> -	if (!parent)
>>>>>> +	if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent)
>>>>>>  		return -EPROBE_DEFER;
>>>>>>  
>>>>>>  	switch (event) {
>>>>>> @@ -147,13 +446,11 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>>>>>  		if (!p_data->this)
>>>>>>  			p_data->this = devfreq;
>>>>>>  
>>>>>> -		nb->notifier_call = devfreq_passive_notifier_call;
>>>>>> -		ret = devfreq_register_notifier(parent, nb,
>>>>>> -					DEVFREQ_TRANSITION_NOTIFIER);
>>>>>> +		ret = register_parent_dev_notifier(&p_data);
>>>>>>  		break;
>>>>>> +
>>>>>>  	case DEVFREQ_GOV_STOP:
>>>>>> -		WARN_ON(devfreq_unregister_notifier(parent, nb,
>>>>>> -					DEVFREQ_TRANSITION_NOTIFIER));
>>>>>> +		ret = unregister_parent_dev_notifier(&p_data);
>>>>>>  		break;
>>>>>>  	default:
>>>>>>  		break;
>>>>>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>>>>>> index 26ea0850be9b..e0093b7c805c 100644
>>>>>> --- a/include/linux/devfreq.h
>>>>>> +++ b/include/linux/devfreq.h
>>>>>> @@ -280,6 +280,25 @@ struct devfreq_simple_ondemand_data {
>>>>>>  
>>>>>>  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
>>>>>>  /**
>>>>>> + * struct devfreq_cpu_state - holds the per-cpu state
>>>>>> + * @freq:	the current frequency of the cpu.
>>>>>> + * @min_freq:	the min frequency of the cpu.
>>>>>> + * @max_freq:	the max frequency of the cpu.
>>>>>> + * @first_cpu:	the cpumask of the first cpu of a policy.
>>>>>> + * @dev:	reference to cpu device.
>>>>>> + * @opp_table:	reference to cpu opp table.
>>>>>> + *
>>>>>> + * This structure stores the required cpu_state of a cpu.
>>>>>> + * This is auto-populated by the governor.
>>>>>> + */
>>>>>> +struct devfreq_cpu_state;
>>>>>> +
>>>>>> +enum devfreq_parent_dev_type {
>>>>>> +	DEVFREQ_PARENT_DEV,
>>>>>> +	CPUFREQ_PARENT_DEV,
>>>>>> +};
>>>>>> +
>>>>>> +/**
>>>>>>   * struct devfreq_passive_data - ``void *data`` fed to struct devfreq
>>>>>>   *	and devfreq_add_device
>>>>>>   * @parent:	the devfreq instance of parent device.
>>>>>> @@ -290,13 +309,15 @@ struct devfreq_simple_ondemand_data {
>>>>>>   *			using governors except for passive governor.
>>>>>>   *			If the devfreq device has the specific method to decide
>>>>>>   *			the next frequency, should use this callback.
>>>>>> + * @parent_type:	parent type of the device
>>>>>>   * @this:	the devfreq instance of own device.
>>>>>>   * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
>>>>>> + * @cpu_state:		the state min/max/current frequency of all online cpu's
>>>>>>   *
>>>>>>   * The devfreq_passive_data have to set the devfreq instance of parent
>>>>>>   * device with governors except for the passive governor. But, don't need to
>>>>>> - * initialize the 'this' and 'nb' field because the devfreq core will handle
>>>>>> - * them.
>>>>>> + * initialize the 'this', 'nb' and 'cpu_state' field because the devfreq core
>>>>>> + * will handle them.
>>>>>>   */
>>>>>>  struct devfreq_passive_data {
>>>>>>  	/* Should set the devfreq instance of parent device */
>>>>>> @@ -305,9 +326,13 @@ struct devfreq_passive_data {
>>>>>>  	/* Optional callback to decide the next frequency of passvice device */
>>>>>>  	int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>>>>>>  
>>>>>> +	/* Should set the type of parent device */
>>>>>> +	enum devfreq_parent_dev_type parent_type;
>>>>>> +
>>>>>>  	/* For passive governor's internal use. Don't need to set them */
>>>>>>  	struct devfreq *this;
>>>>>>  	struct notifier_block nb;
>>>>>> +	struct devfreq_cpu_state *cpu_state[NR_CPUS];
>>>>>>  };
>>>>>>  #endif
>>>>>>  
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


From andrew at aj.id.au  Thu Apr  1 01:04:51 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Thu, 01 Apr 2021 10:34:51 +1030
Subject: [PATCH 3/3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <20210330002338.335-4-zev@bewilderbeest.net>
References: <20210330002338.335-1-zev@bewilderbeest.net>
 <20210330002338.335-4-zev@bewilderbeest.net>
Message-ID: <815c666b-d657-4d0a-bea4-d2e182d9e5d1@www.fastmail.com>



On Tue, 30 Mar 2021, at 10:53, Zev Weiss wrote:
> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
> mini-ITX 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 host power control, serial console and
> KVM support, and POST code snooping.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 188 ++++++++++++++++++
>  1 file changed, 188 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> 
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts 
> b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> new file mode 100644
> index 000000000000..27b34c3cf67a
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/{
> +	model = "ASRock E3C246D4I BMC";
> +	compatible = "aspeed,ast2500";
> +
> +	aliases {
> +		serial4 = &uart5;
> +	};
> +
> +	chosen {
> +		stdout-path = &uart5;
> +		bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
> +	};
> +
> +	memory at 80000000 {
> +		reg = <0x80000000 0x20000000>;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		heartbeat {
> +			/* BMC_HB_LED_N */
> +			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "timer";
> +		};
> +
> +		system-fault {
> +			/* SYSTEM_FAULT_LED_N */
> +			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> +			panic-indicator;
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		uid-button {
> +			label = "uid-button";
> +			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> +			linux,code = <ASPEED_GPIO(F, 1)>;
> +		};
> +	};
> +
> +	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>;
> +	};
> +};

You're hooking up the ADC lines to the iio-hwmon bridge...
> +
> +&adc {
> +	status = "okay";
> +};

But you haven't requested the ADC lines from pinmux here.

It will *happen* to work as expected because ADC is the default mux 
state for the pins, but by not requesting the lines you're leaving the 
pins available for a conflicting request, which can be annoying to 
debug.

> +
> +&kcs3 {
> +	status = "okay";
> +	aspeed,lpc-io-reg = <0xca2>;
> +};

Given you need KCS support, do you mind testing my KCS series?

https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew at aj.id.au/

The cover letter got detached, and is here:

https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew at aj.id.au/

Andrew


From zev at bewilderbeest.net  Thu Apr  1 01:26:41 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 19:26:41 -0500
Subject: [PATCH 3/3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <815c666b-d657-4d0a-bea4-d2e182d9e5d1@www.fastmail.com>
References: <20210330002338.335-1-zev@bewilderbeest.net>
 <20210330002338.335-4-zev@bewilderbeest.net>
 <815c666b-d657-4d0a-bea4-d2e182d9e5d1@www.fastmail.com>
Message-ID: <YGUTQZJLyILvdKhl@hatter.bewilderbeest.net>

On Wed, Mar 31, 2021 at 07:04:51PM CDT, Andrew Jeffery wrote:
>
>
>On Tue, 30 Mar 2021, at 10:53, Zev Weiss wrote:
>> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
>> mini-ITX 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 host power control, serial console and
>> KVM support, and POST code snooping.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 188 ++++++++++++++++++
>>  1 file changed, 188 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>>
>> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>> b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>> new file mode 100644
>> index 000000000000..27b34c3cf67a
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>> @@ -0,0 +1,188 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/dts-v1/;
>> +
>> +#include "aspeed-g5.dtsi"
>> +#include <dt-bindings/gpio/aspeed-gpio.h>
>> +#include <dt-bindings/i2c/i2c.h>
>> +
>> +/{
>> +	model = "ASRock E3C246D4I BMC";
>> +	compatible = "aspeed,ast2500";
>> +
>> +	aliases {
>> +		serial4 = &uart5;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = &uart5;
>> +		bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
>> +	};
>> +
>> +	memory at 80000000 {
>> +		reg = <0x80000000 0x20000000>;
>> +	};
>> +
>> +	leds {
>> +		compatible = "gpio-leds";
>> +
>> +		heartbeat {
>> +			/* BMC_HB_LED_N */
>> +			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
>> +			linux,default-trigger = "timer";
>> +		};
>> +
>> +		system-fault {
>> +			/* SYSTEM_FAULT_LED_N */
>> +			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
>> +			panic-indicator;
>> +		};
>> +	};
>> +
>> +	gpio-keys {
>> +		compatible = "gpio-keys";
>> +
>> +		uid-button {
>> +			label = "uid-button";
>> +			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
>> +			linux,code = <ASPEED_GPIO(F, 1)>;
>> +		};
>> +	};
>> +
>> +	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>;
>> +	};
>> +};
>
>You're hooking up the ADC lines to the iio-hwmon bridge...
>> +
>> +&adc {
>> +	status = "okay";
>> +};
>
>But you haven't requested the ADC lines from pinmux here.
>
>It will *happen* to work as expected because ADC is the default mux
>state for the pins, but by not requesting the lines you're leaving the
>pins available for a conflicting request, which can be annoying to
>debug.
>

Ack, thanks -- will fix & resend.

>> +
>> +&kcs3 {
>> +	status = "okay";
>> +	aspeed,lpc-io-reg = <0xca2>;
>> +};
>
>Given you need KCS support, do you mind testing my KCS series?
>
>https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew at aj.id.au/
>

Sure, I'll try to give that a shot and report back in the next day or 
two.

>The cover letter got detached, and is here:
>
>https://lore.kernel.org/linux-arm-kernel/20210319061952.145040-1-andrew at aj.id.au/
>
>Andrew


From rashmica.g at gmail.com  Thu Apr  1 01:33:14 2021
From: rashmica.g at gmail.com (Rashmica Gupta)
Date: Thu,  1 Apr 2021 11:33:14 +1100
Subject: [PATCH v2] ARM: dts: aspeed: rainier: Add iio-hwmon bridge for temp
 sensors
Message-ID: <20210401003314.167178-1-rashmica.g@gmail.com>

Add iio-hwmon bridges for the dps310 and si7020 sensors so we can
access them via the hwmon subsystem.

Signed-off-by: Rashmica Gupta <rashmica.g at gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index fefb0b8fd6d5..7a2bcc373852 100644
--- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -173,6 +173,16 @@ i2c2mux3: i2c at 3 {
 		};
 	};
 
+	iio-hwmon-dps310 {
+		compatible = "iio-hwmon";
+		io-channels = <&dps 0>;
+	};
+
+	iio-hwmon-si7020 {
+		compatible = "iio-hwmon";
+		io-channels = <&humidity 1>;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 
@@ -1972,9 +1982,10 @@ &i2c7 {
 	multi-master;
 	status = "okay";
 
-	si7021-a20 at 20 {
+	humidity: si7021-a20 at 20 {
 		compatible = "silabs,si7020";
 		reg = <0x20>;
+		#io-channel-cells = <1>;
 	};
 
 	tmp275 at 48 {
-- 
2.26.3



From zev at bewilderbeest.net  Thu Apr  1 01:56:59 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 19:56:59 -0500
Subject: [PATCH v2 0/3] simplify Aspeed VUART SIRQ polarity DT config
In-Reply-To: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
Message-ID: <20210401005702.28271-1-zev@bewilderbeest.net>

The aspeed,sirq-polarity-sense property was a bit of a design mistake
in that it ties Aspeed VUART SIRQ polarity to SCU register bits that
aren't really inherently related to it.

This patch series deprecates that property (though we hope to
eventually remove it) and adds a simple boolean property
(aspeed,sirq-active-high) to use instead.


Changes since v1:
 - deprecate and retain aspeed,sirq-polarity-sense instead of removing it
 - drop e3c246d4i dts addition from this series


Zev Weiss (3):
  dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
  drivers/tty/serial/8250: add DT property for aspeed vuart sirq
    polarity
  dt-bindings: serial: 8250: add aspeed,sirq-active-high

 Documentation/devicetree/bindings/serial/8250.yaml | 14 +++++++++++---
 drivers/tty/serial/8250/8250_aspeed_vuart.c        |  3 +++
 2 files changed, 14 insertions(+), 3 deletions(-)

-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  1 01:57:00 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 19:57:00 -0500
Subject: [PATCH v2 1/3] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210401005702.28271-1-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
Message-ID: <20210401005702.28271-2-zev@bewilderbeest.net>

This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it
was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
       offset and bit number to identify how the SIRQ polarity should be
       configured. One possible data source is the LPC/eSPI mode bit. Only
       applicable to aspeed,ast2500-vuart.
+    deprecated: true
 
 required:
   - reg
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  1 01:57:01 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 19:57:01 -0500
Subject: [PATCH v2 2/3] drivers/tty/serial/8250: add DT property for aspeed
 vuart sirq polarity
In-Reply-To: <20210401005702.28271-1-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
Message-ID: <20210401005702.28271-3-zev@bewilderbeest.net>

This provides a simple boolean to use instead of the deprecated
aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..e5ef9f957f9a 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -482,6 +482,9 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 		of_node_put(sirq_polarity_sense_args.np);
 	}
 
+	if (of_property_read_bool(np, "aspeed,sirq-active-high"))
+		aspeed_vuart_set_sirq_polarity(vuart, 1);
+
 	aspeed_vuart_set_enabled(vuart, true);
 	aspeed_vuart_set_host_tx_discard(vuart, true);
 	platform_set_drvdata(pdev, vuart);
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  1 01:57:02 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 19:57:02 -0500
Subject: [PATCH v2 3/3] dt-bindings: serial: 8250: add aspeed, sirq-active-high
In-Reply-To: <20210401005702.28271-1-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
Message-ID: <20210401005702.28271-4-zev@bewilderbeest.net>

This provides a simpler, more direct alternative to the deprecated
aspeed,sirq-polarity-sense property for indicating the polarity of
the Aspeed VUART's SIRQ line.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..e79bb6ab9d2c 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,9 @@ maintainers:
 allOf:
   - $ref: /schemas/serial.yaml#
   - if:
-      required:
-        - aspeed,sirq-polarity-sense
+      anyOf:
+        - required: [ aspeed,sirq-active-high ]
+        - required: [ aspeed,sirq-polarity-sense ]
     then:
       properties:
         compatible:
@@ -190,6 +191,12 @@ properties:
       applicable to aspeed,ast2500-vuart.
     deprecated: true
 
+  aspeed,sirq-active-high:
+    type: boolean
+    description: |
+      Set to indicate that the SIRQ polarity is active-high (default
+      is active-low).  Only applicable to aspeed,ast2500-vuart.
+
 required:
   - reg
   - interrupts
@@ -228,7 +235,7 @@ examples:
         interrupts = <8>;
         clocks = <&syscon ASPEED_CLK_APB>;
         no-loopback-test;
-        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
+        aspeed,sirq-active-high;
     };
 
 ...
-- 
2.31.1



From lkp at intel.com  Thu Apr  1 02:25:49 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 01 Apr 2021 09:25:49 +0800
Subject: [nomadik:ux500-href-dts-fixups] BUILD SUCCESS
 520be71b4f8dd514903b05d764a04134714c8175
Message-ID: <6065211d.kDafUyECrYn6QUpY%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
branch HEAD: 520be71b4f8dd514903b05d764a04134714c8175  spi: pl022: Convert to use GPIO descriptors

elapsed time: 722m

configs tested: 72
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
i386                             allyesconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  1 02:25:38 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 01 Apr 2021 09:25:38 +0800
Subject: [nomadik:ux500-golden-v5.12-rc2] BUILD SUCCESS
 c317b4bf220412be419ed080561fe434305499bf
Message-ID: <60652112.tPIosSk6HW5rQi2Y%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-golden-v5.12-rc2
branch HEAD: c317b4bf220412be419ed080561fe434305499bf  iio: imu: inv_mpu6050: Use as standalone trigger

elapsed time: 722m

configs tested: 104
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                      cm5200_defconfig
arc                            hsdk_defconfig
openrisc                 simple_smp_defconfig
powerpc                        icon_defconfig
powerpc                 mpc85xx_cds_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                        stmark2_defconfig
arm                            zeus_defconfig
powerpc                      walnut_defconfig
microblaze                          defconfig
powerpc                 mpc8315_rdb_defconfig
m68k                          multi_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  1 02:25:33 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 01 Apr 2021 09:25:33 +0800
Subject: [nomadik:ux500-dts-v5.13] BUILD SUCCESS
 fa99edd84feacc3c5609fbc51744c37d33a2c65a
Message-ID: <6065210d.ydGf+zH3iTEvnnDI%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-dts-v5.13
branch HEAD: fa99edd84feacc3c5609fbc51744c37d33a2c65a  ARM: dts: ux500: Add Cypress CTTYSP touch to TVK UIB

elapsed time: 722m

configs tested: 63
configs skipped: 93

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                        stmark2_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                             allnoconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  1 02:25:36 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 01 Apr 2021 09:25:36 +0800
Subject: [nomadik:ux500-gavini-v5.12-rc2] BUILD SUCCESS
 a811a4d293ff66c42578a29749f06288e321ea26
Message-ID: <60652110.03wU1MBPuIcQNaCB%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-gavini-v5.12-rc2
branch HEAD: a811a4d293ff66c42578a29749f06288e321ea26  ARM: dts: ux500: Add device tree for Samsung Gavini

elapsed time: 722m

configs tested: 109
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                      cm5200_defconfig
arc                            hsdk_defconfig
openrisc                 simple_smp_defconfig
powerpc                        icon_defconfig
powerpc                 mpc85xx_cds_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                        stmark2_defconfig
mips                        workpad_defconfig
sh                           se7722_defconfig
arm                         lpc32xx_defconfig
xtensa                       common_defconfig
sh                        sh7757lcr_defconfig
arm                            zeus_defconfig
powerpc                      walnut_defconfig
microblaze                          defconfig
powerpc                 mpc8315_rdb_defconfig
m68k                          multi_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From sboyd at kernel.org  Thu Apr  1 02:48:40 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 31 Mar 2021 18:48:40 -0700
Subject: [PATCH] clk: zynqmp: move zynqmp_pll_set_mode out of round_rate
 callback
In-Reply-To: <20210331090018.3464094-1-quanyang.wang@windriver.com>
References: <20210331090018.3464094-1-quanyang.wang@windriver.com>
Message-ID: <161724172079.2260335.16388981768978108196@swboyd.mtv.corp.google.com>

Quoting quanyang.wang at windriver.com (2021-03-31 02:00:18)
> From: Quanyang Wang <quanyang.wang at windriver.com>
> 
> The round_rate callback should only perform rate calculation and not
> involve calling zynqmp_pll_set_mode to change the pll mode. So let's
> move zynqmp_pll_set_mode out of round_rate and to set_rate callback.
> 
> Reported-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
> ---

Any Fixes tag?


From sboyd at kernel.org  Thu Apr  1 02:49:09 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 31 Mar 2021 18:49:09 -0700
Subject: [V2] [PATCH] clk: zynqmp: pll: add set_pll_mode to check
 condition in zynqmp_pll_enable
In-Reply-To: <20210330121701.3258948-1-quanyang.wang@windriver.com>
References: <20210330121701.3258948-1-quanyang.wang@windriver.com>
Message-ID: <161724174987.2260335.3629133210221429059@swboyd.mtv.corp.google.com>

Quoting quanyang.wang at windriver.com (2021-03-30 05:17:01)
> From: Quanyang Wang <quanyang.wang at windriver.com>
> 
> If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever,
> we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this
> pll has been enabled. In ATF implementation, it will only assign
> the mode to the variable (struct pm_pll *)pll->mode when handling
> IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force
> ATF send request to PWU to set the pll mode to PLL's register.
> 
> There is a scenario that happens in enabling VPLL_INT(clk_id:96):
> 1) VPLL_INT has been enabled during booting.
> 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT
>    should be set to FRAC mode. Then zynqmp_pll_set_mode is called
>    to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point
>    ATF just stores the mode to a variable.
> 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is
>    called to try to enable VPLL_INT pll. Because of 1), the function
>    zynqmp_pll_enable just returns without doing anything after checking
>    that this pll has been enabled.
> 
> In the scenario above, the pll mode of VPLL_INT will never be set
> successfully. So adding set_pll_mode to check condition to fix it.
> 
> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
> Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> ---

Any Fixes tag?


From quanyang.wang at windriver.com  Thu Apr  1 03:01:19 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Thu, 1 Apr 2021 10:01:19 +0800
Subject: [PATCH] clk: zynqmp: move zynqmp_pll_set_mode out of round_rate
 callback
In-Reply-To: <161724172079.2260335.16388981768978108196@swboyd.mtv.corp.google.com>
References: <20210331090018.3464094-1-quanyang.wang@windriver.com>
 <161724172079.2260335.16388981768978108196@swboyd.mtv.corp.google.com>
Message-ID: <6bbc7554-625b-ae74-2e42-a324eee633fb@windriver.com>

Hi Stephen,

On 4/1/21 9:48 AM, Stephen Boyd wrote:
> Quoting quanyang.wang at windriver.com (2021-03-31 02:00:18)
>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>
>> The round_rate callback should only perform rate calculation and not
>> involve calling zynqmp_pll_set_mode to change the pll mode. So let's
>> move zynqmp_pll_set_mode out of round_rate and to set_rate callback.
>>
>> Reported-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>> ---
> Any Fixes tag?

Thanks for your reminder. I will add Fixes tag at the V2 version patch.

Thanks,

Quanyang



From quanyang.wang at windriver.com  Thu Apr  1 03:02:02 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Thu, 1 Apr 2021 10:02:02 +0800
Subject: [V2] [PATCH] clk: zynqmp: pll: add set_pll_mode to check
 condition in zynqmp_pll_enable
In-Reply-To: <161724174987.2260335.3629133210221429059@swboyd.mtv.corp.google.com>
References: <20210330121701.3258948-1-quanyang.wang@windriver.com>
 <161724174987.2260335.3629133210221429059@swboyd.mtv.corp.google.com>
Message-ID: <deac32ec-a80b-bca7-2573-4c80fe2bca72@windriver.com>

Hi Stephen,

On 4/1/21 9:49 AM, Stephen Boyd wrote:
> Quoting quanyang.wang at windriver.com (2021-03-30 05:17:01)
>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>
>> If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever,
>> we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this
>> pll has been enabled. In ATF implementation, it will only assign
>> the mode to the variable (struct pm_pll *)pll->mode when handling
>> IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force
>> ATF send request to PWU to set the pll mode to PLL's register.
>>
>> There is a scenario that happens in enabling VPLL_INT(clk_id:96):
>> 1) VPLL_INT has been enabled during booting.
>> 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT
>>     should be set to FRAC mode. Then zynqmp_pll_set_mode is called
>>     to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point
>>     ATF just stores the mode to a variable.
>> 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is
>>     called to try to enable VPLL_INT pll. Because of 1), the function
>>     zynqmp_pll_enable just returns without doing anything after checking
>>     that this pll has been enabled.
>>
>> In the scenario above, the pll mode of VPLL_INT will never be set
>> successfully. So adding set_pll_mode to check condition to fix it.
>>
>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>> Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> ---
> Any Fixes tag?

Will add it at V3 patch.

Thanks,

Quanyang



From boon.leong.ong at intel.com  Thu Apr  1 03:11:11 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:11 +0800
Subject: [PATCH net-next v4 0/6] stmmac: Add XDP support
Message-ID: <20210401021117.13360-1-boon.leong.ong@intel.com>

Hi,

This is the v4 patch series for adding XDP native support to stmmac.

Changes in v4:
5/6: Move TX clean timer setup to the end of NAPI RX process and
     group it under stmmac_finalize_xdp_rx().
     Also, fixed stmmac_xdp_xmit_back() returns STMMAC_XDP_CONSUMED
     if XDP buffer conversion to XDP frame fails.

6/6: Move xdp_do_flush(0 into stmmac_finalize_xdp_rx() and combine
     the XDP verdict of XDP TX and XDP REDIRECT together.

I retested the patch series on the 'xdp2' and 'xdp_redirect' related to
changes above and found the result to be satisfactory.

History of previous patch series:
v3: https://patchwork.kernel.org/project/netdevbpf/cover/20210331154135.8507-1-boon.leong.ong at intel.com/
v2: https://patchwork.kernel.org/project/netdevbpf/list/?series=457757
v1: https://patchwork.kernel.org/project/netdevbpf/list/?series=457139

It will be great if community can help to test or review the v4 series
and provide me any input if any.

Thank you very much,
Boon Leong

Ong Boon Leong (6):
  net: stmmac: set IRQ affinity hint for multi MSI vectors
  net: stmmac: make SPH enable/disable to be configurable
  net: stmmac: arrange Tx tail pointer update to
    stmmac_flush_tx_descriptors
  net: stmmac: Add initial XDP support
  net: stmmac: Add support for XDP_TX action
  net: stmmac: Add support for XDP_REDIRECT action

 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  35 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 539 +++++++++++++++---
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  40 ++
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |  12 +
 5 files changed, 547 insertions(+), 80 deletions(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h

-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:12 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:12 +0800
Subject: [PATCH net-next v4 1/6] net: stmmac: set IRQ affinity hint for multi
 MSI vectors
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-2-boon.leong.ong@intel.com>

Certain platform likes Intel mGBE has independent hardware IRQ resources
for TX and RX DMA operation. In preparation to support XDP TX, we add IRQ
affinity hint to group both RX and TX queue of the same queue ID to the
same CPU.

Changes in v2:
 - IRQ affinity hint need to set to null before IRQ is released.
   Thanks to issue reported by Song, Yoong Siang.

Reported-by: Song, Yoong Siang <yoong.siang.song at intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d34388b1ffcc..9d63e8c365ae 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3005,15 +3005,19 @@ static void stmmac_free_irq(struct net_device *dev,
 		fallthrough;
 	case REQ_IRQ_ERR_TX:
 		for (j = irq_idx - 1; j >= 0; j--) {
-			if (priv->tx_irq[j] > 0)
+			if (priv->tx_irq[j] > 0) {
+				irq_set_affinity_hint(priv->tx_irq[j], NULL);
 				free_irq(priv->tx_irq[j], &priv->tx_queue[j]);
+			}
 		}
 		irq_idx = priv->plat->rx_queues_to_use;
 		fallthrough;
 	case REQ_IRQ_ERR_RX:
 		for (j = irq_idx - 1; j >= 0; j--) {
-			if (priv->rx_irq[j] > 0)
+			if (priv->rx_irq[j] > 0) {
+				irq_set_affinity_hint(priv->rx_irq[j], NULL);
 				free_irq(priv->rx_irq[j], &priv->rx_queue[j]);
+			}
 		}
 
 		if (priv->sfty_ue_irq > 0 && priv->sfty_ue_irq != dev->irq)
@@ -3045,6 +3049,7 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 {
 	enum request_irq_err irq_err = REQ_IRQ_ERR_NO;
 	struct stmmac_priv *priv = netdev_priv(dev);
+	cpumask_t cpu_mask;
 	int irq_idx = 0;
 	char *int_name;
 	int ret;
@@ -3153,6 +3158,9 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 			irq_idx = i;
 			goto irq_error;
 		}
+		cpumask_clear(&cpu_mask);
+		cpumask_set_cpu(i % num_online_cpus(), &cpu_mask);
+		irq_set_affinity_hint(priv->rx_irq[i], &cpu_mask);
 	}
 
 	/* Request Tx MSI irq */
@@ -3173,6 +3181,9 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 			irq_idx = i;
 			goto irq_error;
 		}
+		cpumask_clear(&cpu_mask);
+		cpumask_set_cpu(i % num_online_cpus(), &cpu_mask);
+		irq_set_affinity_hint(priv->tx_irq[i], &cpu_mask);
 	}
 
 	return 0;
-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:13 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:13 +0800
Subject: [PATCH net-next v4 2/6] net: stmmac: make SPH enable/disable to be
 configurable
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-3-boon.leong.ong@intel.com>

SPH functionality splits header and payload according to split mode and
offsef fields (SPLM and SPLOFST). It is beneficials for Linux network
stack RX processing however it adds a lot of complexity in XDP
processing.

So, this patch makes the split-header (SPH) capability of the controller
is stored in "priv->sph_cap" and the enabling/disabling of SPH is decided
by "priv->sph".

This is to prepare initial XDP enabling for stmmac to disable the use of
SPH whenever XDP is enabled.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h      |  1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 +++++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 9966f6f10905..e293423f98c3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -160,6 +160,7 @@ struct stmmac_priv {
 	bool tx_path_in_lpi_mode;
 	bool tso;
 	int sph;
+	int sph_cap;
 	u32 sarc_type;
 
 	unsigned int dma_buf_sz;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9d63e8c365ae..18e34a1e2367 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2858,6 +2858,7 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
 	struct stmmac_priv *priv = netdev_priv(dev);
 	u32 rx_cnt = priv->plat->rx_queues_to_use;
 	u32 tx_cnt = priv->plat->tx_queues_to_use;
+	bool sph_en;
 	u32 chan;
 	int ret;
 
@@ -2952,10 +2953,10 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
 	}
 
 	/* Enable Split Header */
-	if (priv->sph && priv->hw->rx_csum) {
-		for (chan = 0; chan < rx_cnt; chan++)
-			stmmac_enable_sph(priv, priv->ioaddr, 1, chan);
-	}
+	sph_en = (priv->hw->rx_csum > 0) && priv->sph;
+	for (chan = 0; chan < rx_cnt; chan++)
+		stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
+
 
 	/* VLAN Tag Insertion */
 	if (priv->dma_cap.vlins)
@@ -5708,7 +5709,8 @@ int stmmac_dvr_probe(struct device *device,
 
 	if (priv->dma_cap.sphen) {
 		ndev->hw_features |= NETIF_F_GRO;
-		priv->sph = true;
+		priv->sph_cap = true;
+		priv->sph = priv->sph_cap;
 		dev_info(priv->device, "SPH feature enabled\n");
 	}
 
-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:14 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:14 +0800
Subject: [PATCH net-next v4 3/6] net: stmmac: arrange Tx tail pointer update
 to stmmac_flush_tx_descriptors
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-4-boon.leong.ong@intel.com>

This patch organizes TX tail pointer update into a new function called
stmmac_flush_tx_descriptors() so that we can reuse it in stmmac_xmit(),
stmmac_tso_xmit() and up-coming XDP implementation.

Changes to v2:
 - Fix for warning: unused variable ?desc_size?
   https://patchwork.hopto.org/static/nipa/457321/12170149/build_32bit/stderr

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 56 +++++++++----------
 1 file changed, 26 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 18e34a1e2367..cb1b2a180429 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3518,6 +3518,28 @@ static void stmmac_tso_allocator(struct stmmac_priv *priv, dma_addr_t des,
 	}
 }
 
+static void stmmac_flush_tx_descriptors(struct stmmac_priv *priv, int queue)
+{
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	int desc_size;
+
+	if (likely(priv->extend_desc))
+		desc_size = sizeof(struct dma_extended_desc);
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		desc_size = sizeof(struct dma_edesc);
+	else
+		desc_size = sizeof(struct dma_desc);
+
+	/* The own bit must be the latest setting done when prepare the
+	 * descriptor and then barrier is needed to make sure that
+	 * all is coherent before granting the DMA engine.
+	 */
+	wmb();
+
+	tx_q->tx_tail_addr = tx_q->dma_tx_phy + (tx_q->cur_tx * desc_size);
+	stmmac_set_tx_tail_ptr(priv, priv->ioaddr, tx_q->tx_tail_addr, queue);
+}
+
 /**
  *  stmmac_tso_xmit - Tx entry point of the driver for oversized frames (TSO)
  *  @skb : the socket buffer
@@ -3549,10 +3571,10 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct dma_desc *desc, *first, *mss_desc = NULL;
 	struct stmmac_priv *priv = netdev_priv(dev);
-	int desc_size, tmp_pay_len = 0, first_tx;
 	int nfrags = skb_shinfo(skb)->nr_frags;
 	u32 queue = skb_get_queue_mapping(skb);
 	unsigned int first_entry, tx_packets;
+	int tmp_pay_len = 0, first_tx;
 	struct stmmac_tx_queue *tx_q;
 	bool has_vlan, set_ic;
 	u8 proto_hdr_len, hdr;
@@ -3750,12 +3772,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
 		stmmac_set_tx_owner(priv, mss_desc);
 	}
 
-	/* The own bit must be the latest setting done when prepare the
-	 * descriptor and then barrier is needed to make sure that
-	 * all is coherent before granting the DMA engine.
-	 */
-	wmb();
-
 	if (netif_msg_pktdata(priv)) {
 		pr_info("%s: curr=%d dirty=%d f=%d, e=%d, f_p=%p, nfrags %d\n",
 			__func__, tx_q->cur_tx, tx_q->dirty_tx, first_entry,
@@ -3766,13 +3782,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);
 
-	if (tx_q->tbs & STMMAC_TBS_AVAIL)
-		desc_size = sizeof(struct dma_edesc);
-	else
-		desc_size = sizeof(struct dma_desc);
-
-	tx_q->tx_tail_addr = tx_q->dma_tx_phy + (tx_q->cur_tx * desc_size);
-	stmmac_set_tx_tail_ptr(priv, priv->ioaddr, tx_q->tx_tail_addr, queue);
+	stmmac_flush_tx_descriptors(priv, queue);
 	stmmac_tx_timer_arm(priv, queue);
 
 	return NETDEV_TX_OK;
@@ -3802,10 +3812,10 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 	int nfrags = skb_shinfo(skb)->nr_frags;
 	int gso = skb_shinfo(skb)->gso_type;
 	struct dma_edesc *tbs_desc = NULL;
-	int entry, desc_size, first_tx;
 	struct dma_desc *desc, *first;
 	struct stmmac_tx_queue *tx_q;
 	bool has_vlan, set_ic;
+	int entry, first_tx;
 	dma_addr_t des;
 
 	tx_q = &priv->tx_queue[queue];
@@ -4007,25 +4017,11 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	stmmac_set_tx_owner(priv, first);
 
-	/* The own bit must be the latest setting done when prepare the
-	 * descriptor and then barrier is needed to make sure that
-	 * all is coherent before granting the DMA engine.
-	 */
-	wmb();
-
 	netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);
 
 	stmmac_enable_dma_transmission(priv, priv->ioaddr);
 
-	if (likely(priv->extend_desc))
-		desc_size = sizeof(struct dma_extended_desc);
-	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-		desc_size = sizeof(struct dma_edesc);
-	else
-		desc_size = sizeof(struct dma_desc);
-
-	tx_q->tx_tail_addr = tx_q->dma_tx_phy + (tx_q->cur_tx * desc_size);
-	stmmac_set_tx_tail_ptr(priv, priv->ioaddr, tx_q->tx_tail_addr, queue);
+	stmmac_flush_tx_descriptors(priv, queue);
 	stmmac_tx_timer_arm(priv, queue);
 
 	return NETDEV_TX_OK;
-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:15 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:15 +0800
Subject: [PATCH net-next v4 4/6] net: stmmac: Add initial XDP support
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-5-boon.leong.ong@intel.com>

This patch adds the initial XDP support to stmmac driver. It supports
XDP_PASS, XDP_DROP and XDP_ABORTED actions. Upcoming patches will add
support for XDP_TX and XDP_REDIRECT.

To support XDP headroom, this patch adds page_offset into RX buffer and
change the dma_sync_single_for_device|cpu(). The DMA address used for
RX operation are changed to take into page_offset too. As page_pool
can handle dma_sync_single_for_device() on behalf of driver with
PP_FLAG_DMA_SYNC_DEV flag, we skip doing that in stmmac driver.

Current stmmac driver supports split header support (SPH) in RX but
the flexibility of splitting header and payload at different position
makes it very complex to be supported for XDP processing. In addition,
jumbo frame is not supported in XDP to keep the initial codes simple.

This patch has been tested with the sample app "xdp1" located in
samples/bpf directory for both SKB and Native (XDP) mode. The burst
traffic generated using pktgen_sample03_burst_single_flow.sh in
samples/pktgen directory.

Changes in v3:
 - factor in xdp header and tail adjustment done by XDP program.
   Thanks to Jakub Kicinski for pointing out the gap in v2.

Changes in v2:
 - fix for "warning: variable 'len' set but not used" reported by lkp.

Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  21 ++-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 150 +++++++++++++++---
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  40 +++++
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |  12 ++
 5 files changed, 197 insertions(+), 27 deletions(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 366740ab9c5a..f2e478b884b0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,6 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o	\
 	      mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o	\
 	      dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \
 	      stmmac_tc.o dwxgmac2_core.o dwxgmac2_dma.o dwxgmac2_descs.o \
+	      stmmac_xdp.o \
 	      $(stmmac-y)
 
 stmmac-$(CONFIG_STMMAC_SELFTESTS) += stmmac_selftests.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index e293423f98c3..e72224c8fbac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -68,8 +68,9 @@ struct stmmac_tx_queue {
 
 struct stmmac_rx_buffer {
 	struct page *page;
-	struct page *sec_page;
 	dma_addr_t addr;
+	__u32 page_offset;
+	struct page *sec_page;
 	dma_addr_t sec_addr;
 };
 
@@ -269,6 +270,9 @@ struct stmmac_priv {
 
 	/* Receive Side Scaling */
 	struct stmmac_rss rss;
+
+	/* XDP BPF Program */
+	struct bpf_prog *xdp_prog;
 };
 
 enum stmmac_state {
@@ -285,6 +289,8 @@ void stmmac_set_ethtool_ops(struct net_device *netdev);
 
 void stmmac_ptp_register(struct stmmac_priv *priv);
 void stmmac_ptp_unregister(struct stmmac_priv *priv);
+int stmmac_open(struct net_device *dev);
+int stmmac_release(struct net_device *dev);
 int stmmac_resume(struct device *dev);
 int stmmac_suspend(struct device *dev);
 int stmmac_dvr_remove(struct device *dev);
@@ -298,6 +304,19 @@ int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size);
 int stmmac_bus_clks_config(struct stmmac_priv *priv, bool enabled);
 void stmmac_fpe_handshake(struct stmmac_priv *priv, bool enable);
 
+static inline bool stmmac_xdp_is_enabled(struct stmmac_priv *priv)
+{
+	return !!priv->xdp_prog;
+}
+
+static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
+{
+	if (stmmac_xdp_is_enabled(priv))
+		return XDP_PACKET_HEADROOM;
+
+	return 0;
+}
+
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
 void stmmac_selftest_run(struct net_device *dev,
 			 struct ethtool_test *etest, u64 *buf);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index cb1b2a180429..0dad8ab93eb5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -38,9 +38,11 @@
 #include <linux/net_tstamp.h>
 #include <linux/phylink.h>
 #include <linux/udp.h>
+#include <linux/bpf_trace.h>
 #include <net/pkt_cls.h>
 #include "stmmac_ptp.h"
 #include "stmmac.h"
+#include "stmmac_xdp.h"
 #include <linux/reset.h>
 #include <linux/of_mdio.h>
 #include "dwmac1000.h"
@@ -67,6 +69,9 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_TX_THRESH(x)	((x)->dma_tx_size / 4)
 #define STMMAC_RX_THRESH(x)	((x)->dma_rx_size / 4)
 
+#define STMMAC_XDP_PASS		0
+#define STMMAC_XDP_CONSUMED	BIT(0)
+
 static int flow_ctrl = FLOW_AUTO;
 module_param(flow_ctrl, int, 0644);
 MODULE_PARM_DESC(flow_ctrl, "Flow control ability [on/off]");
@@ -1384,6 +1389,7 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv, struct dma_desc *p,
 	buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
 	if (!buf->page)
 		return -ENOMEM;
+	buf->page_offset = stmmac_rx_offset(priv);
 
 	if (priv->sph) {
 		buf->sec_page = page_pool_dev_alloc_pages(rx_q->page_pool);
@@ -1397,7 +1403,8 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv, struct dma_desc *p,
 		stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, false);
 	}
 
-	buf->addr = page_pool_get_dma_addr(buf->page);
+	buf->addr = page_pool_get_dma_addr(buf->page) + buf->page_offset;
+
 	stmmac_set_desc_addr(priv, p, buf->addr);
 	if (priv->dma_buf_sz == BUF_SIZE_16KiB)
 		stmmac_init_desc3(priv, p);
@@ -1503,7 +1510,8 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 				if (!buf->page)
 					goto err_reinit_rx_buffers;
 
-				buf->addr = page_pool_get_dma_addr(buf->page);
+				buf->addr = page_pool_get_dma_addr(buf->page) +
+					    buf->page_offset;
 			}
 
 			if (priv->sph && !buf->sec_page) {
@@ -1821,6 +1829,7 @@ static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
  */
 static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 {
+	bool xdp_prog = stmmac_xdp_is_enabled(priv);
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	int ret = -ENOMEM;
 	u32 queue;
@@ -1834,13 +1843,15 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 		rx_q->queue_index = queue;
 		rx_q->priv_data = priv;
 
-		pp_params.flags = PP_FLAG_DMA_MAP;
+		pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV;
 		pp_params.pool_size = priv->dma_rx_size;
 		num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
 		pp_params.order = ilog2(num_pages);
 		pp_params.nid = dev_to_node(priv->device);
 		pp_params.dev = priv->device;
-		pp_params.dma_dir = DMA_FROM_DEVICE;
+		pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
+		pp_params.offset = stmmac_rx_offset(priv);
+		pp_params.max_len = STMMAC_MAX_RX_BUF_SIZE(num_pages);
 
 		rx_q->page_pool = page_pool_create(&pp_params);
 		if (IS_ERR(rx_q->page_pool)) {
@@ -3268,7 +3279,7 @@ static int stmmac_request_irq(struct net_device *dev)
  *  0 on success and an appropriate (-)ve integer as defined in errno.h
  *  file on failure.
  */
-static int stmmac_open(struct net_device *dev)
+int stmmac_open(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	int bfsize = 0;
@@ -3391,7 +3402,7 @@ static void stmmac_fpe_stop_wq(struct stmmac_priv *priv)
  *  Description:
  *  This is the stop entry point of the driver.
  */
-static int stmmac_release(struct net_device *dev)
+int stmmac_release(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	u32 chan;
@@ -4064,11 +4075,9 @@ static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
 static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
 {
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-	int len, dirty = stmmac_rx_dirty(priv, queue);
+	int dirty = stmmac_rx_dirty(priv, queue);
 	unsigned int entry = rx_q->dirty_rx;
 
-	len = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE) * PAGE_SIZE;
-
 	while (dirty-- > 0) {
 		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[entry];
 		struct dma_desc *p;
@@ -4091,18 +4100,9 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
 				break;
 
 			buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
-
-			dma_sync_single_for_device(priv->device, buf->sec_addr,
-						   len, DMA_FROM_DEVICE);
 		}
 
-		buf->addr = page_pool_get_dma_addr(buf->page);
-
-		/* Sync whole allocation to device. This will invalidate old
-		 * data.
-		 */
-		dma_sync_single_for_device(priv->device, buf->addr, len,
-					   DMA_FROM_DEVICE);
+		buf->addr = page_pool_get_dma_addr(buf->page) + buf->page_offset;
 
 		stmmac_set_desc_addr(priv, p, buf->addr);
 		if (priv->sph)
@@ -4181,6 +4181,42 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
 	return plen - len;
 }
 
+static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
+					   struct xdp_buff *xdp)
+{
+	struct bpf_prog *prog;
+	int res;
+	u32 act;
+
+	rcu_read_lock();
+
+	prog = READ_ONCE(priv->xdp_prog);
+	if (!prog) {
+		res = STMMAC_XDP_PASS;
+		goto unlock;
+	}
+
+	act = bpf_prog_run_xdp(prog, xdp);
+	switch (act) {
+	case XDP_PASS:
+		res = STMMAC_XDP_PASS;
+		break;
+	default:
+		bpf_warn_invalid_xdp_action(act);
+		fallthrough;
+	case XDP_ABORTED:
+		trace_xdp_exception(priv->dev, prog, act);
+		fallthrough;
+	case XDP_DROP:
+		res = STMMAC_XDP_CONSUMED;
+		break;
+	}
+
+unlock:
+	rcu_read_unlock();
+	return ERR_PTR(-res);
+}
+
 /**
  * stmmac_rx - manage the receive process
  * @priv: driver private structure
@@ -4196,8 +4232,14 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 	unsigned int count = 0, error = 0, len = 0;
 	int status = 0, coe = priv->hw->rx_csum;
 	unsigned int next_entry = rx_q->cur_rx;
+	enum dma_data_direction dma_dir;
 	unsigned int desc_size;
 	struct sk_buff *skb = NULL;
+	struct xdp_buff xdp;
+	int buf_sz;
+
+	dma_dir = page_pool_get_dma_dir(rx_q->page_pool);
+	buf_sz = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE) * PAGE_SIZE;
 
 	if (netif_msg_rx_status(priv)) {
 		void *rx_head;
@@ -4315,6 +4357,45 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 		}
 
 		if (!skb) {
+			dma_sync_single_for_cpu(priv->device, buf->addr,
+						buf1_len, dma_dir);
+
+			xdp.data = page_address(buf->page) + buf->page_offset;
+			xdp.data_end = xdp.data + buf1_len;
+			xdp.data_hard_start = page_address(buf->page);
+			xdp_set_data_meta_invalid(&xdp);
+			xdp.frame_sz = buf_sz;
+
+			skb = stmmac_xdp_run_prog(priv, &xdp);
+
+			/* For Not XDP_PASS verdict */
+			if (IS_ERR(skb)) {
+				unsigned int xdp_res = -PTR_ERR(skb);
+
+				if (xdp_res & STMMAC_XDP_CONSUMED) {
+					page_pool_recycle_direct(rx_q->page_pool,
+								 buf->page);
+					buf->page = NULL;
+					priv->dev->stats.rx_dropped++;
+
+					/* Clear skb as it was set as
+					 * status by XDP program.
+					 */
+					skb = NULL;
+
+					if (unlikely((status & rx_not_ls)))
+						goto read_again;
+
+					count++;
+					continue;
+				}
+			}
+		}
+
+		if (!skb) {
+			/* XDP program may expand or reduce tail */
+			buf1_len = xdp.data_end - xdp.data;
+
 			skb = napi_alloc_skb(&ch->rx_napi, buf1_len);
 			if (!skb) {
 				priv->dev->stats.rx_dropped++;
@@ -4322,10 +4403,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 				goto drain_data;
 			}
 
-			dma_sync_single_for_cpu(priv->device, buf->addr,
-						buf1_len, DMA_FROM_DEVICE);
-			skb_copy_to_linear_data(skb, page_address(buf->page),
-						buf1_len);
+			/* XDP program may adjust header */
+			skb_copy_to_linear_data(skb, xdp.data, buf1_len);
 			skb_put(skb, buf1_len);
 
 			/* Data payload copied into SKB, page ready for recycle */
@@ -4333,9 +4412,9 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 			buf->page = NULL;
 		} else if (buf1_len) {
 			dma_sync_single_for_cpu(priv->device, buf->addr,
-						buf1_len, DMA_FROM_DEVICE);
+						buf1_len, dma_dir);
 			skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
-					buf->page, 0, buf1_len,
+					buf->page, buf->page_offset, buf1_len,
 					priv->dma_buf_sz);
 
 			/* Data payload appended into SKB */
@@ -4345,7 +4424,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 
 		if (buf2_len) {
 			dma_sync_single_for_cpu(priv->device, buf->sec_addr,
-						buf2_len, DMA_FROM_DEVICE);
+						buf2_len, dma_dir);
 			skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
 					buf->sec_page, 0, buf2_len,
 					priv->dma_buf_sz);
@@ -4503,6 +4582,11 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
 		return -EBUSY;
 	}
 
+	if (stmmac_xdp_is_enabled(priv) && new_mtu > ETH_DATA_LEN) {
+		netdev_dbg(priv->dev, "Jumbo frames not supported for XDP\n");
+		return -EINVAL;
+	}
+
 	new_mtu = STMMAC_ALIGN(new_mtu);
 
 	/* If condition true, FIFO is too small or MTU too large */
@@ -4564,6 +4648,7 @@ static int stmmac_set_features(struct net_device *netdev,
 	stmmac_rx_ipc(priv, priv->hw);
 
 	sph_en = (priv->hw->rx_csum > 0) && priv->sph;
+
 	for (chan = 0; chan < priv->plat->rx_queues_to_use; chan++)
 		stmmac_enable_sph(priv, priv->ioaddr, sph_en, chan);
 
@@ -5299,6 +5384,18 @@ static int stmmac_vlan_rx_kill_vid(struct net_device *ndev, __be16 proto, u16 vi
 	return ret;
 }
 
+static int stmmac_bpf(struct net_device *dev, struct netdev_bpf *bpf)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+
+	switch (bpf->command) {
+	case XDP_SETUP_PROG:
+		return stmmac_xdp_set_prog(priv, bpf->prog, bpf->extack);
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
 static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_open = stmmac_open,
 	.ndo_start_xmit = stmmac_xmit,
@@ -5317,6 +5414,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_set_mac_address = stmmac_set_mac_address,
 	.ndo_vlan_rx_add_vid = stmmac_vlan_rx_add_vid,
 	.ndo_vlan_rx_kill_vid = stmmac_vlan_rx_kill_vid,
+	.ndo_bpf = stmmac_bpf,
 };
 
 static void stmmac_reset_subtask(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
new file mode 100644
index 000000000000..bf38d231860b
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2021, Intel Corporation. */
+
+#include "stmmac.h"
+#include "stmmac_xdp.h"
+
+int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
+			struct netlink_ext_ack *extack)
+{
+	struct net_device *dev = priv->dev;
+	struct bpf_prog *old_prog;
+	bool need_update;
+	bool if_running;
+
+	if_running = netif_running(dev);
+
+	if (prog && dev->mtu > ETH_DATA_LEN) {
+		/* For now, the driver doesn't support XDP functionality with
+		 * jumbo frames so we return error.
+		 */
+		NL_SET_ERR_MSG_MOD(extack, "Jumbo frames not supported");
+		return -EOPNOTSUPP;
+	}
+
+	need_update = !!priv->xdp_prog != !!prog;
+	if (if_running && need_update)
+		stmmac_release(dev);
+
+	old_prog = xchg(&priv->xdp_prog, prog);
+	if (old_prog)
+		bpf_prog_put(old_prog);
+
+	/* Disable RX SPH for XDP operation */
+	priv->sph = priv->sph_cap && !stmmac_xdp_is_enabled(priv);
+
+	if (if_running && need_update)
+		stmmac_open(dev);
+
+	return 0;
+}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
new file mode 100644
index 000000000000..93948569d92a
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2021, Intel Corporation. */
+
+#ifndef _STMMAC_XDP_H_
+#define _STMMAC_XDP_H_
+
+#define STMMAC_MAX_RX_BUF_SIZE(num)	(((num) * PAGE_SIZE) - XDP_PACKET_HEADROOM)
+
+int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
+			struct netlink_ext_ack *extack);
+
+#endif /* _STMMAC_XDP_H_ */
-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:16 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:16 +0800
Subject: [PATCH net-next v4 5/6] net: stmmac: Add support for XDP_TX action
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-6-boon.leong.ong@intel.com>

This patch adds support for XDP_TX action which enables XDP program to
transmit back received frames.

This patch has been tested with the "xdp2" app located in samples/bpf
dir. The DUT receives burst traffic packet generated using pktgen script
'pktgen_sample03_burst_single_flow.sh'.

v4: Moved stmmac_tx_timer_arm() to be done once at the end of NAPI RX.
    Fixed stmmac_xdp_xmit_back() to return STMMAC_XDP_CONSUMED if
    XDP buffer to frame conversion fails. Thanks to Jakub's input.

v3: Added 'nq->trans_start = jiffies' to avoid TX time-out as we are
    sharing TX queue between slow path and XDP. Thanks to Jakub Kicinski
    for pointing out.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  12 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 238 ++++++++++++++++--
 2 files changed, 232 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index e72224c8fbac..a93e22a6be59 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -36,12 +36,18 @@ struct stmmac_resources {
 	int tx_irq[MTL_MAX_TX_QUEUES];
 };
 
+enum stmmac_txbuf_type {
+	STMMAC_TXBUF_T_SKB,
+	STMMAC_TXBUF_T_XDP_TX,
+};
+
 struct stmmac_tx_info {
 	dma_addr_t buf;
 	bool map_as_page;
 	unsigned len;
 	bool last_segment;
 	bool is_jumbo;
+	enum stmmac_txbuf_type buf_type;
 };
 
 #define STMMAC_TBS_AVAIL	BIT(0)
@@ -57,7 +63,10 @@ struct stmmac_tx_queue {
 	struct dma_extended_desc *dma_etx ____cacheline_aligned_in_smp;
 	struct dma_edesc *dma_entx;
 	struct dma_desc *dma_tx;
-	struct sk_buff **tx_skbuff;
+	union {
+		struct sk_buff **tx_skbuff;
+		struct xdp_frame **xdpf;
+	};
 	struct stmmac_tx_info *tx_skbuff_dma;
 	unsigned int cur_tx;
 	unsigned int dirty_tx;
@@ -77,6 +86,7 @@ struct stmmac_rx_buffer {
 struct stmmac_rx_queue {
 	u32 rx_count_frames;
 	u32 queue_index;
+	struct xdp_rxq_info xdp_rxq;
 	struct page_pool *page_pool;
 	struct stmmac_rx_buffer *buf_pool;
 	struct stmmac_priv *priv_data;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0dad8ab93eb5..65163b51f8ad 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -71,6 +71,7 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 
 #define STMMAC_XDP_PASS		0
 #define STMMAC_XDP_CONSUMED	BIT(0)
+#define STMMAC_XDP_TX		BIT(1)
 
 static int flow_ctrl = FLOW_AUTO;
 module_param(flow_ctrl, int, 0644);
@@ -1442,7 +1443,8 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 {
 	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 
-	if (tx_q->tx_skbuff_dma[i].buf) {
+	if (tx_q->tx_skbuff_dma[i].buf &&
+	    tx_q->tx_skbuff_dma[i].buf_type != STMMAC_TXBUF_T_XDP_TX) {
 		if (tx_q->tx_skbuff_dma[i].map_as_page)
 			dma_unmap_page(priv->device,
 				       tx_q->tx_skbuff_dma[i].buf,
@@ -1455,12 +1457,20 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 					 DMA_TO_DEVICE);
 	}
 
-	if (tx_q->tx_skbuff[i]) {
+	if (tx_q->xdpf[i] &&
+	    tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XDP_TX) {
+		xdp_return_frame(tx_q->xdpf[i]);
+		tx_q->xdpf[i] = NULL;
+	}
+
+	if (tx_q->tx_skbuff[i] &&
+	    tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_SKB) {
 		dev_kfree_skb_any(tx_q->tx_skbuff[i]);
 		tx_q->tx_skbuff[i] = NULL;
-		tx_q->tx_skbuff_dma[i].buf = 0;
-		tx_q->tx_skbuff_dma[i].map_as_page = false;
 	}
+
+	tx_q->tx_skbuff_dma[i].buf = 0;
+	tx_q->tx_skbuff_dma[i].map_as_page = false;
 }
 
 /**
@@ -1568,6 +1578,7 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+		int ret;
 
 		netif_dbg(priv, probe, priv->dev,
 			  "(%s) dma_rx_phy=0x%08x\n", __func__,
@@ -1575,6 +1586,14 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 		stmmac_clear_rx_descriptors(priv, queue);
 
+		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+						   MEM_TYPE_PAGE_POOL,
+						   rx_q->page_pool));
+
+		netdev_info(priv->dev,
+			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
+			    rx_q->queue_index);
+
 		for (i = 0; i < priv->dma_rx_size; i++) {
 			struct dma_desc *p;
 
@@ -1775,6 +1794,9 @@ static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
 					  sizeof(struct dma_extended_desc),
 					  rx_q->dma_erx, rx_q->dma_rx_phy);
 
+		if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
+			xdp_rxq_info_unreg(&rx_q->xdp_rxq);
+
 		kfree(rx_q->buf_pool);
 		if (rx_q->page_pool)
 			page_pool_destroy(rx_q->page_pool);
@@ -1837,8 +1859,10 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 	/* RX queues buffers and DMA */
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+		struct stmmac_channel *ch = &priv->channel[queue];
 		struct page_pool_params pp_params = { 0 };
 		unsigned int num_pages;
+		int ret;
 
 		rx_q->queue_index = queue;
 		rx_q->priv_data = priv;
@@ -1884,6 +1908,14 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 			if (!rx_q->dma_rx)
 				goto err_dma;
 		}
+
+		ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
+				       rx_q->queue_index,
+				       ch->rx_napi.napi_id);
+		if (ret) {
+			netdev_err(priv->dev, "Failed to register xdp rxq info\n");
+			goto err_dma;
+		}
 	}
 
 	return 0;
@@ -1985,11 +2017,13 @@ static int alloc_dma_desc_resources(struct stmmac_priv *priv)
  */
 static void free_dma_desc_resources(struct stmmac_priv *priv)
 {
-	/* Release the DMA RX socket buffers */
-	free_dma_rx_desc_resources(priv);
-
 	/* Release the DMA TX socket buffers */
 	free_dma_tx_desc_resources(priv);
+
+	/* Release the DMA RX socket buffers later
+	 * to ensure all pending XDP_TX buffers are returned.
+	 */
+	free_dma_rx_desc_resources(priv);
 }
 
 /**
@@ -2181,10 +2215,22 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 
 	entry = tx_q->dirty_tx;
 	while ((entry != tx_q->cur_tx) && (count < budget)) {
-		struct sk_buff *skb = tx_q->tx_skbuff[entry];
+		struct xdp_frame *xdpf;
+		struct sk_buff *skb;
 		struct dma_desc *p;
 		int status;
 
+		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_TX) {
+			xdpf = tx_q->xdpf[entry];
+			skb = NULL;
+		} else if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
+			xdpf = NULL;
+			skb = tx_q->tx_skbuff[entry];
+		} else {
+			xdpf = NULL;
+			skb = NULL;
+		}
+
 		if (priv->extend_desc)
 			p = (struct dma_desc *)(tx_q->dma_etx + entry);
 		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
@@ -2214,10 +2260,12 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 				priv->dev->stats.tx_packets++;
 				priv->xstats.tx_pkt_n++;
 			}
-			stmmac_get_tx_hwtstamp(priv, p, skb);
+			if (skb)
+				stmmac_get_tx_hwtstamp(priv, p, skb);
 		}
 
-		if (likely(tx_q->tx_skbuff_dma[entry].buf)) {
+		if (likely(tx_q->tx_skbuff_dma[entry].buf &&
+			   tx_q->tx_skbuff_dma[entry].buf_type != STMMAC_TXBUF_T_XDP_TX)) {
 			if (tx_q->tx_skbuff_dma[entry].map_as_page)
 				dma_unmap_page(priv->device,
 					       tx_q->tx_skbuff_dma[entry].buf,
@@ -2238,11 +2286,19 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 		tx_q->tx_skbuff_dma[entry].last_segment = false;
 		tx_q->tx_skbuff_dma[entry].is_jumbo = false;
 
-		if (likely(skb != NULL)) {
-			pkts_compl++;
-			bytes_compl += skb->len;
-			dev_consume_skb_any(skb);
-			tx_q->tx_skbuff[entry] = NULL;
+		if (xdpf &&
+		    tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_TX) {
+			xdp_return_frame_rx_napi(xdpf);
+			tx_q->xdpf[entry] = NULL;
+		}
+
+		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
+			if (likely(skb)) {
+				pkts_compl++;
+				bytes_compl += skb->len;
+				dev_consume_skb_any(skb);
+				tx_q->tx_skbuff[entry] = NULL;
+			}
 		}
 
 		stmmac_release_tx_desc(priv, p, priv->mode);
@@ -3667,6 +3723,8 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	tx_q->tx_skbuff_dma[first_entry].buf = des;
 	tx_q->tx_skbuff_dma[first_entry].len = skb_headlen(skb);
+	tx_q->tx_skbuff_dma[first_entry].map_as_page = false;
+	tx_q->tx_skbuff_dma[first_entry].buf_type = STMMAC_TXBUF_T_SKB;
 
 	if (priv->dma_cap.addr64 <= 32) {
 		first->des0 = cpu_to_le32(des);
@@ -3702,12 +3760,14 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
 		tx_q->tx_skbuff_dma[tx_q->cur_tx].buf = des;
 		tx_q->tx_skbuff_dma[tx_q->cur_tx].len = skb_frag_size(frag);
 		tx_q->tx_skbuff_dma[tx_q->cur_tx].map_as_page = true;
+		tx_q->tx_skbuff_dma[tx_q->cur_tx].buf_type = STMMAC_TXBUF_T_SKB;
 	}
 
 	tx_q->tx_skbuff_dma[tx_q->cur_tx].last_segment = true;
 
 	/* Only the last descriptor gets to point to the skb. */
 	tx_q->tx_skbuff[tx_q->cur_tx] = skb;
+	tx_q->tx_skbuff_dma[tx_q->cur_tx].buf_type = STMMAC_TXBUF_T_SKB;
 
 	/* Manage tx mitigation */
 	tx_packets = (tx_q->cur_tx + 1) - first_tx;
@@ -3914,6 +3974,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 		tx_q->tx_skbuff_dma[entry].map_as_page = true;
 		tx_q->tx_skbuff_dma[entry].len = len;
 		tx_q->tx_skbuff_dma[entry].last_segment = last_segment;
+		tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_SKB;
 
 		/* Prepare the descriptor and set the own bit too */
 		stmmac_prepare_tx_desc(priv, desc, 0, len, csum_insertion,
@@ -3922,6 +3983,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Only the last descriptor gets to point to the skb. */
 	tx_q->tx_skbuff[entry] = skb;
+	tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_SKB;
 
 	/* According to the coalesce parameter the IC bit for the latest
 	 * segment is reset and the timer re-started to clean the tx status.
@@ -4000,6 +4062,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 			goto dma_map_err;
 
 		tx_q->tx_skbuff_dma[first_entry].buf = des;
+		tx_q->tx_skbuff_dma[first_entry].buf_type = STMMAC_TXBUF_T_SKB;
+		tx_q->tx_skbuff_dma[first_entry].map_as_page = false;
 
 		stmmac_set_desc_addr(priv, first, des);
 
@@ -4181,6 +4245,110 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
 	return plen - len;
 }
 
+static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
+				struct xdp_frame *xdpf)
+{
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	struct page *page = virt_to_page(xdpf->data);
+	unsigned int entry = tx_q->cur_tx;
+	struct dma_desc *tx_desc;
+	dma_addr_t dma_addr;
+	bool set_ic;
+
+	if (stmmac_tx_avail(priv, queue) < STMMAC_TX_THRESH(priv))
+		return STMMAC_XDP_CONSUMED;
+
+	if (likely(priv->extend_desc))
+		tx_desc = (struct dma_desc *)(tx_q->dma_etx + entry);
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		tx_desc = &tx_q->dma_entx[entry].basic;
+	else
+		tx_desc = tx_q->dma_tx + entry;
+
+	dma_addr = page_pool_get_dma_addr(page) + sizeof(*xdpf) +
+		   xdpf->headroom;
+	dma_sync_single_for_device(priv->device, dma_addr,
+				   xdpf->len, DMA_BIDIRECTIONAL);
+
+	tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XDP_TX;
+
+	tx_q->tx_skbuff_dma[entry].buf = dma_addr;
+	tx_q->tx_skbuff_dma[entry].map_as_page = false;
+	tx_q->tx_skbuff_dma[entry].len = xdpf->len;
+	tx_q->tx_skbuff_dma[entry].last_segment = true;
+	tx_q->tx_skbuff_dma[entry].is_jumbo = false;
+
+	tx_q->xdpf[entry] = xdpf;
+
+	stmmac_set_desc_addr(priv, tx_desc, dma_addr);
+
+	stmmac_prepare_tx_desc(priv, tx_desc, 1, xdpf->len,
+			       true, priv->mode, true, true,
+			       xdpf->len);
+
+	tx_q->tx_count_frames++;
+
+	if (tx_q->tx_count_frames % priv->tx_coal_frames[queue] == 0)
+		set_ic = true;
+	else
+		set_ic = false;
+
+	if (set_ic) {
+		tx_q->tx_count_frames = 0;
+		stmmac_set_tx_ic(priv, tx_desc);
+		priv->xstats.tx_set_ic_bit++;
+	}
+
+	stmmac_enable_dma_transmission(priv, priv->ioaddr);
+
+	entry = STMMAC_GET_ENTRY(entry, priv->dma_tx_size);
+	tx_q->cur_tx = entry;
+
+	return STMMAC_XDP_TX;
+}
+
+static int stmmac_xdp_get_tx_queue(struct stmmac_priv *priv,
+				   int cpu)
+{
+	int index = cpu;
+
+	if (unlikely(index < 0))
+		index = 0;
+
+	while (index >= priv->plat->tx_queues_to_use)
+		index -= priv->plat->tx_queues_to_use;
+
+	return index;
+}
+
+static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
+				struct xdp_buff *xdp)
+{
+	struct xdp_frame *xdpf = xdp_convert_buff_to_frame(xdp);
+	int cpu = smp_processor_id();
+	struct netdev_queue *nq;
+	int queue;
+	int res;
+
+	if (unlikely(!xdpf))
+		return STMMAC_XDP_CONSUMED;
+
+	queue = stmmac_xdp_get_tx_queue(priv, cpu);
+	nq = netdev_get_tx_queue(priv->dev, queue);
+
+	__netif_tx_lock(nq, cpu);
+	/* Avoids TX time-out as we are sharing with slow path */
+	nq->trans_start = jiffies;
+
+	res = stmmac_xdp_xmit_xdpf(priv, queue, xdpf);
+	if (res == STMMAC_XDP_TX)
+		stmmac_flush_tx_descriptors(priv, queue);
+
+	__netif_tx_unlock(nq);
+
+	return res;
+}
+
 static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 					   struct xdp_buff *xdp)
 {
@@ -4201,6 +4369,9 @@ static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 	case XDP_PASS:
 		res = STMMAC_XDP_PASS;
 		break;
+	case XDP_TX:
+		res = stmmac_xdp_xmit_back(priv, xdp);
+		break;
 	default:
 		bpf_warn_invalid_xdp_action(act);
 		fallthrough;
@@ -4217,6 +4388,18 @@ static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 	return ERR_PTR(-res);
 }
 
+static void stmmac_finalize_xdp_rx(struct stmmac_priv *priv,
+				   int xdp_status)
+{
+	int cpu = smp_processor_id();
+	int queue;
+
+	queue = stmmac_xdp_get_tx_queue(priv, cpu);
+
+	if (xdp_status & STMMAC_XDP_TX)
+		stmmac_tx_timer_arm(priv, queue);
+}
+
 /**
  * stmmac_rx - manage the receive process
  * @priv: driver private structure
@@ -4236,6 +4419,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 	unsigned int desc_size;
 	struct sk_buff *skb = NULL;
 	struct xdp_buff xdp;
+	int xdp_status = 0;
 	int buf_sz;
 
 	dma_dir = page_pool_get_dma_dir(rx_q->page_pool);
@@ -4357,6 +4541,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 		}
 
 		if (!skb) {
+			unsigned int pre_len, sync_len;
+
 			dma_sync_single_for_cpu(priv->device, buf->addr,
 						buf1_len, dma_dir);
 
@@ -4365,16 +4551,26 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 			xdp.data_hard_start = page_address(buf->page);
 			xdp_set_data_meta_invalid(&xdp);
 			xdp.frame_sz = buf_sz;
+			xdp.rxq = &rx_q->xdp_rxq;
 
+			pre_len = xdp.data_end - xdp.data_hard_start -
+				  buf->page_offset;
 			skb = stmmac_xdp_run_prog(priv, &xdp);
+			/* Due xdp_adjust_tail: DMA sync for_device
+			 * cover max len CPU touch
+			 */
+			sync_len = xdp.data_end - xdp.data_hard_start -
+				   buf->page_offset;
+			sync_len = max(sync_len, pre_len);
 
 			/* For Not XDP_PASS verdict */
 			if (IS_ERR(skb)) {
 				unsigned int xdp_res = -PTR_ERR(skb);
 
 				if (xdp_res & STMMAC_XDP_CONSUMED) {
-					page_pool_recycle_direct(rx_q->page_pool,
-								 buf->page);
+					page_pool_put_page(rx_q->page_pool,
+							   virt_to_head_page(xdp.data),
+							   sync_len, true);
 					buf->page = NULL;
 					priv->dev->stats.rx_dropped++;
 
@@ -4388,6 +4584,12 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 
 					count++;
 					continue;
+				} else if (xdp_res & STMMAC_XDP_TX) {
+					xdp_status |= xdp_res;
+					buf->page = NULL;
+					skb = NULL;
+					count++;
+					continue;
 				}
 			}
 		}
@@ -4470,6 +4672,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 		rx_q->state.len = len;
 	}
 
+	stmmac_finalize_xdp_rx(priv, xdp_status);
+
 	stmmac_rx_refill(priv, queue);
 
 	priv->xstats.rx_pkt_n += count;
-- 
2.25.1



From boon.leong.ong at intel.com  Thu Apr  1 03:11:17 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Thu,  1 Apr 2021 10:11:17 +0800
Subject: [PATCH net-next v4 6/6] net: stmmac: Add support for XDP_REDIRECT
 action
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <20210401021117.13360-7-boon.leong.ong@intel.com>

This patch adds the support of XDP_REDIRECT to another remote cpu for
further action. It also implements ndo_xdp_xmit ops, enabling the driver
to transmit packets forwarded to it by XDP program running on another
interface.

This patch has been tested using "xdp_redirect_cpu" for XDP_REDIRECT
+ drop testing. It also been tested with "xdp_redirect" sample app
which can be used to exercise ndo_xdp_xmit ops. The burst traffics are
generated using pktgen_sample03_burst_single_flow.sh in samples/pktgen
directory.

v4: Move xdp_do_flush() processing into stmmac_finalize_xdp_rx() and
    combined the XDP verdict of XDP TX and REDIRECT together.

v3: Added 'nq->trans_start = jiffies' to avoid TX time-out as we are
    sharing TX queue between slow path and XDP. Thanks to Jakub Kicinski
    for point out.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 94 ++++++++++++++++---
 2 files changed, 84 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index a93e22a6be59..c49debb62b05 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -39,6 +39,7 @@ struct stmmac_resources {
 enum stmmac_txbuf_type {
 	STMMAC_TXBUF_T_SKB,
 	STMMAC_TXBUF_T_XDP_TX,
+	STMMAC_TXBUF_T_XDP_NDO,
 };
 
 struct stmmac_tx_info {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 65163b51f8ad..77285646c5fc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -72,6 +72,7 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_XDP_PASS		0
 #define STMMAC_XDP_CONSUMED	BIT(0)
 #define STMMAC_XDP_TX		BIT(1)
+#define STMMAC_XDP_REDIRECT	BIT(2)
 
 static int flow_ctrl = FLOW_AUTO;
 module_param(flow_ctrl, int, 0644);
@@ -1458,7 +1459,8 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 	}
 
 	if (tx_q->xdpf[i] &&
-	    tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XDP_TX) {
+	    (tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XDP_TX ||
+	     tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XDP_NDO)) {
 		xdp_return_frame(tx_q->xdpf[i]);
 		tx_q->xdpf[i] = NULL;
 	}
@@ -2220,7 +2222,8 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 		struct dma_desc *p;
 		int status;
 
-		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_TX) {
+		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_TX ||
+		    tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_NDO) {
 			xdpf = tx_q->xdpf[entry];
 			skb = NULL;
 		} else if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
@@ -2292,6 +2295,12 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 			tx_q->xdpf[entry] = NULL;
 		}
 
+		if (xdpf &&
+		    tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XDP_NDO) {
+			xdp_return_frame(xdpf);
+			tx_q->xdpf[entry] = NULL;
+		}
+
 		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
 			if (likely(skb)) {
 				pkts_compl++;
@@ -4246,10 +4255,9 @@ static unsigned int stmmac_rx_buf2_len(struct stmmac_priv *priv,
 }
 
 static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
-				struct xdp_frame *xdpf)
+				struct xdp_frame *xdpf, bool dma_map)
 {
 	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-	struct page *page = virt_to_page(xdpf->data);
 	unsigned int entry = tx_q->cur_tx;
 	struct dma_desc *tx_desc;
 	dma_addr_t dma_addr;
@@ -4265,12 +4273,23 @@ static int stmmac_xdp_xmit_xdpf(struct stmmac_priv *priv, int queue,
 	else
 		tx_desc = tx_q->dma_tx + entry;
 
-	dma_addr = page_pool_get_dma_addr(page) + sizeof(*xdpf) +
-		   xdpf->headroom;
-	dma_sync_single_for_device(priv->device, dma_addr,
-				   xdpf->len, DMA_BIDIRECTIONAL);
+	if (dma_map) {
+		dma_addr = dma_map_single(priv->device, xdpf->data,
+					  xdpf->len, DMA_TO_DEVICE);
+		if (dma_mapping_error(priv->device, dma_addr))
+			return STMMAC_XDP_CONSUMED;
+
+		tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XDP_NDO;
+	} else {
+		struct page *page = virt_to_page(xdpf->data);
+
+		dma_addr = page_pool_get_dma_addr(page) + sizeof(*xdpf) +
+			   xdpf->headroom;
+		dma_sync_single_for_device(priv->device, dma_addr,
+					   xdpf->len, DMA_BIDIRECTIONAL);
 
-	tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XDP_TX;
+		tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XDP_TX;
+	}
 
 	tx_q->tx_skbuff_dma[entry].buf = dma_addr;
 	tx_q->tx_skbuff_dma[entry].map_as_page = false;
@@ -4340,7 +4359,7 @@ static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
 	/* Avoids TX time-out as we are sharing with slow path */
 	nq->trans_start = jiffies;
 
-	res = stmmac_xdp_xmit_xdpf(priv, queue, xdpf);
+	res = stmmac_xdp_xmit_xdpf(priv, queue, xdpf, false);
 	if (res == STMMAC_XDP_TX)
 		stmmac_flush_tx_descriptors(priv, queue);
 
@@ -4372,6 +4391,12 @@ static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 	case XDP_TX:
 		res = stmmac_xdp_xmit_back(priv, xdp);
 		break;
+	case XDP_REDIRECT:
+		if (xdp_do_redirect(priv->dev, xdp, prog) < 0)
+			res = STMMAC_XDP_CONSUMED;
+		else
+			res = STMMAC_XDP_REDIRECT;
+		break;
 	default:
 		bpf_warn_invalid_xdp_action(act);
 		fallthrough;
@@ -4398,6 +4423,9 @@ static void stmmac_finalize_xdp_rx(struct stmmac_priv *priv,
 
 	if (xdp_status & STMMAC_XDP_TX)
 		stmmac_tx_timer_arm(priv, queue);
+
+	if (xdp_status & STMMAC_XDP_REDIRECT)
+		xdp_do_flush();
 }
 
 /**
@@ -4584,7 +4612,8 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
 
 					count++;
 					continue;
-				} else if (xdp_res & STMMAC_XDP_TX) {
+				} else if (xdp_res & (STMMAC_XDP_TX |
+						      STMMAC_XDP_REDIRECT)) {
 					xdp_status |= xdp_res;
 					buf->page = NULL;
 					skb = NULL;
@@ -5600,6 +5629,48 @@ static int stmmac_bpf(struct net_device *dev, struct netdev_bpf *bpf)
 	}
 }
 
+static int stmmac_xdp_xmit(struct net_device *dev, int num_frames,
+			   struct xdp_frame **frames, u32 flags)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	int cpu = smp_processor_id();
+	struct netdev_queue *nq;
+	int i, nxmit = 0;
+	int queue;
+
+	if (unlikely(test_bit(STMMAC_DOWN, &priv->state)))
+		return -ENETDOWN;
+
+	if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
+		return -EINVAL;
+
+	queue = stmmac_xdp_get_tx_queue(priv, cpu);
+	nq = netdev_get_tx_queue(priv->dev, queue);
+
+	__netif_tx_lock(nq, cpu);
+	/* Avoids TX time-out as we are sharing with slow path */
+	nq->trans_start = jiffies;
+
+	for (i = 0; i < num_frames; i++) {
+		int res;
+
+		res = stmmac_xdp_xmit_xdpf(priv, queue, frames[i], true);
+		if (res == STMMAC_XDP_CONSUMED)
+			break;
+
+		nxmit++;
+	}
+
+	if (flags & XDP_XMIT_FLUSH) {
+		stmmac_flush_tx_descriptors(priv, queue);
+		stmmac_tx_timer_arm(priv, queue);
+	}
+
+	__netif_tx_unlock(nq);
+
+	return nxmit;
+}
+
 static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_open = stmmac_open,
 	.ndo_start_xmit = stmmac_xmit,
@@ -5619,6 +5690,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_vlan_rx_add_vid = stmmac_vlan_rx_add_vid,
 	.ndo_vlan_rx_kill_vid = stmmac_vlan_rx_kill_vid,
 	.ndo_bpf = stmmac_bpf,
+	.ndo_xdp_xmit = stmmac_xdp_xmit,
 };
 
 static void stmmac_reset_subtask(struct stmmac_priv *priv)
-- 
2.25.1



From ck.hu at mediatek.com  Thu Apr  1 03:08:12 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Thu, 1 Apr 2021 10:08:12 +0800
Subject: [PATCH 3/3] drm/mediatek: dpi: add bus format negociation
In-Reply-To: <20210330155330.28759-4-jitao.shi@mediatek.com>
References: <20210330155330.28759-1-jitao.shi@mediatek.com>
 <20210330155330.28759-4-jitao.shi@mediatek.com>
Message-ID: <1617242892.14305.5.camel@mtksdaap41>

Hi, Jitao:

On Tue, 2021-03-30 at 23:53 +0800, Jitao Shi wrote:
> Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
> the possible output and input formats for the current mode and monitor,
> and use the negotiated formats in a basic atomic_check callback.
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 96 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 91 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 87bb27649c4c..4e45d1b01b0c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -81,6 +81,8 @@ struct mtk_dpi {
>  	struct pinctrl *pinctrl;
>  	struct pinctrl_state *pins_gpio;
>  	struct pinctrl_state *pins_dpi;
> +	unsigned int in_bus_format;
> +	unsigned int out_bus_format;

Why do you keep these two value? You does not use them.

>  	bool ddr_edge_sel;
>  	int refcount;
>  };
> @@ -534,6 +536,92 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>  	return 0;
>  }
>  
> +#define MAX_OUTPUT_SEL_FORMATS	2
> +
> +static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> +					struct drm_bridge_state *bridge_state,
> +					struct drm_crtc_state *crtc_state,
> +					struct drm_connector_state *conn_state,
> +					unsigned int *num_output_fmts)
> +{
> +	struct drm_display_mode *mode = &crtc_state->mode;
> +	u32 *output_fmts;
> +	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> +
> +	*num_output_fmts = 0;
> +
> +	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
> +			      GFP_KERNEL);
> +	if (!output_fmts)
> +		return NULL;
> +
> +	/* Default 8bit RGB fallback */
> +	if (dpi->conf->dual_edge) {
> +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
> +		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;

So mt8183 does not support MEDIA_BUS_FMT_RGB888_1X24?

> +		*num_output_fmts = 2;
> +	} else {
> +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
> +		*num_output_fmts = 1;
> +	}
> +
> +	return output_fmts;
> +}
> +
> +#define MAX_INPUT_SEL_FORMATS	1
> +
> +static u32 *mtk_dpi_bridge_atomic_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)
> +{
> +	u32 *input_fmts;
> +
> +	*num_input_fmts = 0;
> +
> +	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> +			     GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	*num_input_fmts = 1;
> +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> +
> +	return input_fmts;
> +}
> +
> +static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
> +				       struct drm_bridge_state *bridge_state,
> +				       struct drm_crtc_state *crtc_state,
> +				       struct drm_connector_state *conn_state)
> +{
> +	struct mtk_dpi *dpi = bridge->driver_private;
> +
> +	dpi->out_bus_format = bridge_state->output_bus_cfg.format;
> +
> +	dpi->in_bus_format = bridge_state->input_bus_cfg.format;
> +
> +	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
> +		bridge_state->input_bus_cfg.format,
> +		bridge_state->output_bus_cfg.format);
> +
> +	if (dpi->out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE ||
> +	    dpi->out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_BE) {

I think you could remove this 'if' checking.

Regards,
CK.

> +		dpi->ddr_edge_sel =
> +			(dpi->out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
> +			 true : false;
> +	}
> +
> +	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> +	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> +	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> +	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> +
> +	return 0;
> +}
> +
>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>  				 enum drm_bridge_attach_flags flags)
>  {
> @@ -572,6 +660,9 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
>  	.mode_set = mtk_dpi_bridge_mode_set,
>  	.disable = mtk_dpi_bridge_disable,
>  	.enable = mtk_dpi_bridge_enable,
> +	.atomic_check = mtk_dpi_bridge_atomic_check,
> +	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
> +	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
>  };
>  
>  static void mtk_dpi_start(struct mtk_ddp_comp *comp)
> @@ -621,11 +712,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
>  		goto err_cleanup;
>  	}
>  
> -	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> -	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> -	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> -	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> -
>  	return 0;
>  
>  err_cleanup:


From tiantao6 at hisilicon.com  Thu Apr  1 03:25:21 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Thu, 1 Apr 2021 10:25:21 +0800
Subject: [PATCH] watchdog: meson_wdt: Use device_get_match_data() helper
Message-ID: <1617243921-56774-1-git-send-email-tiantao6@hisilicon.com>

Use the device_get_match_data() helper instead of open coding.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
 drivers/watchdog/meson_wdt.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/watchdog/meson_wdt.c b/drivers/watchdog/meson_wdt.c
index 459f3ae..539feaa 100644
--- a/drivers/watchdog/meson_wdt.c
+++ b/drivers/watchdog/meson_wdt.c
@@ -162,7 +162,6 @@ static int meson_wdt_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct meson_wdt_dev *meson_wdt;
-	const struct of_device_id *of_id;
 	int err;
 
 	meson_wdt = devm_kzalloc(dev, sizeof(*meson_wdt), GFP_KERNEL);
@@ -173,12 +172,7 @@ static int meson_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(meson_wdt->wdt_base))
 		return PTR_ERR(meson_wdt->wdt_base);
 
-	of_id = of_match_device(meson_wdt_dt_ids, dev);
-	if (!of_id) {
-		dev_err(dev, "Unable to initialize WDT data\n");
-		return -ENODEV;
-	}
-	meson_wdt->data = of_id->data;
+	meson_wdt->data = device_get_match_data(dev);
 
 	meson_wdt->wdt_dev.parent = dev;
 	meson_wdt->wdt_dev.info = &meson_wdt_info;
-- 
2.7.4



From zev at bewilderbeest.net  Thu Apr  1 03:51:03 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 21:51:03 -0500
Subject: [PATCH] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <CACPK8XfBsq6H5qsSNgwqdRhHXTUYnNQKekSNMnxXoVaAzMc=MQ@mail.gmail.com>
References: <CACPK8XfBsq6H5qsSNgwqdRhHXTUYnNQKekSNMnxXoVaAzMc=MQ@mail.gmail.com>
Message-ID: <20210401025104.2278-1-zev@bewilderbeest.net>

This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
mini-ITX 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 host power control, serial console and
KVM support, and POST code snooping.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
---
 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 202 ++++++++++++++++++
 2 files changed, 203 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..b12911262ca1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-ampere-mtjade.dtb \
 	aspeed-bmc-arm-centriq2400-rep.dtb \
 	aspeed-bmc-arm-stardragon4800-rep2.dtb \
+	aspeed-bmc-asrock-e3c246d4i.dts \
 	aspeed-bmc-bytedance-g220a.dtb \
 	aspeed-bmc-facebook-cmm.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
new file mode 100644
index 000000000000..dcab6e78dfa4
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/{
+	model = "ASRock E3C246D4I BMC";
+	compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
+
+	aliases {
+		serial4 = &uart5;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+		bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
+	};
+
+	memory at 80000000 {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		heartbeat {
+			/* BMC_HB_LED_N */
+			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "timer";
+		};
+
+		system-fault {
+			/* SYSTEM_FAULT_LED_N */
+			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
+			panic-indicator;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		uid-button {
+			label = "uid-button";
+			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(F, 1)>;
+		};
+	};
+
+	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>;
+	};
+};
+
+&fmc {
+	status = "okay";
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <100000000>; /* 100 MHz */
+#include "openbmc-flash-layout.dtsi"
+	};
+};
+
+&uart5 {
+	status = "okay";
+};
+
+&vuart {
+	status = "okay";
+	aspeed,sirq-active-high;
+};
+
+&mac0 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+};
+
+&i2c1 {
+	status = "okay";
+
+	/* thermal sensor, one diode run to a disconnected header */
+	w83773g at 4c {
+		compatible = "nuvoton,w83773g";
+		reg = <0x4c>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	/* FRU EEPROM */
+	eeprom at 57 {
+		compatible = "st,24c128", "atmel,24c128";
+		reg = <0x57>;
+		pagesize = <16>;
+	};
+};
+
+&video {
+	status = "okay";
+};
+
+&vhub {
+	status = "okay";
+};
+
+&lpc_ctrl {
+	status = "okay";
+};
+
+&lpc_snoop {
+	status = "okay";
+	snoop-ports = <0x80>;
+};
+
+&gpio {
+	status = "okay";
+	gpio-line-names =
+		/*  A */ "BMC_MAC1_INTB", "BMC_MAC2_INTB", "NMI_BTN_N", "BMC_NMI",
+			"", "", "", "",
+		/*  B */ "", "", "", "", "", "IRQ_BMC_PCH_SMI_LPC_N", "", "",
+		/*  C */ "", "", "", "", "", "", "", "",
+		/*  D */ "BMC_PSIN", "BMC_PSOUT", "BMC_RESETCON", "RESETCON",
+			"", "", "", "",
+		/*  E */ "", "", "", "", "", "", "", "",
+		/*  F */ "LOCATORLED_STATUS_N", "LOCATORBTN", "", "",
+			"", "", "BMC_PCH_SCI_LPC", "BMC_NCSI_MUX_CTL",
+		/*  G */ "HWM_BAT_EN", "CHASSIS_ID0", "CHASSIS_ID1", "CHASSIS_ID2",
+			"BMC_ALERT1_N_R", "BMC_ALERT2_N_R", "BMC_ALERT3_N", "SML0ALERT",
+		/*  H */ "FM_ME_RCVR_N", "O_PWROK", "SKL_CNL_R", "D4_DIMM_EVENT_3V_N",
+			"MFG_MODE_N", "BMC_RTCRST", "BMC_HB_LED_N", "BMC_CASEOPEN",
+		/*  I */ "", "", "", "", "", "", "", "",
+		/*  J */ "BMC_READY", "BMC_PCH_BIOS_CS_N", "BMC_SMI", "",
+			"", "", "", "",
+		/*  K */ "", "", "", "", "", "", "", "",
+		/*  L */ "BMC_CTS1", "BMC_DCD1", "BMC_DSR1", "BMC_RI1",
+			"BMC_DTR1", "BMC_RTS1", "BMC_TXD1", "BMC_RXD1",
+		/*  M */ "BMC_LAN0_DIS_N", "BMC_LAN1_DIS_N", "", "",
+			"", "", "", "",
+		/*  N */ "", "", "", "", "", "", "", "",
+		/*  O */ "", "", "", "", "", "", "", "",
+		/*  P */ "", "", "", "", "", "", "", "",
+		/*  Q */ "", "", "", "",
+			"BMC_SBM_PRESENT_1_N", "BMC_SBM_PRESENT_2_N",
+			"BMC_SBM_PRESENT_3_N", "BMC_PCIE_WAKE_N",
+		/*  R */ "", "", "", "", "", "", "", "",
+		/*  S */ "PCHHOT_BMC_N", "", "RSMRST",
+			"", "", "", "", "",
+		/*  T */ "", "", "", "", "", "", "", "",
+		/*  U */ "", "", "", "", "", "", "", "",
+		/*  V */ "", "", "", "", "", "", "", "",
+		/*  W */ "PS_PWROK", /* dummy always-high signal */
+			"", "", "", "", "", "", "",
+		/*  X */ "", "", "", "", "", "", "", "",
+		/*  Y */ "SLP_S3", "SLP_S5", "", "", "", "", "", "",
+		/*  Z */ "CPU_CATERR_BMC_PCH_N", "", "SYSTEM_FAULT_LED_N", "BMC_THROTTLE_N",
+			"", "", "", "",
+		/* AA */ "CPU1_THERMTRIP_LATCH_N", "", "CPU1_PROCHOT_N", "",
+			"", "", "IRQ_SMI_ACTIVE_N", "FM_BIOS_POST_CMPLT_N",
+		/* AB */ "", "", "ME_OVERRIDE", "BMC_DMI_MODIFY",
+			"", "", "", "",
+		/* AC */ "LAD0", "LAD1", "LAD2", "LAD3",
+			"CK_33M_BMC", "LFRAME", "SERIRQ", "S_PLTRST";
+
+	/* Assert BMC_READY so BIOS doesn't sit around waiting for it */
+	bmc-ready {
+		gpio-hog;
+		gpios = <ASPEED_GPIO(J, 0) GPIO_ACTIVE_LOW>;
+		output-high;
+	};
+};
+
+&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>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
-- 
2.31.1



From chenxiang66 at hisilicon.com  Thu Apr  1 04:28:51 2021
From: chenxiang66 at hisilicon.com (chenxiang (M))
Date: Thu, 1 Apr 2021 11:28:51 +0800
Subject: [RFC PATCH 0/5] Optimization for unmapping iommu mapped buffers
In-Reply-To: <20210331030042.13348-1-isaacm@codeaurora.org>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
Message-ID: <8d8e0c37-95f7-4d24-a4eb-a4b10f771c6a@hisilicon.com>

Hi Isaac,


? 2021/3/31 11:00, Isaac J. Manjarres ??:
> When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
> the buffer at a granule of the largest page size that is supported by
> the IOMMU hardware and fits within the buffer. For every block that
> is unmapped, the IOMMU framework will call into the IOMMU driver, and
> then the io-pgtable framework to walk the page tables to find the entry
> that corresponds to the IOVA, and then unmaps the entry.
>
> This can be suboptimal in scenarios where a buffer or a piece of a
> buffer can be split into several contiguous page blocks of the same size.
> For example, consider an IOMMU that supports 4 KB page blocks, 2 MB page
> blocks, and 1 GB page blocks, and a buffer that is 4 MB in size is being
> unmapped at IOVA 0. The current call-flow will result in 4 indirect calls,
> and 2 page table walks, to unmap 2 entries that are next to each other in
> the page-tables, when both entries could have been unmapped in one shot
> by clearing both page table entries in the same call.
>
> These patches implement a callback called unmap_pages to the io-pgtable
> code and IOMMU drivers which unmaps an IOVA range that consists of a
> number of pages of the same page size that is supported by the IOMMU
> hardware, and allows for clearing multiple entries in the same set of
> indirect calls. The reason for introducing unmap_pages is to give
> other IOMMU drivers/io-pgtable formats time to change to using the new
> unmap_pages callback, so that the transition to using this approach can be
> done piecemeal.
>
> The same optimization is applicable for mapping buffers, however, the
> error handling in the io-pgtable layer couldn't be handled cleanly, as we
> would need to invoke iommu_unmap to unmap the parts of the buffer that
> were mapped, and then do any TLB maintenance. However, that seemed like a
> layering violation.
>
> Any feedback is very much appreciated.

I apply those patchset and implement it for smmuv3 on my kunpeng ARM64 
platform, and test the latency of map/unmap
with tool dma_map_benchmark (./dma_map_benchmark -g xxx),  it promotes 
much on the latency of unmap(us).
Maybe you can add the implement for smmuv3 also. The test result is as 
follows:

                         latency of map/unmap(before opt)    latency of 
map/unmap(after opt)
g=1(4K size)                    0.1/0.7     0.1/0.7
g=2(8K size)                    0.2/1.4     0.2/0.8
g=4(16K size)                  0.3/2.7     0.3/0.9
g=8(32K size)                  0.5/5.4     0.5/1.2
g=16(64K size)                1/10.7 1/1.8
g=32(128K size)              1.8/21.4 1.8/2.8
g=64(256K size)              3.6/42.9 3.6/5.1
g=128(512K size)            7/85.6 7/8.6
g=256(1M size)              13.9/171.1 13.9/15.5
g=512(2M size)              0.2/0.7 0.2/0.9
g=1024(4M size)            0.3/1.5 0.3/1.1


The change for smmuv3 for test are as follows:
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 8594b4a..e0268b1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2292,6 +2292,20 @@ static size_t arm_smmu_unmap(struct iommu_domain 
*domain, unsigned long iova,
         return ops->unmap(ops, iova, size, gather);
  }

+static size_t arm_smmu_unmap_pages(struct iommu_domain *domain, 
unsigned long iova,
+                            size_t pgsize, size_t pgcount,
+                            struct iommu_iotlb_gather *gather)
+{
+       struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+       struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+
+       if (!ops)
+               return 0;
+
+       return ops->unmap_pages(ops, iova, pgsize, pgcount, gather);
+}
+
+
  static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
  {
         struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
@@ -2613,6 +2627,7 @@ static struct iommu_ops arm_smmu_ops = {
         .attach_dev             = arm_smmu_attach_dev,
         .map                    = arm_smmu_map,
         .unmap                  = arm_smmu_unmap,
+       .unmap_pages            = arm_smmu_unmap_pages,
         .flush_iotlb_all        = arm_smmu_flush_iotlb_all,
         .iotlb_sync             = arm_smmu_iotlb_sync,
         .iova_to_phys           = arm_smmu_iova_to_phys,

>
> Thanks,
> Isaac
>
> Isaac J. Manjarres (5):
>    iommu/io-pgtable: Introduce unmap_pages() as a page table op
>    iommu: Add an unmap_pages() op for IOMMU drivers
>    iommu: Add support for the unmap_pages IOMMU callback
>    iommu/io-pgtable-arm: Implement arm_lpae_unmap_pages()
>    iommu/arm-smmu: Implement the unmap_pages IOMMU driver callback
>
>   drivers/iommu/arm/arm-smmu/arm-smmu.c |  19 +++++
>   drivers/iommu/io-pgtable-arm.c        | 114 +++++++++++++++++++++-----
>   drivers/iommu/iommu.c                 |  44 ++++++++--
>   include/linux/io-pgtable.h            |   4 +
>   include/linux/iommu.h                 |   4 +
>   5 files changed, 159 insertions(+), 26 deletions(-)
>




From tiantao6 at hisilicon.com  Thu Apr  1 04:36:44 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Thu, 1 Apr 2021 11:36:44 +0800
Subject: [PATCH] perf: xgene: Use device_get_match_data() to simplify code
Message-ID: <1617248204-8472-1-git-send-email-tiantao6@hisilicon.com>

Use device_get_match_data() here to simplify the code a bit.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
 drivers/perf/xgene_pmu.c | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index ffe3bde..befd2eb 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
 static int xgene_pmu_probe(struct platform_device *pdev)
 {
 	const struct xgene_pmu_data *dev_data;
-	const struct of_device_id *of_id;
 	struct xgene_pmu *xgene_pmu;
 	struct resource *res;
 	int irq, rc;
@@ -1857,21 +1856,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, xgene_pmu);
 
 	version = -EINVAL;
-	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
-	if (of_id) {
-		dev_data = (const struct xgene_pmu_data *) of_id->data;
-		version = dev_data->id;
-	}
-
-#ifdef CONFIG_ACPI
-	if (ACPI_COMPANION(&pdev->dev)) {
-		const struct acpi_device_id *acpi_id;
+	dev_data = device_get_match_data(&pdev->dev);
+	version = dev_data->id;
 
-		acpi_id = acpi_match_device(xgene_pmu_acpi_match, &pdev->dev);
-		if (acpi_id)
-			version = (int) acpi_id->driver_data;
-	}
-#endif
 	if (version < 0)
 		return -ENODEV;
 
-- 
2.7.4



From chenlifu at huawei.com  Thu Apr  1 04:38:30 2021
From: chenlifu at huawei.com (chenlifu)
Date: Thu, 1 Apr 2021 11:38:30 +0800
Subject: [PATCH -next] i2c: gpio: use DEFINE_SPINLOCK() for spinlock
In-Reply-To: <20210327095228.105123-1-chenlifu@huawei.com>
References: <20210327095228.105123-1-chenlifu@huawei.com>
Message-ID: <fec9295e-c5d6-13ee-23f5-13b593d2fd2e@huawei.com>

Kindly pinging ...

Best Regards,
Chen Lifu

? 2021/3/27 17:52, Chen Lifu ??:
> From: Lifu Chen <chenlifu at huawei.com>
> 
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Lifu Chen <chenlifu at huawei.com>
> ---
>   arch/arm/mach-sa1100/simpad.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
> index c7fb9a73e4c5..c183432880d3 100644
> --- a/arch/arm/mach-sa1100/simpad.c
> +++ b/arch/arm/mach-sa1100/simpad.c
> @@ -45,7 +45,7 @@
>    */
>   
>   static long cs3_shadow;
> -static spinlock_t cs3_lock;
> +static DEFINE_SPINLOCK(cs3_lock);
>   static struct gpio_chip cs3_gpio;
>   
>   long simpad_get_cs3_ro(void)
> @@ -379,8 +379,6 @@ static int __init simpad_init(void)
>   {
>   	int ret;
>   
> -	spin_lock_init(&cs3_lock);
> -
>   	cs3_gpio.label = "simpad_cs3";
>   	cs3_gpio.base = SIMPAD_CS3_GPIO_BASE;
>   	cs3_gpio.ngpio = 24;
> 
> .
> 


From joel at jms.id.au  Thu Apr  1 04:51:42 2021
From: joel at jms.id.au (Joel Stanley)
Date: Thu, 1 Apr 2021 03:51:42 +0000
Subject: [PATCH] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <20210401025104.2278-1-zev@bewilderbeest.net>
References: <CACPK8XfBsq6H5qsSNgwqdRhHXTUYnNQKekSNMnxXoVaAzMc=MQ@mail.gmail.com>
 <20210401025104.2278-1-zev@bewilderbeest.net>
Message-ID: <CACPK8Xcr+OauMH2NFSOKF7TZ2HDDnpqPvbnqg17YbKmhroqBMw@mail.gmail.com>

Hi Zev,

On Thu, 1 Apr 2021 at 02:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>
> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
> mini-ITX 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 host power control, serial console and
> KVM support, and POST code snooping.

The patch looks good! Some minor things below.

When sending subsequent versions, make sure to add -v N to your git
format-patch to mark it as the Nth version.

You've also set this to be threaded with a previous version of the
patch. We normally don't do that, and in this case it's doubly
confusing as you've split this patch out from the previous series.

I noticed you cc'd soc at kernel.org. We normally only do this when we
want the soc maintainers to apply a patch directly without going
through another maintainer. In this case the patch should go through
the aspeed maintainer's tree (me), so you don't need to cc that
address.

> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> Reviewed-by: Joel Stanley <joel at jms.id.au>
> ---

This spot just here is where you should put the changes between v1 and v2.

>  arch/arm/boot/dts/Makefile                    |   1 +
>  .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 202 ++++++++++++++++++
>  2 files changed, 203 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e75e..b12911262ca1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>         aspeed-bmc-ampere-mtjade.dtb \
>         aspeed-bmc-arm-centriq2400-rep.dtb \
>         aspeed-bmc-arm-stardragon4800-rep2.dtb \
> +       aspeed-bmc-asrock-e3c246d4i.dts \

This should be the output name (.dtb).

>         aspeed-bmc-bytedance-g220a.dtb \
>         aspeed-bmc-facebook-cmm.dtb \
>         aspeed-bmc-facebook-galaxy100.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> new file mode 100644
> index 000000000000..dcab6e78dfa4
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts

The device tree itself looks good!

If you fix up the things I mentioned and send a v3 I will apply it.

Cheers,

Joel

> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/{
> +       model = "ASRock E3C246D4I BMC";
> +       compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
> +
> +       aliases {
> +               serial4 = &uart5;
> +       };
> +
> +       chosen {
> +               stdout-path = &uart5;
> +               bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
> +       };
> +
> +       memory at 80000000 {
> +               reg = <0x80000000 0x20000000>;
> +       };
> +
> +       leds {
> +               compatible = "gpio-leds";
> +
> +               heartbeat {
> +                       /* BMC_HB_LED_N */
> +                       gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
> +                       linux,default-trigger = "timer";
> +               };
> +
> +               system-fault {
> +                       /* SYSTEM_FAULT_LED_N */
> +                       gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> +                       panic-indicator;
> +               };
> +       };
> +
> +       gpio-keys {
> +               compatible = "gpio-keys";
> +
> +               uid-button {
> +                       label = "uid-button";
> +                       gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> +                       linux,code = <ASPEED_GPIO(F, 1)>;
> +               };
> +       };
> +
> +       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>;
> +       };
> +};
> +
> +&fmc {
> +       status = "okay";
> +       flash at 0 {
> +               status = "okay";
> +               m25p,fast-read;
> +               label = "bmc";
> +               spi-max-frequency = <100000000>; /* 100 MHz */
> +#include "openbmc-flash-layout.dtsi"
> +       };
> +};
> +
> +&uart5 {
> +       status = "okay";
> +};
> +
> +&vuart {
> +       status = "okay";
> +       aspeed,sirq-active-high;
> +};
> +
> +&mac0 {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
> +};
> +
> +&i2c1 {
> +       status = "okay";
> +
> +       /* thermal sensor, one diode run to a disconnected header */
> +       w83773g at 4c {
> +               compatible = "nuvoton,w83773g";
> +               reg = <0x4c>;
> +       };
> +};
> +
> +&i2c3 {
> +       status = "okay";
> +
> +       /* FRU EEPROM */
> +       eeprom at 57 {
> +               compatible = "st,24c128", "atmel,24c128";
> +               reg = <0x57>;
> +               pagesize = <16>;
> +       };
> +};
> +
> +&video {
> +       status = "okay";
> +};
> +
> +&vhub {
> +       status = "okay";
> +};
> +
> +&lpc_ctrl {
> +       status = "okay";
> +};
> +
> +&lpc_snoop {
> +       status = "okay";
> +       snoop-ports = <0x80>;
> +};
> +
> +&gpio {
> +       status = "okay";
> +       gpio-line-names =
> +               /*  A */ "BMC_MAC1_INTB", "BMC_MAC2_INTB", "NMI_BTN_N", "BMC_NMI",
> +                       "", "", "", "",
> +               /*  B */ "", "", "", "", "", "IRQ_BMC_PCH_SMI_LPC_N", "", "",
> +               /*  C */ "", "", "", "", "", "", "", "",
> +               /*  D */ "BMC_PSIN", "BMC_PSOUT", "BMC_RESETCON", "RESETCON",
> +                       "", "", "", "",
> +               /*  E */ "", "", "", "", "", "", "", "",
> +               /*  F */ "LOCATORLED_STATUS_N", "LOCATORBTN", "", "",
> +                       "", "", "BMC_PCH_SCI_LPC", "BMC_NCSI_MUX_CTL",
> +               /*  G */ "HWM_BAT_EN", "CHASSIS_ID0", "CHASSIS_ID1", "CHASSIS_ID2",
> +                       "BMC_ALERT1_N_R", "BMC_ALERT2_N_R", "BMC_ALERT3_N", "SML0ALERT",
> +               /*  H */ "FM_ME_RCVR_N", "O_PWROK", "SKL_CNL_R", "D4_DIMM_EVENT_3V_N",
> +                       "MFG_MODE_N", "BMC_RTCRST", "BMC_HB_LED_N", "BMC_CASEOPEN",
> +               /*  I */ "", "", "", "", "", "", "", "",
> +               /*  J */ "BMC_READY", "BMC_PCH_BIOS_CS_N", "BMC_SMI", "",
> +                       "", "", "", "",
> +               /*  K */ "", "", "", "", "", "", "", "",
> +               /*  L */ "BMC_CTS1", "BMC_DCD1", "BMC_DSR1", "BMC_RI1",
> +                       "BMC_DTR1", "BMC_RTS1", "BMC_TXD1", "BMC_RXD1",
> +               /*  M */ "BMC_LAN0_DIS_N", "BMC_LAN1_DIS_N", "", "",
> +                       "", "", "", "",
> +               /*  N */ "", "", "", "", "", "", "", "",
> +               /*  O */ "", "", "", "", "", "", "", "",
> +               /*  P */ "", "", "", "", "", "", "", "",
> +               /*  Q */ "", "", "", "",
> +                       "BMC_SBM_PRESENT_1_N", "BMC_SBM_PRESENT_2_N",
> +                       "BMC_SBM_PRESENT_3_N", "BMC_PCIE_WAKE_N",
> +               /*  R */ "", "", "", "", "", "", "", "",
> +               /*  S */ "PCHHOT_BMC_N", "", "RSMRST",
> +                       "", "", "", "", "",
> +               /*  T */ "", "", "", "", "", "", "", "",
> +               /*  U */ "", "", "", "", "", "", "", "",
> +               /*  V */ "", "", "", "", "", "", "", "",
> +               /*  W */ "PS_PWROK", /* dummy always-high signal */
> +                       "", "", "", "", "", "", "",
> +               /*  X */ "", "", "", "", "", "", "", "",
> +               /*  Y */ "SLP_S3", "SLP_S5", "", "", "", "", "", "",
> +               /*  Z */ "CPU_CATERR_BMC_PCH_N", "", "SYSTEM_FAULT_LED_N", "BMC_THROTTLE_N",
> +                       "", "", "", "",
> +               /* AA */ "CPU1_THERMTRIP_LATCH_N", "", "CPU1_PROCHOT_N", "",
> +                       "", "", "IRQ_SMI_ACTIVE_N", "FM_BIOS_POST_CMPLT_N",
> +               /* AB */ "", "", "ME_OVERRIDE", "BMC_DMI_MODIFY",
> +                       "", "", "", "",
> +               /* AC */ "LAD0", "LAD1", "LAD2", "LAD3",
> +                       "CK_33M_BMC", "LFRAME", "SERIRQ", "S_PLTRST";
> +
> +       /* Assert BMC_READY so BIOS doesn't sit around waiting for it */
> +       bmc-ready {
> +               gpio-hog;
> +               gpios = <ASPEED_GPIO(J, 0) GPIO_ACTIVE_LOW>;
> +               output-high;
> +       };
> +};
> +
> +&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>;
> +};
> +
> +&kcs3 {
> +       status = "okay";
> +       aspeed,lpc-io-reg = <0xca2>;
> +};
> --
> 2.31.1
>


From joel at jms.id.au  Thu Apr  1 04:53:21 2021
From: joel at jms.id.au (Joel Stanley)
Date: Thu, 1 Apr 2021 03:53:21 +0000
Subject: [PATCH v2 1/3] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210401005702.28271-2-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-2-zev@bewilderbeest.net>
Message-ID: <CACPK8Xeqrvtb4Qku545QcbLeqgbHOZHkpgMp3G332c0aMdMCvA@mail.gmail.com>

On Thu, 1 Apr 2021 at 00:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>
> This property ties SIRQ polarity to SCU register bits that don't
> necessarily have any direct relationship to it; the only use of it
> was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.
>
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>

Reviewed-by: Joel Stanley <joel at jms.id.au>

> ---
>  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index f54cae9ff7b2..491b9297432d 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -188,6 +188,7 @@ properties:
>        offset and bit number to identify how the SIRQ polarity should be
>        configured. One possible data source is the LPC/eSPI mode bit. Only
>        applicable to aspeed,ast2500-vuart.
> +    deprecated: true
>
>  required:
>    - reg
> --
> 2.31.1
>


From andrew at aj.id.au  Thu Apr  1 05:04:44 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Thu, 01 Apr 2021 14:34:44 +1030
Subject: =?UTF-8?Q?Re:_[PATCH_v2_3/3]_dt-bindings:_serial:_8250:_add_aspeed,
 sirq-?= =?UTF-8?Q?active-high?=
In-Reply-To: <20210401005702.28271-4-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-4-zev@bewilderbeest.net>
Message-ID: <d66753ee-7db2-41e5-9fe5-762b1ab678bc@www.fastmail.com>



On Thu, 1 Apr 2021, at 11:27, Zev Weiss wrote:
> This provides a simpler, more direct alternative to the deprecated
> aspeed,sirq-polarity-sense property for indicating the polarity of
> the Aspeed VUART's SIRQ line.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  Documentation/devicetree/bindings/serial/8250.yaml | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml 
> b/Documentation/devicetree/bindings/serial/8250.yaml
> index 491b9297432d..e79bb6ab9d2c 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -12,8 +12,9 @@ maintainers:
>  allOf:
>    - $ref: /schemas/serial.yaml#
>    - if:
> -      required:
> -        - aspeed,sirq-polarity-sense
> +      anyOf:
> +        - required: [ aspeed,sirq-active-high ]

Do you think we could make use of the approach I put forward here?

https://lore.kernel.org/openbmc/20210319062752.145730-18-andrew at aj.id.au/T/#u

Andrew


From zev at bewilderbeest.net  Thu Apr  1 05:09:20 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 23:09:20 -0500
Subject: [PATCH] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <CACPK8Xcr+OauMH2NFSOKF7TZ2HDDnpqPvbnqg17YbKmhroqBMw@mail.gmail.com>
References: <CACPK8XfBsq6H5qsSNgwqdRhHXTUYnNQKekSNMnxXoVaAzMc=MQ@mail.gmail.com>
 <20210401025104.2278-1-zev@bewilderbeest.net>
 <CACPK8Xcr+OauMH2NFSOKF7TZ2HDDnpqPvbnqg17YbKmhroqBMw@mail.gmail.com>
Message-ID: <YGVHcGnwvN638d6z@hatter.bewilderbeest.net>

On Wed, Mar 31, 2021 at 10:51:42PM CDT, Joel Stanley wrote:
>Hi Zev,
>
>On Thu, 1 Apr 2021 at 02:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>>
>> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
>> mini-ITX 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 host power control, serial console and
>> KVM support, and POST code snooping.
>
>The patch looks good! Some minor things below.
>
>When sending subsequent versions, make sure to add -v N to your git
>format-patch to mark it as the Nth version.
>
>You've also set this to be threaded with a previous version of the
>patch. We normally don't do that, and in this case it's doubly
>confusing as you've split this patch out from the previous series.
>
>I noticed you cc'd soc at kernel.org. We normally only do this when we
>want the soc maintainers to apply a patch directly without going
>through another maintainer. In this case the patch should go through
>the aspeed maintainer's tree (me), so you don't need to cc that
>address.
>

Hmm, that came from using './scripts/get_maintainer.pl --no-rolestats' 
with git send-email's --cc-cmd flag; does there happen to be a similarly 
easy alternative that wouldn't do the "wrong" thing there?

Ack on the rest, will send v3 soon.


Thanks,
Zev

>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> Reviewed-by: Joel Stanley <joel at jms.id.au>
>> ---
>
>This spot just here is where you should put the changes between v1 and v2.
>
>>  arch/arm/boot/dts/Makefile                    |   1 +
>>  .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 202 ++++++++++++++++++
>>  2 files changed, 203 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 8e5d4ab4e75e..b12911262ca1 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>         aspeed-bmc-ampere-mtjade.dtb \
>>         aspeed-bmc-arm-centriq2400-rep.dtb \
>>         aspeed-bmc-arm-stardragon4800-rep2.dtb \
>> +       aspeed-bmc-asrock-e3c246d4i.dts \
>
>This should be the output name (.dtb).
>
>>         aspeed-bmc-bytedance-g220a.dtb \
>>         aspeed-bmc-facebook-cmm.dtb \
>>         aspeed-bmc-facebook-galaxy100.dtb \
>> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>> new file mode 100644
>> index 000000000000..dcab6e78dfa4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
>
>The device tree itself looks good!
>
>If you fix up the things I mentioned and send a v3 I will apply it.
>
>Cheers,
>
>Joel
>
>> @@ -0,0 +1,202 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/dts-v1/;
>> +
>> +#include "aspeed-g5.dtsi"
>> +#include <dt-bindings/gpio/aspeed-gpio.h>
>> +#include <dt-bindings/i2c/i2c.h>
>> +
>> +/{
>> +       model = "ASRock E3C246D4I BMC";
>> +       compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
>> +
>> +       aliases {
>> +               serial4 = &uart5;
>> +       };
>> +
>> +       chosen {
>> +               stdout-path = &uart5;
>> +               bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
>> +       };
>> +
>> +       memory at 80000000 {
>> +               reg = <0x80000000 0x20000000>;
>> +       };
>> +
>> +       leds {
>> +               compatible = "gpio-leds";
>> +
>> +               heartbeat {
>> +                       /* BMC_HB_LED_N */
>> +                       gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
>> +                       linux,default-trigger = "timer";
>> +               };
>> +
>> +               system-fault {
>> +                       /* SYSTEM_FAULT_LED_N */
>> +                       gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
>> +                       panic-indicator;
>> +               };
>> +       };
>> +
>> +       gpio-keys {
>> +               compatible = "gpio-keys";
>> +
>> +               uid-button {
>> +                       label = "uid-button";
>> +                       gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
>> +                       linux,code = <ASPEED_GPIO(F, 1)>;
>> +               };
>> +       };
>> +
>> +       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>;
>> +       };
>> +};
>> +
>> +&fmc {
>> +       status = "okay";
>> +       flash at 0 {
>> +               status = "okay";
>> +               m25p,fast-read;
>> +               label = "bmc";
>> +               spi-max-frequency = <100000000>; /* 100 MHz */
>> +#include "openbmc-flash-layout.dtsi"
>> +       };
>> +};
>> +
>> +&uart5 {
>> +       status = "okay";
>> +};
>> +
>> +&vuart {
>> +       status = "okay";
>> +       aspeed,sirq-active-high;
>> +};
>> +
>> +&mac0 {
>> +       status = "okay";
>> +
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
>> +};
>> +
>> +&i2c1 {
>> +       status = "okay";
>> +
>> +       /* thermal sensor, one diode run to a disconnected header */
>> +       w83773g at 4c {
>> +               compatible = "nuvoton,w83773g";
>> +               reg = <0x4c>;
>> +       };
>> +};
>> +
>> +&i2c3 {
>> +       status = "okay";
>> +
>> +       /* FRU EEPROM */
>> +       eeprom at 57 {
>> +               compatible = "st,24c128", "atmel,24c128";
>> +               reg = <0x57>;
>> +               pagesize = <16>;
>> +       };
>> +};
>> +
>> +&video {
>> +       status = "okay";
>> +};
>> +
>> +&vhub {
>> +       status = "okay";
>> +};
>> +
>> +&lpc_ctrl {
>> +       status = "okay";
>> +};
>> +
>> +&lpc_snoop {
>> +       status = "okay";
>> +       snoop-ports = <0x80>;
>> +};
>> +
>> +&gpio {
>> +       status = "okay";
>> +       gpio-line-names =
>> +               /*  A */ "BMC_MAC1_INTB", "BMC_MAC2_INTB", "NMI_BTN_N", "BMC_NMI",
>> +                       "", "", "", "",
>> +               /*  B */ "", "", "", "", "", "IRQ_BMC_PCH_SMI_LPC_N", "", "",
>> +               /*  C */ "", "", "", "", "", "", "", "",
>> +               /*  D */ "BMC_PSIN", "BMC_PSOUT", "BMC_RESETCON", "RESETCON",
>> +                       "", "", "", "",
>> +               /*  E */ "", "", "", "", "", "", "", "",
>> +               /*  F */ "LOCATORLED_STATUS_N", "LOCATORBTN", "", "",
>> +                       "", "", "BMC_PCH_SCI_LPC", "BMC_NCSI_MUX_CTL",
>> +               /*  G */ "HWM_BAT_EN", "CHASSIS_ID0", "CHASSIS_ID1", "CHASSIS_ID2",
>> +                       "BMC_ALERT1_N_R", "BMC_ALERT2_N_R", "BMC_ALERT3_N", "SML0ALERT",
>> +               /*  H */ "FM_ME_RCVR_N", "O_PWROK", "SKL_CNL_R", "D4_DIMM_EVENT_3V_N",
>> +                       "MFG_MODE_N", "BMC_RTCRST", "BMC_HB_LED_N", "BMC_CASEOPEN",
>> +               /*  I */ "", "", "", "", "", "", "", "",
>> +               /*  J */ "BMC_READY", "BMC_PCH_BIOS_CS_N", "BMC_SMI", "",
>> +                       "", "", "", "",
>> +               /*  K */ "", "", "", "", "", "", "", "",
>> +               /*  L */ "BMC_CTS1", "BMC_DCD1", "BMC_DSR1", "BMC_RI1",
>> +                       "BMC_DTR1", "BMC_RTS1", "BMC_TXD1", "BMC_RXD1",
>> +               /*  M */ "BMC_LAN0_DIS_N", "BMC_LAN1_DIS_N", "", "",
>> +                       "", "", "", "",
>> +               /*  N */ "", "", "", "", "", "", "", "",
>> +               /*  O */ "", "", "", "", "", "", "", "",
>> +               /*  P */ "", "", "", "", "", "", "", "",
>> +               /*  Q */ "", "", "", "",
>> +                       "BMC_SBM_PRESENT_1_N", "BMC_SBM_PRESENT_2_N",
>> +                       "BMC_SBM_PRESENT_3_N", "BMC_PCIE_WAKE_N",
>> +               /*  R */ "", "", "", "", "", "", "", "",
>> +               /*  S */ "PCHHOT_BMC_N", "", "RSMRST",
>> +                       "", "", "", "", "",
>> +               /*  T */ "", "", "", "", "", "", "", "",
>> +               /*  U */ "", "", "", "", "", "", "", "",
>> +               /*  V */ "", "", "", "", "", "", "", "",
>> +               /*  W */ "PS_PWROK", /* dummy always-high signal */
>> +                       "", "", "", "", "", "", "",
>> +               /*  X */ "", "", "", "", "", "", "", "",
>> +               /*  Y */ "SLP_S3", "SLP_S5", "", "", "", "", "", "",
>> +               /*  Z */ "CPU_CATERR_BMC_PCH_N", "", "SYSTEM_FAULT_LED_N", "BMC_THROTTLE_N",
>> +                       "", "", "", "",
>> +               /* AA */ "CPU1_THERMTRIP_LATCH_N", "", "CPU1_PROCHOT_N", "",
>> +                       "", "", "IRQ_SMI_ACTIVE_N", "FM_BIOS_POST_CMPLT_N",
>> +               /* AB */ "", "", "ME_OVERRIDE", "BMC_DMI_MODIFY",
>> +                       "", "", "", "",
>> +               /* AC */ "LAD0", "LAD1", "LAD2", "LAD3",
>> +                       "CK_33M_BMC", "LFRAME", "SERIRQ", "S_PLTRST";
>> +
>> +       /* Assert BMC_READY so BIOS doesn't sit around waiting for it */
>> +       bmc-ready {
>> +               gpio-hog;
>> +               gpios = <ASPEED_GPIO(J, 0) GPIO_ACTIVE_LOW>;
>> +               output-high;
>> +       };
>> +};
>> +
>> +&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>;
>> +};
>> +
>> +&kcs3 {
>> +       status = "okay";
>> +       aspeed,lpc-io-reg = <0xca2>;
>> +};
>> --
>> 2.31.1
>>


From joel at jms.id.au  Thu Apr  1 05:15:44 2021
From: joel at jms.id.au (Joel Stanley)
Date: Thu, 1 Apr 2021 04:15:44 +0000
Subject: [PATCH v2 2/3] drivers/tty/serial/8250: add DT property for
 aspeed vuart sirq polarity
In-Reply-To: <20210401005702.28271-3-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-3-zev@bewilderbeest.net>
Message-ID: <CACPK8XdPVf1WMmo8C8RJtd-1cH5qV9odEDhDUHWRiMOk=dQNtg@mail.gmail.com>

On Thu, 1 Apr 2021 at 00:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>
> This provides a simple boolean to use instead of the deprecated
> aspeed,sirq-polarity-sense property.
>
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> index c33e02cbde93..e5ef9f957f9a 100644
> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> @@ -482,6 +482,9 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>                 of_node_put(sirq_polarity_sense_args.np);
>         }
>
> +       if (of_property_read_bool(np, "aspeed,sirq-active-high"))
> +               aspeed_vuart_set_sirq_polarity(vuart, 1);

This assumes the default is always low, so we don't need a property to
set it to that state?

Would it make more sense to have the property describe if it's high or
low? (I'm happy for the answer to be "no", as we've gotten by for the
past few years without it).

This brings up another point. We already have the sysfs file for
setting the lpc address, from userspace. In OpenBMC land this can be
set with obmc-console-client (/etc/obmc-console.conf). Should we add
support to that application for setting the irq polarity too, and do
away with device tree descriptions?

> +
>         aspeed_vuart_set_enabled(vuart, true);
>         aspeed_vuart_set_host_tx_discard(vuart, true);
>         platform_set_drvdata(pdev, vuart);
> --
> 2.31.1
>


From zev at bewilderbeest.net  Thu Apr  1 05:42:31 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 23:42:31 -0500
Subject: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
Message-ID: <20210401044232.9637-1-zev@bewilderbeest.net>

This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
mini-ITX 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 host power control, serial console and
KVM support, and POST code snooping.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
---

Changes since v2:
 - un-bungled filename in dtb-$(CONFIG_ARCH_ASPEED)
Changes since v1:
 - added entry to dtb-$(CONFIG_ARCH_ASPEED)
 - added board to compatible
 - added pinctrl properties to adc
 - split out of mostly-unrelated patch series

 arch/arm/boot/dts/Makefile                    |   1 +
 .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 202 ++++++++++++++++++
 2 files changed, 203 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..c22151b50ddc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-ampere-mtjade.dtb \
 	aspeed-bmc-arm-centriq2400-rep.dtb \
 	aspeed-bmc-arm-stardragon4800-rep2.dtb \
+	aspeed-bmc-asrock-e3c246d4i.dtb \
 	aspeed-bmc-bytedance-g220a.dtb \
 	aspeed-bmc-facebook-cmm.dtb \
 	aspeed-bmc-facebook-galaxy100.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
new file mode 100644
index 000000000000..dcab6e78dfa4
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/i2c/i2c.h>
+
+/{
+	model = "ASRock E3C246D4I BMC";
+	compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
+
+	aliases {
+		serial4 = &uart5;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+		bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
+	};
+
+	memory at 80000000 {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		heartbeat {
+			/* BMC_HB_LED_N */
+			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "timer";
+		};
+
+		system-fault {
+			/* SYSTEM_FAULT_LED_N */
+			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
+			panic-indicator;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		uid-button {
+			label = "uid-button";
+			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(F, 1)>;
+		};
+	};
+
+	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>;
+	};
+};
+
+&fmc {
+	status = "okay";
+	flash at 0 {
+		status = "okay";
+		m25p,fast-read;
+		label = "bmc";
+		spi-max-frequency = <100000000>; /* 100 MHz */
+#include "openbmc-flash-layout.dtsi"
+	};
+};
+
+&uart5 {
+	status = "okay";
+};
+
+&vuart {
+	status = "okay";
+	aspeed,sirq-active-high;
+};
+
+&mac0 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+};
+
+&i2c1 {
+	status = "okay";
+
+	/* thermal sensor, one diode run to a disconnected header */
+	w83773g at 4c {
+		compatible = "nuvoton,w83773g";
+		reg = <0x4c>;
+	};
+};
+
+&i2c3 {
+	status = "okay";
+
+	/* FRU EEPROM */
+	eeprom at 57 {
+		compatible = "st,24c128", "atmel,24c128";
+		reg = <0x57>;
+		pagesize = <16>;
+	};
+};
+
+&video {
+	status = "okay";
+};
+
+&vhub {
+	status = "okay";
+};
+
+&lpc_ctrl {
+	status = "okay";
+};
+
+&lpc_snoop {
+	status = "okay";
+	snoop-ports = <0x80>;
+};
+
+&gpio {
+	status = "okay";
+	gpio-line-names =
+		/*  A */ "BMC_MAC1_INTB", "BMC_MAC2_INTB", "NMI_BTN_N", "BMC_NMI",
+			"", "", "", "",
+		/*  B */ "", "", "", "", "", "IRQ_BMC_PCH_SMI_LPC_N", "", "",
+		/*  C */ "", "", "", "", "", "", "", "",
+		/*  D */ "BMC_PSIN", "BMC_PSOUT", "BMC_RESETCON", "RESETCON",
+			"", "", "", "",
+		/*  E */ "", "", "", "", "", "", "", "",
+		/*  F */ "LOCATORLED_STATUS_N", "LOCATORBTN", "", "",
+			"", "", "BMC_PCH_SCI_LPC", "BMC_NCSI_MUX_CTL",
+		/*  G */ "HWM_BAT_EN", "CHASSIS_ID0", "CHASSIS_ID1", "CHASSIS_ID2",
+			"BMC_ALERT1_N_R", "BMC_ALERT2_N_R", "BMC_ALERT3_N", "SML0ALERT",
+		/*  H */ "FM_ME_RCVR_N", "O_PWROK", "SKL_CNL_R", "D4_DIMM_EVENT_3V_N",
+			"MFG_MODE_N", "BMC_RTCRST", "BMC_HB_LED_N", "BMC_CASEOPEN",
+		/*  I */ "", "", "", "", "", "", "", "",
+		/*  J */ "BMC_READY", "BMC_PCH_BIOS_CS_N", "BMC_SMI", "",
+			"", "", "", "",
+		/*  K */ "", "", "", "", "", "", "", "",
+		/*  L */ "BMC_CTS1", "BMC_DCD1", "BMC_DSR1", "BMC_RI1",
+			"BMC_DTR1", "BMC_RTS1", "BMC_TXD1", "BMC_RXD1",
+		/*  M */ "BMC_LAN0_DIS_N", "BMC_LAN1_DIS_N", "", "",
+			"", "", "", "",
+		/*  N */ "", "", "", "", "", "", "", "",
+		/*  O */ "", "", "", "", "", "", "", "",
+		/*  P */ "", "", "", "", "", "", "", "",
+		/*  Q */ "", "", "", "",
+			"BMC_SBM_PRESENT_1_N", "BMC_SBM_PRESENT_2_N",
+			"BMC_SBM_PRESENT_3_N", "BMC_PCIE_WAKE_N",
+		/*  R */ "", "", "", "", "", "", "", "",
+		/*  S */ "PCHHOT_BMC_N", "", "RSMRST",
+			"", "", "", "", "",
+		/*  T */ "", "", "", "", "", "", "", "",
+		/*  U */ "", "", "", "", "", "", "", "",
+		/*  V */ "", "", "", "", "", "", "", "",
+		/*  W */ "PS_PWROK", /* dummy always-high signal */
+			"", "", "", "", "", "", "",
+		/*  X */ "", "", "", "", "", "", "", "",
+		/*  Y */ "SLP_S3", "SLP_S5", "", "", "", "", "", "",
+		/*  Z */ "CPU_CATERR_BMC_PCH_N", "", "SYSTEM_FAULT_LED_N", "BMC_THROTTLE_N",
+			"", "", "", "",
+		/* AA */ "CPU1_THERMTRIP_LATCH_N", "", "CPU1_PROCHOT_N", "",
+			"", "", "IRQ_SMI_ACTIVE_N", "FM_BIOS_POST_CMPLT_N",
+		/* AB */ "", "", "ME_OVERRIDE", "BMC_DMI_MODIFY",
+			"", "", "", "",
+		/* AC */ "LAD0", "LAD1", "LAD2", "LAD3",
+			"CK_33M_BMC", "LFRAME", "SERIRQ", "S_PLTRST";
+
+	/* Assert BMC_READY so BIOS doesn't sit around waiting for it */
+	bmc-ready {
+		gpio-hog;
+		gpios = <ASPEED_GPIO(J, 0) GPIO_ACTIVE_LOW>;
+		output-high;
+	};
+};
+
+&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>;
+};
+
+&kcs3 {
+	status = "okay";
+	aspeed,lpc-io-reg = <0xca2>;
+};
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  1 05:57:16 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 31 Mar 2021 23:57:16 -0500
Subject: [PATCH v2 3/3] dt-bindings: serial: 8250: add
 aspeed,sirq-active-high
In-Reply-To: <d66753ee-7db2-41e5-9fe5-762b1ab678bc@www.fastmail.com>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-4-zev@bewilderbeest.net>
 <d66753ee-7db2-41e5-9fe5-762b1ab678bc@www.fastmail.com>
Message-ID: <YGVSrCo7mVkSJTeQ@hatter.bewilderbeest.net>

On Wed, Mar 31, 2021 at 11:04:44PM CDT, Andrew Jeffery wrote:
>
>
>On Thu, 1 Apr 2021, at 11:27, Zev Weiss wrote:
>> This provides a simpler, more direct alternative to the deprecated
>> aspeed,sirq-polarity-sense property for indicating the polarity of
>> the Aspeed VUART's SIRQ line.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  Documentation/devicetree/bindings/serial/8250.yaml | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml
>> b/Documentation/devicetree/bindings/serial/8250.yaml
>> index 491b9297432d..e79bb6ab9d2c 100644
>> --- a/Documentation/devicetree/bindings/serial/8250.yaml
>> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
>> @@ -12,8 +12,9 @@ maintainers:
>>  allOf:
>>    - $ref: /schemas/serial.yaml#
>>    - if:
>> -      required:
>> -        - aspeed,sirq-polarity-sense
>> +      anyOf:
>> +        - required: [ aspeed,sirq-active-high ]
>
>Do you think we could make use of the approach I put forward here?
>
>https://lore.kernel.org/openbmc/20210319062752.145730-18-andrew at aj.id.au/T/#u
>
>Andrew

If you mean using a u32 property (say aspeed,sirq-polarity) with an 
explicit IRQ_TYPE_LEVEL_{LOW,HIGH} instead of a present/absent bool,
sure, I guess that seems like a somewhat clearer, more orthogonal 
arrangement.


Zev



From christophe.leroy at csgroup.eu  Thu Apr  1 06:04:58 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 1 Apr 2021 07:04:58 +0200
Subject: [PATCH] watchdog: meson_wdt: Use device_get_match_data() helper
In-Reply-To: <1617243921-56774-1-git-send-email-tiantao6@hisilicon.com>
References: <1617243921-56774-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <77b2534d-8a3c-381a-af2a-4bf7e2d06736@csgroup.eu>



Le 01/04/2021 ? 04:25, Tian Tao a ?crit?:
> Use the device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> ---
>   drivers/watchdog/meson_wdt.c | 8 +-------
>   1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/watchdog/meson_wdt.c b/drivers/watchdog/meson_wdt.c
> index 459f3ae..539feaa 100644
> --- a/drivers/watchdog/meson_wdt.c
> +++ b/drivers/watchdog/meson_wdt.c
> @@ -162,7 +162,6 @@ static int meson_wdt_probe(struct platform_device *pdev)
>   {
>   	struct device *dev = &pdev->dev;
>   	struct meson_wdt_dev *meson_wdt;
> -	const struct of_device_id *of_id;
>   	int err;
>   
>   	meson_wdt = devm_kzalloc(dev, sizeof(*meson_wdt), GFP_KERNEL);
> @@ -173,12 +172,7 @@ static int meson_wdt_probe(struct platform_device *pdev)
>   	if (IS_ERR(meson_wdt->wdt_base))
>   		return PTR_ERR(meson_wdt->wdt_base);
>   
> -	of_id = of_match_device(meson_wdt_dt_ids, dev);
> -	if (!of_id) {
> -		dev_err(dev, "Unable to initialize WDT data\n");
> -		return -ENODEV;
> -	}
> -	meson_wdt->data = of_id->data;
> +	meson_wdt->data = device_get_match_data(dev);

Previously, it was returning -ENODEV on failure.
What happens now when device_get_match_data() returns NULL ?

>   
>   	meson_wdt->wdt_dev.parent = dev;
>   	meson_wdt->wdt_dev.info = &meson_wdt_info;
> 

Christophe


From zev at bewilderbeest.net  Thu Apr  1 06:18:51 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu, 1 Apr 2021 00:18:51 -0500
Subject: [PATCH v2 2/3] drivers/tty/serial/8250: add DT property for
 aspeed vuart sirq polarity
In-Reply-To: <CACPK8XdPVf1WMmo8C8RJtd-1cH5qV9odEDhDUHWRiMOk=dQNtg@mail.gmail.com>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-3-zev@bewilderbeest.net>
 <CACPK8XdPVf1WMmo8C8RJtd-1cH5qV9odEDhDUHWRiMOk=dQNtg@mail.gmail.com>
Message-ID: <YGVXuyqOyxc8kcQz@hatter.bewilderbeest.net>

On Wed, Mar 31, 2021 at 11:15:44PM CDT, Joel Stanley wrote:
>On Thu, 1 Apr 2021 at 00:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>>
>> This provides a simple boolean to use instead of the deprecated
>> aspeed,sirq-polarity-sense property.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> index c33e02cbde93..e5ef9f957f9a 100644
>> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> @@ -482,6 +482,9 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>>                 of_node_put(sirq_polarity_sense_args.np);
>>         }
>>
>> +       if (of_property_read_bool(np, "aspeed,sirq-active-high"))
>> +               aspeed_vuart_set_sirq_polarity(vuart, 1);
>
>This assumes the default is always low, so we don't need a property to
>set it to that state?
>
>Would it make more sense to have the property describe if it's high or
>low? (I'm happy for the answer to be "no", as we've gotten by for the
>past few years without it).
>

Yeah, that sounds like better way to approach it -- I think I'll 
rearrange as Andrew suggested in 
https://lore.kernel.org/openbmc/d66753ee-7db2-41e5-9fe5-762b1ab678bc at www.fastmail.com/

>This brings up another point. We already have the sysfs file for
>setting the lpc address, from userspace. In OpenBMC land this can be
>set with obmc-console-client (/etc/obmc-console.conf). Should we add
>support to that application for setting the irq polarity too, and do
>away with device tree descriptions?
>

I guess I might lean slightly toward keeping the DT description so that 
if for whatever reason obmc-console-server flakes out and doesn't start 
you're better positioned to try banging on /dev/ttyS* manually if you're 
desperate.  Though I suppose that in turn might imply that I'm arguing 
for adding DT properties for lpc_address and sirq too, and if you're 
really that desperate you can just fiddle with sysfs anyway, so...shrug?  
I could be convinced either way fairly easily.


Zev



From mani at kernel.org  Thu Apr  1 06:24:38 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 1 Apr 2021 10:54:38 +0530
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210401052438.GB14052@work>

On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> This patchset adds a socinfo driver which provides information about
> Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> serial_number.
> 
> Please note the serial number is currently available only for the S500
> SoC variant.
> 
> This has been tested on the S500 SoC based RoseapplePi SBC.
> 

Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
what basis it provides? I don't think the SoC has the provision for
soc_id based on HW parameters.

Thanks,
Mani

> Thanks,
> Cristi
> 
> Changes in v2:
>  - Exposed the memory range for reading the SoC serial number under
>    /reserved-memory DT node, according to Rob's review; as a consequence
>    added a new binding document (actions,owl-soc-serial.yaml) and updated
>    owl-socinfo.yaml
> 
>  - Replaced the unportable usage of system_serial_{low,high} globals
>    with a public API to provide external access to SoC serial number
>    parts (e.g. Owl Ethernet MAC driver will use this to generate a
>    stable MAC address)
> 
>  - Rebased patch series on v5.12-rc5
> 
> Cristian Ciocaltea (6):
>   dt-bindings: reserved-memory: Add Owl SoC serial number binding
>   dt-bindings: soc: actions: Add Actions Semi Owl socinfo binding
>   soc: actions: Add Actions Semi Owl socinfo driver
>   arm: dts: owl-s500: Add reserved-memory range for Owl SoC serial
>     number
>   arm: dts: owl-s500: Add socinfo support
>   MAINTAINERS: Add entries for Owl reserved-memory and socinfo bindings
> 
>  .../actions,owl-soc-serial.yaml               |  53 ++++++
>  .../bindings/soc/actions/owl-socinfo.yaml     |  57 +++++++
>  MAINTAINERS                                   |   2 +
>  arch/arm/boot/dts/owl-s500.dtsi               |  13 +-
>  drivers/soc/actions/Kconfig                   |   8 +
>  drivers/soc/actions/Makefile                  |   1 +
>  drivers/soc/actions/owl-socinfo.c             | 152 ++++++++++++++++++
>  include/linux/soc/actions/owl-serial-number.h |  20 +++
>  8 files changed, 305 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
>  create mode 100644 Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
>  create mode 100644 drivers/soc/actions/owl-socinfo.c
>  create mode 100644 include/linux/soc/actions/owl-serial-number.h
> 
> -- 
> 2.31.1
> 


From mani at kernel.org  Thu Apr  1 06:29:29 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 1 Apr 2021 10:59:29 +0530
Subject: [PATCH 1/1] arm: dts: owl-s500-roseapplepi: Add ATC2603C PMIC
In-Reply-To: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
References: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210401052929.GC14052@work>

On Fri, Mar 12, 2021 at 11:49:27AM +0200, Cristian Ciocaltea wrote:
> Add device tree node for ATC2603C PMIC and remove the 'fixed-3.1V'
> dummy regulator used for the uSD supply.
> 
> Additionally, add 'SYSPWR' fixed regulator and provide cpu0 supply.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>

Reviewed-by: Manivannan Sadhasivam <mani at kernel.org>

Thanks,
Mani

> ---
> Please note the patch depends on the ATC260x PMIC support which is queued
> for merging in v5.13:
> 
> https://lore.kernel.org/lkml/cover.1611653995.git.cristian.ciocaltea at gmail.com/
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next&qt=range&q=a38fd8748464831584a19438cbb3082b5a2dab15..eac013a0b7041f5cfc8feedf429a767675350102
> 
>  arch/arm/boot/dts/owl-s500-roseapplepi.dts | 132 ++++++++++++++++++++-
>  1 file changed, 126 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/owl-s500-roseapplepi.dts b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> index ff91561ca99c..b8c5db2344aa 100644
> --- a/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> +++ b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> @@ -2,7 +2,7 @@
>  /*
>   * Roseapple Pi
>   *
> - * Copyright (C) 2020 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> + * Copyright (C) 2020-2021 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
>   */
>  
>  /dts-v1/;
> @@ -27,20 +27,140 @@ memory at 0 {
>  		reg = <0x0 0x80000000>; /* 2GB */
>  	};
>  
> -	/* Fixed regulator used in the absence of PMIC */
> -	sd_vcc: sd-vcc {
> +	syspwr: regulator-5v0 {
>  		compatible = "regulator-fixed";
> -		regulator-name = "fixed-3.1V";
> -		regulator-min-microvolt = <3100000>;
> -		regulator-max-microvolt = <3100000>;
> +		regulator-name = "SYSPWR";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
>  		regulator-always-on;
>  	};
>  };
>  
> +&cpu0 {
> +	cpu0-supply = <&vdd_cpu>;
> +};
> +
>  &i2c0 {
>  	status = "okay";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&i2c0_pins>;
> +
> +	atc260x: pmic at 65 {
> +		compatible = "actions,atc2603c";
> +		reg = <0x65>;
> +		interrupt-parent = <&sirq>;
> +		interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
> +
> +		reset-time-sec = <6>;
> +
> +		regulators {
> +			compatible = "actions,atc2603c-regulator";
> +
> +			dcdc1-supply = <&syspwr>;
> +			dcdc2-supply = <&syspwr>;
> +			dcdc3-supply = <&syspwr>;
> +			ldo1-supply = <&syspwr>;
> +			ldo2-supply = <&syspwr>;
> +			ldo3-supply = <&syspwr>;
> +			ldo5-supply = <&syspwr>;
> +			ldo6-supply = <&syspwr>;
> +			ldo7-supply = <&syspwr>;
> +			ldo8-supply = <&syspwr>;
> +			ldo11-supply = <&syspwr>;
> +			ldo12-supply = <&syspwr>;
> +			switchldo1-supply = <&vcc>;
> +
> +			vdd_cpu: dcdc1 {
> +				regulator-name = "VDD_CPU";
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1400000>;
> +				regulator-always-on;
> +			};
> +
> +			vddq: dcdc2 {
> +				regulator-name = "VDDQ";
> +				regulator-min-microvolt = <1300000>;
> +				regulator-max-microvolt = <2150000>;
> +				regulator-always-on;
> +				regulator-boot-on;
> +			};
> +
> +			vcc: dcdc3 {
> +				regulator-name = "VCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vcc_3v3: ldo1 {
> +				regulator-name = "VCC_3V3";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			avcc: ldo2 {
> +				regulator-name = "AVCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_1v8: ldo3 {
> +				regulator-name = "VDD_1V8";
> +				regulator-min-microvolt = <1500000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-always-on;
> +			};
> +
> +			vcc_3v1: ldo5 {
> +				regulator-name = "VCC_3V1";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +			};
> +
> +			avdd: ldo6 {
> +				regulator-name = "AVDD";
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1400000>;
> +				regulator-always-on;
> +			};
> +
> +			sens_1v8: ldo7 {
> +				regulator-name = "SENS_1V8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +			};
> +
> +			ldo8: ldo8 {
> +				regulator-name = "LDO8";
> +				regulator-min-microvolt = <2300000>;
> +				regulator-max-microvolt = <3300000>;
> +			};
> +
> +			svcc: ldo11 {
> +				regulator-name = "SVCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			rtc_vdd: ldo12 {
> +				regulator-name = "RTC_VDD";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-always-on;
> +			};
> +
> +			sd_vcc: switchldo1 {
> +				regulator-name = "SD_VCC";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +				regulator-boot-on;
> +			};
> +		};
> +	};
>  };
>  
>  &i2c1 {
> -- 
> 2.30.2
> 


From andrew at aj.id.au  Thu Apr  1 06:34:04 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Thu, 01 Apr 2021 16:04:04 +1030
Subject: =?UTF-8?Q?Re:_[PATCH_v2_2/3]_drivers/tty/serial/8250:_add_DT_property_fo?=
 =?UTF-8?Q?r_aspeed_vuart_sirq_polarity?=
In-Reply-To: <YGVXuyqOyxc8kcQz@hatter.bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-3-zev@bewilderbeest.net>
 <CACPK8XdPVf1WMmo8C8RJtd-1cH5qV9odEDhDUHWRiMOk=dQNtg@mail.gmail.com>
 <YGVXuyqOyxc8kcQz@hatter.bewilderbeest.net>
Message-ID: <06aee58f-819b-4486-a5ea-22e6d45e2be5@beta.fastmail.com>



On Thu, 1 Apr 2021, at 15:48, Zev Weiss wrote:
> On Wed, Mar 31, 2021 at 11:15:44PM CDT, Joel Stanley wrote:
> >On Thu, 1 Apr 2021 at 00:57, Zev Weiss <zev at bewilderbeest.net> wrote:
> >>
> >> This provides a simple boolean to use instead of the deprecated
> >> aspeed,sirq-polarity-sense property.
> >>
> >> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> >> ---
> >>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> index c33e02cbde93..e5ef9f957f9a 100644
> >> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> @@ -482,6 +482,9 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
> >>                 of_node_put(sirq_polarity_sense_args.np);
> >>         }
> >>
> >> +       if (of_property_read_bool(np, "aspeed,sirq-active-high"))
> >> +               aspeed_vuart_set_sirq_polarity(vuart, 1);
> >
> >This assumes the default is always low, so we don't need a property to
> >set it to that state?
> >
> >Would it make more sense to have the property describe if it's high or
> >low? (I'm happy for the answer to be "no", as we've gotten by for the
> >past few years without it).
> >
> 
> Yeah, that sounds like better way to approach it -- I think I'll 
> rearrange as Andrew suggested in 
> https://lore.kernel.org/openbmc/d66753ee-7db2-41e5-9fe5-762b1ab678bc at www.fastmail.com/
> 
> >This brings up another point. We already have the sysfs file for
> >setting the lpc address, from userspace. In OpenBMC land this can be
> >set with obmc-console-client (/etc/obmc-console.conf). Should we add
> >support to that application for setting the irq polarity too, and do
> >away with device tree descriptions?
> >
> 
> I guess I might lean slightly toward keeping the DT description so that 
> if for whatever reason obmc-console-server flakes out and doesn't start 
> you're better positioned to try banging on /dev/ttyS* manually if you're 
> desperate.  Though I suppose that in turn might imply that I'm arguing 
> for adding DT properties for lpc_address and sirq too,

Why not just adopt exactly what I've done with KCS, where we have aspeed,lpc-io-reg and aspeed,lpc-interrupts?

Andrew


From mani at kernel.org  Thu Apr  1 06:43:00 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 1 Apr 2021 11:13:00 +0530
Subject: [PATCH 1/1] arm: dts: owl-s500-roseapplepi: Add ATC2603C PMIC
In-Reply-To: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
References: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210401054300.GD14052@work>

On Fri, Mar 12, 2021 at 11:49:27AM +0200, Cristian Ciocaltea wrote:
> Add device tree node for ATC2603C PMIC and remove the 'fixed-3.1V'
> dummy regulator used for the uSD supply.
> 
> Additionally, add 'SYSPWR' fixed regulator and provide cpu0 supply.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>

Applied to for-next after fixing the patch subject as below:

"ARM: dts: owl-s500-roseapplepi: Add ATC2603C PMIC"

Thanks,
Mani

> ---
> Please note the patch depends on the ATC260x PMIC support which is queued
> for merging in v5.13:
> 
> https://lore.kernel.org/lkml/cover.1611653995.git.cristian.ciocaltea at gmail.com/
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=for-mfd-next&qt=range&q=a38fd8748464831584a19438cbb3082b5a2dab15..eac013a0b7041f5cfc8feedf429a767675350102
> 
>  arch/arm/boot/dts/owl-s500-roseapplepi.dts | 132 ++++++++++++++++++++-
>  1 file changed, 126 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/owl-s500-roseapplepi.dts b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> index ff91561ca99c..b8c5db2344aa 100644
> --- a/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> +++ b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> @@ -2,7 +2,7 @@
>  /*
>   * Roseapple Pi
>   *
> - * Copyright (C) 2020 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> + * Copyright (C) 2020-2021 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
>   */
>  
>  /dts-v1/;
> @@ -27,20 +27,140 @@ memory at 0 {
>  		reg = <0x0 0x80000000>; /* 2GB */
>  	};
>  
> -	/* Fixed regulator used in the absence of PMIC */
> -	sd_vcc: sd-vcc {
> +	syspwr: regulator-5v0 {
>  		compatible = "regulator-fixed";
> -		regulator-name = "fixed-3.1V";
> -		regulator-min-microvolt = <3100000>;
> -		regulator-max-microvolt = <3100000>;
> +		regulator-name = "SYSPWR";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
>  		regulator-always-on;
>  	};
>  };
>  
> +&cpu0 {
> +	cpu0-supply = <&vdd_cpu>;
> +};
> +
>  &i2c0 {
>  	status = "okay";
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&i2c0_pins>;
> +
> +	atc260x: pmic at 65 {
> +		compatible = "actions,atc2603c";
> +		reg = <0x65>;
> +		interrupt-parent = <&sirq>;
> +		interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
> +
> +		reset-time-sec = <6>;
> +
> +		regulators {
> +			compatible = "actions,atc2603c-regulator";
> +
> +			dcdc1-supply = <&syspwr>;
> +			dcdc2-supply = <&syspwr>;
> +			dcdc3-supply = <&syspwr>;
> +			ldo1-supply = <&syspwr>;
> +			ldo2-supply = <&syspwr>;
> +			ldo3-supply = <&syspwr>;
> +			ldo5-supply = <&syspwr>;
> +			ldo6-supply = <&syspwr>;
> +			ldo7-supply = <&syspwr>;
> +			ldo8-supply = <&syspwr>;
> +			ldo11-supply = <&syspwr>;
> +			ldo12-supply = <&syspwr>;
> +			switchldo1-supply = <&vcc>;
> +
> +			vdd_cpu: dcdc1 {
> +				regulator-name = "VDD_CPU";
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1400000>;
> +				regulator-always-on;
> +			};
> +
> +			vddq: dcdc2 {
> +				regulator-name = "VDDQ";
> +				regulator-min-microvolt = <1300000>;
> +				regulator-max-microvolt = <2150000>;
> +				regulator-always-on;
> +				regulator-boot-on;
> +			};
> +
> +			vcc: dcdc3 {
> +				regulator-name = "VCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vcc_3v3: ldo1 {
> +				regulator-name = "VCC_3V3";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			avcc: ldo2 {
> +				regulator-name = "AVCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_1v8: ldo3 {
> +				regulator-name = "VDD_1V8";
> +				regulator-min-microvolt = <1500000>;
> +				regulator-max-microvolt = <2000000>;
> +				regulator-always-on;
> +			};
> +
> +			vcc_3v1: ldo5 {
> +				regulator-name = "VCC_3V1";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +			};
> +
> +			avdd: ldo6 {
> +				regulator-name = "AVDD";
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1400000>;
> +				regulator-always-on;
> +			};
> +
> +			sens_1v8: ldo7 {
> +				regulator-name = "SENS_1V8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +			};
> +
> +			ldo8: ldo8 {
> +				regulator-name = "LDO8";
> +				regulator-min-microvolt = <2300000>;
> +				regulator-max-microvolt = <3300000>;
> +			};
> +
> +			svcc: ldo11 {
> +				regulator-name = "SVCC";
> +				regulator-min-microvolt = <2600000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			rtc_vdd: ldo12 {
> +				regulator-name = "RTC_VDD";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-always-on;
> +			};
> +
> +			sd_vcc: switchldo1 {
> +				regulator-name = "SD_VCC";
> +				regulator-min-microvolt = <3000000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +				regulator-boot-on;
> +			};
> +		};
> +	};
>  };
>  
>  &i2c1 {
> -- 
> 2.30.2
> 


From vee.khee.wong at linux.intel.com  Thu Apr  1 07:02:50 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Thu,  1 Apr 2021 14:02:50 +0800
Subject: [PATCH net-next 1/1] stmmac: intel: use managed PCI function on probe
 and resume
Message-ID: <20210401060250.24109-1-vee.khee.wong@linux.intel.com>

Update dwmac-intel to use managed function, i.e. pcim_enable_device().

This will allow devres framework to call resource free function for us.

Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 3d9a57043af2..add95e20548d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -924,7 +924,7 @@ static int intel_eth_pci_probe(struct pci_dev *pdev,
 		return -ENOMEM;
 
 	/* Enable pci device */
-	ret = pci_enable_device(pdev);
+	ret = pcim_enable_device(pdev);
 	if (ret) {
 		dev_err(&pdev->dev, "%s: ERROR: failed to enable device\n",
 			__func__);
@@ -1006,13 +1006,9 @@ static void intel_eth_pci_remove(struct pci_dev *pdev)
 
 	stmmac_dvr_remove(&pdev->dev);
 
-	pci_free_irq_vectors(pdev);
-
 	clk_unregister_fixed_rate(priv->plat->stmmac_clk);
 
 	pcim_iounmap_regions(pdev, BIT(0));
-
-	pci_disable_device(pdev);
 }
 
 static int __maybe_unused intel_eth_pci_suspend(struct device *dev)
@@ -1028,7 +1024,6 @@ static int __maybe_unused intel_eth_pci_suspend(struct device *dev)
 	if (ret)
 		return ret;
 
-	pci_disable_device(pdev);
 	pci_wake_from_d3(pdev, true);
 	return 0;
 }
@@ -1041,7 +1036,7 @@ static int __maybe_unused intel_eth_pci_resume(struct device *dev)
 	pci_restore_state(pdev);
 	pci_set_power_state(pdev, PCI_D0);
 
-	ret = pci_enable_device(pdev);
+	ret = pcim_enable_device(pdev);
 	if (ret)
 		return ret;
 
-- 
2.25.1



From vee.khee.wong at linux.intel.com  Thu Apr  1 07:06:28 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Thu,  1 Apr 2021 14:06:28 +0800
Subject: [PATCH net-next 1/1] net: stmmac: remove unnecessary pci_enable_msi()
 call
Message-ID: <20210401060628.27339-1-vee.khee.wong@linux.intel.com>

The commit d2a029bde37b ("stmmac: pci: add MSI support for Intel Quark
X1000") introduced a pci_enable_msi() call in stmmac_pci.c.

With the commit 58da0cfa6cf1 ("net: stmmac: create dwmac-intel.c to
contain all Intel platform"), Intel Quark platform related codes
have been moved to the newly created driver.

Removing this unnecessary pci_enable_msi() call as there are no other
devices that uses stmmac-pci and need MSI to be enabled.

Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 272cb47af9f2..95e0e4d6f74d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -198,8 +198,6 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
 	if (ret)
 		return ret;
 
-	pci_enable_msi(pdev);
-
 	memset(&res, 0, sizeof(res));
 	res.addr = pcim_iomap_table(pdev)[i];
 	res.wol_irq = pdev->irq;
-- 
2.25.1



From dmugil2000 at gmail.com  Thu Apr  1 07:25:17 2021
From: dmugil2000 at gmail.com (Mugilraj Dhavachelvan)
Date: Thu,  1 Apr 2021 11:55:17 +0530
Subject: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
Message-ID: <20210401062517.28832-1-dmugil2000@gmail.com>

Change function's name to %s and __func__ to fix checkpatch.pl errors.

Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com>
---
 drivers/iio/adc/bcm_iproc_adc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 5e396104ac86..6bffda1082a2 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -170,8 +170,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
 	adc_priv = iio_priv(indio_dev);
 
 	regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, &intr_status);
-	dev_dbg(&indio_dev->dev, "iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
-			intr_status);
+	dev_dbg(&indio_dev->dev, "%s,INTRPT_STS:%x\n", __func__, intr_status);
 
 	intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
 	if (intr_channels) {
-- 
2.25.1



From vigneshr at ti.com  Thu Apr  1 07:28:53 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Thu, 1 Apr 2021 11:58:53 +0530
Subject: [PATCH 1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
In-Reply-To: <20210326130034.15231-2-p.yadav@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
 <20210326130034.15231-2-p.yadav@ti.com>
Message-ID: <18b87b48-84b0-bae6-c5c3-6e849282302b@ti.com>



On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
> ---

Reviewed-by: Vignesh Raghavendra <vigneshr at ti.com>

>  arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 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 6c44afae9187..d56e3475aee7 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -180,7 +180,7 @@ fss: fss at 47000000 {
>  		ranges;
>  
>  		ospi0: spi at 47040000 {
> -			compatible = "ti,am654-ospi";
> +			compatible = "ti,am654-ospi", "cdns,qspi-nor";
>  			reg = <0x0 0x47040000 0x0 0x100>,
>  				<0x5 0x00000000 0x1 0x0000000>;
>  			interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
> @@ -197,7 +197,7 @@ ospi0: spi at 47040000 {
>  		};
>  
>  		ospi1: spi at 47050000 {
> -			compatible = "ti,am654-ospi";
> +			compatible = "ti,am654-ospi", "cdns,qspi-nor";
>  			reg = <0x0 0x47050000 0x0 0x100>,
>  				<0x7 0x00000000 0x1 0x00000000>;
>  			interrupts = <GIC_SPI 841 IRQ_TYPE_LEVEL_HIGH>;
> 


From vigneshr at ti.com  Thu Apr  1 07:28:59 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Thu, 1 Apr 2021 11:58:59 +0530
Subject: [PATCH 2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
In-Reply-To: <20210326130034.15231-3-p.yadav@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
 <20210326130034.15231-3-p.yadav@ti.com>
Message-ID: <9e63fa94-d313-b8f3-8cb9-3ca8fe6b4e16@ti.com>



On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
> ---

Reviewed-by: Vignesh Raghavendra <vigneshr at ti.com>

>  arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 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 5408ec815d58..2ab5a7a15bd5 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> @@ -271,7 +271,7 @@ hbmc: hyperbus at 47034000 {
>  		};
>  
>  		ospi0: spi at 47040000 {
> -			compatible = "ti,am654-ospi";
> +			compatible = "ti,am654-ospi", "cdns,qspi-nor";
>  			reg = <0x0 0x47040000 0x0 0x100>,
>  			      <0x5 0x00000000 0x1 0x0000000>;
>  			interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
> 


From vigneshr at ti.com  Thu Apr  1 07:29:21 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Thu, 1 Apr 2021 11:59:21 +0530
Subject: [PATCH 3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible
In-Reply-To: <20210326130034.15231-4-p.yadav@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
 <20210326130034.15231-4-p.yadav@ti.com>
Message-ID: <7c1d9ee8-ff31-31c9-d113-e16babaf464d@ti.com>



On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
> 
> Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
> ---

Reviewed-by: Vignesh Raghavendra <vigneshr at ti.com>

>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index b997d13f9ec5..3cbdd33384a0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -592,7 +592,7 @@ fss: bus at fc00000 {
>  		ranges;
>  
>  		ospi0: spi at fc40000 {
> -			compatible = "ti,am654-ospi";
> +			compatible = "ti,am654-ospi", "cdns,qspi-nor";
>  			reg = <0x00 0x0fc40000 0x00 0x100>,
>  			      <0x05 0x00000000 0x01 0x00000000>;
>  			interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> 


From keescook at chromium.org  Thu Apr  1 07:31:39 2021
From: keescook at chromium.org (Kees Cook)
Date: Wed, 31 Mar 2021 23:31:39 -0700
Subject: [PATCH v8 3/6] stack: Optionally randomize kernel stack offset
 each syscall
In-Reply-To: <87v9973q54.ffs@nanos.tec.linutronix.de>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210330205750.428816-4-keescook@chromium.org>
 <87im5769op.ffs@nanos.tec.linutronix.de>
 <202103311453.A840B7FC5@keescook>
 <87v9973q54.ffs@nanos.tec.linutronix.de>
Message-ID: <202103312329.394CCA13CF@keescook>

On Thu, Apr 01, 2021 at 12:38:31AM +0200, Thomas Gleixner wrote:
> On Wed, Mar 31 2021 at 14:54, Kees Cook wrote:
> > On Wed, Mar 31, 2021 at 09:53:26AM +0200, Thomas Gleixner wrote:
> >> On Tue, Mar 30 2021 at 13:57, Kees Cook wrote:
> >> > +/*
> >> > + * Do not use this anywhere else in the kernel. This is used here because
> >> > + * it provides an arch-agnostic way to grow the stack with correct
> >> > + * alignment. Also, since this use is being explicitly masked to a max of
> >> > + * 10 bits, stack-clash style attacks are unlikely. For more details see
> >> > + * "VLAs" in Documentation/process/deprecated.rst
> >> > + * The asm statement is designed to convince the compiler to keep the
> >> > + * allocation around even after "ptr" goes out of scope.
> >> 
> >> Nit. That explanation of "ptr" might be better placed right at the
> >> add_random...() macro.
> >
> > Ah, yes! Fixed in v9.
> 
> Hmm, looking at V9 the "ptr" thing got lost ....

I put the comment inline in the macro directly above the asm().

> > Do you want to take this via -tip (and leave off the arm64 patch until
> > it is acked), or would you rather it go via arm64? (I've sent v9 now...)
> 
> Either way is fine.

Since the arm64 folks have been a bit busy, can you just put this in
-tip and leave off the arm64 patch for now?

Thanks!

-- 
Kees Cook


From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:03 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:03 +0800
Subject: [PATCH v2 2/6] soc: mediatek: devapc: move 'vio_idx_num' info to DT
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617259087-5502-2-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
The number of devices controlled by each devapc (i.e. 'vio_idx_num'
in the code) varies.
We move this info from compatible data to DT so that we do not need
to add n compatible for a certain IC which has n devapc HWs with
different 'vio_idx_num', respectively.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index f1cea04..a0f6fbd 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -32,9 +32,6 @@ struct mtk_devapc_vio_dbgs {
 };
 
 struct mtk_devapc_data {
-	/* numbers of violation index */
-	u32 vio_idx_num;
-
 	/* reg offset */
 	u32 vio_mask_offset;
 	u32 vio_sta_offset;
@@ -49,6 +46,7 @@ struct mtk_devapc_data {
 struct mtk_devapc_context {
 	struct device *dev;
 	void __iomem *infra_base;
+	u32 vio_idx_num;
 	struct clk *infra_clk;
 	const struct mtk_devapc_data *data;
 };
@@ -60,10 +58,10 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
 
 	reg = ctx->infra_base + ctx->data->vio_sta_offset;
 
-	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
 		writel(GENMASK(31, 0), reg + 4 * i);
 
-	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
+	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1), 0),
 	       reg + 4 * i);
 }
 
@@ -80,15 +78,15 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
 	else
 		val = 0;
 
-	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
 		writel(val, reg + 4 * i);
 
 	val = readl(reg + 4 * i);
 	if (mask)
-		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
 			       0);
 	else
-		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
 				0);
 
 	writel(val, reg + 4 * i);
@@ -216,7 +214,6 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
 }
 
 static const struct mtk_devapc_data devapc_mt6779 = {
-	.vio_idx_num = 511,
 	.vio_mask_offset = 0x0,
 	.vio_sta_offset = 0x400,
 	.vio_dbg0_offset = 0x900,
@@ -256,6 +253,9 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 	if (!ctx->infra_base)
 		return -EINVAL;
 
+	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
+		return -EINVAL;
+
 	devapc_irq = irq_of_parse_and_map(node, 0);
 	if (!devapc_irq)
 		return -EINVAL;
-- 
2.6.4

From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:04 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:04 +0800
Subject: [PATCH v2 3/6] soc: mediatek: devapc: add shared flag to IRQ
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617259087-5502-3-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
They all share the same IRQ number.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index a0f6fbd..68c3e35 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -268,7 +268,7 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 		return -EINVAL;
 
 	ret = devm_request_irq(&pdev->dev, devapc_irq, devapc_violation_irq,
-			       IRQF_TRIGGER_NONE, "devapc", ctx);
+			       IRQF_TRIGGER_NONE | IRQF_SHARED, "devapc", ctx);
 	if (ret) {
 		clk_disable_unprepare(ctx->infra_clk);
 		return ret;
-- 
2.6.4

From anshuman.khandual at arm.com  Thu Apr  1 07:44:03 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:03 +0530
Subject: [PATCH V2 1/6] mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-2-git-send-email-anshuman.khandual@arm.com>

ARCH_HAS_CACHE_LINE_SIZE config has duplicate definitions on platforms that
subscribe it. Instead, just make it a generic option which can be selected
on applicable platforms. This change reduces code duplication and makes it
cleaner.

Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: Borislav Petkov <bp at alien8.de>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: x86 at kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arc/Kconfig   | 4 +---
 arch/arm64/Kconfig | 4 +---
 arch/x86/Kconfig   | 4 +---
 mm/Kconfig         | 3 +++
 4 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index bc8d6aecfbbd..fab05f7189c0 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -6,6 +6,7 @@
 config ARC
 	def_bool y
 	select ARC_TIMERS
+	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VM_PGTABLE
 	select ARCH_HAS_DMA_PREP_COHERENT
 	select ARCH_HAS_PTE_SPECIAL
@@ -48,9 +49,6 @@ config ARC
 	select HAVE_ARCH_JUMP_LABEL if ISA_ARCV2 && !CPU_ENDIAN_BE32
 	select SET_FS
 
-config ARCH_HAS_CACHE_LINE_SIZE
-	def_bool y
-
 config TRACE_IRQFLAGS_SUPPORT
 	def_bool y
 
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..75a1af6cef9e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,7 @@ config ARM64
 	select ACPI_PPTT if ACPI
 	select ARCH_HAS_DEBUG_WX
 	select ARCH_BINFMT_ELF_STATE
+	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEBUG_VM_PGTABLE
 	select ARCH_HAS_DMA_PREP_COHERENT
@@ -1065,9 +1066,6 @@ config HW_PERF_EVENTS
 config SYS_SUPPORTS_HUGETLBFS
 	def_bool y
 
-config ARCH_HAS_CACHE_LINE_SIZE
-	def_bool y
-
 config ARCH_ENABLE_SPLIT_PMD_PTLOCK
 	def_bool y if PGTABLE_LEVELS > 2
 
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..51d171abb57a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -61,6 +61,7 @@ config X86
 	select ARCH_32BIT_OFF_T			if X86_32
 	select ARCH_CLOCKSOURCE_INIT
 	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
+	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEBUG_VM_PGTABLE	if !X86_PAE
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
@@ -313,9 +314,6 @@ config GENERIC_CALIBRATE_DELAY
 config ARCH_HAS_CPU_RELAX
 	def_bool y
 
-config ARCH_HAS_CACHE_LINE_SIZE
-	def_bool y
-
 config ARCH_HAS_FILTER_PGPROT
 	def_bool y
 
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b95..1c9a37fc651a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -760,6 +760,9 @@ config IDLE_PAGE_TRACKING
 	  See Documentation/admin-guide/mm/idle_page_tracking.rst for
 	  more details.
 
+config ARCH_HAS_CACHE_LINE_SIZE
+	bool
+
 config ARCH_HAS_PTE_DEVMAP
 	bool
 
-- 
2.20.1



From anshuman.khandual at arm.com  Thu Apr  1 07:44:04 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:04 +0530
Subject: [PATCH V2 2/6] mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as
 ARCH_SUPPORTS_HUGETLBFS)
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-3-git-send-email-anshuman.khandual@arm.com>

SYS_SUPPORTS_HUGETLBFS config has duplicate definitions on platforms that
subscribe it. Instead, just make it a generic option which can be selected
on applicable platforms. Also rename it as ARCH_SUPPORTS_HUGETLBFS instead.
This reduces code duplication and makes it cleaner.

Cc: Russell King <linux at armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Thomas Bogendoerfer <tsbogend at alpha.franken.de>
Cc: "James E.J. Bottomley" <James.Bottomley at HansenPartnership.com>
Cc: Helge Deller <deller at gmx.de>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Paul Walmsley <paul.walmsley at sifive.com>
Cc: Palmer Dabbelt <palmer at dabbelt.com>
Cc: Albert Ou <aou at eecs.berkeley.edu>
Cc: Yoshinori Sato <ysato at users.sourceforge.jp>
Cc: Rich Felker <dalias at libc.org>
Cc: Alexander Viro <viro at zeniv.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at vger.kernel.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-riscv at lists.infradead.org
Cc: linux-sh at vger.kernel.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Acked-by: Palmer Dabbelt <palmerdabbelt at google.com> (riscv)
Acked-by: Michael Ellerman <mpe at ellerman.id.au> (powerpc)
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arm/Kconfig                       | 5 +----
 arch/arm64/Kconfig                     | 4 +---
 arch/mips/Kconfig                      | 6 +-----
 arch/parisc/Kconfig                    | 5 +----
 arch/powerpc/Kconfig                   | 3 ---
 arch/powerpc/platforms/Kconfig.cputype | 6 +++---
 arch/riscv/Kconfig                     | 5 +----
 arch/sh/Kconfig                        | 5 +----
 fs/Kconfig                             | 5 ++++-
 9 files changed, 13 insertions(+), 31 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5da96f5df48f..e12d9d1f4892 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -31,6 +31,7 @@ config ARM
 	select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
 	select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
 	select ARCH_SUPPORTS_ATOMIC_RMW
+	select ARCH_SUPPORTS_HUGETLBFS if ARM_LPAE
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
@@ -1504,10 +1505,6 @@ config HW_PERF_EVENTS
 	def_bool y
 	depends on ARM_PMU
 
-config SYS_SUPPORTS_HUGETLBFS
-       def_bool y
-       depends on ARM_LPAE
-
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
        def_bool y
        depends on ARM_LPAE
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 75a1af6cef9e..c86b28ef6ac0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -72,6 +72,7 @@ config ARM64
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_USE_SYM_ANNOTATIONS
 	select ARCH_SUPPORTS_DEBUG_PAGEALLOC
+	select ARCH_SUPPORTS_HUGETLBFS
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 	select ARCH_SUPPORTS_SHADOW_CALL_STACK if CC_HAVE_SHADOW_CALL_STACK
 	select ARCH_SUPPORTS_LTO_CLANG if CPU_LITTLE_ENDIAN
@@ -1063,9 +1064,6 @@ config HW_PERF_EVENTS
 	def_bool y
 	depends on ARM_PMU
 
-config SYS_SUPPORTS_HUGETLBFS
-	def_bool y
-
 config ARCH_ENABLE_SPLIT_PMD_PTLOCK
 	def_bool y if PGTABLE_LEVELS > 2
 
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..73ea9b7558c1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -16,6 +16,7 @@ config MIPS
 	select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
+	select ARCH_SUPPORTS_HUGETLBFS if CPU_SUPPORTS_HUGEPAGES
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_WANT_LD_ORPHAN_WARN
@@ -1281,11 +1282,6 @@ config SYS_SUPPORTS_BIG_ENDIAN
 config SYS_SUPPORTS_LITTLE_ENDIAN
 	bool
 
-config SYS_SUPPORTS_HUGETLBFS
-	bool
-	depends on CPU_SUPPORTS_HUGEPAGES
-	default y
-
 config MIPS_HUGE_TLB_SUPPORT
 	def_bool HUGETLB_PAGE || TRANSPARENT_HUGEPAGE
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index afc3b8d03572..bde9907bc5b2 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -12,6 +12,7 @@ config PARISC
 	select ARCH_HAS_STRICT_KERNEL_RWX
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARCH_NO_SG_CHAIN
+	select ARCH_SUPPORTS_HUGETLBFS if PA20
 	select ARCH_SUPPORTS_MEMORY_FAILURE
 	select DMA_OPS
 	select RTC_CLASS
@@ -138,10 +139,6 @@ config PGTABLE_LEVELS
 	default 3 if 64BIT && PARISC_PAGE_SIZE_4KB
 	default 2
 
-config SYS_SUPPORTS_HUGETLBFS
-	def_bool y if PA20
-
-
 menu "Processor type and features"
 
 choice
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..a74c211e55b1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -700,9 +700,6 @@ config ARCH_SPARSEMEM_DEFAULT
 	def_bool y
 	depends on PPC_BOOK3S_64
 
-config SYS_SUPPORTS_HUGETLBFS
-	bool
-
 config ILLEGAL_POINTER_VALUE
 	hex
 	# This is roughly half way between the top of user space and the bottom
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 3ce907523b1e..cec1017813f8 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -40,8 +40,8 @@ config PPC_85xx
 
 config PPC_8xx
 	bool "Freescale 8xx"
+	select ARCH_SUPPORTS_HUGETLBFS
 	select FSL_SOC
-	select SYS_SUPPORTS_HUGETLBFS
 	select PPC_HAVE_KUEP
 	select PPC_HAVE_KUAP
 	select HAVE_ARCH_VMAP_STACK
@@ -95,9 +95,9 @@ config PPC_BOOK3S_64
 	bool "Server processors"
 	select PPC_FPU
 	select PPC_HAVE_PMU_SUPPORT
-	select SYS_SUPPORTS_HUGETLBFS
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
+	select ARCH_SUPPORTS_HUGETLBFS
 	select ARCH_SUPPORTS_NUMA_BALANCING
 	select IRQ_WORK
 	select PPC_MM_SLICES
@@ -278,9 +278,9 @@ config FSL_BOOKE
 # this is for common code between PPC32 & PPC64 FSL BOOKE
 config PPC_FSL_BOOK3E
 	bool
+	select ARCH_SUPPORTS_HUGETLBFS if PHYS_64BIT || PPC64
 	select FSL_EMB_PERFMON
 	select PPC_SMP_MUXED_IPI
-	select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT || PPC64
 	select PPC_DOORBELL
 	default y if FSL_BOOKE
 
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 87d7b52f278f..440b75adeb1c 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -30,6 +30,7 @@ config RISCV
 	select ARCH_HAS_STRICT_KERNEL_RWX if MMU
 	select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
 	select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+	select ARCH_SUPPORTS_HUGETLBFS if MMU
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
 	select ARCH_WANT_FRAME_POINTERS
 	select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
@@ -165,10 +166,6 @@ config ARCH_WANT_GENERAL_HUGETLB
 config ARCH_SUPPORTS_UPROBES
 	def_bool y
 
-config SYS_SUPPORTS_HUGETLBFS
-	depends on MMU
-	def_bool y
-
 config STACKTRACE_SUPPORT
 	def_bool y
 
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index e798e55915c2..a54b0c5de37b 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -101,9 +101,6 @@ config SYS_SUPPORTS_APM_EMULATION
 	bool
 	select ARCH_SUSPEND_POSSIBLE
 
-config SYS_SUPPORTS_HUGETLBFS
-	bool
-
 config SYS_SUPPORTS_SMP
 	bool
 
@@ -175,12 +172,12 @@ config CPU_SH3
 
 config CPU_SH4
 	bool
+	select ARCH_SUPPORTS_HUGETLBFS if MMU
 	select CPU_HAS_INTEVT
 	select CPU_HAS_SR_RB
 	select CPU_HAS_FPU if !CPU_SH4AL_DSP
 	select SH_INTC
 	select SYS_SUPPORTS_SH_TMU
-	select SYS_SUPPORTS_HUGETLBFS if MMU
 
 config CPU_SH4A
 	bool
diff --git a/fs/Kconfig b/fs/Kconfig
index a55bda4233bb..366a603ad947 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -222,10 +222,13 @@ config TMPFS_INODE64
 
 	  If unsure, say N.
 
+config ARCH_SUPPORTS_HUGETLBFS
+	def_bool n
+
 config HUGETLBFS
 	bool "HugeTLB file system support"
 	depends on X86 || IA64 || SPARC64 || (S390 && 64BIT) || \
-		   SYS_SUPPORTS_HUGETLBFS || BROKEN
+		   ARCH_SUPPORTS_HUGETLBFS || BROKEN
 	help
 	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
 	  ramfs. For architectures that support it, say Y here and read
-- 
2.20.1



From anshuman.khandual at arm.com  Thu Apr  1 07:44:05 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:05 +0530
Subject: [PATCH V2 3/6] mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-4-git-send-email-anshuman.khandual@arm.com>

ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE] configs have duplicate definitions
on platforms that subscribe them. Instead, just make them generic options
which can be selected on applicable platforms.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Heiko Carstens <hca at linux.ibm.com>
Cc: Vasily Gorbik <gor at linux.ibm.com>
Cc: Christian Borntraeger <borntraeger at de.ibm.com>
Cc: Yoshinori Sato <ysato at users.sourceforge.jp>
Cc: Rich Felker <dalias at libc.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: x86 at kernel.org
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-ia64 at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Acked-by: Heiko Carstens <hca at linux.ibm.com> (s390)
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arm64/Kconfig   |  8 ++------
 arch/ia64/Kconfig    |  8 ++------
 arch/powerpc/Kconfig |  8 ++------
 arch/s390/Kconfig    |  8 ++------
 arch/sh/Kconfig      |  2 ++
 arch/sh/mm/Kconfig   |  8 --------
 arch/x86/Kconfig     | 10 ++--------
 mm/Kconfig           |  6 ++++++
 8 files changed, 18 insertions(+), 40 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c86b28ef6ac0..48355c5519c3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,8 @@ config ARM64
 	select ACPI_PPTT if ACPI
 	select ARCH_HAS_DEBUG_WX
 	select ARCH_BINFMT_ELF_STATE
+	select ARCH_ENABLE_MEMORY_HOTPLUG
+	select ARCH_ENABLE_MEMORY_HOTREMOVE
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEBUG_VM_PGTABLE
@@ -305,12 +307,6 @@ config ZONE_DMA32
 	bool "Support DMA32 zone" if EXPERT
 	default y
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-
 config SMP
 	def_bool y
 
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 2ad7a8d29fcc..96ce53ad5c9d 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -13,6 +13,8 @@ config IA64
 	select ARCH_MIGHT_HAVE_PC_SERIO
 	select ACPI
 	select ACPI_NUMA if NUMA
+	select ARCH_ENABLE_MEMORY_HOTPLUG
+	select ARCH_ENABLE_MEMORY_HOTREMOVE
 	select ARCH_SUPPORTS_ACPI
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
 	select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
@@ -250,12 +252,6 @@ config HOTPLUG_CPU
 	  can be controlled through /sys/devices/system/cpu/cpu#.
 	  Say N if you want to disable CPU hotplug.
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-
 config SCHED_SMT
 	bool "SMT scheduler support"
 	depends on SMP
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a74c211e55b1..02a05a24659d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -118,6 +118,8 @@ config PPC
 	# Please keep this list sorted alphabetically.
 	#
 	select ARCH_32BIT_OFF_T if PPC32
+	select ARCH_ENABLE_MEMORY_HOTPLUG
+	select ARCH_ENABLE_MEMORY_HOTREMOVE
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
@@ -515,12 +517,6 @@ config ARCH_CPU_PROBE_RELEASE
 	def_bool y
 	depends on HOTPLUG_CPU
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-
 config PPC64_SUPPORTS_MEMORY_FAILURE
 	bool "Add support for memory hwpoison"
 	depends on PPC_BOOK3S_64
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c1ff874e6c2e..f8b356550daa 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -60,6 +60,8 @@ config S390
 	imply IMA_SECURE_AND_OR_TRUSTED_BOOT
 	select ARCH_32BIT_USTAT_F_TINODE
 	select ARCH_BINFMT_ELF_STATE
+	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM
+	select ARCH_ENABLE_MEMORY_HOTREMOVE
 	select ARCH_HAS_DEBUG_VM_PGTABLE
 	select ARCH_HAS_DEBUG_WX
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
@@ -626,12 +628,6 @@ config ARCH_SPARSEMEM_ENABLE
 config ARCH_SPARSEMEM_DEFAULT
 	def_bool y
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y if SPARSEMEM
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-
 config ARCH_ENABLE_SPLIT_PMD_PTLOCK
 	def_bool y
 
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index a54b0c5de37b..68129537e350 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -2,6 +2,8 @@
 config SUPERH
 	def_bool y
 	select ARCH_32BIT_OFF_T
+	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM && MMU
+	select ARCH_ENABLE_MEMORY_HOTREMOVE if SPARSEMEM && MMU
 	select ARCH_HAVE_CUSTOM_GPIO_H
 	select ARCH_HAVE_NMI_SAFE_CMPXCHG if (GUSA_RB || CPU_SH4A)
 	select ARCH_HAS_BINFMT_FLAT if !MMU
diff --git a/arch/sh/mm/Kconfig b/arch/sh/mm/Kconfig
index 77aa2f802d8d..d551a9cac41e 100644
--- a/arch/sh/mm/Kconfig
+++ b/arch/sh/mm/Kconfig
@@ -136,14 +136,6 @@ config ARCH_SPARSEMEM_DEFAULT
 config ARCH_SELECT_MEMORY_MODEL
 	def_bool y
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y
-	depends on SPARSEMEM && MMU
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-	depends on SPARSEMEM && MMU
-
 config ARCH_MEMORY_PROBE
 	def_bool y
 	depends on MEMORY_HOTPLUG
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 51d171abb57a..503d8b2e8676 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -60,6 +60,8 @@ config X86
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
 	select ARCH_32BIT_OFF_T			if X86_32
 	select ARCH_CLOCKSOURCE_INIT
+	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
+	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
 	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
@@ -2423,14 +2425,6 @@ config ARCH_HAS_ADD_PAGES
 	def_bool y
 	depends on X86_64 && ARCH_ENABLE_MEMORY_HOTPLUG
 
-config ARCH_ENABLE_MEMORY_HOTPLUG
-	def_bool y
-	depends on X86_64 || (X86_32 && HIGHMEM)
-
-config ARCH_ENABLE_MEMORY_HOTREMOVE
-	def_bool y
-	depends on MEMORY_HOTPLUG
-
 config USE_PERCPU_NUMA_NODE_ID
 	def_bool y
 	depends on NUMA
diff --git a/mm/Kconfig b/mm/Kconfig
index 1c9a37fc651a..9b58fa08847d 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -149,6 +149,9 @@ config MEMORY_ISOLATION
 config HAVE_BOOTMEM_INFO_NODE
 	def_bool n
 
+config ARCH_ENABLE_MEMORY_HOTPLUG
+	bool
+
 # eventually, we can have this option just 'select SPARSEMEM'
 config MEMORY_HOTPLUG
 	bool "Allow for memory hot-add"
@@ -177,6 +180,9 @@ config MEMORY_HOTPLUG_DEFAULT_ONLINE
 	  Say N here if you want the default policy to keep all hot-plugged
 	  memory blocks in 'offline' state.
 
+config ARCH_ENABLE_MEMORY_HOTREMOVE
+	bool
+
 config MEMORY_HOTREMOVE
 	bool "Allow for memory hot remove"
 	select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
-- 
2.20.1



From anshuman.khandual at arm.com  Thu Apr  1 07:44:06 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:06 +0530
Subject: [PATCH V2 4/6] mm: Drop redundant ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-5-git-send-email-anshuman.khandual@arm.com>

ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION configs have duplicate definitions on
platforms that subscribe them. Drop these reduntant definitions and instead
just select them appropriately.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: x86 at kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arm64/Kconfig                     | 10 ++--------
 arch/powerpc/platforms/Kconfig.cputype |  5 +----
 arch/x86/Kconfig                       | 10 ++--------
 3 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 48355c5519c3..cd012af0a4b7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,8 +11,10 @@ config ARM64
 	select ACPI_PPTT if ACPI
 	select ARCH_HAS_DEBUG_WX
 	select ARCH_BINFMT_ELF_STATE
+	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
 	select ARCH_ENABLE_MEMORY_HOTPLUG
 	select ARCH_ENABLE_MEMORY_HOTREMOVE
+	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEBUG_VM_PGTABLE
@@ -1905,14 +1907,6 @@ config SYSVIPC_COMPAT
 	def_bool y
 	depends on COMPAT && SYSVIPC
 
-config ARCH_ENABLE_HUGEPAGE_MIGRATION
-	def_bool y
-	depends on HUGETLB_PAGE && MIGRATION
-
-config ARCH_ENABLE_THP_MIGRATION
-	def_bool y
-	depends on TRANSPARENT_HUGEPAGE
-
 menu "Power management options"
 
 source "kernel/power/Kconfig"
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index cec1017813f8..4465b71b2bff 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -96,6 +96,7 @@ config PPC_BOOK3S_64
 	select PPC_FPU
 	select PPC_HAVE_PMU_SUPPORT
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE
+	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
 	select ARCH_SUPPORTS_HUGETLBFS
 	select ARCH_SUPPORTS_NUMA_BALANCING
@@ -420,10 +421,6 @@ config PPC_PKEY
 	depends on PPC_BOOK3S_64
 	depends on PPC_MEM_KEYS || PPC_KUAP || PPC_KUEP
 
-config ARCH_ENABLE_HUGEPAGE_MIGRATION
-	def_bool y
-	depends on PPC_BOOK3S_64 && HUGETLB_PAGE && MIGRATION
-
 
 config PPC_MMU_NOHASH
 	def_bool y
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 503d8b2e8676..10702ef1eb57 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -60,8 +60,10 @@ config X86
 	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
 	select ARCH_32BIT_OFF_T			if X86_32
 	select ARCH_CLOCKSOURCE_INIT
+	select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE && MIGRATION
 	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
 	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
+	select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
@@ -2433,14 +2435,6 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
 	def_bool y
 	depends on X86_64 || X86_PAE
 
-config ARCH_ENABLE_HUGEPAGE_MIGRATION
-	def_bool y
-	depends on X86_64 && HUGETLB_PAGE && MIGRATION
-
-config ARCH_ENABLE_THP_MIGRATION
-	def_bool y
-	depends on X86_64 && TRANSPARENT_HUGEPAGE
-
 menu "Power management and ACPI options"
 
 config ARCH_HIBERNATION_HEADER
-- 
2.20.1



From anshuman.khandual at arm.com  Thu Apr  1 07:44:07 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:07 +0530
Subject: [PATCH V2 5/6] mm: Drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-6-git-send-email-anshuman.khandual@arm.com>

ARCH_ENABLE_SPLIT_PMD_PTLOCKS has duplicate definitions on platforms that
subscribe it. Drop these redundant definitions and instead just select it
on applicable platforms.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Heiko Carstens <hca at linux.ibm.com>
Cc: Vasily Gorbik <gor at linux.ibm.com>
Cc: Christian Borntraeger <borntraeger at de.ibm.com>
Cc: Yoshinori Sato <ysato at users.sourceforge.jp>
Cc: Rich Felker <dalias at libc.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: x86 at kernel.org
Cc: "H. Peter Anvin" <hpa at zytor.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-ia64 at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Acked-by: Heiko Carstens <hca at linux.ibm.com> (s390)
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arm64/Kconfig                     | 4 +---
 arch/powerpc/platforms/Kconfig.cputype | 5 +----
 arch/s390/Kconfig                      | 4 +---
 arch/x86/Kconfig                       | 5 +----
 4 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index cd012af0a4b7..c1d505cad6d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -14,6 +14,7 @@ config ARM64
 	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
 	select ARCH_ENABLE_MEMORY_HOTPLUG
 	select ARCH_ENABLE_MEMORY_HOTREMOVE
+	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_DEBUG_VIRTUAL
@@ -1062,9 +1063,6 @@ config HW_PERF_EVENTS
 	def_bool y
 	depends on ARM_PMU
 
-config ARCH_ENABLE_SPLIT_PMD_PTLOCK
-	def_bool y if PGTABLE_LEVELS > 2
-
 # Supported by clang >= 7.0
 config CC_HAVE_SHADOW_CALL_STACK
 	def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 4465b71b2bff..be0e29f18dd4 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -97,6 +97,7 @@ config PPC_BOOK3S_64
 	select PPC_HAVE_PMU_SUPPORT
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE
 	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
+	select ARCH_ENABLE_PMD_SPLIT_PTLOCK
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
 	select ARCH_SUPPORTS_HUGETLBFS
 	select ARCH_SUPPORTS_NUMA_BALANCING
@@ -356,10 +357,6 @@ config SPE
 
 	  If in doubt, say Y here.
 
-config ARCH_ENABLE_SPLIT_PMD_PTLOCK
-	def_bool y
-	depends on PPC_BOOK3S_64
-
 config PPC_RADIX_MMU
 	bool "Radix MMU Support"
 	depends on PPC_BOOK3S_64
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index f8b356550daa..d72989591223 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -62,6 +62,7 @@ config S390
 	select ARCH_BINFMT_ELF_STATE
 	select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM
 	select ARCH_ENABLE_MEMORY_HOTREMOVE
+	select ARCH_ENABLE_SPLIT_PMD_PTLOCK
 	select ARCH_HAS_DEBUG_VM_PGTABLE
 	select ARCH_HAS_DEBUG_WX
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
@@ -628,9 +629,6 @@ config ARCH_SPARSEMEM_ENABLE
 config ARCH_SPARSEMEM_DEFAULT
 	def_bool y
 
-config ARCH_ENABLE_SPLIT_PMD_PTLOCK
-	def_bool y
-
 config MAX_PHYSMEM_BITS
 	int "Maximum size of supported physical memory in bits (42-53)"
 	range 42 53
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 10702ef1eb57..5dd70c798167 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -63,6 +63,7 @@ config X86
 	select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE && MIGRATION
 	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
 	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
+	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if X86_64 || X86_PAE
 	select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
 	select ARCH_HAS_CACHE_LINE_SIZE
@@ -2431,10 +2432,6 @@ config USE_PERCPU_NUMA_NODE_ID
 	def_bool y
 	depends on NUMA
 
-config ARCH_ENABLE_SPLIT_PMD_PTLOCK
-	def_bool y
-	depends on X86_64 || X86_PAE
-
 menu "Power management and ACPI options"
 
 config ARCH_HIBERNATION_HEADER
-- 
2.20.1



From anshuman.khandual at arm.com  Thu Apr  1 07:44:08 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 12:14:08 +0530
Subject: [PATCH V2 6/6] mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
In-Reply-To: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <1617259448-22529-7-git-send-email-anshuman.khandual@arm.com>

HAVE_ARCH_TRANSPARENT_HUGEPAGE has duplicate definitions on platforms that
subscribe it. Drop these reduntant definitions and instead just select it
on applicable platforms.

Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: Russell King <linux at armlinux.org.uk>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/arc/Kconfig | 5 +----
 arch/arm/Kconfig | 5 +----
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index fab05f7189c0..2d98501c0897 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -29,6 +29,7 @@ config ARC
 	select GENERIC_SMP_IDLE_THREAD
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_TRACEHOOK
+	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4
 	select HAVE_DEBUG_STACKOVERFLOW
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_FUTEX_CMPXCHG if FUTEX
@@ -84,10 +85,6 @@ config STACKTRACE_SUPPORT
 	def_bool y
 	select STACKTRACE
 
-config HAVE_ARCH_TRANSPARENT_HUGEPAGE
-	def_bool y
-	depends on ARC_MMU_V4
-
 menu "ARC Architecture Configuration"
 
 menu "ARC Platform/SoC/Board"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e12d9d1f4892..4b3b204a84bd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -77,6 +77,7 @@ config ARM
 	select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
 	select HAVE_ARCH_THREAD_STRUCT_WHITELIST
 	select HAVE_ARCH_TRACEHOOK
+	select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARM_LPAE
 	select HAVE_ARM_SMCCC if CPU_V7
 	select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
 	select HAVE_CONTEXT_TRACKING
@@ -1505,10 +1506,6 @@ config HW_PERF_EVENTS
 	def_bool y
 	depends on ARM_PMU
 
-config HAVE_ARCH_TRANSPARENT_HUGEPAGE
-       def_bool y
-       depends on ARM_LPAE
-
 config ARCH_WANT_GENERAL_HUGETLB
 	def_bool y
 
-- 
2.20.1



From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:06 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:06 +0800
Subject: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for new IC
 support
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617259087-5502-5-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

There are 3 debug info registers in new ICs while in legacy ones,
we have only 2. When dumping the debug info, we need to check first
if the 3rd debug register exists and then we can konw how to decipher
the debug info.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index bcf6e3c..af55c01 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
 			u32 addr_h:4;
 			u32 resv:4;
 		} dbg0_bits;
+
+		/* Not used, reference only */
+		struct {
+			u32 dmnid:6;
+			u32 vio_w:1;
+			u32 vio_r:1;
+			u32 addr_h:4;
+			u32 resv:20;
+		} dbg0_bits_ver2;
 	};
 
 	u32 vio_dbg1;
+	u32 vio_dbg2;
 };
 
 struct mtk_devapc_data {
@@ -37,6 +47,7 @@ struct mtk_devapc_data {
 	u32 vio_sta_offset;
 	u32 vio_dbg0_offset;
 	u32 vio_dbg1_offset;
+	u32 vio_dbg2_offset;
 	u32 apc_con_offset;
 	u32 vio_shift_sta_offset;
 	u32 vio_shift_sel_offset;
@@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
 	struct mtk_devapc_vio_dbgs vio_dbgs;
 	void __iomem *vio_dbg0_reg;
 	void __iomem *vio_dbg1_reg;
+	void __iomem *vio_dbg2_reg;
+	u32 vio_addr, bus_id;
 
 	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
 	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
+	vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
 
 	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
 	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
+	vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
+
+	if (!ctx->data->vio_dbg2_offset) {
+		/* arch version 1 */
+		bus_id = vio_dbgs.dbg0_bits.mstid;
+		vio_addr = vio_dbgs.vio_dbg1;
+	} else {
+		/* arch version 2 */
+		bus_id = vio_dbgs.vio_dbg1;
+		vio_addr = vio_dbgs.vio_dbg2;
+
+		/* To align with the bit definition of arch_ver 1 */
+		vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);
+	}
 
 	/* Print violation information */
 	if (vio_dbgs.dbg0_bits.vio_w)
@@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
 		dev_info(ctx->dev, "Read Violation\n");
 
 	dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
-		 vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
-		 vio_dbgs.vio_dbg1);
+		 bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
 }
 
 /*
-- 
2.6.4

From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:02 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:02 +0800
Subject: [PATCH v2 1/6] dt-bindings: devapc: Update bindings
Message-ID: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

To support newer hardware architecture of devapc,
update device tree bindings.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
index 31e4d3c..42b284e 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -20,11 +20,17 @@ properties:
   compatible:
     enum:
       - mediatek,mt6779-devapc
+      - mediatek,mt8192-devapc
 
   reg:
     description: The base address of devapc register bank
     maxItems: 1
 
+  vio-idx-num:
+    description: The number of the devices controlled by devapc
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maxItems: 1
+
   interrupts:
     description: A single interrupt specifier
     maxItems: 1
@@ -40,6 +46,7 @@ properties:
 required:
   - compatible
   - reg
+  - vio-idx-num
   - interrupts
   - clocks
   - clock-names
@@ -54,6 +61,7 @@ examples:
     devapc: devapc at 10207000 {
       compatible = "mediatek,mt6779-devapc";
       reg = <0x10207000 0x1000>;
+      vio-idx-num = <511>;
       interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
       clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>;
       clock-names = "devapc-infra-clock";
-- 
2.6.4

From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:05 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:05 +0800
Subject: [PATCH v2 4/6] soc: mediatek: devapc: rename variable for new IC
 support
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617259087-5502-4-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
For example, there is devapc respectively for infra, peri, peri2, etc.
So we rename the variable 'infra_base' to 'base' for code readability.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index 68c3e35..bcf6e3c 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -45,7 +45,7 @@ struct mtk_devapc_data {
 
 struct mtk_devapc_context {
 	struct device *dev;
-	void __iomem *infra_base;
+	void __iomem *base;
 	u32 vio_idx_num;
 	struct clk *infra_clk;
 	const struct mtk_devapc_data *data;
@@ -56,7 +56,7 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
 	void __iomem *reg;
 	int i;
 
-	reg = ctx->infra_base + ctx->data->vio_sta_offset;
+	reg = ctx->base + ctx->data->vio_sta_offset;
 
 	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
 		writel(GENMASK(31, 0), reg + 4 * i);
@@ -71,7 +71,7 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
 	u32 val;
 	int i;
 
-	reg = ctx->infra_base + ctx->data->vio_mask_offset;
+	reg = ctx->base + ctx->data->vio_mask_offset;
 
 	if (mask)
 		val = GENMASK(31, 0);
@@ -113,11 +113,11 @@ static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
 	int ret;
 	u32 val;
 
-	pd_vio_shift_sta_reg = ctx->infra_base +
+	pd_vio_shift_sta_reg = ctx->base +
 			       ctx->data->vio_shift_sta_offset;
-	pd_vio_shift_sel_reg = ctx->infra_base +
+	pd_vio_shift_sel_reg = ctx->base +
 			       ctx->data->vio_shift_sel_offset;
-	pd_vio_shift_con_reg = ctx->infra_base +
+	pd_vio_shift_con_reg = ctx->base +
 			       ctx->data->vio_shift_con_offset;
 
 	/* Find the minimum shift group which has violation */
@@ -159,8 +159,8 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
 	void __iomem *vio_dbg0_reg;
 	void __iomem *vio_dbg1_reg;
 
-	vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset;
-	vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset;
+	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
+	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
 
 	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
 	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
@@ -198,7 +198,7 @@ static irqreturn_t devapc_violation_irq(int irq_number, void *data)
  */
 static void start_devapc(struct mtk_devapc_context *ctx)
 {
-	writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset);
+	writel(BIT(31), ctx->base + ctx->data->apc_con_offset);
 
 	mask_module_irq(ctx, false);
 }
@@ -210,7 +210,7 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
 {
 	mask_module_irq(ctx, true);
 
-	writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset);
+	writel(BIT(2), ctx->base + ctx->data->apc_con_offset);
 }
 
 static const struct mtk_devapc_data devapc_mt6779 = {
@@ -249,8 +249,8 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 	ctx->data = of_device_get_match_data(&pdev->dev);
 	ctx->dev = &pdev->dev;
 
-	ctx->infra_base = of_iomap(node, 0);
-	if (!ctx->infra_base)
+	ctx->base = of_iomap(node, 0);
+	if (!ctx->base)
 		return -EINVAL;
 
 	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
-- 
2.6.4

From nina-cm.wu at mediatek.com  Thu Apr  1 07:38:07 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 1 Apr 2021 14:38:07 +0800
Subject: [PATCH v2 6/6] soc: mediatek: devapc: support mt8192
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617259087-5502-6-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

Add compatible to support mt8192.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index af55c01..a5c15b5 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -251,11 +251,26 @@ static const struct mtk_devapc_data devapc_mt6779 = {
 	.vio_shift_con_offset = 0xF20,
 };
 
+static const struct mtk_devapc_data devapc_mt8192 = {
+	.vio_mask_offset = 0x0,
+	.vio_sta_offset = 0x400,
+	.vio_dbg0_offset = 0x900,
+	.vio_dbg1_offset = 0x904,
+	.vio_dbg2_offset = 0x908,
+	.apc_con_offset = 0xF00,
+	.vio_shift_sta_offset = 0xF20,
+	.vio_shift_sel_offset = 0xF30,
+	.vio_shift_con_offset = 0xF10,
+};
+
 static const struct of_device_id mtk_devapc_dt_match[] = {
 	{
 		.compatible = "mediatek,mt6779-devapc",
 		.data = &devapc_mt6779,
 	}, {
+		.compatible = "mediatek,mt8192-devapc",
+		.data = &devapc_mt8192,
+	}, {
 	},
 };
 
-- 
2.6.4

From zweiss at equinix.com  Thu Apr  1 08:24:05 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Thu, 1 Apr 2021 07:24:05 +0000
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <20210319061952.145040-1-andrew@aj.id.au>
References: <20210319061952.145040-1-andrew@aj.id.au>
Message-ID: <YGV1FIKVX/4hxt1U@packtop>

On Fri, Mar 19, 2021 at 01:19:30AM CDT, Andrew Jeffery wrote:
>Hello,
>
>This series is a bit of a mix of things, but its primary purpose is to
>expose BMC KCS IPMI devices to userspace in a way that enables userspace
>to talk to host firmware using protocols that are not IPMI.
>
>v1 can be found here:
>
>https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew at aj.id.au/
>
>Changes in v2 include:
>
>* A rebase onto v5.12-rc2
>* Incorporation of off-list feedback on SerIRQ configuration from
>  Chiawei
>* Further validation on hardware for ASPEED KCS devices 2, 3 and 4
>* Lifting the existing single-open constraint of the IPMI chardev
>* Fixes addressing Rob's feedback on the conversion of the ASPEED KCS
>  binding to dt-schema
>* Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts
>  property definition for the ASPEED KCS binding
>
>A new chardev device is added whose implementation exposes the Input
>Data Register (IDR), Output Data Register (ODR) and Status Register
>(STR) via read() and write(), and implements poll() for event
>monitoring.
>
>The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in
>a way which encoded the IPMI protocol in its behaviour. However, as
>LPC[0] KCS devices give us bi-directional interrupts between the host
>and a BMC with both a data and status byte, they are useful for purposes
>beyond IPMI.
>
>As a concrete example, libmctp[1] implements a vendor-defined MCTP[2]
>binding using a combination of LPC Firmware cycles for bulk data
>transfer and a KCS device via LPC IO cycles for out-of-band protocol
>control messages[3]. This gives a throughput improvement over the
>standard KCS binding[4] while continuing to exploit the ease of setup of
>the LPC bus for early boot firmware on the host processor.
>
>The series takes a bit of a winding path to achieve its aim:
>
>1. It begins with patches 1-5 put together by Chia-Wei, which I've
>rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
>non-KCS LPC-related ASPEED device drivers in a way that enables the
>SerIRQ patches at the end of the series. With Joel's review I'm hoping
>these 5 can go through the aspeed tree, and that the rest can go through
>the IPMI tree.
>
>2. Next, patches 6-13 fairly heavily refactor the KCS support in the
>IPMI part of the tree, re-architecting things such that it's possible to
>support multiple chardev implementations sitting on top of the ASPEED
>and Nuvoton device drivers. However, the KCS code didn't really have
>great separation of concerns as it stood, so even if we disregard the
>multiple-chardev support I think the cleanups are worthwhile.
>
>3. Patch 14 adds some interrupt management capabilities to the KCS
>device drivers in preparation for patch 16, which introduces the new
>"raw" KCS device interface. I'm not stoked about the device name/path,
>so if people are looking to bikeshed something then feel free to lay
>into that.
>
>4. The remaining patches switch the ASPEED KCS devicetree binding to
>dt-schema, add a new interrupt property to describe the SerIRQ behaviour
>of the device and finally clean up Serial IRQ support in the ASPEED KCS
>driver.
>
>Rob: The dt-binding patches still come before the relevant driver
>changes, I tried to keep the two close together in the series, hence the
>bindings changes not being patches 1 and 2.
>
>I've exercised the series under qemu with the rainier-bmc machine plus
>additional patches for KCS support[5]. I've also substituted this series in
>place of a hacky out-of-tree driver that we've been using for the
>libmctp stack and successfully booted the host processor under our
>internal full-platform simulation tools for a Rainier system.
>
>Note that this work touches the Nuvoton driver as well as ASPEED's, but
>I don't have the capability to test those changes or the IPMI chardev
>path. Tested-by tags would be much appreciated if you can exercise one
>or both.
>
>Please review!
>
>Andrew
>

After rebasing the series onto the OpenBMC dev-5.10 kernel (with only a
tiny conflict for the addition of the ast2600 entry in
ast_kcs_bmc_match) and enabling CONFIG_IPMI_KCS_BMC_CDEV_IPMI, my
e3c246d4i system booted healthily and handled some basic ipmitool
operations as expected.

Tested-by: Zev Weiss <zweiss at equinix.com>


Zev



From zev at bewilderbeest.net  Thu Apr  1 08:36:11 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu, 1 Apr 2021 02:36:11 -0500
Subject: [PATCH v2 2/3] drivers/tty/serial/8250: add DT property for
 aspeed vuart sirq polarity
In-Reply-To: <06aee58f-819b-4486-a5ea-22e6d45e2be5@beta.fastmail.com>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-3-zev@bewilderbeest.net>
 <CACPK8XdPVf1WMmo8C8RJtd-1cH5qV9odEDhDUHWRiMOk=dQNtg@mail.gmail.com>
 <YGVXuyqOyxc8kcQz@hatter.bewilderbeest.net>
 <06aee58f-819b-4486-a5ea-22e6d45e2be5@beta.fastmail.com>
Message-ID: <YGV368K00FHSj5aY@hatter.bewilderbeest.net>

On Thu, Apr 01, 2021 at 12:34:04AM CDT, Andrew Jeffery wrote:
>
>
>On Thu, 1 Apr 2021, at 15:48, Zev Weiss wrote:
>> On Wed, Mar 31, 2021 at 11:15:44PM CDT, Joel Stanley wrote:
>> >On Thu, 1 Apr 2021 at 00:57, Zev Weiss <zev at bewilderbeest.net> wrote:
>> >>
>> >> This provides a simple boolean to use instead of the deprecated
>> >> aspeed,sirq-polarity-sense property.
>> >>
>> >> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> >> ---
>> >>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> >> index c33e02cbde93..e5ef9f957f9a 100644
>> >> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> >> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> >> @@ -482,6 +482,9 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>> >>                 of_node_put(sirq_polarity_sense_args.np);
>> >>         }
>> >>
>> >> +       if (of_property_read_bool(np, "aspeed,sirq-active-high"))
>> >> +               aspeed_vuart_set_sirq_polarity(vuart, 1);
>> >
>> >This assumes the default is always low, so we don't need a property to
>> >set it to that state?
>> >
>> >Would it make more sense to have the property describe if it's high or
>> >low? (I'm happy for the answer to be "no", as we've gotten by for the
>> >past few years without it).
>> >
>>
>> Yeah, that sounds like better way to approach it -- I think I'll
>> rearrange as Andrew suggested in
>> https://lore.kernel.org/openbmc/d66753ee-7db2-41e5-9fe5-762b1ab678bc at www.fastmail.com/
>>
>> >This brings up another point. We already have the sysfs file for
>> >setting the lpc address, from userspace. In OpenBMC land this can be
>> >set with obmc-console-client (/etc/obmc-console.conf). Should we add
>> >support to that application for setting the irq polarity too, and do
>> >away with device tree descriptions?
>> >
>>
>> I guess I might lean slightly toward keeping the DT description so that
>> if for whatever reason obmc-console-server flakes out and doesn't start
>> you're better positioned to try banging on /dev/ttyS* manually if you're
>> desperate.  Though I suppose that in turn might imply that I'm arguing
>> for adding DT properties for lpc_address and sirq too,
>
>Why not just adopt exactly what I've done with KCS, where we have aspeed,lpc-io-reg and aspeed,lpc-interrupts?
>
>Andrew

Ah -- yes, that does sound like a sensible approach.  I'll send a v3 
with that worked in.


Zev



From adrian.hunter at intel.com  Thu Apr  1 08:45:10 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Thu, 1 Apr 2021 10:45:10 +0300
Subject: [PATCH v14 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <dbac8ce8-83c6-49a5-9f4d-f5ea19d7a883@codeaurora.org>
References: <cover.1617143113.git.asutoshd@codeaurora.org>
 <16f1bcf76ff411c70fe0e3e13f84e4b0fa7d9063.1617143113.git.asutoshd@codeaurora.org>
 <a385141d-324b-680e-a19c-ab6121bd6c5d@intel.com>
 <dbac8ce8-83c6-49a5-9f4d-f5ea19d7a883@codeaurora.org>
Message-ID: <612d0f35-89a2-947b-9fa4-608624c4c032@intel.com>

On 1/04/21 4:40 am, Asutosh Das (asd) wrote:
> On 3/31/2021 11:19 AM, Adrian Hunter wrote:
>> On 31/03/21 1:31 am, Asutosh Das wrote:
>>> During runtime-suspend of ufs host, the scsi devices are
>>> already suspended and so are the queues associated with them.
>>> But the ufs host sends SSU (START_STOP_UNIT) to wlun
>>> during its runtime-suspend.
>>> During the process blk_queue_enter checks if the queue is not in
>>> suspended state. If so, it waits for the queue to resume, and never
>>> comes out of it.
>>> The commit
>>> (d55d15a33: scsi: block: Do not accept any requests while suspended)
>>> adds the check if the queue is in suspended state in blk_queue_enter().
>>>
>>> Call trace:
>>> ? __switch_to+0x174/0x2c4
>>> ? __schedule+0x478/0x764
>>> ? schedule+0x9c/0xe0
>>> ? blk_queue_enter+0x158/0x228
>>> ? blk_mq_alloc_request+0x40/0xa4
>>> ? blk_get_request+0x2c/0x70
>>> ? __scsi_execute+0x60/0x1c4
>>> ? ufshcd_set_dev_pwr_mode+0x124/0x1e4
>>> ? ufshcd_suspend+0x208/0x83c
>>> ? ufshcd_runtime_suspend+0x40/0x154
>>> ? ufshcd_pltfrm_runtime_suspend+0x14/0x20
>>> ? pm_generic_runtime_suspend+0x28/0x3c
>>> ? __rpm_callback+0x80/0x2a4
>>> ? rpm_suspend+0x308/0x614
>>> ? rpm_idle+0x158/0x228
>>> ? pm_runtime_work+0x84/0xac
>>> ? process_one_work+0x1f0/0x470
>>> ? worker_thread+0x26c/0x4c8
>>> ? kthread+0x13c/0x320
>>> ? ret_from_fork+0x10/0x18
>>>
>>> Fix this by registering ufs device wlun as a scsi driver and
>>> registering it for block runtime-pm. Also make this as a
>>> supplier for all other luns. That way, this device wlun
>>> suspends after all the consumers and resumes after
>>> hba resumes.
>>>
>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>> ---
>>
> Hi Adrian
> Thanks for the comments.
>> Looks good but still doesn't seem to based on the latest tree.
>>
> Umm, it's based on the below:
> git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
> Branch: refs/heads/for-next
> 
> The top most change is e27f3c8 on 27th March'21.
> Which tree are you referring to that'd be latest?

Dunno, but that seems to be missing:

  commit aa53f580e67b49ec5f4d9bd1de81eb9eb0dc079f
  Author: Can Guo <cang at codeaurora.org>
  Date:   Tue Feb 23 21:36:47 2021 -0800

    scsi: ufs: Minor adjustments to error handling

which is in v5.12-rc3

> 
>> Also came across the issue below:
>>
>> <SNIP>
>>
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int ufshcd_wl_poweroff(struct device *dev)
>>> +{
>>> +??? ufshcd_wl_shutdown(dev);
>>
>> This turned out to be wrong.? This is a PM op and SCSI has already
>> quiesced the sdev's.? All that is needed isOk. I'll fix it in the next version.
> 
>>
>> ????__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
>>
>>> +??? return 0;
>>> +}
>>> +#endif
> 
> 



From o.rempel at pengutronix.de  Thu Apr  1 08:47:51 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 1 Apr 2021 09:47:51 +0200
Subject: [PATCH net-next v1 3/3] net: fec: add basic selftest support
In-Reply-To: <YGRqpxefTxZjqp6w@lunn.ch>
References: <20210330135407.17010-1-o.rempel@pengutronix.de>
 <20210330135407.17010-4-o.rempel@pengutronix.de>
 <YGRqpxefTxZjqp6w@lunn.ch>
Message-ID: <20210401074751.so4m7k3pnhcjeofx@pengutronix.de>

On Wed, Mar 31, 2021 at 02:27:19PM +0200, Andrew Lunn wrote:
> On Tue, Mar 30, 2021 at 03:54:07PM +0200, Oleksij Rempel wrote:
> > Port some parts of the stmmac selftest to the FEC. This patch was tested
> > on iMX6DL.
> > With this tests it is possible to detect some basic issues like:
> > - MAC loopback fail: most probably wrong clock configuration.
> > - PHY loopback fail: incorrect RGMII timings, damaged traces, etc
> 
> Hi
> 
> Oleksij
> 
> I've not done a side-by-side diff with stmmac, but i guess a lot of
> this code is identical?

ack

> Rather than make a copy/paste, could you move
> it somewhere under net and turn it into a library any driver can use?

yes, I assume, it is possible to make this code complete generic for all
devices, but we will need to provide some more call backs. For example
enable MAC loop back, enable DSA loopbacks and so on.

Do you have ideas for the new location of generic selftest code and
where  can be added loopback options for different levels?

Regards,
Oleksij
-- 
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 dan.carpenter at oracle.com  Thu Apr  1 08:49:05 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 1 Apr 2021 10:49:05 +0300
Subject: [PATCH -next] i2c: gpio: use DEFINE_SPINLOCK() for spinlock
In-Reply-To: <fec9295e-c5d6-13ee-23f5-13b593d2fd2e@huawei.com>
References: <20210327095228.105123-1-chenlifu@huawei.com>
 <fec9295e-c5d6-13ee-23f5-13b593d2fd2e@huawei.com>
Message-ID: <20210401074905.GQ2065@kadam>

On Thu, Apr 01, 2021 at 11:38:30AM +0800, chenlifu wrote:
> Kindly pinging ...
> 
> Best Regards,
> Chen Lifu
> 
> ? 2021/3/27 17:52, Chen Lifu ??:

It's to early to start asking for a response.  Please wait at least two
weeks.  (Probably four weeks if the merge window was open).

regards,
dan carpenter




From alexandre.torgue at foss.st.com  Thu Apr  1 08:59:57 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 1 Apr 2021 09:59:57 +0200
Subject: [PATCH v9 0/6] ARM: STM32: add art-pi(stm32h750xbh6) board support
In-Reply-To: <1617179325-6383-1-git-send-email-dillon.minfei@gmail.com>
References: <1617179325-6383-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <50cee64f-a264-4073-bafa-1e6775608169@foss.st.com>

Hi Dillon

On 3/31/21 10:28 AM, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> This patchset intend to add art-pi board support, this board developed
> by rt-thread(https://www.rt-thread.org/).
> 
> Board resources:
> 8MiB QSPI flash
> 16MiB SPI flash
> 32MiB SDRAM
> AP6212 wifi,bt,fm comb
> 
> sw context:
> - as stm32h750 just has 128k bytes internal flash, so running a fw on
>    internal flash to download u-boot/kernel to qspi flash, boot
>    u-boot/kernel from qspi flash. this fw is based on rt-thread.
> - kernel can be xip on qspi flash or load to sdram
> - root filesystem is jffs2(created by buildroot), stored on spi flash
> 
> to support the boad, add following changes.
> - fix r0-r3, r12 register restore failed after svc call,
> - add dts binding
> - update yaml doc
> 

Thanks for adding this new STM32 MCU board. Series applied on 
stm32-next. As discussed I made some changes applying the series.

Regards
Alex



> ---
> changes in v9:
> - move gpio{a..k} entries from stm32h7-pinctrl.dtsi to stm32h743.dtsi
> v8 link:
> https://lore.kernel.org/lkml/1617094704-10040-1-git-send-email-dillon.minfei at gmail.com/
> 
> changes in v8:
> - drop '[PATCH v7 3/6] ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to
>    support stm32h750' - stm32h743-pinctrl.dtsi file
> - move compatible string "st,stm32h743-pinctrl" from stm32h7-pinctrl.dtsi
>    to stm32h743.dtsi
> - update stm32h743i-{dico/eval}.dtsi to include stm32h7-pinctrl.dtsi
> - move file stm32h743.dtsi submit position to [PATCH V8 3/6]
> v7 link:
> https://lore.kernel.org/lkml/1617071338-9436-1-git-send-email-dillon.minfei at gmail.com/
> 
> changes in v7:
> - remove changes in
>    Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
>    Hi Rob Herring
>    as you has already ack this patch, please ignore it. thanks
>    history link:
>    https://lore.kernel.org/lkml/1614758717-18223-4-git-send-email-dillon.minfei at gmail.com/
>    https://lore.kernel.org/lkml/20210308195033.GA2855292 at robh.at.kernel.org/
> - remove "[PATCH v6 8/9] pinctrl: stm32: Add STM32H750 MCU pinctrl support"
>    remove "[PATCH v6 5/9] ARM: dts: stm32: add stm32h750-pinctrl.dtsi"
> - reference to stm32h743-pinctrl.dtsi in stm32h750i-art-pi.dts
> v6 link:
> https://lore.kernel.org/lkml/1616757302-7889-1-git-send-email-dillon.minfei at gmail.com/
> 
> changes in v6:
> - add gpiox{gpio-ranges, ngpios} in stm32h7-pinctrl.dtsi
> - add status="disabled" in stm32h743.dtsi
> 
> changes in v5:
> - accroding to rob's suggestion, replace false with 'type: object'
>    of 'additionalProperties'.
> - add Tested-by: Valentin Caron <valentin.caron at foss.st.com>
> 
> changes in v4:
> - use unevaluatedProperties: false to fix dtbs_check warrnings instead of
>    add 'bluetooth' in st,stm32-uart.yaml
> 
> changes in v3:
> - fix dtbs_check warrning: (8002cbd78fd5 and 4bc21d3dd678)
>    >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: pin-controller:
>       {'type': 'object'} is not allowed for {'#address-cells': [[1]], '#size-cells':
>       [[1]], 'ranges': [[0,
> 
>    >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: 'i2c at 40005C00',
>       'i2c at 58001C00' do not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$',
>       '^[^@]+$', 'pinctrl-[0-9]+'
>    >> arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial at 40004800:
>       'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+'
> 
> changes in v2:
> - reorganize the pinctrl device tree about
>    stm32h7-pinctrl/stm32h743/750-pinctrl
>    stm32h7-pinctrl.dtsi --> stm32h743-pinctrl.dtsi --> stm32h743i-disco.dts
>                           |                          |-> stm32h743i-eval.dts
>                           |-> stm32h750-pinctrl.dtsi --> stm32h750i-art-pi.dts
>    same to the stm32f7/f4's pinctrl style
> - fix author name/copyright mistake
> - add compatible string st,stm32h750-pinctrl to pinctl-stm32h743.c as they
>    have same pin alternate functions, update Kconfig description
> - make item in stm32h750i-art-pi.dts sort by letter
> 
> *** BLURB HERE ***
> 
> dillon min (6):
>    Documentation: arm: stm32: Add stm32h750 value line doc
>    dt-bindings: arm: stm32: Add compatible strings for ART-PI board
>    ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750
>    ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6
>    ARM: stm32: Add a new SOC - STM32H750
>    dt-bindings: serial: stm32: Use 'type: object' instead of false for
>      'additionalProperties'
> 
>   Documentation/arm/index.rst                        |   1 +
>   Documentation/arm/stm32/stm32h750-overview.rst     |  34 +++
>   .../devicetree/bindings/arm/stm32/stm32.yaml       |   4 +
>   .../devicetree/bindings/serial/st,stm32-uart.yaml  |   3 +-
>   arch/arm/boot/dts/Makefile                         |   1 +
>   arch/arm/boot/dts/stm32h7-pinctrl.dtsi             | 275 ++++++++++++++++++
>   arch/arm/boot/dts/stm32h743-pinctrl.dtsi           | 306 ---------------------
>   arch/arm/boot/dts/stm32h743.dtsi                   | 176 +++++++++++-
>   arch/arm/boot/dts/stm32h743i-disco.dts             |   2 +-
>   arch/arm/boot/dts/stm32h743i-eval.dts              |   2 +-
>   arch/arm/boot/dts/stm32h750.dtsi                   |   6 +
>   arch/arm/boot/dts/stm32h750i-art-pi.dts            | 229 +++++++++++++++
>   arch/arm/mach-stm32/board-dt.c                     |   1 +
>   13 files changed, 729 insertions(+), 311 deletions(-)
>   create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst
>   create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi
>   delete mode 100644 arch/arm/boot/dts/stm32h743-pinctrl.dtsi
>   create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
>   create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts
> 


From dillon.minfei at gmail.com  Thu Apr  1 09:08:28 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Thu, 1 Apr 2021 16:08:28 +0800
Subject: [PATCH v9 0/6] ARM: STM32: add art-pi(stm32h750xbh6) board support
In-Reply-To: <50cee64f-a264-4073-bafa-1e6775608169@foss.st.com>
References: <1617179325-6383-1-git-send-email-dillon.minfei@gmail.com>
 <50cee64f-a264-4073-bafa-1e6775608169@foss.st.com>
Message-ID: <CAL9mu0KQWLkNc8HfrsmCu7qq72txiou6N_NRBxTdoN1_XHSpKA@mail.gmail.com>

On Thu, Apr 1, 2021 at 4:00 PM Alexandre TORGUE
<alexandre.torgue at foss.st.com> wrote:
>
> Hi Dillon
>
> On 3/31/21 10:28 AM, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > This patchset intend to add art-pi board support, this board developed
> > by rt-thread(https://www.rt-thread.org/).
> >
> > Board resources:
> > 8MiB QSPI flash
> > 16MiB SPI flash
> > 32MiB SDRAM
> > AP6212 wifi,bt,fm comb
> >
> > sw context:
> > - as stm32h750 just has 128k bytes internal flash, so running a fw on
> >    internal flash to download u-boot/kernel to qspi flash, boot
> >    u-boot/kernel from qspi flash. this fw is based on rt-thread.
> > - kernel can be xip on qspi flash or load to sdram
> > - root filesystem is jffs2(created by buildroot), stored on spi flash
> >
> > to support the boad, add following changes.
> > - fix r0-r3, r12 register restore failed after svc call,
> > - add dts binding
> > - update yaml doc
> >
>
> Thanks for adding this new STM32 MCU board. Series applied on
> stm32-next. As discussed I made some changes applying the series.

Thanks for your work, just check your stm32-next tree, commit message
is more clear than my version. thanks.
Finally, you keep the stm32h750.dtsi, it's fine with me, I'll update crypto node
to this file when i get time to test.

Thanks again.

Regards
Dillon
>
> Regards
> Alex
>
>
>
> > ---
> > changes in v9:
> > - move gpio{a..k} entries from stm32h7-pinctrl.dtsi to stm32h743.dtsi
> > v8 link:
> > https://lore.kernel.org/lkml/1617094704-10040-1-git-send-email-dillon.minfei at gmail.com/
> >
> > changes in v8:
> > - drop '[PATCH v7 3/6] ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to
> >    support stm32h750' - stm32h743-pinctrl.dtsi file
> > - move compatible string "st,stm32h743-pinctrl" from stm32h7-pinctrl.dtsi
> >    to stm32h743.dtsi
> > - update stm32h743i-{dico/eval}.dtsi to include stm32h7-pinctrl.dtsi
> > - move file stm32h743.dtsi submit position to [PATCH V8 3/6]
> > v7 link:
> > https://lore.kernel.org/lkml/1617071338-9436-1-git-send-email-dillon.minfei at gmail.com/
> >
> > changes in v7:
> > - remove changes in
> >    Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
> >    Hi Rob Herring
> >    as you has already ack this patch, please ignore it. thanks
> >    history link:
> >    https://lore.kernel.org/lkml/1614758717-18223-4-git-send-email-dillon.minfei at gmail.com/
> >    https://lore.kernel.org/lkml/20210308195033.GA2855292 at robh.at.kernel.org/
> > - remove "[PATCH v6 8/9] pinctrl: stm32: Add STM32H750 MCU pinctrl support"
> >    remove "[PATCH v6 5/9] ARM: dts: stm32: add stm32h750-pinctrl.dtsi"
> > - reference to stm32h743-pinctrl.dtsi in stm32h750i-art-pi.dts
> > v6 link:
> > https://lore.kernel.org/lkml/1616757302-7889-1-git-send-email-dillon.minfei at gmail.com/
> >
> > changes in v6:
> > - add gpiox{gpio-ranges, ngpios} in stm32h7-pinctrl.dtsi
> > - add status="disabled" in stm32h743.dtsi
> >
> > changes in v5:
> > - accroding to rob's suggestion, replace false with 'type: object'
> >    of 'additionalProperties'.
> > - add Tested-by: Valentin Caron <valentin.caron at foss.st.com>
> >
> > changes in v4:
> > - use unevaluatedProperties: false to fix dtbs_check warrnings instead of
> >    add 'bluetooth' in st,stm32-uart.yaml
> >
> > changes in v3:
> > - fix dtbs_check warrning: (8002cbd78fd5 and 4bc21d3dd678)
> >    >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: pin-controller:
> >       {'type': 'object'} is not allowed for {'#address-cells': [[1]], '#size-cells':
> >       [[1]], 'ranges': [[0,
> >
> >    >> arch/arm/boot/dts/stm32h743i-eval.dt.yaml: soc: 'i2c at 40005C00',
> >       'i2c at 58001C00' do not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$',
> >       '^[^@]+$', 'pinctrl-[0-9]+'
> >    >> arch/arm/boot/dts/stm32h750i-art-pi.dt.yaml: serial at 40004800:
> >       'bluetooth' does not match any of the regexes: 'pinctrl-[0-9]+'
> >
> > changes in v2:
> > - reorganize the pinctrl device tree about
> >    stm32h7-pinctrl/stm32h743/750-pinctrl
> >    stm32h7-pinctrl.dtsi --> stm32h743-pinctrl.dtsi --> stm32h743i-disco.dts
> >                           |                          |-> stm32h743i-eval.dts
> >                           |-> stm32h750-pinctrl.dtsi --> stm32h750i-art-pi.dts
> >    same to the stm32f7/f4's pinctrl style
> > - fix author name/copyright mistake
> > - add compatible string st,stm32h750-pinctrl to pinctl-stm32h743.c as they
> >    have same pin alternate functions, update Kconfig description
> > - make item in stm32h750i-art-pi.dts sort by letter
> >
> > *** BLURB HERE ***
> >
> > dillon min (6):
> >    Documentation: arm: stm32: Add stm32h750 value line doc
> >    dt-bindings: arm: stm32: Add compatible strings for ART-PI board
> >    ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750
> >    ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6
> >    ARM: stm32: Add a new SOC - STM32H750
> >    dt-bindings: serial: stm32: Use 'type: object' instead of false for
> >      'additionalProperties'
> >
> >   Documentation/arm/index.rst                        |   1 +
> >   Documentation/arm/stm32/stm32h750-overview.rst     |  34 +++
> >   .../devicetree/bindings/arm/stm32/stm32.yaml       |   4 +
> >   .../devicetree/bindings/serial/st,stm32-uart.yaml  |   3 +-
> >   arch/arm/boot/dts/Makefile                         |   1 +
> >   arch/arm/boot/dts/stm32h7-pinctrl.dtsi             | 275 ++++++++++++++++++
> >   arch/arm/boot/dts/stm32h743-pinctrl.dtsi           | 306 ---------------------
> >   arch/arm/boot/dts/stm32h743.dtsi                   | 176 +++++++++++-
> >   arch/arm/boot/dts/stm32h743i-disco.dts             |   2 +-
> >   arch/arm/boot/dts/stm32h743i-eval.dts              |   2 +-
> >   arch/arm/boot/dts/stm32h750.dtsi                   |   6 +
> >   arch/arm/boot/dts/stm32h750i-art-pi.dts            | 229 +++++++++++++++
> >   arch/arm/mach-stm32/board-dt.c                     |   1 +
> >   13 files changed, 729 insertions(+), 311 deletions(-)
> >   create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst
> >   create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi
> >   delete mode 100644 arch/arm/boot/dts/stm32h743-pinctrl.dtsi
> >   create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
> >   create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts
> >


From maxime at cerno.tech  Thu Apr  1 09:20:06 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 1 Apr 2021 10:20:06 +0200
Subject: [PATCH 2/2] MAINTAINERS: Match on allwinner keyword
In-Reply-To: <9627361.1JYF2Y7Mv4@kista>
References: <20210331130830.64182-1-maxime@cerno.tech>
 <20210331130830.64182-2-maxime@cerno.tech>
 <9627361.1JYF2Y7Mv4@kista>
Message-ID: <20210401082006.32fbl3syqo7ufjbq@gilmour>

On Wed, Mar 31, 2021 at 09:18:36PM +0200, Jernej ?krabec wrote:
> Hi!
> 
> Dne sreda, 31. marec 2021 ob 15:08:30 CEST je Maxime Ripard napisal(a):
> > Some drivers (phy, crypto, net) folders don't have sunxi in it but
> > allwinner. Add that keyword to match on it too.
> > 
> > Signed-off-by: Maxime Ripard <maxime at cerno.tech>
> 
> Acked-by: Jernej Skrabec <jernej.skrabec at siol.net>

Applied both, 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/20210401/7ed83364/attachment.sig>

From maxime at cerno.tech  Thu Apr  1 09:22:49 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 1 Apr 2021 10:22:49 +0200
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: h6: beelink-gs1:
 Remove ext. 32 kHz osc reference
In-Reply-To: <CAJiuCcc4hs781Hz_=tehcm4S2nci8e0DEJKeUY5ck=bpcgNUbg@mail.gmail.com>
References: <20210330184218.279738-1-jernej.skrabec@siol.net>
 <CAJiuCcc4hs781Hz_=tehcm4S2nci8e0DEJKeUY5ck=bpcgNUbg@mail.gmail.com>
Message-ID: <20210401082249.cga2nxbh7rdsr5gz@gilmour>

On Wed, Mar 31, 2021 at 03:43:37PM +0200, Cl?ment P?ron wrote:
> Hi Jernej,
> 
> On Tue, 30 Mar 2021 at 20:42, Jernej Skrabec <jernej.skrabec at siol.net> wrote:
> >
> > Although every Beelink GS1 seems to have external 32768 Hz oscillator,
> > it works only on one from four tested. There are more reports of RTC
> > issues elsewhere, like Armbian forum.
> >
> > One Beelink GS1 owner read RTC osc status register on Android which
> > shipped with the box. Reported value indicated problems with external
> > oscillator.
> >
> > In order to fix RTC and related issues (HDMI-CEC and suspend/resume with
> > Crust) on all boards, switch to internal oscillator.
> >
> > Fixes: 32507b868119 ("arm64: dts: allwinner: h6: Move ext. oscillator to board DTs")
> > Signed-off-by: Jernej Skrabec <jernej.skrabec at siol.net>
> 
> Tested-by: Cl?ment P?ron <peron.clem at gmail.com>

Applied, 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/20210401/1d9ff701/attachment.sig>

From vigneshr at ti.com  Thu Apr  1 09:27:49 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Thu, 1 Apr 2021 13:57:49 +0530
Subject: [PATCH 4/4] dt-bindings: spi: Convert cadence-quadspi.txt to
 cadence-quadspi.yaml
In-Reply-To: <20210329182256.q4zhss6lezj3s44a@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
 <20210326130034.15231-5-p.yadav@ti.com>
 <20210327183628.GA345487@robh.at.kernel.org>
 <20210329182256.q4zhss6lezj3s44a@ti.com>
Message-ID: <1161dc3b-c889-c5d7-f7c8-baf5b7b79505@ti.com>



On 3/29/21 11:52 PM, Pratyush Yadav wrote:
>>> +  cdns,fifo-depth:
>>> +    description:
>>> +      Size of the data FIFO in words.
>>> +    $ref: "/schemas/types.yaml#/definitions/uint32"
>>> +    enum: [ 128, 256 ]
>>> +    default: 128
>>> +
>>> +  cdns,fifo-width:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      Bus width of the data FIFO in bytes.
>>> +    default: 4
>> I assume there's some constraints on this?
> IIUC this is a matter of how the peripheral is implemented and there are 
> no clear constraints. Different implementations can use different bus 
> widths for the SRAM bus but I don't see any mention of minimum or 
> maximum values. FWIW, all users in the kernel use a 4 byte bus.
> 

IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
wide) given this represents SRAM bus width. Binding can always be
updated if there exists an implementation with higher SRAM bus
width/fifo-width (although that's highly unlikely given there are no
such examples today).

But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
to me.

>> With that,
>>
>> Reviewed-by: Rob Herring <robh at kernel.org>
> Thanks.
> 


From will at kernel.org  Thu Apr  1 09:30:35 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 09:30:35 +0100
Subject: [PATCH v8 3/6] stack: Optionally randomize kernel stack offset
 each syscall
In-Reply-To: <20210330205750.428816-4-keescook@chromium.org>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210330205750.428816-4-keescook@chromium.org>
Message-ID: <20210401083034.GA8554@willie-the-truck>

On Tue, Mar 30, 2021 at 01:57:47PM -0700, Kees Cook wrote:
> diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h
> new file mode 100644
> index 000000000000..351520803006
> --- /dev/null
> +++ b/include/linux/randomize_kstack.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _LINUX_RANDOMIZE_KSTACK_H
> +#define _LINUX_RANDOMIZE_KSTACK_H
> +
> +#include <linux/kernel.h>
> +#include <linux/jump_label.h>
> +#include <linux/percpu-defs.h>
> +
> +DECLARE_STATIC_KEY_MAYBE(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,
> +			 randomize_kstack_offset);
> +DECLARE_PER_CPU(u32, kstack_offset);
> +
> +/*
> + * Do not use this anywhere else in the kernel. This is used here because
> + * it provides an arch-agnostic way to grow the stack with correct
> + * alignment. Also, since this use is being explicitly masked to a max of
> + * 10 bits, stack-clash style attacks are unlikely. For more details see
> + * "VLAs" in Documentation/process/deprecated.rst
> + * The asm statement is designed to convince the compiler to keep the
> + * allocation around even after "ptr" goes out of scope.
> + */
> +void *__builtin_alloca(size_t size);
> +/*
> + * Use, at most, 10 bits of entropy. We explicitly cap this to keep the
> + * "VLA" from being unbounded (see above). 10 bits leaves enough room for
> + * per-arch offset masks to reduce entropy (by removing higher bits, since
> + * high entropy may overly constrain usable stack space), and for
> + * compiler/arch-specific stack alignment to remove the lower bits.
> + */
> +#define KSTACK_OFFSET_MAX(x)	((x) & 0x3FF)
> +
> +/*
> + * These macros must be used during syscall entry when interrupts and
> + * preempt are disabled, and after user registers have been stored to
> + * the stack.
> + */
> +#define add_random_kstack_offset() do {					\
> +	if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,	\
> +				&randomize_kstack_offset)) {		\
> +		u32 offset = __this_cpu_read(kstack_offset);		\
> +		u8 *ptr = __builtin_alloca(KSTACK_OFFSET_MAX(offset));	\
> +		asm volatile("" : "=m"(*ptr) :: "memory");		\

Using the "m" constraint here is dangerous if you don't actually evaluate it
inside the asm. For example, if the compiler decides to generate an
addressing mode relative to the stack but with writeback (autodecrement), then
the stack pointer will be off by 8 bytes. Can you use "o" instead?

Will


From maz at kernel.org  Thu Apr  1 09:31:06 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 09:31:06 +0100
Subject: [PATCH] clocksource/arm_arch_timer: add __ro_after_init and __init
In-Reply-To: <20210330140444.4fb2a7cb@xhacker.debian>
References: <20210330140444.4fb2a7cb@xhacker.debian>
Message-ID: <87zgyipfsl.wl-maz@kernel.org>

On Tue, 30 Mar 2021 07:04:44 +0100,
Jisheng Zhang <Jisheng.Zhang at synaptics.com> wrote:
> 
> Some functions are not needed after booting, so mark them as __init
> to move them to the .init section.
> 
> Some global variables are never modified after init, so can be
> __ro_after_init.
> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

Acked-by: Marc Zyngier <maz at kernel.org>

	M.

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


From will at kernel.org  Thu Apr  1 09:34:31 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 09:34:31 +0100
Subject: [PATCH v7 5/6] arm64: entry: Enable random_kstack_offset support
In-Reply-To: <20210319212835.3928492-6-keescook@chromium.org>
References: <20210319212835.3928492-1-keescook@chromium.org>
 <20210319212835.3928492-6-keescook@chromium.org>
Message-ID: <20210401083430.GB8554@willie-the-truck>

On Fri, Mar 19, 2021 at 02:28:34PM -0700, Kees Cook wrote:
> Allow for a randomized stack offset on a per-syscall basis, with roughly
> 5 bits of entropy. (And include AAPCS rationale AAPCS thanks to Mark
> Rutland.)
> 
> In order to avoid unconditional stack canaries on syscall entry (due to
> the use of alloca()), also disable stack protector to avoid triggering
> needless checks and slowing down the entry path. As there is no general
> way to control stack protector coverage with a function attribute[1],
> this must be disabled at the compilation unit level. This isn't a problem
> here, though, since stack protector was not triggered before: examining
> the resulting syscall.o, there are no changes in canary coverage (none
> before, none now).
> 
> [1] a working __attribute__((no_stack_protector)) has been added to GCC
> and Clang but has not been released in any version yet:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=346b302d09c1e6db56d9fe69048acb32fbb97845
> https://reviews.llvm.org/rG4fbf84c1732fca596ad1d6e96015e19760eb8a9b
> 
> Signed-off-by: Kees Cook <keescook at chromium.org>
> ---
>  arch/arm64/Kconfig          |  1 +
>  arch/arm64/kernel/Makefile  |  5 +++++
>  arch/arm64/kernel/syscall.c | 10 ++++++++++
>  3 files changed, 16 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 1f212b47a48a..2d0e5f544429 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -146,6 +146,7 @@ config ARM64
>  	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>  	select HAVE_ARCH_PFN_VALID
>  	select HAVE_ARCH_PREL32_RELOCATIONS
> +	select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
>  	select HAVE_ARCH_SECCOMP_FILTER
>  	select HAVE_ARCH_STACKLEAK
>  	select HAVE_ARCH_THREAD_STRUCT_WHITELIST
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index ed65576ce710..6cc97730790e 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -9,6 +9,11 @@ CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
>  CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
>  CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
>  
> +# Remove stack protector to avoid triggering unneeded stack canary
> +# checks due to randomize_kstack_offset.
> +CFLAGS_REMOVE_syscall.o	 = -fstack-protector -fstack-protector-strong
> +CFLAGS_syscall.o	+= -fno-stack-protector
> +
>  # Object file lists.
>  obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
>  			   entry-common.o entry-fpsimd.o process.o ptrace.o	\
> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
> index b9cf12b271d7..58227a1c207e 100644
> --- a/arch/arm64/kernel/syscall.c
> +++ b/arch/arm64/kernel/syscall.c
> @@ -5,6 +5,7 @@
>  #include <linux/errno.h>
>  #include <linux/nospec.h>
>  #include <linux/ptrace.h>
> +#include <linux/randomize_kstack.h>
>  #include <linux/syscalls.h>
>  
>  #include <asm/daifflags.h>
> @@ -43,6 +44,8 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
>  {
>  	long ret;
>  
> +	add_random_kstack_offset();
> +
>  	if (scno < sc_nr) {
>  		syscall_fn_t syscall_fn;
>  		syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
> @@ -55,6 +58,13 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
>  		ret = lower_32_bits(ret);
>  
>  	regs->regs[0] = ret;
> +
> +	/*
> +	 * The AAPCS mandates a 16-byte (i.e. 4-bit) aligned SP at
> +	 * function boundaries. We want at least 5 bits of entropy so we
> +	 * must randomize at least SP[8:4].
> +	 */
> +	choose_random_kstack_offset(get_random_int() & 0x1FF);

Not sure about either of these new calls -- aren't we preemptible in
invoke_syscall()?

Will


From alexandre.torgue at foss.st.com  Thu Apr  1 09:35:29 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 1 Apr 2021 10:35:29 +0200
Subject: [PATCH V3 4/4] ARM: dts: stm32: Update GPIO line names on PicoITX
In-Reply-To: <20210329193614.13374-4-marex@denx.de>
References: <20210329193614.13374-1-marex@denx.de>
 <20210329193614.13374-4-marex@denx.de>
Message-ID: <2a0d3d62-06a2-53da-e84f-10f0578ef3cb@foss.st.com>

Hi Marek

On 3/29/21 9:36 PM, Marek Vasut wrote:
> Use more specific custom GPIO line names which denote exactly where
> the GPIO came from, i.e. the base board. Also, update the new blank
> GPIO line names set up by stm32mp15xx-dhcom-som.dtsi back to their
> original values.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: Patrice Chotard <patrice.chotard at foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org

Series applied on stm32-next.

Regards
Alex

> ---
> V2: New patch
> V3: No change
> ---
>   arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi
> index cd3a1798ca68..ba816ef8b9b2 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi
> @@ -57,22 +57,22 @@ usb-port-power-hog {
>   
>   &gpioc {
>   	gpio-line-names = "", "", "", "",
> -			  "", "", "In1", "",
> +			  "", "", "PicoITX-In1", "",
>   			  "", "", "", "",
>   			  "", "", "", "";
>   };
>   
>   &gpiod {
>   	gpio-line-names = "", "", "", "",
> -			  "", "", "", "",
> -			  "", "", "", "Out1",
> -			  "Out2", "", "", "";
> +			  "", "", "DHCOM-B", "",
> +			  "", "", "", "PicoITX-Out1",
> +			  "PicoITX-Out2", "", "", "";
>   };
>   
>   &gpiog {
> -	gpio-line-names = "In2", "", "", "",
> -			  "", "", "", "",
> +	gpio-line-names = "PicoITX-In2", "", "", "",
>   			  "", "", "", "",
> +			  "DHCOM-L", "", "", "",
>   			  "", "", "", "";
>   };
>   
> 


From will at kernel.org  Thu Apr  1 09:37:59 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 09:37:59 +0100
Subject: [PATCH v9 0/6] Optionally randomize kernel stack offset each
 syscall
In-Reply-To: <20210331205458.1871746-1-keescook@chromium.org>
References: <20210331205458.1871746-1-keescook@chromium.org>
Message-ID: <20210401083758.GA8745@willie-the-truck>

Hi Kees,

On Wed, Mar 31, 2021 at 01:54:52PM -0700, Kees Cook wrote:
> Hi Will (and Mark and Catalin),
> 
> Can you take this via the arm64 tree for v5.13 please? Thomas has added
> his Reviewed-by, so it only leaves arm64's. :)

Sorry, these got mixed up in my inbox so I just replied to v7 and v8 and
then noticed v9. Argh!

However, I think the comments still apply: namely that the dummy "=m" looks
dangerous to me and I think you're accessing pcpu variables with preemption
enabled for the arm64 part:

https://lore.kernel.org/r/20210401083034.GA8554 at willie-the-truck
https://lore.kernel.org/r/20210401083430.GB8554 at willie-the-truck

Will


From victor.liu at nxp.com  Thu Apr  1 09:36:37 2021
From: victor.liu at nxp.com (Liu Ying)
Date: Thu, 01 Apr 2021 16:36:37 +0800
Subject: [PATCH v5 2/5] phy: Add LVDS configuration options
In-Reply-To: <f078a133-de32-0e08-2d87-f2dde7c240ec@ti.com>
References: <1616662832-27048-1-git-send-email-victor.liu@nxp.com>
 <1616662832-27048-3-git-send-email-victor.liu@nxp.com>
 <f078a133-de32-0e08-2d87-f2dde7c240ec@ti.com>
Message-ID: <1619db59285c707c60e3738c4fc287ebb7a6487a.camel@nxp.com>

Hi Kishon,

First of all, thanks for your review.

On Wed, 2021-03-31 at 19:02 +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On 25/03/21 2:30 pm, Liu Ying wrote:
> > This patch allows LVDS PHYs to be configured through
> > the generic functions and through a custom structure
> > added to the generic union.
> > 
> > The parameters added here are based on common LVDS PHY
> > implementation practices.  The set of parameters
> > should cover all potential users.
> > 
> > Cc: Kishon Vijay Abraham I <kishon at ti.com>
> > Cc: Vinod Koul <vkoul at kernel.org>
> > Cc: NXP Linux Team <linux-imx at nxp.com>
> > Signed-off-by: Liu Ying <victor.liu at nxp.com>
> > ---
> > v4->v5:
> > * Align kernel-doc style to include/linux/phy/phy.h. (Vinod)
> > * Trivial tweaks.
> > * Drop Robert's R-b tag.
> > 
> > v3->v4:
> > * Add Robert's R-b tag.
> > 
> > v2->v3:
> > * No change.
> > 
> > v1->v2:
> > * No change.
> > 
> >  include/linux/phy/phy-lvds.h | 32 ++++++++++++++++++++++++++++++++
> >  include/linux/phy/phy.h      |  4 ++++
> >  2 files changed, 36 insertions(+)
> >  create mode 100644 include/linux/phy/phy-lvds.h
> > 
> > diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> > new file mode 100644
> > index 00000000..7a2f474
> > --- /dev/null
> > +++ b/include/linux/phy/phy-lvds.h
> > @@ -0,0 +1,32 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2020 NXP
> > + */
> > +
> > +#ifndef __PHY_LVDS_H_
> > +#define __PHY_LVDS_H_
> > +
> > +/**
> > + * struct phy_configure_opts_lvds - LVDS configuration set
> > + * @bits_per_lane_and_dclk_cycle:	Number of bits per data lane and
> > + *					differential clock cycle.
> 
> phy_set_bus_width() instead?

This member aims to configure the number of bits transmitted during a
period of time(a clock cycle). It doesn't sound like a concept of 'bus
width'?

> > + * @differential_clk_rate:		Clock rate, in Hertz, of the LVDS
> > + *					differential clock.
> 
> Please use clk API's to get rate.

I like your idea. But, this rate is likely runtime-configurable, e.g.,
a LVDS to HDMI chip is connected. It seems that there is no appropriate
driver to set the rate by calling clk_set_rate() then?

> > + * @lanes:				Number of active, consecutive,
> > + *					data lanes, starting from lane 0,
> > + *					used for the transmissions.
> > + * @is_slave:				Boolean, true if the phy is a slave
> > + *					which works together with a master
> > + *					phy to support dual link transmission,
> > + *					otherwise a regular phy or a master phy.
> 
> For parameters that are known at design time, it doesn't have to be
> passed from consumer driver. So all these parameters do they really have
> to be passed at runtime?

Yes for all, perhaps. Details below:

1) bits_per_lane_and_dclk_cycle
i.MX8qxp LVDS phy can only do 7, while i.MX8qm LVDS phy(a different IP)
can do either 7 or 10(configurable by setting a phy register).

2) differential_clk_rate
It's likely runtime-configurable, as I mentioned above.

3) lanes
The higher color depth is, the more lanes are used:
RGB666 - 3 lanes
RGB888 - 4 lanes
RGB101010 - 5 lanes

That means a phy with 5 lanes(like i.MX8qm LVDS phy) support up to the
3 types of RGB pixels.

Though the i.MX LVDS phys don't have any register to configure the
lanes to be used, it would be good to define it for phy_validate() or
other potential phys?

4) is_slave
Any i.MX8qxp LVDS phy instance can act as a regular phy or a master phy
or a slave phy. Changing mode at runtime is probably unneeded. But,
it's difficult for the phy driver to get the mode from device tree(see
drm_of_lvds_get_port_pixels_type()), I think. Export an i.MX8qxp LVDS
phy specific function to set this instead?

Regards,
Liu Ying

> 
> Thanks
> Kishon
> > + *
> > + * This structure is used to represent the configuration state of a LVDS phy.
> > + */
> > +struct phy_configure_opts_lvds {
> > +	unsigned int	bits_per_lane_and_dclk_cycle;
> > +	unsigned long	differential_clk_rate;
> > +	unsigned int	lanes;
> > +	bool		is_slave;
> > +};
> > +
> > +#endif /* __PHY_LVDS_H_ */
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > index e435bdb..d450b44 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -17,6 +17,7 @@
> >  #include <linux/regulator/consumer.h>
> >  
> >  #include <linux/phy/phy-dp.h>
> > +#include <linux/phy/phy-lvds.h>
> >  #include <linux/phy/phy-mipi-dphy.h>
> >  
> >  struct phy;
> > @@ -51,10 +52,13 @@ enum phy_mode {
> >   *		the MIPI_DPHY phy mode.
> >   * @dp:		Configuration set applicable for phys supporting
> >   *		the DisplayPort protocol.
> > + * @lvds:	Configuration set applicable for phys supporting
> > + *		the LVDS phy mode.
> >   */
> >  union phy_configure_opts {
> >  	struct phy_configure_opts_mipi_dphy	mipi_dphy;
> >  	struct phy_configure_opts_dp		dp;
> > +	struct phy_configure_opts_lvds		lvds;
> >  };
> >  
> >  /**
> > 



From pk.chi at mediatek.com  Thu Apr  1 09:52:42 2021
From: pk.chi at mediatek.com (Po-Kai Chi)
Date: Thu, 1 Apr 2021 16:52:42 +0800
Subject: [PATCH v1 1/4] dt-bindings: memory: Add binding for MediaTek
 Common DRAM Controller
In-Reply-To: <20210330135814.GA224111@robh.at.kernel.org>
References: <1617081731-7408-1-git-send-email-pk.chi@mediatek.com>
 <1617081731-7408-2-git-send-email-pk.chi@mediatek.com>
 <20210330135814.GA224111@robh.at.kernel.org>
Message-ID: <1617267162.24434.31.camel@mtkswgap22>

Hello Rob,

Thanks for the remind about dt_binding_check fail and the comments, my
reply is as follows and will fix it in the next version (v2).


Po-Kai

On Tue, 2021-03-30 at 21:58 +0800, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 01:22:08PM +0800, Po-Kai Chi wrote:
> > This patch adds the documentation of the device-tree binding for
> > MediaTek Common DRAM Controller.
> > 
> > Signed-off-by: Po-Kai Chi <pk.chi at mediatek.com>
> > ---
> >  .../memory-controllers/mediatek,dramc.yaml         |  155 ++++++++++++++++++++
> >  1 file changed, 155 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml
> > new file mode 100644
> > index 0000000..0217ce0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml
> > @@ -0,0 +1,155 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (c) 2021 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/memory-controllers/mediatek,dramc.yaml*__;Iw!!CTRNKA9wMg0ARbw!y9zM5d-aNLK99Y_ag2yvqq3TI1Xvm6TV_Vu03VVD3Qbe69N1qZXFFk2DUFb6CG0$ 
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!y9zM5d-aNLK99Y_ag2yvqq3TI1Xvm6TV_Vu03VVD3Qbe69N1qZXFFk2DiMad89A$ 
> > +
> > +title: MediaTek DRAM Controller
> > +
> > +maintainers:
> > +  - Po-Kai Chi <pk.chi at mediatek.com>
> > +
> > +description: |
> > +  MediaTek DRAM controller (DRAMC) provides an interface to query information
> > +  about DRAM which collected from bootloader and device tree.
> > +  This is mainly used by MediaTek Extended Memory Interface (EMI) and DVFS Resource
> > +  Control (DVFSRC).
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - mediatek,mt6779-dramc
> > +
> > +  reg:
> > +    description:
> > +      Base address of MediaTek DRAM related hardware modules, each channel has
> > +      its own base address in order of
> > +      DRAMC_AO_{CH}, DRAMC_NAO_{CH}, DDRPHY_AO_{CH}.
> > +    minItems: 3            # 3 * N channels
> > +    maxItems: 6
> > +
> > +  dram_type:
> 
> These need to be either common or have a vendor prefix.
> 
> Also, s/_/-/

Okay, I have revised the naming rule according to writing-schema.rst.

> > +    description:
> > +      The DRAM type of current DRAM chip.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 0
> > +    maximum: 7
> > +
> > +  support_channel_cnt:
> > +    description:
> > +      The maximum DRAM channel count supported by SoC.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 1
> > +    maximum: 4
> > +
> > +  channel_cnt:
> > +    description:
> > +      The DRAM channel count of current DRAM chip.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 1
> > +    maximum: 4
> > +
> > +  rank_cnt:
> > +    description:
> > +      The DRAM rank count of current DRAM chip.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 1
> > +    maximum: 2
> > +
> > +  rank_size:
> > +    description:
> > +      The size of each DRAM rank.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint64

There may be some misunderstanding.
rank_size uses the full 64 bits to describe the size of each DRAM rank.
So the type of rank_size should be uint64-array, instead of uint64.

> > +    minItems: 1
> > +    maxItems: 2
> > +    items:
> > +      minimum: 0x0
> > +      maximum: 0x100000000    # support up to 4GB in single rank
> > +
> > +  mr_cnt:
> > +    description:
> > +      Specifies how many sets of DRAM mode register information to provide.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    maximum: 40    # total 40 MRs for JEDEC LPDDR4X
> > +
> > +  mr:
> > +    description:
> > +      Pair of DRAM mode register information.
> > +      This property is filled in by bootloader according to the board hardware
> > +      configuration.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +    maxItems: 40    # align with mr_cnt
> > +    items:
> > +      items:
> > +        - description:
> > +            Mode register index
> > +        - description:
> > +            Mode register value
> > +
> > +  freq_cnt:
> > +    description:
> > +      Specifies how many sets of DRAM data clock rate supported by SoC.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +  freq_step:
> > +    description:
> > +      The DRAM data clock rate may be slightly different from those defined
> > +      by the specification due to errors in multiples of the base frequency.
> > +      This describe the mapping from real data clock rate measured by
> > +      frequency meter to JEDEC data clock rate.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +    items:
> > +      items:
> > +        - description:
> > +            Real data rate
> > +        - description:
> > +            Spec data rate
> 
> Looks like an OPP table.

Yes, It's essentially an OPP table, but also records the relationship
between real data rate and spec data rate.

> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - dram_type
> > +  - support_channel_cnt
> > +  - channel_cnt
> > +  - rank_cnt
> > +  - mr_cnt
> > +  - freq_cnt
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    dramc at 10230000 {
> > +        compatible = "mediatek,mt6779-dramc";
> > +        reg = <0 0x10230000 0 0x2000>, /* DRAMC AO CHA */
> > +            <0 0x10240000 0 0x2000>,   /* DRAMC AO CHB */
> > +            <0 0x10234000 0 0x1000>,   /* DRAMC NAO CHA */
> > +            <0 0x10244000 0 0x1000>,   /* DRAMC NAO CHB */
> > +            <0 0x10238000 0 0x2000>,   /* DDRPHY AO CHA */
> > +            <0 0x10248000 0 0x2000>;   /* DDRPHY AO CHB */
> > +        dram_type = <0>;
> > +        support_channel_cnt = <2>;
> > +        channel_cnt = <2>;
> > +        rank_cnt = <2>;
> > +        rank_size = <0x40000000 0x40000000>;
> 
> You defined this as 64-bit, so this is a single value?

No, these are independent values.I have updated the description of this
property in the previous paragraph.

And the sample will be updated to
mediatek,rank-size = <0x40000000>, <0x40000000>;

> 
> > +        mr_cnt = <1>;
> > +        mr = <0x5 0xff>;
> > +        freq_cnt = <6>;
> > +        freq_step = <3718 3733>,
> > +                <3094 3200>,
> > +                <2392 2400>,
> > +                <1534 1600>,
> > +                <1196 1200>,
> > +                <754 800>;
> > +    };
> > -- 
> > 1.7.9.5
> > 


From p.yadav at ti.com  Thu Apr  1 09:56:51 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Thu, 1 Apr 2021 14:26:51 +0530
Subject: [PATCH 4/4] dt-bindings: spi: Convert cadence-quadspi.txt to
 cadence-quadspi.yaml
In-Reply-To: <1161dc3b-c889-c5d7-f7c8-baf5b7b79505@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
 <20210326130034.15231-5-p.yadav@ti.com>
 <20210327183628.GA345487@robh.at.kernel.org>
 <20210329182256.q4zhss6lezj3s44a@ti.com>
 <1161dc3b-c889-c5d7-f7c8-baf5b7b79505@ti.com>
Message-ID: <20210401085649.deocs3cbd7kiljrf@ti.com>

On 01/04/21 01:57PM, Vignesh Raghavendra wrote:
> 
> 
> On 3/29/21 11:52 PM, Pratyush Yadav wrote:
> >>> +  cdns,fifo-depth:
> >>> +    description:
> >>> +      Size of the data FIFO in words.
> >>> +    $ref: "/schemas/types.yaml#/definitions/uint32"
> >>> +    enum: [ 128, 256 ]
> >>> +    default: 128
> >>> +
> >>> +  cdns,fifo-width:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>> +    description:
> >>> +      Bus width of the data FIFO in bytes.
> >>> +    default: 4
> >> I assume there's some constraints on this?
> > IIUC this is a matter of how the peripheral is implemented and there are 
> > no clear constraints. Different implementations can use different bus 
> > widths for the SRAM bus but I don't see any mention of minimum or 
> > maximum values. FWIW, all users in the kernel use a 4 byte bus.
> > 
> 
> IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
> wide) given this represents SRAM bus width. Binding can always be
> updated if there exists an implementation with higher SRAM bus
> width/fifo-width (although that's highly unlikely given there are no
> such examples today).
> 
> But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
> to me.

Ok. Will respin.

> 
> >> With that,
> >>
> >> Reviewed-by: Rob Herring <robh at kernel.org>
> > Thanks.
> > 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From will at kernel.org  Thu Apr  1 09:57:52 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 09:57:52 +0100
Subject: [PATCH v13 00/10] iommu: I/O page faults for SMMUv3
In-Reply-To: <YGNdQ863Mohizx7A@myrica>
References: <20210302092644.2553014-1-jean-philippe@linaro.org>
 <YGNdQ863Mohizx7A@myrica>
Message-ID: <20210401085752.GA8781@willie-the-truck>

On Tue, Mar 30, 2021 at 07:17:55PM +0200, Jean-Philippe Brucker wrote:
> On Tue, Mar 02, 2021 at 10:26:36AM +0100, Jean-Philippe Brucker wrote:
> > Add stall support to the SMMUv3 driver, along with a common I/O Page
> > Fault handler.
> 
> I only have review/ack tags and one assert_lockdep to add to this series.
> Should I send a v14 now or wait a little longer?  Just making sure we can
> get at least patches 1-6 in v5.13.

Easiest thing is probably to send a v14 containing just the patches
targetting v5.13, so that Joerg can queue them up.

Will


From will at kernel.org  Thu Apr  1 10:04:28 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 10:04:28 +0100
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <CAL_JsqJMpZWTsFNaobURocdTWoWa37U1bHYZKxQOZZnYZvBrdA@mail.gmail.com>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <CAL_JsqKqKKb8uXSxQKT4ZMqMv8dt3ABpP+T8x+A1-zb2RKjCNA@mail.gmail.com>
 <20210331153845.GB7815@willie-the-truck>
 <CAL_JsqJMpZWTsFNaobURocdTWoWa37U1bHYZKxQOZZnYZvBrdA@mail.gmail.com>
Message-ID: <20210401090427.GB8781@willie-the-truck>

On Wed, Mar 31, 2021 at 12:52:11PM -0500, Rob Herring wrote:
> On Wed, Mar 31, 2021 at 10:38 AM Will Deacon <will at kernel.org> wrote:
> >
> > On Tue, Mar 30, 2021 at 04:08:11PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 12:09 PM Rob Herring <robh at kernel.org> wrote:
> > > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon <will at kernel.org> wrote:
> > > > > The logic here feels like it
> > > > > could with a bit of untangling.
> > > >
> > > > Yes, I don't love it, but couldn't come up with anything better. It is
> > > > complicated by the fact that flags have to be set before we assign the
> > > > counter and can't set/change them when we assign the counter. It would
> > > > take a lot of refactoring with armpmu code to fix that.
> > >
> > > How's this instead?:
> > >
> > > if (armv8pmu_event_want_user_access(event) || !armv8pmu_event_is_64bit(event))
> > >         event->hw.flags |= ARMPMU_EL0_RD_CNTR;
> > >
> > > /*
> > > * At this point, the counter is not assigned. If a 64-bit counter is
> > > * requested, we must make sure the h/w has 64-bit counters if we set
> > > * the event size to 64-bit because chaining is not supported with
> > > * userspace access. This may still fail later on if the CPU cycle
> > > * counter is in use.
> > > */
> > > if (armv8pmu_event_is_64bit(event) &&
> > >     (!armv8pmu_event_want_user_access(event) ||
> > >      armv8pmu_has_long_event(cpu_pmu) || (hw_event_id ==
> > > ARMV8_PMUV3_PERFCTR_CPU_CYCLES)))
> > >         event->hw.flags |= ARMPMU_EVT_64BIT;
> >
> > I thought there were some cases where we could assign cycles event to an
> > event counter; does that not happen anymore?
> 
> Yes, but if we hit that scenario when the user has asked for 64-bit
> user access, then we return an error later when assigning the counter.
> I think we can assume if users have gone to the trouble of requesting
> 64-bit counters, then they can deal with ensuring they don't have
> multiple users.
> 
> Otherwise, the only way I see to simplify this is we only support
> 64-bit counters in userspace when we have v8.5 PMU.

I'm happy to start from that position, and then we can extend it later if
there's a need.

Will


From will at kernel.org  Thu Apr  1 10:08:01 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 10:08:01 +0100
Subject: [PATCH] perf: xgene: Use device_get_match_data() to simplify code
In-Reply-To: <1617248204-8472-1-git-send-email-tiantao6@hisilicon.com>
References: <1617248204-8472-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <20210401090800.GC8781@willie-the-truck>

On Thu, Apr 01, 2021 at 11:36:44AM +0800, Tian Tao wrote:
> Use device_get_match_data() here to simplify the code a bit.
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> ---
>  drivers/perf/xgene_pmu.c | 17 ++---------------
>  1 file changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
> index ffe3bde..befd2eb 100644
> --- a/drivers/perf/xgene_pmu.c
> +++ b/drivers/perf/xgene_pmu.c
> @@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
>  static int xgene_pmu_probe(struct platform_device *pdev)
>  {
>  	const struct xgene_pmu_data *dev_data;
> -	const struct of_device_id *of_id;
>  	struct xgene_pmu *xgene_pmu;
>  	struct resource *res;
>  	int irq, rc;
> @@ -1857,21 +1856,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, xgene_pmu);
>  
>  	version = -EINVAL;
> -	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
> -	if (of_id) {
> -		dev_data = (const struct xgene_pmu_data *) of_id->data;
> -		version = dev_data->id;
> -	}
> -
> -#ifdef CONFIG_ACPI
> -	if (ACPI_COMPANION(&pdev->dev)) {
> -		const struct acpi_device_id *acpi_id;
> +	dev_data = device_get_match_data(&pdev->dev);
> +	version = dev_data->id;

What prevents device_get_match_data() from returning NULL? The old code
handled the case where we didn't get a match.

Will


From tiantao6 at huawei.com  Thu Apr  1 10:17:17 2021
From: tiantao6 at huawei.com (tiantao (H))
Date: Thu, 1 Apr 2021 17:17:17 +0800
Subject: [PATCH] perf: xgene: Use device_get_match_data() to simplify code
In-Reply-To: <20210401090800.GC8781@willie-the-truck>
References: <1617248204-8472-1-git-send-email-tiantao6@hisilicon.com>
 <20210401090800.GC8781@willie-the-truck>
Message-ID: <fda6cf28-6aba-9a48-fee4-a3c538b8a477@huawei.com>


? 2021/4/1 17:08, Will Deacon ??:
> On Thu, Apr 01, 2021 at 11:36:44AM +0800, Tian Tao wrote:
>> Use device_get_match_data() here to simplify the code a bit.
>>
>> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
>> ---
>>   drivers/perf/xgene_pmu.c | 17 ++---------------
>>   1 file changed, 2 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
>> index ffe3bde..befd2eb 100644
>> --- a/drivers/perf/xgene_pmu.c
>> +++ b/drivers/perf/xgene_pmu.c
>> @@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
>>   static int xgene_pmu_probe(struct platform_device *pdev)
>>   {
>>   	const struct xgene_pmu_data *dev_data;
>> -	const struct of_device_id *of_id;
>>   	struct xgene_pmu *xgene_pmu;
>>   	struct resource *res;
>>   	int irq, rc;
>> @@ -1857,21 +1856,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
>>   	platform_set_drvdata(pdev, xgene_pmu);
>>   
>>   	version = -EINVAL;
>> -	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
>> -	if (of_id) {
>> -		dev_data = (const struct xgene_pmu_data *) of_id->data;
>> -		version = dev_data->id;
>> -	}
>> -
>> -#ifdef CONFIG_ACPI
>> -	if (ACPI_COMPANION(&pdev->dev)) {
>> -		const struct acpi_device_id *acpi_id;
>> +	dev_data = device_get_match_data(&pdev->dev);
>> +	version = dev_data->id;
> What prevents device_get_match_data() from returning NULL? The old code
> handled the case where we didn't get a match.

What about doing it like this?

diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index ffe3bde..bd89148 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, 
struct hlist_node *node)
 ?static int xgene_pmu_probe(struct platform_device *pdev)
 ?{
 ??????? const struct xgene_pmu_data *dev_data;
-?????? const struct of_device_id *of_id;
 ??????? struct xgene_pmu *xgene_pmu;
 ??????? struct resource *res;
 ??????? int irq, rc;
@@ -1857,21 +1856,11 @@ static int xgene_pmu_probe(struct 
platform_device *pdev)
 ??????? platform_set_drvdata(pdev, xgene_pmu);

 ??????? version = -EINVAL;
-?????? of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
-?????? if (of_id) {
-?????????????? dev_data = (const struct xgene_pmu_data *) of_id->data;
+?????? dev_data = device_get_match_data(&pdev->dev);
+?????? if (dev_data)
 ??????????????? version = dev_data->id;
-?????? }
-
-#ifdef CONFIG_ACPI
-?????? if (ACPI_COMPANION(&pdev->dev)) {
-?????????????? const struct acpi_device_id *acpi_id;

-?????????????? acpi_id = acpi_match_device(xgene_pmu_acpi_match, 
&pdev->dev);
-?????????????? if (acpi_id)
-?????????????????????? version = (int) acpi_id->driver_data;
-?????? }
-#endif
 ??????? if (version < 0)
 ??????????????? return -ENODEV;

--
2.7.4

>
> Will
> .
>



From victor.liu at nxp.com  Thu Apr  1 10:17:19 2021
From: victor.liu at nxp.com (Liu Ying)
Date: Thu, 01 Apr 2021 17:17:19 +0800
Subject: [PATCH v7 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and
 Status Registers module binding
In-Reply-To: <1617198059.605916.2074860.nullmailer@robh.at.kernel.org>
References: <1617172405-12962-1-git-send-email-victor.liu@nxp.com>
 <1617172405-12962-8-git-send-email-victor.liu@nxp.com>
 <1617198059.605916.2074860.nullmailer@robh.at.kernel.org>
Message-ID: <2e6b0bdd03da30446448e86eff69182e417ce43f.camel@nxp.com>

On Wed, 2021-03-31 at 08:40 -0500, Rob Herring wrote:
> On Wed, 31 Mar 2021 14:33:18 +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
> > 
> > Reviewed-by: Rob Herring <robh at kernel.org>
> > Signed-off-by: Liu Ying <victor.liu at nxp.com>
> > ---
> > v6->v7:
> > * Add Rob's R-b tag.
> > 
> > v5->v6:
> > * Drop 'select' schema. (Rob)
> > 
> > v4->v5:
> > * Newly introduced in v5. (Rob)
> > 
> >  .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml   | 192 +++++++++++++++++++++
> >  1 file changed, 192 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/syscon at 56221000/pxl2dpi: failed to match any schema with compatible: ['fsl,imx8qxp-pxl2dpi']
> Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/syscon at 56221000/ldb: failed to match any schema with compatible: ['fsl,imx8qxp-ldb']
> Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/phy at 56228300: failed to match any schema with compatible: ['fsl,imx8qxp-mipi-dphy']
> 

Sorry for the errors.
But, my patch passes 'make dt_binding_check' locally upon
v5.12-rc1-dontuse at least.
My yamllint and dt-schema are up to date.

Does your bot _additionally_ check all compatibles in example?
I guess I missed something?

Regards,
Liu Ying

> See https://patchwork.ozlabs.org/patch/1460356
> 
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
> 
> 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.
> 



From matthias.bgg at gmail.com  Thu Apr  1 10:24:28 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:24:28 +0200
Subject: [PATCH v10 2/4] soc: mediatek: add MT6765 scpsys and subdomain
 support
In-Reply-To: <1615358218-6540-3-git-send-email-macpaul.lin@mediatek.com>
References: <1615291538-9799-1-git-send-email-macpaul.lin@mediatek.com>
 <1615358218-6540-1-git-send-email-macpaul.lin@mediatek.com>
 <1615358218-6540-3-git-send-email-macpaul.lin@mediatek.com>
Message-ID: <da80f06b-31d6-b728-43ab-e543f3f6d038@gmail.com>

Hi Macpaul,

On 10/03/2021 07:36, Macpaul Lin wrote:
> From: Mars Cheng <mars.cheng at mediatek.com>
> 
> This adds scpsys support for MT6765
> Add subdomain support for MT6765:
> isp, mm, connsys, mfg, and cam.
> 
> Signed-off-by: Mars Cheng <mars.cheng at mediatek.com>
> Signed-off-by: Owen Chen <owen.chen at mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin at mediatek.com>
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 91 +++++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c

the mtk-scpsys is the old version of the driver. Please port your code to the
new driver: mtk-pm-domains.c

The biggest difference for you will be to describe the power domain hierarchy in
DT instead as in the driver.

Regards,
Matthias

> index ca75b14931ec..fc8d3858f1b4 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -15,6 +15,7 @@
>  
>  #include <dt-bindings/power/mt2701-power.h>
>  #include <dt-bindings/power/mt2712-power.h>
> +#include <dt-bindings/power/mt6765-power.h>
>  #include <dt-bindings/power/mt6797-power.h>
>  #include <dt-bindings/power/mt7622-power.h>
>  #include <dt-bindings/power/mt7623a-power.h>
> @@ -750,6 +751,81 @@ static const struct scp_subdomain scp_subdomain_mt2712[] = {
>  	{MT2712_POWER_DOMAIN_MFG_SC2, MT2712_POWER_DOMAIN_MFG_SC3},
>  };
>  
> +/*
> + * MT6765 power domain support
> + */
> +#define SPM_PWR_STATUS_MT6765			0x0180
> +#define SPM_PWR_STATUS_2ND_MT6765		0x0184
> +
> +static const struct scp_domain_data scp_domain_data_mt6765[] = {
> +	[MT6765_POWER_DOMAIN_VCODEC] = {
> +		.name = "vcodec",
> +		.sta_mask = BIT(26),
> +		.ctl_offs = 0x300,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +	[MT6765_POWER_DOMAIN_ISP] = {
> +		.name = "isp",
> +		.sta_mask = BIT(5),
> +		.ctl_offs = 0x308,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +	[MT6765_POWER_DOMAIN_MM] = {
> +		.name = "mm",
> +		.sta_mask = BIT(3),
> +		.ctl_offs = 0x30C,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.clk_id = {CLK_MM},
> +	},
> +	[MT6765_POWER_DOMAIN_CONN] = {
> +		.name = "conn",
> +		.sta_mask = BIT(1),
> +		.ctl_offs = 0x32C,
> +		.sram_pdn_bits = 0,
> +		.sram_pdn_ack_bits = 0,
> +	},
> +	[MT6765_POWER_DOMAIN_MFG_ASYNC] = {
> +		.name = "mfg_async",
> +		.sta_mask = BIT(23),
> +		.ctl_offs = 0x334,
> +		.sram_pdn_bits = 0,
> +		.sram_pdn_ack_bits = 0,
> +		.clk_id = {CLK_MFG},
> +	},
> +	[MT6765_POWER_DOMAIN_MFG] = {
> +		.name = "mfg",
> +		.sta_mask = BIT(4),
> +		.ctl_offs = 0x338,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +	[MT6765_POWER_DOMAIN_CAM] = {
> +		.name = "cam",
> +		.sta_mask = BIT(25),
> +		.ctl_offs = 0x344,
> +		.sram_pdn_bits = GENMASK(9, 8),
> +		.sram_pdn_ack_bits = GENMASK(13, 12),
> +	},
> +	[MT6765_POWER_DOMAIN_MFG_CORE0] = {
> +		.name = "mfg_core0",
> +		.sta_mask = BIT(7),
> +		.ctl_offs = 0x34C,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +};
> +
> +static const struct scp_subdomain scp_subdomain_mt6765[] = {
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_CAM},
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_ISP},
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_VCODEC},
> +	{MT6765_POWER_DOMAIN_MFG_ASYNC, MT6765_POWER_DOMAIN_MFG},
> +	{MT6765_POWER_DOMAIN_MFG, MT6765_POWER_DOMAIN_MFG_CORE0},
> +};
> +
>  /*
>   * MT6797 power domain support
>   */
> @@ -1033,6 +1109,18 @@ static const struct scp_soc_data mt2712_data = {
>  	.bus_prot_reg_update = false,
>  };
>  
> +static const struct scp_soc_data mt6765_data = {
> +	.domains = scp_domain_data_mt6765,
> +	.num_domains = ARRAY_SIZE(scp_domain_data_mt6765),
> +	.subdomains = scp_subdomain_mt6765,
> +	.num_subdomains = ARRAY_SIZE(scp_subdomain_mt6765),
> +	.regs = {
> +		.pwr_sta_offs = SPM_PWR_STATUS_MT6765,
> +		.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6765,
> +	},
> +	.bus_prot_reg_update = true,
> +};
> +
>  static const struct scp_soc_data mt6797_data = {
>  	.domains = scp_domain_data_mt6797,
>  	.num_domains = ARRAY_SIZE(scp_domain_data_mt6797),
> @@ -1088,6 +1176,9 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
>  	}, {
>  		.compatible = "mediatek,mt2712-scpsys",
>  		.data = &mt2712_data,
> +	}, {
> +		.compatible = "mediatek,mt6765-scpsys",
> +		.data = &mt6765_data,
>  	}, {
>  		.compatible = "mediatek,mt6797-scpsys",
>  		.data = &mt6797_data,
> 


From andy.shevchenko at gmail.com  Thu Apr  1 10:24:50 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 1 Apr 2021 12:24:50 +0300
Subject: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
In-Reply-To: <20210401062517.28832-1-dmugil2000@gmail.com>
References: <20210401062517.28832-1-dmugil2000@gmail.com>
Message-ID: <CAHp75VfgL0KW0fetgE3NuBb4itMK1oY+yLmr1xDYkn390hCscg@mail.gmail.com>

On Thu, Apr 1, 2021 at 9:27 AM Mugilraj Dhavachelvan
<dmugil2000 at gmail.com> wrote:
>
> Change function's name to %s and __func__ to fix checkpatch.pl errors.

No, just drop the __func__ completely. First of all, we have a device
name, and uniqueness of the messages in the driver should guarantee
easy findings. Second, specific to _dbg() variants, with enabled
Dynamic Debug it can be chosen at run time!

I recommend going through all drivers and drop __func__ near to
dev_dbg() and pr_debug().

-- 
With Best Regards,
Andy Shevchenko


From anshuman.khandual at arm.com  Thu Apr  1 10:26:33 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu,  1 Apr 2021 14:56:33 +0530
Subject: [PATCH V2 RESEND] mm/memtest: Add ARCH_USE_MEMTEST
Message-ID: <1617269193-22294-1-git-send-email-anshuman.khandual@arm.com>

early_memtest() does not get called from all architectures. Hence enabling
CONFIG_MEMTEST and providing a valid memtest=[1..N] kernel command line
option might not trigger the memory pattern tests as would be expected in
normal circumstances. This situation is misleading.

The change here prevents the above mentioned problem after introducing a
new config option ARCH_USE_MEMTEST that should be subscribed on platforms
that call early_memtest(), in order to enable the config CONFIG_MEMTEST.
Conversely CONFIG_MEMTEST cannot be enabled on platforms where it would
not be tested anyway.

Cc: Russell King <linux at armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Thomas Bogendoerfer <tsbogend at alpha.franken.de>
Cc: Michael Ellerman <mpe at ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: Chris Zankel <chris at zankel.net>
Cc: Max Filippov <jcmvbkbc at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-xtensa at linux-xtensa.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
Reviewed-by: Max Filippov <jcmvbkbc at gmail.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
This patch applies on v5.12-rc5 and has been tested on arm64 platform.
But it has been just build tested on all other platforms.

Changes in V2:

https://patchwork.kernel.org/project/linux-mm/patch/1614573126-7740-1-git-send-email-anshuman.khandual at arm.com/

- Added ARCH_USE_MEMTEST in the sorted alphabetical order on platforms

Changes in V1:

https://patchwork.kernel.org/project/linux-mm/patch/1612498242-31579-1-git-send-email-anshuman.khandual at arm.com/

 arch/arm/Kconfig     | 1 +
 arch/arm64/Kconfig   | 1 +
 arch/mips/Kconfig    | 1 +
 arch/powerpc/Kconfig | 1 +
 arch/x86/Kconfig     | 1 +
 arch/xtensa/Kconfig  | 1 +
 lib/Kconfig.debug    | 9 ++++++++-
 7 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5da96f5df48f..49878877df88 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -33,6 +33,7 @@ config ARM
 	select ARCH_SUPPORTS_ATOMIC_RMW
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF
+	select ARCH_USE_MEMTEST
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
 	select ARCH_WANT_IPC_PARSE_VERSION
 	select ARCH_WANT_LD_ORPHAN_WARN
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..63c380587a77 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -67,6 +67,7 @@ config ARM64
 	select ARCH_KEEP_MEMBLOCK
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_USE_GNU_PROPERTY
+	select ARCH_USE_MEMTEST
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_USE_SYM_ANNOTATIONS
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..93a4f502f962 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -14,6 +14,7 @@ config MIPS
 	select ARCH_SUPPORTS_UPROBES
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
+	select ARCH_USE_MEMTEST
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..3778ad17f56a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -149,6 +149,7 @@ config PPC
 	select ARCH_SUPPORTS_DEBUG_PAGEALLOC	if PPC32 || PPC_BOOK3S_64
 	select ARCH_USE_BUILTIN_BSWAP
 	select ARCH_USE_CMPXCHG_LOCKREF		if PPC64
+	select ARCH_USE_MEMTEST
 	select ARCH_USE_QUEUED_RWLOCKS		if PPC_QUEUED_SPINLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS	if PPC_QUEUED_SPINLOCKS
 	select ARCH_WANT_IPC_PARSE_VERSION
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..2cb76fd5258e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,6 +100,7 @@ config X86
 	select ARCH_SUPPORTS_LTO_CLANG		if X86_64
 	select ARCH_SUPPORTS_LTO_CLANG_THIN	if X86_64
 	select ARCH_USE_BUILTIN_BSWAP
+	select ARCH_USE_MEMTEST
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_USE_SYM_ANNOTATIONS
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 9ad6b7b82707..524413aabbc4 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -7,6 +7,7 @@ config XTENSA
 	select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU
 	select ARCH_HAS_DMA_SET_UNCACHED if MMU
+	select ARCH_USE_MEMTEST
 	select ARCH_USE_QUEUED_RWLOCKS
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2779c29d9981..a3fd69e6f6af 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2515,11 +2515,18 @@ config TEST_FPU
 
 endif # RUNTIME_TESTING_MENU
 
+config ARCH_USE_MEMTEST
+	bool
+	help
+	  An architecture should select this when it uses early_memtest()
+	  during boot process.
+
 config MEMTEST
 	bool "Memtest"
+	depends on ARCH_USE_MEMTEST
 	help
 	  This option adds a kernel parameter 'memtest', which allows memtest
-	  to be set.
+	  to be set and executed.
 	        memtest=0, mean disabled; -- default
 	        memtest=1, mean do 1 test pattern;
 	        ...
-- 
2.20.1



From matthias.bgg at gmail.com  Thu Apr  1 10:28:32 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:28:32 +0200
Subject: [PATCH -next] soc: mediatek: Make symbol 'mtk_mutex_driver' static
In-Reply-To: <20210210075656.1096251-1-weiyongjun1@huawei.com>
References: <20210210075656.1096251-1-weiyongjun1@huawei.com>
Message-ID: <c22c6ae9-9bfc-570b-7b02-ec9c24963b89@gmail.com>



On 10/02/2021 08:56, Wei Yongjun wrote:
> The sparse tool complains as follows:
> 
> drivers/soc/mediatek/mtk-mutex.c:464:24: warning:
>  symbol 'mtk_mutex_driver' was not declared. Should it be static?
> 
> This symbol is not used outside of mtk-mutex.c, so this
> commit marks it static.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>

Applied to v5.12-next/soc

Thanks!

> ---
>  drivers/soc/mediatek/mtk-mutex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
> index f531b119da7a..3a315a62e783 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -461,7 +461,7 @@ static const struct of_device_id mutex_driver_dt_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
>  
> -struct platform_driver mtk_mutex_driver = {
> +static struct platform_driver mtk_mutex_driver = {
>  	.probe		= mtk_mutex_probe,
>  	.remove		= mtk_mutex_remove,
>  	.driver		= {
> 


From hch at lst.de  Thu Apr  1 10:29:57 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 1 Apr 2021 11:29:57 +0200
Subject: [PATCH 05/18] iommu/fsl_pamu: remove support for multiple windows
In-Reply-To: <20210330122234.GE5908@willie-the-truck>
References: <20210316153825.135976-1-hch@lst.de>
 <20210316153825.135976-6-hch@lst.de> <20210330122234.GE5908@willie-the-truck>
Message-ID: <20210401092957.GB2934@lst.de>

On Tue, Mar 30, 2021 at 01:22:34PM +0100, Will Deacon wrote:
> >  	 * win_arr contains information of the configured
> >  	 * windows for a domain. This is allocated only
> >  	 * when the number of windows for the domain are
> >  	 * set.
> >  	 */
> 
> The last part of this comment is now stale ^^

I've updated it, although the comment will go away entirely a little
bit later anyway.


From zweiss at equinix.com  Thu Apr  1 10:30:38 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Thu, 1 Apr 2021 09:30:38 +0000
Subject: [EXTERNAL] [PATCH v2 19/21] ipmi: kcs_bmc_aspeed: Implement KCS
 SerIRQ configuration
In-Reply-To: <20210319062752.145730-19-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-19-andrew@aj.id.au>
Message-ID: <YGWSvRQADGK4Rfkc@packtop>

On Fri, Mar 19, 2021 at 01:27:50AM CDT, Andrew Jeffery wrote:
>Apply the SerIRQ ID and level/sense behaviours from the devicetree if
>provided.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc_aspeed.c | 179 ++++++++++++++++++++++++++++-
> 1 file changed, 177 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 271845eb2e26..3782aef4eb73 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -9,6 +9,7 @@
> #include <linux/errno.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
>+#include <linux/irq.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
> #include <linux/of.h>
>@@ -28,6 +29,22 @@
>
> #define KCS_CHANNEL_MAX     4
>
>+/*
>+ * Field class descriptions
>+ *
>+ * LPCyE	Enable LPC channel y
>+ * IBFIEy	Input Buffer Full IRQ Enable for LPC channel y
>+ * IRQxEy	Assert SerIRQ x for LPC channel y (Deprecated, use IDyIRQX, IRQXEy)
>+ * IDyIRQX	Use the specified 4-bit SerIRQ for LPC channel y
>+ * SELyIRQX	SerIRQ polarity for LPC channel y (low: 0, high: 1)
>+ * IRQXEy	Assert the SerIRQ specified in IDyIRQX for LPC channel y
>+ */
>+
>+#define LPC_TYIRQX_LOW       0b00
>+#define LPC_TYIRQX_HIGH      0b01
>+#define LPC_TYIRQX_RSVD      0b10
>+#define LPC_TYIRQX_RISING    0b11
>+
> #define LPC_HICR0            0x000
> #define     LPC_HICR0_LPC3E          BIT(7)
> #define     LPC_HICR0_LPC2E          BIT(6)
>@@ -39,6 +56,19 @@
> #define LPC_HICR4            0x010
> #define     LPC_HICR4_LADR12AS       BIT(7)
> #define     LPC_HICR4_KCSENBL        BIT(2)
>+#define LPC_SIRQCR0	     0x070
>+/* IRQ{12,1}E1 are deprecated as of AST2600 A3 but necessary for prior chips */
>+#define     LPC_SIRQCR0_IRQ12E1	     BIT(1)
>+#define     LPC_SIRQCR0_IRQ1E1	     BIT(0)
>+#define LPC_HICR5	     0x080
>+#define     LPC_HICR5_ID3IRQX_MASK   GENMASK(23, 20)
>+#define     LPC_HICR5_ID3IRQX_SHIFT  20
>+#define     LPC_HICR5_ID2IRQX_MASK   GENMASK(19, 16)
>+#define     LPC_HICR5_ID2IRQX_SHIFT  16
>+#define     LPC_HICR5_SEL3IRQX       BIT(15)
>+#define     LPC_HICR5_IRQXE3         BIT(14)
>+#define     LPC_HICR5_SEL2IRQX       BIT(13)
>+#define     LPC_HICR5_IRQXE2         BIT(12)
> #define LPC_LADR3H           0x014
> #define LPC_LADR3L           0x018
> #define LPC_LADR12H          0x01C
>@@ -55,6 +85,13 @@
> #define LPC_HICRB            0x100
> #define     LPC_HICRB_IBFIF4         BIT(1)
> #define     LPC_HICRB_LPC4E          BIT(0)
>+#define LPC_HICRC            0x104
>+#define     LPC_HICRC_ID4IRQX_MASK   GENMASK(7, 4)
>+#define     LPC_HICRC_ID4IRQX_SHIFT  4
>+#define     LPC_HICRC_TY4IRQX_MASK   GENMASK(3, 2)
>+#define     LPC_HICRC_TY4IRQX_SHIFT  2
>+#define     LPC_HICRC_OBF4_AUTO_CLR  BIT(1)
>+#define     LPC_HICRC_IRQXE4         BIT(0)
> #define LPC_LADR4            0x110
> #define LPC_IDR4             0x114
> #define LPC_ODR4             0x118
>@@ -62,11 +99,21 @@
>
> #define OBE_POLL_PERIOD	     (HZ / 2)
>
>+enum aspeed_kcs_irq_mode {
>+	aspeed_kcs_irq_none,
>+	aspeed_kcs_irq_serirq,
>+};
>+
> struct aspeed_kcs_bmc {
> 	struct kcs_bmc_device kcs_bmc;
>
> 	struct regmap *map;
>
>+	struct {
>+		enum aspeed_kcs_irq_mode mode;
>+		int id;
>+	} upstream_irq;
>+
> 	struct {
> 		spinlock_t lock;
> 		bool remove;
>@@ -103,6 +150,49 @@ static void aspeed_kcs_outb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 data)
>
> 	rc = regmap_write(priv->map, reg, data);
> 	WARN(rc != 0, "regmap_write() failed: %d\n", rc);
>+
>+	/* Trigger the upstream IRQ on ODR writes, if enabled */
>+
>+	switch (reg) {
>+	case LPC_ODR1:
>+	case LPC_ODR2:
>+	case LPC_ODR3:
>+	case LPC_ODR4:
>+		break;
>+	default:
>+		return;
>+	}
>+
>+	if (priv->upstream_irq.mode != aspeed_kcs_irq_serirq)
>+		return;
>+
>+	switch (kcs_bmc->channel) {
>+	case 1:
>+		switch (priv->upstream_irq.id) {
>+		case 12:
>+			regmap_update_bits(priv->map, LPC_SIRQCR0, LPC_SIRQCR0_IRQ12E1,
>+					   LPC_SIRQCR0_IRQ12E1);
>+			break;
>+		case 1:
>+			regmap_update_bits(priv->map, LPC_SIRQCR0, LPC_SIRQCR0_IRQ1E1,
>+					   LPC_SIRQCR0_IRQ1E1);
>+			break;
>+		default:
>+			break;
>+		}
>+		break;
>+	case 2:
>+		regmap_update_bits(priv->map, LPC_HICR5, LPC_HICR5_IRQXE2, LPC_HICR5_IRQXE2);
>+		break;
>+	case 3:
>+		regmap_update_bits(priv->map, LPC_HICR5, LPC_HICR5_IRQXE3, LPC_HICR5_IRQXE3);
>+		break;
>+	case 4:
>+		regmap_update_bits(priv->map, LPC_HICRC, LPC_HICRC_IRQXE4, LPC_HICRC_IRQXE4);
>+		break;
>+	default:
>+		break;
>+	}
> }
>
> static void aspeed_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 val)
>@@ -161,6 +251,73 @@ static void aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u16 addr)
> 	}
> }
>
>+static inline int aspeed_kcs_map_serirq_type(u32 dt_type)
>+{
>+	switch (dt_type) {
>+	case IRQ_TYPE_EDGE_RISING:
>+		return LPC_TYIRQX_RISING;
>+	case IRQ_TYPE_LEVEL_HIGH:
>+		return LPC_TYIRQX_HIGH;
>+	case IRQ_TYPE_LEVEL_LOW:
>+		return LPC_TYIRQX_LOW;
>+	default:
>+		return -EINVAL;
>+	}
>+}
>+
>+static int aspeed_kcs_config_upstream_irq(struct aspeed_kcs_bmc *priv, u32 id, u32 dt_type)
>+{
>+	unsigned int mask, val, hw_type;
>+
>+	if (id > 15)
>+		return -EINVAL;
>+
>+	hw_type = aspeed_kcs_map_serirq_type(dt_type);
>+	if (hw_type < 0)
>+		return hw_type;
>+
>+	priv->upstream_irq.mode = aspeed_kcs_irq_serirq;
>+	priv->upstream_irq.id = id;
>+
>+	switch (priv->kcs_bmc.channel) {
>+	case 1:
>+		/* Needs IRQxE1 rather than (ID1IRQX, SEL1IRQX, IRQXE1) before AST2600 A3 */
>+		break;
>+	case 2:
>+		if (!(hw_type == LPC_TYIRQX_LOW || hw_type == LPC_TYIRQX_HIGH))
>+			return -EINVAL;
>+
>+		mask = LPC_HICR5_SEL2IRQX | LPC_HICR5_ID2IRQX_MASK;
>+		val = (id << LPC_HICR5_ID2IRQX_SHIFT);
>+		val |= (hw_type == LPC_TYIRQX_HIGH) ? LPC_HICR5_SEL2IRQX : 0;
>+		regmap_update_bits(priv->map, LPC_HICR5, mask, val);
>+
>+		break;
>+	case 3:
>+		if (!(hw_type == LPC_TYIRQX_LOW || hw_type == LPC_TYIRQX_HIGH))
>+			return -EINVAL;
>+
>+		mask = LPC_HICR5_SEL3IRQX | LPC_HICR5_ID3IRQX_MASK;
>+		val = (id << LPC_HICR5_ID3IRQX_SHIFT);
>+		val |= (hw_type == LPC_TYIRQX_HIGH) ? LPC_HICR5_SEL3IRQX : 0;
>+		regmap_update_bits(priv->map, LPC_HICR5, mask, val);
>+
>+		break;
>+	case 4:
>+		mask = LPC_HICRC_ID4IRQX_MASK | LPC_HICRC_TY4IRQX_MASK | LPC_HICRC_OBF4_AUTO_CLR;
>+		val = (id << LPC_HICRC_ID4IRQX_SHIFT) | (hw_type << LPC_HICRC_TY4IRQX_SHIFT);
>+		regmap_update_bits(priv->map, LPC_HICRC, mask, val);
>+		break;
>+	default:
>+		dev_warn(priv->kcs_bmc.dev,
>+			 "SerIRQ configuration not supported on KCS channel %d\n",
>+			 priv->kcs_bmc.channel);
>+		return -EINVAL;
>+	}
>+
>+	return 0;
>+}
>+
> static void aspeed_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enable)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>@@ -267,7 +424,7 @@ static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> 	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> }
>
>-static int aspeed_kcs_config_irq(struct kcs_bmc_device *kcs_bmc,
>+static int aspeed_kcs_config_downstream_irq(struct kcs_bmc_device *kcs_bmc,
> 			struct platform_device *pdev)
> {
> 	struct device *dev = &pdev->dev;
>@@ -371,6 +528,8 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	struct aspeed_kcs_bmc *priv;
> 	struct device_node *np;
> 	int rc, channel, addr;
>+	bool have_upstream_irq;
>+	u32 upstream_irq[2];
>
> 	np = pdev->dev.of_node->parent;
> 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
>@@ -379,6 +538,7 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 		dev_err(&pdev->dev, "unsupported LPC device binding\n");
> 		return -ENODEV;
> 	}
>+
> 	ops = of_device_get_match_data(&pdev->dev);
> 	if (!ops)
> 		return -EINVAL;
>@@ -391,6 +551,13 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	if (addr < 0)
> 		return addr;
>
>+	np = pdev->dev.of_node;
>+	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", upstream_irq, 2);
>+	if ((rc && rc != -EINVAL))
>+		return -EINVAL;
>+
>+	have_upstream_irq = !rc;
>+
> 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> 	if (!priv)
> 		return -ENOMEM;
>@@ -413,10 +580,17 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>
> 	aspeed_kcs_set_address(kcs_bmc, addr);
>
>-	rc = aspeed_kcs_config_irq(kcs_bmc, pdev);
>+	/* Host to BMC IRQ */
>+	rc = aspeed_kcs_config_downstream_irq(kcs_bmc, pdev);
> 	if (rc)
> 		return rc;
>
>+	/* BMC to Host IRQ */
>+	if (have_upstream_irq)
>+		aspeed_kcs_config_upstream_irq(priv, upstream_irq[0], upstream_irq[1]);

This has a return value that could indicate an error if the DT
properties are misconfigured; do we want to check for that here?

>+	else
>+		priv->upstream_irq.mode = aspeed_kcs_irq_none;
>+
> 	platform_set_drvdata(pdev, priv);
>
> 	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
>@@ -481,4 +655,5 @@ module_platform_driver(ast_kcs_bmc_driver);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>+MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
> MODULE_DESCRIPTION("Aspeed device interface to the KCS BMC device");
>-- 
>2.27.0
>

From hch at lst.de  Thu Apr  1 10:32:01 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 1 Apr 2021 11:32:01 +0200
Subject: [PATCH 06/18] iommu/fsl_pamu: remove ->domain_window_enable
In-Reply-To: <20210330124009.GF5908@willie-the-truck>
References: <20210316153825.135976-1-hch@lst.de>
 <20210316153825.135976-7-hch@lst.de> <20210330124009.GF5908@willie-the-truck>
Message-ID: <20210401093201.GC2934@lst.de>

On Tue, Mar 30, 2021 at 01:40:09PM +0100, Will Deacon wrote:
> > +	ret = pamu_config_ppaace(liodn, geom->aperture_start,
> > +				 geom->aperture_end - 1, ~(u32)0,
> 
> You're passing 'geom->aperture_end - 1' as the size here, but the old code
> seemed to _add_ 1:
> 

> > -	win_size = (domain->geometry.aperture_end + 1) >> ilog2(1);
> 
> here ^^ when calculating the exclusive upper bound. In other words, I think
> '1ULL << 36' used to get passed to pamu_config_ppaace(). Is that an
> intentional change?

No, I've fixed it up.


From matthias.bgg at gmail.com  Thu Apr  1 10:32:22 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:32:22 +0200
Subject: [PATCH 1/2] dt-bindings: arm64: dts: mediatek: Add mt8183-pumpkin
 board
In-Reply-To: <20210217205945.830006-1-fparent@baylibre.com>
References: <20210217205945.830006-1-fparent@baylibre.com>
Message-ID: <86a6d071-007d-5a20-bd59-ba09054b9fc1@gmail.com>



On 17/02/2021 21:59, Fabien Parent wrote:
> Add binding documentation for the MT8183 Pumpkin board.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Whole series applied to v5.12-next/dts64

Thanks!

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 53f0d4e3ea98..8f5a625cfb3d 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -123,6 +123,10 @@ properties:
>            - const: google,krane-sku176
>            - const: google,krane
>            - const: mediatek,mt8183
> +      - items:
> +          - enum:
> +              - mediatek,mt8183-pumpkin
> +          - const: mediatek,mt8183
>  
>  additionalProperties: true
>  
> 


From alexandre.torgue at foss.st.com  Thu Apr  1 10:32:50 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 1 Apr 2021 11:32:50 +0200
Subject: [PATCH] ARM: dts: stm32: Enable crc1 and cryp1 where applicable
 on DHSOM
In-Reply-To: <20210325214533.80061-1-marex@denx.de>
References: <20210325214533.80061-1-marex@denx.de>
Message-ID: <1e7f0712-1b02-8e6d-af0b-ce3d46b14a12@foss.st.com>

Hi Marek

On 3/25/21 10:45 PM, Marek Vasut wrote:
> Enable the CRC accelerator on all STM32MP15xx DHSOM based systems
> and CRYP accelerator on all STM32MP15x[CF] DHSOM based systems.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Patrice Chotard <patrice.chotard at st.com>
> Cc: Patrick Delaunay <patrick.delaunay at st.com>
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org
> ---

Applied on stm32-next.

Thanks.
Alex


>   arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts   | 4 ++++
>   arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts    | 4 ++++
>   arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts | 4 ++++
>   arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi    | 4 ++++
>   arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi    | 4 ++++
>   5 files changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts b/arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts
> index 02a39132958e..b4e504f026ce 100644
> --- a/arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts
> +++ b/arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts
> @@ -20,6 +20,10 @@ / {
>   		     "st,stm32mp153";
>   };
>   
> +&cryp1 {
> +	status = "okay";
> +};
> +
>   &m_can1 {
>   	pinctrl-names = "default", "sleep";
>   	pinctrl-0 = <&m_can1_pins_a>;
> diff --git a/arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts b/arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts
> index d3b81382f97c..6dd8216c235e 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts
> @@ -20,6 +20,10 @@ / {
>   		     "st,stm32mp157";
>   };
>   
> +&cryp1 {
> +	status = "okay";
> +};
> +
>   &m_can1 {
>   	pinctrl-names = "default", "sleep";
>   	pinctrl-0 = <&m_can1_pins_a>;
> diff --git a/arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts b/arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts
> index cfb8f8a0c82d..7067a860aaff 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts
> @@ -20,6 +20,10 @@ / {
>   		     "st,stm32mp157";
>   };
>   
> +&cryp1 {
> +	status = "okay";
> +};
> +
>   &m_can1 {
>   	pinctrl-names = "default", "sleep";
>   	pinctrl-0 = <&m_can1_pins_a>;
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> index 7365be965979..50806c84432a 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
> @@ -92,6 +92,10 @@ adc2: adc at 100 {
>   	};
>   };
>   
> +&crc1 {
> +	status = "okay";
> +};
> +
>   &dac {
>   	pinctrl-names = "default";
>   	pinctrl-0 = <&dac_ch1_pins_a &dac_ch2_pins_a>;
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi
> index 803eb8bc9c85..013ae369791d 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi
> @@ -21,6 +21,10 @@ memory at c0000000 {
>   	};
>   };
>   
> +&crc1 {
> +	status = "okay";
> +};
> +
>   &dts {
>   	status = "okay";
>   };
> 


From hch at lst.de  Thu Apr  1 10:34:08 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 1 Apr 2021 11:34:08 +0200
Subject: [PATCH 08/18] iommu/fsl_pamu: merge pamu_set_liodn and map_liodn
In-Reply-To: <20210330124651.GH5908@willie-the-truck>
References: <20210316153825.135976-1-hch@lst.de>
 <20210316153825.135976-9-hch@lst.de> <20210330124651.GH5908@willie-the-truck>
Message-ID: <20210401093408.GD2934@lst.de>

On Tue, Mar 30, 2021 at 01:46:51PM +0100, Will Deacon wrote:
> > +	ret = pamu_config_ppaace(liodn, geom->aperture_start,
> > +				 geom->aperture_end - 1, ~(u32)0,
> > +				 0, dma_domain->snoop_id, dma_domain->stash_id,
> > +				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
> 
> There's more '+1' / '-1' confusion here with aperture_end which I'm not
> managing to follow. What am I missing?

You did not missing anything, I messed this up.   Fixed.


From Claudiu.Beznea at microchip.com  Thu Apr  1 10:34:27 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 1 Apr 2021 09:34:27 +0000
Subject: [PATCH 10/24] ARM: at91: sfrbu: add sfrbu registers definitions
 for sama7g5
In-Reply-To: <YGSbMtNzcVmBg7fQ@piout.net>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-11-claudiu.beznea@microchip.com>
 <YGSbMtNzcVmBg7fQ@piout.net>
Message-ID: <cf45c875-5df8-5b3c-a0c1-7d5d8fc32ccb@microchip.com>

On 31.03.2021 18:54, Alexandre Belloni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 31/03/2021 13:58:54+0300, Claudiu Beznea wrote:
>> Add SFRBU registers definitions for SAMA7G5.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
>>  include/soc/at91/sama7-sfrbu.h | 34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>  create mode 100644 include/soc/at91/sama7-sfrbu.h
>>
>> diff --git a/include/soc/at91/sama7-sfrbu.h b/include/soc/at91/sama7-sfrbu.h
>> new file mode 100644
>> index 000000000000..76b740810d34
>> --- /dev/null
>> +++ b/include/soc/at91/sama7-sfrbu.h
>> @@ -0,0 +1,34 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Microchip SAMA7 SFRBU registers offsets and bit definitions.
>> + *
>> + * Copyright (C) [2020] Microchip Technology Inc. and its subsidiaries
>> + *
>> + * Author: Claudu Beznea <claudiu.beznea at microchip.com>
>> + */
>> +
>> +#ifndef __SAMA7_SFRBU_H__
>> +#define __SAMA7_SFRBU_H__
>> +
>> +#ifdef CONFIG_SOC_SAMA7
>> +
>> +#define AT91_SFRBU_PSWBU                     (0x00)          /* SFRBU Power Switch BU Control Register */
>> +#define              AT91_SFRBU_PSWBU_PSWKEY         (0x4BD20C << 8) /* Specific value mandatory to allow writing of other register bits */
>> +#define              AT91_SFRBU_PSWBU_STATE          (1 << 2)        /* Power switch BU state */
>> +#define              AT91_SFRBU_PSWBU_SOFTSWITCH     (1 << 1)        /* Power switch BU source selection */
>> +#define              AT91_SFRBU_PSWBU_CTRL           (1 << 0)        /* Power switch BU control */
> 
> Please use BIT
> 
>> +
>> +#define AT91_SFRBU_25LDOCR                   (0x0C)          /* SFRBU 2.5V LDO Control Register */
>> +#define              AT91_SFRBU_25LDOCR_LDOANAKEY    (0x3B6E18 << 8) /* Specific value mandatory to allow writing of other register bits. */
>> +#define              AT91_SFRBU_25LDOCR_STATE        (1 << 3)        /* LDOANA Switch On/Off Control */
>> +#define              AT91_SFRBU_25LDOCR_LP           (1 << 2)        /* LDOANA Low-Power Mode Control */
>> +#define              AT91_SFRBU_PD_VALUE_MSK         (0x3)
> 
> GENMASK
> 
>> +#define              AT91_SFRBU_25LDOCR_PD_VALUE(v)  ((v) & AT91_SFRBU_PD_VALUE_MSK) /* LDOANA Pull-down value */
> 
> this macro is not necessary, you can use FIELD_PREP with the previous
> define.
> 

This file (as well as include/soc/at91/sama7-ddr.h) is used in
arch/arm/mach-at91/pm_suspend.S who's content is executed from CPU internal
SRAM. I chose to have these defines w/o BIT(), GENMASK() and friends to not
depend on the bitops.h who's size might be changed at any time.

> 
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 


From hch at lst.de  Thu Apr  1 10:36:42 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 1 Apr 2021 11:36:42 +0200
Subject: [PATCH 11/18] iommu/fsl_pamu: remove the snoop_id field
In-Reply-To: <20210330125816.GK5908@willie-the-truck>
References: <20210316153825.135976-1-hch@lst.de>
 <20210316153825.135976-12-hch@lst.de>
 <20210330125816.GK5908@willie-the-truck>
Message-ID: <20210401093642.GE2934@lst.de>

On Tue, Mar 30, 2021 at 01:58:17PM +0100, Will Deacon wrote:
> pamu_config_ppaace() takes quite a few useless parameters at this stage,
> but anyway:

I'll see it it makes sense to throw in another patch at the end to cut
it down a bit more.

> Acked-by: Will Deacon <will at kernel.org>
> 
> Do you know if this driver is actually useful? Once the complexity has been
> stripped back, the stubs and default values really stand out.

Yeah.  No idea what the usefulness of this driver is.  Bascially all it
seems to do is to setup a few registers to allow access to the whole
physical memory.  But maybe that is required on this hardware to allow
for any DMA access?


From daniel.lezcano at linaro.org  Thu Apr  1 10:36:48 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 1 Apr 2021 11:36:48 +0200
Subject: [PATCH] clocksource/arm_arch_timer: add __ro_after_init and __init
In-Reply-To: <87zgyipfsl.wl-maz@kernel.org>
References: <20210330140444.4fb2a7cb@xhacker.debian>
 <87zgyipfsl.wl-maz@kernel.org>
Message-ID: <d0188aa6-5682-6b0d-0221-f96f4ef77505@linaro.org>

On 01/04/2021 10:31, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 07:04:44 +0100,
> Jisheng Zhang <Jisheng.Zhang at synaptics.com> wrote:
>>
>> Some functions are not needed after booting, so mark them as __init
>> to move them to the .init section.
>>
>> Some global variables are never modified after init, so can be
>> __ro_after_init.
>>
>> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
> 
> Acked-by: Marc Zyngier <maz at kernel.org>
> 
> 	M.

Thanks Marc


-- 
<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 matthias.bgg at gmail.com  Thu Apr  1 10:36:56 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:36:56 +0200
Subject: [PATCH 1/4] soc: mediatek: pm-domains: Add a meaningful power
 domain name
In-Reply-To: <20210225175000.824661-1-enric.balletbo@collabora.com>
References: <20210225175000.824661-1-enric.balletbo@collabora.com>
Message-ID: <f61e32cb-0dbe-2e12-2d77-3778953ee1d7@gmail.com>



On 25/02/2021 18:49, Enric Balletbo i Serra wrote:
> Add the power domains names to the power domain struct so we
> have meaningful name for every power domain. This also removes the
> following debugfs error message.
> 
>   [    2.242068] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!
>   [    2.249949] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!
>   [    2.257784] debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!
>   ...
> 
> Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains")
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

Whole series applied to v5.12-next/soc

Thanks a lot!
Matthias

> ---
> 
>  drivers/soc/mediatek/mt8173-pm-domains.h | 10 ++++++++++
>  drivers/soc/mediatek/mtk-pm-domains.c    |  6 +++++-
>  drivers/soc/mediatek/mtk-pm-domains.h    |  2 ++
>  3 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mt8173-pm-domains.h b/drivers/soc/mediatek/mt8173-pm-domains.h
> index 3e8ee5dabb43..654c717e5467 100644
> --- a/drivers/soc/mediatek/mt8173-pm-domains.h
> +++ b/drivers/soc/mediatek/mt8173-pm-domains.h
> @@ -12,24 +12,28 @@
>  
>  static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
>  	[MT8173_POWER_DOMAIN_VDEC] = {
> +		.name = "vdec",
>  		.sta_mask = PWR_STATUS_VDEC,
>  		.ctl_offs = SPM_VDE_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(12, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_VENC] = {
> +		.name = "venc",
>  		.sta_mask = PWR_STATUS_VENC,
>  		.ctl_offs = SPM_VEN_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(15, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_ISP] = {
> +		.name = "isp",
>  		.sta_mask = PWR_STATUS_ISP,
>  		.ctl_offs = SPM_ISP_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(13, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_MM] = {
> +		.name = "mm",
>  		.sta_mask = PWR_STATUS_DISP,
>  		.ctl_offs = SPM_DIS_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
> @@ -40,18 +44,21 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
>  		},
>  	},
>  	[MT8173_POWER_DOMAIN_VENC_LT] = {
> +		.name = "venc_lt",
>  		.sta_mask = PWR_STATUS_VENC_LT,
>  		.ctl_offs = SPM_VEN2_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(15, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_AUDIO] = {
> +		.name = "audio",
>  		.sta_mask = PWR_STATUS_AUDIO,
>  		.ctl_offs = SPM_AUDIO_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(15, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_USB] = {
> +		.name = "usb",
>  		.sta_mask = PWR_STATUS_USB,
>  		.ctl_offs = SPM_USB_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
> @@ -59,18 +66,21 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
>  		.caps = MTK_SCPD_ACTIVE_WAKEUP,
>  	},
>  	[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
> +		.name = "mfg_async",
>  		.sta_mask = PWR_STATUS_MFG_ASYNC,
>  		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = 0,
>  	},
>  	[MT8173_POWER_DOMAIN_MFG_2D] = {
> +		.name = "mfg_2d",
>  		.sta_mask = PWR_STATUS_MFG_2D,
>  		.ctl_offs = SPM_MFG_2D_PWR_CON,
>  		.sram_pdn_bits = GENMASK(11, 8),
>  		.sram_pdn_ack_bits = GENMASK(13, 12),
>  	},
>  	[MT8173_POWER_DOMAIN_MFG] = {
> +		.name = "mfg",
>  		.sta_mask = PWR_STATUS_MFG,
>  		.ctl_offs = SPM_MFG_PWR_CON,
>  		.sram_pdn_bits = GENMASK(13, 8),
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
> index b7f697666bdd..694d6ea6de1d 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.c
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> @@ -438,7 +438,11 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
>  		goto err_unprepare_subsys_clocks;
>  	}
>  
> -	pd->genpd.name = node->name;
> +	if (!pd->data->name)
> +		pd->genpd.name = node->name;
> +	else
> +		pd->genpd.name = pd->data->name;
> +
>  	pd->genpd.power_off = scpsys_power_off;
>  	pd->genpd.power_on = scpsys_power_on;
>  
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h b/drivers/soc/mediatek/mtk-pm-domains.h
> index 141dc76054e6..21a4e113bbec 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -76,6 +76,7 @@ struct scpsys_bus_prot_data {
>  
>  /**
>   * struct scpsys_domain_data - scp domain data for power on/off flow
> + * @name: The name of the power domain.
>   * @sta_mask: The mask for power on/off status bit.
>   * @ctl_offs: The offset for main power control register.
>   * @sram_pdn_bits: The mask for sram power control bits.
> @@ -85,6 +86,7 @@ struct scpsys_bus_prot_data {
>   * @bp_smi: bus protection for smi subsystem
>   */
>  struct scpsys_domain_data {
> +	const char *name;
>  	u32 sta_mask;
>  	int ctl_offs;
>  	u32 sram_pdn_bits;
> 


From matthias.bgg at gmail.com  Thu Apr  1 10:38:44 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:38:44 +0200
Subject: [PATCH] arm64: dts: mt8183: Add power-domains properity to mfgcfg
In-Reply-To: <CAFqH_50BWF4sQnJAnVZDf3Dbuw+LaN67q39DvOh7ipzqNeNEMw@mail.gmail.com>
References: <20210224091742.1060508-1-ikjn@chromium.org>
 <CAFqH_50BWF4sQnJAnVZDf3Dbuw+LaN67q39DvOh7ipzqNeNEMw@mail.gmail.com>
Message-ID: <6df6486e-89fc-6ea8-2b36-59e2bf49eb3a@gmail.com>



On 24/02/2021 11:30, Enric Balletbo Serra wrote:
> Hi Ikjoon,
> 
> Thank you for your patch.
> 
> Missatge de Ikjoon Jang <ikjn at chromium.org> del dia dc., 24 de febr.
> 2021 a les 10:21:
>>
>> mfgcfg clock is under MFG_ASYNC power domain
>>
>> Signed-off-by: Weiyi Lu <weiyi.lu at mediatek.com>
>> Signed-off-by: Ikjoon Jang <ikjn at chromium.org>
>> ---
>>
>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> index 5b782a4769e7..3384df5284c0 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> @@ -962,6 +962,7 @@ mfgcfg: syscon at 13000000 {
>>                         compatible = "mediatek,mt8183-mfgcfg", "syscon";
>>                         reg = <0 0x13000000 0 0x1000>;
>>                         #clock-cells = <1>;
>> +                       power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_ASYNC>;
> 
> I don't think this will work in mainline, at least, the reference name
> should be &spm
> 

Correct. Would you mind to resend with the comment from Enric. Apart from that,
patch looks fine to me.

Regards,
Matthias

> Thanks,
>   Enric
>>                 };
>>
>>                 mmsys: syscon at 14000000 {
>> --
>> 2.30.0.617.g56c4b15f3c-goog
>>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From Claudiu.Beznea at microchip.com  Thu Apr  1 10:38:56 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 1 Apr 2021 09:38:56 +0000
Subject: [PATCH 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <YGSc1L8yW0KniOsx@piout.net>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-23-claudiu.beznea@microchip.com>
 <YGSc1L8yW0KniOsx@piout.net>
Message-ID: <a908274a-c4d2-faab-54a4-31fd0ffeab7e@microchip.com>

On 31.03.2021 19:01, Alexandre Belloni wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 31/03/2021 13:59:06+0300, Claudiu Beznea wrote:
>> From: Eugen Hristev <eugen.hristev at microchip.com>
>>
>> Introduce new family of SoCs, sama7, and first SoC, sama7g5.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
>>  arch/arm/mach-at91/Makefile |  1 +
>>  arch/arm/mach-at91/sama7.c  | 48 +++++++++++++++++++++++++++++++++++++
>>  2 files changed, 49 insertions(+)
>>  create mode 100644 arch/arm/mach-at91/sama7.c
>>
>> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
>> index f565490f1b70..6cc6624cddac 100644
>> --- a/arch/arm/mach-at91/Makefile
>> +++ b/arch/arm/mach-at91/Makefile
>> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_AT91SAM9)    += at91sam9.o
>>  obj-$(CONFIG_SOC_SAM9X60)    += sam9x60.o
>>  obj-$(CONFIG_SOC_SAMA5)              += sama5.o
>>  obj-$(CONFIG_SOC_SAMV7)              += samv7.o
>> +obj-$(CONFIG_SOC_SAMA7)              += sama7.o
>>
>>  # Power Management
>>  obj-$(CONFIG_ATMEL_PM)               += pm.o pm_suspend.o
>> diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
>> new file mode 100644
>> index 000000000000..e04cadb569ad
>> --- /dev/null
>> +++ b/arch/arm/mach-at91/sama7.c
>> @@ -0,0 +1,48 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Setup code for SAMA7
>> + *
>> + * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
>> + *
>> + */
>> +
>> +#include <linux/of.h>
>> +#include <linux/of_platform.h>
>> +
>> +#include <asm/mach/arch.h>
>> +#include <asm/system_misc.h>
>> +
>> +#include "generic.h"
>> +
>> +static void __init sama7_common_init(void)
>> +{
>> +     of_platform_default_populate(NULL, NULL, NULL);
> 
> Is this necessary? This is left as a workaround for the old SoCs using
> pinctrl-at91. I guess this will be using pio4 so this has to be removed.

OK, I'll have a look. BTW, SAMA5D2 which is also using PIO4 calls
of_platform_default_populate(NULL, NULL, NULL);

> 
>> +}
>> +
>> +static void __init sama7_dt_device_init(void)
>> +{
>> +     sama7_common_init();
>> +}
>> +
>> +static const char *const sama7_dt_board_compat[] __initconst = {
>> +     "microchip,sama7",
>> +     NULL
>> +};
>> +
>> +DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
>> +     /* Maintainer: Microchip */
>> +     .init_machine   = sama7_dt_device_init,
>> +     .dt_compat      = sama7_dt_board_compat,
>> +MACHINE_END
>> +
>> +static const char *const sama7g5_dt_board_compat[] __initconst = {
>> +     "microchip,sama7g5",
>> +     NULL
>> +};
>> +
>> +DT_MACHINE_START(sama7g5_dt, "Microchip SAMA7G5")
>> +     /* Maintainer: Microchip */
>> +     .init_machine   = sama7_dt_device_init,
>> +     .dt_compat      = sama7g5_dt_board_compat,
>> +MACHINE_END
>> +
>> --
>> 2.25.1
>>
> 
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 


From maxime at cerno.tech  Thu Apr  1 10:39:39 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 1 Apr 2021 11:39:39 +0200
Subject: [PATCH v3 2/4] ARM: dts: sun8i: r40: add pinmux settings for
 MMC3 and UARTs 2,4,5&7
In-Reply-To: <20210331155616.793550-3-i.uvarov@cognitivepilot.com>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-3-i.uvarov@cognitivepilot.com>
Message-ID: <20210401093939.b7i3h75kdtk5f7uj@gilmour>

Hi,

On Wed, Mar 31, 2021 at 06:56:14PM +0300, Ivan Uvarov wrote:
> The Forlinx OKA40i-C devboard makes use of UARTs 0,2,3,4,5 and 7 of the R40
> SoC, of which UART 0 is connected to an RS232 converter, UART 5 routed to
> an RS485 converter, and the rest broken out directly via labeled headers.
> The board also contains a micro-SD slot connected to SDC3.
> 
> This patch adds settings to R40's pinmux node for those UARTs that were not
> already mapped, which would allow us to make use of all available UARTs and
> the micro-SD slot on this board in a further patch.
> 
> Reviewed-by: Andre Przywara <andre.przywara at arm.com>
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  1 file changed, 40 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
> index 0b257a0779..51031a0e59 100644
> --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> @@ -357,6 +357,8 @@ mmc3: mmc at 1c12000 {
>  			clock-names = "ahb", "mmc";
>  			resets = <&ccu RST_BUS_MMC3>;
>  			reset-names = "ahb";
> +			pinctrl-0 = <&mmc3_pins>;
> +			pinctrl-names = "default";
>  			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
>  			status = "disabled";
>  			#address-cells = <1>;
> @@ -601,6 +603,14 @@ mmc2_pins: mmc2-pins {
>  				bias-pull-up;
>  			};
>  
> +			mmc3_pins: mmc3-pins {
> +				pins = "PI4", "PI5", "PI6",
> +				       "PI7", "PI8", "PI9";
> +				function = "mmc3";
> +				drive-strength = <30>;
> +				bias-pull-up;
> +			};

I'd put omit-if-no-ref there too

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/20210401/424f9924/attachment.sig>

From matthias.bgg at gmail.com  Thu Apr  1 10:39:51 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 11:39:51 +0200
Subject: [PATCH] arm64: dts: mediatek: fix reset GPIO level on pumpkin
In-Reply-To: <20210223221826.2063911-1-fparent@baylibre.com>
References: <20210223221826.2063911-1-fparent@baylibre.com>
Message-ID: <46f49f9e-20a6-ea3b-a3c2-2249cdd3613b@gmail.com>



On 23/02/2021 23:18, Fabien Parent wrote:
> The tca6416 chip is active low. Fix the reset-gpios value.
> 
> Fixes: e2a8fa1e0faa ("arm64: dts: mediatek: fix tca6416 reset GPIOs in pumpkin")
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Applied to v5.12-next/dts64

Thanks!

> ---
>  arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> index 63fd70086bb8..9f27e7ed5e22 100644
> --- a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
> @@ -56,7 +56,7 @@ &i2c0 {
>  	tca6416: gpio at 20 {
>  		compatible = "ti,tca6416";
>  		reg = <0x20>;
> -		reset-gpios = <&pio 65 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&pio 65 GPIO_ACTIVE_LOW>;
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&tca6416_pins>;
>  
> 


From maxime at cerno.tech  Thu Apr  1 10:40:01 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 1 Apr 2021 11:40:01 +0200
Subject: [PATCH v3 3/4] dt-bindings: arm: add compatible strings for
 Forlinx OKA40i-C
In-Reply-To: <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
Message-ID: <20210401094001.sh3nvkj5psbdcig5@gilmour>

On Wed, Mar 31, 2021 at 06:56:15PM +0300, Ivan Uvarov wrote:
> The OKA40i-C is a carrier/development board for the Forlinx FETA40i-C SoM
> based on the Allwinner R40/A40i SoC.
> 
> This patch adds the relevant dt-binding documentation in preparation for
> the next patch, which adds a devicetree for the SoM and board.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
> index 08607c7ec1..74f8decd78 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
> @@ -224,6 +224,12 @@ properties:
>            - const: empire-electronix,m712
>            - const: allwinner,sun5i-a13
>  
> +      - description: Forlinx OKA40i-C Development board
> +        items:
> +          - const: forlinx,oka40i-c
> +          - const: forlinx,feta40i-c
> +          - const: allwinner,sun8i-r40
> +
>        - description: FriendlyARM NanoPi A64
>          items:
>            - const: friendlyarm,nanopi-a64
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index f6064d84a4..e2ea1a731e 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -403,6 +403,8 @@ patternProperties:
>      description: Firefly
>    "^focaltech,.*":
>      description: FocalTech Systems Co.,Ltd
> +  "^forlinx,.*":
> +    description: Baoding Forlinx Embedded Technology Co., Ltd.
>    "^frida,.*":
>      description: Shenzhen Frida LCD Co., Ltd.
>    "^friendlyarm,.*":
> -- 
> 2.25.1

This part needs to be in a separate patch too

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/20210401/6c751db3/attachment.sig>

From cristian.ciocaltea at gmail.com  Thu Apr  1 10:40:41 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 12:40:41 +0300
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <20210401052438.GB14052@work>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work>
Message-ID: <20210401094041.GA1993499@BV030612LT>

Hi Mani,

On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> > This patchset adds a socinfo driver which provides information about
> > Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> > serial_number.
> > 
> > Please note the serial number is currently available only for the S500
> > SoC variant.
> > 
> > This has been tested on the S500 SoC based RoseapplePi SBC.
> > 
> 
> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
> what basis it provides? I don't think the SoC has the provision for
> soc_id based on HW parameters.

No, the soc_id is not provided by the bootloader, or at least I couldn't
identify any related implementation. Instead, I provided this via the
driver itself, since I've encountered this approach in some other soc
drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 

Thanks,
Cristi

> Thanks,
> Mani
 
[...]


From alexandre.torgue at foss.st.com  Thu Apr  1 10:43:15 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 1 Apr 2021 11:43:15 +0200
Subject: [PATCH] ARM: dts: stm32: Add PTP clock to Ethernet controller
In-Reply-To: <20210316080644.19809-1-kurt@linutronix.de>
References: <20210316080644.19809-1-kurt@linutronix.de>
Message-ID: <ce610592-3d91-e5ad-ffe9-b8567af886f1@foss.st.com>

Hi Kurt

On 3/16/21 9:06 AM, Kurt Kanzenbach wrote:
> Add the PTP clock to the Ethernet controller. Otherwise, the driver uses the
> main clock to derive the PTP frequency which is not necessarily the correct one.
> 
> Tested with linuxptp on Olimex STMP1-OLinuXino-LIME2.
> 
> Signed-off-by: Kurt Kanzenbach <kurt at linutronix.de>
> ---
>   arch/arm/boot/dts/stm32mp151.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
> index 3c75abacb374..d1f596ea2fd5 100644
> --- a/arch/arm/boot/dts/stm32mp151.dtsi
> +++ b/arch/arm/boot/dts/stm32mp151.dtsi
> @@ -1421,11 +1421,13 @@
>   				      "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;
> 

Applied on stm32-next.

Thanks.
Alex


From maxime at cerno.tech  Thu Apr  1 10:43:56 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 1 Apr 2021 11:43:56 +0200
Subject: [PATCH v3 4/4] ARM: dts: sun8i: r40: add devicetree for Forlinx
 FETA40i-C & OKA40i-C
In-Reply-To: <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
Message-ID: <20210401094356.zhijxfoihw73ha7k@gilmour>

On Wed, Mar 31, 2021 at 06:56:16PM +0300, Ivan Uvarov wrote:
> The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i.
> 
> SoM specifications:
> 
> - SoC: R40 or A40i
> - PMIC: AXP221S
> - RAM: 1GiB/2GiB DDR3 (dual-rank)
> - eMMC: 8GB,
> - Mates with carrier board via four 80-pin connectors (AXK6F80337YG).
> 
> OKA40i-C is a carrier board by the same manufacturer for this SoM,
> whose main purpose is as a development board with a wide variety of
> peripherals:
> 
> - Power: DC5V barrel or USB OTG or 4.2V Lipo battery
> - Video out: HDMI, TV out, LVDS
> - WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
> - Ethernet: 10/100Mbps
> - Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
> - USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
> - UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
> - Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
> - Mini PCIe slot with sim holder for WLAN modem
> - Smart card holder
> - RTC (RX8010SJ)
> - Two user LEDs
> - Three user buttons (via KeyADC).
> 
> This patch adds a devicetree for the aforementioned SoM and devboard.
> In order to reflect the modularity of this devboard and simplify adding
> support for future hardware based on the same SoM, the devicetree is split:
> Everything pertaining to the SoM itself is described in a separate .dtsi
> file, which is included by the devboard's .dts.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  3 files changed, 310 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e7..88aae9de95 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1222,6 +1222,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-r16-nintendo-super-nes-classic.dtb \
>  	sun8i-r16-parrot.dtb \
>  	sun8i-r40-bananapi-m2-ultra.dtb \
> +	sun8i-r40-oka40i-c.dtb \
>  	sun8i-s3-elimo-initium.dtb \
>  	sun8i-s3-lichee-zero-plus.dtb \
>  	sun8i-s3-pinecube.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> new file mode 100644
> index 0000000000..265e0fa57a
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> +//  Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> +//  Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> +
> +#include "sun8i-r40.dtsi"
> +
> +&i2c0 {
> +	status = "okay";
> +
> +	axp22x: pmic at 34 {
> +		compatible = "x-powers,axp221";
> +		reg = <0x34>;
> +		interrupt-parent = <&nmi_intc>;
> +		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +	};
> +};
> +
> +#include "axp22x.dtsi"
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_aldo2>;
> +	bus-width = <8>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&pio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&clk_out_a_pin>;
> +	vcc-pa-supply = <&reg_dcdc1>;
> +	vcc-pc-supply = <&reg_aldo2>;
> +	vcc-pd-supply = <&reg_dcdc1>;
> +	vcc-pf-supply = <&reg_dldo4>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vcc-pa";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3000000>;
> +	regulator-max-microvolt = <3000000>;
> +	regulator-name = "avcc";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpu";
> +};
> +
> +&reg_dcdc3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};
> +
> +&reg_dldo1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi-io";
> +};
> +
> +&reg_dldo4 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <2500000>;
> +	regulator-max-microvolt = <2500000>;
> +	regulator-name = "vdd2v5-sata";
> +};
> +
> +&reg_eldo2 {
> +	regulator-min-microvolt = <1200000>;
> +	regulator-max-microvolt = <1200000>;
> +	regulator-name = "vdd1v2-sata";
> +};
> +
> +&reg_eldo3 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-name = "vcc-pe";
> +};
> diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> new file mode 100644
> index 0000000000..9305fda8d1
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> +//	Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> +//	Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> +
> +/dts-v1/;
> +#include "sun8i-r40-feta40i.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +	model = "Forlinx OKA40i-C";
> +	compatible = "forlinx,oka40i-c", "forlinx,feta40i-c", "allwinner,sun8i-r40";
> +
> +	aliases {
> +		ethernet0 = &gmac;
> +		serial0 = &uart0;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5; /* RS485 */
> +		serial7 = &uart7;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	connector {
> +		compatible = "hdmi-connector";
> +		type = "a";
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-5 {
> +			gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /* PH26 */
> +			color = <LED_COLOR_ID_GREEN>;
> +			function = LED_FUNCTION_STATUS;
> +		};
> +
> +		led-6 {
> +			gpios = <&pio 8 15 GPIO_ACTIVE_LOW>; /* PI15 */
> +			color = <LED_COLOR_ID_BLUE>;
> +			function = LED_FUNCTION_STATUS;
> +		};

led-5 and led-6? You can start at 0 :)

Looks good otherwise, 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/20210401/0382d2b1/attachment.sig>

From cristian.ciocaltea at gmail.com  Thu Apr  1 10:44:15 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 12:44:15 +0300
Subject: [PATCH 1/1] arm: dts: owl-s500-roseapplepi: Add ATC2603C PMIC
In-Reply-To: <20210401052929.GC14052@work>
References: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
 <20210401052929.GC14052@work>
Message-ID: <20210401094415.GB1993499@BV030612LT>

On Thu, Apr 01, 2021 at 10:59:29AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 12, 2021 at 11:49:27AM +0200, Cristian Ciocaltea wrote:
> > Add device tree node for ATC2603C PMIC and remove the 'fixed-3.1V'
> > dummy regulator used for the uSD supply.
> > 
> > Additionally, add 'SYSPWR' fixed regulator and provide cpu0 supply.
> > 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> 
> Reviewed-by: Manivannan Sadhasivam <mani at kernel.org>

Thanks for reviewing,
Cristi

> Thanks,
> Mani

[...]


From jiapeng.chong at linux.alibaba.com  Thu Apr  1 10:53:36 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Thu,  1 Apr 2021 17:53:36 +0800
Subject: [PATCH] dmaengine: qcom_hidma: remove unused code
Message-ID: <1617270816-36400-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following clang warning:

drivers/dma/qcom/hidma.c:94:20: warning: unused function 'to_hidma_desc'
[-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/dma/qcom/hidma.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 6c0f9eb..23d6448 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -90,12 +90,6 @@ static inline struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
 	return container_of(dmach, struct hidma_chan, chan);
 }
 
-static inline
-struct hidma_desc *to_hidma_desc(struct dma_async_tx_descriptor *t)
-{
-	return container_of(t, struct hidma_desc, desc);
-}
-
 static void hidma_free(struct hidma_dev *dmadev)
 {
 	INIT_LIST_HEAD(&dmadev->ddev.channels);
-- 
1.8.3.1



From cristian.ciocaltea at gmail.com  Thu Apr  1 10:59:08 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 12:59:08 +0300
Subject: [PATCH 1/1] arm: dts: owl-s500-roseapplepi: Add ATC2603C PMIC
In-Reply-To: <20210401054300.GD14052@work>
References: <2e0a2931ae3757f016948e7c78e8e54afa325ae0.1615538629.git.cristian.ciocaltea@gmail.com>
 <20210401054300.GD14052@work>
Message-ID: <20210401095908.GC1993499@BV030612LT>

On Thu, Apr 01, 2021 at 11:13:00AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 12, 2021 at 11:49:27AM +0200, Cristian Ciocaltea wrote:
> > Add device tree node for ATC2603C PMIC and remove the 'fixed-3.1V'
> > dummy regulator used for the uSD supply.
> > 
> > Additionally, add 'SYSPWR' fixed regulator and provide cpu0 supply.
> > 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> 
> Applied to for-next after fixing the patch subject as below:
> 
> "ARM: dts: owl-s500-roseapplepi: Add ATC2603C PMIC"

I encountered commits with both "ARM: dts:" and "arm: dts:" prefixes,
so I wasn't sure if there is a preferred format.

I have just counted the no. of occurrences in git log for both variants
and it seems the former is indeed more common, so I will make sure to
use "ARM: ..." from now on.

Thanks for noticing this,
Cristi

> Thanks,
> Mani

[...]


From hch at lst.de  Thu Apr  1 10:59:45 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu, 1 Apr 2021 11:59:45 +0200
Subject: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
In-Reply-To: <81dd27fe-28ee-c800-fe5d-aaa64cb93513@arm.com>
References: <20210316153825.135976-1-hch@lst.de>
 <20210316153825.135976-17-hch@lst.de>
 <20210330131149.GP5908@willie-the-truck>
 <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com>
 <20210330135801.GA6187@willie-the-truck>
 <578d6aa5-4239-f5d7-2e9f-686b18e52bba@arm.com>
 <20210331114947.GA7626@willie-the-truck>
 <ef895942-e115-7878-ab86-37e8a1614df5@arm.com>
 <20210331153256.GA7815@willie-the-truck>
 <81dd27fe-28ee-c800-fe5d-aaa64cb93513@arm.com>
Message-ID: <20210401095945.GA6726@lst.de>

For now I'll just pass the iommu_domain to iommu_get_dma_strict,
so that we can check for it.  We can do additional cleanups on top
of that later.


From broonie at kernel.org  Thu Apr  1 11:16:16 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 11:16:16 +0100
Subject: (subset) [PATCH 0/4] Convert Cadence QSPI bindings to yaml
In-Reply-To: <20210326130034.15231-1-p.yadav@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
Message-ID: <161726952255.2486.16196604421904035265.b4-ty@kernel.org>

On Fri, 26 Mar 2021 18:30:30 +0530, Pratyush Yadav wrote:
> This series picks up Ramuthevar's effort on converting the Cadence QSPI
> bindings to yaml [0]. During the conversion process, I discovered that
> some TI device tree files were not using the compatible correctly. Those
> are fixed in patches 1-3.
> 
> [0] https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthevar at linux.intel.com/
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[4/4] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
      commit: e54338004c032b0bb556c7a56db8688454b6587e

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 Apr  1 11:16:20 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 11:16:20 +0100
Subject: [PATCH v2] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210331151843.30583-1-bage@linutronix.de>
References: <20210331150622.GE4758@sirena.org.uk>
 <20210331151843.30583-1-bage@linutronix.de>
Message-ID: <161726938994.2219.2578765032151583218.b4-ty@kernel.org>

On Wed, 31 Mar 2021 17:18:43 +0200, bage at linutronix.de wrote:
> card->owner is a required property and since commit 81033c6b584b ("ALSA:
> core: Warn on empty module") a warning is issued if it is empty. Add it.
> This fixes following warning observed on Lamobo R1:
> 
> WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
> Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
> CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
> Hardware name: Allwinner sun7i (A20) Family
> Call trace:
>  (snd_card_new [snd])
>  (snd_soc_bind_card [snd_soc_core])
>  (snd_soc_register_card [snd_soc_core])
>  (sun4i_codec_probe [sun4i_codec])

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: sunxi: sun4i-codec: fill ASoC card owner
      commit: 7c0d6e482062eb5c06ecccfab340abc523bdca00

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 Apr  1 11:16:25 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 11:16:25 +0100
Subject: [PATCH] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210331145915.12545-1-bage@linutronix.de>
References: <20210331145915.12545-1-bage@linutronix.de>
Message-ID: <161726938994.2219.266176095597087685.b4-ty@kernel.org>

On Wed, 31 Mar 2021 16:59:15 +0200, bage at linutronix.de wrote:
> card->owner is a required property and since commit 81033c6b584b ("ALSA:
> core: Warn on empty module") a warning is issued if it is empty. Add it.
> This fixes following warning observed on Lamobo R1:
> 
> WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
> Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
> CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
> Hardware name: Allwinner sun7i (A20) Family
> [<c0ce8544>] (dump_backtrace) from [<c0ce88f0>] (show_stack+0x20/0x24)
> [<c0ce88d0>] (show_stack) from [<c0ceda20>] (dump_stack+0xc8/0xdc)
> [<c0ced958>] (dump_stack) from [<c034d49c>] (__warn+0xfc/0x158)
> [<c034d3a0>] (__warn) from [<c0ce966c>] (warn_slowpath_fmt+0x70/0xe4)
> [<c0ce9600>] (warn_slowpath_fmt) from [<bf48f604>] (snd_card_new+0x430/0x480 [snd])
> [<bf48f1d4>] (snd_card_new [snd]) from [<bf53340c>] (snd_soc_bind_card+0x3a8/0xa30 [snd_soc_core])
> [<bf533064>] (snd_soc_bind_card [snd_soc_core]) from [<bf533b8c>] (snd_soc_register_card+0xf8/0x108 [snd_soc_core])
> [<bf533a94>] (snd_soc_register_card [snd_soc_core]) from [<bf55b888>] (sun4i_codec_probe+0x224/0x45c [sun4i_codec])
> [<bf55b664>] (sun4i_codec_probe [sun4i_codec]) from [<c09879b4>] (platform_drv_probe+0x58/0xa8)
> [<c098795c>] (platform_drv_probe) from [<c0984dc8>] (really_probe+0x108/0x510)
> [<c0984cc0>] (really_probe) from [<c0985674>] (driver_probe_device+0x100/0x1d0)
> [<c0985574>] (driver_probe_device) from [<c0985a74>] (device_driver_attach+0xb8/0xc0)
> [<c09859bc>] (device_driver_attach) from [<c0985b18>] (__driver_attach+0x9c/0x150)
> [<c0985a7c>] (__driver_attach) from [<c09825c8>] (bus_for_each_dev+0x84/0xd0)
> [<c0982544>] (bus_for_each_dev) from [<c09844bc>] (driver_attach+0x2c/0x30)
> [<c0984490>] (driver_attach) from [<c0983e70>] (bus_add_driver+0x120/0x20c)
> [<c0983d50>] (bus_add_driver) from [<c098670c>] (driver_register+0x98/0x128)
> [<c0986674>] (driver_register) from [<c0987908>] (__platform_driver_register+0x50/0x58)
> [<c09878b8>] (__platform_driver_register) from [<bf566024>] (sun4i_codec_driver_init+0x24/0x1000 [sun4i_codec])
> [<bf566000>] (sun4i_codec_driver_init [sun4i_codec]) from [<c030293c>] (do_one_initcall+0x50/0x274)
> [<c03028ec>] (do_one_initcall) from [<c040d45c>] (do_init_module+0x70/0x294)
> [<c040d3ec>] (do_init_module) from [<c040f9f4>] (load_module+0x2258/0x263c)
> [<c040d79c>] (load_module) from [<c04100c0>] (sys_finit_module+0xc8/0x12c)
> [<c040fff8>] (sys_finit_module) from [<c03002a4>] (__sys_trace_return+0x0/0x1c)

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: sunxi: sun4i-codec: fill ASoC card owner
      commit: 7c0d6e482062eb5c06ecccfab340abc523bdca00

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 lorenzo.pieralisi at arm.com  Thu Apr  1 11:19:57 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 1 Apr 2021 11:19:57 +0100
Subject: [PATCH v3 03/14] PCI: rcar: Convert to MSI domains
In-Reply-To: <20210330151145.997953-4-maz@kernel.org>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-4-maz@kernel.org>
Message-ID: <20210401101957.GA30653@lpieralisi>

On Tue, Mar 30, 2021 at 04:11:34PM +0100, Marc Zyngier wrote:

[...]

> +static void rcar_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> +	struct rcar_msi *msi = irq_data_get_irq_chip_data(data);
> +	unsigned long pa = virt_to_phys(msi);
>  
> -	hwirq = rcar_msi_alloc_region(msi, nvec);
> -	if (hwirq < 0)
> -		return -ENOSPC;
> +	/* Use the msi structure as the PA for the MSI doorbell */
> +	msg->address_lo = lower_32_bits(pa);
> +	msg->address_hi = upper_32_bits(pa);

I don't think this change is aligned with the previous patch (is it ?),
the PA address we are using here is different from the one programmed
into the controller registers - either that or I am missing something,
please let me know.

Thanks,
Lorenzo

> +	msg->data = data->hwirq;
> +}
>  
> -	irq = irq_find_mapping(msi->domain, hwirq);
> -	if (!irq)
> -		return -ENOSPC;
> +static struct irq_chip rcar_msi_bottom_chip = {
> +	.name			= "Rcar MSI",
> +	.irq_ack		= rcar_msi_irq_ack,
> +	.irq_mask		= rcar_msi_irq_mask,
> +	.irq_unmask		= rcar_msi_irq_unmask,
> +	.irq_set_affinity 	= rcar_msi_set_affinity,
> +	.irq_compose_msi_msg	= rcar_compose_msi_msg,
> +};
>  
> -	for (i = 0; i < nvec; i++) {
> -		/*
> -		 * irq_create_mapping() called from rcar_pcie_probe() pre-
> -		 * allocates descs,  so there is no need to allocate descs here.
> -		 * We can therefore assume that if irq_find_mapping() above
> -		 * returns non-zero, then the descs are also successfully
> -		 * allocated.
> -		 */
> -		if (irq_set_msi_desc_off(irq, i, desc)) {
> -			/* TODO: clear */
> -			return -EINVAL;
> -		}
> -	}
> +static int rcar_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
> +				  unsigned int nr_irqs, void *args)
> +{
> +	struct rcar_msi *msi = domain->host_data;
> +	unsigned int i;
> +	int hwirq;
> +
> +	mutex_lock(&msi->map_lock);
>  
> -	desc->nvec_used = nvec;
> -	desc->msi_attrib.multiple = order_base_2(nvec);
> +	hwirq = bitmap_find_free_region(msi->used, INT_PCI_MSI_NR, order_base_2(nr_irqs));
>  
> -	msg.address_lo = rcar_pci_read_reg(pcie, PCIEMSIALR) & ~MSIFE;
> -	msg.address_hi = rcar_pci_read_reg(pcie, PCIEMSIAUR);
> -	msg.data = hwirq;
> +	mutex_unlock(&msi->map_lock);
> +
> +	if (hwirq < 0)
> +		return -ENOSPC;
>  
> -	pci_write_msi_msg(irq, &msg);
> +	for (i = 0; i < nr_irqs; i++)
> +		irq_domain_set_info(domain, virq + i, hwirq + i,
> +				    &rcar_msi_bottom_chip, domain->host_data,
> +				    handle_edge_irq, NULL, NULL);
>  
>  	return 0;
>  }
>  
> -static void rcar_msi_teardown_irq(struct msi_controller *chip, unsigned int irq)
> +static void rcar_msi_domain_free(struct irq_domain *domain, unsigned int virq,
> +				  unsigned int nr_irqs)
>  {
> -	struct rcar_msi *msi = to_rcar_msi(chip);
> -	struct irq_data *d = irq_get_irq_data(irq);
> +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> +	struct rcar_msi *msi = domain->host_data;
>  
> -	rcar_msi_free(msi, d->hwirq);
> -}
> -
> -static struct irq_chip rcar_msi_irq_chip = {
> -	.name = "R-Car PCIe MSI",
> -	.irq_enable = pci_msi_unmask_irq,
> -	.irq_disable = pci_msi_mask_irq,
> -	.irq_mask = pci_msi_mask_irq,
> -	.irq_unmask = pci_msi_unmask_irq,
> -};
> +	mutex_lock(&msi->map_lock);
>  
> -static int rcar_msi_map(struct irq_domain *domain, unsigned int irq,
> -			irq_hw_number_t hwirq)
> -{
> -	irq_set_chip_and_handler(irq, &rcar_msi_irq_chip, handle_simple_irq);
> -	irq_set_chip_data(irq, domain->host_data);
> +	bitmap_release_region(msi->used, d->hwirq, order_base_2(nr_irqs));
>  
> -	return 0;
> +	mutex_unlock(&msi->map_lock);
>  }
>  
> -static const struct irq_domain_ops msi_domain_ops = {
> -	.map = rcar_msi_map,
> +static const struct irq_domain_ops rcar_msi_domain_ops = {
> +	.alloc	= rcar_msi_domain_alloc,
> +	.free	= rcar_msi_domain_free,
> +};
> +
> +static struct msi_domain_info rcar_msi_info = {
> +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> +		   MSI_FLAG_MULTI_PCI_MSI),
> +	.chip	= &rcar_msi_top_chip,
>  };
>  
> -static void rcar_pcie_unmap_msi(struct rcar_pcie_host *host)
> +static int rcar_allocate_domains(struct rcar_msi *msi)
>  {
> -	struct rcar_msi *msi = &host->msi;
> -	int i, irq;
> +	struct rcar_pcie *pcie = &msi_to_host(msi)->pcie;
> +	struct fwnode_handle *fwnode = dev_fwnode(pcie->dev);
> +	struct irq_domain *parent;
> +
> +	parent = irq_domain_create_linear(fwnode, INT_PCI_MSI_NR,
> +					  &rcar_msi_domain_ops, msi);
> +	if (!parent) {
> +		dev_err(pcie->dev, "failed to create IRQ domain\n");
> +		return -ENOMEM;
> +	}
> +	irq_domain_update_bus_token(parent, DOMAIN_BUS_NEXUS);
>  
> -	for (i = 0; i < INT_PCI_MSI_NR; i++) {
> -		irq = irq_find_mapping(msi->domain, i);
> -		if (irq > 0)
> -			irq_dispose_mapping(irq);
> +	msi->domain = pci_msi_create_irq_domain(fwnode, &rcar_msi_info, parent);
> +	if (!msi->domain) {
> +		dev_err(pcie->dev, "failed to create MSI domain\n");
> +		irq_domain_remove(parent);
> +		return -ENOMEM;
>  	}
>  
> -	irq_domain_remove(msi->domain);
> +	return 0;
>  }
>  
> -static void rcar_pcie_hw_enable_msi(struct rcar_pcie_host *host)
> +static void rcar_free_domains(struct rcar_msi *msi)
>  {
> -	struct rcar_pcie *pcie = &host->pcie;
> -	struct device *dev = pcie->dev;
> -	struct resource res;
> +	struct irq_domain *parent = msi->domain->parent;
>  
> -	if (WARN_ON(of_address_to_resource(dev->of_node, 0, &res)))
> -		return;
> -
> -	/* setup MSI data target */
> -	rcar_pci_write_reg(pcie, lower_32_bits(res.start) | MSIFE, PCIEMSIALR);
> -	rcar_pci_write_reg(pcie, upper_32_bits(res.start), PCIEMSIAUR);
> -
> -	/* enable all MSI interrupts */
> -	rcar_pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
> +	irq_domain_remove(msi->domain);
> +	irq_domain_remove(parent);
>  }
>  
>  static int rcar_pcie_enable_msi(struct rcar_pcie_host *host)
> @@ -698,29 +675,24 @@ static int rcar_pcie_enable_msi(struct rcar_pcie_host *host)
>  	struct rcar_pcie *pcie = &host->pcie;
>  	struct device *dev = pcie->dev;
>  	struct rcar_msi *msi = &host->msi;
> -	int err, i;
> -
> -	mutex_init(&msi->lock);
> +	struct resource res;
> +	int err;
>  
> -	msi->chip.dev = dev;
> -	msi->chip.setup_irq = rcar_msi_setup_irq;
> -	msi->chip.setup_irqs = rcar_msi_setup_irqs;
> -	msi->chip.teardown_irq = rcar_msi_teardown_irq;
> +	mutex_init(&msi->map_lock);
> +	spin_lock_init(&msi->mask_lock);
>  
> -	msi->domain = irq_domain_add_linear(dev->of_node, INT_PCI_MSI_NR,
> -					    &msi_domain_ops, &msi->chip);
> -	if (!msi->domain) {
> -		dev_err(dev, "failed to create IRQ domain\n");
> -		return -ENOMEM;
> -	}
> +	err = of_address_to_resource(dev->of_node, 0, &res);
> +	if (err)
> +		return err;
>  
> -	for (i = 0; i < INT_PCI_MSI_NR; i++)
> -		irq_create_mapping(msi->domain, i);
> +	err = rcar_allocate_domains(msi);
> +	if (err)
> +		return err;
>  
>  	/* Two irqs are for MSI, but they are also used for non-MSI irqs */
>  	err = devm_request_irq(dev, msi->irq1, rcar_pcie_msi_irq,
>  			       IRQF_SHARED | IRQF_NO_THREAD,
> -			       rcar_msi_irq_chip.name, host);
> +			       rcar_msi_bottom_chip.name, host);
>  	if (err < 0) {
>  		dev_err(dev, "failed to request IRQ: %d\n", err);
>  		goto err;
> @@ -728,19 +700,26 @@ static int rcar_pcie_enable_msi(struct rcar_pcie_host *host)
>  
>  	err = devm_request_irq(dev, msi->irq2, rcar_pcie_msi_irq,
>  			       IRQF_SHARED | IRQF_NO_THREAD,
> -			       rcar_msi_irq_chip.name, host);
> +			       rcar_msi_bottom_chip.name, host);
>  	if (err < 0) {
>  		dev_err(dev, "failed to request IRQ: %d\n", err);
>  		goto err;
>  	}
>  
> -	/* setup MSI data target */
> -	rcar_pcie_hw_enable_msi(host);
> +	/* disable all MSIs */
> +	rcar_pci_write_reg(pcie, 0, PCIEMSIIER);
> +
> +	/*
> +	 * Setup MSI data target using RC base address address, which
> +	 * is guaranteed to be in the low 32bit range on any RCar HW.
> +	 */
> +	rcar_pci_write_reg(pcie, lower_32_bits(res.start) | MSIFE, PCIEMSIALR);
> +	rcar_pci_write_reg(pcie, upper_32_bits(res.start), PCIEMSIAUR);
>  
>  	return 0;
>  
>  err:
> -	rcar_pcie_unmap_msi(host);
> +	rcar_free_domains(msi);
>  	return err;
>  }
>  
> @@ -754,7 +733,7 @@ static void rcar_pcie_teardown_msi(struct rcar_pcie_host *host)
>  	/* Disable address decoding of the MSI interrupt, MSIFE */
>  	rcar_pci_write_reg(pcie, 0, PCIEMSIALR);
>  
> -	rcar_pcie_unmap_msi(host);
> +	rcar_free_domains(&host->msi);
>  }
>  
>  static int rcar_pcie_get_resources(struct rcar_pcie_host *host)
> @@ -1007,8 +986,17 @@ static int __maybe_unused rcar_pcie_resume(struct device *dev)
>  	dev_info(dev, "PCIe x%d: link up\n", (data >> 20) & 0x3f);
>  
>  	/* Enable MSI */
> -	if (IS_ENABLED(CONFIG_PCI_MSI))
> -		rcar_pcie_hw_enable_msi(host);
> +	if (IS_ENABLED(CONFIG_PCI_MSI)) {
> +		struct resource res;
> +		u32 val;
> +
> +		of_address_to_resource(dev->of_node, 0, &res);
> +		rcar_pci_write_reg(pcie, upper_32_bits(res.start), PCIEMSIAUR);
> +		rcar_pci_write_reg(pcie, lower_32_bits(res.start) | MSIFE, PCIEMSIALR);
> +
> +		bitmap_to_arr32(&val, host->msi.used, INT_PCI_MSI_NR);
> +		rcar_pci_write_reg(pcie, val, PCIEMSIIER);
> +	}
>  
>  	rcar_pcie_hw_enable(host);
>  
> -- 
> 2.29.2
> 


From yangyingliang at huawei.com  Thu Apr  1 11:26:07 2021
From: yangyingliang at huawei.com (Yang Yingliang)
Date: Thu, 1 Apr 2021 18:26:07 +0800
Subject: [PATCH -next] media: imx-pxp: remove redundant dev_err call in
 pxp_probe()
Message-ID: <20210401102607.1554006-1-yangyingliang@huawei.com>

There is an error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang at huawei.com>
---
 drivers/media/platform/imx-pxp.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/imx-pxp.c b/drivers/media/platform/imx-pxp.c
index 08d76eb05ed1..13bc88e9358e 100644
--- a/drivers/media/platform/imx-pxp.c
+++ b/drivers/media/platform/imx-pxp.c
@@ -1654,11 +1654,8 @@ static int pxp_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	dev->mmio = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(dev->mmio)) {
-		ret = PTR_ERR(dev->mmio);
-		dev_err(&pdev->dev, "Failed to map register space: %d\n", ret);
-		return ret;
-	}
+	if (IS_ERR(dev->mmio))
+		return PTR_ERR(dev->mmio);
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0)
-- 
2.25.1



From arnd at kernel.org  Thu Apr  1 11:23:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:26 +0200
Subject: [PATCH] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210323131814.2751750-1-arnd@kernel.org>
References: <20210323131814.2751750-1-arnd@kernel.org>
Message-ID: <161727243810.583633.10194693313914787410.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 23 Mar 2021 14:18:05 +0100, Arnd Bergmann wrote:
> clang warns about an impossible condition when building with 32-bit
> phys_addr_t:
> 
> arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
>             mem_end   > KEYSTONE_HIGH_PHYS_END) {
>             ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
> arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
>         if (mem_start < KEYSTONE_HIGH_PHYS_START ||
>             ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~
> 
> [...]

Applied to arm/fixes

[1/1] ARM: keystone: fix integer overflow warning
      commit: 04e18e1cc319f453a6d752d4553bb3f29fde5f76

       Arnd


From arnd at kernel.org  Thu Apr  1 11:23:28 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:28 +0200
Subject: [PATCH] ARM: omap1: fix building with clang IAS
In-Reply-To: <20210308153430.2530616-1-arnd@kernel.org>
References: <20210308153430.2530616-1-arnd@kernel.org>
Message-ID: <161727243810.583633.14191051174001891363.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 8 Mar 2021 16:34:21 +0100, Arnd Bergmann wrote:
> The clang integrated assembler fails to build one file with
> a complex asm instruction:
> 
> arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this:
>  mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
>  ^
> arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2
>  mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
>  ^
> arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2
>  mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
>  ^
> 
> [...]

Applied to arm/fixes.

[1/1] ARM: omap1: fix building with clang IAS
      commit: b897653a2fd4b7d0a77aa209d1e6b5cc08899bbf

       Arnd


From arnd at kernel.org  Thu Apr  1 11:23:29 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:29 +0200
Subject: [PATCH] ARM: pxa: mainstone: avoid -Woverride-init warning
In-Reply-To: <20210323130849.2362001-1-arnd@kernel.org>
References: <20210323130849.2362001-1-arnd@kernel.org>
Message-ID: <161727243811.583633.1536328285829233051.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 23 Mar 2021 14:08:27 +0100, Arnd Bergmann wrote:
> The default initializer at the start of the array causes a warning
> when building with W=1:
> 
> In file included from arch/arm/mach-pxa/mainstone.c:47:
> arch/arm/mach-pxa/mainstone.h:124:33: error: initialized field overwritten [-Werror=override-init]
>   124 | #define MAINSTONE_IRQ(x)        (MAINSTONE_NR_IRQS + (x))
>       |                                 ^
> arch/arm/mach-pxa/mainstone.h:133:33: note: in expansion of macro 'MAINSTONE_IRQ'
>   133 | #define MAINSTONE_S0_CD_IRQ     MAINSTONE_IRQ(9)
>       |                                 ^~~~~~~~~~~~~
> arch/arm/mach-pxa/mainstone.c:506:15: note: in expansion of macro 'MAINSTONE_S0_CD_IRQ'
>   506 |         [5] = MAINSTONE_S0_CD_IRQ,
>       |               ^~~~~~~~~~~~~~~~~~~
> 
> [...]

Applied to arm/fixes.

[1/1] ARM: pxa: mainstone: avoid -Woverride-init warning
      commit: b08f9cc97c8e1be0f06fc6e5d467ed389a4161ff

       Arnd


From arnd at kernel.org  Thu Apr  1 11:23:30 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:30 +0200
Subject: [PATCH] soc/fsl: qbman: fix conflicting alignment attributes
In-Reply-To: <20210323131530.2619900-1-arnd@kernel.org>
References: <20210323131530.2619900-1-arnd@kernel.org>
Message-ID: <161727243810.583633.4915294266076534019.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 23 Mar 2021 14:15:23 +0100, Arnd Bergmann wrote:
> When building with W=1, gcc points out that the __packed attribute
> on struct qm_eqcr_entry conflicts with the 8-byte alignment
> attribute on struct qm_fd inside it:
> 
> drivers/soc/fsl/qbman/qman.c:189:1: error: alignment 1 of 'struct qm_eqcr_entry' is less than 8 [-Werror=packed-not-aligned]
> 
> I assume that the alignment attribute is the correct one, and
> that qm_eqcr_entry cannot actually be unaligned in memory,
> so add the same alignment on the outer struct.

Applied to arm/fixes

[1/1] soc/fsl: qbman: fix conflicting alignment attributes
      commit: b9ab2619047edc1c6c07dc68963d84a5979f0abe

       Arnd


From arnd at kernel.org  Thu Apr  1 11:23:32 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:32 +0200
Subject: [GIT PULL] i.MX fixes for 5.12, round 2
In-Reply-To: <20210330090236.GQ22955@dragon>
References: <20210330090236.GQ22955@dragon>
Message-ID: <161727243755.583633.10590032736575762334.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 30 Mar 2021 17:02:37 +0800, Shawn Guo wrote:
> The following changes since commit e4817a1b6b77db538bc0141c3b138f2df803ce87:
> 
>   ARM: dts: imx6ull: fix ubi filesystem mount failed (2021-03-18 12:06:28 +0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-5.12-2
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: 89e21e1ad92373b7306b9b8494d45781598ce72f

       Arnd


From arnd at kernel.org  Thu Apr  1 11:23:33 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 12:23:33 +0200
Subject: [GIT PULL] More fixes for omaps for v5.12-rc cycle
In-Reply-To: <pull-1616584662-702939@atomide.com>
References: <pull-1616584662-702939@atomide.com>
Message-ID: <161727243717.583633.17499890750529623246.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 24 Mar 2021 13:20:39 +0200, Tony Lindgren wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.12/fixes-rc4-signed
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: 111a5a421fb770d0fc2e09f7d57eb2cbe51e3ade

       Arnd


From Claudiu.Beznea at microchip.com  Thu Apr  1 11:24:57 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 1 Apr 2021 10:24:57 +0000
Subject: [PATCH 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <a908274a-c4d2-faab-54a4-31fd0ffeab7e@microchip.com>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-23-claudiu.beznea@microchip.com>
 <YGSc1L8yW0KniOsx@piout.net>
 <a908274a-c4d2-faab-54a4-31fd0ffeab7e@microchip.com>
Message-ID: <21bd4417-a754-8ee6-370e-4fb4e0f1fef9@microchip.com>

On 01.04.2021 12:38, Claudiu Beznea - M18063 wrote:
> On 31.03.2021 19:01, Alexandre Belloni wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 31/03/2021 13:59:06+0300, Claudiu Beznea wrote:
>>> From: Eugen Hristev <eugen.hristev at microchip.com>
>>>
>>> Introduce new family of SoCs, sama7, and first SoC, sama7g5.
>>>
>>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>>> ---
>>>  arch/arm/mach-at91/Makefile |  1 +
>>>  arch/arm/mach-at91/sama7.c  | 48 +++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 49 insertions(+)
>>>  create mode 100644 arch/arm/mach-at91/sama7.c
>>>
>>> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
>>> index f565490f1b70..6cc6624cddac 100644
>>> --- a/arch/arm/mach-at91/Makefile
>>> +++ b/arch/arm/mach-at91/Makefile
>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_AT91SAM9)    += at91sam9.o
>>>  obj-$(CONFIG_SOC_SAM9X60)    += sam9x60.o
>>>  obj-$(CONFIG_SOC_SAMA5)              += sama5.o
>>>  obj-$(CONFIG_SOC_SAMV7)              += samv7.o
>>> +obj-$(CONFIG_SOC_SAMA7)              += sama7.o
>>>
>>>  # Power Management
>>>  obj-$(CONFIG_ATMEL_PM)               += pm.o pm_suspend.o
>>> diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
>>> new file mode 100644
>>> index 000000000000..e04cadb569ad
>>> --- /dev/null
>>> +++ b/arch/arm/mach-at91/sama7.c
>>> @@ -0,0 +1,48 @@
>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>> +/*
>>> + * Setup code for SAMA7
>>> + *
>>> + * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
>>> + *
>>> + */
>>> +
>>> +#include <linux/of.h>
>>> +#include <linux/of_platform.h>
>>> +
>>> +#include <asm/mach/arch.h>
>>> +#include <asm/system_misc.h>
>>> +
>>> +#include "generic.h"
>>> +
>>> +static void __init sama7_common_init(void)
>>> +{
>>> +     of_platform_default_populate(NULL, NULL, NULL);
>>
>> Is this necessary? This is left as a workaround for the old SoCs using
>> pinctrl-at91. I guess this will be using pio4 so this has to be removed.
> 
> OK, I'll have a look. BTW, SAMA5D2 which is also using PIO4 calls
> of_platform_default_populate(NULL, NULL, NULL);

Without this call the PM code (arch/arm/mach-at/pm.c) is not able to locate
proper DT nodes:

[    0.194615] at91_pm_backup_init: failed to find securam device!
[    0.201393] at91_pm_sram_init: failed to find sram device!
[    0.207449] AT91: PM not supported, due to no SRAM allocated

> 
>>
>>> +}
>>> +
>>> +static void __init sama7_dt_device_init(void)
>>> +{
>>> +     sama7_common_init();
>>> +}
>>> +
>>> +static const char *const sama7_dt_board_compat[] __initconst = {
>>> +     "microchip,sama7",
>>> +     NULL
>>> +};
>>> +
>>> +DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
>>> +     /* Maintainer: Microchip */
>>> +     .init_machine   = sama7_dt_device_init,
>>> +     .dt_compat      = sama7_dt_board_compat,
>>> +MACHINE_END
>>> +
>>> +static const char *const sama7g5_dt_board_compat[] __initconst = {
>>> +     "microchip,sama7g5",
>>> +     NULL
>>> +};
>>> +
>>> +DT_MACHINE_START(sama7g5_dt, "Microchip SAMA7G5")
>>> +     /* Maintainer: Microchip */
>>> +     .init_machine   = sama7_dt_device_init,
>>> +     .dt_compat      = sama7g5_dt_board_compat,
>>> +MACHINE_END
>>> +
>>> --
>>> 2.25.1
>>>
>>
>> --
>> Alexandre Belloni, co-owner and COO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>>
> 


From mani at kernel.org  Thu Apr  1 11:27:17 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 1 Apr 2021 15:57:17 +0530
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <20210401094041.GA1993499@BV030612LT>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work> <20210401094041.GA1993499@BV030612LT>
Message-ID: <20210401102717.GF14052@work>

On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote:
> Hi Mani,
> 
> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> > > This patchset adds a socinfo driver which provides information about
> > > Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> > > serial_number.
> > > 
> > > Please note the serial number is currently available only for the S500
> > > SoC variant.
> > > 
> > > This has been tested on the S500 SoC based RoseapplePi SBC.
> > > 
> > 
> > Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
> > what basis it provides? I don't think the SoC has the provision for
> > soc_id based on HW parameters.
> 
> No, the soc_id is not provided by the bootloader, or at least I couldn't
> identify any related implementation. Instead, I provided this via the
> driver itself, since I've encountered this approach in some other soc
> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 
> 

Sorry, I was referring to serial_number. Since your comment says so, can
you point to the corresponding code?

Thanks,
Mani

> Thanks,
> Cristi
> 
> > Thanks,
> > Mani
>  
> [...]


From wanjiabing at vivo.com  Thu Apr  1 11:31:14 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Thu,  1 Apr 2021 18:31:14 +0800
Subject: [PATCH] mfd: abx500: Remove repeated struct declaration
Message-ID: <20210401103114.1007550-1-wanjiabing@vivo.com>

struct ab8500_fg is declared twice. The blew one at 457th line
is closer to user. Remove the duplicate here.
Move "Forward declaration" annotation to the suitable place.

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 include/linux/mfd/abx500/ab8500-bm.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/mfd/abx500/ab8500-bm.h b/include/linux/mfd/abx500/ab8500-bm.h
index 903e94c189d8..0b88eddcc5af 100644
--- a/include/linux/mfd/abx500/ab8500-bm.h
+++ b/include/linux/mfd/abx500/ab8500-bm.h
@@ -296,9 +296,6 @@ struct batres_vs_temp {
 	int resist;
 };
 
-/* Forward declaration */
-struct ab8500_fg;
-
 /**
  * struct ab8500_fg_parameters - Fuel gauge algorithm parameters, in seconds
  * if not specified
@@ -452,6 +449,7 @@ struct ab8500_bm_data {
 	const struct ab8500_fg_parameters *fg_params;
 };
 
+/* Forward declaration */
 struct ab8500_btemp;
 struct ab8500_gpadc;
 struct ab8500_fg;
-- 
2.25.1



From Jonathan.Cameron at Huawei.com  Thu Apr  1 11:30:15 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 1 Apr 2021 11:30:15 +0100
Subject: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
In-Reply-To: <CAHp75VfgL0KW0fetgE3NuBb4itMK1oY+yLmr1xDYkn390hCscg@mail.gmail.com>
References: <20210401062517.28832-1-dmugil2000@gmail.com>
 <CAHp75VfgL0KW0fetgE3NuBb4itMK1oY+yLmr1xDYkn390hCscg@mail.gmail.com>
Message-ID: <20210401113015.00006b70@Huawei.com>

On Thu, 1 Apr 2021 12:24:50 +0300
Andy Shevchenko <andy.shevchenko at gmail.com> wrote:

> On Thu, Apr 1, 2021 at 9:27 AM Mugilraj Dhavachelvan
> <dmugil2000 at gmail.com> wrote:
> >
> > Change function's name to %s and __func__ to fix checkpatch.pl errors.  
> 
> No, just drop the __func__ completely. First of all, we have a device
> name, and uniqueness of the messages in the driver should guarantee
> easy findings. Second, specific to _dbg() variants, with enabled
> Dynamic Debug it can be chosen at run time!
> 
> I recommend going through all drivers and drop __func__ near to
> dev_dbg() and pr_debug().
> 

Agreed.  Though beware that some maintainers will count this
as noise and get grumpy.

I'm fine with such patches for IIO.

Jonathan


From yangyingliang at huawei.com  Thu Apr  1 11:35:00 2021
From: yangyingliang at huawei.com (Yang Yingliang)
Date: Thu, 1 Apr 2021 18:35:00 +0800
Subject: [PATCH -next] media: camss: csiphy: Remove redundant dev_err call in
 msm_csiphy_subdev_init()
Message-ID: <20210401103500.1558058-1-yangyingliang@huawei.com>

There is an error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang at huawei.com>
---
 drivers/media/platform/qcom/camss/camss-csiphy.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 6ceb6d7d53d1..b3c3bf19e522 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -593,20 +593,16 @@ int msm_csiphy_subdev_init(struct camss *camss,
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
 	csiphy->base = devm_ioremap_resource(dev, r);
-	if (IS_ERR(csiphy->base)) {
-		dev_err(dev, "could not map memory\n");
+	if (IS_ERR(csiphy->base))
 		return PTR_ERR(csiphy->base);
-	}
 
 	if (camss->version == CAMSS_8x16 ||
 	    camss->version == CAMSS_8x96) {
 		r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 						 res->reg[1]);
 		csiphy->base_clk_mux = devm_ioremap_resource(dev, r);
-		if (IS_ERR(csiphy->base_clk_mux)) {
-			dev_err(dev, "could not map memory\n");
+		if (IS_ERR(csiphy->base_clk_mux))
 			return PTR_ERR(csiphy->base_clk_mux);
-		}
 	} else {
 		csiphy->base_clk_mux = NULL;
 	}
-- 
2.25.1



From broonie at kernel.org  Thu Apr  1 11:28:58 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 11:28:58 +0100
Subject: [PATCH] ARM: configs: Remove REGULATOR_USERSPACE_CONSUMER
Message-ID: <20210401102858.4095-1-broonie@kernel.org>

The userspace consumer is a development tool, not intended for producton
systems and so should not be present in defconfigs especially not those
for specific machines so is not a good fit for defconfig, remove it from
those defconfigs where it is enabled. No system in mainline actually
instantiates one.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm/configs/ezx_defconfig    | 1 -
 arch/arm/configs/imote2_defconfig | 1 -
 arch/arm/configs/pxa_defconfig    | 1 -
 3 files changed, 3 deletions(-)

diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
index 81665b7abf83..a49e699e52de 100644
--- a/arch/arm/configs/ezx_defconfig
+++ b/arch/arm/configs/ezx_defconfig
@@ -213,7 +213,6 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_EZX_PCAP=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_DEBUG=y
-CONFIG_REGULATOR_USERSPACE_CONSUMER=y
 CONFIG_REGULATOR_PCAP=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
diff --git a/arch/arm/configs/imote2_defconfig b/arch/arm/configs/imote2_defconfig
index ae15a2a33802..118c4c927f26 100644
--- a/arch/arm/configs/imote2_defconfig
+++ b/arch/arm/configs/imote2_defconfig
@@ -194,7 +194,6 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_PMIC_DA903X=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_DEBUG=y
-CONFIG_REGULATOR_USERSPACE_CONSUMER=y
 CONFIG_REGULATOR_DA903X=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index bd7dd81c9c54..875a3c28a267 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -415,7 +415,6 @@ CONFIG_MFD_TC6393XB=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_DEBUG=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=m
-CONFIG_REGULATOR_USERSPACE_CONSUMER=m
 CONFIG_REGULATOR_ACT8865=m
 CONFIG_REGULATOR_AS3711=m
 CONFIG_REGULATOR_AXP20X=m
-- 
2.20.1



From maz at kernel.org  Thu Apr  1 11:38:19 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 11:38:19 +0100
Subject: [PATCH v3 03/14] PCI: rcar: Convert to MSI domains
In-Reply-To: <20210401101957.GA30653@lpieralisi>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-4-maz@kernel.org>
 <20210401101957.GA30653@lpieralisi>
Message-ID: <87y2e2p9wk.wl-maz@kernel.org>

On Thu, 01 Apr 2021 11:19:57 +0100,
Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
> 
> On Tue, Mar 30, 2021 at 04:11:34PM +0100, Marc Zyngier wrote:
> 
> [...]
> 
> > +static void rcar_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > +{
> > +	struct rcar_msi *msi = irq_data_get_irq_chip_data(data);
> > +	unsigned long pa = virt_to_phys(msi);
> >  
> > -	hwirq = rcar_msi_alloc_region(msi, nvec);
> > -	if (hwirq < 0)
> > -		return -ENOSPC;
> > +	/* Use the msi structure as the PA for the MSI doorbell */
> > +	msg->address_lo = lower_32_bits(pa);
> > +	msg->address_hi = upper_32_bits(pa);
> 
> I don't think this change is aligned with the previous patch (is it ?),
> the PA address we are using here is different from the one programmed
> into the controller registers - either that or I am missing something,
> please let me know.

Err. You are right. This looks like a bad case of broken conflict
resolution on my part.

The following snippet should fix it. Let me know if you want me to
resend the whole thing or whether you are OK with applying this by
hand.

Thanks,

	M.

diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
index f7331ad0d6dc..765cf2b45e24 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -573,11 +573,10 @@ static int rcar_msi_set_affinity(struct irq_data *d, const struct cpumask *mask,
 static void rcar_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
 	struct rcar_msi *msi = irq_data_get_irq_chip_data(data);
-	unsigned long pa = virt_to_phys(msi);
+	struct rcar_pcie *pcie = &msi_to_host(msi)->pcie;
 
-	/* Use the msi structure as the PA for the MSI doorbell */
-	msg->address_lo = lower_32_bits(pa);
-	msg->address_hi = upper_32_bits(pa);
+	msg->address_lo = rcar_pci_read_reg(pcie, PCIEMSIALR) & ~MSIFE;
+	msg->address_hi = rcar_pci_read_reg(pcie, PCIEMSIAUR);
 	msg->data = data->hwirq;
 }
 

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


From afaerber at suse.de  Thu Apr  1 11:49:37 2021
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Thu, 1 Apr 2021 12:49:37 +0200
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <20210401102717.GF14052@work>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work> <20210401094041.GA1993499@BV030612LT>
 <20210401102717.GF14052@work>
Message-ID: <252dd954-c8f1-fa2a-c37a-ede386fc9d43@suse.de>

Hi,

On 01.04.21 12:27, Manivannan Sadhasivam wrote:
> On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote:
>> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
>>> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
>>>> This patchset adds a socinfo driver which provides information about
>>>> Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
>>>> serial_number.
>>>>
>>>> Please note the serial number is currently available only for the S500
>>>> SoC variant.
>>>>
>>>> This has been tested on the S500 SoC based RoseapplePi SBC.
>>>>
>>>
>>> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
>>> what basis it provides? I don't think the SoC has the provision for
>>> soc_id based on HW parameters.
>>
>> No, the soc_id is not provided by the bootloader, or at least I couldn't
>> identify any related implementation. Instead, I provided this via the
>> driver itself, since I've encountered this approach in some other soc
>> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 
>>
> 
> Sorry, I was referring to serial_number. Since your comment says so, can
> you point to the corresponding code?

Seconded that this needs to be better understood. If this is just a
convention of some downstream U-Boot that's not implemented in mainline
(and maybe not even for Guitar or Labrador? tested on RoseapplePi only),
it might not be worth its own reserved-memory based kernel driver?

Implementing a standard interface such as DMI tables or a DT property in
mainline U-Boot may be more useful then. Is it still Mani's S900 only?

Regards,
Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer
HRB 36809 (AG N?rnberg)


From zhouchuangao at vivo.com  Thu Apr  1 11:49:37 2021
From: zhouchuangao at vivo.com (=?UTF-8?B?5ZGo5Lyg6auY?=)
Date: Thu, 1 Apr 2021 18:49:37 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSF0gYXJtNjQva2VybmVsL3Byb2JlczogVXNlIEJVR19PTiBpbnN0ZWFkIG9mIGlmIGNvbmRpdGlvbiBmb2xsb3dlZCBieSBCVUcu?=
In-Reply-To: <20210330120801.GA5908@willie-the-truck>
Message-ID: <ACUA-ACHDo4PFmCPQ3ckzKr7.3.1617274177288.Hmail.zhouchuangao@vivo.com>


>On Tue, Mar 30, 2021 at 04:57:50AM -0700, zhouchuangao wrote:>> It can be optimized at compile time.
>
>Hmm, I don't see it (and I also don't understand why we care). Do you have
>numbers showing that this is worthwhile?
>

#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)

BUG_ON uses unlikely in if(). Through disassembly, we can see that
brk #0x800 is compiled to the end of the function.
As you can see below:
    ......
    ffffff8008660bec:   d65f03c0    ret
    ffffff8008660bf0:   d4210000    brk #0x800

Usually, the condition in if () is not satisfied. For the multi-stage pipeline, 
we do not need to perform fetch decode and excute operation on brk 
instruction.

In my opinion, this can improve the efficiency of the multi-stage pipeline.

zhouchuangao

>Will



From cristian.ciocaltea at gmail.com  Thu Apr  1 11:58:05 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 13:58:05 +0300
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <252dd954-c8f1-fa2a-c37a-ede386fc9d43@suse.de>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work> <20210401094041.GA1993499@BV030612LT>
 <20210401102717.GF14052@work>
 <252dd954-c8f1-fa2a-c37a-ede386fc9d43@suse.de>
Message-ID: <20210401105805.GA1998829@BV030612LT>

Hi Mani, Andreas,

On Thu, Apr 01, 2021 at 12:49:37PM +0200, Andreas F?rber wrote:
> Hi,
> 
> On 01.04.21 12:27, Manivannan Sadhasivam wrote:
> > On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote:
> >> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
> >>> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> >>>> This patchset adds a socinfo driver which provides information about
> >>>> Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> >>>> serial_number.
> >>>>
> >>>> Please note the serial number is currently available only for the S500
> >>>> SoC variant.
> >>>>
> >>>> This has been tested on the S500 SoC based RoseapplePi SBC.
> >>>>
> >>>
> >>> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
> >>> what basis it provides? I don't think the SoC has the provision for
> >>> soc_id based on HW parameters.
> >>
> >> No, the soc_id is not provided by the bootloader, or at least I couldn't
> >> identify any related implementation. Instead, I provided this via the
> >> driver itself, since I've encountered this approach in some other soc
> >> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 
> >>
> > 
> > Sorry, I was referring to serial_number. Since your comment says so, can
> > you point to the corresponding code?
> 
> Seconded that this needs to be better understood. If this is just a
> convention of some downstream U-Boot that's not implemented in mainline
> (and maybe not even for Guitar or Labrador? tested on RoseapplePi only),
> it might not be worth its own reserved-memory based kernel driver?

The serial number is actually provided by the s500-bootloader for which
Actions did not provide the source code, at least it is not available
in the xapp github repo. I did not find anything related to this in
downstream U-Boot.

Kind regards,
Cristi

> Implementing a standard interface such as DMI tables or a DT property in
> mainline U-Boot may be more useful then. Is it still Mani's S900 only?
> 
> Regards,
> Andreas
> 
> -- 
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer
> HRB 36809 (AG N?rnberg)


From yoshihiro.shimoda.uh at renesas.com  Thu Apr  1 11:59:16 2021
From: yoshihiro.shimoda.uh at renesas.com (Yoshihiro Shimoda)
Date: Thu, 1 Apr 2021 10:59:16 +0000
Subject: [PATCH v3 02/14] PCI: rcar: Don't allocate extra memory for the
 MSI capture address
In-Reply-To: <20210330152857.GA27749@lpieralisi>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-3-maz@kernel.org> <20210330152857.GA27749@lpieralisi>
Message-ID: <TY2PR01MB36924566960FE203EF3B2FC9D87B9@TY2PR01MB3692.jpnprd01.prod.outlook.com>

Hi Lorenzo, Marc,

> From: Lorenzo Pieralisi, Sent: Wednesday, March 31, 2021 12:29 AM
> 
> On Tue, Mar 30, 2021 at 04:11:33PM +0100, Marc Zyngier wrote:
> > A long cargo-culted behaviour of PCI drivers is to allocate memory
> > to obtain an address that is fed to the controller as the MSI
> > capture address (i.e. the MSI doorbell).
> >
> > But there is no actual requirement for this address to be RAM.
> > All it needs to be is a suitable aligned address that will
> > *not* be DMA'd to.
> >
> > Since the rcar platform already has a requirement that this
> > address should be in the first 4GB of the physical address space,
> > use the controller's own base address as the capture address.
> >
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  drivers/pci/controller/pcie-rcar-host.c | 18 +++++++-----------
> >  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> Marek, Yoshihiro,
> 
> can you test this patch please and report back ? It is not fundamental
> for the rest of the series (ie the rest of the series does not depend on
> it) and we can still merge the series without it but it would be good if
> you can review and test anyway.

I reviewed and tested this patch and it worked correctly.
So,

Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Best regards,
Yoshihiro Shimoda



From lorenzo.pieralisi at arm.com  Thu Apr  1 12:03:01 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 1 Apr 2021 12:03:01 +0100
Subject: [PATCH v3 03/14] PCI: rcar: Convert to MSI domains
In-Reply-To: <87y2e2p9wk.wl-maz@kernel.org>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-4-maz@kernel.org>
 <20210401101957.GA30653@lpieralisi> <87y2e2p9wk.wl-maz@kernel.org>
Message-ID: <20210401110301.GA31407@lpieralisi>

On Thu, Apr 01, 2021 at 11:38:19AM +0100, Marc Zyngier wrote:
> On Thu, 01 Apr 2021 11:19:57 +0100,
> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
> > 
> > On Tue, Mar 30, 2021 at 04:11:34PM +0100, Marc Zyngier wrote:
> > 
> > [...]
> > 
> > > +static void rcar_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > > +{
> > > +	struct rcar_msi *msi = irq_data_get_irq_chip_data(data);
> > > +	unsigned long pa = virt_to_phys(msi);
> > >  
> > > -	hwirq = rcar_msi_alloc_region(msi, nvec);
> > > -	if (hwirq < 0)
> > > -		return -ENOSPC;
> > > +	/* Use the msi structure as the PA for the MSI doorbell */
> > > +	msg->address_lo = lower_32_bits(pa);
> > > +	msg->address_hi = upper_32_bits(pa);
> > 
> > I don't think this change is aligned with the previous patch (is it ?),
> > the PA address we are using here is different from the one programmed
> > into the controller registers - either that or I am missing something,
> > please let me know.
> 
> Err. You are right. This looks like a bad case of broken conflict
> resolution on my part.
> 
> The following snippet should fix it. Let me know if you want me to
> resend the whole thing or whether you are OK with applying this by
> hand.

I will apply it and merge the whole series into -next, thanks for
implementing it !

Lorenzo

> Thanks,
> 
> 	M.
> 
> diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
> index f7331ad0d6dc..765cf2b45e24 100644
> --- a/drivers/pci/controller/pcie-rcar-host.c
> +++ b/drivers/pci/controller/pcie-rcar-host.c
> @@ -573,11 +573,10 @@ static int rcar_msi_set_affinity(struct irq_data *d, const struct cpumask *mask,
>  static void rcar_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
>  {
>  	struct rcar_msi *msi = irq_data_get_irq_chip_data(data);
> -	unsigned long pa = virt_to_phys(msi);
> +	struct rcar_pcie *pcie = &msi_to_host(msi)->pcie;
>  
> -	/* Use the msi structure as the PA for the MSI doorbell */
> -	msg->address_lo = lower_32_bits(pa);
> -	msg->address_hi = upper_32_bits(pa);
> +	msg->address_lo = rcar_pci_read_reg(pcie, PCIEMSIALR) & ~MSIFE;
> +	msg->address_hi = rcar_pci_read_reg(pcie, PCIEMSIAUR);
>  	msg->data = data->hwirq;
>  }
>  
> 
> -- 
> Without deviation from the norm, progress is not possible.


From arnd at arndb.de  Thu Apr  1 12:03:42 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 1 Apr 2021 13:03:42 +0200
Subject: [PATCH 1/8] dt-bindings: clk: mstar msc313 cpupll binding
 description
In-Reply-To: <CAFr9PX=h2JPdAwjYS2849ufH=wnxSti2Dj60fbq4bg8b8=xy_g@mail.gmail.com>
References: <20210223061830.1913700-1-daniel@0x0f.com>
 <20210223061830.1913700-2-daniel@0x0f.com>
 <1614108850.540354.4116103.nullmailer@robh.at.kernel.org>
 <CAFr9PX=h2JPdAwjYS2849ufH=wnxSti2Dj60fbq4bg8b8=xy_g@mail.gmail.com>
Message-ID: <CAK8P3a1L62YT1WUxmmfLNmvERo7DbeVwfCHCxuKvxs7Uap+iXg@mail.gmail.com>

On Fri, Feb 26, 2021 at 12:31 PM Daniel Palmer <daniel at 0x0f.com> wrote:
>
> Hi Rob's bot
>
> On Wed, 24 Feb 2021 at 04:34, Rob Herring <robh at kernel.org> wrote:
> > dtschema/dtc warnings/errors:
> > Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.example.dts:19:18: fatal error: dt-bindings/clock/mstar-msc313-mpll.h: No such file or directory
> >    19 |         #include <dt-bindings/clock/mstar-msc313-mpll.h>
> >       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> > make[1]: *** [scripts/Makefile.lib:344: Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.example.dt.yaml] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> > make: *** [Makefile:1370: dt_binding_check] Error 2
>
> Looks like I sent this too early. I will try again later.

I found this is still in patchwork as not merged, and I have not
seen a replacement. Marking all eight patches as 'changes requested' now,
please resend.

         Arnd


From s.hauer at pengutronix.de  Thu Apr  1 12:06:13 2021
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  1 Apr 2021 13:06:13 +0200
Subject: [PATCH v5 0/2] Add L1 and L2 error detection for A53 and A57
Message-ID: <20210401110615.15326-1-s.hauer@pengutronix.de>

Hi,

Resending this mainly because Marc Zyngier and Mark Rutland raised
concerns about using implementation defined registers and I forgot to Cc
them with the last version. This version, like v4 already, should fix
these concerns. Looking forward to feedback.

Sascha

Changes since v4:
- Rebase on v5.12-rc5

Changes since v3:
- Add edac-enabled property to make EDAC support optional

Changes since v2:
- drop usage of virtual dt node (Robh)
- use read_sysreg_s instead of open coded variant (James Morse)
- separate error retrieving from error reporting
- use smp_call_function_single rather than smp_call_function_single_async
- make driver single instance and register all 'cpu' hierarchy up front once

Changes since v1:
- Split dt-binding into separate patch
- Sort local function variables in reverse-xmas tree order
- drop unnecessary comparison and make variable bool

Sascha Hauer (2):
  drivers/edac: Add L1 and L2 error detection for A53 and A57
  dt-bindings: arm: cpus: Add edac-enabled property

 .../devicetree/bindings/arm/cpus.yaml         |   6 +
 drivers/edac/Kconfig                          |   6 +
 drivers/edac/Makefile                         |   1 +
 drivers/edac/cortex_arm64_l1_l2.c             | 221 ++++++++++++++++++
 4 files changed, 234 insertions(+)
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c

-- 
2.29.2



From s.hauer at pengutronix.de  Thu Apr  1 12:06:14 2021
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  1 Apr 2021 13:06:14 +0200
Subject: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53 and
 A57
In-Reply-To: <20210401110615.15326-1-s.hauer@pengutronix.de>
References: <20210401110615.15326-1-s.hauer@pengutronix.de>
Message-ID: <20210401110615.15326-2-s.hauer@pengutronix.de>

The Cortex A53 and A57 cores have error detection capabilities for the
L1/L2 Caches, this patch adds a driver for them.

Unfortunately there is no robust way to inject errors into the caches,
so this driver doesn't contain any code to actually test it. It has
been tested though with code taken from an older version of this driver
found here: https://lkml.org/lkml/2018/3/14/1203. For reasons stated
in this thread the error injection code is not suitable for mainline,
so it is removed from the driver.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/edac/Kconfig              |   6 +
 drivers/edac/Makefile             |   1 +
 drivers/edac/cortex_arm64_l1_l2.c | 218 ++++++++++++++++++++++++++++++
 3 files changed, 225 insertions(+)
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 27d0c4cdc58d..b038aed35e93 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -538,4 +538,10 @@ config EDAC_DMC520
 	  Support for error detection and correction on the
 	  SoCs with ARM DMC-520 DRAM controller.
 
+config EDAC_CORTEX_ARM64_L1_L2
+	tristate "ARM Cortex A57/A53"
+	depends on ARM64
+	help
+	  Support for L1/L2 cache error detection on ARM Cortex A57 and A53.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 2d1641a27a28..5849d8bb32ae 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_EDAC_QCOM)			+= qcom_edac.o
 obj-$(CONFIG_EDAC_ASPEED)		+= aspeed_edac.o
 obj-$(CONFIG_EDAC_BLUEFIELD)		+= bluefield_edac.o
 obj-$(CONFIG_EDAC_DMC520)		+= dmc520_edac.o
+obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)	+= cortex_arm64_l1_l2.o
diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
new file mode 100644
index 000000000000..3b1e2f3ccab6
--- /dev/null
+++ b/drivers/edac/cortex_arm64_l1_l2.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cortex A57 and A53 EDAC L1 and L2 cache error detection
+ *
+ * Copyright (c) 2020 Pengutronix, Sascha Hauer <s.hauer at pengutronix.de>
+ *
+ * Based on Code from:
+ * Copyright (c) 2018, NXP Semiconductor
+ * Author: York Sun <york.sun at nxp.com>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/bitfield.h>
+#include <asm/smp_plat.h>
+
+#include "edac_module.h"
+
+#define DRVNAME				"cortex-arm64-edac"
+
+#define CPUMERRSR_EL1_RAMID		GENMASK(30, 24)
+
+#define CPUMERRSR_EL1_VALID		BIT(31)
+#define CPUMERRSR_EL1_FATAL		BIT(63)
+
+#define L1_I_TAG_RAM			0x00
+#define L1_I_DATA_RAM			0x01
+#define L1_D_TAG_RAM			0x08
+#define L1_D_DATA_RAM			0x09
+#define L1_D_DIRTY_RAM			0x14
+#define TLB_RAM				0x18
+
+#define L2MERRSR_EL1_VALID		BIT(31)
+#define L2MERRSR_EL1_FATAL		BIT(63)
+
+struct merrsr {
+	u64 cpumerr;
+	u64 l2merr;
+};
+
+#define MESSAGE_SIZE 64
+
+#define SYS_CPUMERRSR_EL1			sys_reg(3, 1, 15, 2, 2)
+#define SYS_L2MERRSR_EL1			sys_reg(3, 1, 15, 2, 3)
+
+static struct cpumask compat_mask;
+
+static void report_errors(struct edac_device_ctl_info *edac_ctl, int cpu,
+			  struct merrsr *merrsr)
+{
+	char msg[MESSAGE_SIZE];
+	u64 cpumerr = merrsr->cpumerr;
+	u64 l2merr = merrsr->l2merr;
+
+	if (cpumerr & CPUMERRSR_EL1_VALID) {
+		const char *str;
+		bool fatal = cpumerr & CPUMERRSR_EL1_FATAL;
+
+		switch (FIELD_GET(CPUMERRSR_EL1_RAMID, cpumerr)) {
+		case L1_I_TAG_RAM:
+			str = "L1-I Tag RAM";
+			break;
+		case L1_I_DATA_RAM:
+			str = "L1-I Data RAM";
+			break;
+		case L1_D_TAG_RAM:
+			str = "L1-D Tag RAM";
+			break;
+		case L1_D_DATA_RAM:
+			str = "L1-D Data RAM";
+			break;
+		case L1_D_DIRTY_RAM:
+			str = "L1 Dirty RAM";
+			break;
+		case TLB_RAM:
+			str = "TLB RAM";
+			break;
+		default:
+			str = "unknown";
+			break;
+		}
+
+		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
+			 str, fatal ? "fatal" : "correctable", cpu);
+
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
+	}
+
+	if (l2merr & L2MERRSR_EL1_VALID) {
+		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
+
+		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d",
+			 fatal ? "fatal" : "correctable", cpu);
+		if (fatal)
+			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
+		else
+			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
+	}
+}
+
+static void read_errors(void *data)
+{
+	struct merrsr *merrsr = data;
+
+	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
+	write_sysreg_s(0, SYS_CPUMERRSR_EL1);
+	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
+	write_sysreg_s(0, SYS_L2MERRSR_EL1);
+}
+
+static void cortex_arm64_edac_check(struct edac_device_ctl_info *edac_ctl)
+{
+	struct merrsr merrsr;
+	int cpu;
+
+	for_each_cpu_and(cpu, cpu_online_mask, &compat_mask) {
+		smp_call_function_single(cpu, read_errors, &merrsr, true);
+		report_errors(edac_ctl, cpu, &merrsr);
+	}
+}
+
+static int cortex_arm64_edac_probe(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl;
+	struct device *dev = &pdev->dev;
+	int rc;
+
+	edac_ctl = edac_device_alloc_ctl_info(0, "cpu",
+					      num_possible_cpus(), "L", 2, 1, NULL, 0,
+					      edac_device_alloc_index());
+	if (!edac_ctl)
+		return -ENOMEM;
+
+	edac_ctl->edac_check = cortex_arm64_edac_check;
+	edac_ctl->dev = dev;
+	edac_ctl->mod_name = dev_name(dev);
+	edac_ctl->dev_name = dev_name(dev);
+	edac_ctl->ctl_name = DRVNAME;
+	dev_set_drvdata(dev, edac_ctl);
+
+	rc = edac_device_add_device(edac_ctl);
+	if (rc)
+		goto out_dev;
+
+	return 0;
+
+out_dev:
+	edac_device_free_ctl_info(edac_ctl);
+
+	return rc;
+}
+
+static int cortex_arm64_edac_remove(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *edac_ctl = dev_get_drvdata(&pdev->dev);
+
+	edac_device_del_device(edac_ctl->dev);
+	edac_device_free_ctl_info(edac_ctl);
+
+	return 0;
+}
+
+static const struct of_device_id cortex_arm64_edac_of_match[] = {
+	{ .compatible = "arm,cortex-a53" },
+	{ .compatible = "arm,cortex-a57" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, cortex_arm64_edac_of_match);
+
+static struct platform_driver cortex_arm64_edac_driver = {
+	.probe = cortex_arm64_edac_probe,
+	.remove = cortex_arm64_edac_remove,
+	.driver = {
+		.name = DRVNAME,
+	},
+};
+
+static int __init cortex_arm64_edac_driver_init(void)
+{
+	struct device_node *np;
+	int cpu;
+	struct platform_device *pdev;
+	int err;
+
+	for_each_possible_cpu(cpu) {
+		np = of_get_cpu_node(cpu, NULL);
+
+		if (of_match_node(cortex_arm64_edac_of_match, np))
+			cpumask_set_cpu(cpu, &compat_mask);
+	}
+
+	if (cpumask_empty(&compat_mask))
+		return 0;
+
+	err = platform_driver_register(&cortex_arm64_edac_driver);
+        if (err)
+                return err;
+
+	pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
+	if (IS_ERR(pdev)) {
+		pr_err("failed to register cortex arm64 edac device\n");
+		platform_driver_unregister(&cortex_arm64_edac_driver);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+
+device_initcall(cortex_arm64_edac_driver_init);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sascha Hauer <s.hauer at pengutronix.de>");
+MODULE_DESCRIPTION("Cortex A57 and A53 L1 and L2 cache EDAC driver");
-- 
2.29.2



From s.hauer at pengutronix.de  Thu Apr  1 12:06:15 2021
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu,  1 Apr 2021 13:06:15 +0200
Subject: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property
In-Reply-To: <20210401110615.15326-1-s.hauer@pengutronix.de>
References: <20210401110615.15326-1-s.hauer@pengutronix.de>
Message-ID: <20210401110615.15326-3-s.hauer@pengutronix.de>

Some CPUs like the Cortex-A53 and Cortex-A57 have Error Detection And
Correction (EDAC) support on their L1 and L2 caches. This is implemented
in implementation defined registers, so usage of this functionality is
not safe in virtualized environments or when EL3 already uses these
registers.
This patch adds a edac-enabled flag which can be explicitly set when
EDAC can be used.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
 drivers/edac/cortex_arm64_l1_l2.c               | 7 +++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 26b886b20b27..74be19c0544a 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -270,6 +270,12 @@ properties:
       For PSCI based platforms, the name corresponding to the index of the PSCI
       PM domain provider, must be "psci".
 
+  edac-enabled:
+    $ref: '/schemas/types.yaml#/definitions/flag'
+    description:
+      Some CPUs support Error Detection And Correction (EDAC) on their L1 and
+      L2 caches. This flag marks this function as usable.
+
   qcom,saw:
     $ref: '/schemas/types.yaml#/definitions/phandle'
     description: |
diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
index 3b1e2f3ccab6..6d5355bae80c 100644
--- a/drivers/edac/cortex_arm64_l1_l2.c
+++ b/drivers/edac/cortex_arm64_l1_l2.c
@@ -190,8 +190,11 @@ static int __init cortex_arm64_edac_driver_init(void)
 	for_each_possible_cpu(cpu) {
 		np = of_get_cpu_node(cpu, NULL);
 
-		if (of_match_node(cortex_arm64_edac_of_match, np))
-			cpumask_set_cpu(cpu, &compat_mask);
+		if (!of_match_node(cortex_arm64_edac_of_match, np))
+			continue;
+		if (!of_property_read_bool(np, "edac-enabled"))
+			continue;
+		cpumask_set_cpu(cpu, &compat_mask);
 	}
 
 	if (cpumask_empty(&compat_mask))
-- 
2.29.2



From daniel at 0x0f.com  Thu Apr  1 12:07:20 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Thu, 1 Apr 2021 20:07:20 +0900
Subject: [PATCH 1/8] dt-bindings: clk: mstar msc313 cpupll binding
 description
In-Reply-To: <CAK8P3a1L62YT1WUxmmfLNmvERo7DbeVwfCHCxuKvxs7Uap+iXg@mail.gmail.com>
References: <20210223061830.1913700-1-daniel@0x0f.com>
 <20210223061830.1913700-2-daniel@0x0f.com>
 <1614108850.540354.4116103.nullmailer@robh.at.kernel.org>
 <CAFr9PX=h2JPdAwjYS2849ufH=wnxSti2Dj60fbq4bg8b8=xy_g@mail.gmail.com>
 <CAK8P3a1L62YT1WUxmmfLNmvERo7DbeVwfCHCxuKvxs7Uap+iXg@mail.gmail.com>
Message-ID: <CAFr9PXmT-FUUu-yMBWCe52KDHUSF2+Zhr8wk-NdC+cW+_8prKw@mail.gmail.com>

Hi Arnd,

On Thu, 1 Apr 2021 at 20:04, Arnd Bergmann <arnd at arndb.de> wrote:
> I found this is still in patchwork as not merged, and I have not
> seen a replacement. Marking all eight patches as 'changes requested' now,
> please resend.

Understood. I will resend.

Thanks,

Daniel


From mani at kernel.org  Thu Apr  1 12:07:52 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Thu, 1 Apr 2021 16:37:52 +0530
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <20210401105805.GA1998829@BV030612LT>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work> <20210401094041.GA1993499@BV030612LT>
 <20210401102717.GF14052@work>
 <252dd954-c8f1-fa2a-c37a-ede386fc9d43@suse.de>
 <20210401105805.GA1998829@BV030612LT>
Message-ID: <20210401110752.GG14052@work>

+ Matheus

On Thu, Apr 01, 2021 at 01:58:05PM +0300, Cristian Ciocaltea wrote:
> Hi Mani, Andreas,
> 
> On Thu, Apr 01, 2021 at 12:49:37PM +0200, Andreas F?rber wrote:
> > Hi,
> > 
> > On 01.04.21 12:27, Manivannan Sadhasivam wrote:
> > > On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote:
> > >> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
> > >>> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> > >>>> This patchset adds a socinfo driver which provides information about
> > >>>> Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> > >>>> serial_number.
> > >>>>
> > >>>> Please note the serial number is currently available only for the S500
> > >>>> SoC variant.
> > >>>>
> > >>>> This has been tested on the S500 SoC based RoseapplePi SBC.
> > >>>>
> > >>>
> > >>> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
> > >>> what basis it provides? I don't think the SoC has the provision for
> > >>> soc_id based on HW parameters.
> > >>
> > >> No, the soc_id is not provided by the bootloader, or at least I couldn't
> > >> identify any related implementation. Instead, I provided this via the
> > >> driver itself, since I've encountered this approach in some other soc
> > >> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 
> > >>
> > > 
> > > Sorry, I was referring to serial_number. Since your comment says so, can
> > > you point to the corresponding code?
> > 
> > Seconded that this needs to be better understood. If this is just a
> > convention of some downstream U-Boot that's not implemented in mainline
> > (and maybe not even for Guitar or Labrador? tested on RoseapplePi only),
> > it might not be worth its own reserved-memory based kernel driver?
> 
> The serial number is actually provided by the s500-bootloader for which
> Actions did not provide the source code, at least it is not available
> in the xapp github repo. I did not find anything related to this in
> downstream U-Boot.
> 

Hmm, then we can consider this as the firmware dependent property. But
can we get consensus that this is common for all S500 SoCs? Maybe,
Matheus can verify it on Labrador?

I don't think adding a SOCINFO driver for a single board is a good idea.

Thanks,
Mani

> Kind regards,
> Cristi
> 
> > Implementing a standard interface such as DMI tables or a DT property in
> > mainline U-Boot may be more useful then. Is it still Mani's S900 only?
> > 
> > Regards,
> > Andreas
> > 
> > -- 
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 N?rnberg, Germany
> > GF: Felix Imend?rffer
> > HRB 36809 (AG N?rnberg)


From p.zabel at pengutronix.de  Thu Apr  1 12:12:05 2021
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 1 Apr 2021 13:12:05 +0200
Subject: [PATCH -next] media: imx-pxp: remove redundant dev_err call in
 pxp_probe()
In-Reply-To: <20210401102607.1554006-1-yangyingliang@huawei.com>
References: <20210401102607.1554006-1-yangyingliang@huawei.com>
Message-ID: <20210401111205.GA20418@pengutronix.de>

On Thu, Apr 01, 2021 at 06:26:07PM +0800, Yang Yingliang wrote:
> There is an error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Yang Yingliang <yangyingliang at huawei.com>

Thank you,
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp


From David.Laight at ACULAB.COM  Thu Apr  1 12:15:43 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 1 Apr 2021 11:15:43 +0000
Subject: [PATCH v8 3/6] stack: Optionally randomize kernel stack offset
 each syscall
In-Reply-To: <20210401083034.GA8554@willie-the-truck>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210330205750.428816-4-keescook@chromium.org>
 <20210401083034.GA8554@willie-the-truck>
Message-ID: <61ae9398a03d4fe7868b68c9026d5998@AcuMS.aculab.com>

From: Will Deacon
> Sent: 01 April 2021 09:31
...
> > +/*
> > + * These macros must be used during syscall entry when interrupts and
> > + * preempt are disabled, and after user registers have been stored to
> > + * the stack.
> > + */
> > +#define add_random_kstack_offset() do {					\
> > +	if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,	\
> > +				&randomize_kstack_offset)) {		\
> > +		u32 offset = __this_cpu_read(kstack_offset);		\
> > +		u8 *ptr = __builtin_alloca(KSTACK_OFFSET_MAX(offset));	\
> > +		asm volatile("" : "=m"(*ptr) :: "memory");		\
> 
> Using the "m" constraint here is dangerous if you don't actually evaluate it
> inside the asm. For example, if the compiler decides to generate an
> addressing mode relative to the stack but with writeback (autodecrement), then
> the stack pointer will be off by 8 bytes. Can you use "o" instead?

Is it allowed to use such a mode?
It would have to know that the "m" was substituted exactly once.
I think there are quite a few examples with 'strange' uses of memory
asm arguments.

However, in this case, isn't it enough to ensure the address is 'saved'?
So:
	asm volatile("" : "=r"(ptr) );
should be enough.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From syednwaris at gmail.com  Thu Apr  1 12:15:52 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 1 Apr 2021 16:45:52 +0530
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <DM6PR02MB53863852A28F782B0942ECD8AF7C9@DM6PR02MB5386.namprd02.prod.outlook.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <36db7be3-73b6-c822-02e8-13e3864b0463@xilinx.com>
 <CAMpxmJUv0iU0Ntmks1f6ThDAG6x_eJLYYCaDSjy+1Syedzc5dQ@mail.gmail.com>
 <DM6PR02MB53863852A28F782B0942ECD8AF7C9@DM6PR02MB5386.namprd02.prod.outlook.com>
Message-ID: <CACG_h5q6P5NiNByttQ-NZvq8x3GCTKfSU=Yyywk7PcO6_=i2Mw@mail.gmail.com>

On Wed, Mar 31, 2021 at 8:56 PM Srinivas Neeli <sneeli at xilinx.com> wrote:
>
> Hi,
>
> > -----Original Message-----
> > From: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > Sent: Friday, March 26, 2021 10:58 PM
> > To: Michal Simek <michals at xilinx.com>
> > Cc: Syed Nayyar Waris <syednwaris at gmail.com>; Srinivas Neeli
> > <sneeli at xilinx.com>; Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com>; William Breathitt Gray
> > <vilhelm.gray at gmail.com>; Arnd Bergmann <arnd at arndb.de>; Robert
> > Richter <rrichter at marvell.com>; Linus Walleij <linus.walleij at linaro.org>;
> > Masahiro Yamada <yamada.masahiro at socionext.com>; Andrew Morton
> > <akpm at linux-foundation.org>; Zhang Rui <rui.zhang at intel.com>; Daniel
> > Lezcano <daniel.lezcano at linaro.org>; Amit Kucheria
> > <amit.kucheria at verdurent.com>; Linux-Arch <linux-arch at vger.kernel.org>;
> > linux-gpio <linux-gpio at vger.kernel.org>; LKML <linux-
> > kernel at vger.kernel.org>; arm-soc <linux-arm-kernel at lists.infradead.org>;
> > linux-pm <linux-pm at vger.kernel.org>; Srinivas Goud <sgoud at xilinx.com>
> > Subject: Re: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
> > _set_value
> >
> > On Mon, Mar 8, 2021 at 8:13 AM Michal Simek <michal.simek at xilinx.com>
> > wrote:
> > >
> > >
> > >
> > > On 3/6/21 3:06 PM, Syed Nayyar Waris wrote:
> > > > This patch reimplements the xgpio_set_multiple() function in
> > > > drivers/gpio/gpio-xilinx.c to use the new generic functions:
> > > > bitmap_get_value() and bitmap_set_value(). The code is now simpler
> > > > to read and understand. Moreover, instead of looping for each bit in
> > > > xgpio_set_multiple() function, now we can check each channel at a
> > > > time and save cycles.
> > > >
> > > > Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > > > Cc: Michal Simek <michal.simek at xilinx.com>
> > > > Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> > > > Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> > > > ---
> > > >  drivers/gpio/gpio-xilinx.c | 63
> > > > +++++++++++++++++++-------------------
> > > >  1 file changed, 32 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> > > > index be539381fd82..8445e69cf37b 100644
> > > > --- a/drivers/gpio/gpio-xilinx.c
> > > > +++ b/drivers/gpio/gpio-xilinx.c
> > > > @@ -15,6 +15,7 @@
> > > >  #include <linux/of_device.h>
> > > >  #include <linux/of_platform.h>
> > > >  #include <linux/slab.h>
> > > > +#include "gpiolib.h"
> > > >
> > > >  /* Register Offset Definitions */
> > > >  #define XGPIO_DATA_OFFSET   (0x0)    /* Data register  */
> > > > @@ -141,37 +142,37 @@ static void xgpio_set_multiple(struct
> > > > gpio_chip *gc, unsigned long *mask,  {
> > > >       unsigned long flags;
> > > >       struct xgpio_instance *chip = gpiochip_get_data(gc);
> > > > -     int index = xgpio_index(chip, 0);
> > > > -     int offset, i;
> > > > -
> > > > -     spin_lock_irqsave(&chip->gpio_lock[index], flags);
> > > > -
> > > > -     /* Write to GPIO signals */
> > > > -     for (i = 0; i < gc->ngpio; i++) {
> > > > -             if (*mask == 0)
> > > > -                     break;
> > > > -             /* Once finished with an index write it out to the register */
> > > > -             if (index !=  xgpio_index(chip, i)) {
> > > > -                     xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > -                                    index * XGPIO_CHANNEL_OFFSET,
> > > > -                                    chip->gpio_state[index]);
> > > > -                     spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
> > > > -                     index =  xgpio_index(chip, i);
> > > > -                     spin_lock_irqsave(&chip->gpio_lock[index], flags);
> > > > -             }
> > > > -             if (__test_and_clear_bit(i, mask)) {
> > > > -                     offset =  xgpio_offset(chip, i);
> > > > -                     if (test_bit(i, bits))
> > > > -                             chip->gpio_state[index] |= BIT(offset);
> > > > -                     else
> > > > -                             chip->gpio_state[index] &= ~BIT(offset);
> > > > -             }
> > > > -     }
> > > > -
> > > > -     xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > -                    index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> > > > -
> > > > -     spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
> > > > +     u32 *const state = chip->gpio_state;
> > > > +     unsigned int *const width = chip->gpio_width;
> > > > +
> > > > +     DECLARE_BITMAP(old, 64);
> > > > +     DECLARE_BITMAP(new, 64);
> > > > +     DECLARE_BITMAP(changed, 64);
> > > > +
> > > > +     spin_lock_irqsave(&chip->gpio_lock[0], flags);
> > > > +     spin_lock(&chip->gpio_lock[1]);
> > > > +
> > > > +     bitmap_set_value(old, 64, state[0], width[0], 0);
> > > > +     bitmap_set_value(old, 64, state[1], width[1], width[0]);
> > > > +     bitmap_replace(new, old, bits, mask, gc->ngpio);
> > > > +
> > > > +     bitmap_set_value(old, 64, state[0], 32, 0);
> > > > +     bitmap_set_value(old, 64, state[1], 32, 32);
> > > > +     state[0] = bitmap_get_value(new, 0, width[0]);
> > > > +     state[1] = bitmap_get_value(new, width[0], width[1]);
> > > > +     bitmap_set_value(new, 64, state[0], 32, 0);
> > > > +     bitmap_set_value(new, 64, state[1], 32, 32);
> > > > +     bitmap_xor(changed, old, new, 64);
> > > > +
> > > > +     if (((u32 *)changed)[0])
> > > > +             xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,
> > > > +                             state[0]);
> > > > +     if (((u32 *)changed)[1])
> > > > +             xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > +                             XGPIO_CHANNEL_OFFSET, state[1]);
> > > > +
> > > > +     spin_unlock(&chip->gpio_lock[1]);
> > > > +     spin_unlock_irqrestore(&chip->gpio_lock[0], flags);
> > > >  }
> > > >
> > > >  /**
> > > >
> > >
> > > Srinivas N: Can you please test this code?
> > >
> > > Thanks,
> > > Michal
> >
> > Hey, any chance of getting that Tested-by?
> I tested patches with few modifications in code (spin_lock handling and merge conflict).
> functionality wise it's working fine.
>
> >
> > Bart

Hi Bartosz,

May I please know the URL of the tree that you are using. I had been
using the tree below for submitting this patchset on GPIO to you.
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git

I think I am using the wrong tree. On which tree should I base my
patches on for my next  (v4) submission? Should I use the tree below?
:
https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git

Regards
Syed Nayyar Waris


From liuqi115 at huawei.com  Thu Apr  1 12:16:41 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Thu, 1 Apr 2021 19:16:41 +0800
Subject: [PATCH] arm64: perf: Remove redundant initialization in perf_event.c
Message-ID: <1617275801-1980-1-git-send-email-liuqi115@huawei.com>

The initialization of value in function armv8pmu_read_hw_counter()
and armv8pmu_read_counter() seem redundant, as they are soon updated.
So, We can remove them.

Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 arch/arm64/kernel/perf_event.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4658fcf..f594957 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -470,9 +470,8 @@ static inline u64 armv8pmu_read_evcntr(int idx)
 static inline u64 armv8pmu_read_hw_counter(struct perf_event *event)
 {
 	int idx = event->hw.idx;
-	u64 val = 0;
+	u64 val = armv8pmu_read_evcntr(idx);
 
-	val = armv8pmu_read_evcntr(idx);
 	if (armv8pmu_event_is_chained(event))
 		val = (val << 32) | armv8pmu_read_evcntr(idx - 1);
 	return val;
@@ -520,7 +519,7 @@ static u64 armv8pmu_read_counter(struct perf_event *event)
 {
 	struct hw_perf_event *hwc = &event->hw;
 	int idx = hwc->idx;
-	u64 value = 0;
+	u64 value;
 
 	if (idx == ARMV8_IDX_CYCLE_COUNTER)
 		value = read_sysreg(pmccntr_el0);
-- 
2.8.1



From lorenzo.pieralisi at arm.com  Thu Apr  1 12:27:42 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu,  1 Apr 2021 12:27:42 +0100
Subject: [PATCH v3 00/14] PCI/MSI: Getting rid of msi_controller,
 and other cleanups
In-Reply-To: <20210330151145.997953-1-maz@kernel.org>
References: <20210330151145.997953-1-maz@kernel.org>
Message-ID: <161727636757.32506.11592578621890085687.b4-ty@arm.com>

On Tue, 30 Mar 2021 16:11:31 +0100, Marc Zyngier wrote:
> This is a respin of the series described at [1].
> 
> * From v2 [2]:
>   - Fixed the Xilinx driver, thanks to Bharat for testing it
>   - Dropped the no_msi attribute, and solely rely on msi_domain, which
>     has the same effect for the only platform that was using it.
>   - Fixed compilation on architectures that do not select the generic
>     MSI support
> 
> [...]

I have applied it to pci/msi and should be moved into -next shortly
for further testing/visibility, thanks a lot for putting it together.

[01/14] PCI: tegra: Convert to MSI domains
        https://git.kernel.org/lpieralisi/pci/c/973a28677e
[02/14] PCI: rcar: Don't allocate extra memory for the MSI capture address
        https://git.kernel.org/lpieralisi/pci/c/c244dc15dc
[03/14] PCI: rcar: Convert to MSI domains
        https://git.kernel.org/lpieralisi/pci/c/516286287d
[04/14] PCI: xilinx: Don't allocate extra memory for the MSI capture address
        https://git.kernel.org/lpieralisi/pci/c/cc8cf90738
[05/14] PCI: xilinx: Convert to MSI domains
        https://git.kernel.org/lpieralisi/pci/c/b66873599e
[06/14] PCI: hv: Drop msi_controller structure
        https://git.kernel.org/lpieralisi/pci/c/65b131816a
[07/14] PCI/MSI: Drop use of msi_controller from core code
        https://git.kernel.org/lpieralisi/pci/c/54729d2a7a
[08/14] PCI/MSI: Kill msi_controller structure
        https://git.kernel.org/lpieralisi/pci/c/27278a3fac
[09/14] PCI/MSI: Kill default_teardown_msi_irqs()
        https://git.kernel.org/lpieralisi/pci/c/f68f571db9
[10/14] PCI/MSI: Let PCI host bridges declare their reliance on MSI domains
        https://git.kernel.org/lpieralisi/pci/c/419150a4ff
[11/14] PCI/MSI: Make pci_host_common_probe() declare its reliance on MSI domains
        https://git.kernel.org/lpieralisi/pci/c/98be0634c8
[12/14] PCI: mediatek: Advertise lack of built-in MSI handling
        https://git.kernel.org/lpieralisi/pci/c/77cbd88c90
[13/14] PCI/MSI: Document the various ways of ending up with NO_MSI
        https://git.kernel.org/lpieralisi/pci/c/44ec480daf
[14/14] PCI: Refactor HT advertising of NO_MSI flag
        https://git.kernel.org/lpieralisi/pci/c/18d56e5afe

Thanks,
Lorenzo


From eugen.hristev at microchip.com  Thu Apr  1 12:26:53 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:53 +0300
Subject: [PATCH 00/30] media: atmel: atmel-isc: add support for xisc
Message-ID: <20210401112723.189107-1-eugen.hristev@microchip.com>

Hello,

This series adds support for a variant of the ISC named XISC.
This block is present in the product named sama7g5.

I started by moving code around, the code which was specialized for sama5d2
type of ISC, to have it inside the dedicated sama5d2 file.

I added several new pipeline elements to the code base, which would be common
to sama5d2 and the new sama7g5, but only used by the new style pipeline.

I separated the input and output formats on a per-product separate array.

I added the new sama7g5 compatible driver for the xisc, which is similar with
the sama5d2, but with differences in terms of DT, clocks and callbacks to
specific operations.

I added the binding for the xisc by copying and modifying the existing
isc one. I know that it has to be converted to yaml, and I will do that if
it looks good.

Feedback is appreciated.
Thanks,
Eugen

Eugen Hristev (30):
  media: atmel: atmel-isc: specialize gamma table into product specific
  media: atmel: atmel-isc: specialize driver name constant
  media: atmel: atmel-isc: add checks for limiting frame sizes
  media: atmel: atmel-isc: specialize max width and max height
  media: atmel: atmel-isc: specialize dma cfg
  media: atmel: atmel-isc: extract CSC submodule config into separate
    function
  media: atmel: atmel-isc-base: add id to clock debug message
  media: atmel: atmel-isc: create register offsets struct
  media: atmel: atmel-isc: extract CBC submodule config into separate
    function
  media: atmel: atmel-isc: add CBC to the reg offsets struct
  media: atmel: atmel-isc: add SUB422 and SUB420 to register offsets
  media: atmel: atmel-isc: add RLP to register offsets
  media: atmel: atmel-isc: add HIS to register offsets
  media: atmel: atmel-isc: add DMA to register offsets
  media: atmel: atmel-isc: add support for version register
  media: atmel: atmel-isc: add his_entry to register offsets
  media: atmel: atmel-isc: add register description for additional
    modules
  media: atmel: atmel-isc: extend pipeline with extra modules
  media: atmel: atmel-isc: add CC initialization function
  media: atmel: atmel-isc: create product specific v4l2 controls config
  media: atmel: atmel-isc: create callback for DPC submodule product
    specific
  media: atmel: atmel-isc: create callback for GAM submodule product
    specific
  media: atmel: atmel-isc: create callback for RLP submodule product
    specific
  media: atmel: atmel-isc: move the formats list into product specific
    code
  media: atmel: atmel-isc: create an adapt pipeline callback for product
    specific
  media: atmel: atmel-isc-regs: add additional fields for sama7g5 type
    pipeline
  media: atmel: atmel-isc-base: add support for more formats and
    additional pipeline modules
  dt-bindings: media: atmel: add microchip-xisc binding
  media: atmel: atmel-isc-sama5d2: remove duplicate define
  media: atmel: atmel-isc: add microchip-xisc driver

 .../bindings/media/microchip-xisc.txt         |  64 ++
 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c | 381 ++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h | 133 +++-
 drivers/media/platform/atmel/atmel-isc.h      | 122 +++-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 300 +++++++-
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 644 ++++++++++++++++++
 9 files changed, 1381 insertions(+), 277 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:54 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:54 +0300
Subject: [PATCH 01/30] media: atmel: atmel-isc: specialize gamma table into
 product specific
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-2-eugen.hristev@microchip.com>

Separate the gamma table from the isc base file into the specific sama5d2
product file.
Add a pointer to the gamma table and entries count inside the platform
driver specific struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 47 ++-----------------
 drivers/media/platform/atmel/atmel-isc.h      | 11 +++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 45 ++++++++++++++++++
 3 files changed, 56 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..8b6c5e339cb8 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -176,48 +176,6 @@ struct isc_format formats_list[] = {
 
 };
 
-/* Gamma table with gamma 1/2.2 */
-const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES] = {
-	/* 0 --> gamma 1/1.8 */
-	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
-	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
-	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
-	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
-	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
-	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
-	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
-	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
-	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
-	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
-	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
-
-	/* 1 --> gamma 1/2 */
-	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
-	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
-	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
-	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
-	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
-	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
-	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
-	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
-	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
-	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
-	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
-
-	/* 2 --> gamma 1/2.2 */
-	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
-	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
-	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
-	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
-	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
-	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
-	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
-	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
-	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
-	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
-	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -683,7 +641,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	regmap_write(regmap, ISC_CFA_CFG, bay_cfg | ISC_CFA_CFG_EITPOL);
 
-	gamma = &isc_gamma_table[ctrls->gamma_index][0];
+	gamma = &isc->gamma_table[ctrls->gamma_index][0];
 	regmap_bulk_write(regmap, ISC_GAM_BENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
@@ -2070,7 +2028,8 @@ static int isc_ctrl_init(struct isc_device *isc)
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX, 1, 2);
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
+			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
 					  V4L2_CID_AUTO_WHITE_BALANCE,
 					  0, 1, 1, 1);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fab8eca58d93..f1df47a4655b 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -187,6 +187,10 @@ struct isc_ctrls {
  *
  * @current_subdev:	current subdevice: the sensor
  * @subdev_entities:	list of subdevice entitites
+ *
+ * @gamma_table:	pointer to the table with gamma values, has
+ *			gamma_max sets of GAMMA_ENTRIES entries each
+ * @gamma_max:		maximum number of sets of inside the gamma_table
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -245,16 +249,17 @@ struct isc_device {
 		struct v4l2_ctrl	*gr_off_ctrl;
 		struct v4l2_ctrl	*gb_off_ctrl;
 	};
-};
 
-#define GAMMA_MAX	2
 #define GAMMA_ENTRIES	64
+	/* pointer to the defined gamma table */
+	const u32	(*gamma_table)[GAMMA_ENTRIES];
+	u32		gamma_max;
+};
 
 #define ATMEL_ISC_NAME "atmel-isc"
 
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
-extern const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0b78fecfd2a8..c74f36245bd5 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,48 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
+	/* 0 --> gamma 1/1.8 */
+	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
+	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
+	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
+	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
+	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
+	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
+	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
+	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
+	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
+	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
+	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
+
+	/* 1 --> gamma 1/2 */
+	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
+	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
+	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
+	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
+	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
+	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
+	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
+	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
+	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
+	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
+	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
+
+	/* 2 --> gamma 1/2.2 */
+	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
+	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
+	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
+	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
+	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
+	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
+	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
+	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
+	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
+	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
+	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
+};
+
 static int isc_parse_dt(struct device *dev, struct isc_device *isc)
 {
 	struct device_node *np = dev->of_node;
@@ -150,6 +192,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	isc->gamma_table = isc_sama5d2_gamma_table;
+	isc->gamma_max = 2;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:55 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:55 +0300
Subject: [PATCH 02/30] media: atmel: atmel-isc: specialize driver name constant
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-3-eugen.hristev@microchip.com>

The driver name constant must defined based on product driver, thus moving
the constant directly where it's required. This will allow each ISC based
product to define it's own name.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc.h         | 2 --
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8b6c5e339cb8..277a8fd8b83d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -896,7 +896,7 @@ static int isc_querycap(struct file *file, void *priv,
 {
 	struct isc_device *isc = video_drvdata(file);
 
-	strscpy(cap->driver, ATMEL_ISC_NAME, sizeof(cap->driver));
+	strscpy(cap->driver, "microchip-isc", sizeof(cap->driver));
 	strscpy(cap->card, "Atmel Image Sensor Controller", sizeof(cap->card));
 	snprintf(cap->bus_info, sizeof(cap->bus_info),
 		 "platform:%s", isc->v4l2_dev.name);
@@ -2246,7 +2246,7 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
 	}
 
 	/* Register video device */
-	strscpy(vdev->name, ATMEL_ISC_NAME, sizeof(vdev->name));
+	strscpy(vdev->name, "microchip-isc", sizeof(vdev->name));
 	vdev->release		= video_device_release_empty;
 	vdev->fops		= &isc_fops;
 	vdev->ioctl_ops		= &isc_ioctl_ops;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f1df47a4655b..8d81d9967ad2 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -256,8 +256,6 @@ struct isc_device {
 	u32		gamma_max;
 };
 
-#define ATMEL_ISC_NAME "atmel-isc"
-
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c74f36245bd5..f45d8b96bfb8 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -185,7 +185,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return irq;
 
 	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
-			       ATMEL_ISC_NAME, isc);
+			       "atmel-sama5d2-isc", isc);
 	if (ret < 0) {
 		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
 			irq, ret);
@@ -364,7 +364,7 @@ static struct platform_driver atmel_isc_driver = {
 	.probe	= atmel_isc_probe,
 	.remove	= atmel_isc_remove,
 	.driver	= {
-		.name		= ATMEL_ISC_NAME,
+		.name		= "atmel-sama5d2-isc",
 		.pm		= &atmel_isc_dev_pm_ops,
 		.of_match_table = of_match_ptr(atmel_isc_of_match),
 	},
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:56 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:56 +0300
Subject: [PATCH 03/30] media: atmel: atmel-isc: add checks for limiting frame
 sizes
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-4-eugen.hristev@microchip.com>

When calling the subdev, certain subdev drivers will overwrite the
frame size and adding sizes which are beyond the ISC's capabilities.
Thus we need to ensure the frame size is cropped to the maximum caps.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 277a8fd8b83d..45fc8dbb7943 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1326,6 +1326,12 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
 	pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height;
@@ -1361,6 +1367,12 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 	if (ret < 0)
 		return ret;
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	isc->fmt = *f;
 
 	if (isc->try_config.sd_format && isc->config.sd_format &&
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:57 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:57 +0300
Subject: [PATCH 04/30] media: atmel: atmel-isc: specialize max width and max
 height
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-5-eugen.hristev@microchip.com>

Move the max width and max height constants to the product specific driver
and have them in the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
 drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 45fc8dbb7943..350076dd029a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
 	 * just use the maximum ISC can receive.
 	 */
 	if (ret) {
-		pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
-		pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
+		pad_cfg->try_crop.width = isc->max_width;
+		pad_cfg->try_crop.height = isc->max_height;
 	} else {
 		pad_cfg->try_crop.width = fse.max_width;
 		pad_cfg->try_crop.height = fse.max_height;
@@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	isc->try_config.sd_format = sd_fmt;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	/*
 	 * The mbus format is the one the subdev outputs.
@@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
@@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 		return ret;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (f->fmt.pix.width > isc->max_width)
+		f->fmt.pix.width = isc->max_width;
+	if (f->fmt.pix.height > isc->max_height)
+		f->fmt.pix.height = isc->max_height;
 
 	isc->fmt = *f;
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 8d81d9967ad2..6becc6c3aaf0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -10,9 +10,6 @@
  */
 #ifndef _ATMEL_ISC_H_
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
-
 #define ISC_CLK_MAX_DIV		255
 
 enum isc_clk_id {
@@ -191,6 +188,9 @@ struct isc_ctrls {
  * @gamma_table:	pointer to the table with gamma values, has
  *			gamma_max sets of GAMMA_ENTRIES entries each
  * @gamma_max:		maximum number of sets of inside the gamma_table
+ *
+ * @max_width:		maximum frame width, dependent on the internal RAM
+ * @max_height:		maximum frame height, dependent on the internal RAM
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -254,6 +254,9 @@ struct isc_device {
 	/* pointer to the defined gamma table */
 	const u32	(*gamma_table)[GAMMA_ENTRIES];
 	u32		gamma_max;
+
+	u32		max_width;
+	u32		max_height;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f45d8b96bfb8..f8d1c8ba99b3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -49,8 +49,8 @@
 #include "atmel-isc-regs.h"
 #include "atmel-isc.h"
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
+#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
+#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
 #define ISC_CLK_MAX_DIV		255
 
@@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->gamma_table = isc_sama5d2_gamma_table;
 	isc->gamma_max = 2;
 
+	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:58 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:58 +0300
Subject: [PATCH 05/30] media: atmel: atmel-isc: specialize dma cfg
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-6-eugen.hristev@microchip.com>

The dma configuration (DCFG) is specific to the product.
Move this configuration in the product specific driver, and add the
field inside the driver struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 +--
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 350076dd029a..ff40ee2e2759 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -716,8 +716,7 @@ static int isc_configure(struct isc_device *isc)
 	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
-	dcfg = isc->config.dcfg_imode |
-		       ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+	dcfg = isc->config.dcfg_imode | isc->dcfg;
 
 	pfe_cfg0  |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 6becc6c3aaf0..d14ae096fbf6 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,6 +150,7 @@ struct isc_ctrls {
  * @hclock:		Hclock clock input (refer datasheet)
  * @ispck:		iscpck clock (refer datasheet)
  * @isc_clks:		ISC clocks
+ * @dcfg:		DMA master configuration, architecture dependent
  *
  * @dev:		Registered device driver
  * @v4l2_dev:		v4l2 registered device
@@ -197,6 +198,7 @@ struct isc_device {
 	struct clk		*hclock;
 	struct clk		*ispck;
 	struct isc_clk		isc_clks[2];
+	u32			dcfg;
 
 	struct device		*dev;
 	struct v4l2_device	v4l2_dev;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f8d1c8ba99b3..6d9942dcd7c1 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -198,6 +198,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	/* sama5d2-isc - 8 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:26:59 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:26:59 +0300
Subject: [PATCH 06/30] media: atmel: atmel-isc: extract CSC submodule config
 into separate function
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-7-eugen.hristev@microchip.com>

The CSC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  8 +-------
 drivers/media/platform/atmel/atmel-isc.h         |  7 +++++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 15 +++++++++++++++
 3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index ff40ee2e2759..31f63ba90c71 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -646,13 +646,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
-	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	isc->config_csc(isc);
 
 	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
 	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d14ae096fbf6..bb0b4419deff 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -192,6 +192,9 @@ struct isc_ctrls {
  *
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
+ *
+ * @config_csc:		pointer to a function that initializes product
+ *			specific CSC module
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -259,6 +262,10 @@ struct isc_device {
 
 	u32		max_width;
 	u32		max_height;
+
+	struct {
+		void (*config_csc)(struct isc_device *isc);
+	};
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 6d9942dcd7c1..d9f06daffdf8 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,19 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+void isc_sama5d2_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -198,6 +211,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_csc = isc_sama5d2_config_csc;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:00 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:00 +0300
Subject: [PATCH 07/30] media: atmel: atmel-isc-base: add id to clock debug
 message
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-8-eugen.hristev@microchip.com>

Add the clock id to the debug message regarding clock setup

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 31f63ba90c71..bc036e8ac4fe 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -277,8 +277,8 @@ static int isc_clk_enable(struct clk_hw *hw)
 	unsigned long flags;
 	unsigned int status;
 
-	dev_dbg(isc_clk->dev, "ISC CLK: %s, div = %d, parent id = %d\n",
-		__func__, isc_clk->div, isc_clk->parent_id);
+	dev_dbg(isc_clk->dev, "ISC CLK: %s, id = %d, div = %d, parent id = %d\n",
+		__func__, id, isc_clk->div, isc_clk->parent_id);
 
 	spin_lock_irqsave(&isc_clk->lock, flags);
 	regmap_update_bits(regmap, ISC_CLKCFG,
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:01 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:01 +0300
Subject: [PATCH 08/30] media: atmel: atmel-isc: create register offsets struct
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-9-eugen.hristev@microchip.com>

Create a struct that holds register offsets that are product specific.
Add initially the CSC register.
This allows each product that contains a variant of the ISC to add their
own register offset.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c |  2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      | 12 +++++++++++
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 20 +++++++++++++------
 4 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bc036e8ac4fe..019d931d1367 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,7 +2311,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
-		REG_FIELD(ISC_CSC_CTRL, 0, 0),
+		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index f1e160ed4351..5a65600c5f88 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -153,6 +153,9 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* Offset for CSC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CSC_OFFSET	0
+
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index bb0b4419deff..ef3a0451192d 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -144,6 +144,14 @@ struct isc_ctrls {
 
 #define ISC_PIPE_LINE_NODE_NUM	11
 
+/*
+ * struct isc_reg_offsets - ISC device register offsets
+ * @csc:		Offset for the CSC register
+ */
+struct isc_reg_offsets {
+	u32 csc;
+};
+
 /*
  * struct isc_device - ISC device driver data/config struct
  * @regmap:		Register map
@@ -195,6 +203,8 @@ struct isc_ctrls {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ *
+ * @offsets:		struct holding the product specific register offsets
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -266,6 +276,8 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 	};
+
+	struct isc_reg_offsets		offsets;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index d9f06daffdf8..3b076b87454e 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -59,12 +59,18 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 	struct regmap *regmap = isc->regmap;
 
 	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -213,6 +219,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 
+	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:02 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:02 +0300
Subject: [PATCH 09/30] media: atmel: atmel-isc: extract CBC submodule config
 into separate function
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-10-eugen.hristev@microchip.com>

The CBC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 +---
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 9 +++++++++
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 019d931d1367..446fe232956b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -647,9 +647,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
 	isc->config_csc(isc);
-
-	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
+	isc->config_cbc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index ef3a0451192d..cb47932197b1 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -203,6 +203,8 @@ struct isc_reg_offsets {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ * @config_cbc:		pointer to a function that initializes product
+ *			specific CBC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -275,6 +277,7 @@ struct isc_device {
 
 	struct {
 		void (*config_csc)(struct isc_device *isc);
+		void (*config_cbc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 3b076b87454e..36bf15a9607d 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -73,6 +73,14 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 		     0xFEE | (0x80 << 16));
 }
 
+void isc_sama5d2_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -218,6 +226,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
 	isc->config_csc = isc_sama5d2_config_csc;
+	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:03 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:03 +0300
Subject: [PATCH 10/30] media: atmel: atmel-isc: add CBC to the reg offsets
 struct
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-11-eugen.hristev@microchip.com>

Add cbc to the reg offsets struct. This will allow different products
to have a different reg offset for this particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 3 +++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++--
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 446fe232956b..d4bf7fd5929f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2310,7 +2310,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
-		REG_FIELD(ISC_CBC_CTRL, 0, 0),
+		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
 	};
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5a65600c5f88..a5e2fe01ba9f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -177,6 +177,9 @@
 /* Color Space Conversion CRB OCR Register */
 #define ISC_CSC_CRB_OCR	0x000003b0
 
+/* Offset for CBC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CBC_OFFSET	0
+
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index cb47932197b1..b1fe93c93c61 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -147,9 +147,11 @@ struct isc_ctrls {
 /*
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
+ * @cbc:		Offset for the CBC register
  */
 struct isc_reg_offsets {
 	u32 csc;
+	u32 cbc;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 36bf15a9607d..275999314e61 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -77,8 +77,10 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
 
-	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc,
+		     isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc,
+		     isc->ctrls.contrast);
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -229,6 +231,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:04 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:04 +0300
Subject: [PATCH 11/30] media: atmel: atmel-isc: add SUB422 and SUB420 to
 register offsets
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-12-eugen.hristev@microchip.com>

Add sub420 and sub422 to the reg offsets struct.
This will allow different products to have a different reg offset for these
particular modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 4 ++++
 drivers/media/platform/atmel/atmel-isc.h         | 4 ++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 ++
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index d4bf7fd5929f..b2067d75499b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,8 +2311,8 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
-		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
-		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
+		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
+		REG_FIELD(ISC_SUB420_CTRL + isc->offsets.sub420, 0, 0),
 	};
 
 	for (i = 0; i < ISC_PIPE_LINE_NODE_NUM; i++) {
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a5e2fe01ba9f..04839def6ef6 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -194,9 +194,13 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Offset for SUB422 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB422_OFFSET	0
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
+/* Offset for SUB420 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB420_OFFSET	0
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b1fe93c93c61..fb7257872e7c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -148,10 +148,14 @@ struct isc_ctrls {
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
  * @cbc:		Offset for the CBC register
+ * @sub422:		Offset for the SUB422 register
+ * @sub420:		Offset for the SUB420 register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
+	u32 sub422;
+	u32 sub420;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 275999314e61..1bf83959a9e4 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -232,6 +232,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:05 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:05 +0300
Subject: [PATCH 12/30] media: atmel: atmel-isc: add RLP to register offsets
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-13-eugen.hristev@microchip.com>

Add rlp to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index b2067d75499b..317172959370 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -718,8 +718,8 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG, ISC_RLP_CFG_MODE_MASK,
-			   rlp_mode);
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
 	regmap_write(regmap, ISC_DCFG, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 04839def6ef6..2205484e04fc 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -204,6 +204,8 @@
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
+/* Offset for RLP register specific to sama5d2 product */
+#define ISC_SAMA5D2_RLP_OFFSET	0
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fb7257872e7c..b7d4e7fab570 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,12 +150,14 @@ struct isc_ctrls {
  * @cbc:		Offset for the CBC register
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
+ * @rlp:		Offset for the RLP register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
 	u32 sub422;
 	u32 sub420;
+	u32 rlp;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 1bf83959a9e4..32c05eb1c16d 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -234,6 +234,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:06 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:06 +0300
Subject: [PATCH 13/30] media: atmel: atmel-isc: add HIS to register offsets
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-14-eugen.hristev@microchip.com>

Add his to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 11 +++++++----
 drivers/media/platform/atmel/atmel-isc-regs.h    |  2 ++
 drivers/media/platform/atmel/atmel-isc.h         |  2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c |  1 +
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 317172959370..aa7a9a7ca0e6 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -678,12 +678,13 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 	struct isc_ctrls *ctrls = &isc->ctrls;
 
 	if (enable) {
-		regmap_write(regmap, ISC_HIS_CFG,
+		regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
 			     ISC_HIS_CFG_MODE_GR |
 			     (isc->config.sd_format->cfa_baycfg
 					<< ISC_HIS_CFG_BAYSEL_SHIFT) |
 					ISC_HIS_CFG_RAR);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_EN);
 		regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
 		ctrls->hist_id = ISC_HIS_CFG_MODE_GR;
 		isc_update_profile(isc);
@@ -692,7 +693,8 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 		ctrls->hist_stat = HIST_ENABLED;
 	} else {
 		regmap_write(regmap, ISC_INTDIS, ISC_INT_HISDONE);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_DIS);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_DIS);
 
 		ctrls->hist_stat = HIST_DISABLED;
 	}
@@ -1821,7 +1823,8 @@ static void isc_awb_work(struct work_struct *w)
 			ctrls->awb = ISC_WB_NONE;
 		}
 	}
-	regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
+	regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
+		     hist_id | baysel | ISC_HIS_CFG_RAR);
 	isc_update_profile(isc);
 	/* if awb has been disabled, we don't need to start another histogram */
 	if (ctrls->awb)
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 2205484e04fc..0ab280ab59ec 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -224,6 +224,8 @@
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+/* Offset for HIS register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b7d4e7fab570..652285dc9f52 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -151,6 +151,7 @@ struct isc_ctrls {
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
+ * @his:		Offset for the HIS related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -158,6 +159,7 @@ struct isc_reg_offsets {
 	u32 sub422;
 	u32 sub420;
 	u32 rlp;
+	u32 his;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 32c05eb1c16d..886dea8b7b1c 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -235,6 +235,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:07 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:07 +0300
Subject: [PATCH 14/30] media: atmel: atmel-isc: add DMA to register offsets
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-15-eugen.hristev@microchip.com>

Add dma to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 19 ++++++++++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      |  2 ++
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  1 +
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index aa7a9a7ca0e6..11121943d2cb 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -593,16 +593,20 @@ static void isc_start_dma(struct isc_device *isc)
 			   ISC_PFE_CFG0_COLEN | ISC_PFE_CFG0_ROWEN);
 
 	addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
-	regmap_write(regmap, ISC_DAD0, addr0);
+	regmap_write(regmap, ISC_DAD0 + isc->offsets.dma, addr0);
 
 	switch (isc->config.fourcc) {
 	case V4L2_PIX_FMT_YUV420:
-		regmap_write(regmap, ISC_DAD1, addr0 + (sizeimage * 2) / 3);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 5) / 6);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + (sizeimage * 2) / 3);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 5) / 6);
 		break;
 	case V4L2_PIX_FMT_YUV422P:
-		regmap_write(regmap, ISC_DAD1, addr0 + sizeimage / 2);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 3) / 4);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + sizeimage / 2);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 3) / 4);
 		break;
 	default:
 		break;
@@ -610,7 +614,8 @@ static void isc_start_dma(struct isc_device *isc)
 
 	dctrl_dview = isc->config.dctrl_dview;
 
-	regmap_write(regmap, ISC_DCTRL, dctrl_dview | ISC_DCTRL_IE_IS);
+	regmap_write(regmap, ISC_DCTRL + isc->offsets.dma,
+		     dctrl_dview | ISC_DCTRL_IE_IS);
 	spin_lock(&isc->awb_lock);
 	regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_CAPTURE);
 	spin_unlock(&isc->awb_lock);
@@ -723,7 +728,7 @@ static int isc_configure(struct isc_device *isc)
 	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
-	regmap_write(regmap, ISC_DCFG, dcfg);
+	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
 	/* Set the pipeline */
 	isc_set_pipeline(isc, pipeline);
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 0ab280ab59ec..4940998c82a2 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -247,6 +247,9 @@
 
 #define ISC_HIS_CFG_RAR			BIT(8)
 
+/* Offset for DMA register specific to sama5d2 product */
+#define ISC_SAMA5D2_DMA_OFFSET	0
+
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
 #define ISC_DCFG_IMODE_PACKED8          0x0
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 652285dc9f52..52a9199d65ee 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -152,6 +152,7 @@ struct isc_ctrls {
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
+ * @dma:		Offset for the DMA related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -160,6 +161,7 @@ struct isc_reg_offsets {
 	u32 sub420;
 	u32 rlp;
 	u32 his;
+	u32 dma;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 886dea8b7b1c..f583288f0503 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -236,6 +236,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:08 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:08 +0300
Subject: [PATCH 15/30] media: atmel: atmel-isc: add support for version
 register
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-16-eugen.hristev@microchip.com>

Add support for version register and print it at probe time.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h    | 5 +++++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 5 +++++
 3 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 4940998c82a2..344668dcfcf4 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -295,6 +295,11 @@
 /* DMA Address 2 Register */
 #define ISC_DAD2        0x000003fc
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_VERSION_OFFSET	0
+/* Version Register */
+#define ISC_VERSION	0x0000040c
+
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 52a9199d65ee..676a5be1ee8c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -153,6 +153,7 @@ struct isc_ctrls {
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
+ * @version:		Offset for the version register
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -162,6 +163,7 @@ struct isc_reg_offsets {
 	u32 rlp;
 	u32 his;
 	u32 dma;
+	u32 version;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f583288f0503..500618240fc2 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -189,6 +189,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	struct isc_subdev_entity *subdev_entity;
 	int irq;
 	int ret;
+	u32 ver;
 
 	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
 	if (!isc)
@@ -237,6 +238,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
@@ -332,6 +334,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_request_idle(dev);
 
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip ISC version %x\n", ver);
+
 	return 0;
 
 cleanup_subdev:
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:09 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:09 +0300
Subject: [PATCH 16/30] media: atmel: atmel-isc: add his_entry to register
 offsets
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-17-eugen.hristev@microchip.com>

Add his_entry to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 ++-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 11121943d2cb..2a619eef6aa3 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1672,7 +1672,8 @@ static void isc_hist_count(struct isc_device *isc, u32 *min, u32 *max)
 	*min = 0;
 	*max = HIST_ENTRIES;
 
-	regmap_bulk_read(regmap, ISC_HIS_ENTRY, hist_entry, HIST_ENTRIES);
+	regmap_bulk_read(regmap, ISC_HIS_ENTRY + isc->offsets.his_entry,
+			 hist_entry, HIST_ENTRIES);
 
 	*hist_count = 0;
 	/*
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 344668dcfcf4..a15c13e1a833 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -300,6 +300,8 @@
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 676a5be1ee8c..c5d956fd20a0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -154,6 +154,7 @@ struct isc_ctrls {
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
  * @version:		Offset for the version register
+ * @his_entry:		Offset for the HIS entries registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -164,6 +165,7 @@ struct isc_reg_offsets {
 	u32 his;
 	u32 dma;
 	u32 version;
+	u32 his_entry;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 500618240fc2..da516f2f5ca9 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -239,6 +239,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:10 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:10 +0300
Subject: [PATCH 17/30] media: atmel: atmel-isc: add register description for
 additional modules
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-18-eugen.hristev@microchip.com>

Add register description for additional pipeline modules: the
Defective Pixel Correction (DPC) and the Vertical and Horizontal Scaler(VHXS)

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 67 +++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a15c13e1a833..457eed74cda9 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -90,6 +90,46 @@
 #define ISC_INT_DDONE		BIT(8)
 #define ISC_INT_HISDONE		BIT(12)
 
+/* ISC DPC Control Register */
+#define ISC_DPC_CTRL	0x40
+
+#define ISC_DPC_CTRL_DPCEN	BIT(0)
+#define ISC_DPC_CTRL_GDCEN	BIT(1)
+#define ISC_DPC_CTRL_BLCEN	BIT(2)
+
+/* ISC DPC Config Register */
+#define ISC_DPC_CFG	0x44
+
+#define ISC_DPC_CFG_BAYSEL_SHIFT	0
+
+#define ISC_DPC_CFG_EITPOL		BIT(4)
+
+#define ISC_DPC_CFG_TA_ENABLE		BIT(14)
+#define ISC_DPC_CFG_TC_ENABLE		BIT(13)
+#define ISC_DPC_CFG_TM_ENABLE		BIT(12)
+
+#define ISC_DPC_CFG_RE_MODE		BIT(17)
+
+#define ISC_DPC_CFG_GDCCLP_SHIFT	20
+#define ISC_DPC_CFG_GDCCLP_MASK		GENMASK(22, 20)
+
+#define ISC_DPC_CFG_BLOFF_SHIFT		24
+#define ISC_DPC_CFG_BLOFF_MASK		GENMASK(31, 24)
+
+#define ISC_DPC_CFG_BAYCFG_SHIFT	0
+#define ISC_DPC_CFG_BAYCFG_MASK		GENMASK(1, 0)
+/* ISC DPC Threshold Median Register */
+#define ISC_DPC_THRESHM	0x48
+
+/* ISC DPC Threshold Closest Register */
+#define ISC_DPC_THRESHC	0x4C
+
+/* ISC DPC Threshold Average Register */
+#define ISC_DPC_THRESHA	0x50
+
+/* ISC DPC STatus Register */
+#define ISC_DPC_SR	0x54
+
 /* ISC White Balance Control Register */
 #define ISC_WB_CTRL     0x00000058
 
@@ -153,6 +193,33 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* ISC VHXS Control Register */
+#define ISC_VHXS_CTRL	0x398
+
+/* ISC VHXS Source Size Register */
+#define ISC_VHXS_SS	0x39C
+
+/* ISC VHXS Destination Size Register */
+#define ISC_VHXS_DS	0x3A0
+
+/* ISC Vertical Factor Register */
+#define ISC_VXS_FACT	0x3a4
+
+/* ISC Horizontal Factor Register */
+#define ISC_HXS_FACT	0x3a8
+
+/* ISC Vertical Config Register */
+#define ISC_VXS_CFG	0x3ac
+
+/* ISC Horizontal Config Register */
+#define ISC_HXS_CFG	0x3b0
+
+/* ISC Vertical Tap Register */
+#define ISC_VXS_TAP	0x3b4
+
+/* ISC Horizontal Tap Register */
+#define ISC_HXS_TAP	0x434
+
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
 
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:11 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:11 +0300
Subject: [PATCH 18/30] media: atmel: atmel-isc: extend pipeline with extra
 modules
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-19-eugen.hristev@microchip.com>

Newer ISC pipelines have the additional modules of
Defective Pixel Correction -> DPC itself,
Defective Pixel Correction -> Green Disparity Correction (DPC_GDC)
Defective Pixel Correction -> Black Level Correction (DPC_BLC)
Vertical and Horizontal Scaler -> VHXS

Some products have this full pipeline (sama7g5), other products do not (sama5d2)

Add the modules to the isc base, and also extend the register range to include
the modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 11 ++++++--
 drivers/media/platform/atmel/atmel-isc.h      | 28 +++++++++++--------
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 2a619eef6aa3..66005cb3940f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2309,8 +2309,14 @@ int isc_pipeline_init(struct isc_device *isc)
 	struct regmap_field *regs;
 	unsigned int i;
 
-	/* WB-->CFA-->CC-->GAM-->CSC-->CBC-->SUB422-->SUB420 */
+	/*
+	 * DPCEN-->GDCEN-->BLCEN-->WB-->CFA-->CC-->
+	 * GAM-->VHXS-->CSC-->CBC-->SUB422-->SUB420
+	 */
 	const struct reg_field regfields[ISC_PIPE_LINE_NODE_NUM] = {
+		REG_FIELD(ISC_DPC_CTRL, 0, 0),
+		REG_FIELD(ISC_DPC_CTRL, 1, 1),
+		REG_FIELD(ISC_DPC_CTRL, 2, 2),
 		REG_FIELD(ISC_WB_CTRL, 0, 0),
 		REG_FIELD(ISC_CFA_CTRL, 0, 0),
 		REG_FIELD(ISC_CC_CTRL, 0, 0),
@@ -2318,6 +2324,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
+		REG_FIELD(ISC_VHXS_CTRL, 0, 0),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
@@ -2336,7 +2343,7 @@ int isc_pipeline_init(struct isc_device *isc)
 }
 
 /* regmap configuration */
-#define ATMEL_ISC_REG_MAX    0xbfc
+#define ATMEL_ISC_REG_MAX    0xd5c
 const struct regmap_config isc_regmap_config = {
 	.reg_bits       = 32,
 	.reg_stride     = 4,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index c5d956fd20a0..f574bcc3ba67 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -68,17 +68,21 @@ struct isc_format {
 };
 
 /* Pipeline bitmap */
-#define WB_ENABLE	BIT(0)
-#define CFA_ENABLE	BIT(1)
-#define CC_ENABLE	BIT(2)
-#define GAM_ENABLE	BIT(3)
-#define GAM_BENABLE	BIT(4)
-#define GAM_GENABLE	BIT(5)
-#define GAM_RENABLE	BIT(6)
-#define CSC_ENABLE	BIT(7)
-#define CBC_ENABLE	BIT(8)
-#define SUB422_ENABLE	BIT(9)
-#define SUB420_ENABLE	BIT(10)
+#define DPC_DPCENABLE	BIT(0)
+#define DPC_GDCENABLE	BIT(1)
+#define DPC_BLCENABLE	BIT(2)
+#define WB_ENABLE	BIT(3)
+#define CFA_ENABLE	BIT(4)
+#define CC_ENABLE	BIT(5)
+#define GAM_ENABLE	BIT(6)
+#define GAM_BENABLE	BIT(7)
+#define GAM_GENABLE	BIT(8)
+#define GAM_RENABLE	BIT(9)
+#define VHXS_ENABLE	BIT(10)
+#define CSC_ENABLE	BIT(11)
+#define CBC_ENABLE	BIT(12)
+#define SUB422_ENABLE	BIT(13)
+#define SUB420_ENABLE	BIT(14)
 
 #define GAM_ENABLES	(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
 
@@ -142,7 +146,7 @@ struct isc_ctrls {
 	u32 hist_minmax[HIST_BAYER][2];
 };
 
-#define ISC_PIPE_LINE_NODE_NUM	11
+#define ISC_PIPE_LINE_NODE_NUM	15
 
 /*
  * struct isc_reg_offsets - ISC device register offsets
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:12 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:12 +0300
Subject: [PATCH 19/30] media: atmel: atmel-isc: add CC initialization function
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-20-eugen.hristev@microchip.com>

Implement the color correction (CC) submodule initialization, as a product
specific function, which currently configures the neutral point in color
correction.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  1 +
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 14 ++++++++++++++
 3 files changed, 18 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 66005cb3940f..182903803c05 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -653,6 +653,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
+	isc->config_cc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f574bcc3ba67..a5f8d5001381 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -225,6 +225,8 @@ struct isc_reg_offsets {
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
  *			specific CBC module
+ * @config_cc:		pointer to a function that initializes product
+ *			specific CC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -298,6 +300,7 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
+		void (*config_cc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index da516f2f5ca9..917d10baa525 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -83,6 +83,19 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 		     isc->ctrls.contrast);
 }
 
+void isc_sama5d2_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -230,6 +243,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
+	isc->config_cc = isc_sama5d2_config_cc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:13 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:13 +0300
Subject: [PATCH 20/30] media: atmel: atmel-isc: create product specific v4l2
 controls config
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-21-eugen.hristev@microchip.com>

Create product specific callback for initializing v4l2 controls.
Call this from v4l2 controls init function.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  5 +++--
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 12 ++++++++++++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 182903803c05..69952b6ac401 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2036,11 +2036,12 @@ static int isc_ctrl_init(struct isc_device *isc)
 	if (ret < 0)
 		return ret;
 
+	/* Initialize product specific controls. For example, contrast */
+	isc->config_ctrls(isc, ops);
+
 	ctrls->brightness = 0;
-	ctrls->contrast = 256;
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
 			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index a5f8d5001381..eb549fadb1a8 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -227,6 +227,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_ctrls:	pointer to a functoin that initializes product
+ *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -301,6 +303,9 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+
+		void (*config_ctrls)(struct isc_device *isc,
+				     const struct v4l2_ctrl_ops *ops);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 917d10baa525..a8375961f97d 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -96,6 +96,17 @@ void isc_sama5d2_config_cc(struct isc_device *isc)
 	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
 }
 
+void isc_sama5d2_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 256;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -244,6 +255,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:14 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:14 +0300
Subject: [PATCH 21/30] media: atmel: atmel-isc: create callback for DPC
 submodule product specific
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-22-eugen.hristev@microchip.com>

Create a product specific callback for initializing the DPC submodule
of the pipeline.
For sama5d2 product, this module does not exist, thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 6 ++++++
 3 files changed, 10 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 69952b6ac401..1f7116abc61a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -651,6 +651,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
+	isc->config_dpc(isc);
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index eb549fadb1a8..d6cd85a4c3e9 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -221,6 +221,8 @@ struct isc_reg_offsets {
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
  *
+ * @config_dpc:		pointer to a function that initializes product
+ *			specific DPC module
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
@@ -300,6 +302,7 @@ struct isc_device {
 	u32		max_height;
 
 	struct {
+		void (*config_dpc)(struct isc_device *isc);
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index a8375961f97d..ae906126ffb8 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -107,6 +107,11 @@ void isc_sama5d2_config_ctrls(struct isc_device *isc,
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 }
 
+void isc_sama5d2_config_dpc(struct isc_device *isc)
+{
+	/* This module is not present on sama5d2 pipeline */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -252,6 +257,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_dpc = isc_sama5d2_config_dpc;
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:15 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:15 +0300
Subject: [PATCH 22/30] media: atmel: atmel-isc: create callback for GAM
 submodule product specific
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-23-eugen.hristev@microchip.com>

Create a product specific callback for initializing the GAM submodule
of the pipeline.
For sama5d2 product, there is no special configuration at this moment,
thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 6 ++++++
 3 files changed, 10 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 1f7116abc61a..bd24e0c99613 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -655,6 +655,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
+	isc->config_gam(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d6cd85a4c3e9..1e6988f1876e 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -229,6 +229,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_gam:		pointer to a function that initializes product
+ *			specific GAMMA module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -306,6 +308,7 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+		void (*config_gam)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index ae906126ffb8..f5863bf3ac32 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -112,6 +112,11 @@ void isc_sama5d2_config_dpc(struct isc_device *isc)
 	/* This module is not present on sama5d2 pipeline */
 }
 
+void isc_sama5d2_config_gam(struct isc_device *isc)
+{
+	/* No specific gamma configuration */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -261,6 +266,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_gam = isc_sama5d2_config_gam;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:17 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:17 +0300
Subject: [PATCH 24/30] media: atmel: atmel-isc: move the formats list into
 product specific code
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-25-eugen.hristev@microchip.com>

The list of input and output formats has to be product specific.
Move this list into the product specific code.
Have pointers to these arrays inside the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 167 ++----------------
 drivers/media/platform/atmel/atmel-isc.h      |  12 +-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 136 ++++++++++++++
 3 files changed, 165 insertions(+), 150 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8422df41f083..6746c9060e3f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -45,137 +45,6 @@ module_param(sensor_preferred, uint, 0644);
 MODULE_PARM_DESC(sensor_preferred,
 		 "Sensor is preferred to output the specified format (1-on 0-off), default 1");
 
-/* This is a list of the formats that the ISC can *output* */
-const struct isc_format controller_formats[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB444,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB555,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ABGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_XBGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV420,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV422P,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-	},
-};
-
-/* This is a list of formats that the ISC can receive as *input* */
-struct isc_format formats_list[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR8,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB8,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR10,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB10,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR12,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB12,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-	},
-
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -906,25 +775,26 @@ static int isc_querycap(struct file *file, void *priv,
 static int isc_enum_fmt_vid_cap(struct file *file, void *priv,
 				 struct v4l2_fmtdesc *f)
 {
+	struct isc_device *isc = video_drvdata(file);
 	u32 index = f->index;
 	u32 i, supported_index;
 
-	if (index < ARRAY_SIZE(controller_formats)) {
-		f->pixelformat = controller_formats[index].fourcc;
+	if (index < isc->controller_formats_size) {
+		f->pixelformat = isc->controller_formats[index].fourcc;
 		return 0;
 	}
 
-	index -= ARRAY_SIZE(controller_formats);
+	index -= isc->controller_formats_size;
 
 	i = 0;
 	supported_index = 0;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
-		if (!ISC_IS_FORMAT_RAW(formats_list[i].mbus_code) ||
-		    !formats_list[i].sd_support)
+	for (i = 0; i < isc->formats_list_size; i++) {
+		if (!ISC_IS_FORMAT_RAW(isc->formats_list[i].mbus_code) ||
+		    !isc->formats_list[i].sd_support)
 			continue;
 		if (supported_index == index) {
-			f->pixelformat = formats_list[i].fourcc;
+			f->pixelformat = isc->formats_list[i].fourcc;
 			return 0;
 		}
 		supported_index++;
@@ -1465,8 +1335,8 @@ static int isc_enum_framesizes(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fsize->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fsize->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fsize->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -1502,8 +1372,8 @@ static int isc_enum_frameintervals(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fival->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fival->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fival->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -2111,12 +1981,13 @@ static void isc_async_unbind(struct v4l2_async_notifier *notifier,
 	v4l2_ctrl_handler_free(&isc->ctrls.handler);
 }
 
-static struct isc_format *find_format_by_code(unsigned int code, int *index)
+static struct isc_format *find_format_by_code(struct isc_device *isc,
+					      unsigned int code, int *index)
 {
-	struct isc_format *fmt = &formats_list[0];
+	struct isc_format *fmt = &isc->formats_list[0];
 	unsigned int i;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
+	for (i = 0; i < isc->formats_list_size; i++) {
 		if (fmt->mbus_code == code) {
 			*index = i;
 			return fmt;
@@ -2133,7 +2004,7 @@ static int isc_formats_init(struct isc_device *isc)
 	struct isc_format *fmt;
 	struct v4l2_subdev *subdev = isc->current_subdev->sd;
 	unsigned int num_fmts, i, j;
-	u32 list_size = ARRAY_SIZE(formats_list);
+	u32 list_size = isc->formats_list_size;
 	struct v4l2_subdev_mbus_code_enum mbus_code = {
 		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
 	};
@@ -2143,7 +2014,7 @@ static int isc_formats_init(struct isc_device *isc)
 	       NULL, &mbus_code)) {
 		mbus_code.index++;
 
-		fmt = find_format_by_code(mbus_code.code, &i);
+		fmt = find_format_by_code(isc, mbus_code.code, &i);
 		if (!fmt) {
 			v4l2_warn(&isc->v4l2_dev, "Mbus code %x not supported\n",
 				  mbus_code.code);
@@ -2164,7 +2035,7 @@ static int isc_formats_init(struct isc_device *isc)
 	if (!isc->user_formats)
 		return -ENOMEM;
 
-	fmt = &formats_list[0];
+	fmt = &isc->formats_list[0];
 	for (i = 0, j = 0; i < list_size; i++) {
 		if (fmt->sd_support)
 			isc->user_formats[j++] = fmt;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index abeef7b2ab27..14e318a7373c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -237,6 +237,12 @@ struct isc_reg_offsets {
  *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
+ * @controller_formats:	pointer to the array of possible formats that the
+ *			controller can output
+ * @formats_list:	pointer to the array of possible formats that can
+ *			be used as an input to the controller
+ * @controller_formats_size:	size of controller_formats array
+ * @formats_list_size:	size of formats_list array
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -318,10 +324,12 @@ struct isc_device {
 	};
 
 	struct isc_reg_offsets		offsets;
+	const struct isc_format		*controller_formats;
+	struct isc_format		*formats_list;
+	u32				controller_formats_size;
+	u32				formats_list_size;
 };
 
-extern struct isc_format formats_list[];
-extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 342259ad3690..38b9667537a3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,137 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama5d2_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama5d2_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
@@ -289,6 +420,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
+	isc->controller_formats = sama5d2_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama5d2_controller_formats);
+	isc->formats_list = sama5d2_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama5d2_formats_list);
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:18 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:18 +0300
Subject: [PATCH 25/30] media: atmel: atmel-isc: create an adapt pipeline
 callback for product specific
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-26-eugen.hristev@microchip.com>

Once the pipeline is set in the base code, create a callback that will adapt
the ISC pipeline to each product.
Create the adapt_pipeline callback that will be used in this fashion.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  4 ++++
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 11 +++++++++++
 3 files changed, 20 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 6746c9060e3f..a3c299068bd5 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1047,6 +1047,10 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 	default:
 		isc->try_config.bits_pipeline = 0x0;
 	}
+
+	/* Tune the pipeline to product specific */
+	isc->adapt_pipeline(isc);
+
 	return 0;
 }
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 14e318a7373c..19cc60dfcbe0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -236,6 +236,9 @@ struct isc_reg_offsets {
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
+ * @adapt_pipeline:	pointer to a function that adapts the pipeline bits
+ *			to the product specific pipeline
+ *
  * @offsets:		struct holding the product specific register offsets
  * @controller_formats:	pointer to the array of possible formats that the
  *			controller can output
@@ -321,6 +324,8 @@ struct isc_device {
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
+
+		void (*adapt_pipeline)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 38b9667537a3..c5687fb5b022 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,10 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+#define ISC_SAMA5D2_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
 /* This is a list of the formats that the ISC can *output* */
 const struct isc_format sama5d2_controller_formats[] = {
 	{
@@ -257,6 +261,11 @@ void isc_sama5d2_config_rlp(struct isc_device *isc)
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 }
 
+void isc_sama5d2_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA5D2_PIPELINE;
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -410,6 +419,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
+	isc->adapt_pipeline = isc_sama5d2_adapt_pipeline;
+
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:16 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:16 +0300
Subject: [PATCH 23/30] media: atmel: atmel-isc: create callback for RLP
 submodule product specific
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-24-eugen.hristev@microchip.com>

Create a product specific callback for initializing the RLP submodule
of the pipeline

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  6 ++----
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 10 ++++++++++
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bd24e0c99613..8422df41f083 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -711,11 +711,10 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 static int isc_configure(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
-	u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
+	u32 pfe_cfg0, dcfg, mask, pipeline;
 	struct isc_subdev_entity *subdev = isc->current_subdev;
 
 	pfe_cfg0 = isc->config.sd_format->pfe_cfg0_bps;
-	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
 	dcfg = isc->config.dcfg_imode | isc->dcfg;
@@ -728,8 +727,7 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
-			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+	isc->config_rlp(isc);
 
 	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 1e6988f1876e..abeef7b2ab27 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -231,6 +231,8 @@ struct isc_reg_offsets {
  *			specific CC module
  * @config_gam:		pointer to a function that initializes product
  *			specific GAMMA module
+ * @config_rlp:		pointer to a function that initializes product
+ *			specific RLP module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -309,6 +311,7 @@ struct isc_device {
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
 		void (*config_gam)(struct isc_device *isc);
+		void (*config_rlp)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f5863bf3ac32..342259ad3690 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -117,6 +117,15 @@ void isc_sama5d2_config_gam(struct isc_device *isc)
 	/* No specific gamma configuration */
 }
 
+void isc_sama5d2_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -267,6 +276,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
 	isc->config_gam = isc_sama5d2_config_gam;
+	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:19 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:19 +0300
Subject: [PATCH 26/30] media: atmel: atmel-isc-regs: add additional fields for
 sama7g5 type pipeline
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-27-eugen.hristev@microchip.com>

Add additional fields for registers present in sama7g5 type pipeline.
Extend register masks for additional bits in sama7g5 type pipeline registers.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 457eed74cda9..5f99bf7717c1 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -289,8 +289,18 @@
 #define ISC_RLP_CFG_MODE_ARGB32         0xa
 #define ISC_RLP_CFG_MODE_YYCC           0xb
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
+#define ISC_RLP_CFG_MODE_YCYC           0xd
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+#define ISC_RLP_CFG_LSH			BIT(5)
+
+#define ISC_RLP_CFG_YMODE_YUYV		(3 << 6)
+#define ISC_RLP_CFG_YMODE_YVYU		(2 << 6)
+#define ISC_RLP_CFG_YMODE_VYUY		(0 << 6)
+#define ISC_RLP_CFG_YMODE_UYVY		(1 << 6)
+
+#define ISC_RLP_CFG_YMODE_MASK		GENMASK(7, 6)
+
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
@@ -332,13 +342,15 @@
 #define ISC_DCFG_YMBSIZE_BEATS4         (0x1 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS8         (0x2 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS16        (0x3 << 4)
-#define ISC_DCFG_YMBSIZE_MASK           GENMASK(5, 4)
+#define ISC_DCFG_YMBSIZE_BEATS32        (0x4 << 4)
+#define ISC_DCFG_YMBSIZE_MASK           GENMASK(6, 4)
 
 #define ISC_DCFG_CMBSIZE_SINGLE         (0x0 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS4         (0x1 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS8         (0x2 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS16        (0x3 << 8)
-#define ISC_DCFG_CMBSIZE_MASK           GENMASK(9, 8)
+#define ISC_DCFG_CMBSIZE_BEATS32        (0x4 << 8)
+#define ISC_DCFG_CMBSIZE_MASK           GENMASK(10, 8)
 
 /* DMA Control Register */
 #define ISC_DCTRL       0x000003e4
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:20 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:20 +0300
Subject: [PATCH 27/30] media: atmel: atmel-isc-base: add support for more
 formats and additional pipeline modules
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-28-eugen.hristev@microchip.com>

Add support for additional formats supported by newer pipelines, and for
additional pipeline modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 48 +++++++++++++++----
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index a3c299068bd5..f30493a1dccd 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -843,6 +843,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
 	case V4L2_PIX_FMT_YUV420:
 	case V4L2_PIX_FMT_YUV422P:
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		ret = 0;
 		yuv = true;
 		break;
@@ -857,6 +859,7 @@ static int isc_try_validate_formats(struct isc_device *isc)
 		break;
 	case V4L2_PIX_FMT_GREY:
 	case V4L2_PIX_FMT_Y10:
+	case V4L2_PIX_FMT_Y16:
 		ret = 0;
 		grey = true;
 		break;
@@ -887,6 +890,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
  */
 static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 {
+	isc->try_config.rlp_cfg_mode = 0;
+
 	switch (isc->try_config.fourcc) {
 	case V4L2_PIX_FMT_SBGGR8:
 	case V4L2_PIX_FMT_SGBRG8:
@@ -953,7 +958,19 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.bpp = 16;
 		break;
 	case V4L2_PIX_FMT_YUYV:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YYCC;
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_YUYV;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_UYVY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_UYVY;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_VYUY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_VYUY;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -964,8 +981,11 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 8;
 		break;
+	case V4L2_PIX_FMT_Y16:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10 | ISC_RLP_CFG_LSH;
+		fallthrough;
 	case V4L2_PIX_FMT_Y10:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10;
+		isc->try_config.rlp_cfg_mode |= ISC_RLP_CFG_MODE_DATY10;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED16;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -999,7 +1019,8 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				WB_ENABLE | GAM_ENABLES;
+				WB_ENABLE | GAM_ENABLES | DPC_BLCENABLE |
+				CC_ENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1008,8 +1029,9 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE;
+				CSC_ENABLE | GAM_ENABLES | WB_ENABLE |
+				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE |
+				DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1019,33 +1041,39 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_GREY:
-		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
+	case V4L2_PIX_FMT_Y16:
 		/* if sensor format is RAW, we convert inside ISC */
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				CBC_ENABLE;
+				CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	default:
-		isc->try_config.bits_pipeline = 0x0;
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code))
+			isc->try_config.bits_pipeline = WB_ENABLE | DPC_BLCENABLE;
+		else
+			isc->try_config.bits_pipeline = 0x0;
 	}
 
 	/* Tune the pipeline to product specific */
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:21 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:21 +0300
Subject: [PATCH 28/30] dt-bindings: media: atmel: add microchip-xisc binding
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-29-eugen.hristev@microchip.com>

Add bindings for the microchip xisc, a driver based on atmel-isc.
It shares common code with atmel-isc, but the xisc is the next generation
ISC which is present on sama7g5 product.
It has an enhanced pipeline, additional modules, formats, and it supports
not only parallel sensors, but also serial sensors, by connecting to a demux
endpoint present on sama7g5.
One of the key points for creating a new binding is the clocking scheme, as
atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
input clock.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---

Hello Rob, all,

I did not convert this yet to yaml because I would like first your feedback
if the binding is good.
If it's fine I will convert both this new binding and the old atmel-isc
to yaml.

Thanks for your feedback,
Eugen

 .../bindings/media/microchip-xisc.txt         | 64 +++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt

diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt b/Documentation/devicetree/bindings/media/microchip-xisc.txt
new file mode 100644
index 000000000000..080a357ed84d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
@@ -0,0 +1,64 @@
+Microchip eXtended Image Sensor Controller (XISC)
+----------------------------------------------
+
+Required properties for XISC:
+- compatible
+	Must be "microchip,sama7g5-xisc".
+- reg
+	Physical base address and length of the registers set for the device.
+- interrupts
+	Should contain IRQ line for the XISC.
+- clocks
+	List of clock specifiers, corresponding to entries in
+	the clock-names property;
+	Please refer to clock-bindings.txt.
+- clock-names
+	Required elements: "hclock".
+	This is the clock that clocks the sensor controller, and is usually
+	fed from the clock tree. It is used for the internal controller logic.
+- #clock-cells
+	Should be 0.
+- clock-output-names
+	Should be "isc-mck".
+- pinctrl-names, pinctrl-0
+	Please refer to pinctrl-bindings.txt.
+
+Optional properties for XISC:
+- microchip,mipi-mode;
+	As the XISC is usually connected to a demux/bridge, the XISC receives
+	the same type of input, however, it should be aware of the type of
+	signals received. The mipi-mode enables different internal handling
+	of the data and clock lines.
+
+XISC supports a single port node with internal parallel bus.
+It should contain one 'port' child node with child 'endpoint' node.
+Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+This endpoint has to be connected to a bridge that acts as a demux from either
+a serial interface or acts as a simple direct bridge to a parallel sensor.
+
+Example:
+xisc: xisc at e1408000 {
+	compatible = "microchip,sama7g5-isc";
+	reg = <0xe1408000 0x2000>;
+	interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+	clock-names = "hclock";
+	#clock-cells = <0>;
+	clock-output-names = "isc-mck";
+	microchip,mipi-mode;
+
+	port at 1 {
+		reg = <1>;
+		xisc_in: endpoint {
+		bus-width = <12>;
+		hsync-active = <1>;
+		vsync-active = <1>;
+		remote-endpoint = <&csi2dc_out>;
+		};
+	};
+};
+
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:22 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:22 +0300
Subject: [PATCH 29/30] media: atmel: atmel-isc-sama5d2: remove duplicate define
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-30-eugen.hristev@microchip.com>

Remove a duplicate definition of clock max divider

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c5687fb5b022..b34c3ab0b888 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -52,8 +52,6 @@
 #define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
 #define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
-#define ISC_CLK_MAX_DIV		255
-
 #define ISC_SAMA5D2_PIPELINE \
 	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
 	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr  1 12:27:23 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 1 Apr 2021 14:27:23 +0300
Subject: [PATCH 30/30] media: atmel: atmel-isc: add microchip-xisc driver
In-Reply-To: <20210401112723.189107-1-eugen.hristev@microchip.com>
References: <20210401112723.189107-1-eugen.hristev@microchip.com>
Message-ID: <20210401112723.189107-31-eugen.hristev@microchip.com>

Add driver for the extended variant of the isc, the microchip XISC
present on sama7g5 product.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c |   2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  26 +
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 644 ++++++++++++++++++
 6 files changed, 685 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index eedc14aafb32..73ce083c2fc6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)		+= rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)		+= atmel/
 obj-$(CONFIG_VIDEO_ATMEL_ISI)		+= atmel/
+obj-$(CONFIG_VIDEO_ATMEL_XISC)		+= atmel/
 
 obj-$(CONFIG_VIDEO_STM32_DCMI)		+= stm32/
 
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 1850fe7f9360..99b51213f871 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -12,6 +12,17 @@ config VIDEO_ATMEL_ISC
 	   This module makes the ATMEL Image Sensor Controller available
 	   as a v4l2 device.
 
+config VIDEO_ATMEL_XISC
+	tristate "ATMEL eXtended Image Sensor Controller (XISC) support"
+	depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+	depends on ARCH_AT91 || COMPILE_TEST
+	select VIDEOBUF2_DMA_CONTIG
+	select REGMAP_MMIO
+	select V4L2_FWNODE
+	help
+	   This module makes the ATMEL eXtended Image Sensor Controller
+	   available as a v4l2 device.
+
 config VIDEO_ATMEL_ISI
 	tristate "ATMEL Image Sensor Interface (ISI) support"
 	depends on VIDEO_V4L2 && OF
diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile
index 2dba38994a70..c5c01556c653 100644
--- a/drivers/media/platform/atmel/Makefile
+++ b/drivers/media/platform/atmel/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o
+atmel-xisc-objs = atmel-sama7g5-isc.o atmel-isc-base.o
 
 obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
 obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
+obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel-xisc.o
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index f30493a1dccd..d6409406ce2f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -592,7 +592,7 @@ static int isc_configure(struct isc_device *isc)
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
 	       ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW |
 	       ISC_PFE_CFG0_MODE_MASK | ISC_PFE_CFG0_CCIR_CRC |
-		   ISC_PFE_CFG0_CCIR656;
+	       ISC_PFE_CFG0_CCIR656 | ISC_PFE_CFG0_MIPI;
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5f99bf7717c1..d06b72228d4f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -26,6 +26,7 @@
 #define ISC_PFE_CFG0_PPOL_LOW   BIT(2)
 #define ISC_PFE_CFG0_CCIR656    BIT(9)
 #define ISC_PFE_CFG0_CCIR_CRC   BIT(10)
+#define ISC_PFE_CFG0_MIPI	BIT(14)
 
 #define ISC_PFE_CFG0_MODE_PROGRESSIVE   (0x0 << 4)
 #define ISC_PFE_CFG0_MODE_MASK          GENMASK(6, 4)
@@ -184,6 +185,8 @@
 /* ISC Gamma Correction Control Register */
 #define ISC_GAM_CTRL    0x00000094
 
+#define ISC_GAM_CTRL_BIPART	BIT(4)
+
 /* ISC_Gamma Correction Blue Entry Register */
 #define ISC_GAM_BENTRY	0x00000098
 
@@ -222,6 +225,8 @@
 
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
+/* Offset for CSC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CSC_OFFSET	0x11c
 
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
@@ -246,6 +251,8 @@
 
 /* Offset for CBC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CBC_OFFSET	0
+/* Offset for CBC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CBC_OFFSET	0x11c
 
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
@@ -261,18 +268,30 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Hue Register */
+#define ISC_CBCHS_HUE	0x4e0
+/* Saturation Register */
+#define ISC_CBCHS_SAT	0x4e4
+
 /* Offset for SUB422 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB422_OFFSET	0
+/* Offset for SUB422 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB422_OFFSET	0x124
+
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
 /* Offset for SUB420 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB420_OFFSET	0
+/* Offset for SUB420 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB420_OFFSET	0x124
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
 /* Offset for RLP register specific to sama5d2 product */
 #define ISC_SAMA5D2_RLP_OFFSET	0
+/* Offset for RLP register specific to sama7g5 product */
+#define ISC_SAMA7G5_RLP_OFFSET	0x124
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
@@ -303,6 +322,8 @@
 
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
+/* Offset for HIS register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_OFFSET	0x124
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
@@ -326,6 +347,8 @@
 
 /* Offset for DMA register specific to sama5d2 product */
 #define ISC_SAMA5D2_DMA_OFFSET	0
+/* Offset for DMA register specific to sama7g5 product */
+#define ISC_SAMA7G5_DMA_OFFSET	0x13c
 
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
@@ -376,11 +399,14 @@
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_VERSION_OFFSET	0
+#define ISC_SAMA7G5_VERSION_OFFSET	0x13c
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
+/* Offset for version register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_ENTRY_OFFSET	0x14c
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-sama7g5-isc.c b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
new file mode 100644
index 000000000000..0bc914615e76
--- /dev/null
+++ b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
@@ -0,0 +1,644 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip eXtended Image Sensor Controller (XISC) driver
+ *
+ * Copyright (C) 2019-2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ * Author: Eugen Hristev <eugen.hristev at microchip.com>
+ *
+ * Sensor-->PFE-->DPC-->WB-->CFA-->CC-->GAM-->VHXS-->CSC-->CBHS-->SUB-->RLP-->DMA-->HIS
+ *
+ * ISC video pipeline integrates the following submodules:
+ * PFE: Parallel Front End to sample the camera sensor input stream
+ * DPC: Defective Pixel Correction with black offset correction, green disparity
+ *      correction and defective pixel correction (3 modules total)
+ *  WB: Programmable white balance in the Bayer domain
+ * CFA: Color filter array interpolation module
+ *  CC: Programmable color correction
+ * GAM: Gamma correction
+ *VHXS: Vertical and Horizontal Scaler
+ * CSC: Programmable color space conversion
+ *CBHS: Contrast Brightness Hue and Saturation control
+ * SUB: This module performs YCbCr444 to YCbCr420 chrominance subsampling
+ * RLP: This module performs rounding, range limiting
+ *      and packing of the incoming data
+ * DMA: This module performs DMA master accesses to write frames to external RAM
+ * HIS: Histogram module performs statistic counters on the frames
+ */
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/videodev2.h>
+
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-event.h>
+#include <media/v4l2-image-sizes.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+#include <media/videobuf2-dma-contig.h>
+
+#include "atmel-isc-regs.h"
+#include "atmel-isc.h"
+
+#define ISC_SAMA7G5_MAX_SUPPORT_WIDTH   3264
+#define ISC_SAMA7G5_MAX_SUPPORT_HEIGHT  2464
+
+#define ISC_SAMA7G5_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama7g5_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_VYUY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y16,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama7g5_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
+void isc_sama7g5_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
+}
+
+void isc_sama7g5_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure what is set via v4l2 ctrls */
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc, isc->ctrls.contrast);
+	/* Configure Hue and Saturation as neutral midpoint */
+	regmap_write(regmap, ISC_CBCHS_HUE, 0);
+	regmap_write(regmap, ISC_CBCHS_SAT, (1 << 4));
+}
+
+void isc_sama7g5_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
+void isc_sama7g5_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 16;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 16);
+}
+
+void isc_sama7g5_config_dpc(struct isc_device *isc)
+{
+	u32 bay_cfg = isc->config.sd_format->cfa_baycfg;
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BLOFF_MASK,
+			   (64 << ISC_DPC_CFG_BLOFF_SHIFT));
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BAYCFG_MASK,
+			   (bay_cfg << ISC_DPC_CFG_BAYCFG_SHIFT));
+}
+
+void isc_sama7g5_config_gam(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_GAM_CTRL, ISC_GAM_CTRL_BIPART,
+			   ISC_GAM_CTRL_BIPART);
+}
+
+void isc_sama7g5_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK | ISC_RLP_CFG_LSH |
+			   ISC_RLP_CFG_YMODE_MASK, rlp_mode);
+}
+
+void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA7G5_PIPELINE;
+}
+
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama7g5_gamma_table[][GAMMA_ENTRIES] = {
+	/* index 0 --> gamma bipartite */
+	{
+	      0x980,  0x4c0320,  0x650260,  0x7801e0,  0x8701a0,  0x940180,
+	   0xa00160,  0xab0120,  0xb40120,  0xbd0120,  0xc60100,  0xce0100,
+	   0xd600e0,  0xdd00e0,  0xe400e0,  0xeb00c0,  0xf100c0,  0xf700c0,
+	   0xfd00c0, 0x10300a0, 0x10800c0, 0x10e00a0, 0x11300a0, 0x11800a0,
+	  0x11d00a0, 0x12200a0, 0x12700a0, 0x12c0080, 0x13000a0, 0x1350080,
+	  0x13900a0, 0x13e0080, 0x1420076, 0x17d0062, 0x1ae0054, 0x1d8004a,
+	  0x1fd0044, 0x21f003e, 0x23e003a, 0x25b0036, 0x2760032, 0x28f0030,
+	  0x2a7002e, 0x2be002c, 0x2d4002c, 0x2ea0028, 0x2fe0028, 0x3120026,
+	  0x3250024, 0x3370024, 0x3490022, 0x35a0022, 0x36b0020, 0x37b0020,
+	  0x38b0020, 0x39b001e, 0x3aa001e, 0x3b9001c, 0x3c7001c, 0x3d5001c,
+	  0x3e3001c, 0x3f1001c, 0x3ff001a, 0x40c001a },
+};
+
+static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
+{
+	struct device_node *np = dev->of_node;
+	struct device_node *epn = NULL, *rem;
+	struct isc_subdev_entity *subdev_entity;
+	unsigned int flags;
+	int ret;
+	bool mipi_mode;
+
+	INIT_LIST_HEAD(&isc->subdev_entities);
+
+	mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
+
+	while (1) {
+		struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
+
+		epn = of_graph_get_next_endpoint(np, epn);
+		if (!epn)
+			return 0;
+
+		rem = of_graph_get_remote_port_parent(epn);
+		if (!rem) {
+			dev_notice(dev, "Remote device at %pOF not found\n",
+				   epn);
+			continue;
+		}
+
+		ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
+						 &v4l2_epn);
+		if (ret) {
+			of_node_put(rem);
+			ret = -EINVAL;
+			dev_err(dev, "Could not parse the endpoint\n");
+			break;
+		}
+
+		subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
+					     GFP_KERNEL);
+		if (!subdev_entity) {
+			of_node_put(rem);
+			ret = -ENOMEM;
+			break;
+		}
+
+		/* asd will be freed by the subsystem once it's added to the
+		 * notifier list
+		 */
+		subdev_entity->asd = kzalloc(sizeof(*subdev_entity->asd),
+					     GFP_KERNEL);
+		if (!subdev_entity->asd) {
+			of_node_put(rem);
+			ret = -ENOMEM;
+			break;
+		}
+
+		flags = v4l2_epn.bus.parallel.flags;
+
+		if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
+
+		if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
+
+		if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
+
+		if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
+					ISC_PFE_CFG0_CCIR656;
+
+		if (mipi_mode)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
+
+		subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
+		subdev_entity->asd->match.fwnode = of_fwnode_handle(rem);
+		list_add_tail(&subdev_entity->list, &isc->subdev_entities);
+	}
+
+	of_node_put(epn);
+	return ret;
+}
+
+static int microchip_xisc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct isc_device *isc;
+	struct resource *res;
+	void __iomem *io_base;
+	struct isc_subdev_entity *subdev_entity;
+	int irq;
+	int ret;
+	u32 ver;
+
+	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
+	if (!isc)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, isc);
+	isc->dev = dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	io_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(io_base))
+		return PTR_ERR(io_base);
+
+	isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
+	if (IS_ERR(isc->regmap)) {
+		ret = PTR_ERR(isc->regmap);
+		dev_err(dev, "failed to init register map: %d\n", ret);
+		return ret;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
+			       "microchip-sama7g5-xisc", isc);
+	if (ret < 0) {
+		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
+			irq, ret);
+		return ret;
+	}
+
+	isc->gamma_table = isc_sama7g5_gamma_table;
+	isc->gamma_max = 0;
+
+	isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
+
+	isc->config_dpc = isc_sama7g5_config_dpc;
+	isc->config_csc = isc_sama7g5_config_csc;
+	isc->config_cbc = isc_sama7g5_config_cbc;
+	isc->config_cc = isc_sama7g5_config_cc;
+	isc->config_gam = isc_sama7g5_config_gam;
+	isc->config_rlp = isc_sama7g5_config_rlp;
+	isc->config_ctrls = isc_sama7g5_config_ctrls;
+
+	isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
+
+	isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
+
+	isc->controller_formats = sama7g5_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
+	isc->formats_list = sama7g5_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
+
+	/* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
+
+	ret = isc_pipeline_init(isc);
+	if (ret)
+		return ret;
+
+	isc->hclock = devm_clk_get(dev, "hclock");
+	if (IS_ERR(isc->hclock)) {
+		ret = PTR_ERR(isc->hclock);
+		dev_err(dev, "failed to get hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret) {
+		dev_err(dev, "failed to enable hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = isc_clk_init(isc);
+	if (ret) {
+		dev_err(dev, "failed to init isc clock: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret) {
+		dev_err(dev, "failed to enable ispck: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	/* ispck should be greater or equal to hclock */
+	ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
+	if (ret) {
+		dev_err(dev, "failed to set ispck rate: %d\n", ret);
+		goto unprepare_clk;
+	}
+
+	ret = v4l2_device_register(dev, &isc->v4l2_dev);
+	if (ret) {
+		dev_err(dev, "unable to register v4l2 device.\n");
+		goto unprepare_clk;
+	}
+
+	ret = xisc_parse_dt(dev, isc);
+	if (ret) {
+		dev_err(dev, "fail to parse device tree\n");
+		goto unregister_v4l2_device;
+	}
+
+	if (list_empty(&isc->subdev_entities)) {
+		dev_err(dev, "no subdev found\n");
+		ret = -ENODEV;
+		goto unregister_v4l2_device;
+	}
+
+	list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
+		v4l2_async_notifier_init(&subdev_entity->notifier);
+
+		ret = v4l2_async_notifier_add_subdev(&subdev_entity->notifier,
+						     subdev_entity->asd);
+		if (ret) {
+			fwnode_handle_put(subdev_entity->asd->match.fwnode);
+			goto cleanup_subdev;
+		}
+
+		subdev_entity->notifier.ops = &isc_async_ops;
+
+		ret = v4l2_async_notifier_register(&isc->v4l2_dev,
+						   &subdev_entity->notifier);
+		if (ret) {
+			dev_err(dev, "fail to register async notifier\n");
+			goto cleanup_subdev;
+		}
+
+		if (video_is_registered(&isc->video_dev))
+			break;
+	}
+
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+	pm_request_idle(dev);
+
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip XISC version %x\n", ver);
+
+	return 0;
+
+cleanup_subdev:
+	isc_subdev_cleanup(isc);
+
+unregister_v4l2_device:
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+unprepare_clk:
+	clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return ret;
+}
+
+static int microchip_xisc_remove(struct platform_device *pdev)
+{
+	struct isc_device *isc = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	isc_subdev_cleanup(isc);
+
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_suspend(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_resume(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret)
+		clk_disable_unprepare(isc->hclock);
+
+	return ret;
+}
+
+static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
+};
+
+static const struct of_device_id microchip_xisc_of_match[] = {
+	{ .compatible = "microchip,sama7g5-isc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
+
+static struct platform_driver microchip_xisc_driver = {
+	.probe	= microchip_xisc_probe,
+	.remove	= microchip_xisc_remove,
+	.driver	= {
+		.name		= "microchip-sama7g5-xisc",
+		.pm		= &microchip_xisc_dev_pm_ops,
+		.of_match_table = of_match_ptr(microchip_xisc_of_match),
+	},
+};
+
+module_platform_driver(microchip_xisc_driver);
+
+MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
+MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
+MODULE_LICENSE("GPL v2");
+MODULE_SUPPORTED_DEVICE("video");
-- 
2.25.1



From michal.simek at xilinx.com  Thu Apr  1 12:42:20 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 1 Apr 2021 13:42:20 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
Message-ID: <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>

Hi Jan,

On 3/27/21 8:55 PM, Jan Kiszka wrote:
> On 07.11.19 10:44, Rajan Vaja wrote:
>> Add clock nodes for zynqmp based on CCF.
>>
>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>> ---
>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>> new file mode 100644
>> index 0000000..9868ca1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>> @@ -0,0 +1,222 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Clock specification for Xilinx ZynqMP
>> + *
>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>> + *
>> + * Michal Simek <michal.simek at xilinx.com>
>> + */
>> +
>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>> +/ {
>> +	pss_ref_clk: pss_ref_clk {
>> +		u-boot,dm-pre-reloc;
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <33333333>;
>> +	};
>> +
>> +	video_clk: video_clk {
>> +		u-boot,dm-pre-reloc;
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <27000000>;
>> +	};
>> +
>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>> +		u-boot,dm-pre-reloc;
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <0>;
>> +	};
>> +
>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>> +		u-boot,dm-pre-reloc;
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <108000000>;
>> +	};
>> +
>> +	aux_ref_clk: aux_ref_clk {
>> +		u-boot,dm-pre-reloc;
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <27000000>;
>> +	};
>> +};
>> +
>> +&can0 {
>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&can1 {
>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&cpu0 {
>> +	clocks = <&zynqmp_clk ACPU>;
>> +};
>> +
>> +&fpd_dma_chan1 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan2 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan3 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan4 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan5 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan6 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan7 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&fpd_dma_chan8 {
>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan1 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan2 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan3 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan4 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan5 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan6 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan7 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&lpd_dma_chan8 {
>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&gem0 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>> +		 <&zynqmp_clk GEM_TSU>;
>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>> +};
>> +
>> +&gem1 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>> +		 <&zynqmp_clk GEM_TSU>;
>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>> +};
>> +
>> +&gem2 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>> +		 <&zynqmp_clk GEM_TSU>;
>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>> +};
>> +
>> +&gem3 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>> +		 <&zynqmp_clk GEM_TSU>;
>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>> +};
>> +
>> +&gpio {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&i2c0 {
>> +	clocks = <&zynqmp_clk I2C0_REF>;
>> +};
>> +
>> +&i2c1 {
>> +	clocks = <&zynqmp_clk I2C1_REF>;
>> +};
>> +
>> +&pcie {
>> +	clocks = <&zynqmp_clk PCIE_REF>;
>> +};
>> +
>> +&sata {
>> +	clocks = <&zynqmp_clk SATA_REF>;
>> +};
>> +
>> +&sdhci0 {
>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&sdhci1 {
>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&spi0 {
>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&spi1 {
>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&ttc0 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&ttc1 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&ttc2 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&ttc3 {
>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&uart0 {
>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&uart1 {
>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>> +};
>> +
>> +&usb0 {
>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>> +};
>> +
>> +&usb1 {
>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>> +};
>> +
>> +&watchdog0 {
>> +	clocks = <&zynqmp_clk WDT>;
>> +};
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>> index 0f7b4cf..2e05fa4 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZC1232
>>   *
>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>
>>  / {
>>  	model = "ZynqMP ZC1232 RevA";
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>> index 9092828..3d0aaa0 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZC1254
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>> @@ -11,7 +11,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>
>>  / {
>>  	model = "ZynqMP ZC1254 RevA";
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>> index 4f404c5..1a8127d4 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>> @@ -11,7 +11,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>
>>  / {
>>  	model = "ZynqMP ZC1275 RevA";
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>> index 9a3e39d..fa7eb1b 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/gpio/gpio.h>
>>
>>  / {
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>> index 2421ec7..4191dfa 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/gpio/gpio.h>
>>
>>  / {
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>> index 7a49dee..3750690 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>   *
>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>
>>  / {
>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>> index 54c7b4f..2366cd9 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>
>>  / {
>>  	model = "ZynqMP zc1751-xm018-dc4";
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>> index b8b5ff1..9a894e6 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>   * Michal Simek <michal.simek at xilinx.com>
>> @@ -11,7 +11,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/gpio/gpio.h>
>>
>>  / {
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> index e5699d0..3e39454 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>   *
>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   * Nathalie Chan King Choy
>> @@ -11,7 +11,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/input/input.h>
>>  #include <dt-bindings/interrupt-controller/irq.h>
>>  #include <dt-bindings/gpio/gpio.h>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>> index 2a3b665..f6e9558 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>   *
>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/input/input.h>
>>  #include <dt-bindings/gpio/gpio.h>
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>> index 8f45614..f457f8a 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZCU104
>>   *
>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/gpio/gpio.h>
>>
>>  / {
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>> index 93ce7eb..f15b99a 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZCU106
>>   *
>> - * (C) Copyright 2016, Xilinx, Inc.
>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/input/input.h>
>>  #include <dt-bindings/gpio/gpio.h>
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>> index 8bb0001..e27cd60 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP ZCU111
>>   *
>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   */
>> @@ -10,7 +10,7 @@
>>  /dts-v1/;
>>
>>  #include "zynqmp.dtsi"
>> -#include "zynqmp-clk.dtsi"
>> +#include "zynqmp-clk-ccf.dtsi"
>>  #include <dt-bindings/input/input.h>
>>  #include <dt-bindings/gpio/gpio.h>
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> index 9aa6734..59a547b 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>> @@ -2,7 +2,7 @@
>>  /*
>>   * dts file for Xilinx ZynqMP
>>   *
>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>   *
>>   * Michal Simek <michal.simek at xilinx.com>
>>   *
>> @@ -124,6 +124,28 @@
>>  			     <1 10 0xf08>;
>>  	};
>>
>> +	firmware {
>> +		zynqmp_firmware: zynqmp-firmware {
>> +			compatible = "xlnx,zynqmp-firmware";
>> +			method = "smc";
>> +			zynqmp_clk: clock-controller {
>> +				u-boot,dm-pre-reloc;
>> +				#clock-cells = <1>;
>> +				compatible = "xlnx,zynqmp-clk";
>> +				clocks = <&pss_ref_clk>,
>> +					 <&video_clk>,
>> +					 <&pss_alt_ref_clk>,
>> +					 <&aux_ref_clk>,
>> +					 <&gt_crx_ref_clk>;
>> +				clock-names = "pss_ref_clk",
>> +					      "video_clk",
>> +					      "pss_alt_ref_clk",
>> +					      "aux_ref_clk",
>> +					      "gt_crx_ref_clk";
>> +			};
>> +		};
>> +	};
>> +
>>  	amba_apu: amba-apu at 0 {
>>  		compatible = "simple-bus";
>>  		#address-cells = <2>;
>>
> 
> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
> Starting from this commit on, I'm no longer getting the kernel to boot
> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
> DTBs back before this commit, even a kernel from today's head is fine.
> 
> Further versions of potential relevance:
>  - PMUFW 2019.1 and 2020.2
>  - TF-A 2.3
>  - U-Boot 2020.10
> 
> What's missing? I suspect someone forgot to document a subtle dependency
> of this change.

Does this fix your issue?
https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/

Thanks,
Michal



From robert.foss at linaro.org  Thu Apr  1 12:44:15 2021
From: robert.foss at linaro.org (Robert Foss)
Date: Thu, 1 Apr 2021 13:44:15 +0200
Subject: [PATCH -next] media: camss: csiphy: Remove redundant dev_err call
 in msm_csiphy_subdev_init()
In-Reply-To: <20210401103500.1558058-1-yangyingliang@huawei.com>
References: <20210401103500.1558058-1-yangyingliang@huawei.com>
Message-ID: <CAG3jFyupb==xBb19wdv=TKheKuS_TEojhsvzmAATJsh1VUrdzg@mail.gmail.com>

Hey Yang,

Thanks for the patch, feel free to add my r-b.

Reviewed-by: Robert Foss <robert.foss at linaro.org>

On Thu, 1 Apr 2021 at 12:33, Yang Yingliang <yangyingliang at huawei.com> wrote:
>
> There is an error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Yang Yingliang <yangyingliang at huawei.com>
> ---
>  drivers/media/platform/qcom/camss/camss-csiphy.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
> index 6ceb6d7d53d1..b3c3bf19e522 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
> @@ -593,20 +593,16 @@ int msm_csiphy_subdev_init(struct camss *camss,
>
>         r = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[0]);
>         csiphy->base = devm_ioremap_resource(dev, r);
> -       if (IS_ERR(csiphy->base)) {
> -               dev_err(dev, "could not map memory\n");
> +       if (IS_ERR(csiphy->base))
>                 return PTR_ERR(csiphy->base);
> -       }
>
>         if (camss->version == CAMSS_8x16 ||
>             camss->version == CAMSS_8x96) {
>                 r = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>                                                  res->reg[1]);
>                 csiphy->base_clk_mux = devm_ioremap_resource(dev, r);
> -               if (IS_ERR(csiphy->base_clk_mux)) {
> -                       dev_err(dev, "could not map memory\n");
> +               if (IS_ERR(csiphy->base_clk_mux))
>                         return PTR_ERR(csiphy->base_clk_mux);
> -               }
>         } else {
>                 csiphy->base_clk_mux = NULL;
>         }
> --
> 2.25.1
>


From maz at kernel.org  Thu Apr  1 13:07:18 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 13:07:18 +0100
Subject: [PATCH v3 00/14] PCI/MSI: Getting rid of msi_controller,
 and other cleanups
In-Reply-To: <161727636757.32506.11592578621890085687.b4-ty@arm.com>
References: <20210330151145.997953-1-maz@kernel.org>
 <161727636757.32506.11592578621890085687.b4-ty@arm.com>
Message-ID: <87v996p5s9.wl-maz@kernel.org>

On Thu, 01 Apr 2021 12:27:42 +0100,
Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
> 
> On Tue, 30 Mar 2021 16:11:31 +0100, Marc Zyngier wrote:
> > This is a respin of the series described at [1].
> > 
> > * From v2 [2]:
> >   - Fixed the Xilinx driver, thanks to Bharat for testing it
> >   - Dropped the no_msi attribute, and solely rely on msi_domain, which
> >     has the same effect for the only platform that was using it.
> >   - Fixed compilation on architectures that do not select the generic
> >     MSI support
> > 
> > [...]
> 
> I have applied it to pci/msi and should be moved into -next shortly
> for further testing/visibility, thanks a lot for putting it together.

Thanks Lorenzo.

	M.

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


From mchehab+huawei at kernel.org  Thu Apr  1 13:17:20 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Thu,  1 Apr 2021 14:17:20 +0200
Subject: [PATCH 00/32] Fix broken documentation file references
Message-ID: <cover.1617279355.git.mchehab+huawei@kernel.org>

Each patch on this series can be applied independently. They fix broken
file references.

Most of them are due to DT binding renames, but there are also other
unrelated changes.

This series is based on next-20210401.

Mauro Carvalho Chehab (32):
  MAINTAINERS: update adi,ad5758.yaml reference
  MAINTAINERS: update ste,mcde.yaml reference
  MAINTAINERS: update brcm,bcm-v3d.yaml reference
  MAINTAINERS: update fsl,dpaa2-console.yaml reference
  MAINTAINERS: update st,hts221.yaml reference
  MAINTAINERS: update dpot-dac.yaml reference
  MAINTAINERS: update envelope-detector.yaml reference
  MAINTAINERS: update current-sense-amplifier.yaml reference
  MAINTAINERS: update current-sense-shunt.yaml reference
  MAINTAINERS: update voltage-divider.yaml reference
  MAINTAINERS: update invensense,mpu3050.yaml reference
  MAINTAINERS: update lego,ev3-battery.yaml reference
  MAINTAINERS: update marvell,armada-3700-utmi-phy.yaml reference
  MAINTAINERS: update mtk-sd.yaml reference
  MAINTAINERS: update atmel,sama5d2-adc.yaml reference
  MAINTAINERS: update pni,rm3100.yaml reference
  MAINTAINERS: update renesas,rcar-gyroadc.yaml reference
  MAINTAINERS: update st,lsm6dsx.yaml reference
  MAINTAINERS: update st,vl53l0x.yaml reference
  MAINTAINERS: update snps,dw-axi-dmac.yaml reference
  MAINTAINERS: update ti,dac7612.yaml reference
  MAINTAINERS: update nxp,imx8-jpeg.yaml reference
  MAINTAINERS: update ovti,ov2680.yaml reference
  MAINTAINERS: update imi,rdacm2x-gmsl.yaml reference
  dt-bindings:iio:dac: update microchip,mcp4725.yaml reference
  dt-bindings: iommu: mediatek: update mediatek,iommu.yaml references
  dt-bindings: i3c: update i3c.yaml references
  dt-bindings: power: update battery.yaml reference
  docs: dt: update writing-schema.rst references
  Documentation: net: dsa: update configuration.rst reference
  Documentation: update sysfs-platform_profile.rst reference
  pinctrl: update pin-control.rst references

 .../display/mediatek/mediatek,disp.txt        |  2 +-
 .../bindings/i3c/cdns,i3c-master.txt          |  6 +--
 .../bindings/i3c/snps,dw-i3c-master.txt       |  6 +--
 .../bindings/media/mediatek-jpeg-decoder.txt  |  2 +-
 .../bindings/media/mediatek-jpeg-encoder.txt  |  2 +-
 .../bindings/media/mediatek-mdp.txt           |  2 +-
 .../bindings/media/mediatek-vcodec.txt        |  2 +-
 .../bindings/submitting-patches.rst           |  2 +-
 Documentation/filesystems/cifs/cifsd.rst      |  2 +-
 Documentation/power/power_supply_class.rst    |  2 +-
 MAINTAINERS                                   | 48 +++++++++----------
 include/linux/device.h                        |  2 +-
 include/linux/iio/dac/mcp4725.h               |  2 +-
 include/linux/mfd/madera/pdata.h              |  2 +-
 include/linux/pinctrl/pinconf-generic.h       |  2 +-
 include/linux/platform_profile.h              |  2 +-
 scripts/checkpatch.pl                         |  2 +-
 17 files changed, 44 insertions(+), 44 deletions(-)

-- 
2.30.2




From mchehab+huawei at kernel.org  Thu Apr  1 13:17:46 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Thu,  1 Apr 2021 14:17:46 +0200
Subject: [PATCH 26/32] dt-bindings: iommu: mediatek: update mediatek,
 iommu.yaml references
In-Reply-To: <cover.1617279355.git.mchehab+huawei@kernel.org>
References: <cover.1617279355.git.mchehab+huawei@kernel.org>
Message-ID: <f1a798e2d5ffa829d0324333a1af91f1b3a63dad.1617279356.git.mchehab+huawei@kernel.org>

Changeset bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
renamed: Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
to: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml.

Update the cross-references accordingly.

Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,disp.txt      | 2 +-
 .../devicetree/bindings/media/mediatek-jpeg-decoder.txt         | 2 +-
 .../devicetree/bindings/media/mediatek-jpeg-encoder.txt         | 2 +-
 Documentation/devicetree/bindings/media/mediatek-mdp.txt        | 2 +-
 Documentation/devicetree/bindings/media/mediatek-vcodec.txt     | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 93b160df3eec..fbb59c9ddda6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -64,7 +64,7 @@ Required properties (DMA function blocks):
 - larb: Should contain a phandle pointing to the local arbiter device as defined
   in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
 - iommus: Should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Optional properties (RDMA function blocks):
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index cf60c5acc0e4..39c1028b2dfb 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -19,7 +19,7 @@ Required properties:
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
   for details.
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
index acfb50375b8a..5e53c6ab52d0 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -17,7 +17,7 @@ Required properties:
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
   for details.
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index f4798d04e925..caa24943da33 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -25,7 +25,7 @@ Required properties (DMA function blocks, child node):
         "mediatek,mt8173-mdp-wdma"
         "mediatek,mt8173-mdp-wrot"
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 - mediatek,larb: must contain the local arbiters in the current Socs, see
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8217424fd4bd..a83ebc1a1c7f 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -18,7 +18,7 @@ Required properties:
   "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
   "venc_lt_sel", "vdec_bus_clk_src".
 - iommus : should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 One of the two following nodes:
 - mediatek,vpu : the node of the video processor unit, if using VPU.
-- 
2.30.2



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:20 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:20 +0300
Subject: [PATCH v2 0/6] clk: at91: updates for power management and dvfs
Message-ID: <20210401122726.28528-1-claudiu.beznea@microchip.com>

Hi,

This series addresses the power management for SAMA7G5 and also updates
the master clock prescaller and master clock divider drivers to accommodate
the requests at [1].

The power management part is implemented by adding
save_context()/restore_context() on each clock driver (patch 1/6). Since
the PM part is necessary only for backup mode (supported on SAMA5D2 and
SAMA7G5) the pmc.c has been adapted to call the
save_context()/restore_context() only on switches to/from backup mode
(patch 2/6).

Patch 3/6 adds the securam clock on SAMA7G5. This is necessary for
backup mode of SAMA7G5.

Patch 4/6 adds registers definitions for the new master clocks (MCK1..4) of
SAMA7G5 and adapt the clk-master.c. The defines exported in
include/linux/clk/at91_pmc.h will be also used by platform specific PM
code.

Patch 5/6 adpat the master clock divider and master clock prescaller
to address the requests at [1].

Patch 6/6 clean up a bit the code in clk-master as suggested by Nicolas.

Thank you,
Claudiu Beznea

[1] https://lore.kernel.org/lkml/20210105104426.4tmgc2l3vyicwedd at vireshk-i7/

Changes in v2:
- addressed code review comments
- collected tags

Claudiu Beznea (6):
  clk: at91: re-factor clocks suspend/resume
  clk: at91: pmc: execute suspend/resume only for backup mode
  clk: at91: sama7g5: add securam's peripheral clock
  clk: at91: clk-master: add register definition for sama7g5's master
    clock
  clk: at91: clk-master: update for dvfs
  clk: at91: clk-master: improve readability by using local variables

 drivers/clk/at91/at91rm9200.c       |   2 +-
 drivers/clk/at91/at91sam9260.c      |   2 +-
 drivers/clk/at91/at91sam9g45.c      |   2 +-
 drivers/clk/at91/at91sam9n12.c      |   2 +-
 drivers/clk/at91/at91sam9rl.c       |   2 +-
 drivers/clk/at91/at91sam9x5.c       |   2 +-
 drivers/clk/at91/clk-generated.c    |  46 +++-
 drivers/clk/at91/clk-main.c         |  66 +++++
 drivers/clk/at91/clk-master.c       | 396 +++++++++++++++++++++-------
 drivers/clk/at91/clk-peripheral.c   |  40 ++-
 drivers/clk/at91/clk-pll.c          |  37 +++
 drivers/clk/at91/clk-programmable.c |  29 +-
 drivers/clk/at91/clk-sam9x60-pll.c  |  68 ++++-
 drivers/clk/at91/clk-system.c       |  20 ++
 drivers/clk/at91/clk-usb.c          |  27 ++
 drivers/clk/at91/clk-utmi.c         |  47 +++-
 drivers/clk/at91/dt-compat.c        |   2 +-
 drivers/clk/at91/pmc.c              | 175 +++---------
 drivers/clk/at91/pmc.h              |  27 +-
 drivers/clk/at91/sam9x60.c          |   2 +-
 drivers/clk/at91/sama5d2.c          |   2 +-
 drivers/clk/at91/sama5d3.c          |   2 +-
 drivers/clk/at91/sama5d4.c          |   2 +-
 drivers/clk/at91/sama7g5.c          |   3 +-
 include/linux/clk/at91_pmc.h        |  26 ++
 25 files changed, 752 insertions(+), 277 deletions(-)

-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:21 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:21 +0300
Subject: [PATCH v2 1/6] clk: at91: re-factor clocks suspend/resume
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-2-claudiu.beznea@microchip.com>

SAMA5D2 and SAMA7G5 have a special power saving mode (backup mode) where
most of the SoC's components are powered off (including PMC). Resuming
from this mode is done with the help of bootloader. Peripherals are not
aware of the power saving mode thus most of them are disabling clocks in
proper suspend API and re-enable them in resume API without taking into
account the previously setup rate. Moreover some of the peripherals are
acting as wakeup sources and are not disabling the clocks in this
scenario, when suspending. Since backup mode cuts the power for
peripherals, in resume part these clocks needs to be re-configured.

The initial PMC suspend/resume code was designed with SAMA5D2's PMC
in mind. SAMA7G's PMC is different (few new functionalities, different
registers offsets, different offsets in registers for each
functionalities). To address both SAMA5D2 and SAMA7G5 PMC add
.save_context()/.resume_context() support to each clocks driver and call
this from PMC driver.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 drivers/clk/at91/clk-generated.c    |  46 +++++--
 drivers/clk/at91/clk-main.c         |  66 ++++++++++
 drivers/clk/at91/clk-master.c       | 183 ++++++++++++++++++++++++++--
 drivers/clk/at91/clk-peripheral.c   |  40 +++++-
 drivers/clk/at91/clk-pll.c          |  37 ++++++
 drivers/clk/at91/clk-programmable.c |  29 ++++-
 drivers/clk/at91/clk-sam9x60-pll.c  |  68 ++++++++++-
 drivers/clk/at91/clk-system.c       |  20 +++
 drivers/clk/at91/clk-usb.c          |  27 ++++
 drivers/clk/at91/clk-utmi.c         |  47 ++++++-
 drivers/clk/at91/pmc.c              | 149 ++--------------------
 drivers/clk/at91/pmc.h              |  24 ++--
 12 files changed, 556 insertions(+), 180 deletions(-)

diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index b4fc8d71daf2..a3ff46e251c5 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -27,6 +27,7 @@ struct clk_generated {
 	u32 id;
 	u32 gckdiv;
 	const struct clk_pcr_layout *layout;
+	struct at91_clk_pms pms;
 	u8 parent_id;
 	int chg_pid;
 };
@@ -34,25 +35,35 @@ struct clk_generated {
 #define to_clk_generated(hw) \
 	container_of(hw, struct clk_generated, hw)
 
-static int clk_generated_enable(struct clk_hw *hw)
+static int clk_generated_set(struct clk_generated *gck, int status)
 {
-	struct clk_generated *gck = to_clk_generated(hw);
 	unsigned long flags;
-
-	pr_debug("GCLK: %s, gckdiv = %d, parent id = %d\n",
-		 __func__, gck->gckdiv, gck->parent_id);
+	unsigned int enable = status ? AT91_PMC_PCR_GCKEN : 0;
 
 	spin_lock_irqsave(gck->lock, flags);
 	regmap_write(gck->regmap, gck->layout->offset,
 		     (gck->id & gck->layout->pid_mask));
 	regmap_update_bits(gck->regmap, gck->layout->offset,
 			   AT91_PMC_PCR_GCKDIV_MASK | gck->layout->gckcss_mask |
-			   gck->layout->cmd | AT91_PMC_PCR_GCKEN,
+			   gck->layout->cmd | enable,
 			   field_prep(gck->layout->gckcss_mask, gck->parent_id) |
 			   gck->layout->cmd |
 			   FIELD_PREP(AT91_PMC_PCR_GCKDIV_MASK, gck->gckdiv) |
-			   AT91_PMC_PCR_GCKEN);
+			   enable);
 	spin_unlock_irqrestore(gck->lock, flags);
+
+	return 0;
+}
+
+static int clk_generated_enable(struct clk_hw *hw)
+{
+	struct clk_generated *gck = to_clk_generated(hw);
+
+	pr_debug("GCLK: %s, gckdiv = %d, parent id = %d\n",
+		 __func__, gck->gckdiv, gck->parent_id);
+
+	clk_generated_set(gck, 1);
+
 	return 0;
 }
 
@@ -239,6 +250,23 @@ static int clk_generated_set_rate(struct clk_hw *hw,
 	return 0;
 }
 
+static int clk_generated_save_context(struct clk_hw *hw)
+{
+	struct clk_generated *gck = to_clk_generated(hw);
+
+	gck->pms.status = clk_generated_is_enabled(&gck->hw);
+
+	return 0;
+}
+
+static void clk_generated_restore_context(struct clk_hw *hw)
+{
+	struct clk_generated *gck = to_clk_generated(hw);
+
+	if (gck->pms.status)
+		clk_generated_set(gck, gck->pms.status);
+}
+
 static const struct clk_ops generated_ops = {
 	.enable = clk_generated_enable,
 	.disable = clk_generated_disable,
@@ -248,6 +276,8 @@ static const struct clk_ops generated_ops = {
 	.get_parent = clk_generated_get_parent,
 	.set_parent = clk_generated_set_parent,
 	.set_rate = clk_generated_set_rate,
+	.save_context = clk_generated_save_context,
+	.restore_context = clk_generated_restore_context,
 };
 
 /**
@@ -314,8 +344,6 @@ at91_clk_register_generated(struct regmap *regmap, spinlock_t *lock,
 	if (ret) {
 		kfree(gck);
 		hw = ERR_PTR(ret);
-	} else {
-		pmc_register_id(id);
 	}
 
 	return hw;
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index cfae2f59df66..8601b27c1ae0 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -28,6 +28,7 @@
 struct clk_main_osc {
 	struct clk_hw hw;
 	struct regmap *regmap;
+	struct at91_clk_pms pms;
 };
 
 #define to_clk_main_osc(hw) container_of(hw, struct clk_main_osc, hw)
@@ -37,6 +38,7 @@ struct clk_main_rc_osc {
 	struct regmap *regmap;
 	unsigned long frequency;
 	unsigned long accuracy;
+	struct at91_clk_pms pms;
 };
 
 #define to_clk_main_rc_osc(hw) container_of(hw, struct clk_main_rc_osc, hw)
@@ -51,6 +53,7 @@ struct clk_rm9200_main {
 struct clk_sam9x5_main {
 	struct clk_hw hw;
 	struct regmap *regmap;
+	struct at91_clk_pms pms;
 	u8 parent;
 };
 
@@ -120,10 +123,29 @@ static int clk_main_osc_is_prepared(struct clk_hw *hw)
 	return (status & AT91_PMC_MOSCS) && clk_main_parent_select(tmp);
 }
 
+static int clk_main_osc_save_context(struct clk_hw *hw)
+{
+	struct clk_main_osc *osc = to_clk_main_osc(hw);
+
+	osc->pms.status = clk_main_osc_is_prepared(hw);
+
+	return 0;
+}
+
+static void clk_main_osc_restore_context(struct clk_hw *hw)
+{
+	struct clk_main_osc *osc = to_clk_main_osc(hw);
+
+	if (osc->pms.status)
+		clk_main_osc_prepare(hw);
+}
+
 static const struct clk_ops main_osc_ops = {
 	.prepare = clk_main_osc_prepare,
 	.unprepare = clk_main_osc_unprepare,
 	.is_prepared = clk_main_osc_is_prepared,
+	.save_context = clk_main_osc_save_context,
+	.restore_context = clk_main_osc_restore_context,
 };
 
 struct clk_hw * __init
@@ -240,12 +262,31 @@ static unsigned long clk_main_rc_osc_recalc_accuracy(struct clk_hw *hw,
 	return osc->accuracy;
 }
 
+static int clk_main_rc_osc_save_context(struct clk_hw *hw)
+{
+	struct clk_main_rc_osc *osc = to_clk_main_rc_osc(hw);
+
+	osc->pms.status = clk_main_rc_osc_is_prepared(hw);
+
+	return 0;
+}
+
+static void clk_main_rc_osc_restore_context(struct clk_hw *hw)
+{
+	struct clk_main_rc_osc *osc = to_clk_main_rc_osc(hw);
+
+	if (osc->pms.status)
+		clk_main_rc_osc_prepare(hw);
+}
+
 static const struct clk_ops main_rc_osc_ops = {
 	.prepare = clk_main_rc_osc_prepare,
 	.unprepare = clk_main_rc_osc_unprepare,
 	.is_prepared = clk_main_rc_osc_is_prepared,
 	.recalc_rate = clk_main_rc_osc_recalc_rate,
 	.recalc_accuracy = clk_main_rc_osc_recalc_accuracy,
+	.save_context = clk_main_rc_osc_save_context,
+	.restore_context = clk_main_rc_osc_restore_context,
 };
 
 struct clk_hw * __init
@@ -465,12 +506,37 @@ static u8 clk_sam9x5_main_get_parent(struct clk_hw *hw)
 	return clk_main_parent_select(status);
 }
 
+static int clk_sam9x5_main_save_context(struct clk_hw *hw)
+{
+	struct clk_sam9x5_main *clkmain = to_clk_sam9x5_main(hw);
+
+	clkmain->pms.status = clk_main_rc_osc_is_prepared(&clkmain->hw);
+	clkmain->pms.parent = clk_sam9x5_main_get_parent(&clkmain->hw);
+
+	return 0;
+}
+
+static void clk_sam9x5_main_restore_context(struct clk_hw *hw)
+{
+	struct clk_sam9x5_main *clkmain = to_clk_sam9x5_main(hw);
+	int ret;
+
+	ret = clk_sam9x5_main_set_parent(hw, clkmain->pms.parent);
+	if (ret)
+		return;
+
+	if (clkmain->pms.status)
+		clk_sam9x5_main_prepare(hw);
+}
+
 static const struct clk_ops sam9x5_main_ops = {
 	.prepare = clk_sam9x5_main_prepare,
 	.is_prepared = clk_sam9x5_main_is_prepared,
 	.recalc_rate = clk_sam9x5_main_recalc_rate,
 	.set_parent = clk_sam9x5_main_set_parent,
 	.get_parent = clk_sam9x5_main_get_parent,
+	.save_context = clk_sam9x5_main_save_context,
+	.restore_context = clk_sam9x5_main_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index a80427980bf7..21e82111890d 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -37,6 +37,7 @@ struct clk_master {
 	spinlock_t *lock;
 	const struct clk_master_layout *layout;
 	const struct clk_master_characteristics *characteristics;
+	struct at91_clk_pms pms;
 	u32 *mux_table;
 	u32 mckr;
 	int chg_pid;
@@ -112,10 +113,52 @@ static unsigned long clk_master_div_recalc_rate(struct clk_hw *hw,
 	return rate;
 }
 
+static int clk_master_div_save_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+	struct clk_hw *parent_hw = clk_hw_get_parent(hw);
+	unsigned long flags;
+	unsigned int mckr, div;
+
+	spin_lock_irqsave(master->lock, flags);
+	regmap_read(master->regmap, master->layout->offset, &mckr);
+	spin_unlock_irqrestore(master->lock, flags);
+
+	mckr &= master->layout->mask;
+	div = (mckr >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
+	div = master->characteristics->divisors[div];
+
+	master->pms.parent_rate = clk_hw_get_rate(parent_hw);
+	master->pms.rate = DIV_ROUND_CLOSEST(master->pms.parent_rate, div);
+
+	return 0;
+}
+
+static void clk_master_div_restore_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+	unsigned long flags;
+	unsigned int mckr;
+	u8 div;
+
+	spin_lock_irqsave(master->lock, flags);
+	regmap_read(master->regmap, master->layout->offset, &mckr);
+	spin_unlock_irqrestore(master->lock, flags);
+
+	mckr &= master->layout->mask;
+	div = (mckr >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
+	div = master->characteristics->divisors[div];
+
+	if (div != DIV_ROUND_CLOSEST(master->pms.parent_rate, master->pms.rate))
+		pr_warn("MCKR DIV not configured properly by firmware!\n");
+}
+
 static const struct clk_ops master_div_ops = {
 	.prepare = clk_master_prepare,
 	.is_prepared = clk_master_is_prepared,
 	.recalc_rate = clk_master_div_recalc_rate,
+	.save_context = clk_master_div_save_context,
+	.restore_context = clk_master_div_restore_context,
 };
 
 static int clk_master_div_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -125,7 +168,9 @@ static int clk_master_div_set_rate(struct clk_hw *hw, unsigned long rate,
 	const struct clk_master_characteristics *characteristics =
 						master->characteristics;
 	unsigned long flags;
+	unsigned int mckr, tmp;
 	int div, i;
+	int ret;
 
 	div = DIV_ROUND_CLOSEST(parent_rate, rate);
 	if (div > ARRAY_SIZE(characteristics->divisors))
@@ -145,11 +190,24 @@ static int clk_master_div_set_rate(struct clk_hw *hw, unsigned long rate,
 		return -EINVAL;
 
 	spin_lock_irqsave(master->lock, flags);
-	regmap_update_bits(master->regmap, master->layout->offset,
-			   (MASTER_DIV_MASK << MASTER_DIV_SHIFT),
-			   (div << MASTER_DIV_SHIFT));
+	ret = regmap_read(master->regmap, master->layout->offset, &mckr);
+	if (ret)
+		goto unlock;
+
+	tmp = mckr & master->layout->mask;
+	tmp = (tmp >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
+	if (tmp == div)
+		goto unlock;
+
+	mckr &= ~(MASTER_DIV_MASK << MASTER_DIV_SHIFT);
+	mckr |= (div << MASTER_DIV_SHIFT);
+	ret = regmap_write(master->regmap, master->layout->offset, mckr);
+	if (ret)
+		goto unlock;
+
 	while (!clk_master_ready(master))
 		cpu_relax();
+unlock:
 	spin_unlock_irqrestore(master->lock, flags);
 
 	return 0;
@@ -197,12 +255,25 @@ static int clk_master_div_determine_rate(struct clk_hw *hw,
 	return 0;
 }
 
+static void clk_master_div_restore_context_chg(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+	int ret;
+
+	ret = clk_master_div_set_rate(hw, master->pms.rate,
+				      master->pms.parent_rate);
+	if (ret)
+		pr_warn("Failed to restore MCK DIV clock\n");
+}
+
 static const struct clk_ops master_div_ops_chg = {
 	.prepare = clk_master_prepare,
 	.is_prepared = clk_master_is_prepared,
 	.recalc_rate = clk_master_div_recalc_rate,
 	.determine_rate = clk_master_div_determine_rate,
 	.set_rate = clk_master_div_set_rate,
+	.save_context = clk_master_div_save_context,
+	.restore_context = clk_master_div_restore_context_chg,
 };
 
 static void clk_sama7g5_master_best_diff(struct clk_rate_request *req,
@@ -272,7 +343,8 @@ static int clk_master_pres_set_rate(struct clk_hw *hw, unsigned long rate,
 {
 	struct clk_master *master = to_clk_master(hw);
 	unsigned long flags;
-	unsigned int pres;
+	unsigned int pres, val;
+	int ret;
 
 	pres = DIV_ROUND_CLOSEST(parent_rate, rate);
 	if (pres > MASTER_PRES_MAX)
@@ -284,15 +356,24 @@ static int clk_master_pres_set_rate(struct clk_hw *hw, unsigned long rate,
 		pres = ffs(pres) - 1;
 
 	spin_lock_irqsave(master->lock, flags);
+	ret = regmap_read(master->regmap, master->layout->offset, &val);
+	if (ret)
+		goto unlock;
+
+	val = (val >> master->layout->pres_shift) & MASTER_PRES_MASK;
+	if (pres == val)
+		goto unlock;
+
 	regmap_update_bits(master->regmap, master->layout->offset,
 			   (MASTER_PRES_MASK << master->layout->pres_shift),
 			   (pres << master->layout->pres_shift));
 
 	while (!clk_master_ready(master))
 		cpu_relax();
+unlock:
 	spin_unlock_irqrestore(master->lock, flags);
 
-	return 0;
+	return ret;
 }
 
 static unsigned long clk_master_pres_recalc_rate(struct clk_hw *hw,
@@ -330,11 +411,66 @@ static u8 clk_master_pres_get_parent(struct clk_hw *hw)
 	return mckr & AT91_PMC_CSS;
 }
 
+static int clk_master_pres_save_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+	struct clk_hw *parent_hw = clk_hw_get_parent(hw);
+	unsigned long flags;
+	unsigned int val, pres;
+
+	spin_lock_irqsave(master->lock, flags);
+	regmap_read(master->regmap, master->layout->offset, &val);
+	spin_unlock_irqrestore(master->lock, flags);
+
+	pres = (val >> master->layout->pres_shift) & MASTER_PRES_MASK;
+	if (pres == 3 && master->characteristics->have_div3_pres)
+		pres = 3;
+	else
+		pres = (1 << pres);
+
+	master->pms.parent = val & AT91_PMC_CSS;
+	master->pms.parent_rate = clk_hw_get_rate(parent_hw);
+	master->pms.rate = DIV_ROUND_CLOSEST_ULL(master->pms.parent_rate, pres);
+
+	return 0;
+}
+
+static void clk_master_pres_restore_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+	unsigned long flags;
+	unsigned int val, pres;
+
+	spin_lock_irqsave(master->lock, flags);
+	regmap_read(master->regmap, master->layout->offset, &val);
+	spin_unlock_irqrestore(master->lock, flags);
+
+	pres = (val >> master->layout->pres_shift) & MASTER_PRES_MASK;
+	if (pres == 3 && master->characteristics->have_div3_pres)
+		pres = 3;
+	else
+		pres = (1 << pres);
+
+	if ((master->pms.rate !=
+	     DIV_ROUND_CLOSEST_ULL(master->pms.parent_rate, pres)) ||
+	    (master->pms.parent != (val & AT91_PMC_CSS)))
+		pr_warn("MCKR PRES was not configured properly by firmware!\n");
+}
+
+static void clk_master_pres_restore_context_chg(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+
+	clk_master_pres_set_rate(hw, master->pms.rate, master->pms.parent_rate);
+}
+
 static const struct clk_ops master_pres_ops = {
 	.prepare = clk_master_prepare,
 	.is_prepared = clk_master_is_prepared,
 	.recalc_rate = clk_master_pres_recalc_rate,
 	.get_parent = clk_master_pres_get_parent,
+	.save_context = clk_master_pres_save_context,
+	.restore_context = clk_master_pres_restore_context,
 };
 
 static const struct clk_ops master_pres_ops_chg = {
@@ -344,6 +480,8 @@ static const struct clk_ops master_pres_ops_chg = {
 	.recalc_rate = clk_master_pres_recalc_rate,
 	.get_parent = clk_master_pres_get_parent,
 	.set_rate = clk_master_pres_set_rate,
+	.save_context = clk_master_pres_save_context,
+	.restore_context = clk_master_pres_restore_context_chg,
 };
 
 static struct clk_hw * __init
@@ -539,20 +677,21 @@ static int clk_sama7g5_master_set_parent(struct clk_hw *hw, u8 index)
 	return 0;
 }
 
-static int clk_sama7g5_master_enable(struct clk_hw *hw)
+static void clk_sama7g5_master_set(struct clk_master *master,
+				   unsigned int status)
 {
-	struct clk_master *master = to_clk_master(hw);
 	unsigned long flags;
 	unsigned int val, cparent;
+	unsigned int enable = status ? PMC_MCR_EN : 0;
 
 	spin_lock_irqsave(master->lock, flags);
 
 	regmap_write(master->regmap, PMC_MCR, PMC_MCR_ID(master->id));
 	regmap_read(master->regmap, PMC_MCR, &val);
 	regmap_update_bits(master->regmap, PMC_MCR,
-			   PMC_MCR_EN | PMC_MCR_CSS | PMC_MCR_DIV |
+			   enable | PMC_MCR_CSS | PMC_MCR_DIV |
 			   PMC_MCR_CMD | PMC_MCR_ID_MSK,
-			   PMC_MCR_EN | (master->parent << PMC_MCR_CSS_SHIFT) |
+			   enable | (master->parent << PMC_MCR_CSS_SHIFT) |
 			   (master->div << MASTER_DIV_SHIFT) |
 			   PMC_MCR_CMD | PMC_MCR_ID(master->id));
 
@@ -563,6 +702,13 @@ static int clk_sama7g5_master_enable(struct clk_hw *hw)
 		cpu_relax();
 
 	spin_unlock_irqrestore(master->lock, flags);
+}
+
+static int clk_sama7g5_master_enable(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+
+	clk_sama7g5_master_set(master, 1);
 
 	return 0;
 }
@@ -620,6 +766,23 @@ static int clk_sama7g5_master_set_rate(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
+static int clk_sama7g5_master_save_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+
+	master->pms.status = clk_sama7g5_master_is_enabled(hw);
+
+	return 0;
+}
+
+static void clk_sama7g5_master_restore_context(struct clk_hw *hw)
+{
+	struct clk_master *master = to_clk_master(hw);
+
+	if (master->pms.status)
+		clk_sama7g5_master_set(master, master->pms.status);
+}
+
 static const struct clk_ops sama7g5_master_ops = {
 	.enable = clk_sama7g5_master_enable,
 	.disable = clk_sama7g5_master_disable,
@@ -629,6 +792,8 @@ static const struct clk_ops sama7g5_master_ops = {
 	.set_rate = clk_sama7g5_master_set_rate,
 	.get_parent = clk_sama7g5_master_get_parent,
 	.set_parent = clk_sama7g5_master_set_parent,
+	.save_context = clk_sama7g5_master_save_context,
+	.restore_context = clk_sama7g5_master_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/clk-peripheral.c b/drivers/clk/at91/clk-peripheral.c
index 7a27ba8e0577..e14fa5ac734c 100644
--- a/drivers/clk/at91/clk-peripheral.c
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -37,6 +37,7 @@ struct clk_sam9x5_peripheral {
 	u32 id;
 	u32 div;
 	const struct clk_pcr_layout *layout;
+	struct at91_clk_pms pms;
 	bool auto_div;
 	int chg_pid;
 };
@@ -155,10 +156,11 @@ static void clk_sam9x5_peripheral_autodiv(struct clk_sam9x5_peripheral *periph)
 	periph->div = shift;
 }
 
-static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
+static int clk_sam9x5_peripheral_set(struct clk_sam9x5_peripheral *periph,
+				     unsigned int status)
 {
-	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
 	unsigned long flags;
+	unsigned int enable = status ? AT91_PMC_PCR_EN : 0;
 
 	if (periph->id < PERIPHERAL_ID_MIN)
 		return 0;
@@ -168,15 +170,21 @@ static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
 		     (periph->id & periph->layout->pid_mask));
 	regmap_update_bits(periph->regmap, periph->layout->offset,
 			   periph->layout->div_mask | periph->layout->cmd |
-			   AT91_PMC_PCR_EN,
+			   enable,
 			   field_prep(periph->layout->div_mask, periph->div) |
-			   periph->layout->cmd |
-			   AT91_PMC_PCR_EN);
+			   periph->layout->cmd | enable);
 	spin_unlock_irqrestore(periph->lock, flags);
 
 	return 0;
 }
 
+static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+
+	return clk_sam9x5_peripheral_set(periph, 1);
+}
+
 static void clk_sam9x5_peripheral_disable(struct clk_hw *hw)
 {
 	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
@@ -393,6 +401,23 @@ static int clk_sam9x5_peripheral_set_rate(struct clk_hw *hw,
 	return -EINVAL;
 }
 
+static int clk_sam9x5_peripheral_save_context(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+
+	periph->pms.status = clk_sam9x5_peripheral_is_enabled(hw);
+
+	return 0;
+}
+
+static void clk_sam9x5_peripheral_restore_context(struct clk_hw *hw)
+{
+	struct clk_sam9x5_peripheral *periph = to_clk_sam9x5_peripheral(hw);
+
+	if (periph->pms.status)
+		clk_sam9x5_peripheral_set(periph, periph->pms.status);
+}
+
 static const struct clk_ops sam9x5_peripheral_ops = {
 	.enable = clk_sam9x5_peripheral_enable,
 	.disable = clk_sam9x5_peripheral_disable,
@@ -400,6 +425,8 @@ static const struct clk_ops sam9x5_peripheral_ops = {
 	.recalc_rate = clk_sam9x5_peripheral_recalc_rate,
 	.round_rate = clk_sam9x5_peripheral_round_rate,
 	.set_rate = clk_sam9x5_peripheral_set_rate,
+	.save_context = clk_sam9x5_peripheral_save_context,
+	.restore_context = clk_sam9x5_peripheral_restore_context,
 };
 
 static const struct clk_ops sam9x5_peripheral_chg_ops = {
@@ -409,6 +436,8 @@ static const struct clk_ops sam9x5_peripheral_chg_ops = {
 	.recalc_rate = clk_sam9x5_peripheral_recalc_rate,
 	.determine_rate = clk_sam9x5_peripheral_determine_rate,
 	.set_rate = clk_sam9x5_peripheral_set_rate,
+	.save_context = clk_sam9x5_peripheral_save_context,
+	.restore_context = clk_sam9x5_peripheral_restore_context,
 };
 
 struct clk_hw * __init
@@ -460,7 +489,6 @@ at91_clk_register_sam9x5_peripheral(struct regmap *regmap, spinlock_t *lock,
 		hw = ERR_PTR(ret);
 	} else {
 		clk_sam9x5_peripheral_autodiv(periph);
-		pmc_register_id(id);
 	}
 
 	return hw;
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 6ed986d3eee0..31964622c658 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -40,6 +40,7 @@ struct clk_pll {
 	u16 mul;
 	const struct clk_pll_layout *layout;
 	const struct clk_pll_characteristics *characteristics;
+	struct at91_clk_pms pms;
 };
 
 static inline bool clk_pll_ready(struct regmap *regmap, int id)
@@ -260,6 +261,40 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
+static int clk_pll_save_context(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	struct clk_hw *parent_hw = clk_hw_get_parent(hw);
+
+	pll->pms.parent_rate = clk_hw_get_rate(parent_hw);
+	pll->pms.rate = clk_pll_recalc_rate(&pll->hw, pll->pms.parent_rate);
+	pll->pms.status = clk_pll_ready(pll->regmap, PLL_REG(pll->id));
+
+	return 0;
+}
+
+static void clk_pll_restore_context(struct clk_hw *hw)
+{
+	struct clk_pll *pll = to_clk_pll(hw);
+	unsigned long calc_rate;
+	unsigned int pllr;
+	u8 out = 0;
+
+	if (pll->characteristics->out)
+		out = pll->characteristics->out[pll->range];
+
+	regmap_read(pll->regmap, PLL_REG(pll->id), &pllr);
+
+	calc_rate = (pll->pms.parent_rate / PLL_DIV(pllr)) *
+		     (PLL_MUL(pllr, pll->layout) + 1);
+
+	if (pll->pms.rate != calc_rate ||
+	    pll->pms.status != clk_pll_ready(pll->regmap, PLL_REG(pll->id)) ||
+	    (((pllr >> PLL_COUNT_SHIFT) & PLL_MAX_COUNT) != PLL_MAX_COUNT) ||
+	    (out && ((pllr >> PLL_OUT_SHIFT) & out) != out))
+		pr_warn("PLLAR was not configured properly by firmware\n");
+}
+
 static const struct clk_ops pll_ops = {
 	.prepare = clk_pll_prepare,
 	.unprepare = clk_pll_unprepare,
@@ -267,6 +302,8 @@ static const struct clk_ops pll_ops = {
 	.recalc_rate = clk_pll_recalc_rate,
 	.round_rate = clk_pll_round_rate,
 	.set_rate = clk_pll_set_rate,
+	.save_context = clk_pll_save_context,
+	.restore_context = clk_pll_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index fcf8f6a1c2c6..6c4b259d31d3 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -24,6 +24,7 @@ struct clk_programmable {
 	u32 *mux_table;
 	u8 id;
 	const struct clk_programmable_layout *layout;
+	struct at91_clk_pms pms;
 };
 
 #define to_clk_programmable(hw) container_of(hw, struct clk_programmable, hw)
@@ -177,12 +178,38 @@ static int clk_programmable_set_rate(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
+static int clk_programmable_save_context(struct clk_hw *hw)
+{
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	struct clk_hw *parent_hw = clk_hw_get_parent(hw);
+
+	prog->pms.parent = clk_programmable_get_parent(hw);
+	prog->pms.parent_rate = clk_hw_get_rate(parent_hw);
+	prog->pms.rate = clk_programmable_recalc_rate(hw, prog->pms.parent_rate);
+
+	return 0;
+}
+
+static void clk_programmable_restore_context(struct clk_hw *hw)
+{
+	struct clk_programmable *prog = to_clk_programmable(hw);
+	int ret;
+
+	ret = clk_programmable_set_parent(hw, prog->pms.parent);
+	if (ret)
+		return;
+
+	clk_programmable_set_rate(hw, prog->pms.rate, prog->pms.parent_rate);
+}
+
 static const struct clk_ops programmable_ops = {
 	.recalc_rate = clk_programmable_recalc_rate,
 	.determine_rate = clk_programmable_determine_rate,
 	.get_parent = clk_programmable_get_parent,
 	.set_parent = clk_programmable_set_parent,
 	.set_rate = clk_programmable_set_rate,
+	.save_context = clk_programmable_save_context,
+	.restore_context = clk_programmable_restore_context,
 };
 
 struct clk_hw * __init
@@ -221,8 +248,6 @@ at91_clk_register_programmable(struct regmap *regmap,
 	if (ret) {
 		kfree(prog);
 		hw = ERR_PTR(ret);
-	} else {
-		pmc_register_pck(id);
 	}
 
 	return hw;
diff --git a/drivers/clk/at91/clk-sam9x60-pll.c b/drivers/clk/at91/clk-sam9x60-pll.c
index 34e3ab13741a..7020d3bf6e13 100644
--- a/drivers/clk/at91/clk-sam9x60-pll.c
+++ b/drivers/clk/at91/clk-sam9x60-pll.c
@@ -38,12 +38,14 @@ struct sam9x60_pll_core {
 
 struct sam9x60_frac {
 	struct sam9x60_pll_core core;
+	struct at91_clk_pms pms;
 	u32 frac;
 	u16 mul;
 };
 
 struct sam9x60_div {
 	struct sam9x60_pll_core core;
+	struct at91_clk_pms pms;
 	u8 div;
 };
 
@@ -75,9 +77,8 @@ static unsigned long sam9x60_frac_pll_recalc_rate(struct clk_hw *hw,
 		((u64)parent_rate * frac->frac >> 22));
 }
 
-static int sam9x60_frac_pll_prepare(struct clk_hw *hw)
+static int sam9x60_frac_pll_set(struct sam9x60_pll_core *core)
 {
-	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
 	struct sam9x60_frac *frac = to_sam9x60_frac(core);
 	struct regmap *regmap = core->regmap;
 	unsigned int val, cfrac, cmul;
@@ -141,6 +142,13 @@ static int sam9x60_frac_pll_prepare(struct clk_hw *hw)
 	return 0;
 }
 
+static int sam9x60_frac_pll_prepare(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+
+	return sam9x60_frac_pll_set(core);
+}
+
 static void sam9x60_frac_pll_unprepare(struct clk_hw *hw)
 {
 	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
@@ -280,6 +288,25 @@ static int sam9x60_frac_pll_set_rate_chg(struct clk_hw *hw, unsigned long rate,
 	return ret;
 }
 
+static int sam9x60_frac_pll_save_context(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+	struct sam9x60_frac *frac = to_sam9x60_frac(core);
+
+	frac->pms.status = sam9x60_pll_ready(core->regmap, core->id);
+
+	return 0;
+}
+
+static void sam9x60_frac_pll_restore_context(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+	struct sam9x60_frac *frac = to_sam9x60_frac(core);
+
+	if (frac->pms.status)
+		sam9x60_frac_pll_set(core);
+}
+
 static const struct clk_ops sam9x60_frac_pll_ops = {
 	.prepare = sam9x60_frac_pll_prepare,
 	.unprepare = sam9x60_frac_pll_unprepare,
@@ -287,6 +314,8 @@ static const struct clk_ops sam9x60_frac_pll_ops = {
 	.recalc_rate = sam9x60_frac_pll_recalc_rate,
 	.round_rate = sam9x60_frac_pll_round_rate,
 	.set_rate = sam9x60_frac_pll_set_rate,
+	.save_context = sam9x60_frac_pll_save_context,
+	.restore_context = sam9x60_frac_pll_restore_context,
 };
 
 static const struct clk_ops sam9x60_frac_pll_ops_chg = {
@@ -296,11 +325,12 @@ static const struct clk_ops sam9x60_frac_pll_ops_chg = {
 	.recalc_rate = sam9x60_frac_pll_recalc_rate,
 	.round_rate = sam9x60_frac_pll_round_rate,
 	.set_rate = sam9x60_frac_pll_set_rate_chg,
+	.save_context = sam9x60_frac_pll_save_context,
+	.restore_context = sam9x60_frac_pll_restore_context,
 };
 
-static int sam9x60_div_pll_prepare(struct clk_hw *hw)
+static int sam9x60_div_pll_set(struct sam9x60_pll_core *core)
 {
-	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
 	struct sam9x60_div *div = to_sam9x60_div(core);
 	struct regmap *regmap = core->regmap;
 	unsigned long flags;
@@ -334,6 +364,13 @@ static int sam9x60_div_pll_prepare(struct clk_hw *hw)
 	return 0;
 }
 
+static int sam9x60_div_pll_prepare(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+
+	return sam9x60_div_pll_set(core);
+}
+
 static void sam9x60_div_pll_unprepare(struct clk_hw *hw)
 {
 	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
@@ -482,6 +519,25 @@ static int sam9x60_div_pll_set_rate_chg(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
+static int sam9x60_div_pll_save_context(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+	struct sam9x60_div *div = to_sam9x60_div(core);
+
+	div->pms.status = sam9x60_div_pll_is_prepared(hw);
+
+	return 0;
+}
+
+static void sam9x60_div_pll_restore_context(struct clk_hw *hw)
+{
+	struct sam9x60_pll_core *core = to_sam9x60_pll_core(hw);
+	struct sam9x60_div *div = to_sam9x60_div(core);
+
+	if (div->pms.status)
+		sam9x60_div_pll_set(core);
+}
+
 static const struct clk_ops sam9x60_div_pll_ops = {
 	.prepare = sam9x60_div_pll_prepare,
 	.unprepare = sam9x60_div_pll_unprepare,
@@ -489,6 +545,8 @@ static const struct clk_ops sam9x60_div_pll_ops = {
 	.recalc_rate = sam9x60_div_pll_recalc_rate,
 	.round_rate = sam9x60_div_pll_round_rate,
 	.set_rate = sam9x60_div_pll_set_rate,
+	.save_context = sam9x60_div_pll_save_context,
+	.restore_context = sam9x60_div_pll_restore_context,
 };
 
 static const struct clk_ops sam9x60_div_pll_ops_chg = {
@@ -498,6 +556,8 @@ static const struct clk_ops sam9x60_div_pll_ops_chg = {
 	.recalc_rate = sam9x60_div_pll_recalc_rate,
 	.round_rate = sam9x60_div_pll_round_rate,
 	.set_rate = sam9x60_div_pll_set_rate_chg,
+	.save_context = sam9x60_div_pll_save_context,
+	.restore_context = sam9x60_div_pll_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
index f83ec0de86c3..80720fd1a9cf 100644
--- a/drivers/clk/at91/clk-system.c
+++ b/drivers/clk/at91/clk-system.c
@@ -20,6 +20,7 @@
 struct clk_system {
 	struct clk_hw hw;
 	struct regmap *regmap;
+	struct at91_clk_pms pms;
 	u8 id;
 };
 
@@ -77,10 +78,29 @@ static int clk_system_is_prepared(struct clk_hw *hw)
 	return !!(status & (1 << sys->id));
 }
 
+static int clk_system_save_context(struct clk_hw *hw)
+{
+	struct clk_system *sys = to_clk_system(hw);
+
+	sys->pms.status = clk_system_is_prepared(hw);
+
+	return 0;
+}
+
+static void clk_system_restore_context(struct clk_hw *hw)
+{
+	struct clk_system *sys = to_clk_system(hw);
+
+	if (sys->pms.status)
+		clk_system_prepare(&sys->hw);
+}
+
 static const struct clk_ops system_ops = {
 	.prepare = clk_system_prepare,
 	.unprepare = clk_system_unprepare,
 	.is_prepared = clk_system_is_prepared,
+	.save_context = clk_system_save_context,
+	.restore_context = clk_system_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
index 31d5c45e30d7..b0696a928aa9 100644
--- a/drivers/clk/at91/clk-usb.c
+++ b/drivers/clk/at91/clk-usb.c
@@ -24,6 +24,7 @@
 struct at91sam9x5_clk_usb {
 	struct clk_hw hw;
 	struct regmap *regmap;
+	struct at91_clk_pms pms;
 	u32 usbs_mask;
 	u8 num_parents;
 };
@@ -148,12 +149,38 @@ static int at91sam9x5_clk_usb_set_rate(struct clk_hw *hw, unsigned long rate,
 	return 0;
 }
 
+static int at91sam9x5_usb_save_context(struct clk_hw *hw)
+{
+	struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
+	struct clk_hw *parent_hw = clk_hw_get_parent(hw);
+
+	usb->pms.parent = at91sam9x5_clk_usb_get_parent(hw);
+	usb->pms.parent_rate = clk_hw_get_rate(parent_hw);
+	usb->pms.rate = at91sam9x5_clk_usb_recalc_rate(hw, usb->pms.parent_rate);
+
+	return 0;
+}
+
+static void at91sam9x5_usb_restore_context(struct clk_hw *hw)
+{
+	struct at91sam9x5_clk_usb *usb = to_at91sam9x5_clk_usb(hw);
+	int ret;
+
+	ret = at91sam9x5_clk_usb_set_parent(hw, usb->pms.parent);
+	if (ret)
+		return;
+
+	at91sam9x5_clk_usb_set_rate(hw, usb->pms.rate, usb->pms.parent_rate);
+}
+
 static const struct clk_ops at91sam9x5_usb_ops = {
 	.recalc_rate = at91sam9x5_clk_usb_recalc_rate,
 	.determine_rate = at91sam9x5_clk_usb_determine_rate,
 	.get_parent = at91sam9x5_clk_usb_get_parent,
 	.set_parent = at91sam9x5_clk_usb_set_parent,
 	.set_rate = at91sam9x5_clk_usb_set_rate,
+	.save_context = at91sam9x5_usb_save_context,
+	.restore_context = at91sam9x5_usb_restore_context,
 };
 
 static int at91sam9n12_clk_usb_enable(struct clk_hw *hw)
diff --git a/drivers/clk/at91/clk-utmi.c b/drivers/clk/at91/clk-utmi.c
index df9f3fc3b6a6..2b102ee2a7d3 100644
--- a/drivers/clk/at91/clk-utmi.c
+++ b/drivers/clk/at91/clk-utmi.c
@@ -23,6 +23,7 @@ struct clk_utmi {
 	struct clk_hw hw;
 	struct regmap *regmap_pmc;
 	struct regmap *regmap_sfr;
+	struct at91_clk_pms pms;
 };
 
 #define to_clk_utmi(hw) container_of(hw, struct clk_utmi, hw)
@@ -113,11 +114,30 @@ static unsigned long clk_utmi_recalc_rate(struct clk_hw *hw,
 	return UTMI_RATE;
 }
 
+static int clk_utmi_save_context(struct clk_hw *hw)
+{
+	struct clk_utmi *utmi = to_clk_utmi(hw);
+
+	utmi->pms.status = clk_utmi_is_prepared(hw);
+
+	return 0;
+}
+
+static void clk_utmi_restore_context(struct clk_hw *hw)
+{
+	struct clk_utmi *utmi = to_clk_utmi(hw);
+
+	if (utmi->pms.status)
+		clk_utmi_prepare(hw);
+}
+
 static const struct clk_ops utmi_ops = {
 	.prepare = clk_utmi_prepare,
 	.unprepare = clk_utmi_unprepare,
 	.is_prepared = clk_utmi_is_prepared,
 	.recalc_rate = clk_utmi_recalc_rate,
+	.save_context = clk_utmi_save_context,
+	.restore_context = clk_utmi_restore_context,
 };
 
 static struct clk_hw * __init
@@ -232,10 +252,35 @@ static int clk_utmi_sama7g5_is_prepared(struct clk_hw *hw)
 	return 0;
 }
 
+static unsigned long clk_utmi_sama7g5_recalc_rate(struct clk_hw *hw,
+						  unsigned long parent_rate)
+{
+	return 480000000;
+}
+
+static int clk_utmi_sama7g5_save_context(struct clk_hw *hw)
+{
+	struct clk_utmi *utmi = to_clk_utmi(hw);
+
+	utmi->pms.status = clk_utmi_sama7g5_is_prepared(hw);
+
+	return 0;
+}
+
+static void clk_utmi_sama7g5_restore_context(struct clk_hw *hw)
+{
+	struct clk_utmi *utmi = to_clk_utmi(hw);
+
+	if (utmi->pms.status)
+		clk_utmi_sama7g5_prepare(hw);
+}
+
 static const struct clk_ops sama7g5_utmi_ops = {
 	.prepare = clk_utmi_sama7g5_prepare,
 	.is_prepared = clk_utmi_sama7g5_is_prepared,
-	.recalc_rate = clk_utmi_recalc_rate,
+	.recalc_rate = clk_utmi_sama7g5_recalc_rate,
+	.save_context = clk_utmi_sama7g5_save_context,
+	.restore_context = clk_utmi_sama7g5_restore_context,
 };
 
 struct clk_hw * __init
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 20ee9dccee78..77b57c9f5dcb 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -3,6 +3,7 @@
  *  Copyright (C) 2013 Boris BREZILLON <b.brezillon at overkiz.com>
  */
 
+#include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
 #include <linux/clk/at91_pmc.h>
@@ -14,8 +15,6 @@
 
 #include <asm/proc-fns.h>
 
-#include <dt-bindings/clock/at91.h>
-
 #include "pmc.h"
 
 #define PMC_MAX_IDS 128
@@ -111,147 +110,19 @@ struct pmc_data *pmc_data_allocate(unsigned int ncore, unsigned int nsystem,
 }
 
 #ifdef CONFIG_PM
-static struct regmap *pmcreg;
-
-static u8 registered_ids[PMC_MAX_IDS];
-static u8 registered_pcks[PMC_MAX_PCKS];
-
-static struct
-{
-	u32 scsr;
-	u32 pcsr0;
-	u32 uckr;
-	u32 mor;
-	u32 mcfr;
-	u32 pllar;
-	u32 mckr;
-	u32 usb;
-	u32 imr;
-	u32 pcsr1;
-	u32 pcr[PMC_MAX_IDS];
-	u32 audio_pll0;
-	u32 audio_pll1;
-	u32 pckr[PMC_MAX_PCKS];
-} pmc_cache;
-
-/*
- * As Peripheral ID 0 is invalid on AT91 chips, the identifier is stored
- * without alteration in the table, and 0 is for unused clocks.
- */
-void pmc_register_id(u8 id)
-{
-	int i;
-
-	for (i = 0; i < PMC_MAX_IDS; i++) {
-		if (registered_ids[i] == 0) {
-			registered_ids[i] = id;
-			break;
-		}
-		if (registered_ids[i] == id)
-			break;
-	}
-}
-
-/*
- * As Programmable Clock 0 is valid on AT91 chips, there is an offset
- * of 1 between the stored value and the real clock ID.
- */
-void pmc_register_pck(u8 pck)
-{
-	int i;
-
-	for (i = 0; i < PMC_MAX_PCKS; i++) {
-		if (registered_pcks[i] == 0) {
-			registered_pcks[i] = pck + 1;
-			break;
-		}
-		if (registered_pcks[i] == (pck + 1))
-			break;
-	}
-}
-
-static int pmc_suspend(void)
+static int at91_pmc_suspend(void)
 {
-	int i;
-	u8 num;
-
-	regmap_read(pmcreg, AT91_PMC_SCSR, &pmc_cache.scsr);
-	regmap_read(pmcreg, AT91_PMC_PCSR, &pmc_cache.pcsr0);
-	regmap_read(pmcreg, AT91_CKGR_UCKR, &pmc_cache.uckr);
-	regmap_read(pmcreg, AT91_CKGR_MOR, &pmc_cache.mor);
-	regmap_read(pmcreg, AT91_CKGR_MCFR, &pmc_cache.mcfr);
-	regmap_read(pmcreg, AT91_CKGR_PLLAR, &pmc_cache.pllar);
-	regmap_read(pmcreg, AT91_PMC_MCKR, &pmc_cache.mckr);
-	regmap_read(pmcreg, AT91_PMC_USB, &pmc_cache.usb);
-	regmap_read(pmcreg, AT91_PMC_IMR, &pmc_cache.imr);
-	regmap_read(pmcreg, AT91_PMC_PCSR1, &pmc_cache.pcsr1);
-
-	for (i = 0; registered_ids[i]; i++) {
-		regmap_write(pmcreg, AT91_PMC_PCR,
-			     (registered_ids[i] & AT91_PMC_PCR_PID_MASK));
-		regmap_read(pmcreg, AT91_PMC_PCR,
-			    &pmc_cache.pcr[registered_ids[i]]);
-	}
-	for (i = 0; registered_pcks[i]; i++) {
-		num = registered_pcks[i] - 1;
-		regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
-	}
-
-	return 0;
+	return clk_save_context();
 }
 
-static bool pmc_ready(unsigned int mask)
+static void at91_pmc_resume(void)
 {
-	unsigned int status;
-
-	regmap_read(pmcreg, AT91_PMC_SR, &status);
-
-	return ((status & mask) == mask) ? 1 : 0;
-}
-
-static void pmc_resume(void)
-{
-	int i;
-	u8 num;
-	u32 tmp;
-	u32 mask = AT91_PMC_MCKRDY | AT91_PMC_LOCKA;
-
-	regmap_read(pmcreg, AT91_PMC_MCKR, &tmp);
-	if (pmc_cache.mckr != tmp)
-		pr_warn("MCKR was not configured properly by the firmware\n");
-	regmap_read(pmcreg, AT91_CKGR_PLLAR, &tmp);
-	if (pmc_cache.pllar != tmp)
-		pr_warn("PLLAR was not configured properly by the firmware\n");
-
-	regmap_write(pmcreg, AT91_PMC_SCER, pmc_cache.scsr);
-	regmap_write(pmcreg, AT91_PMC_PCER, pmc_cache.pcsr0);
-	regmap_write(pmcreg, AT91_CKGR_UCKR, pmc_cache.uckr);
-	regmap_write(pmcreg, AT91_CKGR_MOR, pmc_cache.mor);
-	regmap_write(pmcreg, AT91_CKGR_MCFR, pmc_cache.mcfr);
-	regmap_write(pmcreg, AT91_PMC_USB, pmc_cache.usb);
-	regmap_write(pmcreg, AT91_PMC_IMR, pmc_cache.imr);
-	regmap_write(pmcreg, AT91_PMC_PCER1, pmc_cache.pcsr1);
-
-	for (i = 0; registered_ids[i]; i++) {
-		regmap_write(pmcreg, AT91_PMC_PCR,
-			     pmc_cache.pcr[registered_ids[i]] |
-			     AT91_PMC_PCR_CMD);
-	}
-	for (i = 0; registered_pcks[i]; i++) {
-		num = registered_pcks[i] - 1;
-		regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
-	}
-
-	if (pmc_cache.uckr & AT91_PMC_UPLLEN)
-		mask |= AT91_PMC_LOCKU;
-
-	while (!pmc_ready(mask))
-		cpu_relax();
+	clk_restore_context();
 }
 
 static struct syscore_ops pmc_syscore_ops = {
-	.suspend = pmc_suspend,
-	.resume = pmc_resume,
+	.suspend = at91_pmc_suspend,
+	.resume = at91_pmc_resume,
 };
 
 static const struct of_device_id sama5d2_pmc_dt_ids[] = {
@@ -265,12 +136,8 @@ static int __init pmc_register_ops(void)
 
 	np = of_find_matching_node(NULL, sama5d2_pmc_dt_ids);
 	if (!np)
-		return -ENODEV;
-
-	pmcreg = device_node_to_regmap(np);
+		return 0;
 	of_node_put(np);
-	if (IS_ERR(pmcreg))
-		return PTR_ERR(pmcreg);
 
 	register_syscore_ops(&pmc_syscore_ops);
 
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index a49076c804a9..86580ebd9ad9 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -13,6 +13,8 @@
 #include <linux/regmap.h>
 #include <linux/spinlock.h>
 
+#include <dt-bindings/clock/at91.h>
+
 extern spinlock_t pmc_pcr_lock;
 
 struct pmc_data {
@@ -98,6 +100,20 @@ struct clk_pcr_layout {
 	u32 pid_mask;
 };
 
+/**
+ * struct at91_clk_pms - Power management state for AT91 clock
+ * @status: clock status (enabled or disabled)
+ * @parent: clock parent index
+ * @parent_rate: clock parent rate
+ * @rate: clock rate
+ */
+struct at91_clk_pms {
+	unsigned int status;
+	unsigned int parent;
+	unsigned long parent_rate;
+	unsigned long rate;
+};
+
 #define field_get(_mask, _reg) (((_reg) & (_mask)) >> (ffs(_mask) - 1))
 #define field_prep(_mask, _val) (((_val) << (ffs(_mask) - 1)) & (_mask))
 
@@ -248,12 +264,4 @@ struct clk_hw * __init
 at91_clk_sama7g5_register_utmi(struct regmap *regmap, const char *name,
 			       const char *parent_name);
 
-#ifdef CONFIG_PM
-void pmc_register_id(u8 id);
-void pmc_register_pck(u8 pck);
-#else
-static inline void pmc_register_id(u8 id) {}
-static inline void pmc_register_pck(u8 pck) {}
-#endif
-
 #endif /* __PMC_H_ */
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:22 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:22 +0300
Subject: [PATCH v2 2/6] clk: at91: pmc: execute suspend/resume only for backup
 mode
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-3-claudiu.beznea@microchip.com>

Before going to backup mode architecture specific PM code sets the first
word in securam (and it will be cleared in a subsequent commit for the rest
of power saving modes). Thus take this into account when
suspending/resuming clocks. This will avoid executing unnecessary
instructions when suspending to non backup modes. Since the clear of the
1st word in securam will be done in a subsequent commit the current commit
will not broke the current behavior since up to this moment the
suspend/resume were executed for all AT91 PM modes. The difference now
is that the suspend/resume for clocks will be executed for the rest of
AT91 PM modes just after the 1st enter/exit to/from backup mode.
Also this commit changed the postcore_initcall() with subsys_initcall()
to be able to execute of_find_compatible_node() since this was not
available at the moment of postcore_initcall(). This should not alter
the tcb_clksrc since the changes are related to clocks suspend/resume
procedure that will be executed at the user space request, thus long
ago after postcore_initcall().

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 drivers/clk/at91/pmc.c | 48 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
index 77b57c9f5dcb..c226d33cd899 100644
--- a/drivers/clk/at91/pmc.c
+++ b/drivers/clk/at91/pmc.c
@@ -8,6 +8,8 @@
 #include <linux/clkdev.h>
 #include <linux/clk/at91_pmc.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
 #include <linux/mfd/syscon.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
@@ -110,13 +112,35 @@ struct pmc_data *pmc_data_allocate(unsigned int ncore, unsigned int nsystem,
 }
 
 #ifdef CONFIG_PM
+
+/* Address in SECURAM that say if we suspend to backup mode. */
+static void __iomem *at91_pmc_backup_suspend;
+
 static int at91_pmc_suspend(void)
 {
+	unsigned int backup;
+
+	if (!at91_pmc_backup_suspend)
+		return 0;
+
+	backup = *(unsigned int *)at91_pmc_backup_suspend;
+	if (!backup)
+		return 0;
+
 	return clk_save_context();
 }
 
 static void at91_pmc_resume(void)
 {
+	unsigned int backup;
+
+	if (!at91_pmc_backup_suspend)
+		return;
+
+	backup = *(unsigned int *)at91_pmc_backup_suspend;
+	if (!backup)
+		return;
+
 	clk_restore_context();
 }
 
@@ -125,24 +149,30 @@ static struct syscore_ops pmc_syscore_ops = {
 	.resume = at91_pmc_resume,
 };
 
-static const struct of_device_id sama5d2_pmc_dt_ids[] = {
-	{ .compatible = "atmel,sama5d2-pmc" },
-	{ /* sentinel */ }
-};
-
 static int __init pmc_register_ops(void)
 {
+	struct platform_device *pdev;
 	struct device_node *np;
 
-	np = of_find_matching_node(NULL, sama5d2_pmc_dt_ids);
+	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-securam");
 	if (!np)
-		return 0;
+		return -ENODEV;
+
+	pdev = of_find_device_by_node(np);
 	of_node_put(np);
+	if (!pdev)
+		return -ENODEV;
+
+	at91_pmc_backup_suspend = of_iomap(np, 0);
+	if (!at91_pmc_backup_suspend) {
+		pr_warn("%s(): unable to map securam\n", __func__);
+		return -ENOMEM;
+	}
 
 	register_syscore_ops(&pmc_syscore_ops);
 
 	return 0;
 }
-/* This has to happen before arch_initcall because of the tcb_clksrc driver */
-postcore_initcall(pmc_register_ops);
+
+subsys_initcall(pmc_register_ops);
 #endif
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:23 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:23 +0300
Subject: [PATCH v2 3/6] clk: at91: sama7g5: add securam's peripheral clock
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-4-claudiu.beznea@microchip.com>

Add SECURAM's peripheral clock.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
---
 drivers/clk/at91/sama7g5.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index 9e1ec48c4474..9c87b50abbae 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -377,6 +377,7 @@ static const struct {
 	u8 id;
 } sama7g5_periphck[] = {
 	{ .n = "pioA_clk",	.p = "mck0", .id = 11, },
+	{ .n = "securam_clk",	.p = "mck0", .id = 18, },
 	{ .n = "sfr_clk",	.p = "mck1", .id = 19, },
 	{ .n = "hsmc_clk",	.p = "mck1", .id = 21, },
 	{ .n = "xdmac0_clk",	.p = "mck1", .id = 22, },
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:24 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:24 +0300
Subject: [PATCH v2 4/6] clk: at91: clk-master: add register definition for
 sama7g5's master clock
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-5-claudiu.beznea@microchip.com>

Add register definitions for SAMA7G5's master clock. These would be
also used by architecture specific power saving code. With this, update
also clk-master.c.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 drivers/clk/at91/clk-master.c | 50 ++++++++++++++++-------------------
 include/linux/clk/at91_pmc.h  | 26 ++++++++++++++++++
 2 files changed, 49 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 21e82111890d..736406528824 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -17,15 +17,7 @@
 #define MASTER_DIV_SHIFT	8
 #define MASTER_DIV_MASK		0x7
 
-#define PMC_MCR			0x30
-#define PMC_MCR_ID_MSK		GENMASK(3, 0)
-#define PMC_MCR_CMD		BIT(7)
-#define PMC_MCR_DIV		GENMASK(10, 8)
-#define PMC_MCR_CSS		GENMASK(20, 16)
 #define PMC_MCR_CSS_SHIFT	(16)
-#define PMC_MCR_EN		BIT(28)
-
-#define PMC_MCR_ID(x)		((x) & PMC_MCR_ID_MSK)
 
 #define MASTER_MAX_ID		4
 
@@ -682,20 +674,22 @@ static void clk_sama7g5_master_set(struct clk_master *master,
 {
 	unsigned long flags;
 	unsigned int val, cparent;
-	unsigned int enable = status ? PMC_MCR_EN : 0;
+	unsigned int enable = status ? AT91_PMC_MCR_V2_EN : 0;
 
 	spin_lock_irqsave(master->lock, flags);
 
-	regmap_write(master->regmap, PMC_MCR, PMC_MCR_ID(master->id));
-	regmap_read(master->regmap, PMC_MCR, &val);
-	regmap_update_bits(master->regmap, PMC_MCR,
-			   enable | PMC_MCR_CSS | PMC_MCR_DIV |
-			   PMC_MCR_CMD | PMC_MCR_ID_MSK,
+	regmap_write(master->regmap, AT91_PMC_MCR_V2,
+		     AT91_PMC_MCR_V2_ID(master->id));
+	regmap_read(master->regmap, AT91_PMC_MCR_V2, &val);
+	regmap_update_bits(master->regmap, AT91_PMC_MCR_V2,
+			   enable | AT91_PMC_MCR_V2_CSS | AT91_PMC_MCR_V2_DIV |
+			   AT91_PMC_MCR_V2_CMD | AT91_PMC_MCR_V2_ID_MSK,
 			   enable | (master->parent << PMC_MCR_CSS_SHIFT) |
 			   (master->div << MASTER_DIV_SHIFT) |
-			   PMC_MCR_CMD | PMC_MCR_ID(master->id));
+			   AT91_PMC_MCR_V2_CMD |
+			   AT91_PMC_MCR_V2_ID(master->id));
 
-	cparent = (val & PMC_MCR_CSS) >> PMC_MCR_CSS_SHIFT;
+	cparent = (val & AT91_PMC_MCR_V2_CSS) >> PMC_MCR_CSS_SHIFT;
 
 	/* Wait here only if parent is being changed. */
 	while ((cparent != master->parent) && !clk_master_ready(master))
@@ -720,10 +714,12 @@ static void clk_sama7g5_master_disable(struct clk_hw *hw)
 
 	spin_lock_irqsave(master->lock, flags);
 
-	regmap_write(master->regmap, PMC_MCR, master->id);
-	regmap_update_bits(master->regmap, PMC_MCR,
-			   PMC_MCR_EN | PMC_MCR_CMD | PMC_MCR_ID_MSK,
-			   PMC_MCR_CMD | PMC_MCR_ID(master->id));
+	regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+	regmap_update_bits(master->regmap, AT91_PMC_MCR_V2,
+			   AT91_PMC_MCR_V2_EN | AT91_PMC_MCR_V2_CMD |
+			   AT91_PMC_MCR_V2_ID_MSK,
+			   AT91_PMC_MCR_V2_CMD |
+			   AT91_PMC_MCR_V2_ID(master->id));
 
 	spin_unlock_irqrestore(master->lock, flags);
 }
@@ -736,12 +732,12 @@ static int clk_sama7g5_master_is_enabled(struct clk_hw *hw)
 
 	spin_lock_irqsave(master->lock, flags);
 
-	regmap_write(master->regmap, PMC_MCR, master->id);
-	regmap_read(master->regmap, PMC_MCR, &val);
+	regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+	regmap_read(master->regmap, AT91_PMC_MCR_V2, &val);
 
 	spin_unlock_irqrestore(master->lock, flags);
 
-	return !!(val & PMC_MCR_EN);
+	return !!(val & AT91_PMC_MCR_V2_EN);
 }
 
 static int clk_sama7g5_master_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -837,10 +833,10 @@ at91_clk_sama7g5_register_master(struct regmap *regmap,
 	master->mux_table = mux_table;
 
 	spin_lock_irqsave(master->lock, flags);
-	regmap_write(master->regmap, PMC_MCR, master->id);
-	regmap_read(master->regmap, PMC_MCR, &val);
-	master->parent = (val & PMC_MCR_CSS) >> PMC_MCR_CSS_SHIFT;
-	master->div = (val & PMC_MCR_DIV) >> MASTER_DIV_SHIFT;
+	regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+	regmap_read(master->regmap, AT91_PMC_MCR_V2, &val);
+	master->parent = (val & AT91_PMC_MCR_V2_CSS) >> PMC_MCR_CSS_SHIFT;
+	master->div = (val & AT91_PMC_MCR_V2_DIV) >> MASTER_DIV_SHIFT;
 	spin_unlock_irqrestore(master->lock, flags);
 
 	hw = &master->hw;
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index a4f82e836a7c..ccb3f034bfa9 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -137,6 +137,32 @@
 #define			AT91_PMC_PLLADIV2_ON		(1 << 12)
 #define		AT91_PMC_H32MXDIV	BIT(24)
 
+#define	AT91_PMC_MCR_V2		0x30				/* Master Clock Register [SAMA7G5 only] */
+#define		AT91_PMC_MCR_V2_ID_MSK	(0xF)
+#define			AT91_PMC_MCR_V2_ID(_id)		((_id) & AT91_PMC_MCR_V2_ID_MSK)
+#define		AT91_PMC_MCR_V2_CMD	(1 << 7)
+#define		AT91_PMC_MCR_V2_DIV	(7 << 8)
+#define			AT91_PMC_MCR_V2_DIV1		(0 << 8)
+#define			AT91_PMC_MCR_V2_DIV2		(1 << 8)
+#define			AT91_PMC_MCR_V2_DIV4		(2 << 8)
+#define			AT91_PMC_MCR_V2_DIV8		(3 << 8)
+#define			AT91_PMC_MCR_V2_DIV16		(4 << 8)
+#define			AT91_PMC_MCR_V2_DIV32		(5 << 8)
+#define			AT91_PMC_MCR_V2_DIV64		(6 << 8)
+#define			AT91_PMC_MCR_V2_DIV3		(7 << 8)
+#define		AT91_PMC_MCR_V2_CSS	(0x1F << 16)
+#define			AT91_PMC_MCR_V2_CSS_MD_SLCK	(0 << 16)
+#define			AT91_PMC_MCR_V2_CSS_TD_SLCK	(1 << 16)
+#define			AT91_PMC_MCR_V2_CSS_MAINCK	(2 << 16)
+#define			AT91_PMC_MCR_V2_CSS_MCK0	(3 << 16)
+#define			AT91_PMC_MCR_V2_CSS_SYSPLL	(5 << 16)
+#define			AT91_PMC_MCR_V2_CSS_DDRPLL	(6 << 16)
+#define			AT91_PMC_MCR_V2_CSS_IMGPLL	(7 << 16)
+#define			AT91_PMC_MCR_V2_CSS_BAUDPLL	(8 << 16)
+#define			AT91_PMC_MCR_V2_CSS_AUDIOPLL	(9 << 16)
+#define			AT91_PMC_MCR_V2_CSS_ETHPLL	(10 << 16)
+#define		AT91_PMC_MCR_V2_EN	(1 << 28)
+
 #define AT91_PMC_XTALF		0x34			/* Main XTAL Frequency Register [SAMA7G5 only] */
 
 #define	AT91_PMC_USB		0x38			/* USB Clock Register [some SAM9 only] */
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr  1 13:27:25 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:25 +0300
Subject: [PATCH v2 5/6] clk: at91: clk-master: update for dvfs
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-6-claudiu.beznea@microchip.com>

SAMA7G5 supports CPU DVFS. The hardware block diagram for the clock
system generating CPU clock is as follows:

                               +--------+
                           +-->|divider1|--> CPU clock
                           |   +--------+
+--------+   +----------+  |   +--------+
|CPU PLL |-->|prescaller|--+-->|divider0|--> MCK0 clock
+--------+   +----------+      +--------+

The divider1 is not implemented in software since the supported CPU
frequencies could be directly retrieved from CPU PLL + prescaller.
Every time the CPU clock needs to be changed the MCK0 should also be
changed to avoid its over/under clocking and also to preserve its
initial value (200MHz). MCK0 feeds IPs that are glitch free aware.

The initial approach for implementing DVFS was to implement MCK0 and
CPU clocks as 2 different Linux clocks, to pass these two clocks to CPUFreq
driver and in CPUFreq driver to run clk_set_rate() on CPU and MCK clocks
accordingly. E.g. if 1GHz speed was requested by CPUFreq subsystem the
following were executed in CPUFreq driver:

/* ... */
clk_set_rate(mck0, intermediary_freq_to_avoid_over_under_clocking);
clk_set_rate(cpu, 1000000000);
clk_set_rate(mck0, initial_freq);
/ ... */

However, it has been proposed in [1] to use the generic cpufreq-dt driver
and to overload the necessary clocks operations in the proper clock
driver.

To address this proposal the master clock prescaller registers a clock
notifier that will update properly the master clock divider on
PRE_RATE_CHANGE and POST_RATE_CHANGE events to avoid master clock
divider over/under clocking and also to preserve its initial value
(200MHz).

[1] https://lore.kernel.org/lkml/1609842147-8161-1-git-send-email-claudiu.beznea at microchip.com/

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 drivers/clk/at91/at91rm9200.c  |   2 +-
 drivers/clk/at91/at91sam9260.c |   2 +-
 drivers/clk/at91/at91sam9g45.c |   2 +-
 drivers/clk/at91/at91sam9n12.c |   2 +-
 drivers/clk/at91/at91sam9rl.c  |   2 +-
 drivers/clk/at91/at91sam9x5.c  |   2 +-
 drivers/clk/at91/clk-master.c  | 187 ++++++++++++++++++++-------------
 drivers/clk/at91/dt-compat.c   |   2 +-
 drivers/clk/at91/pmc.h         |   3 +-
 drivers/clk/at91/sam9x60.c     |   2 +-
 drivers/clk/at91/sama5d2.c     |   2 +-
 drivers/clk/at91/sama5d3.c     |   2 +-
 drivers/clk/at91/sama5d4.c     |   2 +-
 drivers/clk/at91/sama7g5.c     |   2 +-
 14 files changed, 130 insertions(+), 84 deletions(-)

diff --git a/drivers/clk/at91/at91rm9200.c b/drivers/clk/at91/at91rm9200.c
index 428a6f4b9ebc..f8df6064d55d 100644
--- a/drivers/clk/at91/at91rm9200.c
+++ b/drivers/clk/at91/at91rm9200.c
@@ -144,7 +144,7 @@ static void __init at91rm9200_pmc_setup(struct device_node *np)
 					   &at91rm9200_master_layout,
 					   &rm9200_mck_characteristics,
 					   &rm9200_mck_lock, CLK_SET_RATE_GATE,
-					   INT_MIN);
+					   INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/at91sam9260.c b/drivers/clk/at91/at91sam9260.c
index b29843bea278..8db7bf141b45 100644
--- a/drivers/clk/at91/at91sam9260.c
+++ b/drivers/clk/at91/at91sam9260.c
@@ -420,7 +420,7 @@ static void __init at91sam926x_pmc_setup(struct device_node *np,
 					   &at91rm9200_master_layout,
 					   data->mck_characteristics,
 					   &at91sam9260_mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/at91sam9g45.c b/drivers/clk/at91/at91sam9g45.c
index 15da0dfe3ef2..c139169b2d40 100644
--- a/drivers/clk/at91/at91sam9g45.c
+++ b/drivers/clk/at91/at91sam9g45.c
@@ -155,7 +155,7 @@ static void __init at91sam9g45_pmc_setup(struct device_node *np)
 					   &at91rm9200_master_layout,
 					   &mck_characteristics,
 					   &at91sam9g45_mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/at91sam9n12.c b/drivers/clk/at91/at91sam9n12.c
index 7fe435f4b46b..a4e46c4026d0 100644
--- a/drivers/clk/at91/at91sam9n12.c
+++ b/drivers/clk/at91/at91sam9n12.c
@@ -182,7 +182,7 @@ static void __init at91sam9n12_pmc_setup(struct device_node *np)
 					   &at91sam9x5_master_layout,
 					   &mck_characteristics,
 					   &at91sam9n12_mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/at91sam9rl.c b/drivers/clk/at91/at91sam9rl.c
index ecbabf5162bd..5f2b5dda24d0 100644
--- a/drivers/clk/at91/at91sam9rl.c
+++ b/drivers/clk/at91/at91sam9rl.c
@@ -124,7 +124,7 @@ static void __init at91sam9rl_pmc_setup(struct device_node *np)
 					   &at91rm9200_master_layout,
 					   &sam9rl_mck_characteristics,
 					   &sam9rl_mck_lock, CLK_SET_RATE_GATE,
-					   INT_MIN);
+					   INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/at91sam9x5.c b/drivers/clk/at91/at91sam9x5.c
index 5cce48c64ea2..53a524ff2818 100644
--- a/drivers/clk/at91/at91sam9x5.c
+++ b/drivers/clk/at91/at91sam9x5.c
@@ -202,7 +202,7 @@ static void __init at91sam9x5_pmc_setup(struct device_node *np,
 					   parent_names,
 					   &at91sam9x5_master_layout,
 					   &mck_characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 736406528824..1b2962289629 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -5,6 +5,7 @@
 
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
+#include <linux/clk.h>
 #include <linux/clk/at91_pmc.h>
 #include <linux/of.h>
 #include <linux/mfd/syscon.h>
@@ -38,6 +39,9 @@ struct clk_master {
 	u8 div;
 };
 
+/* MCK div reference to be used by notifier. */
+static struct clk_master *master_div;
+
 static inline bool clk_master_ready(struct clk_master *master)
 {
 	unsigned int bit = master->id ? AT91_PMC_MCKXRDY : AT91_PMC_MCKRDY;
@@ -153,107 +157,127 @@ static const struct clk_ops master_div_ops = {
 	.restore_context = clk_master_div_restore_context,
 };
 
-static int clk_master_div_set_rate(struct clk_hw *hw, unsigned long rate,
-				   unsigned long parent_rate)
+static int clk_master_div_set(struct clk_master *master,
+			      unsigned long parent_rate, int div)
 {
-	struct clk_master *master = to_clk_master(hw);
 	const struct clk_master_characteristics *characteristics =
 						master->characteristics;
-	unsigned long flags;
-	unsigned int mckr, tmp;
-	int div, i;
+	unsigned long rate = parent_rate;
+	unsigned int max_div = 0, div_index = 0, max_div_index = 0;
+	unsigned int i, mckr, tmp;
 	int ret;
 
-	div = DIV_ROUND_CLOSEST(parent_rate, rate);
-	if (div > ARRAY_SIZE(characteristics->divisors))
-		return -EINVAL;
-
 	for (i = 0; i < ARRAY_SIZE(characteristics->divisors); i++) {
 		if (!characteristics->divisors[i])
 			break;
 
-		if (div == characteristics->divisors[i]) {
-			div = i;
-			break;
+		if (div == characteristics->divisors[i])
+			div_index = i;
+
+		if (max_div < characteristics->divisors[i]) {
+			max_div = characteristics->divisors[i];
+			max_div_index = i;
 		}
 	}
 
-	if (i == ARRAY_SIZE(characteristics->divisors))
-		return -EINVAL;
+	if (div > max_div)
+		div_index = max_div_index;
 
-	spin_lock_irqsave(master->lock, flags);
 	ret = regmap_read(master->regmap, master->layout->offset, &mckr);
 	if (ret)
-		goto unlock;
+		return ret;
 
 	tmp = mckr & master->layout->mask;
 	tmp = (tmp >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
-	if (tmp == div)
-		goto unlock;
+	if (tmp == div_index)
+		return 0;
+
+	rate /= characteristics->divisors[div_index];
+	if (rate < characteristics->output.min)
+		pr_warn("master clk div is underclocked");
+	else if (rate > characteristics->output.max)
+		pr_warn("master clk div is overclocked");
 
 	mckr &= ~(MASTER_DIV_MASK << MASTER_DIV_SHIFT);
-	mckr |= (div << MASTER_DIV_SHIFT);
+	mckr |= (div_index << MASTER_DIV_SHIFT);
 	ret = regmap_write(master->regmap, master->layout->offset, mckr);
 	if (ret)
-		goto unlock;
+		return ret;
 
 	while (!clk_master_ready(master))
 		cpu_relax();
-unlock:
-	spin_unlock_irqrestore(master->lock, flags);
+
+	master->div = characteristics->divisors[div_index];
 
 	return 0;
 }
 
-static int clk_master_div_determine_rate(struct clk_hw *hw,
-					 struct clk_rate_request *req)
+static int at91_clk_master_div_notifier(struct notifier_block *notifier,
+					unsigned long code, void *data)
 {
-	struct clk_master *master = to_clk_master(hw);
 	const struct clk_master_characteristics *characteristics =
-						master->characteristics;
-	struct clk_hw *parent;
-	unsigned long parent_rate, tmp_rate, best_rate = 0;
-	int i, best_diff = INT_MIN, tmp_diff;
-
-	parent = clk_hw_get_parent(hw);
-	if (!parent)
-		return -EINVAL;
-
-	parent_rate = clk_hw_get_rate(parent);
-	if (!parent_rate)
-		return -EINVAL;
-
-	for (i = 0; i < ARRAY_SIZE(characteristics->divisors); i++) {
-		if (!characteristics->divisors[i])
-			break;
-
-		tmp_rate = DIV_ROUND_CLOSEST_ULL(parent_rate,
-						 characteristics->divisors[i]);
-		tmp_diff = abs(tmp_rate - req->rate);
+						master_div->characteristics;
+	struct clk_notifier_data *cnd = data;
+	unsigned long cur_rate, flags;
+	unsigned int mckr, cur_div, diff_div;
+	static unsigned int new_div;
+
+	/*
+	 * Need to increase/decrease div to avoid master div clock over/under
+	 * clocking
+	 */
+	spin_lock_irqsave(master_div->lock, flags);
+	switch (code) {
+	case PRE_RATE_CHANGE:
+		regmap_read(master_div->regmap, master_div->layout->offset,
+			    &mckr);
+		mckr &= master_div->layout->mask;
+		mckr = (mckr >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
+
+		cur_div = characteristics->divisors[mckr];
+		cur_rate = DIV_ROUND_CLOSEST_ULL(cnd->old_rate, cur_div);
+		new_div = DIV_ROUND_CLOSEST(cnd->new_rate, cur_rate);
+		diff_div = abs(cur_div - new_div);
+
+		clk_master_div_set(master_div, cnd->old_rate,
+				   cur_div + diff_div);
+		break;
+
+	case POST_RATE_CHANGE:
+		clk_master_div_set(master_div, cnd->new_rate, new_div);
+		break;
+
+	default:
+		break;
+	}
+	spin_unlock_irqrestore(master_div->lock, flags);
 
-		if (!best_rate || best_diff > tmp_diff) {
-			best_diff = tmp_diff;
-			best_rate = tmp_rate;
-		}
+	return 0;
+}
 
-		if (!best_diff)
-			break;
-	}
+static struct notifier_block clk_master_notifier = {
+	.notifier_call = at91_clk_master_div_notifier,
+};
 
-	req->best_parent_rate = best_rate;
-	req->best_parent_hw = parent;
-	req->rate = best_rate;
+static unsigned long clk_master_div_recalc_rate_chg(struct clk_hw *hw,
+						    unsigned long parent_rate)
+{
+	struct clk_master *master = to_clk_master(hw);
 
-	return 0;
+	return DIV_ROUND_CLOSEST_ULL(parent_rate, master->div);
 }
 
 static void clk_master_div_restore_context_chg(struct clk_hw *hw)
 {
 	struct clk_master *master = to_clk_master(hw);
+	unsigned long flags;
 	int ret;
 
-	ret = clk_master_div_set_rate(hw, master->pms.rate,
-				      master->pms.parent_rate);
+	spin_lock_irqsave(master->lock, flags);
+	ret = clk_master_div_set(master, master->pms.parent_rate,
+				 DIV_ROUND_CLOSEST(master->pms.parent_rate,
+						   master->pms.rate));
+	spin_unlock_irqrestore(master->lock, flags);
 	if (ret)
 		pr_warn("Failed to restore MCK DIV clock\n");
 }
@@ -261,9 +285,7 @@ static void clk_master_div_restore_context_chg(struct clk_hw *hw)
 static const struct clk_ops master_div_ops_chg = {
 	.prepare = clk_master_prepare,
 	.is_prepared = clk_master_is_prepared,
-	.recalc_rate = clk_master_div_recalc_rate,
-	.determine_rate = clk_master_div_determine_rate,
-	.set_rate = clk_master_div_set_rate,
+	.recalc_rate = clk_master_div_recalc_rate_chg,
 	.save_context = clk_master_div_save_context,
 	.restore_context = clk_master_div_restore_context_chg,
 };
@@ -488,6 +510,8 @@ at91_clk_register_master_internal(struct regmap *regmap,
 	struct clk_master *master;
 	struct clk_init_data init;
 	struct clk_hw *hw;
+	unsigned int mckr;
+	unsigned long irqflags;
 	int ret;
 
 	if (!name || !num_parents || !parent_names || !lock)
@@ -510,6 +534,16 @@ at91_clk_register_master_internal(struct regmap *regmap,
 	master->chg_pid = chg_pid;
 	master->lock = lock;
 
+	if (ops == &master_div_ops_chg) {
+		spin_lock_irqsave(master->lock, irqflags);
+		regmap_read(master->regmap, master->layout->offset, &mckr);
+		spin_unlock_irqrestore(master->lock, irqflags);
+
+		mckr &= layout->mask;
+		mckr = (mckr >> MASTER_DIV_SHIFT) & MASTER_DIV_MASK;
+		master->div = characteristics->divisors[mckr];
+	}
+
 	hw = &master->hw;
 	ret = clk_hw_register(NULL, &master->hw);
 	if (ret) {
@@ -526,19 +560,24 @@ at91_clk_register_master_pres(struct regmap *regmap,
 		const char **parent_names,
 		const struct clk_master_layout *layout,
 		const struct clk_master_characteristics *characteristics,
-		spinlock_t *lock, u32 flags, int chg_pid)
+		spinlock_t *lock, u32 flags, int chg_pid, bool notifier)
 {
 	const struct clk_ops *ops;
+	struct clk_hw *hw;
 
 	if (flags & CLK_SET_RATE_GATE)
 		ops = &master_pres_ops;
 	else
 		ops = &master_pres_ops_chg;
 
-	return at91_clk_register_master_internal(regmap, name, num_parents,
-						 parent_names, layout,
-						 characteristics, ops,
-						 lock, flags, chg_pid);
+	hw = at91_clk_register_master_internal(regmap, name, num_parents,
+					       parent_names, layout,
+					       characteristics, ops,
+					       lock, flags, chg_pid);
+	if (!IS_ERR(hw) && notifier)
+		clk_notifier_register(hw->clk, &clk_master_notifier);
+
+	return hw;
 }
 
 struct clk_hw * __init
@@ -549,16 +588,22 @@ at91_clk_register_master_div(struct regmap *regmap,
 		spinlock_t *lock, u32 flags)
 {
 	const struct clk_ops *ops;
+	struct clk_hw *hw;
 
 	if (flags & CLK_SET_RATE_GATE)
 		ops = &master_div_ops;
 	else
 		ops = &master_div_ops_chg;
 
-	return at91_clk_register_master_internal(regmap, name, 1,
-						 &parent_name, layout,
-						 characteristics, ops,
-						 lock, flags, -EINVAL);
+	hw = at91_clk_register_master_internal(regmap, name, 1,
+					       &parent_name, layout,
+					       characteristics, ops,
+					       lock, flags, -EINVAL);
+
+	if (!IS_ERR(hw))
+		master_div = to_clk_master(hw);
+
+	return hw;
 }
 
 static unsigned long
diff --git a/drivers/clk/at91/dt-compat.c b/drivers/clk/at91/dt-compat.c
index a97b99c2dc12..99ad43ea6169 100644
--- a/drivers/clk/at91/dt-compat.c
+++ b/drivers/clk/at91/dt-compat.c
@@ -393,7 +393,7 @@ of_at91_clk_master_setup(struct device_node *np,
 	hw = at91_clk_register_master_pres(regmap, "masterck_pres", num_parents,
 					   parent_names, layout,
 					   characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto out_free_characteristics;
 
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 86580ebd9ad9..2263f4df3a82 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -175,7 +175,8 @@ at91_clk_register_master_pres(struct regmap *regmap, const char *name,
 			      int num_parents, const char **parent_names,
 			      const struct clk_master_layout *layout,
 			      const struct clk_master_characteristics *characteristics,
-			      spinlock_t *lock, u32 flags, int chg_pid);
+			      spinlock_t *lock, u32 flags, int chg_pid,
+			      bool notifier);
 
 struct clk_hw * __init
 at91_clk_register_master_div(struct regmap *regmap, const char *name,
diff --git a/drivers/clk/at91/sam9x60.c b/drivers/clk/at91/sam9x60.c
index 5f6fa89571b7..8e1b89e05724 100644
--- a/drivers/clk/at91/sam9x60.c
+++ b/drivers/clk/at91/sam9x60.c
@@ -272,7 +272,7 @@ static void __init sam9x60_pmc_setup(struct device_node *np)
 	hw = at91_clk_register_master_pres(regmap, "masterck_pres", 3,
 					   parent_names, &sam9x60_master_layout,
 					   &mck_characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
index 3d1f78176c3e..40c64c605160 100644
--- a/drivers/clk/at91/sama5d2.c
+++ b/drivers/clk/at91/sama5d2.c
@@ -241,7 +241,7 @@ static void __init sama5d2_pmc_setup(struct device_node *np)
 					   parent_names,
 					   &at91sam9x5_master_layout,
 					   &mck_characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/sama5d3.c b/drivers/clk/at91/sama5d3.c
index d376257807d2..7ec4a54982e1 100644
--- a/drivers/clk/at91/sama5d3.c
+++ b/drivers/clk/at91/sama5d3.c
@@ -176,7 +176,7 @@ static void __init sama5d3_pmc_setup(struct device_node *np)
 					   parent_names,
 					   &at91sam9x5_master_layout,
 					   &mck_characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/sama5d4.c b/drivers/clk/at91/sama5d4.c
index 5cbaac68da44..94f0a574ace4 100644
--- a/drivers/clk/at91/sama5d4.c
+++ b/drivers/clk/at91/sama5d4.c
@@ -191,7 +191,7 @@ static void __init sama5d4_pmc_setup(struct device_node *np)
 					   parent_names,
 					   &at91sam9x5_master_layout,
 					   &mck_characteristics, &mck_lock,
-					   CLK_SET_RATE_GATE, INT_MIN);
+					   CLK_SET_RATE_GATE, INT_MIN, 0);
 	if (IS_ERR(hw))
 		goto err_free;
 
diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index 9c87b50abbae..abc6563e6207 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -986,7 +986,7 @@ static void __init sama7g5_pmc_setup(struct device_node *np)
 	hw = at91_clk_register_master_pres(regmap, "cpuck", 1, parent_names,
 					   &mck0_layout, &mck0_characteristics,
 					   &pmc_mck0_lock,
-					   CLK_SET_RATE_PARENT, 0);
+					   CLK_SET_RATE_PARENT, 0, 1);
 	if (IS_ERR(hw))
 		goto err_free;
 
-- 
2.25.1



From lkp at intel.com  Thu Apr  1 13:26:37 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 1 Apr 2021 20:26:37 +0800
Subject: [xlnx:xlnx_rebase_v5.4 942/1701]
 drivers/mtd/spi-nor/spi-nor.c:5196:14: error: implicit declaration of
 function 'of_get_next_parent'; did you mean 'of_get_parent'?
Message-ID: <202104012030.XdcD0wjk-lkp@intel.com>

Hi Amit,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 24bcc7359bdd609cedf0a715d77dc39e4ad782db [942/1701] mtd: spi-nor: Added axi-qspi support in spi-nor framework
config: alpha-randconfig-r034-20210401 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/24bcc7359bdd609cedf0a715d77dc39e4ad782db
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 24bcc7359bdd609cedf0a715d77dc39e4ad782db
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_write_ear':
   drivers/mtd/spi-nor/spi-nor.c:691:5: warning: variable 'code' set but not used [-Wunused-but-set-variable]
     691 |  u8 code;
         |     ^~~~
   drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_read':
   drivers/mtd/spi-nor/spi-nor.c:2741:9: warning: variable 'addr' set but not used [-Wunused-but-set-variable]
    2741 |  loff_t addr = 0;
         |         ^~~~
   drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_set_addr_width':
>> drivers/mtd/spi-nor/spi-nor.c:5196:14: error: implicit declaration of function 'of_get_next_parent'; did you mean 'of_get_parent'? [-Werror=implicit-function-declaration]
    5196 |     np_spi = of_get_next_parent(np);
         |              ^~~~~~~~~~~~~~~~~~
         |              of_get_parent
>> drivers/mtd/spi-nor/spi-nor.c:5196:12: warning: assignment to 'struct device_node *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
    5196 |     np_spi = of_get_next_parent(np);
         |            ^
   drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_get_flash_info':
   drivers/mtd/spi-nor/spi-nor.c:5266:11: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    5266 |    return jinfo;
         |           ^~~~~
   drivers/mtd/spi-nor/spi-nor.c:5281:9: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    5281 |  return info;
         |         ^~~~
   drivers/mtd/spi-nor/spi-nor.c: In function 'spi_nor_scan':
   drivers/mtd/spi-nor/spi-nor.c:5295:6: warning: unused variable 'is_dual' [-Wunused-variable]
    5295 |  u32 is_dual;
         |      ^~~~~~~
   drivers/mtd/spi-nor/spi-nor.c:5294:22: warning: unused variable 'np_spi' [-Wunused-variable]
    5294 |  struct device_node *np_spi;
         |                      ^~~~~~
   At top level:
   drivers/mtd/spi-nor/spi-nor.c:781:12: warning: 'read_ear' defined but not used [-Wunused-function]
     781 | static int read_ear(struct spi_nor *nor, struct flash_info *info)
         |            ^~~~~~~~
   cc1: some warnings being treated as errors


vim +5196 drivers/mtd/spi-nor/spi-nor.c

  5162	
  5163	static int spi_nor_set_addr_width(struct spi_nor *nor)
  5164	{
  5165		struct device_node *np = spi_nor_get_flash_node(nor);
  5166		struct device_node *np_spi;
  5167		if (nor->addr_width) {
  5168			/* already configured from SFDP */
  5169		} else if (nor->info->addr_width) {
  5170			nor->addr_width = nor->info->addr_width;
  5171		} else if (nor->mtd.size > 0x1000000) {
  5172	#ifdef CONFIG_OF
  5173			np_spi = of_get_next_parent(np);
  5174			if (of_property_match_string(np_spi, "compatible",
  5175						     "xlnx,zynq-qspi-1.0") >= 0) {
  5176				int status;
  5177	
  5178				nor->addr_width = 3;
  5179				nor->params.set_4byte(nor, false);
  5180				status = read_ear(nor, (struct flash_info *)nor->info);
  5181				if (status < 0)
  5182					dev_warn(nor->dev, "failed to read ear reg\n");
  5183				else
  5184					nor->curbank = status & EAR_SEGMENT_MASK;
  5185			} else {
  5186	#endif
  5187				/*
  5188				 * enable 4-byte addressing if the
  5189				 * device exceeds 16MiB
  5190				 */
  5191				nor->addr_width = 4;
  5192				if (JEDEC_MFR(nor->info) == SNOR_MFR_SPANSION ||
  5193				    nor->info->flags & SPI_NOR_4B_OPCODES) {
  5194					spi_nor_set_4byte_opcodes(nor);
  5195				} else {
> 5196					np_spi = of_get_next_parent(np);
  5197					if (of_property_match_string(np_spi,
  5198								     "compatible",
  5199								     "xlnx,xps-spi-2.00.a") >= 0) {
  5200						nor->addr_width = 3;
  5201						nor->params.set_4byte(nor, false);
  5202					} else {
  5203						nor->params.set_4byte(nor, true);
  5204						if (nor->isstacked) {
  5205							nor->spi->master->flags |=
  5206								SPI_MASTER_U_PAGE;
  5207							nor->params.set_4byte(nor, true);
  5208							nor->spi->master->flags &=
  5209								~SPI_MASTER_U_PAGE;
  5210						}
  5211					}
  5212				}
  5213	#ifdef CONFIG_OF
  5214			}
  5215	#endif
  5216		} else {
  5217			nor->addr_width = 3;
  5218		}
  5219	
  5220		if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
  5221			dev_err(nor->dev, "address width is too large: %u\n",
  5222				nor->addr_width);
  5223			return -EINVAL;
  5224		}
  5225	
  5226		/* Set 4byte opcodes when possible. */
  5227		if (nor->addr_width == 4 && nor->flags & SNOR_F_4B_OPCODES &&
  5228		    !(nor->flags & SNOR_F_HAS_4BAIT))
  5229			spi_nor_set_4byte_opcodes(nor);
  5230	
  5231		return 0;
  5232	}
  5233	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 26669 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210401/3c6da4ed/attachment-0001.gz>

From claudiu.beznea at microchip.com  Thu Apr  1 13:27:26 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 1 Apr 2021 15:27:26 +0300
Subject: [PATCH v2 6/6] clk: at91: clk-master: improve readability by using
 local variables
In-Reply-To: <20210401122726.28528-1-claudiu.beznea@microchip.com>
References: <20210401122726.28528-1-claudiu.beznea@microchip.com>
Message-ID: <20210401122726.28528-7-claudiu.beznea@microchip.com>

Improve readability in clk_sama7g5_master_set() by using local
variables.

Suggested-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 drivers/clk/at91/clk-master.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 1b2962289629..76b2467b32dc 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -720,6 +720,8 @@ static void clk_sama7g5_master_set(struct clk_master *master,
 	unsigned long flags;
 	unsigned int val, cparent;
 	unsigned int enable = status ? AT91_PMC_MCR_V2_EN : 0;
+	unsigned int parent = master->parent << PMC_MCR_CSS_SHIFT;
+	unsigned int div = master->div << MASTER_DIV_SHIFT;
 
 	spin_lock_irqsave(master->lock, flags);
 
@@ -729,9 +731,7 @@ static void clk_sama7g5_master_set(struct clk_master *master,
 	regmap_update_bits(master->regmap, AT91_PMC_MCR_V2,
 			   enable | AT91_PMC_MCR_V2_CSS | AT91_PMC_MCR_V2_DIV |
 			   AT91_PMC_MCR_V2_CMD | AT91_PMC_MCR_V2_ID_MSK,
-			   enable | (master->parent << PMC_MCR_CSS_SHIFT) |
-			   (master->div << MASTER_DIV_SHIFT) |
-			   AT91_PMC_MCR_V2_CMD |
+			   enable | parent | div | AT91_PMC_MCR_V2_CMD |
 			   AT91_PMC_MCR_V2_ID(master->id));
 
 	cparent = (val & AT91_PMC_MCR_V2_CSS) >> PMC_MCR_CSS_SHIFT;
-- 
2.25.1



From catalin.marinas at arm.com  Thu Apr  1 13:37:04 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  1 Apr 2021 13:37:04 +0100
Subject: [PATCH -next] docs: arm64: Fix a grammar error
In-Reply-To: <20210330085817.86185-1-heying24@huawei.com>
References: <20210330085817.86185-1-heying24@huawei.com>
Message-ID: <161728062026.15531.9076497905075968278.b4-ty@arm.com>

On Tue, 30 Mar 2021 04:58:17 -0400, He Ying wrote:
> depending -> depending on

Applied to arm64 (for-next/misc), thanks!

[1/1] docs: arm64: Fix a grammar error
      https://git.kernel.org/arm64/c/68f638a432df

-- 
Catalin



From lkp at intel.com  Thu Apr  1 13:46:29 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 1 Apr 2021 20:46:29 +0800
Subject: [xlnx:xlnx_rebase_v5.4 903/1701]
 include/linux/usb/xhci_pdriver.h:22:6: warning: no previous prototype for
 'dwc3_host_wakeup_capable'
Message-ID: <202104012027.TJfD0n8e-lkp@intel.com>

Hi Michal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 6d0468b837bc2b3cce625f59904d137e63637b5d [903/1701] usb: dwc3: Add support for clock disabling during suspend
config: xtensa-randconfig-r036-20210401 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/6d0468b837bc2b3cce625f59904d137e63637b5d
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 6d0468b837bc2b3cce625f59904d137e63637b5d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=xtensa 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from ./arch/xtensa/include/generated/asm/bug.h:1,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:12,
                    from arch/xtensa/include/asm/current.h:18,
                    from include/linux/mutex.h:14,
                    from include/linux/notifier.h:14,
                    from include/linux/clk.h:14,
                    from drivers/usb/host/xhci-plat.c:11:
   include/linux/dma-mapping.h: In function 'dma_map_resource':
   arch/xtensa/include/asm/page.h:182:9: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
     182 |  ((pfn) >= ARCH_PFN_OFFSET && ((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
         |         ^~
   include/asm-generic/bug.h:139:27: note: in definition of macro 'WARN_ON_ONCE'
     139 |  int __ret_warn_once = !!(condition);   \
         |                           ^~~~~~~~~
   include/linux/dma-mapping.h:355:19: note: in expansion of macro 'pfn_valid'
     355 |  if (WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr))))
         |                   ^~~~~~~~~
   In file included from drivers/usb/host/xhci-plat.c:23:
   include/linux/usb/xhci_pdriver.h: At top level:
>> include/linux/usb/xhci_pdriver.h:22:6: warning: no previous prototype for 'dwc3_host_wakeup_capable' [-Wmissing-prototypes]
      22 | void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~


vim +/dwc3_host_wakeup_capable +22 include/linux/usb/xhci_pdriver.h

    20	
    21	#else
  > 22	void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
    23	{ ; }
    24	#endif
    25	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18742 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210401/9b2655a1/attachment-0001.gz>

From bgolaszewski at baylibre.com  Thu Apr  1 13:51:36 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Thu, 1 Apr 2021 14:51:36 +0200
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <CACG_h5q6P5NiNByttQ-NZvq8x3GCTKfSU=Yyywk7PcO6_=i2Mw@mail.gmail.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <36db7be3-73b6-c822-02e8-13e3864b0463@xilinx.com>
 <CAMpxmJUv0iU0Ntmks1f6ThDAG6x_eJLYYCaDSjy+1Syedzc5dQ@mail.gmail.com>
 <DM6PR02MB53863852A28F782B0942ECD8AF7C9@DM6PR02MB5386.namprd02.prod.outlook.com>
 <CACG_h5q6P5NiNByttQ-NZvq8x3GCTKfSU=Yyywk7PcO6_=i2Mw@mail.gmail.com>
Message-ID: <CAMpxmJUO48Aor0zSofOPJgtKJPL-DKe01a=FOd-Aqz-OHYeZOg@mail.gmail.com>

On Thu, Apr 1, 2021 at 1:16 PM Syed Nayyar Waris <syednwaris at gmail.com> wrote:
>
> On Wed, Mar 31, 2021 at 8:56 PM Srinivas Neeli <sneeli at xilinx.com> wrote:
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > > Sent: Friday, March 26, 2021 10:58 PM
> > > To: Michal Simek <michals at xilinx.com>
> > > Cc: Syed Nayyar Waris <syednwaris at gmail.com>; Srinivas Neeli
> > > <sneeli at xilinx.com>; Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com>; William Breathitt Gray
> > > <vilhelm.gray at gmail.com>; Arnd Bergmann <arnd at arndb.de>; Robert
> > > Richter <rrichter at marvell.com>; Linus Walleij <linus.walleij at linaro.org>;
> > > Masahiro Yamada <yamada.masahiro at socionext.com>; Andrew Morton
> > > <akpm at linux-foundation.org>; Zhang Rui <rui.zhang at intel.com>; Daniel
> > > Lezcano <daniel.lezcano at linaro.org>; Amit Kucheria
> > > <amit.kucheria at verdurent.com>; Linux-Arch <linux-arch at vger.kernel.org>;
> > > linux-gpio <linux-gpio at vger.kernel.org>; LKML <linux-
> > > kernel at vger.kernel.org>; arm-soc <linux-arm-kernel at lists.infradead.org>;
> > > linux-pm <linux-pm at vger.kernel.org>; Srinivas Goud <sgoud at xilinx.com>
> > > Subject: Re: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
> > > _set_value
> > >
> > > On Mon, Mar 8, 2021 at 8:13 AM Michal Simek <michal.simek at xilinx.com>
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 3/6/21 3:06 PM, Syed Nayyar Waris wrote:
> > > > > This patch reimplements the xgpio_set_multiple() function in
> > > > > drivers/gpio/gpio-xilinx.c to use the new generic functions:
> > > > > bitmap_get_value() and bitmap_set_value(). The code is now simpler
> > > > > to read and understand. Moreover, instead of looping for each bit in
> > > > > xgpio_set_multiple() function, now we can check each channel at a
> > > > > time and save cycles.
> > > > >
> > > > > Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > > > > Cc: Michal Simek <michal.simek at xilinx.com>
> > > > > Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> > > > > Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> > > > > ---
> > > > >  drivers/gpio/gpio-xilinx.c | 63
> > > > > +++++++++++++++++++-------------------
> > > > >  1 file changed, 32 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> > > > > index be539381fd82..8445e69cf37b 100644
> > > > > --- a/drivers/gpio/gpio-xilinx.c
> > > > > +++ b/drivers/gpio/gpio-xilinx.c
> > > > > @@ -15,6 +15,7 @@
> > > > >  #include <linux/of_device.h>
> > > > >  #include <linux/of_platform.h>
> > > > >  #include <linux/slab.h>
> > > > > +#include "gpiolib.h"
> > > > >
> > > > >  /* Register Offset Definitions */
> > > > >  #define XGPIO_DATA_OFFSET   (0x0)    /* Data register  */
> > > > > @@ -141,37 +142,37 @@ static void xgpio_set_multiple(struct
> > > > > gpio_chip *gc, unsigned long *mask,  {
> > > > >       unsigned long flags;
> > > > >       struct xgpio_instance *chip = gpiochip_get_data(gc);
> > > > > -     int index = xgpio_index(chip, 0);
> > > > > -     int offset, i;
> > > > > -
> > > > > -     spin_lock_irqsave(&chip->gpio_lock[index], flags);
> > > > > -
> > > > > -     /* Write to GPIO signals */
> > > > > -     for (i = 0; i < gc->ngpio; i++) {
> > > > > -             if (*mask == 0)
> > > > > -                     break;
> > > > > -             /* Once finished with an index write it out to the register */
> > > > > -             if (index !=  xgpio_index(chip, i)) {
> > > > > -                     xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > > -                                    index * XGPIO_CHANNEL_OFFSET,
> > > > > -                                    chip->gpio_state[index]);
> > > > > -                     spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
> > > > > -                     index =  xgpio_index(chip, i);
> > > > > -                     spin_lock_irqsave(&chip->gpio_lock[index], flags);
> > > > > -             }
> > > > > -             if (__test_and_clear_bit(i, mask)) {
> > > > > -                     offset =  xgpio_offset(chip, i);
> > > > > -                     if (test_bit(i, bits))
> > > > > -                             chip->gpio_state[index] |= BIT(offset);
> > > > > -                     else
> > > > > -                             chip->gpio_state[index] &= ~BIT(offset);
> > > > > -             }
> > > > > -     }
> > > > > -
> > > > > -     xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > > -                    index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> > > > > -
> > > > > -     spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
> > > > > +     u32 *const state = chip->gpio_state;
> > > > > +     unsigned int *const width = chip->gpio_width;
> > > > > +
> > > > > +     DECLARE_BITMAP(old, 64);
> > > > > +     DECLARE_BITMAP(new, 64);
> > > > > +     DECLARE_BITMAP(changed, 64);
> > > > > +
> > > > > +     spin_lock_irqsave(&chip->gpio_lock[0], flags);
> > > > > +     spin_lock(&chip->gpio_lock[1]);
> > > > > +
> > > > > +     bitmap_set_value(old, 64, state[0], width[0], 0);
> > > > > +     bitmap_set_value(old, 64, state[1], width[1], width[0]);
> > > > > +     bitmap_replace(new, old, bits, mask, gc->ngpio);
> > > > > +
> > > > > +     bitmap_set_value(old, 64, state[0], 32, 0);
> > > > > +     bitmap_set_value(old, 64, state[1], 32, 32);
> > > > > +     state[0] = bitmap_get_value(new, 0, width[0]);
> > > > > +     state[1] = bitmap_get_value(new, width[0], width[1]);
> > > > > +     bitmap_set_value(new, 64, state[0], 32, 0);
> > > > > +     bitmap_set_value(new, 64, state[1], 32, 32);
> > > > > +     bitmap_xor(changed, old, new, 64);
> > > > > +
> > > > > +     if (((u32 *)changed)[0])
> > > > > +             xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,
> > > > > +                             state[0]);
> > > > > +     if (((u32 *)changed)[1])
> > > > > +             xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> > > > > +                             XGPIO_CHANNEL_OFFSET, state[1]);
> > > > > +
> > > > > +     spin_unlock(&chip->gpio_lock[1]);
> > > > > +     spin_unlock_irqrestore(&chip->gpio_lock[0], flags);
> > > > >  }
> > > > >
> > > > >  /**
> > > > >
> > > >
> > > > Srinivas N: Can you please test this code?
> > > >
> > > > Thanks,
> > > > Michal
> > >
> > > Hey, any chance of getting that Tested-by?
> > I tested patches with few modifications in code (spin_lock handling and merge conflict).
> > functionality wise it's working fine.
> >
> > >
> > > Bart
>
> Hi Bartosz,
>
> May I please know the URL of the tree that you are using. I had been
> using the tree below for submitting this patchset on GPIO to you.
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
>
> I think I am using the wrong tree. On which tree should I base my
> patches on for my next  (v4) submission? Should I use the tree below?
> :
> https://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git
>
> Regards
> Syed Nayyar Waris

Yes this is the one. Please address new issues raised by reviewers.

Bart


From broonie at kernel.org  Thu Apr  1 13:49:36 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 13:49:36 +0100
Subject: [PATCH] arm64: Disable fine grained traps on boot
Message-ID: <20210401124936.56877-1-broonie@kernel.org>

The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
to small sets of registers and instructions from EL1 and EL0.  Currently
Linux makes no use of this feature, ensure that it is not active at boot by
disabling the traps during EL2 setup.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/el2_setup.h | 21 +++++++++++++++++++++
 arch/arm64/include/asm/sysreg.h    |  6 ++++++
 2 files changed, 27 insertions(+)

diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index d77d358f9395..f94ef3a76877 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -131,6 +131,26 @@
 .Lskip_sve_\@:
 .endm
 
+/* Disable any fine grained traps */
+.macro __init_el2_fgt
+	mrs	x1, id_aa64mmfr0_el1
+	ubfx	x1, x1, #ID_AA64MMFR0_FGT_SHIFT, #4
+	cbz	x1, .Lskip_fgt_\@
+
+	msr_s	SYS_HDFGRTR_EL2, xzr
+	msr_s	SYS_HDFGWTR_EL2, xzr
+	msr_s	SYS_HFGRTR_EL2, xzr
+	msr_s	SYS_HFGITR_EL2, xzr
+	msr_s	SYS_HFGWTR_EL2, xzr
+
+	mrs	x1, id_aa64pfr0_el1		// AMU traps UNDEF without AMU
+	ubfx	x1, x1, #ID_AA64PFR0_AMU_SHIFT, #4
+	cbz	x1, .Lskip_fgt_\@
+
+	msr_s	SYS_HAFGRTR_EL2, xzr
+.Lskip_fgt_\@:
+.endm
+
 .macro __init_el2_nvhe_prepare_eret
 	mov	x0, #INIT_PSTATE_EL1
 	msr	spsr_el2, x0
@@ -155,6 +175,7 @@
 	__init_el2_nvhe_idregs
 	__init_el2_nvhe_cptr
 	__init_el2_nvhe_sve
+	__init_el2_fgt
 	__init_el2_nvhe_prepare_eret
 .endm
 
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..b35468927363 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -475,9 +475,15 @@
 #define SYS_PMCCFILTR_EL0		sys_reg(3, 3, 14, 15, 7)
 
 #define SYS_SCTLR_EL2			sys_reg(3, 4, 1, 0, 0)
+#define SYS_HFGRTR_EL2			sys_reg(3, 4, 1, 1, 4)
+#define SYS_HFGWTR_EL2			sys_reg(3, 4, 1, 1, 5)
+#define SYS_HFGITR_EL2			sys_reg(3, 4, 1, 1, 6)
 #define SYS_ZCR_EL2			sys_reg(3, 4, 1, 2, 0)
 #define SYS_TRFCR_EL2			sys_reg(3, 4, 1, 2, 1)
 #define SYS_DACR32_EL2			sys_reg(3, 4, 3, 0, 0)
+#define SYS_HDFGRTR_EL2			sys_reg(3, 4, 3, 1, 4)
+#define SYS_HDFGWTR_EL2			sys_reg(3, 4, 3, 1, 5)
+#define SYS_HAFGRTR_EL2			sys_reg(3, 4, 3, 1, 6)
 #define SYS_SPSR_EL2			sys_reg(3, 4, 4, 0, 0)
 #define SYS_ELR_EL2			sys_reg(3, 4, 4, 0, 1)
 #define SYS_IFSR32_EL2			sys_reg(3, 4, 5, 0, 1)
-- 
2.20.1



From daniel at zonque.org  Thu Apr  1 13:50:07 2021
From: daniel at zonque.org (Daniel Mack)
Date: Thu, 1 Apr 2021 14:50:07 +0200
Subject: [PATCH] ARM: configs: Remove REGULATOR_USERSPACE_CONSUMER
In-Reply-To: <20210401102858.4095-1-broonie@kernel.org>
References: <20210401102858.4095-1-broonie@kernel.org>
Message-ID: <7ee9fcd3-e4ed-1edf-4ac5-0bcb26ab4d2a@zonque.org>

On 4/1/21 12:28 PM, Mark Brown wrote:
> The userspace consumer is a development tool, not intended for producton
> systems and so should not be present in defconfigs especially not those
> for specific machines so is not a good fit for defconfig, remove it from
> those defconfigs where it is enabled. No system in mainline actually
> instantiates one.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm/configs/ezx_defconfig    | 1 -
>  arch/arm/configs/imote2_defconfig | 1 -
>  arch/arm/configs/pxa_defconfig    | 1 -

Acked-by: Daniel Mack <daniel at zonque.org>



>  3 files changed, 3 deletions(-)
> 
> diff --git a/arch/arm/configs/ezx_defconfig b/arch/arm/configs/ezx_defconfig
> index 81665b7abf83..a49e699e52de 100644
> --- a/arch/arm/configs/ezx_defconfig
> +++ b/arch/arm/configs/ezx_defconfig
> @@ -213,7 +213,6 @@ CONFIG_POWER_SUPPLY=y
>  CONFIG_EZX_PCAP=y
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_DEBUG=y
> -CONFIG_REGULATOR_USERSPACE_CONSUMER=y
>  CONFIG_REGULATOR_PCAP=y
>  CONFIG_MEDIA_SUPPORT=y
>  CONFIG_VIDEO_DEV=y
> diff --git a/arch/arm/configs/imote2_defconfig b/arch/arm/configs/imote2_defconfig
> index ae15a2a33802..118c4c927f26 100644
> --- a/arch/arm/configs/imote2_defconfig
> +++ b/arch/arm/configs/imote2_defconfig
> @@ -194,7 +194,6 @@ CONFIG_POWER_SUPPLY=y
>  CONFIG_PMIC_DA903X=y
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_DEBUG=y
> -CONFIG_REGULATOR_USERSPACE_CONSUMER=y
>  CONFIG_REGULATOR_DA903X=y
>  CONFIG_MEDIA_SUPPORT=y
>  CONFIG_VIDEO_DEV=y
> diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
> index bd7dd81c9c54..875a3c28a267 100644
> --- a/arch/arm/configs/pxa_defconfig
> +++ b/arch/arm/configs/pxa_defconfig
> @@ -415,7 +415,6 @@ CONFIG_MFD_TC6393XB=y
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_DEBUG=y
>  CONFIG_REGULATOR_FIXED_VOLTAGE=m
> -CONFIG_REGULATOR_USERSPACE_CONSUMER=m
>  CONFIG_REGULATOR_ACT8865=m
>  CONFIG_REGULATOR_AS3711=m
>  CONFIG_REGULATOR_AXP20X=m
> 



From liuyongqiang13 at huawei.com  Thu Apr  1 14:15:33 2021
From: liuyongqiang13 at huawei.com (Yongqiang Liu)
Date: Thu, 1 Apr 2021 13:15:33 +0000
Subject: [PATCH -next] ARM: OMAP2+: Fix build warning when mmc_omap is not
 built
Message-ID: <20210401131533.998767-1-liuyongqiang13@huawei.com>

GCC reports the following warning with W=1:

arch/arm/mach-omap2/board-n8x0.c:325:19: warning:
variable 'index' set but not used [-Wunused-but-set-variable]
325 |  int bit, *openp, index;
    |                   ^~~~~

Fix this by moving CONFIG_MMC_OMAP to cover the rest codes
in the n8x0_mmc_callback().

Signed-off-by: Yongqiang Liu <liuyongqiang13 at huawei.com>
---
 arch/arm/mach-omap2/board-n8x0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 418a61ecb827..5e86145db0e2 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -322,6 +322,7 @@ static int n8x0_mmc_get_cover_state(struct device *dev, int slot)
 
 static void n8x0_mmc_callback(void *data, u8 card_mask)
 {
+#ifdef CONFIG_MMC_OMAP
 	int bit, *openp, index;
 
 	if (board_is_n800()) {
@@ -339,7 +340,6 @@ static void n8x0_mmc_callback(void *data, u8 card_mask)
 	else
 		*openp = 0;
 
-#ifdef CONFIG_MMC_OMAP
 	omap_mmc_notify_cover_event(mmc_device, index, *openp);
 #else
 	pr_warn("MMC: notify cover event not available\n");
-- 
2.25.1



From lkp at intel.com  Thu Apr  1 14:15:26 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 1 Apr 2021 21:15:26 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1296/1701] drivers/usb/dwc3/core.h:1462:
 multiple definition of `dwc3_simple_wakeup_capable';
 drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1462: first defined here
Message-ID: <202104012116.AsNc8bnG-lkp@intel.com>

Hi Vishal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 0b197959bbbdb68e1da974bd013339f08704b178 [1296/1701] staging: xlnxsync: Fix the uapi header license
config: i386-randconfig-a013-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/0b197959bbbdb68e1da974bd013339f08704b178
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 0b197959bbbdb68e1da974bd013339f08704b178
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_wakeup_capable':
>> drivers/usb/dwc3/core.h:1462: multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1462: first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_check_quirks':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_usb_core_power':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_mask_phy_reset':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_wakeup_capable':
   drivers/usb/dwc3/host.c:19: multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1462: first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_check_quirks':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_usb_core_power':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_mask_phy_reset':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_wakeup_capable':
>> drivers/usb/dwc3/core.h:1462: multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1462: first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_check_quirks':
>> drivers/usb/dwc3/core.h:1464: multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1464: first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_usb_core_power':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_mask_phy_reset':
>> drivers/usb/dwc3/core.h:1468: multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1468: first defined here


vim +1462 drivers/usb/dwc3/core.h

c4137a9c841ec7 John Youn    2016-02-05  1450  
6d0468b837bc2b Michal Simek 2020-03-16  1451  #if IS_ENABLED(CONFIG_USB_DWC3_OF_SIMPLE)
8110b9b0dcabf1 Michal Simek 2020-03-16  1452  int dwc3_enable_hw_coherency(struct device *dev);
6d0468b837bc2b Michal Simek 2020-03-16  1453  void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup);
3d600fd776cbda Michal Simek 2020-03-16  1454  void dwc3_set_simple_data(struct dwc3 *dwc);
782658c51bbcd8 Piyush Mehta 2020-01-23  1455  void dwc3_simple_check_quirks(struct dwc3 *dwc);
68a922ded3cde2 Piyush Mehta 2020-01-23  1456  int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on);
128feece434d1c Piyush Mehta 2020-01-23  1457  void dwc3_mask_phy_reset(struct device *dev, bool mask);
6d0468b837bc2b Michal Simek 2020-03-16  1458  #else
8110b9b0dcabf1 Michal Simek 2020-03-16  1459  static inline int dwc3_enable_hw_coherency(struct device *dev)
8110b9b0dcabf1 Michal Simek 2020-03-16  1460  { return 1; }
6d0468b837bc2b Michal Simek 2020-03-16  1461  void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
6d0468b837bc2b Michal Simek 2020-03-16 @1462  { ; }
3d600fd776cbda Michal Simek 2020-03-16  1463  void dwc3_set_simple_data(struct dwc3 *dwc)
3d600fd776cbda Michal Simek 2020-03-16 @1464  { ; }
782658c51bbcd8 Piyush Mehta 2020-01-23  1465  void dwc3_simple_check_quirks(struct dwc3 *dwc)
782658c51bbcd8 Piyush Mehta 2020-01-23  1466  { ; }
68a922ded3cde2 Piyush Mehta 2020-01-23  1467  int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
68a922ded3cde2 Piyush Mehta 2020-01-23 @1468  { ; }
128feece434d1c Piyush Mehta 2020-01-23  1469  void dwc3_mask_phy_reset(struct device *dev, bool mask)
128feece434d1c Piyush Mehta 2020-01-23  1470  { ; }
6d0468b837bc2b Michal Simek 2020-03-16  1471  #endif
6d0468b837bc2b Michal Simek 2020-03-16  1472  

:::::: The code at line 1462 was first introduced by commit
:::::: 6d0468b837bc2b3cce625f59904d137e63637b5d usb: dwc3: Add support for clock disabling during suspend

:::::: TO: Michal Simek <michal.simek at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30765 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210401/bf77b9e9/attachment-0001.gz>

From marcan at marcan.st  Thu Apr  1 14:16:30 2021
From: marcan at marcan.st (Hector Martin)
Date: Thu, 1 Apr 2021 22:16:30 +0900
Subject: [RFT PATCH v3 16/27] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <20210329120442.GA3636@willie-the-truck>
References: <20210304213902.83903-1-marcan@marcan.st>
 <20210304213902.83903-17-marcan@marcan.st>
 <20210324195742.GA13474@willie-the-truck>
 <3564ed98-6ad6-7ddd-01d2-36d7f5af90e0@marcan.st>
 <20210329120442.GA3636@willie-the-truck>
Message-ID: <5ff8eef3-6943-d3c8-cd6f-3dcb44158fab@marcan.st>

Hi Will,

On 29/03/2021 21.04, Will Deacon wrote:
>> One CPU still needs to be able to mutate the flags of another CPU to fire an
>> IPI; AIUI the per-cpu ops are *not* atomic for concurrent access by multiple
>> CPUs, and in fact there is no API for that, only for "this CPU".
> 
> Huh, I really thought we had an API for that, but you're right. Oh well! But
> I'd still suggest a per-cpu atomic_t in that case, rather than the array.

Yeah, after digging into the per-cpu stuff earlier and understanding how 
it works, I agree that a per-cpu atomic makes sense here. Switched it to 
that (which simplified out a bunch of smp_processor_id() calls too). Thanks!

>>> I think a more idiomatic (and portable) way to do this would be to use
>>> the relaxed accessors, but with smp_mb__after_atomic() between them. Do you
>>> have a good reason for _not_ doing it like that?
>>
>> Not particularly, other than symmetry with the case below.
> 
> I think it would be better not to rely on arm64-specific ordering unless
> there's a good reason to.

Sounds reasonable, I'll switch to the barrier version.

>> We do need the return data here, and the release semantics (or another
>> barrier before it). But the read below can be made relaxed and a barrier
>> used instead, and then the same patern above except with a plain
>> atomic_or().
> 
> Yes, I think using atomic_fetch_or() followed by atomic_read() would be
> best (obviously with the relevant comments!)

atomic_fetch_or_release is sufficient here (atomic_fetch_or is stronger; 
atomic_fetch_or_relaxed would not be strong enough as this needs to be 
ordered after any writes prior to sending the IPI; in this case release 
semantics also make logical sense).

>> It is ordered, right? As the comment says, it "needs to be ordered after the
>> aic_ic_write() above". atomic_fetch_andnot() is *supposed* to be fully
>> ordered and that should include against the writel_relaxed() on
>> AIC_IPI_FLAG. On ARM it turns out it's not quite fully ordered, but the
>> acquire semantics of the read half are sufficient for this case, as they
>> guarantee the flags are always read after the FIQ has been ACKed.
> 
> Sorry, I missed that the answer to my question was already written in the
> comment. However, I'm still a bit unsure about whether the memory barriers
> give you what you need here. The barrier in atomic_fetch_andnot() will
> order the previous aic_ic_write(AIC_IPI_ACK) for the purposes of other
> CPUs reading those locations, but it doesn't say anything about when the
> interrupt controller actually changes state after the Ack.
> 
> Given that the AIC is mapped Device-nGnRnE, the Arm ARM offers:
> 
>    | Additionally, for Device-nGnRnE memory, a read or write of a Location
>    | in a Memory-mapped peripheral that exhibits side-effects is complete
>    | only when the read or write both:
>    |
>    | * Can begin to affect the state of the Memory-mapped peripheral.
>    | * Can trigger all associated side-effects, whether they affect other
>    |   peripheral devices, PEs, or memory.
> 
> so without AIC documentation I can't tell whether completion of the Ack write
> just begins the process of an Ack (in which case we might need something like
> a read-back), or whether the write response back from the AIC only occurs once
> the Ack has taken effect. Any ideas?

Ahh, you're talking about latency within AIC itself... I obviously don't 
have an authoritative answer to this, though the hardware designer in me 
wants to say this really ought to be single-cycle type stuff that isn't 
internally pipelined in a way that would create races.

I tried to set up an SMP test case for the atomic-to-AIC sequence in 
m1n1, but unfortunately I couldn't hit the race window in deliberately 
racy code (i.e. ack after clearing flags) without widening it even 
further with at least one dummy load in between, and of course I didn't 
experience any races with the proper code either.

What I can say is that a simple set IPI; ack IPI (in adjacent str 
instructions) sequence always yields a cleared IPI, and the converse 
always yields a set IPI. So if there is latency to the operations it 
seems it would at least be the same for sets and acks and would imply 
readbacks block, which should still yield equivalently correct results. 
But of course this is a single-CPU test, so it is not fully 
representative of what could happen in an SMP scenario.

At this point all I can say is I'm inclined to shrug and say we have no 
evidence of this being something that can happen, and it shouldn't in 
sane hardware, and hope for the best :-)

Thanks,
-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From cristian.ciocaltea at gmail.com  Thu Apr  1 14:19:05 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 16:19:05 +0300
Subject: [PATCH v2 0/6] Add support for Actions Semi Owl socinfo
In-Reply-To: <20210401110752.GG14052@work>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401052438.GB14052@work> <20210401094041.GA1993499@BV030612LT>
 <20210401102717.GF14052@work>
 <252dd954-c8f1-fa2a-c37a-ede386fc9d43@suse.de>
 <20210401105805.GA1998829@BV030612LT> <20210401110752.GG14052@work>
Message-ID: <20210401131905.GA2001688@BV030612LT>

On Thu, Apr 01, 2021 at 04:37:52PM +0530, Manivannan Sadhasivam wrote:
> + Matheus
> 
> On Thu, Apr 01, 2021 at 01:58:05PM +0300, Cristian Ciocaltea wrote:
> > Hi Mani, Andreas,
> > 
> > On Thu, Apr 01, 2021 at 12:49:37PM +0200, Andreas F?rber wrote:
> > > Hi,
> > > 
> > > On 01.04.21 12:27, Manivannan Sadhasivam wrote:
> > > > On Thu, Apr 01, 2021 at 12:40:41PM +0300, Cristian Ciocaltea wrote:
> > > >> On Thu, Apr 01, 2021 at 10:54:38AM +0530, Manivannan Sadhasivam wrote:
> > > >>> On Tue, Mar 30, 2021 at 04:48:15PM +0300, Cristian Ciocaltea wrote:
> > > >>>> This patchset adds a socinfo driver which provides information about
> > > >>>> Actions Semi Owl SoCs to user space via sysfs: machine, family, soc_id,
> > > >>>> serial_number.
> > > >>>>
> > > >>>> Please note the serial number is currently available only for the S500
> > > >>>> SoC variant.
> > > >>>>
> > > >>>> This has been tested on the S500 SoC based RoseapplePi SBC.
> > > >>>>
> > > >>>
> > > >>> Is this the soc_id provided by the vendor bootloader (uboot)? If so, under
> > > >>> what basis it provides? I don't think the SoC has the provision for
> > > >>> soc_id based on HW parameters.
> > > >>
> > > >> No, the soc_id is not provided by the bootloader, or at least I couldn't
> > > >> identify any related implementation. Instead, I provided this via the
> > > >> driver itself, since I've encountered this approach in some other soc
> > > >> drivers as well (e.g. imx/soc-imx.c, versatile/soc-integrator.c). 
> > > >>
> > > > 
> > > > Sorry, I was referring to serial_number. Since your comment says so, can
> > > > you point to the corresponding code?
> > > 
> > > Seconded that this needs to be better understood. If this is just a
> > > convention of some downstream U-Boot that's not implemented in mainline
> > > (and maybe not even for Guitar or Labrador? tested on RoseapplePi only),
> > > it might not be worth its own reserved-memory based kernel driver?
> > 
> > The serial number is actually provided by the s500-bootloader for which
> > Actions did not provide the source code, at least it is not available
> > in the xapp github repo. I did not find anything related to this in
> > downstream U-Boot.
> > 
> 
> Hmm, then we can consider this as the firmware dependent property. But
> can we get consensus that this is common for all S500 SoCs?

This should work on all S500 SoCs, as the downstream Linux kernel doesn't
use any conditional logic around reading those memory locations.
Please see "owl_check_revision()" in arch/arm/mach-owl/board-owl.c, from
any of the following repos:

* https://github.com/xapp-le/kernel
* https://github.com/LeMaker/linux-actions

> Maybe,
> Matheus can verify it on Labrador?

The verification is pretty straightforward: the serial number is dumped
on the serial console by the s500 bootloader right before starting
U-boot:

  load uboot: load address is 0x8000000, entry point is 0x8000040
  in fourth
  chip serial no = 9d,4b,f,6d,31,46,e,8,
  [...]
  U-Boot 2015.04 (Apr 23 2020 - 23:01:25)Actions-Semi

The socinfo driver should provide the equivalent information, but in
reversed order (due to integer representation on LE arch):

  $ cat /sys/devices/soc0/serial_number
  080e46316d0f4b9d

> I don't think adding a SOCINFO driver for a single board is a good idea.

The driver could be used for all Owl SoC variants, including S700 and
S900, even though accessing the serial number is currently supported
only on S500.

Unfortunately I do only have this S500 SoC based SBC to experiment with,
therefore I cannot enable new features for the hardware I'm not able to
validate.

Btw, do you know where I could get an S700 or S900 board from? I
couldn't find any so far..

Thanks,
Cristi

> Thanks,
> Mani
> 
> > Kind regards,
> > Cristi
> > 
> > > Implementing a standard interface such as DMI tables or a DT property in
> > > mainline U-Boot may be more useful then. Is it still Mani's S900 only?
> > > 
> > > Regards,
> > > Andreas
> > > 
> > > -- 
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 N?rnberg, Germany
> > > GF: Felix Imend?rffer
> > > HRB 36809 (AG N?rnberg)


From will at kernel.org  Thu Apr  1 14:26:58 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 14:26:58 +0100
Subject: [PATCH 16/18] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
In-Reply-To: <20210401095945.GA6726@lst.de>
References: <20210316153825.135976-17-hch@lst.de>
 <20210330131149.GP5908@willie-the-truck>
 <a6952aa7-4d7e-54f0-339e-e15f88596dcc@arm.com>
 <20210330135801.GA6187@willie-the-truck>
 <578d6aa5-4239-f5d7-2e9f-686b18e52bba@arm.com>
 <20210331114947.GA7626@willie-the-truck>
 <ef895942-e115-7878-ab86-37e8a1614df5@arm.com>
 <20210331153256.GA7815@willie-the-truck>
 <81dd27fe-28ee-c800-fe5d-aaa64cb93513@arm.com>
 <20210401095945.GA6726@lst.de>
Message-ID: <20210401132657.GA8997@willie-the-truck>

On Thu, Apr 01, 2021 at 11:59:45AM +0200, Christoph Hellwig wrote:
> For now I'll just pass the iommu_domain to iommu_get_dma_strict,
> so that we can check for it.  We can do additional cleanups on top
> of that later.

Sounds good to me, cheers!

Will


From tglx at linutronix.de  Thu Apr  1 14:33:02 2021
From: tglx at linutronix.de (Thomas Gleixner)
Date: Thu, 01 Apr 2021 15:33:02 +0200
Subject: [PATCH v9 0/6] Optionally randomize kernel stack offset each
 syscall
In-Reply-To: <20210401083758.GA8745@willie-the-truck>
References: <20210331205458.1871746-1-keescook@chromium.org>
 <20210401083758.GA8745@willie-the-truck>
Message-ID: <87sg4a3zap.ffs@nanos.tec.linutronix.de>

On Thu, Apr 01 2021 at 09:37, Will Deacon wrote:
> On Wed, Mar 31, 2021 at 01:54:52PM -0700, Kees Cook wrote:
>> Hi Will (and Mark and Catalin),
>> 
>> Can you take this via the arm64 tree for v5.13 please? Thomas has added
>> his Reviewed-by, so it only leaves arm64's. :)
>
> Sorry, these got mixed up in my inbox so I just replied to v7 and v8 and
> then noticed v9. Argh!
>
> However, I think the comments still apply: namely that the dummy "=m" looks
> dangerous to me

> https://lore.kernel.org/r/20210401083034.GA8554 at willie-the-truck

Hrmpf, didn't think about that.

> and I think you're accessing pcpu variables with preemption enabled
> for the arm64 part:

That's my fault. On x86 this is invoked right after coming up into C
code and _before_ enabling interrupts, which I why I suggested not to
use the wrapped one. raw_cpu_read() should be fine everywhere.

Thanks,

        tglx


From mike.leach at linaro.org  Thu Apr  1 14:45:59 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Thu, 1 Apr 2021 14:45:59 +0100
Subject: [PATCH v5 04/10] coresight: etm-perf: update to handle
 configuration selection
In-Reply-To: <20210331204859.GA51243@xps15>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-5-mike.leach@linaro.org>
 <20210331204859.GA51243@xps15>
Message-ID: <CAJ9a7Vg+ua_ZBmn1Dk2U8-mkDpgEyrASgTqZ5jPXUumQMvqzAA@mail.gmail.com>

Hi Mathieu,

On Wed, 31 Mar 2021 at 21:49, Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
>
> On Tue, Mar 16, 2021 at 06:03:54PM +0000, Mike Leach wrote:
> > Loaded coresight configurations are registered in the cs_etm\cs_config sub
>
> This changelog is obsolete - cs_config is no longer under cs_etm.
>
Agreed.

> > directory. This extends the etm-perf code to handle these registrations,
> > and the cs_syscfg driver to perform the registration on load.
> >
> > Signed-off-by: Mike Leach <mike.leach at linaro.org>
> > ---
> >  .../hwtracing/coresight/coresight-config.h    |   2 +
> >  .../hwtracing/coresight/coresight-etm-perf.c  | 139 ++++++++++++++----
> >  .../hwtracing/coresight/coresight-etm-perf.h  |   8 +
> >  .../hwtracing/coresight/coresight-syscfg.c    |  12 ++
> >  4 files changed, 130 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
> > index f70561c1504b..38fd1c71eb05 100644
> > --- a/drivers/hwtracing/coresight/coresight-config.h
> > +++ b/drivers/hwtracing/coresight/coresight-config.h
> > @@ -126,6 +126,7 @@ struct cscfg_feature_desc {
> >   * @nr_presets:              Number of sets of presets supplied by this configuration.
> >   * @nr_total_params: Sum of all parameters declared by used features
> >   * @presets:         Array of preset values.
> > + * @event_ea:                Extended attribute for perf event value
> >   *
> >   */
> >  struct cscfg_config_desc {
> > @@ -137,6 +138,7 @@ struct cscfg_config_desc {
> >       int nr_presets;
> >       int nr_total_params;
> >       const u64 *presets; /* nr_presets * nr_total_params */
> > +     struct dev_ext_attribute *event_ea;
> >  };
> >
> >  /**
> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > index 0e392513b2d6..66bda452a2f4 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> > @@ -18,8 +18,10 @@
> >  #include <linux/types.h>
> >  #include <linux/workqueue.h>
> >
> > +#include "coresight-config.h"
> >  #include "coresight-etm-perf.h"
> >  #include "coresight-priv.h"
> > +#include "coresight-syscfg.h"
> >
> >  static struct pmu etm_pmu;
> >  static bool etm_perf_up;
> > @@ -38,8 +40,13 @@ PMU_FORMAT_ATTR(contextid1,        "config:" __stringify(ETM_OPT_CTXTID));
> >  PMU_FORMAT_ATTR(contextid2,  "config:" __stringify(ETM_OPT_CTXTID2));
> >  PMU_FORMAT_ATTR(timestamp,   "config:" __stringify(ETM_OPT_TS));
> >  PMU_FORMAT_ATTR(retstack,    "config:" __stringify(ETM_OPT_RETSTK));
> > +/* preset - if sink ID is used as a configuration selector */
> > +PMU_FORMAT_ATTR(preset,              "config:0-3");
> >  /* Sink ID - same for all ETMs */
> >  PMU_FORMAT_ATTR(sinkid,              "config2:0-31");
> > +/* config ID - set if a system configuration is selected */
> > +PMU_FORMAT_ATTR(configid,    "config2:32-63");
> > +
> >
> >  /*
> >   * contextid always traces the "PID".  The PID is in CONTEXTIDR_EL1
> > @@ -69,6 +76,8 @@ static struct attribute *etm_config_formats_attr[] = {
> >       &format_attr_timestamp.attr,
> >       &format_attr_retstack.attr,
> >       &format_attr_sinkid.attr,
> > +     &format_attr_preset.attr,
> > +     &format_attr_configid.attr,
> >       NULL,
> >  };
> >
> > @@ -86,9 +95,19 @@ static const struct attribute_group etm_pmu_sinks_group = {
> >       .attrs  = etm_config_sinks_attr,
> >  };
> >
> > +static struct attribute *etm_config_events_attr[] = {
> > +     NULL,
> > +};
> > +
> > +static const struct attribute_group etm_pmu_events_group = {
> > +     .name   = "events",
> > +     .attrs  = etm_config_events_attr,
> > +};
> > +
> >  static const struct attribute_group *etm_pmu_attr_groups[] = {
> >       &etm_pmu_format_group,
> >       &etm_pmu_sinks_group,
> > +     &etm_pmu_events_group,
> >       NULL,
> >  };
> >
> > @@ -247,7 +266,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
> >       INIT_WORK(&event_data->work, free_event_data);
> >
> >       /* First get the selected sink from user space. */
> > -     if (event->attr.config2) {
> > +     if (event->attr.config2 & GENMASK_ULL(31, 0)) {
> >               id = (u32)event->attr.config2;
> >               sink = coresight_get_sink_by_id(id);
> >       }
> > @@ -555,9 +574,9 @@ int etm_perf_symlink(struct coresight_device *csdev, bool link)
> >  }
> >  EXPORT_SYMBOL_GPL(etm_perf_symlink);
> >
> > -static ssize_t etm_perf_sink_name_show(struct device *dev,
> > -                                    struct device_attribute *dattr,
> > -                                    char *buf)
>
> Because we now have etm_perf_cscfg_event_show(), this could have remained
> unchanged.
>
> > +static ssize_t etm_perf_name_show(struct device *dev,
> > +                               struct device_attribute *dattr,
> > +                               char *buf)
> >  {
> >       struct dev_ext_attribute *ea;
> >
> > @@ -565,68 +584,126 @@ static ssize_t etm_perf_sink_name_show(struct device *dev,
> >       return scnprintf(buf, PAGE_SIZE, "0x%lx\n", (unsigned long)(ea->var));
> >  }
> >
> > -int etm_perf_add_symlink_sink(struct coresight_device *csdev)
> > +static struct dev_ext_attribute *
> > +etm_perf_add_symlink_group(struct device *dev, const char *name, const char *group_name)
> >  {
> > -     int ret;
> > +     struct dev_ext_attribute *ea;
> >       unsigned long hash;
> > -     const char *name;
> > +     int ret;
> >       struct device *pmu_dev = etm_pmu.dev;
> > -     struct device *dev = &csdev->dev;
> > -     struct dev_ext_attribute *ea;
> > -
> > -     if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
> > -         csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
> > -             return -EINVAL;
> > -
> > -     if (csdev->ea != NULL)
> > -             return -EINVAL;
> >
> >       if (!etm_perf_up)
> > -             return -EPROBE_DEFER;
> > +             return ERR_PTR(-EPROBE_DEFER);
> >
> >       ea = devm_kzalloc(dev, sizeof(*ea), GFP_KERNEL);
> >       if (!ea)
> > -             return -ENOMEM;
> > +             return ERR_PTR(-ENOMEM);
> >
> > -     name = dev_name(dev);
> > -     /* See function coresight_get_sink_by_id() to know where this is used */
> > +     /*
> > +      * If this function is called adding a sink then the hash is used for
> > +      * sink selection - see function coresight_get_sink_by_id().
> > +      * If adding a configuration then the hash is used for selection in
> > +      * cscfg_activate_config()
> > +      */
> >       hash = hashlen_hash(hashlen_string(NULL, name));
> >
> >       sysfs_attr_init(&ea->attr.attr);
> >       ea->attr.attr.name = devm_kstrdup(dev, name, GFP_KERNEL);
> >       if (!ea->attr.attr.name)
> > -             return -ENOMEM;
> > +             return ERR_PTR(-ENOMEM);
> >
> >       ea->attr.attr.mode = 0444;
> > -     ea->attr.show = etm_perf_sink_name_show;
> > +     ea->attr.show = etm_perf_name_show;
>
> I would have removed the assignment entirely from this function and moved it to
> etm_perf_add_symlink_cscfg() (like you already did) and
> etm_perf_add_symlink_link().
>
OK

> >       ea->var = (unsigned long *)hash;
> >
> >       ret = sysfs_add_file_to_group(&pmu_dev->kobj,
> > -                                   &ea->attr.attr, "sinks");
> > +                                   &ea->attr.attr, group_name);
> >
> > -     if (!ret)
> > -             csdev->ea = ea;
> > +     return ret ? ERR_PTR(ret) : ea;
> > +}
> >
> > -     return ret;
> > +int etm_perf_add_symlink_sink(struct coresight_device *csdev)
> > +{
> > +     const char *name;
> > +     struct device *dev = &csdev->dev;
> > +     int err = 0;
> > +
> > +     if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
> > +         csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
> > +             return -EINVAL;
> > +
> > +     if (csdev->ea != NULL)
> > +             return -EINVAL;
> > +
> > +     name = dev_name(dev);
> > +     csdev->ea = etm_perf_add_symlink_group(dev, name, "sinks");
> > +     if (IS_ERR(csdev->ea)) {
> > +             err = PTR_ERR(csdev->ea);
> > +             csdev->ea = NULL;
> > +     }
> > +     return err;
> >  }
> >
> > -void etm_perf_del_symlink_sink(struct coresight_device *csdev)
> > +void etm_perf_del_symlink_group(struct dev_ext_attribute *ea, const char *group_name)
> >  {
> >       struct device *pmu_dev = etm_pmu.dev;
> > -     struct dev_ext_attribute *ea = csdev->ea;
> >
> > +     sysfs_remove_file_from_group(&pmu_dev->kobj,
> > +                                  &ea->attr.attr, group_name);
> > +}
> > +
> > +void etm_perf_del_symlink_sink(struct coresight_device *csdev)
> > +{
> >       if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
> >           csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
> >               return;
> >
> > -     if (!ea)
> > +     if (!csdev->ea)
> >               return;
> >
> > -     sysfs_remove_file_from_group(&pmu_dev->kobj,
> > -                                  &ea->attr.attr, "sinks");
> > +     etm_perf_del_symlink_group(csdev->ea, "sinks");
> >       csdev->ea = NULL;
> >  }
> >
> > +static ssize_t etm_perf_cscfg_event_show(struct device *dev,
> > +                                      struct device_attribute *dattr,
> > +                                      char *buf)
> > +{
> > +     struct dev_ext_attribute *ea;
> > +
> > +     ea = container_of(dattr, struct dev_ext_attribute, attr);
> > +     return scnprintf(buf, PAGE_SIZE, "configid=0x%lx\n", (unsigned long)(ea->var));
> > +}
> > +
> > +int etm_perf_add_symlink_cscfg(struct device *dev, struct cscfg_config_desc *config_desc)
> > +{
> > +     int err = 0;
> > +
> > +     if (config_desc->event_ea != NULL)
> > +             return 0;
> > +
> > +     config_desc->event_ea = etm_perf_add_symlink_group(dev, config_desc->name, "events");
> > +
> > +     /* override the show function to the custom cscfg event */
> > +     if (!IS_ERR(config_desc->event_ea))
> > +             config_desc->event_ea->attr.show = etm_perf_cscfg_event_show;
> > +     else {
> > +             err = PTR_ERR(config_desc->event_ea);
> > +             config_desc->event_ea = NULL;
> > +     }
> > +
> > +     return err;
> > +}
> > +
> > +void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc)
> > +{
> > +     if (!config_desc->event_ea)
> > +             return;
> > +
> > +     etm_perf_del_symlink_group(config_desc->event_ea, "events");
> > +     config_desc->event_ea = NULL;
> > +}
> > +
> >  int __init etm_perf_init(void)
> >  {
> >       int ret;
> > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
> > index 29d90dfeba31..ba617fe2217e 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm-perf.h
> > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
> > @@ -11,6 +11,7 @@
> >  #include "coresight-priv.h"
> >
> >  struct coresight_device;
> > +struct cscfg_config_desc;
> >
> >  /*
> >   * In both ETMv3 and v4 the maximum number of address comparator implentable
> > @@ -69,6 +70,9 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >               return data->snk_config;
> >       return NULL;
> >  }
> > +int etm_perf_add_symlink_cscfg(struct device *dev,
> > +                            struct cscfg_config_desc *config_desc);
> > +void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc);
> >  #else
> >  static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
> >  { return -EINVAL; }
> > @@ -79,6 +83,10 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
> >  {
> >       return NULL;
> >  }
> > +int etm_perf_add_symlink_cscfg(struct device *dev,
> > +                            struct cscfg_config_desc *config_desc)
> > +{ return -EINVAL; }
> > +void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc) {}
> >
> >  #endif /* CONFIG_CORESIGHT */
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> > index 11d1422f0ed3..03014a2142c1 100644
> > --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> > @@ -7,6 +7,7 @@
> >  #include <linux/platform_device.h>
> >
> >  #include "coresight-config.h"
> > +#include "coresight-etm-perf.h"
> >  #include "coresight-syscfg.h"
> >
> >  /*
> > @@ -86,6 +87,7 @@ static int cscfg_add_csdev_cfg(struct coresight_device *csdev,
> >                       config_csdev->feats_csdev[config_csdev->nr_feat++] = feat_csdev;
> >               }
> >       }
> > +
>
> Spurious newline.
>
> If you end up respinning:
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>
> Otherwise I have fixed it on my side.
>
> Thanks,
> Mathieu
>

I have a v6 underway that picks up the kernel robot issues and a
couple of minor fixes I spotted in patches 5 (missing NULL assignment
for the enabled config on disable)  and 8 (unused #define) while
re-basing the follow-up dynamic config load / unload set. Only one in
patch 5 has potential to actually cause incorrect behaviour - then
only when configs have been unloaded - but it is part of the baseline
code so must be fixed there.

Assuming no major issues from your reviews of the rest of this set, v6
should be available quickly.

Thanks

Mike

> >       /* if matched features, add config to device.*/
> >       if (config_csdev) {
> >               mutex_lock(&cscfg_csdev_mutex);
> > @@ -276,6 +278,11 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
> >       if (err)
> >               return err;
> >
> > +     /* add config to perf fs to allow selection */
> > +     err = etm_perf_add_symlink_cscfg(cscfg_device(), config_desc);
> > +     if (err)
> > +             return err;
> > +
> >       list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
> >       return 0;
> >  }
> > @@ -490,7 +497,12 @@ int cscfg_create_device(void)
> >
> >  void cscfg_clear_device(void)
> >  {
> > +     struct cscfg_config_desc *cfg_desc;
> > +
> >       mutex_lock(&cscfg_mutex);
> > +     list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
> > +             etm_perf_del_symlink_cscfg(cfg_desc);
> > +     }
> >       device_unregister(cscfg_device());
> >       mutex_unlock(&cscfg_mutex);
> >  }
> > --
> > 2.17.1
> >



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From jolsa at redhat.com  Thu Apr  1 14:49:40 2021
From: jolsa at redhat.com (Jiri Olsa)
Date: Thu, 1 Apr 2021 15:49:40 +0200
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <1616668398-144648-3-git-send-email-john.garry@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
Message-ID: <YGXPdEAecos4iPVc@krava>

On Thu, Mar 25, 2021 at 06:33:14PM +0800, John Garry wrote:

SNIP

> +struct metric {
> +	struct list_head list;
> +	struct metric_ref metric_ref;
> +};
> +
> +static int resolve_metric_simple(struct expr_parse_ctx *pctx,
> +				 struct list_head *compound_list,
> +				 struct pmu_events_map *map,
> +				 const char *metric_name)
> +{
> +	struct hashmap_entry *cur, *cur_tmp;
> +	struct metric *metric, *tmp;
> +	size_t bkt;
> +	bool all;
> +	int rc;
> +
> +	do {
> +		all = true;
> +		hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
> +			struct metric_ref *ref;
> +			struct pmu_event *pe;
> +
> +			pe = metrcgroup_find_metric(cur->key, map);
> +			if (!pe)
> +				continue;
> +
> +			if (!strcmp(metric_name, (char *)cur->key)) {
> +				pr_warning("Recursion detected for metric %s\n", metric_name);
> +				rc = -1;
> +				goto out_err;
> +			}
> +
> +			all = false;
> +
> +			/* The metric key itself needs to go out.. */
> +			expr__del_id(pctx, cur->key);
> +
> +			metric = malloc(sizeof(*metric));
> +			if (!metric) {
> +				rc = -ENOMEM;
> +				goto out_err;
> +			}
> +
> +			ref = &metric->metric_ref;
> +			ref->metric_name = pe->metric_name;
> +			ref->metric_expr = pe->metric_expr;
> +			list_add_tail(&metric->list, compound_list);
> +
> +			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);

so this might add new items to pctx->ids, I think you need
to restart the iteration as we do it in __resolve_metric
otherwise you could miss some new keys

jirka

> +			if (rc)
> +				goto out_err;
> +		}
> +	} while (!all);
> +
> +	return 0;
> +
> +out_err:
> +	list_for_each_entry_safe(metric, tmp, compound_list, list)
> +		free(metric);
> +
> +	return rc;
> +
> +}

SNIP



From nm at ti.com  Thu Apr  1 14:52:15 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 1 Apr 2021 08:52:15 -0500
Subject: (subset) [PATCH 0/4] Convert Cadence QSPI bindings to yaml
In-Reply-To: <20210326130034.15231-1-p.yadav@ti.com>
References: <20210326130034.15231-1-p.yadav@ti.com>
Message-ID: <161728504983.2096.1063574920554874294.b4-ty@ti.com>

On Fri, 26 Mar 2021 18:30:30 +0530, Pratyush Yadav wrote:
> This series picks up Ramuthevar's effort on converting the Cadence QSPI
> bindings to yaml [0]. During the conversion process, I discovered that
> some TI device tree files were not using the compatible correctly. Those
> are fixed in patches 1-3.
> 
> [0] https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthevar at linux.intel.com/
> 
> [...]

Hi Pratyush Yadav,

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

[1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
      commit: f1b6f6e7f595ed66ba5f5d628df3d259218d584b
[2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
      commit: 0e941f496a8bdc47d34199c17f81b09b0dbe14ae
[3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible
      commit: 112e5934ff3a7505e583365213a27f990922b76b


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] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D



From alexandru.elisei at arm.com  Thu Apr  1 14:55:54 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 1 Apr 2021 14:55:54 +0100
Subject: [PATCH v2] KVM: arm64: Initialize VCPU mdcr_el2 before loading it
In-Reply-To: <87lfa4fm8u.wl-maz@kernel.org>
References: <20210323180057.263356-1-alexandru.elisei@arm.com>
 <87sg4dq83r.wl-maz@kernel.org> <5cfd4870-db31-cd7d-699f-bd70a1ab90fe@arm.com>
 <5c90a3b2-c9a8-640b-fb6a-7a09d397ba7f@arm.com> <87lfa4fm8u.wl-maz@kernel.org>
Message-ID: <d3f6cd69-42c8-0199-c7cd-56e1789ac141@arm.com>

Hi Marc,

On 3/30/21 8:57 PM, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 18:49:54 +0100,
> Alexandru Elisei <alexandru.elisei at arm.com> wrote:
>> Hi Marc,
>>
>> On 3/30/21 6:13 PM, Alexandru Elisei wrote:
>>> [..]
>>>>> +}
>>>>> +
>>>>>  /**
>>>>>   * kvm_arm_reset_debug_ptr - reset the debug ptr to point to the vcpu state
>>>>>   */
>>>>> @@ -83,12 +137,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
>>>>>   * @vcpu:	the vcpu pointer
>>>>>   *
>>>>>   * This is called before each entry into the hypervisor to setup any
>>>>> - * debug related registers. Currently this just ensures we will trap
>>>>> - * access to:
>>>>> - *  - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR)
>>>>> - *  - Debug ROM Address (MDCR_EL2_TDRA)
>>>>> - *  - OS related registers (MDCR_EL2_TDOSA)
>>>>> - *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
>>>>> + * debug related registers.
>>>>>   *
>>>>>   * Additionally, KVM only traps guest accesses to the debug registers if
>>>>>   * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
>>>>> @@ -100,27 +149,14 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
>>>>>  
>>>>>  void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
>>>>>  {
>>>>> -	bool trap_debug = !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY);
>>>>>  	unsigned long mdscr, orig_mdcr_el2 = vcpu->arch.mdcr_el2;
>>>>>  
>>>>>  	trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug);
>>>>>  
>>>>> -	/*
>>>>> -	 * This also clears MDCR_EL2_E2PB_MASK to disable guest access
>>>>> -	 * to the profiling buffer.
>>>>> -	 */
>>>>> -	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
>>>>> -	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
>>>>> -				MDCR_EL2_TPMS |
>>>>> -				MDCR_EL2_TPMCR |
>>>>> -				MDCR_EL2_TDRA |
>>>>> -				MDCR_EL2_TDOSA);
>>>>> +	kvm_arm_setup_mdcr_el2(vcpu, __this_cpu_read(mdcr_el2));
>>>>>  
>>>>>  	/* Is Guest debugging in effect? */
>>>>>  	if (vcpu->guest_debug) {
>>>>> -		/* Route all software debug exceptions to EL2 */
>>>>> -		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
>>>>> -
>>>>>  		/* Save guest debug state */
>>>>>  		save_guest_debug_regs(vcpu);
>>>>>  
>>>>> @@ -174,7 +210,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
>>>>>  
>>>>>  			vcpu->arch.debug_ptr = &vcpu->arch.external_debug_state;
>>>>>  			vcpu->arch.flags |= KVM_ARM64_DEBUG_DIRTY;
>>>>> -			trap_debug = true;
>>>> There is something that slightly worries me here: there is now a
>>>> disconnect between flagging debug as dirty and setting the
>>>> trapping. And actually, you now check for KVM_ARM64_DEBUG_DIRTY and
>>>> set the trap bits *before* setting the dirty bit itself.
>>>>
>>>> Here, I believe you end up with guest/host confusion of breakpoints,
>>>> which isn't great. Or did I miss something?
>>> I'm sorry, but I don't understand what you mean. This is my understanding of what
>>> is happening.
>>>
>>> Without this patch, trap_debug is set to true and the KVM_ARM64_DEBUG_DIRTY flag
>>> is set if vcpu->guest_debug & KVM_GUESTDBG_USE_HW. Further down, trap debug is
>>> only used when computing mdcr_el2.
>>>
>>> With this patch, trap_debug is set to true if vcpu->guest_debug &
>>> KVM_GUESTDBG_USE_HW and it's also used for computing mdcr_el2, but this happens in
>>> kvm_arm_setup_mdcr_el2(), which is called at the start of kvm_arm_setup_debug().
>>> The KVM_ARM_DEBUG_DIRTY flags is still set in kvm_arm_setup_debug() if
>>> vcpu->guest_debug & KVM_GUESTDBG_USE_HW, like before.
>>>
>>> The guest never runs with the value computed in kvm_vcpu_first_run_init() unless
>>> it's identical with the value recomputed in kvm_arm_setup_debug().
>>>
>>> The only difference I see is that mdcr_el2 is computed at the start of
>>> kvm_arm_setup_debug(). I get the feeling I'm also missing something.
>> I think I understand what you mean, you are worried that we won't
>> set the bit in mdcr_el2 to trap debug in the same place where we set
>> the debug dirty flag.
> Yes, that's what I mean. The code is conceptually as such ATM:
>
> 	debug_trap = (something based on vcpu->flags);
> 	if (something else) {
> 		check stuff;
> 		vcpu->flags |= stuff;
> 		debug_trap = true;
> 	}
>
> 	if (debug_trap)
> 		set trap conditions;
>
> You are turning this into:
>
> 	debug_trap = (something based on vcpu->flags);
> 	if (debug_trap) {
> 		set trap conditions;
> 	}
> 	if (something else) {
> 		check stuff;
> 		vcpu->flags |= stuff;
> 	}
>
> which isn't the same thing. In your case, it probably works because of
> KVM_GUESTDBG_USE_HW, but that's really hard to follow, and we have had
> so many bugs in the debug code that it really needs to be kept as
> stupid as possible.
>
>> If that's the case, then I can move kvm_arm_setup_mdcr_el2 right
>> after the BUG_ON() and remove the KVM_GUESTDBG_USE_HW check because
>> the KVM_ARM_DEBUG_DIRTY would be already set.
> Yes, I think that'd be better.
>
Had another go at this, and as I was looking at the code, I realized that
conceptually, trapping debug registers access (MDCR_EL2.TDA) is tied to:

- KVM_ARM64_DEBUG_DIRTY *not* being set (guest is debugging itself and KVM will
world-switch the debug registers).

- KVM_GUESTDBG_USE_HW being set, which also *sets* KVM_ARM64_DEBUG_DIRTY (host is
debugging the guest using hardware breakpoints).

So I cannot set the MDCR_EL2.TDA bit based on KVM_ARM64_DEBUG_DIRTY, because I
would lose one of the two cases. It looks to me that keeping
kvm_arm_setup_mdcr_el2() unchanged and calling it at the start of
kvm_arm_setup_debug() is the way to go here.

Thanks,

Alex



From mlevitsk at redhat.com  Thu Apr  1 14:54:48 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:48 +0300
Subject: [PATCH v2 6/9] KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-7-mlevitsk@redhat.com>

KVM_GUESTDBG_BLOCKEVENTS is a guest debug feature that
will allow KVM to block all interrupts while running.
It is mostly intended to be used together with single stepping,
to make it more robust, and has the following benefits:

* Resuming from a breakpoint is much more reliable:
  When resuming execution from a breakpoint, with interrupts enabled,
  more often than not, KVM would inject an interrupt and make the CPU
  jump immediately to the interrupt handler and eventually return to
  the breakpoint, only to trigger it again.

  From the gdb's user point of view it looks like the CPU has never
  executed a single instruction and in some cases that can even
  prevent forward progress, for example, when the breakpoint
  is placed by an automated script (e.g lx-symbols), which does
  something in response to the breakpoint and then continues
  the guest automatically.
  If the script execution takes enough time for another interrupt to
  arrive, the guest will be stuck on the same breakpoint forever.

* Normal single stepping is much more predictable, since it won't
  land the debugger into an interrupt handler.

* Chances of RFLAGS.TF being leaked to the guest are reduced:

  KVM sets that flag behind the guest's back to single step it,
  but if the single step lands the vCPU into an
  interrupt/exception handler the RFLAGS.TF will be leaked to the
  guest in the form of being pushed to the stack.
  This doesn't completely eliminate this problem as exceptions
  can still happen, but at least this eliminates the common
  case.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 Documentation/virt/kvm/api.rst  | 1 +
 arch/x86/include/asm/kvm_host.h | 3 ++-
 arch/x86/include/uapi/asm/kvm.h | 1 +
 arch/x86/kvm/x86.c              | 4 ++++
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 9778b2434c03..a4f2dc84741f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -3338,6 +3338,7 @@ flags which can include the following:
   - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
   - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
   - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]
+  - KVM_GUESTDBG_BLOCKIRQ:      avoid injecting interrupts/NMI/SMI [x86]
 
 For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints
 are enabled in memory so we need to ensure breakpoint exceptions are
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index cc7c82a449d5..8c529ae9dbbe 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -227,7 +227,8 @@ enum x86_intercept_stage;
 	KVM_GUESTDBG_USE_HW_BP | \
 	KVM_GUESTDBG_USE_SW_BP | \
 	KVM_GUESTDBG_INJECT_BP | \
-	KVM_GUESTDBG_INJECT_DB)
+	KVM_GUESTDBG_INJECT_DB | \
+	KVM_GUESTDBG_BLOCKIRQ)
 
 
 #define PFERR_PRESENT_BIT 0
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 5a3022c8af82..b0f9945067f7 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -282,6 +282,7 @@ struct kvm_debug_exit_arch {
 #define KVM_GUESTDBG_USE_HW_BP		0x00020000
 #define KVM_GUESTDBG_INJECT_DB		0x00040000
 #define KVM_GUESTDBG_INJECT_BP		0x00080000
+#define KVM_GUESTDBG_BLOCKIRQ		0x00100000
 
 /* for KVM_SET_GUEST_DEBUG */
 struct kvm_guest_debug_arch {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 956e8e0bd6af..3627ce8fe5bb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8460,6 +8460,10 @@ static void inject_pending_event(struct kvm_vcpu *vcpu, bool *req_immediate_exit
 		can_inject = false;
 	}
 
+	/* Don't inject interrupts if the user asked to avoid doing so */
+	if (vcpu->guest_debug & KVM_GUESTDBG_BLOCKIRQ)
+		return;
+
 	/*
 	 * Finally, inject interrupt events.  If an event cannot be injected
 	 * due to architectural conditions (e.g. IF=0) a window-open exit
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:44 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:44 +0300
Subject: [PATCH v2 2/9] KVM: introduce KVM_CAP_SET_GUEST_DEBUG2
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-3-mlevitsk@redhat.com>

This capability will allow the user to know which KVM_GUESTDBG_* bits
are supported.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 Documentation/virt/kvm/api.rst | 3 +++
 include/uapi/linux/kvm.h       | 1 +
 2 files changed, 4 insertions(+)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 38e327d4b479..9778b2434c03 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -3357,6 +3357,9 @@ indicating the number of supported registers.
 For ppc, the KVM_CAP_PPC_GUEST_DEBUG_SSTEP capability indicates whether
 the single-step debug event (KVM_GUESTDBG_SINGLESTEP) is supported.
 
+Also when supported, KVM_CAP_SET_GUEST_DEBUG2 capability indicates the
+supported KVM_GUESTDBG_* bits in the control field.
+
 When debug events exit the main run loop with the reason
 KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
 structure containing architecture specific debug information.
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f6afee209620..727010788eff 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1078,6 +1078,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_DIRTY_LOG_RING 192
 #define KVM_CAP_X86_BUS_LOCK_EXIT 193
 #define KVM_CAP_PPC_DAWR1 194
+#define KVM_CAP_SET_GUEST_DEBUG2 195
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:49 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:49 +0300
Subject: [PATCH v2 7/9] KVM: SVM: split svm_handle_invalid_exit
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-8-mlevitsk@redhat.com>

Split the check for having a vmexit handler to
svm_check_exit_valid, and make svm_handle_invalid_exit
only handle a vmexit that is already not valid.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/x86/kvm/svm/svm.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 271196400495..2aa951bc470c 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3220,12 +3220,14 @@ static void dump_vmcb(struct kvm_vcpu *vcpu)
 	       "excp_to:", save->last_excp_to);
 }
 
-static int svm_handle_invalid_exit(struct kvm_vcpu *vcpu, u64 exit_code)
+static bool svm_check_exit_valid(struct kvm_vcpu *vcpu, u64 exit_code)
 {
-	if (exit_code < ARRAY_SIZE(svm_exit_handlers) &&
-	    svm_exit_handlers[exit_code])
-		return 0;
+	return (exit_code < ARRAY_SIZE(svm_exit_handlers) &&
+		svm_exit_handlers[exit_code]);
+}
 
+static int svm_handle_invalid_exit(struct kvm_vcpu *vcpu, u64 exit_code)
+{
 	vcpu_unimpl(vcpu, "svm: unexpected exit reason 0x%llx\n", exit_code);
 	dump_vmcb(vcpu);
 	vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
@@ -3233,14 +3235,13 @@ static int svm_handle_invalid_exit(struct kvm_vcpu *vcpu, u64 exit_code)
 	vcpu->run->internal.ndata = 2;
 	vcpu->run->internal.data[0] = exit_code;
 	vcpu->run->internal.data[1] = vcpu->arch.last_vmentry_cpu;
-
-	return -EINVAL;
+	return 0;
 }
 
 int svm_invoke_exit_handler(struct kvm_vcpu *vcpu, u64 exit_code)
 {
-	if (svm_handle_invalid_exit(vcpu, exit_code))
-		return 0;
+	if (!svm_check_exit_valid(vcpu, exit_code))
+		return svm_handle_invalid_exit(vcpu, exit_code);
 
 #ifdef CONFIG_RETPOLINE
 	if (exit_code == SVM_EXIT_MSR)
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:50 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:50 +0300
Subject: [PATCH v2 8/9] KVM: x86: add force_intercept_exceptions_mask
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-9-mlevitsk@redhat.com>

This parameter will be used by VMX and SVM code to force
interception of a set of exceptions, given by a bitmask
for guest debug and/or kvm debug.

This option is not intended for production.

This is based on an idea first shown here:
https://patchwork.kernel.org/project/kvm/patch/20160301192822.GD22677 at pd.tnic/

CC: Borislav Petkov <bp at suse.de>
Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/x86/kvm/x86.c | 3 +++
 arch/x86/kvm/x86.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3627ce8fe5bb..1a51031d64d8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -176,6 +176,9 @@ module_param(force_emulation_prefix, bool, S_IRUGO);
 int __read_mostly pi_inject_timer = -1;
 module_param(pi_inject_timer, bint, S_IRUGO | S_IWUSR);
 
+uint force_intercept_exceptions_mask;
+module_param(force_intercept_exceptions_mask, uint, S_IRUGO | S_IWUSR);
+EXPORT_SYMBOL_GPL(force_intercept_exceptions_mask);
 /*
  * Restoring the host value for MSRs that are only consumed when running in
  * usermode, e.g. SYSCALL MSRs and TSC_AUX, can be deferred until the CPU
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index daccf20fbcd5..644480711ff7 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -311,6 +311,8 @@ extern struct static_key kvm_no_apic_vcpu;
 
 extern bool report_ignored_msrs;
 
+extern uint force_intercept_exceptions_mask;
+
 static inline u64 nsec_to_cycles(struct kvm_vcpu *vcpu, u64 nsec)
 {
 	return pvclock_scale_delta(nsec, vcpu->arch.virtual_tsc_mult,
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:42 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:42 +0300
Subject: [PATCH v2 0/9] KVM: my debug patch queue
Message-ID: <20210401135451.1004564-1-mlevitsk@redhat.com>

Hi!

I would like to publish two debug features which were needed for other stuff
I work on.

One is the reworked lx-symbols script which now actually works on at least
gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
for some reason, not related to this patch) and upstream qemu.

The other feature is the ability to trap all guest exceptions (on SVM for now)
and see them in kvmtrace prior to potential merge to double/triple fault.

This can be very useful and I already had to manually patch KVM a few
times for this.
I will, once time permits, implement this feature on Intel as well.

V2:

 * Some more refactoring and workarounds for lx-symbols script

 * added KVM_GUESTDBG_BLOCKEVENTS flag to enable 'block interrupts on
   single step' together with KVM_CAP_SET_GUEST_DEBUG2 capability
   to indicate which guest debug flags are supported.

   This is a replacement for unconditional block of interrupts on single
   step that was done in previous version of this patch set.
   Patches to qemu to use that feature will be sent soon.

 * Reworked the the 'intercept all exceptions for debug' feature according
   to the review feedback:

   - renamed the parameter that enables the feature and
     moved it to common kvm module.
     (only SVM part is currently implemented though)

   - disable the feature for SEV guests as was suggested during the review
   - made the vmexit table const again, as was suggested in the review as well.

Best regards,
	Maxim Levitsky

Maxim Levitsky (9):
  scripts/gdb: rework lx-symbols gdb script
  KVM: introduce KVM_CAP_SET_GUEST_DEBUG2
  KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2
  KVM: aarch64: implement KVM_CAP_SET_GUEST_DEBUG2
  KVM: s390x: implement KVM_CAP_SET_GUEST_DEBUG2
  KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
  KVM: SVM: split svm_handle_invalid_exit
  KVM: x86: add force_intercept_exceptions_mask
  KVM: SVM: implement force_intercept_exceptions_mask

 Documentation/virt/kvm/api.rst    |   4 +
 arch/arm64/include/asm/kvm_host.h |   4 +
 arch/arm64/kvm/arm.c              |   2 +
 arch/arm64/kvm/guest.c            |   5 -
 arch/s390/include/asm/kvm_host.h  |   4 +
 arch/s390/kvm/kvm-s390.c          |   3 +
 arch/x86/include/asm/kvm_host.h   |  12 ++
 arch/x86/include/uapi/asm/kvm.h   |   1 +
 arch/x86/kvm/svm/svm.c            |  87 +++++++++++--
 arch/x86/kvm/svm/svm.h            |   6 +-
 arch/x86/kvm/x86.c                |  14 ++-
 arch/x86/kvm/x86.h                |   2 +
 include/uapi/linux/kvm.h          |   1 +
 kernel/module.c                   |   8 +-
 scripts/gdb/linux/symbols.py      | 203 ++++++++++++++++++++----------
 15 files changed, 272 insertions(+), 84 deletions(-)

-- 
2.26.2




From mlevitsk at redhat.com  Thu Apr  1 14:54:43 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:43 +0300
Subject: [PATCH v2 1/9] scripts/gdb: rework lx-symbols gdb script
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-2-mlevitsk@redhat.com>

Fix several issues that are present in lx-symbols script:

* Track module unloads by placing another software breakpoint at
  'free_module'
  (force uninline this symbol just in case), and use remove-symbol-file
  gdb command to unload the symobls of the module that is unloading.

  That gives the gdb a chance to mark all software breakpoints from
  this module as pending again.
  Also remove the module from the 'known' module list once it is unloaded.

* Since we now track module unload, we don't need to reload all
  symbols anymore when 'known' module loaded again
  (that can't happen anymore).
  This allows reloading a module in the debugged kernel to finish
  much faster, while lx-symbols tracks module loads and unloads.

* Disable/enable all gdb breakpoints on both module load and unload
  breakpoint hits, and not only in 'load_all_symbols' as was done before.
  (load_all_symbols is no longer called on breakpoint hit)
  That allows gdb to avoid getting confused about the state of the
  (now two) internal breakpoints we place.
  Otherwise it will leave them in the kernel code segment, when
  continuing which triggers a guest kernel panic as soon as it skips
  over the 'int3' instruction and executes the garbage tail of the optcode
  on which the breakpoint was placed.

* Block SIGINT while symbols are reloading as this seems to crash gdb.
  (new in V2)

* Add a basic check that kernel is already loaded into the guest memory
  to avoid confusing errors.
  (new in V2)

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 kernel/module.c              |   8 +-
 scripts/gdb/linux/symbols.py | 203 +++++++++++++++++++++++------------
 2 files changed, 143 insertions(+), 68 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 30479355ab85..ea81fc06ea1f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -901,8 +901,12 @@ int module_refcount(struct module *mod)
 }
 EXPORT_SYMBOL(module_refcount);
 
-/* This exists whether we can unload or not */
-static void free_module(struct module *mod);
+/* This exists whether we can unload or not
+ * Keep it uninlined to provide a reliable breakpoint target,
+ * e.g. for the gdb helper command 'lx-symbols'.
+ */
+
+static noinline void free_module(struct module *mod);
 
 SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
 		unsigned int, flags)
diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
index 1be9763cf8bb..e1374a6e06f7 100644
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -14,45 +14,23 @@
 import gdb
 import os
 import re
+import signal
 
 from linux import modules, utils
 
 
 if hasattr(gdb, 'Breakpoint'):
-    class LoadModuleBreakpoint(gdb.Breakpoint):
-        def __init__(self, spec, gdb_command):
-            super(LoadModuleBreakpoint, self).__init__(spec, internal=True)
+
+    class BreakpointWrapper(gdb.Breakpoint):
+        def __init__(self, callback, **kwargs):
+            super(BreakpointWrapper, self).__init__(internal=True, **kwargs)
             self.silent = True
-            self.gdb_command = gdb_command
+            self.callback = callback
 
         def stop(self):
-            module = gdb.parse_and_eval("mod")
-            module_name = module['name'].string()
-            cmd = self.gdb_command
-
-            # enforce update if object file is not found
-            cmd.module_files_updated = False
-
-            # Disable pagination while reporting symbol (re-)loading.
-            # The console input is blocked in this context so that we would
-            # get stuck waiting for the user to acknowledge paged output.
-            show_pagination = gdb.execute("show pagination", to_string=True)
-            pagination = show_pagination.endswith("on.\n")
-            gdb.execute("set pagination off")
-
-            if module_name in cmd.loaded_modules:
-                gdb.write("refreshing all symbols to reload module "
-                          "'{0}'\n".format(module_name))
-                cmd.load_all_symbols()
-            else:
-                cmd.load_module_symbols(module)
-
-            # restore pagination state
-            gdb.execute("set pagination %s" % ("on" if pagination else "off"))
-
+            self.callback()
             return False
 
-
 class LxSymbols(gdb.Command):
     """(Re-)load symbols of Linux kernel and currently loaded modules.
 
@@ -61,15 +39,52 @@ are scanned recursively, starting in the same directory. Optionally, the module
 search path can be extended by a space separated list of paths passed to the
 lx-symbols command."""
 
-    module_paths = []
-    module_files = []
-    module_files_updated = False
-    loaded_modules = []
-    breakpoint = None
-
     def __init__(self):
         super(LxSymbols, self).__init__("lx-symbols", gdb.COMMAND_FILES,
                                         gdb.COMPLETE_FILENAME)
+        self.module_paths = []
+        self.module_files = []
+        self.module_files_updated = False
+        self.loaded_modules = {}
+        self.internal_breakpoints = []
+
+    # prepare GDB for loading/unloading a module
+    def _prepare_for_module_load_unload(self):
+
+        self.blocked_sigint = False
+
+        # block SIGINT during execution to avoid gdb crash
+        sigmask = signal.pthread_sigmask(signal.SIG_BLOCK, [])
+        if not signal.SIGINT in sigmask:
+            self.blocked_sigint = True
+            signal.pthread_sigmask(signal.SIG_BLOCK, {signal.SIGINT})
+
+        # disable all breakpoints to workaround a GDB bug where it would
+        # not correctly resume from an internal breakpoint we placed
+        # in do_module_init/free_module (it leaves the int3
+        self.saved_breakpoints = []
+        if hasattr(gdb, 'breakpoints') and not gdb.breakpoints() is None:
+            for bp in gdb.breakpoints():
+                self.saved_breakpoints.append({'breakpoint': bp, 'enabled': bp.enabled})
+                bp.enabled = False
+
+        # disable pagination to avoid asking user for continue
+        show_pagination = gdb.execute("show pagination", to_string=True)
+        self.saved_pagination = show_pagination.endswith("on.\n")
+        gdb.execute("set pagination off")
+
+    def _unprepare_for_module_load_unload(self):
+        # restore breakpoint state
+        for breakpoint in self.saved_breakpoints:
+            breakpoint['breakpoint'].enabled = breakpoint['enabled']
+
+        # restore pagination state
+        gdb.execute("set pagination %s" % ("on" if self.saved_pagination else "off"))
+
+        # unblock SIGINT
+        if self.blocked_sigint:
+            sigmask = signal.pthread_sigmask(signal.SIG_UNBLOCK, {signal.SIGINT})
+            self.blocked_sigint = False
 
     def _update_module_files(self):
         self.module_files = []
@@ -107,7 +122,7 @@ lx-symbols command."""
                     name=section_name, addr=str(address)))
         return "".join(args)
 
-    def load_module_symbols(self, module):
+    def _do_load_module_symbols(self, module):
         module_name = module['name'].string()
         module_addr = str(module['core_layout']['base']).split()[0]
 
@@ -130,55 +145,111 @@ lx-symbols command."""
                 addr=module_addr,
                 sections=self._section_arguments(module))
             gdb.execute(cmdline, to_string=True)
-            if module_name not in self.loaded_modules:
-                self.loaded_modules.append(module_name)
+
+            self.loaded_modules[module_name] = {"module_file": module_file,
+                                                "module_addr": module_addr}
         else:
             gdb.write("no module object found for '{0}'\n".format(module_name))
 
+
+    def load_module_symbols(self):
+        module = gdb.parse_and_eval("mod")
+
+                # module already loaded, false alarm
+        # can happen if 'do_init_module' breakpoint is hit multiple times
+        # due to interrupts
+        module_name = module['name'].string()
+        if module_name in self.loaded_modules:
+            gdb.write("spurious module load breakpoint\n")
+            return
+
+        # enforce update if object file is not found
+        self.module_files_updated = False
+        self._prepare_for_module_load_unload()
+        try:
+            self._do_load_module_symbols(module)
+        finally:
+            self._unprepare_for_module_load_unload()
+
+
+    def unload_module_symbols(self):
+        module = gdb.parse_and_eval("mod")
+        module_name = module['name'].string()
+
+        # module already unloaded, false alarm
+        # can happen if 'free_module' breakpoint is hit multiple times
+        # due to interrupts
+        if not module_name in self.loaded_modules:
+            gdb.write("spurious module unload breakpoint\n")
+            return
+
+        module_file = self.loaded_modules[module_name]["module_file"]
+        module_addr = self.loaded_modules[module_name]["module_addr"]
+
+        self._prepare_for_module_load_unload()
+        try:
+            gdb.write("unloading @{addr}: {filename}\n".format(
+                addr=module_addr, filename=module_file))
+            cmdline = "remove-symbol-file {filename}".format(
+                filename=module_file)
+            gdb.execute(cmdline, to_string=True)
+            del self.loaded_modules[module_name]
+
+        finally:
+            self._unprepare_for_module_load_unload()
+
     def load_all_symbols(self):
         gdb.write("loading vmlinux\n")
 
-        # Dropping symbols will disable all breakpoints. So save their states
-        # and restore them afterward.
-        saved_states = []
-        if hasattr(gdb, 'breakpoints') and not gdb.breakpoints() is None:
-            for bp in gdb.breakpoints():
-                saved_states.append({'breakpoint': bp, 'enabled': bp.enabled})
-
-        # drop all current symbols and reload vmlinux
-        orig_vmlinux = 'vmlinux'
-        for obj in gdb.objfiles():
-            if obj.filename.endswith('vmlinux'):
-                orig_vmlinux = obj.filename
-        gdb.execute("symbol-file", to_string=True)
-        gdb.execute("symbol-file {0}".format(orig_vmlinux))
-
-        self.loaded_modules = []
-        module_list = modules.module_list()
-        if not module_list:
-            gdb.write("no modules found\n")
-        else:
-            [self.load_module_symbols(module) for module in module_list]
+        self._prepare_for_module_load_unload()
+        try:
+            # drop all current symbols and reload vmlinux
+            orig_vmlinux = 'vmlinux'
+            for obj in gdb.objfiles():
+                if obj.filename.endswith('vmlinux'):
+                    orig_vmlinux = obj.filename
+            gdb.execute("symbol-file", to_string=True)
+            gdb.execute("symbol-file {0}".format(orig_vmlinux))
+            self.loaded_modules = {}
+            module_list = modules.module_list()
+            if not module_list:
+                gdb.write("no modules found\n")
+            else:
+                [self._do_load_module_symbols(module) for module in module_list]
+        finally:
+            self._unprepare_for_module_load_unload()
 
-        for saved_state in saved_states:
-            saved_state['breakpoint'].enabled = saved_state['enabled']
+        self._unprepare_for_module_load_unload()
 
     def invoke(self, arg, from_tty):
         self.module_paths = [os.path.expanduser(p) for p in arg.split()]
         self.module_paths.append(os.getcwd())
 
+        try:
+            gdb.parse_and_eval("*start_kernel").fetch_lazy()
+        except gdb.MemoryError:
+            gdb.write("Error: Kernel is not yet loaded\n")
+            return
+
         # enforce update
         self.module_files = []
         self.module_files_updated = False
 
+        for bp in self.internal_breakpoints:
+            bp.delete()
+        self.internal_breakpoints = []
+
         self.load_all_symbols()
 
         if hasattr(gdb, 'Breakpoint'):
-            if self.breakpoint is not None:
-                self.breakpoint.delete()
-                self.breakpoint = None
-            self.breakpoint = LoadModuleBreakpoint(
-                "kernel/module.c:do_init_module", self)
+            self.internal_breakpoints.append(
+                BreakpointWrapper(self.load_module_symbols,
+                                  spec="kernel/module.c:do_init_module",
+                                  ))
+            self.internal_breakpoints.append(
+                BreakpointWrapper(self.unload_module_symbols,
+                                  spec="kernel/module.c:free_module",
+                                  ))
         else:
             gdb.write("Note: symbol update on module loading not supported "
                       "with this gdb version\n")
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:46 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:46 +0300
Subject: [PATCH v2 4/9] KVM: aarch64: implement KVM_CAP_SET_GUEST_DEBUG2
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-5-mlevitsk@redhat.com>

Move KVM_GUESTDBG_VALID_MASK to kvm_host.h
and use it to return the value of this capability.
Compile tested only.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h | 4 ++++
 arch/arm64/kvm/arm.c              | 2 ++
 arch/arm64/kvm/guest.c            | 5 -----
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527f7d..613421454ab6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -401,6 +401,10 @@ struct kvm_vcpu_arch {
 #define KVM_ARM64_PENDING_EXCEPTION	(1 << 8) /* Exception pending */
 #define KVM_ARM64_EXCEPT_MASK		(7 << 9) /* Target EL/MODE */
 
+#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
+				 KVM_GUESTDBG_USE_SW_BP | \
+				 KVM_GUESTDBG_USE_HW | \
+				 KVM_GUESTDBG_SINGLESTEP)
 /*
  * When KVM_ARM64_PENDING_EXCEPTION is set, KVM_ARM64_EXCEPT_MASK can
  * take the following values:
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7f06ba76698d..e575eff76e97 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -208,6 +208,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_VCPU_ATTRIBUTES:
 		r = 1;
 		break;
+	case KVM_CAP_SET_GUEST_DEBUG2:
+		return KVM_GUESTDBG_VALID_MASK;
 	case KVM_CAP_ARM_SET_DEVICE_ADDR:
 		r = 1;
 		break;
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 9bbd30e62799..6cb39ee74acd 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -888,11 +888,6 @@ int kvm_arch_vcpu_ioctl_translate(struct kvm_vcpu *vcpu,
 	return -EINVAL;
 }
 
-#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE |    \
-			    KVM_GUESTDBG_USE_SW_BP | \
-			    KVM_GUESTDBG_USE_HW | \
-			    KVM_GUESTDBG_SINGLESTEP)
-
 /**
  * kvm_arch_vcpu_ioctl_set_guest_debug - set up guest debugging
  * @kvm:	pointer to the KVM struct
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:51 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:51 +0300
Subject: [PATCH v2 9/9] KVM: SVM: implement force_intercept_exceptions_mask
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-10-mlevitsk@redhat.com>

Currently #TS interception is only done once.
Also exception interception is not enabled for SEV guests.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/x86/include/asm/kvm_host.h |  2 +
 arch/x86/kvm/svm/svm.c          | 70 +++++++++++++++++++++++++++++++++
 arch/x86/kvm/svm/svm.h          |  6 ++-
 arch/x86/kvm/x86.c              |  5 ++-
 4 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 8c529ae9dbbe..d15ae64a2c4e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1574,6 +1574,8 @@ int kvm_emulate_rdpmc(struct kvm_vcpu *vcpu);
 void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr);
 void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32 error_code);
 void kvm_queue_exception_p(struct kvm_vcpu *vcpu, unsigned nr, unsigned long payload);
+void kvm_queue_exception_e_p(struct kvm_vcpu *vcpu, unsigned nr,
+			     u32 error_code, unsigned long payload);
 void kvm_requeue_exception(struct kvm_vcpu *vcpu, unsigned nr);
 void kvm_requeue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32 error_code);
 void kvm_inject_page_fault(struct kvm_vcpu *vcpu, struct x86_exception *fault);
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 2aa951bc470c..de7fd7922ec7 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -220,6 +220,8 @@ static const u32 msrpm_ranges[] = {0, 0xc0000000, 0xc0010000};
 #define MSRS_RANGE_SIZE 2048
 #define MSRS_IN_RANGE (MSRS_RANGE_SIZE * 8 / 2)
 
+static int svm_handle_invalid_exit(struct kvm_vcpu *vcpu, u64 exit_code);
+
 u32 svm_msrpm_offset(u32 msr)
 {
 	u32 offset;
@@ -1113,6 +1115,22 @@ static void svm_check_invpcid(struct vcpu_svm *svm)
 	}
 }
 
+static void svm_init_force_exceptions_intercepts(struct vcpu_svm *svm)
+{
+	int exc;
+
+	svm->force_intercept_exceptions_mask = force_intercept_exceptions_mask;
+	for (exc = 0 ; exc < 32 ; exc++) {
+		if (!(svm->force_intercept_exceptions_mask & (1 << exc)))
+			continue;
+
+		/* Those are defined to have undefined behavior in the SVM spec */
+		if (exc != 2 && exc != 9)
+			continue;
+		set_exception_intercept(svm, exc);
+	}
+}
+
 static void init_vmcb(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
@@ -1288,6 +1306,9 @@ static void init_vmcb(struct kvm_vcpu *vcpu)
 
 	enable_gif(svm);
 
+	if (!sev_es_guest(vcpu->kvm))
+		svm_init_force_exceptions_intercepts(svm);
+
 }
 
 static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
@@ -1913,6 +1934,17 @@ static int pf_interception(struct kvm_vcpu *vcpu)
 	u64 fault_address = svm->vmcb->control.exit_info_2;
 	u64 error_code = svm->vmcb->control.exit_info_1;
 
+	if ((svm->force_intercept_exceptions_mask & (1 << PF_VECTOR)))
+		if (npt_enabled && !vcpu->arch.apf.host_apf_flags) {
+			/* If the #PF was only intercepted for debug, inject
+			 * it directly to the guest, since the kvm's mmu code
+			 * is not ready to deal with such page faults.
+			 */
+			kvm_queue_exception_e_p(vcpu, PF_VECTOR,
+						error_code, fault_address);
+			return 1;
+		}
+
 	return kvm_handle_page_fault(vcpu, error_code, fault_address,
 			static_cpu_has(X86_FEATURE_DECODEASSISTS) ?
 			svm->vmcb->control.insn_bytes : NULL,
@@ -1988,6 +2020,40 @@ static int ac_interception(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+static int gen_exc_interception(struct kvm_vcpu *vcpu)
+{
+	/*
+	 * Generic exception intercept handler which forwards a guest exception
+	 * as-is to the guest.
+	 * For exceptions that don't have a special intercept handler.
+	 *
+	 * Used only for 'force_intercept_exceptions_mask' KVM debug feature.
+	 */
+	struct vcpu_svm *svm = to_svm(vcpu);
+	int exc = svm->vmcb->control.exit_code - SVM_EXIT_EXCP_BASE;
+
+	/* SVM doesn't provide us with an error code for the #DF */
+	u32 err_code = exc == DF_VECTOR ? 0 : svm->vmcb->control.exit_info_1;
+
+	if (!(svm->force_intercept_exceptions_mask & (1 << exc)))
+		return svm_handle_invalid_exit(vcpu, svm->vmcb->control.exit_code);
+
+	if (exc == TS_VECTOR) {
+		/*
+		 * SVM doesn't provide us with an error code to be able to
+		 * re-inject the #TS exception, so just disable its
+		 * intercept, and let the guest re-execute the instruction.
+		 */
+		vmcb_clr_intercept(&svm->vmcb01.ptr->control,
+				   INTERCEPT_EXCEPTION_OFFSET + TS_VECTOR);
+		recalc_intercepts(svm);
+	} else if (x86_exception_has_error_code(exc))
+		kvm_queue_exception_e(vcpu, exc, err_code);
+	else
+		kvm_queue_exception(vcpu, exc);
+	return 1;
+}
+
 static bool is_erratum_383(void)
 {
 	int err, i;
@@ -3051,6 +3117,10 @@ static int (*const svm_exit_handlers[])(struct kvm_vcpu *vcpu) = {
 	[SVM_EXIT_WRITE_DR5]			= dr_interception,
 	[SVM_EXIT_WRITE_DR6]			= dr_interception,
 	[SVM_EXIT_WRITE_DR7]			= dr_interception,
+
+	[SVM_EXIT_EXCP_BASE ...
+	SVM_EXIT_EXCP_BASE + 31]		= gen_exc_interception,
+
 	[SVM_EXIT_EXCP_BASE + DB_VECTOR]	= db_interception,
 	[SVM_EXIT_EXCP_BASE + BP_VECTOR]	= bp_interception,
 	[SVM_EXIT_EXCP_BASE + UD_VECTOR]	= ud_interception,
diff --git a/arch/x86/kvm/svm/svm.h b/arch/x86/kvm/svm/svm.h
index 8e276c4fb33d..79d0aea87753 100644
--- a/arch/x86/kvm/svm/svm.h
+++ b/arch/x86/kvm/svm/svm.h
@@ -183,6 +183,7 @@ struct vcpu_svm {
 	bool ghcb_sa_free;
 
 	bool guest_state_loaded;
+	u32 force_intercept_exceptions_mask;
 };
 
 struct svm_cpu_data {
@@ -333,8 +334,11 @@ static inline void clr_exception_intercept(struct vcpu_svm *svm, u32 bit)
 	struct vmcb *vmcb = svm->vmcb01.ptr;
 
 	WARN_ON_ONCE(bit >= 32);
-	vmcb_clr_intercept(&vmcb->control, INTERCEPT_EXCEPTION_OFFSET + bit);
 
+	if ((1 << bit) & svm->force_intercept_exceptions_mask)
+		return;
+
+	vmcb_clr_intercept(&vmcb->control, INTERCEPT_EXCEPTION_OFFSET + bit);
 	recalc_intercepts(svm);
 }
 
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1a51031d64d8..ae57816fe6d9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -630,12 +630,13 @@ void kvm_queue_exception_p(struct kvm_vcpu *vcpu, unsigned nr,
 }
 EXPORT_SYMBOL_GPL(kvm_queue_exception_p);
 
-static void kvm_queue_exception_e_p(struct kvm_vcpu *vcpu, unsigned nr,
-				    u32 error_code, unsigned long payload)
+void kvm_queue_exception_e_p(struct kvm_vcpu *vcpu, unsigned nr,
+			     u32 error_code, unsigned long payload)
 {
 	kvm_multiple_exception(vcpu, nr, true, error_code,
 			       true, payload, false);
 }
+EXPORT_SYMBOL_GPL(kvm_queue_exception_e_p);
 
 int kvm_complete_insn_gp(struct kvm_vcpu *vcpu, int err)
 {
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:47 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:47 +0300
Subject: [PATCH v2 5/9] KVM: s390x: implement KVM_CAP_SET_GUEST_DEBUG2
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-6-mlevitsk@redhat.com>

Define KVM_GUESTDBG_VALID_MASK and use it to implement this capabiity.
Compile tested only.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/s390/include/asm/kvm_host.h | 4 ++++
 arch/s390/kvm/kvm-s390.c         | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 6bcfc5614bbc..a3902b57b825 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -700,6 +700,10 @@ struct kvm_hw_bp_info_arch {
 #define guestdbg_exit_pending(vcpu) (guestdbg_enabled(vcpu) && \
 		(vcpu->guest_debug & KVM_GUESTDBG_EXIT_PENDING))
 
+#define KVM_GUESTDBG_VALID_MASK \
+		(KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_SINGLESTEP |\
+		KVM_GUESTDBG_USE_HW_BP | KVM_GUESTDBG_EXIT_PENDING)
+
 struct kvm_guestdbg_info_arch {
 	unsigned long cr0;
 	unsigned long cr9;
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 2f09e9d7dc95..2049fc8c222a 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -544,6 +544,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_S390_DIAG318:
 		r = 1;
 		break;
+	case KVM_CAP_SET_GUEST_DEBUG2:
+		r = KVM_GUESTDBG_VALID_MASK;
+		break;
 	case KVM_CAP_S390_HPAGE_1M:
 		r = 0;
 		if (hpage && !kvm_is_ucontrol(kvm))
-- 
2.26.2



From mlevitsk at redhat.com  Thu Apr  1 14:54:45 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Thu,  1 Apr 2021 16:54:45 +0300
Subject: [PATCH v2 3/9] KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <20210401135451.1004564-4-mlevitsk@redhat.com>

Store the supported bits into KVM_GUESTDBG_VALID_MASK
macro, similar to how arm does this.

Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
---
 arch/x86/include/asm/kvm_host.h | 9 +++++++++
 arch/x86/kvm/x86.c              | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a52f973bdff6..cc7c82a449d5 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -221,6 +221,15 @@ enum x86_intercept_stage;
 #define DR7_FIXED_1	0x00000400
 #define DR7_VOLATILE	0xffff2bff
 
+#define KVM_GUESTDBG_VALID_MASK \
+	(KVM_GUESTDBG_ENABLE | \
+	KVM_GUESTDBG_SINGLESTEP | \
+	KVM_GUESTDBG_USE_HW_BP | \
+	KVM_GUESTDBG_USE_SW_BP | \
+	KVM_GUESTDBG_INJECT_BP | \
+	KVM_GUESTDBG_INJECT_DB)
+
+
 #define PFERR_PRESENT_BIT 0
 #define PFERR_WRITE_BIT 1
 #define PFERR_USER_BIT 2
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a9d95f90a048..956e8e0bd6af 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3798,6 +3798,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_ENFORCE_PV_FEATURE_CPUID:
 		r = 1;
 		break;
+	case KVM_CAP_SET_GUEST_DEBUG2:
+		return KVM_GUESTDBG_VALID_MASK;
 #ifdef CONFIG_KVM_XEN
 	case KVM_CAP_XEN_HVM:
 		r = KVM_XEN_HVM_CONFIG_HYPERCALL_MSR |
-- 
2.26.2



From matthias.bgg at gmail.com  Thu Apr  1 14:58:41 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 15:58:41 +0200
Subject: [GIT PULL] defconfig: mediatek: changes for v5.13
Message-ID: <70f6a2ae-2a99-6861-e591-9cc71bb174af@gmail.com>

Hi Arnd and Olof,

Please have a look at the following changes to defconfig. There is a small merge
conflict with the IMX branch, but it should be trivial.

Regards,
Matthias
---
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-defconfig

for you to fetch changes up to f6dc45610879f88b1c37c07c8342f6764bcd55f4:

  arm64: defconfig: Enable options to support panel display for Mediatek
Chromebooks (2021-03-31 12:12:59 +0200)

----------------------------------------------------------------
Enable option to boot MediaTek based chromebook (mt8173 and mt8183) with defconfig

----------------------------------------------------------------
Enric Balletbo i Serra (2):
      arm64: defconfig: Allow mt8173-based boards to boot from usb
      arm64: defconfig: Enable options to support panel display for Mediatek
Chromebooks

 arch/arm64/configs/defconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)


From matthias.bgg at gmail.com  Thu Apr  1 15:01:34 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 16:01:34 +0200
Subject: [GIT PULL] ARM: dts: mediatek: updates for v5.13
Message-ID: <be262120-6cd9-87a7-ccc3-f5c403cff66b@gmail.com>

Hi Olof and Arnd,

Please take the below patches into account. These are mostly cleanups to make
the DTB checker happy. Apart from that we now have SMP support for MT6589, it's
nice to see that someone keeps working on this old platform with which I started
upstreaming :)

Regards,
Matthias

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-dts32

for you to fetch changes up to 562f818deaf0601f224999cc39b6c97fbb2adc57:

  arm: mediatek: dts: activate SMP for mt6589 (2021-03-30 12:12:25 +0200)

----------------------------------------------------------------
- fix dtbs_check warnings
- enable SMP for mt6589

----------------------------------------------------------------
Boris Lysov (1):
      arm: mediatek: dts: activate SMP for mt6589

Chunfeng Yun (3):
      arm: dts: mt7629: harmonize node names and compatibles
      arm: dts: mt7623: harmonize node names and compatibles
      arm: dts: mt2701: harmonize node names and compatibles

 arch/arm/boot/dts/mt2701.dtsi  | 19 +++++++++++--------
 arch/arm/boot/dts/mt6589.dtsi  |  1 +
 arch/arm/boot/dts/mt7623.dtsi  | 26 ++++++++++++++------------
 arch/arm/boot/dts/mt7623n.dtsi |  4 ++--
 arch/arm/boot/dts/mt7629.dtsi  | 12 +++++++-----
 5 files changed, 35 insertions(+), 27 deletions(-)


From andre.przywara at arm.com  Thu Apr  1 15:02:52 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 1 Apr 2021 15:02:52 +0100
Subject: [PATCH v3 4/4] ARM: dts: sun8i: r40: add devicetree for Forlinx
 FETA40i-C & OKA40i-C
In-Reply-To: <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
Message-ID: <20210401150252.15d1b39c@slackpad.fritz.box>

On Wed, 31 Mar 2021 18:56:16 +0300
Ivan Uvarov <i.uvarov at cognitivepilot.com> wrote:

> The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i.
> 
> SoM specifications:
> 
> - SoC: R40 or A40i
> - PMIC: AXP221S
> - RAM: 1GiB/2GiB DDR3 (dual-rank)
> - eMMC: 8GB,
> - Mates with carrier board via four 80-pin connectors (AXK6F80337YG).
> 
> OKA40i-C is a carrier board by the same manufacturer for this SoM,
> whose main purpose is as a development board with a wide variety of
> peripherals:
> 
> - Power: DC5V barrel or USB OTG or 4.2V Lipo battery
> - Video out: HDMI, TV out, LVDS
> - WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
> - Ethernet: 10/100Mbps
> - Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
> - USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
> - UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
> - Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
> - Mini PCIe slot with sim holder for WLAN modem
> - Smart card holder
> - RTC (RX8010SJ)
> - Two user LEDs
> - Three user buttons (via KeyADC).
> 
> This patch adds a devicetree for the aforementioned SoM and devboard.
> In order to reflect the modularity of this devboard and simplify adding
> support for future hardware based on the same SoM, the devicetree is split:
> Everything pertaining to the SoM itself is described in a separate .dtsi
> file, which is included by the devboard's .dts.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

Thanks for the changes, looks good to me now!

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre

>  3 files changed, 310 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e7..88aae9de95 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1222,6 +1222,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-r16-nintendo-super-nes-classic.dtb \
>  	sun8i-r16-parrot.dtb \
>  	sun8i-r40-bananapi-m2-ultra.dtb \
> +	sun8i-r40-oka40i-c.dtb \
>  	sun8i-s3-elimo-initium.dtb \
>  	sun8i-s3-lichee-zero-plus.dtb \
>  	sun8i-s3-pinecube.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> new file mode 100644
> index 0000000000..265e0fa57a
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> +//  Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> +//  Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> +
> +#include "sun8i-r40.dtsi"
> +
> +&i2c0 {
> +	status = "okay";
> +
> +	axp22x: pmic at 34 {
> +		compatible = "x-powers,axp221";
> +		reg = <0x34>;
> +		interrupt-parent = <&nmi_intc>;
> +		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +	};
> +};
> +
> +#include "axp22x.dtsi"
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_aldo2>;
> +	bus-width = <8>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&pio {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&clk_out_a_pin>;
> +	vcc-pa-supply = <&reg_dcdc1>;
> +	vcc-pc-supply = <&reg_aldo2>;
> +	vcc-pd-supply = <&reg_dcdc1>;
> +	vcc-pf-supply = <&reg_dldo4>;
> +	vcc-pg-supply = <&reg_dldo1>;
> +};
> +
> +&reg_aldo2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-name = "vcc-pa";
> +};
> +
> +&reg_aldo3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3000000>;
> +	regulator-max-microvolt = <3000000>;
> +	regulator-name = "avcc";
> +};
> +
> +&reg_dcdc1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-3v3";
> +};
> +
> +&reg_dcdc2 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-cpu";
> +};
> +
> +&reg_dcdc3 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1100000>;
> +	regulator-max-microvolt = <1100000>;
> +	regulator-name = "vdd-sys";
> +};
> +
> +&reg_dcdc5 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <1500000>;
> +	regulator-max-microvolt = <1500000>;
> +	regulator-name = "vcc-dram";
> +};
> +
> +&reg_dldo1 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi-io";
> +};
> +
> +&reg_dldo4 {
> +	regulator-always-on;
> +	regulator-min-microvolt = <2500000>;
> +	regulator-max-microvolt = <2500000>;
> +	regulator-name = "vdd2v5-sata";
> +};
> +
> +&reg_eldo2 {
> +	regulator-min-microvolt = <1200000>;
> +	regulator-max-microvolt = <1200000>;
> +	regulator-name = "vdd1v2-sata";
> +};
> +
> +&reg_eldo3 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-name = "vcc-pe";
> +};
> diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> new file mode 100644
> index 0000000000..9305fda8d1
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> +//	Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> +//	Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> +
> +/dts-v1/;
> +#include "sun8i-r40-feta40i.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> +	model = "Forlinx OKA40i-C";
> +	compatible = "forlinx,oka40i-c", "forlinx,feta40i-c", "allwinner,sun8i-r40";
> +
> +	aliases {
> +		ethernet0 = &gmac;
> +		serial0 = &uart0;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5; /* RS485 */
> +		serial7 = &uart7;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	connector {
> +		compatible = "hdmi-connector";
> +		type = "a";
> +
> +		port {
> +			hdmi_con_in: endpoint {
> +				remote-endpoint = <&hdmi_out_con>;
> +			};
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led-5 {
> +			gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /* PH26 */
> +			color = <LED_COLOR_ID_GREEN>;
> +			function = LED_FUNCTION_STATUS;
> +		};
> +
> +		led-6 {
> +			gpios = <&pio 8 15 GPIO_ACTIVE_LOW>; /* PI15 */
> +			color = <LED_COLOR_ID_BLUE>;
> +			function = LED_FUNCTION_STATUS;
> +		};
> +	};
> +
> +	reg_vcc5v0: vcc5v0 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc5v0";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +	};
> +
> +	wifi_pwrseq: wifi_pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		reset-gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; // PB10 WIFI_EN
> +		clocks = <&ccu CLK_OUTA>;
> +		clock-names = "ext_clock";
> +	};
> +};
> +
> +&ahci {
> +	ahci-supply = <&reg_dldo4>;
> +	phy-supply = <&reg_eldo2>;
> +	status = "okay";
> +};
> +
> +&de {
> +	status = "okay";
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&gmac {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&gmac_rgmii_pins>;
> +	phy-handle = <&phy1>;
> +	phy-mode = "rgmii-id";
> +	phy-supply = <&reg_dcdc1>;
> +	status = "okay";
> +};
> +
> +&gmac_mdio {
> +	phy1: ethernet-phy at 1 {
> +		compatible = "ethernet-phy-ieee802.3-c22";
> +		reg = <1>;
> +	};
> +};
> +
> +&hdmi {
> +	status = "okay";
> +};
> +
> +&hdmi_out {
> +	hdmi_out_con: endpoint {
> +		remote-endpoint = <&hdmi_con_in>;
> +	};
> +};
> +
> +&i2c2 {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_dcdc1>;
> +	bus-width = <4>;
> +	cd-gpios = <&pio 8 11 GPIO_ACTIVE_LOW>; // PI11
> +	status = "okay";
> +};
> +
> +&mmc3 {
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_dcdc1>;
> +	bus-width = <4>;
> +	cd-gpios = <&pio 8 10 GPIO_ACTIVE_LOW>; // PI10
> +	status = "okay";
> +};
> +
> +&ohci1 {
> +	status = "okay";
> +};
> +
> +&ohci2 {
> +	status = "okay";
> +};
> +
> +&reg_dc1sw {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-lcd";
> +};
> +
> +&reg_dldo2 {
> +	regulator-min-microvolt = <3300000>;
> +	regulator-max-microvolt = <3300000>;
> +	regulator-name = "vcc-wifi";
> +};
> +
> +&tcon_tv0 {
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pb_pins>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart2_pi_pins>, <&uart2_rts_cts_pi_pins>;
> +	uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart3_pg_pins>, <&uart3_rts_cts_pg_pins>;
> +	uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&uart4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart4_pg_pins>;
> +	status = "okay";
> +};
> +
> +&uart5 { /* RS485 */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart5_ph_pins>;
> +	status = "okay";
> +};
> +
> +&uart7 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart7_pi_pins>;
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	usb1_vbus-supply = <&reg_vcc5v0>;
> +	usb2_vbus-supply = <&reg_vcc5v0>;
> +	status = "okay";
> +};



From broonie at kernel.org  Thu Apr  1 15:13:28 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 15:13:28 +0100
Subject: [PATCH 4/4] dt-bindings: spi: Convert cadence-quadspi.txt to
 cadence-quadspi.yaml
In-Reply-To: <20210331193930.tzsvbjup3wpxmh26@ti.com>
References: <20210331193930.tzsvbjup3wpxmh26@ti.com>
Message-ID: <20210401141328.GH4758@sirena.org.uk>

On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:

> I did take a look by running git log on 
> Documentation/devicetree/bindings/spi/ and there is no single style 
> being used. Using "dt-bindings: spi:" is a popular choice. Some other 
> commits just use "spi:". And then some use "spi: dt-bindings:". The last 
> commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix 
> "dt-bindings: spi:".

Yes, lots of people pick unfortunate subject lines for DT patches - that
doesn't mean it's good.  I'm looking to see spi: same as for all other
SPI patches.

> So on the prefix front I think the subject is good enough. Of course, if 
> you have any other preference then it can be re-worded but let's first 
> be clear on what the expectation is. And then let's make sure to apply 
> it to all future patches uniformly. This way future contributors won't 
> have to take a guess on what the expected prefix is.

I do edit some percentage of patches, but some do slip through for
various reasons.  There's also some things that just get completely
missed, especially if there isn't also a code patch nearby.

> Apart from the prefix is there anything else to improve? IMHO the 
> subject is good enough but I'm open to suggestions.

There was the thing with constraints.
-------------- 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/20210401/32853e0a/attachment.sig>

From matthias.bgg at gmail.com  Thu Apr  1 15:14:20 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 16:14:20 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13
Message-ID: <d1121630-5778-0955-fac7-f921174defe7@gmail.com>

Hi Olof and Arnd,

Please have a look at the updates below. As you can see we have quite some
activity on the MT8183 based devices, with a whole bunch of new Chromebook
bindings added this round. Apart from that the a bit older MT8173 still gets
improvement, which is nice to see.

Regards,
Matthias
---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-dts64

for you to fetch changes up to a7dceafed43a4a610d340da3703653cca2c50c1d:

  arm64: dts: mediatek: fix reset GPIO level on pumpkin (2021-04-01 11:39:10 +0200)

----------------------------------------------------------------
- add trivial bindings for MT8195
- fix dtbs_check warnings
- add pinmux for build-in Wifi on MT7622 evaluation borad

MT8183:
- fix USB wakeup register
- add regulator for EVB board
- add registers to mailbox consumers
- add thermal zone and trip points for CPU cooling
- Add new boards:
  * ASUS Chromebook Flip CM3
  * ASUS Chromebook Detachable CM3
  * Acer Chromebook Spin 311
  * Lenovo 10e Chromebook Tablet

MT8173:
- fix PHY property in DSI
- fix power-domain for PMIC wrapper

Pumkin:
- add MT8516 based board
- add MT8183 based board
- fix reset pin for MT8167 and MT8516 based boards

----------------------------------------------------------------
Chunfeng Yun (8):
      arm64: dts: mt8183: update wakeup register offset
      arm64: dts: mt8173: fix property typo of 'phys' in dsi node
      arm64: dts: mediatek: mt8173: fix dtbs_check warning
      arm64: dts: mediatek: mt2712: harmonize node names
      arm64: dts: mediatek: mt8516: harmonize node names and compatibles
      arm64: dts: mediatek: mt7622: harmonize node names and compatibles
      arm64: dts: mediatek: mt8183: fix dtbs_check warning
      arm64: dts: mt8173: fix wrong power-domain phandle of pmic

Fabien Parent (4):
      dt-bindings: arm64: dts: mediatek: Add mt8516-pumpkin board
      dt-bindings: arm64: dts: mediatek: Add mt8183-pumpkin board
      arm64: dts: mt8183: add mt8183 pumpkin board
      arm64: dts: mediatek: fix reset GPIO level on pumpkin

Hsin-Yi Wang (9):
      arm64: dts: mediatek: mt8183: evb: Add domain supply for mfg
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-damu
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-juniper
      arm64: dts: mt8183: Add kukui-jacuzzi-damu board
      arm64: dts: mt8183: Add kukui-jacuzzi-juniper board
      arm64: dts: mt8183: Add gce client reg for display subcomponents
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-kakadu
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-kodama
      arm64: dts: mt8183: Add kukui kodama board

Matthias Kaehlcke (1):
      arm64: dts: mt8183: Configure CPU cooling

Nicolas Boichat (1):
      arm64: dts: mt8183: Add kukui kakadu board

Ryan Wu (1):
      dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC

Ryder Lee (1):
      arm64: dts: mt7622: add ePA/eLNA pinmux for built-in WiFi

Seiya Wang (3):
      dt-bindings: timer: Add compatible for Mediatek MT8195
      dt-bindings: serial: Add compatible for Mediatek MT8195
      dt-bindings: arm: Add compatible for Mediatek MT8195

michael.kao (1):
      arm64: dts: mt8183: add thermal zone node

 .../devicetree/bindings/arm/mediatek.yaml          |  36 ++
 .../devicetree/bindings/nvmem/mtk-efuse.txt        |   1 +
 .../devicetree/bindings/serial/mtk-uart.txt        |   1 +
 .../bindings/timer/mediatek,mtk-timer.txt          |   1 +
 arch/arm64/boot/dts/mediatek/Makefile              |   8 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi          |   8 +-
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts       |  12 +
 arch/arm64/boot/dts/mediatek/mt7622.dtsi           |   9 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts        |   6 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  15 +-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts        |   4 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-damu.dts     |  31 ++
 .../mt8183-kukui-jacuzzi-juniper-sku16.dts         |  13 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi |  27 ++
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi    | 474 +++++++++++++++++++++
 .../boot/dts/mediatek/mt8183-kukui-kakadu.dts      |  13 +
 .../boot/dts/mediatek/mt8183-kukui-kakadu.dtsi     | 378 ++++++++++++++++
 .../dts/mediatek/mt8183-kukui-kodama-sku16.dts     |  21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku272.dts    |  21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku288.dts    |  21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku32.dts     |  21 +
 .../boot/dts/mediatek/mt8183-kukui-kodama.dtsi     | 343 +++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts    | 378 ++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi           | 158 ++++++-
 arch/arm64/boot/dts/mediatek/mt8516.dtsi           |   9 +-
 arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi   |   3 +-
 26 files changed, 1982 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
 create mode 100644
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts


From matthias.bgg at gmail.com  Thu Apr  1 15:19:45 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 1 Apr 2021 16:19:45 +0200
Subject: [GIT PULL] soc: mediatek: changes for v5.13
Message-ID: <c47d4bdd-9e05-c0de-bacb-3a262fed936d@gmail.com>

Hi Arnd and Olof,

Below you can find the changes for the SoC drivers. After we fixed in the last
round the power management domain driver. This time it is the MMSYS driver. Up
to now it held one big table with routing information for all SoCs. But that's
not practical over time, so that was splitten up to add only per SoC structures.
That should make it easier in the future to add support for new SoCs. At least
one series didn't hit mainline this time, but should be ready for the next round.

Please take the patches into account for your pull request.

Regards,
Matthias

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-soc

for you to fetch changes up to 60d93f64a851d276b23b7ef68ddc638258485d32:

  soc: mediatek: pm-domains: Add a power domain names for mt8167 (2021-04-01
11:36:04 +0200)

----------------------------------------------------------------
- add MT8183 support to mutex driver

MMSYS:
- use per SoC array to describe the possible routing
- add support for MT8183

Power management domains:
- fix the case of a domain fails to get added
- add names for each power domain to make debugging easier

PMIC wrapper:
- add support for PMIC wrapper with integrated arbiter
- add support for MT8192/MT6873

----------------------------------------------------------------
CK Hu (2):
      soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
      soc: mediatek: mmsys: Use an array for setting the routing registers

Enric Balletbo i Serra (5):
      soc: mediatek: pm-domains: Fix missing error code in scpsys_add_subdomain()
      soc: mediatek: pm-domains: Add a meaningful power domain name
      soc: mediatek: pm-domains: Add a power domain names for mt8183
      soc: mediatek: pm-domains: Add a power domain names for mt8192
      soc: mediatek: pm-domains: Add a power domain names for mt8167

Hsin-Hsiung Wang (4):
      soc: mediatek: pwrap: use BIT() macro
      soc: mediatek: pwrap: add arbiter capability
      dt-bindings: mediatek: add compatible for MT6873/8192 pwrap
      soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs

Hsin-Yi Wang (1):
      soc: mediatek: mmsys: Add mt8183 mmsys routing table

Wei Yongjun (1):
      soc: mediatek: Make symbol 'mtk_mutex_driver' static

Yongqiang Niu (1):
      soc: mediatek: add mtk mutex support for MT8183

 .../devicetree/bindings/soc/mediatek/pwrap.txt     |   1 +
 drivers/soc/mediatek/mt8167-pm-domains.h           |   7 +
 drivers/soc/mediatek/mt8173-pm-domains.h           |  10 +
 drivers/soc/mediatek/mt8183-mmsys.h                |  54 ++++
 drivers/soc/mediatek/mt8183-pm-domains.h           |  15 +
 drivers/soc/mediatek/mt8192-pm-domains.h           |  21 ++
 drivers/soc/mediatek/mtk-mmsys.c                   | 303 +++------------------
 drivers/soc/mediatek/mtk-mmsys.h                   | 215 +++++++++++++++
 drivers/soc/mediatek/mtk-mutex.c                   |  52 +++-
 drivers/soc/mediatek/mtk-pm-domains.c              |  11 +-
 drivers/soc/mediatek/mtk-pm-domains.h              |   2 +
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  97 ++++++-
 12 files changed, 511 insertions(+), 277 deletions(-)
 create mode 100644 drivers/soc/mediatek/mt8183-mmsys.h
 create mode 100644 drivers/soc/mediatek/mtk-mmsys.h


From broonie at kernel.org  Thu Apr  1 15:27:59 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 15:27:59 +0100
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <20210330190955.13707-4-madvenka@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
Message-ID: <20210401142759.GJ4758@sirena.org.uk>

On Tue, Mar 30, 2021 at 02:09:54PM -0500, madvenka at linux.microsoft.com wrote:

> +	 * FTRACE trampolines.
> +	 */
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> +	{ (unsigned long) &ftrace_graph_call, 0 },
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +	{ (unsigned long) ftrace_graph_caller, 0 },
> +	{ (unsigned long) return_to_handler, 0 },
> +#endif
> +#endif

It's weird that we take the address of ftrace_graph_call but not the
other functions - we should be consistent or explain why.  It'd probably
also look nicer to not nest the ifdefs, the dependencies in Kconfig will
ensure we only get things when we should.
-------------- 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/20210401/372d547f/attachment-0001.sig>

From pmladek at suse.com  Thu Apr  1 15:37:50 2021
From: pmladek at suse.com (Petr Mladek)
Date: Thu, 1 Apr 2021 16:37:50 +0200
Subject: [PATCH printk v2 3/5] printk: remove NMI tracking
In-Reply-To: <20210330153512.1182-4-john.ogness@linutronix.de>
References: <20210330153512.1182-1-john.ogness@linutronix.de>
 <20210330153512.1182-4-john.ogness@linutronix.de>
Message-ID: <YGXavg8+f9i1PZLn@alley>

On Tue 2021-03-30 17:35:10, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
> 
> Signed-off-by: John Ogness <john.ogness at linutronix.de>

This is another great win!

Reviewed-by: Petr Mladek <pmladek at suse.com>

Best Regards,
Petr


From Claudiu.Beznea at microchip.com  Thu Apr  1 15:42:47 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 1 Apr 2021 14:42:47 +0000
Subject: [PATCH] power: reset: at91-reset: free resources on exit path
In-Reply-To: <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
References: <20210209110109.906034-1-claudiu.beznea@microchip.com>
 <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
Message-ID: <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>

On 31.03.2021 11:18, Nicolas Ferre wrote:
> On 09/02/2021 at 12:01, Claudiu Beznea wrote:
>> Free resources on exit path (failure path of probe and remove).
> 
> I'm not sure we can use this driver as a module anyway.
> 
> Otherwise, it looks fine, but isn't it possible to use devm_of_iomap(),
> even in loop, and avoid having to deal with exit path?

For:
reset->rstc_base = of_iomap(pdev->dev.of_node, 0);

it should work.

For the maps in the loop I have to double check. Basically, the struct
resource object to pass to devm_of_iomap() is needed and for this the
pointer to a struct platform_device object corresponding to the node we
look for in the loop is needed. So, I think this cannot be done this way.

> 
>> Reported-by: kernel test robot <lkp at intel.com>
>> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
>> ? drivers/power/reset/at91-reset.c | 25 ++++++++++++++++++++-----
>> ? 1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/power/reset/at91-reset.c
>> b/drivers/power/reset/at91-reset.c
>> index 3ff9d93a5226..2ff7833153b6 100644
>> --- a/drivers/power/reset/at91-reset.c
>> +++ b/drivers/power/reset/at91-reset.c
>> @@ -206,7 +206,8 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> ????????????? if (!reset->ramc_base[idx]) {
>> ????????????????? dev_err(&pdev->dev, "Could not map ram controller
>> address\n");
>> ????????????????? of_node_put(np);
>> -??????????????? return -ENODEV;
>> +??????????????? ret = -ENODEV;
>> +??????????????? goto unmap;
>> ????????????? }
>> ????????????? idx++;
>> ????????? }
>> @@ -218,13 +219,15 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> ????? reset->args = (u32)match->data;
>> ? ????? reset->sclk = devm_clk_get(&pdev->dev, NULL);
>> -??? if (IS_ERR(reset->sclk))
>> -??????? return PTR_ERR(reset->sclk);
>> +??? if (IS_ERR(reset->sclk)) {
>> +??????? ret = PTR_ERR(reset->sclk);
>> +??????? goto unmap;
>> +??? }
>> ? ????? ret = clk_prepare_enable(reset->sclk);
>> ????? if (ret) {
>> ????????? dev_err(&pdev->dev, "Could not enable slow clock\n");
>> -??????? return ret;
>> +??????? goto unmap;
>> ????? }
>> ? ????? platform_set_drvdata(pdev, reset);
>> @@ -239,21 +242,33 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> ????? ret = register_restart_handler(&reset->nb);
>> ????? if (ret) {
>> ????????? clk_disable_unprepare(reset->sclk);
>> -??????? return ret;
>> +??????? goto unmap;
>> ????? }
>> ? ????? at91_reset_status(pdev, reset->rstc_base);
>> ? ????? return 0;
>> +
>> +unmap:
>> +??? iounmap(reset->rstc_base);
>> +??? for (idx = 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>> +??????? iounmap(reset->ramc_base[idx]);
> 
> But if we keep this loop, I have the feeling that some kind of
> "of_node_put()" is needed as well.

No! In the loop:

for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
	reset->ramc_lpr = (u32)match->data;
	reset->ramc_base[idx] = of_iomap(np, 0);
	if (!reset->ramc_base[idx]) {
		dev_err(&pdev->dev, "Could not map ram controller address\n");
		of_node_put(np);
		ret = -ENODEV;
		goto unmap;
	}
	idx++;
}

the of_node_put() is needed only if the loop is interrupted as the macro:
for_each_matching_node_and_match() is defined as follows:

#define for_each_matching_node_and_match(dn, matches, match) \
	for (dn = of_find_matching_node_and_match(NULL, matches, match); \
	     dn; dn = of_find_matching_node_and_match(dn, matches, match))

and of_find_matching_node_and_match() will return a np with refcount
incremented but at the next loop step the of_find_matching_node_and_match()
will be called with the same np pointer and the np refcount will be
decremented.

struct device_node *of_find_matching_node_and_match(
		struct device_node *from,
		const struct of_device_id *matches,
		const struct of_device_id **match)
{
	// ...
	of_node_put(from);
	// ...
}

> 
>> +
>> +??? return ret;
>> ? }
>> ? ? static int __exit at91_reset_remove(struct platform_device *pdev)
>> ? {
>> ????? struct at91_reset *reset = platform_get_drvdata(pdev);
>> +??? int idx;
>> ? ????? unregister_restart_handler(&reset->nb);
>> ????? clk_disable_unprepare(reset->sclk);
>> ? +??? iounmap(reset->rstc_base);
>> +??? for (idx = 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>> +??????? iounmap(reset->ramc_base[idx]);
> 
> Ditto
> 
>> +
>> ????? return 0;
>> ? }
>> ?
> 
> 



From Claudiu.Beznea at microchip.com  Thu Apr  1 15:50:14 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 1 Apr 2021 14:50:14 +0000
Subject: [PATCH] power: reset: at91-reset: free resources on exit path
In-Reply-To: <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
References: <20210209110109.906034-1-claudiu.beznea@microchip.com>
 <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
 <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
Message-ID: <5fbc077d-1f45-6bc0-8d73-6008c6a28e76@microchip.com>

On 01.04.2021 17:42, Claudiu Beznea - M18063 wrote:
> On 31.03.2021 11:18, Nicolas Ferre wrote:
>> On 09/02/2021 at 12:01, Claudiu Beznea wrote:
>>> Free resources on exit path (failure path of probe and remove).
>>
>> I'm not sure we can use this driver as a module anyway.
>>
>> Otherwise, it looks fine, but isn't it possible to use devm_of_iomap(),
>> even in loop, and avoid having to deal with exit path?
> 
> For:
> reset->rstc_base = of_iomap(pdev->dev.of_node, 0);
> 
> it should work.
> 
> For the maps in the loop I have to double check. Basically, the struct
> resource object to pass to devm_of_iomap() is needed and for this the

Just realized I looked at the wrong code. Anyway, I'll double check and return.

> pointer to a struct platform_device object corresponding to the node we
> look for in the loop is needed. So, I think this cannot be done this way.
> 
>>
>>> Reported-by: kernel test robot <lkp at intel.com>
>>> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>>> ---
>>> ? drivers/power/reset/at91-reset.c | 25 ++++++++++++++++++++-----
>>> ? 1 file changed, 20 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/power/reset/at91-reset.c
>>> b/drivers/power/reset/at91-reset.c
>>> index 3ff9d93a5226..2ff7833153b6 100644
>>> --- a/drivers/power/reset/at91-reset.c
>>> +++ b/drivers/power/reset/at91-reset.c
>>> @@ -206,7 +206,8 @@ static int __init at91_reset_probe(struct
>>> platform_device *pdev)
>>> ????????????? if (!reset->ramc_base[idx]) {
>>> ????????????????? dev_err(&pdev->dev, "Could not map ram controller
>>> address\n");
>>> ????????????????? of_node_put(np);
>>> -??????????????? return -ENODEV;
>>> +??????????????? ret = -ENODEV;
>>> +??????????????? goto unmap;
>>> ????????????? }
>>> ????????????? idx++;
>>> ????????? }
>>> @@ -218,13 +219,15 @@ static int __init at91_reset_probe(struct
>>> platform_device *pdev)
>>> ????? reset->args = (u32)match->data;
>>> ? ????? reset->sclk = devm_clk_get(&pdev->dev, NULL);
>>> -??? if (IS_ERR(reset->sclk))
>>> -??????? return PTR_ERR(reset->sclk);
>>> +??? if (IS_ERR(reset->sclk)) {
>>> +??????? ret = PTR_ERR(reset->sclk);
>>> +??????? goto unmap;
>>> +??? }
>>> ? ????? ret = clk_prepare_enable(reset->sclk);
>>> ????? if (ret) {
>>> ????????? dev_err(&pdev->dev, "Could not enable slow clock\n");
>>> -??????? return ret;
>>> +??????? goto unmap;
>>> ????? }
>>> ? ????? platform_set_drvdata(pdev, reset);
>>> @@ -239,21 +242,33 @@ static int __init at91_reset_probe(struct
>>> platform_device *pdev)
>>> ????? ret = register_restart_handler(&reset->nb);
>>> ????? if (ret) {
>>> ????????? clk_disable_unprepare(reset->sclk);
>>> -??????? return ret;
>>> +??????? goto unmap;
>>> ????? }
>>> ? ????? at91_reset_status(pdev, reset->rstc_base);
>>> ? ????? return 0;
>>> +
>>> +unmap:
>>> +??? iounmap(reset->rstc_base);
>>> +??? for (idx = 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>>> +??????? iounmap(reset->ramc_base[idx]);
>>
>> But if we keep this loop, I have the feeling that some kind of
>> "of_node_put()" is needed as well.
> 
> No! In the loop:
> 
> for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
> 	reset->ramc_lpr = (u32)match->data;
> 	reset->ramc_base[idx] = of_iomap(np, 0);
> 	if (!reset->ramc_base[idx]) {
> 		dev_err(&pdev->dev, "Could not map ram controller address\n");
> 		of_node_put(np);
> 		ret = -ENODEV;
> 		goto unmap;
> 	}
> 	idx++;
> }
> 
> the of_node_put() is needed only if the loop is interrupted as the macro:
> for_each_matching_node_and_match() is defined as follows:
> 
> #define for_each_matching_node_and_match(dn, matches, match) \
> 	for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> 	     dn; dn = of_find_matching_node_and_match(dn, matches, match))
> 
> and of_find_matching_node_and_match() will return a np with refcount
> incremented but at the next loop step the of_find_matching_node_and_match()
> will be called with the same np pointer and the np refcount will be
> decremented.
> 
> struct device_node *of_find_matching_node_and_match(
> 		struct device_node *from,
> 		const struct of_device_id *matches,
> 		const struct of_device_id **match)
> {
> 	// ...
> 	of_node_put(from);
> 	// ...
> }
> 
>>
>>> +
>>> +??? return ret;
>>> ? }
>>> ? ? static int __exit at91_reset_remove(struct platform_device *pdev)
>>> ? {
>>> ????? struct at91_reset *reset = platform_get_drvdata(pdev);
>>> +??? int idx;
>>> ? ????? unregister_restart_handler(&reset->nb);
>>> ????? clk_disable_unprepare(reset->sclk);
>>> ? +??? iounmap(reset->rstc_base);
>>> +??? for (idx = 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>>> +??????? iounmap(reset->ramc_base[idx]);
>>
>> Ditto
>>
>>> +
>>> ????? return 0;
>>> ? }
>>> ?
>>
>>
> 



From dmugil2000 at gmail.com  Thu Apr  1 15:52:47 2021
From: dmugil2000 at gmail.com (Mugilraj D)
Date: Thu, 1 Apr 2021 20:22:47 +0530
Subject: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
In-Reply-To: <20210401113015.00006b70@Huawei.com>
References: <20210401062517.28832-1-dmugil2000@gmail.com>
 <CAHp75VfgL0KW0fetgE3NuBb4itMK1oY+yLmr1xDYkn390hCscg@mail.gmail.com>
 <20210401113015.00006b70@Huawei.com>
Message-ID: <a2ac91a9-54e3-2525-1e7e-00a26d3393e3@gmail.com>



On 01/04/21 4:00 pm, Jonathan Cameron wrote:
> On Thu, 1 Apr 2021 12:24:50 +0300
> Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
> 
>> On Thu, Apr 1, 2021 at 9:27 AM Mugilraj Dhavachelvan
>> <dmugil2000 at gmail.com> wrote:
>>>
>>> Change function's name to %s and __func__ to fix checkpatch.pl errors.  
>>
>> No, just drop the __func__ completely. First of all, we have a device
>> name, and uniqueness of the messages in the driver should guarantee
>> easy findings. Second, specific to _dbg() variants, with enabled
>> Dynamic Debug it can be chosen at run time!
>>
>> I recommend going through all drivers and drop __func__ near to
>> dev_dbg() and pr_debug().
>>
> 
> Agreed.  Though beware that some maintainers will count this
> as noise and get grumpy.
> 
> I'm fine with such patches for IIO.

Sorry for the noise. I just seen the docs about dynamic debug.
So, if we use dev_dbg("log_msg") it will print statement like
filename:lineno [module]func flag log_msg, If I get it correctly.
And no need of specifying __func__ in dev_dbg() and dp_dbg() right!!

Jonathan do you have any TODO's?

> 
> Jonathan
> 


From jan.kiszka at web.de  Thu Apr  1 15:52:46 2021
From: jan.kiszka at web.de (Jan Kiszka)
Date: Thu, 1 Apr 2021 16:52:46 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
Message-ID: <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>

On 01.04.21 13:42, Michal Simek wrote:
> Hi Jan,
>
> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>> On 07.11.19 10:44, Rajan Vaja wrote:
>>> Add clock nodes for zynqmp based on CCF.
>>>
>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>> ---
>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>> new file mode 100644
>>> index 0000000..9868ca1
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>> @@ -0,0 +1,222 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Clock specification for Xilinx ZynqMP
>>> + *
>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>> + *
>>> + * Michal Simek <michal.simek at xilinx.com>
>>> + */
>>> +
>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>> +/ {
>>> +	pss_ref_clk: pss_ref_clk {
>>> +		u-boot,dm-pre-reloc;
>>> +		compatible = "fixed-clock";
>>> +		#clock-cells = <0>;
>>> +		clock-frequency = <33333333>;
>>> +	};
>>> +
>>> +	video_clk: video_clk {
>>> +		u-boot,dm-pre-reloc;
>>> +		compatible = "fixed-clock";
>>> +		#clock-cells = <0>;
>>> +		clock-frequency = <27000000>;
>>> +	};
>>> +
>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>> +		u-boot,dm-pre-reloc;
>>> +		compatible = "fixed-clock";
>>> +		#clock-cells = <0>;
>>> +		clock-frequency = <0>;
>>> +	};
>>> +
>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>> +		u-boot,dm-pre-reloc;
>>> +		compatible = "fixed-clock";
>>> +		#clock-cells = <0>;
>>> +		clock-frequency = <108000000>;
>>> +	};
>>> +
>>> +	aux_ref_clk: aux_ref_clk {
>>> +		u-boot,dm-pre-reloc;
>>> +		compatible = "fixed-clock";
>>> +		#clock-cells = <0>;
>>> +		clock-frequency = <27000000>;
>>> +	};
>>> +};
>>> +
>>> +&can0 {
>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&can1 {
>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&cpu0 {
>>> +	clocks = <&zynqmp_clk ACPU>;
>>> +};
>>> +
>>> +&fpd_dma_chan1 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan2 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan3 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan4 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan5 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan6 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan7 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&fpd_dma_chan8 {
>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan1 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan2 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan3 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan4 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan5 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan6 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan7 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&lpd_dma_chan8 {
>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&gem0 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>> +		 <&zynqmp_clk GEM_TSU>;
>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>> +};
>>> +
>>> +&gem1 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>> +		 <&zynqmp_clk GEM_TSU>;
>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>> +};
>>> +
>>> +&gem2 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>> +		 <&zynqmp_clk GEM_TSU>;
>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>> +};
>>> +
>>> +&gem3 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>> +		 <&zynqmp_clk GEM_TSU>;
>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>> +};
>>> +
>>> +&gpio {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&i2c0 {
>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>> +};
>>> +
>>> +&i2c1 {
>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>> +};
>>> +
>>> +&pcie {
>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>> +};
>>> +
>>> +&sata {
>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>> +};
>>> +
>>> +&sdhci0 {
>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&sdhci1 {
>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&spi0 {
>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&spi1 {
>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&ttc0 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&ttc1 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&ttc2 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&ttc3 {
>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&uart0 {
>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&uart1 {
>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>> +};
>>> +
>>> +&usb0 {
>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>> +};
>>> +
>>> +&usb1 {
>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>> +};
>>> +
>>> +&watchdog0 {
>>> +	clocks = <&zynqmp_clk WDT>;
>>> +};
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>> index 0f7b4cf..2e05fa4 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZC1232
>>>   *
>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>
>>>  / {
>>>  	model = "ZynqMP ZC1232 RevA";
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>> index 9092828..3d0aaa0 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZC1254
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>> @@ -11,7 +11,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>
>>>  / {
>>>  	model = "ZynqMP ZC1254 RevA";
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>> index 4f404c5..1a8127d4 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>> @@ -11,7 +11,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>
>>>  / {
>>>  	model = "ZynqMP ZC1275 RevA";
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>> index 9a3e39d..fa7eb1b 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>>  / {
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>> index 2421ec7..4191dfa 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>>  / {
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>> index 7a49dee..3750690 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>   *
>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>
>>>  / {
>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>> index 54c7b4f..2366cd9 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>
>>>  / {
>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>> index b8b5ff1..9a894e6 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>   * Michal Simek <michal.simek at xilinx.com>
>>> @@ -11,7 +11,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>>  / {
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>> index e5699d0..3e39454 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>   *
>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   * Nathalie Chan King Choy
>>> @@ -11,7 +11,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>> index 2a3b665..f6e9558 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>   *
>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>> index 8f45614..f457f8a 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZCU104
>>>   *
>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>>  / {
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>> index 93ce7eb..f15b99a 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZCU106
>>>   *
>>> - * (C) Copyright 2016, Xilinx, Inc.
>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>> index 8bb0001..e27cd60 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP ZCU111
>>>   *
>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   */
>>> @@ -10,7 +10,7 @@
>>>  /dts-v1/;
>>>
>>>  #include "zynqmp.dtsi"
>>> -#include "zynqmp-clk.dtsi"
>>> +#include "zynqmp-clk-ccf.dtsi"
>>>  #include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>>
>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>> index 9aa6734..59a547b 100644
>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>> @@ -2,7 +2,7 @@
>>>  /*
>>>   * dts file for Xilinx ZynqMP
>>>   *
>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>   *
>>>   * Michal Simek <michal.simek at xilinx.com>
>>>   *
>>> @@ -124,6 +124,28 @@
>>>  			     <1 10 0xf08>;
>>>  	};
>>>
>>> +	firmware {
>>> +		zynqmp_firmware: zynqmp-firmware {
>>> +			compatible = "xlnx,zynqmp-firmware";
>>> +			method = "smc";
>>> +			zynqmp_clk: clock-controller {
>>> +				u-boot,dm-pre-reloc;
>>> +				#clock-cells = <1>;
>>> +				compatible = "xlnx,zynqmp-clk";
>>> +				clocks = <&pss_ref_clk>,
>>> +					 <&video_clk>,
>>> +					 <&pss_alt_ref_clk>,
>>> +					 <&aux_ref_clk>,
>>> +					 <&gt_crx_ref_clk>;
>>> +				clock-names = "pss_ref_clk",
>>> +					      "video_clk",
>>> +					      "pss_alt_ref_clk",
>>> +					      "aux_ref_clk",
>>> +					      "gt_crx_ref_clk";
>>> +			};
>>> +		};
>>> +	};
>>> +
>>>  	amba_apu: amba-apu at 0 {
>>>  		compatible = "simple-bus";
>>>  		#address-cells = <2>;
>>>
>>
>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>> Starting from this commit on, I'm no longer getting the kernel to boot
>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>> DTBs back before this commit, even a kernel from today's head is fine.
>>
>> Further versions of potential relevance:
>>  - PMUFW 2019.1 and 2020.2
>>  - TF-A 2.3
>>  - U-Boot 2020.10
>>
>> What's missing? I suspect someone forgot to document a subtle dependency
>> of this change.
>
> Does this fix your issue?
> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>

Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
missing even more. If you have some reference, I'm happy to try. I
suspect that earlyprintk will also not reveal more without clocks (but I
didn't play with that yet).

Meanwhile, I'm carrying a revert of this commit and a related cleanup.
That helps for now.

Jan


From i.uvarov at cognitivepilot.com  Thu Apr  1 15:55:37 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Thu, 1 Apr 2021 17:55:37 +0300
Subject: [PATCH v3 3/4] dt-bindings: arm: add compatible strings for
 Forlinx OKA40i-C
In-Reply-To: <20210401094001.sh3nvkj5psbdcig5@gilmour>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
 <20210401094001.sh3nvkj5psbdcig5@gilmour>
Message-ID: <20210401175420.39b75553@NervousEnergy>

On Thu, 1 Apr 2021 11:40:01 +0200
Maxime Ripard <maxime at cerno.tech> wrote:

> On Wed, Mar 31, 2021 at 06:56:15PM +0300, Ivan Uvarov wrote:
> > The OKA40i-C is a carrier/development board for the Forlinx
> > FETA40i-C SoM based on the Allwinner R40/A40i SoC.
> > 
> > This patch adds the relevant dt-binding documentation in
> > preparation for the next patch, which adds a devicetree for the SoM
> > and board.
> > 
> > Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> > 
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > b/Documentation/devicetree/bindings/arm/sunxi.yaml index
> > 08607c7ec1..74f8decd78 100644 ---
> > a/Documentation/devicetree/bindings/arm/sunxi.yaml +++
> > b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -224,6
> > +224,12 @@ properties:
> >            - const: empire-electronix,m712
> >            - const: allwinner,sun5i-a13
> >  
> > +      - description: Forlinx OKA40i-C Development board
> > +        items:
> > +          - const: forlinx,oka40i-c
> > +          - const: forlinx,feta40i-c
> > +          - const: allwinner,sun8i-r40
> > +
> >        - description: FriendlyARM NanoPi A64
> >          items:
> >            - const: friendlyarm,nanopi-a64
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > b/Documentation/devicetree/bindings/vendor-prefixes.yaml index
> > f6064d84a4..e2ea1a731e 100644 ---
> > a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++
> > b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -403,6
> > +403,8 @@ patternProperties: description: Firefly
> >    "^focaltech,.*":
> >      description: FocalTech Systems Co.,Ltd
> > +  "^forlinx,.*":
> > +    description: Baoding Forlinx Embedded Technology Co., Ltd.
> >    "^frida,.*":
> >      description: Shenzhen Frida LCD Co., Ltd.
> >    "^friendlyarm,.*":
> > -- 
> > 2.25.1  
> 
> This part needs to be in a separate patch too
> 
> Maxime
> 

As in, a separate patch for just the vendor prefix?

--
Regards,
Ivan Uvarov


From robh at kernel.org  Thu Apr  1 15:56:21 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 01 Apr 2021 09:56:21 -0500
Subject: [PATCH v2 3/3] dt-bindings: serial: 8250: add aspeed,
 sirq-active-high
In-Reply-To: <20210401005702.28271-4-zev@bewilderbeest.net>
References: <YGOuhjD19SmjmQou@hatter.bewilderbeest.net>
 <20210401005702.28271-1-zev@bewilderbeest.net>
 <20210401005702.28271-4-zev@bewilderbeest.net>
Message-ID: <1617288981.559685.409158.nullmailer@robh.at.kernel.org>

On Wed, 31 Mar 2021 19:57:02 -0500, Zev Weiss wrote:
> This provides a simpler, more direct alternative to the deprecated
> aspeed,sirq-polarity-sense property for indicating the polarity of
> the Aspeed VUART's SIRQ line.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  Documentation/devicetree/bindings/serial/8250.yaml | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/serial/8250.yaml:16:30: [warning] too few spaces after comma (commas)
./Documentation/devicetree/bindings/serial/8250.yaml:17:30: [warning] too few spaces after comma (commas)

dtschema/dtc warnings/errors:

See https://patchwork.ozlabs.org/patch/1460791

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From i.uvarov at cognitivepilot.com  Thu Apr  1 15:59:38 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Thu, 1 Apr 2021 17:59:38 +0300
Subject: [PATCH v3 4/4] ARM: dts: sun8i: r40: add devicetree for Forlinx
 FETA40i-C & OKA40i-C
In-Reply-To: <20210401094356.zhijxfoihw73ha7k@gilmour>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
 <20210401094356.zhijxfoihw73ha7k@gilmour>
Message-ID: <20210401175938.1f6d065c@NervousEnergy>

On Thu, 1 Apr 2021 11:43:56 +0200
Maxime Ripard <maxime at cerno.tech> wrote:

> On Wed, Mar 31, 2021 at 06:56:16PM +0300, Ivan Uvarov wrote:
> > The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i.
> > 
> > SoM specifications:
> > 
> > - SoC: R40 or A40i
> > - PMIC: AXP221S
> > - RAM: 1GiB/2GiB DDR3 (dual-rank)
> > - eMMC: 8GB,
> > - Mates with carrier board via four 80-pin connectors
> > (AXK6F80337YG).
> > 
> > OKA40i-C is a carrier board by the same manufacturer for this SoM,
> > whose main purpose is as a development board with a wide variety of
> > peripherals:
> > 
> > - Power: DC5V barrel or USB OTG or 4.2V Lipo battery
> > - Video out: HDMI, TV out, LVDS
> > - WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT
> > V2.1/3.0/4.0)
> > - Ethernet: 10/100Mbps
> > - Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
> > - USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG
> > (micro-B)
> > - UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
> > - Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
> > - Mini PCIe slot with sim holder for WLAN modem
> > - Smart card holder
> > - RTC (RX8010SJ)
> > - Two user LEDs
> > - Three user buttons (via KeyADC).
> > 
> > This patch adds a devicetree for the aforementioned SoM and
> > devboard. In order to reflect the modularity of this devboard and
> > simplify adding support for future hardware based on the same SoM,
> > the devicetree is split: Everything pertaining to the SoM itself is
> > described in a separate .dtsi file, which is included by the
> > devboard's .dts.
> > 
> > Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> > 
> >  3 files changed, 310 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 8e5d4ab4e7..88aae9de95 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -1222,6 +1222,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >  	sun8i-r16-nintendo-super-nes-classic.dtb \
> >  	sun8i-r16-parrot.dtb \
> >  	sun8i-r40-bananapi-m2-ultra.dtb \
> > +	sun8i-r40-oka40i-c.dtb \
> >  	sun8i-s3-elimo-initium.dtb \
> >  	sun8i-s3-lichee-zero-plus.dtb \
> >  	sun8i-s3-pinecube.dtb \
> > diff --git a/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> > b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi new file mode 100644
> > index 0000000000..265e0fa57a
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
> > @@ -0,0 +1,106 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> > +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> > +//  Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> > +//  Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> > +
> > +#include "sun8i-r40.dtsi"
> > +
> > +&i2c0 {
> > +	status = "okay";
> > +
> > +	axp22x: pmic at 34 {
> > +		compatible = "x-powers,axp221";
> > +		reg = <0x34>;
> > +		interrupt-parent = <&nmi_intc>;
> > +		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> > +};
> > +
> > +#include "axp22x.dtsi"
> > +
> > +&mmc2 {
> > +	vmmc-supply = <&reg_dcdc1>;
> > +	vqmmc-supply = <&reg_aldo2>;
> > +	bus-width = <8>;
> > +	non-removable;
> > +	status = "okay";
> > +};
> > +
> > +&pio {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&clk_out_a_pin>;
> > +	vcc-pa-supply = <&reg_dcdc1>;
> > +	vcc-pc-supply = <&reg_aldo2>;
> > +	vcc-pd-supply = <&reg_dcdc1>;
> > +	vcc-pf-supply = <&reg_dldo4>;
> > +	vcc-pg-supply = <&reg_dldo1>;
> > +};
> > +
> > +&reg_aldo2 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <1800000>;
> > +	regulator-max-microvolt = <1800000>;
> > +	regulator-name = "vcc-pa";
> > +};
> > +
> > +&reg_aldo3 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <3000000>;
> > +	regulator-max-microvolt = <3000000>;
> > +	regulator-name = "avcc";
> > +};
> > +
> > +&reg_dcdc1 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <3300000>;
> > +	regulator-max-microvolt = <3300000>;
> > +	regulator-name = "vcc-3v3";
> > +};
> > +
> > +&reg_dcdc2 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <1100000>;
> > +	regulator-max-microvolt = <1100000>;
> > +	regulator-name = "vdd-cpu";
> > +};
> > +
> > +&reg_dcdc3 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <1100000>;
> > +	regulator-max-microvolt = <1100000>;
> > +	regulator-name = "vdd-sys";
> > +};
> > +
> > +&reg_dcdc5 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <1500000>;
> > +	regulator-max-microvolt = <1500000>;
> > +	regulator-name = "vcc-dram";
> > +};
> > +
> > +&reg_dldo1 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <3300000>;
> > +	regulator-max-microvolt = <3300000>;
> > +	regulator-name = "vcc-wifi-io";
> > +};
> > +
> > +&reg_dldo4 {
> > +	regulator-always-on;
> > +	regulator-min-microvolt = <2500000>;
> > +	regulator-max-microvolt = <2500000>;
> > +	regulator-name = "vdd2v5-sata";
> > +};
> > +
> > +&reg_eldo2 {
> > +	regulator-min-microvolt = <1200000>;
> > +	regulator-max-microvolt = <1200000>;
> > +	regulator-name = "vdd1v2-sata";
> > +};
> > +
> > +&reg_eldo3 {
> > +	regulator-min-microvolt = <2800000>;
> > +	regulator-max-microvolt = <2800000>;
> > +	regulator-name = "vcc-pe";
> > +};
> > diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> > b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts new file mode 100644
> > index 0000000000..9305fda8d1
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
> > @@ -0,0 +1,203 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
> > +// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
> > +//	Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
> > +//	Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
> > +
> > +/dts-v1/;
> > +#include "sun8i-r40-feta40i.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > +	model = "Forlinx OKA40i-C";
> > +	compatible = "forlinx,oka40i-c", "forlinx,feta40i-c",
> > "allwinner,sun8i-r40"; +
> > +	aliases {
> > +		ethernet0 = &gmac;
> > +		serial0 = &uart0;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +		serial4 = &uart4;
> > +		serial5 = &uart5; /* RS485 */
> > +		serial7 = &uart7;
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = "serial0:115200n8";
> > +	};
> > +
> > +	connector {
> > +		compatible = "hdmi-connector";
> > +		type = "a";
> > +
> > +		port {
> > +			hdmi_con_in: endpoint {
> > +				remote-endpoint = <&hdmi_out_con>;
> > +			};
> > +		};
> > +	};
> > +
> > +	leds {
> > +		compatible = "gpio-leds";
> > +
> > +		led-5 {
> > +			gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /*
> > PH26 */
> > +			color = <LED_COLOR_ID_GREEN>;
> > +			function = LED_FUNCTION_STATUS;
> > +		};
> > +
> > +		led-6 {
> > +			gpios = <&pio 8 15 GPIO_ACTIVE_LOW>; /*
> > PI15 */
> > +			color = <LED_COLOR_ID_BLUE>;
> > +			function = LED_FUNCTION_STATUS;
> > +		};  
> 
> led-5 and led-6? You can start at 0 :)
> 
> Looks good otherwise, thanks
> 
> Maxime

This is how they are labeled on the board, so I kept the names. Should
I rename them anyway?

--
Regards,
Ivan Uvarov


From jic23 at kernel.org  Thu Apr  1 16:05:57 2021
From: jic23 at kernel.org (Jonathan Cameron)
Date: Thu, 1 Apr 2021 16:05:57 +0100
Subject: [PATCH] iio: adc: bcm_iproc_adc: Use %s and __func__
In-Reply-To: <a2ac91a9-54e3-2525-1e7e-00a26d3393e3@gmail.com>
References: <20210401062517.28832-1-dmugil2000@gmail.com>
 <CAHp75VfgL0KW0fetgE3NuBb4itMK1oY+yLmr1xDYkn390hCscg@mail.gmail.com>
 <20210401113015.00006b70@Huawei.com>
 <a2ac91a9-54e3-2525-1e7e-00a26d3393e3@gmail.com>
Message-ID: <20210401160557.533bae90@jic23-huawei>

On Thu, 1 Apr 2021 20:22:47 +0530
Mugilraj D <dmugil2000 at gmail.com> wrote:

> On 01/04/21 4:00 pm, Jonathan Cameron wrote:
> > On Thu, 1 Apr 2021 12:24:50 +0300
> > Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
> >   
> >> On Thu, Apr 1, 2021 at 9:27 AM Mugilraj Dhavachelvan
> >> <dmugil2000 at gmail.com> wrote:  
> >>>
> >>> Change function's name to %s and __func__ to fix checkpatch.pl errors.    
> >>
> >> No, just drop the __func__ completely. First of all, we have a device
> >> name, and uniqueness of the messages in the driver should guarantee
> >> easy findings. Second, specific to _dbg() variants, with enabled
> >> Dynamic Debug it can be chosen at run time!
> >>
> >> I recommend going through all drivers and drop __func__ near to
> >> dev_dbg() and pr_debug().
> >>  
> > 
> > Agreed.  Though beware that some maintainers will count this
> > as noise and get grumpy.
> > 
> > I'm fine with such patches for IIO.  
> 
> Sorry for the noise. I just seen the docs about dynamic debug.
> So, if we use dev_dbg("log_msg") it will print statement like
> filename:lineno [module]func flag log_msg, If I get it correctly.
> And no need of specifying __func__ in dev_dbg() and dp_dbg() right!!
> 
> Jonathan do you have any TODO's?

I tend not to mind cleanup patches (within reason)in IIO so I'm absolutely
fine with a series removing any __func__ items like this.  One patch per
driver preferred because it avoids issues with this interfering with backports
etc. There will end up being about 18 patches from a quick grep.  Perhaps send
a small number first though to avoid having to put in too much effort as
any issues likely to affect the whole set.

Just be careful with other maintainers, they sometimes strike a different
balance for what they consider noise vs useful.  

Jonathan

> 
> > 
> > Jonathan
> >   



From michael.wei.hong.sit at intel.com  Thu Apr  1 16:01:50 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu,  1 Apr 2021 23:01:50 +0800
Subject: [PATCH net-next 0/2] Enable 2.5Gbps speed for stmmac
Message-ID: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>

This patchset enables 2.5Gbps speed mode for stmmac.
Link speed mode is detected and configured at serdes power up sequence.
For 2.5G, we do not use SGMII in-band AN, we check the link speed mode
in the serdes and disable the in-band AN accordingly.

iperf3 and ping for 2.5Gbps and regression test on 10M/100M/1000Mbps
is done to prevent regresson issues.

10Mbps
host at EHL$ ethtool -s enp0s30f4 duplex full speed 10
[  310.132264] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down
[  312.438102] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 10Mbps/Full - flow control off
[  312.447652] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60706 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.26 MBytes  10.6 Mbits/sec    0   29.7 KBytes
[  5]   1.00-2.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   2.00-3.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   3.00-4.00   sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
[  5]   4.00-5.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   5.00-6.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   6.00-7.00   sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
[  5]   7.00-8.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   8.00-9.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   9.00-10.00  sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  11.3 MBytes  9.47 Mbits/sec    0             sender
[  5]   0.00-10.01  sec  11.1 MBytes  9.34 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.557 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.528 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.535 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.525 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.527 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.539 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.588 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.570 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.540 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9194ms
rtt min/avg/max/mdev = 0.525/0.546/0.588/0.019 ms
host at EHL$

100Mbps
host at EHL$ ethtool -s enp0s30f4 duplex full speed 100
[  204.178572] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down
[  207.990094] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 100Mbps/Full - flow control off
[  207.999744] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60702 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.6 MBytes  97.0 Mbits/sec    1    102 KBytes
[  5]   1.00-2.00   sec  10.9 MBytes  91.7 Mbits/sec    0    102 KBytes
[  5]   2.00-3.00   sec  10.8 MBytes  90.5 Mbits/sec    0    102 KBytes
[  5]   3.00-4.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   4.00-5.00   sec  10.8 MBytes  90.6 Mbits/sec    0    102 KBytes
[  5]   5.00-6.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   6.00-7.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   7.00-8.00   sec  10.8 MBytes  90.6 Mbits/sec    0    102 KBytes
[  5]   8.00-9.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   9.00-10.00  sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   110 MBytes  92.3 Mbits/sec    1             sender
[  5]   0.00-10.00  sec   109 MBytes  91.8 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.331 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.322 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.295 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.307 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.294 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.297 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9215ms
rtt min/avg/max/mdev = 0.292/0.306/0.331/0.012 ms

1G speed
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60698 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    533 KBytes
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec    0    591 KBytes
[  5]   2.00-3.00   sec   113 MBytes   945 Mbits/sec    0    621 KBytes
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    621 KBytes
[  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec    0    764 KBytes
[  5]   5.00-6.00   sec   112 MBytes   944 Mbits/sec    0    764 KBytes
[  5]   6.00-7.00   sec   111 MBytes   933 Mbits/sec    0    803 KBytes
[  5]   7.00-8.00   sec   112 MBytes   944 Mbits/sec    0    803 KBytes
[  5]   8.00-9.00   sec   112 MBytes   944 Mbits/sec    0    843 KBytes
[  5]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    843 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.277 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.277 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.286 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.330 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.274 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9196ms
rtt min/avg/max/mdev = 0.272/0.286/0.330/0.017 ms

2.5G speed
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 55160 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   175 MBytes  1.47 Gbits/sec   17    683 KBytes
[  5]   1.00-2.00   sec   202 MBytes  1.70 Gbits/sec    0    707 KBytes
[  5]   2.00-3.00   sec   204 MBytes  1.71 Gbits/sec    0    751 KBytes
[  5]   3.00-4.00   sec   204 MBytes  1.71 Gbits/sec    0    773 KBytes
[  5]   4.00-5.00   sec   202 MBytes  1.70 Gbits/sec    0    773 KBytes
[  5]   5.00-6.00   sec   204 MBytes  1.71 Gbits/sec    0    798 KBytes
[  5]   6.00-7.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   7.00-8.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   8.00-9.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   9.00-10.00  sec   202 MBytes  1.70 Gbits/sec    0    807 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.96 GBytes  1.68 Gbits/sec   17             sender
[  5]   0.00-10.00  sec  1.96 GBytes  1.68 Gbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.671 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.291 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.301 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.328 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.306 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.293 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9251ms
rtt min/avg/max/mdev = 0.291/0.338/0.671/0.111 ms

Voon Weifeng (2):
  net: stmmac: enable 2.5Gbps link speed
  net: pcs: configure xpcs 2.5G speed mode

 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 44 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h | 13 ++++++
 .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 27 +++++++++++-
 drivers/net/pcs/pcs-xpcs.c                    | 29 ++++++++++++
 include/linux/pcs/pcs-xpcs.h                  |  1 +
 include/linux/stmmac.h                        |  2 +
 7 files changed, 114 insertions(+), 3 deletions(-)

-- 
2.17.1



From michael.wei.hong.sit at intel.com  Thu Apr  1 16:01:51 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu,  1 Apr 2021 23:01:51 +0800
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210401150152.22444-2-michael.wei.hong.sit@intel.com>

From: Voon Weifeng <weifeng.voon at intel.com>

Intel mgbe supports 2.5G mode operation when PCS is in 1000BASE-X mode.
The 2.5G mode of operation is functionally same as 1000BASE-X mode,
except that the clock rate is 2.5 times the original rate. In 2.5G mode,
the link will operate as 2500Mbps/250Mbps/25Mbps. Hence, 2.5Gbps
link speed will be mutually exclusive with 1000Mbps/100Mbps/10Mbps.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 44 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h | 13 ++++++
 .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 26 ++++++++++-
 include/linux/stmmac.h                        |  2 +
 5 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 3d9a57043af2..4f70a12b42f9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -102,6 +102,22 @@ static int intel_serdes_powerup(struct net_device *ndev, void *priv_data)
 
 	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
 
+	/* Set the serdes rate and the PCLK rate */
+	data = mdiobus_read(priv->mii, serdes_phy_addr,
+			    SERDES_GCR0);
+
+	data &= ~SERDES_RATE_MASK;
+	data &= ~SERDES_PCLK_MASK;
+
+	if (priv->plat->speed_2500_en)
+		data |= SERDES_RATE_PCIE_GEN2 << SERDES_RATE_PCIE_SHIFT |
+			SERDES_PCLK_37p5MHZ << SERDES_PCLK_SHIFT;
+	else
+		data |= SERDES_RATE_PCIE_GEN1 << SERDES_RATE_PCIE_SHIFT |
+			SERDES_PCLK_70MHZ << SERDES_PCLK_SHIFT;
+
+	mdiobus_write(priv->mii, serdes_phy_addr, SERDES_GCR0, data);
+
 	/* assert clk_req */
 	data = mdiobus_read(priv->mii, serdes_phy_addr, SERDES_GCR0);
 	data |= SERDES_PLL_CLK;
@@ -220,6 +236,28 @@ static void intel_serdes_powerdown(struct net_device *ndev, void *intel_data)
 	}
 }
 
+static bool intel_speed_mode_2500(struct net_device *ndev, void *intel_data)
+{
+	struct intel_priv_data *intel_priv = intel_data;
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int serdes_phy_addr = 0;
+	u32 data = 0;
+
+	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
+
+	/* Determine the link speed mode: 2.5Gbps/1Gbps */
+	data = mdiobus_read(priv->mii, serdes_phy_addr,
+			    SERDES_GCR);
+
+	if (((data & SERDES_LINK_MODE_MASK) >> SERDES_LINK_MODE_SHIFT) ==
+	    SERDES_LINK_MODE_2G5) {
+		dev_info(priv->device, "Link Speed Mode: 2.5Gbps\n");
+		return true;
+	} else {
+		return false;
+	}
+}
+
 /* Program PTP Clock Frequency for different variant of
  * Intel mGBE that has slightly different GPO mapping
  */
@@ -540,7 +578,7 @@ static int ehl_sgmii_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 1;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
-
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 
@@ -593,6 +631,7 @@ static int ehl_pse0_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return ehl_pse0_common_data(pdev, plat);
@@ -631,6 +670,7 @@ static int ehl_pse1_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return ehl_pse1_common_data(pdev, plat);
@@ -655,6 +695,7 @@ static int tgl_sgmii_phy0_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 1;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return tgl_common_data(pdev, plat);
@@ -669,6 +710,7 @@ static int tgl_sgmii_phy1_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 2;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return tgl_common_data(pdev, plat);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index e723096c0b15..021a5c178d97 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -9,6 +9,7 @@
 #define POLL_DELAY_US 8
 
 /* SERDES Register */
+#define SERDES_GCR	0x0	/* Global Conguration */
 #define SERDES_GSR0	0x5	/* Global Status Reg0 */
 #define SERDES_GCR0	0xb	/* Global Configuration Reg0 */
 
@@ -16,8 +17,20 @@
 #define SERDES_PLL_CLK		BIT(0)		/* PLL clk valid signal */
 #define SERDES_RST		BIT(2)		/* Serdes Reset */
 #define SERDES_PWR_ST_MASK	GENMASK(6, 4)	/* Serdes Power state*/
+#define SERDES_RATE_MASK	GENMASK(9, 8)
+#define SERDES_PCLK_MASK	GENMASK(14, 12)	/* PCLK rate to PHY */
+#define SERDES_LINK_MODE_MASK	GENMASK(2, 1)
+#define SERDES_LINK_MODE_SHIFT	1
 #define SERDES_PWR_ST_SHIFT	4
 #define SERDES_PWR_ST_P0	0x0
 #define SERDES_PWR_ST_P3	0x3
+#define SERDES_LINK_MODE_2G5	0x3
+#define SERSED_LINK_MODE_1G	0x2
+#define SERDES_PCLK_37p5MHZ	0x0
+#define SERDES_PCLK_70MHZ	0x1
+#define SERDES_RATE_PCIE_GEN1	0x0
+#define SERDES_RATE_PCIE_GEN2	0x1
+#define SERDES_RATE_PCIE_SHIFT	8
+#define SERDES_PCLK_SHIFT	12
 
 #endif /* __DWMAC_INTEL_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 95864f014ffa..4c3f27a9e8b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -1357,6 +1357,7 @@ int dwmac4_setup(struct stmmac_priv *priv)
 	mac->link.speed10 = GMAC_CONFIG_PS;
 	mac->link.speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
 	mac->link.speed1000 = 0;
+	mac->link.speed2500 = GMAC_CONFIG_FES;
 	mac->link.speed_mask = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
 	mac->mii.addr = GMAC_MDIO_ADDR;
 	mac->mii.data = GMAC_MDIO_DATA;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d34388b1ffcc..e182f9be4247 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -882,6 +882,18 @@ static void stmmac_validate(struct phylink_config *config,
 	phylink_set(mac_supported, Asym_Pause);
 	phylink_set_port_modes(mac_supported);
 
+	/* 2.5G mode only support 2500baseT full duplex only */
+	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
+		phylink_set(mac_supported, 2500baseT_Full);
+		phylink_set(mask, 10baseT_Half);
+		phylink_set(mask, 10baseT_Full);
+		phylink_set(mask, 100baseT_Half);
+		phylink_set(mask, 100baseT_Full);
+		phylink_set(mask, 1000baseT_Half);
+		phylink_set(mask, 1000baseT_Full);
+		phylink_set(mask, 1000baseKX_Full);
+	}
+
 	/* Cut down 1G if asked to */
 	if ((max_speed > 0) && (max_speed < 1000)) {
 		phylink_set(mask, 1000baseT_Full);
@@ -1192,8 +1204,13 @@ static int stmmac_phy_setup(struct stmmac_priv *priv)
 	priv->phylink_config.dev = &priv->dev->dev;
 	priv->phylink_config.type = PHYLINK_NETDEV;
 	priv->phylink_config.pcs_poll = true;
-	priv->phylink_config.ovr_an_inband =
-		priv->plat->mdio_bus_data->xpcs_an_inband;
+	/* For 2.5G, we do not use SGMII in-band AN */
+	if (priv->plat->speed_2500_en) {
+		priv->phylink_config.ovr_an_inband = false;
+	} else {
+		priv->phylink_config.ovr_an_inband =
+			priv->plat->mdio_bus_data->xpcs_an_inband;
+	}
 
 	if (!fwnode)
 		fwnode = dev_fwnode(priv->device);
@@ -5815,6 +5832,11 @@ int stmmac_dvr_probe(struct device *device,
 		}
 	}
 
+	if (priv->plat->speed_mode_2500) {
+		priv->plat->speed_2500_en = priv->plat->speed_mode_2500(ndev,
+									priv->plat->bsp_priv);
+	}
+
 	ret = stmmac_phy_setup(priv);
 	if (ret) {
 		netdev_err(ndev, "failed to setup phy (%d)\n", ret);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..a43ce24d2a42 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -209,6 +209,7 @@ struct plat_stmmacenet_data {
 	void (*fix_mac_speed)(void *priv, unsigned int speed);
 	int (*serdes_powerup)(struct net_device *ndev, void *priv);
 	void (*serdes_powerdown)(struct net_device *ndev, void *priv);
+	bool (*speed_mode_2500)(struct net_device *ndev, void *priv);
 	void (*ptp_clk_freq_config)(void *priv);
 	int (*init)(struct platform_device *pdev, void *priv);
 	void (*exit)(struct platform_device *pdev, void *priv);
@@ -234,6 +235,7 @@ struct plat_stmmacenet_data {
 	int has_xgmac;
 	bool vlan_fail_q_en;
 	u8 vlan_fail_q;
+	bool speed_2500_en;
 	unsigned int eee_usecs_rate;
 	struct pci_dev *pdev;
 	bool has_crossts;
-- 
2.17.1



From michael.wei.hong.sit at intel.com  Thu Apr  1 16:01:52 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu,  1 Apr 2021 23:01:52 +0800
Subject: [PATCH net-next 2/2] net: pcs: configure xpcs 2.5G speed mode
In-Reply-To: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210401150152.22444-3-michael.wei.hong.sit@intel.com>

From: Voon Weifeng <weifeng.voon at intel.com>

Besides setting 2.5G configuration, this patch will also disable
automatic speed mode change. This is due to the 2.5G mode is
using the same functionality as 1G mode except the clock rate is
2.5 times the original rate. Hence, auto-negotiation is disabled
to make sure it will only be in 2.5G mode.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  1 +
 drivers/net/pcs/pcs-xpcs.c                    | 29 +++++++++++++++++++
 include/linux/pcs/pcs-xpcs.h                  |  1 +
 3 files changed, 31 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e182f9be4247..23178651310e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5835,6 +5835,7 @@ int stmmac_dvr_probe(struct device *device,
 	if (priv->plat->speed_mode_2500) {
 		priv->plat->speed_2500_en = priv->plat->speed_mode_2500(ndev,
 									priv->plat->bsp_priv);
+		priv->hw->xpcs_args.speed_2500_en = priv->plat->speed_2500_en;
 	}
 
 	ret = stmmac_phy_setup(priv);
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 944ba105cac1..e7562cfcd7d5 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -60,10 +60,14 @@
 
 /* Clause 37 Defines */
 /* VR MII MMD registers offsets */
+#define DW_VR_MII_MMD_CTRL		0x0000
 #define DW_VR_MII_DIG_CTRL1		0x8000
 #define DW_VR_MII_AN_CTRL		0x8001
 #define DW_VR_MII_AN_INTR_STS		0x8002
 
+/* Enable 2.5G Mode */
+#define DW_VR_MII_DIG_CTRL1_2G5_EN	BIT(2)
+
 /* VR_MII_DIG_CTRL1 */
 #define DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW		BIT(9)
 
@@ -86,6 +90,11 @@
 #define DW_VR_MII_C37_ANSGM_SP_1000		0x2
 #define DW_VR_MII_C37_ANSGM_SP_LNKSTS		BIT(4)
 
+/* SR MII MMD Control defines */
+#define AN_CL37_EN		BIT(12)	/* Enable Clause 37 auto-nego */
+#define SGMII_SPEED_SS13	BIT(13)	/* SGMII speed along with SS6 */
+#define SGMII_SPEED_SS6		BIT(6)	/* SGMII speed along with SS13 */
+
 static const int xpcs_usxgmii_features[] = {
 	ETHTOOL_LINK_MODE_Pause_BIT,
 	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
@@ -141,6 +150,7 @@ static const int xpcs_sgmii_features[] = {
 	ETHTOOL_LINK_MODE_100baseT_Full_BIT,
 	ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
 	ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
 	__ETHTOOL_LINK_MODE_MASK_NBITS,
 };
 
@@ -654,6 +664,25 @@ static int xpcs_config_aneg_c37_sgmii(struct mdio_xpcs_args *xpcs)
 {
 	int ret;
 
+	if (xpcs->speed_2500_en) {
+		ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1);
+		if (ret < 0)
+			return ret;
+		ret |= DW_VR_MII_DIG_CTRL1_2G5_EN;
+		ret &= ~DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
+		ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1, ret);
+		if (ret < 0)
+			return ret;
+
+		ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL);
+		if (ret < 0)
+			return ret;
+		ret &= ~AN_CL37_EN;
+		ret |= SGMII_SPEED_SS6;
+		ret &= ~SGMII_SPEED_SS13;
+		return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL, ret);
+	}
+
 	/* For AN for C37 SGMII mode, the settings are :-
 	 * 1) VR_MII_AN_CTRL Bit(2:1)[PCS_MODE] = 10b (SGMII AN)
 	 * 2) VR_MII_AN_CTRL Bit(3) [TX_CONFIG] = 0b (MAC side SGMII)
diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h
index 2cb5188a7ef1..6b94b2a48e0c 100644
--- a/include/linux/pcs/pcs-xpcs.h
+++ b/include/linux/pcs/pcs-xpcs.h
@@ -19,6 +19,7 @@ struct mdio_xpcs_args {
 	struct mii_bus *bus;
 	int addr;
 	int an_mode;
+	bool speed_2500_en;
 };
 
 struct mdio_xpcs_ops {
-- 
2.17.1



From linux at armlinux.org.uk  Thu Apr  1 16:10:44 2021
From: linux at armlinux.org.uk (Russell King - ARM Linux admin)
Date: Thu, 1 Apr 2021 16:10:44 +0100
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
 <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
Message-ID: <20210401151044.GZ1463@shell.armlinux.org.uk>

On Thu, Apr 01, 2021 at 11:01:51PM +0800, Michael Sit Wei Hong wrote:
> +	/* 2.5G mode only support 2500baseT full duplex only */
> +	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> +		phylink_set(mac_supported, 2500baseT_Full);
> +		phylink_set(mask, 10baseT_Half);
> +		phylink_set(mask, 10baseT_Full);
> +		phylink_set(mask, 100baseT_Half);
> +		phylink_set(mask, 100baseT_Full);
> +		phylink_set(mask, 1000baseT_Half);
> +		phylink_set(mask, 1000baseT_Full);
> +		phylink_set(mask, 1000baseKX_Full);

Why? This seems at odds to the comment above?

What about 2500baseX_Full ?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


From maz at kernel.org  Thu Apr  1 16:14:35 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 16:14:35 +0100
Subject: [PATCH] arm64: Disable fine grained traps on boot
In-Reply-To: <20210401124936.56877-1-broonie@kernel.org>
References: <20210401124936.56877-1-broonie@kernel.org>
Message-ID: <87sg4aox44.wl-maz@kernel.org>

Thanks Will for the bounce.

On Thu, 01 Apr 2021 13:49:36 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
> to small sets of registers and instructions from EL1 and EL0.  Currently
> Linux makes no use of this feature, ensure that it is not active at boot by
> disabling the traps during EL2 setup.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/asm/el2_setup.h | 21 +++++++++++++++++++++
>  arch/arm64/include/asm/sysreg.h    |  6 ++++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
> index d77d358f9395..f94ef3a76877 100644
> --- a/arch/arm64/include/asm/el2_setup.h
> +++ b/arch/arm64/include/asm/el2_setup.h
> @@ -131,6 +131,26 @@
>  .Lskip_sve_\@:
>  .endm
>  
> +/* Disable any fine grained traps */
> +.macro __init_el2_fgt
> +	mrs	x1, id_aa64mmfr0_el1
> +	ubfx	x1, x1, #ID_AA64MMFR0_FGT_SHIFT, #4
> +	cbz	x1, .Lskip_fgt_\@
> +
> +	msr_s	SYS_HDFGRTR_EL2, xzr
> +	msr_s	SYS_HDFGWTR_EL2, xzr
> +	msr_s	SYS_HFGRTR_EL2, xzr
> +	msr_s	SYS_HFGITR_EL2, xzr
> +	msr_s	SYS_HFGWTR_EL2, xzr

nit: consider grouping SYS_HFGWTR_EL2 and SYS_HFGRTR_EL2 together,
since they affect the same registers.

> +
> +	mrs	x1, id_aa64pfr0_el1		// AMU traps UNDEF without AMU
> +	ubfx	x1, x1, #ID_AA64PFR0_AMU_SHIFT, #4
> +	cbz	x1, .Lskip_fgt_\@
> +
> +	msr_s	SYS_HAFGRTR_EL2, xzr

Do we need to document the need for SCR_EL3.FGTEn to be set so that
these register accesses don't trap? That'd be consistent with what we
do for other features (PtrAuth, AMU...).

> +.Lskip_fgt_\@:
> +.endm
> +
>  .macro __init_el2_nvhe_prepare_eret
>  	mov	x0, #INIT_PSTATE_EL1
>  	msr	spsr_el2, x0
> @@ -155,6 +175,7 @@
>  	__init_el2_nvhe_idregs
>  	__init_el2_nvhe_cptr
>  	__init_el2_nvhe_sve
> +	__init_el2_fgt
>  	__init_el2_nvhe_prepare_eret
>  .endm
>  
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index d4a5fca984c3..b35468927363 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -475,9 +475,15 @@
>  #define SYS_PMCCFILTR_EL0		sys_reg(3, 3, 14, 15, 7)
>  
>  #define SYS_SCTLR_EL2			sys_reg(3, 4, 1, 0, 0)
> +#define SYS_HFGRTR_EL2			sys_reg(3, 4, 1, 1, 4)
> +#define SYS_HFGWTR_EL2			sys_reg(3, 4, 1, 1, 5)
> +#define SYS_HFGITR_EL2			sys_reg(3, 4, 1, 1, 6)
>  #define SYS_ZCR_EL2			sys_reg(3, 4, 1, 2, 0)
>  #define SYS_TRFCR_EL2			sys_reg(3, 4, 1, 2, 1)
>  #define SYS_DACR32_EL2			sys_reg(3, 4, 3, 0, 0)
> +#define SYS_HDFGRTR_EL2			sys_reg(3, 4, 3, 1, 4)
> +#define SYS_HDFGWTR_EL2			sys_reg(3, 4, 3, 1, 5)
> +#define SYS_HAFGRTR_EL2			sys_reg(3, 4, 3, 1, 6)
>  #define SYS_SPSR_EL2			sys_reg(3, 4, 4, 0, 0)
>  #define SYS_ELR_EL2			sys_reg(3, 4, 4, 0, 1)
>  #define SYS_IFSR32_EL2			sys_reg(3, 4, 5, 0, 1)

Thanks,

	M.

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


From colin.king at canonical.com  Thu Apr  1 16:18:27 2021
From: colin.king at canonical.com (Colin King)
Date: Thu,  1 Apr 2021 16:18:27 +0100
Subject: [PATCH][next] crypto: sun8i-ss: Fix memory leak of pad
Message-ID: <20210401151827.2015960-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

It appears there are several failure return paths that don't seem
to be free'ing pad. Fix these.

Addresses-Coverity: ("Resource leak")
Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
index 7d1fc9aba665..3c073eb3db03 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
@@ -348,8 +348,10 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq)
 	bf = (__le32 *)pad;
 
 	result = kzalloc(digestsize, GFP_KERNEL | GFP_DMA);
-	if (!result)
+	if (!result) {
+		kfree(pad);
 		return -ENOMEM;
+	}
 
 	for (i = 0; i < MAX_SG; i++) {
 		rctx->t_dst[i].addr = 0;
@@ -436,10 +438,9 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq)
 		     DMA_TO_DEVICE);
 	dma_unmap_single(ss->dev, addr_res, digestsize, DMA_FROM_DEVICE);
 
-	kfree(pad);
-
 	memcpy(areq->result, result, algt->alg.hash.halg.digestsize);
 theend:
+	kfree(pad);
 	kfree(result);
 	crypto_finalize_hash_request(engine, breq, err);
 	return 0;
-- 
2.30.2



From maz at kernel.org  Thu Apr  1 16:22:40 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 16:22:40 +0100
Subject: [PATCH v2] KVM: arm64: Initialize VCPU mdcr_el2 before loading it
In-Reply-To: <d3f6cd69-42c8-0199-c7cd-56e1789ac141@arm.com>
References: <20210323180057.263356-1-alexandru.elisei@arm.com>
 <87sg4dq83r.wl-maz@kernel.org>
 <5cfd4870-db31-cd7d-699f-bd70a1ab90fe@arm.com>
 <5c90a3b2-c9a8-640b-fb6a-7a09d397ba7f@arm.com>
 <87lfa4fm8u.wl-maz@kernel.org>
 <d3f6cd69-42c8-0199-c7cd-56e1789ac141@arm.com>
Message-ID: <87r1juowqn.wl-maz@kernel.org>

On Thu, 01 Apr 2021 14:55:54 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:

[...]

> Had another go at this, and as I was looking at the code, I realized that
> conceptually, trapping debug registers access (MDCR_EL2.TDA) is tied to:
> 
> - KVM_ARM64_DEBUG_DIRTY *not* being set (guest is debugging itself and KVM will
> world-switch the debug registers).
> 
> - KVM_GUESTDBG_USE_HW being set, which also *sets* KVM_ARM64_DEBUG_DIRTY (host is
> debugging the guest using hardware breakpoints).
> 
> So I cannot set the MDCR_EL2.TDA bit based on KVM_ARM64_DEBUG_DIRTY,
> because I would lose one of the two cases. It looks to me that
> keeping kvm_arm_setup_mdcr_el2() unchanged and calling it at the
> start of kvm_arm_setup_debug() is the way to go here.

Just post the revised patch, and we'll take it from there.

Thanks,

	M.

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


From alcooperx at gmail.com  Thu Apr  1 16:23:20 2021
From: alcooperx at gmail.com (Alan Cooper)
Date: Thu, 1 Apr 2021 11:23:20 -0400
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
Message-ID: <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>

Nicolas,

Sorry, I just noticed this thread.
This is a known bug in some newer Arasan cores.
The problem happens when the difference between the core clock and the
bus clock is too great.
Limiting the clock to 200KHz minimum should be a good fix.
In my experience, it's only eMMC that needs the clock to be retried
below 400KHz and not SD or SDIO. That's because the CMD signal for
eMMC starts out as open-drain during identification and the size of
the pull-up on the CMD signal can require the <400KHz clock. Once eMMC
is out of identification mode the CMD signal is switched to push-pull
and can run at much higher clock rates.
I don't think that SD and SDIO have any open-drain signals, so they
shouldn't need to retry at slower clock speeds.
I'm trying to get more detail on the bug, like the exact ratio of core
clock to bus clock that causes the problem. When I first found this
bug I was told that the failure would not happen at 200KHz, but we
were using a 405MHz core clock.

One other question. Why are you using polling for the SD card, this
newer controller supports the interrupt driven "Card Inserted" signal
and avoids wasting time polling?

Al


On Fri, Mar 26, 2021 at 12:17 PM Nicolas Saenz Julienne
<nsaenzjulienne at suse.de> wrote:
>
> On Thu, 2021-03-25 at 20:11 +0100, Stefan Wahren wrote:
> > Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
> > > Hi Stefan,
> > >
> > > On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
> > > > Hi Nicolas,
> > > >
> > > > Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
> > > > > From: Nicolas Saenz Julienne <nsaenzjulienne at suse.de>
> > > > >
> > > > > Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
> > > > > seems to interfere with the VPU clock when setup at frequencies bigger
> > > > > than 500MHz (a pretty common case). This ends up causing unwarranted
> > > > > SDHCI CMD hangs  when no SD card is present.
> > > > >
> > > > > Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> > > > > ---
> > > > >  arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++++++
> > > > >  1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> > > > > index 3b4ab947492a..9aa8408d9960 100644
> > > > > --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> > > > > +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> > > > > @@ -257,6 +257,12 @@ &emmc2 {
> > > > >         vqmmc-supply = <&sd_io_1v8_reg>;
> > > > >         vmmc-supply = <&sd_vcc_reg>;
> > > > >         broken-cd;
> > > > > +       /*
> > > > > +        * Force the frequency to 150MHz as the default 100MHz seems to
> > > > > +        * interfere with the VPU clock when setup at frequencies bigger than
> > > > > +        * 500MHz, causing unwarranted CMD hangs.
> > > > > +        */
> > > > > +       clock-frequency = <150000000>;
> > > > i don't want to bike-shed here, but is there any chance to solve this in
> > > > clk-bcm2835 in a less hacky way?
> > > What do you have in mind?
> > Sorry, nothing specific.
> > >
> > > All I can think of is adding some kind of heuristic to the clock's prepare()
> > > callback. That said, I don't feel it would be a better solution than this.
> >
> > Based on my limited knowledge and an old SD card specification, all
> > possibly connected devices could have different frequencies. So my
> > concern here is, that in case we limit the frequency to a specific value
> > we could break things just to suppress a warning.
>
> SDHCI should be able to handle up to 233MHz IIRC, and there are divisors
> available, it depends on the implementation but the worst kind provide /2^n.
> Not perfect, but good enough for things to work.
>
> Now, I've been having a deeper look into how clocks are handled, and found two
> new clues:
>
>  - First of all RPi4's sdhci-iproc needs SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
>    that is, the controller isn't properly identifying the clock frequency fed
>    into it, and defaults to saying it's configured at 100MHz. I'm not an SDHCI
>    expert, so it's possible changing frequencies also needs a special operation
>    to recalculate this variable. But this was making all internal calculations
>    wrong when paired with this series.
>
>  - With this flag set SDHCI's core now properly calculates divisor values based
>    on whatever clock frequency I set in DT. And guess what, the issue reappears
>    even when running on 150MHz. It turns out, as I had some debugging enabled,
>    the issue only happens when the controller is configured at 100KHz (that
>    only happens while running the card detect thread).
>
> So, I can now do this (note that for card detection try to communicate with the
> card starting at 400KHz down to 100KHz in 100KHz steps):
>
> ----->8-----
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 536c382e2486..e5a5de63f347 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -173,6 +173,11 @@ static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host)
>                 return pltfm_host->clock;
>  }
>
> +static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host *host)
> +{
> +       return 200000;
> +}
> +
>  static const struct sdhci_ops sdhci_iproc_ops = {
>         .set_clock = sdhci_set_clock,
>         .get_max_clock = sdhci_iproc_get_max_clock,
> @@ -271,13 +276,15 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
>         .set_clock = sdhci_set_clock,
>         .set_power = sdhci_set_power_and_bus_voltage,
>         .get_max_clock = sdhci_iproc_get_max_clock,
> +       .get_min_clock = sdhci_iproc_bcm2711_get_min_clock,
>         .set_bus_width = sdhci_set_bus_width,
>         .reset = sdhci_reset,
>         .set_uhs_signaling = sdhci_set_uhs_signaling,
>  };
>
> ----->8-----
>
>  Which is rather nicer than what this series introduces. But I can't still
>  explain why configuring the controller at 100KHz is causing the hangs (while
>  having the core clock setup at 500MHz), and I'm not sure if excluding 100KHz
>  from the polling frequency list is going to break support for older SD cards.
>
>  Regards,
>  Nicolas
>
>


From broonie at kernel.org  Thu Apr  1 16:27:41 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 16:27:41 +0100
Subject: [RFC PATCH v1 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <20210330190955.13707-2-madvenka@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-2-madvenka@linux.microsoft.com>
Message-ID: <20210401152741.GK4758@sirena.org.uk>

On Tue, Mar 30, 2021 at 02:09:52PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> Implement a check_reliability() function that will contain checks for the
> presence of various features and conditions that can render the stack trace
> unreliable.

This looks good to me with one minor stylistic thing:

> +/*
> + * Special functions where the stack trace is unreliable.
> + */
> +static struct function_range	special_functions[] = {
> +	{ 0, 0 }
> +};

Might be good to put a comment here saying that this is terminating the
list rather than detecting a NULL function pointer:

	{ /* sentinel */ }

is a common idiom for that.

Given that it's a fixed array we could also...

> +	for (func = special_functions; func->start; func++) {
> +		if (pc >= func->start && pc < func->end)

...do these as

	for (i = 0; i < ARRAY_SIZE(special_functions); i++) 

so you don't need something like that, though that gets awkward when you
have to write out special_functions[i].field a lot.

So many different potential colours for the bikeshed!
-------------- 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/20210401/13066291/attachment.sig>

From alex.kogan at oracle.com  Thu Apr  1 16:31:51 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:51 -0400
Subject: [PATCH v14 1/6] locking/qspinlock: Rename mcs lock/unlock macros and
 make them more generic
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-2-alex.kogan@oracle.com>

The mcs unlock macro (arch_mcs_lock_handoff) should accept the value to be
stored into the lock argument as another argument. This allows using the
same macro in cases where the value to be stored when passing the lock is
different from 1.

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 arch/arm/include/asm/mcs_spinlock.h |  6 +++---
 include/asm-generic/mcs_spinlock.h  |  4 ++--
 kernel/locking/mcs_spinlock.h       | 18 +++++++++---------
 kernel/locking/qspinlock.c          |  4 ++--
 kernel/locking/qspinlock_paravirt.h |  2 +-
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/include/asm/mcs_spinlock.h b/arch/arm/include/asm/mcs_spinlock.h
index 529d2cf4d06f..1eb4d733459c 100644
--- a/arch/arm/include/asm/mcs_spinlock.h
+++ b/arch/arm/include/asm/mcs_spinlock.h
@@ -6,7 +6,7 @@
 #include <asm/spinlock.h>
 
 /* MCS spin-locking. */
-#define arch_mcs_spin_lock_contended(lock)				\
+#define arch_mcs_spin_wait(lock)					\
 do {									\
 	/* Ensure prior stores are observed before we enter wfe. */	\
 	smp_mb();							\
@@ -14,9 +14,9 @@ do {									\
 		wfe();							\
 } while (0)								\
 
-#define arch_mcs_spin_unlock_contended(lock)				\
+#define arch_mcs_lock_handoff(lock, val)				\
 do {									\
-	smp_store_release(lock, 1);					\
+	smp_store_release((lock), (val));				\
 	dsb_sev();							\
 } while (0)
 
diff --git a/include/asm-generic/mcs_spinlock.h b/include/asm-generic/mcs_spinlock.h
index 10cd4ffc6ba2..f933d99c63e0 100644
--- a/include/asm-generic/mcs_spinlock.h
+++ b/include/asm-generic/mcs_spinlock.h
@@ -4,8 +4,8 @@
 /*
  * Architectures can define their own:
  *
- *   arch_mcs_spin_lock_contended(l)
- *   arch_mcs_spin_unlock_contended(l)
+ *   arch_mcs_spin_wait(l)
+ *   arch_mcs_lock_handoff(l, val)
  *
  * See kernel/locking/mcs_spinlock.c.
  */
diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h
index 5e10153b4d3c..904ba5d0f3f4 100644
--- a/kernel/locking/mcs_spinlock.h
+++ b/kernel/locking/mcs_spinlock.h
@@ -21,7 +21,7 @@ struct mcs_spinlock {
 	int count;  /* nesting count, see qspinlock.c */
 };
 
-#ifndef arch_mcs_spin_lock_contended
+#ifndef arch_mcs_spin_wait
 /*
  * Using smp_cond_load_acquire() provides the acquire semantics
  * required so that subsequent operations happen after the
@@ -29,20 +29,20 @@ struct mcs_spinlock {
  * ARM64 would like to do spin-waiting instead of purely
  * spinning, and smp_cond_load_acquire() provides that behavior.
  */
-#define arch_mcs_spin_lock_contended(l)					\
-do {									\
-	smp_cond_load_acquire(l, VAL);					\
+#define arch_mcs_spin_wait(l)					\
+do {								\
+	smp_cond_load_acquire(l, VAL);				\
 } while (0)
 #endif
 
-#ifndef arch_mcs_spin_unlock_contended
+#ifndef arch_mcs_lock_handoff
 /*
  * smp_store_release() provides a memory barrier to ensure all
  * operations in the critical section has been completed before
  * unlocking.
  */
-#define arch_mcs_spin_unlock_contended(l)				\
-	smp_store_release((l), 1)
+#define arch_mcs_lock_handoff(l, val)				\
+	smp_store_release((l), (val))
 #endif
 
 /*
@@ -91,7 +91,7 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
 	WRITE_ONCE(prev->next, node);
 
 	/* Wait until the lock holder passes the lock down. */
-	arch_mcs_spin_lock_contended(&node->locked);
+	arch_mcs_spin_wait(&node->locked);
 }
 
 /*
@@ -115,7 +115,7 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
 	}
 
 	/* Pass lock to next waiter. */
-	arch_mcs_spin_unlock_contended(&next->locked);
+	arch_mcs_lock_handoff(&next->locked, 1);
 }
 
 #endif /* __LINUX_MCS_SPINLOCK_H */
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index cbff6ba53d56..435d696f9250 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -471,7 +471,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 		WRITE_ONCE(prev->next, node);
 
 		pv_wait_node(node, prev);
-		arch_mcs_spin_lock_contended(&node->locked);
+		arch_mcs_spin_wait(&node->locked);
 
 		/*
 		 * While waiting for the MCS lock, the next pointer may have
@@ -550,7 +550,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 	if (!next)
 		next = smp_cond_load_relaxed(&node->next, (VAL));
 
-	arch_mcs_spin_unlock_contended(&next->locked);
+	arch_mcs_lock_handoff(&next->locked, 1);
 	pv_kick_node(lock, next);
 
 release:
diff --git a/kernel/locking/qspinlock_paravirt.h b/kernel/locking/qspinlock_paravirt.h
index e84d21aa0722..619d80fd5ea8 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -368,7 +368,7 @@ static void pv_kick_node(struct qspinlock *lock, struct mcs_spinlock *node)
 	 *
 	 * Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
 	 *
-	 * The write to next->locked in arch_mcs_spin_unlock_contended()
+	 * The write to next->locked in arch_mcs_lock_handoff()
 	 * must be ordered before the read of pn->state in the cmpxchg()
 	 * below for the code to work correctly. To guarantee full ordering
 	 * irrespective of the success or failure of the cmpxchg(),
-- 
2.24.3 (Apple Git-128)



From alex.kogan at oracle.com  Thu Apr  1 16:31:56 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:56 -0400
Subject: [PATCH v14 6/6] locking/qspinlock: Introduce the shuffle reduction
 optimization into CNA
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-7-alex.kogan@oracle.com>

This performance optimization chooses probabilistically to avoid moving
threads from the main queue into the secondary one when the secondary queue
is empty.

It is helpful when the lock is only lightly contended. In particular, it
makes CNA less eager to create a secondary queue, but does not introduce
any extra delays for threads waiting in that queue once it is created.

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 kernel/locking/qspinlock_cna.h | 39 ++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
index 29c3abbd3d94..983c6a47a221 100644
--- a/kernel/locking/qspinlock_cna.h
+++ b/kernel/locking/qspinlock_cna.h
@@ -5,6 +5,7 @@
 
 #include <linux/topology.h>
 #include <linux/sched/rt.h>
+#include <linux/random.h>
 
 /*
  * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
@@ -86,6 +87,34 @@ static inline bool intra_node_threshold_reached(struct cna_node *cn)
 	return current_time - threshold > 0;
 }
 
+/*
+ * Controls the probability for enabling the ordering of the main queue
+ * when the secondary queue is empty. The chosen value reduces the amount
+ * of unnecessary shuffling of threads between the two waiting queues
+ * when the contention is low, while responding fast enough and enabling
+ * the shuffling when the contention is high.
+ */
+#define SHUFFLE_REDUCTION_PROB_ARG  (7)
+
+/* Per-CPU pseudo-random number seed */
+static DEFINE_PER_CPU(u32, seed);
+
+/*
+ * Return false with probability 1 / 2^@num_bits.
+ * Intuitively, the larger @num_bits the less likely false is to be returned.
+ * @num_bits must be a number between 0 and 31.
+ */
+static bool probably(unsigned int num_bits)
+{
+	u32 s;
+
+	s = this_cpu_read(seed);
+	s = next_pseudo_random32(s);
+	this_cpu_write(seed, s);
+
+	return s & ((1 << num_bits) - 1);
+}
+
 static void __init cna_init_nodes_per_cpu(unsigned int cpu)
 {
 	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);
@@ -293,6 +322,16 @@ static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
 {
 	struct cna_node *cn = (struct cna_node *)node;
 
+	if (node->locked <= 1 && probably(SHUFFLE_REDUCTION_PROB_ARG)) {
+		/*
+		 * When the secondary queue is empty, skip the call to
+		 * cna_order_queue() below with high probability. This optimization
+		 * reduces the overhead of unnecessary shuffling of threads
+		 * between waiting queues when the lock is only lightly contended.
+		 */
+		return 0;
+	}
+
 	if (!cn->start_time || !intra_node_threshold_reached(cn)) {
 		/*
 		 * We are at the head of the wait queue, no need to use
-- 
2.24.3 (Apple Git-128)



From alex.kogan at oracle.com  Thu Apr  1 16:31:54 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:54 -0400
Subject: [PATCH v14 4/6] locking/qspinlock: Introduce starvation avoidance
 into CNA
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-5-alex.kogan@oracle.com>

Keep track of the time the thread at the head of the secondary queue
has been waiting, and force inter-node handoff once this time passes
a preset threshold. The default value for the threshold (10ms) can be
overridden with the new kernel boot command-line option
"numa_spinlock_threshold". The ms value is translated internally to the
nearest rounded-up jiffies.

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 .../admin-guide/kernel-parameters.txt         |  9 ++
 kernel/locking/qspinlock_cna.h                | 96 ++++++++++++++++---
 2 files changed, 93 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index ace55afd4441..5c959631a8c8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3485,6 +3485,15 @@
 			Not specifying this option is equivalent to
 			numa_spinlock=auto.
 
+	numa_spinlock_threshold=	[NUMA, PV_OPS]
+			Set the time threshold in milliseconds for the
+			number of intra-node lock hand-offs before the
+			NUMA-aware spinlock is forced to be passed to
+			a thread on another NUMA node.	Valid values
+			are in the [1..100] range. Smaller values result
+			in a more fair, but less performant spinlock,
+			and vice versa. The default value is 10.
+
 	numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
 			'node', 'default' can be specified
 			This can be set from sysctl after boot.
diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
index d689861a7b3d..0513360c11fe 100644
--- a/kernel/locking/qspinlock_cna.h
+++ b/kernel/locking/qspinlock_cna.h
@@ -37,6 +37,12 @@
  * gradually filter the primary queue, leaving only waiters running on the same
  * preferred NUMA node.
  *
+ * We change the NUMA node preference after a waiter at the head of the
+ * secondary queue spins for a certain amount of time (10ms, by default).
+ * We do that by flushing the secondary queue into the head of the primary queue,
+ * effectively changing the preference to the NUMA node of the waiter at the head
+ * of the secondary queue at the time of the flush.
+ *
  * For more details, see https://arxiv.org/abs/1810.05600.
  *
  * Authors: Alex Kogan <alex.kogan at oracle.com>
@@ -49,13 +55,33 @@ struct cna_node {
 	u16			real_numa_node;
 	u32			encoded_tail;	/* self */
 	u32			partial_order;	/* enum val */
+	s32			start_time;
 };
 
 enum {
 	LOCAL_WAITER_FOUND,
 	LOCAL_WAITER_NOT_FOUND,
+	FLUSH_SECONDARY_QUEUE
 };
 
+/*
+ * Controls the threshold time in ms (default = 10) for intra-node lock
+ * hand-offs before the NUMA-aware variant of spinlock is forced to be
+ * passed to a thread on another NUMA node. The default setting can be
+ * changed with the "numa_spinlock_threshold" boot option.
+ */
+#define MSECS_TO_JIFFIES(m)	\
+	(((m) + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ))
+static int intra_node_handoff_threshold __ro_after_init = MSECS_TO_JIFFIES(10);
+
+static inline bool intra_node_threshold_reached(struct cna_node *cn)
+{
+	s32 current_time = (s32)jiffies;
+	s32 threshold = cn->start_time + intra_node_handoff_threshold;
+
+	return current_time - threshold > 0;
+}
+
 static void __init cna_init_nodes_per_cpu(unsigned int cpu)
 {
 	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);
@@ -99,6 +125,7 @@ static __always_inline void cna_init_node(struct mcs_spinlock *node)
 
 	cn->numa_node = cn->real_numa_node;
 	cn->partial_order = LOCAL_WAITER_FOUND;
+	cn->start_time = 0;
 }
 
 /*
@@ -198,8 +225,15 @@ static void cna_splice_next(struct mcs_spinlock *node,
 
 	/* stick `next` on the secondary queue tail */
 	if (node->locked <= 1) { /* if secondary queue is empty */
+		struct cna_node *cn = (struct cna_node *)node;
+
 		/* create secondary queue */
 		next->next = next;
+
+		cn->start_time = (s32)jiffies;
+		/* make sure start_time != 0 iff secondary queue is not empty */
+		if (!cn->start_time)
+			cn->start_time = 1;
 	} else {
 		/* add to the tail of the secondary queue */
 		struct mcs_spinlock *tail_2nd = decode_tail(node->locked);
@@ -250,11 +284,17 @@ static void cna_order_queue(struct mcs_spinlock *node)
 static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
 						 struct mcs_spinlock *node)
 {
-	/*
-	 * Try and put the time otherwise spent spin waiting on
-	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
-	 */
-	cna_order_queue(node);
+	struct cna_node *cn = (struct cna_node *)node;
+
+	if (!cn->start_time || !intra_node_threshold_reached(cn)) {
+		/*
+		 * Try and put the time otherwise spent spin waiting on
+		 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
+		 */
+		cna_order_queue(node);
+	} else {
+		cn->partial_order = FLUSH_SECONDARY_QUEUE;
+	}
 
 	return 0; /* we lied; we didn't wait, go do so now */
 }
@@ -270,13 +310,28 @@ static inline void cna_lock_handoff(struct mcs_spinlock *node,
 	if (partial_order == LOCAL_WAITER_NOT_FOUND)
 		cna_order_queue(node);
 
-	/*
-	 * We have a local waiter, either real or fake one;
-	 * reload @next in case it was changed by cna_order_queue().
-	 */
-	next = node->next;
-	if (node->locked > 1)
-		val = node->locked;	/* preseve secondary queue */
+	if (partial_order != FLUSH_SECONDARY_QUEUE) {
+		/*
+		 * We have a local waiter, either real or fake one;
+		 * reload @next in case it was changed by cna_order_queue().
+		 */
+		next = node->next;
+		if (node->locked > 1) {
+			val = node->locked;     /* preseve secondary queue */
+			((struct cna_node *)next)->start_time = cn->start_time;
+		}
+	} else {
+		/*
+		 * We decided to flush the secondary queue;
+		 * this can only happen if that queue is not empty.
+		 */
+		WARN_ON(node->locked <= 1);
+		/*
+		 * Splice the secondary queue onto the primary queue and pass the lock
+		 * to the longest waiting remote waiter.
+		 */
+		next = cna_splice_head(NULL, 0, node, next);
+	}
 
 	arch_mcs_lock_handoff(&next->locked, val);
 }
@@ -328,3 +383,20 @@ void __init cna_configure_spin_lock_slowpath(void)
 
 	pr_info("Enabling CNA spinlock\n");
 }
+
+static int __init numa_spinlock_threshold_setup(char *str)
+{
+	int param;
+
+	if (get_option(&str, &param)) {
+		/* valid value is between 1 and 100 */
+		if (param <= 0 || param > 100)
+			return 0;
+
+		intra_node_handoff_threshold = msecs_to_jiffies(param);
+		return 1;
+	}
+
+	return 0;
+}
+__setup("numa_spinlock_threshold=", numa_spinlock_threshold_setup);
-- 
2.24.3 (Apple Git-128)



From alex.kogan at oracle.com  Thu Apr  1 16:31:52 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:52 -0400
Subject: [PATCH v14 2/6] locking/qspinlock: Refactor the qspinlock slow path
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-3-alex.kogan@oracle.com>

Move some of the code manipulating the spin lock into separate functions.
This would allow easier integration of alternative ways to manipulate
that lock.

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 kernel/locking/qspinlock.c | 38 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 435d696f9250..e3518709ffdc 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -289,6 +289,34 @@ static __always_inline u32  __pv_wait_head_or_lock(struct qspinlock *lock,
 #define queued_spin_lock_slowpath	native_queued_spin_lock_slowpath
 #endif
 
+/*
+ * __try_clear_tail - try to clear tail by setting the lock value to
+ * _Q_LOCKED_VAL.
+ * @lock: Pointer to the queued spinlock structure
+ * @val: Current value of the lock
+ * @node: Pointer to the MCS node of the lock holder
+ */
+static __always_inline bool __try_clear_tail(struct qspinlock *lock,
+					     u32 val,
+					     struct mcs_spinlock *node)
+{
+	return atomic_try_cmpxchg_relaxed(&lock->val, &val, _Q_LOCKED_VAL);
+}
+
+/*
+ * __mcs_lock_handoff - pass the MCS lock to the next waiter
+ * @node: Pointer to the MCS node of the lock holder
+ * @next: Pointer to the MCS node of the first waiter in the MCS queue
+ */
+static __always_inline void __mcs_lock_handoff(struct mcs_spinlock *node,
+					       struct mcs_spinlock *next)
+{
+	arch_mcs_lock_handoff(&next->locked, 1);
+}
+
+#define try_clear_tail		__try_clear_tail
+#define mcs_lock_handoff	__mcs_lock_handoff
+
 #endif /* _GEN_PV_LOCK_SLOWPATH */
 
 /**
@@ -533,7 +561,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 	 *       PENDING will make the uncontended transition fail.
 	 */
 	if ((val & _Q_TAIL_MASK) == tail) {
-		if (atomic_try_cmpxchg_relaxed(&lock->val, &val, _Q_LOCKED_VAL))
+		if (try_clear_tail(lock, val, node))
 			goto release; /* No contention */
 	}
 
@@ -550,7 +578,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 	if (!next)
 		next = smp_cond_load_relaxed(&node->next, (VAL));
 
-	arch_mcs_lock_handoff(&next->locked, 1);
+	mcs_lock_handoff(node, next);
 	pv_kick_node(lock, next);
 
 release:
@@ -575,6 +603,12 @@ EXPORT_SYMBOL(queued_spin_lock_slowpath);
 #undef pv_kick_node
 #undef pv_wait_head_or_lock
 
+#undef try_clear_tail
+#define try_clear_tail		__try_clear_tail
+
+#undef mcs_lock_handoff
+#define mcs_lock_handoff			__mcs_lock_handoff
+
 #undef  queued_spin_lock_slowpath
 #define queued_spin_lock_slowpath	__pv_queued_spin_lock_slowpath
 
-- 
2.24.3 (Apple Git-128)



From alex.kogan at oracle.com  Thu Apr  1 16:31:50 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:50 -0400
Subject: [PATCH v14 0/6] Add NUMA-awareness to qspinlock
Message-ID: <20210401153156.1165900-1-alex.kogan@oracle.com>

Change from v13:
----------------

Fix regression in stress-ng.
Reported-by: kernel test robot <oliver.sang at intel.com>

The fix is to move common-case stores into the 'partial_order' field
of the queue node from cna_wait_head_or_lock() (where those stores
can cause a cache miss during lock handover) to cna_init_node().

Summary
-------

Lock throughput can be increased by handing a lock to a waiter on the
same NUMA node as the lock holder, provided care is taken to avoid
starvation of waiters on other NUMA nodes. This patch introduces CNA
(compact NUMA-aware lock) as the slow path for qspinlock. It is
enabled through a configuration option (NUMA_AWARE_SPINLOCKS).

CNA is a NUMA-aware version of the MCS lock. Spinning threads are
organized in two queues, a primary queue for threads running on the same
node as the current lock holder, and a secondary queue for threads
running on other nodes. Threads store the ID of the node on which
they are running in their queue nodes. After acquiring the MCS lock and
before acquiring the spinlock, the MCS lock holder checks whether the next
waiter in the primary queue (if exists) is running on the same NUMA node.
If it is not, that waiter is detached from the main queue and moved into
the tail of the secondary queue. This way, we gradually filter the primary
queue, leaving only waiters running on the same preferred NUMA node. Note
that certain priortized waiters (e.g., in irq and nmi contexts) are
excluded from being moved to the secondary queue. We change the NUMA node
preference after a waiter at the head of the secondary queue spins for a
certain amount of time. We do that by flushing the secondary queue into
the head of the primary queue, effectively changing the preference to the
NUMA node of the waiter at the head of the secondary queue at the time of
the flush.

More details are available at https://arxiv.org/abs/1810.05600.

We have done some performance evaluation with the locktorture module
as well as with several benchmarks from the will-it-scale repo.
The following locktorture results are from an Oracle X5-4 server
(four Intel Xeon E7-8895 v3 @ 2.60GHz sockets with 18 hyperthreaded
cores each). Each number represents an average (over 25 runs) of the
total number of ops (x10^7) reported at the end of each run. The 
standard deviation is also reported in (), and in general is about 3%
from the average. The 'stock' kernel is v5.12.0-rc5,
commit 99d4e8b4e609b, compiled in the default configuration. 
'CNA' is the modified kernel with NUMA_AWARE_SPINLOCKS set;
The speedup is calculated by dividing the result of 'CNA' by the result
 achieved with 'stock'.

#thr  	 stock     CNA / speedup     
  1  2.675 (0.088) 2.707 (0.100) / 1.012
  2  2.781 (0.172) 2.790 (0.148) / 1.003
  4  4.314 (0.115) 4.403 (0.205) / 1.021
  8  5.085 (0.140) 7.292 (0.210) / 1.434
 16  5.846 (0.114) 9.340 (0.186) / 1.598
 32  6.282 (0.127) 10.074 (0.197) / 1.603
 36  6.382 (0.144) 10.243 (0.198) / 1.605
 72  6.175 (0.086) 10.482 (0.179) / 1.698
108  6.037 (0.073) 10.354 (0.164) / 1.715
142  5.796 (0.072) 10.275 (0.193) / 1.773

The following tables contain throughput results (ops/us) from the same
setup for will-it-scale/open1_threads: 

#thr  	 stock     CNA / speedup
  1  0.515 (0.002) 0.514 (0.001) / 0.999
  2  0.774 (0.018) 0.780 (0.019) / 1.009
  4  1.408 (0.030) 1.421 (0.034) / 1.009
  8  1.785 (0.082) 1.724 (0.115) / 0.965
 16  1.878 (0.118) 1.775 (0.114) / 0.945
 32  0.914 (0.072) 1.755 (0.105) / 1.920
 36  0.877 (0.064) 1.738 (0.100) / 1.981
 72  0.810 (0.047) 1.658 (0.086) / 2.047
108  0.835 (0.036) 1.756 (0.091) / 2.103
142  0.809 (0.038) 1.766 (0.069) / 2.184

and will-it-scale/lock2_threads:

#thr  	 stock     CNA / speedup
  1  1.605 (0.003) 1.606 (0.005) / 1.000
  2  2.814 (0.077) 2.793 (0.068) / 0.992
  4  5.318 (0.352) 5.463 (0.357) / 1.027
  8  4.241 (0.265) 4.025 (0.366) / 0.949
 16  4.125 (0.124) 3.914 (0.159) / 0.949
 32  2.458 (0.113) 3.950 (0.131) / 1.607
 36  2.457 (0.075) 3.924 (0.080) / 1.597
 72  1.836 (0.102) 3.909 (0.104) / 2.129
108  1.868 (0.098) 3.871 (0.106) / 2.072
142  1.780 (0.124) 3.894 (0.089) / 2.188

Our evaluation shows that CNA also improves performance of user 
applications that have hot pthread mutexes. Those mutexes are 
blocking, and waiting threads park and unpark via the futex 
mechanism in the kernel. Given that kernel futex chains, which
are hashed by the mutex address, are each protected by a 
chain-specific spin lock, the contention on a user-mode mutex 
translates into contention on a kernel level spinlock. 

Here are the throughput results (ops/us) for the leveldb ?readrandom?
benchmark:

#thr  	 stock         CNA / speedup
  1  0.493 (0.034) 0.520 (0.026) / 1.053
  2  0.796 (0.046) 0.838 (0.033) / 1.053
  4  1.172 (0.076) 1.211 (0.043) / 1.033
  8  1.215 (0.096) 1.207 (0.116) / 0.993
 16  0.986 (0.136) 1.070 (0.129) / 1.085
 32  0.756 (0.036) 1.148 (0.021) / 1.519
 36  0.701 (0.032) 1.147 (0.017) / 1.636
 72  0.625 (0.016) 1.149 (0.024) / 1.839
108  0.612 (0.015) 1.146 (0.014) / 1.872
142  0.606 (0.013) 1.131 (0.025) / 1.867

Further comments are welcome and appreciated.

Alex Kogan (6):
  locking/qspinlock: Rename mcs lock/unlock macros and make them more
    generic
  locking/qspinlock: Refactor the qspinlock slow path
  locking/qspinlock: Introduce CNA into the slow path of qspinlock
  locking/qspinlock: Introduce starvation avoidance into CNA
  locking/qspinlock: Avoid moving certain threads between waiting queues
    in CNA
  locking/qspinlock: Introduce the shuffle reduction optimization into
    CNA

 .../admin-guide/kernel-parameters.txt         |  19 +
 arch/arm/include/asm/mcs_spinlock.h           |   6 +-
 arch/x86/Kconfig                              |  20 +
 arch/x86/include/asm/qspinlock.h              |   4 +
 arch/x86/kernel/alternative.c                 |   4 +
 include/asm-generic/mcs_spinlock.h            |   4 +-
 kernel/locking/mcs_spinlock.h                 |  20 +-
 kernel/locking/qspinlock.c                    |  82 +++-
 kernel/locking/qspinlock_cna.h                | 455 ++++++++++++++++++
 kernel/locking/qspinlock_paravirt.h           |   2 +-
 10 files changed, 593 insertions(+), 23 deletions(-)
 create mode 100644 kernel/locking/qspinlock_cna.h

-- 
2.24.3 (Apple Git-128)



From alex.kogan at oracle.com  Thu Apr  1 16:31:55 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:55 -0400
Subject: [PATCH v14 5/6] locking/qspinlock: Avoid moving certain threads
 between waiting queues in CNA
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-6-alex.kogan@oracle.com>

Prohibit moving certain threads (e.g., in irq and nmi contexts)
to the secondary queue. Those prioritized threads will always stay
in the primary queue, and so will have a shorter wait time for the lock.

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 kernel/locking/qspinlock_cna.h | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
index 0513360c11fe..29c3abbd3d94 100644
--- a/kernel/locking/qspinlock_cna.h
+++ b/kernel/locking/qspinlock_cna.h
@@ -4,6 +4,7 @@
 #endif
 
 #include <linux/topology.h>
+#include <linux/sched/rt.h>
 
 /*
  * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
@@ -35,7 +36,8 @@
  * running on the same NUMA node. If it is not, that waiter is detached from the
  * main queue and moved into the tail of the secondary queue. This way, we
  * gradually filter the primary queue, leaving only waiters running on the same
- * preferred NUMA node.
+ * preferred NUMA node. Note that certain priortized waiters (e.g., in
+ * irq and nmi contexts) are excluded from being moved to the secondary queue.
  *
  * We change the NUMA node preference after a waiter at the head of the
  * secondary queue spins for a certain amount of time (10ms, by default).
@@ -49,6 +51,8 @@
  *          Dave Dice <dave.dice at oracle.com>
  */
 
+#define CNA_PRIORITY_NODE      0xffff
+
 struct cna_node {
 	struct mcs_spinlock	mcs;
 	u16			numa_node;
@@ -121,9 +125,10 @@ static int __init cna_init_nodes(void)
 
 static __always_inline void cna_init_node(struct mcs_spinlock *node)
 {
+	bool priority = !in_task() || irqs_disabled() || rt_task(current);
 	struct cna_node *cn = (struct cna_node *)node;
 
-	cn->numa_node = cn->real_numa_node;
+	cn->numa_node = priority ? CNA_PRIORITY_NODE : cn->real_numa_node;
 	cn->partial_order = LOCAL_WAITER_FOUND;
 	cn->start_time = 0;
 }
@@ -266,11 +271,13 @@ static void cna_order_queue(struct mcs_spinlock *node)
 	next_numa_node = ((struct cna_node *)next)->numa_node;
 
 	if (next_numa_node != numa_node) {
-		struct mcs_spinlock *nnext = READ_ONCE(next->next);
+		if (next_numa_node != CNA_PRIORITY_NODE) {
+			struct mcs_spinlock *nnext = READ_ONCE(next->next);
 
-		if (nnext) {
-			cna_splice_next(node, next, nnext);
-			next = nnext;
+			if (nnext) {
+				cna_splice_next(node, next, nnext);
+				next = nnext;
+			}
 		}
 		/*
 		 * Inherit NUMA node id of primary queue, to maintain the
@@ -287,6 +294,13 @@ static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
 	struct cna_node *cn = (struct cna_node *)node;
 
 	if (!cn->start_time || !intra_node_threshold_reached(cn)) {
+		/*
+		 * We are at the head of the wait queue, no need to use
+		 * the fake NUMA node ID.
+		 */
+		if (cn->numa_node == CNA_PRIORITY_NODE)
+			cn->numa_node = cn->real_numa_node;
+
 		/*
 		 * Try and put the time otherwise spent spin waiting on
 		 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
-- 
2.24.3 (Apple Git-128)



From robin.murphy at arm.com  Thu Apr  1 16:33:53 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 1 Apr 2021 16:33:53 +0100
Subject: [RFC PATCH 0/5] Optimization for unmapping iommu mapped buffers
In-Reply-To: <20210331030042.13348-1-isaacm@codeaurora.org>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
Message-ID: <f4931afb-7530-ff96-44e0-25e3e86de336@arm.com>

On 2021-03-31 04:00, Isaac J. Manjarres wrote:
> When unmapping a buffer from an IOMMU domain, the IOMMU framework unmaps
> the buffer at a granule of the largest page size that is supported by
> the IOMMU hardware and fits within the buffer. For every block that
> is unmapped, the IOMMU framework will call into the IOMMU driver, and
> then the io-pgtable framework to walk the page tables to find the entry
> that corresponds to the IOVA, and then unmaps the entry.
> 
> This can be suboptimal in scenarios where a buffer or a piece of a
> buffer can be split into several contiguous page blocks of the same size.
> For example, consider an IOMMU that supports 4 KB page blocks, 2 MB page
> blocks, and 1 GB page blocks, and a buffer that is 4 MB in size is being
> unmapped at IOVA 0. The current call-flow will result in 4 indirect calls,
> and 2 page table walks, to unmap 2 entries that are next to each other in
> the page-tables, when both entries could have been unmapped in one shot
> by clearing both page table entries in the same call.

s/unmap/map/ and s/clear/set/ and those two paragraphs are still just as 
valid. I'd say If it's worth doing anything at all then it's worth doing 
more than just half the job ;)

> These patches implement a callback called unmap_pages to the io-pgtable
> code and IOMMU drivers which unmaps an IOVA range that consists of a
> number of pages of the same page size that is supported by the IOMMU
> hardware, and allows for clearing multiple entries in the same set of
> indirect calls. The reason for introducing unmap_pages is to give
> other IOMMU drivers/io-pgtable formats time to change to using the new
> unmap_pages callback, so that the transition to using this approach can be
> done piecemeal.
> 
> The same optimization is applicable for mapping buffers, however, the
> error handling in the io-pgtable layer couldn't be handled cleanly, as we
> would need to invoke iommu_unmap to unmap the parts of the buffer that
> were mapped, and then do any TLB maintenance. However, that seemed like a
> layering violation.

Why couldn't it just return the partial mapping and let the caller roll 
it back?

Note that having a weird asymmetric interface was how things started out 
way back when - see bd13969b9524 ("iommu: Split iommu_unmaps") for context.

> Any feedback is very much appreciated.

Do you have any real-world performance figures? I proposed this as an 
approach because it was clear it could give *some* benefit for 
relatively low impact, but I'm curious to find out exactly how much, and 
in particular whether it appears to leave anything on the table vs. 
punting the entire operation down into the drivers.

Robin.

> Thanks,
> Isaac
> 
> Isaac J. Manjarres (5):
>    iommu/io-pgtable: Introduce unmap_pages() as a page table op
>    iommu: Add an unmap_pages() op for IOMMU drivers
>    iommu: Add support for the unmap_pages IOMMU callback
>    iommu/io-pgtable-arm: Implement arm_lpae_unmap_pages()
>    iommu/arm-smmu: Implement the unmap_pages IOMMU driver callback
> 
>   drivers/iommu/arm/arm-smmu/arm-smmu.c |  19 +++++
>   drivers/iommu/io-pgtable-arm.c        | 114 +++++++++++++++++++++-----
>   drivers/iommu/iommu.c                 |  44 ++++++++--
>   include/linux/io-pgtable.h            |   4 +
>   include/linux/iommu.h                 |   4 +
>   5 files changed, 159 insertions(+), 26 deletions(-)
> 


From alex.kogan at oracle.com  Thu Apr  1 16:31:53 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu,  1 Apr 2021 11:31:53 -0400
Subject: [PATCH v14 3/6] locking/qspinlock: Introduce CNA into the slow path
 of qspinlock
In-Reply-To: <20210401153156.1165900-1-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
Message-ID: <20210401153156.1165900-4-alex.kogan@oracle.com>

In CNA, spinning threads are organized in two queues, a primary queue for
threads running on the same node as the current lock holder, and a
secondary queue for threads running on other nodes. After acquiring the
MCS lock and before acquiring the spinlock, the MCS lock
holder checks whether the next waiter in the primary queue (if exists) is
running on the same NUMA node. If it is not, that waiter is detached from
the main queue and moved into the tail of the secondary queue. This way,
we gradually filter the primary queue, leaving only waiters running on
the same preferred NUMA node. For more details, see
https://arxiv.org/abs/1810.05600.

Note that this variant of CNA may introduce starvation by continuously
passing the lock between waiters in the main queue. This issue will be
addressed later in the series.

Enabling CNA is controlled via a new configuration option
(NUMA_AWARE_SPINLOCKS). By default, the CNA variant is patched in at the
boot time only if we run on a multi-node machine in native environment and
the new config is enabled. (For the time being, the patching requires
CONFIG_PARAVIRT_SPINLOCKS to be enabled as well. However, this should be
resolved once static_call() is available.) This default behavior can be
overridden with the new kernel boot command-line option
"numa_spinlock=on/off" (default is "auto").

Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
Reviewed-by: Waiman Long <longman at redhat.com>
---
 .../admin-guide/kernel-parameters.txt         |  10 +
 arch/x86/Kconfig                              |  20 ++
 arch/x86/include/asm/qspinlock.h              |   4 +
 arch/x86/kernel/alternative.c                 |   4 +
 kernel/locking/mcs_spinlock.h                 |   2 +-
 kernel/locking/qspinlock.c                    |  42 ++-
 kernel/locking/qspinlock_cna.h                | 330 ++++++++++++++++++
 7 files changed, 407 insertions(+), 5 deletions(-)
 create mode 100644 kernel/locking/qspinlock_cna.h

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..ace55afd4441 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3475,6 +3475,16 @@
 	numa_balancing=	[KNL,X86] Enable or disable automatic NUMA balancing.
 			Allowed values are enable and disable
 
+	numa_spinlock=	[NUMA, PV_OPS] Select the NUMA-aware variant
+			of spinlock. The options are:
+			auto - Enable this variant if running on a multi-node
+			machine in native environment.
+			on  - Unconditionally enable this variant.
+			off - Unconditionally disable this variant.
+
+			Not specifying this option is equivalent to
+			numa_spinlock=auto.
+
 	numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
 			'node', 'default' can be specified
 			This can be set from sysctl after boot.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..c3b47077d7e4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1558,6 +1558,26 @@ config NUMA
 
 	  Otherwise, you should say N.
 
+config NUMA_AWARE_SPINLOCKS
+	bool "Numa-aware spinlocks"
+	depends on NUMA
+	depends on QUEUED_SPINLOCKS
+	depends on 64BIT
+	# For now, we depend on PARAVIRT_SPINLOCKS to make the patching work.
+	# This is awkward, but hopefully would be resolved once static_call()
+	# is available.
+	depends on PARAVIRT_SPINLOCKS
+	default y
+	help
+	  Introduce NUMA (Non Uniform Memory Access) awareness into
+	  the slow path of spinlocks.
+
+	  In this variant of qspinlock, the kernel will try to keep the lock
+	  on the same node, thus reducing the number of remote cache misses,
+	  while trading some of the short term fairness for better performance.
+
+	  Say N if you want absolute first come first serve fairness.
+
 config AMD_NUMA
 	def_bool y
 	prompt "Old style AMD Opteron NUMA detection"
diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index d86ab942219c..21d09e8db979 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -27,6 +27,10 @@ static __always_inline u32 queued_fetch_set_pending_acquire(struct qspinlock *lo
 	return val;
 }
 
+#ifdef CONFIG_NUMA_AWARE_SPINLOCKS
+extern void cna_configure_spin_lock_slowpath(void);
+#endif
+
 #ifdef CONFIG_PARAVIRT_SPINLOCKS
 extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
 extern void __pv_init_lock_hash(void);
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 8d778e46725d..0178ff898d8a 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -741,6 +741,10 @@ void __init alternative_instructions(void)
 	}
 #endif
 
+#if defined(CONFIG_NUMA_AWARE_SPINLOCKS)
+	cna_configure_spin_lock_slowpath();
+#endif
+
 	apply_paravirt(__parainstructions, __parainstructions_end);
 
 	restart_nmi();
diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h
index 904ba5d0f3f4..5e47ffb3f08b 100644
--- a/kernel/locking/mcs_spinlock.h
+++ b/kernel/locking/mcs_spinlock.h
@@ -17,7 +17,7 @@
 
 struct mcs_spinlock {
 	struct mcs_spinlock *next;
-	int locked; /* 1 if lock acquired */
+	unsigned int locked; /* 1 if lock acquired */
 	int count;  /* nesting count, see qspinlock.c */
 };
 
diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index e3518709ffdc..8c1a21b53913 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -11,7 +11,7 @@
  *          Peter Zijlstra <peterz at infradead.org>
  */
 
-#ifndef _GEN_PV_LOCK_SLOWPATH
+#if !defined(_GEN_PV_LOCK_SLOWPATH) && !defined(_GEN_CNA_LOCK_SLOWPATH)
 
 #include <linux/smp.h>
 #include <linux/bug.h>
@@ -71,7 +71,8 @@
 /*
  * On 64-bit architectures, the mcs_spinlock structure will be 16 bytes in
  * size and four of them will fit nicely in one 64-byte cacheline. For
- * pvqspinlock, however, we need more space for extra data. To accommodate
+ * pvqspinlock, however, we need more space for extra data. The same also
+ * applies for the NUMA-aware variant of spinlocks (CNA). To accommodate
  * that, we insert two more long words to pad it up to 32 bytes. IOW, only
  * two of them can fit in a cacheline in this case. That is OK as it is rare
  * to have more than 2 levels of slowpath nesting in actual use. We don't
@@ -80,7 +81,7 @@
  */
 struct qnode {
 	struct mcs_spinlock mcs;
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#if defined(CONFIG_PARAVIRT_SPINLOCKS) || defined(CONFIG_NUMA_AWARE_SPINLOCKS)
 	long reserved[2];
 #endif
 };
@@ -104,6 +105,8 @@ struct qnode {
  * Exactly fits one 64-byte cacheline on a 64-bit architecture.
  *
  * PV doubles the storage and uses the second cacheline for PV state.
+ * CNA also doubles the storage and uses the second cacheline for
+ * CNA-specific state.
  */
 static DEFINE_PER_CPU_ALIGNED(struct qnode, qnodes[MAX_NODES]);
 
@@ -317,7 +320,7 @@ static __always_inline void __mcs_lock_handoff(struct mcs_spinlock *node,
 #define try_clear_tail		__try_clear_tail
 #define mcs_lock_handoff	__mcs_lock_handoff
 
-#endif /* _GEN_PV_LOCK_SLOWPATH */
+#endif /* _GEN_PV_LOCK_SLOWPATH && _GEN_CNA_LOCK_SLOWPATH */
 
 /**
  * queued_spin_lock_slowpath - acquire the queued spinlock
@@ -589,6 +592,37 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 }
 EXPORT_SYMBOL(queued_spin_lock_slowpath);
 
+/*
+ * Generate the code for NUMA-aware spinlocks
+ */
+#if !defined(_GEN_CNA_LOCK_SLOWPATH) && defined(CONFIG_NUMA_AWARE_SPINLOCKS)
+#define _GEN_CNA_LOCK_SLOWPATH
+
+#undef pv_init_node
+#define pv_init_node			cna_init_node
+
+#undef pv_wait_head_or_lock
+#define pv_wait_head_or_lock		cna_wait_head_or_lock
+
+#undef try_clear_tail
+#define try_clear_tail			cna_try_clear_tail
+
+#undef mcs_lock_handoff
+#define mcs_lock_handoff			cna_lock_handoff
+
+#undef  queued_spin_lock_slowpath
+/*
+ * defer defining queued_spin_lock_slowpath until after the include to
+ * avoid a name clash with the identically named field in pv_ops.lock
+ * (see cna_configure_spin_lock_slowpath())
+ */
+#include "qspinlock_cna.h"
+#define queued_spin_lock_slowpath	__cna_queued_spin_lock_slowpath
+
+#include "qspinlock.c"
+
+#endif
+
 /*
  * Generate the paravirt code for queued_spin_unlock_slowpath().
  */
diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
new file mode 100644
index 000000000000..d689861a7b3d
--- /dev/null
+++ b/kernel/locking/qspinlock_cna.h
@@ -0,0 +1,330 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _GEN_CNA_LOCK_SLOWPATH
+#error "do not include this file"
+#endif
+
+#include <linux/topology.h>
+
+/*
+ * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
+ *
+ * In CNA, spinning threads are organized in two queues, a primary queue for
+ * threads running on the same NUMA node as the current lock holder, and a
+ * secondary queue for threads running on other nodes. Schematically, it
+ * looks like this:
+ *
+ *    cna_node
+ *   +----------+     +--------+         +--------+
+ *   |mcs:next  | --> |mcs:next| --> ... |mcs:next| --> NULL  [Primary queue]
+ *   |mcs:locked| -.  +--------+         +--------+
+ *   +----------+  |
+ *                 `----------------------.
+ *                                        v
+ *                 +--------+         +--------+
+ *                 |mcs:next| --> ... |mcs:next|            [Secondary queue]
+ *                 +--------+         +--------+
+ *                     ^                    |
+ *                     `--------------------'
+ *
+ * N.B. locked := 1 if secondary queue is absent. Otherwise, it contains the
+ * encoded pointer to the tail of the secondary queue, which is organized as a
+ * circular list.
+ *
+ * After acquiring the MCS lock and before acquiring the spinlock, the MCS lock
+ * holder checks whether the next waiter in the primary queue (if exists) is
+ * running on the same NUMA node. If it is not, that waiter is detached from the
+ * main queue and moved into the tail of the secondary queue. This way, we
+ * gradually filter the primary queue, leaving only waiters running on the same
+ * preferred NUMA node.
+ *
+ * For more details, see https://arxiv.org/abs/1810.05600.
+ *
+ * Authors: Alex Kogan <alex.kogan at oracle.com>
+ *          Dave Dice <dave.dice at oracle.com>
+ */
+
+struct cna_node {
+	struct mcs_spinlock	mcs;
+	u16			numa_node;
+	u16			real_numa_node;
+	u32			encoded_tail;	/* self */
+	u32			partial_order;	/* enum val */
+};
+
+enum {
+	LOCAL_WAITER_FOUND,
+	LOCAL_WAITER_NOT_FOUND,
+};
+
+static void __init cna_init_nodes_per_cpu(unsigned int cpu)
+{
+	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);
+	int numa_node = cpu_to_node(cpu);
+	int i;
+
+	for (i = 0; i < MAX_NODES; i++) {
+		struct cna_node *cn = (struct cna_node *)grab_mcs_node(base, i);
+
+		cn->real_numa_node = numa_node;
+		cn->encoded_tail = encode_tail(cpu, i);
+		/*
+		 * make sure @encoded_tail is not confused with other valid
+		 * values for @locked (0 or 1)
+		 */
+		WARN_ON(cn->encoded_tail <= 1);
+	}
+}
+
+static int __init cna_init_nodes(void)
+{
+	unsigned int cpu;
+
+	/*
+	 * this will break on 32bit architectures, so we restrict
+	 * the use of CNA to 64bit only (see arch/x86/Kconfig)
+	 */
+	BUILD_BUG_ON(sizeof(struct cna_node) > sizeof(struct qnode));
+	/* we store an ecoded tail word in the node's @locked field */
+	BUILD_BUG_ON(sizeof(u32) > sizeof(unsigned int));
+
+	for_each_possible_cpu(cpu)
+		cna_init_nodes_per_cpu(cpu);
+
+	return 0;
+}
+
+static __always_inline void cna_init_node(struct mcs_spinlock *node)
+{
+	struct cna_node *cn = (struct cna_node *)node;
+
+	cn->numa_node = cn->real_numa_node;
+	cn->partial_order = LOCAL_WAITER_FOUND;
+}
+
+/*
+ * cna_splice_head -- splice the entire secondary queue onto the head of the
+ * primary queue.
+ *
+ * Returns the new primary head node or NULL on failure.
+ */
+static struct mcs_spinlock *
+cna_splice_head(struct qspinlock *lock, u32 val,
+		struct mcs_spinlock *node, struct mcs_spinlock *next)
+{
+	struct mcs_spinlock *head_2nd, *tail_2nd;
+	u32 new;
+
+	tail_2nd = decode_tail(node->locked);
+	head_2nd = tail_2nd->next;
+
+	if (next) {
+		/*
+		 * If the primary queue is not empty, the primary tail doesn't
+		 * need to change and we can simply link the secondary tail to
+		 * the old primary head.
+		 */
+		tail_2nd->next = next;
+	} else {
+		/*
+		 * When the primary queue is empty, the secondary tail becomes
+		 * the primary tail.
+		 */
+
+		/*
+		 * Speculatively break the secondary queue's circular link such
+		 * that when the secondary tail becomes the primary tail it all
+		 * works out.
+		 */
+		tail_2nd->next = NULL;
+
+		/*
+		 * tail_2nd->next = NULL;	old = xchg_tail(lock, tail);
+		 *				prev = decode_tail(old);
+		 * try_cmpxchg_release(...);	WRITE_ONCE(prev->next, node);
+		 *
+		 * If the following cmpxchg() succeeds, our stores will not
+		 * collide.
+		 */
+		new = ((struct cna_node *)tail_2nd)->encoded_tail |
+			_Q_LOCKED_VAL;
+		if (!atomic_try_cmpxchg_release(&lock->val, &val, new)) {
+			/* Restore the secondary queue's circular link. */
+			tail_2nd->next = head_2nd;
+			return NULL;
+		}
+	}
+
+	/* The primary queue head now is what was the secondary queue head. */
+	return head_2nd;
+}
+
+static inline bool cna_try_clear_tail(struct qspinlock *lock, u32 val,
+				      struct mcs_spinlock *node)
+{
+	/*
+	 * We're here because the primary queue is empty; check the secondary
+	 * queue for remote waiters.
+	 */
+	if (node->locked > 1) {
+		struct mcs_spinlock *next;
+
+		/*
+		 * When there are waiters on the secondary queue, try to move
+		 * them back onto the primary queue and let them rip.
+		 */
+		next = cna_splice_head(lock, val, node, NULL);
+		if (next) {
+			arch_mcs_lock_handoff(&next->locked, 1);
+			return true;
+		}
+
+		return false;
+	}
+
+	/* Both queues are empty. Do what MCS does. */
+	return __try_clear_tail(lock, val, node);
+}
+
+/*
+ * cna_splice_tail -- splice the next node from the primary queue onto
+ * the secondary queue.
+ */
+static void cna_splice_next(struct mcs_spinlock *node,
+			    struct mcs_spinlock *next,
+			    struct mcs_spinlock *nnext)
+{
+	/* remove 'next' from the main queue */
+	node->next = nnext;
+
+	/* stick `next` on the secondary queue tail */
+	if (node->locked <= 1) { /* if secondary queue is empty */
+		/* create secondary queue */
+		next->next = next;
+	} else {
+		/* add to the tail of the secondary queue */
+		struct mcs_spinlock *tail_2nd = decode_tail(node->locked);
+		struct mcs_spinlock *head_2nd = tail_2nd->next;
+
+		tail_2nd->next = next;
+		next->next = head_2nd;
+	}
+
+	node->locked = ((struct cna_node *)next)->encoded_tail;
+}
+
+/*
+ * cna_order_queue - check whether the next waiter in the main queue is on
+ * the same NUMA node as the lock holder; if not, and it has a waiter behind
+ * it in the main queue, move the former onto the secondary queue.
+ */
+static void cna_order_queue(struct mcs_spinlock *node)
+{
+	struct mcs_spinlock *next = READ_ONCE(node->next);
+	struct cna_node *cn = (struct cna_node *)node;
+	int numa_node, next_numa_node;
+
+	if (!next) {
+		cn->partial_order = LOCAL_WAITER_NOT_FOUND;
+		return;
+	}
+
+	numa_node = cn->numa_node;
+	next_numa_node = ((struct cna_node *)next)->numa_node;
+
+	if (next_numa_node != numa_node) {
+		struct mcs_spinlock *nnext = READ_ONCE(next->next);
+
+		if (nnext) {
+			cna_splice_next(node, next, nnext);
+			next = nnext;
+		}
+		/*
+		 * Inherit NUMA node id of primary queue, to maintain the
+		 * preference even if the next waiter is on a different node.
+		 */
+		((struct cna_node *)next)->numa_node = numa_node;
+	}
+}
+
+/* Abuse the pv_wait_head_or_lock() hook to get some work done */
+static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
+						 struct mcs_spinlock *node)
+{
+	/*
+	 * Try and put the time otherwise spent spin waiting on
+	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
+	 */
+	cna_order_queue(node);
+
+	return 0; /* we lied; we didn't wait, go do so now */
+}
+
+static inline void cna_lock_handoff(struct mcs_spinlock *node,
+				 struct mcs_spinlock *next)
+{
+	struct cna_node *cn = (struct cna_node *)node;
+	u32 val = 1;
+
+	u32 partial_order = cn->partial_order;
+
+	if (partial_order == LOCAL_WAITER_NOT_FOUND)
+		cna_order_queue(node);
+
+	/*
+	 * We have a local waiter, either real or fake one;
+	 * reload @next in case it was changed by cna_order_queue().
+	 */
+	next = node->next;
+	if (node->locked > 1)
+		val = node->locked;	/* preseve secondary queue */
+
+	arch_mcs_lock_handoff(&next->locked, val);
+}
+
+/*
+ * Constant (boot-param configurable) flag selecting the NUMA-aware variant
+ * of spinlock.  Possible values: -1 (off) / 0 (auto, default) / 1 (on).
+ */
+static int numa_spinlock_flag;
+
+static int __init numa_spinlock_setup(char *str)
+{
+	if (!strcmp(str, "auto")) {
+		numa_spinlock_flag = 0;
+		return 1;
+	} else if (!strcmp(str, "on")) {
+		numa_spinlock_flag = 1;
+		return 1;
+	} else if (!strcmp(str, "off")) {
+		numa_spinlock_flag = -1;
+		return 1;
+	}
+
+	return 0;
+}
+__setup("numa_spinlock=", numa_spinlock_setup);
+
+void __cna_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+
+/*
+ * Switch to the NUMA-friendly slow path for spinlocks when we have
+ * multiple NUMA nodes in native environment, unless the user has
+ * overridden this default behavior by setting the numa_spinlock flag.
+ */
+void __init cna_configure_spin_lock_slowpath(void)
+{
+
+	if (numa_spinlock_flag < 0)
+		return;
+
+	if (numa_spinlock_flag == 0 && (nr_node_ids < 2 ||
+		    pv_ops.lock.queued_spin_lock_slowpath !=
+			native_queued_spin_lock_slowpath))
+		return;
+
+	cna_init_nodes();
+
+	pv_ops.lock.queued_spin_lock_slowpath = __cna_queued_spin_lock_slowpath;
+
+	pr_info("Enabling CNA spinlock\n");
+}
-- 
2.24.3 (Apple Git-128)



From robin.murphy at arm.com  Thu Apr  1 16:34:37 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 1 Apr 2021 16:34:37 +0100
Subject: [RFC PATCH 3/5] iommu: Add support for the unmap_pages IOMMU
 callback
In-Reply-To: <20210331030042.13348-4-isaacm@codeaurora.org>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
 <20210331030042.13348-4-isaacm@codeaurora.org>
Message-ID: <f57e2151-1199-46f0-21ed-e401be358857@arm.com>

On 2021-03-31 04:00, Isaac J. Manjarres wrote:
> The IOMMU framework currently unmaps memory one page block at a time,
> per the page block sizes that are supported by the IOMMU hardware.
> Now that IOMMU drivers can supply a callback for unmapping multiple
> in one call, add support in the IOMMU framework to calculate how many
> page mappings of the same size can be unmapped in one shot, and invoke the
> IOMMU driver's unmap_pages callback if it has one. Otherwise, the
> existing behavior will be used.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>   drivers/iommu/iommu.c | 44 +++++++++++++++++++++++++++++++++++++------
>   1 file changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d0b0a15dba84..dc4295f6bc7f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2356,8 +2356,8 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
>   }
>   EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
>   
> -static size_t iommu_pgsize(struct iommu_domain *domain,
> -			   unsigned long addr_merge, size_t size)
> +static size_t __iommu_pgsize(struct iommu_domain *domain,
> +			     unsigned long addr_merge, size_t size)
>   {
>   	unsigned int pgsize_idx;
>   	size_t pgsize;
> @@ -2388,6 +2388,24 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
>   	return pgsize;
>   }
>   
> +static size_t iommu_pgsize(struct iommu_domain *domain,
> +			   unsigned long addr_merge, size_t size,
> +			   size_t *pgcount)
> +{
> +	size_t pgsize = __iommu_pgsize(domain, addr_merge, size);
> +	size_t pgs = 0;
> +
> +	do {
> +		pgs++;
> +		size -= pgsize;
> +		addr_merge += pgsize;
> +	} while (size && __iommu_pgsize(domain, addr_merge, size) == pgsize);

This looks horrifically inefficient. As part of calculating the best 
current page size it should then be pretty trivial to calculate "(size & 
next_pgsize_up - 1) >> pgsize_idx" for the number of current-size pages 
up to the next-better-size boundary (with next_pgsize_up being 0 if 
pgsize is already the largest possible for the relative alignment of 
physical and virtual address). A loop is just... yuck :(

> +
> +	*pgcount = pgs;
> +
> +	return pgsize;
> +}
> +
>   static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
>   		       phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
>   {
> @@ -2422,7 +2440,7 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
>   	pr_debug("map: iova 0x%lx pa %pa size 0x%zx\n", iova, &paddr, size);
>   
>   	while (size) {
> -		size_t pgsize = iommu_pgsize(domain, iova | paddr, size);
> +		size_t pgsize = __iommu_pgsize(domain, iova | paddr, size);
>   
>   		pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx\n",
>   			 iova, &paddr, pgsize);
> @@ -2473,6 +2491,21 @@ int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
>   }
>   EXPORT_SYMBOL_GPL(iommu_map_atomic);
>   
> +static size_t __iommu_unmap_pages(struct iommu_domain *domain, unsigned long iova,
> +				  size_t size, struct iommu_iotlb_gather *iotlb_gather)
> +{
> +	const struct iommu_ops *ops = domain->ops;
> +	size_t pgsize, pgcount;
> +
> +	if (ops->unmap_pages) {
> +		pgsize = iommu_pgsize(domain, iova, size, &pgcount);
> +		return ops->unmap_pages(domain, iova, pgsize, pgcount, iotlb_gather);
> +	}
> +
> +	pgsize = __iommu_pgsize(domain, iova, size);
> +	return ops->unmap(domain, iova, pgsize, iotlb_gather);
> +}
> +
>   static size_t __iommu_unmap(struct iommu_domain *domain,
>   			    unsigned long iova, size_t size,
>   			    struct iommu_iotlb_gather *iotlb_gather)
> @@ -2510,9 +2543,8 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
>   	 * or we hit an area that isn't mapped.
>   	 */
>   	while (unmapped < size) {
> -		size_t pgsize = iommu_pgsize(domain, iova, size - unmapped);
> -
> -		unmapped_page = ops->unmap(domain, iova, pgsize, iotlb_gather);
> +		unmapped_page = __iommu_unmap_pages(domain, iova, size - unmapped,
> +						    iotlb_gather);

I think it would make more sense to restructure the basic function 
around handling a page range, then just have a little inner loop to 
iterate over the individual pages if the driver doesn't provide the new 
callback.

Robin.

>   		if (!unmapped_page)
>   			break;
>   
> 


From maz at kernel.org  Thu Apr  1 16:37:06 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 16:37:06 +0100
Subject: [PATCH 2/2] dt-bindings: arm: cpus: Add edac-enabled property
In-Reply-To: <20210401110615.15326-3-s.hauer@pengutronix.de>
References: <20210401110615.15326-1-s.hauer@pengutronix.de>
 <20210401110615.15326-3-s.hauer@pengutronix.de>
Message-ID: <87pmzeow2l.wl-maz@kernel.org>

On Thu, 01 Apr 2021 12:06:15 +0100,
Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> Some CPUs like the Cortex-A53 and Cortex-A57 have Error Detection And
> Correction (EDAC) support on their L1 and L2 caches. This is implemented
> in implementation defined registers, so usage of this functionality is
> not safe in virtualized environments or when EL3 already uses these
> registers.
> This patch adds a edac-enabled flag which can be explicitly set when
> EDAC can be used.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> ---
>  Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++++++
>  drivers/edac/cortex_arm64_l1_l2.c               | 7 +++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 26b886b20b27..74be19c0544a 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -270,6 +270,12 @@ properties:
>        For PSCI based platforms, the name corresponding to the index of the PSCI
>        PM domain provider, must be "psci".
>  
> +  edac-enabled:
> +    $ref: '/schemas/types.yaml#/definitions/flag'
> +    description:
> +      Some CPUs support Error Detection And Correction (EDAC) on their L1 and
> +      L2 caches. This flag marks this function as usable.
> +
>    qcom,saw:
>      $ref: '/schemas/types.yaml#/definitions/phandle'
>      description: |
> diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
> index 3b1e2f3ccab6..6d5355bae80c 100644
> --- a/drivers/edac/cortex_arm64_l1_l2.c
> +++ b/drivers/edac/cortex_arm64_l1_l2.c
> @@ -190,8 +190,11 @@ static int __init cortex_arm64_edac_driver_init(void)
>  	for_each_possible_cpu(cpu) {
>  		np = of_get_cpu_node(cpu, NULL);
>  
> -		if (of_match_node(cortex_arm64_edac_of_match, np))
> -			cpumask_set_cpu(cpu, &compat_mask);
> +		if (!of_match_node(cortex_arm64_edac_of_match, np))
> +			continue;
> +		if (!of_property_read_bool(np, "edac-enabled"))
> +			continue;
> +		cpumask_set_cpu(cpu, &compat_mask);
>  	}
>  
>  	if (cpumask_empty(&compat_mask))

This last hunk must be part of the initial patch. Otherwise, it breaks
exactly as described in the commit message.

Thanks,

	M.

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


From lkp at intel.com  Thu Apr  1 16:42:31 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 1 Apr 2021 23:42:31 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1116/1701] drivers/gpio/gpio-xilinx.c:377:12:
 warning: conversion from 'long unsigned int' to 'unsigned int'
 changes value from '18446744071562067967' to '2147483647'
Message-ID: <202104012324.PajrO8Zo-lkp@intel.com>

Hi Srinivas,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 256f37f6020654ff3d8044852f75542882301a26 [1116/1701] gpio: xilinx: Add irq support to the driver
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/256f37f6020654ff3d8044852f75542882301a26
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 256f37f6020654ff3d8044852f75542882301a26
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-xilinx.c: In function 'xgpio_irq_mask':
>> drivers/gpio/gpio-xilinx.c:377:12: warning: conversion from 'long unsigned int' to 'unsigned int' changes value from '18446744071562067967' to '2147483647' [-Woverflow]
     377 |            ~XGPIO_GIER_IE);
   drivers/gpio/gpio-xilinx.c:39:45: note: in definition of macro 'xgpio_writereg'
      39 | # define xgpio_writereg(offset, val) writel(val, offset)
         |                                             ^~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_irqhandler':
   drivers/gpio/gpio-xilinx.c:472:14: warning: variable 'status' set but not used [-Wunused-but-set-variable]
     472 |  u32 offset, status, channel = 1;
         |              ^~~~~~


vim +377 drivers/gpio/gpio-xilinx.c

   342	
   343	/**
   344	 * xgpiops_irq_mask - Write the specified signal of the GPIO device.
   345	 * @irq_data: per irq and chip data passed down to chip functions
   346	 */
   347	static void xgpio_irq_mask(struct irq_data *irq_data)
   348	{
   349		unsigned long flags;
   350		struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
   351		u32 offset = irq_data->irq - chip->irq_base;
   352		u32 temp;
   353		s32 val;
   354		int index = xgpio_index(chip, 0);
   355	
   356		pr_debug("%s: Disable %d irq, irq_enable_mask 0x%x\n",
   357			 __func__, offset, chip->irq_enable);
   358	
   359		spin_lock_irqsave(&chip->gpio_lock[index], flags);
   360	
   361		chip->irq_enable &= ~BIT(offset);
   362	
   363		if (!chip->irq_enable) {
   364			/* Enable per channel interrupt */
   365			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   366			val = offset - chip->gpio_width[0] + 1;
   367			if (val > 0)
   368				temp &= 1;
   369			else
   370				temp &= 2;
   371			xgpio_writereg(chip->regs + XGPIO_IPIER_OFFSET, temp);
   372	
   373			/* Disable global interrupt if channel interrupts are unused */
   374			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   375			if (!temp)
   376				xgpio_writereg(chip->regs + XGPIO_GIER_OFFSET,
 > 377					       ~XGPIO_GIER_IE);
   378		}
   379		spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
   380	}
   381	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 61137 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210401/a35b2c82/attachment-0001.gz>

From dmugil2000 at gmail.com  Thu Apr  1 16:43:43 2021
From: dmugil2000 at gmail.com (Mugilraj Dhavachelvan)
Date: Thu,  1 Apr 2021 21:13:43 +0530
Subject: [PATCH] iio: adc: stm32-dfsdm: drop __func__ while using Dynamic debug
Message-ID: <20210401154343.41527-1-dmugil2000@gmail.com>

dropped __func__ while using dev_dbg() and pr_debug()

Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com>
---
 drivers/iio/adc/stm32-dfsdm-adc.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index 76a60d93fe23..95ec5f3c3126 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -198,7 +198,7 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
 	unsigned int p = fl->ford;	/* filter order (ford) */
 	struct stm32_dfsdm_filter_osr *flo = &fl->flo[fast];
 
-	pr_debug("%s: Requested oversampling: %d\n",  __func__, oversamp);
+	pr_debug("Requested oversampling: %d\n", oversamp);
 	/*
 	 * This function tries to compute filter oversampling and integrator
 	 * oversampling, base on oversampling ratio requested by user.
@@ -294,8 +294,8 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
 				}
 				flo->max = (s32)max;
 
-				pr_debug("%s: fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
-					 __func__, fast, flo->fosr, flo->iosr,
+				pr_debug("fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
+					 fast, flo->fosr, flo->iosr,
 					 flo->res, bits, flo->rshift,
 					 flo->lshift);
 			}
@@ -858,7 +858,7 @@ static void stm32_dfsdm_dma_buffer_done(void *data)
 	 * support in IIO.
 	 */
 
-	dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
+	dev_dbg(&indio_dev->dev, "pos = %d, available = %d\n",
 		adc->bufi, available);
 	old_pos = adc->bufi;
 
@@ -912,7 +912,7 @@ static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
 	if (!adc->dma_chan)
 		return -EINVAL;
 
-	dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
+	dev_dbg(&indio_dev->dev, "size=%d watermark=%d\n",
 		adc->buf_sz, adc->buf_sz / 2);
 
 	if (adc->nconv == 1 && !indio_dev->trig)
-- 
2.25.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:10 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:10 +0200
Subject: [PATCH v14 01/10] iommu: Fix comment for struct iommu_fwspec
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-2-jean-philippe@linaro.org>

Commit 986d5ecc5699 ("iommu: Move fwspec->iommu_priv to struct
dev_iommu") removed iommu_priv from fwspec and commit 5702ee24182f
("ACPI/IORT: Check ATS capability in root complex nodes") added @flags.
Update the struct doc.

Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 include/linux/iommu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 5e7fe519430a..1d422bf722a1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -571,7 +571,7 @@ struct iommu_group *fsl_mc_device_group(struct device *dev);
  * struct iommu_fwspec - per-device IOMMU instance data
  * @ops: ops for this device's IOMMU
  * @iommu_fwnode: firmware handle for this device's IOMMU
- * @iommu_priv: IOMMU driver private data for this device
+ * @flags: IOMMU_FWSPEC_* flags
  * @num_pasid_bits: number of PASID bits supported by this device
  * @num_ids: number of associated device IDs
  * @ids: IDs which this device may present to the IOMMU
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:11 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:11 +0200
Subject: [PATCH v14 02/10] iommu/arm-smmu-v3: Use device properties for
 pasid-num-bits
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-3-jean-philippe@linaro.org>

The pasid-num-bits property shouldn't need a dedicated fwspec field,
it's a job for device properties. Add properties for IORT, and access
the number of PASID bits using device_property_read_u32().

Suggested-by: Robin Murphy <robin.murphy at arm.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Acked-by: Will Deacon <will at kernel.org>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 include/linux/iommu.h                       |  2 --
 drivers/acpi/arm64/iort.c                   | 13 +++++++------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  3 ++-
 drivers/iommu/of_iommu.c                    |  5 -----
 4 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 1d422bf722a1..16ce75693d83 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -572,7 +572,6 @@ struct iommu_group *fsl_mc_device_group(struct device *dev);
  * @ops: ops for this device's IOMMU
  * @iommu_fwnode: firmware handle for this device's IOMMU
  * @flags: IOMMU_FWSPEC_* flags
- * @num_pasid_bits: number of PASID bits supported by this device
  * @num_ids: number of associated device IDs
  * @ids: IDs which this device may present to the IOMMU
  */
@@ -580,7 +579,6 @@ struct iommu_fwspec {
 	const struct iommu_ops	*ops;
 	struct fwnode_handle	*iommu_fwnode;
 	u32			flags;
-	u32			num_pasid_bits;
 	unsigned int		num_ids;
 	u32			ids[];
 };
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2494138a6905..3912a1f6058e 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -968,15 +968,16 @@ static int iort_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 static void iort_named_component_init(struct device *dev,
 				      struct acpi_iort_node *node)
 {
+	struct property_entry props[2] = {};
 	struct acpi_iort_named_component *nc;
-	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
-
-	if (!fwspec)
-		return;
 
 	nc = (struct acpi_iort_named_component *)node->node_data;
-	fwspec->num_pasid_bits = FIELD_GET(ACPI_IORT_NC_PASID_BITS,
-					   nc->node_flags);
+	props[0] = PROPERTY_ENTRY_U32("pasid-num-bits",
+				      FIELD_GET(ACPI_IORT_NC_PASID_BITS,
+						nc->node_flags));
+
+	if (device_add_properties(dev, props))
+		dev_warn(dev, "Could not add device properties\n");
 }
 
 static int iort_nc_iommu_map(struct device *dev, struct acpi_iort_node *node)
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 941ba5484731..bd77495023c8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2395,7 +2395,8 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 		}
 	}
 
-	master->ssid_bits = min(smmu->ssid_bits, fwspec->num_pasid_bits);
+	device_property_read_u32(dev, "pasid-num-bits", &master->ssid_bits);
+	master->ssid_bits = min(smmu->ssid_bits, master->ssid_bits);
 
 	/*
 	 * Note that PASID must be enabled before, and disabled after ATS:
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index e505b9130a1c..a9d2df001149 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -210,11 +210,6 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 					     of_pci_iommu_init, &info);
 	} else {
 		err = of_iommu_configure_device(master_np, dev, id);
-
-		fwspec = dev_iommu_fwspec_get(dev);
-		if (!err && fwspec)
-			of_property_read_u32(master_np, "pasid-num-bits",
-					     &fwspec->num_pasid_bits);
 	}
 
 	/*
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:12 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:12 +0200
Subject: [PATCH v14 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from
 IOMMU_DEV_FEAT_SVA
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-4-jean-philippe@linaro.org>

Some devices manage I/O Page Faults (IOPF) themselves instead of relying
on PCIe PRI or Arm SMMU stall. Allow their drivers to enable SVA without
mandating IOMMU-managed IOPF. The other device drivers now need to first
enable IOMMU_DEV_FEAT_IOPF before enabling IOMMU_DEV_FEAT_SVA. Enabling
IOMMU_DEV_FEAT_IOPF on its own doesn't have any effect visible to the
device driver, it is used in combination with other features.

Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Lu Baolu <baolu.lu at linux.intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Joerg Roedel <joro at 8bytes.org>
Cc: Lu Baolu <baolu.lu at linux.intel.com>
Cc: Will Deacon <will at kernel.org>
Cc: Zhangfei Gao <zhangfei.gao at linaro.org>
Cc: Zhou Wang <wangzhou1 at hisilicon.com>
---
 include/linux/iommu.h | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 16ce75693d83..45c4eb372f56 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -156,10 +156,24 @@ struct iommu_resv_region {
 	enum iommu_resv_type	type;
 };
 
-/* Per device IOMMU features */
+/**
+ * enum iommu_dev_features - Per device IOMMU features
+ * @IOMMU_DEV_FEAT_AUX: Auxiliary domain feature
+ * @IOMMU_DEV_FEAT_SVA: Shared Virtual Addresses
+ * @IOMMU_DEV_FEAT_IOPF: I/O Page Faults such as PRI or Stall. Generally
+ *			 enabling %IOMMU_DEV_FEAT_SVA requires
+ *			 %IOMMU_DEV_FEAT_IOPF, but some devices manage I/O Page
+ *			 Faults themselves instead of relying on the IOMMU. When
+ *			 supported, this feature must be enabled before and
+ *			 disabled after %IOMMU_DEV_FEAT_SVA.
+ *
+ * Device drivers query whether a feature is supported using
+ * iommu_dev_has_feature(), and enable it using iommu_dev_enable_feature().
+ */
 enum iommu_dev_features {
-	IOMMU_DEV_FEAT_AUX,	/* Aux-domain feature */
-	IOMMU_DEV_FEAT_SVA,	/* Shared Virtual Addresses */
+	IOMMU_DEV_FEAT_AUX,
+	IOMMU_DEV_FEAT_SVA,
+	IOMMU_DEV_FEAT_IOPF,
 };
 
 #define IOMMU_PASID_INVALID	(-1U)
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:13 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:13 +0200
Subject: [PATCH v14 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-5-jean-philippe@linaro.org>

Allow drivers to query and enable IOMMU_DEV_FEAT_IOPF, which amounts to
checking whether PRI is enabled.

Reviewed-by: Lu Baolu <baolu.lu at linux.intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Lu Baolu <baolu.lu at linux.intel.com>
---
 drivers/iommu/intel/iommu.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d64..c5c5fd444779 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5343,6 +5343,8 @@ static int siov_find_pci_dvsec(struct pci_dev *pdev)
 static bool
 intel_iommu_dev_has_feat(struct device *dev, enum iommu_dev_features feat)
 {
+	struct device_domain_info *info = get_domain_info(dev);
+
 	if (feat == IOMMU_DEV_FEAT_AUX) {
 		int ret;
 
@@ -5357,13 +5359,13 @@ intel_iommu_dev_has_feat(struct device *dev, enum iommu_dev_features feat)
 		return !!siov_find_pci_dvsec(to_pci_dev(dev));
 	}
 
-	if (feat == IOMMU_DEV_FEAT_SVA) {
-		struct device_domain_info *info = get_domain_info(dev);
+	if (feat == IOMMU_DEV_FEAT_IOPF)
+		return info && info->pri_supported;
 
+	if (feat == IOMMU_DEV_FEAT_SVA)
 		return info && (info->iommu->flags & VTD_FLAG_SVM_CAPABLE) &&
 			info->pasid_supported && info->pri_supported &&
 			info->ats_supported;
-	}
 
 	return false;
 }
@@ -5374,6 +5376,9 @@ intel_iommu_dev_enable_feat(struct device *dev, enum iommu_dev_features feat)
 	if (feat == IOMMU_DEV_FEAT_AUX)
 		return intel_iommu_enable_auxd(dev);
 
+	if (feat == IOMMU_DEV_FEAT_IOPF)
+		return intel_iommu_dev_has_feat(dev, feat) ? 0 : -ENODEV;
+
 	if (feat == IOMMU_DEV_FEAT_SVA) {
 		struct device_domain_info *info = get_domain_info(dev);
 
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:09 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:09 +0200
Subject: [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
Message-ID: <20210401154718.307519-1-jean-philippe@linaro.org>

Add stall support to the SMMUv3 driver, along with a common I/O Page
Fault handler.

Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert.
It would be good to have all of it in v5.13, since patch 10 introduces
the first user for the IOPF interface from patch 6.  But if that's not
possible, please pick patches 1-6 so the Vt-d driver can start using
them.

[v13] https://lore.kernel.org/linux-iommu/20210302092644.2553014-1-jean-philippe at linaro.org/

Jean-Philippe Brucker (10):
  iommu: Fix comment for struct iommu_fwspec
  iommu/arm-smmu-v3: Use device properties for pasid-num-bits
  iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
  iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF
  uacce: Enable IOMMU_DEV_FEAT_IOPF
  iommu: Add a page fault handler
  iommu/arm-smmu-v3: Maintain a SID->device structure
  dt-bindings: document stall property for IOMMU masters
  ACPI/IORT: Enable stall support for platform devices
  iommu/arm-smmu-v3: Add stall support for platform devices

 drivers/iommu/Makefile                        |   1 +
 .../devicetree/bindings/iommu/iommu.txt       |  18 +
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  56 ++-
 drivers/iommu/iommu-sva-lib.h                 |  53 ++
 include/linux/iommu.h                         |  26 +-
 drivers/acpi/arm64/iort.c                     |  15 +-
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  59 ++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 355 ++++++++++++--
 drivers/iommu/intel/iommu.c                   |  11 +-
 drivers/iommu/io-pgfault.c                    | 461 ++++++++++++++++++
 drivers/iommu/of_iommu.c                      |   5 -
 drivers/misc/uacce/uacce.c                    |  39 +-
 12 files changed, 1025 insertions(+), 74 deletions(-)
 create mode 100644 drivers/iommu/io-pgfault.c

-- 
2.31.1



From broonie at kernel.org  Thu Apr  1 16:48:05 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 16:48:05 +0100
Subject: [PATCH] arm64: Disable fine grained traps on boot
In-Reply-To: <87sg4aox44.wl-maz@kernel.org>
References: <20210401124936.56877-1-broonie@kernel.org>
 <87sg4aox44.wl-maz@kernel.org>
Message-ID: <20210401154805.GL4758@sirena.org.uk>

On Thu, Apr 01, 2021 at 04:14:35PM +0100, Marc Zyngier wrote:
> On Thu, 01 Apr 2021 13:49:36 +0100,
> Mark Brown <broonie at kernel.org> wrote:

> > +	msr_s	SYS_HFGRTR_EL2, xzr
> > +	msr_s	SYS_HFGITR_EL2, xzr
> > +	msr_s	SYS_HFGWTR_EL2, xzr

> nit: consider grouping SYS_HFGWTR_EL2 and SYS_HFGRTR_EL2 together,
> since they affect the same registers.

Ack, I'd sorted them numerically IIRC.

> > +	mrs	x1, id_aa64pfr0_el1		// AMU traps UNDEF without AMU
> > +	ubfx	x1, x1, #ID_AA64PFR0_AMU_SHIFT, #4
> > +	cbz	x1, .Lskip_fgt_\@

> > +	msr_s	SYS_HAFGRTR_EL2, xzr

> Do we need to document the need for SCR_EL3.FGTEn to be set so that
> these register accesses don't trap? That'd be consistent with what we
> do for other features (PtrAuth, AMU...).

Yes, good point.  We should if this is going in - this is the result of
some other stuff I've been sending to document disabling these on boot,
Will wanted to have code doing that, so I'll pull that into there.  It
does end up being a bit weird that we demand this be enabled so we can
explicitly not use it, but better to do that so we can in future decide
to take advantage of it.
-------------- 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/20210401/02429900/attachment-0001.sig>

From jean-philippe at linaro.org  Thu Apr  1 16:47:14 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:14 +0200
Subject: [PATCH v14 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-6-jean-philippe@linaro.org>

The IOPF (I/O Page Fault) feature is now enabled independently from the
SVA feature, because some IOPF implementations are device-specific and
do not require IOMMU support for PCIe PRI or Arm SMMU stall.

Enable IOPF unconditionally when enabling SVA for now. In the future, if
a device driver implementing a uacce interface doesn't need IOPF
support, it will need to tell the uacce module, for example with a new
flag.

Acked-by: Zhangfei Gao <zhangfei.gao at linaro.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Zhangfei Gao <zhangfei.gao at linaro.org>
Cc: Zhou Wang <wangzhou1 at hisilicon.com>
---
 drivers/misc/uacce/uacce.c | 39 +++++++++++++++++++++++++++++---------
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c
index d07af4edfcac..6db7a98486ec 100644
--- a/drivers/misc/uacce/uacce.c
+++ b/drivers/misc/uacce/uacce.c
@@ -385,6 +385,33 @@ static void uacce_release(struct device *dev)
 	kfree(uacce);
 }
 
+static unsigned int uacce_enable_sva(struct device *parent, unsigned int flags)
+{
+	if (!(flags & UACCE_DEV_SVA))
+		return flags;
+
+	flags &= ~UACCE_DEV_SVA;
+
+	if (iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_IOPF))
+		return flags;
+
+	if (iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_SVA)) {
+		iommu_dev_disable_feature(parent, IOMMU_DEV_FEAT_IOPF);
+		return flags;
+	}
+
+	return flags | UACCE_DEV_SVA;
+}
+
+static void uacce_disable_sva(struct uacce_device *uacce)
+{
+	if (!(uacce->flags & UACCE_DEV_SVA))
+		return;
+
+	iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_SVA);
+	iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_IOPF);
+}
+
 /**
  * uacce_alloc() - alloc an accelerator
  * @parent: pointer of uacce parent device
@@ -404,11 +431,7 @@ struct uacce_device *uacce_alloc(struct device *parent,
 	if (!uacce)
 		return ERR_PTR(-ENOMEM);
 
-	if (flags & UACCE_DEV_SVA) {
-		ret = iommu_dev_enable_feature(parent, IOMMU_DEV_FEAT_SVA);
-		if (ret)
-			flags &= ~UACCE_DEV_SVA;
-	}
+	flags = uacce_enable_sva(parent, flags);
 
 	uacce->parent = parent;
 	uacce->flags = flags;
@@ -432,8 +455,7 @@ struct uacce_device *uacce_alloc(struct device *parent,
 	return uacce;
 
 err_with_uacce:
-	if (flags & UACCE_DEV_SVA)
-		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_SVA);
+	uacce_disable_sva(uacce);
 	kfree(uacce);
 	return ERR_PTR(ret);
 }
@@ -487,8 +509,7 @@ void uacce_remove(struct uacce_device *uacce)
 	mutex_unlock(&uacce->queues_lock);
 
 	/* disable sva now since no opened queues */
-	if (uacce->flags & UACCE_DEV_SVA)
-		iommu_dev_disable_feature(uacce->parent, IOMMU_DEV_FEAT_SVA);
+	uacce_disable_sva(uacce);
 
 	if (uacce->cdev)
 		cdev_device_del(uacce->cdev, &uacce->dev);
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:16 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:16 +0200
Subject: [PATCH v14 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-8-jean-philippe@linaro.org>

When handling faults from the event or PRI queue, we need to find the
struct device associated with a SID. Add a rb_tree to keep track of
SIDs.

Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  13 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 158 ++++++++++++++++----
 2 files changed, 141 insertions(+), 30 deletions(-)

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 230b6f6b3901..1b463e27bca1 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -639,6 +639,15 @@ struct arm_smmu_device {
 
 	/* IOMMU core code handle */
 	struct iommu_device		iommu;
+
+	struct rb_root			streams;
+	struct mutex			streams_mutex;
+};
+
+struct arm_smmu_stream {
+	u32				id;
+	struct arm_smmu_master		*master;
+	struct rb_node			node;
 };
 
 /* SMMU private data for each master */
@@ -647,8 +656,8 @@ struct arm_smmu_master {
 	struct device			*dev;
 	struct arm_smmu_domain		*domain;
 	struct list_head		domain_head;
-	u32				*sids;
-	unsigned int			num_sids;
+	struct arm_smmu_stream		*streams;
+	unsigned int			num_streams;
 	bool				ats_enabled;
 	bool				sva_enabled;
 	struct list_head		bonds;
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 bd77495023c8..8279291660b2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -909,8 +909,8 @@ static void arm_smmu_sync_cd(struct arm_smmu_domain *smmu_domain,
 
 	spin_lock_irqsave(&smmu_domain->devices_lock, flags);
 	list_for_each_entry(master, &smmu_domain->devices, domain_head) {
-		for (i = 0; i < master->num_sids; i++) {
-			cmd.cfgi.sid = master->sids[i];
+		for (i = 0; i < master->num_streams; i++) {
+			cmd.cfgi.sid = master->streams[i].id;
 			arm_smmu_cmdq_batch_add(smmu, &cmds, &cmd);
 		}
 	}
@@ -1355,6 +1355,29 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
 	return 0;
 }
 
+__maybe_unused
+static struct arm_smmu_master *
+arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
+{
+	struct rb_node *node;
+	struct arm_smmu_stream *stream;
+
+	lockdep_assert_held(&smmu->streams_mutex);
+
+	node = smmu->streams.rb_node;
+	while (node) {
+		stream = rb_entry(node, struct arm_smmu_stream, node);
+		if (stream->id < sid)
+			node = node->rb_right;
+		else if (stream->id > sid)
+			node = node->rb_left;
+		else
+			return stream->master;
+	}
+
+	return NULL;
+}
+
 /* IRQ and event handlers */
 static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
 {
@@ -1588,8 +1611,8 @@ static int arm_smmu_atc_inv_master(struct arm_smmu_master *master)
 
 	arm_smmu_atc_inv_to_cmd(0, 0, 0, &cmd);
 
-	for (i = 0; i < master->num_sids; i++) {
-		cmd.atc.sid = master->sids[i];
+	for (i = 0; i < master->num_streams; i++) {
+		cmd.atc.sid = master->streams[i].id;
 		arm_smmu_cmdq_issue_cmd(master->smmu, &cmd);
 	}
 
@@ -1632,8 +1655,8 @@ int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, int ssid,
 		if (!master->ats_enabled)
 			continue;
 
-		for (i = 0; i < master->num_sids; i++) {
-			cmd.atc.sid = master->sids[i];
+		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);
 		}
 	}
@@ -2065,13 +2088,13 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
 	int i, j;
 	struct arm_smmu_device *smmu = master->smmu;
 
-	for (i = 0; i < master->num_sids; ++i) {
-		u32 sid = master->sids[i];
+	for (i = 0; i < master->num_streams; ++i) {
+		u32 sid = master->streams[i].id;
 		__le64 *step = arm_smmu_get_step_for_sid(smmu, sid);
 
 		/* Bridged PCI devices may end up with duplicated IDs */
 		for (j = 0; j < i; j++)
-			if (master->sids[j] == sid)
+			if (master->streams[j].id == sid)
 				break;
 		if (j < i)
 			continue;
@@ -2348,11 +2371,101 @@ static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
 	return sid < limit;
 }
 
+static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
+				  struct arm_smmu_master *master)
+{
+	int i;
+	int ret = 0;
+	struct arm_smmu_stream *new_stream, *cur_stream;
+	struct rb_node **new_node, *parent_node = NULL;
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
+
+	master->streams = kcalloc(fwspec->num_ids, sizeof(*master->streams),
+				  GFP_KERNEL);
+	if (!master->streams)
+		return -ENOMEM;
+	master->num_streams = fwspec->num_ids;
+
+	mutex_lock(&smmu->streams_mutex);
+	for (i = 0; i < fwspec->num_ids; i++) {
+		u32 sid = fwspec->ids[i];
+
+		new_stream = &master->streams[i];
+		new_stream->id = sid;
+		new_stream->master = master;
+
+		/*
+		 * Check the SIDs are in range of the SMMU and our stream table
+		 */
+		if (!arm_smmu_sid_in_range(smmu, sid)) {
+			ret = -ERANGE;
+			break;
+		}
+
+		/* Ensure l2 strtab is initialised */
+		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
+			ret = arm_smmu_init_l2_strtab(smmu, sid);
+			if (ret)
+				break;
+		}
+
+		/* Insert into SID tree */
+		new_node = &(smmu->streams.rb_node);
+		while (*new_node) {
+			cur_stream = rb_entry(*new_node, struct arm_smmu_stream,
+					      node);
+			parent_node = *new_node;
+			if (cur_stream->id > new_stream->id) {
+				new_node = &((*new_node)->rb_left);
+			} else if (cur_stream->id < new_stream->id) {
+				new_node = &((*new_node)->rb_right);
+			} else {
+				dev_warn(master->dev,
+					 "stream %u already in tree\n",
+					 cur_stream->id);
+				ret = -EINVAL;
+				break;
+			}
+		}
+		if (ret)
+			break;
+
+		rb_link_node(&new_stream->node, parent_node, new_node);
+		rb_insert_color(&new_stream->node, &smmu->streams);
+	}
+
+	if (ret) {
+		for (i--; i >= 0; i--)
+			rb_erase(&master->streams[i].node, &smmu->streams);
+		kfree(master->streams);
+	}
+	mutex_unlock(&smmu->streams_mutex);
+
+	return ret;
+}
+
+static void arm_smmu_remove_master(struct arm_smmu_master *master)
+{
+	int i;
+	struct arm_smmu_device *smmu = master->smmu;
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
+
+	if (!smmu || !master->streams)
+		return;
+
+	mutex_lock(&smmu->streams_mutex);
+	for (i = 0; i < fwspec->num_ids; i++)
+		rb_erase(&master->streams[i].node, &smmu->streams);
+	mutex_unlock(&smmu->streams_mutex);
+
+	kfree(master->streams);
+}
+
 static struct iommu_ops arm_smmu_ops;
 
 static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 {
-	int i, ret;
+	int ret;
 	struct arm_smmu_device *smmu;
 	struct arm_smmu_master *master;
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
@@ -2373,27 +2486,12 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 
 	master->dev = dev;
 	master->smmu = smmu;
-	master->sids = fwspec->ids;
-	master->num_sids = fwspec->num_ids;
 	INIT_LIST_HEAD(&master->bonds);
 	dev_iommu_priv_set(dev, master);
 
-	/* Check the SIDs are in range of the SMMU and our stream table */
-	for (i = 0; i < master->num_sids; i++) {
-		u32 sid = master->sids[i];
-
-		if (!arm_smmu_sid_in_range(smmu, sid)) {
-			ret = -ERANGE;
-			goto err_free_master;
-		}
-
-		/* Ensure l2 strtab is initialised */
-		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
-			ret = arm_smmu_init_l2_strtab(smmu, sid);
-			if (ret)
-				goto err_free_master;
-		}
-	}
+	ret = arm_smmu_insert_master(smmu, master);
+	if (ret)
+		goto err_free_master;
 
 	device_property_read_u32(dev, "pasid-num-bits", &master->ssid_bits);
 	master->ssid_bits = min(smmu->ssid_bits, master->ssid_bits);
@@ -2432,6 +2530,7 @@ static void arm_smmu_release_device(struct device *dev)
 	WARN_ON(arm_smmu_master_sva_enabled(master));
 	arm_smmu_detach_dev(master);
 	arm_smmu_disable_pasid(master);
+	arm_smmu_remove_master(master);
 	kfree(master);
 	iommu_fwspec_free(dev);
 }
@@ -2855,6 +2954,9 @@ static int arm_smmu_init_structures(struct arm_smmu_device *smmu)
 {
 	int ret;
 
+	mutex_init(&smmu->streams_mutex);
+	smmu->streams = RB_ROOT;
+
 	ret = arm_smmu_init_queues(smmu);
 	if (ret)
 		return ret;
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:17 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:17 +0200
Subject: [PATCH v14 08/10] dt-bindings: document stall property for IOMMU
 masters
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-9-jean-philippe@linaro.org>

On ARM systems, some platform devices behind an IOMMU may support stall,
which is the ability to recover from page faults. Let the firmware tell us
when a device supports stall.

Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 .../devicetree/bindings/iommu/iommu.txt        | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt
index 3c36334e4f94..26ba9e530f13 100644
--- a/Documentation/devicetree/bindings/iommu/iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -92,6 +92,24 @@ Optional properties:
   tagging DMA transactions with an address space identifier. By default,
   this is 0, which means that the device only has one address space.
 
+- dma-can-stall: When present, the master can wait for a transaction to
+  complete for an indefinite amount of time. Upon translation fault some
+  IOMMUs, instead of aborting the translation immediately, may first
+  notify the driver and keep the transaction in flight. This allows the OS
+  to inspect the fault and, for example, make physical pages resident
+  before updating the mappings and completing the transaction. Such IOMMU
+  accepts a limited number of simultaneous stalled transactions before
+  having to either put back-pressure on the master, or abort new faulting
+  transactions.
+
+  Firmware has to opt-in stalling, because most buses and masters don't
+  support it. In particular it isn't compatible with PCI, where
+  transactions have to complete before a time limit. More generally it
+  won't work in systems and masters that haven't been designed for
+  stalling. For example the OS, in order to handle a stalled transaction,
+  may attempt to retrieve pages from secondary storage in a stalled
+  domain, leading to a deadlock.
+
 
 Notes:
 ======
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:18 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:18 +0200
Subject: [PATCH v14 09/10] ACPI/IORT: Enable stall support for platform devices
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-10-jean-philippe@linaro.org>

Copy the "Stall supported" bit, that tells whether a named component
supports stall, into the dma-can-stall device property.

Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/acpi/arm64/iort.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 3912a1f6058e..0828f70cb782 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -968,13 +968,15 @@ static int iort_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 static void iort_named_component_init(struct device *dev,
 				      struct acpi_iort_node *node)
 {
-	struct property_entry props[2] = {};
+	struct property_entry props[3] = {};
 	struct acpi_iort_named_component *nc;
 
 	nc = (struct acpi_iort_named_component *)node->node_data;
 	props[0] = PROPERTY_ENTRY_U32("pasid-num-bits",
 				      FIELD_GET(ACPI_IORT_NC_PASID_BITS,
 						nc->node_flags));
+	if (nc->node_flags & ACPI_IORT_NC_STALL_SUPPORTED)
+		props[1] = PROPERTY_ENTRY_BOOL("dma-can-stall");
 
 	if (device_add_properties(dev, props))
 		dev_warn(dev, "Could not add device properties\n");
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:15 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:15 +0200
Subject: [PATCH v14 06/10] iommu: Add a page fault handler
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-7-jean-philippe@linaro.org>

Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCIe PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
fault report API"). Add a page fault handler for host SVA.

IOMMU driver can now instantiate several fault workqueues and link them
to IOPF-capable devices. Drivers can choose between a single global
workqueue, one per IOMMU device, one per low-level fault queue, one per
domain, etc.

When it receives a fault event, most commonly in an IRQ handler, the
IOMMU driver reports the fault using iommu_report_device_fault(), which
calls the registered handler. The page fault handler then calls the mm
fault handler, and reports either success or failure with
iommu_page_response(). After the handler succeeds, the hardware retries
the access.

The iopf_param pointer could be embedded into iommu_fault_param. But
putting iopf_param into the iommu_param structure allows us not to care
about ordering between calls to iopf_queue_add_device() and
iommu_register_device_fault_handler().

Tested-by: Lu Baolu <baolu.lu at linux.intel.com>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Jacob Pan <jacob.jun.pan at linux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Reviewed-by: Lu Baolu <baolu.lu at linux.intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/iommu/Makefile        |   1 +
 drivers/iommu/iommu-sva-lib.h |  53 ++++
 include/linux/iommu.h         |   2 +
 drivers/iommu/io-pgfault.c    | 461 ++++++++++++++++++++++++++++++++++
 4 files changed, 517 insertions(+)
 create mode 100644 drivers/iommu/io-pgfault.c

diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 61bd30cd8369..60fafc23dee6 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
 obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
 obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
 obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o
+obj-$(CONFIG_IOMMU_SVA_LIB) += io-pgfault.o
diff --git a/drivers/iommu/iommu-sva-lib.h b/drivers/iommu/iommu-sva-lib.h
index b40990aef3fd..031155010ca8 100644
--- a/drivers/iommu/iommu-sva-lib.h
+++ b/drivers/iommu/iommu-sva-lib.h
@@ -12,4 +12,57 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t min, ioasid_t max);
 void iommu_sva_free_pasid(struct mm_struct *mm);
 struct mm_struct *iommu_sva_find(ioasid_t pasid);
 
+/* I/O Page fault */
+struct device;
+struct iommu_fault;
+struct iopf_queue;
+
+#ifdef CONFIG_IOMMU_SVA_LIB
+int iommu_queue_iopf(struct iommu_fault *fault, void *cookie);
+
+int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev);
+int iopf_queue_remove_device(struct iopf_queue *queue,
+			     struct device *dev);
+int iopf_queue_flush_dev(struct device *dev);
+struct iopf_queue *iopf_queue_alloc(const char *name);
+void iopf_queue_free(struct iopf_queue *queue);
+int iopf_queue_discard_partial(struct iopf_queue *queue);
+
+#else /* CONFIG_IOMMU_SVA_LIB */
+static inline int iommu_queue_iopf(struct iommu_fault *fault, void *cookie)
+{
+	return -ENODEV;
+}
+
+static inline int iopf_queue_add_device(struct iopf_queue *queue,
+					struct device *dev)
+{
+	return -ENODEV;
+}
+
+static inline int iopf_queue_remove_device(struct iopf_queue *queue,
+					   struct device *dev)
+{
+	return -ENODEV;
+}
+
+static inline int iopf_queue_flush_dev(struct device *dev)
+{
+	return -ENODEV;
+}
+
+static inline struct iopf_queue *iopf_queue_alloc(const char *name)
+{
+	return NULL;
+}
+
+static inline void iopf_queue_free(struct iopf_queue *queue)
+{
+}
+
+static inline int iopf_queue_discard_partial(struct iopf_queue *queue)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_IOMMU_SVA_LIB */
 #endif /* _IOMMU_SVA_LIB_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 45c4eb372f56..86d688c4418f 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -367,6 +367,7 @@ struct iommu_fault_param {
  * struct dev_iommu - Collection of per-device IOMMU data
  *
  * @fault_param: IOMMU detected device fault reporting data
+ * @iopf_param:	 I/O Page Fault queue and data
  * @fwspec:	 IOMMU fwspec data
  * @iommu_dev:	 IOMMU device this device is linked to
  * @priv:	 IOMMU Driver private data
@@ -377,6 +378,7 @@ struct iommu_fault_param {
 struct dev_iommu {
 	struct mutex lock;
 	struct iommu_fault_param	*fault_param;
+	struct iopf_device_param	*iopf_param;
 	struct iommu_fwspec		*fwspec;
 	struct iommu_device		*iommu_dev;
 	void				*priv;
diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
new file mode 100644
index 000000000000..1df8c1dcae77
--- /dev/null
+++ b/drivers/iommu/io-pgfault.c
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Handle device page faults
+ *
+ * Copyright (C) 2020 ARM Ltd.
+ */
+
+#include <linux/iommu.h>
+#include <linux/list.h>
+#include <linux/sched/mm.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#include "iommu-sva-lib.h"
+
+/**
+ * struct iopf_queue - IO Page Fault queue
+ * @wq: the fault workqueue
+ * @devices: devices attached to this queue
+ * @lock: protects the device list
+ */
+struct iopf_queue {
+	struct workqueue_struct		*wq;
+	struct list_head		devices;
+	struct mutex			lock;
+};
+
+/**
+ * struct iopf_device_param - IO Page Fault data attached to a device
+ * @dev: the device that owns this param
+ * @queue: IOPF queue
+ * @queue_list: index into queue->devices
+ * @partial: faults that are part of a Page Request Group for which the last
+ *           request hasn't been submitted yet.
+ */
+struct iopf_device_param {
+	struct device			*dev;
+	struct iopf_queue		*queue;
+	struct list_head		queue_list;
+	struct list_head		partial;
+};
+
+struct iopf_fault {
+	struct iommu_fault		fault;
+	struct list_head		list;
+};
+
+struct iopf_group {
+	struct iopf_fault		last_fault;
+	struct list_head		faults;
+	struct work_struct		work;
+	struct device			*dev;
+};
+
+static int iopf_complete_group(struct device *dev, struct iopf_fault *iopf,
+			       enum iommu_page_response_code status)
+{
+	struct iommu_page_response resp = {
+		.version		= IOMMU_PAGE_RESP_VERSION_1,
+		.pasid			= iopf->fault.prm.pasid,
+		.grpid			= iopf->fault.prm.grpid,
+		.code			= status,
+	};
+
+	if ((iopf->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) &&
+	    (iopf->fault.prm.flags & IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID))
+		resp.flags = IOMMU_PAGE_RESP_PASID_VALID;
+
+	return iommu_page_response(dev, &resp);
+}
+
+static enum iommu_page_response_code
+iopf_handle_single(struct iopf_fault *iopf)
+{
+	vm_fault_t ret;
+	struct mm_struct *mm;
+	struct vm_area_struct *vma;
+	unsigned int access_flags = 0;
+	unsigned int fault_flags = FAULT_FLAG_REMOTE;
+	struct iommu_fault_page_request *prm = &iopf->fault.prm;
+	enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
+
+	if (!(prm->flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID))
+		return status;
+
+	mm = iommu_sva_find(prm->pasid);
+	if (IS_ERR_OR_NULL(mm))
+		return status;
+
+	mmap_read_lock(mm);
+
+	vma = find_extend_vma(mm, prm->addr);
+	if (!vma)
+		/* Unmapped area */
+		goto out_put_mm;
+
+	if (prm->perm & IOMMU_FAULT_PERM_READ)
+		access_flags |= VM_READ;
+
+	if (prm->perm & IOMMU_FAULT_PERM_WRITE) {
+		access_flags |= VM_WRITE;
+		fault_flags |= FAULT_FLAG_WRITE;
+	}
+
+	if (prm->perm & IOMMU_FAULT_PERM_EXEC) {
+		access_flags |= VM_EXEC;
+		fault_flags |= FAULT_FLAG_INSTRUCTION;
+	}
+
+	if (!(prm->perm & IOMMU_FAULT_PERM_PRIV))
+		fault_flags |= FAULT_FLAG_USER;
+
+	if (access_flags & ~vma->vm_flags)
+		/* Access fault */
+		goto out_put_mm;
+
+	ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
+	status = ret & VM_FAULT_ERROR ? IOMMU_PAGE_RESP_INVALID :
+		IOMMU_PAGE_RESP_SUCCESS;
+
+out_put_mm:
+	mmap_read_unlock(mm);
+	mmput(mm);
+
+	return status;
+}
+
+static void iopf_handle_group(struct work_struct *work)
+{
+	struct iopf_group *group;
+	struct iopf_fault *iopf, *next;
+	enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
+
+	group = container_of(work, struct iopf_group, work);
+
+	list_for_each_entry_safe(iopf, next, &group->faults, list) {
+		/*
+		 * For the moment, errors are sticky: don't handle subsequent
+		 * faults in the group if there is an error.
+		 */
+		if (status == IOMMU_PAGE_RESP_SUCCESS)
+			status = iopf_handle_single(iopf);
+
+		if (!(iopf->fault.prm.flags &
+		      IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
+			kfree(iopf);
+	}
+
+	iopf_complete_group(group->dev, &group->last_fault, status);
+	kfree(group);
+}
+
+/**
+ * iommu_queue_iopf - IO Page Fault handler
+ * @fault: fault event
+ * @cookie: struct device, passed to iommu_register_device_fault_handler.
+ *
+ * Add a fault to the device workqueue, to be handled by mm.
+ *
+ * This module doesn't handle PCI PASID Stop Marker; IOMMU drivers must discard
+ * them before reporting faults. A PASID Stop Marker (LRW = 0b100) doesn't
+ * expect a response. It may be generated when disabling a PASID (issuing a
+ * PASID stop request) by some PCI devices.
+ *
+ * The PASID stop request is issued by the device driver before unbind(). Once
+ * it completes, no page request is generated for this PASID anymore and
+ * outstanding ones have been pushed to the IOMMU (as per PCIe 4.0r1.0 - 6.20.1
+ * and 10.4.1.2 - Managing PASID TLP Prefix Usage). Some PCI devices will wait
+ * for all outstanding page requests to come back with a response before
+ * completing the PASID stop request. Others do not wait for page responses, and
+ * instead issue this Stop Marker that tells us when the PASID can be
+ * reallocated.
+ *
+ * It is safe to discard the Stop Marker because it is an optimization.
+ * a. Page requests, which are posted requests, have been flushed to the IOMMU
+ *    when the stop request completes.
+ * b. The IOMMU driver flushes all fault queues on unbind() before freeing the
+ *    PASID.
+ *
+ * So even though the Stop Marker might be issued by the device *after* the stop
+ * request completes, outstanding faults will have been dealt with by the time
+ * the PASID is freed.
+ *
+ * Return: 0 on success and <0 on error.
+ */
+int iommu_queue_iopf(struct iommu_fault *fault, void *cookie)
+{
+	int ret;
+	struct iopf_group *group;
+	struct iopf_fault *iopf, *next;
+	struct iopf_device_param *iopf_param;
+
+	struct device *dev = cookie;
+	struct dev_iommu *param = dev->iommu;
+
+	lockdep_assert_held(&param->lock);
+
+	if (fault->type != IOMMU_FAULT_PAGE_REQ)
+		/* Not a recoverable page fault */
+		return -EOPNOTSUPP;
+
+	/*
+	 * As long as we're holding param->lock, the queue can't be unlinked
+	 * from the device and therefore cannot disappear.
+	 */
+	iopf_param = param->iopf_param;
+	if (!iopf_param)
+		return -ENODEV;
+
+	if (!(fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
+		iopf = kzalloc(sizeof(*iopf), GFP_KERNEL);
+		if (!iopf)
+			return -ENOMEM;
+
+		iopf->fault = *fault;
+
+		/* Non-last request of a group. Postpone until the last one */
+		list_add(&iopf->list, &iopf_param->partial);
+
+		return 0;
+	}
+
+	group = kzalloc(sizeof(*group), GFP_KERNEL);
+	if (!group) {
+		/*
+		 * The caller will send a response to the hardware. But we do
+		 * need to clean up before leaving, otherwise partial faults
+		 * will be stuck.
+		 */
+		ret = -ENOMEM;
+		goto cleanup_partial;
+	}
+
+	group->dev = dev;
+	group->last_fault.fault = *fault;
+	INIT_LIST_HEAD(&group->faults);
+	list_add(&group->last_fault.list, &group->faults);
+	INIT_WORK(&group->work, iopf_handle_group);
+
+	/* See if we have partial faults for this group */
+	list_for_each_entry_safe(iopf, next, &iopf_param->partial, list) {
+		if (iopf->fault.prm.grpid == fault->prm.grpid)
+			/* Insert *before* the last fault */
+			list_move(&iopf->list, &group->faults);
+	}
+
+	queue_work(iopf_param->queue->wq, &group->work);
+	return 0;
+
+cleanup_partial:
+	list_for_each_entry_safe(iopf, next, &iopf_param->partial, list) {
+		if (iopf->fault.prm.grpid == fault->prm.grpid) {
+			list_del(&iopf->list);
+			kfree(iopf);
+		}
+	}
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_queue_iopf);
+
+/**
+ * iopf_queue_flush_dev - Ensure that all queued faults have been processed
+ * @dev: the endpoint whose faults need to be flushed.
+ *
+ * The IOMMU driver calls this before releasing a PASID, to ensure that all
+ * pending faults for this PASID have been handled, and won't hit the address
+ * space of the next process that uses this PASID. The driver must make sure
+ * that no new fault is added to the queue. In particular it must flush its
+ * low-level queue before calling this function.
+ *
+ * Return: 0 on success and <0 on error.
+ */
+int iopf_queue_flush_dev(struct device *dev)
+{
+	int ret = 0;
+	struct iopf_device_param *iopf_param;
+	struct dev_iommu *param = dev->iommu;
+
+	if (!param)
+		return -ENODEV;
+
+	mutex_lock(&param->lock);
+	iopf_param = param->iopf_param;
+	if (iopf_param)
+		flush_workqueue(iopf_param->queue->wq);
+	else
+		ret = -ENODEV;
+	mutex_unlock(&param->lock);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iopf_queue_flush_dev);
+
+/**
+ * iopf_queue_discard_partial - Remove all pending partial fault
+ * @queue: the queue whose partial faults need to be discarded
+ *
+ * When the hardware queue overflows, last page faults in a group may have been
+ * lost and the IOMMU driver calls this to discard all partial faults. The
+ * driver shouldn't be adding new faults to this queue concurrently.
+ *
+ * Return: 0 on success and <0 on error.
+ */
+int iopf_queue_discard_partial(struct iopf_queue *queue)
+{
+	struct iopf_fault *iopf, *next;
+	struct iopf_device_param *iopf_param;
+
+	if (!queue)
+		return -EINVAL;
+
+	mutex_lock(&queue->lock);
+	list_for_each_entry(iopf_param, &queue->devices, queue_list) {
+		list_for_each_entry_safe(iopf, next, &iopf_param->partial,
+					 list) {
+			list_del(&iopf->list);
+			kfree(iopf);
+		}
+	}
+	mutex_unlock(&queue->lock);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(iopf_queue_discard_partial);
+
+/**
+ * iopf_queue_add_device - Add producer to the fault queue
+ * @queue: IOPF queue
+ * @dev: device to add
+ *
+ * Return: 0 on success and <0 on error.
+ */
+int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev)
+{
+	int ret = -EBUSY;
+	struct iopf_device_param *iopf_param;
+	struct dev_iommu *param = dev->iommu;
+
+	if (!param)
+		return -ENODEV;
+
+	iopf_param = kzalloc(sizeof(*iopf_param), GFP_KERNEL);
+	if (!iopf_param)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&iopf_param->partial);
+	iopf_param->queue = queue;
+	iopf_param->dev = dev;
+
+	mutex_lock(&queue->lock);
+	mutex_lock(&param->lock);
+	if (!param->iopf_param) {
+		list_add(&iopf_param->queue_list, &queue->devices);
+		param->iopf_param = iopf_param;
+		ret = 0;
+	}
+	mutex_unlock(&param->lock);
+	mutex_unlock(&queue->lock);
+
+	if (ret)
+		kfree(iopf_param);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iopf_queue_add_device);
+
+/**
+ * iopf_queue_remove_device - Remove producer from fault queue
+ * @queue: IOPF queue
+ * @dev: device to remove
+ *
+ * Caller makes sure that no more faults are reported for this device.
+ *
+ * Return: 0 on success and <0 on error.
+ */
+int iopf_queue_remove_device(struct iopf_queue *queue, struct device *dev)
+{
+	int ret = -EINVAL;
+	struct iopf_fault *iopf, *next;
+	struct iopf_device_param *iopf_param;
+	struct dev_iommu *param = dev->iommu;
+
+	if (!param || !queue)
+		return -EINVAL;
+
+	mutex_lock(&queue->lock);
+	mutex_lock(&param->lock);
+	iopf_param = param->iopf_param;
+	if (iopf_param && iopf_param->queue == queue) {
+		list_del(&iopf_param->queue_list);
+		param->iopf_param = NULL;
+		ret = 0;
+	}
+	mutex_unlock(&param->lock);
+	mutex_unlock(&queue->lock);
+	if (ret)
+		return ret;
+
+	/* Just in case some faults are still stuck */
+	list_for_each_entry_safe(iopf, next, &iopf_param->partial, list)
+		kfree(iopf);
+
+	kfree(iopf_param);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
+
+/**
+ * iopf_queue_alloc - Allocate and initialize a fault queue
+ * @name: a unique string identifying the queue (for workqueue)
+ *
+ * Return: the queue on success and NULL on error.
+ */
+struct iopf_queue *iopf_queue_alloc(const char *name)
+{
+	struct iopf_queue *queue;
+
+	queue = kzalloc(sizeof(*queue), GFP_KERNEL);
+	if (!queue)
+		return NULL;
+
+	/*
+	 * The WQ is unordered because the low-level handler enqueues faults by
+	 * group. PRI requests within a group have to be ordered, but once
+	 * that's dealt with, the high-level function can handle groups out of
+	 * order.
+	 */
+	queue->wq = alloc_workqueue("iopf_queue/%s", WQ_UNBOUND, 0, name);
+	if (!queue->wq) {
+		kfree(queue);
+		return NULL;
+	}
+
+	INIT_LIST_HEAD(&queue->devices);
+	mutex_init(&queue->lock);
+
+	return queue;
+}
+EXPORT_SYMBOL_GPL(iopf_queue_alloc);
+
+/**
+ * iopf_queue_free - Free IOPF queue
+ * @queue: queue to free
+ *
+ * Counterpart to iopf_queue_alloc(). The driver must not be queuing faults or
+ * adding/removing devices on this queue anymore.
+ */
+void iopf_queue_free(struct iopf_queue *queue)
+{
+	struct iopf_device_param *iopf_param, *next;
+
+	if (!queue)
+		return;
+
+	list_for_each_entry_safe(iopf_param, next, &queue->devices, queue_list)
+		iopf_queue_remove_device(queue, iopf_param->dev);
+
+	destroy_workqueue(queue->wq);
+	kfree(queue);
+}
+EXPORT_SYMBOL_GPL(iopf_queue_free);
-- 
2.31.1



From jean-philippe at linaro.org  Thu Apr  1 16:47:19 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu,  1 Apr 2021 17:47:19 +0200
Subject: [PATCH v14 10/10] iommu/arm-smmu-v3: Add stall support for platform
 devices
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401154718.307519-11-jean-philippe@linaro.org>

The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCIe PRI, but doesn't require devices to have
their own translation cache. Instead, faulting transactions are parked
and the OS is given a chance to fix the page tables and retry the
transaction.

Enable stall for devices that support it (opt-in by firmware). When an
event corresponds to a translation error, call the IOMMU fault handler.
If the fault is recoverable, it will call us back to terminate or
continue the stall.

To use stall device drivers need to enable IOMMU_DEV_FEAT_IOPF, which
initializes the fault queue for the device.

Tested-by: Zhangfei Gao <zhangfei.gao at linaro.org>
Reviewed-by: Eric Auger <eric.auger at redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  43 ++++
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  59 +++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 196 +++++++++++++++++-
 3 files changed, 283 insertions(+), 15 deletions(-)

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 1b463e27bca1..6ce1a7a7e44d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -354,6 +354,13 @@
 #define CMDQ_PRI_1_GRPID		GENMASK_ULL(8, 0)
 #define CMDQ_PRI_1_RESP			GENMASK_ULL(13, 12)
 
+#define CMDQ_RESUME_0_RESP_TERM		0UL
+#define CMDQ_RESUME_0_RESP_RETRY	1UL
+#define CMDQ_RESUME_0_RESP_ABORT	2UL
+#define CMDQ_RESUME_0_RESP		GENMASK_ULL(13, 12)
+#define CMDQ_RESUME_0_SID		GENMASK_ULL(63, 32)
+#define CMDQ_RESUME_1_STAG		GENMASK_ULL(15, 0)
+
 #define CMDQ_SYNC_0_CS			GENMASK_ULL(13, 12)
 #define CMDQ_SYNC_0_CS_NONE		0
 #define CMDQ_SYNC_0_CS_IRQ		1
@@ -370,6 +377,25 @@
 
 #define EVTQ_0_ID			GENMASK_ULL(7, 0)
 
+#define EVT_ID_TRANSLATION_FAULT	0x10
+#define EVT_ID_ADDR_SIZE_FAULT		0x11
+#define EVT_ID_ACCESS_FAULT		0x12
+#define EVT_ID_PERMISSION_FAULT		0x13
+
+#define EVTQ_0_SSV			(1UL << 11)
+#define EVTQ_0_SSID			GENMASK_ULL(31, 12)
+#define EVTQ_0_SID			GENMASK_ULL(63, 32)
+#define EVTQ_1_STAG			GENMASK_ULL(15, 0)
+#define EVTQ_1_STALL			(1UL << 31)
+#define EVTQ_1_PnU			(1UL << 33)
+#define EVTQ_1_InD			(1UL << 34)
+#define EVTQ_1_RnW			(1UL << 35)
+#define EVTQ_1_S2			(1UL << 39)
+#define EVTQ_1_CLASS			GENMASK_ULL(41, 40)
+#define EVTQ_1_TT_READ			(1UL << 44)
+#define EVTQ_2_ADDR			GENMASK_ULL(63, 0)
+#define EVTQ_3_IPA			GENMASK_ULL(51, 12)
+
 /* PRI queue */
 #define PRIQ_ENT_SZ_SHIFT		4
 #define PRIQ_ENT_DWORDS			((1 << PRIQ_ENT_SZ_SHIFT) >> 3)
@@ -464,6 +490,13 @@ struct arm_smmu_cmdq_ent {
 			enum pri_resp		resp;
 		} pri;
 
+		#define CMDQ_OP_RESUME		0x44
+		struct {
+			u32			sid;
+			u16			stag;
+			u8			resp;
+		} resume;
+
 		#define CMDQ_OP_CMD_SYNC	0x46
 		struct {
 			u64			msiaddr;
@@ -522,6 +555,7 @@ struct arm_smmu_cmdq_batch {
 
 struct arm_smmu_evtq {
 	struct arm_smmu_queue		q;
+	struct iopf_queue		*iopf;
 	u32				max_stalls;
 };
 
@@ -659,7 +693,9 @@ struct arm_smmu_master {
 	struct arm_smmu_stream		*streams;
 	unsigned int			num_streams;
 	bool				ats_enabled;
+	bool				stall_enabled;
 	bool				sva_enabled;
+	bool				iopf_enabled;
 	struct list_head		bonds;
 	unsigned int			ssid_bits;
 };
@@ -678,6 +714,7 @@ struct arm_smmu_domain {
 
 	struct io_pgtable_ops		*pgtbl_ops;
 	bool				non_strict;
+	bool				stall_enabled;
 	atomic_t			nr_ats_masters;
 
 	enum arm_smmu_domain_stage	stage;
@@ -719,6 +756,7 @@ bool arm_smmu_master_sva_supported(struct arm_smmu_master *master);
 bool arm_smmu_master_sva_enabled(struct arm_smmu_master *master);
 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);
 struct iommu_sva *arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
 				    void *drvdata);
 void arm_smmu_sva_unbind(struct iommu_sva *handle);
@@ -750,6 +788,11 @@ static inline int arm_smmu_master_disable_sva(struct arm_smmu_master *master)
 	return -ENODEV;
 }
 
+static inline bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
+{
+	return false;
+}
+
 static inline struct iommu_sva *
 arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm, void *drvdata)
 {
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 bb251cab61f3..ee66d1f4cb81 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
@@ -435,9 +435,13 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 	return true;
 }
 
-static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
+bool arm_smmu_master_iopf_supported(struct arm_smmu_master *master)
 {
-	return false;
+	/* We're not keeping track of SIDs in fault events */
+	if (master->num_streams != 1)
+		return false;
+
+	return master->stall_enabled;
 }
 
 bool arm_smmu_master_sva_supported(struct arm_smmu_master *master)
@@ -445,8 +449,8 @@ bool arm_smmu_master_sva_supported(struct arm_smmu_master *master)
 	if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
 		return false;
 
-	/* SSID and IOPF support are mandatory for the moment */
-	return master->ssid_bits && arm_smmu_iopf_supported(master);
+	/* SSID support is mandatory for the moment */
+	return master->ssid_bits;
 }
 
 bool arm_smmu_master_sva_enabled(struct arm_smmu_master *master)
@@ -459,13 +463,55 @@ bool arm_smmu_master_sva_enabled(struct arm_smmu_master *master)
 	return enabled;
 }
 
+static int arm_smmu_master_sva_enable_iopf(struct arm_smmu_master *master)
+{
+	int ret;
+	struct device *dev = master->dev;
+
+	/*
+	 * Drivers for devices supporting PRI or stall should enable IOPF first.
+	 * Others have device-specific fault handlers and don't need IOPF.
+	 */
+	if (!arm_smmu_master_iopf_supported(master))
+		return 0;
+
+	if (!master->iopf_enabled)
+		return -EINVAL;
+
+	ret = iopf_queue_add_device(master->smmu->evtq.iopf, dev);
+	if (ret)
+		return ret;
+
+	ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf, dev);
+	if (ret) {
+		iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
+		return ret;
+	}
+	return 0;
+}
+
+static void arm_smmu_master_sva_disable_iopf(struct arm_smmu_master *master)
+{
+	struct device *dev = master->dev;
+
+	if (!master->iopf_enabled)
+		return;
+
+	iommu_unregister_device_fault_handler(dev);
+	iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
+}
+
 int arm_smmu_master_enable_sva(struct arm_smmu_master *master)
 {
+	int ret;
+
 	mutex_lock(&sva_lock);
-	master->sva_enabled = true;
+	ret = arm_smmu_master_sva_enable_iopf(master);
+	if (!ret)
+		master->sva_enabled = true;
 	mutex_unlock(&sva_lock);
 
-	return 0;
+	return ret;
 }
 
 int arm_smmu_master_disable_sva(struct arm_smmu_master *master)
@@ -476,6 +522,7 @@ int arm_smmu_master_disable_sva(struct arm_smmu_master *master)
 		mutex_unlock(&sva_lock);
 		return -EBUSY;
 	}
+	arm_smmu_master_sva_disable_iopf(master);
 	master->sva_enabled = false;
 	mutex_unlock(&sva_lock);
 
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 8279291660b2..85e103bf021d 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -32,6 +32,7 @@
 #include <linux/amba/bus.h>
 
 #include "arm-smmu-v3.h"
+#include "../../iommu-sva-lib.h"
 
 static bool disable_bypass = true;
 module_param(disable_bypass, bool, 0444);
@@ -315,6 +316,11 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent)
 		}
 		cmd[1] |= FIELD_PREP(CMDQ_PRI_1_RESP, ent->pri.resp);
 		break;
+	case CMDQ_OP_RESUME:
+		cmd[0] |= FIELD_PREP(CMDQ_RESUME_0_SID, ent->resume.sid);
+		cmd[0] |= FIELD_PREP(CMDQ_RESUME_0_RESP, ent->resume.resp);
+		cmd[1] |= FIELD_PREP(CMDQ_RESUME_1_STAG, ent->resume.stag);
+		break;
 	case CMDQ_OP_CMD_SYNC:
 		if (ent->sync.msiaddr) {
 			cmd[0] |= FIELD_PREP(CMDQ_SYNC_0_CS, CMDQ_SYNC_0_CS_IRQ);
@@ -878,6 +884,44 @@ static int arm_smmu_cmdq_batch_submit(struct arm_smmu_device *smmu,
 	return arm_smmu_cmdq_issue_cmdlist(smmu, cmds->cmds, cmds->num, true);
 }
 
+static int arm_smmu_page_response(struct device *dev,
+				  struct iommu_fault_event *unused,
+				  struct iommu_page_response *resp)
+{
+	struct arm_smmu_cmdq_ent cmd = {0};
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	int sid = master->streams[0].id;
+
+	if (master->stall_enabled) {
+		cmd.opcode		= CMDQ_OP_RESUME;
+		cmd.resume.sid		= sid;
+		cmd.resume.stag		= resp->grpid;
+		switch (resp->code) {
+		case IOMMU_PAGE_RESP_INVALID:
+		case IOMMU_PAGE_RESP_FAILURE:
+			cmd.resume.resp = CMDQ_RESUME_0_RESP_ABORT;
+			break;
+		case IOMMU_PAGE_RESP_SUCCESS:
+			cmd.resume.resp = CMDQ_RESUME_0_RESP_RETRY;
+			break;
+		default:
+			return -EINVAL;
+		}
+	} else {
+		return -ENODEV;
+	}
+
+	arm_smmu_cmdq_issue_cmd(master->smmu, &cmd);
+	/*
+	 * Don't send a SYNC, it doesn't do anything for RESUME or PRI_RESP.
+	 * RESUME consumption guarantees that the stalled transaction will be
+	 * terminated... at some point in the future. PRI_RESP is fire and
+	 * forget.
+	 */
+
+	return 0;
+}
+
 /* Context descriptor manipulation functions */
 void arm_smmu_tlb_inv_asid(struct arm_smmu_device *smmu, u16 asid)
 {
@@ -988,7 +1032,6 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain, int ssid,
 	u64 val;
 	bool cd_live;
 	__le64 *cdptr;
-	struct arm_smmu_device *smmu = smmu_domain->smmu;
 
 	if (WARN_ON(ssid >= (1 << smmu_domain->s1_cfg.s1cdmax)))
 		return -E2BIG;
@@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain, int ssid,
 			FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) |
 			CTXDESC_CD_0_V;
 
-		/* STALL_MODEL==0b10 && CD.S==0 is ILLEGAL */
-		if (smmu->features & ARM_SMMU_FEAT_STALL_FORCE)
+		if (smmu_domain->stall_enabled)
 			val |= CTXDESC_CD_0_S;
 	}
 
@@ -1278,7 +1320,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 			 FIELD_PREP(STRTAB_STE_1_STRW, strw));
 
 		if (smmu->features & ARM_SMMU_FEAT_STALLS &&
-		   !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE))
+		    !master->stall_enabled)
 			dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
 		val |= (s1_cfg->cdcfg.cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
@@ -1355,7 +1397,6 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
 	return 0;
 }
 
-__maybe_unused
 static struct arm_smmu_master *
 arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
 {
@@ -1379,9 +1420,103 @@ arm_smmu_find_master(struct arm_smmu_device *smmu, u32 sid)
 }
 
 /* IRQ and event handlers */
+static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
+{
+	int ret;
+	u32 reason;
+	u32 perm = 0;
+	struct arm_smmu_master *master;
+	bool ssid_valid = evt[0] & EVTQ_0_SSV;
+	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
+	struct iommu_fault_event fault_evt = { };
+	struct iommu_fault *flt = &fault_evt.fault;
+
+	switch (FIELD_GET(EVTQ_0_ID, evt[0])) {
+	case EVT_ID_TRANSLATION_FAULT:
+		reason = IOMMU_FAULT_REASON_PTE_FETCH;
+		break;
+	case EVT_ID_ADDR_SIZE_FAULT:
+		reason = IOMMU_FAULT_REASON_OOR_ADDRESS;
+		break;
+	case EVT_ID_ACCESS_FAULT:
+		reason = IOMMU_FAULT_REASON_ACCESS;
+		break;
+	case EVT_ID_PERMISSION_FAULT:
+		reason = IOMMU_FAULT_REASON_PERMISSION;
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	/* Stage-2 is always pinned at the moment */
+	if (evt[1] & EVTQ_1_S2)
+		return -EFAULT;
+
+	if (evt[1] & EVTQ_1_RnW)
+		perm |= IOMMU_FAULT_PERM_READ;
+	else
+		perm |= IOMMU_FAULT_PERM_WRITE;
+
+	if (evt[1] & EVTQ_1_InD)
+		perm |= IOMMU_FAULT_PERM_EXEC;
+
+	if (evt[1] & EVTQ_1_PnU)
+		perm |= IOMMU_FAULT_PERM_PRIV;
+
+	if (evt[1] & EVTQ_1_STALL) {
+		flt->type = IOMMU_FAULT_PAGE_REQ;
+		flt->prm = (struct iommu_fault_page_request) {
+			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
+			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
+			.perm = perm,
+			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
+		};
+
+		if (ssid_valid) {
+			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
+			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
+		}
+	} else {
+		flt->type = IOMMU_FAULT_DMA_UNRECOV;
+		flt->event = (struct iommu_fault_unrecoverable) {
+			.reason = reason,
+			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID,
+			.perm = perm,
+			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
+		};
+
+		if (ssid_valid) {
+			flt->event.flags |= IOMMU_FAULT_UNRECOV_PASID_VALID;
+			flt->event.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
+		}
+	}
+
+	mutex_lock(&smmu->streams_mutex);
+	master = arm_smmu_find_master(smmu, sid);
+	if (!master) {
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	ret = iommu_report_device_fault(master->dev, &fault_evt);
+	if (ret && flt->type == IOMMU_FAULT_PAGE_REQ) {
+		/* Nobody cared, abort the access */
+		struct iommu_page_response resp = {
+			.pasid		= flt->prm.pasid,
+			.grpid		= flt->prm.grpid,
+			.code		= IOMMU_PAGE_RESP_FAILURE,
+		};
+		arm_smmu_page_response(master->dev, &fault_evt, &resp);
+	}
+
+out_unlock:
+	mutex_unlock(&smmu->streams_mutex);
+	return ret;
+}
+
 static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
 {
-	int i;
+	int i, ret;
 	struct arm_smmu_device *smmu = dev;
 	struct arm_smmu_queue *q = &smmu->evtq.q;
 	struct arm_smmu_ll_queue *llq = &q->llq;
@@ -1391,6 +1526,10 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
 		while (!queue_remove_raw(q, evt)) {
 			u8 id = FIELD_GET(EVTQ_0_ID, evt[0]);
 
+			ret = arm_smmu_handle_evt(smmu, evt);
+			if (!ret)
+				continue;
+
 			dev_info(smmu->dev, "event 0x%02x received:\n", id);
 			for (i = 0; i < ARRAY_SIZE(evt); ++i)
 				dev_info(smmu->dev, "\t0x%016llx\n",
@@ -1925,6 +2064,8 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
 
 	cfg->s1cdmax = master->ssid_bits;
 
+	smmu_domain->stall_enabled = master->stall_enabled;
+
 	ret = arm_smmu_alloc_cd_tables(smmu_domain);
 	if (ret)
 		goto out_free_asid;
@@ -2272,6 +2413,12 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
 			smmu_domain->s1_cfg.s1cdmax, master->ssid_bits);
 		ret = -EINVAL;
 		goto out_unlock;
+	} else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
+		   smmu_domain->stall_enabled != master->stall_enabled) {
+		dev_err(dev, "cannot attach to stall-%s domain\n",
+			smmu_domain->stall_enabled ? "enabled" : "disabled");
+		ret = -EINVAL;
+		goto out_unlock;
 	}
 
 	master->domain = smmu_domain;
@@ -2510,6 +2657,11 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 		master->ssid_bits = min_t(u8, master->ssid_bits,
 					  CTXDESC_LINEAR_CDMAX);
 
+	if ((smmu->features & ARM_SMMU_FEAT_STALLS &&
+	     device_property_read_bool(dev, "dma-can-stall")) ||
+	    smmu->features & ARM_SMMU_FEAT_STALL_FORCE)
+		master->stall_enabled = true;
+
 	return &smmu->iommu;
 
 err_free_master:
@@ -2527,7 +2679,8 @@ static void arm_smmu_release_device(struct device *dev)
 		return;
 
 	master = dev_iommu_priv_get(dev);
-	WARN_ON(arm_smmu_master_sva_enabled(master));
+	if (WARN_ON(arm_smmu_master_sva_enabled(master)))
+		iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
 	arm_smmu_detach_dev(master);
 	arm_smmu_disable_pasid(master);
 	arm_smmu_remove_master(master);
@@ -2655,6 +2808,8 @@ static bool arm_smmu_dev_has_feature(struct device *dev,
 		return false;
 
 	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return arm_smmu_master_iopf_supported(master);
 	case IOMMU_DEV_FEAT_SVA:
 		return arm_smmu_master_sva_supported(master);
 	default:
@@ -2671,6 +2826,8 @@ static bool arm_smmu_dev_feature_enabled(struct device *dev,
 		return false;
 
 	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return master->iopf_enabled;
 	case IOMMU_DEV_FEAT_SVA:
 		return arm_smmu_master_sva_enabled(master);
 	default:
@@ -2681,6 +2838,8 @@ static bool arm_smmu_dev_feature_enabled(struct device *dev,
 static int arm_smmu_dev_enable_feature(struct device *dev,
 				       enum iommu_dev_features feat)
 {
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+
 	if (!arm_smmu_dev_has_feature(dev, feat))
 		return -ENODEV;
 
@@ -2688,8 +2847,11 @@ static int arm_smmu_dev_enable_feature(struct device *dev,
 		return -EBUSY;
 
 	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		master->iopf_enabled = true;
+		return 0;
 	case IOMMU_DEV_FEAT_SVA:
-		return arm_smmu_master_enable_sva(dev_iommu_priv_get(dev));
+		return arm_smmu_master_enable_sva(master);
 	default:
 		return -EINVAL;
 	}
@@ -2698,12 +2860,19 @@ static int arm_smmu_dev_enable_feature(struct device *dev,
 static int arm_smmu_dev_disable_feature(struct device *dev,
 					enum iommu_dev_features feat)
 {
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+
 	if (!arm_smmu_dev_feature_enabled(dev, feat))
 		return -EINVAL;
 
 	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		if (master->sva_enabled)
+			return -EBUSY;
+		master->iopf_enabled = false;
+		return 0;
 	case IOMMU_DEV_FEAT_SVA:
-		return arm_smmu_master_disable_sva(dev_iommu_priv_get(dev));
+		return arm_smmu_master_disable_sva(master);
 	default:
 		return -EINVAL;
 	}
@@ -2734,6 +2903,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.sva_bind		= arm_smmu_sva_bind,
 	.sva_unbind		= arm_smmu_sva_unbind,
 	.sva_get_pasid		= arm_smmu_sva_get_pasid,
+	.page_response		= arm_smmu_page_response,
 	.pgsize_bitmap		= -1UL, /* Restricted during device attach */
 };
 
@@ -2831,6 +3001,13 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
 	if (ret)
 		return ret;
 
+	if ((smmu->features & ARM_SMMU_FEAT_SVA) &&
+	    (smmu->features & ARM_SMMU_FEAT_STALLS)) {
+		smmu->evtq.iopf = iopf_queue_alloc(dev_name(smmu->dev));
+		if (!smmu->evtq.iopf)
+			return -ENOMEM;
+	}
+
 	/* priq */
 	if (!(smmu->features & ARM_SMMU_FEAT_PRI))
 		return 0;
@@ -3746,6 +3923,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 	iommu_device_unregister(&smmu->iommu);
 	iommu_device_sysfs_remove(&smmu->iommu);
 	arm_smmu_device_disable(smmu);
+	iopf_queue_free(smmu->evtq.iopf);
 
 	return 0;
 }
-- 
2.31.1



From mikelley at microsoft.com  Thu Apr  1 16:50:06 2021
From: mikelley at microsoft.com (Michael Kelley)
Date: Thu, 1 Apr 2021 15:50:06 +0000
Subject: [PATCH v5 2/7] arm64: smccc: Add support for SMCCCv1.2
 input/output registers
In-Reply-To: <20210326125124.yl234hz5ipr6yn2d@bogus>
References: <20210325143255.1532452-1-sudeep.holla@arm.com>
 <20210325143255.1532452-3-sudeep.holla@arm.com>
 <20210325144113.GB41100@C02TD0UTHF1T.local>
 <20210326121833.GA56294@C02TD0UTHF1T.local>
 <20210326125124.yl234hz5ipr6yn2d@bogus>
Message-ID: <MWHPR21MB15939FCE24BDF74B06616560D77B9@MWHPR21MB1593.namprd21.prod.outlook.com>

From: Sudeep Holla <sudeep.holla at arm.com> Sent: Friday, March 26, 2021 5:51 AM
> 
> On Fri, Mar 26, 2021 at 12:18:50PM +0000, Mark Rutland wrote:
> > On Thu, Mar 25, 2021 at 02:41:13PM +0000, Mark Rutland wrote:
> > > Hi Sudeep,
> > >
> > > On Thu, Mar 25, 2021 at 02:32:50PM +0000, Sudeep Holla wrote:
> > > > SMCCC v1.2 allows x8-x17 to be used as parameter registers and x4?x17
> > > > to be used as result registers in SMC64/HVC64. Arm Firmware Framework
> > > > for Armv8-A specification makes use of x0-x7 as parameter and result
> > > > registers.
> > > >
> > > > Current SMCCC interface in the kernel just use x0-x7 as parameter and
> > > > x0-x3 as result registers. Let us add new interface to support x0-x7
> > > > as parameter and result registers. This can be extended to include
> > > > x8-x17 when there are users for the same.
> > >
> > > Michael Kelley is also looking at using SMCCCv1.2, and on his HyperV
> > > thread I'd suggested we should deal with the whole set of SMCCCv1.2
> > > registers now to avoid future churn in this area (using struct both for
> > > the arguments and return values).
> > >
> > > How painful would it be to extend this patch to do that?
> >
> > I *think* the major change with this would be making the interfaces:
> >
> > void arm_smccc_1_2_{hvc,smc}(struct arm_smccc_1_2_args *args,
> > 			     struct arm_smccc_1_2_res *res);
> >
> > ... and callers manipulating the structs directly, with arm64 having
> > more fields, e.g.
> >
> > // arm64
> > struct arm_smccc_1_2_args {
> > 	unsigned long a1;
> > 	...
> > 	unsigned long a17;
> > }
> >
> > struct arm_smccc_1_2_res {
> > 	unsigned long a0;
> > 	...
> > 	unsigned long a17;
> > }
> >
> > // arm
> > struct arm_smccc_1_2_args {
> > 	unsigned long a1;
> > 	...
> > 	unsigned long a7;
> > }
> >
> > struct arm_smccc_1_2_res {
> > 	unsigned long a0;
> > 	...
> > 	unsigned long a7;
> > }
> >
> > I think that can be hidden in the FF-A wrappers, so that doesn't need to
> > be what FF-A drivers see. Does that sound plausible, or is that painful?
> >
> 
> Sounds possible, will give it a try.
> 
> > > > +  DEFINE(ARM_SMCCC_V1_2_RES_X0_OFFS,	offsetof(struct
> arm_smccc_v1_2_res, a0));
> >
> > As a general nit, for consistency with the existing arm_smccc_1_1 code,
> > could we please drop the 'V' in these names, and use `ARM_SMCCC_1_2` or
> > `arm_smccc_1_2` ?
> >
> 
> Sure, makes sense.
> 
> > FWIW, other than the above comments, this all looks good to me
> >
> 
> Thanks.
> 
> --
> Regards,
> Sudeep

Sudeep -- let me know when you have a new version available.  I can
test it for use with Hyper-V.

Michael


From hch at lst.de  Thu Apr  1 16:52:39 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:39 +0200
Subject: [PATCH 03/20] iommu/fsl_pamu: remove support for setting
 DOMAIN_ATTR_GEOMETRY
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-4-hch@lst.de>

The default geometry is the same as the one set by qman_port given
that FSL_PAMU depends on having 64-bit physical and thus DMA addresses.

Remove the support to update the geometry and remove the now pointless
geom_size field.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c     | 55 +++--------------------------
 drivers/iommu/fsl_pamu_domain.h     |  6 ----
 drivers/soc/fsl/qbman/qman_portal.c | 12 -------
 3 files changed, 5 insertions(+), 68 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index e587ec43f7e750..7bd08ddad07779 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -62,7 +62,7 @@ static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, dma_addr_t i
 
 	geom = &dma_domain->iommu_domain.geometry;
 
-	if (!win_cnt || !dma_domain->geom_size) {
+	if (!win_cnt) {
 		pr_debug("Number of windows/geometry not configured for the domain\n");
 		return 0;
 	}
@@ -72,7 +72,7 @@ static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, dma_addr_t i
 		dma_addr_t subwin_iova;
 		u32 wnd;
 
-		subwin_size = dma_domain->geom_size >> ilog2(win_cnt);
+		subwin_size = (geom->aperture_end + 1) >> ilog2(win_cnt);
 		subwin_iova = iova & ~(subwin_size - 1);
 		wnd = (subwin_iova - geom->aperture_start) >> ilog2(subwin_size);
 		win_ptr = &dma_domain->win_arr[wnd];
@@ -234,7 +234,7 @@ static int pamu_set_liodn(int liodn, struct device *dev,
 	get_ome_index(&omi_index, dev);
 
 	window_addr = geom_attr->aperture_start;
-	window_size = dma_domain->geom_size;
+	window_size = geom_attr->aperture_end + 1;
 
 	spin_lock_irqsave(&iommu_lock, flags);
 	ret = pamu_disable_liodn(liodn);
@@ -303,7 +303,6 @@ static struct fsl_dma_domain *iommu_alloc_dma_domain(void)
 	domain->stash_id = ~(u32)0;
 	domain->snoop_id = ~(u32)0;
 	domain->win_cnt = pamu_get_max_subwin_cnt();
-	domain->geom_size = 0;
 
 	INIT_LIST_HEAD(&domain->devices);
 
@@ -502,7 +501,8 @@ static int fsl_pamu_window_enable(struct iommu_domain *domain, u32 wnd_nr,
 		return -EINVAL;
 	}
 
-	win_size = dma_domain->geom_size >> ilog2(dma_domain->win_cnt);
+	win_size = (domain->geometry.aperture_end + 1) >>
+			ilog2(dma_domain->win_cnt);
 	if (size > win_size) {
 		pr_debug("Invalid window size\n");
 		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
@@ -665,41 +665,6 @@ static void fsl_pamu_detach_device(struct iommu_domain *domain,
 		pr_debug("missing fsl,liodn property at %pOF\n", dev->of_node);
 }
 
-static  int configure_domain_geometry(struct iommu_domain *domain, void *data)
-{
-	struct iommu_domain_geometry *geom_attr = data;
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	dma_addr_t geom_size;
-	unsigned long flags;
-
-	geom_size = geom_attr->aperture_end - geom_attr->aperture_start + 1;
-	/*
-	 * Sanity check the geometry size. Also, we do not support
-	 * DMA outside of the geometry.
-	 */
-	if (check_size(geom_size, geom_attr->aperture_start) ||
-	    !geom_attr->force_aperture) {
-		pr_debug("Invalid PAMU geometry attributes\n");
-		return -EINVAL;
-	}
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	if (dma_domain->enabled) {
-		pr_debug("Can't set geometry attributes as domain is active\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return  -EBUSY;
-	}
-
-	/* Copy the domain geometry information */
-	memcpy(&domain->geometry, geom_attr,
-	       sizeof(struct iommu_domain_geometry));
-	dma_domain->geom_size = geom_size;
-
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-
-	return 0;
-}
-
 /* Set the domain stash attribute */
 static int configure_domain_stash(struct fsl_dma_domain *dma_domain, void *data)
 {
@@ -769,13 +734,6 @@ static int fsl_pamu_set_windows(struct iommu_domain *domain, u32 w_count)
 		return  -EBUSY;
 	}
 
-	/* Ensure that the geometry has been set for the domain */
-	if (!dma_domain->geom_size) {
-		pr_debug("Please configure geometry before setting the number of windows\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EINVAL;
-	}
-
 	/*
 	 * Ensure we have valid window count i.e. it should be less than
 	 * maximum permissible limit and should be a power of two.
@@ -811,9 +769,6 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
 	int ret = 0;
 
 	switch (attr_type) {
-	case DOMAIN_ATTR_GEOMETRY:
-		ret = configure_domain_geometry(domain, data);
-		break;
 	case DOMAIN_ATTR_FSL_PAMU_STASH:
 		ret = configure_domain_stash(dma_domain, data);
 		break;
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index 2865d42782e802..53d359d66fe577 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -17,12 +17,6 @@ struct dma_window {
 };
 
 struct fsl_dma_domain {
-	/*
-	 * Indicates the geometry size for the domain.
-	 * This would be set when the geometry is
-	 * configured for the domain.
-	 */
-	dma_addr_t			geom_size;
 	/*
 	 * Number of windows assocaited with this domain.
 	 * During domain initialization, it is set to the
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index 5685b67068931a..c958e6310d3094 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -47,7 +47,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 #ifdef CONFIG_FSL_PAMU
 	struct device *dev = pcfg->dev;
 	int window_count = 1;
-	struct iommu_domain_geometry geom_attr;
 	struct pamu_stash_attribute stash_attr;
 	int ret;
 
@@ -56,17 +55,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 		dev_err(dev, "%s(): iommu_domain_alloc() failed", __func__);
 		goto no_iommu;
 	}
-	geom_attr.aperture_start = 0;
-	geom_attr.aperture_end =
-		((dma_addr_t)1 << min(8 * sizeof(dma_addr_t), (size_t)36)) - 1;
-	geom_attr.force_aperture = true;
-	ret = iommu_domain_set_attr(pcfg->iommu_domain, DOMAIN_ATTR_GEOMETRY,
-				    &geom_attr);
-	if (ret < 0) {
-		dev_err(dev, "%s(): iommu_domain_set_attr() = %d", __func__,
-			ret);
-		goto out_domain_free;
-	}
 	ret = iommu_domain_set_attr(pcfg->iommu_domain, DOMAIN_ATTR_WINDOWS,
 				    &window_count);
 	if (ret < 0) {
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:37 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:37 +0200
Subject: [PATCH 01/20] iommu: remove the unused domain_window_disable method
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-2-hch@lst.de>

domain_window_disable is wired up by fsl_pamu, but never actually called.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 48 ---------------------------------
 include/linux/iommu.h           |  2 --
 2 files changed, 50 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index b2110767caf49c..53380cf1fa452f 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -473,53 +473,6 @@ static int update_domain_mapping(struct fsl_dma_domain *dma_domain, u32 wnd_nr)
 	return ret;
 }
 
-static int disable_domain_win(struct fsl_dma_domain *dma_domain, u32 wnd_nr)
-{
-	struct device_domain_info *info;
-	int ret = 0;
-
-	list_for_each_entry(info, &dma_domain->devices, link) {
-		if (dma_domain->win_cnt == 1 && dma_domain->enabled) {
-			ret = pamu_disable_liodn(info->liodn);
-			if (!ret)
-				dma_domain->enabled = 0;
-		} else {
-			ret = pamu_disable_spaace(info->liodn, wnd_nr);
-		}
-	}
-
-	return ret;
-}
-
-static void fsl_pamu_window_disable(struct iommu_domain *domain, u32 wnd_nr)
-{
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	unsigned long flags;
-	int ret;
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	if (!dma_domain->win_arr) {
-		pr_debug("Number of windows not configured\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return;
-	}
-
-	if (wnd_nr >= dma_domain->win_cnt) {
-		pr_debug("Invalid window index\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return;
-	}
-
-	if (dma_domain->win_arr[wnd_nr].valid) {
-		ret = disable_domain_win(dma_domain, wnd_nr);
-		if (!ret) {
-			dma_domain->win_arr[wnd_nr].valid = 0;
-			dma_domain->mapped--;
-		}
-	}
-
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-}
 
 static int fsl_pamu_window_enable(struct iommu_domain *domain, u32 wnd_nr,
 				  phys_addr_t paddr, u64 size, int prot)
@@ -1032,7 +985,6 @@ static const struct iommu_ops fsl_pamu_ops = {
 	.attach_dev	= fsl_pamu_attach_device,
 	.detach_dev	= fsl_pamu_detach_device,
 	.domain_window_enable = fsl_pamu_window_enable,
-	.domain_window_disable = fsl_pamu_window_disable,
 	.iova_to_phys	= fsl_pamu_iova_to_phys,
 	.domain_set_attr = fsl_pamu_set_domain_attr,
 	.domain_get_attr = fsl_pamu_get_domain_attr,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 5e7fe519430af4..47c8b318d8f523 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -209,7 +209,6 @@ struct iommu_iotlb_gather {
  * @put_resv_regions: Free list of reserved regions for a device
  * @apply_resv_region: Temporary helper call-back for iova reserved ranges
  * @domain_window_enable: Configure and enable a particular window for a domain
- * @domain_window_disable: Disable a particular window for a domain
  * @of_xlate: add OF master IDs to iommu grouping
  * @is_attach_deferred: Check if domain attach should be deferred from iommu
  *                      driver init to device driver init (default no)
@@ -270,7 +269,6 @@ struct iommu_ops {
 	/* Window handling functions */
 	int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
 				    phys_addr_t paddr, u64 size, int prot);
-	void (*domain_window_disable)(struct iommu_domain *domain, u32 wnd_nr);
 
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
 	bool (*is_attach_deferred)(struct iommu_domain *domain, struct device *dev);
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:41 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:41 +0200
Subject: [PATCH 05/20] iommu/fsl_pamu: remove support for multiple windows
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-6-hch@lst.de>

The only domains allocated forces use of a single window.  Remove all
the code related to multiple window support, as well as the need for
qman_portal to force a single window.

Remove the now unused DOMAIN_ATTR_WINDOWS iommu_attr.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu.c            | 264 +-------------------------
 drivers/iommu/fsl_pamu.h            |  10 +-
 drivers/iommu/fsl_pamu_domain.c     | 275 +++++-----------------------
 drivers/iommu/fsl_pamu_domain.h     |  16 +-
 drivers/soc/fsl/qbman/qman_portal.c |   7 -
 include/linux/iommu.h               |   1 -
 6 files changed, 60 insertions(+), 513 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index b9a974d9783113..3e1647cd5ad47a 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -63,19 +63,6 @@ static const struct of_device_id l3_device_ids[] = {
 /* maximum subwindows permitted per liodn */
 static u32 max_subwindow_count;
 
-/* Pool for fspi allocation */
-static struct gen_pool *spaace_pool;
-
-/**
- * pamu_get_max_subwin_cnt() - Return the maximum supported
- * subwindow count per liodn.
- *
- */
-u32 pamu_get_max_subwin_cnt(void)
-{
-	return max_subwindow_count;
-}
-
 /**
  * pamu_get_ppaace() - Return the primary PACCE
  * @liodn: liodn PAACT index for desired PAACE
@@ -155,13 +142,6 @@ static unsigned int map_addrspace_size_to_wse(phys_addr_t addrspace_size)
 	return fls64(addrspace_size) - 2;
 }
 
-/* Derive the PAACE window count encoding for the subwindow count */
-static unsigned int map_subwindow_cnt_to_wce(u32 subwindow_cnt)
-{
-	/* window count is 2^(WCE+1) bytes */
-	return __ffs(subwindow_cnt) - 1;
-}
-
 /*
  * Set the PAACE type as primary and set the coherency required domain
  * attribute
@@ -174,89 +154,11 @@ static void pamu_init_ppaace(struct paace *ppaace)
 	       PAACE_M_COHERENCE_REQ);
 }
 
-/*
- * Set the PAACE type as secondary and set the coherency required domain
- * attribute.
- */
-static void pamu_init_spaace(struct paace *spaace)
-{
-	set_bf(spaace->addr_bitfields, PAACE_AF_PT, PAACE_PT_SECONDARY);
-	set_bf(spaace->domain_attr.to_host.coherency_required, PAACE_DA_HOST_CR,
-	       PAACE_M_COHERENCE_REQ);
-}
-
-/*
- * Return the spaace (corresponding to the secondary window index)
- * for a particular ppaace.
- */
-static struct paace *pamu_get_spaace(struct paace *paace, u32 wnum)
-{
-	u32 subwin_cnt;
-	struct paace *spaace = NULL;
-
-	subwin_cnt = 1UL << (get_bf(paace->impl_attr, PAACE_IA_WCE) + 1);
-
-	if (wnum < subwin_cnt)
-		spaace = &spaact[paace->fspi + wnum];
-	else
-		pr_debug("secondary paace out of bounds\n");
-
-	return spaace;
-}
-
-/**
- * pamu_get_fspi_and_allocate() - Allocates fspi index and reserves subwindows
- *                                required for primary PAACE in the secondary
- *                                PAACE table.
- * @subwin_cnt: Number of subwindows to be reserved.
- *
- * A PPAACE entry may have a number of associated subwindows. A subwindow
- * corresponds to a SPAACE entry in the SPAACT table. Each PAACE entry stores
- * the index (fspi) of the first SPAACE entry in the SPAACT table. This
- * function returns the index of the first SPAACE entry. The remaining
- * SPAACE entries are reserved contiguously from that index.
- *
- * Returns a valid fspi index in the range of 0 - SPAACE_NUMBER_ENTRIES on success.
- * If no SPAACE entry is available or the allocator can not reserve the required
- * number of contiguous entries function returns ULONG_MAX indicating a failure.
- *
- */
-static unsigned long pamu_get_fspi_and_allocate(u32 subwin_cnt)
-{
-	unsigned long spaace_addr;
-
-	spaace_addr = gen_pool_alloc(spaace_pool, subwin_cnt * sizeof(struct paace));
-	if (!spaace_addr)
-		return ULONG_MAX;
-
-	return (spaace_addr - (unsigned long)spaact) / (sizeof(struct paace));
-}
-
-/* Release the subwindows reserved for a particular LIODN */
-void pamu_free_subwins(int liodn)
-{
-	struct paace *ppaace;
-	u32 subwin_cnt, size;
-
-	ppaace = pamu_get_ppaace(liodn);
-	if (!ppaace) {
-		pr_debug("Invalid liodn entry\n");
-		return;
-	}
-
-	if (get_bf(ppaace->addr_bitfields, PPAACE_AF_MW)) {
-		subwin_cnt = 1UL << (get_bf(ppaace->impl_attr, PAACE_IA_WCE) + 1);
-		size = (subwin_cnt - 1) * sizeof(struct paace);
-		gen_pool_free(spaace_pool, (unsigned long)&spaact[ppaace->fspi], size);
-		set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
-	}
-}
-
 /*
  * Function used for updating stash destination for the coressponding
  * LIODN.
  */
-int  pamu_update_paace_stash(int liodn, u32 subwin, u32 value)
+int pamu_update_paace_stash(int liodn, u32 value)
 {
 	struct paace *paace;
 
@@ -265,11 +167,6 @@ int  pamu_update_paace_stash(int liodn, u32 subwin, u32 value)
 		pr_debug("Invalid liodn entry\n");
 		return -ENOENT;
 	}
-	if (subwin) {
-		paace = pamu_get_spaace(paace, subwin - 1);
-		if (!paace)
-			return -ENOENT;
-	}
 	set_bf(paace->impl_attr, PAACE_IA_CID, value);
 
 	mb();
@@ -277,31 +174,6 @@ int  pamu_update_paace_stash(int liodn, u32 subwin, u32 value)
 	return 0;
 }
 
-/* Disable a subwindow corresponding to the LIODN */
-int pamu_disable_spaace(int liodn, u32 subwin)
-{
-	struct paace *paace;
-
-	paace = pamu_get_ppaace(liodn);
-	if (!paace) {
-		pr_debug("Invalid liodn entry\n");
-		return -ENOENT;
-	}
-	if (subwin) {
-		paace = pamu_get_spaace(paace, subwin - 1);
-		if (!paace)
-			return -ENOENT;
-		set_bf(paace->addr_bitfields, PAACE_AF_V, PAACE_V_INVALID);
-	} else {
-		set_bf(paace->addr_bitfields, PAACE_AF_AP,
-		       PAACE_AP_PERMS_DENIED);
-	}
-
-	mb();
-
-	return 0;
-}
-
 /**
  * pamu_config_paace() - Sets up PPAACE entry for specified liodn
  *
@@ -314,17 +186,15 @@ int pamu_disable_spaace(int liodn, u32 subwin)
  *	     stashid not defined
  * @snoopid: snoop id for hardware coherency -- if ~snoopid == 0 then
  *	     snoopid not defined
- * @subwin_cnt: number of sub-windows
  * @prot: window permissions
  *
  * Returns 0 upon success else error code < 0 returned
  */
 int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
 		       u32 omi, unsigned long rpn, u32 snoopid, u32 stashid,
-		       u32 subwin_cnt, int prot)
+		       int prot)
 {
 	struct paace *ppaace;
-	unsigned long fspi;
 
 	if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE) {
 		pr_debug("window size too small or not a power of two %pa\n",
@@ -368,116 +238,12 @@ int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
 	if (~snoopid != 0)
 		ppaace->domain_attr.to_host.snpid = snoopid;
 
-	if (subwin_cnt) {
-		/* The first entry is in the primary PAACE instead */
-		fspi = pamu_get_fspi_and_allocate(subwin_cnt - 1);
-		if (fspi == ULONG_MAX) {
-			pr_debug("spaace indexes exhausted\n");
-			return -EINVAL;
-		}
-
-		/* window count is 2^(WCE+1) bytes */
-		set_bf(ppaace->impl_attr, PAACE_IA_WCE,
-		       map_subwindow_cnt_to_wce(subwin_cnt));
-		set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0x1);
-		ppaace->fspi = fspi;
-	} else {
-		set_bf(ppaace->impl_attr, PAACE_IA_ATM, PAACE_ATM_WINDOW_XLATE);
-		ppaace->twbah = rpn >> 20;
-		set_bf(ppaace->win_bitfields, PAACE_WIN_TWBAL, rpn);
-		set_bf(ppaace->addr_bitfields, PAACE_AF_AP, prot);
-		set_bf(ppaace->impl_attr, PAACE_IA_WCE, 0);
-		set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
-	}
-	mb();
-
-	return 0;
-}
-
-/**
- * pamu_config_spaace() - Sets up SPAACE entry for specified subwindow
- *
- * @liodn:  Logical IO device number
- * @subwin_cnt:  number of sub-windows associated with dma-window
- * @subwin: subwindow index
- * @subwin_size: size of subwindow
- * @omi: Operation mapping index
- * @rpn: real (true physical) page number
- * @snoopid: snoop id for hardware coherency -- if ~snoopid == 0 then
- *			  snoopid not defined
- * @stashid: cache stash id for associated cpu
- * @enable: enable/disable subwindow after reconfiguration
- * @prot: sub window permissions
- *
- * Returns 0 upon success else error code < 0 returned
- */
-int pamu_config_spaace(int liodn, u32 subwin_cnt, u32 subwin,
-		       phys_addr_t subwin_size, u32 omi, unsigned long rpn,
-		       u32 snoopid, u32 stashid, int enable, int prot)
-{
-	struct paace *paace;
-
-	/* setup sub-windows */
-	if (!subwin_cnt) {
-		pr_debug("Invalid subwindow count\n");
-		return -EINVAL;
-	}
-
-	paace = pamu_get_ppaace(liodn);
-	if (subwin > 0 && subwin < subwin_cnt && paace) {
-		paace = pamu_get_spaace(paace, subwin - 1);
-
-		if (paace && !(paace->addr_bitfields & PAACE_V_VALID)) {
-			pamu_init_spaace(paace);
-			set_bf(paace->addr_bitfields, SPAACE_AF_LIODN, liodn);
-		}
-	}
-
-	if (!paace) {
-		pr_debug("Invalid liodn entry\n");
-		return -ENOENT;
-	}
-
-	if ((subwin_size & (subwin_size - 1)) || subwin_size < PAMU_PAGE_SIZE) {
-		pr_debug("subwindow size out of range, or not a power of 2\n");
-		return -EINVAL;
-	}
-
-	if (rpn == ULONG_MAX) {
-		pr_debug("real page number out of range\n");
-		return -EINVAL;
-	}
-
-	/* window size is 2^(WSE+1) bytes */
-	set_bf(paace->win_bitfields, PAACE_WIN_SWSE,
-	       map_addrspace_size_to_wse(subwin_size));
-
-	set_bf(paace->impl_attr, PAACE_IA_ATM, PAACE_ATM_WINDOW_XLATE);
-	paace->twbah = rpn >> 20;
-	set_bf(paace->win_bitfields, PAACE_WIN_TWBAL, rpn);
-	set_bf(paace->addr_bitfields, PAACE_AF_AP, prot);
-
-	/* configure snoop id */
-	if (~snoopid != 0)
-		paace->domain_attr.to_host.snpid = snoopid;
-
-	/* set up operation mapping if it's configured */
-	if (omi < OME_NUMBER_ENTRIES) {
-		set_bf(paace->impl_attr, PAACE_IA_OTM, PAACE_OTM_INDEXED);
-		paace->op_encode.index_ot.omi = omi;
-	} else if (~omi != 0) {
-		pr_debug("bad operation mapping index: %d\n", omi);
-		return -EINVAL;
-	}
-
-	if (~stashid != 0)
-		set_bf(paace->impl_attr, PAACE_IA_CID, stashid);
-
-	smp_wmb();
-
-	if (enable)
-		set_bf(paace->addr_bitfields, PAACE_AF_V, PAACE_V_VALID);
-
+	set_bf(ppaace->impl_attr, PAACE_IA_ATM, PAACE_ATM_WINDOW_XLATE);
+	ppaace->twbah = rpn >> 20;
+	set_bf(ppaace->win_bitfields, PAACE_WIN_TWBAL, rpn);
+	set_bf(ppaace->addr_bitfields, PAACE_AF_AP, prot);
+	set_bf(ppaace->impl_attr, PAACE_IA_WCE, 0);
+	set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
 	mb();
 
 	return 0;
@@ -1129,17 +895,6 @@ static int fsl_pamu_probe(struct platform_device *pdev)
 	spaact_phys = virt_to_phys(spaact);
 	omt_phys = virt_to_phys(omt);
 
-	spaace_pool = gen_pool_create(ilog2(sizeof(struct paace)), -1);
-	if (!spaace_pool) {
-		ret = -ENOMEM;
-		dev_err(dev, "Failed to allocate spaace gen pool\n");
-		goto error;
-	}
-
-	ret = gen_pool_add(spaace_pool, (unsigned long)spaact, SPAACT_SIZE, -1);
-	if (ret)
-		goto error_genpool;
-
 	pamubypenr = in_be32(&guts_regs->pamubypenr);
 
 	for (pamu_reg_off = 0, pamu_counter = 0x80000000; pamu_reg_off < size;
@@ -1167,9 +922,6 @@ static int fsl_pamu_probe(struct platform_device *pdev)
 
 	return 0;
 
-error_genpool:
-	gen_pool_destroy(spaace_pool);
-
 error:
 	if (irq != NO_IRQ)
 		free_irq(irq, data);
diff --git a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h
index e1496ba96160fd..04fd843d718dd1 100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -383,18 +383,12 @@ struct ome {
 int pamu_domain_init(void);
 int pamu_enable_liodn(int liodn);
 int pamu_disable_liodn(int liodn);
-void pamu_free_subwins(int liodn);
 int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
 		       u32 omi, unsigned long rpn, u32 snoopid, uint32_t stashid,
-		       u32 subwin_cnt, int prot);
-int pamu_config_spaace(int liodn, u32 subwin_cnt, u32 subwin_addr,
-		       phys_addr_t subwin_size, u32 omi, unsigned long rpn,
-		       uint32_t snoopid, u32 stashid, int enable, int prot);
+		       int prot);
 
 u32 get_stash_id(u32 stash_dest_hint, u32 vcpu);
 void get_ome_index(u32 *omi_index, struct device *dev);
-int  pamu_update_paace_stash(int liodn, u32 subwin, u32 value);
-int pamu_disable_spaace(int liodn, u32 subwin);
-u32 pamu_get_max_subwin_cnt(void);
+int  pamu_update_paace_stash(int liodn, u32 value);
 
 #endif  /* __FSL_PAMU_H */
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index a4da5597755d3d..e6bdd38fc18409 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -56,65 +56,19 @@ static int __init iommu_init_mempool(void)
 
 static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, dma_addr_t iova)
 {
-	u32 win_cnt = dma_domain->win_cnt;
 	struct dma_window *win_ptr = &dma_domain->win_arr[0];
 	struct iommu_domain_geometry *geom;
 
 	geom = &dma_domain->iommu_domain.geometry;
 
-	if (!win_cnt) {
-		pr_debug("Number of windows/geometry not configured for the domain\n");
-		return 0;
-	}
-
-	if (win_cnt > 1) {
-		u64 subwin_size;
-		dma_addr_t subwin_iova;
-		u32 wnd;
-
-		subwin_size = (geom->aperture_end + 1) >> ilog2(win_cnt);
-		subwin_iova = iova & ~(subwin_size - 1);
-		wnd = (subwin_iova - geom->aperture_start) >> ilog2(subwin_size);
-		win_ptr = &dma_domain->win_arr[wnd];
-	}
-
 	if (win_ptr->valid)
 		return win_ptr->paddr + (iova & (win_ptr->size - 1));
 
 	return 0;
 }
 
-static int map_subwins(int liodn, struct fsl_dma_domain *dma_domain)
-{
-	struct dma_window *sub_win_ptr = &dma_domain->win_arr[0];
-	int i, ret;
-	unsigned long rpn, flags;
-
-	for (i = 0; i < dma_domain->win_cnt; i++) {
-		if (sub_win_ptr[i].valid) {
-			rpn = sub_win_ptr[i].paddr >> PAMU_PAGE_SHIFT;
-			spin_lock_irqsave(&iommu_lock, flags);
-			ret = pamu_config_spaace(liodn, dma_domain->win_cnt, i,
-						 sub_win_ptr[i].size,
-						 ~(u32)0,
-						 rpn,
-						 dma_domain->snoop_id,
-						 dma_domain->stash_id,
-						 (i > 0) ? 1 : 0,
-						 sub_win_ptr[i].prot);
-			spin_unlock_irqrestore(&iommu_lock, flags);
-			if (ret) {
-				pr_debug("SPAACE configuration failed for liodn %d\n",
-					 liodn);
-				return ret;
-			}
-		}
-	}
-
-	return ret;
-}
-
-static int map_win(int liodn, struct fsl_dma_domain *dma_domain)
+/* Map the DMA window corresponding to the LIODN */
+static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
 {
 	int ret;
 	struct dma_window *wnd = &dma_domain->win_arr[0];
@@ -127,7 +81,7 @@ static int map_win(int liodn, struct fsl_dma_domain *dma_domain)
 				 ~(u32)0,
 				 wnd->paddr >> PAMU_PAGE_SHIFT,
 				 dma_domain->snoop_id, dma_domain->stash_id,
-				 0, wnd->prot);
+				 wnd->prot);
 	spin_unlock_irqrestore(&iommu_lock, flags);
 	if (ret)
 		pr_debug("PAACE configuration failed for liodn %d\n", liodn);
@@ -135,50 +89,27 @@ static int map_win(int liodn, struct fsl_dma_domain *dma_domain)
 	return ret;
 }
 
-/* Map the DMA window corresponding to the LIODN */
-static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
-{
-	if (dma_domain->win_cnt > 1)
-		return map_subwins(liodn, dma_domain);
-	else
-		return map_win(liodn, dma_domain);
-}
-
 /* Update window/subwindow mapping for the LIODN */
 static int update_liodn(int liodn, struct fsl_dma_domain *dma_domain, u32 wnd_nr)
 {
 	int ret;
 	struct dma_window *wnd = &dma_domain->win_arr[wnd_nr];
+	phys_addr_t wnd_addr;
 	unsigned long flags;
 
 	spin_lock_irqsave(&iommu_lock, flags);
-	if (dma_domain->win_cnt > 1) {
-		ret = pamu_config_spaace(liodn, dma_domain->win_cnt, wnd_nr,
-					 wnd->size,
-					 ~(u32)0,
-					 wnd->paddr >> PAMU_PAGE_SHIFT,
-					 dma_domain->snoop_id,
-					 dma_domain->stash_id,
-					 (wnd_nr > 0) ? 1 : 0,
-					 wnd->prot);
-		if (ret)
-			pr_debug("Subwindow reconfiguration failed for liodn %d\n",
-				 liodn);
-	} else {
-		phys_addr_t wnd_addr;
 
-		wnd_addr = dma_domain->iommu_domain.geometry.aperture_start;
+	wnd_addr = dma_domain->iommu_domain.geometry.aperture_start;
 
-		ret = pamu_config_ppaace(liodn, wnd_addr,
-					 wnd->size,
-					 ~(u32)0,
-					 wnd->paddr >> PAMU_PAGE_SHIFT,
-					 dma_domain->snoop_id, dma_domain->stash_id,
-					 0, wnd->prot);
-		if (ret)
-			pr_debug("Window reconfiguration failed for liodn %d\n",
-				 liodn);
-	}
+	ret = pamu_config_ppaace(liodn, wnd_addr,
+				 wnd->size,
+				 ~(u32)0,
+				 wnd->paddr >> PAMU_PAGE_SHIFT,
+				 dma_domain->snoop_id, dma_domain->stash_id,
+				 wnd->prot);
+	if (ret)
+		pr_debug("Window reconfiguration failed for liodn %d\n",
+			 liodn);
 
 	spin_unlock_irqrestore(&iommu_lock, flags);
 
@@ -192,21 +123,12 @@ static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 	unsigned long flags;
 
 	spin_lock_irqsave(&iommu_lock, flags);
-	if (!dma_domain->win_arr) {
-		pr_debug("Windows not configured, stash destination update failed for liodn %d\n",
-			 liodn);
+	ret = pamu_update_paace_stash(liodn, val);
+	if (ret) {
+		pr_debug("Failed to update SPAACE %d field for liodn %d\n ",
+			 i, liodn);
 		spin_unlock_irqrestore(&iommu_lock, flags);
-		return -EINVAL;
-	}
-
-	for (i = 0; i < dma_domain->win_cnt; i++) {
-		ret = pamu_update_paace_stash(liodn, i, val);
-		if (ret) {
-			pr_debug("Failed to update SPAACE %d field for liodn %d\n ",
-				 i, liodn);
-			spin_unlock_irqrestore(&iommu_lock, flags);
-			return ret;
-		}
+		return ret;
 	}
 
 	spin_unlock_irqrestore(&iommu_lock, flags);
@@ -217,14 +139,12 @@ static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 /* Set the geometry parameters for a LIODN */
 static int pamu_set_liodn(int liodn, struct device *dev,
 			  struct fsl_dma_domain *dma_domain,
-			  struct iommu_domain_geometry *geom_attr,
-			  u32 win_cnt)
+			  struct iommu_domain_geometry *geom_attr)
 {
 	phys_addr_t window_addr, window_size;
-	phys_addr_t subwin_size;
-	int ret = 0, i;
 	u32 omi_index = ~(u32)0;
 	unsigned long flags;
+	int ret;
 
 	/*
 	 * Configure the omi_index at the geometry setup time.
@@ -241,34 +161,14 @@ static int pamu_set_liodn(int liodn, struct device *dev,
 	if (!ret)
 		ret = pamu_config_ppaace(liodn, window_addr, window_size, omi_index,
 					 0, dma_domain->snoop_id,
-					 dma_domain->stash_id, win_cnt, 0);
+					 dma_domain->stash_id, 0);
 	spin_unlock_irqrestore(&iommu_lock, flags);
 	if (ret) {
-		pr_debug("PAACE configuration failed for liodn %d, win_cnt =%d\n",
-			 liodn, win_cnt);
+		pr_debug("PAACE configuration failed for liodn %d\n",
+			 liodn);
 		return ret;
 	}
 
-	if (win_cnt > 1) {
-		subwin_size = window_size >> ilog2(win_cnt);
-		for (i = 0; i < win_cnt; i++) {
-			spin_lock_irqsave(&iommu_lock, flags);
-			ret = pamu_disable_spaace(liodn, i);
-			if (!ret)
-				ret = pamu_config_spaace(liodn, win_cnt, i,
-							 subwin_size, omi_index,
-							 0, dma_domain->snoop_id,
-							 dma_domain->stash_id,
-							 0, 0);
-			spin_unlock_irqrestore(&iommu_lock, flags);
-			if (ret) {
-				pr_debug("SPAACE configuration failed for liodn %d\n",
-					 liodn);
-				return ret;
-			}
-		}
-	}
-
 	return ret;
 }
 
@@ -292,14 +192,12 @@ static int check_size(u64 size, dma_addr_t iova)
 	return 0;
 }
 
-static void remove_device_ref(struct device_domain_info *info, u32 win_cnt)
+static void remove_device_ref(struct device_domain_info *info)
 {
 	unsigned long flags;
 
 	list_del(&info->link);
 	spin_lock_irqsave(&iommu_lock, flags);
-	if (win_cnt > 1)
-		pamu_free_subwins(info->liodn);
 	pamu_disable_liodn(info->liodn);
 	spin_unlock_irqrestore(&iommu_lock, flags);
 	spin_lock_irqsave(&device_domain_lock, flags);
@@ -317,7 +215,7 @@ static void detach_device(struct device *dev, struct fsl_dma_domain *dma_domain)
 	/* Remove the device from the domain device list */
 	list_for_each_entry_safe(info, tmp, &dma_domain->devices, link) {
 		if (!dev || (info->dev == dev))
-			remove_device_ref(info, dma_domain->win_cnt);
+			remove_device_ref(info);
 	}
 	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 }
@@ -399,7 +297,6 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned type)
 
 	dma_domain->stash_id = ~(u32)0;
 	dma_domain->snoop_id = ~(u32)0;
-	dma_domain->win_cnt = pamu_get_max_subwin_cnt();
 	INIT_LIST_HEAD(&dma_domain->devices);
 	spin_lock_init(&dma_domain->domain_lock);
 
@@ -411,24 +308,6 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned type)
 	return &dma_domain->iommu_domain;
 }
 
-/* Configure geometry settings for all LIODNs associated with domain */
-static int pamu_set_domain_geometry(struct fsl_dma_domain *dma_domain,
-				    struct iommu_domain_geometry *geom_attr,
-				    u32 win_cnt)
-{
-	struct device_domain_info *info;
-	int ret = 0;
-
-	list_for_each_entry(info, &dma_domain->devices, link) {
-		ret = pamu_set_liodn(info->liodn, info->dev, dma_domain,
-				     geom_attr, win_cnt);
-		if (ret)
-			break;
-	}
-
-	return ret;
-}
-
 /* Update stash destination for all LIODNs associated with the domain */
 static int update_domain_stash(struct fsl_dma_domain *dma_domain, u32 val)
 {
@@ -475,39 +354,30 @@ static int fsl_pamu_window_enable(struct iommu_domain *domain, u32 wnd_nr,
 		pamu_prot |= PAACE_AP_PERMS_UPDATE;
 
 	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	if (!dma_domain->win_arr) {
-		pr_debug("Number of windows not configured\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -ENODEV;
-	}
-
-	if (wnd_nr >= dma_domain->win_cnt) {
+	if (wnd_nr > 0) {
 		pr_debug("Invalid window index\n");
 		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 		return -EINVAL;
 	}
 
-	win_size = (domain->geometry.aperture_end + 1) >>
-			ilog2(dma_domain->win_cnt);
+	win_size = (domain->geometry.aperture_end + 1) >> ilog2(1);
 	if (size > win_size) {
 		pr_debug("Invalid window size\n");
 		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 		return -EINVAL;
 	}
 
-	if (dma_domain->win_cnt == 1) {
-		if (dma_domain->enabled) {
-			pr_debug("Disable the window before updating the mapping\n");
-			spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-			return -EBUSY;
-		}
+	if (dma_domain->enabled) {
+		pr_debug("Disable the window before updating the mapping\n");
+		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
+		return -EBUSY;
+	}
 
-		ret = check_size(size, domain->geometry.aperture_start);
-		if (ret) {
-			pr_debug("Aperture start not aligned to the size\n");
-			spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-			return -EINVAL;
-		}
+	ret = check_size(size, domain->geometry.aperture_start);
+	if (ret) {
+		pr_debug("Aperture start not aligned to the size\n");
+		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
+		return -EINVAL;
 	}
 
 	wnd = &dma_domain->win_arr[wnd_nr];
@@ -560,22 +430,18 @@ static int handle_attach_device(struct fsl_dma_domain *dma_domain,
 		 * for the domain. If yes, set the geometry for
 		 * the LIODN.
 		 */
-		if (dma_domain->win_arr) {
-			u32 win_cnt = dma_domain->win_cnt > 1 ? dma_domain->win_cnt : 0;
-
-			ret = pamu_set_liodn(liodn[i], dev, dma_domain,
-					     &domain->geometry, win_cnt);
+		ret = pamu_set_liodn(liodn[i], dev, dma_domain,
+				     &domain->geometry);
+		if (ret)
+			break;
+		if (dma_domain->mapped) {
+			/*
+			 * Create window/subwindow mapping for
+			 * the LIODN.
+			 */
+			ret = map_liodn(liodn[i], dma_domain);
 			if (ret)
 				break;
-			if (dma_domain->mapped) {
-				/*
-				 * Create window/subwindow mapping for
-				 * the LIODN.
-				 */
-				ret = map_liodn(liodn[i], dma_domain);
-				if (ret)
-					break;
-			}
 		}
 	}
 	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
@@ -706,48 +572,6 @@ static int configure_domain_dma_state(struct fsl_dma_domain *dma_domain, bool en
 	return 0;
 }
 
-static int fsl_pamu_set_windows(struct iommu_domain *domain, u32 w_count)
-{
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	unsigned long flags;
-	int ret;
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	/* Ensure domain is inactive i.e. DMA should be disabled for the domain */
-	if (dma_domain->enabled) {
-		pr_debug("Can't set geometry attributes as domain is active\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return  -EBUSY;
-	}
-
-	/*
-	 * Ensure we have valid window count i.e. it should be less than
-	 * maximum permissible limit and should be a power of two.
-	 */
-	if (w_count > pamu_get_max_subwin_cnt() || !is_power_of_2(w_count)) {
-		pr_debug("Invalid window count\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EINVAL;
-	}
-
-	ret = pamu_set_domain_geometry(dma_domain, &domain->geometry,
-				       w_count > 1 ? w_count : 0);
-	if (!ret) {
-		kfree(dma_domain->win_arr);
-		dma_domain->win_arr = kcalloc(w_count,
-					      sizeof(*dma_domain->win_arr),
-					      GFP_ATOMIC);
-		if (!dma_domain->win_arr) {
-			spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-			return -ENOMEM;
-		}
-		dma_domain->win_cnt = w_count;
-	}
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-
-	return ret;
-}
-
 static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
 				    enum iommu_attr attr_type, void *data)
 {
@@ -761,9 +585,6 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
 	case DOMAIN_ATTR_FSL_PAMU_ENABLE:
 		ret = configure_domain_dma_state(dma_domain, *(int *)data);
 		break;
-	case DOMAIN_ATTR_WINDOWS:
-		ret = fsl_pamu_set_windows(domain, *(u32 *)data);
-		break;
 	default:
 		pr_debug("Unsupported attribute type\n");
 		ret = -EINVAL;
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index 53d359d66fe577..d3523ee9999d83 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -17,23 +17,11 @@ struct dma_window {
 };
 
 struct fsl_dma_domain {
-	/*
-	 * Number of windows assocaited with this domain.
-	 * During domain initialization, it is set to the
-	 * the maximum number of subwindows allowed for a LIODN.
-	 * Minimum value for this is 1 indicating a single PAMU
-	 * window, without any sub windows. Value can be set/
-	 * queried by set_attr/get_attr API for DOMAIN_ATTR_WINDOWS.
-	 * Value can only be set once the geometry has been configured.
-	 */
-	u32				win_cnt;
 	/*
 	 * win_arr contains information of the configured
-	 * windows for a domain. This is allocated only
-	 * when the number of windows for the domain are
-	 * set.
+	 * windows for a domain.
 	 */
-	struct dma_window		*win_arr;
+	struct dma_window		win_arr[1];
 	/* list of devices associated with the domain */
 	struct list_head		devices;
 	/* dma_domain states:
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index c958e6310d3094..3d56ec4b373b4b 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -55,13 +55,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 		dev_err(dev, "%s(): iommu_domain_alloc() failed", __func__);
 		goto no_iommu;
 	}
-	ret = iommu_domain_set_attr(pcfg->iommu_domain, DOMAIN_ATTR_WINDOWS,
-				    &window_count);
-	if (ret < 0) {
-		dev_err(dev, "%s(): iommu_domain_set_attr() = %d", __func__,
-			ret);
-		goto out_domain_free;
-	}
 	stash_attr.cpu = cpu;
 	stash_attr.cache = PAMU_ATTR_CACHE_L1;
 	ret = iommu_domain_set_attr(pcfg->iommu_domain,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 52874ae164dd60..861c3558c878bf 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -109,7 +109,6 @@ enum iommu_cap {
 enum iommu_attr {
 	DOMAIN_ATTR_GEOMETRY,
 	DOMAIN_ATTR_PAGING,
-	DOMAIN_ATTR_WINDOWS,
 	DOMAIN_ATTR_FSL_PAMU_STASH,
 	DOMAIN_ATTR_FSL_PAMU_ENABLE,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:38 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:38 +0200
Subject: [PATCH 02/20] iommu/fsl_pamu: remove fsl_pamu_get_domain_attr
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-3-hch@lst.de>

None of the values returned by this function are ever queried.  Also
remove the DOMAIN_ATTR_FSL_PAMUV1 enum value that is not otherwise used.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 30 ------------------------------
 include/linux/iommu.h           |  4 ----
 2 files changed, 34 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 53380cf1fa452f..e587ec43f7e750 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -832,35 +832,6 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
 	return ret;
 }
 
-static int fsl_pamu_get_domain_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr_type, void *data)
-{
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	int ret = 0;
-
-	switch (attr_type) {
-	case DOMAIN_ATTR_FSL_PAMU_STASH:
-		memcpy(data, &dma_domain->dma_stash,
-		       sizeof(struct pamu_stash_attribute));
-		break;
-	case DOMAIN_ATTR_FSL_PAMU_ENABLE:
-		*(int *)data = dma_domain->enabled;
-		break;
-	case DOMAIN_ATTR_FSL_PAMUV1:
-		*(int *)data = DOMAIN_ATTR_FSL_PAMUV1;
-		break;
-	case DOMAIN_ATTR_WINDOWS:
-		*(u32 *)data = dma_domain->win_cnt;
-		break;
-	default:
-		pr_debug("Unsupported attribute type\n");
-		ret = -EINVAL;
-		break;
-	}
-
-	return ret;
-}
-
 static struct iommu_group *get_device_iommu_group(struct device *dev)
 {
 	struct iommu_group *group;
@@ -987,7 +958,6 @@ static const struct iommu_ops fsl_pamu_ops = {
 	.domain_window_enable = fsl_pamu_window_enable,
 	.iova_to_phys	= fsl_pamu_iova_to_phys,
 	.domain_set_attr = fsl_pamu_set_domain_attr,
-	.domain_get_attr = fsl_pamu_get_domain_attr,
 	.probe_device	= fsl_pamu_probe_device,
 	.release_device	= fsl_pamu_release_device,
 	.device_group   = fsl_pamu_device_group,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 47c8b318d8f523..52874ae164dd60 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -104,9 +104,6 @@ enum iommu_cap {
  *  -the actual size of the mapped region of a window must be power
  *   of 2 starting with 4KB and physical address must be naturally
  *   aligned.
- * DOMAIN_ATTR_FSL_PAMUV1 corresponds to the above mentioned contraints.
- * The caller can invoke iommu_domain_get_attr to check if the underlying
- * iommu implementation supports these constraints.
  */
 
 enum iommu_attr {
@@ -115,7 +112,6 @@ enum iommu_attr {
 	DOMAIN_ATTR_WINDOWS,
 	DOMAIN_ATTR_FSL_PAMU_STASH,
 	DOMAIN_ATTR_FSL_PAMU_ENABLE,
-	DOMAIN_ATTR_FSL_PAMUV1,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:40 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:40 +0200
Subject: [PATCH 04/20] iommu/fsl_pamu: merge iommu_alloc_dma_domain into
 fsl_pamu_domain_alloc
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-5-hch@lst.de>

Keep the functionality to allocate the domain together.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 34 ++++++++++-----------------------
 1 file changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 7bd08ddad07779..a4da5597755d3d 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -292,25 +292,6 @@ static int check_size(u64 size, dma_addr_t iova)
 	return 0;
 }
 
-static struct fsl_dma_domain *iommu_alloc_dma_domain(void)
-{
-	struct fsl_dma_domain *domain;
-
-	domain = kmem_cache_zalloc(fsl_pamu_domain_cache, GFP_KERNEL);
-	if (!domain)
-		return NULL;
-
-	domain->stash_id = ~(u32)0;
-	domain->snoop_id = ~(u32)0;
-	domain->win_cnt = pamu_get_max_subwin_cnt();
-
-	INIT_LIST_HEAD(&domain->devices);
-
-	spin_lock_init(&domain->domain_lock);
-
-	return domain;
-}
-
 static void remove_device_ref(struct device_domain_info *info, u32 win_cnt)
 {
 	unsigned long flags;
@@ -412,12 +393,17 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned type)
 	if (type != IOMMU_DOMAIN_UNMANAGED)
 		return NULL;
 
-	dma_domain = iommu_alloc_dma_domain();
-	if (!dma_domain) {
-		pr_debug("dma_domain allocation failed\n");
+	dma_domain = kmem_cache_zalloc(fsl_pamu_domain_cache, GFP_KERNEL);
+	if (!dma_domain)
 		return NULL;
-	}
-	/* defaul geometry 64 GB i.e. maximum system address */
+
+	dma_domain->stash_id = ~(u32)0;
+	dma_domain->snoop_id = ~(u32)0;
+	dma_domain->win_cnt = pamu_get_max_subwin_cnt();
+	INIT_LIST_HEAD(&dma_domain->devices);
+	spin_lock_init(&dma_domain->domain_lock);
+
+	/* default geometry 64 GB i.e. maximum system address */
 	dma_domain->iommu_domain. geometry.aperture_start = 0;
 	dma_domain->iommu_domain.geometry.aperture_end = (1ULL << 36) - 1;
 	dma_domain->iommu_domain.geometry.force_aperture = true;
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:36 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:36 +0200
Subject: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver v3
Message-ID: <20210401155256.298656-1-hch@lst.de>

Hi all,

there are a bunch of IOMMU APIs that are entirely unused, or only used as
a private communication channel between the FSL PAMU driver and it's only
consumer, the qbman portal driver.

So this series drops a huge chunk of entirely unused FSL PAMU
functionality, then drops all kinds of unused IOMMU APIs, and then
replaces what is left of the iommu_attrs with properly typed, smaller
and easier to use specific APIs.

Changes since v2:
 - remove a comment fragment a little bit earlier
 - fix the aperture end passed to pamu_config_ppaace
 - fix a few trivial typos
 - remove more unused arguments to pamu_config_ppaace
 - do not accidentally enable lazy flushing for non-dma domains

Changes since v1:
 - use a different way to control strict flushing behavior (from Robin)
 - remove the iommu_cmd_line wrappers
 - simplify the pagetbl quirks a little more
 - slightly improved patch ordering
 - better changelogs

Diffstat:
 arch/powerpc/include/asm/fsl_pamu_stash.h   |   12 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c     |    5 
 drivers/iommu/amd/iommu.c                   |   23 
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   75 ---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |    1 
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  111 +---
 drivers/iommu/arm/arm-smmu/arm-smmu.h       |    2 
 drivers/iommu/dma-iommu.c                   |    9 
 drivers/iommu/fsl_pamu.c                    |  293 -----------
 drivers/iommu/fsl_pamu.h                    |   12 
 drivers/iommu/fsl_pamu_domain.c             |  688 ++--------------------------
 drivers/iommu/fsl_pamu_domain.h             |   46 -
 drivers/iommu/intel/iommu.c                 |   95 ---
 drivers/iommu/iommu.c                       |  118 +---
 drivers/soc/fsl/qbman/qman_portal.c         |   55 --
 drivers/vfio/vfio_iommu_type1.c             |   31 -
 drivers/vhost/vdpa.c                        |   10 
 include/linux/io-pgtable.h                  |    4 
 include/linux/iommu.h                       |   76 ---
 19 files changed, 203 insertions(+), 1463 deletions(-)


From hch at lst.de  Thu Apr  1 16:52:43 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:43 +0200
Subject: [PATCH 07/20] iommu/fsl_pamu: replace DOMAIN_ATTR_FSL_PAMU_STASH with
 a direct call
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-8-hch@lst.de>

Add a fsl_pamu_configure_l1_stash API that qman_portal can call directly
instead of indirecting through the iommu attr API.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 arch/powerpc/include/asm/fsl_pamu_stash.h | 12 +++---------
 drivers/iommu/fsl_pamu_domain.c           | 16 +++-------------
 drivers/iommu/fsl_pamu_domain.h           |  2 --
 drivers/soc/fsl/qbman/qman_portal.c       | 18 +++---------------
 include/linux/iommu.h                     |  1 -
 5 files changed, 9 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/fsl_pamu_stash.h b/arch/powerpc/include/asm/fsl_pamu_stash.h
index 30a31ad2123d86..c0fbadb70b5dad 100644
--- a/arch/powerpc/include/asm/fsl_pamu_stash.h
+++ b/arch/powerpc/include/asm/fsl_pamu_stash.h
@@ -7,6 +7,8 @@
 #ifndef __FSL_PAMU_STASH_H
 #define __FSL_PAMU_STASH_H
 
+struct iommu_domain;
+
 /* cache stash targets */
 enum pamu_stash_target {
 	PAMU_ATTR_CACHE_L1 = 1,
@@ -14,14 +16,6 @@ enum pamu_stash_target {
 	PAMU_ATTR_CACHE_L3,
 };
 
-/*
- * This attribute allows configuring stashig specific parameters
- * in the PAMU hardware.
- */
-
-struct pamu_stash_attribute {
-	u32	cpu;	/* cpu number */
-	u32	cache;	/* cache to stash to: L1,L2,L3 */
-};
+int fsl_pamu_configure_l1_stash(struct iommu_domain *domain, u32 cpu);
 
 #endif  /* __FSL_PAMU_STASH_H */
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 689035e9d40955..557a152c1d2c49 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -372,27 +372,20 @@ static void fsl_pamu_detach_device(struct iommu_domain *domain,
 }
 
 /* Set the domain stash attribute */
-static int configure_domain_stash(struct fsl_dma_domain *dma_domain, void *data)
+int fsl_pamu_configure_l1_stash(struct iommu_domain *domain, u32 cpu)
 {
-	struct pamu_stash_attribute *stash_attr = data;
+	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
 	unsigned long flags;
 	int ret;
 
 	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-
-	memcpy(&dma_domain->dma_stash, stash_attr,
-	       sizeof(struct pamu_stash_attribute));
-
-	dma_domain->stash_id = get_stash_id(stash_attr->cache,
-					    stash_attr->cpu);
+	dma_domain->stash_id = get_stash_id(PAMU_ATTR_CACHE_L1, cpu);
 	if (dma_domain->stash_id == ~(u32)0) {
 		pr_debug("Invalid stash attributes\n");
 		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 		return -EINVAL;
 	}
-
 	ret = update_domain_stash(dma_domain, dma_domain->stash_id);
-
 	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 
 	return ret;
@@ -426,9 +419,6 @@ static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
 	int ret = 0;
 
 	switch (attr_type) {
-	case DOMAIN_ATTR_FSL_PAMU_STASH:
-		ret = configure_domain_stash(dma_domain, data);
-		break;
 	case DOMAIN_ATTR_FSL_PAMU_ENABLE:
 		ret = configure_domain_dma_state(dma_domain, *(int *)data);
 		break;
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index 13ee06e0ef0136..cd488004acd1b3 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -22,9 +22,7 @@ struct fsl_dma_domain {
 	 *
 	 */
 	int				enabled;
-	/* stash_id obtained from the stash attribute details */
 	u32				stash_id;
-	struct pamu_stash_attribute	dma_stash;
 	u32				snoop_id;
 	struct iommu_domain		iommu_domain;
 	spinlock_t			domain_lock;
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index 9ee1663f422cbf..798b3a1ffd0b9c 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -47,7 +47,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 #ifdef CONFIG_FSL_PAMU
 	struct device *dev = pcfg->dev;
 	int window_count = 1;
-	struct pamu_stash_attribute stash_attr;
 	int ret;
 
 	pcfg->iommu_domain = iommu_domain_alloc(&platform_bus_type);
@@ -55,13 +54,9 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 		dev_err(dev, "%s(): iommu_domain_alloc() failed", __func__);
 		goto no_iommu;
 	}
-	stash_attr.cpu = cpu;
-	stash_attr.cache = PAMU_ATTR_CACHE_L1;
-	ret = iommu_domain_set_attr(pcfg->iommu_domain,
-				    DOMAIN_ATTR_FSL_PAMU_STASH,
-				    &stash_attr);
+	ret = fsl_pamu_configure_l1_stash(pcfg->iommu_domain, cpu);
 	if (ret < 0) {
-		dev_err(dev, "%s(): iommu_domain_set_attr() = %d",
+		dev_err(dev, "%s(): fsl_pamu_configure_l1_stash() = %d",
 			__func__, ret);
 		goto out_domain_free;
 	}
@@ -143,15 +138,8 @@ static void qman_portal_update_sdest(const struct qm_portal_config *pcfg,
 							unsigned int cpu)
 {
 #ifdef CONFIG_FSL_PAMU /* TODO */
-	struct pamu_stash_attribute stash_attr;
-	int ret;
-
 	if (pcfg->iommu_domain) {
-		stash_attr.cpu = cpu;
-		stash_attr.cache = PAMU_ATTR_CACHE_L1;
-		ret = iommu_domain_set_attr(pcfg->iommu_domain,
-				DOMAIN_ATTR_FSL_PAMU_STASH, &stash_attr);
-		if (ret < 0) {
+		if (fsl_pamu_configure_l1_stash(pcfg->iommu_domain, cpu) < 0) {
 			dev_err(pcfg->dev,
 				"Failed to update pamu stash setting\n");
 			return;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f7baa81887a8bc..208e570e8d99e7 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -109,7 +109,6 @@ enum iommu_cap {
 enum iommu_attr {
 	DOMAIN_ATTR_GEOMETRY,
 	DOMAIN_ATTR_PAGING,
-	DOMAIN_ATTR_FSL_PAMU_STASH,
 	DOMAIN_ATTR_FSL_PAMU_ENABLE,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:42 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:42 +0200
Subject: [PATCH 06/20] iommu/fsl_pamu: remove ->domain_window_enable
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-7-hch@lst.de>

The only thing that fsl_pamu_window_enable does for the current caller
is to fill in the prot value in the only dma_window structure, and to
propagate a few values from the iommu_domain_geometry struture into the
dma_window.  Remove the dma_window entirely, hardcode the prot value and
otherwise use the iommu_domain_geometry structure instead.

Remove the now unused ->domain_window_enable iommu method.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c     | 182 +++-------------------------
 drivers/iommu/fsl_pamu_domain.h     |  15 ---
 drivers/iommu/iommu.c               |  11 --
 drivers/soc/fsl/qbman/qman_portal.c |   7 --
 include/linux/iommu.h               |  17 ---
 5 files changed, 14 insertions(+), 218 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index e6bdd38fc18409..689035e9d40955 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -54,34 +54,18 @@ static int __init iommu_init_mempool(void)
 	return 0;
 }
 
-static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, dma_addr_t iova)
-{
-	struct dma_window *win_ptr = &dma_domain->win_arr[0];
-	struct iommu_domain_geometry *geom;
-
-	geom = &dma_domain->iommu_domain.geometry;
-
-	if (win_ptr->valid)
-		return win_ptr->paddr + (iova & (win_ptr->size - 1));
-
-	return 0;
-}
-
 /* Map the DMA window corresponding to the LIODN */
 static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
 {
 	int ret;
-	struct dma_window *wnd = &dma_domain->win_arr[0];
-	phys_addr_t wnd_addr = dma_domain->iommu_domain.geometry.aperture_start;
+	struct iommu_domain_geometry *geom = &dma_domain->iommu_domain.geometry;
 	unsigned long flags;
 
 	spin_lock_irqsave(&iommu_lock, flags);
-	ret = pamu_config_ppaace(liodn, wnd_addr,
-				 wnd->size,
-				 ~(u32)0,
-				 wnd->paddr >> PAMU_PAGE_SHIFT,
-				 dma_domain->snoop_id, dma_domain->stash_id,
-				 wnd->prot);
+	ret = pamu_config_ppaace(liodn, geom->aperture_start,
+				 geom->aperture_end + 1, ~(u32)0,
+				 0, dma_domain->snoop_id, dma_domain->stash_id,
+				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
 	spin_unlock_irqrestore(&iommu_lock, flags);
 	if (ret)
 		pr_debug("PAACE configuration failed for liodn %d\n", liodn);
@@ -89,33 +73,6 @@ static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
 	return ret;
 }
 
-/* Update window/subwindow mapping for the LIODN */
-static int update_liodn(int liodn, struct fsl_dma_domain *dma_domain, u32 wnd_nr)
-{
-	int ret;
-	struct dma_window *wnd = &dma_domain->win_arr[wnd_nr];
-	phys_addr_t wnd_addr;
-	unsigned long flags;
-
-	spin_lock_irqsave(&iommu_lock, flags);
-
-	wnd_addr = dma_domain->iommu_domain.geometry.aperture_start;
-
-	ret = pamu_config_ppaace(liodn, wnd_addr,
-				 wnd->size,
-				 ~(u32)0,
-				 wnd->paddr >> PAMU_PAGE_SHIFT,
-				 dma_domain->snoop_id, dma_domain->stash_id,
-				 wnd->prot);
-	if (ret)
-		pr_debug("Window reconfiguration failed for liodn %d\n",
-			 liodn);
-
-	spin_unlock_irqrestore(&iommu_lock, flags);
-
-	return ret;
-}
-
 static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 			      u32 val)
 {
@@ -172,26 +129,6 @@ static int pamu_set_liodn(int liodn, struct device *dev,
 	return ret;
 }
 
-static int check_size(u64 size, dma_addr_t iova)
-{
-	/*
-	 * Size must be a power of two and at least be equal
-	 * to PAMU page size.
-	 */
-	if ((size & (size - 1)) || size < PAMU_PAGE_SIZE) {
-		pr_debug("Size too small or not a power of two\n");
-		return -EINVAL;
-	}
-
-	/* iova must be page size aligned */
-	if (iova & (size - 1)) {
-		pr_debug("Address is not aligned with window size\n");
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
 static void remove_device_ref(struct device_domain_info *info)
 {
 	unsigned long flags;
@@ -257,13 +194,10 @@ static void attach_device(struct fsl_dma_domain *dma_domain, int liodn, struct d
 static phys_addr_t fsl_pamu_iova_to_phys(struct iommu_domain *domain,
 					 dma_addr_t iova)
 {
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-
 	if (iova < domain->geometry.aperture_start ||
 	    iova > domain->geometry.aperture_end)
 		return 0;
-
-	return get_phys_addr(dma_domain, iova);
+	return iova;
 }
 
 static bool fsl_pamu_capable(enum iommu_cap cap)
@@ -279,7 +213,6 @@ static void fsl_pamu_domain_free(struct iommu_domain *domain)
 	detach_device(NULL, dma_domain);
 
 	dma_domain->enabled = 0;
-	dma_domain->mapped = 0;
 
 	kmem_cache_free(fsl_pamu_domain_cache, dma_domain);
 }
@@ -323,84 +256,6 @@ static int update_domain_stash(struct fsl_dma_domain *dma_domain, u32 val)
 	return ret;
 }
 
-/* Update domain mappings for all LIODNs associated with the domain */
-static int update_domain_mapping(struct fsl_dma_domain *dma_domain, u32 wnd_nr)
-{
-	struct device_domain_info *info;
-	int ret = 0;
-
-	list_for_each_entry(info, &dma_domain->devices, link) {
-		ret = update_liodn(info->liodn, dma_domain, wnd_nr);
-		if (ret)
-			break;
-	}
-	return ret;
-}
-
-
-static int fsl_pamu_window_enable(struct iommu_domain *domain, u32 wnd_nr,
-				  phys_addr_t paddr, u64 size, int prot)
-{
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	struct dma_window *wnd;
-	int pamu_prot = 0;
-	int ret;
-	unsigned long flags;
-	u64 win_size;
-
-	if (prot & IOMMU_READ)
-		pamu_prot |= PAACE_AP_PERMS_QUERY;
-	if (prot & IOMMU_WRITE)
-		pamu_prot |= PAACE_AP_PERMS_UPDATE;
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	if (wnd_nr > 0) {
-		pr_debug("Invalid window index\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EINVAL;
-	}
-
-	win_size = (domain->geometry.aperture_end + 1) >> ilog2(1);
-	if (size > win_size) {
-		pr_debug("Invalid window size\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EINVAL;
-	}
-
-	if (dma_domain->enabled) {
-		pr_debug("Disable the window before updating the mapping\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EBUSY;
-	}
-
-	ret = check_size(size, domain->geometry.aperture_start);
-	if (ret) {
-		pr_debug("Aperture start not aligned to the size\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -EINVAL;
-	}
-
-	wnd = &dma_domain->win_arr[wnd_nr];
-	if (!wnd->valid) {
-		wnd->paddr = paddr;
-		wnd->size = size;
-		wnd->prot = pamu_prot;
-
-		ret = update_domain_mapping(dma_domain, wnd_nr);
-		if (!ret) {
-			wnd->valid = 1;
-			dma_domain->mapped++;
-		}
-	} else {
-		pr_debug("Disable the window before updating the mapping\n");
-		ret = -EBUSY;
-	}
-
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-
-	return ret;
-}
-
 /*
  * Attach the LIODN to the DMA domain and configure the geometry
  * and window mappings.
@@ -434,15 +289,14 @@ static int handle_attach_device(struct fsl_dma_domain *dma_domain,
 				     &domain->geometry);
 		if (ret)
 			break;
-		if (dma_domain->mapped) {
-			/*
-			 * Create window/subwindow mapping for
-			 * the LIODN.
-			 */
-			ret = map_liodn(liodn[i], dma_domain);
-			if (ret)
-				break;
-		}
+
+		/*
+		 * Create window/subwindow mapping for
+		 * the LIODN.
+		 */
+		ret = map_liodn(liodn[i], dma_domain);
+		if (ret)
+			break;
 	}
 	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 
@@ -552,13 +406,6 @@ static int configure_domain_dma_state(struct fsl_dma_domain *dma_domain, bool en
 	int ret;
 
 	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-
-	if (enable && !dma_domain->mapped) {
-		pr_debug("Can't enable DMA domain without valid mapping\n");
-		spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-		return -ENODEV;
-	}
-
 	dma_domain->enabled = enable;
 	list_for_each_entry(info, &dma_domain->devices, link) {
 		ret = (enable) ? pamu_enable_liodn(info->liodn) :
@@ -717,7 +564,6 @@ static const struct iommu_ops fsl_pamu_ops = {
 	.domain_free    = fsl_pamu_domain_free,
 	.attach_dev	= fsl_pamu_attach_device,
 	.detach_dev	= fsl_pamu_detach_device,
-	.domain_window_enable = fsl_pamu_window_enable,
 	.iova_to_phys	= fsl_pamu_iova_to_phys,
 	.domain_set_attr = fsl_pamu_set_domain_attr,
 	.probe_device	= fsl_pamu_probe_device,
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index d3523ee9999d83..13ee06e0ef0136 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -9,24 +9,10 @@
 
 #include "fsl_pamu.h"
 
-struct dma_window {
-	phys_addr_t paddr;
-	u64 size;
-	int valid;
-	int prot;
-};
-
 struct fsl_dma_domain {
-	/*
-	 * win_arr contains information of the configured
-	 * windows for a domain.
-	 */
-	struct dma_window		win_arr[1];
 	/* list of devices associated with the domain */
 	struct list_head		devices;
 	/* dma_domain states:
-	 * mapped - A particular mapping has been created
-	 * within the configured geometry.
 	 * enabled - DMA has been enabled for the given
 	 * domain. This translates to setting of the
 	 * valid bit for the primary PAACE in the PAMU
@@ -35,7 +21,6 @@ struct fsl_dma_domain {
 	 * enabled for it.
 	 *
 	 */
-	int				mapped;
 	int				enabled;
 	/* stash_id obtained from the stash attribute details */
 	u32				stash_id;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba8413..b212bf0261820b 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2610,17 +2610,6 @@ size_t iommu_map_sg_atomic(struct iommu_domain *domain, unsigned long iova,
 	return __iommu_map_sg(domain, iova, sg, nents, prot, GFP_ATOMIC);
 }
 
-int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
-			       phys_addr_t paddr, u64 size, int prot)
-{
-	if (unlikely(domain->ops->domain_window_enable == NULL))
-		return -ENODEV;
-
-	return domain->ops->domain_window_enable(domain, wnd_nr, paddr, size,
-						 prot);
-}
-EXPORT_SYMBOL_GPL(iommu_domain_window_enable);
-
 /**
  * report_iommu_fault() - report about an IOMMU fault to the IOMMU framework
  * @domain: the iommu domain where the fault has happened
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index 3d56ec4b373b4b..9ee1663f422cbf 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -65,13 +65,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 			__func__, ret);
 		goto out_domain_free;
 	}
-	ret = iommu_domain_window_enable(pcfg->iommu_domain, 0, 0, 1ULL << 36,
-					 IOMMU_READ | IOMMU_WRITE);
-	if (ret < 0) {
-		dev_err(dev, "%s(): iommu_domain_window_enable() = %d",
-			__func__, ret);
-		goto out_domain_free;
-	}
 	ret = iommu_attach_device(pcfg->iommu_domain, dev);
 	if (ret < 0) {
 		dev_err(dev, "%s(): iommu_device_attach() = %d", __func__,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 861c3558c878bf..f7baa81887a8bc 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -203,7 +203,6 @@ struct iommu_iotlb_gather {
  * @get_resv_regions: Request list of reserved regions for a device
  * @put_resv_regions: Free list of reserved regions for a device
  * @apply_resv_region: Temporary helper call-back for iova reserved ranges
- * @domain_window_enable: Configure and enable a particular window for a domain
  * @of_xlate: add OF master IDs to iommu grouping
  * @is_attach_deferred: Check if domain attach should be deferred from iommu
  *                      driver init to device driver init (default no)
@@ -261,10 +260,6 @@ struct iommu_ops {
 				  struct iommu_domain *domain,
 				  struct iommu_resv_region *region);
 
-	/* Window handling functions */
-	int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
-				    phys_addr_t paddr, u64 size, int prot);
-
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
 	bool (*is_attach_deferred)(struct iommu_domain *domain, struct device *dev);
 
@@ -505,11 +500,6 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 
-/* Window handling function prototypes */
-extern int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
-				      phys_addr_t offset, u64 size,
-				      int prot);
-
 extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
 			      unsigned long iova, int flags);
 
@@ -735,13 +725,6 @@ static inline void iommu_iotlb_sync(struct iommu_domain *domain,
 {
 }
 
-static inline int iommu_domain_window_enable(struct iommu_domain *domain,
-					     u32 wnd_nr, phys_addr_t paddr,
-					     u64 size, int prot)
-{
-	return -ENODEV;
-}
-
 static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
 {
 	return 0;
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:44 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:44 +0200
Subject: [PATCH 08/20] iommu/fsl_pamu: merge pamu_set_liodn and map_liodn
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-9-hch@lst.de>

Merge the two fuctions that configure the ppaace into a single coherent
function.  I somehow doubt we need the two pamu_config_ppaace calls,
but keep the existing behavior just to be on the safe side.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 65 +++++++++------------------------
 1 file changed, 17 insertions(+), 48 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 557a152c1d2c49..198725ef27954f 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -54,25 +54,6 @@ static int __init iommu_init_mempool(void)
 	return 0;
 }
 
-/* Map the DMA window corresponding to the LIODN */
-static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
-{
-	int ret;
-	struct iommu_domain_geometry *geom = &dma_domain->iommu_domain.geometry;
-	unsigned long flags;
-
-	spin_lock_irqsave(&iommu_lock, flags);
-	ret = pamu_config_ppaace(liodn, geom->aperture_start,
-				 geom->aperture_end + 1, ~(u32)0,
-				 0, dma_domain->snoop_id, dma_domain->stash_id,
-				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
-	spin_unlock_irqrestore(&iommu_lock, flags);
-	if (ret)
-		pr_debug("PAACE configuration failed for liodn %d\n", liodn);
-
-	return ret;
-}
-
 static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 			      u32 val)
 {
@@ -94,11 +75,11 @@ static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 }
 
 /* Set the geometry parameters for a LIODN */
-static int pamu_set_liodn(int liodn, struct device *dev,
-			  struct fsl_dma_domain *dma_domain,
-			  struct iommu_domain_geometry *geom_attr)
+static int pamu_set_liodn(struct fsl_dma_domain *dma_domain, struct device *dev,
+			  int liodn)
 {
-	phys_addr_t window_addr, window_size;
+	struct iommu_domain *domain = &dma_domain->iommu_domain;
+	struct iommu_domain_geometry *geom = &domain->geometry;
 	u32 omi_index = ~(u32)0;
 	unsigned long flags;
 	int ret;
@@ -110,22 +91,25 @@ static int pamu_set_liodn(int liodn, struct device *dev,
 	 */
 	get_ome_index(&omi_index, dev);
 
-	window_addr = geom_attr->aperture_start;
-	window_size = geom_attr->aperture_end + 1;
-
 	spin_lock_irqsave(&iommu_lock, flags);
 	ret = pamu_disable_liodn(liodn);
-	if (!ret)
-		ret = pamu_config_ppaace(liodn, window_addr, window_size, omi_index,
-					 0, dma_domain->snoop_id,
-					 dma_domain->stash_id, 0);
+	if (ret)
+		goto out_unlock;
+	ret = pamu_config_ppaace(liodn, geom->aperture_start,
+				 geom->aperture_end + 1, omi_index, 0,
+				 dma_domain->snoop_id, dma_domain->stash_id, 0);
+	if (ret)
+		goto out_unlock;
+	ret = pamu_config_ppaace(liodn, geom->aperture_start,
+				 geom->aperture_end + 1, ~(u32)0,
+				 0, dma_domain->snoop_id, dma_domain->stash_id,
+				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
+out_unlock:
 	spin_unlock_irqrestore(&iommu_lock, flags);
 	if (ret) {
 		pr_debug("PAACE configuration failed for liodn %d\n",
 			 liodn);
-		return ret;
 	}
-
 	return ret;
 }
 
@@ -265,7 +249,6 @@ static int handle_attach_device(struct fsl_dma_domain *dma_domain,
 				int num)
 {
 	unsigned long flags;
-	struct iommu_domain *domain = &dma_domain->iommu_domain;
 	int ret = 0;
 	int i;
 
@@ -280,21 +263,7 @@ static int handle_attach_device(struct fsl_dma_domain *dma_domain,
 		}
 
 		attach_device(dma_domain, liodn[i], dev);
-		/*
-		 * Check if geometry has already been configured
-		 * for the domain. If yes, set the geometry for
-		 * the LIODN.
-		 */
-		ret = pamu_set_liodn(liodn[i], dev, dma_domain,
-				     &domain->geometry);
-		if (ret)
-			break;
-
-		/*
-		 * Create window/subwindow mapping for
-		 * the LIODN.
-		 */
-		ret = map_liodn(liodn[i], dma_domain);
+		ret = pamu_set_liodn(dma_domain, dev, liodn[i]);
 		if (ret)
 			break;
 	}
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:46 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:46 +0200
Subject: [PATCH 10/20] iommu/fsl_pamu: enable the liodn when attaching a device
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-11-hch@lst.de>

Instead of a separate call to enable all devices from the list, just
enable the liodn once the device is attached to the iommu domain.

This also remove the DOMAIN_ATTR_FSL_PAMU_ENABLE iommu_attr.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c     | 47 ++---------------------------
 drivers/iommu/fsl_pamu_domain.h     | 10 ------
 drivers/soc/fsl/qbman/qman_portal.c | 11 -------
 include/linux/iommu.h               |  1 -
 4 files changed, 3 insertions(+), 66 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 41927c3c417751..c2e7e17570e76d 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -195,9 +195,6 @@ static void fsl_pamu_domain_free(struct iommu_domain *domain)
 
 	/* remove all the devices from the device list */
 	detach_device(NULL, dma_domain);
-
-	dma_domain->enabled = 0;
-
 	kmem_cache_free(fsl_pamu_domain_cache, dma_domain);
 }
 
@@ -285,6 +282,9 @@ static int fsl_pamu_attach_device(struct iommu_domain *domain,
 		ret = pamu_set_liodn(dma_domain, dev, liodn[i]);
 		if (ret)
 			break;
+		ret = pamu_enable_liodn(liodn[i]);
+		if (ret)
+			break;
 	}
 	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 	return ret;
@@ -341,46 +341,6 @@ int fsl_pamu_configure_l1_stash(struct iommu_domain *domain, u32 cpu)
 	return ret;
 }
 
-/* Configure domain dma state i.e. enable/disable DMA */
-static int configure_domain_dma_state(struct fsl_dma_domain *dma_domain, bool enable)
-{
-	struct device_domain_info *info;
-	unsigned long flags;
-	int ret;
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	dma_domain->enabled = enable;
-	list_for_each_entry(info, &dma_domain->devices, link) {
-		ret = (enable) ? pamu_enable_liodn(info->liodn) :
-			pamu_disable_liodn(info->liodn);
-		if (ret)
-			pr_debug("Unable to set dma state for liodn %d",
-				 info->liodn);
-	}
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-
-	return 0;
-}
-
-static int fsl_pamu_set_domain_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr_type, void *data)
-{
-	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
-	int ret = 0;
-
-	switch (attr_type) {
-	case DOMAIN_ATTR_FSL_PAMU_ENABLE:
-		ret = configure_domain_dma_state(dma_domain, *(int *)data);
-		break;
-	default:
-		pr_debug("Unsupported attribute type\n");
-		ret = -EINVAL;
-		break;
-	}
-
-	return ret;
-}
-
 static struct iommu_group *get_device_iommu_group(struct device *dev)
 {
 	struct iommu_group *group;
@@ -505,7 +465,6 @@ static const struct iommu_ops fsl_pamu_ops = {
 	.attach_dev	= fsl_pamu_attach_device,
 	.detach_dev	= fsl_pamu_detach_device,
 	.iova_to_phys	= fsl_pamu_iova_to_phys,
-	.domain_set_attr = fsl_pamu_set_domain_attr,
 	.probe_device	= fsl_pamu_probe_device,
 	.release_device	= fsl_pamu_release_device,
 	.device_group   = fsl_pamu_device_group,
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index cd488004acd1b3..5f4ed253f61b31 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -12,16 +12,6 @@
 struct fsl_dma_domain {
 	/* list of devices associated with the domain */
 	struct list_head		devices;
-	/* dma_domain states:
-	 * enabled - DMA has been enabled for the given
-	 * domain. This translates to setting of the
-	 * valid bit for the primary PAACE in the PAMU
-	 * PAACT table. Domain geometry should be set and
-	 * it must have a valid mapping before DMA can be
-	 * enabled for it.
-	 *
-	 */
-	int				enabled;
 	u32				stash_id;
 	u32				snoop_id;
 	struct iommu_domain		iommu_domain;
diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
index 798b3a1ffd0b9c..bf38eb0042ed52 100644
--- a/drivers/soc/fsl/qbman/qman_portal.c
+++ b/drivers/soc/fsl/qbman/qman_portal.c
@@ -46,7 +46,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 {
 #ifdef CONFIG_FSL_PAMU
 	struct device *dev = pcfg->dev;
-	int window_count = 1;
 	int ret;
 
 	pcfg->iommu_domain = iommu_domain_alloc(&platform_bus_type);
@@ -66,14 +65,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 			ret);
 		goto out_domain_free;
 	}
-	ret = iommu_domain_set_attr(pcfg->iommu_domain,
-				    DOMAIN_ATTR_FSL_PAMU_ENABLE,
-				    &window_count);
-	if (ret < 0) {
-		dev_err(dev, "%s(): iommu_domain_set_attr() = %d", __func__,
-			ret);
-		goto out_detach_device;
-	}
 
 no_iommu:
 #endif
@@ -82,8 +73,6 @@ static void portal_set_cpu(struct qm_portal_config *pcfg, int cpu)
 	return;
 
 #ifdef CONFIG_FSL_PAMU
-out_detach_device:
-	iommu_detach_device(pcfg->iommu_domain, NULL);
 out_domain_free:
 	iommu_domain_free(pcfg->iommu_domain);
 	pcfg->iommu_domain = NULL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 208e570e8d99e7..840864844027dc 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -109,7 +109,6 @@ enum iommu_cap {
 enum iommu_attr {
 	DOMAIN_ATTR_GEOMETRY,
 	DOMAIN_ATTR_PAGING,
-	DOMAIN_ATTR_FSL_PAMU_ENABLE,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:48 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:48 +0200
Subject: [PATCH 12/20] iommu/fsl_pamu: remove the rpn and snoop_id arguments
 to pamu_config_ppaac
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-13-hch@lst.de>

These are always wired to fixed values, so don't bother passing them as
arguments.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 drivers/iommu/fsl_pamu.c        | 14 +++-----------
 drivers/iommu/fsl_pamu.h        |  3 +--
 drivers/iommu/fsl_pamu_domain.c |  6 +++---
 3 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index 3e1647cd5ad47a..742fa0e8c45b88 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -181,18 +181,14 @@ int pamu_update_paace_stash(int liodn, u32 value)
  * @win_addr: starting address of DSA window
  * @win-size: size of DSA window
  * @omi: Operation mapping index -- if ~omi == 0 then omi not defined
- * @rpn: real (true physical) page number
  * @stashid: cache stash id for associated cpu -- if ~stashid == 0 then
  *	     stashid not defined
- * @snoopid: snoop id for hardware coherency -- if ~snoopid == 0 then
- *	     snoopid not defined
  * @prot: window permissions
  *
  * Returns 0 upon success else error code < 0 returned
  */
 int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
-		       u32 omi, unsigned long rpn, u32 snoopid, u32 stashid,
-		       int prot)
+		       u32 omi, u32 stashid, int prot)
 {
 	struct paace *ppaace;
 
@@ -234,13 +230,9 @@ int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
 	if (~stashid != 0)
 		set_bf(ppaace->impl_attr, PAACE_IA_CID, stashid);
 
-	/* configure snoop id */
-	if (~snoopid != 0)
-		ppaace->domain_attr.to_host.snpid = snoopid;
-
 	set_bf(ppaace->impl_attr, PAACE_IA_ATM, PAACE_ATM_WINDOW_XLATE);
-	ppaace->twbah = rpn >> 20;
-	set_bf(ppaace->win_bitfields, PAACE_WIN_TWBAL, rpn);
+	ppaace->twbah = 0;
+	set_bf(ppaace->win_bitfields, PAACE_WIN_TWBAL, 0);
 	set_bf(ppaace->addr_bitfields, PAACE_AF_AP, prot);
 	set_bf(ppaace->impl_attr, PAACE_IA_WCE, 0);
 	set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
diff --git a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h
index 04fd843d718dd1..c96b29f0c7077f 100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -384,8 +384,7 @@ int pamu_domain_init(void);
 int pamu_enable_liodn(int liodn);
 int pamu_disable_liodn(int liodn);
 int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
-		       u32 omi, unsigned long rpn, u32 snoopid, uint32_t stashid,
-		       int prot);
+		       u32 omi, uint32_t stashid, int prot);
 
 u32 get_stash_id(u32 stash_dest_hint, u32 vcpu);
 void get_ome_index(u32 *omi_index, struct device *dev);
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index e9c1e0dd68f084..c83f1e7c2cb0c9 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -96,13 +96,13 @@ static int pamu_set_liodn(struct fsl_dma_domain *dma_domain, struct device *dev,
 	if (ret)
 		goto out_unlock;
 	ret = pamu_config_ppaace(liodn, geom->aperture_start,
-				 geom->aperture_end + 1, omi_index, 0,
-				 ~(u32)0, dma_domain->stash_id, 0);
+				 geom->aperture_end + 1, omi_index,
+				 dma_domain->stash_id, 0);
 	if (ret)
 		goto out_unlock;
 	ret = pamu_config_ppaace(liodn, geom->aperture_start,
 				 geom->aperture_end + 1, ~(u32)0,
-				 0, ~(u32)0, dma_domain->stash_id,
+				 dma_domain->stash_id,
 				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
 out_unlock:
 	spin_unlock_irqrestore(&iommu_lock, flags);
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:47 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:47 +0200
Subject: [PATCH 11/20] iommu/fsl_pamu: remove the snoop_id field
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-12-hch@lst.de>

The snoop_id is always set to ~(u32)0.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 5 ++---
 drivers/iommu/fsl_pamu_domain.h | 1 -
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index c2e7e17570e76d..e9c1e0dd68f084 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -97,12 +97,12 @@ static int pamu_set_liodn(struct fsl_dma_domain *dma_domain, struct device *dev,
 		goto out_unlock;
 	ret = pamu_config_ppaace(liodn, geom->aperture_start,
 				 geom->aperture_end + 1, omi_index, 0,
-				 dma_domain->snoop_id, dma_domain->stash_id, 0);
+				 ~(u32)0, dma_domain->stash_id, 0);
 	if (ret)
 		goto out_unlock;
 	ret = pamu_config_ppaace(liodn, geom->aperture_start,
 				 geom->aperture_end + 1, ~(u32)0,
-				 0, dma_domain->snoop_id, dma_domain->stash_id,
+				 0, ~(u32)0, dma_domain->stash_id,
 				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
 out_unlock:
 	spin_unlock_irqrestore(&iommu_lock, flags);
@@ -210,7 +210,6 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned type)
 		return NULL;
 
 	dma_domain->stash_id = ~(u32)0;
-	dma_domain->snoop_id = ~(u32)0;
 	INIT_LIST_HEAD(&dma_domain->devices);
 	spin_lock_init(&dma_domain->domain_lock);
 
diff --git a/drivers/iommu/fsl_pamu_domain.h b/drivers/iommu/fsl_pamu_domain.h
index 5f4ed253f61b31..95ac1b3cab3b69 100644
--- a/drivers/iommu/fsl_pamu_domain.h
+++ b/drivers/iommu/fsl_pamu_domain.h
@@ -13,7 +13,6 @@ struct fsl_dma_domain {
 	/* list of devices associated with the domain */
 	struct list_head		devices;
 	u32				stash_id;
-	u32				snoop_id;
 	struct iommu_domain		iommu_domain;
 	spinlock_t			domain_lock;
 };
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:50 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:50 +0200
Subject: [PATCH 14/20] iommu: remove DOMAIN_ATTR_PAGING
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-15-hch@lst.de>

DOMAIN_ATTR_PAGING is never used.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/iommu.c | 5 -----
 include/linux/iommu.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b212bf0261820b..9a4cda390993e6 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2668,7 +2668,6 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
 			  enum iommu_attr attr, void *data)
 {
 	struct iommu_domain_geometry *geometry;
-	bool *paging;
 	int ret = 0;
 
 	switch (attr) {
@@ -2676,10 +2675,6 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
 		geometry  = data;
 		*geometry = domain->geometry;
 
-		break;
-	case DOMAIN_ATTR_PAGING:
-		paging  = data;
-		*paging = (domain->pgsize_bitmap != 0UL);
 		break;
 	default:
 		if (!domain->ops->domain_get_attr)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 840864844027dc..180ff4bd7fa7ef 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -108,7 +108,6 @@ enum iommu_cap {
 
 enum iommu_attr {
 	DOMAIN_ATTR_GEOMETRY,
-	DOMAIN_ATTR_PAGING,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:45 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:45 +0200
Subject: [PATCH 09/20] iommu/fsl_pamu: merge handle_attach_device into
 fsl_pamu_attach_device
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-10-hch@lst.de>

No good reason to split this functionality over two functions.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/fsl_pamu_domain.c | 59 +++++++++++----------------------
 1 file changed, 20 insertions(+), 39 deletions(-)

diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 198725ef27954f..41927c3c417751 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -240,45 +240,13 @@ static int update_domain_stash(struct fsl_dma_domain *dma_domain, u32 val)
 	return ret;
 }
 
-/*
- * Attach the LIODN to the DMA domain and configure the geometry
- * and window mappings.
- */
-static int handle_attach_device(struct fsl_dma_domain *dma_domain,
-				struct device *dev, const u32 *liodn,
-				int num)
-{
-	unsigned long flags;
-	int ret = 0;
-	int i;
-
-	spin_lock_irqsave(&dma_domain->domain_lock, flags);
-	for (i = 0; i < num; i++) {
-		/* Ensure that LIODN value is valid */
-		if (liodn[i] >= PAACE_NUMBER_ENTRIES) {
-			pr_debug("Invalid liodn %d, attach device failed for %pOF\n",
-				 liodn[i], dev->of_node);
-			ret = -EINVAL;
-			break;
-		}
-
-		attach_device(dma_domain, liodn[i], dev);
-		ret = pamu_set_liodn(dma_domain, dev, liodn[i]);
-		if (ret)
-			break;
-	}
-	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
-
-	return ret;
-}
-
 static int fsl_pamu_attach_device(struct iommu_domain *domain,
 				  struct device *dev)
 {
 	struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
+	unsigned long flags;
+	int len, ret = 0, i;
 	const u32 *liodn;
-	u32 liodn_cnt;
-	int len, ret = 0;
 	struct pci_dev *pdev = NULL;
 	struct pci_controller *pci_ctl;
 
@@ -298,14 +266,27 @@ static int fsl_pamu_attach_device(struct iommu_domain *domain,
 	}
 
 	liodn = of_get_property(dev->of_node, "fsl,liodn", &len);
-	if (liodn) {
-		liodn_cnt = len / sizeof(u32);
-		ret = handle_attach_device(dma_domain, dev, liodn, liodn_cnt);
-	} else {
+	if (!liodn) {
 		pr_debug("missing fsl,liodn property at %pOF\n", dev->of_node);
-		ret = -EINVAL;
+		return -EINVAL;
 	}
 
+	spin_lock_irqsave(&dma_domain->domain_lock, flags);
+	for (i = 0; i < len / sizeof(u32); i++) {
+		/* Ensure that LIODN value is valid */
+		if (liodn[i] >= PAACE_NUMBER_ENTRIES) {
+			pr_debug("Invalid liodn %d, attach device failed for %pOF\n",
+				 liodn[i], dev->of_node);
+			ret = -EINVAL;
+			break;
+		}
+
+		attach_device(dma_domain, liodn[i], dev);
+		ret = pamu_set_liodn(dma_domain, dev, liodn[i]);
+		if (ret)
+			break;
+	}
+	spin_unlock_irqrestore(&dma_domain->domain_lock, flags);
 	return ret;
 }
 
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:49 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:49 +0200
Subject: [PATCH 13/20] iommu/fsl_pamu: hardcode the window address and size in
 pamu_config_ppaace
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-14-hch@lst.de>

The win_addr and win_size parameters are always set to 0 and 1 << 36
respectively, so just hard code them.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 drivers/iommu/fsl_pamu.c        | 23 ++++-------------------
 drivers/iommu/fsl_pamu.h        |  3 +--
 drivers/iommu/fsl_pamu_domain.c | 10 ++--------
 3 files changed, 7 insertions(+), 29 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index 742fa0e8c45b88..fc38b1fba7cff0 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -178,8 +178,6 @@ int pamu_update_paace_stash(int liodn, u32 value)
  * pamu_config_paace() - Sets up PPAACE entry for specified liodn
  *
  * @liodn: Logical IO device number
- * @win_addr: starting address of DSA window
- * @win-size: size of DSA window
  * @omi: Operation mapping index -- if ~omi == 0 then omi not defined
  * @stashid: cache stash id for associated cpu -- if ~stashid == 0 then
  *	     stashid not defined
@@ -187,35 +185,22 @@ int pamu_update_paace_stash(int liodn, u32 value)
  *
  * Returns 0 upon success else error code < 0 returned
  */
-int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
-		       u32 omi, u32 stashid, int prot)
+int pamu_config_ppaace(int liodn, u32 omi, u32 stashid, int prot)
 {
 	struct paace *ppaace;
 
-	if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE) {
-		pr_debug("window size too small or not a power of two %pa\n",
-			 &win_size);
-		return -EINVAL;
-	}
-
-	if (win_addr & (win_size - 1)) {
-		pr_debug("window address is not aligned with window size\n");
-		return -EINVAL;
-	}
-
 	ppaace = pamu_get_ppaace(liodn);
 	if (!ppaace)
 		return -ENOENT;
 
 	/* window size is 2^(WSE+1) bytes */
 	set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
-	       map_addrspace_size_to_wse(win_size));
+	       map_addrspace_size_to_wse(1ULL << 36));
 
 	pamu_init_ppaace(ppaace);
 
-	ppaace->wbah = win_addr >> (PAMU_PAGE_SHIFT + 20);
-	set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL,
-	       (win_addr >> PAMU_PAGE_SHIFT));
+	ppaace->wbah = 0;
+	set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL, 0);
 
 	/* set up operation mapping if it's configured */
 	if (omi < OME_NUMBER_ENTRIES) {
diff --git a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h
index c96b29f0c7077f..36df7975ff64d3 100644
--- a/drivers/iommu/fsl_pamu.h
+++ b/drivers/iommu/fsl_pamu.h
@@ -383,8 +383,7 @@ struct ome {
 int pamu_domain_init(void);
 int pamu_enable_liodn(int liodn);
 int pamu_disable_liodn(int liodn);
-int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t win_size,
-		       u32 omi, uint32_t stashid, int prot);
+int pamu_config_ppaace(int liodn, u32 omi, uint32_t stashid, int prot);
 
 u32 get_stash_id(u32 stash_dest_hint, u32 vcpu);
 void get_ome_index(u32 *omi_index, struct device *dev);
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index c83f1e7c2cb0c9..32944d67baa495 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -78,8 +78,6 @@ static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
 static int pamu_set_liodn(struct fsl_dma_domain *dma_domain, struct device *dev,
 			  int liodn)
 {
-	struct iommu_domain *domain = &dma_domain->iommu_domain;
-	struct iommu_domain_geometry *geom = &domain->geometry;
 	u32 omi_index = ~(u32)0;
 	unsigned long flags;
 	int ret;
@@ -95,14 +93,10 @@ static int pamu_set_liodn(struct fsl_dma_domain *dma_domain, struct device *dev,
 	ret = pamu_disable_liodn(liodn);
 	if (ret)
 		goto out_unlock;
-	ret = pamu_config_ppaace(liodn, geom->aperture_start,
-				 geom->aperture_end + 1, omi_index,
-				 dma_domain->stash_id, 0);
+	ret = pamu_config_ppaace(liodn, omi_index, dma_domain->stash_id, 0);
 	if (ret)
 		goto out_unlock;
-	ret = pamu_config_ppaace(liodn, geom->aperture_start,
-				 geom->aperture_end + 1, ~(u32)0,
-				 dma_domain->stash_id,
+	ret = pamu_config_ppaace(liodn, ~(u32)0, dma_domain->stash_id,
 				 PAACE_AP_PERMS_QUERY | PAACE_AP_PERMS_UPDATE);
 out_unlock:
 	spin_unlock_irqrestore(&iommu_lock, flags);
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:51 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:51 +0200
Subject: [PATCH 15/20] iommu: remove DOMAIN_ATTR_GEOMETRY
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-16-hch@lst.de>

The geometry information can be trivially queried from the iommu_domain
struture.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/iommu.c           | 20 +++-----------------
 drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++--------------
 drivers/vhost/vdpa.c            | 10 +++-------
 include/linux/iommu.h           |  1 -
 4 files changed, 18 insertions(+), 39 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 9a4cda390993e6..23daaea7883b75 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2667,23 +2667,9 @@ core_initcall(iommu_init);
 int iommu_domain_get_attr(struct iommu_domain *domain,
 			  enum iommu_attr attr, void *data)
 {
-	struct iommu_domain_geometry *geometry;
-	int ret = 0;
-
-	switch (attr) {
-	case DOMAIN_ATTR_GEOMETRY:
-		geometry  = data;
-		*geometry = domain->geometry;
-
-		break;
-	default:
-		if (!domain->ops->domain_get_attr)
-			return -EINVAL;
-
-		ret = domain->ops->domain_get_attr(domain, attr, data);
-	}
-
-	return ret;
+	if (!domain->ops->domain_get_attr)
+		return -EINVAL;
+	return domain->ops->domain_get_attr(domain, attr, data);
 }
 EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
 
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45cbfd4879a553..ae6d72f17aee78 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2262,7 +2262,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	int ret;
 	bool resv_msi, msi_remap;
 	phys_addr_t resv_msi_base = 0;
-	struct iommu_domain_geometry geo;
+	struct iommu_domain_geometry *geo;
 	LIST_HEAD(iova_copy);
 	LIST_HEAD(group_resv_regions);
 
@@ -2343,10 +2343,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 		goto out_domain;
 
 	/* Get aperture info */
-	iommu_domain_get_attr(domain->domain, DOMAIN_ATTR_GEOMETRY, &geo);
-
-	if (vfio_iommu_aper_conflict(iommu, geo.aperture_start,
-				     geo.aperture_end)) {
+	geo = &domain->domain->geometry;
+	if (vfio_iommu_aper_conflict(iommu, geo->aperture_start,
+				     geo->aperture_end)) {
 		ret = -EINVAL;
 		goto out_detach;
 	}
@@ -2369,8 +2368,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	if (ret)
 		goto out_detach;
 
-	ret = vfio_iommu_aper_resize(&iova_copy, geo.aperture_start,
-				     geo.aperture_end);
+	ret = vfio_iommu_aper_resize(&iova_copy, geo->aperture_start,
+				     geo->aperture_end);
 	if (ret)
 		goto out_detach;
 
@@ -2503,7 +2502,6 @@ static void vfio_iommu_aper_expand(struct vfio_iommu *iommu,
 				   struct list_head *iova_copy)
 {
 	struct vfio_domain *domain;
-	struct iommu_domain_geometry geo;
 	struct vfio_iova *node;
 	dma_addr_t start = 0;
 	dma_addr_t end = (dma_addr_t)~0;
@@ -2512,12 +2510,12 @@ static void vfio_iommu_aper_expand(struct vfio_iommu *iommu,
 		return;
 
 	list_for_each_entry(domain, &iommu->domain_list, next) {
-		iommu_domain_get_attr(domain->domain, DOMAIN_ATTR_GEOMETRY,
-				      &geo);
-		if (geo.aperture_start > start)
-			start = geo.aperture_start;
-		if (geo.aperture_end < end)
-			end = geo.aperture_end;
+		struct iommu_domain_geometry *geo = &domain->domain->geometry;
+
+		if (geo->aperture_start > start)
+			start = geo->aperture_start;
+		if (geo->aperture_end < end)
+			end = geo->aperture_end;
 	}
 
 	/* Modify aperture limits. The new aper is either same or bigger */
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index e0a27e33629356..cd1ff7b556dcee 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -832,18 +832,14 @@ static void vhost_vdpa_free_domain(struct vhost_vdpa *v)
 static void vhost_vdpa_set_iova_range(struct vhost_vdpa *v)
 {
 	struct vdpa_iova_range *range = &v->range;
-	struct iommu_domain_geometry geo;
 	struct vdpa_device *vdpa = v->vdpa;
 	const struct vdpa_config_ops *ops = vdpa->config;
 
 	if (ops->get_iova_range) {
 		*range = ops->get_iova_range(vdpa);
-	} else if (v->domain &&
-		   !iommu_domain_get_attr(v->domain,
-		   DOMAIN_ATTR_GEOMETRY, &geo) &&
-		   geo.force_aperture) {
-		range->first = geo.aperture_start;
-		range->last = geo.aperture_end;
+	} else if (v->domain && v->domain->geometry.force_aperture) {
+		range->first = v->domain->geometry.aperture_start;
+		range->last = v->domain->geometry.aperture_end;
 	} else {
 		range->first = 0;
 		range->last = ULLONG_MAX;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 180ff4bd7fa7ef..c15a8658daad64 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -107,7 +107,6 @@ enum iommu_cap {
  */
 
 enum iommu_attr {
-	DOMAIN_ATTR_GEOMETRY,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:53 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:53 +0200
Subject: [PATCH 17/20] iommu: remove iommu_set_cmd_line_dma_api and
 iommu_cmd_line_dma_api
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-18-hch@lst.de>

Don't obsfucate the trivial bit flag check.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 58d1d11a8d5c10..052cef11ae30df 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -70,16 +70,6 @@ static const char * const iommu_group_resv_type_string[] = {
 
 #define IOMMU_CMD_LINE_DMA_API		BIT(0)
 
-static void iommu_set_cmd_line_dma_api(void)
-{
-	iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API;
-}
-
-static bool iommu_cmd_line_dma_api(void)
-{
-	return !!(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API);
-}
-
 static int iommu_alloc_default_domain(struct iommu_group *group,
 				      struct device *dev);
 static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
@@ -130,9 +120,7 @@ static const char *iommu_domain_type_str(unsigned int t)
 
 static int __init iommu_subsys_init(void)
 {
-	bool cmd_line = iommu_cmd_line_dma_api();
-
-	if (!cmd_line) {
+	if (!(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API)) {
 		if (IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH))
 			iommu_set_default_passthrough(false);
 		else
@@ -146,7 +134,8 @@ static int __init iommu_subsys_init(void)
 
 	pr_info("Default domain type: %s %s\n",
 		iommu_domain_type_str(iommu_def_domain_type),
-		cmd_line ? "(set via kernel command line)" : "");
+		(iommu_cmd_line & IOMMU_CMD_LINE_DMA_API) ?
+			"(set via kernel command line)" : "");
 
 	return 0;
 }
@@ -2757,16 +2746,14 @@ EXPORT_SYMBOL_GPL(iommu_alloc_resv_region);
 void iommu_set_default_passthrough(bool cmd_line)
 {
 	if (cmd_line)
-		iommu_set_cmd_line_dma_api();
-
+		iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API;
 	iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
 }
 
 void iommu_set_default_translated(bool cmd_line)
 {
 	if (cmd_line)
-		iommu_set_cmd_line_dma_api();
-
+		iommu_cmd_line |= IOMMU_CMD_LINE_DMA_API;
 	iommu_def_domain_type = IOMMU_DOMAIN_DMA;
 }
 
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:54 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:54 +0200
Subject: [PATCH 18/20] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-19-hch@lst.de>

From: Robin Murphy <robin.murphy at arm.com>

Instead make the global iommu_dma_strict paramete in iommu.c canonical by
exporting helpers to get and set it and use those directly in the drivers.

This make sure that the iommu.strict parameter also works for the AMD and
Intel IOMMU drivers on x86.  As those default to lazy flushing a new
IOMMU_CMD_LINE_STRICT is used to turn the value into a tristate to
represent the default if not overriden by an explicit parameter.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>.
[ported on top of the other iommu_attr changes and added a few small
 missing bits]
Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 drivers/iommu/amd/iommu.c                   | 23 +-------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 50 +---------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  1 -
 drivers/iommu/arm/arm-smmu/arm-smmu.c       | 27 +--------
 drivers/iommu/dma-iommu.c                   |  9 +--
 drivers/iommu/intel/iommu.c                 | 64 ++++-----------------
 drivers/iommu/iommu.c                       | 30 +++++++---
 include/linux/iommu.h                       |  4 +-
 8 files changed, 43 insertions(+), 165 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index a69a8b573e40d0..ce6393d2224d86 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1771,26 +1771,6 @@ static struct iommu_group *amd_iommu_device_group(struct device *dev)
 	return acpihid_device_group(dev);
 }
 
-static int amd_iommu_domain_get_attr(struct iommu_domain *domain,
-		enum iommu_attr attr, void *data)
-{
-	switch (domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		return -ENODEV;
-	case IOMMU_DOMAIN_DMA:
-		switch (attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-			*(int *)data = !amd_iommu_unmap_flush;
-			return 0;
-		default:
-			return -ENODEV;
-		}
-		break;
-	default:
-		return -EINVAL;
-	}
-}
-
 /*****************************************************************************
  *
  * The next functions belong to the dma_ops mapping/unmapping code.
@@ -1855,7 +1835,7 @@ int __init amd_iommu_init_dma_ops(void)
 		pr_info("IO/TLB flush on unmap enabled\n");
 	else
 		pr_info("Lazy IO/TLB flushing enabled\n");
-
+	iommu_set_dma_strict(amd_iommu_unmap_flush);
 	return 0;
 
 }
@@ -2257,7 +2237,6 @@ const struct iommu_ops amd_iommu_ops = {
 	.release_device = amd_iommu_release_device,
 	.probe_finalize = amd_iommu_probe_finalize,
 	.device_group = amd_iommu_device_group,
-	.domain_get_attr = amd_iommu_domain_get_attr,
 	.get_resv_regions = amd_iommu_get_resv_regions,
 	.put_resv_regions = generic_iommu_put_resv_regions,
 	.is_attach_deferred = amd_iommu_is_attach_deferred,
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 f1e38526d5bd40..91f7e7a3b34dfd 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2017,7 +2017,7 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain,
 		.iommu_dev	= smmu->dev,
 	};
 
-	if (smmu_domain->non_strict)
+	if (!iommu_get_dma_strict(domain))
 		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
 
 	pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
@@ -2449,52 +2449,6 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 	return group;
 }
 
-static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr, void *data)
-{
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-
-	switch (domain->type) {
-	case IOMMU_DOMAIN_DMA:
-		switch (attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-			*(int *)data = smmu_domain->non_strict;
-			return 0;
-		default:
-			return -ENODEV;
-		}
-		break;
-	default:
-		return -EINVAL;
-	}
-}
-
-static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr, void *data)
-{
-	int ret = 0;
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-
-	mutex_lock(&smmu_domain->init_mutex);
-
-	switch (domain->type) {
-	case IOMMU_DOMAIN_DMA:
-		switch(attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-			smmu_domain->non_strict = *(int *)data;
-			break;
-		default:
-			ret = -ENODEV;
-		}
-		break;
-	default:
-		ret = -EINVAL;
-	}
-
-	mutex_unlock(&smmu_domain->init_mutex);
-	return ret;
-}
-
 static int arm_smmu_enable_nesting(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
@@ -2607,8 +2561,6 @@ static struct iommu_ops arm_smmu_ops = {
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
 	.device_group		= arm_smmu_device_group,
-	.domain_get_attr	= arm_smmu_domain_get_attr,
-	.domain_set_attr	= arm_smmu_domain_set_attr,
 	.enable_nesting		= arm_smmu_enable_nesting,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
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 f985817c967a25..edb1de479dd1a7 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -668,7 +668,6 @@ struct arm_smmu_domain {
 	struct mutex			init_mutex; /* Protects smmu pointer */
 
 	struct io_pgtable_ops		*pgtbl_ops;
-	bool				non_strict;
 	atomic_t			nr_ats_masters;
 
 	enum arm_smmu_domain_stage	stage;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0aa6d667274970..f17c54a76ef6f1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -761,6 +761,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 		.iommu_dev	= smmu->dev,
 	};
 
+	if (!iommu_get_dma_strict(domain))
+		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+
 	if (smmu->impl && smmu->impl->init_context) {
 		ret = smmu->impl->init_context(smmu_domain, &pgtbl_cfg, dev);
 		if (ret)
@@ -1499,18 +1502,6 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 			return -ENODEV;
 		}
 		break;
-	case IOMMU_DOMAIN_DMA:
-		switch (attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE: {
-			bool non_strict = smmu_domain->pgtbl_cfg.quirks &
-					  IO_PGTABLE_QUIRK_NON_STRICT;
-			*(int *)data = non_strict;
-			return 0;
-		}
-		default:
-			return -ENODEV;
-		}
-		break;
 	default:
 		return -EINVAL;
 	}
@@ -1557,18 +1548,6 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 			ret = -ENODEV;
 		}
 		break;
-	case IOMMU_DOMAIN_DMA:
-		switch (attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-			if (*(int *)data)
-				smmu_domain->pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-			else
-				smmu_domain->pgtbl_cfg.quirks &= ~IO_PGTABLE_QUIRK_NON_STRICT;
-			break;
-		default:
-			ret = -ENODEV;
-		}
-		break;
 	default:
 		ret = -EINVAL;
 	}
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index af765c813cc84c..d67dfa320176ac 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -304,10 +304,7 @@ static void iommu_dma_flush_iotlb_all(struct iova_domain *iovad)
 
 	cookie = container_of(iovad, struct iommu_dma_cookie, iovad);
 	domain = cookie->fq_domain;
-	/*
-	 * The IOMMU driver supporting DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
-	 * implies that ops->flush_iotlb_all must be non-NULL.
-	 */
+
 	domain->ops->flush_iotlb_all(domain);
 }
 
@@ -334,7 +331,6 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
 	struct iommu_dma_cookie *cookie = domain->iova_cookie;
 	unsigned long order, base_pfn;
 	struct iova_domain *iovad;
-	int attr;
 
 	if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
 		return -EINVAL;
@@ -371,8 +367,7 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
 	init_iova_domain(iovad, 1UL << order, base_pfn);
 
 	if (!cookie->fq_domain && (!dev || !dev_is_untrusted(dev)) &&
-	    !iommu_domain_get_attr(domain, DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE, &attr) &&
-	    attr) {
+	    domain->ops->flush_iotlb_all && !iommu_get_dma_strict(domain)) {
 		if (init_iova_flush_queue(iovad, iommu_dma_flush_iotlb_all,
 					  iommu_dma_entry_dtor))
 			pr_warn("iova flush queue initialization failed\n");
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 070ba76242e819..5b00adfb7212a7 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4377,6 +4377,17 @@ int __init intel_iommu_init(void)
 
 	down_read(&dmar_global_lock);
 	for_each_active_iommu(iommu, drhd) {
+		/*
+		 * The flush queue implementation does not perform
+		 * page-selective invalidations that are required for efficient
+		 * TLB flushes in virtual environments.  The benefit of batching
+		 * is likely to be much lower than the overhead of synchronizing
+		 * the virtual and physical IOMMU page-tables.
+		 */
+		if (!intel_iommu_strict && cap_caching_mode(iommu->cap)) {
+			pr_warn("IOMMU batching is disabled due to virtualization");
+			intel_iommu_strict = 1;
+		}
 		iommu_device_sysfs_add(&iommu->iommu, NULL,
 				       intel_iommu_groups,
 				       "%s", iommu->name);
@@ -4385,6 +4396,7 @@ int __init intel_iommu_init(void)
 	}
 	up_read(&dmar_global_lock);
 
+	iommu_set_dma_strict(intel_iommu_strict);
 	bus_set_iommu(&pci_bus_type, &intel_iommu_ops);
 	if (si_domain && !hw_pass_through)
 		register_memory_notifier(&intel_iommu_memory_nb);
@@ -5440,57 +5452,6 @@ intel_iommu_enable_nesting(struct iommu_domain *domain)
 	return ret;
 }
 
-static bool domain_use_flush_queue(void)
-{
-	struct dmar_drhd_unit *drhd;
-	struct intel_iommu *iommu;
-	bool r = true;
-
-	if (intel_iommu_strict)
-		return false;
-
-	/*
-	 * The flush queue implementation does not perform page-selective
-	 * invalidations that are required for efficient TLB flushes in virtual
-	 * environments. The benefit of batching is likely to be much lower than
-	 * the overhead of synchronizing the virtual and physical IOMMU
-	 * page-tables.
-	 */
-	rcu_read_lock();
-	for_each_active_iommu(iommu, drhd) {
-		if (!cap_caching_mode(iommu->cap))
-			continue;
-
-		pr_warn_once("IOMMU batching is disabled due to virtualization");
-		r = false;
-		break;
-	}
-	rcu_read_unlock();
-
-	return r;
-}
-
-static int
-intel_iommu_domain_get_attr(struct iommu_domain *domain,
-			    enum iommu_attr attr, void *data)
-{
-	switch (domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		return -ENODEV;
-	case IOMMU_DOMAIN_DMA:
-		switch (attr) {
-		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-			*(int *)data = domain_use_flush_queue();
-			return 0;
-		default:
-			return -ENODEV;
-		}
-		break;
-	default:
-		return -EINVAL;
-	}
-}
-
 /*
  * Check that the device does not live on an external facing PCI port that is
  * marked as untrusted. Such devices should not be able to apply quirks and
@@ -5563,7 +5524,6 @@ const struct iommu_ops intel_iommu_ops = {
 	.capable		= intel_iommu_capable,
 	.domain_alloc		= intel_iommu_domain_alloc,
 	.domain_free		= intel_iommu_domain_free,
-	.domain_get_attr        = intel_iommu_domain_get_attr,
 	.enable_nesting		= intel_iommu_enable_nesting,
 	.attach_dev		= intel_iommu_attach_device,
 	.detach_dev		= intel_iommu_detach_device,
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 052cef11ae30df..d191e4a399785d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -69,6 +69,7 @@ static const char * const iommu_group_resv_type_string[] = {
 };
 
 #define IOMMU_CMD_LINE_DMA_API		BIT(0)
+#define IOMMU_CMD_LINE_STRICT		BIT(1)
 
 static int iommu_alloc_default_domain(struct iommu_group *group,
 				      struct device *dev);
@@ -318,10 +319,29 @@ early_param("iommu.passthrough", iommu_set_def_domain_type);
 
 static int __init iommu_dma_setup(char *str)
 {
-	return kstrtobool(str, &iommu_dma_strict);
+	int ret = kstrtobool(str, &iommu_dma_strict);
+
+	if (!ret)
+		iommu_cmd_line |= IOMMU_CMD_LINE_STRICT;
+	return ret;
 }
 early_param("iommu.strict", iommu_dma_setup);
 
+void iommu_set_dma_strict(bool strict)
+{
+	if (strict || !(iommu_cmd_line & IOMMU_CMD_LINE_STRICT))
+		iommu_dma_strict = strict;
+}
+
+bool iommu_get_dma_strict(struct iommu_domain *domain)
+{
+	/* only allow lazy flushing for DMA domains */
+	if (domain->type == IOMMU_DOMAIN_DMA)
+		return iommu_dma_strict;
+	return true;
+}
+EXPORT_SYMBOL_GPL(iommu_get_dma_strict);
+
 static ssize_t iommu_group_attr_show(struct kobject *kobj,
 				     struct attribute *__attr, char *buf)
 {
@@ -1500,14 +1520,6 @@ static int iommu_group_alloc_default_domain(struct bus_type *bus,
 	group->default_domain = dom;
 	if (!group->domain)
 		group->domain = dom;
-
-	if (!iommu_dma_strict) {
-		int attr = 1;
-		iommu_domain_set_attr(dom,
-				      DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
-				      &attr);
-	}
-
 	return 0;
 }
 
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 670e7a3523f286..4e1051dd8d9946 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -107,7 +107,6 @@ enum iommu_cap {
  */
 
 enum iommu_attr {
-	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
 	DOMAIN_ATTR_MAX,
 };
@@ -498,6 +497,9 @@ extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 int iommu_enable_nesting(struct iommu_domain *domain);
 
+void iommu_set_dma_strict(bool val);
+bool iommu_get_dma_strict(struct iommu_domain *domain);
+
 extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
 			      unsigned long iova, int flags);
 
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:52 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:52 +0200
Subject: [PATCH 16/20] iommu: remove DOMAIN_ATTR_NESTING
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-17-hch@lst.de>

Use an explicit enable_nesting method instead.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 43 ++++++++-------------
 drivers/iommu/arm/arm-smmu/arm-smmu.c       | 30 +++++++-------
 drivers/iommu/intel/iommu.c                 | 31 +++++----------
 drivers/iommu/iommu.c                       | 10 +++++
 drivers/vfio/vfio_iommu_type1.c             |  5 +--
 include/linux/iommu.h                       |  4 +-
 6 files changed, 55 insertions(+), 68 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 8594b4a8304375..f1e38526d5bd40 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2455,15 +2455,6 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
 
 	switch (domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		switch (attr) {
-		case DOMAIN_ATTR_NESTING:
-			*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
-			return 0;
-		default:
-			return -ENODEV;
-		}
-		break;
 	case IOMMU_DOMAIN_DMA:
 		switch (attr) {
 		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
@@ -2487,23 +2478,6 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 	mutex_lock(&smmu_domain->init_mutex);
 
 	switch (domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		switch (attr) {
-		case DOMAIN_ATTR_NESTING:
-			if (smmu_domain->smmu) {
-				ret = -EPERM;
-				goto out_unlock;
-			}
-
-			if (*(int *)data)
-				smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
-			else
-				smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
-			break;
-		default:
-			ret = -ENODEV;
-		}
-		break;
 	case IOMMU_DOMAIN_DMA:
 		switch(attr) {
 		case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
@@ -2517,11 +2491,25 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 		ret = -EINVAL;
 	}
 
-out_unlock:
 	mutex_unlock(&smmu_domain->init_mutex);
 	return ret;
 }
 
+static int arm_smmu_enable_nesting(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	int ret = 0;
+
+	mutex_lock(&smmu_domain->init_mutex);
+	if (smmu_domain->smmu)
+		ret = -EPERM;
+	else
+		smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
+	mutex_unlock(&smmu_domain->init_mutex);
+
+	return ret;
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2621,6 +2609,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.device_group		= arm_smmu_device_group,
 	.domain_get_attr	= arm_smmu_domain_get_attr,
 	.domain_set_attr	= arm_smmu_domain_set_attr,
+	.enable_nesting		= arm_smmu_enable_nesting,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a6158..0aa6d667274970 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1489,9 +1489,6 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 	switch(domain->type) {
 	case IOMMU_DOMAIN_UNMANAGED:
 		switch (attr) {
-		case DOMAIN_ATTR_NESTING:
-			*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
-			return 0;
 		case DOMAIN_ATTR_IO_PGTABLE_CFG: {
 			struct io_pgtable_domain_attr *pgtbl_cfg = data;
 			*pgtbl_cfg = smmu_domain->pgtbl_cfg;
@@ -1519,6 +1516,21 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 	}
 }
 
+static int arm_smmu_enable_nesting(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	int ret = 0;
+
+	mutex_lock(&smmu_domain->init_mutex);
+	if (smmu_domain->smmu)
+		ret = -EPERM;
+	else
+		smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
+	mutex_unlock(&smmu_domain->init_mutex);
+
+	return ret;
+}
+
 static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 				    enum iommu_attr attr, void *data)
 {
@@ -1530,17 +1542,6 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 	switch(domain->type) {
 	case IOMMU_DOMAIN_UNMANAGED:
 		switch (attr) {
-		case DOMAIN_ATTR_NESTING:
-			if (smmu_domain->smmu) {
-				ret = -EPERM;
-				goto out_unlock;
-			}
-
-			if (*(int *)data)
-				smmu_domain->stage = ARM_SMMU_DOMAIN_NESTED;
-			else
-				smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
-			break;
 		case DOMAIN_ATTR_IO_PGTABLE_CFG: {
 			struct io_pgtable_domain_attr *pgtbl_cfg = data;
 
@@ -1633,6 +1634,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.device_group		= arm_smmu_device_group,
 	.domain_get_attr	= arm_smmu_domain_get_attr,
 	.domain_set_attr	= arm_smmu_domain_set_attr,
+	.enable_nesting		= arm_smmu_enable_nesting,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ee0932307d646b..070ba76242e819 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5423,32 +5423,19 @@ static bool intel_iommu_is_attach_deferred(struct iommu_domain *domain,
 }
 
 static int
-intel_iommu_domain_set_attr(struct iommu_domain *domain,
-			    enum iommu_attr attr, void *data)
+intel_iommu_enable_nesting(struct iommu_domain *domain)
 {
 	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
 	unsigned long flags;
-	int ret = 0;
-
-	if (domain->type != IOMMU_DOMAIN_UNMANAGED)
-		return -EINVAL;
+	int ret = -ENODEV;
 
-	switch (attr) {
-	case DOMAIN_ATTR_NESTING:
-		spin_lock_irqsave(&device_domain_lock, flags);
-		if (nested_mode_support() &&
-		    list_empty(&dmar_domain->devices)) {
-			dmar_domain->flags |= DOMAIN_FLAG_NESTING_MODE;
-			dmar_domain->flags &= ~DOMAIN_FLAG_USE_FIRST_LEVEL;
-		} else {
-			ret = -ENODEV;
-		}
-		spin_unlock_irqrestore(&device_domain_lock, flags);
-		break;
-	default:
-		ret = -EINVAL;
-		break;
+	spin_lock_irqsave(&device_domain_lock, flags);
+	if (nested_mode_support() && list_empty(&dmar_domain->devices)) {
+		dmar_domain->flags |= DOMAIN_FLAG_NESTING_MODE;
+		dmar_domain->flags &= ~DOMAIN_FLAG_USE_FIRST_LEVEL;
+		ret = 0;
 	}
+	spin_unlock_irqrestore(&device_domain_lock, flags);
 
 	return ret;
 }
@@ -5577,7 +5564,7 @@ const struct iommu_ops intel_iommu_ops = {
 	.domain_alloc		= intel_iommu_domain_alloc,
 	.domain_free		= intel_iommu_domain_free,
 	.domain_get_attr        = intel_iommu_domain_get_attr,
-	.domain_set_attr	= intel_iommu_domain_set_attr,
+	.enable_nesting		= intel_iommu_enable_nesting,
 	.attach_dev		= intel_iommu_attach_device,
 	.detach_dev		= intel_iommu_detach_device,
 	.aux_attach_dev		= intel_iommu_aux_attach_device,
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 23daaea7883b75..58d1d11a8d5c10 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2690,6 +2690,16 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
 
+int iommu_enable_nesting(struct iommu_domain *domain)
+{
+	if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+		return -EINVAL;
+	if (!domain->ops->enable_nesting)
+		return -EINVAL;
+	return domain->ops->enable_nesting(domain);
+}
+EXPORT_SYMBOL_GPL(iommu_enable_nesting);
+
 void iommu_get_resv_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev->bus->iommu_ops;
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index ae6d72f17aee78..3c8048d78282ae 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2330,10 +2330,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	}
 
 	if (iommu->nesting) {
-		int attr = 1;
-
-		ret = iommu_domain_set_attr(domain->domain, DOMAIN_ATTR_NESTING,
-					    &attr);
+		ret = iommu_enable_nesting(domain->domain);
 		if (ret)
 			goto out_domain;
 	}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c15a8658daad64..670e7a3523f286 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -107,7 +107,6 @@ enum iommu_cap {
  */
 
 enum iommu_attr {
-	DOMAIN_ATTR_NESTING,	/* two stages of translation */
 	DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
 	DOMAIN_ATTR_IO_PGTABLE_CFG,
 	DOMAIN_ATTR_MAX,
@@ -196,6 +195,7 @@ struct iommu_iotlb_gather {
  * @device_group: find iommu group for a particular device
  * @domain_get_attr: Query domain attributes
  * @domain_set_attr: Change domain attributes
+ * @enable_nesting: Enable nesting
  * @get_resv_regions: Request list of reserved regions for a device
  * @put_resv_regions: Free list of reserved regions for a device
  * @apply_resv_region: Temporary helper call-back for iova reserved ranges
@@ -248,6 +248,7 @@ struct iommu_ops {
 			       enum iommu_attr attr, void *data);
 	int (*domain_set_attr)(struct iommu_domain *domain,
 			       enum iommu_attr attr, void *data);
+	int (*enable_nesting)(struct iommu_domain *domain);
 
 	/* Request/Free a list of reserved regions for a device */
 	void (*get_resv_regions)(struct device *dev, struct list_head *list);
@@ -495,6 +496,7 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
+int iommu_enable_nesting(struct iommu_domain *domain);
 
 extern int report_iommu_fault(struct iommu_domain *domain, struct device *dev,
 			      unsigned long iova, int flags);
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:55 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:55 +0200
Subject: [PATCH 19/20] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-20-hch@lst.de>

Use an explicit set_pgtable_quirks method instead that just passes
the actual quirk bitmask instead.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
Acked-by: Li Yang <leoyang.li at nxp.com>
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu.c   | 64 +++++--------------------
 drivers/iommu/arm/arm-smmu/arm-smmu.h   |  2 +-
 drivers/iommu/iommu.c                   | 11 +++++
 include/linux/io-pgtable.h              |  4 --
 include/linux/iommu.h                   | 12 ++++-
 6 files changed, 35 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0f184c3dd9d9ec..4a0b14dad93e2e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -188,10 +188,7 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
 
 void adreno_set_llc_attributes(struct iommu_domain *iommu)
 {
-	struct io_pgtable_domain_attr pgtbl_cfg;
-
-	pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
-	iommu_domain_set_attr(iommu, DOMAIN_ATTR_IO_PGTABLE_CFG, &pgtbl_cfg);
+	iommu_set_pgtable_quirks(iommu, IO_PGTABLE_QUIRK_ARM_OUTER_WBWA);
 }
 
 struct msm_gem_address_space *
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index f17c54a76ef6f1..3c6adcdb201bb8 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -770,8 +770,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
 			goto out_clear_smmu;
 	}
 
-	if (smmu_domain->pgtbl_cfg.quirks)
-		pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
+	if (smmu_domain->pgtbl_quirks)
+		pgtbl_cfg.quirks |= smmu_domain->pgtbl_quirks;
 
 	pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
 	if (!pgtbl_ops) {
@@ -1484,29 +1484,6 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 	return group;
 }
 
-static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr, void *data)
-{
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-
-	switch(domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		switch (attr) {
-		case DOMAIN_ATTR_IO_PGTABLE_CFG: {
-			struct io_pgtable_domain_attr *pgtbl_cfg = data;
-			*pgtbl_cfg = smmu_domain->pgtbl_cfg;
-
-			return 0;
-		}
-		default:
-			return -ENODEV;
-		}
-		break;
-	default:
-		return -EINVAL;
-	}
-}
-
 static int arm_smmu_enable_nesting(struct iommu_domain *domain)
 {
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
@@ -1522,37 +1499,19 @@ static int arm_smmu_enable_nesting(struct iommu_domain *domain)
 	return ret;
 }
 
-static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
-				    enum iommu_attr attr, void *data)
+static int arm_smmu_set_pgtable_quirks(struct iommu_domain *domain,
+		unsigned long quirks)
 {
-	int ret = 0;
 	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	int ret = 0;
 
 	mutex_lock(&smmu_domain->init_mutex);
-
-	switch(domain->type) {
-	case IOMMU_DOMAIN_UNMANAGED:
-		switch (attr) {
-		case DOMAIN_ATTR_IO_PGTABLE_CFG: {
-			struct io_pgtable_domain_attr *pgtbl_cfg = data;
-
-			if (smmu_domain->smmu) {
-				ret = -EPERM;
-				goto out_unlock;
-			}
-
-			smmu_domain->pgtbl_cfg = *pgtbl_cfg;
-			break;
-		}
-		default:
-			ret = -ENODEV;
-		}
-		break;
-	default:
-		ret = -EINVAL;
-	}
-out_unlock:
+	if (smmu_domain->smmu)
+		ret = -EPERM;
+	else
+		smmu_domain->pgtbl_quirks = quirks;
 	mutex_unlock(&smmu_domain->init_mutex);
+
 	return ret;
 }
 
@@ -1611,9 +1570,8 @@ static struct iommu_ops arm_smmu_ops = {
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
 	.device_group		= arm_smmu_device_group,
-	.domain_get_attr	= arm_smmu_domain_get_attr,
-	.domain_set_attr	= arm_smmu_domain_set_attr,
 	.enable_nesting		= arm_smmu_enable_nesting,
+	.set_pgtable_quirks	= arm_smmu_set_pgtable_quirks,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index d2a2d1bc58bad8..c31a59d35c64da 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -364,7 +364,7 @@ enum arm_smmu_domain_stage {
 struct arm_smmu_domain {
 	struct arm_smmu_device		*smmu;
 	struct io_pgtable_ops		*pgtbl_ops;
-	struct io_pgtable_domain_attr	pgtbl_cfg;
+	unsigned long			pgtbl_quirks;
 	const struct iommu_flush_ops	*flush_ops;
 	struct arm_smmu_cfg		cfg;
 	enum arm_smmu_domain_stage	stage;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d191e4a399785d..bf7dcd2fc08643 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2701,6 +2701,17 @@ int iommu_enable_nesting(struct iommu_domain *domain)
 }
 EXPORT_SYMBOL_GPL(iommu_enable_nesting);
 
+int iommu_set_pgtable_quirks(struct iommu_domain *domain,
+		unsigned long quirk)
+{
+	if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+		return -EINVAL;
+	if (!domain->ops->set_pgtable_quirks)
+		return -EINVAL;
+	return domain->ops->set_pgtable_quirks(domain, quirk);
+}
+EXPORT_SYMBOL_GPL(iommu_set_pgtable_quirks);
+
 void iommu_get_resv_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev->bus->iommu_ops;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a4c9ca2c31f10a..4d40dfa75b55fe 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -204,10 +204,6 @@ struct io_pgtable {
 
 #define io_pgtable_ops_to_pgtable(x) container_of((x), struct io_pgtable, ops)
 
-struct io_pgtable_domain_attr {
-	unsigned long quirks;
-};
-
 static inline void io_pgtable_tlb_flush_all(struct io_pgtable *iop)
 {
 	if (iop->cfg.tlb && iop->cfg.tlb->tlb_flush_all)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 4e1051dd8d9946..4280be90a27956 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -107,7 +107,6 @@ enum iommu_cap {
  */
 
 enum iommu_attr {
-	DOMAIN_ATTR_IO_PGTABLE_CFG,
 	DOMAIN_ATTR_MAX,
 };
 
@@ -195,6 +194,7 @@ struct iommu_iotlb_gather {
  * @domain_get_attr: Query domain attributes
  * @domain_set_attr: Change domain attributes
  * @enable_nesting: Enable nesting
+ * @set_pgtable_quirks: Set io page table quirks (IO_PGTABLE_QUIRK_*)
  * @get_resv_regions: Request list of reserved regions for a device
  * @put_resv_regions: Free list of reserved regions for a device
  * @apply_resv_region: Temporary helper call-back for iova reserved ranges
@@ -248,6 +248,8 @@ struct iommu_ops {
 	int (*domain_set_attr)(struct iommu_domain *domain,
 			       enum iommu_attr attr, void *data);
 	int (*enable_nesting)(struct iommu_domain *domain);
+	int (*set_pgtable_quirks)(struct iommu_domain *domain,
+				  unsigned long quirks);
 
 	/* Request/Free a list of reserved regions for a device */
 	void (*get_resv_regions)(struct device *dev, struct list_head *list);
@@ -496,6 +498,8 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 int iommu_enable_nesting(struct iommu_domain *domain);
+int iommu_set_pgtable_quirks(struct iommu_domain *domain,
+		unsigned long quirks);
 
 void iommu_set_dma_strict(bool val);
 bool iommu_get_dma_strict(struct iommu_domain *domain);
@@ -877,6 +881,12 @@ static inline int iommu_domain_set_attr(struct iommu_domain *domain,
 	return -EINVAL;
 }
 
+static inline int iommu_set_pgtable_quirks(struct iommu_domain *domain,
+		unsigned long quirks)
+{
+	return 0;
+}
+
 static inline int  iommu_device_register(struct iommu_device *iommu)
 {
 	return -ENODEV;
-- 
2.30.1



From hch at lst.de  Thu Apr  1 16:52:56 2021
From: hch at lst.de (Christoph Hellwig)
Date: Thu,  1 Apr 2021 17:52:56 +0200
Subject: [PATCH 20/20] iommu: remove iommu_domain_{get,set}_attr
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <20210401155256.298656-21-hch@lst.de>

Remove the now unused iommu attr infrastructure.

Signed-off-by: Christoph Hellwig <hch at lst.de>
Acked-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 26 --------------------------
 include/linux/iommu.h | 36 ------------------------------------
 2 files changed, 62 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index bf7dcd2fc08643..d19944733b9dac 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2665,32 +2665,6 @@ static int __init iommu_init(void)
 }
 core_initcall(iommu_init);
 
-int iommu_domain_get_attr(struct iommu_domain *domain,
-			  enum iommu_attr attr, void *data)
-{
-	if (!domain->ops->domain_get_attr)
-		return -EINVAL;
-	return domain->ops->domain_get_attr(domain, attr, data);
-}
-EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
-
-int iommu_domain_set_attr(struct iommu_domain *domain,
-			  enum iommu_attr attr, void *data)
-{
-	int ret = 0;
-
-	switch (attr) {
-	default:
-		if (domain->ops->domain_set_attr == NULL)
-			return -EINVAL;
-
-		ret = domain->ops->domain_set_attr(domain, attr, data);
-	}
-
-	return ret;
-}
-EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
-
 int iommu_enable_nesting(struct iommu_domain *domain)
 {
 	if (domain->type != IOMMU_DOMAIN_UNMANAGED)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 4280be90a27956..1a905446dc4ca1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -96,20 +96,6 @@ enum iommu_cap {
 	IOMMU_CAP_NOEXEC,		/* IOMMU_NOEXEC flag */
 };
 
-/*
- * Following constraints are specifc to FSL_PAMUV1:
- *  -aperture must be power of 2, and naturally aligned
- *  -number of windows must be power of 2, and address space size
- *   of each window is determined by aperture size / # of windows
- *  -the actual size of the mapped region of a window must be power
- *   of 2 starting with 4KB and physical address must be naturally
- *   aligned.
- */
-
-enum iommu_attr {
-	DOMAIN_ATTR_MAX,
-};
-
 /* These are the possible reserved region types */
 enum iommu_resv_type {
 	/* Memory regions which must be mapped 1:1 at all times */
@@ -191,8 +177,6 @@ struct iommu_iotlb_gather {
  * @probe_finalize: Do final setup work after the device is added to an IOMMU
  *                  group and attached to the groups domain
  * @device_group: find iommu group for a particular device
- * @domain_get_attr: Query domain attributes
- * @domain_set_attr: Change domain attributes
  * @enable_nesting: Enable nesting
  * @set_pgtable_quirks: Set io page table quirks (IO_PGTABLE_QUIRK_*)
  * @get_resv_regions: Request list of reserved regions for a device
@@ -243,10 +227,6 @@ struct iommu_ops {
 	void (*release_device)(struct device *dev);
 	void (*probe_finalize)(struct device *dev);
 	struct iommu_group *(*device_group)(struct device *dev);
-	int (*domain_get_attr)(struct iommu_domain *domain,
-			       enum iommu_attr attr, void *data);
-	int (*domain_set_attr)(struct iommu_domain *domain,
-			       enum iommu_attr attr, void *data);
 	int (*enable_nesting)(struct iommu_domain *domain);
 	int (*set_pgtable_quirks)(struct iommu_domain *domain,
 				  unsigned long quirks);
@@ -493,10 +473,6 @@ extern int iommu_page_response(struct device *dev,
 extern int iommu_group_id(struct iommu_group *group);
 extern struct iommu_domain *iommu_group_default_domain(struct iommu_group *);
 
-extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
-				 void *data);
-extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
-				 void *data);
 int iommu_enable_nesting(struct iommu_domain *domain);
 int iommu_set_pgtable_quirks(struct iommu_domain *domain,
 		unsigned long quirks);
@@ -869,18 +845,6 @@ static inline int iommu_group_id(struct iommu_group *group)
 	return -ENODEV;
 }
 
-static inline int iommu_domain_get_attr(struct iommu_domain *domain,
-					enum iommu_attr attr, void *data)
-{
-	return -EINVAL;
-}
-
-static inline int iommu_domain_set_attr(struct iommu_domain *domain,
-					enum iommu_attr attr, void *data)
-{
-	return -EINVAL;
-}
-
 static inline int iommu_set_pgtable_quirks(struct iommu_domain *domain,
 		unsigned long quirks)
 {
-- 
2.30.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:51 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:51 +0200
Subject: [PATCH v8 01/13] dt-bindings: mfd: Add 'nxp,
 imx8mq-vpu-ctrl' to syscon list
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-2-benjamin.gaignard@collabora.com>

Add 'nxp,imx8mq-vpu-ctrl' in the list of possible syscon.
It will used to access to the VPU control registers.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
version 8:
 - Add Lee ack

version 7:
 - Add Rob ack

 Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index f14ae6da0068..ae22c4730613 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -44,6 +44,7 @@ properties:
               - hisilicon,peri-subctrl
               - microchip,sparx5-cpu-syscon
               - mstar,msc313-pmsleep
+              - nxp,imx8mq-vpu-ctrl
               - rockchip,px30-qos
               - rockchip,rk3066-qos
               - rockchip,rk3288-qos
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:53 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:53 +0200
Subject: [PATCH v8 03/13] media: hantro: Use syscon instead of 'ctrl' register
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-4-benjamin.gaignard@collabora.com>

In order to be able to share the control hardware block between
VPUs use a syscon instead a ioremap it in the driver.
To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
phandle is not found look at 'ctrl' reg-name.
With the method it becomes useless to provide a list of register
names so remove it.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
version 7:
 - Add Philipp reviewed-by tag.
 - Change syscon phandle name.
 
version 5:
 - use syscon instead of VPU reset driver.
 - if DT doesn't provide syscon keep backward compatibilty by using
   'ctrl' reg-name.

 drivers/staging/media/hantro/hantro.h       |  5 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
 2 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 6c1b888abe75..37b9ce04bd4e 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -13,6 +13,7 @@
 #define HANTRO_H_
 
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 #include <linux/videodev2.h>
 #include <linux/wait.h>
 #include <linux/clk.h>
@@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
  * @reg_bases:		Mapped addresses of VPU registers.
  * @enc_base:		Mapped address of VPU encoder register for convenience.
  * @dec_base:		Mapped address of VPU decoder register for convenience.
- * @ctrl_base:		Mapped address of VPU control block.
+ * @ctrl_base:		Regmap of VPU control block.
  * @vpu_mutex:		Mutex to synchronize V4L2 calls.
  * @irqlock:		Spinlock to synchronize access to data structures
  *			shared with interrupt handlers.
@@ -186,7 +187,7 @@ struct hantro_dev {
 	void __iomem **reg_bases;
 	void __iomem *enc_base;
 	void __iomem *dec_base;
-	void __iomem *ctrl_base;
+	struct regmap *ctrl_base;
 
 	struct mutex vpu_mutex;	/* video_device lock */
 	spinlock_t irqlock;
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index c222de075ef4..8d0c3425234b 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -7,6 +7,7 @@
 
 #include <linux/clk.h>
 #include <linux/delay.h>
+#include <linux/mfd/syscon.h>
 
 #include "hantro.h"
 #include "hantro_jpeg.h"
@@ -24,30 +25,28 @@
 #define CTRL_G1_PP_FUSE		0x0c
 #define CTRL_G2_DEC_FUSE	0x10
 
+static const struct regmap_config ctrl_regmap_ctrl = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 0x14,
+};
+
 static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
 {
-	u32 val;
-
 	/* Assert */
-	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
-	val &= ~reset_bits;
-	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
+	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
 
 	udelay(2);
 
 	/* Release */
-	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
-	val |= reset_bits;
-	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
+	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
+			   reset_bits, reset_bits);
 }
 
 static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
 {
-	u32 val;
-
-	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
-	val |= clock_bits;
-	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
+	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
+			   clock_bits, clock_bits);
 }
 
 static int imx8mq_runtime_resume(struct hantro_dev *vpu)
@@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
 	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
 
 	/* Set values of the fuse registers */
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
+	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
+	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
+	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
 
 	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
 
@@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
-	vpu->dec_base = vpu->reg_bases[0];
-	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
+	struct device_node *np = vpu->dev->of_node;
+
+	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
+	if (IS_ERR(vpu->ctrl_base)) {
+		struct resource *res;
+		void __iomem *ctrl;
+
+		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
+		ctrl = devm_ioremap_resource(vpu->dev, res);
+		if (IS_ERR(ctrl))
+			return PTR_ERR(ctrl);
+
+		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
+		if (IS_ERR(vpu->ctrl_base))
+			return PTR_ERR(vpu->ctrl_base);
+	}
 
 	return 0;
 }
@@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
 };
 
 static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
-static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
 
 const struct hantro_variant imx8mq_vpu_variant = {
 	.dec_fmts = imx8m_vpu_dec_fmts,
@@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
 	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
 	.clk_names = imx8mq_clk_names,
 	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
-	.reg_names = imx8mq_reg_names,
-	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
 };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:52 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:52 +0200
Subject: [PATCH v8 02/13] dt-bindings: media: nxp,
 imx8mq-vpu: Update the bindings for G2 support
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-3-benjamin.gaignard@collabora.com>

Introducing G2 hevc video decoder lead to modify the bindings to allow
to get one node per VPUs.
VPUs share one hardware control block which is provided as a phandle on
an syscon.
Each node got now one reg and one interrupt.
Add a compatible for G2 hardware block: nxp,imx8mq-vpu-g2.

To be compatible with older DT the driver is still capable to use 'ctrl'
reg-name even if it is deprecated now.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
version 7:
- Add Rob and Philipp reviewed-by tag
- Change syscon phandle name to nxp,imx8m-vpu-ctrl (remove 'q' to be
  usable for iMX8MM too)

version 5:
- This version doesn't break the backward compatibilty between kernel
  and DT.

 .../bindings/media/nxp,imx8mq-vpu.yaml        | 53 ++++++++++++-------
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
index 762be3f96ce9..18e7d40a5f24 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
@@ -15,22 +15,18 @@ description:
 
 properties:
   compatible:
-    const: nxp,imx8mq-vpu
+    oneOf:
+      - const: nxp,imx8mq-vpu
+      - const: nxp,imx8mq-vpu-g2
 
   reg:
-    maxItems: 3
-
-  reg-names:
-    items:
-      - const: g1
-      - const: g2
-      - const: ctrl
+    maxItems: 1
 
   interrupts:
-    maxItems: 2
+    maxItems: 1
 
   interrupt-names:
-    items:
+    oneOf:
       - const: g1
       - const: g2
 
@@ -46,14 +42,18 @@ properties:
   power-domains:
     maxItems: 1
 
+  nxp,imx8m-vpu-ctrl:
+    description: Specifies a phandle to syscon VPU hardware control block
+    $ref: "/schemas/types.yaml#/definitions/phandle"
+
 required:
   - compatible
   - reg
-  - reg-names
   - interrupts
   - interrupt-names
   - clocks
   - clock-names
+  - nxp,imx8m-vpu-ctrl
 
 additionalProperties: false
 
@@ -62,18 +62,33 @@ examples:
         #include <dt-bindings/clock/imx8mq-clock.h>
         #include <dt-bindings/interrupt-controller/arm-gic.h>
 
-        vpu: video-codec at 38300000 {
+        vpu_ctrl: syscon at 38320000 {
+                 compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
+                 reg = <0x38320000 0x10000>;
+        };
+
+        vpu_g1: video-codec at 38300000 {
                 compatible = "nxp,imx8mq-vpu";
-                reg = <0x38300000 0x10000>,
-                      <0x38310000 0x10000>,
-                      <0x38320000 0x10000>;
-                reg-names = "g1", "g2", "ctrl";
-                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
-                             <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
-                interrupt-names = "g1", "g2";
+                reg = <0x38300000 0x10000>;
+                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "g1";
+                clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
+                         <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
+                         <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
+                clock-names = "g1", "g2", "bus";
+                power-domains = <&pgc_vpu>;
+                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
+        };
+
+        vpu_g2: video-codec at 38310000 {
+                compatible = "nxp,imx8mq-vpu-g2";
+                reg = <0x38300000 0x10000>;
+                interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "g2";
                 clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
                          <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
                          <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
                 clock-names = "g1", "g2", "bus";
                 power-domains = <&pgc_vpu>;
+                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
         };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:50 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:50 +0200
Subject: [PATCH v8 00/13] Add HANTRO G2/HEVC decoder support for IMX8MQ
Message-ID: <20210401160003.88803-1-benjamin.gaignard@collabora.com>

The IMX8MQ got two VPUs but until now only G1 has been enabled.
This series aim to add the second VPU (aka G2) and provide basic 
HEVC decoding support.

To be able to decode HEVC it is needed to add/update some of the
structures in the uapi. In addition of them one HANTRO dedicated
control is required to inform the driver of the numbre of bits to skip
at the beginning of the slice header.
The hardware require to allocate few auxiliary buffers to store the
references frame or tile size data.

The driver has been tested with fluster test suite stream.
For example with this command: ./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0

Finally the both VPUs will have a node the device-tree and be
independent from v4l2 point of view.

A branch with all the dev is available here:
https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/commits/upstream_g2_v8

version 8:
 - Add reviewed-by and ack-by tags 
 - Fix the warnings reported by kernel test robot
 - Only patch 9 (adding dedicated control), patch 11 (HEVC support) and
   patch 13 (DT changes) are still missing of review/ack tag.

version 7:
 - Remove 'q' from syscon phandle name to make usable for iMX8MM too.
   Update the bindings documentation.
 - Add review/ack tags.
 - Rebase on top of media_tree/master
 - Be more accurate when computing the size of the memory needed motion
   vectors.
 - Explain why the all clocks need to set in the both DT node.

version 6:
 - fix the errors reported by kernel test robot

version 5:
 - use syscon instead of VPU reset driver.
 - Do not break kernel/DT backward compatibility.
 - Add documentation for dedicated Hantro control.
 - Fix the remarks done by Ezequeil (typo, comments, unused function)
 - Run v4l2-compliance without errors (see below).
 - Do not add field to distinguish version, check postproc reg instead

version 4:
- Split the changes in hevc controls in 2 commits to make them easier to
  review.
- Change hantro_codec_ops run() prototype to return errors   
- Hantro v4l2 dedicated control is now only an integer
- rebase on top of VPU reset changes posted here:
  https://www.spinics.net/lists/arm-kernel/msg878440.html
- Various fix from previous remarks
- Limit the modifications in API to what the driver needs

version 3:
- Fix typo in Hantro v4l2 dedicated control
- Add documentation for the new structures and fields
- Rebased on top of media_tree for-linus-5.12-rc1 tag

version 2:
- remove all change related to scaling
- squash commits to a coherent split
- be more verbose about the added fields
- fix the comments done by Ezequiel about dma_alloc_coherent usage
- fix Dan's comments about control copy, reverse the test logic
in tile_buffer_reallocate, rework some goto and return cases.
- be more verbose about why I change the bindings
- remove all sign-off expect mime since it is confusing
- remove useless clocks in VPUs nodes

./v4l2-compliance -m 1 
v4l2-compliance 1.21.0-4705, 64 bits, 64-bit time_t
v4l2-compliance SHA: 733f7a54f79d 2021-02-03 08:25:49

Compliance test for hantro-vpu device /dev/media1:

Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0

Required ioctls:
	test MEDIA_IOC_DEVICE_INFO: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/media1 open: OK
	test MEDIA_IOC_DEVICE_INFO: OK
	test for unlimited opens: OK

Media Controller ioctls:
	test MEDIA_IOC_G_TOPOLOGY: OK
	Entities: 3 Interfaces: 1 Pads: 4 Links: 4
	test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
	test MEDIA_IOC_SETUP_LINK: OK

Total for hantro-vpu device /dev/media1: 8, Succeeded: 8, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for hantro-vpu device /dev/video1:

Driver Info:
	Driver name      : hantro-vpu
	Card type        : nxp,imx8mq-vpu-g2-dec
	Bus info         : platform: hantro-vpu
	Driver version   : 5.11.0
	Capabilities     : 0x84204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0
Interface Info:
	ID               : 0x0300000c
	Type             : V4L Video
Entity Info:
	ID               : 0x00000001 (1)
	Name             : nxp,imx8mq-vpu-g2-dec-source
	Function         : V4L2 I/O
	Pad 0x01000002   : 0: Source
	  Link 0x02000008: to remote pad 0x1000004 of entity 'nxp,imx8mq-vpu-g2-dec-proc': Data, Enabled, Immutable

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video1 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 8 Private Controls: 1

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK

Total for hantro-vpu device /dev/video1: 46, Succeeded: 46, Failed: 0, Warnings: 0

Grand Total for hantro-vpu device /dev/media1: 54, Succeeded: 54, Failed: 0, Warnings: 0

Benjamin
 
Benjamin Gaignard (13):
  dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to syscon list
  dt-bindings: media: nxp,imx8mq-vpu: Update the bindings for G2 support
  media: hantro: Use syscon instead of 'ctrl' register
  media: hevc: Add fields and flags for hevc PPS
  media: hevc: Add decode params control
  media: hantro: change hantro_codec_ops run prototype to return errors
  media: hantro: Define HEVC codec profiles and supported features
  media: hantro: Only use postproc when post processed formats are
    defined
  media: uapi: Add a control for HANTRO driver
  media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
  media: hantro: Introduce G2/HEVC decoder
  media: hantro: IMX8M: add variant for G2/HEVC codec
  arm64: dts: imx8mq: Add node to G2 hardware

 .../bindings/media/nxp,imx8mq-vpu.yaml        |  53 +-
 .../devicetree/bindings/mfd/syscon.yaml       |   1 +
 .../userspace-api/media/drivers/hantro.rst    |  14 +
 .../userspace-api/media/drivers/index.rst     |   1 +
 .../media/v4l/ext-ctrls-codec.rst             | 108 +++-
 .../media/v4l/vidioc-queryctrl.rst            |   6 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  43 +-
 drivers/media/v4l2-core/v4l2-ctrls.c          |  26 +-
 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |  18 +-
 drivers/staging/media/hantro/hantro_drv.c     |  99 ++-
 .../staging/media/hantro/hantro_g1_h264_dec.c |  10 +-
 .../media/hantro/hantro_g1_mpeg2_dec.c        |   4 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |   6 +-
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |   4 +-
 drivers/staging/media/hantro/hantro_hevc.c    | 325 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  69 +-
 .../staging/media/hantro/hantro_postproc.c    |  14 +
 drivers/staging/media/hantro/hantro_v4l2.c    |   5 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c   | 128 +++-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |   4 +-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |   4 +-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |   6 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   6 +
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  |  12 +-
 include/media/hevc-ctrls.h                    |  33 +-
 include/uapi/linux/v4l2-controls.h            |  13 +
 31 files changed, 1682 insertions(+), 120 deletions(-)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:54 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:54 +0200
Subject: [PATCH v8 04/13] media: hevc: Add fields and flags for hevc PPS
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-5-benjamin.gaignard@collabora.com>

Add fields and flags as they are defined in
7.4.3.3.1 "General picture parameter set RBSP semantics of the
H.265 ITU specification.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

 .../userspace-api/media/v4l/ext-ctrls-codec.rst    | 14 ++++++++++++++
 include/media/hevc-ctrls.h                         |  4 ++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 188aef8e40d0..92314aec655a 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -2967,6 +2967,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``num_extra_slice_header_bits``
       -
+    * - __u8
+      - ``num_ref_idx_l0_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l0_active_minus1
+    * - __u8
+      - ``num_ref_idx_l1_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l1_active_minus1
     * - __s8
       - ``init_qp_minus26``
       -
@@ -3077,6 +3083,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT``
       - 0x00040000
       -
+    * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
+      - 0x00080000
+      - Specifies the presence of deblocking filter control syntax elements in
+        the PPS
+    * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING``
+      - 0x00100000
+      - Specifies that tile column boundaries and likewise tile row boundaries
+        are distributed uniformly across the picture
 
 .. raw:: latex
 
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index b4cb2ef02f17..003f819ecb26 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -100,10 +100,14 @@ struct v4l2_ctrl_hevc_sps {
 #define V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER	(1ULL << 16)
 #define V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT		(1ULL << 17)
 #define V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT (1ULL << 18)
+#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT	(1ULL << 19)
+#define V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING			(1ULL << 20)
 
 struct v4l2_ctrl_hevc_pps {
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture parameter set */
 	__u8	num_extra_slice_header_bits;
+	__u8	num_ref_idx_l0_default_active_minus1;
+	__u8	num_ref_idx_l1_default_active_minus1;
 	__s8	init_qp_minus26;
 	__u8	diff_cu_qp_delta_depth;
 	__s8	pps_cb_qp_offset;
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:59 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:59 +0200
Subject: [PATCH v8 09/13] media: uapi: Add a control for HANTRO driver
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-10-benjamin.gaignard@collabora.com>

The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific requirement so create a dedicated control
that this purpose.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 5:
 - Be even more verbose in control documentation.
 - Do not create class for the control.
version 4:
- The control is now an integer which is enough to provide the numbers
  of bits to skip.
version 3:
- Fix typo in field name

 .../userspace-api/media/drivers/hantro.rst         | 14 ++++++++++++++
 .../userspace-api/media/drivers/index.rst          |  1 +
 include/uapi/linux/v4l2-controls.h                 | 13 +++++++++++++
 3 files changed, 28 insertions(+)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst

diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst
new file mode 100644
index 000000000000..78dcd2a44a03
--- /dev/null
+++ b/Documentation/userspace-api/media/drivers/hantro.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Hantro video decoder driver
+===========================
+
+The Hantro video decoder driver implements the following driver-specific controls:
+
+``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
+    Specifies to Hantro HEVC video decoder driver the number of data (in bits) to
+    skip in the slice segment header.
+    If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+    to before syntax element "slice_temporal_mvp_enabled_flag".
+    If IDR, the skipped bits are just "pic_output_flag"
+    (separate_colour_plane_flag is not supported).
diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
index 1a9038f5f9fa..12e3c512d718 100644
--- a/Documentation/userspace-api/media/drivers/index.rst
+++ b/Documentation/userspace-api/media/drivers/index.rst
@@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux.
 
 	ccs
 	cx2341x-uapi
+        hantro
 	imx-uapi
 	max2175
 	meye-uapi
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index f3376aafea65..1dfb874b6272 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -869,6 +869,19 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
 #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC		(V4L2_CID_CODEC_MFC51_BASE+53)
 #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P		(V4L2_CID_CODEC_MFC51_BASE+54)
 
+/*  MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */
+#define V4L2_CID_CODEC_HANTRO_BASE				(V4L2_CTRL_CLASS_CODEC | 0x1200)
+/*
+ * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
+ * the number of data (in bits) to skip in the
+ * slice segment header.
+ * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+ * to before syntax element "slice_temporal_mvp_enabled_flag".
+ * If IDR, the skipped bits are just "pic_output_flag"
+ * (separate_colour_plane_flag is not supported).
+ */
+#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP	(V4L2_CID_CODEC_HANTRO_BASE + 0)
+
 /*  Camera class control IDs */
 
 #define V4L2_CID_CAMERA_CLASS_BASE	(V4L2_CTRL_CLASS_CAMERA | 0x900)
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:55 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:55 +0200
Subject: [PATCH v8 05/13] media: hevc: Add decode params control
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-6-benjamin.gaignard@collabora.com>

Add decode params control and it associated structure to regroup
all the information that are needed to decode a reference frame as
it is describe in ITU-T Rec. H.265 section "8.3.2 Decoding process
for reference picture set".

Adapt Cedrus driver to these changes.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

version 7:
 - rebased on top of media_tree/master branch

version 6:
 - fix compilation errors

 .../media/v4l/ext-ctrls-codec.rst             | 94 +++++++++++++++----
 .../media/v4l/vidioc-queryctrl.rst            |  6 ++
 drivers/media/v4l2-core/v4l2-ctrls.c          | 26 +++--
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  6 ++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 12 ++-
 include/media/hevc-ctrls.h                    | 29 ++++--
 8 files changed, 137 insertions(+), 39 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 92314aec655a..7552869687f7 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3181,9 +3181,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``pic_struct``
       -
-    * - __u8
-      - ``num_active_dpb_entries``
-      - The number of entries in ``dpb``.
     * - __u8
       - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L0 reference elements as indices in the DPB.
@@ -3191,22 +3188,8 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
       - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L1 reference elements as indices in the DPB.
     * - __u8
-      - ``num_rps_poc_st_curr_before``
-      - The number of reference pictures in the short-term set that come before
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_st_curr_after``
-      - The number of reference pictures in the short-term set that come after
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_lt_curr``
-      - The number of reference pictures in the long-term set.
-    * - __u8
-      - ``padding[7]``
+      - ``padding``
       - Applications and drivers must set this to zero.
-    * - struct :c:type:`v4l2_hevc_dpb_entry`
-      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
-      - The decoded picture buffer, for meta-data about reference frames.
     * - struct :c:type:`v4l2_hevc_pred_weight_table`
       - ``pred_weight_table``
       - The prediction weight coefficients for inter-picture prediction.
@@ -3441,3 +3424,78 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     so this has to come from client.
     This is applicable to H264 and valid Range is from 0 to 63.
     Source Rec. ITU-T H.264 (06/2019); G.7.4.1.1, G.8.8.1.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)``
+    Specifies various decode parameters, especially the references picture order
+    count (POC) for all the lists (short, long, before, current, after) and the
+    number of entries for each of them.
+    These parameters are defined according to :ref:`hevc`.
+    They are described in section 8.3 "Slice decoding process" of the
+    specification.
+
+.. c:type:: v4l2_ctrl_hevc_decode_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_hevc_decode_params
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - __s32
+      - ``pic_order_cnt_val``
+      - PicOrderCntVal as described in section 8.3.1 "Decoding process
+        for picture order count" of the specification.
+    * - __u8
+      - ``num_active_dpb_entries``
+      - The number of entries in ``dpb``.
+    * - struct :c:type:`v4l2_hevc_dpb_entry`
+      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - The decoded picture buffer, for meta-data about reference frames.
+    * - __u8
+      - ``num_poc_st_curr_before``
+      - The number of reference pictures in the short-term set that come before
+        the current frame.
+    * - __u8
+      - ``num_poc_st_curr_after``
+      - The number of reference pictures in the short-term set that come after
+        the current frame.
+    * - __u8
+      - ``num_poc_lt_curr``
+      - The number of reference pictures in the long-term set.
+    * - __u8
+      - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocLtCurr as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u64
+      - ``flags``
+      - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>`
+
+.. _hevc_decode_params_flags:
+
+``Decode Parameters Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC``
+      - 0x00000001
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC``
+      - 0x00000002
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR``
+      - 0x00000004
+      -
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index 8a285daedc6a..cf8f94693c39 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -495,6 +495,12 @@ See also the examples in :ref:`control`.
       - n/a
       - A struct :c:type:`v4l2_ctrl_vp8_frame`, containing VP8
 	frame parameters for stateless video decoders.
+    * - ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``
+      - n/a
+      - n/a
+      - n/a
+      - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC
+	decoding parameters for stateless video decoders.
 
 .. raw:: latex
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 39038c6ad8fb..8c1a98ed4ca4 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1037,6 +1037,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_HEVC_SPS:			return "HEVC Sequence Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_PPS:			return "HEVC Picture Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:		return "HEVC Slice Parameters";
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:		return "HEVC Decode Parameters";
 	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:		return "HEVC Decode Mode";
 	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:		return "HEVC Start Code";
 
@@ -1496,6 +1497,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
 		*type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
 		break;
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
+		*type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
+		break;
 	case V4L2_CID_UNIT_CELL_SIZE:
 		*type = V4L2_CTRL_TYPE_AREA;
 		*flags |= V4L2_CTRL_FLAG_READ_ONLY;
@@ -1852,6 +1856,7 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 	struct v4l2_ctrl_hevc_sps *p_hevc_sps;
 	struct v4l2_ctrl_hevc_pps *p_hevc_pps;
 	struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
+	struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;
 	struct v4l2_area *area;
 	void *p = ptr.p + idx * ctrl->elem_size;
 	unsigned int i;
@@ -2127,23 +2132,27 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 		zero_padding(*p_hevc_pps);
 		break;
 
-	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
-		p_hevc_slice_params = p;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		p_hevc_decode_params = p;
 
-		if (p_hevc_slice_params->num_active_dpb_entries >
+		if (p_hevc_decode_params->num_active_dpb_entries >
 		    V4L2_HEVC_DPB_ENTRIES_NUM_MAX)
 			return -EINVAL;
 
-		zero_padding(p_hevc_slice_params->pred_weight_table);
-
-		for (i = 0; i < p_hevc_slice_params->num_active_dpb_entries;
+		for (i = 0; i < p_hevc_decode_params->num_active_dpb_entries;
 		     i++) {
 			struct v4l2_hevc_dpb_entry *dpb_entry =
-				&p_hevc_slice_params->dpb[i];
+				&p_hevc_decode_params->dpb[i];
 
 			zero_padding(*dpb_entry);
 		}
 
+		break;
+
+	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
+		p_hevc_slice_params = p;
+
+		zero_padding(p_hevc_slice_params->pred_weight_table);
 		zero_padding(*p_hevc_slice_params);
 		break;
 
@@ -2840,6 +2849,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
 	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
 		elem_size = sizeof(struct v4l2_ctrl_hevc_slice_params);
 		break;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		elem_size = sizeof(struct v4l2_ctrl_hevc_decode_params);
+		break;
 	case V4L2_CTRL_TYPE_AREA:
 		elem_size = sizeof(struct v4l2_area);
 		break;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 92812d1a39d4..6f095ae53818 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -151,6 +151,12 @@ static const struct cedrus_control cedrus_controls[] = {
 		},
 		.codec		= CEDRUS_CODEC_VP8,
 	},
+	{
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
+		.codec		= CEDRUS_CODEC_H265,
+	},
 };
 
 #define CEDRUS_CONTROLS_COUNT	ARRAY_SIZE(cedrus_controls)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 15f147dad4cb..930922bd4e46 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -76,6 +76,7 @@ struct cedrus_h265_run {
 	const struct v4l2_ctrl_hevc_sps			*sps;
 	const struct v4l2_ctrl_hevc_pps			*pps;
 	const struct v4l2_ctrl_hevc_slice_params	*slice_params;
+	const struct v4l2_ctrl_hevc_decode_params	*decode_params;
 };
 
 struct cedrus_vp8_run {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index d696b3ec70c0..8a7e44f92812 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -68,6 +68,8 @@ void cedrus_device_run(void *priv)
 			V4L2_CID_MPEG_VIDEO_HEVC_PPS);
 		run.h265.slice_params = cedrus_find_control_data(ctx,
 			V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
+		run.h265.decode_params = cedrus_find_control_data(ctx,
+			V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
 		break;
 
 	case V4L2_PIX_FMT_VP8_FRAME:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
index ce497d0197df..397a4ba5df4c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
@@ -245,6 +245,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	const struct v4l2_ctrl_hevc_sps *sps;
 	const struct v4l2_ctrl_hevc_pps *pps;
 	const struct v4l2_ctrl_hevc_slice_params *slice_params;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
 	const struct v4l2_hevc_pred_weight_table *pred_weight_table;
 	dma_addr_t src_buf_addr;
 	dma_addr_t src_buf_end_addr;
@@ -256,6 +257,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	sps = run->h265.sps;
 	pps = run->h265.pps;
 	slice_params = run->h265.slice_params;
+	decode_params = run->h265.decode_params;
 	pred_weight_table = &slice_params->pred_weight_table;
 
 	/* MV column buffer size and allocation. */
@@ -487,7 +489,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	reg = VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_TC_OFFSET_DIV2(slice_params->slice_tc_offset_div2) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_BETA_OFFSET_DIV2(slice_params->slice_beta_offset_div2) |
-	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(slice_params->num_rps_poc_st_curr_after == 0) |
+	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(decode_params->num_poc_st_curr_after == 0) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CR_QP_OFFSET(slice_params->slice_cr_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CB_QP_OFFSET(slice_params->slice_cb_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_QP_DELTA(slice_params->slice_qp_delta);
@@ -527,8 +529,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	cedrus_write(dev, VE_DEC_H265_NEIGHBOR_INFO_ADDR, reg);
 
 	/* Write decoded picture buffer in pic list. */
-	cedrus_h265_frame_info_write_dpb(ctx, slice_params->dpb,
-					 slice_params->num_active_dpb_entries);
+	cedrus_h265_frame_info_write_dpb(ctx, decode_params->dpb,
+					 decode_params->num_active_dpb_entries);
 
 	/* Output frame. */
 
@@ -545,7 +547,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 0 (for P/B frames). */
 	if (slice_params->slice_type != V4L2_HEVC_SLICE_TYPE_I) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l0,
 					       slice_params->num_ref_idx_l0_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST0);
@@ -564,7 +566,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 1 (for B frames). */
 	if (slice_params->slice_type == V4L2_HEVC_SLICE_TYPE_B) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l1,
 					       slice_params->num_ref_idx_l1_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST1);
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 003f819ecb26..8e0109eea454 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -19,6 +19,7 @@
 #define V4L2_CID_MPEG_VIDEO_HEVC_SPS		(V4L2_CID_CODEC_BASE + 1008)
 #define V4L2_CID_MPEG_VIDEO_HEVC_PPS		(V4L2_CID_CODEC_BASE + 1009)
 #define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS	(V4L2_CID_CODEC_BASE + 1010)
+#define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_BASE + 1012)
 #define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE	(V4L2_CID_CODEC_BASE + 1015)
 #define V4L2_CID_MPEG_VIDEO_HEVC_START_CODE	(V4L2_CID_CODEC_BASE + 1016)
 
@@ -26,6 +27,7 @@
 #define V4L2_CTRL_TYPE_HEVC_SPS 0x0120
 #define V4L2_CTRL_TYPE_HEVC_PPS 0x0121
 #define V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS 0x0122
+#define V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS 0x0124
 
 enum v4l2_mpeg_video_hevc_decode_mode {
 	V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
@@ -194,18 +196,10 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u8	pic_struct;
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	__u8	num_active_dpb_entries;
 	__u8	ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 	__u8	ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 
-	__u8	num_rps_poc_st_curr_before;
-	__u8	num_rps_poc_st_curr_after;
-	__u8	num_rps_poc_lt_curr;
-
-	__u8	padding;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	padding[5];
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
 	struct v4l2_hevc_pred_weight_table pred_weight_table;
@@ -213,4 +207,21 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u64	flags;
 };
 
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC		0x1
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC		0x2
+#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR  0x4
+
+struct v4l2_ctrl_hevc_decode_params {
+	__s32	pic_order_cnt_val;
+	__u8	num_active_dpb_entries;
+	struct	v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	num_poc_st_curr_before;
+	__u8	num_poc_st_curr_after;
+	__u8	num_poc_lt_curr;
+	__u8	poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u64	flags;
+};
+
 #endif
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 17:00:03 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 18:00:03 +0200
Subject: [PATCH v8 13/13] arm64: dts: imx8mq: Add node to G2 hardware
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-14-benjamin.gaignard@collabora.com>

Split VPU node in two: one for G1 and one for G2 since they are
different hardware blocks.
Add syscon for hardware control block.
Remove reg-names property that is useless.
Each VPU node only need one interrupt.
Change G2 assigned clock to match to the specifications.
In the both nodes all the clocks need to assigned to make
sure that control block will be correctly clocked even if
only one device node is enabled.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 7:
 - use nxp,imx8m-vpu-ctrl as phandle syscon property name

version 5:
 - use syscon instead of VPU reset

 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 43 ++++++++++++++++++-----
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 17c449e12c2e..65158414d255 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1329,15 +1329,16 @@ usb3_phy1: usb-phy at 382f0040 {
 			status = "disabled";
 		};
 
-		vpu: video-codec at 38300000 {
+		vpu_ctrl: syscon at 38320000 {
+			compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
+			reg = <0x38320000 0x10000>;
+		};
+
+		vpu_g1: video-codec at 38300000 {
 			compatible = "nxp,imx8mq-vpu";
-			reg = <0x38300000 0x10000>,
-			      <0x38310000 0x10000>,
-			      <0x38320000 0x10000>;
-			reg-names = "g1", "g2", "ctrl";
-			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "g1", "g2";
+			reg = <0x38300000 0x10000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "g1";
 			clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
 				 <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
 				 <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
@@ -1350,9 +1351,33 @@ vpu: video-codec at 38300000 {
 						 <&clk IMX8MQ_VPU_PLL_OUT>,
 						 <&clk IMX8MQ_SYS1_PLL_800M>,
 						 <&clk IMX8MQ_VPU_PLL>;
-			assigned-clock-rates = <600000000>, <600000000>,
+			assigned-clock-rates = <600000000>, <300000000>,
+					       <800000000>, <0>;
+			power-domains = <&pgc_vpu>;
+			nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
+		};
+
+		vpu_g2: video-codec at 38310000 {
+			compatible = "nxp,imx8mq-vpu-g2";
+			reg = <0x38310000 0x10000>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "g2";
+			clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
+				 <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
+				 <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
+			clock-names = "g1", "g2",  "bus";
+			assigned-clocks = <&clk IMX8MQ_CLK_VPU_G1>,
+					  <&clk IMX8MQ_CLK_VPU_G2>,
+					  <&clk IMX8MQ_CLK_VPU_BUS>,
+					  <&clk IMX8MQ_VPU_PLL_BYPASS>;
+			assigned-clock-parents = <&clk IMX8MQ_VPU_PLL_OUT>,
+						 <&clk IMX8MQ_VPU_PLL_OUT>,
+						 <&clk IMX8MQ_SYS1_PLL_800M>,
+						 <&clk IMX8MQ_VPU_PLL>;
+			assigned-clock-rates = <600000000>, <300000000>,
 					       <800000000>, <0>;
 			power-domains = <&pgc_vpu>;
+			nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
 		};
 
 		pcie0: pcie at 33800000 {
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:58 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:58 +0200
Subject: [PATCH v8 08/13] media: hantro: Only use postproc when post processed
 formats are defined
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-9-benjamin.gaignard@collabora.com>

If the variant doesn't offert postprocessed formats make sure it will
be ok.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

 drivers/staging/media/hantro/hantro.h          |  8 ++------
 drivers/staging/media/hantro/hantro_postproc.c | 14 ++++++++++++++
 drivers/staging/media/hantro/hantro_v4l2.c     |  4 +++-
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index edb4561a6887..7a5ad93466c8 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -414,12 +414,8 @@ hantro_get_dst_buf(struct hantro_ctx *ctx)
 	return v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 }
 
-static inline bool
-hantro_needs_postproc(const struct hantro_ctx *ctx,
-		      const struct hantro_fmt *fmt)
-{
-	return !ctx->is_encoder && fmt->fourcc != V4L2_PIX_FMT_NV12;
-}
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt);
 
 static inline dma_addr_t
 hantro_get_dec_buf_addr(struct hantro_ctx *ctx, struct vb2_buffer *vb)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 6d2a8f2a8f0b..ed8916c950a4 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -50,6 +50,20 @@ const struct hantro_postproc_regs hantro_g1_postproc_regs = {
 	.display_width = {G1_REG_PP_DISPLAY_WIDTH, 0, 0xfff},
 };
 
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder)
+		return false;
+
+	if (!vpu->variant->postproc_fmts)
+		return false;
+
+	return fmt->fourcc != V4L2_PIX_FMT_NV12;
+}
+
 void hantro_postproc_enable(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1bc118e375a1..77d7fe62ce81 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -55,7 +55,9 @@ static const struct hantro_fmt *
 hantro_get_postproc_formats(const struct hantro_ctx *ctx,
 			    unsigned int *num_fmts)
 {
-	if (ctx->is_encoder) {
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder || !vpu->variant->postproc_fmts) {
 		*num_fmts = 0;
 		return NULL;
 	}
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 17:00:02 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 18:00:02 +0200
Subject: [PATCH v8 12/13] media: hantro: IMX8M: add variant for G2/HEVC codec
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-13-benjamin.gaignard@collabora.com>

Add variant to IMX8M to enable G2/HEVC codec.
Define the capabilities for the hardware up to 3840x2160.
G2 doesn't have postprocessor, use the same clocks and got it
own interruption.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - Add Ezequiel Reviewed-by tag.

version 7:
 - Add Philipp Reviewed-by tag.

version 5:
 - remove useless postproc fields for G2

version 2:
- remove useless clocks

 drivers/staging/media/hantro/hantro_drv.c   |  1 +
 drivers/staging/media/hantro/hantro_hw.h    |  1 +
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 76 ++++++++++++++++++++-
 3 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 33b8bd38eac1..ed380a8bef93 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -574,6 +574,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_IMX8M
 	{ .compatible = "nxp,imx8mq-vpu", .data = &imx8mq_vpu_variant, },
+	{ .compatible = "nxp,imx8mq-vpu-g2", .data = &imx8mq_vpu_g2_variant },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 5788188aae50..b4e7490bbe45 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -193,6 +193,7 @@ extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant imx8mq_vpu_g2_variant;
 
 extern const struct hantro_postproc_regs hantro_g1_postproc_regs;
 
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index 8d0c3425234b..6de43e0edc36 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -12,6 +12,7 @@
 #include "hantro.h"
 #include "hantro_jpeg.h"
 #include "hantro_g1_regs.h"
+#include "hantro_g2_regs.h"
 
 #define CTRL_SOFT_RESET		0x00
 #define RESET_G1		BIT(1)
@@ -129,6 +130,26 @@ static const struct hantro_fmt imx8m_vpu_dec_fmts[] = {
 	},
 };
 
+static const struct hantro_fmt imx8m_vpu_g2_dec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
+		.codec_mode = HANTRO_MODE_HEVC_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = 48,
+			.max_width = 3840,
+			.step_width = MB_DIM,
+			.min_height = 48,
+			.max_height = 2160,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
 static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 {
 	struct hantro_dev *vpu = dev_id;
@@ -147,6 +168,24 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t imx8m_vpu_g2_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+	state = (status & HEVC_REG_INTERRUPT_DEC_RDY_INT) ?
+		 VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vdpu_write(vpu, 0, HEVC_REG_INTERRUPT);
+	vdpu_write(vpu, HEVC_REG_CONFIG_DEC_CLK_GATE_E, HEVC_REG_CONFIG);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
 	struct device_node *np = vpu->dev->of_node;
@@ -176,6 +215,13 @@ static void imx8m_vpu_g1_reset(struct hantro_ctx *ctx)
 	imx8m_soft_reset(vpu, RESET_G1);
 }
 
+static void imx8m_vpu_g2_reset(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	imx8m_soft_reset(vpu, RESET_G2);
+}
+
 /*
  * Supported codec ops.
  */
@@ -201,16 +247,28 @@ static const struct hantro_codec_ops imx8mq_vpu_codec_ops[] = {
 	},
 };
 
+static const struct hantro_codec_ops imx8mq_vpu_g2_codec_ops[] = {
+	[HANTRO_MODE_HEVC_DEC] = {
+		.run = hantro_g2_hevc_dec_run,
+		.reset = imx8m_vpu_g2_reset,
+		.init = hantro_hevc_dec_init,
+		.exit = hantro_hevc_dec_exit,
+	},
+};
+
 /*
  * VPU variants.
  */
 
 static const struct hantro_irq imx8mq_irqs[] = {
 	{ "g1", imx8m_vpu_g1_irq },
-	{ "g2", NULL /* TODO: imx8m_vpu_g2_irq */ },
 };
 
-static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
+static const struct hantro_irq imx8mq_g2_irqs[] = {
+	{ "g2", imx8m_vpu_g2_irq },
+};
+
+static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus"};
 
 const struct hantro_variant imx8mq_vpu_variant = {
 	.dec_fmts = imx8m_vpu_dec_fmts,
@@ -228,3 +286,17 @@ const struct hantro_variant imx8mq_vpu_variant = {
 	.clk_names = imx8mq_clk_names,
 	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
 };
+
+const struct hantro_variant imx8mq_vpu_g2_variant = {
+	.dec_offset = 0x0,
+	.dec_fmts = imx8m_vpu_g2_dec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(imx8m_vpu_g2_dec_fmts),
+	.codec = HANTRO_HEVC_DECODER,
+	.codec_ops = imx8mq_vpu_g2_codec_ops,
+	.init = imx8mq_vpu_hw_init,
+	.runtime_resume = imx8mq_runtime_resume,
+	.irqs = imx8mq_g2_irqs,
+	.num_irqs = ARRAY_SIZE(imx8mq_g2_irqs),
+	.clk_names = imx8mq_clk_names,
+	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
+};
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 17:00:00 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 18:00:00 +0200
Subject: [PATCH v8 10/13] media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-11-benjamin.gaignard@collabora.com>

Make sure that V4L2_PIX_FMT_HEVC_SLICE is correctly handle by v4l2
of the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - Add Ezequiel review tag

 drivers/staging/media/hantro/hantro_v4l2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 77d7fe62ce81..0655324fd0d4 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -392,6 +392,7 @@ hantro_update_requires_request(struct hantro_ctx *ctx, u32 fourcc)
 	case V4L2_PIX_FMT_MPEG2_SLICE:
 	case V4L2_PIX_FMT_VP8_FRAME:
 	case V4L2_PIX_FMT_H264_SLICE:
+	case V4L2_PIX_FMT_HEVC_SLICE:
 		ctx->fh.m2m_ctx->out_q_ctx.q.requires_requests = true;
 		break;
 	default:
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:56 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:56 +0200
Subject: [PATCH v8 06/13] media: hantro: change hantro_codec_ops run prototype
 to return errors
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-7-benjamin.gaignard@collabora.com>

Change hantro_codec_ops run prototype from 'void' to 'int'.
This allow to cancel the job if an error occur while configuring
the hardware.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

version 5:
 - forward hantro_h264_dec_prepare_run() return value in case
   of error

 drivers/staging/media/hantro/hantro_drv.c     |  4 +++-
 .../staging/media/hantro/hantro_g1_h264_dec.c | 10 +++++++---
 .../media/hantro/hantro_g1_mpeg2_dec.c        |  4 +++-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |  6 ++++--
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |  4 +++-
 drivers/staging/media/hantro/hantro_hw.h      | 19 ++++++++++---------
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |  4 +++-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |  4 +++-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |  6 ++++--
 9 files changed, 40 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 595e82a82728..02c5c2f1a88b 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -161,7 +161,9 @@ static void device_run(void *priv)
 
 	v4l2_m2m_buf_copy_metadata(src, dst, true);
 
-	ctx->codec_ops->run(ctx);
+	if (ctx->codec_ops->run(ctx))
+		goto err_cancel_job;
+
 	return;
 
 err_cancel_job:
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 845bef73d218..5c792b7bcb79 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -273,13 +273,15 @@ static void set_buffers(struct hantro_ctx *ctx)
 	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, G1_REG_ADDR_QTABLE);
 }
 
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
+	int ret;
 
 	/* Prepare the H264 decoder context. */
-	if (hantro_h264_dec_prepare_run(ctx))
-		return;
+	ret = hantro_h264_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
 
 	/* Configure hardware registers. */
 	set_params(ctx);
@@ -301,4 +303,6 @@ void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 			   G1_REG_CONFIG_DEC_CLK_GATE_E,
 			   G1_REG_CONFIG);
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
index 6386a3989bfe..5e8943d31dc5 100644
--- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
@@ -155,7 +155,7 @@ hantro_g1_mpeg2_dec_set_buffers(struct hantro_dev *vpu, struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, backward_addr, G1_REG_REFER3_BASE);
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -248,4 +248,6 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = G1_REG_DEC_E(1);
 	vdpu_write(vpu, reg, G1_SWREG(1));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 57002ba70176..96622a7f8279 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -425,7 +425,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, G1_REG_ADDR_DST);
 }
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -438,7 +438,7 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -498,4 +498,6 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index b88dc4ed06db..56cf261a8e95 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -88,7 +88,7 @@ hantro_h1_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -136,6 +136,8 @@ void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vepu_write(vpu, reg, H1_REG_ENC_CTRL);
+
+	return 0;
 }
 
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx)
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 13a6e7113001..a76852966578 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -126,14 +126,15 @@ struct hantro_postproc_ctx {
  *		Optional and called from process context.
  * @run:	Start single {en,de)coding job. Called from atomic context
  *		to indicate that a pair of buffers is ready and the hardware
- *		should be programmed and started.
+ *		should be programmed and started. Returns zero if OK, a
+ *		negative value in error cases.
  * @done:	Read back processing results and additional data from hardware.
  * @reset:	Reset the hardware in case of a timeout.
  */
 struct hantro_codec_ops {
 	int (*init)(struct hantro_ctx *ctx);
 	void (*exit)(struct hantro_ctx *ctx);
-	void (*run)(struct hantro_ctx *ctx);
+	int (*run)(struct hantro_ctx *ctx);
 	void (*done)(struct hantro_ctx *ctx);
 	void (*reset)(struct hantro_ctx *ctx);
 };
@@ -164,8 +165,8 @@ void hantro_irq_done(struct hantro_dev *vpu,
 void hantro_start_prepare_run(struct hantro_ctx *ctx);
 void hantro_end_prepare_run(struct hantro_ctx *ctx);
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
 int hantro_jpeg_enc_init(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_exit(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
@@ -173,7 +174,7 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
 dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 				   unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
@@ -204,15 +205,15 @@ hantro_h264_mv_size(unsigned int width, unsigned int height)
 	return 64 * MB_WIDTH(width) * MB_WIDTH(height) + 32;
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_copy_qtable(u8 *qtable,
 	const struct v4l2_ctrl_mpeg2_quantization *ctrl);
 int hantro_mpeg2_dec_init(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_exit(struct hantro_ctx *ctx);
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
 int hantro_vp8_dec_init(struct hantro_ctx *ctx);
 void hantro_vp8_dec_exit(struct hantro_ctx *ctx);
 void hantro_vp8_prob_update(struct hantro_ctx *ctx,
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
index 3498e6124acd..3a27ebef4f38 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
@@ -118,7 +118,7 @@ rk3399_vpu_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -168,4 +168,6 @@ void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 	/* Kick the watchdog and start encoding */
 	hantro_end_prepare_run(ctx);
 	vepu_write(vpu, reg, VEPU_REG_ENCODE_START);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
index f610fa5b4335..4bd3080abbc1 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
@@ -157,7 +157,7 @@ rk3399_vpu_mpeg2_dec_set_buffers(struct hantro_dev *vpu,
 	vdpu_write_relaxed(vpu, backward_addr, VDPU_REG_REFER3_BASE);
 }
 
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -254,4 +254,6 @@ void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = vdpu_read(vpu, VDPU_SWREG(57)) | VDPU_REG_DEC_E(1);
 	vdpu_write(vpu, reg, VDPU_SWREG(57));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
index 8661a3cc1e6b..e5d20fe5b007 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
@@ -503,7 +503,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, VDPU_REG_ADDR_DST);
 }
 
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -516,7 +516,7 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -589,4 +589,6 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	hantro_reg_write(vpu, &vp8_dec_start_dec, 1);
+
+	return 0;
 }
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 16:59:57 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 17:59:57 +0200
Subject: [PATCH v8 07/13] media: hantro: Define HEVC codec profiles and
 supported features
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-8-benjamin.gaignard@collabora.com>

Define which HEVC profiles (up to level 5.1) and features
(no scaling, no 10 bits) are supported by the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

 drivers/staging/media/hantro/hantro.h     |  3 ++
 drivers/staging/media/hantro/hantro_drv.c | 58 +++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 37b9ce04bd4e..edb4561a6887 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -35,6 +35,7 @@ struct hantro_codec_ops;
 #define HANTRO_MPEG2_DECODER	BIT(16)
 #define HANTRO_VP8_DECODER	BIT(17)
 #define HANTRO_H264_DECODER	BIT(18)
+#define HANTRO_HEVC_DECODER	BIT(19)
 #define HANTRO_DECODERS		0xffff0000
 
 /**
@@ -100,6 +101,7 @@ struct hantro_variant {
  * @HANTRO_MODE_H264_DEC: H264 decoder.
  * @HANTRO_MODE_MPEG2_DEC: MPEG-2 decoder.
  * @HANTRO_MODE_VP8_DEC: VP8 decoder.
+ * @HANTRO_MODE_HEVC_DEC: HEVC decoder.
  */
 enum hantro_codec_mode {
 	HANTRO_MODE_NONE = -1,
@@ -107,6 +109,7 @@ enum hantro_codec_mode {
 	HANTRO_MODE_H264_DEC,
 	HANTRO_MODE_MPEG2_DEC,
 	HANTRO_MODE_VP8_DEC,
+	HANTRO_MODE_HEVC_DEC,
 };
 
 /*
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 02c5c2f1a88b..d9a3a5ef9330 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -245,6 +245,18 @@ static int hantro_try_ctrl(struct v4l2_ctrl *ctrl)
 		if (sps->bit_depth_luma_minus8 != 0)
 			/* Only 8-bit is supported */
 			return -EINVAL;
+	} else if (ctrl->id == V4L2_CID_MPEG_VIDEO_HEVC_SPS) {
+		const struct v4l2_ctrl_hevc_sps *sps = ctrl->p_new.p_hevc_sps;
+
+		if (sps->bit_depth_luma_minus8 != sps->bit_depth_chroma_minus8)
+			/* Luma and chroma bit depth mismatch */
+			return -EINVAL;
+		if (sps->bit_depth_luma_minus8 != 0)
+			/* Only 8-bit is supported */
+			return -EINVAL;
+		if (sps->flags & V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED)
+			/* No scaling support */
+			return -EINVAL;
 	}
 	return 0;
 }
@@ -351,6 +363,52 @@ static const struct hantro_ctrl controls[] = {
 			.def = V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
 		}
 	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.max = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.def = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_START_CODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.max = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.def = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
+			.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+			.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
+			.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
+			.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
+			.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+			.ops = &hantro_ctrl_ops,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
 	},
 };
 
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr  1 17:00:01 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu,  1 Apr 2021 18:00:01 +0200
Subject: [PATCH v8 11/13] media: hantro: Introduce G2/HEVC decoder
In-Reply-To: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
Message-ID: <20210401160003.88803-12-benjamin.gaignard@collabora.com>

Implement all the logic to get G2 hardware decoding HEVC frames.
It support up level 5.1 HEVC stream.
It doesn't support yet 10 bits formats or scaling feature.

Add HANTRO HEVC dedicated control to skip some bits at the beginning
of the slice header. That is very specific to this hardware so can't
go into uapi structures. Compute the needed value is complex and require
information from the stream that only the userland knows so let it
provide the correct value to the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Co-developed-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Signed-off-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Co-developed-by: Ezequiel Garcia <ezequiel at collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - Fix compilation warnings

version 7:
 - Improve motion vectors requested memory size computation.

 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |   2 +
 drivers/staging/media/hantro/hantro_drv.c     |  36 ++
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 drivers/staging/media/hantro/hantro_hevc.c    | 325 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  49 ++
 7 files changed, 1199 insertions(+)
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile
index 743ce08eb184..0357f1772267 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -9,12 +9,14 @@ hantro-vpu-y += \
 		hantro_h1_jpeg_enc.o \
 		hantro_g1_h264_dec.o \
 		hantro_g1_mpeg2_dec.o \
+		hantro_g2_hevc_dec.o \
 		hantro_g1_vp8_dec.o \
 		rk3399_vpu_hw_jpeg_enc.o \
 		rk3399_vpu_hw_mpeg2_dec.o \
 		rk3399_vpu_hw_vp8_dec.o \
 		hantro_jpeg.o \
 		hantro_h264.o \
+		hantro_hevc.o \
 		hantro_mpeg2.o \
 		hantro_vp8.o
 
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 7a5ad93466c8..6a21d1e95b34 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -222,6 +222,7 @@ struct hantro_dev {
  * @jpeg_enc:		JPEG-encoding context.
  * @mpeg2_dec:		MPEG-2-decoding context.
  * @vp8_dec:		VP8-decoding context.
+ * @hevc_dec:		HEVC-decoding context.
  */
 struct hantro_ctx {
 	struct hantro_dev *dev;
@@ -248,6 +249,7 @@ struct hantro_ctx {
 		struct hantro_jpeg_enc_hw_ctx jpeg_enc;
 		struct hantro_mpeg2_dec_hw_ctx mpeg2_dec;
 		struct hantro_vp8_dec_hw_ctx vp8_dec;
+		struct hantro_hevc_dec_hw_ctx hevc_dec;
 	};
 };
 
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index d9a3a5ef9330..33b8bd38eac1 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -281,6 +281,26 @@ static int hantro_jpeg_s_ctrl(struct v4l2_ctrl *ctrl)
 	return 0;
 }
 
+static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct hantro_ctx *ctx;
+
+	ctx = container_of(ctrl->handler,
+			   struct hantro_ctx, ctrl_handler);
+
+	vpu_debug(1, "s_ctrl: id = %d, val = %d\n", ctrl->id, ctrl->val);
+
+	switch (ctrl->id) {
+	case V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP:
+		ctx->hevc_dec.ctrls.hevc_hdr_skip_length = ctrl->val;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
 	.try_ctrl = hantro_try_ctrl,
 };
@@ -289,6 +309,10 @@ static const struct v4l2_ctrl_ops hantro_jpeg_ctrl_ops = {
 	.s_ctrl = hantro_jpeg_s_ctrl,
 };
 
+static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
+	.s_ctrl = hantro_hevc_s_ctrl,
+};
+
 static const struct hantro_ctrl controls[] = {
 	{
 		.codec = HANTRO_JPEG_ENCODER,
@@ -409,6 +433,18 @@ static const struct hantro_ctrl controls[] = {
 		.cfg = {
 			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
 		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP,
+			.name = "Hantro HEVC slice header skip bytes",
+			.type = V4L2_CTRL_TYPE_INTEGER,
+			.min = 0,
+			.def = 0,
+			.max = 0x7fffffff,
+			.step = 1,
+			.ops = &hantro_hevc_ctrl_ops,
+		},
 	},
 };
 
diff --git a/drivers/staging/media/hantro/hantro_g2_hevc_dec.c b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
new file mode 100644
index 000000000000..03a193a50c09
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
@@ -0,0 +1,587 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include "hantro_hw.h"
+#include "hantro_g2_regs.h"
+
+#define HEVC_DEC_MODE	0xC
+
+#define BUS_WIDTH_32		0
+#define BUS_WIDTH_64		1
+#define BUS_WIDTH_128		2
+#define BUS_WIDTH_256		3
+
+static inline void hantro_write_addr(struct hantro_dev *vpu,
+				     unsigned long offset,
+				     dma_addr_t addr)
+{
+	vdpu_write(vpu, addr & 0xffffffff, offset);
+}
+
+static void prepare_tile_info_buffer(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	u16 *p = (u16 *)((u8 *)ctx->hevc_dec.tile_sizes.cpu);
+	unsigned int num_tile_rows = pps->num_tile_rows_minus1 + 1;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int pic_width_in_ctbs, pic_height_in_ctbs;
+	unsigned int max_log2_ctb_size, ctb_size;
+	bool tiles_enabled, uniform_spacing;
+	u32 no_chroma = 0;
+
+	tiles_enabled = !!(pps->flags & V4L2_HEVC_PPS_FLAG_TILES_ENABLED);
+	uniform_spacing = !!(pps->flags & V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING);
+
+	hantro_reg_write(vpu, hevc_tile_e, tiles_enabled);
+
+	max_log2_ctb_size = sps->log2_min_luma_coding_block_size_minus3 + 3 +
+			    sps->log2_diff_max_min_luma_coding_block_size;
+	pic_width_in_ctbs = (sps->pic_width_in_luma_samples +
+			    (1 << max_log2_ctb_size) - 1) >> max_log2_ctb_size;
+	pic_height_in_ctbs = (sps->pic_height_in_luma_samples + (1 << max_log2_ctb_size) - 1)
+			     >> max_log2_ctb_size;
+	ctb_size = 1 << max_log2_ctb_size;
+
+	vpu_debug(1, "Preparing tile sizes buffer for %dx%d CTBs (CTB size %d)\n",
+		  pic_width_in_ctbs, pic_height_in_ctbs, ctb_size);
+
+	if (tiles_enabled) {
+		unsigned int i, j, h;
+
+		vpu_debug(1, "Tiles enabled! %dx%d\n", num_tile_cols, num_tile_rows);
+
+		hantro_reg_write(vpu, hevc_num_tile_rows, num_tile_rows);
+		hantro_reg_write(vpu, hevc_num_tile_cols, num_tile_cols);
+
+		/* write width + height for each tile in pic */
+		if (!uniform_spacing) {
+			u32 tmp_w = 0, tmp_h = 0;
+
+			for (i = 0; i < num_tile_rows; i++) {
+				if (i == num_tile_rows - 1)
+					h = pic_height_in_ctbs - tmp_h;
+				else
+					h = pps->row_height_minus1[i] + 1;
+				tmp_h += h;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, tmp_w = 0; j < num_tile_cols - 1; j++) {
+					tmp_w += pps->column_width_minus1[j] + 1;
+					*p++ = pps->column_width_minus1[j + 1];
+					*p++ = h;
+					if (i == 0 && h == 1 && ctb_size == 16)
+						no_chroma = 1;
+				}
+				/* last column */
+				*p++ = pic_width_in_ctbs - tmp_w;
+				*p++ = h;
+			}
+		} else { /* uniform spacing */
+			u32 tmp, prev_h, prev_w;
+
+			for (i = 0, prev_h = 0; i < num_tile_rows; i++) {
+				tmp = (i + 1) * pic_height_in_ctbs / num_tile_rows;
+				h = tmp - prev_h;
+				prev_h = tmp;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, prev_w = 0; j < num_tile_cols; j++) {
+					tmp = (j + 1) * pic_width_in_ctbs / num_tile_cols;
+					*p++ = tmp - prev_w;
+					*p++ = h;
+					if (j == 0 &&
+					    (pps->column_width_minus1[0] + 1) == 1 &&
+					    ctb_size == 16)
+						no_chroma = 1;
+					prev_w = tmp;
+				}
+			}
+		}
+	} else {
+		hantro_reg_write(vpu, hevc_num_tile_rows, 1);
+		hantro_reg_write(vpu, hevc_num_tile_cols, 1);
+
+		/* There's one tile, with dimensions equal to pic size. */
+		p[0] = pic_width_in_ctbs;
+		p[1] = pic_height_in_ctbs;
+	}
+
+	if (no_chroma)
+		vpu_debug(1, "%s: no chroma!\n", __func__);
+}
+
+static void set_params(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 min_log2_cb_size, max_log2_ctb_size, min_cb_size, max_ctb_size;
+	u32 pic_width_in_min_cbs, pic_height_in_min_cbs;
+	u32 pic_width_aligned, pic_height_aligned;
+	u32 partial_ctb_x, partial_ctb_y;
+
+	hantro_reg_write(vpu, hevc_bit_depth_y_minus8, sps->bit_depth_luma_minus8);
+	hantro_reg_write(vpu, hevc_bit_depth_c_minus8, sps->bit_depth_chroma_minus8);
+
+	hantro_reg_write(vpu, hevc_output_8_bits, 0);
+
+	hantro_reg_write(vpu, hevc_hdr_skip_length, ctrls->hevc_hdr_skip_length);
+
+	min_log2_cb_size = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	max_log2_ctb_size = min_log2_cb_size + sps->log2_diff_max_min_luma_coding_block_size;
+
+	hantro_reg_write(vpu, hevc_min_cb_size, min_log2_cb_size);
+	hantro_reg_write(vpu, hevc_max_cb_size, max_log2_ctb_size);
+
+	min_cb_size = 1 << min_log2_cb_size;
+	max_ctb_size = 1 << max_log2_ctb_size;
+
+	pic_width_in_min_cbs = sps->pic_width_in_luma_samples / min_cb_size;
+	pic_height_in_min_cbs = sps->pic_height_in_luma_samples / min_cb_size;
+	pic_width_aligned = ALIGN(sps->pic_width_in_luma_samples, max_ctb_size);
+	pic_height_aligned = ALIGN(sps->pic_height_in_luma_samples, max_ctb_size);
+
+	partial_ctb_x = !!(sps->pic_width_in_luma_samples != pic_width_aligned);
+	partial_ctb_y = !!(sps->pic_height_in_luma_samples != pic_height_aligned);
+
+	hantro_reg_write(vpu, hevc_partial_ctb_x, partial_ctb_x);
+	hantro_reg_write(vpu, hevc_partial_ctb_y, partial_ctb_y);
+
+	hantro_reg_write(vpu, hevc_pic_width_in_cbs, pic_width_in_min_cbs);
+	hantro_reg_write(vpu, hevc_pic_height_in_cbs, pic_height_in_min_cbs);
+
+	hantro_reg_write(vpu, hevc_pic_width_4x4,
+			 (pic_width_in_min_cbs * min_cb_size) / 4);
+	hantro_reg_write(vpu, hevc_pic_height_4x4,
+			 (pic_height_in_min_cbs * min_cb_size) / 4);
+
+	hantro_reg_write(vpu, hevc_max_inter_hierdepth,
+			 sps->max_transform_hierarchy_depth_inter);
+	hantro_reg_write(vpu, hevc_max_intra_hierdepth,
+			 sps->max_transform_hierarchy_depth_intra);
+	hantro_reg_write(vpu, hevc_min_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2);
+	hantro_reg_write(vpu, hevc_max_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2 +
+			 sps->log2_diff_max_min_luma_transform_block_size);
+
+	hantro_reg_write(vpu, hevc_tempor_mvp_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED) &&
+			 !(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC));
+	hantro_reg_write(vpu, hevc_strong_smooth_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED));
+	hantro_reg_write(vpu, hevc_asym_pred_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_AMP_ENABLED));
+	hantro_reg_write(vpu, hevc_sao_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET));
+	hantro_reg_write(vpu, hevc_sign_data_hide,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED));
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED) {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 1);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, pps->diff_cu_qp_delta_depth);
+	} else {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 0);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, 0);
+	}
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT) {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, pps->pps_cb_qp_offset);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, pps->pps_cr_qp_offset);
+	} else {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, 0);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_filt_offset_beta, pps->pps_beta_offset_div2);
+	hantro_reg_write(vpu, hevc_filt_offset_tc, pps->pps_tc_offset_div2);
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT));
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_bits, pps->num_extra_slice_header_bits);
+	hantro_reg_write(vpu, hevc_slice_chqp_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT));
+	hantro_reg_write(vpu, hevc_weight_bipr_idc,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED));
+	hantro_reg_write(vpu, hevc_transq_bypass,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED));
+	hantro_reg_write(vpu, hevc_list_mod_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT));
+	hantro_reg_write(vpu, hevc_entropy_sync_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_idr_pic_e,
+			 !!(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC));
+	hantro_reg_write(vpu, hevc_parallel_merge,
+			 pps->log2_parallel_merge_level_minus2 + 2);
+	hantro_reg_write(vpu, hevc_pcm_filt_d,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED));
+	hantro_reg_write(vpu, hevc_pcm_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED));
+	if (sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED) {
+		hantro_reg_write(vpu, hevc_max_pcm_size,
+				 sps->log2_diff_max_min_pcm_luma_coding_block_size +
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_min_pcm_size,
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y,
+				 sps->pcm_sample_bit_depth_luma_minus1 + 1);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c,
+				 sps->pcm_sample_bit_depth_chroma_minus1 + 1);
+	} else {
+		hantro_reg_write(vpu, hevc_max_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_min_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_start_code_e, 1);
+	hantro_reg_write(vpu, hevc_init_qp, pps->init_qp_minus26 + 26);
+	hantro_reg_write(vpu, hevc_weight_pred_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_const_intra_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED));
+	hantro_reg_write(vpu, hevc_transform_skip,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED));
+	hantro_reg_write(vpu, hevc_out_filtering_dis,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER));
+	hantro_reg_write(vpu, hevc_filt_ctrl_pres,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT));
+	hantro_reg_write(vpu, hevc_dependent_slice,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT));
+	hantro_reg_write(vpu, hevc_filter_override,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED));
+	hantro_reg_write(vpu, hevc_refidx0_active,
+			 pps->num_ref_idx_l0_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_refidx1_active,
+			 pps->num_ref_idx_l1_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_apf_threshold, 8);
+}
+
+static int find_ref_pic_index(const struct v4l2_hevc_dpb_entry *dpb, int pic_order_cnt)
+{
+	int i;
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		if (dpb[i].pic_order_cnt[0] == pic_order_cnt)
+			return i;
+	}
+
+	return 0x0;
+}
+
+static void set_ref_pic_list(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	u32 list0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	u32 list1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	const struct hantro_reg *ref_pic_regs0[] = {
+		hevc_rlist_f0,
+		hevc_rlist_f1,
+		hevc_rlist_f2,
+		hevc_rlist_f3,
+		hevc_rlist_f4,
+		hevc_rlist_f5,
+		hevc_rlist_f6,
+		hevc_rlist_f7,
+		hevc_rlist_f8,
+		hevc_rlist_f9,
+		hevc_rlist_f10,
+		hevc_rlist_f11,
+		hevc_rlist_f12,
+		hevc_rlist_f13,
+		hevc_rlist_f14,
+		hevc_rlist_f15,
+	};
+	const struct hantro_reg *ref_pic_regs1[] = {
+		hevc_rlist_b0,
+		hevc_rlist_b1,
+		hevc_rlist_b2,
+		hevc_rlist_b3,
+		hevc_rlist_b4,
+		hevc_rlist_b5,
+		hevc_rlist_b6,
+		hevc_rlist_b7,
+		hevc_rlist_b8,
+		hevc_rlist_b9,
+		hevc_rlist_b10,
+		hevc_rlist_b11,
+		hevc_rlist_b12,
+		hevc_rlist_b13,
+		hevc_rlist_b14,
+		hevc_rlist_b15,
+	};
+	unsigned int i, j;
+
+	/* List 0 contains: short term before, short term after and long term */
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	/* Fill the list, copying over and over */
+	i = 0;
+	while (j < ARRAY_SIZE(list0))
+		list0[j++] = list0[i++];
+
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	i = 0;
+	while (j < ARRAY_SIZE(list1))
+		list1[j++] = list1[i++];
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_reg_write(vpu, ref_pic_regs0[i], list0[i]);
+		hantro_reg_write(vpu, ref_pic_regs1[i], list1[i]);
+	}
+}
+
+static int set_ref(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
+	struct hantro_dev *vpu = ctx->dev;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	size_t mv_offset = hantro_hevc_motion_vectors_offset(sps);
+	u32 max_ref_frames;
+	u16 dpb_longterm_e;
+
+	const struct hantro_reg *cur_poc[] = {
+		hevc_cur_poc_00,
+		hevc_cur_poc_01,
+		hevc_cur_poc_02,
+		hevc_cur_poc_03,
+		hevc_cur_poc_04,
+		hevc_cur_poc_05,
+		hevc_cur_poc_06,
+		hevc_cur_poc_07,
+		hevc_cur_poc_08,
+		hevc_cur_poc_09,
+		hevc_cur_poc_10,
+		hevc_cur_poc_11,
+		hevc_cur_poc_12,
+		hevc_cur_poc_13,
+		hevc_cur_poc_14,
+		hevc_cur_poc_15,
+	};
+	unsigned int i;
+
+	max_ref_frames = decode_params->num_poc_lt_curr +
+		decode_params->num_poc_st_curr_before +
+		decode_params->num_poc_st_curr_after;
+	/*
+	 * Set max_ref_frames to non-zero to avoid HW hang when decoding
+	 * badly marked I-frames.
+	 */
+	max_ref_frames = max_ref_frames ? max_ref_frames : 1;
+	hantro_reg_write(vpu, hevc_num_ref_frames, max_ref_frames);
+	hantro_reg_write(vpu, hevc_filter_over_slices,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED));
+	hantro_reg_write(vpu, hevc_filter_over_tiles,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED));
+
+	/*
+	 * Write POC count diff from current pic. For frame decoding only compute
+	 * pic_order_cnt[0] and ignore pic_order_cnt[1] used in field-coding.
+	 */
+	for (i = 0; i < decode_params->num_active_dpb_entries && i < ARRAY_SIZE(cur_poc); i++) {
+		char poc_diff = decode_params->pic_order_cnt_val - dpb[i].pic_order_cnt[0];
+
+		hantro_reg_write(vpu, cur_poc[i], poc_diff);
+	}
+
+	if (i < ARRAY_SIZE(cur_poc)) {
+		/*
+		 * After the references, fill one entry pointing to itself,
+		 * i.e. difference is zero.
+		 */
+		hantro_reg_write(vpu, cur_poc[i], 0);
+		i++;
+	}
+
+	/* Fill the rest with the current picture */
+	for (; i < ARRAY_SIZE(cur_poc); i++)
+		hantro_reg_write(vpu, cur_poc[i], decode_params->pic_order_cnt_val);
+
+	set_ref_pic_list(ctx);
+
+	/* We will only keep the references picture that are still used */
+	ctx->hevc_dec.ref_bufs_used = 0;
+
+	/* Set up addresses of DPB buffers */
+	dpb_longterm_e = 0;
+	for (i = 0; i < decode_params->num_active_dpb_entries &&
+	     i < (V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1); i++) {
+		luma_addr = hantro_hevc_get_ref_buf(ctx, dpb[i].pic_order_cnt[0]);
+		if (!luma_addr)
+			return -ENOMEM;
+
+		chroma_addr = luma_addr + cr_offset;
+		mv_addr = luma_addr + mv_offset;
+
+		if (dpb[i].rps == V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR)
+			dpb_longterm_e |= BIT(V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1 - i);
+
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), mv_addr);
+	}
+
+	luma_addr = hantro_hevc_get_ref_buf(ctx, decode_params->pic_order_cnt_val);
+	if (!luma_addr)
+		return -ENOMEM;
+
+	chroma_addr = luma_addr + cr_offset;
+	mv_addr = luma_addr + mv_offset;
+
+	hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+	hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+	hantro_write_addr(vpu, HEVC_REG_DMV_REF(i++), mv_addr);
+
+	hantro_write_addr(vpu, HEVC_ADDR_DST, luma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_CHR, chroma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_MV, mv_addr);
+
+	hantro_hevc_ref_remove_unused(ctx);
+
+	for (; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), 0);
+	}
+
+	hantro_reg_write(vpu, hevc_refer_lterm_e, dpb_longterm_e);
+
+	return 0;
+}
+
+static void set_buffers(struct hantro_ctx *ctx)
+{
+	struct vb2_v4l2_buffer *src_buf, *dst_buf;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	dma_addr_t src_dma, dst_dma;
+	u32 src_len, src_buf_len;
+
+	src_buf = hantro_get_src_buf(ctx);
+	dst_buf = hantro_get_dst_buf(ctx);
+
+	/* Source (stream) buffer. */
+	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+	src_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+	src_buf_len = vb2_plane_size(&src_buf->vb2_buf, 0);
+
+	hantro_write_addr(vpu, HEVC_ADDR_STR, src_dma);
+	hantro_reg_write(vpu, hevc_stream_len, src_len);
+	hantro_reg_write(vpu, hevc_strm_buffer_len, src_buf_len);
+	hantro_reg_write(vpu, hevc_strm_start_offset, 0);
+	hantro_reg_write(vpu, hevc_write_mvs_e, 1);
+
+	/* Destination (decoded frame) buffer. */
+	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
+
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN, dst_dma);
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN_CHR, dst_dma + cr_offset);
+	hantro_write_addr(vpu, HEVC_ADDR_TILE_SIZE, ctx->hevc_dec.tile_sizes.dma);
+	hantro_write_addr(vpu, HEVC_TILE_FILTER, ctx->hevc_dec.tile_filter.dma);
+	hantro_write_addr(vpu, HEVC_TILE_SAO, ctx->hevc_dec.tile_sao.dma);
+	hantro_write_addr(vpu, HEVC_TILE_BSD, ctx->hevc_dec.tile_bsd.dma);
+}
+
+static void hantro_g2_check_idle(struct hantro_dev *vpu)
+{
+	int i;
+
+	for (i = 0; i < 3; i++) {
+		u32 status;
+
+		/* Make sure the VPU is idle */
+		status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+		if (status & HEVC_REG_INTERRUPT_DEC_E) {
+			dev_warn(vpu->dev, "device still running, aborting");
+			status |= HEVC_REG_INTERRUPT_DEC_ABORT_E | HEVC_REG_INTERRUPT_DEC_IRQ_DIS;
+			vdpu_write(vpu, status, HEVC_REG_INTERRUPT);
+		}
+	}
+}
+
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	int ret;
+
+	hantro_g2_check_idle(vpu);
+
+	/* Prepare HEVC decoder context. */
+	ret = hantro_hevc_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
+
+	/* Configure hardware registers. */
+	set_params(ctx);
+
+	/* set reference pictures */
+	ret = set_ref(ctx);
+	if (ret)
+		return ret;
+
+	set_buffers(ctx);
+	prepare_tile_info_buffer(ctx);
+
+	hantro_end_prepare_run(ctx);
+
+	hantro_reg_write(vpu, hevc_mode, HEVC_DEC_MODE);
+	hantro_reg_write(vpu, hevc_clk_gate_e, 1);
+
+	/* Don't disable output */
+	hantro_reg_write(vpu, hevc_out_dis, 0);
+
+	/* Don't compress buffers */
+	hantro_reg_write(vpu, hevc_ref_compress_bypass, 1);
+
+	/* use NV12 as output format */
+	hantro_reg_write(vpu, hevc_out_rs_e, 1);
+
+	/* Bus width and max burst */
+	hantro_reg_write(vpu, hevc_buswidth, BUS_WIDTH_128);
+	hantro_reg_write(vpu, hevc_max_burst, 16);
+
+	/* Swap */
+	hantro_reg_write(vpu, hevc_strm_swap, 0xf);
+	hantro_reg_write(vpu, hevc_dirmv_swap, 0xf);
+	hantro_reg_write(vpu, hevc_compress_swap, 0xf);
+
+	/* Start decoding! */
+	vdpu_write(vpu, HEVC_REG_INTERRUPT_DEC_E, HEVC_REG_INTERRUPT);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_g2_regs.h b/drivers/staging/media/hantro/hantro_g2_regs.h
new file mode 100644
index 000000000000..a361c9ba911d
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_regs.h
@@ -0,0 +1,198 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2021, Collabora
+ *
+ * Author: Benjamin Gaignard <benjamin.gaignard at collabora.com>
+ */
+
+#ifndef HANTRO_G2_REGS_H_
+#define HANTRO_G2_REGS_H_
+
+#include "hantro.h"
+
+#define G2_SWREG(nr)	((nr) * 4)
+
+#define HEVC_DEC_REG(name, base, shift, mask) \
+	static const struct hantro_reg _hevc_##name[] = { \
+		{ G2_SWREG(base), (shift), (mask) } \
+	}; \
+	static const struct hantro_reg __maybe_unused *hevc_##name = &_hevc_##name[0];
+
+#define HEVC_REG_VERSION		G2_SWREG(0)
+
+#define HEVC_REG_INTERRUPT		G2_SWREG(1)
+#define HEVC_REG_INTERRUPT_DEC_RDY_INT	BIT(12)
+#define HEVC_REG_INTERRUPT_DEC_ABORT_E	BIT(5)
+#define HEVC_REG_INTERRUPT_DEC_IRQ_DIS	BIT(4)
+#define HEVC_REG_INTERRUPT_DEC_E	BIT(0)
+
+HEVC_DEC_REG(strm_swap,		2, 28,	0xf)
+HEVC_DEC_REG(dirmv_swap,	2, 20,	0xf)
+
+HEVC_DEC_REG(mode,		  3, 27, 0x1f)
+HEVC_DEC_REG(compress_swap,	  3, 20, 0xf)
+HEVC_DEC_REG(ref_compress_bypass, 3, 17, 0x1)
+HEVC_DEC_REG(out_rs_e,		  3, 16, 0x1)
+HEVC_DEC_REG(out_dis,		  3, 15, 0x1)
+HEVC_DEC_REG(out_filtering_dis,   3, 14, 0x1)
+HEVC_DEC_REG(write_mvs_e,	  3, 12, 0x1)
+
+HEVC_DEC_REG(pic_width_in_cbs,	4, 19,	0x1ff)
+HEVC_DEC_REG(pic_height_in_cbs,	4, 6,	0x1ff)
+HEVC_DEC_REG(num_ref_frames,	4, 0,	0x1f)
+
+HEVC_DEC_REG(scaling_list_e,	5, 24,	0x1)
+HEVC_DEC_REG(cb_qp_offset,	5, 19,	0x1f)
+HEVC_DEC_REG(cr_qp_offset,	5, 14,	0x1f)
+HEVC_DEC_REG(sign_data_hide,	5, 12,	0x1)
+HEVC_DEC_REG(tempor_mvp_e,	5, 11,	0x1)
+HEVC_DEC_REG(max_cu_qpd_depth,	5, 5,	0x3f)
+HEVC_DEC_REG(cu_qpd_e,		5, 4,	0x1)
+
+HEVC_DEC_REG(stream_len,	6, 0,	0xffffffff)
+
+HEVC_DEC_REG(cabac_init_present, 7, 31, 0x1)
+HEVC_DEC_REG(weight_pred_e,	 7, 28, 0x1)
+HEVC_DEC_REG(weight_bipr_idc,	 7, 26, 0x3)
+HEVC_DEC_REG(filter_over_slices, 7, 25, 0x1)
+HEVC_DEC_REG(filter_over_tiles,  7, 24, 0x1)
+HEVC_DEC_REG(asym_pred_e,	 7, 23, 0x1)
+HEVC_DEC_REG(sao_e,		 7, 22, 0x1)
+HEVC_DEC_REG(pcm_filt_d,	 7, 21, 0x1)
+HEVC_DEC_REG(slice_chqp_present, 7, 20, 0x1)
+HEVC_DEC_REG(dependent_slice,	 7, 19, 0x1)
+HEVC_DEC_REG(filter_override,	 7, 18, 0x1)
+HEVC_DEC_REG(strong_smooth_e,	 7, 17, 0x1)
+HEVC_DEC_REG(filt_offset_beta,	 7, 12, 0x1f)
+HEVC_DEC_REG(filt_offset_tc,	 7, 7,  0x1f)
+HEVC_DEC_REG(slice_hdr_ext_e,	 7, 6,	0x1)
+HEVC_DEC_REG(slice_hdr_ext_bits, 7, 3,	0x7)
+
+HEVC_DEC_REG(const_intra_e,	 8, 31, 0x1)
+HEVC_DEC_REG(filt_ctrl_pres,	 8, 30, 0x1)
+HEVC_DEC_REG(idr_pic_e,		 8, 16, 0x1)
+HEVC_DEC_REG(bit_depth_pcm_y,	 8, 12, 0xf)
+HEVC_DEC_REG(bit_depth_pcm_c,	 8, 8,  0xf)
+HEVC_DEC_REG(bit_depth_y_minus8, 8, 6,  0x3)
+HEVC_DEC_REG(bit_depth_c_minus8, 8, 4,  0x3)
+HEVC_DEC_REG(output_8_bits,	 8, 3,  0x1)
+
+HEVC_DEC_REG(refidx1_active,	9, 19,	0x1f)
+HEVC_DEC_REG(refidx0_active,	9, 14,	0x1f)
+HEVC_DEC_REG(hdr_skip_length,	9, 0,	0x3fff)
+
+HEVC_DEC_REG(start_code_e,	10, 31, 0x1)
+HEVC_DEC_REG(init_qp,		10, 24, 0x3f)
+HEVC_DEC_REG(num_tile_cols,	10, 19, 0x1f)
+HEVC_DEC_REG(num_tile_rows,	10, 14, 0x1f)
+HEVC_DEC_REG(tile_e,		10, 1,	0x1)
+HEVC_DEC_REG(entropy_sync_e,	10, 0,	0x1)
+
+HEVC_DEC_REG(refer_lterm_e,	12, 16, 0xffff)
+HEVC_DEC_REG(min_cb_size,	12, 13, 0x7)
+HEVC_DEC_REG(max_cb_size,	12, 10, 0x7)
+HEVC_DEC_REG(min_pcm_size,	12, 7,  0x7)
+HEVC_DEC_REG(max_pcm_size,	12, 4,  0x7)
+HEVC_DEC_REG(pcm_e,		12, 3,  0x1)
+HEVC_DEC_REG(transform_skip,	12, 2,	0x1)
+HEVC_DEC_REG(transq_bypass,	12, 1,	0x1)
+HEVC_DEC_REG(list_mod_e,	12, 0,	0x1)
+
+HEVC_DEC_REG(min_trb_size,	  13, 13, 0x7)
+HEVC_DEC_REG(max_trb_size,	  13, 10, 0x7)
+HEVC_DEC_REG(max_intra_hierdepth, 13, 7,  0x7)
+HEVC_DEC_REG(max_inter_hierdepth, 13, 4,  0x7)
+HEVC_DEC_REG(parallel_merge,	  13, 0,  0xf)
+
+HEVC_DEC_REG(rlist_f0,		14, 0,	0x1f)
+HEVC_DEC_REG(rlist_f1,		14, 10,	0x1f)
+HEVC_DEC_REG(rlist_f2,		14, 20,	0x1f)
+HEVC_DEC_REG(rlist_b0,		14, 5,	0x1f)
+HEVC_DEC_REG(rlist_b1,		14, 15, 0x1f)
+HEVC_DEC_REG(rlist_b2,		14, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f3,		15, 0,	0x1f)
+HEVC_DEC_REG(rlist_f4,		15, 10, 0x1f)
+HEVC_DEC_REG(rlist_f5,		15, 20, 0x1f)
+HEVC_DEC_REG(rlist_b3,		15, 5,	0x1f)
+HEVC_DEC_REG(rlist_b4,		15, 15, 0x1f)
+HEVC_DEC_REG(rlist_b5,		15, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f6,		16, 0,	0x1f)
+HEVC_DEC_REG(rlist_f7,		16, 10, 0x1f)
+HEVC_DEC_REG(rlist_f8,		16, 20, 0x1f)
+HEVC_DEC_REG(rlist_b6,		16, 5,	0x1f)
+HEVC_DEC_REG(rlist_b7,		16, 15, 0x1f)
+HEVC_DEC_REG(rlist_b8,		16, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f9,		17, 0,	0x1f)
+HEVC_DEC_REG(rlist_f10,		17, 10, 0x1f)
+HEVC_DEC_REG(rlist_f11,		17, 20, 0x1f)
+HEVC_DEC_REG(rlist_b9,		17, 5,	0x1f)
+HEVC_DEC_REG(rlist_b10,		17, 15, 0x1f)
+HEVC_DEC_REG(rlist_b11,		17, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f12,		18, 0,	0x1f)
+HEVC_DEC_REG(rlist_f13,		18, 10, 0x1f)
+HEVC_DEC_REG(rlist_f14,		18, 20, 0x1f)
+HEVC_DEC_REG(rlist_b12,		18, 5,	0x1f)
+HEVC_DEC_REG(rlist_b13,		18, 15, 0x1f)
+HEVC_DEC_REG(rlist_b14,		18, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f15,		19, 0,	0x1f)
+HEVC_DEC_REG(rlist_b15,		19, 5,	0x1f)
+
+HEVC_DEC_REG(partial_ctb_x,	20, 31, 0x1)
+HEVC_DEC_REG(partial_ctb_y,	20, 30, 0x1)
+HEVC_DEC_REG(pic_width_4x4,	20, 16, 0xfff)
+HEVC_DEC_REG(pic_height_4x4,	20, 0,  0xfff)
+
+HEVC_DEC_REG(cur_poc_00,	46, 24,	0xff)
+HEVC_DEC_REG(cur_poc_01,	46, 16,	0xff)
+HEVC_DEC_REG(cur_poc_02,	46, 8,	0xff)
+HEVC_DEC_REG(cur_poc_03,	46, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_04,	47, 24,	0xff)
+HEVC_DEC_REG(cur_poc_05,	47, 16,	0xff)
+HEVC_DEC_REG(cur_poc_06,	47, 8,	0xff)
+HEVC_DEC_REG(cur_poc_07,	47, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_08,	48, 24,	0xff)
+HEVC_DEC_REG(cur_poc_09,	48, 16,	0xff)
+HEVC_DEC_REG(cur_poc_10,	48, 8,	0xff)
+HEVC_DEC_REG(cur_poc_11,	48, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_12,	49, 24, 0xff)
+HEVC_DEC_REG(cur_poc_13,	49, 16, 0xff)
+HEVC_DEC_REG(cur_poc_14,	49, 8,	0xff)
+HEVC_DEC_REG(cur_poc_15,	49, 0,	0xff)
+
+HEVC_DEC_REG(apf_threshold,	55, 0,	0xffff)
+
+HEVC_DEC_REG(clk_gate_e,	58, 16,	0x1)
+HEVC_DEC_REG(buswidth,		58, 8,	0x7)
+HEVC_DEC_REG(max_burst,		58, 0,	0xff)
+
+#define HEVC_REG_CONFIG				G2_SWREG(58)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_E		BIT(16)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_IDLE_E	BIT(17)
+
+#define HEVC_ADDR_DST		(G2_SWREG(65))
+#define HEVC_REG_ADDR_REF(i)	(G2_SWREG(67)  + ((i) * 0x8))
+#define HEVC_ADDR_DST_CHR	(G2_SWREG(99))
+#define HEVC_REG_CHR_REF(i)	(G2_SWREG(101) + ((i) * 0x8))
+#define HEVC_ADDR_DST_MV	(G2_SWREG(133))
+#define HEVC_REG_DMV_REF(i)	(G2_SWREG(135) + ((i) * 0x8))
+#define HEVC_ADDR_TILE_SIZE	(G2_SWREG(167))
+#define HEVC_ADDR_STR		(G2_SWREG(169))
+#define HEVC_SCALING_LIST	(G2_SWREG(171))
+#define HEVC_RASTER_SCAN	(G2_SWREG(175))
+#define HEVC_RASTER_SCAN_CHR	(G2_SWREG(177))
+#define HEVC_TILE_FILTER	(G2_SWREG(179))
+#define HEVC_TILE_SAO		(G2_SWREG(181))
+#define HEVC_TILE_BSD		(G2_SWREG(183))
+
+HEVC_DEC_REG(strm_buffer_len,	258, 0,	0xffffffff)
+HEVC_DEC_REG(strm_start_offset,	259, 0,	0xffffffff)
+
+#endif
diff --git a/drivers/staging/media/hantro/hantro_hevc.c b/drivers/staging/media/hantro/hantro_hevc.c
new file mode 100644
index 000000000000..3d40aea444f5
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_hevc.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include <linux/types.h>
+#include <media/v4l2-mem2mem.h>
+
+#include "hantro.h"
+#include "hantro_hw.h"
+
+#define VERT_FILTER_RAM_SIZE 8 /* bytes per pixel row */
+/*
+ * BSD control data of current picture at tile border
+ * 128 bits per 4x4 tile = 128/(8*4) bytes per row
+ */
+#define BSD_CTRL_RAM_SIZE 4 /* bytes per pixel row */
+/* tile border coefficients of filter */
+#define VERT_SAO_RAM_SIZE 48 /* bytes per pixel */
+
+#define MAX_TILE_COLS 20
+#define MAX_TILE_ROWS 22
+
+#define UNUSED_REF	-1
+
+#define G2_ALIGN		16
+
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	int bytes_per_pixel = sps->bit_depth_luma_minus8 == 0 ? 1 : 2;
+
+	return sps->pic_width_in_luma_samples *
+	       sps->pic_height_in_luma_samples * bytes_per_pixel;
+}
+
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+
+	return ALIGN((cr_offset * 3) / 2, G2_ALIGN);
+}
+
+static size_t hantro_hevc_mv_size(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	u32 min_cb_log2_size_y = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	u32 ctb_log2_size_y = min_cb_log2_size_y + sps->log2_diff_max_min_luma_coding_block_size;
+	u32 pic_width_in_ctbs_y = (sps->pic_width_in_luma_samples + (1 << ctb_log2_size_y) - 1) >> ctb_log2_size_y;
+	u32 pic_height_in_ctbs_y = (sps->pic_height_in_luma_samples + (1 << ctb_log2_size_y) - 1) >> ctb_log2_size_y;
+	size_t mv_size;
+
+	mv_size = pic_width_in_ctbs_y * pic_height_in_ctbs_y *
+		  (1 << (2 * (ctb_log2_size_y - 4))) * 16;
+
+	vpu_debug(4, "%dx%d (CTBs) %ld MV bytes\n",
+		  pic_width_in_ctbs_y, pic_height_in_ctbs_y, mv_size);
+
+	return mv_size;
+}
+
+static size_t hantro_hevc_ref_size(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+
+	return hantro_hevc_motion_vectors_offset(sps) + hantro_hevc_mv_size(sps);
+}
+
+static void hantro_hevc_ref_free(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	struct hantro_dev *vpu = ctx->dev;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs[i].cpu)
+			dma_free_coherent(vpu->dev, hevc_dec->ref_bufs[i].size,
+					  hevc_dec->ref_bufs[i].cpu,
+					  hevc_dec->ref_bufs[i].dma);
+	}
+}
+
+static void hantro_hevc_ref_init(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++)
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+}
+
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
+				   int poc)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Find the reference buffer in already know ones */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == poc) {
+			hevc_dec->ref_bufs_used |= 1 << i;
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	/* Allocate a new reference buffer */
+	for (i = 0; i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF) {
+			if (!hevc_dec->ref_bufs[i].cpu) {
+				struct hantro_dev *vpu = ctx->dev;
+
+				/*
+				 * Allocate the space needed for the raw data +
+				 * motion vector data. Optimizations could be to
+				 * allocate raw data in non coherent memory and only
+				 * clear the motion vector data.
+				 */
+				hevc_dec->ref_bufs[i].cpu =
+					dma_alloc_coherent(vpu->dev,
+							   hantro_hevc_ref_size(ctx),
+							   &hevc_dec->ref_bufs[i].dma,
+							   GFP_KERNEL);
+				if (!hevc_dec->ref_bufs[i].cpu)
+					return 0;
+
+				hevc_dec->ref_bufs[i].size = hantro_hevc_ref_size(ctx);
+			}
+			hevc_dec->ref_bufs_used |= 1 << i;
+			memset(hevc_dec->ref_bufs[i].cpu, 0, hantro_hevc_ref_size(ctx));
+			hevc_dec->ref_bufs_poc[i] = poc;
+
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	return 0;
+}
+
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Just tag buffer as unused, do not free them */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF)
+			continue;
+
+		if (hevc_dec->ref_bufs_used & (1 << i))
+			continue;
+
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+	}
+}
+
+static int tile_buffer_reallocate(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int height64 = (sps->pic_height_in_luma_samples + 63) & ~63;
+	unsigned int size;
+
+	if (num_tile_cols <= 1 ||
+	    num_tile_cols <= hevc_dec->num_tile_cols_allocated)
+		return 0;
+
+	/* Need to reallocate due to tiles passed via PPS */
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+
+	size = VERT_FILTER_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_filter.cpu = dma_alloc_coherent(vpu->dev, size,
+						       &hevc_dec->tile_filter.dma,
+						       GFP_KERNEL);
+	if (!hevc_dec->tile_filter.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_filter.size = size;
+
+	size = VERT_SAO_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_sao.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_sao.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_sao.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_sao.size = size;
+
+	size = BSD_CTRL_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_bsd.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_bsd.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_bsd.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_bsd.size = size;
+
+	hevc_dec->num_tile_cols_allocated = num_tile_cols;
+
+	return 0;
+
+err_free_tile_buffers:
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	return -ENOMEM;
+}
+
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_ctx = &ctx->hevc_dec;
+	struct hantro_hevc_dec_ctrls *ctrls = &hevc_ctx->ctrls;
+	int ret;
+
+	hantro_start_prepare_run(ctx);
+
+	ctrls->decode_params =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
+	if (WARN_ON(!ctrls->decode_params))
+		return -EINVAL;
+
+	ctrls->sps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_SPS);
+	if (WARN_ON(!ctrls->sps))
+		return -EINVAL;
+
+	ctrls->pps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_PPS);
+	if (WARN_ON(!ctrls->pps))
+		return -EINVAL;
+
+	ret = tile_buffer_reallocate(ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+
+	if (hevc_dec->tile_sizes.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sizes.size,
+				  hevc_dec->tile_sizes.cpu,
+				  hevc_dec->tile_sizes.dma);
+	hevc_dec->tile_sizes.cpu = NULL;
+
+	if (hevc_dec->tile_filter.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	hantro_hevc_ref_free(ctx);
+}
+
+int hantro_hevc_dec_init(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	unsigned int size;
+
+	memset(hevc_dec, 0, sizeof(*hevc_dec));
+
+	/*
+	 * Maximum number of tiles times width and height (2 bytes each),
+	 * rounding up to next 16 bytes boundary + one extra 16 byte
+	 * chunk (HW guys wanted to have this).
+	 */
+	size = round_up(MAX_TILE_COLS * MAX_TILE_ROWS * 4 * sizeof(u16) + 16, 16);
+	hevc_dec->tile_sizes.cpu = dma_alloc_coherent(vpu->dev, size,
+						      &hevc_dec->tile_sizes.dma,
+						      GFP_KERNEL);
+	if (!hevc_dec->tile_sizes.cpu)
+		return -ENOMEM;
+
+	hevc_dec->tile_sizes.size = size;
+
+	hantro_hevc_ref_init(ctx);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index a76852966578..5788188aae50 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -20,6 +20,8 @@
 #define MB_WIDTH(w)		DIV_ROUND_UP(w, MB_DIM)
 #define MB_HEIGHT(h)		DIV_ROUND_UP(h, MB_DIM)
 
+#define NUM_REF_PICTURES	(V4L2_HEVC_DPB_ENTRIES_NUM_MAX + 1)
+
 struct hantro_dev;
 struct hantro_ctx;
 struct hantro_buf;
@@ -90,6 +92,44 @@ struct hantro_h264_dec_hw_ctx {
 	struct hantro_h264_dec_ctrls ctrls;
 };
 
+/**
+ * struct hantro_hevc_dec_ctrls
+ * @decode_params: Decode params
+ * @sps:	SPS info
+ * @pps:	PPS info
+ * @hevc_hdr_skip_length: the number of data (in bits) to skip in the
+ *			  slice segment header syntax after 'slice type'
+ *			  token
+ */
+struct hantro_hevc_dec_ctrls {
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
+	const struct v4l2_ctrl_hevc_sps *sps;
+	const struct v4l2_ctrl_hevc_pps *pps;
+	u32 hevc_hdr_skip_length;
+};
+
+/**
+ * struct hantro_hevc_dec_hw_ctx
+ * @tile_sizes:		Tile sizes buffer
+ * @tile_filter:	Tile vertical filter buffer
+ * @tile_sao:		Tile SAO buffer
+ * @tile_bsd:		Tile BSD control buffer
+ * @dpb:	DPB
+ * @reflists:	P/B0/B1 reflists
+ * @ctrls:	V4L2 controls attached to a run
+ */
+struct hantro_hevc_dec_hw_ctx {
+	struct hantro_aux_buf tile_sizes;
+	struct hantro_aux_buf tile_filter;
+	struct hantro_aux_buf tile_sao;
+	struct hantro_aux_buf tile_bsd;
+	struct hantro_aux_buf ref_bufs[NUM_REF_PICTURES];
+	int ref_bufs_poc[NUM_REF_PICTURES];
+	u32 ref_bufs_used;
+	struct hantro_hevc_dec_ctrls ctrls;
+	unsigned int num_tile_cols_allocated;
+};
+
 /**
  * struct hantro_mpeg2_dec_hw_ctx
  * @qtable:		Quantization table
@@ -178,6 +218,15 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
+int hantro_hevc_dec_init(struct hantro_ctx *ctx);
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx);
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx);
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx);
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, int poc);
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx);
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps);
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps);
+
 static inline size_t
 hantro_h264_mv_size(unsigned int width, unsigned int height)
 {
-- 
2.25.1



From robh at kernel.org  Thu Apr  1 17:03:34 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 11:03:34 -0500
Subject: [PATCH v7 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and
 Status Registers module binding
In-Reply-To: <2e6b0bdd03da30446448e86eff69182e417ce43f.camel@nxp.com>
References: <1617172405-12962-1-git-send-email-victor.liu@nxp.com>
 <1617172405-12962-8-git-send-email-victor.liu@nxp.com>
 <1617198059.605916.2074860.nullmailer@robh.at.kernel.org>
 <2e6b0bdd03da30446448e86eff69182e417ce43f.camel@nxp.com>
Message-ID: <CAL_JsqLn5simeQ20jHhvdWn54DdkVHJf-f1Q4ij-1ff=vHpi-w@mail.gmail.com>

On Thu, Apr 1, 2021 at 4:18 AM Liu Ying <victor.liu at nxp.com> wrote:
>
> On Wed, 2021-03-31 at 08:40 -0500, Rob Herring wrote:
> > On Wed, 31 Mar 2021 14:33:18 +0800, Liu Ying wrote:
> > > This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.
> > >
> > > Reviewed-by: Rob Herring <robh at kernel.org>
> > > Signed-off-by: Liu Ying <victor.liu at nxp.com>
> > > ---
> > > v6->v7:
> > > * Add Rob's R-b tag.
> > >
> > > v5->v6:
> > > * Drop 'select' schema. (Rob)
> > >
> > > v4->v5:
> > > * Newly introduced in v5. (Rob)
> > >
> > >  .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml   | 192 +++++++++++++++++++++
> > >  1 file changed, 192 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
> > >
> >
> > My bot found errors running 'make dt_binding_check' on your patch:
> >
> > yamllint warnings/errors:
> >
> > dtschema/dtc warnings/errors:
> > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/syscon at 56221000/pxl2dpi: failed to match any schema with compatible: ['fsl,imx8qxp-pxl2dpi']
> > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/syscon at 56221000/ldb: failed to match any schema with compatible: ['fsl,imx8qxp-ldb']
> > Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.example.dt.yaml:0:0: /example-0/phy at 56228300: failed to match any schema with compatible: ['fsl,imx8qxp-mipi-dphy']
> >
>
> Sorry for the errors.
> But, my patch passes 'make dt_binding_check' locally upon
> v5.12-rc1-dontuse at least.
> My yamllint and dt-schema are up to date.
>
> Does your bot _additionally_ check all compatibles in example?
> I guess I missed something?

Yes, it now adds 'DT_CHECKER_FLAGS=-m' which is new and pending in
linux-next. It's off by default until we get rid of the ~90 existing
cases.

Rob


From lkp at intel.com  Thu Apr  1 17:03:58 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 00:03:58 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1296/1701]
 ./usr/include/linux/videodev2.h:2345:20: error: field 'timestamp' has
 incomplete type
Message-ID: <202104020052.2TAJK1gW-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 0b197959bbbdb68e1da974bd013339f08704b178 [1296/1701] staging: xlnxsync: Fix the uapi header license
config: i386-randconfig-r001-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/0b197959bbbdb68e1da974bd013339f08704b178
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 0b197959bbbdb68e1da974bd013339f08704b178
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from ./usr/include/linux/xilinx-sdirxss.h:7,
                    from <command-line>:32:
>> ./usr/include/linux/videodev2.h:2345:20: error: field 'timestamp' has incomplete type
    2345 |  struct timespec   timestamp;
         |                    ^~~~~~~~~
--
   In file included from <command-line>:32:
>> ./usr/include/linux/xlnx_mpg2tsmux_interface.h:58:2: error: unknown type name 'u8'
      58 |  u8 stream_id;
         |  ^~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:59:2: error: unknown type name 'u8'
      59 |  u8 extended_stream_id;
         |  ^~
>> ./usr/include/linux/xlnx_mpg2tsmux_interface.h:60:2: error: unknown type name 'bool'
      60 |  bool is_pcr_stream;
         |  ^~~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:61:2: error: unknown type name 'bool'
      61 |  bool is_valid_pts;
         |  ^~~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:62:2: error: unknown type name 'bool'
      62 |  bool is_valid_dts;
         |  ^~~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:63:2: error: unknown type name 'bool'
      63 |  bool is_dmabuf;
         |  ^~~~
>> ./usr/include/linux/xlnx_mpg2tsmux_interface.h:64:2: error: unknown type name 'u16'
      64 |  u16 pid;
         |  ^~~
>> ./usr/include/linux/xlnx_mpg2tsmux_interface.h:65:2: error: unknown type name 'u64'
      65 |  u64 size_data_in;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:66:2: error: unknown type name 'u64'
      66 |  u64 pts;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:67:2: error: unknown type name 'u64'
      67 |  u64 dts;
         |  ^~~
>> ./usr/include/linux/xlnx_mpg2tsmux_interface.h:68:2: error: unknown type name 'u32'
      68 |  u32 srcbuf_id;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:69:2: error: unknown type name 'bool'
      69 |  bool insert_pcr;
         |  ^~~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:70:2: error: unknown type name 'u16'
      70 |  u16 pcr_extension;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:71:2: error: unknown type name 'u64'
      71 |  u64 pcr_base;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:81:2: error: unknown type name 'bool'
      81 |  bool is_dmabuf;
         |  ^~~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:82:2: error: unknown type name 'u32'
      82 |  u32 dstbuf_id;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:83:2: error: unknown type name 'u32'
      83 |  u32 dmabuf_size;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:104:2: error: unknown type name 'u32'
     104 |  u32 num_buf;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:105:2: error: unknown type name 'u32'
     105 |  u32 buf_size;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:114:2: error: unknown type name 'u32'
     114 |  u32 buf_id;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:115:2: error: unknown type name 'u32'
     115 |  u32 buf_write;
         |  ^~~
   ./usr/include/linux/xlnx_mpg2tsmux_interface.h:137:2: error: unknown type name 'u16'
     137 |  u16 pid;
         |  ^~~
--
   In file included from <command-line>:32:
>> ./usr/include/linux/xlnxsync.h:44:2: error: unknown type name 'u64'
      44 |  u64 hdr_ver;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:45:2: error: unknown type name 'u64'
      45 |  u64 luma_start_offset[XLNXSYNC_IO];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:46:2: error: unknown type name 'u64'
      46 |  u64 chroma_start_offset[XLNXSYNC_IO];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:47:2: error: unknown type name 'u64'
      47 |  u64 luma_end_offset[XLNXSYNC_IO];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:48:2: error: unknown type name 'u64'
      48 |  u64 chroma_end_offset[XLNXSYNC_IO];
         |  ^~~
>> ./usr/include/linux/xlnxsync.h:49:2: error: unknown type name 'u32'
      49 |  u32 luma_margin;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:50:2: error: unknown type name 'u32'
      50 |  u32 chroma_margin;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:51:2: error: unknown type name 'u32'
      51 |  u32 luma_core_offset[XLNXSYNC_MAX_CORES];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:52:2: error: unknown type name 'u32'
      52 |  u32 chroma_core_offset[XLNXSYNC_MAX_CORES];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:53:2: error: unknown type name 'u32'
      53 |  u32 dma_fd;
         |  ^~~
>> ./usr/include/linux/xlnxsync.h:54:2: error: unknown type name 'u8'
      54 |  u8 fb_id[XLNXSYNC_IO];
         |  ^~
   ./usr/include/linux/xlnxsync.h:55:2: error: unknown type name 'u8'
      55 |  u8 ismono[XLNXSYNC_IO];
         |  ^~
   ./usr/include/linux/xlnxsync.h:67:2: error: unknown type name 'u64'
      67 |  u64 hdr_ver;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:68:2: error: unknown type name 'u8'
      68 |  u8 sync_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:69:2: error: unknown type name 'u8'
      69 |  u8 wdg_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:70:2: error: unknown type name 'u8'
      70 |  u8 ldiff_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:71:2: error: unknown type name 'u8'
      71 |  u8 cdiff_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:80:2: error: unknown type name 'u64'
      80 |  u64 hdr_ver;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:81:2: error: unknown type name 'u8'
      81 |  u8 status[XLNXSYNC_BUF_PER_CHAN][XLNXSYNC_IO];
         |  ^~
   ./usr/include/linux/xlnxsync.h:93:2: error: unknown type name 'u64'
      93 |  u64 hdr_ver;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:94:2: error: unknown type name 'u8'
      94 |  u8 encode;
         |  ^~
   ./usr/include/linux/xlnxsync.h:95:2: error: unknown type name 'u8'
      95 |  u8 max_channels;
         |  ^~
   ./usr/include/linux/xlnxsync.h:96:2: error: unknown type name 'u8'
      96 |  u8 active_channels;
         |  ^~
   ./usr/include/linux/xlnxsync.h:97:2: error: unknown type name 'u8'
      97 |  u8 reserved_id;
         |  ^~
   ./usr/include/linux/xlnxsync.h:98:2: error: unknown type name 'u32'
      98 |  u32 reserved[10];
         |  ^~~
   ./usr/include/linux/xlnxsync.h:112:2: error: unknown type name 'u64'
     112 |  u64 hdr_ver;
         |  ^~~
   ./usr/include/linux/xlnxsync.h:113:2: error: unknown type name 'u8'
     113 |  u8 fbdone[XLNXSYNC_BUF_PER_CHAN][XLNXSYNC_IO];
         |  ^~
   ./usr/include/linux/xlnxsync.h:114:2: error: unknown type name 'u8'
     114 |  u8 enable;
         |  ^~
   ./usr/include/linux/xlnxsync.h:115:2: error: unknown type name 'u8'
     115 |  u8 sync_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:116:2: error: unknown type name 'u8'
     116 |  u8 wdg_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:117:2: error: unknown type name 'u8'
     117 |  u8 ldiff_err;
         |  ^~
   ./usr/include/linux/xlnxsync.h:118:2: error: unknown type name 'u8'
     118 |  u8 cdiff_err;
         |  ^~
--
   In file included from <command-line>:32:
>> ./usr/include/linux/zocl_ioctl.h:42:2: error: unknown type name 'uint64_t'
      42 |  uint64_t size;
         |  ^~~~~~~~
>> ./usr/include/linux/zocl_ioctl.h:43:2: error: unknown type name 'uint32_t'
      43 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:44:2: error: unknown type name 'uint32_t'
      44 |  uint32_t flags;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:48:2: error: unknown type name 'uint32_t'
      48 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:49:2: error: unknown type name 'uint32_t'
      49 |  uint32_t pad;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:50:2: error: unknown type name 'uint64_t'
      50 |  uint64_t offset;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:61:2: error: unknown type name 'uint32_t'
      61 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:63:2: error: unknown type name 'uint64_t'
      63 |  uint64_t offset;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:64:2: error: unknown type name 'uint64_t'
      64 |  uint64_t size;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:74:2: error: unknown type name 'uint32_t'
      74 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:75:2: error: unknown type name 'uint64_t'
      75 |  uint64_t size;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:76:2: error: unknown type name 'uint64_t'
      76 |  uint64_t paddr;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:88:2: error: unknown type name 'uint32_t'
      88 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:89:2: error: unknown type name 'uint32_t'
      89 |  uint32_t pad;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:90:2: error: unknown type name 'uint64_t'
      90 |  uint64_t offset;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:91:2: error: unknown type name 'uint64_t'
      91 |  uint64_t size;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:92:2: error: unknown type name 'uint64_t'
      92 |  uint64_t data_ptr;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:104:2: error: unknown type name 'uint32_t'
     104 |  uint32_t handle;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:105:2: error: unknown type name 'uint32_t'
     105 |  uint32_t pad;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:106:2: error: unknown type name 'uint64_t'
     106 |  uint64_t offset;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:107:2: error: unknown type name 'uint64_t'
     107 |  uint64_t size;
         |  ^~~~~~~~
   ./usr/include/linux/zocl_ioctl.h:108:2: error: unknown type name 'uint64_t'
     108 |  uint64_t data_ptr;
         |  ^~~~~~~~

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35478 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/4dee8200/attachment-0001.gz>

From maciej.falkowski9 at gmail.com  Thu Apr  1 17:04:34 2021
From: maciej.falkowski9 at gmail.com (Maciej Falkowski)
Date: Thu,  1 Apr 2021 18:04:34 +0200
Subject: [PATCH] ARM: OMAP1: ams-delta: remove unused function
 ams_delta_camera_power
Message-ID: <20210401160434.7655-1-maciej.falkowski9@gmail.com>

The ams_delta_camera_power() function is unused as reports
Clang compilation with omap1_defconfig on linux-next:

arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function 'ams_delta_camera_power' [-Wunused-function]
static int ams_delta_camera_power(struct device *dev, int power)
           ^
1 warning generated.

The soc_camera support was dropped without removing
ams_delta_camera_power() function, making it unused.

Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies")
Link: https://github.com/ClangBuiltLinux/linux/issues/1326
---
 arch/arm/mach-omap1/board-ams-delta.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 2ee527c00284..1026a816dcc0 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -458,20 +458,6 @@ static struct gpiod_lookup_table leds_gpio_table = {
 
 #ifdef CONFIG_LEDS_TRIGGERS
 DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
-
-static int ams_delta_camera_power(struct device *dev, int power)
-{
-	/*
-	 * turn on camera LED
-	 */
-	if (power)
-		led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
-	else
-		led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
-	return 0;
-}
-#else
-#define ams_delta_camera_power	NULL
 #endif
 
 static struct platform_device ams_delta_audio_device = {
-- 
2.26.3



From f.fainelli at gmail.com  Thu Apr  1 17:06:41 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 1 Apr 2021 09:06:41 -0700
Subject: [PATCH net-next v1 3/3] net: fec: add basic selftest support
In-Reply-To: <20210401074751.so4m7k3pnhcjeofx@pengutronix.de>
References: <20210330135407.17010-1-o.rempel@pengutronix.de>
 <20210330135407.17010-4-o.rempel@pengutronix.de> <YGRqpxefTxZjqp6w@lunn.ch>
 <20210401074751.so4m7k3pnhcjeofx@pengutronix.de>
Message-ID: <ea8fd02b-69bb-ccd9-10c4-82f86bd972e9@gmail.com>

On 4/1/21 12:47 AM, Oleksij Rempel wrote:
> On Wed, Mar 31, 2021 at 02:27:19PM +0200, Andrew Lunn wrote:
>> On Tue, Mar 30, 2021 at 03:54:07PM +0200, Oleksij Rempel wrote:
>>> Port some parts of the stmmac selftest to the FEC. This patch was tested
>>> on iMX6DL.
>>> With this tests it is possible to detect some basic issues like:
>>> - MAC loopback fail: most probably wrong clock configuration.
>>> - PHY loopback fail: incorrect RGMII timings, damaged traces, etc
>>
>> Hi
>>
>> Oleksij
>>
>> I've not done a side-by-side diff with stmmac, but i guess a lot of
>> this code is identical?
> 
> ack
> 
>> Rather than make a copy/paste, could you move
>> it somewhere under net and turn it into a library any driver can use?
> 
> yes, I assume, it is possible to make this code complete generic for all
> devices, but we will need to provide some more call backs. For example
> enable MAC loop back, enable DSA loopbacks and so on.
> 
> Do you have ideas for the new location of generic selftest code and
> where  can be added loopback options for different levels?

You could place the generic selftest code under net/core/ or net/ethernet.
-- 
Florian


From yoong.siang.song at intel.com  Thu Apr  1 17:06:25 2021
From: yoong.siang.song at intel.com (Song, Yoong Siang)
Date: Thu, 1 Apr 2021 16:06:25 +0000
Subject: [PATCH net-next v4 0/6] stmmac: Add XDP support
In-Reply-To: <20210401021117.13360-1-boon.leong.ong@intel.com>
References: <20210401021117.13360-1-boon.leong.ong@intel.com>
Message-ID: <CY4PR1101MB2342702E5C52DEF4E905CCFBD87B9@CY4PR1101MB2342.namprd11.prod.outlook.com>

> Hi,
> 
> This is the v4 patch series for adding XDP native support to stmmac.
> 
> Changes in v4:
> 5/6: Move TX clean timer setup to the end of NAPI RX process and
>      group it under stmmac_finalize_xdp_rx().
>      Also, fixed stmmac_xdp_xmit_back() returns STMMAC_XDP_CONSUMED
>      if XDP buffer conversion to XDP frame fails.
> 
> 6/6: Move xdp_do_flush(0 into stmmac_finalize_xdp_rx() and combine
>      the XDP verdict of XDP TX and XDP REDIRECT together.
> 
> I retested the patch series on the 'xdp2' and 'xdp_redirect' related to changes
> above and found the result to be satisfactory.
> 
> History of previous patch series:
> v3:
> https://patchwork.kernel.org/project/netdevbpf/cover/20210331154135.850
> 7-1-boon.leong.ong at intel.com/
> v2: https://patchwork.kernel.org/project/netdevbpf/list/?series=457757
> v1: https://patchwork.kernel.org/project/netdevbpf/list/?series=457139
> 
> It will be great if community can help to test or review the v4 series and
> provide me any input if any.
> 
> Thank you very much,
> Boon Leong
> 
> Ong Boon Leong (6):
>   net: stmmac: set IRQ affinity hint for multi MSI vectors
>   net: stmmac: make SPH enable/disable to be configurable
>   net: stmmac: arrange Tx tail pointer update to
>     stmmac_flush_tx_descriptors
>   net: stmmac: Add initial XDP support
>   net: stmmac: Add support for XDP_TX action
>   net: stmmac: Add support for XDP_REDIRECT action
> 
>  drivers/net/ethernet/stmicro/stmmac/Makefile  |   1 +
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  35 +-
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 539 +++++++++++++++---
> .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  40 ++
> .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |  12 +
>  5 files changed, 547 insertions(+), 80 deletions(-)  create mode 100644
> drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
> 
> --
> 2.25.1

I tested these patches on my Intel ADL platform using xdp1, xdp2,
xdp-redirect, xdp-redirect-cpu and xdp-adjust-tail apps in
samples/bpf. Samples/pktgen/pktgen_sample03_burst_single_flow.sh script
is used to send burst traffics from link partner (LP) to ADL platform.
Thev result looked good and satisfying. Following shows the test steps
and results that are obtained using Intel mGbE controller under
preempt-rt environment.

Board Setup
###########
 ___________________               ___________________
|                   |             |                   |
|         enp0s30f4 | <---------> | enp0s30f4         |
|  ADL              |                           LP    |
|         enp0s30f5 | <---------> | enp0s30f5         |
|___________________|             |___________________|

XDP_DROP Native mode
####################
ADL:~# taskset -c 1 ./xdp1 enp0s30f4
libbpf: elf: skipping unrecognized data section(16) .eh_frame
libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
proto 17:          0 pkt/s
proto 17:          6 pkt/s
proto 17:     658310 pkt/s
proto 17:     679719 pkt/s
proto 17:     681285 pkt/s
proto 17:     681035 pkt/s
proto 17:     680345 pkt/s
proto 17:     678550 pkt/s
proto 17:     680796 pkt/s
proto 17:     681186 pkt/s

XDP_DROP skb mode
#################
ADL:~# taskset -c 1 ./xdp -S enp0s30f4
libbpf: elf: skipping unrecognized data section(16) .eh_frame
libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
proto 17:          0 pkt/s
proto 17:          0 pkt/s
proto 17:     113288 pkt/s
proto 17:     244100 pkt/s
proto 17:     222234 pkt/s
proto 17:     246207 pkt/s
proto 17:     245042 pkt/s
proto 17:     228392 pkt/s
proto 17:     243027 pkt/s
proto 17:     195756 pkt/s

XDP_REDIRECT (CPU 0 -> CPU 0)
#############################
ADL:~# ./xdp_redirect_cpu-dev enp0s30f4 --cpu 0
libbpf: elf: skipping unrecognized data section(39) .eh_frame
libbpf: elf: skipping relo section(40) .rel.eh_frame for section(39) .eh_frame
libbpf: elf: skipping unrecognized data section(20) .eh_frame
libbpf: elf: skipping relo section(21) .rel.eh_frame for section(20) .eh_frame
Add-new CPU:0 as idx:0 qsize:192 prog_fd: 33 (cpus_count:1)
Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          total   0              0
cpumap_kthread  total   0              0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  total   0              0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       345,419        0           0
XDP-RX          total   345,419        0
cpumap-enqueue    0:0   345,437        221,150     7.82       bulk-average
cpumap-enqueue  sum:0   345,437        221,150     7.82       bulk-average
cpumap_kthread  0       124,204        0           0
cpumap_kthread  total   124,204        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  0       124,204        0           0
xdp-in-kthread  total   124,204        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       670,172        0           0
XDP-RX          total   670,172        0
cpumap-enqueue    0:0   670,156        387,270     7.81       bulk-average
cpumap-enqueue  sum:0   670,156        387,270     7.81       bulk-average
cpumap_kthread  0       282,904        0           0
cpumap_kthread  total   282,904        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  0       282,904        0           0
xdp-in-kthread  total   282,904        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       660,924        0           0
XDP-RX          total   660,924        0
cpumap-enqueue    0:0   660,931        393,566     7.81       bulk-average
cpumap-enqueue  sum:0   660,931        393,566     7.81       bulk-average
cpumap_kthread  0       267,350        0           0
cpumap_kthread  total   267,350        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  0       267,351        0           0
xdp-in-kthread  total   267,351        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       671,898        0           0
XDP-RX          total   671,898        0
cpumap-enqueue    0:0   671,890        398,465     7.81       bulk-average
cpumap-enqueue  sum:0   671,890        398,465     7.81       bulk-average
cpumap_kthread  0       273,429        0           0
cpumap_kthread  total   273,429        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  0       273,429        0           0
xdp-in-kthread  total   273,429        0           0

XDP_REDIRECT (CPU 0 -> CPU 1)
#############################
ADL:~# ./xdp_redirect_cpu --dev enp0s30f4 --cpu 1
libbpf: elf: skipping unrecognized data section(39) .eh_frame
libbpf: elf: skipping relo section(40) .rel.eh_frame for section(39) .eh_frame
libbpf: elf: skipping unrecognized data section(20) .eh_frame
libbpf: elf: skipping relo section(21) .rel.eh_frame for section(20) .eh_frame
Add-new CPU:1 as idx:0 qsize:192 prog_fd: 33 (cpus_count:1)
Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          total   0              0
cpumap_kthread  total   0              0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  total   0              0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       427,639        0           0
XDP-RX          total   427,639        0
cpumap-enqueue    0:1   427,642        202,047     7.81       bulk-average
cpumap-enqueue  sum:1   427,642        202,047     7.81       bulk-average
cpumap_kthread  1       225,528        0           0
cpumap_kthread  total   225,528        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  1       225,528        0           0
xdp-in-kthread  total   225,528        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       666,549        0           0
XDP-RX          total   666,549        0
cpumap-enqueue    0:1   666,569        315,294     7.81       bulk-average
cpumap-enqueue  sum:1   666,569        315,294     7.81       bulk-average
cpumap_kthread  1       351,251        0           0
cpumap_kthread  total   351,251        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  1       351,252        0           0
xdp-in-kthread  total   351,252        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       671,218        0           0
XDP-RX          total   671,218        0
cpumap-enqueue    0:1   671,198        322,057     7.81       bulk-average
cpumap-enqueue  sum:1   671,198        322,057     7.81       bulk-average
cpumap_kthread  1       349,168        0           0
cpumap_kthread  total   349,168        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  1       349,169        0           0
xdp-in-kthread  total   349,169        0           0

Running XDP/eBPF prog_name:xdp_cpu_map5_lb_hash_ip_pairs
XDP-cpumap      CPU:to  pps            drop-pps    extra-info
XDP-RX          0       663,667        0           0
XDP-RX          total   663,667        0
cpumap-enqueue    0:1   663,682        317,167     7.81       bulk-average
cpumap-enqueue  sum:1   663,682        317,167     7.81       bulk-average
cpumap_kthread  1       346,498        0           0
cpumap_kthread  total   346,498        0           0
redirect_err    total   0              0
xdp_exception   total   0              0

2nd remote XDP/eBPF prog_name: xdp_redirect_dummy
XDP-cpumap      CPU:to  xdp-pass       xdp-drop    xdp-redir
xdp-in-kthread  1       346,498        0           0
xdp-in-kthread  total   346,498        0           0

XDP_TX Native mode
##################
ADL:~# taskset -c 1 ./xdp2 enp0s30f4
libbpf: elf: skipping unrecognized data section(16) .eh_frame
libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
proto 17:          0 pkt/s
proto 17:      53032 pkt/s
proto 17:     710618 pkt/s
proto 17:     711055 pkt/s
proto 17:     711740 pkt/s
proto 17:     711797 pkt/s
proto 17:     707434 pkt/s
proto 17:     684045 pkt/s
proto 17:     707764 pkt/s
proto 17:     712372 pkt/s

LP:~# tcpdump -nei enp0s30f4 udp port 5100 -Q in						
20:49:18.963638 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:49:18.963638 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:49:18.963638 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:49:18.963638 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:49:18.963638 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18

XDP_TX skb mode
###############
ADL:~# taskset -c 1 ./xdp2 -S enp0s30f4
libbpf: elf: skipping unrecognized data section(16) .eh_frame
libbpf: elf: skipping relo section(17) .rel.eh_frame for section(16) .eh_frame
proto 17:          0 pkt/s
proto 17:          0 pkt/s
proto 17:     128325 pkt/s
proto 17:     179723 pkt/s
proto 17:     185476 pkt/s
proto 17:     182408 pkt/s
proto 17:     185688 pkt/s
proto 17:     172516 pkt/s
proto 17:     185351 pkt/s
proto 17:     184617 pkt/s

LP:~# tcpdump -nei enp0s30f4 udp port 5100 -Q in
20:51:39.613069 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:51:39.613373 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:51:39.613486 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:51:39.613581 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:51:39.613684 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18

XDP_REDIRECT Native mode (enp0s30f4 Rx -> enp0s30f5 Tx)
#######################################################
ADL:~# ./xdp_redirect enp0s30f4 enp0s30f5
input: 5 output: 6
libbpf: elf: skipping unrecognized data section(20) .eh_frame
libbpf: elf: skipping relo section(21) .rel.eh_frame for section(20) .eh_frame
ifindex 6:          0 pkt/s
ifindex 6:     136241 pkt/s
ifindex 6:     702588 pkt/s
ifindex 6:     703771 pkt/s
ifindex 6:     702328 pkt/s
ifindex 6:     703372 pkt/s
ifindex 6:     700253 pkt/s
ifindex 6:     702647 pkt/s

LP:~# tcpdump -nei enp0s30f5 udp port 5100 -Q in
20:59:49.846614 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:59:49.846614 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:59:49.846614 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:59:49.846634 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
20:59:49.846634 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18

XDP_REDIRECT skb mode (enp0s30f4 Rx -> enp0s30f5 Tx)
####################################################
ADL:~/# ./xdp_redirect -S enp0s30f4 enp0s30f5
input: 5 output: 6
libbpf: elf: skipping unrecognized data section(20) .eh_frame
libbpf: elf: skipping relo section(21) .rel.eh_frame for section(20) .eh_frame
ifindex 6:          0 pkt/s
ifindex 6:     166041 pkt/s
ifindex 6:     186639 pkt/s
ifindex 6:     176872 pkt/s
ifindex 6:     184643 pkt/s
ifindex 6:     188171 pkt/s
ifindex 6:     183235 pkt/s

LP:~# tcpdump -nei enp0s30f5 udp port 5100 -Q in
21:10:09.650126 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
21:10:09.650144 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
21:10:09.650145 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
21:10:09.650145 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18
21:10:09.650146 88:ab:cd:00:ef:5c > 88:ab:cd:11:01:23, ethertype IPv4
(0x0800), length 60: 169.254.1.22.9 > 169.254.1.11.5100: UDP, length 18

XDP_ADJUST_TAIL skb mode
########################
ADL:~# ./xdp_adjust_tail -i enp0s30f4 -P 400 -S
libbpf: elf: skipping unrecognized data section(18) .eh_frame
libbpf: elf: skipping relo section(19) .rel.eh_frame for section(18) .eh_frame
icmp "packet too big" sent:          0 pkts
icmp "packet too big" sent:          0 pkts
icmp "packet too big" sent:          0 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts
icmp "packet too big" sent:         10 pkts

LP:~# ping 169.254.1.11 -s 300 -i 0.1 -c 10
PING 169.254.1.11 (169.254.1.11) 300(328) bytes of data.
308 bytes from 169.254.1.11: icmp_seq=1 ttl=64 time=0.943 ms
308 bytes from 169.254.1.11: icmp_seq=2 ttl=64 time=1.04 ms
308 bytes from 169.254.1.11: icmp_seq=3 ttl=64 time=1.13 ms
308 bytes from 169.254.1.11: icmp_seq=4 ttl=64 time=0.974 ms
308 bytes from 169.254.1.11: icmp_seq=5 ttl=64 time=1.08 ms
308 bytes from 169.254.1.11: icmp_seq=6 ttl=64 time=0.951 ms
308 bytes from 169.254.1.11: icmp_seq=7 ttl=64 time=1.10 ms
308 bytes from 169.254.1.11: icmp_seq=8 ttl=64 time=0.878 ms
308 bytes from 169.254.1.11: icmp_seq=9 ttl=64 time=1.34 ms
308 bytes from 169.254.1.11: icmp_seq=10 ttl=64 time=1.20 ms

--- 169.254.1.11 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 907ms
rtt min/avg/max/mdev = 0.878/1.063/1.340/0.131 ms

LP:~# ping 169.254.1.11 -s 500 -i 0.1 -c 10
PING 169.254.1.11 (169.254.1.11) 500(528) bytes of data.

--- 169.254.1.11 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 933ms

XDP_ADJUST_TAIL Native mode
###########################
ADL:~# ./xdp_adjust_tail -i enp0s30f4 -P 400 -N
libbpf: elf: skipping unrecognized data section(18) .eh_frame
libbpf: elf: skipping relo section(19) .rel.eh_frame for section(18) .eh_frame
icmp "packet too big" sent:          0 pkts
icmp "packet too big" sent:          0 pkts
icmp "packet too big" sent:          1 pkts
icmp "packet too big" sent:          1 pkts
icmp "packet too big" sent:          2 pkts
icmp "packet too big" sent:          2 pkts
icmp "packet too big" sent:          2 pkts
icmp "packet too big" sent:         12 pkts
icmp "packet too big" sent:         13 pkts
icmp "packet too big" sent:         14 pkts

LP:~# ping 169.254.1.11 -s 300 -i 0.1 -c 10
PING 169.254.1.11 (169.254.1.11) 300(328) bytes of data.
308 bytes from 169.254.1.11: icmp_seq=1 ttl=64 time=1.00 ms
308 bytes from 169.254.1.11: icmp_seq=2 ttl=64 time=0.829 ms
308 bytes from 169.254.1.11: icmp_seq=3 ttl=64 time=1.12 ms
308 bytes from 169.254.1.11: icmp_seq=4 ttl=64 time=1.06 ms
308 bytes from 169.254.1.11: icmp_seq=5 ttl=64 time=0.946 ms
308 bytes from 169.254.1.11: icmp_seq=6 ttl=64 time=1.14 ms
308 bytes from 169.254.1.11: icmp_seq=7 ttl=64 time=1.10 ms
308 bytes from 169.254.1.11: icmp_seq=8 ttl=64 time=1.10 ms
308 bytes from 169.254.1.11: icmp_seq=9 ttl=64 time=1.04 ms
308 bytes from 169.254.1.11: icmp_seq=10 ttl=64 time=0.870 ms

--- 169.254.1.11 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 909ms
rtt min/avg/max/mdev = 0.829/1.020/1.136/0.101 ms

LP:~# ping 169.254.1.11 -s 500 -i 0.1 -c 10
PING 169.254.1.11 (169.254.1.11) 500(528) bytes of data.
From 169.254.1.11 icmp_seq=7 Frag needed and DF set (mtu = 386)
From 169.254.1.11 icmp_seq=9 Frag needed and DF set (mtu = 386)

--- 169.254.1.11 ping statistics ---
10 packets transmitted, 0 received, +2 errors, 100% packet loss, time 930ms

Regards
Song, Yoong Siang

From maciej.falkowski9 at gmail.com  Thu Apr  1 17:11:27 2021
From: maciej.falkowski9 at gmail.com (Maciej Falkowski)
Date: Thu,  1 Apr 2021 18:11:27 +0200
Subject: [PATCH] ARM: OMAP: Fix use of possibly uninitialized irq variable
Message-ID: <20210401161127.8942-1-maciej.falkowski9@gmail.com>

The current control flow of IRQ number assignment to `irq` variable
allows a request of IRQ of unspecified value,
generating a warning under Clang compilation with omap1_defconfig on linux-next:

arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used uninitialized whenever
'if' condition is false [-Wsometimes-uninitialized]
        else if (cpu_is_omap16xx())
                 ^~~~~~~~~~~~~~~~~
./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro 'cpu_is_omap16xx'
                                        ^~~~~~~~~~~~~
arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here
        if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
                        ^~~
arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is always true
        else if (cpu_is_omap16xx())
             ^~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to silence this warning
        int irq;
               ^
                = 0
1 warning generated.

The patch provides a default value to the `irq` variable
along with a validity check.

Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1324
---
 arch/arm/mach-omap1/pm.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 2c1e2b32b9b3..a745d64d4699 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -655,9 +655,13 @@ static int __init omap_pm_init(void)
 		irq = INT_7XX_WAKE_UP_REQ;
 	else if (cpu_is_omap16xx())
 		irq = INT_1610_WAKE_UP_REQ;
-	if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
-			NULL))
-		pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
+	else
+		irq = -1;
+
+	if (irq >= 0) {
+		if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", NULL))
+			pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
+	}
 
 	/* Program new power ramp-up time
 	 * (0 for most boards since we don't lower voltage when in deep sleep)
-- 
2.26.3



From james.morse at arm.com  Thu Apr  1 17:15:09 2021
From: james.morse at arm.com (James Morse)
Date: Thu, 1 Apr 2021 17:15:09 +0100
Subject: [PATCH RFC] soc: fujitsu: Add cache driver code
In-Reply-To: <OSAPR01MB21463C735D4A07344F35E7CC8B7C9@OSAPR01MB2146.jpnprd01.prod.outlook.com>
References: <1614764303-34903-1-git-send-email-tan.shaopeng@jp.fujitsu.com>
 <1614764303-34903-2-git-send-email-tan.shaopeng@jp.fujitsu.com>
 <CAK8P3a0VUoixMKg5UmF8agAZUXoMT8_SbCiWBdStbZ+_yAYNjA@mail.gmail.com>
 <OSAPR01MB2146DC8A26F6EBD1CF11D9748B979@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <20210304104650.GA20843@willie-the-truck>
 <CAK8P3a2pFcNTw9NpRtQfYr7A5OcZ=As2kM0D_sbfFcGQ_J2Q+Q@mail.gmail.com>
 <OSAPR01MB21463C735D4A07344F35E7CC8B7C9@OSAPR01MB2146.jpnprd01.prod.outlook.com>
Message-ID: <edaea436-d94e-d862-1136-66e9f881e0cc@arm.com>

Hi Tan Shaopeng,

On 31/03/2021 09:52, tan.shaopeng at fujitsu.com wrote:
>>> Given that all of this is outside of the scope of the architecture, I
>>> don't think that arch/arm64/ is the right place for it. Perhaps this
>>> would fit into the resctrl rework that James has been doing for MPAM?
>>
>> Indeed, that sounds like a good starting point. I don't understand enough about
>> either of the two to be sure, but it sounds like there is some overlap in
>> functionality, and ideally we would have one user interface that can deal with
>> all the hardware implementations (intel, arm, fujitsu and any future ones).

> According to my study, it seems possible to add A64FX's sector cache function
> to resctrl.

I think this depends on whether it maps to one of Intel RDT's existing schema.
While adding new ones looks easy, it is bad for user-space as they are not portable
between machines that support resctrl.


> I heard you are working on resctrl rework for MPAM , 
> but I cannot find related patches on ML archive. Therefore, 
> I would like to know the status about MPAM support. 

Its about five or six series that refactor resctrl inside arch/x86 to have a clear
boundary between arch-specific code and the resctrl code that implements the filesystem,
then pull it out to /fs/ and build the MPAM driver to make it work for arm64.

Unfortunately, its rather large (>100 patches), so will take some time to be reviewed.


> (1) I think the first step is to support resctrl for ARM arch. 
>    Have you finished the work of arm support and when will you release it? 

No-one wants a second copy of the code to implement resctrl, as this will introduce subtle
bugs that user-space would have to work around, and make it harder to merge later.

The first step is to refactor the arch/x86 implementation of resctrl so that the parts
that are visible to user-space can be moved somewhere that is common to multiple
architectures.

I've posted the next chunk of that work here:
https://lore.kernel.org/lkml/20210312175849.8327-1-james.morse at arm.com/

> (2) When will you release MPAM patch?

The latest complete version of the tree is here:
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/snapshot/feb

It is over a year old, and has plenty of bugs.

I hope to push a newer version of the branch once I have a complete copy of the tree that
has been tested, and is based on the current version of the ACPI table.



Thanks,

James


From maciej.falkowski9 at gmail.com  Thu Apr  1 17:20:32 2021
From: maciej.falkowski9 at gmail.com (Maciej Falkowski)
Date: Thu,  1 Apr 2021 18:20:32 +0200
Subject: [PATCH] usb: isp1301-omap: Add missing gpiod_add_lookup_table function
Message-ID: <20210401162032.10150-1-maciej.falkowski9@gmail.com>

The gpiod table was added without any usage making it unused
as reported by Clang compilation from omap1_defconfig on linux-next:

arch/arm/mach-omap1/board-h2.c:347:34: warning: unused variable 'isp1301_gpiod_table' [-Wunused-variable]
static struct gpiod_lookup_table isp1301_gpiod_table = {
                                 ^
1 warning generated.

The patch adds the missing gpiod_add_lookup_table() function.

Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
Fixes: f3ef38160e3d ("usb: isp1301-omap: Convert to use GPIO descriptors")
Link: https://github.com/ClangBuiltLinux/linux/issues/1325
---
 arch/arm/mach-omap1/board-h2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index c40cf5ef8607..977b0b744c22 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -320,7 +320,7 @@ static int tps_setup(struct i2c_client *client, void *context)
 {
 	if (!IS_BUILTIN(CONFIG_TPS65010))
 		return -ENOSYS;
-	
+
 	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
 				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
 
@@ -394,6 +394,8 @@ static void __init h2_init(void)
 	BUG_ON(gpio_request(H2_NAND_RB_GPIO_PIN, "NAND ready") < 0);
 	gpio_direction_input(H2_NAND_RB_GPIO_PIN);
 
+	gpiod_add_lookup_table(&isp1301_gpiod_table);
+
 	omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
 	omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
 
-- 
2.26.3



From nicolas.ferre at microchip.com  Thu Apr  1 17:22:07 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Thu, 1 Apr 2021 18:22:07 +0200
Subject: [GIT PULL] ARM: at91: defconfig for 5.13
Message-ID: <20210401162207.29299-1-nicolas.ferre@microchip.com>

From: Nicolas Ferre <nicolas.ferre at microchip.com>

Arnd, Olof,

Here are the defconfig changes for 5.13 which is bigger than usual for aligning
with options that we use frequently and some changes which will be beneficial
for CI.
There is an update with savedefconfig included, tell me if you prefer the PR
without this first patch of the series.

Thanks, best regards,
  Nicolas

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-5.13

for you to fetch changes up to 4136c4443efce6f028eca74885870ac649981da1:

  ARM: configs: at91: Modernize UBI defconfig part (2021-03-29 11:27:14 +0200)

----------------------------------------------------------------
AT91 defconfig for 5.13:

- aligment with recent kernel for sama5_defconfig
- move of 2 options to built-in
- addition of useful modules for validation and CI
- addition of Hantro G1 VPU from staging

----------------------------------------------------------------
Codrin Ciubotariu (1):
      ARM: configs: at91: sama5: Add audio MIKROE PROTO board

Emil Velikov (2):
      ARM: configs: at91: sama5: update with savedefconfig
      ARM: configs: at91: sama5: enable the Hantro G1 engine

Nicolas Ferre (4):
      ARM: configs: at91: sama5: MCP16502 regulator as built-in
      ARM: configs: at91: Add mtd tests as modules
      ARM: configs: at91: Add USB Video webcam class
      ARM: configs: at91: Modernize UBI defconfig part

Razvan Stefanescu (2):
      ARM: configs: at91: sama5: PIOBU as built-in
      ARM: configs: at91: sama5: Enable LAN78XX as module

 arch/arm/configs/at91_dt_defconfig |  5 +++-
 arch/arm/configs/sama5_defconfig   | 51 ++++++++++++++++++++---------------
 2 files changed, 33 insertions(+), 23 deletions(-)

-- 
Nicolas Ferre


From robh at kernel.org  Thu Apr  1 17:36:40 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 11:36:40 -0500
Subject: [PATCH v7 4/8] dt-bindings: regulator: Add document for MT6359
 regulator
In-Reply-To: <1617188527-3392-5-git-send-email-hsin-hsiung.wang@mediatek.com>
References: <1617188527-3392-1-git-send-email-hsin-hsiung.wang@mediatek.com>
 <1617188527-3392-5-git-send-email-hsin-hsiung.wang@mediatek.com>
Message-ID: <20210401163640.GA562289@robh.at.kernel.org>

On Wed, 31 Mar 2021 19:02:03 +0800, Hsin-Hsiung Wang wrote:
> add dt-binding document for MediaTek MT6359 PMIC
> 
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang at mediatek.com>
> ---
> changes since v6:
> - fix yaml error.
> ---
>  .../bindings/regulator/mt6359-regulator.yaml  | 385 ++++++++++++++++++
>  1 file changed, 385 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From will at kernel.org  Thu Apr  1 17:37:05 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 17:37:05 +0100
Subject: [RFC PATCH 3/5] iommu: Add support for the unmap_pages IOMMU
 callback
In-Reply-To: <f57e2151-1199-46f0-21ed-e401be358857@arm.com>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
 <20210331030042.13348-4-isaacm@codeaurora.org>
 <f57e2151-1199-46f0-21ed-e401be358857@arm.com>
Message-ID: <20210401163705.GA9281@willie-the-truck>

On Thu, Apr 01, 2021 at 04:34:37PM +0100, Robin Murphy wrote:
> On 2021-03-31 04:00, Isaac J. Manjarres wrote:
> > The IOMMU framework currently unmaps memory one page block at a time,
> > per the page block sizes that are supported by the IOMMU hardware.
> > Now that IOMMU drivers can supply a callback for unmapping multiple
> > in one call, add support in the IOMMU framework to calculate how many
> > page mappings of the same size can be unmapped in one shot, and invoke the
> > IOMMU driver's unmap_pages callback if it has one. Otherwise, the
> > existing behavior will be used.
> > 
> > Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> > Suggested-by: Will Deacon <will at kernel.org>
> > ---
> >   drivers/iommu/iommu.c | 44 +++++++++++++++++++++++++++++++++++++------
> >   1 file changed, 38 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index d0b0a15dba84..dc4295f6bc7f 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -2356,8 +2356,8 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
> >   }
> >   EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
> > -static size_t iommu_pgsize(struct iommu_domain *domain,
> > -			   unsigned long addr_merge, size_t size)
> > +static size_t __iommu_pgsize(struct iommu_domain *domain,
> > +			     unsigned long addr_merge, size_t size)
> >   {
> >   	unsigned int pgsize_idx;
> >   	size_t pgsize;
> > @@ -2388,6 +2388,24 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
> >   	return pgsize;
> >   }
> > +static size_t iommu_pgsize(struct iommu_domain *domain,
> > +			   unsigned long addr_merge, size_t size,
> > +			   size_t *pgcount)
> > +{
> > +	size_t pgsize = __iommu_pgsize(domain, addr_merge, size);
> > +	size_t pgs = 0;
> > +
> > +	do {
> > +		pgs++;
> > +		size -= pgsize;
> > +		addr_merge += pgsize;
> > +	} while (size && __iommu_pgsize(domain, addr_merge, size) == pgsize);
> 
> This looks horrifically inefficient. As part of calculating the best current
> page size it should then be pretty trivial to calculate "(size &
> next_pgsize_up - 1) >> pgsize_idx" for the number of current-size pages up
> to the next-better-size boundary (with next_pgsize_up being 0 if pgsize is
> already the largest possible for the relative alignment of physical and
> virtual address). A loop is just... yuck :(

Hehe, I'm glad you said that as I was thinking the same thing. It's
surprisingly fiddly to get this right, but I spent some time hacking it
today and I _think_ I have something that Isaac could build on (and
hopefully won't be too hairy for ->map either).

I'll post it as an RFC in a sec...

Will


From nathan at kernel.org  Thu Apr  1 17:37:32 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Thu, 1 Apr 2021 09:37:32 -0700
Subject: [PATCH] ARM: OMAP1: ams-delta: remove unused function
 ams_delta_camera_power
In-Reply-To: <20210401160434.7655-1-maciej.falkowski9@gmail.com>
References: <20210401160434.7655-1-maciej.falkowski9@gmail.com>
Message-ID: <20210401163732.gl63gs2dpi6pickt@archlinux-ax161>

On Thu, Apr 01, 2021 at 06:04:34PM +0200, Maciej Falkowski wrote:
> The ams_delta_camera_power() function is unused as reports
> Clang compilation with omap1_defconfig on linux-next:
> 
> arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function 'ams_delta_camera_power' [-Wunused-function]
> static int ams_delta_camera_power(struct device *dev, int power)
>            ^
> 1 warning generated.
> 
> The soc_camera support was dropped without removing
> ams_delta_camera_power() function, making it unused.
> 
> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
> Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1326

Thanks for the patch!

Reviewed-by: Nathan Chancellor <nathan at kernel.org>

> ---
>  arch/arm/mach-omap1/board-ams-delta.c | 14 --------------
>  1 file changed, 14 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 2ee527c00284..1026a816dcc0 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -458,20 +458,6 @@ static struct gpiod_lookup_table leds_gpio_table = {
>  
>  #ifdef CONFIG_LEDS_TRIGGERS
>  DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
> -
> -static int ams_delta_camera_power(struct device *dev, int power)
> -{
> -	/*
> -	 * turn on camera LED
> -	 */
> -	if (power)
> -		led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
> -	else
> -		led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
> -	return 0;
> -}
> -#else
> -#define ams_delta_camera_power	NULL
>  #endif
>  
>  static struct platform_device ams_delta_audio_device = {
> -- 
> 2.26.3
> 


From robh at kernel.org  Thu Apr  1 17:37:45 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 11:37:45 -0500
Subject: [PATCH v4 7/7] dt-bindings: clock: st: clkgen-fsyn: add new
 introduced compatible
In-Reply-To: <20210331201632.24530-8-avolmat@me.com>
References: <20210331201632.24530-1-avolmat@me.com>
 <20210331201632.24530-8-avolmat@me.com>
Message-ID: <20210401163745.GA572347@robh.at.kernel.org>

On Wed, 31 Mar 2021 22:16:32 +0200, Alain Volmat wrote:
> New compatible are added, supporting various kind of clkgen-fsyn
> used for STiH407, STiH410 and STiH418
> 
> Signed-off-by: Alain Volmat <avolmat at me.com>
> ---
>  Documentation/devicetree/bindings/clock/st/st,quadfs.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From nathan at kernel.org  Thu Apr  1 17:42:35 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Thu, 1 Apr 2021 09:42:35 -0700
Subject: [PATCH] usb: isp1301-omap: Add missing gpiod_add_lookup_table
 function
In-Reply-To: <20210401162032.10150-1-maciej.falkowski9@gmail.com>
References: <20210401162032.10150-1-maciej.falkowski9@gmail.com>
Message-ID: <20210401164235.cb6hrx55vkqiuvz2@archlinux-ax161>

On Thu, Apr 01, 2021 at 06:20:32PM +0200, Maciej Falkowski wrote:
> The gpiod table was added without any usage making it unused
> as reported by Clang compilation from omap1_defconfig on linux-next:
> 
> arch/arm/mach-omap1/board-h2.c:347:34: warning: unused variable 'isp1301_gpiod_table' [-Wunused-variable]
> static struct gpiod_lookup_table isp1301_gpiod_table = {
>                                  ^
> 1 warning generated.
> 
> The patch adds the missing gpiod_add_lookup_table() function.
> 
> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
> Fixes: f3ef38160e3d ("usb: isp1301-omap: Convert to use GPIO descriptors")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1325

Thanks for the patch!

Reviewed-by: Nathan Chancellor <nathan at kernel.org>

> ---
>  arch/arm/mach-omap1/board-h2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index c40cf5ef8607..977b0b744c22 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -320,7 +320,7 @@ static int tps_setup(struct i2c_client *client, void *context)
>  {
>  	if (!IS_BUILTIN(CONFIG_TPS65010))
>  		return -ENOSYS;
> -	
> +
>  	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
>  				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>  
> @@ -394,6 +394,8 @@ static void __init h2_init(void)
>  	BUG_ON(gpio_request(H2_NAND_RB_GPIO_PIN, "NAND ready") < 0);
>  	gpio_direction_input(H2_NAND_RB_GPIO_PIN);
>  
> +	gpiod_add_lookup_table(&isp1301_gpiod_table);
> +
>  	omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
>  	omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
>  
> -- 
> 2.26.3
> 


From mathieu.poirier at linaro.org  Thu Apr  1 17:43:13 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 1 Apr 2021 10:43:13 -0600
Subject: [PATCH v5 05/10] coresight: syscfg: Add API to activate and
 enable configurations
In-Reply-To: <20210316180400.7184-6-mike.leach@linaro.org>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-6-mike.leach@linaro.org>
Message-ID: <20210401164313.GA145043@xps15>

On Tue, Mar 16, 2021 at 06:03:55PM +0000, Mike Leach wrote:
> Configurations are first activated, then when any coresight device is
> enabled, the active configurations are checked and any matching
> one is enabled.
> 
> This patch provides the activation / enable API.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> ---
>  .../hwtracing/coresight/coresight-config.h    |   2 +
>  .../hwtracing/coresight/coresight-syscfg.c    | 122 ++++++++++++++++++
>  .../hwtracing/coresight/coresight-syscfg.h    |   8 ++
>  include/linux/coresight.h                     |   2 +
>  4 files changed, 134 insertions(+)
>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
 
> diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
> index 38fd1c71eb05..f1a5957a25c9 100644
> --- a/drivers/hwtracing/coresight/coresight-config.h
> +++ b/drivers/hwtracing/coresight/coresight-config.h
> @@ -127,6 +127,7 @@ struct cscfg_feature_desc {
>   * @nr_total_params:	Sum of all parameters declared by used features
>   * @presets:		Array of preset values.
>   * @event_ea:		Extended attribute for perf event value
> + * @active_cnt:		ref count for activate on this configuration.
>   *
>   */
>  struct cscfg_config_desc {
> @@ -139,6 +140,7 @@ struct cscfg_config_desc {
>  	int nr_total_params;
>  	const u64 *presets; /* nr_presets * nr_total_params */
>  	struct dev_ext_attribute *event_ea;
> +	atomic_t active_cnt;
>  };
>  
>  /**
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> index 03014a2142c1..c44746d6cd6d 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> @@ -284,6 +284,7 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
>  		return err;
>  
>  	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
> +	atomic_set(&config_desc->active_cnt, 0);
>  	return 0;
>  }
>  
> @@ -451,6 +452,126 @@ void cscfg_unregister_csdev(struct coresight_device *csdev)
>  }
>  EXPORT_SYMBOL_GPL(cscfg_unregister_csdev);
>  
> +void cscfg_csdev_reset_feats(struct coresight_device *csdev)
> +{
> +	struct cscfg_feature_csdev *feat_csdev;
> +
> +	mutex_lock(&cscfg_csdev_mutex);
> +	if (list_empty(&csdev->feature_csdev_list))
> +		goto unlock_exit;
> +
> +	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node)
> +		cscfg_reset_feat(feat_csdev);
> +
> +unlock_exit:
> +	mutex_unlock(&cscfg_csdev_mutex);
> +}
> +EXPORT_SYMBOL_GPL(cscfg_csdev_reset_feats);
> +
> +/**
> + * Mark a config descriptor as active.
> + * This will be seen when csdev devices are activated in the system.
> + *
> + * Selection by hash value - generated from the configuration name when it
> + * was loaded and added to the cs_etm/configurations file system for selection
> + * by perf.
> + *
> + * @cfg_hash: Hash value of the selected configuration name.
> + */
> +int cscfg_activate_config(unsigned long cfg_hash)
> +{
> +	struct cscfg_config_desc *config_desc;
> +	int err = -EINVAL;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
> +		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
> +			/*
> +			 * increment the global active count - control changes to
> +			 * active configurations
> +			 */
> +			atomic_inc(&cscfg_mgr->sys_active_cnt);
> +
> +			/*
> +			 * mark the descriptor as active so enable config on a
> +			 * device instance will use it
> +			 */
> +			atomic_inc(&config_desc->active_cnt);
> +
> +			err = 0;
> +			dev_dbg(cscfg_device(), "Activate config %s.\n", config_desc->name);
> +			break;
> +		}
> +	}
> +	mutex_unlock(&cscfg_mutex);
> +
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(cscfg_activate_config);
> +
> +void cscfg_deactivate_config(unsigned long cfg_hash)
> +{
> +	struct cscfg_config_desc *config_desc;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
> +		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
> +			atomic_dec(&config_desc->active_cnt);
> +			atomic_dec(&cscfg_mgr->sys_active_cnt);
> +			dev_dbg(cscfg_device(), "Deactivate config %s.\n", config_desc->name);
> +			break;
> +		}
> +	}
> +	mutex_unlock(&cscfg_mutex);
> +}
> +EXPORT_SYMBOL_GPL(cscfg_deactivate_config);
> +
> +/* Find and program any active config for the supplied device.*/
> +int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
> +				     unsigned long cfg_hash, int preset)
> +{
> +	struct cscfg_config_csdev *config_csdev_active = NULL, *config_csdev_item;
> +	const struct cscfg_config_desc *config_desc;
> +	int err = 0;
> +
> +	/* quickly check global count */
> +	if (!atomic_read(&cscfg_mgr->sys_active_cnt))
> +		return 0;
> +
> +	mutex_lock(&cscfg_csdev_mutex);
> +	list_for_each_entry(config_csdev_item, &csdev->config_csdev_list, node) {
> +		config_desc = config_csdev_item->config_desc;
> +		if ((atomic_read(&config_desc->active_cnt)) &&
> +		    ((unsigned long)config_desc->event_ea->var == cfg_hash)) {
> +			config_csdev_active = config_csdev_item;
> +			break;
> +		}
> +	}
> +	if (config_csdev_active) {
> +		err = cscfg_csdev_enable_config(config_csdev_active, preset);
> +		if (!err)
> +			csdev->active_cscfg_ctxt = (void *)config_csdev_active;
> +	}
> +	mutex_unlock(&cscfg_csdev_mutex);
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(cscfg_csdev_enable_active_config);
> +
> +/* save and disable the active config for the device */
> +void cscfg_csdev_disable_active_config(struct coresight_device *csdev)
> +{
> +	struct cscfg_config_csdev *config_csdev;
> +
> +	mutex_lock(&cscfg_csdev_mutex);
> +	config_csdev = (struct cscfg_config_csdev *)csdev->active_cscfg_ctxt;
> +	if (config_csdev)
> +		cscfg_csdev_disable_config(config_csdev);
> +	mutex_unlock(&cscfg_csdev_mutex);
> +}
> +EXPORT_SYMBOL_GPL(cscfg_csdev_disable_active_config);
> +
>  /* Initialise system configuration management device. */
>  
>  struct device *cscfg_device(void)
> @@ -519,6 +640,7 @@ int __init cscfg_init(void)
>  	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
> +	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
>  
>  	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
>  	return 0;
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
> index 5bcae3b374c6..a52775890670 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.h
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.h
> @@ -24,12 +24,14 @@
>   * @csdev_desc_list:	List of coresight devices registered with the configuration manager.
>   * @feat_desc_list:	List of feature descriptors to load into registered devices.
>   * @config_desc_list:	List of system configuration descriptors to load into registered devices.
> + * @sys_active_cnt:	Total number of active config descriptor references.
>   */
>  struct cscfg_manager {
>  	struct device dev;
>  	struct list_head csdev_desc_list;
>  	struct list_head feat_desc_list;
>  	struct list_head config_desc_list;
> +	atomic_t sys_active_cnt;
>  };
>  
>  /* get reference to dev in cscfg_manager */
> @@ -61,5 +63,11 @@ int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
>  int cscfg_register_csdev(struct coresight_device *csdev, u32 match_flags,
>  			 struct cscfg_csdev_feat_ops *ops);
>  void cscfg_unregister_csdev(struct coresight_device *csdev);
> +int cscfg_activate_config(unsigned long cfg_hash);
> +void cscfg_deactivate_config(unsigned long cfg_hash);
> +void cscfg_csdev_reset_feats(struct coresight_device *csdev);
> +int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
> +				     unsigned long cfg_hash, int preset);
> +void cscfg_csdev_disable_active_config(struct coresight_device *csdev);
>  
>  #endif /* CORESIGHT_SYSCFG_H */
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index d0126ed326a6..a3b39ce2d6ef 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -221,6 +221,7 @@ struct coresight_sysfs_link {
>   * @has_conns_grp: Have added a "connections" group for sysfs links.
>   * @feature_csdev_list: List of complex feature programming added to the device.
>   * @config_csdev_list:  List of system configurations added to the device.
> + * @active_cscfg_ctxt:  Context information for current active system configuration.
>   */
>  struct coresight_device {
>  	struct coresight_platform_data *pdata;
> @@ -245,6 +246,7 @@ struct coresight_device {
>  	/* system configuration and feature lists */
>  	struct list_head feature_csdev_list;
>  	struct list_head config_csdev_list;
> +	void *active_cscfg_ctxt;
>  };
>  
>  /*
> -- 
> 2.17.1
> 


From nathan at kernel.org  Thu Apr  1 17:45:52 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Thu, 1 Apr 2021 09:45:52 -0700
Subject: [PATCH] ARM: OMAP: Fix use of possibly uninitialized irq variable
In-Reply-To: <20210401161127.8942-1-maciej.falkowski9@gmail.com>
References: <20210401161127.8942-1-maciej.falkowski9@gmail.com>
Message-ID: <20210401164552.n4nuwvqz5mofdblg@archlinux-ax161>

On Thu, Apr 01, 2021 at 06:11:27PM +0200, Maciej Falkowski wrote:
> The current control flow of IRQ number assignment to `irq` variable
> allows a request of IRQ of unspecified value,
> generating a warning under Clang compilation with omap1_defconfig on linux-next:
> 
> arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used uninitialized whenever
> 'if' condition is false [-Wsometimes-uninitialized]
>         else if (cpu_is_omap16xx())
>                  ^~~~~~~~~~~~~~~~~
> ./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro 'cpu_is_omap16xx'
>                                         ^~~~~~~~~~~~~
> arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here
>         if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
>                         ^~~
> arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is always true
>         else if (cpu_is_omap16xx())
>              ^~~~~~~~~~~~~~~~~~~~~~
> arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to silence this warning
>         int irq;
>                ^
>                 = 0
> 1 warning generated.
> 
> The patch provides a default value to the `irq` variable
> along with a validity check.
> 

Might be worth a fixes tag:

Fixes: b75ca5217743 ("ARM: OMAP: replace setup_irq() by request_irq()")

> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1324

Reviewed-by: Nathan Chancellor <nathan at kernel.org>

> ---
>  arch/arm/mach-omap1/pm.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 2c1e2b32b9b3..a745d64d4699 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -655,9 +655,13 @@ static int __init omap_pm_init(void)
>  		irq = INT_7XX_WAKE_UP_REQ;
>  	else if (cpu_is_omap16xx())
>  		irq = INT_1610_WAKE_UP_REQ;
> -	if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
> -			NULL))
> -		pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
> +	else
> +		irq = -1;
> +
> +	if (irq >= 0) {
> +		if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", NULL))
> +			pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
> +	}
>  
>  	/* Program new power ramp-up time
>  	 * (0 for most boards since we don't lower voltage when in deep sleep)
> -- 
> 2.26.3
> 


From lkp at intel.com  Thu Apr  1 17:44:54 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 00:44:54 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1116/1701] drivers/gpio/gpio-xilinx.c:377:12:
 warning: implicit conversion from 'unsigned long' to 'unsigned int'
 changes value from 18446744071562067967 to 2147483647
Message-ID: <202104020048.iWq5k32s-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 256f37f6020654ff3d8044852f75542882301a26 [1116/1701] gpio: xilinx: Add irq support to the driver
config: x86_64-randconfig-a001-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/256f37f6020654ff3d8044852f75542882301a26
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 256f37f6020654ff3d8044852f75542882301a26
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/gpio/gpio-xilinx.c:377:12: warning: implicit conversion from 'unsigned long' to 'unsigned int' changes value from 18446744071562067967 to 2147483647 [-Wconstant-conversion]
                                          ~XGPIO_GIER_IE);
                                          ^~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:39:45: note: expanded from macro 'xgpio_writereg'
   # define xgpio_writereg(offset, val)    writel(val, offset)
                                           ~~~~~~ ^~~
   1 warning generated.


vim +377 drivers/gpio/gpio-xilinx.c

   342	
   343	/**
   344	 * xgpiops_irq_mask - Write the specified signal of the GPIO device.
   345	 * @irq_data: per irq and chip data passed down to chip functions
   346	 */
   347	static void xgpio_irq_mask(struct irq_data *irq_data)
   348	{
   349		unsigned long flags;
   350		struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
   351		u32 offset = irq_data->irq - chip->irq_base;
   352		u32 temp;
   353		s32 val;
   354		int index = xgpio_index(chip, 0);
   355	
   356		pr_debug("%s: Disable %d irq, irq_enable_mask 0x%x\n",
   357			 __func__, offset, chip->irq_enable);
   358	
   359		spin_lock_irqsave(&chip->gpio_lock[index], flags);
   360	
   361		chip->irq_enable &= ~BIT(offset);
   362	
   363		if (!chip->irq_enable) {
   364			/* Enable per channel interrupt */
   365			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   366			val = offset - chip->gpio_width[0] + 1;
   367			if (val > 0)
   368				temp &= 1;
   369			else
   370				temp &= 2;
   371			xgpio_writereg(chip->regs + XGPIO_IPIER_OFFSET, temp);
   372	
   373			/* Disable global interrupt if channel interrupts are unused */
   374			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   375			if (!temp)
   376				xgpio_writereg(chip->regs + XGPIO_GIER_OFFSET,
 > 377					       ~XGPIO_GIER_IE);
   378		}
   379		spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
   380	}
   381	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38005 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/de49946f/attachment-0001.gz>

From will at kernel.org  Thu Apr  1 17:47:33 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:33 +0100
Subject: [RFC PATCH 1/6] iommu/io-pgtable: Introduce unmap_pages() as a page
 table op
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-2-will@kernel.org>

From: "Isaac J. Manjarres" <isaacm at codeaurora.org>

The io-pgtable code expects to operate on a single block or
granule of memory that is supported by the IOMMU hardware when
unmapping memory.

This means that when a large buffer that consists of multiple
such blocks is unmapped, the io-pgtable code will walk the page
tables to the correct level to unmap each block, even for blocks
that are virtually contiguous and at the same level, which can
incur an overhead in performance.

Introduce the unmap_pages() page table op to express to the
io-pgtable code that it should unmap a number of blocks of
the same size, instead of a single block. Doing so allows
multiple blocks to be unmapped in one call to the io-pgtable
code, reducing the number of page table walks, and indirect
calls.

Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
Suggested-by: Will Deacon <will at kernel.org>
Signed-off-by: Will Deacon <will at kernel.org>
---
 include/linux/io-pgtable.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a4c9ca2c31f1..2ed0c057d9e7 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -144,6 +144,7 @@ struct io_pgtable_cfg {
  *
  * @map:          Map a physically contiguous memory region.
  * @unmap:        Unmap a physically contiguous memory region.
+ * @unmap_pages:  Unmap a range of virtually contiguous pages of the same size.
  * @iova_to_phys: Translate iova to physical address.
  *
  * These functions map directly onto the iommu_ops member functions with
@@ -154,6 +155,9 @@ struct io_pgtable_ops {
 		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
 	size_t (*unmap)(struct io_pgtable_ops *ops, unsigned long iova,
 			size_t size, struct iommu_iotlb_gather *gather);
+	size_t (*unmap_pages)(struct io_pgtable_ops *ops, unsigned long iova,
+			      size_t pgsize, size_t pgcount,
+			      struct iommu_iotlb_gather *gather);
 	phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
 				    unsigned long iova);
 };
-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:32 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:32 +0100
Subject: [RFC PATCH 0/6] iommu_pgsize() improvements to help towards
 ->[un]map_pages()
Message-ID: <20210401164738.9513-1-will@kernel.org>

Hi Isaac,

I had a go at removing the loop you have in pgsize_bitmap() over at:

https://lore.kernel.org/r/20210331030042.13348-4-isaacm at codeaurora.org

and I ended up with this. It's _very_ lightly tested, but I thought it
might be useful to you, especially if you're going to be adding support
for '->map_pages' as well.

Cheers,

Will

Cc: "Isaac J. Manjarres" <isaacm at codeaurora.org>
Cc: Pratik Patel <pratikp at codeaurora.org>
Cc: Robin Murphy <robin.murphy at arm.com>
Cc: Lu Baolu <baolu.lu at linux.intel.com>

--->8

Isaac J. Manjarres (2):
  iommu/io-pgtable: Introduce unmap_pages() as a page table op
  iommu: Add an unmap_pages() op for IOMMU drivers

Will Deacon (4):
  iommu: Use bitmap to calculate page size in iommu_pgsize()
  iommu: Split 'addr_merge' argument to iommu_pgsize() into separate
    parts
  iommu: Hook up '->unmap_pages' driver callback
  iommu: Accomodate larger pages in iommu_pgsize() 'count' calculation

 drivers/iommu/iommu.c      | 87 +++++++++++++++++++++++++++-----------
 include/linux/io-pgtable.h |  4 ++
 include/linux/iommu.h      |  4 ++
 3 files changed, 70 insertions(+), 25 deletions(-)

-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:34 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:34 +0100
Subject: [RFC PATCH 2/6] iommu: Add an unmap_pages() op for IOMMU drivers
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-3-will@kernel.org>

From: "Isaac J. Manjarres" <isaacm at codeaurora.org>

Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.

For IOMMU drivers that do not specify an unmap_pages() callback,
the existing logic of unmapping memory one page block at a time
will be used.

Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
Suggested-by: Will Deacon <will at kernel.org>
Signed-off-by: Will Deacon <will at kernel.org>
---
 include/linux/iommu.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 5e7fe519430a..9cf81242581a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -193,6 +193,7 @@ struct iommu_iotlb_gather {
  * @detach_dev: detach device from an iommu domain
  * @map: map a physically contiguous memory region to an iommu domain
  * @unmap: unmap a physically contiguous memory region from an iommu domain
+ * @unmap_pages: unmap a number of pages of the same size from an iommu domain
  * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
  * @iotlb_sync_map: Sync mappings created recently using @map to the hardware
  * @iotlb_sync: Flush all queued ranges from the hardware TLBs and empty flush
@@ -245,6 +246,9 @@ struct iommu_ops {
 		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
 	size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
 		     size_t size, struct iommu_iotlb_gather *iotlb_gather);
+	size_t (*unmap_pages)(struct iommu_domain *domain, unsigned long iova,
+			      size_t pgsize, size_t pgcount,
+			      struct iommu_iotlb_gather *iotlb_gather);
 	void (*flush_iotlb_all)(struct iommu_domain *domain);
 	void (*iotlb_sync_map)(struct iommu_domain *domain, unsigned long iova,
 			       size_t size);
-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:35 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:35 +0100
Subject: [RFC PATCH 3/6] iommu: Use bitmap to calculate page size in
 iommu_pgsize()
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-4-will@kernel.org>

Avoid the potential for shifting values by amounts greater than the
width of their type by using a bitmap to compute page size in
iommu_pgsize().

Signed-off-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 31 ++++++++++++-------------------
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..bcd623862bf9 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -8,6 +8,7 @@
 
 #include <linux/device.h>
 #include <linux/kernel.h>
+#include <linux/bits.h>
 #include <linux/bug.h>
 #include <linux/types.h>
 #include <linux/init.h>
@@ -2360,30 +2361,22 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
 			   unsigned long addr_merge, size_t size)
 {
 	unsigned int pgsize_idx;
+	unsigned long pgsizes;
 	size_t pgsize;
 
-	/* Max page size that still fits into 'size' */
-	pgsize_idx = __fls(size);
+	/* Page sizes supported by the hardware and small enough for @size */
+	pgsizes = domain->pgsize_bitmap & GENMASK(__fls(size), 0);
 
-	/* need to consider alignment requirements ? */
-	if (likely(addr_merge)) {
-		/* Max page size allowed by address */
-		unsigned int align_pgsize_idx = __ffs(addr_merge);
-		pgsize_idx = min(pgsize_idx, align_pgsize_idx);
-	}
-
-	/* build a mask of acceptable page sizes */
-	pgsize = (1UL << (pgsize_idx + 1)) - 1;
-
-	/* throw away page sizes not supported by the hardware */
-	pgsize &= domain->pgsize_bitmap;
+	/* Constrain the page sizes further based on the maximum alignment */
+	if (likely(addr_merge))
+		pgsizes &= GENMASK(__ffs(addr_merge), 0);
 
-	/* make sure we're still sane */
-	BUG_ON(!pgsize);
+	/* Make sure we have at least one suitable page size */
+	BUG_ON(!pgsizes);
 
-	/* pick the biggest page */
-	pgsize_idx = __fls(pgsize);
-	pgsize = 1UL << pgsize_idx;
+	/* Pick the biggest page size remaining */
+	pgsize_idx = __fls(pgsizes);
+	pgsize = BIT(pgsize_idx);
 
 	return pgsize;
 }
-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:36 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:36 +0100
Subject: [RFC PATCH 4/6] iommu: Split 'addr_merge' argument to iommu_pgsize()
 into separate parts
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-5-will@kernel.org>

The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.

Subsequent improvements to iommu_pgsize() will need to check the
alignment of the virtual and physical components of 'addr_merge'
independently, so pass them in as separate parameters and reconstruct
'addr_merge' locally.

No functional change.

Signed-off-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index bcd623862bf9..ab689611a03b 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2357,12 +2357,13 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
 }
 EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
 
-static size_t iommu_pgsize(struct iommu_domain *domain,
-			   unsigned long addr_merge, size_t size)
+static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
+			   phys_addr_t paddr, size_t size)
 {
 	unsigned int pgsize_idx;
 	unsigned long pgsizes;
 	size_t pgsize;
+	phys_addr_t addr_merge = paddr | iova;
 
 	/* Page sizes supported by the hardware and small enough for @size */
 	pgsizes = domain->pgsize_bitmap & GENMASK(__fls(size), 0);
@@ -2415,7 +2416,7 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
 	pr_debug("map: iova 0x%lx pa %pa size 0x%zx\n", iova, &paddr, size);
 
 	while (size) {
-		size_t pgsize = iommu_pgsize(domain, iova | paddr, size);
+		size_t pgsize = iommu_pgsize(domain, iova, paddr, size);
 
 		pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx\n",
 			 iova, &paddr, pgsize);
@@ -2503,8 +2504,9 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
 	 * or we hit an area that isn't mapped.
 	 */
 	while (unmapped < size) {
-		size_t pgsize = iommu_pgsize(domain, iova, size - unmapped);
+		size_t pgsize;
 
+		pgsize = iommu_pgsize(domain, iova, iova, size - unmapped);
 		unmapped_page = ops->unmap(domain, iova, pgsize, iotlb_gather);
 		if (!unmapped_page)
 			break;
-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:37 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:37 +0100
Subject: [RFC PATCH 5/6] iommu: Hook up '->unmap_pages' driver callback
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-6-will@kernel.org>

Extend iommu_pgsize() to populate an optional 'count' paramater so that
we can direct unmapping operation to the ->unmap_pages callback if it
has been provided by the driver.

Signed-off-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ab689611a03b..fe186691fc21 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2358,7 +2358,7 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
 EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
 
 static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
-			   phys_addr_t paddr, size_t size)
+			   phys_addr_t paddr, size_t size, size_t *count)
 {
 	unsigned int pgsize_idx;
 	unsigned long pgsizes;
@@ -2379,6 +2379,8 @@ static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
 	pgsize_idx = __fls(pgsizes);
 	pgsize = BIT(pgsize_idx);
 
+	if (count)
+		*count = size >> pgsize_idx;
 	return pgsize;
 }
 
@@ -2416,7 +2418,7 @@ static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
 	pr_debug("map: iova 0x%lx pa %pa size 0x%zx\n", iova, &paddr, size);
 
 	while (size) {
-		size_t pgsize = iommu_pgsize(domain, iova, paddr, size);
+		size_t pgsize = iommu_pgsize(domain, iova, paddr, size, NULL);
 
 		pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx\n",
 			 iova, &paddr, pgsize);
@@ -2467,6 +2469,19 @@ int iommu_map_atomic(struct iommu_domain *domain, unsigned long iova,
 }
 EXPORT_SYMBOL_GPL(iommu_map_atomic);
 
+static size_t __iommu_unmap_pages(struct iommu_domain *domain,
+				  unsigned long iova, size_t size,
+				  struct iommu_iotlb_gather *iotlb_gather)
+{
+	const struct iommu_ops *ops = domain->ops;
+	size_t pgsize, count;
+
+	pgsize = iommu_pgsize(domain, iova, iova, size, &count);
+	return ops->unmap_pages ?
+	       ops->unmap_pages(domain, iova, pgsize, count, iotlb_gather) :
+	       ops->unmap(domain, iova, pgsize, iotlb_gather);
+}
+
 static size_t __iommu_unmap(struct iommu_domain *domain,
 			    unsigned long iova, size_t size,
 			    struct iommu_iotlb_gather *iotlb_gather)
@@ -2504,10 +2519,9 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
 	 * or we hit an area that isn't mapped.
 	 */
 	while (unmapped < size) {
-		size_t pgsize;
-
-		pgsize = iommu_pgsize(domain, iova, iova, size - unmapped);
-		unmapped_page = ops->unmap(domain, iova, pgsize, iotlb_gather);
+		unmapped_page = __iommu_unmap_pages(domain, iova,
+						    size - unmapped,
+						    iotlb_gather);
 		if (!unmapped_page)
 			break;
 
-- 
2.31.0.291.g576ba9dcdaf-goog



From will at kernel.org  Thu Apr  1 17:47:38 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 17:47:38 +0100
Subject: [RFC PATCH 6/6] iommu: Accomodate larger pages in iommu_pgsize()
 'count' calculation
In-Reply-To: <20210401164738.9513-1-will@kernel.org>
References: <20210401164738.9513-1-will@kernel.org>
Message-ID: <20210401164738.9513-7-will@kernel.org>

Extend the calculation of 'count' in iommu_pgsize() so that it takes
larger page sizes into consideration and returns a value which will
allow a larger page size to be used on the next call.

Signed-off-by: Will Deacon <will at kernel.org>
---
 drivers/iommu/iommu.c | 36 ++++++++++++++++++++++++++++++++----
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index fe186691fc21..0572a4dcd9e2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2360,9 +2360,9 @@ EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
 static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
 			   phys_addr_t paddr, size_t size, size_t *count)
 {
-	unsigned int pgsize_idx;
+	unsigned int pgsize_idx, pgsize_idx_next;
 	unsigned long pgsizes;
-	size_t pgsize;
+	size_t offset, pgsize, pgsize_next;
 	phys_addr_t addr_merge = paddr | iova;
 
 	/* Page sizes supported by the hardware and small enough for @size */
@@ -2378,9 +2378,37 @@ static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
 	/* Pick the biggest page size remaining */
 	pgsize_idx = __fls(pgsizes);
 	pgsize = BIT(pgsize_idx);
+	if (!count)
+		return pgsize;
 
-	if (count)
-		*count = size >> pgsize_idx;
+
+	/* Find the next biggest support page size, if it exists */
+	pgsizes = domain->pgsize_bitmap & ~GENMASK(pgsize_idx, 0);
+	if (!pgsizes)
+		goto out_set_count;
+
+	pgsize_idx_next = __ffs(pgsizes);
+	pgsize_next = BIT(pgsize_idx_next);
+
+	/*
+	 * There's no point trying a bigger page size unless the virtual
+	 * and physical addresses are similarly offset within the larger page.
+	 */
+	if ((iova ^ paddr) & (pgsize_next - 1))
+		goto out_set_count;
+
+	/* Calculate the offset to the next page size alignment boundary */
+	offset = pgsize_next - (addr_merge & (pgsize_next - 1));
+
+	/*
+	 * If size is big enough to accomodate the larger page, reduce
+	 * the number of smaller pages.
+	 */
+	if (offset + pgsize_next <= size)
+		size = offset;
+
+out_set_count:
+	*count = size >> pgsize_idx;
 	return pgsize;
 }
 
-- 
2.31.0.291.g576ba9dcdaf-goog



From pcc at google.com  Thu Apr  1 17:51:10 2021
From: pcc at google.com (Peter Collingbourne)
Date: Thu,  1 Apr 2021 09:51:10 -0700
Subject: [PATCH] arm64: fix inline asm in load_unaligned_zeropad()
Message-ID: <20210401165110.3952103-1-pcc@google.com>

The inline asm's addr operand is marked as input-only, however in
the case where an exception is taken it may be modified by the BIC
instruction on the exception path. Fix the problem by using a temporary
register as the destination register for the BIC instruction.

Signed-off-by: Peter Collingbourne <pcc at google.com>
Cc: stable at vger.kernel.org
Link: https://linux-review.googlesource.com/id/I84538c8a2307d567b4f45bb20b715451005f9617
---
 arch/arm64/include/asm/word-at-a-time.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/word-at-a-time.h b/arch/arm64/include/asm/word-at-a-time.h
index 3333950b5909..ea487218db79 100644
--- a/arch/arm64/include/asm/word-at-a-time.h
+++ b/arch/arm64/include/asm/word-at-a-time.h
@@ -53,7 +53,7 @@ static inline unsigned long find_zero(unsigned long mask)
  */
 static inline unsigned long load_unaligned_zeropad(const void *addr)
 {
-	unsigned long ret, offset;
+	unsigned long ret, tmp;
 
 	/* Load word from unaligned pointer addr */
 	asm(
@@ -61,9 +61,9 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
 	"2:\n"
 	"	.pushsection .fixup,\"ax\"\n"
 	"	.align 2\n"
-	"3:	and	%1, %2, #0x7\n"
-	"	bic	%2, %2, #0x7\n"
-	"	ldr	%0, [%2]\n"
+	"3:	bic	%1, %2, #0x7\n"
+	"	ldr	%0, [%1]\n"
+	"	and	%1, %2, #0x7\n"
 	"	lsl	%1, %1, #0x3\n"
 #ifndef __AARCH64EB__
 	"	lsr	%0, %0, %1\n"
@@ -73,7 +73,7 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
 	"	b	2b\n"
 	"	.popsection\n"
 	_ASM_EXTABLE(1b, 3b)
-	: "=&r" (ret), "=&r" (offset)
+	: "=&r" (ret), "=&r" (tmp)
 	: "r" (addr), "Q" (*(unsigned long *)addr));
 
 	return ret;
-- 
2.31.0.291.g576ba9dcdaf-goog



From mathieu.poirier at linaro.org  Thu Apr  1 17:53:53 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 1 Apr 2021 10:53:53 -0600
Subject: [PATCH v5 06/10] coresight: etm-perf: Update to activate
 selected configuration
In-Reply-To: <20210316180400.7184-7-mike.leach@linaro.org>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-7-mike.leach@linaro.org>
Message-ID: <20210401165353.GB145043@xps15>

On Tue, Mar 16, 2021 at 06:03:56PM +0000, Mike Leach wrote:
> Add calls to activate the selected configuration as perf starts
> and stops the tracing session.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

> ---
>  drivers/hwtracing/coresight/coresight-etm-perf.c | 14 +++++++++++++-
>  drivers/hwtracing/coresight/coresight-etm-perf.h |  2 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 66bda452a2f4..9128f59864a8 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -196,6 +196,10 @@ static void free_event_data(struct work_struct *work)
>  	/* Free the sink buffers, if there are any */
>  	free_sink_buffer(event_data);
>  
> +	/* clear any configuration we were using */
> +	if (event_data->cfg_hash)
> +		cscfg_deactivate_config(event_data->cfg_hash);
> +
>  	for_each_cpu(cpu, mask) {
>  		struct list_head **ppath;
>  
> @@ -254,7 +258,7 @@ static void etm_free_aux(void *data)
>  static void *etm_setup_aux(struct perf_event *event, void **pages,
>  			   int nr_pages, bool overwrite)
>  {
> -	u32 id;
> +	u32 id, cfg_hash;
>  	int cpu = event->cpu;
>  	cpumask_t *mask;
>  	struct coresight_device *sink = NULL;
> @@ -271,6 +275,14 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
>  		sink = coresight_get_sink_by_id(id);
>  	}
>  
> +	/* check if user wants a coresight configuration selected */
> +	cfg_hash = (u32)((event->attr.config2 & GENMASK_ULL(63, 32)) >> 32);
> +	if (cfg_hash) {
> +		if (cscfg_activate_config(cfg_hash))
> +			goto err;
> +		event_data->cfg_hash = cfg_hash;
> +	}
> +
>  	mask = &event_data->mask;
>  
>  	/*
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
> index ba617fe2217e..468f7799ab4f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.h
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
> @@ -49,12 +49,14 @@ struct etm_filters {
>   * @work:		Handle to free allocated memory outside IRQ context.
>   * @mask:		Hold the CPU(s) this event was set for.
>   * @snk_config:		The sink configuration.
> + * @cfg_hash:		The hash id of any coresight config selected.
>   * @path:		An array of path, each slot for one CPU.
>   */
>  struct etm_event_data {
>  	struct work_struct work;
>  	cpumask_t mask;
>  	void *snk_config;
> +	u32 cfg_hash;
>  	struct list_head * __percpu *path;
>  };
>  
> -- 
> 2.17.1
> 


From pcc at google.com  Thu Apr  1 17:55:43 2021
From: pcc at google.com (Peter Collingbourne)
Date: Thu,  1 Apr 2021 09:55:43 -0700
Subject: [PATCH] arm: fix inline asm in load_unaligned_zeropad()
Message-ID: <20210401165543.3957816-1-pcc@google.com>

The inline asm's addr operand is marked as input-only, however in
the case where an exception is taken it may be modified by the BIC
instruction on the exception path. Fix the problem by using a temporary
register as the destination register for the BIC instruction.

Signed-off-by: Peter Collingbourne <pcc at google.com>
Cc: stable at vger.kernel.org
Link: https://linux-review.googlesource.com/id/I0f9ad1682821f874fb9b47e1279721943b2e5325
---
 arch/arm/include/asm/word-at-a-time.h | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/word-at-a-time.h b/arch/arm/include/asm/word-at-a-time.h
index 352ab213520d..2e6d0b4349f4 100644
--- a/arch/arm/include/asm/word-at-a-time.h
+++ b/arch/arm/include/asm/word-at-a-time.h
@@ -66,7 +66,7 @@ static inline unsigned long find_zero(unsigned long mask)
  */
 static inline unsigned long load_unaligned_zeropad(const void *addr)
 {
-	unsigned long ret, offset;
+	unsigned long ret, tmp;
 
 	/* Load word from unaligned pointer addr */
 	asm(
@@ -74,9 +74,9 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
 	"2:\n"
 	"	.pushsection .text.fixup,\"ax\"\n"
 	"	.align 2\n"
-	"3:	and	%1, %2, #0x3\n"
-	"	bic	%2, %2, #0x3\n"
-	"	ldr	%0, [%2]\n"
+	"3:	bic	%1, %2, #0x3\n"
+	"	ldr	%0, [%1]\n"
+	"	and	%1, %2, #0x3\n"
 	"	lsl	%1, %1, #0x3\n"
 #ifndef __ARMEB__
 	"	lsr	%0, %0, %1\n"
@@ -89,7 +89,7 @@ static inline unsigned long load_unaligned_zeropad(const void *addr)
 	"	.align	3\n"
 	"	.long	1b, 3b\n"
 	"	.popsection"
-	: "=&r" (ret), "=&r" (offset)
+	: "=&r" (ret), "=&r" (tmp)
 	: "r" (addr), "Qo" (*(unsigned long *)addr));
 
 	return ret;
-- 
2.31.0.291.g576ba9dcdaf-goog



From robh at kernel.org  Thu Apr  1 17:59:47 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 11:59:47 -0500
Subject: [PATCH v3 3/4] dt-bindings: arm: add compatible strings for
 Forlinx OKA40i-C
In-Reply-To: <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
Message-ID: <20210401165947.GA608122@robh.at.kernel.org>

On Wed, 31 Mar 2021 18:56:15 +0300, Ivan Uvarov wrote:
> The OKA40i-C is a carrier/development board for the Forlinx FETA40i-C SoM
> based on the Allwinner R40/A40i SoC.
> 
> This patch adds the relevant dt-binding documentation in preparation for
> the next patch, which adds a devicetree for the SoM and board.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  2 files changed, 8 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr  1 18:00:22 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:00:22 -0500
Subject: [PATCH V2 1/8] dt-bindings: remoteproc: imx_rproc: add fsl,
 auto-boot property
In-Reply-To: <1617095574-6764-2-git-send-email-peng.fan@oss.nxp.com>
References: <1617095574-6764-1-git-send-email-peng.fan@oss.nxp.com>
 <1617095574-6764-2-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210401170022.GA609295@robh.at.kernel.org>

On Tue, 30 Mar 2021 17:12:47 +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add an optional property "fsl,auto-boot" to indicate remote processor
> auto boot.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml       | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr  1 18:00:43 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:00:43 -0500
Subject: [PATCH V2 2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
 support
In-Reply-To: <1617095574-6764-3-git-send-email-peng.fan@oss.nxp.com>
References: <1617095574-6764-1-git-send-email-peng.fan@oss.nxp.com>
 <1617095574-6764-3-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210401170043.GA609931@robh.at.kernel.org>

On Tue, 30 Mar 2021 17:12:48 +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add i.MX7ULP compatible.
> 
> We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
> control of M4 core, M4 core starts by ROM and powers most serivces used
> by A7 core, so A7 core has no power to start and stop M4 core. So
> clocks and syscon are not required.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml          | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Thu Apr  1 18:01:48 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 01:01:48 +0800
Subject: [xlnx:xlnx_rebase_v5.4 904/1701] trace.c:(.text+0x1c20): multiple
 definition of `dwc3_set_simple_data';
 drivers/usb/dwc3/core.o:core.c:(.text+0x780): first defined here
Message-ID: <202104020145.czg4arzZ-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 3d600fd776cbda29abdea084f7437f7d9102b2a5 [904/1701] usb: dwc3: Add support for removing vbus when suspended
config: i386-randconfig-c021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/3d600fd776cbda29abdea084f7437f7d9102b2a5
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 3d600fd776cbda29abdea084f7437f7d9102b2a5
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:35:
   drivers/usb/dwc3/core.h:1419:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1419 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.h:1421:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1421 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
--
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_wakeup_capable':
   trace.c:(.text+0x1c10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x770): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_simple_data':
>> trace.c:(.text+0x1c20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x780): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_wakeup_capable':
   host.c:(.text+0x0): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x770): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_simple_data':
   host.c:(.text+0x10): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x780): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_wakeup_capable':
   ulpi.c:(.text+0xa80): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x770): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_simple_data':
   ulpi.c:(.text+0xa90): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x780): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_wakeup_capable':
   debugfs.c:(.text+0xa10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x770): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_simple_data':
   debugfs.c:(.text+0xa20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x780): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/7f0eda5c/attachment-0001.gz>

From maz at kernel.org  Thu Apr  1 18:03:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 01 Apr 2021 18:03:09 +0100
Subject: [PATCH] arm64: Disable fine grained traps on boot
In-Reply-To: <20210401154805.GL4758@sirena.org.uk>
References: <20210401124936.56877-1-broonie@kernel.org>
 <87sg4aox44.wl-maz@kernel.org>
 <20210401154805.GL4758@sirena.org.uk>
Message-ID: <87h7kqey42.wl-maz@kernel.org>

On Thu, 01 Apr 2021 16:48:05 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> On Thu, Apr 01, 2021 at 04:14:35PM +0100, Marc Zyngier wrote:
> > On Thu, 01 Apr 2021 13:49:36 +0100,
> > Mark Brown <broonie at kernel.org> wrote:
> 
> > > +	msr_s	SYS_HFGRTR_EL2, xzr
> > > +	msr_s	SYS_HFGITR_EL2, xzr
> > > +	msr_s	SYS_HFGWTR_EL2, xzr
> 
> > nit: consider grouping SYS_HFGWTR_EL2 and SYS_HFGRTR_EL2 together,
> > since they affect the same registers.
> 
> Ack, I'd sorted them numerically IIRC.
> 
> > > +	mrs	x1, id_aa64pfr0_el1		// AMU traps UNDEF without AMU
> > > +	ubfx	x1, x1, #ID_AA64PFR0_AMU_SHIFT, #4
> > > +	cbz	x1, .Lskip_fgt_\@
> 
> > > +	msr_s	SYS_HAFGRTR_EL2, xzr
> 
> > Do we need to document the need for SCR_EL3.FGTEn to be set so that
> > these register accesses don't trap? That'd be consistent with what we
> > do for other features (PtrAuth, AMU...).
> 
> Yes, good point.  We should if this is going in - this is the result of
> some other stuff I've been sending to document disabling these on boot,
> Will wanted to have code doing that, so I'll pull that into there.  It
> does end up being a bit weird that we demand this be enabled so we can
> explicitly not use it, but better to do that so we can in future decide
> to take advantage of it.

I definitely have plans for this feature right now, as some of the
traps that KVM uses could be minimised using FGT, so I don't believe
the feature will stay unused for too long.

Thanks,

	M.

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


From robh at kernel.org  Thu Apr  1 18:07:04 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:07:04 -0500
Subject: [PATCH v2 1/6] dt-bindings: reserved-memory: Add Owl SoC serial
 number binding
In-Reply-To: <fb74862bec15f1e9e0c4d8b70ebd6c07c6eb1a40.1617110420.git.cristian.ciocaltea@gmail.com>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <fb74862bec15f1e9e0c4d8b70ebd6c07c6eb1a40.1617110420.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210401170704.GA610119@robh.at.kernel.org>

On Tue, Mar 30, 2021 at 04:48:16PM +0300, Cristian Ciocaltea wrote:
> Add devicetree binding for the Actions Semi Owl SoC serial number
> reserved-memory range.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> ---
>  .../actions,owl-soc-serial.yaml               | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> 
> diff --git a/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> new file mode 100644
> index 000000000000..41b71f47ee6c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/actions,owl-soc-serial.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl reserved-memory for SoC serial number
> +
> +maintainers:
> +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> +
> +description: |
> +  Provide access to the memory region where the two parts of the Actions
> +  Semi Owl SoC serial number (low & high) can be read from. This information
> +  is provided by the bootloader, hence expose it under /reserved-memory node.
> +
> +  Please refer to reserved-memory.txt in this directory for common binding
> +  part and usage.
> +
> +  This is currently supported only on the S500 SoC variant.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: actions,owl-soc-serial
> +      - items:
> +          - enum:
> +              - actions,s500-soc-serial
> +          - const: actions,owl-soc-serial
> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +    reserved-memory {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        ranges;
> +
> +        soc_serial: soc-serial at 800 {
> +            compatible = "actions,s500-soc-serial", "actions,owl-soc-serial";
> +            reg = <0x800 0x8>;

You end up wasting a whole page of memory for 8 bytes. It may be better 
to copy this to a DT property ('serial-number' is already a defined root 
property).

Rob


From will at kernel.org  Thu Apr  1 18:07:52 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 18:07:52 +0100
Subject: [PATCH v14 07/10] iommu/arm-smmu-v3: Maintain a SID->device
 structure
In-Reply-To: <20210401154718.307519-8-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-8-jean-philippe@linaro.org>
Message-ID: <20210401170752.GA9447@willie-the-truck>

On Thu, Apr 01, 2021 at 05:47:16PM +0200, Jean-Philippe Brucker wrote:
> When handling faults from the event or PRI queue, we need to find the
> struct device associated with a SID. Add a rb_tree to keep track of
> SIDs.
> 
> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Reviewed-by: Eric Auger <eric.auger at redhat.com>
> Reviewed-by: Keqian Zhu <zhukeqian1 at huawei.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>

Acked-by: Will Deacon <will at kernel.org>

Will


From robh at kernel.org  Thu Apr  1 18:08:18 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:08:18 -0500
Subject: [PATCH v2 2/6] dt-bindings: soc: actions: Add Actions Semi Owl
 socinfo binding
In-Reply-To: <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210401170818.GB610119@robh.at.kernel.org>

On Tue, Mar 30, 2021 at 04:48:17PM +0300, Cristian Ciocaltea wrote:
> Add devicetree binding for the Actions Semi Owl socinfo driver.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> ---
>  .../bindings/soc/actions/owl-socinfo.yaml     | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> new file mode 100644
> index 000000000000..01e4a8b4f5ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/actions/owl-socinfo.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl SoC info module
> +
> +maintainers:
> +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> +
> +description: |
> +  Actions Semi Owl SoC info module provides access to various information
> +  about the S500, S700 and S900 SoC variants, such as serial number or id.
> +
> +select:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - actions,s500-soc
> +          - actions,s700-soc
> +          - actions,s900-soc
> +  required:
> +    - compatible
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - actions,s500-soc
> +          - actions,s700-soc
> +          - actions,s900-soc
> +      - const: simple-bus
> +
> +required:
> +  - compatible
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +    / {
> +        compatible = "roseapplepi,roseapplepi", "actions,s500";
> +        model = "Roseapple Pi";
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        soc {
> +            compatible = "actions,s500-soc", "simple-bus";

What's the actual h/w for this bus? Still looks like abuse of DT to 
create your virtual soc_info driver.

> +            #address-cells = <1>;
> +            #size-cells = <1>;
> +            ranges;
> +        };
> +    };
> +
> +...
> -- 
> 2.31.1
> 


From robh at kernel.org  Thu Apr  1 18:09:33 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:09:33 -0500
Subject: [PATCH v2 3/3] bindings: ipmi: Add binding for Aspeed SSIF BMC
 driver
In-Reply-To: <20210330141029.20412-4-quan@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-4-quan@os.amperecomputing.com>
Message-ID: <20210401170933.GA622142@robh.at.kernel.org>

On Tue, Mar 30, 2021 at 09:10:29PM +0700, Quan Nguyen wrote:
> Add device tree binding document for the Aspeed SSIF BMC driver.
> 
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
>  .../bindings/ipmi/aspeed-ssif-bmc.txt          | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-ssif-bmc.txt

Same comment as you ignored on v1.


From mathieu.poirier at linaro.org  Thu Apr  1 18:10:32 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 1 Apr 2021 11:10:32 -0600
Subject: [PATCH v5 07/10] coresight: etm4x: Add complex configuration
 handlers to etmv4
In-Reply-To: <20210316180400.7184-8-mike.leach@linaro.org>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-8-mike.leach@linaro.org>
Message-ID: <20210401171032.GC145043@xps15>

On Tue, Mar 16, 2021 at 06:03:57PM +0000, Mike Leach wrote:
> Adds in handlers to allow the ETMv4 to use the complex configuration
> support. Features and configurations can be loaded and selected in the
> device.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> ---
>  drivers/hwtracing/coresight/Makefile          |   3 +-
>  .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
>  .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
>  .../coresight/coresight-etm4x-core.c          |  38 +++-
>  .../coresight/coresight-etm4x-sysfs.c         |   3 +
>  5 files changed, 238 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
 
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index daad9f103a78..ea544206204d 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
>  coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
>  		     coresight-etm3x-sysfs.o
>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
> -coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
> +coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
> +			coresight-etm4x-cfg.o
>  obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>  obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>  obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> new file mode 100644
> index 000000000000..de612498b29d
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +#include "coresight-etm4x.h"
> +#include "coresight-etm4x-cfg.h"
> +#include "coresight-priv.h"
> +#include "coresight-syscfg.h"
> +
> +/* defines to associate register IDs with driver data locations */
> +#define CHECKREG(cval, elem) \
> +	{ \
> +		if (offset == cval) { \
> +			reg_csdev->driver_regval = &drvcfg->elem; \
> +			err = 0; \
> +			break; \
> +		} \
> +	}
> +
> +#define CHECKREGIDX(cval, elem, off_idx, mask)	\
> +	{ \
> +		if (mask == cval) { \
> +			reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
> +			err = 0; \
> +			break; \
> +		} \
> +	}
> +
> +/**
> + * etm4_cfg_map_reg_offset - validate and map the register offset into a
> + *			     location in the driver config struct.
> + *
> + * Limits the number of registers that can be accessed and programmed in
> + * features, to those which are used to control the trace capture parameters.
> + *
> + * Omits or limits access to those which the driver must use exclusively.
> + *
> + * Invalid offsets will result in fail code return and feature load failure.
> + *
> + * @drvdata:	driver data to map into.
> + * @reg:	register to map.
> + * @offset:	device offset for the register
> + */
> +static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> +				   struct cscfg_regval_csdev *reg_csdev, u32 offset)
> +{
> +	int err = -EINVAL, idx;
> +	struct etmv4_config *drvcfg = &drvdata->config;
> +	u32 off_mask;
> +
> +	if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> +	    ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
> +	    ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
> +		do {
> +			CHECKREG(TRCEVENTCTL0R, eventctrl0);
> +			CHECKREG(TRCEVENTCTL1R, eventctrl1);
> +			CHECKREG(TRCSTALLCTLR, stall_ctrl);
> +			CHECKREG(TRCTSCTLR, ts_ctrl);
> +			CHECKREG(TRCSYNCPR, syncfreq);
> +			CHECKREG(TRCCCCTLR, ccctlr);
> +			CHECKREG(TRCBBCTLR, bb_ctrl);
> +			CHECKREG(TRCVICTLR, vinst_ctrl);
> +			CHECKREG(TRCVIIECTLR, viiectlr);
> +			CHECKREG(TRCVISSCTLR, vissctlr);
> +			CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
> +			CHECKREG(TRCSEQRSTEVR, seq_rst);
> +			CHECKREG(TRCSEQSTR, seq_state);
> +			CHECKREG(TRCEXTINSELR, ext_inp);
> +			CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
> +			CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
> +			CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
> +			CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
> +		} while (0);
> +	} else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
> +		/* sequencer state control registers */
> +		idx = (offset & GENMASK(3, 0)) / 4;
> +		if (idx < ETM_MAX_SEQ_STATES) {
> +			reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
> +			err = 0;
> +		}
> +	} else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
> +		/* 32 bit, 8 off indexed register sets */
> +		idx = (offset & GENMASK(4, 0)) / 4;
> +		off_mask =  (offset & GENMASK(11, 5));
> +		do {
> +			CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> +			CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> +			CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> +		/* 64 bit, 8 off indexed register sets */
> +		idx = (offset & GENMASK(5, 0)) / 8;
> +		off_mask = (offset & GENMASK(11, 6));
> +		do {
> +			CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
> +			CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCRSCTLRn(2)) &&
> +		   (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
> +		/* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
> +		idx = (offset & GENMASK(6, 0)) / 4;
> +		if (idx < ETM_MAX_RES_SEL) {
> +			reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
> +			err = 0;
> +		}
> +	} else if ((offset >= TRCACVRn(0)) &&
> +		   (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
> +		/* 64 bit addr cmp regs, 16 off */
> +		idx = (offset & GENMASK(6, 0)) / 8;
> +		off_mask = offset & GENMASK(11, 7);
> +		do {
> +			CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
> +			CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCCNTRLDVRn(0)) &&
> +		   (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
> +		/* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
> +		idx = (offset &  GENMASK(3, 0)) / 4;
> +		off_mask = offset &  GENMASK(11, 4);
> +		do {
> +			CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
> +			CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
> +			CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
> +		} while (0);
> +	}
> +	return err;
> +}
> +
> +/**
> + * etm4_cfg_load_feature - load a feature into a device instance.
> + *
> + * @csdev:	An ETMv4 CoreSight device.
> + * @feat:	The feature to be loaded.
> + *
> + * The function will load a feature instance into the device, checking that
> + * the register definitions are valid for the device.
> + *
> + * Parameter and register definitions will be converted into internal
> + * structures that are used to set the values in the driver when the
> + * feature is enabled for the device.
> + *
> + * The feature spinlock pointer is initialised to the same spinlock
> + * that the driver uses to protect the internal register values.
> + */
> +static int etm4_cfg_load_feature(struct coresight_device *csdev,
> +				 struct cscfg_feature_csdev *feat_csdev)
> +{
> +	struct device *dev = csdev->dev.parent;
> +	struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
> +	const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
> +	u32 offset;
> +	int i = 0, err = 0;
> +
> +	/*
> +	 * essential we set the device spinlock - this is used in the generic
> +	 * programming routines when copying values into the drvdata structures
> +	 * via the pointers setup in etm4_cfg_map_reg_offset().
> +	 */
> +	feat_csdev->drv_spinlock = &drvdata->spinlock;
> +
> +	/* process the register descriptions */
> +	for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
> +		offset = feat_desc->regs_desc[i].offset;
> +		err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
> +	}
> +	return err;
> +}
> +
> +/* match information when loading configurations */
> +#define CS_CFG_ETM4_MATCH_FLAGS	(CS_CFG_MATCH_CLASS_SRC_ALL | \
> +				 CS_CFG_MATCH_CLASS_SRC_ETM4)
> +
> +int etm4_cscfg_register(struct coresight_device *csdev, const char *dev_name)
> +{
> +	struct cscfg_csdev_feat_ops ops;
> +
> +	ops.load_feat = &etm4_cfg_load_feature;
> +
> +	return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> new file mode 100644
> index 000000000000..7ec65771ee58
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _CORESIGHT_ETM4X_CFG_H
> +#define _CORESIGHT_ETM4X_CFG_H
> +
> +#include "coresight-config.h"
> +#include "coresight-etm4x.h"
> +
> +/* ETMv4 specific config functions */
> +int etm4_cscfg_register(struct coresight_device *csdev, const char *dev_name);
> +
> +#endif /* CORESIGHT_ETM4X_CFG_H */
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 15016f757828..fb82a33f2606 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -38,6 +38,8 @@
>  
>  #include "coresight-etm4x.h"
>  #include "coresight-etm-perf.h"
> +#include "coresight-etm4x-cfg.h"
> +#include "coresight-syscfg.h"
>  
>  static int boot_enable;
>  module_param(boot_enable, int, 0444);
> @@ -492,12 +494,15 @@ static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata)
>  	return ret;
>  }
>  
> -static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
> +static int etm4_parse_event_config(struct coresight_device *csdev,
>  				   struct perf_event *event)
>  {
>  	int ret = 0;
> +	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>  	struct etmv4_config *config = &drvdata->config;
>  	struct perf_event_attr *attr = &event->attr;
> +	unsigned long cfg_hash;
> +	int preset;
>  
>  	if (!attr) {
>  		ret = -EINVAL;
> @@ -568,6 +573,20 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
>  		/* bit[12], Return stack enable bit */
>  		config->cfg |= BIT(12);
>  
> +	/*
> +	 * Set any selected configuration and preset.
> +	 *
> +	 * This extracts the values of PMU_FORMAT_ATTR(configid) and PMU_FORMAT_ATTR(preset)
> +	 * in the perf attributes defined in coresight-etm-perf.c.
> +	 * configid uses bits 63:32 of attr->config2, preset uses bits 3:0 of attr->config.
> +	 * A zero configid means no configuration active, preset = 0 means no preset selected.
> +	 */
> +	if (attr->config2 & GENMASK_ULL(63, 32)) {
> +		cfg_hash = (u32)(attr->config2 >> 32);
> +		preset = attr->config & 0xF;
> +		ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
> +	}
> +
>  out:
>  	return ret;
>  }
> @@ -584,7 +603,7 @@ static int etm4_enable_perf(struct coresight_device *csdev,
>  	}
>  
>  	/* Configure the tracer based on the session's specifics */
> -	ret = etm4_parse_event_config(drvdata, event);
> +	ret = etm4_parse_event_config(csdev, event);
>  	if (ret)
>  		goto out;
>  	/* And enable it */
> @@ -715,11 +734,18 @@ static int etm4_disable_perf(struct coresight_device *csdev,
>  	u32 control;
>  	struct etm_filters *filters = event->hw.addr_filters;
>  	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +	struct perf_event_attr *attr = &event->attr;
>  
>  	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
>  		return -EINVAL;
>  
>  	etm4_disable_hw(drvdata);
> +	/*
> +	 * The config_id occupies bits 63:32 of the config2 perf event attr
> +	 * field. If this is non-zero then we will have enabled a config.
> +	 */
> +	if (attr->config2 & GENMASK_ULL(63, 32))
> +		cscfg_csdev_disable_active_config(csdev);
>  
>  	/*
>  	 * Check if the start/stop logic was active when the unit was stopped.
> @@ -1831,6 +1857,13 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
>  		return ret;
>  	}
>  
> +	/* register with config infrastructure & load any current features */
> +	ret = etm4_cscfg_register(drvdata->csdev, dev_name(dev));
> +	if (ret) {
> +		coresight_unregister(drvdata->csdev);
> +		return ret;
> +	}
> +
>  	etmdrvdata[drvdata->cpu] = drvdata;
>  
>  	dev_info(&drvdata->csdev->dev, "CPU%d: ETM v%d.%d initialized\n",
> @@ -1918,6 +1951,7 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
>  
>  	cpus_read_unlock();
>  
> +	cscfg_unregister_csdev(drvdata->csdev);
>  	coresight_unregister(drvdata->csdev);
>  
>  	return 0;
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> index 0995a10790f4..71593b605bd5 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> @@ -9,6 +9,7 @@
>  #include <linux/sysfs.h>
>  #include "coresight-etm4x.h"
>  #include "coresight-priv.h"
> +#include "coresight-syscfg.h"
>  
>  static int etm4_set_mode_exclude(struct etmv4_drvdata *drvdata, bool exclude)
>  {
> @@ -269,6 +270,8 @@ static ssize_t reset_store(struct device *dev,
>  
>  	spin_unlock(&drvdata->spinlock);
>  
> +	cscfg_csdev_reset_feats(to_coresight_device(dev));
> +
>  	return size;
>  }
>  static DEVICE_ATTR_WO(reset);
> -- 
> 2.17.1
> 


From will at kernel.org  Thu Apr  1 18:11:02 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 18:11:02 +0100
Subject: [PATCH v14 10/10] iommu/arm-smmu-v3: Add stall support for
 platform devices
In-Reply-To: <20210401154718.307519-11-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-11-jean-philippe@linaro.org>
Message-ID: <20210401171101.GB9447@willie-the-truck>

On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
> The SMMU provides a Stall model for handling page faults in platform
> devices. It is similar to PCIe PRI, but doesn't require devices to have
> their own translation cache. Instead, faulting transactions are parked
> and the OS is given a chance to fix the page tables and retry the
> transaction.
> 
> Enable stall for devices that support it (opt-in by firmware). When an
> event corresponds to a translation error, call the IOMMU fault handler.
> If the fault is recoverable, it will call us back to terminate or
> continue the stall.

Which hardware is this useful for? Stalling adds a fair amount of complexity
to the driver, so I don't think we should support it unless we're likely to
see platforms that both implement it and do something useful with it.

Will


From will at kernel.org  Thu Apr  1 18:15:02 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 18:15:02 +0100
Subject: [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <20210401171501.GC9447@willie-the-truck>

On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote:
> Add stall support to the SMMUv3 driver, along with a common I/O Page
> Fault handler.
> 
> Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert.
> It would be good to have all of it in v5.13, since patch 10 introduces
> the first user for the IOPF interface from patch 6.  But if that's not
> possible, please pick patches 1-6 so the Vt-d driver can start using
> them.

Patches 1-7 look good to me, but I'm not convinced about the utility of
stalling faults so I'd prefer the later patches to come along with a
real user.

Will


From robh at kernel.org  Thu Apr  1 18:16:03 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 12:16:03 -0500
Subject: [RFC PATCH v2 1/2] dt-bindings: usb: Add DT bindings for
 Microchip sama7g5 tcpc
In-Reply-To: <20210330205442.981649-2-cristian.birsan@microchip.com>
References: <20210330205442.981649-1-cristian.birsan@microchip.com>
 <20210330205442.981649-2-cristian.birsan@microchip.com>
Message-ID: <20210401171603.GA624021@robh.at.kernel.org>

On Tue, Mar 30, 2021 at 11:54:41PM +0300, cristian.birsan at microchip.com wrote:
> From: Cristian Birsan <cristian.birsan at microchip.com>
> 
> This patch adds DT bindings for the new Microchip USB Type-C Port
> Controller (TCPC) embedded in sama7g5 SoC.
> 
> Signed-off-by: Cristian Birsan <cristian.birsan at microchip.com>
> ---
>  .../bindings/usb/microchip,sama7g5-tcpc.yaml  | 90 +++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/microchip,sama7g5-tcpc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/usb/microchip,sama7g5-tcpc.yaml b/Documentation/devicetree/bindings/usb/microchip,sama7g5-tcpc.yaml
> new file mode 100644
> index 000000000000..2d3289dd9ac9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/microchip,sama7g5-tcpc.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/usb/microchip,sama7g5-tcpc.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Microchip SAMA7G5 Type-C port controller bindings
> +
> +maintainers:
> +  - Cristian Birsan <cristian.birsan at microchip.com>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - microchip,sama7g5-tcpc
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: Peripheral Bus Clock
> +      - description: Generic Clock
> +
> +  clock-names:
> +    items:
> +      - const: pclk
> +      - const: gclk
> +
> +  vbus-supply:
> +    description: vbus power supply (5V) phandle

This belongs in the connector node unless this chip uses Vbus as a 
supply.

> +
> +  microchip,vbus-gpio:
> +    description: vbus detect gpio

We have standard property for this in the connector node.

> +
> +  connector:
> +    type: object
> +
> +    allOf:
> +      - $ref: ../connector/usb-connector.yaml

You can drop 'allOf'. And add:

       unevaluatedProperties: false

> +
> +    properties:
> +      compatible:
> +        const: usb-c-connector
> +
> +      power-role: true
> +
> +    required:
> +      - compatible
> +
> +required:
> +  - compatible
> +  - reg
> +  - connector
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/at91.h>
> +    #include <dt-bindings/usb/pd.h>
> +    tcpcb: tcpcb at e0844000 {
> +      compatible = "microchip,sama7g5-tcpc";
> +      reg = <0xe0844000 0x3fff>;
> +      clocks = <&pmc PMC_TYPE_PERIPHERAL 95>, <&pmc PMC_TYPE_GCK 95>;
> +      clock-names = "pclk", "gclk";
> +
> +      usb_con: connector {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        compatible = "usb-c-connector";
> +        label = "USB-C";
> +        data-role = "device";
> +        power-role = "sink";
> +        try-power-role = "sink";
> +        source-pdos = <PDO_FIXED(5000, 500,
> +            PDO_FIXED_USB_COMM)>;
> +        sink-pdos = <PDO_FIXED(5000, 500,
> +            PDO_FIXED_USB_COMM)>;
> +        op-sink-microwatt = <2500000>;
> +
> +        port at 1 {
> +          reg = <1>;
> +          usb_con_hs: endpoint {
> +            remote-endpoint = <&usb_phy1>;
> +          };
> +        };
> +      };
> +    };
> +...
> -- 
> 2.25.1
> 


From will at kernel.org  Thu Apr  1 18:16:55 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 18:16:55 +0100
Subject: [PATCH] arm: fix inline asm in load_unaligned_zeropad()
In-Reply-To: <20210401165543.3957816-1-pcc@google.com>
References: <20210401165543.3957816-1-pcc@google.com>
Message-ID: <20210401171655.GD9447@willie-the-truck>

On Thu, Apr 01, 2021 at 09:55:43AM -0700, Peter Collingbourne wrote:
> The inline asm's addr operand is marked as input-only, however in
> the case where an exception is taken it may be modified by the BIC
> instruction on the exception path. Fix the problem by using a temporary
> register as the destination register for the BIC instruction.
> 
> Signed-off-by: Peter Collingbourne <pcc at google.com>
> Cc: stable at vger.kernel.org
> Link: https://linux-review.googlesource.com/id/I0f9ad1682821f874fb9b47e1279721943b2e5325
> ---
>  arch/arm/include/asm/word-at-a-time.h | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Please can you put this into Russell's patch system?

Thanks,

Will


From Vineet.Gupta1 at synopsys.com  Thu Apr  1 18:18:00 2021
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 1 Apr 2021 17:18:00 +0000
Subject: [PATCH V2 1/6] mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
In-Reply-To: <1617259448-22529-2-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
 <1617259448-22529-2-git-send-email-anshuman.khandual@arm.com>
Message-ID: <c88eb6c2-505f-bde7-d60d-4fb33078012e@synopsys.com>

On 3/31/21 11:44 PM, Anshuman Khandual wrote:
> ARCH_HAS_CACHE_LINE_SIZE config has duplicate definitions on platforms that
> subscribe it. Instead, just make it a generic option which can be selected
> on applicable platforms. This change reduces code duplication and makes it
> cleaner.

Acked-by: Vineet Gupta <vgupta at synopsys.com>   #arc


Thx,
-Vineet

From Vineet.Gupta1 at synopsys.com  Thu Apr  1 18:18:51 2021
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Thu, 1 Apr 2021 17:18:51 +0000
Subject: [PATCH V2 6/6] mm: Drop redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
In-Reply-To: <1617259448-22529-7-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
 <1617259448-22529-7-git-send-email-anshuman.khandual@arm.com>
Message-ID: <2d63f2c2-6478-d6ea-306f-885a58726294@synopsys.com>

On 3/31/21 11:44 PM, Anshuman Khandual wrote:
> HAVE_ARCH_TRANSPARENT_HUGEPAGE has duplicate definitions on platforms that
> subscribe it. Drop these reduntant definitions and instead just select it
> on applicable platforms.

Acked-by: Vineet Gupta <vgupta at synopsys.com>   #arc

Thx,
-Vineet

From robin.murphy at arm.com  Thu Apr  1 18:19:32 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 1 Apr 2021 18:19:32 +0100
Subject: [RFC PATCH 4/5] iommu/io-pgtable-arm: Implement
 arm_lpae_unmap_pages()
In-Reply-To: <20210331030042.13348-5-isaacm@codeaurora.org>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
 <20210331030042.13348-5-isaacm@codeaurora.org>
Message-ID: <b93fa0b1-e2a4-1aad-8b88-4d0dfecdfef7@arm.com>

On 2021-03-31 04:00, Isaac J. Manjarres wrote:
> Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> format.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>   drivers/iommu/io-pgtable-arm.c | 114 +++++++++++++++++++++++++++------
>   1 file changed, 94 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 87def58e79b5..6eccebf1744d 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -248,10 +248,26 @@ static void __arm_lpae_set_pte(arm_lpae_iopte *ptep, arm_lpae_iopte pte,
>   		__arm_lpae_sync_pte(ptep, cfg);
>   }
>   
> +static void __arm_lpae_sync_ptes(arm_lpae_iopte *ptep, size_t num_ptes,
> +				 struct io_pgtable_cfg *cfg)
> +{
> +	dma_sync_single_for_device(cfg->iommu_dev, __arm_lpae_dma_addr(ptep),
> +				   sizeof(*ptep) * num_ptes, DMA_TO_DEVICE);
> +}
> +
> +static void __arm_lpae_clear_ptes(arm_lpae_iopte *ptep, size_t num_ptes,
> +				  struct io_pgtable_cfg *cfg)
> +{
> +	memset(ptep, 0, sizeof(*ptep) * num_ptes);
> +
> +	if (!cfg->coherent_walk)
> +		__arm_lpae_sync_ptes(ptep, num_ptes, cfg);
> +}
> +

It seesm like overkill to add separate functions - the existing ones 
could easily just take an extra argument, like we do for the v7s format.

>   static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
>   			       struct iommu_iotlb_gather *gather,
> -			       unsigned long iova, size_t size, int lvl,
> -			       arm_lpae_iopte *ptep);
> +			       unsigned long iova, size_t size, size_t pgcount,
> +			       int lvl, arm_lpae_iopte *ptep);
>   
>   static void __arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>   				phys_addr_t paddr, arm_lpae_iopte prot,
> @@ -289,7 +305,7 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>   		size_t sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
>   
>   		tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
> -		if (__arm_lpae_unmap(data, NULL, iova, sz, lvl, tblp) != sz) {
> +		if (__arm_lpae_unmap(data, NULL, iova, sz, 1, lvl, tblp) != sz) {
>   			WARN_ON(1);
>   			return -EINVAL;
>   		}
> @@ -516,14 +532,14 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>   				       struct iommu_iotlb_gather *gather,
>   				       unsigned long iova, size_t size,
>   				       arm_lpae_iopte blk_pte, int lvl,
> -				       arm_lpae_iopte *ptep)
> +				       arm_lpae_iopte *ptep, size_t pgcount)
>   {
>   	struct io_pgtable_cfg *cfg = &data->iop.cfg;
>   	arm_lpae_iopte pte, *tablep;
>   	phys_addr_t blk_paddr;
>   	size_t tablesz = ARM_LPAE_GRANULE(data);
>   	size_t split_sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
> -	int i, unmap_idx = -1;
> +	int i, unmap_idx_start = -1;
>   
>   	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
>   		return 0;
> @@ -533,14 +549,14 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>   		return 0; /* Bytes unmapped */
>   
>   	if (size == split_sz)
> -		unmap_idx = ARM_LPAE_LVL_IDX(iova, lvl, data);
> +		unmap_idx_start = ARM_LPAE_LVL_IDX(iova, lvl, data);
>   
>   	blk_paddr = iopte_to_paddr(blk_pte, data);
>   	pte = iopte_prot(blk_pte);
>   
>   	for (i = 0; i < tablesz / sizeof(pte); i++, blk_paddr += split_sz) {
>   		/* Unmap! */
> -		if (i == unmap_idx)
> +		if (i >= unmap_idx_start && i < (unmap_idx_start + pgcount))
>   			continue;
>   
>   		__arm_lpae_init_pte(data, blk_paddr, pte, lvl, &tablep[i]);
> @@ -558,20 +574,24 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>   			return 0;
>   
>   		tablep = iopte_deref(pte, data);
> -	} else if (unmap_idx >= 0) {
> -		io_pgtable_tlb_add_page(&data->iop, gather, iova, size);
> -		return size;
> +	} else if (unmap_idx_start >= 0) {
> +		for (i = 0; i < pgcount; i++) {
> +			io_pgtable_tlb_add_page(&data->iop, gather, iova, size);
> +			iova += size;
> +		}
> +		return pgcount * size;
>   	}
>   
> -	return __arm_lpae_unmap(data, gather, iova, size, lvl, tablep);
> +	return __arm_lpae_unmap(data, gather, iova, size, pgcount, lvl, tablep);
>   }
>   
>   static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
>   			       struct iommu_iotlb_gather *gather,
> -			       unsigned long iova, size_t size, int lvl,
> -			       arm_lpae_iopte *ptep)
> +			       unsigned long iova, size_t size, size_t pgcount,
> +			       int lvl, arm_lpae_iopte *ptep)
>   {
>   	arm_lpae_iopte pte;
> +	size_t i;
>   	struct io_pgtable *iop = &data->iop;
>   
>   	/* Something went horribly wrong and we ran out of page table */
> @@ -585,11 +605,11 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
>   
>   	/* If the size matches this level, we're in the right place */
>   	if (size == ARM_LPAE_BLOCK_SIZE(lvl, data)) {
> -		__arm_lpae_set_pte(ptep, 0, &iop->cfg);
> +		__arm_lpae_clear_ptes(ptep, pgcount, &iop->cfg);
>   
>   		if (!iopte_leaf(pte, lvl, iop->fmt)) {
>   			/* Also flush any partial walks */
> -			io_pgtable_tlb_flush_walk(iop, iova, size,
> +			io_pgtable_tlb_flush_walk(iop, iova, pgcount * size,
>   						  ARM_LPAE_GRANULE(data));
>   			ptep = iopte_deref(pte, data);
>   			__arm_lpae_free_pgtable(data, lvl + 1, ptep);
> @@ -601,22 +621,25 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
>   			 */
>   			smp_wmb();
>   		} else {
> -			io_pgtable_tlb_add_page(iop, gather, iova, size);
> +			for (i = 0; i < pgcount; i++) {
> +				io_pgtable_tlb_add_page(iop, gather, iova, size);
> +				iova += size;
> +			}
>   		}
>   
> -		return size;
> +		return pgcount * size;
>   	} else if (iopte_leaf(pte, lvl, iop->fmt)) {
>   		/*
>   		 * Insert a table at the next level to map the old region,
>   		 * minus the part we want to unmap
>   		 */
>   		return arm_lpae_split_blk_unmap(data, gather, iova, size, pte,
> -						lvl + 1, ptep);
> +						lvl + 1, ptep, pgcount);
>   	}
>   
>   	/* Keep on walkin' */
>   	ptep = iopte_deref(pte, data);
> -	return __arm_lpae_unmap(data, gather, iova, size, lvl + 1, ptep);
> +	return __arm_lpae_unmap(data, gather, iova, size, pgcount, lvl + 1, ptep);
>   }
>   
>   static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> @@ -635,7 +658,57 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
>   	if (WARN_ON(iaext))
>   		return 0;
>   
> -	return __arm_lpae_unmap(data, gather, iova, size, data->start_level, ptep);
> +	return __arm_lpae_unmap(data, gather, iova, size, 1, data->start_level, ptep);
> +}
> +
> +static size_t arm_lpae_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
> +				   size_t pgsize, size_t pgcount,
> +				   struct iommu_iotlb_gather *gather)
> +{
> +	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> +	struct io_pgtable_cfg *cfg = &data->iop.cfg;
> +	arm_lpae_iopte *ptep = data->pgd;
> +	long iaext = (s64)iova >> cfg->ias;
> +	size_t unmapped = 0, unmapped_page;
> +	int last_lvl = data->start_level;
> +	size_t table_size, pages, tbl_offset, max_entries;
> +
> +	if (WARN_ON(!pgsize || (pgsize & cfg->pgsize_bitmap) != pgsize || !pgcount))
> +		return 0;
> +
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> +		iaext = ~iaext;
> +	if (WARN_ON(iaext))
> +		return 0;
> +
> +	/*
> +	 * Calculating the page table size here helps avoid situations where
> +	 * a page range that is being unmapped may be mapped at the same level
> +	 * but not mapped by the same tables. Allowing such a scenario to
> +	 * occur can complicate the logic in arm_lpae_split_blk_unmap().
> +	 */
> +	while (ARM_LPAE_BLOCK_SIZE(last_lvl, data) != pgsize)
> +		last_lvl++;
> +
> +	table_size = last_lvl == data->start_level ? ARM_LPAE_PGD_SIZE(data) :
> +		ARM_LPAE_GRANULE(data);
> +	max_entries = table_size / sizeof(*ptep);

I'm really struggling to understand what's going on here :/

When would table_size ever not be equal to page_size? (In a way that 
matters - manipulating top-level block entries in a concatenated stage 2 
table is hardly going to be common enough to deserve specific optimisation)

> +	while (pgcount) {
> +		tbl_offset = ARM_LPAE_LVL_IDX(iova, last_lvl, data);
> +		pages = min_t(size_t, pgcount, max_entries - tbl_offset);
> +		unmapped_page = __arm_lpae_unmap(data, gather, iova, pgsize,
> +						 pages, data->start_level,
> +						 ptep);

This again seems less efficient than it deserves to be - iterating 
within __arm_lpae_unmap() itself would seem to make more sense than 
recursing all the way in and out multiple times per operation.

> +		if (!unmapped_page)
> +			break;
> +
> +		unmapped += unmapped_page;
> +		iova += unmapped_page;
> +		pgcount -= pages;
> +	}
> +
> +	return unmapped;
>   }
>   
>   static phys_addr_t arm_lpae_iova_to_phys(struct io_pgtable_ops *ops,
> @@ -751,6 +824,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
>   	data->iop.ops = (struct io_pgtable_ops) {
>   		.map		= arm_lpae_map,
>   		.unmap		= arm_lpae_unmap,
> +		.unmap_pages	= arm_lpae_unmap_pages,

Why would we need to keep the old callback and have a bunch of 
duplicated code? Even fully converting all the users isn't _that_ 
involved, but having them just call .unmap_pages with n=1 is even less so.

Robin.

>   		.iova_to_phys	= arm_lpae_iova_to_phys,
>   	};
>   
> 


From broonie at kernel.org  Thu Apr  1 18:21:14 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 18:21:14 +0100
Subject: [RFC PATCH v1 2/4] arm64: Mark a stack trace unreliable if an
 EL1 exception frame is detected
In-Reply-To: <20210330190955.13707-3-madvenka@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-3-madvenka@linux.microsoft.com>
Message-ID: <20210401172114.GM4758@sirena.org.uk>

On Tue, Mar 30, 2021 at 02:09:53PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> EL1 exceptions can happen on any instruction including instructions in
> the frame pointer prolog or epilog. Depending on where exactly they happen,
> they could render the stack trace unreliable.

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/20210401/bb63561d/attachment-0001.sig>

From mathieu.poirier at linaro.org  Thu Apr  1 18:21:43 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 1 Apr 2021 11:21:43 -0600
Subject: [PATCH v5 08/10] coresight: config: Add preloaded configurations
In-Reply-To: <20210316180400.7184-9-mike.leach@linaro.org>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-9-mike.leach@linaro.org>
Message-ID: <20210401172143.GD145043@xps15>

On Tue, Mar 16, 2021 at 06:03:58PM +0000, Mike Leach wrote:
> Preload set of configurations.
> 
> This patch creates a small set of preloaded configurations and features
> that are available immediately after coresight has been initialised.
> 
> The current set provides a strobing feature for ETMv4, that creates a
> periodic sampling of trace by switching trace generation on and off
> using counters in the ETM.
> 
> A configuration called "autofdo" is also provided that uses the 'strobing'
> feature and provides a couple of preset values, selectable on the perf
> command line.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> ---
>  drivers/hwtracing/coresight/Makefile          |   3 +-
>  .../hwtracing/coresight/coresight-cfg-afdo.c  | 149 ++++++++++++++++++
>  .../coresight/coresight-cfg-preload.c         |  27 ++++
>  .../coresight/coresight-cfg-preload.h         |  11 ++
>  .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
>  .../hwtracing/coresight/coresight-syscfg.c    |   9 ++
>  .../hwtracing/coresight/coresight-syscfg.h    |   1 +
>  7 files changed, 214 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h
> 

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index ea544206204d..2707bfef1b76 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -4,7 +4,8 @@
>  #
>  obj-$(CONFIG_CORESIGHT) += coresight.o
>  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
> -		coresight-sysfs.o coresight-syscfg.o coresight-config.o
> +		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
> +		coresight-cfg-preload.o coresight-cfg-afdo.o
>  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
>  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
>  		      coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight-cfg-afdo.c b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
> new file mode 100644
> index 000000000000..44d60ca1da49
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +#include "coresight-config.h"
> +#include "coresight-etm4x-cfg.h"
> +
> +/* preload configurations and features */
> +
> +/* preload in features for ETMv4 */
> +
> +/* strobe feature */
> +static struct cscfg_parameter_desc strobe_params[] = {
> +	{
> +		.name = "window",
> +		.value = 5000,
> +	},
> +	{
> +		.name = "period",
> +		.value = 10000,
> +	},
> +};
> +
> +static struct cscfg_regval_desc strobe_regs[] = {
> +	/* resource selectors */
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCRSCTLRn(2),
> +		.hw_info = ETM4_CFG_RES_SEL,
> +		.val32 = 0x20001,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCRSCTLRn(3),
> +		.hw_info = ETM4_CFG_RES_SEQ,
> +		.val32 = 0x20002,
> +	},
> +	/* strobe window counter 0 - reload from param 0 */
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
> +		.offset = TRCCNTVRn(0),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
> +		.offset = TRCCNTRLDVRn(0),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +		.val32 = 0,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCCNTCTLRn(0),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +		.val32 = 0x10001,
> +	},
> +	/* strobe period counter 1 - reload from param 1 */
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
> +		.offset = TRCCNTVRn(1),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
> +		.offset = TRCCNTRLDVRn(1),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +		.val32 = 1,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCCNTCTLRn(1),
> +		.hw_info = ETM4_CFG_RES_CTR,
> +		.val32 = 0x8102,
> +	},
> +	/* sequencer */
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCSEQEVRn(0),
> +		.hw_info = ETM4_CFG_RES_SEQ,
> +		.val32 = 0x0081,
> +	},
> +	{
> +		.type = CS_CFG_REG_TYPE_RESOURCE,
> +		.offset = TRCSEQEVRn(1),
> +		.hw_info = ETM4_CFG_RES_SEQ,
> +		.val32 = 0x0000,
> +	},
> +	/* view-inst */
> +	{
> +		.type = CS_CFG_REG_TYPE_STD | CS_CFG_REG_TYPE_VAL_MASK,
> +		.offset = TRCVICTLR,
> +		.val32 = 0x0003,
> +		.mask32 = 0x0003,
> +	},
> +	/* end of regs */
> +};
> +
> +struct cscfg_feature_desc strobe = {
> +	.name = "strobing",
> +	.description = "Generate periodic trace capture windows.\n"
> +		       "parameter \'window\': a number of CPU cycles (W)\n"
> +		       "parameter \'period\': trace enabled for W cycles every period x W cycles\n",
> +	.match_flags = CS_CFG_MATCH_CLASS_SRC_ETM4,
> +	.nr_params = ARRAY_SIZE(strobe_params),
> +	.params_desc = strobe_params,
> +	.nr_regs = ARRAY_SIZE(strobe_regs),
> +	.regs_desc = strobe_regs,
> +};
> +
> +/* create an autofdo configuration */
> +
> +/* we will provide 9 sets of preset parameter values */
> +#define AFDO_NR_PRESETS	9
> +/* the total number of parameters in used features */
> +#define AFDO_NR_PARAMS	ARRAY_SIZE(strobe_params)
> +
> +#define AFDO_MATCH_STROBING (CS_CFG_MATCH_INST_ANY | CS_CFG_MATCH_CLASS_SRC_ETM4)
> +
> +static const char *afdo_ref_names[] = {
> +	"strobing",
> +};
> +
> +/*
> + * set of presets leaves strobing window constant while varying period to allow
> + * experimentation with mark / space ratios for various workloads
> + */
> +static u64 afdo_presets[AFDO_NR_PRESETS][AFDO_NR_PARAMS] = {
> +	{ 5000, 2 },
> +	{ 5000, 4 },
> +	{ 5000, 8 },
> +	{ 5000, 16 },
> +	{ 5000, 64 },
> +	{ 5000, 128 },
> +	{ 5000, 512 },
> +	{ 5000, 1024 },
> +	{ 5000, 4096 },
> +};
> +
> +struct cscfg_config_desc afdo = {
> +	.name = "autofdo",
> +	.description = "Setup ETMs with strobing for autofdo\n"
> +	"Supplied presets allow experimentation with mark-space ratio for various loads\n",
> +	.nr_feat_refs = ARRAY_SIZE(afdo_ref_names),
> +	.feat_ref_names = afdo_ref_names,
> +	.nr_presets = AFDO_NR_PRESETS,
> +	.nr_total_params = AFDO_NR_PARAMS,
> +	.presets = &afdo_presets[0][0],
> +};
> diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.c b/drivers/hwtracing/coresight/coresight-cfg-preload.c
> new file mode 100644
> index 000000000000..9ed0f029a335
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cfg-preload.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +#include "coresight-cfg-preload.h"
> +#include "coresight-config.h"
> +#include "coresight-syscfg.h"
> +
> +/* Basic features and configurations pre-loaded on initialisation */
> +
> +static struct cscfg_feature_desc *preload_feats[] = {
> +	&strobe,
> +	0
> +};
> +
> +static struct cscfg_config_desc *preload_cfgs[] = {
> +	&afdo,
> +	0
> +};
> +
> +/* preload called on initialisation */
> +int cscfg_preload(void)
> +{
> +	return cscfg_load_config_sets(preload_cfgs, preload_feats);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.h b/drivers/hwtracing/coresight/coresight-cfg-preload.h
> new file mode 100644
> index 000000000000..fc4ac7faa93d
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-cfg-preload.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +/* declare preloaded configurations and features */
> +
> +/* from coresight-cfg-afdo.c */
> +extern struct cscfg_feature_desc strobe;
> +extern struct cscfg_config_desc afdo;
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> index 7ec65771ee58..1f5477883818 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> @@ -9,6 +9,21 @@
>  #include "coresight-config.h"
>  #include "coresight-etm4x.h"
>  
> +/* ETMv4 specific config defines */
> +
> +/* resource IDs */
> +
> +#define ETM4_CFG_RES_CTR	0x001
> +#define ETM4_CFG_RES_CMP	0x002
> +#define ETM4_CFG_RES_CMP_PAIR0	0x003
> +#define ETM4_CFG_RES_CMP_PAIR1	0x004
> +#define ETM4_CFG_RES_SEL	0x005
> +#define ETM4_CFG_RES_SEL_PAIR0	0x006
> +#define ETM4_CFG_RES_SEL_PAIR1	0x007
> +#define ETM4_CFG_RES_SEQ	0x008
> +#define ETM4_CFG_RES_TS		0x009
> +#define ETM4_CFG_RES_MASK	0x00F
> +
>  /* ETMv4 specific config functions */
>  int etm4_cscfg_register(struct coresight_device *csdev, const char *dev_name);
>  
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> index c44746d6cd6d..befc379b85b9 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> @@ -642,8 +642,17 @@ int __init cscfg_init(void)
>  	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
>  	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
>  
> +	/* preload built-in configurations */
> +	err = cscfg_preload();
> +	if (err)
> +		goto exit_err;
> +
>  	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
>  	return 0;
> +
> +exit_err:
> +	cscfg_clear_device();
> +	return err;
>  }
>  
>  void cscfg_exit(void)
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
> index a52775890670..7bb8c8e497ba 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.h
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.h
> @@ -56,6 +56,7 @@ struct cscfg_registered_csdev {
>  /* internal core operations for cscfg */
>  int __init cscfg_init(void);
>  void cscfg_exit(void);
> +int cscfg_preload(void);
>  
>  /* syscfg manager external API */
>  int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
> -- 
> 2.17.1
> 


From will at kernel.org  Thu Apr  1 18:23:24 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 1 Apr 2021 18:23:24 +0100
Subject: [PATCH] perf: xgene: Use device_get_match_data() to simplify code
In-Reply-To: <fda6cf28-6aba-9a48-fee4-a3c538b8a477@huawei.com>
References: <1617248204-8472-1-git-send-email-tiantao6@hisilicon.com>
 <20210401090800.GC8781@willie-the-truck>
 <fda6cf28-6aba-9a48-fee4-a3c538b8a477@huawei.com>
Message-ID: <20210401172323.GE9447@willie-the-truck>

On Thu, Apr 01, 2021 at 05:17:17PM +0800, tiantao (H) wrote:
> 
> ? 2021/4/1 17:08, Will Deacon ??:
> > On Thu, Apr 01, 2021 at 11:36:44AM +0800, Tian Tao wrote:
> > > Use device_get_match_data() here to simplify the code a bit.
> > > 
> > > Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> > > ---
> > >   drivers/perf/xgene_pmu.c | 17 ++---------------
> > >   1 file changed, 2 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
> > > index ffe3bde..befd2eb 100644
> > > --- a/drivers/perf/xgene_pmu.c
> > > +++ b/drivers/perf/xgene_pmu.c
> > > @@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> > >   static int xgene_pmu_probe(struct platform_device *pdev)
> > >   {
> > >   	const struct xgene_pmu_data *dev_data;
> > > -	const struct of_device_id *of_id;
> > >   	struct xgene_pmu *xgene_pmu;
> > >   	struct resource *res;
> > >   	int irq, rc;
> > > @@ -1857,21 +1856,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
> > >   	platform_set_drvdata(pdev, xgene_pmu);
> > >   	version = -EINVAL;
> > > -	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
> > > -	if (of_id) {
> > > -		dev_data = (const struct xgene_pmu_data *) of_id->data;
> > > -		version = dev_data->id;
> > > -	}
> > > -
> > > -#ifdef CONFIG_ACPI
> > > -	if (ACPI_COMPANION(&pdev->dev)) {
> > > -		const struct acpi_device_id *acpi_id;
> > > +	dev_data = device_get_match_data(&pdev->dev);
> > > +	version = dev_data->id;
> > What prevents device_get_match_data() from returning NULL? The old code
> > handled the case where we didn't get a match.
> 
> What about doing it like this?

Sure, or even just have:

	version = dev_data ? dev_data->id : -EINVAL;

and drop the earlier assignment of -EINVAL;

Will


From broonie at kernel.org  Thu Apr  1 18:23:37 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 18:23:37 +0100
Subject: [RFC PATCH v1 4/4] arm64: Mark stack trace as unreliable if
 kretprobed functions are present
In-Reply-To: <20210330190955.13707-5-madvenka@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-5-madvenka@linux.microsoft.com>
Message-ID: <20210401172337.GN4758@sirena.org.uk>

On Tue, Mar 30, 2021 at 02:09:55PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> When a kretprobe is active for a function, the function's return address
> in its stack frame is modified to point to the kretprobe trampoline. When
> the function returns, the frame is popped and control is transferred
> to the trampoline. The trampoline eventually returns to the original return
> address.

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/20210401/b0cb30af/attachment.sig>

From thierry.reding at gmail.com  Thu Apr  1 18:26:18 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  1 Apr 2021 19:26:18 +0200
Subject: [GIT PULL 1/5] dt-bindings: Changes for v5.13-rc1
Message-ID: <20210401172622.3352990-1-thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-dt-bindings

for you to fetch changes up to d1e24c46250731204dbf61b5191e4dcf2c2d9391:

  dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop (2021-03-24 14:04:40 +0100)

Thanks,
Thierry

----------------------------------------------------------------
dt-bindings: Changes for v5.13-rc1

One single changes that adds the nvidia,pmc property to the XUSB pad
controller binding, which will subsequently be used to implement USB
sleepwalk functionality.

----------------------------------------------------------------
JC Kuo (1):
      dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop

 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt | 1 +
 1 file changed, 1 insertion(+)


From thierry.reding at gmail.com  Thu Apr  1 18:26:19 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  1 Apr 2021 19:26:19 +0200
Subject: [GIT PULL 2/5] clk: tegra: Changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-1-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
Message-ID: <20210401172622.3352990-2-thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-clk

for you to fetch changes up to 0c7ea2b1c850756140fef03bed0fbaf0957f120a:

  clk: tegra: Don't enable PLLE HW sequencer at init (2021-03-24 14:02:14 +0100)

Thanks,
Thierry

----------------------------------------------------------------
clk: tegra: Changes for v5.13-rc1

This adds PLLE HW sequencer support which is necessary for USB sleepwalk
functionality.

----------------------------------------------------------------
JC Kuo (2):
      clk: tegra: Add PLLE HW power sequencer control
      clk: tegra: Don't enable PLLE HW sequencer at init

 drivers/clk/tegra/clk-pll.c      | 12 ---------
 drivers/clk/tegra/clk-tegra210.c | 53 +++++++++++++++++++++++++++++++++++++++-
 include/linux/clk/tegra.h        |  4 ++-
 3 files changed, 55 insertions(+), 14 deletions(-)


From thierry.reding at gmail.com  Thu Apr  1 18:26:20 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  1 Apr 2021 19:26:20 +0200
Subject: [GIT PULL 3/5] soc/tegra: Changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-1-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
Message-ID: <20210401172622.3352990-3-thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-soc

for you to fetch changes up to 366d7c643a8a9db652341e314b33d3fc80595e6c:

  soc/tegra: pmc: Print out domain name when reset fails to acquire (2021-03-26 13:10:25 +0100)

Thanks,
Thierry

----------------------------------------------------------------
soc/tegra: Changes for v5.13-rc1

Contains a couple of fixes to the PMC power domain implementation and
exports a regmap from PMC needed to implement USB sleepwalk support.

----------------------------------------------------------------
Dmitry Osipenko (5):
      soc/tegra: regulators: Fix locking up when voltage-spread is out of range
      soc/tegra: pmc: Fix imbalanced clock disabling in error code path
      soc/tegra: pmc: Fix completion of power-gate toggling
      soc/tegra: pmc: Ensure that clock rates aren't too high
      soc/tegra: pmc: Print out domain name when reset fails to acquire

JC Kuo (1):
      soc/tegra: pmc: Provide USB sleepwalk register map

 drivers/soc/tegra/pmc.c                | 259 ++++++++++++++++++++++++++++++++-
 drivers/soc/tegra/regulators-tegra30.c |   2 +-
 2 files changed, 252 insertions(+), 9 deletions(-)


From thierry.reding at gmail.com  Thu Apr  1 18:26:21 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  1 Apr 2021 19:26:21 +0200
Subject: [GIT PULL 4/5] ARM: tegra: Device tree changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-1-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
Message-ID: <20210401172622.3352990-4-thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm-dt

for you to fetch changes up to 3a6c267dd7b8822eb722835b503c5a438cbd3700:

  ARM: tegra: acer-a500: Add atmel,wakeup-method property (2021-03-26 14:21:28 +0100)

Thanks,
Thierry

----------------------------------------------------------------
ARM: tegra: Device tree changes for v5.13-rc1

This contains a couple of improvements and fixes for various 32-bit
Tegra-based boards.

----------------------------------------------------------------
Dmitry Osipenko (15):
      ARM: tegra: ventana: Support CPU and Core voltage scaling
      ARM: tegra: ventana: Support CPU thermal throttling
      ARM: tegra: cardhu: Support CPU frequency and voltage scaling on all board variants
      ARM: tegra: cardhu: Support CPU thermal throttling
      ARM: tegra: paz00: Enable full voltage scaling ranges for CPU and Core domains
      ARM: tegra: acer-a500: Enable core voltage scaling
      ARM: tegra: acer-a500: Reduce thermal throttling hysteresis to 0.2C
      ARM: tegra: acer-a500: Specify all CPU cores as cooling devices
      ARM: tegra: acer-a500: Rename avdd to vdda of touchscreen node
      ARM: tegra: nexus7: Specify all CPU cores as cooling devices
      ARM: tegra: ouya: Specify all CPU cores as cooling devices
      ARM: tegra: Specify CPU suspend OPP in device-tree
      ARM: tegra: Specify memory suspend OPP in device-tree
      ARM: tegra: Specify tps65911 as wakeup source
      ARM: tegra: acer-a500: Add atmel,wakeup-method property

 arch/arm/boot/dts/tegra124-peripherals-opp.dtsi    |  5 ++
 arch/arm/boot/dts/tegra20-acer-a500-picasso.dts    | 16 +++--
 arch/arm/boot/dts/tegra20-cpu-opp.dtsi             |  2 +
 arch/arm/boot/dts/tegra20-paz00.dts                | 14 ++--
 arch/arm/boot/dts/tegra20-peripherals-opp.dtsi     |  1 +
 arch/arm/boot/dts/tegra20-ventana.dts              | 78 +++++++++++++++++---
 arch/arm/boot/dts/tegra30-apalis.dtsi              |  1 +
 .../dts/tegra30-asus-nexus7-grouper-common.dtsi    | 14 ++--
 .../dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi   |  1 +
 arch/arm/boot/dts/tegra30-beaver.dts               |  1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           | 48 -------------
 arch/arm/boot/dts/tegra30-cardhu.dtsi              | 84 ++++++++++++++++++++--
 arch/arm/boot/dts/tegra30-colibri.dtsi             |  1 +
 arch/arm/boot/dts/tegra30-cpu-opp.dtsi             |  3 +
 arch/arm/boot/dts/tegra30-ouya.dts                 | 16 +++--
 arch/arm/boot/dts/tegra30-peripherals-opp.dtsi     |  3 +
 16 files changed, 204 insertions(+), 84 deletions(-)


From thierry.reding at gmail.com  Thu Apr  1 18:26:22 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  1 Apr 2021 19:26:22 +0200
Subject: [GIT PULL 5/5] arm64: tegra: Device tree fixes for v5.12-rc6
In-Reply-To: <20210401172622.3352990-1-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
Message-ID: <20210401172622.3352990-5-thierry.reding@gmail.com>

Hi ARM SoC maintainers,

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm64-dt

for you to fetch changes up to 405fa9e9d8664e830982c5fbcb70f9ba8656bafc:

  arm64: tegra: Move clocks from RT5658 endpoint to device node (2021-03-25 14:04:49 +0100)

Thanks,
Thierry

----------------------------------------------------------------
arm64: tegra: Device tree fixes for v5.12-rc6

This contains a couple of device tree fixes for the v5.12 release cycle.
These are needed for proper audio support on Jetson AGX Xavier, to boot
the Jetson Xavier NX from an SD card and to be able to suspend/resume
the Jetson TX2.

----------------------------------------------------------------
Jon Hunter (2):
      arm64: tegra: Set fw_devlink=on for Jetson TX2
      arm64: tegra: Fix mmc0 alias for Jetson Xavier NX

Sameer Pujar (1):
      arm64: tegra: Move clocks from RT5658 endpoint to device node

Thierry Reding (1):
      arm64: tegra: Add unit-address for ACONNECT on Tegra186

 arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts  | 2 +-
 arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi      | 2 +-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi            | 2 +-
 arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts  | 3 ++-
 arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi | 4 ++++
 arch/arm64/boot/dts/nvidia/tegra194-p3668-0001.dtsi | 4 ++++
 arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi      | 1 -
 7 files changed, 13 insertions(+), 5 deletions(-)


From will at kernel.org  Thu Apr  1 18:33:31 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 18:33:31 +0100
Subject: [PATCH] arm64: perf: Remove redundant initialization in
 perf_event.c
In-Reply-To: <1617275801-1980-1-git-send-email-liuqi115@huawei.com>
References: <1617275801-1980-1-git-send-email-liuqi115@huawei.com>
Message-ID: <161729673248.2265527.16326375852509765963.b4-ty@kernel.org>

On Thu, 1 Apr 2021 19:16:41 +0800, Qi Liu wrote:
> The initialization of value in function armv8pmu_read_hw_counter()
> and armv8pmu_read_counter() seem redundant, as they are soon updated.
> So, We can remove them.

Applied to will (for-next/perf), thanks!

[1/1] arm64: perf: Remove redundant initialization in perf_event.c
      https://git.kernel.org/will/c/2c2e21e78a94

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From will at kernel.org  Thu Apr  1 18:33:32 2021
From: will at kernel.org (Will Deacon)
Date: Thu,  1 Apr 2021 18:33:32 +0100
Subject: [PATCH] arm64: fix inline asm in load_unaligned_zeropad()
In-Reply-To: <20210401165110.3952103-1-pcc@google.com>
References: <20210401165110.3952103-1-pcc@google.com>
Message-ID: <161729737453.2267359.5680771151630291141.b4-ty@kernel.org>

On Thu, 1 Apr 2021 09:51:10 -0700, Peter Collingbourne wrote:
> The inline asm's addr operand is marked as input-only, however in
> the case where an exception is taken it may be modified by the BIC
> instruction on the exception path. Fix the problem by using a temporary
> register as the destination register for the BIC instruction.

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64: fix inline asm in load_unaligned_zeropad()
      https://git.kernel.org/arm64/c/185f2e5f51c2

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From konrad.wilk at oracle.com  Thu Apr  1 18:33:23 2021
From: konrad.wilk at oracle.com (Konrad Rzeszutek Wilk)
Date: Thu, 1 Apr 2021 13:33:23 -0400
Subject: [PATCH] ARM: Qualify enabling of swiotlb_init()
In-Reply-To: <20210330053607.GA4863@lst.de>
References: <20210319040333.183827-1-f.fainelli@gmail.com>
 <20210319130731.GB2624@lst.de>
 <20210319195929.GA1346384@konrad-char-us-oracle-com.allregionaliads.osdevelopmeniad.oraclevcn.com>
 <alpine.DEB.2.21.2103191718210.439@sstabellini-ThinkPad-T480s>
 <3db926f4-6047-cc62-8654-a965b8570e75@gmail.com>
 <20210330053607.GA4863@lst.de>
Message-ID: <YGYD40RbKN9r8I8n@Konrads-MacBook-Pro.local>

On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote:
> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
> > Should I toss this in Russell's patch tracker or do you need me to make
> > some changes to the patch?
> 
> Due to all the other changes in this area I don't think anything but
> the swiotlb tree makes much sense here.

I've put them all on 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
devel/for-linus-5.13




From cristian.ciocaltea at gmail.com  Thu Apr  1 18:40:01 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 20:40:01 +0300
Subject: [PATCH v2 1/6] dt-bindings: reserved-memory: Add Owl SoC serial
 number binding
In-Reply-To: <20210401170704.GA610119@robh.at.kernel.org>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <fb74862bec15f1e9e0c4d8b70ebd6c07c6eb1a40.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401170704.GA610119@robh.at.kernel.org>
Message-ID: <20210401174001.GA2016477@BV030612LT>

On Thu, Apr 01, 2021 at 12:07:04PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 04:48:16PM +0300, Cristian Ciocaltea wrote:
> > Add devicetree binding for the Actions Semi Owl SoC serial number
> > reserved-memory range.
> > 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > ---
> >  .../actions,owl-soc-serial.yaml               | 53 +++++++++++++++++++
> >  1 file changed, 53 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > new file mode 100644
> > index 000000000000..41b71f47ee6c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > @@ -0,0 +1,53 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reserved-memory/actions,owl-soc-serial.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Actions Semi Owl reserved-memory for SoC serial number
> > +
> > +maintainers:
> > +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > +
> > +description: |
> > +  Provide access to the memory region where the two parts of the Actions
> > +  Semi Owl SoC serial number (low & high) can be read from. This information
> > +  is provided by the bootloader, hence expose it under /reserved-memory node.
> > +
> > +  Please refer to reserved-memory.txt in this directory for common binding
> > +  part and usage.
> > +
> > +  This is currently supported only on the S500 SoC variant.
> > +
> > +properties:
> > +  compatible:
> > +    oneOf:
> > +      - const: actions,owl-soc-serial
> > +      - items:
> > +          - enum:
> > +              - actions,s500-soc-serial
> > +          - const: actions,owl-soc-serial
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > +  - |
> > +    reserved-memory {
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +        ranges;
> > +
> > +        soc_serial: soc-serial at 800 {
> > +            compatible = "actions,s500-soc-serial", "actions,owl-soc-serial";
> > +            reg = <0x800 0x8>;
> 
> You end up wasting a whole page of memory for 8 bytes. It may be better 
> to copy this to a DT property ('serial-number' is already a defined root 
> property).

Actually there is more information provided by the vendor bootloader
in this memory page, so we might use it once we are able to decode it.
For the moment I could only identify the serial number.

Thanks,
Cristi

> Rob


From krzysztof.kozlowski at canonical.com  Thu Apr  1 18:41:04 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu,  1 Apr 2021 19:41:04 +0200
Subject: [PATCH] ARM: s3c/rx1950: Use pwm_get() in favour of pwm_request()
In-Reply-To: <20210326090641.122436-1-u.kleine-koenig@pengutronix.de>
References: <20210326090641.122436-1-u.kleine-koenig@pengutronix.de>
Message-ID: <161729885474.9397.10566581741781836932.b4-ty@canonical.com>

On Fri, 26 Mar 2021 10:06:41 +0100, Uwe Kleine-K?nig wrote:
> pwm_request() is deprecated because (among others) it depends on a global
> numbering of PWM devices. So register a pwm_lookup to pick the right PWM
> device (identified by provider and its local id) and use pwm_get().
> 
> Before this patch the PWM #1 was used. This is provided by the
> samsung-pwm device which is the only PWM provider on this machine. The
> local offset is 1, see also commit c107fe904a10 ("ARM: S3C24XX: Use PWM
> lookup table for mach-rx1950") with a similar conversion for PWM #0.
> 
> [...]

Applied, thanks!

[1/1] ARM: s3c/rx1950: Use pwm_get() in favour of pwm_request()
      commit: 19f5027e0394d2f3e1766200b6bbde660f0b7848

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


From madvenka at linux.microsoft.com  Thu Apr  1 18:43:25 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 12:43:25 -0500
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210401142759.GJ4758@sirena.org.uk>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
Message-ID: <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>



On 4/1/21 9:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:54PM -0500, madvenka at linux.microsoft.com wrote:
> 
>> +	 * FTRACE trampolines.
>> +	 */
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> +	{ (unsigned long) &ftrace_graph_call, 0 },
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> +	{ (unsigned long) ftrace_graph_caller, 0 },
>> +	{ (unsigned long) return_to_handler, 0 },
>> +#endif
>> +#endif
> 
> It's weird that we take the address of ftrace_graph_call but not the
> other functions - we should be consistent or explain why.  It'd probably
> also look nicer to not nest the ifdefs, the dependencies in Kconfig will
> ensure we only get things when we should.
> 

I have explained it in the comment in the FTRACE trampoline right above
ftrace_graph_call().

        /*
         * The only call in the FTRACE trampoline code is above. The above
         * instruction is patched to call a tracer function. Its return
         * address is below (ftrace_graph_call). In a stack trace taken from
         * a tracer function, ftrace_graph_call() will show. The unwinder
         * checks this for reliable stack trace. Please see the comments
         * in stacktrace.c. If another call is added in the FTRACE
         * trampoline code, the special_functions[] array in stacktrace.c
         * must be updated.
         */

I also noticed that I have to fix something here. The label ftrace_graph_call
is defined like this:


#ifdef CONFIG_FUNCTION_GRAPH_TRACER
SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
        nop                             // If enabled, this will be replaced
                                        // "b ftrace_graph_caller"
#endif

So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
this as well as your comment by defining another label whose name is more meaningful
to our use:


+SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
        nop                             // If enabled, this will be replaced
                                        // "b ftrace_graph_caller"
#endif

Is this acceptable?

Thanks.

Madhavan


From madvenka at linux.microsoft.com  Thu Apr  1 18:44:53 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 12:44:53 -0500
Subject: [RFC PATCH v1 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <20210401152741.GK4758@sirena.org.uk>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-2-madvenka@linux.microsoft.com>
 <20210401152741.GK4758@sirena.org.uk>
Message-ID: <ecdca67a-223f-40de-ebfa-89183e15a2a8@linux.microsoft.com>



On 4/1/21 10:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:52PM -0500, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>
>> Implement a check_reliability() function that will contain checks for the
>> presence of various features and conditions that can render the stack trace
>> unreliable.
> 
> This looks good to me with one minor stylistic thing:
> 
>> +/*
>> + * Special functions where the stack trace is unreliable.
>> + */
>> +static struct function_range	special_functions[] = {
>> +	{ 0, 0 }
>> +};
> 
> Might be good to put a comment here saying that this is terminating the
> list rather than detecting a NULL function pointer:
> 
> 	{ /* sentinel */ }
> 
> is a common idiom for that.
> 
> Given that it's a fixed array we could also...
> 
>> +	for (func = special_functions; func->start; func++) {
>> +		if (pc >= func->start && pc < func->end)
> 
> ...do these as
> 
> 	for (i = 0; i < ARRAY_SIZE(special_functions); i++) 
> 
> so you don't need something like that, though that gets awkward when you
> have to write out special_functions[i].field a lot.
> 
> So many different potential colours for the bikeshed!
I will make the above changes.

Thanks!

Madhavan


From syednwaris at gmail.com  Thu Apr  1 18:47:14 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 1 Apr 2021 23:17:14 +0530
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <YGHxNFXAjcg4PfnE@smile.fi.intel.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <YGHxNFXAjcg4PfnE@smile.fi.intel.com>
Message-ID: <CACG_h5pOJKUQd6h+75_Tiv_VVaUn9Dg9O5UBvQBu_2QWE0E9iw@mail.gmail.com>

On Mon, Mar 29, 2021 at 8:54 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> On Sat, Mar 06, 2021 at 07:36:30PM +0530, Syed Nayyar Waris wrote:
> > This patch reimplements the xgpio_set_multiple() function in
> > drivers/gpio/gpio-xilinx.c to use the new generic functions:
> > bitmap_get_value() and bitmap_set_value(). The code is now simpler
> > to read and understand. Moreover, instead of looping for each bit
> > in xgpio_set_multiple() function, now we can check each channel at
> > a time and save cycles.
>
> ...
>
> > +     u32 *const state = chip->gpio_state;
>
> Looking at this... What's the point of the const here?
>
> Am I right that this tells: pointer is a const, while the data underneath
> can be modified?
>
> > +     unsigned int *const width = chip->gpio_width;
>
> Ditto.
>
> Putting const:s here and there for sake of the const is not good practice.
> It makes code harder to read.
>
> --
> With Best Regards,
> Andy Shevchenko
>
Okay. I will incorporate your comments in my next submission. Thank You.

Regards
Syed Nayyar Waris


From madvenka at linux.microsoft.com  Thu Apr  1 18:48:59 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 12:48:59 -0500
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210401142759.GJ4758@sirena.org.uk>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
Message-ID: <fe69ec57-4798-3fcc-4e41-3d36957ee5f6@linux.microsoft.com>



On 4/1/21 9:27 AM, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 02:09:54PM -0500, madvenka at linux.microsoft.com wrote:
> 
>> +	 * FTRACE trampolines.
>> +	 */
>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>> +	{ (unsigned long) &ftrace_graph_call, 0 },
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> +	{ (unsigned long) ftrace_graph_caller, 0 },
>> +	{ (unsigned long) return_to_handler, 0 },
>> +#endif
>> +#endif
> 
> It's weird that we take the address of ftrace_graph_call but not the
> other functions - we should be consistent or explain why.  It'd probably
> also look nicer to not nest the ifdefs, the dependencies in Kconfig will
> ensure we only get things when we should.
> 

Sorry. I forgot to respond to the nested ifdef comment. I will fix that.

Thanks!

Madhavan


From nicolas.ferre at microchip.com  Thu Apr  1 18:45:44 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Thu, 1 Apr 2021 19:45:44 +0200
Subject: [GIT PULL] ARM: at91: soc for 5.13
Message-ID: <20210401174544.32193-1-nicolas.ferre@microchip.com>

From: Nicolas Ferre <nicolas.ferre at microchip.com>

Arnd, Olof,

One single patch for now on our SoC branch. Stakeholders agreed to make it
travel with at91 -> arm-soc.

Thanks, best regards,
  Nicolas

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-soc-5.13

for you to fetch changes up to 41dbf4a146a06443d1cbf39e238f02fa1ca9d626:

  ARM: at91: pm: Move prototypes to mutually included header (2021-03-26 18:20:49 +0100)

----------------------------------------------------------------
AT91 soc for 5.13:

- Fixing a W=1 warning

----------------------------------------------------------------
Lee Jones (1):
      ARM: at91: pm: Move prototypes to mutually included header

 arch/arm/mach-at91/pm.c        | 19 ++++++++-----------
 drivers/pinctrl/pinctrl-at91.c |  2 ++
 include/soc/at91/pm.h          | 16 ++++++++++++++++
 3 files changed, 26 insertions(+), 11 deletions(-)
 create mode 100644 include/soc/at91/pm.h

-- 
Nicolas Ferre


From syednwaris at gmail.com  Thu Apr  1 18:50:19 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 1 Apr 2021 23:20:19 +0530
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <CAHp75VektkxSH7S3qTkYd1De613HGrBDvXn36FFex_p1n9BDng@mail.gmail.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <CAHp75VfJ5bGaPkai_adsBoT6=7nS2K8ze0ka3gzZkQARkM5evA@mail.gmail.com>
 <CACG_h5pb0pA+cTNPGircAM3UrV5BGmqgk45LF_9phU_J4FaRyw@mail.gmail.com>
 <CAHp75VfDZbJjCOEGdHc=-D6W8_7m2=CinXj-itwn6hvoVqdWYQ@mail.gmail.com>
 <YF8evJTkiBYjnDON@shinobu>
 <CAHp75VektkxSH7S3qTkYd1De613HGrBDvXn36FFex_p1n9BDng@mail.gmail.com>
Message-ID: <CACG_h5pox5CCmhy7+itc7cpjCSYtzSXGA85ow14nPrAThyNTDA@mail.gmail.com>

On Sat, Mar 27, 2021 at 10:05 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
>
> On Sat, Mar 27, 2021 at 2:02 PM William Breathitt Gray
> <vilhelm.gray at gmail.com> wrote:
> > On Sat, Mar 27, 2021 at 09:29:26AM +0200, Andy Shevchenko wrote:
> > > On Saturday, March 27, 2021, Syed Nayyar Waris <syednwaris at gmail.com> wrote:
> > > > On Fri, Mar 26, 2021 at 11:32 PM Andy Shevchenko
> > > > <andy.shevchenko at gmail.com> wrote:
> > > > > On Sat, Mar 6, 2021 at 4:08 PM Syed Nayyar Waris <syednwaris at gmail.com>
> > > > wrote:
> > > > >
> > > > > > +       bitmap_set_value(old, 64, state[0], 32, 0);
> > > > > > +       bitmap_set_value(old, 64, state[1], 32, 32);
> > > > >
> > > > > Isn't it effectively bitnap_from_arr32() ?
> > > > >
> > > > > > +       bitmap_set_value(new, 64, state[0], 32, 0);
> > > > > > +       bitmap_set_value(new, 64, state[1], 32, 32);
> > > > >
> > > > > Ditto.
>
> > > > With bitmap_set_value() we are also specifying the offset (or start)
> > > > position too. so that the remainder of the array remains unaffected. I
> > > > think it would not be feasible to use bitmap_from/to_arr32()  here.
> > >
> > >
> > > You have hard coded start and nbits parameters to 32. How is it not the
> > > same?
> >
> > Would these four lines become something like this:
> >
> >         bitmap_from_arr32(old, state, 64);
> >         ...
> >         bitmap_from_arr32(new, state, 64);
>
> This is my understanding, but I might miss something. I mean driver
> specifics that make my proposal incorrect.
>
> --
> With Best Regards,
> Andy Shevchenko

I initially (incorrectly) thought that all of the bitmap_set_value()
statements have to be replaced. But now I realised, only those
specific bitmap_set_value() calls containing 32 bits width have to
replaced.

I will incorporate the above review comments in my next v4 submission.

Regards
Syed Nayyar Waris


From cristian.ciocaltea at gmail.com  Thu Apr  1 18:57:02 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Thu, 1 Apr 2021 20:57:02 +0300
Subject: [PATCH v2 2/6] dt-bindings: soc: actions: Add Actions Semi Owl
 socinfo binding
In-Reply-To: <20210401170818.GB610119@robh.at.kernel.org>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401170818.GB610119@robh.at.kernel.org>
Message-ID: <20210401175702.GB2016477@BV030612LT>

On Thu, Apr 01, 2021 at 12:08:18PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 04:48:17PM +0300, Cristian Ciocaltea wrote:
> > Add devicetree binding for the Actions Semi Owl socinfo driver.
> > 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > ---
> >  .../bindings/soc/actions/owl-socinfo.yaml     | 57 +++++++++++++++++++
> >  1 file changed, 57 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > new file mode 100644
> > index 000000000000..01e4a8b4f5ac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > @@ -0,0 +1,57 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/actions/owl-socinfo.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Actions Semi Owl SoC info module
> > +
> > +maintainers:
> > +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > +
> > +description: |
> > +  Actions Semi Owl SoC info module provides access to various information
> > +  about the S500, S700 and S900 SoC variants, such as serial number or id.
> > +
> > +select:
> > +  properties:
> > +    compatible:
> > +      contains:
> > +        enum:
> > +          - actions,s500-soc
> > +          - actions,s700-soc
> > +          - actions,s900-soc
> > +  required:
> > +    - compatible
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - actions,s500-soc
> > +          - actions,s700-soc
> > +          - actions,s900-soc
> > +      - const: simple-bus
> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > +  - |
> > +    / {
> > +        compatible = "roseapplepi,roseapplepi", "actions,s500";
> > +        model = "Roseapple Pi";
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +
> > +        soc {
> > +            compatible = "actions,s500-soc", "simple-bus";
> 
> What's the actual h/w for this bus? Still looks like abuse of DT to 
> create your virtual soc_info driver.

Right, there is no bus involved in accessing soc info, but I assumed
the already existing soc node in common DTS is a good candidate for
binding the driver. (e.g. arch/arm/boot/dts/owl-s500.dtsi)

Should I, instead, create a dedicated sub-node?

Thanks,
Cristi

> 
> > +            #address-cells = <1>;
> > +            #size-cells = <1>;
> > +            ranges;
> > +        };
> > +    };
> > +
> > +...
> > -- 
> > 2.31.1
> > 


From andy.shevchenko at gmail.com  Thu Apr  1 19:05:58 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 1 Apr 2021 21:05:58 +0300
Subject: [PATCH] iio: adc: stm32-dfsdm: drop __func__ while using Dynamic
 debug
In-Reply-To: <20210401154343.41527-1-dmugil2000@gmail.com>
References: <20210401154343.41527-1-dmugil2000@gmail.com>
Message-ID: <CAHp75VfkCQpfUrVcWHUnD4DLMp9iZJBL8mYfsYOCsESm_y068A@mail.gmail.com>

On Thu, Apr 1, 2021 at 8:48 PM Mugilraj Dhavachelvan
<dmugil2000 at gmail.com> wrote:
>
> dropped __func__ while using dev_dbg() and pr_debug()

The commit message may be amended, from code perspective LGTM!
Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>

> Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com>
> ---
>  drivers/iio/adc/stm32-dfsdm-adc.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> index 76a60d93fe23..95ec5f3c3126 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -198,7 +198,7 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
>         unsigned int p = fl->ford;      /* filter order (ford) */
>         struct stm32_dfsdm_filter_osr *flo = &fl->flo[fast];
>
> -       pr_debug("%s: Requested oversampling: %d\n",  __func__, oversamp);
> +       pr_debug("Requested oversampling: %d\n", oversamp);
>         /*
>          * This function tries to compute filter oversampling and integrator
>          * oversampling, base on oversampling ratio requested by user.
> @@ -294,8 +294,8 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
>                                 }
>                                 flo->max = (s32)max;
>
> -                               pr_debug("%s: fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
> -                                        __func__, fast, flo->fosr, flo->iosr,
> +                               pr_debug("fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
> +                                        fast, flo->fosr, flo->iosr,
>                                          flo->res, bits, flo->rshift,
>                                          flo->lshift);
>                         }
> @@ -858,7 +858,7 @@ static void stm32_dfsdm_dma_buffer_done(void *data)
>          * support in IIO.
>          */
>
> -       dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
> +       dev_dbg(&indio_dev->dev, "pos = %d, available = %d\n",
>                 adc->bufi, available);
>         old_pos = adc->bufi;
>
> @@ -912,7 +912,7 @@ static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
>         if (!adc->dma_chan)
>                 return -EINVAL;
>
> -       dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
> +       dev_dbg(&indio_dev->dev, "size=%d watermark=%d\n",
>                 adc->buf_sz, adc->buf_sz / 2);
>
>         if (adc->nconv == 1 && !indio_dev->trig)
> --
> 2.25.1
>


-- 
With Best Regards,
Andy Shevchenko


From broonie at kernel.org  Thu Apr  1 19:09:38 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 19:09:38 +0100
Subject: [PATCH v2 0/4] arm64: Booting clarifications and fine grained traps
 setup
Message-ID: <20210401180942.35815-1-broonie@kernel.org>

Currently there are a number of areas where we are not explicit about
how system registers should be configured when booting the kernel,
provide more detailed guidance to help ensure people get things right.
I'm not entirely happy with the wording on use of specified reset values
so it is a separate patch at the end, I worry that the requirement is
too strict.

This was triggered by noticing that it was in spec to leave fine grained
traps to EL2 enabled so explicitly disable them at boot, this is sent as
part of the same series since doing so means we require that EL3 provide
access to fine grained traps in the same document.

v2:
 - Pull booting and FGT setup into a single series.
 - Require system registers at or below the level the kernel is entered
   to be initialised, not just those at that level.
 - Rather than documenting the desired EL2 setup for FGT add a general
   statement about how we expect registers to be set up.
 - Reorder register initialisation in el2_setup.h.
 - Document requirement for SCR_EL3.FGTEn to be 1.

Mark Brown (4):
  arm64: Document requirements for fine grained traps at boot
  arm64: Disable fine grained traps on boot
  arm64: Require that system registers at all visible ELs be initialized
  arm64: Document values for system registers on boot

 Documentation/arm64/booting.rst    | 15 ++++++++++++---
 arch/arm64/include/asm/el2_setup.h | 21 +++++++++++++++++++++
 arch/arm64/include/asm/sysreg.h    |  6 ++++++
 3 files changed, 39 insertions(+), 3 deletions(-)


base-commit: 1e28eed17697bcf343c6743f0028cc3b5dd88bf0
-- 
2.20.1



From broonie at kernel.org  Thu Apr  1 19:09:39 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 19:09:39 +0100
Subject: [PATCH v2 1/4] arm64: Document requirements for fine grained traps at
 boot
In-Reply-To: <20210401180942.35815-1-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
Message-ID: <20210401180942.35815-2-broonie@kernel.org>

The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
to small sets of registers and instructions from EL1 and EL0, access to
which is controlled by EL3.  Require access to it so that it is
available to us in future and so that we can ensure these traps are
disabled during boot.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 7552dbc1cc54..92ec0bea1af5 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -270,6 +270,12 @@ Before jumping into the kernel, the following conditions must be met:
       having 0b1 set for the corresponding bit for each of the auxiliary
       counters present.
 
+  For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
+
+  - If EL3 is present and the kernel is entered at EL2:
+
+    - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
+
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.
-- 
2.20.1



From broonie at kernel.org  Thu Apr  1 19:09:40 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 19:09:40 +0100
Subject: [PATCH v2 2/4] arm64: Disable fine grained traps on boot
In-Reply-To: <20210401180942.35815-1-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
Message-ID: <20210401180942.35815-3-broonie@kernel.org>

The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
to small sets of registers and instructions from EL1 and EL0.  Currently
Linux makes no use of this feature, ensure that it is not active at boot by
disabling the traps during EL2 setup.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/include/asm/el2_setup.h | 21 +++++++++++++++++++++
 arch/arm64/include/asm/sysreg.h    |  6 ++++++
 2 files changed, 27 insertions(+)

diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index d77d358f9395..b3f2d3bb0938 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -131,6 +131,26 @@
 .Lskip_sve_\@:
 .endm
 
+/* Disable any fine grained traps */
+.macro __init_el2_fgt
+	mrs	x1, id_aa64mmfr0_el1
+	ubfx	x1, x1, #ID_AA64MMFR0_FGT_SHIFT, #4
+	cbz	x1, .Lskip_fgt_\@
+
+	msr_s	SYS_HDFGRTR_EL2, xzr
+	msr_s	SYS_HDFGWTR_EL2, xzr
+	msr_s	SYS_HFGRTR_EL2, xzr
+	msr_s	SYS_HFGWTR_EL2, xzr
+	msr_s	SYS_HFGITR_EL2, xzr
+
+	mrs	x1, id_aa64pfr0_el1		// AMU traps UNDEF without AMU
+	ubfx	x1, x1, #ID_AA64PFR0_AMU_SHIFT, #4
+	cbz	x1, .Lskip_fgt_\@
+
+	msr_s	SYS_HAFGRTR_EL2, xzr
+.Lskip_fgt_\@:
+.endm
+
 .macro __init_el2_nvhe_prepare_eret
 	mov	x0, #INIT_PSTATE_EL1
 	msr	spsr_el2, x0
@@ -155,6 +175,7 @@
 	__init_el2_nvhe_idregs
 	__init_el2_nvhe_cptr
 	__init_el2_nvhe_sve
+	__init_el2_fgt
 	__init_el2_nvhe_prepare_eret
 .endm
 
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..b35468927363 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -475,9 +475,15 @@
 #define SYS_PMCCFILTR_EL0		sys_reg(3, 3, 14, 15, 7)
 
 #define SYS_SCTLR_EL2			sys_reg(3, 4, 1, 0, 0)
+#define SYS_HFGRTR_EL2			sys_reg(3, 4, 1, 1, 4)
+#define SYS_HFGWTR_EL2			sys_reg(3, 4, 1, 1, 5)
+#define SYS_HFGITR_EL2			sys_reg(3, 4, 1, 1, 6)
 #define SYS_ZCR_EL2			sys_reg(3, 4, 1, 2, 0)
 #define SYS_TRFCR_EL2			sys_reg(3, 4, 1, 2, 1)
 #define SYS_DACR32_EL2			sys_reg(3, 4, 3, 0, 0)
+#define SYS_HDFGRTR_EL2			sys_reg(3, 4, 3, 1, 4)
+#define SYS_HDFGWTR_EL2			sys_reg(3, 4, 3, 1, 5)
+#define SYS_HAFGRTR_EL2			sys_reg(3, 4, 3, 1, 6)
 #define SYS_SPSR_EL2			sys_reg(3, 4, 4, 0, 0)
 #define SYS_ELR_EL2			sys_reg(3, 4, 4, 0, 1)
 #define SYS_IFSR32_EL2			sys_reg(3, 4, 5, 0, 1)
-- 
2.20.1



From broonie at kernel.org  Thu Apr  1 19:09:41 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 19:09:41 +0100
Subject: [PATCH v2 3/4] arm64: Require that system registers at all visible
 ELs be initialized
In-Reply-To: <20210401180942.35815-1-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
Message-ID: <20210401180942.35815-4-broonie@kernel.org>

Currently we require that software at a higher exception level initialise
all registers at the exception level the kernel will be entered prior to
starting the kernel in order to ensure that there is nothing uninitialised
which could result in an UNKNOWN state while running the kernel. The
expectation is that the software running at the highest exception levels
will be tightly coupled to the system and can ensure that all available
features are appropriately initialised and that the kernel can initialise
anything else.

There is a gap here in the case where new registers are added to lower
exception levels that require initialisation but the kernel does not yet
understand them. Extend the requirement to also include exception levels
below the one where the kernel is entered to cover this.

Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 92ec0bea1af5..4fcc00add117 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -202,9 +202,10 @@ Before jumping into the kernel, the following conditions must be met:
 
 - System registers
 
-  All writable architected system registers at the exception level where
-  the kernel image will be entered must be initialised by software at a
-  higher exception level to prevent execution in an UNKNOWN state.
+  All writable architected system registers at or below the exception
+  level where the kernel image will be entered must be initialised by
+  software at a higher exception level to prevent execution in an UNKNOWN
+  state.
 
   - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
     executing on.
-- 
2.20.1



From broonie at kernel.org  Thu Apr  1 19:09:42 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  1 Apr 2021 19:09:42 +0100
Subject: [PATCH v2 4/4] arm64: Document values for system registers on boot
In-Reply-To: <20210401180942.35815-1-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
Message-ID: <20210401180942.35815-5-broonie@kernel.org>

When booting require that the system registers available at or below the
exception level the kernel is entered be initialised but do not specify
what values should be used in the general case, creating some potential
for issues if the kernel does not subsequently configure those registers
explicitly (for example if they are not yet used by the kernel) or where
their effects may create issues during early configuration.

Specify that where the architecture provides a reset value that value
must be used.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 4fcc00add117..d49f568eb79d 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -205,7 +205,9 @@ Before jumping into the kernel, the following conditions must be met:
   All writable architected system registers at or below the exception
   level where the kernel image will be entered must be initialised by
   software at a higher exception level to prevent execution in an UNKNOWN
-  state.
+  state.  Where these architected system registers have reset values
+  specified by the architecture they must be initialised to those values
+  unless specified more specifically.
 
   - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
     executing on.
-- 
2.20.1



From zweiss at equinix.com  Thu Apr  1 19:18:09 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Thu, 1 Apr 2021 18:18:09 +0000
Subject: Re [PATCH v2 21/21] ipmi: kcs_bmc_aspeed: Optionally apply status
 address
In-Reply-To: <20210319062752.145730-21-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-21-andrew@aj.id.au>
Message-ID: <YGYOX4HcdKcWOUx1@packtop>

On Fri, Mar 19, 2021 at 01:27:52AM CDT, Andrew Jeffery wrote:
>Some Aspeed KCS devices can derive the status register address from the
>address of the data register. As such, the address of the status
>register can be implicit in the configuration if desired. On the other
>hand, sometimes address schemes might be requested that are incompatible
>with the default addressing scheme. Allow these requests where possible
>if the devicetree specifies the status register address.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc_aspeed.c | 113 +++++++++++++++++++++--------
> 1 file changed, 81 insertions(+), 32 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 7334b1f51dcc..98789b837690 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -83,6 +83,8 @@
> #define LPC_STR2             0x040
> #define LPC_STR3             0x044
> #define LPC_HICRB            0x100
>+#define     LPC_HICRB_EN16LADR2      BIT(5)
>+#define     LPC_HICRB_EN16LADR1      BIT(4)
> #define     LPC_HICRB_IBFIE4         BIT(1)
> #define     LPC_HICRB_LPC4E          BIT(0)
> #define LPC_HICRC            0x104
>@@ -96,6 +98,11 @@
> #define LPC_IDR4             0x114
> #define LPC_ODR4             0x118
> #define LPC_STR4             0x11C
>+#define LPC_LSADR12	     0x120
>+#define     LPC_LSADR12_LSADR2_MASK  GENMASK(31, 16)
>+#define     LPC_LSADR12_LSADR2_SHIFT 16
>+#define     LPC_LSADR12_LSADR1_MASK  GENMASK(15, 0)
>+#define     LPC_LSADR12_LSADR1_SHIFT 0
>
> #define OBE_POLL_PERIOD	     (HZ / 2)
>
>@@ -123,7 +130,7 @@ struct aspeed_kcs_bmc {
>
> struct aspeed_kcs_of_ops {
> 	int (*get_channel)(struct platform_device *pdev);
>-	int (*get_io_address)(struct platform_device *pdev);
>+	int (*get_io_address)(struct platform_device *pdev, u32 addrs[2]);
> };
>
> static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc_device *kcs_bmc)
>@@ -217,38 +224,64 @@ static void aspeed_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask,
>  *     C. KCS4
>  *        D / C : CA4h / CA5h
>  */
>-static void aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u16 addr)
>+static int aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u32 addrs[2], int nr_addrs)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>
>-	switch (kcs_bmc->channel) {
>+	if (WARN_ON(nr_addrs < 1 || nr_addrs > 2))
>+		return -EINVAL;
>+
>+	switch (priv->kcs_bmc.channel) {
> 	case 1:
>-		regmap_update_bits(priv->map, LPC_HICR4,
>-				LPC_HICR4_LADR12AS, 0);
>-		regmap_write(priv->map, LPC_LADR12H, addr >> 8);
>-		regmap_write(priv->map, LPC_LADR12L, addr & 0xFF);
>+		regmap_update_bits(priv->map, LPC_HICR4, LPC_HICR4_LADR12AS, 0);
>+		regmap_write(priv->map, LPC_LADR12H, addrs[0] >> 8);
>+		regmap_write(priv->map, LPC_LADR12L, addrs[0] & 0xFF);
>+		if (nr_addrs == 2) {
>+			regmap_update_bits(priv->map, LPC_LSADR12, LPC_LSADR12_LSADR1_MASK,
>+					   addrs[1] << LPC_LSADR12_LSADR1_SHIFT);
>+
>+			regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_EN16LADR1,
>+					   LPC_HICRB_EN16LADR1);
>+		}
> 		break;
>
> 	case 2:
>-		regmap_update_bits(priv->map, LPC_HICR4,
>-				LPC_HICR4_LADR12AS, LPC_HICR4_LADR12AS);
>-		regmap_write(priv->map, LPC_LADR12H, addr >> 8);
>-		regmap_write(priv->map, LPC_LADR12L, addr & 0xFF);
>+		regmap_update_bits(priv->map, LPC_HICR4, LPC_HICR4_LADR12AS, LPC_HICR4_LADR12AS);
>+		regmap_write(priv->map, LPC_LADR12H, addrs[0] >> 8);
>+		regmap_write(priv->map, LPC_LADR12L, addrs[0] & 0xFF);
>+		if (nr_addrs == 2) {
>+			regmap_update_bits(priv->map, LPC_LSADR12, LPC_LSADR12_LSADR2_MASK,
>+					   addrs[1] << LPC_LSADR12_LSADR2_SHIFT);
>+
>+			regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_EN16LADR2,
>+					   LPC_HICRB_EN16LADR2);
>+		}
> 		break;
>
> 	case 3:
>-		regmap_write(priv->map, LPC_LADR3H, addr >> 8);
>-		regmap_write(priv->map, LPC_LADR3L, addr & 0xFF);
>+		if (nr_addrs == 2) {
>+			dev_err(priv->kcs_bmc.dev,
>+				"Channel 3 only supports inferred status IO address\n");
>+			return -EINVAL;
>+		}
>+
>+		regmap_write(priv->map, LPC_LADR3H, addrs[0] >> 8);
>+		regmap_write(priv->map, LPC_LADR3L, addrs[0] & 0xFF);
> 		break;
>
> 	case 4:
>-		regmap_write(priv->map, LPC_LADR4, ((addr + 1) << 16) |
>-			addr);
>+		if (nr_addrs == 1)
>+			regmap_write(priv->map, LPC_LADR4, ((addrs[0] + 1) << 16) | addrs[0]);
>+		else
>+			regmap_write(priv->map, LPC_LADR4, (addrs[1] << 16) | addrs[0]);
>+
> 		break;
>
> 	default:
>-		break;
>+		return -EINVAL;
> 	}
>+
>+	return 0;
> }
>
> static inline int aspeed_kcs_map_serirq_type(u32 dt_type)
>@@ -462,18 +495,18 @@ static int aspeed_kcs_of_v1_get_channel(struct platform_device *pdev)
> 	return channel;
> }
>
>-static int aspeed_kcs_of_v1_get_io_address(struct platform_device *pdev)
>+static int
>+aspeed_kcs_of_v1_get_io_address(struct platform_device *pdev, u32 addrs[2])
> {
>-	u32 slave;
> 	int rc;
>
>-	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", &slave);
>-	if (rc || slave > 0xffff) {
>+	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", addrs);
>+	if (rc || addrs[0] > 0xffff) {
> 		dev_err(&pdev->dev, "no valid 'kcs_addr' configured\n");
> 		return -EINVAL;
> 	}
>
>-	return slave;
>+	return 1;
> }
>
> static int aspeed_kcs_of_v2_get_channel(struct platform_device *pdev)
>@@ -509,16 +542,27 @@ static int aspeed_kcs_of_v2_get_channel(struct platform_device *pdev)
> 	return -EINVAL;
> }
>
>-static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
>+static int
>+aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev, u32 addrs[2])
> {
>-	uint32_t slave;
> 	int rc;
>
>-	rc = of_property_read_u32(pdev->dev.of_node, "aspeed,lpc-io-reg", &slave);
>-	if (rc || slave > 0xffff)
>+	rc = of_property_read_variable_u32_array(pdev->dev.of_node,
>+						 "aspeed,lpc-io-reg",
>+						 addrs, 1, 2);
>+	if (rc < 0)
>+		return rc;
>+
>+	if (WARN_ON(rc == 0))
>+		return -EINVAL;

Is this check necessary?  It looks like
of_property_read_variable_u32_array() should fail in that case given
sz_min==1, so this seems like it should be impossible to trigger.

>+
>+	if (addrs[0] > 0xffff)
>+		return -EINVAL;
>+
>+	if (rc == 2 && addrs[1] > 0xffff)
> 		return -EINVAL;
>
>-	return slave;
>+	return rc;
> }
>
> static int aspeed_kcs_probe(struct platform_device *pdev)
>@@ -527,9 +571,11 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	struct kcs_bmc_device *kcs_bmc;
> 	struct aspeed_kcs_bmc *priv;
> 	struct device_node *np;
>-	int rc, channel, addr;
> 	bool have_upstream_irq;
> 	u32 upstream_irq[2];
>+	int rc, channel;
>+	int nr_addrs;
>+	u32 addrs[2];
>
> 	np = pdev->dev.of_node->parent;
> 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
>@@ -547,9 +593,9 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	if (channel < 0)
> 		return channel;
>
>-	addr = ops->get_io_address(pdev);
>-	if (addr < 0)
>-		return addr;
>+	nr_addrs = ops->get_io_address(pdev, addrs);
>+	if (nr_addrs < 0)
>+		return nr_addrs;
>
> 	np = pdev->dev.of_node;
> 	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", upstream_irq, 2);
>@@ -578,7 +624,9 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	priv->obe.remove = false;
> 	timer_setup(&priv->obe.timer, aspeed_kcs_check_obe, 0);
>
>-	aspeed_kcs_set_address(kcs_bmc, addr);
>+	rc = aspeed_kcs_set_address(kcs_bmc, addrs, nr_addrs);
>+	if (rc)
>+		return rc;
>
> 	/* Host to BMC IRQ */
> 	rc = aspeed_kcs_config_downstream_irq(kcs_bmc, pdev);
>@@ -600,7 +648,8 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	if (rc < 0)
> 		return rc;
>
>-	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n", kcs_bmc->channel, addr);
>+	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n",
>+			kcs_bmc->channel, addrs[0]);
>
> 	return 0;
> }
>-- 
>2.27.0
>

From broonie at kernel.org  Thu Apr  1 19:28:11 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 1 Apr 2021 19:28:11 +0100
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
 <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
Message-ID: <20210401182810.GO4758@sirena.org.uk>

On Thu, Apr 01, 2021 at 12:43:25PM -0500, Madhavan T. Venkataraman wrote:

> >> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> >> +	{ (unsigned long) &ftrace_graph_call, 0 },
> >> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> >> +	{ (unsigned long) ftrace_graph_caller, 0 },

> > It's weird that we take the address of ftrace_graph_call but not the
> > other functions - we should be consistent or explain why.  It'd probably
> > also look nicer to not nest the ifdefs, the dependencies in Kconfig will
> > ensure we only get things when we should.

> I have explained it in the comment in the FTRACE trampoline right above
> ftrace_graph_call().

Ah, right - it's a result of it being an inner label.  I'd suggest
putting a brief note right at that line of code explaining this (eg,
"Inner label, not a function"), it wasn't confusing due to the use of
that symbol but rather due to it being different from everything else
in the list and that's kind of lost in the main comment.

> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
> this as well as your comment by defining another label whose name is more meaningful
> to our use:

> +SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
>         nop                             // If enabled, this will be replaced
>                                         // "b ftrace_graph_caller"
> #endif

I'm not sure we need to bother with that, you'd still need the & I think.
-------------- 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/20210401/b9bac590/attachment.sig>

From madvenka at linux.microsoft.com  Thu Apr  1 19:40:23 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 13:40:23 -0500
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210401182810.GO4758@sirena.org.uk>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
 <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
 <20210401182810.GO4758@sirena.org.uk>
Message-ID: <2a56fe4b-9929-0d8b-aa49-c2b1c1b82b79@linux.microsoft.com>



On 4/1/21 1:28 PM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 12:43:25PM -0500, Madhavan T. Venkataraman wrote:
> 
>>>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
>>>> +	{ (unsigned long) &ftrace_graph_call, 0 },
>>>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>>> +	{ (unsigned long) ftrace_graph_caller, 0 },
> 
>>> It's weird that we take the address of ftrace_graph_call but not the
>>> other functions - we should be consistent or explain why.  It'd probably
>>> also look nicer to not nest the ifdefs, the dependencies in Kconfig will
>>> ensure we only get things when we should.
> 
>> I have explained it in the comment in the FTRACE trampoline right above
>> ftrace_graph_call().
> 
> Ah, right - it's a result of it being an inner label.  I'd suggest
> putting a brief note right at that line of code explaining this (eg,
> "Inner label, not a function"), it wasn't confusing due to the use of
> that symbol but rather due to it being different from everything else
> in the list and that's kind of lost in the main comment.
> 

OK, So, I will add a note in the main comment above the list. I will add the
comment line you have suggested at the exact line.

>> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
>> this as well as your comment by defining another label whose name is more meaningful
>> to our use:
> 
>> +SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
>> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
>>         nop                             // If enabled, this will be replaced
>>                                         // "b ftrace_graph_caller"
>> #endif
> 
> I'm not sure we need to bother with that, you'd still need the & I think.

I think we need to bother with that. If CONFIG_FUNCTION_GRAPH_TRACER is not on but
CONFIG_DYNAMIC_FTRACE_WITH_REGS is, then ftrace_graph_call() will not occur in the stack
trace taken from a tracer function. The unwinder still needs to recognize an ftrace frame.
I don't want to assume ftrace_common_return which is the label that currently follows
the above code. So, we need a different label outside the above ifdef.

As for the &, I needed it because ftrace_graph_call is currently defined elsewhere as:

extern unsigned long ftrace_graph_call;

I did not want to change that.

Thanks,

Madhavan



From lkp at intel.com  Thu Apr  1 19:42:10 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 02:42:10 +0800
Subject: [xlnx:xlnx_rebase_v5.4 906/1701] trace.c:(.text+0x1c30): multiple
 definition of `dwc3_simple_check_quirks';
 drivers/usb/dwc3/core.o:core.c:(.text+0x8b0): first defined here
Message-ID: <202104020202.XYCLZ6Vt-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 782658c51bbcd85a39a5d9a51b57224f185d7670 [906/1701] usb: dwc3: Correct errors when dwc3 loaded as module
config: i386-randconfig-c021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/782658c51bbcd85a39a5d9a51b57224f185d7670
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 782658c51bbcd85a39a5d9a51b57224f185d7670
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1429:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1429 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1431:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1431 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.h:1433:6: warning: no previous prototype for 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
    1433 | void dwc3_simple_check_quirks(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
--
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_wakeup_capable':
   trace.c:(.text+0x1c10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x890): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_simple_data':
   trace.c:(.text+0x1c20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x8a0): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_check_quirks':
>> trace.c:(.text+0x1c30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x8b0): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_wakeup_capable':
   host.c:(.text+0x10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x890): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_simple_data':
   host.c:(.text+0x20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x8a0): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_check_quirks':
   host.c:(.text+0x30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x8b0): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_wakeup_capable':
   ulpi.c:(.text+0xa80): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x890): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_simple_data':
   ulpi.c:(.text+0xa90): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x8a0): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_check_quirks':
   ulpi.c:(.text+0xaa0): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x8b0): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_wakeup_capable':
   debugfs.c:(.text+0xa10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x890): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_simple_data':
   debugfs.c:(.text+0xa20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x8a0): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_check_quirks':
   debugfs.c:(.text+0xa30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x8b0): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/76756908/attachment-0001.gz>

From madvenka at linux.microsoft.com  Thu Apr  1 19:53:12 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 13:53:12 -0500
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <2a56fe4b-9929-0d8b-aa49-c2b1c1b82b79@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
 <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
 <20210401182810.GO4758@sirena.org.uk>
 <2a56fe4b-9929-0d8b-aa49-c2b1c1b82b79@linux.microsoft.com>
Message-ID: <fe2f3b1e-8cb6-05ce-7968-216fed079fe4@linux.microsoft.com>



On 4/1/21 1:40 PM, Madhavan T. Venkataraman wrote:
>>> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
>>> this as well as your comment by defining another label whose name is more meaningful
>>> to our use:
>>> +SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
>>> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>> SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
>>>         nop                             // If enabled, this will be replaced
>>>                                         // "b ftrace_graph_caller"
>>> #endif
>> I'm not sure we need to bother with that, you'd still need the & I think.
> I think we need to bother with that. If CONFIG_FUNCTION_GRAPH_TRACER is not on but
> CONFIG_DYNAMIC_FTRACE_WITH_REGS is, then ftrace_graph_call() will not occur in the stack
> trace taken from a tracer function. The unwinder still needs to recognize an ftrace frame.
> I don't want to assume ftrace_common_return which is the label that currently follows
> the above code. So, we need a different label outside the above ifdef.

Alternatively, I could just move the SYM_INNER_LABEL(ftrace_graph_call..) to outside the ifdef.

Madhavan


From ndesaulniers at google.com  Thu Apr  1 19:55:49 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Thu, 1 Apr 2021 11:55:49 -0700
Subject: [PATCH] ARM: OMAP1: ams-delta: remove unused function
 ams_delta_camera_power
In-Reply-To: <20210401160434.7655-1-maciej.falkowski9@gmail.com>
References: <20210401160434.7655-1-maciej.falkowski9@gmail.com>
Message-ID: <CAKwvOdmSCz7awnjuDWKSd8n+x1E2ziN9F4xLOX0RG5F1yYOFQg@mail.gmail.com>

On Thu, Apr 1, 2021 at 9:05 AM Maciej Falkowski
<maciej.falkowski9 at gmail.com> wrote:
>
> The ams_delta_camera_power() function is unused as reports
> Clang compilation with omap1_defconfig on linux-next:
>
> arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: unused function 'ams_delta_camera_power' [-Wunused-function]
> static int ams_delta_camera_power(struct device *dev, int power)
>            ^
> 1 warning generated.
>
> The soc_camera support was dropped without removing
> ams_delta_camera_power() function, making it unused.
>
> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>

Thanks for the patch!
Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>

> Fixes: ce548396a433 ("media: mach-omap1: board-ams-delta.c: remove soc_camera dependencies")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1326
> ---
>  arch/arm/mach-omap1/board-ams-delta.c | 14 --------------
>  1 file changed, 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 2ee527c00284..1026a816dcc0 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -458,20 +458,6 @@ static struct gpiod_lookup_table leds_gpio_table = {
>
>  #ifdef CONFIG_LEDS_TRIGGERS
>  DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
> -
> -static int ams_delta_camera_power(struct device *dev, int power)
> -{
> -       /*
> -        * turn on camera LED
> -        */
> -       if (power)
> -               led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
> -       else
> -               led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
> -       return 0;
> -}
> -#else
> -#define ams_delta_camera_power NULL
>  #endif
>
>  static struct platform_device ams_delta_audio_device = {
> --
> 2.26.3
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210401160434.7655-1-maciej.falkowski9%40gmail.com.



-- 
Thanks,
~Nick Desaulniers


From ndesaulniers at google.com  Thu Apr  1 20:05:53 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Thu, 1 Apr 2021 12:05:53 -0700
Subject: [PATCH] ARM: OMAP: Fix use of possibly uninitialized irq variable
In-Reply-To: <20210401161127.8942-1-maciej.falkowski9@gmail.com>
References: <20210401161127.8942-1-maciej.falkowski9@gmail.com>
Message-ID: <CAKwvOdkCe1OkPetLzFTO+f-dp8=kD3OKX8mfEnw2GBRkU_cBnw@mail.gmail.com>

On Thu, Apr 1, 2021 at 9:12 AM Maciej Falkowski
<maciej.falkowski9 at gmail.com> wrote:
>
> The current control flow of IRQ number assignment to `irq` variable
> allows a request of IRQ of unspecified value,
> generating a warning under Clang compilation with omap1_defconfig on linux-next:
>
> arch/arm/mach-omap1/pm.c:656:11: warning: variable 'irq' is used uninitialized whenever
> 'if' condition is false [-Wsometimes-uninitialized]
>         else if (cpu_is_omap16xx())
>                  ^~~~~~~~~~~~~~~~~
> ./arch/arm/mach-omap1/include/mach/soc.h:123:30: note: expanded from macro 'cpu_is_omap16xx'
>                                         ^~~~~~~~~~~~~
> arch/arm/mach-omap1/pm.c:658:18: note: uninitialized use occurs here
>         if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
>                         ^~~
> arch/arm/mach-omap1/pm.c:656:7: note: remove the 'if' if its condition is always true
>         else if (cpu_is_omap16xx())
>              ^~~~~~~~~~~~~~~~~~~~~~
> arch/arm/mach-omap1/pm.c:611:9: note: initialize the variable 'irq' to silence this warning
>         int irq;
>                ^
>                 = 0
> 1 warning generated.

Ooh, yeah if cpu_is_omap15xx() then irq is unused uninitialized; I
don't see any INT_1610_WAKE_UP_REQ-equlivalent for
INT_15XX_WAKE_UP_REQ.

Ok, LGTM.

Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>

I agree with Nathan on the Fixes tag.

>
> The patch provides a default value to the `irq` variable
> along with a validity check.
>
> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1324
> ---
>  arch/arm/mach-omap1/pm.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
> index 2c1e2b32b9b3..a745d64d4699 100644
> --- a/arch/arm/mach-omap1/pm.c
> +++ b/arch/arm/mach-omap1/pm.c
> @@ -655,9 +655,13 @@ static int __init omap_pm_init(void)
>                 irq = INT_7XX_WAKE_UP_REQ;
>         else if (cpu_is_omap16xx())
>                 irq = INT_1610_WAKE_UP_REQ;
> -       if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup",
> -                       NULL))
> -               pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
> +       else
> +               irq = -1;
> +
> +       if (irq >= 0) {
> +               if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", NULL))
> +                       pr_err("Failed to request irq %d (peripheral wakeup)\n", irq);
> +       }
>
>         /* Program new power ramp-up time
>          * (0 for most boards since we don't lower voltage when in deep sleep)
> --
-- 
Thanks,
~Nick Desaulniers


From f.fainelli at gmail.com  Thu Apr  1 20:11:26 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 1 Apr 2021 12:11:26 -0700
Subject: [PATCH] ARM: Qualify enabling of swiotlb_init()
In-Reply-To: <YGYD40RbKN9r8I8n@Konrads-MacBook-Pro.local>
References: <20210319040333.183827-1-f.fainelli@gmail.com>
 <20210319130731.GB2624@lst.de>
 <20210319195929.GA1346384@konrad-char-us-oracle-com.allregionaliads.osdevelopmeniad.oraclevcn.com>
 <alpine.DEB.2.21.2103191718210.439@sstabellini-ThinkPad-T480s>
 <3db926f4-6047-cc62-8654-a965b8570e75@gmail.com>
 <20210330053607.GA4863@lst.de> <YGYD40RbKN9r8I8n@Konrads-MacBook-Pro.local>
Message-ID: <c3811249-8e34-499f-e3f3-ed84319bcffa@gmail.com>

On 4/1/21 10:33 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote:
>> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
>>> Should I toss this in Russell's patch tracker or do you need me to make
>>> some changes to the patch?
>>
>> Due to all the other changes in this area I don't think anything but
>> the swiotlb tree makes much sense here.
> 
> I've put them all on 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
> devel/for-linus-5.13

Thanks! Did you also want to queue up this one:

https://lore.kernel.org/lkml/20210323015350.399493-1-f.fainelli at gmail.com/
-- 
Florian


From lkp at intel.com  Thu Apr  1 20:11:57 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 03:11:57 +0800
Subject: [arm-platforms:kvm-arm64/nvhe-panic-info 4/5]
 arch/arm64/kvm/hyp/vhe/switch.c:217:17: warning: no previous prototype for
 function 'hyp_panic'
Message-ID: <202104020351.KTVA9l7S-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nvhe-panic-info
head:   aec0fae62e47050019474936248a311a0ab08705
commit: f79e616f27ab6cd74deb0995a8eead3d1c9d65af [4/5] KVM: arm64: Use BUG and BUG_ON in nVHE hyp
config: arm64-randconfig-r033-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=f79e616f27ab6cd74deb0995a8eead3d1c9d65af
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms kvm-arm64/nvhe-panic-info
        git checkout f79e616f27ab6cd74deb0995a8eead3d1c9d65af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm64/kvm/hyp/vhe/switch.c:217:17: warning: no previous prototype for function 'hyp_panic' [-Wmissing-prototypes]
   void __noreturn hyp_panic(void)
                   ^
   arch/arm64/kvm/hyp/vhe/switch.c:217:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __noreturn hyp_panic(void)
   ^
   static 
   arch/arm64/kvm/hyp/vhe/switch.c:227:17: warning: no previous prototype for function 'kvm_unexpected_el2_exception' [-Wmissing-prototypes]
   asmlinkage void kvm_unexpected_el2_exception(void)
                   ^
   arch/arm64/kvm/hyp/vhe/switch.c:227:12: note: declare 'static' if the function is not intended to be used outside of this translation unit
   asmlinkage void kvm_unexpected_el2_exception(void)
              ^
              static 
   2 warnings generated.
--
>> arch/arm64/kvm/hyp/nvhe/switch.c:264:17: warning: no previous prototype for function 'hyp_panic' [-Wmissing-prototypes]
   void __noreturn hyp_panic(void)
                   ^
   arch/arm64/kvm/hyp/nvhe/switch.c:264:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __noreturn hyp_panic(void)
   ^
   static 
   arch/arm64/kvm/hyp/nvhe/switch.c:286:17: warning: no previous prototype for function 'kvm_unexpected_el2_exception' [-Wmissing-prototypes]
   asmlinkage void kvm_unexpected_el2_exception(void)
                   ^
   arch/arm64/kvm/hyp/nvhe/switch.c:286:12: note: declare 'static' if the function is not intended to be used outside of this translation unit
   asmlinkage void kvm_unexpected_el2_exception(void)
              ^
              static 
   2 warnings generated.


vim +/hyp_panic +217 arch/arm64/kvm/hyp/vhe/switch.c

09cf57eba30424 David Brazdil 2020-06-25  216  
6a0259ed29bba8 Andrew Scull  2020-09-15 @217  void __noreturn hyp_panic(void)
09cf57eba30424 David Brazdil 2020-06-25  218  {
09cf57eba30424 David Brazdil 2020-06-25  219  	u64 spsr = read_sysreg_el2(SYS_SPSR);
09cf57eba30424 David Brazdil 2020-06-25  220  	u64 elr = read_sysreg_el2(SYS_ELR);
96d389ca10110d Rob Herring   2020-10-28  221  	u64 par = read_sysreg_par();
09cf57eba30424 David Brazdil 2020-06-25  222  
6a0259ed29bba8 Andrew Scull  2020-09-15  223  	__hyp_call_panic(spsr, elr, par);
09cf57eba30424 David Brazdil 2020-06-25  224  	unreachable();
09cf57eba30424 David Brazdil 2020-06-25  225  }
e9ee186bb735bf James Morse   2020-08-21  226  

:::::: The code at line 217 was first introduced by commit
:::::: 6a0259ed29bba83653a36fabcdf6b06aecd78596 KVM: arm64: Remove hyp_panic arguments

:::::: TO: Andrew Scull <ascull at google.com>
:::::: CC: Marc Zyngier <maz at kernel.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 48009 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/18423e51/attachment-0001.gz>

From lkp at intel.com  Thu Apr  1 20:16:41 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 03:16:41 +0800
Subject: [xlnx:xlnx_rebase_v5.4 217/1701]
 drivers/media/i2c/adv7511-v4l2.c:427:2: error: void function
 'adv7511_set_rgb_quantization_mode' should not return a value
Message-ID: <202104020332.f8rNLsUi-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 9836a252284b997aacd6b86766514a0bb84b4f43 [217/1701] drivers: media: Customized adv7511 for Xylon LogiCVC (deprecated)
config: x86_64-randconfig-a004-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/9836a252284b997aacd6b86766514a0bb84b4f43
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 9836a252284b997aacd6b86766514a0bb84b4f43
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

>> drivers/media/i2c/adv7511-v4l2.c:427:2: error: void function 'adv7511_set_rgb_quantization_mode' should not return a value [-Wreturn-type]
           return 0;
           ^      ~
>> drivers/media/i2c/adv7511-v4l2.c:2251:21: warning: no previous prototype for function 'adv7511_subdev' [-Wmissing-prototypes]
   struct v4l2_subdev *adv7511_subdev(struct v4l2_subdev *sd)
                       ^
   drivers/media/i2c/adv7511-v4l2.c:2251:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   struct v4l2_subdev *adv7511_subdev(struct v4l2_subdev *sd)
   ^
   static 
   1 warning and 1 error generated.


vim +/adv7511_set_rgb_quantization_mode +427 drivers/media/i2c/adv7511-v4l2.c

   421	
   422	static void adv7511_set_rgb_quantization_mode(struct v4l2_subdev *sd, struct v4l2_ctrl *ctrl)
   423	{
   424		struct adv7511_state *state = get_adv7511_state(sd);
   425	
   426	#ifdef XYLON_LOGICVC_INTG
 > 427		return 0;
   428	#endif
   429	
   430		/* Only makes sense for RGB formats */
   431		if (state->fmt_code != MEDIA_BUS_FMT_RGB888_1X24) {
   432			/* so just keep quantization */
   433			adv7511_csc_rgb_full2limit(sd, false);
   434			return;
   435		}
   436	
   437		switch (ctrl->val) {
   438		case V4L2_DV_RGB_RANGE_AUTO:
   439			/* automatic */
   440			if (state->dv_timings.bt.flags & V4L2_DV_FL_IS_CE_VIDEO) {
   441				/* CE format, RGB limited range (16-235) */
   442				adv7511_csc_rgb_full2limit(sd, true);
   443			} else {
   444				/* not CE format, RGB full range (0-255) */
   445				adv7511_csc_rgb_full2limit(sd, false);
   446			}
   447			break;
   448		case V4L2_DV_RGB_RANGE_LIMITED:
   449			/* RGB limited range (16-235) */
   450			adv7511_csc_rgb_full2limit(sd, true);
   451			break;
   452		case V4L2_DV_RGB_RANGE_FULL:
   453			/* RGB full range (0-255) */
   454			adv7511_csc_rgb_full2limit(sd, false);
   455			break;
   456		}
   457	}
   458	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29120 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/06e75330/attachment-0001.gz>

From ndesaulniers at google.com  Thu Apr  1 20:20:07 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Thu, 1 Apr 2021 12:20:07 -0700
Subject: [PATCH] usb: isp1301-omap: Add missing gpiod_add_lookup_table
 function
In-Reply-To: <20210401162032.10150-1-maciej.falkowski9@gmail.com>
References: <20210401162032.10150-1-maciej.falkowski9@gmail.com>
Message-ID: <CAKwvOdkqExnM=HpPDoj+40MDA3Wyv+oMGDD5MQq3Si2ehfT=6w@mail.gmail.com>

On Thu, Apr 1, 2021 at 9:21 AM Maciej Falkowski
<maciej.falkowski9 at gmail.com> wrote:
>
> The gpiod table was added without any usage making it unused
> as reported by Clang compilation from omap1_defconfig on linux-next:
>
> arch/arm/mach-omap1/board-h2.c:347:34: warning: unused variable 'isp1301_gpiod_table' [-Wunused-variable]
> static struct gpiod_lookup_table isp1301_gpiod_table = {
>                                  ^
> 1 warning generated.
>
> The patch adds the missing gpiod_add_lookup_table() function.
>
> Signed-off-by: Maciej Falkowski <maciej.falkowski9 at gmail.com>
> Fixes: f3ef38160e3d ("usb: isp1301-omap: Convert to use GPIO descriptors")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1325

Looks consistent to me with other callers of gpiod_add_lookup_table
from .init_machine callbacks.

Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>

> ---
>  arch/arm/mach-omap1/board-h2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index c40cf5ef8607..977b0b744c22 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -320,7 +320,7 @@ static int tps_setup(struct i2c_client *client, void *context)
>  {
>         if (!IS_BUILTIN(CONFIG_TPS65010))
>                 return -ENOSYS;
> -
> +
>         tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
>                                 TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
>
> @@ -394,6 +394,8 @@ static void __init h2_init(void)
>         BUG_ON(gpio_request(H2_NAND_RB_GPIO_PIN, "NAND ready") < 0);
>         gpio_direction_input(H2_NAND_RB_GPIO_PIN);
>
> +       gpiod_add_lookup_table(&isp1301_gpiod_table);
> +
>         omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
>         omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
>
> --

-- 
Thanks,
~Nick Desaulniers


From royyang at google.com  Thu Apr  1 20:17:44 2021
From: royyang at google.com (Roy Yang)
Date: Thu,  1 Apr 2021 12:17:44 -0700
Subject: [PATCH] Where we are for this patch?
In-Reply-To: <20210330205750.428816-1-keescook@chromium.org>
References: <20210330205750.428816-1-keescook@chromium.org>
Message-ID: <20210401191744.1685896-1-royyang@google.com>

Both Android and Chrome OS really want this feature; For Container-Optimized OS, we have customers
interested in the defense too.

Thank you very much.

Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3
-- 
2.31.0.208.g409f899ff0-goog



From arnd at kernel.org  Thu Apr  1 20:24:16 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:16 +0200
Subject: [GIT PULL 2/5] clk: tegra: Changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-2-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-2-thierry.reding@gmail.com>
Message-ID: <161730504512.632809.13353373466753586224.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:26:19 +0200, Thierry Reding wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-clk
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 16320d7fe7d6ca19c57523bb5a9b085942842159

       Arnd


From arnd at kernel.org  Thu Apr  1 20:24:14 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:14 +0200
Subject: [GIT PULL] Raspberry Pi driver updates for v5.13
In-Reply-To: <20210322174232.29549-1-nsaenz@kernel.org>
References: <20210322174232.29549-1-nsaenz@kernel.org>
Message-ID: <161730504479.632809.2179392548261995613.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 22 Mar 2021 18:42:32 +0100, Nicolas Saenz Julienne wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi.git tags/rpi-poe-v5.13
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 7da68c64bc9037da7e470bfd219a2b5b7e7c5af1

       Arnd


From arnd at kernel.org  Thu Apr  1 20:24:17 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:17 +0200
Subject: [GIT PULL 3/5] soc/tegra: Changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-3-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-3-thierry.reding@gmail.com>
Message-ID: <161730504520.632809.18138273991245281834.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:26:20 +0200, Thierry Reding wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-soc
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 66f3431a87339f332a2ca674e9fbca48a6014f89

       Arnd


From arnd at kernel.org  Thu Apr  1 20:24:15 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:15 +0200
Subject: [GIT PULL 1/6] i.MX drivers change for 5.13
In-Reply-To: <20210331041019.31345-1-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
Message-ID: <161730504504.632809.4091149331295571068.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:14 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-drivers-5.13
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 62c93360ec5a135061624eb095986799942efcbd

       Arnd


From arnd at kernel.org  Thu Apr  1 20:24:12 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:12 +0200
Subject: [GIT PULL 3/3] Broadcom drivers changes for 5.13
In-Reply-To: <20210330184006.1451315-3-f.fainelli@gmail.com>
References: <20210330184006.1451315-1-f.fainelli@gmail.com>
 <20210330184006.1451315-3-f.fainelli@gmail.com>
Message-ID: <161730504496.632809.4121560040129719627.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 30 Mar 2021 11:40:06 -0700, Florian Fainelli wrote:
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.13/drivers
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: e9396d6b3864d235c57733ccb4902834eb8313a8

       Arnd


From arnd at kernel.org  Thu Apr  1 20:24:18 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 21:24:18 +0200
Subject: [GIT PULL 1/3] Driver changes for omaps for genpd support
In-Reply-To: <pull-1617004205-537424@atomide.com>
References: <pull-1617004205-537424@atomide.com>
Message-ID: <161730504480.632809.11230034462236012550.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 29 Mar 2021 10:55:20 +0300, Tony Lindgren wrote:
> The following changes since commit 4c9f4865f4604744d4f1a43db22ac6ec9dc8e587:
> 
>   Merge branch 'fixes-rc2' into fixes (2021-03-08 11:34:12 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/ti-sysc-signed
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 1d79dca631e8e7fe886f44f49b1e0a16e1ac1dfc

       Arnd


From robh at kernel.org  Thu Apr  1 20:45:21 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 1 Apr 2021 14:45:21 -0500
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <20210331160059.GD7815@willie-the-truck>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
Message-ID: <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>

On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
>
> On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon <will at kernel.org> wrote:
> > >
> > > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > > From: Raphael Gault <raphael.gault at arm.com>
> > > >
> > > > Keep track of event opened with direct access to the hardware counters
> > > > and modify permissions while they are open.
> > > >
> > > > The strategy used here is the same which x86 uses: every time an event
> > > > is mapped, the permissions are set if required. The atomic field added
> > > > in the mm_context helps keep track of the different event opened and
> > > > de-activate the permissions when all are unmapped.
> > > > We also need to update the permissions in the context switch code so
> > > > that tasks keep the right permissions.
> > > >
> > > > In order to enable 64-bit counters for userspace when available, a new
> > > > config1 bit is added for userspace to indicate it wants userspace counter
> > > > access. This bit allows the kernel to decide if chaining should be
> > > > disabled and chaining and userspace access are incompatible.
> > > > The modes for config1 are as follows:
> > > >
> > > > config1 = 0 or 2 : user access enabled and always 32-bit
> > > > config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
> > > > config1 = 3 : user access enabled and counter size matches underlying counter.
> > >
> > > In this last case, how does userspace know whether it got a 32-bit or a
> > > 64-bit counter?
> >
> > pmc_width in the user page. If the read loop is correct, then it
> > doesn't matter to the user.
>
> Gotcha; please mention that in this comment,
>
> > > > +static void refresh_pmuserenr(void *mm)
> > > > +{
> > > > +     if (mm == current->active_mm)
> > > > +             perf_switch_user_access(mm);
> > > > +}
> > > > +
> > > > +static void armv8pmu_event_mapped(struct perf_event *event, struct mm_struct *mm)
> > > > +{
> > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > +
> > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > +             return;
> > > > +
> > > > +     /*
> > > > +      * This function relies on not being called concurrently in two
> > > > +      * tasks in the same mm.  Otherwise one task could observe
> > > > +      * pmu_direct_access > 1 and return all the way back to
> > > > +      * userspace with user access disabled while another task is still
> > > > +      * doing on_each_cpu_mask() to enable user access.
> > > > +      *
> > > > +      * For now, this can't happen because all callers hold mmap_lock
> > > > +      * for write.  If this changes, we'll need a different solution.
> > > > +      */
> > > > +     lockdep_assert_held_write(&mm->mmap_lock);
> > > > +
> > > > +     if (atomic_inc_return(&mm->context.pmu_direct_access) == 1)
> > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > > > +}
> > >
> > > Why do we need to cross-call here? Seems like it would be a tonne simpler to
> > > handle the trap. Is there a reason not to do that?
> >
> > Alignment with x86? You didn't like the trap handler either:
> >
> > > Hmm... this feels pretty fragile since, although we may expect userspace only
> > > to trigger this in the context of the specific perf use-case, we don't have
> > > a way to detect that, so the ABI we're exposing is that EL0 accesses to
> > > non-existent counters will return 0. I don't really think that's something
> > > we want to commit to.
> >
> > Full mail: https://lore.kernel.org/r/20200928182601.GA11974 at willie-the-truck
> >
> > The handler would be different, but we'd still have the problem of not
> > being able to detect the use case, right?
>
> Well hang on, the thing you link to was about _emulating_ the access. I'm
> not saying we should do that, but rather just enable EL0 PMU access lazily
> instead of using the IPI. We're going to enable it when we context-switch
> anyway.
>
> The alternative is enabling EL0 access unconditionally and leaving it
> enabled.

That BTW is what x86 originally did. This pmu_direct_access stuff came
about as part of locking down access a bit.

In any case, I've modified this to trap. It avoids the mmap lock
dependency too, so that's nice.

> > > > +
> > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > +{
> > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > +
> > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > +             return;
> > > > +
> > > > +     if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > >
> > > Given that the pmu_direct_access field is global per-mm, won't this go
> > > wrong if multiple PMUs are opened by the same process but only a subset
> > > are exposed to EL0? Perhaps pmu_direct_access should be treated as a mask
> > > rather than a counter, so that we can 'and' it with the supported_cpus for
> > > the PMU we're dealing with.
> >
> > It needs to be a count to support multiple events on the same PMU. If
> > the event is not enabled for EL0, then we'd exit out on the
> > ARMPMU_EL0_RD_CNTR check. So I think we're fine.
>
> I'm still not convinced; pmu_direct_access is shared between PMUs, so
> testing the result of atomic_dec_and_test() just doesn't make sense to
> me, as another PMU could be playing with the count.

How is that a problem? Let's make a concrete example:

map PMU1:event2 -> pmu_direct_access = 1 -> enable access
map PMU2:event3 -> pmu_direct_access = 2
map PMU1:event4 -> pmu_direct_access = 3
unmap PMU2:event3 -> pmu_direct_access = 2
unmap PMU1:event2 -> pmu_direct_access = 1
unmap PMU1:event4 -> pmu_direct_access = 0 -> disable access

The only issue I can see is PMU2 remains enabled for user access until
the last unmap. But we're sharing the mm, so who cares? Also, in this
scenario it is the user's problem to pin themselves to cores sharing a
PMU. If the user doesn't do that, they get to keep the pieces.

We have to have something that says 'we have mmapped user accessible
events for the mm context'. I don't think there is any way around that
if we gate access on mmapping events.

Rob


From madvenka at linux.microsoft.com  Thu Apr  1 20:47:11 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 1 Apr 2021 14:47:11 -0500
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <fe2f3b1e-8cb6-05ce-7968-216fed079fe4@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
 <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
 <20210401182810.GO4758@sirena.org.uk>
 <2a56fe4b-9929-0d8b-aa49-c2b1c1b82b79@linux.microsoft.com>
 <fe2f3b1e-8cb6-05ce-7968-216fed079fe4@linux.microsoft.com>
Message-ID: <9ebc341b-ba5a-db9a-c5e6-17b30d4b1fd4@linux.microsoft.com>



On 4/1/21 1:53 PM, Madhavan T. Venkataraman wrote:
> 
> 
> On 4/1/21 1:40 PM, Madhavan T. Venkataraman wrote:
>>>> So, it is only defined if CONFIG_FUNCTION_GRAPH_TRACER is defined. I can address
>>>> this as well as your comment by defining another label whose name is more meaningful
>>>> to our use:
>>>> +SYM_INNER_LABEL(ftrace_trampoline, SYM_L_GLOBAL) // checked by the unwinder
>>>> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>>> SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();
>>>>         nop                             // If enabled, this will be replaced
>>>>                                         // "b ftrace_graph_caller"
>>>> #endif
>>> I'm not sure we need to bother with that, you'd still need the & I think.
>> I think we need to bother with that. If CONFIG_FUNCTION_GRAPH_TRACER is not on but
>> CONFIG_DYNAMIC_FTRACE_WITH_REGS is, then ftrace_graph_call() will not occur in the stack
>> trace taken from a tracer function. The unwinder still needs to recognize an ftrace frame.
>> I don't want to assume ftrace_common_return which is the label that currently follows
>> the above code. So, we need a different label outside the above ifdef.
> 
> Alternatively, I could just move the SYM_INNER_LABEL(ftrace_graph_call..) to outside the ifdef.
> 
> Madhavan
> 

Or, even better, I could just use ftrace_call+4 because that would be the return
address for the tracer function at ftrace_call:

SYM_CODE_START(ftrace_common)
        sub     x0, x30, #AARCH64_INSN_SIZE     // ip (callsite's BL insn)
        mov     x1, x9                          // parent_ip (callsite's LR)
        ldr_l   x2, function_trace_op           // op
        mov     x3, sp                          // regs

SYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL)
        bl      ftrace_stub

I think that would be cleaner. And, I don't need the complicated comments for ftrace_graph_call.

Is this acceptable?

Madhavan


From viro at zeniv.linux.org.uk  Thu Apr  1 20:48:30 2021
From: viro at zeniv.linux.org.uk (Al Viro)
Date: Thu, 1 Apr 2021 19:48:30 +0000
Subject: [PATCH] Where we are for this patch?
In-Reply-To: <20210401191744.1685896-1-royyang@google.com>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210401191744.1685896-1-royyang@google.com>
Message-ID: <YGYjjpoj1uMn1VEd@zeniv-ca.linux.org.uk>

On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote:
> Both Android and Chrome OS really want this feature; For Container-Optimized OS, we have customers
> interested in the defense too.
> 
> Thank you very much.
> 
> Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3

	You forgot to tell what patch you are refering to.  Your
Change-Id (whatever the hell that is) doesn't help at all.  Don't
assume that keys in your internal database make sense for the
rest of the world, especially when they appear to contain a hash
of something...


From lkp at intel.com  Thu Apr  1 21:07:14 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 04:07:14 +0800
Subject: [xlnx:xlnx_rebase_v5.4 908/1701] trace.c:(.text+0x1c40): multiple
 definition of `dwc3_set_usb_core_power';
 drivers/usb/dwc3/core.o:core.c:(.text+0x9a0): first defined here
Message-ID: <202104020410.QMj0Dfmx-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 68a922ded3cde24cb75c0cad0c62403d97ca9aaf [908/1701] usb: dwc3: Add code for supporting entering into D3 state during suspend
config: i386-randconfig-c021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/68a922ded3cde24cb75c0cad0c62403d97ca9aaf
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 68a922ded3cde24cb75c0cad0c62403d97ca9aaf
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1430:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1430 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1432:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1432 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1434:6: warning: no previous prototype for 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
    1434 | void dwc3_simple_check_quirks(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.h:1436:5: warning: no previous prototype for 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
    1436 | int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
         |     ^~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h: In function 'dwc3_set_usb_core_power':
>> drivers/usb/dwc3/core.h:1437:5: warning: control reaches end of non-void function [-Wreturn-type]
    1437 | { ; }
         |     ^
--
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_wakeup_capable':
   trace.c:(.text+0x1c10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x970): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_simple_data':
   trace.c:(.text+0x1c20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x980): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_check_quirks':
   trace.c:(.text+0x1c30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x990): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_usb_core_power':
>> trace.c:(.text+0x1c40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0x9a0): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_wakeup_capable':
   host.c:(.text+0x10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x970): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_simple_data':
   host.c:(.text+0x20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x980): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_check_quirks':
   host.c:(.text+0x30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x990): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_usb_core_power':
   host.c:(.text+0x40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0x9a0): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_wakeup_capable':
   ulpi.c:(.text+0xa80): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x970): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_simple_data':
   ulpi.c:(.text+0xa90): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x980): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_check_quirks':
   ulpi.c:(.text+0xaa0): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x990): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_usb_core_power':
   ulpi.c:(.text+0xab0): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0x9a0): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_wakeup_capable':
   debugfs.c:(.text+0xa10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0x970): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_simple_data':
   debugfs.c:(.text+0xa20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0x980): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_check_quirks':
   debugfs.c:(.text+0xa30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0x990): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_usb_core_power':
   debugfs.c:(.text+0xa40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0x9a0): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/4c38a546/attachment-0001.gz>

From tytso at mit.edu  Thu Apr  1 21:13:21 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 1 Apr 2021 16:13:21 -0400
Subject: [PATCH] Where we are for this patch?
In-Reply-To: <YGYjjpoj1uMn1VEd@zeniv-ca.linux.org.uk>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210401191744.1685896-1-royyang@google.com>
 <YGYjjpoj1uMn1VEd@zeniv-ca.linux.org.uk>
Message-ID: <YGYpYUqIf9rdJqRi@mit.edu>

On Thu, Apr 01, 2021 at 07:48:30PM +0000, Al Viro wrote:
> On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote:
> > Both Android and Chrome OS really want this feature; For Container-Optimized OS, we have customers
> > interested in the defense too.
> > 
> > Thank you very much.
> > 
> > Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3
> 
> 	You forgot to tell what patch you are refering to.  Your
> Change-Id (whatever the hell that is) doesn't help at all.  Don't
> assume that keys in your internal database make sense for the
> rest of the world, especially when they appear to contain a hash
> of something...

The Change-Id fails to have any direct search hits at lore.kernel.org.
However, it turn up Roy's original patch, and clicking on the
message-Id in the "In-Reply-Field", it apperas Roy was replying to
this message:

https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/

which is the head of this patch series:

Subject: [PATCH v8 0/6] Optionally randomize kernel stack offset each syscall

That being said, it would have been better if the original subject
line had been preserved, and it's yet another example of how the
lore.kernel.org URL is infinitely better than the Change-Id.  :-)

		       		  	      - Ted


From arnd at kernel.org  Thu Apr  1 21:15:16 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:16 +0200
Subject: [PATCH 0/3] ARM: mstar: MPLL mop up
In-Reply-To: <20210301123542.2800643-1-daniel@0x0f.com>
References: <20210301123542.2800643-1-daniel@0x0f.com>
Message-ID: <161730808589.655497.9969521332794261660.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 1 Mar 2021 21:35:39 +0900, Daniel Palmer wrote:
> This series is just 3 small patches that got left behind
> when the MPLL driver was merged.
> 
> Link: https://lore.kernel.org/linux-arm-kernel/20210211052206.2955988-1-daniel at 0x0f.com/
> 
> Daniel Palmer (3):
>   ARM: mstar: Select MSTAR_MSC313_MPLL
>   ARM: mstar: Add the external clocks to the base dsti
>   ARM: mstar: Add mpll to base dtsi
> 
> [...]

Applied to arm/dt, thanks!

[1/3] ARM: mstar: Select MSTAR_MSC313_MPLL
      commit: de73b5a97bba1538f065e1e90d8eeac399db7510
[2/3] ARM: mstar: Add the external clocks to the base dsti
      commit: a93cf651df08c370e622c3aea456bc729b352437
[3/3] ARM: mstar: Add mpll to base dtsi
      commit: f374f25aab6f10ba5e442d8f81dd94d960276cb5

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:18 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:18 +0200
Subject: [GIT PULL 1/3] Broadcom devicetree changes for 5.13
In-Reply-To: <20210330184006.1451315-1-f.fainelli@gmail.com>
References: <20210330184006.1451315-1-f.fainelli@gmail.com>
Message-ID: <161730808607.655497.16848778452197527943.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 30 Mar 2021 11:40:04 -0700, Florian Fainelli wrote:
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.13/devicetree
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 498adc8623c237d9f87f4a0582393e0d69504bae

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:19 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:19 +0200
Subject: [GIT PULL 2/3] Broadcom devicetree-arm64 changes for 5.13
In-Reply-To: <20210330184006.1451315-2-f.fainelli@gmail.com>
References: <20210330184006.1451315-1-f.fainelli@gmail.com>
 <20210330184006.1451315-2-f.fainelli@gmail.com>
Message-ID: <161730808616.655497.2246714520571394134.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 30 Mar 2021 11:40:05 -0700, Florian Fainelli wrote:
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.13/devicetre-arm64
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 3b73ea6c8069a616be468d00c7ba6148bf82dad9

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:22 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:22 +0200
Subject: [GIT PULL] ARM: dts: mediatek: updates for v5.13
In-Reply-To: <be262120-6cd9-87a7-ccc3-f5c403cff66b@gmail.com>
References: <be262120-6cd9-87a7-ccc3-f5c403cff66b@gmail.com>
Message-ID: <161730808698.655497.18205720456447891568.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 16:01:34 +0200, Matthias Brugger wrote:
> Please take the below patches into account. These are mostly cleanups to make
> the DTB checker happy. Apart from that we now have SMP support for MT6589, it's
> nice to see that someone keeps working on this old platform with which I started
> upstreaming :)
> 
> Regards,
> Matthias

Merged into arm/dt, thanks!

merge commit: 8028548ba16284166987d8969e0c5bec36a0228d

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:21 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:21 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13
In-Reply-To: <d1121630-5778-0955-fac7-f921174defe7@gmail.com>
References: <d1121630-5778-0955-fac7-f921174defe7@gmail.com>
Message-ID: <161730808707.655497.13146893990691457286.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 16:14:20 +0200, Matthias Brugger wrote:
> Please have a look at the updates below. As you can see we have quite some
> activity on the MT8183 based devices, with a whole bunch of new Chromebook
> bindings added this round. Apart from that the a bit older MT8173 still gets
> improvement, which is nice to see.
> 
> Regards,
> Matthias

Merged into arm/dt, thanks!

merge commit: 7d534c3a5e1f52022c889ed10c413c54ac2a4d0f

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:24 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:24 +0200
Subject: [GIT PULL 4/6] i.MX device tree change for 5.13
In-Reply-To: <20210331041019.31345-4-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
 <20210331041019.31345-4-shawnguo@kernel.org>
Message-ID: <161730808632.655497.14668701970057565320.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:17 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-5.13
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 4f662ba2be220044bb965f36826723c8f1e14eec

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:23 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:23 +0200
Subject: [GIT PULL 3/6] i.MX DT bindings update for 5.13
In-Reply-To: <20210331041019.31345-3-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
 <20210331041019.31345-3-shawnguo@kernel.org>
Message-ID: <161730808624.655497.9470372573569537914.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:16 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-bindgins-5.13
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 2771bc0dbaad48238b0fc3ae73d1c5215b5e018b

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:25 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:25 +0200
Subject: [GIT PULL 5/6] i.MX arm64 device tree update for 5.13
In-Reply-To: <20210331041019.31345-5-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
 <20210331041019.31345-5-shawnguo@kernel.org>
Message-ID: <161730808640.655497.12938908556780243539.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:18 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-5.13
> 
> [...]

Merged into arm/dt, thanks!

merge commit: d2adc561c9bfc72468cb50d15080459757ff5f2e

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:26 +0200
Subject: [GIT PULL] arm64: dts: juno: Updates for v5.13
In-Reply-To: <20210331100410.cenuhvpqoumvsk52@bogus>
References: <20210331100410.cenuhvpqoumvsk52@bogus>
Message-ID: <161730808648.655497.9953607257021480984.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 11:04:10 +0100, Sudeep Holla wrote:
> Please pull !
> 
> Regards,
> Sudeep
> 
> -->8
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 45f174d8a13cd877034189628f6b00bf30c832c6

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:27 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:27 +0200
Subject: [GIT PULL 1/5] dt-bindings: Changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-1-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
Message-ID: <161730808673.655497.15661315865375300905.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:26:18 +0200, Thierry Reding wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-dt-bindings
> 
> [...]

Merged into arm/dt, thanks!

merge commit: ece61ed98bdab5c5ee28777cd5cb3113fe71bacf

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:28 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:28 +0200
Subject: [GIT PULL 4/5] ARM: tegra: Device tree changes for v5.13-rc1
In-Reply-To: <20210401172622.3352990-4-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-4-thierry.reding@gmail.com>
Message-ID: <161730808681.655497.5868198720723763066.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:26:21 +0200, Thierry Reding wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm-dt
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 815bacb522c5d5e833dad5be349c80de9afdf1df

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:30 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:30 +0200
Subject: [GIT PULL 2/3] Devicetree changes for omaps for genpd support
In-Reply-To: <pull-1617004205-537424@atomide.com-2>
References: <pull-1617004205-537424@atomide.com>
 <pull-1617004205-537424@atomide.com-2>
Message-ID: <161730808591.655497.12428729315912496095.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 29 Mar 2021 10:55:21 +0300, Tony Lindgren wrote:
> The following changes since commit e259c2926c016dd815e5547412356d378fc1f589:
> 
>   PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver (2021-03-10 14:01:00 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/dts-genpd-signed
> 
> [...]

Merged into arm/dt, thanks!

merge commit: e49936d2154724213b5ec8a8aae89b2c2ebc3af1

       Arnd


From arnd at kernel.org  Thu Apr  1 21:15:29 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 22:15:29 +0200
Subject: [GIT PULL 5/5] arm64: tegra: Device tree fixes for v5.12-rc6
In-Reply-To: <20210401172622.3352990-5-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-5-thierry.reding@gmail.com>
Message-ID: <161730808690.655497.9362657785877242094.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:26:22 +0200, Thierry Reding wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm64-dt
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 520f30feb864e9baaf7bed677892b478ffd10232

       Arnd


From lkp at intel.com  Thu Apr  1 21:36:45 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 04:36:45 +0800
Subject: [PATCH 06/30] media: atmel: atmel-isc: extract CSC submodule
 config into separate function
In-Reply-To: <20210401112723.189107-7-eugen.hristev@microchip.com>
References: <20210401112723.189107-7-eugen.hristev@microchip.com>
Message-ID: <202104020456.fWb6HaZn-lkp@intel.com>

Hi Eugen,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v5.12-rc5 next-20210401]
[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]

url:    https://github.com/0day-ci/linux/commits/Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
base:   git://linuxtv.org/media_tree.git master
config: arm64-randconfig-r024-20210401 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/16c4afad71c41ecb74d0afff8e7ccc7e868d3cdd
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
        git checkout 16c4afad71c41ecb74d0afff8e7ccc7e868d3cdd
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/media/platform/atmel/atmel-sama5d2-isc.c:57:6: warning: no previous prototype for 'isc_sama5d2_config_csc' [-Wmissing-prototypes]
      57 | void isc_sama5d2_config_csc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~


vim +/isc_sama5d2_config_csc +57 drivers/media/platform/atmel/atmel-sama5d2-isc.c

    56	
  > 57	void isc_sama5d2_config_csc(struct isc_device *isc)
    58	{
    59		struct regmap *regmap = isc->regmap;
    60	
    61		/* Convert RGB to YUV */
    62		regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
    63		regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
    64		regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
    65		regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
    66		regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
    67		regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
    68	}
    69	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37908 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/a2acf82f/attachment-0001.gz>

From lkp at intel.com  Thu Apr  1 21:36:46 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 04:36:46 +0800
Subject: [PATCH 30/30] media: atmel: atmel-isc: add microchip-xisc driver
In-Reply-To: <20210401112723.189107-31-eugen.hristev@microchip.com>
References: <20210401112723.189107-31-eugen.hristev@microchip.com>
Message-ID: <202104020456.nce4D2jt-lkp@intel.com>

Hi Eugen,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v5.12-rc5 next-20210401]
[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]

url:    https://github.com/0day-ci/linux/commits/Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
base:   git://linuxtv.org/media_tree.git master
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/5940a9ab90aba6cd4c659b9df3ab1b8bb0ce0e43
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
        git checkout 5940a9ab90aba6cd4c659b9df3ab1b8bb0ce0e43
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:207:6: warning: no previous prototype for 'isc_sama7g5_config_csc' [-Wmissing-prototypes]
     207 | void isc_sama7g5_config_csc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:226:6: warning: no previous prototype for 'isc_sama7g5_config_cbc' [-Wmissing-prototypes]
     226 | void isc_sama7g5_config_cbc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:238:6: warning: no previous prototype for 'isc_sama7g5_config_cc' [-Wmissing-prototypes]
     238 | void isc_sama7g5_config_cc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:251:6: warning: no previous prototype for 'isc_sama7g5_config_ctrls' [-Wmissing-prototypes]
     251 | void isc_sama7g5_config_ctrls(struct isc_device *isc,
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:262:6: warning: no previous prototype for 'isc_sama7g5_config_dpc' [-Wmissing-prototypes]
     262 | void isc_sama7g5_config_dpc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:273:6: warning: no previous prototype for 'isc_sama7g5_config_gam' [-Wmissing-prototypes]
     273 | void isc_sama7g5_config_gam(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:281:6: warning: no previous prototype for 'isc_sama7g5_config_rlp' [-Wmissing-prototypes]
     281 | void isc_sama7g5_config_rlp(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama7g5-isc.c:291:6: warning: no previous prototype for 'isc_sama7g5_adapt_pipeline' [-Wmissing-prototypes]
     291 | void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/media/platform/atmel/atmel-sama7g5-isc.c: In function 'microchip_xisc_probe':
   drivers/media/platform/atmel/atmel-sama7g5-isc.c:530:9: error: implicit declaration of function 'v4l2_async_notifier_add_subdev'; did you mean 'v4l2_async_notifier_add_i2c_subdev'? [-Werror=implicit-function-declaration]
     530 |   ret = v4l2_async_notifier_add_subdev(&subdev_entity->notifier,
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         |         v4l2_async_notifier_add_i2c_subdev
   cc1: some warnings being treated as errors


vim +/isc_sama7g5_config_csc +207 drivers/media/platform/atmel/atmel-sama7g5-isc.c

   206	
 > 207	void isc_sama7g5_config_csc(struct isc_device *isc)
   208	{
   209		struct regmap *regmap = isc->regmap;
   210	
   211		/* Convert RGB to YUV */
   212		regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
   213			     0x42 | (0x81 << 16));
   214		regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
   215			     0x19 | (0x10 << 16));
   216		regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
   217			     0xFDA | (0xFB6 << 16));
   218		regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
   219			     0x70 | (0x80 << 16));
   220		regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
   221			     0x70 | (0xFA2 << 16));
   222		regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
   223			     0xFEE | (0x80 << 16));
   224	}
   225	
 > 226	void isc_sama7g5_config_cbc(struct isc_device *isc)
   227	{
   228		struct regmap *regmap = isc->regmap;
   229	
   230		/* Configure what is set via v4l2 ctrls */
   231		regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc, isc->ctrls.brightness);
   232		regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc, isc->ctrls.contrast);
   233		/* Configure Hue and Saturation as neutral midpoint */
   234		regmap_write(regmap, ISC_CBCHS_HUE, 0);
   235		regmap_write(regmap, ISC_CBCHS_SAT, (1 << 4));
   236	}
   237	
 > 238	void isc_sama7g5_config_cc(struct isc_device *isc)
   239	{
   240		struct regmap *regmap = isc->regmap;
   241	
   242		/* Configure each register at the neutral fixed point 1.0 or 0.0 */
   243		regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
   244		regmap_write(regmap, ISC_CC_RB_OR, 0);
   245		regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
   246		regmap_write(regmap, ISC_CC_GB_OG, 0);
   247		regmap_write(regmap, ISC_CC_BR_BG, 0);
   248		regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
   249	}
   250	
 > 251	void isc_sama7g5_config_ctrls(struct isc_device *isc,
   252				      const struct v4l2_ctrl_ops *ops)
   253	{
   254		struct isc_ctrls *ctrls = &isc->ctrls;
   255		struct v4l2_ctrl_handler *hdl = &ctrls->handler;
   256	
   257		ctrls->contrast = 16;
   258	
   259		v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 16);
   260	}
   261	
 > 262	void isc_sama7g5_config_dpc(struct isc_device *isc)
   263	{
   264		u32 bay_cfg = isc->config.sd_format->cfa_baycfg;
   265		struct regmap *regmap = isc->regmap;
   266	
   267		regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BLOFF_MASK,
   268				   (64 << ISC_DPC_CFG_BLOFF_SHIFT));
   269		regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BAYCFG_MASK,
   270				   (bay_cfg << ISC_DPC_CFG_BAYCFG_SHIFT));
   271	}
   272	
 > 273	void isc_sama7g5_config_gam(struct isc_device *isc)
   274	{
   275		struct regmap *regmap = isc->regmap;
   276	
   277		regmap_update_bits(regmap, ISC_GAM_CTRL, ISC_GAM_CTRL_BIPART,
   278				   ISC_GAM_CTRL_BIPART);
   279	}
   280	
 > 281	void isc_sama7g5_config_rlp(struct isc_device *isc)
   282	{
   283		struct regmap *regmap = isc->regmap;
   284		u32 rlp_mode = isc->config.rlp_cfg_mode;
   285	
   286		regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
   287				   ISC_RLP_CFG_MODE_MASK | ISC_RLP_CFG_LSH |
   288				   ISC_RLP_CFG_YMODE_MASK, rlp_mode);
   289	}
   290	
 > 291	void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
   292	{
   293		isc->try_config.bits_pipeline &= ISC_SAMA7G5_PIPELINE;
   294	}
   295	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 58972 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/544c40e2/attachment-0001.gz>

From lkp at intel.com  Thu Apr  1 21:38:19 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 04:38:19 +0800
Subject: [xlnx:xlnx_rebase_v5.4 842/1701] drivers/spi/spi-mem.c:18:6:
 warning: no previous prototype for function 'update_stripe'
Message-ID: <202104020412.ZU9dfJgd-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 3780469dd372e934445de2fbb5e8cf6e712b9b99 [842/1701] spi: Add Zynq QSPI controller driver
config: x86_64-randconfig-a004-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/3780469dd372e934445de2fbb5e8cf6e712b9b99
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 3780469dd372e934445de2fbb5e8cf6e712b9b99
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/spi/spi-mem.c:10:
   In file included from include/linux/mtd/spi-nor.h:10:
   include/linux/mtd/cfi.h:62:2: warning: No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work. [-W#warnings]
   #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
    ^
>> drivers/spi/spi-mem.c:18:6: warning: no previous prototype for function 'update_stripe' [-Wmissing-prototypes]
   bool update_stripe(const u8 opcode)
        ^
   drivers/spi/spi-mem.c:18:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   bool update_stripe(const u8 opcode)
   ^
   static 
   2 warnings generated.


vim +/update_stripe +18 drivers/spi/spi-mem.c

    17	
  > 18	bool update_stripe(const u8 opcode)
    19	{
    20		if (opcode ==  SPINOR_OP_BE_4K ||
    21		    opcode ==  SPINOR_OP_BE_32K ||
    22		    opcode ==  SPINOR_OP_CHIP_ERASE ||
    23		    opcode ==  SPINOR_OP_SE ||
    24		    opcode ==  SPINOR_OP_BE_32K_4B ||
    25		    opcode ==  SPINOR_OP_SE_4B ||
    26		    opcode == SPINOR_OP_BE_4K_4B ||
    27		    opcode ==  SPINOR_OP_WRSR ||
    28		    opcode ==  SPINOR_OP_WREAR ||
    29		    opcode ==  SPINOR_OP_BRWR ||
    30		    opcode ==  SPINOR_OP_WRSR2)
    31			return false;
    32	
    33		return true;
    34	}
    35	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29128 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/bb04b4b2/attachment-0001.gz>

From royyang at google.com  Thu Apr  1 21:49:17 2021
From: royyang at google.com (Roy Yang)
Date: Thu, 1 Apr 2021 13:49:17 -0700
Subject: [PATCH v8 0/6] Optionally randomize kernel stack offset each syscall
Message-ID: <CANemeMjOw4sOzMxjdjJcWKD315u+KRn19h687GMbkQdP5Jc_kQ@mail.gmail.com>

Thanks Ted, Casey and Al Viro. I am sorry for the inconvenience.

I tried to follow the instructions listed under
https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/
using git-send-email

Thought that will reply to the original thread with the original
subject . Let me know what I can do to correct this to avoid
confusion.


- Roy


On Thu, Apr 1, 2021 at 1:13 PM Theodore Ts'o <tytso at mit.edu> wrote:
>
> On Thu, Apr 01, 2021 at 07:48:30PM +0000, Al Viro wrote:
> > On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote:
> > > Both Android and Chrome OS really want this feature; For Container-Optimized OS, we have customers
> > > interested in the defense too.
> > >
> > > Thank you very much.
> > >
> > > Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3
> >
> >       You forgot to tell what patch you are refering to.  Your
> > Change-Id (whatever the hell that is) doesn't help at all.  Don't
> > assume that keys in your internal database make sense for the
> > rest of the world, especially when they appear to contain a hash
> > of something...
>
> The Change-Id fails to have any direct search hits at lore.kernel.org.
> However, it turn up Roy's original patch, and clicking on the
> message-Id in the "In-Reply-Field", it apperas Roy was replying to
> this message:
>
> https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/
>
> which is the head of this patch series:
>
> Subject: [PATCH v8 0/6] Optionally randomize kernel stack offset each syscall
>
> That being said, it would have been better if the original subject
> line had been preserved, and it's yet another example of how the
> lore.kernel.org URL is infinitely better than the Change-Id.  :-)
>
>                                               - Ted


From tytso at mit.edu  Thu Apr  1 21:59:20 2021
From: tytso at mit.edu (Theodore Ts'o)
Date: Thu, 1 Apr 2021 16:59:20 -0400
Subject: [PATCH v8 0/6] Optionally randomize kernel stack offset each
 syscall
In-Reply-To: <CANemeMjOw4sOzMxjdjJcWKD315u+KRn19h687GMbkQdP5Jc_kQ@mail.gmail.com>
References: <CANemeMjOw4sOzMxjdjJcWKD315u+KRn19h687GMbkQdP5Jc_kQ@mail.gmail.com>
Message-ID: <YGY0KAgMmm4XlaS8@mit.edu>

On Thu, Apr 01, 2021 at 01:49:17PM -0700, Roy Yang wrote:
> Thanks Ted, Casey and Al Viro. I am sorry for the inconvenience.
> 
> I tried to follow the instructions listed under
> https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/
> using git-send-email
> 
> Thought that will reply to the original thread with the original
> subject . Let me know what I can do to correct this to avoid
> confusion.

It did chain to the original thread; that's how I was able to figure
out the context.  However, it looks like in your reply, you set the
subject to be:

[PATCH] Where we are for this patch?

And the problem is if someone had deleted the original e-mail chain
--- for example, optimizing the kernel stack is not one of the
subjects that I normally closely track, I had already deleted those
e-mail chains.  So all I saw (and I suspect all Al saw) was a message
with the above subject line, and no context.

If you had kept the original subject line, then those of us who mostly
focus on file system stuff would have known that it's an area which is
covered by other maintainers, and we wouldn't have deleted your query
and let someone else respond.

Cheers,

					- Ted

P.S.  I personally find the use "git-send-email" to reply to be so
much of a pain that I just use a non-google.com address to which I can
use a traditional threaded mail-reader (such as mutt) and I can send
e-mail without having to worry about the DMARC nonsense.  :-)



From arnd at kernel.org  Thu Apr  1 22:06:02 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:06:02 +0200
Subject: [PATCH] ARM: configs: Remove REGULATOR_USERSPACE_CONSUMER
In-Reply-To: <20210401102858.4095-1-broonie@kernel.org>
References: <20210401102858.4095-1-broonie@kernel.org>
Message-ID: <161731114633.662954.15683308110570757088.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 11:28:58 +0100, Mark Brown wrote:
> The userspace consumer is a development tool, not intended for producton
> systems and so should not be present in defconfigs especially not those
> for specific machines so is not a good fit for defconfig, remove it from
> those defconfigs where it is enabled. No system in mainline actually
> instantiates one.

Applied to arm/defconfig, thanks!

[1/1] ARM: configs: Remove REGULATOR_USERSPACE_CONSUMER
      commit: 797e1491b8df16eb666ec12f7a49515f12515c37

       Arnd


From arnd at kernel.org  Thu Apr  1 22:06:07 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:06:07 +0200
Subject: [GIT PULL 6/6] i.MX defconfig change for 5.13
In-Reply-To: <20210331041019.31345-6-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
 <20210331041019.31345-6-shawnguo@kernel.org>
Message-ID: <161731114623.662954.11029736079612919707.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:19 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-5.13
> 
> [...]

Merged into arm/defconfig, thanks!

merge commit: bbbd7b0120849d0d8022a5a211d3f1171ecf43cb

       Arnd


From arnd at kernel.org  Thu Apr  1 22:06:04 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:06:04 +0200
Subject: [PATCH] ARM: configs: ux500: Update for new drivers
In-Reply-To: <20210301232050.1457397-1-linus.walleij@linaro.org>
References: <20210301232050.1457397-1-linus.walleij@linaro.org>
Message-ID: <161731114635.662954.4375604729144576675.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 2 Mar 2021 00:20:50 +0100, Linus Walleij wrote:
> Some new driver support for the Ux500 devices landed in
> v5.12-rc1 so update the defconfig to use them:
> 
> - TM2 touchkey, used on the Golden and Janice.
> - SPI GPIO, used for the Janice display control.
> - NTC thermistor, used for the HREF temperature
>   sensors.
> - V4L2 flash control that gives support for LED
>   torch to userspaces such as Phosh.
> - The LEDs Flash class and RT8515 Flash/torch LED
>   driver used in all the Samsung mobiles.
> - FSA9480 extcon, used by Janice.
> - BMC150 accelerometer, used by Janice.
> - IIO rescaler, used for thermistors and ALS
>   on Janice.
> - MPU3050 gyroscope driver used by Janice.
> - Yamaha YAS530 magnetometer driver used by Janice.

Applied to arm/defconfig, thanks!

[1/1] ARM: configs: ux500: Update for new drivers
      commit: 907d6d3e41f960a083dc927350b3b531c43c1ce1

       Arnd


From arnd at kernel.org  Thu Apr  1 22:06:06 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:06:06 +0200
Subject: [GIT PULL] ARM: at91: defconfig for 5.13
In-Reply-To: <20210401162207.29299-1-nicolas.ferre@microchip.com>
References: <20210401162207.29299-1-nicolas.ferre@microchip.com>
Message-ID: <161731114635.662954.7067488075603315200.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 18:22:07 +0200, nicolas.ferre at microchip.com wrote:
> Arnd, Olof,
> 
> Here are the defconfig changes for 5.13 which is bigger than usual for aligning
> with options that we use frequently and some changes which will be beneficial
> for CI.
> There is an update with savedefconfig included, tell me if you prefer the PR
> without this first patch of the series.
> 
> [...]

Merged into arm/defconfig, thanks!

merge commit: 630bc9784b637eac9266d7133cb8698c5507ae7d

       Arnd


From arnd at kernel.org  Thu Apr  1 22:06:05 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:06:05 +0200
Subject: [GIT PULL] defconfig: mediatek: changes for v5.13
In-Reply-To: <70f6a2ae-2a99-6861-e591-9cc71bb174af@gmail.com>
References: <70f6a2ae-2a99-6861-e591-9cc71bb174af@gmail.com>
Message-ID: <161731114634.662954.7269701673980981374.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 15:58:41 +0200, Matthias Brugger wrote:
> Please have a look at the following changes to defconfig. There is a small merge
> conflict with the IMX branch, but it should be trivial.
> 
> Regards,
> Matthias

Merged into arm/defconfig, thanks!

merge commit: 03c623535fbd7313f854f944b1e22f364e7b4c98

       Arnd


From arnd at kernel.org  Thu Apr  1 22:07:04 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:07:04 +0200
Subject: [GIT PULL] ARM: at91: soc for 5.13
In-Reply-To: <20210401174544.32193-1-nicolas.ferre@microchip.com>
References: <20210401174544.32193-1-nicolas.ferre@microchip.com>
Message-ID: <161731121872.663132.5899374227891115109.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 19:45:44 +0200, nicolas.ferre at microchip.com wrote:
> Arnd, Olof,
> 
> One single patch for now on our SoC branch. Stakeholders agreed to make it
> travel with at91 -> arm-soc.
> 
> Thanks, best regards,
>   Nicolas
> 
> [...]

Merged into arm/soc, thanks!

merge commit: 6f35f62958ea395fa8cbd2a28f713ccac8d9b5bd

       Arnd


From arnd at kernel.org  Thu Apr  1 22:07:03 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:07:03 +0200
Subject: [PATCH] ARM: ux500: make ux500_cpu_die static
In-Reply-To: <20210323083203.1646842-1-linus.walleij@linaro.org>
References: <20210323083203.1646842-1-linus.walleij@linaro.org>
Message-ID: <161731121856.663132.10821808877634787283.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 23 Mar 2021 09:32:03 +0100, Linus Walleij wrote:
> The ux500_cpu_die function is not exported so make it static
> to avoid the following warning:
> 
> arch/arm/mach-ux500/platsmp.c:89:6: warning: symbol 'ux500_cpu_die' was not declared. Should it be static?

Applied to arm/soc, thanks!

[1/1] ARM: ux500: make ux500_cpu_die static
      commit: 758c5408ea3d6d730ee388ad8354c4fe94685d4c

       Arnd


From arnd at kernel.org  Thu Apr  1 22:07:05 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:07:05 +0200
Subject: [GIT PULL 2/6] i.MX SoC update for 5.13
In-Reply-To: <20210331041019.31345-2-shawnguo@kernel.org>
References: <20210331041019.31345-1-shawnguo@kernel.org>
 <20210331041019.31345-2-shawnguo@kernel.org>
Message-ID: <161731121864.663132.16506818644518053696.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 12:10:15 +0800, Shawn Guo wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-5.13
> 
> [...]

Merged into arm/soc, thanks!

merge commit: 4f9c62d1f79c42674e8ba0c4592a438c21fcbf23

       Arnd


From arnd at kernel.org  Thu Apr  1 22:07:06 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:07:06 +0200
Subject: [GIT PULL 3/3] Drop legacy data for dra7 and omap4/5 and clean-up
In-Reply-To: <pull-1617004205-537424@atomide.com-3>
References: <pull-1617004205-537424@atomide.com>
 <pull-1617004205-537424@atomide.com-3>
Message-ID: <161731121857.663132.4089815992350147845.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 29 Mar 2021 10:55:22 +0300, Tony Lindgren wrote:
> The following changes since commit 083516ad540a1104a0ae5ae7e83f2a2d8e39d2bc:
> 
>   Merge tags 'genpd-dts-dra7', 'genpd-dts-omap4' and 'genpd-dts-omap5' into omap-for-v5.13/dts-genpd (2021-03-10 14:16:34 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/genpd-cleanup-signed
> 
> [...]

Merged into arm/soc, thanks!

merge commit: 3e26eccd40f9d4ff43fbd05edaccb96abfab04e8

       Arnd


From arnd at kernel.org  Thu Apr  1 22:08:36 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  1 Apr 2021 23:08:36 +0200
Subject: [GIT PULL] soc: mediatek: changes for v5.13
In-Reply-To: <c47d4bdd-9e05-c0de-bacb-3a262fed936d@gmail.com>
References: <c47d4bdd-9e05-c0de-bacb-3a262fed936d@gmail.com>
Message-ID: <161731130321.663335.9439061446866872029.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Thu, 1 Apr 2021 16:19:45 +0200, Matthias Brugger wrote:
> Below you can find the changes for the SoC drivers. After we fixed in the last
> round the power management domain driver. This time it is the MMSYS driver. Up
> to now it held one big table with routing information for all SoCs. But that's
> not practical over time, so that was splitten up to add only per SoC structures.
> That should make it easier in the future to add support for new SoCs. At least
> one series didn't hit mainline this time, but should be ready for the next round.
> 
> Please take the patches into account for your pull request.
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 3e7f2f2980e82eb20ce73691d65d696c6994ad4c

       Arnd


From lkp at intel.com  Thu Apr  1 22:19:06 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 05:19:06 +0800
Subject: [xlnx:xlnx_rebase_v5.4 864/1701] drivers/fpga/fpga-mgr.c:828:2:
 error: implicit declaration of function 'set_dma_ops'
Message-ID: <202104020502.2GwKJmIr-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 1a0c556193a3d81ff6bde4c571c38b2c19bbb443 [864/1701] fpga: support loading from a pre-allocated buffer
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/1a0c556193a3d81ff6bde4c571c38b2c19bbb443
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 1a0c556193a3d81ff6bde4c571c38b2c19bbb443
        # save the attached .config to linux build tree
        make W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   In file included from include/linux/file.h:9,
                    from include/linux/dma-buf.h:16,
                    from drivers/fpga/fpga-mgr.c:11:
   include/asm-generic/fixmap.h: In function 'fix_to_virt':
   include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |                   ^~
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
     330 |   if (!(condition))     \
         |         ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
      50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
         |  ^~~~~~~~~~~~~~~~
   include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON'
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |  ^~~~~~~~~~~~
   In file included from include/linux/uaccess.h:11,
                    from include/linux/highmem.h:9,
                    from drivers/fpga/fpga-mgr.c:21:
   arch/um/include/asm/uaccess.h: In function '__access_ok':
   arch/um/include/asm/uaccess.h:17:29: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
      17 |    (((unsigned long) (addr) >= FIXADDR_USER_START) && \
         |                             ^~
   arch/um/include/asm/uaccess.h:45:3: note: in expansion of macro '__access_ok_vsyscall'
      45 |   __access_ok_vsyscall(addr, size) ||
         |   ^~~~~~~~~~~~~~~~~~~~
   drivers/fpga/fpga-mgr.c: In function 'fpga_mgr_create':
>> drivers/fpga/fpga-mgr.c:828:2: error: implicit declaration of function 'set_dma_ops' [-Werror=implicit-function-declaration]
     828 |  set_dma_ops(&mgr->dev, get_dma_ops(dev));
         |  ^~~~~~~~~~~
>> drivers/fpga/fpga-mgr.c:828:25: error: implicit declaration of function 'get_dma_ops'; did you mean 'get_dma_buf'? [-Werror=implicit-function-declaration]
     828 |  set_dma_ops(&mgr->dev, get_dma_ops(dev));
         |                         ^~~~~~~~~~~
         |                         get_dma_buf
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +/set_dma_ops +828 drivers/fpga/fpga-mgr.c

   773	
   774	/**
   775	 * fpga_mgr_create - create and initialize a FPGA manager struct
   776	 * @dev:	fpga manager device from pdev
   777	 * @name:	fpga manager name
   778	 * @mops:	pointer to structure of fpga manager ops
   779	 * @priv:	fpga manager private data
   780	 *
   781	 * The caller of this function is responsible for freeing the struct with
   782	 * fpga_mgr_free().  Using devm_fpga_mgr_create() instead is recommended.
   783	 *
   784	 * Return: pointer to struct fpga_manager or NULL
   785	 */
   786	struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
   787					     const struct fpga_manager_ops *mops,
   788					     void *priv)
   789	{
   790		struct fpga_manager *mgr;
   791		int id, ret;
   792	
   793		if (!mops || !mops->write_complete || !mops->state ||
   794		    !mops->write_init || (!mops->write && !mops->write_sg)) {
   795			dev_err(dev, "Attempt to register without fpga_manager_ops\n");
   796			return NULL;
   797		}
   798	
   799		if (!name || !strlen(name)) {
   800			dev_err(dev, "Attempt to register with no name!\n");
   801			return NULL;
   802		}
   803	
   804		mgr = kzalloc(sizeof(*mgr), GFP_KERNEL);
   805		if (!mgr)
   806			return NULL;
   807	
   808		id = ida_simple_get(&fpga_mgr_ida, 0, 0, GFP_KERNEL);
   809		if (id < 0) {
   810			ret = id;
   811			goto error_kfree;
   812		}
   813	
   814		mutex_init(&mgr->ref_mutex);
   815	
   816		mgr->name = name;
   817		mgr->mops = mops;
   818		mgr->priv = priv;
   819	
   820		device_initialize(&mgr->dev);
   821		mgr->dev.class = fpga_mgr_class;
   822		mgr->dev.groups = mops->groups;
   823		mgr->dev.parent = dev;
   824		mgr->dev.of_node = dev->of_node;
   825		mgr->dev.id = id;
   826	
   827		/* Make device dma capable by inheriting from parent's */
 > 828		set_dma_ops(&mgr->dev, get_dma_ops(dev));
   829		ret = dma_coerce_mask_and_coherent(&mgr->dev, dma_get_mask(dev));
   830		if (ret) {
   831			dev_warn(dev,
   832			"Failed to set DMA mask %llx. Trying to continue... %x\n",
   833			dma_get_mask(dev), ret);
   834		}
   835	
   836		ret = dev_set_name(&mgr->dev, "fpga%d", id);
   837		if (ret)
   838			goto error_device;
   839	
   840		mgr->miscdev.minor = MISC_DYNAMIC_MINOR;
   841		mgr->miscdev.name = kobject_name(&mgr->dev.kobj);
   842		mgr->miscdev.fops = &fpga_fops;
   843		ret = misc_register(&mgr->miscdev);
   844		if (ret) {
   845			pr_err("fpga: failed to register misc device.\n");
   846			goto error_device;
   847		}
   848	
   849		return mgr;
   850	
   851	error_device:
   852		ida_simple_remove(&fpga_mgr_ida, id);
   853	error_kfree:
   854		kfree(mgr);
   855	
   856		return NULL;
   857	}
   858	EXPORT_SYMBOL_GPL(fpga_mgr_create);
   859	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 21928 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/c2a4e270/attachment-0001.gz>

From mhiramat at kernel.org  Thu Apr  1 22:21:49 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Fri, 2 Apr 2021 06:21:49 +0900
Subject: [PATCH] arm64/kernel/probes: Use BUG_ON instead of if condition
 followed by BUG.
In-Reply-To: <1617105472-6081-1-git-send-email-zhouchuangao@vivo.com>
References: <1617105472-6081-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <20210402062149.98ad11a0ec940cef86122fc2@kernel.org>

On Tue, 30 Mar 2021 04:57:50 -0700
zhouchuangao <zhouchuangao at vivo.com> wrote:

> It can be optimized at compile time.
> 

Anyway, this seems to make the code simpler.

Reviewed-by: Masami Hiramatsu <mhiramat at kernel.org>

Thanks!

> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
> ---
>  arch/arm64/kernel/probes/kprobes.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 66aac28..ecf0f61 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -264,8 +264,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
>  		 * normal page fault.
>  		 */
>  		instruction_pointer_set(regs, (unsigned long) cur->addr);
> -		if (!instruction_pointer(regs))
> -			BUG();
> +		BUG_ON(!instruction_pointer(regs));
>  
>  		if (kcb->kprobe_status == KPROBE_REENTER)
>  			restore_previous_kprobe(kcb);
> -- 
> 2.7.4
> 


-- 
Masami Hiramatsu <mhiramat at kernel.org>


From jim2101024 at gmail.com  Thu Apr  1 22:21:40 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:40 -0400
Subject: [PATCH v4 0/6] PCI: brcmstb: add slot0 device regulators and panic
 handler
Message-ID: <20210401212148.47033-1-jim2101024@gmail.com>

v4 [NOTE: I'm not sure this fixes RobH and MarkB constraints but I'd
          like to use this pullreq as a basis for future discussion.]
   [Commit: Add bindings for ...]
     -- Fix syntax error in YAML bindings example (RobH)
     -- {vpcie12v,vpcie3v3}-supply props are back in root complex DT node
        (I believe RobH said this was okay)
   [Commit: Add control of ..]
     -- Do not do global search for regulator; now we look specifically
        for the property {vpcie12v,vpcie3v3}-supply in the root complex
	DT node and then call devm_regulator_bulk_get() (MarkB)
     -- Use devm_regulator_bulk_get() (Bjorn)
     -- s/EP/slot0 device/ (Bjorn)
     -- Spelling, capitalization (Bjorn)
     -- Have brcm_phy_stop() return a void (Bjorn)
   [Commit: Do not turn off ...]
     -- Capitalization (Bjorn)
   [Commit: Check return value ...]
     -- Commit message content (Bjorn)
     -- Move 6/6 hunk to 2/6 where it belongs (Bjorn)
     -- Move the rest of 6/6 before all other commits (Bjorn)

v3 -- Driver now searches for EP DT subnode for any regulators to turn on.
      If present, these regulators have the property names
      "vpcie12v-supply" and "vpcie3v3-supply".  The existence of these
      regulators in the EP subnode are currently pending as a pullreq
      in pci-bus.yaml at
      https://github.com/devicetree-org/dt-schema/pull/54
      (MarkB, RobH).
   -- Check return of brcm_set_regulators() (Florian)
   -- Specify one regulator string per line for easier update (Florian)
   -- Author/Committer/Signoff email changed from that of V2 from
      'james.quinlan at broadcom.com' to 'jim2101024 at gmail.com'.

v2 -- Use regulator bulk API rather than multiple calls (MarkB).

v1 -- Bindings are added for fixed regulators that may power the EP device.
   -- The brcmstb RC driver is modified to control these regulators
      during probe, suspend, and resume.
   -- 7216 type SOCs have additional error reporting HW and a
      panic handler is added to dump its info.
   -- A missing return value check is added.



Jim Quinlan (6):
  PCI: brcmstb: Check return value of clk_prepare_enable()
  dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage
    regulators
  PCI: brcmstb: Add control of slot0 device voltage regulators
  PCI: brcmstb: Do not turn off regulators if EP can wake up
  PCI: brcmstb: Give 7216 SOCs their own config type
  PCI: brcmstb: Add panic/die handler to RC driver

 .../bindings/pci/brcm,stb-pcie.yaml           |   4 +
 drivers/pci/controller/pcie-brcmstb.c         | 262 +++++++++++++++++-
 2 files changed, 259 insertions(+), 7 deletions(-)

-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:46 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:46 -0400
Subject: [PATCH v4 6/6] PCI: brcmstb: Add panic/die handler to RC driver
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-7-jim2101024@gmail.com>

Whereas most PCIe HW returns 0xffffffff on illegal accesses and the like,
by default Broadcom's STB PCIe controller effects an abort.  This simple
handler determines if the PCIe controller was the cause of the abort and if
so, prints out diagnostic info.

Example output:
  brcm-pcie 8b20000.pcie: Error: Mem Acc: 32bit, Read, @0x38000000
  brcm-pcie 8b20000.pcie:  Type: TO=0 Abt=0 UnspReq=1 AccDsble=0 BadAddr=0

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 122 ++++++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 44128df33785..73a12c62b94e 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -12,11 +12,13 @@
 #include <linux/ioport.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqdomain.h>
+#include <linux/kdebug.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/log2.h>
 #include <linux/module.h>
 #include <linux/msi.h>
+#include <linux/notifier.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/of_pci.h>
@@ -186,6 +188,39 @@
 #define  PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK		0x1
 #define  PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT		0x0
 
+/* Error report regiseters */
+#define PCIE_OUTB_ERR_TREAT				0x6000
+#define  PCIE_OUTB_ERR_TREAT_CONFIG_MASK		0x1
+#define  PCIE_OUTB_ERR_TREAT_MEM_MASK			0x2
+#define PCIE_OUTB_ERR_VALID				0x6004
+#define PCIE_OUTB_ERR_CLEAR				0x6008
+#define PCIE_OUTB_ERR_ACC_INFO				0x600c
+#define  PCIE_OUTB_ERR_ACC_INFO_CFG_ERR_MASK		0x01
+#define  PCIE_OUTB_ERR_ACC_INFO_MEM_ERR_MASK		0x02
+#define  PCIE_OUTB_ERR_ACC_INFO_TYPE_64_MASK		0x04
+#define  PCIE_OUTB_ERR_ACC_INFO_DIR_WRITE_MASK		0x10
+#define  PCIE_OUTB_ERR_ACC_INFO_BYTE_LANES_MASK		0xff00
+#define PCIE_OUTB_ERR_ACC_ADDR				0x6010
+#define PCIE_OUTB_ERR_ACC_ADDR_BUS_MASK			0xff00000
+#define PCIE_OUTB_ERR_ACC_ADDR_DEV_MASK			0xf8000
+#define PCIE_OUTB_ERR_ACC_ADDR_FUNC_MASK		0x7000
+#define PCIE_OUTB_ERR_ACC_ADDR_REG_MASK			0xfff
+#define PCIE_OUTB_ERR_CFG_CAUSE				0x6014
+#define  PCIE_OUTB_ERR_CFG_CAUSE_TIMEOUT_MASK		0x40
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ABORT_MASK		0x20
+#define  PCIE_OUTB_ERR_CFG_CAUSE_UNSUPP_REQ_MASK	0x10
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_TIMEOUT_MASK	0x4
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_DISABLED_MASK	0x2
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_64BIT__MASK	0x1
+#define PCIE_OUTB_ERR_MEM_ADDR_LO			0x6018
+#define PCIE_OUTB_ERR_MEM_ADDR_HI			0x601c
+#define PCIE_OUTB_ERR_MEM_CAUSE				0x6020
+#define  PCIE_OUTB_ERR_MEM_CAUSE_TIMEOUT_MASK		0x40
+#define  PCIE_OUTB_ERR_MEM_CAUSE_ABORT_MASK		0x20
+#define  PCIE_OUTB_ERR_MEM_CAUSE_UNSUPP_REQ_MASK	0x10
+#define  PCIE_OUTB_ERR_MEM_CAUSE_ACC_DISABLED_MASK	0x2
+#define  PCIE_OUTB_ERR_MEM_CAUSE_BAD_ADDR_MASK		0x1
+
 /* Forward declarations */
 struct brcm_pcie;
 static inline void brcm_pcie_bridge_sw_init_set_7278(struct brcm_pcie *pcie, u32 val);
@@ -223,6 +258,7 @@ struct pcie_cfg_data {
 	const enum pcie_type type;
 	void (*perst_set)(struct brcm_pcie *pcie, u32 val);
 	void (*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
+	const bool has_err_report;
 };
 
 static const int pcie_offsets[] = {
@@ -270,6 +306,7 @@ static const struct pcie_cfg_data bcm7216_cfg = {
 	.type		= BCM7278,
 	.perst_set	= brcm_pcie_perst_set_7278,
 	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
+	.has_err_report = true,
 };
 
 struct brcm_msi {
@@ -313,8 +350,87 @@ struct brcm_pcie {
 	struct regulator_bulk_data supplies[PCIE_BRCM_MAX_EP_REGULATORS];
 	unsigned int		num_supplies;
 	bool			ep_wakeup_capable;
+	bool			has_err_report;
+	struct notifier_block	die_notifier;
 };
 
+/* Dump out PCIe errors on die or panic */
+static int dump_pcie_error(struct notifier_block *self, unsigned long v, void *p)
+{
+	const struct brcm_pcie *pcie = container_of(self, struct brcm_pcie, die_notifier);
+	void __iomem *base = pcie->base;
+	int i, is_cfg_err, is_mem_err, lanes;
+	char *width_str, *direction_str, lanes_str[9];
+	u32 info;
+
+	if (readl(base + PCIE_OUTB_ERR_VALID) == 0)
+		return NOTIFY_DONE;
+	info = readl(base + PCIE_OUTB_ERR_ACC_INFO);
+
+
+	is_cfg_err = !!(info & PCIE_OUTB_ERR_ACC_INFO_CFG_ERR_MASK);
+	is_mem_err = !!(info & PCIE_OUTB_ERR_ACC_INFO_MEM_ERR_MASK);
+	width_str = (info & PCIE_OUTB_ERR_ACC_INFO_TYPE_64_MASK) ? "64bit" : "32bit";
+	direction_str = (info & PCIE_OUTB_ERR_ACC_INFO_DIR_WRITE_MASK) ? "Write" : "Read";
+	lanes = FIELD_GET(PCIE_OUTB_ERR_ACC_INFO_BYTE_LANES_MASK, info);
+	for (i = 0, lanes_str[8] = 0; i < 8; i++)
+		lanes_str[i] = (lanes & (1 << i)) ? '1' : '0';
+
+	if (is_cfg_err) {
+		u32 cfg_addr = readl(base + PCIE_OUTB_ERR_ACC_ADDR);
+		u32 cause = readl(base + PCIE_OUTB_ERR_CFG_CAUSE);
+		int bus = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_BUS_MASK, cfg_addr);
+		int dev = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_DEV_MASK, cfg_addr);
+		int func = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_FUNC_MASK, cfg_addr);
+		int reg = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_REG_MASK, cfg_addr);
+
+		dev_err(pcie->dev, "Error: CFG Acc, %s, %s, Bus=%d, Dev=%d, Fun=%d, Reg=0x%x, lanes=%s\n",
+			width_str, direction_str, bus, dev, func, reg, lanes_str);
+		dev_err(pcie->dev, " Type: TO=%d Abt=%d UnsupReq=%d AccTO=%d AccDsbld=%d Acc64bit=%d\n",
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ABORT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_UNSUPP_REQ_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_DISABLED_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_64BIT__MASK));
+	}
+
+	if (is_mem_err) {
+		u32 cause = readl(base + PCIE_OUTB_ERR_MEM_CAUSE);
+		u32 lo = readl(base + PCIE_OUTB_ERR_MEM_ADDR_LO);
+		u32 hi = readl(base + PCIE_OUTB_ERR_MEM_ADDR_HI);
+		u64 addr = ((u64)hi << 32) | (u64)lo;
+
+		dev_err(pcie->dev, "Error: Mem Acc, %s, %s, @0x%llx, lanes=%s\n",
+			width_str, direction_str, addr, lanes_str);
+		dev_err(pcie->dev, " Type: TO=%d Abt=%d UnsupReq=%d AccDsble=%d BadAddr=%d\n",
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_ABORT_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_UNSUPP_REQ_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_ACC_DISABLED_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_BAD_ADDR_MASK));
+	}
+
+	/* Clear the error */
+	writel(1, base + PCIE_OUTB_ERR_CLEAR);
+
+	return NOTIFY_DONE;
+}
+
+static void brcm_register_die_notifiers(struct brcm_pcie *pcie)
+{
+	pcie->die_notifier.notifier_call = dump_pcie_error;
+	register_die_notifier(&pcie->die_notifier);
+	atomic_notifier_chain_register(&panic_notifier_list, &pcie->die_notifier);
+}
+
+static void brcm_unregister_die_notifiers(struct brcm_pcie *pcie)
+{
+	unregister_die_notifier(&pcie->die_notifier);
+	atomic_notifier_chain_unregister(&panic_notifier_list, &pcie->die_notifier);
+	pcie->die_notifier.notifier_call = NULL;
+}
+
 static int pci_dev_may_wakeup(struct pci_dev *dev, void *data)
 {
 	bool *ret = data;
@@ -1321,6 +1437,8 @@ static int brcm_pcie_remove(struct platform_device *pdev)
 	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
 
 	pci_stop_root_bus(bridge->bus);
+	if (pcie->has_err_report)
+		brcm_unregister_die_notifiers(pcie);
 	pci_remove_root_bus(bridge->bus);
 	__brcm_pcie_remove(pcie);
 
@@ -1360,6 +1478,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 	pcie->np = np;
 	pcie->reg_offsets = data->offsets;
 	pcie->type = data->type;
+	pcie->has_err_report = data->has_err_report;
 	pcie->perst_set = data->perst_set;
 	pcie->bridge_sw_init_set = data->bridge_sw_init_set;
 
@@ -1439,6 +1558,9 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, pcie);
 
+	if (pcie->has_err_report)
+		brcm_register_die_notifiers(pcie);
+
 	return pci_host_probe(bridge);
 fail:
 	__brcm_pcie_remove(pcie);
-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:41 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:41 -0400
Subject: [PATCH v4 1/6] PCI: brcmstb: Check return value of
 clk_prepare_enable()
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-2-jim2101024@gmail.com>

Check for failure of clk_prepare_enable() on device resume.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
Fixes: 8195b7417018 ("PCI: brcmstb: Add suspend and resume pm_ops")
---
 drivers/pci/controller/pcie-brcmstb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index e330e6811f0b..4ce1f3a60574 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1161,7 +1161,9 @@ static int brcm_pcie_resume(struct device *dev)
 	int ret;
 
 	base = pcie->base;
-	clk_prepare_enable(pcie->clk);
+	ret = clk_prepare_enable(pcie->clk);
+	if (ret)
+		return ret;
 
 	ret = brcm_phy_start(pcie);
 	if (ret)
-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:43 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:43 -0400
Subject: [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 device voltage
 regulators
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-4-jim2101024@gmail.com>

This Broadcom STB has one port and connects directly to one device, be it a
switch or an endpoint.  We want to be able to turn on/off any regulators
for that device.  Control of regulators is needed because of the
chicken-and-egg situation: although the regulator is "owned" by the device
and would be best handled by its driver, the device cannot be discovered
and probed unless its regulator is already turned on.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 83 +++++++++++++++++++++++++--
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 4ce1f3a60574..1b0de0c7da60 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -24,6 +24,7 @@
 #include <linux/pci.h>
 #include <linux/pci-ecam.h>
 #include <linux/printk.h>
+#include <linux/regulator/consumer.h>
 #include <linux/reset.h>
 #include <linux/sizes.h>
 #include <linux/slab.h>
@@ -169,6 +170,7 @@
 #define SSC_STATUS_SSC_MASK		0x400
 #define SSC_STATUS_PLL_LOCK_MASK	0x800
 #define PCIE_BRCM_MAX_MEMC		3
+#define PCIE_BRCM_MAX_EP_REGULATORS	4
 
 #define IDX_ADDR(pcie)			(pcie->reg_offsets[EXT_CFG_INDEX])
 #define DATA_ADDR(pcie)			(pcie->reg_offsets[EXT_CFG_DATA])
@@ -192,6 +194,11 @@ static inline void brcm_pcie_perst_set_4908(struct brcm_pcie *pcie, u32 val);
 static inline void brcm_pcie_perst_set_7278(struct brcm_pcie *pcie, u32 val);
 static inline void brcm_pcie_perst_set_generic(struct brcm_pcie *pcie, u32 val);
 
+static const char * const supplies[] = {
+	"vpcie12v-supply",
+	"vpcie3v3-supply",
+};
+
 enum {
 	RGR1_SW_INIT_1,
 	EXT_CFG_INDEX,
@@ -295,8 +302,27 @@ struct brcm_pcie {
 	u32			hw_rev;
 	void			(*perst_set)(struct brcm_pcie *pcie, u32 val);
 	void			(*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
+	struct regulator_bulk_data supplies[PCIE_BRCM_MAX_EP_REGULATORS];
+	unsigned int		num_supplies;
 };
 
+static int brcm_set_regulators(struct brcm_pcie *pcie, bool on)
+{
+	struct device *dev = pcie->dev;
+	int ret;
+
+	if (!pcie->num_supplies)
+		return 0;
+	if (on)
+		ret = regulator_bulk_enable(pcie->num_supplies, pcie->supplies);
+	else
+		ret = regulator_bulk_disable(pcie->num_supplies, pcie->supplies);
+	if (ret)
+		dev_err(dev, "failed to %s EP regulators\n",
+			on ? "enable" : "disable");
+	return ret;
+}
+
 /*
  * This is to convert the size of the inbound "BAR" region to the
  * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
@@ -1112,9 +1138,10 @@ static inline int brcm_phy_start(struct brcm_pcie *pcie)
 	return pcie->rescal ? brcm_phy_cntl(pcie, 1) : 0;
 }
 
-static inline int brcm_phy_stop(struct brcm_pcie *pcie)
+static inline void brcm_phy_stop(struct brcm_pcie *pcie)
 {
-	return pcie->rescal ? brcm_phy_cntl(pcie, 0) : 0;
+	if (pcie->rescal)
+		brcm_phy_cntl(pcie, 0);
 }
 
 static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
@@ -1141,16 +1168,45 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
 	pcie->bridge_sw_init_set(pcie, 1);
 }
 
+static int brcm_pcie_get_regulators(struct brcm_pcie *pcie)
+{
+	struct device_node *np = pcie->np;
+	struct property *pp;
+	const unsigned int ns = ARRAY_SIZE(supplies);
+	unsigned int i;
+	int ret = 0;
+
+	/* Look for specific pcie regulators in the RC DT node. */
+	for_each_property_of_node(np, pp) {
+		for (i = 0; i < ns; i++)
+			if (strcmp(supplies[i], pp->name) == 0)
+				break;
+		if (i >= ns)
+			continue;
+
+		if (pcie->num_supplies < PCIE_BRCM_MAX_EP_REGULATORS)
+			pcie->supplies[pcie->num_supplies++].supply
+				= supplies[i];
+		else
+			dev_warn(pcie->dev, "No room for supply %s\n",
+				 supplies[i]);
+	}
+
+	if (pcie->num_supplies)
+		ret = devm_regulator_bulk_get(pcie->dev, pcie->num_supplies,
+					      pcie->supplies);
+	return ret;
+}
+
 static int brcm_pcie_suspend(struct device *dev)
 {
 	struct brcm_pcie *pcie = dev_get_drvdata(dev);
-	int ret;
 
 	brcm_pcie_turn_off(pcie);
-	ret = brcm_phy_stop(pcie);
+	brcm_phy_stop(pcie);
 	clk_disable_unprepare(pcie->clk);
 
-	return ret;
+	return brcm_set_regulators(pcie, false);
 }
 
 static int brcm_pcie_resume(struct device *dev)
@@ -1165,6 +1221,10 @@ static int brcm_pcie_resume(struct device *dev)
 	if (ret)
 		return ret;
 
+	ret = brcm_set_regulators(pcie, true);
+	if (ret)
+		return ret;
+
 	ret = brcm_phy_start(pcie);
 	if (ret)
 		goto err;
@@ -1201,6 +1261,7 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
 	brcm_phy_stop(pcie);
 	reset_control_assert(pcie->rescal);
 	clk_disable_unprepare(pcie->clk);
+	brcm_set_regulators(pcie, false);
 }
 
 static int brcm_pcie_remove(struct platform_device *pdev)
@@ -1291,6 +1352,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	ret = brcm_pcie_get_regulators(pcie);
+	if (ret) {
+		pcie->num_supplies = 0;
+		if (ret != -EPROBE_DEFER)
+			dev_err(pcie->dev, "failed to get regulators (err=%d)\n", ret);
+		goto fail;
+	}
+
+	ret = brcm_set_regulators(pcie, true);
+	if (ret)
+		goto fail;
+
 	ret = brcm_pcie_setup(pcie);
 	if (ret)
 		goto fail;
-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:45 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:45 -0400
Subject: [PATCH v4 5/6] PCI: brcmstb: Give 7216 SOCs their own config type
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-6-jim2101024@gmail.com>

This distinction is required for an imminent commit.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 4c79aff66de7..44128df33785 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -265,6 +265,13 @@ static const struct pcie_cfg_data bcm2711_cfg = {
 	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
 };
 
+static const struct pcie_cfg_data bcm7216_cfg = {
+	.offsets	= pcie_offset_bcm7278,
+	.type		= BCM7278,
+	.perst_set	= brcm_pcie_perst_set_7278,
+	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
+};
+
 struct brcm_msi {
 	struct device		*dev;
 	void __iomem		*base;
@@ -1325,7 +1332,7 @@ static const struct of_device_id brcm_pcie_match[] = {
 	{ .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
 	{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
 	{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
-	{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
+	{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7216_cfg },
 	{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
 	{},
 };
-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:44 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:44 -0400
Subject: [PATCH v4 4/6] PCI: brcmstb: Do not turn off regulators if EP can
 wake up
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-5-jim2101024@gmail.com>

If any downstream device may wake up during S2/S3 suspend, we do not want
to turn off its power when suspending.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 58 +++++++++++++++++++++++----
 1 file changed, 51 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 1b0de0c7da60..4c79aff66de7 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -193,6 +193,7 @@ static inline void brcm_pcie_bridge_sw_init_set_generic(struct brcm_pcie *pcie,
 static inline void brcm_pcie_perst_set_4908(struct brcm_pcie *pcie, u32 val);
 static inline void brcm_pcie_perst_set_7278(struct brcm_pcie *pcie, u32 val);
 static inline void brcm_pcie_perst_set_generic(struct brcm_pcie *pcie, u32 val);
+static bool brcm_pcie_link_up(struct brcm_pcie *pcie);
 
 static const char * const supplies[] = {
 	"vpcie12v-supply",
@@ -304,22 +305,65 @@ struct brcm_pcie {
 	void			(*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
 	struct regulator_bulk_data supplies[PCIE_BRCM_MAX_EP_REGULATORS];
 	unsigned int		num_supplies;
+	bool			ep_wakeup_capable;
 };
 
-static int brcm_set_regulators(struct brcm_pcie *pcie, bool on)
+static int pci_dev_may_wakeup(struct pci_dev *dev, void *data)
 {
+	bool *ret = data;
+
+	if (device_may_wakeup(&dev->dev)) {
+		*ret = true;
+		dev_dbg(&dev->dev, "disable cancelled for wake-up device\n");
+	}
+	return (int) *ret;
+}
+
+enum {
+	TURN_OFF,		/* Turn regulators off, unless an EP is wakeup-capable */
+	TURN_OFF_ALWAYS,	/* Turn regulators off, no exceptions */
+	TURN_ON,		/* Turn regulators on, unless pcie->ep_wakeup_capable */
+};
+
+static int brcm_set_regulators(struct brcm_pcie *pcie, int how)
+{
+	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
 	struct device *dev = pcie->dev;
 	int ret;
 
 	if (!pcie->num_supplies)
 		return 0;
-	if (on)
+	if (how == TURN_ON) {
+		if (pcie->ep_wakeup_capable) {
+			/*
+			 * We are resuming from a suspend.  In the
+			 * previous suspend we did not disable the power
+			 * supplies, so there is no need to enable them
+			 * (and falsely increase their usage count).
+			 */
+			pcie->ep_wakeup_capable = false;
+			return 0;
+		}
+	} else if (how == TURN_OFF) {
+		/*
+		 * If at least one device on this bus is enabled as a
+		 * wake-up source, do not turn off regulators.
+		 */
+		pcie->ep_wakeup_capable = false;
+		if (bridge->bus && brcm_pcie_link_up(pcie)) {
+			pci_walk_bus(bridge->bus, pci_dev_may_wakeup, &pcie->ep_wakeup_capable);
+			if (pcie->ep_wakeup_capable)
+				return 0;
+		}
+	}
+
+	if (how == TURN_ON)
 		ret = regulator_bulk_enable(pcie->num_supplies, pcie->supplies);
 	else
 		ret = regulator_bulk_disable(pcie->num_supplies, pcie->supplies);
 	if (ret)
 		dev_err(dev, "failed to %s EP regulators\n",
-			on ? "enable" : "disable");
+			how == TURN_ON ? "enable" : "disable");
 	return ret;
 }
 
@@ -1206,7 +1250,7 @@ static int brcm_pcie_suspend(struct device *dev)
 	brcm_phy_stop(pcie);
 	clk_disable_unprepare(pcie->clk);
 
-	return brcm_set_regulators(pcie, false);
+	return brcm_set_regulators(pcie, TURN_OFF);
 }
 
 static int brcm_pcie_resume(struct device *dev)
@@ -1221,7 +1265,7 @@ static int brcm_pcie_resume(struct device *dev)
 	if (ret)
 		return ret;
 
-	ret = brcm_set_regulators(pcie, true);
+	ret = brcm_set_regulators(pcie, TURN_ON);
 	if (ret)
 		return ret;
 
@@ -1261,7 +1305,7 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
 	brcm_phy_stop(pcie);
 	reset_control_assert(pcie->rescal);
 	clk_disable_unprepare(pcie->clk);
-	brcm_set_regulators(pcie, false);
+	brcm_set_regulators(pcie, TURN_OFF_ALWAYS);
 }
 
 static int brcm_pcie_remove(struct platform_device *pdev)
@@ -1360,7 +1404,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 		goto fail;
 	}
 
-	ret = brcm_set_regulators(pcie, true);
+	ret = brcm_set_regulators(pcie, TURN_ON);
 	if (ret)
 		goto fail;
 
-- 
2.17.1



From jim2101024 at gmail.com  Thu Apr  1 22:21:42 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu,  1 Apr 2021 17:21:42 -0400
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint
 device voltage regulators
In-Reply-To: <20210401212148.47033-1-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
Message-ID: <20210401212148.47033-3-jim2101024@gmail.com>

Similar to the regulator bindings found in "rockchip-pcie-host.txt", this
allows optional regulators to be attached and controlled by the PCIe RC
driver.  That being said, this driver searches in the DT subnode (the EP
node, eg pci at 0,0) for the regulator property.

The use of a regulator property in the pcie EP subnode such as
"vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml
file at

https://github.com/devicetree-org/dt-schema/pull/54

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
---
 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index f90557f6deb8..f2caa5b3b281 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -64,6 +64,9 @@ properties:
 
   aspm-no-l0s: true
 
+  vpcie12v-supply: true
+  vpcie3v3-supply: true
+
   brcm,scb-sizes:
     description: u64 giving the 64bit PCIe memory
       viewport size of a memory controller.  There may be up to
@@ -156,5 +159,6 @@ examples:
                                  <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
                     brcm,enable-ssc;
                     brcm,scb-sizes =  <0x0000000080000000 0x0000000080000000>;
+                    vpcie12v-supply = <&vreg12>;
             };
     };
-- 
2.17.1



From jbx6244 at gmail.com  Thu Apr  1 22:36:50 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu,  1 Apr 2021 23:36:50 +0200
Subject: [PATCH v6 2/4] arm64: dts: rockchip: optimize clks for rk3399 dwc3
In-Reply-To: <20210401213652.14676-1-jbx6244@gmail.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
Message-ID: <20210401213652.14676-3-jbx6244@gmail.com>

From: Wu Liang feng <wulf at rock-chips.com>

Remove unnecessary clocks, refer to rk3399 TRM, aclk_usb3 is the
parent of aclk_usb3otg0/1 and aclk_usb3_grf, and we will enable
aclk_usb3otg0/1 and aclk_usb3_grf, so don't need to enable aclk_usb3
again. In addition, the aclk_usb3_rksoc_axi_perf clk is used for usb3
performance monitor module which we don't use now, so don't need to
enable it.

Signed-off-by: Wu Liang feng <wulf at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e93a5f320..186a7c483 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -370,11 +370,9 @@
 		#size-cells = <2>;
 		ranges;
 		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
-			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
-			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
 		clock-names = "ref_clk", "suspend_clk",
-			      "bus_clk", "aclk_usb3_rksoc_axi_perf",
-			      "aclk_usb3", "grf_clk";
+			      "bus_clk", "grf_clk";
 		resets = <&cru SRST_A_USB3_OTG0>;
 		reset-names = "usb3-otg";
 		status = "disabled";
@@ -406,11 +404,9 @@
 		#size-cells = <2>;
 		ranges;
 		clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
-			 <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
-			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+			 <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
 		clock-names = "ref_clk", "suspend_clk",
-			      "bus_clk", "aclk_usb3_rksoc_axi_perf",
-			      "aclk_usb3", "grf_clk";
+			      "bus_clk", "grf_clk";
 		resets = <&cru SRST_A_USB3_OTG1>;
 		reset-names = "usb3-otg";
 		status = "disabled";
-- 
2.11.0



From jbx6244 at gmail.com  Thu Apr  1 22:36:49 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu,  1 Apr 2021 23:36:49 +0200
Subject: [PATCH v6 1/4] usb: dwc3: of-simple: bail probe if no dwc3 child node
In-Reply-To: <20210401213652.14676-1-jbx6244@gmail.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
Message-ID: <20210401213652.14676-2-jbx6244@gmail.com>

For some of the dwc3-of-simple compatible SoCs we
don't want to bind this driver to a dwc3 node,
but bind that node to the 'snps,dwc3' driver instead.
The kernel has no logic to decide which driver to bind
to if there are 2 matching drivers, so bail probe if no
dwc3 child node.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 drivers/usb/dwc3/dwc3-of-simple.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c b/drivers/usb/dwc3/dwc3-of-simple.c
index 71fd620c5..8d3baa5df 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -38,6 +38,10 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
 
 	int			ret;
 
+	/* Bail probe if no dwc3 child node. */
+	if (!of_get_compatible_child(dev->of_node, "snps,dwc3"))
+		return -ENODEV;
+
 	simple = devm_kzalloc(dev, sizeof(*simple), GFP_KERNEL);
 	if (!simple)
 		return -ENOMEM;
-- 
2.11.0



From jbx6244 at gmail.com  Thu Apr  1 22:36:48 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu,  1 Apr 2021 23:36:48 +0200
Subject: [PATCH v6 0/4] convert rockchip,dwc3.txt to yaml
Message-ID: <20210401213652.14676-1-jbx6244@gmail.com>

The conversion of rockchip,dwc3.txt to yaml was added to linux-next,
but the necessary changes for rk3399 are still pending.

For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
so that was removed in the YAML example.

Now dtbs_check still generates notifications for the compatibility string in
the dts files that doesn't match, because it changed from
"rockchip,rk3399-dwc3" to "rockchip,rk3399-dwc3", "snps,dwc3".

The problem is to keep compatible with old device trees.
I.e. a device running an older device tree should still work with newer
kernels.

Comment by Rob in version 3:
Presumably you are getting lucky here (with link order). The kernel
has no logic to decide which driver to bind to if there are 2 matching
drivers. If we did, it would probably be the opposite of what you want
here as we'd pick the most specific match. This driver should probably
bail probe if no dwc3 child node.

Please advise how to move forward with this serie.

Changed V6:
  rebase
  remove accepted patches from serie

Changed V5:
  add select

Changed V4:
  removed patch "of-simple: add compatible for rk3328"
  add patch "of-simple: bail probe if no dwc3 child node"

Changed V3:
  remove aclk_usb3_rksoc_axi_perf
  remove aclk_usb3

Changed V2:
  remove node wrapper

Johan Jonker (3):
  usb: dwc3: of-simple: bail probe if no dwc3 child node
  arm64: dts: rockchip: restyle rk3399 usbdrd3_0 node
  arm64: dts: rockchip: restyle rk3399 usbdrd3_1 node

Wu Liang feng (1):
  arm64: dts: rockchip: optimize clks for rk3399 dwc3

 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts      |  4 +-
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    | 12 +--
 .../boot/dts/rockchip/rk3399-gru-chromebook.dtsi   |  6 +-
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |  6 +-
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 12 +--
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      | 12 +--
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  | 12 +--
 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |  8 --
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   | 12 +--
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |  8 --
 .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts |  4 -
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |  6 +-
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    | 10 +--
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 12 +--
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dts    |  4 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |  8 --
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 12 +--
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  | 12 +--
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 86 ++++++++--------------
 .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |  4 -
 drivers/usb/dwc3/dwc3-of-simple.c                  |  4 +
 22 files changed, 59 insertions(+), 197 deletions(-)

-- 
2.11.0



From jbx6244 at gmail.com  Thu Apr  1 22:36:52 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu,  1 Apr 2021 23:36:52 +0200
Subject: [PATCH v6 4/4] arm64: dts: rockchip: restyle rk3399 usbdrd3_1 node
In-Reply-To: <20210401213652.14676-1-jbx6244@gmail.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
Message-ID: <20210401213652.14676-5-jbx6244@gmail.com>

For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
so restyle the rk3399 usbdrd3_1 node before more new SoC types are
added with the same IP.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V3:
  remove aclk_usb3_rksoc_axi_perf
  remove aclk_usb3
---
 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    |  6 +---
 .../boot/dts/rockchip/rk3399-gru-chromebook.dtsi   |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts |  6 +---
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   |  6 +---
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dts    |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 37 ++++++++--------------
 17 files changed, 26 insertions(+), 93 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 95110d065..4392780db 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -157,7 +157,7 @@
 	dr_mode = "host";
 };
 
-&usbdrd_dwc3_1 {
+&usbdrd3_1 {
 	dr_mode = "host";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 4017b0e8c..28e5895de 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -778,12 +778,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
index 1384dabbd..c996c688d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
@@ -351,13 +351,9 @@ ap_i2c_tp: &i2c5 {
 };
 
 &usbdrd3_1 {
-	status = "okay";
+	dr_mode = "host";
 	extcon = <&usbc_extcon1>;
-};
-
-&usbdrd_dwc3_1 {
 	status = "okay";
-	dr_mode = "host";
 };
 
 &pinctrl {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
index daf14f732..397050703 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
@@ -736,12 +736,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
index d028285fb..30e6e3e41 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -802,12 +802,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
index 1c0b48a71..a7092fda3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -616,12 +616,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 01c15c833..6605d0bcb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -711,10 +711,6 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
 	dr_mode = "host";
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
index 7b633622c..fdc027ff3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
@@ -859,12 +859,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index f00e11075..80ac8ab6a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -1091,10 +1091,6 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
 	dr_mode = "host";
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
index 6ae9032d8..542980344 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi
@@ -466,12 +466,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usb_host1_ehci {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
index 4d30c1b32..f15f85162 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
@@ -793,12 +793,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
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 69c067dd1..f07f49f45 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -673,12 +673,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
index df4119441..bb110c456 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
@@ -143,7 +143,7 @@
 	dr_mode = "otg";
 };
 
-&usbdrd_dwc3_1 {
+&usbdrd3_1 {
 	dr_mode = "host";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index 3920dcbd1..b5f23661e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -639,10 +639,6 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_1 {
-	status = "okay";
-};
-
 &vopb {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index f119fc41f..a8e5d9e02 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -835,12 +835,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 2e76f178e..fe9d4b2f8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -619,12 +619,8 @@
 };
 
 &usbdrd3_1 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_1 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index deac8f8e5..497df16cc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -388,37 +388,26 @@
 	};
 
 	usbdrd3_1: usb at fe900000 {
-		compatible = "rockchip,rk3399-dwc3";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
+		compatible = "rockchip,rk3399-dwc3", "snps,dwc3";
+		reg = <0x0 0xfe900000 0x0 0x100000>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
 		clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
 			 <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
 		clock-names = "ref_clk", "suspend_clk",
 			      "bus_clk", "grf_clk";
+		dr_mode = "otg";
+		phys = <&u2phy1_otg>, <&tcphy1_usb3>;
+		phy-names = "usb2-phy", "usb3-phy";
+		phy_type = "utmi_wide";
+		power-domains = <&power RK3399_PD_USB3>;
 		resets = <&cru SRST_A_USB3_OTG1>;
 		reset-names = "usb3-otg";
+		snps,dis-del-phy-power-chg-quirk;
+		snps,dis_enblslpm_quirk;
+		snps,dis-tx-ipgap-linecheck-quirk;
+		snps,dis-u2-freeclk-exists-quirk;
+		snps,dis_u2_susphy_quirk;
 		status = "disabled";
-
-		usbdrd_dwc3_1: usb at fe900000 {
-			compatible = "snps,dwc3";
-			reg = <0x0 0xfe900000 0x0 0x100000>;
-			interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
-			clocks = <&cru SCLK_USB3OTG1_REF>, <&cru ACLK_USB3OTG1>,
-				 <&cru SCLK_USB3OTG1_SUSPEND>;
-			clock-names = "ref", "bus_early", "suspend";
-			dr_mode = "otg";
-			phys = <&u2phy1_otg>, <&tcphy1_usb3>;
-			phy-names = "usb2-phy", "usb3-phy";
-			phy_type = "utmi_wide";
-			snps,dis_enblslpm_quirk;
-			snps,dis-u2-freeclk-exists-quirk;
-			snps,dis_u2_susphy_quirk;
-			snps,dis-del-phy-power-chg-quirk;
-			snps,dis-tx-ipgap-linecheck-quirk;
-			power-domains = <&power RK3399_PD_USB3>;
-			status = "disabled";
-		};
 	};
 
 	cdn_dp: dp at fec00000 {
-- 
2.11.0



From jbx6244 at gmail.com  Thu Apr  1 22:36:51 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu,  1 Apr 2021 23:36:51 +0200
Subject: [PATCH v6 3/4] arm64: dts: rockchip: restyle rk3399 usbdrd3_0 node
In-Reply-To: <20210401213652.14676-1-jbx6244@gmail.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
Message-ID: <20210401213652.14676-4-jbx6244@gmail.com>

For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
so restyle the rk3399 usbdrd3_0 node before more new SoC types are
added with the same IP.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V6:
  rebase

Changed V3:
  remove aclk_usb3_rksoc_axi_perf
  remove aclk_usb3
---
 arch/arm64/boot/dts/rockchip/rk3399-ficus.dts      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts |  6 +---
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   |  6 +---
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |  4 ---
 .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dts    |  2 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |  4 ---
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  |  6 +---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 37 ++++++++--------------
 .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |  4 ---
 19 files changed, 25 insertions(+), 96 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
index 1ce85a581..95110d065 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
@@ -153,7 +153,7 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
+&usbdrd3_0 {
 	dr_mode = "host";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
index 6db18808b..4017b0e8c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -773,12 +773,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "otg";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 32dcaf210..e42783cb7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -618,13 +618,9 @@ ap_i2c_audio: &i2c8 {
 };
 
 &usbdrd3_0 {
-	status = "okay";
+	dr_mode = "host";
 	extcon = <&usbc_extcon0>;
-};
-
-&usbdrd_dwc3_0 {
 	status = "okay";
-	dr_mode = "host";
 };
 
 &vopb {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
index 341d074ed..daf14f732 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
@@ -731,12 +731,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
index 635afdd99..d028285fb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
@@ -797,12 +797,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "otg";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
index 1fa80ac15..1c0b48a71 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
@@ -611,12 +611,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "otg";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
index fa5809887..33730b3c5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
@@ -124,7 +124,7 @@
 	status = "disabled";
 };
 
-&usbdrd_dwc3_0 {
+&usbdrd3_0 {
 	dr_mode = "host";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 48ed4aaa3..01c15c833 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -714,10 +714,6 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
-	status = "okay";
-};
-
 &usbdrd_dwc3_1 {
 	dr_mode = "host";
 	status = "okay";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
index ad7c4d008..7b633622c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts
@@ -854,12 +854,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 219b7507a..f00e11075 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -1086,10 +1086,6 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
 	dr_mode = "host";
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
index a8d363568..35780506c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dts
@@ -223,10 +223,6 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
 	dr_mode = "otg";
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
index 20309076d..4d30c1b32 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
@@ -792,10 +792,6 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
-	status = "okay";
-};
-
 &usbdrd3_1 {
 	status = "okay";
 };
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 fb7599f07..69c067dd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -668,12 +668,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
index 1a23e8f3c..df4119441 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
@@ -139,7 +139,7 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
+&usbdrd3_0 {
 	dr_mode = "otg";
 };
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index 5e3ac589b..3920dcbd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -635,10 +635,6 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
-	status = "okay";
-};
-
 &usbdrd3_1 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index d42c75c6d..f119fc41f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -830,12 +830,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
index 701a567d7..2e76f178e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi
@@ -614,12 +614,8 @@
 };
 
 &usbdrd3_0 {
-	status = "okay";
-};
-
-&usbdrd_dwc3_0 {
-	status = "okay";
 	dr_mode = "host";
+	status = "okay";
 };
 
 &usbdrd3_1 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 186a7c483..deac8f8e5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -365,37 +365,26 @@
 	};
 
 	usbdrd3_0: usb at fe800000 {
-		compatible = "rockchip,rk3399-dwc3";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
+		compatible = "rockchip,rk3399-dwc3", "snps,dwc3";
+		reg = <0x0 0xfe800000 0x0 0x100000>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
 		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
 			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
 		clock-names = "ref_clk", "suspend_clk",
 			      "bus_clk", "grf_clk";
+		dr_mode = "otg";
+		phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+		phy-names = "usb2-phy", "usb3-phy";
+		phy_type = "utmi_wide";
+		power-domains = <&power RK3399_PD_USB3>;
 		resets = <&cru SRST_A_USB3_OTG0>;
 		reset-names = "usb3-otg";
+		snps,dis-del-phy-power-chg-quirk;
+		snps,dis_enblslpm_quirk;
+		snps,dis-tx-ipgap-linecheck-quirk;
+		snps,dis-u2-freeclk-exists-quirk;
+		snps,dis_u2_susphy_quirk;
 		status = "disabled";
-
-		usbdrd_dwc3_0: usb at fe800000 {
-			compatible = "snps,dwc3";
-			reg = <0x0 0xfe800000 0x0 0x100000>;
-			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
-			clocks = <&cru SCLK_USB3OTG0_REF>, <&cru ACLK_USB3OTG0>,
-				 <&cru SCLK_USB3OTG0_SUSPEND>;
-			clock-names = "ref", "bus_early", "suspend";
-			dr_mode = "otg";
-			phys = <&u2phy0_otg>, <&tcphy0_usb3>;
-			phy-names = "usb2-phy", "usb3-phy";
-			phy_type = "utmi_wide";
-			snps,dis_enblslpm_quirk;
-			snps,dis-u2-freeclk-exists-quirk;
-			snps,dis_u2_susphy_quirk;
-			snps,dis-del-phy-power-chg-quirk;
-			snps,dis-tx-ipgap-linecheck-quirk;
-			power-domains = <&power RK3399_PD_USB3>;
-			status = "disabled";
-		};
 	};
 
 	usbdrd3_1: usb at fe900000 {
diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
index 7257494d2..810fb7880 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
@@ -454,10 +454,6 @@
 	status = "okay";
 };
 
-&usbdrd_dwc3_0 {
-	status = "okay";
-};
-
 &vbus_host {
 	enable-active-high;
 	gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>; /* USB1_EN_OC# */
-- 
2.11.0



From lkp at intel.com  Thu Apr  1 22:37:29 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 05:37:29 +0800
Subject: [PATCH 09/30] media: atmel: atmel-isc: extract CBC submodule
 config into separate function
In-Reply-To: <20210401112723.189107-10-eugen.hristev@microchip.com>
References: <20210401112723.189107-10-eugen.hristev@microchip.com>
Message-ID: <202104020535.rlJduYt6-lkp@intel.com>

Hi Eugen,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v5.12-rc5 next-20210401]
[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]

url:    https://github.com/0day-ci/linux/commits/Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
base:   git://linuxtv.org/media_tree.git master
config: arm64-randconfig-r024-20210401 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/0136fa35e972de936a196a353496986799606b7b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Eugen-Hristev/media-atmel-atmel-isc-add-support-for-xisc/20210402-024144
        git checkout 0136fa35e972de936a196a353496986799606b7b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/media/platform/atmel/atmel-sama5d2-isc.c:57:6: warning: no previous prototype for 'isc_sama5d2_config_csc' [-Wmissing-prototypes]
      57 | void isc_sama5d2_config_csc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~
>> drivers/media/platform/atmel/atmel-sama5d2-isc.c:76:6: warning: no previous prototype for 'isc_sama5d2_config_cbc' [-Wmissing-prototypes]
      76 | void isc_sama5d2_config_cbc(struct isc_device *isc)
         |      ^~~~~~~~~~~~~~~~~~~~~~


vim +/isc_sama5d2_config_cbc +76 drivers/media/platform/atmel/atmel-sama5d2-isc.c

    56	
  > 57	void isc_sama5d2_config_csc(struct isc_device *isc)
    58	{
    59		struct regmap *regmap = isc->regmap;
    60	
    61		/* Convert RGB to YUV */
    62		regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
    63			     0x42 | (0x81 << 16));
    64		regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
    65			     0x19 | (0x10 << 16));
    66		regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
    67			     0xFDA | (0xFB6 << 16));
    68		regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
    69			     0x70 | (0x80 << 16));
    70		regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
    71			     0x70 | (0xFA2 << 16));
    72		regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
    73			     0xFEE | (0x80 << 16));
    74	}
    75	
  > 76	void isc_sama5d2_config_cbc(struct isc_device *isc)
    77	{
    78		struct regmap *regmap = isc->regmap;
    79	
    80		regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
    81		regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
    82	}
    83	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37908 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/113a68b8/attachment-0001.gz>

From lkp at intel.com  Thu Apr  1 22:45:28 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 05:45:28 +0800
Subject: [xlnx:xlnx_rebase_v5.4 913/1701] drivers/usb/dwc3/core.c:977:5:
 warning: no previous prototype for 'dwc3_core_init'
Message-ID: <202104020521.JgWkNfVz-lkp@intel.com>

Hi Anurag,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 526f56822f971265d67428fe61e40fe18f95ac81 [913/1701] usb: dwc3: Add hibernation support when operating as gadget
config: i386-randconfig-c021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/526f56822f971265d67428fe61e40fe18f95ac81
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 526f56822f971265d67428fe61e40fe18f95ac81
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1444:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1444 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1446:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1446 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1448:6: warning: no previous prototype for 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
    1448 | void dwc3_simple_check_quirks(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1450:5: warning: no previous prototype for 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
    1450 | int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
         |     ^~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.c:386:6: warning: no previous prototype for 'dwc3_free_event_buffers' [-Wmissing-prototypes]
     386 | void dwc3_free_event_buffers(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.c:403:5: warning: no previous prototype for 'dwc3_alloc_event_buffers' [-Wmissing-prototypes]
     403 | int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
         |     ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.c:977:5: warning: no previous prototype for 'dwc3_core_init' [-Wmissing-prototypes]
     977 | int dwc3_core_init(struct dwc3 *dwc)
         |     ^~~~~~~~~~~~~~
   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h: In function 'dwc3_set_usb_core_power':
   drivers/usb/dwc3/core.h:1451:5: warning: control reaches end of non-void function [-Wreturn-type]
    1451 | { ; }
         |     ^


vim +/dwc3_core_init +977 drivers/usb/dwc3/core.c

   970	
   971	/**
   972	 * dwc3_core_init - Low-level initialization of DWC3 Core
   973	 * @dwc: Pointer to our controller context structure
   974	 *
   975	 * Returns 0 on success otherwise negative errno.
   976	 */
 > 977	int dwc3_core_init(struct dwc3 *dwc)
   978	{
   979		u32			reg;
   980		int			ret;
   981	
   982		/*
   983		 * Write Linux Version Code to our GUID register so it's easy to figure
   984		 * out which kernel version a bug was found.
   985		 */
   986		dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
   987	
   988		/* Handle USB2.0-only core configuration */
   989		if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
   990				DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
   991			if (dwc->maximum_speed == USB_SPEED_SUPER)
   992				dwc->maximum_speed = USB_SPEED_HIGH;
   993		}
   994	
   995		ret = dwc3_phy_setup(dwc);
   996		if (ret)
   997			goto err0;
   998	
   999		if (!dwc->ulpi_ready) {
  1000			ret = dwc3_core_ulpi_init(dwc);
  1001			if (ret)
  1002				goto err0;
  1003			dwc->ulpi_ready = true;
  1004		}
  1005	
  1006		if (!dwc->phys_ready) {
  1007			ret = dwc3_core_get_phy(dwc);
  1008			if (ret)
  1009				goto err0a;
  1010			dwc->phys_ready = true;
  1011		}
  1012	
  1013		ret = dwc3_core_soft_reset(dwc);
  1014		if (ret)
  1015			goto err0a;
  1016	
  1017		dwc3_core_setup_global_control(dwc);
  1018		dwc3_core_num_eps(dwc);
  1019	
  1020		if (dwc->scratchbuf == NULL) {
  1021			ret = dwc3_alloc_scratch_buffers(dwc);
  1022			if (ret) {
  1023				dev_err(dwc->dev,
  1024					"Not enough memory for scratch buffers\n");
  1025				goto err1;
  1026			}
  1027		}
  1028	
  1029		ret = dwc3_setup_scratch_buffers(dwc);
  1030		if (ret) {
  1031			dev_err(dwc->dev, "Failed to setup scratch buffers: %d\n", ret);
  1032			goto err1;
  1033		}
  1034	
  1035		/* Adjust Frame Length */
  1036		dwc3_frame_length_adjustment(dwc);
  1037	
  1038		dwc3_set_incr_burst_type(dwc);
  1039	
  1040		ret = dwc3_config_soc_bus(dwc);
  1041		if (ret)
  1042			goto err1;
  1043	
  1044		usb_phy_set_suspend(dwc->usb2_phy, 0);
  1045		usb_phy_set_suspend(dwc->usb3_phy, 0);
  1046		ret = phy_power_on(dwc->usb2_generic_phy);
  1047		if (ret < 0)
  1048			goto err2;
  1049	
  1050		ret = phy_power_on(dwc->usb3_generic_phy);
  1051		if (ret < 0)
  1052			goto err3;
  1053	
  1054		ret = dwc3_event_buffers_setup(dwc);
  1055		if (ret) {
  1056			dev_err(dwc->dev, "failed to setup event buffers\n");
  1057			goto err4;
  1058		}
  1059	
  1060		/*
  1061		 * ENDXFER polling is available on version 3.10a and later of
  1062		 * the DWC_usb3 controller. It is NOT available in the
  1063		 * DWC_usb31 controller.
  1064		 */
  1065		if (!dwc3_is_usb31(dwc) && dwc->revision >= DWC3_REVISION_310A) {
  1066			reg = dwc3_readl(dwc->regs, DWC3_GUCTL2);
  1067			reg |= DWC3_GUCTL2_RST_ACTBITLATER;
  1068			dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
  1069		}
  1070	
  1071		/* When configured in HOST mode, after issuing U3/L2 exit controller
  1072		 * fails to send proper CRC checksum in CRC5 feild. Because of this
  1073		 * behaviour Transaction Error is generated, resulting in reset and
  1074		 * re-enumeration of usb device attached. Enabling bit 10 of GUCTL1
  1075		 * will correct this problem
  1076		 */
  1077		if (dwc->enable_guctl1_resume_quirk) {
  1078			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1079			reg |= DWC3_GUCTL1_RESUME_QUIRK;
  1080			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1081		}
  1082	
  1083		/* SNPS controller when configureed in HOST mode maintains Inter Packet
  1084		 * Delay (IPD) of ~380ns which works with most of the super-speed hubs
  1085		 * except VIA-LAB hubs. When IPD is ~380ns HOST controller fails to
  1086		 * enumerate FS/LS devices when connected behind VIA-LAB hubs.
  1087		 * Enabling bit 9 of GUCTL1 enables the workaround in HW to reduce the
  1088		 * ULPI clock latency by 1 cycle, thus reducing the IPD (~360ns) and
  1089		 * making controller enumerate FS/LS devices connected behind VIA-LAB.
  1090		 */
  1091		if (dwc->enable_guctl1_ipd_quirk) {
  1092			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1093			reg |= DWC3_GUCTL1_IPD_QUIRK;
  1094			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1095		}
  1096	
  1097		if (dwc->revision >= DWC3_REVISION_250A) {
  1098			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1099	
  1100			/*
  1101			 * Enable hardware control of sending remote wakeup
  1102			 * in HS when the device is in the L1 state.
  1103			 */
  1104			if (dwc->revision >= DWC3_REVISION_290A)
  1105				reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
  1106	
  1107			if (dwc->dis_tx_ipgap_linecheck_quirk)
  1108				reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
  1109	
  1110			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1111		}
  1112	
  1113		if (dwc->dr_mode == USB_DR_MODE_HOST ||
  1114		    dwc->dr_mode == USB_DR_MODE_OTG) {
  1115			reg = dwc3_readl(dwc->regs, DWC3_GUCTL);
  1116	
  1117			/*
  1118			 * Enable Auto retry Feature to make the controller operating in
  1119			 * Host mode on seeing transaction errors(CRC errors or internal
  1120			 * overrun scenerios) on IN transfers to reply to the device
  1121			 * with a non-terminating retry ACK (i.e, an ACK transcation
  1122			 * packet with Retry=1 & Nump != 0)
  1123			 */
  1124			reg |= DWC3_GUCTL_HSTINAUTORETRY;
  1125	
  1126			dwc3_writel(dwc->regs, DWC3_GUCTL, reg);
  1127		}
  1128	
  1129		/*
  1130		 * Must config both number of packets and max burst settings to enable
  1131		 * RX and/or TX threshold.
  1132		 */
  1133		if (dwc3_is_usb31(dwc) && dwc->dr_mode == USB_DR_MODE_HOST) {
  1134			u8 rx_thr_num = dwc->rx_thr_num_pkt_prd;
  1135			u8 rx_maxburst = dwc->rx_max_burst_prd;
  1136			u8 tx_thr_num = dwc->tx_thr_num_pkt_prd;
  1137			u8 tx_maxburst = dwc->tx_max_burst_prd;
  1138	
  1139			if (rx_thr_num && rx_maxburst) {
  1140				reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
  1141				reg |= DWC31_RXTHRNUMPKTSEL_PRD;
  1142	
  1143				reg &= ~DWC31_RXTHRNUMPKT_PRD(~0);
  1144				reg |= DWC31_RXTHRNUMPKT_PRD(rx_thr_num);
  1145	
  1146				reg &= ~DWC31_MAXRXBURSTSIZE_PRD(~0);
  1147				reg |= DWC31_MAXRXBURSTSIZE_PRD(rx_maxburst);
  1148	
  1149				dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
  1150			}
  1151	
  1152			if (tx_thr_num && tx_maxburst) {
  1153				reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
  1154				reg |= DWC31_TXTHRNUMPKTSEL_PRD;
  1155	
  1156				reg &= ~DWC31_TXTHRNUMPKT_PRD(~0);
  1157				reg |= DWC31_TXTHRNUMPKT_PRD(tx_thr_num);
  1158	
  1159				reg &= ~DWC31_MAXTXBURSTSIZE_PRD(~0);
  1160				reg |= DWC31_MAXTXBURSTSIZE_PRD(tx_maxburst);
  1161	
  1162				dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
  1163			}
  1164		}
  1165	
  1166		return 0;
  1167	
  1168	err4:
  1169		phy_power_off(dwc->usb3_generic_phy);
  1170	
  1171	err3:
  1172		phy_power_off(dwc->usb2_generic_phy);
  1173	
  1174	err2:
  1175		usb_phy_set_suspend(dwc->usb2_phy, 1);
  1176		usb_phy_set_suspend(dwc->usb3_phy, 1);
  1177	
  1178	err1:
  1179		usb_phy_shutdown(dwc->usb2_phy);
  1180		usb_phy_shutdown(dwc->usb3_phy);
  1181		phy_exit(dwc->usb2_generic_phy);
  1182		phy_exit(dwc->usb3_generic_phy);
  1183	
  1184	err0a:
  1185		dwc3_ulpi_exit(dwc);
  1186	
  1187	err0:
  1188		return ret;
  1189	}
  1190	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/54e51e92/attachment-0001.gz>

From keescook at chromium.org  Thu Apr  1 22:46:23 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu, 1 Apr 2021 14:46:23 -0700
Subject: [PATCH v8 0/6] Optionally randomize kernel stack offset each
 syscall
In-Reply-To: <20210401191744.1685896-1-royyang@google.com>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210401191744.1685896-1-royyang@google.com>
Message-ID: <202104011442.B20F2BAFC@keescook>

On Thu, Apr 01, 2021 at 12:17:44PM -0700, Roy Yang wrote:
> Both Android and Chrome OS really want this feature; For Container-Optimized OS, we have customers
> interested in the defense too.

It's pretty close! There are a couple recent comments that need to be
addressed, but hopefully it can land if x86 and arm64 maintainers are
happy v10.

> Change-Id: I1eb1b726007aa8f9c374b934cc1c690fb4924aa3
> -- 
> 2.31.0.208.g409f899ff0-goog

And to let other folks know, I'm guessing this email got sent with git
send-email to try to get a valid In-Reply-To header, but I guess git
trashed the Subject and ran hooks to generate a Change-Id UUID.

I assume it's from following the "Reply instructions" at the bottom of:
https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/
(It seems those need clarification about Subject handling.)

-- 
Kees Cook


From lkp at intel.com  Thu Apr  1 23:04:45 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 06:04:45 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1102/1701]
 drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:45:9: error: implicit
 declaration of function 'in_be32'
Message-ID: <202104020642.bGDQMtrh-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: bbcf6f9bb1bc206330ca4d423e5a3966d8d82110 [1102/1701] net: xilinx: Add support for PL TSN IP features
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/bbcf6f9bb1bc206330ca4d423e5a3966d8d82110
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout bbcf6f9bb1bc206330ca4d423e5a3966d8d82110
        # save the attached .config to linux build tree
        make W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c: In function 'xlnx_tod_read':
>> drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:45:9: error: implicit declaration of function 'in_be32' [-Werror=implicit-function-declaration]
      45 |  nsec = in_be32(timer->baseaddr + XTIMER1588_CURRENT_RTC_NS);
         |         ^~~~~~~
   In file included from include/linux/kernel.h:15,
                    from include/linux/list.h:9,
                    from include/linux/kobject.h:19,
                    from include/linux/device.h:16,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:18:
   drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c: In function 'xlnx_rtc_offset_write':
   drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:55:11: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'time64_t' {aka 'const long long int'} [-Wformat=]
      55 |  pr_debug("%s: sec: %ld nsec: %ld\n", __func__, ts->tv_sec, ts->tv_nsec);
         |           ^~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/printk.h:288:21: note: in definition of macro 'pr_fmt'
     288 | #define pr_fmt(fmt) fmt
         |                     ^~~
   include/linux/dynamic_debug.h:143:2: note: in expansion of macro '__dynamic_func_call'
     143 |  __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/dynamic_debug.h:153:2: note: in expansion of macro '_dynamic_func_call'
     153 |  _dynamic_func_call(fmt, __dynamic_pr_debug,  \
         |  ^~~~~~~~~~~~~~~~~~
   include/linux/printk.h:336:2: note: in expansion of macro 'dynamic_pr_debug'
     336 |  dynamic_pr_debug(fmt, ##__VA_ARGS__)
         |  ^~~~~~~~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:55:2: note: in expansion of macro 'pr_debug'
      55 |  pr_debug("%s: sec: %ld nsec: %ld\n", __func__, ts->tv_sec, ts->tv_nsec);
         |  ^~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:55:23: note: format string is defined here
      55 |  pr_debug("%s: sec: %ld nsec: %ld\n", __func__, ts->tv_sec, ts->tv_nsec);
         |                     ~~^
         |                       |
         |                       long int
         |                     %lld
>> drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c:57:2: error: implicit declaration of function 'out_be32' [-Werror=implicit-function-declaration]
      57 |  out_be32((timer->baseaddr + XTIMER1588_RTC_OFFSET_SEC_H), 0);
         |  ^~~~~~~~
   cc1: some warnings being treated as errors
--
   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   In file included from include/linux/uaccess.h:11,
                    from include/linux/crypto.h:21,
                    from include/crypto/hash.h:11,
                    from include/linux/uio.h:10,
                    from include/linux/socket.h:8,
                    from include/linux/compat.h:15,
                    from include/linux/ethtool.h:17,
                    from include/linux/netdevice.h:37,
                    from drivers/net/ethernet/xilinx/xilinx_axienet.h:12,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.h:21,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.c:18:
   arch/um/include/asm/uaccess.h: In function '__access_ok':
   arch/um/include/asm/uaccess.h:17:29: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
      17 |    (((unsigned long) (addr) >= FIXADDR_USER_START) && \
         |                             ^~
   arch/um/include/asm/uaccess.h:45:3: note: in expansion of macro '__access_ok_vsyscall'
      45 |   __access_ok_vsyscall(addr, size) ||
         |   ^~~~~~~~~~~~~~~~~~~~
   In file included from include/linux/kernel.h:11,
                    from include/linux/list.h:9,
                    from include/linux/timer.h:5,
                    from include/linux/netdevice.h:24,
                    from drivers/net/ethernet/xilinx/xilinx_axienet.h:12,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.h:21,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.c:18:
   include/asm-generic/fixmap.h: In function 'fix_to_virt':
   include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |                   ^~
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
     330 |   if (!(condition))     \
         |         ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
      50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
         |  ^~~~~~~~~~~~~~~~
   include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON'
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |  ^~~~~~~~~~~~
   In file included from arch/um/include/asm/io.h:16,
                    from include/linux/scatterlist.h:9,
                    from include/linux/dma-mapping.h:11,
                    from include/linux/skbuff.h:31,
                    from include/linux/if_ether.h:19,
                    from include/uapi/linux/ethtool.h:19,
                    from include/linux/ethtool.h:18,
                    from include/linux/netdevice.h:37,
                    from drivers/net/ethernet/xilinx/xilinx_axienet.h:12,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.h:21,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_switch.c:18:
   drivers/net/ethernet/xilinx/xilinx_tsn_switch.c: In function 'tsnswitch_probe':
>> include/asm-generic/io.h:127:32: warning: 'pmap' may be used uninitialized in this function [-Wmaybe-uninitialized]
     127 |  *(volatile u32 __force *)addr = value;
         |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_switch.c:580:6: note: 'pmap' was declared here
     580 |  u32 pmap;
         |      ^~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +/in_be32 +45 drivers/net/ethernet/xilinx/xilinx_tsn_ptp_clock.c

    40	
    41	static void xlnx_tod_read(struct xlnx_ptp_timer *timer, struct timespec64 *ts)
    42	{
    43		u32 sec, nsec;
    44	
  > 45		nsec = in_be32(timer->baseaddr + XTIMER1588_CURRENT_RTC_NS);
    46		sec = in_be32(timer->baseaddr + XTIMER1588_CURRENT_RTC_SEC_L);
    47	
    48		ts->tv_sec = sec;
    49		ts->tv_nsec = nsec;
    50	}
    51	
    52	static void xlnx_rtc_offset_write(struct xlnx_ptp_timer *timer,
    53					  const struct timespec64 *ts)
    54	{
    55		pr_debug("%s: sec: %ld nsec: %ld\n", __func__, ts->tv_sec, ts->tv_nsec);
    56	
  > 57		out_be32((timer->baseaddr + XTIMER1588_RTC_OFFSET_SEC_H), 0);
    58		out_be32((timer->baseaddr + XTIMER1588_RTC_OFFSET_SEC_L),
    59			 (ts->tv_sec));
    60		out_be32((timer->baseaddr + XTIMER1588_RTC_OFFSET_NS), ts->tv_nsec);
    61	}
    62	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22032 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/e61066b8/attachment-0001.gz>

From lkp at intel.com  Thu Apr  1 23:08:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 06:08:43 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1138/1701] ERROR: "__divdi3"
 [drivers/rtc/rtc-zynqmp.ko] undefined!
Message-ID: <202104020638.gK86aSMx-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: a4704c54d84d1e391275ad6ac10ce0e7c9157505 [1138/1701] rtc: zynqmp: Add calibration set and get support
config: i386-randconfig-a011-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/a4704c54d84d1e391275ad6ac10ce0e7c9157505
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout a4704c54d84d1e391275ad6ac10ce0e7c9157505
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> ERROR: "__divdi3" [drivers/rtc/rtc-zynqmp.ko] undefined!
>> ERROR: "__udivdi3" [drivers/rtc/rtc-zynqmp.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28977 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/cfd1e8d3/attachment-0001.gz>

From mark.kettenis at xs4all.nl  Thu Apr  1 23:18:21 2021
From: mark.kettenis at xs4all.nl (Mark Kettenis)
Date: Fri, 2 Apr 2021 00:18:21 +0200 (CEST)
Subject: [PATCH v6 0/4] convert rockchip,dwc3.txt to yaml
In-Reply-To: <20210401213652.14676-1-jbx6244@gmail.com> (message from Johan
 Jonker on Thu, 1 Apr 2021 23:36:48 +0200)
References: <20210401213652.14676-1-jbx6244@gmail.com>
Message-ID: <c1bced42d7388f34@bloch.sibelius.xs4all.nl>

> From: Johan Jonker <jbx6244 at gmail.com>
> Date: Thu,  1 Apr 2021 23:36:48 +0200
> 
> The conversion of rockchip,dwc3.txt to yaml was added to linux-next,
> but the necessary changes for rk3399 are still pending.
> 
> For rk3399 dwc3 usb the wrapper node for only clocks makes no sense,
> so that was removed in the YAML example.
> 
> Now dtbs_check still generates notifications for the compatibility string in
> the dts files that doesn't match, because it changed from
> "rockchip,rk3399-dwc3" to "rockchip,rk3399-dwc3", "snps,dwc3".
> 
> The problem is to keep compatible with old device trees.
> I.e. a device running an older device tree should still work with newer
> kernels.
> 
> Comment by Rob in version 3:
> Presumably you are getting lucky here (with link order). The kernel
> has no logic to decide which driver to bind to if there are 2 matching
> drivers. If we did, it would probably be the opposite of what you want
> here as we'd pick the most specific match. This driver should probably
> bail probe if no dwc3 child node.
> 
> Please advise how to move forward with this serie.

As I tried to point out earlier, this kind of binding change is
unhelpful.  Yes, you now have extra code in future Linux kernels that
works around the problem.  But other consumers of device trees
(U-Boot, other OSes) will have to add similar code or keep using older
device trees.  And even then it will still cause frustration for users
that want to run older kernels.

I do understand that it is sometimes necessary to change device tree
bindings.  But changes like this one just cause a lot of pain without
a significant technical benefit.

Cheers,

Mark


> Changed V6:
>   rebase
>   remove accepted patches from serie
> 
> Changed V5:
>   add select
> 
> Changed V4:
>   removed patch "of-simple: add compatible for rk3328"
>   add patch "of-simple: bail probe if no dwc3 child node"
> 
> Changed V3:
>   remove aclk_usb3_rksoc_axi_perf
>   remove aclk_usb3
> 
> Changed V2:
>   remove node wrapper
> 
> Johan Jonker (3):
>   usb: dwc3: of-simple: bail probe if no dwc3 child node
>   arm64: dts: rockchip: restyle rk3399 usbdrd3_0 node
>   arm64: dts: rockchip: restyle rk3399 usbdrd3_1 node
> 
> Wu Liang feng (1):
>   arm64: dts: rockchip: optimize clks for rk3399 dwc3
> 
>  arch/arm64/boot/dts/rockchip/rk3399-ficus.dts      |  4 +-
>  arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    | 12 +--
>  .../boot/dts/rockchip/rk3399-gru-chromebook.dtsi   |  6 +-
>  arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |  6 +-
>  arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 12 +--
>  .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      | 12 +--
>  arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  | 12 +--
>  arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts |  2 +-
>  arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |  8 --
>  arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   | 12 +--
>  .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |  8 --
>  .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts |  4 -
>  arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |  6 +-
>  arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    | 10 +--
>  arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 12 +--
>  arch/arm64/boot/dts/rockchip/rk3399-rock960.dts    |  4 +-
>  arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |  8 --
>  arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 12 +--
>  arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  | 12 +--
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 86 ++++++++--------------
>  .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |  4 -
>  drivers/usb/dwc3/dwc3-of-simple.c                  |  4 +
>  22 files changed, 59 insertions(+), 197 deletions(-)
> 
> -- 
> 2.11.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From keescook at chromium.org  Thu Apr  1 23:42:08 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu, 1 Apr 2021 15:42:08 -0700
Subject: [PATCH v8 3/6] stack: Optionally randomize kernel stack offset
 each syscall
In-Reply-To: <61ae9398a03d4fe7868b68c9026d5998@AcuMS.aculab.com>
References: <20210330205750.428816-1-keescook@chromium.org>
 <20210330205750.428816-4-keescook@chromium.org>
 <20210401083034.GA8554@willie-the-truck>
 <61ae9398a03d4fe7868b68c9026d5998@AcuMS.aculab.com>
Message-ID: <202104011447.2E7F543@keescook>

On Thu, Apr 01, 2021 at 11:15:43AM +0000, David Laight wrote:
> From: Will Deacon
> > Sent: 01 April 2021 09:31
> ...
> > > +/*
> > > + * These macros must be used during syscall entry when interrupts and
> > > + * preempt are disabled, and after user registers have been stored to
> > > + * the stack.
> > > + */
> > > +#define add_random_kstack_offset() do {					\
> > > +	if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,	\
> > > +				&randomize_kstack_offset)) {		\
> > > +		u32 offset = __this_cpu_read(kstack_offset);		\
> > > +		u8 *ptr = __builtin_alloca(KSTACK_OFFSET_MAX(offset));	\
> > > +		asm volatile("" : "=m"(*ptr) :: "memory");		\
> > 
> > Using the "m" constraint here is dangerous if you don't actually evaluate it
> > inside the asm. For example, if the compiler decides to generate an
> > addressing mode relative to the stack but with writeback (autodecrement), then
> > the stack pointer will be off by 8 bytes. Can you use "o" instead?

I see other examples of empty asm, but it's true, none are using "=m" read
constraints. But, yes, using "o" appears to work happily.

> Is it allowed to use such a mode?
> It would have to know that the "m" was substituted exactly once.
> I think there are quite a few examples with 'strange' uses of memory
> asm arguments.
> 
> However, in this case, isn't it enough to ensure the address is 'saved'?
> So:
> 	asm volatile("" : "=r"(ptr) );
> should be enough.

It isn't, it seems.

Here's a comparison:

https://godbolt.org/z/xYGn9GfGY

So, I'll resend with "o", and with raw_cpu_*().

Thanks!

-- 
Kees Cook


From lkp at intel.com  Thu Apr  1 23:54:16 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 06:54:16 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1171/1701]
 drivers/irqchip/irq-xilinx-intc.c:295:3: error: implicit declaration of
 function 'set_handle_irq'; did you mean 'generic_handle_irq'?
Message-ID: <202104020610.Voprvqw5-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: e310970affe01f4432b5a022438bae976c7f324f [1171/1701] irqchip: xilinx: Enable generic irq multi handler
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/e310970affe01f4432b5a022438bae976c7f324f
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout e310970affe01f4432b5a022438bae976c7f324f
        # save the attached .config to linux build tree
        make W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/irqchip/irq-xilinx-intc.c: In function 'xilinx_intc_of_init':
>> drivers/irqchip/irq-xilinx-intc.c:295:3: error: implicit declaration of function 'set_handle_irq'; did you mean 'generic_handle_irq'? [-Werror=implicit-function-declaration]
     295 |   set_handle_irq(xil_intc_handle_irq);
         |   ^~~~~~~~~~~~~~
         |   generic_handle_irq
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +295 drivers/irqchip/irq-xilinx-intc.c

   194	
   195	static int __init xilinx_intc_of_init(struct device_node *intc,
   196						     struct device_node *parent)
   197	{
   198		int ret, irq;
   199		struct xintc_irq_chip *irqc;
   200		struct irq_chip *intc_dev;
   201		u32 cpu_id = 0;
   202	
   203		ret = of_property_read_u32(intc, "cpu-id", &cpu_id);
   204		if (ret < 0)
   205			pr_err("%s: %pOF: cpu_id not found\n", __func__, intc);
   206	
   207		/* No parent means it is primary intc */
   208		if (!parent) {
   209			irqc = per_cpu_ptr(&primary_intc, cpu_id);
   210			if (irqc->base) {
   211				pr_err("%pOF: %s: cpu %d has already irq controller\n",
   212					intc, __func__, cpu_id);
   213				return -EINVAL;
   214			}
   215		} else {
   216			irqc = kzalloc(sizeof(*irqc), GFP_KERNEL);
   217			if (!irqc)
   218				return -ENOMEM;
   219		}
   220	
   221		irqc->base = of_iomap(intc, 0);
   222		BUG_ON(!irqc->base);
   223	
   224		ret = of_property_read_u32(intc, "xlnx,num-intr-inputs", &irqc->nr_irq);
   225		if (ret < 0) {
   226			pr_err("irq-xilinx: unable to read xlnx,num-intr-inputs\n");
   227			goto error;
   228		}
   229	
   230		ret = of_property_read_u32(intc, "xlnx,kind-of-intr", &irqc->intr_mask);
   231		if (ret < 0) {
   232			pr_warn("irq-xilinx: unable to read xlnx,kind-of-intr\n");
   233			irqc->intr_mask = 0;
   234		}
   235	
   236		if (irqc->intr_mask >> irqc->nr_irq)
   237			pr_warn("irq-xilinx: mismatch in kind-of-intr param\n");
   238	
   239		pr_info("irq-xilinx: %pOF: num_irq=%d, edge=0x%x\n",
   240			intc, irqc->nr_irq, irqc->intr_mask);
   241	
   242		intc_dev = kzalloc(sizeof(*intc_dev), GFP_KERNEL);
   243		if (!intc_dev) {
   244			ret = -ENOMEM;
   245			goto error;
   246		}
   247	
   248		intc_dev->name = intc->full_name;
   249		intc_dev->irq_unmask = intc_enable_or_unmask,
   250		intc_dev->irq_mask = intc_disable_or_mask,
   251		intc_dev->irq_ack = intc_ack,
   252		intc_dev->irq_mask_ack = intc_mask_ack,
   253		irqc->intc_dev = intc_dev;
   254	
   255		irqc->write_fn = xintc_write;
   256		irqc->read_fn = xintc_read;
   257		/*
   258		 * Disable all external interrupts until they are
   259		 * explicity requested.
   260		 */
   261		irqc->write_fn(irqc->base + IER, 0);
   262	
   263		/* Acknowledge any pending interrupts just in case. */
   264		irqc->write_fn(irqc->base + IAR, 0xffffffff);
   265	
   266		/* Turn on the Master Enable. */
   267		irqc->write_fn(irqc->base + MER, MER_HIE | MER_ME);
   268		if (!(irqc->read_fn(irqc->base + MER) & (MER_HIE | MER_ME))) {
   269			irqc->write_fn = xintc_write_be;
   270			irqc->read_fn = xintc_read_be;
   271			irqc->write_fn(irqc->base + MER, MER_HIE | MER_ME);
   272		}
   273	
   274		irqc->root_domain = irq_domain_add_linear(intc, irqc->nr_irq,
   275							  &xintc_irq_domain_ops, irqc);
   276		if (!irqc->root_domain) {
   277			pr_err("irq-xilinx: Unable to create IRQ domain\n");
   278			ret = -EINVAL;
   279			goto err_alloc;
   280		}
   281	
   282		if (parent) {
   283			irq = irq_of_parse_and_map(intc, 0);
   284			if (irq) {
   285				irq_set_chained_handler_and_data(irq,
   286								 xil_intc_irq_handler,
   287								 irqc);
   288			} else {
   289				pr_err("irq-xilinx: interrupts property not in DT\n");
   290				ret = -EINVAL;
   291				goto err_alloc;
   292			}
   293		} else {
   294			irq_set_default_host(irqc->root_domain);
 > 295			set_handle_irq(xil_intc_handle_irq);
   296		}
   297	
   298		return 0;
   299	
   300	err_alloc:
   301		kfree(intc_dev);
   302	error:
   303		iounmap(irqc->base);
   304		if (parent)
   305			kfree(irqc);
   306		return ret;
   307	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22043 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/df4b259b/attachment-0001.gz>

From patchwork-bot+netdevbpf at kernel.org  Fri Apr  2 00:00:08 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 01 Apr 2021 23:00:08 +0000
Subject: [PATCH net-next 1/1] stmmac: intel: use managed PCI function on
 probe and resume
In-Reply-To: <20210401060250.24109-1-vee.khee.wong@linux.intel.com>
References: <20210401060250.24109-1-vee.khee.wong@linux.intel.com>
Message-ID: <161731800895.8028.1455207086826594661.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Thu,  1 Apr 2021 14:02:50 +0800 you wrote:
> Update dwmac-intel to use managed function, i.e. pcim_enable_device().
> 
> This will allow devres framework to call resource free function for us.
> 
> Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)

Here is the summary with links:
  - [net-next,1/1] stmmac: intel: use managed PCI function on probe and resume
    https://git.kernel.org/netdev/net-next/c/8accc467758e

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From patchwork-bot+netdevbpf at kernel.org  Fri Apr  2 00:00:08 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 01 Apr 2021 23:00:08 +0000
Subject: [PATCH net-next 1/1] net: stmmac: remove unnecessary
 pci_enable_msi() call
In-Reply-To: <20210401060628.27339-1-vee.khee.wong@linux.intel.com>
References: <20210401060628.27339-1-vee.khee.wong@linux.intel.com>
Message-ID: <161731800891.8028.4149863007531019665.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Thu,  1 Apr 2021 14:06:28 +0800 you wrote:
> The commit d2a029bde37b ("stmmac: pci: add MSI support for Intel Quark
> X1000") introduced a pci_enable_msi() call in stmmac_pci.c.
> 
> With the commit 58da0cfa6cf1 ("net: stmmac: create dwmac-intel.c to
> contain all Intel platform"), Intel Quark platform related codes
> have been moved to the newly created driver.
> 
> [...]

Here is the summary with links:
  - [net-next,1/1] net: stmmac: remove unnecessary pci_enable_msi() call
    https://git.kernel.org/netdev/net-next/c/2237778d8c21

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From irogers at google.com  Fri Apr  2 00:16:32 2021
From: irogers at google.com (Ian Rogers)
Date: Thu, 1 Apr 2021 16:16:32 -0700
Subject: [PATCH v2 1/6] perf metricgroup: Make find_metric() public with
 name change
In-Reply-To: <1616668398-144648-2-git-send-email-john.garry@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-2-git-send-email-john.garry@huawei.com>
Message-ID: <CAP-5=fVMfK5-rGtx1QjTLz6AQeGr0ruyxuwC3ADt4kriU9wz0A@mail.gmail.com>

On Thu, Mar 25, 2021 at 3:38 AM John Garry <john.garry at huawei.com> wrote:
>
> Function find_metric() is required for the metric processing in the
> pmu-events testcase, so make it public. Also change the name to include
> "metricgroup".

Would it make more sense as "pmu_events_map__find_metric" ?

Thanks,
Ian

> Signed-off-by: John Garry <john.garry at huawei.com>
> ---
>  tools/perf/util/metricgroup.c | 5 +++--
>  tools/perf/util/metricgroup.h | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 6acb44ad439b..71a13406e0bd 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -900,7 +900,8 @@ static int __add_metric(struct list_head *metric_list,
>                     (match_metric(__pe->metric_group, __metric) ||      \
>                      match_metric(__pe->metric_name, __metric)))
>
> -static struct pmu_event *find_metric(const char *metric, struct pmu_events_map *map)
> +struct pmu_event *metrcgroup_find_metric(const char *metric,
> +                                        struct pmu_events_map *map)
>  {
>         struct pmu_event *pe;
>         int i;
> @@ -985,7 +986,7 @@ static int __resolve_metric(struct metric *m,
>                         struct expr_id *parent;
>                         struct pmu_event *pe;
>
> -                       pe = find_metric(cur->key, map);
> +                       pe = metrcgroup_find_metric(cur->key, map);
>                         if (!pe)
>                                 continue;
>
> diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
> index ed1b9392e624..1674c6a36d74 100644
> --- a/tools/perf/util/metricgroup.h
> +++ b/tools/perf/util/metricgroup.h
> @@ -44,7 +44,8 @@ int metricgroup__parse_groups(const struct option *opt,
>                               bool metric_no_group,
>                               bool metric_no_merge,
>                               struct rblist *metric_events);
> -
> +struct pmu_event *metrcgroup_find_metric(const char *metric,
> +                                        struct pmu_events_map *map);
>  int metricgroup__parse_groups_test(struct evlist *evlist,
>                                    struct pmu_events_map *map,
>                                    const char *str,
> --
> 2.26.2
>


From keescook at chromium.org  Fri Apr  2 00:23:45 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:45 -0700
Subject: [PATCH v10 4/6] x86/entry: Enable random_kstack_offset support
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-5-keescook@chromium.org>

Allow for a randomized stack offset on a per-syscall basis, with roughly
5-6 bits of entropy, depending on compiler and word size. Since the
method of offsetting uses macros, this cannot live in the common entry
code (the stack offset needs to be retained for the life of the syscall,
which means it needs to happen at the actual entry point).

Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
Link: https://lore.kernel.org/lkml/87lfa369tv.ffs at nanos.tec.linutronix.de/
Signed-off-by: Kees Cook <keescook at chromium.org>
---
 arch/x86/Kconfig                    |  1 +
 arch/x86/entry/common.c             |  3 +++
 arch/x86/include/asm/entry-common.h | 16 ++++++++++++++++
 3 files changed, 20 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..4b4ad8ec10d2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -165,6 +165,7 @@ config X86
 	select HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD if X86_64
 	select HAVE_ARCH_USERFAULTFD_WP         if X86_64 && USERFAULTFD
 	select HAVE_ARCH_VMAP_STACK		if X86_64
+	select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
 	select HAVE_ARCH_WITHIN_STACK_FRAMES
 	select HAVE_ASM_MODVERSIONS
 	select HAVE_CMPXCHG_DOUBLE
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index a2433ae8a65e..810983d7c26f 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -38,6 +38,7 @@
 #ifdef CONFIG_X86_64
 __visible noinstr void do_syscall_64(unsigned long nr, struct pt_regs *regs)
 {
+	add_random_kstack_offset();
 	nr = syscall_enter_from_user_mode(regs, nr);
 
 	instrumentation_begin();
@@ -83,6 +84,7 @@ __visible noinstr void do_int80_syscall_32(struct pt_regs *regs)
 {
 	unsigned int nr = syscall_32_enter(regs);
 
+	add_random_kstack_offset();
 	/*
 	 * Subtlety here: if ptrace pokes something larger than 2^32-1 into
 	 * orig_ax, the unsigned int return value truncates it.  This may
@@ -102,6 +104,7 @@ static noinstr bool __do_fast_syscall_32(struct pt_regs *regs)
 	unsigned int nr = syscall_32_enter(regs);
 	int res;
 
+	add_random_kstack_offset();
 	/*
 	 * This cannot use syscall_enter_from_user_mode() as it has to
 	 * fetch EBP before invoking any of the syscall entry work
diff --git a/arch/x86/include/asm/entry-common.h b/arch/x86/include/asm/entry-common.h
index 2b87b191b3b8..14ebd2196569 100644
--- a/arch/x86/include/asm/entry-common.h
+++ b/arch/x86/include/asm/entry-common.h
@@ -2,6 +2,7 @@
 #ifndef _ASM_X86_ENTRY_COMMON_H
 #define _ASM_X86_ENTRY_COMMON_H
 
+#include <linux/randomize_kstack.h>
 #include <linux/user-return-notifier.h>
 
 #include <asm/nospec-branch.h>
@@ -70,6 +71,21 @@ static inline void arch_exit_to_user_mode_prepare(struct pt_regs *regs,
 	 */
 	current_thread_info()->status &= ~(TS_COMPAT | TS_I386_REGS_POKED);
 #endif
+
+	/*
+	 * Ultimately, this value will get limited by KSTACK_OFFSET_MAX(),
+	 * but not enough for x86 stack utilization comfort. To keep
+	 * reasonable stack head room, reduce the maximum offset to 8 bits.
+	 *
+	 * The actual entropy will be further reduced by the compiler when
+	 * applying stack alignment constraints (see cc_stack_align4/8 in
+	 * arch/x86/Makefile), which will remove the 3 (x86_64) or 2 (ia32)
+	 * low bits from any entropy chosen here.
+	 *
+	 * Therefore, final stack offset entropy will be 5 (x86_64) or
+	 * 6 (ia32) bits.
+	 */
+	choose_random_kstack_offset(rdtsc() & 0xFF);
 }
 #define arch_exit_to_user_mode_prepare arch_exit_to_user_mode_prepare
 
-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:41 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:41 -0700
Subject: [PATCH v10 0/6] Optionally randomize kernel stack offset each syscall
Message-ID: <20210401232347.2791257-1-keescook@chromium.org>

Hi!

This should be good to go now. :)

v10:
- switch from "m" to "o" constraint (will)
- switch to raw_cpu_*() (tglx)
- hooked LKDTM test up to kselftest
v9: https://lore.kernel.org/lkml/20210331205458.1871746-1-keescook at chromium.org/
v8: https://lore.kernel.org/lkml/20210330205750.428816-1-keescook at chromium.org/
v7: https://lore.kernel.org/lkml/20210319212835.3928492-1-keescook at chromium.org/
v6: https://lore.kernel.org/lkml/20210315180229.1224655-1-keescook at chromium.org/
v5: https://lore.kernel.org/lkml/20210309214301.678739-1-keescook at chromium.org/
v4: https://lore.kernel.org/lkml/20200622193146.2985288-1-keescook at chromium.org/
v3: https://lore.kernel.org/lkml/20200406231606.37619-1-keescook at chromium.org/
v2: https://lore.kernel.org/lkml/20200324203231.64324-1-keescook at chromium.org/
rfc: https://lore.kernel.org/kernel-hardening/20190329081358.30497-1-elena.reshetova at intel.com/

This is a continuation and refactoring of Elena's earlier effort to add
kernel stack base offset randomization. In the time since the earlier
discussions, two attacks[1][2] were made public that depended on stack
determinism, so we're no longer in the position of "this is a good idea
but we have no examples of attacks". :)

Earlier discussions also devolved into debates on entropy sources, which
is mostly a red herring, given the already low entropy available due
to stack size. Regardless, entropy can be changed/improved separately
from this series as needed.

Earlier discussions also got stuck debating how much syscall overhead
was too much, but this is also a red herring since the feature itself
needs to be selectable at boot with no cost for those that don't want it:
this is solved here with static branches.

So, here is the latest improved version, made as arch-agnostic as
possible, with usage added for x86 and arm64. It also includes some small
static branch clean ups, and addresses some surprise performance issues
due to the stack canary[3].

Thanks!

-Kees

[1] https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
[2] https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf
[3] https://lore.kernel.org/lkml/202003281520.A9BFF461 at keescook/

Kees Cook (6):
  jump_label: Provide CONFIG-driven build state defaults
  init_on_alloc: Optimize static branches
  stack: Optionally randomize kernel stack offset each syscall
  x86/entry: Enable random_kstack_offset support
  arm64: entry: Enable random_kstack_offset support
  lkdtm: Add REPORT_STACK for checking stack offsets

 .../admin-guide/kernel-parameters.txt         | 11 ++++
 Makefile                                      |  4 ++
 arch/Kconfig                                  | 23 ++++++++
 arch/arm64/Kconfig                            |  1 +
 arch/arm64/kernel/Makefile                    |  5 ++
 arch/arm64/kernel/syscall.c                   | 16 ++++++
 arch/x86/Kconfig                              |  1 +
 arch/x86/entry/common.c                       |  3 ++
 arch/x86/include/asm/entry-common.h           | 16 ++++++
 drivers/misc/lkdtm/bugs.c                     | 17 ++++++
 drivers/misc/lkdtm/core.c                     |  1 +
 drivers/misc/lkdtm/lkdtm.h                    |  1 +
 include/linux/jump_label.h                    | 19 +++++++
 include/linux/mm.h                            | 10 ++--
 include/linux/randomize_kstack.h              | 54 +++++++++++++++++++
 init/main.c                                   | 23 ++++++++
 mm/page_alloc.c                               |  4 +-
 mm/slab.h                                     |  6 ++-
 tools/testing/selftests/lkdtm/.gitignore      |  1 +
 tools/testing/selftests/lkdtm/Makefile        |  1 +
 .../testing/selftests/lkdtm/stack-entropy.sh  | 36 +++++++++++++
 21 files changed, 245 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/randomize_kstack.h
 create mode 100755 tools/testing/selftests/lkdtm/stack-entropy.sh

-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:43 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:43 -0700
Subject: [PATCH v10 2/6] init_on_alloc: Optimize static branches
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-3-keescook@chromium.org>

The state of CONFIG_INIT_ON_ALLOC_DEFAULT_ON (and ...ON_FREE...) did not
change the assembly ordering of the static branches: they were always out
of line. Use the new jump_label macros to check the CONFIG settings to
default to the "expected" state, which slightly optimizes the resulting
assembly code.

Reviewed-by: Alexander Potapenko <glider at google.com>
Link: https://lore.kernel.org/lkml/CAG_fn=X0DVwqLaHJTO6Jw7TGcMSm77GKHinrd0m_6y0SzWOrFA at mail.gmail.com/
Acked-by: Vlastimil Babka <vbabka at suse.cz>
Link: https://lore.kernel.org/lkml/5d626b9b-5355-be94-e8e2-1be47f880f30 at suse.cz
Signed-off-by: Kees Cook <keescook at chromium.org>
---
 include/linux/mm.h | 10 ++++++----
 mm/page_alloc.c    |  4 ++--
 mm/slab.h          |  6 ++++--
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 77e64e3eac80..2ccd856ac0d1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2871,18 +2871,20 @@ static inline void kernel_poison_pages(struct page *page, int numpages) { }
 static inline void kernel_unpoison_pages(struct page *page, int numpages) { }
 #endif
 
-DECLARE_STATIC_KEY_FALSE(init_on_alloc);
+DECLARE_STATIC_KEY_MAYBE(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, init_on_alloc);
 static inline bool want_init_on_alloc(gfp_t flags)
 {
-	if (static_branch_unlikely(&init_on_alloc))
+	if (static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON,
+				&init_on_alloc))
 		return true;
 	return flags & __GFP_ZERO;
 }
 
-DECLARE_STATIC_KEY_FALSE(init_on_free);
+DECLARE_STATIC_KEY_MAYBE(CONFIG_INIT_ON_FREE_DEFAULT_ON, init_on_free);
 static inline bool want_init_on_free(void)
 {
-	return static_branch_unlikely(&init_on_free);
+	return static_branch_maybe(CONFIG_INIT_ON_FREE_DEFAULT_ON,
+				   &init_on_free);
 }
 
 extern bool _debug_pagealloc_enabled_early;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3e4b29ee2b1e..267c04b8911d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -167,10 +167,10 @@ unsigned long totalcma_pages __read_mostly;
 
 int percpu_pagelist_fraction;
 gfp_t gfp_allowed_mask __read_mostly = GFP_BOOT_MASK;
-DEFINE_STATIC_KEY_FALSE(init_on_alloc);
+DEFINE_STATIC_KEY_MAYBE(CONFIG_INIT_ON_ALLOC_DEFAULT_ON, init_on_alloc);
 EXPORT_SYMBOL(init_on_alloc);
 
-DEFINE_STATIC_KEY_FALSE(init_on_free);
+DEFINE_STATIC_KEY_MAYBE(CONFIG_INIT_ON_FREE_DEFAULT_ON, init_on_free);
 EXPORT_SYMBOL(init_on_free);
 
 static bool _init_on_alloc_enabled_early __read_mostly
diff --git a/mm/slab.h b/mm/slab.h
index 076582f58f68..774c7221efdc 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -601,7 +601,8 @@ static inline void cache_random_seq_destroy(struct kmem_cache *cachep) { }
 
 static inline bool slab_want_init_on_alloc(gfp_t flags, struct kmem_cache *c)
 {
-	if (static_branch_unlikely(&init_on_alloc)) {
+	if (static_branch_maybe(CONFIG_INIT_ON_ALLOC_DEFAULT_ON,
+				&init_on_alloc)) {
 		if (c->ctor)
 			return false;
 		if (c->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON))
@@ -613,7 +614,8 @@ static inline bool slab_want_init_on_alloc(gfp_t flags, struct kmem_cache *c)
 
 static inline bool slab_want_init_on_free(struct kmem_cache *c)
 {
-	if (static_branch_unlikely(&init_on_free))
+	if (static_branch_maybe(CONFIG_INIT_ON_FREE_DEFAULT_ON,
+				&init_on_free))
 		return !(c->ctor ||
 			 (c->flags & (SLAB_TYPESAFE_BY_RCU | SLAB_POISON)));
 	return false;
-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:42 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:42 -0700
Subject: [PATCH v10 1/6] jump_label: Provide CONFIG-driven build state defaults
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-2-keescook@chromium.org>

As shown in jump_label.h[1], choosing the initial state of static
branches changes the assembly layout. If the condition is expected to
be likely it's inline, and if unlikely it is out of line via a jump. A
few places in the kernel use (or could be using) a CONFIG to choose the
default state, which would give a small performance benefit to their
compile-time declared default. Provide the infrastructure to do this.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/jump_label.h?h=v5.11#n398

Acked-by: Peter Zijlstra (Intel) <peterz at infradead.org>
Link: https://lore.kernel.org/lkml/20200324220641.GT2452 at worktop.programming.kicks-ass.net/
Signed-off-by: Kees Cook <keescook at chromium.org>
---
 include/linux/jump_label.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index d92691262f51..05f5554d860f 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -382,6 +382,21 @@ struct static_key_false {
 		[0 ... (count) - 1] = STATIC_KEY_FALSE_INIT,	\
 	}
 
+#define _DEFINE_STATIC_KEY_1(name)	DEFINE_STATIC_KEY_TRUE(name)
+#define _DEFINE_STATIC_KEY_0(name)	DEFINE_STATIC_KEY_FALSE(name)
+#define DEFINE_STATIC_KEY_MAYBE(cfg, name)			\
+	__PASTE(_DEFINE_STATIC_KEY_, IS_ENABLED(cfg))(name)
+
+#define _DEFINE_STATIC_KEY_RO_1(name)	DEFINE_STATIC_KEY_TRUE_RO(name)
+#define _DEFINE_STATIC_KEY_RO_0(name)	DEFINE_STATIC_KEY_FALSE_RO(name)
+#define DEFINE_STATIC_KEY_MAYBE_RO(cfg, name)			\
+	__PASTE(_DEFINE_STATIC_KEY_RO_, IS_ENABLED(cfg))(name)
+
+#define _DECLARE_STATIC_KEY_1(name)	DECLARE_STATIC_KEY_TRUE(name)
+#define _DECLARE_STATIC_KEY_0(name)	DECLARE_STATIC_KEY_FALSE(name)
+#define DECLARE_STATIC_KEY_MAYBE(cfg, name)			\
+	__PASTE(_DECLARE_STATIC_KEY_, IS_ENABLED(cfg))(name)
+
 extern bool ____wrong_branch_error(void);
 
 #define static_key_enabled(x)							\
@@ -482,6 +497,10 @@ extern bool ____wrong_branch_error(void);
 
 #endif /* CONFIG_JUMP_LABEL */
 
+#define static_branch_maybe(config, x)					\
+	(IS_ENABLED(config) ? static_branch_likely(x)			\
+			    : static_branch_unlikely(x))
+
 /*
  * Advanced usage; refcount, branch is enabled when: count != 0
  */
-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:44 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:44 -0700
Subject: [PATCH v10 3/6] stack: Optionally randomize kernel stack offset each
 syscall
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-4-keescook@chromium.org>

This provides the ability for architectures to enable kernel stack base
address offset randomization. This feature is controlled by the boot
param "randomize_kstack_offset=on/off", with its default value set by
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.

This feature is based on the original idea from the last public release
of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt
All the credit for the original idea goes to the PaX team. Note that
the design and implementation of this upstream randomize_kstack_offset
feature differs greatly from the RANDKSTACK feature (see below).

Reasoning for the feature:

This feature aims to make harder the various stack-based attacks that
rely on deterministic stack structure. We have had many such attacks in
past (just to name few):

https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf
https://jon.oberheide.org/files/stackjacking-infiltrate11.pdf
https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html

As Linux kernel stack protections have been constantly improving
(vmap-based stack allocation with guard pages, removal of thread_info,
STACKLEAK), attackers have had to find new ways for their exploits
to work. They have done so, continuing to rely on the kernel's stack
determinism, in situations where VMAP_STACK and THREAD_INFO_IN_TASK_STRUCT
were not relevant. For example, the following recent attacks would have
been hampered if the stack offset was non-deterministic between syscalls:

https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf
(page 70: targeting the pt_regs copy with linear stack overflow)

https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
(leaked stack address from one syscall as a target during next syscall)

The main idea is that since the stack offset is randomized on each system
call, it is harder for an attack to reliably land in any particular place
on the thread stack, even with address exposures, as the stack base will
change on the next syscall. Also, since randomization is performed after
placing pt_regs, the ptrace-based approach[1] to discover the randomized
offset during a long-running syscall should not be possible.

Design description:

During most of the kernel's execution, it runs on the "thread stack",
which is pretty deterministic in its structure: it is fixed in size,
and on every entry from userspace to kernel on a syscall the thread
stack starts construction from an address fetched from the per-cpu
cpu_current_top_of_stack variable. The first element to be pushed to the
thread stack is the pt_regs struct that stores all required CPU registers
and syscall parameters. Finally the specific syscall function is called,
with the stack being used as the kernel executes the resulting request.

The goal of randomize_kstack_offset feature is to add a random offset
after the pt_regs has been pushed to the stack and before the rest of the
thread stack is used during the syscall processing, and to change it every
time a process issues a syscall. The source of randomness is currently
architecture-defined (but x86 is using the low byte of rdtsc()). Future
improvements for different entropy sources is possible, but out of scope
for this patch. Further more, to add more unpredictability, new offsets
are chosen at the end of syscalls (the timing of which should be less
easy to measure from userspace than at syscall entry time), and stored
in a per-CPU variable, so that the life of the value does not stay
explicitly tied to a single task.

As suggested by Andy Lutomirski, the offset is added using alloca()
and an empty asm() statement with an output constraint, since it avoids
changes to assembly syscall entry code, to the unwinder, and provides
correct stack alignment as defined by the compiler.

In order to make this available by default with zero performance impact
for those that don't want it, it is boot-time selectable with static
branches. This way, if the overhead is not wanted, it can just be
left turned off with no performance impact.

The generated assembly for x86_64 with GCC looks like this:

...
ffffffff81003977: 65 8b 05 02 ea 00 7f  mov %gs:0x7f00ea02(%rip),%eax
					    # 12380 <kstack_offset>
ffffffff8100397e: 25 ff 03 00 00        and $0x3ff,%eax
ffffffff81003983: 48 83 c0 0f           add $0xf,%rax
ffffffff81003987: 25 f8 07 00 00        and $0x7f8,%eax
ffffffff8100398c: 48 29 c4              sub %rax,%rsp
ffffffff8100398f: 48 8d 44 24 0f        lea 0xf(%rsp),%rax
ffffffff81003994: 48 83 e0 f0           and $0xfffffffffffffff0,%rax
...

As a result of the above stack alignment, this patch introduces about
5 bits of randomness after pt_regs is spilled to the thread stack on
x86_64, and 6 bits on x86_32 (since its has 1 fewer bit required for
stack alignment). The amount of entropy could be adjusted based on how
much of the stack space we wish to trade for security.

My measure of syscall performance overhead (on x86_64):

lmbench: /usr/lib/lmbench/bin/x86_64-linux-gnu/lat_syscall -N 10000 null
    randomize_kstack_offset=y	Simple syscall: 0.7082 microseconds
    randomize_kstack_offset=n	Simple syscall: 0.7016 microseconds

So, roughly 0.9% overhead growth for a no-op syscall, which is very
manageable. And for people that don't want this, it's off by default.

There are two gotchas with using the alloca() trick. First,
compilers that have Stack Clash protection (-fstack-clash-protection)
enabled by default (e.g. Ubuntu[3]) add pagesize stack probes to
any dynamic stack allocations. While the randomization offset is
always less than a page, the resulting assembly would still contain
(unreachable!) probing routines, bloating the resulting assembly. To
avoid this, -fno-stack-clash-protection is unconditionally added to
the kernel Makefile since this is the only dynamic stack allocation in
the kernel (now that VLAs have been removed) and it is provably safe
from Stack Clash style attacks.

The second gotcha with alloca() is a negative interaction with
-fstack-protector*, in that it sees the alloca() as an array allocation,
which triggers the unconditional addition of the stack canary function
pre/post-amble which slows down syscalls regardless of the static
branch. In order to avoid adding this unneeded check and its associated
performance impact, architectures need to carefully remove uses of
-fstack-protector-strong (or -fstack-protector) in the compilation units
that use the add_random_kstack() macro and to audit the resulting stack
mitigation coverage (to make sure no desired coverage disappears). No
change is visible for this on x86 because the stack protector is already
unconditionally disabled for the compilation unit, but the change is
required on arm64. There is, unfortunately, no attribute that can be
used to disable stack protector for specific functions.

Comparison to PaX RANDKSTACK feature:

The RANDKSTACK feature randomizes the location of the stack start
(cpu_current_top_of_stack), i.e. including the location of pt_regs
structure itself on the stack. Initially this patch followed the same
approach, but during the recent discussions[2], it has been determined
to be of a little value since, if ptrace functionality is available for
an attacker, they can use PTRACE_PEEKUSR/PTRACE_POKEUSR to read/write
different offsets in the pt_regs struct, observe the cache behavior of
the pt_regs accesses, and figure out the random stack offset. Another
difference is that the random offset is stored in a per-cpu variable,
rather than having it be per-thread. As a result, these implementations
differ a fair bit in their implementation details and results, though
obviously the intent is similar.

[1] https://lore.kernel.org/kernel-hardening/2236FBA76BA1254E88B949DDB74E612BA4BC57C1 at IRSMSX102.ger.corp.intel.com/
[2] https://lore.kernel.org/kernel-hardening/20190329081358.30497-1-elena.reshetova at intel.com/
[3] https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html

Co-developed-by: Elena Reshetova <elena.reshetova at intel.com>
Signed-off-by: Elena Reshetova <elena.reshetova at intel.com>
Link: https://lore.kernel.org/r/20190415060918.3766-1-elena.reshetova at intel.com
Reviewed-by: Thomas Gleixner <tglx at linutronix.de>
Link: https://lore.kernel.org/lkml/87im5769op.ffs at nanos.tec.linutronix.de/
Signed-off-by: Kees Cook <keescook at chromium.org>
---
 .../admin-guide/kernel-parameters.txt         | 11 ++++
 Makefile                                      |  4 ++
 arch/Kconfig                                  | 23 ++++++++
 include/linux/randomize_kstack.h              | 54 +++++++++++++++++++
 init/main.c                                   | 23 ++++++++
 5 files changed, 115 insertions(+)
 create mode 100644 include/linux/randomize_kstack.h

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..bee8644a192e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4061,6 +4061,17 @@
 			fully seed the kernel's CRNG. Default is controlled
 			by CONFIG_RANDOM_TRUST_CPU.
 
+	randomize_kstack_offset=
+			[KNL] Enable or disable kernel stack offset
+			randomization, which provides roughly 5 bits of
+			entropy, frustrating memory corruption attacks
+			that depend on stack address determinism or
+			cross-syscall address exposures. This is only
+			available on architectures that have defined
+			CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET.
+			Format: <bool>  (1/Y/y=enable, 0/N/n=disable)
+			Default is CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.
+
 	ras=option[,option,...]	[KNL] RAS-specific options
 
 		cec_disable	[X86]
diff --git a/Makefile b/Makefile
index 31dcdb3d61fa..8a959a264588 100644
--- a/Makefile
+++ b/Makefile
@@ -811,6 +811,10 @@ KBUILD_CFLAGS	+= -ftrivial-auto-var-init=zero
 KBUILD_CFLAGS	+= -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
 endif
 
+# While VLAs have been removed, GCC produces unreachable stack probes
+# for the randomize_kstack_offset feature. Disable it for all compilers.
+KBUILD_CFLAGS	+= $(call cc-option, -fno-stack-clash-protection)
+
 DEBUG_CFLAGS	:=
 
 # Workaround for GCC versions < 5.0
diff --git a/arch/Kconfig b/arch/Kconfig
index 2bb30673d8e6..4fe6b047fcbc 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1055,6 +1055,29 @@ config VMAP_STACK
 	  backing virtual mappings with real shadow memory, and KASAN_VMALLOC
 	  must be enabled.
 
+config HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
+	def_bool n
+	help
+	  An arch should select this symbol if it can support kernel stack
+	  offset randomization with calls to add_random_kstack_offset()
+	  during syscall entry and choose_random_kstack_offset() during
+	  syscall exit. Careful removal of -fstack-protector-strong and
+	  -fstack-protector should also be applied to the entry code and
+	  closely examined, as the artificial stack bump looks like an array
+	  to the compiler, so it will attempt to add canary checks regardless
+	  of the static branch state.
+
+config RANDOMIZE_KSTACK_OFFSET_DEFAULT
+	bool "Randomize kernel stack offset on syscall entry"
+	depends on HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
+	help
+	  The kernel stack offset can be randomized (after pt_regs) by
+	  roughly 5 bits of entropy, frustrating memory corruption
+	  attacks that depend on stack address determinism or
+	  cross-syscall address exposures. This feature is controlled
+	  by kernel boot param "randomize_kstack_offset=on/off", and this
+	  config chooses the default boot state.
+
 config ARCH_OPTIONAL_KERNEL_RWX
 	def_bool n
 
diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h
new file mode 100644
index 000000000000..fd80fab663a9
--- /dev/null
+++ b/include/linux/randomize_kstack.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _LINUX_RANDOMIZE_KSTACK_H
+#define _LINUX_RANDOMIZE_KSTACK_H
+
+#include <linux/kernel.h>
+#include <linux/jump_label.h>
+#include <linux/percpu-defs.h>
+
+DECLARE_STATIC_KEY_MAYBE(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,
+			 randomize_kstack_offset);
+DECLARE_PER_CPU(u32, kstack_offset);
+
+/*
+ * Do not use this anywhere else in the kernel. This is used here because
+ * it provides an arch-agnostic way to grow the stack with correct
+ * alignment. Also, since this use is being explicitly masked to a max of
+ * 10 bits, stack-clash style attacks are unlikely. For more details see
+ * "VLAs" in Documentation/process/deprecated.rst
+ */
+void *__builtin_alloca(size_t size);
+/*
+ * Use, at most, 10 bits of entropy. We explicitly cap this to keep the
+ * "VLA" from being unbounded (see above). 10 bits leaves enough room for
+ * per-arch offset masks to reduce entropy (by removing higher bits, since
+ * high entropy may overly constrain usable stack space), and for
+ * compiler/arch-specific stack alignment to remove the lower bits.
+ */
+#define KSTACK_OFFSET_MAX(x)	((x) & 0x3FF)
+
+/*
+ * These macros must be used during syscall entry when interrupts and
+ * preempt are disabled, and after user registers have been stored to
+ * the stack.
+ */
+#define add_random_kstack_offset() do {					\
+	if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,	\
+				&randomize_kstack_offset)) {		\
+		u32 offset = raw_cpu_read(kstack_offset);		\
+		u8 *ptr = __builtin_alloca(KSTACK_OFFSET_MAX(offset));	\
+		/* Keep allocation even after "ptr" loses scope. */	\
+		asm volatile("" : "=o"(*ptr) :: "memory");		\
+	}								\
+} while (0)
+
+#define choose_random_kstack_offset(rand) do {				\
+	if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,	\
+				&randomize_kstack_offset)) {		\
+		u32 offset = raw_cpu_read(kstack_offset);		\
+		offset ^= (rand);					\
+		raw_cpu_write(kstack_offset, offset);			\
+	}								\
+} while (0)
+
+#endif
diff --git a/init/main.c b/init/main.c
index 53b278845b88..f498aac26e8c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -844,6 +844,29 @@ static void __init mm_init(void)
 	pti_init();
 }
 
+#ifdef CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
+DEFINE_STATIC_KEY_MAYBE_RO(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,
+			   randomize_kstack_offset);
+DEFINE_PER_CPU(u32, kstack_offset);
+
+static int __init early_randomize_kstack_offset(char *buf)
+{
+	int ret;
+	bool bool_result;
+
+	ret = kstrtobool(buf, &bool_result);
+	if (ret)
+		return ret;
+
+	if (bool_result)
+		static_branch_enable(&randomize_kstack_offset);
+	else
+		static_branch_disable(&randomize_kstack_offset);
+	return 0;
+}
+early_param("randomize_kstack_offset", early_randomize_kstack_offset);
+#endif
+
 void __init __weak arch_call_rest_init(void)
 {
 	rest_init();
-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:46 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:46 -0700
Subject: [PATCH v10 5/6] arm64: entry: Enable random_kstack_offset support
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-6-keescook@chromium.org>

Allow for a randomized stack offset on a per-syscall basis, with roughly
5 bits of entropy. (And include AAPCS rationale AAPCS thanks to Mark
Rutland.)

In order to avoid unconditional stack canaries on syscall entry (due to
the use of alloca()), also disable stack protector to avoid triggering
needless checks and slowing down the entry path. As there is no general
way to control stack protector coverage with a function attribute[1],
this must be disabled at the compilation unit level. This isn't a problem
here, though, since stack protector was not triggered before: examining
the resulting syscall.o, there are no changes in canary coverage (none
before, none now).

[1] a working __attribute__((no_stack_protector)) has been added to GCC
and Clang but has not been released in any version yet:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=346b302d09c1e6db56d9fe69048acb32fbb97845
https://reviews.llvm.org/rG4fbf84c1732fca596ad1d6e96015e19760eb8a9b

Signed-off-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/Kconfig          |  1 +
 arch/arm64/kernel/Makefile  |  5 +++++
 arch/arm64/kernel/syscall.c | 16 ++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f212b47a48a..2d0e5f544429 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -146,6 +146,7 @@ config ARM64
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
 	select HAVE_ARCH_PFN_VALID
 	select HAVE_ARCH_PREL32_RELOCATIONS
+	select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_ARCH_STACKLEAK
 	select HAVE_ARCH_THREAD_STRUCT_WHITELIST
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index ed65576ce710..6cc97730790e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -9,6 +9,11 @@ CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_insn.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_return_address.o = $(CC_FLAGS_FTRACE)
 
+# Remove stack protector to avoid triggering unneeded stack canary
+# checks due to randomize_kstack_offset.
+CFLAGS_REMOVE_syscall.o	 = -fstack-protector -fstack-protector-strong
+CFLAGS_syscall.o	+= -fno-stack-protector
+
 # Object file lists.
 obj-y			:= debug-monitors.o entry.o irq.o fpsimd.o		\
 			   entry-common.o entry-fpsimd.o process.o ptrace.o	\
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index b9cf12b271d7..263d6c1a525f 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -5,6 +5,7 @@
 #include <linux/errno.h>
 #include <linux/nospec.h>
 #include <linux/ptrace.h>
+#include <linux/randomize_kstack.h>
 #include <linux/syscalls.h>
 
 #include <asm/daifflags.h>
@@ -43,6 +44,8 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
 {
 	long ret;
 
+	add_random_kstack_offset();
+
 	if (scno < sc_nr) {
 		syscall_fn_t syscall_fn;
 		syscall_fn = syscall_table[array_index_nospec(scno, sc_nr)];
@@ -55,6 +58,19 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
 		ret = lower_32_bits(ret);
 
 	regs->regs[0] = ret;
+
+	/*
+	 * Ultimately, this value will get limited by KSTACK_OFFSET_MAX(),
+	 * but not enough for arm64 stack utilization comfort. To keep
+	 * reasonable stack head room, reduce the maximum offset to 9 bits.
+	 *
+	 * The actual entropy will be further reduced by the compiler when
+	 * applying stack alignment constraints: the AAPCS mandates a
+	 * 16-byte (i.e. 4-bit) aligned SP at function boundaries.
+	 *
+	 * The resulting 5 bits of entropy is seen in SP[8:4].
+	 */
+	choose_random_kstack_offset(get_random_int() & 0x1FF);
 }
 
 static inline bool has_syscall_work(unsigned long flags)
-- 
2.25.1



From keescook at chromium.org  Fri Apr  2 00:23:47 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu,  1 Apr 2021 16:23:47 -0700
Subject: [PATCH v10 6/6] lkdtm: Add REPORT_STACK for checking stack offsets
In-Reply-To: <20210401232347.2791257-1-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
Message-ID: <20210401232347.2791257-7-keescook@chromium.org>

For validating the stack offset behavior, report the offset from a given
process's first seen stack address. Add script to calculate the results
to the LKDTM kselftests.

Signed-off-by: Kees Cook <keescook at chromium.org>
---
 drivers/misc/lkdtm/bugs.c                     | 17 +++++++++
 drivers/misc/lkdtm/core.c                     |  1 +
 drivers/misc/lkdtm/lkdtm.h                    |  1 +
 tools/testing/selftests/lkdtm/.gitignore      |  1 +
 tools/testing/selftests/lkdtm/Makefile        |  1 +
 .../testing/selftests/lkdtm/stack-entropy.sh  | 36 +++++++++++++++++++
 6 files changed, 57 insertions(+)
 create mode 100755 tools/testing/selftests/lkdtm/stack-entropy.sh

diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index 110f5a8538e9..0e8254d0cf0b 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -134,6 +134,23 @@ noinline void lkdtm_CORRUPT_STACK_STRONG(void)
 	__lkdtm_CORRUPT_STACK((void *)&data);
 }
 
+static pid_t stack_pid;
+static unsigned long stack_addr;
+
+void lkdtm_REPORT_STACK(void)
+{
+	volatile uintptr_t magic;
+	pid_t pid = task_pid_nr(current);
+
+	if (pid != stack_pid) {
+		pr_info("Starting stack offset tracking for pid %d\n", pid);
+		stack_pid = pid;
+		stack_addr = (uintptr_t)&magic;
+	}
+
+	pr_info("Stack offset: %d\n", (int)(stack_addr - (uintptr_t)&magic));
+}
+
 void lkdtm_UNALIGNED_LOAD_STORE_WRITE(void)
 {
 	static u8 data[5] __attribute__((aligned(4))) = {1, 2, 3, 4, 5};
diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index b2aff4d87c01..8024b6a5cc7f 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -110,6 +110,7 @@ static const struct crashtype crashtypes[] = {
 	CRASHTYPE(EXHAUST_STACK),
 	CRASHTYPE(CORRUPT_STACK),
 	CRASHTYPE(CORRUPT_STACK_STRONG),
+	CRASHTYPE(REPORT_STACK),
 	CRASHTYPE(CORRUPT_LIST_ADD),
 	CRASHTYPE(CORRUPT_LIST_DEL),
 	CRASHTYPE(STACK_GUARD_PAGE_LEADING),
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 5ae48c64df24..99f90d3e5e9c 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -17,6 +17,7 @@ void lkdtm_LOOP(void);
 void lkdtm_EXHAUST_STACK(void);
 void lkdtm_CORRUPT_STACK(void);
 void lkdtm_CORRUPT_STACK_STRONG(void);
+void lkdtm_REPORT_STACK(void);
 void lkdtm_UNALIGNED_LOAD_STORE_WRITE(void);
 void lkdtm_SOFTLOCKUP(void);
 void lkdtm_HARDLOCKUP(void);
diff --git a/tools/testing/selftests/lkdtm/.gitignore b/tools/testing/selftests/lkdtm/.gitignore
index f26212605b6b..d4b0be857deb 100644
--- a/tools/testing/selftests/lkdtm/.gitignore
+++ b/tools/testing/selftests/lkdtm/.gitignore
@@ -1,2 +1,3 @@
 *.sh
 !run.sh
+!stack-entropy.sh
diff --git a/tools/testing/selftests/lkdtm/Makefile b/tools/testing/selftests/lkdtm/Makefile
index 1bcc9ee990eb..c71109ceeb2d 100644
--- a/tools/testing/selftests/lkdtm/Makefile
+++ b/tools/testing/selftests/lkdtm/Makefile
@@ -5,6 +5,7 @@ include ../lib.mk
 
 # NOTE: $(OUTPUT) won't get default value if used before lib.mk
 TEST_FILES := tests.txt
+TEST_PROGS := stack-entropy.sh
 TEST_GEN_PROGS = $(patsubst %,$(OUTPUT)/%.sh,$(shell awk '{print $$1}' tests.txt | sed -e 's/\#//'))
 all: $(TEST_GEN_PROGS)
 
diff --git a/tools/testing/selftests/lkdtm/stack-entropy.sh b/tools/testing/selftests/lkdtm/stack-entropy.sh
new file mode 100755
index 000000000000..b1b8a5097cbb
--- /dev/null
+++ b/tools/testing/selftests/lkdtm/stack-entropy.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Measure kernel stack entropy by sampling via LKDTM's REPORT_STACK test.
+set -e
+samples="${1:-1000}"
+
+# Capture dmesg continuously since it may fill up depending on sample size.
+log=$(mktemp -t stack-entropy-XXXXXX)
+dmesg --follow >"$log" & pid=$!
+report=-1
+for i in $(seq 1 $samples); do
+        echo "REPORT_STACK" >/sys/kernel/debug/provoke-crash/DIRECT
+	if [ -t 1 ]; then
+		percent=$(( 100 * $i / $samples ))
+		if [ "$percent" -ne "$report" ]; then
+			/bin/echo -en "$percent%\r"
+			report="$percent"
+		fi
+	fi
+done
+kill "$pid"
+
+# Count unique offsets since last run.
+seen=$(tac "$log" | grep -m1 -B"$samples"0 'Starting stack offset' | \
+	grep 'Stack offset' | awk '{print $NF}' | sort | uniq -c | wc -l)
+bits=$(echo "obase=2; $seen" | bc | wc -L)
+echo "Bits of stack entropy: $bits"
+rm -f "$log"
+
+# We would expect any functional stack randomization to be at least 5 bits.
+if [ "$bits" -lt 5 ]; then
+	exit 1
+else
+	exit 0
+fi
-- 
2.25.1



From lkp at intel.com  Fri Apr  2 00:29:12 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 07:29:12 +0800
Subject: [xlnx:xlnx_rebase_v5.4 935/1701] trace.c:(.text+0x1c50): multiple
 definition of `dwc3_mask_phy_reset';
 drivers/usb/dwc3/core.o:core.c:(.text+0xea0): first defined here
Message-ID: <202104020703.kROaiw4I-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 128feece434d1c02d2dfac7e4103b2c73b6afb27 [935/1701] usb: dwc3: Add support for masking phy reset signal
config: i386-randconfig-c021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/128feece434d1c02d2dfac7e4103b2c73b6afb27
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 128feece434d1c02d2dfac7e4103b2c73b6afb27
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1451:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1451 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1453:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1453 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1455:6: warning: no previous prototype for 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
    1455 | void dwc3_simple_check_quirks(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1457:5: warning: no previous prototype for 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
    1457 | int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
         |     ^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.h:1459:6: warning: no previous prototype for 'dwc3_mask_phy_reset' [-Wmissing-prototypes]
    1459 | void dwc3_mask_phy_reset(struct device *dev, bool mask)
         |      ^~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.c:386:6: warning: no previous prototype for 'dwc3_free_event_buffers' [-Wmissing-prototypes]
     386 | void dwc3_free_event_buffers(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.c:403:5: warning: no previous prototype for 'dwc3_alloc_event_buffers' [-Wmissing-prototypes]
     403 | int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
         |     ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.c:977:5: warning: no previous prototype for 'dwc3_core_init' [-Wmissing-prototypes]
     977 | int dwc3_core_init(struct dwc3 *dwc)
         |     ^~~~~~~~~~~~~~
   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h: In function 'dwc3_set_usb_core_power':
   drivers/usb/dwc3/core.h:1458:5: warning: control reaches end of non-void function [-Wreturn-type]
    1458 | { ; }
         |     ^
--
   In file included from drivers/usb/dwc3/trace.h:19,
                    from drivers/usb/dwc3/trace.c:11:
   drivers/usb/dwc3/core.h:1451:6: warning: no previous prototype for 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
    1451 | void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1453:6: warning: no previous prototype for 'dwc3_set_simple_data' [-Wmissing-prototypes]
    1453 | void dwc3_set_simple_data(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1455:6: warning: no previous prototype for 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
    1455 | void dwc3_simple_check_quirks(struct dwc3 *dwc)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h:1457:5: warning: no previous prototype for 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
    1457 | int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
         |     ^~~~~~~~~~~~~~~~~~~~~~~
>> drivers/usb/dwc3/core.h:1459:6: warning: no previous prototype for 'dwc3_mask_phy_reset' [-Wmissing-prototypes]
    1459 | void dwc3_mask_phy_reset(struct device *dev, bool mask)
         |      ^~~~~~~~~~~~~~~~~~~
   drivers/usb/dwc3/core.h: In function 'dwc3_set_usb_core_power':
   drivers/usb/dwc3/core.h:1458:5: warning: control reaches end of non-void function [-Wreturn-type]
    1458 | { ; }
         |     ^
--
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_wakeup_capable':
   trace.c:(.text+0x1c10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0xe60): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_simple_data':
   trace.c:(.text+0x1c20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0xe70): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_simple_check_quirks':
   trace.c:(.text+0x1c30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0xe80): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_set_usb_core_power':
   trace.c:(.text+0x1c40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0xe90): first defined here
   ld: drivers/usb/dwc3/trace.o: in function `dwc3_mask_phy_reset':
>> trace.c:(.text+0x1c50): multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:core.c:(.text+0xea0): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_wakeup_capable':
   host.c:(.text+0x10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0xe60): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_simple_data':
   host.c:(.text+0x20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0xe70): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_simple_check_quirks':
   host.c:(.text+0x30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0xe80): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_set_usb_core_power':
   host.c:(.text+0x40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0xe90): first defined here
   ld: drivers/usb/dwc3/host.o: in function `dwc3_mask_phy_reset':
   host.c:(.text+0x50): multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:core.c:(.text+0xea0): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_wakeup_capable':
   ulpi.c:(.text+0xa80): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0xe60): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_simple_data':
   ulpi.c:(.text+0xa90): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0xe70): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_simple_check_quirks':
   ulpi.c:(.text+0xaa0): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0xe80): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_set_usb_core_power':
   ulpi.c:(.text+0xab0): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0xe90): first defined here
   ld: drivers/usb/dwc3/ulpi.o: in function `dwc3_mask_phy_reset':
   ulpi.c:(.text+0xac0): multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:core.c:(.text+0xea0): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_wakeup_capable':
   debugfs.c:(.text+0xa10): multiple definition of `dwc3_simple_wakeup_capable'; drivers/usb/dwc3/core.o:core.c:(.text+0xe60): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_simple_data':
   debugfs.c:(.text+0xa20): multiple definition of `dwc3_set_simple_data'; drivers/usb/dwc3/core.o:core.c:(.text+0xe70): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_simple_check_quirks':
   debugfs.c:(.text+0xa30): multiple definition of `dwc3_simple_check_quirks'; drivers/usb/dwc3/core.o:core.c:(.text+0xe80): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_set_usb_core_power':
   debugfs.c:(.text+0xa40): multiple definition of `dwc3_set_usb_core_power'; drivers/usb/dwc3/core.o:core.c:(.text+0xe90): first defined here
   ld: drivers/usb/dwc3/debugfs.o: in function `dwc3_mask_phy_reset':
   debugfs.c:(.text+0xa50): multiple definition of `dwc3_mask_phy_reset'; drivers/usb/dwc3/core.o:core.c:(.text+0xea0): first defined here

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35311 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/44767741/attachment-0001.gz>

From samitolvanen at google.com  Fri Apr  2 00:31:58 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:31:58 -0700
Subject: [PATCH v5 00/18] Add support for Clang CFI
Message-ID: <20210401233216.2540591-1-samitolvanen@google.com>

This series adds support for Clang's Control-Flow Integrity (CFI)
checking. With CFI, the compiler injects a runtime check before 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. For more details, see:

  https://clang.llvm.org/docs/ControlFlowIntegrity.html

The first patch contains build system changes and error handling,
and implements support for cross-module indirect call checking. The
remaining patches address issues caused by the compiler
instrumentation. These include fixing known type mismatches, as well
as issues with address space confusion and cross-module function
address equality.

These patches add support only for arm64, but I'll post patches also
for x86_64 after we address the remaining issues there, including
objtool support.

You can also pull this series from

  https://github.com/samitolvanen/linux.git cfi-v5

---
Changes in v5:
 - Changed module.lds.S to only include <asm/page.h> when CFI is
   enabled to fix the MIPS build.
 - Added a patch that fixes dynamic ftrace with CFI on arm64.

Changes in v4:
 - Per Mark's suggestion, dropped __pa_function() and renamed
   __va_function() to function_nocfi().
 - Added a comment to function_nocfi() to explain what it does.
 - Updated the psci patch to use an intermediate variable for
   the physical address for clarity.

Changes in v3:
 - Added a patch to change list_sort() callers treewide to use
   const pointers instead of simply removing the internal casts.
 - Changed cleanup_symbol_name() to return bool.
 - Changed module.lds.S to drop the .eh_frame section only with
   CONFIG_CFI_CLANG.
 - Switched to synchronize_rcu() in update_shadow().

Changes in v2:
 - Fixed .text merging in module.lds.S.
 - Added WARN_ON_FUNCTION_MISMATCH() and changed kernel/thread.c
   and kernel/workqueue.c to use the macro instead.


Sami Tolvanen (18):
  add support for Clang CFI
  cfi: add __cficanonical
  mm: add generic function_nocfi macro
  module: ensure __cfi_check alignment
  workqueue: use WARN_ON_FUNCTION_MISMATCH
  kthread: use WARN_ON_FUNCTION_MISMATCH
  kallsyms: strip ThinLTO hashes from static functions
  bpf: disable CFI in dispatcher functions
  treewide: Change list_sort to use const pointers
  lkdtm: use function_nocfi
  psci: use function_nocfi for cpu_resume
  arm64: implement function_nocfi
  arm64: use function_nocfi with __pa_symbol
  arm64: add __nocfi to functions that jump to a physical address
  arm64: add __nocfi to __apply_alternatives
  arm64: ftrace: use function_nocfi for ftrace_call
  KVM: arm64: Disable CFI for nVHE
  arm64: allow CONFIG_CFI_CLANG to be selected

 Makefile                                      |  17 +
 arch/Kconfig                                  |  45 +++
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/memory.h               |  15 +
 arch/arm64/include/asm/mmu_context.h          |   4 +-
 arch/arm64/kernel/acpi_parking_protocol.c     |   3 +-
 arch/arm64/kernel/alternative.c               |   4 +-
 arch/arm64/kernel/cpu-reset.h                 |  10 +-
 arch/arm64/kernel/cpufeature.c                |   4 +-
 arch/arm64/kernel/ftrace.c                    |   2 +-
 arch/arm64/kernel/psci.c                      |   3 +-
 arch/arm64/kernel/smp_spin_table.c            |   3 +-
 arch/arm64/kvm/hyp/nvhe/Makefile              |   6 +-
 arch/arm64/kvm/vgic/vgic-its.c                |   8 +-
 arch/arm64/kvm/vgic/vgic.c                    |   3 +-
 block/blk-mq-sched.c                          |   3 +-
 block/blk-mq.c                                |   3 +-
 drivers/acpi/nfit/core.c                      |   3 +-
 drivers/acpi/numa/hmat.c                      |   3 +-
 drivers/clk/keystone/sci-clk.c                |   4 +-
 drivers/firmware/psci/psci.c                  |   7 +-
 drivers/gpu/drm/drm_modes.c                   |   3 +-
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |   3 +-
 drivers/gpu/drm/i915/gvt/debugfs.c            |   2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   3 +-
 drivers/gpu/drm/radeon/radeon_cs.c            |   4 +-
 .../hw/usnic/usnic_uiom_interval_tree.c       |   3 +-
 drivers/interconnect/qcom/bcm-voter.c         |   2 +-
 drivers/md/raid5.c                            |   3 +-
 drivers/misc/lkdtm/usercopy.c                 |   2 +-
 drivers/misc/sram.c                           |   4 +-
 drivers/nvme/host/core.c                      |   3 +-
 .../controller/cadence/pcie-cadence-host.c    |   3 +-
 drivers/spi/spi-loopback-test.c               |   3 +-
 fs/btrfs/raid56.c                             |   3 +-
 fs/btrfs/tree-log.c                           |   3 +-
 fs/btrfs/volumes.c                            |   3 +-
 fs/ext4/fsmap.c                               |   4 +-
 fs/gfs2/glock.c                               |   3 +-
 fs/gfs2/log.c                                 |   2 +-
 fs/gfs2/lops.c                                |   3 +-
 fs/iomap/buffered-io.c                        |   3 +-
 fs/ubifs/gc.c                                 |   7 +-
 fs/ubifs/replay.c                             |   4 +-
 fs/xfs/scrub/bitmap.c                         |   4 +-
 fs/xfs/xfs_bmap_item.c                        |   4 +-
 fs/xfs/xfs_buf.c                              |   6 +-
 fs/xfs/xfs_extent_busy.c                      |   4 +-
 fs/xfs/xfs_extent_busy.h                      |   3 +-
 fs/xfs/xfs_extfree_item.c                     |   4 +-
 fs/xfs/xfs_refcount_item.c                    |   4 +-
 fs/xfs/xfs_rmap_item.c                        |   4 +-
 include/asm-generic/bug.h                     |  16 +
 include/asm-generic/vmlinux.lds.h             |  20 +-
 include/linux/bpf.h                           |   4 +-
 include/linux/cfi.h                           |  41 +++
 include/linux/compiler-clang.h                |   3 +
 include/linux/compiler_types.h                |   8 +
 include/linux/init.h                          |   6 +-
 include/linux/list_sort.h                     |   7 +-
 include/linux/mm.h                            |  10 +
 include/linux/module.h                        |  13 +-
 include/linux/pci.h                           |   4 +-
 init/Kconfig                                  |   2 +-
 kernel/Makefile                               |   4 +
 kernel/cfi.c                                  | 329 ++++++++++++++++++
 kernel/kallsyms.c                             |  55 ++-
 kernel/kthread.c                              |   3 +-
 kernel/module.c                               |  43 +++
 kernel/workqueue.c                            |   2 +-
 lib/list_sort.c                               |  17 +-
 lib/test_list_sort.c                          |   3 +-
 net/tipc/name_table.c                         |   4 +-
 scripts/Makefile.modfinal                     |   2 +-
 scripts/module.lds.S                          |  19 +-
 75 files changed, 759 insertions(+), 113 deletions(-)
 create mode 100644 include/linux/cfi.h
 create mode 100644 kernel/cfi.c


base-commit: 6905b1dc3c32a094f0da61bd656a740f0a97d592
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:31:59 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:31:59 -0700
Subject: [PATCH v5 01/18] add support for Clang CFI
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-2-samitolvanen@google.com>

This change adds support for Clang?s forward-edge Control Flow
Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
injects a runtime check before 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. For more details, see:

  https://clang.llvm.org/docs/ControlFlowIntegrity.html

Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
visibility to possible call targets. Kernel modules are supported
with Clang?s cross-DSO CFI mode, which allows checking between
independently compiled components.

With CFI enabled, the compiler injects a __cfi_check() function into
the kernel and each module for validating local call targets. For
cross-module calls that cannot be validated locally, the compiler
calls the global __cfi_slowpath_diag() function, which determines
the target module and calls the correct __cfi_check() function. This
patch includes a slowpath implementation that uses __module_address()
to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
shadow map that speeds up module look-ups by ~3x.

Clang implements indirect call checking using jump tables and
offers two methods of generating them. With canonical jump tables,
the compiler renames each address-taken function to <function>.cfi
and points the original symbol to a jump table entry, which passes
__cfi_check() validation. This isn?t compatible with stand-alone
assembly code, which the compiler doesn?t instrument, and would
result in indirect calls to assembly code to fail. Therefore, we
default to using non-canonical jump tables instead, where the compiler
generates a local jump table entry <function>.cfi_jt for each
address-taken function, and replaces all references to the function
with the address of the jump table entry.

Note that because non-canonical jump table addresses are local
to each component, they break cross-module function address
equality. Specifically, the address of a global function will be
different in each module, as it's replaced with the address of a local
jump table entry. If this address is passed to a different module,
it won?t match the address of the same function taken there. This
may break code that relies on comparing addresses passed from other
components.

CFI checking can be disabled in a function with the __nocfi attribute.
Additionally, CFI can be disabled for an entire compilation unit by
filtering out CC_FLAGS_CFI.

By default, CFI failures result in a kernel panic to stop a potential
exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
kernel prints out a rate-limited warning instead, and allows execution
to continue. This option is helpful for locating type mismatches, but
should only be enabled during development.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 Makefile                          |  17 ++
 arch/Kconfig                      |  45 ++++
 include/asm-generic/bug.h         |  16 ++
 include/asm-generic/vmlinux.lds.h |  20 +-
 include/linux/cfi.h               |  41 ++++
 include/linux/compiler-clang.h    |   2 +
 include/linux/compiler_types.h    |   4 +
 include/linux/init.h              |   2 +-
 include/linux/module.h            |  13 +-
 init/Kconfig                      |   2 +-
 kernel/Makefile                   |   4 +
 kernel/cfi.c                      | 329 ++++++++++++++++++++++++++++++
 kernel/module.c                   |  43 ++++
 scripts/Makefile.modfinal         |   2 +-
 14 files changed, 534 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/cfi.h
 create mode 100644 kernel/cfi.c

diff --git a/Makefile b/Makefile
index 73add16f9898..4a9c1ff420b6 100644
--- a/Makefile
+++ b/Makefile
@@ -920,6 +920,23 @@ KBUILD_AFLAGS	+= -fno-lto
 export CC_FLAGS_LTO
 endif
 
+ifdef CONFIG_CFI_CLANG
+CC_FLAGS_CFI	:= -fsanitize=cfi \
+		   -fsanitize-cfi-cross-dso \
+		   -fno-sanitize-cfi-canonical-jump-tables \
+		   -fno-sanitize-trap=cfi \
+		   -fno-sanitize-blacklist
+
+ifdef CONFIG_CFI_PERMISSIVE
+CC_FLAGS_CFI	+= -fsanitize-recover=cfi
+endif
+
+# If LTO flags are filtered out, we must also filter out CFI.
+CC_FLAGS_LTO	+= $(CC_FLAGS_CFI)
+KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
+export CC_FLAGS_CFI
+endif
+
 ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_32B
 KBUILD_CFLAGS += -falign-functions=32
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index ecfd3520b676..f6a85ba6cba2 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -692,6 +692,51 @@ config LTO_CLANG_THIN
 	  If unsure, say Y.
 endchoice
 
+config ARCH_SUPPORTS_CFI_CLANG
+	bool
+	help
+	  An architecture should select this option if it can support Clang's
+	  Control-Flow Integrity (CFI) checking.
+
+config CFI_CLANG
+	bool "Use Clang's Control Flow Integrity (CFI)"
+	depends on LTO_CLANG && ARCH_SUPPORTS_CFI_CLANG
+	# Clang >= 12:
+	# - https://bugs.llvm.org/show_bug.cgi?id=46258
+	# - https://bugs.llvm.org/show_bug.cgi?id=47479
+	depends on CLANG_VERSION >= 120000
+	select KALLSYMS
+	help
+	  This option enables Clang?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 Clang's documentation:
+
+	    https://clang.llvm.org/docs/ControlFlowIntegrity.html
+
+config CFI_CLANG_SHADOW
+	bool "Use CFI shadow to speed up cross-module checks"
+	default y
+	depends on CFI_CLANG && MODULES
+	help
+	  If you select this option, the kernel builds a fast look-up table of
+	  CFI check functions in loaded modules to reduce performance overhead.
+
+	  If unsure, say Y.
+
+config CFI_PERMISSIVE
+	bool "Use CFI in permissive mode"
+	depends on CFI_CLANG
+	help
+	  When selected, Control Flow Integrity (CFI) violations result in a
+	  warning instead of a kernel panic. This option should only be used
+	  for finding indirect call type mismatches during development.
+
+	  If unsure, say N.
+
 config HAVE_ARCH_WITHIN_STACK_FRAMES
 	bool
 	help
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 76a10e0dca9f..b402494883b6 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -241,6 +241,22 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
 # define WARN_ON_SMP(x)			({0;})
 #endif
 
+/*
+ * WARN_ON_FUNCTION_MISMATCH() warns if a value doesn't match a
+ * function address, and can be useful for catching issues with
+ * callback functions, for example.
+ *
+ * With CONFIG_CFI_CLANG, the warning is disabled because the
+ * compiler replaces function addresses taken in C code with
+ * local jump table addresses, which breaks cross-module function
+ * address equality.
+ */
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_MODULES)
+# define WARN_ON_FUNCTION_MISMATCH(x, fn) ({ 0; })
+#else
+# define WARN_ON_FUNCTION_MISMATCH(x, fn) WARN_ON_ONCE((x) != (fn))
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 0331d5d49551..40a9c101565e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -544,6 +544,22 @@
 	. = ALIGN((align));						\
 	__end_rodata = .;
 
+
+/*
+ * .text..L.cfi.jumptable.* contain Control-Flow Integrity (CFI)
+ * jump table entries.
+ */
+#ifdef CONFIG_CFI_CLANG
+#define TEXT_CFI_JT							\
+		. = ALIGN(PMD_SIZE);					\
+		__cfi_jt_start = .;					\
+		*(.text..L.cfi.jumptable .text..L.cfi.jumptable.*)	\
+		. = ALIGN(PMD_SIZE);					\
+		__cfi_jt_end = .;
+#else
+#define TEXT_CFI_JT
+#endif
+
 /*
  * Non-instrumentable text section
  */
@@ -570,6 +586,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 
@@ -974,7 +991,8 @@
  * keep any .init_array.* sections.
  * https://bugs.llvm.org/show_bug.cgi?id=46478
  */
-#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
+#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN) || \
+	defined(CONFIG_CFI_CLANG)
 # ifdef CONFIG_CONSTRUCTORS
 #  define SANITIZER_DISCARDS						\
 	*(.eh_frame)
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
new file mode 100644
index 000000000000..879744aaa6e0
--- /dev/null
+++ b/include/linux/cfi.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Clang Control Flow Integrity (CFI) support.
+ *
+ * Copyright (C) 2021 Google LLC
+ */
+#ifndef _LINUX_CFI_H
+#define _LINUX_CFI_H
+
+#ifdef CONFIG_CFI_CLANG
+typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
+
+/* Compiler-generated function in each module, and the kernel */
+extern void __cfi_check(uint64_t id, void *ptr, void *diag);
+
+/*
+ * Force the compiler to generate a CFI jump table entry for a function
+ * and store the jump table address to __cfi_jt_<function>.
+ */
+#define __CFI_ADDRESSABLE(fn, __attr) \
+	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
+
+#ifdef CONFIG_CFI_CLANG_SHADOW
+
+extern void cfi_module_add(struct module *mod, unsigned long base_addr);
+extern void cfi_module_remove(struct module *mod, unsigned long base_addr);
+
+#else
+
+static inline void cfi_module_add(struct module *mod, unsigned long base_addr) {}
+static inline void cfi_module_remove(struct module *mod, unsigned long base_addr) {}
+
+#endif /* CONFIG_CFI_CLANG_SHADOW */
+
+#else /* !CONFIG_CFI_CLANG */
+
+#define __CFI_ADDRESSABLE(fn, __attr)
+
+#endif /* CONFIG_CFI_CLANG */
+
+#endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index d217c382b02d..6de9d0c9377e 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -61,3 +61,5 @@
 #if __has_feature(shadow_call_stack)
 # define __noscs	__attribute__((__no_sanitize__("shadow-call-stack")))
 #endif
+
+#define __nocfi		__attribute__((__no_sanitize__("cfi")))
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index e5dd5a4ae946..796935a37e37 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -242,6 +242,10 @@ struct ftrace_likely_data {
 # define __noscs
 #endif
 
+#ifndef __nocfi
+# define __nocfi
+#endif
+
 #ifndef asm_volatile_goto
 #define asm_volatile_goto(x...) asm goto(x)
 #endif
diff --git a/include/linux/init.h b/include/linux/init.h
index 31f54de58429..b3ea15348fbd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
 
 /* These are for everybody (although not all archs will actually
    discard it in modules) */
-#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline
+#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline __nocfi
 #define __initdata	__section(".init.data")
 #define __initconst	__section(".init.rodata")
 #define __exitdata	__section(".exit.data")
diff --git a/include/linux/module.h b/include/linux/module.h
index da4b6fbe8ebe..8100bb477d86 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -26,6 +26,7 @@
 #include <linux/tracepoint-defs.h>
 #include <linux/srcu.h>
 #include <linux/static_call_types.h>
+#include <linux/cfi.h>
 
 #include <linux/percpu.h>
 #include <asm/module.h>
@@ -128,13 +129,17 @@ extern void cleanup_module(void);
 #define module_init(initfn)					\
 	static inline initcall_t __maybe_unused __inittest(void)		\
 	{ return initfn; }					\
-	int init_module(void) __copy(initfn) __attribute__((alias(#initfn)));
+	int init_module(void) __copy(initfn)			\
+		__attribute__((alias(#initfn)));		\
+	__CFI_ADDRESSABLE(init_module, __initdata);
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)					\
 	static inline exitcall_t __maybe_unused __exittest(void)		\
 	{ return exitfn; }					\
-	void cleanup_module(void) __copy(exitfn) __attribute__((alias(#exitfn)));
+	void cleanup_module(void) __copy(exitfn)		\
+		__attribute__((alias(#exitfn)));		\
+	__CFI_ADDRESSABLE(cleanup_module, __exitdata);
 
 #endif
 
@@ -376,6 +381,10 @@ struct module {
 	const s32 *crcs;
 	unsigned int num_syms;
 
+#ifdef CONFIG_CFI_CLANG
+	cfi_check_fn cfi_check;
+#endif
+
 	/* Kernel parameters. */
 #ifdef CONFIG_SYSFS
 	struct mutex param_lock;
diff --git a/init/Kconfig b/init/Kconfig
index 5f5c776ef192..5babea38e346 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2296,7 +2296,7 @@ endif # MODULES
 
 config MODULES_TREE_LOOKUP
 	def_bool y
-	depends on PERF_EVENTS || TRACING
+	depends on PERF_EVENTS || TRACING || CFI_CLANG
 
 config INIT_ALL_POSSIBLE
 	bool
diff --git a/kernel/Makefile b/kernel/Makefile
index 320f1f3941b7..e8a6715f38dc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -41,6 +41,9 @@ KCSAN_SANITIZE_kcov.o := n
 UBSAN_SANITIZE_kcov.o := n
 CFLAGS_kcov.o := $(call cc-option, -fno-conserve-stack) -fno-stack-protector
 
+# Don't instrument error handlers
+CFLAGS_REMOVE_cfi.o := $(CC_FLAGS_CFI)
+
 obj-y += sched/
 obj-y += locking/
 obj-y += power/
@@ -111,6 +114,7 @@ obj-$(CONFIG_BPF) += bpf/
 obj-$(CONFIG_KCSAN) += kcsan/
 obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o
 obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call.o
+obj-$(CONFIG_CFI_CLANG) += cfi.o
 
 obj-$(CONFIG_PERF_EVENTS) += events/
 
diff --git a/kernel/cfi.c b/kernel/cfi.c
new file mode 100644
index 000000000000..e17a56639766
--- /dev/null
+++ b/kernel/cfi.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clang Control Flow Integrity (CFI) error and slowpath handling.
+ *
+ * Copyright (C) 2021 Google LLC
+ */
+
+#include <linux/hardirq.h>
+#include <linux/kallsyms.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/printk.h>
+#include <linux/ratelimit.h>
+#include <linux/rcupdate.h>
+#include <linux/vmalloc.h>
+#include <asm/cacheflush.h>
+#include <asm/set_memory.h>
+
+/* Compiler-defined handler names */
+#ifdef CONFIG_CFI_PERMISSIVE
+#define cfi_failure_handler	__ubsan_handle_cfi_check_fail
+#else
+#define cfi_failure_handler	__ubsan_handle_cfi_check_fail_abort
+#endif
+
+static inline void handle_cfi_failure(void *ptr)
+{
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
+		WARN_RATELIMIT(1, "CFI failure (target: %pS):\n", ptr);
+	else
+		panic("CFI failure (target: %pS)\n", ptr);
+}
+
+#ifdef CONFIG_MODULES
+#ifdef CONFIG_CFI_CLANG_SHADOW
+/*
+ * Index type. A 16-bit index can address at most (2^16)-2 pages (taking
+ * into account SHADOW_INVALID), i.e. ~256M with 4k pages.
+ */
+typedef u16 shadow_t;
+#define SHADOW_INVALID		((shadow_t)~0UL)
+
+struct cfi_shadow {
+	/* Page index for the beginning of the shadow */
+	unsigned long base;
+	/* An array of __cfi_check locations (as indices to the shadow) */
+	shadow_t shadow[1];
+} __packed;
+
+/*
+ * The shadow covers ~128M from the beginning of the module region. If
+ * the region is larger, we fall back to __module_address for the rest.
+ */
+#define __SHADOW_RANGE		(_UL(SZ_128M) >> PAGE_SHIFT)
+
+/* The in-memory size of struct cfi_shadow, always at least one page */
+#define __SHADOW_PAGES		((__SHADOW_RANGE * sizeof(shadow_t)) >> PAGE_SHIFT)
+#define SHADOW_PAGES		max(1UL, __SHADOW_PAGES)
+#define SHADOW_SIZE		(SHADOW_PAGES << PAGE_SHIFT)
+
+/* The actual size of the shadow array, minus metadata */
+#define SHADOW_ARR_SIZE		(SHADOW_SIZE - offsetof(struct cfi_shadow, shadow))
+#define SHADOW_ARR_SLOTS	(SHADOW_ARR_SIZE / sizeof(shadow_t))
+
+static DEFINE_MUTEX(shadow_update_lock);
+static struct cfi_shadow __rcu *cfi_shadow __read_mostly;
+
+/* Returns the index in the shadow for the given address */
+static inline int ptr_to_shadow(const struct cfi_shadow *s, unsigned long ptr)
+{
+	unsigned long index;
+	unsigned long page = ptr >> PAGE_SHIFT;
+
+	if (unlikely(page < s->base))
+		return -1; /* Outside of module area */
+
+	index = page - s->base;
+
+	if (index >= SHADOW_ARR_SLOTS)
+		return -1; /* Cannot be addressed with shadow */
+
+	return (int)index;
+}
+
+/* Returns the page address for an index in the shadow */
+static inline unsigned long shadow_to_ptr(const struct cfi_shadow *s,
+	int index)
+{
+	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
+		return 0;
+
+	return (s->base + index) << PAGE_SHIFT;
+}
+
+/* Returns the __cfi_check function address for the given shadow location */
+static inline unsigned long shadow_to_check_fn(const struct cfi_shadow *s,
+	int index)
+{
+	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
+		return 0;
+
+	if (unlikely(s->shadow[index] == SHADOW_INVALID))
+		return 0;
+
+	/* __cfi_check is always page aligned */
+	return (s->base + s->shadow[index]) << PAGE_SHIFT;
+}
+
+static void prepare_next_shadow(const struct cfi_shadow __rcu *prev,
+		struct cfi_shadow *next)
+{
+	int i, index, check;
+
+	/* Mark everything invalid */
+	memset(next->shadow, 0xFF, SHADOW_ARR_SIZE);
+
+	if (!prev)
+		return; /* No previous shadow */
+
+	/* If the base address didn't change, an update is not needed */
+	if (prev->base == next->base) {
+		memcpy(next->shadow, prev->shadow, SHADOW_ARR_SIZE);
+		return;
+	}
+
+	/* Convert the previous shadow to the new address range */
+	for (i = 0; i < SHADOW_ARR_SLOTS; ++i) {
+		if (prev->shadow[i] == SHADOW_INVALID)
+			continue;
+
+		index = ptr_to_shadow(next, shadow_to_ptr(prev, i));
+		if (index < 0)
+			continue;
+
+		check = ptr_to_shadow(next,
+				shadow_to_check_fn(prev, prev->shadow[i]));
+		if (check < 0)
+			continue;
+
+		next->shadow[index] = (shadow_t)check;
+	}
+}
+
+static void add_module_to_shadow(struct cfi_shadow *s, struct module *mod,
+			unsigned long min_addr, unsigned long max_addr)
+{
+	int check_index;
+	unsigned long check = (unsigned long)mod->cfi_check;
+	unsigned long ptr;
+
+	if (unlikely(!PAGE_ALIGNED(check))) {
+		pr_warn("cfi: not using shadow for module %s\n", mod->name);
+		return;
+	}
+
+	check_index = ptr_to_shadow(s, check);
+	if (check_index < 0)
+		return; /* Module not addressable with shadow */
+
+	/* For each page, store the check function index in the shadow */
+	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
+		int index = ptr_to_shadow(s, ptr);
+
+		if (index >= 0) {
+			/* Each page must only contain one module */
+			WARN_ON_ONCE(s->shadow[index] != SHADOW_INVALID);
+			s->shadow[index] = (shadow_t)check_index;
+		}
+	}
+}
+
+static void remove_module_from_shadow(struct cfi_shadow *s, struct module *mod,
+		unsigned long min_addr, unsigned long max_addr)
+{
+	unsigned long ptr;
+
+	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
+		int index = ptr_to_shadow(s, ptr);
+
+		if (index >= 0)
+			s->shadow[index] = SHADOW_INVALID;
+	}
+}
+
+typedef void (*update_shadow_fn)(struct cfi_shadow *, struct module *,
+			unsigned long min_addr, unsigned long max_addr);
+
+static void update_shadow(struct module *mod, unsigned long base_addr,
+		update_shadow_fn fn)
+{
+	struct cfi_shadow *prev;
+	struct cfi_shadow *next;
+	unsigned long min_addr, max_addr;
+
+	next = vmalloc(SHADOW_SIZE);
+
+	mutex_lock(&shadow_update_lock);
+	prev = rcu_dereference_protected(cfi_shadow,
+					 mutex_is_locked(&shadow_update_lock));
+
+	if (next) {
+		next->base = base_addr >> PAGE_SHIFT;
+		prepare_next_shadow(prev, next);
+
+		min_addr = (unsigned long)mod->core_layout.base;
+		max_addr = min_addr + mod->core_layout.text_size;
+		fn(next, mod, min_addr & PAGE_MASK, max_addr & PAGE_MASK);
+
+		set_memory_ro((unsigned long)next, SHADOW_PAGES);
+	}
+
+	rcu_assign_pointer(cfi_shadow, next);
+	mutex_unlock(&shadow_update_lock);
+	synchronize_rcu();
+
+	if (prev) {
+		set_memory_rw((unsigned long)prev, SHADOW_PAGES);
+		vfree(prev);
+	}
+}
+
+void cfi_module_add(struct module *mod, unsigned long base_addr)
+{
+	update_shadow(mod, base_addr, add_module_to_shadow);
+}
+
+void cfi_module_remove(struct module *mod, unsigned long base_addr)
+{
+	update_shadow(mod, base_addr, remove_module_from_shadow);
+}
+
+static inline cfi_check_fn ptr_to_check_fn(const struct cfi_shadow __rcu *s,
+	unsigned long ptr)
+{
+	int index;
+
+	if (unlikely(!s))
+		return NULL; /* No shadow available */
+
+	index = ptr_to_shadow(s, ptr);
+	if (index < 0)
+		return NULL; /* Cannot be addressed with shadow */
+
+	return (cfi_check_fn)shadow_to_check_fn(s, index);
+}
+
+static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn;
+
+	rcu_read_lock_sched();
+	fn = ptr_to_check_fn(rcu_dereference_sched(cfi_shadow), ptr);
+	rcu_read_unlock_sched();
+
+	return fn;
+}
+
+#else /* !CONFIG_CFI_CLANG_SHADOW */
+
+static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
+{
+	return NULL;
+}
+
+#endif /* CONFIG_CFI_CLANG_SHADOW */
+
+static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn = NULL;
+	struct module *mod;
+
+	rcu_read_lock_sched();
+	mod = __module_address(ptr);
+	if (mod)
+		fn = mod->cfi_check;
+	rcu_read_unlock_sched();
+
+	return fn;
+}
+
+static inline cfi_check_fn find_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn = NULL;
+
+	if (is_kernel_text(ptr))
+		return __cfi_check;
+
+	/*
+	 * Indirect call checks can happen when RCU is not watching. Both
+	 * the shadow and __module_address use RCU, so we need to wake it
+	 * up if necessary.
+	 */
+	RCU_NONIDLE({
+		if (IS_ENABLED(CONFIG_CFI_CLANG_SHADOW))
+			fn = find_shadow_check_fn(ptr);
+
+		if (!fn)
+			fn = find_module_check_fn(ptr);
+	});
+
+	return fn;
+}
+
+void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+{
+	cfi_check_fn fn = find_check_fn((unsigned long)ptr);
+
+	if (likely(fn))
+		fn(id, ptr, diag);
+	else /* Don't allow unchecked modules */
+		handle_cfi_failure(ptr);
+}
+EXPORT_SYMBOL(__cfi_slowpath_diag);
+
+#else /* !CONFIG_MODULES */
+
+void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+{
+	handle_cfi_failure(ptr); /* No modules */
+}
+EXPORT_SYMBOL(__cfi_slowpath_diag);
+
+#endif /* CONFIG_MODULES */
+
+void cfi_failure_handler(void *data, void *ptr, void *vtable)
+{
+	handle_cfi_failure(ptr);
+}
+EXPORT_SYMBOL(cfi_failure_handler);
diff --git a/kernel/module.c b/kernel/module.c
index 30479355ab85..20fb004e7d8d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2146,6 +2146,8 @@ void __weak module_arch_freeing_init(struct module *mod)
 {
 }
 
+static void cfi_cleanup(struct module *mod);
+
 /* Free a module, remove from lists, etc. */
 static void free_module(struct module *mod)
 {
@@ -2187,6 +2189,9 @@ static void free_module(struct module *mod)
 	synchronize_rcu();
 	mutex_unlock(&module_mutex);
 
+	/* Clean up CFI for the module. */
+	cfi_cleanup(mod);
+
 	/* This may be empty, but that's OK */
 	module_arch_freeing_init(mod);
 	module_memfree(mod->init_layout.base);
@@ -3866,6 +3871,8 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,
 	return 0;
 }
 
+static void cfi_init(struct module *mod);
+
 /*
  * Allocate and load the module: note that size of section 0 is always
  * zero, and we rely on this for optional sections.
@@ -3997,6 +4004,9 @@ static int load_module(struct load_info *info, const char __user *uargs,
 
 	flush_module_icache(mod);
 
+	/* Setup CFI for the module. */
+	cfi_init(mod);
+
 	/* Now copy in args */
 	mod->args = strndup_user(uargs, ~0UL >> 1);
 	if (IS_ERR(mod->args)) {
@@ -4070,6 +4080,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
 	synchronize_rcu();
 	kfree(mod->args);
  free_arch_cleanup:
+	cfi_cleanup(mod);
 	module_arch_cleanup(mod);
  free_modinfo:
 	free_modinfo(mod);
@@ -4415,6 +4426,38 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, const char *,
 #endif /* CONFIG_LIVEPATCH */
 #endif /* CONFIG_KALLSYMS */
 
+static void cfi_init(struct module *mod)
+{
+#ifdef CONFIG_CFI_CLANG
+	initcall_t *init;
+	exitcall_t *exit;
+
+	rcu_read_lock_sched();
+	mod->cfi_check = (cfi_check_fn)
+		find_kallsyms_symbol_value(mod, "__cfi_check");
+	init = (initcall_t *)
+		find_kallsyms_symbol_value(mod, "__cfi_jt_init_module");
+	exit = (exitcall_t *)
+		find_kallsyms_symbol_value(mod, "__cfi_jt_cleanup_module");
+	rcu_read_unlock_sched();
+
+	/* Fix init/exit functions to point to the CFI jump table */
+	if (init)
+		mod->init = *init;
+	if (exit)
+		mod->exit = *exit;
+
+	cfi_module_add(mod, module_addr_min);
+#endif
+}
+
+static void cfi_cleanup(struct module *mod)
+{
+#ifdef CONFIG_CFI_CLANG
+	cfi_module_remove(mod, module_addr_min);
+#endif
+}
+
 /* Maximum number of characters written by module_flags() */
 #define MODULE_FLAGS_BUF_SIZE (TAINT_FLAGS_COUNT + 4)
 
diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 735e11e9041b..dd87cea9fba7 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -23,7 +23,7 @@ modname = $(notdir $(@:.mod.o=))
 part-of-module = y
 
 quiet_cmd_cc_o_c = CC [M]  $@
-      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
+      cmd_cc_o_c = $(CC) $(filter-out $(CC_FLAGS_CFI), $(c_flags)) -c -o $@ $<
 
 %.mod.o: %.mod.c FORCE
 	$(call if_changed_dep,cc_o_c)
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:00 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:00 -0700
Subject: [PATCH v5 02/18] cfi: add __cficanonical
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-3-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces a function address taken
in C code with the address of a local jump table entry, which passes
runtime indirect call checks. However, the compiler won't replace
addresses taken in assembly code, which will result in a CFI failure
if we later jump to such an address in instrumented C code. The code
generated for the non-canonical jump table looks this:

  <noncanonical.cfi_jt>: /* In C, &noncanonical points here */
	jmp noncanonical
  ...
  <noncanonical>:        /* function body */
	...

This change adds the __cficanonical attribute, which tells the
compiler to use a canonical jump table for the function instead. This
means the compiler will rename the actual function to <function>.cfi
and points the original symbol to the jump table entry instead:

  <canonical>:           /* jump table entry */
	jmp canonical.cfi
  ...
  <canonical.cfi>:       /* function body */
	...

As a result, the address taken in assembly, or other non-instrumented
code always points to the jump table and therefore, can be used for
indirect calls in instrumented code without tripping CFI checks.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>   # pci.h
---
 include/linux/compiler-clang.h | 1 +
 include/linux/compiler_types.h | 4 ++++
 include/linux/init.h           | 4 ++--
 include/linux/pci.h            | 4 ++--
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 6de9d0c9377e..adbe76b203e2 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -63,3 +63,4 @@
 #endif
 
 #define __nocfi		__attribute__((__no_sanitize__("cfi")))
+#define __cficanonical	__attribute__((__cfi_canonical_jump_table__))
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 796935a37e37..d29bda7f6ebd 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -246,6 +246,10 @@ struct ftrace_likely_data {
 # define __nocfi
 #endif
 
+#ifndef __cficanonical
+# define __cficanonical
+#endif
+
 #ifndef asm_volatile_goto
 #define asm_volatile_goto(x...) asm goto(x)
 #endif
diff --git a/include/linux/init.h b/include/linux/init.h
index b3ea15348fbd..045ad1650ed1 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -220,8 +220,8 @@ extern bool initcall_debug;
 	__initcall_name(initstub, __iid, id)
 
 #define __define_initcall_stub(__stub, fn)			\
-	int __init __stub(void);				\
-	int __init __stub(void)					\
+	int __init __cficanonical __stub(void);			\
+	int __init __cficanonical __stub(void)			\
 	{ 							\
 		return fn();					\
 	}							\
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 86c799c97b77..39684b72db91 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1944,8 +1944,8 @@ enum pci_fixup_pass {
 #ifdef CONFIG_LTO_CLANG
 #define __DECLARE_PCI_FIXUP_SECTION(sec, name, vendor, device, class,	\
 				  class_shift, hook, stub)		\
-	void stub(struct pci_dev *dev);					\
-	void stub(struct pci_dev *dev)					\
+	void __cficanonical stub(struct pci_dev *dev);			\
+	void __cficanonical stub(struct pci_dev *dev)			\
 	{ 								\
 		hook(dev); 						\
 	}								\
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:01 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:01 -0700
Subject: [PATCH v5 03/18] mm: add generic function_nocfi macro
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-4-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function addresses
in instrumented C code with jump table addresses. This means that
__pa_symbol(function) returns the physical address of the jump table
entry instead of the actual function, which may not work as the jump
table code will immediately jump to a virtual address that may not be
mapped.

To avoid this address space confusion, this change adds a generic
definition for function_nocfi(), which architectures that support CFI
can override. The typical implementation of would use inline assembly
to take the function address, which avoids compiler instrumentation.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 include/linux/mm.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..22cce9c7dd05 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -124,6 +124,16 @@ extern int mmap_rnd_compat_bits __read_mostly;
 #define lm_alias(x)	__va(__pa_symbol(x))
 #endif
 
+/*
+ * With CONFIG_CFI_CLANG, the compiler replaces function addresses in
+ * instrumented C code with jump table addresses. Architectures that
+ * support CFI can define this macro to return the actual function address
+ * when needed.
+ */
+#ifndef function_nocfi
+#define function_nocfi(x) (x)
+#endif
+
 /*
  * To prevent common memory management code establishing
  * a zero page mapping on a read fault.
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:02 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:02 -0700
Subject: [PATCH v5 04/18] module: ensure __cfi_check alignment
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-5-samitolvanen@google.com>

CONFIG_CFI_CLANG_SHADOW assumes the __cfi_check() function is page
aligned and at the beginning of the .text section. While Clang would
normally align the function correctly, it fails to do so for modules
with no executable code.

This change ensures the correct __cfi_check() location and
alignment. It also discards the .eh_frame section, which Clang can
generate with certain sanitizers, such as CFI.

Link: https://bugs.llvm.org/show_bug.cgi?id=46293
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Jessica Yu <jeyu at kernel.org>
---
 scripts/module.lds.S | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 168cd27e6122..f8022b34e388 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -3,10 +3,20 @@
  * Archs are free to supply their own linker scripts.  ld will
  * combine them automatically.
  */
+#ifdef CONFIG_CFI_CLANG
+# include <asm/page.h>
+# define ALIGN_CFI 		ALIGN(PAGE_SIZE)
+# define SANITIZER_DISCARDS	*(.eh_frame)
+#else
+# define ALIGN_CFI
+# define SANITIZER_DISCARDS
+#endif
+
 SECTIONS {
 	/DISCARD/ : {
 		*(.discard)
 		*(.discard.*)
+		SANITIZER_DISCARDS
 	}
 
 	__ksymtab		0 : { *(SORT(___ksymtab+*)) }
@@ -40,7 +50,14 @@ SECTIONS {
 		*(.rodata..L*)
 	}
 
-	.text : { *(.text .text.[0-9a-zA-Z_]*) }
+	/*
+	 * With CONFIG_CFI_CLANG, we assume __cfi_check is at the beginning
+	 * of the .text section, and is aligned to PAGE_SIZE.
+	 */
+	.text : ALIGN_CFI {
+		*(.text.__cfi_check)
+		*(.text .text.[0-9a-zA-Z_]* .text..L.cfi*)
+	}
 }
 
 /* bring in arch-specific sections */
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:03 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:03 -0700
Subject: [PATCH v5 05/18] workqueue: use WARN_ON_FUNCTION_MISMATCH
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-6-samitolvanen@google.com>

With CONFIG_CFI_CLANG, a callback function passed to
__queue_delayed_work from a module points to a jump table entry
defined in the module instead of the one used in the core kernel,
which breaks function address equality in this check:

  WARN_ON_ONCE(timer->function != delayed_work_timer_fn);

Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
when CFI and modules are both enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 kernel/workqueue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 0d150da252e8..03fe07d2f39f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1630,7 +1630,7 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq,
 	struct work_struct *work = &dwork->work;
 
 	WARN_ON_ONCE(!wq);
-	WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
+	WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn);
 	WARN_ON_ONCE(timer_pending(timer));
 	WARN_ON_ONCE(!list_empty(&work->entry));
 
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:04 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:04 -0700
Subject: [PATCH v5 06/18] kthread: use WARN_ON_FUNCTION_MISMATCH
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-7-samitolvanen@google.com>

With CONFIG_CFI_CLANG, a callback function passed to
__kthread_queue_delayed_work from a module points to a jump table
entry defined in the module instead of the one used in the core
kernel, which breaks function address equality in this check:

  WARN_ON_ONCE(timer->function != ktead_delayed_work_timer_fn);

Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
when CFI and modules are both enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 kernel/kthread.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 1578973c5740..a1972eba2917 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -963,7 +963,8 @@ static void __kthread_queue_delayed_work(struct kthread_worker *worker,
 	struct timer_list *timer = &dwork->timer;
 	struct kthread_work *work = &dwork->work;
 
-	WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn);
+	WARN_ON_FUNCTION_MISMATCH(timer->function,
+				  kthread_delayed_work_timer_fn);
 
 	/*
 	 * If @delay is 0, queue @dwork->work immediately.  This is for
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:05 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:05 -0700
Subject: [PATCH v5 07/18] kallsyms: strip ThinLTO hashes from static functions
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-8-samitolvanen@google.com>

With CONFIG_CFI_CLANG and ThinLTO, Clang appends a hash to the names
of all static functions not marked __used. This can break userspace
tools that don't expect the function name to change, so strip out the
hash from the output.

Suggested-by: Jack Pham <jackp at codeaurora.org>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 kernel/kallsyms.c | 55 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 8043a90aa50e..c851ca0ed357 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -161,6 +161,27 @@ static unsigned long kallsyms_sym_address(int idx)
 	return kallsyms_relative_base - 1 - kallsyms_offsets[idx];
 }
 
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_LTO_CLANG_THIN)
+/*
+ * LLVM appends a hash to static function names when ThinLTO and CFI are
+ * both enabled, i.e. foo() becomes foo$707af9a22804d33c81801f27dcfe489b.
+ * This causes confusion and potentially breaks user space tools, so we
+ * strip the suffix from expanded symbol names.
+ */
+static inline bool cleanup_symbol_name(char *s)
+{
+	char *res;
+
+	res = strrchr(s, '$');
+	if (res)
+		*res = '\0';
+
+	return res != NULL;
+}
+#else
+static inline bool cleanup_symbol_name(char *s) { return false; }
+#endif
+
 /* Lookup the address for this symbol. Returns 0 if not found. */
 unsigned long kallsyms_lookup_name(const char *name)
 {
@@ -173,6 +194,9 @@ unsigned long kallsyms_lookup_name(const char *name)
 
 		if (strcmp(namebuf, name) == 0)
 			return kallsyms_sym_address(i);
+
+		if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0)
+			return kallsyms_sym_address(i);
 	}
 	return module_kallsyms_lookup_name(name);
 }
@@ -303,7 +327,9 @@ const char *kallsyms_lookup(unsigned long addr,
 				       namebuf, KSYM_NAME_LEN);
 		if (modname)
 			*modname = NULL;
-		return namebuf;
+
+		ret = namebuf;
+		goto found;
 	}
 
 	/* See if it's in a module or a BPF JITed image. */
@@ -316,11 +342,16 @@ const char *kallsyms_lookup(unsigned long addr,
 	if (!ret)
 		ret = ftrace_mod_address_lookup(addr, symbolsize,
 						offset, modname, namebuf);
+
+found:
+	cleanup_symbol_name(namebuf);
 	return ret;
 }
 
 int lookup_symbol_name(unsigned long addr, char *symname)
 {
+	int res;
+
 	symname[0] = '\0';
 	symname[KSYM_NAME_LEN - 1] = '\0';
 
@@ -331,15 +362,23 @@ int lookup_symbol_name(unsigned long addr, char *symname)
 		/* Grab name */
 		kallsyms_expand_symbol(get_symbol_offset(pos),
 				       symname, KSYM_NAME_LEN);
-		return 0;
+		goto found;
 	}
 	/* See if it's in a module. */
-	return lookup_module_symbol_name(addr, symname);
+	res = lookup_module_symbol_name(addr, symname);
+	if (res)
+		return res;
+
+found:
+	cleanup_symbol_name(symname);
+	return 0;
 }
 
 int lookup_symbol_attrs(unsigned long addr, unsigned long *size,
 			unsigned long *offset, char *modname, char *name)
 {
+	int res;
+
 	name[0] = '\0';
 	name[KSYM_NAME_LEN - 1] = '\0';
 
@@ -351,10 +390,16 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long *size,
 		kallsyms_expand_symbol(get_symbol_offset(pos),
 				       name, KSYM_NAME_LEN);
 		modname[0] = '\0';
-		return 0;
+		goto found;
 	}
 	/* See if it's in a module. */
-	return lookup_module_symbol_attrs(addr, size, offset, modname, name);
+	res = lookup_module_symbol_attrs(addr, size, offset, modname, name);
+	if (res)
+		return res;
+
+found:
+	cleanup_symbol_name(name);
+	return 0;
 }
 
 /* Look up a kernel symbol and return it in a text buffer. */
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:06 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:06 -0700
Subject: [PATCH v5 08/18] bpf: disable CFI in dispatcher functions
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-9-samitolvanen@google.com>

BPF dispatcher functions are patched at runtime to perform direct
instead of indirect calls. Disable CFI for the dispatcher functions to
avoid conflicts.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 include/linux/bpf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3625f019767d..2f46f98479e1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -650,7 +650,7 @@ struct bpf_dispatcher {
 	struct bpf_ksym ksym;
 };
 
-static __always_inline unsigned int bpf_dispatcher_nop_func(
+static __always_inline __nocfi unsigned int bpf_dispatcher_nop_func(
 	const void *ctx,
 	const struct bpf_insn *insnsi,
 	unsigned int (*bpf_func)(const void *,
@@ -678,7 +678,7 @@ void bpf_trampoline_put(struct bpf_trampoline *tr);
 }
 
 #define DEFINE_BPF_DISPATCHER(name)					\
-	noinline unsigned int bpf_dispatcher_##name##_func(		\
+	noinline __nocfi unsigned int bpf_dispatcher_##name##_func(	\
 		const void *ctx,					\
 		const struct bpf_insn *insnsi,				\
 		unsigned int (*bpf_func)(const void *,			\
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:08 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:08 -0700
Subject: [PATCH v5 10/18] lkdtm: use function_nocfi
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-11-samitolvanen@google.com>

To ensure we take the actual address of a function in kernel text,
use function_nocfi. Otherwise, with CONFIG_CFI_CLANG, the compiler
replaces the address with a pointer to the CFI jump table, which is
actually in the module when compiled with CONFIG_LKDTM=m.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Acked-by: Kees Cook <keescook at chromium.org>
---
 drivers/misc/lkdtm/usercopy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 109e8d4302c1..15d220ef35a5 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -314,7 +314,7 @@ void lkdtm_USERCOPY_KERNEL(void)
 
 	pr_info("attempting bad copy_to_user from kernel text: %px\n",
 		vm_mmap);
-	if (copy_to_user((void __user *)user_addr, vm_mmap,
+	if (copy_to_user((void __user *)user_addr, function_nocfi(vm_mmap),
 			 unconst + PAGE_SIZE)) {
 		pr_warn("copy_to_user failed, but lacked Oops\n");
 		goto free_user;
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:07 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:07 -0700
Subject: [PATCH v5 09/18] treewide: Change list_sort to use const pointers
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-10-samitolvanen@google.com>

list_sort() internally casts the comparison function passed to it
to a different type with constant struct list_head pointers, and
uses this pointer to call the functions, which trips indirect call
Control-Flow Integrity (CFI) checking.

Instead of removing the consts, this change defines the
list_cmp_func_t type and changes the comparison function types of
all list_sort() callers to use const pointers, thus avoiding type
mismatches.

Suggested-by: Nick Desaulniers <ndesaulniers at google.com>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>
Tested-by: Nick Desaulniers <ndesaulniers at google.com>
Reviewed-by: Christoph Hellwig <hch at lst.de>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/kvm/vgic/vgic-its.c                  |  8 ++++----
 arch/arm64/kvm/vgic/vgic.c                      |  3 ++-
 block/blk-mq-sched.c                            |  3 ++-
 block/blk-mq.c                                  |  3 ++-
 drivers/acpi/nfit/core.c                        |  3 ++-
 drivers/acpi/numa/hmat.c                        |  3 ++-
 drivers/clk/keystone/sci-clk.c                  |  4 ++--
 drivers/gpu/drm/drm_modes.c                     |  3 ++-
 drivers/gpu/drm/i915/gt/intel_engine_user.c     |  3 ++-
 drivers/gpu/drm/i915/gvt/debugfs.c              |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c   |  3 ++-
 drivers/gpu/drm/radeon/radeon_cs.c              |  4 ++--
 .../hw/usnic/usnic_uiom_interval_tree.c         |  3 ++-
 drivers/interconnect/qcom/bcm-voter.c           |  2 +-
 drivers/md/raid5.c                              |  3 ++-
 drivers/misc/sram.c                             |  4 ++--
 drivers/nvme/host/core.c                        |  3 ++-
 .../pci/controller/cadence/pcie-cadence-host.c  |  3 ++-
 drivers/spi/spi-loopback-test.c                 |  3 ++-
 fs/btrfs/raid56.c                               |  3 ++-
 fs/btrfs/tree-log.c                             |  3 ++-
 fs/btrfs/volumes.c                              |  3 ++-
 fs/ext4/fsmap.c                                 |  4 ++--
 fs/gfs2/glock.c                                 |  3 ++-
 fs/gfs2/log.c                                   |  2 +-
 fs/gfs2/lops.c                                  |  3 ++-
 fs/iomap/buffered-io.c                          |  3 ++-
 fs/ubifs/gc.c                                   |  7 ++++---
 fs/ubifs/replay.c                               |  4 ++--
 fs/xfs/scrub/bitmap.c                           |  4 ++--
 fs/xfs/xfs_bmap_item.c                          |  4 ++--
 fs/xfs/xfs_buf.c                                |  6 +++---
 fs/xfs/xfs_extent_busy.c                        |  4 ++--
 fs/xfs/xfs_extent_busy.h                        |  3 ++-
 fs/xfs/xfs_extfree_item.c                       |  4 ++--
 fs/xfs/xfs_refcount_item.c                      |  4 ++--
 fs/xfs/xfs_rmap_item.c                          |  4 ++--
 include/linux/list_sort.h                       |  7 ++++---
 lib/list_sort.c                                 | 17 ++++++-----------
 lib/test_list_sort.c                            |  3 ++-
 net/tipc/name_table.c                           |  4 ++--
 41 files changed, 90 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 40cbaca81333..b9518f94bd43 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2190,8 +2190,8 @@ static int vgic_its_restore_ite(struct vgic_its *its, u32 event_id,
 	return offset;
 }
 
-static int vgic_its_ite_cmp(void *priv, struct list_head *a,
-			    struct list_head *b)
+static int vgic_its_ite_cmp(void *priv, const struct list_head *a,
+			    const struct list_head *b)
 {
 	struct its_ite *itea = container_of(a, struct its_ite, ite_list);
 	struct its_ite *iteb = container_of(b, struct its_ite, ite_list);
@@ -2329,8 +2329,8 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
 	return offset;
 }
 
-static int vgic_its_device_cmp(void *priv, struct list_head *a,
-			       struct list_head *b)
+static int vgic_its_device_cmp(void *priv, const struct list_head *a,
+			       const struct list_head *b)
 {
 	struct its_device *deva = container_of(a, struct its_device, dev_list);
 	struct its_device *devb = container_of(b, struct its_device, dev_list);
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1c597c9885fa..15b666200f0b 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -255,7 +255,8 @@ static struct kvm_vcpu *vgic_target_oracle(struct vgic_irq *irq)
  * Return negative if "a" sorts before "b", 0 to preserve order, and positive
  * to sort "b" before "a".
  */
-static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int vgic_irq_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct vgic_irq *irqa = container_of(a, struct vgic_irq, ap_list);
 	struct vgic_irq *irqb = container_of(b, struct vgic_irq, ap_list);
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index e1e997af89a0..3ebd6f10f728 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -75,7 +75,8 @@ void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx)
 	blk_mq_run_hw_queue(hctx, true);
 }
 
-static int sched_rq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int sched_rq_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct request *rqa = container_of(a, struct request, queuelist);
 	struct request *rqb = container_of(b, struct request, queuelist);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d4d7c1caa439..4e3a70ab5be1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1895,7 +1895,8 @@ void blk_mq_insert_requests(struct blk_mq_hw_ctx *hctx, struct blk_mq_ctx *ctx,
 	spin_unlock(&ctx->lock);
 }
 
-static int plug_rq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int plug_rq_cmp(void *priv, const struct list_head *a,
+		       const struct list_head *b)
 {
 	struct request *rqa = container_of(a, struct request, queuelist);
 	struct request *rqb = container_of(b, struct request, queuelist);
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 8c5dde628405..d15e3ee93b5b 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1195,7 +1195,8 @@ static int __nfit_mem_init(struct acpi_nfit_desc *acpi_desc,
 	return 0;
 }
 
-static int nfit_mem_cmp(void *priv, struct list_head *_a, struct list_head *_b)
+static int nfit_mem_cmp(void *priv, const struct list_head *_a,
+		const struct list_head *_b)
 {
 	struct nfit_mem *a = container_of(_a, typeof(*a), list);
 	struct nfit_mem *b = container_of(_b, typeof(*b), list);
diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
index cb73a5d6ea76..137a5dd880c2 100644
--- a/drivers/acpi/numa/hmat.c
+++ b/drivers/acpi/numa/hmat.c
@@ -558,7 +558,8 @@ static bool hmat_update_best(u8 type, u32 value, u32 *best)
 	return updated;
 }
 
-static int initiator_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int initiator_cmp(void *priv, const struct list_head *a,
+			 const struct list_head *b)
 {
 	struct memory_initiator *ia;
 	struct memory_initiator *ib;
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
index aaf31abe1c8f..7e1b136e71ae 100644
--- a/drivers/clk/keystone/sci-clk.c
+++ b/drivers/clk/keystone/sci-clk.c
@@ -503,8 +503,8 @@ static int ti_sci_scan_clocks_from_fw(struct sci_clk_provider *provider)
 
 #else
 
-static int _cmp_sci_clk_list(void *priv, struct list_head *a,
-			     struct list_head *b)
+static int _cmp_sci_clk_list(void *priv, const struct list_head *a,
+			     const struct list_head *b)
 {
 	struct sci_clk *ca = container_of(a, struct sci_clk, node);
 	struct sci_clk *cb = container_of(b, struct sci_clk, node);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1ac67d4505e0..6662d0457ad6 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1290,7 +1290,8 @@ EXPORT_SYMBOL(drm_mode_prune_invalid);
  * Negative if @lh_a is better than @lh_b, zero if they're equivalent, or
  * positive if @lh_b is better than @lh_a.
  */
-static int drm_mode_compare(void *priv, struct list_head *lh_a, struct list_head *lh_b)
+static int drm_mode_compare(void *priv, const struct list_head *lh_a,
+			    const struct list_head *lh_b)
 {
 	struct drm_display_mode *a = list_entry(lh_a, struct drm_display_mode, head);
 	struct drm_display_mode *b = list_entry(lh_b, struct drm_display_mode, head);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 34e6096f196e..da21d2a10cc9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -49,7 +49,8 @@ static const u8 uabi_classes[] = {
 	[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
 };
 
-static int engine_cmp(void *priv, struct list_head *A, struct list_head *B)
+static int engine_cmp(void *priv, const struct list_head *A,
+		      const struct list_head *B)
 {
 	const struct intel_engine_cs *a =
 		container_of((struct rb_node *)A, typeof(*a), uabi_node);
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c b/drivers/gpu/drm/i915/gvt/debugfs.c
index 62e6a14ad58e..9f1c209d9251 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -41,7 +41,7 @@ struct diff_mmio {
 
 /* Compare two diff_mmio items. */
 static int mmio_offset_compare(void *priv,
-	struct list_head *a, struct list_head *b)
+	const struct list_head *a, const struct list_head *b)
 {
 	struct diff_mmio *ma;
 	struct diff_mmio *mb;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index c1adea8765a9..52b9c39e0155 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1076,7 +1076,8 @@ static int igt_ppgtt_shrink_boom(void *arg)
 	return exercise_ppgtt(arg, shrink_boom);
 }
 
-static int sort_holes(void *priv, struct list_head *A, struct list_head *B)
+static int sort_holes(void *priv, const struct list_head *A,
+		      const struct list_head *B)
 {
 	struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack);
 	struct drm_mm_node *b = list_entry(B, typeof(*b), hole_stack);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c
index 35e937d39b51..1a5c3db1d53b 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -393,8 +393,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
 	return 0;
 }
 
-static int cmp_size_smaller_first(void *priv, struct list_head *a,
-				  struct list_head *b)
+static int cmp_size_smaller_first(void *priv, const struct list_head *a,
+				  const struct list_head *b)
 {
 	struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list, tv.head);
 	struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list, tv.head);
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c b/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
index d399523206c7..29d71267af78 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
@@ -83,7 +83,8 @@ usnic_uiom_interval_node_alloc(long int start, long int last, int ref_cnt,
 	return interval;
 }
 
-static int interval_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int interval_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct usnic_uiom_interval_node *node_a, *node_b;
 
diff --git a/drivers/interconnect/qcom/bcm-voter.c b/drivers/interconnect/qcom/bcm-voter.c
index 1cc565bce2f4..d1591a28b743 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -39,7 +39,7 @@ struct bcm_voter {
 	u32 tcs_wait;
 };
 
-static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
+static int cmp_vcd(void *priv, const struct list_head *a, const struct list_head *b)
 {
 	const struct qcom_icc_bcm *bcm_a = list_entry(a, struct qcom_icc_bcm, list);
 	const struct qcom_icc_bcm *bcm_b = list_entry(b, struct qcom_icc_bcm, list);
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 5d57a5bd171f..841e1c1aa5e6 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -953,7 +953,8 @@ static void dispatch_bio_list(struct bio_list *tmp)
 		submit_bio_noacct(bio);
 }
 
-static int cmp_stripe(void *priv, struct list_head *a, struct list_head *b)
+static int cmp_stripe(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	const struct r5pending_data *da = list_entry(a,
 				struct r5pending_data, sibling);
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 6c1a23cb3e8c..202bf951e909 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -144,8 +144,8 @@ static void sram_free_partitions(struct sram_dev *sram)
 	}
 }
 
-static int sram_reserve_cmp(void *priv, struct list_head *a,
-					struct list_head *b)
+static int sram_reserve_cmp(void *priv, const struct list_head *a,
+					const struct list_head *b)
 {
 	struct sram_reserve *ra = list_entry(a, struct sram_reserve, list);
 	struct sram_reserve *rb = list_entry(b, struct sram_reserve, list);
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 0896e21642be..5eaaa51a5e30 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3855,7 +3855,8 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned nsid,
 	return ret;
 }
 
-static int ns_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int ns_cmp(void *priv, const struct list_head *a,
+		const struct list_head *b)
 {
 	struct nvme_ns *nsa = container_of(a, struct nvme_ns, list);
 	struct nvme_ns *nsb = container_of(b, struct nvme_ns, list);
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 73dcf8cf98fb..ae1c55503513 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -345,7 +345,8 @@ static int cdns_pcie_host_bar_config(struct cdns_pcie_rc *rc,
 	return 0;
 }
 
-static int cdns_pcie_host_dma_ranges_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int cdns_pcie_host_dma_ranges_cmp(void *priv, const struct list_head *a,
+					 const struct list_head *b)
 {
 	struct resource_entry *entry1, *entry2;
 
diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index df981e55c24c..f1cf2232f0b5 100644
--- a/drivers/spi/spi-loopback-test.c
+++ b/drivers/spi/spi-loopback-test.c
@@ -454,7 +454,8 @@ struct rx_ranges {
 	u8 *end;
 };
 
-static int rx_ranges_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int rx_ranges_cmp(void *priv, const struct list_head *a,
+			 const struct list_head *b)
 {
 	struct rx_ranges *rx_a = list_entry(a, struct rx_ranges, list);
 	struct rx_ranges *rx_b = list_entry(b, struct rx_ranges, list);
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 8c31357f08ed..f4139de63b2e 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1634,7 +1634,8 @@ struct btrfs_plug_cb {
 /*
  * rbios on the plug list are sorted for easier merging.
  */
-static int plug_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int plug_cmp(void *priv, const struct list_head *a,
+		    const struct list_head *b)
 {
 	struct btrfs_raid_bio *ra = container_of(a, struct btrfs_raid_bio,
 						 plug_list);
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 92a368627791..00a88bd8105e 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4136,7 +4136,8 @@ static noinline int copy_items(struct btrfs_trans_handle *trans,
 	return ret;
 }
 
-static int extent_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int extent_cmp(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	struct extent_map *em1, *em2;
 
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1c6810bbaf8b..912dd8b9f156 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1224,7 +1224,8 @@ static int open_fs_devices(struct btrfs_fs_devices *fs_devices,
 	return 0;
 }
 
-static int devid_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int devid_cmp(void *priv, const struct list_head *a,
+		     const struct list_head *b)
 {
 	struct btrfs_device *dev1, *dev2;
 
diff --git a/fs/ext4/fsmap.c b/fs/ext4/fsmap.c
index 4c2a9fe30067..4493ef0c715e 100644
--- a/fs/ext4/fsmap.c
+++ b/fs/ext4/fsmap.c
@@ -354,8 +354,8 @@ static unsigned int ext4_getfsmap_find_sb(struct super_block *sb,
 
 /* Compare two fsmap items. */
 static int ext4_getfsmap_compare(void *priv,
-				 struct list_head *a,
-				 struct list_head *b)
+				 const struct list_head *a,
+				 const struct list_head *b)
 {
 	struct ext4_fsmap *fa;
 	struct ext4_fsmap *fb;
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 9567520d79f7..c06a6cdf05de 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1732,7 +1732,8 @@ void gfs2_glock_complete(struct gfs2_glock *gl, int ret)
 	spin_unlock(&gl->gl_lockref.lock);
 }
 
-static int glock_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int glock_cmp(void *priv, const struct list_head *a,
+		     const struct list_head *b)
 {
 	struct gfs2_glock *gla, *glb;
 
diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
index 6410281546f9..88649b43fcff 100644
--- a/fs/gfs2/log.c
+++ b/fs/gfs2/log.c
@@ -695,7 +695,7 @@ void log_flush_wait(struct gfs2_sbd *sdp)
 	}
 }
 
-static int ip_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int ip_cmp(void *priv, const struct list_head *a, const struct list_head *b)
 {
 	struct gfs2_inode *ipa, *ipb;
 
diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index a82f4747aa8d..b4809967efc6 100644
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -634,7 +634,8 @@ static void gfs2_check_magic(struct buffer_head *bh)
 	kunmap_atomic(kaddr);
 }
 
-static int blocknr_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int blocknr_cmp(void *priv, const struct list_head *a,
+		       const struct list_head *b)
 {
 	struct gfs2_bufdata *bda, *bdb;
 
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 414769a6ad11..0129e6bab985 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1155,7 +1155,8 @@ iomap_ioend_try_merge(struct iomap_ioend *ioend, struct list_head *more_ioends,
 EXPORT_SYMBOL_GPL(iomap_ioend_try_merge);
 
 static int
-iomap_ioend_compare(void *priv, struct list_head *a, struct list_head *b)
+iomap_ioend_compare(void *priv, const struct list_head *a,
+		const struct list_head *b)
 {
 	struct iomap_ioend *ia = container_of(a, struct iomap_ioend, io_list);
 	struct iomap_ioend *ib = container_of(b, struct iomap_ioend, io_list);
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index a4aaeea63893..dc3e26e9ed7b 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -102,7 +102,8 @@ static int switch_gc_head(struct ubifs_info *c)
  * This function compares data nodes @a and @b. Returns %1 if @a has greater
  * inode or block number, and %-1 otherwise.
  */
-static int data_nodes_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int data_nodes_cmp(void *priv, const struct list_head *a,
+			  const struct list_head *b)
 {
 	ino_t inuma, inumb;
 	struct ubifs_info *c = priv;
@@ -145,8 +146,8 @@ static int data_nodes_cmp(void *priv, struct list_head *a, struct list_head *b)
  * first and sorted by length in descending order. Directory entry nodes go
  * after inode nodes and are sorted in ascending hash valuer order.
  */
-static int nondata_nodes_cmp(void *priv, struct list_head *a,
-			     struct list_head *b)
+static int nondata_nodes_cmp(void *priv, const struct list_head *a,
+			     const struct list_head *b)
 {
 	ino_t inuma, inumb;
 	struct ubifs_info *c = priv;
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 0f8a6a16421b..4d17e5382b74 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -298,8 +298,8 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r)
  * entries @a and @b by comparing their sequence numer.  Returns %1 if @a has
  * greater sequence number and %-1 otherwise.
  */
-static int replay_entries_cmp(void *priv, struct list_head *a,
-			      struct list_head *b)
+static int replay_entries_cmp(void *priv, const struct list_head *a,
+			      const struct list_head *b)
 {
 	struct ubifs_info *c = priv;
 	struct replay_entry *ra, *rb;
diff --git a/fs/xfs/scrub/bitmap.c b/fs/xfs/scrub/bitmap.c
index f88694f22d05..813b5f219113 100644
--- a/fs/xfs/scrub/bitmap.c
+++ b/fs/xfs/scrub/bitmap.c
@@ -63,8 +63,8 @@ xbitmap_init(
 static int
 xbitmap_range_cmp(
 	void			*priv,
-	struct list_head	*a,
-	struct list_head	*b)
+	const struct list_head	*a,
+	const struct list_head	*b)
 {
 	struct xbitmap_range	*ap;
 	struct xbitmap_range	*bp;
diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c
index 2344757ede63..e3a691937e92 100644
--- a/fs/xfs/xfs_bmap_item.c
+++ b/fs/xfs/xfs_bmap_item.c
@@ -265,8 +265,8 @@ xfs_trans_log_finish_bmap_update(
 static int
 xfs_bmap_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_bmap_intent		*ba;
 	struct xfs_bmap_intent		*bb;
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 37a1d12762d8..592800c8852f 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -2124,9 +2124,9 @@ xfs_buf_delwri_queue(
  */
 static int
 xfs_buf_cmp(
-	void		*priv,
-	struct list_head *a,
-	struct list_head *b)
+	void			*priv,
+	const struct list_head	*a,
+	const struct list_head	*b)
 {
 	struct xfs_buf	*ap = container_of(a, struct xfs_buf, b_list);
 	struct xfs_buf	*bp = container_of(b, struct xfs_buf, b_list);
diff --git a/fs/xfs/xfs_extent_busy.c b/fs/xfs/xfs_extent_busy.c
index ef17c1f6db32..a4075685d9eb 100644
--- a/fs/xfs/xfs_extent_busy.c
+++ b/fs/xfs/xfs_extent_busy.c
@@ -629,8 +629,8 @@ xfs_extent_busy_wait_all(
 int
 xfs_extent_busy_ag_cmp(
 	void			*priv,
-	struct list_head	*l1,
-	struct list_head	*l2)
+	const struct list_head	*l1,
+	const struct list_head	*l2)
 {
 	struct xfs_extent_busy	*b1 =
 		container_of(l1, struct xfs_extent_busy, list);
diff --git a/fs/xfs/xfs_extent_busy.h b/fs/xfs/xfs_extent_busy.h
index 990ab3891971..8aea07100092 100644
--- a/fs/xfs/xfs_extent_busy.h
+++ b/fs/xfs/xfs_extent_busy.h
@@ -58,7 +58,8 @@ void
 xfs_extent_busy_wait_all(struct xfs_mount *mp);
 
 int
-xfs_extent_busy_ag_cmp(void *priv, struct list_head *a, struct list_head *b);
+xfs_extent_busy_ag_cmp(void *priv, const struct list_head *a,
+	const struct list_head *b);
 
 static inline void xfs_extent_busy_sort(struct list_head *list)
 {
diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c
index 93223ebb3372..2424230ca2c3 100644
--- a/fs/xfs/xfs_extfree_item.c
+++ b/fs/xfs/xfs_extfree_item.c
@@ -397,8 +397,8 @@ xfs_trans_free_extent(
 static int
 xfs_extent_free_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_extent_free_item	*ra;
diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c
index 07ebccbbf4df..746f4eda724c 100644
--- a/fs/xfs/xfs_refcount_item.c
+++ b/fs/xfs/xfs_refcount_item.c
@@ -269,8 +269,8 @@ xfs_trans_log_finish_refcount_update(
 static int
 xfs_refcount_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_refcount_intent	*ra;
diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
index 49cebd68b672..dc4f0c9f0897 100644
--- a/fs/xfs/xfs_rmap_item.c
+++ b/fs/xfs/xfs_rmap_item.c
@@ -337,8 +337,8 @@ xfs_trans_log_finish_rmap_update(
 static int
 xfs_rmap_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_rmap_intent		*ra;
diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
index 20f178c24e9d..453105f74e05 100644
--- a/include/linux/list_sort.h
+++ b/include/linux/list_sort.h
@@ -6,8 +6,9 @@
 
 struct list_head;
 
+typedef int __attribute__((nonnull(2,3))) (*list_cmp_func_t)(void *,
+		const struct list_head *, const struct list_head *);
+
 __attribute__((nonnull(2,3)))
-void list_sort(void *priv, struct list_head *head,
-	       int (*cmp)(void *priv, struct list_head *a,
-			  struct list_head *b));
+void list_sort(void *priv, struct list_head *head, list_cmp_func_t cmp);
 #endif
diff --git a/lib/list_sort.c b/lib/list_sort.c
index 52f0c258c895..a926d96ffd44 100644
--- a/lib/list_sort.c
+++ b/lib/list_sort.c
@@ -7,16 +7,13 @@
 #include <linux/list_sort.h>
 #include <linux/list.h>
 
-typedef int __attribute__((nonnull(2,3))) (*cmp_func)(void *,
-		struct list_head const *, struct list_head const *);
-
 /*
  * Returns a list organized in an intermediate format suited
  * to chaining of merge() calls: null-terminated, no reserved or
  * sentinel head node, "prev" links not maintained.
  */
 __attribute__((nonnull(2,3,4)))
-static struct list_head *merge(void *priv, cmp_func cmp,
+static struct list_head *merge(void *priv, list_cmp_func_t cmp,
 				struct list_head *a, struct list_head *b)
 {
 	struct list_head *head, **tail = &head;
@@ -52,7 +49,7 @@ static struct list_head *merge(void *priv, cmp_func cmp,
  * throughout.
  */
 __attribute__((nonnull(2,3,4,5)))
-static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
+static void merge_final(void *priv, list_cmp_func_t cmp, struct list_head *head,
 			struct list_head *a, struct list_head *b)
 {
 	struct list_head *tail = head;
@@ -185,9 +182,7 @@ static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
  * 2^(k+1) - 1 (second merge of case 5 when x == 2^(k-1) - 1).
  */
 __attribute__((nonnull(2,3)))
-void list_sort(void *priv, struct list_head *head,
-		int (*cmp)(void *priv, struct list_head *a,
-			struct list_head *b))
+void list_sort(void *priv, struct list_head *head, list_cmp_func_t cmp)
 {
 	struct list_head *list = head->next, *pending = NULL;
 	size_t count = 0;	/* Count of pending */
@@ -227,7 +222,7 @@ void list_sort(void *priv, struct list_head *head,
 		if (likely(bits)) {
 			struct list_head *a = *tail, *b = a->prev;
 
-			a = merge(priv, (cmp_func)cmp, b, a);
+			a = merge(priv, cmp, b, a);
 			/* Install the merged result in place of the inputs */
 			a->prev = b->prev;
 			*tail = a;
@@ -249,10 +244,10 @@ void list_sort(void *priv, struct list_head *head,
 
 		if (!next)
 			break;
-		list = merge(priv, (cmp_func)cmp, pending, list);
+		list = merge(priv, cmp, pending, list);
 		pending = next;
 	}
 	/* The final merge, rebuilding prev links */
-	merge_final(priv, (cmp_func)cmp, head, pending, list);
+	merge_final(priv, cmp, head, pending, list);
 }
 EXPORT_SYMBOL(list_sort);
diff --git a/lib/test_list_sort.c b/lib/test_list_sort.c
index 1f017d3b610e..00daaf23316f 100644
--- a/lib/test_list_sort.c
+++ b/lib/test_list_sort.c
@@ -56,7 +56,8 @@ static int __init check(struct debug_el *ela, struct debug_el *elb)
 	return 0;
 }
 
-static int __init cmp(void *priv, struct list_head *a, struct list_head *b)
+static int __init cmp(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	struct debug_el *ela, *elb;
 
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index ee5ac40ea2b6..f8141443f2e2 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -397,8 +397,8 @@ static struct publication *tipc_service_remove_publ(struct service_range *sr,
  * Code reused: time_after32() for the same purpose
  */
 #define publication_after(pa, pb) time_after32((pa)->id, (pb)->id)
-static int tipc_publ_sort(void *priv, struct list_head *a,
-			  struct list_head *b)
+static int tipc_publ_sort(void *priv, const struct list_head *a,
+			  const struct list_head *b)
 {
 	struct publication *pa, *pb;
 
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:09 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:09 -0700
Subject: [PATCH v5 11/18] psci: use function_nocfi for cpu_resume
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-12-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function pointers with
jump table addresses, which results in __pa_symbol returning the
physical address of the jump table entry. As the jump table contains
an immediate jump to an EL1 virtual address, this typically won't
work as intended. Use function_nocfi to get the actual address of
cpu_resume.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 drivers/firmware/psci/psci.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f5fc429cae3f..64344e84bd63 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -325,8 +325,9 @@ static int __init psci_features(u32 psci_func_id)
 static int psci_suspend_finisher(unsigned long state)
 {
 	u32 power_state = state;
+	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
 
-	return psci_ops.cpu_suspend(power_state, __pa_symbol(cpu_resume));
+	return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
 }
 
 int psci_cpu_suspend_enter(u32 state)
@@ -344,8 +345,10 @@ int psci_cpu_suspend_enter(u32 state)
 
 static int psci_system_suspend(unsigned long unused)
 {
+	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+
 	return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
-			      __pa_symbol(cpu_resume), 0, 0);
+			      pa_cpu_resume, 0, 0);
 }
 
 static int psci_system_suspend_enter(suspend_state_t state)
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:10 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:10 -0700
Subject: [PATCH v5 12/18] arm64: implement function_nocfi
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-13-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function addresses in
instrumented C code with jump table addresses. This change implements
the function_nocfi() macro, which returns the actual function address
instead.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/include/asm/memory.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..b55410afd3d1 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -321,6 +321,21 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define virt_to_pfn(x)		__phys_to_pfn(__virt_to_phys((unsigned long)(x)))
 #define sym_to_pfn(x)		__phys_to_pfn(__pa_symbol(x))
 
+#ifdef CONFIG_CFI_CLANG
+/*
+ * With CONFIG_CFI_CLANG, the compiler replaces function address
+ * references with the address of the function's CFI jump table
+ * entry. The function_nocfi macro always returns the address of the
+ * actual function instead.
+ */
+#define function_nocfi(x) ({						\
+	void *addr;							\
+	asm("adrp %0, " __stringify(x) "\n\t"				\
+	    "add  %0, %0, :lo12:" __stringify(x) : "=r" (addr));	\
+	addr;								\
+})
+#endif
+
 /*
  *  virt_to_page(x)	convert a _valid_ virtual address to struct page *
  *  virt_addr_valid(x)	indicates whether a virtual address is valid
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:11 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:11 -0700
Subject: [PATCH v5 13/18] arm64: use function_nocfi with __pa_symbol
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-14-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function address
references with the address of the function's CFI jump table
entry. This means that __pa_symbol(function) returns the physical
address of the jump table entry, which can lead to address space
confusion as the jump table points to the function's virtual
address. Therefore, use the function_nocfi() macro to ensure we are
always taking the address of the actual function instead.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/include/asm/mmu_context.h      | 2 +-
 arch/arm64/kernel/acpi_parking_protocol.c | 3 ++-
 arch/arm64/kernel/cpu-reset.h             | 2 +-
 arch/arm64/kernel/cpufeature.c            | 2 +-
 arch/arm64/kernel/psci.c                  | 3 ++-
 arch/arm64/kernel/smp_spin_table.c        | 3 ++-
 6 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index bd02e99b1a4c..386b96400a57 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -140,7 +140,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 		ttbr1 |= TTBR_CNP_BIT;
 	}
 
-	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
+	replace_phys = (void *)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
 
 	cpu_install_idmap();
 	replace_phys(ttbr1);
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index e7c941d8340d..bfeeb5319abf 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -99,7 +99,8 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * that read this address need to convert this address to the
 	 * Boot-Loader's endianness before jumping.
 	 */
-	writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
+	writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
+		       &mailbox->entry_point);
 	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
 
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index ed50e9587ad8..f3adc574f969 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -22,7 +22,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
 
 	unsigned long el2_switch = !is_kernel_in_hyp_mode() &&
 		is_hyp_mode_available();
-	restart = (void *)__pa_symbol(__cpu_soft_restart);
+	restart = (void *)__pa_symbol(function_nocfi(__cpu_soft_restart));
 
 	cpu_install_idmap();
 	restart(el2_switch, entry, arg0, arg1, arg2);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e5281e1c8f1d..0b2e0d7b13ec 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1462,7 +1462,7 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 	if (arm64_use_ng_mappings)
 		return;
 
-	remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
+	remap_fn = (void *)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
 
 	cpu_install_idmap();
 	remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 62d2bda7adb8..e74bcb57559b 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -38,7 +38,8 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
 
 static int cpu_psci_cpu_boot(unsigned int cpu)
 {
-	int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
+	int err = psci_ops.cpu_on(cpu_logical_map(cpu),
+			__pa_symbol(function_nocfi(secondary_entry)));
 	if (err)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
 
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 056772c26098..4c4e36ded4aa 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -88,7 +88,8 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
 	 * boot-loader's endianness before jumping. This is mandated by
 	 * the boot protocol.
 	 */
-	writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
+	writeq_relaxed(__pa_symbol(function_nocfi(secondary_holding_pen)),
+		       release_addr);
 	__flush_dcache_area((__force void *)release_addr,
 			    sizeof(*release_addr));
 
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:12 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:12 -0700
Subject: [PATCH v5 14/18] arm64: add __nocfi to functions that jump to a
 physical address
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-15-samitolvanen@google.com>

Disable CFI checking for functions that switch to linear mapping and
make an indirect call to a physical address, since the compiler only
understands virtual addresses and the CFI check for such indirect calls
would always fail.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/kernel/cpu-reset.h        | 8 ++++----
 arch/arm64/kernel/cpufeature.c       | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 386b96400a57..d3cef9133539 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void)
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
  */
-static inline void cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
 {
 	typedef void (ttbr_replace_func)(phys_addr_t);
 	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index f3adc574f969..9a7b1262ef17 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -13,10 +13,10 @@
 void __cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
 	unsigned long arg0, unsigned long arg1, unsigned long arg2);
 
-static inline void __noreturn cpu_soft_restart(unsigned long entry,
-					       unsigned long arg0,
-					       unsigned long arg1,
-					       unsigned long arg2)
+static inline void __noreturn __nocfi cpu_soft_restart(unsigned long entry,
+						       unsigned long arg0,
+						       unsigned long arg1,
+						       unsigned long arg2)
 {
 	typeof(__cpu_soft_restart) *restart;
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 0b2e0d7b13ec..c2f94a5206e0 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1445,7 +1445,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 }
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
-static void
+static void __nocfi
 kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 {
 	typedef void (kpti_remap_fn)(int, int, phys_addr_t);
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:14 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:14 -0700
Subject: [PATCH v5 16/18] arm64: ftrace: use function_nocfi for ftrace_call
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-17-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function pointers with
jump table addresses, which breaks dynamic ftrace as the address of
ftrace_call is replaced with the address of ftrace_call.cfi_jt. Use
function_nocfi() to get the address of the actual function instead.

Suggested-by: Ben Dai <ben.dai at unisoc.com>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
---
 arch/arm64/kernel/ftrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 86a5cf9bc19a..b5d3ddaf69d9 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -55,7 +55,7 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
 	unsigned long pc;
 	u32 new;
 
-	pc = (unsigned long)&ftrace_call;
+	pc = (unsigned long)function_nocfi(ftrace_call);
 	new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
 					  AARCH64_INSN_BRANCH_LINK);
 
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:13 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:13 -0700
Subject: [PATCH v5 15/18] arm64: add __nocfi to __apply_alternatives
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-16-samitolvanen@google.com>

__apply_alternatives makes indirect calls to functions whose address
is taken in assembly code using the alternative_cb macro. With
non-canonical CFI, the compiler won't replace these function
references with the jump table addresses, which trips CFI. Disable CFI
checking in the function to work around the issue.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/kernel/alternative.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 1184c44ea2c7..abc84636af07 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -133,8 +133,8 @@ static void clean_dcache_range_nopatch(u64 start, u64 end)
 	} while (cur += d_size, cur < end);
 }
 
-static void __apply_alternatives(void *alt_region,  bool is_module,
-				 unsigned long *feature_mask)
+static void __nocfi __apply_alternatives(void *alt_region,  bool is_module,
+					 unsigned long *feature_mask)
 {
 	struct alt_instr *alt;
 	struct alt_region *region = alt_region;
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:15 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:15 -0700
Subject: [PATCH v5 17/18] KVM: arm64: Disable CFI for nVHE
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-18-samitolvanen@google.com>

Disable CFI for the nVHE code to avoid address space confusion.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/kvm/hyp/nvhe/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index a6707df4f6c0..fb24a0f022ad 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -75,9 +75,9 @@ quiet_cmd_hyprel = HYPREL  $@
 quiet_cmd_hypcopy = HYPCOPY $@
       cmd_hypcopy = $(OBJCOPY) --prefix-symbols=__kvm_nvhe_ $< $@
 
-# Remove ftrace and Shadow Call Stack CFLAGS.
-# This is equivalent to the 'notrace' and '__noscs' annotations.
-KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
+# Remove ftrace, Shadow Call Stack, and CFI CFLAGS.
+# This is equivalent to the 'notrace', '__noscs', and '__nocfi' annotations.
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS) $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
 
 # KVM nVHE code is run at a different exception code with a different map, so
 # compiler instrumentation that inserts callbacks or checks into the code may
-- 
2.31.0.208.g409f899ff0-goog



From samitolvanen at google.com  Fri Apr  2 00:32:16 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  1 Apr 2021 16:32:16 -0700
Subject: [PATCH v5 18/18] arm64: allow CONFIG_CFI_CLANG to be selected
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210401233216.2540591-19-samitolvanen@google.com>

Select ARCH_SUPPORTS_CFI_CLANG to allow CFI to be enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..d7395772b6b8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -75,6 +75,7 @@ config ARM64
 	select ARCH_SUPPORTS_SHADOW_CALL_STACK if CC_HAVE_SHADOW_CALL_STACK
 	select ARCH_SUPPORTS_LTO_CLANG if CPU_LITTLE_ENDIAN
 	select ARCH_SUPPORTS_LTO_CLANG_THIN
+	select ARCH_SUPPORTS_CFI_CLANG
 	select ARCH_SUPPORTS_ATOMIC_RMW
 	select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && (GCC_VERSION >= 50000 || CC_IS_CLANG)
 	select ARCH_SUPPORTS_NUMA_BALANCING
-- 
2.31.0.208.g409f899ff0-goog



From f.fainelli at gmail.com  Fri Apr  2 00:52:33 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 1 Apr 2021 16:52:33 -0700
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
Message-ID: <a8b8dabd-6637-335d-5abc-5a88d21b4db0@gmail.com>

On 3/30/21 4:40 AM, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin at nokia.com>
> 
> FTRACE's function tracer currently doesn't always work on ARM with
> MODULE_PLT option enabled. If the module is loaded too far, FTRACE's
> code modifier cannot cope with introduced veneers and turns the
> function tracer off globally.
> 
> ARM64 already has a solution for the problem, refer to the following
> patches:
> 
> arm64: ftrace: emit ftrace-mod.o contents through code
> arm64: module-plts: factor out PLT generation code for ftrace
> arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels
> arm64: ftrace: fix building without CONFIG_MODULES
> arm64: ftrace: add support for far branches to dynamic ftrace
> arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()
> 
> But the presented ARM variant has just a half of the footprint in terms of
> the changed LoCs. It also retains the code validation-before-modification
> instead of switching it off.
> 
> Changelog:
> v8:
> * Add warn suppress parameter to arm_gen_branch_link()
> v7:
> * rebased
> v6:
> * rebased
> v5:
> * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block
> * use "for" loop instead of "while"
> * scripts/recordmcount is filtering reloc types
> v4:
> * Fixed build without CONFIG_FUNCTION_TRACER
> * Reorganized pre-allocated PLTs handling in get_module_plt(),
>   now compiler eliminates the whole FTRACE-related handling code
>     if ARRAY_SIZE(fixed_plts) == 0
>     v3:
>     * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled
>     v2:
>     * As suggested by Steven Rostedt, refrain from tree-wide API modification,
>       save module pointer in struct dyn_arch_ftrace instead (PowerPC way)

FWIW, ftracetest did not pick up new failures (nor were new tests fixed)
with this patch series.
-- 
Florian


From lkp at intel.com  Fri Apr  2 00:56:17 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 07:56:17 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1172/1701]
 drivers/irqchip/irq-xilinx-intc.c:170:10: error: implicit declaration of
 function 'handle_domain_irq'; did you mean 'handle_bad_irq'?
Message-ID: <202104020713.UcIcXUGc-lkp@intel.com>

Hi Michal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 9b798b0101efddfd3c5f6e2d86dfbb1522bfc1cf [1172/1701] irqchip: xilinx: Use handle_domain_irq()
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/9b798b0101efddfd3c5f6e2d86dfbb1522bfc1cf
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 9b798b0101efddfd3c5f6e2d86dfbb1522bfc1cf
        # save the attached .config to linux build tree
        make W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/irqchip/irq-xilinx-intc.c: In function 'xil_intc_handle_irq':
>> drivers/irqchip/irq-xilinx-intc.c:170:10: error: implicit declaration of function 'handle_domain_irq'; did you mean 'handle_bad_irq'? [-Werror=implicit-function-declaration]
     170 |    ret = handle_domain_irq(irqc->root_domain, hwirq, regs);
         |          ^~~~~~~~~~~~~~~~~
         |          handle_bad_irq
   drivers/irqchip/irq-xilinx-intc.c: In function 'xilinx_intc_of_init':
   drivers/irqchip/irq-xilinx-intc.c:280:3: error: implicit declaration of function 'set_handle_irq'; did you mean 'generic_handle_irq'? [-Werror=implicit-function-declaration]
     280 |   set_handle_irq(xil_intc_handle_irq);
         |   ^~~~~~~~~~~~~~
         |   generic_handle_irq
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +170 drivers/irqchip/irq-xilinx-intc.c

   160	
   161	static void xil_intc_handle_irq(struct pt_regs *regs)
   162	{
   163		int ret;
   164		unsigned int hwirq, cpu_id = smp_processor_id();
   165		struct xintc_irq_chip *irqc = per_cpu_ptr(&primary_intc, cpu_id);
   166	
   167		do {
   168			hwirq = irqc->read_fn(irqc->base + IVR);
   169			if (hwirq != -1U) {
 > 170				ret = handle_domain_irq(irqc->root_domain, hwirq, regs);
   171				WARN_ONCE(ret, "cpu %d: Unhandled HWIRQ %d\n",
   172					  cpu_id, hwirq);
   173				continue;
   174			}
   175	
   176			break;
   177		} while (1);
   178	}
   179	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22043 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/bfa98a40/attachment-0001.gz>

From lkp at intel.com  Fri Apr  2 01:02:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 08:02:43 +0800
Subject: [arm-platforms:kvm-arm64/nvhe-panic-info 5/5]
 arch/arm64/kvm/handle_exit.c:295:24: warning: no previous prototype for
 function 'nvhe_hyp_panic_handler'
Message-ID: <202104020840.2i4MPNds-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nvhe-panic-info
head:   aec0fae62e47050019474936248a311a0ab08705
commit: aec0fae62e47050019474936248a311a0ab08705 [5/5] KVM: arm64: Log source when panicking from nVHE hyp
config: arm64-randconfig-r033-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=aec0fae62e47050019474936248a311a0ab08705
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms kvm-arm64/nvhe-panic-info
        git checkout aec0fae62e47050019474936248a311a0ab08705
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:182:25: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_CP14_64]    = kvm_handle_cp14_64,
                                     ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:183:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_HVC32]      = handle_hvc,
                                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:184:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_SMC32]      = handle_smc,
                                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:185:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_HVC64]      = handle_hvc,
                                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:186:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_SMC64]      = handle_smc,
                                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:187:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_SYS64]      = kvm_handle_sys_reg,
                                     ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:188:21: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_SVE]        = handle_sve,
                                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:189:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_IABT_LOW]   = kvm_handle_guest_abort,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:190:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_DABT_LOW]   = kvm_handle_guest_abort,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:191:28: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:192:28: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_WATCHPT_LOW]= kvm_handle_guest_debug,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:193:28: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_BREAKPT_LOW]= kvm_handle_guest_debug,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:194:24: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_BKPT32]     = kvm_handle_guest_debug,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:195:23: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_BRK64]      = kvm_handle_guest_debug,
                                     ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:196:26: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_FP_ASIMD]   = handle_no_fpsimd,
                                     ^~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:197:21: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           [ESR_ELx_EC_PAC]        = kvm_handle_ptrauth,
                                     ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:176:27: note: previous initialization is here
           [0 ... ESR_ELx_EC_MAX]  = kvm_handle_unknown_ec,
                                     ^~~~~~~~~~~~~~~~~~~~~
>> arch/arm64/kvm/handle_exit.c:295:24: warning: no previous prototype for function 'nvhe_hyp_panic_handler' [-Wmissing-prototypes]
   void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr,
                          ^
   arch/arm64/kvm/handle_exit.c:295:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr,
   ^
   static 
   22 warnings generated.


vim +/nvhe_hyp_panic_handler +295 arch/arm64/kvm/handle_exit.c

   294	
 > 295	void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr,

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 48010 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/a64dbe41/attachment-0001.gz>

From guohanjun at huawei.com  Fri Apr  2 01:35:29 2021
From: guohanjun at huawei.com (Hanjun Guo)
Date: Fri, 2 Apr 2021 08:35:29 +0800
Subject: [PATCH v14 02/10] iommu/arm-smmu-v3: Use device properties for
 pasid-num-bits
In-Reply-To: <20210401154718.307519-3-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-3-jean-philippe@linaro.org>
Message-ID: <5e0037ea-7c1a-ecbd-e5db-89050679650e@huawei.com>

On 2021/4/1 23:47, Jean-Philippe Brucker wrote:
> The pasid-num-bits property shouldn't need a dedicated fwspec field,
> it's a job for device properties. Add properties for IORT, and access
> the number of PASID bits using device_property_read_u32().
> 
> Suggested-by: Robin Murphy<robin.murphy at arm.com>
> Acked-by: Jonathan Cameron<Jonathan.Cameron at huawei.com>
> Acked-by: Will Deacon<will at kernel.org>
> Reviewed-by: Eric Auger<eric.auger at redhat.com>
> Signed-off-by: Jean-Philippe Brucker<jean-philippe at linaro.org>
> ---
>   include/linux/iommu.h                       |  2 --
>   drivers/acpi/arm64/iort.c                   | 13 +++++++------

Acked-by: Hanjun Guo <guohanjun at huawei.com>


From guohanjun at huawei.com  Fri Apr  2 01:45:38 2021
From: guohanjun at huawei.com (Hanjun Guo)
Date: Fri, 2 Apr 2021 08:45:38 +0800
Subject: [PATCH v14 09/10] ACPI/IORT: Enable stall support for platform
 devices
In-Reply-To: <20210401154718.307519-10-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-10-jean-philippe@linaro.org>
Message-ID: <15220cd4-8260-316b-6133-fec13a6604f8@huawei.com>

On 2021/4/1 23:47, Jean-Philippe Brucker wrote:
> Copy the "Stall supported" bit, that tells whether a named component
> supports stall, into the dma-can-stall device property.
> 
> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
> ---
>   drivers/acpi/arm64/iort.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 3912a1f6058e..0828f70cb782 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -968,13 +968,15 @@ static int iort_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
>   static void iort_named_component_init(struct device *dev,
>   				      struct acpi_iort_node *node)
>   {
> -	struct property_entry props[2] = {};
> +	struct property_entry props[3] = {};
>   	struct acpi_iort_named_component *nc;
>   
>   	nc = (struct acpi_iort_named_component *)node->node_data;
>   	props[0] = PROPERTY_ENTRY_U32("pasid-num-bits",
>   				      FIELD_GET(ACPI_IORT_NC_PASID_BITS,
>   						nc->node_flags));
> +	if (nc->node_flags & ACPI_IORT_NC_STALL_SUPPORTED)
> +		props[1] = PROPERTY_ENTRY_BOOL("dma-can-stall");
>   
>   	if (device_add_properties(dev, props))
>   		dev_warn(dev, "Could not add device properties\n");

Acked-by: Hanjun Guo <guohanjun at huawei.com>


From zev at bewilderbeest.net  Fri Apr  2 01:47:13 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu,  1 Apr 2021 19:47:13 -0500
Subject: [PATCH v3 1/4] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210402004716.15961-1-zev@bewilderbeest.net>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
Message-ID: <20210402004716.15961-2-zev@bewilderbeest.net>

This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it
was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
       offset and bit number to identify how the SIRQ polarity should be
       configured. One possible data source is the LPC/eSPI mode bit. Only
       applicable to aspeed,ast2500-vuart.
+    deprecated: true
 
 required:
   - reg
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 01:47:12 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu,  1 Apr 2021 19:47:12 -0500
Subject: [PATCH v3 0/4] aspeed-vuart: generalized DT properties
Message-ID: <20210402004716.15961-1-zev@bewilderbeest.net>

This series generalizes the aspeed-vuart driver's device tree
properties to cover all the attributes it currently exposes via sysfs.

The aspeed,sirq-polarity-sense property was a bit of a design mistake
in that it ties Aspeed VUART SIRQ polarity to SCU register bits that
aren't really inherently related to it; the first patch in this series
deprecates it (though we hope to eventually remove it).

The rest of the series adds two new properties, aspeed,lpc-address and
aspeed,sirq.  The latter allows describing the SIRQ polarity (along
with the interrupt number) directly, providing a simpler replacement
for aspeed,sirq-polarity-sense.


Changes since v2 [0]:
 - expanded to also handle sirq number and lpc address in addition to
   sirq polarity
 - added default settings if DT properties not specified
 - refactored existing sysfs code slightly, adding range checks
 - cleaned up 'make dt_binding_check' warnings

Changes since v1 [1]:
 - deprecate and retain aspeed,sirq-polarity-sense instead of removing it
 - drop e3c246d4i dts addition from this series

[0] https://lore.kernel.org/openbmc/20210401005702.28271-1-zev at bewilderbeest.net/
[1] https://lore.kernel.org/openbmc/20210330002338.335-1-zev at bewilderbeest.net/

Zev Weiss (4):
  dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
  drivers/tty/serial/8250: refactor sirq and lpc address setting code
  drivers/tty/serial/8250: add aspeed,lpc-address and aspeed,sirq DT
    properties
  dt-bindings: serial: 8250: add aspeed,lpc-address and aspeed,sirq

 .../devicetree/bindings/serial/8250.yaml      | 28 +++++-
 drivers/tty/serial/8250/8250_aspeed_vuart.c   | 95 +++++++++++++++----
 2 files changed, 103 insertions(+), 20 deletions(-)

-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 01:47:14 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu,  1 Apr 2021 19:47:14 -0500
Subject: [PATCH v3 2/4] drivers/tty/serial/8250: refactor sirq and lpc address
 setting code
In-Reply-To: <20210402004716.15961-1-zev@bewilderbeest.net>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
Message-ID: <20210402004716.15961-3-zev@bewilderbeest.net>

This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers.  While we're at it,
these functions now provide some basic bounds-checking on their
arguments.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..8433f8dbb186 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
 }
 
+static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
+{
+	if (addr > U16_MAX)
+		return -EINVAL;
+
+	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+	return 0;
+}
+
 static ssize_t lpc_address_store(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
-	unsigned long val;
+	u32 val;
 	int err;
 
-	err = kstrtoul(buf, 0, &val);
+	err = kstrtou32(buf, 0, &val);
 	if (err)
 		return err;
 
-	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
-	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
-
-	return count;
+	err = aspeed_vuart_set_lpc_address(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(lpc_address);
@@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
 }
 
+static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
+{
+	u8 reg;
+
+	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
+		return -EINVAL;
+
+	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+	reg |= sirq;
+	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+	return 0;
+}
+
 static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
 			  const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
 	unsigned long val;
 	int err;
-	u8 reg;
 
 	err = kstrtoul(buf, 0, &val);
 	if (err)
 		return err;
 
-	val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
-	val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-
-	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
-	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-	reg |= val;
-	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
-
-	return count;
+	err = aspeed_vuart_set_sirq(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(sirq);
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 01:47:15 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu,  1 Apr 2021 19:47:15 -0500
Subject: [PATCH v3 3/4] drivers/tty/serial/8250: add aspeed,
 lpc-address and aspeed, sirq DT properties
In-Reply-To: <20210402004716.15961-1-zev@bewilderbeest.net>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
Message-ID: <20210402004716.15961-4-zev@bewilderbeest.net>

These allow describing all the Aspeed VUART attributes currently
available via sysfs.  aspeed,sirq provides a replacement for the
deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 44 ++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 8433f8dbb186..10b1f33386e6 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -28,6 +28,10 @@
 #define ASPEED_VUART_ADDRL		0x28
 #define ASPEED_VUART_ADDRH		0x2c
 
+#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
+#define ASPEED_VUART_DEFAULT_SIRQ	4
+#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
+
 struct aspeed_vuart {
 	struct device		*dev;
 	void __iomem		*regs;
@@ -393,7 +397,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 	struct aspeed_vuart *vuart;
 	struct device_node *np;
 	struct resource *res;
-	u32 clk, prop;
+	u32 clk, prop, sirq[2];
+	bool sirq_polarity;
 	int rc;
 
 	np = pdev->dev.of_node;
@@ -501,6 +506,43 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 		of_node_put(sirq_polarity_sense_args.np);
 	}
 
+	rc = of_property_read_u32(np, "aspeed,lpc-address", &prop);
+	if (rc < 0)
+		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
+
+	rc = aspeed_vuart_set_lpc_address(vuart, prop);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid value in aspeed,lpc-address property\n");
+		goto err_clk_disable;
+	}
+
+	rc = of_property_read_u32_array(np, "aspeed,sirq", sirq, 2);
+	if (rc < 0) {
+		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
+		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
+	}
+
+	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid sirq number in aspeed,sirq property\n");
+		goto err_clk_disable;
+	}
+
+	switch (sirq[1]) {
+	case IRQ_TYPE_LEVEL_LOW:
+		sirq_polarity = false;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		sirq_polarity = true;
+		break;
+	default:
+		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,sirq property\n");
+		rc = -EINVAL;
+		goto err_clk_disable;
+	}
+
+	aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
+
 	aspeed_vuart_set_enabled(vuart, true);
 	aspeed_vuart_set_host_tx_discard(vuart, true);
 	platform_set_drvdata(pdev, vuart);
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 01:47:16 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu,  1 Apr 2021 19:47:16 -0500
Subject: [PATCH v3 4/4] dt-bindings: serial: 8250: add aspeed,
 lpc-address and aspeed, sirq
In-Reply-To: <20210402004716.15961-1-zev@bewilderbeest.net>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
Message-ID: <20210402004716.15961-5-zev@bewilderbeest.net>

These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,sirq provides a
replacement for the deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..a6e01f9b745f 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,13 @@ maintainers:
 allOf:
   - $ref: /schemas/serial.yaml#
   - if:
-      required:
-        - aspeed,sirq-polarity-sense
+      anyOf:
+        - required:
+            - aspeed,lpc-address
+        - required:
+            - aspeed,sirq
+        - required:
+            - aspeed,sirq-polarity-sense
     then:
       properties:
         compatible:
@@ -190,6 +195,20 @@ properties:
       applicable to aspeed,ast2500-vuart.
     deprecated: true
 
+  aspeed,lpc-address:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      The VUART LPC address.  Only applicable to aspeed,ast2500-vuart.
+
+  aspeed,sirq:
+    $ref: "/schemas/types.yaml#/definitions/uint32-array"
+    minItems: 2
+    maxItems: 2
+    description: |
+      A 2-cell property describing the VUART SIRQ number and SIRQ
+      polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH).  Only
+      applicable to aspeed,ast2500-vuart.
+
 required:
   - reg
   - interrupts
@@ -221,6 +240,7 @@ examples:
     };
   - |
     #include <dt-bindings/clock/aspeed-clock.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
     serial at 1e787000 {
         compatible = "aspeed,ast2500-vuart";
         reg = <0x1e787000 0x40>;
@@ -228,7 +248,8 @@ examples:
         interrupts = <8>;
         clocks = <&syscon ASPEED_CLK_APB>;
         no-loopback-test;
-        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
+        aspeed,lpc-address = <0x3f8>;
+        aspeed,sirq = <4 IRQ_TYPE_LEVEL_LOW>;
     };
 
 ...
-- 
2.31.1



From swboyd at chromium.org  Fri Apr  2 01:50:38 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Thu, 01 Apr 2021 17:50:38 -0700
Subject: [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data
 Capture and Compare unit(DCC)
In-Reply-To: <326da78181b566ee7d48683d68bb89d7@codeaurora.org>
References: <cover.1616651305.git.schowdhu@codeaurora.org>
 <dc058ed6d05f1aec4e97fee6d4c007abdf3b54a0.1616651305.git.schowdhu@codeaurora.org>
 <161704834593.3012082.17486072850156076295@swboyd.mtv.corp.google.com>
 <326da78181b566ee7d48683d68bb89d7@codeaurora.org>
Message-ID: <161732463842.2260335.16117110131113613939@swboyd.mtv.corp.google.com>

Quoting schowdhu at codeaurora.org (2021-04-01 07:04:07)
> On 2021-03-30 01:35, Stephen Boyd wrote:
> > Quoting Souradeep Chowdhury (2021-03-25 01:02:33)
> >> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> >> new file mode 100644
> >> index 0000000..a55d8ca7
> >> --- /dev/null
> >> +++ b/drivers/soc/qcom/dcc.c
> >> @@ -0,0 +1,1549 @@
[..]
> > 
> >> +       void __iomem            *base;
> >> +       u32                     reg_size;
> >> +       struct device           *dev;
> >> +       struct mutex            mutex;
> > 
> > In particular what this mutex is protecting.
> 
> Ack. The mutex is used to protect the access as well as manipulation of 
> the main instance of dcc_drvdata structure
> initialized during probe time. This structure contains the useful driver 
> data information and is set using the call
> platform_set_drvdata(pdev, drvdata) which links this data to the 
> platform device and hence needs to be protected via
> mutex locks. The same convention is followed across other similar 
> drivers exposing userspace like the llcc driver.

The region that the mutex is protecting seems quite large. That's
probably because I don't understand the driver.

> > 
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +
> >> +       for (curr_list = 0; curr_list < drvdata->nr_link_list; 
> >> curr_list++) {
> >> +               if (!drvdata->enable[curr_list])
> >> +                       continue;
> >> +               ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> >> +               tmp_ll_cfg = ll_cfg & ~BIT(9);
> >> +               dcc_writel(drvdata, tmp_ll_cfg, 
> >> DCC_LL_CFG(curr_list));
> >> +               dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
> >> +               dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
> >> +       }
> > 
> > Does the mutex need to be held while waiting for ready?
> 
> Yes, to maintain consistency because inside the dcc_ready function, 
> there is access to dcc_drvdata structure set
> on the platform device.

Is the drvdata going to be modified somewhere else?

> >> +
> >> +               dev_info(drvdata->dev, "All values written to 
> >> enable.\n");
> > 
> > Debug print?
> 
> Ack
> 
> > 
> >> +               /* Make sure all config is written in sram */
> >> +               mb();
> > 
> > This won't work as intended.
> 
> This was called to prevent instruction reordering if the driver runs on 
> multiple
> CPU cores. As the hardware manipulation has to be done sequentially 
> before the
> trigger is set. Kindly let me know the concern in this case.

Device I/O with the proper accessors is sequential even if the process
moves to a different CPU. Is that what you're worried about? The comment
says "make sure it is written to sram", which should be achieved by
reading some register back from the device after all the writes so that
the driver knows the writes have been posted to the device. I believe
this mb() is doing nothing.

> 
> > 
> >> +
> >> +               drvdata->enable[list] = true;
> >> +
> >> +               /* 5. Configure trigger */
> >> +               dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
> >> +       }
> >> +
> >> +err:
> >> +       mutex_unlock(&drvdata->mutex);
> >> +       return ret;
> >> +}
> >> +
> >> +static void dcc_disable(struct dcc_drvdata *drvdata)
> >> +{
> >> +       int curr_list;
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +
> >> +       if (!dcc_ready(drvdata))
> >> +               dev_err(drvdata->dev, "DCC is not ready Disabling 
> >> DCC...\n");
> > 
> > Is that two sentences? And a debug print?
> 
> Ack.
> 
> > 
> >> +
> >> +       for (curr_list = 0; curr_list < drvdata->nr_link_list; 
> >> curr_list++) {
> >> +               if (!drvdata->enable[curr_list])
> >> +                       continue;
> >> +               dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
> >> +               dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
> >> +               dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
> >> +               dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
> >> +               drvdata->enable[curr_list] = false;
> >> +       }
> >> +       memset_io(drvdata->ram_base, 0, drvdata->ram_size);
> >> +       drvdata->ram_cfg = 0;
> >> +       drvdata->ram_start = 0;
> >> +       mutex_unlock(&drvdata->mutex);
> >> +}
> >> +
> >> +static ssize_t curr_list_show(struct device *dev,
> >> +       struct device_attribute *attr, char *buf)
> >> +{
> >> +       int ret;
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +       if (drvdata->curr_list == DCC_INVALID_LINK_LIST) {
> >> +               dev_err(dev, "curr_list is not set.\n");
> >> +               ret = -EINVAL;
> >> +               goto err;
> >> +       }
> >> +
> >> +       ret = scnprintf(buf, PAGE_SIZE, "%d\n", drvdata->curr_list);
> >> +err:
> >> +       mutex_unlock(&drvdata->mutex);
> >> +       return ret;
> >> +}
> >> +
> >> +static ssize_t curr_list_store(struct device *dev,
> >> +                                               struct 
> >> device_attribute *attr,
> >> +                                               const char *buf, 
> >> size_t size)
> >> +{
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +       unsigned long val;
> >> +       u32 lock_reg;
> >> +       bool dcc_enable = false;
> >> +
> >> +       if (kstrtoul(buf, 16, &val))
> >> +               return -EINVAL;
> >> +
> >> +       if (val >= drvdata->nr_link_list)
> >> +               return -EINVAL;
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +
> >> +       dcc_enable = is_dcc_enabled(drvdata);
> >> +       if (drvdata->curr_list != DCC_INVALID_LINK_LIST && dcc_enable) 
> >> {
> >> +               dev_err(drvdata->dev, "DCC is enabled, please disable 
> >> it first.\n");
> >> +               mutex_unlock(&drvdata->mutex);
> >> +               return -EINVAL;
> >> +       }
> >> +
> >> +       lock_reg = dcc_readl(drvdata, DCC_LL_LOCK(val));
> >> +       if (lock_reg & 0x1) {
> >> +               dev_err(drvdata->dev, "DCC linked list is already 
> >> configured\n");
> >> +               mutex_unlock(&drvdata->mutex);
> >> +               return -EINVAL;
> >> +       }
> >> +       drvdata->curr_list = val;
> >> +       mutex_unlock(&drvdata->mutex);
> >> +
> >> +       return size;
> >> +}
> >> +
> >> +static DEVICE_ATTR_RW(curr_list);
> >> +
> >> +
> >> +static ssize_t trigger_store(struct device *dev,
> >> +                                       struct device_attribute *attr,
> >> +                                       const char *buf, size_t size)
> >> +{
> >> +       int ret = 0;
> >> +       unsigned long val;
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +
> >> +       if (kstrtoul(buf, 16, &val))
> >> +               return -EINVAL;
> >> +       if (val != 1)
> >> +               return -EINVAL;
> >> +
> >> +       ret = dcc_sw_trigger(drvdata);
> >> +       if (!ret)
> >> +               ret = size;
> >> +
> >> +       return ret;
> >> +}
> >> +static DEVICE_ATTR_WO(trigger);
> >> +
> >> +static ssize_t enable_show(struct device *dev,
> >> +       struct device_attribute *attr, char *buf)
> >> +{
> >> +       int ret;
> >> +       bool dcc_enable = false;
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +       if (drvdata->curr_list >= drvdata->nr_link_list) {
> >> +               dev_err(dev, "Select link list to program using 
> >> curr_list\n");
> >> +               ret = -EINVAL;
> >> +               goto err;
> >> +       }
> >> +
> >> +       dcc_enable = is_dcc_enabled(drvdata);
> >> +
> >> +       ret = scnprintf(buf, PAGE_SIZE, "%u\n",
> >> +                               (unsigned int)dcc_enable);
> >> +err:
> >> +       mutex_unlock(&drvdata->mutex);
> > 
> > What does the mutex being held serve here?
> 
> As mentioned earlier, the mutex has been used while accessing 
> dcc_drvdata structure.
> 

And what purpose does it serve? I suppose curr_list can be modified? But
then when this function returns it could be disabled before userspace
sees the value so I'm still lost why we care to hold the lock this long.

> > 
> >> +       return ret;
> >> +}
> >> +
> >> +static ssize_t enable_store(struct device *dev,
> >> +                               struct device_attribute *attr,
> >> +                               const char *buf, size_t size)
> >> +{
> >> +       int ret = 0;
> >> +       unsigned long val;
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +
> >> +       if (kstrtoul(buf, 16, &val))
> >> +               return -EINVAL;
> >> +
> >> +       if (val)
> >> +               ret = dcc_enable(drvdata);
> >> +       else
> >> +               dcc_disable(drvdata);
> >> +
> >> +       if (!ret)
> >> +               ret = size;
> >> +
> >> +       return ret;
> >> +
> >> +}
> >> +
> >> +static DEVICE_ATTR_RW(enable);
> >> +
> >> +static ssize_t config_show(struct device *dev,
> >> +       struct device_attribute *attr, char *buf)
> >> +{
> >> +       struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +       struct dcc_config_entry *entry;
> >> +       char local_buf[64];
> >> +       int len = 0, count = 0;
> >> +
> >> +       buf[0] = '\0';
> > 
> > Why?
> 
> The strlcat function is used here to concatenate the buffer with the 
> config values.
> The strlcat function in C needs a NULL terminated string both as it's 
> source and
> destination. That's why this has been initialized with NULL termination.
> 

sysfs files shall be one value per file, i.e. something that a machine
reads. This function looks like a debugfs function.

> 
> > 
> >> +
> >> +       mutex_lock(&drvdata->mutex);
> >> +       if (drvdata->curr_list >= drvdata->nr_link_list) {
> >> +               dev_err(dev, "Select link list to program using 
> >> curr_list\n");
> >> +               count = -EINVAL;
> >> +               goto err;
> >> +       }
> >> +
> >> +       list_for_each_entry(entry,
> >> +       &drvdata->cfg_head[drvdata->curr_list], list) {
> >> +               switch (entry->desc_type) {
> >> +               case DCC_READ_WRITE_TYPE:
> >> +                       len = snprintf(local_buf, 64, "Index: 0x%x, 
> >> mask: 0x%x, val: 0x%x\n",
> >> +                               entry->index, entry->mask, 
> >> entry->write_val);
> >> +                       break;
> >> +               case DCC_LOOP_TYPE:
> >> +                       len = snprintf(local_buf, 64, "Index: 0x%x, 
> >> Loop: %d\n",
> >> +                               entry->index, entry->loop_cnt);
> >> +                       break;
> >> +               case DCC_WRITE_TYPE:
> >> +                       len = snprintf(local_buf, 64,
> >> +                               "Write Index: 0x%x, Base: 0x%x, 
> >> Offset: 0x%x, len: 0x%x APB: %d\n",
> >> +                               entry->index, entry->base, 
> >> entry->offset, entry->len,
> >> +                               entry->apb_bus);
> >> +                       break;
> >> +               default:
> >> +                       len = snprintf(local_buf, 64,
> >> +                               "Read Index: 0x%x, Base: 0x%x, Offset: 
> >> 0x%x, len: 0x%x APB: %d\n",
> >> +                               entry->index, entry->base, 
> >> entry->offset,
> >> +                               entry->len, entry->apb_bus);
> >> +               }
> >> +
> >> +               if ((count + len) > PAGE_SIZE) {
> >> +                       dev_err(dev, "DCC: Couldn't write complete 
> >> config\n");
> >> +                       break;
> >> +               }
> >> +               strlcat(buf, local_buf, PAGE_SIZE);
> >> +               count += len;
> >> +       }
> >> +
> >> +err:
> >> +       mutex_unlock(&drvdata->mutex);
> >> +       return count;
> >> +}
> > 
> >> +
> >> +       /* EOF check */
> >> +       if (drvdata->ram_size <= *ppos)
> >> +               return 0;
> >> +
> >> +       if ((*ppos + len) > drvdata->ram_size)
> >> +               len = (drvdata->ram_size - *ppos);
> >> +
> >> +       buf = kzalloc(len, GFP_KERNEL);
> >> +       if (!buf)
> >> +               return -ENOMEM;
> >> +
> >> +       memcpy_fromio(buf, drvdata->ram_base + *ppos, len);
> >> +
> >> +       if (copy_to_user(data, buf, len)) {
> > 
> > Is there any sort of memcpy_fromio_to_user() API? That would avoid the
> > extra buffer allocation by copying to userspace in the readl loop.
> 
> No. For directly copying io data to userspace we need to use direct I/O 
> which is used for
> special cases like tape drivers. In this case the complexity of using it 
> outweighs it's
> advantages. Also this is a fixed transfer of data in the form of 
> dcc_sram content rather
> than bulk transfers.

Tape drivers? Huh? Can you please look into adding a
memcpy_fromio_to_user() API that does this without allocating memory for
a buffer?

> 
> > 
> >> +               dcc->loopoff = DCC_FIX_LOOP_OFFSET;
> >> +       else
> >> +               dcc->loopoff = get_bitmask_order((dcc->ram_size +
> >> +                               dcc->ram_offset) / 4 - 1);
> >> +
> >> +       mutex_init(&dcc->mutex);
> >> +       dcc->enable = devm_kcalloc(dev, dcc->nr_link_list,
> >> +                       sizeof(bool), GFP_KERNEL);
> >> +       if (!dcc->enable)
> >> +               return -ENOMEM;
> >> +
> >> +       dcc->configured = devm_kcalloc(dev, dcc->nr_link_list,
> >> +                       sizeof(bool), GFP_KERNEL);
> >> +       if (!dcc->configured)
> >> +               return -ENOMEM;
> >> +
> >> +       dcc->nr_config = devm_kcalloc(dev, dcc->nr_link_list,
> >> +                       sizeof(u32), GFP_KERNEL);
> >> +       if (!dcc->nr_config)
> >> +               return -ENOMEM;
> >> +
> >> +       dcc->cfg_head = devm_kcalloc(dev, dcc->nr_link_list,
> >> +                       sizeof(struct list_head), GFP_KERNEL);
> >> +       if (!dcc->cfg_head)
> >> +               return -ENOMEM;
> > 
> > These are a lot of allocations. Any chance we can do one instead of 
> > this
> > many?
> 
> All these variable have predefined requirement of sizes
> so they need to be allocated separately.

Gather requirements, do some addition, and then allocate one chunk of
memory?


From seanjc at google.com  Fri Apr  2 01:56:48 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:48 -0700
Subject: [PATCH v2 00/10] KVM: Consolidate and optimize MMU notifiers
Message-ID: <20210402005658.3024832-1-seanjc@google.com>

The end goal of this series is to optimize the MMU notifiers to take
mmu_lock if and only if the notification is relevant to KVM, i.e. the hva
range overlaps a memslot.   Large VMs (hundreds of vCPUs) are very
sensitive to mmu_lock being taken for write at inopportune times, and
such VMs also tend to be "static", e.g. backed by HugeTLB with minimal
page shenanigans.  The vast majority of notifications for these VMs will
be spurious (for KVM), and eliding mmu_lock for spurious notifications
avoids an otherwise unacceptable disruption to the guest.

To get there without potentially degrading performance, e.g. due to
multiple memslot lookups, especially on non-x86 where the use cases are
largely unknown (from my perspective), first consolidate the MMU notifier
logic by moving the hva->gfn lookups into common KVM.

Based on kvm/queue, commit 5f986f748438 ("KVM: x86: dump_vmcs should
include the autoload/autostore MSR lists").

Well tested on Intel and AMD.  Compile tested for arm64, MIPS, PPC,
PPC e500, and s390.  Absolutely needs to be tested for real on non-x86,
I give it even odds that I introduced an off-by-one bug somewhere.

v2:
 - Drop the patches that have already been pushed to kvm/queue.
 - Drop two selftest changes that had snuck in via "git commit -a".
 - Add a patch to assert that mmu_notifier_count is elevated when
   .change_pte() runs. [Paolo]
 - Split out moving KVM_MMU_(UN)LOCK() to __kvm_handle_hva_range() to a
   separate patch.  Opted not to squash it with the introduction of the
   common hva walkers (patch 02), as that prevented sharing code between
   the old and new APIs. [Paolo]
 - Tweak the comment in kvm_vm_destroy() above the smashing of the new
   slots lock. [Paolo]
 - Make mmu_notifier_slots_lock unconditional to avoid #ifdefs. [Paolo]

v1:
 - https://lkml.kernel.org/r/20210326021957.1424875-1-seanjc at google.com

Sean Christopherson (10):
  KVM: Assert that notifier count is elevated in .change_pte()
  KVM: Move x86's MMU notifier memslot walkers to generic code
  KVM: arm64: Convert to the gfn-based MMU notifier callbacks
  KVM: MIPS/MMU: Convert to the gfn-based MMU notifier callbacks
  KVM: PPC: Convert to the gfn-based MMU notifier callbacks
  KVM: Kill off the old hva-based MMU notifier callbacks
  KVM: Move MMU notifier's mmu_lock acquisition into common helper
  KVM: Take mmu_lock when handling MMU notifier iff the hva hits a
    memslot
  KVM: Don't take mmu_lock for range invalidation unless necessary
  KVM: x86/mmu: Allow yielding during MMU notifier unmap/zap, if
    possible

 arch/arm64/kvm/mmu.c                   | 117 +++------
 arch/mips/kvm/mmu.c                    |  97 ++------
 arch/powerpc/include/asm/kvm_book3s.h  |  12 +-
 arch/powerpc/include/asm/kvm_ppc.h     |   9 +-
 arch/powerpc/kvm/book3s.c              |  18 +-
 arch/powerpc/kvm/book3s.h              |  10 +-
 arch/powerpc/kvm/book3s_64_mmu_hv.c    |  98 ++------
 arch/powerpc/kvm/book3s_64_mmu_radix.c |  25 +-
 arch/powerpc/kvm/book3s_hv.c           |  12 +-
 arch/powerpc/kvm/book3s_pr.c           |  56 ++---
 arch/powerpc/kvm/e500_mmu_host.c       |  27 +-
 arch/x86/kvm/mmu/mmu.c                 | 127 ++++------
 arch/x86/kvm/mmu/tdp_mmu.c             | 245 +++++++------------
 arch/x86/kvm/mmu/tdp_mmu.h             |  14 +-
 include/linux/kvm_host.h               |  22 +-
 virt/kvm/kvm_main.c                    | 325 +++++++++++++++++++------
 16 files changed, 552 insertions(+), 662 deletions(-)

-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:49 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:49 -0700
Subject: [PATCH v2 01/10] KVM: Assert that notifier count is elevated in
 .change_pte()
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-2-seanjc@google.com>

In KVM's .change_pte() notification callback, replace the notifier
sequence bump with a WARN_ON assertion that the notifier count is
elevated.  An elevated count provides stricter protections than bumping
the sequence, and the sequence is guarnateed to be bumped before the
count hits zero.

When .change_pte() was added by commit 828502d30073 ("ksm: add
mmu_notifier set_pte_at_notify()"), bumping the sequence was necessary
as .change_pte() would be invoked without any surrounding notifications.

However, since commit 6bdb913f0a70 ("mm: wrap calls to set_pte_at_notify
with invalidate_range_start and invalidate_range_end"), all calls to
.change_pte() are guaranteed to be bookended by start() and end(), and
so are guaranteed to run with an elevated notifier count.

Note, wrapping .change_pte() with .invalidate_range_{start,end}() is a
bug of sorts, as invalidating the secondary MMU's (KVM's) PTE defeats
the purpose of .change_pte().  Every arch's kvm_set_spte_hva() assumes
.change_pte() is called when the relevant SPTE is present in KVM's MMU,
as the original goal was to accelerate Kernel Samepage Merging (KSM) by
updating KVM's SPTEs without requiring a VM-Exit (due to invalidating
the SPTE).  I.e. it means that .change_pte() is effectively dead code
on _all_ architectures.

x86 and MIPS are clearcut nops if the old SPTE is not-present, and that
is guaranteed due to the prior invalidation.  PPC simply unmaps the SPTE,
which again should be a nop due to the invalidation.  arm64 is a bit
murky, but it's also likely a nop because kvm_pgtable_stage2_map() is
called without a cache pointer, which means it will map an entry if and
only if an existing PTE was found.

For now, take advantage of the bug to simplify future consolidation of
KVMs's MMU notifier code.   Doing so will not greatly complicate fixing
.change_pte(), assuming it's even worth fixing.  .change_pte() has been
broken for 8+ years and no one has complained.  Even if there are
KSM+KVM users that care deeply about its performance, the benefits of
avoiding VM-Exits via .change_pte() need to be reevaluated to justify
the added complexity and testing burden.  Ripping out .change_pte()
entirely would be a lot easier.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 virt/kvm/kvm_main.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d1de843b7618..8df091950161 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -461,12 +461,17 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 
 	trace_kvm_set_spte_hva(address);
 
+	/*
+	 * .change_pte() must be bookended by .invalidate_range_{start,end}(),
+	 * and so always runs with an elevated notifier count.  This obviates
+	 * the need to bump the sequence count.
+	 */
+	WARN_ON_ONCE(!kvm->mmu_notifier_count);
+
 	idx = srcu_read_lock(&kvm->srcu);
 
 	KVM_MMU_LOCK(kvm);
 
-	kvm->mmu_notifier_seq++;
-
 	if (kvm_set_spte_hva(kvm, address, pte))
 		kvm_flush_remote_tlbs(kvm);
 
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:50 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:50 -0700
Subject: [PATCH v2 02/10] KVM: Move x86's MMU notifier memslot walkers to
 generic code
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-3-seanjc@google.com>

Move the hva->gfn lookup for MMU notifiers into common code.  Every arch
does a similar lookup, and some arch code is all but identical across
multiple architectures.

In addition to consolidating code, this will allow introducing
optimizations that will benefit all architectures without incurring
multiple walks of the memslots, e.g. by taking mmu_lock if and only if a
relevant range exists in the memslots.

The use of __always_inline to avoid indirect call retpolines, as done by
x86, may also benefit other architectures.

Consolidating the lookups also fixes a wart in x86, where the legacy MMU
and TDP MMU each do their own memslot walks.

Lastly, future enhancements to the memslot implementation, e.g. to add an
interval tree to track host address, will need to touch far less arch
specific code.

MIPS, PPC, and arm64 will be converted one at a time in future patches.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/x86/include/asm/kvm_host.h |   1 +
 arch/x86/kvm/mmu/mmu.c          | 127 +++++++----------
 arch/x86/kvm/mmu/tdp_mmu.c      | 241 ++++++++++++--------------------
 arch/x86/kvm/mmu/tdp_mmu.h      |  14 +-
 include/linux/kvm_host.h        |  14 ++
 virt/kvm/kvm_main.c             | 169 +++++++++++++++++++++-
 6 files changed, 317 insertions(+), 249 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 99778ac51243..a21e3698f4dc 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1718,6 +1718,7 @@ asmlinkage void kvm_spurious_fault(void);
 	_ASM_EXTABLE(666b, 667b)
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
+#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
 int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index efb41f31e80a..f2046c41eb93 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1298,26 +1298,25 @@ static bool kvm_zap_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
 	return flush;
 }
 
-static int kvm_unmap_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
-			   struct kvm_memory_slot *slot, gfn_t gfn, int level,
-			   unsigned long data)
+static bool kvm_unmap_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+			    struct kvm_memory_slot *slot, gfn_t gfn, int level,
+			    pte_t unused)
 {
 	return kvm_zap_rmapp(kvm, rmap_head, slot);
 }
 
-static int kvm_set_pte_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
-			     struct kvm_memory_slot *slot, gfn_t gfn, int level,
-			     unsigned long data)
+static bool kvm_set_pte_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+			      struct kvm_memory_slot *slot, gfn_t gfn, int level,
+			      pte_t pte)
 {
 	u64 *sptep;
 	struct rmap_iterator iter;
 	int need_flush = 0;
 	u64 new_spte;
-	pte_t *ptep = (pte_t *)data;
 	kvm_pfn_t new_pfn;
 
-	WARN_ON(pte_huge(*ptep));
-	new_pfn = pte_pfn(*ptep);
+	WARN_ON(pte_huge(pte));
+	new_pfn = pte_pfn(pte);
 
 restart:
 	for_each_rmap_spte(rmap_head, &iter, sptep) {
@@ -1326,7 +1325,7 @@ static int kvm_set_pte_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
 
 		need_flush = 1;
 
-		if (pte_write(*ptep)) {
+		if (pte_write(pte)) {
 			pte_list_remove(rmap_head, sptep);
 			goto restart;
 		} else {
@@ -1414,86 +1413,52 @@ static void slot_rmap_walk_next(struct slot_rmap_walk_iterator *iterator)
 	     slot_rmap_walk_okay(_iter_);				\
 	     slot_rmap_walk_next(_iter_))
 
-typedef int (*rmap_handler_t)(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
-			      struct kvm_memory_slot *slot, gfn_t gfn,
-			      int level, unsigned long data);
+typedef bool (*rmap_handler_t)(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+			       struct kvm_memory_slot *slot, gfn_t gfn,
+			       int level, pte_t pte);
 
-static __always_inline int kvm_handle_hva_range(struct kvm *kvm,
-						unsigned long start,
-						unsigned long end,
-						unsigned long data,
-						rmap_handler_t handler)
+static __always_inline bool kvm_handle_gfn_range(struct kvm *kvm,
+						 struct kvm_gfn_range *range,
+						 rmap_handler_t handler)
 {
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
 	struct slot_rmap_walk_iterator iterator;
-	int ret = 0;
-	int i;
+	bool ret = false;
 
-	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
-		slots = __kvm_memslots(kvm, i);
-		kvm_for_each_memslot(memslot, slots) {
-			unsigned long hva_start, hva_end;
-			gfn_t gfn_start, gfn_end;
-
-			hva_start = max(start, memslot->userspace_addr);
-			hva_end = min(end, memslot->userspace_addr +
-				      (memslot->npages << PAGE_SHIFT));
-			if (hva_start >= hva_end)
-				continue;
-			/*
-			 * {gfn(page) | page intersects with [hva_start, hva_end)} =
-			 * {gfn_start, gfn_start+1, ..., gfn_end-1}.
-			 */
-			gfn_start = hva_to_gfn_memslot(hva_start, memslot);
-			gfn_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot);
-
-			for_each_slot_rmap_range(memslot, PG_LEVEL_4K,
-						 KVM_MAX_HUGEPAGE_LEVEL,
-						 gfn_start, gfn_end - 1,
-						 &iterator)
-				ret |= handler(kvm, iterator.rmap, memslot,
-					       iterator.gfn, iterator.level, data);
-		}
-	}
+	for_each_slot_rmap_range(range->slot, PG_LEVEL_4K, KVM_MAX_HUGEPAGE_LEVEL,
+				 range->start, range->end - 1, &iterator)
+		ret |= handler(kvm, iterator.rmap, range->slot, iterator.gfn,
+			       iterator.level, range->pte);
 
 	return ret;
 }
 
-static int kvm_handle_hva(struct kvm *kvm, unsigned long hva,
-			  unsigned long data, rmap_handler_t handler)
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm_handle_hva_range(kvm, hva, hva + 1, data, handler);
-}
-
-int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end,
-			unsigned flags)
-{
-	int r;
+	bool flush;
 
-	r = kvm_handle_hva_range(kvm, start, end, 0, kvm_unmap_rmapp);
+	flush = kvm_handle_gfn_range(kvm, range, kvm_unmap_rmapp);
 
 	if (is_tdp_mmu_enabled(kvm))
-		r |= kvm_tdp_mmu_zap_hva_range(kvm, start, end);
+		flush |= kvm_tdp_mmu_unmap_gfn_range(kvm, range, flush);
 
-	return r;
+	return flush;
 }
 
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	int r;
+	bool flush;
 
-	r = kvm_handle_hva(kvm, hva, (unsigned long)&pte, kvm_set_pte_rmapp);
+	flush = kvm_handle_gfn_range(kvm, range, kvm_set_pte_rmapp);
 
 	if (is_tdp_mmu_enabled(kvm))
-		r |= kvm_tdp_mmu_set_spte_hva(kvm, hva, &pte);
+		flush |= kvm_tdp_mmu_set_spte_gfn(kvm, range);
 
-	return r;
+	return flush;
 }
 
-static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
-			 struct kvm_memory_slot *slot, gfn_t gfn, int level,
-			 unsigned long data)
+static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+			  struct kvm_memory_slot *slot, gfn_t gfn, int level,
+			  pte_t unused)
 {
 	u64 *sptep;
 	struct rmap_iterator iter;
@@ -1505,9 +1470,9 @@ static int kvm_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
 	return young;
 }
 
-static int kvm_test_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
-			      struct kvm_memory_slot *slot, gfn_t gfn,
-			      int level, unsigned long data)
+static bool kvm_test_age_rmapp(struct kvm *kvm, struct kvm_rmap_head *rmap_head,
+			       struct kvm_memory_slot *slot, gfn_t gfn,
+			       int level, pte_t unused)
 {
 	u64 *sptep;
 	struct rmap_iterator iter;
@@ -1529,29 +1494,31 @@ static void rmap_recycle(struct kvm_vcpu *vcpu, u64 *spte, gfn_t gfn)
 
 	rmap_head = gfn_to_rmap(vcpu->kvm, gfn, sp);
 
-	kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, 0);
+	kvm_unmap_rmapp(vcpu->kvm, rmap_head, NULL, gfn, sp->role.level, __pte(0));
 	kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn,
 			KVM_PAGES_PER_HPAGE(sp->role.level));
 }
 
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	int young = false;
+	bool young;
+
+	young = kvm_handle_gfn_range(kvm, range, kvm_age_rmapp);
 
-	young = kvm_handle_hva_range(kvm, start, end, 0, kvm_age_rmapp);
 	if (is_tdp_mmu_enabled(kvm))
-		young |= kvm_tdp_mmu_age_hva_range(kvm, start, end);
+		young |= kvm_tdp_mmu_age_gfn_range(kvm, range);
 
 	return young;
 }
 
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	int young = false;
+	bool young;
+
+	young = kvm_handle_gfn_range(kvm, range, kvm_test_age_rmapp);
 
-	young = kvm_handle_hva(kvm, hva, 0, kvm_test_age_rmapp);
 	if (is_tdp_mmu_enabled(kvm))
-		young |= kvm_tdp_mmu_test_age_hva(kvm, hva);
+		young |= kvm_tdp_mmu_test_age_gfn(kvm, range);
 
 	return young;
 }
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index eeb644d2eb6f..7797d24f0937 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -878,142 +878,118 @@ int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
 	return ret;
 }
 
-typedef int (*tdp_handler_t)(struct kvm *kvm, struct kvm_memory_slot *slot,
-			     struct kvm_mmu_page *root, gfn_t start, gfn_t end,
-			     unsigned long data);
-
-static __always_inline int kvm_tdp_mmu_handle_hva_range(struct kvm *kvm,
-							unsigned long start,
-							unsigned long end,
-							unsigned long data,
-							tdp_handler_t handler)
+bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,
+				 bool flush)
 {
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
 	struct kvm_mmu_page *root;
-	int ret = 0;
-	int as_id;
 
-	for (as_id = 0; as_id < KVM_ADDRESS_SPACE_NUM; as_id++) {
-		for_each_tdp_mmu_root_yield_safe(kvm, root, as_id) {
-			slots = __kvm_memslots(kvm, as_id);
-			kvm_for_each_memslot(memslot, slots) {
-				unsigned long hva_start, hva_end;
-				gfn_t gfn_start, gfn_end;
+	for_each_tdp_mmu_root(kvm, root, range->slot->as_id)
+		flush |= zap_gfn_range(kvm, root, range->start, range->end,
+				       false, flush);
+
+	return flush;
+}
+
+typedef bool (*tdp_handler_t)(struct kvm *kvm, struct tdp_iter *iter,
+			      struct kvm_gfn_range *range);
+
+static __always_inline bool kvm_tdp_mmu_handle_gfn(struct kvm *kvm,
+						   struct kvm_gfn_range *range,
+						   tdp_handler_t handler)
+{
+	struct kvm_mmu_page *root;
+	struct tdp_iter iter;
+	bool ret = false;
 
-				hva_start = max(start, memslot->userspace_addr);
-				hva_end = min(end, memslot->userspace_addr +
-					(memslot->npages << PAGE_SHIFT));
-				if (hva_start >= hva_end)
-					continue;
-				/*
-				 * {gfn(page) | page intersects with [hva_start, hva_end)} =
-				 * {gfn_start, gfn_start+1, ..., gfn_end-1}.
-				 */
-				gfn_start = hva_to_gfn_memslot(hva_start, memslot);
-				gfn_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot);
+	rcu_read_lock();
 
-				ret |= handler(kvm, memslot, root, gfn_start,
-					gfn_end, data);
-			}
-		}
+	for_each_tdp_mmu_root(kvm, root, range->slot->as_id) {
+		tdp_root_for_each_leaf_pte(iter, root, range->start, range->end)
+			ret |= handler(kvm, &iter, range);
 	}
 
+	rcu_read_unlock();
+
 	return ret;
 }
 
-static __always_inline int kvm_tdp_mmu_handle_hva(struct kvm *kvm,
-						  unsigned long addr,
-						  unsigned long data,
-						  tdp_handler_t handler)
-{
-	return kvm_tdp_mmu_handle_hva_range(kvm, addr, addr + 1, data, handler);
-}
-
-static int zap_gfn_range_hva_wrapper(struct kvm *kvm,
-				     struct kvm_memory_slot *slot,
-				     struct kvm_mmu_page *root, gfn_t start,
-				     gfn_t end, unsigned long unused)
-{
-	return zap_gfn_range(kvm, root, start, end, false, false);
-}
-
-int kvm_tdp_mmu_zap_hva_range(struct kvm *kvm, unsigned long start,
-			      unsigned long end)
-{
-	return kvm_tdp_mmu_handle_hva_range(kvm, start, end, 0,
-					    zap_gfn_range_hva_wrapper);
-}
-
 /*
  * Mark the SPTEs range of GFNs [start, end) unaccessed and return non-zero
  * if any of the GFNs in the range have been accessed.
  */
-static int age_gfn_range(struct kvm *kvm, struct kvm_memory_slot *slot,
-			 struct kvm_mmu_page *root, gfn_t start, gfn_t end,
-			 unsigned long unused)
+static bool age_gfn_range(struct kvm *kvm, struct tdp_iter *iter,
+			  struct kvm_gfn_range *range)
 {
-	struct tdp_iter iter;
-	int young = 0;
-	u64 new_spte;
+	u64 new_spte = 0;
 
-	rcu_read_lock();
+	/* If we have a non-accessed entry we don't need to change the pte. */
+	if (!is_accessed_spte(iter->old_spte))
+		return false;
 
-	tdp_root_for_each_leaf_pte(iter, root, start, end) {
+	new_spte = iter->old_spte;
+
+	if (spte_ad_enabled(new_spte)) {
+		new_spte &= ~shadow_accessed_mask;
+	} else {
 		/*
-		 * If we have a non-accessed entry we don't need to change the
-		 * pte.
+		 * Capture the dirty status of the page, so that it doesn't get
+		 * lost when the SPTE is marked for access tracking.
 		 */
-		if (!is_accessed_spte(iter.old_spte))
-			continue;
-
-		new_spte = iter.old_spte;
-
-		if (spte_ad_enabled(new_spte)) {
-			new_spte &= ~shadow_accessed_mask;
-		} else {
-			/*
-			 * Capture the dirty status of the page, so that it doesn't get
-			 * lost when the SPTE is marked for access tracking.
-			 */
-			if (is_writable_pte(new_spte))
-				kvm_set_pfn_dirty(spte_to_pfn(new_spte));
-
-			new_spte = mark_spte_for_access_track(new_spte);
-		}
-
-		tdp_mmu_set_spte_no_acc_track(kvm, &iter, new_spte);
-		young = 1;
+		if (is_writable_pte(new_spte))
+			kvm_set_pfn_dirty(spte_to_pfn(new_spte));
+
+		new_spte = mark_spte_for_access_track(new_spte);
 	}
 
-	rcu_read_unlock();
+	tdp_mmu_set_spte_no_acc_track(kvm, iter, new_spte);
 
-	return young;
+	return true;
 }
 
-int kvm_tdp_mmu_age_hva_range(struct kvm *kvm, unsigned long start,
-			      unsigned long end)
+bool kvm_tdp_mmu_age_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm_tdp_mmu_handle_hva_range(kvm, start, end, 0,
-					    age_gfn_range);
+	return kvm_tdp_mmu_handle_gfn(kvm, range, age_gfn_range);
 }
 
-static int test_age_gfn(struct kvm *kvm, struct kvm_memory_slot *slot,
-			struct kvm_mmu_page *root, gfn_t gfn, gfn_t end,
-			unsigned long unused)
+static bool test_age_gfn(struct kvm *kvm, struct tdp_iter *iter,
+			 struct kvm_gfn_range *range)
 {
-	struct tdp_iter iter;
-
-	tdp_root_for_each_leaf_pte(iter, root, gfn, end)
-		if (is_accessed_spte(iter.old_spte))
-			return 1;
+	return is_accessed_spte(iter->old_spte);
+}
 
-	return 0;
+bool kvm_tdp_mmu_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
+{
+	return kvm_tdp_mmu_handle_gfn(kvm, range, test_age_gfn);
 }
 
-int kvm_tdp_mmu_test_age_hva(struct kvm *kvm, unsigned long hva)
+static bool set_spte_gfn(struct kvm *kvm, struct tdp_iter *iter,
+			 struct kvm_gfn_range *range)
 {
-	return kvm_tdp_mmu_handle_hva(kvm, hva, 0, test_age_gfn);
+	u64 new_spte;
+
+	/* Huge pages aren't expected to be modified without first being zapped. */
+	WARN_ON(pte_huge(range->pte) || range->start + 1 != range->end);
+
+	if (iter->level != PG_LEVEL_4K ||
+	    !is_shadow_present_pte(iter->old_spte))
+		return false;
+
+	/*
+	 * Note, when changing a read-only SPTE, it's not strictly necessary to
+	 * zero the SPTE before setting the new PFN, but doing so preserves the
+	 * invariant that the PFN of a present * leaf SPTE can never change.
+	 * See __handle_changed_spte().
+	 */
+	tdp_mmu_set_spte(kvm, iter, 0);
+
+	if (!pte_write(range->pte)) {
+		new_spte = kvm_mmu_changed_pte_notifier_make_spte(iter->old_spte,
+								  pte_pfn(range->pte));
+
+		tdp_mmu_set_spte(kvm, iter, new_spte);
+	}
+
+	return true;
 }
 
 /*
@@ -1022,60 +998,15 @@ int kvm_tdp_mmu_test_age_hva(struct kvm *kvm, unsigned long hva)
  * notifier.
  * Returns non-zero if a flush is needed before releasing the MMU lock.
  */
-static int set_tdp_spte(struct kvm *kvm, struct kvm_memory_slot *slot,
-			struct kvm_mmu_page *root, gfn_t gfn, gfn_t end,
-			unsigned long data)
+bool kvm_tdp_mmu_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	struct tdp_iter iter;
-	pte_t *ptep = (pte_t *)data;
-	kvm_pfn_t new_pfn;
-	u64 new_spte;
-	int need_flush = 0;
+	bool flush = kvm_tdp_mmu_handle_gfn(kvm, range, set_spte_gfn);
 
-	rcu_read_lock();
+	/* FIXME: return 'flush' instead of flushing here. */
+	if (flush)
+		kvm_flush_remote_tlbs_with_address(kvm, range->start, 1);
 
-	WARN_ON(pte_huge(*ptep) || (gfn + 1) != end);
-
-	new_pfn = pte_pfn(*ptep);
-
-	tdp_root_for_each_leaf_pte(iter, root, gfn, gfn + 1) {
-		if (iter.level != PG_LEVEL_4K)
-			continue;
-
-		if (!is_shadow_present_pte(iter.old_spte))
-			break;
-
-		/*
-		 * Note, when changing a read-only SPTE, it's not strictly
-		 * necessary to zero the SPTE before setting the new PFN, but
-		 * doing so preserves the invariant that the PFN of a present
-		 * leaf SPTE can never change.  See __handle_changed_spte().
-		 */
-		tdp_mmu_set_spte(kvm, &iter, 0);
-
-		if (!pte_write(*ptep)) {
-			new_spte = kvm_mmu_changed_pte_notifier_make_spte(
-					iter.old_spte, new_pfn);
-
-			tdp_mmu_set_spte(kvm, &iter, new_spte);
-		}
-
-		need_flush = 1;
-	}
-
-	if (need_flush)
-		kvm_flush_remote_tlbs_with_address(kvm, gfn, 1);
-
-	rcu_read_unlock();
-
-	return 0;
-}
-
-int kvm_tdp_mmu_set_spte_hva(struct kvm *kvm, unsigned long address,
-			     pte_t *host_ptep)
-{
-	return kvm_tdp_mmu_handle_hva(kvm, address, (unsigned long)host_ptep,
-				      set_tdp_spte);
+	return false;
 }
 
 /*
diff --git a/arch/x86/kvm/mmu/tdp_mmu.h b/arch/x86/kvm/mmu/tdp_mmu.h
index bf3ce169122e..ee8efa58902f 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.h
+++ b/arch/x86/kvm/mmu/tdp_mmu.h
@@ -38,15 +38,11 @@ int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
 		    int map_writable, int max_level, kvm_pfn_t pfn,
 		    bool prefault);
 
-int kvm_tdp_mmu_zap_hva_range(struct kvm *kvm, unsigned long start,
-			      unsigned long end);
-
-int kvm_tdp_mmu_age_hva_range(struct kvm *kvm, unsigned long start,
-			      unsigned long end);
-int kvm_tdp_mmu_test_age_hva(struct kvm *kvm, unsigned long hva);
-
-int kvm_tdp_mmu_set_spte_hva(struct kvm *kvm, unsigned long address,
-			     pte_t *host_ptep);
+bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,
+				 bool flush);
+bool kvm_tdp_mmu_age_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
+bool kvm_tdp_mmu_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
+bool kvm_tdp_mmu_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
 
 bool kvm_tdp_mmu_wrprot_slot(struct kvm *kvm, struct kvm_memory_slot *slot,
 			     int min_level);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index e6d77353025c..e6bb401dd856 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -219,11 +219,25 @@ int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
 #endif
 
 #ifdef KVM_ARCH_WANT_MMU_NOTIFIER
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+struct kvm_gfn_range {
+	struct kvm_memory_slot *slot;
+	gfn_t start;
+	gfn_t end;
+	pte_t pte;
+	bool may_block;
+};
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
+#else
 int kvm_unmap_hva_range(struct kvm *kvm,
 			unsigned long start, unsigned long end, unsigned flags);
 int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
 int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
+#endif /* KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS */
 #endif
 
 enum {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8df091950161..7a7e62ae5eb4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -451,14 +451,131 @@ static void kvm_mmu_notifier_invalidate_range(struct mmu_notifier *mn,
 	srcu_read_unlock(&kvm->srcu, idx);
 }
 
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+
+typedef bool (*hva_handler_t)(struct kvm *kvm, struct kvm_gfn_range *range);
+
+struct kvm_hva_range {
+	unsigned long start;
+	unsigned long end;
+	pte_t pte;
+	hva_handler_t handler;
+	bool flush_on_ret;
+	bool may_block;
+};
+
+static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
+						  const struct kvm_hva_range *range)
+{
+	struct kvm_memory_slot *slot;
+	struct kvm_memslots *slots;
+	struct kvm_gfn_range gfn_range;
+	bool ret = false;
+	int i, idx;
+
+	lockdep_assert_held_write(&kvm->mmu_lock);
+
+	idx = srcu_read_lock(&kvm->srcu);
+
+	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
+		slots = __kvm_memslots(kvm, i);
+		kvm_for_each_memslot(slot, slots) {
+			unsigned long hva_start, hva_end;
+
+			hva_start = max(range->start, slot->userspace_addr);
+			hva_end = min(range->end, slot->userspace_addr +
+						  (slot->npages << PAGE_SHIFT));
+			if (hva_start >= hva_end)
+				continue;
+
+			/*
+			 * To optimize for the likely case where the address
+			 * range is covered by zero or one memslots, don't
+			 * bother making these conditional (to avoid writes on
+			 * the second or later invocation of the handler).
+			 */
+			gfn_range.pte = range->pte;
+			gfn_range.may_block = range->may_block;
+
+			/*
+			 * {gfn(page) | page intersects with [hva_start, hva_end)} =
+			 * {gfn_start, gfn_start+1, ..., gfn_end-1}.
+			 */
+			gfn_range.start = hva_to_gfn_memslot(hva_start, slot);
+			gfn_range.end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, slot);
+			gfn_range.slot = slot;
+
+			ret |= range->handler(kvm, &gfn_range);
+		}
+	}
+
+	if (range->flush_on_ret && (ret || kvm->tlbs_dirty))
+		kvm_flush_remote_tlbs(kvm);
+
+	srcu_read_unlock(&kvm->srcu, idx);
+
+	/* The notifiers are averse to booleans. :-( */
+	return (int)ret;
+}
+
+static __always_inline int kvm_handle_hva_range(struct mmu_notifier *mn,
+						unsigned long start,
+						unsigned long end,
+						pte_t pte,
+						hva_handler_t handler)
+{
+	struct kvm *kvm = mmu_notifier_to_kvm(mn);
+	const struct kvm_hva_range range = {
+		.start		= start,
+		.end		= end,
+		.pte		= pte,
+		.handler	= handler,
+		.flush_on_ret	= true,
+		.may_block	= false,
+	};
+	int ret;
+
+	KVM_MMU_LOCK(kvm);
+	ret = __kvm_handle_hva_range(kvm, &range);
+	KVM_MMU_UNLOCK(kvm);
+
+	return ret;
+}
+
+static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn,
+							 unsigned long start,
+							 unsigned long end,
+							 hva_handler_t handler)
+{
+	struct kvm *kvm = mmu_notifier_to_kvm(mn);
+	const struct kvm_hva_range range = {
+		.start		= start,
+		.end		= end,
+		.pte		= __pte(0),
+		.handler	= handler,
+		.flush_on_ret	= false,
+		.may_block	= false,
+	};
+	int ret;
+
+	KVM_MMU_LOCK(kvm);
+	ret = __kvm_handle_hva_range(kvm, &range);
+	KVM_MMU_UNLOCK(kvm);
+
+	return ret;
+}
+#endif /* KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS */
+
 static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 					struct mm_struct *mm,
 					unsigned long address,
 					pte_t pte)
 {
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-	int idx;
 
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	int idx;
+#endif
 	trace_kvm_set_spte_hva(address);
 
 	/*
@@ -468,6 +585,9 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 	 */
 	WARN_ON_ONCE(!kvm->mmu_notifier_count);
 
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	kvm_handle_hva_range(mn, address, address + 1, pte, kvm_set_spte_gfn);
+#else
 	idx = srcu_read_lock(&kvm->srcu);
 
 	KVM_MMU_LOCK(kvm);
@@ -477,17 +597,32 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 
 	KVM_MMU_UNLOCK(kvm);
 	srcu_read_unlock(&kvm->srcu, idx);
+#endif
 }
 
 static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 					const struct mmu_notifier_range *range)
 {
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	const struct kvm_hva_range hva_range = {
+		.start		= range->start,
+		.end		= range->end,
+		.pte		= __pte(0),
+		.handler	= kvm_unmap_gfn_range,
+		.flush_on_ret	= true,
+		.may_block	= mmu_notifier_range_blockable(range),
+	};
+#else
 	int need_tlb_flush = 0, idx;
+#endif
 
 	trace_kvm_unmap_hva_range(range->start, range->end);
 
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	idx = srcu_read_lock(&kvm->srcu);
+#endif
+
 	KVM_MMU_LOCK(kvm);
 	/*
 	 * The count increase must become visible at unlock time as no
@@ -513,14 +648,21 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 		kvm->mmu_notifier_range_end =
 			max(kvm->mmu_notifier_range_end, range->end);
 	}
+
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	__kvm_handle_hva_range(kvm, &hva_range);
+#else
 	need_tlb_flush = kvm_unmap_hva_range(kvm, range->start, range->end,
 					     range->flags);
 	/* we've to flush the tlb before the pages can be freed */
 	if (need_tlb_flush || kvm->tlbs_dirty)
 		kvm_flush_remote_tlbs(kvm);
+#endif
 
 	KVM_MMU_UNLOCK(kvm);
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	srcu_read_unlock(&kvm->srcu, idx);
+#endif
 
 	return 0;
 }
@@ -554,11 +696,15 @@ static int kvm_mmu_notifier_clear_flush_young(struct mmu_notifier *mn,
 					      unsigned long start,
 					      unsigned long end)
 {
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 	int young, idx;
-
+#endif
 	trace_kvm_age_hva(start, end);
 
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	return kvm_handle_hva_range(mn, start, end, __pte(0), kvm_age_gfn);
+#else
 	idx = srcu_read_lock(&kvm->srcu);
 	KVM_MMU_LOCK(kvm);
 
@@ -570,6 +716,7 @@ static int kvm_mmu_notifier_clear_flush_young(struct mmu_notifier *mn,
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	return young;
+#endif
 }
 
 static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
@@ -577,13 +724,13 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
 					unsigned long start,
 					unsigned long end)
 {
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 	int young, idx;
+#endif
 
 	trace_kvm_age_hva(start, end);
 
-	idx = srcu_read_lock(&kvm->srcu);
-	KVM_MMU_LOCK(kvm);
 	/*
 	 * Even though we do not flush TLB, this will still adversely
 	 * affect performance on pre-Haswell Intel EPT, where there is
@@ -597,22 +744,33 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
 	 * cadence. If we find this inaccurate, we might come up with a
 	 * more sophisticated heuristic later.
 	 */
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	return kvm_handle_hva_range_no_flush(mn, start, end, kvm_age_gfn);
+#else
+	idx = srcu_read_lock(&kvm->srcu);
+	KVM_MMU_LOCK(kvm);
 	young = kvm_age_hva(kvm, start, end);
 	KVM_MMU_UNLOCK(kvm);
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	return young;
+#endif
 }
 
 static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn,
 				       struct mm_struct *mm,
 				       unsigned long address)
 {
+#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 	int young, idx;
-
+#endif
 	trace_kvm_test_age_hva(address);
 
+#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
+	return kvm_handle_hva_range_no_flush(mn, address, address + 1,
+					     kvm_test_age_gfn);
+#else
 	idx = srcu_read_lock(&kvm->srcu);
 	KVM_MMU_LOCK(kvm);
 	young = kvm_test_age_hva(kvm, address);
@@ -620,6 +778,7 @@ static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn,
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	return young;
+#endif
 }
 
 static void kvm_mmu_notifier_release(struct mmu_notifier *mn,
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:51 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:51 -0700
Subject: [PATCH v2 03/10] KVM: arm64: Convert to the gfn-based MMU notifier
 callbacks
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-4-seanjc@google.com>

Move arm64 to the gfn-base MMU notifier APIs, which do the hva->gfn
lookup in common code.

No meaningful functional change intended, though the exact order of
operations is slightly different since the memslot lookups occur before
calling into arch code.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/arm64/include/asm/kvm_host.h |   1 +
 arch/arm64/kvm/mmu.c              | 117 ++++++++----------------------
 2 files changed, 33 insertions(+), 85 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 72e6b4600264..1ad729cf7b0d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -582,6 +582,7 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
 			      struct kvm_vcpu_events *events);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
+#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 void kvm_arm_halt_guest(struct kvm *kvm);
 void kvm_arm_resume_guest(struct kvm *kvm);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 4b7e1e327337..35728231e9a0 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -839,7 +839,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	 * gfn_to_pfn_prot (which calls get_user_pages), so that we don't risk
 	 * the page we just got a reference to gets unmapped before we have a
 	 * chance to grab the mmu_lock, which ensure that if the page gets
-	 * unmapped afterwards, the call to kvm_unmap_hva will take it away
+	 * unmapped afterwards, the call to kvm_unmap_gfn will take it away
 	 * from us again properly. This smp_rmb() interacts with the smp_wmb()
 	 * in kvm_mmu_notifier_invalidate_<page|range_end>.
 	 */
@@ -1064,123 +1064,70 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static int handle_hva_to_gpa(struct kvm *kvm,
-			     unsigned long start,
-			     unsigned long end,
-			     int (*handler)(struct kvm *kvm,
-					    gpa_t gpa, u64 size,
-					    void *data),
-			     void *data)
-{
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
-	int ret = 0;
-
-	slots = kvm_memslots(kvm);
-
-	/* we only care about the pages that the guest sees */
-	kvm_for_each_memslot(memslot, slots) {
-		unsigned long hva_start, hva_end;
-		gfn_t gpa;
-
-		hva_start = max(start, memslot->userspace_addr);
-		hva_end = min(end, memslot->userspace_addr +
-					(memslot->npages << PAGE_SHIFT));
-		if (hva_start >= hva_end)
-			continue;
-
-		gpa = hva_to_gfn_memslot(hva_start, memslot) << PAGE_SHIFT;
-		ret |= handler(kvm, gpa, (u64)(hva_end - hva_start), data);
-	}
-
-	return ret;
-}
-
-static int kvm_unmap_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
-{
-	unsigned flags = *(unsigned *)data;
-	bool may_block = flags & MMU_NOTIFIER_RANGE_BLOCKABLE;
-
-	__unmap_stage2_range(&kvm->arch.mmu, gpa, size, may_block);
-	return 0;
-}
-
-int kvm_unmap_hva_range(struct kvm *kvm,
-			unsigned long start, unsigned long end, unsigned flags)
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	if (!kvm->arch.mmu.pgt)
 		return 0;
 
-	handle_hva_to_gpa(kvm, start, end, &kvm_unmap_hva_handler, &flags);
-	return 0;
-}
+	__unmap_stage2_range(&kvm->arch.mmu, range->start << PAGE_SHIFT,
+			     (range->end - range->start) << PAGE_SHIFT,
+			     range->may_block);
 
-static int kvm_set_spte_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
-{
-	kvm_pfn_t *pfn = (kvm_pfn_t *)data;
-
-	WARN_ON(size != PAGE_SIZE);
-
-	/*
-	 * The MMU notifiers will have unmapped a huge PMD before calling
-	 * ->change_pte() (which in turn calls kvm_set_spte_hva()) and
-	 * therefore we never need to clear out a huge PMD through this
-	 * calling path and a memcache is not required.
-	 */
-	kvm_pgtable_stage2_map(kvm->arch.mmu.pgt, gpa, PAGE_SIZE,
-			       __pfn_to_phys(*pfn), KVM_PGTABLE_PROT_R, NULL);
 	return 0;
 }
 
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	unsigned long end = hva + PAGE_SIZE;
-	kvm_pfn_t pfn = pte_pfn(pte);
+	kvm_pfn_t pfn = pte_pfn(range->pte);
 
 	if (!kvm->arch.mmu.pgt)
 		return 0;
 
+	WARN_ON(range->end - range->start != 1);
+
 	/*
 	 * We've moved a page around, probably through CoW, so let's treat it
 	 * just like a translation fault and clean the cache to the PoC.
 	 */
 	clean_dcache_guest_page(pfn, PAGE_SIZE);
-	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
+
+	/*
+	 * The MMU notifiers will have unmapped a huge PMD before calling
+	 * ->change_pte() (which in turn calls kvm_set_spte_gfn()) and
+	 * therefore we never need to clear out a huge PMD through this
+	 * calling path and a memcache is not required.
+	 */
+	kvm_pgtable_stage2_map(kvm->arch.mmu.pgt, range->start << PAGE_SHIFT,
+			       PAGE_SIZE, __pfn_to_phys(pfn),
+			       KVM_PGTABLE_PROT_R, NULL);
+
 	return 0;
 }
 
-static int kvm_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	pte_t pte;
+	u64 size = (range->end - range->start) << PAGE_SHIFT;
 	kvm_pte_t kpte;
+	pte_t pte;
+
+	if (!kvm->arch.mmu.pgt)
+		return 0;
 
 	WARN_ON(size != PAGE_SIZE && size != PMD_SIZE && size != PUD_SIZE);
-	kpte = kvm_pgtable_stage2_mkold(kvm->arch.mmu.pgt, gpa);
+
+	kpte = kvm_pgtable_stage2_mkold(kvm->arch.mmu.pgt,
+					range->start << PAGE_SHIFT);
 	pte = __pte(kpte);
 	return pte_valid(pte) && pte_young(pte);
 }
 
-static int kvm_test_age_hva_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
-{
-	WARN_ON(size != PAGE_SIZE && size != PMD_SIZE && size != PUD_SIZE);
-	return kvm_pgtable_stage2_is_young(kvm->arch.mmu.pgt, gpa);
-}
-
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
-{
-	if (!kvm->arch.mmu.pgt)
-		return 0;
-
-	return handle_hva_to_gpa(kvm, start, end, kvm_age_hva_handler, NULL);
-}
-
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	if (!kvm->arch.mmu.pgt)
 		return 0;
 
-	return handle_hva_to_gpa(kvm, hva, hva + PAGE_SIZE,
-				 kvm_test_age_hva_handler, NULL);
+	return kvm_pgtable_stage2_is_young(kvm->arch.mmu.pgt,
+					   range->start << PAGE_SHIFT);
 }
 
 phys_addr_t kvm_mmu_get_httbr(void)
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:52 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:52 -0700
Subject: [PATCH v2 04/10] KVM: MIPS/MMU: Convert to the gfn-based MMU notifier
 callbacks
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-5-seanjc@google.com>

Move MIPS to the gfn-based MMU notifier APIs, which do the hva->gfn
lookup in common code, and whose code is nearly identical to MIPS'
lookup.

No meaningful functional change intended, though the exact order of
operations is slightly different since the memslot lookups occur before
calling into arch code.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/mips/include/asm/kvm_host.h |  1 +
 arch/mips/kvm/mmu.c              | 97 ++++++--------------------------
 2 files changed, 17 insertions(+), 81 deletions(-)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index feaa77036b67..374a3c8806e8 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -967,6 +967,7 @@ enum kvm_mips_fault_result kvm_trap_emul_gva_fault(struct kvm_vcpu *vcpu,
 						   bool write);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
+#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 /* Emulation */
 int kvm_get_inst(u32 *opc, struct kvm_vcpu *vcpu, u32 *out);
diff --git a/arch/mips/kvm/mmu.c b/arch/mips/kvm/mmu.c
index 3dabeda82458..3dc885df2e32 100644
--- a/arch/mips/kvm/mmu.c
+++ b/arch/mips/kvm/mmu.c
@@ -439,85 +439,36 @@ static int kvm_mips_mkold_gpa_pt(struct kvm *kvm, gfn_t start_gfn,
 				  end_gfn << PAGE_SHIFT);
 }
 
-static int handle_hva_to_gpa(struct kvm *kvm,
-			     unsigned long start,
-			     unsigned long end,
-			     int (*handler)(struct kvm *kvm, gfn_t gfn,
-					    gpa_t gfn_end,
-					    struct kvm_memory_slot *memslot,
-					    void *data),
-			     void *data)
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
-	int ret = 0;
-
-	slots = kvm_memslots(kvm);
-
-	/* we only care about the pages that the guest sees */
-	kvm_for_each_memslot(memslot, slots) {
-		unsigned long hva_start, hva_end;
-		gfn_t gfn, gfn_end;
-
-		hva_start = max(start, memslot->userspace_addr);
-		hva_end = min(end, memslot->userspace_addr +
-					(memslot->npages << PAGE_SHIFT));
-		if (hva_start >= hva_end)
-			continue;
-
-		/*
-		 * {gfn(page) | page intersects with [hva_start, hva_end)} =
-		 * {gfn_start, gfn_start+1, ..., gfn_end-1}.
-		 */
-		gfn = hva_to_gfn_memslot(hva_start, memslot);
-		gfn_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot);
-
-		ret |= handler(kvm, gfn, gfn_end, memslot, data);
-	}
-
-	return ret;
-}
-
-
-static int kvm_unmap_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
-				 struct kvm_memory_slot *memslot, void *data)
-{
-	kvm_mips_flush_gpa_pt(kvm, gfn, gfn_end);
-	return 1;
-}
-
-int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end,
-			unsigned flags)
-{
-	handle_hva_to_gpa(kvm, start, end, &kvm_unmap_hva_handler, NULL);
+	kvm_mips_flush_gpa_pt(kvm, range->start, range->end);
 
 	kvm_mips_callbacks->flush_shadow_all(kvm);
 	return 0;
 }
 
-static int kvm_set_spte_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
-				struct kvm_memory_slot *memslot, void *data)
+static bool __kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	gpa_t gpa = gfn << PAGE_SHIFT;
-	pte_t hva_pte = *(pte_t *)data;
+	gpa_t gpa = range->start << PAGE_SHIFT;
+	pte_t hva_pte = range->pte;
 	pte_t *gpa_pte = kvm_mips_pte_for_gpa(kvm, NULL, gpa);
 	pte_t old_pte;
 
 	if (!gpa_pte)
-		return 0;
+		return false;
 
 	/* Mapping may need adjusting depending on memslot flags */
 	old_pte = *gpa_pte;
-	if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES && !pte_dirty(old_pte))
+	if (range->slot->flags & KVM_MEM_LOG_DIRTY_PAGES && !pte_dirty(old_pte))
 		hva_pte = pte_mkclean(hva_pte);
-	else if (memslot->flags & KVM_MEM_READONLY)
+	else if (range->slot->flags & KVM_MEM_READONLY)
 		hva_pte = pte_wrprotect(hva_pte);
 
 	set_pte(gpa_pte, hva_pte);
 
 	/* Replacing an absent or old page doesn't need flushes */
 	if (!pte_present(old_pte) || !pte_young(old_pte))
-		return 0;
+		return false;
 
 	/* Pages swapped, aged, moved, or cleaned require flushes */
 	return !pte_present(hva_pte) ||
@@ -526,27 +477,21 @@ static int kvm_set_spte_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
 	       (pte_dirty(old_pte) && !pte_dirty(hva_pte));
 }
 
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	unsigned long end = hva + PAGE_SIZE;
-	int ret;
-
-	ret = handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pte);
-	if (ret)
+	if (__kvm_set_spte_gfn(kvm, range))
 		kvm_mips_callbacks->flush_shadow_all(kvm);
-	return 0;
+	return false;
 }
 
-static int kvm_age_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
-			       struct kvm_memory_slot *memslot, void *data)
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm_mips_mkold_gpa_pt(kvm, gfn, gfn_end);
+	return kvm_mips_mkold_gpa_pt(kvm, range->start, range->end);
 }
 
-static int kvm_test_age_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
-				    struct kvm_memory_slot *memslot, void *data)
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	gpa_t gpa = gfn << PAGE_SHIFT;
+	gpa_t gpa = range->start << PAGE_SHIFT;
 	pte_t *gpa_pte = kvm_mips_pte_for_gpa(kvm, NULL, gpa);
 
 	if (!gpa_pte)
@@ -554,16 +499,6 @@ static int kvm_test_age_hva_handler(struct kvm *kvm, gfn_t gfn, gfn_t gfn_end,
 	return pte_young(*gpa_pte);
 }
 
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
-{
-	return handle_hva_to_gpa(kvm, start, end, kvm_age_hva_handler, NULL);
-}
-
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
-{
-	return handle_hva_to_gpa(kvm, hva, hva, kvm_test_age_hva_handler, NULL);
-}
-
 /**
  * _kvm_mips_map_page_fast() - Fast path GPA fault handler.
  * @vcpu:		VCPU pointer.
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:53 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:53 -0700
Subject: [PATCH v2 05/10] KVM: PPC: Convert to the gfn-based MMU notifier
 callbacks
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-6-seanjc@google.com>

Move PPC to the gfn-base MMU notifier APIs, and update all 15 bajillion
PPC-internal hooks to work with gfns instead of hvas.

No meaningful functional change intended, though the exact order of
operations is slightly different since the memslot lookups occur before
calling into arch code.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/powerpc/include/asm/kvm_book3s.h  | 12 ++--
 arch/powerpc/include/asm/kvm_host.h    |  1 +
 arch/powerpc/include/asm/kvm_ppc.h     |  9 ++-
 arch/powerpc/kvm/book3s.c              | 18 +++--
 arch/powerpc/kvm/book3s.h              | 10 ++-
 arch/powerpc/kvm/book3s_64_mmu_hv.c    | 98 +++++++-------------------
 arch/powerpc/kvm/book3s_64_mmu_radix.c | 25 +++----
 arch/powerpc/kvm/book3s_hv.c           | 12 ++--
 arch/powerpc/kvm/book3s_pr.c           | 56 +++++----------
 arch/powerpc/kvm/e500_mmu_host.c       | 27 +++----
 10 files changed, 95 insertions(+), 173 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index 2f5f919f6cd3..2d03f2930767 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -210,12 +210,12 @@ extern void kvmppc_free_pgtable_radix(struct kvm *kvm, pgd_t *pgd,
 				      unsigned int lpid);
 extern int kvmppc_radix_init(void);
 extern void kvmppc_radix_exit(void);
-extern int kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			unsigned long gfn);
-extern int kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			unsigned long gfn);
-extern int kvm_test_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			unsigned long gfn);
+extern bool kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			    unsigned long gfn);
+extern bool kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			  unsigned long gfn);
+extern bool kvm_test_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			       unsigned long gfn);
 extern long kvmppc_hv_get_dirty_log_radix(struct kvm *kvm,
 			struct kvm_memory_slot *memslot, unsigned long *map);
 extern void kvmppc_radix_flush_memslot(struct kvm *kvm,
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 1e83359f286b..1335f0001bdd 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -55,6 +55,7 @@
 #include <linux/mmu_notifier.h>
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
+#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 #define HPTEG_CACHE_NUM			(1 << 15)
 #define HPTEG_HASH_BITS_PTE		13
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index 8aacd76bb702..21ab0332eb42 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -281,11 +281,10 @@ struct kvmppc_ops {
 				     const struct kvm_memory_slot *old,
 				     const struct kvm_memory_slot *new,
 				     enum kvm_mr_change change);
-	int (*unmap_hva_range)(struct kvm *kvm, unsigned long start,
-			   unsigned long end);
-	int (*age_hva)(struct kvm *kvm, unsigned long start, unsigned long end);
-	int (*test_age_hva)(struct kvm *kvm, unsigned long hva);
-	void (*set_spte_hva)(struct kvm *kvm, unsigned long hva, pte_t pte);
+	bool (*unmap_gfn_range)(struct kvm *kvm, struct kvm_gfn_range *range);
+	bool (*age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
+	bool (*test_age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
+	bool (*set_spte_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);
 	void (*free_memslot)(struct kvm_memory_slot *slot);
 	int (*init_vm)(struct kvm *kvm);
 	void (*destroy_vm)(struct kvm *kvm);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 44bf567b6589..2b691f4d1f26 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -834,26 +834,24 @@ void kvmppc_core_commit_memory_region(struct kvm *kvm,
 	kvm->arch.kvm_ops->commit_memory_region(kvm, mem, old, new, change);
 }
 
-int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end,
-			unsigned flags)
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm->arch.kvm_ops->unmap_hva_range(kvm, start, end);
+	return kvm->arch.kvm_ops->unmap_gfn_range(kvm, range);
 }
 
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm->arch.kvm_ops->age_hva(kvm, start, end);
+	return kvm->arch.kvm_ops->age_gfn(kvm, range);
 }
 
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	return kvm->arch.kvm_ops->test_age_hva(kvm, hva);
+	return kvm->arch.kvm_ops->test_age_gfn(kvm, range);
 }
 
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	kvm->arch.kvm_ops->set_spte_hva(kvm, hva, pte);
-	return 0;
+	return kvm->arch.kvm_ops->set_spte_gfn(kvm, range);
 }
 
 int kvmppc_core_init_vm(struct kvm *kvm)
diff --git a/arch/powerpc/kvm/book3s.h b/arch/powerpc/kvm/book3s.h
index 9b6323ec8e60..740e51def5a5 100644
--- a/arch/powerpc/kvm/book3s.h
+++ b/arch/powerpc/kvm/book3s.h
@@ -9,12 +9,10 @@
 
 extern void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
 					 struct kvm_memory_slot *memslot);
-extern int kvm_unmap_hva_range_hv(struct kvm *kvm, unsigned long start,
-				  unsigned long end);
-extern int kvm_age_hva_hv(struct kvm *kvm, unsigned long start,
-			  unsigned long end);
-extern int kvm_test_age_hva_hv(struct kvm *kvm, unsigned long hva);
-extern void kvm_set_spte_hva_hv(struct kvm *kvm, unsigned long hva, pte_t pte);
+extern bool kvm_unmap_gfn_range_hv(struct kvm *kvm, struct kvm_gfn_range *range);
+extern bool kvm_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
+extern bool kvm_test_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
+extern bool kvm_set_spte_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range);
 
 extern int kvmppc_mmu_init_pr(struct kvm_vcpu *vcpu);
 extern void kvmppc_mmu_destroy_pr(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index bb6773594cf8..b7bd9ca040b8 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -752,51 +752,6 @@ void kvmppc_rmap_reset(struct kvm *kvm)
 	srcu_read_unlock(&kvm->srcu, srcu_idx);
 }
 
-typedef int (*hva_handler_fn)(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			      unsigned long gfn);
-
-static int kvm_handle_hva_range(struct kvm *kvm,
-				unsigned long start,
-				unsigned long end,
-				hva_handler_fn handler)
-{
-	int ret;
-	int retval = 0;
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
-
-	slots = kvm_memslots(kvm);
-	kvm_for_each_memslot(memslot, slots) {
-		unsigned long hva_start, hva_end;
-		gfn_t gfn, gfn_end;
-
-		hva_start = max(start, memslot->userspace_addr);
-		hva_end = min(end, memslot->userspace_addr +
-					(memslot->npages << PAGE_SHIFT));
-		if (hva_start >= hva_end)
-			continue;
-		/*
-		 * {gfn(page) | page intersects with [hva_start, hva_end)} =
-		 * {gfn, gfn+1, ..., gfn_end-1}.
-		 */
-		gfn = hva_to_gfn_memslot(hva_start, memslot);
-		gfn_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot);
-
-		for (; gfn < gfn_end; ++gfn) {
-			ret = handler(kvm, memslot, gfn);
-			retval |= ret;
-		}
-	}
-
-	return retval;
-}
-
-static int kvm_handle_hva(struct kvm *kvm, unsigned long hva,
-			  hva_handler_fn handler)
-{
-	return kvm_handle_hva_range(kvm, hva, hva + 1, handler);
-}
-
 /* Must be called with both HPTE and rmap locked */
 static void kvmppc_unmap_hpte(struct kvm *kvm, unsigned long i,
 			      struct kvm_memory_slot *memslot,
@@ -840,8 +795,8 @@ static void kvmppc_unmap_hpte(struct kvm *kvm, unsigned long i,
 	}
 }
 
-static int kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			   unsigned long gfn)
+static bool kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			    unsigned long gfn)
 {
 	unsigned long i;
 	__be64 *hptep;
@@ -874,16 +829,15 @@ static int kvm_unmap_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 		unlock_rmap(rmapp);
 		__unlock_hpte(hptep, be64_to_cpu(hptep[0]));
 	}
-	return 0;
+	return false;
 }
 
-int kvm_unmap_hva_range_hv(struct kvm *kvm, unsigned long start, unsigned long end)
+bool kvm_unmap_gfn_range_hv(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	hva_handler_fn handler;
+	if (kvm_is_radix(kvm))
+		return kvm_unmap_radix(kvm, range->slot, range->start);
 
-	handler = kvm_is_radix(kvm) ? kvm_unmap_radix : kvm_unmap_rmapp;
-	kvm_handle_hva_range(kvm, start, end, handler);
-	return 0;
+	return kvm_unmap_rmapp(kvm, range->slot, range->start);
 }
 
 void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
@@ -913,8 +867,8 @@ void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
 	}
 }
 
-static int kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			 unsigned long gfn)
+static bool kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			  unsigned long gfn)
 {
 	struct revmap_entry *rev = kvm->arch.hpt.rev;
 	unsigned long head, i, j;
@@ -968,26 +922,26 @@ static int kvm_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 	return ret;
 }
 
-int kvm_age_hva_hv(struct kvm *kvm, unsigned long start, unsigned long end)
+bool kvm_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	hva_handler_fn handler;
+	if (kvm_is_radix(kvm))
+		kvm_age_radix(kvm, range->slot, range->start);
 
-	handler = kvm_is_radix(kvm) ? kvm_age_radix : kvm_age_rmapp;
-	return kvm_handle_hva_range(kvm, start, end, handler);
+	return kvm_age_rmapp(kvm, range->slot, range->start);
 }
 
-static int kvm_test_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
-			      unsigned long gfn)
+static bool kvm_test_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			       unsigned long gfn)
 {
 	struct revmap_entry *rev = kvm->arch.hpt.rev;
 	unsigned long head, i, j;
 	unsigned long *hp;
-	int ret = 1;
+	bool ret = true;
 	unsigned long *rmapp;
 
 	rmapp = &memslot->arch.rmap[gfn - memslot->base_gfn];
 	if (*rmapp & KVMPPC_RMAP_REFERENCED)
-		return 1;
+		return true;
 
 	lock_rmap(rmapp);
 	if (*rmapp & KVMPPC_RMAP_REFERENCED)
@@ -1002,27 +956,27 @@ static int kvm_test_age_rmapp(struct kvm *kvm, struct kvm_memory_slot *memslot,
 				goto out;
 		} while ((i = j) != head);
 	}
-	ret = 0;
+	ret = false;
 
  out:
 	unlock_rmap(rmapp);
 	return ret;
 }
 
-int kvm_test_age_hva_hv(struct kvm *kvm, unsigned long hva)
+bool kvm_test_age_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	hva_handler_fn handler;
+	if (kvm_is_radix(kvm))
+		kvm_test_age_radix(kvm, range->slot, range->start);
 
-	handler = kvm_is_radix(kvm) ? kvm_test_age_radix : kvm_test_age_rmapp;
-	return kvm_handle_hva(kvm, hva, handler);
+	return kvm_test_age_rmapp(kvm, range->slot, range->start);
 }
 
-void kvm_set_spte_hva_hv(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn_hv(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	hva_handler_fn handler;
+	if (kvm_is_radix(kvm))
+		return kvm_unmap_radix(kvm, range->slot, range->start);
 
-	handler = kvm_is_radix(kvm) ? kvm_unmap_radix : kvm_unmap_rmapp;
-	kvm_handle_hva(kvm, hva, handler);
+	return kvm_unmap_rmapp(kvm, range->slot, range->start);
 }
 
 static int vcpus_running(struct kvm *kvm)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index e603de7ade52..ec4f58fa9f5a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -993,8 +993,8 @@ int kvmppc_book3s_radix_page_fault(struct kvm_vcpu *vcpu,
 }
 
 /* Called with kvm->mmu_lock held */
-int kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-		    unsigned long gfn)
+bool kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+		     unsigned long gfn)
 {
 	pte_t *ptep;
 	unsigned long gpa = gfn << PAGE_SHIFT;
@@ -1002,24 +1002,24 @@ int kvm_unmap_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
 
 	if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE) {
 		uv_page_inval(kvm->arch.lpid, gpa, PAGE_SHIFT);
-		return 0;
+		return false;
 	}
 
 	ptep = find_kvm_secondary_pte(kvm, gpa, &shift);
 	if (ptep && pte_present(*ptep))
 		kvmppc_unmap_pte(kvm, ptep, gpa, shift, memslot,
 				 kvm->arch.lpid);
-	return 0;
+	return false;
 }
 
 /* Called with kvm->mmu_lock held */
-int kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-		  unsigned long gfn)
+bool kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+		   unsigned long gfn)
 {
 	pte_t *ptep;
 	unsigned long gpa = gfn << PAGE_SHIFT;
 	unsigned int shift;
-	int ref = 0;
+	bool ref = false;
 	unsigned long old, *rmapp;
 
 	if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE)
@@ -1035,26 +1035,27 @@ int kvm_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
 		kvmhv_update_nest_rmap_rc_list(kvm, rmapp, _PAGE_ACCESSED, 0,
 					       old & PTE_RPN_MASK,
 					       1UL << shift);
-		ref = 1;
+		ref = true;
 	}
 	return ref;
 }
 
 /* Called with kvm->mmu_lock held */
-int kvm_test_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
-		       unsigned long gfn)
+bool kvm_test_age_radix(struct kvm *kvm, struct kvm_memory_slot *memslot,
+			unsigned long gfn)
+
 {
 	pte_t *ptep;
 	unsigned long gpa = gfn << PAGE_SHIFT;
 	unsigned int shift;
-	int ref = 0;
+	bool ref = false;
 
 	if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE)
 		return ref;
 
 	ptep = find_kvm_secondary_pte(kvm, gpa, &shift);
 	if (ptep && pte_present(*ptep) && pte_young(*ptep))
-		ref = 1;
+		ref = true;
 	return ref;
 }
 
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 13bad6bf4c95..07682ad4110e 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4770,7 +4770,7 @@ int kvmppc_switch_mmu_to_hpt(struct kvm *kvm)
 		kvmhv_release_all_nested(kvm);
 	kvmppc_rmap_reset(kvm);
 	kvm->arch.process_table = 0;
-	/* Mutual exclusion with kvm_unmap_hva_range etc. */
+	/* Mutual exclusion with kvm_unmap_gfn_range etc. */
 	spin_lock(&kvm->mmu_lock);
 	kvm->arch.radix = 0;
 	spin_unlock(&kvm->mmu_lock);
@@ -4792,7 +4792,7 @@ int kvmppc_switch_mmu_to_radix(struct kvm *kvm)
 	if (err)
 		return err;
 	kvmppc_rmap_reset(kvm);
-	/* Mutual exclusion with kvm_unmap_hva_range etc. */
+	/* Mutual exclusion with kvm_unmap_gfn_range etc. */
 	spin_lock(&kvm->mmu_lock);
 	kvm->arch.radix = 1;
 	spin_unlock(&kvm->mmu_lock);
@@ -5654,10 +5654,10 @@ static struct kvmppc_ops kvm_ops_hv = {
 	.flush_memslot  = kvmppc_core_flush_memslot_hv,
 	.prepare_memory_region = kvmppc_core_prepare_memory_region_hv,
 	.commit_memory_region  = kvmppc_core_commit_memory_region_hv,
-	.unmap_hva_range = kvm_unmap_hva_range_hv,
-	.age_hva  = kvm_age_hva_hv,
-	.test_age_hva = kvm_test_age_hva_hv,
-	.set_spte_hva = kvm_set_spte_hva_hv,
+	.unmap_gfn_range = kvm_unmap_gfn_range_hv,
+	.age_gfn = kvm_age_gfn_hv,
+	.test_age_gfn = kvm_test_age_gfn_hv,
+	.set_spte_gfn = kvm_set_spte_gfn_hv,
 	.free_memslot = kvmppc_core_free_memslot_hv,
 	.init_vm =  kvmppc_core_init_vm_hv,
 	.destroy_vm = kvmppc_core_destroy_vm_hv,
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 913944dc3620..d7733b07f489 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -425,61 +425,39 @@ static int kvmppc_core_check_requests_pr(struct kvm_vcpu *vcpu)
 }
 
 /************* MMU Notifiers *************/
-static void do_kvm_unmap_hva(struct kvm *kvm, unsigned long start,
-			     unsigned long end)
+static bool do_kvm_unmap_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	long i;
 	struct kvm_vcpu *vcpu;
-	struct kvm_memslots *slots;
-	struct kvm_memory_slot *memslot;
 
-	slots = kvm_memslots(kvm);
-	kvm_for_each_memslot(memslot, slots) {
-		unsigned long hva_start, hva_end;
-		gfn_t gfn, gfn_end;
+	kvm_for_each_vcpu(i, vcpu, kvm)
+		kvmppc_mmu_pte_pflush(vcpu, range->start << PAGE_SHIFT,
+				      range->end << PAGE_SHIFT);
 
-		hva_start = max(start, memslot->userspace_addr);
-		hva_end = min(end, memslot->userspace_addr +
-					(memslot->npages << PAGE_SHIFT));
-		if (hva_start >= hva_end)
-			continue;
-		/*
-		 * {gfn(page) | page intersects with [hva_start, hva_end)} =
-		 * {gfn, gfn+1, ..., gfn_end-1}.
-		 */
-		gfn = hva_to_gfn_memslot(hva_start, memslot);
-		gfn_end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, memslot);
-		kvm_for_each_vcpu(i, vcpu, kvm)
-			kvmppc_mmu_pte_pflush(vcpu, gfn << PAGE_SHIFT,
-					      gfn_end << PAGE_SHIFT);
-	}
+	return false;
 }
 
-static int kvm_unmap_hva_range_pr(struct kvm *kvm, unsigned long start,
-				  unsigned long end)
+static bool kvm_unmap_gfn_range_pr(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	do_kvm_unmap_hva(kvm, start, end);
-
-	return 0;
+	return do_kvm_unmap_gfn(kvm, range);
 }
 
-static int kvm_age_hva_pr(struct kvm *kvm, unsigned long start,
-			  unsigned long end)
+static bool kvm_age_gfn_pr(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* XXX could be more clever ;) */
-	return 0;
+	return false;
 }
 
-static int kvm_test_age_hva_pr(struct kvm *kvm, unsigned long hva)
+static bool kvm_test_age_gfn_pr(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* XXX could be more clever ;) */
-	return 0;
+	return false;
 }
 
-static void kvm_set_spte_hva_pr(struct kvm *kvm, unsigned long hva, pte_t pte)
+static bool kvm_set_spte_gfn_pr(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* The page will get remapped properly on its next fault */
-	do_kvm_unmap_hva(kvm, hva, hva + PAGE_SIZE);
+	return do_kvm_unmap_gfn(kvm, range);
 }
 
 /*****************************************/
@@ -2079,10 +2057,10 @@ static struct kvmppc_ops kvm_ops_pr = {
 	.flush_memslot = kvmppc_core_flush_memslot_pr,
 	.prepare_memory_region = kvmppc_core_prepare_memory_region_pr,
 	.commit_memory_region = kvmppc_core_commit_memory_region_pr,
-	.unmap_hva_range = kvm_unmap_hva_range_pr,
-	.age_hva  = kvm_age_hva_pr,
-	.test_age_hva = kvm_test_age_hva_pr,
-	.set_spte_hva = kvm_set_spte_hva_pr,
+	.unmap_gfn_range = kvm_unmap_gfn_range_pr,
+	.age_gfn  = kvm_age_gfn_pr,
+	.test_age_gfn = kvm_test_age_gfn_pr,
+	.set_spte_gfn = kvm_set_spte_gfn_pr,
 	.free_memslot = kvmppc_core_free_memslot_pr,
 	.init_vm = kvmppc_core_init_vm_pr,
 	.destroy_vm = kvmppc_core_destroy_vm_pr,
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 648aefe1a3e7..7f16afc331ef 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -721,43 +721,36 @@ int kvmppc_load_last_inst(struct kvm_vcpu *vcpu,
 
 /************* MMU Notifiers *************/
 
-static int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
+static bool kvm_e500_mmu_unmap_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/*
 	 * Flush all shadow tlb entries everywhere. This is slow, but
 	 * we are 100% sure that we catch the to be unmapped page
 	 */
-	kvm_flush_remote_tlbs(kvm);
-
-	return 0;
+	return true;
 }
 
-int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long end,
-			unsigned flags)
+bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
-	/* kvm_unmap_hva flushes everything anyways */
-	kvm_unmap_hva(kvm, start);
-
-	return 0;
+	return kvm_e500_mmu_unmap_gfn(kvm, range);
 }
 
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end)
+bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* XXX could be more clever ;) */
-	return 0;
+	return false;
 }
 
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* XXX could be more clever ;) */
-	return 0;
+	return false;
 }
 
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
+bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	/* The page will get remapped properly on its next fault */
-	kvm_unmap_hva(kvm, hva);
-	return 0;
+	return kvm_e500_mmu_unmap_gfn(kvm, range);
 }
 
 /*****************************************/
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:55 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:55 -0700
Subject: [PATCH v2 07/10] KVM: Move MMU notifier's mmu_lock acquisition into
 common helper
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-8-seanjc@google.com>

Acquire and release mmu_lock in the __kvm_handle_hva_range() helper
instead of requiring the caller to do the same.  This paves the way for
future patches to take mmu_lock if and only if an overlapping memslot is
found, without also having to introduce the on_lock() shenanigans used
to manipulate the notifier count and sequence.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---

Note, the WARN_ON_ONCE that asserts on_lock and handler aren't both null
is optimized out of all functions on recent gcc (for x86).  I wanted to
make it a BUILD_BUG_ON, but older versions of gcc aren't agressive/smart
enough to optimize it out, and using __builtin_constant_p() to get it to
build on older compilers prevents the assertion from firing on newer
compilers when given bad input.

I'm also a-ok dropping the check altogether, it just felt wrong having
the semi-funky on_lock -> !handler combo without documenting that handler
isn't allowed to be null in the common case.

 virt/kvm/kvm_main.c | 125 +++++++++++++++++++++++++++++---------------
 1 file changed, 82 insertions(+), 43 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2e809d73c7f1..25ecb5235e17 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -453,28 +453,57 @@ static void kvm_mmu_notifier_invalidate_range(struct mmu_notifier *mn,
 
 typedef bool (*hva_handler_t)(struct kvm *kvm, struct kvm_gfn_range *range);
 
+typedef void (*on_lock_fn_t)(struct kvm *kvm, unsigned long start,
+			     unsigned long end);
+
 struct kvm_hva_range {
 	unsigned long start;
 	unsigned long end;
 	pte_t pte;
 	hva_handler_t handler;
+	on_lock_fn_t on_lock;
 	bool flush_on_ret;
 	bool may_block;
 };
 
+/*
+ * Use a dedicated stub instead of NULL to indicate that there is no callback
+ * function/handler.  The compiler technically can't guarantee that a real
+ * function will have a non-zero address, and so it will generate code to
+ * check for !NULL, whereas comparing against a stub will be elided at compile
+ * time (unless the compiler is getting long in the tooth, e.g. gcc 4.9).
+ */
+static void kvm_null_fn(void)
+{
+
+}
+#define IS_KVM_NULL_FN(fn) ((fn) == (void *)kvm_null_fn)
+
 static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 						  const struct kvm_hva_range *range)
 {
-	struct kvm_memory_slot *slot;
-	struct kvm_memslots *slots;
 	struct kvm_gfn_range gfn_range;
+	struct kvm_memory_slot *slot;
+	struct kvm_memslots *slots;
 	bool ret = false;
 	int i, idx;
 
-	lockdep_assert_held_write(&kvm->mmu_lock);
+	/* A null handler is allowed if and only if on_lock() is provided. */
+	if (WARN_ON_ONCE(IS_KVM_NULL_FN(range->on_lock) &&
+			 IS_KVM_NULL_FN(range->handler)))
+		return 0;
+
+	KVM_MMU_LOCK(kvm);
 
 	idx = srcu_read_lock(&kvm->srcu);
 
+	if (!IS_KVM_NULL_FN(range->on_lock)) {
+		range->on_lock(kvm, range->start, range->end);
+
+		if (IS_KVM_NULL_FN(range->handler))
+			goto out_unlock;
+	}
+
 	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
 		slots = __kvm_memslots(kvm, i);
 		kvm_for_each_memslot(slot, slots) {
@@ -510,6 +539,9 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 	if (range->flush_on_ret && (ret || kvm->tlbs_dirty))
 		kvm_flush_remote_tlbs(kvm);
 
+out_unlock:
+	KVM_MMU_UNLOCK(kvm);
+
 	srcu_read_unlock(&kvm->srcu, idx);
 
 	/* The notifiers are averse to booleans. :-( */
@@ -528,16 +560,12 @@ static __always_inline int kvm_handle_hva_range(struct mmu_notifier *mn,
 		.end		= end,
 		.pte		= pte,
 		.handler	= handler,
+		.on_lock	= (void *)kvm_null_fn,
 		.flush_on_ret	= true,
 		.may_block	= false,
 	};
-	int ret;
 
-	KVM_MMU_LOCK(kvm);
-	ret = __kvm_handle_hva_range(kvm, &range);
-	KVM_MMU_UNLOCK(kvm);
-
-	return ret;
+	return __kvm_handle_hva_range(kvm, &range);
 }
 
 static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn,
@@ -551,16 +579,12 @@ static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn
 		.end		= end,
 		.pte		= __pte(0),
 		.handler	= handler,
+		.on_lock	= (void *)kvm_null_fn,
 		.flush_on_ret	= false,
 		.may_block	= false,
 	};
-	int ret;
 
-	KVM_MMU_LOCK(kvm);
-	ret = __kvm_handle_hva_range(kvm, &range);
-	KVM_MMU_UNLOCK(kvm);
-
-	return ret;
+	return __kvm_handle_hva_range(kvm, &range);
 }
 static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 					struct mm_struct *mm,
@@ -581,22 +605,9 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 	kvm_handle_hva_range(mn, address, address + 1, pte, kvm_set_spte_gfn);
 }
 
-static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
-					const struct mmu_notifier_range *range)
+static void kvm_inc_notifier_count(struct kvm *kvm, unsigned long start,
+				   unsigned long end)
 {
-	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-	const struct kvm_hva_range hva_range = {
-		.start		= range->start,
-		.end		= range->end,
-		.pte		= __pte(0),
-		.handler	= kvm_unmap_gfn_range,
-		.flush_on_ret	= true,
-		.may_block	= mmu_notifier_range_blockable(range),
-	};
-
-	trace_kvm_unmap_hva_range(range->start, range->end);
-
-	KVM_MMU_LOCK(kvm);
 	/*
 	 * The count increase must become visible at unlock time as no
 	 * spte can be established without taking the mmu_lock and
@@ -604,8 +615,8 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 	 */
 	kvm->mmu_notifier_count++;
 	if (likely(kvm->mmu_notifier_count == 1)) {
-		kvm->mmu_notifier_range_start = range->start;
-		kvm->mmu_notifier_range_end = range->end;
+		kvm->mmu_notifier_range_start = start;
+		kvm->mmu_notifier_range_end = end;
 	} else {
 		/*
 		 * Fully tracking multiple concurrent ranges has dimishing
@@ -617,24 +628,36 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 		 * complete.
 		 */
 		kvm->mmu_notifier_range_start =
-			min(kvm->mmu_notifier_range_start, range->start);
+			min(kvm->mmu_notifier_range_start, start);
 		kvm->mmu_notifier_range_end =
-			max(kvm->mmu_notifier_range_end, range->end);
+			max(kvm->mmu_notifier_range_end, end);
 	}
-
-	__kvm_handle_hva_range(kvm, &hva_range);
-
-	KVM_MMU_UNLOCK(kvm);
-
-	return 0;
 }
 
-static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
+static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 					const struct mmu_notifier_range *range)
 {
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
+	const struct kvm_hva_range hva_range = {
+		.start		= range->start,
+		.end		= range->end,
+		.pte		= __pte(0),
+		.handler	= kvm_unmap_gfn_range,
+		.on_lock	= kvm_inc_notifier_count,
+		.flush_on_ret	= true,
+		.may_block	= mmu_notifier_range_blockable(range),
+	};
 
-	KVM_MMU_LOCK(kvm);
+	trace_kvm_unmap_hva_range(range->start, range->end);
+
+	__kvm_handle_hva_range(kvm, &hva_range);
+
+	return 0;
+}
+
+static void kvm_dec_notifier_count(struct kvm *kvm, unsigned long start,
+				   unsigned long end)
+{
 	/*
 	 * This sequence increase will notify the kvm page fault that
 	 * the page that is going to be mapped in the spte could have
@@ -648,7 +671,23 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 	 * in conjunction with the smp_rmb in mmu_notifier_retry().
 	 */
 	kvm->mmu_notifier_count--;
-	KVM_MMU_UNLOCK(kvm);
+}
+
+static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
+					const struct mmu_notifier_range *range)
+{
+	struct kvm *kvm = mmu_notifier_to_kvm(mn);
+	const struct kvm_hva_range hva_range = {
+		.start		= range->start,
+		.end		= range->end,
+		.pte		= __pte(0),
+		.handler	= (void *)kvm_null_fn,
+		.on_lock	= kvm_dec_notifier_count,
+		.flush_on_ret	= true,
+		.may_block	= mmu_notifier_range_blockable(range),
+	};
+
+	__kvm_handle_hva_range(kvm, &hva_range);
 
 	BUG_ON(kvm->mmu_notifier_count < 0);
 }
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:56 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:56 -0700
Subject: [PATCH v2 08/10] KVM: Take mmu_lock when handling MMU notifier iff
 the hva hits a memslot
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-9-seanjc@google.com>

Defer acquiring mmu_lock in the MMU notifier paths until a "hit" has been
detected in the memslots, i.e. don't take the lock for notifications that
don't affect the guest.

For small VMs, spurious locking is a minor annoyance.  And for "volatile"
setups where the majority of notifications _are_ relevant, this barely
qualifies as an optimization.

But, for large VMs (hundreds of threads) with static setups, e.g. no
page migration, no swapping, etc..., the vast majority of MMU notifier
callbacks will be unrelated to the guest, e.g. will often be in response
to the userspace VMM adjusting its own virtual address space.  In such
large VMs, acquiring mmu_lock can be painful as it blocks vCPUs from
handling page faults.  In some scenarios it can even be "fatal" in the
sense that it causes unacceptable brownouts, e.g. when rebuilding huge
pages after live migration, a significant percentage of vCPUs will be
attempting to handle page faults.

x86's TDP MMU implementation is especially susceptible to spurious
locking due it taking mmu_lock for read when handling page faults.
Because rwlock is fair, a single writer will stall future readers, while
the writer is itself stalled waiting for in-progress readers to complete.
This is exacerbated by the MMU notifiers often firing multiple times in
quick succession, e.g. moving a page will (always?) invoke three separate
notifiers: .invalidate_range_start(), invalidate_range_end(), and
.change_pte().  Unnecessarily taking mmu_lock each time means even a
single spurious sequence can be problematic.

Note, this optimizes only the unpaired callbacks.  Optimizing the
.invalidate_range_{start,end}() pairs is more complex and will be done in
a future patch.

Suggested-by: Ben Gardon <bgardon at google.com>
Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 virt/kvm/kvm_main.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 25ecb5235e17..f6697ad741ed 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -482,10 +482,10 @@ static void kvm_null_fn(void)
 static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 						  const struct kvm_hva_range *range)
 {
+	bool ret = false, locked = false;
 	struct kvm_gfn_range gfn_range;
 	struct kvm_memory_slot *slot;
 	struct kvm_memslots *slots;
-	bool ret = false;
 	int i, idx;
 
 	/* A null handler is allowed if and only if on_lock() is provided. */
@@ -493,11 +493,13 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 			 IS_KVM_NULL_FN(range->handler)))
 		return 0;
 
-	KVM_MMU_LOCK(kvm);
-
 	idx = srcu_read_lock(&kvm->srcu);
 
+	/* The on_lock() path does not yet support lock elision. */
 	if (!IS_KVM_NULL_FN(range->on_lock)) {
+		locked = true;
+		KVM_MMU_LOCK(kvm);
+
 		range->on_lock(kvm, range->start, range->end);
 
 		if (IS_KVM_NULL_FN(range->handler))
@@ -532,6 +534,10 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 			gfn_range.end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, slot);
 			gfn_range.slot = slot;
 
+			if (!locked) {
+				locked = true;
+				KVM_MMU_LOCK(kvm);
+			}
 			ret |= range->handler(kvm, &gfn_range);
 		}
 	}
@@ -540,7 +546,8 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 		kvm_flush_remote_tlbs(kvm);
 
 out_unlock:
-	KVM_MMU_UNLOCK(kvm);
+	if (locked)
+		KVM_MMU_UNLOCK(kvm);
 
 	srcu_read_unlock(&kvm->srcu, idx);
 
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:54 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:54 -0700
Subject: [PATCH v2 06/10] KVM: Kill off the old hva-based MMU notifier
 callbacks
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-7-seanjc@google.com>

Yank out the hva-based MMU notifier APIs now that all architectures that
use the notifiers have moved to the gfn-based APIs.

No functional change intended.

Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/arm64/include/asm/kvm_host.h   |  1 -
 arch/mips/include/asm/kvm_host.h    |  1 -
 arch/powerpc/include/asm/kvm_host.h |  1 -
 arch/x86/include/asm/kvm_host.h     |  1 -
 include/linux/kvm_host.h            |  8 ---
 virt/kvm/kvm_main.c                 | 85 -----------------------------
 6 files changed, 97 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1ad729cf7b0d..72e6b4600264 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -582,7 +582,6 @@ int __kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
 			      struct kvm_vcpu_events *events);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
-#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 void kvm_arm_halt_guest(struct kvm *kvm);
 void kvm_arm_resume_guest(struct kvm *kvm);
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 374a3c8806e8..feaa77036b67 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -967,7 +967,6 @@ enum kvm_mips_fault_result kvm_trap_emul_gva_fault(struct kvm_vcpu *vcpu,
 						   bool write);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
-#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 /* Emulation */
 int kvm_get_inst(u32 *opc, struct kvm_vcpu *vcpu, u32 *out);
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 1335f0001bdd..1e83359f286b 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -55,7 +55,6 @@
 #include <linux/mmu_notifier.h>
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
-#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 #define HPTEG_CACHE_NUM			(1 << 15)
 #define HPTEG_HASH_BITS_PTE		13
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index a21e3698f4dc..99778ac51243 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1718,7 +1718,6 @@ asmlinkage void kvm_spurious_fault(void);
 	_ASM_EXTABLE(666b, 667b)
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
-#define KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 
 int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
 int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index e6bb401dd856..40ac2d40bb5a 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -219,7 +219,6 @@ int kvm_async_pf_wakeup_all(struct kvm_vcpu *vcpu);
 #endif
 
 #ifdef KVM_ARCH_WANT_MMU_NOTIFIER
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 struct kvm_gfn_range {
 	struct kvm_memory_slot *slot;
 	gfn_t start;
@@ -231,13 +230,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range);
 bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
 bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
 bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range);
-#else
-int kvm_unmap_hva_range(struct kvm *kvm,
-			unsigned long start, unsigned long end, unsigned flags);
-int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
-int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
-int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
-#endif /* KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS */
 #endif
 
 enum {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7a7e62ae5eb4..2e809d73c7f1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -451,8 +451,6 @@ static void kvm_mmu_notifier_invalidate_range(struct mmu_notifier *mn,
 	srcu_read_unlock(&kvm->srcu, idx);
 }
 
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-
 typedef bool (*hva_handler_t)(struct kvm *kvm, struct kvm_gfn_range *range);
 
 struct kvm_hva_range {
@@ -564,8 +562,6 @@ static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn
 
 	return ret;
 }
-#endif /* KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS */
-
 static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 					struct mm_struct *mm,
 					unsigned long address,
@@ -573,9 +569,6 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 {
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	int idx;
-#endif
 	trace_kvm_set_spte_hva(address);
 
 	/*
@@ -585,26 +578,13 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 	 */
 	WARN_ON_ONCE(!kvm->mmu_notifier_count);
 
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	kvm_handle_hva_range(mn, address, address + 1, pte, kvm_set_spte_gfn);
-#else
-	idx = srcu_read_lock(&kvm->srcu);
-
-	KVM_MMU_LOCK(kvm);
-
-	if (kvm_set_spte_hva(kvm, address, pte))
-		kvm_flush_remote_tlbs(kvm);
-
-	KVM_MMU_UNLOCK(kvm);
-	srcu_read_unlock(&kvm->srcu, idx);
-#endif
 }
 
 static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 					const struct mmu_notifier_range *range)
 {
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	const struct kvm_hva_range hva_range = {
 		.start		= range->start,
 		.end		= range->end,
@@ -613,16 +593,9 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 		.flush_on_ret	= true,
 		.may_block	= mmu_notifier_range_blockable(range),
 	};
-#else
-	int need_tlb_flush = 0, idx;
-#endif
 
 	trace_kvm_unmap_hva_range(range->start, range->end);
 
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	idx = srcu_read_lock(&kvm->srcu);
-#endif
-
 	KVM_MMU_LOCK(kvm);
 	/*
 	 * The count increase must become visible at unlock time as no
@@ -649,20 +622,9 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 			max(kvm->mmu_notifier_range_end, range->end);
 	}
 
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	__kvm_handle_hva_range(kvm, &hva_range);
-#else
-	need_tlb_flush = kvm_unmap_hva_range(kvm, range->start, range->end,
-					     range->flags);
-	/* we've to flush the tlb before the pages can be freed */
-	if (need_tlb_flush || kvm->tlbs_dirty)
-		kvm_flush_remote_tlbs(kvm);
-#endif
 
 	KVM_MMU_UNLOCK(kvm);
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	srcu_read_unlock(&kvm->srcu, idx);
-#endif
 
 	return 0;
 }
@@ -696,27 +658,9 @@ static int kvm_mmu_notifier_clear_flush_young(struct mmu_notifier *mn,
 					      unsigned long start,
 					      unsigned long end)
 {
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-	int young, idx;
-#endif
 	trace_kvm_age_hva(start, end);
 
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	return kvm_handle_hva_range(mn, start, end, __pte(0), kvm_age_gfn);
-#else
-	idx = srcu_read_lock(&kvm->srcu);
-	KVM_MMU_LOCK(kvm);
-
-	young = kvm_age_hva(kvm, start, end);
-	if (young)
-		kvm_flush_remote_tlbs(kvm);
-
-	KVM_MMU_UNLOCK(kvm);
-	srcu_read_unlock(&kvm->srcu, idx);
-
-	return young;
-#endif
 }
 
 static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
@@ -724,11 +668,6 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
 					unsigned long start,
 					unsigned long end)
 {
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-	int young, idx;
-#endif
-
 	trace_kvm_age_hva(start, end);
 
 	/*
@@ -744,41 +683,17 @@ static int kvm_mmu_notifier_clear_young(struct mmu_notifier *mn,
 	 * cadence. If we find this inaccurate, we might come up with a
 	 * more sophisticated heuristic later.
 	 */
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	return kvm_handle_hva_range_no_flush(mn, start, end, kvm_age_gfn);
-#else
-	idx = srcu_read_lock(&kvm->srcu);
-	KVM_MMU_LOCK(kvm);
-	young = kvm_age_hva(kvm, start, end);
-	KVM_MMU_UNLOCK(kvm);
-	srcu_read_unlock(&kvm->srcu, idx);
-
-	return young;
-#endif
 }
 
 static int kvm_mmu_notifier_test_young(struct mmu_notifier *mn,
 				       struct mm_struct *mm,
 				       unsigned long address)
 {
-#ifndef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
-	struct kvm *kvm = mmu_notifier_to_kvm(mn);
-	int young, idx;
-#endif
 	trace_kvm_test_age_hva(address);
 
-#ifdef KVM_ARCH_WANT_NEW_MMU_NOTIFIER_APIS
 	return kvm_handle_hva_range_no_flush(mn, address, address + 1,
 					     kvm_test_age_gfn);
-#else
-	idx = srcu_read_lock(&kvm->srcu);
-	KVM_MMU_LOCK(kvm);
-	young = kvm_test_age_hva(kvm, address);
-	KVM_MMU_UNLOCK(kvm);
-	srcu_read_unlock(&kvm->srcu, idx);
-
-	return young;
-#endif
 }
 
 static void kvm_mmu_notifier_release(struct mmu_notifier *mn,
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:57 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:57 -0700
Subject: [PATCH v2 09/10] KVM: Don't take mmu_lock for range invalidation
 unless necessary
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-10-seanjc@google.com>

Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
notifications.  Because mmu_notifier_count must be modified while holding
mmu_lock for write, and must always be paired across start->end to stay
balanced, lock elision must happen in both or none.  To meet that
requirement, add a rwsem to prevent memslot updates across range_start()
and range_end().

Use a rwsem instead of a rwlock since most notifiers _allow_ blocking,
and the lock will be endl across the entire start() ... end() sequence.
If anything in the sequence sleeps, including the caller or a different
notifier, holding the spinlock would be disastrous.

For notifiers that _disallow_ blocking, e.g. OOM reaping, simply go down
the slow path of unconditionally acquiring mmu_lock.  The sane
alternative would be to try to acquire the lock and force the notifier
to retry on failure.  But since OOM is currently the _only_ scenario
where blocking is disallowed attempting to optimize a guest that has been
marked for death is pointless.

Unconditionally define and use mmu_notifier_slots_lock in the memslots
code, purely to avoid more #ifdefs.  The overhead of acquiring the lock
is negligible when the lock is uncontested, which will always be the case
when the MMU notifiers are not used.

Note, technically flag-only memslot updates could be allowed in parallel,
but stalling a memslot update for a relatively short amount of time is
not a scalability issue, and this is all more than complex enough.

Based heavily on code from Ben Gardon.

Suggested-by: Ben Gardon <bgardon at google.com>
Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 include/linux/kvm_host.h |  6 ++-
 virt/kvm/kvm_main.c      | 96 +++++++++++++++++++++++++++++++---------
 2 files changed, 80 insertions(+), 22 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 40ac2d40bb5a..bc3dd2838bb8 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -472,6 +472,7 @@ struct kvm {
 #endif /* KVM_HAVE_MMU_RWLOCK */
 
 	struct mutex slots_lock;
+	struct rw_semaphore mmu_notifier_slots_lock;
 	struct mm_struct *mm; /* userspace tied to this vm */
 	struct kvm_memslots __rcu *memslots[KVM_ADDRESS_SPACE_NUM];
 	struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
@@ -660,8 +661,9 @@ static inline struct kvm_memslots *__kvm_memslots(struct kvm *kvm, int as_id)
 {
 	as_id = array_index_nospec(as_id, KVM_ADDRESS_SPACE_NUM);
 	return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
-			lockdep_is_held(&kvm->slots_lock) ||
-			!refcount_read(&kvm->users_count));
+				      lockdep_is_held(&kvm->slots_lock) ||
+				      lockdep_is_held(&kvm->mmu_notifier_slots_lock) ||
+				      !refcount_read(&kvm->users_count));
 }
 
 static inline struct kvm_memslots *kvm_memslots(struct kvm *kvm)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f6697ad741ed..af28f39817a5 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -462,6 +462,7 @@ struct kvm_hva_range {
 	pte_t pte;
 	hva_handler_t handler;
 	on_lock_fn_t on_lock;
+	bool must_lock;
 	bool flush_on_ret;
 	bool may_block;
 };
@@ -479,6 +480,25 @@ static void kvm_null_fn(void)
 }
 #define IS_KVM_NULL_FN(fn) ((fn) == (void *)kvm_null_fn)
 
+
+/* Acquire mmu_lock if necessary.  Returns %true if @handler is "null" */
+static __always_inline bool kvm_mmu_lock_and_check_handler(struct kvm *kvm,
+							   const struct kvm_hva_range *range,
+							   bool *locked)
+{
+	if (*locked)
+		return false;
+
+	*locked = true;
+
+	KVM_MMU_LOCK(kvm);
+
+	if (!IS_KVM_NULL_FN(range->on_lock))
+		range->on_lock(kvm, range->start, range->end);
+
+	return IS_KVM_NULL_FN(range->handler);
+}
+
 static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 						  const struct kvm_hva_range *range)
 {
@@ -495,16 +515,9 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 
 	idx = srcu_read_lock(&kvm->srcu);
 
-	/* The on_lock() path does not yet support lock elision. */
-	if (!IS_KVM_NULL_FN(range->on_lock)) {
-		locked = true;
-		KVM_MMU_LOCK(kvm);
-
-		range->on_lock(kvm, range->start, range->end);
-
-		if (IS_KVM_NULL_FN(range->handler))
-			goto out_unlock;
-	}
+	if (range->must_lock &&
+	    kvm_mmu_lock_and_check_handler(kvm, range, &locked))
+		goto out_unlock;
 
 	for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) {
 		slots = __kvm_memslots(kvm, i);
@@ -534,10 +547,9 @@ static __always_inline int __kvm_handle_hva_range(struct kvm *kvm,
 			gfn_range.end = hva_to_gfn_memslot(hva_end + PAGE_SIZE - 1, slot);
 			gfn_range.slot = slot;
 
-			if (!locked) {
-				locked = true;
-				KVM_MMU_LOCK(kvm);
-			}
+			if (kvm_mmu_lock_and_check_handler(kvm, range, &locked))
+				goto out_unlock;
+
 			ret |= range->handler(kvm, &gfn_range);
 		}
 	}
@@ -568,6 +580,7 @@ static __always_inline int kvm_handle_hva_range(struct mmu_notifier *mn,
 		.pte		= pte,
 		.handler	= handler,
 		.on_lock	= (void *)kvm_null_fn,
+		.must_lock	= false,
 		.flush_on_ret	= true,
 		.may_block	= false,
 	};
@@ -587,6 +600,7 @@ static __always_inline int kvm_handle_hva_range_no_flush(struct mmu_notifier *mn
 		.pte		= __pte(0),
 		.handler	= handler,
 		.on_lock	= (void *)kvm_null_fn,
+		.must_lock	= false,
 		.flush_on_ret	= false,
 		.may_block	= false,
 	};
@@ -603,11 +617,15 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
 	trace_kvm_set_spte_hva(address);
 
 	/*
-	 * .change_pte() must be bookended by .invalidate_range_{start,end}(),
-	 * and so always runs with an elevated notifier count.  This obviates
-	 * the need to bump the sequence count.
+	 * .change_pte() must be bookended by .invalidate_range_{start,end}().
+	 * If mmu_notifier_count is zero, then start() didn't find a relevant
+	 * memslot and wasn't forced down the slow path; rechecking here is
+	 * unnecessary.  This can only occur if memslot updates are blocked.
 	 */
-	WARN_ON_ONCE(!kvm->mmu_notifier_count);
+	if (!kvm->mmu_notifier_count) {
+		lockdep_assert_held(&kvm->mmu_notifier_slots_lock);
+		return;
+	}
 
 	kvm_handle_hva_range(mn, address, address + 1, pte, kvm_set_spte_gfn);
 }
@@ -644,6 +662,7 @@ static void kvm_inc_notifier_count(struct kvm *kvm, unsigned long start,
 static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 					const struct mmu_notifier_range *range)
 {
+	bool blockable = mmu_notifier_range_blockable(range);
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 	const struct kvm_hva_range hva_range = {
 		.start		= range->start,
@@ -651,12 +670,29 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
 		.pte		= __pte(0),
 		.handler	= kvm_unmap_gfn_range,
 		.on_lock	= kvm_inc_notifier_count,
+		.must_lock	= !blockable,
 		.flush_on_ret	= true,
-		.may_block	= mmu_notifier_range_blockable(range),
+		.may_block	= blockable,
 	};
 
 	trace_kvm_unmap_hva_range(range->start, range->end);
 
+	/*
+	 * Prevent memslot modification between range_start() and range_end()
+	 * so that conditionally locking provides the same result in both
+	 * functions.  Without that guarantee, the mmu_notifier_count
+	 * adjustments will be imbalanced.
+	 *
+	 * Skip the memslot-lookup lock elision (set @must_lock above) to avoid
+	 * having to take the semaphore on non-blockable calls, e.g. OOM kill.
+	 * The complexity required to handle conditional locking for this case
+	 * is not worth the marginal benefits, the VM is likely doomed anyways.
+	 *
+	 * Pairs with the unlock in range_end().
+	 */
+	if (blockable)
+		down_read(&kvm->mmu_notifier_slots_lock);
+
 	__kvm_handle_hva_range(kvm, &hva_range);
 
 	return 0;
@@ -683,6 +719,7 @@ static void kvm_dec_notifier_count(struct kvm *kvm, unsigned long start,
 static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 					const struct mmu_notifier_range *range)
 {
+	bool blockable = mmu_notifier_range_blockable(range);
 	struct kvm *kvm = mmu_notifier_to_kvm(mn);
 	const struct kvm_hva_range hva_range = {
 		.start		= range->start,
@@ -690,12 +727,17 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn,
 		.pte		= __pte(0),
 		.handler	= (void *)kvm_null_fn,
 		.on_lock	= kvm_dec_notifier_count,
+		.must_lock	= !blockable,
 		.flush_on_ret	= true,
-		.may_block	= mmu_notifier_range_blockable(range),
+		.may_block	= blockable,
 	};
 
 	__kvm_handle_hva_range(kvm, &hva_range);
 
+	/* Pairs with the lock in range_start(). */
+	if (blockable)
+		up_read(&kvm->mmu_notifier_slots_lock);
+
 	BUG_ON(kvm->mmu_notifier_count < 0);
 }
 
@@ -908,6 +950,7 @@ static struct kvm *kvm_create_vm(unsigned long type)
 	mutex_init(&kvm->lock);
 	mutex_init(&kvm->irq_lock);
 	mutex_init(&kvm->slots_lock);
+	init_rwsem(&kvm->mmu_notifier_slots_lock);
 	INIT_LIST_HEAD(&kvm->devices);
 
 	BUILD_BUG_ON(KVM_MEM_SLOTS_NUM > SHRT_MAX);
@@ -1028,6 +1071,16 @@ static void kvm_destroy_vm(struct kvm *kvm)
 	kvm_coalesced_mmio_free(kvm);
 #if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
 	mmu_notifier_unregister(&kvm->mmu_notifier, kvm->mm);
+	/*
+	 * Reset the lock used to prevent memslot updates between MMU notifier
+	 * invalidate_range_start() and invalidate_range_end().  At this point,
+	 * no more MMU notifiers will run and pending calls to ...start() have
+	 * completed.  But, the lock could still be held if KVM's notifier was
+	 * removed between ...start() and ...end().  No threads can be waiting
+	 * on the lock as the last reference on KVM has been dropped.  If the
+	 * lock is still held, freeing memslots will deadlock.
+	 */
+	init_rwsem(&kvm->mmu_notifier_slots_lock);
 #else
 	kvm_arch_flush_shadow_all(kvm);
 #endif
@@ -1279,7 +1332,10 @@ static struct kvm_memslots *install_new_memslots(struct kvm *kvm,
 	WARN_ON(gen & KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS);
 	slots->generation = gen | KVM_MEMSLOT_GEN_UPDATE_IN_PROGRESS;
 
+	down_write(&kvm->mmu_notifier_slots_lock);
 	rcu_assign_pointer(kvm->memslots[as_id], slots);
+	up_write(&kvm->mmu_notifier_slots_lock);
+
 	synchronize_srcu_expedited(&kvm->srcu);
 
 	/*
-- 
2.31.0.208.g409f899ff0-goog



From seanjc at google.com  Fri Apr  2 01:56:58 2021
From: seanjc at google.com (Sean Christopherson)
Date: Thu,  1 Apr 2021 17:56:58 -0700
Subject: [PATCH v2 10/10] KVM: x86/mmu: Allow yielding during MMU notifier
 unmap/zap, if possible
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <20210402005658.3024832-11-seanjc@google.com>

Let the TDP MMU yield when unmapping a range in response to a MMU
notification, if yielding is allowed by said notification.  There is no
reason to disallow yielding in this case, and in theory the range being
invalidated could be quite large.

Cc: Ben Gardon <bgardon at google.com>
Signed-off-by: Sean Christopherson <seanjc at google.com>
---
 arch/x86/kvm/mmu/tdp_mmu.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 7797d24f0937..dd17d9673ff2 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -885,7 +885,7 @@ bool kvm_tdp_mmu_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range,
 
 	for_each_tdp_mmu_root(kvm, root, range->slot->as_id)
 		flush |= zap_gfn_range(kvm, root, range->start, range->end,
-				       false, flush);
+				       range->may_block, flush);
 
 	return flush;
 }
@@ -903,6 +903,10 @@ static __always_inline bool kvm_tdp_mmu_handle_gfn(struct kvm *kvm,
 
 	rcu_read_lock();
 
+	/*
+	 * Don't support rescheduling, none of the MMU notifiers that funnel
+	 * into this helper allow blocking; it'd be dead, wasteful code.
+	 */
 	for_each_tdp_mmu_root(kvm, root, range->slot->as_id) {
 		tdp_root_for_each_leaf_pte(iter, root, range->start, range->end)
 			ret |= handler(kvm, &iter, range);
-- 
2.31.0.208.g409f899ff0-goog



From tiantao6 at hisilicon.com  Fri Apr  2 02:10:38 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Fri, 2 Apr 2021 09:10:38 +0800
Subject: [PATCH v2] perf: xgene: Use device_get_match_data() to simplify code
Message-ID: <1617325838-23369-1-git-send-email-tiantao6@hisilicon.com>

Use device_get_match_data() here to simplify the code a bit.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
v2:handled the case which device_get_match_data() return NULL.
---
 drivers/perf/xgene_pmu.c | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index ffe3bde..45f36c1 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
 static int xgene_pmu_probe(struct platform_device *pdev)
 {
 	const struct xgene_pmu_data *dev_data;
-	const struct of_device_id *of_id;
 	struct xgene_pmu *xgene_pmu;
 	struct resource *res;
 	int irq, rc;
@@ -1856,22 +1855,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
 	xgene_pmu->dev = &pdev->dev;
 	platform_set_drvdata(pdev, xgene_pmu);
 
-	version = -EINVAL;
-	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
-	if (of_id) {
-		dev_data = (const struct xgene_pmu_data *) of_id->data;
-		version = dev_data->id;
-	}
-
-#ifdef CONFIG_ACPI
-	if (ACPI_COMPANION(&pdev->dev)) {
-		const struct acpi_device_id *acpi_id;
+	dev_data = device_get_match_data(&pdev->dev);
 
-		acpi_id = acpi_match_device(xgene_pmu_acpi_match, &pdev->dev);
-		if (acpi_id)
-			version = (int) acpi_id->driver_data;
-	}
-#endif
+	version = dev_data ? dev_data->id : -EINVAL;
 	if (version < 0)
 		return -ENODEV;
 
-- 
2.7.4



From swboyd at chromium.org  Fri Apr  2 02:10:31 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Thu, 01 Apr 2021 18:10:31 -0700
Subject: [PATCH V2 3/5] DCC: Added the sysfs entries for DCC(Data Capture
 and Compare) driver
In-Reply-To: <56a657ebc4b843575037e3ba9ec9cb9a@codeaurora.org>
References: <cover.1616651305.git.schowdhu@codeaurora.org>
 <eeb3cfe92cba2c7981170f3c3ff96dd440b69f25.1616651305.git.schowdhu@codeaurora.org>
 <161704857307.3012082.499264834486221320@swboyd.mtv.corp.google.com>
 <56a657ebc4b843575037e3ba9ec9cb9a@codeaurora.org>
Message-ID: <161732583102.2260335.10112716468679763483@swboyd.mtv.corp.google.com>

Quoting schowdhu at codeaurora.org (2021-04-01 08:42:50)
> On 2021-03-30 01:39, Stephen Boyd wrote:
> > Quoting Souradeep Chowdhury (2021-03-25 01:02:34)
> >> The DCC is a DMA engine designed to store register values either in
> >> case of a system crash or in case of software triggers manually done
> >> by the user.Using DCC hardware and the sysfs interface of the driver
> >> the user can exploit various functionalities of DCC.The user can 
> >> specify
> >> the register addresses,the values of which is stored by DCC in it's
> >> dedicated SRAM.The register addresses can be used either to read from,
> >> write to,first read and store value and then write or to loop.All 
> >> these
> >> options can be exploited using the sysfs interface given to the user.
> >> Following are the sysfs interfaces exposed in DCC driver which are
> >> documented
> >> 1)trigger
> >> 2)config
> >> 3)config_write
> >> 4)config_reset
> >> 5)enable
> >> 6)rd_mod_wr
> >> 7)loop
> >> 
> >> Signed-off-by: Souradeep Chowdhury <schowdhu at codeaurora.org>
> >> ---
> >>  Documentation/ABI/testing/sysfs-driver-dcc | 114 
> >> +++++++++++++++++++++++++++++
> > 
> > Please combine this with the driver patch.
> 
> Ack
> 
> > 
> >>  1 file changed, 114 insertions(+)
> >>  create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
> > 
> > Perhaps this should be an ioctl interface instead of a sysfs interface?
> 
> The reasons for choosing sysfs over ioctl is as follows

Cool, please add these details to the commit text.

> 
> 
> i) As can be seen from the sysfs attribute descriptions, most of it does 
> basic hardware manipulations like dcc_enable, dcc_disable, config reset 
> etc. As a result sysfs is preferred over ioctl as we just need to enter 
> a 0 or 1
> signal in such cases.
> 
> ii) Existing similar debug hardwares are there for which drivers have 
> been written using sysfs interface. One such example is the 
> coresight-etm-trace driver. Following is the link for reference
> 
> https://www.kernel.org/doc/html/latest/trace/coresight/coresight-etm4x-reference.html

I wasn't deeply involved but I recall that the whole coresight sysfs
interface was disliked and it mostly got rewritten to go through the
perf tool instead. Pointing to the coresight sysfs API is not the best
approach here.

Maybe a closer analog would be the watchdog subsystem, which is ioctl
based and uses a character device like /dev/watchdog. Watchdogs are
simple debug features that reboot the system when everything goes wrong.
This looks like a hardware block that can be used to gather information
when the watchdog fires.

Reading the doc closer it is quite frightening that a device like this
can let you read registers in the hardware on-demand and even store
values of registers over time. This is like /dev/mem on steroids. This
needs to be highly restricted as it sounds like it could be used to
snoop on security keys that are set in the hardware or secrets stored in
memory. Is the hardware restricted at all in what it can read?


From andrew at aj.id.au  Fri Apr  2 02:14:39 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 02 Apr 2021 11:44:39 +1030
Subject: =?UTF-8?Q?Re:_[PATCH_v3_4/4]_dt-bindings:_serial:_8250:_add_aspeed,
 lpc-a?= =?UTF-8?Q?ddress_and_aspeed,sirq?=
In-Reply-To: <20210402004716.15961-5-zev@bewilderbeest.net>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
 <20210402004716.15961-5-zev@bewilderbeest.net>
Message-ID: <639f957f-a0d7-4a06-8598-90da0e17820b@beta.fastmail.com>



On Fri, 2 Apr 2021, at 11:17, Zev Weiss wrote:
> These correspond to the existing lpc_address, sirq, and sirq_polarity
> sysfs attributes; the second element of aspeed,sirq provides a
> replacement for the deprecated aspeed,sirq-polarity-sense property.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml 
> b/Documentation/devicetree/bindings/serial/8250.yaml
> index 491b9297432d..a6e01f9b745f 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -12,8 +12,13 @@ maintainers:
>  allOf:
>    - $ref: /schemas/serial.yaml#
>    - if:
> -      required:
> -        - aspeed,sirq-polarity-sense
> +      anyOf:
> +        - required:
> +            - aspeed,lpc-address

Why not aspeed,lpc-io-reg like the KCS binding?

There are some things we can do to improve it, but we shouldn't go and invent something different. I prefer aspeed,lpc-io-reg because it's name derives from the generic 'reg' property as does it's behaviour (if you assume a related `#size-cells = 0`).

> +        - required:
> +            - aspeed,sirq

Why not aspeed,lpc-interrupts like the KCS binding?

The generic IRQ property is 'interrupts', so like aspeed,lpc-io-reg the interrupts proposal for KCS follows in name and form. I'm hiding it behind the aspeed vendor prefix for now while I'm not satisfied that I understand the requirements of non-aspeed parts. Similarly, I added the lpc prefix because we don't tend to describe the host devicetree in the BMC devicetree (and so there's no parent interrupt controller that we can reference via a phandle) and we need a way to differentiate from the local interrupts property.

I don't see a reason for either of them to differ from what we already have for KCS, and I don't see any reason to continue the sysfs naming scheme in the binding.

Eventually I want to distil an LPC peripheral binding schema from what we've developed for the peripherals supported by aspeed and nuvoton SoCs.

Cheers,

Andrew

> +        - required:
> +            - aspeed,sirq-polarity-sense
>      then:
>        properties:
>          compatible:
> @@ -190,6 +195,20 @@ properties:
>        applicable to aspeed,ast2500-vuart.
>      deprecated: true
>  
> +  aspeed,lpc-address:
> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> +    description: |
> +      The VUART LPC address.  Only applicable to aspeed,ast2500-vuart.
> +
> +  aspeed,sirq:
> +    $ref: "/schemas/types.yaml#/definitions/uint32-array"
> +    minItems: 2
> +    maxItems: 2
> +    description: |
> +      A 2-cell property describing the VUART SIRQ number and SIRQ
> +      polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH).  Only
> +      applicable to aspeed,ast2500-vuart.
> +
>  required:
>    - reg
>    - interrupts
> @@ -221,6 +240,7 @@ examples:
>      };
>    - |
>      #include <dt-bindings/clock/aspeed-clock.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
>      serial at 1e787000 {
>          compatible = "aspeed,ast2500-vuart";
>          reg = <0x1e787000 0x40>;
> @@ -228,7 +248,8 @@ examples:
>          interrupts = <8>;
>          clocks = <&syscon ASPEED_CLK_APB>;
>          no-loopback-test;
> -        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
> +        aspeed,lpc-address = <0x3f8>;
> +        aspeed,sirq = <4 IRQ_TYPE_LEVEL_LOW>;
>      };
>  
>  ...
> -- 
> 2.31.1
> 
>


From zev at bewilderbeest.net  Fri Apr  2 02:19:47 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Thu, 1 Apr 2021 20:19:47 -0500
Subject: [PATCH v3 4/4] dt-bindings: serial: 8250: add aspeed, lpc-address
 and aspeed,sirq
In-Reply-To: <639f957f-a0d7-4a06-8598-90da0e17820b@beta.fastmail.com>
References: <20210402004716.15961-1-zev@bewilderbeest.net>
 <20210402004716.15961-5-zev@bewilderbeest.net>
 <639f957f-a0d7-4a06-8598-90da0e17820b@beta.fastmail.com>
Message-ID: <YGZxM31x0All76gm@hatter.bewilderbeest.net>

On Thu, Apr 01, 2021 at 08:14:39PM CDT, Andrew Jeffery wrote:
>
>
>On Fri, 2 Apr 2021, at 11:17, Zev Weiss wrote:
>> These correspond to the existing lpc_address, sirq, and sirq_polarity
>> sysfs attributes; the second element of aspeed,sirq provides a
>> replacement for the deprecated aspeed,sirq-polarity-sense property.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
>>  1 file changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml
>> b/Documentation/devicetree/bindings/serial/8250.yaml
>> index 491b9297432d..a6e01f9b745f 100644
>> --- a/Documentation/devicetree/bindings/serial/8250.yaml
>> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
>> @@ -12,8 +12,13 @@ maintainers:
>>  allOf:
>>    - $ref: /schemas/serial.yaml#
>>    - if:
>> -      required:
>> -        - aspeed,sirq-polarity-sense
>> +      anyOf:
>> +        - required:
>> +            - aspeed,lpc-address
>
>Why not aspeed,lpc-io-reg like the KCS binding?
>
>There are some things we can do to improve it, but we shouldn't go and invent something different. I prefer aspeed,lpc-io-reg because it's name derives from the generic 'reg' property as does it's behaviour (if you assume a related `#size-cells = 0`).
>
>> +        - required:
>> +            - aspeed,sirq
>
>Why not aspeed,lpc-interrupts like the KCS binding?
>
>The generic IRQ property is 'interrupts', so like aspeed,lpc-io-reg the interrupts proposal for KCS follows in name and form. I'm hiding it behind the aspeed vendor prefix for now while I'm not satisfied that I understand the requirements of non-aspeed parts. Similarly, I added the lpc prefix because we don't tend to describe the host devicetree in the BMC devicetree (and so there's no parent interrupt controller that we can reference via a phandle) and we need a way to differentiate from the local interrupts property.
>
>I don't see a reason for either of them to differ from what we already have for KCS, and I don't see any reason to continue the sysfs naming scheme in the binding.
>

Ah, OK -- I was aiming for consistency with the existing vuart sysfs 
attributes, but if that's not a worthwhile concern I'm fine with 
aspeed,lpc-io-reg & aspeed,lpc-interrupts.


Zev



From zhangfei.gao at linaro.org  Fri Apr  2 02:34:00 2021
From: zhangfei.gao at linaro.org (Zhangfei Gao)
Date: Fri, 2 Apr 2021 09:34:00 +0800
Subject: [PATCH v14 10/10] iommu/arm-smmu-v3: Add stall support for
 platform devices
In-Reply-To: <20210401171101.GB9447@willie-the-truck>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-11-jean-philippe@linaro.org>
 <20210401171101.GB9447@willie-the-truck>
Message-ID: <0292a8fb-9408-9c2b-0875-0b71e5f6e170@linaro.org>

Hi, Will

On 2021/4/2 ??1:11, Will Deacon wrote:
> On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
>> The SMMU provides a Stall model for handling page faults in platform
>> devices. It is similar to PCIe PRI, but doesn't require devices to have
>> their own translation cache. Instead, faulting transactions are parked
>> and the OS is given a chance to fix the page tables and retry the
>> transaction.
>>
>> Enable stall for devices that support it (opt-in by firmware). When an
>> event corresponds to a translation error, call the IOMMU fault handler.
>> If the fault is recoverable, it will call us back to terminate or
>> continue the stall.
> Which hardware is this useful for? Stalling adds a fair amount of complexity
> to the driver, so I don't think we should support it unless we're likely to
> see platforms that both implement it and do something useful with it.
I have tested the stall mode on Hisilicon Kunpeng920 board, as well as 
using drivers/misc/uacce/uacce.c.

Thanks


From wangzhou1 at hisilicon.com  Fri Apr  2 02:45:01 2021
From: wangzhou1 at hisilicon.com (Zhou Wang)
Date: Fri, 2 Apr 2021 09:45:01 +0800
Subject: [PATCH v14 10/10] iommu/arm-smmu-v3: Add stall support for
 platform devices
In-Reply-To: <20210401171101.GB9447@willie-the-truck>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-11-jean-philippe@linaro.org>
 <20210401171101.GB9447@willie-the-truck>
Message-ID: <8e55e807-69f2-6492-e4a0-0dd9250142bc@hisilicon.com>

On 2021/4/2 1:11, Will Deacon wrote:
> On Thu, Apr 01, 2021 at 05:47:19PM +0200, Jean-Philippe Brucker wrote:
>> The SMMU provides a Stall model for handling page faults in platform
>> devices. It is similar to PCIe PRI, but doesn't require devices to have
>> their own translation cache. Instead, faulting transactions are parked
>> and the OS is given a chance to fix the page tables and retry the
>> transaction.
>>
>> Enable stall for devices that support it (opt-in by firmware). When an
>> event corresponds to a translation error, call the IOMMU fault handler.
>> If the fault is recoverable, it will call us back to terminate or
>> continue the stall.
> 
> Which hardware is this useful for? Stalling adds a fair amount of complexity
> to the driver, so I don't think we should support it unless we're likely to
> see platforms that both implement it and do something useful with it.

Hi Will?

HiSilicon Kunpeng920's ZIP/SEC/HPRE engines(drivers/crypto/hisilicon/) are using
stall mode.

UACCE driver(drivers/misc/uacce/) is used to export these engines to user space.
A user space library: https://github.com/Linaro/uadk offers APIs to help users
to use these engines.

In fact, we only need a quirk(https://lkml.org/lkml/2021/3/8/1506) based on this
IOPF series to make whole solution mainline ready. So please also take this
patch, we need it! :)

Best,
Zhou

> 
> Will
> 
> .
> 



From quan at os.amperecomputing.com  Fri Apr  2 02:59:58 2021
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Fri, 2 Apr 2021 08:59:58 +0700
Subject: [PATCH v2 3/3] bindings: ipmi: Add binding for Aspeed SSIF BMC
 driver
In-Reply-To: <20210401170933.GA622142@robh.at.kernel.org>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-4-quan@os.amperecomputing.com>
 <20210401170933.GA622142@robh.at.kernel.org>
Message-ID: <62acc395-de5b-fd5c-c74f-d7d713b43377@os.amperecomputing.com>

On 02/04/2021 00:09, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 09:10:29PM +0700, Quan Nguyen wrote:
>> Add device tree binding document for the Aspeed SSIF BMC driver.
>>
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
>> ---
>>   .../bindings/ipmi/aspeed-ssif-bmc.txt          | 18 ++++++++++++++++++
>>   1 file changed, 18 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-ssif-bmc.txt
> 
> Same comment as you ignored on v1.
> 

Dear Rob,
I really did not mean to do that.

What happen is that there was a compilation error complaint by kernel 
robot test on my v1. So I tried to send my v2 to fix that issue asap. 
Unfortunately, your reply on my v1 arrived just right after I hit "git 
send-email" to send out my v2.

For this comment, I'll switch to use yaml file in next version.

- Quan


From lkp at intel.com  Fri Apr  2 04:14:24 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 11:14:24 +0800
Subject: [xlnx:xlnx_rebase_v5.4 913/1701] drivers/usb/dwc3/core.c:977:5:
 warning: no previous prototype for function 'dwc3_core_init'
Message-ID: <202104021115.DELqrT8i-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 526f56822f971265d67428fe61e40fe18f95ac81 [913/1701] usb: dwc3: Add hibernation support when operating as gadget
config: x86_64-randconfig-a004-20210401 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 1c268a8ff4e90a85d0e634350b1104080614cf2b)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/526f56822f971265d67428fe61e40fe18f95ac81
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 526f56822f971265d67428fe61e40fe18f95ac81
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1444:6: warning: no previous prototype for function 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
        ^
   drivers/usb/dwc3/core.h:1444:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
   drivers/usb/dwc3/core.h:1446:6: warning: no previous prototype for function 'dwc3_set_simple_data' [-Wmissing-prototypes]
   void dwc3_set_simple_data(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1446:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_set_simple_data(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1448:6: warning: no previous prototype for function 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1448:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1450:5: warning: no previous prototype for function 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
       ^
   drivers/usb/dwc3/core.h:1450:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
   ^
   static 
   drivers/usb/dwc3/core.h:1451:5: warning: non-void function does not return a value [-Wreturn-type]
   { ; }
       ^
   drivers/usb/dwc3/core.c:386:6: warning: no previous prototype for function 'dwc3_free_event_buffers' [-Wmissing-prototypes]
   void dwc3_free_event_buffers(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.c:386:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_free_event_buffers(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.c:403:5: warning: no previous prototype for function 'dwc3_alloc_event_buffers' [-Wmissing-prototypes]
   int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
       ^
   drivers/usb/dwc3/core.c:403:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
   ^
   static 
>> drivers/usb/dwc3/core.c:977:5: warning: no previous prototype for function 'dwc3_core_init' [-Wmissing-prototypes]
   int dwc3_core_init(struct dwc3 *dwc)
       ^
   drivers/usb/dwc3/core.c:977:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_core_init(struct dwc3 *dwc)
   ^
   static 
   8 warnings generated.


vim +/dwc3_core_init +977 drivers/usb/dwc3/core.c

   970	
   971	/**
   972	 * dwc3_core_init - Low-level initialization of DWC3 Core
   973	 * @dwc: Pointer to our controller context structure
   974	 *
   975	 * Returns 0 on success otherwise negative errno.
   976	 */
 > 977	int dwc3_core_init(struct dwc3 *dwc)
   978	{
   979		u32			reg;
   980		int			ret;
   981	
   982		/*
   983		 * Write Linux Version Code to our GUID register so it's easy to figure
   984		 * out which kernel version a bug was found.
   985		 */
   986		dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
   987	
   988		/* Handle USB2.0-only core configuration */
   989		if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
   990				DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
   991			if (dwc->maximum_speed == USB_SPEED_SUPER)
   992				dwc->maximum_speed = USB_SPEED_HIGH;
   993		}
   994	
   995		ret = dwc3_phy_setup(dwc);
   996		if (ret)
   997			goto err0;
   998	
   999		if (!dwc->ulpi_ready) {
  1000			ret = dwc3_core_ulpi_init(dwc);
  1001			if (ret)
  1002				goto err0;
  1003			dwc->ulpi_ready = true;
  1004		}
  1005	
  1006		if (!dwc->phys_ready) {
  1007			ret = dwc3_core_get_phy(dwc);
  1008			if (ret)
  1009				goto err0a;
  1010			dwc->phys_ready = true;
  1011		}
  1012	
  1013		ret = dwc3_core_soft_reset(dwc);
  1014		if (ret)
  1015			goto err0a;
  1016	
  1017		dwc3_core_setup_global_control(dwc);
  1018		dwc3_core_num_eps(dwc);
  1019	
  1020		if (dwc->scratchbuf == NULL) {
  1021			ret = dwc3_alloc_scratch_buffers(dwc);
  1022			if (ret) {
  1023				dev_err(dwc->dev,
  1024					"Not enough memory for scratch buffers\n");
  1025				goto err1;
  1026			}
  1027		}
  1028	
  1029		ret = dwc3_setup_scratch_buffers(dwc);
  1030		if (ret) {
  1031			dev_err(dwc->dev, "Failed to setup scratch buffers: %d\n", ret);
  1032			goto err1;
  1033		}
  1034	
  1035		/* Adjust Frame Length */
  1036		dwc3_frame_length_adjustment(dwc);
  1037	
  1038		dwc3_set_incr_burst_type(dwc);
  1039	
  1040		ret = dwc3_config_soc_bus(dwc);
  1041		if (ret)
  1042			goto err1;
  1043	
  1044		usb_phy_set_suspend(dwc->usb2_phy, 0);
  1045		usb_phy_set_suspend(dwc->usb3_phy, 0);
  1046		ret = phy_power_on(dwc->usb2_generic_phy);
  1047		if (ret < 0)
  1048			goto err2;
  1049	
  1050		ret = phy_power_on(dwc->usb3_generic_phy);
  1051		if (ret < 0)
  1052			goto err3;
  1053	
  1054		ret = dwc3_event_buffers_setup(dwc);
  1055		if (ret) {
  1056			dev_err(dwc->dev, "failed to setup event buffers\n");
  1057			goto err4;
  1058		}
  1059	
  1060		/*
  1061		 * ENDXFER polling is available on version 3.10a and later of
  1062		 * the DWC_usb3 controller. It is NOT available in the
  1063		 * DWC_usb31 controller.
  1064		 */
  1065		if (!dwc3_is_usb31(dwc) && dwc->revision >= DWC3_REVISION_310A) {
  1066			reg = dwc3_readl(dwc->regs, DWC3_GUCTL2);
  1067			reg |= DWC3_GUCTL2_RST_ACTBITLATER;
  1068			dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
  1069		}
  1070	
  1071		/* When configured in HOST mode, after issuing U3/L2 exit controller
  1072		 * fails to send proper CRC checksum in CRC5 feild. Because of this
  1073		 * behaviour Transaction Error is generated, resulting in reset and
  1074		 * re-enumeration of usb device attached. Enabling bit 10 of GUCTL1
  1075		 * will correct this problem
  1076		 */
  1077		if (dwc->enable_guctl1_resume_quirk) {
  1078			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1079			reg |= DWC3_GUCTL1_RESUME_QUIRK;
  1080			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1081		}
  1082	
  1083		/* SNPS controller when configureed in HOST mode maintains Inter Packet
  1084		 * Delay (IPD) of ~380ns which works with most of the super-speed hubs
  1085		 * except VIA-LAB hubs. When IPD is ~380ns HOST controller fails to
  1086		 * enumerate FS/LS devices when connected behind VIA-LAB hubs.
  1087		 * Enabling bit 9 of GUCTL1 enables the workaround in HW to reduce the
  1088		 * ULPI clock latency by 1 cycle, thus reducing the IPD (~360ns) and
  1089		 * making controller enumerate FS/LS devices connected behind VIA-LAB.
  1090		 */
  1091		if (dwc->enable_guctl1_ipd_quirk) {
  1092			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1093			reg |= DWC3_GUCTL1_IPD_QUIRK;
  1094			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1095		}
  1096	
  1097		if (dwc->revision >= DWC3_REVISION_250A) {
  1098			reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
  1099	
  1100			/*
  1101			 * Enable hardware control of sending remote wakeup
  1102			 * in HS when the device is in the L1 state.
  1103			 */
  1104			if (dwc->revision >= DWC3_REVISION_290A)
  1105				reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
  1106	
  1107			if (dwc->dis_tx_ipgap_linecheck_quirk)
  1108				reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
  1109	
  1110			dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
  1111		}
  1112	
  1113		if (dwc->dr_mode == USB_DR_MODE_HOST ||
  1114		    dwc->dr_mode == USB_DR_MODE_OTG) {
  1115			reg = dwc3_readl(dwc->regs, DWC3_GUCTL);
  1116	
  1117			/*
  1118			 * Enable Auto retry Feature to make the controller operating in
  1119			 * Host mode on seeing transaction errors(CRC errors or internal
  1120			 * overrun scenerios) on IN transfers to reply to the device
  1121			 * with a non-terminating retry ACK (i.e, an ACK transcation
  1122			 * packet with Retry=1 & Nump != 0)
  1123			 */
  1124			reg |= DWC3_GUCTL_HSTINAUTORETRY;
  1125	
  1126			dwc3_writel(dwc->regs, DWC3_GUCTL, reg);
  1127		}
  1128	
  1129		/*
  1130		 * Must config both number of packets and max burst settings to enable
  1131		 * RX and/or TX threshold.
  1132		 */
  1133		if (dwc3_is_usb31(dwc) && dwc->dr_mode == USB_DR_MODE_HOST) {
  1134			u8 rx_thr_num = dwc->rx_thr_num_pkt_prd;
  1135			u8 rx_maxburst = dwc->rx_max_burst_prd;
  1136			u8 tx_thr_num = dwc->tx_thr_num_pkt_prd;
  1137			u8 tx_maxburst = dwc->tx_max_burst_prd;
  1138	
  1139			if (rx_thr_num && rx_maxburst) {
  1140				reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
  1141				reg |= DWC31_RXTHRNUMPKTSEL_PRD;
  1142	
  1143				reg &= ~DWC31_RXTHRNUMPKT_PRD(~0);
  1144				reg |= DWC31_RXTHRNUMPKT_PRD(rx_thr_num);
  1145	
  1146				reg &= ~DWC31_MAXRXBURSTSIZE_PRD(~0);
  1147				reg |= DWC31_MAXRXBURSTSIZE_PRD(rx_maxburst);
  1148	
  1149				dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
  1150			}
  1151	
  1152			if (tx_thr_num && tx_maxburst) {
  1153				reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
  1154				reg |= DWC31_TXTHRNUMPKTSEL_PRD;
  1155	
  1156				reg &= ~DWC31_TXTHRNUMPKT_PRD(~0);
  1157				reg |= DWC31_TXTHRNUMPKT_PRD(tx_thr_num);
  1158	
  1159				reg &= ~DWC31_MAXTXBURSTSIZE_PRD(~0);
  1160				reg |= DWC31_MAXTXBURSTSIZE_PRD(tx_maxburst);
  1161	
  1162				dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
  1163			}
  1164		}
  1165	
  1166		return 0;
  1167	
  1168	err4:
  1169		phy_power_off(dwc->usb3_generic_phy);
  1170	
  1171	err3:
  1172		phy_power_off(dwc->usb2_generic_phy);
  1173	
  1174	err2:
  1175		usb_phy_set_suspend(dwc->usb2_phy, 1);
  1176		usb_phy_set_suspend(dwc->usb3_phy, 1);
  1177	
  1178	err1:
  1179		usb_phy_shutdown(dwc->usb2_phy);
  1180		usb_phy_shutdown(dwc->usb3_phy);
  1181		phy_exit(dwc->usb2_generic_phy);
  1182		phy_exit(dwc->usb3_generic_phy);
  1183	
  1184	err0a:
  1185		dwc3_ulpi_exit(dwc);
  1186	
  1187	err0:
  1188		return ret;
  1189	}
  1190	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29136 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/b84873e6/attachment-0001.gz>

From madvenka at linux.microsoft.com  Fri Apr  2 04:24:04 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Thu,  1 Apr 2021 22:24:04 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210402032404.47239-1-madvenka@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
Message-ID: <20210402032404.47239-2-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Reliable stacktracing requires that we identify when a stacktrace is
terminated early. We can do this by ensuring all tasks have a final
frame record at a known location on their task stack, and checking
that this is the final frame record in the chain.

Kernel Tasks
============

All tasks except the idle task have a pt_regs structure right after the
task stack. This is called the task pt_regs. The pt_regs structure has a
special stackframe field. Make this stackframe field the final frame in the
task stack. This needs to be done in copy_thread() which initializes a new
task's pt_regs and initial CPU context.

For the idle task, there is no task pt_regs. For our purpose, we need one.
So, create a pt_regs just like other kernel tasks and make
pt_regs->stackframe the final frame in the idle task stack. This needs to be
done at two places:

	- On the primary CPU, the boot task runs. It calls start_kernel()
	  and eventually becomes the idle task for the primary CPU. Just
	  before start_kernel() is called, set up the final frame.

	- On each secondary CPU, a startup task runs that calls
	  secondary_startup_kernel() and eventually becomes the idle task
	  on the secondary CPU. Just before secondary_start_kernel() is
	  called, set up the final frame.

User Tasks
==========

User tasks are initially set up like kernel tasks when they are created.
Then, they return to userland after fork via ret_from_fork(). After that,
they enter the kernel only on an EL0 exception. (In arm64, system calls are
also EL0 exceptions). The EL0 exception handler stores state in the task
pt_regs and calls different functions based on the type of exception. The
stack trace for an EL0 exception must end at the task pt_regs. So, make
task pt_regs->stackframe as the final frame in the EL0 exception stack.

In summary, task pt_regs->stackframe is where a successful stack trace ends.

Stack trace termination
=======================

In the unwinder, terminate the stack trace successfully when
task_pt_regs(task)->stackframe is reached. For stack traces in the kernel,
this will correctly terminate the stack trace at the right place.

However, debuggers terminate the stack trace when FP == 0. In the
pt_regs->stackframe, the PC is 0 as well. So, stack traces taken in the
debugger may print an extra record 0x0 at the end. While this is not
pretty, this does not do any harm. This is a small price to pay for
having reliable stack trace termination in the kernel.

Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/kernel/entry.S      |  8 +++++---
 arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
 arch/arm64/kernel/process.c    |  5 +++++
 arch/arm64/kernel/stacktrace.c | 10 +++++-----
 4 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a31a0a713c85..e2dc2e998934 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -261,16 +261,18 @@ alternative_else_nop_endif
 	stp	lr, x21, [sp, #S_LR]
 
 	/*
-	 * For exceptions from EL0, terminate the callchain here.
+	 * For exceptions from EL0, terminate the callchain here at
+	 * task_pt_regs(current)->stackframe.
+	 *
 	 * For exceptions from EL1, create a synthetic frame record so the
 	 * interrupted code shows up in the backtrace.
 	 */
 	.if \el == 0
-	mov	x29, xzr
+	stp	xzr, xzr, [sp, #S_STACKFRAME]
 	.else
 	stp	x29, x22, [sp, #S_STACKFRAME]
-	add	x29, sp, #S_STACKFRAME
 	.endif
+	add	x29, sp, #S_STACKFRAME
 
 #ifdef CONFIG_ARM64_SW_TTBR0_PAN
 alternative_if_not ARM64_HAS_PAN
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 840bda1869e9..743c019a42c7 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -393,6 +393,23 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	ret	x28
 SYM_FUNC_END(__create_page_tables)
 
+	/*
+	 * The boot task becomes the idle task for the primary CPU. The
+	 * CPU startup task on each secondary CPU becomes the idle task
+	 * for the secondary CPU.
+	 *
+	 * The idle task does not require pt_regs. But create a dummy
+	 * pt_regs so that task_pt_regs(idle_task)->stackframe can be
+	 * set up to be the final frame on the idle task stack just like
+	 * all the other kernel tasks. This helps the unwinder to
+	 * terminate the stack trace at a well-known stack offset.
+	 */
+	.macro setup_final_frame
+	sub	sp, sp, #PT_REGS_SIZE
+	stp	xzr, xzr, [sp, #S_STACKFRAME]
+	add	x29, sp, #S_STACKFRAME
+	.endm
+
 /*
  * The following fragment of code is executed with the MMU enabled.
  *
@@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 #endif
 	bl	switch_to_vhe			// Prefer VHE if possible
 	add	sp, sp, #16
-	mov	x29, #0
-	mov	x30, #0
-	b	start_kernel
+	setup_final_frame
+	bl	start_kernel
+	nop
 SYM_FUNC_END(__primary_switched)
 
 	.pushsection ".rodata", "a"
@@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
 	cbz	x2, __secondary_too_slow
 	msr	sp_el0, x2
 	scs_load x2, x3
-	mov	x29, #0
-	mov	x30, #0
+	setup_final_frame
 
 #ifdef CONFIG_ARM64_PTR_AUTH
 	ptrauth_keys_init_cpu x2, x3, x4, x5
 #endif
 
-	b	secondary_start_kernel
+	bl	secondary_start_kernel
+	nop
 SYM_FUNC_END(__secondary_switched)
 
 SYM_FUNC_START_LOCAL(__secondary_too_slow)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 325c83b1a24d..906baa232a89 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -437,6 +437,11 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	}
 	p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
 	p->thread.cpu_context.sp = (unsigned long)childregs;
+	/*
+	 * For the benefit of the unwinder, set up childregs->stackframe
+	 * as the final frame for the new task.
+	 */
+	p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
 
 	ptrace_hw_copy_thread(p);
 
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..72f5af8c69dc 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 	unsigned long fp = frame->fp;
 	struct stack_info info;
 
-	/* Terminal record; nothing to unwind */
-	if (!fp)
+	if (!tsk)
+		tsk = current;
+
+	/* Final frame; nothing to unwind */
+	if (fp == (unsigned long) task_pt_regs(tsk)->stackframe)
 		return -ENOENT;
 
 	if (fp & 0xf)
 		return -EINVAL;
 
-	if (!tsk)
-		tsk = current;
-
 	if (!on_accessible_stack(tsk, fp, &info))
 		return -EINVAL;
 
-- 
2.25.1



From madvenka at linux.microsoft.com  Fri Apr  2 04:24:03 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Thu,  1 Apr 2021 22:24:03 -0500
Subject: [RFC PATCH v2 0/1] arm64: Implement stack trace termination record
In-Reply-To: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
Message-ID: <20210402032404.47239-1-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Reliable stacktracing requires that we identify when a stacktrace is
terminated early. We can do this by ensuring all tasks have a final
frame record at a known location on their task stack, and checking
that this is the final frame record in the chain.

All tasks have a pt_regs structure right after the task stack in the stack
page. The pt_regs structure contains a stackframe field. Make this stackframe
field the final frame in the task stack so all stack traces end at a fixed
stack offset.

For kernel tasks, this is simple to understand. For user tasks, there is
some extra detail. User tasks get created via fork() et al. Once they return
from fork, they enter the kernel only on an EL0 exception. In arm64,
system calls are also EL0 exceptions.

The EL0 exception handler uses the task pt_regs mentioned above to save
register state and call different exception functions. All stack traces
from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe
the final frame in the EL0 exception stack.

To summarize, task_pt_regs(task)->stackframe will always be the final frame
in a stack trace.

Sample stack traces
===================

The final frame for the idle tasks is different from v1. The rest of the
stack traces are the same.

Primary CPU's idle task (changed from v1)
=======================

[    0.022365]   arch_stack_walk+0x0/0xd0
[    0.022376]   callfd_stack+0x30/0x60
[    0.022387]   rest_init+0xd8/0xf8
[    0.022397]   arch_call_rest_init+0x18/0x24
[    0.022411]   start_kernel+0x5b8/0x5f4
[    0.022424]   __primary_switched+0xa8/0xac

Secondary CPU's idle task (changed from v1)
=========================

[    0.022484]   arch_stack_walk+0x0/0xd0
[    0.022494]   callfd_stack+0x30/0x60
[    0.022502]   secondary_start_kernel+0x188/0x1e0
[    0.022513]   __secondary_switched+0x80/0x84

---
Changelog:

v1
	- Set up task_pt_regs(current)->stackframe as the final frame
	  when a new task is initialized in copy_thread().

	- Create pt_regs for the idle tasks and set up pt_regs->stackframe
	  as the final frame for the idle tasks.

	- Set up task_pt_regs(current)->stackframe as the final frame in
	  the EL0 exception handler so the EL0 exception stack trace ends
	  there.

	- Terminate the stack trace successfully in unwind_frame() when
	  the FP reaches task_pt_regs(current)->stackframe.

	- The stack traces (above) in the kernel will terminate at the
	  correct place. Debuggers may show an extra record 0x0 at the end
	  for pt_regs->stackframe. That said, I did not see that extra frame
	  when I did stack traces using gdb.
v2
	- Changed some wordings as suggested by Mark Rutland.

	- Removed the synthetic return PC for idle tasks. Changed the
	  branches to start_kernel() and secondary_start_kernel() to
	  calls so that they will have a proper return PC.

Madhavan T. Venkataraman (1):
  arm64: Implement stack trace termination record

 arch/arm64/kernel/entry.S      |  8 +++++---
 arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
 arch/arm64/kernel/process.c    |  5 +++++
 arch/arm64/kernel/stacktrace.c | 10 +++++-----
 4 files changed, 38 insertions(+), 14 deletions(-)


base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
-- 
2.25.1



From shawn.guo at linaro.org  Fri Apr  2 04:55:59 2021
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri,  2 Apr 2021 11:55:59 +0800
Subject: [PATCH v2 0/3] arm-smmu-qcom: Create qcom_smmu_impl for ACPI boot
Message-ID: <20210402035602.9484-1-shawn.guo@linaro.org>

The arm-smmu-qcom driver needs to hook up qcom_smmu_impl for booting up
Snapdragon platforms.  Such hook-up is being done for DT boot by
matching compatibles.  The series tries to handle the hook-up for ACPI
boot by looking at model identifier, which is figured out by IORT driver
using acpi_match_platform_list() helper.  It helps to get Debian
installer booting with ACPI work for Qualcomm SC8180X based laptops like
Lenovo Flex 5G.

Changes for v2:
- Rather than using asl_compiler_id in IORT table, follow suggestion
  from Robin Murphy to use acpi_match_platform_list() to match platform.


Shawn Guo (3):
  ACPI/IORT: Consolidate use of SMMU device platdata
  ACPI/IORT: Add Qualcomm Snapdragon platforms to iort_plat_info[]
  iommu/arm-smmu-qcom: hook up qcom_smmu_impl for ACPI boot

 drivers/acpi/arm64/iort.c                   | 36 +++++++++------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  6 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c  |  9 ++++++
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  9 ++++--
 drivers/perf/arm_smmuv3_pmu.c               |  8 +++--
 include/linux/acpi_iort.h                   | 12 +++++--
 6 files changed, 51 insertions(+), 29 deletions(-)

-- 
2.17.1



From shawn.guo at linaro.org  Fri Apr  2 04:56:00 2021
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri,  2 Apr 2021 11:56:00 +0800
Subject: [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata
In-Reply-To: <20210402035602.9484-1-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
Message-ID: <20210402035602.9484-2-shawn.guo@linaro.org>

Currently the platdata is being used in different way by SMMU and PMCG
device.  The former uses it for acpi_iort_node pointer passing, while
the later uses it for model identifier.  As it's been seen that the
model identifier is useful for SMMU devices as well, let's consolidate
the platdata use to get it accommodate both acpi_iort_node pointer and
model identifier, so that all IORT devices (SMMU, SMMUv3 and PMCG) pass
platdata in a consistent manner.

With this change, model identifier is not specific to PMCG, so
IORT_SMMU_V3_PMCG_GENERIC gets renamed to IORT_SMMU_GENERIC.  While at
it, the spaces used in model defines are converted to tabs.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/acpi/arm64/iort.c                   | 31 ++++++++-------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  6 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  9 ++++--
 drivers/perf/arm_smmuv3_pmu.c               |  8 ++++--
 include/linux/acpi_iort.h                   | 11 ++++++--
 5 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2494138a6905..e2a96d2d399a 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1463,25 +1463,28 @@ static void __init arm_smmu_v3_pmcg_init_resources(struct resource *res,
 				       ACPI_EDGE_SENSITIVE, &res[2]);
 }
 
-static struct acpi_platform_list pmcg_plat_info[] __initdata = {
+static struct acpi_platform_list iort_plat_info[] __initdata = {
 	/* HiSilicon Hip08 Platform */
 	{"HISI  ", "HIP08   ", 0, ACPI_SIG_IORT, greater_than_or_equal,
 	 "Erratum #162001800", IORT_SMMU_V3_PMCG_HISI_HIP08},
 	{ }
 };
 
-static int __init arm_smmu_v3_pmcg_add_platdata(struct platform_device *pdev)
+static int __init iort_smmu_add_platdata(struct platform_device *pdev,
+					 struct acpi_iort_node *node)
 {
-	u32 model;
+	struct iort_smmu_pdata pdata;
 	int idx;
 
-	idx = acpi_match_platform_list(pmcg_plat_info);
+	pdata.node = node;
+
+	idx = acpi_match_platform_list(iort_plat_info);
 	if (idx >= 0)
-		model = pmcg_plat_info[idx].data;
+		pdata.model = iort_plat_info[idx].data;
 	else
-		model = IORT_SMMU_V3_PMCG_GENERIC;
+		pdata.model = IORT_SMMU_GENERIC;
 
-	return platform_device_add_data(pdev, &model, sizeof(model));
+	return platform_device_add_data(pdev, &pdata, sizeof(pdata));
 }
 
 struct iort_dev_config {
@@ -1494,7 +1497,6 @@ struct iort_dev_config {
 				     struct acpi_iort_node *node);
 	int (*dev_set_proximity)(struct device *dev,
 				    struct acpi_iort_node *node);
-	int (*dev_add_platdata)(struct platform_device *pdev);
 };
 
 static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
@@ -1516,7 +1518,6 @@ static const struct iort_dev_config iort_arm_smmu_v3_pmcg_cfg __initconst = {
 	.name = "arm-smmu-v3-pmcg",
 	.dev_count_resources = arm_smmu_v3_pmcg_count_resources,
 	.dev_init_resources = arm_smmu_v3_pmcg_init_resources,
-	.dev_add_platdata = arm_smmu_v3_pmcg_add_platdata,
 };
 
 static __init const struct iort_dev_config *iort_get_dev_cfg(
@@ -1579,17 +1580,7 @@ static int __init iort_add_platform_device(struct acpi_iort_node *node,
 	if (ret)
 		goto dev_put;
 
-	/*
-	 * Platform devices based on PMCG nodes uses platform_data to
-	 * pass the hardware model info to the driver. For others, add
-	 * a copy of IORT node pointer to platform_data to be used to
-	 * retrieve IORT data information.
-	 */
-	if (ops->dev_add_platdata)
-		ret = ops->dev_add_platdata(pdev);
-	else
-		ret = platform_device_add_data(pdev, &node, sizeof(node));
-
+	ret = iort_smmu_add_platdata(pdev, node);
 	if (ret)
 		goto dev_put;
 
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 8ca7415d785d..91c9a74d8ac6 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3397,9 +3397,13 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
 {
 	struct acpi_iort_smmu_v3 *iort_smmu;
 	struct device *dev = smmu->dev;
+	struct iort_smmu_pdata *pdata = dev_get_platdata(dev);
 	struct acpi_iort_node *node;
 
-	node = *(struct acpi_iort_node **)dev_get_platdata(dev);
+	if (pdata == NULL)
+		return -ENODEV;
+
+	node = pdata->node;
 
 	/* Retrieve SMMUv3 specific data */
 	iort_smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a61..d53ab3927a30 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1991,11 +1991,16 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
 				      struct arm_smmu_device *smmu)
 {
 	struct device *dev = smmu->dev;
-	struct acpi_iort_node *node =
-		*(struct acpi_iort_node **)dev_get_platdata(dev);
+	struct iort_smmu_pdata *pdata = dev_get_platdata(dev);
+	struct acpi_iort_node *node;
 	struct acpi_iort_smmu *iort_smmu;
 	int ret;
 
+	if (pdata == NULL)
+		return -ENODEV;
+
+	node = pdata->node;
+
 	/* Retrieve SMMU1/2 specific data */
 	iort_smmu = (struct acpi_iort_smmu *)node->node_data;
 
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 74474bb322c3..77fcf5e7413a 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -747,17 +747,19 @@ static void smmu_pmu_reset(struct smmu_pmu *smmu_pmu)
 
 static void smmu_pmu_get_acpi_options(struct smmu_pmu *smmu_pmu)
 {
-	u32 model;
+	struct iort_smmu_pdata *pdata = dev_get_platdata(smmu_pmu->dev);
 
-	model = *(u32 *)dev_get_platdata(smmu_pmu->dev);
+	if (pdata == NULL)
+		goto done;
 
-	switch (model) {
+	switch (pdata->model) {
 	case IORT_SMMU_V3_PMCG_HISI_HIP08:
 		/* HiSilicon Erratum 162001800 */
 		smmu_pmu->options |= SMMU_PMCG_EVCNTR_RDONLY;
 		break;
 	}
 
+done:
 	dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
 }
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 1a12baa58e40..678cdf036948 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -15,12 +15,17 @@
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
 /*
- * PMCG model identifiers for use in smmu pmu driver. Please note
+ * Model identifiers for use in SMMU drivers. Please note
  * that this is purely for the use of software and has nothing to
  * do with hardware or with IORT specification.
  */
-#define IORT_SMMU_V3_PMCG_GENERIC        0x00000000 /* Generic SMMUv3 PMCG */
-#define IORT_SMMU_V3_PMCG_HISI_HIP08     0x00000001 /* HiSilicon HIP08 PMCG */
+#define IORT_SMMU_GENERIC		0x00000000 /* Generic SMMU */
+#define IORT_SMMU_V3_PMCG_HISI_HIP08	0x00000001 /* HiSilicon HIP08 PMCG */
+
+struct iort_smmu_pdata {
+	struct acpi_iort_node *node;
+	u32 model;
+};
 
 int iort_register_domain_token(int trans_id, phys_addr_t base,
 			       struct fwnode_handle *fw_node);
-- 
2.17.1



From shawn.guo at linaro.org  Fri Apr  2 04:56:01 2021
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri,  2 Apr 2021 11:56:01 +0800
Subject: [PATCH v2 2/3] ACPI/IORT: Add Qualcomm Snapdragon platforms to
 iort_plat_info[]
In-Reply-To: <20210402035602.9484-1-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
Message-ID: <20210402035602.9484-3-shawn.guo@linaro.org>

The SMMU driver on Qualcomm Snapdragon platforms needs to hook up some
QCOM specific arm_smmu_impl.  Define model identifier for QCOM SMMU and
add Qualcomm SC8180X platform to iort_plat_info[], so that SMMU
driver can detect the model and handle QCOM specific arm_smmu_impl.

Some device chooses to use manufacturer name in IORT table, like Lenovo
Flex 5G, while others use SoC vendor name, such as Microsoft Surface Pro
X and Samsung Galaxy Book S.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/acpi/arm64/iort.c | 5 +++++
 include/linux/acpi_iort.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e2a96d2d399a..f88b8c0a7d84 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1467,6 +1467,11 @@ static struct acpi_platform_list iort_plat_info[] __initdata = {
 	/* HiSilicon Hip08 Platform */
 	{"HISI  ", "HIP08   ", 0, ACPI_SIG_IORT, greater_than_or_equal,
 	 "Erratum #162001800", IORT_SMMU_V3_PMCG_HISI_HIP08},
+	/* Qualcomm Snapdragon Platform */
+	{ "LENOVO", "CB-01   ", 0x8180, ACPI_SIG_IORT, equal,
+	  "QCOM SMMU", IORT_SMMU_QCOM },
+	{ "QCOM  ", "QCOMEDK2", 0x8180, ACPI_SIG_IORT, equal,
+	  "QCOM SMMU", IORT_SMMU_QCOM },
 	{ }
 };
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 678cdf036948..66c859ea2abf 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -21,6 +21,7 @@
  */
 #define IORT_SMMU_GENERIC		0x00000000 /* Generic SMMU */
 #define IORT_SMMU_V3_PMCG_HISI_HIP08	0x00000001 /* HiSilicon HIP08 PMCG */
+#define IORT_SMMU_QCOM			0x00000002 /* QCOM SMMU */
 
 struct iort_smmu_pdata {
 	struct acpi_iort_node *node;
-- 
2.17.1



From shawn.guo at linaro.org  Fri Apr  2 04:56:02 2021
From: shawn.guo at linaro.org (Shawn Guo)
Date: Fri,  2 Apr 2021 11:56:02 +0800
Subject: [PATCH v2 3/3] iommu/arm-smmu-qcom: hook up qcom_smmu_impl for ACPI
 boot
In-Reply-To: <20210402035602.9484-1-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
Message-ID: <20210402035602.9484-4-shawn.guo@linaro.org>

The hookup with qcom_smmu_impl is required to do ACPI boot on SC8180X
based devices like Lenovo Flex 5G laptop and Microsoft Surface Pro X.
Check IORT SMMU model identifier and create qcom_smmu_impl accordingly.

(np == NULL) is used to check ACPI boot, because fwnode of SMMU device
is a static allocation and thus helpers like has_acpi_companion() don't
work here.

Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 82c7edc6e025..7ced0f93bc99 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2019, The Linux Foundation. All rights reserved.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/adreno-smmu-priv.h>
 #include <linux/of_device.h>
 #include <linux/qcom_scm.h>
@@ -340,6 +341,14 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
 {
 	const struct device_node *np = smmu->dev->of_node;
 
+	if (np == NULL) {
+		/* ACPI boot */
+		struct iort_smmu_pdata *pdata = dev_get_platdata(smmu->dev);
+
+		if (pdata && pdata->model == IORT_SMMU_QCOM)
+			return qcom_smmu_create(smmu, &qcom_smmu_impl);
+	}
+
 	if (of_match_node(qcom_smmu_impl_of_match, np))
 		return qcom_smmu_create(smmu, &qcom_smmu_impl);
 
-- 
2.17.1



From hch at infradead.org  Fri Apr  2 07:37:40 2021
From: hch at infradead.org (Christoph Hellwig)
Date: Fri, 2 Apr 2021 07:37:40 +0100
Subject: [PATCH v5 03/18] mm: add generic function_nocfi macro
In-Reply-To: <20210401233216.2540591-4-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-4-samitolvanen@google.com>
Message-ID: <20210402063740.GA1738362@infradead.org>

Thanks, this looks much better than the earlier naming:

Acked-by: Christoph Hellwig <hch at lst.de>


From christianshewitt at gmail.com  Fri Apr  2 07:45:18 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Fri,  2 Apr 2021 06:45:18 +0000
Subject: [PATCH v2 0/3] arm64: dts: meson: add support for MeCool
 KII-Pro/KIII-Pro
Message-ID: <20210402064521.30579-1-christianshewitt@gmail.com>

This series adds support for the MeCool (Videostrong) KII Pro (GXL)
and KIII Pro (GXM) Android STB devices. These are quite popular due
to the embedded multi-standard tuner card (which is sadly not-yet
supported in the kernel). Both devices closely follow the Amlogic
reference designs with keys/buttons/LED details taken from known-
working vendor kernel device-trees.

Testing was made by Drazen Spio via the LibreELEC forums [0] as I
don't own either device. Since dts files were added to LibreELEC
nightly test images I've seen the number of active installs grow
without reported issues.

[0] https://forum.libreelec.tv/thread/23590-nightbuild-on-mecool-kiii-pro/

Changes since v1:

- Rebased on khilman/v5.13/dt64
- Add ack on bindings from Rob
- Add reviewed-by(s) from Neil

Christian Hewitt (3):
  dt-bindings: arm: amlogic: add MeCool KII/KIII Pro bindings
  arm64: dts: meson: add initial device-tree for MeCool KII Pro
  arm64: dts: meson: add initial device-tree for MeCool KIII Pro

 .../devicetree/bindings/arm/amlogic.yaml      |   2 +
 arch/arm64/boot/dts/amlogic/Makefile          |   2 +
 .../meson-gxl-s905d-mecool-kii-pro.dts        |  86 +++++++++++++
 .../dts/amlogic/meson-gxm-mecool-kiii-pro.dts | 113 ++++++++++++++++++
 4 files changed, 203 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts

-- 
2.17.1



From christianshewitt at gmail.com  Fri Apr  2 07:45:19 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Fri,  2 Apr 2021 06:45:19 +0000
Subject: [PATCH v2 1/3] dt-bindings: arm: amlogic: add MeCool KII/KIII Pro
 bindings
In-Reply-To: <20210402064521.30579-1-christianshewitt@gmail.com>
References: <20210402064521.30579-1-christianshewitt@gmail.com>
Message-ID: <20210402064521.30579-2-christianshewitt@gmail.com>

Add the board bindings for the MeCool (Videostrong Technology Co., Ltd)
KII-Pro (S905D) and KIII-Pro (S912) devices.

Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index d24334e1e166..97fb96266344 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -109,6 +109,7 @@ properties:
               - libretech,aml-s905d-pc
               - phicomm,n1
               - smartlabs,sml5442tw
+              - videostrong,gxl-kii-pro
           - const: amlogic,s905d
           - const: amlogic,meson-gxl
 
@@ -123,6 +124,7 @@ properties:
               - minix,neo-u9h
               - nexbox,a1
               - tronsmart,vega-s96
+              - videostrong,gxm-kiii-pro
               - wetek,core2
           - const: amlogic,s912
           - const: amlogic,meson-gxm
-- 
2.17.1



From christianshewitt at gmail.com  Fri Apr  2 07:45:20 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Fri,  2 Apr 2021 06:45:20 +0000
Subject: [PATCH v2 2/3] arm64: dts: meson: add initial device-tree for MeCool
 KII Pro
In-Reply-To: <20210402064521.30579-1-christianshewitt@gmail.com>
References: <20210402064521.30579-1-christianshewitt@gmail.com>
Message-ID: <20210402064521.30579-3-christianshewitt@gmail.com>

MeCool (Videostrong) KII Pro is based on the Amlogic P230 reference
board with an S905D chip and the following specs:

- 2GB DDR3 RAM
- 16GB eMMC
- 10/100 Base-T Ethernet
- BCM4335 Wireless (802.11 b/g/n/ac, BT 4.0)
- DVB-C/T/T2/S/S2 (AVL6862TA demod + R848 tuner)
- HDMI 2.0a video
- S/PDIF optical output
- CVBS/Analogue output
- 4x USB 2.0 ports
- IR receiver
- 1x Power button (with integrated blue LED)
- 1x micro SD card slot

Tested-by: Drazen Spio <drazsp at gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
---
 arch/arm64/boot/dts/amlogic/Makefile          |  1 +
 .../meson-gxl-s905d-mecool-kii-pro.dts        | 86 +++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts

diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index aebd49c88719..f8f515c93055 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-libretech-cc.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-libretech-cc-v2.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-nexbox-a95x.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-mecool-kii-pro.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-phicomm-n1.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts
new file mode 100644
index 000000000000..5ab5d3aa0646
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/*
+ * Author: Christian Hewitt <christianshewitt at gmail.com>
+ */
+
+/dts-v1/;
+
+#include "meson-gxl-s905d.dtsi"
+#include "meson-gx-p23x-q20x.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	compatible = "videostrong,gxl-kii-pro", "amlogic,s905d", "amlogic,meson-gxl";
+	model = "MeCool KII Pro";
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1710000>;
+
+		button-function {
+			label = "Update";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <10000>;
+		};
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		poll-interval = <100>;
+
+		button at 0 {
+			label = "power";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		blue {
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_POWER;
+			gpios = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+			panic-indicator;
+		};
+	};
+};
+
+&ethmac {
+	phy-mode = "rmii";
+	phy-handle = <&internal_phy>;
+};
+
+&ir {
+	linux,rc-map-name = "rc-mecool-kii-pro";
+};
+
+&sd_emmc_a {
+	brcmf: wifi at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
+};
+
+&uart_A {
+	status = "okay";
+	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+	pinctrl-names = "default";
+	uart-has-rtscts;
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+		max-speed = <2000000>;
+		clocks = <&wifi32k>;
+		clock-names = "lpo";
+	};
+};
-- 
2.17.1



From christianshewitt at gmail.com  Fri Apr  2 07:45:21 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Fri,  2 Apr 2021 06:45:21 +0000
Subject: [PATCH v2 3/3] arm64: dts: meson: add initial device-tree for MeCool
 KIII Pro
In-Reply-To: <20210402064521.30579-1-christianshewitt@gmail.com>
References: <20210402064521.30579-1-christianshewitt@gmail.com>
Message-ID: <20210402064521.30579-4-christianshewitt@gmail.com>

MeCool (Videostrong) KIII Pro is based on the Amlogic Q200 reference
board with an S912 chip and the following specs:

- 3GB DDR3 RAM
- 16GB eMMC
- 10/100/1000 Base-T Ethernet
- BCM4335 Wireless (802.11 b/g/n/ac, BT 4.0)
- DVB-C/T/T2/S/S2 (AVL6862TA demod + R912 tuner)
- HDMI 2.0a video
- S/PDIF optical output
- CVBS/Analogue output
- 4x USB 2.0 ports
- IR receiver
- 1x Power button (with integrated blue LED)
- 1x Update/Reset button (underside)
- 1x micro SD card slot

Tested-by: Drazen Spio <drazsp at gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
---
 arch/arm64/boot/dts/amlogic/Makefile          |   1 +
 .../dts/amlogic/meson-gxm-mecool-kiii-pro.dts | 113 ++++++++++++++++++
 2 files changed, 114 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts

diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index f8f515c93055..a58ccecfcb55 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905w-p281.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905w-tx3-mini.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-libretech-pc.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-khadas-vim2.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-mecool-kiii-pro.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-minix-neo-u9h.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts
new file mode 100644
index 000000000000..0651756d7fb5
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/*
+ * Author: Christian Hewitt <christianshewitt at gmail.com>
+ */
+
+/dts-v1/;
+
+#include "meson-gxm.dtsi"
+#include "meson-gx-p23x-q20x.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	compatible = "videostrong,gxm-kiii-pro", "amlogic,s912", "amlogic,meson-gxm";
+	model = "MeCool KIII Pro";
+
+	memory at 0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0xC0000000>;
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1710000>;
+
+		button-function {
+			label = "Update";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <10000>;
+		};
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		poll-interval = <100>;
+
+		button at 0 {
+			label = "power";
+			linux,code = <KEY_POWER>;
+			gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		blue {
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_POWER;
+			gpios = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+			panic-indicator;
+		};
+	};
+};
+
+&ethmac {
+	pinctrl-0 = <&eth_pins>;
+	pinctrl-names = "default";
+
+	phy-handle = <&external_phy>;
+
+	amlogic,tx-delay-ns = <2>;
+
+	phy-mode = "rgmii";
+};
+
+&external_mdio {
+	external_phy: ethernet-phy at 0 {
+		/* Realtek RTL8211F (0x001cc916) */
+		reg = <0>;
+		max-speed = <1000>;
+
+		reset-assert-us = <10000>;
+		reset-deassert-us = <80000>;
+		reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
+
+		interrupt-parent = <&gpio_intc>;
+		/* MAC_INTR on GPIOZ_15 */
+		interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&ir {
+	linux,rc-map-name = "rc-mecool-kiii-pro";
+};
+
+&sd_emmc_a {
+	brcmf: wifi at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
+};
+
+&uart_A {
+	status = "okay";
+	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+	pinctrl-names = "default";
+	uart-has-rtscts;
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+		max-speed = <2000000>;
+		clocks = <&wifi32k>;
+		clock-names = "lpo";
+	};
+};
-- 
2.17.1



From xuwei5 at hisilicon.com  Fri Apr  2 08:28:47 2021
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 2 Apr 2021 15:28:47 +0800
Subject: [PATCH v4 1/1] arm64: dts: correct vendor prefix hisi to hisilicon
In-Reply-To: <20210302113351.1204-2-thunder.leizhen@huawei.com>
References: <20210302113351.1204-1-thunder.leizhen@huawei.com>
 <20210302113351.1204-2-thunder.leizhen@huawei.com>
Message-ID: <6066C7AF.7030304@hisilicon.com>

Hi Zhen Lei,

On 2021/3/2 19:33, Zhen Lei wrote:
> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
> stated in "vendor-prefixes.yaml".
> 
> Fixes: a4e36ae0fb33 ("arm64: dts: hi3660: add resources for clock and reset")
> Fixes: 757a4b2913eb ("arm64: dts: hisilicon: hi3670: Add reset controller support")
> Fixes: 305656e0989d ("arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst")
> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
> Cc: Zhangfei Gao <zhangfei.gao at linaro.org>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
> Cc: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Thanks!
Applied to the hisilicon arm64 dt tree.

Best Regards,
Wei

> ---
>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
>  arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> index cab89dc6f596121..8b8d3d07b67fe84 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
> @@ -345,7 +345,7 @@
>  		crg_rst: crg_rst_controller {
>  			compatible = "hisilicon,hi3660-reset";
>  			#reset-cells = <2>;
> -			hisi,rst-syscon = <&crg_ctrl>;
> +			hisilicon,rst-syscon = <&crg_ctrl>;
>  		};
>  
>  
> @@ -376,7 +376,7 @@
>  
>  		iomcu_rst: reset {
>  			compatible = "hisilicon,hi3660-reset";
> -			hisi,rst-syscon = <&iomcu>;
> +			hisilicon,rst-syscon = <&iomcu>;
>  			#reset-cells = <2>;
>  		};
>  
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> index 8830795c8efc5a5..37409f0639628d0 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi3670.dtsi
> @@ -155,7 +155,7 @@
>  			compatible = "hisilicon,hi3670-reset",
>  				     "hisilicon,hi3660-reset";
>  			#reset-cells = <2>;
> -			hisi,rst-syscon = <&crg_ctrl>;
> +			hisilicon,rst-syscon = <&crg_ctrl>;
>  		};
>  
>  		pctrl: pctrl at e8a09000 {
> @@ -196,7 +196,7 @@
>  
>  		iomcu_rst: reset {
>  			compatible = "hisilicon,hi3660-reset";
> -			hisi,rst-syscon = <&iomcu>;
> +			hisilicon,rst-syscon = <&iomcu>;
>  			#reset-cells = <2>;
>  		};
>  
> 


From nicolas.ferre at microchip.com  Fri Apr  2 08:32:01 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Fri, 2 Apr 2021 09:32:01 +0200
Subject: [PATCH] power: reset: at91-reset: free resources on exit path
In-Reply-To: <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
References: <20210209110109.906034-1-claudiu.beznea@microchip.com>
 <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
 <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
Message-ID: <f9519a82-4fce-13ac-f51e-8364bc5f8694@microchip.com>

On 01/04/2021 at 16:42, Claudiu Beznea - M18063 wrote:
>>> +unmap:
>>> +??? iounmap(reset->rstc_base);
>>> +??? for (idx = 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>>> +??????? iounmap(reset->ramc_base[idx]);
>> But if we keep this loop, I have the feeling that some kind of
>> "of_node_put()" is needed as well.
> No! In the loop:
> 
> for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
> 	reset->ramc_lpr = (u32)match->data;
> 	reset->ramc_base[idx] = of_iomap(np, 0);
> 	if (!reset->ramc_base[idx]) {
> 		dev_err(&pdev->dev, "Could not map ram controller address\n");
> 		of_node_put(np);
> 		ret = -ENODEV;
> 		goto unmap;
> 	}
> 	idx++;
> }
> 
> the of_node_put() is needed only if the loop is interrupted as the macro:
> for_each_matching_node_and_match() is defined as follows:
> 
> #define for_each_matching_node_and_match(dn, matches, match) \
> 	for (dn = of_find_matching_node_and_match(NULL, matches, match); \
> 	     dn; dn = of_find_matching_node_and_match(dn, matches, match))
> 
> and of_find_matching_node_and_match() will return a np with refcount
> incremented but at the next loop step the of_find_matching_node_and_match()
> will be called with the same np pointer and the np refcount will be
> decremented.
> 
> struct device_node *of_find_matching_node_and_match(
> 		struct device_node *from,
> 		const struct of_device_id *matches,
> 		const struct of_device_id **match)
> {
> 	// ...
> 	of_node_put(from);
> 	// ...
> }

Oh yes you're right Claudiu, I overlooked this one. Thanks for the 
in-depth explanation.

Best regards,
   Nicolas

-- 
Nicolas Ferre


From shc_work at mail.ru  Fri Apr  2 08:43:14 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:43:14 +0300
Subject: [PATCH RESEND 1/5] ARM: dts: clps711x: Add SYSCON nodes where it is
 used
Message-ID: <20210402074318.8582-1-shc_work@mail.ru>

This patch adds SYSCON descriptors to framebuffer, SPI, DAI
and modem control GPIO nodes to further rework these drivers
to remove the call to the syscon_regmap_lookup_by_compatible() function.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/ep7209.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/ep7209.dtsi b/arch/arm/boot/dts/ep7209.dtsi
index 365931f8b48d..dacbe0d8e67a 100644
--- a/arch/arm/boot/dts/ep7209.dtsi
+++ b/arch/arm/boot/dts/ep7209.dtsi
@@ -108,6 +108,7 @@ fb: fb at 800002c0 {
 			compatible = "cirrus,ep7209-fb";
 			reg = <0x800002c0 0xd44>, <0x60000000 0xc000>;
 			clocks = <&clks CLPS711X_CLK_BUS>;
+			syscon = <&syscon1>;
 			status = "disabled";
 		};
 
@@ -147,6 +148,7 @@ spi: spi at 80000500 {
 			reg = <0x80000500 0x4>;
 			interrupts = <15>;
 			clocks = <&clks CLPS711X_CLK_SPI>;
+			syscon = <&syscon3>;
 			status = "disabled";
 		};
 
@@ -170,6 +172,7 @@ dai: dai at 80002000 {
 			clocks = <&clks CLPS711X_CLK_PLL>;
 			clock-names = "pll";
 			interrupts = <32>;
+			syscon = <&syscon3>;
 			status = "disabled";
 		};
 
@@ -181,6 +184,7 @@ syscon3: syscon at 80002200 {
 
 	mctrl: mctrl {
 		compatible = "cirrus,ep7209-mctrl-gpio";
+		gpio,syscon-dev = <&syscon1 0 0>;
 		gpio-controller;
 		#gpio-cells = <2>;
 	};
-- 
2.26.2



From shc_work at mail.ru  Fri Apr  2 08:43:15 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:43:15 +0300
Subject: [PATCH RESEND 2/5] ARM: dts: clps711x: Add keypad node
In-Reply-To: <20210402074318.8582-1-shc_work@mail.ru>
References: <20210402074318.8582-1-shc_work@mail.ru>
Message-ID: <20210402074318.8582-2-shc_work@mail.ru>

This adds missing keypad node to basic clps711x DT.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/ep7209.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/ep7209.dtsi b/arch/arm/boot/dts/ep7209.dtsi
index dacbe0d8e67a..02606547bdc5 100644
--- a/arch/arm/boot/dts/ep7209.dtsi
+++ b/arch/arm/boot/dts/ep7209.dtsi
@@ -182,6 +182,13 @@ syscon3: syscon at 80002200 {
 		};
 	};
 
+	keypad: keypad {
+		compatible = "cirrus,ep7209-keypad";
+		interrupts = <16>;
+		syscon = <&syscon1>;
+		status = "disabled";
+	};
+
 	mctrl: mctrl {
 		compatible = "cirrus,ep7209-mctrl-gpio";
 		gpio,syscon-dev = <&syscon1 0 0>;
-- 
2.26.2



From shc_work at mail.ru  Fri Apr  2 08:43:16 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:43:16 +0300
Subject: [PATCH RESEND 3/5] ARM: dts: clps711x: Fix serial port names
In-Reply-To: <20210402074318.8582-1-shc_work@mail.ru>
References: <20210402074318.8582-1-shc_work@mail.ru>
Message-ID: <20210402074318.8582-3-shc_work@mail.ru>

Preferred node name for serial ports is "serial".

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/ep7209.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ep7209.dtsi b/arch/arm/boot/dts/ep7209.dtsi
index 02606547bdc5..9350497c1805 100644
--- a/arch/arm/boot/dts/ep7209.dtsi
+++ b/arch/arm/boot/dts/ep7209.dtsi
@@ -133,7 +133,7 @@ pwm: pwm at 80000400 {
 			#pwm-cells = <1>;
 		};
 
-		uart1: uart at 80000480 {
+		uart1: serial at 80000480 {
 			compatible = "cirrus,ep7209-uart";
 			reg = <0x80000480 0x80>;
 			interrupts = <12 13>;
@@ -157,7 +157,7 @@ syscon2: syscon at 80001100 {
 			reg = <0x80001100 0x80>;
 		};
 
-		uart2: uart at 80001480 {
+		uart2: serial at 80001480 {
 			compatible = "cirrus,ep7209-uart";
 			reg = <0x80001480 0x80>;
 			interrupts = <28 29>;
-- 
2.26.2



From shc_work at mail.ru  Fri Apr  2 08:43:17 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:43:17 +0300
Subject: [PATCH RESEND 4/5] ARM: dts: clps711x: edb7211: Add unit-address to
 memory node
In-Reply-To: <20210402074318.8582-1-shc_work@mail.ru>
References: <20210402074318.8582-1-shc_work@mail.ru>
Message-ID: <20210402074318.8582-4-shc_work@mail.ru>

The memory node requires a unit-address, add it.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/ep7211-edb7211.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ep7211-edb7211.dts b/arch/arm/boot/dts/ep7211-edb7211.dts
index da076479c8e2..7fb532f227af 100644
--- a/arch/arm/boot/dts/ep7211-edb7211.dts
+++ b/arch/arm/boot/dts/ep7211-edb7211.dts
@@ -7,7 +7,7 @@ / {
 	model = "Cirrus Logic EP7211 Development Board";
 	compatible = "cirrus,edb7211", "cirrus,ep7211", "cirrus,ep7209";
 
-	memory {
+	memory at c0000000 {
 		device_type = "memory";
 		reg = <0xc0000000 0x02000000>;
 	};
-- 
2.26.2



From shc_work at mail.ru  Fri Apr  2 08:43:18 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:43:18 +0300
Subject: [PATCH RESEND 5/5] ARM: dts: clps711x: Add an empty chosen node to
 top level DTSI
In-Reply-To: <20210402074318.8582-1-shc_work@mail.ru>
References: <20210402074318.8582-1-shc_work@mail.ru>
Message-ID: <20210402074318.8582-5-shc_work@mail.ru>

Missing "chosen" node can cause issues when booting a kernel
with a boot-loader that doesn't create a chosen node if this
isn't present in the DTB since the decompressor relies on a
pre-existing chosen node to be available to insert the command
line and merge other ATAGS info.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/ep7209.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/ep7209.dtsi b/arch/arm/boot/dts/ep7209.dtsi
index 9350497c1805..40a277370fd0 100644
--- a/arch/arm/boot/dts/ep7209.dtsi
+++ b/arch/arm/boot/dts/ep7209.dtsi
@@ -10,6 +10,8 @@ / {
 	model = "Cirrus Logic EP7209";
 	compatible = "cirrus,ep7209";
 
+	chosen { };
+
 	aliases {
 		gpio0 = &porta;
 		gpio1 = &portb;
-- 
2.26.2



From xuwei5 at hisilicon.com  Fri Apr  2 08:44:10 2021
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Fri, 2 Apr 2021 15:44:10 +0800
Subject: [PATCH] ARM: hisi: use the correct HiSilicon copyright
In-Reply-To: <1617087100-20949-1-git-send-email-fanghao11@huawei.com>
References: <1617087100-20949-1-git-send-email-fanghao11@huawei.com>
Message-ID: <6066CB4A.4060504@hisilicon.com>

Hi Hao Fang,

On 2021/3/30 14:51, Hao Fang wrote:
> s/Hisilicon/HiSilicon/
> It should use capital S, according to
> https://www.hisilicon.com/en/terms-of-use.
> 
> Signed-off-by: Hao Fang <fanghao11 at huawei.com>

Thanks!
Applied to the hisilicon arm32 SoC tree.

Best Regards,
Wei

> ---
>  arch/arm/mach-hisi/hisilicon.c | 4 ++--
>  arch/arm/mach-hisi/hotplug.c   | 2 +-
>  arch/arm/mach-hisi/platmcpm.c  | 2 +-
>  arch/arm/mach-hisi/platsmp.c   | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
> index 07ea28b..b8d14b3 100644
> --- a/arch/arm/mach-hisi/hisilicon.c
> +++ b/arch/arm/mach-hisi/hisilicon.c
> @@ -1,8 +1,8 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * (Hisilicon's SoC based) flattened device tree enabled machine
> + * (HiSilicon's SoC based) flattened device tree enabled machine
>   *
> - * Copyright (c) 2012-2013 Hisilicon Ltd.
> + * Copyright (c) 2012-2013 HiSilicon Ltd.
>   * Copyright (c) 2012-2013 Linaro Ltd.
>   *
>   * Author: Haojian Zhuang <haojian.zhuang at linaro.org>
> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
> index 5c5f255..c517941 100644
> --- a/arch/arm/mach-hisi/hotplug.c
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013 Linaro Ltd.
> - * Copyright (c) 2013 Hisilicon Limited.
> + * Copyright (c) 2013 HiSilicon Limited.
>   */
>  
>  #include <linux/cpu.h>
> diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c
> index f155e32..96a4840 100644
> --- a/arch/arm/mach-hisi/platmcpm.c
> +++ b/arch/arm/mach-hisi/platmcpm.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013-2014 Linaro Ltd.
> - * Copyright (c) 2013-2014 Hisilicon Limited.
> + * Copyright (c) 2013-2014 HiSilicon Limited.
>   */
>  #include <linux/init.h>
>  #include <linux/smp.h>
> diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
> index da7a09c..a56cc64 100644
> --- a/arch/arm/mach-hisi/platsmp.c
> +++ b/arch/arm/mach-hisi/platsmp.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (c) 2013 Linaro Ltd.
> - * Copyright (c) 2013 Hisilicon Limited.
> + * Copyright (c) 2013 HiSilicon Limited.
>   * Based on arch/arm/mach-vexpress/platsmp.c, Copyright (C) 2002 ARM Ltd.
>   */
>  #include <linux/smp.h>
> 


From weifeng.voon at intel.com  Fri Apr  2 08:45:04 2021
From: weifeng.voon at intel.com (Voon, Weifeng)
Date: Fri, 2 Apr 2021 07:45:04 +0000
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <20210401151044.GZ1463@shell.armlinux.org.uk>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
 <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
 <20210401151044.GZ1463@shell.armlinux.org.uk>
Message-ID: <SN6PR11MB3136F7A7ACA1A5C324031607887A9@SN6PR11MB3136.namprd11.prod.outlook.com>

> > +	/* 2.5G mode only support 2500baseT full duplex only */
> > +	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > +		phylink_set(mac_supported, 2500baseT_Full);
> > +		phylink_set(mask, 10baseT_Half);
> > +		phylink_set(mask, 10baseT_Full);
> > +		phylink_set(mask, 100baseT_Half);
> > +		phylink_set(mask, 100baseT_Full);
> > +		phylink_set(mask, 1000baseT_Half);
> > +		phylink_set(mask, 1000baseT_Full);
> > +		phylink_set(mask, 1000baseKX_Full);
> 
> Why? This seems at odds to the comment above?

> What about 2500baseX_Full ?

The comments explain that the PCS<->PHY link is in 2500BASE-X
and why 10/100/1000 link speed is mutually exclusive with 2500.
But the connected external PHY are twisted pair cable which only
supports 2500baseT_full.

Weifeng


From shc_work at mail.ru  Fri Apr  2 08:53:54 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:53:54 +0300
Subject: [PATCH RESEND 1/2] ARM: dts: imx6q-icore-rqs: Drop redundant "fsl,
 mode" option
Message-ID: <20210402075355.9190-1-shc_work@mail.ru>

The operating mode is used for the AC97 interface only,
so lets drop the excess fsl,mode item from SSI node.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
index a4217f564a53..67b2dd510981 100644
--- a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
@@ -225,7 +225,6 @@ &pcie {
 };
 
 &ssi1 {
-	fsl,mode = "i2s-slave";
 	status = "okay";
 };
 
-- 
2.26.2



From shc_work at mail.ru  Fri Apr  2 08:53:55 2021
From: shc_work at mail.ru (Alexander Shiyan)
Date: Fri,  2 Apr 2021 10:53:55 +0300
Subject: [PATCH RESEND 2/2] ARM: dts: imx6q-icore: Drop redundant "fsl,
 mode" option
In-Reply-To: <20210402075355.9190-1-shc_work@mail.ru>
References: <20210402075355.9190-1-shc_work@mail.ru>
Message-ID: <20210402075355.9190-2-shc_work@mail.ru>

The operating mode is used for the AC97 interface only,
so lets drop the excess fsl,mode item from SSI node.

Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
---
 arch/arm/boot/dts/imx6qdl-icore.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 23c318d9636f..7ed853e33eca 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -252,7 +252,6 @@ &pwm3 {
 };
 
 &ssi1 {
-	fsl,mode = "i2s-slave";
 	status = "okay";
 };
 
-- 
2.26.2



From lkp at intel.com  Fri Apr  2 09:02:59 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 16:02:59 +0800
Subject: [xlnx:xlnx_rebase_v5.4 16/1701]
 drivers/mtd/nand/raw/nand_onfi.c:297:26: sparse: sparse: cast to restricted
 __le16
Message-ID: <202104021656.IioTEnaK-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 535b606b074de913935e28235504c248c657f9ea [16/1701] mtd: rawnand: Add jedec_id to struct onfi_params
config: x86_64-randconfig-s021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-279-g6d5d9b42-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/535b606b074de913935e28235504c248c657f9ea
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 535b606b074de913935e28235504c248c657f9ea
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/mtd/nand/raw/nand_onfi.c:297:26: sparse: sparse: cast to restricted __le16

vim +297 drivers/mtd/nand/raw/nand_onfi.c

   136	
   137	/*
   138	 * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise.
   139	 */
   140	int nand_onfi_detect(struct nand_chip *chip)
   141	{
   142		struct mtd_info *mtd = nand_to_mtd(chip);
   143		struct nand_memory_organization *memorg;
   144		struct nand_onfi_params *p;
   145		struct onfi_params *onfi;
   146		int onfi_version = 0;
   147		char id[4];
   148		int i, ret, val;
   149	
   150		memorg = nanddev_get_memorg(&chip->base);
   151	
   152		/* Try ONFI for unknown chip or LP */
   153		ret = nand_readid_op(chip, 0x20, id, sizeof(id));
   154		if (ret || strncmp(id, "ONFI", 4))
   155			return 0;
   156	
   157		/* ONFI chip: allocate a buffer to hold its parameter page */
   158		p = kzalloc((sizeof(*p) * 3), GFP_KERNEL);
   159		if (!p)
   160			return -ENOMEM;
   161	
   162		ret = nand_read_param_page_op(chip, 0, NULL, 0);
   163		if (ret) {
   164			ret = 0;
   165			goto free_onfi_param_page;
   166		}
   167	
   168		for (i = 0; i < 3; i++) {
   169			ret = nand_read_data_op(chip, &p[i], sizeof(*p), true);
   170			if (ret) {
   171				ret = 0;
   172				goto free_onfi_param_page;
   173			}
   174	
   175			if (onfi_crc16(ONFI_CRC_BASE, (u8 *)&p[i], 254) ==
   176					le16_to_cpu(p->crc)) {
   177				if (i)
   178					memcpy(p, &p[i], sizeof(*p));
   179				break;
   180			}
   181		}
   182	
   183		if (i == 3) {
   184			const void *srcbufs[3] = {p, p + 1, p + 2};
   185	
   186			pr_warn("Could not find a valid ONFI parameter page, trying bit-wise majority to recover it\n");
   187			nand_bit_wise_majority(srcbufs, ARRAY_SIZE(srcbufs), p,
   188					       sizeof(*p));
   189	
   190			if (onfi_crc16(ONFI_CRC_BASE, (u8 *)p, 254) !=
   191					le16_to_cpu(p->crc)) {
   192				pr_err("ONFI parameter recovery failed, aborting\n");
   193				goto free_onfi_param_page;
   194			}
   195		}
   196	
   197		if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
   198		    chip->manufacturer.desc->ops->fixup_onfi_param_page)
   199			chip->manufacturer.desc->ops->fixup_onfi_param_page(chip, p);
   200	
   201		/* Check version */
   202		val = le16_to_cpu(p->revision);
   203		if (val & ONFI_VERSION_2_3)
   204			onfi_version = 23;
   205		else if (val & ONFI_VERSION_2_2)
   206			onfi_version = 22;
   207		else if (val & ONFI_VERSION_2_1)
   208			onfi_version = 21;
   209		else if (val & ONFI_VERSION_2_0)
   210			onfi_version = 20;
   211		else if (val & ONFI_VERSION_1_0)
   212			onfi_version = 10;
   213	
   214		if (!onfi_version) {
   215			pr_info("unsupported ONFI version: %d\n", val);
   216			goto free_onfi_param_page;
   217		}
   218	
   219		sanitize_string(p->manufacturer, sizeof(p->manufacturer));
   220		sanitize_string(p->model, sizeof(p->model));
   221		chip->parameters.model = kstrdup(p->model, GFP_KERNEL);
   222		if (!chip->parameters.model) {
   223			ret = -ENOMEM;
   224			goto free_onfi_param_page;
   225		}
   226	
   227		memorg->pagesize = le32_to_cpu(p->byte_per_page);
   228		mtd->writesize = memorg->pagesize;
   229	
   230		/*
   231		 * pages_per_block and blocks_per_lun may not be a power-of-2 size
   232		 * (don't ask me who thought of this...). MTD assumes that these
   233		 * dimensions will be power-of-2, so just truncate the remaining area.
   234		 */
   235		memorg->pages_per_eraseblock =
   236				1 << (fls(le32_to_cpu(p->pages_per_block)) - 1);
   237		mtd->erasesize = memorg->pages_per_eraseblock * memorg->pagesize;
   238	
   239		memorg->oobsize = le16_to_cpu(p->spare_bytes_per_page);
   240		mtd->oobsize = memorg->oobsize;
   241	
   242		memorg->luns_per_target = p->lun_count;
   243		memorg->planes_per_lun = 1 << p->interleaved_bits;
   244	
   245		/* See erasesize comment */
   246		memorg->eraseblocks_per_lun =
   247			1 << (fls(le32_to_cpu(p->blocks_per_lun)) - 1);
   248		memorg->max_bad_eraseblocks_per_lun = le32_to_cpu(p->blocks_per_lun);
   249		memorg->bits_per_cell = p->bits_per_cell;
   250	
   251		if (le16_to_cpu(p->features) & ONFI_FEATURE_16_BIT_BUS)
   252			chip->options |= NAND_BUSWIDTH_16;
   253	
   254		if (p->ecc_bits != 0xff) {
   255			chip->base.eccreq.strength = p->ecc_bits;
   256			chip->base.eccreq.step_size = 512;
   257		} else if (onfi_version >= 21 &&
   258			(le16_to_cpu(p->features) & ONFI_FEATURE_EXT_PARAM_PAGE)) {
   259	
   260			/*
   261			 * The nand_flash_detect_ext_param_page() uses the
   262			 * Change Read Column command which maybe not supported
   263			 * by the chip->legacy.cmdfunc. So try to update the
   264			 * chip->legacy.cmdfunc now. We do not replace user supplied
   265			 * command function.
   266			 */
   267			nand_legacy_adjust_cmdfunc(chip);
   268	
   269			/* The Extended Parameter Page is supported since ONFI 2.1. */
   270			if (nand_flash_detect_ext_param_page(chip, p))
   271				pr_warn("Failed to detect ONFI extended param page\n");
   272		} else {
   273			pr_warn("Could not retrieve ONFI ECC requirements\n");
   274		}
   275	
   276		/* Save some parameters from the parameter page for future use */
   277		if (le16_to_cpu(p->opt_cmd) & ONFI_OPT_CMD_SET_GET_FEATURES) {
   278			chip->parameters.supports_set_get_features = true;
   279			bitmap_set(chip->parameters.get_feature_list,
   280				   ONFI_FEATURE_ADDR_TIMING_MODE, 1);
   281			bitmap_set(chip->parameters.set_feature_list,
   282				   ONFI_FEATURE_ADDR_TIMING_MODE, 1);
   283		}
   284	
   285		onfi = kzalloc(sizeof(*onfi), GFP_KERNEL);
   286		if (!onfi) {
   287			ret = -ENOMEM;
   288			goto free_model;
   289		}
   290	
   291		onfi->version = onfi_version;
   292		onfi->tPROG = le16_to_cpu(p->t_prog);
   293		onfi->tBERS = le16_to_cpu(p->t_bers);
   294		onfi->tR = le16_to_cpu(p->t_r);
   295		onfi->tCCS = le16_to_cpu(p->t_ccs);
   296		onfi->async_timing_mode = le16_to_cpu(p->async_timing_mode);
 > 297		onfi->jedec_id = le16_to_cpu(p->jedec_id);

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39318 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/247d3e31/attachment-0001.gz>

From zuoqilin1 at 163.com  Fri Apr  2 09:20:26 2021
From: zuoqilin1 at 163.com (zuoqilin1 at 163.com)
Date: Fri,  2 Apr 2021 16:20:26 +0800
Subject: [PATCH] arm/mm: Convert to DEFINE_SHOW_ATTRIBUTE
Message-ID: <20210402082026.568-1-zuoqilin1@163.com>

From: zuoqilin <zuoqilin at yulong.com>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: zuoqilin <zuoqilin at yulong.com>
---
 arch/arm/mm/ptdump_debugfs.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index 598b636..6a62bce 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -12,17 +12,7 @@ static int ptdump_show(struct seq_file *m, void *v)
 	return 0;
 }
 
-static int ptdump_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
-	.open		= ptdump_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
 
 void ptdump_debugfs_register(struct ptdump_info *info, const char *name)
 {
-- 
1.9.1




From lkp at intel.com  Fri Apr  2 09:43:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:43 +0800
Subject: [soc:broadcom/dt] BUILD SUCCESS
 dcb56d61d5a8acca0a357cc603397bc0272ce4cb
Message-ID: <6066d93f.ce7yZKHtjJQOxvew%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git broadcom/dt
branch HEAD: dcb56d61d5a8acca0a357cc603397bc0272ce4cb  ARM: dts: BCM5301X: Set Linksys EA9500 power LED

elapsed time: 1979m

configs tested: 289
configs skipped: 114

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                           se7705_defconfig
mips                         tb0219_defconfig
arm                     am200epdkit_defconfig
mips                           ip32_defconfig
sh                        sh7785lcr_defconfig
m68k                        stmark2_defconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
arm                           h5000_defconfig
m68k                         amcore_defconfig
arm                       spear13xx_defconfig
arm                           viper_defconfig
um                            kunit_defconfig
xtensa                  cadence_csp_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
m68k                        m5307c3_defconfig
mips                            gpr_defconfig
mips                        nlm_xlp_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
powerpc                     akebono_defconfig
arm                           corgi_defconfig
sh                             sh03_defconfig
sh                              ul2_defconfig
mips                        bcm63xx_defconfig
powerpc                 mpc836x_mds_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                         mpc30x_defconfig
arm                         vf610m4_defconfig
arm                          exynos_defconfig
h8300                    h8300h-sim_defconfig
xtensa                  nommu_kc705_defconfig
m68k                             alldefconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
xtensa                  audio_kc705_defconfig
arm                        vexpress_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
mips                malta_kvm_guest_defconfig
sh                        edosk7760_defconfig
sh                               allmodconfig
alpha                               defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arc                         haps_hs_defconfig
mips                          ath79_defconfig
arm                          collie_defconfig
mips                         cobalt_defconfig
m68k                         apollo_defconfig
arc                           tb10x_defconfig
arm                            dove_defconfig
arm                        multi_v7_defconfig
powerpc                  mpc866_ads_defconfig
powerpc               mpc834x_itxgp_defconfig
m68k                          atari_defconfig
x86_64                           alldefconfig
arm                  colibri_pxa300_defconfig
m68k                        mvme16x_defconfig
arm                       multi_v4t_defconfig
arm                         shannon_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                   motionpro_defconfig
arm                         axm55xx_defconfig
ia64                                defconfig
powerpc                      ppc6xx_defconfig
arm                         s5pv210_defconfig
powerpc                      ppc40x_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
sh                          r7780mp_defconfig
m68k                          sun3x_defconfig
ia64                         bigsur_defconfig
h8300                            alldefconfig
arm                         nhk8815_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
sh                          landisk_defconfig
xtensa                       common_defconfig
arm                      integrator_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
powerpc                 mpc836x_rdk_defconfig
sh                                  defconfig
m68k                                defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
sh                           se7722_defconfig
arm                          moxart_defconfig
mips                       capcella_defconfig
mips                    maltaup_xpa_defconfig
sh                     sh7710voipgw_defconfig
sh                          lboxre2_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                         cm_x300_defconfig
sh                   sh7724_generic_defconfig
powerpc                   lite5200b_defconfig
arm                          imote2_defconfig
mips                  maltasmvp_eva_defconfig
mips                           rs90_defconfig
arm                     eseries_pxa_defconfig
sh                           se7751_defconfig
arc                            hsdk_defconfig
powerpc                    ge_imp3a_defconfig
sh                         ap325rxa_defconfig
powerpc                     ep8248e_defconfig
arm                         orion5x_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
xtensa                    xip_kc705_defconfig
powerpc                        fsp2_defconfig
sh                        apsh4ad0a_defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
riscv                               defconfig
s390                                defconfig
arm                         socfpga_defconfig
powerpc                 linkstation_defconfig
ia64                            zx1_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
arm                          ixp4xx_defconfig
mips                     loongson1b_defconfig
sh                            shmin_defconfig
arm                       cns3420vb_defconfig
m68k                        mvme147_defconfig
mips                 decstation_r4k_defconfig
arm                              alldefconfig
mips                malta_qemu_32r6_defconfig
mips                           mtx1_defconfig
riscv                            alldefconfig
mips                       lemote2f_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc837x_rdb_defconfig
ia64                             allyesconfig
um                               allmodconfig
powerpc                     powernv_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
s390                             allyesconfig
powerpc64                        alldefconfig
arc                        nsimosci_defconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
mips                      malta_kvm_defconfig
powerpc                mpc7448_hpc2_defconfig
powerpc                 mpc85xx_cds_defconfig
ia64                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
parisc                              defconfig
parisc                           allyesconfig
i386                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:47 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:47 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 7d534c3a5e1f52022c889ed10c413c54ac2a4d0f
Message-ID: <6066d943.0kj0THzkukzW0o9t%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: 7d534c3a5e1f52022c889ed10c413c54ac2a4d0f  Merge tag 'v5.12-next-dts64' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/dt

elapsed time: 729m

configs tested: 151
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
powerpc                 mpc837x_rdb_defconfig
arm                     am200epdkit_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:56 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:56 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 ba87f2009edb69fa81d344c55bcee518b0707c98
Message-ID: <6066d94c.OpCNsVBbScFTUL+D%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: ba87f2009edb69fa81d344c55bcee518b0707c98  Merge tag 'socfpga_update_for_v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/drivers

elapsed time: 729m

configs tested: 168
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
arm                        trizeps4_defconfig
h8300                       h8s-sim_defconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
um                                allnoconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                        edosk7760_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
riscv                    nommu_k210_defconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:50 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:50 +0800
Subject: [soc:stm32/dt] BUILD SUCCESS 6ed9269265e10669d62280a869652dbe26f43ecb
Message-ID: <6066d946.U4nGcVH4O8N5US1M%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git stm32/dt
branch HEAD: 6ed9269265e10669d62280a869652dbe26f43ecb  ARM: dts: stm32: Add PTP clock to Ethernet controller

elapsed time: 1277m

configs tested: 231
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
arm                           h5000_defconfig
m68k                         amcore_defconfig
arm                       spear13xx_defconfig
arm                           viper_defconfig
um                            kunit_defconfig
xtensa                  cadence_csp_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
m68k                            q40_defconfig
arm                       netwinder_defconfig
powerpc                       ppc64_defconfig
xtensa                       common_defconfig
mips                 decstation_r4k_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
powerpc                 mpc836x_mds_defconfig
mips                             allmodconfig
riscv                          rv32_defconfig
mips                malta_kvm_guest_defconfig
sh                        edosk7760_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
m68k                         apollo_defconfig
arc                           tb10x_defconfig
arm                            dove_defconfig
arm                        multi_v7_defconfig
powerpc                  mpc866_ads_defconfig
powerpc               mpc834x_itxgp_defconfig
m68k                          atari_defconfig
x86_64                           alldefconfig
arm                          exynos_defconfig
mips                        nlm_xlp_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
sh                          r7780mp_defconfig
m68k                          sun3x_defconfig
ia64                         bigsur_defconfig
h8300                            alldefconfig
arm                         nhk8815_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
sh                          landisk_defconfig
arm                      integrator_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
powerpc                 mpc836x_rdk_defconfig
sh                                  defconfig
arm                           corgi_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                         cm_x300_defconfig
sh                   sh7724_generic_defconfig
powerpc                   lite5200b_defconfig
arm                          imote2_defconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                    ge_imp3a_defconfig
sh                         ap325rxa_defconfig
powerpc                     ep8248e_defconfig
arm                         orion5x_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
riscv                               defconfig
s390                                defconfig
arm                         socfpga_defconfig
powerpc                 linkstation_defconfig
ia64                            zx1_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
arm                          ixp4xx_defconfig
arm                       cns3420vb_defconfig
m68k                        mvme147_defconfig
arm                              alldefconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
powerpc                 mpc837x_rdb_defconfig
ia64                             allyesconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7751_defconfig
sh                             sh03_defconfig
riscv             nommu_k210_sdcard_defconfig
sh                            shmin_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
sh                              ul2_defconfig
powerpc64                        alldefconfig
arc                        nsimosci_defconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:03 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:03 +0800
Subject: [soc:tegra/soc] BUILD SUCCESS 366d7c643a8a9db652341e314b33d3fc80595e6c
Message-ID: <6066d953.cHDLHJb2zjep4Pqz%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/soc
branch HEAD: 366d7c643a8a9db652341e314b33d3fc80595e6c  soc/tegra: pmc: Print out domain name when reset fails to acquire

elapsed time: 9859m

configs tested: 507
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                     mpc5200_defconfig
arm                        shmobile_defconfig
powerpc                     ep8248e_defconfig
powerpc                     ksi8560_defconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
xtensa                          iss_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                        trizeps4_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
sh                               alldefconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
m68k                            q40_defconfig
mips                     loongson1c_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            migor_defconfig
mips                         cobalt_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
sh                           se7780_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
arm                          ixp4xx_defconfig
powerpc                          allmodconfig
powerpc                     akebono_defconfig
powerpc                    adder875_defconfig
arm                        multi_v7_defconfig
sh                                  defconfig
arm                      pxa255-idp_defconfig
arm                          iop32x_defconfig
powerpc                 mpc836x_mds_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
ia64                          tiger_defconfig
powerpc                         wii_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                     pseries_defconfig
arm                        mini2440_defconfig
mips                          ath25_defconfig
mips                          ath79_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
riscv                          rv32_defconfig
powerpc                       ebony_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
sparc                               defconfig
nds32                            alldefconfig
arc                     haps_hs_smp_defconfig
ia64                            zx1_defconfig
m68k                                defconfig
arm                          imote2_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
powerpc                      cm5200_defconfig
parisc                generic-64bit_defconfig
mips                             allmodconfig
riscv                             allnoconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
h8300                       h8s-sim_defconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
um                             i386_defconfig
powerpc                     sbc8548_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                          pxa3xx_defconfig
arm                       aspeed_g5_defconfig
sparc                            alldefconfig
mips                         tb0219_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
powerpc                 mpc834x_itx_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
ia64                             alldefconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
sh                             sh03_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
h8300                    h8300h-sim_defconfig
powerpc                      chrp32_defconfig
arm                            qcom_defconfig
arm                  colibri_pxa270_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
m68k                        mvme16x_defconfig
powerpc                     tqm8560_defconfig
arm                       multi_v4t_defconfig
arm                            mps2_defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
sh                          r7785rp_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
powerpc                   motionpro_defconfig
powerpc                     ppa8548_defconfig
powerpc                     tqm8541_defconfig
powerpc                 xes_mpc85xx_defconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
arm                       imx_v6_v7_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
mips                          malta_defconfig
powerpc                       eiger_defconfig
powerpc                  mpc885_ads_defconfig
arm                       aspeed_g4_defconfig
arm                       cns3420vb_defconfig
arm                      tct_hammer_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
sh                      rts7751r2d1_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
sparc                       sparc64_defconfig
sh                           se7705_defconfig
powerpc                     rainier_defconfig
mips                    maltaup_xpa_defconfig
mips                          rb532_defconfig
mips                 decstation_r4k_defconfig
powerpc                      walnut_defconfig
i386                             alldefconfig
arm                        vexpress_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                     tqm5200_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
powerpc                      ppc40x_defconfig
sh                        dreamcast_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
mips                       rbtx49xx_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
powerpc                 mpc8272_ads_defconfig
sh                           se7343_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
mips                           mtx1_defconfig
sh                             shx3_defconfig
xtensa                  cadence_csp_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                            shmin_defconfig
arc                         haps_hs_defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
arm                         mv78xx0_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     powernv_defconfig
um                               allyesconfig
xtensa                       common_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
x86_64                           alldefconfig
mips                           ci20_defconfig
powerpc                      ppc6xx_defconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
riscv                    nommu_virt_defconfig
arm                           corgi_defconfig
sh                        edosk7760_defconfig
powerpc                    mvme5100_defconfig
arm                           stm32_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
mips                          rm200_defconfig
sparc64                          alldefconfig
s390                             allyesconfig
nds32                             allnoconfig
riscv             nommu_k210_sdcard_defconfig
arc                      axs103_smp_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
um                               allmodconfig
mips                malta_kvm_guest_defconfig
m68k                             allyesconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a015-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a012-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:59 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:59 +0800
Subject: [soc:drivers/optee-memref] BUILD SUCCESS
 c650b8dc7a7910eb25af0aac1720f778b29e679d
Message-ID: <6066d94f.8/xua7pSDevICJB0%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/optee-memref
branch HEAD: c650b8dc7a7910eb25af0aac1720f778b29e679d  tee: optee: do not check memref size on return from Secure World

elapsed time: 4261m

configs tested: 326
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
m68k                           sun3_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                        trizeps4_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
arm                       imx_v6_v7_defconfig
sh                              ul2_defconfig
microblaze                      mmu_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
powerpc                 mpc837x_rdb_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         db1xxx_defconfig
arm                        cerfcube_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
mips                  cavium_octeon_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
mips                        vocore2_defconfig
sh                        edosk7705_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
mips                        workpad_defconfig
sh                           se7722_defconfig
arm                        shmobile_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            hp6xx_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
sparc64                             defconfig
powerpc                  storcenter_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
m68k                        stmark2_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                          lpd270_defconfig
arm                             pxa_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
arm                            qcom_defconfig
arm                            pleb_defconfig
arm                  colibri_pxa270_defconfig
powerpc                        icon_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
powerpc                     tqm8560_defconfig
powerpc                         ps3_defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
powerpc                     tqm8541_defconfig
arm                          gemini_defconfig
powerpc                 xes_mpc85xx_defconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
arm                       mainstone_defconfig
sh                          landisk_defconfig
arm                   milbeaut_m10v_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
powerpc                      makalu_defconfig
arm                        multi_v7_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                     davinci_all_defconfig
sh                                  defconfig
powerpc                      ep88xc_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
arm                          simpad_defconfig
powerpc                    sam440ep_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                         hackkit_defconfig
mips                           jazz_defconfig
arc                         haps_hs_defconfig
mips                      bmips_stb_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
mips                       rbtx49xx_defconfig
powerpc                   motionpro_defconfig
arm                         socfpga_defconfig
mips                malta_qemu_32r6_defconfig
arm                        keystone_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
powerpc                       maple_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
arm                            zeus_defconfig
m68k                       m5208evb_defconfig
mips                            ar7_defconfig
powerpc                     ksi8560_defconfig
powerpc                     ppa8548_defconfig
arm                     am200epdkit_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
parisc                           allyesconfig
mips                         cobalt_defconfig
riscv                               defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                               alldefconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                      ppc44x_defconfig
sh                   secureedge5410_defconfig
m68k                            mac_defconfig
powerpc                     skiroot_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
sparc                       sparc64_defconfig
powerpc                       eiger_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
arm                    vt8500_v6_v7_defconfig
mips                         tb0219_defconfig
powerpc                    socrates_defconfig
arm                         s5pv210_defconfig
riscv                    nommu_virt_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
mips                       capcella_defconfig
ia64                             allyesconfig
powerpc                      ppc40x_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
mips                           xway_defconfig
um                               allmodconfig
arm                      jornada720_defconfig
sparc64                          alldefconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
mips                malta_kvm_guest_defconfig
powerpc                       ebony_defconfig
sh                            migor_defconfig
mips                       lemote2f_defconfig
ia64                             allmodconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:06 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:06 +0800
Subject: [soc:mediatek/dt] BUILD SUCCESS
 562f818deaf0601f224999cc39b6c97fbb2adc57
Message-ID: <6066d956.IveX6jCFF2kgnEle%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
branch HEAD: 562f818deaf0601f224999cc39b6c97fbb2adc57  arm: mediatek: dts: activate SMP for mt6589

elapsed time: 4147m

configs tested: 293
configs skipped: 111

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                         s3c6400_defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
microblaze                      mmu_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
powerpc                 mpc837x_rdb_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
nios2                         3c120_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
xtensa                    xip_kc705_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
arm                        cerfcube_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
mips                  cavium_octeon_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
mips                        vocore2_defconfig
sh                        edosk7705_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                          lpd270_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
nios2                            alldefconfig
arm                            qcom_defconfig
arm                            pleb_defconfig
arm                  colibri_pxa270_defconfig
powerpc                        icon_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
powerpc                    amigaone_defconfig
x86_64                           alldefconfig
sparc64                             defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
m68k                           sun3_defconfig
powerpc                     tqm8541_defconfig
mips                        jmr3927_defconfig
arm                          gemini_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
arm                       imx_v6_v7_defconfig
mips                     cu1000-neo_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
h8300                               defconfig
arm                       mainstone_defconfig
sh                          landisk_defconfig
arm                   milbeaut_m10v_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
powerpc                      makalu_defconfig
arm                        multi_v7_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                        stmark2_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
powerpc                    sam440ep_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
sh                          rsk7201_defconfig
arm                         hackkit_defconfig
mips                           jazz_defconfig
arc                         haps_hs_defconfig
mips                      bmips_stb_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
powerpc                     tqm8560_defconfig
mips                       rbtx49xx_defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
nds32                               defconfig
powerpc                       maple_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
arm                            zeus_defconfig
m68k                       m5208evb_defconfig
mips                            ar7_defconfig
powerpc                     ksi8560_defconfig
powerpc                     ppa8548_defconfig
arm                     am200epdkit_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
parisc                           allyesconfig
mips                         cobalt_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                      ppc44x_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                      arches_defconfig
riscv                          rv32_defconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                    socrates_defconfig
riscv                    nommu_virt_defconfig
arm                         s5pv210_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
mips                       capcella_defconfig
ia64                             allyesconfig
powerpc                      ppc40x_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
riscv                    nommu_k210_defconfig
powerpc                     akebono_defconfig
s390                          debug_defconfig
mips                        maltaup_defconfig
mips                           xway_defconfig
powerpc                       ppc64_defconfig
um                               allmodconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
mips                malta_kvm_guest_defconfig
powerpc                       ebony_defconfig
sh                            migor_defconfig
mips                       lemote2f_defconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
riscv                               defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:54 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:54 +0800
Subject: [soc:omap/drivers] BUILD SUCCESS
 d995d3d025bbd2d89abf12418f20d19bc0cb0130
Message-ID: <6066d94a.Gg6LB1QP5Iu7p7te%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git omap/drivers
branch HEAD: d995d3d025bbd2d89abf12418f20d19bc0cb0130  bus: ti-sysc: Use kzalloc for allocating only one thing

elapsed time: 12695m

configs tested: 598
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                           ip28_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
powerpc                   currituck_defconfig
h8300                            alldefconfig
powerpc                     ksi8560_defconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                  mpc885_ads_defconfig
xtensa                         virt_defconfig
arm                           corgi_defconfig
powerpc64                           defconfig
sh                            titan_defconfig
powerpc                       maple_defconfig
powerpc                      obs600_defconfig
sparc64                             defconfig
arm                         assabet_defconfig
sh                         ecovec24_defconfig
powerpc                    ge_imp3a_defconfig
arm                        shmobile_defconfig
powerpc                      cm5200_defconfig
powerpc                         wii_defconfig
arm                      jornada720_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
arc                                 defconfig
sh                        edosk7760_defconfig
arm                             ezx_defconfig
riscv             nommu_k210_sdcard_defconfig
riscv                               defconfig
sh                           se7780_defconfig
m68k                        m5407c3_defconfig
mips                        qi_lb60_defconfig
mips                         tb0226_defconfig
arm                              alldefconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
sh                   secureedge5410_defconfig
arm                        cerfcube_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
powerpc                        icon_defconfig
arc                        nsimosci_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
m68k                            q40_defconfig
mips                     loongson1c_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            migor_defconfig
mips                         cobalt_defconfig
arm                      tct_hammer_defconfig
arm                             mxs_defconfig
mips                 decstation_r4k_defconfig
powerpc                    adder875_defconfig
sh                             sh03_defconfig
sh                           se7343_defconfig
powerpc                     mpc5200_defconfig
arm                          pxa3xx_defconfig
sh                          rsk7264_defconfig
csky                                defconfig
sh                     sh7710voipgw_defconfig
m68k                        stmark2_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
arc                        vdk_hs38_defconfig
um                           x86_64_defconfig
x86_64                              defconfig
powerpc                 xes_mpc85xx_defconfig
mips                          rb532_defconfig
powerpc                 mpc834x_mds_defconfig
arm                          moxart_defconfig
powerpc                     ep8248e_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
arm                          ixp4xx_defconfig
powerpc                          allmodconfig
powerpc                     akebono_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                          lpd270_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
powerpc                      ppc64e_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                 mpc836x_rdk_defconfig
arc                         haps_hs_defconfig
um                             i386_defconfig
arm                          badge4_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                           sh2007_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
mips                         tb0219_defconfig
sh                          r7780mp_defconfig
powerpc                     tqm8560_defconfig
sh                   rts7751r2dplus_defconfig
ia64                          tiger_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                        workpad_defconfig
sparc                            alldefconfig
m68k                        m5272c3_defconfig
mips                            e55_defconfig
um                                allnoconfig
mips                      bmips_stb_defconfig
mips                        maltaup_defconfig
arm                        mvebu_v7_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
powerpc                       ebony_defconfig
sh                          polaris_defconfig
sh                 kfr2r09-romimage_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
powerpc                         ps3_defconfig
parisc                generic-64bit_defconfig
mips                        vocore2_defconfig
mips                             allmodconfig
riscv                             allnoconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
sh                        dreamcast_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                       cns3420vb_defconfig
parisc                           alldefconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
ia64                            zx1_defconfig
powerpc                  mpc866_ads_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
mips                  cavium_octeon_defconfig
arm                       imx_v4_v5_defconfig
mips                         tb0287_defconfig
arm                           spitz_defconfig
mips                      maltaaprp_defconfig
arm                        spear3xx_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
m68k                          hp300_defconfig
s390                             allmodconfig
mips                        bcm63xx_defconfig
powerpc                      katmai_defconfig
arm                       imx_v6_v7_defconfig
arm                       aspeed_g5_defconfig
powerpc                 mpc834x_itx_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
nios2                         10m50_defconfig
nds32                             allnoconfig
arm                      pxa255-idp_defconfig
arm                            mps2_defconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
h8300                    h8300h-sim_defconfig
powerpc                      chrp32_defconfig
sh                                  defconfig
arm                            qcom_defconfig
mips                          ath25_defconfig
nios2                            alldefconfig
arm                  colibri_pxa270_defconfig
m68k                        mvme16x_defconfig
powerpc                   motionpro_defconfig
mips                     decstation_defconfig
sh                             espt_defconfig
m68k                                defconfig
arm                       multi_v4t_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
xtensa                  cadence_csp_defconfig
powerpc                        cell_defconfig
riscv                    nommu_virt_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
sh                          sdk7780_defconfig
arm                       netwinder_defconfig
powerpc                      bamboo_defconfig
mips                         mpc30x_defconfig
mips                       rbtx49xx_defconfig
powerpc                       eiger_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
arm                         palmz72_defconfig
h8300                       h8s-sim_defconfig
mips                      loongson3_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
arc                          axs103_defconfig
powerpc                     tqm5200_defconfig
powerpc                 linkstation_defconfig
csky                             alldefconfig
sparc                       sparc64_defconfig
m68k                             alldefconfig
alpha                               defconfig
arm                        multi_v5_defconfig
nds32                            alldefconfig
powerpc                      ep88xc_defconfig
mips                        omega2p_defconfig
mips                    maltaup_xpa_defconfig
m68k                             allmodconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
mips                           xway_defconfig
powerpc                 canyonlands_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
sh                           se7705_defconfig
powerpc                    klondike_defconfig
powerpc                 mpc8560_ads_defconfig
arm                          imote2_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
powerpc                      ppc40x_defconfig
sh                          sdk7786_defconfig
arm                           stm32_defconfig
sh                           se7721_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                     stx_gp3_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
arm                        vexpress_defconfig
arc                      axs103_smp_defconfig
mips                  maltasmvp_eva_defconfig
powerpc                 mpc8313_rdb_defconfig
sh                          r7785rp_defconfig
sh                            shmin_defconfig
powerpc                     pq2fads_defconfig
mips                        bcm47xx_defconfig
arm                         axm55xx_defconfig
ia64                        generic_defconfig
m68k                            mac_defconfig
powerpc                      ppc6xx_defconfig
arm                         mv78xx0_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
powerpc                     sbc8548_defconfig
powerpc                     pseries_defconfig
powerpc                     powernv_defconfig
um                               allyesconfig
xtensa                       common_defconfig
sh                           se7206_defconfig
powerpc                 mpc8315_rdb_defconfig
s390                       zfcpdump_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                            dove_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
mips                           ci20_defconfig
powerpc                 mpc8272_ads_defconfig
sh                      rts7751r2d1_defconfig
powerpc                  iss476-smp_defconfig
arm                           viper_defconfig
mips                           ip32_defconfig
arm                       mainstone_defconfig
s390                             allyesconfig
sparc64                          alldefconfig
mips                      pic32mzda_defconfig
s390                          debug_defconfig
arm                       versatile_defconfig
um                               allmodconfig
xtensa                    smp_lx200_defconfig
arm                            mmp2_defconfig
powerpc64                        alldefconfig
mips                malta_kvm_guest_defconfig
ia64                             allmodconfig
m68k                             allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a002-20210325
x86_64               randconfig-a003-20210325
x86_64               randconfig-a006-20210325
x86_64               randconfig-a001-20210325
x86_64               randconfig-a005-20210325
x86_64               randconfig-a004-20210325
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a003-20210323
i386                 randconfig-a004-20210323
i386                 randconfig-a001-20210323
i386                 randconfig-a002-20210323
i386                 randconfig-a006-20210323
i386                 randconfig-a005-20210323
i386                 randconfig-a003-20210325
i386                 randconfig-a004-20210325
i386                 randconfig-a001-20210325
i386                 randconfig-a002-20210325
i386                 randconfig-a006-20210325
i386                 randconfig-a005-20210325
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a004-20210324
i386                 randconfig-a003-20210324
i386                 randconfig-a001-20210324
i386                 randconfig-a002-20210324
i386                 randconfig-a006-20210324
i386                 randconfig-a005-20210324
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a012-20210324
x86_64               randconfig-a015-20210324
x86_64               randconfig-a014-20210324
x86_64               randconfig-a013-20210324
x86_64               randconfig-a016-20210324
x86_64               randconfig-a011-20210324
i386                 randconfig-a014-20210325
i386                 randconfig-a011-20210325
i386                 randconfig-a015-20210325
i386                 randconfig-a016-20210325
i386                 randconfig-a013-20210325
i386                 randconfig-a012-20210325
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210324
i386                 randconfig-a011-20210324
i386                 randconfig-a015-20210324
i386                 randconfig-a016-20210324
i386                 randconfig-a013-20210324
i386                 randconfig-a012-20210324
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
i386                 randconfig-a014-20210323
i386                 randconfig-a011-20210323
i386                 randconfig-a015-20210323
i386                 randconfig-a016-20210323
i386                 randconfig-a012-20210323
i386                 randconfig-a013-20210323
x86_64               randconfig-a002-20210323
x86_64               randconfig-a003-20210323
x86_64               randconfig-a006-20210323
x86_64               randconfig-a001-20210323
x86_64               randconfig-a004-20210323
x86_64               randconfig-a005-20210323
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210324
x86_64               randconfig-a003-20210324
x86_64               randconfig-a001-20210324
x86_64               randconfig-a006-20210324
x86_64               randconfig-a005-20210324
x86_64               randconfig-a004-20210324
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a012-20210325
x86_64               randconfig-a015-20210325
x86_64               randconfig-a014-20210325
x86_64               randconfig-a013-20210325
x86_64               randconfig-a011-20210325
x86_64               randconfig-a016-20210325
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a012-20210323
x86_64               randconfig-a015-20210323
x86_64               randconfig-a013-20210323
x86_64               randconfig-a014-20210323
x86_64               randconfig-a011-20210323
x86_64               randconfig-a016-20210323
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:43:40 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:43:40 +0800
Subject: [soc:tegra/dt-bindings] BUILD SUCCESS
 d1e24c46250731204dbf61b5191e4dcf2c2d9391
Message-ID: <6066d93c.V44dKp8IY7HPur+V%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/dt-bindings
branch HEAD: d1e24c46250731204dbf61b5191e4dcf2c2d9391  dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop

elapsed time: 12453m

configs tested: 613
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
mips                           ip28_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
powerpc                   currituck_defconfig
h8300                            alldefconfig
powerpc                     ksi8560_defconfig
powerpc                     mpc5200_defconfig
arm                        shmobile_defconfig
powerpc                     ep8248e_defconfig
um                               allyesconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      obs600_defconfig
arm                           h3600_defconfig
sh                        sh7785lcr_defconfig
arm                         hackkit_defconfig
powerpc                    klondike_defconfig
powerpc                     tqm8555_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                  mpc885_ads_defconfig
xtensa                         virt_defconfig
arm                           corgi_defconfig
powerpc64                           defconfig
sh                            titan_defconfig
powerpc                       maple_defconfig
sparc64                             defconfig
arm                         assabet_defconfig
sh                         ecovec24_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                      cm5200_defconfig
powerpc                         wii_defconfig
arm                      jornada720_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
xtensa                          iss_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
arm                           tegra_defconfig
arc                                 defconfig
sh                        edosk7760_defconfig
riscv             nommu_k210_sdcard_defconfig
riscv                               defconfig
sh                           se7780_defconfig
m68k                        m5407c3_defconfig
mips                        qi_lb60_defconfig
mips                         tb0226_defconfig
arm                              alldefconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
sh                   secureedge5410_defconfig
arm                        cerfcube_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                      tct_hammer_defconfig
arm                             mxs_defconfig
mips                 decstation_r4k_defconfig
powerpc                    adder875_defconfig
sh                             sh03_defconfig
sh                           se7343_defconfig
arm                          pxa3xx_defconfig
sh                          rsk7264_defconfig
csky                                defconfig
sh                     sh7710voipgw_defconfig
m68k                        stmark2_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
mips                          rb532_defconfig
nds32                            alldefconfig
powerpc                      chrp32_defconfig
arm                        mini2440_defconfig
sh                              ul2_defconfig
arc                        nsimosci_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
arm                          ixp4xx_defconfig
powerpc                          allmodconfig
powerpc                     akebono_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                          lpd270_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
powerpc                      ppc64e_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                        mvebu_v5_defconfig
xtensa                           alldefconfig
s390                          debug_defconfig
arc                      axs103_smp_defconfig
arm                        spear3xx_defconfig
powerpc                 mpc836x_rdk_defconfig
arc                         haps_hs_defconfig
um                             i386_defconfig
arm                          badge4_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
arm                       omap2plus_defconfig
riscv                    nommu_virt_defconfig
um                            kunit_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
sh                        sh7757lcr_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      acadia_defconfig
powerpc                        cell_defconfig
mips                      pic32mzda_defconfig
ia64                          tiger_defconfig
mips                         tb0219_defconfig
sh                          r7780mp_defconfig
powerpc                     tqm8560_defconfig
sh                   rts7751r2dplus_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                        workpad_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
m68k                        m5272c3_defconfig
mips                            e55_defconfig
um                                allnoconfig
mips                      bmips_stb_defconfig
mips                        maltaup_defconfig
arm                        mvebu_v7_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
powerpc                       ebony_defconfig
arc                     haps_hs_smp_defconfig
arm                      footbridge_defconfig
ia64                            zx1_defconfig
m68k                                defconfig
arm                          imote2_defconfig
sh                 kfr2r09-romimage_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
powerpc                         ps3_defconfig
parisc                generic-64bit_defconfig
sh                   sh7770_generic_defconfig
mips                        vocore2_defconfig
mips                             allmodconfig
riscv                             allnoconfig
mips                       capcella_defconfig
sh                        dreamcast_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                       cns3420vb_defconfig
parisc                           alldefconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
h8300                       h8s-sim_defconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
powerpc                     sbc8548_defconfig
arc                        vdk_hs38_defconfig
arm                         lubbock_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
mips                         tb0287_defconfig
microblaze                      mmu_defconfig
arm                           spitz_defconfig
mips                      maltaaprp_defconfig
arc                          axs101_defconfig
arm                       imx_v4_v5_defconfig
m68k                       m5249evb_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
openrisc                    or1ksim_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                     mpc512x_defconfig
s390                             allmodconfig
mips                        bcm63xx_defconfig
mips                           ip27_defconfig
mips                       rbtx49xx_defconfig
ia64                      gensparse_defconfig
mips                     loongson1c_defconfig
powerpc                      katmai_defconfig
arm                       imx_v6_v7_defconfig
arm                       aspeed_g5_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
powerpc                 mpc834x_itx_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
arm                             pxa_defconfig
ia64                             alldefconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
sh                                  defconfig
arm                            qcom_defconfig
mips                          ath25_defconfig
arm                  colibri_pxa270_defconfig
m68k                        mvme16x_defconfig
powerpc                   motionpro_defconfig
mips                     decstation_defconfig
sh                             espt_defconfig
arm                       multi_v4t_defconfig
arm                            mps2_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
m68k                       bvme6000_defconfig
xtensa                    smp_lx200_defconfig
mips                  cavium_octeon_defconfig
xtensa                  cadence_csp_defconfig
sh                          r7785rp_defconfig
powerpc                      arches_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
arm                       netwinder_defconfig
sh                          sdk7780_defconfig
mips                         mpc30x_defconfig
powerpc                       eiger_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
sh                      rts7751r2d1_defconfig
sh                            migor_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
arm                         palmz72_defconfig
mips                      loongson3_defconfig
m68k                            q40_defconfig
mips                     loongson1b_defconfig
powerpc                     tqm5200_defconfig
powerpc                 linkstation_defconfig
csky                             alldefconfig
mips                        nlm_xlp_defconfig
sparc                       sparc64_defconfig
sh                           se7705_defconfig
m68k                             alldefconfig
alpha                               defconfig
mips                       bmips_be_defconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
arm                        vexpress_defconfig
powerpc                 mpc85xx_cds_defconfig
mips                           xway_defconfig
arm                      pxa255-idp_defconfig
powerpc                 canyonlands_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                     eseries_pxa_defconfig
ia64                             allmodconfig
powerpc                      ppc6xx_defconfig
arm                       versatile_defconfig
powerpc                 mpc8560_ads_defconfig
sh                           se7724_defconfig
powerpc                      ppc40x_defconfig
mips                      fuloong2e_defconfig
sh                          sdk7786_defconfig
arm                           stm32_defconfig
sh                           se7721_defconfig
powerpc                     stx_gp3_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
xtensa                       common_defconfig
arm                            xcep_defconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc8272_ads_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
mips                  maltasmvp_eva_defconfig
m68k                          multi_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                     pq2fads_defconfig
mips                        bcm47xx_defconfig
arm                         axm55xx_defconfig
ia64                        generic_defconfig
m68k                            mac_defconfig
arm                         mv78xx0_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
powerpc                     pseries_defconfig
powerpc                     powernv_defconfig
arm                         cm_x300_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                            dove_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
mips                           ci20_defconfig
powerpc                    mvme5100_defconfig
arm                           viper_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
s390                             allyesconfig
nds32                             allnoconfig
um                               allmodconfig
powerpc64                        alldefconfig
mips                malta_kvm_guest_defconfig
m68k                             allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210325
x86_64               randconfig-a003-20210325
x86_64               randconfig-a006-20210325
x86_64               randconfig-a001-20210325
x86_64               randconfig-a005-20210325
x86_64               randconfig-a004-20210325
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a004-20210324
i386                 randconfig-a003-20210324
i386                 randconfig-a001-20210324
i386                 randconfig-a002-20210324
i386                 randconfig-a006-20210324
i386                 randconfig-a005-20210324
i386                 randconfig-a003-20210325
i386                 randconfig-a004-20210325
i386                 randconfig-a001-20210325
i386                 randconfig-a002-20210325
i386                 randconfig-a006-20210325
i386                 randconfig-a005-20210325
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a003-20210323
i386                 randconfig-a004-20210323
i386                 randconfig-a001-20210323
i386                 randconfig-a002-20210323
i386                 randconfig-a006-20210323
i386                 randconfig-a005-20210323
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210324
x86_64               randconfig-a015-20210324
x86_64               randconfig-a014-20210324
x86_64               randconfig-a013-20210324
x86_64               randconfig-a016-20210324
x86_64               randconfig-a011-20210324
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a014-20210325
i386                 randconfig-a011-20210325
i386                 randconfig-a015-20210325
i386                 randconfig-a016-20210325
i386                 randconfig-a013-20210325
i386                 randconfig-a012-20210325
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210324
i386                 randconfig-a011-20210324
i386                 randconfig-a015-20210324
i386                 randconfig-a016-20210324
i386                 randconfig-a013-20210324
i386                 randconfig-a012-20210324
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
i386                 randconfig-a014-20210323
i386                 randconfig-a011-20210323
i386                 randconfig-a015-20210323
i386                 randconfig-a016-20210323
i386                 randconfig-a012-20210323
i386                 randconfig-a013-20210323
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210324
x86_64               randconfig-a003-20210324
x86_64               randconfig-a001-20210324
x86_64               randconfig-a006-20210324
x86_64               randconfig-a005-20210324
x86_64               randconfig-a004-20210324
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210325
x86_64               randconfig-a015-20210325
x86_64               randconfig-a014-20210325
x86_64               randconfig-a013-20210325
x86_64               randconfig-a011-20210325
x86_64               randconfig-a016-20210325
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a012-20210323
x86_64               randconfig-a015-20210323
x86_64               randconfig-a013-20210323
x86_64               randconfig-a014-20210323
x86_64               randconfig-a011-20210323
x86_64               randconfig-a016-20210323
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From tan.shaopeng at fujitsu.com  Fri Apr  2 09:44:32 2021
From: tan.shaopeng at fujitsu.com (tan.shaopeng at fujitsu.com)
Date: Fri, 2 Apr 2021 08:44:32 +0000
Subject: [PATCH RFC] soc: fujitsu: Add cache driver code
In-Reply-To: <edaea436-d94e-d862-1136-66e9f881e0cc@arm.com>
References: <1614764303-34903-1-git-send-email-tan.shaopeng@jp.fujitsu.com>
 <1614764303-34903-2-git-send-email-tan.shaopeng@jp.fujitsu.com>
 <CAK8P3a0VUoixMKg5UmF8agAZUXoMT8_SbCiWBdStbZ+_yAYNjA@mail.gmail.com>
 <OSAPR01MB2146DC8A26F6EBD1CF11D9748B979@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <20210304104650.GA20843@willie-the-truck>
 <CAK8P3a2pFcNTw9NpRtQfYr7A5OcZ=As2kM0D_sbfFcGQ_J2Q+Q@mail.gmail.com>
 <OSAPR01MB21463C735D4A07344F35E7CC8B7C9@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <edaea436-d94e-d862-1136-66e9f881e0cc@arm.com>
Message-ID: <OSAPR01MB2146C20E39297D5DB347ACB48B7A9@OSAPR01MB2146.jpnprd01.prod.outlook.com>

Hi James Morse

> On 31/03/2021 09:52, tan.shaopeng at fujitsu.com wrote:
> >>> Given that all of this is outside of the scope of the architecture,
> >>> I don't think that arch/arm64/ is the right place for it. Perhaps
> >>> this would fit into the resctrl rework that James has been doing for
> MPAM?
> >>
> >> Indeed, that sounds like a good starting point. I don't understand
> >> enough about either of the two to be sure, but it sounds like there
> >> is some overlap in functionality, and ideally we would have one user
> >> interface that can deal with all the hardware implementations (intel, arm,
> fujitsu and any future ones).
> 
> > According to my study, it seems possible to add A64FX's sector cache
> > function to resctrl.
> 
> I think this depends on whether it maps to one of Intel RDT's existing schema.
> While adding new ones looks easy, it is bad for user-space as they are not
> portable between machines that support resctrl.

Thanks for your advice, I will try finding a way to add
the sector cache function in resctrl by using existing schema.

> > I heard you are working on resctrl rework for MPAM , but I cannot find
> > related patches on ML archive. Therefore, I would like to know the
> > status about MPAM support.
> 
> Its about five or six series that refactor resctrl inside arch/x86 to have a clear
> boundary between arch-specific code and the resctrl code that implements the
> filesystem, then pull it out to /fs/ and build the MPAM driver to make it work for
> arm64.
> 
> Unfortunately, its rather large (>100 patches), so will take some time to be
> reviewed.
> 
> 
> > (1) I think the first step is to support resctrl for ARM arch.
> >    Have you finished the work of arm support and when will you release it?
> 
> No-one wants a second copy of the code to implement resctrl, as this will
> introduce subtle bugs that user-space would have to work around, and make it
> harder to merge later.
> 
> The first step is to refactor the arch/x86 implementation of resctrl so that the
> parts that are visible to user-space can be moved somewhere that is common
> to multiple architectures.
> 
> I've posted the next chunk of that work here:
> https://lore.kernel.org/lkml/20210312175849.8327-1-james.morse at arm.com/
> 
> > (2) When will you release MPAM patch?
> 
> The latest complete version of the tree is here:
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpa
> m/snapshot/feb
> 
> It is over a year old, and has plenty of bugs.
> 
> I hope to push a newer version of the branch once I have a complete copy of the
> tree that has been tested, and is based on the current version of the ACPI table.

Thanks for your information. Let me see the patch.

Thanks, 
Tan Shaopeng

From lkp at intel.com  Fri Apr  2 09:44:26 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:26 +0800
Subject: [soc:tegra/dt] BUILD SUCCESS WITH WARNING
 3a6c267dd7b8822eb722835b503c5a438cbd3700
Message-ID: <6066d96a.1S1yL4EQJtaWPtEx%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/dt
branch HEAD: 3a6c267dd7b8822eb722835b503c5a438cbd3700  ARM: tegra: acer-a500: Add atmel,wakeup-method property

possible Warning in current branch:

arch/arm/boot/dts/tegra20-acer-a500-picasso.dt.yaml: touchscreen at 4c: 'atmel,wakeup-method' does not match any of the regexes: 'pinctrl-[0-9]+'

Warning ids grouped by kconfigs:

gcc_recent_errors
`-- arm-defconfig
    `-- arch-arm-boot-dts-tegra20-acer-a500-picasso.dt.yaml:touchscreen-4c:atmel-wakeup-method-does-not-match-any-of-the-regexes:pinctrl

elapsed time: 9565m

configs tested: 443
configs skipped: 114

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
m68k                           sun3_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
m68k                            q40_defconfig
mips                     loongson1c_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            migor_defconfig
mips                         cobalt_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
microblaze                      mmu_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
sh                ecovec24-romimage_defconfig
sh                           se7780_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
arc                    vdk_hs38_smp_defconfig
arm                       versatile_defconfig
arm                         mv78xx0_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
powerpc                       ebony_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
powerpc                      cm5200_defconfig
parisc                generic-64bit_defconfig
mips                             allmodconfig
xtensa                generic_kc705_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      ppc40x_defconfig
sh                   rts7751r2dplus_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
mips                            ar7_defconfig
powerpc                     ep8248e_defconfig
powerpc                          g5_defconfig
ia64                            zx1_defconfig
sh                            titan_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
mips                     cu1000-neo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
arm                          pxa3xx_defconfig
arm                       aspeed_g5_defconfig
sparc                            alldefconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
ia64                             alldefconfig
sh                             sh03_defconfig
arm                   milbeaut_m10v_defconfig
arm                        multi_v7_defconfig
m68k                       m5475evb_defconfig
sparc                            allyesconfig
arm                        vexpress_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
arm                       multi_v4t_defconfig
arm                            mps2_defconfig
powerpc                         ps3_defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                            qcom_defconfig
sh                          r7785rp_defconfig
arc                           tb10x_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
m68k                          atari_defconfig
riscv                    nommu_virt_defconfig
powerpc                        cell_defconfig
powerpc                   motionpro_defconfig
powerpc                     ppa8548_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
ia64                      gensparse_defconfig
arm                       imx_v6_v7_defconfig
m68k                       m5275evb_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
powerpc                       eiger_defconfig
arm                      tct_hammer_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
m68k                             alldefconfig
alpha                               defconfig
xtensa                  cadence_csp_defconfig
m68k                             allmodconfig
arc                          axs101_defconfig
powerpc                      chrp32_defconfig
mips                           xway_defconfig
arm                      pxa255-idp_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                       cns3420vb_defconfig
arm                          imote2_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
sh                        dreamcast_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
powerpc                     tqm8560_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                        clps711x_defconfig
arm                  colibri_pxa270_defconfig
powerpc                 mpc836x_mds_defconfig
mips                malta_qemu_32r6_defconfig
arm                        keystone_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7722_defconfig
xtensa                       common_defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
powerpc                 mpc8272_ads_defconfig
sh                           se7343_defconfig
sh                            shmin_defconfig
sh                        edosk7705_defconfig
sh                               alldefconfig
arc                         haps_hs_defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
arm                         palmz72_defconfig
alpha                            allyesconfig
powerpc                     mpc5200_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
sh                        edosk7760_defconfig
h8300                    h8300h-sim_defconfig
mips                      maltaaprp_defconfig
m68k                                defconfig
arm                          ixp4xx_defconfig
s390                       zfcpdump_defconfig
arm                    vt8500_v6_v7_defconfig
riscv                          rv32_defconfig
powerpc                      ppc6xx_defconfig
powerpc                         wii_defconfig
arm                         cm_x300_defconfig
arm                         s5pv210_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
powerpc                    mvme5100_defconfig
mips                           ci20_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
mips                   sb1250_swarm_defconfig
sh                           se7750_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arc                      axs103_smp_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
mips                        nlm_xlp_defconfig
um                               allmodconfig
mips                        omega2p_defconfig
powerpc                 mpc8315_rdb_defconfig
sh                           se7206_defconfig
mips                     cu1830-neo_defconfig
sparc                       sparc64_defconfig
mips                malta_kvm_guest_defconfig
arm                            zeus_defconfig
m68k                          multi_defconfig
ia64                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
s390                                defconfig
parisc                              defconfig
s390                             allmodconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a005-20210326
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a003-20210327
i386                 randconfig-a004-20210327
i386                 randconfig-a001-20210327
i386                 randconfig-a002-20210327
i386                 randconfig-a006-20210327
i386                 randconfig-a005-20210327
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
riscv                             allnoconfig
riscv                               defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:45:05 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:45:05 +0800
Subject: [soc:imx/dt64] BUILD SUCCESS 51c8eaa1b73e39d4f36a2a55ba5c68404b53fa78
Message-ID: <6066d991.EZj+ADBZ7f3RflrH%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/dt64
branch HEAD: 51c8eaa1b73e39d4f36a2a55ba5c68404b53fa78  arm64: dts: fsl-ls1028a-kontron-sl28: add rtc0 alias

elapsed time: 6125m

configs tested: 417
configs skipped: 121

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
xtensa                          iss_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
m68k                           sun3_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
sh                            titan_defconfig
arm                        trizeps4_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
arc                    vdk_hs38_smp_defconfig
arm                       versatile_defconfig
arm                         mv78xx0_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                     akebono_defconfig
powerpc                    adder875_defconfig
sh                         microdev_defconfig
arm                        multi_v7_defconfig
sh                                  defconfig
arm                      pxa255-idp_defconfig
arm                          iop32x_defconfig
powerpc                 mpc836x_mds_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                          pxa3xx_defconfig
um                               allmodconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
sh                        dreamcast_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
powerpc                  mpc866_ads_defconfig
powerpc                       ebony_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
h8300                     edosk2674_defconfig
sh                   sh7724_generic_defconfig
microblaze                          defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
parisc                generic-64bit_defconfig
m68k                        mvme147_defconfig
h8300                    h8300h-sim_defconfig
m68k                       m5475evb_defconfig
sparc                            allyesconfig
sh                ecovec24-romimage_defconfig
arm                        vexpress_defconfig
powerpc                      chrp32_defconfig
arm                            qcom_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
m68k                        mvme16x_defconfig
powerpc                     tqm8560_defconfig
arm                         lpc18xx_defconfig
powerpc                     rainier_defconfig
um                                  defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      cm5200_defconfig
openrisc                 simple_smp_defconfig
powerpc                        icon_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
powerpc                        cell_defconfig
riscv                    nommu_virt_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
mips                        jmr3927_defconfig
powerpc                 xes_mpc85xx_defconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
powerpc                  mpc885_ads_defconfig
arm                       cns3420vb_defconfig
arm                      tct_hammer_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
sh                               j2_defconfig
h8300                               defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
arm                         hackkit_defconfig
m68k                             alldefconfig
alpha                               defconfig
xtensa                  cadence_csp_defconfig
i386                             alldefconfig
sparc                       sparc64_defconfig
arc                          axs101_defconfig
mips                           xway_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
sh                          rsk7201_defconfig
powerpc                     tqm5200_defconfig
arm                  colibri_pxa270_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
powerpc                      ppc40x_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
arm                        clps711x_defconfig
powerpc                 mpc837x_mds_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
sh                           se7780_defconfig
xtensa                       common_defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
mips                      pistachio_defconfig
mips                        nlm_xlp_defconfig
powerpc                 mpc8272_ads_defconfig
sh                          kfr2r09_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
sh                               alldefconfig
sh                          r7780mp_defconfig
arc                         haps_hs_defconfig
mips                          malta_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
sh                         ap325rxa_defconfig
powerpc                     mpc5200_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
arm                      footbridge_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
arm                          ixp4xx_defconfig
powerpc                      bamboo_defconfig
powerpc                 mpc8315_rdb_defconfig
s390                       zfcpdump_defconfig
riscv                          rv32_defconfig
arm                         s5pv210_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
sh                        edosk7760_defconfig
powerpc                    mvme5100_defconfig
arm                   milbeaut_m10v_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
arm                       mainstone_defconfig
sh                           se7750_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arc                      axs103_smp_defconfig
powerpc                      ppc6xx_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
m68k                       m5249evb_defconfig
sh                           se7206_defconfig
mips                     cu1830-neo_defconfig
sh                            shmin_defconfig
sparc64                          alldefconfig
mips                malta_kvm_guest_defconfig
sh                            migor_defconfig
arm                            zeus_defconfig
m68k                          multi_defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
s390                                defconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
riscv                               defconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:50 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:50 +0800
Subject: [soc:tegra/dt64] BUILD SUCCESS
 405fa9e9d8664e830982c5fbcb70f9ba8656bafc
Message-ID: <6066d982.SXUJUxhU+RLzx7ro%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/dt64
branch HEAD: 405fa9e9d8664e830982c5fbcb70f9ba8656bafc  arm64: tegra: Move clocks from RT5658 endpoint to device node

elapsed time: 9860m

configs tested: 496
configs skipped: 146

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
sh                               alldefconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
arc                        nsimosci_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
m68k                            q40_defconfig
mips                     loongson1c_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            migor_defconfig
mips                         cobalt_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
sh                           se7780_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
arm                          moxart_defconfig
powerpc                     ep8248e_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
arm                          ixp4xx_defconfig
powerpc                          allmodconfig
powerpc                     akebono_defconfig
powerpc                    adder875_defconfig
arm                        multi_v7_defconfig
sh                                  defconfig
arm                      pxa255-idp_defconfig
arm                          iop32x_defconfig
powerpc                 mpc836x_mds_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
powerpc                      chrp32_defconfig
arm                       omap2plus_defconfig
riscv                    nommu_virt_defconfig
um                            kunit_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                           sh2007_defconfig
sh                          rsk7203_defconfig
sh                        sh7757lcr_defconfig
ia64                          tiger_defconfig
powerpc                         wii_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
powerpc                       ebony_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
sparc                               defconfig
nds32                            alldefconfig
arc                     haps_hs_smp_defconfig
arm                      footbridge_defconfig
ia64                            zx1_defconfig
m68k                                defconfig
arm                          imote2_defconfig
sh                          polaris_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
powerpc                      cm5200_defconfig
parisc                generic-64bit_defconfig
mips                             allmodconfig
riscv                             allnoconfig
arm                          pxa3xx_defconfig
mips                       capcella_defconfig
sh                        dreamcast_defconfig
xtensa                generic_kc705_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      ppc40x_defconfig
sh                   rts7751r2dplus_defconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
h8300                       h8s-sim_defconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
um                             i386_defconfig
powerpc                     sbc8548_defconfig
sh                            titan_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
arm                         lubbock_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
arm                       aspeed_g5_defconfig
sparc                            alldefconfig
mips                         tb0219_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
powerpc                 mpc834x_itx_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
mips                        workpad_defconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
powerpc                          allyesconfig
sh                             sh03_defconfig
arm                   milbeaut_m10v_defconfig
sh                           se7722_defconfig
h8300                    h8300h-sim_defconfig
m68k                       m5475evb_defconfig
arm                            qcom_defconfig
mips                          ath25_defconfig
nios2                            alldefconfig
arm                  colibri_pxa270_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                       multi_v4t_defconfig
arm                            mps2_defconfig
powerpc                     rainier_defconfig
um                                  defconfig
x86_64                           alldefconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
sh                          r7785rp_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
powerpc                        cell_defconfig
powerpc                   motionpro_defconfig
powerpc                     ppa8548_defconfig
powerpc                 xes_mpc85xx_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
arm                       imx_v6_v7_defconfig
mips                     cu1000-neo_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
powerpc                       eiger_defconfig
powerpc                  mpc885_ads_defconfig
arm                       cns3420vb_defconfig
arm                      tct_hammer_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
h8300                               defconfig
sh                      rts7751r2d1_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                      loongson3_defconfig
um                                allnoconfig
sparc                       sparc64_defconfig
sh                           se7705_defconfig
m68k                             alldefconfig
alpha                               defconfig
xtensa                  cadence_csp_defconfig
mips                     cu1830-neo_defconfig
mips                          rb532_defconfig
mips                 decstation_r4k_defconfig
m68k                             allmodconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
arm                        vexpress_defconfig
mips                           xway_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
arm                        oxnas_v6_defconfig
powerpc                     tqm5200_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
arm                          pcm027_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
powerpc                     tqm8560_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
xtensa                       common_defconfig
mips                        nlm_xlp_defconfig
powerpc                 mpc8272_ads_defconfig
sh                           se7343_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     mpc5200_defconfig
mips                           mtx1_defconfig
sh                             shx3_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                            shmin_defconfig
arm                        spear6xx_defconfig
arc                         haps_hs_defconfig
mips                          malta_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
arm                         palmz72_defconfig
arm                         mv78xx0_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
mips                  decstation_64_defconfig
powerpc                     powernv_defconfig
um                               allyesconfig
powerpc                       maple_defconfig
ia64                         bigsur_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
riscv                          rv32_defconfig
mips                           ci20_defconfig
powerpc                      ppc6xx_defconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
arm                           corgi_defconfig
arm                        trizeps4_defconfig
sh                        edosk7760_defconfig
arm                           stm32_defconfig
powerpc                         ps3_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
mips                          rm200_defconfig
sparc64                          alldefconfig
s390                             allyesconfig
nds32                             allnoconfig
riscv             nommu_k210_sdcard_defconfig
arc                      axs103_smp_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
mips                        jmr3927_defconfig
s390                          debug_defconfig
um                               allmodconfig
powerpc                  iss476-smp_defconfig
mips                malta_kvm_guest_defconfig
arm                            zeus_defconfig
m68k                          multi_defconfig
ia64                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nios2                            allyesconfig
csky                                defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:45:01 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:45:01 +0800
Subject: [soc:socfpga/dt] BUILD SUCCESS
 0501418e4439d4ba2644b9d9a52287002fbc7553
Message-ID: <6066d98d.GjkQfEUH6IV/uDKK%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git socfpga/dt
branch HEAD: 0501418e4439d4ba2644b9d9a52287002fbc7553  arm64: dts: intel: adjust qpsi read-delay property

elapsed time: 4147m

configs tested: 297
configs skipped: 137

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                         s3c6400_defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
microblaze                      mmu_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
powerpc                 mpc837x_rdb_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                       ppc64_defconfig
sh                           sh2007_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
arm                        cerfcube_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
mips                  cavium_octeon_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
mips                        vocore2_defconfig
sh                        edosk7705_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
sparc64                             defconfig
powerpc                  storcenter_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
m68k                        stmark2_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
mips                     cu1000-neo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                          lpd270_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
nios2                            alldefconfig
arm                            qcom_defconfig
arm                            pleb_defconfig
arm                  colibri_pxa270_defconfig
powerpc                        icon_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
m68k                          hp300_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
powerpc                     tqm8560_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
m68k                           sun3_defconfig
powerpc                     tqm8541_defconfig
arm                          gemini_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
arm                       imx_v6_v7_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                        magician_defconfig
arm                          exynos_defconfig
arm                       mainstone_defconfig
sh                          landisk_defconfig
arm                   milbeaut_m10v_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
powerpc                      makalu_defconfig
arm                        multi_v7_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
powerpc                    sam440ep_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                         hackkit_defconfig
mips                           jazz_defconfig
arc                         haps_hs_defconfig
mips                      bmips_stb_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
powerpc                   motionpro_defconfig
arm                         socfpga_defconfig
mips                malta_qemu_32r6_defconfig
arm                        keystone_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
powerpc                       maple_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
arm                     am200epdkit_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
parisc                           allyesconfig
mips                         cobalt_defconfig
riscv                               defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
powerpc                       eiger_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
mips                          malta_defconfig
arm                    vt8500_v6_v7_defconfig
riscv                          rv32_defconfig
mips                         tb0219_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                    socrates_defconfig
arm                         s5pv210_defconfig
riscv                    nommu_virt_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                       spear13xx_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
ia64                             allyesconfig
powerpc                      ppc40x_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
arm                      jornada720_defconfig
sparc                       sparc64_defconfig
sparc64                          alldefconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
mips                malta_kvm_guest_defconfig
powerpc                       ebony_defconfig
sh                            migor_defconfig
mips                       lemote2f_defconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:58 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:58 +0800
Subject: [soc:imx/dt] BUILD SUCCESS
 6634b2d252accd3fcdc94a5e0a1319009363892e
Message-ID: <6066d98a.3BENY8qE2McyxNSN%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/dt
branch HEAD: 6634b2d252accd3fcdc94a5e0a1319009363892e  dt-bindings: arm: fsl: Add the reMarkable 2 e-Ink tablet

elapsed time: 6126m

configs tested: 390
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
arm                         s3c6400_defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
arm                       aspeed_g4_defconfig
m68k                            q40_defconfig
m68k                        m5407c3_defconfig
arm                          pcm027_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
riscv                    nommu_k210_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      chrp32_defconfig
arm                       omap2plus_defconfig
um                            kunit_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
sh                        sh7757lcr_defconfig
powerpc                     pseries_defconfig
arm                        mini2440_defconfig
mips                          ath25_defconfig
mips                          ath79_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                        spear6xx_defconfig
arm                        oxnas_v6_defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
powerpc                       ppc64_defconfig
arm                         orion5x_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
arm                         shannon_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
h8300                     edosk2674_defconfig
sh                   sh7724_generic_defconfig
m68k                           sun3_defconfig
microblaze                          defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
parisc                generic-64bit_defconfig
m68k                        mvme147_defconfig
h8300                    h8300h-sim_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
sh                            titan_defconfig
powerpc                    amigaone_defconfig
x86_64                           alldefconfig
sparc64                             defconfig
powerpc                      cm5200_defconfig
openrisc                 simple_smp_defconfig
powerpc                        icon_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
riscv                    nommu_virt_defconfig
powerpc                        cell_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
arc                    vdk_hs38_smp_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arm                        multi_v7_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                         hackkit_defconfig
m68k                             alldefconfig
alpha                               defconfig
xtensa                  cadence_csp_defconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
sparc                       sparc64_defconfig
arc                          axs101_defconfig
mips                           xway_defconfig
arm                      pxa255-idp_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
arm                     eseries_pxa_defconfig
sh                           se7724_defconfig
powerpc                      ppc40x_defconfig
sh                        dreamcast_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
powerpc                     tqm8560_defconfig
mips                       rbtx49xx_defconfig
arm                        clps711x_defconfig
arm                  colibri_pxa270_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
nds32                               defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
sh                          kfr2r09_defconfig
powerpc                      bamboo_defconfig
sh                        apsh4ad0a_defconfig
arm                      jornada720_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
sh                         microdev_defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
sh                         ap325rxa_defconfig
mips                        maltaup_defconfig
powerpc                     mpc5200_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
powerpc                       eiger_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
sh                             espt_defconfig
ia64                        generic_defconfig
powerpc                       ebony_defconfig
s390                       zfcpdump_defconfig
arm                      tct_hammer_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                      arches_defconfig
mips                malta_qemu_32r6_defconfig
arm                         cm_x300_defconfig
nios2                            alldefconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
sh                        edosk7760_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
powerpc                         ps3_defconfig
arm                       mainstone_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arc                      axs103_smp_defconfig
powerpc                      ppc6xx_defconfig
arm                           spitz_defconfig
um                               allmodconfig
sh                           sh2007_defconfig
sh                          sdk7786_defconfig
sh                            migor_defconfig
mips                malta_kvm_guest_defconfig
arm                            zeus_defconfig
m68k                          multi_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210328
i386                 randconfig-a011-20210328
i386                 randconfig-a015-20210328
i386                 randconfig-a016-20210328
i386                 randconfig-a013-20210328
i386                 randconfig-a012-20210328
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:45:09 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:45:09 +0800
Subject: [soc:socfpga/rename] BUILD REGRESSION
 4483397b03536506535d611b0cb28a81a69e8edf
Message-ID: <6066d995.AL7kTlg9iqUmfetx%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git socfpga/rename
branch HEAD: 4483397b03536506535d611b0cb28a81a69e8edf  ARM: socfpga: drop ARCH_SOCFPGA

Error/Warning in current branch:

include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_177' declared with attribute error: FIELD_GET: type of reg too small for mask

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
`-- arm-allyesconfig
    `-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:FIELD_GET:type-of-reg-too-small-for-mask

elapsed time: 13809m

configs tested: 604
configs skipped: 5

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
powerpc                     akebono_defconfig
sh                          rsk7203_defconfig
sh                             shx3_defconfig
arm                         orion5x_defconfig
mips                           ip28_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
powerpc                   currituck_defconfig
h8300                            alldefconfig
powerpc                     ksi8560_defconfig
arm                        shmobile_defconfig
powerpc                     ep8248e_defconfig
um                               allyesconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                      obs600_defconfig
arm                           h3600_defconfig
sh                        sh7785lcr_defconfig
arm                         hackkit_defconfig
powerpc                    klondike_defconfig
powerpc                     tqm8555_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                       maple_defconfig
sparc64                             defconfig
arm                         assabet_defconfig
sh                         ecovec24_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                      cm5200_defconfig
powerpc                         wii_defconfig
arm                      jornada720_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
mips                         tb0287_defconfig
mips                        qi_lb60_defconfig
arm                        vexpress_defconfig
sh                  sh7785lcr_32bit_defconfig
sh                        edosk7760_defconfig
riscv             nommu_k210_sdcard_defconfig
sh                           se7780_defconfig
m68k                        m5407c3_defconfig
mips                         tb0226_defconfig
arm                              alldefconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
sh                   secureedge5410_defconfig
arm                        cerfcube_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
powerpc                        icon_defconfig
arc                        nsimosci_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
powerpc                     redwood_defconfig
mips                            ar7_defconfig
m68k                            mac_defconfig
arm                          imote2_defconfig
arm                      tct_hammer_defconfig
arm                             mxs_defconfig
sh                            titan_defconfig
mips                 decstation_r4k_defconfig
powerpc                    adder875_defconfig
sh                             sh03_defconfig
sh                           se7343_defconfig
arm                          pxa3xx_defconfig
sh                          rsk7264_defconfig
csky                                defconfig
sh                     sh7710voipgw_defconfig
m68k                        stmark2_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
mips                     cu1000-neo_defconfig
mips                      bmips_stb_defconfig
arm                   milbeaut_m10v_defconfig
arm                         mv78xx0_defconfig
arm                        spear3xx_defconfig
arc                        vdk_hs38_defconfig
um                           x86_64_defconfig
nds32                            alldefconfig
powerpc                      chrp32_defconfig
arm                        mini2440_defconfig
sh                              ul2_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
powerpc                          allmodconfig
arm                          ixp4xx_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                          lpd270_defconfig
nios2                         3c120_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
xtensa                    xip_kc705_defconfig
sh                 kfr2r09-romimage_defconfig
ia64                          tiger_defconfig
mips                          ath25_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                        mvebu_v5_defconfig
xtensa                           alldefconfig
powerpc                      walnut_defconfig
mips                        omega2p_defconfig
m68k                          sun3x_defconfig
powerpc                  iss476-smp_defconfig
s390                          debug_defconfig
arc                      axs103_smp_defconfig
sh                           se7619_defconfig
powerpc                 mpc836x_rdk_defconfig
arc                         haps_hs_defconfig
um                             i386_defconfig
arm                          badge4_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
openrisc                  or1klitex_defconfig
powerpc                 linkstation_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      acadia_defconfig
powerpc                        cell_defconfig
mips                         tb0219_defconfig
sh                          r7780mp_defconfig
powerpc                     tqm8560_defconfig
sh                   rts7751r2dplus_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                     pseries_defconfig
mips                          ath79_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                             allmodconfig
powerpc                 mpc836x_mds_defconfig
mips                        workpad_defconfig
sparc                            alldefconfig
mips                          rb532_defconfig
m68k                        m5272c3_defconfig
mips                            e55_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
arm                            mps2_defconfig
parisc                generic-64bit_defconfig
sh                   sh7770_generic_defconfig
mips                        vocore2_defconfig
mips                       capcella_defconfig
sh                        dreamcast_defconfig
powerpc                     tqm8540_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
parisc                           alldefconfig
powerpc                          g5_defconfig
ia64                            zx1_defconfig
powerpc                  mpc866_ads_defconfig
powerpc                       ebony_defconfig
arm                         lubbock_defconfig
mips                  cavium_octeon_defconfig
arm                       imx_v4_v5_defconfig
powerpc64                           defconfig
arm                           spitz_defconfig
mips                      maltaaprp_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
openrisc                    or1ksim_defconfig
powerpc                     mpc512x_defconfig
mips                        bcm63xx_defconfig
mips                           ip27_defconfig
ia64                      gensparse_defconfig
mips                     loongson1c_defconfig
powerpc                      katmai_defconfig
arm                       imx_v6_v7_defconfig
arm                       aspeed_g5_defconfig
powerpc                 mpc834x_itx_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                   bluestone_defconfig
arm                      pxa255-idp_defconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
sh                                  defconfig
arm                            qcom_defconfig
xtensa                         virt_defconfig
m68k                        mvme16x_defconfig
h8300                       h8s-sim_defconfig
mips                      pic32mzda_defconfig
arm                       versatile_defconfig
ia64                         bigsur_defconfig
powerpc                   motionpro_defconfig
mips                     decstation_defconfig
sh                             espt_defconfig
m68k                                defconfig
arm                       multi_v4t_defconfig
arc                              alldefconfig
x86_64                           alldefconfig
xtensa                    smp_lx200_defconfig
xtensa                  cadence_csp_defconfig
sh                          r7785rp_defconfig
powerpc                      arches_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
mips                        jmr3927_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
powerpc                     taishan_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          multi_defconfig
arm                       netwinder_defconfig
sh                          sdk7780_defconfig
mips                         mpc30x_defconfig
powerpc                       eiger_defconfig
powerpc                  mpc885_ads_defconfig
riscv                    nommu_k210_defconfig
arm                       cns3420vb_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
h8300                               defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
mips                      loongson3_defconfig
nds32                             allnoconfig
m68k                            q40_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     tqm5200_defconfig
mips                          malta_defconfig
csky                             alldefconfig
sparc                       sparc64_defconfig
m68k                             alldefconfig
riscv                    nommu_virt_defconfig
alpha                               defconfig
arc                     haps_hs_smp_defconfig
mips                       bmips_be_defconfig
powerpc                     tqm8548_defconfig
sh                     magicpanelr2_defconfig
m68k                       bvme6000_defconfig
m68k                             allmodconfig
i386                             alldefconfig
mips                           xway_defconfig
powerpc                 canyonlands_defconfig
arm                     eseries_pxa_defconfig
mips                      malta_kvm_defconfig
arm                           stm32_defconfig
riscv                               defconfig
sh                           se7705_defconfig
powerpc                 mpc8560_ads_defconfig
powerpc                      ppc64e_defconfig
arm                  colibri_pxa270_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
powerpc                      ppc40x_defconfig
mips                      fuloong2e_defconfig
s390                             alldefconfig
sh                          sdk7786_defconfig
sh                           se7721_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                     stx_gp3_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
parisc                generic-32bit_defconfig
arm                            xcep_defconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                          landisk_defconfig
arm                      integrator_defconfig
mips                             allyesconfig
mips                  maltasmvp_eva_defconfig
powerpc                 mpc8313_rdb_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
mips                        bcm47xx_defconfig
mips                          rm200_defconfig
arm                         axm55xx_defconfig
ia64                        generic_defconfig
powerpc                      ppc6xx_defconfig
arm                         palmz72_defconfig
alpha                            allyesconfig
mips                            gpr_defconfig
sh                         ap325rxa_defconfig
powerpc                     sbc8548_defconfig
riscv                             allnoconfig
powerpc                     powernv_defconfig
xtensa                       common_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
riscv                          rv32_defconfig
arm                           u8500_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
mips                           ci20_defconfig
powerpc                 mpc8272_ads_defconfig
sh                      rts7751r2d1_defconfig
powerpc                    mvme5100_defconfig
arm                           viper_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
sh                            migor_defconfig
um                               allmodconfig
powerpc64                        alldefconfig
mips                malta_kvm_guest_defconfig
m68k                             allyesconfig
arc                              allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
x86_64               randconfig-a002-20210325
x86_64               randconfig-a003-20210325
x86_64               randconfig-a006-20210325
x86_64               randconfig-a001-20210325
x86_64               randconfig-a005-20210325
x86_64               randconfig-a004-20210325
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
x86_64               randconfig-a002-20210323
x86_64               randconfig-a003-20210323
x86_64               randconfig-a006-20210323
x86_64               randconfig-a001-20210323
x86_64               randconfig-a004-20210323
x86_64               randconfig-a005-20210323
i386                 randconfig-a003-20210323
i386                 randconfig-a004-20210323
i386                 randconfig-a001-20210323
i386                 randconfig-a002-20210323
i386                 randconfig-a006-20210323
i386                 randconfig-a005-20210323
i386                 randconfig-a003-20210325
i386                 randconfig-a004-20210325
i386                 randconfig-a001-20210325
i386                 randconfig-a002-20210325
i386                 randconfig-a006-20210325
i386                 randconfig-a005-20210325
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210324
i386                 randconfig-a003-20210324
i386                 randconfig-a001-20210324
i386                 randconfig-a002-20210324
i386                 randconfig-a006-20210324
i386                 randconfig-a005-20210324
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210324
x86_64               randconfig-a015-20210324
x86_64               randconfig-a014-20210324
x86_64               randconfig-a013-20210324
x86_64               randconfig-a016-20210324
x86_64               randconfig-a011-20210324
i386                 randconfig-a014-20210323
i386                 randconfig-a011-20210323
i386                 randconfig-a015-20210323
i386                 randconfig-a016-20210323
i386                 randconfig-a012-20210323
i386                 randconfig-a013-20210323
i386                 randconfig-a014-20210325
i386                 randconfig-a011-20210325
i386                 randconfig-a015-20210325
i386                 randconfig-a016-20210325
i386                 randconfig-a013-20210325
i386                 randconfig-a012-20210325
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210324
i386                 randconfig-a011-20210324
i386                 randconfig-a015-20210324
i386                 randconfig-a016-20210324
i386                 randconfig-a013-20210324
i386                 randconfig-a012-20210324
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
um                                allnoconfig
um                                  defconfig
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec
x86_64                    rhel-8.3-kselftests

clang tested configs:
x86_64               randconfig-a002-20210324
x86_64               randconfig-a003-20210324
x86_64               randconfig-a001-20210324
x86_64               randconfig-a006-20210324
x86_64               randconfig-a005-20210324
x86_64               randconfig-a004-20210324
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a012-20210325
x86_64               randconfig-a015-20210325
x86_64               randconfig-a014-20210325
x86_64               randconfig-a013-20210325
x86_64               randconfig-a011-20210325
x86_64               randconfig-a016-20210325
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210323
x86_64               randconfig-a015-20210323
x86_64               randconfig-a013-20210323
x86_64               randconfig-a014-20210323
x86_64               randconfig-a011-20210323
x86_64               randconfig-a016-20210323
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:13 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:13 +0800
Subject: [soc:broadcom/drivers] BUILD SUCCESS
 be6d99420306bb6b0abfff7a814564a614690db6
Message-ID: <6066d95d.PmRmW6Phdq+fruRl%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git broadcom/drivers
branch HEAD: be6d99420306bb6b0abfff7a814564a614690db6  soc: bcm: bcm-pmb: add BCM63138 SATA support

elapsed time: 2206m

configs tested: 257
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
nios2                         3c120_defconfig
arm                        spear6xx_defconfig
arm                           stm32_defconfig
arm                          collie_defconfig
sh                          rsk7264_defconfig
sh                             espt_defconfig
powerpc                      ppc6xx_defconfig
arm                          simpad_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
m68k                        m5307c3_defconfig
mips                            gpr_defconfig
mips                        nlm_xlp_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
powerpc                      tqm8xx_defconfig
arm                           corgi_defconfig
powerpc                 mpc8272_ads_defconfig
powerpc                        fsp2_defconfig
powerpc                 mpc837x_mds_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
h8300                            allyesconfig
powerpc                   bluestone_defconfig
sh                         microdev_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
sh                          rsk7269_defconfig
powerpc64                           defconfig
arm                   milbeaut_m10v_defconfig
sh                              ul2_defconfig
arm                         orion5x_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                    mvme5100_defconfig
arc                            hsdk_defconfig
sparc                       sparc64_defconfig
powerpc                     ksi8560_defconfig
sh                          rsk7201_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
powerpc                  mpc885_ads_defconfig
mips                           mtx1_defconfig
powerpc                      cm5200_defconfig
ia64                            zx1_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
s390                       zfcpdump_defconfig
mips                        qi_lb60_defconfig
arm                        keystone_defconfig
sh                            migor_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
h8300                     edosk2674_defconfig
arc                      axs103_smp_defconfig
mips                      pic32mzda_defconfig
mips                        omega2p_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                        stmark2_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
sh                           se7722_defconfig
xtensa                       common_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
sh                          sdk7786_defconfig
powerpc                     sequoia_defconfig
arm                          exynos_defconfig
sh                ecovec24-romimage_defconfig
sh                            shmin_defconfig
riscv                             allnoconfig
mips                          ath25_defconfig
powerpc                     ppa8548_defconfig
sh                        edosk7760_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
arm                          ixp4xx_defconfig
arm                         cm_x300_defconfig
powerpc                 mpc832x_rdb_defconfig
powerpc                  storcenter_defconfig
mips                    maltaup_xpa_defconfig
alpha                            allyesconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      chrp32_defconfig
powerpc                       ppc64_defconfig
powerpc                     tqm8555_defconfig
sh                           sh2007_defconfig
um                               allmodconfig
arc                                 defconfig
powerpc                     powernv_defconfig
powerpc                 mpc8315_rdb_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                          r7780mp_defconfig
mips                        jmr3927_defconfig
powerpc                        cell_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                    nommu_virt_defconfig
riscv                               defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:37 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:37 +0800
Subject: [soc:broadcom/dt64] BUILD SUCCESS
 9f01f5cdb548352418b34ce77db02a560fe2913b
Message-ID: <6066d975.nU5e8mL0wJo4QHTN%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git broadcom/dt64
branch HEAD: 9f01f5cdb548352418b34ce77db02a560fe2913b  arm64: dts: broadcom: bcm4908: add Ethernet MAC addr

elapsed time: 5114m

configs tested: 381
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
m68k                           sun3_defconfig
arm                         s3c6400_defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
mips                  maltasmvp_eva_defconfig
m68k                            mac_defconfig
xtensa                          iss_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
sh                                  defconfig
m68k                          atari_defconfig
arm                      pxa255-idp_defconfig
arm                          iop32x_defconfig
powerpc                 mpc836x_mds_defconfig
m68k                       m5208evb_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
powerpc                 mpc832x_mds_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
powerpc                  mpc866_ads_defconfig
powerpc                       ebony_defconfig
sh                            titan_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
powerpc                    klondike_defconfig
mips                      loongson3_defconfig
xtensa                  cadence_csp_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
powerpc                      chrp32_defconfig
arm                            qcom_defconfig
arc                        nsim_700_defconfig
mips                          ath25_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
m68k                        mvme16x_defconfig
powerpc                     tqm8560_defconfig
powerpc                         ps3_defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
ia64                      gensparse_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
arm                      tct_hammer_defconfig
powerpc                       holly_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
h8300                               defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
arc                    vdk_hs38_smp_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arm                        multi_v7_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
powerpc                     mpc5200_defconfig
arm                        realview_defconfig
mips                           ci20_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
arm                     eseries_pxa_defconfig
h8300                    h8300h-sim_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
powerpc                      ppc40x_defconfig
sh                        dreamcast_defconfig
mips                       rbtx49xx_defconfig
arm                    vt8500_v6_v7_defconfig
sh                          r7785rp_defconfig
arm                            hisi_defconfig
arm                       multi_v4t_defconfig
mips                malta_qemu_32r6_defconfig
arm                        keystone_defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
nds32                               defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                               alldefconfig
sh                          r7780mp_defconfig
arc                         haps_hs_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
sh                        edosk7760_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
arm                         cm_x300_defconfig
arm                      footbridge_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
s390                       zfcpdump_defconfig
m68k                        mvme147_defconfig
powerpc                      arches_defconfig
arm                       mainstone_defconfig
sh                         ap325rxa_defconfig
arm                            lart_defconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
riscv                    nommu_virt_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
powerpc                    mvme5100_defconfig
arm                   milbeaut_m10v_defconfig
arm                            mps2_defconfig
m68k                         amcore_defconfig
x86_64                              defconfig
arm                       versatile_defconfig
mips                         rt305x_defconfig
mips                          rm200_defconfig
sparc64                          alldefconfig
sh                            migor_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
riscv                    nommu_k210_defconfig
mips                      pic32mzda_defconfig
mips                        jmr3927_defconfig
m68k                       m5275evb_defconfig
mips                        nlm_xlp_defconfig
um                               allmodconfig
arm                      jornada720_defconfig
sparc                       sparc64_defconfig
openrisc                 simple_smp_defconfig
mips                malta_kvm_guest_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:09 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:09 +0800
Subject: [soc:mediatek/dt64] BUILD SUCCESS
 a7dceafed43a4a610d340da3703653cca2c50c1d
Message-ID: <6066d959.vso9pFJqE4L+ZmJ1%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt64
branch HEAD: a7dceafed43a4a610d340da3703653cca2c50c1d  arm64: dts: mediatek: fix reset GPIO level on pumpkin

elapsed time: 1277m

configs tested: 218
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
arm                           h5000_defconfig
m68k                         amcore_defconfig
arm                       spear13xx_defconfig
arm                           viper_defconfig
um                            kunit_defconfig
xtensa                  cadence_csp_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
powerpc                 mpc836x_mds_defconfig
mips                             allmodconfig
riscv                          rv32_defconfig
mips                malta_kvm_guest_defconfig
sh                        edosk7760_defconfig
sh                  sh7785lcr_32bit_defconfig
sh                               allmodconfig
m68k                                defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
m68k                         apollo_defconfig
arc                           tb10x_defconfig
arm                            dove_defconfig
arm                        multi_v7_defconfig
powerpc                  mpc866_ads_defconfig
powerpc               mpc834x_itxgp_defconfig
m68k                          atari_defconfig
x86_64                           alldefconfig
arm                          exynos_defconfig
mips                        nlm_xlp_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
sh                          landisk_defconfig
xtensa                       common_defconfig
arm                      integrator_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
powerpc                 mpc836x_rdk_defconfig
sh                                  defconfig
arm                           corgi_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
h8300                       h8s-sim_defconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
um                                allnoconfig
arm                         cm_x300_defconfig
sh                   sh7724_generic_defconfig
powerpc                   lite5200b_defconfig
arm                          imote2_defconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
riscv                               defconfig
s390                                defconfig
arm                         socfpga_defconfig
powerpc                 linkstation_defconfig
ia64                            zx1_defconfig
arm                         orion5x_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
arm                          ixp4xx_defconfig
arm                       cns3420vb_defconfig
m68k                        mvme147_defconfig
mips                 decstation_r4k_defconfig
arm                              alldefconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
powerpc                 mpc837x_rdb_defconfig
ia64                             allyesconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7751_defconfig
sh                             sh03_defconfig
riscv             nommu_k210_sdcard_defconfig
sh                            shmin_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:22 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:22 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS a2fa9e57a68cd108777ded8f0443483a5fa179ed
Message-ID: <6066d966.ruFhka7FkXLtgcEQ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: a2fa9e57a68cd108777ded8f0443483a5fa179ed  ARM: mvebu: avoid clang -Wtautological-constant warning

elapsed time: 729m

configs tested: 156
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
arm                        trizeps4_defconfig
h8300                       h8s-sim_defconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
um                                allnoconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
arm                     am200epdkit_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
riscv                    nommu_k210_defconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:44 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:44 +0800
Subject: [soc:mediatek/soc] BUILD SUCCESS
 60d93f64a851d276b23b7ef68ddc638258485d32
Message-ID: <6066d97c.oq0BnY/nR6+VVYjw%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/soc
branch HEAD: 60d93f64a851d276b23b7ef68ddc638258485d32  soc: mediatek: pm-domains: Add a power domain names for mt8167

elapsed time: 1278m

configs tested: 231
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
arm                           h5000_defconfig
m68k                         amcore_defconfig
arm                       spear13xx_defconfig
arm                           viper_defconfig
um                            kunit_defconfig
xtensa                  cadence_csp_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
m68k                            q40_defconfig
arm                       netwinder_defconfig
powerpc                       ppc64_defconfig
xtensa                       common_defconfig
mips                 decstation_r4k_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
powerpc                 mpc836x_mds_defconfig
mips                             allmodconfig
riscv                          rv32_defconfig
mips                malta_kvm_guest_defconfig
sh                        edosk7760_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
m68k                         apollo_defconfig
arc                           tb10x_defconfig
arm                            dove_defconfig
arm                        multi_v7_defconfig
powerpc                  mpc866_ads_defconfig
powerpc               mpc834x_itxgp_defconfig
m68k                          atari_defconfig
x86_64                           alldefconfig
arm                          exynos_defconfig
mips                        nlm_xlp_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
sh                          r7780mp_defconfig
m68k                          sun3x_defconfig
ia64                         bigsur_defconfig
h8300                            alldefconfig
arm                         nhk8815_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
sh                          landisk_defconfig
arm                      integrator_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
powerpc                 mpc836x_rdk_defconfig
sh                                  defconfig
arm                           corgi_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                         cm_x300_defconfig
sh                   sh7724_generic_defconfig
powerpc                   lite5200b_defconfig
arm                          imote2_defconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                    ge_imp3a_defconfig
sh                         ap325rxa_defconfig
powerpc                     ep8248e_defconfig
arm                         orion5x_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
riscv                               defconfig
s390                                defconfig
arm                         socfpga_defconfig
powerpc                 linkstation_defconfig
ia64                            zx1_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
arm                          ixp4xx_defconfig
arm                       cns3420vb_defconfig
m68k                        mvme147_defconfig
arm                              alldefconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
powerpc                 mpc837x_rdb_defconfig
ia64                             allyesconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7751_defconfig
sh                             sh03_defconfig
riscv             nommu_k210_sdcard_defconfig
sh                            shmin_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
sh                              ul2_defconfig
powerpc64                        alldefconfig
arc                        nsimosci_defconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:18 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:18 +0800
Subject: [soc:imx/drivers] BUILD SUCCESS
 f63af5f3b8e2cba1b0b19b5cc4aa00d152f84599
Message-ID: <6066d962.Ni8s5JfttgzAa5vQ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/drivers
branch HEAD: f63af5f3b8e2cba1b0b19b5cc4aa00d152f84599  firmware: imx: scu-pd: add missed ADC1 pd

elapsed time: 6125m

configs tested: 406
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
m68k                           sun3_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                        trizeps4_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
m68k                            q40_defconfig
m68k                        m5407c3_defconfig
arm                          pcm027_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      chrp32_defconfig
arm                       omap2plus_defconfig
riscv                    nommu_virt_defconfig
um                            kunit_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arc                        nsimosci_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                          pxa3xx_defconfig
um                               allmodconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
sh                        dreamcast_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      ppc40x_defconfig
sh                   rts7751r2dplus_defconfig
arm                        spear6xx_defconfig
arm                        oxnas_v6_defconfig
arc                        vdk_hs38_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
sparc64                             defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
h8300                     edosk2674_defconfig
sh                   sh7724_generic_defconfig
microblaze                          defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
sh                           se7722_defconfig
parisc                generic-64bit_defconfig
m68k                        mvme147_defconfig
h8300                    h8300h-sim_defconfig
sh                                  defconfig
arm                            qcom_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
powerpc                     tqm8560_defconfig
arm                         lpc18xx_defconfig
powerpc                     rainier_defconfig
um                                  defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
powerpc                        cell_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
ia64                      gensparse_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                      tct_hammer_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
sh                               j2_defconfig
sh                      rts7751r2d1_defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
arc                    vdk_hs38_smp_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arm                        multi_v7_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
i386                             alldefconfig
sparc                       sparc64_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
powerpc                     tqm5200_defconfig
arm                  colibri_pxa270_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                        clps711x_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
sh                           se7780_defconfig
xtensa                       common_defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
sh                         microdev_defconfig
sh                               alldefconfig
sh                          r7780mp_defconfig
arc                         haps_hs_defconfig
sh                         ap325rxa_defconfig
powerpc                     mpc5200_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                       eiger_defconfig
arm                          ixp4xx_defconfig
sh                             espt_defconfig
ia64                        generic_defconfig
powerpc                       ebony_defconfig
powerpc                 mpc8315_rdb_defconfig
s390                       zfcpdump_defconfig
powerpc                     pq2fads_defconfig
arm                         s5pv210_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
sh                        edosk7760_defconfig
powerpc                    mvme5100_defconfig
arm                   milbeaut_m10v_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
sh                            migor_defconfig
sh                           se7750_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arc                      axs103_smp_defconfig
powerpc                      ppc6xx_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
m68k                       m5275evb_defconfig
m68k                       m5249evb_defconfig
arm                       versatile_defconfig
arm                         palmz72_defconfig
sh                          sdk7786_defconfig
mips                malta_kvm_guest_defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
riscv                             allnoconfig
riscv                               defconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 09:44:41 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 16:44:41 +0800
Subject: [soc:tegra/clk] BUILD SUCCESS 0c7ea2b1c850756140fef03bed0fbaf0957f120a
Message-ID: <6066d979.RX3N9rIK05U4sbwY%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tegra/clk
branch HEAD: 0c7ea2b1c850756140fef03bed0fbaf0957f120a  clk: tegra: Don't enable PLLE HW sequencer at init

elapsed time: 12454m

configs tested: 611
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                           ip28_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
powerpc                   currituck_defconfig
h8300                            alldefconfig
powerpc                     ksi8560_defconfig
powerpc                     mpc5200_defconfig
arm                        shmobile_defconfig
powerpc                     ep8248e_defconfig
um                               allyesconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      obs600_defconfig
arm                           h3600_defconfig
sh                        sh7785lcr_defconfig
arm                         hackkit_defconfig
powerpc                    klondike_defconfig
powerpc                     tqm8555_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                       maple_defconfig
sparc64                             defconfig
arm                         assabet_defconfig
sh                         ecovec24_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
xtensa                          iss_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
arm                           tegra_defconfig
arc                                 defconfig
sh                        edosk7760_defconfig
riscv             nommu_k210_sdcard_defconfig
riscv                               defconfig
sh                           se7780_defconfig
m68k                        m5407c3_defconfig
mips                        qi_lb60_defconfig
mips                         tb0226_defconfig
arm                              alldefconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
sh                   secureedge5410_defconfig
arm                        cerfcube_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
arc                        nsimosci_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
sh                            titan_defconfig
arm                        trizeps4_defconfig
arm                      tct_hammer_defconfig
arm                             mxs_defconfig
mips                 decstation_r4k_defconfig
powerpc                    adder875_defconfig
sh                             sh03_defconfig
sh                           se7343_defconfig
arm                          pxa3xx_defconfig
sh                          rsk7264_defconfig
csky                                defconfig
sh                     sh7710voipgw_defconfig
m68k                        stmark2_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
arm                       versatile_defconfig
arm                         mv78xx0_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                 xes_mpc85xx_defconfig
mips                          rb532_defconfig
nds32                            alldefconfig
powerpc                      chrp32_defconfig
arm                        mini2440_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
powerpc                          allmodconfig
arm                          ixp4xx_defconfig
powerpc                     akebono_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                          lpd270_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
powerpc                      ppc64e_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
s390                          debug_defconfig
arc                      axs103_smp_defconfig
arm                        spear3xx_defconfig
powerpc                 mpc836x_rdk_defconfig
arc                         haps_hs_defconfig
um                             i386_defconfig
arm                          badge4_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
arm                       omap2plus_defconfig
riscv                    nommu_virt_defconfig
um                            kunit_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                          rsk7203_defconfig
arm                          iop32x_defconfig
sh                        sh7757lcr_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      acadia_defconfig
powerpc                        cell_defconfig
mips                         tb0219_defconfig
powerpc                     tqm8560_defconfig
sh                   rts7751r2dplus_defconfig
ia64                          tiger_defconfig
powerpc                         wii_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                        workpad_defconfig
sparc                            alldefconfig
m68k                        m5272c3_defconfig
mips                            e55_defconfig
um                                allnoconfig
powerpc64                           defconfig
mips                      bmips_stb_defconfig
mips                        maltaup_defconfig
arm                        mvebu_v7_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
powerpc                       ebony_defconfig
arc                     haps_hs_smp_defconfig
arm                      footbridge_defconfig
ia64                            zx1_defconfig
m68k                                defconfig
arm                          imote2_defconfig
sh                 kfr2r09-romimage_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
parisc                generic-64bit_defconfig
sh                   sh7770_generic_defconfig
mips                        vocore2_defconfig
powerpc                      cm5200_defconfig
mips                             allmodconfig
riscv                             allnoconfig
mips                       capcella_defconfig
sh                        dreamcast_defconfig
xtensa                generic_kc705_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
powerpc                      ppc40x_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
parisc                           alldefconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
h8300                       h8s-sim_defconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
powerpc                     sbc8548_defconfig
arc                        vdk_hs38_defconfig
arm                         lubbock_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
arm                           spitz_defconfig
mips                      maltaaprp_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
openrisc                    or1ksim_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                     mpc512x_defconfig
mips                        bcm63xx_defconfig
mips                           ip27_defconfig
mips                       rbtx49xx_defconfig
ia64                      gensparse_defconfig
arm                      jornada720_defconfig
mips                     loongson1c_defconfig
powerpc                      katmai_defconfig
arm                       imx_v6_v7_defconfig
arm                       aspeed_g5_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
powerpc                 mpc834x_itx_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
nds32                             allnoconfig
arm                      pxa255-idp_defconfig
arm                            mps2_defconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
sparc                            allyesconfig
arm                        vexpress_defconfig
sh                                  defconfig
arm                            qcom_defconfig
arm                  colibri_pxa270_defconfig
xtensa                         virt_defconfig
powerpc                   motionpro_defconfig
mips                     decstation_defconfig
sh                             espt_defconfig
arm                       multi_v4t_defconfig
powerpc                     rainier_defconfig
um                                  defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
m68k                       bvme6000_defconfig
xtensa                    smp_lx200_defconfig
mips                  cavium_octeon_defconfig
xtensa                  cadence_csp_defconfig
sh                          r7785rp_defconfig
powerpc                      arches_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
powerpc                        fsp2_defconfig
m68k                       m5275evb_defconfig
mips                          malta_defconfig
arm                       netwinder_defconfig
sh                          sdk7780_defconfig
mips                         mpc30x_defconfig
powerpc                       eiger_defconfig
powerpc                  mpc885_ads_defconfig
arm                       cns3420vb_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                               j2_defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
sh                      rts7751r2d1_defconfig
sh                            migor_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
arm                         palmz72_defconfig
mips                      loongson3_defconfig
m68k                            q40_defconfig
mips                     loongson1b_defconfig
powerpc                     tqm5200_defconfig
powerpc                 linkstation_defconfig
csky                             alldefconfig
mips                        nlm_xlp_defconfig
sparc                       sparc64_defconfig
sh                           se7705_defconfig
m68k                             alldefconfig
alpha                               defconfig
mips                       bmips_be_defconfig
powerpc                      ep88xc_defconfig
i386                             alldefconfig
powerpc                 mpc85xx_cds_defconfig
mips                           xway_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                     eseries_pxa_defconfig
powerpc                 mpc8560_ads_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
sh                          sdk7786_defconfig
arm                           stm32_defconfig
sh                           se7721_defconfig
powerpc                     stx_gp3_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
xtensa                       common_defconfig
arm                            xcep_defconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc8272_ads_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
mips                  maltasmvp_eva_defconfig
m68k                          multi_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                     pq2fads_defconfig
mips                        bcm47xx_defconfig
arm                         axm55xx_defconfig
ia64                        generic_defconfig
powerpc                      ppc6xx_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
powerpc                     pseries_defconfig
powerpc                     powernv_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
sh                           se7751_defconfig
mips                           ci20_defconfig
arm                           corgi_defconfig
powerpc                    mvme5100_defconfig
arm                           viper_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
s390                             allyesconfig
mips                      pic32mzda_defconfig
um                               allmodconfig
sh                            shmin_defconfig
mips                malta_kvm_guest_defconfig
m68k                             allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                               defconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210325
x86_64               randconfig-a003-20210325
x86_64               randconfig-a006-20210325
x86_64               randconfig-a001-20210325
x86_64               randconfig-a005-20210325
x86_64               randconfig-a004-20210325
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a003-20210325
i386                 randconfig-a004-20210325
i386                 randconfig-a001-20210325
i386                 randconfig-a002-20210325
i386                 randconfig-a006-20210325
i386                 randconfig-a005-20210325
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a004-20210324
i386                 randconfig-a003-20210324
i386                 randconfig-a001-20210324
i386                 randconfig-a002-20210324
i386                 randconfig-a006-20210324
i386                 randconfig-a005-20210324
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210323
i386                 randconfig-a004-20210323
i386                 randconfig-a001-20210323
i386                 randconfig-a002-20210323
i386                 randconfig-a006-20210323
i386                 randconfig-a005-20210323
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210324
x86_64               randconfig-a015-20210324
x86_64               randconfig-a014-20210324
x86_64               randconfig-a013-20210324
x86_64               randconfig-a016-20210324
x86_64               randconfig-a011-20210324
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a014-20210325
i386                 randconfig-a011-20210325
i386                 randconfig-a015-20210325
i386                 randconfig-a016-20210325
i386                 randconfig-a013-20210325
i386                 randconfig-a012-20210325
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210324
i386                 randconfig-a011-20210324
i386                 randconfig-a015-20210324
i386                 randconfig-a016-20210324
i386                 randconfig-a013-20210324
i386                 randconfig-a012-20210324
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
i386                 randconfig-a014-20210323
i386                 randconfig-a011-20210323
i386                 randconfig-a015-20210323
i386                 randconfig-a016-20210323
i386                 randconfig-a012-20210323
i386                 randconfig-a013-20210323
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a002-20210324
x86_64               randconfig-a003-20210324
x86_64               randconfig-a001-20210324
x86_64               randconfig-a006-20210324
x86_64               randconfig-a005-20210324
x86_64               randconfig-a004-20210324
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210325
x86_64               randconfig-a015-20210325
x86_64               randconfig-a014-20210325
x86_64               randconfig-a013-20210325
x86_64               randconfig-a011-20210325
x86_64               randconfig-a016-20210325
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a012-20210323
x86_64               randconfig-a015-20210323
x86_64               randconfig-a013-20210323
x86_64               randconfig-a014-20210323
x86_64               randconfig-a011-20210323
x86_64               randconfig-a016-20210323
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From marcan at marcan.st  Fri Apr  2 10:05:24 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:24 +0900
Subject: [PATCH v4 00/18] Apple M1 SoC platform bring-up
Message-ID: <20210402090542.131194-1-marcan@marcan.st>

This series brings up initial support for the Apple M1 SoC, used in the
2020 Mac Mini, MacBook Pro, and MacBook Air models.

The following features are supported in this initial port:

- UART (samsung-style) with earlycon support
- Interrupts, including affinity and IPIs (Apple Interrupt Controller)
- SMP (through standard spin-table support)
- simplefb-based framebuffer
- Devicetree for the Mac Mini (should work for the others too at this
  stage)

See below for an overview of changes since v3.

== Merge notes ==

This patchset has several dependencies:

* Build dep on the FIQ support series in [1].
* Runtime dep on the Samsung TTY changes in tty-next (modulo DT validation).
* Runtime dep on the nVHE changes being reviewed in [2].

A tree containing this patchset on top of the required dependencies is
available at [3][4], for those who want to test it.

This series is expected to be merged by Arnd via the SoC tree.
Maintainers, please ack if you are happy with the patches. We will
coordinate with Arnd and Mark on the FIQ series to make sure all
that goes smoothly.

[1] https://lore.kernel.org/linux-arm-kernel/20210315115629.57191-1-mark.rutland at arm.com/T/
[2] https://lore.kernel.org/linux-arm-kernel/20210330173947.999859-1-maz at kernel.org/T/
[3] git://github.com/AsahiLinux/linux.git upstream-bringup-v4
[4] https://github.com/AsahiLinux/linux/tree/upstream-bringup-v4

== Testing notes ==

This has been tested on an Apple M1 Mac Mini booting to a framebuffer
and serial console, with SMP and KASLR, with an arm64 defconfig
(+ CONFIG_FB_SIMPLE for the fb). In addition, the AIC driver now supports
running in EL1, tested in UP mode only.

== Patch overview ==

- 01-02 Core platform DT bindings
- 03-04 CPU DT bindings and MIDR defines
- 05-06 Add interrupt-names support to the ARM timer driver
        This is used to cleanly express the lack of a secure timer;
        platforms in the past have used various hacks like dummy
        IRQs here.
- 07-12 ioremap_np() (nGnRnE) support
        The fabric in these SoCs only supports nGnRnE accesses for
        standard MMIO, except for PCI ranges which use nGnRE. Linux
        currently defaults to the latter on ARM64, so this adds a new
        ioremap type and DT properties to automatically select it for
        drivers using OF and devm abstractions, under buses specified
        in DT.
- 13-15 AIC (Apple Interrupt Controller) driver and support defines
        This also embeds FIQ handling for this platform.
- 16    Introduce CONFIG_ARCH_APPLE & add it to defconfig
- 17    simple-framebuffer bindings for Apple (trivial)
- 18    Add the initial M1 Mac Mini (j274) devicetree

== About the hardware ==

These machines officially support booting unsigned/user-provided
XNU-like kernels, with a very different boot protocol and devicetree
format. We are developing an initial bootloader, m1n1 [1], to take care
of as many hardware peculiarities as possible and present a standard
Linux arm64 boot protocol and device tree. In the future, I expect that
production setups will add U-Boot and perhaps GRUB into the boot chain,
to make the boot process similar to other ARM64 platforms.

The machines expose their debug UART over USB Type C, triggered with
vendor-specific USB-PD commands. Currently, the easiest way to get a
serial console on these machines is to use a second M1 box and a simple
USB C cable [2]. You can also build a DIY interface using an Arduino, a
FUSB302 chip or board, and a 1.2V UART-TTL adapter [3]. In the coming
weeks we will be designing an open hardware project to provide
serial/debug connectivity to these machines (and, hopefully, also
support other UART-over-Type C setups from other vendors). Please
contact me privately if you are interested in getting an early prototype
version of one of these devices.

We also have WIP/not merged yet support for loading kernels and
interacting via dwc3 usb-gadget, which works with a standard C-C or C-A
cable and any Linux host.

A quickstart guide to booting Linux kernels on these machines is
available at [4], and we are documenting the hardware at [5].

[1] https://github.com/AsahiLinux/m1n1/
[2] https://github.com/AsahiLinux/macvdmtool/
[3] https://github.com/AsahiLinux/vdmtool/
[4] https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
[5] https://github.com/AsahiLinux/docs/wiki

== Project Blurb ==

Asahi Linux is an open community project dedicated to developing and
maintaining mainline support for Apple Silicon on Linux. Feel free to
drop by #asahi and #asahi-dev on freenode to chat with us, or check
our website for more information on the project:

https://asahilinux.org/

== Changes since v3 ==

* Serial patches have already been merged into tty-next and are
  no longer included
* nVHE fixup patches are being reviewed separately and no longer
  part of this series
* Updated arm,arch-timer bindings to be more restrictive, renamed
  phys-secure to sec-phys
* Reordered ioremap() variants list in device-io.rst
* Removed sysreg_apple.h (defines are in drivers now)
* Many cleanups, bug fixes, and reworks to AIC, including some bug
  fixes from Marc's KVM series, kernel as EL1 support, and more.
* Simplified non-posted MMIO DT handling to only apply to direct
  children of a bus, and only use "nonposted-mmio". Removed quirk
  optimization.
* Implemented default pci_remap_cfgspace() in terms of ioremap_np()
  and removed arch-specific pci_remap_cfgspace override for arm64
  (arm32 can come later)
* Replaced license in AIC bindings header with GPL-2.0+ OR MIT
* Other minor typo/style fixes

Arnd Bergmann (1):
  docs: driver-api: device-io: Document I/O access functions

Hector Martin (17):
  dt-bindings: vendor-prefixes: Add apple prefix
  dt-bindings: arm: apple: Add bindings for Apple ARM platforms
  dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles
  arm64: cputype: Add CPU implementor & types for the Apple M1 cores
  dt-bindings: timer: arm,arch_timer: Add interrupt-names support
  arm64: arch_timer: Implement support for interrupt-names
  asm-generic/io.h:  Add a non-posted variant of ioremap()
  docs: driver-api: device-io: Document ioremap() variants & access
    funcs
  arm64: Implement ioremap_np() to map MMIO as nGnRnE
  asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
  of/address: Add infrastructure to declare MMIO as non-posted
  arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h
  dt-bindings: interrupt-controller: Add DT bindings for apple-aic
  irqchip/apple-aic: Add support for the Apple Interrupt Controller
  arm64: Kconfig: Introduce CONFIG_ARCH_APPLE
  dt-bindings: display: Add apple,simple-framebuffer
  arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree

 .../devicetree/bindings/arm/apple.yaml        |  64 ++
 .../devicetree/bindings/arm/cpus.yaml         |   2 +
 .../bindings/display/simple-framebuffer.yaml  |   5 +
 .../interrupt-controller/apple,aic.yaml       |  88 ++
 .../bindings/timer/arm,arch_timer.yaml        |  19 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 Documentation/driver-api/device-io.rst        | 356 ++++++++
 .../driver-api/driver-model/devres.rst        |   1 +
 MAINTAINERS                                   |  14 +
 arch/arm64/Kconfig.platforms                  |   7 +
 arch/arm64/boot/dts/Makefile                  |   1 +
 arch/arm64/boot/dts/apple/Makefile            |   2 +
 arch/arm64/boot/dts/apple/t8103-j274.dts      |  45 +
 arch/arm64/boot/dts/apple/t8103.dtsi          | 135 +++
 arch/arm64/configs/defconfig                  |   1 +
 arch/arm64/include/asm/cputype.h              |   6 +
 arch/arm64/include/asm/io.h                   |  11 +-
 arch/arm64/include/asm/sysreg.h               |  60 ++
 arch/sparc/include/asm/io_64.h                |   4 +
 drivers/clocksource/arm_arch_timer.c          |  24 +-
 drivers/irqchip/Kconfig                       |   8 +
 drivers/irqchip/Makefile                      |   1 +
 drivers/irqchip/irq-apple-aic.c               | 837 ++++++++++++++++++
 drivers/of/address.c                          |  43 +-
 include/asm-generic/io.h                      |  22 +-
 include/asm-generic/iomap.h                   |   9 +
 include/clocksource/arm_arch_timer.h          |   1 +
 .../interrupt-controller/apple-aic.h          |  15 +
 include/linux/cpuhotplug.h                    |   1 +
 include/linux/io.h                            |  23 +-
 include/linux/ioport.h                        |   1 +
 include/linux/irqchip/arm-gic-v3.h            |  56 --
 include/linux/of_address.h                    |   1 +
 lib/devres.c                                  |  22 +
 34 files changed, 1807 insertions(+), 80 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/apple.yaml
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 create mode 100644 arch/arm64/boot/dts/apple/Makefile
 create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
 create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi
 create mode 100644 drivers/irqchip/irq-apple-aic.c
 create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h

--
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:25 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:25 +0900
Subject: [PATCH v4 01/18] dt-bindings: vendor-prefixes: Add apple prefix
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-2-marcan@marcan.st>

This is different from the legacy AAPL prefix used on PPC, but
consensus is that we prefer `apple` for these new platforms.

Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 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 f6064d84a424..7b59b6d3f526 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -103,6 +103,8 @@ patternProperties:
     description: Anvo-Systems Dresden GmbH
   "^apm,.*":
     description: Applied Micro Circuits Corporation (APM)
+  "^apple,.*":
+    description: Apple Inc.
   "^aptina,.*":
     description: Aptina Imaging
   "^arasan,.*":
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:26 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:26 +0900
Subject: [PATCH v4 02/18] dt-bindings: arm: apple: Add bindings for Apple ARM
 platforms
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-3-marcan@marcan.st>

This introduces bindings for all three 2020 Apple M1 devices:

* apple,j274 - Mac mini (M1, 2020)
* apple,j293 - MacBook Pro (13-inch, M1, 2020)
* apple,j313 - MacBook Air (M1, 2020)

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 .../devicetree/bindings/arm/apple.yaml        | 64 +++++++++++++++++++
 MAINTAINERS                                   | 10 +++
 2 files changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/apple.yaml

diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml
new file mode 100644
index 000000000000..1e772c85206c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apple.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/apple.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple ARM Machine Device Tree Bindings
+
+maintainers:
+  - Hector Martin <marcan at marcan.st>
+
+description: |
+  ARM platforms using SoCs designed by Apple Inc., branded "Apple Silicon".
+
+  This currently includes devices based on the "M1" SoC, starting with the
+  three Mac models released in late 2020:
+
+  - Mac mini (M1, 2020)
+  - MacBook Pro (13-inch, M1, 2020)
+  - MacBook Air (M1, 2020)
+
+  The compatible property should follow this format:
+
+  compatible = "apple,<targettype>", "apple,<socid>", "apple,arm-platform";
+
+  <targettype> represents the board/device and comes from the `target-type`
+  property of the root node of the Apple Device Tree, lowercased. It can be
+  queried on macOS using the following command:
+
+  $ ioreg -d2 -l | grep target-type
+
+  <socid> is the lowercased SoC ID. Apple uses at least *five* different
+  names for their SoCs:
+
+  - Marketing name ("M1")
+  - Internal name ("H13G")
+  - Codename ("Tonga")
+  - SoC ID ("T8103")
+  - Package/IC part number ("APL1102")
+
+  Devicetrees should use the lowercased SoC ID, to avoid confusion if
+  multiple SoCs share the same marketing name. This can be obtained from
+  the `compatible` property of the arm-io node of the Apple Device Tree,
+  which can be queried as follows on macOS:
+
+  $ ioreg -n arm-io | grep compatible
+
+properties:
+  $nodename:
+    const: "/"
+  compatible:
+    oneOf:
+      - description: Apple M1 SoC based platforms
+        items:
+          - enum:
+              - apple,j274 # Mac mini (M1, 2020)
+              - apple,j293 # MacBook Pro (13-inch, M1, 2020)
+              - apple,j313 # MacBook Air (M1, 2020)
+          - const: apple,t8103
+          - const: apple,arm-platform
+
+additionalProperties: true
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 88ad851fb5da..bee9a57e6cec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1637,6 +1637,16 @@ F:	arch/arm/mach-alpine/
 F:	arch/arm64/boot/dts/amazon/
 F:	drivers/*/*alpine*
 
+ARM/APPLE MACHINE SUPPORT
+M:	Hector Martin <marcan at marcan.st>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+W:	https://asahilinux.org
+B:	https://github.com/AsahiLinux/linux/issues
+C:	irc://chat.freenode.net/asahi-dev
+T:	git https://github.com/AsahiLinux/linux.git
+F:	Documentation/devicetree/bindings/arm/apple.yaml
+
 ARM/ARTPEC MACHINE SUPPORT
 M:	Jesper Nilsson <jesper.nilsson at axis.com>
 M:	Lars Persson <lars.persson at axis.com>
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:27 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:27 +0900
Subject: [PATCH v4 03/18] dt-bindings: arm: cpus: Add apple,
 firestorm & icestorm compatibles
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-4-marcan@marcan.st>

These are the CPU cores in the "Apple Silicon" M1 SoC.

Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 26b886b20b27..c299423dc7cb 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -85,6 +85,8 @@ properties:
 
   compatible:
     enum:
+      - apple,icestorm
+      - apple,firestorm
       - arm,arm710t
       - arm,arm720t
       - arm,arm740t
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:28 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:28 +0900
Subject: [PATCH v4 04/18] arm64: cputype: Add CPU implementor & types for the
 Apple M1 cores
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-5-marcan@marcan.st>

The implementor will be used to condition the FIQ support quirk.

The specific CPU types are not used at the moment, but let's add them
for documentation purposes.

Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 arch/arm64/include/asm/cputype.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index ef5b040dee44..6231e1f0abe7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -59,6 +59,7 @@
 #define ARM_CPU_IMP_NVIDIA		0x4E
 #define ARM_CPU_IMP_FUJITSU		0x46
 #define ARM_CPU_IMP_HISI		0x48
+#define ARM_CPU_IMP_APPLE		0x61
 
 #define ARM_CPU_PART_AEM_V8		0xD0F
 #define ARM_CPU_PART_FOUNDATION		0xD00
@@ -99,6 +100,9 @@
 
 #define HISI_CPU_PART_TSV110		0xD01
 
+#define APPLE_CPU_PART_M1_ICESTORM	0x022
+#define APPLE_CPU_PART_M1_FIRESTORM	0x023
+
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
 #define MIDR_CORTEX_A72 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A72)
@@ -127,6 +131,8 @@
 #define MIDR_NVIDIA_CARMEL MIDR_CPU_MODEL(ARM_CPU_IMP_NVIDIA, NVIDIA_CPU_PART_CARMEL)
 #define MIDR_FUJITSU_A64FX MIDR_CPU_MODEL(ARM_CPU_IMP_FUJITSU, FUJITSU_CPU_PART_A64FX)
 #define MIDR_HISI_TSV110 MIDR_CPU_MODEL(ARM_CPU_IMP_HISI, HISI_CPU_PART_TSV110)
+#define MIDR_APPLE_M1_ICESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M1_ICESTORM)
+#define MIDR_APPLE_M1_FIRESTORM MIDR_CPU_MODEL(ARM_CPU_IMP_APPLE, APPLE_CPU_PART_M1_FIRESTORM)
 
 /* Fujitsu Erratum 010001 affects A64FX 1.0 and 1.1, (v0r0 and v1r0) */
 #define MIDR_FUJITSU_ERRATUM_010001		MIDR_FUJITSU_A64FX
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:29 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:29 +0900
Subject: [PATCH v4 05/18] dt-bindings: timer: arm,
 arch_timer: Add interrupt-names support
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-6-marcan@marcan.st>

Not all platforms provide the same set of timers/interrupts, and Linux
only needs one (plus kvm/guest ones); some platforms are working around
this by using dummy fake interrupts. Implementing interrupt-names allows
the devicetree to specify an arbitrary set of available interrupts, so
the timer code can pick the right one.

This also adds the hyp-virt timer/interrupt, which was previously not
expressed in the fixed 4-interrupt form.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Marc Zyngier <maz at kernel.org>
Reviewed-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 .../bindings/timer/arm,arch_timer.yaml        | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
index 2c75105c1398..7f5e3af58255 100644
--- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
+++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
@@ -34,11 +34,30 @@ properties:
               - arm,armv8-timer
 
   interrupts:
+    minItems: 1
+    maxItems: 5
     items:
       - description: secure timer irq
       - description: non-secure timer irq
       - description: virtual timer irq
       - description: hypervisor timer irq
+      - description: hypervisor virtual timer irq
+
+  interrupt-names:
+    oneOf:
+      - minItems: 2
+        items:
+          - const: phys
+          - const: virt
+          - const: hyp-phys
+          - const: hyp-virt
+      - minItems: 3
+        items:
+          - const: sec-phys
+          - const: phys
+          - const: virt
+          - const: hyp-phys
+          - const: hyp-virt
 
   clock-frequency:
     description: The frequency of the main counter, in Hz. Should be present
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:30 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:30 +0900
Subject: [PATCH v4 06/18] arm64: arch_timer: Implement support for
 interrupt-names
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-7-marcan@marcan.st>

This allows the devicetree to correctly represent the available set of
timers, which varies from device to device, without the need for fake
dummy interrupts for unavailable slots.

Also add the hyp-virt timer/PPI, which is not currently used, but worth
representing.

Reviewed-by: Tony Lindgren <tony at atomide.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Marc Zyngier <maz at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 drivers/clocksource/arm_arch_timer.c | 24 +++++++++++++++++++++---
 include/clocksource/arm_arch_timer.h |  1 +
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index d0177824c518..932f95691e27 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -63,6 +63,14 @@ struct arch_timer {
 static u32 arch_timer_rate;
 static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
 
+static const char *arch_timer_ppi_names[ARCH_TIMER_MAX_TIMER_PPI] = {
+	[ARCH_TIMER_PHYS_SECURE_PPI]	= "sec-phys",
+	[ARCH_TIMER_PHYS_NONSECURE_PPI]	= "phys",
+	[ARCH_TIMER_VIRT_PPI]		= "virt",
+	[ARCH_TIMER_HYP_PPI]		= "hyp-phys",
+	[ARCH_TIMER_HYP_VIRT_PPI]	= "hyp-virt",
+};
+
 static struct clock_event_device __percpu *arch_timer_evt;
 
 static enum arch_timer_ppi_nr arch_timer_uses_ppi = ARCH_TIMER_VIRT_PPI;
@@ -1280,8 +1288,9 @@ static void __init arch_timer_populate_kvm_info(void)
 
 static int __init arch_timer_of_init(struct device_node *np)
 {
-	int i, ret;
+	int i, irq, ret;
 	u32 rate;
+	bool has_names;
 
 	if (arch_timers_present & ARCH_TIMER_TYPE_CP15) {
 		pr_warn("multiple nodes in dt, skipping\n");
@@ -1289,8 +1298,17 @@ static int __init arch_timer_of_init(struct device_node *np)
 	}
 
 	arch_timers_present |= ARCH_TIMER_TYPE_CP15;
-	for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++)
-		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
+
+	has_names = of_property_read_bool(np, "interrupt-names");
+
+	for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI; i++) {
+		if (has_names)
+			irq = of_irq_get_byname(np, arch_timer_ppi_names[i]);
+		else
+			irq = of_irq_get(np, i);
+		if (irq > 0)
+			arch_timer_ppi[i] = irq;
+	}
 
 	arch_timer_populate_kvm_info();
 
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 1d68d5613dae..73c7139c866f 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -32,6 +32,7 @@ enum arch_timer_ppi_nr {
 	ARCH_TIMER_PHYS_NONSECURE_PPI,
 	ARCH_TIMER_VIRT_PPI,
 	ARCH_TIMER_HYP_PPI,
+	ARCH_TIMER_HYP_VIRT_PPI,
 	ARCH_TIMER_MAX_TIMER_PPI
 };
 
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:31 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:31 +0900
Subject: [PATCH v4 07/18] asm-generic/io.h: Add a non-posted variant of
 ioremap()
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-8-marcan@marcan.st>

ARM64 currently defaults to posted MMIO (nGnRE), but some devices
require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap()
variant to handle this case. ioremap_np() returns NULL on arches that
do not implement this variant.

sparc64 is the only architecture that needs to be touched directly,
because it includes neither of the generic io.h or iomap.h headers.

This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this
variant and marks a given resource as requiring non-posted mappings.
This is implemented in the resource system because it is a SoC-level
requirement, so existing drivers do not need special-case code to pick
this ioremap variant.

Then this is implemented in devres by introducing devm_ioremap_np(),
and making devm_ioremap_resource() automatically select this variant
when the resource has the IORESOURCE_MEM_NONPOSTED flag set.

Acked-by: Marc Zyngier <maz at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 .../driver-api/driver-model/devres.rst        |  1 +
 arch/sparc/include/asm/io_64.h                |  4 ++++
 include/asm-generic/io.h                      | 22 ++++++++++++++++++-
 include/asm-generic/iomap.h                   |  9 ++++++++
 include/linux/io.h                            |  2 ++
 include/linux/ioport.h                        |  1 +
 lib/devres.c                                  | 22 +++++++++++++++++++
 7 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst
index cd8b6e657b94..2f45877a539d 100644
--- a/Documentation/driver-api/driver-model/devres.rst
+++ b/Documentation/driver-api/driver-model/devres.rst
@@ -309,6 +309,7 @@ IOMAP
   devm_ioremap()
   devm_ioremap_uc()
   devm_ioremap_wc()
+  devm_ioremap_np()
   devm_ioremap_resource() : checks resource, requests memory region, ioremaps
   devm_ioremap_resource_wc()
   devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 9bb27e5c22f1..9fbfc9574432 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -409,6 +409,10 @@ static inline void __iomem *ioremap(unsigned long offset, unsigned long size)
 #define ioremap_uc(X,Y)			ioremap((X),(Y))
 #define ioremap_wc(X,Y)			ioremap((X),(Y))
 #define ioremap_wt(X,Y)			ioremap((X),(Y))
+static inline void __iomem *ioremap_np(unsigned long offset, unsigned long size)
+{
+	return NULL;
+}
 
 static inline void iounmap(volatile void __iomem *addr)
 {
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index c6af40ce03be..082e0c96db6e 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -942,7 +942,9 @@ static inline void *phys_to_virt(unsigned long address)
  *
  * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
  * for specific drivers if the architecture choses to implement them.  If they
- * are not implemented we fall back to plain ioremap.
+ * are not implemented we fall back to plain ioremap. Conversely, ioremap_np()
+ * can provide stricter non-posted write semantics if the architecture
+ * implements them.
  */
 #ifndef CONFIG_MMU
 #ifndef ioremap
@@ -993,6 +995,24 @@ static inline void __iomem *ioremap_uc(phys_addr_t offset, size_t size)
 {
 	return NULL;
 }
+
+/*
+ * ioremap_np needs an explicit architecture implementation, as it
+ * requests stronger semantics than regular ioremap(). Portable drivers
+ * should instead use one of the higher-level abstractions, like
+ * devm_ioremap_resource(), to choose the correct variant for any given
+ * device and bus. Portable drivers with a good reason to want non-posted
+ * write semantics should always provide an ioremap() fallback in case
+ * ioremap_np() is not available.
+ */
+#ifndef ioremap_np
+#define ioremap_np ioremap_np
+static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size)
+{
+	return NULL;
+}
+#endif
+
 #endif
 
 #ifdef CONFIG_HAS_IOPORT_MAP
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 649224664969..9b3eb6d86200 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -101,6 +101,15 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wt ioremap
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_NP
+/* See the comment in asm-generic/io.h about ioremap_np(). */
+#define ioremap_np ioremap_np
+static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size)
+{
+	return NULL;
+}
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;
diff --git a/include/linux/io.h b/include/linux/io.h
index 8394c56babc2..d718354ed3e1 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -68,6 +68,8 @@ void __iomem *devm_ioremap_uc(struct device *dev, resource_size_t offset,
 				   resource_size_t size);
 void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
 				   resource_size_t size);
+void __iomem *devm_ioremap_np(struct device *dev, resource_size_t offset,
+				   resource_size_t size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
 			const unsigned char *signature, int length);
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 55de385c839c..1de6c2e40c32 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -108,6 +108,7 @@ struct resource {
 #define IORESOURCE_MEM_32BIT		(3<<3)
 #define IORESOURCE_MEM_SHADOWABLE	(1<<5)	/* dup: IORESOURCE_SHADOWABLE */
 #define IORESOURCE_MEM_EXPANSIONROM	(1<<6)
+#define IORESOURCE_MEM_NONPOSTED	(1<<7)
 
 /* PnP I/O specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IO_16BIT_ADDR	(1<<0)
diff --git a/lib/devres.c b/lib/devres.c
index 2a4ff5d64288..4679dbb1bf5f 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -10,6 +10,7 @@ enum devm_ioremap_type {
 	DEVM_IOREMAP = 0,
 	DEVM_IOREMAP_UC,
 	DEVM_IOREMAP_WC,
+	DEVM_IOREMAP_NP,
 };
 
 void devm_ioremap_release(struct device *dev, void *res)
@@ -42,6 +43,9 @@ static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
 	case DEVM_IOREMAP_WC:
 		addr = ioremap_wc(offset, size);
 		break;
+	case DEVM_IOREMAP_NP:
+		addr = ioremap_np(offset, size);
+		break;
 	}
 
 	if (addr) {
@@ -98,6 +102,21 @@ void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
 }
 EXPORT_SYMBOL(devm_ioremap_wc);
 
+/**
+ * devm_ioremap_np - Managed ioremap_np()
+ * @dev: Generic device to remap IO address for
+ * @offset: Resource address to map
+ * @size: Size of map
+ *
+ * Managed ioremap_np().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_np(struct device *dev, resource_size_t offset,
+			      resource_size_t size)
+{
+	return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NP);
+}
+EXPORT_SYMBOL(devm_ioremap_np);
+
 /**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
@@ -128,6 +147,9 @@ __devm_ioremap_resource(struct device *dev, const struct resource *res,
 		return IOMEM_ERR_PTR(-EINVAL);
 	}
 
+	if (type == DEVM_IOREMAP && res->flags & IORESOURCE_MEM_NONPOSTED)
+		type = DEVM_IOREMAP_NP;
+
 	size = resource_size(res);
 
 	if (res->name)
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:32 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:32 +0900
Subject: [PATCH v4 08/18] docs: driver-api: device-io: Document I/O access
 functions
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-9-marcan@marcan.st>

From: Arnd Bergmann <arnd at arndb.de>

This adds more detailed descriptions of the various read/write
primitives available for use with I/O memory/ports.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 Documentation/driver-api/device-io.rst | 138 +++++++++++++++++++++++++
 1 file changed, 138 insertions(+)

diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst
index 764963876d08..b20864b3ddc7 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -146,6 +146,144 @@ There are also equivalents to memcpy. The ins() and
 outs() functions copy bytes, words or longs to the given
 port.
 
+__iomem pointer tokens
+======================
+
+The data type for an MMIO address is an ``__iomem`` qualified pointer, such as
+``void __iomem *reg``. On most architectures it is a regular pointer that
+points to a virtual memory address and can be offset or dereferenced, but in
+portable code, it must only be passed from and to functions that explicitly
+operated on an ``__iomem`` token, in particular the ioremap() and
+readl()/writel() functions. The 'sparse' semantic code checker can be used to
+verify that this is done correctly.
+
+While on most architectures, ioremap() creates a page table entry for an
+uncached virtual address pointing to the physical MMIO address, some
+architectures require special instructions for MMIO, and the ``__iomem`` pointer
+just encodes the physical address or an offsettable cookie that is interpreted
+by readl()/writel().
+
+Differences between I/O access functions
+========================================
+
+readq(), readl(), readw(), readb(), writeq(), writel(), writew(), writeb()
+
+  These are the most generic accessors, providing serialization against other
+  MMIO accesses and DMA accesses as well as fixed endianness for accessing
+  little-endian PCI devices and on-chip peripherals. Portable device drivers
+  should generally use these for any access to ``__iomem`` pointers.
+
+  Note that posted writes are not strictly ordered against a spinlock, see
+  Documentation/driver-api/io_ordering.rst.
+
+readq_relaxed(), readl_relaxed(), readw_relaxed(), readb_relaxed(),
+writeq_relaxed(), writel_relaxed(), writew_relaxed(), writeb_relaxed()
+
+  On architectures that require an expensive barrier for serializing against
+  DMA, these "relaxed" versions of the MMIO accessors only serialize against
+  each other, but contain a less expensive barrier operation. A device driver
+  might use these in a particularly performance sensitive fast path, with a
+  comment that explains why the usage in a specific location is safe without
+  the extra barriers.
+
+  See memory-barriers.txt for a more detailed discussion on the precise ordering
+  guarantees of the non-relaxed and relaxed versions.
+
+ioread64(), ioread32(), ioread16(), ioread8(),
+iowrite64(), iowrite32(), iowrite16(), iowrite8()
+
+  These are an alternative to the normal readl()/writel() functions, with almost
+  identical behavior, but they can also operate on ``__iomem`` tokens returned
+  for mapping PCI I/O space with pci_iomap() or ioport_map(). On architectures
+  that require special instructions for I/O port access, this adds a small
+  overhead for an indirect function call implemented in lib/iomap.c, while on
+  other architectures, these are simply aliases.
+
+ioread64be(), ioread32be(), ioread16be()
+iowrite64be(), iowrite32be(), iowrite16be()
+
+  These behave in the same way as the ioread32()/iowrite32() family, but with
+  reversed byte order, for accessing devices with big-endian MMIO registers.
+  Device drivers that can operate on either big-endian or little-endian
+  registers may have to implement a custom wrapper function that picks one or
+  the other depending on which device was found.
+
+  Note: On some architectures, the normal readl()/writel() functions
+  traditionally assume that devices are the same endianness as the CPU, while
+  using a hardware byte-reverse on the PCI bus when running a big-endian kernel.
+  Drivers that use readl()/writel() this way are generally not portable, but
+  tend to be limited to a particular SoC.
+
+hi_lo_readq(), lo_hi_readq(), hi_lo_readq_relaxed(), lo_hi_readq_relaxed(),
+ioread64_lo_hi(), ioread64_hi_lo(), ioread64be_lo_hi(), ioread64be_hi_lo(),
+hi_lo_writeq(), lo_hi_writeq(), hi_lo_writeq_relaxed(), lo_hi_writeq_relaxed(),
+iowrite64_lo_hi(), iowrite64_hi_lo(), iowrite64be_lo_hi(), iowrite64be_hi_lo()
+
+  Some device drivers have 64-bit registers that cannot be accessed atomically
+  on 32-bit architectures but allow two consecutive 32-bit accesses instead.
+  Since it depends on the particular device which of the two halves has to be
+  accessed first, a helper is provided for each combination of 64-bit accessors
+  with either low/high or high/low word ordering. A device driver must include
+  either <linux/io-64-nonatomic-lo-hi.h> or <linux/io-64-nonatomic-hi-lo.h> to
+  get the function definitions along with helpers that redirect the normal
+  readq()/writeq() to them on architectures that do not provide 64-bit access
+  natively.
+
+__raw_readq(), __raw_readl(), __raw_readw(), __raw_readb(),
+__raw_writeq(), __raw_writel(), __raw_writew(), __raw_writeb()
+
+  These are low-level MMIO accessors without barriers or byteorder changes and
+  architecture specific behavior. Accesses are usually atomic in the sense that
+  a four-byte __raw_readl() does not get split into individual byte loads, but
+  multiple consecutive accesses can be combined on the bus. In portable code, it
+  is only safe to use these to access memory behind a device bus but not MMIO
+  registers, as there are no ordering guarantees with regard to other MMIO
+  accesses or even spinlocks. The byte order is generally the same as for normal
+  memory, so unlike the other functions, these can be used to copy data between
+  kernel memory and device memory.
+
+inl(), inw(), inb(), outl(), outw(), outb()
+
+  PCI I/O port resources traditionally require separate helpers as they are
+  implemented using special instructions on the x86 architecture. On most other
+  architectures, these are mapped to readl()/writel() style accessors
+  internally, usually pointing to a fixed area in virtual memory. Instead of an
+  ``__iomem`` pointer, the address is a 32-bit integer token to identify a port
+  number. PCI requires I/O port access to be non-posted, meaning that an outb()
+  must complete before the following code executes, while a normal writeb() may
+  still be in progress. On architectures that correctly implement this, I/O port
+  access is therefore ordered against spinlocks. Many non-x86 PCI host bridge
+  implementations and CPU architectures however fail to implement non-posted I/O
+  space on PCI, so they can end up being posted on such hardware.
+
+  In some architectures, the I/O port number space has a 1:1 mapping to
+  ``__iomem`` pointers, but this is not recommended and device drivers should
+  not rely on that for portability. Similarly, an I/O port number as described
+  in a PCI base address register may not correspond to the port number as seen
+  by a device driver. Portable drivers need to read the port number for the
+  resource provided by the kernel.
+
+  There are no direct 64-bit I/O port accessors, but pci_iomap() in combination
+  with ioread64/iowrite64 can be used instead.
+
+inl_p(), inw_p(), inb_p(), outl_p(), outw_p(), outb_p()
+
+  On ISA devices that require specific timing, the _p versions of the I/O
+  accessors add a small delay. On architectures that do not have ISA buses,
+  these are aliases to the normal inb/outb helpers.
+
+readsq, readsl, readsw, readsb
+writesq, writesl, writesw, writesb
+ioread64_rep, ioread32_rep, ioread16_rep, ioread8_rep
+iowrite64_rep, iowrite32_rep, iowrite16_rep, iowrite8_rep
+insl, insw, insb, outsl, outsw, outsb
+
+  These are helpers that access the same address multiple times, usually to copy
+  data between kernel memory byte stream and a FIFO buffer. Unlike the normal
+  MMIO accessors, these do not perform a byteswap on big-endian kernels, so the
+  first byte in the FIFO register corresponds to the first byte in the memory
+  buffer regardless of the architecture.
+
 Public Functions Provided
 =========================
 
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:33 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:33 +0900
Subject: [PATCH v4 09/18] docs: driver-api: device-io: Document ioremap()
 variants & access funcs
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-10-marcan@marcan.st>

This documents the newly introduced ioremap_np() along with all the
other common ioremap() variants, and some higher-level abstractions
available.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 Documentation/driver-api/device-io.rst | 218 +++++++++++++++++++++++++
 1 file changed, 218 insertions(+)

diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst
index b20864b3ddc7..e9f04b1815d1 100644
--- a/Documentation/driver-api/device-io.rst
+++ b/Documentation/driver-api/device-io.rst
@@ -284,6 +284,224 @@ insl, insw, insb, outsl, outsw, outsb
   first byte in the FIFO register corresponds to the first byte in the memory
   buffer regardless of the architecture.
 
+Device memory mapping modes
+===========================
+
+Some architectures support multiple modes for mapping device memory.
+ioremap_*() variants provide a common abstraction around these
+architecture-specific modes, with a shared set of semantics.
+
+ioremap() is the most common mapping type, and is applicable to typical device
+memory (e.g. I/O registers). Other modes can offer weaker or stronger
+guarantees, if supported by the architecture. From most to least common, they
+are as follows:
+
+ioremap()
+---------
+
+The default mode, suitable for most memory-mapped devices, e.g. control
+registers. Memory mapped using ioremap() has the following characteristics:
+
+* Uncached - CPU-side caches are bypassed, and all reads and writes are handled
+  directly by the device
+* No speculative operations - the CPU may not issue a read or write to this
+  memory, unless the instruction that does so has been reached in committed
+  program flow.
+* No reordering - The CPU may not reorder accesses to this memory mapping with
+  respect to each other. On some architectures, this relies on barriers in
+  readl_relaxed()/writel_relaxed().
+* No repetition - The CPU may not issue multiple reads or writes for a single
+  program instruction.
+* No write-combining - Each I/O operation results in one discrete read or write
+  being issued to the device, and multiple writes are not combined into larger
+  writes. This may or may not be enforced when using __raw I/O accessors or
+  pointer dereferences.
+* Non-executable - The CPU is not allowed to speculate instruction execution
+  from this memory (it probably goes without saying, but you're also not
+  allowed to jump into device memory).
+
+On many platforms and buses (e.g. PCI), writes issued through ioremap()
+mappings are posted, which means that the CPU does not wait for the write to
+actually reach the target device before retiring the write instruction.
+
+On many platforms, I/O accesses must be aligned with respect to the access
+size; failure to do so will result in an exception or unpredictable results.
+
+ioremap_wc()
+------------
+
+Maps I/O memory as normal memory with write combining. Unlike ioremap(),
+
+* The CPU may speculatively issue reads from the device that the program
+  didn't actually execute, and may choose to basically read whatever it wants.
+* The CPU may reorder operations as long as the result is consistent from the
+  program's point of view.
+* The CPU may write to the same location multiple times, even when the program
+  issued a single write.
+* The CPU may combine several writes into a single larger write.
+
+This mode is typically used for video framebuffers, where it can increase
+performance of writes. It can also be used for other blocks of memory in
+devices (e.g. buffers or shared memory), but care must be taken as accesses are
+not guaranteed to be ordered with respect to normal ioremap() MMIO register
+accesses without explicit barriers.
+
+On a PCI bus, it is usually safe to use ioremap_wc() on MMIO areas marked as
+``IORESOURCE_PREFETCH``, but it may not be used on those without the flag.
+For on-chip devices, there is no corresponding flag, but a driver can use
+ioremap_wc() on a device that is known to be safe.
+
+ioremap_wt()
+------------
+
+Maps I/O memory as normal memory with write-through caching. Like ioremap_wc(),
+but also,
+
+* The CPU may cache writes issued to and reads from the device, and serve reads
+  from that cache.
+
+This mode is sometimes used for video framebuffers, where drivers still expect
+writes to reach the device in a timely manner (and not be stuck in the CPU
+cache), but reads may be served from the cache for efficiency. However, it is
+rarely useful these days, as framebuffer drivers usually perform writes only,
+for which ioremap_wc() is more efficient (as it doesn't needlessly trash the
+cache). Most drivers should not use this.
+
+ioremap_np()
+------------
+
+Like ioremap(), but explicitly requests non-posted write semantics. On some
+architectures and buses, ioremap() mappings have posted write semantics, which
+means that writes can appear to "complete" from the point of view of the
+CPU before the written data actually arrives at the target device. Writes are
+still ordered with respect to other writes and reads from the same device, but
+due to the posted write semantics, this is not the case with respect to other
+devices. ioremap_np() explicitly requests non-posted semantics, which means
+that the write instruction will not appear to complete until the device has
+received (and to some platform-specific extent acknowledged) the written data.
+
+This mapping mode primarily exists to cater for platforms with bus fabrics that
+require this particular mapping mode to work correctly. These platforms set the
+``IORESOURCE_MEM_NONPOSTED`` flag for a resource that requires ioremap_np()
+semantics and portable drivers should use an abstraction that automatically
+selects it where appropriate (see the `Higher-level ioremap abstractions`_
+section below).
+
+The bare ioremap_np() is only available on some architectures; on others, it
+always returns NULL. Drivers should not normally use it, unless they are
+platform-specific or they derive benefit from non-posted writes where
+supported, and can fall back to ioremap() otherwise. The normal approach to
+ensure posted write completion is to do a dummy read after a write as
+explained in `Accessing the device`_, which works with ioremap() on all
+platforms.
+
+ioremap_np() should never be used for PCI drivers. PCI memory space writes are
+always posted, even on architectures that otherwise implement ioremap_np().
+Using ioremap_np() for PCI BARs will at best result in posted write semantics,
+and at worst result in complete breakage.
+
+Note that non-posted write semantics are orthogonal to CPU-side ordering
+guarantees. A CPU may still choose to issue other reads or writes before a
+non-posted write instruction retires. See the previous section on MMIO access
+functions for details on the CPU side of things.
+
+ioremap_uc()
+------------
+
+ioremap_uc() behaves like ioremap() except that on the x86 architecture without
+'PAT' mode, it marks memory as uncached even when the MTRR has designated
+it as cacheable, see Documentation/x86/pat.rst.
+
+Portable drivers should avoid the use of ioremap_uc().
+
+ioremap_cache()
+---------------
+
+ioremap_cache() effectively maps I/O memory as normal RAM. CPU write-back
+caches can be used, and the CPU is free to treat the device as if it were a
+block of RAM. This should never be used for device memory which has side
+effects of any kind, or which does not return the data previously written on
+read.
+
+It should also not be used for actual RAM, as the returned pointer is an
+``__iomem`` token. memremap() can be used for mapping normal RAM that is outside
+of the linear kernel memory area to a regular pointer.
+
+Portable drivers should avoid the use of ioremap_cache().
+
+Architecture example
+--------------------
+
+Here is how the above modes map to memory attribute settings on the ARM64
+architecture:
+
++------------------------+--------------------------------------------+
+| API                    | Memory region type and cacheability        |
++------------------------+--------------------------------------------+
+| ioremap_np()           | Device-nGnRnE                              |
++------------------------+--------------------------------------------+
+| ioremap()              | Device-nGnRE                               |
++------------------------+--------------------------------------------+
+| ioremap_uc()           | (not implemented)                          |
++------------------------+--------------------------------------------+
+| ioremap_wc()           | Normal-Non Cacheable                       |
++------------------------+--------------------------------------------+
+| ioremap_wt()           | (not implemented; fallback to ioremap)     |
++------------------------+--------------------------------------------+
+| ioremap_cache()        | Normal-Write-Back Cacheable                |
++------------------------+--------------------------------------------+
+
+Higher-level ioremap abstractions
+=================================
+
+Instead of using the above raw ioremap() modes, drivers are encouraged to use
+higher-level APIs. These APIs may implement platform-specific logic to
+automatically choose an appropriate ioremap mode on any given bus, allowing for
+a platform-agnostic driver to work on those platforms without any special
+cases. At the time of this writing, the following ioremap() wrappers have such
+logic:
+
+devm_ioremap_resource()
+
+  Can automatically select ioremap_np() over ioremap() according to platform
+  requirements, if the ``IORESOURCE_MEM_NONPOSTED`` flag is set on the struct
+  resource. Uses devres to automatically unmap the resource when the driver
+  probe() function fails or a device in unbound from its driver.
+
+  Documented in Documentation/driver-api/driver-model/devres.rst.
+
+of_address_to_resource()
+
+  Automatically sets the ``IORESOURCE_MEM_NONPOSTED`` flag for platforms that
+  require non-posted writes for certain buses (see the nonposted-mmio and
+  posted-mmio device tree properties).
+
+of_iomap()
+
+  Maps the resource described in a ``reg`` property in the device tree, doing
+  all required translations. Automatically selects ioremap_np() according to
+  platform requirements, as above.
+
+pci_ioremap_bar(), pci_ioremap_wc_bar()
+
+  Maps the resource described in a PCI base address without having to extract
+  the physical address first.
+
+pci_iomap(), pci_iomap_wc()
+
+  Like pci_ioremap_bar()/pci_ioremap_bar(), but also works on I/O space when
+  used together with ioread32()/iowrite32() and similar accessors
+
+pcim_iomap()
+
+  Like pci_iomap(), but uses devres to automatically unmap the resource when
+  the driver probe() function fails or a device in unbound from its driver
+
+  Documented in Documentation/driver-api/driver-model/devres.rst.
+
+Not using these wrappers may make drivers unusable on certain platforms with
+stricter rules for mapping I/O memory.
+
 Public Functions Provided
 =========================
 
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:34 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:34 +0900
Subject: [PATCH v4 10/18] arm64: Implement ioremap_np() to map MMIO as nGnRnE
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-11-marcan@marcan.st>

This is used on Apple ARM platforms, which require most MMIO
(except PCI devices) to be mapped as nGnRnE.

Acked-by: Marc Zyngier <maz at kernel.org>
Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 arch/arm64/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 5ea8656a2030..953b8703af60 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -169,6 +169,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
 
 #define ioremap(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size)		__ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
+#define ioremap_np(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
 
 /*
  * PCI configuration space mapping function.
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:35 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:35 +0900
Subject: [PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace using
 ioremap_np
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-12-marcan@marcan.st>

Now that we have ioremap_np(), we can make pci_remap_cfgspace() default
to it, falling back to ioremap() on platforms where it is not available.

Remove the arm64 implementation, since that is now redundant. Future
cleanups should be able to do the same for other arches, and eventually
make the generic pci_remap_cfgspace() unconditional.

Signed-off-by: Hector Martin <marcan at marcan.st>
---
 arch/arm64/include/asm/io.h | 10 ----------
 include/linux/io.h          | 21 +++++++++++++--------
 2 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 953b8703af60..7fd836bea7eb 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -171,16 +171,6 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
 #define ioremap_wc(addr, size)		__ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
 #define ioremap_np(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
 
-/*
- * PCI configuration space mapping function.
- *
- * The PCI specification disallows posted write configuration transactions.
- * Add an arch specific pci_remap_cfgspace() definition that is implemented
- * through nGnRnE device memory attribute as recommended by the ARM v8
- * Architecture reference manual Issue A.k B2.8.2 "Device memory".
- */
-#define pci_remap_cfgspace(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
-
 /*
  * io{read,write}{16,32,64}be() macros
  */
diff --git a/include/linux/io.h b/include/linux/io.h
index d718354ed3e1..6f6b9233f2c3 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -82,20 +82,25 @@ void devm_memunmap(struct device *dev, void *addr);
 #ifdef CONFIG_PCI
 /*
  * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
- * Posting") mandate non-posted configuration transactions. There is
- * no ioremap API in the kernel that can guarantee non-posted write
- * semantics across arches so provide a default implementation for
- * mapping PCI config space that defaults to ioremap(); arches
- * should override it if they have memory mapping implementations that
- * guarantee non-posted writes semantics to make the memory mapping
- * compliant with the PCI specification.
+ * Posting") mandate non-posted configuration transactions. This default
+ * implementation attempts to use the ioremap_np() API to provide this
+ * on arches that support it, and falls back to ioremap() on those that
+ * don't. Overriding this function is deprecated; arches that properly
+ * support non-posted accesses should implement ioremap_np() instead, which
+ * this default implementation can then use to return mappings compliant with
+ * the PCI specification.
  */
 #ifndef pci_remap_cfgspace
 #define pci_remap_cfgspace pci_remap_cfgspace
 static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
 					       size_t size)
 {
-	return ioremap(offset, size);
+	void __iomem *ret = ioremap_np(offset, size);
+
+	if (!ret)
+		ret = ioremap(offset, size);
+
+	return ret;
 }
 #endif
 #endif
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:36 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:36 +0900
Subject: [PATCH v4 12/18] of/address: Add infrastructure to declare MMIO as
 non-posted
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-13-marcan@marcan.st>

This implements the 'nonposted-mmio' boolean property. Placing this
property in a bus marks all direct child devices as requiring
non-posted MMIO mappings. If no such property is found, the default
is posted MMIO.

of_mmio_is_nonposted() performs this check to determine if a given
device has requested non-posted MMIO.

of_address_to_resource() uses this to set the IORESOURCE_MEM_NONPOSTED
flag on resources that require non-posted MMIO.

of_iomap() and of_io_request_and_map() then use this flag to pick the
correct ioremap() variant.

This mechanism is currently restricted to builds that support Apple ARM
platforms, as an optimization.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 drivers/of/address.c       | 43 ++++++++++++++++++++++++++++++++++++--
 include/linux/of_address.h |  1 +
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..6485cc536e81 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -847,6 +847,9 @@ static int __of_address_to_resource(struct device_node *dev,
 		return -EINVAL;
 	memset(r, 0, sizeof(struct resource));
 
+	if (of_mmio_is_nonposted(dev))
+		flags |= IORESOURCE_MEM_NONPOSTED;
+
 	r->start = taddr;
 	r->end = taddr + size - 1;
 	r->flags = flags;
@@ -896,7 +899,10 @@ void __iomem *of_iomap(struct device_node *np, int index)
 	if (of_address_to_resource(np, index, &res))
 		return NULL;
 
-	return ioremap(res.start, resource_size(&res));
+	if (res.flags & IORESOURCE_MEM_NONPOSTED)
+		return ioremap_np(res.start, resource_size(&res));
+	else
+		return ioremap(res.start, resource_size(&res));
 }
 EXPORT_SYMBOL(of_iomap);
 
@@ -928,7 +934,11 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
 	if (!request_mem_region(res.start, resource_size(&res), name))
 		return IOMEM_ERR_PTR(-EBUSY);
 
-	mem = ioremap(res.start, resource_size(&res));
+	if (res.flags & IORESOURCE_MEM_NONPOSTED)
+		mem = ioremap_np(res.start, resource_size(&res));
+	else
+		mem = ioremap(res.start, resource_size(&res));
+
 	if (!mem) {
 		release_mem_region(res.start, resource_size(&res));
 		return IOMEM_ERR_PTR(-ENOMEM);
@@ -1094,3 +1104,32 @@ bool of_dma_is_coherent(struct device_node *np)
 	return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/**
+ * of_mmio_is_nonposted - Check if device uses non-posted MMIO
+ * @np:	device node
+ *
+ * Returns true if the "nonposted-mmio" property was found for
+ * the device's bus.
+ *
+ * This is currently only enabled on builds that support Apple ARM devices, as
+ * an optimization.
+ */
+bool of_mmio_is_nonposted(struct device_node *np)
+{
+	struct device_node *parent;
+	bool nonposted;
+
+	if (!IS_ENABLED(CONFIG_ARCH_APPLE))
+		return false;
+
+	parent = of_get_parent(np);
+	if (!parent)
+		return false;
+
+	nonposted = of_property_read_bool(parent, "nonposted-mmio");
+
+	of_node_put(parent);
+	return nonposted;
+}
+EXPORT_SYMBOL_GPL(of_mmio_is_nonposted);
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 88bc943405cd..88f6333fee6c 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -62,6 +62,7 @@ extern struct of_pci_range *of_pci_range_parser_one(
 					struct of_pci_range_parser *parser,
 					struct of_pci_range *range);
 extern bool of_dma_is_coherent(struct device_node *np);
+extern bool of_mmio_is_nonposted(struct device_node *np);
 #else /* CONFIG_OF_ADDRESS */
 static inline void __iomem *of_io_request_and_map(struct device_node *device,
 						  int index, const char *name)
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:37 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:37 +0900
Subject: [PATCH v4 13/18] arm64: Move ICH_ sysreg bits from arm-gic-v3.h to
 sysreg.h
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-14-marcan@marcan.st>

These definitions are in arm-gic-v3.h for historical reasons which no
longer apply. Move them to sysreg.h so the AIC driver can use them, as
it needs to peek into vGIC registers to deal with the GIC maintentance
interrupt.

Acked-by: Marc Zyngier <maz at kernel.org>
Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 arch/arm64/include/asm/sysreg.h    | 60 ++++++++++++++++++++++++++++++
 include/linux/irqchip/arm-gic-v3.h | 56 ----------------------------
 2 files changed, 60 insertions(+), 56 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..609dc42ec8c8 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -1032,6 +1032,66 @@
 #define TRFCR_ELx_ExTRE			BIT(1)
 #define TRFCR_ELx_E0TRE			BIT(0)
 
+
+/* GIC Hypervisor interface registers */
+/* ICH_MISR_EL2 bit definitions */
+#define ICH_MISR_EOI		(1 << 0)
+#define ICH_MISR_U		(1 << 1)
+
+/* ICH_LR*_EL2 bit definitions */
+#define ICH_LR_VIRTUAL_ID_MASK	((1ULL << 32) - 1)
+
+#define ICH_LR_EOI		(1ULL << 41)
+#define ICH_LR_GROUP		(1ULL << 60)
+#define ICH_LR_HW		(1ULL << 61)
+#define ICH_LR_STATE		(3ULL << 62)
+#define ICH_LR_PENDING_BIT	(1ULL << 62)
+#define ICH_LR_ACTIVE_BIT	(1ULL << 63)
+#define ICH_LR_PHYS_ID_SHIFT	32
+#define ICH_LR_PHYS_ID_MASK	(0x3ffULL << ICH_LR_PHYS_ID_SHIFT)
+#define ICH_LR_PRIORITY_SHIFT	48
+#define ICH_LR_PRIORITY_MASK	(0xffULL << ICH_LR_PRIORITY_SHIFT)
+
+/* ICH_HCR_EL2 bit definitions */
+#define ICH_HCR_EN		(1 << 0)
+#define ICH_HCR_UIE		(1 << 1)
+#define ICH_HCR_NPIE		(1 << 3)
+#define ICH_HCR_TC		(1 << 10)
+#define ICH_HCR_TALL0		(1 << 11)
+#define ICH_HCR_TALL1		(1 << 12)
+#define ICH_HCR_EOIcount_SHIFT	27
+#define ICH_HCR_EOIcount_MASK	(0x1f << ICH_HCR_EOIcount_SHIFT)
+
+/* ICH_VMCR_EL2 bit definitions */
+#define ICH_VMCR_ACK_CTL_SHIFT	2
+#define ICH_VMCR_ACK_CTL_MASK	(1 << ICH_VMCR_ACK_CTL_SHIFT)
+#define ICH_VMCR_FIQ_EN_SHIFT	3
+#define ICH_VMCR_FIQ_EN_MASK	(1 << ICH_VMCR_FIQ_EN_SHIFT)
+#define ICH_VMCR_CBPR_SHIFT	4
+#define ICH_VMCR_CBPR_MASK	(1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_EOIM_SHIFT	9
+#define ICH_VMCR_EOIM_MASK	(1 << ICH_VMCR_EOIM_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT	18
+#define ICH_VMCR_BPR1_MASK	(7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT	21
+#define ICH_VMCR_BPR0_MASK	(7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_PMR_SHIFT	24
+#define ICH_VMCR_PMR_MASK	(0xffUL << ICH_VMCR_PMR_SHIFT)
+#define ICH_VMCR_ENG0_SHIFT	0
+#define ICH_VMCR_ENG0_MASK	(1 << ICH_VMCR_ENG0_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT	1
+#define ICH_VMCR_ENG1_MASK	(1 << ICH_VMCR_ENG1_SHIFT)
+
+/* ICH_VTR_EL2 bit definitions */
+#define ICH_VTR_PRI_BITS_SHIFT	29
+#define ICH_VTR_PRI_BITS_MASK	(7 << ICH_VTR_PRI_BITS_SHIFT)
+#define ICH_VTR_ID_BITS_SHIFT	23
+#define ICH_VTR_ID_BITS_MASK	(7 << ICH_VTR_ID_BITS_SHIFT)
+#define ICH_VTR_SEIS_SHIFT	22
+#define ICH_VTR_SEIS_MASK	(1 << ICH_VTR_SEIS_SHIFT)
+#define ICH_VTR_A3V_SHIFT	21
+#define ICH_VTR_A3V_MASK	(1 << ICH_VTR_A3V_SHIFT)
+
 #ifdef __ASSEMBLY__
 
 	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index f6d092fdb93d..81cbf85f73de 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -575,67 +575,11 @@
 #define ICC_SRE_EL1_DFB			(1U << 1)
 #define ICC_SRE_EL1_SRE			(1U << 0)
 
-/*
- * Hypervisor interface registers (SRE only)
- */
-#define ICH_LR_VIRTUAL_ID_MASK		((1ULL << 32) - 1)
-
-#define ICH_LR_EOI			(1ULL << 41)
-#define ICH_LR_GROUP			(1ULL << 60)
-#define ICH_LR_HW			(1ULL << 61)
-#define ICH_LR_STATE			(3ULL << 62)
-#define ICH_LR_PENDING_BIT		(1ULL << 62)
-#define ICH_LR_ACTIVE_BIT		(1ULL << 63)
-#define ICH_LR_PHYS_ID_SHIFT		32
-#define ICH_LR_PHYS_ID_MASK		(0x3ffULL << ICH_LR_PHYS_ID_SHIFT)
-#define ICH_LR_PRIORITY_SHIFT		48
-#define ICH_LR_PRIORITY_MASK		(0xffULL << ICH_LR_PRIORITY_SHIFT)
-
 /* These are for GICv2 emulation only */
 #define GICH_LR_VIRTUALID		(0x3ffUL << 0)
 #define GICH_LR_PHYSID_CPUID_SHIFT	(10)
 #define GICH_LR_PHYSID_CPUID		(7UL << GICH_LR_PHYSID_CPUID_SHIFT)
 
-#define ICH_MISR_EOI			(1 << 0)
-#define ICH_MISR_U			(1 << 1)
-
-#define ICH_HCR_EN			(1 << 0)
-#define ICH_HCR_UIE			(1 << 1)
-#define ICH_HCR_NPIE			(1 << 3)
-#define ICH_HCR_TC			(1 << 10)
-#define ICH_HCR_TALL0			(1 << 11)
-#define ICH_HCR_TALL1			(1 << 12)
-#define ICH_HCR_EOIcount_SHIFT		27
-#define ICH_HCR_EOIcount_MASK		(0x1f << ICH_HCR_EOIcount_SHIFT)
-
-#define ICH_VMCR_ACK_CTL_SHIFT		2
-#define ICH_VMCR_ACK_CTL_MASK		(1 << ICH_VMCR_ACK_CTL_SHIFT)
-#define ICH_VMCR_FIQ_EN_SHIFT		3
-#define ICH_VMCR_FIQ_EN_MASK		(1 << ICH_VMCR_FIQ_EN_SHIFT)
-#define ICH_VMCR_CBPR_SHIFT		4
-#define ICH_VMCR_CBPR_MASK		(1 << ICH_VMCR_CBPR_SHIFT)
-#define ICH_VMCR_EOIM_SHIFT		9
-#define ICH_VMCR_EOIM_MASK		(1 << ICH_VMCR_EOIM_SHIFT)
-#define ICH_VMCR_BPR1_SHIFT		18
-#define ICH_VMCR_BPR1_MASK		(7 << ICH_VMCR_BPR1_SHIFT)
-#define ICH_VMCR_BPR0_SHIFT		21
-#define ICH_VMCR_BPR0_MASK		(7 << ICH_VMCR_BPR0_SHIFT)
-#define ICH_VMCR_PMR_SHIFT		24
-#define ICH_VMCR_PMR_MASK		(0xffUL << ICH_VMCR_PMR_SHIFT)
-#define ICH_VMCR_ENG0_SHIFT		0
-#define ICH_VMCR_ENG0_MASK		(1 << ICH_VMCR_ENG0_SHIFT)
-#define ICH_VMCR_ENG1_SHIFT		1
-#define ICH_VMCR_ENG1_MASK		(1 << ICH_VMCR_ENG1_SHIFT)
-
-#define ICH_VTR_PRI_BITS_SHIFT		29
-#define ICH_VTR_PRI_BITS_MASK		(7 << ICH_VTR_PRI_BITS_SHIFT)
-#define ICH_VTR_ID_BITS_SHIFT		23
-#define ICH_VTR_ID_BITS_MASK		(7 << ICH_VTR_ID_BITS_SHIFT)
-#define ICH_VTR_SEIS_SHIFT		22
-#define ICH_VTR_SEIS_MASK		(1 << ICH_VTR_SEIS_SHIFT)
-#define ICH_VTR_A3V_SHIFT		21
-#define ICH_VTR_A3V_MASK		(1 << ICH_VTR_A3V_SHIFT)
-
 #define ICC_IAR1_EL1_SPURIOUS		0x3ff
 
 #define ICC_SRE_EL2_SRE			(1 << 0)
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:38 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:38 +0900
Subject: [PATCH v4 14/18] dt-bindings: interrupt-controller: Add DT bindings
 for apple-aic
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-15-marcan@marcan.st>

AIC is the Apple Interrupt Controller found on Apple ARM SoCs, such as
the M1.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 .../interrupt-controller/apple,aic.yaml       | 88 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 .../interrupt-controller/apple-aic.h          | 15 ++++
 3 files changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h

diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
new file mode 100644
index 000000000000..cf6c091a07b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/apple,aic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple Interrupt Controller
+
+maintainers:
+  - Hector Martin <marcan at marcan.st>
+
+description: |
+  The Apple Interrupt Controller is a simple interrupt controller present on
+  Apple ARM SoC platforms, including various iPhone and iPad devices and the
+  "Apple Silicon" Macs.
+
+  It provides the following features:
+
+  - Level-triggered hardware IRQs wired to SoC blocks
+    - Single mask bit per IRQ
+    - Per-IRQ affinity setting
+    - Automatic masking on event delivery (auto-ack)
+    - Software triggering (ORed with hw line)
+  - 2 per-CPU IPIs (meant as "self" and "other", but they are interchangeable
+    if not symmetric)
+  - Automatic prioritization (single event/ack register per CPU, lower IRQs =
+    higher priority)
+  - Automatic masking on ack
+  - Default "this CPU" register view and explicit per-CPU views
+
+  This device also represents the FIQ interrupt sources on platforms using AIC,
+  which do not go through a discrete interrupt controller.
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+  compatible:
+    items:
+      - const: apple,t8103-aic
+      - const: apple,aic
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+    const: 3
+    description: |
+      The 1st cell contains the interrupt type:
+        - 0: Hardware IRQ
+        - 1: FIQ
+
+      The 2nd cell contains the interrupt number.
+        - HW IRQs: interrupt number
+        - FIQs:
+          - 0: physical HV timer
+          - 1: virtual HV timer
+          - 2: physical guest timer
+          - 3: virtual guest timer
+
+      The 3rd cell contains the interrupt flags. This is normally
+      IRQ_TYPE_LEVEL_HIGH (4).
+
+  reg:
+    description: |
+      Specifies base physical address and size of the AIC registers.
+    maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        aic: interrupt-controller at 23b100000 {
+            compatible = "apple,t8103-aic", "apple,aic";
+            #interrupt-cells = <3>;
+            interrupt-controller;
+            reg = <0x2 0x3b100000 0x0 0x8000>;
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index bee9a57e6cec..b26a7e23c512 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1646,6 +1646,7 @@ B:	https://github.com/AsahiLinux/linux/issues
 C:	irc://chat.freenode.net/asahi-dev
 T:	git https://github.com/AsahiLinux/linux.git
 F:	Documentation/devicetree/bindings/arm/apple.yaml
+F:	Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 
 ARM/ARTPEC MACHINE SUPPORT
 M:	Jesper Nilsson <jesper.nilsson at axis.com>
diff --git a/include/dt-bindings/interrupt-controller/apple-aic.h b/include/dt-bindings/interrupt-controller/apple-aic.h
new file mode 100644
index 000000000000..604f2bb30ac0
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/apple-aic.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR MIT */
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+#define AIC_IRQ	0
+#define AIC_FIQ	1
+
+#define AIC_TMR_HV_PHYS		0
+#define AIC_TMR_HV_VIRT		1
+#define AIC_TMR_GUEST_PHYS	2
+#define AIC_TMR_GUEST_VIRT	3
+
+#endif
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:39 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:39 +0900
Subject: [PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-16-marcan@marcan.st>

This is the root interrupt controller used on Apple ARM SoCs such as the
M1. This irqchip driver performs multiple functions:

* Handles both IRQs and FIQs

* Drives the AIC peripheral itself (which handles IRQs)

* Dispatches FIQs to downstream hard-wired clients (currently the ARM
  timer).

* Implements a virtual IPI multiplexer to funnel multiple Linux IPIs
  into a single hardware IPI

Signed-off-by: Hector Martin <marcan at marcan.st>
---
 MAINTAINERS                     |   2 +
 drivers/irqchip/Kconfig         |   8 +
 drivers/irqchip/Makefile        |   1 +
 drivers/irqchip/irq-apple-aic.c | 837 ++++++++++++++++++++++++++++++++
 include/linux/cpuhotplug.h      |   1 +
 5 files changed, 849 insertions(+)
 create mode 100644 drivers/irqchip/irq-apple-aic.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b26a7e23c512..e27332ec1f12 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1647,6 +1647,8 @@ C:	irc://chat.freenode.net/asahi-dev
 T:	git https://github.com/AsahiLinux/linux.git
 F:	Documentation/devicetree/bindings/arm/apple.yaml
 F:	Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
+F:	drivers/irqchip/irq-apple-aic.c
+F:	include/dt-bindings/interrupt-controller/apple-aic.h
 
 ARM/ARTPEC MACHINE SUPPORT
 M:	Jesper Nilsson <jesper.nilsson at axis.com>
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 15536e321df5..d3a14f304ec8 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -577,4 +577,12 @@ config MST_IRQ
 	help
 	  Support MStar Interrupt Controller.
 
+config APPLE_AIC
+	bool "Apple Interrupt Controller (AIC)"
+	depends on ARM64
+	default ARCH_APPLE
+	help
+	  Support for the Apple Interrupt Controller found on Apple Silicon SoCs,
+	  such as the M1.
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c59b95a0532c..eb6a515f0f64 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_LOONGSON_PCH_MSI)		+= irq-loongson-pch-msi.o
 obj-$(CONFIG_MST_IRQ)			+= irq-mst-intc.o
 obj-$(CONFIG_SL28CPLD_INTC)		+= irq-sl28cpld.o
 obj-$(CONFIG_MACH_REALTEK_RTL)		+= irq-realtek-rtl.o
+obj-$(CONFIG_APPLE_AIC)			+= irq-apple-aic.o
diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c
new file mode 100644
index 000000000000..ed16b6cc00d7
--- /dev/null
+++ b/drivers/irqchip/irq-apple-aic.c
@@ -0,0 +1,837 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright The Asahi Linux Contributors
+ *
+ * Based on irq-lpc32xx:
+ *   Copyright 2015-2016 Vladimir Zapolskiy <vz at mleia.com>
+ * Based on irq-bcm2836:
+ *   Copyright 2015 Broadcom
+ */
+
+/*
+ * AIC is a fairly simple interrupt controller with the following features:
+ *
+ * - 896 level-triggered hardware IRQs
+ *   - Single mask bit per IRQ
+ *   - Per-IRQ affinity setting
+ *   - Automatic masking on event delivery (auto-ack)
+ *   - Software triggering (ORed with hw line)
+ * - 2 per-CPU IPIs (meant as "self" and "other", but they are
+ *   interchangeable if not symmetric)
+ * - Automatic prioritization (single event/ack register per CPU, lower IRQs =
+ *   higher priority)
+ * - Automatic masking on ack
+ * - Default "this CPU" register view and explicit per-CPU views
+ *
+ * In addition, this driver also handles FIQs, as these are routed to the same
+ * IRQ vector. These are used for Fast IPIs (TODO), the ARMv8 timer IRQs, and
+ * performance counters (TODO).
+ *
+ * Implementation notes:
+ *
+ * - This driver creates two IRQ domains, one for HW IRQs and internal FIQs,
+ *   and one for IPIs.
+ * - Since Linux needs more than 2 IPIs, we implement a software IRQ controller
+ *   and funnel all IPIs into one per-CPU IPI (the second "self" IPI is unused).
+ * - FIQ hwirq numbers are assigned after true hwirqs, and are per-cpu.
+ * - DT bindings use 3-cell form (like GIC):
+ *   - <0 nr flags> - hwirq #nr
+ *   - <1 nr flags> - FIQ #nr
+ *     - nr=0  Physical HV timer
+ *     - nr=1  Virtual HV timer
+ *     - nr=2  Physical guest timer
+ *     - nr=3  Virtual guest timer
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/bits.h>
+#include <linux/bitfield.h>
+#include <linux/cpuhotplug.h>
+#include <linux/io.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/limits.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <asm/exception.h>
+#include <asm/sysreg.h>
+#include <asm/virt.h>
+
+#include <dt-bindings/interrupt-controller/apple-aic.h>
+
+/*
+ * AIC registers (MMIO)
+ */
+
+#define AIC_INFO		0x0004
+#define AIC_INFO_NR_HW		GENMASK(15, 0)
+
+#define AIC_CONFIG		0x0010
+
+#define AIC_WHOAMI		0x2000
+#define AIC_EVENT		0x2004
+#define AIC_EVENT_TYPE		GENMASK(31, 16)
+#define AIC_EVENT_NUM		GENMASK(15, 0)
+
+#define AIC_EVENT_TYPE_HW	1
+#define AIC_EVENT_TYPE_IPI	4
+#define AIC_EVENT_IPI_OTHER	1
+#define AIC_EVENT_IPI_SELF	2
+
+#define AIC_IPI_SEND		0x2008
+#define AIC_IPI_ACK		0x200c
+#define AIC_IPI_MASK_SET	0x2024
+#define AIC_IPI_MASK_CLR	0x2028
+
+#define AIC_IPI_SEND_CPU(cpu)	BIT(cpu)
+
+#define AIC_IPI_OTHER		BIT(0)
+#define AIC_IPI_SELF		BIT(31)
+
+#define AIC_TARGET_CPU		0x3000
+#define AIC_SW_SET		0x4000
+#define AIC_SW_CLR		0x4080
+#define AIC_MASK_SET		0x4100
+#define AIC_MASK_CLR		0x4180
+
+#define AIC_CPU_IPI_SET(cpu)	(0x5008 + ((cpu) << 7))
+#define AIC_CPU_IPI_CLR(cpu)	(0x500c + ((cpu) << 7))
+#define AIC_CPU_IPI_MASK_SET(cpu) (0x5024 + ((cpu) << 7))
+#define AIC_CPU_IPI_MASK_CLR(cpu) (0x5028 + ((cpu) << 7))
+
+#define MASK_REG(x)		(4 * ((x) >> 5))
+#define MASK_BIT(x)		BIT((x) & GENMASK(4, 0))
+
+/*
+ * IMP-DEF sysregs that control FIQ sources
+ * Note: sysreg-based IPIs are not supported yet.
+ */
+
+/* Core PMC control register */
+#define SYS_IMP_APL_PMCR0_EL1		sys_reg(3, 1, 15, 0, 0)
+#define PMCR0_IMODE			GENMASK(10, 8)
+#define PMCR0_IMODE_OFF			0
+#define PMCR0_IMODE_PMI			1
+#define PMCR0_IMODE_AIC			2
+#define PMCR0_IMODE_HALT		3
+#define PMCR0_IMODE_FIQ			4
+#define PMCR0_IACT			BIT(11)
+
+/* IPI request registers */
+#define SYS_IMP_APL_IPI_RR_LOCAL_EL1	sys_reg(3, 5, 15, 0, 0)
+#define SYS_IMP_APL_IPI_RR_GLOBAL_EL1	sys_reg(3, 5, 15, 0, 1)
+#define IPI_RR_CPU			GENMASK(7, 0)
+/* Cluster only used for the GLOBAL register */
+#define IPI_RR_CLUSTER			GENMASK(23, 16)
+#define IPI_RR_TYPE			GENMASK(29, 28)
+#define IPI_RR_IMMEDIATE		0
+#define IPI_RR_RETRACT			1
+#define IPI_RR_DEFERRED			2
+#define IPI_RR_NOWAKE			3
+
+/* IPI status register */
+#define SYS_IMP_APL_IPI_SR_EL1		sys_reg(3, 5, 15, 1, 1)
+#define IPI_SR_PENDING			BIT(0)
+
+/* Guest timer FIQ enable register */
+#define SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2	sys_reg(3, 5, 15, 1, 3)
+#define VM_TMR_FIQ_ENABLE_V		BIT(0)
+#define VM_TMR_FIQ_ENABLE_P		BIT(1)
+
+/* Deferred IPI countdown register */
+#define SYS_IMP_APL_IPI_CR_EL1		sys_reg(3, 5, 15, 3, 1)
+
+/* Uncore PMC control register */
+#define SYS_IMP_APL_UPMCR0_EL1		sys_reg(3, 7, 15, 0, 4)
+#define UPMCR0_IMODE			GENMASK(18, 16)
+#define UPMCR0_IMODE_OFF		0
+#define UPMCR0_IMODE_AIC		2
+#define UPMCR0_IMODE_HALT		3
+#define UPMCR0_IMODE_FIQ		4
+
+/* Uncore PMC status register */
+#define SYS_IMP_APL_UPMSR_EL1		sys_reg(3, 7, 15, 6, 4)
+#define UPMSR_IACT			BIT(0)
+
+#define AIC_NR_FIQ		4
+#define AIC_NR_SWIPI		32
+
+struct aic_irq_chip {
+	void __iomem *base;
+	struct irq_domain *hw_domain;
+	struct irq_domain *ipi_domain;
+	int nr_hw;
+	int ipi_hwirq;
+};
+
+static DEFINE_PER_CPU(uint32_t, aic_fiq_unmasked);
+
+static DEFINE_PER_CPU(atomic_t, aic_vipi_flag);
+static DEFINE_PER_CPU(atomic_t, aic_vipi_enable);
+
+static struct aic_irq_chip *aic_irqc;
+
+static void aic_handle_ipi(struct pt_regs *regs);
+
+static u32 aic_ic_read(struct aic_irq_chip *ic, u32 reg)
+{
+	return readl_relaxed(ic->base + reg);
+}
+
+static void aic_ic_write(struct aic_irq_chip *ic, u32 reg, u32 val)
+{
+	writel_relaxed(val, ic->base + reg);
+}
+
+/*
+ * IRQ irqchip
+ */
+
+static void aic_irq_mask(struct irq_data *d)
+{
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+
+	aic_ic_write(ic, AIC_MASK_SET + MASK_REG(irqd_to_hwirq(d)),
+		     MASK_BIT(irqd_to_hwirq(d)));
+}
+
+static void aic_irq_unmask(struct irq_data *d)
+{
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+
+	aic_ic_write(ic, AIC_MASK_CLR + MASK_REG(d->hwirq),
+		     MASK_BIT(irqd_to_hwirq(d)));
+}
+
+static void aic_irq_eoi(struct irq_data *d)
+{
+	/*
+	 * Reading the interrupt reason automatically acknowledges and masks
+	 * the IRQ, so we just unmask it here if needed.
+	 */
+	if (!irqd_irq_disabled(d) && !irqd_irq_masked(d))
+		aic_irq_unmask(d);
+}
+
+static void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+	struct aic_irq_chip *ic = aic_irqc;
+	u32 event, type, irq;
+
+	do {
+		/*
+		 * We cannot use a relaxed read here, as reads from DMA buffers
+		 * need to be ordered after the IRQ fires.
+		 */
+		event = readl(ic->base + AIC_EVENT);
+		type = FIELD_GET(AIC_EVENT_TYPE, event);
+		irq = FIELD_GET(AIC_EVENT_NUM, event);
+
+		if (type == AIC_EVENT_TYPE_HW)
+			handle_domain_irq(aic_irqc->hw_domain, irq, regs);
+		else if (type == AIC_EVENT_TYPE_IPI && irq == 1)
+			aic_handle_ipi(regs);
+		else if (event != 0)
+			pr_err_ratelimited("Unknown IRQ event %d, %d\n", type, irq);
+	} while (event);
+
+	/*
+	 * vGIC maintenance interrupts end up here too, so we need to check
+	 * for them separately. This should never trigger if KVM is working
+	 * properly, because it will have already taken care of clearing it
+	 * on guest exit before this handler runs.
+	 */
+	if (is_kernel_in_hyp_mode() && (read_sysreg_s(SYS_ICH_HCR_EL2) & ICH_HCR_EN) &&
+		read_sysreg_s(SYS_ICH_MISR_EL2) != 0) {
+		pr_err_ratelimited("vGIC IRQ fired and not handled by KVM, disabling.\n");
+		sysreg_clear_set_s(SYS_ICH_HCR_EL2, ICH_HCR_EN, 0);
+	}
+}
+
+static int aic_irq_set_affinity(struct irq_data *d,
+				const struct cpumask *mask_val, bool force)
+{
+	irq_hw_number_t hwirq = irqd_to_hwirq(d);
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+	int cpu;
+
+	if (force)
+		cpu = cpumask_first(mask_val);
+	else
+		cpu = cpumask_any_and(mask_val, cpu_online_mask);
+
+	aic_ic_write(ic, AIC_TARGET_CPU + hwirq * 4, BIT(cpu));
+	irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+	return IRQ_SET_MASK_OK;
+}
+
+static int aic_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	/*
+	 * Some IRQs (e.g. MSIs) implicitly have edge semantics, and we don't
+	 * have a way to find out the type of any given IRQ, so just allow both.
+	 */
+	return (type == IRQ_TYPE_LEVEL_HIGH || type == IRQ_TYPE_EDGE_RISING) ? 0 : -EINVAL;
+}
+
+static struct irq_chip aic_chip = {
+	.name = "AIC",
+	.irq_mask = aic_irq_mask,
+	.irq_unmask = aic_irq_unmask,
+	.irq_eoi = aic_irq_eoi,
+	.irq_set_affinity = aic_irq_set_affinity,
+	.irq_set_type = aic_irq_set_type,
+};
+
+/*
+ * FIQ irqchip
+ */
+
+static unsigned long aic_fiq_get_idx(struct irq_data *d)
+{
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+
+	return irqd_to_hwirq(d) - ic->nr_hw;
+}
+
+static void aic_fiq_set_mask(struct irq_data *d)
+{
+	/* Only the guest timers have real mask bits, unfortunately. */
+	switch (aic_fiq_get_idx(d)) {
+	case AIC_TMR_GUEST_PHYS:
+		sysreg_clear_set_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, VM_TMR_FIQ_ENABLE_P, 0);
+		isb();
+		break;
+	case AIC_TMR_GUEST_VIRT:
+		sysreg_clear_set_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, VM_TMR_FIQ_ENABLE_V, 0);
+		isb();
+		break;
+	default:
+		break;
+	}
+}
+
+static void aic_fiq_clear_mask(struct irq_data *d)
+{
+	switch (aic_fiq_get_idx(d)) {
+	case AIC_TMR_GUEST_PHYS:
+		sysreg_clear_set_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, 0, VM_TMR_FIQ_ENABLE_P);
+		isb();
+		break;
+	case AIC_TMR_GUEST_VIRT:
+		sysreg_clear_set_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2, 0, VM_TMR_FIQ_ENABLE_V);
+		isb();
+		break;
+	default:
+		break;
+	}
+}
+
+static void aic_fiq_mask(struct irq_data *d)
+{
+	aic_fiq_set_mask(d);
+	__this_cpu_and(aic_fiq_unmasked, ~BIT(aic_fiq_get_idx(d)));
+}
+
+static void aic_fiq_unmask(struct irq_data *d)
+{
+	aic_fiq_clear_mask(d);
+	__this_cpu_or(aic_fiq_unmasked, BIT(aic_fiq_get_idx(d)));
+}
+
+static void aic_fiq_eoi(struct irq_data *d)
+{
+	/* We mask to ack (where we can), so we need to unmask at EOI. */
+	if (__this_cpu_read(aic_fiq_unmasked) & BIT(aic_fiq_get_idx(d)))
+		aic_fiq_clear_mask(d);
+}
+
+#define TIMER_FIRING(x)                                                        \
+	(((x) & (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_MASK |            \
+		 ARCH_TIMER_CTRL_IT_STAT)) ==                                  \
+	 (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
+
+static void __exception_irq_entry aic_handle_fiq(struct pt_regs *regs)
+{
+	/*
+	 * It would be really nice if we had a system register that lets us get
+	 * the FIQ source state without having to peek down into sources...
+	 * but such a register does not seem to exist.
+	 *
+	 * So, we have these potential sources to test for:
+	 *  - Fast IPIs (not yet used)
+	 *  - The 4 timers (CNTP, CNTV for each of HV and guest)
+	 *  - Per-core PMCs (not yet supported)
+	 *  - Per-cluster uncore PMCs (not yet supported)
+	 *
+	 * Since not dealing with any of these results in a FIQ storm,
+	 * we check for everything here, even things we don't support yet.
+	 */
+
+	if (read_sysreg_s(SYS_IMP_APL_IPI_SR_EL1) & IPI_SR_PENDING) {
+		pr_err_ratelimited("Fast IPI fired. Acking.\n");
+		write_sysreg_s(IPI_SR_PENDING, SYS_IMP_APL_IPI_SR_EL1);
+	}
+
+	if (TIMER_FIRING(read_sysreg(cntp_ctl_el0)))
+		handle_domain_irq(aic_irqc->hw_domain,
+				  aic_irqc->nr_hw + AIC_TMR_HV_PHYS, regs);
+
+	if (TIMER_FIRING(read_sysreg(cntv_ctl_el0)))
+		handle_domain_irq(aic_irqc->hw_domain,
+				  aic_irqc->nr_hw + AIC_TMR_HV_VIRT, regs);
+
+	if (is_kernel_in_hyp_mode()) {
+		uint64_t enabled = read_sysreg_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2);
+
+		if ((enabled & VM_TMR_FIQ_ENABLE_P) &&
+		    TIMER_FIRING(read_sysreg_s(SYS_CNTP_CTL_EL02)))
+			handle_domain_irq(aic_irqc->hw_domain,
+					  aic_irqc->nr_hw + AIC_TMR_GUEST_PHYS, regs);
+
+		if ((enabled & VM_TMR_FIQ_ENABLE_V) &&
+		    TIMER_FIRING(read_sysreg_s(SYS_CNTV_CTL_EL02)))
+			handle_domain_irq(aic_irqc->hw_domain,
+					  aic_irqc->nr_hw + AIC_TMR_GUEST_VIRT, regs);
+	}
+
+	if ((read_sysreg_s(SYS_IMP_APL_PMCR0_EL1) & (PMCR0_IMODE | PMCR0_IACT)) ==
+			(FIELD_PREP(PMCR0_IMODE, PMCR0_IMODE_FIQ) | PMCR0_IACT)) {
+		/*
+		 * Not supported yet, let's figure out how to handle this when
+		 * we implement these proprietary performance counters. For now,
+		 * just mask it and move on.
+		 */
+		pr_err_ratelimited("PMC FIQ fired. Masking.\n");
+		sysreg_clear_set_s(SYS_IMP_APL_PMCR0_EL1, PMCR0_IMODE | PMCR0_IACT,
+				   FIELD_PREP(PMCR0_IMODE, PMCR0_IMODE_OFF));
+	}
+
+	if (FIELD_GET(UPMCR0_IMODE, read_sysreg_s(SYS_IMP_APL_UPMCR0_EL1)) == UPMCR0_IMODE_FIQ &&
+			(read_sysreg_s(SYS_IMP_APL_UPMSR_EL1) & UPMSR_IACT)) {
+		/* Same story with uncore PMCs */
+		pr_err_ratelimited("Uncore PMC FIQ fired. Masking.\n");
+		sysreg_clear_set_s(SYS_IMP_APL_UPMCR0_EL1, UPMCR0_IMODE,
+				   FIELD_PREP(UPMCR0_IMODE, UPMCR0_IMODE_OFF));
+	}
+}
+
+static int aic_fiq_set_type(struct irq_data *d, unsigned int type)
+{
+	return (type == IRQ_TYPE_LEVEL_HIGH) ? 0 : -EINVAL;
+}
+
+static struct irq_chip fiq_chip = {
+	.name = "AIC-FIQ",
+	.irq_mask = aic_fiq_mask,
+	.irq_unmask = aic_fiq_unmask,
+	.irq_ack = aic_fiq_set_mask,
+	.irq_eoi = aic_fiq_eoi,
+	.irq_set_type = aic_fiq_set_type,
+};
+
+/*
+ * Main IRQ domain
+ */
+
+static int aic_irq_domain_map(struct irq_domain *id, unsigned int irq,
+			      irq_hw_number_t hw)
+{
+	struct aic_irq_chip *ic = id->host_data;
+
+	if (hw < ic->nr_hw) {
+		irq_domain_set_info(id, irq, hw, &aic_chip, id->host_data,
+				    handle_fasteoi_irq, NULL, NULL);
+		irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(irq)));
+	} else {
+		irq_set_percpu_devid(irq);
+		irq_domain_set_info(id, irq, hw, &fiq_chip, id->host_data,
+				    handle_percpu_devid_irq, NULL, NULL);
+	}
+
+	return 0;
+}
+
+static int aic_irq_domain_translate(struct irq_domain *id,
+				    struct irq_fwspec *fwspec,
+				    unsigned long *hwirq,
+				    unsigned int *type)
+{
+	struct aic_irq_chip *ic = id->host_data;
+
+	if (fwspec->param_count != 3 || !is_of_node(fwspec->fwnode))
+		return -EINVAL;
+
+	switch (fwspec->param[0]) {
+	case AIC_IRQ:
+		if (fwspec->param[1] >= ic->nr_hw)
+			return -EINVAL;
+		*hwirq = fwspec->param[1];
+		break;
+	case AIC_FIQ:
+		if (fwspec->param[1] >= AIC_NR_FIQ)
+			return -EINVAL;
+		*hwirq = ic->nr_hw + fwspec->param[1];
+
+		/*
+		 * In EL1 the non-redirected registers are the guest's,
+		 * not EL2's, so remap the hwirqs to match.
+		 */
+		if (!is_kernel_in_hyp_mode()) {
+			switch (fwspec->param[1]) {
+			case AIC_TMR_GUEST_PHYS:
+				*hwirq = ic->nr_hw + AIC_TMR_HV_PHYS;
+				break;
+			case AIC_TMR_GUEST_VIRT:
+				*hwirq = ic->nr_hw + AIC_TMR_HV_VIRT;
+				break;
+			case AIC_TMR_HV_PHYS:
+			case AIC_TMR_HV_VIRT:
+				return -ENOENT;
+			default:
+				break;
+			}
+		}
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	*type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
+
+	return 0;
+}
+
+static int aic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+				unsigned int nr_irqs, void *arg)
+{
+	unsigned int type = IRQ_TYPE_NONE;
+	struct irq_fwspec *fwspec = arg;
+	irq_hw_number_t hwirq;
+	int i, ret;
+
+	ret = aic_irq_domain_translate(domain, fwspec, &hwirq, &type);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < nr_irqs; i++) {
+		ret = aic_irq_domain_map(domain, virq + i, hwirq + i);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static void aic_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+				unsigned int nr_irqs)
+{
+	int i;
+
+	for (i = 0; i < nr_irqs; i++) {
+		struct irq_data *d = irq_domain_get_irq_data(domain, virq + i);
+
+		irq_set_handler(virq + i, NULL);
+		irq_domain_reset_irq_data(d);
+	}
+}
+
+static const struct irq_domain_ops aic_irq_domain_ops = {
+	.translate	= aic_irq_domain_translate,
+	.alloc		= aic_irq_domain_alloc,
+	.free		= aic_irq_domain_free,
+};
+
+/*
+ * IPI irqchip
+ */
+
+static void aic_ipi_mask(struct irq_data *d)
+{
+	u32 irq_bit = BIT(irqd_to_hwirq(d));
+
+	/* No specific ordering requirements needed here. */
+	atomic_andnot(irq_bit, this_cpu_ptr(&aic_vipi_enable));
+}
+
+static void aic_ipi_unmask(struct irq_data *d)
+{
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+	u32 irq_bit = BIT(irqd_to_hwirq(d));
+
+	atomic_or(irq_bit, this_cpu_ptr(&aic_vipi_enable));
+
+	/*
+	 * The atomic_or() above must complete before the atomic_read_acquire() below to avoid
+	 * racing aic_ipi_send_mask().
+	 */
+	smp_mb__after_atomic();
+
+	/*
+	 * If a pending vIPI was unmasked, raise a HW IPI to ourselves.
+	 * No barriers needed here since this is a self-IPI.
+	 */
+	if (atomic_read(this_cpu_ptr(&aic_vipi_flag)) & irq_bit)
+		aic_ic_write(ic, AIC_IPI_SEND, AIC_IPI_SEND_CPU(smp_processor_id()));
+}
+
+static void aic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
+{
+	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
+	u32 irq_bit = BIT(irqd_to_hwirq(d));
+	u32 send = 0;
+	int cpu;
+	unsigned long pending;
+
+	for_each_cpu(cpu, mask) {
+		/*
+		 * This sequence is the mirror of the one in aic_ipi_unmask();
+		 * see the comment there. Additionally, release semantics
+		 * ensure that the vIPI flag set is ordered after any shared
+		 * memory accesses that precede it. This therefore also pairs
+		 * with the atomic_fetch_andnot in aic_handle_ipi().
+		 */
+		pending = atomic_fetch_or_release(irq_bit, per_cpu_ptr(&aic_vipi_flag, cpu));
+
+		/*
+		 * The atomic_fetch_or_release() above must complete before the
+		 * atomic_read_acquire() below to avoid racing aic_ipi_unmask().
+		 */
+		smp_mb__after_atomic();
+
+		if (!(pending & irq_bit) &&
+		    (atomic_read(per_cpu_ptr(&aic_vipi_enable, cpu)) & irq_bit))
+			send |= AIC_IPI_SEND_CPU(cpu);
+	}
+
+	/*
+	 * The flag writes must complete before the physical IPI is issued
+	 * to another CPU. This is implied by the control dependency on
+	 * the result of atomic_read_acquire() above, which is itself
+	 * already ordered after the vIPI flag write.
+	 */
+	if (send)
+		aic_ic_write(ic, AIC_IPI_SEND, send);
+}
+
+static struct irq_chip ipi_chip = {
+	.name = "AIC-IPI",
+	.irq_mask = aic_ipi_mask,
+	.irq_unmask = aic_ipi_unmask,
+	.ipi_send_mask = aic_ipi_send_mask,
+};
+
+/*
+ * IPI IRQ domain
+ */
+
+static void aic_handle_ipi(struct pt_regs *regs)
+{
+	int i;
+	unsigned long enabled, firing;
+
+	/*
+	 * Ack the IPI. We need to order this after the AIC event read, but
+	 * that is enforced by normal MMIO ordering guarantees.
+	 */
+	aic_ic_write(aic_irqc, AIC_IPI_ACK, AIC_IPI_OTHER);
+
+	/*
+	 * The mask read does not need to be ordered. Only we can change
+	 * our own mask anyway, so no races are possible here, as long as
+	 * we are properly in the interrupt handler (which is covered by
+	 * the barrier that is part of the top-level AIC handler's readl()).
+	 */
+	enabled = atomic_read(this_cpu_ptr(&aic_vipi_enable));
+
+	/*
+	 * Clear the IPIs we are about to handle. This pairs with the
+	 * atomic_fetch_or_release() in aic_ipi_send_mask(), and needs to be
+	 * ordered after the aic_ic_write() above (to avoid dropping vIPIs) and
+	 * before IPI handling code (to avoid races handling vIPIs before they
+	 * are signaled). The former is taken care of by the release semantics
+	 * of the write portion, while the latter is taken care of by the
+	 * acquire semantics of the read portion.
+	 */
+	firing = atomic_fetch_andnot(enabled, this_cpu_ptr(&aic_vipi_flag)) & enabled;
+
+	for_each_set_bit(i, &firing, AIC_NR_SWIPI)
+		handle_domain_irq(aic_irqc->ipi_domain, i, regs);
+
+	/*
+	 * No ordering needed here; at worst this just changes the timing of
+	 * when the next IPI will be delivered.
+	 */
+	aic_ic_write(aic_irqc, AIC_IPI_MASK_CLR, AIC_IPI_OTHER);
+}
+
+static int aic_ipi_alloc(struct irq_domain *d, unsigned int virq,
+			 unsigned int nr_irqs, void *args)
+{
+	int i;
+
+	for (i = 0; i < nr_irqs; i++) {
+		irq_set_percpu_devid(virq + i);
+		irq_domain_set_info(d, virq + i, i, &ipi_chip, d->host_data,
+				    handle_percpu_devid_irq, NULL, NULL);
+	}
+
+	return 0;
+}
+
+static void aic_ipi_free(struct irq_domain *d, unsigned int virq, unsigned int nr_irqs)
+{
+	/* Not freeing IPIs */
+}
+
+static const struct irq_domain_ops aic_ipi_domain_ops = {
+	.alloc = aic_ipi_alloc,
+	.free = aic_ipi_free,
+};
+
+static int aic_init_smp(struct aic_irq_chip *irqc, struct device_node *node)
+{
+	struct irq_domain *ipi_domain;
+	int base_ipi;
+
+	ipi_domain = irq_domain_create_linear(irqc->hw_domain->fwnode, AIC_NR_SWIPI,
+					      &aic_ipi_domain_ops, irqc);
+	if (WARN_ON(!ipi_domain))
+		return -ENODEV;
+
+	ipi_domain->flags |= IRQ_DOMAIN_FLAG_IPI_SINGLE;
+	irq_domain_update_bus_token(ipi_domain, DOMAIN_BUS_IPI);
+
+	base_ipi = __irq_domain_alloc_irqs(ipi_domain, -1, AIC_NR_SWIPI,
+					   NUMA_NO_NODE, NULL, false, NULL);
+
+	if (WARN_ON(!base_ipi)) {
+		irq_domain_remove(ipi_domain);
+		return -ENODEV;
+	}
+
+	set_smp_ipi_range(base_ipi, AIC_NR_SWIPI);
+
+	irqc->ipi_domain = ipi_domain;
+
+	return 0;
+}
+
+static int aic_init_cpu(unsigned int cpu)
+{
+	/* Mask all hard-wired per-CPU IRQ/FIQ sources */
+
+	/* Pending Fast IPI FIQs */
+	write_sysreg_s(IPI_SR_PENDING, SYS_IMP_APL_IPI_SR_EL1);
+
+	/* Timer FIQs */
+	sysreg_clear_set(cntp_ctl_el0, 0, ARCH_TIMER_CTRL_IT_MASK);
+	sysreg_clear_set(cntv_ctl_el0, 0, ARCH_TIMER_CTRL_IT_MASK);
+
+	/* EL2-only (VHE mode) IRQ sources */
+	if (is_kernel_in_hyp_mode()) {
+		/* Guest timers */
+		sysreg_clear_set_s(SYS_IMP_APL_VM_TMR_FIQ_ENA_EL2,
+				   VM_TMR_FIQ_ENABLE_V | VM_TMR_FIQ_ENABLE_P, 0);
+
+		/* vGIC maintenance IRQ */
+		sysreg_clear_set_s(SYS_ICH_HCR_EL2, ICH_HCR_EN, 0);
+	}
+
+	/* PMC FIQ */
+	sysreg_clear_set_s(SYS_IMP_APL_PMCR0_EL1, PMCR0_IMODE | PMCR0_IACT,
+			   FIELD_PREP(PMCR0_IMODE, PMCR0_IMODE_OFF));
+
+	/* Uncore PMC FIQ */
+	sysreg_clear_set_s(SYS_IMP_APL_UPMCR0_EL1, UPMCR0_IMODE,
+			   FIELD_PREP(UPMCR0_IMODE, UPMCR0_IMODE_OFF));
+
+	/* Commit all of the above */
+	isb();
+
+	/*
+	 * Make sure the kernel's idea of logical CPU order is the same as AIC's
+	 * If we ever end up with a mismatch here, we will have to introduce
+	 * a mapping table similar to what other irqchip drivers do.
+	 */
+	WARN_ON(aic_ic_read(aic_irqc, AIC_WHOAMI) != smp_processor_id());
+
+	/*
+	 * Always keep IPIs unmasked at the hardware level (except auto-masking
+	 * by AIC during processing). We manage masks at the vIPI level.
+	 */
+	aic_ic_write(aic_irqc, AIC_IPI_ACK, AIC_IPI_SELF | AIC_IPI_OTHER);
+	aic_ic_write(aic_irqc, AIC_IPI_MASK_SET, AIC_IPI_SELF);
+	aic_ic_write(aic_irqc, AIC_IPI_MASK_CLR, AIC_IPI_OTHER);
+
+	/* Initialize the local mask state */
+	__this_cpu_write(aic_fiq_unmasked, 0);
+
+	return 0;
+}
+
+static int __init aic_of_ic_init(struct device_node *node, struct device_node *parent)
+{
+	int i;
+	void __iomem *regs;
+	u32 info;
+	struct aic_irq_chip *irqc;
+
+	regs = of_iomap(node, 0);
+	if (WARN_ON(!regs))
+		return -EIO;
+
+	irqc = kzalloc(sizeof(*irqc), GFP_KERNEL);
+	if (!irqc)
+		return -ENOMEM;
+
+	aic_irqc = irqc;
+	irqc->base = regs;
+
+	info = aic_ic_read(irqc, AIC_INFO);
+	irqc->nr_hw = FIELD_GET(AIC_INFO_NR_HW, info);
+
+	irqc->hw_domain = irq_domain_create_linear(of_node_to_fwnode(node),
+						   irqc->nr_hw + AIC_NR_FIQ,
+						   &aic_irq_domain_ops, irqc);
+	if (WARN_ON(!irqc->hw_domain)) {
+		iounmap(irqc->base);
+		kfree(irqc);
+		return -ENODEV;
+	}
+
+	irq_domain_update_bus_token(irqc->hw_domain, DOMAIN_BUS_WIRED);
+
+	if (aic_init_smp(irqc, node)) {
+		irq_domain_remove(irqc->hw_domain);
+		iounmap(irqc->base);
+		kfree(irqc);
+		return -ENODEV;
+	}
+
+	set_handle_irq(aic_handle_irq);
+	set_handle_fiq(aic_handle_fiq);
+
+	for (i = 0; i < BITS_TO_U32(irqc->nr_hw); i++)
+		aic_ic_write(irqc, AIC_MASK_SET + i * 4, U32_MAX);
+	for (i = 0; i < BITS_TO_U32(irqc->nr_hw); i++)
+		aic_ic_write(irqc, AIC_SW_CLR + i * 4, U32_MAX);
+	for (i = 0; i < irqc->nr_hw; i++)
+		aic_ic_write(irqc, AIC_TARGET_CPU + i * 4, 1);
+
+	if (!is_kernel_in_hyp_mode())
+		pr_info("Kernel running in EL1, mapping interrupts");
+
+	cpuhp_setup_state(CPUHP_AP_IRQ_APPLE_AIC_STARTING,
+			  "irqchip/apple-aic/ipi:starting",
+			  aic_init_cpu, NULL);
+
+	pr_info("Initialized with %d IRQs, %d FIQs, %d vIPIs\n",
+		irqc->nr_hw, AIC_NR_FIQ, AIC_NR_SWIPI);
+
+	return 0;
+}
+
+IRQCHIP_DECLARE(apple_m1_aic, "apple,aic", aic_of_ic_init);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index f14adb882338..f56eee992c75 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -100,6 +100,7 @@ enum cpuhp_state {
 	CPUHP_AP_CPU_PM_STARTING,
 	CPUHP_AP_IRQ_GIC_STARTING,
 	CPUHP_AP_IRQ_HIP04_STARTING,
+	CPUHP_AP_IRQ_APPLE_AIC_STARTING,
 	CPUHP_AP_IRQ_ARMADA_XP_STARTING,
 	CPUHP_AP_IRQ_BCM2836_STARTING,
 	CPUHP_AP_IRQ_MIPS_GIC_STARTING,
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:40 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:40 +0900
Subject: [PATCH v4 16/18] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-17-marcan@marcan.st>

This adds a Kconfig option to toggle support for Apple ARM SoCs.
At this time this targets the M1 and later "Apple Silicon" Mac SoCs.

Signed-off-by: Hector Martin <marcan at marcan.st>
---
 arch/arm64/Kconfig.platforms | 7 +++++++
 arch/arm64/configs/defconfig | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index cdfd5fed457f..df320a13915a 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -36,6 +36,13 @@ config ARCH_ALPINE
 	  This enables support for the Annapurna Labs Alpine
 	  Soc family.
 
+config ARCH_APPLE
+	bool "Apple Silicon SoC family"
+	select APPLE_AIC
+	help
+	  This enables support for Apple's in-house ARM SoC family, starting
+	  with the Apple M1.
+
 config ARCH_BCM2835
 	bool "Broadcom BCM2835 family"
 	select TIMER_OF
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d612f633b771..54fb257e55f7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_ARCH_ACTIONS=y
 CONFIG_ARCH_AGILEX=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_APPLE=y
 CONFIG_ARCH_BCM2835=y
 CONFIG_ARCH_BCM4908=y
 CONFIG_ARCH_BCM_IPROC=y
-- 
2.30.0



From marcan at marcan.st  Fri Apr  2 10:05:41 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:41 +0900
Subject: [PATCH v4 17/18] dt-bindings: display: Add apple,simple-framebuffer
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-18-marcan@marcan.st>

Apple SoCs run firmware that sets up a simplefb-compatible framebuffer
for us. Add a compatible for it, and two missing supported formats.

Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Hector Martin <marcan at marcan.st>
---
 .../devicetree/bindings/display/simple-framebuffer.yaml      | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
index eaf8c54fcf50..c2499a7906f5 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
@@ -54,6 +54,7 @@ properties:
   compatible:
     items:
       - enum:
+          - apple,simple-framebuffer
           - allwinner,simple-framebuffer
           - amlogic,simple-framebuffer
       - const: simple-framebuffer
@@ -84,9 +85,13 @@ properties:
       Format of the framebuffer:
         * `a8b8g8r8` - 32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r
         * `r5g6b5` - 16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b
+        * `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
+        * `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
     enum:
       - a8b8g8r8
       - r5g6b5
+      - x2r10g10b10
+      - x8r8g8b8
 
   display:
     $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.0



From quan at os.amperecomputing.com  Fri Apr  2 10:07:34 2021
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Fri, 2 Apr 2021 16:07:34 +0700
Subject: [PATCH v1 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver
In-Reply-To: <CACPK8Xf5d67-KR9AQ9QMcyT2Or9ieF_Q+_RbMMTHt4ckiKi6_A@mail.gmail.com>
References: <20210329121759.5644-1-quan@os.amperecomputing.com>
 <20210329121759.5644-3-quan@os.amperecomputing.com>
 <CACPK8Xf5d67-KR9AQ9QMcyT2Or9ieF_Q+_RbMMTHt4ckiKi6_A@mail.gmail.com>
Message-ID: <e0016596-9ac8-8a54-68bf-42a6959e78be@os.amperecomputing.com>

On 31/03/2021 14:21, Joel Stanley wrote:
> On Mon, 29 Mar 2021 at 12:18, Quan Nguyen <quan at os.amperecomputing.com> wrote:
>>
>> The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
>> in-band IPMI communication with their host in management (BMC) side.
>>
>> This commits adds support specifically for Aspeed AST2500 which commonly
>> used as Board Management Controllers.
>>
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> 
> I don't have any SSIF or IPMI related feedback on your patch, but some
> general things I noticed when reading it.
> 

Thank you, Joel,
I'm really appreciate your comments for this patch series.

And, as there is a compilation error detected by kernel robot test, I 
was hurry to send out v2 just to fix that just before your email 
arrived. So I'd like to address all comments in my upcoming v3.


>> ---
>>   drivers/char/ipmi/Kconfig           |  22 +
>>   drivers/char/ipmi/Makefile          |   2 +
>>   drivers/char/ipmi/ssif_bmc.c        | 645 ++++++++++++++++++++++++++++
>>   drivers/char/ipmi/ssif_bmc.h        |  92 ++++
>>   drivers/char/ipmi/ssif_bmc_aspeed.c | 132 ++++++
>>   5 files changed, 893 insertions(+)
>>   create mode 100644 drivers/char/ipmi/ssif_bmc.c
>>   create mode 100644 drivers/char/ipmi/ssif_bmc.h
>>   create mode 100644 drivers/char/ipmi/ssif_bmc_aspeed.c
> 
> It would make sense to split the aspeed implementation into a separate
> patch form the ssif framework.
> 
Yes, will do in next version

>> +++ b/drivers/char/ipmi/ssif_bmc.c
>> @@ -0,0 +1,645 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * The driver for BMC side of SSIF interface
>> + *
>> + * Copyright (c) 2021, Ampere Computing LLC
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> 
> You should omit the licence text; it is replaced by the SPDX tags.
> 
My bad, will remove in next version

>> +static int send_ssif_bmc_response(struct ssif_bmc_ctx *ssif_bmc, bool non_blocking)
>> +{
>> +       unsigned long flags;
>> +       int ret;
>> +
>> +       if (!non_blocking) {
>> +retry:
>> +               ret = wait_event_interruptible(ssif_bmc->wait_queue,
>> +                                              !ssif_bmc->response_in_progress);
>> +               if (ret)
>> +                       return ret;
>> +       }
>> +
>> +       spin_lock_irqsave(&ssif_bmc->lock, flags);
> 
> What's the lock doing here? We've just waited for response_in_progress
> to be false, so we then take the lock to check what value it is?
> Should it also be sending some data in this function?
> 
The lock is to make sure ssif_bmc->response_in_progress are completely 
processed, ie: when the lock already released.
My concern is that reference to that value without acquiring lock may 
not be true as it is under other possess.

In fact, the lock here is for the whole data pointed by ssif_bmc 
pointer. Hence, every reference/modify to this data must be done with 
the lock acquired.

>> +       if (ssif_bmc->response_in_progress) {
>> +               spin_unlock_irqrestore(&ssif_bmc->lock, flags);
>> +               if (non_blocking)
>> +                       return -EAGAIN;
>> +
>> +               goto retry;
> 
> The goto threw me, so I tried re-writing it without. Again, I don't
> quite follow what the spinlock is doing.
> 
> while (1) {
>      if (blocking) {
>          ret = wait_event_interruptible();
>          if (ret)
>               return ret;
>      }
> 
>       spin_lock_irqsave()
>       if (ssif_bmc->response_in_progress) {
>           spin_lock_irqrestore()
>           if (!blocking)
>               return -EAGAIN;
>       } else {
>          spin_lock_irqrestore()
>          break;
>       }
> }
> 
> 
I'm afraid we would need to re-acquire the lock before modifying 
ssif_bmc->is_singlepart_read and ssif_bmc->response_in_progress below.

>> +       }
>> +
>> +       /*
>> +        * Check the response data length from userspace to determine the type
>> +        * of the response message whether it is single-part or multi-part.
>> +        */
>> +       ssif_bmc->is_singlepart_read =
>> +               (ssif_msg_len(&ssif_bmc->response) <= (MAX_PAYLOAD_PER_TRANSACTION + 1)) ?
>> +               true : false; /* 1: byte of length */
> 
> I don't follow the 1: byte of length comment, what is it telling me?
> 
> The ternary operator is a bit messy here, I'd go for a good old if statement.
> 
The comment indeed does not provide any info here. Will change back to 
if else statement and add more meaningful comment if necessary in next 
version.

>> +
>> +       ssif_bmc->response_in_progress = true;
>> +       spin_unlock_irqrestore(&ssif_bmc->lock, flags);
>> +
>> +       return 0;
>> +}
> 
>> +/* Handle SSIF message that will be sent to user */
>> +static ssize_t ssif_bmc_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
>> +{
>> +       struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
>> +       struct ssif_msg msg;
>> +       unsigned long flags;
>> +       ssize_t ret;
>> +
>> +       mutex_lock(&ssif_bmc->file_mutex);
> 
> ->file_mutex is protecting the device against more than one user of
> the character device? Can you enforce that in open() instead?
> 

The current use is to serialize access among read()/write()/poll().

About enforcing open() to return -EBUSY to protect the device against 
more than one user, we can either implement follow example of 
drivers/char/ipmi/kcs_bmc.c OR drivers/char/ipmi/bt-bmc.c

But I'm still wonder what should be better between atomic_t open_count 
(bt_bmc.c) or simply reuse the file_mutex similar with kcs_bmc.c.

>> +
>> +       ret = receive_ssif_bmc_request(ssif_bmc, file->f_flags & O_NONBLOCK);
>> +       if (ret < 0)
>> +               goto out;
>> +
>> +       spin_lock_irqsave(&ssif_bmc->lock, flags);
>> +       count = min_t(ssize_t, count, ssif_msg_len(&ssif_bmc->request));
> 
> count is user controlled, so I assume ssif_msg_len will always be less
> than or equal to struct ssif_msg?
> 

The size of struct ssif_msg is 255 bytes, and the ssif_msg_len() should 
always return less than this number unless the ssif_msg->len is wrong 
and exceeded the size of struct ssif_msg.

For safe I think it should be changed to the min among count, 
sizeof(struct ssif_msg), and return value of 
ssif_msg_len(&ssif_bmc->request).
ie:
count = min_t(ssize_t, count, min_t(ssize_t, sizeof(struct ssif_msg), 
ssif_msg_len(&ssif_bmc->request));

>> +       memcpy(&msg, &ssif_bmc->request, count);
>> +       ssif_bmc->request_available = false;
>> +       spin_unlock_irqrestore(&ssif_bmc->lock, flags);
>> +
>> +       ret = copy_to_user(buf, &msg, count);
>> +out:
>> +       mutex_unlock(&ssif_bmc->file_mutex);
>> +
>> +       return (ret < 0) ? ret : count;
>> +}
>> +
>> +/* Handle SSIF message that is written by user */
>> +static ssize_t ssif_bmc_write(struct file *file, const char __user *buf, size_t count,
>> +                             loff_t *ppos)
>> +{
>> +       struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
>> +       struct ssif_msg msg;
>> +       unsigned long flags;
>> +       ssize_t ret;
>> +
>> +       if (count > sizeof(struct ssif_msg))
>> +               return -EINVAL;
>> +
>> +       mutex_lock(&ssif_bmc->file_mutex);
>> +
>> +       ret = copy_from_user(&msg, buf, count);
>> +       if (ret)
>> +               goto out;
>> +
>> +       spin_lock_irqsave(&ssif_bmc->lock, flags);
>> +       if (count >= ssif_msg_len(&ssif_bmc->response))
> 
> Is that test correct?
> 
As the "if (count > sizeof(struct ssif_msg))" above ensure the data will 
not exceeded the size of buffer, ie: sizeof ssif_msg, we can now to make 
sure the actually data size to agree with ssif_msg->len, ie: the return 
of ssif_msg_len().

But as this test looked "not easy to read" so I think I will fix this to:

    if (count < ssif_msg_len(&ssif_bmc->response))
         ret = -EINVAL;
    else
         memcpy(...);

Hope this way made it easier to read.

>> +               memcpy(&ssif_bmc->response, &msg, count);
>> +       else
>> +               ret = -EINVAL;
>> +       spin_unlock_irqrestore(&ssif_bmc->lock, flags);
>> +
>> +       if (ret)
>> +               goto out;
>> +
>> +       ret = send_ssif_bmc_response(ssif_bmc, file->f_flags & O_NONBLOCK);
>> +       if (!ret && ssif_bmc->set_ssif_bmc_status)
>> +               ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_READY);
>> +out:
>> +       mutex_unlock(&ssif_bmc->file_mutex);
>> +
>> +       return (ret < 0) ? ret : count;
>> +}
>> +
>> +static long ssif_bmc_ioctl(struct file *file, unsigned int cmd, unsigned long param)
>> +{
> 
> If you're not using this I suspect you should omit the callback.
> 
Will remove this in next version

>> +       return 0;
>> +}
>> +
>> +static unsigned int ssif_bmc_poll(struct file *file, poll_table *wait)
>> +{
>> +       struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
>> +       unsigned int mask = 0;
>> +
>> +       mutex_lock(&ssif_bmc->file_mutex);
>> +       poll_wait(file, &ssif_bmc->wait_queue, wait);
>> +
>> +       /*
>> +        * The request message is now available so userspace application can
>> +        * get the request
>> +        */
>> +       if (ssif_bmc->request_available)
>> +               mask |= POLLIN;
>> +
>> +       mutex_unlock(&ssif_bmc->file_mutex);
>> +       return mask;
>> +}
>> +
>> +/*
>> + * System calls to device interface for user apps
>> + */
>> +static const struct file_operations ssif_bmc_fops = {
>> +       .owner          = THIS_MODULE,
>> +       .read           = ssif_bmc_read,
>> +       .write          = ssif_bmc_write,
>> +       .poll           = ssif_bmc_poll,
>> +       .unlocked_ioctl = ssif_bmc_ioctl,
>> +};
>> +
>> +/* Called with ssif_bmc->lock held. */
>> +static int handle_request(struct ssif_bmc_ctx *ssif_bmc)
> 
> Could return void.
> 
Will do in next version

>> +{
>> +       if (ssif_bmc->set_ssif_bmc_status)
>> +               ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_BUSY);
>> +
>> +       /* Request message is available to process */
>> +       ssif_bmc->request_available = true;
>> +       /*
>> +        * This is the new READ request.
>> +        * Clear the response buffer of the previous transaction
>> +        */
>> +       memset(&ssif_bmc->response, 0, sizeof(struct ssif_msg));
>> +       wake_up_all(&ssif_bmc->wait_queue);
>> +       return 0;
>> +}
>> +
>> +/* Called with ssif_bmc->lock held. */
>> +static int complete_response(struct ssif_bmc_ctx *ssif_bmc)
> 
> Could return void.
>
Will do in next version

>> +{
>> +       /* Invalidate response in buffer to denote it having been sent. */
>> +       ssif_bmc->response.len = 0;
>> +       ssif_bmc->response_in_progress = false;
>> +       ssif_bmc->nbytes_processed = 0;
>> +       ssif_bmc->remain_len = 0;
>> +       memset(&ssif_bmc->response_buf, 0, MAX_PAYLOAD_PER_TRANSACTION);
>> +       wake_up_all(&ssif_bmc->wait_queue);
>> +       return 0;
>> +}
>> +
>> +static void set_multipart_response_buffer(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
>> +{
> 
>> +       default:
>> +               /* Do not expect to go to this case */
>> +               pr_err("Error: Unexpected SMBus command received 0x%x\n", ssif_bmc->smbus_cmd);
> 
> Use dev_err if you can, so the message is associated with the device.
> 

Will try to use dev_err() in next version

>> +               break;
>> +       }
>> +
>> +       ssif_bmc->nbytes_processed += response_len;
>> +}
>> +



From marcan at marcan.st  Fri Apr  2 10:05:42 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri,  2 Apr 2021 18:05:42 +0900
Subject: [PATCH v4 18/18] arm64: apple: Add initial Apple Mac mini (M1,
 2020) devicetree
In-Reply-To: <20210402090542.131194-1-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
Message-ID: <20210402090542.131194-19-marcan@marcan.st>

This currently supports:

* SMP (via spin-tables)
* AIC IRQs
* Serial (with earlycon)
* Framebuffer

A number of properties are dynamic, and based on system firmware
decisions that vary from version to version. These are expected
to be filled in by the loader.

Signed-off-by: Hector Martin <marcan at marcan.st>
---
 MAINTAINERS                              |   1 +
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/apple/Makefile       |   2 +
 arch/arm64/boot/dts/apple/t8103-j274.dts |  45 ++++++++
 arch/arm64/boot/dts/apple/t8103.dtsi     | 135 +++++++++++++++++++++++
 5 files changed, 184 insertions(+)
 create mode 100644 arch/arm64/boot/dts/apple/Makefile
 create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
 create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index e27332ec1f12..9ac46317840b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1647,6 +1647,7 @@ C:	irc://chat.freenode.net/asahi-dev
 T:	git https://github.com/AsahiLinux/linux.git
 F:	Documentation/devicetree/bindings/arm/apple.yaml
 F:	Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
+F:	arch/arm64/boot/dts/apple/
 F:	drivers/irqchip/irq-apple-aic.c
 F:	include/dt-bindings/interrupt-controller/apple-aic.h
 
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f1173cd93594..639e01a4d855 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -6,6 +6,7 @@ subdir-y += amazon
 subdir-y += amd
 subdir-y += amlogic
 subdir-y += apm
+subdir-y += apple
 subdir-y += arm
 subdir-y += bitmain
 subdir-y += broadcom
diff --git a/arch/arm64/boot/dts/apple/Makefile b/arch/arm64/boot/dts/apple/Makefile
new file mode 100644
index 000000000000..cbbd701ebf05
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_APPLE) += t8103-j274.dtb
diff --git a/arch/arm64/boot/dts/apple/t8103-j274.dts b/arch/arm64/boot/dts/apple/t8103-j274.dts
new file mode 100644
index 000000000000..e0f6775b9878
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/t8103-j274.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple Mac mini (M1, 2020)
+ *
+ * target-type: J274
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+/dts-v1/;
+
+#include "t8103.dtsi"
+
+/ {
+	compatible = "apple,j274", "apple,t8103", "apple,arm-platform";
+	model = "Apple Mac mini (M1, 2020)";
+
+	aliases {
+		serial0 = &serial0;
+	};
+
+	chosen {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		stdout-path = "serial0";
+
+		framebuffer0: framebuffer at 0 {
+			compatible = "apple,simple-framebuffer", "simple-framebuffer";
+			reg = <0 0 0 0>; /* To be filled by loader */
+			/* Format properties will be added by loader */
+			status = "disabled";
+		};
+	};
+
+	memory at 800000000 {
+		device_type = "memory";
+		reg = <0x8 0 0x2 0>; /* To be filled by loader */
+	};
+};
+
+&serial0 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi
new file mode 100644
index 000000000000..ff2bcb64bb13
--- /dev/null
+++ b/arch/arm64/boot/dts/apple/t8103.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple T8103 "M1" SoC
+ *
+ * Other names: H13G, "Tonga"
+ *
+ * Copyright The Asahi Linux Contributors
+ */
+
+#include <dt-bindings/interrupt-controller/apple-aic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	compatible = "apple,t8103", "apple,arm-platform";
+
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			compatible = "apple,icestorm";
+			device_type = "cpu";
+			reg = <0x0 0x0>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu1: cpu at 1 {
+			compatible = "apple,icestorm";
+			device_type = "cpu";
+			reg = <0x0 0x1>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu2: cpu at 2 {
+			compatible = "apple,icestorm";
+			device_type = "cpu";
+			reg = <0x0 0x2>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu3: cpu at 3 {
+			compatible = "apple,icestorm";
+			device_type = "cpu";
+			reg = <0x0 0x3>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu4: cpu at 10100 {
+			compatible = "apple,firestorm";
+			device_type = "cpu";
+			reg = <0x0 0x10100>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu5: cpu at 10101 {
+			compatible = "apple,firestorm";
+			device_type = "cpu";
+			reg = <0x0 0x10101>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu6: cpu at 10102 {
+			compatible = "apple,firestorm";
+			device_type = "cpu";
+			reg = <0x0 0x10102>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+
+		cpu7: cpu at 10103 {
+			compatible = "apple,firestorm";
+			device_type = "cpu";
+			reg = <0x0 0x10103>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0 0>; /* To be filled by loader */
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupt-parent = <&aic>;
+		interrupt-names = "phys", "virt", "hyp-phys", "hyp-virt";
+		interrupts = <AIC_FIQ AIC_TMR_GUEST_PHYS IRQ_TYPE_LEVEL_HIGH>,
+			     <AIC_FIQ AIC_TMR_GUEST_VIRT IRQ_TYPE_LEVEL_HIGH>,
+			     <AIC_FIQ AIC_TMR_HV_PHYS IRQ_TYPE_LEVEL_HIGH>,
+			     <AIC_FIQ AIC_TMR_HV_VIRT IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	clk24: clock-24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "clk24";
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		ranges;
+		nonposted-mmio;
+
+		aic: interrupt-controller at 23b100000 {
+			compatible = "apple,t8103-aic", "apple,aic";
+			#interrupt-cells = <3>;
+			interrupt-controller;
+			reg = <0x2 0x3b100000 0x0 0x8000>;
+		};
+
+		serial0: serial at 235200000 {
+			compatible = "apple,s5l-uart";
+			reg = <0x2 0x35200000 0x0 0x1000>;
+			reg-io-width = <4>;
+			interrupt-parent = <&aic>;
+			interrupts = <AIC_IRQ 605 IRQ_TYPE_LEVEL_HIGH>;
+			/*
+			 * TODO: figure out the clocking properly, there may
+			 * be a third selectable clock.
+			 */
+			clocks = <&clk24>, <&clk24>;
+			clock-names = "uart", "clk_uart_baud0";
+			status = "disabled";
+		};
+	};
+};
-- 
2.30.0



From nava.manne at xilinx.com  Fri Apr  2 10:09:30 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:39:30 +0530
Subject: [PATCH RFC 0/3] Adds support to allow the bitstream configuration
 from pre-allocated dma-buffer 
Message-ID: <20210402090933.32276-1-nava.manne@xilinx.com>

Nava kishore Manne (3):
  fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'
  fpga: support loading from a pre-allocated buffer
  fpga: zynqmp: Use the scatterlist interface

 .../devicetree/bindings/fpga/fpga-region.txt  |   2 +
 drivers/fpga/fpga-mgr.c                       | 126 +++++++++++++++++-
 drivers/fpga/of-fpga-region.c                 |   3 +
 drivers/fpga/zynqmp-fpga.c                    |  35 +++++
 include/linux/fpga/fpga-mgr.h                 |   6 +-
 5 files changed, 169 insertions(+), 3 deletions(-)

-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:09:32 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:39:32 +0530
Subject: [PATCH RFC 2/3] fpga: support loading from a pre-allocated buffer
In-Reply-To: <20210402090933.32276-1-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
Message-ID: <20210402090933.32276-3-nava.manne@xilinx.com>

Some systems are memory constrained but they need to load very
large Configuration files. The FPGA subsystem allows drivers to
request this Configuration image be loaded from the filesystem,
but this requires that the entire configuration data be loaded
into kernel memory first before it's provided to the driver.
This can lead to a situation where we map the configuration
data twice, once to load the configuration data into kernel
memory and once to copy the configuration data into the final
resting place which is nothing but a dma-able continuous buffer.

This creates needless memory pressure and delays due to multiple
copies. Let's add a dmabuf handling support to the fpga manager
framework that allows drivers to load the Configuration data
directly from a pre-allocated buffer. This skips the intermediate
step of allocating a buffer in kernel memory to hold the
Configuration data.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/fpga/fpga-mgr.c       | 126 +++++++++++++++++++++++++++++++++-
 drivers/fpga/of-fpga-region.c |   3 +
 include/linux/fpga/fpga-mgr.h |   6 +-
 3 files changed, 132 insertions(+), 3 deletions(-)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index b85bc47c91a9..13faed61af62 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -8,6 +8,8 @@
  * With code from the mailing list:
  * Copyright (C) 2013 Xilinx, Inc.
  */
+#include <linux/dma-buf.h>
+#include <linux/dma-map-ops.h>
 #include <linux/firmware.h>
 #include <linux/fpga/fpga-mgr.h>
 #include <linux/idr.h>
@@ -306,6 +308,51 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
 	return rc;
 }
 
+/**
+ * fpga_mgr_buf_load - load fpga from image in dma buffer
+ * @mgr:        fpga manager
+ * @info:       fpga image info
+ *
+ * Step the low level fpga manager through the device-specific steps of getting
+ * an FPGA ready to be configured, writing the image to it, then doing whatever
+ * post-configuration steps necessary.  This code assumes the caller got the
+ * mgr pointer from of_fpga_mgr_get() and checked that it is not an error code.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int fpga_dmabuf_load(struct fpga_manager *mgr,
+			    struct fpga_image_info *info)
+{
+	struct dma_buf_attachment *attach;
+	struct sg_table *sgt;
+	int ret;
+
+	/* create attachment for dmabuf with the user device */
+	attach = dma_buf_attach(mgr->dmabuf, &mgr->dev);
+	if (IS_ERR(attach)) {
+		pr_err("failed to attach dmabuf\n");
+		ret = PTR_ERR(attach);
+		goto fail_put;
+	}
+
+	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+	if (IS_ERR(sgt)) {
+		ret = PTR_ERR(sgt);
+		goto fail_detach;
+	}
+
+	info->sgt = sgt;
+	ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
+	dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+
+fail_detach:
+	dma_buf_detach(mgr->dmabuf, attach);
+fail_put:
+	dma_buf_put(mgr->dmabuf);
+
+	return ret;
+}
+
 /**
  * fpga_mgr_firmware_load - request firmware and load to fpga
  * @mgr:	fpga manager
@@ -358,6 +405,8 @@ static int fpga_mgr_firmware_load(struct fpga_manager *mgr,
  */
 int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info)
 {
+	if (info->flags & FPGA_MGR_CONFIG_DMA_BUF)
+		return fpga_dmabuf_load(mgr, info);
 	if (info->sgt)
 		return fpga_mgr_buf_load_sg(mgr, info, info->sgt);
 	if (info->buf && info->count)
@@ -549,6 +598,62 @@ void fpga_mgr_unlock(struct fpga_manager *mgr)
 }
 EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
 
+static int fpga_dmabuf_fd_get(struct file *file, char __user *argp)
+{
+	struct fpga_manager *mgr =  (struct fpga_manager *)(file->private_data);
+	int buffd;
+
+	if (copy_from_user(&buffd, argp, sizeof(buffd)))
+		return -EFAULT;
+
+	mgr->dmabuf = dma_buf_get(buffd);
+	if (IS_ERR_OR_NULL(mgr->dmabuf))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int fpga_device_open(struct inode *inode, struct file *file)
+{
+	struct miscdevice *miscdev = file->private_data;
+	struct fpga_manager *mgr = container_of(miscdev,
+						struct fpga_manager, miscdev);
+
+	file->private_data = mgr;
+
+	return 0;
+}
+
+static int fpga_device_release(struct inode *inode, struct file *file)
+{
+	return 0;
+}
+
+static long fpga_device_ioctl(struct file *file, unsigned int cmd,
+			      unsigned long arg)
+{
+	char __user *argp = (char __user *)arg;
+	int err;
+
+	switch (cmd) {
+	case FPGA_IOCTL_LOAD_DMA_BUFF:
+		err = fpga_dmabuf_fd_get(file, argp);
+		break;
+	default:
+		err = -ENOTTY;
+	}
+
+	return err;
+}
+
+static const struct file_operations fpga_fops = {
+	.owner		= THIS_MODULE,
+	.open		= fpga_device_open,
+	.release	= fpga_device_release,
+	.unlocked_ioctl	= fpga_device_ioctl,
+	.compat_ioctl	= fpga_device_ioctl,
+};
+
 /**
  * fpga_mgr_create - create and initialize a FPGA manager struct
  * @dev:	fpga manager device from pdev
@@ -569,8 +674,7 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
 	int id, ret;
 
 	if (!mops || !mops->write_complete || !mops->state ||
-	    !mops->write_init || (!mops->write && !mops->write_sg) ||
-	    (mops->write && mops->write_sg)) {
+	    !mops->write_init || (!mops->write && !mops->write_sg)) {
 		dev_err(dev, "Attempt to register without fpga_manager_ops\n");
 		return NULL;
 	}
@@ -601,10 +705,28 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
 	mgr->dev.of_node = dev->of_node;
 	mgr->dev.id = id;
 
+	/* Make device dma capable by inheriting from parent's */
+	set_dma_ops(&mgr->dev, get_dma_ops(dev));
+	ret = dma_coerce_mask_and_coherent(&mgr->dev, dma_get_mask(dev));
+	if (ret) {
+		dev_warn(dev,
+			 "Failed to set DMA mask %llx.Trying to continue.%x\n",
+			 dma_get_mask(dev), ret);
+	}
+
 	ret = dev_set_name(&mgr->dev, "fpga%d", id);
 	if (ret)
 		goto error_device;
 
+	mgr->miscdev.minor = MISC_DYNAMIC_MINOR;
+	mgr->miscdev.name = kobject_name(&mgr->dev.kobj);
+	mgr->miscdev.fops = &fpga_fops;
+	ret = misc_register(&mgr->miscdev);
+	if (ret) {
+		pr_err("fpga: failed to register misc device.\n");
+		goto error_device;
+	}
+
 	return mgr;
 
 error_device:
diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index 35fc2f3d4bd8..698e3e42ccba 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -229,6 +229,9 @@ static struct fpga_image_info *of_fpga_region_parse_ov(
 	if (of_property_read_bool(overlay, "encrypted-fpga-config"))
 		info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM;
 
+	if (of_property_read_bool(overlay, "fpga-config-from-dmabuf"))
+		info->flags |= FPGA_MGR_CONFIG_DMA_BUF;
+
 	if (!of_property_read_string(overlay, "firmware-name",
 				     &firmware_name)) {
 		info->firmware_name = devm_kstrdup(dev, firmware_name,
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 2bc3030a69e5..6208c22f7bed 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -9,6 +9,7 @@
 #define _LINUX_FPGA_MGR_H
 
 #include <linux/mutex.h>
+#include <linux/miscdevice.h>
 #include <linux/platform_device.h>
 
 struct fpga_manager;
@@ -73,7 +74,7 @@ enum fpga_mgr_states {
 #define FPGA_MGR_ENCRYPTED_BITSTREAM	BIT(2)
 #define FPGA_MGR_BITSTREAM_LSB_FIRST	BIT(3)
 #define FPGA_MGR_COMPRESSED_BITSTREAM	BIT(4)
-
+#define FPGA_MGR_CONFIG_DMA_BUF		BIT(5)
 /**
  * struct fpga_image_info - information specific to a FPGA image
  * @flags: boolean flags as defined above
@@ -167,6 +168,8 @@ struct fpga_compat_id {
 struct fpga_manager {
 	const char *name;
 	struct device dev;
+	struct miscdevice miscdev;
+	struct dma_buf *dmabuf;
 	struct mutex ref_mutex;
 	enum fpga_mgr_states state;
 	struct fpga_compat_id *compat_id;
@@ -204,4 +207,5 @@ struct fpga_manager *devm_fpga_mgr_create(struct device *dev, const char *name,
 					  const struct fpga_manager_ops *mops,
 					  void *priv);
 
+#define FPGA_IOCTL_LOAD_DMA_BUFF	_IOWR('R', 1, __u32)
 #endif /*_LINUX_FPGA_MGR_H */
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:09:31 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:39:31 +0530
Subject: [PATCH RFC 1/3] fpga: region: Add fpga-region property
 'fpga-config-from-dmabuf'
In-Reply-To: <20210402090933.32276-1-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
Message-ID: <20210402090933.32276-2-nava.manne@xilinx.com>

Add "fpga-config-from-dmabuf" property to allow the bitstream
configuration from pre-allocated dma-buffer.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 Documentation/devicetree/bindings/fpga/fpga-region.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index 969ca53bb65e..c573cf258d60 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -177,6 +177,8 @@ Optional properties:
 	it indicates that the FPGA has already been programmed with this image.
 	If this property is in an overlay targeting a FPGA region, it is a
 	request to program the FPGA with that image.
+- fpga-config-from-dmabuf : boolean, set if the FPGA configured done from the
+	pre-allocated dma-buffer.
 - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be
 	controlled during FPGA programming along with the parent FPGA bridge.
 	This property is optional if the FPGA Manager handles the bridges.
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:09:33 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:39:33 +0530
Subject: [PATCH RFC 3/3] fpga: zynqmp: Use the scatterlist interface
In-Reply-To: <20210402090933.32276-1-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
Message-ID: <20210402090933.32276-4-nava.manne@xilinx.com>

Allows drivers to request the Configuration image
be loaded from dma-able continuous buffer to avoid
needless memory pressure and delays due to multiple
copies.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/fpga/zynqmp-fpga.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
index 125743c9797f..3bb6bd520d71 100644
--- a/drivers/fpga/zynqmp-fpga.c
+++ b/drivers/fpga/zynqmp-fpga.c
@@ -66,6 +66,40 @@ static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
 	return ret;
 }
 
+static unsigned long zynqmp_fpga_get_contiguous_size(struct sg_table *sgt)
+{
+	dma_addr_t expected = sg_dma_address(sgt->sgl);
+	unsigned long size = 0;
+	struct scatterlist *s;
+	unsigned int i;
+
+	for_each_sg(sgt->sgl, s, sgt->nents, i) {
+		if (sg_dma_address(s) != expected)
+			break;
+		expected = sg_dma_address(s) + sg_dma_len(s);
+		size += sg_dma_len(s);
+	}
+
+	return size;
+}
+
+static int zynqmp_fpga_ops_write_sg(struct fpga_manager *mgr,
+				    struct sg_table *sgt)
+{
+	struct zynqmp_fpga_priv *priv;
+	unsigned long contig_size;
+	dma_addr_t dma_addr;
+	u32 eemi_flags = 0;
+
+	priv = mgr->priv;
+	dma_addr = sg_dma_address(sgt->sgl);
+	contig_size = zynqmp_fpga_get_contiguous_size(sgt);
+	if (priv->flags & FPGA_MGR_PARTIAL_RECONFIG)
+		eemi_flags |= XILINX_ZYNQMP_PM_FPGA_PARTIAL;
+
+	return zynqmp_pm_fpga_load(dma_addr, contig_size, eemi_flags);
+}
+
 static int zynqmp_fpga_ops_write_complete(struct fpga_manager *mgr,
 					  struct fpga_image_info *info)
 {
@@ -87,6 +121,7 @@ static const struct fpga_manager_ops zynqmp_fpga_ops = {
 	.state = zynqmp_fpga_ops_state,
 	.write_init = zynqmp_fpga_ops_write_init,
 	.write = zynqmp_fpga_ops_write,
+	.write_sg = zynqmp_fpga_ops_write_sg,
 	.write_complete = zynqmp_fpga_ops_write_complete,
 };
 
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:20:47 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:50:47 +0530
Subject: [PATCH 1/3] dt-bindings: zynqmp: Add new PD_PL macro
In-Reply-To: <20210402092049.479-1-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
Message-ID: <20210402092049.479-2-nava.manne@xilinx.com>

Add new power domain for PL region.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 include/dt-bindings/power/xlnx-zynqmp-power.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h b/include/dt-bindings/power/xlnx-zynqmp-power.h
index 0d9a412fd5e0..5f718759c38f 100644
--- a/include/dt-bindings/power/xlnx-zynqmp-power.h
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -35,5 +35,6 @@
 #define		PD_CAN_1	48
 #define		PD_GPU		58
 #define		PD_PCIE		59
+#define		PD_PL		69
 
 #endif
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:20:49 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:50:49 +0530
Subject: [PATCH 3/3] fpga: region: Adds runtime PM support
In-Reply-To: <20210402092049.479-1-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
Message-ID: <20210402092049.479-4-nava.manne@xilinx.com>

Adds support to handle FPGA/PL power domain. With this patch,
the PL power domain will be turned on before loading the bitstream
and turned off while removing/unloading the bitstream using overlays.
This can be achieved by adding the runtime PM support.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/fpga/of-fpga-region.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index e405309baadc..35fc2f3d4bd8 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -15,6 +15,7 @@
 #include <linux/of_platform.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/pm_runtime.h>
 
 static const struct of_device_id fpga_region_of_match[] = {
 	{ .compatible = "fpga-region", },
@@ -302,6 +303,7 @@ static int of_fpga_region_notify_pre_apply(struct fpga_region *region,
 	}
 
 	region->info = info;
+	pm_runtime_get_sync(dev->parent);
 	ret = fpga_region_program_fpga(region);
 	if (ret) {
 		/* error; reject overlay */
@@ -324,10 +326,13 @@ static int of_fpga_region_notify_pre_apply(struct fpga_region *region,
 static void of_fpga_region_notify_post_remove(struct fpga_region *region,
 					      struct of_overlay_notify_data *nd)
 {
+	struct device *dev = &region->dev;
+
 	fpga_bridges_disable(&region->bridge_list);
 	fpga_bridges_put(&region->bridge_list);
 	fpga_image_info_free(region->info);
 	region->info = NULL;
+	pm_runtime_put(dev->parent);
 }
 
 /**
@@ -411,9 +416,16 @@ static int of_fpga_region_probe(struct platform_device *pdev)
 		goto eprobe_mgr_put;
 	}
 
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0)
+		goto err_pm;
+
+	pm_runtime_put(&pdev->dev);
+
 	ret = fpga_region_register(region);
 	if (ret)
-		goto eprobe_mgr_put;
+		goto err_pm;
 
 	of_platform_populate(np, fpga_region_of_match, NULL, &region->dev);
 	platform_set_drvdata(pdev, region);
@@ -422,6 +434,9 @@ static int of_fpga_region_probe(struct platform_device *pdev)
 
 	return 0;
 
+err_pm:
+	pm_runtime_put(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
 eprobe_mgr_put:
 	fpga_mgr_put(mgr);
 	return ret;
@@ -434,6 +449,7 @@ static int of_fpga_region_remove(struct platform_device *pdev)
 
 	fpga_region_unregister(region);
 	fpga_mgr_put(mgr);
+	pm_runtime_disable(region->dev.parent);
 
 	return 0;
 }
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:20:48 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:50:48 +0530
Subject: [PATCH 2/3] fpga: region: Add fpga-region property 'power-domains'
In-Reply-To: <20210402092049.479-1-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
Message-ID: <20210402092049.479-3-nava.manne@xilinx.com>

Add fpga-region property 'power-domains' to allow to handle
the FPGA/PL power domins.

dt-bindings: fpga: Enable PM generic domain support

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 .../devicetree/bindings/fpga/fpga-region.txt       | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index e811cf825019..969ca53bb65e 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -196,6 +196,20 @@ Optional properties:
 - config-complete-timeout-us : The maximum time in microseconds time for the
 	FPGA to go to operating mode after the region has been programmed.
 - child nodes : devices in the FPGA after programming.
+- power-domains : A phandle and PM domain specifier as defined by bindings of
+	the power controller specified by phandle.
+Example:
+	fpga_full: fpga-full {
+                compatible = "fpga-region";
+                fpga-mgr = <&zynqmp_pcap>;
+                #address-cells = <2>;
+                #size-cells = <2>;
+                ranges;
+                power-domains = <&zynqmp_firmware PL_PD>;
+        };
+
+	The PL_PD power domain will be turned on before loading the bitstream
+and turned off while removing/unloading the bitstream using overlays.
 
 In the example below, when an overlay is applied targeting fpga-region0,
 fpga_mgr is used to program the FPGA.  Two bridges are controlled during
-- 
2.18.0



From nava.manne at xilinx.com  Fri Apr  2 10:20:46 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Fri, 2 Apr 2021 14:50:46 +0530
Subject: [PATCH 0/3]Enable PM generic domain support
Message-ID: <20210402092049.479-1-nava.manne@xilinx.com>

Adds support to handle FPGA/PL power Domain to optimize the PL power
consumption.

Nava kishore Manne (3):
  dt-bindings: zynqmp: Add new PD_PL macro
  fpga: region: Add fpga-region property 'power-domains'
  fpga: region: Adds runtime PM support

 .../devicetree/bindings/fpga/fpga-region.txt   | 14 ++++++++++++++
 drivers/fpga/of-fpga-region.c                  | 18 +++++++++++++++++-
 include/dt-bindings/power/xlnx-zynqmp-power.h  |  1 +
 3 files changed, 32 insertions(+), 1 deletion(-)

-- 
2.18.0



From weiyongjun1 at huawei.com  Fri Apr  2 10:40:41 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Fri, 2 Apr 2021 09:40:41 +0000
Subject: [PATCH -next] HID: thrustmaster: fix return value check in
 thrustmaster_probe()
Message-ID: <20210402094041.3424285-1-weiyongjun1@huawei.com>

Fix the return value check which testing the wrong variable
in thrustmaster_probe().

Fixes: c49c33637802 ("HID: support for initialization of some Thrustmaster wheels")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 drivers/hid/hid-thrustmaster.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-thrustmaster.c b/drivers/hid/hid-thrustmaster.c
index bfcd08759ba0..fada3536f60e 100644
--- a/drivers/hid/hid-thrustmaster.c
+++ b/drivers/hid/hid-thrustmaster.c
@@ -311,7 +311,7 @@ static int thrustmaster_probe(struct hid_device *hdev, const struct hid_device_i
 	}
 
 	tm_wheel->change_request = kzalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL);
-	if (!tm_wheel->model_request) {
+	if (!tm_wheel->change_request) {
 		ret = -ENOMEM;
 		goto error5;
 	}



From pbonzini at redhat.com  Fri Apr  2 10:34:38 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 11:34:38 +0200
Subject: [PATCH v2 09/10] KVM: Don't take mmu_lock for range invalidation
 unless necessary
In-Reply-To: <20210402005658.3024832-10-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-10-seanjc@google.com>
Message-ID: <417bd6b5-b7d0-ed22-adae-02150cdbfebe@redhat.com>

On 02/04/21 02:56, Sean Christopherson wrote:
> Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
> notifications.  Because mmu_notifier_count must be modified while holding
> mmu_lock for write, and must always be paired across start->end to stay
> balanced, lock elision must happen in both or none.  To meet that
> requirement, add a rwsem to prevent memslot updates across range_start()
> and range_end().
> 
> Use a rwsem instead of a rwlock since most notifiers _allow_ blocking,
> and the lock will be endl across the entire start() ... end() sequence.
> If anything in the sequence sleeps, including the caller or a different
> notifier, holding the spinlock would be disastrous.
> 
> For notifiers that _disallow_ blocking, e.g. OOM reaping, simply go down
> the slow path of unconditionally acquiring mmu_lock.  The sane
> alternative would be to try to acquire the lock and force the notifier
> to retry on failure.  But since OOM is currently the _only_ scenario
> where blocking is disallowed attempting to optimize a guest that has been
> marked for death is pointless.
> 
> Unconditionally define and use mmu_notifier_slots_lock in the memslots
> code, purely to avoid more #ifdefs.  The overhead of acquiring the lock
> is negligible when the lock is uncontested, which will always be the case
> when the MMU notifiers are not used.
> 
> Note, technically flag-only memslot updates could be allowed in parallel,
> but stalling a memslot update for a relatively short amount of time is
> not a scalability issue, and this is all more than complex enough.

Proposal for the locking documentation:

diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index b21a34c34a21..3e4ad7de36cb 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -16,6 +16,13 @@ The acquisition orders for mutexes are as follows:
  - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
    them together is quite rare.
  
+- The kvm->mmu_notifier_slots_lock rwsem ensures that pairs of
+  invalidate_range_start() and invalidate_range_end() callbacks
+  use the same memslots array.  kvm->slots_lock is taken outside the
+  write-side critical section of kvm->mmu_notifier_slots_lock, so
+  MMU notifiers must not take kvm->slots_lock.  No other write-side
+  critical sections should be added.
+
  On x86, vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock.
  
  Everything else is a leaf: no other lock is taken inside the critical

Paolo



From pbonzini at redhat.com  Fri Apr  2 10:35:36 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 11:35:36 +0200
Subject: [PATCH v2 07/10] KVM: Move MMU notifier's mmu_lock acquisition
 into common helper
In-Reply-To: <20210402005658.3024832-8-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-8-seanjc@google.com>
Message-ID: <a30f556a-40b2-f703-f0ee-b985989ee4b7@redhat.com>

On 02/04/21 02:56, Sean Christopherson wrote:
> +		.handler	= (void *)kvm_null_fn,
> +		.on_lock	= kvm_dec_notifier_count,
> +		.flush_on_ret	= true,

Doesn't really matter since the handler is null, but I think it's 
cleaner to have false here.

Paolo



From syednwaris at gmail.com  Fri Apr  2 10:40:37 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:10:37 +0530
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <CAHp75VePT-Df1F8ma1__ay8+9DHtYwonvwTZtK-OFqCtXshx-w@mail.gmail.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <CAHp75VePT-Df1F8ma1__ay8+9DHtYwonvwTZtK-OFqCtXshx-w@mail.gmail.com>
Message-ID: <CACG_h5pNhJJQ1nvmPmT1iZJwtLB+a-4nmy=TmgU6GLWiyF=bHA@mail.gmail.com>

On Fri, Mar 26, 2021 at 11:27 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
>
> On Sat, Mar 6, 2021 at 4:08 PM Syed Nayyar Waris <syednwaris at gmail.com> wrote:
> >
> > This patch reimplements the xgpio_set_multiple() function in
> > drivers/gpio/gpio-xilinx.c to use the new generic functions:
> > bitmap_get_value() and bitmap_set_value(). The code is now simpler
> > to read and understand. Moreover, instead of looping for each bit
> > in xgpio_set_multiple() function, now we can check each channel at
> > a time and save cycles.
>
> ...
>
> > +       u32 *const state = chip->gpio_state;
> > +       unsigned int *const width = chip->gpio_width;
>
> > +
>
> Extra blank line.
>
> > +       DECLARE_BITMAP(old, 64);
> > +       DECLARE_BITMAP(new, 64);
> > +       DECLARE_BITMAP(changed, 64);
>
> > +       spin_lock_irqsave(&chip->gpio_lock[0], flags);
> > +       spin_lock(&chip->gpio_lock[1]);
>
> I understand why this is done at the top of the function in the original code.
> I do not understand why you put some operations under spin lock.
>
> Have you checked what each of these spin locks protects?
> Please check and try to lock as minimum as possible.
>
> > +       bitmap_set_value(old, 64, state[0], width[0], 0);
> > +       bitmap_set_value(old, 64, state[1], width[1], width[0]);
> > +       bitmap_replace(new, old, bits, mask, gc->ngpio);
> > +
> > +       bitmap_set_value(old, 64, state[0], 32, 0);
> > +       bitmap_set_value(old, 64, state[1], 32, 32);
> > +       state[0] = bitmap_get_value(new, 0, width[0]);
> > +       state[1] = bitmap_get_value(new, width[0], width[1]);
> > +       bitmap_set_value(new, 64, state[0], 32, 0);
> > +       bitmap_set_value(new, 64, state[1], 32, 32);
> > +       bitmap_xor(changed, old, new, 64);
>
> Original code and this is cryptic. Can you add a few comments
> explaining what is going on here?
>
> > +       spin_unlock(&chip->gpio_lock[1]);
> > +       spin_unlock_irqrestore(&chip->gpio_lock[0], flags);
>
> --
> With Best Regards,
> Andy Shevchenko

Have removed the extra line and added comments. Regarding locking - I
see that now there is just a single lock available instead of 2 locks.
Have made necessary changes. Thanks
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpio/gpio-xilinx.c?id=37ef334680800263b32bb96a5156a4b47f0244a2

Regards

Syed Nayyar Waris


From herbert at gondor.apana.org.au  Fri Apr  2 10:47:36 2021
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 2 Apr 2021 20:47:36 +1100
Subject: [PATCH] crypto: poly1305: fix poly1305_core_setkey() declaration
In-Reply-To: <20210322170542.1791154-1-arnd@kernel.org>
References: <20210322170542.1791154-1-arnd@kernel.org>
Message-ID: <20210402094736.GC24509@gondor.apana.org.au>

On Mon, Mar 22, 2021 at 06:05:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> gcc-11 points out a mismatch between the declaration and the definition
> of poly1305_core_setkey():
> 
> lib/crypto/poly1305-donna32.c:13:67: error: argument 2 of type ?const u8[16]? {aka ?const unsigned char[16]?} with mismatched bound [-Werror=array-parameter=]
>    13 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 raw_key[16])
>       |                                                          ~~~~~~~~~^~~~~~~~~~~
> In file included from lib/crypto/poly1305-donna32.c:11:
> include/crypto/internal/poly1305.h:21:68: note: previously declared as ?const u8 *? {aka ?const unsigned char *?}
>    21 | void poly1305_core_setkey(struct poly1305_core_key *key, const u8 *raw_key);
> 
> This is harmless in principle, as the calling conventions are the same,
> but the more specific prototype allows better type checking in the
> caller.
> 
> Change the declaration to match the actual function definition.
> The poly1305_simd_init() is a bit suspicious here, as it previously
> had a 32-byte argument type, but looks like it needs to take the
> 16-byte POLY1305_BLOCK_SIZE array instead.
> 
> Fixes: 1c08a104360f ("crypto: poly1305 - add new 32 and 64-bit generic versions")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/crypto/poly1305-glue.c    | 2 +-
>  arch/arm64/crypto/poly1305-glue.c  | 2 +-
>  arch/mips/crypto/poly1305-glue.c   | 2 +-
>  arch/x86/crypto/poly1305_glue.c    | 6 +++---
>  include/crypto/internal/poly1305.h | 3 ++-
>  include/crypto/poly1305.h          | 6 ++++--
>  lib/crypto/poly1305-donna32.c      | 3 ++-
>  lib/crypto/poly1305-donna64.c      | 3 ++-
>  lib/crypto/poly1305.c              | 3 ++-
>  9 files changed, 18 insertions(+), 12 deletions(-)

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 jic23 at kernel.org  Fri Apr  2 10:53:35 2021
From: jic23 at kernel.org (Jonathan Cameron)
Date: Fri, 2 Apr 2021 10:53:35 +0100
Subject: [PATCH] iio: adc: stm32-dfsdm: drop __func__ while using
 Dynamic debug
In-Reply-To: <CAHp75VfkCQpfUrVcWHUnD4DLMp9iZJBL8mYfsYOCsESm_y068A@mail.gmail.com>
References: <20210401154343.41527-1-dmugil2000@gmail.com>
 <CAHp75VfkCQpfUrVcWHUnD4DLMp9iZJBL8mYfsYOCsESm_y068A@mail.gmail.com>
Message-ID: <20210402105335.1bfbaf2e@jic23-huawei>

On Thu, 1 Apr 2021 21:05:58 +0300
Andy Shevchenko <andy.shevchenko at gmail.com> wrote:

> On Thu, Apr 1, 2021 at 8:48 PM Mugilraj Dhavachelvan
> <dmugil2000 at gmail.com> wrote:
> >
> > dropped __func__ while using dev_dbg() and pr_debug()  
> 
> The commit message may be amended, from code perspective LGTM!
> Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>

I added a note to the commit message to observe that the function
name printing can be configured using dynamic debug.

Applied to the togreg branch of iio.git and pushed out as testing
to let the autobuilder bots like 0-day check if they can find any
problems that we've missed.

Thanks,

Jonathan

> 
> > Signed-off-by: Mugilraj Dhavachelvan <dmugil2000 at gmail.com>
> > ---
> >  drivers/iio/adc/stm32-dfsdm-adc.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
> > index 76a60d93fe23..95ec5f3c3126 100644
> > --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> > +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> > @@ -198,7 +198,7 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
> >         unsigned int p = fl->ford;      /* filter order (ford) */
> >         struct stm32_dfsdm_filter_osr *flo = &fl->flo[fast];
> >
> > -       pr_debug("%s: Requested oversampling: %d\n",  __func__, oversamp);
> > +       pr_debug("Requested oversampling: %d\n", oversamp);
> >         /*
> >          * This function tries to compute filter oversampling and integrator
> >          * oversampling, base on oversampling ratio requested by user.
> > @@ -294,8 +294,8 @@ static int stm32_dfsdm_compute_osrs(struct stm32_dfsdm_filter *fl,
> >                                 }
> >                                 flo->max = (s32)max;
> >
> > -                               pr_debug("%s: fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
> > -                                        __func__, fast, flo->fosr, flo->iosr,
> > +                               pr_debug("fast %d, fosr %d, iosr %d, res 0x%llx/%d bits, rshift %d, lshift %d\n",
> > +                                        fast, flo->fosr, flo->iosr,
> >                                          flo->res, bits, flo->rshift,
> >                                          flo->lshift);
> >                         }
> > @@ -858,7 +858,7 @@ static void stm32_dfsdm_dma_buffer_done(void *data)
> >          * support in IIO.
> >          */
> >
> > -       dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
> > +       dev_dbg(&indio_dev->dev, "pos = %d, available = %d\n",
> >                 adc->bufi, available);
> >         old_pos = adc->bufi;
> >
> > @@ -912,7 +912,7 @@ static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
> >         if (!adc->dma_chan)
> >                 return -EINVAL;
> >
> > -       dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
> > +       dev_dbg(&indio_dev->dev, "size=%d watermark=%d\n",
> >                 adc->buf_sz, adc->buf_sz / 2);
> >
> >         if (adc->nconv == 1 && !indio_dev->trig)
> > --
> > 2.25.1
> >  
> 
> 



From maz at kernel.org  Fri Apr  2 11:06:56 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 02 Apr 2021 11:06:56 +0100
Subject: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53
 and A57
In-Reply-To: <20210401110615.15326-2-s.hauer@pengutronix.de>
References: <20210401110615.15326-1-s.hauer@pengutronix.de>
 <20210401110615.15326-2-s.hauer@pengutronix.de>
Message-ID: <87czvdf1a7.wl-maz@kernel.org>

On Thu, 01 Apr 2021 12:06:14 +0100,
Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 
> The Cortex A53 and A57 cores have error detection capabilities for the
> L1/L2 Caches, this patch adds a driver for them.
> 
> Unfortunately there is no robust way to inject errors into the caches,
> so this driver doesn't contain any code to actually test it. It has
> been tested though with code taken from an older version of this driver
> found here: https://lkml.org/lkml/2018/3/14/1203. For reasons stated
> in this thread the error injection code is not suitable for mainline,
> so it is removed from the driver.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> ---
>  drivers/edac/Kconfig              |   6 +
>  drivers/edac/Makefile             |   1 +
>  drivers/edac/cortex_arm64_l1_l2.c | 218 ++++++++++++++++++++++++++++++
>  3 files changed, 225 insertions(+)
>  create mode 100644 drivers/edac/cortex_arm64_l1_l2.c
> 
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 27d0c4cdc58d..b038aed35e93 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -538,4 +538,10 @@ config EDAC_DMC520
>  	  Support for error detection and correction on the
>  	  SoCs with ARM DMC-520 DRAM controller.
>  
> +config EDAC_CORTEX_ARM64_L1_L2
> +	tristate "ARM Cortex A57/A53"
> +	depends on ARM64
> +	help
> +	  Support for L1/L2 cache error detection on ARM Cortex A57 and A53.

I went through the TRMs for a few other Cortex-A cores, and this
feature looks more common than this comment suggests. At least A35 and
A72 implement something similar (if not strictly identical), probably
owing to their ancestry.

> +
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index 2d1641a27a28..5849d8bb32ae 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_EDAC_QCOM)			+= qcom_edac.o
>  obj-$(CONFIG_EDAC_ASPEED)		+= aspeed_edac.o
>  obj-$(CONFIG_EDAC_BLUEFIELD)		+= bluefield_edac.o
>  obj-$(CONFIG_EDAC_DMC520)		+= dmc520_edac.o
> +obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)	+= cortex_arm64_l1_l2.o
> diff --git a/drivers/edac/cortex_arm64_l1_l2.c b/drivers/edac/cortex_arm64_l1_l2.c
> new file mode 100644
> index 000000000000..3b1e2f3ccab6
> --- /dev/null
> +++ b/drivers/edac/cortex_arm64_l1_l2.c
> @@ -0,0 +1,218 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Cortex A57 and A53 EDAC L1 and L2 cache error detection
> + *
> + * Copyright (c) 2020 Pengutronix, Sascha Hauer <s.hauer at pengutronix.de>
> + *
> + * Based on Code from:
> + * Copyright (c) 2018, NXP Semiconductor
> + * Author: York Sun <york.sun at nxp.com>
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/bitfield.h>
> +#include <asm/smp_plat.h>
> +
> +#include "edac_module.h"
> +
> +#define DRVNAME				"cortex-arm64-edac"
> +
> +#define CPUMERRSR_EL1_RAMID		GENMASK(30, 24)
> +
> +#define CPUMERRSR_EL1_VALID		BIT(31)
> +#define CPUMERRSR_EL1_FATAL		BIT(63)
> +
> +#define L1_I_TAG_RAM			0x00
> +#define L1_I_DATA_RAM			0x01
> +#define L1_D_TAG_RAM			0x08
> +#define L1_D_DATA_RAM			0x09
> +#define L1_D_DIRTY_RAM			0x14
> +#define TLB_RAM				0x18
> +
> +#define L2MERRSR_EL1_VALID		BIT(31)
> +#define L2MERRSR_EL1_FATAL		BIT(63)
> +
> +struct merrsr {
> +	u64 cpumerr;
> +	u64 l2merr;
> +};
> +
> +#define MESSAGE_SIZE 64
> +
> +#define SYS_CPUMERRSR_EL1			sys_reg(3, 1, 15, 2, 2)
> +#define SYS_L2MERRSR_EL1			sys_reg(3, 1, 15, 2, 3)
> +
> +static struct cpumask compat_mask;
> +
> +static void report_errors(struct edac_device_ctl_info *edac_ctl, int cpu,
> +			  struct merrsr *merrsr)
> +{
> +	char msg[MESSAGE_SIZE];
> +	u64 cpumerr = merrsr->cpumerr;
> +	u64 l2merr = merrsr->l2merr;
> +
> +	if (cpumerr & CPUMERRSR_EL1_VALID) {
> +		const char *str;
> +		bool fatal = cpumerr & CPUMERRSR_EL1_FATAL;
> +
> +		switch (FIELD_GET(CPUMERRSR_EL1_RAMID, cpumerr)) {
> +		case L1_I_TAG_RAM:
> +			str = "L1-I Tag RAM";
> +			break;
> +		case L1_I_DATA_RAM:
> +			str = "L1-I Data RAM";
> +			break;
> +		case L1_D_TAG_RAM:
> +			str = "L1-D Tag RAM";
> +			break;
> +		case L1_D_DATA_RAM:
> +			str = "L1-D Data RAM";
> +			break;
> +		case L1_D_DIRTY_RAM:
> +			str = "L1 Dirty RAM";
> +			break;
> +		case TLB_RAM:
> +			str = "TLB RAM";
> +			break;
> +		default:
> +			str = "unknown";
> +			break;
> +		}
> +
> +		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
> +			 str, fatal ? "fatal" : "correctable", cpu);
> +
> +		if (fatal)
> +			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
> +		else
> +			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
> +	}
> +
> +	if (l2merr & L2MERRSR_EL1_VALID) {
> +		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
> +
> +		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d",
> +			 fatal ? "fatal" : "correctable", cpu);

The shared nature of the L2 makes the CPU it has been detected on
pretty much irrelevant. What you really want here is the CPUID+Way
that is in the register data.

> +		if (fatal)
> +			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
> +		else
> +			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
> +	}
> +}
> +
> +static void read_errors(void *data)
> +{
> +	struct merrsr *merrsr = data;
> +
> +	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
> +	write_sysreg_s(0, SYS_CPUMERRSR_EL1);
> +	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
> +	write_sysreg_s(0, SYS_L2MERRSR_EL1);

If an error happens between read and write, you lose it. That's not
great. You could improve things by only writing 0 if you have found an
error. You probably also need an isb after the write if you want it to
take effect in a timely manner.

I'm also not sure of how valuable it is to probe for L2 errors on each
CPU, given that it is shared with up to 3 other cores. You probably
want to use the cache topology information for this.

Thanks,

	M.

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


From syednwaris at gmail.com  Fri Apr  2 11:07:26 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:37:26 +0530
Subject: [PATCH v3 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <YGHxNFXAjcg4PfnE@smile.fi.intel.com>
References: <cover.1615038553.git.syednwaris@gmail.com>
 <4c259d34b5943bf384fd3cb0d98eccf798a34f0f.1615038553.git.syednwaris@gmail.com>
 <YGHxNFXAjcg4PfnE@smile.fi.intel.com>
Message-ID: <CACG_h5qV2g7GUKtktBydxfx2Z-o3_6Tssj_+Dt-xZxYKVo9YMw@mail.gmail.com>

On Mon, Mar 29, 2021 at 8:54 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> On Sat, Mar 06, 2021 at 07:36:30PM +0530, Syed Nayyar Waris wrote:
> > This patch reimplements the xgpio_set_multiple() function in
> > drivers/gpio/gpio-xilinx.c to use the new generic functions:
> > bitmap_get_value() and bitmap_set_value(). The code is now simpler
> > to read and understand. Moreover, instead of looping for each bit
> > in xgpio_set_multiple() function, now we can check each channel at
> > a time and save cycles.
>
> ...
>
> > +     u32 *const state = chip->gpio_state;
>
> Looking at this... What's the point of the const here?
>
> Am I right that this tells: pointer is a const, while the data underneath
> can be modified?

Yes you are right and the data underneath can be modified.
I have removed the 'const' in v4

>
> > +     unsigned int *const width = chip->gpio_width;
>
> Ditto.
>
> Putting const:s here and there for sake of the const is not good practice.
> It makes code harder to read.

Okay.

>
> --
> With Best Regards,
> Andy Shevchenko
>
>


From syednwaris at gmail.com  Fri Apr  2 11:10:44 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:40:44 +0530
Subject: [PATCH v4 0/3] Introduce the for_each_set_nbits macro
Message-ID: <cover.1617357235.git.syednwaris@gmail.com>

Hello Bartosz,

Since this patchset primarily affects GPIO drivers, would you like
to pick it up through your GPIO tree?

This patchset introduces a new generic version of for_each_set_nbits.
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated a
for-loop syntax that iterates over a memory region entire groups of set
bits at a time.

For example, suppose you would like to iterate over a 32-bit integer 8
bits at a time, skipping over 8-bit groups with no set bit, where
XXXXXXXX represents the current 8-bit group:

    Example:        10111110 00000000 11111111 00110011
    First loop:     10111110 00000000 11111111 XXXXXXXX
    Second loop:    10111110 00000000 XXXXXXXX 00110011
    Third loop:     XXXXXXXX 00000000 11111111 00110011

Each iteration of the loop returns the next 8-bit group that has at
least one set bit.

But with the new for_each_set_nbits the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word
size is not multiple of clump size. Following are examples showing the working
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x000000aa000000aa;
        0xbbbbabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_nbits:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:        offset: 0 clump: 0xfedcba
Iteration second:       offset: 24 clump: 0xabcdef
Iteration third:        offset: 48 clump: 0xaabbbb
Iteration fourth:       offset: 96 clump: 0xaa
Iteration fifth:        offset: 144 clump: 0xff
Iteration sixth:        offset: 168 clump: 0xaaaaaa
Iteration seventh:      offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour).

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x0f00000000000000;
        0x0000000000000ac0;  /* Least significant bits */

Different iterations of for_each_set_nbits:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:        offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v4:
 - [Patch 3/3]: Remove extra line and add few comments.
 - [Patch 3/3]: Use single lock (and unlock) call instead of two 
   lock (and two unlock) calls.
 - [Patch 3/3]: Use bitmap_from_arr32() where applicalble.
 - [Patch 3/3]: Remove unnecessary 'const'.

Changes in v3:
 - [Patch 1/3]: Rename for_each_set_clump to for_each_set_nbits.
 - [Patch 1/3]: Shift function definitions outside 'ifdef CONFIG_DEBUG_FS'
   macro guard to resolve build (linking) error in xilinx Patch[3/3].
 - [Patch 2/3]: Rename for_each_set_clump to for_each_set_nbits.

Changes in v2:
 - [Patch 1/3]: Shift the macros and related functions to gpiolib inside
   gpio/. Reduce the visibilty of 'for_each_set_clump' to gpio.
 - [Patch 1/3]: Remove __builtin_unreachable and simply use return
   statement.
 - Remove tests from lib/test_bitmap.c as 'for_each_set_clump' is
   now localised inside gpio/ only.

Syed Nayyar Waris (3):
  gpiolib: Introduce the for_each_set_nbits macro
  gpio: thunderx: Utilize for_each_set_nbits macro
  gpio: xilinx: Utilize generic bitmap_get_value and _set_value

 drivers/gpio/gpio-thunderx.c | 13 ++++--
 drivers/gpio/gpio-xilinx.c   | 60 ++++++++++++------------
 drivers/gpio/gpiolib.c       | 90 ++++++++++++++++++++++++++++++++++++
 drivers/gpio/gpiolib.h       | 28 +++++++++++
 4 files changed, 156 insertions(+), 35 deletions(-)


base-commit: e1b7033ecdac56c1cc4dff72d67cac25d449efc6
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 11:11:24 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:41:24 +0530
Subject: [PATCH v4 1/3] gpiolib: Introduce the for_each_set_nbits macro
In-Reply-To: <cover.1617357235.git.syednwaris@gmail.com>
References: <cover.1617357235.git.syednwaris@gmail.com>
Message-ID: <12102d94258fc6bd5c01800b7cea680fc51d8b93.1617357235.git.syednwaris@gmail.com>

This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value() and bitmap_set_value() functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size from 1 to BITS_PER_LONG. size less
than 1 or more than BITS_PER_LONG causes undefined behaviour.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving the value from bitmap.

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Bartosz Go?aszewski <bgolaszewski at baylibre.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpiolib.c | 90 ++++++++++++++++++++++++++++++++++++++++++
 drivers/gpio/gpiolib.h | 28 +++++++++++++
 2 files changed, 118 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1427c1be749b..5576d1465c81 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -150,6 +150,96 @@ struct gpio_desc *gpiochip_get_desc(struct gpio_chip *gc,
 }
 EXPORT_SYMBOL_GPL(gpiochip_get_desc);
 
+/**
+ * bitmap_get_value - get 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 (must be between 1 and BITS_PER_LONG inclusive).
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+unsigned long bitmap_get_value(const unsigned long *map,
+				unsigned long start,
+				unsigned long nbits)
+{
+	const size_t index = BIT_WORD(start);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+	unsigned long value_low, value_high;
+
+	if (space >= nbits)
+		return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+	else {
+		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);
+	}
+}
+EXPORT_SYMBOL_GPL(bitmap_get_value);
+
+/**
+ * bitmap_set_value - set value within a memory region
+ * @map: address to the bitmap memory region
+ * @nbits: size of map in bits
+ * @value: value of clump
+ * @value_width: size of value in bits (must be between 1 and BITS_PER_LONG inclusive)
+ * @start: bit offset of the value
+ */
+void bitmap_set_value(unsigned long *map, unsigned long nbits,
+			unsigned long value, unsigned long value_width,
+			unsigned long start)
+{
+	const unsigned long index = BIT_WORD(start);
+	const unsigned long length = BIT_WORD(nbits);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+
+	value &= GENMASK(value_width - 1, 0);
+
+	if (space >= value_width) {
+		map[index] &= ~(GENMASK(value_width - 1, 0) << offset);
+		map[index] |= value << offset;
+	} else {
+		map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start);
+		map[index + 0] |= value << offset;
+
+		if (index + 1 >= length)
+			return;
+
+		map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + value_width);
+		map[index + 1] |= value >> space;
+	}
+}
+EXPORT_SYMBOL_GPL(bitmap_set_value);
+
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+unsigned long find_next_clump(unsigned long *clump, const unsigned long *addr,
+				unsigned long size, unsigned long offset,
+				unsigned long clump_size)
+{
+	offset = find_next_bit(addr, size, offset);
+	if (offset == size)
+		return size;
+
+	offset = rounddown(offset, clump_size);
+	*clump = bitmap_get_value(addr, offset, clump_size);
+	return offset;
+}
+EXPORT_SYMBOL_GPL(find_next_clump);
+
 /**
  * desc_to_gpio - convert a GPIO descriptor to the integer namespace
  * @desc: GPIO descriptor
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 30bc3f80f83e..af79784dfce3 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -141,6 +141,34 @@ int gpio_set_debounce_timeout(struct gpio_desc *desc, unsigned int debounce);
 int gpiod_hog(struct gpio_desc *desc, const char *name,
 		unsigned long lflags, enum gpiod_flags dflags);
 
+unsigned long bitmap_get_value(const unsigned long *map,
+				unsigned long start,
+				unsigned long nbits);
+
+void bitmap_set_value(unsigned long *map, unsigned long nbits,
+			unsigned long value, unsigned long value_width,
+			unsigned long start);
+
+unsigned long find_next_clump(unsigned long *clump, const unsigned long *addr,
+				unsigned long size, unsigned long offset,
+				unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+	find_next_clump((clump), (bits), (size), 0, (clump_size))
+
+/**
+ * for_each_set_nbits - iterate over bitmap for each clump with set bits
+ * @start: bit offset to start search and to store the current iteration offset
+ * @clump: location to store copy of current 8-bit clump
+ * @bits: bitmap address to base the search on
+ * @size: bitmap size in number of bits
+ * @clump_size: clump size in bits
+ */
+#define for_each_set_nbits(start, clump, bits, size, clump_size) \
+	for ((start) = find_first_clump(&(clump), (bits), (size), (clump_size)); \
+	     (start) < (size); \
+	     (start) = find_next_clump(&(clump), (bits), (size), (start) + (clump_size), (clump_size)))
+
 /*
  * Return the GPIO number of the passed descriptor relative to its chip
  */
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 11:12:06 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:42:06 +0530
Subject: [PATCH v4 2/3] gpio: thunderx: Utilize for_each_set_nbits macro
In-Reply-To: <cover.1617357235.git.syednwaris@gmail.com>
References: <cover.1617357235.git.syednwaris@gmail.com>
Message-ID: <3a9bd0a593798538bec54d8b5ceab20a73d7eaa1.1617357235.git.syednwaris@gmail.com>

This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_nbits macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.

Cc: Robert Richter <rrichter at marvell.com>
Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpio-thunderx.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..4349e7393a1d 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -16,7 +16,7 @@
 #include <linux/pci.h>
 #include <linux/spinlock.h>
 #include <asm-generic/msi.h>
-
+#include "gpiolib.h"
 
 #define GPIO_RX_DAT	0x0
 #define GPIO_TX_SET	0x8
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip *chip,
 				       unsigned long *bits)
 {
 	int bank;
-	u64 set_bits, clear_bits;
+	unsigned long set_bits, clear_bits, gpio_mask;
+	unsigned long offset;
+
 	struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
 
-	for (bank = 0; bank <= chip->ngpio / 64; bank++) {
-		set_bits = bits[bank] & mask[bank];
-		clear_bits = ~bits[bank] & mask[bank];
+	for_each_set_nbits(offset, gpio_mask, mask, chip->ngpio, 64) {
+		bank = offset / 64;
+		set_bits = bits[bank] & gpio_mask;
+		clear_bits = ~bits[bank] & gpio_mask;
 		writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_SET);
 		writeq(clear_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_CLR);
 	}
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 11:12:40 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 15:42:40 +0530
Subject: [PATCH v4 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <cover.1617357235.git.syednwaris@gmail.com>
References: <cover.1617357235.git.syednwaris@gmail.com>
Message-ID: <00d085d4068be651c58a61564926d4f3d495ab80.1617357235.git.syednwaris@gmail.com>

This patch reimplements the xgpio_set_multiple() function in
drivers/gpio/gpio-xilinx.c to use the new generic functions:
bitmap_get_value() and bitmap_set_value(). The code is now simpler
to read and understand. Moreover, instead of looping for each bit
in xgpio_set_multiple() function, now we can check each channel at
a time and save cycles.

Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
Cc: Michal Simek <michal.simek at xilinx.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpio-xilinx.c | 60 +++++++++++++++++++-------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index b411d3156e0b..e0ad3a81f216 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -18,6 +18,7 @@
 #include <linux/of_platform.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
+#include "gpiolib.h"
 
 /* Register Offset Definitions */
 #define XGPIO_DATA_OFFSET   (0x0)	/* Data register  */
@@ -161,37 +162,36 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 {
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
 
-	spin_lock_irqsave(&chip->gpio_lock, flags);
-
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock, flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock, flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
-	}
-
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
-	spin_unlock_irqrestore(&chip->gpio_lock, flags);
+    u32 *state = chip->gpio_state;
+    unsigned int *width = chip->gpio_width;
+    DECLARE_BITMAP(old, 64);
+    DECLARE_BITMAP(new, 64);
+    DECLARE_BITMAP(changed, 64);
+
+    spin_lock_irqsave(&chip->gpio_lock, flags);
+
+    /* Copy initial value of state bits into 'old' bit-wise */
+    bitmap_set_value(old, 64, state[0], width[0], 0);
+    bitmap_set_value(old, 64, state[1], width[1], width[0]);
+    /* Copy value from 'old' into 'new' with mask applied */
+    bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+    bitmap_from_arr32(old, state, 64);
+    /* Update 'state' */
+    state[0] = bitmap_get_value(new, 0, width[0]);
+    state[1] = bitmap_get_value(new, width[0], width[1]);
+    bitmap_from_arr32(new, state, 64);
+    /* XOR operation sets only changed bits */
+    bitmap_xor(changed, old, new, 64);
+
+    if (((u32 *)changed)[0])
+        xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET, state[0]);
+    if (((u32 *)changed)[1])
+        xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+                XGPIO_CHANNEL_OFFSET, state[1]);
+
+    spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
 
 /**
-- 
2.29.0



From lkp at intel.com  Fri Apr  2 11:26:55 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:55 +0800
Subject: [soc:for-next] BUILD SUCCESS 4ddda2b8d5bb61f7b2390523be8bfbc735229d02
Message-ID: <6066f16f.77FfVUQr/rkRBehQ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 4ddda2b8d5bb61f7b2390523be8bfbc735229d02  soc: document merges

elapsed time: 726m

configs tested: 146
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                           h5000_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
mips                        qi_lb60_defconfig
mips                       rbtx49xx_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
powerpc                     redwood_defconfig
sh                        edosk7760_defconfig
h8300                    h8300h-sim_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
arm                     am200epdkit_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
riscv                    nommu_k210_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:43 +0800
Subject: [soc:at91/soc] BUILD SUCCESS 41dbf4a146a06443d1cbf39e238f02fa1ca9d626
Message-ID: <6066f163.cgwKNJbMdXb0l8NP%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git at91/soc
branch HEAD: 41dbf4a146a06443d1cbf39e238f02fa1ca9d626  ARM: at91: pm: Move prototypes to mutually included header

elapsed time: 9660m

configs tested: 488
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
sh                          rsk7203_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                  mpc866_ads_defconfig
arm                          gemini_defconfig
powerpc                        icon_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
sh                               alldefconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
arc                        nsimosci_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
sh                           se7780_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
powerpc                          allmodconfig
arm                          ixp4xx_defconfig
powerpc                     ep8248e_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
nios2                         10m50_defconfig
powerpc                       holly_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                         orion5x_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
ia64                          tiger_defconfig
powerpc                         wii_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                     pseries_defconfig
arm                        mini2440_defconfig
mips                          ath25_defconfig
mips                          ath79_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                       ebony_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
nds32                            alldefconfig
arc                     haps_hs_smp_defconfig
arm                      footbridge_defconfig
ia64                            zx1_defconfig
m68k                                defconfig
arm                          imote2_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
xtensa                generic_kc705_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      ppc40x_defconfig
sh                   rts7751r2dplus_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
mips                            ar7_defconfig
powerpc                          g5_defconfig
h8300                       h8s-sim_defconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
um                             i386_defconfig
powerpc                     sbc8548_defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
sparc64                             defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
arc                          axs101_defconfig
arm                       imx_v4_v5_defconfig
m68k                       m5249evb_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
arm                          pxa3xx_defconfig
arm                       aspeed_g5_defconfig
mips                     loongson1c_defconfig
sparc                            alldefconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
mips                        workpad_defconfig
sh                             sh03_defconfig
arm                   milbeaut_m10v_defconfig
arm                        multi_v7_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
parisc                generic-64bit_defconfig
h8300                    h8300h-sim_defconfig
arm                            qcom_defconfig
arm                  colibri_pxa270_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
sh                            titan_defconfig
powerpc                     tqm8560_defconfig
arm                       multi_v4t_defconfig
arm                            mps2_defconfig
s390                          debug_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
powerpc                    amigaone_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
sh                          r7785rp_defconfig
mips                           ip32_defconfig
arc                          axs103_defconfig
powerpc                   motionpro_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
mips                        jmr3927_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
ia64                      gensparse_defconfig
mips                          malta_defconfig
arm                        trizeps4_defconfig
powerpc                       eiger_defconfig
arm                      tct_hammer_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
h8300                               defconfig
sh                      rts7751r2d1_defconfig
sh                            migor_defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
um                                allnoconfig
sparc                       sparc64_defconfig
sh                           se7705_defconfig
powerpc                      chrp32_defconfig
powerpc                     rainier_defconfig
m68k                             alldefconfig
riscv                    nommu_virt_defconfig
alpha                               defconfig
xtensa                  cadence_csp_defconfig
powerpc                      walnut_defconfig
i386                             alldefconfig
mips                           xway_defconfig
arm                      pxa255-idp_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
sh                          rsk7201_defconfig
arm                       cns3420vb_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
sh                        dreamcast_defconfig
mips                        qi_lb60_defconfig
mips                          rb532_defconfig
nds32                               defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
sh                           se7343_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     mpc5200_defconfig
mips                           mtx1_defconfig
sh                             shx3_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7780mp_defconfig
arc                         haps_hs_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
arm                         palmz72_defconfig
arm                         mv78xx0_defconfig
alpha                            allyesconfig
sh                         ap325rxa_defconfig
mips                        maltaup_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
xtensa                       common_defconfig
ia64                         bigsur_defconfig
sh                           se7206_defconfig
s390                       zfcpdump_defconfig
arm                    vt8500_v6_v7_defconfig
m68k                            q40_defconfig
mips                malta_qemu_32r6_defconfig
m68k                       m5275evb_defconfig
mips                           ci20_defconfig
arm                         cm_x300_defconfig
arm                         s5pv210_defconfig
powerpc                 mpc8272_ads_defconfig
arm                           corgi_defconfig
sh                        edosk7760_defconfig
sh                 kfr2r09-romimage_defconfig
arm                           stm32_defconfig
arm                           sunxi_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
mips                   sb1250_swarm_defconfig
s390                             allyesconfig
nds32                             allnoconfig
riscv             nommu_k210_sdcard_defconfig
arc                      axs103_smp_defconfig
powerpc                      ppc6xx_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
mips                        nlm_xlp_defconfig
arm                       versatile_defconfig
um                               allmodconfig
mips                malta_kvm_guest_defconfig
m68k                             allyesconfig
arc                              allyesconfig
nios2                            allyesconfig
csky                                defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a005-20210326
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
i386                 randconfig-a003-20210327
i386                 randconfig-a004-20210327
i386                 randconfig-a001-20210327
i386                 randconfig-a002-20210327
i386                 randconfig-a006-20210327
i386                 randconfig-a005-20210327
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a015-20210328
x86_64               randconfig-a012-20210328
x86_64               randconfig-a013-20210328
x86_64               randconfig-a014-20210328
x86_64               randconfig-a016-20210328
x86_64               randconfig-a011-20210328
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a002-20210328
x86_64               randconfig-a003-20210328
x86_64               randconfig-a001-20210328
x86_64               randconfig-a006-20210328
x86_64               randconfig-a005-20210328
x86_64               randconfig-a004-20210328
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:52 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:52 +0800
Subject: [soc:arm/defconfig] BUILD SUCCESS
 630bc9784b637eac9266d7133cb8698c5507ae7d
Message-ID: <6066f16c.yicv60l4k56b5+wU%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/defconfig
branch HEAD: 630bc9784b637eac9266d7133cb8698c5507ae7d  Merge tag 'at91-defconfig-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/defconfig

elapsed time: 726m

configs tested: 181
configs skipped: 85

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
m68k                             allmodconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
mips                        qi_lb60_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                        edosk7760_defconfig
sh                           se7619_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:58 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:58 +0800
Subject: [soc:imx/defconfig] BUILD SUCCESS
 94c586e5941a472fd114815f0eed2f2bb6b83a11
Message-ID: <6066f172.vT3L+dZszIig2K1s%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/defconfig
branch HEAD: 94c586e5941a472fd114815f0eed2f2bb6b83a11  arm64: configs: enable FlexTimer alarm timer

elapsed time: 6227m

configs tested: 387
configs skipped: 124

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
m68k                            q40_defconfig
mips                     loongson1c_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
sh                            migor_defconfig
mips                         cobalt_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
powerpc                      walnut_defconfig
parisc                generic-32bit_defconfig
sh                         ecovec24_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
powerpc                     akebono_defconfig
powerpc                    adder875_defconfig
sh                         microdev_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                           sh2007_defconfig
arc                        nsimosci_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
m68k                             allmodconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
powerpc                  mpc866_ads_defconfig
powerpc                       ebony_defconfig
sparc64                             defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
arm                          pxa910_defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
h8300                     edosk2674_defconfig
sh                   sh7724_generic_defconfig
m68k                           sun3_defconfig
microblaze                          defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
sh                           se7722_defconfig
parisc                generic-64bit_defconfig
m68k                        mvme147_defconfig
h8300                    h8300h-sim_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
m68k                          hp300_defconfig
m68k                        mvme16x_defconfig
powerpc                     tqm8560_defconfig
x86_64                           alldefconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
riscv                    nommu_virt_defconfig
powerpc                        cell_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
powerpc                 xes_mpc85xx_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
arm                       imx_v6_v7_defconfig
m68k                       m5275evb_defconfig
arm                       versatile_defconfig
powerpc                  mpc885_ads_defconfig
arm                       aspeed_g4_defconfig
arm                       cns3420vb_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arc                              allyesconfig
mips                        qi_lb60_defconfig
arm                         palmz72_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
sparc                       sparc64_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
powerpc                     tqm5200_defconfig
arm                  colibri_pxa270_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
powerpc                      ppc40x_defconfig
sh                        dreamcast_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
arm                        clps711x_defconfig
powerpc                 mpc837x_mds_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
mips                        workpad_defconfig
xtensa                       common_defconfig
powerpc                       maple_defconfig
arm                             pxa_defconfig
mips                            e55_defconfig
openrisc                 simple_smp_defconfig
mips                        nlm_xlp_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
sh                            shmin_defconfig
sh                         ap325rxa_defconfig
mips                        maltaup_defconfig
powerpc                     mpc5200_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
sh                         apsh4a3a_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
sh                        edosk7760_defconfig
mips                      maltaaprp_defconfig
powerpc                      bamboo_defconfig
s390                       zfcpdump_defconfig
arm                      tct_hammer_defconfig
powerpc                      ppc6xx_defconfig
powerpc                         wii_defconfig
nios2                            alldefconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
powerpc                 mpc8272_ads_defconfig
powerpc                       eiger_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
powerpc                     pq2fads_defconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
powerpc                         ps3_defconfig
powerpc                      chrp32_defconfig
arm                       mainstone_defconfig
arm                           omap1_defconfig
arc                      axs103_smp_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
um                               allmodconfig
sparc64                          alldefconfig
mips                malta_kvm_guest_defconfig
ia64                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:36 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:36 +0800
Subject: [soc:socfpga/defconfig] BUILD SUCCESS
 40f90f4763e26cc4eb04b37766b7fd3f5952b516
Message-ID: <6066f15c.C/45D8AI+a8cOP5V%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git socfpga/defconfig
branch HEAD: 40f90f4763e26cc4eb04b37766b7fd3f5952b516  arm64: defconfig: enable Intel's eASIC N5X SoCFPGA and Keem Bay SoC

elapsed time: 13911m

configs tested: 614
configs skipped: 135

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
powerpc                     akebono_defconfig
sh                          rsk7203_defconfig
sh                             shx3_defconfig
arm                         orion5x_defconfig
mips                           ip28_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
powerpc                   currituck_defconfig
h8300                            alldefconfig
powerpc                     ksi8560_defconfig
sh                ecovec24-romimage_defconfig
arc                    vdk_hs38_smp_defconfig
m68k                         amcore_defconfig
m68k                           sun3_defconfig
powerpc                      pmac32_defconfig
sh                        sh7763rdp_defconfig
arm                         lpc32xx_defconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                       maple_defconfig
powerpc                      obs600_defconfig
sparc64                             defconfig
arm                         assabet_defconfig
sh                         ecovec24_defconfig
m68k                          atari_defconfig
sh                           se7712_defconfig
arc                        nsim_700_defconfig
arc                           tb10x_defconfig
arm                        keystone_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
xtensa                          iss_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                          hp300_defconfig
nios2                            alldefconfig
sh                          polaris_defconfig
arm                             ezx_defconfig
sh                           sh2007_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
arc                                 defconfig
sh                        edosk7760_defconfig
riscv             nommu_k210_sdcard_defconfig
riscv                               defconfig
sh                           se7780_defconfig
m68k                        m5407c3_defconfig
mips                         tb0226_defconfig
arm                              alldefconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
sh                   secureedge5410_defconfig
arm                        cerfcube_defconfig
powerpc                    sam440ep_defconfig
sh                           se7750_defconfig
arm                        clps711x_defconfig
mips                        nlm_xlr_defconfig
arm                       spear13xx_defconfig
arm                       aspeed_g4_defconfig
arm                             pxa_defconfig
sparc                       sparc32_defconfig
ia64                             alldefconfig
powerpc                        icon_defconfig
arc                        nsimosci_defconfig
arm                    vt8500_v6_v7_defconfig
arm                         cm_x300_defconfig
riscv                            alldefconfig
arm                            hisi_defconfig
microblaze                      mmu_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
sh                              ul2_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
sh                            titan_defconfig
arm                        trizeps4_defconfig
powerpc                     redwood_defconfig
mips                            ar7_defconfig
m68k                            mac_defconfig
arm                          imote2_defconfig
arm                      tct_hammer_defconfig
arm                             mxs_defconfig
mips                 decstation_r4k_defconfig
powerpc                    adder875_defconfig
sh                             sh03_defconfig
sh                           se7343_defconfig
arm                          pxa3xx_defconfig
sh                          rsk7264_defconfig
csky                                defconfig
sh                     sh7710voipgw_defconfig
m68k                        stmark2_defconfig
arm                         hackkit_defconfig
arm                         lpc18xx_defconfig
sh                          kfr2r09_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
mips                     cu1000-neo_defconfig
mips                      bmips_stb_defconfig
arm                   milbeaut_m10v_defconfig
arm                         mv78xx0_defconfig
arm                        spear3xx_defconfig
arc                        vdk_hs38_defconfig
um                           x86_64_defconfig
mips                          rb532_defconfig
arm                          moxart_defconfig
openrisc                            defconfig
sh                         microdev_defconfig
powerpc                          allmodconfig
arm                          ixp4xx_defconfig
powerpc                     ep8248e_defconfig
arm                        multi_v7_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                          lpd270_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                   bluestone_defconfig
powerpc                      ppc64e_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                        mvebu_v5_defconfig
xtensa                           alldefconfig
s390                          debug_defconfig
arc                      axs103_smp_defconfig
powerpc                 mpc836x_rdk_defconfig
arc                         haps_hs_defconfig
um                             i386_defconfig
arm                          badge4_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
openrisc                  or1klitex_defconfig
powerpc                 linkstation_defconfig
alpha                            alldefconfig
mips                      pic32mzda_defconfig
ia64                          tiger_defconfig
parisc                generic-32bit_defconfig
mips                         tb0219_defconfig
powerpc                     tqm8560_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                         wii_defconfig
mips                      pistachio_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
mips                        workpad_defconfig
sparc                            alldefconfig
m68k                        m5272c3_defconfig
mips                            e55_defconfig
um                                allnoconfig
powerpc64                           defconfig
mips                        maltaup_defconfig
arm                        mvebu_v7_defconfig
arm                            pleb_defconfig
m68k                        mvme147_defconfig
microblaze                          defconfig
sh                 kfr2r09-romimage_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
mips                         db1xxx_defconfig
arm                        neponset_defconfig
arm                            mps2_defconfig
powerpc                         ps3_defconfig
parisc                generic-64bit_defconfig
mips                        qi_lb60_defconfig
sh                   sh7770_generic_defconfig
mips                        vocore2_defconfig
sh                         ap325rxa_defconfig
xtensa                    smp_lx200_defconfig
arm                        multi_v5_defconfig
um                               allmodconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
sh                        dreamcast_defconfig
powerpc                     tqm8540_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
parisc                           alldefconfig
arm                        shmobile_defconfig
powerpc                          g5_defconfig
ia64                            zx1_defconfig
powerpc                  mpc866_ads_defconfig
powerpc                       ebony_defconfig
arm                         lubbock_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
sh                          rsk7201_defconfig
mips                  cavium_octeon_defconfig
arm                           spitz_defconfig
mips                      maltaaprp_defconfig
arc                          axs101_defconfig
m68k                       m5249evb_defconfig
arm                        mini2440_defconfig
ia64                             allyesconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
powerpc                 mpc8540_ads_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
mips                        bcm63xx_defconfig
mips                           ip27_defconfig
ia64                      gensparse_defconfig
arm                      jornada720_defconfig
mips                     loongson1c_defconfig
powerpc                      katmai_defconfig
arm                       imx_v6_v7_defconfig
arm                       aspeed_g5_defconfig
powerpc                 mpc834x_itx_defconfig
arm                     am200epdkit_defconfig
arm                          pxa910_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
arm                          pxa168_defconfig
arm                           sunxi_defconfig
powerpc                          allyesconfig
sh                           se7722_defconfig
xtensa                generic_kc705_defconfig
h8300                    h8300h-sim_defconfig
powerpc                      chrp32_defconfig
sh                                  defconfig
arm                            qcom_defconfig
arm                           sama5_defconfig
mips                          ath25_defconfig
xtensa                         virt_defconfig
m68k                        mvme16x_defconfig
h8300                       h8s-sim_defconfig
arm                       versatile_defconfig
sh                        sh7785lcr_defconfig
powerpc                   motionpro_defconfig
mips                     decstation_defconfig
sh                             espt_defconfig
m68k                                defconfig
arm                       multi_v4t_defconfig
arc                              alldefconfig
powerpc                  iss476-smp_defconfig
x86_64                           alldefconfig
powerpc                      cm5200_defconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      tqm8xx_defconfig
m68k                       bvme6000_defconfig
xtensa                  cadence_csp_defconfig
arm                          gemini_defconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                        fsp2_defconfig
m68k                       m5275evb_defconfig
mips                          malta_defconfig
arm                       netwinder_defconfig
sh                          sdk7780_defconfig
mips                         mpc30x_defconfig
powerpc                      arches_defconfig
powerpc                       eiger_defconfig
powerpc                  mpc885_ads_defconfig
arm                       cns3420vb_defconfig
sh                               j2_defconfig
powerpc                     asp8347_defconfig
mips                  decstation_64_defconfig
arm                         socfpga_defconfig
arm                  colibri_pxa300_defconfig
mips                             allmodconfig
h8300                     edosk2674_defconfig
arc                              allyesconfig
arm                         palmz72_defconfig
mips                      loongson3_defconfig
nds32                             allnoconfig
m68k                            q40_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
arc                          axs103_defconfig
powerpc                     tqm5200_defconfig
csky                             alldefconfig
sparc                       sparc64_defconfig
m68k                             alldefconfig
riscv                    nommu_virt_defconfig
alpha                               defconfig
nds32                            alldefconfig
mips                        omega2p_defconfig
sh                     magicpanelr2_defconfig
mips                    maltaup_xpa_defconfig
powerpc                     tqm8541_defconfig
i386                             alldefconfig
arm                        vexpress_defconfig
mips                           xway_defconfig
arm                      pxa255-idp_defconfig
powerpc                 canyonlands_defconfig
powerpc                    ge_imp3a_defconfig
mips                          rm200_defconfig
arm                           u8500_defconfig
arm                     eseries_pxa_defconfig
mips                      malta_kvm_defconfig
arm                           stm32_defconfig
sh                           se7705_defconfig
powerpc                    klondike_defconfig
arm                  colibri_pxa270_defconfig
sh                        edosk7705_defconfig
sh                           se7724_defconfig
powerpc                      ppc40x_defconfig
sh                          sdk7786_defconfig
sh                           se7721_defconfig
powerpc                     stx_gp3_defconfig
mips                malta_qemu_32r6_defconfig
nds32                               defconfig
xtensa                       common_defconfig
arm                            xcep_defconfig
ia64                             allmodconfig
mips                        nlm_xlp_defconfig
sh                          landisk_defconfig
arm                      integrator_defconfig
mips                             allyesconfig
mips                  maltasmvp_eva_defconfig
powerpc                 mpc8313_rdb_defconfig
powerpc                 mpc8560_ads_defconfig
sh                          r7785rp_defconfig
powerpc                     pq2fads_defconfig
mips                        bcm47xx_defconfig
arm                         axm55xx_defconfig
ia64                        generic_defconfig
powerpc                      ppc6xx_defconfig
alpha                            allyesconfig
mips                            gpr_defconfig
sh                         apsh4a3a_defconfig
powerpc                     sbc8548_defconfig
powerpc                     pseries_defconfig
powerpc                     powernv_defconfig
um                               allyesconfig
powerpc                     taishan_defconfig
sh                           se7206_defconfig
powerpc                 mpc8315_rdb_defconfig
s390                       zfcpdump_defconfig
sh                           se7751_defconfig
mips                           ci20_defconfig
powerpc                 mpc8272_ads_defconfig
arm                           corgi_defconfig
powerpc                     tqm8555_defconfig
sh                      rts7751r2d1_defconfig
powerpc                    mvme5100_defconfig
arm                           viper_defconfig
mips                           ip32_defconfig
arm                       mainstone_defconfig
arm                           omap1_defconfig
mips                         rt305x_defconfig
sparc64                          alldefconfig
sh                            migor_defconfig
powerpc64                        alldefconfig
mips                malta_kvm_guest_defconfig
arm                            zeus_defconfig
powerpc                      walnut_defconfig
m68k                          multi_defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
x86_64               randconfig-a002-20210325
x86_64               randconfig-a003-20210325
x86_64               randconfig-a006-20210325
x86_64               randconfig-a001-20210325
x86_64               randconfig-a005-20210325
x86_64               randconfig-a004-20210325
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a003-20210325
i386                 randconfig-a004-20210325
i386                 randconfig-a001-20210325
i386                 randconfig-a002-20210325
i386                 randconfig-a006-20210325
i386                 randconfig-a005-20210325
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a003-20210323
i386                 randconfig-a004-20210323
i386                 randconfig-a001-20210323
i386                 randconfig-a002-20210323
i386                 randconfig-a006-20210323
i386                 randconfig-a005-20210323
i386                 randconfig-a004-20210324
i386                 randconfig-a003-20210324
i386                 randconfig-a001-20210324
i386                 randconfig-a002-20210324
i386                 randconfig-a006-20210324
i386                 randconfig-a005-20210324
i386                 randconfig-a004-20210326
i386                 randconfig-a003-20210326
i386                 randconfig-a001-20210326
i386                 randconfig-a002-20210326
i386                 randconfig-a006-20210326
i386                 randconfig-a005-20210326
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
x86_64               randconfig-a012-20210326
x86_64               randconfig-a015-20210326
x86_64               randconfig-a014-20210326
x86_64               randconfig-a013-20210326
x86_64               randconfig-a016-20210326
x86_64               randconfig-a011-20210326
x86_64               randconfig-a012-20210324
x86_64               randconfig-a015-20210324
x86_64               randconfig-a014-20210324
x86_64               randconfig-a013-20210324
x86_64               randconfig-a016-20210324
x86_64               randconfig-a011-20210324
x86_64               randconfig-a002-20210323
x86_64               randconfig-a003-20210323
x86_64               randconfig-a006-20210323
x86_64               randconfig-a001-20210323
x86_64               randconfig-a004-20210323
x86_64               randconfig-a005-20210323
i386                 randconfig-a014-20210325
i386                 randconfig-a011-20210325
i386                 randconfig-a015-20210325
i386                 randconfig-a016-20210325
i386                 randconfig-a013-20210325
i386                 randconfig-a012-20210325
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a011-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
i386                 randconfig-a014-20210324
i386                 randconfig-a011-20210324
i386                 randconfig-a015-20210324
i386                 randconfig-a016-20210324
i386                 randconfig-a013-20210324
i386                 randconfig-a012-20210324
i386                 randconfig-a014-20210326
i386                 randconfig-a011-20210326
i386                 randconfig-a015-20210326
i386                 randconfig-a016-20210326
i386                 randconfig-a012-20210326
i386                 randconfig-a013-20210326
i386                 randconfig-a014-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210323
i386                 randconfig-a011-20210323
i386                 randconfig-a015-20210323
i386                 randconfig-a016-20210323
i386                 randconfig-a012-20210323
i386                 randconfig-a013-20210323
i386                 randconfig-a015-20210331
i386                 randconfig-a011-20210331
i386                 randconfig-a014-20210331
i386                 randconfig-a013-20210331
i386                 randconfig-a016-20210331
i386                 randconfig-a012-20210331
x86_64               randconfig-a002-20210327
x86_64               randconfig-a003-20210327
x86_64               randconfig-a006-20210327
x86_64               randconfig-a001-20210327
x86_64               randconfig-a004-20210327
x86_64               randconfig-a005-20210327
riscv                             allnoconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210324
x86_64               randconfig-a003-20210324
x86_64               randconfig-a001-20210324
x86_64               randconfig-a006-20210324
x86_64               randconfig-a005-20210324
x86_64               randconfig-a004-20210324
x86_64               randconfig-a002-20210326
x86_64               randconfig-a003-20210326
x86_64               randconfig-a001-20210326
x86_64               randconfig-a006-20210326
x86_64               randconfig-a004-20210326
x86_64               randconfig-a005-20210326
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210325
x86_64               randconfig-a015-20210325
x86_64               randconfig-a014-20210325
x86_64               randconfig-a013-20210325
x86_64               randconfig-a011-20210325
x86_64               randconfig-a016-20210325
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a012-20210323
x86_64               randconfig-a015-20210323
x86_64               randconfig-a013-20210323
x86_64               randconfig-a014-20210323
x86_64               randconfig-a011-20210323
x86_64               randconfig-a016-20210323
x86_64               randconfig-a012-20210327
x86_64               randconfig-a015-20210327
x86_64               randconfig-a014-20210327
x86_64               randconfig-a013-20210327
x86_64               randconfig-a011-20210327
x86_64               randconfig-a016-20210327
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:46 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:46 +0800
Subject: [soc:at91/defconfig] BUILD SUCCESS
 4136c4443efce6f028eca74885870ac649981da1
Message-ID: <6066f166.k8JJwJVE3xdfc8bW%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git at91/defconfig
branch HEAD: 4136c4443efce6f028eca74885870ac649981da1  ARM: configs: at91: Modernize UBI defconfig part

elapsed time: 5670m

configs tested: 375
configs skipped: 123

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
xtensa                              defconfig
powerpc                 mpc837x_rdb_defconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                      pcm030_defconfig
powerpc                    socrates_defconfig
mips                       lemote2f_defconfig
powerpc                      ppc44x_defconfig
arm                         s3c6400_defconfig
ia64                                defconfig
powerpc                     sequoia_defconfig
arm                         lpc32xx_defconfig
arm                           tegra_defconfig
sh                          lboxre2_defconfig
xtensa                generic_kc705_defconfig
sh                            titan_defconfig
arm                      footbridge_defconfig
arm                             ezx_defconfig
arm                        trizeps4_defconfig
powerpc               mpc834x_itxgp_defconfig
arc                            hsdk_defconfig
sh                            hp6xx_defconfig
powerpc                      makalu_defconfig
mips                        workpad_defconfig
sh                          sdk7780_defconfig
arm                           sama5_defconfig
arm                          pxa910_defconfig
mips                           gcw0_defconfig
powerpc                        warp_defconfig
powerpc                     kmeter1_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
m68k                       m5208evb_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         vf610m4_defconfig
arm                        cerfcube_defconfig
arm                          lpd270_defconfig
m68k                        stmark2_defconfig
riscv                    nommu_k210_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                      pasemi_defconfig
xtensa                  audio_kc705_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                           allnoconfig
powerpc                       ppc64_defconfig
sh                           sh2007_defconfig
arc                        nsimosci_defconfig
arm                          iop32x_defconfig
um                            kunit_defconfig
sh                        sh7757lcr_defconfig
powerpc                    sam440ep_defconfig
powerpc                  storcenter_defconfig
parisc                           allyesconfig
arm                          simpad_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
sh                          polaris_defconfig
sh                 kfr2r09-romimage_defconfig
mips                        maltaup_defconfig
arc                     nsimosci_hs_defconfig
mips                   sb1250_swarm_defconfig
powerpc                         ps3_defconfig
ia64                             allmodconfig
mips                          ath25_defconfig
m68k                        m5272c3_defconfig
mips                         db1xxx_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
m68k                             allmodconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                      ppc40x_defconfig
sh                   rts7751r2dplus_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arc                        vdk_hs38_defconfig
mips                       capcella_defconfig
arm                         lubbock_defconfig
arm                         orion5x_defconfig
arm                     eseries_pxa_defconfig
powerpc                      arches_defconfig
sparc64                             defconfig
powerpc                     kilauea_defconfig
nios2                               defconfig
mips                        jmr3927_defconfig
powerpc                      ppc64e_defconfig
sh                          rsk7201_defconfig
arm                         shannon_defconfig
powerpc                    amigaone_defconfig
arm                          badge4_defconfig
openrisc                    or1ksim_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                               defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
powerpc                 mpc834x_itx_defconfig
mips                         tb0219_defconfig
mips                            ar7_defconfig
arm                     am200epdkit_defconfig
arm                          collie_defconfig
sh                          urquell_defconfig
arm                            mmp2_defconfig
powerpc                      bamboo_defconfig
i386                                defconfig
powerpc                 mpc837x_mds_defconfig
arm                             pxa_defconfig
nios2                         10m50_defconfig
ia64                             alldefconfig
sh                           se7722_defconfig
parisc                generic-64bit_defconfig
m68k                        mvme147_defconfig
h8300                    h8300h-sim_defconfig
powerpc                      chrp32_defconfig
sh                                  defconfig
arm                            qcom_defconfig
arc                        nsim_700_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
arm                        mini2440_defconfig
m68k                          hp300_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
m68k                           sun3_defconfig
powerpc                   motionpro_defconfig
arm                          gemini_defconfig
nios2                            allyesconfig
powerpc                     ppa8548_defconfig
mips                         cobalt_defconfig
powerpc                     tqm8541_defconfig
powerpc                 xes_mpc85xx_defconfig
arc                              alldefconfig
ia64                      gensparse_defconfig
powerpc                        fsp2_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                      tct_hammer_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc64                        alldefconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                          exynos_defconfig
powerpc                     akebono_defconfig
arm                         socfpga_defconfig
m68k                          atari_defconfig
arm                  colibri_pxa300_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
arm                        multi_v7_defconfig
h8300                       h8s-sim_defconfig
um                                allnoconfig
mips                      loongson3_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                          allmodconfig
sh                           se7724_defconfig
m68k                        m5407c3_defconfig
sh                        dreamcast_defconfig
mips                      fuloong2e_defconfig
arm                       netwinder_defconfig
mips                        qi_lb60_defconfig
arm                        clps711x_defconfig
arm                  colibri_pxa270_defconfig
mips                malta_qemu_32r6_defconfig
arm                        keystone_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
xtensa                       common_defconfig
powerpc                       maple_defconfig
mips                            e55_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                     mpc5200_defconfig
powerpc                  mpc885_ads_defconfig
mips                     loongson1b_defconfig
mips                     decstation_defconfig
arm                         assabet_defconfig
powerpc                     sbc8548_defconfig
mips                  decstation_64_defconfig
sh                               alldefconfig
arm                         cm_x300_defconfig
powerpc                       eiger_defconfig
arm                          ixp4xx_defconfig
s390                       zfcpdump_defconfig
x86_64                           alldefconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
csky                             alldefconfig
mips                        nlm_xlp_defconfig
nios2                            alldefconfig
arm                           u8500_defconfig
arm                         s5pv210_defconfig
riscv                    nommu_virt_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        multi_v5_defconfig
arm                           corgi_defconfig
ia64                             allyesconfig
arm                            mps2_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
arm                       mainstone_defconfig
mips                         rt305x_defconfig
mips                          rm200_defconfig
sparc64                          alldefconfig
sh                            migor_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
arc                      axs103_smp_defconfig
powerpc                      ppc6xx_defconfig
arm                           spitz_defconfig
arm                      jornada720_defconfig
mips                      pic32mzda_defconfig
m68k                       m5275evb_defconfig
s390                          debug_defconfig
m68k                       m5249evb_defconfig
arm                       versatile_defconfig
mips                           xway_defconfig
um                               allmodconfig
arm                         palmz72_defconfig
sparc                       sparc64_defconfig
openrisc                 simple_smp_defconfig
mips                malta_kvm_guest_defconfig
powerpc                       ebony_defconfig
m68k                                defconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
powerpc                          allyesconfig
x86_64               randconfig-a002-20210329
x86_64               randconfig-a003-20210329
x86_64               randconfig-a006-20210329
x86_64               randconfig-a001-20210329
x86_64               randconfig-a005-20210329
x86_64               randconfig-a004-20210329
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a003-20210329
i386                 randconfig-a004-20210329
i386                 randconfig-a001-20210329
i386                 randconfig-a002-20210329
i386                 randconfig-a006-20210329
i386                 randconfig-a005-20210329
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210329
i386                 randconfig-a011-20210329
i386                 randconfig-a015-20210329
i386                 randconfig-a016-20210329
i386                 randconfig-a013-20210329
i386                 randconfig-a012-20210329
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a015-20210329
x86_64               randconfig-a012-20210329
x86_64               randconfig-a013-20210329
x86_64               randconfig-a014-20210329
x86_64               randconfig-a011-20210329
x86_64               randconfig-a016-20210329
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  2 11:26:49 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 02 Apr 2021 18:26:49 +0800
Subject: [soc:arm/soc] BUILD SUCCESS 6f35f62958ea395fa8cbd2a28f713ccac8d9b5bd
Message-ID: <6066f169.R0GUOUk8R+eJAGOD%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/soc
branch HEAD: 6f35f62958ea395fa8cbd2a28f713ccac8d9b5bd  Merge tag 'at91-soc-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/soc

elapsed time: 726m

configs tested: 182
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
s390                             allmodconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
mips                         tb0226_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
m68k                             allmodconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
arm                        oxnas_v6_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                        mvme16x_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
arm                            pleb_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
ia64                      gensparse_defconfig
arm                       spear13xx_defconfig
arm                        trizeps4_defconfig
h8300                       h8s-sim_defconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arc                     nsimosci_hs_defconfig
um                                allnoconfig
arm                     eseries_pxa_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
mips                        qi_lb60_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
s390                                defconfig
powerpc                 mpc8315_rdb_defconfig
sh                        edosk7760_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
arm                          ixp4xx_defconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
riscv                    nommu_k210_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
um                               allmodconfig
arm                         palmz72_defconfig
sh                           sh2007_defconfig
arm                      jornada720_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From geert+renesas at glider.be  Fri Apr  2 11:37:15 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri,  2 Apr 2021 12:37:15 +0200
Subject: [GIT PULL] Renesas ARM DT updates for v5.13 (take two)
Message-ID: <cover.1617359678.git.geert+renesas@glider.be>

	Hi arm-soc folks,

The following changes since commit c8aebc1346522d3569690867ce3996642ad52e01:

  arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding (2021-03-16 09:58:00 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-dt-for-v5.13-tag2

for you to fetch changes up to 2b35ca2fe605f85aa1a52c713571baf04a5f434a:

  arm64: dts: renesas: ulcb: Add cpu-supply property to a57_0 node (2021-04-02 09:22:35 +0200)

----------------------------------------------------------------
Renesas ARM DT updates for v5.13 (take two)

  - Video IN (VIN) and Camera (CSI-2) support for the R-Car M3-W+ SoC,
  - LED support for the Falcon development board,
  - Preparatory display pipeline support for the R-Car V3U SoC,
  - Miscellaneous fixes and improvements.

Thanks for pulling!

----------------------------------------------------------------
Dien Pham (1):
      arm64: dts: renesas: salvator-common: Add cpu-supply property to a57_0 node

Geert Uytterhoeven (5):
      arm64: dts: renesas: falcon: Move console config to CPU board DTS
      arm64: dts: renesas: falcon: Move watchdog config to CPU board DTS
      arm64: dts: renesas: falcon: Move AVB0 to main DTS
      ARM: dts: koelsch: Configure pull-up for SOFT_SW GPIO keys
      arm64: dts: renesas: r8a77950: Drop operating points above 1.5 GHz

Kieran Bingham (3):
      arm64: dts: renesas: falcon-cpu: Add GP LEDs
      arm64: dts: renesas: r8a779a0: Add FCPVD support
      arm64: dts: renesas: r8a779a0: Add VSPD support

Niklas S?derlund (1):
      arm64: dts: renesas: r8a77961: Add VIN and CSI-2 device nodes

Yoshihiro Shimoda (1):
      arm64: dts: renesas: r8a779a0: Fix PMU interrupt

Yusuke Goda (1):
      arm64: dts: renesas: ulcb: Add cpu-supply property to a57_0 node

 arch/arm/boot/dts/r8a7791-koelsch.dts              |   8 +
 arch/arm64/boot/dts/renesas/r8a77950.dtsi          |   5 +
 arch/arm64/boot/dts/renesas/r8a77961.dtsi          | 314 ++++++++++++++++++++-
 .../boot/dts/renesas/r8a779a0-falcon-cpu.dtsi      |  72 ++---
 arch/arm64/boot/dts/renesas/r8a779a0-falcon.dts    |  39 ++-
 arch/arm64/boot/dts/renesas/r8a779a0.dtsi          |  43 ++-
 arch/arm64/boot/dts/renesas/salvator-common.dtsi   |   4 +
 arch/arm64/boot/dts/renesas/ulcb.dtsi              |   4 +
 8 files changed, 435 insertions(+), 54 deletions(-)

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 microchip.com  Fri Apr  2 11:50:18 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 2 Apr 2021 13:50:18 +0300
Subject: [PATCH v2 1/1] power: reset: at91-reset: use devm_of_iomap
Message-ID: <20210402105018.2212-1-claudiu.beznea@microchip.com>

Use devm_of_iomap() to map resources. This will avoid the necessity to
track the mapped resources and free them on failure path or on remove.

Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
Suggested-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---

Changes in v2:
- use devm_of_iomap()
- change commit description and title to match to the new approach
- add Suggested-by tag

 drivers/power/reset/at91-reset.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index 3ff9d93a5226..026649409135 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
@@ -192,7 +192,7 @@ static int __init at91_reset_probe(struct platform_device *pdev)
 	if (!reset)
 		return -ENOMEM;
 
-	reset->rstc_base = of_iomap(pdev->dev.of_node, 0);
+	reset->rstc_base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
 	if (!reset->rstc_base) {
 		dev_err(&pdev->dev, "Could not map reset controller address\n");
 		return -ENODEV;
@@ -202,7 +202,7 @@ static int __init at91_reset_probe(struct platform_device *pdev)
 		/* we need to shutdown the ddr controller, so get ramc base */
 		for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
 			reset->ramc_lpr = (u32)match->data;
-			reset->ramc_base[idx] = of_iomap(np, 0);
+			reset->ramc_base[idx] = devm_of_iomap(&pdev->dev, np, 0, NULL);
 			if (!reset->ramc_base[idx]) {
 				dev_err(&pdev->dev, "Could not map ram controller address\n");
 				of_node_put(np);
-- 
2.25.1



From pbonzini at redhat.com  Fri Apr  2 12:08:57 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 13:08:57 +0200
Subject: [PATCH v2 01/10] KVM: Assert that notifier count is elevated in
 .change_pte()
In-Reply-To: <20210402005658.3024832-2-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-2-seanjc@google.com>
Message-ID: <3fb5283e-21f0-8eb2-03ab-96113ca1f463@redhat.com>

On 02/04/21 02:56, Sean Christopherson wrote:
> In KVM's .change_pte() notification callback, replace the notifier
> sequence bump with a WARN_ON assertion that the notifier count is
> elevated.  An elevated count provides stricter protections than bumping
> the sequence, and the sequence is guarnateed to be bumped before the
> count hits zero.
> 
> When .change_pte() was added by commit 828502d30073 ("ksm: add
> mmu_notifier set_pte_at_notify()"), bumping the sequence was necessary
> as .change_pte() would be invoked without any surrounding notifications.
> 
> However, since commit 6bdb913f0a70 ("mm: wrap calls to set_pte_at_notify
> with invalidate_range_start and invalidate_range_end"), all calls to
> .change_pte() are guaranteed to be bookended by start() and end(), and
> so are guaranteed to run with an elevated notifier count.
> 
> Note, wrapping .change_pte() with .invalidate_range_{start,end}() is a
> bug of sorts, as invalidating the secondary MMU's (KVM's) PTE defeats
> the purpose of .change_pte().  Every arch's kvm_set_spte_hva() assumes
> .change_pte() is called when the relevant SPTE is present in KVM's MMU,
> as the original goal was to accelerate Kernel Samepage Merging (KSM) by
> updating KVM's SPTEs without requiring a VM-Exit (due to invalidating
> the SPTE).  I.e. it means that .change_pte() is effectively dead code
> on _all_ architectures.
> 
> x86 and MIPS are clearcut nops if the old SPTE is not-present, and that
> is guaranteed due to the prior invalidation.  PPC simply unmaps the SPTE,
> which again should be a nop due to the invalidation.  arm64 is a bit
> murky, but it's also likely a nop because kvm_pgtable_stage2_map() is
> called without a cache pointer, which means it will map an entry if and
> only if an existing PTE was found.
> 
> For now, take advantage of the bug to simplify future consolidation of
> KVMs's MMU notifier code.   Doing so will not greatly complicate fixing
> .change_pte(), assuming it's even worth fixing.  .change_pte() has been
> broken for 8+ years and no one has complained.  Even if there are
> KSM+KVM users that care deeply about its performance, the benefits of
> avoiding VM-Exits via .change_pte() need to be reevaluated to justify
> the added complexity and testing burden.  Ripping out .change_pte()
> entirely would be a lot easier.
> 
> Signed-off-by: Sean Christopherson <seanjc at google.com>
> ---
>   virt/kvm/kvm_main.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index d1de843b7618..8df091950161 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -461,12 +461,17 @@ static void kvm_mmu_notifier_change_pte(struct mmu_notifier *mn,
>   
>   	trace_kvm_set_spte_hva(address);
>   
> +	/*
> +	 * .change_pte() must be bookended by .invalidate_range_{start,end}(),

Changed to "surrounded" for the benefit of non-native speakers. :)

Paolo

> +	 * and so always runs with an elevated notifier count.  This obviates
> +	 * the need to bump the sequence count.
> +	 */
> +	WARN_ON_ONCE(!kvm->mmu_notifier_count);
> +
>   	idx = srcu_read_lock(&kvm->srcu);
>   
>   	KVM_MMU_LOCK(kvm);
>   
> -	kvm->mmu_notifier_seq++;
> -
>   	if (kvm_set_spte_hva(kvm, address, pte))
>   		kvm_flush_remote_tlbs(kvm);
>   
> 



From maz at kernel.org  Fri Apr  2 12:11:24 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 02 Apr 2021 12:11:24 +0100
Subject: [PATCH 5/6] PCI: keystone: Add PCI legacy interrupt support for
 AM654
In-Reply-To: <20210325090026.8843-6-kishon@ti.com>
References: <20210325090026.8843-1-kishon@ti.com>
 <20210325090026.8843-6-kishon@ti.com>
Message-ID: <87blaxeyar.wl-maz@kernel.org>

On Thu, 25 Mar 2021 09:00:25 +0000,
Kishon Vijay Abraham I <kishon at ti.com> wrote:
> 
> Add PCI legacy interrupt support for AM654. AM654 has a single HW
> interrupt line for all the four legacy interrupts INTA/INTB/INTC/INTD.
> The HW interrupt line connected to GIC is a pulse interrupt whereas
> the legacy interrupts by definition is level interrupt. In order to
> provide level interrupt functionality to edge interrupt line, PCIe
> in AM654 has provided IRQ_EOI register. When the SW writes to IRQ_EOI
> register after handling the interrupt, the IP checks the state of
> legacy interrupt and re-triggers pulse interrupt invoking the handler
> again.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  drivers/pci/controller/dwc/pci-keystone.c | 87 +++++++++++++++++++++--
>  1 file changed, 82 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index dfa9a7fcf9b7..84a25207d0d3 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -118,6 +118,7 @@ struct keystone_pcie {
>  	/* PCI Device ID */
>  	u32			device_id;
>  	struct			device_node *legacy_intc_np;
> +	struct irq_domain	*legacy_irq_domain;
>  
>  	int			msi_host_irq;
>  	int			num_lanes;
> @@ -289,6 +290,29 @@ static irqreturn_t ks_pcie_handle_error_irq(struct keystone_pcie *ks_pcie)
>  	return IRQ_HANDLED;
>  }
>  
> +static void ks_pcie_am654_legacy_irq_handler(struct irq_desc *desc)
> +{
> +	struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
> +	struct irq_chip *chip = irq_desc_get_chip(desc);
> +	int virq, i;
> +	u32 reg;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	for (i = 0; i < PCI_NUM_INTX; i++) {
> +		reg = ks_pcie_app_readl(ks_pcie, IRQ_STATUS(i));
> +		if (!(reg & INTx_EN))
> +			continue;
> +
> +		virq = irq_linear_revmap(ks_pcie->legacy_irq_domain, i);
> +		generic_handle_irq(virq);

I'm on my way to kill irq_linear_revmap(), so I'd rather you didn't
add more instances. Consider using irq_find_mapping() instead.

> +		ks_pcie_app_writel(ks_pcie, IRQ_STATUS(i), INTx_EN);
> +		ks_pcie_app_writel(ks_pcie, IRQ_EOI, i);

What are these writes for? The first one feels like an Ack, and the
second one has EOI written over it.

If that's what they are, llease move these to a proper irq_chip
structure and use the appropriate flow handler, instead of
dummy_irq_chip and handle_simple_irq.

Thanks,

	M.

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


From sebastian.reichel at collabora.com  Fri Apr  2 12:13:08 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Fri, 2 Apr 2021 13:13:08 +0200
Subject: [PATCH v2 1/1] power: reset: at91-reset: use devm_of_iomap
In-Reply-To: <20210402105018.2212-1-claudiu.beznea@microchip.com>
References: <20210402105018.2212-1-claudiu.beznea@microchip.com>
Message-ID: <20210402111308.jx7mrfb52wbcuwjg@earth.universe>

Hi,

On Fri, Apr 02, 2021 at 01:50:18PM +0300, Claudiu Beznea wrote:
> Use devm_of_iomap() to map resources. This will avoid the necessity to
> track the mapped resources and free them on failure path or on remove.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> Suggested-by: Nicolas Ferre <nicolas.ferre at microchip.com>
> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> ---

Thanks, queued.

-- Sebastian

> Changes in v2:
> - use devm_of_iomap()
> - change commit description and title to match to the new approach
> - add Suggested-by tag
> 
>  drivers/power/reset/at91-reset.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
> index 3ff9d93a5226..026649409135 100644
> --- a/drivers/power/reset/at91-reset.c
> +++ b/drivers/power/reset/at91-reset.c
> @@ -192,7 +192,7 @@ static int __init at91_reset_probe(struct platform_device *pdev)
>  	if (!reset)
>  		return -ENOMEM;
>  
> -	reset->rstc_base = of_iomap(pdev->dev.of_node, 0);
> +	reset->rstc_base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
>  	if (!reset->rstc_base) {
>  		dev_err(&pdev->dev, "Could not map reset controller address\n");
>  		return -ENODEV;
> @@ -202,7 +202,7 @@ static int __init at91_reset_probe(struct platform_device *pdev)
>  		/* we need to shutdown the ddr controller, so get ramc base */
>  		for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
>  			reset->ramc_lpr = (u32)match->data;
> -			reset->ramc_base[idx] = of_iomap(np, 0);
> +			reset->ramc_base[idx] = devm_of_iomap(&pdev->dev, np, 0, NULL);
>  			if (!reset->ramc_base[idx]) {
>  				dev_err(&pdev->dev, "Could not map ram controller address\n");
>  				of_node_put(np);
> -- 
> 2.25.1
> 
-------------- 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/20210402/dd69aeab/attachment.sig>

From maz at kernel.org  Fri Apr  2 12:17:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 02 Apr 2021 12:17:09 +0100
Subject: [PATCH 3/4] PCI: j721e: Add PCIe support for j7200
In-Reply-To: <20210325090936.9306-4-kishon@ti.com>
References: <20210325090936.9306-1-kishon@ti.com>
 <20210325090936.9306-4-kishon@ti.com>
Message-ID: <87a6qhey16.wl-maz@kernel.org>

On Thu, 25 Mar 2021 09:09:35 +0000,
Kishon Vijay Abraham I <kishon at ti.com> wrote:
> 
> J7200 has the same PCIe IP as in J721E with minor changes in the
> wrapper. Add PCIe support for j7200 accounting for the wrapper
> changes in pci-j721e.c
> Changes from J721E:
>  *) Allows byte access of bridge configuration space registers
>  *) Changes in legacy interrupt register map
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  drivers/pci/controller/cadence/pci-j721e.c | 111 ++++++++++++++++++---
>  1 file changed, 99 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
> index 17db86a51ca8..f175f116abf6 100644
> --- a/drivers/pci/controller/cadence/pci-j721e.c
> +++ b/drivers/pci/controller/cadence/pci-j721e.c
> @@ -27,6 +27,7 @@
>  #define STATUS_REG_SYS_2	0x508
>  #define STATUS_CLR_REG_SYS_2	0x708
>  #define LINK_DOWN		BIT(1)
> +#define J7200_LINK_DOWN		BIT(10)
>  
>  #define EOI_REG			0x10
>  
> @@ -35,6 +36,10 @@
>  #define STATUS_CLR_REG_SYS_0	0x700
>  #define INTx_EN(num)		(1 << (num))
>  
> +#define ENABLE_REG_SYS_1	0x104
> +#define STATUS_REG_SYS_1	0x504
> +#define SYS1_INTx_EN(num)	(1 << (22 + (num)))
> +
>  #define J721E_PCIE_USER_CMD_STATUS	0x4
>  #define LINK_TRAINING_ENABLE		BIT(0)
>  
> @@ -48,6 +53,14 @@ enum link_status {
>  	LINK_UP_DL_COMPLETED,
>  };
>  
> +#define USER_EOI_REG		0xC8
> +enum eoi_reg {
> +	EOI_DOWNSTREAM_INTERRUPT,
> +	EOI_FLR_INTERRUPT,
> +	EOI_LEGACY_INTERRUPT,
> +	EOI_POWER_STATE_INTERRUPT,
> +};
> +
>  #define J721E_MODE_RC			BIT(7)
>  #define LANE_COUNT_MASK			BIT(8)
>  #define LANE_COUNT(n)			((n) << 8)
> @@ -65,6 +78,8 @@ struct j721e_pcie {
>  	void __iomem		*user_cfg_base;
>  	void __iomem		*intd_cfg_base;
>  	struct irq_domain	*legacy_irq_domain;
> +	bool			is_intc_v1;
> +	u32			link_irq_reg_field;
>  };
>  
>  enum j721e_pcie_mode {
> @@ -75,6 +90,9 @@ enum j721e_pcie_mode {
>  struct j721e_pcie_data {
>  	enum j721e_pcie_mode	mode;
>  	bool quirk_retrain_flag;
> +	bool			is_intc_v1;
> +	bool			byte_access_allowed;
> +	const struct cdns_pcie_ops *ops;
>  };
>  
>  static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
> @@ -106,12 +124,12 @@ static irqreturn_t j721e_pcie_link_irq_handler(int irq, void *priv)
>  	u32 reg;
>  
>  	reg = j721e_pcie_intd_readl(pcie, STATUS_REG_SYS_2);
> -	if (!(reg & LINK_DOWN))
> +	if (!(reg & pcie->link_irq_reg_field))
>  		return IRQ_NONE;
>  
>  	dev_err(dev, "LINK DOWN!\n");
>  
> -	j721e_pcie_intd_writel(pcie, STATUS_CLR_REG_SYS_2, LINK_DOWN);
> +	j721e_pcie_intd_writel(pcie, STATUS_CLR_REG_SYS_2, pcie->link_irq_reg_field);
>  	return IRQ_HANDLED;
>  }
>  
> @@ -119,12 +137,40 @@ static void j721e_pcie_config_link_irq(struct j721e_pcie *pcie)
>  {
>  	u32 reg;
>  
> +	pcie->link_irq_reg_field = J7200_LINK_DOWN;
> +	if (pcie->is_intc_v1)
> +		pcie->link_irq_reg_field = LINK_DOWN;
> +
>  	reg = j721e_pcie_intd_readl(pcie, ENABLE_REG_SYS_2);
> -	reg |= LINK_DOWN;
> +	reg |= pcie->link_irq_reg_field;
>  	j721e_pcie_intd_writel(pcie, ENABLE_REG_SYS_2, reg);
>  }
>  
>  static void j721e_pcie_legacy_irq_handler(struct irq_desc *desc)
> +{
> +	struct j721e_pcie *pcie = irq_desc_get_handler_data(desc);
> +	struct irq_chip *chip = irq_desc_get_chip(desc);
> +	int virq;
> +	u32 reg;
> +	int i;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	for (i = 0; i < PCI_NUM_INTX; i++) {
> +		reg = j721e_pcie_intd_readl(pcie, STATUS_REG_SYS_1);
> +		if (!(reg & SYS1_INTx_EN(i)))
> +			continue;
> +
> +		virq = irq_find_mapping(pcie->legacy_irq_domain, i);
> +		generic_handle_irq(virq);
> +		j721e_pcie_user_writel(pcie, USER_EOI_REG,
> +				       EOI_LEGACY_INTERRUPT);

Exact same comment as in the previous patch: this EOI (which I assume
is used to regenerate the GIC edge at after handling the INTx level
interrupt) must be placed in a irq_eoi() callback.

Thanks,

	M.

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


From clabbe.montjoie at gmail.com  Fri Apr  2 12:18:25 2021
From: clabbe.montjoie at gmail.com (Corentin Labbe)
Date: Fri, 2 Apr 2021 13:18:25 +0200
Subject: [PATCH][next] crypto: sun8i-ss: Fix memory leak of pad
In-Reply-To: <20210401151827.2015960-1-colin.king@canonical.com>
References: <20210401151827.2015960-1-colin.king@canonical.com>
Message-ID: <YGb9gYv1+2aqFUNa@Red>

Le Thu, Apr 01, 2021 at 04:18:27PM +0100, Colin King a ?crit :
> From: Colin Ian King <colin.king at canonical.com>
> 
> It appears there are several failure return paths that don't seem
> to be free'ing pad. Fix these.
> 
> Addresses-Coverity: ("Resource leak")
> Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---

Hello

Acked-by: Corentin Labbe <clabbe.montjoie at gmail.com>
Tested-by: Corentin Labbe <clabbe.montjoie at gmail.com>
Tested-on: sun8i-a83t-bananapi-m3

Thanks


From derrick.mckee at gmail.com  Fri Apr  2 12:26:12 2021
From: derrick.mckee at gmail.com (Derrick McKee)
Date: Fri, 2 Apr 2021 07:26:12 -0400
Subject: Removed MTE function
Message-ID: <CAJoBWHz5GdRVnYAuvCkVxcx8qFEMnkmLToSy4Lwckg1LptHfpA@mail.gmail.com>

Hi,

I was under the impression that MTE was mainlined in the kernel.
However, the function mte_assign_mem_tag_range is not present in the
5.10 or later kernels.  Was it removed or just that functionality
isn't ready yet?  If it was removed, why?  Thanks.


--
Derrick McKee
Phone: (703) 957-9362
Email: derrick.mckee at gmail.com


From catalin.marinas at arm.com  Fri Apr  2 12:26:57 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 2 Apr 2021 12:26:57 +0100
Subject: [PATCH] arm64/mm: Fix mapping_dirty_helpers with arm64
In-Reply-To: <20210331182344.47987-1-zackr@vmware.com>
References: <20210331182344.47987-1-zackr@vmware.com>
Message-ID: <20210402112657.GB29774@arm.com>

On Wed, Mar 31, 2021 at 02:23:44PM -0400, Zack Rusin wrote:
> The pagetable walk callbacks in mm/mapping_dirty_helpers.c depend
> on a set of helpers from which pud_dirty(pud) was missing. I'm
> assuming mapping_dirty_helpers weren't used on ARM64 before
> because the missing pud_dirty is causing a compilation error.
> 
> The drivers/gpu/drm/vmwgfx code uses mapping_dirty_helpers and
> has been ported to ARM64 but it depends on this code getting in
> first in order to compile/work.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Peter Zijlstra <peterz at infradead.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Zack Rusin <zackr at vmware.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 47027796c2f9..ecd80f87a996 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -451,6 +451,7 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
>  #define pfn_pmd(pfn,prot)	__pmd(__phys_to_pmd_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
>  #define mk_pmd(page,prot)	pfn_pmd(page_to_pfn(page),prot)
>  
> +#define pud_dirty(pud)		pte_dirty(pud_pte(pud))
>  #define pud_young(pud)		pte_young(pud_pte(pud))
>  #define pud_mkyoung(pud)	pte_pud(pte_mkyoung(pud_pte(pud)))
>  #define pud_write(pud)		pte_write(pud_pte(pud))

I think pud_dirty() should only be defined if
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD which is not the case on
arm64. Well, the pud_young/mkyoung/write should probably also be removed
until we have pud pages on arm64.

The wp_clean_pud_entry() function bails out early since
pud_trans_unstable() returns 0 on arm64. So we either bracket this
function by some #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD or we
make some generic definitions for pud_* accessors when we don't have
this config.

-- 
Catalin


From sebastian.reichel at collabora.com  Fri Apr  2 12:57:42 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Fri, 2 Apr 2021 13:57:42 +0200
Subject: [PATCH v4 2/2] power: supply: mt6360_charger: add MT6360 charger
 support
In-Reply-To: <1610973703-676-3-git-send-email-gene.chen.richtek@gmail.com>
References: <1610973703-676-1-git-send-email-gene.chen.richtek@gmail.com>
 <1610973703-676-3-git-send-email-gene.chen.richtek@gmail.com>
Message-ID: <20210402115742.ssgh72eztfjv66sc@earth.universe>

Hi,

On Mon, Jan 18, 2021 at 08:41:43PM +0800, Gene Chen wrote:
> From: Gene Chen <gene_chen at richtek.com>
> 
> Add basic support for the battery charger for MT6360 PMIC
> 
> Signed-off-by: Gene Chen <gene_chen at richtek.com>
> ---
>  drivers/power/supply/Kconfig          |  10 +
>  drivers/power/supply/Makefile         |   1 +
>  drivers/power/supply/mt6360_charger.c | 914 ++++++++++++++++++++++++++++++++++
>  3 files changed, 925 insertions(+)
>  create mode 100644 drivers/power/supply/mt6360_charger.c
> 
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index eec646c..dd63bed 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -567,6 +567,16 @@ config CHARGER_MP2629
>  	  Battery charger. This driver provides Battery charger power management
>  	  functions on the systems.
>  
> +config CHARGER_MT6360
> +	tristate "Mediatek MT6360 Charger Driver"
> +	depends on MFD_MT6360
> +	depends on REGULATOR
> +	help
> +	  Say Y here to enable MT6360 Charger Part.
> +	  The device supports High-Accuracy Voltage/Current Regulation,
> +	  Average Input Current Regulation, Battery Tempature Sensing,
> +	  Over-Temperature Protection, DPDM Detection for BC1.2
> +
>  config CHARGER_QCOM_SMBB
>  	tristate "Qualcomm Switch-Mode Battery Charger and Boost"
>  	depends on MFD_SPMI_PMIC || COMPILE_TEST
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index dd4b863..9bd0804 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -77,6 +77,7 @@ obj-$(CONFIG_CHARGER_MAX77693)	+= max77693_charger.o
>  obj-$(CONFIG_CHARGER_MAX8997)	+= max8997_charger.o
>  obj-$(CONFIG_CHARGER_MAX8998)	+= max8998_charger.o
>  obj-$(CONFIG_CHARGER_MP2629)	+= mp2629_charger.o
> +obj-$(CONFIG_CHARGER_MT6360)	+= mt6360_charger.o
>  obj-$(CONFIG_CHARGER_QCOM_SMBB)	+= qcom_smbb.o
>  obj-$(CONFIG_CHARGER_BQ2415X)	+= bq2415x_charger.o
>  obj-$(CONFIG_CHARGER_BQ24190)	+= bq24190_charger.o
> diff --git a/drivers/power/supply/mt6360_charger.c b/drivers/power/supply/mt6360_charger.c
> new file mode 100644
> index 0000000..d80bdad
> --- /dev/null
> +++ b/drivers/power/supply/mt6360_charger.c
> @@ -0,0 +1,914 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/driver.h>
> +
> +#define MT6360_PMU_CHG_CTRL1	0x311
> +#define MT6360_PMU_CHG_CTRL2	0x312
> +#define MT6360_PMU_CHG_CTRL3	0x313
> +#define MT6360_PMU_CHG_CTRL4	0x314
> +#define MT6360_PMU_CHG_CTRL5	0x315
> +#define MT6360_PMU_CHG_CTRL6	0x316
> +#define MT6360_PMU_CHG_CTRL7	0x317
> +#define MT6360_PMU_CHG_CTRL8	0x318
> +#define MT6360_PMU_CHG_CTRL9	0x319
> +#define MT6360_PMU_CHG_CTRL10	0x31A
> +#define MT6360_PMU_DEVICE_TYPE	0x322
> +#define MT6360_PMU_USB_STATUS1	0x327
> +#define MT6360_PMU_CHG_STAT	0x34A
> +#define MT6360_PMU_CHG_CTRL19	0x361
> +#define MT6360_PMU_FOD_STAT	0x3E7
> +
> +/* MT6360_PMU_CHG_CTRL1 */
> +#define MT6360_FSLP_SHFT	(3)
> +#define MT6360_FSLP_MASK	BIT(MT6360_FSLP_SHFT)
> +#define MT6360_OPA_MODE_SHFT	(0)
> +#define MT6360_OPA_MODE_MASK	BIT(MT6360_OPA_MODE_SHFT)
> +/* MT6360_PMU_CHG_CTRL2 */
> +#define MT6360_IINLMTSEL_SHFT	(2)
> +#define MT6360_IINLMTSEL_MASK	GENMASK(3, 2)
> +/* MT6360_PMU_CHG_CTRL3 */
> +#define MT6360_IAICR_SHFT	(2)
> +#define MT6360_IAICR_MASK	GENMASK(7, 2)
> +#define MT6360_ILIM_EN_MASK	BIT(0)
> +/* MT6360_PMU_CHG_CTRL4 */
> +#define MT6360_VOREG_SHFT	(1)
> +#define MT6360_VOREG_MASK	GENMASK(7, 1)
> +/* MT6360_PMU_CHG_CTRL5 */
> +#define MT6360_VOBST_MASK	GENMASK(7, 2)
> +/* MT6360_PMU_CHG_CTRL6 */
> +#define MT6360_VMIVR_SHFT      (1)
> +#define MT6360_VMIVR_MASK      GENMASK(7, 1)
> +/* MT6360_PMU_CHG_CTRL7 */
> +#define MT6360_ICHG_SHFT	(2)
> +#define MT6360_ICHG_MASK	GENMASK(7, 2)
> +/* MT6360_PMU_CHG_CTRL8 */
> +#define MT6360_IPREC_SHFT	(0)
> +#define MT6360_IPREC_MASK	GENMASK(3, 0)
> +/* MT6360_PMU_CHG_CTRL9 */
> +#define MT6360_IEOC_SHFT	(4)
> +#define MT6360_IEOC_MASK	GENMASK(7, 4)
> +/* MT6360_PMU_CHG_CTRL10 */
> +#define MT6360_OTG_OC_MASK	GENMASK(3, 0)
> +/* MT6360_PMU_DEVICE_TYPE */
> +#define MT6360_USBCHGEN_MASK	BIT(7)
> +/* MT6360_PMU_USB_STATUS1 */
> +#define MT6360_USB_STATUS_SHFT	(4)
> +#define MT6360_USB_STATUS_MASK	GENMASK(6, 4)
> +/* MT6360_PMU_CHG_STAT */
> +#define MT6360_CHG_STAT_SHFT	(6)
> +#define MT6360_CHG_STAT_MASK	GENMASK(7, 6)
> +#define MT6360_VBAT_LVL_MASK	BIT(5)
> +/* MT6360_PMU_CHG_CTRL19 */
> +#define MT6360_VINOVP_SHFT	(5)
> +#define MT6360_VINOVP_MASK	GENMASK(6, 5)
> +/* MT6360_PMU_FOD_STAT */
> +#define MT6360_CHRDET_EXT_MASK	BIT(4)
> +
> +/* uV */
> +#define MT6360_VMIVR_MIN	3900000
> +#define MT6360_VMIVR_MAX	13400000
> +#define MT6360_VMIVR_STEP	100000
> +/* uA */
> +#define MT6360_ICHG_MIN		100000
> +#define MT6360_ICHG_MAX		5000000
> +#define MT6360_ICHG_STEP	100000
> +/* uV */
> +#define MT6360_VOREG_MIN	3900000
> +#define MT6360_VOREG_MAX	4710000
> +#define MT6360_VOREG_STEP	10000
> +/* uA */
> +#define MT6360_AICR_MIN		100000
> +#define MT6360_AICR_MAX		3250000
> +#define MT6360_AICR_STEP	50000
> +/* uA */
> +#define MT6360_IPREC_MIN	100000
> +#define MT6360_IPREC_MAX	850000
> +#define MT6360_IPREC_STEP	50000
> +/* uA */
> +#define MT6360_IEOC_MIN		100000
> +#define MT6360_IEOC_MAX		850000
> +#define MT6360_IEOC_STEP	50000
> +
> +struct mt6360_chg_info {
> +	struct device *dev;
> +	struct regmap *regmap;
> +	struct power_supply_desc psy_desc;
> +	struct power_supply *psy;
> +	struct regulator_dev *otg_rdev;
> +	struct mutex chgdet_lock;
> +	u32 vinovp;
> +	bool pwr_rdy;
> +	bool bc12_en;
> +	int psy_usb_type;
> +	struct work_struct chrdet_work;
> +};
> +
> +enum mt6360_iinlmtsel {
> +	MT6360_IINLMTSEL_AICR_3250 = 0,
> +	MT6360_IINLMTSEL_CHG_TYPE,
> +	MT6360_IINLMTSEL_AICR,
> +	MT6360_IINLMTSEL_LOWER_LEVEL,
> +};
> +
> +enum mt6360_pmu_chg_type {
> +	MT6360_CHG_TYPE_NOVBUS = 0,
> +	MT6360_CHG_TYPE_UNDER_GOING,
> +	MT6360_CHG_TYPE_SDP,
> +	MT6360_CHG_TYPE_SDPNSTD,
> +	MT6360_CHG_TYPE_DCP,
> +	MT6360_CHG_TYPE_CDP,
> +	MT6360_CHG_TYPE_DISABLE_BC12,
> +	MT6360_CHG_TYPE_MAX,
> +};
> +
> +static enum power_supply_usb_type mt6360_charger_usb_types[] = {
> +	POWER_SUPPLY_USB_TYPE_UNKNOWN,
> +	POWER_SUPPLY_USB_TYPE_SDP,
> +	POWER_SUPPLY_USB_TYPE_DCP,
> +	POWER_SUPPLY_USB_TYPE_CDP,
> +};
> +
> +static unsigned int mt6360_map_reg_sel(u32 data, u32 min, u32 max, u32 step)
> +{
> +	u32 target = 0, max_sel;
> +
> +	if (data >= min) {
> +		target = (data - min) / step;
> +		max_sel = (max - min) / step;
> +		if (target > max_sel)
> +			target = max_sel;
> +	}
> +	return target;
> +}
> +
> +static u32 mt6360_map_real_val(u32 sel, u32 min, u32 max, u32 step)
> +{
> +	u32 target = 0;
> +
> +	target = min + (sel * step);
> +	if (target > max)
> +		target = max;
> +	return target;
> +}
> +
> +static int mt6360_get_chrdet_ext_stat(struct mt6360_chg_info *mci,
> +					     bool *pwr_rdy)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_FOD_STAT, &regval);
> +	if (ret < 0)
> +		return ret;
> +	*pwr_rdy = (regval & MT6360_CHRDET_EXT_MASK) ? true : false;
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_online(struct mt6360_chg_info *mci,
> +				     union power_supply_propval *val)
> +{
> +	int ret;
> +	bool pwr_rdy;
> +
> +	ret = mt6360_get_chrdet_ext_stat(mci, &pwr_rdy);
> +	if (ret < 0)
> +		return ret;
> +	val->intval = pwr_rdy ? true : false;
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_status(struct mt6360_chg_info *mci,
> +				     union power_supply_propval *val)
> +{
> +	int status, ret;
> +	unsigned int regval;
> +	bool pwr_rdy;
> +
> +	ret = mt6360_get_chrdet_ext_stat(mci, &pwr_rdy);
> +	if (ret < 0)
> +		return ret;
> +	if (!pwr_rdy) {
> +		status = POWER_SUPPLY_STATUS_DISCHARGING;
> +		goto out;
> +	}
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_STAT, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval &= MT6360_CHG_STAT_MASK;
> +	regval >>= MT6360_CHG_STAT_SHFT;
> +	switch (regval) {
> +	case 0x0:
> +		status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> +		break;
> +	case 0x1:
> +		status = POWER_SUPPLY_STATUS_CHARGING;
> +		break;
> +	case 0x2:
> +		status = POWER_SUPPLY_STATUS_FULL;
> +		break;
> +	default:
> +		ret = -EIO;
> +	}
> +out:
> +	if (!ret)
> +		val->intval = status;
> +	return ret;
> +}
> +
> +static int mt6360_charger_get_charge_type(struct mt6360_chg_info *mci,
> +					  union power_supply_propval *val)
> +{
> +	int type, ret;
> +	unsigned int regval;
> +	u8 chg_stat;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_STAT, &regval);
> +	if (ret < 0)
> +		return ret;
> +
> +	chg_stat = (regval & MT6360_CHG_STAT_MASK) >> MT6360_CHG_STAT_SHFT;
> +	switch (chg_stat) {
> +	case 0x01: /* Charge in Progress */
> +		if (regval & MT6360_VBAT_LVL_MASK)
> +			type = POWER_SUPPLY_CHARGE_TYPE_FAST;
> +		else
> +			type = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
> +		break;
> +	case 0x00: /* Not Charging */
> +	case 0x02: /* Charge Done */
> +	case 0x03: /* Charge Fault */
> +	default:
> +		type = POWER_SUPPLY_CHARGE_TYPE_NONE;
> +		break;
> +	}
> +
> +	val->intval = type;
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_ichg(struct mt6360_chg_info *mci,
> +				   union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL7, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_ICHG_MASK) >> MT6360_ICHG_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_ICHG_MIN,
> +					  MT6360_ICHG_MAX,
> +					  MT6360_ICHG_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_max_ichg(struct mt6360_chg_info *mci,
> +				       union power_supply_propval *val)
> +{
> +	val->intval = MT6360_ICHG_MAX;
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_cv(struct mt6360_chg_info *mci,
> +				 union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL4, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_VOREG_MASK) >> MT6360_VOREG_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_VOREG_MIN,
> +					  MT6360_VOREG_MAX,
> +					  MT6360_VOREG_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_max_cv(struct mt6360_chg_info *mci,
> +				     union power_supply_propval *val)
> +{
> +	val->intval = MT6360_VOREG_MAX;
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_aicr(struct mt6360_chg_info *mci,
> +				   union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL3, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_IAICR_MASK) >> MT6360_IAICR_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_AICR_MIN,
> +					  MT6360_AICR_MAX,
> +					  MT6360_AICR_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_mivr(struct mt6360_chg_info *mci,
> +				   union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL6, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_VMIVR_MASK) >> MT6360_VMIVR_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_VMIVR_MIN,
> +					  MT6360_VMIVR_MAX,
> +					  MT6360_VMIVR_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_iprechg(struct mt6360_chg_info *mci,
> +				      union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL8, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_IPREC_MASK) >> MT6360_IPREC_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_IPREC_MIN,
> +					  MT6360_IPREC_MAX,
> +					  MT6360_IPREC_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_get_ieoc(struct mt6360_chg_info *mci,
> +				   union power_supply_propval *val)
> +{
> +	int ret;
> +	unsigned int regval;
> +
> +	ret = regmap_read(mci->regmap, MT6360_PMU_CHG_CTRL9, &regval);
> +	if (ret < 0)
> +		return ret;
> +	regval = (regval & MT6360_IEOC_MASK) >> MT6360_IEOC_SHFT;
> +	val->intval = mt6360_map_real_val(regval,
> +					  MT6360_IEOC_MIN,
> +					  MT6360_IEOC_MAX,
> +					  MT6360_IEOC_STEP);
> +	return 0;
> +}
> +
> +static int mt6360_charger_set_online(struct mt6360_chg_info *mci,
> +				     const union power_supply_propval *val)
> +{
> +	u8 force_sleep = val->intval ? 0 : 1;
> +
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL1,
> +				  MT6360_FSLP_MASK,
> +				  force_sleep << MT6360_FSLP_SHFT);
> +}
> +
> +static int mt6360_charger_set_ichg(struct mt6360_chg_info *mci,
> +				   const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_ICHG_MIN,
> +				 MT6360_ICHG_MAX,
> +				 MT6360_ICHG_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL7,
> +				  MT6360_ICHG_MASK,
> +				  sel << MT6360_ICHG_SHFT);
> +}
> +
> +static int mt6360_charger_set_cv(struct mt6360_chg_info *mci,
> +				 const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_VOREG_MIN,
> +				 MT6360_VOREG_MAX,
> +				 MT6360_VOREG_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL4,
> +				  MT6360_VOREG_MASK,
> +				  sel << MT6360_VOREG_SHFT);
> +}
> +
> +static int mt6360_charger_set_aicr(struct mt6360_chg_info *mci,
> +				   const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_AICR_MIN,
> +				 MT6360_AICR_MAX,
> +				 MT6360_AICR_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL3,
> +				  MT6360_IAICR_MASK,
> +				  sel << MT6360_IAICR_SHFT);
> +}
> +
> +static int mt6360_charger_set_mivr(struct mt6360_chg_info *mci,
> +				   const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_VMIVR_MIN,
> +				 MT6360_VMIVR_MAX,
> +				 MT6360_VMIVR_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL3,
> +				  MT6360_VMIVR_MASK,
> +				  sel << MT6360_VMIVR_SHFT);
> +}
> +
> +static int mt6360_charger_set_iprechg(struct mt6360_chg_info *mci,
> +				      const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_IPREC_MIN,
> +				 MT6360_IPREC_MAX,
> +				 MT6360_IPREC_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL8,
> +				  MT6360_IPREC_MASK,
> +				  sel << MT6360_IPREC_SHFT);
> +}
> +
> +static int mt6360_charger_set_ieoc(struct mt6360_chg_info *mci,
> +				   const union power_supply_propval *val)
> +{
> +	u8 sel;
> +
> +	sel = mt6360_map_reg_sel(val->intval,
> +				 MT6360_IEOC_MIN,
> +				 MT6360_IEOC_MAX,
> +				 MT6360_IEOC_STEP);
> +	return regmap_update_bits(mci->regmap,
> +				  MT6360_PMU_CHG_CTRL9,
> +				  MT6360_IEOC_MASK,
> +				  sel << MT6360_IEOC_SHFT);
> +}
> +
> +static int mt6360_charger_get_property(struct power_supply *psy,
> +				       enum power_supply_property psp,
> +				       union power_supply_propval *val)
> +{
> +	struct mt6360_chg_info *mci = power_supply_get_drvdata(psy);
> +	int ret = 0;
> +
> +	switch (psp) {
> +	case POWER_SUPPLY_PROP_ONLINE:
> +		ret = mt6360_charger_get_online(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_STATUS:
> +		ret = mt6360_charger_get_status(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CHARGE_TYPE:
> +		ret = mt6360_charger_get_charge_type(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
> +		ret = mt6360_charger_get_ichg(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
> +		ret = mt6360_charger_get_max_ichg(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
> +		ret = mt6360_charger_get_cv(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
> +		ret = mt6360_charger_get_max_cv(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> +		ret = mt6360_charger_get_aicr(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT:
> +		ret = mt6360_charger_get_mivr(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
> +		ret = mt6360_charger_get_iprechg(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
> +		ret = mt6360_charger_get_ieoc(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_USB_TYPE:
> +		val->intval = mci->psy_usb_type;
> +		break;
> +	default:
> +		ret = -ENODATA;
> +	}
> +	return ret;
> +}
> +
> +static int mt6360_charger_set_property(struct power_supply *psy,
> +				       enum power_supply_property psp,
> +				       const union power_supply_propval *val)
> +{
> +	struct mt6360_chg_info *mci = power_supply_get_drvdata(psy);
> +	int ret;
> +
> +	switch (psp) {
> +	case POWER_SUPPLY_PROP_ONLINE:
> +		ret = mt6360_charger_set_online(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
> +		ret = mt6360_charger_set_ichg(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
> +		ret = mt6360_charger_set_cv(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> +		ret = mt6360_charger_set_aicr(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT:
> +		ret = mt6360_charger_set_mivr(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
> +		ret = mt6360_charger_set_iprechg(mci, val);
> +		break;
> +	case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
> +		ret = mt6360_charger_set_ieoc(mci, val);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +	return ret;
> +}
> +
> +static int mt6360_charger_property_is_writeable(struct power_supply *psy,
> +					       enum power_supply_property psp)
> +{
> +	switch (psp) {
> +	case POWER_SUPPLY_PROP_ONLINE:
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
> +	case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
> +	case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
> +	case POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT:
> +	case POWER_SUPPLY_PROP_PRECHARGE_CURRENT:
> +	case POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT:
> +		return 1;
> +	default:
> +		return 0;
> +	}
> +}
> +
> +static enum power_supply_property mt6360_charger_properties[] = {
> +	POWER_SUPPLY_PROP_ONLINE,
> +	POWER_SUPPLY_PROP_STATUS,
> +	POWER_SUPPLY_PROP_CHARGE_TYPE,
> +	POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
> +	POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
> +	POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
> +	POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
> +	POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
> +	POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT,
> +	POWER_SUPPLY_PROP_PRECHARGE_CURRENT,
> +	POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
> +	POWER_SUPPLY_PROP_USB_TYPE,
> +};
> +
> +static const struct power_supply_desc mt6360_charger_desc = {
> +	.type			= POWER_SUPPLY_TYPE_USB,
> +	.properties		= mt6360_charger_properties,
> +	.num_properties		= ARRAY_SIZE(mt6360_charger_properties),
> +	.get_property		= mt6360_charger_get_property,
> +	.set_property		= mt6360_charger_set_property,
> +	.property_is_writeable	= mt6360_charger_property_is_writeable,
> +	.usb_types		= mt6360_charger_usb_types,
> +	.num_usb_types		= ARRAY_SIZE(mt6360_charger_usb_types),
> +};
> +
> +static const struct regulator_ops mt6360_chg_otg_ops = {
> +	.list_voltage = regulator_list_voltage_linear,
> +	.enable = regulator_enable_regmap,
> +	.disable = regulator_disable_regmap,
> +	.is_enabled = regulator_is_enabled_regmap,
> +	.set_voltage_sel = regulator_set_voltage_sel_regmap,
> +	.get_voltage_sel = regulator_get_voltage_sel_regmap,
> +};
> +
> +static const struct regulator_desc mt6360_otg_rdesc = {
> +	.of_match = "usb-otg-vbus",
> +	.name = "usb-otg-vbus",
> +	.ops = &mt6360_chg_otg_ops,
> +	.owner = THIS_MODULE,
> +	.type = REGULATOR_VOLTAGE,
> +	.min_uV = 4425000,
> +	.uV_step = 25000,
> +	.n_voltages = 57,
> +	.vsel_reg = MT6360_PMU_CHG_CTRL5,
> +	.vsel_mask = MT6360_VOBST_MASK,
> +	.enable_reg = MT6360_PMU_CHG_CTRL1,
> +	.enable_mask = MT6360_OPA_MODE_MASK,
> +};
> +
> +static irqreturn_t mt6360_pmu_attach_i_handler(int irq, void *data)
> +{
> +	struct mt6360_chg_info *mci = data;
> +	int ret;
> +	unsigned int usb_status;
> +	int last_usb_type;
> +
> +	mutex_lock(&mci->chgdet_lock);
> +	if (!mci->bc12_en) {
> +		dev_warn(mci->dev, "Received attach interrupt, bc12 disabled, ignore irq\n");
> +		goto out;
> +	}
> +	last_usb_type = mci->psy_usb_type;
> +	/* Plug in */
> +	ret = regmap_read(mci->regmap, MT6360_PMU_USB_STATUS1, &usb_status);
> +	if (ret < 0)
> +		goto out;
> +	usb_status &= MT6360_USB_STATUS_MASK;
> +	usb_status >>= MT6360_USB_STATUS_SHFT;
> +	switch (usb_status) {
> +	case MT6360_CHG_TYPE_NOVBUS:
> +		dev_dbg(mci->dev, "Received attach interrupt, no vbus\n");
> +		goto out;
> +	case MT6360_CHG_TYPE_UNDER_GOING:
> +		dev_dbg(mci->dev, "Received attach interrupt, under going...\n");
> +		goto out;
> +	case MT6360_CHG_TYPE_SDP:
> +		mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_SDP;
> +		break;
> +	case MT6360_CHG_TYPE_SDPNSTD:
> +		mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_SDP;
> +		break;
> +	case MT6360_CHG_TYPE_CDP:
> +		mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_CDP;
> +		break;
> +	case MT6360_CHG_TYPE_DCP:
> +		mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_DCP;
> +		break;
> +	case MT6360_CHG_TYPE_DISABLE_BC12:
> +		dev_dbg(mci->dev, "Received attach interrupt, bc12 detect not enable\n");
> +		goto out;
> +	default:
> +		dev_dbg(mci->dev, "Received attach interrupt, reserved address\n");
> +		goto out;
> +	}

I suppose the cases with dev_dbg should have

mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_UNKNOWN;

> +	dev_dbg(mci->dev, "Received attach interrupt, chg_type = %d\n", mci->psy_usb_type);
> +	if (last_usb_type != mci->psy_usb_type)
> +		power_supply_changed(mci->psy);
> +out:
> +	mutex_unlock(&mci->chgdet_lock);
> +	return IRQ_HANDLED;
> +}
> +
> +static void mt6360_handle_chrdet_ext_evt(struct mt6360_chg_info *mci)
> +{
> +	int ret;
> +	bool pwr_rdy;
> +
> +	mutex_lock(&mci->chgdet_lock);
> +	ret = mt6360_get_chrdet_ext_stat(mci, &pwr_rdy);
> +	if (ret < 0)
> +		goto out;
> +	if (mci->pwr_rdy == pwr_rdy) {
> +		dev_dbg(mci->dev, "Received vbus interrupt, pwr_rdy is same(%d)\n", pwr_rdy);
> +		goto out;
> +	}
> +	mci->pwr_rdy = pwr_rdy;
> +	dev_dbg(mci->dev, "Received vbus interrupt, pwr_rdy = %d\n", pwr_rdy);
> +	if (!pwr_rdy) {
> +		mci->psy_usb_type = POWER_SUPPLY_USB_TYPE_UNKNOWN;
> +		power_supply_changed(mci->psy);
> +
> +	}
> +	ret = regmap_update_bits(mci->regmap,
> +				 MT6360_PMU_DEVICE_TYPE,
> +				 MT6360_USBCHGEN_MASK,
> +				 pwr_rdy ? MT6360_USBCHGEN_MASK : 0);
> +	if (ret < 0)
> +		goto out;
> +	mci->bc12_en = pwr_rdy;
> +out:
> +	mutex_unlock(&mci->chgdet_lock);
> +}
> +
> +static void mt6360_chrdet_work(struct work_struct *work)
> +{
> +	struct mt6360_chg_info *mci = (struct mt6360_chg_info *)container_of(
> +				     work, struct mt6360_chg_info, chrdet_work);
> +
> +	mt6360_handle_chrdet_ext_evt(mci);
> +}
> +
> +static irqreturn_t mt6360_pmu_chrdet_ext_evt_handler(int irq, void *data)
> +{
> +	struct mt6360_chg_info *mci = data;
> +
> +	mt6360_handle_chrdet_ext_evt(mci);
> +	return IRQ_HANDLED;
> +}
> +
> +static int mt6360_chg_irq_register(struct platform_device *pdev)
> +{
> +	const struct {
> +		const char *name;
> +		irq_handler_t handler;
> +	} irq_descs[] = {
> +		{ "attach_i", mt6360_pmu_attach_i_handler },
> +		{ "chrdet_ext_evt", mt6360_pmu_chrdet_ext_evt_handler }
> +	};
> +	int i, ret;
> +
> +	for (i = 0; i < ARRAY_SIZE(irq_descs); i++) {
> +		ret = platform_get_irq_byname(pdev, irq_descs[i].name);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = devm_request_threaded_irq(&pdev->dev, ret, NULL,
> +						irq_descs[i].handler,
> +						IRQF_TRIGGER_FALLING,
> +						irq_descs[i].name,
> +						platform_get_drvdata(pdev));
> +		if (ret < 0)
> +			return dev_err_probe(&pdev->dev, ret, "Failed to request %s irq\n",
> +					     irq_descs[i].name);

Missing IRQF_ONESHOT

> +	}
> +
> +	return 0;
> +}
> +
> +struct mt6360_field_info {
> +	struct device_attribute dev_attr;
> +	u16 reg;
> +	u8 mask;
> +	u8 shft;
> +};
> +
> +static int mt6360_chg_init_setting(struct mt6360_chg_info *mci)
> +{
> +	int ret;
> +
> +	ret = regmap_update_bits(mci->regmap, MT6360_PMU_DEVICE_TYPE,
> +				 MT6360_USBCHGEN_MASK, 0);
> +	if (ret)
> +		return dev_err_probe(mci->dev, ret, "%s: Failed to disable bc12\n", __func__);
> +	ret = regmap_update_bits(mci->regmap, MT6360_PMU_CHG_CTRL2,
> +				 MT6360_IINLMTSEL_MASK,
> +				 MT6360_IINLMTSEL_AICR <<
> +					MT6360_IINLMTSEL_SHFT);
> +	if (ret)
> +		return dev_err_probe(mci->dev, ret,
> +				     "%s: Failed to switch iinlmtsel to aicr\n", __func__);
> +	usleep_range(5000, 6000);
> +	ret = regmap_update_bits(mci->regmap, MT6360_PMU_CHG_CTRL3,
> +				 MT6360_ILIM_EN_MASK, 0);
> +	if (ret)
> +		return dev_err_probe(mci->dev, ret,
> +				     "%s: Failed to disable ilim\n", __func__);
> +	ret = regmap_update_bits(mci->regmap, MT6360_PMU_CHG_CTRL10,
> +				 MT6360_OTG_OC_MASK, MT6360_OTG_OC_MASK);
> +	if (ret)
> +		return dev_err_probe(mci->dev, ret,
> +				     "%s: Failed to config otg oc to 3A\n", __func__);
> +	return 0;
> +}
> +
> +static u32 mt6360_vinovp_trans_to_sel(u32 val)
> +{
> +	u32 vinovp_tbl[] = { 5500000, 6500000, 11000000, 14500000 };
> +	int i;
> +
> +	/* Select the smaller and equal supported value */
> +	for (i = 0; i < ARRAY_SIZE(vinovp_tbl)-1; i++) {
> +		if (val < vinovp_tbl[i+1])
> +			break;
> +	}
> +	return i;
> +}
> +
> +static int mt6360_parse_dt(struct platform_device *pdev)
> +{
> +	struct mt6360_chg_info *mci = dev_get_drvdata(&pdev->dev);
> +	int ret;
> +
> +	ret = device_property_read_u32(&pdev->dev, "richtek,vinovp-microvolt", &mci->vinovp);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to parse vinovp in DT\n");
> +	return ret;
> +}
> +
> +static int mt6360_apply_dt(struct platform_device *pdev)
> +{
> +	struct mt6360_chg_info *mci = dev_get_drvdata(&pdev->dev);
> +	u32 sel;
> +
> +	sel = mt6360_vinovp_trans_to_sel(mci->vinovp);
> +	return regmap_update_bits(mci->regmap, MT6360_PMU_CHG_CTRL19,
> +				  MT6360_VINOVP_MASK, sel << MT6360_VINOVP_SHFT);
> +}
> +
> +static int mt6360_charger_probe(struct platform_device *pdev)
> +{
> +	struct mt6360_chg_info *mci;
> +	struct power_supply_config charger_cfg = {};
> +	struct regulator_config config = { };
> +	int ret;
> +
> +	mci = devm_kzalloc(&pdev->dev, sizeof(*mci), GFP_KERNEL);
> +	if (!mci)
> +		return -ENOMEM;
> +
> +	ret = mt6360_parse_dt(pdev);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to parse dt\n");

Just directly call device_property_read_u32() here. No need for
extra complexity.

> +	mci->dev = &pdev->dev;
> +	mci->vinovp = 6500000;

You are overwriting the value provided by device_property_* here.
You need to call it after initializing the value. 

> +	mutex_init(&mci->chgdet_lock);
> +	platform_set_drvdata(pdev, mci);
> +	INIT_WORK(&mci->chrdet_work, &mt6360_chrdet_work);
> +
> +	mci->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +	if (!mci->regmap)
> +		return dev_err_probe(&pdev->dev, -ENODEV, "Failed to get parent regmap\n");
> +
> +	ret = mt6360_apply_dt(pdev);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to apply dt\n");

Either rename to something like mt6360_apply_config
(device_property_* also supports e.g. ACPI), or just
drop the function and do the config here. Is there
any reason to initialize this value early? Otherwise
just merge this function into mt6360_chg_init_setting().

> +	memcpy(&mci->psy_desc, &mt6360_charger_desc, sizeof(mci->psy_desc));
> +	mci->psy_desc.name = dev_name(&pdev->dev);
> +	charger_cfg.drv_data = mci;
> +	charger_cfg.of_node = pdev->dev.of_node;
> +	mci->psy = devm_power_supply_register(&pdev->dev,
> +					      &mci->psy_desc, &charger_cfg);
> +	if (IS_ERR(mci->psy))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(mci->psy),
> +				     "Failed to register power supply dev\n");
> +
> +	ret = mt6360_chg_init_setting(mci);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to initial setting\n");
> +
> +	schedule_work(&mci->chrdet_work);

Missing work cleanup on probe error or driver removal?

> +	ret = mt6360_chg_irq_register(pdev);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to register irqs\n");
> +
> +	config.dev = &pdev->dev;
> +	config.regmap = mci->regmap;
> +	mci->otg_rdev = devm_regulator_register(&pdev->dev, &mt6360_otg_rdesc,
> +						&config);
> +	if (IS_ERR(mci->otg_rdev))
> +		return PTR_ERR(mci->otg_rdev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id __maybe_unused mt6360_charger_of_id[] = {
> +	{ .compatible = "mediatek,mt6360-chg", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mt6360_charger_of_id);
> +
> +static const struct platform_device_id mt6360_charger_id[] = {
> +	{ "mt6360-chg", 0 },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(platform, mt6360_charger_id);
> +
> +static struct platform_driver mt6360_charger_driver = {
> +	.driver = {
> +		.name = "mt6360-chg",
> +		.of_match_table = of_match_ptr(mt6360_charger_of_id),
> +	},
> +	.probe = mt6360_charger_probe,
> +	.id_table = mt6360_charger_id,
> +};
> +module_platform_driver(mt6360_charger_driver);
> +
> +MODULE_AUTHOR("Gene Chen <gene_chen at richtek.com>");
> +MODULE_DESCRIPTION("MT6360 Charger Driver");
> +MODULE_LICENSE("GPL");

-- Sebastian
-------------- 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/20210402/20137843/attachment-0001.sig>

From p.zabel at pengutronix.de  Fri Apr  2 13:01:37 2021
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 2 Apr 2021 14:01:37 +0200
Subject: [PATCH v2 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver
In-Reply-To: <20210330141029.20412-3-quan@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-3-quan@os.amperecomputing.com>
Message-ID: <20210402120137.GA26002@pengutronix.de>

Hi Quan,

On Tue, Mar 30, 2021 at 09:10:28PM +0700, Quan Nguyen wrote:
> The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
> in-band IPMI communication with their host in management (BMC) side.
> 
> This commits adds support specifically for Aspeed AST2500 which commonly
> used as Board Management Controllers.
> 
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
[...]
> diff --git a/drivers/char/ipmi/ssif_bmc_aspeed.c b/drivers/char/ipmi/ssif_bmc_aspeed.c
> new file mode 100644
> index 000000000000..a563fcff5acc
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc_aspeed.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The driver for BMC side of Aspeed SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/poll.h>
> +#include <linux/iopoll.h>
> +
> +#include "ssif_bmc.h"
> +
> +struct aspeed_i2c_bus {
> +	struct i2c_adapter              adap;
> +	struct device                   *dev;

This device handle is apparently unused.

> +	void __iomem                    *base;
> +	struct reset_control            *rst;

This reset control handle is unused as well.

> +	/* Synchronizes I/O mem access to base. */
> +	spinlock_t                      lock;
> +};

regards
Philipp


From pbonzini at redhat.com  Fri Apr  2 13:17:45 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 14:17:45 +0200
Subject: [PATCH v2 00/10] KVM: Consolidate and optimize MMU notifiers
In-Reply-To: <20210402005658.3024832-1-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
Message-ID: <9376b453-be3a-f8b7-d53a-7e54c25161ce@redhat.com>

On 02/04/21 02:56, Sean Christopherson wrote:
> The end goal of this series is to optimize the MMU notifiers to take
> mmu_lock if and only if the notification is relevant to KVM, i.e. the hva
> range overlaps a memslot.   Large VMs (hundreds of vCPUs) are very
> sensitive to mmu_lock being taken for write at inopportune times, and
> such VMs also tend to be "static", e.g. backed by HugeTLB with minimal
> page shenanigans.  The vast majority of notifications for these VMs will
> be spurious (for KVM), and eliding mmu_lock for spurious notifications
> avoids an otherwise unacceptable disruption to the guest.
> 
> To get there without potentially degrading performance, e.g. due to
> multiple memslot lookups, especially on non-x86 where the use cases are
> largely unknown (from my perspective), first consolidate the MMU notifier
> logic by moving the hva->gfn lookups into common KVM.
> 
> Based on kvm/queue, commit 5f986f748438 ("KVM: x86: dump_vmcs should
> include the autoload/autostore MSR lists").
> 
> Well tested on Intel and AMD.  Compile tested for arm64, MIPS, PPC,
> PPC e500, and s390.  Absolutely needs to be tested for real on non-x86,
> I give it even odds that I introduced an off-by-one bug somewhere.
> 
> v2:
>   - Drop the patches that have already been pushed to kvm/queue.
>   - Drop two selftest changes that had snuck in via "git commit -a".
>   - Add a patch to assert that mmu_notifier_count is elevated when
>     .change_pte() runs. [Paolo]
>   - Split out moving KVM_MMU_(UN)LOCK() to __kvm_handle_hva_range() to a
>     separate patch.  Opted not to squash it with the introduction of the
>     common hva walkers (patch 02), as that prevented sharing code between
>     the old and new APIs. [Paolo]
>   - Tweak the comment in kvm_vm_destroy() above the smashing of the new
>     slots lock. [Paolo]
>   - Make mmu_notifier_slots_lock unconditional to avoid #ifdefs. [Paolo]
> 
> v1:
>   - https://lkml.kernel.org/r/20210326021957.1424875-1-seanjc at google.com
> 
> Sean Christopherson (10):
>    KVM: Assert that notifier count is elevated in .change_pte()
>    KVM: Move x86's MMU notifier memslot walkers to generic code
>    KVM: arm64: Convert to the gfn-based MMU notifier callbacks
>    KVM: MIPS/MMU: Convert to the gfn-based MMU notifier callbacks
>    KVM: PPC: Convert to the gfn-based MMU notifier callbacks
>    KVM: Kill off the old hva-based MMU notifier callbacks
>    KVM: Move MMU notifier's mmu_lock acquisition into common helper
>    KVM: Take mmu_lock when handling MMU notifier iff the hva hits a
>      memslot
>    KVM: Don't take mmu_lock for range invalidation unless necessary
>    KVM: x86/mmu: Allow yielding during MMU notifier unmap/zap, if
>      possible
> 
>   arch/arm64/kvm/mmu.c                   | 117 +++------
>   arch/mips/kvm/mmu.c                    |  97 ++------
>   arch/powerpc/include/asm/kvm_book3s.h  |  12 +-
>   arch/powerpc/include/asm/kvm_ppc.h     |   9 +-
>   arch/powerpc/kvm/book3s.c              |  18 +-
>   arch/powerpc/kvm/book3s.h              |  10 +-
>   arch/powerpc/kvm/book3s_64_mmu_hv.c    |  98 ++------
>   arch/powerpc/kvm/book3s_64_mmu_radix.c |  25 +-
>   arch/powerpc/kvm/book3s_hv.c           |  12 +-
>   arch/powerpc/kvm/book3s_pr.c           |  56 ++---
>   arch/powerpc/kvm/e500_mmu_host.c       |  27 +-
>   arch/x86/kvm/mmu/mmu.c                 | 127 ++++------
>   arch/x86/kvm/mmu/tdp_mmu.c             | 245 +++++++------------
>   arch/x86/kvm/mmu/tdp_mmu.h             |  14 +-
>   include/linux/kvm_host.h               |  22 +-
>   virt/kvm/kvm_main.c                    | 325 +++++++++++++++++++------
>   16 files changed, 552 insertions(+), 662 deletions(-)
> 

For MIPS, I am going to post a series that simplifies TLB flushing 
further.  I applied it, and rebased this one on top, to 
kvm/mmu-notifier-queue.

Architecture maintainers, please look at the branch and review/test/ack 
your parts.

Thanks!

Paolo



From ezequiel at collabora.com  Fri Apr  2 13:27:28 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Fri, 02 Apr 2021 09:27:28 -0300
Subject: [PATCH v8 09/13] media: uapi: Add a control for HANTRO driver
In-Reply-To: <20210401160003.88803-10-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
 <20210401160003.88803-10-benjamin.gaignard@collabora.com>
Message-ID: <5674859659f93ba547cad43528ac94ef145347b3.camel@collabora.com>

Hi Benjamin,

Thanks for the patch.

On Thu, 2021-04-01 at 17:59 +0200, Benjamin Gaignard wrote:
> The HEVC HANTRO driver needs to know the number of bits to skip at
> the beginning of the slice header.
> That is a hardware specific requirement so create a dedicated control
> that this purpose.
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> ---
> version 5:
> ?- Be even more verbose in control documentation.
> ?- Do not create class for the control.
> version 4:
> - The control is now an integer which is enough to provide the numbers
> ? of bits to skip.
> version 3:
> - Fix typo in field name
> 
> ?.../userspace-api/media/drivers/hantro.rst???????? | 14 ++++++++++++++
> ?.../userspace-api/media/drivers/index.rst????????? |? 1 +
> ?include/uapi/linux/v4l2-controls.h???????????????? | 13 +++++++++++++
> ?3 files changed, 28 insertions(+)
> ?create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
> 
> diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst
> new file mode 100644
> index 000000000000..78dcd2a44a03
> --- /dev/null
> +++ b/Documentation/userspace-api/media/drivers/hantro.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Hantro video decoder driver
> +===========================
> +
> +The Hantro video decoder driver implements the following driver-specific controls:
> +
> +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
> +??? Specifies to Hantro HEVC video decoder driver the number of data (in bits) to
> +??? skip in the slice segment header.
> +??? If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
> +??? to before syntax element "slice_temporal_mvp_enabled_flag".
> +??? If IDR, the skipped bits are just "pic_output_flag"
> +??? (separate_colour_plane_flag is not supported).
> diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
> index 1a9038f5f9fa..12e3c512d718 100644
> --- a/Documentation/userspace-api/media/drivers/index.rst
> +++ b/Documentation/userspace-api/media/drivers/index.rst
> @@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux.
> ?
> ????????ccs
> ????????cx2341x-uapi
> +??????? hantro
> ????????imx-uapi
> ????????max2175
> ????????meye-uapi
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index f3376aafea65..1dfb874b6272 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -869,6 +869,19 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> ?#define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC??????????????(V4L2_CID_CODEC_MFC51_BASE+53)
> ?#define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P???????????????(V4L2_CID_CODEC_MFC51_BASE+54)
> ?
> +/*? MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */

We are moving away from "MPEG" terminology for codecs.

> +#define V4L2_CID_CODEC_HANTRO_BASE?????????????????????????????(V4L2_CTRL_CLASS_CODEC | 0x1200)

Using V4L2_CTRL_CLASS_CODEC_STATELESS is IMO better,
since this belongs to a stateless decoder.

And also, since we are still a bit unsure about the
syntax of this parameter (given it's not documented):

how about keeping the V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP
definition in drivers/staging/media/hantro/hantro.h ?

This would be a hint for applications that this control
is a quirk.

Hans, Philipp, any thoughts on this?

Regards,
Ezequiel



From catalin.marinas at arm.com  Fri Apr  2 13:34:16 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 2 Apr 2021 13:34:16 +0100
Subject: Removed MTE function
In-Reply-To: <CAJoBWHz5GdRVnYAuvCkVxcx8qFEMnkmLToSy4Lwckg1LptHfpA@mail.gmail.com>
References: <CAJoBWHz5GdRVnYAuvCkVxcx8qFEMnkmLToSy4Lwckg1LptHfpA@mail.gmail.com>
Message-ID: <20210402123415.GA2830@arm.com>

On Fri, Apr 02, 2021 at 07:26:12AM -0400, Derrick McKee wrote:
> I was under the impression that MTE was mainlined in the kernel.
> However, the function mte_assign_mem_tag_range is not present in the
> 5.10 or later kernels.  Was it removed or just that functionality
> isn't ready yet?  If it was removed, why?  Thanks.

It was added in commit 85f49cae4dfc ("arm64: mte: add in-kernel MTE
helpers") in 5.11 but moved out of mte.S by commit 2cb34276427a ("arm64:
kasan: simplify and inline MTE functions") in 5.12 and renamed to
mte_set_mem_tag_range(). Unfortunately, that commit did not delete the
old function prototypes in mte.h. I'll clean it up next week, unless
someone beats me to it with a patch.

What do you need this function for? It's supposed to be used only by
kasan, hence moved to mte-kasan.h.

-- 
Catalin


From andrew at lunn.ch  Fri Apr  2 13:34:59 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 2 Apr 2021 14:34:59 +0200
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <SN6PR11MB3136F7A7ACA1A5C324031607887A9@SN6PR11MB3136.namprd11.prod.outlook.com>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
 <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
 <20210401151044.GZ1463@shell.armlinux.org.uk>
 <SN6PR11MB3136F7A7ACA1A5C324031607887A9@SN6PR11MB3136.namprd11.prod.outlook.com>
Message-ID: <YGcPc3dan0ocRSG2@lunn.ch>

On Fri, Apr 02, 2021 at 07:45:04AM +0000, Voon, Weifeng wrote:
> > > +	/* 2.5G mode only support 2500baseT full duplex only */
> > > +	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > > +		phylink_set(mac_supported, 2500baseT_Full);
> > > +		phylink_set(mask, 10baseT_Half);
> > > +		phylink_set(mask, 10baseT_Full);
> > > +		phylink_set(mask, 100baseT_Half);
> > > +		phylink_set(mask, 100baseT_Full);
> > > +		phylink_set(mask, 1000baseT_Half);
> > > +		phylink_set(mask, 1000baseT_Full);
> > > +		phylink_set(mask, 1000baseKX_Full);
> > 
> > Why? This seems at odds to the comment above?
> 
> > What about 2500baseX_Full ?
> 
> The comments explain that the PCS<->PHY link is in 2500BASE-X
> and why 10/100/1000 link speed is mutually exclusive with 2500.
> But the connected external PHY are twisted pair cable which only
> supports 2500baseT_full.

The PHY should indicate what modes its supports. The PHY drivers
get_features() call should set supported to only 2500baseT_Full, if
that is all it supports.

What modes are actually used should then be the intersect of what both
the MAC and the PHY indicate they can do.

     Andrew


From nicolas.ferre at microchip.com  Fri Apr  2 14:02:27 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Fri, 2 Apr 2021 15:02:27 +0200
Subject: [PATCH] ARM: dts: at91: change the key code of the gpio key
Message-ID: <20210402130227.21478-1-nicolas.ferre@microchip.com>

From: Ludovic Desroches <ludovic.desroches at microchip.com>

Having a button code and not a key code causes issues with libinput.
udev won't set ID_INPUT_KEY. If it is forced, then it causes a bug
within libinput.

Signed-off-by: Ludovic Desroches <ludovic.desroches at microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre at microchip.com>
---
 arch/arm/boot/dts/at91-sam9x60ek.dts          | 3 ++-
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts   | 3 ++-
 arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_icp.dts        | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts     | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_xplained.dts   | 3 ++-
 arch/arm/boot/dts/at91-sama5d3_xplained.dts   | 3 ++-
 arch/arm/boot/dts/at91sam9260ek.dts           | 3 ++-
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi   | 3 ++-
 9 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sam9x60ek.dts b/arch/arm/boot/dts/at91-sam9x60ek.dts
index 73b6b1f89de9..f68284cdff54 100644
--- a/arch/arm/boot/dts/at91-sam9x60ek.dts
+++ b/arch/arm/boot/dts/at91-sam9x60ek.dts
@@ -8,6 +8,7 @@
  */
 /dts-v1/;
 #include "sam9x60.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Microchip SAM9X60-EK";
@@ -84,7 +85,7 @@ gpio_keys {
 		sw1 {
 			label = "SW1";
 			gpios = <&pioD 18 GPIO_ACTIVE_LOW>;
-			linux,code=<0x104>;
+			linux,code=<KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 84e1180f3e89..a9e6fee55a2a 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -11,6 +11,7 @@
 #include "at91-sama5d27_som1.dtsi"
 #include <dt-bindings/mfd/atmel-flexcom.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Atmel SAMA5D27 SOM1 EK";
@@ -466,7 +467,7 @@ gpio_keys {
 		pb4 {
 			label = "USER";
 			gpios = <&pioA PIN_PA29 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
index 180a08765cb8..ff83967fd008 100644
--- a/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
@@ -8,6 +8,7 @@
  */
 /dts-v1/;
 #include "at91-sama5d27_wlsom1.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Microchip SAMA5D27 WLSOM1 EK";
@@ -35,7 +36,7 @@ gpio_keys {
 		sw4 {
 			label = "USER BUTTON";
 			gpios = <&pioA PIN_PB2 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 46722a163184..bd64721fa23c 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -12,6 +12,7 @@
 #include "sama5d2.dtsi"
 #include "sama5d2-pinfunc.h"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/mfd/atmel-flexcom.h>
 
 / {
@@ -51,7 +52,7 @@ gpio_keys {
 		sw4 {
 			label = "USER_PB1";
 			gpios = <&pioA PIN_PD0 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 8de57d164acd..dfd150eb0fd8 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -11,6 +11,7 @@
 #include "sama5d2-pinfunc.h"
 #include <dt-bindings/mfd/atmel-flexcom.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/pinctrl/at91.h>
 
 / {
@@ -402,7 +403,7 @@ gpio_keys {
 		bp1 {
 			label = "PB_USER";
 			gpios = <&pioA PIN_PA10 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 4e7cf21f124c..509c732a0d8b 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -10,6 +10,7 @@
 #include "sama5d2-pinfunc.h"
 #include <dt-bindings/mfd/atmel-flexcom.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/regulator/active-semi,8945a-regulator.h>
 
 / {
@@ -712,7 +713,7 @@ gpio_keys {
 		bp1 {
 			label = "PB_USER";
 			gpios = <&pioA PIN_PB9 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 5179258f9247..9c55a921263b 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -7,6 +7,7 @@
  */
 /dts-v1/;
 #include "sama5d36.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "SAMA5D3 Xplained";
@@ -354,7 +355,7 @@ gpio_keys {
 		bp3 {
 			label = "PB_USER";
 			gpios = <&pioE 29 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
index d3446e42b598..ce96345d28a3 100644
--- a/arch/arm/boot/dts/at91sam9260ek.dts
+++ b/arch/arm/boot/dts/at91sam9260ek.dts
@@ -7,6 +7,7 @@
  */
 /dts-v1/;
 #include "at91sam9260.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "Atmel at91sam9260ek";
@@ -156,7 +157,7 @@ btn3 {
 		btn4 {
 			label = "Button 4";
 			gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
diff --git a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
index 6e6e672c0b86..87bb39060e8b 100644
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
@@ -5,6 +5,7 @@
  * Copyright (C) 2012 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
  */
 #include "at91sam9g20.dtsi"
+#include <dt-bindings/input/input.h>
 
 / {
 
@@ -234,7 +235,7 @@ btn3 {
 		btn4 {
 			label = "Button 4";
 			gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
-			linux,code = <0x104>;
+			linux,code = <KEY_PROG1>;
 			wakeup-source;
 		};
 	};
-- 
2.31.1



From mripard at kernel.org  Fri Apr  2 14:36:33 2021
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 2 Apr 2021 15:36:33 +0200
Subject: [GIT PULL] Allwinner Fixes for 5.12
Message-ID: <9df637a0-945e-4469-8e6d-0903cc9d3196.lettre@localhost>

Hi Arnd, Olof,

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.12

for you to fetch changes up to a3797571964d80ff3abebb1cd5047d4ae6d8db4e:

  arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference (2021-04-01 10:22:33 +0200)

----------------------------------------------------------------
One 32kHz clock fix for the beelink gs1, a CD polarity fix for the SoPine, some
MAINTAINERS maintainance, and a clk / reset switch to our headers.

----------------------------------------------------------------
Andre Przywara (1):
      arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems

Chen-Yu Tsai (1):
      arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices

Jernej Skrabec (1):
      arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference

Maxime Ripard (2):
      MAINTAINERS: Add our new mailing-list
      MAINTAINERS: Match on allwinner keyword


 MAINTAINERS                                             | 2 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 4 ++++
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi    | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ----
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi            | 4 ++--
 5 files changed, 9 insertions(+), 7 deletions(-)


-------------- 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/20210402/46c1ce19/attachment.sig>

From mripard at kernel.org  Fri Apr  2 14:52:36 2021
From: mripard at kernel.org (Maxime Ripard)
Date: Fri, 2 Apr 2021 15:52:36 +0200
Subject: [GIT PULL] Allwinner Device Tree Changes for 5.13
Message-ID: <8a3e3271-bebe-4d27-a9e7-7b7a6311a38d.lettre@localhost>

Hi Arnd, Olof,

Please pull the following changes for the next release.

Thanks!
Maxime

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-dt-for-5.13-1

for you to fetch changes up to d580e6f0ec3ab42e81f3825ef4438836ead88c5f:

  ARM: dts: sun8i: h3: beelink-x2: Add power button (2021-03-24 10:25:37 +0100)

----------------------------------------------------------------
Our usual bunch of patches to support the Allwinner SoCs, this time
adding:
  - New secondary interrupt controller binding to support the wake-up 
  - Use the RSB bus instead of I2C for the PMIC on the H6
  - HDMI support for the BananaPi M2-Zero
  - New board: Topwise A721

----------------------------------------------------------------
Jernej Skrabec (1):
      ARM: dts: sun8i: h3: beelink-x2: Add power button

Pascal Roeleven (2):
      dt-bindings: arm: Add Topwise A721
      ARM: dts: sun4i: Add support for Topwise A721 tablet

Pieter Beers (1):
      ARM: dts: sunxi: h2-plus-bananapi-m2-zero: Add HDMI out

Samuel Holland (6):
      ARM: dts: sunxi: Use the new r_intc binding
      ARM: dts: sunxi: h3/h5: Add r_intc node
      ARM: dts: sunxi: Move wakeup-capable IRQs to r_intc
      arm64: dts: allwinner: Use the new r_intc binding
      arm64: dts: allwinner: Move wakeup-capable IRQs to r_intc
      arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection


 Documentation/devicetree/bindings/arm/sunxi.yaml           |   5 +-
 arch/arm/boot/dts/Makefile                                 |   3 +-
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts               | 242 ++++++++++++++-
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts                |   2 +-
 arch/arm/boot/dts/sun6i-a31-m9.dts                         |   2 +-
 arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts           |   2 +-
 arch/arm/boot/dts/sun6i-a31.dtsi                           |   6 +-
 arch/arm/boot/dts/sun6i-a31s-primo81.dts                   |   2 +-
 arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi             |   2 +-
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts           |   2 +-
 arch/arm/boot/dts/sun6i-a31s-yones-toptech-bs1078-v2.dts   |   2 +-
 arch/arm/boot/dts/sun6i-reference-design-tablet.dtsi       |   2 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi                       |   6 +-
 arch/arm/boot/dts/sun8i-a33-olinuxino.dts                  |   2 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts             |   2 +-
 arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts     |   4 +-
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts               |   4 +-
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts           |   4 +-
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts                  |   4 +-
 arch/arm/boot/dts/sun8i-a83t.dtsi                          |   5 +-
 arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts       |  25 +-
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts                  |  11 +-
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts               |   2 +-
 arch/arm/boot/dts/sun8i-r16-parrot.dts                     |   2 +-
 arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi       |   2 +-
 arch/arm/boot/dts/sunxi-h3-h5.dtsi                         |  12 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts  |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts    |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts     |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts  |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts        |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts      |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi    |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts       |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi       |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts       |   2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi              |   6 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts    |  40 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts     |  16 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi      |  24 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts       |   4 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi               |   8 +-
 43 files changed, 395 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts


-------------- 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/20210402/aa56fc18/attachment.sig>

From lkp at intel.com  Fri Apr  2 15:01:34 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 2 Apr 2021 22:01:34 +0800
Subject: [xlnx:xlnx_rebase_v5.4 19/1701] include/linux/mtd/rawnand.h:1294:16:
 sparse: sparse: cast to restricted __le16
Message-ID: <202104022231.JYanxEYH-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   8540825db3d5519ef205a710515b7819b95eeb4f
commit: 1dea215e98f470c4fabe230cb5dcb648e3301fb9 [19/1701] mtd: rawnand: Add support for ARASAN NAND controller
config: x86_64-randconfig-s021-20210401 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-279-g6d5d9b42-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/1dea215e98f470c4fabe230cb5dcb648e3301fb9
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 1dea215e98f470c4fabe230cb5dcb648e3301fb9
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/mtd/nand/raw/arasan_nand.c: note: in included file:
>> include/linux/mtd/rawnand.h:1294:16: sparse: sparse: cast to restricted __le16

vim +1294 include/linux/mtd/rawnand.h

cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1287  
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1288  /* return the supported synchronous timing mode. */
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1289  static inline int onfi_get_sync_timing_mode(struct nand_chip *chip)
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1290  {
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1291  	if (!chip->parameters.onfi)
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1292  		return ONFI_TIMING_MODE_UNKNOWN;
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1293  
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05 @1294  	return le16_to_cpu(chip->parameters.onfi->src_sync_timing_mode);
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1295  }
cbb56fde78b2f2 Naga Sureshkumar Relli 2019-12-05  1296  

:::::: The code at line 1294 was first introduced by commit
:::::: cbb56fde78b2f2617856523a561f10102c622c8f mtd: rawnand: Add sync and async timing mode support

:::::: TO: Naga Sureshkumar Relli <naga.sureshkumar.relli at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39327 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210402/f683f73f/attachment-0001.gz>

From daniel.lezcano at linaro.org  Fri Apr  2 15:15:13 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 2 Apr 2021 16:15:13 +0200
Subject: [PATCH v2] drivers/clocksource/mediatek: Ack and disable
 interrupts on shutdown
In-Reply-To: <CAP8nV8rv6bKARZ31fVqcjVgMe+5UyVG8UAyNsm1hDCP2BbRSgw@mail.gmail.com>
References: <20210325123446.v2.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid>
 <049946ac-5263-21ee-9651-7295f0bcf387@linaro.org>
 <CAP8nV8rv6bKARZ31fVqcjVgMe+5UyVG8UAyNsm1hDCP2BbRSgw@mail.gmail.com>
Message-ID: <67eed9a2-2b97-be1b-3290-948da662ea65@linaro.org>


Hi Evan,

On 27/03/2021 02:31, Evan Benn wrote:
> Hi Daniel,
> 
> That is a good point, and I did try that at first and it works fine. I
> uploaded this version because the suspend/resume callbacks were
> undocumented and mostly not used by other clocksource drivers. I
> thought a smaller diff might be preferable.
> I also thought it would be better to shut off the interrupt as soon as
> it is not needed, avoiding any other potential bugs, instead of just
> fixing the one we know about with suspend. I'm not sure how the other
> driver / timer disable flows are intended to work for example
> (shutdown, detach, etc).
> 
> That said I am happy to upload that version if people think it is better.

IMO, it is not in the normal flow to disable/enable the interrupts.

Does this timer belong to an always-on power domain ?



> https://elixir.bootlin.com/linux/latest/source/include/linux/clockchips.h#L120
> 
> 
> On Thu, 25 Mar 2021 at 19:10, Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
>>
>> On 25/03/2021 02:35, Evan Benn wrote:
>>> set_state_shutdown is called during system suspend after interrupts have
>>> been disabled. If the timer has fired in the meantime, there will be
>>> a pending IRQ. So we ack that now and disable the timer. Without this
>>> ARM trusted firmware will abort the suspend due to the pending
>>> interrupt.


>>> Now always disable the IRQ in state transitions, and re-enable in
>>> set_periodic and next_event.
>>
>> Why not put add the suspend/resume callbacks and put there the specific
>> code and let the irq untouched in the normal flow ?
>>
>>> Signed-off-by: Evan Benn <evanbenn at chromium.org>
>>> ---
>>>
>>> Changes in v2:
>>> Remove the patch that splits the drivers into 2 files.
>>>
>>>  drivers/clocksource/timer-mediatek.c | 49 +++++++++++++++++-----------
>>>  1 file changed, 30 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
>>> index 9318edcd8963..fba2f9494d90 100644
>>> --- a/drivers/clocksource/timer-mediatek.c
>>> +++ b/drivers/clocksource/timer-mediatek.c
>>> @@ -132,13 +132,33 @@ static u64 notrace mtk_gpt_read_sched_clock(void)
>>>       return readl_relaxed(gpt_sched_reg);
>>>  }
>>>
>>> +static void mtk_gpt_disable_ack_interrupts(struct timer_of *to, u8 timer)
>>> +{
>>> +     u32 val;
>>> +
>>> +     /* Disable interrupts */
>>> +     val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
>>> +     writel(val & ~GPT_IRQ_ENABLE(timer), timer_of_base(to) +
>>> +            GPT_IRQ_EN_REG);
>>> +
>>> +     /* Ack interrupts */
>>> +     writel(GPT_IRQ_ACK(timer), timer_of_base(to) + GPT_IRQ_ACK_REG);
>>> +}
>>> +
>>>  static void mtk_gpt_clkevt_time_stop(struct timer_of *to, u8 timer)
>>>  {
>>>       u32 val;
>>>
>>> +     /* Disable timer */
>>>       val = readl(timer_of_base(to) + GPT_CTRL_REG(timer));
>>>       writel(val & ~GPT_CTRL_ENABLE, timer_of_base(to) +
>>>              GPT_CTRL_REG(timer));
>>> +
>>> +     /* This may be called with interrupts disabled,
>>> +      * so we need to ack any interrupt that is pending
>>> +      * Or for example ATF will prevent a suspend from completing.
>>> +      */
>>> +     mtk_gpt_disable_ack_interrupts(to, timer);
>>>  }
>>>
>>>  static void mtk_gpt_clkevt_time_setup(struct timer_of *to,
>>> @@ -152,8 +172,10 @@ static void mtk_gpt_clkevt_time_start(struct timer_of *to,
>>>  {
>>>       u32 val;
>>>
>>> -     /* Acknowledge interrupt */
>>> -     writel(GPT_IRQ_ACK(timer), timer_of_base(to) + GPT_IRQ_ACK_REG);
>>> +     /* Enable interrupts */
>>> +     val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
>>> +     writel(val | GPT_IRQ_ENABLE(timer),
>>> +            timer_of_base(to) + GPT_IRQ_EN_REG);
>>>
>>>       val = readl(timer_of_base(to) + GPT_CTRL_REG(timer));
>>>
>>> @@ -226,21 +248,6 @@ __init mtk_gpt_setup(struct timer_of *to, u8 timer, u8 option)
>>>              timer_of_base(to) + GPT_CTRL_REG(timer));
>>>  }
>>>
>>> -static void mtk_gpt_enable_irq(struct timer_of *to, u8 timer)
>>> -{
>>> -     u32 val;
>>> -
>>> -     /* Disable all interrupts */
>>> -     writel(0x0, timer_of_base(to) + GPT_IRQ_EN_REG);
>>> -
>>> -     /* Acknowledge all spurious pending interrupts */
>>> -     writel(0x3f, timer_of_base(to) + GPT_IRQ_ACK_REG);
>>> -
>>> -     val = readl(timer_of_base(to) + GPT_IRQ_EN_REG);
>>> -     writel(val | GPT_IRQ_ENABLE(timer),
>>> -            timer_of_base(to) + GPT_IRQ_EN_REG);
>>> -}
>>> -
>>>  static struct timer_of to = {
>>>       .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
>>>
>>> @@ -292,6 +299,12 @@ static int __init mtk_gpt_init(struct device_node *node)
>>>       if (ret)
>>>               return ret;
>>>
>>> +     /* In case the firmware left the interrupts enabled
>>> +      * disable and ack those now
>>> +      */
>>> +     mtk_gpt_disable_ack_interrupts(&to, TIMER_CLK_SRC);
>>> +     mtk_gpt_disable_ack_interrupts(&to, TIMER_CLK_EVT);
>>> +
>>>       /* Configure clock source */
>>>       mtk_gpt_setup(&to, TIMER_CLK_SRC, GPT_CTRL_OP_FREERUN);
>>>       clocksource_mmio_init(timer_of_base(&to) + GPT_CNT_REG(TIMER_CLK_SRC),
>>> @@ -305,8 +318,6 @@ static int __init mtk_gpt_init(struct device_node *node)
>>>       clockevents_config_and_register(&to.clkevt, timer_of_rate(&to),
>>>                                       TIMER_SYNC_TICKS, 0xffffffff);
>>>
>>> -     mtk_gpt_enable_irq(&to, TIMER_CLK_EVT);
>>> -
>>>       return 0;
>>>  }
>>>  TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
>>>
>>
>>
>> --
>> <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


-- 
<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 minyard at acm.org  Fri Apr  2 15:21:24 2021
From: minyard at acm.org (Corey Minyard)
Date: Fri, 2 Apr 2021 09:21:24 -0500
Subject: [PATCH v2 0/3] Add Aspeed SSIF BMC driver
In-Reply-To: <20210330141029.20412-1-quan@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
Message-ID: <20210402142124.GV507977@minyard.net>

On Tue, Mar 30, 2021 at 09:10:26PM +0700, Quan Nguyen wrote:
> This series add support for the Aspeed specific SSIF BMC driver which
> is to perform in-band IPMI communication with the host in management
> (BMC) side.

I don't have any specific feedback for this, but I'm wondering if it's
really necessary.

Why can't the BMC just open the I2C device and use it?  Is there any
functionality that this provides that cannot be accomplished from
userland access to the I2C device?  I don't see any.

If it tied into some existing framework to give abstract access to a BMC
slave side interface, I'd be ok with this.  But I don't see that.

Unless there is a big need to have this in the kernel, I'm against
including this and would suggest you do all this work in userland.
Perhaps write a library.  Sorry, but I'm trying to do my part to reduce
unnecessary things in the kernel.

Thanks,

-corey

> 
> v2:
>   + Fixed compiling error with COMPILE_TEST for arc
> 
> Quan Nguyen (3):
>   i2c: i2c-core-smbus: Expose PEC calculate function for generic use
>   drivers: char: ipmi: Add Aspeed SSIF BMC driver
>   bindings: ipmi: Add binding for Aspeed SSIF BMC driver
> 
>  .../bindings/ipmi/aspeed-ssif-bmc.txt         |  18 +
>  drivers/char/ipmi/Kconfig                     |  22 +
>  drivers/char/ipmi/Makefile                    |   2 +
>  drivers/char/ipmi/ssif_bmc.c                  | 645 ++++++++++++++++++
>  drivers/char/ipmi/ssif_bmc.h                  |  92 +++
>  drivers/char/ipmi/ssif_bmc_aspeed.c           | 132 ++++
>  drivers/i2c/i2c-core-smbus.c                  |  12 +-
>  include/linux/i2c.h                           |   1 +
>  8 files changed, 922 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-ssif-bmc.txt
>  create mode 100644 drivers/char/ipmi/ssif_bmc.c
>  create mode 100644 drivers/char/ipmi/ssif_bmc.h
>  create mode 100644 drivers/char/ipmi/ssif_bmc_aspeed.c
> 
> -- 
> 2.28.0
> 


From trix at redhat.com  Fri Apr  2 15:35:53 2021
From: trix at redhat.com (Tom Rix)
Date: Fri, 2 Apr 2021 07:35:53 -0700
Subject: [PATCH RFC 0/3] Adds support to allow the bitstream configuration
 from pre-allocated dma-buffer
In-Reply-To: <20210402090933.32276-1-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
Message-ID: <979ebb17-bc76-e0ef-10b4-996edc12dfa3@redhat.com>

Please add to this patch cover letter what you want to discuss.

Got this new feature, not sure about ...

Tom

On 4/2/21 2:09 AM, Nava kishore Manne wrote:
> Nava kishore Manne (3):
>   fpga: region: Add fpga-region property 'fpga-config-from-dmabuf'
>   fpga: support loading from a pre-allocated buffer
>   fpga: zynqmp: Use the scatterlist interface
>
>  .../devicetree/bindings/fpga/fpga-region.txt  |   2 +
>  drivers/fpga/fpga-mgr.c                       | 126 +++++++++++++++++-
>  drivers/fpga/of-fpga-region.c                 |   3 +
>  drivers/fpga/zynqmp-fpga.c                    |  35 +++++
>  include/linux/fpga/fpga-mgr.h                 |   6 +-
>  5 files changed, 169 insertions(+), 3 deletions(-)
>



From seanjc at google.com  Fri Apr  2 15:59:18 2021
From: seanjc at google.com (Sean Christopherson)
Date: Fri, 2 Apr 2021 14:59:18 +0000
Subject: [PATCH v2 09/10] KVM: Don't take mmu_lock for range invalidation
 unless necessary
In-Reply-To: <417bd6b5-b7d0-ed22-adae-02150cdbfebe@redhat.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-10-seanjc@google.com>
 <417bd6b5-b7d0-ed22-adae-02150cdbfebe@redhat.com>
Message-ID: <YGcxRmzbEr3kPsWE@google.com>

On Fri, Apr 02, 2021, Paolo Bonzini wrote:
> On 02/04/21 02:56, Sean Christopherson wrote:
> > Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
> > notifications.  Because mmu_notifier_count must be modified while holding
> > mmu_lock for write, and must always be paired across start->end to stay
> > balanced, lock elision must happen in both or none.  To meet that
> > requirement, add a rwsem to prevent memslot updates across range_start()
> > and range_end().
> > 
> > Use a rwsem instead of a rwlock since most notifiers _allow_ blocking,
> > and the lock will be endl across the entire start() ... end() sequence.
> > If anything in the sequence sleeps, including the caller or a different
> > notifier, holding the spinlock would be disastrous.
> > 
> > For notifiers that _disallow_ blocking, e.g. OOM reaping, simply go down
> > the slow path of unconditionally acquiring mmu_lock.  The sane
> > alternative would be to try to acquire the lock and force the notifier
> > to retry on failure.  But since OOM is currently the _only_ scenario
> > where blocking is disallowed attempting to optimize a guest that has been
> > marked for death is pointless.
> > 
> > Unconditionally define and use mmu_notifier_slots_lock in the memslots
> > code, purely to avoid more #ifdefs.  The overhead of acquiring the lock
> > is negligible when the lock is uncontested, which will always be the case
> > when the MMU notifiers are not used.
> > 
> > Note, technically flag-only memslot updates could be allowed in parallel,
> > but stalling a memslot update for a relatively short amount of time is
> > not a scalability issue, and this is all more than complex enough.
> 
> Proposal for the locking documentation:

Argh, sorry!  Looks great, I owe you.

> diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
> index b21a34c34a21..3e4ad7de36cb 100644
> --- a/Documentation/virt/kvm/locking.rst
> +++ b/Documentation/virt/kvm/locking.rst
> @@ -16,6 +16,13 @@ The acquisition orders for mutexes are as follows:
>  - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
>    them together is quite rare.
> +- The kvm->mmu_notifier_slots_lock rwsem ensures that pairs of
> +  invalidate_range_start() and invalidate_range_end() callbacks
> +  use the same memslots array.  kvm->slots_lock is taken outside the
> +  write-side critical section of kvm->mmu_notifier_slots_lock, so
> +  MMU notifiers must not take kvm->slots_lock.  No other write-side
> +  critical sections should be added.
> +
>  On x86, vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock.
>  Everything else is a leaf: no other lock is taken inside the critical
> 
> Paolo
> 


From seanjc at google.com  Fri Apr  2 15:59:42 2021
From: seanjc at google.com (Sean Christopherson)
Date: Fri, 2 Apr 2021 14:59:42 +0000
Subject: [PATCH v2 07/10] KVM: Move MMU notifier's mmu_lock acquisition
 into common helper
In-Reply-To: <a30f556a-40b2-f703-f0ee-b985989ee4b7@redhat.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-8-seanjc@google.com>
 <a30f556a-40b2-f703-f0ee-b985989ee4b7@redhat.com>
Message-ID: <YGcxXvrluFJ+7o9X@google.com>

On Fri, Apr 02, 2021, Paolo Bonzini wrote:
> On 02/04/21 02:56, Sean Christopherson wrote:
> > +		.handler	= (void *)kvm_null_fn,
> > +		.on_lock	= kvm_dec_notifier_count,
> > +		.flush_on_ret	= true,
> 
> Doesn't really matter since the handler is null, but I think it's cleaner to
> have false here.

Agreed.


From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:03 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:03 +0000 (UTC)
Subject: [PATCH v4 02/20] drivers: of: use cmdline building function
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <b39c6cfefe9c8391a64ebfca3ae39fcc49e5c607.1617375802.git.christophe.leroy@csgroup.eu>

This patch uses the new cmdline building function to
concatenate the of provided cmdline with built-in parts
based on compile-time options.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 drivers/of/fdt.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..7c5e9fb6039b 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
 #include <linux/serial_core.h>
 #include <linux/sysfs.h>
 #include <linux/random.h>
+#include <linux/cmdline.h>
 
 #include <asm/setup.h>  /* for COMMAND_LINE_SIZE */
 #include <asm/page.h>
@@ -1050,26 +1051,10 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 
 	/* Retrieve command line */
 	p = of_get_flat_dt_prop(node, "bootargs", &l);
-	if (p != NULL && l > 0)
-		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
+	if (l <= 0)
+		p = NULL;
 
-	/*
-	 * CONFIG_CMDLINE is meant to be a default in case nothing else
-	 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
-	 * is set in which case we override whatever was found earlier.
-	 */
-#ifdef CONFIG_CMDLINE
-#if defined(CONFIG_CMDLINE_EXTEND)
-	strlcat(data, " ", COMMAND_LINE_SIZE);
-	strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
-	strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
-	/* No arguments from boot loader, use kernel's  cmdl*/
-	if (!((char *)data)[0])
-		strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif /* CONFIG_CMDLINE */
+	cmdline_build(data, p);
 
 	pr_debug("Command line is: %s\n", (char *)data);
 
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:05 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:05 +0000 (UTC)
Subject: [PATCH v4 04/20] drivers: firmware: efi: use cmdline building function
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <13fb0995a91bdbce71812794d28cb29070daf51e.1617375802.git.christophe.leroy@csgroup.eu>

Use cmdline building function in EFI.

EFI cannot use pr_err() and doesn't have a .init.data section,
so use the __cmdline_build() internal function and provides
both a source and a destination.

Remove the handling of too long command lines as it is handled
by the generic CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4: New
---
 .../firmware/efi/libstub/efi-stub-helper.c    | 35 ++++++++++---------
 drivers/firmware/efi/libstub/efi-stub.c       | 23 +++---------
 drivers/firmware/efi/libstub/efistub.h        |  2 +-
 drivers/firmware/efi/libstub/x86-stub.c       | 18 +++-------
 4 files changed, 29 insertions(+), 49 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aa8da0a49829..9f60d471d650 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -13,6 +13,7 @@
 #include <linux/efi.h>
 #include <linux/kernel.h>
 #include <linux/printk.h> /* For CONSOLE_LOGLEVEL_* */
+#include <linux/cmdline.h>
 #include <asm/efi.h>
 #include <asm/setup.h>
 
@@ -339,13 +340,13 @@ void efi_apply_loadoptions_quirk(const void **load_options, int *load_options_si
  * Size of memory allocated return in *cmd_line_len.
  * Returns NULL on error.
  */
-char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
+char *efi_convert_cmdline(efi_loaded_image_t *image)
 {
 	const u16 *s2;
-	unsigned long cmdline_addr = 0;
+	unsigned long cmdline_addr = 0, options_addr = 0;
 	int options_chars = efi_table_attr(image, load_options_size);
 	const u16 *options = efi_table_attr(image, load_options);
-	int options_bytes = 0, safe_options_bytes = 0;  /* UTF-8 bytes */
+	int options_bytes = 0;  /* UTF-8 bytes */
 	bool in_quote = false;
 	efi_status_t status;
 
@@ -354,16 +355,12 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
 
 	if (options) {
 		s2 = options;
-		while (options_bytes < COMMAND_LINE_SIZE && options_chars--) {
+		while (options_chars--) {
 			u16 c = *s2++;
 
 			if (c < 0x80) {
 				if (c == L'\0' || c == L'\n')
 					break;
-				if (c == L'"')
-					in_quote = !in_quote;
-				else if (!in_quote && isspace((char)c))
-					safe_options_bytes = options_bytes;
 
 				options_bytes++;
 				continue;
@@ -395,24 +392,30 @@ char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len)
 				}
 			}
 		}
-		if (options_bytes >= COMMAND_LINE_SIZE) {
-			options_bytes = safe_options_bytes;
-			efi_err("Command line is too long: truncated to %d bytes\n",
-				options_bytes);
-		}
 	}
 
 	options_bytes++;	/* NUL termination */
 
 	status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, options_bytes,
-			     (void **)&cmdline_addr);
+			     (void **)&options_addr);
 	if (status != EFI_SUCCESS)
 		return NULL;
 
-	snprintf((char *)cmdline_addr, options_bytes, "%.*ls",
+	snprintf((char *)options_addr, options_bytes, "%.*ls",
 		 options_bytes - 1, options);
 
-	*cmd_line_len = options_bytes;
+	status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, COMMAND_LINE_SIZE,
+			     (void **)&cmdline_addr);
+	if (status != EFI_SUCCESS) {
+		efi_bs_call(free_pool, (void *)options_addr);
+		return NULL;
+	}
+
+	if (!__cmdline_build((char *)cmdline_addr, (char *)options_addr))
+		efi_err("Command line is too long\n");
+
+	efi_bs_call(free_pool, (void *)cmdline_addr);
+
 	return (char *)cmdline_addr;
 }
 
diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c
index 26e69788f27a..b79ee76f2e95 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -127,7 +127,6 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	unsigned long fdt_addr = 0;  /* Original DTB */
 	unsigned long fdt_size = 0;
 	char *cmdline_ptr = NULL;
-	int cmdline_size = 0;
 	efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
 	unsigned long reserve_addr = 0;
 	unsigned long reserve_size = 0;
@@ -165,29 +164,17 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	 * protocol. We are going to copy the command line into the
 	 * device tree, so this can be allocated anywhere.
 	 */
-	cmdline_ptr = efi_convert_cmdline(image, &cmdline_size);
+	cmdline_ptr = efi_convert_cmdline(image);
 	if (!cmdline_ptr) {
 		efi_err("getting command line via LOADED_IMAGE_PROTOCOL\n");
 		status = EFI_OUT_OF_RESOURCES;
 		goto fail;
 	}
 
-	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
-	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
-	    cmdline_size == 0) {
-		status = efi_parse_options(CONFIG_CMDLINE);
-		if (status != EFI_SUCCESS) {
-			efi_err("Failed to parse options\n");
-			goto fail_free_cmdline;
-		}
-	}
-
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0) {
-		status = efi_parse_options(cmdline_ptr);
-		if (status != EFI_SUCCESS) {
-			efi_err("Failed to parse options\n");
-			goto fail_free_cmdline;
-		}
+	status = efi_parse_options(cmdline_ptr);
+	if (status != EFI_SUCCESS) {
+		efi_err("Failed to parse options\n");
+		goto fail_free_cmdline;
 	}
 
 	efi_info("Booting Linux Kernel...\n");
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index cde0a2ef507d..2f872c48b20b 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -780,7 +780,7 @@ void efi_free(unsigned long size, unsigned long addr);
 
 void efi_apply_loadoptions_quirk(const void **load_options, int *load_options_size);
 
-char *efi_convert_cmdline(efi_loaded_image_t *image, int *cmd_line_len);
+char *efi_convert_cmdline(efi_loaded_image_t *image);
 
 efi_status_t efi_get_memory_map(struct efi_boot_memmap *map);
 
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 28659276b6ba..0f6a33149ef7 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -359,7 +359,6 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	struct setup_header *hdr;
 	void *image_base;
 	efi_guid_t proto = LOADED_IMAGE_PROTOCOL_GUID;
-	int options_size = 0;
 	efi_status_t status;
 	char *cmdline_ptr;
 
@@ -404,7 +403,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
 	hdr->type_of_loader = 0x21;
 
 	/* Convert unicode cmdline to ascii */
-	cmdline_ptr = efi_convert_cmdline(image, &options_size);
+	cmdline_ptr = efi_convert_cmdline(image);
 	if (!cmdline_ptr)
 		goto fail;
 
@@ -674,6 +673,8 @@ unsigned long efi_main(efi_handle_t handle,
 	unsigned long buffer_start, buffer_end;
 	struct setup_header *hdr = &boot_params->hdr;
 	efi_status_t status;
+	unsigned long cmdline_paddr = ((u64)hdr->cmd_line_ptr |
+				       ((u64)boot_params->ext_cmd_line_ptr << 32));
 
 	efi_system_table = sys_table_arg;
 
@@ -735,22 +736,11 @@ unsigned long efi_main(efi_handle_t handle,
 		image_offset = 0;
 	}
 
-#ifdef CONFIG_CMDLINE_BOOL
-	status = efi_parse_options(CONFIG_CMDLINE);
+	status = efi_parse_options((char *)cmdline_paddr);
 	if (status != EFI_SUCCESS) {
 		efi_err("Failed to parse options\n");
 		goto fail;
 	}
-#endif
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
-		unsigned long cmdline_paddr = ((u64)hdr->cmd_line_ptr |
-					       ((u64)boot_params->ext_cmd_line_ptr << 32));
-		status = efi_parse_options((char *)cmdline_paddr);
-		if (status != EFI_SUCCESS) {
-			efi_err("Failed to parse options\n");
-			goto fail;
-		}
-	}
 
 	/*
 	 * At this point, an initrd may already have been loaded by the
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:02 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:02 +0000 (UTC)
Subject: [PATCH v4 01/20] cmdline: Add generic function to build command line.
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <68db4e57bb88c523f76dcae12feafbb0cae1a85d.1617375802.git.christophe.leroy@csgroup.eu>

This code provides architectures with a way to build command line
based on what is built in the kernel and what is handed over by the
bootloader, based on selected compile-time options.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v3:
- Addressed comments from Will
- Added capability to have src == dst
v4:
- Add cmdline_strlcpy()
- Removed cmdline_build() macro, __cmdline_build() becomes cmdline_build()
- Fixed the destination length to COMMAND_LINE_SIZE
- Truncate at a space not in a quote when too long
- Added a message when forcing the command line
---
 include/linux/cmdline.h | 79 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 include/linux/cmdline.h

diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index 000000000000..a0773dc365c7
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+#include <linux/string.h>
+#include <linux/printk.h>
+#include <asm/setup.h>
+
+/* Allow users to override strlcat/strlcpy, powerpc can't use strings so early*/
+#ifndef cmdline_strlcat
+#define cmdline_strlcat strlcat
+#define cmdline_strlcpy strlcpy
+#endif
+
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dst: The destination of the final command line (Min. size COMMAND_LINE_SIZE)
+ * @src: The starting string or NULL if there isn't one. Must not equal dst.
+ * Returns: false if the string was truncated, true otherwise
+ */
+static __always_inline bool __cmdline_build(char *dst, const char *src)
+{
+	int len;
+	char *ptr, *last_space;
+	bool in_quote = false;
+
+	if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
+		src = NULL;
+
+	dst[0] = 0;
+
+	if (IS_ENABLED(CONFIG_CMDLINE_PREPEND))
+		len = cmdline_strlcat(dst, CONFIG_CMDLINE " ", COMMAND_LINE_SIZE);
+
+	len = cmdline_strlcat(dst, src, COMMAND_LINE_SIZE);
+
+	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
+		len = cmdline_strlcat(dst, " " CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+
+	if (len < COMMAND_LINE_SIZE - 1)
+		return true;
+
+	for (ptr = dst; *ptr; ptr++) {
+		if (*ptr == '"')
+			in_quote = !in_quote;
+		if (*ptr == ' ' && !in_quote)
+			last_space = ptr;
+	}
+	if (last_space)
+		*last_space = 0;
+
+	return false;
+}
+
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dst: The destination of the final command line (Min. size COMMAND_LINE_SIZE)
+ * @src: The starting string or NULL if there isn't one.
+ */
+static __always_inline void cmdline_build(char *dst, const char *src)
+{
+	static char tmp[COMMAND_LINE_SIZE] __initdata;
+
+	if (src == dst) {
+		cmdline_strlcpy(tmp, src, COMMAND_LINE_SIZE);
+		src = tmp;
+	}
+	if (!__cmdline_build(dst, src))
+		pr_warn("Command line is too long, it has been truncated\n");
+
+	if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
+		pr_info("Forcing kernel command line to: %s\n", dst);
+}
+
+#endif /* _LINUX_CMDLINE_H */
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:01 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:01 +0000 (UTC)
Subject: [PATCH v4 00/20] Implement GENERIC_CMDLINE
Message-ID: <cover.1617375802.git.christophe.leroy@csgroup.eu>

The purpose of this series is to improve and enhance the
handling of kernel boot arguments.

Current situation is that most if not all architectures are using
similar options to do some manupulation on command line arguments:
- Prepend built-in arguments in front of bootloader provided arguments
- Append built-in arguments after bootloader provided arguments
- Replace bootloader provided arguments by built-in arguments
- Use built-in arguments when none is provided by bootloader.

On some architectures, all the options are possible. On other ones,
only a subset are available.

The purpose of this series is to refactor and enhance the
handling of kernel boot arguments so that every architecture can
benefit from all possibilities.

It is first focussed on powerpc but also extends the capability
for other arches.

The work has been focussed on minimising the churn in architectures
by keeping the most commonly used namings.

Main changes in V4:
- Included patch from Daniel to replace powerpc's strcpy() by strlcpy()
- Using strlcpy() instead of zeroing first char + strlcat() (idea taken frm Daniel's series)
- Reworked the convertion of EFI which was wrong in V3
- Added "too long" command line handling
- Changed cmdline macro into a function
- Done a few fixes in arch (NIOS2, SH, ARM)
- Taken comments into account (see individual responses for details)
- Tested on powerpc, build tested on ARM64, X86_64.

Main changes in V3:
- Also accept destination equal to source in cmdline_build() by setting a tmp buffer in __initdata. Powerpc provides different source and destination and call __cmdline_build() directly.
- Taken comments received from Will and Rob
- Converted all architectures (Only tested on powerpc)

Christophe Leroy (19):
  cmdline: Add generic function to build command line.
  drivers: of: use cmdline building function
  x86/efi: Replace CONFIG_CMDLINE_OVERRIDE by CONFIG_CMDLINE_FORCE
  drivers: firmware: efi: use cmdline building function
  cmdline: Gives architectures opportunity to use generically defined
    boot cmdline manipulation
  powerpc: Convert to GENERIC_CMDLINE
  arm: Convert to GENERIC_CMDLINE
  arm64: Convert to GENERIC_CMDLINE
  hexagon: Convert to GENERIC_CMDLINE
  microblaze: Convert to GENERIC_CMDLINE
  nios2: Convert to GENERIC_CMDLINE
  openrisc: Convert to GENERIC_CMDLINE
  riscv: Convert to GENERIC_CMDLINE
  sh: Convert to GENERIC_CMDLINE
  sparc: Convert to GENERIC_CMDLINE
  xtensa: Convert to GENERIC_CMDLINE
  x86: Convert to GENERIC_CMDLINE
  mips: Convert to GENERIC_CMDLINE
  cmdline: Remove CONFIG_CMDLINE_EXTEND

Daniel Walker (1):
  powerpc: convert strcpy to strlcpy in prom_init

 arch/arm/Kconfig                              | 38 +--------
 arch/arm/kernel/atags_parse.c                 | 13 +--
 arch/arm64/Kconfig                            | 33 +-------
 arch/arm64/kernel/idreg-override.c            |  9 +--
 arch/hexagon/Kconfig                          | 11 +--
 arch/hexagon/kernel/setup.c                   | 10 +--
 arch/microblaze/Kconfig                       | 24 +-----
 arch/microblaze/configs/mmu_defconfig         |  2 +-
 arch/microblaze/kernel/head.S                 |  4 +-
 arch/mips/Kconfig                             |  1 +
 arch/mips/Kconfig.debug                       | 44 -----------
 arch/mips/configs/ar7_defconfig               |  1 -
 arch/mips/configs/bcm47xx_defconfig           |  1 -
 arch/mips/configs/bcm63xx_defconfig           |  1 -
 arch/mips/configs/bmips_be_defconfig          |  1 -
 arch/mips/configs/bmips_stb_defconfig         |  1 -
 arch/mips/configs/capcella_defconfig          |  1 -
 arch/mips/configs/ci20_defconfig              |  1 -
 arch/mips/configs/cu1000-neo_defconfig        |  1 -
 arch/mips/configs/cu1830-neo_defconfig        |  1 -
 arch/mips/configs/e55_defconfig               |  1 -
 arch/mips/configs/generic_defconfig           |  1 -
 arch/mips/configs/gpr_defconfig               |  1 -
 arch/mips/configs/loongson3_defconfig         |  1 -
 arch/mips/configs/mpc30x_defconfig            |  1 -
 arch/mips/configs/rt305x_defconfig            |  1 -
 arch/mips/configs/tb0219_defconfig            |  1 -
 arch/mips/configs/tb0226_defconfig            |  1 -
 arch/mips/configs/tb0287_defconfig            |  1 -
 arch/mips/configs/workpad_defconfig           |  1 -
 arch/mips/configs/xway_defconfig              |  1 -
 arch/mips/kernel/relocate.c                   |  4 +-
 arch/mips/kernel/setup.c                      | 40 +---------
 arch/mips/pic32/pic32mzda/early_console.c     |  2 +-
 arch/mips/pic32/pic32mzda/init.c              |  2 -
 arch/nios2/Kconfig                            | 25 +-----
 arch/nios2/kernel/setup.c                     | 13 +--
 arch/openrisc/Kconfig                         | 10 +--
 arch/powerpc/Kconfig                          | 37 +--------
 arch/powerpc/kernel/prom_init.c               | 46 ++++++-----
 arch/riscv/Kconfig                            | 44 +----------
 arch/riscv/kernel/setup.c                     |  7 +-
 arch/sh/Kconfig                               | 28 +------
 arch/sh/configs/ap325rxa_defconfig            |  2 +-
 arch/sh/configs/dreamcast_defconfig           |  2 +-
 arch/sh/configs/ecovec24-romimage_defconfig   |  2 +-
 arch/sh/configs/ecovec24_defconfig            |  2 +-
 arch/sh/configs/edosk7760_defconfig           |  2 +-
 arch/sh/configs/espt_defconfig                |  2 +-
 arch/sh/configs/j2_defconfig                  |  2 +-
 arch/sh/configs/kfr2r09-romimage_defconfig    |  2 +-
 arch/sh/configs/kfr2r09_defconfig             |  2 +-
 arch/sh/configs/lboxre2_defconfig             |  2 +-
 arch/sh/configs/microdev_defconfig            |  2 +-
 arch/sh/configs/migor_defconfig               |  2 +-
 arch/sh/configs/polaris_defconfig             |  2 +-
 arch/sh/configs/r7780mp_defconfig             |  2 +-
 arch/sh/configs/r7785rp_defconfig             |  2 +-
 arch/sh/configs/rsk7201_defconfig             |  2 +-
 arch/sh/configs/rsk7203_defconfig             |  2 +-
 arch/sh/configs/rts7751r2d1_defconfig         |  2 +-
 arch/sh/configs/rts7751r2dplus_defconfig      |  2 +-
 arch/sh/configs/sdk7780_defconfig             |  2 +-
 arch/sh/configs/sdk7786_defconfig             |  2 +-
 arch/sh/configs/se7206_defconfig              |  2 +-
 arch/sh/configs/se7343_defconfig              |  2 +-
 arch/sh/configs/se7712_defconfig              |  2 +-
 arch/sh/configs/se7721_defconfig              |  2 +-
 arch/sh/configs/se7724_defconfig              |  2 +-
 arch/sh/configs/se7751_defconfig              |  2 +-
 arch/sh/configs/se7780_defconfig              |  2 +-
 arch/sh/configs/sh03_defconfig                |  2 +-
 arch/sh/configs/sh2007_defconfig              |  2 +-
 arch/sh/configs/sh7757lcr_defconfig           |  2 +-
 arch/sh/configs/sh7763rdp_defconfig           |  2 +-
 arch/sh/configs/shmin_defconfig               |  2 +-
 arch/sh/configs/shx3_defconfig                |  2 +-
 arch/sh/configs/titan_defconfig               |  2 +-
 arch/sh/configs/ul2_defconfig                 |  2 +-
 arch/sh/kernel/setup.c                        | 11 +--
 arch/sparc/Kconfig                            | 18 +----
 arch/sparc/prom/bootstr_64.c                  |  2 +-
 arch/x86/Kconfig                              | 45 +----------
 arch/x86/kernel/setup.c                       | 17 +---
 arch/xtensa/Kconfig                           | 15 +---
 arch/xtensa/configs/audio_kc705_defconfig     |  1 -
 arch/xtensa/configs/common_defconfig          |  1 -
 arch/xtensa/configs/generic_kc705_defconfig   |  1 -
 arch/xtensa/configs/iss_defconfig             |  1 -
 arch/xtensa/configs/nommu_kc705_defconfig     |  1 -
 arch/xtensa/configs/smp_lx200_defconfig       |  1 -
 arch/xtensa/configs/virt_defconfig            |  1 -
 arch/xtensa/configs/xip_kc705_defconfig       |  1 -
 arch/xtensa/kernel/setup.c                    | 10 +--
 .../firmware/efi/libstub/efi-stub-helper.c    | 35 ++++----
 drivers/firmware/efi/libstub/efi-stub.c       | 23 ++----
 drivers/firmware/efi/libstub/efistub.h        |  2 +-
 drivers/firmware/efi/libstub/x86-stub.c       | 18 +----
 drivers/of/fdt.c                              | 23 +-----
 include/linux/cmdline.h                       | 79 +++++++++++++++++++
 init/Kconfig                                  | 46 +++++++++++
 usr/Kconfig                                   |  2 +-
 102 files changed, 265 insertions(+), 628 deletions(-)
 create mode 100644 include/linux/cmdline.h

-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:04 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:04 +0000 (UTC)
Subject: [PATCH v4 03/20] x86/efi: Replace CONFIG_CMDLINE_OVERRIDE by
 CONFIG_CMDLINE_FORCE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <76542a49b685ddb41894fd53feb250fcec731b01.1617375802.git.christophe.leroy@csgroup.eu>

During boot, x86 uses EFI driver. That driver is also used
by ARM.

In order to refactor the command line processing in that driver
in a following patch, rename CONFIG_CMDLINE_OVERRIDE by
CONFIG_CMDLINE_FORCE on the x86 in order to be similar
to ARM (and most other architectures).

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4: New
---
 arch/x86/Kconfig                        | 4 ++--
 arch/x86/kernel/setup.c                 | 2 +-
 drivers/firmware/efi/libstub/x86-stub.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..a20684d56b4b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2384,14 +2384,14 @@ config CMDLINE
 	  command line at boot time, it is appended to this string to
 	  form the full kernel command line, when the system boots.
 
-	  However, you can use the CONFIG_CMDLINE_OVERRIDE option to
+	  However, you can use the CONFIG_CMDLINE_FORCE option to
 	  change this behavior.
 
 	  In most cases, the command line (whether built-in or provided
 	  by the boot loader) should specify the device for the root
 	  file system.
 
-config CMDLINE_OVERRIDE
+config CMDLINE_FORCE
 	bool "Built-in command line overrides boot loader arguments"
 	depends on CMDLINE_BOOL && CMDLINE != ""
 	help
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d883176ef2ce..6f2de58eeb54 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -884,7 +884,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.end = __pa_symbol(__bss_stop)-1;
 
 #ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
+#ifdef CONFIG_CMDLINE_FORCE
 	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
 #else
 	if (builtin_cmdline[0]) {
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index f14c4ff5839f..28659276b6ba 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -742,7 +742,7 @@ unsigned long efi_main(efi_handle_t handle,
 		goto fail;
 	}
 #endif
-	if (!IS_ENABLED(CONFIG_CMDLINE_OVERRIDE)) {
+	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
 		unsigned long cmdline_paddr = ((u64)hdr->cmd_line_ptr |
 					       ((u64)boot_params->ext_cmd_line_ptr << 32));
 		status = efi_parse_options((char *)cmdline_paddr);
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:06 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:06 +0000 (UTC)
Subject: [PATCH v4 05/20] cmdline: Gives architectures opportunity to use
 generically defined boot cmdline manipulation
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <9cf63d0419bb51d91c5b1c83ce250dff1e7107cc.1617375802.git.christophe.leroy@csgroup.eu>

Most architectures have similar boot command line manipulation
options. This patchs adds the definition in init/Kconfig, gated by
CONFIG_HAVE_CMDLINE that the architectures can select to use them.

CONFIG_CMDLINE_EXTEND is understood differently by architectures.
For some of them it appends built-in CMDLINE to bootloader provided
line. For others it appends the bootloader provided CMDLINE to the
built-in one.
To avoid confusion, this commit brings to different options:
- CONFIG_CMDLINE_APPEND to append the built-in CMDLINE to the
bootloader line.
- CONFIG_CMDLINE_PREPEND to prepend the built-in CMDLINE in front of
the bootloader line.

For compatibility with existing architecture which uses CONFIG_OF, as
OF has already been converted to generic cmdline, we keep
CONFIG_CMDLINE_EXTEND as a synonym to CONFIG_CMDLINE_APPEND until
arm, powerpc, riscv and sh architectures have been converted.

A few differences are identified and will have to be taken
into account when converting the architecture to generic cmdline:
- riscv has CMDLINE_FALLBACK instead of CMDLINE_FROM_BOOTLOADER
- Some architectures are using CONFIG_CMDLINE_OVERRIDE or
CONFIG_CMDLINE_OVERWRITE instead of CONFIG_CMDLINE_FORCE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v3:
- Comments from Will.
- Remove CONFIG_CMDLINE_BOOL. Using CONFIG_CMDLINE != "" instead, like arm and powerpc.
- Changed EXTEND to APPEND. Keep EXTEND for backward compatibility.

v4:
- Added CMDLINE_PREPEND as a dependency for INITRAMFS_FORCE
- Removed the EXTEND || APPEND in cmdline.h, keep EXTEND as it
   will always exit and switch to APPEND in last patch.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 init/Kconfig | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 usr/Kconfig  |  2 +-
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/init/Kconfig b/init/Kconfig
index 5f5c776ef192..af0d84662cc2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -117,6 +117,58 @@ config INIT_ENV_ARG_LIMIT
 	  Maximum of each of the number of arguments and environment
 	  variables passed to init from the kernel command line.
 
+config GENERIC_CMDLINE
+	bool
+
+config CMDLINE
+	string "Default kernel command string" if GENERIC_CMDLINE
+	default ""
+	help
+	  Defines a default kernel command string.
+	  If this string is not empty, additional choices are proposed
+	  below to determine how it will be used by the kernel.
+
+choice
+	prompt "Kernel command line type" if CMDLINE != ""
+	default CMDLINE_PREPEND if ARCH_WANT_CMDLINE_PREPEND_BY_DEFAULT
+	default CMDLINE_FROM_BOOTLOADER
+	depends on GENERIC_CMDLINE
+	help
+	  Determine how the default kernel arguments are combined with any
+	  arguments passed by the bootloader if any.
+
+config CMDLINE_FROM_BOOTLOADER
+	bool "Use bootloader kernel arguments if available"
+	help
+	  Uses the command-line options passed by the boot loader. If
+	  the boot loader doesn't provide any, the default kernel command
+	  string provided in CMDLINE will be used.
+
+config CMDLINE_APPEND
+	bool "Append to the bootloader kernel arguments"
+	help
+	  The default kernel command string will be appended to the
+	  command-line arguments provided by the bootloader.
+
+config CMDLINE_PREPEND
+	bool "Prepend to the bootloader kernel arguments"
+	help
+	  The default kernel command string will be prepended to the
+	  command-line arguments provided by the bootloader.
+
+config CMDLINE_FORCE
+	bool "Always use the default kernel command string"
+	help
+	  Always use the default kernel command string, ignoring any
+	  arguments provided by the bootloader.
+endchoice
+
+config CMDLINE_EXTEND
+	bool
+	default CMDLINE_APPEND
+	help
+	  To be removed once all architectures are converted to generic CMDLINE
+
 config COMPILE_TEST
 	bool "Compile also drivers which will not load"
 	depends on HAS_IOMEM
diff --git a/usr/Kconfig b/usr/Kconfig
index 8bbcf699fe3b..b397e6b114d1 100644
--- a/usr/Kconfig
+++ b/usr/Kconfig
@@ -24,7 +24,7 @@ config INITRAMFS_SOURCE
 
 config INITRAMFS_FORCE
 	bool "Ignore the initramfs passed by the bootloader"
-	depends on CMDLINE_EXTEND || CMDLINE_FORCE
+	depends on CMDLINE_PREPEND || CMDLINE_APPEND || CMDLINE_FORCE
 	help
 	  This option causes the kernel to ignore the initramfs image
 	  (or initrd image) passed to it by the bootloader. This is
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:07 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:07 +0000 (UTC)
Subject: [PATCH v4 06/20] powerpc: convert strcpy to strlcpy in prom_init
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <03c0b931557967876abcebc7d0e3c6537eb6ab89.1617375802.git.christophe.leroy@csgroup.eu>

From: Daniel Walker <danielwa at cisco.com>

There's only two users of strcpy and one is the command
line handling. The generic command line handling uses strlcpy
and it makes sense to convert this one other user to strlcpy to
keep prom_init size consistent.

Cc: xe-linux-external at cisco.com
Signed-off-by: Daniel Walker <danielwa at cisco.com>
Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/powerpc/kernel/prom_init.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 41ed7e33d897..33316ee55265 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -242,15 +242,6 @@ static int __init prom_strcmp(const char *cs, const char *ct)
 	return 0;
 }
 
-static char __init *prom_strcpy(char *dest, const char *src)
-{
-	char *tmp = dest;
-
-	while ((*dest++ = *src++) != '\0')
-		/* nothing */;
-	return tmp;
-}
-
 static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
 {
 	unsigned char c1, c2;
@@ -276,6 +267,20 @@ static size_t __init prom_strlen(const char *s)
 	return sc - s;
 }
 
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)
+{
+	size_t ret = prom_strlen(src);
+
+	if (size) {
+		size_t len = (ret >= size) ? size - 1 : ret;
+
+		memcpy(dest, src, len);
+		dest[len] = '\0';
+	}
+	return ret;
+}
+
+
 static int __init prom_memcmp(const void *cs, const void *ct, size_t count)
 {
 	const unsigned char *su1, *su2;
@@ -2702,7 +2707,7 @@ static void __init flatten_device_tree(void)
 
 	/* Add "phandle" in there, we'll need it */
 	namep = make_room(&mem_start, &mem_end, 16, 1);
-	prom_strcpy(namep, "phandle");
+	prom_strlcpy(namep, "phandle", 8);
 	mem_start = (unsigned long)namep + prom_strlen(namep) + 1;
 
 	/* Build string array */
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:08 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:08 +0000 (UTC)
Subject: [PATCH v4 07/20] powerpc: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <bcc28f6552708885aecb14a7106b65afbffcc294.1617375802.git.christophe.leroy@csgroup.eu>

This updates the powerpc code to use the new cmdline building function.

The cmdline_build() defines a temporary string in __initdata.
powerpc uses __prombss instead at the moment, so we must
call cmdline_build() with destination different from the source
to allow GCC to optimise the temporary string out.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4:
- Use cmdline_build() instead of __cmdline_build()
- Add cmdline_strlcpy() define
---
 arch/powerpc/Kconfig            | 37 +--------------------------------
 arch/powerpc/kernel/prom_init.c | 21 +++++++++----------
 2 files changed, 11 insertions(+), 47 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c1344c05226c..6723f10ac246 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -168,6 +168,7 @@ config PPC
 	select EDAC_SUPPORT
 	select GENERIC_ATOMIC64			if PPC32
 	select GENERIC_CLOCKEVENTS_BROADCAST	if SMP
+	select GENERIC_CMDLINE
 	select GENERIC_CMOS_UPDATE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_CPU_VULNERABILITIES	if PPC_BARRIER_NOSPEC
@@ -888,42 +889,6 @@ config PPC_DENORMALISATION
 	  Add support for handling denormalisation of single precision
 	  values.  Useful for bare metal only.  If unsure say Y here.
 
-config CMDLINE
-	string "Initial kernel command string"
-	default ""
-	help
-	  On some platforms, there is currently no way for the boot loader to
-	  pass arguments to the kernel. For these platforms, you can supply
-	  some command-line options at build time by entering them here.  In
-	  most cases you will need to specify the root device here.
-
-choice
-	prompt "Kernel command line type" if CMDLINE != ""
-	default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
-	bool "Use bootloader kernel arguments if available"
-	help
-	  Uses the command-line options passed by the boot loader. If
-	  the boot loader doesn't provide any, the default kernel command
-	  string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-	bool "Extend bootloader kernel arguments"
-	help
-	  The command-line arguments provided by the boot loader will be
-	  appended to the default kernel command string.
-
-config CMDLINE_FORCE
-	bool "Always use the default kernel command string"
-	help
-	  Always use the default kernel command string, even if the boot
-	  loader passes other arguments to the kernel.
-	  This is useful if you cannot or don't want to change the
-	  command-line options your boot loader passes to the kernel.
-
-endchoice
-
 config EXTRA_TARGETS
 	string "Additional default image types"
 	help
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 33316ee55265..704afd028213 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -152,7 +152,7 @@ static struct prom_t __prombss prom;
 static unsigned long __prombss prom_entry;
 
 static char __prombss of_stdout_device[256];
-static char __prombss prom_scratch[256];
+static char __prombss prom_scratch[COMMAND_LINE_SIZE];
 
 static unsigned long __prombss dt_header_start;
 static unsigned long __prombss dt_struct_start, dt_struct_end;
@@ -770,24 +770,23 @@ static unsigned long prom_memparse(const char *ptr, const char **retptr)
  * Early parsing of the command line passed to the kernel, used for
  * "mem=x" and the options that affect the iommu
  */
+#define cmdline_strlcat prom_strlcat
+#define cmdline_strlcpy prom_strlcpy
+#include <linux/cmdline.h>
+
 static void __init early_cmdline_parse(void)
 {
 	const char *opt;
-
-	char *p;
 	int l = 0;
-
-	prom_cmd_line[0] = 0;
-	p = prom_cmd_line;
+	bool truncated;
 
 	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && (long)prom.chosen > 0)
-		l = prom_getprop(prom.chosen, "bootargs", p, COMMAND_LINE_SIZE-1);
+		l = prom_getprop(prom.chosen, "bootargs", prom_scratch,
+				 COMMAND_LINE_SIZE - 1);
 
-	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) || l <= 0 || p[0] == '\0')
-		prom_strlcat(prom_cmd_line, " " CONFIG_CMDLINE,
-			     sizeof(prom_cmd_line));
+	truncated = !__cmdline_build(prom_cmd_line, l > 0 ? prom_scratch : NULL);
 
-	prom_printf("command line: %s\n", prom_cmd_line);
+	prom_printf("command line: %s %s\n", prom_cmd_line, truncated ? "[truncated]" : "");
 
 #ifdef CONFIG_PPC64
 	opt = prom_strstr(prom_cmd_line, "iommu=");
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:10 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:10 +0000 (UTC)
Subject: [PATCH v4 09/20] arm64: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <d1a338ad8f382216083166d546bed7acce798674.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/arm64/Kconfig                 | 33 +-----------------------------
 arch/arm64/kernel/idreg-override.c |  9 ++++----
 2 files changed, 5 insertions(+), 37 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..9781ba3758b1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -105,6 +105,7 @@ config ARM64
 	select GENERIC_ALLOCATOR
 	select GENERIC_ARCH_TOPOLOGY
 	select GENERIC_CLOCKEVENTS_BROADCAST
+	select GENERIC_CMDLINE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_EARLY_IOREMAP
@@ -1841,38 +1842,6 @@ config ARM64_ACPI_PARKING_PROTOCOL
 	  protocol even if the corresponding data is present in the ACPI
 	  MADT table.
 
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	help
-	  Provide a set of default command-line options at build time by
-	  entering them here. As a minimum, you should specify the the
-	  root device (e.g. root=/dev/nfs).
-
-choice
-	prompt "Kernel command line type" if CMDLINE != ""
-	default CMDLINE_FROM_BOOTLOADER
-	help
-	  Choose how the kernel will handle the provided default kernel
-	  command line string.
-
-config CMDLINE_FROM_BOOTLOADER
-	bool "Use bootloader kernel arguments if available"
-	help
-	  Uses the command-line options passed by the boot loader. If
-	  the boot loader doesn't provide any, the default kernel command
-	  string provided in CMDLINE will be used.
-
-config CMDLINE_FORCE
-	bool "Always use the default kernel command string"
-	help
-	  Always use the default kernel command string, even if the boot
-	  loader passes other arguments to the kernel.
-	  This is useful if you cannot or don't want to change the
-	  command-line options your boot loader passes to the kernel.
-
-endchoice
-
 config EFI_STUB
 	bool
 
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 83f1c4b92095..96a4e96a80a2 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -9,6 +9,7 @@
 #include <linux/ctype.h>
 #include <linux/kernel.h>
 #include <linux/libfdt.h>
+#include <linux/cmdline.h>
 
 #include <asm/cacheflush.h>
 #include <asm/cpufeature.h>
@@ -187,12 +188,10 @@ static __init const u8 *get_bootargs_cmdline(void)
 static __init void parse_cmdline(void)
 {
 	const u8 *prop = get_bootargs_cmdline();
+	static char __initdata cmdline[COMMAND_LINE_SIZE];
 
-	if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !prop)
-		__parse_cmdline(CONFIG_CMDLINE, true);
-
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
-		__parse_cmdline(prop, true);
+	cmdline_build(cmdline, prop);
+	__parse_cmdline(cmdline, true);
 }
 
 /* Keep checkers quiet */
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:09 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:09 +0000 (UTC)
Subject: [PATCH v4 08/20] arm: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <2e49b9ae60a90aec8b555946279cab059a2812a4.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4:
- Removed dependency to ATAGS
- Removed the message when forcing
---
 arch/arm/Kconfig              | 38 +----------------------------------
 arch/arm/kernel/atags_parse.c | 13 +++---------
 2 files changed, 4 insertions(+), 47 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5da96f5df48f..1a1808b0eef7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -50,6 +50,7 @@ config ARM
 	select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
 	select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
 	select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+	select GENERIC_CMDLINE
 	select GENERIC_IRQ_IPI if SMP
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_EARLY_IOREMAP
@@ -1740,43 +1741,6 @@ config ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND
 
 endchoice
 
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	help
-	  On some architectures (e.g. CATS), there is currently no way
-	  for the boot loader to pass arguments to the kernel. For these
-	  architectures, you should supply some command-line options at build
-	  time by entering them here. As a minimum, you should specify the
-	  memory size and the root device (e.g., mem=64M root=/dev/nfs).
-
-choice
-	prompt "Kernel command line type" if CMDLINE != ""
-	default CMDLINE_FROM_BOOTLOADER
-	depends on ATAGS
-
-config CMDLINE_FROM_BOOTLOADER
-	bool "Use bootloader kernel arguments if available"
-	help
-	  Uses the command-line options passed by the boot loader. If
-	  the boot loader doesn't provide any, the default kernel command
-	  string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-	bool "Extend bootloader kernel arguments"
-	help
-	  The command-line arguments provided by the boot loader will be
-	  appended to the default kernel command string.
-
-config CMDLINE_FORCE
-	bool "Always use the default kernel command string"
-	help
-	  Always use the default kernel command string, even if the boot
-	  loader passes other arguments to the kernel.
-	  This is useful if you cannot or don't want to change the
-	  command-line options your boot loader passes to the kernel.
-endchoice
-
 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
 	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 373b61f9a4f0..ef97ec015c51 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -14,6 +14,7 @@
  * is not parsed in any way).
  */
 
+#include <linux/cmdline.h>
 #include <linux/init.h>
 #include <linux/initrd.h>
 #include <linux/kernel.h>
@@ -120,16 +121,8 @@ __tagtable(ATAG_REVISION, parse_tag_revision);
 
 static int __init parse_tag_cmdline(const struct tag *tag)
 {
-#if defined(CONFIG_CMDLINE_EXTEND)
-	strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
-	strlcat(default_command_line, tag->u.cmdline.cmdline,
-		COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
-	pr_warn("Ignoring tag cmdline (using the default kernel command line)\n");
-#else
-	strlcpy(default_command_line, tag->u.cmdline.cmdline,
-		COMMAND_LINE_SIZE);
-#endif
+	cmdline_build(default_command_line, tag->u.cmdline.cmdline);
+
 	return 0;
 }
 
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:11 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:11 +0000 (UTC)
Subject: [PATCH v4 10/20] hexagon: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <1180421ba35993f4a533708b91c93f1da07d14dc.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/hexagon/Kconfig        | 11 +----------
 arch/hexagon/kernel/setup.c | 10 ++--------
 2 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 44a409967af1..1e69c99bae6b 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -18,6 +18,7 @@ config HEXAGON
 	select HAVE_PERF_EVENTS
 	# GENERIC_ALLOCATOR is used by dma_alloc_coherent()
 	select GENERIC_ALLOCATOR
+	select GENERIC_CMDLINE
 	select GENERIC_IRQ_SHOW
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_TRACEHOOK
@@ -91,16 +92,6 @@ config HEXAGON_ARCH_VERSION
 	int "Architecture version"
 	default 2
 
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	help
-	  On some platforms, there is currently no way for the boot loader
-	  to pass arguments to the kernel. For these, you should supply some
-	  command-line options at build time by entering them here.  At a
-	  minimum, you should specify the memory size and the root device
-	  (e.g., mem=64M root=/dev/nfs).
-
 config SMP
 	bool "Multi-Processing support"
 	help
diff --git a/arch/hexagon/kernel/setup.c b/arch/hexagon/kernel/setup.c
index 1880d9beaf2b..78641ce219e2 100644
--- a/arch/hexagon/kernel/setup.c
+++ b/arch/hexagon/kernel/setup.c
@@ -13,6 +13,7 @@
 #include <linux/seq_file.h>
 #include <linux/console.h>
 #include <linux/of_fdt.h>
+#include <linux/cmdline.h>
 #include <asm/io.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
@@ -22,7 +23,6 @@
 #include <asm/time.h>
 
 char cmd_line[COMMAND_LINE_SIZE];
-static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
 
 int on_simulator;
 
@@ -38,8 +38,6 @@ void calibrate_delay(void)
 
 void __init setup_arch(char **cmdline_p)
 {
-	char *p = &external_cmdline_buffer;
-
 	/*
 	 * These will eventually be pulled in via either some hypervisor
 	 * or devicetree description.  Hardwiring for now.
@@ -65,11 +63,7 @@ void __init setup_arch(char **cmdline_p)
 	else
 		on_simulator = 0;
 
-	if (p[0] != '\0')
-		strlcpy(boot_command_line, p, COMMAND_LINE_SIZE);
-	else
-		strlcpy(boot_command_line, default_command_line,
-			COMMAND_LINE_SIZE);
+	cmdline_build(boot_command_line, external_cmdline_buffer);
 
 	/*
 	 * boot_command_line and the value set up by setup_arch
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:12 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:12 +0000 (UTC)
Subject: [PATCH v4 11/20] microblaze: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <c73e170d5fbcc3ac5d7bc98a1e0bfa0b899b185e.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/microblaze/Kconfig               | 24 +-----------------------
 arch/microblaze/configs/mmu_defconfig |  2 +-
 arch/microblaze/kernel/head.S         |  4 ++--
 3 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0660f47012bc..1242f34bc2a2 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -15,6 +15,7 @@ config MICROBLAZE
 	select COMMON_CLK
 	select DMA_DIRECT_REMAP
 	select GENERIC_ATOMIC64
+	select GENERIC_CMDLINE
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IDLE_POLL_SETUP
 	select GENERIC_IRQ_PROBE
@@ -93,29 +94,6 @@ source "kernel/Kconfig.hz"
 config MMU
 	def_bool y
 
-comment "Boot options"
-
-config CMDLINE_BOOL
-	bool "Default bootloader kernel arguments"
-
-config CMDLINE
-	string "Default kernel command string"
-	depends on CMDLINE_BOOL
-	default "console=ttyUL0,115200"
-	help
-	  On some architectures there is currently no way for the boot loader
-	  to pass arguments to the kernel. For these architectures, you should
-	  supply some command-line options at build time by entering them
-	  here.
-
-config CMDLINE_FORCE
-	bool "Force default kernel command string"
-	depends on CMDLINE_BOOL
-	default n
-	help
-	  Set this to have arguments from the default kernel command string
-	  override those passed by the boot loader.
-
 endmenu
 
 menu "Kernel features"
diff --git a/arch/microblaze/configs/mmu_defconfig b/arch/microblaze/configs/mmu_defconfig
index 51337fffb947..b4d2219d0a8f 100644
--- a/arch/microblaze/configs/mmu_defconfig
+++ b/arch/microblaze/configs/mmu_defconfig
@@ -16,7 +16,7 @@ CONFIG_XILINX_MICROBLAZE0_USE_DIV=1
 CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2
 CONFIG_XILINX_MICROBLAZE0_USE_FPU=2
 CONFIG_HZ_100=y
-CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="console=ttyUL0,115200"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_HIGHMEM=y
 CONFIG_PCI_XILINX=y
diff --git a/arch/microblaze/kernel/head.S b/arch/microblaze/kernel/head.S
index ec2fcb545e64..605b18c86ac8 100644
--- a/arch/microblaze/kernel/head.S
+++ b/arch/microblaze/kernel/head.S
@@ -105,7 +105,7 @@ _copy_fdt:
 	addik	r3, r3, -4 /* descrement loop */
 no_fdt_arg:
 
-#ifndef CONFIG_CMDLINE_BOOL
+#if CONFIG_CMDLINE == ""
 /*
  * handling command line
  * copy command line directly to cmd_line placed in data section.
@@ -126,7 +126,7 @@ _copy_command_line:
 	addik	r5, r4, 0		/* add new space for command line */
 	tovirt(r5,r5)
 skip:
-#endif /* CONFIG_CMDLINE_BOOL */
+#endif /* CONFIG_CMDLINE */
 
 #ifdef NOT_COMPILE
 /* save bram context */
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:15 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:15 +0000 (UTC)
Subject: [PATCH v4 13/20] openrisc: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <c3d52a6e1423d9d27c59ad7ab945929b09f74866.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/openrisc/Kconfig | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 591acc5990dc..ca1d0f18fe16 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -25,6 +25,7 @@ config OPENRISC
 	select HAVE_UID16
 	select GENERIC_ATOMIC64
 	select GENERIC_CLOCKEVENTS_BROADCAST
+	select GENERIC_CMDLINE
 	select GENERIC_STRNCPY_FROM_USER
 	select GENERIC_STRNLEN_USER
 	select GENERIC_SMP_IDLE_THREAD
@@ -162,15 +163,6 @@ config OPENRISC_HAVE_SHADOW_GPRS
 	  On SMP systems, this feature is mandatory.
 	  On a unicore system it's safe to say N here if you are unsure.
 
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	help
-	  On some architectures there is currently no way for the boot loader
-	  to pass arguments to the kernel. For these architectures, you should
-	  supply some command-line options at build time by entering them
-	  here.
-
 menu "Debugging options"
 
 config JUMP_UPON_UNHANDLED_EXCEPTION
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:13 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:13 +0000 (UTC)
Subject: [PATCH v4 12/20] nios2: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <9b4899b0abc156eb207b19fe0b24dd5bf0355b99.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4: Added missing selection of CONFIG_GENERIC_CMDLINE in Kconfig
---
 arch/nios2/Kconfig        | 25 ++-----------------------
 arch/nios2/kernel/setup.c | 13 ++++---------
 2 files changed, 6 insertions(+), 32 deletions(-)

diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig
index c24955c81c92..6018f3d626f8 100644
--- a/arch/nios2/Kconfig
+++ b/arch/nios2/Kconfig
@@ -10,6 +10,7 @@ config NIOS2
 	select COMMON_CLK
 	select TIMER_OF
 	select GENERIC_ATOMIC64
+	select GENERIC_CMDLINE
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
@@ -90,31 +91,9 @@ config NIOS2_ALIGNMENT_TRAP
 
 comment "Boot options"
 
-config CMDLINE_BOOL
-	bool "Default bootloader kernel arguments"
-	default y
-
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	depends on CMDLINE_BOOL
-	help
-	  On some platforms, there is currently no way for the boot loader to
-	  pass arguments to the kernel. For these platforms, you can supply
-	  some command-line options at build time by entering them here.  In
-	  other cases you can specify kernel args so that you don't have
-	  to set them up in board prom initialization routines.
-
-config CMDLINE_FORCE
-	bool "Force default kernel command string"
-	depends on CMDLINE_BOOL
-	help
-	  Set this to have arguments from the default kernel command string
-	  override those passed by the boot loader.
-
 config NIOS2_CMDLINE_IGNORE_DTB
 	bool "Ignore kernel command string from DTB"
-	depends on CMDLINE_BOOL
+	depends on CMDLINE != ""
 	depends on !CMDLINE_FORCE
 	default y
 	help
diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c
index d2f21957e99c..5b38d3d0ad64 100644
--- a/arch/nios2/kernel/setup.c
+++ b/arch/nios2/kernel/setup.c
@@ -20,6 +20,7 @@
 #include <linux/initrd.h>
 #include <linux/of_fdt.h>
 #include <linux/screen_info.h>
+#include <linux/cmdline.h>
 
 #include <asm/mmu_context.h>
 #include <asm/sections.h>
@@ -108,7 +109,7 @@ asmlinkage void __init nios2_boot_init(unsigned r4, unsigned r5, unsigned r6,
 				       unsigned r7)
 {
 	unsigned dtb_passed = 0;
-	char cmdline_passed[COMMAND_LINE_SIZE] __maybe_unused = { 0, };
+	char cmdline_passed[COMMAND_LINE_SIZE] = { 0, };
 
 #if defined(CONFIG_NIOS2_PASS_CMDLINE)
 	if (r4 == 0x534f494e) { /* r4 is magic NIOS */
@@ -127,14 +128,8 @@ asmlinkage void __init nios2_boot_init(unsigned r4, unsigned r5, unsigned r6,
 
 	early_init_devtree((void *)dtb_passed);
 
-#ifndef CONFIG_CMDLINE_FORCE
-	if (cmdline_passed[0])
-		strlcpy(boot_command_line, cmdline_passed, COMMAND_LINE_SIZE);
-#ifdef CONFIG_NIOS2_CMDLINE_IGNORE_DTB
-	else
-		strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif
+	if (cmdline_passed[0] || IS_ENABLED(CONFIG_NIOS2_CMDLINE_IGNORE_DTB))
+		cmdline_build(boot_command_line, cmdline_passed);
 
 	parse_early_param();
 }
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:16 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:16 +0000 (UTC)
Subject: [PATCH v4 14/20] riscv: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <9590d262050923a22d434358a9037131f67fcaae.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4: Remove the message when forcing
---
 arch/riscv/Kconfig        | 44 +--------------------------------------
 arch/riscv/kernel/setup.c |  7 +++----
 2 files changed, 4 insertions(+), 47 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 87d7b52f278f..3dbd50bed037 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -39,6 +39,7 @@ config RISCV
 	select EDAC_SUPPORT
 	select GENERIC_ARCH_TOPOLOGY if SMP
 	select GENERIC_ATOMIC64 if !64BIT
+	select GENERIC_CMDLINE
 	select GENERIC_EARLY_IOREMAP
 	select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
 	select GENERIC_IOREMAP
@@ -390,49 +391,6 @@ endmenu
 
 menu "Boot options"
 
-config CMDLINE
-	string "Built-in kernel command line"
-	help
-	  For most platforms, the arguments for the kernel's command line
-	  are provided at run-time, during boot. However, there are cases
-	  where either no arguments are being provided or the provided
-	  arguments are insufficient or even invalid.
-
-	  When that occurs, it is possible to define a built-in command
-	  line here and choose how the kernel should use it later on.
-
-choice
-	prompt "Built-in command line usage" if CMDLINE != ""
-	default CMDLINE_FALLBACK
-	help
-	  Choose how the kernel will handle the provided built-in command
-	  line.
-
-config CMDLINE_FALLBACK
-	bool "Use bootloader kernel arguments if available"
-	help
-	  Use the built-in command line as fallback in case we get nothing
-	  during boot. This is the default behaviour.
-
-config CMDLINE_EXTEND
-	bool "Extend bootloader kernel arguments"
-	help
-	  The command-line arguments provided during boot will be
-	  appended to the built-in command line. This is useful in
-	  cases where the provided arguments are insufficient and
-	  you don't want to or cannot modify them.
-
-
-config CMDLINE_FORCE
-	bool "Always use the default kernel command string"
-	help
-	  Always use the built-in command line, even if we get one during
-	  boot. This is useful in case you need to override the provided
-	  command line on systems where you don't have or want control
-	  over it.
-
-endchoice
-
 config EFI_STUB
 	bool
 
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index f8f15332caa2..d4f16a9c1762 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -20,6 +20,7 @@
 #include <linux/swiotlb.h>
 #include <linux/smp.h>
 #include <linux/efi.h>
+#include <linux/cmdline.h>
 
 #include <asm/cpu_ops.h>
 #include <asm/early_ioremap.h>
@@ -228,10 +229,8 @@ static void __init parse_dtb(void)
 	}
 
 	pr_err("No DTB passed to the kernel\n");
-#ifdef CONFIG_CMDLINE_FORCE
-	strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-	pr_info("Forcing kernel command line to: %s\n", boot_command_line);
-#endif
+
+	cmdline_build(boot_command_line, NULL);
 }
 
 void __init setup_arch(char **cmdline_p)
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:17 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:17 +0000 (UTC)
Subject: [PATCH v4 15/20] sh: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <56269e717991d446112958ecf7340ce095b371a6.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
v4: Restore the removed 'endmenu' in Kconfig
---
 arch/sh/Kconfig                             | 28 +--------------------
 arch/sh/configs/ap325rxa_defconfig          |  2 +-
 arch/sh/configs/dreamcast_defconfig         |  2 +-
 arch/sh/configs/ecovec24-romimage_defconfig |  2 +-
 arch/sh/configs/ecovec24_defconfig          |  2 +-
 arch/sh/configs/edosk7760_defconfig         |  2 +-
 arch/sh/configs/espt_defconfig              |  2 +-
 arch/sh/configs/j2_defconfig                |  2 +-
 arch/sh/configs/kfr2r09-romimage_defconfig  |  2 +-
 arch/sh/configs/kfr2r09_defconfig           |  2 +-
 arch/sh/configs/lboxre2_defconfig           |  2 +-
 arch/sh/configs/microdev_defconfig          |  2 +-
 arch/sh/configs/migor_defconfig             |  2 +-
 arch/sh/configs/polaris_defconfig           |  2 +-
 arch/sh/configs/r7780mp_defconfig           |  2 +-
 arch/sh/configs/r7785rp_defconfig           |  2 +-
 arch/sh/configs/rsk7201_defconfig           |  2 +-
 arch/sh/configs/rsk7203_defconfig           |  2 +-
 arch/sh/configs/rts7751r2d1_defconfig       |  2 +-
 arch/sh/configs/rts7751r2dplus_defconfig    |  2 +-
 arch/sh/configs/sdk7780_defconfig           |  2 +-
 arch/sh/configs/sdk7786_defconfig           |  2 +-
 arch/sh/configs/se7206_defconfig            |  2 +-
 arch/sh/configs/se7343_defconfig            |  2 +-
 arch/sh/configs/se7712_defconfig            |  2 +-
 arch/sh/configs/se7721_defconfig            |  2 +-
 arch/sh/configs/se7724_defconfig            |  2 +-
 arch/sh/configs/se7751_defconfig            |  2 +-
 arch/sh/configs/se7780_defconfig            |  2 +-
 arch/sh/configs/sh03_defconfig              |  2 +-
 arch/sh/configs/sh2007_defconfig            |  2 +-
 arch/sh/configs/sh7757lcr_defconfig         |  2 +-
 arch/sh/configs/sh7763rdp_defconfig         |  2 +-
 arch/sh/configs/shmin_defconfig             |  2 +-
 arch/sh/configs/shx3_defconfig              |  2 +-
 arch/sh/configs/titan_defconfig             |  2 +-
 arch/sh/configs/ul2_defconfig               |  2 +-
 arch/sh/kernel/setup.c                      | 11 ++------
 38 files changed, 39 insertions(+), 72 deletions(-)

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index e798e55915c2..92d6a4443166 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -16,6 +16,7 @@ config SUPERH
 	select CPU_NO_EFFICIENT_FFS
 	select DMA_DECLARE_COHERENT
 	select GENERIC_ATOMIC64
+	select GENERIC_CMDLINE
 	select GENERIC_CMOS_UPDATE if SH_SH03 || SH_DREAMCAST
 	select GENERIC_IDLE_POLL_SETUP
 	select GENERIC_IRQ_SHOW
@@ -742,33 +743,6 @@ config ROMIMAGE_MMCIF
 	  first part of the romImage which in turn loads the rest the kernel
 	  image to RAM using the MMCIF hardware block.
 
-choice
-	prompt "Kernel command line"
-	optional
-	default CMDLINE_OVERWRITE
-	help
-	  Setting this option allows the kernel command line arguments
-	  to be set.
-
-config CMDLINE_OVERWRITE
-	bool "Overwrite bootloader kernel arguments"
-	help
-	  Given string will overwrite any arguments passed in by
-	  a bootloader.
-
-config CMDLINE_EXTEND
-	bool "Extend bootloader kernel arguments"
-	help
-	  Given string will be concatenated with arguments passed in
-	  by a bootloader.
-
-endchoice
-
-config CMDLINE
-	string "Kernel command line arguments string"
-	depends on CMDLINE_OVERWRITE || CMDLINE_EXTEND
-	default "console=ttySC1,115200"
-
 endmenu
 
 menu "Bus options"
diff --git a/arch/sh/configs/ap325rxa_defconfig b/arch/sh/configs/ap325rxa_defconfig
index 5193b3e099b9..3997aa49c75b 100644
--- a/arch/sh/configs/ap325rxa_defconfig
+++ b/arch/sh/configs/ap325rxa_defconfig
@@ -15,7 +15,7 @@ CONFIG_SH_AP325RXA=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SECCOMP=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty1 console=ttySC5,38400 root=/dev/nfs ip=dhcp"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/dreamcast_defconfig b/arch/sh/configs/dreamcast_defconfig
index 6a82c7b8ff32..ac030c1a351e 100644
--- a/arch/sh/configs/dreamcast_defconfig
+++ b/arch/sh/configs/dreamcast_defconfig
@@ -22,7 +22,7 @@ CONFIG_NR_DMA_CHANNELS_BOOL=y
 CONFIG_NR_DMA_CHANNELS=9
 CONFIG_SECCOMP=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 panic=3"
 CONFIG_MAPLE=y
 CONFIG_PCI=y
diff --git a/arch/sh/configs/ecovec24-romimage_defconfig b/arch/sh/configs/ecovec24-romimage_defconfig
index 5c60e71d839e..db78857ae30f 100644
--- a/arch/sh/configs/ecovec24-romimage_defconfig
+++ b/arch/sh/configs/ecovec24-romimage_defconfig
@@ -14,7 +14,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_ECOVEC=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_KEXEC=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200"
 # CONFIG_SUSPEND is not set
 CONFIG_NET=y
diff --git a/arch/sh/configs/ecovec24_defconfig b/arch/sh/configs/ecovec24_defconfig
index 03cb916819fa..f6f7d2e1840d 100644
--- a/arch/sh/configs/ecovec24_defconfig
+++ b/arch/sh/configs/ecovec24_defconfig
@@ -16,7 +16,7 @@ CONFIG_SH_ECOVEC=y
 CONFIG_HEARTBEAT=y
 CONFIG_SECCOMP=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 root=/dev/nfs ip=dhcp mem=248M memchunk.vpu=8m memchunk.veu0=4m"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/edosk7760_defconfig b/arch/sh/configs/edosk7760_defconfig
index d77f54e906fd..1ac8eb89c550 100644
--- a/arch/sh/configs/edosk7760_defconfig
+++ b/arch/sh/configs/edosk7760_defconfig
@@ -19,7 +19,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SH_DMA=y
 CONFIG_SH_DMA_API=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="mem=64M console=ttySC2,115200 root=/dev/nfs rw nfsroot=192.168.0.3:/scripts/filesys ip=192.168.0.4"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/espt_defconfig b/arch/sh/configs/espt_defconfig
index 2804cb760a76..1bffacbaba3d 100644
--- a/arch/sh/configs/espt_defconfig
+++ b/arch/sh/configs/espt_defconfig
@@ -14,7 +14,7 @@ CONFIG_MEMORY_START=0x0c000000
 CONFIG_SH_ESPT=y
 CONFIG_SH_PCLK_FREQ=66666666
 CONFIG_SECCOMP=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/nfs ip=bootp"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/j2_defconfig b/arch/sh/configs/j2_defconfig
index 2eb81ebe3888..983c62e936eb 100644
--- a/arch/sh/configs/j2_defconfig
+++ b/arch/sh/configs/j2_defconfig
@@ -10,7 +10,7 @@ CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_SH_DEVICE_TREE=y
 CONFIG_SH_JCORE_SOC=y
 CONFIG_HZ_100=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttyUL0 earlycon"
 CONFIG_BINFMT_ELF_FDPIC=y
 CONFIG_BINFMT_FLAT=y
diff --git a/arch/sh/configs/kfr2r09-romimage_defconfig b/arch/sh/configs/kfr2r09-romimage_defconfig
index 04436b4fbd76..8418c1f0c1ce 100644
--- a/arch/sh/configs/kfr2r09-romimage_defconfig
+++ b/arch/sh/configs/kfr2r09-romimage_defconfig
@@ -15,7 +15,7 @@ CONFIG_SH_KFR2R09=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_HZ_100=y
 CONFIG_KEXEC=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 quiet"
 # CONFIG_SUSPEND is not set
 CONFIG_NET=y
diff --git a/arch/sh/configs/kfr2r09_defconfig b/arch/sh/configs/kfr2r09_defconfig
index 833404490cfe..0b04d179ebba 100644
--- a/arch/sh/configs/kfr2r09_defconfig
+++ b/arch/sh/configs/kfr2r09_defconfig
@@ -19,7 +19,7 @@ CONFIG_NO_HZ=y
 CONFIG_HZ_1000=y
 CONFIG_KEXEC=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty0 console=ttySC1,115200"
 # CONFIG_SUSPEND is not set
 CONFIG_CPU_IDLE=y
diff --git a/arch/sh/configs/lboxre2_defconfig b/arch/sh/configs/lboxre2_defconfig
index 05e4ac6fed5f..498c88953d2a 100644
--- a/arch/sh/configs/lboxre2_defconfig
+++ b/arch/sh/configs/lboxre2_defconfig
@@ -12,7 +12,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_LBOX_RE2=y
 CONFIG_SH_PCLK_FREQ=40000000
 CONFIG_KEXEC=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_PCCARD=y
diff --git a/arch/sh/configs/microdev_defconfig b/arch/sh/configs/microdev_defconfig
index e9825196dd66..8467de1d3092 100644
--- a/arch/sh/configs/microdev_defconfig
+++ b/arch/sh/configs/microdev_defconfig
@@ -11,7 +11,7 @@ CONFIG_SH_DMA=y
 CONFIG_SH_DMA_API=y
 CONFIG_HEARTBEAT=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/hda1"
 CONFIG_SUPERHYWAY=y
 CONFIG_NET=y
diff --git a/arch/sh/configs/migor_defconfig b/arch/sh/configs/migor_defconfig
index 4859cd30cfc4..e43fb2a63f1f 100644
--- a/arch/sh/configs/migor_defconfig
+++ b/arch/sh/configs/migor_defconfig
@@ -15,7 +15,7 @@ CONFIG_NUMA=y
 CONFIG_SH_MIGOR=y
 # CONFIG_SH_TIMER_CMT is not set
 CONFIG_SECCOMP=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty0 console=ttySC0,115200 earlyprintk=serial ip=on root=/dev/nfs ip=dhcp"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/polaris_defconfig b/arch/sh/configs/polaris_defconfig
index 246408ec7462..2fc2bdc0e002 100644
--- a/arch/sh/configs/polaris_defconfig
+++ b/arch/sh/configs/polaris_defconfig
@@ -25,7 +25,7 @@ CONFIG_SH_DMA_API=y
 CONFIG_HEARTBEAT=y
 CONFIG_HZ_100=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 root=/dev/mtdblock2 rootfstype=jffs2 mem=63M mtdparts=physmap-flash.0:0x00100000(bootloader)ro,0x00500000(Kernel)ro,0x00A00000(Filesystem)"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/r7780mp_defconfig b/arch/sh/configs/r7780mp_defconfig
index f823cc6b18f9..9e2438114890 100644
--- a/arch/sh/configs/r7780mp_defconfig
+++ b/arch/sh/configs/r7780mp_defconfig
@@ -20,7 +20,7 @@ CONFIG_SH_PCLK_FREQ=33333333
 CONFIG_PUSH_SWITCH=y
 CONFIG_KEXEC=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_NET=y
diff --git a/arch/sh/configs/r7785rp_defconfig b/arch/sh/configs/r7785rp_defconfig
index f96bc20d4b1a..c1c92f154694 100644
--- a/arch/sh/configs/r7785rp_defconfig
+++ b/arch/sh/configs/r7785rp_defconfig
@@ -26,7 +26,7 @@ CONFIG_HEARTBEAT=y
 CONFIG_PUSH_SWITCH=y
 CONFIG_KEXEC=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_BINFMT_MISC=m
diff --git a/arch/sh/configs/rsk7201_defconfig b/arch/sh/configs/rsk7201_defconfig
index e41526120be1..65f3d695bc78 100644
--- a/arch/sh/configs/rsk7201_defconfig
+++ b/arch/sh/configs/rsk7201_defconfig
@@ -21,7 +21,7 @@ CONFIG_CPU_BIG_ENDIAN=y
 CONFIG_SH_RSK=y
 CONFIG_SH_PCLK_FREQ=40000000
 CONFIG_HZ_1000=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 earlyprintk=serial ignore_loglevel"
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_ZFLAT=y
diff --git a/arch/sh/configs/rsk7203_defconfig b/arch/sh/configs/rsk7203_defconfig
index 6af08fa1ddf8..33f608c54b85 100644
--- a/arch/sh/configs/rsk7203_defconfig
+++ b/arch/sh/configs/rsk7203_defconfig
@@ -26,7 +26,7 @@ CONFIG_CPU_FREQ=y
 CONFIG_SH_CPU_FREQ=y
 CONFIG_HEARTBEAT=y
 CONFIG_HZ_1000=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 earlyprintk=serial ignore_loglevel"
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_ZFLAT=y
diff --git a/arch/sh/configs/rts7751r2d1_defconfig b/arch/sh/configs/rts7751r2d1_defconfig
index 96263a4912b7..131699a6daa7 100644
--- a/arch/sh/configs/rts7751r2d1_defconfig
+++ b/arch/sh/configs/rts7751r2d1_defconfig
@@ -11,7 +11,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_RTS7751R2D=y
 CONFIG_RTS7751R2D_1=y
 CONFIG_HEARTBEAT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_HOTPLUG_PCI=y
diff --git a/arch/sh/configs/rts7751r2dplus_defconfig b/arch/sh/configs/rts7751r2dplus_defconfig
index 92e586e6c974..ffa76ad8efaa 100644
--- a/arch/sh/configs/rts7751r2dplus_defconfig
+++ b/arch/sh/configs/rts7751r2dplus_defconfig
@@ -11,7 +11,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_RTS7751R2D=y
 CONFIG_RTS7751R2D_PLUS=y
 CONFIG_HEARTBEAT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_HOTPLUG_PCI=y
diff --git a/arch/sh/configs/sdk7780_defconfig b/arch/sh/configs/sdk7780_defconfig
index 6c719ab4332a..a33f81c41a13 100644
--- a/arch/sh/configs/sdk7780_defconfig
+++ b/arch/sh/configs/sdk7780_defconfig
@@ -22,7 +22,7 @@ CONFIG_SH_DMA=y
 CONFIG_SH_DMA_API=y
 CONFIG_HEARTBEAT=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="mem=128M console=tty0 console=ttySC0,115200 ip=bootp root=/dev/nfs nfsroot=192.168.0.1:/home/rootfs"
 CONFIG_PCI=y
 CONFIG_PCI_DEBUG=y
diff --git a/arch/sh/configs/sdk7786_defconfig b/arch/sh/configs/sdk7786_defconfig
index f776a1d0d277..1daf3dbffc16 100644
--- a/arch/sh/configs/sdk7786_defconfig
+++ b/arch/sh/configs/sdk7786_defconfig
@@ -70,7 +70,7 @@ CONFIG_HOTPLUG_CPU=y
 CONFIG_PREEMPT=y
 CONFIG_INTC_USERIMASK=y
 CONFIG_INTC_BALANCING=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 earlyprintk=sh-sci.1,115200 root=/dev/sda1 nmi_debug=state,debounce rootdelay=5 pmb=iomap ignore_loglevel"
 CONFIG_PCI=y
 CONFIG_PCIEPORTBUS=y
diff --git a/arch/sh/configs/se7206_defconfig b/arch/sh/configs/se7206_defconfig
index 315b04a8dd2f..c729ddb5d2c8 100644
--- a/arch/sh/configs/se7206_defconfig
+++ b/arch/sh/configs/se7206_defconfig
@@ -36,7 +36,7 @@ CONFIG_SH_CPU_FREQ=y
 CONFIG_HEARTBEAT=y
 CONFIG_HZ_1000=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC3,115200 ignore_loglevel earlyprintk=serial"
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_ZFLAT=y
diff --git a/arch/sh/configs/se7343_defconfig b/arch/sh/configs/se7343_defconfig
index 5d6c19338ebf..32fedfd8ae81 100644
--- a/arch/sh/configs/se7343_defconfig
+++ b/arch/sh/configs/se7343_defconfig
@@ -17,7 +17,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_7343_SOLUTION_ENGINE=y
 # CONFIG_SH_TIMER_CMT is not set
 CONFIG_HEARTBEAT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/se7712_defconfig b/arch/sh/configs/se7712_defconfig
index ee6d28ae08de..02a8dcb898db 100644
--- a/arch/sh/configs/se7712_defconfig
+++ b/arch/sh/configs/se7712_defconfig
@@ -22,7 +22,7 @@ CONFIG_SH_SOLUTION_ENGINE=y
 CONFIG_SH_PCLK_FREQ=66666666
 CONFIG_HEARTBEAT=y
 CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda1"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/se7721_defconfig b/arch/sh/configs/se7721_defconfig
index bad921bc10f8..a0ce6eca3bf5 100644
--- a/arch/sh/configs/se7721_defconfig
+++ b/arch/sh/configs/se7721_defconfig
@@ -22,7 +22,7 @@ CONFIG_SH_7721_SOLUTION_ENGINE=y
 CONFIG_SH_PCLK_FREQ=33333333
 CONFIG_HEARTBEAT=y
 CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda2"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/se7724_defconfig b/arch/sh/configs/se7724_defconfig
index a26f7f1841c7..9cd50acd959d 100644
--- a/arch/sh/configs/se7724_defconfig
+++ b/arch/sh/configs/se7724_defconfig
@@ -17,7 +17,7 @@ CONFIG_SH_DMA_API=y
 CONFIG_HEARTBEAT=y
 CONFIG_SECCOMP=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=tty1 console=ttySC3,115200 root=/dev/nfs ip=dhcp memchunk.vpu=4m"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/se7751_defconfig b/arch/sh/configs/se7751_defconfig
index 4a024065bb75..8c2beb3677e2 100644
--- a/arch/sh/configs/se7751_defconfig
+++ b/arch/sh/configs/se7751_defconfig
@@ -12,7 +12,7 @@ CONFIG_MEMORY_START=0x0c000000
 CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_7751_SOLUTION_ENGINE=y
 CONFIG_HEARTBEAT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,38400"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/se7780_defconfig b/arch/sh/configs/se7780_defconfig
index dcd85b858ac8..3be23f65c38e 100644
--- a/arch/sh/configs/se7780_defconfig
+++ b/arch/sh/configs/se7780_defconfig
@@ -14,7 +14,7 @@ CONFIG_MEMORY_SIZE=0x08000000
 CONFIG_SH_7780_SOLUTION_ENGINE=y
 CONFIG_SH_PCLK_FREQ=33333333
 CONFIG_HEARTBEAT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda1"
 CONFIG_PCI=y
 CONFIG_NET=y
diff --git a/arch/sh/configs/sh03_defconfig b/arch/sh/configs/sh03_defconfig
index ff502683132e..87e9805b76d0 100644
--- a/arch/sh/configs/sh03_defconfig
+++ b/arch/sh/configs/sh03_defconfig
@@ -16,7 +16,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_SH03=y
 CONFIG_HEARTBEAT=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 mem=64M root=/dev/nfs"
 CONFIG_PCI=y
 CONFIG_HOTPLUG_PCI=y
diff --git a/arch/sh/configs/sh2007_defconfig b/arch/sh/configs/sh2007_defconfig
index 99975db461d8..8e92c58316db 100644
--- a/arch/sh/configs/sh2007_defconfig
+++ b/arch/sh/configs/sh2007_defconfig
@@ -20,7 +20,7 @@ CONFIG_SH_DMA=y
 CONFIG_SH_DMA_API=y
 CONFIG_NR_DMA_CHANNELS_BOOL=y
 CONFIG_HZ_100=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 ip=dhcp root=/dev/nfs rw nfsroot=/nfs/rootfs,rsize=1024,wsize=1024 earlyprintk=sh-sci.1"
 CONFIG_PCCARD=y
 CONFIG_BINFMT_MISC=y
diff --git a/arch/sh/configs/sh7757lcr_defconfig b/arch/sh/configs/sh7757lcr_defconfig
index a2700ab165af..a15877daff16 100644
--- a/arch/sh/configs/sh7757lcr_defconfig
+++ b/arch/sh/configs/sh7757lcr_defconfig
@@ -21,7 +21,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_SH_SH7757LCR=y
 CONFIG_HEARTBEAT=y
 CONFIG_SECCOMP=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC2,115200 root=/dev/nfs ip=dhcp"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/sh7763rdp_defconfig b/arch/sh/configs/sh7763rdp_defconfig
index 8a6a446f9eb8..351ccabac8a6 100644
--- a/arch/sh/configs/sh7763rdp_defconfig
+++ b/arch/sh/configs/sh7763rdp_defconfig
@@ -14,7 +14,7 @@ CONFIG_MEMORY_START=0x0c000000
 CONFIG_SH_SH7763RDP=y
 CONFIG_SH_PCLK_FREQ=66666666
 CONFIG_SECCOMP=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC2,115200 root=/dev/sda1 rootdelay=10"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/configs/shmin_defconfig b/arch/sh/configs/shmin_defconfig
index c0b6f40d01cc..7cc8725951f5 100644
--- a/arch/sh/configs/shmin_defconfig
+++ b/arch/sh/configs/shmin_defconfig
@@ -18,7 +18,7 @@ CONFIG_FLATMEM_MANUAL=y
 # CONFIG_SH_ADC is not set
 CONFIG_SH_SHMIN=y
 CONFIG_SH_PCLK_FREQ=32000000
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,115200 root=1f01 mtdparts=phys_mapped_flash:64k(firm)ro,-(sys) netdev=34,0x300,eth0 "
 CONFIG_NET=y
 CONFIG_UNIX=y
diff --git a/arch/sh/configs/shx3_defconfig b/arch/sh/configs/shx3_defconfig
index 32ec6eb1eabc..36cac3067cef 100644
--- a/arch/sh/configs/shx3_defconfig
+++ b/arch/sh/configs/shx3_defconfig
@@ -47,7 +47,7 @@ CONFIG_KEXEC=y
 CONFIG_SECCOMP=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 earlyprintk=bios ignore_loglevel"
 CONFIG_BINFMT_MISC=y
 CONFIG_NET=y
diff --git a/arch/sh/configs/titan_defconfig b/arch/sh/configs/titan_defconfig
index ba887f1351be..5aa513d54df0 100644
--- a/arch/sh/configs/titan_defconfig
+++ b/arch/sh/configs/titan_defconfig
@@ -20,7 +20,7 @@ CONFIG_SH_PCLK_FREQ=30000000
 CONFIG_SH_DMA=y
 CONFIG_SH_DMA_API=y
 CONFIG_PREEMPT_VOLUNTARY=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC1,38400N81 root=/dev/nfs ip=:::::eth1:autoconf rw"
 CONFIG_PCI=y
 CONFIG_HOTPLUG_PCI=y
diff --git a/arch/sh/configs/ul2_defconfig b/arch/sh/configs/ul2_defconfig
index 103b81ec1ffb..8d8b6787302f 100644
--- a/arch/sh/configs/ul2_defconfig
+++ b/arch/sh/configs/ul2_defconfig
@@ -18,7 +18,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_HZ_100=y
 CONFIG_KEXEC=y
 CONFIG_PREEMPT=y
-CONFIG_CMDLINE_OVERWRITE=y
+CONFIG_CMDLINE_FORCE=y
 CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/nfs ip=dhcp"
 CONFIG_NET=y
 CONFIG_PACKET=y
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index 4144be650d41..464ccbbd8205 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -32,6 +32,7 @@
 #include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <linux/uaccess.h>
+#include <linux/cmdline.h>
 #include <uapi/linux/mount.h>
 #include <asm/io.h>
 #include <asm/page.h>
@@ -306,15 +307,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(__bss_start);
 	bss_resource.end = virt_to_phys(__bss_stop)-1;
 
-#ifdef CONFIG_CMDLINE_OVERWRITE
-	strlcpy(command_line, CONFIG_CMDLINE, sizeof(command_line));
-#else
-	strlcpy(command_line, COMMAND_LINE, sizeof(command_line));
-#ifdef CONFIG_CMDLINE_EXTEND
-	strlcat(command_line, " ", sizeof(command_line));
-	strlcat(command_line, CONFIG_CMDLINE, sizeof(command_line));
-#endif
-#endif
+	cmdline_build(command_line, COMMAND_LINE);
 
 	/* Save unparsed command line copy for /proc/cmdline */
 	memcpy(boot_command_line, command_line, COMMAND_LINE_SIZE);
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:18 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:18 +0000 (UTC)
Subject: [PATCH v4 16/20] sparc: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <37fc5bd333125270f7032b8f9be225297e6dbe4f.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/sparc/Kconfig           | 18 +-----------------
 arch/sparc/prom/bootstr_64.c |  2 +-
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 164a5254c91c..2a197f3a2549 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -50,6 +50,7 @@ config SPARC
 	select NEED_DMA_MAP_STATE
 	select NEED_SG_DMA_LENGTH
 	select SET_FS
+	select GENERIC_CMDLINE if SPARC64
 
 config SPARC32
 	def_bool !64BIT
@@ -313,23 +314,6 @@ config SCHED_MC
 	  making when dealing with multi-core CPU chips at a cost of slightly
 	  increased overhead in some places. If unsure say N here.
 
-config CMDLINE_BOOL
-	bool "Default bootloader kernel arguments"
-	depends on SPARC64
-
-config CMDLINE
-	string "Initial kernel command string"
-	depends on CMDLINE_BOOL
-	default "console=ttyS0,9600 root=/dev/sda1"
-	help
-	  Say Y here if you want to be able to pass default arguments to
-	  the kernel. This will be overridden by the bootloader, if you
-	  use one (such as SILO). This is most useful if you want to boot
-	  a kernel from TFTP, and want default options to be available
-	  with having them passed on the command line.
-
-	  NOTE: This option WILL override the PROM bootargs setting!
-
 config SUN_PM
 	bool
 	default y if SPARC32
diff --git a/arch/sparc/prom/bootstr_64.c b/arch/sparc/prom/bootstr_64.c
index f1cc34d99eec..4853a45b3de9 100644
--- a/arch/sparc/prom/bootstr_64.c
+++ b/arch/sparc/prom/bootstr_64.c
@@ -25,7 +25,7 @@ struct {
 	char bootstr_buf[BARG_LEN];
 } bootstr_info = {
 	.bootstr_len = BARG_LEN,
-#ifdef CONFIG_CMDLINE
+#if CONFIG_CMDLINE != ""
 	.bootstr_valid = 1,
 	.bootstr_buf = CONFIG_CMDLINE,
 #endif
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:19 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:19 +0000 (UTC)
Subject: [PATCH v4 17/20] xtensa: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <61707011a81a365ccc22a6374f797b6f63cf5030.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/xtensa/Kconfig                         | 15 +--------------
 arch/xtensa/configs/audio_kc705_defconfig   |  1 -
 arch/xtensa/configs/common_defconfig        |  1 -
 arch/xtensa/configs/generic_kc705_defconfig |  1 -
 arch/xtensa/configs/iss_defconfig           |  1 -
 arch/xtensa/configs/nommu_kc705_defconfig   |  1 -
 arch/xtensa/configs/smp_lx200_defconfig     |  1 -
 arch/xtensa/configs/virt_defconfig          |  1 -
 arch/xtensa/configs/xip_kc705_defconfig     |  1 -
 arch/xtensa/kernel/setup.c                  | 10 ++--------
 10 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 9ad6b7b82707..42309f5e9cda 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -16,6 +16,7 @@ config XTENSA
 	select COMMON_CLK
 	select DMA_REMAP if MMU
 	select GENERIC_ATOMIC64
+	select GENERIC_CMDLINE
 	select GENERIC_IRQ_SHOW
 	select GENERIC_PCI_IOMAP
 	select GENERIC_SCHED_CLOCK
@@ -353,20 +354,6 @@ config GENERIC_CALIBRATE_DELAY
 	help
 	  The BogoMIPS value can easily be derived from the CPU frequency.
 
-config CMDLINE_BOOL
-	bool "Default bootloader kernel arguments"
-
-config CMDLINE
-	string "Initial kernel command string"
-	depends on CMDLINE_BOOL
-	default "console=ttyS0,38400 root=/dev/ram"
-	help
-	  On some architectures (EBSA110 and CATS), there is currently no way
-	  for the boot loader to pass arguments to the kernel. For these
-	  architectures, you should supply some command-line options at build
-	  time by entering them here. As a minimum, you should specify the
-	  memory size and the root device (e.g., mem=64M root=/dev/nfs).
-
 config USE_OF
 	bool "Flattened Device Tree support"
 	select OF
diff --git a/arch/xtensa/configs/audio_kc705_defconfig b/arch/xtensa/configs/audio_kc705_defconfig
index 3be62da8089b..5f8661a33ab4 100644
--- a/arch/xtensa/configs/audio_kc705_defconfig
+++ b/arch/xtensa/configs/audio_kc705_defconfig
@@ -27,7 +27,6 @@ CONFIG_PREEMPT=y
 CONFIG_HIGHMEM=y
 # CONFIG_PCI is not set
 CONFIG_XTENSA_PLATFORM_XTFPGA=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon=uart8250,mmio32native,0xfd050020,115200n8 console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=0x38000000 at 0"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="kc705"
diff --git a/arch/xtensa/configs/common_defconfig b/arch/xtensa/configs/common_defconfig
index fa9389869154..6467ebcbb080 100644
--- a/arch/xtensa/configs/common_defconfig
+++ b/arch/xtensa/configs/common_defconfig
@@ -6,7 +6,6 @@ CONFIG_MODULES=y
 CONFIG_MODVERSIONS=y
 CONFIG_XTENSA_PLATFORM_XT2000=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,38400 ip=bootp root=nfs nfsroot=/opt/montavista/pro/devkit/xtensa/linux_be/target memmap=128M at 0"
 CONFIG_BINFMT_MISC=y
 CONFIG_NET=y
diff --git a/arch/xtensa/configs/generic_kc705_defconfig b/arch/xtensa/configs/generic_kc705_defconfig
index e9d6b6f6eca1..8984c4e68a42 100644
--- a/arch/xtensa/configs/generic_kc705_defconfig
+++ b/arch/xtensa/configs/generic_kc705_defconfig
@@ -26,7 +26,6 @@ CONFIG_PREEMPT=y
 CONFIG_HIGHMEM=y
 # CONFIG_PCI is not set
 CONFIG_XTENSA_PLATFORM_XTFPGA=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon=uart8250,mmio32native,0xfd050020,115200n8 console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=0x38000000 at 0"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="kc705"
diff --git a/arch/xtensa/configs/iss_defconfig b/arch/xtensa/configs/iss_defconfig
index 32ce8fb068f0..996ad115264d 100644
--- a/arch/xtensa/configs/iss_defconfig
+++ b/arch/xtensa/configs/iss_defconfig
@@ -2,7 +2,6 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 # CONFIG_PCI is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,38400 eth0=tuntap,,tap0 ip=192.168.168.5:192.168.168.1 root=nfs nfsroot=192.168.168.1:/opt/montavista/pro/devkit/xtensa/linux_be/target memmap=128M at 0"
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_NET=y
diff --git a/arch/xtensa/configs/nommu_kc705_defconfig b/arch/xtensa/configs/nommu_kc705_defconfig
index 88b2e222d4bf..54250bc74885 100644
--- a/arch/xtensa/configs/nommu_kc705_defconfig
+++ b/arch/xtensa/configs/nommu_kc705_defconfig
@@ -33,7 +33,6 @@ CONFIG_PREEMPT=y
 CONFIG_MEMMAP_CACHEATTR=0xfff2442f
 # CONFIG_PCI is not set
 CONFIG_XTENSA_PLATFORM_XTFPGA=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon=uart8250,mmio32native,0x9d050020,115200n8 console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=256M at 0x60000000"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="kc705_nommu"
diff --git a/arch/xtensa/configs/smp_lx200_defconfig b/arch/xtensa/configs/smp_lx200_defconfig
index a47c85638ec1..58b284fd627f 100644
--- a/arch/xtensa/configs/smp_lx200_defconfig
+++ b/arch/xtensa/configs/smp_lx200_defconfig
@@ -30,7 +30,6 @@ CONFIG_HOTPLUG_CPU=y
 # CONFIG_INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX is not set
 # CONFIG_PCI is not set
 CONFIG_XTENSA_PLATFORM_XTFPGA=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon=uart8250,mmio32native,0xfd050020,115200n8 console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=96M at 0"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="lx200mx"
diff --git a/arch/xtensa/configs/virt_defconfig b/arch/xtensa/configs/virt_defconfig
index 6d1387dfa96f..fb4dce2c70a3 100644
--- a/arch/xtensa/configs/virt_defconfig
+++ b/arch/xtensa/configs/virt_defconfig
@@ -21,7 +21,6 @@ CONFIG_XTENSA_VARIANT_DC233C=y
 CONFIG_XTENSA_UNALIGNED_USER=y
 CONFIG_XTENSA_KSEG_512M=y
 CONFIG_HIGHMEM=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=0x80000000 at 0"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="virt"
diff --git a/arch/xtensa/configs/xip_kc705_defconfig b/arch/xtensa/configs/xip_kc705_defconfig
index 4f1ff9531f6a..ae4427773af2 100644
--- a/arch/xtensa/configs/xip_kc705_defconfig
+++ b/arch/xtensa/configs/xip_kc705_defconfig
@@ -26,7 +26,6 @@ CONFIG_KERNEL_LOAD_ADDRESS=0xf6000000
 CONFIG_XTENSA_KSEG_512M=y
 CONFIG_HIGHMEM=y
 CONFIG_XTENSA_PLATFORM_XTFPGA=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon=uart8250,mmio32native,0xfd050020,115200n8 console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw debug memmap=0x38000000 at 0"
 CONFIG_USE_OF=y
 CONFIG_BUILTIN_DTB_SOURCE="kc705"
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index ed184106e4cf..ebb009f112a5 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -25,6 +25,7 @@
 #include <linux/cpu.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
+#include <linux/cmdline.h>
 
 #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
 # include <linux/console.h>
@@ -73,10 +74,6 @@ extern unsigned long loops_per_jiffy;
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
 
-#ifdef CONFIG_CMDLINE_BOOL
-static char default_command_line[COMMAND_LINE_SIZE] __initdata = CONFIG_CMDLINE;
-#endif
-
 #ifdef CONFIG_PARSE_BOOTPARAM
 /*
  * Boot parameter parsing.
@@ -257,10 +254,7 @@ void __init init_arch(bp_tag_t *bp_start)
 	early_init_devtree(dtb_start);
 #endif
 
-#ifdef CONFIG_CMDLINE_BOOL
-	if (!command_line[0])
-		strlcpy(command_line, default_command_line, COMMAND_LINE_SIZE);
-#endif
+	cmdline_build(command_line, command_line);
 
 	/* Early hook for platforms */
 
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:20 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:20 +0000 (UTC)
Subject: [PATCH v4 18/20] x86: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <ab0fd4477964cdbf99e3dd2965a455aa3e738e4b.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/x86/Kconfig        | 45 ++---------------------------------------
 arch/x86/kernel/setup.c | 17 ++--------------
 2 files changed, 4 insertions(+), 58 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a20684d56b4b..66b384228ca3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -104,6 +104,7 @@ config X86
 	select ARCH_USE_QUEUED_SPINLOCKS
 	select ARCH_USE_SYM_ANNOTATIONS
 	select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
+	select ARCH_WANT_CMDLINE_PREPEND_BY_DEFAULT
 	select ARCH_WANT_DEFAULT_BPF_JIT	if X86_64
 	select ARCH_WANTS_DYNAMIC_TASK_STRUCT
 	select ARCH_WANT_HUGE_PMD_SHARE
@@ -118,6 +119,7 @@ config X86
 	select EDAC_SUPPORT
 	select GENERIC_CLOCKEVENTS_BROADCAST	if X86_64 || (X86_32 && X86_LOCAL_APIC)
 	select GENERIC_CLOCKEVENTS_MIN_ADJUST
+	select GENERIC_CMDLINE
 	select GENERIC_CMOS_UPDATE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_CPU_VULNERABILITIES
@@ -2358,49 +2360,6 @@ choice
 
 endchoice
 
-config CMDLINE_BOOL
-	bool "Built-in kernel command line"
-	help
-	  Allow for specifying boot arguments to the kernel at
-	  build time.  On some systems (e.g. embedded ones), it is
-	  necessary or convenient to provide some or all of the
-	  kernel boot arguments with the kernel itself (that is,
-	  to not rely on the boot loader to provide them.)
-
-	  To compile command line arguments into the kernel,
-	  set this option to 'Y', then fill in the
-	  boot arguments in CONFIG_CMDLINE.
-
-	  Systems with fully functional boot loaders (i.e. non-embedded)
-	  should leave this option set to 'N'.
-
-config CMDLINE
-	string "Built-in kernel command string"
-	depends on CMDLINE_BOOL
-	default ""
-	help
-	  Enter arguments here that should be compiled into the kernel
-	  image and used at boot time.  If the boot loader provides a
-	  command line at boot time, it is appended to this string to
-	  form the full kernel command line, when the system boots.
-
-	  However, you can use the CONFIG_CMDLINE_FORCE option to
-	  change this behavior.
-
-	  In most cases, the command line (whether built-in or provided
-	  by the boot loader) should specify the device for the root
-	  file system.
-
-config CMDLINE_FORCE
-	bool "Built-in command line overrides boot loader arguments"
-	depends on CMDLINE_BOOL && CMDLINE != ""
-	help
-	  Set this option to 'Y' to have the kernel ignore the boot loader
-	  command line, and use ONLY the built-in command line.
-
-	  This is used to work around broken boot loaders.  This should
-	  be set to 'N' under normal conditions.
-
 config MODIFY_LDT_SYSCALL
 	bool "Enable the LDT (local descriptor table)" if EXPERT
 	default y
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 6f2de58eeb54..3f274b02e51c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -5,6 +5,7 @@
  * This file contains the setup_arch() code, which handles the architecture-dependent
  * parts of early kernel initialization.
  */
+#include <linux/cmdline.h>
 #include <linux/console.h>
 #include <linux/crash_dump.h>
 #include <linux/dma-map-ops.h>
@@ -161,9 +162,6 @@ unsigned long saved_video_mode;
 #define RAMDISK_LOAD_FLAG		0x4000
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
-#ifdef CONFIG_CMDLINE_BOOL
-static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
-#endif
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 struct edd edd;
@@ -883,18 +881,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = __pa_symbol(__bss_start);
 	bss_resource.end = __pa_symbol(__bss_stop)-1;
 
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_FORCE
-	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
-	if (builtin_cmdline[0]) {
-		/* append boot loader cmdline to builtin */
-		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
-		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
-		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-	}
-#endif
-#endif
+	cmdline_build(boot_command_line, boot_command_line);
 
 	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
 	*cmdline_p = command_line;
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:22 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:22 +0000 (UTC)
Subject: [PATCH v4 20/20] cmdline: Remove CONFIG_CMDLINE_EXTEND
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <349128c2baa37dfcafb61a10d4e6c62f93cfe881.1617375803.git.christophe.leroy@csgroup.eu>

All architectures providing CONFIG_CMDLINE_EXTEND
are now converted to GENERIC_CMDLINE.

This configuration item is not used anymore, drop it.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 include/linux/cmdline.h | 2 +-
 init/Kconfig            | 6 ------
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
index a0773dc365c7..020028e2bdf0 100644
--- a/include/linux/cmdline.h
+++ b/include/linux/cmdline.h
@@ -36,7 +36,7 @@ static __always_inline bool __cmdline_build(char *dst, const char *src)
 
 	len = cmdline_strlcat(dst, src, COMMAND_LINE_SIZE);
 
-	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
+	if (IS_ENABLED(CONFIG_CMDLINE_APPEND))
 		len = cmdline_strlcat(dst, " " CONFIG_CMDLINE, COMMAND_LINE_SIZE);
 
 	if (len < COMMAND_LINE_SIZE - 1)
diff --git a/init/Kconfig b/init/Kconfig
index af0d84662cc2..fa002e3765ab 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -163,12 +163,6 @@ config CMDLINE_FORCE
 	  arguments provided by the bootloader.
 endchoice
 
-config CMDLINE_EXTEND
-	bool
-	default CMDLINE_APPEND
-	help
-	  To be removed once all architectures are converted to generic CMDLINE
-
 config COMPILE_TEST
 	bool "Compile also drivers which will not load"
 	depends on HAS_IOMEM
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:18:21 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri,  2 Apr 2021 15:18:21 +0000 (UTC)
Subject: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>

This converts the architecture to GENERIC_CMDLINE.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/mips/Kconfig                         |  1 +
 arch/mips/Kconfig.debug                   | 44 -----------------------
 arch/mips/configs/ar7_defconfig           |  1 -
 arch/mips/configs/bcm47xx_defconfig       |  1 -
 arch/mips/configs/bcm63xx_defconfig       |  1 -
 arch/mips/configs/bmips_be_defconfig      |  1 -
 arch/mips/configs/bmips_stb_defconfig     |  1 -
 arch/mips/configs/capcella_defconfig      |  1 -
 arch/mips/configs/ci20_defconfig          |  1 -
 arch/mips/configs/cu1000-neo_defconfig    |  1 -
 arch/mips/configs/cu1830-neo_defconfig    |  1 -
 arch/mips/configs/e55_defconfig           |  1 -
 arch/mips/configs/generic_defconfig       |  1 -
 arch/mips/configs/gpr_defconfig           |  1 -
 arch/mips/configs/loongson3_defconfig     |  1 -
 arch/mips/configs/mpc30x_defconfig        |  1 -
 arch/mips/configs/rt305x_defconfig        |  1 -
 arch/mips/configs/tb0219_defconfig        |  1 -
 arch/mips/configs/tb0226_defconfig        |  1 -
 arch/mips/configs/tb0287_defconfig        |  1 -
 arch/mips/configs/workpad_defconfig       |  1 -
 arch/mips/configs/xway_defconfig          |  1 -
 arch/mips/kernel/relocate.c               |  4 +--
 arch/mips/kernel/setup.c                  | 40 ++-------------------
 arch/mips/pic32/pic32mzda/early_console.c |  2 +-
 arch/mips/pic32/pic32mzda/init.c          |  2 --
 26 files changed, 5 insertions(+), 108 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..a65ce9ddbfce 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
 	select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
 	select CPU_PM if CPU_IDLE
 	select GENERIC_ATOMIC64 if !64BIT
+	select GENERIC_CMDLINE
 	select GENERIC_CMOS_UPDATE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_GETTIMEOFDAY
diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 7a8d94cdd493..b5a099c74eb6 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -30,50 +30,6 @@ config EARLY_PRINTK_8250
 config USE_GENERIC_EARLY_PRINTK_8250
 	bool
 
-config CMDLINE_BOOL
-	bool "Built-in kernel command line"
-	help
-	  For most systems, it is firmware or second stage bootloader that
-	  by default specifies the kernel command line options.  However,
-	  it might be necessary or advantageous to either override the
-	  default kernel command line or add a few extra options to it.
-	  For such cases, this option allows you to hardcode your own
-	  command line options directly into the kernel.  For that, you
-	  should choose 'Y' here, and fill in the extra boot arguments
-	  in CONFIG_CMDLINE.
-
-	  The built-in options will be concatenated to the default command
-	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
-	  command line will be ignored and replaced by the built-in string.
-
-	  Most MIPS systems will normally expect 'N' here and rely upon
-	  the command line from the firmware or the second-stage bootloader.
-
-config CMDLINE
-	string "Default kernel command string"
-	depends on CMDLINE_BOOL
-	help
-	  On some platforms, there is currently no way for the boot loader to
-	  pass arguments to the kernel.  For these platforms, and for the cases
-	  when you want to add some extra options to the command line or ignore
-	  the default command line, you can supply some command-line options at
-	  build time by entering them here.  In other cases you can specify
-	  kernel args so that you don't have to set them up in board prom
-	  initialization routines.
-
-	  For more information, see the CMDLINE_BOOL and CMDLINE_OVERRIDE
-	  options.
-
-config CMDLINE_OVERRIDE
-	bool "Built-in command line overrides firmware arguments"
-	depends on CMDLINE_BOOL
-	help
-	  By setting this option to 'Y' you will have your kernel ignore
-	  command line arguments from firmware or second stage bootloader.
-	  Instead, the built-in command line will be used exclusively.
-
-	  Normally, you will choose 'N' here.
-
 config SB1XXX_CORELIS
 	bool "Corelis Debugger"
 	depends on SIBYTE_SB1xxx_SOC
diff --git a/arch/mips/configs/ar7_defconfig b/arch/mips/configs/ar7_defconfig
index cf9c6329b807..5e8adcd799d0 100644
--- a/arch/mips/configs/ar7_defconfig
+++ b/arch/mips/configs/ar7_defconfig
@@ -120,5 +120,4 @@ CONFIG_SQUASHFS=y
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_STRIP_ASM_SYMS=y
 CONFIG_DEBUG_FS=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="rootfstype=squashfs,jffs2"
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index 91ce75edbfb4..690f423509f0 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -77,5 +77,4 @@ CONFIG_DEBUG_INFO_REDUCED=y
 CONFIG_STRIP_ASM_SYMS=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,115200"
diff --git a/arch/mips/configs/bcm63xx_defconfig b/arch/mips/configs/bcm63xx_defconfig
index 861f680184b9..19b15424f669 100644
--- a/arch/mips/configs/bcm63xx_defconfig
+++ b/arch/mips/configs/bcm63xx_defconfig
@@ -65,5 +65,4 @@ CONFIG_PROC_KCORE=y
 # CONFIG_NETWORK_FILESYSTEMS is not set
 # CONFIG_CRYPTO_HW is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,115200"
diff --git a/arch/mips/configs/bmips_be_defconfig b/arch/mips/configs/bmips_be_defconfig
index 032bb51defe8..2db7712acc5d 100644
--- a/arch/mips/configs/bmips_be_defconfig
+++ b/arch/mips/configs/bmips_be_defconfig
@@ -75,5 +75,4 @@ CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon"
diff --git a/arch/mips/configs/bmips_stb_defconfig b/arch/mips/configs/bmips_stb_defconfig
index 625bd2d7e685..bc1659d43ca7 100644
--- a/arch/mips/configs/bmips_stb_defconfig
+++ b/arch/mips/configs/bmips_stb_defconfig
@@ -86,5 +86,4 @@ CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon"
diff --git a/arch/mips/configs/capcella_defconfig b/arch/mips/configs/capcella_defconfig
index 7bf8971af53b..300032a5caa0 100644
--- a/arch/mips/configs/capcella_defconfig
+++ b/arch/mips/configs/capcella_defconfig
@@ -87,5 +87,4 @@ CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_DEFLATE=m
 # CONFIG_CRYPTO_HW is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="mem=32M console=ttyVR0,38400"
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index ab7ebb066834..f874e421b54f 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -203,5 +203,4 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused"
diff --git a/arch/mips/configs/cu1000-neo_defconfig b/arch/mips/configs/cu1000-neo_defconfig
index 9d75f5b77d5d..03cb524967e7 100644
--- a/arch/mips/configs/cu1000-neo_defconfig
+++ b/arch/mips/configs/cu1000-neo_defconfig
@@ -123,5 +123,4 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon clk_ignore_unused"
diff --git a/arch/mips/configs/cu1830-neo_defconfig b/arch/mips/configs/cu1830-neo_defconfig
index 29decd0003c6..d733ccab494e 100644
--- a/arch/mips/configs/cu1830-neo_defconfig
+++ b/arch/mips/configs/cu1830-neo_defconfig
@@ -126,5 +126,4 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon clk_ignore_unused"
diff --git a/arch/mips/configs/e55_defconfig b/arch/mips/configs/e55_defconfig
index fd82b858a8f0..ffc964d1bae7 100644
--- a/arch/mips/configs/e55_defconfig
+++ b/arch/mips/configs/e55_defconfig
@@ -33,5 +33,4 @@ CONFIG_AUTOFS4_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_TMPFS=y
 CONFIG_TMPFS_POSIX_ACL=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyVR0,19200 ide0=0x1f0,0x3f6,40 mem=8M"
diff --git a/arch/mips/configs/generic_defconfig b/arch/mips/configs/generic_defconfig
index 714169e411cf..6003f6c7aa09 100644
--- a/arch/mips/configs/generic_defconfig
+++ b/arch/mips/configs/generic_defconfig
@@ -88,5 +88,4 @@ CONFIG_DEBUG_INFO_REDUCED=y
 CONFIG_DEBUG_FS=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="earlycon"
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 5cb91509bb7c..8998d28b94c8 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@ -306,5 +306,4 @@ CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_DEFLATE=m
 # CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/nfs rw ip=auto"
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 0e79f81217bc..c4f9a236bd1f 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -408,5 +408,4 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="ieee754=relaxed"
diff --git a/arch/mips/configs/mpc30x_defconfig b/arch/mips/configs/mpc30x_defconfig
index d4e038802510..6ecef2a666fc 100644
--- a/arch/mips/configs/mpc30x_defconfig
+++ b/arch/mips/configs/mpc30x_defconfig
@@ -49,5 +49,4 @@ CONFIG_AUTOFS4_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_CONFIGFS_FS=m
 CONFIG_NFS_FS=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="mem=32M console=ttyVR0,19200 ide0=0x170,0x376,73"
diff --git a/arch/mips/configs/rt305x_defconfig b/arch/mips/configs/rt305x_defconfig
index fec5851c164b..c34441ce6621 100644
--- a/arch/mips/configs/rt305x_defconfig
+++ b/arch/mips/configs/rt305x_defconfig
@@ -147,4 +147,3 @@ CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
diff --git a/arch/mips/configs/tb0219_defconfig b/arch/mips/configs/tb0219_defconfig
index 6547f84750b5..ccf20bd156a1 100644
--- a/arch/mips/configs/tb0219_defconfig
+++ b/arch/mips/configs/tb0219_defconfig
@@ -73,5 +73,4 @@ CONFIG_NFS_FS=y
 CONFIG_ROOT_NFS=y
 CONFIG_NFSD=y
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
diff --git a/arch/mips/configs/tb0226_defconfig b/arch/mips/configs/tb0226_defconfig
index 7e099f7c2286..9f78fd00a4f6 100644
--- a/arch/mips/configs/tb0226_defconfig
+++ b/arch/mips/configs/tb0226_defconfig
@@ -68,5 +68,4 @@ CONFIG_NFS_FS=y
 CONFIG_ROOT_NFS=y
 CONFIG_NFSD=m
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="cca=3 mem=32M console=ttyVR0,115200"
diff --git a/arch/mips/configs/tb0287_defconfig b/arch/mips/configs/tb0287_defconfig
index 0d881dd862c0..5529d0dacf94 100644
--- a/arch/mips/configs/tb0287_defconfig
+++ b/arch/mips/configs/tb0287_defconfig
@@ -81,5 +81,4 @@ CONFIG_NFSD_V3=y
 CONFIG_FONTS=y
 CONFIG_FONT_8x8=y
 CONFIG_FONT_8x16=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
diff --git a/arch/mips/configs/workpad_defconfig b/arch/mips/configs/workpad_defconfig
index 891a5f77305d..ee712f7b5575 100644
--- a/arch/mips/configs/workpad_defconfig
+++ b/arch/mips/configs/workpad_defconfig
@@ -61,5 +61,4 @@ CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_NFS_FS=m
 CONFIG_NFSD=m
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE="console=ttyVR0,19200 ide0=0x170,0x376,49 mem=16M"
diff --git a/arch/mips/configs/xway_defconfig b/arch/mips/configs/xway_defconfig
index 9abbc0debc2a..ebd8dbdb0695 100644
--- a/arch/mips/configs/xway_defconfig
+++ b/arch/mips/configs/xway_defconfig
@@ -153,4 +153,3 @@ CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 499a5357c09f..13c955027696 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -244,15 +244,13 @@ static inline __init unsigned long get_random_boot(void)
 static inline __init bool kaslr_disabled(void)
 {
 	char *str;
-
-#if defined(CONFIG_CMDLINE_BOOL)
 	const char *builtin_cmdline = CONFIG_CMDLINE;
 
 	str = strstr(builtin_cmdline, "nokaslr");
 	if (str == builtin_cmdline ||
 	    (str > builtin_cmdline && *(str - 1) == ' '))
 		return true;
-#endif
+
 	str = strstr(arcs_cmdline, "nokaslr");
 	if (str == arcs_cmdline || (str > arcs_cmdline && *(str - 1) == ' '))
 		return true;
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 279be0153f8b..f2270528011b 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -29,6 +29,7 @@
 #include <linux/of_fdt.h>
 #include <linux/dmi.h>
 #include <linux/crash_dump.h>
+#include <linux/cmdline.h>
 
 #include <asm/addrspace.h>
 #include <asm/bootinfo.h>
@@ -66,12 +67,6 @@ EXPORT_SYMBOL(mips_machtype);
 static char __initdata command_line[COMMAND_LINE_SIZE];
 char __initdata arcs_cmdline[COMMAND_LINE_SIZE];
 
-#ifdef CONFIG_CMDLINE_BOOL
-static const char builtin_cmdline[] __initconst = CONFIG_CMDLINE;
-#else
-static const char builtin_cmdline[] __initconst = "";
-#endif
-
 /*
  * mips_io_port_base is the begin of the address space to which x86 style
  * I/O ports are mapped.
@@ -546,28 +541,6 @@ static void __init bootcmdline_init(void)
 {
 	bool dt_bootargs = false;
 
-	/*
-	 * If CMDLINE_OVERRIDE is enabled then initializing the command line is
-	 * trivial - we simply use the built-in command line unconditionally &
-	 * unmodified.
-	 */
-	if (IS_ENABLED(CONFIG_CMDLINE_OVERRIDE)) {
-		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-		return;
-	}
-
-	/*
-	 * If the user specified a built-in command line &
-	 * MIPS_CMDLINE_BUILTIN_EXTEND, then the built-in command line is
-	 * prepended to arguments from the bootloader or DT so we'll copy them
-	 * to the start of boot_command_line here. Otherwise, empty
-	 * boot_command_line to undo anything early_init_dt_scan_chosen() did.
-	 */
-	if (IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND))
-		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-	else
-		boot_command_line[0] = 0;
-
 #ifdef CONFIG_OF_EARLY_FLATTREE
 	/*
 	 * If we're configured to take boot arguments from DT, look for those
@@ -585,16 +558,7 @@ static void __init bootcmdline_init(void)
 	 * plat_mem_setup() should have filled arcs_cmdline with arguments from
 	 * the bootloader.
 	 */
-	if (IS_ENABLED(CONFIG_MIPS_CMDLINE_DTB_EXTEND) || !dt_bootargs)
-		bootcmdline_append(arcs_cmdline, COMMAND_LINE_SIZE);
-
-	/*
-	 * If the user specified a built-in command line & we didn't already
-	 * prepend it, we append it to boot_command_line here.
-	 */
-	if (IS_ENABLED(CONFIG_CMDLINE_BOOL) &&
-	    !IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND))
-		bootcmdline_append(builtin_cmdline, COMMAND_LINE_SIZE);
+	cmdline_build(boot_command_line, arcs_cmdline);
 }
 
 /*
diff --git a/arch/mips/pic32/pic32mzda/early_console.c b/arch/mips/pic32/pic32mzda/early_console.c
index 25372e62783b..94d3a5ba5e10 100644
--- a/arch/mips/pic32/pic32mzda/early_console.c
+++ b/arch/mips/pic32/pic32mzda/early_console.c
@@ -75,7 +75,7 @@ static char * __init pic32_getcmdline(void)
 	 * arch_mem_init() has not been called yet, so we don't have a real
 	 * command line setup if using CONFIG_CMDLINE_BOOL.
 	 */
-#ifdef CONFIG_CMDLINE_OVERRIDE
+#ifdef CONFIG_CMDLINE_FORCE
 	return CONFIG_CMDLINE;
 #else
 	return fw_getcmdline();
diff --git a/arch/mips/pic32/pic32mzda/init.c b/arch/mips/pic32/pic32mzda/init.c
index 764f2d022fae..39fdacbbac56 100644
--- a/arch/mips/pic32/pic32mzda/init.c
+++ b/arch/mips/pic32/pic32mzda/init.c
@@ -40,9 +40,7 @@ void __init plat_mem_setup(void)
 	pr_info("Found following command lines\n");
 	pr_info(" boot_command_line: %s\n", boot_command_line);
 	pr_info(" arcs_cmdline     : %s\n", arcs_cmdline);
-#ifdef CONFIG_CMDLINE_BOOL
 	pr_info(" builtin_cmdline  : %s\n", CONFIG_CMDLINE);
-#endif
 	if (dtb != __dtb_start)
 		strlcpy(arcs_cmdline, boot_command_line, COMMAND_LINE_SIZE);
 
-- 
2.25.0



From christophe.leroy at csgroup.eu  Fri Apr  2 16:19:02 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:19:02 +0200
Subject: [PATCH v3 05/17] arm: Convert to GENERIC_CMDLINE
In-Reply-To: <CAL_Jsq+LF-s5K4Jwd5jCHrU8271L5WCiGb0tR7aTUa8ddHF1YQ@mail.gmail.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <7362e4f6a5f5b79e6ad3fd3cec3183a4a283f7fc.1616765870.git.christophe.leroy@csgroup.eu>
 <CAL_Jsq+LF-s5K4Jwd5jCHrU8271L5WCiGb0tR7aTUa8ddHF1YQ@mail.gmail.com>
Message-ID: <f0ef9e09-982a-e44a-1a5f-0dd56a151789@csgroup.eu>



Le 26/03/2021 ? 16:47, Rob Herring a ?crit?:
> On Fri, Mar 26, 2021 at 7:44 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>> This converts the architecture to GENERIC_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   arch/arm/Kconfig              | 38 +----------------------------------
>>   arch/arm/kernel/atags_parse.c | 15 +++++---------
>>   2 files changed, 6 insertions(+), 47 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5da96f5df48f..67bc75f2da81 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -50,6 +50,7 @@ config ARM
>>          select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
>>          select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
>>          select GENERIC_CLOCKEVENTS_BROADCAST if SMP
>> +       select GENERIC_CMDLINE if ATAGS
> 
> Don't we need this enabled for !ATAGS (i.e. DT boot)?
> 
> Can we always enable GENERIC_CMDLINE for OF_EARLY_FLATTREE?
> 

Done in v4


From christophe.leroy at csgroup.eu  Fri Apr  2 16:20:45 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:20:45 +0200
Subject: [PATCH v3 00/17] Implement GENERIC_CMDLINE
In-Reply-To: <CAL_JsqLQTM0Xw_skFeysJyYAyW3B=0u0xgePgoUYSpKaWw9SjQ@mail.gmail.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <CAL_JsqLQTM0Xw_skFeysJyYAyW3B=0u0xgePgoUYSpKaWw9SjQ@mail.gmail.com>
Message-ID: <da5d4c76-2102-25bb-1b6e-ea0349222a31@csgroup.eu>



Le 26/03/2021 ? 16:04, Rob Herring a ?crit?:
> On Fri, Mar 26, 2021 at 7:44 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>> The purpose of this series is to improve and enhance the
>> handling of kernel boot arguments.
>>
>> It is first focussed on powerpc but also extends the capability
>> for other arches.
>>
>> This is based on suggestion from Daniel Walker <danielwa at cisco.com>
>>
>> Main changes in V3:
>> - Also accept destination equal to source in cmdline_build() by setting a tmp buffer in __initdata. Powerpc provides different source and destination and call __cmdline_build() directly.
>> - Taken comments received from Will and Rob
>> - Converted all architectures (Only tested on powerpc)
>>
>> Christophe Leroy (17):
>>    cmdline: Add generic function to build command line.
>>    drivers: of: use cmdline building function
>>    cmdline: Gives architectures opportunity to use generically defined
>>      boot cmdline manipulation
>>    powerpc: Convert to GENERIC_CMDLINE
>>    arm: Convert to GENERIC_CMDLINE
>>    arm64: Convert to GENERIC_CMDLINE
>>    hexagon: Convert to GENERIC_CMDLINE
>>    microblaze: Convert to GENERIC_CMDLINE
>>    nios2: Convert to GENERIC_CMDLINE
>>    openrisc: Convert to GENERIC_CMDLINE
>>    riscv: Convert to GENERIC_CMDLINE
>>    sh: Convert to GENERIC_CMDLINE
>>    sparc: Convert to GENERIC_CMDLINE
>>    xtensa: Convert to GENERIC_CMDLINE
>>    x86: Convert to GENERIC_CMDLINE
>>    mips: Convert to GENERIC_CMDLINE
>>    cmdline: Remove CONFIG_CMDLINE_EXTEND
>>
>>   arch/arm/Kconfig                            | 38 +-------------
>>   arch/arm/kernel/atags_parse.c               | 15 ++----
>>   arch/arm64/Kconfig                          | 33 +-----------
>>   arch/arm64/kernel/idreg-override.c          |  9 ++--
>>   arch/hexagon/Kconfig                        | 11 +---
>>   arch/hexagon/kernel/setup.c                 | 10 +---
>>   arch/microblaze/Kconfig                     | 24 +--------
>>   arch/microblaze/configs/mmu_defconfig       |  2 +-
>>   arch/microblaze/kernel/head.S               |  4 +-
>>   arch/mips/Kconfig                           |  1 +
>>   arch/mips/Kconfig.debug                     | 44 ----------------
>>   arch/mips/configs/ar7_defconfig             |  1 -
>>   arch/mips/configs/bcm47xx_defconfig         |  1 -
>>   arch/mips/configs/bcm63xx_defconfig         |  1 -
>>   arch/mips/configs/bmips_be_defconfig        |  1 -
>>   arch/mips/configs/bmips_stb_defconfig       |  1 -
>>   arch/mips/configs/capcella_defconfig        |  1 -
>>   arch/mips/configs/ci20_defconfig            |  1 -
>>   arch/mips/configs/cu1000-neo_defconfig      |  1 -
>>   arch/mips/configs/cu1830-neo_defconfig      |  1 -
>>   arch/mips/configs/e55_defconfig             |  1 -
>>   arch/mips/configs/generic_defconfig         |  1 -
>>   arch/mips/configs/gpr_defconfig             |  1 -
>>   arch/mips/configs/loongson3_defconfig       |  1 -
>>   arch/mips/configs/mpc30x_defconfig          |  1 -
>>   arch/mips/configs/rt305x_defconfig          |  1 -
>>   arch/mips/configs/tb0219_defconfig          |  1 -
>>   arch/mips/configs/tb0226_defconfig          |  1 -
>>   arch/mips/configs/tb0287_defconfig          |  1 -
>>   arch/mips/configs/workpad_defconfig         |  1 -
>>   arch/mips/configs/xway_defconfig            |  1 -
>>   arch/mips/kernel/relocate.c                 |  4 +-
>>   arch/mips/kernel/setup.c                    | 40 +--------------
>>   arch/mips/pic32/pic32mzda/early_console.c   |  2 +-
>>   arch/mips/pic32/pic32mzda/init.c            |  2 -
>>   arch/nios2/Kconfig                          | 24 +--------
>>   arch/nios2/kernel/setup.c                   | 13 ++---
>>   arch/openrisc/Kconfig                       | 10 +---
>>   arch/powerpc/Kconfig                        | 37 +------------
>>   arch/powerpc/kernel/prom_init.c             | 17 +++---
>>   arch/riscv/Kconfig                          | 44 +---------------
>>   arch/riscv/kernel/setup.c                   |  5 +-
>>   arch/sh/Kconfig                             | 30 +----------
>>   arch/sh/configs/ap325rxa_defconfig          |  2 +-
>>   arch/sh/configs/dreamcast_defconfig         |  2 +-
>>   arch/sh/configs/ecovec24-romimage_defconfig |  2 +-
>>   arch/sh/configs/ecovec24_defconfig          |  2 +-
>>   arch/sh/configs/edosk7760_defconfig         |  2 +-
>>   arch/sh/configs/espt_defconfig              |  2 +-
>>   arch/sh/configs/j2_defconfig                |  2 +-
>>   arch/sh/configs/kfr2r09-romimage_defconfig  |  2 +-
>>   arch/sh/configs/kfr2r09_defconfig           |  2 +-
>>   arch/sh/configs/lboxre2_defconfig           |  2 +-
>>   arch/sh/configs/microdev_defconfig          |  2 +-
>>   arch/sh/configs/migor_defconfig             |  2 +-
>>   arch/sh/configs/polaris_defconfig           |  2 +-
>>   arch/sh/configs/r7780mp_defconfig           |  2 +-
>>   arch/sh/configs/r7785rp_defconfig           |  2 +-
>>   arch/sh/configs/rsk7201_defconfig           |  2 +-
>>   arch/sh/configs/rsk7203_defconfig           |  2 +-
>>   arch/sh/configs/rts7751r2d1_defconfig       |  2 +-
>>   arch/sh/configs/rts7751r2dplus_defconfig    |  2 +-
>>   arch/sh/configs/sdk7780_defconfig           |  2 +-
>>   arch/sh/configs/sdk7786_defconfig           |  2 +-
>>   arch/sh/configs/se7206_defconfig            |  2 +-
>>   arch/sh/configs/se7343_defconfig            |  2 +-
>>   arch/sh/configs/se7712_defconfig            |  2 +-
>>   arch/sh/configs/se7721_defconfig            |  2 +-
>>   arch/sh/configs/se7724_defconfig            |  2 +-
>>   arch/sh/configs/se7751_defconfig            |  2 +-
>>   arch/sh/configs/se7780_defconfig            |  2 +-
>>   arch/sh/configs/sh03_defconfig              |  2 +-
>>   arch/sh/configs/sh2007_defconfig            |  2 +-
>>   arch/sh/configs/sh7757lcr_defconfig         |  2 +-
>>   arch/sh/configs/sh7763rdp_defconfig         |  2 +-
>>   arch/sh/configs/shmin_defconfig             |  2 +-
>>   arch/sh/configs/shx3_defconfig              |  2 +-
>>   arch/sh/configs/titan_defconfig             |  2 +-
>>   arch/sh/configs/ul2_defconfig               |  2 +-
>>   arch/sh/kernel/setup.c                      | 11 +---
>>   arch/sparc/Kconfig                          | 18 +------
>>   arch/sparc/prom/bootstr_64.c                |  2 +-
>>   arch/x86/Kconfig                            | 45 +---------------
>>   arch/x86/kernel/setup.c                     | 17 +-----
>>   arch/xtensa/Kconfig                         | 15 +-----
>>   arch/xtensa/configs/audio_kc705_defconfig   |  1 -
>>   arch/xtensa/configs/common_defconfig        |  1 -
>>   arch/xtensa/configs/generic_kc705_defconfig |  1 -
>>   arch/xtensa/configs/iss_defconfig           |  1 -
>>   arch/xtensa/configs/nommu_kc705_defconfig   |  1 -
>>   arch/xtensa/configs/smp_lx200_defconfig     |  1 -
>>   arch/xtensa/configs/virt_defconfig          |  1 -
>>   arch/xtensa/configs/xip_kc705_defconfig     |  1 -
>>   arch/xtensa/kernel/setup.c                  | 10 +---
>>   drivers/firmware/efi/libstub/x86-stub.c     | 26 +++++-----
> 
> You missed efi-stub.c which has CMDLINE_EXTEND.
> 

I think I completely missed EFI.

Reworked in V4.



From christophe.leroy at csgroup.eu  Fri Apr  2 16:21:51 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:21:51 +0200
Subject: [PATCH v3 11/17] riscv: Convert to GENERIC_CMDLINE
In-Reply-To: <CAL_JsqK2TT=j1QjiRgTYQvwHqivE-3HgYo2JzxTJSWO2wvK69Q@mail.gmail.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <46745e07b04139a22b5bd01dc37df97e6981e643.1616765870.git.christophe.leroy@csgroup.eu>
 <87zgyqdn3d.fsf@igel.home> <81a7e63f-57d4-5c81-acc5-35278fe5bb04@csgroup.eu>
 <CAL_JsqK2TT=j1QjiRgTYQvwHqivE-3HgYo2JzxTJSWO2wvK69Q@mail.gmail.com>
Message-ID: <d71c83a8-cc10-b435-5a28-70ca4df6fdf9@csgroup.eu>



Le 26/03/2021 ? 16:26, Rob Herring a ?crit?:
> On Fri, Mar 26, 2021 at 8:20 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>>
>>
>> Le 26/03/2021 ? 15:08, Andreas Schwab a ?crit :
>>> On M?r 26 2021, Christophe Leroy wrote:
>>>
>>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>>>> index f8f15332caa2..e7c91ee478d1 100644
>>>> --- a/arch/riscv/kernel/setup.c
>>>> +++ b/arch/riscv/kernel/setup.c
>>>> @@ -20,6 +20,7 @@
>>>>    #include <linux/swiotlb.h>
>>>>    #include <linux/smp.h>
>>>>    #include <linux/efi.h>
>>>> +#include <linux/cmdline.h>
>>>>
>>>>    #include <asm/cpu_ops.h>
>>>>    #include <asm/early_ioremap.h>
>>>> @@ -228,10 +229,8 @@ static void __init parse_dtb(void)
>>>>       }
>>>>
>>>>       pr_err("No DTB passed to the kernel\n");
>>>> -#ifdef CONFIG_CMDLINE_FORCE
>>>> -    strlcpy(boot_command_line, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
>>>> +    cmdline_build(boot_command_line, NULL, COMMAND_LINE_SIZE);
>>>>       pr_info("Forcing kernel command line to: %s\n", boot_command_line);
>>>
>>> Shouldn't that message become conditional in some way?
>>>
>>
>> You are right, I did something similar on ARM but looks like I missed it on RISCV.
> 
> How is this hunk even useful? Under what conditions can you boot
> without a DTB? Even with a built-in DTB, the DT cmdline handling would
> be called.
> 

Don't know, I wanted to keep as is today.

Do you think the hunk should be completely removed ?



From christophe.leroy at csgroup.eu  Fri Apr  2 16:23:32 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:23:32 +0200
Subject: [PATCH v3 01/17] cmdline: Add generic function to build command
 line.
In-Reply-To: <CAL_JsqKr3xekKSo3DtQvOOw_VoGC=FUTagZGY5g=CGGGdUZSMQ@mail.gmail.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <878228ad88df38f8914c7aa25dede3ed05c50f48.1616765869.git.christophe.leroy@csgroup.eu>
 <CAL_JsqKr3xekKSo3DtQvOOw_VoGC=FUTagZGY5g=CGGGdUZSMQ@mail.gmail.com>
Message-ID: <53aa0b8c-4ee3-a6af-6fb8-2edc5cd79ea5@csgroup.eu>



Le 26/03/2021 ? 16:42, Rob Herring a ?crit?:
> On Fri, Mar 26, 2021 at 7:44 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>> This code provides architectures with a way to build command line
>> based on what is built in the kernel and what is handed over by the
>> bootloader, based on selected compile-time options.
> 
> Note that I have this patch pending:
> 
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210316193820.3137-1-alex at ghiti.fr/
> 
> It's going to need to be adapted for this. I've held off applying to
> see if this gets settled.

When reworking EFI, I found out that they are a similar handling, which in addition takes care of 
space inside quotes.

I added something similar now in cmdline_build() function.


> 
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>> v3:
>> - Addressed comments from Will
>> - Added capability to have src == dst
>> ---
>>   include/linux/cmdline.h | 57 +++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 57 insertions(+)
>>   create mode 100644 include/linux/cmdline.h
>>
>> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>> new file mode 100644
>> index 000000000000..dea87edd41be
>> --- /dev/null
>> +++ b/include/linux/cmdline.h
>> @@ -0,0 +1,57 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_CMDLINE_H
>> +#define _LINUX_CMDLINE_H
>> +
>> +#include <linux/string.h>
>> +
>> +/* Allow architectures to override strlcat, powerpc can't use strings so early */
>> +#ifndef cmdline_strlcat
>> +#define cmdline_strlcat strlcat
>> +#endif
>> +
>> +/*
>> + * This function will append or prepend a builtin command line to the command
>> + * line provided by the bootloader. Kconfig options can be used to alter
>> + * the behavior of this builtin command line.
>> + * @dst: The destination of the final appended/prepended string.
>> + * @src: The starting string or NULL if there isn't one.
>> + * @len: the length of dest buffer.
>> + */
>> +static __always_inline void __cmdline_build(char *dst, const char *src, size_t len)
>> +{
>> +       if (!len || src == dst)
>> +               return;
>> +
>> +       if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !src) {
>> +               dst[0] = 0;
>> +               cmdline_strlcat(dst, CONFIG_CMDLINE, len);
>> +               return;
>> +       }
>> +
>> +       if (dst != src)
>> +               dst[0] = 0;
>> +
>> +       if (IS_ENABLED(CONFIG_CMDLINE_PREPEND))
>> +               cmdline_strlcat(dst, CONFIG_CMDLINE " ", len);
>> +
>> +       cmdline_strlcat(dst, src, len);
>> +
>> +       if (IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> 
> Should be APPEND.
> 
>> +               cmdline_strlcat(dst, " " CONFIG_CMDLINE, len);
>> +}
>> +
>> +#define cmdline_build(dst, src, len) do {                              \
> 
> Perhaps a comment why we need this to be a define.
> 
>> +       char *__c_dst = (dst);                                          \
>> +       const char *__c_src = (src);                                    \
>> +                                                                       \
>> +       if (__c_src == __c_dst) {                                       \
>> +               static char __c_tmp[COMMAND_LINE_SIZE] __initdata = ""; \
>> +                                                                       \
>> +               cmdline_strlcat(__c_tmp, __c_src, COMMAND_LINE_SIZE);   \
>> +               __cmdline_build(__c_dst, __c_tmp, (len));               \
>> +       } else {                                                        \
>> +               __cmdline_build(__c_dst, __c_src, (len));               \
>> +       }                                                               \
>> +} while (0)
>> +
>> +#endif /* _LINUX_CMDLINE_H */
>> --
>> 2.25.0
>>


From christophe.leroy at csgroup.eu  Fri Apr  2 16:24:05 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:24:05 +0200
Subject: [PATCH v3 05/17] arm: Convert to GENERIC_CMDLINE
In-Reply-To: <CAL_Jsq+LF-s5K4Jwd5jCHrU8271L5WCiGb0tR7aTUa8ddHF1YQ@mail.gmail.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <7362e4f6a5f5b79e6ad3fd3cec3183a4a283f7fc.1616765870.git.christophe.leroy@csgroup.eu>
 <CAL_Jsq+LF-s5K4Jwd5jCHrU8271L5WCiGb0tR7aTUa8ddHF1YQ@mail.gmail.com>
Message-ID: <84ca838c-d77b-0142-7f45-b8b95c03d81e@csgroup.eu>



Le 26/03/2021 ? 16:47, Rob Herring a ?crit?:
> On Fri, Mar 26, 2021 at 7:44 AM Christophe Leroy
> <christophe.leroy at csgroup.eu> wrote:
>>
>> This converts the architecture to GENERIC_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   arch/arm/Kconfig              | 38 +----------------------------------
>>   arch/arm/kernel/atags_parse.c | 15 +++++---------
>>   2 files changed, 6 insertions(+), 47 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5da96f5df48f..67bc75f2da81 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -50,6 +50,7 @@ config ARM
>>          select GENERIC_ARCH_TOPOLOGY if ARM_CPU_TOPOLOGY
>>          select GENERIC_ATOMIC64 if CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI
>>          select GENERIC_CLOCKEVENTS_BROADCAST if SMP
>> +       select GENERIC_CMDLINE if ATAGS
> 
> Don't we need this enabled for !ATAGS (i.e. DT boot)?
> 
> Can we always enable GENERIC_CMDLINE for OF_EARLY_FLATTREE?
> 

Yes missed it in v3 after your comment on v2. Done in v4.


From christophe.leroy at csgroup.eu  Fri Apr  2 16:33:06 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:33:06 +0200
Subject: [PATCH v3 01/17] cmdline: Add generic function to build command
 line.
In-Reply-To: <20210330172714.GR109100@zorba>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <878228ad88df38f8914c7aa25dede3ed05c50f48.1616765869.git.christophe.leroy@csgroup.eu>
 <20210330172714.GR109100@zorba>
Message-ID: <9c74d82f-f58f-1ccb-bf22-8eb02a4cd55d@csgroup.eu>



Le 30/03/2021 ? 19:27, Daniel Walker a ?crit?:
> On Fri, Mar 26, 2021 at 01:44:48PM +0000, Christophe Leroy wrote:
>> This code provides architectures with a way to build command line
>> based on what is built in the kernel and what is handed over by the
>> bootloader, based on selected compile-time options.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>> v3:
>> - Addressed comments from Will
>> - Added capability to have src == dst
>> ---
>>   include/linux/cmdline.h | 57 +++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 57 insertions(+)
>>   create mode 100644 include/linux/cmdline.h
>>
>> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>> new file mode 100644
>> index 000000000000..dea87edd41be
>> --- /dev/null
>> +++ b/include/linux/cmdline.h
>> @@ -0,0 +1,57 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_CMDLINE_H
>> +#define _LINUX_CMDLINE_H
>> +
>> +#include <linux/string.h>
>> +
>> +/* Allow architectures to override strlcat, powerpc can't use strings so early */
>> +#ifndef cmdline_strlcat
>> +#define cmdline_strlcat strlcat
>> +#endif
>> +
>> +/*
>> + * This function will append or prepend a builtin command line to the command
>> + * line provided by the bootloader. Kconfig options can be used to alter
>> + * the behavior of this builtin command line.
>> + * @dst: The destination of the final appended/prepended string.
>> + * @src: The starting string or NULL if there isn't one.
>> + * @len: the length of dest buffer.
>> + */
> 
> Append or prepend ? Cisco requires both at the same time. This is why my
> implementation provides both. I can't use this with both at once.
> 

I think it can be added as a second step if dimmed necessary. The feeling I have from all the 
discussion is that it's not what people from the community are looking for at the moment.

Anyway, once all architectures are moved to generic handling, I believe it is then easier to split 
CONFIG_CMDLINE in two configuration items in order to provide both appending and prepending at the 
same time.

I see some concerns about risk of double changes, but I have focussed in changing as little as 
possible the existing configuration items, in order to minimise that.


From christophe.leroy at csgroup.eu  Fri Apr  2 16:33:59 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:33:59 +0200
Subject: [PATCH v3 09/17] nios2: Convert to GENERIC_CMDLINE
In-Reply-To: <BY5PR11MB38934E74AF74D40379E46AB9CC7E9@BY5PR11MB3893.namprd11.prod.outlook.com>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <85b1dc6339351cbc46d179e8fdb9dfc398e58303.1616765870.git.christophe.leroy@csgroup.eu>
 <BY5PR11MB38934E74AF74D40379E46AB9CC7E9@BY5PR11MB3893.namprd11.prod.outlook.com>
Message-ID: <18f89697-5612-6a1a-ab9d-8842c1b943db@csgroup.eu>



Le 29/03/2021 ? 03:35, Tan, Ley Foon a ?crit?:
> 
> 
>> -----Original Message-----
>> From: Christophe Leroy <christophe.leroy at csgroup.eu>
>> Sent: Friday, March 26, 2021 9:45 PM
>> To: will at kernel.org; danielwa at cisco.com; robh at kernel.org;
>> daniel at gimpelevich.san-francisco.ca.us
>> Cc: linux-arch at vger.kernel.org; devicetree at vger.kernel.org; linuxppc-
>> dev at lists.ozlabs.org; linux-kernel at vger.kernel.org; linuxppc-
>> dev at lists.ozlabs.org; linux-arm-kernel at lists.infradead.org; microblaze
>> <monstr at monstr.eu>; linux-mips at vger.kernel.org; Tan, Ley Foon
>> <ley.foon.tan at intel.com>; openrisc at lists.librecores.org; linux-
>> hexagon at vger.kernel.org; linux-riscv at lists.infradead.org; x86 at kernel.org;
>> linux-xtensa at linux-xtensa.org; linux-sh at vger.kernel.org;
>> sparclinux at vger.kernel.org
>> Subject: [PATCH v3 09/17] nios2: Convert to GENERIC_CMDLINE
>>
>> This converts the architecture to GENERIC_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   arch/nios2/Kconfig        | 24 +-----------------------
>>   arch/nios2/kernel/setup.c | 13 ++++---------
>>   2 files changed, 5 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig index
>> c24955c81c92..f66c97b15813 100644
>> --- a/arch/nios2/Kconfig
>> +++ b/arch/nios2/Kconfig
>> @@ -90,31 +90,9 @@ config NIOS2_ALIGNMENT_TRAP
>>
>>   comment "Boot options"
>>
>> -config CMDLINE_BOOL
>> -	bool "Default bootloader kernel arguments"
>> -	default y
>> -
>> -config CMDLINE
>> -	string "Default kernel command string"
>> -	default ""
>> -	depends on CMDLINE_BOOL
>> -	help
>> -	  On some platforms, there is currently no way for the boot loader to
>> -	  pass arguments to the kernel. For these platforms, you can supply
>> -	  some command-line options at build time by entering them here.  In
>> -	  other cases you can specify kernel args so that you don't have
>> -	  to set them up in board prom initialization routines.
>> -
>> -config CMDLINE_FORCE
>> -	bool "Force default kernel command string"
>> -	depends on CMDLINE_BOOL
>> -	help
>> -	  Set this to have arguments from the default kernel command string
>> -	  override those passed by the boot loader.
>> -
>>   config NIOS2_CMDLINE_IGNORE_DTB
>>   	bool "Ignore kernel command string from DTB"
>> -	depends on CMDLINE_BOOL
>> +	depends on CMDLINE != ""
>>   	depends on !CMDLINE_FORCE
>>   	default y
>>   	help
> 
> Missing " select GENERIC_CMDLINE" ?

Added in v4

Thanks
Christophe


From christophe.leroy at csgroup.eu  Fri Apr  2 16:36:12 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 2 Apr 2021 17:36:12 +0200
Subject: [PATCH v3 12/17] sh: Convert to GENERIC_CMDLINE
In-Reply-To: <6b76649009943f2893fdfded22becd41db2fe1f7.1616765870.git.christophe.leroy@csgroup.eu>
References: <cover.1616765869.git.christophe.leroy@csgroup.eu>
 <6b76649009943f2893fdfded22becd41db2fe1f7.1616765870.git.christophe.leroy@csgroup.eu>
Message-ID: <d672dec1-6fcb-d5dc-a551-2a99e6dd6976@csgroup.eu>



Le 26/03/2021 ? 14:44, Christophe Leroy a ?crit?:
> This converts the architecture to GENERIC_CMDLINE.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---

> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index e798e55915c2..fab84f62448c 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -16,6 +16,7 @@ config SUPERH
>   	select CPU_NO_EFFICIENT_FFS
>   	select DMA_DECLARE_COHERENT
>   	select GENERIC_ATOMIC64
> +	select GENERIC_CMDLINE
>   	select GENERIC_CMOS_UPDATE if SH_SH03 || SH_DREAMCAST
>   	select GENERIC_IDLE_POLL_SETUP
>   	select GENERIC_IRQ_SHOW
> @@ -742,35 +743,6 @@ config ROMIMAGE_MMCIF
>   	  first part of the romImage which in turn loads the rest the kernel
>   	  image to RAM using the MMCIF hardware block.
>   
> -choice
> -	prompt "Kernel command line"
> -	optional
> -	default CMDLINE_OVERWRITE
> -	help
> -	  Setting this option allows the kernel command line arguments
> -	  to be set.
> -
> -config CMDLINE_OVERWRITE
> -	bool "Overwrite bootloader kernel arguments"
> -	help
> -	  Given string will overwrite any arguments passed in by
> -	  a bootloader.
> -
> -config CMDLINE_EXTEND
> -	bool "Extend bootloader kernel arguments"
> -	help
> -	  Given string will be concatenated with arguments passed in
> -	  by a bootloader.
> -
> -endchoice
> -
> -config CMDLINE
> -	string "Kernel command line arguments string"
> -	depends on CMDLINE_OVERWRITE || CMDLINE_EXTEND
> -	default "console=ttySC1,115200"
> -
> -endmenu
> -

That "endmenu" shall not be removed.

Fixed in v4,

Thanks to Rob L. for the report.
Christophe

>   menu "Bus options"
>   
>   config SUPERHYWAY


From syednwaris at gmail.com  Fri Apr  2 17:34:25 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 22:04:25 +0530
Subject: [PATCH v4 3/3] gpio: xilinx: Utilize generic bitmap_get_value and
 _set_value
In-Reply-To: <00d085d4068be651c58a61564926d4f3d495ab80.1617357235.git.syednwaris@gmail.com>
References: <cover.1617357235.git.syednwaris@gmail.com>
 <00d085d4068be651c58a61564926d4f3d495ab80.1617357235.git.syednwaris@gmail.com>
Message-ID: <CACG_h5rCPSdQApNzGziqxpd9aVc4uP9Q7zKRnBW5NBrH=ZxTcw@mail.gmail.com>

On Fri, Apr 2, 2021 at 3:42 PM Syed Nayyar Waris <syednwaris at gmail.com> wrote:
>
> This patch reimplements the xgpio_set_multiple() function in
> drivers/gpio/gpio-xilinx.c to use the new generic functions:
> bitmap_get_value() and bitmap_set_value(). The code is now simpler
> to read and understand. Moreover, instead of looping for each bit
> in xgpio_set_multiple() function, now we can check each channel at
> a time and save cycles.
>
> Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
> Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/gpio/gpio-xilinx.c | 60 +++++++++++++++++++-------------------
>  1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index b411d3156e0b..e0ad3a81f216 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -18,6 +18,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/slab.h>
> +#include "gpiolib.h"
>
>  /* Register Offset Definitions */
>  #define XGPIO_DATA_OFFSET   (0x0)      /* Data register  */
> @@ -161,37 +162,36 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
>  {
>         unsigned long flags;
>         struct xgpio_instance *chip = gpiochip_get_data(gc);
> -       int index = xgpio_index(chip, 0);
> -       int offset, i;
>
> -       spin_lock_irqsave(&chip->gpio_lock, flags);
> -
> -       /* Write to GPIO signals */
> -       for (i = 0; i < gc->ngpio; i++) {
> -               if (*mask == 0)
> -                       break;
> -               /* Once finished with an index write it out to the register */
> -               if (index !=  xgpio_index(chip, i)) {
> -                       xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -                                      index * XGPIO_CHANNEL_OFFSET,
> -                                      chip->gpio_state[index]);
> -                       spin_unlock_irqrestore(&chip->gpio_lock, flags);
> -                       index =  xgpio_index(chip, i);
> -                       spin_lock_irqsave(&chip->gpio_lock, flags);
> -               }
> -               if (__test_and_clear_bit(i, mask)) {
> -                       offset =  xgpio_offset(chip, i);
> -                       if (test_bit(i, bits))
> -                               chip->gpio_state[index] |= BIT(offset);
> -                       else
> -                               chip->gpio_state[index] &= ~BIT(offset);
> -               }
> -       }
> -
> -       xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> -                      index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
> -
> -       spin_unlock_irqrestore(&chip->gpio_lock, flags);
> +    u32 *state = chip->gpio_state;
> +    unsigned int *width = chip->gpio_width;
> +    DECLARE_BITMAP(old, 64);
> +    DECLARE_BITMAP(new, 64);
> +    DECLARE_BITMAP(changed, 64);
> +
> +    spin_lock_irqsave(&chip->gpio_lock, flags);
> +
> +    /* Copy initial value of state bits into 'old' bit-wise */
> +    bitmap_set_value(old, 64, state[0], width[0], 0);
> +    bitmap_set_value(old, 64, state[1], width[1], width[0]);
> +    /* Copy value from 'old' into 'new' with mask applied */
> +    bitmap_replace(new, old, bits, mask, gc->ngpio);
> +
> +    bitmap_from_arr32(old, state, 64);
> +    /* Update 'state' */
> +    state[0] = bitmap_get_value(new, 0, width[0]);
> +    state[1] = bitmap_get_value(new, width[0], width[1]);
> +    bitmap_from_arr32(new, state, 64);
> +    /* XOR operation sets only changed bits */
> +    bitmap_xor(changed, old, new, 64);
> +
> +    if (((u32 *)changed)[0])
> +        xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET, state[0]);
> +    if (((u32 *)changed)[1])
> +        xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
> +                XGPIO_CHANNEL_OFFSET, state[1]);
> +
> +    spin_unlock_irqrestore(&chip->gpio_lock, flags);
>  }
>
>  /**
> --
> 2.29.0
>

Hi All,

There were indentation errors reported. I am Re-sending the patchset.
I am keeping the version same as v4.

Kindly consider the "RESEND" prefixed v4 patchset for future.

Regards
Syed Nayyar Waris


From syednwaris at gmail.com  Fri Apr  2 17:35:36 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 22:05:36 +0530
Subject: [RESEND PATCH v4 0/3] Introduce the for_each_set_nbits macro
Message-ID: <cover.1617380819.git.syednwaris@gmail.com>

Hello Bartosz,

Since this patchset primarily affects GPIO drivers, would you like
to pick it up through your GPIO tree?

This patchset introduces a new generic version of for_each_set_nbits.
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated a
for-loop syntax that iterates over a memory region entire groups of set
bits at a time.

For example, suppose you would like to iterate over a 32-bit integer 8
bits at a time, skipping over 8-bit groups with no set bit, where
XXXXXXXX represents the current 8-bit group:

    Example:        10111110 00000000 11111111 00110011
    First loop:     10111110 00000000 11111111 XXXXXXXX
    Second loop:    10111110 00000000 XXXXXXXX 00110011
    Third loop:     XXXXXXXX 00000000 11111111 00110011

Each iteration of the loop returns the next 8-bit group that has at
least one set bit.

But with the new for_each_set_nbits the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word
size is not multiple of clump size. Following are examples showing the working
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x000000aa000000aa;
        0xbbbbabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_nbits:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:        offset: 0 clump: 0xfedcba
Iteration second:       offset: 24 clump: 0xabcdef
Iteration third:        offset: 48 clump: 0xaabbbb
Iteration fourth:       offset: 96 clump: 0xaa
Iteration fifth:        offset: 144 clump: 0xff
Iteration sixth:        offset: 168 clump: 0xaaaaaa
Iteration seventh:      offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour).

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

     /* bitmap memory region */
        0x00aa0000ff000000;  /* Most significant bits */
        0xaaaaaa0000ff0000;
        0x0f00000000000000;
        0x0000000000000ac0;  /* Least significant bits */

Different iterations of for_each_set_nbits:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:        offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v4:
 - [Patch 3/3]: Remove extra line and add few comments.
 - [Patch 3/3]: Use single lock (and unlock) call instead of two
   lock (and two unlock) calls.
 - [Patch 3/3]: Use bitmap_from_arr32() where applicalble.
 - [Patch 3/3]: Remove unnecessary 'const'.

Changes in v3:
 - [Patch 1/3]: Rename for_each_set_clump to for_each_set_nbits.
 - [Patch 1/3]: Shift function definitions outside 'ifdef CONFIG_DEBUG_FS'
   macro guard to resolve build (linking) error in xilinx Patch[3/3].
 - [Patch 2/3]: Rename for_each_set_clump to for_each_set_nbits.

Changes in v2:
 - [Patch 1/3]: Shift the macros and related functions to gpiolib inside
   gpio/. Reduce the visibilty of 'for_each_set_clump' to gpio.
 - [Patch 1/3]: Remove __builtin_unreachable and simply use return
   statement.
 - Remove tests from lib/test_bitmap.c as 'for_each_set_clump' is
   now localised inside gpio/ only.

Syed Nayyar Waris (3):
  gpiolib: Introduce the for_each_set_nbits macro
  gpio: thunderx: Utilize for_each_set_nbits macro
  gpio: xilinx: Utilize generic bitmap_get_value and _set_value

 drivers/gpio/gpio-thunderx.c | 13 ++++--
 drivers/gpio/gpio-xilinx.c   | 52 ++++++++++-----------
 drivers/gpio/gpiolib.c       | 90 ++++++++++++++++++++++++++++++++++++
 drivers/gpio/gpiolib.h       | 28 +++++++++++
 4 files changed, 152 insertions(+), 31 deletions(-)


base-commit: e1b7033ecdac56c1cc4dff72d67cac25d449efc6
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 17:36:14 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 22:06:14 +0530
Subject: [RESEND PATCH v4 1/3] gpiolib: Introduce the for_each_set_nbits macro
In-Reply-To: <cover.1617380819.git.syednwaris@gmail.com>
References: <cover.1617380819.git.syednwaris@gmail.com>
Message-ID: <12102d94258fc6bd5c01800b7cea680fc51d8b93.1617380819.git.syednwaris@gmail.com>

This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value() and bitmap_set_value() functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size from 1 to BITS_PER_LONG. size less
than 1 or more than BITS_PER_LONG causes undefined behaviour.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving the value from bitmap.

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Bartosz Go?aszewski <bgolaszewski at baylibre.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpiolib.c | 90 ++++++++++++++++++++++++++++++++++++++++++
 drivers/gpio/gpiolib.h | 28 +++++++++++++
 2 files changed, 118 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1427c1be749b..5576d1465c81 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -150,6 +150,96 @@ struct gpio_desc *gpiochip_get_desc(struct gpio_chip *gc,
 }
 EXPORT_SYMBOL_GPL(gpiochip_get_desc);
 
+/**
+ * bitmap_get_value - get 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 (must be between 1 and BITS_PER_LONG inclusive).
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+unsigned long bitmap_get_value(const unsigned long *map,
+				unsigned long start,
+				unsigned long nbits)
+{
+	const size_t index = BIT_WORD(start);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+	unsigned long value_low, value_high;
+
+	if (space >= nbits)
+		return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+	else {
+		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);
+	}
+}
+EXPORT_SYMBOL_GPL(bitmap_get_value);
+
+/**
+ * bitmap_set_value - set value within a memory region
+ * @map: address to the bitmap memory region
+ * @nbits: size of map in bits
+ * @value: value of clump
+ * @value_width: size of value in bits (must be between 1 and BITS_PER_LONG inclusive)
+ * @start: bit offset of the value
+ */
+void bitmap_set_value(unsigned long *map, unsigned long nbits,
+			unsigned long value, unsigned long value_width,
+			unsigned long start)
+{
+	const unsigned long index = BIT_WORD(start);
+	const unsigned long length = BIT_WORD(nbits);
+	const unsigned long offset = start % BITS_PER_LONG;
+	const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG);
+	const unsigned long space = ceiling - start;
+
+	value &= GENMASK(value_width - 1, 0);
+
+	if (space >= value_width) {
+		map[index] &= ~(GENMASK(value_width - 1, 0) << offset);
+		map[index] |= value << offset;
+	} else {
+		map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start);
+		map[index + 0] |= value << offset;
+
+		if (index + 1 >= length)
+			return;
+
+		map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + value_width);
+		map[index + 1] |= value >> space;
+	}
+}
+EXPORT_SYMBOL_GPL(bitmap_set_value);
+
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+unsigned long find_next_clump(unsigned long *clump, const unsigned long *addr,
+				unsigned long size, unsigned long offset,
+				unsigned long clump_size)
+{
+	offset = find_next_bit(addr, size, offset);
+	if (offset == size)
+		return size;
+
+	offset = rounddown(offset, clump_size);
+	*clump = bitmap_get_value(addr, offset, clump_size);
+	return offset;
+}
+EXPORT_SYMBOL_GPL(find_next_clump);
+
 /**
  * desc_to_gpio - convert a GPIO descriptor to the integer namespace
  * @desc: GPIO descriptor
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index 30bc3f80f83e..af79784dfce3 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -141,6 +141,34 @@ int gpio_set_debounce_timeout(struct gpio_desc *desc, unsigned int debounce);
 int gpiod_hog(struct gpio_desc *desc, const char *name,
 		unsigned long lflags, enum gpiod_flags dflags);
 
+unsigned long bitmap_get_value(const unsigned long *map,
+				unsigned long start,
+				unsigned long nbits);
+
+void bitmap_set_value(unsigned long *map, unsigned long nbits,
+			unsigned long value, unsigned long value_width,
+			unsigned long start);
+
+unsigned long find_next_clump(unsigned long *clump, const unsigned long *addr,
+				unsigned long size, unsigned long offset,
+				unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+	find_next_clump((clump), (bits), (size), 0, (clump_size))
+
+/**
+ * for_each_set_nbits - iterate over bitmap for each clump with set bits
+ * @start: bit offset to start search and to store the current iteration offset
+ * @clump: location to store copy of current 8-bit clump
+ * @bits: bitmap address to base the search on
+ * @size: bitmap size in number of bits
+ * @clump_size: clump size in bits
+ */
+#define for_each_set_nbits(start, clump, bits, size, clump_size) \
+	for ((start) = find_first_clump(&(clump), (bits), (size), (clump_size)); \
+	     (start) < (size); \
+	     (start) = find_next_clump(&(clump), (bits), (size), (start) + (clump_size), (clump_size)))
+
 /*
  * Return the GPIO number of the passed descriptor relative to its chip
  */
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 17:36:48 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 22:06:48 +0530
Subject: [RESEND PATCH v4 2/3] gpio: thunderx: Utilize for_each_set_nbits macro
In-Reply-To: <cover.1617380819.git.syednwaris@gmail.com>
References: <cover.1617380819.git.syednwaris@gmail.com>
Message-ID: <3a9bd0a593798538bec54d8b5ceab20a73d7eaa1.1617380819.git.syednwaris@gmail.com>

This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_nbits macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.

Cc: Robert Richter <rrichter at marvell.com>
Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpio-thunderx.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..4349e7393a1d 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -16,7 +16,7 @@
 #include <linux/pci.h>
 #include <linux/spinlock.h>
 #include <asm-generic/msi.h>
-
+#include "gpiolib.h"
 
 #define GPIO_RX_DAT	0x0
 #define GPIO_TX_SET	0x8
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip *chip,
 				       unsigned long *bits)
 {
 	int bank;
-	u64 set_bits, clear_bits;
+	unsigned long set_bits, clear_bits, gpio_mask;
+	unsigned long offset;
+
 	struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
 
-	for (bank = 0; bank <= chip->ngpio / 64; bank++) {
-		set_bits = bits[bank] & mask[bank];
-		clear_bits = ~bits[bank] & mask[bank];
+	for_each_set_nbits(offset, gpio_mask, mask, chip->ngpio, 64) {
+		bank = offset / 64;
+		set_bits = bits[bank] & gpio_mask;
+		clear_bits = ~bits[bank] & gpio_mask;
 		writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_SET);
 		writeq(clear_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_CLR);
 	}
-- 
2.29.0



From syednwaris at gmail.com  Fri Apr  2 17:37:36 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Fri, 2 Apr 2021 22:07:36 +0530
Subject: [RESEND PATCH v4 3/3] gpio: xilinx: Utilize generic bitmap_get_value
 and _set_value
In-Reply-To: <cover.1617380819.git.syednwaris@gmail.com>
References: <cover.1617380819.git.syednwaris@gmail.com>
Message-ID: <d150bd18acc767c86c23ec06cc2abd5ca74ccbbb.1617380819.git.syednwaris@gmail.com>

This patch reimplements the xgpio_set_multiple() function in
drivers/gpio/gpio-xilinx.c to use the new generic functions:
bitmap_get_value() and bitmap_set_value(). The code is now simpler
to read and understand. Moreover, instead of looping for each bit
in xgpio_set_multiple() function, now we can check each channel at
a time and save cycles.

Cc: Bartosz Golaszewski <bgolaszewski at baylibre.com>
Cc: Michal Simek <michal.simek at xilinx.com>
Signed-off-by: Syed Nayyar Waris <syednwaris at gmail.com>
Acked-by: William Breathitt Gray <vilhelm.gray at gmail.com>
---
 drivers/gpio/gpio-xilinx.c | 52 +++++++++++++++++++-------------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index b411d3156e0b..512198250b02 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -18,6 +18,7 @@
 #include <linux/of_platform.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
+#include "gpiolib.h"
 
 /* Register Offset Definitions */
 #define XGPIO_DATA_OFFSET   (0x0)	/* Data register  */
@@ -161,35 +162,34 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 {
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
 
-	spin_lock_irqsave(&chip->gpio_lock, flags);
+	u32 *state = chip->gpio_state;
+	unsigned int *width = chip->gpio_width;
+	DECLARE_BITMAP(old, 64);
+	DECLARE_BITMAP(new, 64);
+	DECLARE_BITMAP(changed, 64);
 
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock, flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock, flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
-	}
+	spin_lock_irqsave(&chip->gpio_lock, flags);
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
+	/* Copy initial value of state bits into 'old' contiguously */
+	bitmap_set_value(old, 64, state[0], width[0], 0);
+	bitmap_set_value(old, 64, state[1], width[1], width[0]);
+	/* Copy value from 'old' into 'new' with mask applied */
+	bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+	bitmap_from_arr32(old, state, 64);
+	/* Update 'state' */
+	state[0] = bitmap_get_value(new, 0, width[0]);
+	state[1] = bitmap_get_value(new, width[0], width[1]);
+	bitmap_from_arr32(new, state, 64);
+	/* XOR operation sets only changed bits */
+	bitmap_xor(changed, old, new, 64);
+
+	if (((u32 *)changed)[0])
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET, state[0]);
+	if (((u32 *)changed)[1])
+		xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+			XGPIO_CHANNEL_OFFSET, state[1]);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
-- 
2.29.0



From adrien.grassein at gmail.com  Fri Apr  2 17:45:04 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Fri,  2 Apr 2021 18:45:04 +0200
Subject: [PATCH v1 0/2] Add imx8m power domain driver
Message-ID: <20210402164506.520121-1-adrien.grassein@gmail.com>

Hi,

this patch et aims to add the support of the i.MX 8 Power Domain driver.
Some devices (like usbotg2) can't work without this patch as their
attached power domain are down.

The original drivr was taken from le imx kernel and aapted to fit with
the actual mainline (minor fixes).

Thanks,

Adrien Grassein (2):
  dt-bindings: power: Add documentation for imx8m power domain driver
  soc: imx: add Power Domain driver for i.MX8M(M|N|P)

 .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
 MAINTAINERS                                   |  10 +
 drivers/soc/imx/Kconfig                       |   7 +
 drivers/soc/imx/Makefile                      |   1 +
 drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
 include/dt-bindings/power/imx8mm-power.h      |  21 ++
 include/dt-bindings/power/imx8mn-power.h      |  15 ++
 include/dt-bindings/power/imx8mp-power.h      |  28 +++
 include/soc/imx/imx_sip.h                     |  12 +
 9 files changed, 416 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/dt-bindings/power/imx8mm-power.h
 create mode 100644 include/dt-bindings/power/imx8mn-power.h
 create mode 100644 include/dt-bindings/power/imx8mp-power.h
 create mode 100644 include/soc/imx/imx_sip.h

-- 
2.25.1



From adrien.grassein at gmail.com  Fri Apr  2 17:45:06 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Fri,  2 Apr 2021 18:45:06 +0200
Subject: [PATCH v1 2/2] soc: imx: add Power Domain driver for i.MX8M(M|N|P)
In-Reply-To: <20210402164506.520121-1-adrien.grassein@gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
Message-ID: <20210402164506.520121-3-adrien.grassein@gmail.com>

Add code allowing to control the power domain of some
i.MX8 socs.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 MAINTAINERS                        |   2 +
 drivers/soc/imx/Kconfig            |   7 +
 drivers/soc/imx/Makefile           |   1 +
 drivers/soc/imx/imx8m_pm_domains.c | 233 +++++++++++++++++++++++++++++
 include/soc/imx/imx_sip.h          |  12 ++
 5 files changed, 255 insertions(+)
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/soc/imx/imx_sip.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 97536afca0e1..06e1568d003b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13014,9 +13014,11 @@ NXP i.MX 8M(M|N|P) POWER DOMAIN DRIVER
 M:	Adrien Grassein <adrien.grassein at gmail.com>
 S:	Maintained
 F:	Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
+F:	drivers/soc/imx/imx8m_pm_domains.c
 F:	include/dt-bindings/power/imx8mm-power.h
 F:	include/dt-bindings/power/imx8mn-power.h
 F:	include/dt-bindings/power/imx8mp-power.h
+F:	include/soc/imx/imx_sip.h
 
 NXP i.MX 8MQ DCSS DRIVER
 M:	Laurentiu Palcu <laurentiu.palcu at oss.nxp.com>
diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index 05812f8ae734..02d93346fd4b 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -8,6 +8,13 @@ config IMX_GPCV2_PM_DOMAINS
 	select PM_GENERIC_DOMAINS
 	default y if SOC_IMX7D
 
+config IMX8M_PM_DOMAINS
+	bool "i.MX8M PM domains"
+	depends on ARCH_MXC || (COMPILE_TEST && OF)
+	depends on PM
+	select PM_GENERIC_DOMAINS
+	default y if SOC_IMX8M
+
 config SOC_IMX8M
 	bool "i.MX8M SoC family support"
 	depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 078dc918f4f3..7387239aecec 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o
 endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
+obj-$(CONFIG_IMX8M_PM_DOMAINS) += imx8m_pm_domains.o
 obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o
diff --git a/drivers/soc/imx/imx8m_pm_domains.c b/drivers/soc/imx/imx8m_pm_domains.c
new file mode 100644
index 000000000000..3a039572b734
--- /dev/null
+++ b/drivers/soc/imx/imx8m_pm_domains.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/clk.h>
+#include <linux/delay.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/pm_domain.h>
+#include <linux/regulator/consumer.h>
+
+#include <soc/imx/imx_sip.h>
+
+#define MAX_CLK_NUM	6
+#define to_imx8m_pm_domain(_genpd) container_of(_genpd, struct imx8m_pm_domain, pd)
+
+struct imx8m_pm_domain {
+	struct device *dev;
+	struct generic_pm_domain pd;
+	u32 domain_index;
+	struct clk *clk[MAX_CLK_NUM];
+	unsigned int num_clks;
+	struct regulator *reg;
+};
+
+enum imx8m_pm_domain_state {
+	PD_STATE_OFF,
+	PD_STATE_ON,
+};
+
+static DEFINE_MUTEX(gpc_pd_mutex);
+
+static int imx8m_pd_power_on(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	/* power on the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_enable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power up the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* enable the necessary clks needed by the power domain */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_prepare_enable(domain->clk[index]);
+	}
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_ON, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	return 0;
+}
+
+static int imx8m_pd_power_off(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_OFF, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	/* power off the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_disable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power off the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* disable clks when power domain is off */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_disable_unprepare(domain->clk[index]);
+	}
+
+	return ret;
+};
+
+static int imx8m_pd_get_clocks(struct imx8m_pm_domain *domain)
+{
+	int i, ret;
+
+	for (i = 0; ; i++) {
+		struct clk *clk = of_clk_get(domain->dev->of_node, i);
+
+		if (IS_ERR(clk))
+			break;
+		if (i >= MAX_CLK_NUM) {
+			dev_err(domain->dev, "more than %d clocks\n",
+				MAX_CLK_NUM);
+			ret = -EINVAL;
+			goto clk_err;
+		}
+		domain->clk[i] = clk;
+	}
+	domain->num_clks = i;
+
+	return 0;
+
+clk_err:
+	while (i--)
+		clk_put(domain->clk[i]);
+
+	return ret;
+}
+
+static void imx8m_pd_put_clocks(struct imx8m_pm_domain *domain)
+{
+	int i;
+
+	for (i = domain->num_clks - 1; i >= 0; i--)
+		clk_put(domain->clk[i]);
+}
+
+static const struct of_device_id imx8m_pm_domain_ids[] = {
+	{.compatible = "fsl,imx8mm-pm-domain"},
+	{.compatible = "fsl,imx8mn-pm-domain"},
+	{.compatible = "fsl,imx8mn-pm-domain"},
+	{},
+};
+
+static int imx8m_pm_domain_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8m_pm_domain *domain;
+	struct of_phandle_args parent, child;
+	int ret;
+
+	domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
+	if (!domain)
+		return -ENOMEM;
+
+	child.np = np;
+	domain->dev = dev;
+
+	ret = of_property_read_string(np, "domain-name", &domain->pd.name);
+	if (ret) {
+		dev_err(dev, "failed to get the domain name\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(np, "domain-index", &domain->domain_index);
+	if (ret) {
+		dev_err(dev, "failed to get the domain index\n");
+		return -EINVAL;
+	}
+
+	domain->reg = devm_regulator_get_optional(dev, "power");
+	if (IS_ERR(domain->reg)) {
+		if (PTR_ERR(domain->reg) != -ENODEV) {
+			if (PTR_ERR(domain->reg) != -EPROBE_DEFER)
+				dev_err(dev, "failed to get domain's regulator\n");
+			return PTR_ERR(domain->reg);
+		}
+	}
+
+	ret = imx8m_pd_get_clocks(domain);
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get domain's clocks\n");
+		return ret;
+	}
+
+	domain->pd.power_off = imx8m_pd_power_off;
+	domain->pd.power_on = imx8m_pd_power_on;
+	if (of_property_read_bool(np, "fsl,active-wakeup"))
+		domain->pd.flags |= GENPD_FLAG_ACTIVE_WAKEUP;
+	if (of_property_read_bool(np, "fsl,rpm-always-on"))
+		domain->pd.flags |= GENPD_FLAG_RPM_ALWAYS_ON;
+
+	pm_genpd_init(&domain->pd, NULL, !(domain->pd.flags & GENPD_FLAG_RPM_ALWAYS_ON));
+
+	ret = of_genpd_add_provider_simple(np, &domain->pd);
+	if (ret) {
+		dev_err(dev, "failed to add the domain provider\n");
+		pm_genpd_remove(&domain->pd);
+		imx8m_pd_put_clocks(domain);
+		return ret;
+	}
+
+	/* add it as subdomain if necessary */
+	if (!of_parse_phandle_with_args(np, "power-domains",
+					"#power-domain-cells",
+					0, &parent)) {
+		ret = of_genpd_add_subdomain(&parent, &child);
+		of_node_put(parent.np);
+
+		if (ret < 0) {
+			dev_dbg(dev, "failed to add the subdomain: %s: %d",
+				domain->pd.name, ret);
+			of_genpd_del_provider(np);
+			pm_genpd_remove(&domain->pd);
+			imx8m_pd_put_clocks(domain);
+			return driver_deferred_probe_check_state(dev);
+		}
+	}
+
+	return 0;
+}
+
+static struct platform_driver imx8m_pm_domain_driver = {
+	.driver = {
+		.name	= "imx8m_pm_domain",
+		.owner	= THIS_MODULE,
+		.of_match_table = imx8m_pm_domain_ids,
+	},
+	.probe = imx8m_pm_domain_probe,
+};
+module_platform_driver(imx8m_pm_domain_driver);
+
+MODULE_AUTHOR("NXP");
+/* Just for mainstreaming */
+MODULE_AUTHOR("Adrien Grassein <adrien.grassein at gmail.com>");
+MODULE_DESCRIPTION("NXP i.MX8M power domain driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/imx/imx_sip.h b/include/soc/imx/imx_sip.h
new file mode 100644
index 000000000000..6b96b33c870e
--- /dev/null
+++ b/include/soc/imx/imx_sip.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2019 NXP
+ */
+
+#ifndef __IMX_SIP_H__
+#define __IMX_SIP_H__
+
+#define IMX_SIP_GPC			0xC2000000
+#define IMX_SIP_CONFIG_GPC_PM_DOMAIN	0x03
+
+#endif /* __IMX_SIP_H__ */
-- 
2.25.1



From adrien.grassein at gmail.com  Fri Apr  2 17:45:05 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Fri,  2 Apr 2021 18:45:05 +0200
Subject: [PATCH v1 1/2] dt-bindings: power: Add documentation for imx8m power
 domain driver
In-Reply-To: <20210402164506.520121-1-adrien.grassein@gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
Message-ID: <20210402164506.520121-2-adrien.grassein@gmail.com>

Add documentation for the imx8m(m|n|p) power domain driver.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 .../bindings/power/fsl,imx-power-domain.yaml  | 89 +++++++++++++++++++
 MAINTAINERS                                   |  8 ++
 include/dt-bindings/power/imx8mm-power.h      | 21 +++++
 include/dt-bindings/power/imx8mn-power.h      | 15 ++++
 include/dt-bindings/power/imx8mp-power.h      | 28 ++++++
 5 files changed, 161 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
 create mode 100644 include/dt-bindings/power/imx8mm-power.h
 create mode 100644 include/dt-bindings/power/imx8mn-power.h
 create mode 100644 include/dt-bindings/power/imx8mp-power.h

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml b/Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
new file mode 100644
index 000000000000..8b4811aa80eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/fsl,imx-power-domain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX 8mm, 8mn and 8mp Power Domain
+
+maintainers:
+  - Adrien Grassein <adrien.grassein at gmail.com>
+
+description: |+
+  i.MX processors include support for multiple power domains which are used
+  to gate power to one or more peripherals on the processor.
+
+allOf:
+  - $ref: power-domain.yaml#
+
+properties:
+  compatible:
+    enum:
+      - fsl,imx8mm-pm-domain
+      - fsl,imx8mn-pm-domain
+      - fsl,imx8mp-pm-domain
+
+  domain-name:
+    $ref: /schemas/types.yaml#/definitions/string
+    description: |
+      Human readable string with domain name. Will be visible in userspace
+      to let user to distinguish between multiple domains in SoC.
+
+  domain-index:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      Power domain index. Valid values are defined in
+      include/dt-bindings/power/imx8mm-power.h for i.MX 8mm
+      include/dt-bindings/power/imx8mn-power.h for i.MX 8mn
+      include/dt-bindings/power/imx8mp-power.h for i.MX 8mp
+
+    maxItems: 1
+
+  clocks:
+    description: |
+      A number of phandles to clocks that need to be enabled during domain
+      power-up sequencing to ensure reset propagation into devices located
+      inside this power domain.
+    minItems: 1
+    maxItems: 6
+
+  power-supply:
+    description:
+      A phandle to a supply to enable when powering on the domain.
+
+  fsl,active-wakeup:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Instructs genpd to keep the PM domain powered on.
+
+  fsl,rpm-always-on:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Instructs genpd to always keep the PM domain powered on except
+      for system suspend.
+
+  "#power-domain-cells":
+    const: 0
+
+  power-domains:
+    maxItems: 1
+
+required:
+  - compatible
+  - domain-name
+  - domain-index
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/power/imx8mm-power.h>
+    #include <dt-bindings/clock/imx8mm-clock.h>
+
+    hsiomix_pd: power-domain-hsio {
+        compatible = "fsl,imx8mm-pm-domain";
+        domain-index = <IMX8MM_POWER_DOMAIN_HSIOMIX>;
+        #power-domain-cells = <0>;
+        domain-name = "hsiomix";
+        clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 38d823d72e52..97536afca0e1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13010,6 +13010,14 @@ L:	linux-imx at nxp.com
 S:	Maintained
 F:	drivers/clk/imx/
 
+NXP i.MX 8M(M|N|P) POWER DOMAIN DRIVER
+M:	Adrien Grassein <adrien.grassein at gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
+F:	include/dt-bindings/power/imx8mm-power.h
+F:	include/dt-bindings/power/imx8mn-power.h
+F:	include/dt-bindings/power/imx8mp-power.h
+
 NXP i.MX 8MQ DCSS DRIVER
 M:	Laurentiu Palcu <laurentiu.palcu at oss.nxp.com>
 R:	Lucas Stach <l.stach at pengutronix.de>
diff --git a/include/dt-bindings/power/imx8mm-power.h b/include/dt-bindings/power/imx8mm-power.h
new file mode 100644
index 000000000000..bec25fd32394
--- /dev/null
+++ b/include/dt-bindings/power/imx8mm-power.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2021 Adrien Grassein <adrien.grassein at gmail.com>
+ */
+
+#ifndef __DT_BINDINGS_IMX8MM_POWER_H__
+#define __DT_BINDINGS_IMX8MM_POWER_H__
+
+#define IMX8MM_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MM_POWER_DOMAIN_PCIE1	1
+#define IMX8MM_POWER_DOMAIN_USB_OTG1	2
+#define IMX8MM_POWER_DOMAIN_USB_OTG2	3
+#define IMX8MM_POWER_DOMAIN_GPU		4
+#define IMX8MM_POWER_DOMAIN_VPU		5
+#define IMX8MM_POWER_DOMAIN_VPU_G1	6
+#define IMX8MM_POWER_DOMAIN_VPU_G2	7
+#define IMX8MM_POWER_DOMAIN_VPU_H1	8
+#define IMX8MM_POWER_DOMAIN_DISPLAY	9
+#define IMX8MM_POWER_DOMAIN_MIPI	10
+
+#endif
diff --git a/include/dt-bindings/power/imx8mn-power.h b/include/dt-bindings/power/imx8mn-power.h
new file mode 100644
index 000000000000..dfa0711171cd
--- /dev/null
+++ b/include/dt-bindings/power/imx8mn-power.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2021 Adrien Grassein <adrien.grassein at gmail.com>
+ */
+
+#ifndef __DT_BINDINGS_IMX8MN_POWER_H__
+#define __DT_BINDINGS_IMX8MN_POWER_H__
+
+#define IMX8MN_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MN_POWER_DOMAIN_USB_OTG1	2
+#define IMX8MN_POWER_DOMAIN_GPU		4
+#define IMX8MN_POWER_DOMAIN_DISPLAY	9
+#define IMX8MN_POWER_DOMAIN_MIPI	10
+
+#endif
diff --git a/include/dt-bindings/power/imx8mp-power.h b/include/dt-bindings/power/imx8mp-power.h
new file mode 100644
index 000000000000..660e6b7d6c69
--- /dev/null
+++ b/include/dt-bindings/power/imx8mp-power.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2021 Adrien Grassein <adrien.grassein at gmail.com>
+ */
+
+#ifndef __DT_BINDINGS_IMX8MP_POWER_H__
+#define __DT_BINDINGS_IMX8MP_POWER_H__
+
+#define IMX8MP_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MP_POWER_DOMAIN_PCIE1	1
+#define IMX8MP_POWER_DOMAIN_USB_OTG1	2
+#define IMX8MP_POWER_DOMAIN_USB_OTG2	3
+#define IMX8MP_POWER_DOMAIN_MLMIX	4
+#define IMX8MP_POWER_DOMAIN_AUDIOMIX	5
+#define IMX8MP_POWER_DOMAIN_GPU_MIX	6
+#define IMX8MP_POWER_DOMAIN_GPU_2D	7
+#define IMX8MP_POWER_DOMAIN_GPU_3D	8
+#define IMX8MP_POWER_DOMAIN_VPUMIX	9
+#define IMX8MP_POWER_DOMAIN_G1		10
+#define IMX8MP_POWER_DOMAIN_G2		11
+#define IMX8MP_POWER_DOMAIN_H1		12
+#define IMX8MP_POWER_MEDIAMIX		13
+#define IMX8MP_ISP_DWP			14
+#define IMX8MP_MIPI_PHY1		15
+#define IMX8MP_MIPI_PHY2		16
+#define IMX8MP_HDMI_MIX			17
+#define IMX8MP_HDMI_PHY			18
+#endif
-- 
2.25.1



From nicolas.ferre at microchip.com  Fri Apr  2 18:01:39 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Fri, 2 Apr 2021 19:01:39 +0200
Subject: [PATCH] ARM: dts: at91: sama5d2: add ETB and ETM unit name
Message-ID: <20210402170139.140595-1-nicolas.ferre@microchip.com>

From: Nicolas Ferre <nicolas.ferre at microchip.com>

Add unit address to the ETB and ETM nodes.

It also allow us to get rid of the warnings:
../arch/arm/boot/dts/sama5d2.dtsi:43.6-57.4: Warning
(unit_address_vs_reg): /etb: node has a reg or ranges property, but no
unit name
../arch/arm/boot/dts/sama5d2.dtsi:59.6-73.4: Warning
(unit_address_vs_reg): /etm: node has a reg or ranges property, but no
unit name
when we compile with W=1.

Signed-off-by: Nicolas Ferre <nicolas.ferre at microchip.com>
---
 arch/arm/boot/dts/sama5d2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 2c4952427296..a27294394508 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -40,7 +40,7 @@ pmu {
 		interrupts = <2 IRQ_TYPE_LEVEL_HIGH 0>;
 	};
 
-	etb {
+	etb at 740000 {
 		compatible = "arm,coresight-etb10", "arm,primecell";
 		reg = <0x740000 0x1000>;
 
@@ -56,7 +56,7 @@ etb_in: endpoint {
 		};
 	};
 
-	etm {
+	etm at 73C000 {
 		compatible = "arm,coresight-etm3x", "arm,primecell";
 		reg = <0x73C000 0x1000>;
 
-- 
2.31.1



From pbonzini at redhat.com  Fri Apr  2 18:07:32 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 19:07:32 +0200
Subject: [PATCH v2 6/9] KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
In-Reply-To: <20210401135451.1004564-7-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
 <20210401135451.1004564-7-mlevitsk@redhat.com>
Message-ID: <f9e1ca0c-d6cb-7477-55f2-c4861d8f8704@redhat.com>

On 01/04/21 15:54, Maxim Levitsky wrote:
> KVM_GUESTDBG_BLOCKEVENTS is a guest debug feature that
> will allow KVM to block all interrupts while running.
> It is mostly intended to be used together with single stepping,
> to make it more robust, and has the following benefits:
> 
> * Resuming from a breakpoint is much more reliable:
>    When resuming execution from a breakpoint, with interrupts enabled,
>    more often than not, KVM would inject an interrupt and make the CPU
>    jump immediately to the interrupt handler and eventually return to
>    the breakpoint, only to trigger it again.
> 
>    From the gdb's user point of view it looks like the CPU has never
>    executed a single instruction and in some cases that can even
>    prevent forward progress, for example, when the breakpoint
>    is placed by an automated script (e.g lx-symbols), which does
>    something in response to the breakpoint and then continues
>    the guest automatically.
>    If the script execution takes enough time for another interrupt to
>    arrive, the guest will be stuck on the same breakpoint forever.
> 
> * Normal single stepping is much more predictable, since it won't
>    land the debugger into an interrupt handler.
> 
> * Chances of RFLAGS.TF being leaked to the guest are reduced:
> 
>    KVM sets that flag behind the guest's back to single step it,
>    but if the single step lands the vCPU into an
>    interrupt/exception handler the RFLAGS.TF will be leaked to the
>    guest in the form of being pushed to the stack.
>    This doesn't completely eliminate this problem as exceptions
>    can still happen, but at least this eliminates the common
>    case.
> 
> Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>

The patch uses BLOCKIRQ instead of BLOCKEVENTS.

Paolo

> ---
>   Documentation/virt/kvm/api.rst  | 1 +
>   arch/x86/include/asm/kvm_host.h | 3 ++-
>   arch/x86/include/uapi/asm/kvm.h | 1 +
>   arch/x86/kvm/x86.c              | 4 ++++
>   4 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 9778b2434c03..a4f2dc84741f 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -3338,6 +3338,7 @@ flags which can include the following:
>     - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
>     - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
>     - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]
> +  - KVM_GUESTDBG_BLOCKIRQ:      avoid injecting interrupts/NMI/SMI [x86]
>   
>   For example KVM_GUESTDBG_USE_SW_BP indicates that software breakpoints
>   are enabled in memory so we need to ensure breakpoint exceptions are
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index cc7c82a449d5..8c529ae9dbbe 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -227,7 +227,8 @@ enum x86_intercept_stage;
>   	KVM_GUESTDBG_USE_HW_BP | \
>   	KVM_GUESTDBG_USE_SW_BP | \
>   	KVM_GUESTDBG_INJECT_BP | \
> -	KVM_GUESTDBG_INJECT_DB)
> +	KVM_GUESTDBG_INJECT_DB | \
> +	KVM_GUESTDBG_BLOCKIRQ)
>   
>   
>   #define PFERR_PRESENT_BIT 0
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 5a3022c8af82..b0f9945067f7 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -282,6 +282,7 @@ struct kvm_debug_exit_arch {
>   #define KVM_GUESTDBG_USE_HW_BP		0x00020000
>   #define KVM_GUESTDBG_INJECT_DB		0x00040000
>   #define KVM_GUESTDBG_INJECT_BP		0x00080000
> +#define KVM_GUESTDBG_BLOCKIRQ		0x00100000
>   
>   /* for KVM_SET_GUEST_DEBUG */
>   struct kvm_guest_debug_arch {
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 956e8e0bd6af..3627ce8fe5bb 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8460,6 +8460,10 @@ static void inject_pending_event(struct kvm_vcpu *vcpu, bool *req_immediate_exit
>   		can_inject = false;
>   	}
>   
> +	/* Don't inject interrupts if the user asked to avoid doing so */
> +	if (vcpu->guest_debug & KVM_GUESTDBG_BLOCKIRQ)
> +		return;
> +
>   	/*
>   	 * Finally, inject interrupt events.  If an event cannot be injected
>   	 * due to architectural conditions (e.g. IF=0) a window-open exit
> 



From mdf at kernel.org  Fri Apr  2 18:15:38 2021
From: mdf at kernel.org (Moritz Fischer)
Date: Fri, 2 Apr 2021 10:15:38 -0700
Subject: [PATCH 2/3] fpga: region: Add fpga-region property 'power-domains'
In-Reply-To: <20210402092049.479-3-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-3-nava.manne@xilinx.com>
Message-ID: <YGdROrOOzltI/Bbe@epycbox.lan>

On Fri, Apr 02, 2021 at 02:50:48PM +0530, Nava kishore Manne wrote:
> Add fpga-region property 'power-domains' to allow to handle
> the FPGA/PL power domins.
> 
> dt-bindings: fpga: Enable PM generic domain support
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  .../devicetree/bindings/fpga/fpga-region.txt       | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> index e811cf825019..969ca53bb65e 100644
> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> @@ -196,6 +196,20 @@ Optional properties:
>  - config-complete-timeout-us : The maximum time in microseconds time for the
>  	FPGA to go to operating mode after the region has been programmed.
>  - child nodes : devices in the FPGA after programming.
> +- power-domains : A phandle and PM domain specifier as defined by bindings of
> +	the power controller specified by phandle.
> +Example:
> +	fpga_full: fpga-full {
> +                compatible = "fpga-region";
> +                fpga-mgr = <&zynqmp_pcap>;
> +                #address-cells = <2>;
> +                #size-cells = <2>;
> +                ranges;
> +                power-domains = <&zynqmp_firmware PL_PD>;
> +        };
> +
> +	The PL_PD power domain will be turned on before loading the bitstream
> +and turned off while removing/unloading the bitstream using overlays.

Can multiple regions share a power-domain or is this specific to full
fpga reconfiguration?

- Moritz


From andy.shevchenko at gmail.com  Fri Apr  2 18:30:45 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 2 Apr 2021 20:30:45 +0300
Subject: [RESEND PATCH v4 0/3] Introduce the for_each_set_nbits macro
In-Reply-To: <cover.1617380819.git.syednwaris@gmail.com>
References: <cover.1617380819.git.syednwaris@gmail.com>
Message-ID: <CAHp75VdUJE_G7D8prW53_p9s06Qs_XzoF9AaYL5HRkDooKCUcw@mail.gmail.com>

On Fri, Apr 2, 2021 at 7:36 PM Syed Nayyar Waris <syednwaris at gmail.com> wrote:
>
> Hello Bartosz,
>
> Since this patchset primarily affects GPIO drivers, would you like
> to pick it up through your GPIO tree?
>
> This patchset introduces a new generic version of for_each_set_nbits.
> The previous version of for_each_set_clump8 used a fixed size 8-bit
> clump, but the new generic version can work with clump of any size but

clumps

> less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
> in several GPIO drivers.
>
> The earlier 8-bit for_each_set_clump8 facilitated a
> for-loop syntax that iterates over a memory region entire groups of set
> bits at a time.
>
> For example, suppose you would like to iterate over a 32-bit integer 8
> bits at a time, skipping over 8-bit groups with no set bit, where
> XXXXXXXX represents the current 8-bit group:
>
>     Example:        10111110 00000000 11111111 00110011
>     First loop:     10111110 00000000 11111111 XXXXXXXX
>     Second loop:    10111110 00000000 XXXXXXXX 00110011
>     Third loop:     XXXXXXXX 00000000 11111111 00110011
>
> Each iteration of the loop returns the next 8-bit group that has at
> least one set bit.
>
> But with the new for_each_set_nbits the clump size can be different from 8 bits.
> Moreover, the clump can be split at word boundary in situations where word

boundaries

> size is not multiple of clump size. Following are examples showing the working
> of new macro for clump sizes of 24 bits and 6 bits.
>
> Example 1:
> clump size: 24 bits, Number of clumps (or ports): 10
> bitmap stores the bit information from where successive clumps are retrieved.
>
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x000000aa000000aa;
>         0xbbbbabcdeffedcba;  /* Least significant bits */
>
> Different iterations of for_each_set_nbits:-
> 'offset' is the bit position and 'clump' is the 24 bit clump from the
> above bitmap.
> Iteration first:        offset: 0 clump: 0xfedcba
> Iteration second:       offset: 24 clump: 0xabcdef
> Iteration third:        offset: 48 clump: 0xaabbbb
> Iteration fourth:       offset: 96 clump: 0xaa
> Iteration fifth:        offset: 144 clump: 0xff
> Iteration sixth:        offset: 168 clump: 0xaaaaaa
> Iteration seventh:      offset: 216 clump: 0xff
> Loop breaks because in the end the remaining bits (0x00aa) size was less
> than clump size of 24 bits.
>
> In above example it can be seen that in iteration third, the 24 bit clump
> that was retrieved was split between bitmap[0] and bitmap[1]. This example
> also shows that 24 bit zeroes if present in between, were skipped (preserving
> the previous for_each_set_macro8 behaviour).
>
> Example 2:
> clump size = 6 bits, Number of clumps (or ports) = 3.
>
>      /* bitmap memory region */
>         0x00aa0000ff000000;  /* Most significant bits */
>         0xaaaaaa0000ff0000;
>         0x0f00000000000000;
>         0x0000000000000ac0;  /* Least significant bits */
>
> Different iterations of for_each_set_nbits:
> 'offset' is the bit position and 'clump' is the 6 bit clump from the
> above bitmap.
> Iteration first:        offset: 6 clump: 0x2b
> Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
> Here 6 * 3 is clump size * no. of clumps.

Bart, I would like to have a fresh look at this.

(missed changelog)

> Changes in v4:
>  - [Patch 3/3]: Remove extra line and add few comments.
>  - [Patch 3/3]: Use single lock (and unlock) call instead of two
>    lock (and two unlock) calls.
>  - [Patch 3/3]: Use bitmap_from_arr32() where applicalble.
>  - [Patch 3/3]: Remove unnecessary 'const'.
>
> Changes in v3:
>  - [Patch 1/3]: Rename for_each_set_clump to for_each_set_nbits.
>  - [Patch 1/3]: Shift function definitions outside 'ifdef CONFIG_DEBUG_FS'
>    macro guard to resolve build (linking) error in xilinx Patch[3/3].
>  - [Patch 2/3]: Rename for_each_set_clump to for_each_set_nbits.
>
> Changes in v2:
>  - [Patch 1/3]: Shift the macros and related functions to gpiolib inside
>    gpio/. Reduce the visibilty of 'for_each_set_clump' to gpio.
>  - [Patch 1/3]: Remove __builtin_unreachable and simply use return
>    statement.
>  - Remove tests from lib/test_bitmap.c as 'for_each_set_clump' is
>    now localised inside gpio/ only.
>
> Syed Nayyar Waris (3):
>   gpiolib: Introduce the for_each_set_nbits macro
>   gpio: thunderx: Utilize for_each_set_nbits macro
>   gpio: xilinx: Utilize generic bitmap_get_value and _set_value
>
>  drivers/gpio/gpio-thunderx.c | 13 ++++--
>  drivers/gpio/gpio-xilinx.c   | 52 ++++++++++-----------
>  drivers/gpio/gpiolib.c       | 90 ++++++++++++++++++++++++++++++++++++
>  drivers/gpio/gpiolib.h       | 28 +++++++++++
>  4 files changed, 152 insertions(+), 31 deletions(-)
>
>
> base-commit: e1b7033ecdac56c1cc4dff72d67cac25d449efc6
> --
> 2.29.0
>


-- 
With Best Regards,
Andy Shevchenko


From pbonzini at redhat.com  Fri Apr  2 18:38:39 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 2 Apr 2021 19:38:39 +0200
Subject: [PATCH v2 0/9] KVM: my debug patch queue
In-Reply-To: <20210401135451.1004564-1-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
Message-ID: <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>

On 01/04/21 15:54, Maxim Levitsky wrote:
> Hi!
> 
> I would like to publish two debug features which were needed for other stuff
> I work on.
> 
> One is the reworked lx-symbols script which now actually works on at least
> gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
> for some reason, not related to this patch) and upstream qemu.

Queued patches 2-5 for now.  6 is okay but it needs a selftest. (e.g. 
using KVM_VCPU_SET_EVENTS) and the correct name for the constant.

Paolo

> The other feature is the ability to trap all guest exceptions (on SVM for now)
> and see them in kvmtrace prior to potential merge to double/triple fault.
> 
> This can be very useful and I already had to manually patch KVM a few
> times for this.
> I will, once time permits, implement this feature on Intel as well.
> 
> V2:
> 
>   * Some more refactoring and workarounds for lx-symbols script
> 
>   * added KVM_GUESTDBG_BLOCKEVENTS flag to enable 'block interrupts on
>     single step' together with KVM_CAP_SET_GUEST_DEBUG2 capability
>     to indicate which guest debug flags are supported.
> 
>     This is a replacement for unconditional block of interrupts on single
>     step that was done in previous version of this patch set.
>     Patches to qemu to use that feature will be sent soon.
> 
>   * Reworked the the 'intercept all exceptions for debug' feature according
>     to the review feedback:
> 
>     - renamed the parameter that enables the feature and
>       moved it to common kvm module.
>       (only SVM part is currently implemented though)
> 
>     - disable the feature for SEV guests as was suggested during the review
>     - made the vmexit table const again, as was suggested in the review as well.
> 
> Best regards,
> 	Maxim Levitsky
> 
> Maxim Levitsky (9):
>    scripts/gdb: rework lx-symbols gdb script
>    KVM: introduce KVM_CAP_SET_GUEST_DEBUG2
>    KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2
>    KVM: aarch64: implement KVM_CAP_SET_GUEST_DEBUG2
>    KVM: s390x: implement KVM_CAP_SET_GUEST_DEBUG2
>    KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
>    KVM: SVM: split svm_handle_invalid_exit
>    KVM: x86: add force_intercept_exceptions_mask
>    KVM: SVM: implement force_intercept_exceptions_mask
> 
>   Documentation/virt/kvm/api.rst    |   4 +
>   arch/arm64/include/asm/kvm_host.h |   4 +
>   arch/arm64/kvm/arm.c              |   2 +
>   arch/arm64/kvm/guest.c            |   5 -
>   arch/s390/include/asm/kvm_host.h  |   4 +
>   arch/s390/kvm/kvm-s390.c          |   3 +
>   arch/x86/include/asm/kvm_host.h   |  12 ++
>   arch/x86/include/uapi/asm/kvm.h   |   1 +
>   arch/x86/kvm/svm/svm.c            |  87 +++++++++++--
>   arch/x86/kvm/svm/svm.h            |   6 +-
>   arch/x86/kvm/x86.c                |  14 ++-
>   arch/x86/kvm/x86.h                |   2 +
>   include/uapi/linux/kvm.h          |   1 +
>   kernel/module.c                   |   8 +-
>   scripts/gdb/linux/symbols.py      | 203 ++++++++++++++++++++----------
>   15 files changed, 272 insertions(+), 84 deletions(-)
> 



From abel.vesa at nxp.com  Fri Apr  2 18:42:28 2021
From: abel.vesa at nxp.com (Abel Vesa)
Date: Fri, 2 Apr 2021 20:42:28 +0300
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <20210402164506.520121-1-adrien.grassein@gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
Message-ID: <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>

On 21-04-02 18:45:04, Adrien Grassein wrote:
> Hi,
> 
> this patch et aims to add the support of the i.MX 8 Power Domain driver.
> Some devices (like usbotg2) can't work without this patch as their
> attached power domain are down.
> 
> The original drivr was taken from le imx kernel and aapted to fit with
> the actual mainline (minor fixes).
> 
> Thanks,
> 

Big NACK for the whole series.

This approach has already been rejected upstream.

Plus, you changed the original author, this work was originally done by Jacky Bai.

> Adrien Grassein (2):
>   dt-bindings: power: Add documentation for imx8m power domain driver
>   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> 
>  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
>  MAINTAINERS                                   |  10 +
>  drivers/soc/imx/Kconfig                       |   7 +
>  drivers/soc/imx/Makefile                      |   1 +
>  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
>  include/dt-bindings/power/imx8mm-power.h      |  21 ++
>  include/dt-bindings/power/imx8mn-power.h      |  15 ++
>  include/dt-bindings/power/imx8mp-power.h      |  28 +++
>  include/soc/imx/imx_sip.h                     |  12 +
>  9 files changed, 416 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
>  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
>  create mode 100644 include/dt-bindings/power/imx8mm-power.h
>  create mode 100644 include/dt-bindings/power/imx8mn-power.h
>  create mode 100644 include/dt-bindings/power/imx8mp-power.h
>  create mode 100644 include/soc/imx/imx_sip.h
> 
> -- 
> 2.25.1
> 


From adrien.grassein at gmail.com  Fri Apr  2 18:48:41 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Fri, 2 Apr 2021 19:48:41 +0200
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
 <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
Message-ID: <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>

Hi,

Le ven. 2 avr. 2021 ? 19:42, Abel Vesa <abel.vesa at nxp.com> a ?crit :
>
> On 21-04-02 18:45:04, Adrien Grassein wrote:
> > Hi,
> >
> > this patch et aims to add the support of the i.MX 8 Power Domain driver.
> > Some devices (like usbotg2) can't work without this patch as their
> > attached power domain are down.
> >
> > The original drivr was taken from le imx kernel and aapted to fit with
> > the actual mainline (minor fixes).
> >
> > Thanks,
> >
>
> Big NACK for the whole series.
>
> This approach has already been rejected upstream.

So what is the correct approach?
At this point otg2 node of imx8mm is not working at all (and blocks the whole
boot of the kernel)

>
> Plus, you changed the original author, this work was originally done by Jacky Bai.

I have not changed this, the original author is not mentioned on the
original patch.
(Taken from https://github.com/Freescale/linux-fslc branch 5.4-2.2.x-imx)

>
> > Adrien Grassein (2):
> >   dt-bindings: power: Add documentation for imx8m power domain driver
> >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> >
> >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
> >  MAINTAINERS                                   |  10 +
> >  drivers/soc/imx/Kconfig                       |   7 +
> >  drivers/soc/imx/Makefile                      |   1 +
> >  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
> >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> >  include/dt-bindings/power/imx8mn-power.h      |  15 ++
> >  include/dt-bindings/power/imx8mp-power.h      |  28 +++
> >  include/soc/imx/imx_sip.h                     |  12 +
> >  9 files changed, 416 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> >  create mode 100644 include/soc/imx/imx_sip.h
> >
> > --
> > 2.25.1
> >

Thanks,


From abel.vesa at nxp.com  Fri Apr  2 18:58:50 2021
From: abel.vesa at nxp.com (Abel Vesa)
Date: Fri, 2 Apr 2021 20:58:50 +0300
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
 <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
 <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>
Message-ID: <20210402175850.6ovyum7ot4pgv2wx@fsr-ub1664-175>

On 21-04-02 19:48:41, Adrien Grassein wrote:
> Hi,
> 
> Le ven. 2 avr. 2021 ? 19:42, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> >
> > On 21-04-02 18:45:04, Adrien Grassein wrote:
> > > Hi,
> > >
> > > this patch et aims to add the support of the i.MX 8 Power Domain driver.
> > > Some devices (like usbotg2) can't work without this patch as their
> > > attached power domain are down.
> > >
> > > The original drivr was taken from le imx kernel and aapted to fit with
> > > the actual mainline (minor fixes).
> > >
> > > Thanks,
> > >
> >
> > Big NACK for the whole series.
> >
> > This approach has already been rejected upstream.
> 
> So what is the correct approach?
> At this point otg2 node of imx8mm is not working at all (and blocks the whole
> boot of the kernel)
> 

Have a look at this thread:

https://lkml.org/lkml/2020/4/27/706

> >
> > Plus, you changed the original author, this work was originally done by Jacky Bai.
> 
> I have not changed this, the original author is not mentioned on the
> original patch.

Here is the original commit:

https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0


> 
> >
> > > Adrien Grassein (2):
> > >   dt-bindings: power: Add documentation for imx8m power domain driver
> > >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> > >
> > >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
> > >  MAINTAINERS                                   |  10 +
> > >  drivers/soc/imx/Kconfig                       |   7 +
> > >  drivers/soc/imx/Makefile                      |   1 +
> > >  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
> > >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> > >  include/dt-bindings/power/imx8mn-power.h      |  15 ++
> > >  include/dt-bindings/power/imx8mp-power.h      |  28 +++
> > >  include/soc/imx/imx_sip.h                     |  12 +
> > >  9 files changed, 416 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> > >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> > >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> > >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> > >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> > >  create mode 100644 include/soc/imx/imx_sip.h
> > >
> > > --
> > > 2.25.1
> > >
> 
> Thanks,


From mani at kernel.org  Fri Apr  2 19:04:07 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Fri, 2 Apr 2021 23:34:07 +0530
Subject: [PATCH v2 2/6] dt-bindings: soc: actions: Add Actions Semi Owl
 socinfo binding
In-Reply-To: <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210402180407.GA31906@thinkpad>

On Tue, Mar 30, 2021 at 04:48:17PM +0300, Cristian Ciocaltea wrote:
> Add devicetree binding for the Actions Semi Owl socinfo driver.
> 

Devicetree binding shouldn't be added for a driver instead for an IP or hw.

> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> ---
>  .../bindings/soc/actions/owl-socinfo.yaml     | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> new file mode 100644
> index 000000000000..01e4a8b4f5ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/actions/owl-socinfo.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Actions Semi Owl SoC info module
> +
> +maintainers:
> +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> +
> +description: |
> +  Actions Semi Owl SoC info module provides access to various information
> +  about the S500, S700 and S900 SoC variants, such as serial number or id.
> +

S700/S900 are not yet confirmed, so please avoid them.

> +select:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - actions,s500-soc
> +          - actions,s700-soc
> +          - actions,s900-soc
> +  required:
> +    - compatible
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - actions,s500-soc
> +          - actions,s700-soc
> +          - actions,s900-soc
> +      - const: simple-bus
> +
> +required:
> +  - compatible
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +    / {
> +        compatible = "roseapplepi,roseapplepi", "actions,s500";
> +        model = "Roseapple Pi";
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +
> +        soc {
> +            compatible = "actions,s500-soc", "simple-bus";

No. This shouldn't fall under /soc. I think you should added a separate
compatible for the reserved memory itself and add a corresponding socinfo
driver under drivers/soc.

This way it is obvious that the information is contained in a memory region and
a driver is used for parsing that.

Thanks,
Mani

> +            #address-cells = <1>;
> +            #size-cells = <1>;
> +            ranges;
> +        };
> +    };
> +
> +...
> -- 
> 2.31.1
> 


From mani at kernel.org  Fri Apr  2 19:06:07 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Fri, 2 Apr 2021 23:36:07 +0530
Subject: [PATCH v2 1/6] dt-bindings: reserved-memory: Add Owl SoC serial
 number binding
In-Reply-To: <20210401174001.GA2016477@BV030612LT>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <fb74862bec15f1e9e0c4d8b70ebd6c07c6eb1a40.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401170704.GA610119@robh.at.kernel.org>
 <20210401174001.GA2016477@BV030612LT>
Message-ID: <20210402180607.GB31906@thinkpad>

On Thu, Apr 01, 2021 at 08:40:01PM +0300, Cristian Ciocaltea wrote:
> On Thu, Apr 01, 2021 at 12:07:04PM -0500, Rob Herring wrote:
> > On Tue, Mar 30, 2021 at 04:48:16PM +0300, Cristian Ciocaltea wrote:
> > > Add devicetree binding for the Actions Semi Owl SoC serial number
> > > reserved-memory range.
> > > 
> > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > > ---
> > >  .../actions,owl-soc-serial.yaml               | 53 +++++++++++++++++++
> > >  1 file changed, 53 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > new file mode 100644
> > > index 000000000000..41b71f47ee6c
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > @@ -0,0 +1,53 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/reserved-memory/actions,owl-soc-serial.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Actions Semi Owl reserved-memory for SoC serial number
> > > +
> > > +maintainers:
> > > +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > > +
> > > +description: |
> > > +  Provide access to the memory region where the two parts of the Actions
> > > +  Semi Owl SoC serial number (low & high) can be read from. This information
> > > +  is provided by the bootloader, hence expose it under /reserved-memory node.
> > > +
> > > +  Please refer to reserved-memory.txt in this directory for common binding
> > > +  part and usage.
> > > +
> > > +  This is currently supported only on the S500 SoC variant.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    oneOf:
> > > +      - const: actions,owl-soc-serial
> > > +      - items:
> > > +          - enum:
> > > +              - actions,s500-soc-serial
> > > +          - const: actions,owl-soc-serial
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +
> > > +additionalProperties: true
> > > +
> > > +examples:
> > > +  - |
> > > +    reserved-memory {
> > > +        #address-cells = <1>;
> > > +        #size-cells = <1>;
> > > +        ranges;
> > > +
> > > +        soc_serial: soc-serial at 800 {
> > > +            compatible = "actions,s500-soc-serial", "actions,owl-soc-serial";
> > > +            reg = <0x800 0x8>;
> > 
> > You end up wasting a whole page of memory for 8 bytes. It may be better 
> > to copy this to a DT property ('serial-number' is already a defined root 
> > property).
> 
> Actually there is more information provided by the vendor bootloader

Then you should call it as socinfo or something not soc_serial.

Thanks,
Mani

> in this memory page, so we might use it once we are able to decode it.
> For the moment I could only identify the serial number.
> 
> Thanks,
> Cristi
> 
> > Rob


From adrien.grassein at gmail.com  Fri Apr  2 19:11:18 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Fri, 2 Apr 2021 20:11:18 +0200
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <20210402175850.6ovyum7ot4pgv2wx@fsr-ub1664-175>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
 <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
 <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>
 <20210402175850.6ovyum7ot4pgv2wx@fsr-ub1664-175>
Message-ID: <CABkfQAESbRQsn3fWo4uKeVMMf84LurCLkdgvbPi+A4Kqr87enw@mail.gmail.com>

Le ven. 2 avr. 2021 ? 19:58, Abel Vesa <abel.vesa at nxp.com> a ?crit :
>
> On 21-04-02 19:48:41, Adrien Grassein wrote:
> > Hi,
> >
> > Le ven. 2 avr. 2021 ? 19:42, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> > >
> > > On 21-04-02 18:45:04, Adrien Grassein wrote:
> > > > Hi,
> > > >
> > > > this patch et aims to add the support of the i.MX 8 Power Domain driver.
> > > > Some devices (like usbotg2) can't work without this patch as their
> > > > attached power domain are down.
> > > >
> > > > The original drivr was taken from le imx kernel and aapted to fit with
> > > > the actual mainline (minor fixes).
> > > >
> > > > Thanks,
> > > >
> > >
> > > Big NACK for the whole series.
> > >
> > > This approach has already been rejected upstream.
> >
> > So what is the correct approach?
> > At this point otg2 node of imx8mm is not working at all (and blocks the whole
> > boot of the kernel)
> >
>
> Have a look at this thread:
>
> https://lkml.org/lkml/2020/4/27/706
>
Understood, so I will try to update the gpc driver (at least for otg).

> > >
> > > Plus, you changed the original author, this work was originally done by Jacky Bai.
> >
> > I have not changed this, the original author is not mentioned on the
> > original patch.
>
> Here is the original commit:
>
> https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0
>
>
> >
> > >
> > > > Adrien Grassein (2):
> > > >   dt-bindings: power: Add documentation for imx8m power domain driver
> > > >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> > > >
> > > >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
> > > >  MAINTAINERS                                   |  10 +
> > > >  drivers/soc/imx/Kconfig                       |   7 +
> > > >  drivers/soc/imx/Makefile                      |   1 +
> > > >  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
> > > >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> > > >  include/dt-bindings/power/imx8mn-power.h      |  15 ++
> > > >  include/dt-bindings/power/imx8mp-power.h      |  28 +++
> > > >  include/soc/imx/imx_sip.h                     |  12 +
> > > >  9 files changed, 416 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> > > >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> > > >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> > > >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> > > >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> > > >  create mode 100644 include/soc/imx/imx_sip.h
> > > >
> > > > --
> > > > 2.25.1
> > > >
> >
> > Thanks,

Thanks,


From mani at kernel.org  Fri Apr  2 19:16:24 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Fri, 2 Apr 2021 23:46:24 +0530
Subject: [PATCH v2 3/6] soc: actions: Add Actions Semi Owl socinfo driver
In-Reply-To: <75ec4eff3e6113f4e72daa1b428c355b28005297.1617110420.git.cristian.ciocaltea@gmail.com>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <75ec4eff3e6113f4e72daa1b428c355b28005297.1617110420.git.cristian.ciocaltea@gmail.com>
Message-ID: <20210402181624.GC31906@thinkpad>

On Tue, Mar 30, 2021 at 04:48:18PM +0300, Cristian Ciocaltea wrote:
> The driver provides information about the Action Semi Owl family of
> SoCs (S500, S700 and S900) to user space via sysfs: machine, family,
> soc_id, serial_number.
> 
> Note the serial number is currently provided only for the S500 SoC
> variant.
> 
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> ---
>  drivers/soc/actions/Kconfig                   |   8 +
>  drivers/soc/actions/Makefile                  |   1 +
>  drivers/soc/actions/owl-socinfo.c             | 152 ++++++++++++++++++
>  include/linux/soc/actions/owl-serial-number.h |  20 +++
>  4 files changed, 181 insertions(+)
>  create mode 100644 drivers/soc/actions/owl-socinfo.c
>  create mode 100644 include/linux/soc/actions/owl-serial-number.h
> 
> diff --git a/drivers/soc/actions/Kconfig b/drivers/soc/actions/Kconfig
> index 1aca2058a40c..15faade9282d 100644
> --- a/drivers/soc/actions/Kconfig
> +++ b/drivers/soc/actions/Kconfig
> @@ -14,4 +14,12 @@ config OWL_PM_DOMAINS
>  	  power-gating on Actions Semiconductor S500, S700 and S900 SoCs.
>  	  If unsure, say 'n'.
>  
> +config OWL_SOCINFO
> +	bool "Actions Semi Owl SoC info driver"
> +	default ARCH_ACTIONS
> +	select SOC_BUS
> +	help
> +	  Say 'y' here to support the Action Semiconductor Owl socinfo

Actions Semi

> +	  driver, providing information about the SoC to user space.
> +
>  endif
> diff --git a/drivers/soc/actions/Makefile b/drivers/soc/actions/Makefile
> index 4db9e7b050e5..4b2591d3089f 100644
> --- a/drivers/soc/actions/Makefile
> +++ b/drivers/soc/actions/Makefile
> @@ -2,3 +2,4 @@
>  
>  obj-$(CONFIG_OWL_PM_DOMAINS_HELPER) += owl-sps-helper.o
>  obj-$(CONFIG_OWL_PM_DOMAINS) += owl-sps.o
> +obj-$(CONFIG_OWL_SOCINFO) += owl-socinfo.o
> diff --git a/drivers/soc/actions/owl-socinfo.c b/drivers/soc/actions/owl-socinfo.c
> new file mode 100644
> index 000000000000..f28eafac3792
> --- /dev/null
> +++ b/drivers/soc/actions/owl-socinfo.c
> @@ -0,0 +1,152 @@

[...]

> + * Access SoC's serial number stored by the bootloader in DDR memory.
> + */
> +static int owl_socinfo_read_serial_rmem(struct device *dev)
> +{
> +	struct reserved_mem *rmem;
> +	struct device_node *np;
> +	int ret = 0;
> +
> +	np = of_find_compatible_node(NULL, NULL, "actions,owl-soc-serial");
> +	if (!np)
> +		return -ENXIO;
> +
> +	rmem = of_reserved_mem_lookup(np);

If you do this correctly, you could use "pdev->dev.of_node" here instead of
using "of_find_compatible_node()" for getting np.

> +	if (!rmem) {
> +		dev_err(dev, "failed to acquire reserved memory region\n");
> +		ret = -EINVAL;
> +		goto out_put;
> +	}
> +

[...]

> +static const struct of_device_id owl_socinfo_of_match[] = {
> +	{ .compatible = "actions,s500-soc", .data = &s500_soc_info, },
> +	{ .compatible = "actions,s700-soc", .data = &s700_soc_info, },
> +	{ .compatible = "actions,s900-soc", .data = &s900_soc_info, },

Please don't add S700/S900 for now.

> +	{ }
> +};
> +
> +static struct platform_driver owl_socinfo_platform_driver = {
> +	.probe = owl_socinfo_probe,
> +	.driver = {
> +		.name = "owl-socinfo",
> +		.of_match_table = owl_socinfo_of_match,
> +	},
> +};
> +
> +static int __init owl_socinfo_init(void)
> +{
> +	return platform_driver_register(&owl_socinfo_platform_driver);
> +}
> +subsys_initcall(owl_socinfo_init);
> diff --git a/include/linux/soc/actions/owl-serial-number.h b/include/linux/soc/actions/owl-serial-number.h
> new file mode 100644
> index 000000000000..f8595417668f
> --- /dev/null
> +++ b/include/linux/soc/actions/owl-serial-number.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2021 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> + */
> +
> +#ifndef __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__
> +#define __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__
> +
> +#if IS_ENABLED(CONFIG_OWL_SOCINFO)
> +u32 owl_get_soc_serial_low(void);
> +u32 owl_get_soc_serial_high(void);

Where are these APIs used?

Thanks,
Mani

> +#else
> +static inline u32 owl_get_soc_serial_low(void)
> +{ return 0; }
> +
> +static inline u32 owl_get_soc_serial_high(void)
> +{ return 0; }
> +#endif /* CONFIG_OWL_SOCINFO */
> +
> +#endif /* __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__ */
> -- 
> 2.31.1
> 


From zev at bewilderbeest.net  Fri Apr  2 19:27:21 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri,  2 Apr 2021 13:27:21 -0500
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210402182724.20848-1-zev@bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
Message-ID: <20210402182724.20848-2-zev@bewilderbeest.net>

This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it
was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
       offset and bit number to identify how the SIRQ polarity should be
       configured. One possible data source is the LPC/eSPI mode bit. Only
       applicable to aspeed,ast2500-vuart.
+    deprecated: true
 
 required:
   - reg
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 19:27:20 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri,  2 Apr 2021 13:27:20 -0500
Subject: [PATCH v4 0/4] aspeed-vuart: generalized DT properties
Message-ID: <20210402182724.20848-1-zev@bewilderbeest.net>

This series generalizes the aspeed-vuart driver's device tree
properties to cover all the attributes it currently exposes via sysfs.

The aspeed,sirq-polarity-sense property was a bit of a design mistake
in that it ties Aspeed VUART SIRQ polarity to SCU register bits that
aren't really inherently related to it; the first patch in this series
deprecates it (though we hope to eventually remove it).

The rest of the series adds two new properties, aspeed,lpc-io-reg and
aspeed,lpc-interrupts.  The latter allows describing the SIRQ polarity
(along with the interrupt number) directly, providing a simpler
replacement for aspeed,sirq-polarity-sense.


Changes since v3 [2]:
 - renamed properties to match aspeed,ast2400-kcs-bmc

Changes since v2 [0]:
 - expanded to also handle sirq number and lpc address in addition to
   sirq polarity
 - added default settings if DT properties not specified
 - refactored existing sysfs code slightly, adding range checks
 - cleaned up 'make dt_binding_check' warnings

Changes since v1 [1]:
 - deprecate and retain aspeed,sirq-polarity-sense instead of removing it
 - drop e3c246d4i dts addition from this series


[0] https://lore.kernel.org/openbmc/20210401005702.28271-1-zev at bewilderbeest.net/
[1] https://lore.kernel.org/openbmc/20210330002338.335-1-zev at bewilderbeest.net/
[2] https://lore.kernel.org/openbmc/20210402004716.15961-1-zev at bewilderbeest.net/


Zev Weiss (4):
  dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
  drivers/tty/serial/8250: refactor sirq and lpc address setting code
  drivers/tty/serial/8250: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts DT properties
  dt-bindings: serial: 8250: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts

 .../devicetree/bindings/serial/8250.yaml      | 28 +++++-
 drivers/tty/serial/8250/8250_aspeed_vuart.c   | 95 +++++++++++++++----
 2 files changed, 103 insertions(+), 20 deletions(-)

-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 19:27:23 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri,  2 Apr 2021 13:27:23 -0500
Subject: [PATCH v4 3/4] drivers/tty/serial/8250: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts DT properties
In-Reply-To: <20210402182724.20848-1-zev@bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
Message-ID: <20210402182724.20848-4-zev@bewilderbeest.net>

These allow describing all the Aspeed VUART attributes currently
available via sysfs.  aspeed,sirq provides a replacement for the
deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 44 ++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 8433f8dbb186..75ef006fa24b 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -28,6 +28,10 @@
 #define ASPEED_VUART_ADDRL		0x28
 #define ASPEED_VUART_ADDRH		0x2c
 
+#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
+#define ASPEED_VUART_DEFAULT_SIRQ	4
+#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
+
 struct aspeed_vuart {
 	struct device		*dev;
 	void __iomem		*regs;
@@ -393,7 +397,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 	struct aspeed_vuart *vuart;
 	struct device_node *np;
 	struct resource *res;
-	u32 clk, prop;
+	u32 clk, prop, sirq[2];
+	bool sirq_polarity;
 	int rc;
 
 	np = pdev->dev.of_node;
@@ -501,6 +506,43 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 		of_node_put(sirq_polarity_sense_args.np);
 	}
 
+	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
+	if (rc < 0)
+		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
+
+	rc = aspeed_vuart_set_lpc_address(vuart, prop);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
+		goto err_clk_disable;
+	}
+
+	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
+	if (rc < 0) {
+		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
+		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
+	}
+
+	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts property\n");
+		goto err_clk_disable;
+	}
+
+	switch (sirq[1]) {
+	case IRQ_TYPE_LEVEL_LOW:
+		sirq_polarity = false;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		sirq_polarity = true;
+		break;
+	default:
+		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts property\n");
+		rc = -EINVAL;
+		goto err_clk_disable;
+	}
+
+	aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
+
 	aspeed_vuart_set_enabled(vuart, true);
 	aspeed_vuart_set_host_tx_discard(vuart, true);
 	platform_set_drvdata(pdev, vuart);
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 19:27:24 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri,  2 Apr 2021 13:27:24 -0500
Subject: [PATCH v4 4/4] dt-bindings: serial: 8250: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts
In-Reply-To: <20210402182724.20848-1-zev@bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
Message-ID: <20210402182724.20848-5-zev@bewilderbeest.net>

These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,lpc-interrupts provides
a replacement for the deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..0e82b076e199 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,13 @@ maintainers:
 allOf:
   - $ref: /schemas/serial.yaml#
   - if:
-      required:
-        - aspeed,sirq-polarity-sense
+      anyOf:
+        - required:
+            - aspeed,lpc-io-reg
+        - required:
+            - aspeed,lpc-interrupts
+        - required:
+            - aspeed,sirq-polarity-sense
     then:
       properties:
         compatible:
@@ -190,6 +195,20 @@ properties:
       applicable to aspeed,ast2500-vuart.
     deprecated: true
 
+  aspeed,lpc-io-reg:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      The VUART LPC address.  Only applicable to aspeed,ast2500-vuart.
+
+  aspeed,lpc-interrupts:
+    $ref: "/schemas/types.yaml#/definitions/uint32-array"
+    minItems: 2
+    maxItems: 2
+    description: |
+      A 2-cell property describing the VUART SIRQ number and SIRQ
+      polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH).  Only
+      applicable to aspeed,ast2500-vuart.
+
 required:
   - reg
   - interrupts
@@ -221,6 +240,7 @@ examples:
     };
   - |
     #include <dt-bindings/clock/aspeed-clock.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
     serial at 1e787000 {
         compatible = "aspeed,ast2500-vuart";
         reg = <0x1e787000 0x40>;
@@ -228,7 +248,8 @@ examples:
         interrupts = <8>;
         clocks = <&syscon ASPEED_CLK_APB>;
         no-loopback-test;
-        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
+        aspeed,lpc-io-reg = <0x3f8>;
+        aspeed,lpc-interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
     };
 
 ...
-- 
2.31.1



From zev at bewilderbeest.net  Fri Apr  2 19:27:22 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri,  2 Apr 2021 13:27:22 -0500
Subject: [PATCH v4 2/4] drivers/tty/serial/8250: refactor sirq and lpc address
 setting code
In-Reply-To: <20210402182724.20848-1-zev@bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
Message-ID: <20210402182724.20848-3-zev@bewilderbeest.net>

This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers.  While we're at it,
these functions now provide some basic bounds-checking on their
arguments.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..8433f8dbb186 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
 }
 
+static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
+{
+	if (addr > U16_MAX)
+		return -EINVAL;
+
+	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+	return 0;
+}
+
 static ssize_t lpc_address_store(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
-	unsigned long val;
+	u32 val;
 	int err;
 
-	err = kstrtoul(buf, 0, &val);
+	err = kstrtou32(buf, 0, &val);
 	if (err)
 		return err;
 
-	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
-	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
-
-	return count;
+	err = aspeed_vuart_set_lpc_address(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(lpc_address);
@@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
 }
 
+static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
+{
+	u8 reg;
+
+	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
+		return -EINVAL;
+
+	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+	reg |= sirq;
+	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+	return 0;
+}
+
 static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
 			  const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
 	unsigned long val;
 	int err;
-	u8 reg;
 
 	err = kstrtoul(buf, 0, &val);
 	if (err)
 		return err;
 
-	val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
-	val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-
-	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
-	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-	reg |= val;
-	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
-
-	return count;
+	err = aspeed_vuart_set_sirq(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(sirq);
-- 
2.31.1



From dariobin at libero.it  Fri Apr  2 20:25:16 2021
From: dariobin at libero.it (Dario Binacchi)
Date: Fri,  2 Apr 2021 21:25:16 +0200
Subject: [PATCH] ARM: OMAP2+: CM: remove omap2_set_globals_cm()
Message-ID: <20210402192516.9143-1-dariobin@libero.it>

The function is no longer used, so let's remove it.

Signed-off-by: Dario Binacchi <dariobin at libero.it>

---

 arch/arm/mach-omap2/cm.h        |  1 -
 arch/arm/mach-omap2/cm_common.c | 13 -------------
 2 files changed, 14 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index d02fe63dab59..14beb59e5f7b 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -26,7 +26,6 @@
 
 extern struct omap_domain_base cm_base;
 extern struct omap_domain_base cm2_base;
-extern void omap2_set_globals_cm(void __iomem *cm, void __iomem *cm2);
 # endif
 
 /*
diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
index b7ea609386d5..e2d069fe67f1 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -37,19 +37,6 @@ struct omap_domain_base cm2_base;
 #define CM_NO_CLOCKS		0x1
 #define CM_SINGLE_INSTANCE	0x2
 
-/**
- * omap2_set_globals_cm - set the CM/CM2 base addresses (for early use)
- * @cm: CM base virtual address
- * @cm2: CM2 base virtual address (if present on the booted SoC)
- *
- * XXX Will be replaced when the PRM/CM drivers are completed.
- */
-void __init omap2_set_globals_cm(void __iomem *cm, void __iomem *cm2)
-{
-	cm_base.va = cm;
-	cm2_base.va = cm2;
-}
-
 /**
  * cm_split_idlest_reg - split CM_IDLEST reg addr into its components
  * @idlest_reg: CM_IDLEST* virtual address
-- 
2.17.1



From cristian.ciocaltea at gmail.com  Fri Apr  2 20:25:55 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Fri, 2 Apr 2021 22:25:55 +0300
Subject: [PATCH v2 2/6] dt-bindings: soc: actions: Add Actions Semi Owl
 socinfo binding
In-Reply-To: <20210402180407.GA31906@thinkpad>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <15da0257b10aa62bfb7046437915d05a614c01ee.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210402180407.GA31906@thinkpad>
Message-ID: <20210402192555.GA2052516@BV030612LT>

On Fri, Apr 02, 2021 at 11:34:07PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Mar 30, 2021 at 04:48:17PM +0300, Cristian Ciocaltea wrote:
> > Add devicetree binding for the Actions Semi Owl socinfo driver.
> > 
> 
> Devicetree binding shouldn't be added for a driver instead for an IP or hw.
> 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > ---
> >  .../bindings/soc/actions/owl-socinfo.yaml     | 57 +++++++++++++++++++
> >  1 file changed, 57 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > new file mode 100644
> > index 000000000000..01e4a8b4f5ac
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/actions/owl-socinfo.yaml
> > @@ -0,0 +1,57 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/actions/owl-socinfo.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Actions Semi Owl SoC info module
> > +
> > +maintainers:
> > +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > +
> > +description: |
> > +  Actions Semi Owl SoC info module provides access to various information
> > +  about the S500, S700 and S900 SoC variants, such as serial number or id.
> > +
> 
> S700/S900 are not yet confirmed, so please avoid them.
> 
> > +select:
> > +  properties:
> > +    compatible:
> > +      contains:
> > +        enum:
> > +          - actions,s500-soc
> > +          - actions,s700-soc
> > +          - actions,s900-soc
> > +  required:
> > +    - compatible
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - actions,s500-soc
> > +          - actions,s700-soc
> > +          - actions,s900-soc
> > +      - const: simple-bus
> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > +  - |
> > +    / {
> > +        compatible = "roseapplepi,roseapplepi", "actions,s500";
> > +        model = "Roseapple Pi";
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +
> > +        soc {
> > +            compatible = "actions,s500-soc", "simple-bus";
> 
> No. This shouldn't fall under /soc. I think you should added a separate
> compatible for the reserved memory itself and add a corresponding socinfo
> driver under drivers/soc.
> 
> This way it is obvious that the information is contained in a memory region and
> a driver is used for parsing that.

I avoided on purpose to bind the driver on the reserved memory node
in order to be able to handle also the S700 and S900 SoCs, for which
we currently provide (only) the following information: machine, family,
soc_id.

I assumed the serial_number is not mandatory and we can use the driver
as it is for all SoC variants. I don't know how the serial number for
S700 and S900 could be read, but I think it is very likely they require
a different access method.

Hence my intention was to keep the driver generic, not coupled strictly
with the serial number information.

Regards,
Cristi

> Thanks,
> Mani
> 
> > +            #address-cells = <1>;
> > +            #size-cells = <1>;
> > +            ranges;
> > +        };
> > +    };
> > +
> > +...
> > -- 
> > 2.31.1
> > 


From dariobin at libero.it  Fri Apr  2 20:27:20 2021
From: dariobin at libero.it (Dario Binacchi)
Date: Fri,  2 Apr 2021 21:27:20 +0200
Subject: [PATCH] ARM: OMAP2+: remove omap2_set_globals_control()
Message-ID: <20210402192720.9487-1-dariobin@libero.it>

The function is no longer used, so let's remove it.

Signed-off-by: Dario Binacchi <dariobin at libero.it>

---

 arch/arm/mach-omap2/control.c | 5 -----
 arch/arm/mach-omap2/control.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 73338cf80d76..062d431fc33a 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -136,11 +136,6 @@ struct omap3_control_regs {
 static struct omap3_control_regs control_context;
 #endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
 
-void __init omap2_set_globals_control(void __iomem *ctrl)
-{
-	omap2_ctrl_base = ctrl;
-}
-
 u8 omap_ctrl_readb(u16 offset)
 {
 	u32 val;
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index eceb4b09adb2..c4ca30ba1790 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -528,7 +528,6 @@ extern int omap3_ctrl_save_padconf(void);
 void omap3_ctrl_init(void);
 int omap2_control_base_init(void);
 int omap_control_init(void);
-void omap2_set_globals_control(void __iomem *ctrl);
 void __init omap3_control_legacy_iomap_init(void);
 #else
 #define omap_ctrl_readb(x)		0
-- 
2.17.1



From cristian.ciocaltea at gmail.com  Fri Apr  2 20:36:08 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Fri, 2 Apr 2021 22:36:08 +0300
Subject: [PATCH v2 3/6] soc: actions: Add Actions Semi Owl socinfo driver
In-Reply-To: <20210402181624.GC31906@thinkpad>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <75ec4eff3e6113f4e72daa1b428c355b28005297.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210402181624.GC31906@thinkpad>
Message-ID: <20210402193608.GB2052516@BV030612LT>

On Fri, Apr 02, 2021 at 11:46:24PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Mar 30, 2021 at 04:48:18PM +0300, Cristian Ciocaltea wrote:
> > The driver provides information about the Action Semi Owl family of
> > SoCs (S500, S700 and S900) to user space via sysfs: machine, family,
> > soc_id, serial_number.
> > 
> > Note the serial number is currently provided only for the S500 SoC
> > variant.
> > 
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > ---
> >  drivers/soc/actions/Kconfig                   |   8 +
> >  drivers/soc/actions/Makefile                  |   1 +
> >  drivers/soc/actions/owl-socinfo.c             | 152 ++++++++++++++++++
> >  include/linux/soc/actions/owl-serial-number.h |  20 +++
> >  4 files changed, 181 insertions(+)
> >  create mode 100644 drivers/soc/actions/owl-socinfo.c
> >  create mode 100644 include/linux/soc/actions/owl-serial-number.h
> > 
> > diff --git a/drivers/soc/actions/Kconfig b/drivers/soc/actions/Kconfig
> > index 1aca2058a40c..15faade9282d 100644
> > --- a/drivers/soc/actions/Kconfig
> > +++ b/drivers/soc/actions/Kconfig
> > @@ -14,4 +14,12 @@ config OWL_PM_DOMAINS
> >  	  power-gating on Actions Semiconductor S500, S700 and S900 SoCs.
> >  	  If unsure, say 'n'.
> >  
> > +config OWL_SOCINFO
> > +	bool "Actions Semi Owl SoC info driver"
> > +	default ARCH_ACTIONS
> > +	select SOC_BUS
> > +	help
> > +	  Say 'y' here to support the Action Semiconductor Owl socinfo
> 
> Actions Semi
> 
> > +	  driver, providing information about the SoC to user space.
> > +
> >  endif
> > diff --git a/drivers/soc/actions/Makefile b/drivers/soc/actions/Makefile
> > index 4db9e7b050e5..4b2591d3089f 100644
> > --- a/drivers/soc/actions/Makefile
> > +++ b/drivers/soc/actions/Makefile
> > @@ -2,3 +2,4 @@
> >  
> >  obj-$(CONFIG_OWL_PM_DOMAINS_HELPER) += owl-sps-helper.o
> >  obj-$(CONFIG_OWL_PM_DOMAINS) += owl-sps.o
> > +obj-$(CONFIG_OWL_SOCINFO) += owl-socinfo.o
> > diff --git a/drivers/soc/actions/owl-socinfo.c b/drivers/soc/actions/owl-socinfo.c
> > new file mode 100644
> > index 000000000000..f28eafac3792
> > --- /dev/null
> > +++ b/drivers/soc/actions/owl-socinfo.c
> > @@ -0,0 +1,152 @@
> 
> [...]
> 
> > + * Access SoC's serial number stored by the bootloader in DDR memory.
> > + */
> > +static int owl_socinfo_read_serial_rmem(struct device *dev)
> > +{
> > +	struct reserved_mem *rmem;
> > +	struct device_node *np;
> > +	int ret = 0;
> > +
> > +	np = of_find_compatible_node(NULL, NULL, "actions,owl-soc-serial");
> > +	if (!np)
> > +		return -ENXIO;
> > +
> > +	rmem = of_reserved_mem_lookup(np);
> 
> If you do this correctly, you could use "pdev->dev.of_node" here instead of
> using "of_find_compatible_node()" for getting np.

Right, as previously explained, my intention was to avoid binding the
driver on the serial number node in order to keep it generic enough.

> > +	if (!rmem) {
> > +		dev_err(dev, "failed to acquire reserved memory region\n");
> > +		ret = -EINVAL;
> > +		goto out_put;
> > +	}
> > +
> 
> [...]
> 
> > +static const struct of_device_id owl_socinfo_of_match[] = {
> > +	{ .compatible = "actions,s500-soc", .data = &s500_soc_info, },
> > +	{ .compatible = "actions,s700-soc", .data = &s700_soc_info, },
> > +	{ .compatible = "actions,s900-soc", .data = &s900_soc_info, },
> 
> Please don't add S700/S900 for now.

I assumed we can use the driver for S700/S900, even though the serial
number is not provided for them.

> > +	{ }
> > +};
> > +
> > +static struct platform_driver owl_socinfo_platform_driver = {
> > +	.probe = owl_socinfo_probe,
> > +	.driver = {
> > +		.name = "owl-socinfo",
> > +		.of_match_table = owl_socinfo_of_match,
> > +	},
> > +};
> > +
> > +static int __init owl_socinfo_init(void)
> > +{
> > +	return platform_driver_register(&owl_socinfo_platform_driver);
> > +}
> > +subsys_initcall(owl_socinfo_init);
> > diff --git a/include/linux/soc/actions/owl-serial-number.h b/include/linux/soc/actions/owl-serial-number.h
> > new file mode 100644
> > index 000000000000..f8595417668f
> > --- /dev/null
> > +++ b/include/linux/soc/actions/owl-serial-number.h
> > @@ -0,0 +1,20 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (c) 2021 Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > + */
> > +
> > +#ifndef __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__
> > +#define __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__
> > +
> > +#if IS_ENABLED(CONFIG_OWL_SOCINFO)
> > +u32 owl_get_soc_serial_low(void);
> > +u32 owl_get_soc_serial_high(void);
> 
> Where are these APIs used?

This will be used by the Ethernet MAC driver to generate a stable
address. Initially I used the global 'system_serial_{low,high}'
variables to pass this information outside the driver, but that is
not portable, i.e. only supported on ARM32, not ARM64.

Thanks for the review,
Cristi

> Thanks,
> Mani
> 
> > +#else
> > +static inline u32 owl_get_soc_serial_low(void)
> > +{ return 0; }
> > +
> > +static inline u32 owl_get_soc_serial_high(void)
> > +{ return 0; }
> > +#endif /* CONFIG_OWL_SOCINFO */
> > +
> > +#endif /* __SOC_ACTIONS_OWL_SERIAL_NUMBER_H__ */
> > -- 
> > 2.31.1
> > 


From cristian.ciocaltea at gmail.com  Fri Apr  2 20:44:04 2021
From: cristian.ciocaltea at gmail.com (Cristian Ciocaltea)
Date: Fri, 2 Apr 2021 22:44:04 +0300
Subject: [PATCH v2 1/6] dt-bindings: reserved-memory: Add Owl SoC serial
 number binding
In-Reply-To: <20210402180607.GB31906@thinkpad>
References: <cover.1617110420.git.cristian.ciocaltea@gmail.com>
 <fb74862bec15f1e9e0c4d8b70ebd6c07c6eb1a40.1617110420.git.cristian.ciocaltea@gmail.com>
 <20210401170704.GA610119@robh.at.kernel.org>
 <20210401174001.GA2016477@BV030612LT>
 <20210402180607.GB31906@thinkpad>
Message-ID: <20210402194404.GC2052516@BV030612LT>

On Fri, Apr 02, 2021 at 11:36:07PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Apr 01, 2021 at 08:40:01PM +0300, Cristian Ciocaltea wrote:
> > On Thu, Apr 01, 2021 at 12:07:04PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 04:48:16PM +0300, Cristian Ciocaltea wrote:
> > > > Add devicetree binding for the Actions Semi Owl SoC serial number
> > > > reserved-memory range.
> > > > 
> > > > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > > > ---
> > > >  .../actions,owl-soc-serial.yaml               | 53 +++++++++++++++++++
> > > >  1 file changed, 53 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > > new file mode 100644
> > > > index 000000000000..41b71f47ee6c
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/reserved-memory/actions,owl-soc-serial.yaml
> > > > @@ -0,0 +1,53 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/reserved-memory/actions,owl-soc-serial.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Actions Semi Owl reserved-memory for SoC serial number
> > > > +
> > > > +maintainers:
> > > > +  - Cristian Ciocaltea <cristian.ciocaltea at gmail.com>
> > > > +
> > > > +description: |
> > > > +  Provide access to the memory region where the two parts of the Actions
> > > > +  Semi Owl SoC serial number (low & high) can be read from. This information
> > > > +  is provided by the bootloader, hence expose it under /reserved-memory node.
> > > > +
> > > > +  Please refer to reserved-memory.txt in this directory for common binding
> > > > +  part and usage.
> > > > +
> > > > +  This is currently supported only on the S500 SoC variant.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    oneOf:
> > > > +      - const: actions,owl-soc-serial
> > > > +      - items:
> > > > +          - enum:
> > > > +              - actions,s500-soc-serial
> > > > +          - const: actions,owl-soc-serial
> > > > +
> > > > +  reg:
> > > > +    maxItems: 1
> > > > +
> > > > +required:
> > > > +  - compatible
> > > > +  - reg
> > > > +
> > > > +additionalProperties: true
> > > > +
> > > > +examples:
> > > > +  - |
> > > > +    reserved-memory {
> > > > +        #address-cells = <1>;
> > > > +        #size-cells = <1>;
> > > > +        ranges;
> > > > +
> > > > +        soc_serial: soc-serial at 800 {
> > > > +            compatible = "actions,s500-soc-serial", "actions,owl-soc-serial";
> > > > +            reg = <0x800 0x8>;
> > > 
> > > You end up wasting a whole page of memory for 8 bytes. It may be better 
> > > to copy this to a DT property ('serial-number' is already a defined root 
> > > property).
> > 
> > Actually there is more information provided by the vendor bootloader
> 
> Then you should call it as socinfo or something not soc_serial.

Agree, maybe 'bootinfo' or 'fwinfo', to suggest it is coming from
firmware / bootloader.

Thanks for reviewing,
Cristi

> Thanks,
> Mani
> 
> > in this memory page, so we might use it once we are able to decode it.
> > For the moment I could only identify the serial number.
> > 
> > Thanks,
> > Cristi
> > 
> > > Rob


From gregory.clement at bootlin.com  Fri Apr  2 20:49:00 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 21:49:00 +0200
Subject: [PATCH 0/2] arm64: clearfog-gt-8k: Add DT for fan control
In-Reply-To: <20210309151925.GG1463@shell.armlinux.org.uk>
References: <20210309151925.GG1463@shell.armlinux.org.uk>
Message-ID: <87mtugcvrn.fsf@BL-laptop>

Hi Russell,

> Hi,
>
> This patch series adds the DT descriptions to control a PWM fan on the
> SolidRun Clearfog GT8k platform.
>
>  .../dts/marvell/armada-8040-clearfog-gt-8k.dts     | 127 +++++++++++++++++++++
>  1 file changed, 127 insertions(+)
>

Applied on mvebu/dt64

Thanks,

Gregory


> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Apr  2 20:50:26 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 21:50:26 +0200
Subject: [PATCH mvebu v2 01/10] arm64: dts: marvell: armada-37xx: add
 syscon compatible to NB clk node
In-Reply-To: <20210114124032.12765-2-pali@kernel.org>
References: <20210114124032.12765-1-pali@kernel.org>
 <20210114124032.12765-2-pali@kernel.org>
Message-ID: <87k0pkcvp9.fsf@BL-laptop>

Hi Pali,

> From: Marek Beh?n <kabel at kernel.org>
>
> Add "syscon" compatible to the North Bridge clocks node to allow the
> cpufreq driver to access these registers via syscon API.
>
> This is needed for a fix of cpufreq driver.
>
> Signed-off-by: Marek Beh?n <kabel at kernel.org>
> Fixes: e8d66e7927b2 ("arm64: dts: marvell: armada-37xx: add nodes...")
> Cc: stable at vger.kernel.org
> Cc: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Cc: Miquel Raynal <miquel.raynal at bootlin.com>

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index d5b6c0a1c54a..a89e47d95eef 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -156,7 +156,8 @@
>  			};
>  
>  			nb_periph_clk: nb-periph-clk at 13000 {
> -				compatible = "marvell,armada-3700-periph-clock-nb";
> +				compatible = "marvell,armada-3700-periph-clock-nb",
> +					     "syscon";
>  				reg = <0x13000 0x100>;
>  				clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
>  				<&tbg 3>, <&xtalclk>;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From nathan at kernel.org  Fri Apr  2 20:58:23 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri, 2 Apr 2021 12:58:23 -0700
Subject: [PATCH v5 00/18] Add support for Clang CFI
In-Reply-To: <20210401233216.2540591-1-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
Message-ID: <20210402195823.huphtlhluqjgrw26@archlinux-ax161>

On Thu, Apr 01, 2021 at 04:31:58PM -0700, Sami Tolvanen wrote:
> This series adds support for Clang's Control-Flow Integrity (CFI)
> checking. With CFI, the compiler injects a runtime check before 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. For more details, see:
> 
>   https://clang.llvm.org/docs/ControlFlowIntegrity.html
> 
> The first patch contains build system changes and error handling,
> and implements support for cross-module indirect call checking. The
> remaining patches address issues caused by the compiler
> instrumentation. These include fixing known type mismatches, as well
> as issues with address space confusion and cross-module function
> address equality.
> 
> These patches add support only for arm64, but I'll post patches also
> for x86_64 after we address the remaining issues there, including
> objtool support.
> 
> You can also pull this series from
> 
>   https://github.com/samitolvanen/linux.git cfi-v5
> 
> ---
> Changes in v5:
>  - Changed module.lds.S to only include <asm/page.h> when CFI is
>    enabled to fix the MIPS build.
>  - Added a patch that fixes dynamic ftrace with CFI on arm64.
> 
> Changes in v4:
>  - Per Mark's suggestion, dropped __pa_function() and renamed
>    __va_function() to function_nocfi().
>  - Added a comment to function_nocfi() to explain what it does.
>  - Updated the psci patch to use an intermediate variable for
>    the physical address for clarity.
> 
> Changes in v3:
>  - Added a patch to change list_sort() callers treewide to use
>    const pointers instead of simply removing the internal casts.
>  - Changed cleanup_symbol_name() to return bool.
>  - Changed module.lds.S to drop the .eh_frame section only with
>    CONFIG_CFI_CLANG.
>  - Switched to synchronize_rcu() in update_shadow().
> 
> Changes in v2:
>  - Fixed .text merging in module.lds.S.
>  - Added WARN_ON_FUNCTION_MISMATCH() and changed kernel/thread.c
>    and kernel/workqueue.c to use the macro instead.
> 
> 
> Sami Tolvanen (18):
>   add support for Clang CFI
>   cfi: add __cficanonical
>   mm: add generic function_nocfi macro
>   module: ensure __cfi_check alignment
>   workqueue: use WARN_ON_FUNCTION_MISMATCH
>   kthread: use WARN_ON_FUNCTION_MISMATCH
>   kallsyms: strip ThinLTO hashes from static functions
>   bpf: disable CFI in dispatcher functions
>   treewide: Change list_sort to use const pointers
>   lkdtm: use function_nocfi
>   psci: use function_nocfi for cpu_resume
>   arm64: implement function_nocfi
>   arm64: use function_nocfi with __pa_symbol
>   arm64: add __nocfi to functions that jump to a physical address
>   arm64: add __nocfi to __apply_alternatives
>   arm64: ftrace: use function_nocfi for ftrace_call
>   KVM: arm64: Disable CFI for nVHE
>   arm64: allow CONFIG_CFI_CLANG to be selected
> 
>  Makefile                                      |  17 +
>  arch/Kconfig                                  |  45 +++
>  arch/arm64/Kconfig                            |   1 +
>  arch/arm64/include/asm/memory.h               |  15 +
>  arch/arm64/include/asm/mmu_context.h          |   4 +-
>  arch/arm64/kernel/acpi_parking_protocol.c     |   3 +-
>  arch/arm64/kernel/alternative.c               |   4 +-
>  arch/arm64/kernel/cpu-reset.h                 |  10 +-
>  arch/arm64/kernel/cpufeature.c                |   4 +-
>  arch/arm64/kernel/ftrace.c                    |   2 +-
>  arch/arm64/kernel/psci.c                      |   3 +-
>  arch/arm64/kernel/smp_spin_table.c            |   3 +-
>  arch/arm64/kvm/hyp/nvhe/Makefile              |   6 +-
>  arch/arm64/kvm/vgic/vgic-its.c                |   8 +-
>  arch/arm64/kvm/vgic/vgic.c                    |   3 +-
>  block/blk-mq-sched.c                          |   3 +-
>  block/blk-mq.c                                |   3 +-
>  drivers/acpi/nfit/core.c                      |   3 +-
>  drivers/acpi/numa/hmat.c                      |   3 +-
>  drivers/clk/keystone/sci-clk.c                |   4 +-
>  drivers/firmware/psci/psci.c                  |   7 +-
>  drivers/gpu/drm/drm_modes.c                   |   3 +-
>  drivers/gpu/drm/i915/gt/intel_engine_user.c   |   3 +-
>  drivers/gpu/drm/i915/gvt/debugfs.c            |   2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   3 +-
>  drivers/gpu/drm/radeon/radeon_cs.c            |   4 +-
>  .../hw/usnic/usnic_uiom_interval_tree.c       |   3 +-
>  drivers/interconnect/qcom/bcm-voter.c         |   2 +-
>  drivers/md/raid5.c                            |   3 +-
>  drivers/misc/lkdtm/usercopy.c                 |   2 +-
>  drivers/misc/sram.c                           |   4 +-
>  drivers/nvme/host/core.c                      |   3 +-
>  .../controller/cadence/pcie-cadence-host.c    |   3 +-
>  drivers/spi/spi-loopback-test.c               |   3 +-
>  fs/btrfs/raid56.c                             |   3 +-
>  fs/btrfs/tree-log.c                           |   3 +-
>  fs/btrfs/volumes.c                            |   3 +-
>  fs/ext4/fsmap.c                               |   4 +-
>  fs/gfs2/glock.c                               |   3 +-
>  fs/gfs2/log.c                                 |   2 +-
>  fs/gfs2/lops.c                                |   3 +-
>  fs/iomap/buffered-io.c                        |   3 +-
>  fs/ubifs/gc.c                                 |   7 +-
>  fs/ubifs/replay.c                             |   4 +-
>  fs/xfs/scrub/bitmap.c                         |   4 +-
>  fs/xfs/xfs_bmap_item.c                        |   4 +-
>  fs/xfs/xfs_buf.c                              |   6 +-
>  fs/xfs/xfs_extent_busy.c                      |   4 +-
>  fs/xfs/xfs_extent_busy.h                      |   3 +-
>  fs/xfs/xfs_extfree_item.c                     |   4 +-
>  fs/xfs/xfs_refcount_item.c                    |   4 +-
>  fs/xfs/xfs_rmap_item.c                        |   4 +-
>  include/asm-generic/bug.h                     |  16 +
>  include/asm-generic/vmlinux.lds.h             |  20 +-
>  include/linux/bpf.h                           |   4 +-
>  include/linux/cfi.h                           |  41 +++
>  include/linux/compiler-clang.h                |   3 +
>  include/linux/compiler_types.h                |   8 +
>  include/linux/init.h                          |   6 +-
>  include/linux/list_sort.h                     |   7 +-
>  include/linux/mm.h                            |  10 +
>  include/linux/module.h                        |  13 +-
>  include/linux/pci.h                           |   4 +-
>  init/Kconfig                                  |   2 +-
>  kernel/Makefile                               |   4 +
>  kernel/cfi.c                                  | 329 ++++++++++++++++++
>  kernel/kallsyms.c                             |  55 ++-
>  kernel/kthread.c                              |   3 +-
>  kernel/module.c                               |  43 +++
>  kernel/workqueue.c                            |   2 +-
>  lib/list_sort.c                               |  17 +-
>  lib/test_list_sort.c                          |   3 +-
>  net/tipc/name_table.c                         |   4 +-
>  scripts/Makefile.modfinal                     |   2 +-
>  scripts/module.lds.S                          |  19 +-
>  75 files changed, 759 insertions(+), 113 deletions(-)
>  create mode 100644 include/linux/cfi.h
>  create mode 100644 kernel/cfi.c
> 
> 
> base-commit: 6905b1dc3c32a094f0da61bd656a740f0a97d592
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


Hi Sami,

I booted this series on Equinix's c1.large.arm (2x Cavium ThunderX
CN8890) and c2.large.arm (1x Ampere eMAG 8180) servers [1] and my
Raspberry Pi 4B. I ran them through LTP's read_all test case on both
/proc and /sys and a few compile workloads, only uncovering one issue [2].

Consider this series:

Tested-by: Nathan Chancellor <nathan at kernel.org>

[1]: https://metal.equinix.com/developers/docs/servers/
[2]: https://lore.kernel.org/r/20210402195241.gahc5w25gezluw7p at archlinux-ax161/

Cheers,
Nathan


From gregory.clement at bootlin.com  Fri Apr  2 21:07:46 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri,  2 Apr 2021 22:07:46 +0200
Subject: [PATCH] Revert "arm64: dts: marvell: armada-cp110: Switch to per-port
 SATA interrupts"
Message-ID: <20210402200746.1254396-1-gregory.clement@bootlin.com>

The driver part of this support was not merged which leads to break
AHCI on all Marvell Armada 7k8k / CN913x platforms as it was reported
by Marcin Wojtas.

So for now let's remove it in order to fix the issue waiting for the
driver part really be merged.

This reverts commit 53e950d597e3578da84238b86424bfcc9e101d87.
Fixes: 53e950d597e3 ("arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts")

Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
---
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
index 64179a372ecf..c6f5df2deccf 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
@@ -310,9 +310,11 @@ CP11X_LABEL(usb3_1): usb at 510000 {
 		};
 
 		CP11X_LABEL(sata0): sata at 540000 {
-			compatible = "marvell,armada-8k-ahci";
+			compatible = "marvell,armada-8k-ahci",
+			"generic-ahci";
 			reg = <0x540000 0x30000>;
 			dma-coherent;
+			interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&CP11X_LABEL(clk) 1 15>,
 				 <&CP11X_LABEL(clk) 1 16>;
 			#address-cells = <1>;
@@ -320,12 +322,10 @@ CP11X_LABEL(sata0): sata at 540000 {
 			status = "disabled";
 
 			sata-port at 0 {
-				interrupts = <109 IRQ_TYPE_LEVEL_HIGH>;
 				reg = <0>;
 			};
 
 			sata-port at 1 {
-				interrupts = <107 IRQ_TYPE_LEVEL_HIGH>;
 				reg = <1>;
 			};
 		};
-- 
2.30.2



From gregory.clement at bootlin.com  Fri Apr  2 21:13:19 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 22:13:19 +0200
Subject: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management
In-Reply-To: <20210217153038.1068170-1-rsalvaterra@gmail.com>
References: <20210217153038.1068170-1-rsalvaterra@gmail.com>
Message-ID: <87h7kocun4.fsf@BL-laptop>

Hi Rui,

> Hardware buffer management has never worked on the Turris Omnia, as the
> required MBus window hadn't been reserved. Fix thusly.
>
> Fixes: 018b88eee1a2 ("ARM: dts: turris-omnia: enable HW buffer management")
>
> Signed-off-by: Rui Salvaterra <rsalvaterra at gmail.com>

Applied on mvebu/fixes

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> index 646a06420c77..dc80a909ea88 100644
> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -32,7 +32,8 @@ soc {
>  		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
>  			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
>  			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
> -			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
> +			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
> +			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
>  
>  		internal-regs {
>  
> -- 
> 2.30.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Apr  2 21:15:57 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 22:15:57 +0200
Subject: [PATCH mvebu-dt] ARM: dts: turris-omnia: configure LED[2]/INTn
 pin as interrupt pin
In-Reply-To: <20210220231144.32325-1-kabel@kernel.org>
References: <20210220231144.32325-1-kabel@kernel.org>
Message-ID: <87eefscuiq.fsf@BL-laptop>

Hi Marek,

> Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
> of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.
>
> Without this the pin is by default in LED[2] mode, and the Marvell PHY
> driver configures LED[2] into "On - Link, Blink - Activity" mode.
>
> This fixes the issue where the pca9538 GPIO/interrupt controller (which
> can't mask interrupts in HW) received too many interrupts and after a
> time started ignoring the interrupt with error message:
>   IRQ 71: nobody cared
>
> There is a work in progress to have the Marvell PHY driver support
> parsing PHY LED nodes from OF and registering the LEDs as Linux LED
> class devices. Once this is done the PHY driver can also automatically
> set the pin into INTn mode if it does not find LED[2] in OF.
>
> Until then, though, we fix this via `marvell,reg-init` DT property.
>
> Signed-off-by: Marek Beh?n <kabel at kernel.org>
> Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
> Cc: <stable at vger.kernel.org>


Applied on mvebu/fixes

Thanks,

Gregory

>
> ---
>
> This patch fixes bug introduced with the commit that added Turris
> Omnia's DTS (26ca8b52d6e1), but will not apply cleanly because there is
> commit 8ee4a5f4f40d which changed node name and node compatible
> property and this commit did not go into stable.
>
> So either commit 8ee4a5f4f40d has also to go into stable before this, or
> this patch has to be fixed a little in order to apply to 4.14+.
>
> Please let me know how should I handle this.
>
> ---
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> index 646a06420c77..b0f3fd8e1429 100644
> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -389,6 +389,7 @@ &mdio {
>  	phy1: ethernet-phy at 1 {
>  		compatible = "ethernet-phy-ieee802.3-c22";
>  		reg = <1>;
> +		marvell,reg-init = <3 18 0 0x4985>;
>  
>  		/* irq is connected to &pcawan pin 7 */
>  	};
> -- 
> 2.26.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Apr  2 21:37:30 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 22:37:30 +0200
Subject: [GIT PULL] ARM: mvebu: fixes for v5.12 (#1)
Message-ID: <87a6qgctit.fsf@BL-laptop>

Hi,

Here is the first pull request for fixes for mvebu for v5.12.

Gregory

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-fixes-5.12-1

for you to fetch changes up to a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086:

  ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin (2021-04-02 22:14:44 +0200)

----------------------------------------------------------------
mvebu fixes for 5.12 (part 1)

2 fixes on on turris-omnia (Armada 38x based:)
 - Fix storm interrupt
 - Enable hardware buffer management as it should be

Unbreak AHCI on all Marvell Armada 7k8k / CN913x platforms

----------------------------------------------------------------
Gregory CLEMENT (1):
      Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts"

Marek Beh?n (1):
      ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

Rui Salvaterra (1):
      ARM: dts: turris-omnia: fix hardware buffer management

 arch/arm/boot/dts/armada-385-turris-omnia.dts | 4 +++-
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 6 +++---
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Apr  2 21:48:18 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 22:48:18 +0200
Subject: [PATCH v3 0/5] Add support for CP110 UTMI PHY
In-Reply-To: <20210307163343.25684-1-kostap@marvell.com>
References: <20210307163343.25684-1-kostap@marvell.com>
Message-ID: <877dlkct0t.fsf@BL-laptop>

Hi Kosta,

> From: Konstantin Porotchkin <kostap at marvell.com>
>
> This series of patches adds a new PHY driver for supporting CP110 UTMI
> PHY in Linux. Currently the functionality of USB ports connected to
> this PHY depends on boot loader setup.
> The new driver eliminates kernel configuration dependency from the boot
> loader. 
>
> v3:
> - rebase on top of Linux 5.12-rc2
> - convert Armada 3700 UTMI PHY DT binding document to YAML schema
> - create a separate DT binding for Armada CP11x UTMI PHY in YAML format
> - change UTMI PHY port node names from "phy" to "usb-phy"
>
> v2:
> - extend the comment about reference clock 
> - fix driver probe function, add some prints
> - move to usage of dr_mode from connected USB controller instead of
>   dedicated device tree property
>
> Konstantin Porotchkin (5):
>   drivers: phy: add support for Armada CP110 UTMI PHY
>   dt-bindings: phy: convert phy-mvebu-utmi to YAML schema
>   devicetree/bindings: add support for CP110 UTMI PHY
>   arch/arm64: dts: add support for Marvell CP110 UTMI PHY
>   arch/arm64: dts: enable CP110 UTMI PHY usage

Patch 4 and 5 applied on mvebu/dt64.

I've just modified the title to align with the other commits in
arch/arm64/boot/dts/marvell. They now begin by "arm64: dts: marvell:".

Thanks,

Gregory


>
>  .../phy/marvell,armada-3700-utmi-phy.yaml     |  57 +++
>  .../phy/marvell,armada-cp110-utmi-phy.yaml    | 109 +++++
>  .../bindings/phy/phy-mvebu-utmi.txt           |  38 --
>  .../arm64/boot/dts/marvell/armada-7040-db.dts |  14 +-
>  .../arm64/boot/dts/marvell/armada-8040-db.dts |  21 +-
>  .../boot/dts/marvell/armada-8040-mcbin.dtsi   |  19 +-
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi |  19 +
>  arch/arm64/boot/dts/marvell/cn9130-db.dts     |  12 +-
>  arch/arm64/boot/dts/marvell/cn9131-db.dts     |   9 +-
>  arch/arm64/boot/dts/marvell/cn9132-db.dts     |  11 +-
>  drivers/phy/marvell/Kconfig                   |   8 +
>  drivers/phy/marvell/Makefile                  |   1 +
>  drivers/phy/marvell/phy-mvebu-cp110-utmi.c    | 384 ++++++++++++++++++
>  13 files changed, 650 insertions(+), 52 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml
>  create mode 100644 Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml
>  delete mode 100644 Documentation/devicetree/bindings/phy/phy-mvebu-utmi.txt
>  create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-utmi.c
>
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From gregory.clement at bootlin.com  Fri Apr  2 22:05:42 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Fri, 02 Apr 2021 23:05:42 +0200
Subject: [GIT PULL] ARM: mvebu: dt64 for v5.13 (#1)
Message-ID: <874kgocs7t.fsf@BL-laptop>

Hi,

Here is the first pull request for dt64 for mvebu for v5.13.

Gregory

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt64-5.13-1

for you to fetch changes up to 99fa8ac5c0f1cf781194dbd04fcd162f4392a9b1:

  arm64: dts: marvell: enable CP110 UTMI PHY usage (2021-04-02 22:43:51 +0200)

----------------------------------------------------------------
mvebu dt64 for 5.13 (part 1)

Add DT for fan control on SolidRun Clearfog GT8k platform

Add syscon compatible to NB clk node allowing improving cpufreq
support on Armada 37xx

Add support for UTMI PHY allowing removing kernel dependency from the
boot loader for UBS port connected to this PHY (Armada 7K, 8K and
CN91xx)

----------------------------------------------------------------
Konstantin Porotchkin (2):
      arm64: dts: marvell: add support for Marvell CP110 UTMI PHY
      arm64: dts: marvell: enable CP110 UTMI PHY usage

Marek Beh?n (1):
      arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node

Russell King (2):
      arm64: dts: marvell: clearfog-gt-8k: add pwm-fan
      arm64: dts: marvell: clearfog-gt-8k: add cooling maps

 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       |   3 +-
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  14 ++-
 .../dts/marvell/armada-8040-clearfog-gt-8k.dts     | 127 +++++++++++++++++++++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts     |  21 +++-
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi |  19 ++-
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi      |  19 +++
 arch/arm64/boot/dts/marvell/cn9130-db.dts          |  12 +-
 arch/arm64/boot/dts/marvell/cn9131-db.dts          |   9 +-
 arch/arm64/boot/dts/marvell/cn9132-db.dts          |  11 +-
 9 files changed, 220 insertions(+), 15 deletions(-)

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From aford173 at gmail.com  Fri Apr  2 23:09:50 2021
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 2 Apr 2021 17:09:50 -0500
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <CABkfQAESbRQsn3fWo4uKeVMMf84LurCLkdgvbPi+A4Kqr87enw@mail.gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
 <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
 <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>
 <20210402175850.6ovyum7ot4pgv2wx@fsr-ub1664-175>
 <CABkfQAESbRQsn3fWo4uKeVMMf84LurCLkdgvbPi+A4Kqr87enw@mail.gmail.com>
Message-ID: <CAHCN7x+cb-Nz9_3aciJLWx=j603RFXgLG92WbBk0MMYwM_mx6g@mail.gmail.com>

On Fri, Apr 2, 2021 at 1:16 PM Adrien Grassein
<adrien.grassein at gmail.com> wrote:
>
> Le ven. 2 avr. 2021 ? 19:58, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> >
> > On 21-04-02 19:48:41, Adrien Grassein wrote:
> > > Hi,
> > >
> > > Le ven. 2 avr. 2021 ? 19:42, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> > > >
> > > > On 21-04-02 18:45:04, Adrien Grassein wrote:
> > > > > Hi,
> > > > >
> > > > > this patch et aims to add the support of the i.MX 8 Power Domain driver.
> > > > > Some devices (like usbotg2) can't work without this patch as their
> > > > > attached power domain are down.
> > > > >
> > > > > The original drivr was taken from le imx kernel and aapted to fit with
> > > > > the actual mainline (minor fixes).
> > > > >
> > > > > Thanks,
> > > > >
> > > >
> > > > Big NACK for the whole series.
> > > >
> > > > This approach has already been rejected upstream.
> > >
> > > So what is the correct approach?
> > > At this point otg2 node of imx8mm is not working at all (and blocks the whole
> > > boot of the kernel)
> > >
> >
> > Have a look at this thread:
> >
> > https://lkml.org/lkml/2020/4/27/706
> >
> Understood, so I will try to update the gpc driver (at least for otg).

Thanks for doing that. I know Lucas tried a few times to get something
going.  I'm willing to adapt whatever work you do on the Mini toward
the Nano if you don't have time.

adam
>
> > > >
> > > > Plus, you changed the original author, this work was originally done by Jacky Bai.
> > >
> > > I have not changed this, the original author is not mentioned on the
> > > original patch.
> >
> > Here is the original commit:
> >
> > https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0
> >
> >
> > >
> > > >
> > > > > Adrien Grassein (2):
> > > > >   dt-bindings: power: Add documentation for imx8m power domain driver
> > > > >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> > > > >
> > > > >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
> > > > >  MAINTAINERS                                   |  10 +
> > > > >  drivers/soc/imx/Kconfig                       |   7 +
> > > > >  drivers/soc/imx/Makefile                      |   1 +
> > > > >  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
> > > > >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> > > > >  include/dt-bindings/power/imx8mn-power.h      |  15 ++
> > > > >  include/dt-bindings/power/imx8mp-power.h      |  28 +++
> > > > >  include/soc/imx/imx_sip.h                     |  12 +
> > > > >  9 files changed, 416 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> > > > >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> > > > >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> > > > >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> > > > >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> > > > >  create mode 100644 include/soc/imx/imx_sip.h
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >
> > >
> > > Thanks,
>
> Thanks,
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From adrien.grassein at gmail.com  Fri Apr  2 23:26:17 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Sat, 3 Apr 2021 00:26:17 +0200
Subject: [PATCH v1 0/2] Add imx8m power domain driver
In-Reply-To: <CAHCN7x+cb-Nz9_3aciJLWx=j603RFXgLG92WbBk0MMYwM_mx6g@mail.gmail.com>
References: <20210402164506.520121-1-adrien.grassein@gmail.com>
 <20210402174228.wjl6paul5hxu7dnx@fsr-ub1664-175>
 <CABkfQAH+Gvu69UeDbxBGyQ1GroYuEqmrYFbkNE-qaLM2zpGRfQ@mail.gmail.com>
 <20210402175850.6ovyum7ot4pgv2wx@fsr-ub1664-175>
 <CABkfQAESbRQsn3fWo4uKeVMMf84LurCLkdgvbPi+A4Kqr87enw@mail.gmail.com>
 <CAHCN7x+cb-Nz9_3aciJLWx=j603RFXgLG92WbBk0MMYwM_mx6g@mail.gmail.com>
Message-ID: <CABkfQAEm=AE_p3YT_Xi+E8haW5eXqPHY-Lh3L--rU8VSeD40SA@mail.gmail.com>

Hi,

Le sam. 3 avr. 2021 ? 00:10, Adam Ford <aford173 at gmail.com> a ?crit :
>
> On Fri, Apr 2, 2021 at 1:16 PM Adrien Grassein
> <adrien.grassein at gmail.com> wrote:
> >
> > Le ven. 2 avr. 2021 ? 19:58, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> > >
> > > On 21-04-02 19:48:41, Adrien Grassein wrote:
> > > > Hi,
> > > >
> > > > Le ven. 2 avr. 2021 ? 19:42, Abel Vesa <abel.vesa at nxp.com> a ?crit :
> > > > >
> > > > > On 21-04-02 18:45:04, Adrien Grassein wrote:
> > > > > > Hi,
> > > > > >
> > > > > > this patch et aims to add the support of the i.MX 8 Power Domain driver.
> > > > > > Some devices (like usbotg2) can't work without this patch as their
> > > > > > attached power domain are down.
> > > > > >
> > > > > > The original drivr was taken from le imx kernel and aapted to fit with
> > > > > > the actual mainline (minor fixes).
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > >
> > > > > Big NACK for the whole series.
> > > > >
> > > > > This approach has already been rejected upstream.
> > > >
> > > > So what is the correct approach?
> > > > At this point otg2 node of imx8mm is not working at all (and blocks the whole
> > > > boot of the kernel)
> > > >
> > >
> > > Have a look at this thread:
> > >
> > > https://lkml.org/lkml/2020/4/27/706
> > >
> > Understood, so I will try to update the gpc driver (at least for otg).
>
> Thanks for doing that. I know Lucas tried a few times to get something
> going.  I'm willing to adapt whatever work you do on the Mini toward
> the Nano if you don't have time.
>

NP, the problem here is that I don't have an Nano to test.

> adam
> >
> > > > >
> > > > > Plus, you changed the original author, this work was originally done by Jacky Bai.
> > > >
> > > > I have not changed this, the original author is not mentioned on the
> > > > original patch.
> > >
> > > Here is the original commit:
> > >
> > > https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0
> > >
> > >
> > > >
> > > > >
> > > > > > Adrien Grassein (2):
> > > > > >   dt-bindings: power: Add documentation for imx8m power domain driver
> > > > > >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> > > > > >
> > > > > >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++++++
> > > > > >  MAINTAINERS                                   |  10 +
> > > > > >  drivers/soc/imx/Kconfig                       |   7 +
> > > > > >  drivers/soc/imx/Makefile                      |   1 +
> > > > > >  drivers/soc/imx/imx8m_pm_domains.c            | 233 ++++++++++++++++++
> > > > > >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> > > > > >  include/dt-bindings/power/imx8mn-power.h      |  15 ++
> > > > > >  include/dt-bindings/power/imx8mp-power.h      |  28 +++
> > > > > >  include/soc/imx/imx_sip.h                     |  12 +
> > > > > >  9 files changed, 416 insertions(+)
> > > > > >  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> > > > > >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> > > > > >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> > > > > >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> > > > > >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> > > > > >  create mode 100644 include/soc/imx/imx_sip.h
> > > > > >
> > > > > > --
> > > > > > 2.25.1
> > > > > >
> > > >
> > > > Thanks,
> >
> > Thanks,
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Thanks,


From konrad.dybcio at somainline.org  Fri Apr  2 23:48:15 2021
From: konrad.dybcio at somainline.org (Konrad Dybcio)
Date: Sat, 3 Apr 2021 00:48:15 +0200
Subject: [PATCH v4 18/18] arm64: apple: Add initial Apple Mac mini (M1,
 2020) devicetree
In-Reply-To: <20210402090542.131194-19-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-19-marcan@marcan.st>
Message-ID: <424e7c1e-aad9-3380-1d08-f0e215c0c144@somainline.org>

Hi,


Looks like you didn't look into my comments on the v3 [1], please check them out.


[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210304213902.83903-28-marcan at marcan.st/#24037817


Konrad



From baolu.lu at linux.intel.com  Sat Apr  3 02:35:23 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Sat, 3 Apr 2021 09:35:23 +0800
Subject: [RFC PATCH 2/5] iommu: Add an unmap_pages() op for IOMMU drivers
In-Reply-To: <b9bbc82b3e405e5bc1d28ed073f6d5b4@codeaurora.org>
References: <20210331030042.13348-1-isaacm@codeaurora.org>
 <20210331030042.13348-3-isaacm@codeaurora.org>
 <e1cadb9e-2ffa-8506-6790-2dab4733af25@linux.intel.com>
 <4c396e68a076f321ed3f406c2c875006@codeaurora.org>
 <3a931043-71bc-88a2-ee57-be9c139e7c9f@linux.intel.com>
 <b9bbc82b3e405e5bc1d28ed073f6d5b4@codeaurora.org>
Message-ID: <fde5cf0e-caed-077b-4d64-eb04ef9b7e07@linux.intel.com>

Hi Isaac,

On 4/3/21 1:25 AM, isaacm at codeaurora.org wrote:
> On 2021-03-30 22:39, Lu Baolu wrote:
>> On 3/31/21 1:36 PM, isaacm at codeaurora.org wrote:
>>> On 2021-03-30 21:47, Lu Baolu wrote:
>>>> On 3/31/21 11:00 AM, Isaac J. Manjarres wrote:
>>>>> Add a callback for IOMMU drivers to provide a path for the
>>>>> IOMMU framework to call into an IOMMU driver, which can call
>>>>> into the io-pgtable code, to unmap a virtually contiguous
>>>>> range of pages of the same size.
>>>>>
>>>>> For IOMMU drivers that do not specify an unmap_pages() callback,
>>>>> the existing logic of unmapping memory one page block at a time
>>>>> will be used.
>>>>>
>>>>> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
>>>>> Suggested-by: Will Deacon <will at kernel.org>
>>>>> ---
>>>>> ? include/linux/iommu.h | 4 ++++
>>>>> ? 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>>>>> index 5e7fe519430a..9cf81242581a 100644
>>>>> --- a/include/linux/iommu.h
>>>>> +++ b/include/linux/iommu.h
>>>>> @@ -193,6 +193,7 @@ struct iommu_iotlb_gather {
>>>>> ?? * @detach_dev: detach device from an iommu domain
>>>>> ?? * @map: map a physically contiguous memory region to an iommu 
>>>>> domain
>>>>> ?? * @unmap: unmap a physically contiguous memory region from an 
>>>>> iommu domain
>>>>> + * @unmap_pages: unmap a number of pages of the same size from an 
>>>>> iommu domain
>>>>> ?? * @flush_iotlb_all: Synchronously flush all hardware TLBs for 
>>>>> this domain
>>>>> ?? * @iotlb_sync_map: Sync mappings created recently using @map to 
>>>>> the hardware
>>>>> ?? * @iotlb_sync: Flush all queued ranges from the hardware TLBs 
>>>>> and empty flush
>>>>> @@ -245,6 +246,9 @@ struct iommu_ops {
>>>>> ???????????? phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
>>>>> ????? size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
>>>>> ?????????????? size_t size, struct iommu_iotlb_gather *iotlb_gather);
>>>>> +??? size_t (*unmap_pages)(struct iommu_domain *domain, unsigned 
>>>>> long iova,
>>>>> +????????????????? size_t pgsize, size_t pgcount,
>>>>> +????????????????? struct iommu_iotlb_gather *iotlb_gather);
>>>>
>>>> Is it possible to add an equivalent map_pages() callback?
>>> Yes, map_pages() can be implemented and can leverage a lot of the 
>>> implementation
>>> of unmap_pages(). The problem is that if you map several pages in one 
>>> call, and then
>>> encounter an error and have to rollback, you should do TLB 
>>> maintenance, as iommu_map
>>> does when it encounters an error. However, we can't call iommu_unmap 
>>> from io-pgtable-arm
>>> for example. We can call arm_lpae_unmap_pages() from the later 
>>> patches, but that doesn't
>>> solve the TLB maintenance issue. Do you have any thoughts on how to 
>>> address this?
>>
>> Call unmap_pages() with the same pages and size to roll back. Does it
>> work?
>>
>> Best regards,
>> baolu
> Hi Lu,
> 
> I've given map_pages() a shot. Here's the second version of the RFC 
> series: 
> https://lore.kernel.org/linux-iommu/20210402013452.4013-1-isaacm at codeaurora.org/T/#t. 

Thanks for doing that. I will look into it and try it with a VT-d
implementation.

Best regards,
baolu


From chunkuang.hu at kernel.org  Sat Apr  3 03:42:48 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 3 Apr 2021 10:42:48 +0800
Subject: [PATCH 0/3] Refine mtk-cmdq-mailbox callback mechanism
In-Reply-To: <20210314233323.23377-1-chunkuang.hu@kernel.org>
References: <20210314233323.23377-1-chunkuang.hu@kernel.org>
Message-ID: <CAAOTY__SvoLJ7aPhuiNLXBd_JhbuzF=bTABG-MHc7bvHuQJi0w@mail.gmail.com>

Hi, Jassi:

Chun-Kuang Hu <chunkuang.hu at kernel.org> ? 2021?3?15? ?? ??7:33???
>
> mtk-cmdq-mailbox use proprietary callback mechanism and proprietary
> error number, but these could be replaced by standard callback
> mechanism and standard error number. In addition, use cmdq_pkt as
> callback data to prevent redundnat assignment.
>
> Because client driver still use proprietary mechanism, so keep
> proprietary mechanism until client driver use the standard one.

How do you think about this series?

Regards,
Chun-Kuang.

>
> Chun-Kuang Hu (3):
>   mailbox: mtk-cmdq: Remove cmdq_cb_status
>   mailbox: mtk-cmdq: Use mailbox rx_callback
>   mailbox: mtk-cmdq: Add struct cmdq_pkt in struct cmdq_cb_data
>
>  drivers/mailbox/mtk-cmdq-mailbox.c       | 24 +++++++++++++++---------
>  include/linux/mailbox/mtk-cmdq-mailbox.h |  8 ++------
>  2 files changed, 17 insertions(+), 15 deletions(-)
>
> --
> 2.17.1
>


From leo.yan at linaro.org  Sat Apr  3 08:23:39 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:39 +0800
Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
Message-ID: <20210403072346.30430-1-leo.yan@linaro.org>

As we know, the timestamp is important for AUX trace; it's mainly used
to correlate between perf events and AUX trace, allows to generate
events with time ordered manner.  There have several good examples of
enabling timestamp for AUX trace (like Intel-pt, Intel-bts, etc).

Since the conversion between TSC and kernel timestamp has been supported
on Arm64, TSC is a naming convention from x86, but perf now has reused
it to support Arm arch timer counter.

This patch set is to enable timestamp for Arm SPE trace.  It reads out
TSC parameters from mmap page and stores into auxtrace info structure;
the TSC parameters are used for conversion between timer counter and
kernel time and which is applied for Arm SPE samples.

This patch set can be clearly applied on perf/core branch with:

  commit 6859bc0e78c6 ("perf stat: Improve readability of shadow stats")

Ths patch series has been tested on Hisilicon D06 platform.

After:

  # perf script -F comm,time,cpu,pid,dso,ip,sym

              perf  2408 [032]   168.680297:  ffffbd1253690a3c perf_event_exec ([kernel.kallsyms])
              perf  2408 [032]   168.680297:  ffffbd1253690a3c perf_event_exec ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680317:  ffffbd1253683f50 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680317:  ffffbd1253683f50 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680319:  ffffbd1253683f70 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680319:  ffffbd1253683f70 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680367:  ffffbd12539b03ec __arch_clear_user ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440 kmem_cache_alloc ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440 kmem_cache_alloc ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440 kmem_cache_alloc ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440 kmem_cache_alloc ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
   false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70 perf_iterate_ctx.constprop.0 ([kernel.kallsyms])

Changes from v1:
* Rebased patch series on the latest perf/core branch;
* Fixed the patch for dumping TSC parameters to support both the
  older and new auxtrace info format.


Leo Yan (7):
  perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
  perf arm-spe: Store TSC parameters in auxtrace info
  perf arm-spe: Dump TSC parameters
  perf arm-spe: Convert event kernel time to counter value
  perf arm-spe: Assign kernel time to synthesized event
  perf arm-spe: Bail out if the trace is later than perf event
  perf arm-spe: Don't wait for PERF_RECORD_EXIT event

 tools/perf/arch/arm64/util/arm-spe.c | 23 +++++++
 tools/perf/util/arm-spe.c            | 89 +++++++++++++++++++++++-----
 tools/perf/util/arm-spe.h            |  7 ++-
 3 files changed, 103 insertions(+), 16 deletions(-)

-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:40 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:40 +0800
Subject: [PATCH v2 1/7] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-2-leo.yan@linaro.org>

The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
index 98d3235781c3..105ce0ea0a01 100644
--- a/tools/perf/util/arm-spe.h
+++ b/tools/perf/util/arm-spe.h
@@ -11,7 +11,6 @@
 
 enum {
 	ARM_SPE_PMU_TYPE,
-	ARM_SPE_PER_CPU_MMAPS,
 	ARM_SPE_AUXTRACE_PRIV_MAX,
 };
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:41 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:41 +0800
Subject: [PATCH v2 2/7] perf arm-spe: Store TSC parameters in auxtrace info
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-3-leo.yan@linaro.org>

The TSC parameters are used for conversion between arch timer counter
and kernel timestamp, this patch stores the parameters into the struct
perf_record_auxtrace_info, and it is saved in perf data file.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/arch/arm64/util/arm-spe.c | 23 +++++++++++++++++++++++
 tools/perf/util/arm-spe.h            |  6 ++++++
 2 files changed, 29 insertions(+)

diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 414c8a5584b1..dd940cf16f49 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -15,7 +15,9 @@
 #include "../../../util/event.h"
 #include "../../../util/evsel.h"
 #include "../../../util/evlist.h"
+#include "../../../util/mmap.h"
 #include "../../../util/session.h"
+#include "../../../util/tsc.h"
 #include <internal/lib.h> // page_size
 #include "../../../util/pmu.h"
 #include "../../../util/debug.h"
@@ -47,6 +49,9 @@ static int arm_spe_info_fill(struct auxtrace_record *itr,
 	struct arm_spe_recording *sper =
 			container_of(itr, struct arm_spe_recording, itr);
 	struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
+	struct perf_event_mmap_page *pc;
+	struct perf_tsc_conversion tc = { .time_mult = 0, };
+	int err;
 
 	if (priv_size != ARM_SPE_AUXTRACE_PRIV_SIZE)
 		return -EINVAL;
@@ -54,8 +59,26 @@ static int arm_spe_info_fill(struct auxtrace_record *itr,
 	if (!session->evlist->core.nr_mmaps)
 		return -EINVAL;
 
+	pc = session->evlist->mmap[0].core.base;
+	if (pc) {
+		err = perf_read_tsc_conversion(pc, &tc);
+		if (err) {
+			if (err != -EOPNOTSUPP)
+				return err;
+		}
+
+		if (!tc.time_mult)
+			ui__warning("Arm SPE: arch timer not available\n");
+	}
+
 	auxtrace_info->type = PERF_AUXTRACE_ARM_SPE;
 	auxtrace_info->priv[ARM_SPE_PMU_TYPE] = arm_spe_pmu->type;
+	auxtrace_info->priv[ARM_SPE_TIME_SHIFT] = tc.time_shift;
+	auxtrace_info->priv[ARM_SPE_TIME_MULT] = tc.time_mult;
+	auxtrace_info->priv[ARM_SPE_TIME_ZERO] = tc.time_zero;
+	auxtrace_info->priv[ARM_SPE_TIME_CYCLES] = tc.time_cycles;
+	auxtrace_info->priv[ARM_SPE_TIME_MASK] = tc.time_mask;
+	auxtrace_info->priv[ARM_SPE_CAP_USER_TIME_SHORT] = tc.cap_user_time_short;
 
 	return 0;
 }
diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
index 105ce0ea0a01..5bf3e838d226 100644
--- a/tools/perf/util/arm-spe.h
+++ b/tools/perf/util/arm-spe.h
@@ -11,6 +11,12 @@
 
 enum {
 	ARM_SPE_PMU_TYPE,
+	ARM_SPE_TIME_SHIFT,
+	ARM_SPE_TIME_MULT,
+	ARM_SPE_TIME_ZERO,
+	ARM_SPE_TIME_CYCLES,
+	ARM_SPE_TIME_MASK,
+	ARM_SPE_CAP_USER_TIME_SHORT,
 	ARM_SPE_AUXTRACE_PRIV_MAX,
 };
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:42 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:42 +0800
Subject: [PATCH v2 3/7] perf arm-spe: Dump TSC parameters
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-4-leo.yan@linaro.org>

The TSC parameters are stored in auxtrace info, this patch dumps these
parameters for reporting the raw data.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 42 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 2539d4baec44..69ce3483d1af 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -26,6 +26,7 @@
 #include "symbol.h"
 #include "thread.h"
 #include "thread-stack.h"
+#include "tsc.h"
 #include "tool.h"
 #include "util/synthetic-events.h"
 
@@ -45,6 +46,8 @@ struct arm_spe {
 	struct machine			*machine;
 	u32				pmu_type;
 
+	struct perf_tsc_conversion	tc;
+
 	u8				timeless_decoding;
 	u8				data_queued;
 
@@ -803,14 +806,23 @@ static bool arm_spe_evsel_is_auxtrace(struct perf_session *session,
 
 static const char * const arm_spe_info_fmts[] = {
 	[ARM_SPE_PMU_TYPE]		= "  PMU Type           %"PRId64"\n",
+	[ARM_SPE_TIME_SHIFT]		= "  Time Shift         %"PRIu64"\n",
+	[ARM_SPE_TIME_MULT]		= "  Time Muliplier     %"PRIu64"\n",
+	[ARM_SPE_TIME_ZERO]		= "  Time Zero          %"PRIu64"\n",
+	[ARM_SPE_TIME_CYCLES]		= "  Time Cycles        %"PRIu64"\n",
+	[ARM_SPE_TIME_MASK]		= "  Time Mask          %#"PRIx64"\n",
+	[ARM_SPE_CAP_USER_TIME_SHORT]	= "  Cap Time Short     %"PRId64"\n",
 };
 
-static void arm_spe_print_info(__u64 *arr)
+static void arm_spe_print_info(__u64 *arr, int start, int finish)
 {
+	int i;
+
 	if (!dump_trace)
 		return;
 
-	fprintf(stdout, arm_spe_info_fmts[ARM_SPE_PMU_TYPE], arr[ARM_SPE_PMU_TYPE]);
+	for (i = start; i <= finish; i++)
+		fprintf(stdout, arm_spe_info_fmts[i], arr[i]);
 }
 
 struct arm_spe_synth {
@@ -1001,11 +1013,19 @@ arm_spe_synth_events(struct arm_spe *spe, struct perf_session *session)
 	return 0;
 }
 
+static bool arm_spe_has(struct perf_record_auxtrace_info *auxtrace_info,
+			int pos)
+{
+	return auxtrace_info->header.size >=
+		(sizeof(struct perf_record_auxtrace_info) +
+		 (sizeof(u64) * (pos + 1)));
+}
+
 int arm_spe_process_auxtrace_info(union perf_event *event,
 				  struct perf_session *session)
 {
 	struct perf_record_auxtrace_info *auxtrace_info = &event->auxtrace_info;
-	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
+	size_t min_sz = sizeof(u64) * ARM_SPE_TIME_SHIFT;
 	struct arm_spe *spe;
 	int err;
 
@@ -1025,6 +1045,20 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
 	spe->machine = &session->machines.host; /* No kvm support */
 	spe->auxtrace_type = auxtrace_info->type;
 	spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
+	arm_spe_print_info(&auxtrace_info->priv[0], ARM_SPE_PMU_TYPE,
+			   ARM_SPE_PMU_TYPE);
+
+	if (arm_spe_has(auxtrace_info, ARM_SPE_CAP_USER_TIME_SHORT)) {
+		spe->tc.time_shift = auxtrace_info->priv[ARM_SPE_TIME_SHIFT];
+		spe->tc.time_mult = auxtrace_info->priv[ARM_SPE_TIME_MULT];
+		spe->tc.time_zero = auxtrace_info->priv[ARM_SPE_TIME_ZERO];
+		spe->tc.time_cycles = auxtrace_info->priv[ARM_SPE_TIME_CYCLES];
+		spe->tc.time_mask = auxtrace_info->priv[ARM_SPE_TIME_MASK];
+		spe->tc.cap_user_time_short =
+			auxtrace_info->priv[ARM_SPE_CAP_USER_TIME_SHORT];
+		arm_spe_print_info(&auxtrace_info->priv[0], ARM_SPE_TIME_SHIFT,
+				   ARM_SPE_CAP_USER_TIME_SHORT);
+	}
 
 	spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
 	spe->auxtrace.process_event = arm_spe_process_event;
@@ -1035,8 +1069,6 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
 	spe->auxtrace.evsel_is_auxtrace = arm_spe_evsel_is_auxtrace;
 	session->auxtrace = &spe->auxtrace;
 
-	arm_spe_print_info(&auxtrace_info->priv[0]);
-
 	if (dump_trace)
 		return 0;
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:43 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:43 +0800
Subject: [PATCH v2 4/7] perf arm-spe: Convert event kernel time to counter
 value
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-5-leo.yan@linaro.org>

When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.

This patch converts the event kernel time to arch timer's counter value,
thus it can be used to compare with counter value contained in Arm SPE
Timestamp packet.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 69ce3483d1af..4cf558b0218a 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -669,7 +669,7 @@ static int arm_spe_process_event(struct perf_session *session,
 	}
 
 	if (sample->time && (sample->time != (u64) -1))
-		timestamp = sample->time;
+		timestamp = perf_time_to_tsc(sample->time, &spe->tc);
 	else
 		timestamp = 0;
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:44 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:44 +0800
Subject: [PATCH v2 5/7] perf arm-spe: Assign kernel time to synthesized event
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-6-leo.yan@linaro.org>

In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.

To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 4cf558b0218a..80f5659e7f7e 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
 	struct arm_spe_record *record = &speq->decoder->record;
 
 	if (!spe->timeless_decoding)
-		sample->time = speq->timestamp;
+		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
 
 	sample->ip = record->from_ip;
 	sample->cpumode = arm_spe_cpumode(spe, sample->ip);
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:45 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:45 +0800
Subject: [PATCH v2 6/7] perf arm-spe: Bail out if the trace is later than perf
 event
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-7-leo.yan@linaro.org>

It's possible that record in Arm SPE trace is later than perf event and
vice versa.  This asks to correlate the perf events and Arm SPE
synthesized events to be processed in the manner of correct timing.

To achieve the time ordering, this patch reverses the flow, it firstly
calls arm_spe_sample() and then calls arm_spe_decode().  By comparing
the timestamp value and detect the perf event is coming earlier than Arm
SPE trace data, it bails out from the decoding loop, the last record is
pushed into auxtrace stack and is deferred to generate sample.  To track
the timestamp, everytime it updates timestamp for the latest record.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 80f5659e7f7e..99a394c366e0 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -434,12 +434,36 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
 static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 {
 	struct arm_spe *spe = speq->spe;
+	struct arm_spe_record *record;
 	int ret;
 
 	if (!spe->kernel_start)
 		spe->kernel_start = machine__kernel_start(spe->machine);
 
 	while (1) {
+		/*
+		 * The usual logic is firstly to decode the packets, and then
+		 * based the record to synthesize sample; but here the flow is
+		 * reversed: it calls arm_spe_sample() for synthesizing samples
+		 * prior to arm_spe_decode().
+		 *
+		 * Two reasons for this code logic:
+		 * 1. Firstly, when setup queue in arm_spe__setup_queue(), it
+		 * has decoded trace data and generated a record, but the record
+		 * is left to generate sample until run to here, so it's correct
+		 * to synthesize sample for the left record.
+		 * 2. After decoding trace data, it needs to compare the record
+		 * timestamp with the coming perf event, if the record timestamp
+		 * is later than the perf event, it needs bail out and pushs the
+		 * record into auxtrace heap, thus the record can be deferred to
+		 * synthesize sample until run to here at the next time; so this
+		 * can correlate samples between Arm SPE trace data and other
+		 * perf events with correct time ordering.
+		 */
+		ret = arm_spe_sample(speq);
+		if (ret)
+			return ret;
+
 		ret = arm_spe_decode(speq->decoder);
 		if (!ret) {
 			pr_debug("No data or all data has been processed.\n");
@@ -453,10 +477,17 @@ static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 		if (ret < 0)
 			continue;
 
-		ret = arm_spe_sample(speq);
-		if (ret)
-			return ret;
+		record = &speq->decoder->record;
 
+		/* Update timestamp for the last record */
+		if (record->timestamp > speq->timestamp)
+			speq->timestamp = record->timestamp;
+
+		/*
+		 * If the timestamp of the queue is later than timestamp of the
+		 * coming perf event, bail out so can allow the perf event to
+		 * be processed ahead.
+		 */
 		if (!spe->timeless_decoding && speq->timestamp >= *timestamp) {
 			*timestamp = speq->timestamp;
 			return 0;
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr  3 08:23:46 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat,  3 Apr 2021 15:23:46 +0800
Subject: [PATCH v2 7/7] perf arm-spe: Don't wait for PERF_RECORD_EXIT event
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <20210403072346.30430-8-leo.yan@linaro.org>

When decode Arm SPE trace, it waits for PERF_RECORD_EXIT event (the last
perf event) for processing trace data, which is needless and even might
cause logic error, e.g. it might fail to correlate perf events with Arm
SPE events correctly.

So this patch removes the condition checking for PERF_RECORD_EXIT event.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 99a394c366e0..17dcad99912a 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -717,11 +717,7 @@ static int arm_spe_process_event(struct perf_session *session,
 					sample->time);
 		}
 	} else if (timestamp) {
-		if (event->header.type == PERF_RECORD_EXIT) {
-			err = arm_spe_process_queues(spe, timestamp);
-			if (err)
-				return err;
-		}
+		err = arm_spe_process_queues(spe, timestamp);
 	}
 
 	return err;
-- 
2.25.1



From syzbot+be81a058b10931003a4a at syzkaller.appspotmail.com  Sat Apr  3 09:12:26 2021
From: syzbot+be81a058b10931003a4a at syzkaller.appspotmail.com (syzbot)
Date: Sat, 03 Apr 2021 01:12:26 -0700
Subject: [syzbot] WARNING: suspicious RCU usage in __schedule
Message-ID: <00000000000066b6f405bf0d0660@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1432bd1ad00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=78a83786814e7724
dashboard link: https://syzkaller.appspot.com/bug?extid=be81a058b10931003a4a
userspace arch: arm

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+be81a058b10931003a4a at syzkaller.appspotmail.com

=============================
WARNING: suspicious RCU usage
5.12.0-rc5-syzkaller-00003-g1e43c377a79f #0 Not tainted
-----------------------------
kernel/sched/core.c:4841 Illegal context switch in RCU-sched read-side critical section!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 0
no locks held by migration/1/17.

stack backtrace:
CPU: 1 PID: 17 Comm: migration/1 Not tainted 5.12.0-rc5-syzkaller-00003-g1e43c377a79f #0
Hardware name: linux,dummy-virt (DT)
Stopper: 0x0 <- 0x0
Call trace:
 dump_backtrace+0x0/0x3e0 arch/arm64/include/asm/pointer_auth.h:76
 show_stack+0x18/0x24 arch/arm64/kernel/stacktrace.c:191
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x120/0x1a8 lib/dump_stack.c:120
 lockdep_rcu_suspicious+0x130/0x148 kernel/locking/lockdep.c:6428
 schedule_debug kernel/sched/core.c:4841 [inline]
 __schedule+0x1244/0x1bc4 kernel/sched/core.c:4967
 schedule+0xac/0x22c kernel/sched/core.c:5152
 smpboot_thread_fn+0x278/0x7f4 kernel/smpboot.c:161
 kthread+0x320/0x3bc kernel/kthread.c:292
 ret_from_fork+0x10/0x3c arch/arm64/kernel/entry.S:958


---
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.


From arnd at arndb.de  Sat Apr  3 12:00:00 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Sat, 3 Apr 2021 13:00:00 +0200
Subject: [PATCH RESEND 1/5] ARM: dts: clps711x: Add SYSCON nodes where it
 is used
In-Reply-To: <20210402074318.8582-1-shc_work@mail.ru>
References: <20210402074318.8582-1-shc_work@mail.ru>
Message-ID: <CAK8P3a2kkRX1YpU4LPsxezYQWZBOPB8vxGr-03y78m3u=9OnjA@mail.gmail.com>

On Fri, Apr 2, 2021 at 9:43 AM Alexander Shiyan <shc_work at mail.ru> wrote:
>
> This patch adds SYSCON descriptors to framebuffer, SPI, DAI
> and modem control GPIO nodes to further rework these drivers
> to remove the call to the syscon_regmap_lookup_by_compatible() function.
>
> Signed-off-by: Alexander Shiyan <shc_work at mail.ru>
> ---
>  arch/arm/boot/dts/ep7209.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)

The patches all look good. Can you resend them to soc at kernel.org
to make them end up in patchwork for me to pick them up into the soc tree?

Thanks,

        Arnd


From maz at kernel.org  Sat Apr  3 12:29:24 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:24 +0100
Subject: [PATCH v2 2/9] KVM: arm64: Handle physical FIQ as an IRQ while
 running a guest
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-3-maz@kernel.org>

As we we now entertain the possibility of FIQ being used on the host,
treat the signalling of a FIQ while running a guest as an IRQ,
causing an exit instead of a HYP panic.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/hyp/hyp-entry.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 5f49df4ffdd8..9aa9b73475c9 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -76,6 +76,7 @@ el1_trap:
 	b	__guest_exit
 
 el1_irq:
+el1_fiq:
 	get_vcpu_ptr	x1, x0
 	mov	x0, #ARM_EXCEPTION_IRQ
 	b	__guest_exit
@@ -131,7 +132,6 @@ SYM_CODE_END(\label)
 	invalid_vector	el2t_error_invalid
 	invalid_vector	el2h_irq_invalid
 	invalid_vector	el2h_fiq_invalid
-	invalid_vector	el1_fiq_invalid
 
 	.ltorg
 
@@ -179,12 +179,12 @@ SYM_CODE_START(__kvm_hyp_vector)
 
 	valid_vect	el1_sync		// Synchronous 64-bit EL1
 	valid_vect	el1_irq			// IRQ 64-bit EL1
-	invalid_vect	el1_fiq_invalid		// FIQ 64-bit EL1
+	valid_vect	el1_fiq			// FIQ 64-bit EL1
 	valid_vect	el1_error		// Error 64-bit EL1
 
 	valid_vect	el1_sync		// Synchronous 32-bit EL1
 	valid_vect	el1_irq			// IRQ 32-bit EL1
-	invalid_vect	el1_fiq_invalid		// FIQ 32-bit EL1
+	valid_vect	el1_fiq			// FIQ 32-bit EL1
 	valid_vect	el1_error		// Error 32-bit EL1
 SYM_CODE_END(__kvm_hyp_vector)
 
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:22 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:22 +0100
Subject: [PATCH v2 0/9] KVM: arm64: Initial host support for the Apple M1
Message-ID: <20210403112931.1043452-1-maz@kernel.org>

This is a new version of the series initially posted at [1], reworking
the vGIC and timer code to cope with the M1 braindead^Wamusing nature.

Not much has changed, except for the missing irq_ack callback when
taking a timer interrupt, which would leave a screaming interrupt.

Tested with multiple concurrent VMs running from an initramfs.

* From v1 [1]:
  - Rebased on Hector's v4 posting[0]
  - Dropped a couple of patches that have been merged in the above series
  - Fixed irq_ack callback on the timer path

[0] https://lore.kernel.org/r/20210402090542.131194-1-marcan at marcan.st
[1] https://lore.kernel.org/r/20210316174617.173033-1-maz at kernel.org

Marc Zyngier (9):
  irqchip/gic: Split vGIC probing information from the GIC code
  KVM: arm64: Handle physical FIQ as an IRQ while running a guest
  KVM: arm64: vgic: Be tolerant to the lack of maintenance interrupt
  KVM: arm64: vgic: Let an interrupt controller advertise lack of HW
    deactivation
  KVM: arm64: vgic: move irq->get_input_level into an ops structure
  KVM: arm64: vgic: Implement SW-driven deactivation
  KVM: arm64: timer: Refactor IRQ configuration
  KVM: arm64: timer: Add support for SW-based deactivation
  irqchip/apple-aic: Advertise some level of vGICv3 compatibility

 arch/arm64/kvm/arch_timer.c            | 161 +++++++++++++++++++++----
 arch/arm64/kvm/hyp/hyp-entry.S         |   6 +-
 arch/arm64/kvm/vgic/vgic-init.c        |  33 ++++-
 arch/arm64/kvm/vgic/vgic-v2.c          |  19 ++-
 arch/arm64/kvm/vgic/vgic-v3.c          |  19 ++-
 arch/arm64/kvm/vgic/vgic.c             |  14 +--
 drivers/irqchip/irq-apple-aic.c        |   8 ++
 drivers/irqchip/irq-gic-common.c       |  13 --
 drivers/irqchip/irq-gic-common.h       |   2 -
 drivers/irqchip/irq-gic-v3.c           |   6 +-
 drivers/irqchip/irq-gic.c              |   6 +-
 include/kvm/arm_vgic.h                 |  41 +++++--
 include/linux/irqchip/arm-gic-common.h |  25 +---
 include/linux/irqchip/arm-vgic-info.h  |  43 +++++++
 14 files changed, 290 insertions(+), 106 deletions(-)
 create mode 100644 include/linux/irqchip/arm-vgic-info.h

-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:25 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:25 +0100
Subject: [PATCH v2 3/9] KVM: arm64: vgic: Be tolerant to the lack of
 maintenance interrupt
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-4-maz@kernel.org>

As it turns out, not all the interrupt controllers are able to
expose a vGIC maintenance interrupt as a distrete signal.
And to be fair, it doesn't really matter as all we require is
for *something* to kick us out of guest mode out way or another.

On systems that do not expose a maintenance interrupt as such,
there are two outcomes:

- either the virtual CPUIF does generate an interrupt, and
  by the time we are back to the host the interrupt will have long
  been disabled (as we set ICH_HCR_EL2.EN to 0 on exit). In this case,
  interrupt latency is as good as it gets.

- or some other event (physical timer) will take us out of the guest
  anyway, and the only drawback is a bad interrupt latency.

So let's be tolerant to the lack of maintenance interrupt, and just let
the user know that their mileage may vary...

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 9b491263f5f7..00c75495fd0c 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -521,11 +521,6 @@ int kvm_vgic_hyp_init(void)
 	if (!gic_kvm_info)
 		return -ENODEV;
 
-	if (!gic_kvm_info->maint_irq) {
-		kvm_err("No vgic maintenance irq\n");
-		return -ENXIO;
-	}
-
 	switch (gic_kvm_info->type) {
 	case GIC_V2:
 		ret = vgic_v2_probe(gic_kvm_info);
@@ -549,6 +544,11 @@ int kvm_vgic_hyp_init(void)
 	if (ret)
 		return ret;
 
+	if (!kvm_vgic_global_state.maint_irq) {
+		kvm_err("No maintenance interrupt available, fingers crossed...\n");
+		return 0;
+	}
+
 	ret = request_percpu_irq(kvm_vgic_global_state.maint_irq,
 				 vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:23 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:23 +0100
Subject: [PATCH v2 1/9] irqchip/gic: Split vGIC probing information from the
 GIC code
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-2-maz@kernel.org>

The vGIC advertising code is unsurprisingly very much tied to
the GIC implementations. However, we are about to extend the
support to lesser implementations.

Let's dissociate the vgic registration from the GIC code and
move it into KVM, where it makes a bit more sense. This also
allows us to mark the gic_kvm_info structures as __initdata.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c        | 17 +++++++++--
 drivers/irqchip/irq-gic-common.c       | 13 --------
 drivers/irqchip/irq-gic-common.h       |  2 --
 drivers/irqchip/irq-gic-v3.c           |  6 ++--
 drivers/irqchip/irq-gic.c              |  6 ++--
 include/linux/irqchip/arm-gic-common.h | 25 +---------------
 include/linux/irqchip/arm-vgic-info.h  | 41 ++++++++++++++++++++++++++
 7 files changed, 62 insertions(+), 48 deletions(-)
 create mode 100644 include/linux/irqchip/arm-vgic-info.h

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 052917deb149..9b491263f5f7 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -480,6 +480,15 @@ static irqreturn_t vgic_maintenance_handler(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
+static struct gic_kvm_info *gic_kvm_info;
+
+void __init vgic_set_kvm_info(const struct gic_kvm_info *info)
+{
+	BUG_ON(gic_kvm_info != NULL);
+	gic_kvm_info = kmalloc(sizeof(*info), GFP_KERNEL);
+	*gic_kvm_info = *info;
+}
+
 /**
  * kvm_vgic_init_cpu_hardware - initialize the GIC VE hardware
  *
@@ -507,10 +516,8 @@ void kvm_vgic_init_cpu_hardware(void)
  */
 int kvm_vgic_hyp_init(void)
 {
-	const struct gic_kvm_info *gic_kvm_info;
 	int ret;
 
-	gic_kvm_info = gic_get_kvm_info();
 	if (!gic_kvm_info)
 		return -ENODEV;
 
@@ -534,10 +541,14 @@ int kvm_vgic_hyp_init(void)
 		ret = -ENODEV;
 	}
 
+	kvm_vgic_global_state.maint_irq = gic_kvm_info->maint_irq;
+
+	kfree(gic_kvm_info);
+	gic_kvm_info = NULL;
+
 	if (ret)
 		return ret;
 
-	kvm_vgic_global_state.maint_irq = gic_kvm_info->maint_irq;
 	ret = request_percpu_irq(kvm_vgic_global_state.maint_irq,
 				 vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());
diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index f47b41dfd023..a610821c8ff2 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -12,19 +12,6 @@
 
 static DEFINE_RAW_SPINLOCK(irq_controller_lock);
 
-static const struct gic_kvm_info *gic_kvm_info;
-
-const struct gic_kvm_info *gic_get_kvm_info(void)
-{
-	return gic_kvm_info;
-}
-
-void gic_set_kvm_info(const struct gic_kvm_info *info)
-{
-	BUG_ON(gic_kvm_info != NULL);
-	gic_kvm_info = info;
-}
-
 void gic_enable_of_quirks(const struct device_node *np,
 			  const struct gic_quirk *quirks, void *data)
 {
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index ccba8b0fe0f5..27e3d4ed4f32 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -28,6 +28,4 @@ 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);
 
-void gic_set_kvm_info(const struct gic_kvm_info *info);
-
 #endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index eb0ee356a629..3bd0f25a342f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -103,7 +103,7 @@ EXPORT_SYMBOL(gic_nonsecure_priorities);
 /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
 static refcount_t *ppi_nmi_refs;
 
-static struct gic_kvm_info gic_v3_kvm_info;
+static struct gic_kvm_info gic_v3_kvm_info __initdata;
 static DEFINE_PER_CPU(bool, has_rss);
 
 #define MPIDR_RS(mpidr)			(((mpidr) & 0xF0UL) >> 4)
@@ -1852,7 +1852,7 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
 
 	gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
 	gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
-	gic_set_kvm_info(&gic_v3_kvm_info);
+	vgic_set_kvm_info(&gic_v3_kvm_info);
 }
 
 static int __init gic_of_init(struct device_node *node, struct device_node *parent)
@@ -2168,7 +2168,7 @@ static void __init gic_acpi_setup_kvm_info(void)
 
 	gic_v3_kvm_info.has_v4 = gic_data.rdists.has_vlpis;
 	gic_v3_kvm_info.has_v4_1 = gic_data.rdists.has_rvpeid;
-	gic_set_kvm_info(&gic_v3_kvm_info);
+	vgic_set_kvm_info(&gic_v3_kvm_info);
 }
 
 static int __init
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index b1d9c22caf2e..2de9ec8ece0c 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -119,7 +119,7 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
 
 static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
 
-static struct gic_kvm_info gic_v2_kvm_info;
+static struct gic_kvm_info gic_v2_kvm_info __initdata;
 
 static DEFINE_PER_CPU(u32, sgi_intid);
 
@@ -1451,7 +1451,7 @@ static void __init gic_of_setup_kvm_info(struct device_node *node)
 		return;
 
 	if (static_branch_likely(&supports_deactivate_key))
-		gic_set_kvm_info(&gic_v2_kvm_info);
+		vgic_set_kvm_info(&gic_v2_kvm_info);
 }
 
 int __init
@@ -1618,7 +1618,7 @@ static void __init gic_acpi_setup_kvm_info(void)
 
 	gic_v2_kvm_info.maint_irq = irq;
 
-	gic_set_kvm_info(&gic_v2_kvm_info);
+	vgic_set_kvm_info(&gic_v2_kvm_info);
 }
 
 static int __init gic_v2_acpi_init(union acpi_subtable_headers *header,
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
index fa8c0455c352..1177f3a1aed5 100644
--- a/include/linux/irqchip/arm-gic-common.h
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -7,8 +7,7 @@
 #ifndef __LINUX_IRQCHIP_ARM_GIC_COMMON_H
 #define __LINUX_IRQCHIP_ARM_GIC_COMMON_H
 
-#include <linux/types.h>
-#include <linux/ioport.h>
+#include <linux/irqchip/arm-vgic-info.h>
 
 #define GICD_INT_DEF_PRI		0xa0
 #define GICD_INT_DEF_PRI_X4		((GICD_INT_DEF_PRI << 24) |\
@@ -16,28 +15,6 @@
 					(GICD_INT_DEF_PRI << 8) |\
 					GICD_INT_DEF_PRI)
 
-enum gic_type {
-	GIC_V2,
-	GIC_V3,
-};
-
-struct gic_kvm_info {
-	/* GIC type */
-	enum gic_type	type;
-	/* Virtual CPU interface */
-	struct resource vcpu;
-	/* Interrupt number */
-	unsigned int	maint_irq;
-	/* Virtual control interface */
-	struct resource vctrl;
-	/* vlpi support */
-	bool		has_v4;
-	/* rvpeid support */
-	bool		has_v4_1;
-};
-
-const struct gic_kvm_info *gic_get_kvm_info(void);
-
 struct irq_domain;
 struct fwnode_handle;
 int gicv2m_init(struct fwnode_handle *parent_handle,
diff --git a/include/linux/irqchip/arm-vgic-info.h b/include/linux/irqchip/arm-vgic-info.h
new file mode 100644
index 000000000000..0319636be928
--- /dev/null
+++ b/include/linux/irqchip/arm-vgic-info.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * include/linux/irqchip/arm-vgic-info.h
+ *
+ * Copyright (C) 2016 ARM Limited, All Rights Reserved.
+ */
+#ifndef __ARM_VGIC_INFO_H
+#define __ARM_VGIC_INFO_H
+
+#include <linux/types.h>
+#include <linux/ioport.h>
+
+enum gic_type {
+	/* Full GICv2 */
+	GIC_V2,
+	/* Full GICv3, optionally with v2 compat */
+	GIC_V3,
+};
+
+struct gic_kvm_info {
+	/* GIC type */
+	enum gic_type	type;
+	/* Virtual CPU interface */
+	struct resource vcpu;
+	/* Interrupt number */
+	unsigned int	maint_irq;
+	/* Virtual control interface */
+	struct resource vctrl;
+	/* vlpi support */
+	bool		has_v4;
+	/* rvpeid support */
+	bool		has_v4_1;
+};
+
+#ifdef CONFIG_KVM
+void vgic_set_kvm_info(const struct gic_kvm_info *info);
+#else
+static inline void vgic_set_kvm_info(const struct gic_kvm_info *info) {}
+#endif
+
+#endif
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:26 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:26 +0100
Subject: [PATCH v2 4/9] KVM: arm64: vgic: Let an interrupt controller
 advertise lack of HW deactivation
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-5-maz@kernel.org>

The vGIC, as architected by ARM, allows a virtual interrupt to
trigger the deactivation of a physical interrupt. This allows
the following interrupt to be delivered without requiring an exit.

However, some implementations have choosen not to implement this,
meaning that we will need some unsavoury workarounds to deal with this.

On detecting such a case, taint the kernel and spit a nastygram.
We'll deal with this in later patches.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-init.c       | 10 ++++++++++
 include/kvm/arm_vgic.h                |  3 +++
 include/linux/irqchip/arm-vgic-info.h |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 00c75495fd0c..0c8637a58535 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -521,6 +521,16 @@ int kvm_vgic_hyp_init(void)
 	if (!gic_kvm_info)
 		return -ENODEV;
 
+	/*
+	 * If we get one of these oddball non-GICs, taint the kernel,
+	 * as we have no idea of how they *really* behave.
+	 */
+	if (gic_kvm_info->no_hw_deactivation) {
+		kvm_info("Non-architectural vgic, tainting kernel\n");
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
+		kvm_vgic_global_state.no_hw_deactivation = true;
+	}
+
 	switch (gic_kvm_info->type) {
 	case GIC_V2:
 		ret = vgic_v2_probe(gic_kvm_info);
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 3d74f1060bd1..7afe789194d8 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -72,6 +72,9 @@ struct vgic_global {
 	bool			has_gicv4;
 	bool			has_gicv4_1;
 
+	/* Pseudo GICv3 from outer space */
+	bool			no_hw_deactivation;
+
 	/* GIC system register CPU interface */
 	struct static_key_false gicv3_cpuif;
 
diff --git a/include/linux/irqchip/arm-vgic-info.h b/include/linux/irqchip/arm-vgic-info.h
index 0319636be928..d39d0b591c5a 100644
--- a/include/linux/irqchip/arm-vgic-info.h
+++ b/include/linux/irqchip/arm-vgic-info.h
@@ -30,6 +30,8 @@ struct gic_kvm_info {
 	bool		has_v4;
 	/* rvpeid support */
 	bool		has_v4_1;
+	/* Deactivation impared, subpar stuff */
+	bool		no_hw_deactivation;
 };
 
 #ifdef CONFIG_KVM
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:28 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:28 +0100
Subject: [PATCH v2 6/9] KVM: arm64: vgic: Implement SW-driven deactivation
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-7-maz@kernel.org>

In order to deal with these systems that do not offer HW-based
deactivation of interrupts, let implement a SW-based approach:

- When the irq is queued into a LR, treat it as a pure virtual
  interrupt and set the EOI flag in the LR.

- When the interrupt state is read back from the LR, force a
  deactivation when the state is invalid (neither active nor
  pending)

Interrupts requiring such treatment get the VGIC_SW_RESAMPLE flag.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-v2.c | 19 +++++++++++++++----
 arch/arm64/kvm/vgic/vgic-v3.c | 19 +++++++++++++++----
 include/kvm/arm_vgic.h        | 10 ++++++++++
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c
index 11934c2af2f4..2c580204f1dc 100644
--- a/arch/arm64/kvm/vgic/vgic-v2.c
+++ b/arch/arm64/kvm/vgic/vgic-v2.c
@@ -108,11 +108,22 @@ void vgic_v2_fold_lr_state(struct kvm_vcpu *vcpu)
 		 * If this causes us to lower the level, we have to also clear
 		 * the physical active state, since we will otherwise never be
 		 * told when the interrupt becomes asserted again.
+		 *
+		 * Another case is when the interrupt requires a helping hand
+		 * on deactivation (no HW deactivation, for example).
 		 */
-		if (vgic_irq_is_mapped_level(irq) && (val & GICH_LR_PENDING_BIT)) {
-			irq->line_level = vgic_get_phys_line_level(irq);
+		if (vgic_irq_is_mapped_level(irq)) {
+			bool resample = false;
+
+			if (val & GICH_LR_PENDING_BIT) {
+				irq->line_level = vgic_get_phys_line_level(irq);
+				resample = !irq->line_level;
+			} else if (vgic_irq_needs_resampling(irq) &&
+				   !(irq->active || irq->pending_latch)) {
+				resample = true;
+			}
 
-			if (!irq->line_level)
+			if (resample)
 				vgic_irq_set_phys_active(irq, false);
 		}
 
@@ -152,7 +163,7 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
 	if (irq->group)
 		val |= GICH_LR_GROUP1;
 
-	if (irq->hw) {
+	if (irq->hw && !vgic_irq_needs_resampling(irq)) {
 		val |= GICH_LR_HW;
 		val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
 		/*
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index 6f530925a231..d7ee88de3a5c 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -99,11 +99,22 @@ void vgic_v3_fold_lr_state(struct kvm_vcpu *vcpu)
 		 * If this causes us to lower the level, we have to also clear
 		 * the physical active state, since we will otherwise never be
 		 * told when the interrupt becomes asserted again.
+		 *
+		 * Another case is when the interrupt requires a helping hand
+		 * on deactivation (no HW deactivation, for example).
 		 */
-		if (vgic_irq_is_mapped_level(irq) && (val & ICH_LR_PENDING_BIT)) {
-			irq->line_level = vgic_get_phys_line_level(irq);
+		if (vgic_irq_is_mapped_level(irq)) {
+			bool resample = false;
+
+			if (val & ICH_LR_PENDING_BIT) {
+				irq->line_level = vgic_get_phys_line_level(irq);
+				resample = !irq->line_level;
+			} else if (vgic_irq_needs_resampling(irq) &&
+				   !(irq->active || irq->pending_latch)) {
+				resample = true;
+			}
 
-			if (!irq->line_level)
+			if (resample)
 				vgic_irq_set_phys_active(irq, false);
 		}
 
@@ -134,7 +145,7 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
 		}
 	}
 
-	if (irq->hw) {
+	if (irq->hw && !vgic_irq_needs_resampling(irq)) {
 		val |= ICH_LR_HW;
 		val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
 		/*
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index a7130f1b5ab9..379ee0c97ede 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -99,6 +99,11 @@ enum vgic_irq_config {
  * kvm_arm_get_running_vcpu() to get the vcpu pointer for private IRQs.
  */
 struct irq_ops {
+	/* Per interrupt flags for special-cased interrupts */
+	unsigned long flags;
+
+#define VGIC_IRQ_SW_RESAMPLE	BIT(0)	/* Clear the active state for resampling */
+
 	/*
 	 * Callback function pointer to in-kernel devices that can tell us the
 	 * state of the input level of mapped level-triggered IRQ faster than
@@ -150,6 +155,11 @@ struct vgic_irq {
 					   for in-kernel devices. */
 };
 
+static inline bool vgic_irq_needs_resampling(struct vgic_irq *irq)
+{
+	return irq->ops && (irq->ops->flags & VGIC_IRQ_SW_RESAMPLE);
+}
+
 struct vgic_register_region;
 struct vgic_its;
 
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:27 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:27 +0100
Subject: [PATCH v2 5/9] KVM: arm64: vgic: move irq->get_input_level into an
 ops structure
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-6-maz@kernel.org>

We already have the option to attach a callback to an interrupt
to retrieve its pending state. As we are planning to expand this
facility, move this callback into its own data structure.

This will limit the size of individual interrupts as the ops
structures can be shared across multiple interrupts.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/arch_timer.c |  8 ++++++--
 arch/arm64/kvm/vgic/vgic.c  | 14 +++++++-------
 include/kvm/arm_vgic.h      | 28 +++++++++++++++++-----------
 3 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 74e0699661e9..e2288b6bf435 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -1116,6 +1116,10 @@ bool kvm_arch_timer_get_input_level(int vintid)
 	return kvm_timer_should_fire(timer);
 }
 
+static struct irq_ops arch_timer_irq_ops = {
+	.get_input_level = kvm_arch_timer_get_input_level,
+};
+
 int kvm_timer_enable(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = vcpu_timer(vcpu);
@@ -1143,7 +1147,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
 	ret = kvm_vgic_map_phys_irq(vcpu,
 				    map.direct_vtimer->host_timer_irq,
 				    map.direct_vtimer->irq.irq,
-				    kvm_arch_timer_get_input_level);
+				    &arch_timer_irq_ops);
 	if (ret)
 		return ret;
 
@@ -1151,7 +1155,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
 		ret = kvm_vgic_map_phys_irq(vcpu,
 					    map.direct_ptimer->host_timer_irq,
 					    map.direct_ptimer->irq.irq,
-					    kvm_arch_timer_get_input_level);
+					    &arch_timer_irq_ops);
 	}
 
 	if (ret)
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1c597c9885fa..1d22365c68e2 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -182,8 +182,8 @@ bool vgic_get_phys_line_level(struct vgic_irq *irq)
 
 	BUG_ON(!irq->hw);
 
-	if (irq->get_input_level)
-		return irq->get_input_level(irq->intid);
+	if (irq->ops && irq->ops->get_input_level)
+		return irq->ops->get_input_level(irq->intid);
 
 	WARN_ON(irq_get_irqchip_state(irq->host_irq,
 				      IRQCHIP_STATE_PENDING,
@@ -479,7 +479,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
 /* @irq->irq_lock must be held */
 static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
 			    unsigned int host_irq,
-			    bool (*get_input_level)(int vindid))
+			    struct irq_ops *ops)
 {
 	struct irq_desc *desc;
 	struct irq_data *data;
@@ -499,7 +499,7 @@ static int kvm_vgic_map_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
 	irq->hw = true;
 	irq->host_irq = host_irq;
 	irq->hwintid = data->hwirq;
-	irq->get_input_level = get_input_level;
+	irq->ops = ops;
 	return 0;
 }
 
@@ -508,11 +508,11 @@ static inline void kvm_vgic_unmap_irq(struct vgic_irq *irq)
 {
 	irq->hw = false;
 	irq->hwintid = 0;
-	irq->get_input_level = NULL;
+	irq->ops = NULL;
 }
 
 int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
-			  u32 vintid, bool (*get_input_level)(int vindid))
+			  u32 vintid, struct irq_ops *ops)
 {
 	struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, vintid);
 	unsigned long flags;
@@ -521,7 +521,7 @@ int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
 	BUG_ON(!irq);
 
 	raw_spin_lock_irqsave(&irq->irq_lock, flags);
-	ret = kvm_vgic_map_irq(vcpu, irq, host_irq, get_input_level);
+	ret = kvm_vgic_map_irq(vcpu, irq, host_irq, ops);
 	raw_spin_unlock_irqrestore(&irq->irq_lock, flags);
 	vgic_put_irq(vcpu->kvm, irq);
 
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 7afe789194d8..a7130f1b5ab9 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -92,6 +92,21 @@ enum vgic_irq_config {
 	VGIC_CONFIG_LEVEL
 };
 
+/*
+ * Per-irq ops overriding some common behavious.
+ *
+ * Always called in non-preemptible section and the functions can use
+ * kvm_arm_get_running_vcpu() to get the vcpu pointer for private IRQs.
+ */
+struct irq_ops {
+	/*
+	 * Callback function pointer to in-kernel devices that can tell us the
+	 * state of the input level of mapped level-triggered IRQ faster than
+	 * peaking into the physical GIC.
+	 */
+	bool (*get_input_level)(int vintid);
+};
+
 struct vgic_irq {
 	raw_spinlock_t irq_lock;	/* Protects the content of the struct */
 	struct list_head lpi_list;	/* Used to link all LPIs together */
@@ -129,16 +144,7 @@ struct vgic_irq {
 	u8 group;			/* 0 == group 0, 1 == group 1 */
 	enum vgic_irq_config config;	/* Level or edge */
 
-	/*
-	 * Callback function pointer to in-kernel devices that can tell us the
-	 * state of the input level of mapped level-triggered IRQ faster than
-	 * peaking into the physical GIC.
-	 *
-	 * Always called in non-preemptible section and the functions can use
-	 * kvm_arm_get_running_vcpu() to get the vcpu pointer for private
-	 * IRQs.
-	 */
-	bool (*get_input_level)(int vintid);
+	struct irq_ops *ops;
 
 	void *owner;			/* Opaque pointer to reserve an interrupt
 					   for in-kernel devices. */
@@ -354,7 +360,7 @@ void kvm_vgic_init_cpu_hardware(void);
 int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int intid,
 			bool level, void *owner);
 int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
-			  u32 vintid, bool (*get_input_level)(int vindid));
+			  u32 vintid, struct irq_ops *ops);
 int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int vintid);
 bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, unsigned int vintid);
 
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:31 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:31 +0100
Subject: [PATCH v2 9/9] irqchip/apple-aic: Advertise some level of vGICv3
 compatibility
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-10-maz@kernel.org>

The CPUs in the Apple M1 SoC partially implement a virtual GICv3
CPU interface, although one that is incapable of HW deactivation
of interrupts.

Advertise the support to KVM.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/irqchip/irq-apple-aic.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/irqchip/irq-apple-aic.c b/drivers/irqchip/irq-apple-aic.c
index ed16b6cc00d7..65067b2c746b 100644
--- a/drivers/irqchip/irq-apple-aic.c
+++ b/drivers/irqchip/irq-apple-aic.c
@@ -50,6 +50,7 @@
 #include <linux/cpuhotplug.h>
 #include <linux/io.h>
 #include <linux/irqchip.h>
+#include <linux/irqchip/arm-vgic-info.h>
 #include <linux/irqdomain.h>
 #include <linux/limits.h>
 #include <linux/of_address.h>
@@ -772,6 +773,11 @@ static int aic_init_cpu(unsigned int cpu)
 	return 0;
 }
 
+static struct gic_kvm_info vgic_info __initdata = {
+	.type			= GIC_V3,
+	.no_hw_deactivation	= true,
+};
+
 static int __init aic_of_ic_init(struct device_node *node, struct device_node *parent)
 {
 	int i;
@@ -828,6 +834,8 @@ static int __init aic_of_ic_init(struct device_node *node, struct device_node *p
 			  "irqchip/apple-aic/ipi:starting",
 			  aic_init_cpu, NULL);
 
+	vgic_set_kvm_info(&vgic_info);
+
 	pr_info("Initialized with %d IRQs, %d FIQs, %d vIPIs\n",
 		irqc->nr_hw, AIC_NR_FIQ, AIC_NR_SWIPI);
 
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:29 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:29 +0100
Subject: [PATCH v2 7/9] KVM: arm64: timer: Refactor IRQ configuration
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-8-maz@kernel.org>

As we are about to add some more things to the timer IRQ
configuration, move this code out of the main timer init code
into its own set of functions.

No functional changes.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/arch_timer.c | 61 ++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index e2288b6bf435..7fa4f446456a 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -973,6 +973,39 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
 	return 0;
 }
 
+static void kvm_irq_fixup_flags(unsigned int virq, u32 *flags)
+{
+	*flags = irq_get_trigger_type(virq);
+	if (*flags != IRQF_TRIGGER_HIGH && *flags != IRQF_TRIGGER_LOW) {
+		kvm_err("Invalid trigger for timer IRQ%d, assuming level low\n",
+			virq);
+		*flags = IRQF_TRIGGER_LOW;
+	}
+}
+
+static int kvm_irq_init(struct arch_timer_kvm_info *info)
+{
+	struct irq_domain *domain = NULL;
+	struct fwnode_handle *fwnode;
+	struct irq_data *data;
+
+	if (info->virtual_irq <= 0) {
+		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
+			info->virtual_irq);
+		return -ENODEV;
+	}
+
+	host_vtimer_irq = info->virtual_irq;
+	kvm_irq_fixup_flags(host_vtimer_irq, &host_vtimer_irq_flags);
+
+	if (info->physical_irq > 0) {
+		host_ptimer_irq = info->physical_irq;
+		kvm_irq_fixup_flags(host_ptimer_irq, &host_ptimer_irq_flags);
+	}
+
+	return 0;
+}
+
 int kvm_timer_hyp_init(bool has_gic)
 {
 	struct arch_timer_kvm_info *info;
@@ -986,22 +1019,11 @@ int kvm_timer_hyp_init(bool has_gic)
 		return -ENODEV;
 	}
 
-	/* First, do the virtual EL1 timer irq */
-
-	if (info->virtual_irq <= 0) {
-		kvm_err("kvm_arch_timer: invalid virtual timer IRQ: %d\n",
-			info->virtual_irq);
-		return -ENODEV;
-	}
-	host_vtimer_irq = info->virtual_irq;
+	err = kvm_irq_init(info);
+	if (err)
+		return err;
 
-	host_vtimer_irq_flags = irq_get_trigger_type(host_vtimer_irq);
-	if (host_vtimer_irq_flags != IRQF_TRIGGER_HIGH &&
-	    host_vtimer_irq_flags != IRQF_TRIGGER_LOW) {
-		kvm_err("Invalid trigger for vtimer IRQ%d, assuming level low\n",
-			host_vtimer_irq);
-		host_vtimer_irq_flags = IRQF_TRIGGER_LOW;
-	}
+	/* First, do the virtual EL1 timer irq */
 
 	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
 				 "kvm guest vtimer", kvm_get_running_vcpus());
@@ -1027,15 +1049,6 @@ int kvm_timer_hyp_init(bool has_gic)
 	/* Now let's do the physical EL1 timer irq */
 
 	if (info->physical_irq > 0) {
-		host_ptimer_irq = info->physical_irq;
-		host_ptimer_irq_flags = irq_get_trigger_type(host_ptimer_irq);
-		if (host_ptimer_irq_flags != IRQF_TRIGGER_HIGH &&
-		    host_ptimer_irq_flags != IRQF_TRIGGER_LOW) {
-			kvm_err("Invalid trigger for ptimer IRQ%d, assuming level low\n",
-				host_ptimer_irq);
-			host_ptimer_irq_flags = IRQF_TRIGGER_LOW;
-		}
-
 		err = request_percpu_irq(host_ptimer_irq, kvm_arch_timer_handler,
 					 "kvm guest ptimer", kvm_get_running_vcpus());
 		if (err) {
-- 
2.29.2



From maz at kernel.org  Sat Apr  3 12:29:30 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat,  3 Apr 2021 12:29:30 +0100
Subject: [PATCH v2 8/9] KVM: arm64: timer: Add support for SW-based
 deactivation
In-Reply-To: <20210403112931.1043452-1-maz@kernel.org>
References: <20210403112931.1043452-1-maz@kernel.org>
Message-ID: <20210403112931.1043452-9-maz@kernel.org>

In order to deal with the lack of active state, we need to use
the mask/unmask primitives (after all, the active state is just an
additional mask on top of the normal one).

To avoid adding a bunch of ugly conditionals in the timer and vgic
code, let's use a timer-specific irqdomain to deal with the state
conversion. Yes, this is an unexpected use of irqdomains, but
there is no reason not to be just as creative as the designers
of the HW...

This involves overloading the vcpu_affinity, set_irqchip_state
and eoi callbacks so that the rest of the KVM code can continue
ignoring the oddities of the underlying platform.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/arch_timer.c | 100 ++++++++++++++++++++++++++++++++++--
 1 file changed, 96 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
index 7fa4f446456a..4c24cbb19ba1 100644
--- a/arch/arm64/kvm/arch_timer.c
+++ b/arch/arm64/kvm/arch_timer.c
@@ -9,6 +9,7 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/irqdomain.h>
 #include <linux/uaccess.h>
 
 #include <clocksource/arm_arch_timer.h>
@@ -973,6 +974,77 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
 	return 0;
 }
 
+static int timer_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
+{
+	if (vcpu)
+		irqd_set_forwarded_to_vcpu(d);
+	else
+		irqd_clr_forwarded_to_vcpu(d);
+
+	return 0;
+}
+
+static int timer_irq_set_irqchip_state(struct irq_data *d,
+				       enum irqchip_irq_state which, bool val)
+{
+	if (which != IRQCHIP_STATE_ACTIVE || !irqd_is_forwarded_to_vcpu(d))
+		return irq_chip_set_parent_state(d, which, val);
+
+	if (val)
+		irq_chip_mask_parent(d);
+	else
+		irq_chip_unmask_parent(d);
+
+	return 0;
+}
+
+static void timer_irq_eoi(struct irq_data *d)
+{
+	if (!irqd_is_forwarded_to_vcpu(d))
+		irq_chip_eoi_parent(d);
+}
+
+static void timer_irq_ack(struct irq_data *d)
+{
+	d = d->parent_data;
+	if (d->chip->irq_ack)
+		d->chip->irq_ack(d);
+}
+
+static struct irq_chip timer_chip = {
+	.name			= "KVM",
+	.irq_ack		= timer_irq_ack,
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= timer_irq_eoi,
+	.irq_set_type		= irq_chip_set_type_parent,
+	.irq_set_vcpu_affinity	= timer_irq_set_vcpu_affinity,
+	.irq_set_irqchip_state	= timer_irq_set_irqchip_state,
+};
+
+static int timer_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+				  unsigned int nr_irqs, void *arg)
+{
+	irq_hw_number_t hwirq = (uintptr_t)arg;
+
+	return irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
+					     &timer_chip, NULL);
+}
+
+static void timer_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+				  unsigned int nr_irqs)
+{
+}
+
+static const struct irq_domain_ops timer_domain_ops = {
+	.alloc	= timer_irq_domain_alloc,
+	.free	= timer_irq_domain_free,
+};
+
+static struct irq_ops arch_timer_irq_ops = {
+	.get_input_level = kvm_arch_timer_get_input_level,
+};
+
 static void kvm_irq_fixup_flags(unsigned int virq, u32 *flags)
 {
 	*flags = irq_get_trigger_type(virq);
@@ -998,9 +1070,33 @@ static int kvm_irq_init(struct arch_timer_kvm_info *info)
 	host_vtimer_irq = info->virtual_irq;
 	kvm_irq_fixup_flags(host_vtimer_irq, &host_vtimer_irq_flags);
 
+	if (kvm_vgic_global_state.no_hw_deactivation) {
+		fwnode = irq_domain_alloc_named_fwnode("kvm-timer");
+		if (!fwnode)
+			return -ENOMEM;
+
+		/* Assume both vtimer and ptimer in the same parent */
+		data = irq_get_irq_data(host_vtimer_irq);
+		domain = irq_domain_create_hierarchy(data->domain, 0,
+						     NR_KVM_TIMERS, fwnode,
+						     &timer_domain_ops, NULL);
+		if (!domain) {
+			irq_domain_free_fwnode(fwnode);
+			return -ENOMEM;
+		}
+
+		arch_timer_irq_ops.flags |= VGIC_IRQ_SW_RESAMPLE;
+		WARN_ON(irq_domain_push_irq(domain, host_vtimer_irq,
+					    (void *)TIMER_VTIMER));
+	}
+
 	if (info->physical_irq > 0) {
 		host_ptimer_irq = info->physical_irq;
 		kvm_irq_fixup_flags(host_ptimer_irq, &host_ptimer_irq_flags);
+
+		if (domain)
+			WARN_ON(irq_domain_push_irq(domain, host_ptimer_irq,
+						    (void *)TIMER_PTIMER));
 	}
 
 	return 0;
@@ -1129,10 +1225,6 @@ bool kvm_arch_timer_get_input_level(int vintid)
 	return kvm_timer_should_fire(timer);
 }
 
-static struct irq_ops arch_timer_irq_ops = {
-	.get_input_level = kvm_arch_timer_get_input_level,
-};
-
 int kvm_timer_enable(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = vcpu_timer(vcpu);
-- 
2.29.2



From xuwei5 at hisilicon.com  Sat Apr  3 15:59:06 2021
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Sat, 3 Apr 2021 22:59:06 +0800
Subject: [GIT,PULL] arm: hisilicon: SoC updates for v5.13
Message-ID: <eba8b55e-0969-8ca2-eca3-7c471cb0ff6f@hisilicon.com>

Hi ARM-SoC team,

Please consider to pull the following changes.
Thanks!

Best Regards,
Wei

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the git repository at:

  git://github.com/hisilicon/linux-hisi.git tags/hisi-armv7soc-for-5.13

for you to fetch changes up to c1ce9d8081a9fca5fd1b2e48bcc20e5dc3387302:

  ARM: hisi: use the correct HiSilicon copyright (2021-04-02 15:36:27 +0800)

----------------------------------------------------------------
HiSilicon ARMv7 SoC updates for v5.13

- Correct the HiSilicon copyright

----------------------------------------------------------------
Hao Fang (1):
      ARM: hisi: use the correct HiSilicon copyright

 arch/arm/mach-hisi/hisilicon.c | 4 ++--
 arch/arm/mach-hisi/hotplug.c   | 2 +-
 arch/arm/mach-hisi/platmcpm.c  | 2 +-
 arch/arm/mach-hisi/platsmp.c   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)


From xuwei5 at hisilicon.com  Sat Apr  3 16:06:05 2021
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Sat, 3 Apr 2021 23:06:05 +0800
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v5.13
Message-ID: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>

Hi ARM-SoC team,

Please consider to pull the following changes.
Thanks!

Best Regards,
Wei

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the git repository at:

  git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-5.13

for you to fetch changes up to 3d208c8207bfaa861a783c8fed9f31438fc0bcc6:

  arm64: dts: hisilicon: correct vendor prefix hisi to hisilicon (2021-04-02 15:12:52 +0800)

----------------------------------------------------------------
ARM64: DT: Hisilicon ARM64 DT updates for 5.13

- Correct the vendor prefix for hi3660 and hi3670

----------------------------------------------------------------
Zhen Lei (1):
      arm64: dts: hisilicon: correct vendor prefix hisi to hisilicon

 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
 arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)


From jpoimboe at redhat.com  Sat Apr  3 16:59:48 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Sat, 3 Apr 2021 10:59:48 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210402032404.47239-2-madvenka@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
Message-ID: <20210403155948.ubbgtwmlsdyar7yp@treble>

On Thu, Apr 01, 2021 at 10:24:04PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>  #endif
>  	bl	switch_to_vhe			// Prefer VHE if possible
>  	add	sp, sp, #16
> -	mov	x29, #0
> -	mov	x30, #0
> -	b	start_kernel
> +	setup_final_frame
> +	bl	start_kernel
> +	nop
>  SYM_FUNC_END(__primary_switched)
>  
>  	.pushsection ".rodata", "a"
> @@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
>  	cbz	x2, __secondary_too_slow
>  	msr	sp_el0, x2
>  	scs_load x2, x3
> -	mov	x29, #0
> -	mov	x30, #0
> +	setup_final_frame
>  
>  #ifdef CONFIG_ARM64_PTR_AUTH
>  	ptrauth_keys_init_cpu x2, x3, x4, x5
>  #endif
>  
> -	b	secondary_start_kernel
> +	bl	secondary_start_kernel
> +	nop
>  SYM_FUNC_END(__secondary_switched)

I'm somewhat arm-ignorant, so take the following comments with a grain
of salt.


I don't think changing these to 'bl' is necessary, unless you wanted
__primary_switched() and __secondary_switched() to show up in the
stacktrace for some reason?  If so, that seems like a separate patch.


Also, why are nops added after the calls?  My guess would be because,
since these are basically tail calls to "noreturn" functions, the stack
dump code would otherwise show the wrong function, i.e. whatever
function happens to be after the 'bl'.

We had the same issue for x86.  It can be fixed by using '%pB' instead
of '%pS' when printing the address in dump_backtrace_entry().  See
sprint_backtrace() for more details.

BTW I think the same issue exists for GCC-generated code.  The following
shows several such cases:

  objdump -dr vmlinux |awk '/bl   / {bl=1;l=$0;next} bl == 1 && /^$/ {print l; print} // {bl=0}'


However, looking at how arm64 unwinds through exceptions in kernel
space, using '%pB' might have side effects when the exception LR
(elr_el1) points to the beginning of a function.  Then '%pB' would show
the end of the previous function, instead of the function which was
interrupted.

So you may need to rethink how to unwind through in-kernel exceptions.

Basically, when printing a stack return address, you want to use '%pB'
for a call return address and '%pS' for an interrupted address.

On x86, with the frame pointer unwinder, we encode the frame pointer by
setting a bit in %rbp which tells the unwinder that it's a special
pt_regs frame.  Then instead of treating it like a normal call frame,
the stack dump code prints the registers, and the return address
(regs->ip) gets printed with '%pS'.

>  SYM_FUNC_START_LOCAL(__secondary_too_slow)
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 325c83b1a24d..906baa232a89 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -437,6 +437,11 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>  	}
>  	p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>  	p->thread.cpu_context.sp = (unsigned long)childregs;
> +	/*
> +	 * For the benefit of the unwinder, set up childregs->stackframe
> +	 * as the final frame for the new task.
> +	 */
> +	p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
>  
>  	ptrace_hw_copy_thread(p);
>  
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index ad20981dfda4..72f5af8c69dc 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  	unsigned long fp = frame->fp;
>  	struct stack_info info;
>  
> -	/* Terminal record; nothing to unwind */
> -	if (!fp)
> +	if (!tsk)
> +		tsk = current;
> +
> +	/* Final frame; nothing to unwind */
> +	if (fp == (unsigned long) task_pt_regs(tsk)->stackframe)
>  		return -ENOENT;

As far as I can tell, the regs stackframe value is initialized to zero
during syscall entry, so isn't this basically just 'if (fp == 0)'?

Shouldn't it instead be comparing with the _address_ of the stackframe
field to make sure it reached the end?

-- 
Josh



From jpoimboe at redhat.com  Sat Apr  3 18:01:59 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Sat, 3 Apr 2021 12:01:59 -0500
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210330190955.13707-1-madvenka@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
Message-ID: <20210403170159.gegqjrsrg7jshlne@treble>

On Tue, Mar 30, 2021 at 02:09:51PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> There are a number of places in kernel code where the stack trace is not
> reliable. Enhance the unwinder to check for those cases and mark the
> stack trace as unreliable. Once all of the checks are in place, the unwinder
> can be used for livepatching.

This assumes all such places are known.  That's a big assumption, as

a) hand-written asm code may inadvertantly skip frame pointer setup;

b) for inline asm which calls a function, the compiler may blindly
   insert it into a function before the frame pointer setup.

That's where objtool stack validation would come in.
   
> Detect EL1 exception frame
> ==========================
> 
> EL1 exceptions can happen on any instruction including instructions in
> the frame pointer prolog or epilog. Depending on where exactly they happen,
> they could render the stack trace unreliable.
> 
> Add all of the EL1 exception handlers to special_functions[].
> 
> 	- el1_sync()
> 	- el1_irq()
> 	- el1_error()
> 	- el1_sync_invalid()
> 	- el1_irq_invalid()
> 	- el1_fiq_invalid()
> 	- el1_error_invalid()

A possibly more robust alternative would be to somehow mark el1
exception frames so the unwinder can detect them more generally.

For example, as described in my previous email, encode the frame pointer
so the unwinder can detect el1 frames automatically.

> Detect ftrace frame
> ===================
> 
> When FTRACE executes at the beginning of a traced function, it creates two
> frames and calls the tracer function:
> 
> 	- One frame for the traced function
> 
> 	- One frame for the caller of the traced function
> 
> That gives a sensible stack trace while executing in the tracer function.
> When FTRACE returns to the traced function, the frames are popped and
> everything is back to normal.
> 
> However, in cases like live patch, the tracer function redirects execution
> to a different function. When FTRACE returns, control will go to that target
> function. A stack trace taken in the tracer function will not show the target
> function. The target function is the real function that we want to track.
> So, the stack trace is unreliable.

I don't think this is a real problem.  Livepatch only checks the stacks
of blocked tasks (and the task calling into livepatch).  So the
reliability of unwinding from the livepatch tracer function itself
(klp_ftrace_handler) isn't a concern since it doesn't sleep.

> To detect FTRACE in a stack trace, add the following to special_functions[]:
> 
> 	- ftrace_graph_call()
> 	- ftrace_graph_caller()
> 
> Please see the diff for a comment that explains why ftrace_graph_call()
> must be checked.
> 
> Also, the Function Graph Tracer modifies the return address of a traced
> function to a return trampoline (return_to_handler()) to gather tracing
> data on function return. Stack traces taken from the traced function and
> functions it calls will not show the original caller of the traced function.
> The unwinder handles this case by getting the original caller from FTRACE.
> 
> However, stack traces taken from the trampoline itself and functions it calls
> are unreliable as the original return address may not be available in
> that context. This is because the trampoline calls FTRACE to gather trace
> data as well as to obtain the actual return address and FTRACE discards the
> record of the original return address along the way.

Again, this shouldn't be a concern because livepatch won't be unwinding
from a function_graph trampoline unless it got preempted somehow (and
then the el1 frame would get detected anyway).

> Add return_to_handler() to special_functions[].
> 
> Check for kretprobe
> ===================
> 
> For functions with a kretprobe set up, probe code executes on entry
> to the function and replaces the return address in the stack frame with a
> kretprobe trampoline. Whenever the function returns, control is
> transferred to the trampoline. The trampoline eventually returns to the
> original return address.
> 
> A stack trace taken while executing in the function (or in functions that
> get called from the function) will not show the original return address.
> Similarly, a stack trace taken while executing in the trampoline itself
> (and functions that get called from the trampoline) will not show the
> original return address. This means that the caller of the probed function
> will not show. This makes the stack trace unreliable.
> 
> Add the kretprobe trampoline to special_functions[].
> 
> FYI, each task contains a task->kretprobe_instances list that can
> theoretically be consulted to find the orginal return address. But I am
> not entirely sure how to safely traverse that list for stack traces
> not on the current process. So, I have taken the easy way out.

For kretprobes, unwinding from the trampoline or kretprobe handler
shouldn't be a reliability concern for live patching, for similar
reasons as above.

Otherwise, when unwinding from a blocked task which has
'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
original return address.  Masami has been working on an interface to
make that possible for x86.  I assume something similar could be done
for arm64.

> Optprobes
> =========
> 
> Optprobes may be implemented in the future for arm64. For optprobes,
> the relevant trampoline(s) can be added to special_functions[].

Similar comment here, livepatch doesn't unwind from such trampolines.

-- 
Josh



From lkp at intel.com  Sat Apr  3 18:25:17 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 01:25:17 +0800
Subject: [arm-platforms:hack/m1-pcie 15/15]
 drivers/iommu/apple-dart-iommu.c:801:29: error: 'pci_bus_type' undeclared;
 did you mean 'pci_pcie_type'?
Message-ID: <202104040112.wrVj0bRL-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 1fd2c9634dd24fba323baba52200de18e4d3f4ee [15/15] WIP
config: sparc64-randconfig-r021-20210404 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=1fd2c9634dd24fba323baba52200de18e4d3f4ee
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 1fd2c9634dd24fba323baba52200de18e4d3f4ee
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sparc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/iommu/apple-dart-iommu.c: In function 'apple_dart_probe':
>> drivers/iommu/apple-dart-iommu.c:801:29: error: 'pci_bus_type' undeclared (first use in this function); did you mean 'pci_pcie_type'?
     801 |  if (dev->bus->iommu_ops != pci_bus_type.iommu_ops) {
         |                             ^~~~~~~~~~~~
         |                             pci_pcie_type
   drivers/iommu/apple-dart-iommu.c:801:29: note: each undeclared identifier is reported only once for each function it appears in

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for FRAME_POINTER
   Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS || MCOUNT
   Selected by
   - LOCKDEP && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && !MIPS && !PPC && !ARM && !S390 && !MICROBLAZE && !ARC && !X86


vim +801 drivers/iommu/apple-dart-iommu.c

   730	
   731	static int apple_dart_probe(struct platform_device *pdev)
   732	{
   733		int ret;
   734		int i;
   735		struct resource *res;
   736		struct apple_dart *dart;
   737		struct device *dev = &pdev->dev;
   738	
   739		dev_warn(&pdev->dev, "probing\n");
   740		dart = devm_kzalloc(dev, sizeof(*dart), GFP_KERNEL);
   741		if (!dart)
   742			return -ENOMEM;
   743	
   744		dart->dev = dev;
   745		spin_lock_init(&dart->lock);
   746	
   747		if (pdev->num_resources < 1)
   748			return -ENODEV;
   749	
   750		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
   751		if (resource_size(res) < 0x4000) {
   752			dev_err(dev, "MMIO region too small (%pr)\n", res);
   753			return -EINVAL;
   754		}
   755	
   756		dart->regs = devm_ioremap_resource(dev, res);
   757		if (IS_ERR(dart->regs))
   758			return PTR_ERR(dart->regs);
   759	
   760		ret = devm_clk_bulk_get_all(dev, &dart->clks);
   761		if (ret < 0)
   762			return ret;
   763		dart->num_clks = ret;
   764	
   765		ret = clk_bulk_prepare_enable(dart->num_clks, dart->clks);
   766		if (ret)
   767			return ret;
   768	
   769		ret = apple_dart_hw_reset(dart);
   770		if (ret)
   771			return ret;
   772	
   773		dart->irq = platform_get_irq(pdev, 0);
   774		if (dart->irq < 0)
   775			return -ENODEV;
   776	
   777		ret = devm_request_irq(dart->dev, dart->irq, apple_dart_irq,
   778				       IRQF_SHARED, "apple-dart fault handler", dart);
   779		if (ret)
   780			return ret;
   781	
   782		platform_set_drvdata(pdev, dart);
   783	
   784		ret = iommu_device_sysfs_add(&dart->iommu, dev, NULL, "apple-dart.%s",
   785					     dev_name(&pdev->dev));
   786		if (ret)
   787			return ret;
   788	
   789		iommu_device_set_ops(&dart->iommu, &apple_dart_iommu_ops);
   790		iommu_device_set_fwnode(&dart->iommu, dev->fwnode);
   791	
   792		ret = iommu_device_register(&dart->iommu);
   793		if (ret)
   794			return ret;
   795	
   796		if (dev->bus->iommu_ops != &apple_dart_iommu_ops) {
   797			ret = bus_set_iommu(dev->bus, &apple_dart_iommu_ops);
   798			if (ret)
   799				return ret;
   800		}
 > 801		if (dev->bus->iommu_ops != pci_bus_type.iommu_ops) {
   802			ret = bus_set_iommu(&pci_bus_type, &apple_dart_iommu_ops);
   803			if (ret)
   804				return ret;
   805		}
   806	
   807		dev_warn(&pdev->dev, "probed\n");
   808		return 0;
   809	}
   810	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29906 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/53fb1f03/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 18:28:35 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 01:28:35 +0800
Subject: [arm-platforms:hack/m1-pcie 77/99] include/linux/io.h:98:22: error:
 implicit declaration of function 'ioremap_np'
Message-ID: <202104040128.ew0Vvp8P-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 3364619d8489baef060f4ac9c71ae25c128ae820 [77/99] asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
config: powerpc64-randconfig-r004-20210403 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 3bcb6a389ff4338d76a25b7d9e0e3c40d84695be)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=3364619d8489baef060f4ac9c71ae25c128ae820
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 3364619d8489baef060f4ac9c71ae25c128ae820
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
>> include/linux/io.h:98:22: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           void __iomem *ret = ioremap_np(offset, size);
                               ^
>> include/linux/io.h:98:16: warning: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion]
           void __iomem *ret = ioremap_np(offset, size);
                         ^     ~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
--
   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
>> include/linux/io.h:98:22: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           void __iomem *ret = ioremap_np(offset, size);
                               ^
>> include/linux/io.h:98:16: warning: incompatible integer to pointer conversion initializing 'void *' with an expression of type 'int' [-Wint-conversion]
           void __iomem *ret = ioremap_np(offset, size);
                         ^     ~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
   make[2]: *** [scripts/Makefile.build:116: arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1235: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +/ioremap_np +98 include/linux/io.h

    81	
    82	#ifdef CONFIG_PCI
    83	/*
    84	 * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
    85	 * Posting") mandate non-posted configuration transactions. This default
    86	 * implementation attempts to use the ioremap_np() API to provide this
    87	 * on arches that support it, and falls back to ioremap() on those that
    88	 * don't. Overriding this function is deprecated; arches that properly
    89	 * support non-posted accesses should implement ioremap_np() instead, which
    90	 * this default implementation can then use to return mappings compliant with
    91	 * the PCI specification.
    92	 */
    93	#ifndef pci_remap_cfgspace
    94	#define pci_remap_cfgspace pci_remap_cfgspace
    95	static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
    96						       size_t size)
    97	{
  > 98		void __iomem *ret = ioremap_np(offset, size);
    99	
   100		if (!ret)
   101			ret = ioremap(offset, size);
   102	
   103		return ret;
   104	}
   105	#endif
   106	#endif
   107	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33711 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/4439a9fb/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 18:44:20 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 01:44:20 +0800
Subject: [arm-platforms:hack/m1-pcie 10/15]
 drivers/pci/controller/pcie-apple-m1.c:66:22: warning: initialized field
 overwritten
Message-ID: <202104040118.KkSduCky-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 4506277b9030202811e5c671330c1ac9b1d3a0b0 [10/15] M1 PCIe hacks
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=4506277b9030202811e5c671330c1ac9b1d3a0b0
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 4506277b9030202811e5c671330c1ac9b1d3a0b0
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/pci/controller/pcie-apple-m1.c:66:22: warning: initialized field overwritten [-Woverride-init]
      66 |  .irq_set_affinity = irq_chip_set_affinity_parent,
         |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/pci/controller/pcie-apple-m1.c:66:22: note: (near initialization for 'apple_msi_bottom_chip.irq_set_affinity')


vim +66 drivers/pci/controller/pcie-apple-m1.c

    59	
    60	static struct irq_chip apple_msi_bottom_chip = {
    61		.name			= "MSI",
    62		.irq_mask		= irq_chip_mask_parent,
    63		.irq_unmask		= irq_chip_unmask_parent,
    64		.irq_set_affinity 	= irq_chip_set_affinity_parent,
    65		.irq_eoi		= irq_chip_eoi_parent,
  > 66		.irq_set_affinity	= irq_chip_set_affinity_parent,
    67		.irq_set_type		= irq_chip_set_type_parent,
    68		.irq_compose_msi_msg	= apple_msi_compose_msg,
    69	};
    70	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67441 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/39f440d4/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 18:45:22 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 01:45:22 +0800
Subject: [arm-platforms:hack/m1-pcie 10/15]
 drivers/pci/controller/pcie-apple-m1.c:66:22: warning: initializer overrides
 prior initialization of this subobject
Message-ID: <202104040120.fvH69zea-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 4506277b9030202811e5c671330c1ac9b1d3a0b0 [10/15] M1 PCIe hacks
config: riscv-randconfig-r026-20210404 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 3bcb6a389ff4338d76a25b7d9e0e3c40d84695be)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install riscv cross compiling tool for clang build
        # apt-get install binutils-riscv64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=4506277b9030202811e5c671330c1ac9b1d3a0b0
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 4506277b9030202811e5c671330c1ac9b1d3a0b0
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/pci/controller/pcie-apple-m1.c:66:22: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
           .irq_set_affinity       = irq_chip_set_affinity_parent,
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/pci/controller/pcie-apple-m1.c:64:23: note: previous initialization is here
           .irq_set_affinity       = irq_chip_set_affinity_parent,
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning generated.


vim +66 drivers/pci/controller/pcie-apple-m1.c

    59	
    60	static struct irq_chip apple_msi_bottom_chip = {
    61		.name			= "MSI",
    62		.irq_mask		= irq_chip_mask_parent,
    63		.irq_unmask		= irq_chip_unmask_parent,
    64		.irq_set_affinity 	= irq_chip_set_affinity_parent,
    65		.irq_eoi		= irq_chip_eoi_parent,
  > 66		.irq_set_affinity	= irq_chip_set_affinity_parent,
    67		.irq_set_type		= irq_chip_set_type_parent,
    68		.irq_compose_msi_msg	= apple_msi_compose_msg,
    69	};
    70	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 44592 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/e7452b38/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 18:57:19 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 01:57:19 +0800
Subject: [arm-platforms:hack/m1-pcie 73/99] lib/devres.c:47:10: error:
 implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'?
Message-ID: <202104040117.oZ6DoQxO-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 8ac84ab8494128c7c12e9e7609c67bc7fb62a428 [73/99] asm-generic/io.h:  Add a non-posted variant of ioremap()
config: powerpc-mpc8540_ads_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=8ac84ab8494128c7c12e9e7609c67bc7fb62a428
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 8ac84ab8494128c7c12e9e7609c67bc7fb62a428
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   lib/devres.c: In function '__devm_ioremap':
>> lib/devres.c:47:10: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
      47 |   addr = ioremap_np(offset, size);
         |          ^~~~~~~~~~
         |          ioremap_wt
>> lib/devres.c:47:8: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
      47 |   addr = ioremap_np(offset, size);
         |        ^
   cc1: some warnings being treated as errors


vim +47 lib/devres.c

    25	
    26	static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
    27					    resource_size_t size,
    28					    enum devm_ioremap_type type)
    29	{
    30		void __iomem **ptr, *addr = NULL;
    31	
    32		ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
    33		if (!ptr)
    34			return NULL;
    35	
    36		switch (type) {
    37		case DEVM_IOREMAP:
    38			addr = ioremap(offset, size);
    39			break;
    40		case DEVM_IOREMAP_UC:
    41			addr = ioremap_uc(offset, size);
    42			break;
    43		case DEVM_IOREMAP_WC:
    44			addr = ioremap_wc(offset, size);
    45			break;
    46		case DEVM_IOREMAP_NP:
  > 47			addr = ioremap_np(offset, size);
    48			break;
    49		}
    50	
    51		if (addr) {
    52			*ptr = addr;
    53			devres_add(dev, ptr);
    54		} else
    55			devres_free(ptr);
    56	
    57		return addr;
    58	}
    59	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 12600 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/415c1004/attachment.gz>

From lkp at intel.com  Sat Apr  3 19:08:33 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 02:08:33 +0800
Subject: [arm-platforms:hack/m1-pcie 15/15] include/linux/kern_levels.h:5:18:
 warning: format '%lx' expects argument of type 'long unsigned int',
 but argument 4 has type 'size_t' {aka 'unsigned int'}
Message-ID: <202104040226.pdN7ukMZ-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 1fd2c9634dd24fba323baba52200de18e4d3f4ee [15/15] WIP
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=1fd2c9634dd24fba323baba52200de18e4d3f4ee
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 1fd2c9634dd24fba323baba52200de18e4d3f4ee
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:7,
                    from include/linux/kernel.h:16,
                    from include/linux/clk.h:13,
                    from drivers/iommu/apple-dart-iommu.c:12:
   drivers/iommu/apple-dart-iommu.c: In function 'apple_dart_map':
>> include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
       5 | #define KERN_SOH "\001"  /* ASCII Start Of Header */
         |                  ^~~~~~
   include/linux/kern_levels.h:12:22: note: in expansion of macro 'KERN_SOH'
      12 | #define KERN_WARNING KERN_SOH "4" /* warning conditions */
         |                      ^~~~~~~~
   include/linux/printk.h:353:9: note: in expansion of macro 'KERN_WARNING'
     353 |  printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
         |         ^~~~~~~~~~~~
   drivers/iommu/apple-dart-iommu.c:360:2: note: in expansion of macro 'pr_warn'
     360 |  pr_warn("mapping %lx %llx %lx\n", iova, paddr, size);
         |  ^~~~~~~
   drivers/iommu/apple-dart-iommu.c:360:30: note: format string is defined here
     360 |  pr_warn("mapping %lx %llx %lx\n", iova, paddr, size);
         |                            ~~^
         |                              |
         |                              long unsigned int
         |                            %x


vim +5 include/linux/kern_levels.h

314ba3520e513a Joe Perches 2012-07-30  4  
04d2c8c83d0e3a Joe Perches 2012-07-30 @5  #define KERN_SOH	"\001"		/* ASCII Start Of Header */
04d2c8c83d0e3a Joe Perches 2012-07-30  6  #define KERN_SOH_ASCII	'\001'
04d2c8c83d0e3a Joe Perches 2012-07-30  7  

:::::: The code at line 5 was first introduced by commit
:::::: 04d2c8c83d0e3ac5f78aeede51babb3236200112 printk: convert the format for KERN_<LEVEL> to a 2 byte pattern

:::::: TO: Joe Perches <joe at perches.com>
:::::: CC: Linus Torvalds <torvalds at linux-foundation.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67447 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/8ea28b0f/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 19:16:32 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 02:16:32 +0800
Subject: [arm-platforms:hack/m1-pcie 78/99] drivers/of/address.c:903:10:
 error: implicit declaration of function 'ioremap_np'; did you mean
 'ioremap_wt'?
Message-ID: <202104040229.EkLh34Bb-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 270af822bb6aeba92e99d8b5a6b6645b5dc8ce03 [78/99] of/address: Add infrastructure to declare MMIO as non-posted
config: powerpc-mpc8540_ads_defconfig (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=270af822bb6aeba92e99d8b5a6b6645b5dc8ce03
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 270af822bb6aeba92e99d8b5a6b6645b5dc8ce03
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   drivers/of/address.c: In function 'of_iomap':
>> drivers/of/address.c:903:10: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
     903 |   return ioremap_np(res.start, resource_size(&res));
         |          ^~~~~~~~~~
         |          ioremap_wt
>> drivers/of/address.c:903:10: warning: returning 'int' from a function with return type 'void *' makes pointer from integer without a cast [-Wint-conversion]
     903 |   return ioremap_np(res.start, resource_size(&res));
         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/of/address.c: In function 'of_io_request_and_map':
>> drivers/of/address.c:938:7: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     938 |   mem = ioremap_np(res.start, resource_size(&res));
         |       ^
   cc1: some warnings being treated as errors


vim +903 drivers/of/address.c

   887	
   888	/**
   889	 * of_iomap - Maps the memory mapped IO for a given device_node
   890	 * @np:		the device whose io range will be mapped
   891	 * @index:	index of the io range
   892	 *
   893	 * Returns a pointer to the mapped memory
   894	 */
   895	void __iomem *of_iomap(struct device_node *np, int index)
   896	{
   897		struct resource res;
   898	
   899		if (of_address_to_resource(np, index, &res))
   900			return NULL;
   901	
   902		if (res.flags & IORESOURCE_MEM_NONPOSTED)
 > 903			return ioremap_np(res.start, resource_size(&res));
   904		else
   905			return ioremap(res.start, resource_size(&res));
   906	}
   907	EXPORT_SYMBOL(of_iomap);
   908	
   909	/*
   910	 * of_io_request_and_map - Requests a resource and maps the memory mapped IO
   911	 *			   for a given device_node
   912	 * @device:	the device whose io range will be mapped
   913	 * @index:	index of the io range
   914	 * @name:	name "override" for the memory region request or NULL
   915	 *
   916	 * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
   917	 * error code on failure. Usage example:
   918	 *
   919	 *	base = of_io_request_and_map(node, 0, "foo");
   920	 *	if (IS_ERR(base))
   921	 *		return PTR_ERR(base);
   922	 */
   923	void __iomem *of_io_request_and_map(struct device_node *np, int index,
   924					    const char *name)
   925	{
   926		struct resource res;
   927		void __iomem *mem;
   928	
   929		if (of_address_to_resource(np, index, &res))
   930			return IOMEM_ERR_PTR(-EINVAL);
   931	
   932		if (!name)
   933			name = res.name;
   934		if (!request_mem_region(res.start, resource_size(&res), name))
   935			return IOMEM_ERR_PTR(-EBUSY);
   936	
   937		if (res.flags & IORESOURCE_MEM_NONPOSTED)
 > 938			mem = ioremap_np(res.start, resource_size(&res));
   939		else
   940			mem = ioremap(res.start, resource_size(&res));
   941	
   942		if (!mem) {
   943			release_mem_region(res.start, resource_size(&res));
   944			return IOMEM_ERR_PTR(-ENOMEM);
   945		}
   946	
   947		return mem;
   948	}
   949	EXPORT_SYMBOL(of_io_request_and_map);
   950	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 12600 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/5a00bae3/attachment.gz>

From lkp at intel.com  Sat Apr  3 20:09:04 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 03:09:04 +0800
Subject: [arm-platforms:hack/m1-pcie 12/15] io-pgtable.c:undefined reference
 to `io_pgtable_apple_dart_init_fns'
Message-ID: <202104040302.ZDxaXy5J-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af [12/15] iommu: io-pgtable: add DART pagetable format
config: riscv-randconfig-r003-20210404 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   riscv32-linux-ld: drivers/iommu/io-pgtable.o: in function `.LANCHOR0':
>> io-pgtable.c:(.rodata+0x1c): undefined reference to `io_pgtable_apple_dart_init_fns'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37400 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/ed25cfcc/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 20:26:59 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 03:26:59 +0800
Subject: [arm-platforms:hack/m1-pcie 12/15] or1k-linux-ld:
 drivers/iommu/io-pgtable.o:undefined reference to
 `io_pgtable_apple_dart_init_fns'
Message-ID: <202104040357.a5navdwM-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af [12/15] iommu: io-pgtable: add DART pagetable format
config: openrisc-randconfig-r023-20210403 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 275c6d9c53b68efaf21ec1fd3ee4d1fb9cef87af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=openrisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> or1k-linux-ld: drivers/iommu/io-pgtable.o:(.rodata+0x1c): undefined reference to `io_pgtable_apple_dart_init_fns'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29037 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/98bf7d53/attachment-0001.gz>

From lkp at intel.com  Sat Apr  3 21:39:50 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 04:39:50 +0800
Subject: [arm-platforms:hack/m1-pcie 73/99] lib/devres.c:47:10: error:
 implicit declaration of function 'ioremap_np'
Message-ID: <202104040443.4tNLaw0q-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 8ac84ab8494128c7c12e9e7609c67bc7fb62a428 [73/99] asm-generic/io.h:  Add a non-posted variant of ioremap()
config: powerpc-randconfig-r034-20210403 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 3bcb6a389ff4338d76a25b7d9e0e3c40d84695be)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc cross compiling tool for clang build
        # apt-get install binutils-powerpc-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=8ac84ab8494128c7c12e9e7609c67bc7fb62a428
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 8ac84ab8494128c7c12e9e7609c67bc7fb62a428
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from lib/devres.c:3:
   In file included from include/linux/pci.h:38:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:5:1: note: expanded from here
   __do_insw
   ^
   arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw'
   #define __do_insw(p, b, n)      readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
                                          ~~~~~~~~~~~~~~~~~~~~~^
   In file included from lib/devres.c:3:
   In file included from include/linux/pci.h:38:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:7:1: note: expanded from here
   __do_insl
   ^
   arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl'
   #define __do_insl(p, b, n)      readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
                                          ~~~~~~~~~~~~~~~~~~~~~^
   In file included from lib/devres.c:3:
   In file included from include/linux/pci.h:38:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:9:1: note: expanded from here
   __do_outsb
   ^
   arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb'
   #define __do_outsb(p, b, n)     writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
   In file included from lib/devres.c:3:
   In file included from include/linux/pci.h:38:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:11:1: note: expanded from here
   __do_outsw
   ^
   arch/powerpc/include/asm/io.h:560:58: note: expanded from macro '__do_outsw'
   #define __do_outsw(p, b, n)     writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
   In file included from lib/devres.c:3:
   In file included from include/linux/pci.h:38:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:13:1: note: expanded from here
   __do_outsl
   ^
   arch/powerpc/include/asm/io.h:561:58: note: expanded from macro '__do_outsl'
   #define __do_outsl(p, b, n)     writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
>> lib/devres.c:47:10: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
                   addr = ioremap_np(offset, size);
                          ^
   lib/devres.c:47:10: note: did you mean 'ioremap_wc'?
   arch/powerpc/include/asm/io.h:848:22: note: 'ioremap_wc' declared here
   extern void __iomem *ioremap_wc(phys_addr_t address, unsigned long size);
                        ^
>> lib/devres.c:47:8: warning: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion]
                   addr = ioremap_np(offset, size);
                        ^ ~~~~~~~~~~~~~~~~~~~~~~~~
   13 warnings and 1 error generated.


vim +/ioremap_np +47 lib/devres.c

    25	
    26	static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
    27					    resource_size_t size,
    28					    enum devm_ioremap_type type)
    29	{
    30		void __iomem **ptr, *addr = NULL;
    31	
    32		ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
    33		if (!ptr)
    34			return NULL;
    35	
    36		switch (type) {
    37		case DEVM_IOREMAP:
    38			addr = ioremap(offset, size);
    39			break;
    40		case DEVM_IOREMAP_UC:
    41			addr = ioremap_uc(offset, size);
    42			break;
    43		case DEVM_IOREMAP_WC:
    44			addr = ioremap_wc(offset, size);
    45			break;
    46		case DEVM_IOREMAP_NP:
  > 47			addr = ioremap_np(offset, size);
    48			break;
    49		}
    50	
    51		if (addr) {
    52			*ptr = addr;
    53			devres_add(dev, ptr);
    54		} else
    55			devres_free(ptr);
    56	
    57		return addr;
    58	}
    59	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36478 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/33b36e28/attachment-0001.gz>

From arnd at kernel.org  Sat Apr  3 21:56:56 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sat,  3 Apr 2021 22:56:56 +0200
Subject: [GIT PULL] ARM: mvebu: fixes for v5.12 (#1)
In-Reply-To: <87a6qgctit.fsf@BL-laptop>
References: <87a6qgctit.fsf@BL-laptop>
Message-ID: <161748341017.896324.9953024889088248771.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 02 Apr 2021 22:37:30 +0200, Gregory CLEMENT wrote:
> Here is the first pull request for fixes for mvebu for v5.12.
> 
> Gregory
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: 6bf18bbe1999c4ad4875bb7205df70e1037d17cd

       Arnd


From arnd at kernel.org  Sat Apr  3 21:56:57 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sat,  3 Apr 2021 22:56:57 +0200
Subject: [GIT PULL] Allwinner Fixes for 5.12
In-Reply-To: <9df637a0-945e-4469-8e6d-0903cc9d3196.lettre@localhost>
References: <9df637a0-945e-4469-8e6d-0903cc9d3196.lettre@localhost>
Message-ID: <161748340980.896324.15422033544003499472.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 2 Apr 2021 15:36:33 +0200, Maxime Ripard wrote:
> Please pull the following changes for the current release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: d06d82146c3b4b1159b052c6c2e143293ee9f687

       Arnd


From madvenka at linux.microsoft.com  Sun Apr  4 04:29:12 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Sat, 3 Apr 2021 22:29:12 -0500
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210403170159.gegqjrsrg7jshlne@treble>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
Message-ID: <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>



On 4/3/21 12:01 PM, Josh Poimboeuf wrote:
> On Tue, Mar 30, 2021 at 02:09:51PM -0500, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>
>> There are a number of places in kernel code where the stack trace is not
>> reliable. Enhance the unwinder to check for those cases and mark the
>> stack trace as unreliable. Once all of the checks are in place, the unwinder
>> can be used for livepatching.
> 
> This assumes all such places are known.  That's a big assumption, as
> 
> a) hand-written asm code may inadvertantly skip frame pointer setup;
> 
> b) for inline asm which calls a function, the compiler may blindly
>    insert it into a function before the frame pointer setup.
> 
> That's where objtool stack validation would come in.
>    

Yes. I meant that the reliable stack trace in the kernel is necessary. I did
not imply that it was sufficient. Clearly, it is not sufficient. It relies
on the frame pointer being setup correctly for all functions. That has to be
guaranteed by another entity such as objtool.

So, I will improve the wording and make it clear in the next version.

>> Detect EL1 exception frame
>> ==========================
>>
>> EL1 exceptions can happen on any instruction including instructions in
>> the frame pointer prolog or epilog. Depending on where exactly they happen,
>> they could render the stack trace unreliable.
>>
>> Add all of the EL1 exception handlers to special_functions[].
>>
>> 	- el1_sync()
>> 	- el1_irq()
>> 	- el1_error()
>> 	- el1_sync_invalid()
>> 	- el1_irq_invalid()
>> 	- el1_fiq_invalid()
>> 	- el1_error_invalid()
> 
> A possibly more robust alternative would be to somehow mark el1
> exception frames so the unwinder can detect them more generally.
> 
> For example, as described in my previous email, encode the frame pointer
> so the unwinder can detect el1 frames automatically.
> 

Encoding the frame pointer by setting the LSB (like X86) was my first solution.
Mark Rutland NAKed it. His objection was that it would confuse the debuggers
which are expecting the last 4 bits of the frame pointer to be 0. I agree with
this objection.

My problem with the encoding was also that it is not possible to know if the
LSB was set because of encoding or because of stack corruption.

My second attempt was to encode the frame pointer indirectly. That is, make
pt_regs->stackframe the exception frame and use other fields in the pt_regs
(including a frame type encoding field) for verification.

Mark Rutland NAKed it. His objection (if I am rephrasing it correctly) was that
garbage on the stack may accidentally match the values the unwinder checks in
the pt_regs (however unlikely that match might be).

The consensus was that the return PC must be checked against special functions
to recognize those special cases as the special functions are only invoked in
those special contexts and nowhere else.

As an aside, Mark Brown suggested (if I recall correctly) that the exception
functions could be placed in a special exception section so the unwinder can
check a return PC against the section bounds instead of individual functions.
I did consider implementing this. But I needed a way to address FTRACE
trampolines and KPROBE trampolines as well. So, I did not do that.


>> Detect ftrace frame
>> ===================
>>
>> When FTRACE executes at the beginning of a traced function, it creates two
>> frames and calls the tracer function:
>>
>> 	- One frame for the traced function
>>
>> 	- One frame for the caller of the traced function
>>
>> That gives a sensible stack trace while executing in the tracer function.
>> When FTRACE returns to the traced function, the frames are popped and
>> everything is back to normal.
>>
>> However, in cases like live patch, the tracer function redirects execution
>> to a different function. When FTRACE returns, control will go to that target
>> function. A stack trace taken in the tracer function will not show the target
>> function. The target function is the real function that we want to track.
>> So, the stack trace is unreliable.
> 
> I don't think this is a real problem.  Livepatch only checks the stacks
> of blocked tasks (and the task calling into livepatch).  So the
> reliability of unwinding from the livepatch tracer function itself
> (klp_ftrace_handler) isn't a concern since it doesn't sleep.
> 

My thinking was - arch_stack_walk_reliable() should provide a reliable stack trace
and not assume anything about its consumers. It should not assume that livepatch is
the only consumer although it might be. 

Theoretically, there can be a tracer function that calls some kernel function F() that
can go to sleep. Is this not allowed?

Or, F() could call arch_stack_walk_reliable() on the current task for debugging
or tracing purposes. It should still work correctly.

>> To detect FTRACE in a stack trace, add the following to special_functions[]:
>>
>> 	- ftrace_graph_call()
>> 	- ftrace_graph_caller()
>>
>> Please see the diff for a comment that explains why ftrace_graph_call()
>> must be checked.
>>
>> Also, the Function Graph Tracer modifies the return address of a traced
>> function to a return trampoline (return_to_handler()) to gather tracing
>> data on function return. Stack traces taken from the traced function and
>> functions it calls will not show the original caller of the traced function.
>> The unwinder handles this case by getting the original caller from FTRACE.
>>
>> However, stack traces taken from the trampoline itself and functions it calls
>> are unreliable as the original return address may not be available in
>> that context. This is because the trampoline calls FTRACE to gather trace
>> data as well as to obtain the actual return address and FTRACE discards the
>> record of the original return address along the way.
> 
> Again, this shouldn't be a concern because livepatch won't be unwinding
> from a function_graph trampoline unless it got preempted somehow (and
> then the el1 frame would get detected anyway).
> 

Please see previous answer.

>> Add return_to_handler() to special_functions[].
>>
>> Check for kretprobe
>> ===================
>>
>> For functions with a kretprobe set up, probe code executes on entry
>> to the function and replaces the return address in the stack frame with a
>> kretprobe trampoline. Whenever the function returns, control is
>> transferred to the trampoline. The trampoline eventually returns to the
>> original return address.
>>
>> A stack trace taken while executing in the function (or in functions that
>> get called from the function) will not show the original return address.
>> Similarly, a stack trace taken while executing in the trampoline itself
>> (and functions that get called from the trampoline) will not show the
>> original return address. This means that the caller of the probed function
>> will not show. This makes the stack trace unreliable.
>>
>> Add the kretprobe trampoline to special_functions[].
>>
>> FYI, each task contains a task->kretprobe_instances list that can
>> theoretically be consulted to find the orginal return address. But I am
>> not entirely sure how to safely traverse that list for stack traces
>> not on the current process. So, I have taken the easy way out.
> 
> For kretprobes, unwinding from the trampoline or kretprobe handler
> shouldn't be a reliability concern for live patching, for similar
> reasons as above.
> 

Please see previous answer.

> Otherwise, when unwinding from a blocked task which has
> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
> original return address.  Masami has been working on an interface to
> make that possible for x86.  I assume something similar could be done
> for arm64.
> 

OK. Until that is available, this case needs to be addressed.

Madhavan


From madvenka at linux.microsoft.com  Sun Apr  4 04:46:02 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Sat, 3 Apr 2021 22:46:02 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210403155948.ubbgtwmlsdyar7yp@treble>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
 <20210403155948.ubbgtwmlsdyar7yp@treble>
Message-ID: <171fef08-17d3-2c2e-dad8-6caf4c0c7f15@linux.microsoft.com>



On 4/3/21 10:59 AM, Josh Poimboeuf wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>> @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>>  #endif
>>  	bl	switch_to_vhe			// Prefer VHE if possible
>>  	add	sp, sp, #16
>> -	mov	x29, #0
>> -	mov	x30, #0
>> -	b	start_kernel
>> +	setup_final_frame
>> +	bl	start_kernel
>> +	nop
>>  SYM_FUNC_END(__primary_switched)
>>  
>>  	.pushsection ".rodata", "a"
>> @@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
>>  	cbz	x2, __secondary_too_slow
>>  	msr	sp_el0, x2
>>  	scs_load x2, x3
>> -	mov	x29, #0
>> -	mov	x30, #0
>> +	setup_final_frame
>>  
>>  #ifdef CONFIG_ARM64_PTR_AUTH
>>  	ptrauth_keys_init_cpu x2, x3, x4, x5
>>  #endif
>>  
>> -	b	secondary_start_kernel
>> +	bl	secondary_start_kernel
>> +	nop
>>  SYM_FUNC_END(__secondary_switched)
> 
> I'm somewhat arm-ignorant, so take the following comments with a grain
> of salt.
> 
> 
> I don't think changing these to 'bl' is necessary, unless you wanted
> __primary_switched() and __secondary_switched() to show up in the
> stacktrace for some reason?  If so, that seems like a separate patch.
> 

The problem is with __secondary_switched. If you trace the code back to where
a secondary CPU is started, I don't see any calls anywhere. There are only
branches if I am not mistaken. So, the return address register never gets
set up with a proper address. The stack trace shows some hexadecimal value
instead of a symbol name.

On ARM64, the call instruction is actually a branch instruction IIUC. The
only extra thing it does is to load the link register (return address register)
with the return address. That is all.

Instead of the link register pointing to some arbitrary code in startup that
did not call start_kernel() or secondary_start_kernel(), I wanted to set it
up as shown above.

> 
> Also, why are nops added after the calls?  My guess would be because,
> since these are basically tail calls to "noreturn" functions, the stack
> dump code would otherwise show the wrong function, i.e. whatever
> function happens to be after the 'bl'.
> 

That is correct. The stack trace shows something arbitrary.

> We had the same issue for x86.  It can be fixed by using '%pB' instead
> of '%pS' when printing the address in dump_backtrace_entry().  See
> sprint_backtrace() for more details.
> 
> BTW I think the same issue exists for GCC-generated code.  The following
> shows several such cases:
> 
>   objdump -dr vmlinux |awk '/bl   / {bl=1;l=$0;next} bl == 1 && /^$/ {print l; print} // {bl=0}'
> 
> 
> However, looking at how arm64 unwinds through exceptions in kernel
> space, using '%pB' might have side effects when the exception LR
> (elr_el1) points to the beginning of a function.  Then '%pB' would show
> the end of the previous function, instead of the function which was
> interrupted.
> 
> So you may need to rethink how to unwind through in-kernel exceptions.
> 
> Basically, when printing a stack return address, you want to use '%pB'
> for a call return address and '%pS' for an interrupted address.
> 
> On x86, with the frame pointer unwinder, we encode the frame pointer by
> setting a bit in %rbp which tells the unwinder that it's a special
> pt_regs frame.  Then instead of treating it like a normal call frame,
> the stack dump code prints the registers, and the return address
> (regs->ip) gets printed with '%pS'.
> 

Yes. But there are objections to that kind of encoding.

Having the nop above does not do any harm. It just adds 4 bytes to the function text.
I would rather keep this simple right now because this is only for getting a sensible
stack trace for idle tasks.

Is there any other problem that you can see?

>>  SYM_FUNC_START_LOCAL(__secondary_too_slow)
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 325c83b1a24d..906baa232a89 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -437,6 +437,11 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>>  	}
>>  	p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>>  	p->thread.cpu_context.sp = (unsigned long)childregs;
>> +	/*
>> +	 * For the benefit of the unwinder, set up childregs->stackframe
>> +	 * as the final frame for the new task.
>> +	 */
>> +	p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
>>  
>>  	ptrace_hw_copy_thread(p);
>>  
>> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
>> index ad20981dfda4..72f5af8c69dc 100644
>> --- a/arch/arm64/kernel/stacktrace.c
>> +++ b/arch/arm64/kernel/stacktrace.c
>> @@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>>  	unsigned long fp = frame->fp;
>>  	struct stack_info info;
>>  
>> -	/* Terminal record; nothing to unwind */
>> -	if (!fp)
>> +	if (!tsk)
>> +		tsk = current;
>> +
>> +	/* Final frame; nothing to unwind */
>> +	if (fp == (unsigned long) task_pt_regs(tsk)->stackframe)
>>  		return -ENOENT;
> 
> As far as I can tell, the regs stackframe value is initialized to zero
> during syscall entry, so isn't this basically just 'if (fp == 0)'?
> 
> Shouldn't it instead be comparing with the _address_ of the stackframe
> field to make sure it reached the end?
> 

pt_regs->stackframe is an array of two u64 elements- one for FP and one for
PC. So, I am comparing the address and not the value of FP.

        u64 stackframe[2];

Madhavan


From lkp at intel.com  Sun Apr  4 05:38:04 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 12:38:04 +0800
Subject: [arm-platforms:hack/m1-pcie 83/99] dtbs_check:
 arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: framebuffer@1fc00000:
 compatible:0: 'simple-framebuffer' is not one of
 ['apple,simple-framebuffer', 'allwinner,simple-framebuffer',
 'amlogic,simple-framebuffer']
Message-ID: <202104041201.P5uuKKFk-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 851b95bf6ed3f38984dbeb228531dd2be63f9b44 [83/99] dt-bindings: display: Add apple,simple-framebuffer
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce: make ARCH=arm dtbs_check

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


dtcheck warnings: (new ones prefixed by >>)
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: audio-controller at d42a0c00: port:endpoint:frame-master: True is not of type 'array'
   	From schema: Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: audio-controller at d42a0c00: port:endpoint:bitclock-master: True is not of type 'array'
   	From schema: Documentation/devicetree/bindings/sound/marvell,mmp-sspa.yaml
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: accelerometer at 1d: compatible:0: 'st,lis331dlh' is not one of ['st,lis3lv02d', 'st,lis302dl-spi', 'st,lis3lv02dl-accel', 'st,lsm303dlh-accel', 'st,lsm303dlhc-accel', 'st,lis3dh-accel', 'st,lsm330d-accel', 'st,lsm330dl-accel', 'st,lsm330dlc-accel', 'st,lis331dl-accel', 'st,lis331dlh-accel', 'st,lsm303dl-accel', 'st,lsm303dlm-accel', 'st,lsm330-accel', 'st,lsm303agr-accel', 'st,lis2dh12-accel', 'st,h3lis331dl-accel', 'st,lng2dm-accel', 'st,lis3l02dq', 'st,lis2dw12', 'st,lis3dhh', 'st,lis3de', 'st,lis2de12', 'st,lis2hh12', 'st,l3g4200d-gyro', 'st,lsm330d-gyro', 'st,lsm330dl-gyro', 'st,lsm330dlc-gyro', 'st,l3gd20-gyro', 'st,l3gd20h-gyro', 'st,l3g4is-gyro', 'st,lsm330-gyro', 'st,lsm9ds0-gyro', 'st,lsm303agr-magn', 'st,lsm303dlh-magn', 'st,lsm303dlhc-magn', 'st,lsm303dlm-magn', 'st,lis3mdl-magn', 'st,lis2mdl', 'st,lsm9ds1-magn', 'st,lps001wp-press', 'st,lps25h-press', 'st,lps331ap-press', 'st,lps22hb-press', 'st,lps33hw', 'st,lps35hw', 'st,lps22hh']
   	From schema: Documentation/devicetree/bindings/iio/st,st-sensors.yaml
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: accelerometer at 1d: compatible: ['st,lis331dlh', 'st,lis3lv02d'] is too long
   	From schema: Documentation/devicetree/bindings/iio/st,st-sensors.yaml
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: accelerometer at 1d: compatible: Additional items are not allowed ('st,lis3lv02d' was unexpected)
   	From schema: Documentation/devicetree/bindings/iio/st,st-sensors.yaml
>> arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: framebuffer at 1fc00000: compatible:0: 'simple-framebuffer' is not one of ['apple,simple-framebuffer', 'allwinner,simple-framebuffer', 'amlogic,simple-framebuffer']
   	From schema: Documentation/devicetree/bindings/display/simple-framebuffer.yaml
   arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: framebuffer at 1fc00000: compatible: ['simple-framebuffer'] is too short
   	From schema: Documentation/devicetree/bindings/display/simple-framebuffer.yaml

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From madvenka at linux.microsoft.com  Sun Apr  4 05:40:51 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Sat, 3 Apr 2021 23:40:51 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <171fef08-17d3-2c2e-dad8-6caf4c0c7f15@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
 <20210403155948.ubbgtwmlsdyar7yp@treble>
 <171fef08-17d3-2c2e-dad8-6caf4c0c7f15@linux.microsoft.com>
Message-ID: <49790505-f611-b4a2-c804-b779060601a9@linux.microsoft.com>



On 4/3/21 10:46 PM, Madhavan T. Venkataraman wrote:
>> I'm somewhat arm-ignorant, so take the following comments with a grain
>> of salt.
>>
>>
>> I don't think changing these to 'bl' is necessary, unless you wanted
>> __primary_switched() and __secondary_switched() to show up in the
>> stacktrace for some reason?  If so, that seems like a separate patch.
>>
> The problem is with __secondary_switched. If you trace the code back to where
> a secondary CPU is started, I don't see any calls anywhere. There are only
> branches if I am not mistaken. So, the return address register never gets
> set up with a proper address. The stack trace shows some hexadecimal value
> instead of a symbol name.
> 

Actually, I take that back. There are calls in that code path. But I did only
see some hexadecimal value instead of a proper address in the stack trace.
Sorry about that confusion.

My reason to convert the branches to calls is this - the value of the return
address register at that point is the return PC of the previous branch and link
instruction wherever that happens to be. I think that is a little arbitrary.

Instead, if I call start_kernel() and secondary_start_kernel(), the return address
gets set up to the next instruction which, IMHO, is better.

But I am open to other suggestions.

Madhavan


From lkp at intel.com  Sun Apr  4 08:48:17 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 4 Apr 2021 15:48:17 +0800
Subject: [arm-platforms:hack/m1-pcie 77/99] include/linux/io.h:98:22: error:
 implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'?
Message-ID: <202104041510.yaj00RnT-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 3364619d8489baef060f4ac9c71ae25c128ae820 [77/99] asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
config: powerpc-randconfig-c024-20210403 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=3364619d8489baef060f4ac9c71ae25c128ae820
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms hack/m1-pcie
        git checkout 3364619d8489baef060f4ac9c71ae25c128ae820
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/irq.h:20,
                    from arch/powerpc/include/asm/hardirq.h:6,
                    from include/linux/hardirq.h:10,
                    from include/linux/interrupt.h:11,
                    from include/linux/kernel_stat.h:9,
                    from include/linux/cgroup.h:26,
                    from include/linux/memcontrol.h:13,
                    from include/linux/swap.h:9,
                    from include/linux/suspend.h:5,
                    from arch/powerpc/kernel/asm-offsets.c:23:
   include/linux/io.h: In function 'pci_remap_cfgspace':
>> include/linux/io.h:98:22: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
      98 |  void __iomem *ret = ioremap_np(offset, size);
         |                      ^~~~~~~~~~
         |                      ioremap_wt
>> include/linux/io.h:98:22: warning: initialization of 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   cc1: some warnings being treated as errors
--
   In file included from include/linux/irq.h:20,
                    from arch/powerpc/include/asm/hardirq.h:6,
                    from include/linux/hardirq.h:10,
                    from include/linux/interrupt.h:11,
                    from include/linux/kernel_stat.h:9,
                    from include/linux/cgroup.h:26,
                    from include/linux/memcontrol.h:13,
                    from include/linux/swap.h:9,
                    from include/linux/suspend.h:5,
                    from arch/powerpc/kernel/asm-offsets.c:23:
   include/linux/io.h: In function 'pci_remap_cfgspace':
>> include/linux/io.h:98:22: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
      98 |  void __iomem *ret = ioremap_np(offset, size);
         |                      ^~~~~~~~~~
         |                      ioremap_wt
>> include/linux/io.h:98:22: warning: initialization of 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   cc1: some warnings being treated as errors
   make[2]: *** [scripts/Makefile.build:116: arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1235: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +98 include/linux/io.h

    81	
    82	#ifdef CONFIG_PCI
    83	/*
    84	 * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
    85	 * Posting") mandate non-posted configuration transactions. This default
    86	 * implementation attempts to use the ioremap_np() API to provide this
    87	 * on arches that support it, and falls back to ioremap() on those that
    88	 * don't. Overriding this function is deprecated; arches that properly
    89	 * support non-posted accesses should implement ioremap_np() instead, which
    90	 * this default implementation can then use to return mappings compliant with
    91	 * the PCI specification.
    92	 */
    93	#ifndef pci_remap_cfgspace
    94	#define pci_remap_cfgspace pci_remap_cfgspace
    95	static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
    96						       size_t size)
    97	{
  > 98		void __iomem *ret = ioremap_np(offset, size);
    99	
   100		if (!ret)
   101			ret = ioremap(offset, size);
   102	
   103		return ret;
   104	}
   105	#endif
   106	#endif
   107	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30543 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/212dec63/attachment-0001.gz>

From lkp at intel.com  Sun Apr  4 10:57:26 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 04 Apr 2021 17:57:26 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS 6bf18bbe1999c4ad4875bb7205df70e1037d17cd
Message-ID: <60698d86.lrGG43EWVp+V+G1+%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: 6bf18bbe1999c4ad4875bb7205df70e1037d17cd  Merge tag 'mvebu-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes

elapsed time: 721m

configs tested: 113
configs skipped: 22

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                        apsh4ad0a_defconfig
arm                        vexpress_defconfig
powerpc64                        alldefconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                     kilauea_defconfig
xtensa                  nommu_kc705_defconfig
arm                       aspeed_g5_defconfig
sh                        dreamcast_defconfig
ia64                             alldefconfig
arm                        oxnas_v6_defconfig
arm                         orion5x_defconfig
powerpc                     redwood_defconfig
sh                        edosk7760_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
s390                          debug_defconfig
arm                           viper_defconfig
xtensa                  cadence_csp_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7269_defconfig
sh                           se7751_defconfig
mips                        omega2p_defconfig
arm                        mvebu_v7_defconfig
um                            kunit_defconfig
sh                           se7705_defconfig
mips                     decstation_defconfig
powerpc                      ppc64e_defconfig
arm                        multi_v5_defconfig
arm                         nhk8815_defconfig
m68k                          amiga_defconfig
ia64                          tiger_defconfig
csky                                defconfig
m68k                            q40_defconfig
powerpc                 mpc8560_ads_defconfig
arm                           h5000_defconfig
sh                           se7619_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         shannon_defconfig
arm                         hackkit_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     powernv_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210404
x86_64               randconfig-a003-20210404
x86_64               randconfig-a005-20210404
x86_64               randconfig-a001-20210404
x86_64               randconfig-a002-20210404
x86_64               randconfig-a006-20210404
i386                 randconfig-a006-20210404
i386                 randconfig-a003-20210404
i386                 randconfig-a001-20210404
i386                 randconfig-a004-20210404
i386                 randconfig-a005-20210404
i386                 randconfig-a002-20210404
i386                 randconfig-a014-20210404
i386                 randconfig-a016-20210404
i386                 randconfig-a011-20210404
i386                 randconfig-a012-20210404
i386                 randconfig-a015-20210404
i386                 randconfig-a013-20210404
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210404
x86_64               randconfig-a015-20210404
x86_64               randconfig-a013-20210404
x86_64               randconfig-a011-20210404
x86_64               randconfig-a012-20210404
x86_64               randconfig-a016-20210404

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From julia.lawall at inria.fr  Sun Apr  4 16:26:19 2021
From: julia.lawall at inria.fr (Julia Lawall)
Date: Sun, 4 Apr 2021 17:26:19 +0200 (CEST)
Subject: [PATCH] iommu: dart: fix call_kern.cocci warnings
Message-ID: <alpine.DEB.2.22.394.2104041724340.2958@hadrien>

From: kernel test robot <lkp at intel.com>

Function apple_dart_attach_stream called on line 519 inside
lock on line 509 but uses GFP_KERNEL

Generated by: scripts/coccinelle/locks/call_kern.cocci

Fixes: ce67d3b3ef37 ("iommu: dart: Add DART iommu driver")
CC: Sven Peter <sven at svenpeter.dev>
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: kernel test robot <lkp at intel.com>
Signed-off-by: Julia Lawall <julia.lawall at inria.fr>
---

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: ce67d3b3ef3734925631ec65deb1cf8078d826cf [14/15] iommu: dart: Add DART iommu driver
:::::: branch date: 8 hours ago
:::::: commit date: 8 hours ago

Please take the patch only if it's a positive warning. Thanks!

 apple-dart-iommu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/iommu/apple-dart-iommu.c
+++ b/drivers/iommu/apple-dart-iommu.c
@@ -435,7 +435,7 @@ static int apple_dart_attach_stream(stru
 		goto error;
 	}

-	stream = kzalloc(sizeof(*stream), GFP_KERNEL);
+	stream = kzalloc(sizeof(*stream), GFP_ATOMIC);
 	if (!stream) {
 		ret = -ENOMEM;
 		goto error;


From julia.lawall at inria.fr  Sun Apr  4 16:27:30 2021
From: julia.lawall at inria.fr (Julia Lawall)
Date: Sun, 4 Apr 2021 17:27:30 +0200 (CEST)
Subject: [arm-platforms:hack/m1-pcie 10/15]
 drivers/pci/controller/pcie-apple-m1.c:60:45-46:
 irq_set_affinity: first occurrence line 64, second occurrence line 66
 (fwd)
Message-ID: <alpine.DEB.2.22.394.2104041726390.2958@hadrien>

The field .irq_set_affinity is initialized twice, both times to the same
value.

julia

---------- Forwarded message ----------
Date: Sun, 4 Apr 2021 10:34:39 +0800
From: kernel test robot <lkp at intel.com>
To: kbuild at lists.01.org
Cc: lkp at intel.com, Julia Lawall <julia.lawall at lip6.fr>
Subject: [arm-platforms:hack/m1-pcie 10/15]
    drivers/pci/controller/pcie-apple-m1.c:60:45-46: irq_set_affinity: first
    occurrence line 64, second occurrence line 66

CC: kbuild-all at lists.01.org
CC: linux-arm-kernel at lists.infradead.org
TO: Marc Zyngier <maz at kernel.org>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git hack/m1-pcie
head:   1fd2c9634dd24fba323baba52200de18e4d3f4ee
commit: 4506277b9030202811e5c671330c1ac9b1d3a0b0 [10/15] M1 PCIe hacks
:::::: branch date: 16 hours ago
:::::: commit date: 16 hours ago
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Julia Lawall <julia.lawall at lip6.fr>


cocci warnings: (new ones prefixed by >>)
>> drivers/pci/controller/pcie-apple-m1.c:60:45-46: irq_set_affinity: first occurrence line 64, second occurrence line 66

vim +60 drivers/pci/controller/pcie-apple-m1.c

4506277b9030202 Marc Zyngier 2021-03-29  59
4506277b9030202 Marc Zyngier 2021-03-29 @60  static struct irq_chip apple_msi_bottom_chip = {
4506277b9030202 Marc Zyngier 2021-03-29  61  	.name			= "MSI",
4506277b9030202 Marc Zyngier 2021-03-29  62  	.irq_mask		= irq_chip_mask_parent,
4506277b9030202 Marc Zyngier 2021-03-29  63  	.irq_unmask		= irq_chip_unmask_parent,
4506277b9030202 Marc Zyngier 2021-03-29 @64  	.irq_set_affinity 	= irq_chip_set_affinity_parent,
4506277b9030202 Marc Zyngier 2021-03-29  65  	.irq_eoi		= irq_chip_eoi_parent,
4506277b9030202 Marc Zyngier 2021-03-29 @66  	.irq_set_affinity	= irq_chip_set_affinity_parent,
4506277b9030202 Marc Zyngier 2021-03-29  67  	.irq_set_type		= irq_chip_set_type_parent,
4506277b9030202 Marc Zyngier 2021-03-29  68  	.irq_compose_msi_msg	= apple_msi_compose_msg,
4506277b9030202 Marc Zyngier 2021-03-29  69  };
4506277b9030202 Marc Zyngier 2021-03-29  70

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 65044 bytes
Desc: 
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210404/63fd8fe3/attachment-0001.gz>

From bjorn.andersson at linaro.org  Sun Apr  4 16:56:04 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sun,  4 Apr 2021 10:56:04 -0500
Subject: [GIT PULL] Qualcomm fix for 5.12
Message-ID: <20210404155604.712236-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-fixes-for-5.12

for you to fetch changes up to 0c9fdcdba68208270ae85d39600ea97da1718344:

  soc: qcom: geni: shield geni_icc_get() for ACPI boot (2021-03-11 20:22:05 -0600)

----------------------------------------------------------------
Qualcomm fix for 5.12

This bypasses the, recently introduced, interconnect handling in the
GENI (serial engine) driver when running off ACPI, as this causes the
GENI probe to fail and the Lenovo Yoga C630 to boot without keyboard and
touchpad.

----------------------------------------------------------------
Shawn Guo (1):
      soc: qcom: geni: shield geni_icc_get() for ACPI boot

 drivers/soc/qcom/qcom-geni-se.c | 3 +++
 1 file changed, 3 insertions(+)


From lkp at intel.com  Sun Apr  4 17:19:09 2021
From: lkp at intel.com (kernel test robot)
Date: Mon, 5 Apr 2021 00:19:09 +0800
Subject: [arm-platforms:irq/domain_cleanup 8/12]
 arch/powerpc/sysdev/ehv_pic.c:184:32: error: initialization of 'struct
 device_node *' from 'int' makes pointer from integer without a cast
Message-ID: <202104050005.llW0lwg9-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/domain_cleanup
head:   550eec9280bbaf3704f847777e7a1468d9ed8db0
commit: 702ba25bbe5e01f95ee505140cbf6ab97044e881 [8/12] powerpc: Convert irq_domain_add_legacy_isa use to irq_domain_add_legacy
config: powerpc-ppc64e_defconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=702ba25bbe5e01f95ee505140cbf6ab97044e881
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms irq/domain_cleanup
        git checkout 702ba25bbe5e01f95ee505140cbf6ab97044e881
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   arch/powerpc/sysdev/ehv_pic.c:44:6: error: no previous prototype for 'ehv_pic_unmask_irq' [-Werror=missing-prototypes]
      44 | void ehv_pic_unmask_irq(struct irq_data *d)
         |      ^~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:51:6: error: no previous prototype for 'ehv_pic_mask_irq' [-Werror=missing-prototypes]
      51 | void ehv_pic_mask_irq(struct irq_data *d)
         |      ^~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:58:6: error: no previous prototype for 'ehv_pic_end_irq' [-Werror=missing-prototypes]
      58 | void ehv_pic_end_irq(struct irq_data *d)
         |      ^~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:65:6: error: no previous prototype for 'ehv_pic_direct_end_irq' [-Werror=missing-prototypes]
      65 | void ehv_pic_direct_end_irq(struct irq_data *d)
         |      ^~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:70:5: error: no previous prototype for 'ehv_pic_set_affinity' [-Werror=missing-prototypes]
      70 | int ehv_pic_set_affinity(struct irq_data *d, const struct cpumask *dest,
         |     ^~~~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:111:5: error: no previous prototype for 'ehv_pic_set_irq_type' [-Werror=missing-prototypes]
     111 | int ehv_pic_set_irq_type(struct irq_data *d, unsigned int flow_type)
         |     ^~~~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c: In function 'ehv_pic_get_irq':
>> arch/powerpc/sysdev/ehv_pic.c:177:9: error: implicit declaration of function 'irq_linear_revmap' [-Werror=implicit-function-declaration]
     177 |  return irq_linear_revmap(global_ehv_pic->irqhost, irq);
         |         ^~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c: At top level:
   arch/powerpc/sysdev/ehv_pic.c:181:15: error: 'enum irq_domain_bus_token' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
     181 |          enum irq_domain_bus_token bus_token)
         |               ^~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/sysdev/ehv_pic.c:181:36: error: parameter 3 ('bus_token') has incomplete type
     181 |          enum irq_domain_bus_token bus_token)
         |          ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
>> arch/powerpc/sysdev/ehv_pic.c:180:12: error: function declaration isn't a prototype [-Werror=strict-prototypes]
     180 | static int ehv_pic_host_match(struct irq_domain *h, struct device_node *node,
         |            ^~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c: In function 'ehv_pic_host_match':
>> arch/powerpc/sysdev/ehv_pic.c:184:32: error: implicit declaration of function 'irq_domain_get_of_node'; did you mean 'irq_data_get_node'? [-Werror=implicit-function-declaration]
     184 |  struct device_node *of_node = irq_domain_get_of_node(h);
         |                                ^~~~~~~~~~~~~~~~~~~~~~
         |                                irq_data_get_node
>> arch/powerpc/sysdev/ehv_pic.c:184:32: error: initialization of 'struct device_node *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
   arch/powerpc/sysdev/ehv_pic.c: In function 'ehv_pic_host_map':
>> arch/powerpc/sysdev/ehv_pic.c:191:29: error: dereferencing pointer to incomplete type 'struct irq_domain'
     191 |  struct ehv_pic *ehv_pic = h->host_data;
         |                             ^~
   arch/powerpc/sysdev/ehv_pic.c: At top level:
>> arch/powerpc/sysdev/ehv_pic.c:248:21: error: variable 'ehv_pic_host_ops' has initializer but incomplete type
     248 | static const struct irq_domain_ops ehv_pic_host_ops = {
         |                     ^~~~~~~~~~~~~~
>> arch/powerpc/sysdev/ehv_pic.c:249:3: error: 'const struct irq_domain_ops' has no member named 'match'
     249 |  .match = ehv_pic_host_match,
         |   ^~~~~
   arch/powerpc/sysdev/ehv_pic.c:249:11: error: excess elements in struct initializer [-Werror]
     249 |  .match = ehv_pic_host_match,
         |           ^~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:249:11: note: (near initialization for 'ehv_pic_host_ops')
>> arch/powerpc/sysdev/ehv_pic.c:250:3: error: 'const struct irq_domain_ops' has no member named 'map'
     250 |  .map = ehv_pic_host_map,
         |   ^~~
   arch/powerpc/sysdev/ehv_pic.c:250:9: error: excess elements in struct initializer [-Werror]
     250 |  .map = ehv_pic_host_map,
         |         ^~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:250:9: note: (near initialization for 'ehv_pic_host_ops')
>> arch/powerpc/sysdev/ehv_pic.c:251:3: error: 'const struct irq_domain_ops' has no member named 'xlate'
     251 |  .xlate = ehv_pic_host_xlate,
         |   ^~~~~
   arch/powerpc/sysdev/ehv_pic.c:251:11: error: excess elements in struct initializer [-Werror]
     251 |  .xlate = ehv_pic_host_xlate,
         |           ^~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c:251:11: note: (near initialization for 'ehv_pic_host_ops')
   arch/powerpc/sysdev/ehv_pic.c: In function 'ehv_pic_init':
>> arch/powerpc/sysdev/ehv_pic.c:275:21: error: implicit declaration of function 'irq_domain_add_linear' [-Werror=implicit-function-declaration]
     275 |  ehv_pic->irqhost = irq_domain_add_linear(np, NR_EHV_PIC_INTS,
         |                     ^~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/sysdev/ehv_pic.c:275:19: error: assignment to 'struct irq_domain *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
     275 |  ehv_pic->irqhost = irq_domain_add_linear(np, NR_EHV_PIC_INTS,
         |                   ^
>> arch/powerpc/sysdev/ehv_pic.c:297:2: error: implicit declaration of function 'irq_set_default_host' [-Werror=implicit-function-declaration]
     297 |  irq_set_default_host(global_ehv_pic->irqhost);
         |  ^~~~~~~~~~~~~~~~~~~~
   arch/powerpc/sysdev/ehv_pic.c: At top level:
>> arch/powerpc/sysdev/ehv_pic.c:248:36: error: storage size of 'ehv_pic_host_ops' isn't known
     248 | static const struct irq_domain_ops ehv_pic_host_ops = {
         |                                    ^~~~~~~~~~~~~~~~
   cc1: all warnings being treated as errors


vim +184 arch/powerpc/sysdev/ehv_pic.c

3a93261f70c7b9 Ashish Kalra      2011-05-19   69  
3a93261f70c7b9 Ashish Kalra      2011-05-19  @70  int ehv_pic_set_affinity(struct irq_data *d, const struct cpumask *dest,
3a93261f70c7b9 Ashish Kalra      2011-05-19   71  			 bool force)
3a93261f70c7b9 Ashish Kalra      2011-05-19   72  {
3a93261f70c7b9 Ashish Kalra      2011-05-19   73  	unsigned int src = virq_to_hw(d->irq);
3a93261f70c7b9 Ashish Kalra      2011-05-19   74  	unsigned int config, prio, cpu_dest;
3a93261f70c7b9 Ashish Kalra      2011-05-19   75  	int cpuid = irq_choose_cpu(dest);
3a93261f70c7b9 Ashish Kalra      2011-05-19   76  	unsigned long flags;
3a93261f70c7b9 Ashish Kalra      2011-05-19   77  
3a93261f70c7b9 Ashish Kalra      2011-05-19   78  	spin_lock_irqsave(&ehv_pic_lock, flags);
3a93261f70c7b9 Ashish Kalra      2011-05-19   79  	ev_int_get_config(src, &config, &prio, &cpu_dest);
3a93261f70c7b9 Ashish Kalra      2011-05-19   80  	ev_int_set_config(src, config, prio, cpuid);
3a93261f70c7b9 Ashish Kalra      2011-05-19   81  	spin_unlock_irqrestore(&ehv_pic_lock, flags);
3a93261f70c7b9 Ashish Kalra      2011-05-19   82  
dcb615aef988b5 Alexander Gordeev 2013-05-13   83  	return IRQ_SET_MASK_OK;
3a93261f70c7b9 Ashish Kalra      2011-05-19   84  }
3a93261f70c7b9 Ashish Kalra      2011-05-19   85  
3a93261f70c7b9 Ashish Kalra      2011-05-19   86  static unsigned int ehv_pic_type_to_vecpri(unsigned int type)
3a93261f70c7b9 Ashish Kalra      2011-05-19   87  {
3a93261f70c7b9 Ashish Kalra      2011-05-19   88  	/* Now convert sense value */
3a93261f70c7b9 Ashish Kalra      2011-05-19   89  
3a93261f70c7b9 Ashish Kalra      2011-05-19   90  	switch (type & IRQ_TYPE_SENSE_MASK) {
3a93261f70c7b9 Ashish Kalra      2011-05-19   91  	case IRQ_TYPE_EDGE_RISING:
3a93261f70c7b9 Ashish Kalra      2011-05-19   92  		return EHV_PIC_INFO(VECPRI_SENSE_EDGE) |
3a93261f70c7b9 Ashish Kalra      2011-05-19   93  		       EHV_PIC_INFO(VECPRI_POLARITY_POSITIVE);
3a93261f70c7b9 Ashish Kalra      2011-05-19   94  
3a93261f70c7b9 Ashish Kalra      2011-05-19   95  	case IRQ_TYPE_EDGE_FALLING:
3a93261f70c7b9 Ashish Kalra      2011-05-19   96  	case IRQ_TYPE_EDGE_BOTH:
3a93261f70c7b9 Ashish Kalra      2011-05-19   97  		return EHV_PIC_INFO(VECPRI_SENSE_EDGE) |
3a93261f70c7b9 Ashish Kalra      2011-05-19   98  		       EHV_PIC_INFO(VECPRI_POLARITY_NEGATIVE);
3a93261f70c7b9 Ashish Kalra      2011-05-19   99  
3a93261f70c7b9 Ashish Kalra      2011-05-19  100  	case IRQ_TYPE_LEVEL_HIGH:
3a93261f70c7b9 Ashish Kalra      2011-05-19  101  		return EHV_PIC_INFO(VECPRI_SENSE_LEVEL) |
3a93261f70c7b9 Ashish Kalra      2011-05-19  102  		       EHV_PIC_INFO(VECPRI_POLARITY_POSITIVE);
3a93261f70c7b9 Ashish Kalra      2011-05-19  103  
3a93261f70c7b9 Ashish Kalra      2011-05-19  104  	case IRQ_TYPE_LEVEL_LOW:
3a93261f70c7b9 Ashish Kalra      2011-05-19  105  	default:
3a93261f70c7b9 Ashish Kalra      2011-05-19  106  		return EHV_PIC_INFO(VECPRI_SENSE_LEVEL) |
3a93261f70c7b9 Ashish Kalra      2011-05-19  107  		       EHV_PIC_INFO(VECPRI_POLARITY_NEGATIVE);
3a93261f70c7b9 Ashish Kalra      2011-05-19  108  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  109  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  110  
3a93261f70c7b9 Ashish Kalra      2011-05-19  111  int ehv_pic_set_irq_type(struct irq_data *d, unsigned int flow_type)
3a93261f70c7b9 Ashish Kalra      2011-05-19  112  {
3a93261f70c7b9 Ashish Kalra      2011-05-19  113  	unsigned int src = virq_to_hw(d->irq);
3a93261f70c7b9 Ashish Kalra      2011-05-19  114  	unsigned int vecpri, vold, vnew, prio, cpu_dest;
3a93261f70c7b9 Ashish Kalra      2011-05-19  115  	unsigned long flags;
3a93261f70c7b9 Ashish Kalra      2011-05-19  116  
3a93261f70c7b9 Ashish Kalra      2011-05-19  117  	if (flow_type == IRQ_TYPE_NONE)
3a93261f70c7b9 Ashish Kalra      2011-05-19  118  		flow_type = IRQ_TYPE_LEVEL_LOW;
3a93261f70c7b9 Ashish Kalra      2011-05-19  119  
c866cda47f2c6c Thomas Gleixner   2014-02-23  120  	irqd_set_trigger_type(d, flow_type);
3a93261f70c7b9 Ashish Kalra      2011-05-19  121  
3a93261f70c7b9 Ashish Kalra      2011-05-19  122  	vecpri = ehv_pic_type_to_vecpri(flow_type);
3a93261f70c7b9 Ashish Kalra      2011-05-19  123  
3a93261f70c7b9 Ashish Kalra      2011-05-19  124  	spin_lock_irqsave(&ehv_pic_lock, flags);
3a93261f70c7b9 Ashish Kalra      2011-05-19  125  	ev_int_get_config(src, &vold, &prio, &cpu_dest);
3a93261f70c7b9 Ashish Kalra      2011-05-19  126  	vnew = vold & ~(EHV_PIC_INFO(VECPRI_POLARITY_MASK) |
3a93261f70c7b9 Ashish Kalra      2011-05-19  127  			EHV_PIC_INFO(VECPRI_SENSE_MASK));
3a93261f70c7b9 Ashish Kalra      2011-05-19  128  	vnew |= vecpri;
3a93261f70c7b9 Ashish Kalra      2011-05-19  129  
3a93261f70c7b9 Ashish Kalra      2011-05-19  130  	/*
3a93261f70c7b9 Ashish Kalra      2011-05-19  131  	 * TODO : Add specific interface call for platform to set
3a93261f70c7b9 Ashish Kalra      2011-05-19  132  	 * individual interrupt priorities.
3a93261f70c7b9 Ashish Kalra      2011-05-19  133  	 * platform currently using static/default priority for all ints
3a93261f70c7b9 Ashish Kalra      2011-05-19  134  	 */
3a93261f70c7b9 Ashish Kalra      2011-05-19  135  
3a93261f70c7b9 Ashish Kalra      2011-05-19  136  	prio = 8;
3a93261f70c7b9 Ashish Kalra      2011-05-19  137  
3a93261f70c7b9 Ashish Kalra      2011-05-19  138  	ev_int_set_config(src, vecpri, prio, cpu_dest);
3a93261f70c7b9 Ashish Kalra      2011-05-19  139  
3a93261f70c7b9 Ashish Kalra      2011-05-19  140  	spin_unlock_irqrestore(&ehv_pic_lock, flags);
c866cda47f2c6c Thomas Gleixner   2014-02-23  141  	return IRQ_SET_MASK_OK_NOCOPY;
3a93261f70c7b9 Ashish Kalra      2011-05-19  142  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  143  
3a93261f70c7b9 Ashish Kalra      2011-05-19  144  static struct irq_chip ehv_pic_irq_chip = {
3a93261f70c7b9 Ashish Kalra      2011-05-19  145  	.irq_mask	= ehv_pic_mask_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  146  	.irq_unmask	= ehv_pic_unmask_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  147  	.irq_eoi	= ehv_pic_end_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  148  	.irq_set_type	= ehv_pic_set_irq_type,
3a93261f70c7b9 Ashish Kalra      2011-05-19  149  };
3a93261f70c7b9 Ashish Kalra      2011-05-19  150  
3a93261f70c7b9 Ashish Kalra      2011-05-19  151  static struct irq_chip ehv_pic_direct_eoi_irq_chip = {
3a93261f70c7b9 Ashish Kalra      2011-05-19  152  	.irq_mask	= ehv_pic_mask_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  153  	.irq_unmask	= ehv_pic_unmask_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  154  	.irq_eoi	= ehv_pic_direct_end_irq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  155  	.irq_set_type	= ehv_pic_set_irq_type,
3a93261f70c7b9 Ashish Kalra      2011-05-19  156  };
3a93261f70c7b9 Ashish Kalra      2011-05-19  157  
ef24ba7091517d Michael Ellerman  2016-09-06  158  /* Return an interrupt vector or 0 if no interrupt is pending. */
3a93261f70c7b9 Ashish Kalra      2011-05-19  159  unsigned int ehv_pic_get_irq(void)
3a93261f70c7b9 Ashish Kalra      2011-05-19  160  {
3a93261f70c7b9 Ashish Kalra      2011-05-19  161  	int irq;
3a93261f70c7b9 Ashish Kalra      2011-05-19  162  
3a93261f70c7b9 Ashish Kalra      2011-05-19  163  	BUG_ON(global_ehv_pic == NULL);
3a93261f70c7b9 Ashish Kalra      2011-05-19  164  
3a93261f70c7b9 Ashish Kalra      2011-05-19  165  	if (global_ehv_pic->coreint_flag)
3a93261f70c7b9 Ashish Kalra      2011-05-19  166  		irq = mfspr(SPRN_EPR); /* if core int mode */
3a93261f70c7b9 Ashish Kalra      2011-05-19  167  	else
3a93261f70c7b9 Ashish Kalra      2011-05-19  168  		ev_int_iack(0, &irq); /* legacy mode */
3a93261f70c7b9 Ashish Kalra      2011-05-19  169  
3a93261f70c7b9 Ashish Kalra      2011-05-19  170  	if (irq == 0xFFFF)    /* 0xFFFF --> no irq is pending */
ef24ba7091517d Michael Ellerman  2016-09-06  171  		return 0;
3a93261f70c7b9 Ashish Kalra      2011-05-19  172  
3a93261f70c7b9 Ashish Kalra      2011-05-19  173  	/*
3a93261f70c7b9 Ashish Kalra      2011-05-19  174  	 * this will also setup revmap[] in the slow path for the first
3a93261f70c7b9 Ashish Kalra      2011-05-19  175  	 * time, next calls will always use fast path by indexing revmap
3a93261f70c7b9 Ashish Kalra      2011-05-19  176  	 */
3a93261f70c7b9 Ashish Kalra      2011-05-19 @177  	return irq_linear_revmap(global_ehv_pic->irqhost, irq);
3a93261f70c7b9 Ashish Kalra      2011-05-19  178  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  179  
ad3aedfbb04b3a Marc Zyngier      2015-07-28 @180  static int ehv_pic_host_match(struct irq_domain *h, struct device_node *node,
ad3aedfbb04b3a Marc Zyngier      2015-07-28 @181  			      enum irq_domain_bus_token bus_token)
3a93261f70c7b9 Ashish Kalra      2011-05-19  182  {
3a93261f70c7b9 Ashish Kalra      2011-05-19  183  	/* Exact match, unless ehv_pic node is NULL */
5d4c9bc7767bc8 Marc Zyngier      2015-10-13 @184  	struct device_node *of_node = irq_domain_get_of_node(h);
5d4c9bc7767bc8 Marc Zyngier      2015-10-13  185  	return of_node == NULL || of_node == node;
3a93261f70c7b9 Ashish Kalra      2011-05-19  186  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  187  
bae1d8f19983fb Grant Likely      2012-02-14  188  static int ehv_pic_host_map(struct irq_domain *h, unsigned int virq,
3a93261f70c7b9 Ashish Kalra      2011-05-19  189  			 irq_hw_number_t hw)
3a93261f70c7b9 Ashish Kalra      2011-05-19  190  {
3a93261f70c7b9 Ashish Kalra      2011-05-19 @191  	struct ehv_pic *ehv_pic = h->host_data;
3a93261f70c7b9 Ashish Kalra      2011-05-19  192  	struct irq_chip *chip;
3a93261f70c7b9 Ashish Kalra      2011-05-19  193  
3a93261f70c7b9 Ashish Kalra      2011-05-19  194  	/* Default chip */
3a93261f70c7b9 Ashish Kalra      2011-05-19  195  	chip = &ehv_pic->hc_irq;
3a93261f70c7b9 Ashish Kalra      2011-05-19  196  
3a93261f70c7b9 Ashish Kalra      2011-05-19  197  	if (mpic_percpu_base_vaddr)
3a93261f70c7b9 Ashish Kalra      2011-05-19  198  		if (hwirq_intspec[hw] & IRQ_TYPE_MPIC_DIRECT)
3a93261f70c7b9 Ashish Kalra      2011-05-19  199  			chip = &ehv_pic_direct_eoi_irq_chip;
3a93261f70c7b9 Ashish Kalra      2011-05-19  200  
3a93261f70c7b9 Ashish Kalra      2011-05-19  201  	irq_set_chip_data(virq, chip);
3a93261f70c7b9 Ashish Kalra      2011-05-19  202  	/*
3a93261f70c7b9 Ashish Kalra      2011-05-19  203  	 * using handle_fasteoi_irq as our irq handler, this will
3a93261f70c7b9 Ashish Kalra      2011-05-19  204  	 * only call the eoi callback and suitable for the MPIC
3a93261f70c7b9 Ashish Kalra      2011-05-19  205  	 * controller which set ISR/IPR automatically and clear the
3a93261f70c7b9 Ashish Kalra      2011-05-19  206  	 * highest priority active interrupt in ISR/IPR when we do
3a93261f70c7b9 Ashish Kalra      2011-05-19  207  	 * a specific eoi
3a93261f70c7b9 Ashish Kalra      2011-05-19  208  	 */
3a93261f70c7b9 Ashish Kalra      2011-05-19  209  	irq_set_chip_and_handler(virq, chip, handle_fasteoi_irq);
3a93261f70c7b9 Ashish Kalra      2011-05-19  210  
3a93261f70c7b9 Ashish Kalra      2011-05-19  211  	/* Set default irq type */
3a93261f70c7b9 Ashish Kalra      2011-05-19  212  	irq_set_irq_type(virq, IRQ_TYPE_NONE);
3a93261f70c7b9 Ashish Kalra      2011-05-19  213  
3a93261f70c7b9 Ashish Kalra      2011-05-19  214  	return 0;
3a93261f70c7b9 Ashish Kalra      2011-05-19  215  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  216  
bae1d8f19983fb Grant Likely      2012-02-14  217  static int ehv_pic_host_xlate(struct irq_domain *h, struct device_node *ct,
3a93261f70c7b9 Ashish Kalra      2011-05-19  218  			   const u32 *intspec, unsigned int intsize,
3a93261f70c7b9 Ashish Kalra      2011-05-19  219  			   irq_hw_number_t *out_hwirq, unsigned int *out_flags)
3a93261f70c7b9 Ashish Kalra      2011-05-19  220  
3a93261f70c7b9 Ashish Kalra      2011-05-19  221  {
3a93261f70c7b9 Ashish Kalra      2011-05-19  222  	/*
3a93261f70c7b9 Ashish Kalra      2011-05-19  223  	 * interrupt sense values coming from the guest device tree
3a93261f70c7b9 Ashish Kalra      2011-05-19  224  	 * interrupt specifiers can have four possible sense and
3a93261f70c7b9 Ashish Kalra      2011-05-19  225  	 * level encoding information and they need to
3a93261f70c7b9 Ashish Kalra      2011-05-19  226  	 * be translated between firmware type & linux type.
3a93261f70c7b9 Ashish Kalra      2011-05-19  227  	 */
3a93261f70c7b9 Ashish Kalra      2011-05-19  228  
3a93261f70c7b9 Ashish Kalra      2011-05-19  229  	static unsigned char map_of_senses_to_linux_irqtype[4] = {
3a93261f70c7b9 Ashish Kalra      2011-05-19  230  		IRQ_TYPE_EDGE_FALLING,
3a93261f70c7b9 Ashish Kalra      2011-05-19  231  		IRQ_TYPE_EDGE_RISING,
3a93261f70c7b9 Ashish Kalra      2011-05-19  232  		IRQ_TYPE_LEVEL_LOW,
3a93261f70c7b9 Ashish Kalra      2011-05-19  233  		IRQ_TYPE_LEVEL_HIGH,
3a93261f70c7b9 Ashish Kalra      2011-05-19  234  	};
3a93261f70c7b9 Ashish Kalra      2011-05-19  235  
3a93261f70c7b9 Ashish Kalra      2011-05-19  236  	*out_hwirq = intspec[0];
3a93261f70c7b9 Ashish Kalra      2011-05-19  237  	if (intsize > 1) {
3a93261f70c7b9 Ashish Kalra      2011-05-19  238  		hwirq_intspec[intspec[0]] = intspec[1];
3a93261f70c7b9 Ashish Kalra      2011-05-19  239  		*out_flags = map_of_senses_to_linux_irqtype[intspec[1] &
3a93261f70c7b9 Ashish Kalra      2011-05-19  240  							~IRQ_TYPE_MPIC_DIRECT];
3a93261f70c7b9 Ashish Kalra      2011-05-19  241  	} else {
3a93261f70c7b9 Ashish Kalra      2011-05-19  242  		*out_flags = IRQ_TYPE_NONE;
3a93261f70c7b9 Ashish Kalra      2011-05-19  243  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  244  
3a93261f70c7b9 Ashish Kalra      2011-05-19  245  	return 0;
3a93261f70c7b9 Ashish Kalra      2011-05-19  246  }
3a93261f70c7b9 Ashish Kalra      2011-05-19  247  
9f70b8eb3cd37c Grant Likely      2012-01-26 @248  static const struct irq_domain_ops ehv_pic_host_ops = {
3a93261f70c7b9 Ashish Kalra      2011-05-19 @249  	.match = ehv_pic_host_match,
3a93261f70c7b9 Ashish Kalra      2011-05-19 @250  	.map = ehv_pic_host_map,
3a93261f70c7b9 Ashish Kalra      2011-05-19 @251  	.xlate = ehv_pic_host_xlate,
3a93261f70c7b9 Ashish Kalra      2011-05-19  252  };
3a93261f70c7b9 Ashish Kalra      2011-05-19  253  
3a93261f70c7b9 Ashish Kalra      2011-05-19  254  void __init ehv_pic_init(void)
3a93261f70c7b9 Ashish Kalra      2011-05-19  255  {
3a93261f70c7b9 Ashish Kalra      2011-05-19  256  	struct device_node *np, *np2;
3a93261f70c7b9 Ashish Kalra      2011-05-19  257  	struct ehv_pic *ehv_pic;
3a93261f70c7b9 Ashish Kalra      2011-05-19  258  	int coreint_flag = 1;
3a93261f70c7b9 Ashish Kalra      2011-05-19  259  
3a93261f70c7b9 Ashish Kalra      2011-05-19  260  	np = of_find_compatible_node(NULL, NULL, "epapr,hv-pic");
3a93261f70c7b9 Ashish Kalra      2011-05-19  261  	if (!np) {
3a93261f70c7b9 Ashish Kalra      2011-05-19  262  		pr_err("ehv_pic_init: could not find epapr,hv-pic node\n");
3a93261f70c7b9 Ashish Kalra      2011-05-19  263  		return;
3a93261f70c7b9 Ashish Kalra      2011-05-19  264  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  265  
3a93261f70c7b9 Ashish Kalra      2011-05-19  266  	if (!of_find_property(np, "has-external-proxy", NULL))
3a93261f70c7b9 Ashish Kalra      2011-05-19  267  		coreint_flag = 0;
3a93261f70c7b9 Ashish Kalra      2011-05-19  268  
3a93261f70c7b9 Ashish Kalra      2011-05-19  269  	ehv_pic = kzalloc(sizeof(struct ehv_pic), GFP_KERNEL);
3a93261f70c7b9 Ashish Kalra      2011-05-19  270  	if (!ehv_pic) {
3a93261f70c7b9 Ashish Kalra      2011-05-19  271  		of_node_put(np);
3a93261f70c7b9 Ashish Kalra      2011-05-19  272  		return;
3a93261f70c7b9 Ashish Kalra      2011-05-19  273  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  274  
a8db8cf0d894df Grant Likely      2012-02-14 @275  	ehv_pic->irqhost = irq_domain_add_linear(np, NR_EHV_PIC_INTS,
a8db8cf0d894df Grant Likely      2012-02-14  276  						 &ehv_pic_host_ops, ehv_pic);
3a93261f70c7b9 Ashish Kalra      2011-05-19  277  	if (!ehv_pic->irqhost) {
3a93261f70c7b9 Ashish Kalra      2011-05-19  278  		of_node_put(np);
e3854b6e25d1b0 Julia Lawall      2011-08-08  279  		kfree(ehv_pic);
3a93261f70c7b9 Ashish Kalra      2011-05-19  280  		return;
3a93261f70c7b9 Ashish Kalra      2011-05-19  281  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  282  
3a93261f70c7b9 Ashish Kalra      2011-05-19  283  	np2 = of_find_compatible_node(NULL, NULL, "fsl,hv-mpic-per-cpu");
3a93261f70c7b9 Ashish Kalra      2011-05-19  284  	if (np2) {
3a93261f70c7b9 Ashish Kalra      2011-05-19  285  		mpic_percpu_base_vaddr = of_iomap(np2, 0);
3a93261f70c7b9 Ashish Kalra      2011-05-19  286  		if (!mpic_percpu_base_vaddr)
3a93261f70c7b9 Ashish Kalra      2011-05-19  287  			pr_err("ehv_pic_init: of_iomap failed\n");
3a93261f70c7b9 Ashish Kalra      2011-05-19  288  
3a93261f70c7b9 Ashish Kalra      2011-05-19  289  		of_node_put(np2);
3a93261f70c7b9 Ashish Kalra      2011-05-19  290  	}
3a93261f70c7b9 Ashish Kalra      2011-05-19  291  
3a93261f70c7b9 Ashish Kalra      2011-05-19  292  	ehv_pic->hc_irq = ehv_pic_irq_chip;
3a93261f70c7b9 Ashish Kalra      2011-05-19  293  	ehv_pic->hc_irq.irq_set_affinity = ehv_pic_set_affinity;
3a93261f70c7b9 Ashish Kalra      2011-05-19  294  	ehv_pic->coreint_flag = coreint_flag;
3a93261f70c7b9 Ashish Kalra      2011-05-19  295  
3a93261f70c7b9 Ashish Kalra      2011-05-19  296  	global_ehv_pic = ehv_pic;
3a93261f70c7b9 Ashish Kalra      2011-05-19 @297  	irq_set_default_host(global_ehv_pic->irqhost);

:::::: The code at line 184 was first introduced by commit
:::::: 5d4c9bc7767bc86eb9a0e66df783e3fbada7dc97 irqdomain: Use irq_domain_get_of_node() instead of direct field access

:::::: TO: Marc Zyngier <marc.zyngier at arm.com>
:::::: CC: Thomas Gleixner <tglx at linutronix.de>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 17830 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210405/ab5301e1/attachment-0001.gz>

From madvenka at linux.microsoft.com  Sun Apr  4 17:29:57 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Sun, 4 Apr 2021 11:29:57 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <49790505-f611-b4a2-c804-b779060601a9@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
 <20210403155948.ubbgtwmlsdyar7yp@treble>
 <171fef08-17d3-2c2e-dad8-6caf4c0c7f15@linux.microsoft.com>
 <49790505-f611-b4a2-c804-b779060601a9@linux.microsoft.com>
Message-ID: <74475382-9482-48ac-e9a3-00073cb721ea@linux.microsoft.com>



On 4/3/21 11:40 PM, Madhavan T. Venkataraman wrote:
> 
> 
> On 4/3/21 10:46 PM, Madhavan T. Venkataraman wrote:
>>> I'm somewhat arm-ignorant, so take the following comments with a grain
>>> of salt.
>>>
>>>
>>> I don't think changing these to 'bl' is necessary, unless you wanted
>>> __primary_switched() and __secondary_switched() to show up in the
>>> stacktrace for some reason?  If so, that seems like a separate patch.
>>>
>> The problem is with __secondary_switched. If you trace the code back to where
>> a secondary CPU is started, I don't see any calls anywhere. There are only
>> branches if I am not mistaken. So, the return address register never gets
>> set up with a proper address. The stack trace shows some hexadecimal value
>> instead of a symbol name.
>>
> 
> Actually, I take that back. There are calls in that code path. But I did only
> see some hexadecimal value instead of a proper address in the stack trace.
> Sorry about that confusion.
> 

Again, I apologize. I had this confused with something else in my notes.

So, the stack trace looks like this without my changes to convert the branch to
secondary_start_kernel() to a call:

		 ...
[    0.022492]   secondary_start_kernel+0x188/0x1e0
[    0.022503]   0xf8689e1cc

It looks like the code calls __enable_mmu before reaching the place where it
branches to secondary_start_kernel().

	bl      __enable_mmu

The return address register should be set to the next instruction address. I am
guessing that the return address is 0xf8689e1cc because of the idmap stuff.

Madhavan


From bjorn.andersson at linaro.org  Sun Apr  4 17:48:41 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sun,  4 Apr 2021 11:48:41 -0500
Subject: [GIT PULL] Qualcomm ARM64 defconfig udpate for 5.13
Message-ID: <20210404164841.712845-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -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-5.13

for you to fetch changes up to 1a0252abb6ff8312f28d4d8bc2b115ffa9c5d6c6:

  arm64: defconfig: Enable Qualcomm SM8350 TLMM and GCC (2021-03-08 10:45:28 -0600)

----------------------------------------------------------------
Qualcomm ARM64 defconfig udpate for 5.13

This enables the SM8350 TLMM and GCC drivers, needed to boot the
platform.

----------------------------------------------------------------
Bjorn Andersson (1):
      arm64: defconfig: Enable Qualcomm SM8350 TLMM and GCC

 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)


From bjorn.andersson at linaro.org  Sun Apr  4 17:49:14 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sun,  4 Apr 2021 11:49:14 -0500
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
Message-ID: <20210404164914.712946-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13

for you to fetch changes up to e9269650db2f5b4aeeafced1a42b2e51d10bcdf5:

  arm64: dts: qcom: qrb5165-rb5: switch into using GPIO for SPI0 CS (2021-03-18 09:35:42 -0500)

----------------------------------------------------------------
Qualcomm ARM64 DT updates for 5.13

This extends the initial SM8350 description merged in v5.12 with
CPUfreq, SMMU, UFS, RPMHPD, SPMI, USB and remoteproc support. It adds
initial PMIC definitions for the 6 PMICs found on the MTP and it
introduces the new SM8350 Hardware Development Kit (HDK).

SC7180 is further polished, the DisplayPort portion of the QMP phy is
defined and several new SKUs of the Trogdor devices are introduced.

The new SC7280 platform is introduced, with RPMH, RPMHPD, RPMCC, SPMI,
CPU idle, SMMU and watchdog defined.

SDM845 gains the camera related nodes and some cleanups.

For SM8250 it brings some cleanups and migrates SPI0 to use GPIO for
chip select.

----------------------------------------------------------------
Abhishek Kumar (1):
      arm64: dts: qcom: sc7180: add GO_LAZOR variant property for lazor

Alexandru M Stan (1):
      arm64: dts: qcom: sc7180-trogdor: Remove fp control pins in prep for coachz

Bjorn Andersson (3):
      arm64: dts: qcom: Introduce SM8350 HDK
      dt-bindings: arm: qcom: Add SM8350 HDK
      arm64: dts: qcom: pm8150: Enable RTC

Dmitry Baryshkov (4):
      arm64: dts: qcom: sm8250: split spi pinctrl config
      arm64: dts: qcom: sm8250: further split of spi pinctrl config
      arm64: dts: qcom: sm8250: add pinctrl for SPI using GPIO as a CS
      arm64: dts: qcom: qrb5165-rb5: switch into using GPIO for SPI0 CS

Douglas Anderson (7):
      arm64: dts: qcom: Move sc7180 MI2S config to board files and make pulldown
      arm64: dts: qcom: Prep sc7180-trogdor trackpad IRQ for new boards
      arm64: dts: qcom: Unify the sc7180-trogdor panel nodes
      arm64: dts: qcom: Add sc7180-lazor-limozeen skus
      arm64: dts: qcom: Add sc7180-trogdor-pompom skus
      arm64: dts: qcom: Add sc7180-trogdor-coachz skus
      arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor

Jack Pham (2):
      arm64: dts: qcom: sm8350: add USB and PHY device nodes
      arm64: dts: qcom: sm8350-mtp: enable USB nodes

Matthias Kaehlcke (5):
      arm64: dts: qcom: sc7180: trogdor: Add label to charger thermal zone
      arm64: dts: qcom: sc7180: Disable charger thermal zone for lazor
      arm64: dts: qcom: sc7180: trogdor: Fix trip point config of charger thermal zone
      arm64: dts: qcom: sc7180: trogdor: Use ADC TM channel 0 instead of 1 for charger temperature
      arm64: dts: qcom: sc7180: Set up lazor r3+ as sc7180-lite SKUs

Maulik Shah (3):
      arm64: dts: qcom: sc7280: Add RSC and PDC devices
      arm64: dts: qcom: sc7280: Add reserved memory for fw
      arm64: dts: qcom: sc7280: Add cpuidle states

Rajendra Nayak (4):
      dt-bindings: arm: qcom: Document sc7280 SoC and board
      arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc
      arm64: dts: qcom: SC7280: Add rpmhcc clock controller node
      arm64: dts: qcom: sc7280: Add rpmh power-domain node

Robert Foss (3):
      arm64: dts: qcom: sdm845: Add CAMSS ISP node
      arm64: dts: qcom: sdm845-db845c: Configure regulators for camss node
      arm64: dts: qcom: sdm845-db845c: Enable ov8856 sensor and connect to ISP

Sai Prakash Ranjan (9):
      arm64: dts: qcom: sc7180: Rename the qmp node to power-controller
      arm64: dts: qcom: sdm845: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8250: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8350: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8250: Fix level triggered PMU interrupt polarity
      arm64: dts: qcom: sm8350: Fix level triggered PMU interrupt polarity
      arm64: dts: qcom: sm8250: Fix timer interrupt to specify EL2 physical timer
      arm64: dts: qcom: sc7280: Add device node for APPS SMMU
      arm64: dts: qcom: sc7280: Add APSS watchdog node

Sandeep Maheswaram (1):
      arm64: dts: qcom: sc7180: Use pdc interrupts for USB instead of GIC interrupts

Shawn Guo (4):
      arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'

Srinivas Kandagatla (1):
      arm64: dts: qcom: db845c: fix correct powerdown pin for WSA881x

Stephen Boyd (4):
      arm64: dts: qcom: sc7180: Update dts for DP phy inside QMP phy
      arm64: dts: qcom: trogdor: Only wakeup from pen eject
      arm64: dts: qcom: Disable camera clk on sc7180-trogdor devices by default
      arm64: dts: qcom: sc7180: Drop duplicate dp_hot_plug_det node in trogdor

Venkata Lakshmi Narayana Gubba (1):
      arm64: dts: qcom: sc7180: Remove clock for bluetooth on Trogdor

Vinod Koul (25):
      arm64: dts: qcom: sm8350: Add apss_smmu node
      arm64: dts: qcom: sm8350: Add UFS nodes
      arm64: dts: qcom: sm8350-mtp: enable UFS nodes
      arm64: dts: qcom: sm8350-mtp: add regulator names
      arm64: dts: qcom: sm8350: fix typo
      arm64: dts: qcom: sm8350: Add rpmhpd node
      arm64: dts: qcom: sm8350: Add rmtfs node
      arm64: dts: qcom: sm8350: Add SMP2P nodes
      arm64: dts: qcom: sm8350: Add remoteprocs
      arm64: dts: qcom: sm8350-mtp: Enable remoteprocs
      arm64: dts: qcom: sm8350: Use enums for GCC
      arm64: dts: qcom: sm8350: Add cpufreq node
      arm64: dts: qcom: apq8016-sbc: drop qcom,sbc
      arm64: dts: qcom: msm8916: don't use empty memory node
      dt-bindings: arm: qcom: Document ipq6018-cp01 board
      arm64: dts: qcom: msm8994: don't use empty memory node
      dt-bindings: arm: qcom: Document sony boards for apq8094
      arm64: dts: qcom: sm8350: Add spmi node
      arm64: dts: qcom: pmk8350: Add base dts file
      arm64: dts: qcom: pm8350: Add base dts file
      arm64: dts: qcom: pm8350b: Add base dts file
      arm64: dts: qcom: pm8350c: Add base dts file
      arm64: dts: qcom: pmr735a: Add base dts file
      arm64: dts: qcom: pmr735B: Add base dts file
      arm64: dts: qcom: sm8350-mtp: Add PMICs

satya priya (1):
      arm64: dts: qcom: sc7280: Add SPMI PMIC arbiter device for SC7280

 Documentation/devicetree/bindings/arm/qcom.yaml    |  18 +
 arch/arm64/boot/dts/qcom/Makefile                  |  13 +
 arch/arm64/boot/dts/qcom/apq8016-sbc.dts           |   2 +-
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |   4 +-
 arch/arm64/boot/dts/qcom/msm8994.dtsi              |   4 +-
 arch/arm64/boot/dts/qcom/pm8150.dtsi               |   4 +-
 arch/arm64/boot/dts/qcom/pm8350.dtsi               |  25 +
 arch/arm64/boot/dts/qcom/pm8350b.dtsi              |  25 +
 arch/arm64/boot/dts/qcom/pm8350c.dtsi              |  25 +
 arch/arm64/boot/dts/qcom/pmk8350.dtsi              |  25 +
 arch/arm64/boot/dts/qcom/pmr735a.dtsi              |  25 +
 arch/arm64/boot/dts/qcom/pmr735b.dtsi              |  25 +
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts           |  18 +-
 .../boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dts |  18 +
 .../boot/dts/qcom/sc7180-trogdor-coachz-r1.dts     | 154 +++++
 .../boot/dts/qcom/sc7180-trogdor-coachz-r2-lte.dts |  18 +
 .../boot/dts/qcom/sc7180-trogdor-coachz-r2.dts     |  15 +
 .../arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 240 +++++++
 .../qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dts |  34 +
 .../qcom/sc7180-trogdor-lazor-limozeen-nots.dts    |  26 +
 .../dts/qcom/sc7180-trogdor-lazor-limozeen.dts     |  42 ++
 .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts      |   9 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts      |   9 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts   |   5 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts  |   4 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3.dts      |  10 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi |  39 +-
 .../boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dts |  14 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r1.dts     |  26 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r2-lte.dts |  14 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r2.dts     |  44 ++
 .../arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi | 288 ++++++++
 arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts     |  35 +-
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi       | 162 ++---
 arch/arm64/boot/dts/qcom/sc7180.dtsi               |  51 +-
 arch/arm64/boot/dts/qcom/sc7280-idp.dts            |  47 ++
 arch/arm64/boot/dts/qcom/sc7280.dtsi               | 608 +++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts         |  27 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi               | 139 +++-
 arch/arm64/boot/dts/qcom/sm8150.dtsi               |   2 +-
 arch/arm64/boot/dts/qcom/sm8250-mtp.dts            |   4 -
 arch/arm64/boot/dts/qcom/sm8250.dtsi               | 548 ++++++++--------
 arch/arm64/boot/dts/qcom/sm8350-hdk.dts            | 319 +++++++++
 arch/arm64/boot/dts/qcom/sm8350-mtp.dts            | 116 ++++
 arch/arm64/boot/dts/qcom/sm8350.dtsi               | 726 ++++++++++++++++++++-
 45 files changed, 3553 insertions(+), 453 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350b.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmr735b.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r2-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sc7280-idp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7280.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sm8350-hdk.dts


From bjorn.andersson at linaro.org  Sun Apr  4 17:49:51 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sun,  4 Apr 2021 11:49:51 -0500
Subject: [GIT PULL] Qualcomm driver updates for 5.13
Message-ID: <20210404164951.713045-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-5.13

for you to fetch changes up to ac6ad7c2a862d682bb584a4bc904d89fa7721af8:

  bus: qcom: Put child node before return (2021-03-29 22:01:27 -0500)

----------------------------------------------------------------
Qualcomm driver updates for 5.13

This introduces SC7280 and SM8350 support in the RPMH power-domain
driver, SC7280 support to the LLCC driver, SC7280 support tot he AOSS
QMP driver, cleanups to the RPMH driver and a few smaller fixes to the
SMEM, QMI and EBI2 drivers.

----------------------------------------------------------------
Bhaskar Chowdhury (1):
      soc: qcom: Fix typos in the file qmi_encdec.c

Pan Bian (1):
      bus: qcom: Put child node before return

Rajendra Nayak (3):
      dt-bindings: power: rpmpd: Add sc7280 to rpmpd binding
      soc: qcom: rpmhpd: Add sc7280 powerdomains
      dt-bindings: firmware: scm: Add sc7280 support

Sai Prakash Ranjan (4):
      dt-bindings: arm: msm: Add LLCC for SC7280
      soc: qcom: llcc: Add configuration data for SC7280
      dt-bindings: soc: qcom: aoss: Add SC7280 compatible
      soc: qcom: aoss: Add AOSS QMP support for SC7280

Sibi Sankar (1):
      soc: qcom: smem: Update max processor count

Stephen Boyd (3):
      soc: qcom: rpmh-rsc: Remove tcs_is_free() API
      soc: qcom: rpmh-rsc: Loop over fewer bits in irq handler
      soc: qcom: rpmh-rsc: Fold WARN_ON() into if condition

Vinod Koul (2):
      dt-bindings: power: Add rpm power domain bindings for SM8350
      soc: qcom: rpmhpd: Add SM8350 power domains

 .../devicetree/bindings/arm/msm/qcom,llcc.yaml     |  1 +
 .../devicetree/bindings/firmware/qcom,scm.txt      |  1 +
 .../devicetree/bindings/power/qcom,rpmpd.yaml      |  2 +
 .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt |  1 +
 drivers/bus/qcom-ebi2.c                            |  4 +-
 drivers/soc/qcom/llcc-qcom.c                       | 19 +++++++
 drivers/soc/qcom/qcom_aoss.c                       |  1 +
 drivers/soc/qcom/qmi_encdec.c                      |  8 +--
 drivers/soc/qcom/rpmh-rsc.c                        | 65 ++++++++--------------
 drivers/soc/qcom/rpmhpd.c                          | 56 +++++++++++++++++++
 drivers/soc/qcom/smem.c                            |  2 +-
 include/dt-bindings/power/qcom-rpmpd.h             | 26 +++++++++
 12 files changed, 137 insertions(+), 49 deletions(-)


From christophe.leroy at csgroup.eu  Sun Apr  4 18:20:48 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Sun,  4 Apr 2021 17:20:48 +0000 (UTC)
Subject: [RFC PATCH v6 1/1] cmdline: Add capability to both append and prepend
 at the same time
Message-ID: <34d20d1dbb88f26d418b33985557b0475374a1a5.1617556785.git.christophe.leroy@csgroup.eu>

One user has expressed the need to both append and prepend some
built-in parameters to the command line provided by the bootloader.

Allthough it is a corner case, it is easy to implement so let's do it.

When the user chooses to prepend the bootloader provided command line
with the built-in command line, he is offered the possibility to enter
an additionnal built-in command line to be appended after the
bootloader provided command line.

It is a complementary feature which has no impact on the already
existing ones and/or the existing defconfig.

Suggested-by: Daniel Walker <danielwa at cisco.com>
Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
Sending this out as an RFC, applies on top of the series
("Implement GENERIC_CMDLINE"). I will add it to the series next spin
unless someone is against it.
---
 include/linux/cmdline.h |  3 +++
 init/Kconfig            | 12 +++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
index 020028e2bdf0..fb274a4d5519 100644
--- a/include/linux/cmdline.h
+++ b/include/linux/cmdline.h
@@ -36,6 +36,9 @@ static __always_inline bool __cmdline_build(char *dst, const char *src)
 
 	len = cmdline_strlcat(dst, src, COMMAND_LINE_SIZE);
 
+	if (IS_ENABLED(CONFIG_CMDLINE_PREPEND))
+		len = cmdline_strlcat(dst, " " CONFIG_CMDLINE_MORE, COMMAND_LINE_SIZE);
+
 	if (IS_ENABLED(CONFIG_CMDLINE_APPEND))
 		len = cmdline_strlcat(dst, " " CONFIG_CMDLINE, COMMAND_LINE_SIZE);
 
diff --git a/init/Kconfig b/init/Kconfig
index fa002e3765ab..cd3087ff4f28 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -128,6 +128,14 @@ config CMDLINE
 	  If this string is not empty, additional choices are proposed
 	  below to determine how it will be used by the kernel.
 
+config CMDLINE_MORE
+	string "Additional default kernel command string" if GENERIC_CMDLINE && CMDLINE_PREPEND
+	default ""
+	help
+	  Defines an additional default kernel command string.
+	  If this string is not empty, it is appended to the
+	  command-line arguments provided by the bootloader
+
 choice
 	prompt "Kernel command line type" if CMDLINE != ""
 	default CMDLINE_PREPEND if ARCH_WANT_CMDLINE_PREPEND_BY_DEFAULT
@@ -154,7 +162,9 @@ config CMDLINE_PREPEND
 	bool "Prepend to the bootloader kernel arguments"
 	help
 	  The default kernel command string will be prepended to the
-	  command-line arguments provided by the bootloader.
+	  command-line arguments provided by the bootloader. When this
+	  option is selected, another string can be added which will
+	  be appended.
 
 config CMDLINE_FORCE
 	bool "Always use the default kernel command string"
-- 
2.25.0



From daniel.lezcano at linaro.org  Sun Apr  4 21:28:32 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 4 Apr 2021 22:28:32 +0200
Subject: [PATCH 05/14] dt-bindings: timer: nuvoton,npcm7xx: Add
 wpcm450-timer
In-Reply-To: <20210320181610.680870-6-j.neuschaefer@gmx.net>
References: <20210320181610.680870-1-j.neuschaefer@gmx.net>
 <20210320181610.680870-6-j.neuschaefer@gmx.net>
Message-ID: <623f26fa-38f3-c7fc-a857-126d93a0e886@linaro.org>

On 20/03/2021 19:16, Jonathan Neusch?fer wrote:
> Add a compatible string for WPCM450, which has essentially the same
> timer controller.
> 
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
> ---

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 daniel.lezcano at linaro.org  Sun Apr  4 21:33:26 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 4 Apr 2021 22:33:26 +0200
Subject: [PATCH v2 1/8] dt-bindings: timer: Add compatible for Mediatek
 MT8195
In-Reply-To: <bf7ad31e-974a-3e0a-12bd-32973c7c3cbd@gmail.com>
References: <20210319023427.16711-1-seiya.wang@mediatek.com>
 <20210319023427.16711-3-seiya.wang@mediatek.com>
 <bf7ad31e-974a-3e0a-12bd-32973c7c3cbd@gmail.com>
Message-ID: <11bf6761-8902-bfa5-8577-d397846e7638@linaro.org>

On 29/03/2021 13:52, Matthias Brugger wrote:
> 
> 
> On 19/03/2021 03:34, Seiya Wang wrote:
>> This commit adds dt-binding documentation of timer for Mediatek MT8195 SoC
>> Platform.
>>
>> Signed-off-by: Seiya Wang <seiya.wang at mediatek.com>
> 
> Applied to v5.12-next/dts64

Usually bindings go through the subsystem maintainer.


-- 
<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 marcan at marcan.st  Mon Apr  5 06:50:42 2021
From: marcan at marcan.st (Hector Martin)
Date: Mon, 5 Apr 2021 14:50:42 +0900
Subject: [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini
 (M1, 2020) devicetree
In-Reply-To: <a94dd533-6aa2-167f-78a5-4fbd2efe7d7e@somainline.org>
References: <20210304213902.83903-1-marcan@marcan.st>
 <20210304213902.83903-28-marcan@marcan.st>
 <a94dd533-6aa2-167f-78a5-4fbd2efe7d7e@somainline.org>
Message-ID: <f9dea9a0-bc52-4e32-417d-ee93dd1c070c@marcan.st>

Hi,

Sorry, I did not see this e-mail originally as it was sent only to the 
mailing list, not to me nor CCed to anyone else.

I am subscribed to the lists, but I generally rely on my inbox for 
review feedback. I have added a sieve rule to catch emails sent to the 
list that are replies to me and do not have me in To: or Cc: and copy 
them to my inbox in the future.

That said, I think it's best to reply-all, to keep everyone else in the 
loop. CCing a few relevant folks.

On 14/03/2021 05.22, Konrad Dybcio wrote:
>> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> 
> It seems to be
> 
> "// SPDX-License-Identifier: (GPL-2.0+ OR MIT)"
> 
> in other DTs (notice the brackets).

This was already discussed in [1].

The conclusion was that no braces is the preferred form according to the 
SPDX spec.

[1] 
https://lore.kernel.org/linux-arm-kernel/20210216073120.qmlaky43t6uelqc4 at kozik-lap/

>> +/*
>> + * Apple Mac mini (M1, 2020)
> 
> Not sure if it's necessary, you already state it in model=""

I find it helpful to have identifying info in the top comment, since 
it's easier to locate at a glance than visually searching for the model 
property. Since I also add identifiers that Apple uses to be able to 
cross reference things here, even if it's somewhat duplicative, I think 
it makes sense to keep all of it in the top comment.

>> + *
>> + * target-type: J174
> 
> Isn't that a typo? Compatible states J*2*74, but I'm curious if that's intentional.

That's a typo, it's already fixed in v4 :)

>> + *
>> + * Copyright The Asahi Linux Contributors
> 
> * Copyright (C) 2021 The Asahi Linux Contributors

This was also discussed, see [2] and [3]. Copyright dates in headers are 
essentially useless because they are always out of date in practice.

[2] 
https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/
[3] 
https://lore.kernel.org/linux-arm-kernel/d8454963-3242-699b-4c20-e85d26b19796 at marcan.st/

>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "t8103.dtsi"
>> +
>> +/ {
>> +	compatible = "apple,j274", "apple,t8103", "apple,arm-platform";
>> +	model = "Apple Mac mini (M1, 2020)";
>> +
>> +	aliases {
>> +		serial0 = &serial0;
> 
> Isn't this M1-common?

It's common to all existing M1 devices, but in principle there is 
nothing that says that the stdout path has to be the first UART on any 
given device (there is more than one UART, we just aren't declaring the 
others yet in this series). This is a common pattern, see e.g. 
nvidia/tegra210-smaug.dts.

>> +	};
>> +
>> +	chosen {
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		stdout-path = "serial0";
> 
> Doesn't serial work without this?

This is for earlycon to work. See e.g. nvidia/tegra210-smaug.dts for 
another example. Note that this still requires the earlycon kernel 
parameter, so if earlycon is not enabled then this does nothing; if the 
user also isn't setting the serial TTY device as a console, then the 
serial port is free for use by the user.

> Not sure if we want the @0 (unless it's also overwritten by the loader).

We need a unit address for the linter, but yes, this is in fact 
overwritten by the loader with the correct one.

>> +			compatible = "apple,simple-framebuffer", "simple-framebuffer";
>> +			reg = <0 0 0 0>; /* To be filled by loader */
>> +			/* Format properties will be added by loader */
>> +			status = "disabled";
> 
> Does it get enabled by the loader?

Yup, assuming everything works. The loader leaves it disabled if 
something goes wrong converting the information from the XNU bootargs 
(e.g. unsupported CLUT format, which I don't think any M1 mac ever uses).

> Also, isn't the framebuffer common for all M1 devices?

The framebuffer is allocated by iBoot dynamically, and is at a variable 
address. The format is also variable, as is the resolution, depending on 
the device. This is why the loader fills in the info.

In principle, the idea that a framebuffer exists is common to all 
existing devices, but nothing says this has to be the case for future 
devices: it's not a SoC property, it's a property of devices built using 
the SoC (and the way they are configured by iBoot).

>> +		};
>> +	};
>> +
>> +	memory at 800000000 {
>> +		device_type = "memory";
>> +		reg = <0x8 0 0x2 0>; /* To be filled by loader */
>> +	};
> 
> Shouldn't this be in the SoC DTSI?

It could. The pattern I'm trying to follow here is that stuff filled in 
by the loader or which varies from device to device goes in the board 
file; technically here it doesn't matter since of course every SoC has 
"some" memory and the loader overwrites it anyway, but this still makes 
logical sense to me. If you look around, you'll see memory is usually 
defined in board or sub-platform files, not the SoC root (exception: 
qcom stuff, apparently).

>> +	compatible = "apple,t8103", "apple,arm-platform";
> 
> Please remove this line, it's getting overwritten anyway.

I think it's helpful to document the expected compatible subset to be 
inherited by board files. The Tegra example I linked above does this too.

>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +
>> +		ranges;
>> +		nonposted-mmio;
>> +
> 
> I think
> 
> "
> 
> compatible = "simple-bus";
> 
> #address-cells = <2>;
> 
> #size-cells = <2>;
> 
> nonposted-mmio;
> 
> ranges;
> 
> "
> 
> would look more coherent to the human eye, but that's rather a nit.

The reason for putting nonposted-mmio last is that it is a flag for a 
bus, so to me it makes logical sense to put it after ranges, which is 
what marks this as a translatable bus.

> Other than this, node order seems to be entirely random. Please sort them by address (where applicable) and by name where not, so that this doesn't become a huge mess as we go forward.

Outside of the soc bus I think the order we have makes sense: CPUs 
first, timer (which is part of the CPU complex) next, then fixed clocks. 
There are only a few things that are going to go in here, so I think an 
ad-hoc order like this is okay.

Inside the bus we only have two nodes so far, and they are indeed in the 
wrong order :-). I'll sort them by address. Almost everything else is 
going to go in here in the future, so that should keep things sane.

Thanks!
-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From baolu.lu at linux.intel.com  Mon Apr  5 07:00:02 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Mon, 5 Apr 2021 14:00:02 +0800
Subject: [PATCH v2 07/12] iommu: Hook up '->unmap_pages' driver callback
In-Reply-To: <20210402013452.4013-8-isaacm@codeaurora.org>
References: <20210402013452.4013-1-isaacm@codeaurora.org>
 <20210402013452.4013-8-isaacm@codeaurora.org>
Message-ID: <0d1a6c6b-c523-8868-99c5-51c6a1e40cc4@linux.intel.com>

Hi,

On 4/2/21 9:34 AM, Isaac J. Manjarres wrote:
>   static size_t __iommu_unmap(struct iommu_domain *domain,
>   			    unsigned long iova, size_t size,
>   			    struct iommu_iotlb_gather *iotlb_gather)
> @@ -2476,7 +2519,7 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
>   	unsigned long orig_iova = iova;
>   	unsigned int min_pagesz;
>   
> -	if (unlikely(ops->unmap == NULL ||
> +	if (unlikely((ops->unmap == NULL && ops->unmap_pages == NULL) ||
>   		     domain->pgsize_bitmap == 0UL))

This change should also be applied to __iommu_map() path. And perhaps
could be:

	if (unlikely(!(ops->unmap || ops->unmap_pages) || !domain->pgsize_bitmap))

Best regards,
baolu


From gregkh at linuxfoundation.org  Mon Apr  5 08:02:57 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 5 Apr 2021 09:02:57 +0200
Subject: [PATCH v6 1/4] usb: dwc3: of-simple: bail probe if no dwc3 child
 node
In-Reply-To: <20210401213652.14676-2-jbx6244@gmail.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
 <20210401213652.14676-2-jbx6244@gmail.com>
Message-ID: <YGq2IaygRQaAcLli@kroah.com>

On Thu, Apr 01, 2021 at 11:36:49PM +0200, Johan Jonker wrote:
> For some of the dwc3-of-simple compatible SoCs we
> don't want to bind this driver to a dwc3 node,
> but bind that node to the 'snps,dwc3' driver instead.
> The kernel has no logic to decide which driver to bind
> to if there are 2 matching drivers, so bail probe if no
> dwc3 child node.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  drivers/usb/dwc3/dwc3-of-simple.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c b/drivers/usb/dwc3/dwc3-of-simple.c
> index 71fd620c5..8d3baa5df 100644
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -38,6 +38,10 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
>  
>  	int			ret;
>  
> +	/* Bail probe if no dwc3 child node. */
> +	if (!of_get_compatible_child(dev->of_node, "snps,dwc3"))
> +		return -ENODEV;

Why is this part of the "convert to yaml" patch series?  Shouldn't this
be a separate, independant patch?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Mon Apr  5 08:04:01 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 5 Apr 2021 09:04:01 +0200
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <1617179455.2752.1.camel@mhfsdcap03>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03>
Message-ID: <YGq2YfURFApdJLxb@kroah.com>

On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> 
> I'll test it , thanks

Did you test this series and find any problems?  If not, I'll go queue
these up...

thanks,

greg k-h


From cnsztl at gmail.com  Mon Apr  5 08:44:59 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon,  5 Apr 2021 15:44:59 +0800
Subject: [PATCH] rockchip: enabled LAN port on NanoPi R2S
Message-ID: <20210405074459.4217-1-cnsztl@gmail.com>

From: David Bauer <mail at david-bauer.net>

Enable the USB3 port on the FriendlyARM NanoPi R2S.
This is required for the USB3 attached LAN port to work.

Signed-off-by: David Bauer <mail at david-bauer.net>
Signed-off-by: Tianling Shen <cnsztl at gmail.com>
---
 .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
index faf496d789cf..6ba9799a95c5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
@@ -37,6 +37,18 @@
 		};
 	};
 
+	vcc_rtl8153: vcc-rtl8153-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtl8153_en_drv>;
+		regulator-always-on;
+		regulator-name = "vcc_rtl8153";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
@@ -265,6 +277,12 @@
 			};
 		};
 	};
+
+	usb {
+		rtl8153_en_drv: rtl8153-en-drv {
+			rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &io_domains {
@@ -364,6 +382,11 @@
 	dr_mode = "host";
 };
 
+&usbdrd3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
 &usb_host0_ehci {
 	status = "okay";
 };
-- 
2.17.1



From wens at kernel.org  Mon Apr  5 09:13:49 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 5 Apr 2021 16:13:49 +0800
Subject: [PATCH] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <20210405074459.4217-1-cnsztl@gmail.com>
References: <20210405074459.4217-1-cnsztl@gmail.com>
Message-ID: <CAGb2v66K3SFSkm9T_D6X5o7jSYOoYpYeS_yMp1k6nMonmjiHZA@mail.gmail.com>

Hi,

On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen <cnsztl at gmail.com> wrote:
>
> From: David Bauer <mail at david-bauer.net>
>
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
>
> Signed-off-by: David Bauer <mail at david-bauer.net>
> Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> ---
>  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 23 +++++++++++++++++++
>  1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index faf496d789cf..6ba9799a95c5 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -37,6 +37,18 @@
>                 };
>         };
>
> +       vcc_rtl8153: vcc-rtl8153-regulator {
> +               compatible = "regulator-fixed";
> +               gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&rtl8153_en_drv>;
> +               regulator-always-on;
> +               regulator-name = "vcc_rtl8153";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;

This is just a simple switch, not an actual regulator.
It would make more sense to drop the voltage range and
instead have the implementation pass-through voltage
constraints from its parent.

> +               enable-active-high;
> +       };
> +
>         leds {
>                 compatible = "gpio-leds";
>                 pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> @@ -265,6 +277,12 @@
>                         };
>                 };
>         };
> +
> +       usb {
> +               rtl8153_en_drv: rtl8153-en-drv {
> +                       rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +               };
> +       };
>  };
>
>  &io_domains {
> @@ -364,6 +382,11 @@
>         dr_mode = "host";
>  };
>
> +&usbdrd3 {
> +       dr_mode = "host";
> +       status = "okay";

Please also add a device node for the actual Ethernet controller, and
set up an aliases node for it, so that the bootloader has some place
to fill in a MAC address.


ChenYu

> +};
> +
>  &usb_host0_ehci {
>         status = "okay";
>  };
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From p.yadav at ti.com  Mon Apr  5 09:34:17 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Mon, 5 Apr 2021 14:04:17 +0530
Subject: [PATCH 4/4] dt-bindings: spi: Convert cadence-quadspi.txt to
 cadence-quadspi.yaml
In-Reply-To: <20210401141328.GH4758@sirena.org.uk>
References: <20210331193930.tzsvbjup3wpxmh26@ti.com>
 <20210401141328.GH4758@sirena.org.uk>
Message-ID: <20210405083415.x6azwdzanvsbiljn@ti.com>

On 01/04/21 03:13PM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:
> 
> > I did take a look by running git log on 
> > Documentation/devicetree/bindings/spi/ and there is no single style 
> > being used. Using "dt-bindings: spi:" is a popular choice. Some other 
> > commits just use "spi:". And then some use "spi: dt-bindings:". The last 
> > commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix 
> > "dt-bindings: spi:".
> 
> Yes, lots of people pick unfortunate subject lines for DT patches - that
> doesn't mean it's good.  I'm looking to see spi: same as for all other
> SPI patches.

All right. "spi: dt-bindings:" it is from now on.

> 
> > So on the prefix front I think the subject is good enough. Of course, if 
> > you have any other preference then it can be re-worded but let's first 
> > be clear on what the expectation is. And then let's make sure to apply 
> > it to all future patches uniformly. This way future contributors won't 
> > have to take a guess on what the expected prefix is.
> 
> I do edit some percentage of patches, but some do slip through for
> various reasons.  There's also some things that just get completely
> missed, especially if there isn't also a code patch nearby.
> 
> > Apart from the prefix is there anything else to improve? IMHO the 
> > subject is good enough but I'm open to suggestions.
> 
> There was the thing with constraints.

Will send a follow up patch to add the constraints that Vignesh 
suggested.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From nsaenzjulienne at suse.de  Mon Apr  5 09:45:29 2021
From: nsaenzjulienne at suse.de (Nicolas Saenz Julienne)
Date: Mon, 05 Apr 2021 10:45:29 +0200
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
 <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
Message-ID: <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>

Hi Alan,

On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
> Nicolas,
> 
> Sorry, I just noticed this thread.
> This is a known bug in some newer Arasan cores.
> The problem happens when the difference between the core clock and the bus
> clock is too great.
> Limiting the clock to 200KHz minimum should be a good fix.

Great, that's what I was hoping to hear :). Out of curiosity, can you share
more details on how the failure occurs?

> In my experience, it's only eMMC that needs the clock to be retried

> below 400KHz and not SD or SDIO. That's because the CMD signal for
> eMMC starts out as open-drain during identification and the size of
> the pull-up on the CMD signal can require the <400KHz clock. Once eMMC
> is out of identification mode the CMD signal is switched to push-pull
> and can run at much higher clock rates.

Fair enough, I need to do some tests, some of the compute modules use an eMMC.

> I don't think that SD and SDIO have any open-drain signals, so they
> shouldn't need to retry at slower clock speeds.

Noted.

> I'm trying to get more detail on the bug, like the exact ratio of core
> clock to bus clock that causes the problem. When I first found this
> bug I was told that the failure would not happen at 200KHz, but we
> were using a 405MHz core clock.

That would be nice to have.

> One other question. Why are you using polling for the SD card, this
> newer controller supports the interrupt driven "Card Inserted" signal
> and avoids wasting time polling?

I believe the line isn't routed on RPi4.

> Al

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210405/689a49fa/attachment-0001.sig>

From navam at xilinx.com  Mon Apr  5 09:46:51 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Mon, 5 Apr 2021 08:46:51 +0000
Subject: [PATCH 2/3] fpga: region: Add fpga-region property 'power-domains'
In-Reply-To: <YGdROrOOzltI/Bbe@epycbox.lan>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-3-nava.manne@xilinx.com> <YGdROrOOzltI/Bbe@epycbox.lan>
Message-ID: <MWHPR02MB2623E90AF327BF4416D30729C2779@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Moritz,

	Thanks for the response.
Please find my response inline.

> -----Original Message-----
> From: Moritz Fischer <mdf at kernel.org>
> Sent: Friday, April 2, 2021 10:46 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: mdf at kernel.org; trix at redhat.com; robh+dt at kernel.org; Michal Simek
> <michals at xilinx.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; git <git at xilinx.com>
> Subject: Re: [PATCH 2/3] fpga: region: Add fpga-region property 'power-
> domains'
> 
> On Fri, Apr 02, 2021 at 02:50:48PM +0530, Nava kishore Manne wrote:
> > Add fpga-region property 'power-domains' to allow to handle the
> > FPGA/PL power domins.
> >
> > dt-bindings: fpga: Enable PM generic domain support
> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  .../devicetree/bindings/fpga/fpga-region.txt       | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> > b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> > index e811cf825019..969ca53bb65e 100644
> > --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> > @@ -196,6 +196,20 @@ Optional properties:
> >  - config-complete-timeout-us : The maximum time in microseconds time
> for the
> >  	FPGA to go to operating mode after the region has been
> programmed.
> >  - child nodes : devices in the FPGA after programming.
> > +- power-domains : A phandle and PM domain specifier as defined by
> bindings of
> > +	the power controller specified by phandle.
> > +Example:
> > +	fpga_full: fpga-full {
> > +                compatible = "fpga-region";
> > +                fpga-mgr = <&zynqmp_pcap>;
> > +                #address-cells = <2>;
> > +                #size-cells = <2>;
> > +                ranges;
> > +                power-domains = <&zynqmp_firmware PL_PD>;
> > +        };
> > +
> > +	The PL_PD power domain will be turned on before loading the
> > +bitstream and turned off while removing/unloading the bitstream using
> overlays.
> 
> Can multiple regions share a power-domain or is this specific to full fpga
> reconfiguration?
> 

These are generic changes and not limited to full region. If H/W supports individual power domains to control the Partial reconfiguration regions we can control the individual Partial reconfiguration region power domains as well.

Regards,
Navakishore.


From cnsztl at gmail.com  Mon Apr  5 09:52:57 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon, 5 Apr 2021 16:52:57 +0800
Subject: [PATCH] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <CAGb2v66K3SFSkm9T_D6X5o7jSYOoYpYeS_yMp1k6nMonmjiHZA@mail.gmail.com>
References: <20210405074459.4217-1-cnsztl@gmail.com>
 <CAGb2v66K3SFSkm9T_D6X5o7jSYOoYpYeS_yMp1k6nMonmjiHZA@mail.gmail.com>
Message-ID: <CAOP2_Th4+ZXtYfrr2kWnnuuzzS-HdNvN6FVtMj=5-nk4QTOvnQ@mail.gmail.com>

Hi Chen-Yu,

On 2021-04-05 16:14, Chen-Yu Tsai <wens at kernel.org> wrote:
>
> Hi,
>
> On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen <cnsztl at gmail.com> wrote:
> >
> > From: David Bauer <mail at david-bauer.net>
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work.
> >
> > Signed-off-by: David Bauer <mail at david-bauer.net>
> > Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 23 +++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > index faf496d789cf..6ba9799a95c5 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > @@ -37,6 +37,18 @@
> >                 };
> >         };
> >
> > +       vcc_rtl8153: vcc-rtl8153-regulator {
> > +               compatible = "regulator-fixed";
> > +               gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&rtl8153_en_drv>;
> > +               regulator-always-on;
> > +               regulator-name = "vcc_rtl8153";
> > +               regulator-min-microvolt = <5000000>;
> > +               regulator-max-microvolt = <5000000>;
>
> This is just a simple switch, not an actual regulator.
> It would make more sense to drop the voltage range and
> instead have the implementation pass-through voltage
> constraints from its parent.

Thanks, I'll remove them in v2.

>
> > +               enable-active-high;
> > +       };
> > +
> >         leds {
> >                 compatible = "gpio-leds";
> >                 pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> > @@ -265,6 +277,12 @@
> >                         };
> >                 };
> >         };
> > +
> > +       usb {
> > +               rtl8153_en_drv: rtl8153-en-drv {
> > +                       rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > +               };
> > +       };
> >  };
> >
> >  &io_domains {
> > @@ -364,6 +382,11 @@
> >         dr_mode = "host";
> >  };
> >
> > +&usbdrd3 {
> > +       dr_mode = "host";
> > +       status = "okay";
>
> Please also add a device node for the actual Ethernet controller, and
> set up an aliases node for it, so that the bootloader has some place
> to fill in a MAC address.

But there's no valid (unique) MAC address for both this or on-board ethernet...
They're non-existent in design.

Thanks,
Tianling.

>
>
> ChenYu
>
> > +};
> > +
> >  &usb_host0_ehci {
> >         status = "okay";
> >  };
> > --
> > 2.17.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From wens at kernel.org  Mon Apr  5 09:56:38 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 5 Apr 2021 16:56:38 +0800
Subject: [PATCH] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <CAOP2_Th4+ZXtYfrr2kWnnuuzzS-HdNvN6FVtMj=5-nk4QTOvnQ@mail.gmail.com>
References: <20210405074459.4217-1-cnsztl@gmail.com>
 <CAGb2v66K3SFSkm9T_D6X5o7jSYOoYpYeS_yMp1k6nMonmjiHZA@mail.gmail.com>
 <CAOP2_Th4+ZXtYfrr2kWnnuuzzS-HdNvN6FVtMj=5-nk4QTOvnQ@mail.gmail.com>
Message-ID: <CAGb2v65c2jFQCuAg_PhqJA+_m5Vi-cX=f8yHZ41P=_XnhBvKNQ@mail.gmail.com>

On Mon, Apr 5, 2021 at 4:53 PM Tianling Shen <cnsztl at gmail.com> wrote:
>
> Hi Chen-Yu,
>
> On 2021-04-05 16:14, Chen-Yu Tsai <wens at kernel.org> wrote:
> >
> > Hi,
> >
> > On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen <cnsztl at gmail.com> wrote:
> > >
> > > From: David Bauer <mail at david-bauer.net>
> > >
> > > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > > This is required for the USB3 attached LAN port to work.
> > >
> > > Signed-off-by: David Bauer <mail at david-bauer.net>
> > > Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> > > ---
> > >  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 23 +++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > index faf496d789cf..6ba9799a95c5 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > @@ -37,6 +37,18 @@
> > >                 };
> > >         };
> > >
> > > +       vcc_rtl8153: vcc-rtl8153-regulator {
> > > +               compatible = "regulator-fixed";
> > > +               gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> > > +               pinctrl-names = "default";
> > > +               pinctrl-0 = <&rtl8153_en_drv>;
> > > +               regulator-always-on;
> > > +               regulator-name = "vcc_rtl8153";
> > > +               regulator-min-microvolt = <5000000>;
> > > +               regulator-max-microvolt = <5000000>;
> >
> > This is just a simple switch, not an actual regulator.
> > It would make more sense to drop the voltage range and
> > instead have the implementation pass-through voltage
> > constraints from its parent.
>
> Thanks, I'll remove them in v2.
>
> >
> > > +               enable-active-high;
> > > +       };
> > > +
> > >         leds {
> > >                 compatible = "gpio-leds";
> > >                 pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> > > @@ -265,6 +277,12 @@
> > >                         };
> > >                 };
> > >         };
> > > +
> > > +       usb {
> > > +               rtl8153_en_drv: rtl8153-en-drv {
> > > +                       rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > > +               };
> > > +       };
> > >  };
> > >
> > >  &io_domains {
> > > @@ -364,6 +382,11 @@
> > >         dr_mode = "host";
> > >  };
> > >
> > > +&usbdrd3 {
> > > +       dr_mode = "host";
> > > +       status = "okay";
> >
> > Please also add a device node for the actual Ethernet controller, and
> > set up an aliases node for it, so that the bootloader has some place
> > to fill in a MAC address.
>
> But there's no valid (unique) MAC address for both this or on-board ethernet...
> They're non-existent in design.

Correct. And thanks for confirming that it's not just me and Robin that
got boards without the MAC address EEPROM...

If the user sets some MAC address in the bootloader environment by hand,
the bootloader could still potentially pass that MAC address to Linux
through the device tree. Whether the board has a valid address or not
is beside the point.


ChenYu


> Thanks,
> Tianling.
>
> >
> >
> > ChenYu
> >
> > > +};
> > > +
> > >  &usb_host0_ehci {
> > >         status = "okay";
> > >  };
> > > --
> > > 2.17.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From weifeng.voon at intel.com  Mon Apr  5 10:07:34 2021
From: weifeng.voon at intel.com (Voon, Weifeng)
Date: Mon, 5 Apr 2021 09:07:34 +0000
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <YGcPc3dan0ocRSG2@lunn.ch>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
 <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
 <20210401151044.GZ1463@shell.armlinux.org.uk>
 <SN6PR11MB3136F7A7ACA1A5C324031607887A9@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YGcPc3dan0ocRSG2@lunn.ch>
Message-ID: <SN6PR11MB3136C4F44116EC909186742C88779@SN6PR11MB3136.namprd11.prod.outlook.com>

> On Fri, Apr 02, 2021 at 07:45:04AM +0000, Voon, Weifeng wrote:
> > > > +	/* 2.5G mode only support 2500baseT full duplex only */
> > > > +	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > > > +		phylink_set(mac_supported, 2500baseT_Full);
> > > > +		phylink_set(mask, 10baseT_Half);
> > > > +		phylink_set(mask, 10baseT_Full);
> > > > +		phylink_set(mask, 100baseT_Half);
> > > > +		phylink_set(mask, 100baseT_Full);
> > > > +		phylink_set(mask, 1000baseT_Half);
> > > > +		phylink_set(mask, 1000baseT_Full);
> > > > +		phylink_set(mask, 1000baseKX_Full);
> > >
> > > Why? This seems at odds to the comment above?
> >
> > > What about 2500baseX_Full ?
> >
> > The comments explain that the PCS<->PHY link is in 2500BASE-X and why
> > 10/100/1000 link speed is mutually exclusive with 2500.
> > But the connected external PHY are twisted pair cable which only
> > supports 2500baseT_full.
> 
> The PHY should indicate what modes its supports. The PHY drivers
> get_features() call should set supported to only 2500baseT_Full, if that is
> all it supports.
> 
> What modes are actually used should then be the intersect of what both the
> MAC and the PHY indicate they can do.

Noted Andrew. Instead of masking the 10/100/1000 mode support in the MAC, we will
set the supported modes in the PCS.


From cnsztl at gmail.com  Mon Apr  5 10:34:23 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon,  5 Apr 2021 17:34:23 +0800
Subject: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
Message-ID: <20210405093423.16149-1-cnsztl@gmail.com>

From: David Bauer <mail at david-bauer.net>

Enable the USB3 port on the FriendlyARM NanoPi R2S.
This is required for the USB3 attached LAN port to work.

Signed-off-by: David Bauer <mail at david-bauer.net>
[added device node for USB Ethernet controller]
Signed-off-by: Tianling Shen <cnsztl at gmail.com>
---
 .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
index faf496d789cf..18936b393d9d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
@@ -13,6 +13,10 @@
 	model = "FriendlyElec NanoPi R2S";
 	compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
 
+	aliases {
+		ethernet1 = &r8153;
+	};
+
 	chosen {
 		stdout-path = "serial2:1500000n8";
 	};
@@ -37,6 +41,16 @@
 		};
 	};
 
+	vcc_rtl8153: vcc-rtl8153-regulator {
+		compatible = "regulator-fixed";
+		gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtl8153_en_drv>;
+		regulator-always-on;
+		regulator-name = "vcc_rtl8153";
+		enable-active-high;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
@@ -265,6 +279,12 @@
 			};
 		};
 	};
+
+	usb {
+		rtl8153_en_drv: rtl8153-en-drv {
+			rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &io_domains {
@@ -364,6 +384,18 @@
 	dr_mode = "host";
 };
 
+&usbdrd3 {
+	dr_mode = "host";
+	status = "okay";
+
+	r8153: usb-eth at 2 {
+		compatible = "realtek,rtl8153";
+		reg = <2>;
+
+		local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by U-Boot */
+	};
+};
+
 &usb_host0_ehci {
 	status = "okay";
 };
-- 
2.17.1



From jbx6244 at gmail.com  Mon Apr  5 12:03:46 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 5 Apr 2021 13:03:46 +0200
Subject: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <20210405093423.16149-1-cnsztl@gmail.com>
References: <20210405093423.16149-1-cnsztl@gmail.com>
Message-ID: <c12341c8-8590-8314-d59b-3d5903041491@gmail.com>

Hi Tianling,

On 4/5/21 11:34 AM, Tianling Shen wrote:
> From: David Bauer <mail at david-bauer.net>
> 
> Enable the USB3 port on the FriendlyARM NanoPi R2S.
> This is required for the USB3 attached LAN port to work.
> 
> Signed-off-by: David Bauer <mail at david-bauer.net>
> [added device node for USB Ethernet controller]
> Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> ---
>  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 32 +++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> index faf496d789cf..18936b393d9d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> @@ -13,6 +13,10 @@
>  	model = "FriendlyElec NanoPi R2S";
>  	compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
>  
> +	aliases {
> +		ethernet1 = &r8153;
> +	};
> +
>  	chosen {
>  		stdout-path = "serial2:1500000n8";
>  	};
> @@ -37,6 +41,16 @@
>  		};
>  	};
>  

> +	vcc_rtl8153: vcc-rtl8153-regulator {

sort nodename

> +		compatible = "regulator-fixed";
> +		gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&rtl8153_en_drv>;
> +		regulator-always-on;

> +		regulator-name = "vcc_rtl8153";

exception to the sort rule
sort regulator-name above all other regulator properties

> +		enable-active-high;

sort

----
Heiko's sort rules:

compatible
reg
interrupts
[alphabetical]
status [if needed]

----

> +	};
> +
>  	leds {
>  		compatible = "gpio-leds";
>  		pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> @@ -265,6 +279,12 @@
>  			};
>  		};
>  	};
> +
> +	usb {
> +		rtl8153_en_drv: rtl8153-en-drv {
> +			rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>  };
>  
>  &io_domains {
> @@ -364,6 +384,18 @@
>  	dr_mode = "host";
>  };
>  
> +&usbdrd3 {
> +	dr_mode = "host";
> +	status = "okay";
> +

> +	r8153: usb-eth at 2 {

With YAML undocumented additional properties and nodes generate
notifications.
We need a change in the documents below for that.
rockchip,dwc3.yaml > usb-drd.yaml > usb.yaml

Is there a standard for the usb-eth nodename?

> +		compatible = "realtek,rtl8153";

Since a while Rob has improved has scripts.
There's no escape anymore.
Add a YAML document to this serie for "realtek,rtl8153".

Improve checking for undocumented compatible strings
https://github.com/devicetree-org/dt-schema/commit/93e7ada8d53af099074cb5d53f7caa12835784e0

> +		reg = <2>;

Why 2 ?

> +

> +		local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by U-Boot */

This is a private property.
In a generic dts that's up to the user.

> +	};
> +};
> +
>  &usb_host0_ehci {
>  	status = "okay";
>  };
> 



From michael.wei.hong.sit at intel.com  Mon Apr  5 12:29:51 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Mon,  5 Apr 2021 19:29:51 +0800
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
Message-ID: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>

This patchset enables 2.5Gbps speed mode for stmmac.
Link speed mode is detected and configured at serdes power up sequence.
For 2.5G, we do not use SGMII in-band AN, we check the link speed mode
in the serdes and disable the in-band AN accordingly.

Changes:
v1 -> v2
 patch 1/2
 -Remove MAC supported link speed masking

 patch 2/2
 -Add supported link speed masking in the PCS

iperf3 and ping for 2.5Gbps and regression test on 10M/100M/1000Mbps
is done to prevent regresson issues.

10Mbps
host at EHL$ ethtool -s enp0s30f4 duplex full speed 10
[  310.132264] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down
[  312.438102] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 10Mbps/Full - flow control off
[  312.447652] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60706 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.26 MBytes  10.6 Mbits/sec    0   29.7 KBytes
[  5]   1.00-2.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   2.00-3.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   3.00-4.00   sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
[  5]   4.00-5.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   5.00-6.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   6.00-7.00   sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
[  5]   7.00-8.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   8.00-9.00   sec  1.09 MBytes  9.17 Mbits/sec    0   29.7 KBytes
[  5]   9.00-10.00  sec  1.15 MBytes  9.68 Mbits/sec    0   29.7 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  11.3 MBytes  9.47 Mbits/sec    0             sender
[  5]   0.00-10.01  sec  11.1 MBytes  9.34 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.557 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.528 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.535 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.525 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.527 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.539 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.588 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.570 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.540 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9194ms
rtt min/avg/max/mdev = 0.525/0.546/0.588/0.019 ms
host at EHL$

100Mbps
host at EHL$ ethtool -s enp0s30f4 duplex full speed 100
[  204.178572] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down
[  207.990094] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 100Mbps/Full - flow control off
[  207.999744] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60702 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.6 MBytes  97.0 Mbits/sec    1    102 KBytes
[  5]   1.00-2.00   sec  10.9 MBytes  91.7 Mbits/sec    0    102 KBytes
[  5]   2.00-3.00   sec  10.8 MBytes  90.5 Mbits/sec    0    102 KBytes
[  5]   3.00-4.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   4.00-5.00   sec  10.8 MBytes  90.6 Mbits/sec    0    102 KBytes
[  5]   5.00-6.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   6.00-7.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   7.00-8.00   sec  10.8 MBytes  90.6 Mbits/sec    0    102 KBytes
[  5]   8.00-9.00   sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
[  5]   9.00-10.00  sec  11.0 MBytes  92.6 Mbits/sec    0    102 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   110 MBytes  92.3 Mbits/sec    1             sender
[  5]   0.00-10.00  sec   109 MBytes  91.8 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.331 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.322 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.315 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.295 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.307 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.294 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.297 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9215ms
rtt min/avg/max/mdev = 0.292/0.306/0.331/0.012 ms

1G speed
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 60698 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    533 KBytes
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec    0    591 KBytes
[  5]   2.00-3.00   sec   113 MBytes   945 Mbits/sec    0    621 KBytes
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    621 KBytes
[  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec    0    764 KBytes
[  5]   5.00-6.00   sec   112 MBytes   944 Mbits/sec    0    764 KBytes
[  5]   6.00-7.00   sec   111 MBytes   933 Mbits/sec    0    803 KBytes
[  5]   7.00-8.00   sec   112 MBytes   944 Mbits/sec    0    803 KBytes
[  5]   8.00-9.00   sec   112 MBytes   944 Mbits/sec    0    843 KBytes
[  5]   9.00-10.00  sec   112 MBytes   944 Mbits/sec    0    843 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
[  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.277 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.277 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.286 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.330 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.274 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9196ms
rtt min/avg/max/mdev = 0.272/0.286/0.330/0.017 ms

2.5G speed
host at EHL$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.2 port 55160 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   175 MBytes  1.47 Gbits/sec   17    683 KBytes
[  5]   1.00-2.00   sec   202 MBytes  1.70 Gbits/sec    0    707 KBytes
[  5]   2.00-3.00   sec   204 MBytes  1.71 Gbits/sec    0    751 KBytes
[  5]   3.00-4.00   sec   204 MBytes  1.71 Gbits/sec    0    773 KBytes
[  5]   4.00-5.00   sec   202 MBytes  1.70 Gbits/sec    0    773 KBytes
[  5]   5.00-6.00   sec   204 MBytes  1.71 Gbits/sec    0    798 KBytes
[  5]   6.00-7.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   7.00-8.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   8.00-9.00   sec   204 MBytes  1.71 Gbits/sec    0    807 KBytes
[  5]   9.00-10.00  sec   202 MBytes  1.70 Gbits/sec    0    807 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.96 GBytes  1.68 Gbits/sec   17             sender
[  5]   0.00-10.00  sec  1.96 GBytes  1.68 Gbits/sec                  receiver

iperf Done.
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.671 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.300 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.291 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.296 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.301 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.328 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.306 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.293 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9251ms
rtt min/avg/max/mdev = 0.291/0.338/0.671/0.111 ms

Voon Weifeng (2):
  net: stmmac: enable 2.5Gbps link speed
  net: pcs: configure xpcs 2.5G speed mode

 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 44 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h | 13 ++++++
 .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++-
 drivers/net/pcs/pcs-xpcs.c                    | 39 ++++++++++++++++
 include/linux/pcs/pcs-xpcs.h                  |  1 +
 include/linux/stmmac.h                        |  2 +
 7 files changed, 117 insertions(+), 3 deletions(-)

-- 
2.17.1



From michael.wei.hong.sit at intel.com  Mon Apr  5 12:29:52 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Mon,  5 Apr 2021 19:29:52 +0800
Subject: [PATCH net-next v2 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210405112953.26008-2-michael.wei.hong.sit@intel.com>

From: Voon Weifeng <weifeng.voon at intel.com>

The MAC support 2.5G mode when the PCS is in 1000BASE-T mode. The
2.5G mode of operation is functionally same as 1000BASE-T mode,
except that the clock rate is 2.5 times the original rate.
In this mode, the serdes/PHY operates at a serial baud rate of
3.125 Gbps and the PCS data path and GMII interface of the MAC
operate at 312.5 MHz instead of 125 MHz.

The MAC running in 10M/100M/1G mode or 2.5G mode depends on
the link speed mode in the serdes.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 44 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.h | 13 ++++++
 .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  1 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 +++++++-
 include/linux/stmmac.h                        |  2 +
 5 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 3d9a57043af2..4f70a12b42f9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -102,6 +102,22 @@ static int intel_serdes_powerup(struct net_device *ndev, void *priv_data)
 
 	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
 
+	/* Set the serdes rate and the PCLK rate */
+	data = mdiobus_read(priv->mii, serdes_phy_addr,
+			    SERDES_GCR0);
+
+	data &= ~SERDES_RATE_MASK;
+	data &= ~SERDES_PCLK_MASK;
+
+	if (priv->plat->speed_2500_en)
+		data |= SERDES_RATE_PCIE_GEN2 << SERDES_RATE_PCIE_SHIFT |
+			SERDES_PCLK_37p5MHZ << SERDES_PCLK_SHIFT;
+	else
+		data |= SERDES_RATE_PCIE_GEN1 << SERDES_RATE_PCIE_SHIFT |
+			SERDES_PCLK_70MHZ << SERDES_PCLK_SHIFT;
+
+	mdiobus_write(priv->mii, serdes_phy_addr, SERDES_GCR0, data);
+
 	/* assert clk_req */
 	data = mdiobus_read(priv->mii, serdes_phy_addr, SERDES_GCR0);
 	data |= SERDES_PLL_CLK;
@@ -220,6 +236,28 @@ static void intel_serdes_powerdown(struct net_device *ndev, void *intel_data)
 	}
 }
 
+static bool intel_speed_mode_2500(struct net_device *ndev, void *intel_data)
+{
+	struct intel_priv_data *intel_priv = intel_data;
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int serdes_phy_addr = 0;
+	u32 data = 0;
+
+	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
+
+	/* Determine the link speed mode: 2.5Gbps/1Gbps */
+	data = mdiobus_read(priv->mii, serdes_phy_addr,
+			    SERDES_GCR);
+
+	if (((data & SERDES_LINK_MODE_MASK) >> SERDES_LINK_MODE_SHIFT) ==
+	    SERDES_LINK_MODE_2G5) {
+		dev_info(priv->device, "Link Speed Mode: 2.5Gbps\n");
+		return true;
+	} else {
+		return false;
+	}
+}
+
 /* Program PTP Clock Frequency for different variant of
  * Intel mGBE that has slightly different GPO mapping
  */
@@ -540,7 +578,7 @@ static int ehl_sgmii_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 1;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
-
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 
@@ -593,6 +631,7 @@ static int ehl_pse0_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return ehl_pse0_common_data(pdev, plat);
@@ -631,6 +670,7 @@ static int ehl_pse1_sgmii1g_data(struct pci_dev *pdev,
 				 struct plat_stmmacenet_data *plat)
 {
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return ehl_pse1_common_data(pdev, plat);
@@ -655,6 +695,7 @@ static int tgl_sgmii_phy0_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 1;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return tgl_common_data(pdev, plat);
@@ -669,6 +710,7 @@ static int tgl_sgmii_phy1_data(struct pci_dev *pdev,
 {
 	plat->bus_id = 2;
 	plat->phy_interface = PHY_INTERFACE_MODE_SGMII;
+	plat->speed_mode_2500 = intel_speed_mode_2500;
 	plat->serdes_powerup = intel_serdes_powerup;
 	plat->serdes_powerdown = intel_serdes_powerdown;
 	return tgl_common_data(pdev, plat);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index e723096c0b15..021a5c178d97 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -9,6 +9,7 @@
 #define POLL_DELAY_US 8
 
 /* SERDES Register */
+#define SERDES_GCR	0x0	/* Global Conguration */
 #define SERDES_GSR0	0x5	/* Global Status Reg0 */
 #define SERDES_GCR0	0xb	/* Global Configuration Reg0 */
 
@@ -16,8 +17,20 @@
 #define SERDES_PLL_CLK		BIT(0)		/* PLL clk valid signal */
 #define SERDES_RST		BIT(2)		/* Serdes Reset */
 #define SERDES_PWR_ST_MASK	GENMASK(6, 4)	/* Serdes Power state*/
+#define SERDES_RATE_MASK	GENMASK(9, 8)
+#define SERDES_PCLK_MASK	GENMASK(14, 12)	/* PCLK rate to PHY */
+#define SERDES_LINK_MODE_MASK	GENMASK(2, 1)
+#define SERDES_LINK_MODE_SHIFT	1
 #define SERDES_PWR_ST_SHIFT	4
 #define SERDES_PWR_ST_P0	0x0
 #define SERDES_PWR_ST_P3	0x3
+#define SERDES_LINK_MODE_2G5	0x3
+#define SERSED_LINK_MODE_1G	0x2
+#define SERDES_PCLK_37p5MHZ	0x0
+#define SERDES_PCLK_70MHZ	0x1
+#define SERDES_RATE_PCIE_GEN1	0x0
+#define SERDES_RATE_PCIE_GEN2	0x1
+#define SERDES_RATE_PCIE_SHIFT	8
+#define SERDES_PCLK_SHIFT	12
 
 #endif /* __DWMAC_INTEL_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 95864f014ffa..4c3f27a9e8b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -1357,6 +1357,7 @@ int dwmac4_setup(struct stmmac_priv *priv)
 	mac->link.speed10 = GMAC_CONFIG_PS;
 	mac->link.speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
 	mac->link.speed1000 = 0;
+	mac->link.speed2500 = GMAC_CONFIG_FES;
 	mac->link.speed_mask = GMAC_CONFIG_FES | GMAC_CONFIG_PS;
 	mac->mii.addr = GMAC_MDIO_ADDR;
 	mac->mii.data = GMAC_MDIO_DATA;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d34388b1ffcc..7def80c6347e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -882,6 +882,11 @@ static void stmmac_validate(struct phylink_config *config,
 	phylink_set(mac_supported, Asym_Pause);
 	phylink_set_port_modes(mac_supported);
 
+	/* 2.5G mode only support 2500baseT full duplex only */
+	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
+		phylink_set(mac_supported, 2500baseT_Full);
+	}
+
 	/* Cut down 1G if asked to */
 	if ((max_speed > 0) && (max_speed < 1000)) {
 		phylink_set(mask, 1000baseT_Full);
@@ -1192,8 +1197,13 @@ static int stmmac_phy_setup(struct stmmac_priv *priv)
 	priv->phylink_config.dev = &priv->dev->dev;
 	priv->phylink_config.type = PHYLINK_NETDEV;
 	priv->phylink_config.pcs_poll = true;
-	priv->phylink_config.ovr_an_inband =
-		priv->plat->mdio_bus_data->xpcs_an_inband;
+	/* For 2.5G, we do not use SGMII in-band AN */
+	if (priv->plat->speed_2500_en) {
+		priv->phylink_config.ovr_an_inband = false;
+	} else {
+		priv->phylink_config.ovr_an_inband =
+			priv->plat->mdio_bus_data->xpcs_an_inband;
+	}
 
 	if (!fwnode)
 		fwnode = dev_fwnode(priv->device);
@@ -5815,6 +5825,11 @@ int stmmac_dvr_probe(struct device *device,
 		}
 	}
 
+	if (priv->plat->speed_mode_2500) {
+		priv->plat->speed_2500_en = priv->plat->speed_mode_2500(ndev,
+									priv->plat->bsp_priv);
+	}
+
 	ret = stmmac_phy_setup(priv);
 	if (ret) {
 		netdev_err(ndev, "failed to setup phy (%d)\n", ret);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..a43ce24d2a42 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -209,6 +209,7 @@ struct plat_stmmacenet_data {
 	void (*fix_mac_speed)(void *priv, unsigned int speed);
 	int (*serdes_powerup)(struct net_device *ndev, void *priv);
 	void (*serdes_powerdown)(struct net_device *ndev, void *priv);
+	bool (*speed_mode_2500)(struct net_device *ndev, void *priv);
 	void (*ptp_clk_freq_config)(void *priv);
 	int (*init)(struct platform_device *pdev, void *priv);
 	void (*exit)(struct platform_device *pdev, void *priv);
@@ -234,6 +235,7 @@ struct plat_stmmacenet_data {
 	int has_xgmac;
 	bool vlan_fail_q_en;
 	u8 vlan_fail_q;
+	bool speed_2500_en;
 	unsigned int eee_usecs_rate;
 	struct pci_dev *pdev;
 	bool has_crossts;
-- 
2.17.1



From michael.wei.hong.sit at intel.com  Mon Apr  5 12:29:53 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Mon,  5 Apr 2021 19:29:53 +0800
Subject: [PATCH net-next v2 2/2] net: pcs: configure xpcs 2.5G speed mode
In-Reply-To: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210405112953.26008-3-michael.wei.hong.sit@intel.com>

From: Voon Weifeng <weifeng.voon at intel.com>

Besides setting 2.5G configuration, this patch will also disable
automatic speed mode change. This is due to the 2.5G mode is
using the same functionality as 1G mode except the clock rate is
2.5 times the original rate. Hence, auto-negotiation is disabled
to make sure it will only be in 2.5G mode.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  1 +
 drivers/net/pcs/pcs-xpcs.c                    | 39 +++++++++++++++++++
 include/linux/pcs/pcs-xpcs.h                  |  1 +
 3 files changed, 41 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7def80c6347e..97545cce3430 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5828,6 +5828,7 @@ int stmmac_dvr_probe(struct device *device,
 	if (priv->plat->speed_mode_2500) {
 		priv->plat->speed_2500_en = priv->plat->speed_mode_2500(ndev,
 									priv->plat->bsp_priv);
+		priv->hw->xpcs_args.speed_2500_en = priv->plat->speed_2500_en;
 	}
 
 	ret = stmmac_phy_setup(priv);
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 944ba105cac1..bd651299d75f 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -60,10 +60,14 @@
 
 /* Clause 37 Defines */
 /* VR MII MMD registers offsets */
+#define DW_VR_MII_MMD_CTRL		0x0000
 #define DW_VR_MII_DIG_CTRL1		0x8000
 #define DW_VR_MII_AN_CTRL		0x8001
 #define DW_VR_MII_AN_INTR_STS		0x8002
 
+/* Enable 2.5G Mode */
+#define DW_VR_MII_DIG_CTRL1_2G5_EN	BIT(2)
+
 /* VR_MII_DIG_CTRL1 */
 #define DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW		BIT(9)
 
@@ -86,6 +90,11 @@
 #define DW_VR_MII_C37_ANSGM_SP_1000		0x2
 #define DW_VR_MII_C37_ANSGM_SP_LNKSTS		BIT(4)
 
+/* SR MII MMD Control defines */
+#define AN_CL37_EN		BIT(12)	/* Enable Clause 37 auto-nego */
+#define SGMII_SPEED_SS13	BIT(13)	/* SGMII speed along with SS6 */
+#define SGMII_SPEED_SS6		BIT(6)	/* SGMII speed along with SS13 */
+
 static const int xpcs_usxgmii_features[] = {
 	ETHTOOL_LINK_MODE_Pause_BIT,
 	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
@@ -141,6 +150,7 @@ static const int xpcs_sgmii_features[] = {
 	ETHTOOL_LINK_MODE_100baseT_Full_BIT,
 	ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
 	ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
 	__ETHTOOL_LINK_MODE_MASK_NBITS,
 };
 
@@ -645,6 +655,16 @@ static int xpcs_validate(struct mdio_xpcs_args *xpcs,
 			 unsigned long *supported,
 			 struct phylink_link_state *state)
 {
+	if (xpcs->speed_2500_en) {
+		__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+		phylink_set(mask, 10baseT_Half);
+		phylink_set(mask, 10baseT_Full);
+		phylink_set(mask, 100baseT_Half);
+		phylink_set(mask, 100baseT_Full);
+		phylink_set(mask, 1000baseT_Half);
+		phylink_set(mask, 1000baseT_Full);
+		linkmode_andnot(xpcs->supported, xpcs->supported, mask);
+	}
 	linkmode_and(supported, supported, xpcs->supported);
 	linkmode_and(state->advertising, state->advertising, xpcs->supported);
 	return 0;
@@ -654,6 +674,25 @@ static int xpcs_config_aneg_c37_sgmii(struct mdio_xpcs_args *xpcs)
 {
 	int ret;
 
+	if (xpcs->speed_2500_en) {
+		ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1);
+		if (ret < 0)
+			return ret;
+		ret |= DW_VR_MII_DIG_CTRL1_2G5_EN;
+		ret &= ~DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
+		ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1, ret);
+		if (ret < 0)
+			return ret;
+
+		ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL);
+		if (ret < 0)
+			return ret;
+		ret &= ~AN_CL37_EN;
+		ret |= SGMII_SPEED_SS6;
+		ret &= ~SGMII_SPEED_SS13;
+		return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL, ret);
+	}
+
 	/* For AN for C37 SGMII mode, the settings are :-
 	 * 1) VR_MII_AN_CTRL Bit(2:1)[PCS_MODE] = 10b (SGMII AN)
 	 * 2) VR_MII_AN_CTRL Bit(3) [TX_CONFIG] = 0b (MAC side SGMII)
diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h
index 2cb5188a7ef1..6b94b2a48e0c 100644
--- a/include/linux/pcs/pcs-xpcs.h
+++ b/include/linux/pcs/pcs-xpcs.h
@@ -19,6 +19,7 @@ struct mdio_xpcs_args {
 	struct mii_bus *bus;
 	int addr;
 	int an_mode;
+	bool speed_2500_en;
 };
 
 struct mdio_xpcs_ops {
-- 
2.17.1



From wens at kernel.org  Mon Apr  5 12:56:21 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 5 Apr 2021 19:56:21 +0800
Subject: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <c12341c8-8590-8314-d59b-3d5903041491@gmail.com>
References: <20210405093423.16149-1-cnsztl@gmail.com>
 <c12341c8-8590-8314-d59b-3d5903041491@gmail.com>
Message-ID: <CAGb2v65vdH-6h-y_SLUqSqgAOh3+2=BHV8hgABbKcEF23GBWkg@mail.gmail.com>

On Mon, Apr 5, 2021 at 7:03 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer <mail at david-bauer.net>
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work.
> >
> > Signed-off-by: David Bauer <mail at david-bauer.net>
> > [added device node for USB Ethernet controller]
> > Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 32 +++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > index faf496d789cf..18936b393d9d 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > @@ -13,6 +13,10 @@
> >       model = "FriendlyElec NanoPi R2S";
> >       compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
> >
> > +     aliases {
> > +             ethernet1 = &r8153;
> > +     };
> > +
> >       chosen {
> >               stdout-path = "serial2:1500000n8";
> >       };
> > @@ -37,6 +41,16 @@
> >               };
> >       };
> >
>
> > +     vcc_rtl8153: vcc-rtl8153-regulator {
>
> sort nodename
>
> > +             compatible = "regulator-fixed";
> > +             gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&rtl8153_en_drv>;
> > +             regulator-always-on;
>
> > +             regulator-name = "vcc_rtl8153";
>
> exception to the sort rule
> sort regulator-name above all other regulator properties
>
> > +             enable-active-high;
>
> sort
>
> ----
> Heiko's sort rules:
>
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
>
> ----
>
> > +     };
> > +
> >       leds {
> >               compatible = "gpio-leds";
> >               pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> > @@ -265,6 +279,12 @@
> >                       };
> >               };
> >       };
> > +
> > +     usb {
> > +             rtl8153_en_drv: rtl8153-en-drv {
> > +                     rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > +             };
> > +     };
> >  };
> >
> >  &io_domains {
> > @@ -364,6 +384,18 @@
> >       dr_mode = "host";
> >  };
> >
> > +&usbdrd3 {
> > +     dr_mode = "host";
> > +     status = "okay";
> > +
>
> > +     r8153: usb-eth at 2 {
>
> With YAML undocumented additional properties and nodes generate
> notifications.
> We need a change in the documents below for that.
> rockchip,dwc3.yaml > usb-drd.yaml > usb.yaml
>
> Is there a standard for the usb-eth nodename?

The USB devices binding seems to specify "device" and then
"interface" sub-nodes.

> > +             compatible = "realtek,rtl8153";
>
> Since a while Rob has improved has scripts.
> There's no escape anymore.
> Add a YAML document to this serie for "realtek,rtl8153".

Actually it should be "usbbda,8153", which conforms to

    Documentation/devicetree/bindings/usb/usb-device.yaml

Giving "realtek,rtl8153" to the kernel will not help it match any
device.

ChenYu

> Improve checking for undocumented compatible strings
> https://github.com/devicetree-org/dt-schema/commit/93e7ada8d53af099074cb5d53f7caa12835784e0
>
> > +             reg = <2>;
>
> Why 2 ?
>
> > +
>
> > +             local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by U-Boot */
>
> This is a private property.
> In a generic dts that's up to the user.
>
> > +     };
> > +};
> > +
> >  &usb_host0_ehci {
> >       status = "okay";
> >  };
> >
>


From jbx6244 at gmail.com  Mon Apr  5 13:06:10 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 5 Apr 2021 14:06:10 +0200
Subject: [PATCH v6 1/4] usb: dwc3: of-simple: bail probe if no dwc3 child
 node
In-Reply-To: <YGq2IaygRQaAcLli@kroah.com>
References: <20210401213652.14676-1-jbx6244@gmail.com>
 <20210401213652.14676-2-jbx6244@gmail.com> <YGq2IaygRQaAcLli@kroah.com>
Message-ID: <abd513bc-dee9-d87b-6841-338bfb2f30d0@gmail.com>

On 4/5/21 9:02 AM, Greg KH wrote:
> On Thu, Apr 01, 2021 at 11:36:49PM +0200, Johan Jonker wrote:
>> For some of the dwc3-of-simple compatible SoCs we
>> don't want to bind this driver to a dwc3 node,
>> but bind that node to the 'snps,dwc3' driver instead.
>> The kernel has no logic to decide which driver to bind
>> to if there are 2 matching drivers, so bail probe if no
>> dwc3 child node.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---
>>  drivers/usb/dwc3/dwc3-of-simple.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c b/drivers/usb/dwc3/dwc3-of-simple.c
>> index 71fd620c5..8d3baa5df 100644
>> --- a/drivers/usb/dwc3/dwc3-of-simple.c
>> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
>> @@ -38,6 +38,10 @@ static int dwc3_of_simple_probe(struct platform_device *pdev)
>>  
>>  	int			ret;
>>  
>> +	/* Bail probe if no dwc3 child node. */
>> +	if (!of_get_compatible_child(dev->of_node, "snps,dwc3"))
>> +		return -ENODEV;
> 

> Why is this part of the "convert to yaml" patch series?  Shouldn't this
> be a separate, independant patch?
independent


Hi Greg,

As pointed out by Rob in the v3 review process the YAML conversion has
some side effects for new dt files. A good habit is to fix things before
they become in effect. That's why this patch is placed before the dtsi
changes and why Heiko asked to have a look at it.

For the sake of completeness there are other less optimal options:
- remove rk3399 support from dwc3-of-simple.c
- unselect CONFIG_USB_DWC3_OF_SIMPLE for new rk3399 device trees

In that case at least have it on record why USB maintainers didn't apply
it in case someone else start to complain about it later when Heiko goes
ahead with it.

Johan Jonker

> 
> thanks,
> 
> greg k-h
> 



From andrew at lunn.ch  Mon Apr  5 13:43:13 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 5 Apr 2021 14:43:13 +0200
Subject: [PATCH net-next 1/2] net: stmmac: enable 2.5Gbps link speed
In-Reply-To: <SN6PR11MB3136C4F44116EC909186742C88779@SN6PR11MB3136.namprd11.prod.outlook.com>
References: <20210401150152.22444-1-michael.wei.hong.sit@intel.com>
 <20210401150152.22444-2-michael.wei.hong.sit@intel.com>
 <20210401151044.GZ1463@shell.armlinux.org.uk>
 <SN6PR11MB3136F7A7ACA1A5C324031607887A9@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YGcPc3dan0ocRSG2@lunn.ch>
 <SN6PR11MB3136C4F44116EC909186742C88779@SN6PR11MB3136.namprd11.prod.outlook.com>
Message-ID: <YGsF4aGguqsfaQQ3@lunn.ch>

On Mon, Apr 05, 2021 at 09:07:34AM +0000, Voon, Weifeng wrote:
> > On Fri, Apr 02, 2021 at 07:45:04AM +0000, Voon, Weifeng wrote:
> > > > > +	/* 2.5G mode only support 2500baseT full duplex only */
> > > > > +	if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> > > > > +		phylink_set(mac_supported, 2500baseT_Full);
> > > > > +		phylink_set(mask, 10baseT_Half);
> > > > > +		phylink_set(mask, 10baseT_Full);
> > > > > +		phylink_set(mask, 100baseT_Half);
> > > > > +		phylink_set(mask, 100baseT_Full);
> > > > > +		phylink_set(mask, 1000baseT_Half);
> > > > > +		phylink_set(mask, 1000baseT_Full);
> > > > > +		phylink_set(mask, 1000baseKX_Full);
> > > >
> > > > Why? This seems at odds to the comment above?
> > >
> > > > What about 2500baseX_Full ?
> > >
> > > The comments explain that the PCS<->PHY link is in 2500BASE-X and why
> > > 10/100/1000 link speed is mutually exclusive with 2500.
> > > But the connected external PHY are twisted pair cable which only
> > > supports 2500baseT_full.
> > 
> > The PHY should indicate what modes its supports. The PHY drivers
> > get_features() call should set supported to only 2500baseT_Full, if that is
> > all it supports.
> > 
> > What modes are actually used should then be the intersect of what both the
> > MAC and the PHY indicate they can do.
> 
> Noted Andrew. Instead of masking the 10/100/1000 mode support in the MAC, we will
> set the supported modes in the PCS.

PCS?

You said:

> > > But the connected external PHY are twisted pair cable which only
> > > supports 2500baseT_full.

So it should be the PHY, not the PCS, which indicates it only supports
2500baseT_full.

	Andrew


From lkp at intel.com  Mon Apr  5 13:46:00 2021
From: lkp at intel.com (kernel test robot)
Date: Mon, 5 Apr 2021 20:46:00 +0800
Subject: [arm-platforms:kvm-arm64/nvhe-panic-info 5/5]
 arch/arm64/kvm/handle_exit.c:318:4: error: implicit declaration of function
 'bug_get_file_line'
Message-ID: <202104052054.jTyIABEE-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/nvhe-panic-info
head:   aec0fae62e47050019474936248a311a0ab08705
commit: aec0fae62e47050019474936248a311a0ab08705 [5/5] KVM: arm64: Log source when panicking from nVHE hyp
config: arm64-randconfig-r021-20210405 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=aec0fae62e47050019474936248a311a0ab08705
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms kvm-arm64/nvhe-panic-info
        git checkout aec0fae62e47050019474936248a311a0ab08705
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   arch/arm64/kvm/handle_exit.c:177:21: warning: initialized field overwritten [-Woverride-init]
     177 |  [ESR_ELx_EC_WFx] = kvm_handle_wfx,
         |                     ^~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:177:21: note: (near initialization for 'arm_exit_handlers[1]')
   arch/arm64/kvm/handle_exit.c:178:25: warning: initialized field overwritten [-Woverride-init]
     178 |  [ESR_ELx_EC_CP15_32] = kvm_handle_cp15_32,
         |                         ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:178:25: note: (near initialization for 'arm_exit_handlers[3]')
   arch/arm64/kvm/handle_exit.c:179:25: warning: initialized field overwritten [-Woverride-init]
     179 |  [ESR_ELx_EC_CP15_64] = kvm_handle_cp15_64,
         |                         ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:179:25: note: (near initialization for 'arm_exit_handlers[4]')
   arch/arm64/kvm/handle_exit.c:180:25: warning: initialized field overwritten [-Woverride-init]
     180 |  [ESR_ELx_EC_CP14_MR] = kvm_handle_cp14_32,
         |                         ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:180:25: note: (near initialization for 'arm_exit_handlers[5]')
   arch/arm64/kvm/handle_exit.c:181:25: warning: initialized field overwritten [-Woverride-init]
     181 |  [ESR_ELx_EC_CP14_LS] = kvm_handle_cp14_load_store,
         |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:181:25: note: (near initialization for 'arm_exit_handlers[6]')
   arch/arm64/kvm/handle_exit.c:182:25: warning: initialized field overwritten [-Woverride-init]
     182 |  [ESR_ELx_EC_CP14_64] = kvm_handle_cp14_64,
         |                         ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:182:25: note: (near initialization for 'arm_exit_handlers[12]')
   arch/arm64/kvm/handle_exit.c:183:23: warning: initialized field overwritten [-Woverride-init]
     183 |  [ESR_ELx_EC_HVC32] = handle_hvc,
         |                       ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:183:23: note: (near initialization for 'arm_exit_handlers[18]')
   arch/arm64/kvm/handle_exit.c:184:23: warning: initialized field overwritten [-Woverride-init]
     184 |  [ESR_ELx_EC_SMC32] = handle_smc,
         |                       ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:184:23: note: (near initialization for 'arm_exit_handlers[19]')
   arch/arm64/kvm/handle_exit.c:185:23: warning: initialized field overwritten [-Woverride-init]
     185 |  [ESR_ELx_EC_HVC64] = handle_hvc,
         |                       ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:185:23: note: (near initialization for 'arm_exit_handlers[22]')
   arch/arm64/kvm/handle_exit.c:186:23: warning: initialized field overwritten [-Woverride-init]
     186 |  [ESR_ELx_EC_SMC64] = handle_smc,
         |                       ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:186:23: note: (near initialization for 'arm_exit_handlers[23]')
   arch/arm64/kvm/handle_exit.c:187:23: warning: initialized field overwritten [-Woverride-init]
     187 |  [ESR_ELx_EC_SYS64] = kvm_handle_sys_reg,
         |                       ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:187:23: note: (near initialization for 'arm_exit_handlers[24]')
   arch/arm64/kvm/handle_exit.c:188:21: warning: initialized field overwritten [-Woverride-init]
     188 |  [ESR_ELx_EC_SVE] = handle_sve,
         |                     ^~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:188:21: note: (near initialization for 'arm_exit_handlers[25]')
   arch/arm64/kvm/handle_exit.c:189:26: warning: initialized field overwritten [-Woverride-init]
     189 |  [ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
         |                          ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:189:26: note: (near initialization for 'arm_exit_handlers[32]')
   arch/arm64/kvm/handle_exit.c:190:26: warning: initialized field overwritten [-Woverride-init]
     190 |  [ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
         |                          ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:190:26: note: (near initialization for 'arm_exit_handlers[36]')
   arch/arm64/kvm/handle_exit.c:191:28: warning: initialized field overwritten [-Woverride-init]
     191 |  [ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
         |                            ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:191:28: note: (near initialization for 'arm_exit_handlers[50]')
   arch/arm64/kvm/handle_exit.c:192:28: warning: initialized field overwritten [-Woverride-init]
     192 |  [ESR_ELx_EC_WATCHPT_LOW]= kvm_handle_guest_debug,
         |                            ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:192:28: note: (near initialization for 'arm_exit_handlers[52]')
   arch/arm64/kvm/handle_exit.c:193:28: warning: initialized field overwritten [-Woverride-init]
     193 |  [ESR_ELx_EC_BREAKPT_LOW]= kvm_handle_guest_debug,
         |                            ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:193:28: note: (near initialization for 'arm_exit_handlers[48]')
   arch/arm64/kvm/handle_exit.c:194:24: warning: initialized field overwritten [-Woverride-init]
     194 |  [ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
         |                        ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:194:24: note: (near initialization for 'arm_exit_handlers[56]')
   arch/arm64/kvm/handle_exit.c:195:23: warning: initialized field overwritten [-Woverride-init]
     195 |  [ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
         |                       ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:195:23: note: (near initialization for 'arm_exit_handlers[60]')
   arch/arm64/kvm/handle_exit.c:196:26: warning: initialized field overwritten [-Woverride-init]
     196 |  [ESR_ELx_EC_FP_ASIMD] = handle_no_fpsimd,
         |                          ^~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:196:26: note: (near initialization for 'arm_exit_handlers[7]')
   arch/arm64/kvm/handle_exit.c:197:21: warning: initialized field overwritten [-Woverride-init]
     197 |  [ESR_ELx_EC_PAC] = kvm_handle_ptrauth,
         |                     ^~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c:197:21: note: (near initialization for 'arm_exit_handlers[9]')
   arch/arm64/kvm/handle_exit.c:295:24: warning: no previous prototype for 'nvhe_hyp_panic_handler' [-Wmissing-prototypes]
     295 | void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr,
         |                        ^~~~~~~~~~~~~~~~~~~~~~
   arch/arm64/kvm/handle_exit.c: In function 'nvhe_hyp_panic_handler':
>> arch/arm64/kvm/handle_exit.c:318:4: error: implicit declaration of function 'bug_get_file_line' [-Werror=implicit-function-declaration]
     318 |    bug_get_file_line(bug, &file, &line);
         |    ^~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/bug_get_file_line +318 arch/arm64/kvm/handle_exit.c

   294	
   295	void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr,
   296						      u64 par, uintptr_t vcpu,
   297						      u64 far, u64 hpfar) {
   298		u64 elr_in_kimg = __phys_to_kimg(__hyp_pa(elr));
   299		u64 hyp_offset = elr_in_kimg - kaslr_offset() - elr;
   300		u64 mode = spsr & PSR_MODE_MASK;
   301	
   302		/*
   303		 * The nVHE hyp symbols are not included by kallsyms to avoid issues
   304		 * with aliasing. That means that the symbols cannot be printed with the
   305		 * "%pS" format specifier, so fall back to the vmlinux address if
   306		 * there's no better option.
   307		 */
   308		if (mode != PSR_MODE_EL2t && mode != PSR_MODE_EL2h) {
   309			kvm_err("Invalid host exception to nVHE hyp!\n");
   310		} else if (ESR_ELx_EC(esr) == ESR_ELx_EC_BRK64 &&
   311			   (esr & ESR_ELx_BRK64_ISS_COMMENT_MASK) == BUG_BRK_IMM) {
   312			struct bug_entry *bug = find_bug(elr_in_kimg);
   313			const char *file = NULL;
   314			unsigned int line = 0;
   315	
   316			/* All hyp bugs, including warnings, are treated as fatal. */
   317			if (bug)
 > 318				bug_get_file_line(bug, &file, &line);

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36482 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210405/b2592258/attachment-0001.gz>

From andrew at lunn.ch  Mon Apr  5 14:11:08 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 5 Apr 2021 15:11:08 +0200
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
Message-ID: <YGsMbBW9h4H1y/T8@lunn.ch>

On Mon, Apr 05, 2021 at 07:29:51PM +0800, Michael Sit Wei Hong wrote:
> This patchset enables 2.5Gbps speed mode for stmmac.
> Link speed mode is detected and configured at serdes power up sequence.
> For 2.5G, we do not use SGMII in-band AN, we check the link speed mode
> in the serdes and disable the in-band AN accordingly.
> 
> Changes:
> v1 -> v2
>  patch 1/2
>  -Remove MAC supported link speed masking
> 
>  patch 2/2
>  -Add supported link speed masking in the PCS

So there still some confusion here.

------------            --------
|MAC - PCS |---serdes---| PHY  |--- copper 
------------            --------


You have a MAC and an PCS in the stmmac IP block. That then has some
sort of SERDES interface, running 1000BaseX, SGMII, SGMII overclocked
at 2.5G or 25000BaseX. Connected to the SERDES you have a PHY which
converts to copper, giving you 2500BaseT.

You said earlier, that the PHY can only do 2500BaseT. So it should be
the PHY driver which sets supported to 2500BaseT and no other speeds.

You should think about when somebody uses this MAC with a different
PHY, one that can do the full range of 10/half through to 2.5G
full. What generally happens is that the PHY performs auto-neg to
determine the link speed. For 10M-1G speeds the PHY will configure its
SERDES interface to SGMII and phylink will ask the PCS to also be
configured to SGMII. If the PHY negotiates 2500BaseT, it will
configure its side of the SERDES to 2500BaseX or SGMII overclocked at
2.5G. Again, phylink will ask the PCS to match what the PHY is doing.

So, where exactly is the limitation in your hardware? PCS or PHY?

     Andrew


From mhiramat at kernel.org  Mon Apr  5 14:24:36 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Mon, 5 Apr 2021 22:24:36 +0900
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
Message-ID: <20210405222436.4fda9a930676d95e862744af@kernel.org>

Hi Madhaven,

On Sat, 3 Apr 2021 22:29:12 -0500
"Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:


> >> Check for kretprobe
> >> ===================
> >>
> >> For functions with a kretprobe set up, probe code executes on entry
> >> to the function and replaces the return address in the stack frame with a
> >> kretprobe trampoline. Whenever the function returns, control is
> >> transferred to the trampoline. The trampoline eventually returns to the
> >> original return address.
> >>
> >> A stack trace taken while executing in the function (or in functions that
> >> get called from the function) will not show the original return address.
> >> Similarly, a stack trace taken while executing in the trampoline itself
> >> (and functions that get called from the trampoline) will not show the
> >> original return address. This means that the caller of the probed function
> >> will not show. This makes the stack trace unreliable.
> >>
> >> Add the kretprobe trampoline to special_functions[].
> >>
> >> FYI, each task contains a task->kretprobe_instances list that can
> >> theoretically be consulted to find the orginal return address. But I am
> >> not entirely sure how to safely traverse that list for stack traces
> >> not on the current process. So, I have taken the easy way out.
> > 
> > For kretprobes, unwinding from the trampoline or kretprobe handler
> > shouldn't be a reliability concern for live patching, for similar
> > reasons as above.
> > 
> 
> Please see previous answer.
> 
> > Otherwise, when unwinding from a blocked task which has
> > 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
> > original return address.  Masami has been working on an interface to
> > make that possible for x86.  I assume something similar could be done
> > for arm64.
> > 
> 
> OK. Until that is available, this case needs to be addressed.

Actually, I've done that on arm64 :) See below patch.
(and I also have a similar code for arm32, what I'm considering is how
to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
similar.)

This is applicable on my x86 series v5

https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/

Thank you,


>From 947cf6cf1fd4154edd5533d18c2f8dfedc8d993d Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat at kernel.org>
Date: Sat, 20 Mar 2021 00:14:29 +0900
Subject: [PATCH] arm64: Recover kretprobe modified return address in
 stacktrace

Since the kretprobe replaces the function return address with
the kretprobe_trampoline on the stack, arm64 unwinder shows it
instead of the correct return address.

This finds the correct return address from the per-task
kretprobe_instances list and verify it is in between the
caller fp and callee fp.

Signed-off-by: Masami Hiramatsu <mhiramat at kernel.org>
---
 arch/arm64/include/asm/stacktrace.h |  2 ++
 arch/arm64/kernel/probes/kprobes.c  | 28 ++++++++++++++++++++++++++++
 arch/arm64/kernel/stacktrace.c      |  3 +++
 kernel/kprobes.c                    |  8 ++++----
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
index eb29b1fe8255..50ebc9e9dba9 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -9,6 +9,7 @@
 #include <linux/sched.h>
 #include <linux/sched/task_stack.h>
 #include <linux/types.h>
+#include <linux/llist.h>
 
 #include <asm/memory.h>
 #include <asm/ptrace.h>
@@ -59,6 +60,7 @@ struct stackframe {
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 	int graph;
 #endif
+	struct llist_node *kr_cur;
 };
 
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index fce681fdfce6..204e475cbff3 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -410,6 +410,34 @@ int __init arch_populate_kprobe_blacklist(void)
 	return ret;
 }
 
+unsigned long __kretprobe_find_ret_addr(struct task_struct *tsk,
+					struct llist_node **cur);
+
+unsigned long kretprobe_find_ret_addr(struct task_struct *tsk,
+				void *fp, struct llist_node **cur)
+{
+	struct kretprobe_instance *ri;
+	unsigned long ret;
+
+	do {
+		ret = __kretprobe_find_ret_addr(tsk, cur);
+		if (!ret)
+			return ret;
+		ri = container_of(*cur, struct kretprobe_instance, llist);
+		/*
+		 * Since arm64 stores the stack pointer of the entry of target
+		 * function (callee) to ri->fp, the given real @fp must be
+		 * smaller than ri->fp, but bigger than the previous ri->fp.
+		 *
+		 * callee sp (prev ri->fp)
+		 * fp (and *saved_lr)
+		 * caller sp (ri->fp)
+		 */
+	} while (ri->fp <= fp);
+
+	return ret;
+}
+
 void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
 {
 	return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs));
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..956486d4ac10 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -105,6 +105,8 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 		frame->pc = ret_stack->ret;
 	}
 #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+	if (is_kretprobe_trampoline(frame->pc))
+		frame->pc = kretprobe_find_ret_addr(tsk, (void *)fp, &frame->kr_cur);
 
 	frame->pc = ptrauth_strip_insn_pac(frame->pc);
 
@@ -199,6 +201,7 @@ void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
 {
 	struct stackframe frame;
 
+	memset(&frame, 0, sizeof(frame));
 	if (regs)
 		start_backtrace(&frame, regs->regs[29], regs->pc);
 	else if (task == current)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 4ce3e6f5d28d..12677a463561 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1859,8 +1859,8 @@ static struct notifier_block kprobe_exceptions_nb = {
 #ifdef CONFIG_KRETPROBES
 
 /* This assumes the tsk is current or the task which is not running. */
-static unsigned long __kretprobe_find_ret_addr(struct task_struct *tsk,
-					       struct llist_node **cur)
+unsigned long __kretprobe_find_ret_addr(struct task_struct *tsk,
+					struct llist_node **cur)
 {
 	struct kretprobe_instance *ri = NULL;
 	struct llist_node *node = *cur;
@@ -1882,8 +1882,8 @@ static unsigned long __kretprobe_find_ret_addr(struct task_struct *tsk,
 }
 NOKPROBE_SYMBOL(__kretprobe_find_ret_addr);
 
-unsigned long kretprobe_find_ret_addr(struct task_struct *tsk, void *fp,
-				      struct llist_node **cur)
+unsigned long __weak kretprobe_find_ret_addr(struct task_struct *tsk,
+				void *fp, struct llist_node **cur)
 {
 	struct kretprobe_instance *ri = NULL;
 	unsigned long ret;
-- 
2.25.1



-- 
Masami Hiramatsu <mhiramat at kernel.org>


From madvenka at linux.microsoft.com  Mon Apr  5 14:46:30 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 5 Apr 2021 08:46:30 -0500
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210405222436.4fda9a930676d95e862744af@kernel.org>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
 <20210405222436.4fda9a930676d95e862744af@kernel.org>
Message-ID: <7db94d60-3cb5-625a-a90b-d843e88f4533@linux.microsoft.com>



On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> Hi Madhaven,
> 
> On Sat, 3 Apr 2021 22:29:12 -0500
> "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:
> 
> 
>>>> Check for kretprobe
>>>> ===================
>>>>
>>>> For functions with a kretprobe set up, probe code executes on entry
>>>> to the function and replaces the return address in the stack frame with a
>>>> kretprobe trampoline. Whenever the function returns, control is
>>>> transferred to the trampoline. The trampoline eventually returns to the
>>>> original return address.
>>>>
>>>> A stack trace taken while executing in the function (or in functions that
>>>> get called from the function) will not show the original return address.
>>>> Similarly, a stack trace taken while executing in the trampoline itself
>>>> (and functions that get called from the trampoline) will not show the
>>>> original return address. This means that the caller of the probed function
>>>> will not show. This makes the stack trace unreliable.
>>>>
>>>> Add the kretprobe trampoline to special_functions[].
>>>>
>>>> FYI, each task contains a task->kretprobe_instances list that can
>>>> theoretically be consulted to find the orginal return address. But I am
>>>> not entirely sure how to safely traverse that list for stack traces
>>>> not on the current process. So, I have taken the easy way out.
>>>
>>> For kretprobes, unwinding from the trampoline or kretprobe handler
>>> shouldn't be a reliability concern for live patching, for similar
>>> reasons as above.
>>>
>>
>> Please see previous answer.
>>
>>> Otherwise, when unwinding from a blocked task which has
>>> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
>>> original return address.  Masami has been working on an interface to
>>> make that possible for x86.  I assume something similar could be done
>>> for arm64.
>>>
>>
>> OK. Until that is available, this case needs to be addressed.
> 
> Actually, I've done that on arm64 :) See below patch.
> (and I also have a similar code for arm32, what I'm considering is how
> to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
> similar.)
> 
> This is applicable on my x86 series v5
> 
> https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/
> 
> Thank you,
> 
> 

OK. I will take a look.

Thanks.

Madhavan


From michael.wei.hong.sit at intel.com  Mon Apr  5 15:23:20 2021
From: michael.wei.hong.sit at intel.com (Sit, Michael Wei Hong)
Date: Mon, 5 Apr 2021 14:23:20 +0000
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <YGsMbBW9h4H1y/T8@lunn.ch>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
Message-ID: <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>



> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Monday, 5 April, 2021 9:11 PM
> To: Sit, Michael Wei Hong <michael.wei.hong.sit at intel.com>
> Cc: peppe.cavallaro at st.com; alexandre.torgue at st.com;
> joabreu at synopsys.com; davem at davemloft.net;
> kuba at kernel.org; mcoquelin.stm32 at gmail.com;
> linux at armlinux.org.uk; Voon, Weifeng
> <weifeng.voon at intel.com>; Ong, Boon Leong
> <boon.leong.ong at intel.com>; qiangqing.zhang at nxp.com; Wong,
> Vee Khee <vee.khee.wong at intel.com>; fugang.duan at nxp.com;
> Chuah, Kim Tatt <kim.tatt.chuah at intel.com>;
> netdev at vger.kernel.org; linux-stm32 at st-md-
> mailman.stormreply.com; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; hkallweit1 at gmail.com
> Subject: Re: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for
> stmmac
> 
> On Mon, Apr 05, 2021 at 07:29:51PM +0800, Michael Sit Wei Hong
> wrote:
> > This patchset enables 2.5Gbps speed mode for stmmac.
> > Link speed mode is detected and configured at serdes power
> up sequence.
> > For 2.5G, we do not use SGMII in-band AN, we check the link
> speed mode
> > in the serdes and disable the in-band AN accordingly.
> >
> > Changes:
> > v1 -> v2
> >  patch 1/2
> >  -Remove MAC supported link speed masking
> >
> >  patch 2/2
> >  -Add supported link speed masking in the PCS
> 
> So there still some confusion here.
> 
> ------------            --------
> |MAC - PCS |---serdes---| PHY  |--- copper
> ------------            --------
> 
> 
> You have a MAC and an PCS in the stmmac IP block. That then has
> some
> sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> overclocked
> at 2.5G or 25000BaseX. Connected to the SERDES you have a PHY
> which
> converts to copper, giving you 2500BaseT.
> 
> You said earlier, that the PHY can only do 2500BaseT. So it should
> be
> the PHY driver which sets supported to 2500BaseT and no other
> speeds.
> 
> You should think about when somebody uses this MAC with a
> different
> PHY, one that can do the full range of 10/half through to 2.5G
> full. What generally happens is that the PHY performs auto-neg to
> determine the link speed. For 10M-1G speeds the PHY will
> configure its
> SERDES interface to SGMII and phylink will ask the PCS to also be
> configured to SGMII. If the PHY negotiates 2500BaseT, it will
> configure its side of the SERDES to 2500BaseX or SGMII
> overclocked at
> 2.5G. Again, phylink will ask the PCS to match what the PHY is
> doing.
> 
> So, where exactly is the limitation in your hardware? PCS or PHY?
The limitation in the hardware is at the PCS side where it is either running
in SGMII 2.5G or SGMII 1G speeds.
When running on SGMII 2.5G speeds, we disable the in-band AN and use 2.5G speed only
> 
>      Andrew


From andrew at lunn.ch  Mon Apr  5 15:35:09 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 5 Apr 2021 16:35:09 +0200
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
Message-ID: <YGsgHWItHcLFV9Kg@lunn.ch>

> > You have a MAC and an PCS in the stmmac IP block. That then has
> > some
> > sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> > overclocked
> > at 2.5G or 25000BaseX. Connected to the SERDES you have a PHY
> > which
> > converts to copper, giving you 2500BaseT.
> > 
> > You said earlier, that the PHY can only do 2500BaseT. So it should
> > be
> > the PHY driver which sets supported to 2500BaseT and no other
> > speeds.
> > 
> > You should think about when somebody uses this MAC with a
> > different
> > PHY, one that can do the full range of 10/half through to 2.5G
> > full. What generally happens is that the PHY performs auto-neg to
> > determine the link speed. For 10M-1G speeds the PHY will
> > configure its
> > SERDES interface to SGMII and phylink will ask the PCS to also be
> > configured to SGMII. If the PHY negotiates 2500BaseT, it will
> > configure its side of the SERDES to 2500BaseX or SGMII
> > overclocked at
> > 2.5G. Again, phylink will ask the PCS to match what the PHY is
> > doing.
> > 
> > So, where exactly is the limitation in your hardware? PCS or PHY?
> The limitation in the hardware is at the PCS side where it is either running
> in SGMII 2.5G or SGMII 1G speeds.
> When running on SGMII 2.5G speeds, we disable the in-band AN and use 2.5G speed only

So there is no actual limitation! The MAC should indicate it can do
10Half through to 2500BaseT. And you need to listen to PHYLINK and
swap the PCS between SGMII to overclocked SGMII when it requests.

PHYLINK will call stmmac_mac_config() and use state->interface to
decide how to configure the PCS to match what the PHY is doing.

     Andrew


From linux at roeck-us.net  Mon Apr  5 15:49:13 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 5 Apr 2021 07:49:13 -0700
Subject: [PATCH] watchdog: meson_wdt: Use device_get_match_data() helper
In-Reply-To: <1617243921-56774-1-git-send-email-tiantao6@hisilicon.com>
References: <1617243921-56774-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <61aa8bab-4282-3264-ccae-2b7284f4c9ec@roeck-us.net>

On 3/31/21 7:25 PM, Tian Tao wrote:
> Use the device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>  drivers/watchdog/meson_wdt.c | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/watchdog/meson_wdt.c b/drivers/watchdog/meson_wdt.c
> index 459f3ae..539feaa 100644
> --- a/drivers/watchdog/meson_wdt.c
> +++ b/drivers/watchdog/meson_wdt.c
> @@ -162,7 +162,6 @@ static int meson_wdt_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct meson_wdt_dev *meson_wdt;
> -	const struct of_device_id *of_id;
>  	int err;
>  
>  	meson_wdt = devm_kzalloc(dev, sizeof(*meson_wdt), GFP_KERNEL);
> @@ -173,12 +172,7 @@ static int meson_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(meson_wdt->wdt_base))
>  		return PTR_ERR(meson_wdt->wdt_base);
>  
> -	of_id = of_match_device(meson_wdt_dt_ids, dev);
> -	if (!of_id) {
> -		dev_err(dev, "Unable to initialize WDT data\n");
> -		return -ENODEV;
> -	}
> -	meson_wdt->data = of_id->data;
> +	meson_wdt->data = device_get_match_data(dev);
>  
>  	meson_wdt->wdt_dev.parent = dev;
>  	meson_wdt->wdt_dev.info = &meson_wdt_info;
> 



From madvenka at linux.microsoft.com  Mon Apr  5 15:56:48 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 5 Apr 2021 09:56:48 -0500
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210405222436.4fda9a930676d95e862744af@kernel.org>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
 <20210405222436.4fda9a930676d95e862744af@kernel.org>
Message-ID: <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>



On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> Hi Madhaven,
> 
> On Sat, 3 Apr 2021 22:29:12 -0500
> "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:
> 
> 
>>>> Check for kretprobe
>>>> ===================
>>>>
>>>> For functions with a kretprobe set up, probe code executes on entry
>>>> to the function and replaces the return address in the stack frame with a
>>>> kretprobe trampoline. Whenever the function returns, control is
>>>> transferred to the trampoline. The trampoline eventually returns to the
>>>> original return address.
>>>>
>>>> A stack trace taken while executing in the function (or in functions that
>>>> get called from the function) will not show the original return address.
>>>> Similarly, a stack trace taken while executing in the trampoline itself
>>>> (and functions that get called from the trampoline) will not show the
>>>> original return address. This means that the caller of the probed function
>>>> will not show. This makes the stack trace unreliable.
>>>>
>>>> Add the kretprobe trampoline to special_functions[].
>>>>
>>>> FYI, each task contains a task->kretprobe_instances list that can
>>>> theoretically be consulted to find the orginal return address. But I am
>>>> not entirely sure how to safely traverse that list for stack traces
>>>> not on the current process. So, I have taken the easy way out.
>>>
>>> For kretprobes, unwinding from the trampoline or kretprobe handler
>>> shouldn't be a reliability concern for live patching, for similar
>>> reasons as above.
>>>
>>
>> Please see previous answer.
>>
>>> Otherwise, when unwinding from a blocked task which has
>>> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
>>> original return address.  Masami has been working on an interface to
>>> make that possible for x86.  I assume something similar could be done
>>> for arm64.
>>>
>>
>> OK. Until that is available, this case needs to be addressed.
> 
> Actually, I've done that on arm64 :) See below patch.
> (and I also have a similar code for arm32, what I'm considering is how
> to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
> similar.)
> 
> This is applicable on my x86 series v5
> 
> https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/
> 
> Thank you,
> 
> 

I took a brief look at your changes. Looks reasonable.

However, for now, I am going to include the kretprobe_trampoline in the special_functions[]
array until your changes are merged. At that point, it is just a matter of deleting
kretprobe_trampoline from the special_functions[] array. That is all.

I hope that is fine with everyone.

Madhavan



From dinguyen at kernel.org  Mon Apr  5 16:50:26 2021
From: dinguyen at kernel.org (Dinh Nguyen)
Date: Mon,  5 Apr 2021 10:50:26 -0500
Subject: [GIT PULL] SoCFPGA firmware update for v5.13
Message-ID: <20210405155026.86309-1-dinguyen@kernel.org>

Hi Arnd, Kevin, and Olof:

Please pull in this patch for v5.13.

Thanks,
Dinh

The following changes since commit 4483397b03536506535d611b0cb28a81a69e8edf:

  ARM: socfpga: drop ARCH_SOCFPGA (2021-03-23 11:03:36 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_update_for_v5.13_part2

for you to fetch changes up to 38ad957b04c5c2c9effc6336365187dae1301051:

  firmware: stratix10-svc: build only on 64-bit ARM (2021-04-04 07:41:43 -0500)

----------------------------------------------------------------
SoCFPGA updates for v5.13, part 2
- Only build Stratix10 Service Layer and RSU drivers on ARM64

----------------------------------------------------------------
Krzysztof Kozlowski (1):
      firmware: stratix10-svc: build only on 64-bit ARM

 drivers/firmware/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From eugen.hristev at microchip.com  Mon Apr  5 16:50:35 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:35 +0300
Subject: [PATCH v2 00/30] media: atmel: atmel-isc: add support for xisc
Message-ID: <20210405155105.162529-1-eugen.hristev@microchip.com>

Hello,

This series adds support for a variant of the ISC named XISC.
This block is present in the product named sama7g5.

I started by moving code around, the code which was specialized for sama5d2
type of ISC, to have it inside the dedicated sama5d2 file.

I added several new pipeline elements to the code base, which would be common
to sama5d2 and the new sama7g5, but only used by the new style pipeline.

I separated the input and output formats on a per-product separate array.

I added the new sama7g5 compatible driver for the xisc, which is similar with
the sama5d2, but with differences in terms of DT, clocks and callbacks to
specific operations.

I added the binding for the xisc by copying and modifying the existing
isc one. I know that it has to be converted to yaml, and I will do that if
it looks good.

Feedback is appreciated.
Thanks,
Eugen

Changes in v2:
- Fixed krobot warnings with W=1 regarding functions with no prototype
- Fixed new sama7g5 driver to use the new subdev fwnode API in kernel 5.12. my driver was
based on old 5.10 style API.

Eugen Hristev (30):
  media: atmel: atmel-isc: specialize gamma table into product specific
  media: atmel: atmel-isc: specialize driver name constant
  media: atmel: atmel-isc: add checks for limiting frame sizes
  media: atmel: atmel-isc: specialize max width and max height
  media: atmel: atmel-isc: specialize dma cfg
  media: atmel: atmel-isc: extract CSC submodule config into separate
    function
  media: atmel: atmel-isc-base: add id to clock debug message
  media: atmel: atmel-isc: create register offsets struct
  media: atmel: atmel-isc: extract CBC submodule config into separate
    function
  media: atmel: atmel-isc: add CBC to the reg offsets struct
  media: atmel: atmel-isc: add SUB422 and SUB420 to register offsets
  media: atmel: atmel-isc: add RLP to register offsets
  media: atmel: atmel-isc: add HIS to register offsets
  media: atmel: atmel-isc: add DMA to register offsets
  media: atmel: atmel-isc: add support for version register
  media: atmel: atmel-isc: add his_entry to register offsets
  media: atmel: atmel-isc: add register description for additional
    modules
  media: atmel: atmel-isc: extend pipeline with extra modules
  media: atmel: atmel-isc: add CC initialization function
  media: atmel: atmel-isc: create product specific v4l2 controls config
  media: atmel: atmel-isc: create callback for DPC submodule product
    specific
  media: atmel: atmel-isc: create callback for GAM submodule product
    specific
  media: atmel: atmel-isc: create callback for RLP submodule product
    specific
  media: atmel: atmel-isc: move the formats list into product specific
    code
  media: atmel: atmel-isc: create an adapt pipeline callback for product
    specific
  media: atmel: atmel-isc-regs: add additional fields for sama7g5 type
    pipeline
  media: atmel: atmel-isc-base: add support for more formats and
    additional pipeline modules
  dt-bindings: media: atmel: add microchip-xisc binding
  media: atmel: atmel-isc-sama5d2: remove duplicate define
  media: atmel: atmel-isc: add microchip-xisc driver

 .../bindings/media/microchip-xisc.txt         |  64 ++
 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c | 381 ++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h | 133 +++-
 drivers/media/platform/atmel/atmel-isc.h      | 122 +++-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 311 ++++++++-
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
 9 files changed, 1391 insertions(+), 277 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:36 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:36 +0300
Subject: [PATCH v2 01/30] media: atmel: atmel-isc: specialize gamma table into
 product specific
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-2-eugen.hristev@microchip.com>

Separate the gamma table from the isc base file into the specific sama5d2
product file.
Add a pointer to the gamma table and entries count inside the platform
driver specific struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 47 ++-----------------
 drivers/media/platform/atmel/atmel-isc.h      | 11 +++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 45 ++++++++++++++++++
 3 files changed, 56 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..8b6c5e339cb8 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -176,48 +176,6 @@ struct isc_format formats_list[] = {
 
 };
 
-/* Gamma table with gamma 1/2.2 */
-const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES] = {
-	/* 0 --> gamma 1/1.8 */
-	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
-	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
-	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
-	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
-	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
-	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
-	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
-	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
-	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
-	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
-	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
-
-	/* 1 --> gamma 1/2 */
-	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
-	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
-	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
-	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
-	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
-	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
-	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
-	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
-	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
-	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
-	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
-
-	/* 2 --> gamma 1/2.2 */
-	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
-	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
-	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
-	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
-	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
-	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
-	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
-	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
-	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
-	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
-	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -683,7 +641,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	regmap_write(regmap, ISC_CFA_CFG, bay_cfg | ISC_CFA_CFG_EITPOL);
 
-	gamma = &isc_gamma_table[ctrls->gamma_index][0];
+	gamma = &isc->gamma_table[ctrls->gamma_index][0];
 	regmap_bulk_write(regmap, ISC_GAM_BENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
@@ -2070,7 +2028,8 @@ static int isc_ctrl_init(struct isc_device *isc)
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX, 1, 2);
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
+			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
 					  V4L2_CID_AUTO_WHITE_BALANCE,
 					  0, 1, 1, 1);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fab8eca58d93..f1df47a4655b 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -187,6 +187,10 @@ struct isc_ctrls {
  *
  * @current_subdev:	current subdevice: the sensor
  * @subdev_entities:	list of subdevice entitites
+ *
+ * @gamma_table:	pointer to the table with gamma values, has
+ *			gamma_max sets of GAMMA_ENTRIES entries each
+ * @gamma_max:		maximum number of sets of inside the gamma_table
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -245,16 +249,17 @@ struct isc_device {
 		struct v4l2_ctrl	*gr_off_ctrl;
 		struct v4l2_ctrl	*gb_off_ctrl;
 	};
-};
 
-#define GAMMA_MAX	2
 #define GAMMA_ENTRIES	64
+	/* pointer to the defined gamma table */
+	const u32	(*gamma_table)[GAMMA_ENTRIES];
+	u32		gamma_max;
+};
 
 #define ATMEL_ISC_NAME "atmel-isc"
 
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
-extern const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0b78fecfd2a8..c74f36245bd5 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,48 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
+	/* 0 --> gamma 1/1.8 */
+	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
+	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
+	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
+	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
+	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
+	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
+	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
+	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
+	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
+	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
+	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
+
+	/* 1 --> gamma 1/2 */
+	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
+	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
+	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
+	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
+	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
+	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
+	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
+	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
+	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
+	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
+	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
+
+	/* 2 --> gamma 1/2.2 */
+	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
+	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
+	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
+	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
+	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
+	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
+	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
+	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
+	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
+	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
+	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
+};
+
 static int isc_parse_dt(struct device *dev, struct isc_device *isc)
 {
 	struct device_node *np = dev->of_node;
@@ -150,6 +192,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	isc->gamma_table = isc_sama5d2_gamma_table;
+	isc->gamma_max = 2;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:37 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:37 +0300
Subject: [PATCH v2 02/30] media: atmel: atmel-isc: specialize driver name
 constant
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-3-eugen.hristev@microchip.com>

The driver name constant must defined based on product driver, thus moving
the constant directly where it's required. This will allow each ISC based
product to define it's own name.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc.h         | 2 --
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8b6c5e339cb8..277a8fd8b83d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -896,7 +896,7 @@ static int isc_querycap(struct file *file, void *priv,
 {
 	struct isc_device *isc = video_drvdata(file);
 
-	strscpy(cap->driver, ATMEL_ISC_NAME, sizeof(cap->driver));
+	strscpy(cap->driver, "microchip-isc", sizeof(cap->driver));
 	strscpy(cap->card, "Atmel Image Sensor Controller", sizeof(cap->card));
 	snprintf(cap->bus_info, sizeof(cap->bus_info),
 		 "platform:%s", isc->v4l2_dev.name);
@@ -2246,7 +2246,7 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
 	}
 
 	/* Register video device */
-	strscpy(vdev->name, ATMEL_ISC_NAME, sizeof(vdev->name));
+	strscpy(vdev->name, "microchip-isc", sizeof(vdev->name));
 	vdev->release		= video_device_release_empty;
 	vdev->fops		= &isc_fops;
 	vdev->ioctl_ops		= &isc_ioctl_ops;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f1df47a4655b..8d81d9967ad2 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -256,8 +256,6 @@ struct isc_device {
 	u32		gamma_max;
 };
 
-#define ATMEL_ISC_NAME "atmel-isc"
-
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c74f36245bd5..f45d8b96bfb8 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -185,7 +185,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return irq;
 
 	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
-			       ATMEL_ISC_NAME, isc);
+			       "atmel-sama5d2-isc", isc);
 	if (ret < 0) {
 		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
 			irq, ret);
@@ -364,7 +364,7 @@ static struct platform_driver atmel_isc_driver = {
 	.probe	= atmel_isc_probe,
 	.remove	= atmel_isc_remove,
 	.driver	= {
-		.name		= ATMEL_ISC_NAME,
+		.name		= "atmel-sama5d2-isc",
 		.pm		= &atmel_isc_dev_pm_ops,
 		.of_match_table = of_match_ptr(atmel_isc_of_match),
 	},
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:38 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:38 +0300
Subject: [PATCH v2 03/30] media: atmel: atmel-isc: add checks for limiting
 frame sizes
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-4-eugen.hristev@microchip.com>

When calling the subdev, certain subdev drivers will overwrite the
frame size and adding sizes which are beyond the ISC's capabilities.
Thus we need to ensure the frame size is cropped to the maximum caps.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 277a8fd8b83d..45fc8dbb7943 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1326,6 +1326,12 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
 	pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height;
@@ -1361,6 +1367,12 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 	if (ret < 0)
 		return ret;
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	isc->fmt = *f;
 
 	if (isc->try_config.sd_format && isc->config.sd_format &&
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:39 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:39 +0300
Subject: [PATCH v2 04/30] media: atmel: atmel-isc: specialize max width and
 max height
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-5-eugen.hristev@microchip.com>

Move the max width and max height constants to the product specific driver
and have them in the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
 drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 45fc8dbb7943..350076dd029a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
 	 * just use the maximum ISC can receive.
 	 */
 	if (ret) {
-		pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
-		pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
+		pad_cfg->try_crop.width = isc->max_width;
+		pad_cfg->try_crop.height = isc->max_height;
 	} else {
 		pad_cfg->try_crop.width = fse.max_width;
 		pad_cfg->try_crop.height = fse.max_height;
@@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	isc->try_config.sd_format = sd_fmt;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	/*
 	 * The mbus format is the one the subdev outputs.
@@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
@@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 		return ret;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (f->fmt.pix.width > isc->max_width)
+		f->fmt.pix.width = isc->max_width;
+	if (f->fmt.pix.height > isc->max_height)
+		f->fmt.pix.height = isc->max_height;
 
 	isc->fmt = *f;
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 8d81d9967ad2..6becc6c3aaf0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -10,9 +10,6 @@
  */
 #ifndef _ATMEL_ISC_H_
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
-
 #define ISC_CLK_MAX_DIV		255
 
 enum isc_clk_id {
@@ -191,6 +188,9 @@ struct isc_ctrls {
  * @gamma_table:	pointer to the table with gamma values, has
  *			gamma_max sets of GAMMA_ENTRIES entries each
  * @gamma_max:		maximum number of sets of inside the gamma_table
+ *
+ * @max_width:		maximum frame width, dependent on the internal RAM
+ * @max_height:		maximum frame height, dependent on the internal RAM
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -254,6 +254,9 @@ struct isc_device {
 	/* pointer to the defined gamma table */
 	const u32	(*gamma_table)[GAMMA_ENTRIES];
 	u32		gamma_max;
+
+	u32		max_width;
+	u32		max_height;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f45d8b96bfb8..f8d1c8ba99b3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -49,8 +49,8 @@
 #include "atmel-isc-regs.h"
 #include "atmel-isc.h"
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
+#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
+#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
 #define ISC_CLK_MAX_DIV		255
 
@@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->gamma_table = isc_sama5d2_gamma_table;
 	isc->gamma_max = 2;
 
+	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:40 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:40 +0300
Subject: [PATCH v2 05/30] media: atmel: atmel-isc: specialize dma cfg
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-6-eugen.hristev@microchip.com>

The dma configuration (DCFG) is specific to the product.
Move this configuration in the product specific driver, and add the
field inside the driver struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 +--
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 350076dd029a..ff40ee2e2759 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -716,8 +716,7 @@ static int isc_configure(struct isc_device *isc)
 	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
-	dcfg = isc->config.dcfg_imode |
-		       ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+	dcfg = isc->config.dcfg_imode | isc->dcfg;
 
 	pfe_cfg0  |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 6becc6c3aaf0..d14ae096fbf6 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,6 +150,7 @@ struct isc_ctrls {
  * @hclock:		Hclock clock input (refer datasheet)
  * @ispck:		iscpck clock (refer datasheet)
  * @isc_clks:		ISC clocks
+ * @dcfg:		DMA master configuration, architecture dependent
  *
  * @dev:		Registered device driver
  * @v4l2_dev:		v4l2 registered device
@@ -197,6 +198,7 @@ struct isc_device {
 	struct clk		*hclock;
 	struct clk		*ispck;
 	struct isc_clk		isc_clks[2];
+	u32			dcfg;
 
 	struct device		*dev;
 	struct v4l2_device	v4l2_dev;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f8d1c8ba99b3..6d9942dcd7c1 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -198,6 +198,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	/* sama5d2-isc - 8 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:41 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:41 +0300
Subject: [PATCH v2 06/30] media: atmel: atmel-isc: extract CSC submodule
 config into separate function
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-7-eugen.hristev@microchip.com>

The CSC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c   |  8 +-------
 drivers/media/platform/atmel/atmel-isc.h        |  7 +++++++
 .../media/platform/atmel/atmel-sama5d2-isc.c    | 17 +++++++++++++++++
 3 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index ff40ee2e2759..31f63ba90c71 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -646,13 +646,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
-	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	isc->config_csc(isc);
 
 	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
 	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d14ae096fbf6..bb0b4419deff 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -192,6 +192,9 @@ struct isc_ctrls {
  *
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
+ *
+ * @config_csc:		pointer to a function that initializes product
+ *			specific CSC module
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -259,6 +262,10 @@ struct isc_device {
 
 	u32		max_width;
 	u32		max_height;
+
+	struct {
+		void (*config_csc)(struct isc_device *isc);
+	};
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 6d9942dcd7c1..f041bd75090e 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,21 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+void isc_sama5d2_config_csc(struct isc_device *isc);
+
+void isc_sama5d2_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -198,6 +213,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_csc = isc_sama5d2_config_csc;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From nm at ti.com  Mon Apr  5 16:53:36 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 5 Apr 2021 10:53:36 -0500
Subject: [GIT PULL] arm64: dts: TI K3 updates for v5.13
Message-ID: <20210405155336.smohb7uzkperqwuz@reflex>

Hi,

Please pull the following device tree changes for v5.13 cycle.

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git tags/ti-k3-dt-for-v5.13

for you to fetch changes up to 112e5934ff3a7505e583365213a27f990922b76b:

  arm64: dts: ti: k3-am64-main: Fix ospi compatible (2021-04-01 08:50:33 -0500)

----------------------------------------------------------------
Devicetree changes for TI K3 platforms for v5.13 merge window:

* New SoCs:
  - AM642 mean for industrial control, motor control, remote IO, IoT gateway etc.
* New Boards:
  - AM65: Siemens SIMATIC IOT2050 advanced and basic boards
  - AM64: EVM and SK boards
* New peripherals:
  - AM65: watchdog
  - AM65,J721E: ICSSG
  - J7200: OSPI, GPIO
* Fixes:
  - AM65: pcie node fixup, ospi speed updates
  - J721e, J7200: MMC speed updates, ospi speed updates and compatibles fixups.

----------------------------------------------------------------
Aswath Govindraju (7):
      arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
      arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM
      arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
      arm64: dts: ti: k3-am642-evm: Add USB support
      arm64: dts: ti: k3-am64: Add GPIO DT nodes
      arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware usage
      arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems

Dave Gerlach (4):
      dt-bindings: arm: ti: Add bindings for AM642 SoC
      dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64
      arm64: dts: ti: Add support for AM642 SoC
      arm64: dts: ti: Add support for AM642 EVM

Faiz Abbas (2):
      arm64: dts: ti: k3-j7200: Add gpio nodes
      arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules

Grygorii Strashko (1):
      arm64: dts: ti: k3-am64-main: add main CPTS entry

Jan Kiszka (5):
      arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes
      arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
      dt-bindings: Add Siemens vendor prefix
      dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
      arm64: dts: ti: Add support for Siemens IOT2050 boards

Lokesh Vutla (2):
      dt-bindings: arm: ti: Add bindings for AM642 SK
      arm64: dts: ti: Add support for AM642 SK

Peter Ujfalusi (1):
      arm64: dts: ti: k3-am64-main: Enable DMA support

Pratyush Yadav (6):
      arm64: dts: ti: k3-j721e-som-p0: Enable 8D-8D-8D mode on OSPI
      arm64: dts: ti: am654-base-board: Enable 8D-8D-8D mode on OSPI
      arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
      arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
      arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
      arm64: dts: ti: k3-am64-main: Fix ospi compatible

Suman Anna (5):
      arm64: dts: ti: k3-am65-main: Add ICSSG nodes
      arm64: dts: ti: k3-j721e-main: Add ICSSG nodes
      arm64: dts: ti: k3-am64-main: Add hwspinlock node
      arm64: dts: ti: k3-am64-main: Add mailbox cluster nodes
      arm64: dts: ti: k3-am642-evm/sk: Add IPC sub-mailbox nodes

Vignesh Raghavendra (6):
      arm64: dts: ti: k3-am64-main: Add CPSW DT node
      arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes
      arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes
      arm64: dts: ti: k3-am64-main: Add ADC nodes
      arm64: dts: ti: k3-am64-main: Add OSPI node
      arm64: dts: ti: k3-am64-evm/sk: Add OSPI flash DT node

 Documentation/devicetree/bindings/arm/ti/k3.yaml   |   9 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm64/boot/dts/ti/Makefile                    |   8 +-
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi           | 675 +++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi            | 103 ++++
 arch/arm64/boot/dts/ti/k3-am64.dtsi                | 105 ++++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts            | 468 ++++++++++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts             | 334 ++++++++++
 arch/arm64/boot/dts/ti/k3-am642.dtsi               |  65 ++
 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi | 655 ++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi           | 395 ++++++++++++
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi            |   9 +
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts |  61 ++
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts     |   4 +-
 .../boot/dts/ti/k3-am6548-iot2050-advanced.dts     |  60 ++
 .../boot/dts/ti/k3-j7200-common-proc-board.dts     |  94 +++
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi          |  86 ++-
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi    |  51 ++
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi        |  36 ++
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi          | 279 ++++++++-
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi    |   4 +-
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi        |   4 +-
 include/dt-bindings/pinctrl/k3.h                   |   5 +-
 23 files changed, 3501 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-sk.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
-- 
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/20210405/5578c25c/attachment.sig>

From eugen.hristev at microchip.com  Mon Apr  5 16:50:42 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:42 +0300
Subject: [PATCH v2 07/30] media: atmel: atmel-isc-base: add id to clock debug
 message
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-8-eugen.hristev@microchip.com>

Add the clock id to the debug message regarding clock setup

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 31f63ba90c71..bc036e8ac4fe 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -277,8 +277,8 @@ static int isc_clk_enable(struct clk_hw *hw)
 	unsigned long flags;
 	unsigned int status;
 
-	dev_dbg(isc_clk->dev, "ISC CLK: %s, div = %d, parent id = %d\n",
-		__func__, isc_clk->div, isc_clk->parent_id);
+	dev_dbg(isc_clk->dev, "ISC CLK: %s, id = %d, div = %d, parent id = %d\n",
+		__func__, id, isc_clk->div, isc_clk->parent_id);
 
 	spin_lock_irqsave(&isc_clk->lock, flags);
 	regmap_update_bits(regmap, ISC_CLKCFG,
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:43 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:43 +0300
Subject: [PATCH v2 08/30] media: atmel: atmel-isc: create register offsets
 struct
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-9-eugen.hristev@microchip.com>

Create a struct that holds register offsets that are product specific.
Add initially the CSC register.
This allows each product that contains a variant of the ISC to add their
own register offset.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c |  2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      | 12 +++++++++++
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 20 +++++++++++++------
 4 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bc036e8ac4fe..019d931d1367 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,7 +2311,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
-		REG_FIELD(ISC_CSC_CTRL, 0, 0),
+		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index f1e160ed4351..5a65600c5f88 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -153,6 +153,9 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* Offset for CSC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CSC_OFFSET	0
+
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index bb0b4419deff..ef3a0451192d 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -144,6 +144,14 @@ struct isc_ctrls {
 
 #define ISC_PIPE_LINE_NODE_NUM	11
 
+/*
+ * struct isc_reg_offsets - ISC device register offsets
+ * @csc:		Offset for the CSC register
+ */
+struct isc_reg_offsets {
+	u32 csc;
+};
+
 /*
  * struct isc_device - ISC device driver data/config struct
  * @regmap:		Register map
@@ -195,6 +203,8 @@ struct isc_ctrls {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ *
+ * @offsets:		struct holding the product specific register offsets
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -266,6 +276,8 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 	};
+
+	struct isc_reg_offsets		offsets;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f041bd75090e..9e557d17e731 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -61,12 +61,18 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 	struct regmap *regmap = isc->regmap;
 
 	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -215,6 +221,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 
+	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:44 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:44 +0300
Subject: [PATCH v2 09/30] media: atmel: atmel-isc: extract CBC submodule
 config into separate function
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-10-eugen.hristev@microchip.com>

The CBC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  4 +---
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 10 ++++++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 019d931d1367..446fe232956b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -647,9 +647,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
 	isc->config_csc(isc);
-
-	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
+	isc->config_cbc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index ef3a0451192d..cb47932197b1 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -203,6 +203,8 @@ struct isc_reg_offsets {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ * @config_cbc:		pointer to a function that initializes product
+ *			specific CBC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -275,6 +277,7 @@ struct isc_device {
 
 	struct {
 		void (*config_csc)(struct isc_device *isc);
+		void (*config_cbc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 9e557d17e731..66b92fa1c752 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -55,6 +55,7 @@
 #define ISC_CLK_MAX_DIV		255
 
 void isc_sama5d2_config_csc(struct isc_device *isc);
+void isc_sama5d2_config_cbc(struct isc_device *isc);
 
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
@@ -75,6 +76,14 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 		     0xFEE | (0x80 << 16));
 }
 
+void isc_sama5d2_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -220,6 +229,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
 	isc->config_csc = isc_sama5d2_config_csc;
+	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:45 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:45 +0300
Subject: [PATCH v2 10/30] media: atmel: atmel-isc: add CBC to the reg offsets
 struct
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-11-eugen.hristev@microchip.com>

Add cbc to the reg offsets struct. This will allow different products
to have a different reg offset for this particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 3 +++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++--
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 446fe232956b..d4bf7fd5929f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2310,7 +2310,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
-		REG_FIELD(ISC_CBC_CTRL, 0, 0),
+		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
 	};
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5a65600c5f88..a5e2fe01ba9f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -177,6 +177,9 @@
 /* Color Space Conversion CRB OCR Register */
 #define ISC_CSC_CRB_OCR	0x000003b0
 
+/* Offset for CBC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CBC_OFFSET	0
+
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index cb47932197b1..b1fe93c93c61 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -147,9 +147,11 @@ struct isc_ctrls {
 /*
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
+ * @cbc:		Offset for the CBC register
  */
 struct isc_reg_offsets {
 	u32 csc;
+	u32 cbc;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 66b92fa1c752..c3037244e01e 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -80,8 +80,10 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
 
-	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc,
+		     isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc,
+		     isc->ctrls.contrast);
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -232,6 +234,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:46 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:46 +0300
Subject: [PATCH v2 11/30] media: atmel: atmel-isc: add SUB422 and SUB420 to
 register offsets
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-12-eugen.hristev@microchip.com>

Add sub420 and sub422 to the reg offsets struct.
This will allow different products to have a different reg offset for these
particular modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 4 ++++
 drivers/media/platform/atmel/atmel-isc.h         | 4 ++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 ++
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index d4bf7fd5929f..b2067d75499b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,8 +2311,8 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
-		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
-		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
+		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
+		REG_FIELD(ISC_SUB420_CTRL + isc->offsets.sub420, 0, 0),
 	};
 
 	for (i = 0; i < ISC_PIPE_LINE_NODE_NUM; i++) {
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a5e2fe01ba9f..04839def6ef6 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -194,9 +194,13 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Offset for SUB422 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB422_OFFSET	0
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
+/* Offset for SUB420 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB420_OFFSET	0
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b1fe93c93c61..fb7257872e7c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -148,10 +148,14 @@ struct isc_ctrls {
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
  * @cbc:		Offset for the CBC register
+ * @sub422:		Offset for the SUB422 register
+ * @sub420:		Offset for the SUB420 register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
+	u32 sub422;
+	u32 sub420;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c3037244e01e..943793fbc791 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -235,6 +235,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:47 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:47 +0300
Subject: [PATCH v2 12/30] media: atmel: atmel-isc: add RLP to register offsets
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-13-eugen.hristev@microchip.com>

Add rlp to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index b2067d75499b..317172959370 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -718,8 +718,8 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG, ISC_RLP_CFG_MODE_MASK,
-			   rlp_mode);
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
 	regmap_write(regmap, ISC_DCFG, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 04839def6ef6..2205484e04fc 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -204,6 +204,8 @@
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
+/* Offset for RLP register specific to sama5d2 product */
+#define ISC_SAMA5D2_RLP_OFFSET	0
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fb7257872e7c..b7d4e7fab570 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,12 +150,14 @@ struct isc_ctrls {
  * @cbc:		Offset for the CBC register
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
+ * @rlp:		Offset for the RLP register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
 	u32 sub422;
 	u32 sub420;
+	u32 rlp;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 943793fbc791..dd3f8e50a8d4 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -237,6 +237,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:48 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:48 +0300
Subject: [PATCH v2 13/30] media: atmel: atmel-isc: add HIS to register offsets
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-14-eugen.hristev@microchip.com>

Add his to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 11 +++++++----
 drivers/media/platform/atmel/atmel-isc-regs.h    |  2 ++
 drivers/media/platform/atmel/atmel-isc.h         |  2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c |  1 +
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 317172959370..aa7a9a7ca0e6 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -678,12 +678,13 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 	struct isc_ctrls *ctrls = &isc->ctrls;
 
 	if (enable) {
-		regmap_write(regmap, ISC_HIS_CFG,
+		regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
 			     ISC_HIS_CFG_MODE_GR |
 			     (isc->config.sd_format->cfa_baycfg
 					<< ISC_HIS_CFG_BAYSEL_SHIFT) |
 					ISC_HIS_CFG_RAR);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_EN);
 		regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
 		ctrls->hist_id = ISC_HIS_CFG_MODE_GR;
 		isc_update_profile(isc);
@@ -692,7 +693,8 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 		ctrls->hist_stat = HIST_ENABLED;
 	} else {
 		regmap_write(regmap, ISC_INTDIS, ISC_INT_HISDONE);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_DIS);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_DIS);
 
 		ctrls->hist_stat = HIST_DISABLED;
 	}
@@ -1821,7 +1823,8 @@ static void isc_awb_work(struct work_struct *w)
 			ctrls->awb = ISC_WB_NONE;
 		}
 	}
-	regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
+	regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
+		     hist_id | baysel | ISC_HIS_CFG_RAR);
 	isc_update_profile(isc);
 	/* if awb has been disabled, we don't need to start another histogram */
 	if (ctrls->awb)
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 2205484e04fc..0ab280ab59ec 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -224,6 +224,8 @@
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+/* Offset for HIS register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b7d4e7fab570..652285dc9f52 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -151,6 +151,7 @@ struct isc_ctrls {
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
+ * @his:		Offset for the HIS related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -158,6 +159,7 @@ struct isc_reg_offsets {
 	u32 sub422;
 	u32 sub420;
 	u32 rlp;
+	u32 his;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index dd3f8e50a8d4..914de4ed63f3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -238,6 +238,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:49 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:49 +0300
Subject: [PATCH v2 14/30] media: atmel: atmel-isc: add DMA to register offsets
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-15-eugen.hristev@microchip.com>

Add dma to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 19 ++++++++++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      |  2 ++
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  1 +
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index aa7a9a7ca0e6..11121943d2cb 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -593,16 +593,20 @@ static void isc_start_dma(struct isc_device *isc)
 			   ISC_PFE_CFG0_COLEN | ISC_PFE_CFG0_ROWEN);
 
 	addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
-	regmap_write(regmap, ISC_DAD0, addr0);
+	regmap_write(regmap, ISC_DAD0 + isc->offsets.dma, addr0);
 
 	switch (isc->config.fourcc) {
 	case V4L2_PIX_FMT_YUV420:
-		regmap_write(regmap, ISC_DAD1, addr0 + (sizeimage * 2) / 3);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 5) / 6);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + (sizeimage * 2) / 3);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 5) / 6);
 		break;
 	case V4L2_PIX_FMT_YUV422P:
-		regmap_write(regmap, ISC_DAD1, addr0 + sizeimage / 2);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 3) / 4);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + sizeimage / 2);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 3) / 4);
 		break;
 	default:
 		break;
@@ -610,7 +614,8 @@ static void isc_start_dma(struct isc_device *isc)
 
 	dctrl_dview = isc->config.dctrl_dview;
 
-	regmap_write(regmap, ISC_DCTRL, dctrl_dview | ISC_DCTRL_IE_IS);
+	regmap_write(regmap, ISC_DCTRL + isc->offsets.dma,
+		     dctrl_dview | ISC_DCTRL_IE_IS);
 	spin_lock(&isc->awb_lock);
 	regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_CAPTURE);
 	spin_unlock(&isc->awb_lock);
@@ -723,7 +728,7 @@ static int isc_configure(struct isc_device *isc)
 	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
-	regmap_write(regmap, ISC_DCFG, dcfg);
+	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
 	/* Set the pipeline */
 	isc_set_pipeline(isc, pipeline);
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 0ab280ab59ec..4940998c82a2 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -247,6 +247,9 @@
 
 #define ISC_HIS_CFG_RAR			BIT(8)
 
+/* Offset for DMA register specific to sama5d2 product */
+#define ISC_SAMA5D2_DMA_OFFSET	0
+
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
 #define ISC_DCFG_IMODE_PACKED8          0x0
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 652285dc9f52..52a9199d65ee 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -152,6 +152,7 @@ struct isc_ctrls {
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
+ * @dma:		Offset for the DMA related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -160,6 +161,7 @@ struct isc_reg_offsets {
 	u32 sub420;
 	u32 rlp;
 	u32 his;
+	u32 dma;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 914de4ed63f3..12f56a71db40 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -239,6 +239,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:50 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:50 +0300
Subject: [PATCH v2 15/30] media: atmel: atmel-isc: add support for version
 register
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-16-eugen.hristev@microchip.com>

Add support for version register and print it at probe time.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h    | 5 +++++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 5 +++++
 3 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 4940998c82a2..344668dcfcf4 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -295,6 +295,11 @@
 /* DMA Address 2 Register */
 #define ISC_DAD2        0x000003fc
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_VERSION_OFFSET	0
+/* Version Register */
+#define ISC_VERSION	0x0000040c
+
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 52a9199d65ee..676a5be1ee8c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -153,6 +153,7 @@ struct isc_ctrls {
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
+ * @version:		Offset for the version register
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -162,6 +163,7 @@ struct isc_reg_offsets {
 	u32 rlp;
 	u32 his;
 	u32 dma;
+	u32 version;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 12f56a71db40..10b70d4b04c4 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -192,6 +192,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	struct isc_subdev_entity *subdev_entity;
 	int irq;
 	int ret;
+	u32 ver;
 
 	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
 	if (!isc)
@@ -240,6 +241,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
@@ -335,6 +337,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_request_idle(dev);
 
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip ISC version %x\n", ver);
+
 	return 0;
 
 cleanup_subdev:
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:51 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:51 +0300
Subject: [PATCH v2 16/30] media: atmel: atmel-isc: add his_entry to register
 offsets
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-17-eugen.hristev@microchip.com>

Add his_entry to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 ++-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 11121943d2cb..2a619eef6aa3 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1672,7 +1672,8 @@ static void isc_hist_count(struct isc_device *isc, u32 *min, u32 *max)
 	*min = 0;
 	*max = HIST_ENTRIES;
 
-	regmap_bulk_read(regmap, ISC_HIS_ENTRY, hist_entry, HIST_ENTRIES);
+	regmap_bulk_read(regmap, ISC_HIS_ENTRY + isc->offsets.his_entry,
+			 hist_entry, HIST_ENTRIES);
 
 	*hist_count = 0;
 	/*
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 344668dcfcf4..a15c13e1a833 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -300,6 +300,8 @@
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 676a5be1ee8c..c5d956fd20a0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -154,6 +154,7 @@ struct isc_ctrls {
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
  * @version:		Offset for the version register
+ * @his_entry:		Offset for the HIS entries registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -164,6 +165,7 @@ struct isc_reg_offsets {
 	u32 his;
 	u32 dma;
 	u32 version;
+	u32 his_entry;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 10b70d4b04c4..0ff13198d732 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -242,6 +242,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:52 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:52 +0300
Subject: [PATCH v2 17/30] media: atmel: atmel-isc: add register description
 for additional modules
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-18-eugen.hristev@microchip.com>

Add register description for additional pipeline modules: the
Defective Pixel Correction (DPC) and the Vertical and Horizontal Scaler(VHXS)

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 67 +++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a15c13e1a833..457eed74cda9 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -90,6 +90,46 @@
 #define ISC_INT_DDONE		BIT(8)
 #define ISC_INT_HISDONE		BIT(12)
 
+/* ISC DPC Control Register */
+#define ISC_DPC_CTRL	0x40
+
+#define ISC_DPC_CTRL_DPCEN	BIT(0)
+#define ISC_DPC_CTRL_GDCEN	BIT(1)
+#define ISC_DPC_CTRL_BLCEN	BIT(2)
+
+/* ISC DPC Config Register */
+#define ISC_DPC_CFG	0x44
+
+#define ISC_DPC_CFG_BAYSEL_SHIFT	0
+
+#define ISC_DPC_CFG_EITPOL		BIT(4)
+
+#define ISC_DPC_CFG_TA_ENABLE		BIT(14)
+#define ISC_DPC_CFG_TC_ENABLE		BIT(13)
+#define ISC_DPC_CFG_TM_ENABLE		BIT(12)
+
+#define ISC_DPC_CFG_RE_MODE		BIT(17)
+
+#define ISC_DPC_CFG_GDCCLP_SHIFT	20
+#define ISC_DPC_CFG_GDCCLP_MASK		GENMASK(22, 20)
+
+#define ISC_DPC_CFG_BLOFF_SHIFT		24
+#define ISC_DPC_CFG_BLOFF_MASK		GENMASK(31, 24)
+
+#define ISC_DPC_CFG_BAYCFG_SHIFT	0
+#define ISC_DPC_CFG_BAYCFG_MASK		GENMASK(1, 0)
+/* ISC DPC Threshold Median Register */
+#define ISC_DPC_THRESHM	0x48
+
+/* ISC DPC Threshold Closest Register */
+#define ISC_DPC_THRESHC	0x4C
+
+/* ISC DPC Threshold Average Register */
+#define ISC_DPC_THRESHA	0x50
+
+/* ISC DPC STatus Register */
+#define ISC_DPC_SR	0x54
+
 /* ISC White Balance Control Register */
 #define ISC_WB_CTRL     0x00000058
 
@@ -153,6 +193,33 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* ISC VHXS Control Register */
+#define ISC_VHXS_CTRL	0x398
+
+/* ISC VHXS Source Size Register */
+#define ISC_VHXS_SS	0x39C
+
+/* ISC VHXS Destination Size Register */
+#define ISC_VHXS_DS	0x3A0
+
+/* ISC Vertical Factor Register */
+#define ISC_VXS_FACT	0x3a4
+
+/* ISC Horizontal Factor Register */
+#define ISC_HXS_FACT	0x3a8
+
+/* ISC Vertical Config Register */
+#define ISC_VXS_CFG	0x3ac
+
+/* ISC Horizontal Config Register */
+#define ISC_HXS_CFG	0x3b0
+
+/* ISC Vertical Tap Register */
+#define ISC_VXS_TAP	0x3b4
+
+/* ISC Horizontal Tap Register */
+#define ISC_HXS_TAP	0x434
+
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
 
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:53 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:53 +0300
Subject: [PATCH v2 18/30] media: atmel: atmel-isc: extend pipeline with extra
 modules
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-19-eugen.hristev@microchip.com>

Newer ISC pipelines have the additional modules of
Defective Pixel Correction -> DPC itself,
Defective Pixel Correction -> Green Disparity Correction (DPC_GDC)
Defective Pixel Correction -> Black Level Correction (DPC_BLC)
Vertical and Horizontal Scaler -> VHXS

Some products have this full pipeline (sama7g5), other products do not (sama5d2)

Add the modules to the isc base, and also extend the register range to include
the modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 11 ++++++--
 drivers/media/platform/atmel/atmel-isc.h      | 28 +++++++++++--------
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 2a619eef6aa3..66005cb3940f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2309,8 +2309,14 @@ int isc_pipeline_init(struct isc_device *isc)
 	struct regmap_field *regs;
 	unsigned int i;
 
-	/* WB-->CFA-->CC-->GAM-->CSC-->CBC-->SUB422-->SUB420 */
+	/*
+	 * DPCEN-->GDCEN-->BLCEN-->WB-->CFA-->CC-->
+	 * GAM-->VHXS-->CSC-->CBC-->SUB422-->SUB420
+	 */
 	const struct reg_field regfields[ISC_PIPE_LINE_NODE_NUM] = {
+		REG_FIELD(ISC_DPC_CTRL, 0, 0),
+		REG_FIELD(ISC_DPC_CTRL, 1, 1),
+		REG_FIELD(ISC_DPC_CTRL, 2, 2),
 		REG_FIELD(ISC_WB_CTRL, 0, 0),
 		REG_FIELD(ISC_CFA_CTRL, 0, 0),
 		REG_FIELD(ISC_CC_CTRL, 0, 0),
@@ -2318,6 +2324,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
+		REG_FIELD(ISC_VHXS_CTRL, 0, 0),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
@@ -2336,7 +2343,7 @@ int isc_pipeline_init(struct isc_device *isc)
 }
 
 /* regmap configuration */
-#define ATMEL_ISC_REG_MAX    0xbfc
+#define ATMEL_ISC_REG_MAX    0xd5c
 const struct regmap_config isc_regmap_config = {
 	.reg_bits       = 32,
 	.reg_stride     = 4,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index c5d956fd20a0..f574bcc3ba67 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -68,17 +68,21 @@ struct isc_format {
 };
 
 /* Pipeline bitmap */
-#define WB_ENABLE	BIT(0)
-#define CFA_ENABLE	BIT(1)
-#define CC_ENABLE	BIT(2)
-#define GAM_ENABLE	BIT(3)
-#define GAM_BENABLE	BIT(4)
-#define GAM_GENABLE	BIT(5)
-#define GAM_RENABLE	BIT(6)
-#define CSC_ENABLE	BIT(7)
-#define CBC_ENABLE	BIT(8)
-#define SUB422_ENABLE	BIT(9)
-#define SUB420_ENABLE	BIT(10)
+#define DPC_DPCENABLE	BIT(0)
+#define DPC_GDCENABLE	BIT(1)
+#define DPC_BLCENABLE	BIT(2)
+#define WB_ENABLE	BIT(3)
+#define CFA_ENABLE	BIT(4)
+#define CC_ENABLE	BIT(5)
+#define GAM_ENABLE	BIT(6)
+#define GAM_BENABLE	BIT(7)
+#define GAM_GENABLE	BIT(8)
+#define GAM_RENABLE	BIT(9)
+#define VHXS_ENABLE	BIT(10)
+#define CSC_ENABLE	BIT(11)
+#define CBC_ENABLE	BIT(12)
+#define SUB422_ENABLE	BIT(13)
+#define SUB420_ENABLE	BIT(14)
 
 #define GAM_ENABLES	(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
 
@@ -142,7 +146,7 @@ struct isc_ctrls {
 	u32 hist_minmax[HIST_BAYER][2];
 };
 
-#define ISC_PIPE_LINE_NODE_NUM	11
+#define ISC_PIPE_LINE_NODE_NUM	15
 
 /*
  * struct isc_reg_offsets - ISC device register offsets
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:54 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:54 +0300
Subject: [PATCH v2 19/30] media: atmel: atmel-isc: add CC initialization
 function
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-20-eugen.hristev@microchip.com>

Implement the color correction (CC) submodule initialization, as a product
specific function, which currently configures the neutral point in color
correction.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  1 +
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 15 +++++++++++++++
 3 files changed, 19 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 66005cb3940f..182903803c05 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -653,6 +653,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
+	isc->config_cc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f574bcc3ba67..a5f8d5001381 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -225,6 +225,8 @@ struct isc_reg_offsets {
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
  *			specific CBC module
+ * @config_cc:		pointer to a function that initializes product
+ *			specific CC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -298,6 +300,7 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
+		void (*config_cc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0ff13198d732..0ce8293622f9 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -56,6 +56,7 @@
 
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
+void isc_sama5d2_config_cc(struct isc_device *isc);
 
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
@@ -86,6 +87,19 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 		     isc->ctrls.contrast);
 }
 
+void isc_sama5d2_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -233,6 +247,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
+	isc->config_cc = isc_sama5d2_config_cc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:55 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:55 +0300
Subject: [PATCH v2 20/30] media: atmel: atmel-isc: create product specific
 v4l2 controls config
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-21-eugen.hristev@microchip.com>

Create product specific callback for initializing v4l2 controls.
Call this from v4l2 controls init function.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  5 +++--
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 15 +++++++++++++++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 182903803c05..69952b6ac401 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2036,11 +2036,12 @@ static int isc_ctrl_init(struct isc_device *isc)
 	if (ret < 0)
 		return ret;
 
+	/* Initialize product specific controls. For example, contrast */
+	isc->config_ctrls(isc, ops);
+
 	ctrls->brightness = 0;
-	ctrls->contrast = 256;
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
 			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index a5f8d5001381..eb549fadb1a8 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -227,6 +227,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_ctrls:	pointer to a functoin that initializes product
+ *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -301,6 +303,9 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+
+		void (*config_ctrls)(struct isc_device *isc,
+				     const struct v4l2_ctrl_ops *ops);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0ce8293622f9..7ff8b362568d 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -58,6 +58,9 @@ void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 
+void isc_sama5d2_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops);
+
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
@@ -100,6 +103,17 @@ void isc_sama5d2_config_cc(struct isc_device *isc)
 	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
 }
 
+void isc_sama5d2_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 256;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -248,6 +262,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:56 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:56 +0300
Subject: [PATCH v2 21/30] media: atmel: atmel-isc: create callback for DPC
 submodule product specific
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-22-eugen.hristev@microchip.com>

Create a product specific callback for initializing the DPC submodule
of the pipeline.
For sama5d2 product, this module does not exist, thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++++
 3 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 69952b6ac401..1f7116abc61a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -651,6 +651,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
+	isc->config_dpc(isc);
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index eb549fadb1a8..d6cd85a4c3e9 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -221,6 +221,8 @@ struct isc_reg_offsets {
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
  *
+ * @config_dpc:		pointer to a function that initializes product
+ *			specific DPC module
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
@@ -300,6 +302,7 @@ struct isc_device {
 	u32		max_height;
 
 	struct {
+		void (*config_dpc)(struct isc_device *isc);
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 7ff8b362568d..2b53e9427353 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -57,6 +57,7 @@
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
+void isc_sama5d2_config_dpc(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -114,6 +115,11 @@ void isc_sama5d2_config_ctrls(struct isc_device *isc,
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 }
 
+void isc_sama5d2_config_dpc(struct isc_device *isc)
+{
+	/* This module is not present on sama5d2 pipeline */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -259,6 +265,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_dpc = isc_sama5d2_config_dpc;
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:57 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:57 +0300
Subject: [PATCH v2 22/30] media: atmel: atmel-isc: create callback for GAM
 submodule product specific
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-23-eugen.hristev@microchip.com>

Create a product specific callback for initializing the GAM submodule
of the pipeline.
For sama5d2 product, there is no special configuration at this moment,
thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++++
 3 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 1f7116abc61a..bd24e0c99613 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -655,6 +655,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
+	isc->config_gam(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d6cd85a4c3e9..1e6988f1876e 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -229,6 +229,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_gam:		pointer to a function that initializes product
+ *			specific GAMMA module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -306,6 +308,7 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+		void (*config_gam)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 2b53e9427353..df26941af64b 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -58,6 +58,7 @@ void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
+void isc_sama5d2_config_gam(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -120,6 +121,11 @@ void isc_sama5d2_config_dpc(struct isc_device *isc)
 	/* This module is not present on sama5d2 pipeline */
 }
 
+void isc_sama5d2_config_gam(struct isc_device *isc)
+{
+	/* No specific gamma configuration */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -269,6 +275,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_gam = isc_sama5d2_config_gam;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:58 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:58 +0300
Subject: [PATCH v2 23/30] media: atmel: atmel-isc: create callback for RLP
 submodule product specific
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-24-eugen.hristev@microchip.com>

Create a product specific callback for initializing the RLP submodule
of the pipeline

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  6 ++----
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 11 +++++++++++
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bd24e0c99613..8422df41f083 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -711,11 +711,10 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 static int isc_configure(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
-	u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
+	u32 pfe_cfg0, dcfg, mask, pipeline;
 	struct isc_subdev_entity *subdev = isc->current_subdev;
 
 	pfe_cfg0 = isc->config.sd_format->pfe_cfg0_bps;
-	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
 	dcfg = isc->config.dcfg_imode | isc->dcfg;
@@ -728,8 +727,7 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
-			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+	isc->config_rlp(isc);
 
 	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 1e6988f1876e..abeef7b2ab27 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -231,6 +231,8 @@ struct isc_reg_offsets {
  *			specific CC module
  * @config_gam:		pointer to a function that initializes product
  *			specific GAMMA module
+ * @config_rlp:		pointer to a function that initializes product
+ *			specific RLP module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -309,6 +311,7 @@ struct isc_device {
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
 		void (*config_gam)(struct isc_device *isc);
+		void (*config_rlp)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index df26941af64b..855027821fba 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -59,6 +59,7 @@ void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
 void isc_sama5d2_config_gam(struct isc_device *isc);
+void isc_sama5d2_config_rlp(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -126,6 +127,15 @@ void isc_sama5d2_config_gam(struct isc_device *isc)
 	/* No specific gamma configuration */
 }
 
+void isc_sama5d2_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -276,6 +286,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
 	isc->config_gam = isc_sama5d2_config_gam;
+	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:50:59 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:50:59 +0300
Subject: [PATCH v2 24/30] media: atmel: atmel-isc: move the formats list into
 product specific code
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-25-eugen.hristev@microchip.com>

The list of input and output formats has to be product specific.
Move this list into the product specific code.
Have pointers to these arrays inside the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 167 ++----------------
 drivers/media/platform/atmel/atmel-isc.h      |  12 +-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 136 ++++++++++++++
 3 files changed, 165 insertions(+), 150 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8422df41f083..6746c9060e3f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -45,137 +45,6 @@ module_param(sensor_preferred, uint, 0644);
 MODULE_PARM_DESC(sensor_preferred,
 		 "Sensor is preferred to output the specified format (1-on 0-off), default 1");
 
-/* This is a list of the formats that the ISC can *output* */
-const struct isc_format controller_formats[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB444,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB555,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ABGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_XBGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV420,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV422P,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-	},
-};
-
-/* This is a list of formats that the ISC can receive as *input* */
-struct isc_format formats_list[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR8,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB8,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR10,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB10,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR12,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB12,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-	},
-
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -906,25 +775,26 @@ static int isc_querycap(struct file *file, void *priv,
 static int isc_enum_fmt_vid_cap(struct file *file, void *priv,
 				 struct v4l2_fmtdesc *f)
 {
+	struct isc_device *isc = video_drvdata(file);
 	u32 index = f->index;
 	u32 i, supported_index;
 
-	if (index < ARRAY_SIZE(controller_formats)) {
-		f->pixelformat = controller_formats[index].fourcc;
+	if (index < isc->controller_formats_size) {
+		f->pixelformat = isc->controller_formats[index].fourcc;
 		return 0;
 	}
 
-	index -= ARRAY_SIZE(controller_formats);
+	index -= isc->controller_formats_size;
 
 	i = 0;
 	supported_index = 0;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
-		if (!ISC_IS_FORMAT_RAW(formats_list[i].mbus_code) ||
-		    !formats_list[i].sd_support)
+	for (i = 0; i < isc->formats_list_size; i++) {
+		if (!ISC_IS_FORMAT_RAW(isc->formats_list[i].mbus_code) ||
+		    !isc->formats_list[i].sd_support)
 			continue;
 		if (supported_index == index) {
-			f->pixelformat = formats_list[i].fourcc;
+			f->pixelformat = isc->formats_list[i].fourcc;
 			return 0;
 		}
 		supported_index++;
@@ -1465,8 +1335,8 @@ static int isc_enum_framesizes(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fsize->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fsize->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fsize->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -1502,8 +1372,8 @@ static int isc_enum_frameintervals(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fival->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fival->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fival->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -2111,12 +1981,13 @@ static void isc_async_unbind(struct v4l2_async_notifier *notifier,
 	v4l2_ctrl_handler_free(&isc->ctrls.handler);
 }
 
-static struct isc_format *find_format_by_code(unsigned int code, int *index)
+static struct isc_format *find_format_by_code(struct isc_device *isc,
+					      unsigned int code, int *index)
 {
-	struct isc_format *fmt = &formats_list[0];
+	struct isc_format *fmt = &isc->formats_list[0];
 	unsigned int i;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
+	for (i = 0; i < isc->formats_list_size; i++) {
 		if (fmt->mbus_code == code) {
 			*index = i;
 			return fmt;
@@ -2133,7 +2004,7 @@ static int isc_formats_init(struct isc_device *isc)
 	struct isc_format *fmt;
 	struct v4l2_subdev *subdev = isc->current_subdev->sd;
 	unsigned int num_fmts, i, j;
-	u32 list_size = ARRAY_SIZE(formats_list);
+	u32 list_size = isc->formats_list_size;
 	struct v4l2_subdev_mbus_code_enum mbus_code = {
 		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
 	};
@@ -2143,7 +2014,7 @@ static int isc_formats_init(struct isc_device *isc)
 	       NULL, &mbus_code)) {
 		mbus_code.index++;
 
-		fmt = find_format_by_code(mbus_code.code, &i);
+		fmt = find_format_by_code(isc, mbus_code.code, &i);
 		if (!fmt) {
 			v4l2_warn(&isc->v4l2_dev, "Mbus code %x not supported\n",
 				  mbus_code.code);
@@ -2164,7 +2035,7 @@ static int isc_formats_init(struct isc_device *isc)
 	if (!isc->user_formats)
 		return -ENOMEM;
 
-	fmt = &formats_list[0];
+	fmt = &isc->formats_list[0];
 	for (i = 0, j = 0; i < list_size; i++) {
 		if (fmt->sd_support)
 			isc->user_formats[j++] = fmt;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index abeef7b2ab27..14e318a7373c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -237,6 +237,12 @@ struct isc_reg_offsets {
  *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
+ * @controller_formats:	pointer to the array of possible formats that the
+ *			controller can output
+ * @formats_list:	pointer to the array of possible formats that can
+ *			be used as an input to the controller
+ * @controller_formats_size:	size of controller_formats array
+ * @formats_list_size:	size of formats_list array
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -318,10 +324,12 @@ struct isc_device {
 	};
 
 	struct isc_reg_offsets		offsets;
+	const struct isc_format		*controller_formats;
+	struct isc_format		*formats_list;
+	u32				controller_formats_size;
+	u32				formats_list_size;
 };
 
-extern struct isc_format formats_list[];
-extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 855027821fba..a5823a3a6111 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -64,6 +64,137 @@ void isc_sama5d2_config_rlp(struct isc_device *isc);
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
 
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama5d2_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama5d2_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
@@ -299,6 +430,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
+	isc->controller_formats = sama5d2_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama5d2_controller_formats);
+	isc->formats_list = sama5d2_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama5d2_formats_list);
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:00 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:00 +0300
Subject: [PATCH v2 25/30] media: atmel: atmel-isc: create an adapt pipeline
 callback for product specific
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-26-eugen.hristev@microchip.com>

Once the pipeline is set in the base code, create a callback that will adapt
the ISC pipeline to each product.
Create the adapt_pipeline callback that will be used in this fashion.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  4 ++++
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 12 ++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 6746c9060e3f..a3c299068bd5 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1047,6 +1047,10 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 	default:
 		isc->try_config.bits_pipeline = 0x0;
 	}
+
+	/* Tune the pipeline to product specific */
+	isc->adapt_pipeline(isc);
+
 	return 0;
 }
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 14e318a7373c..19cc60dfcbe0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -236,6 +236,9 @@ struct isc_reg_offsets {
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
+ * @adapt_pipeline:	pointer to a function that adapts the pipeline bits
+ *			to the product specific pipeline
+ *
  * @offsets:		struct holding the product specific register offsets
  * @controller_formats:	pointer to the array of possible formats that the
  *			controller can output
@@ -321,6 +324,8 @@ struct isc_device {
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
+
+		void (*adapt_pipeline)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index a5823a3a6111..b2ace528b260 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,12 +54,17 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+#define ISC_SAMA5D2_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
 void isc_sama5d2_config_gam(struct isc_device *isc);
 void isc_sama5d2_config_rlp(struct isc_device *isc);
+void isc_sama5d2_adapt_pipeline(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -267,6 +272,11 @@ void isc_sama5d2_config_rlp(struct isc_device *isc)
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 }
 
+void isc_sama5d2_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA5D2_PIPELINE;
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -420,6 +430,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
+	isc->adapt_pipeline = isc_sama5d2_adapt_pipeline;
+
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:01 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:01 +0300
Subject: [PATCH v2 26/30] media: atmel: atmel-isc-regs: add additional fields
 for sama7g5 type pipeline
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-27-eugen.hristev@microchip.com>

Add additional fields for registers present in sama7g5 type pipeline.
Extend register masks for additional bits in sama7g5 type pipeline registers.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 457eed74cda9..5f99bf7717c1 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -289,8 +289,18 @@
 #define ISC_RLP_CFG_MODE_ARGB32         0xa
 #define ISC_RLP_CFG_MODE_YYCC           0xb
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
+#define ISC_RLP_CFG_MODE_YCYC           0xd
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+#define ISC_RLP_CFG_LSH			BIT(5)
+
+#define ISC_RLP_CFG_YMODE_YUYV		(3 << 6)
+#define ISC_RLP_CFG_YMODE_YVYU		(2 << 6)
+#define ISC_RLP_CFG_YMODE_VYUY		(0 << 6)
+#define ISC_RLP_CFG_YMODE_UYVY		(1 << 6)
+
+#define ISC_RLP_CFG_YMODE_MASK		GENMASK(7, 6)
+
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
@@ -332,13 +342,15 @@
 #define ISC_DCFG_YMBSIZE_BEATS4         (0x1 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS8         (0x2 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS16        (0x3 << 4)
-#define ISC_DCFG_YMBSIZE_MASK           GENMASK(5, 4)
+#define ISC_DCFG_YMBSIZE_BEATS32        (0x4 << 4)
+#define ISC_DCFG_YMBSIZE_MASK           GENMASK(6, 4)
 
 #define ISC_DCFG_CMBSIZE_SINGLE         (0x0 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS4         (0x1 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS8         (0x2 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS16        (0x3 << 8)
-#define ISC_DCFG_CMBSIZE_MASK           GENMASK(9, 8)
+#define ISC_DCFG_CMBSIZE_BEATS32        (0x4 << 8)
+#define ISC_DCFG_CMBSIZE_MASK           GENMASK(10, 8)
 
 /* DMA Control Register */
 #define ISC_DCTRL       0x000003e4
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:02 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:02 +0300
Subject: [PATCH v2 27/30] media: atmel: atmel-isc-base: add support for more
 formats and additional pipeline modules
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-28-eugen.hristev@microchip.com>

Add support for additional formats supported by newer pipelines, and for
additional pipeline modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 48 +++++++++++++++----
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index a3c299068bd5..f30493a1dccd 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -843,6 +843,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
 	case V4L2_PIX_FMT_YUV420:
 	case V4L2_PIX_FMT_YUV422P:
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		ret = 0;
 		yuv = true;
 		break;
@@ -857,6 +859,7 @@ static int isc_try_validate_formats(struct isc_device *isc)
 		break;
 	case V4L2_PIX_FMT_GREY:
 	case V4L2_PIX_FMT_Y10:
+	case V4L2_PIX_FMT_Y16:
 		ret = 0;
 		grey = true;
 		break;
@@ -887,6 +890,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
  */
 static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 {
+	isc->try_config.rlp_cfg_mode = 0;
+
 	switch (isc->try_config.fourcc) {
 	case V4L2_PIX_FMT_SBGGR8:
 	case V4L2_PIX_FMT_SGBRG8:
@@ -953,7 +958,19 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.bpp = 16;
 		break;
 	case V4L2_PIX_FMT_YUYV:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YYCC;
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_YUYV;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_UYVY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_UYVY;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_VYUY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_VYUY;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -964,8 +981,11 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 8;
 		break;
+	case V4L2_PIX_FMT_Y16:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10 | ISC_RLP_CFG_LSH;
+		fallthrough;
 	case V4L2_PIX_FMT_Y10:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10;
+		isc->try_config.rlp_cfg_mode |= ISC_RLP_CFG_MODE_DATY10;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED16;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -999,7 +1019,8 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				WB_ENABLE | GAM_ENABLES;
+				WB_ENABLE | GAM_ENABLES | DPC_BLCENABLE |
+				CC_ENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1008,8 +1029,9 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE;
+				CSC_ENABLE | GAM_ENABLES | WB_ENABLE |
+				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE |
+				DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1019,33 +1041,39 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_GREY:
-		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
+	case V4L2_PIX_FMT_Y16:
 		/* if sensor format is RAW, we convert inside ISC */
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				CBC_ENABLE;
+				CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	default:
-		isc->try_config.bits_pipeline = 0x0;
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code))
+			isc->try_config.bits_pipeline = WB_ENABLE | DPC_BLCENABLE;
+		else
+			isc->try_config.bits_pipeline = 0x0;
 	}
 
 	/* Tune the pipeline to product specific */
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:03 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:03 +0300
Subject: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc binding
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-29-eugen.hristev@microchip.com>

Add bindings for the microchip xisc, a driver based on atmel-isc.
It shares common code with atmel-isc, but the xisc is the next generation
ISC which is present on sama7g5 product.
It has an enhanced pipeline, additional modules, formats, and it supports
not only parallel sensors, but also serial sensors, by connecting to a demux
endpoint present on sama7g5.
One of the key points for creating a new binding is the clocking scheme, as
atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
input clock.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---

Hello Rob, all,

I did not convert this yet to yaml because I would like first your feedback
if the binding is good.
If it's fine I will convert both this new binding and the old atmel-isc
to yaml.

Thanks for your feedback,
Eugen

 .../bindings/media/microchip-xisc.txt         | 64 +++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt

diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt b/Documentation/devicetree/bindings/media/microchip-xisc.txt
new file mode 100644
index 000000000000..080a357ed84d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
@@ -0,0 +1,64 @@
+Microchip eXtended Image Sensor Controller (XISC)
+----------------------------------------------
+
+Required properties for XISC:
+- compatible
+	Must be "microchip,sama7g5-xisc".
+- reg
+	Physical base address and length of the registers set for the device.
+- interrupts
+	Should contain IRQ line for the XISC.
+- clocks
+	List of clock specifiers, corresponding to entries in
+	the clock-names property;
+	Please refer to clock-bindings.txt.
+- clock-names
+	Required elements: "hclock".
+	This is the clock that clocks the sensor controller, and is usually
+	fed from the clock tree. It is used for the internal controller logic.
+- #clock-cells
+	Should be 0.
+- clock-output-names
+	Should be "isc-mck".
+- pinctrl-names, pinctrl-0
+	Please refer to pinctrl-bindings.txt.
+
+Optional properties for XISC:
+- microchip,mipi-mode;
+	As the XISC is usually connected to a demux/bridge, the XISC receives
+	the same type of input, however, it should be aware of the type of
+	signals received. The mipi-mode enables different internal handling
+	of the data and clock lines.
+
+XISC supports a single port node with internal parallel bus.
+It should contain one 'port' child node with child 'endpoint' node.
+Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+This endpoint has to be connected to a bridge that acts as a demux from either
+a serial interface or acts as a simple direct bridge to a parallel sensor.
+
+Example:
+xisc: xisc at e1408000 {
+	compatible = "microchip,sama7g5-isc";
+	reg = <0xe1408000 0x2000>;
+	interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+	clock-names = "hclock";
+	#clock-cells = <0>;
+	clock-output-names = "isc-mck";
+	microchip,mipi-mode;
+
+	port at 1 {
+		reg = <1>;
+		xisc_in: endpoint {
+		bus-width = <12>;
+		hsync-active = <1>;
+		vsync-active = <1>;
+		remote-endpoint = <&csi2dc_out>;
+		};
+	};
+};
+
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:04 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:04 +0300
Subject: [PATCH v2 29/30] media: atmel: atmel-isc-sama5d2: remove duplicate
 define
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-30-eugen.hristev@microchip.com>

Remove a duplicate definition of clock max divider

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index b2ace528b260..213a2ecc7c66 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -52,8 +52,6 @@
 #define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
 #define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
-#define ISC_CLK_MAX_DIV		255
-
 #define ISC_SAMA5D2_PIPELINE \
 	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
 	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
-- 
2.25.1



From eugen.hristev at microchip.com  Mon Apr  5 16:51:05 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Mon, 5 Apr 2021 18:51:05 +0300
Subject: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc driver
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <20210405155105.162529-31-eugen.hristev@microchip.com>

Add driver for the extended variant of the isc, the microchip XISC
present on sama7g5 product.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v2:
- adapted to new fwnode subdev style API, as in kernel 5.12.
my old code was based on 5.10 style API.

 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c |   2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  26 +
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
 6 files changed, 684 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index eedc14aafb32..73ce083c2fc6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)		+= rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)		+= atmel/
 obj-$(CONFIG_VIDEO_ATMEL_ISI)		+= atmel/
+obj-$(CONFIG_VIDEO_ATMEL_XISC)		+= atmel/
 
 obj-$(CONFIG_VIDEO_STM32_DCMI)		+= stm32/
 
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 1850fe7f9360..99b51213f871 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -12,6 +12,17 @@ config VIDEO_ATMEL_ISC
 	   This module makes the ATMEL Image Sensor Controller available
 	   as a v4l2 device.
 
+config VIDEO_ATMEL_XISC
+	tristate "ATMEL eXtended Image Sensor Controller (XISC) support"
+	depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+	depends on ARCH_AT91 || COMPILE_TEST
+	select VIDEOBUF2_DMA_CONTIG
+	select REGMAP_MMIO
+	select V4L2_FWNODE
+	help
+	   This module makes the ATMEL eXtended Image Sensor Controller
+	   available as a v4l2 device.
+
 config VIDEO_ATMEL_ISI
 	tristate "ATMEL Image Sensor Interface (ISI) support"
 	depends on VIDEO_V4L2 && OF
diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile
index 2dba38994a70..c5c01556c653 100644
--- a/drivers/media/platform/atmel/Makefile
+++ b/drivers/media/platform/atmel/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o
+atmel-xisc-objs = atmel-sama7g5-isc.o atmel-isc-base.o
 
 obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
 obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
+obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel-xisc.o
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index f30493a1dccd..d6409406ce2f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -592,7 +592,7 @@ static int isc_configure(struct isc_device *isc)
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
 	       ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW |
 	       ISC_PFE_CFG0_MODE_MASK | ISC_PFE_CFG0_CCIR_CRC |
-		   ISC_PFE_CFG0_CCIR656;
+	       ISC_PFE_CFG0_CCIR656 | ISC_PFE_CFG0_MIPI;
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5f99bf7717c1..d06b72228d4f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -26,6 +26,7 @@
 #define ISC_PFE_CFG0_PPOL_LOW   BIT(2)
 #define ISC_PFE_CFG0_CCIR656    BIT(9)
 #define ISC_PFE_CFG0_CCIR_CRC   BIT(10)
+#define ISC_PFE_CFG0_MIPI	BIT(14)
 
 #define ISC_PFE_CFG0_MODE_PROGRESSIVE   (0x0 << 4)
 #define ISC_PFE_CFG0_MODE_MASK          GENMASK(6, 4)
@@ -184,6 +185,8 @@
 /* ISC Gamma Correction Control Register */
 #define ISC_GAM_CTRL    0x00000094
 
+#define ISC_GAM_CTRL_BIPART	BIT(4)
+
 /* ISC_Gamma Correction Blue Entry Register */
 #define ISC_GAM_BENTRY	0x00000098
 
@@ -222,6 +225,8 @@
 
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
+/* Offset for CSC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CSC_OFFSET	0x11c
 
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
@@ -246,6 +251,8 @@
 
 /* Offset for CBC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CBC_OFFSET	0
+/* Offset for CBC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CBC_OFFSET	0x11c
 
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
@@ -261,18 +268,30 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Hue Register */
+#define ISC_CBCHS_HUE	0x4e0
+/* Saturation Register */
+#define ISC_CBCHS_SAT	0x4e4
+
 /* Offset for SUB422 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB422_OFFSET	0
+/* Offset for SUB422 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB422_OFFSET	0x124
+
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
 /* Offset for SUB420 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB420_OFFSET	0
+/* Offset for SUB420 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB420_OFFSET	0x124
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
 /* Offset for RLP register specific to sama5d2 product */
 #define ISC_SAMA5D2_RLP_OFFSET	0
+/* Offset for RLP register specific to sama7g5 product */
+#define ISC_SAMA7G5_RLP_OFFSET	0x124
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
@@ -303,6 +322,8 @@
 
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
+/* Offset for HIS register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_OFFSET	0x124
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
@@ -326,6 +347,8 @@
 
 /* Offset for DMA register specific to sama5d2 product */
 #define ISC_SAMA5D2_DMA_OFFSET	0
+/* Offset for DMA register specific to sama7g5 product */
+#define ISC_SAMA7G5_DMA_OFFSET	0x13c
 
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
@@ -376,11 +399,14 @@
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_VERSION_OFFSET	0
+#define ISC_SAMA7G5_VERSION_OFFSET	0x13c
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
+/* Offset for version register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_ENTRY_OFFSET	0x14c
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-sama7g5-isc.c b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
new file mode 100644
index 000000000000..9d2f0bbd8815
--- /dev/null
+++ b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
@@ -0,0 +1,643 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip eXtended Image Sensor Controller (XISC) driver
+ *
+ * Copyright (C) 2019-2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ * Author: Eugen Hristev <eugen.hristev at microchip.com>
+ *
+ * Sensor-->PFE-->DPC-->WB-->CFA-->CC-->GAM-->VHXS-->CSC-->CBHS-->SUB-->RLP-->DMA-->HIS
+ *
+ * ISC video pipeline integrates the following submodules:
+ * PFE: Parallel Front End to sample the camera sensor input stream
+ * DPC: Defective Pixel Correction with black offset correction, green disparity
+ *      correction and defective pixel correction (3 modules total)
+ *  WB: Programmable white balance in the Bayer domain
+ * CFA: Color filter array interpolation module
+ *  CC: Programmable color correction
+ * GAM: Gamma correction
+ *VHXS: Vertical and Horizontal Scaler
+ * CSC: Programmable color space conversion
+ *CBHS: Contrast Brightness Hue and Saturation control
+ * SUB: This module performs YCbCr444 to YCbCr420 chrominance subsampling
+ * RLP: This module performs rounding, range limiting
+ *      and packing of the incoming data
+ * DMA: This module performs DMA master accesses to write frames to external RAM
+ * HIS: Histogram module performs statistic counters on the frames
+ */
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/videodev2.h>
+
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-event.h>
+#include <media/v4l2-image-sizes.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+#include <media/videobuf2-dma-contig.h>
+
+#include "atmel-isc-regs.h"
+#include "atmel-isc.h"
+
+#define ISC_SAMA7G5_MAX_SUPPORT_WIDTH   3264
+#define ISC_SAMA7G5_MAX_SUPPORT_HEIGHT  2464
+
+#define ISC_SAMA7G5_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
+void isc_sama7g5_config_csc(struct isc_device *isc);
+void isc_sama7g5_config_cbc(struct isc_device *isc);
+void isc_sama7g5_config_cc(struct isc_device *isc);
+void isc_sama7g5_config_dpc(struct isc_device *isc);
+void isc_sama7g5_config_gam(struct isc_device *isc);
+void isc_sama7g5_config_rlp(struct isc_device *isc);
+
+void isc_sama7g5_adapt_pipeline(struct isc_device *isc);
+
+void isc_sama7g5_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops);
+
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama7g5_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_VYUY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y16,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama7g5_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
+void isc_sama7g5_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
+}
+
+void isc_sama7g5_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure what is set via v4l2 ctrls */
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc, isc->ctrls.contrast);
+	/* Configure Hue and Saturation as neutral midpoint */
+	regmap_write(regmap, ISC_CBCHS_HUE, 0);
+	regmap_write(regmap, ISC_CBCHS_SAT, (1 << 4));
+}
+
+void isc_sama7g5_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
+void isc_sama7g5_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 16;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 16);
+}
+
+void isc_sama7g5_config_dpc(struct isc_device *isc)
+{
+	u32 bay_cfg = isc->config.sd_format->cfa_baycfg;
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BLOFF_MASK,
+			   (64 << ISC_DPC_CFG_BLOFF_SHIFT));
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BAYCFG_MASK,
+			   (bay_cfg << ISC_DPC_CFG_BAYCFG_SHIFT));
+}
+
+void isc_sama7g5_config_gam(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_GAM_CTRL, ISC_GAM_CTRL_BIPART,
+			   ISC_GAM_CTRL_BIPART);
+}
+
+void isc_sama7g5_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK | ISC_RLP_CFG_LSH |
+			   ISC_RLP_CFG_YMODE_MASK, rlp_mode);
+}
+
+void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA7G5_PIPELINE;
+}
+
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama7g5_gamma_table[][GAMMA_ENTRIES] = {
+	/* index 0 --> gamma bipartite */
+	{
+	      0x980,  0x4c0320,  0x650260,  0x7801e0,  0x8701a0,  0x940180,
+	   0xa00160,  0xab0120,  0xb40120,  0xbd0120,  0xc60100,  0xce0100,
+	   0xd600e0,  0xdd00e0,  0xe400e0,  0xeb00c0,  0xf100c0,  0xf700c0,
+	   0xfd00c0, 0x10300a0, 0x10800c0, 0x10e00a0, 0x11300a0, 0x11800a0,
+	  0x11d00a0, 0x12200a0, 0x12700a0, 0x12c0080, 0x13000a0, 0x1350080,
+	  0x13900a0, 0x13e0080, 0x1420076, 0x17d0062, 0x1ae0054, 0x1d8004a,
+	  0x1fd0044, 0x21f003e, 0x23e003a, 0x25b0036, 0x2760032, 0x28f0030,
+	  0x2a7002e, 0x2be002c, 0x2d4002c, 0x2ea0028, 0x2fe0028, 0x3120026,
+	  0x3250024, 0x3370024, 0x3490022, 0x35a0022, 0x36b0020, 0x37b0020,
+	  0x38b0020, 0x39b001e, 0x3aa001e, 0x3b9001c, 0x3c7001c, 0x3d5001c,
+	  0x3e3001c, 0x3f1001c, 0x3ff001a, 0x40c001a },
+};
+
+static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
+{
+	struct device_node *np = dev->of_node;
+	struct device_node *epn = NULL;
+	struct isc_subdev_entity *subdev_entity;
+	unsigned int flags;
+	int ret;
+	bool mipi_mode;
+
+	INIT_LIST_HEAD(&isc->subdev_entities);
+
+	mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
+
+	while (1) {
+		struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
+
+		epn = of_graph_get_next_endpoint(np, epn);
+		if (!epn)
+			return 0;
+
+		ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
+						 &v4l2_epn);
+		if (ret) {
+			ret = -EINVAL;
+			dev_err(dev, "Could not parse the endpoint\n");
+			break;
+		}
+
+		subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
+					     GFP_KERNEL);
+		if (!subdev_entity) {
+			ret = -ENOMEM;
+			break;
+		}
+		subdev_entity->epn = epn;
+
+		flags = v4l2_epn.bus.parallel.flags;
+
+		if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
+
+		if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
+
+		if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
+
+		if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
+					ISC_PFE_CFG0_CCIR656;
+
+		if (mipi_mode)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
+
+		list_add_tail(&subdev_entity->list, &isc->subdev_entities);
+	}
+	of_node_put(epn);
+
+	return ret;
+}
+
+static int microchip_xisc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct isc_device *isc;
+	struct resource *res;
+	void __iomem *io_base;
+	struct isc_subdev_entity *subdev_entity;
+	int irq;
+	int ret;
+	u32 ver;
+
+	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
+	if (!isc)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, isc);
+	isc->dev = dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	io_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(io_base))
+		return PTR_ERR(io_base);
+
+	isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
+	if (IS_ERR(isc->regmap)) {
+		ret = PTR_ERR(isc->regmap);
+		dev_err(dev, "failed to init register map: %d\n", ret);
+		return ret;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
+			       "microchip-sama7g5-xisc", isc);
+	if (ret < 0) {
+		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
+			irq, ret);
+		return ret;
+	}
+
+	isc->gamma_table = isc_sama7g5_gamma_table;
+	isc->gamma_max = 0;
+
+	isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
+
+	isc->config_dpc = isc_sama7g5_config_dpc;
+	isc->config_csc = isc_sama7g5_config_csc;
+	isc->config_cbc = isc_sama7g5_config_cbc;
+	isc->config_cc = isc_sama7g5_config_cc;
+	isc->config_gam = isc_sama7g5_config_gam;
+	isc->config_rlp = isc_sama7g5_config_rlp;
+	isc->config_ctrls = isc_sama7g5_config_ctrls;
+
+	isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
+
+	isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
+
+	isc->controller_formats = sama7g5_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
+	isc->formats_list = sama7g5_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
+
+	/* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
+
+	ret = isc_pipeline_init(isc);
+	if (ret)
+		return ret;
+
+	isc->hclock = devm_clk_get(dev, "hclock");
+	if (IS_ERR(isc->hclock)) {
+		ret = PTR_ERR(isc->hclock);
+		dev_err(dev, "failed to get hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret) {
+		dev_err(dev, "failed to enable hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = isc_clk_init(isc);
+	if (ret) {
+		dev_err(dev, "failed to init isc clock: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret) {
+		dev_err(dev, "failed to enable ispck: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	/* ispck should be greater or equal to hclock */
+	ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
+	if (ret) {
+		dev_err(dev, "failed to set ispck rate: %d\n", ret);
+		goto unprepare_clk;
+	}
+
+	ret = v4l2_device_register(dev, &isc->v4l2_dev);
+	if (ret) {
+		dev_err(dev, "unable to register v4l2 device.\n");
+		goto unprepare_clk;
+	}
+
+	ret = xisc_parse_dt(dev, isc);
+	if (ret) {
+		dev_err(dev, "fail to parse device tree\n");
+		goto unregister_v4l2_device;
+	}
+
+	if (list_empty(&isc->subdev_entities)) {
+		dev_err(dev, "no subdev found\n");
+		ret = -ENODEV;
+		goto unregister_v4l2_device;
+	}
+
+	list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
+		struct v4l2_async_subdev *asd;
+
+		v4l2_async_notifier_init(&subdev_entity->notifier);
+
+		asd = v4l2_async_notifier_add_fwnode_remote_subdev(
+					&subdev_entity->notifier,
+					of_fwnode_handle(subdev_entity->epn),
+					struct v4l2_async_subdev);
+
+		of_node_put(subdev_entity->epn);
+		subdev_entity->epn = NULL;
+
+		if (IS_ERR(asd)) {
+			ret = PTR_ERR(asd);
+			goto cleanup_subdev;
+		}
+
+		subdev_entity->notifier.ops = &isc_async_ops;
+
+		ret = v4l2_async_notifier_register(&isc->v4l2_dev,
+						   &subdev_entity->notifier);
+		if (ret) {
+			dev_err(dev, "fail to register async notifier\n");
+			goto cleanup_subdev;
+		}
+
+		if (video_is_registered(&isc->video_dev))
+			break;
+	}
+
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+	pm_request_idle(dev);
+
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip XISC version %x\n", ver);
+
+	return 0;
+
+cleanup_subdev:
+	isc_subdev_cleanup(isc);
+
+unregister_v4l2_device:
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+unprepare_clk:
+	clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return ret;
+}
+
+static int microchip_xisc_remove(struct platform_device *pdev)
+{
+	struct isc_device *isc = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	isc_subdev_cleanup(isc);
+
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_suspend(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_resume(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret)
+		clk_disable_unprepare(isc->hclock);
+
+	return ret;
+}
+
+static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
+};
+
+static const struct of_device_id microchip_xisc_of_match[] = {
+	{ .compatible = "microchip,sama7g5-isc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
+
+static struct platform_driver microchip_xisc_driver = {
+	.probe	= microchip_xisc_probe,
+	.remove	= microchip_xisc_remove,
+	.driver	= {
+		.name		= "microchip-sama7g5-xisc",
+		.pm		= &microchip_xisc_dev_pm_ops,
+		.of_match_table = of_match_ptr(microchip_xisc_of_match),
+	},
+};
+
+module_platform_driver(microchip_xisc_driver);
+
+MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
+MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
+MODULE_LICENSE("GPL v2");
+MODULE_SUPPORTED_DEVICE("video");
-- 
2.25.1



From sashal at kernel.org  Mon Apr  5 17:03:48 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:03:48 -0400
Subject: [PATCH AUTOSEL 5.11 05/22] drm/imx: imx-ldb: fix out of bounds array
 access warning
In-Reply-To: <20210405160406.268132-1-sashal@kernel.org>
References: <20210405160406.268132-1-sashal@kernel.org>
Message-ID: <20210405160406.268132-5-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 41e2978cb1eb..75036aaa0c63 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -190,6 +190,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -248,6 +253,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:03:46 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:03:46 -0400
Subject: [PATCH AUTOSEL 5.11 03/22] KVM: arm64: Hide system instruction access
 to Trace registers
In-Reply-To: <20210405160406.268132-1-sashal@kernel.org>
References: <20210405160406.268132-1-sashal@kernel.org>
Message-ID: <20210405160406.268132-3-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.

Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 33b6f56dcb21..22106062cb63 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -380,7 +380,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:03:47 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:03:47 -0400
Subject: [PATCH AUTOSEL 5.11 04/22] KVM: arm64: Disable guest access to trace
 filter controls
In-Reply-To: <20210405160406.268132-1-sashal@kernel.org>
References: <20210405160406.268132-1-sashal@kernel.org>
Message-ID: <20210405160406.268132-4-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 4e90c2debf70..94d4025acc0b 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -278,6 +278,7 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 7a7e425616b5..dbc890511631 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -89,6 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -112,6 +113,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:12 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:12 -0400
Subject: [PATCH AUTOSEL 5.10 03/22] KVM: arm64: Hide system instruction access
 to Trace registers
In-Reply-To: <20210405160432.268374-1-sashal@kernel.org>
References: <20210405160432.268374-1-sashal@kernel.org>
Message-ID: <20210405160432.268374-3-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.

Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 7da9a7cee4ce..5001c43ea6c3 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -382,7 +382,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:13 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:13 -0400
Subject: [PATCH AUTOSEL 5.10 04/22] KVM: arm64: Disable guest access to trace
 filter controls
In-Reply-To: <20210405160432.268374-1-sashal@kernel.org>
References: <20210405160432.268374-1-sashal@kernel.org>
Message-ID: <20210405160432.268374-4-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 64ce29378467..395cb22d9f7d 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -277,6 +277,7 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 7a7e425616b5..dbc890511631 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -89,6 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -112,6 +113,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:14 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:14 -0400
Subject: [PATCH AUTOSEL 5.10 05/22] drm/imx: imx-ldb: fix out of bounds array
 access warning
In-Reply-To: <20210405160432.268374-1-sashal@kernel.org>
References: <20210405160432.268374-1-sashal@kernel.org>
Message-ID: <20210405160432.268374-5-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 41e2978cb1eb..75036aaa0c63 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -190,6 +190,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -248,6 +253,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:48 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:48 -0400
Subject: [PATCH AUTOSEL 5.4 03/13] KVM: arm64: Disable guest access to trace
 filter controls
In-Reply-To: <20210405160459.268794-1-sashal@kernel.org>
References: <20210405160459.268794-1-sashal@kernel.org>
Message-ID: <20210405160459.268794-3-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index a4ffd9b55e72..9be64c0ad31f 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -276,6 +276,7 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 7a7e425616b5..dbc890511631 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -89,6 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -112,6 +113,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:49 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:49 -0400
Subject: [PATCH AUTOSEL 5.4 04/13] drm/imx: imx-ldb: fix out of bounds array
 access warning
In-Reply-To: <20210405160459.268794-1-sashal@kernel.org>
References: <20210405160459.268794-1-sashal@kernel.org>
Message-ID: <20210405160459.268794-4-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index d6629fc869f3..116473c2360a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -197,6 +197,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -255,6 +260,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:08 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:08 -0400
Subject: [PATCH AUTOSEL 4.19 1/8] KVM: arm64: Hide system instruction access
 to Trace registers
Message-ID: <20210405160515.269020-1-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.

Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 1719d21a171a..122d5e843ab6 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -258,7 +258,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:09 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:09 -0400
Subject: [PATCH AUTOSEL 4.19 2/8] KVM: arm64: Disable guest access to trace
 filter controls
In-Reply-To: <20210405160515.269020-1-sashal@kernel.org>
References: <20210405160515.269020-1-sashal@kernel.org>
Message-ID: <20210405160515.269020-2-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index a3b6f58d188c..6d43f7901da2 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -198,6 +198,7 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 4e722d73a3c3..3606f6b89094 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -100,6 +100,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -123,6 +124,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:22 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:22 -0400
Subject: [PATCH AUTOSEL 4.14 1/5] KVM: arm64: Hide system instruction access
 to Trace registers
Message-ID: <20210405160526.269140-1-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.

Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 174aa12fb8b1..1481e18aa5ca 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -230,7 +230,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:24 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:24 -0400
Subject: [PATCH AUTOSEL 4.14 3/5] drm/imx: imx-ldb: fix out of bounds array
 access warning
In-Reply-To: <20210405160526.269140-1-sashal@kernel.org>
References: <20210405160526.269140-1-sashal@kernel.org>
Message-ID: <20210405160526.269140-3-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index d38648a7ef2d..d88ac6f2222a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -206,6 +206,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -264,6 +269,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:33 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:33 -0400
Subject: [PATCH AUTOSEL 4.9 1/2] drm/imx: imx-ldb: fix out of bounds array
 access warning
Message-ID: <20210405160534.269237-1-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 2df407b2b0da..3a9d06de81b4 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -212,6 +212,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -270,6 +275,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:04:47 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:04:47 -0400
Subject: [PATCH AUTOSEL 5.4 02/13] KVM: arm64: Hide system instruction access
 to Trace registers
In-Reply-To: <20210405160459.268794-1-sashal@kernel.org>
References: <20210405160459.268794-1-sashal@kernel.org>
Message-ID: <20210405160459.268794-2-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit 1d676673d665fd2162e7e466dcfbe5373bfdb73e ]

Currently we advertise the ID_AA6DFR0_EL1.TRACEVER for the guest,
when the trace register accesses are trapped (CPTR_EL2.TTA == 1).
So, the guest will get an undefined instruction, if trusts the
ID registers and access one of the trace registers.
Lets be nice to the guest and hide the feature to avoid
unexpected behavior.

Even though this can be done at KVM sysreg emulation layer,
we do this by removing the TRACEVER from the sanitised feature
register field. This is fine as long as the ETM drivers
can handle the individual trace units separately, even
when there are differences among the CPUs.

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-2-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 79caab15ccbf..acdef8d76c64 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -277,7 +277,6 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
 	 * of support.
 	 */
 	S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
 	ARM64_FTR_END,
 };
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:37 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:37 -0400
Subject: [PATCH AUTOSEL 4.4] drm/imx: imx-ldb: fix out of bounds array access
 warning
Message-ID: <20210405160538.269310-1-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index b9dc2ef64ed8..74585ba16501 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -217,6 +217,11 @@ static void imx_ldb_encoder_commit(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -267,6 +272,11 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder *encoder,
 	unsigned long di_clk = mode->clock * 1000;
 	int mux = imx_drm_encoder_get_mux_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:23 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:23 -0400
Subject: [PATCH AUTOSEL 4.14 2/5] KVM: arm64: Disable guest access to trace
 filter controls
In-Reply-To: <20210405160526.269140-1-sashal@kernel.org>
References: <20210405160526.269140-1-sashal@kernel.org>
Message-ID: <20210405160526.269140-2-sashal@kernel.org>

From: Suzuki K Poulose <suzuki.poulose at arm.com>

[ Upstream commit a354a64d91eec3e0f8ef0eed575b480fd75b999c ]

Disable guest access to the Trace Filter control registers.
We do not advertise the Trace filter feature to the guest
(ID_AA64DFR0_EL1: TRACE_FILT is cleared) already, but the guest
can still access the TRFCR_EL1 unless we trap it.

This will also make sure that the guest cannot fiddle with
the filtering controls set by a nvhe host.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/20210323120647.454211-3-suzuki.poulose at arm.com
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/include/asm/kvm_arm.h | 1 +
 arch/arm64/kvm/debug.c           | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index f88611e241f0..72ed11292df3 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -191,6 +191,7 @@
 #define CPTR_EL2_DEFAULT	0x000033ff
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
 #define MDCR_EL2_E2PB_SHIFT	(UL(12))
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index dbadfaf850a7..2da4f45ab0bb 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -96,6 +96,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -118,6 +119,7 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
 				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
 				MDCR_EL2_TPMCR |
 				MDCR_EL2_TDRA |
 				MDCR_EL2_TDOSA);
-- 
2.30.2



From sashal at kernel.org  Mon Apr  5 17:05:10 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon,  5 Apr 2021 12:05:10 -0400
Subject: [PATCH AUTOSEL 4.19 3/8] drm/imx: imx-ldb: fix out of bounds array
 access warning
In-Reply-To: <20210405160515.269020-1-sashal@kernel.org>
References: <20210405160515.269020-1-sashal@kernel.org>
Message-ID: <20210405160515.269020-3-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 33ce7f2f95cabb5834cf0906308a5cb6103976da ]

When CONFIG_OF is disabled, building with 'make W=1' produces warnings
about out of bounds array access:

drivers/gpu/drm/imx/imx-ldb.c: In function 'imx_ldb_set_clock.constprop':
drivers/gpu/drm/imx/imx-ldb.c:186:8: error: array subscript -22 is below array bounds of 'struct clk *[4]' [-Werror=array-bounds]

Add an error check before the index is used, which helps with the
warning, as well as any possible other error condition that may be
triggered at runtime.

The warning could be fixed by adding a Kconfig depedency on CONFIG_OF,
but Liu Ying points out that the driver may hit the out-of-bounds
problem at runtime anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Liu Ying <victor.liu at nxp.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/gpu/drm/imx/imx-ldb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 221a8cbc57f9..a4dba034dca4 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -206,6 +206,11 @@ static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 	int dual = ldb->ldb_ctrl & LDB_SPLIT_MODE_EN;
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	drm_panel_prepare(imx_ldb_ch->panel);
 
 	if (dual) {
@@ -264,6 +269,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 	int mux = drm_of_encoder_active_port_id(imx_ldb_ch->child, encoder);
 	u32 bus_format = imx_ldb_ch->bus_format;
 
+	if (mux < 0 || mux >= ARRAY_SIZE(ldb->clk_sel)) {
+		dev_warn(ldb->dev, "%s: invalid mux %d\n", __func__, mux);
+		return;
+	}
+
 	if (mode->clock > 170000) {
 		dev_warn(ldb->dev,
 			 "%s: mode exceeds 170 MHz pixel clock\n", __func__);
-- 
2.30.2



From weifeng.voon at intel.com  Mon Apr  5 17:33:57 2021
From: weifeng.voon at intel.com (Voon Weifeng)
Date: Tue,  6 Apr 2021 00:33:57 +0800
Subject: [PATCH net-next] net: intel: Enable SERDES PHY rx clk for PSE
Message-ID: <20210405163357.30902-1-weifeng.voon@intel.com>

EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
sequence and vice versa.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 10 ++++++++++
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index add95e20548d..a4fec5fe0779 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -153,6 +153,11 @@ static int intel_serdes_powerup(struct net_device *ndev, void *priv_data)
 		return data;
 	}
 
+	/* PSE only - ungate SGMII PHY Rx Clock */
+	if (intel_priv->is_pse)
+		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
+			       0, SERDES_PHY_RX_CLK);
+
 	return 0;
 }
 
@@ -168,6 +173,11 @@ static void intel_serdes_powerdown(struct net_device *ndev, void *intel_data)
 
 	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
 
+	/* PSE only - gate SGMII PHY Rx Clock */
+	if (intel_priv->is_pse)
+		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
+			       SERDES_PHY_RX_CLK, 0);
+
 	/*  move power state to P3 */
 	data = mdiobus_read(priv->mii, serdes_phy_addr, SERDES_GCR0);
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index e723096c0b15..542acb8ce467 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -14,6 +14,7 @@
 
 /* SERDES defines */
 #define SERDES_PLL_CLK		BIT(0)		/* PLL clk valid signal */
+#define SERDES_PHY_RX_CLK	BIT(1)		/* PSE SGMII PHY rx clk */
 #define SERDES_RST		BIT(2)		/* Serdes Reset */
 #define SERDES_PWR_ST_MASK	GENMASK(6, 4)	/* Serdes Power state*/
 #define SERDES_PWR_ST_SHIFT	4
-- 
2.17.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:47 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:47 +0100
Subject: [PATCH v6 00/20] coresight: Add support for ETE and TRBE
Message-ID: <20210405164307.1720226-1-suzuki.poulose@arm.com>

This series enables future IP trace features Embedded Trace Extension
(ETE) and Trace Buffer Extension (TRBE). This series applies on
kvmarm/fixes tree. A standalone tree is also available here [0].
The queued patches (almost there) are included in this posting for
the sake of constructing a tree from the posting.

ETE is the PE (CPU) trace unit for CPUs, implementing future
architecture extensions. ETE overlaps with the ETMv4 architecture, with
additions to support the newer architecture features and some restrictions
on the supported features w.r.t ETMv4. The ETE support is added by extending
the ETMv4 driver to recognise the ETE and handle the features as exposed by
the TRCIDRx registers. ETE only supports system instructions access from the
host CPU. The ETE could be integrated with a TRBE (see below), or with
the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same
firmware description as the ETMs and requires a node per instance. 

Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which
is accessible via the system registers and can be combined with the ETE to
provide a 1x1 configuration of source & sink. TRBE is being represented
here as a CoreSight sink. Primary reason is that the ETE source could
work with other traditional CoreSight sink devices. As TRBE captures the
trace data which is produced by ETE, it cannot work alone.

TRBE representation here have some distinct deviations from a
traditional CoreSight sink device. Coresight path between ETE and TRBE are
not built during boot looking at respective DT or ACPI entries.

Unlike traditional sinks, TRBE can generate interrupts to signal
including many other things, buffer got filled. The interrupt is a PPI and
should be communicated from the platform. DT or ACPI entry representing TRBE
should have the PPI number for a given platform. During perf session, the
TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting
it back. System registers being used here to configure ETE and TRBE could
be referred in the link below.

https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers.

[0] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/ete/v6/

Changes since v6:
 - Rebased to kvmarm/fixes tree (which has some patches queued that this
   series depends on)
 - Fixed a sparse warning in TRBE driver Reported-by: kernel test robot
   <lkp at intel.com>
 - Add explicit undef handler for TRFCR_EL1 (Marc Zyngier)
 - Check for the SPE support early, kvm_arch_vcpu_load(), instead of
   every single time in guest_enter() (Patch 06)

Changes since V4:

https://lkml.kernel.org/r/20210225193543.2920532-1-suzuki.poulose at arm.com

 - Split the documentation patches from the TRBE driver
 - Drop the patches already queued for v5.12.
 - Mark the buffer TRUNCATED in case of a WRAP event
 - Fix error code for vmap failure
 - Fix build break on arm32 for per-cpu sink patch
 - Address comments on ETE dts bindings.
 - Make ete_sysreg_read/write static (kernel test robot)
 - Merged ete sysreg definition patch with ete support, to avoid
   a "defined but unused warning" on build in part of the series.
 - Add new bindings to MAINTAINERS 
 
Changes since V3:

https://lore.kernel.org/linux-arm-kernel/1611737738-1493-1-git-send-email-anshuman.khandual at arm.com/

 - ETE and TRBE changes have been captured in the respective patches
 - Better support for nVHE
 - Re-ordered and splitted the patches to keep the changes separate
   for the generic/arm64 tree from CoreSight driver specific changes.
 - Fixes for KVM handling of Trace/SPE


Changes since V2:

https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-anshuman.khandual at arm.com/

- Rebased on coresight/next
- Changed DT bindings for ETE
- Included additional patches for arm64 nvhe, perf aux buffer flags etc
- TRBE changes have been captured in the respective patches

Changes since V1:

https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-anshuman.khandual at arm.com/

- Converted both ETE and TRBE DT bindings into Yaml
- TRBE changes have been captured in the respective patches
 
Changes since RFC:


- There are not much ETE changes from Suzuki apart from splitting of the
  ETE DTS patch
- TRBE changes have been captured in the respective patches

RFC:

https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-anshuman.khandual at arm.com/

Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Peter Zilstra <peterz at infradead.org>
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Linu Cherian <lcherian at marvell.com>
Cc: coresight at lists.linaro.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org



Anshuman Khandual (5):
  arm64: Add TRBE definitions
  coresight: core: Add support for dedicated percpu sinks
  coresight: sink: Add TRBE driver
  Documentation: coresight: trbe: Sysfs ABI description
  Documentation: trace: Add documentation for TRBE

Suzuki K Poulose (15):
  perf: aux: Add flags for the buffer format
  perf: aux: Add CoreSight PMU buffer formats
  arm64: Add support for trace synchronization barrier
  kvm: arm64: Handle access to TRFCR_EL1
  kvm: arm64: Move SPE availability check to VCPU load
  arm64: kvm: Enable access to TRBE support for host
  coresight: etm4x: Move ETM to prohibited region for disable
  coresight: etm-perf: Allow an event to use different sinks
  coresight: Do not scan for graph if none is present
  coresight: etm4x: Add support for PE OS lock
  coresight: ete: Add support for ETE sysreg access
  coresight: ete: Add support for ETE tracing
  dts: bindings: Document device tree bindings for ETE
  coresight: etm-perf: Handle stale output handles
  dts: bindings: Document device tree bindings for Arm TRBE

 .../testing/sysfs-bus-coresight-devices-trbe  |   14 +
 .../devicetree/bindings/arm/ete.yaml          |   75 ++
 .../devicetree/bindings/arm/trbe.yaml         |   49 +
 .../trace/coresight/coresight-trbe.rst        |   38 +
 MAINTAINERS                                   |    2 +
 arch/arm64/include/asm/barrier.h              |    1 +
 arch/arm64/include/asm/el2_setup.h            |   13 +
 arch/arm64/include/asm/kvm_arm.h              |    2 +
 arch/arm64/include/asm/kvm_host.h             |    8 +
 arch/arm64/include/asm/sysreg.h               |   50 +
 arch/arm64/kernel/hyp-stub.S                  |    3 +-
 arch/arm64/kvm/arm.c                          |    2 +
 arch/arm64/kvm/debug.c                        |   36 +-
 arch/arm64/kvm/hyp/nvhe/debug-sr.c            |   56 +-
 arch/arm64/kvm/hyp/nvhe/switch.c              |    1 +
 arch/arm64/kvm/sys_regs.c                     |    1 +
 drivers/hwtracing/coresight/Kconfig           |   24 +-
 drivers/hwtracing/coresight/Makefile          |    1 +
 drivers/hwtracing/coresight/coresight-core.c  |   29 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |  119 +-
 .../coresight/coresight-etm4x-core.c          |  161 ++-
 .../coresight/coresight-etm4x-sysfs.c         |   19 +-
 drivers/hwtracing/coresight/coresight-etm4x.h |   83 +-
 .../hwtracing/coresight/coresight-platform.c  |    6 +
 drivers/hwtracing/coresight/coresight-priv.h  |    3 +
 drivers/hwtracing/coresight/coresight-trbe.c  | 1157 +++++++++++++++++
 drivers/hwtracing/coresight/coresight-trbe.h  |  152 +++
 include/linux/coresight.h                     |   13 +
 include/uapi/linux/perf_event.h               |   13 +-
 29 files changed, 2054 insertions(+), 77 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
 create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
 create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h

-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:48 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:48 +0100
Subject: [PATCH v6 01/20] perf: aux: Add flags for the buffer format
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-2-suzuki.poulose@arm.com>

Allocate a byte for advertising the PMU specific format type
of the given AUX record. A PMU could end up providing hardware
trace data in multiple format in a single session.

e.g, The format of hardware buffer produced by CoreSight ETM
PMU depends on the type of the "sink" device used for collection
for an event (Traditional TMC-ETR/Bs with formatting or
TRBEs without any formatting).

 # Boring story of why this is needed. Goto The_End_of_Story for skipping.

CoreSight ETM trace allows instruction level tracing of Arm CPUs.
The ETM generates the CPU excecution trace and pumps it into CoreSight
AMBA Trace Bus and is collected by a different CoreSight component
(traditionally CoreSight TMC-ETR /ETB/ETF), called "sink".
Important to note that there is no guarantee that every CPU has
a dedicated sink.  Thus multiple ETMs could pump the trace data
into the same "sink" and thus they apply additional formatting
of the trace data for the user to decode it properly and attribute
the trace data to the corresponding ETM.

However, with the introduction of Arm Trace buffer Extensions (TRBE),
we now have a dedicated per-CPU architected sink for collecting the
trace. Since the TRBE is always per-CPU, it doesn't apply any formatting
of the trace. The support for this driver is under review [1].

Now a system could have a per-cpu TRBE and one or more shared
TMC-ETRs on the system. A user could choose a "specific" sink
for a perf session (e.g, a TMC-ETR) or the driver could automatically
select the nearest sink for a given ETM. It is possible that
some ETMs could end up using TMC-ETR (e.g, if the TRBE is not
usable on the CPU) while the others using TRBE in a single
perf session. Thus we now have "formatted" trace collected
from TMC-ETR and "unformatted" trace collected from TRBE.
However, we don't get into a situation where a single event
could end up using TMC-ETR & TRBE. i.e, any AUX buffer is
guaranteed to be either RAW or FORMATTED, but not a mix
of both.

As for perf decoding, we need to know the type of the data
in the individual AUX buffers, so that it can set up the
"OpenCSD" (library for decoding CoreSight trace) decoder
instance appropriately. Thus the perf.data file must conatin
the hints for the tool to decode the data correctly.

Since this is a runtime variable, and perf tool doesn't have
a control on what sink gets used (in case of automatic sink
selection), we need this information made available from
the PMU driver for each AUX record.

 # The_End_of_Story

Cc: Peter Ziljstra <peterz at infradead.org>
Cc: alexander.shishkin at linux.intel.com
Cc: mingo at redhat.com
Cc: will at kernel.org
Cc: mark.rutland at arm.com
Cc: mike.leach at linaro.org
Cc: acme at kernel.org
Cc: jolsa at redhat.com
Cc: Mathieu Poirier <mathieu.poirer at linaro.org>
Reviewed by: Mike Leach <mike.leach at linaro.org>
Acked-by: Peter Ziljstra <peterz at infradead.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 include/uapi/linux/perf_event.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index ad15e40d7f5d..f006eeab6f0e 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1156,10 +1156,11 @@ enum perf_callchain_context {
 /**
  * PERF_RECORD_AUX::flags bits
  */
-#define PERF_AUX_FLAG_TRUNCATED		0x01	/* record was truncated to fit */
-#define PERF_AUX_FLAG_OVERWRITE		0x02	/* snapshot from overwrite mode */
-#define PERF_AUX_FLAG_PARTIAL		0x04	/* record contains gaps */
-#define PERF_AUX_FLAG_COLLISION		0x08	/* sample collided with another */
+#define PERF_AUX_FLAG_TRUNCATED			0x01	/* record was truncated to fit */
+#define PERF_AUX_FLAG_OVERWRITE			0x02	/* snapshot from overwrite mode */
+#define PERF_AUX_FLAG_PARTIAL			0x04	/* record contains gaps */
+#define PERF_AUX_FLAG_COLLISION			0x08	/* sample collided with another */
+#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK	0xff00	/* PMU specific trace format type */
 
 #define PERF_FLAG_FD_NO_GROUP		(1UL << 0)
 #define PERF_FLAG_FD_OUTPUT		(1UL << 1)
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:49 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:49 +0100
Subject: [PATCH v6 02/20] perf: aux: Add CoreSight PMU buffer formats
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-3-suzuki.poulose@arm.com>

CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).

The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ETMs, with the TraceID to indicate
the source of a given trace packet.

Arm Trace Buffer Extension is new "sink" IP, attached to individual
CPUs and thus do not provide additional formatting, like TMC-ETR.

Additionally, a system could have both TRBE *and* TMC-ETR for
the trace collection. e.g, TMC-ETR could be used as a single
trace buffer to collect data from multiple ETMs to correlate
the traces from different CPUs. It is possible to have a
perf session where some events end up collecting the trace
in TMC-ETR while the others in TRBE. Thus we need a way
to identify the type of the trace for each AUX record.

Define the trace formats exported by the CoreSight PMU.
We don't define the flags following the "ETM" as this
information is available to the user when issuing
the session. What is missing is the additional
formatting applied by the "sink" which is decided
at the runtime and the user may not have a control on.

So we define :
 - CORESIGHT format (indicates the Frame format)
 - RAW format (indicates the format of the source)

The default value is CORESIGHT format for all the records
(i,e == 0). Add the RAW format for others that use
raw format.

Cc: Peter Zijlstra <peterz at infradead.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 include/uapi/linux/perf_event.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index f006eeab6f0e..63971eaef127 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1162,6 +1162,10 @@ enum perf_callchain_context {
 #define PERF_AUX_FLAG_COLLISION			0x08	/* sample collided with another */
 #define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK	0xff00	/* PMU specific trace format type */
 
+/* CoreSight PMU AUX buffer formats */
+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT	0x0000 /* Default for backward compatibility */
+#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW		0x0100 /* Raw format of the source */
+
 #define PERF_FLAG_FD_NO_GROUP		(1UL << 0)
 #define PERF_FLAG_FD_OUTPUT		(1UL << 1)
 #define PERF_FLAG_PID_CGROUP		(1UL << 2) /* pid=cgroup id, per-cpu mode only */
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:50 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:50 +0100
Subject: [PATCH v6 03/20] arm64: Add support for trace synchronization barrier
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-4-suzuki.poulose@arm.com>

tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/barrier.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index c3009b0e5239..5a8367a2b868 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -23,6 +23,7 @@
 #define dsb(opt)	asm volatile("dsb " #opt : : : "memory")
 
 #define psb_csync()	asm volatile("hint #17" : : : "memory")
+#define tsb_csync()	asm volatile("hint #18" : : : "memory")
 #define csdb()		asm volatile("hint #20" : : : "memory")
 
 #define spec_bar()	asm volatile(ALTERNATIVE("dsb nsh\nisb\n",		\
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:51 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:51 +0100
Subject: [PATCH v6 04/20] arm64: Add TRBE definitions
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-5-suzuki.poulose@arm.com>

From: Anshuman Khandual <anshuman.khandual at arm.com>

This adds TRBE related registers and corresponding feature macros.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/sysreg.h | 50 +++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..a27ba8be46a2 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -333,6 +333,55 @@
 
 /*** End of Statistical Profiling Extension ***/
 
+/*
+ * TRBE Registers
+ */
+#define SYS_TRBLIMITR_EL1		sys_reg(3, 0, 9, 11, 0)
+#define SYS_TRBPTR_EL1			sys_reg(3, 0, 9, 11, 1)
+#define SYS_TRBBASER_EL1		sys_reg(3, 0, 9, 11, 2)
+#define SYS_TRBSR_EL1			sys_reg(3, 0, 9, 11, 3)
+#define SYS_TRBMAR_EL1			sys_reg(3, 0, 9, 11, 4)
+#define SYS_TRBTRG_EL1			sys_reg(3, 0, 9, 11, 6)
+#define SYS_TRBIDR_EL1			sys_reg(3, 0, 9, 11, 7)
+
+#define TRBLIMITR_LIMIT_MASK		GENMASK_ULL(51, 0)
+#define TRBLIMITR_LIMIT_SHIFT		12
+#define TRBLIMITR_NVM			BIT(5)
+#define TRBLIMITR_TRIG_MODE_MASK	GENMASK(1, 0)
+#define TRBLIMITR_TRIG_MODE_SHIFT	3
+#define TRBLIMITR_FILL_MODE_MASK	GENMASK(1, 0)
+#define TRBLIMITR_FILL_MODE_SHIFT	1
+#define TRBLIMITR_ENABLE		BIT(0)
+#define TRBPTR_PTR_MASK			GENMASK_ULL(63, 0)
+#define TRBPTR_PTR_SHIFT		0
+#define TRBBASER_BASE_MASK		GENMASK_ULL(51, 0)
+#define TRBBASER_BASE_SHIFT		12
+#define TRBSR_EC_MASK			GENMASK(5, 0)
+#define TRBSR_EC_SHIFT			26
+#define TRBSR_IRQ			BIT(22)
+#define TRBSR_TRG			BIT(21)
+#define TRBSR_WRAP			BIT(20)
+#define TRBSR_ABORT			BIT(18)
+#define TRBSR_STOP			BIT(17)
+#define TRBSR_MSS_MASK			GENMASK(15, 0)
+#define TRBSR_MSS_SHIFT			0
+#define TRBSR_BSC_MASK			GENMASK(5, 0)
+#define TRBSR_BSC_SHIFT			0
+#define TRBSR_FSC_MASK			GENMASK(5, 0)
+#define TRBSR_FSC_SHIFT			0
+#define TRBMAR_SHARE_MASK		GENMASK(1, 0)
+#define TRBMAR_SHARE_SHIFT		8
+#define TRBMAR_OUTER_MASK		GENMASK(3, 0)
+#define TRBMAR_OUTER_SHIFT		4
+#define TRBMAR_INNER_MASK		GENMASK(3, 0)
+#define TRBMAR_INNER_SHIFT		0
+#define TRBTRG_TRG_MASK			GENMASK(31, 0)
+#define TRBTRG_TRG_SHIFT		0
+#define TRBIDR_FLAG			BIT(5)
+#define TRBIDR_PROG			BIT(4)
+#define TRBIDR_ALIGN_MASK		GENMASK(3, 0)
+#define TRBIDR_ALIGN_SHIFT		0
+
 #define SYS_PMINTENSET_EL1		sys_reg(3, 0, 9, 14, 1)
 #define SYS_PMINTENCLR_EL1		sys_reg(3, 0, 9, 14, 2)
 
@@ -840,6 +889,7 @@
 #define ID_AA64MMFR2_CNP_SHIFT		0
 
 /* id_aa64dfr0 */
+#define ID_AA64DFR0_TRBE_SHIFT		44
 #define ID_AA64DFR0_TRACE_FILT_SHIFT	40
 #define ID_AA64DFR0_DOUBLELOCK_SHIFT	36
 #define ID_AA64DFR0_PMSVER_SHIFT	32
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:52 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:52 +0100
Subject: [PATCH v6 05/20] kvm: arm64: Handle access to TRFCR_EL1
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-6-suzuki.poulose@arm.com>

Rather than falling to an "unhandled access", inject add an explicit
"undefined access" for TRFCR_EL1 access from the guest.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kvm/sys_regs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4f2f1e3145de..52fdb9a015a4 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1472,6 +1472,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_GCR_EL1), undef_access },
 
 	{ SYS_DESC(SYS_ZCR_EL1), NULL, reset_val, ZCR_EL1, 0, .visibility = sve_visibility },
+	{ SYS_DESC(SYS_TRFCR_EL1), undef_access },
 	{ 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 },
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:53 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:53 +0100
Subject: [PATCH v6 06/20] kvm: arm64: Move SPE availability check to VCPU load
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-7-suzuki.poulose@arm.com>

At the moment, we check the availability of SPE on the given
CPU (i.e, SPE is implemented and is allowed at the host) during
every guest entry. This can be optimized a bit by moving the
check to vcpu_load time and recording the availability of the
feature on the current CPU via a new flag. This will also be useful
for adding the TRBE support.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Alexandru Elisei <Alexandru.Elisei at arm.com>
Cc: James Morse <james.morse at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/kvm_host.h  |  5 +++++
 arch/arm64/kvm/arm.c               |  2 ++
 arch/arm64/kvm/debug.c             | 23 +++++++++++++++++++++++
 arch/arm64/kvm/hyp/nvhe/debug-sr.c | 22 +++++++++-------------
 4 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527f7d..acc2b45dd433 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -400,6 +400,7 @@ struct kvm_vcpu_arch {
 #define KVM_ARM64_GUEST_HAS_PTRAUTH	(1 << 7) /* PTRAUTH exposed to guest */
 #define KVM_ARM64_PENDING_EXCEPTION	(1 << 8) /* Exception pending */
 #define KVM_ARM64_EXCEPT_MASK		(7 << 9) /* Target EL/MODE */
+#define KVM_ARM64_DEBUG_STATE_SAVE_SPE	(1 << 12) /* Save SPE context if active  */
 
 /*
  * When KVM_ARM64_PENDING_EXCEPTION is set, KVM_ARM64_EXCEPT_MASK can
@@ -734,6 +735,10 @@ static inline bool kvm_pmu_counter_deferred(struct perf_event_attr *attr)
 	return (!has_vhe() && attr->exclude_host);
 }
 
+/* Flags for host debug state */
+void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
+
 #ifdef CONFIG_KVM /* Avoid conflicts with core headers if CONFIG_KVM=n */
 static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7f06ba76698d..954752208509 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -416,10 +416,12 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 
 	if (vcpu_has_ptrauth(vcpu))
 		vcpu_ptrauth_disable(vcpu);
+	kvm_arch_vcpu_load_debug_state_flags(vcpu);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 {
+	kvm_arch_vcpu_put_debug_state_flags(vcpu);
 	kvm_arch_vcpu_put_fp(vcpu);
 	if (has_vhe())
 		kvm_vcpu_put_sysregs_vhe(vcpu);
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index dbc890511631..b6d2c33ad1df 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -231,3 +231,26 @@ void kvm_arm_clear_debug(struct kvm_vcpu *vcpu)
 		}
 	}
 }
+
+void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
+{
+	u64 dfr0;
+
+	/* For VHE, there is nothing to do */
+	if (has_vhe())
+		return;
+
+	dfr0 = read_sysreg(id_aa64dfr0_el1);
+	/*
+	 * If SPE is present on this CPU and is available at current EL,
+	 * we may need to check if the host state needs to be saved.
+	 */
+	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_PMSVER_SHIFT) &&
+	    !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(SYS_PMBIDR_EL1_P_SHIFT)))
+		vcpu->arch.flags |= KVM_ARM64_DEBUG_STATE_SAVE_SPE;
+}
+
+void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.flags &= ~KVM_ARM64_DEBUG_STATE_SAVE_SPE;
+}
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index f401724f12ef..e6ee9b7faec6 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -21,17 +21,11 @@ static void __debug_save_spe(u64 *pmscr_el1)
 	/* Clear pmscr in case of early return */
 	*pmscr_el1 = 0;
 
-	/* SPE present on this CPU? */
-	if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
-						  ID_AA64DFR0_PMSVER_SHIFT))
-		return;
-
-	/* Yes; is it owned by EL3? */
-	reg = read_sysreg_s(SYS_PMBIDR_EL1);
-	if (reg & BIT(SYS_PMBIDR_EL1_P_SHIFT))
-		return;
-
-	/* No; is the host actually using the thing? */
+	/*
+	 * At this point, we know that this CPU implements
+	 * SPE and is available to the host.
+	 * Check if the host is actually using it ?
+	 */
 	reg = read_sysreg_s(SYS_PMBLIMITR_EL1);
 	if (!(reg & BIT(SYS_PMBLIMITR_EL1_E_SHIFT)))
 		return;
@@ -61,7 +55,8 @@ static void __debug_restore_spe(u64 pmscr_el1)
 void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
 {
 	/* Disable and flush SPE data generation */
-	__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);
+	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
+		__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);
 }
 
 void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
@@ -71,7 +66,8 @@ void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
 
 void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
 {
-	__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
+	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
+		__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
 }
 
 void __debug_switch_to_host(struct kvm_vcpu *vcpu)
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:54 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:54 +0100
Subject: [PATCH v6 07/20] arm64: kvm: Enable access to TRBE support for host
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-8-suzuki.poulose@arm.com>

For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while we are in EL1 by clearing the TRFCR_EL1.

For vhe, the EL2 must prevent the EL1 access to the Trace
Buffer.

The MDCR_EL2 bit definitions for TRBE are available here :

  https://developer.arm.com/documentation/ddi0601/2020-12/AArch64-Registers/

Cc: Will Deacon <will at kernel.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Acked-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/el2_setup.h | 13 ++++++++++++
 arch/arm64/include/asm/kvm_arm.h   |  2 ++
 arch/arm64/include/asm/kvm_host.h  |  3 +++
 arch/arm64/kernel/hyp-stub.S       |  3 ++-
 arch/arm64/kvm/debug.c             | 14 ++++++++----
 arch/arm64/kvm/hyp/nvhe/debug-sr.c | 34 ++++++++++++++++++++++++++++++
 arch/arm64/kvm/hyp/nvhe/switch.c   |  1 +
 7 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
index d77d358f9395..bda918948471 100644
--- a/arch/arm64/include/asm/el2_setup.h
+++ b/arch/arm64/include/asm/el2_setup.h
@@ -65,6 +65,19 @@
 						// use EL1&0 translation.
 
 .Lskip_spe_\@:
+	/* Trace buffer */
+	ubfx	x0, x1, #ID_AA64DFR0_TRBE_SHIFT, #4
+	cbz	x0, .Lskip_trace_\@		// Skip if TraceBuffer is not present
+
+	mrs_s	x0, SYS_TRBIDR_EL1
+	and	x0, x0, TRBIDR_PROG
+	cbnz	x0, .Lskip_trace_\@		// If TRBE is available at EL2
+
+	mov	x0, #(MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT)
+	orr	x2, x2, x0			// allow the EL1&0 translation
+						// to own it.
+
+.Lskip_trace_\@:
 	msr	mdcr_el2, x2			// Configure debug traps
 .endm
 
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 94d4025acc0b..692c9049befa 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -278,6 +278,8 @@
 #define CPTR_EL2_DEFAULT	CPTR_EL2_RES1
 
 /* Hyp Debug Configuration Register bits */
+#define MDCR_EL2_E2TB_MASK	(UL(0x3))
+#define MDCR_EL2_E2TB_SHIFT	(UL(24))
 #define MDCR_EL2_TTRF		(1 << 19)
 #define MDCR_EL2_TPMS		(1 << 14)
 #define MDCR_EL2_E2PB_MASK	(UL(0x3))
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index acc2b45dd433..a61282eb11bc 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -315,6 +315,8 @@ struct kvm_vcpu_arch {
 		struct kvm_guest_debug_arch regs;
 		/* Statistical profiling extension */
 		u64 pmscr_el1;
+		/* Self-hosted trace */
+		u64 trfcr_el1;
 	} host_debug_state;
 
 	/* VGIC state */
@@ -401,6 +403,7 @@ struct kvm_vcpu_arch {
 #define KVM_ARM64_PENDING_EXCEPTION	(1 << 8) /* Exception pending */
 #define KVM_ARM64_EXCEPT_MASK		(7 << 9) /* Target EL/MODE */
 #define KVM_ARM64_DEBUG_STATE_SAVE_SPE	(1 << 12) /* Save SPE context if active  */
+#define KVM_ARM64_DEBUG_STATE_SAVE_TRBE	(1 << 13) /* Save TRBE context if active  */
 
 /*
  * When KVM_ARM64_PENDING_EXCEPTION is set, KVM_ARM64_EXCEPT_MASK can
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 5eccbd62fec8..05d25e645b46 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -115,9 +115,10 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
 	mrs_s	x0, SYS_VBAR_EL12
 	msr	vbar_el1, x0
 
-	// Use EL2 translations for SPE and disable access from EL1
+	// Use EL2 translations for SPE & TRBE and disable access from EL1
 	mrs	x0, mdcr_el2
 	bic	x0, x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
+	bic	x0, x0, #(MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT)
 	msr	mdcr_el2, x0
 
 	// Transfer the MM state from EL1 to EL2
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index b6d2c33ad1df..6f992c696911 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -89,7 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  *  - Debug ROM Address (MDCR_EL2_TDRA)
  *  - OS related registers (MDCR_EL2_TDOSA)
  *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
- *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
+ *  - Self-hosted Trace (MDCR_EL2_TTRF/MDCR_EL2_E2TB)
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -107,8 +107,8 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug);
 
 	/*
-	 * This also clears MDCR_EL2_E2PB_MASK to disable guest access
-	 * to the profiling buffer.
+	 * This also clears MDCR_EL2_E2PB_MASK and MDCR_EL2_E2TB_MASK
+	 * to disable guest access to the profiling and trace buffers
 	 */
 	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
 	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
@@ -248,9 +248,15 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
 	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_PMSVER_SHIFT) &&
 	    !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(SYS_PMBIDR_EL1_P_SHIFT)))
 		vcpu->arch.flags |= KVM_ARM64_DEBUG_STATE_SAVE_SPE;
+
+	/* Check if we have TRBE implemented and available at the host */
+	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_TRBE_SHIFT) &&
+	    !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_PROG))
+		vcpu->arch.flags |= KVM_ARM64_DEBUG_STATE_SAVE_TRBE;
 }
 
 void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
 {
-	vcpu->arch.flags &= ~KVM_ARM64_DEBUG_STATE_SAVE_SPE;
+	vcpu->arch.flags &= ~(KVM_ARM64_DEBUG_STATE_SAVE_SPE |
+			      KVM_ARM64_DEBUG_STATE_SAVE_TRBE);
 }
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index e6ee9b7faec6..7d3f25868cae 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -52,11 +52,43 @@ static void __debug_restore_spe(u64 pmscr_el1)
 	write_sysreg_s(pmscr_el1, SYS_PMSCR_EL1);
 }
 
+static void __debug_save_trace(u64 *trfcr_el1)
+{
+	*trfcr_el1 = 0;
+
+	/* Check if the TRBE is enabled */
+	if (!(read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_ENABLE))
+		return;
+	/*
+	 * Prohibit trace generation while we are in guest.
+	 * Since access to TRFCR_EL1 is trapped, the guest can't
+	 * modify the filtering set by the host.
+	 */
+	*trfcr_el1 = read_sysreg_s(SYS_TRFCR_EL1);
+	write_sysreg_s(0, SYS_TRFCR_EL1);
+	isb();
+	/* Drain the trace buffer to memory */
+	tsb_csync();
+	dsb(nsh);
+}
+
+static void __debug_restore_trace(u64 trfcr_el1)
+{
+	if (!trfcr_el1)
+		return;
+
+	/* Restore trace filter controls */
+	write_sysreg_s(trfcr_el1, SYS_TRFCR_EL1);
+}
+
 void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
 {
 	/* Disable and flush SPE data generation */
 	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
 		__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);
+	/* Disable and flush Self-Hosted Trace generation */
+	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_TRBE)
+		__debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1);
 }
 
 void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
@@ -68,6 +100,8 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
 {
 	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
 		__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
+	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_TRBE)
+		__debug_restore_trace(vcpu->arch.host_debug_state.trfcr_el1);
 }
 
 void __debug_switch_to_host(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 68ab6b4d5141..736805232521 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -95,6 +95,7 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu)
 
 	mdcr_el2 &= MDCR_EL2_HPMN_MASK;
 	mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
+	mdcr_el2 |= MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT;
 
 	write_sysreg(mdcr_el2, mdcr_el2);
 	if (is_protected_kvm_enabled())
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:55 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:55 +0100
Subject: [PATCH v6 08/20] coresight: etm4x: Move ETM to prohibited region for
 disable
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-9-suzuki.poulose@arm.com>

If the CPU implements Arm v8.4 Trace filter controls (FEAT_TRF),
move the ETM to trace prohibited region using TRFCR, while disabling.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../coresight/coresight-etm4x-core.c          | 21 +++++++++++++++++--
 drivers/hwtracing/coresight/coresight-etm4x.h |  2 ++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 15016f757828..00297906669c 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -31,6 +31,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/property.h>
 
+#include <asm/barrier.h>
 #include <asm/sections.h>
 #include <asm/sysreg.h>
 #include <asm/local.h>
@@ -654,6 +655,7 @@ static int etm4_enable(struct coresight_device *csdev,
 static void etm4_disable_hw(void *info)
 {
 	u32 control;
+	u64 trfcr;
 	struct etmv4_drvdata *drvdata = info;
 	struct etmv4_config *config = &drvdata->config;
 	struct coresight_device *csdev = drvdata->csdev;
@@ -676,6 +678,16 @@ static void etm4_disable_hw(void *info)
 	/* EN, bit[0] Trace unit enable bit */
 	control &= ~0x1;
 
+	/*
+	 * If the CPU supports v8.4 Trace filter Control,
+	 * set the ETM to trace prohibited region.
+	 */
+	if (drvdata->trfc) {
+		trfcr = read_sysreg_s(SYS_TRFCR_EL1);
+		write_sysreg_s(trfcr & ~(TRFCR_ELx_ExTRE | TRFCR_ELx_E0TRE),
+			       SYS_TRFCR_EL1);
+		isb();
+	}
 	/*
 	 * Make sure everything completes before disabling, as recommended
 	 * by section 7.3.77 ("TRCVICTLR, ViewInst Main Control Register,
@@ -683,12 +695,16 @@ static void etm4_disable_hw(void *info)
 	 */
 	dsb(sy);
 	isb();
+	/* Trace synchronization barrier, is a nop if not supported */
+	tsb_csync();
 	etm4x_relaxed_write32(csa, control, TRCPRGCTLR);
 
 	/* wait for TRCSTATR.PMSTABLE to go to '1' */
 	if (coresight_timeout(csa, TRCSTATR, TRCSTATR_PMSTABLE_BIT, 1))
 		dev_err(etm_dev,
 			"timeout while waiting for PM stable Trace Status\n");
+	if (drvdata->trfc)
+		write_sysreg_s(trfcr, SYS_TRFCR_EL1);
 
 	/* read the status of the single shot comparators */
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
@@ -873,7 +889,7 @@ static bool etm4_init_csdev_access(struct etmv4_drvdata *drvdata,
 	return false;
 }
 
-static void cpu_enable_tracing(void)
+static void cpu_enable_tracing(struct etmv4_drvdata *drvdata)
 {
 	u64 dfr0 = read_sysreg(id_aa64dfr0_el1);
 	u64 trfcr;
@@ -881,6 +897,7 @@ static void cpu_enable_tracing(void)
 	if (!cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_TRACE_FILT_SHIFT))
 		return;
 
+	drvdata->trfc = true;
 	/*
 	 * If the CPU supports v8.4 SelfHosted Tracing, enable
 	 * tracing at the kernel EL and EL0, forcing to use the
@@ -1082,7 +1099,7 @@ static void etm4_init_arch_data(void *info)
 	/* NUMCNTR, bits[30:28] number of counters available for tracing */
 	drvdata->nr_cntr = BMVAL(etmidr5, 28, 30);
 	etm4_cs_lock(drvdata, csa);
-	cpu_enable_tracing();
+	cpu_enable_tracing(drvdata);
 }
 
 static inline u32 etm4_get_victlr_access_type(struct etmv4_config *config)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 0af60571aa23..f6478ef642bf 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -862,6 +862,7 @@ struct etmv4_save_state {
  * @nooverflow:	Indicate if overflow prevention is supported.
  * @atbtrig:	If the implementation can support ATB triggers
  * @lpoverride:	If the implementation can support low-power state over.
+ * @trfc:	If the implementation supports Arm v8.4 trace filter controls.
  * @config:	structure holding configuration parameters.
  * @save_state:	State to be preserved across power loss
  * @state_needs_restore: True when there is context to restore after PM exit
@@ -912,6 +913,7 @@ struct etmv4_drvdata {
 	bool				nooverflow;
 	bool				atbtrig;
 	bool				lpoverride;
+	bool				trfc;
 	struct etmv4_config		config;
 	struct etmv4_save_state		*save_state;
 	bool				state_needs_restore;
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:56 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:56 +0100
Subject: [PATCH v6 09/20] coresight: etm-perf: Allow an event to use different
 sinks
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-10-suzuki.poulose@arm.com>

When a sink is not specified by the user, the etm perf driver
finds a suitable sink automatically, based on the first ETM
where this event could be scheduled. Then we allocate the
sink buffer based on the selected sink. This is fine for a
CPU bound event as the "sink" is always guaranteed to be
reachable from the ETM (as this is the only ETM where the
event is going to be scheduled). However, if we have a thread
bound event, the event could be scheduled on any of the ETMs
on the system. In this case, currently we automatically select
a sink and exclude any ETMs that cannot reach the selected
sink. This is problematic especially for 1x1 configurations.
We end up in tracing the event only on the "first" ETM,
as the default sink is local to the first ETM and unreachable
from the rest. However, we could allow the other ETMs to
trace if they all have a sink that is compatible with the
"selected" sink and can use the sink buffer. This can be
easily done by verifying that they are all driven by the
same driver and matches the same subtype. Please note
that at anytime there can be only one ETM tracing the event.

Adding support for different types of sinks for a single
event is complex and is not something that we expect
on a sane configuration.

Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Tested-by: Linu Cherian <lcherian at marvell.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../hwtracing/coresight/coresight-etm-perf.c  | 60 ++++++++++++++++---
 1 file changed, 52 insertions(+), 8 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 0f603b4094f2..aa0974bd265b 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -232,6 +232,25 @@ static void etm_free_aux(void *data)
 	schedule_work(&event_data->work);
 }
 
+/*
+ * Check if two given sinks are compatible with each other,
+ * so that they can use the same sink buffers, when an event
+ * moves around.
+ */
+static bool sinks_compatible(struct coresight_device *a,
+			     struct coresight_device *b)
+{
+	if (!a || !b)
+		return false;
+	/*
+	 * If the sinks are of the same subtype and driven
+	 * by the same driver, we can use the same buffer
+	 * on these sinks.
+	 */
+	return (a->subtype.sink_subtype == b->subtype.sink_subtype) &&
+	       (sink_ops(a) == sink_ops(b));
+}
+
 static void *etm_setup_aux(struct perf_event *event, void **pages,
 			   int nr_pages, bool overwrite)
 {
@@ -239,6 +258,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	int cpu = event->cpu;
 	cpumask_t *mask;
 	struct coresight_device *sink = NULL;
+	struct coresight_device *user_sink = NULL, *last_sink = NULL;
 	struct etm_event_data *event_data = NULL;
 
 	event_data = alloc_event_data(cpu);
@@ -249,7 +269,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	/* First get the selected sink from user space. */
 	if (event->attr.config2) {
 		id = (u32)event->attr.config2;
-		sink = coresight_get_sink_by_id(id);
+		sink = user_sink = coresight_get_sink_by_id(id);
 	}
 
 	mask = &event_data->mask;
@@ -277,14 +297,33 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 		}
 
 		/*
-		 * No sink provided - look for a default sink for one of the
-		 * devices. At present we only support topology where all CPUs
-		 * use the same sink [N:1], so only need to find one sink. The
-		 * coresight_build_path later will remove any CPU that does not
-		 * attach to the sink, or if we have not found a sink.
+		 * No sink provided - look for a default sink for all the ETMs,
+		 * where this event can be scheduled.
+		 * We allocate the sink specific buffers only once for this
+		 * event. If the ETMs have different default sink devices, we
+		 * can only use a single "type" of sink as the event can carry
+		 * only one sink specific buffer. Thus we have to make sure
+		 * that the sinks are of the same type and driven by the same
+		 * driver, as the one we allocate the buffer for. As such
+		 * we choose the first sink and check if the remaining ETMs
+		 * have a compatible default sink. We don't trace on a CPU
+		 * if the sink is not compatible.
 		 */
-		if (!sink)
+		if (!user_sink) {
+			/* Find the default sink for this ETM */
 			sink = coresight_find_default_sink(csdev);
+			if (!sink) {
+				cpumask_clear_cpu(cpu, mask);
+				continue;
+			}
+
+			/* Check if this sink compatible with the last sink */
+			if (last_sink && !sinks_compatible(last_sink, sink)) {
+				cpumask_clear_cpu(cpu, mask);
+				continue;
+			}
+			last_sink = sink;
+		}
 
 		/*
 		 * Building a path doesn't enable it, it simply builds a
@@ -312,7 +351,12 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	if (!sink_ops(sink)->alloc_buffer || !sink_ops(sink)->free_buffer)
 		goto err;
 
-	/* Allocate the sink buffer for this session */
+	/*
+	 * Allocate the sink buffer for this session. All the sinks
+	 * where this event can be scheduled are ensured to be of the
+	 * same type. Thus the same sink configuration is used by the
+	 * sinks.
+	 */
 	event_data->snk_config =
 			sink_ops(sink)->alloc_buffer(sink, event, pages,
 						     nr_pages, overwrite);
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:57 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:57 +0100
Subject: [PATCH v6 10/20] coresight: Do not scan for graph if none is present
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-11-suzuki.poulose@arm.com>

If a graph node is not found for a given node, of_get_next_endpoint()
will emit the following error message :

 OF: graph: no port node found in /<node_name>

If the given component doesn't have any explicit connections (e.g,
ETE) we could simply ignore the graph parsing. As for any legacy
component where this is mandatory, the device will not be usable
as before this patch. Updating the DT bindings to Yaml and enabling
the schema checks can detect such issues with the DT.

Cc: Mike Leach <mike.leach at linaro.org>
Cc: Leo Yan <leo.yan at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/coresight-platform.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
index 3629b7885aca..c594f45319fc 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -90,6 +90,12 @@ static void of_coresight_get_ports_legacy(const struct device_node *node,
 	struct of_endpoint endpoint;
 	int in = 0, out = 0;
 
+	/*
+	 * Avoid warnings in of_graph_get_next_endpoint()
+	 * if the device doesn't have any graph connections
+	 */
+	if (!of_graph_is_present(node))
+		return;
 	do {
 		ep = of_graph_get_next_endpoint(node, ep);
 		if (!ep)
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:58 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:58 +0100
Subject: [PATCH v6 11/20] coresight: etm4x: Add support for PE OS lock
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-12-suzuki.poulose@arm.com>

ETE may not implement the OS lock and instead could rely on
the PE OS Lock for the trace unit access. This is indicated
by the TRCOLSR.OSM == 0b100. Add support for handling the
PE OS lock

Cc: Mike Leach <mike.leach at linaro.org>
Reviewed-by: mike.leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../coresight/coresight-etm4x-core.c          | 50 +++++++++++++++----
 drivers/hwtracing/coresight/coresight-etm4x.h | 15 ++++++
 2 files changed, 56 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 00297906669c..35802caca32a 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -115,30 +115,59 @@ void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)
 	}
 }
 
-static void etm4_os_unlock_csa(struct etmv4_drvdata *drvdata, struct csdev_access *csa)
+static void etm_detect_os_lock(struct etmv4_drvdata *drvdata,
+			       struct csdev_access *csa)
 {
-	/* Writing 0 to TRCOSLAR unlocks the trace registers */
-	etm4x_relaxed_write32(csa, 0x0, TRCOSLAR);
-	drvdata->os_unlock = true;
+	u32 oslsr = etm4x_relaxed_read32(csa, TRCOSLSR);
+
+	drvdata->os_lock_model = ETM_OSLSR_OSLM(oslsr);
+}
+
+static void etm_write_os_lock(struct etmv4_drvdata *drvdata,
+			      struct csdev_access *csa, u32 val)
+{
+	val = !!val;
+
+	switch (drvdata->os_lock_model) {
+	case ETM_OSLOCK_PRESENT:
+		etm4x_relaxed_write32(csa, val, TRCOSLAR);
+		break;
+	case ETM_OSLOCK_PE:
+		write_sysreg_s(val, SYS_OSLAR_EL1);
+		break;
+	default:
+		pr_warn_once("CPU%d: Unsupported Trace OSLock model: %x\n",
+			     smp_processor_id(), drvdata->os_lock_model);
+		fallthrough;
+	case ETM_OSLOCK_NI:
+		return;
+	}
 	isb();
 }
 
+static inline void etm4_os_unlock_csa(struct etmv4_drvdata *drvdata,
+				      struct csdev_access *csa)
+{
+	WARN_ON(drvdata->cpu != smp_processor_id());
+
+	/* Writing 0 to OS Lock unlocks the trace unit registers */
+	etm_write_os_lock(drvdata, csa, 0x0);
+	drvdata->os_unlock = true;
+}
+
 static void etm4_os_unlock(struct etmv4_drvdata *drvdata)
 {
 	if (!WARN_ON(!drvdata->csdev))
 		etm4_os_unlock_csa(drvdata, &drvdata->csdev->access);
-
 }
 
 static void etm4_os_lock(struct etmv4_drvdata *drvdata)
 {
 	if (WARN_ON(!drvdata->csdev))
 		return;
-
-	/* Writing 0x1 to TRCOSLAR locks the trace registers */
-	etm4x_relaxed_write32(&drvdata->csdev->access, 0x1, TRCOSLAR);
+	/* Writing 0x1 to OS Lock locks the trace registers */
+	etm_write_os_lock(drvdata, &drvdata->csdev->access, 0x1);
 	drvdata->os_unlock = false;
-	isb();
 }
 
 static void etm4_cs_lock(struct etmv4_drvdata *drvdata,
@@ -937,6 +966,9 @@ static void etm4_init_arch_data(void *info)
 	if (!etm4_init_csdev_access(drvdata, csa))
 		return;
 
+	/* Detect the support for OS Lock before we actually use it */
+	etm_detect_os_lock(drvdata, csa);
+
 	/* Make sure all registers are accessible */
 	etm4_os_unlock_csa(drvdata, csa);
 	etm4_cs_unlock(drvdata, csa);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index f6478ef642bf..5b961c5b78d1 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -505,6 +505,20 @@
 					 ETM_MODE_EXCL_KERN | \
 					 ETM_MODE_EXCL_USER)
 
+/*
+ * TRCOSLSR.OSLM advertises the OS Lock model.
+ * OSLM[2:0] = TRCOSLSR[4:3,0]
+ *
+ *	0b000 - Trace OS Lock is not implemented.
+ *	0b010 - Trace OS Lock is implemented.
+ *	0b100 - Trace OS Lock is not implemented, unit is controlled by PE OS Lock.
+ */
+#define ETM_OSLOCK_NI		0b000
+#define ETM_OSLOCK_PRESENT	0b010
+#define ETM_OSLOCK_PE		0b100
+
+#define ETM_OSLSR_OSLM(oslsr)	((((oslsr) & GENMASK(4, 3)) >> 2) | (oslsr & 0x1))
+
 /*
  * TRCDEVARCH Bit field definitions
  * Bits[31:21]	- ARCHITECT = Always Arm Ltd.
@@ -898,6 +912,7 @@ struct etmv4_drvdata {
 	u8				s_ex_level;
 	u8				ns_ex_level;
 	u8				q_support;
+	u8				os_lock_model;
 	bool				sticky_enable;
 	bool				boot_enable;
 	bool				os_unlock;
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:42:59 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:42:59 +0100
Subject: [PATCH v6 12/20] coresight: ete: Add support for ETE sysreg access
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-13-suzuki.poulose@arm.com>

Add support for handling the system registers for Embedded Trace
Extensions (ETE). ETE shares most of the registers with ETMv4 except
for some and also adds some new registers. Re-arrange the ETMv4x list
to share the common definitions and add the ETE sysreg support.

Cc: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../coresight/coresight-etm4x-core.c          | 32 +++++++++++
 drivers/hwtracing/coresight/coresight-etm4x.h | 54 +++++++++++++++----
 2 files changed, 77 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 35802caca32a..3e400fd2e404 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -115,6 +115,38 @@ void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)
 	}
 }
 
+static u64 ete_sysreg_read(u32 offset, bool _relaxed, bool _64bit)
+{
+	u64 res = 0;
+
+	switch (offset) {
+	ETE_READ_CASES(res)
+	default :
+		pr_warn_ratelimited("ete: trying to read unsupported register @%x\n",
+				    offset);
+	}
+
+	if (!_relaxed)
+		__iormb(res);	/* Imitate the !relaxed I/O helpers */
+
+	return res;
+}
+
+static void ete_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit)
+{
+	if (!_relaxed)
+		__iowmb();	/* Imitate the !relaxed I/O helpers */
+	if (!_64bit)
+		val &= GENMASK(31, 0);
+
+	switch (offset) {
+	ETE_WRITE_CASES(val)
+	default :
+		pr_warn_ratelimited("ete: trying to write to unsupported register @%x\n",
+				    offset);
+	}
+}
+
 static void etm_detect_os_lock(struct etmv4_drvdata *drvdata,
 			       struct csdev_access *csa)
 {
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 5b961c5b78d1..157fb1ae7e64 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -29,6 +29,7 @@
 #define TRCAUXCTLR			0x018
 #define TRCEVENTCTL0R			0x020
 #define TRCEVENTCTL1R			0x024
+#define TRCRSR				0x028
 #define TRCSTALLCTLR			0x02C
 #define TRCTSCTLR			0x030
 #define TRCSYNCPR			0x034
@@ -49,6 +50,7 @@
 #define TRCSEQRSTEVR			0x118
 #define TRCSEQSTR			0x11C
 #define TRCEXTINSELR			0x120
+#define TRCEXTINSELRn(n)		(0x120 + (n * 4)) /* n = 0-3 */
 #define TRCCNTRLDVRn(n)			(0x140 + (n * 4)) /* n = 0-3 */
 #define TRCCNTCTLRn(n)			(0x150 + (n * 4)) /* n = 0-3 */
 #define TRCCNTVRn(n)			(0x160 + (n * 4)) /* n = 0-3 */
@@ -160,10 +162,22 @@
 #define CASE_NOP(__unused, x)					\
 	case (x):	/* fall through */
 
+#define ETE_ONLY_SYSREG_LIST(op, val)		\
+	CASE_##op((val), TRCRSR)		\
+	CASE_##op((val), TRCEXTINSELRn(1))	\
+	CASE_##op((val), TRCEXTINSELRn(2))	\
+	CASE_##op((val), TRCEXTINSELRn(3))
+
 /* List of registers accessible via System instructions */
-#define ETM_SYSREG_LIST(op, val)		\
-	CASE_##op((val), TRCPRGCTLR)		\
+#define ETM4x_ONLY_SYSREG_LIST(op, val)		\
 	CASE_##op((val), TRCPROCSELR)		\
+	CASE_##op((val), TRCVDCTLR)		\
+	CASE_##op((val), TRCVDSACCTLR)		\
+	CASE_##op((val), TRCVDARCCTLR)		\
+	CASE_##op((val), TRCOSLAR)
+
+#define ETM_COMMON_SYSREG_LIST(op, val)		\
+	CASE_##op((val), TRCPRGCTLR)		\
 	CASE_##op((val), TRCSTATR)		\
 	CASE_##op((val), TRCCONFIGR)		\
 	CASE_##op((val), TRCAUXCTLR)		\
@@ -180,9 +194,6 @@
 	CASE_##op((val), TRCVIIECTLR)		\
 	CASE_##op((val), TRCVISSCTLR)		\
 	CASE_##op((val), TRCVIPCSSCTLR)		\
-	CASE_##op((val), TRCVDCTLR)		\
-	CASE_##op((val), TRCVDSACCTLR)		\
-	CASE_##op((val), TRCVDARCCTLR)		\
 	CASE_##op((val), TRCSEQEVRn(0))		\
 	CASE_##op((val), TRCSEQEVRn(1))		\
 	CASE_##op((val), TRCSEQEVRn(2))		\
@@ -277,7 +288,6 @@
 	CASE_##op((val), TRCSSPCICRn(5))	\
 	CASE_##op((val), TRCSSPCICRn(6))	\
 	CASE_##op((val), TRCSSPCICRn(7))	\
-	CASE_##op((val), TRCOSLAR)		\
 	CASE_##op((val), TRCOSLSR)		\
 	CASE_##op((val), TRCACVRn(0))		\
 	CASE_##op((val), TRCACVRn(1))		\
@@ -369,12 +379,38 @@
 	CASE_##op((val), TRCPIDR2)		\
 	CASE_##op((val), TRCPIDR3)
 
-#define ETM4x_READ_SYSREG_CASES(res)	ETM_SYSREG_LIST(READ, (res))
-#define ETM4x_WRITE_SYSREG_CASES(val)	ETM_SYSREG_LIST(WRITE, (val))
+#define ETM4x_READ_SYSREG_CASES(res)		\
+	ETM_COMMON_SYSREG_LIST(READ, (res))	\
+	ETM4x_ONLY_SYSREG_LIST(READ, (res))
+
+#define ETM4x_WRITE_SYSREG_CASES(val)		\
+	ETM_COMMON_SYSREG_LIST(WRITE, (val))	\
+	ETM4x_ONLY_SYSREG_LIST(WRITE, (val))
+
+#define ETM_COMMON_SYSREG_LIST_CASES		\
+	ETM_COMMON_SYSREG_LIST(NOP, __unused)
+
+#define ETM4x_ONLY_SYSREG_LIST_CASES		\
+	ETM4x_ONLY_SYSREG_LIST(NOP, __unused)
+
+#define ETM4x_SYSREG_LIST_CASES			\
+	ETM_COMMON_SYSREG_LIST_CASES		\
+	ETM4x_ONLY_SYSREG_LIST(NOP, __unused)
 
-#define ETM4x_SYSREG_LIST_CASES		ETM_SYSREG_LIST(NOP, __unused)
 #define ETM4x_MMAP_LIST_CASES		ETM_MMAP_LIST(NOP, __unused)
 
+/* ETE only supports system register access */
+#define ETE_READ_CASES(res)			\
+	ETM_COMMON_SYSREG_LIST(READ, (res))	\
+	ETE_ONLY_SYSREG_LIST(READ, (res))
+
+#define ETE_WRITE_CASES(val)			\
+	ETM_COMMON_SYSREG_LIST(WRITE, (val))	\
+	ETE_ONLY_SYSREG_LIST(WRITE, (val))
+
+#define ETE_ONLY_SYSREG_LIST_CASES		\
+	ETE_ONLY_SYSREG_LIST(NOP, __unused)
+
 #define read_etm4x_sysreg_offset(offset, _64bit)				\
 	({									\
 		u64 __val;							\
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:00 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:00 +0100
Subject: [PATCH v6 13/20] coresight: ete: Add support for ETE tracing
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-14-suzuki.poulose@arm.com>

Add ETE as one of the supported device types we support
with ETM4x driver. The devices are named following the
existing convention as ete<N>.

ETE mandates that the trace resource status register is programmed
before the tracing is turned on. For the moment simply write to
it indicating TraceActive.

Cc: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/Kconfig           | 10 ++--
 .../coresight/coresight-etm4x-core.c          | 58 ++++++++++++++-----
 .../coresight/coresight-etm4x-sysfs.c         | 19 +++++-
 drivers/hwtracing/coresight/coresight-etm4x.h | 12 ++++
 4 files changed, 78 insertions(+), 21 deletions(-)

diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index 7b44ba22cbe1..f154ae7e705d 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -97,15 +97,15 @@ config CORESIGHT_SOURCE_ETM3X
 	  module will be called coresight-etm3x.
 
 config CORESIGHT_SOURCE_ETM4X
-	tristate "CoreSight Embedded Trace Macrocell 4.x driver"
+	tristate "CoreSight ETMv4.x / ETE driver"
 	depends on ARM64
 	select CORESIGHT_LINKS_AND_SINKS
 	select PID_IN_CONTEXTIDR
 	help
-	  This driver provides support for the ETM4.x tracer module, tracing the
-	  instructions that a processor is executing. This is primarily useful
-	  for instruction level tracing. Depending on the implemented version
-	  data tracing may also be available.
+	  This driver provides support for the CoreSight Embedded Trace Macrocell
+	  version 4.x and the Embedded Trace Extensions (ETE). Both are CPU tracer
+	  modules, tracing the instructions that a processor is executing. This is
+	  primarily useful for instruction level tracing.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called coresight-etm4x.
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 3e400fd2e404..efb84ced83dd 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -433,6 +433,13 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
 		etm4x_relaxed_write32(csa, trcpdcr | TRCPDCR_PU, TRCPDCR);
 	}
 
+	/*
+	 * ETE mandates that the TRCRSR is written to before
+	 * enabling it.
+	 */
+	if (etm4x_is_ete(drvdata))
+		etm4x_relaxed_write32(csa, TRCRSR_TA, TRCRSR);
+
 	/* Enable the trace unit */
 	etm4x_relaxed_write32(csa, 1, TRCPRGCTLR);
 
@@ -894,13 +901,24 @@ static bool etm4_init_sysreg_access(struct etmv4_drvdata *drvdata,
 	 * ETMs implementing sysreg access must implement TRCDEVARCH.
 	 */
 	devarch = read_etm4x_sysreg_const_offset(TRCDEVARCH);
-	if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH)
+	switch (devarch & ETM_DEVARCH_ID_MASK) {
+	case ETM_DEVARCH_ETMv4x_ARCH:
+		*csa = (struct csdev_access) {
+			.io_mem	= false,
+			.read	= etm4x_sysreg_read,
+			.write	= etm4x_sysreg_write,
+		};
+		break;
+	case ETM_DEVARCH_ETE_ARCH:
+		*csa = (struct csdev_access) {
+			.io_mem	= false,
+			.read	= ete_sysreg_read,
+			.write	= ete_sysreg_write,
+		};
+		break;
+	default:
 		return false;
-	*csa = (struct csdev_access) {
-		.io_mem	= false,
-		.read	= etm4x_sysreg_read,
-		.write	= etm4x_sysreg_write,
-	};
+	}
 
 	drvdata->arch = etm_devarch_to_arch(devarch);
 	return true;
@@ -1841,6 +1859,8 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 	struct etmv4_drvdata *drvdata;
 	struct coresight_desc desc = { 0 };
 	struct etm4_init_arg init_arg = { 0 };
+	u8 major, minor;
+	char *type_name;
 
 	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
 	if (!drvdata)
@@ -1867,10 +1887,6 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 	if (drvdata->cpu < 0)
 		return drvdata->cpu;
 
-	desc.name = devm_kasprintf(dev, GFP_KERNEL, "etm%d", drvdata->cpu);
-	if (!desc.name)
-		return -ENOMEM;
-
 	init_arg.drvdata = drvdata;
 	init_arg.csa = &desc.access;
 	init_arg.pid = etm_pid;
@@ -1887,6 +1903,22 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 	    fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up"))
 		drvdata->skip_power_up = true;
 
+	major = ETM_ARCH_MAJOR_VERSION(drvdata->arch);
+	minor = ETM_ARCH_MINOR_VERSION(drvdata->arch);
+
+	if (etm4x_is_ete(drvdata)) {
+		type_name = "ete";
+		/* ETE v1 has major version == 0b101. Adjust this for logging.*/
+		major -= 4;
+	} else {
+		type_name = "etm";
+	}
+
+	desc.name = devm_kasprintf(dev, GFP_KERNEL,
+				   "%s%d", type_name, drvdata->cpu);
+	if (!desc.name)
+		return -ENOMEM;
+
 	etm4_init_trace_id(drvdata);
 	etm4_set_default(&drvdata->config);
 
@@ -1914,9 +1946,8 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 
 	etmdrvdata[drvdata->cpu] = drvdata;
 
-	dev_info(&drvdata->csdev->dev, "CPU%d: ETM v%d.%d initialized\n",
-		 drvdata->cpu, ETM_ARCH_MAJOR_VERSION(drvdata->arch),
-		 ETM_ARCH_MINOR_VERSION(drvdata->arch));
+	dev_info(&drvdata->csdev->dev, "CPU%d: %s v%d.%d initialized\n",
+		 drvdata->cpu, type_name, major, minor);
 
 	if (boot_enable) {
 		coresight_enable(drvdata->csdev);
@@ -2059,6 +2090,7 @@ static struct amba_driver etm4x_amba_driver = {
 
 static const struct of_device_id etm4_sysreg_match[] = {
 	{ .compatible	= "arm,coresight-etm4x-sysreg" },
+	{ .compatible	= "arm,embedded-trace-extension" },
 	{}
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index 0995a10790f4..007bad9e7ad8 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -2374,12 +2374,20 @@ static inline bool
 etm4x_register_implemented(struct etmv4_drvdata *drvdata, u32 offset)
 {
 	switch (offset) {
-	ETM4x_SYSREG_LIST_CASES
+	ETM_COMMON_SYSREG_LIST_CASES
 		/*
-		 * Registers accessible via system instructions are always
-		 * implemented.
+		 * Common registers to ETE & ETM4x accessible via system
+		 * instructions are always implemented.
 		 */
 		return true;
+
+	ETM4x_ONLY_SYSREG_LIST_CASES
+		/*
+		 * We only support etm4x and ete. So if the device is not
+		 * ETE, it must be ETMv4x.
+		 */
+		return !etm4x_is_ete(drvdata);
+
 	ETM4x_MMAP_LIST_CASES
 		/*
 		 * Registers accessible only via memory-mapped registers
@@ -2389,8 +2397,13 @@ etm4x_register_implemented(struct etmv4_drvdata *drvdata, u32 offset)
 		 * coresight_register() and the csdev is not initialized
 		 * until that is done. So rely on the drvdata->base to
 		 * detect if we have a memory mapped access.
+		 * Also ETE doesn't implement memory mapped access, thus
+		 * it is sufficient to check that we are using mmio.
 		 */
 		return !!drvdata->base;
+
+	ETE_ONLY_SYSREG_LIST_CASES
+		return etm4x_is_ete(drvdata);
 	}
 
 	return false;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 157fb1ae7e64..e5b79bdb9851 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -128,6 +128,8 @@
 #define TRCCIDR2			0xFF8
 #define TRCCIDR3			0xFFC
 
+#define TRCRSR_TA			BIT(12)
+
 /*
  * System instructions to access ETM registers.
  * See ETMv4.4 spec ARM IHI0064F section 4.3.6 System instructions
@@ -591,11 +593,14 @@
 	((ETM_DEVARCH_MAKE_ARCHID_ARCH_VER(major)) | ETM_DEVARCH_ARCHID_ARCH_PART(0xA13))
 
 #define ETM_DEVARCH_ARCHID_ETMv4x		ETM_DEVARCH_MAKE_ARCHID(0x4)
+#define ETM_DEVARCH_ARCHID_ETE			ETM_DEVARCH_MAKE_ARCHID(0x5)
 
 #define ETM_DEVARCH_ID_MASK						\
 	(ETM_DEVARCH_ARCHITECT_MASK | ETM_DEVARCH_ARCHID_MASK | ETM_DEVARCH_PRESENT)
 #define ETM_DEVARCH_ETMv4x_ARCH						\
 	(ETM_DEVARCH_ARCHITECT_ARM | ETM_DEVARCH_ARCHID_ETMv4x | ETM_DEVARCH_PRESENT)
+#define ETM_DEVARCH_ETE_ARCH						\
+	(ETM_DEVARCH_ARCHITECT_ARM | ETM_DEVARCH_ARCHID_ETE | ETM_DEVARCH_PRESENT)
 
 #define TRCSTATR_IDLE_BIT		0
 #define TRCSTATR_PMSTABLE_BIT		1
@@ -685,6 +690,8 @@
 #define ETM_ARCH_MINOR_VERSION(arch)	((arch) & 0xfU)
 
 #define ETM_ARCH_V4	ETM_ARCH_VERSION(4, 0)
+#define ETM_ARCH_ETE	ETM_ARCH_VERSION(5, 0)
+
 /* Interpretation of resource numbers change at ETM v4.3 architecture */
 #define ETM_ARCH_V4_3	ETM_ARCH_VERSION(4, 3)
 
@@ -993,4 +1000,9 @@ void etm4_config_trace_mode(struct etmv4_config *config);
 
 u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit);
 void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit);
+
+static inline bool etm4x_is_ete(struct etmv4_drvdata *drvdata)
+{
+	return drvdata->arch >= ETM_ARCH_ETE;
+}
 #endif
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:01 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:01 +0100
Subject: [PATCH v6 14/20] dts: bindings: Document device tree bindings for ETE
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-15-suzuki.poulose@arm.com>

Document the device tree bindings for Embedded Trace Extensions.
ETE can be connected to legacy coresight components and thus
could optionally contain a connection graph as described by
the CoreSight bindings.

Cc: devicetree at vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../devicetree/bindings/arm/ete.yaml          | 75 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml

diff --git a/Documentation/devicetree/bindings/arm/ete.yaml b/Documentation/devicetree/bindings/arm/ete.yaml
new file mode 100644
index 000000000000..7f9b2d1e1147
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ete.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# Copyright 2021, Arm Ltd
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/ete.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: ARM Embedded Trace Extensions
+
+maintainers:
+  - Suzuki K Poulose <suzuki.poulose at arm.com>
+  - Mathieu Poirier <mathieu.poirier at linaro.org>
+
+description: |
+  Arm Embedded Trace Extension(ETE) is a per CPU trace component that
+  allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
+  architecture and has extended support for future architecture changes.
+  The trace generated by the ETE could be stored via legacy CoreSight
+  components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
+  Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
+  legacy CoreSight components, a node must be listed per instance, along
+  with any optional connection graph as per the coresight bindings.
+  See bindings/arm/coresight.txt.
+
+properties:
+  $nodename:
+    pattern: "^ete([0-9a-f]+)$"
+  compatible:
+    items:
+      - const: arm,embedded-trace-extension
+
+  cpu:
+    description: |
+      Handle to the cpu this ETE is bound to.
+    $ref: /schemas/types.yaml#/definitions/phandle
+
+  out-ports:
+    description: |
+      Output connections from the ETE to legacy CoreSight trace bus.
+    $ref: /schemas/graph.yaml#/properties/ports
+    properties:
+      port:
+        description: Output connection from the ETE to legacy CoreSight Trace bus.
+        $ref: /schemas/graph.yaml#/properties/port
+
+required:
+  - compatible
+  - cpu
+
+additionalProperties: false
+
+examples:
+
+# An ETE node without legacy CoreSight connections
+  - |
+    ete0 {
+      compatible = "arm,embedded-trace-extension";
+      cpu = <&cpu_0>;
+    };
+# An ETE node with legacy CoreSight connections
+  - |
+   ete1 {
+      compatible = "arm,embedded-trace-extension";
+      cpu = <&cpu_1>;
+
+      out-ports {        /* legacy coresight connection */
+         port {
+             ete1_out_port: endpoint {
+                remote-endpoint = <&funnel_in_port0>;
+             };
+         };
+      };
+   };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index aa84121c5611..2a20a36c724a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1761,6 +1761,7 @@ F:	Documentation/ABI/testing/sysfs-bus-coresight-devices-*
 F:	Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 F:	Documentation/devicetree/bindings/arm/coresight-cti.yaml
 F:	Documentation/devicetree/bindings/arm/coresight.txt
+F:	Documentation/devicetree/bindings/arm/ete.yaml
 F:	Documentation/trace/coresight/*
 F:	drivers/hwtracing/coresight/*
 F:	include/dt-bindings/arm/coresight-cti-dt.h
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:02 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:02 +0100
Subject: [PATCH v6 15/20] coresight: etm-perf: Handle stale output handles
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-16-suzuki.poulose@arm.com>

The context associated with an ETM for a given perf event
includes :
  - handle -> the perf output handle for the AUX buffer.
  - the path for the trace components
  - the buffer config for the sink.

The path and the buffer config are part of the "aux_priv" data
(etm_event_data) setup by the setup_aux() callback, and made available
via perf_get_aux(handle).

Now with a sink supporting IRQ, the sink could "end" an output
handle when the buffer reaches the programmed limit and would try
to restart a handle. This could fail if there is not enough
space left the AUX buffer (e.g, the userspace has not consumed
the data). This leaves the "handle" disconnected from the "event"
and also the "perf_get_aux()" cleared. This all happens within
the sink driver, without the etm_perf driver being aware.
Now when the event is actually stopped, etm_event_stop()
will need to access the "event_data". But since the handle
is not valid anymore, we loose the information to stop the
"trace" path. So, we need a reliable way to access the etm_event_data
even when the handle may not be active.

This patch replaces the per_cpu handle array with a per_cpu context
for the ETM, which tracks the "handle" as well as the "etm_event_data".
The context notes the etm_event_data at etm_event_start() and clears
it at etm_event_stop(). This makes sure that we don't access a
stale "etm_event_data" as we are guaranteed that it is not
freed by free_aux() as long as the event is active and tracing,
also provides us with access to the critical information
needed to wind up a session even in the absence of an active
output_handle.

This is not an issue for the legacy sinks as none of them supports
an IRQ and is centrally handled by the etm-perf.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Leo Yan <leo.yan at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../hwtracing/coresight/coresight-etm-perf.c  | 59 +++++++++++++++++--
 1 file changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index aa0974bd265b..f123c26b9f54 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -24,7 +24,26 @@
 static struct pmu etm_pmu;
 static bool etm_perf_up;
 
-static DEFINE_PER_CPU(struct perf_output_handle, ctx_handle);
+/*
+ * An ETM context for a running event includes the perf aux handle
+ * and aux_data. For ETM, the aux_data (etm_event_data), consists of
+ * the trace path and the sink configuration. The event data is accessible
+ * via perf_get_aux(handle). However, a sink could "end" a perf output
+ * handle via the IRQ handler. And if the "sink" encounters a failure
+ * to "begin" another session (e.g due to lack of space in the buffer),
+ * the handle will be cleared. Thus, the event_data may not be accessible
+ * from the handle when we get to the etm_event_stop(), which is required
+ * for stopping the trace path. The event_data is guaranteed to stay alive
+ * until "free_aux()", which cannot happen as long as the event is active on
+ * the ETM. Thus the event_data for the session must be part of the ETM context
+ * to make sure we can disable the trace path.
+ */
+struct etm_ctxt {
+	struct perf_output_handle handle;
+	struct etm_event_data *event_data;
+};
+
+static DEFINE_PER_CPU(struct etm_ctxt, etm_ctxt);
 static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
 
 /*
@@ -376,13 +395,18 @@ static void etm_event_start(struct perf_event *event, int flags)
 {
 	int cpu = smp_processor_id();
 	struct etm_event_data *event_data;
-	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
+	struct etm_ctxt *ctxt = this_cpu_ptr(&etm_ctxt);
+	struct perf_output_handle *handle = &ctxt->handle;
 	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
 	struct list_head *path;
 
 	if (!csdev)
 		goto fail;
 
+	/* Have we messed up our tracking ? */
+	if (WARN_ON(ctxt->event_data))
+		goto fail;
+
 	/*
 	 * Deal with the ring buffer API and get a handle on the
 	 * session's information.
@@ -418,6 +442,8 @@ static void etm_event_start(struct perf_event *event, int flags)
 	if (source_ops(csdev)->enable(csdev, event, CS_MODE_PERF))
 		goto fail_disable_path;
 
+	/* Save the event_data for this ETM */
+	ctxt->event_data = event_data;
 out:
 	return;
 
@@ -436,13 +462,30 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	int cpu = smp_processor_id();
 	unsigned long size;
 	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
-	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
-	struct etm_event_data *event_data = perf_get_aux(handle);
+	struct etm_ctxt *ctxt = this_cpu_ptr(&etm_ctxt);
+	struct perf_output_handle *handle = &ctxt->handle;
+	struct etm_event_data *event_data;
 	struct list_head *path;
 
+	/*
+	 * If we still have access to the event_data via handle,
+	 * confirm that we haven't messed up the tracking.
+	 */
+	if (handle->event &&
+	    WARN_ON(perf_get_aux(handle) != ctxt->event_data))
+		return;
+
+	event_data = ctxt->event_data;
+	/* Clear the event_data as this ETM is stopping the trace. */
+	ctxt->event_data = NULL;
+
 	if (event->hw.state == PERF_HES_STOPPED)
 		return;
 
+	/* We must have a valid event_data for a running event */
+	if (WARN_ON(!event_data))
+		return;
+
 	if (!csdev)
 		return;
 
@@ -460,7 +503,13 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	/* tell the core */
 	event->hw.state = PERF_HES_STOPPED;
 
-	if (mode & PERF_EF_UPDATE) {
+	/*
+	 * If the handle is not bound to an event anymore
+	 * (e.g, the sink driver was unable to restart the
+	 * handle due to lack of buffer space), we don't
+	 * have to do anything here.
+	 */
+	if (handle->event && (mode & PERF_EF_UPDATE)) {
 		if (WARN_ON_ONCE(handle->event != event))
 			return;
 
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:03 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:03 +0100
Subject: [PATCH v6 16/20] coresight: core: Add support for dedicated percpu
 sinks
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-17-suzuki.poulose@arm.com>

From: Anshuman Khandual <anshuman.khandual at arm.com>

Add support for dedicated sinks that are bound to individual CPUs. (e.g,
TRBE). To allow quicker access to the sink for a given CPU bound source,
keep a percpu array of the sink devices. Also, add support for building
a path to the CPU local sink from the ETM.

This adds a new percpu sink type CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM.
This new sink type is exclusively available and can only work with percpu
source type device CORESIGHT_DEV_SUBTYPE_SOURCE_PROC.

This defines a percpu structure that accommodates a single coresight_device
which can be used to store an initialized instance from a sink driver. As
these sinks are exclusively linked and dependent on corresponding percpu
sources devices, they should also be the default sink device during a perf
session.

Outwards device connections are scanned while establishing paths between a
source and a sink device. But such connections are not present for certain
percpu source and sink devices which are exclusively linked and dependent.
Build the path directly and skip connection scanning for such devices.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
[Moved the set/get percpu sink APIs from TRBE patch to here
 Fixed build break on arm32
]
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 29 ++++++++++++++++++--
 drivers/hwtracing/coresight/coresight-priv.h |  3 ++
 include/linux/coresight.h                    | 13 +++++++++
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 0062c8935653..55c645616bf6 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -23,6 +23,7 @@
 #include "coresight-priv.h"
 
 static DEFINE_MUTEX(coresight_mutex);
+DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
 
 /**
  * struct coresight_node - elements of a path, from source to sink
@@ -70,6 +71,18 @@ void coresight_remove_cti_ops(void)
 }
 EXPORT_SYMBOL_GPL(coresight_remove_cti_ops);
 
+void coresight_set_percpu_sink(int cpu, struct coresight_device *csdev)
+{
+	per_cpu(csdev_sink, cpu) = csdev;
+}
+EXPORT_SYMBOL_GPL(coresight_set_percpu_sink);
+
+struct coresight_device *coresight_get_percpu_sink(int cpu)
+{
+	return per_cpu(csdev_sink, cpu);
+}
+EXPORT_SYMBOL_GPL(coresight_get_percpu_sink);
+
 static int coresight_id_match(struct device *dev, void *data)
 {
 	int trace_id, i_trace_id;
@@ -784,6 +797,14 @@ static int _coresight_build_path(struct coresight_device *csdev,
 	if (csdev == sink)
 		goto out;
 
+	if (coresight_is_percpu_source(csdev) && coresight_is_percpu_sink(sink) &&
+	    sink == per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev))) {
+		if (_coresight_build_path(sink, sink, path) == 0) {
+			found = true;
+			goto out;
+		}
+	}
+
 	/* Not a sink - recursively explore each port found on this element */
 	for (i = 0; i < csdev->pdata->nr_outport; i++) {
 		struct coresight_device *child_dev;
@@ -999,8 +1020,12 @@ coresight_find_default_sink(struct coresight_device *csdev)
 	int depth = 0;
 
 	/* look for a default sink if we have not found for this device */
-	if (!csdev->def_sink)
-		csdev->def_sink = coresight_find_sink(csdev, &depth);
+	if (!csdev->def_sink) {
+		if (coresight_is_percpu_source(csdev))
+			csdev->def_sink = per_cpu(csdev_sink, source_ops(csdev)->cpu_id(csdev));
+		if (!csdev->def_sink)
+			csdev->def_sink = coresight_find_sink(csdev, &depth);
+	}
 	return csdev->def_sink;
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index f5f654ea2994..ff1dd2092ac5 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -232,4 +232,7 @@ coresight_find_csdev_by_fwnode(struct fwnode_handle *r_fwnode);
 void coresight_set_assoc_ectdev_mutex(struct coresight_device *csdev,
 				      struct coresight_device *ect_csdev);
 
+void coresight_set_percpu_sink(int cpu, struct coresight_device *csdev);
+struct coresight_device *coresight_get_percpu_sink(int cpu);
+
 #endif
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 976ec2697610..85008a65e21f 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -50,6 +50,7 @@ enum coresight_dev_subtype_sink {
 	CORESIGHT_DEV_SUBTYPE_SINK_PORT,
 	CORESIGHT_DEV_SUBTYPE_SINK_BUFFER,
 	CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM,
+	CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM,
 };
 
 enum coresight_dev_subtype_link {
@@ -455,6 +456,18 @@ static inline void csdev_access_write64(struct csdev_access *csa, u64 val, u32 o
 }
 #endif	/* CONFIG_64BIT */
 
+static inline bool coresight_is_percpu_source(struct coresight_device *csdev)
+{
+	return csdev && (csdev->type == CORESIGHT_DEV_TYPE_SOURCE) &&
+	       (csdev->subtype.source_subtype == CORESIGHT_DEV_SUBTYPE_SOURCE_PROC);
+}
+
+static inline bool coresight_is_percpu_sink(struct coresight_device *csdev)
+{
+	return csdev && (csdev->type == CORESIGHT_DEV_TYPE_SINK) &&
+	       (csdev->subtype.sink_subtype == CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM);
+}
+
 extern struct coresight_device *
 coresight_register(struct coresight_desc *desc);
 extern void coresight_unregister(struct coresight_device *csdev);
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:05 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:05 +0100
Subject: [PATCH v6 18/20] Documentation: coresight: trbe: Sysfs ABI description
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-19-suzuki.poulose@arm.com>

From: Anshuman Khandual <anshuman.khandual at arm.com>

Add sysfs ABI documentation for the TRBE devices.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Jonathan Corbet <corbet at lwn.net>
Cc: linux-doc at vger.kernel.org
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
[ Split from the TRBE driver patch ]
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../ABI/testing/sysfs-bus-coresight-devices-trbe   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe b/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
new file mode 100644
index 000000000000..ad3bbc6fa751
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
@@ -0,0 +1,14 @@
+What:		/sys/bus/coresight/devices/trbe<cpu>/align
+Date:		March 2021
+KernelVersion:	5.13
+Contact:	Anshuman Khandual <anshuman.khandual at arm.com>
+Description:	(Read) Shows the TRBE write pointer alignment. This value
+		is fetched from the TRBIDR register.
+
+What:		/sys/bus/coresight/devices/trbe<cpu>/flag
+Date:		March 2021
+KernelVersion:	5.13
+Contact:	Anshuman Khandual <anshuman.khandual at arm.com>
+Description:	(Read) Shows if TRBE updates in the memory are with access
+		and dirty flag updates as well. This value is fetched from
+		the TRBIDR register.
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:04 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:04 +0100
Subject: [PATCH v6 17/20] coresight: sink: Add TRBE driver
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-18-suzuki.poulose@arm.com>

From: Anshuman Khandual <anshuman.khandual at arm.com>

Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
accessible via the system registers. The TRBE supports different addressing
modes including CPU virtual address and buffer modes including the circular
buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
access to the trace buffer could be prohibited by a higher exception level
(EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
private interrupt (PPI) on address translation errors and when the buffer
is full. Overall implementation here is inspired from the Arm SPE driver.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mike Leach <mike.leach at linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
[ Mark the buffer truncated on WRAP event, error code cleanup ]
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/Kconfig          |   14 +
 drivers/hwtracing/coresight/Makefile         |    1 +
 drivers/hwtracing/coresight/coresight-trbe.c | 1157 ++++++++++++++++++
 drivers/hwtracing/coresight/coresight-trbe.h |  152 +++
 4 files changed, 1324 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h

diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index f154ae7e705d..84530fd80998 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -173,4 +173,18 @@ config CORESIGHT_CTI_INTEGRATION_REGS
 	  CTI trigger connections between this and other devices.These
 	  registers are not used in normal operation and can leave devices in
 	  an inconsistent state.
+
+config CORESIGHT_TRBE
+	tristate "Trace Buffer Extension (TRBE) driver"
+	depends on ARM64 && CORESIGHT_SOURCE_ETM4X
+	help
+	  This driver provides support for percpu Trace Buffer Extension (TRBE).
+	  TRBE always needs to be used along with it's corresponding percpu ETE
+	  component. ETE generates trace data which is then captured with TRBE.
+	  Unlike traditional sink devices, TRBE is a CPU feature accessible via
+	  system registers. But it's explicit dependency with trace unit (ETE)
+	  requires it to be plugged in as a coresight sink device.
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called coresight-trbe.
 endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index f20e357758d1..d60816509755 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -21,5 +21,6 @@ obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
 obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
 obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
 obj-$(CONFIG_CORESIGHT_CTI) += coresight-cti.o
+obj-$(CONFIG_CORESIGHT_TRBE) += coresight-trbe.o
 coresight-cti-y := coresight-cti-core.o	coresight-cti-platform.o \
 		   coresight-cti-sysfs.o
diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
new file mode 100644
index 000000000000..5ce239875c98
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -0,0 +1,1157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This driver enables Trace Buffer Extension (TRBE) as a per-cpu coresight
+ * sink device could then pair with an appropriate per-cpu coresight source
+ * device (ETE) thus generating required trace data. Trace can be enabled
+ * via the perf framework.
+ *
+ * The AUX buffer handling is inspired from Arm SPE PMU driver.
+ *
+ * Copyright (C) 2020 ARM Ltd.
+ *
+ * Author: Anshuman Khandual <anshuman.khandual at arm.com>
+ */
+#define DRVNAME "arm_trbe"
+
+#define pr_fmt(fmt) DRVNAME ": " fmt
+
+#include <asm/barrier.h>
+#include "coresight-trbe.h"
+
+#define PERF_IDX2OFF(idx, buf) ((idx) % ((buf)->nr_pages << PAGE_SHIFT))
+
+/*
+ * A padding packet that will help the user space tools
+ * in skipping relevant sections in the captured trace
+ * data which could not be decoded. TRBE doesn't support
+ * formatting the trace data, unlike the legacy CoreSight
+ * sinks and thus we use ETE trace packets to pad the
+ * sections of the buffer.
+ */
+#define ETE_IGNORE_PACKET		0x70
+
+/*
+ * Minimum amount of meaningful trace will contain:
+ * A-Sync, Trace Info, Trace On, Address, Atom.
+ * This is about 44bytes of ETE trace. To be on
+ * the safer side, we assume 64bytes is the minimum
+ * space required for a meaningful session, before
+ * we hit a "WRAP" event.
+ */
+#define TRBE_TRACE_MIN_BUF_SIZE		64
+
+enum trbe_fault_action {
+	TRBE_FAULT_ACT_WRAP,
+	TRBE_FAULT_ACT_SPURIOUS,
+	TRBE_FAULT_ACT_FATAL,
+};
+
+struct trbe_buf {
+	/*
+	 * Even though trbe_base represents vmap()
+	 * mapped allocated buffer's start address,
+	 * it's being as unsigned long for various
+	 * arithmetic and comparision operations &
+	 * also to be consistent with trbe_write &
+	 * trbe_limit sibling pointers.
+	 */
+	unsigned long trbe_base;
+	unsigned long trbe_limit;
+	unsigned long trbe_write;
+	int nr_pages;
+	void **pages;
+	bool snapshot;
+	struct trbe_cpudata *cpudata;
+};
+
+struct trbe_cpudata {
+	bool trbe_flag;
+	u64 trbe_align;
+	int cpu;
+	enum cs_mode mode;
+	struct trbe_buf *buf;
+	struct trbe_drvdata *drvdata;
+};
+
+struct trbe_drvdata {
+	struct trbe_cpudata __percpu *cpudata;
+	struct perf_output_handle * __percpu *handle;
+	struct hlist_node hotplug_node;
+	int irq;
+	cpumask_t supported_cpus;
+	enum cpuhp_state trbe_online;
+	struct platform_device *pdev;
+};
+
+static int trbe_alloc_node(struct perf_event *event)
+{
+	if (event->cpu == -1)
+		return NUMA_NO_NODE;
+	return cpu_to_node(event->cpu);
+}
+
+static void trbe_drain_buffer(void)
+{
+	tsb_csync();
+	dsb(nsh);
+}
+
+static void trbe_drain_and_disable_local(void)
+{
+	u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+
+	trbe_drain_buffer();
+
+	/*
+	 * Disable the TRBE without clearing LIMITPTR which
+	 * might be required for fetching the buffer limits.
+	 */
+	trblimitr &= ~TRBLIMITR_ENABLE;
+	write_sysreg_s(trblimitr, SYS_TRBLIMITR_EL1);
+	isb();
+}
+
+static void trbe_reset_local(void)
+{
+	trbe_drain_and_disable_local();
+	write_sysreg_s(0, SYS_TRBLIMITR_EL1);
+	write_sysreg_s(0, SYS_TRBPTR_EL1);
+	write_sysreg_s(0, SYS_TRBBASER_EL1);
+	write_sysreg_s(0, SYS_TRBSR_EL1);
+}
+
+static void trbe_stop_and_truncate_event(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+
+	/*
+	 * We cannot proceed with the buffer collection and we
+	 * do not have any data for the current session. The
+	 * etm_perf driver expects to close out the aux_buffer
+	 * at event_stop(). So disable the TRBE here and leave
+	 * the update_buffer() to return a 0 size.
+	 */
+	trbe_drain_and_disable_local();
+	perf_aux_output_flag(handle, PERF_AUX_FLAG_TRUNCATED);
+	*this_cpu_ptr(buf->cpudata->drvdata->handle) = NULL;
+}
+
+/*
+ * TRBE Buffer Management
+ *
+ * The TRBE buffer spans from the base pointer till the limit pointer. When enabled,
+ * it starts writing trace data from the write pointer onward till the limit pointer.
+ * When the write pointer reaches the address just before the limit pointer, it gets
+ * wrapped around again to the base pointer. This is called a TRBE wrap event, which
+ * generates a maintenance interrupt when operated in WRAP or FILL mode. This driver
+ * uses FILL mode, where the TRBE stops the trace collection at wrap event. The IRQ
+ * handler updates the AUX buffer and re-enables the TRBE with updated WRITE and
+ * LIMIT pointers.
+ *
+ *	Wrap around with an IRQ
+ *	------ < ------ < ------- < ----- < -----
+ *	|					|
+ *	------ > ------ > ------- > ----- > -----
+ *
+ *	+---------------+-----------------------+
+ *	|		|			|
+ *	+---------------+-----------------------+
+ *	Base Pointer	Write Pointer		Limit Pointer
+ *
+ * The base and limit pointers always needs to be PAGE_SIZE aligned. But the write
+ * pointer can be aligned to the implementation defined TRBE trace buffer alignment
+ * as captured in trbe_cpudata->trbe_align.
+ *
+ *
+ *		head		tail		wakeup
+ *	+---------------------------------------+----- ~ ~ ------
+ *	|$$$$$$$|################|$$$$$$$$$$$$$$|		|
+ *	+---------------------------------------+----- ~ ~ ------
+ *	Base Pointer	Write Pointer		Limit Pointer
+ *
+ * The perf_output_handle indices (head, tail, wakeup) are monotonically increasing
+ * values which tracks all the driver writes and user reads from the perf auxiliary
+ * buffer. Generally [head..tail] is the area where the driver can write into unless
+ * the wakeup is behind the tail. Enabled TRBE buffer span needs to be adjusted and
+ * configured depending on the perf_output_handle indices, so that the driver does
+ * not override into areas in the perf auxiliary buffer which is being or yet to be
+ * consumed from the user space. The enabled TRBE buffer area is a moving subset of
+ * the allocated perf auxiliary buffer.
+ */
+static void trbe_pad_buf(struct perf_output_handle *handle, int len)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+	u64 head = PERF_IDX2OFF(handle->head, buf);
+
+	memset((void *)buf->trbe_base + head, ETE_IGNORE_PACKET, len);
+	if (!buf->snapshot)
+		perf_aux_output_skip(handle, len);
+}
+
+static unsigned long trbe_snapshot_offset(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+
+	/*
+	 * The ETE trace has alignment synchronization packets allowing
+	 * the decoder to reset in case of an overflow or corruption.
+	 * So we can use the entire buffer for the snapshot mode.
+	 */
+	return buf->nr_pages * PAGE_SIZE;
+}
+
+/*
+ * TRBE Limit Calculation
+ *
+ * The following markers are used to illustrate various TRBE buffer situations.
+ *
+ * $$$$ - Data area, unconsumed captured trace data, not to be overridden
+ * #### - Free area, enabled, trace will be written
+ * %%%% - Free area, disabled, trace will not be written
+ * ==== - Free area, padded with ETE_IGNORE_PACKET, trace will be skipped
+ */
+static unsigned long __trbe_normal_offset(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+	struct trbe_cpudata *cpudata = buf->cpudata;
+	const u64 bufsize = buf->nr_pages * PAGE_SIZE;
+	u64 limit = bufsize;
+	u64 head, tail, wakeup;
+
+	head = PERF_IDX2OFF(handle->head, buf);
+
+	/*
+	 *		head
+	 *	------->|
+	 *	|
+	 *	head	TRBE align	tail
+	 * +----|-------|---------------|-------+
+	 * |$$$$|=======|###############|$$$$$$$|
+	 * +----|-------|---------------|-------+
+	 * trbe_base				trbe_base + nr_pages
+	 *
+	 * Perf aux buffer output head position can be misaligned depending on
+	 * various factors including user space reads. In case misaligned, head
+	 * needs to be aligned before TRBE can be configured. Pad the alignment
+	 * gap with ETE_IGNORE_PACKET bytes that will be ignored by user tools
+	 * and skip this section thus advancing the head.
+	 */
+	if (!IS_ALIGNED(head, cpudata->trbe_align)) {
+		unsigned long delta = roundup(head, cpudata->trbe_align) - head;
+
+		delta = min(delta, handle->size);
+		trbe_pad_buf(handle, delta);
+		head = PERF_IDX2OFF(handle->head, buf);
+	}
+
+	/*
+	 *	head = tail (size = 0)
+	 * +----|-------------------------------+
+	 * |$$$$|$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$	|
+	 * +----|-------------------------------+
+	 * trbe_base				trbe_base + nr_pages
+	 *
+	 * Perf aux buffer does not have any space for the driver to write into.
+	 * Just communicate trace truncation event to the user space by marking
+	 * it with PERF_AUX_FLAG_TRUNCATED.
+	 */
+	if (!handle->size) {
+		perf_aux_output_flag(handle, PERF_AUX_FLAG_TRUNCATED);
+		return 0;
+	}
+
+	/* Compute the tail and wakeup indices now that we've aligned head */
+	tail = PERF_IDX2OFF(handle->head + handle->size, buf);
+	wakeup = PERF_IDX2OFF(handle->wakeup, buf);
+
+	/*
+	 * Lets calculate the buffer area which TRBE could write into. There
+	 * are three possible scenarios here. Limit needs to be aligned with
+	 * PAGE_SIZE per the TRBE requirement. Always avoid clobbering the
+	 * unconsumed data.
+	 *
+	 * 1) head < tail
+	 *
+	 *	head			tail
+	 * +----|-----------------------|-------+
+	 * |$$$$|#######################|$$$$$$$|
+	 * +----|-----------------------|-------+
+	 * trbe_base			limit	trbe_base + nr_pages
+	 *
+	 * TRBE could write into [head..tail] area. Unless the tail is right at
+	 * the end of the buffer, neither an wrap around nor an IRQ is expected
+	 * while being enabled.
+	 *
+	 * 2) head == tail
+	 *
+	 *	head = tail (size > 0)
+	 * +----|-------------------------------+
+	 * |%%%%|###############################|
+	 * +----|-------------------------------+
+	 * trbe_base				limit = trbe_base + nr_pages
+	 *
+	 * TRBE should just write into [head..base + nr_pages] area even though
+	 * the entire buffer is empty. Reason being, when the trace reaches the
+	 * end of the buffer, it will just wrap around with an IRQ giving an
+	 * opportunity to reconfigure the buffer.
+	 *
+	 * 3) tail < head
+	 *
+	 *	tail			head
+	 * +----|-----------------------|-------+
+	 * |%%%%|$$$$$$$$$$$$$$$$$$$$$$$|#######|
+	 * +----|-----------------------|-------+
+	 * trbe_base				limit = trbe_base + nr_pages
+	 *
+	 * TRBE should just write into [head..base + nr_pages] area even though
+	 * the [trbe_base..tail] is also empty. Reason being, when the trace
+	 * reaches the end of the buffer, it will just wrap around with an IRQ
+	 * giving an opportunity to reconfigure the buffer.
+	 */
+	if (head < tail)
+		limit = round_down(tail, PAGE_SIZE);
+
+	/*
+	 * Wakeup may be arbitrarily far into the future. If it's not in the
+	 * current generation, either we'll wrap before hitting it, or it's
+	 * in the past and has been handled already.
+	 *
+	 * If there's a wakeup before we wrap, arrange to be woken up by the
+	 * page boundary following it. Keep the tail boundary if that's lower.
+	 *
+	 *	head		wakeup	tail
+	 * +----|---------------|-------|-------+
+	 * |$$$$|###############|%%%%%%%|$$$$$$$|
+	 * +----|---------------|-------|-------+
+	 * trbe_base		limit		trbe_base + nr_pages
+	 */
+	if (handle->wakeup < (handle->head + handle->size) && head <= wakeup)
+		limit = min(limit, round_up(wakeup, PAGE_SIZE));
+
+	/*
+	 * There are two situation when this can happen i.e limit is before
+	 * the head and hence TRBE cannot be configured.
+	 *
+	 * 1) head < tail (aligned down with PAGE_SIZE) and also they are both
+	 * within the same PAGE size range.
+	 *
+	 *			PAGE_SIZE
+	 *		|----------------------|
+	 *
+	 *		limit	head	tail
+	 * +------------|------|--------|-------+
+	 * |$$$$$$$$$$$$$$$$$$$|========|$$$$$$$|
+	 * +------------|------|--------|-------+
+	 * trbe_base				trbe_base + nr_pages
+	 *
+	 * 2) head < wakeup (aligned up with PAGE_SIZE) < tail and also both
+	 * head and wakeup are within same PAGE size range.
+	 *
+	 *		PAGE_SIZE
+	 *	|----------------------|
+	 *
+	 *	limit	head	wakeup  tail
+	 * +----|------|-------|--------|-------+
+	 * |$$$$$$$$$$$|=======|========|$$$$$$$|
+	 * +----|------|-------|--------|-------+
+	 * trbe_base				trbe_base + nr_pages
+	 */
+	if (limit > head)
+		return limit;
+
+	trbe_pad_buf(handle, handle->size);
+	perf_aux_output_flag(handle, PERF_AUX_FLAG_TRUNCATED);
+	return 0;
+}
+
+static unsigned long trbe_normal_offset(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = perf_get_aux(handle);
+	u64 limit = __trbe_normal_offset(handle);
+	u64 head = PERF_IDX2OFF(handle->head, buf);
+
+	/*
+	 * If the head is too close to the limit and we don't
+	 * have space for a meaningful run, we rather pad it
+	 * and start fresh.
+	 */
+	if (limit && (limit - head < TRBE_TRACE_MIN_BUF_SIZE)) {
+		trbe_pad_buf(handle, limit - head);
+		limit = __trbe_normal_offset(handle);
+	}
+	return limit;
+}
+
+static unsigned long compute_trbe_buffer_limit(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+	unsigned long offset;
+
+	if (buf->snapshot)
+		offset = trbe_snapshot_offset(handle);
+	else
+		offset = trbe_normal_offset(handle);
+	return buf->trbe_base + offset;
+}
+
+static void clr_trbe_status(void)
+{
+	u64 trbsr = read_sysreg_s(SYS_TRBSR_EL1);
+
+	WARN_ON(is_trbe_enabled());
+	trbsr &= ~TRBSR_IRQ;
+	trbsr &= ~TRBSR_TRG;
+	trbsr &= ~TRBSR_WRAP;
+	trbsr &= ~(TRBSR_EC_MASK << TRBSR_EC_SHIFT);
+	trbsr &= ~(TRBSR_BSC_MASK << TRBSR_BSC_SHIFT);
+	trbsr &= ~TRBSR_STOP;
+	write_sysreg_s(trbsr, SYS_TRBSR_EL1);
+}
+
+static void set_trbe_limit_pointer_enabled(unsigned long addr)
+{
+	u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+
+	WARN_ON(!IS_ALIGNED(addr, (1UL << TRBLIMITR_LIMIT_SHIFT)));
+	WARN_ON(!IS_ALIGNED(addr, PAGE_SIZE));
+
+	trblimitr &= ~TRBLIMITR_NVM;
+	trblimitr &= ~(TRBLIMITR_FILL_MODE_MASK << TRBLIMITR_FILL_MODE_SHIFT);
+	trblimitr &= ~(TRBLIMITR_TRIG_MODE_MASK << TRBLIMITR_TRIG_MODE_SHIFT);
+	trblimitr &= ~(TRBLIMITR_LIMIT_MASK << TRBLIMITR_LIMIT_SHIFT);
+
+	/*
+	 * Fill trace buffer mode is used here while configuring the
+	 * TRBE for trace capture. In this particular mode, the trace
+	 * collection is stopped and a maintenance interrupt is raised
+	 * when the current write pointer wraps. This pause in trace
+	 * collection gives the software an opportunity to capture the
+	 * trace data in the interrupt handler, before reconfiguring
+	 * the TRBE.
+	 */
+	trblimitr |= (TRBE_FILL_MODE_FILL & TRBLIMITR_FILL_MODE_MASK) << TRBLIMITR_FILL_MODE_SHIFT;
+
+	/*
+	 * Trigger mode is not used here while configuring the TRBE for
+	 * the trace capture. Hence just keep this in the ignore mode.
+	 */
+	trblimitr |= (TRBE_TRIG_MODE_IGNORE & TRBLIMITR_TRIG_MODE_MASK) <<
+		      TRBLIMITR_TRIG_MODE_SHIFT;
+	trblimitr |= (addr & PAGE_MASK);
+
+	trblimitr |= TRBLIMITR_ENABLE;
+	write_sysreg_s(trblimitr, SYS_TRBLIMITR_EL1);
+
+	/* Synchronize the TRBE enable event */
+	isb();
+}
+
+static void trbe_enable_hw(struct trbe_buf *buf)
+{
+	WARN_ON(buf->trbe_write < buf->trbe_base);
+	WARN_ON(buf->trbe_write >= buf->trbe_limit);
+	set_trbe_disabled();
+	isb();
+	clr_trbe_status();
+	set_trbe_base_pointer(buf->trbe_base);
+	set_trbe_write_pointer(buf->trbe_write);
+
+	/*
+	 * Synchronize all the register updates
+	 * till now before enabling the TRBE.
+	 */
+	isb();
+	set_trbe_limit_pointer_enabled(buf->trbe_limit);
+}
+
+static enum trbe_fault_action trbe_get_fault_act(u64 trbsr)
+{
+	int ec = get_trbe_ec(trbsr);
+	int bsc = get_trbe_bsc(trbsr);
+
+	WARN_ON(is_trbe_running(trbsr));
+	if (is_trbe_trg(trbsr) || is_trbe_abort(trbsr))
+		return TRBE_FAULT_ACT_FATAL;
+
+	if ((ec == TRBE_EC_STAGE1_ABORT) || (ec == TRBE_EC_STAGE2_ABORT))
+		return TRBE_FAULT_ACT_FATAL;
+
+	if (is_trbe_wrap(trbsr) && (ec == TRBE_EC_OTHERS) && (bsc == TRBE_BSC_FILLED)) {
+		if (get_trbe_write_pointer() == get_trbe_base_pointer())
+			return TRBE_FAULT_ACT_WRAP;
+	}
+	return TRBE_FAULT_ACT_SPURIOUS;
+}
+
+static void *arm_trbe_alloc_buffer(struct coresight_device *csdev,
+				   struct perf_event *event, void **pages,
+				   int nr_pages, bool snapshot)
+{
+	struct trbe_buf *buf;
+	struct page **pglist;
+	int i;
+
+	/*
+	 * TRBE LIMIT and TRBE WRITE pointers must be page aligned. But with
+	 * just a single page, there would not be any room left while writing
+	 * into a partially filled TRBE buffer after the page size alignment.
+	 * Hence restrict the minimum buffer size as two pages.
+	 */
+	if (nr_pages < 2)
+		return NULL;
+
+	buf = kzalloc_node(sizeof(*buf), GFP_KERNEL, trbe_alloc_node(event));
+	if (!buf)
+		return ERR_PTR(-ENOMEM);
+
+	pglist = kcalloc(nr_pages, sizeof(*pglist), GFP_KERNEL);
+	if (!pglist) {
+		kfree(buf);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	for (i = 0; i < nr_pages; i++)
+		pglist[i] = virt_to_page(pages[i]);
+
+	buf->trbe_base = (unsigned long)vmap(pglist, nr_pages, VM_MAP, PAGE_KERNEL);
+	if (!buf->trbe_base) {
+		kfree(pglist);
+		kfree(buf);
+		return ERR_PTR(-ENOMEM);
+	}
+	buf->trbe_limit = buf->trbe_base + nr_pages * PAGE_SIZE;
+	buf->trbe_write = buf->trbe_base;
+	buf->snapshot = snapshot;
+	buf->nr_pages = nr_pages;
+	buf->pages = pages;
+	kfree(pglist);
+	return buf;
+}
+
+static void arm_trbe_free_buffer(void *config)
+{
+	struct trbe_buf *buf = config;
+
+	vunmap((void *)buf->trbe_base);
+	kfree(buf);
+}
+
+static unsigned long arm_trbe_update_buffer(struct coresight_device *csdev,
+					    struct perf_output_handle *handle,
+					    void *config)
+{
+	struct trbe_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
+	struct trbe_buf *buf = config;
+	enum trbe_fault_action act;
+	unsigned long size, offset;
+	unsigned long write, base, status;
+	unsigned long flags;
+
+	WARN_ON(buf->cpudata != cpudata);
+	WARN_ON(cpudata->cpu != smp_processor_id());
+	WARN_ON(cpudata->drvdata != drvdata);
+	if (cpudata->mode != CS_MODE_PERF)
+		return 0;
+
+	perf_aux_output_flag(handle, PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW);
+
+	/*
+	 * We are about to disable the TRBE. And this could in turn
+	 * fill up the buffer triggering, an IRQ. This could be consumed
+	 * by the PE asynchronously, causing a race here against
+	 * the IRQ handler in closing out the handle. So, let us
+	 * make sure the IRQ can't trigger while we are collecting
+	 * the buffer. We also make sure that a WRAP event is handled
+	 * accordingly.
+	 */
+	local_irq_save(flags);
+
+	/*
+	 * If the TRBE was disabled due to lack of space in the AUX buffer or a
+	 * spurious fault, the driver leaves it disabled, truncating the buffer.
+	 * Since the etm_perf driver expects to close out the AUX buffer, the
+	 * driver skips it. Thus, just pass in 0 size here to indicate that the
+	 * buffer was truncated.
+	 */
+	if (!is_trbe_enabled()) {
+		size = 0;
+		goto done;
+	}
+	/*
+	 * perf handle structure needs to be shared with the TRBE IRQ handler for
+	 * capturing trace data and restarting the handle. There is a probability
+	 * of an undefined reference based crash when etm event is being stopped
+	 * while a TRBE IRQ also getting processed. This happens due the release
+	 * of perf handle via perf_aux_output_end() in etm_event_stop(). Stopping
+	 * the TRBE here will ensure that no IRQ could be generated when the perf
+	 * handle gets freed in etm_event_stop().
+	 */
+	trbe_drain_and_disable_local();
+	write = get_trbe_write_pointer();
+	base = get_trbe_base_pointer();
+
+	/* Check if there is a pending interrupt and handle it here */
+	status = read_sysreg_s(SYS_TRBSR_EL1);
+	if (is_trbe_irq(status)) {
+
+		/*
+		 * Now that we are handling the IRQ here, clear the IRQ
+		 * from the status, to let the irq handler know that it
+		 * is taken care of.
+		 */
+		clr_trbe_irq();
+		isb();
+
+		act = trbe_get_fault_act(status);
+		/*
+		 * If this was not due to a WRAP event, we have some
+		 * errors and as such buffer is empty.
+		 */
+		if (act != TRBE_FAULT_ACT_WRAP) {
+			size = 0;
+			goto done;
+		}
+
+		/*
+		 * Otherwise, the buffer is full and the write pointer
+		 * has reached base. Adjust this back to the Limit pointer
+		 * for correct size. Also, mark the buffer truncated.
+		 */
+		write = get_trbe_limit_pointer();
+		perf_aux_output_flag(handle, PERF_AUX_FLAG_TRUNCATED);
+	}
+
+	offset = write - base;
+	if (WARN_ON_ONCE(offset < PERF_IDX2OFF(handle->head, buf)))
+		size = 0;
+	else
+		size = offset - PERF_IDX2OFF(handle->head, buf);
+
+done:
+	local_irq_restore(flags);
+
+	if (buf->snapshot)
+		handle->head += size;
+	return size;
+}
+
+static int arm_trbe_enable(struct coresight_device *csdev, u32 mode, void *data)
+{
+	struct trbe_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
+	struct perf_output_handle *handle = data;
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+
+	WARN_ON(cpudata->cpu != smp_processor_id());
+	WARN_ON(cpudata->drvdata != drvdata);
+	if (mode != CS_MODE_PERF)
+		return -EINVAL;
+
+	*this_cpu_ptr(drvdata->handle) = handle;
+	cpudata->buf = buf;
+	cpudata->mode = mode;
+	buf->cpudata = cpudata;
+	buf->trbe_limit = compute_trbe_buffer_limit(handle);
+	buf->trbe_write = buf->trbe_base + PERF_IDX2OFF(handle->head, buf);
+	if (buf->trbe_limit == buf->trbe_base) {
+		trbe_stop_and_truncate_event(handle);
+		return 0;
+	}
+	trbe_enable_hw(buf);
+	return 0;
+}
+
+static int arm_trbe_disable(struct coresight_device *csdev)
+{
+	struct trbe_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
+	struct trbe_buf *buf = cpudata->buf;
+
+	WARN_ON(buf->cpudata != cpudata);
+	WARN_ON(cpudata->cpu != smp_processor_id());
+	WARN_ON(cpudata->drvdata != drvdata);
+	if (cpudata->mode != CS_MODE_PERF)
+		return -EINVAL;
+
+	trbe_drain_and_disable_local();
+	buf->cpudata = NULL;
+	cpudata->buf = NULL;
+	cpudata->mode = CS_MODE_DISABLED;
+	return 0;
+}
+
+static void trbe_handle_spurious(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+
+	buf->trbe_limit = compute_trbe_buffer_limit(handle);
+	buf->trbe_write = buf->trbe_base + PERF_IDX2OFF(handle->head, buf);
+	if (buf->trbe_limit == buf->trbe_base) {
+		trbe_drain_and_disable_local();
+		return;
+	}
+	trbe_enable_hw(buf);
+}
+
+static void trbe_handle_overflow(struct perf_output_handle *handle)
+{
+	struct perf_event *event = handle->event;
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+	unsigned long offset, size;
+	struct etm_event_data *event_data;
+
+	offset = get_trbe_limit_pointer() - get_trbe_base_pointer();
+	size = offset - PERF_IDX2OFF(handle->head, buf);
+	if (buf->snapshot)
+		handle->head += size;
+
+	/*
+	 * Mark the buffer as truncated, as we have stopped the trace
+	 * collection upon the WRAP event, without stopping the source.
+	 */
+	perf_aux_output_flag(handle, PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW |
+				     PERF_AUX_FLAG_TRUNCATED);
+	perf_aux_output_end(handle, size);
+	event_data = perf_aux_output_begin(handle, event);
+	if (!event_data) {
+		/*
+		 * We are unable to restart the trace collection,
+		 * thus leave the TRBE disabled. The etm-perf driver
+		 * is able to detect this with a disconnected handle
+		 * (handle->event = NULL).
+		 */
+		trbe_drain_and_disable_local();
+		*this_cpu_ptr(buf->cpudata->drvdata->handle) = NULL;
+		return;
+	}
+	buf->trbe_limit = compute_trbe_buffer_limit(handle);
+	buf->trbe_write = buf->trbe_base + PERF_IDX2OFF(handle->head, buf);
+	if (buf->trbe_limit == buf->trbe_base) {
+		trbe_stop_and_truncate_event(handle);
+		return;
+	}
+	*this_cpu_ptr(buf->cpudata->drvdata->handle) = handle;
+	trbe_enable_hw(buf);
+}
+
+static bool is_perf_trbe(struct perf_output_handle *handle)
+{
+	struct trbe_buf *buf = etm_perf_sink_config(handle);
+	struct trbe_cpudata *cpudata = buf->cpudata;
+	struct trbe_drvdata *drvdata = cpudata->drvdata;
+	int cpu = smp_processor_id();
+
+	WARN_ON(buf->trbe_base != get_trbe_base_pointer());
+	WARN_ON(buf->trbe_limit != get_trbe_limit_pointer());
+
+	if (cpudata->mode != CS_MODE_PERF)
+		return false;
+
+	if (cpudata->cpu != cpu)
+		return false;
+
+	if (!cpumask_test_cpu(cpu, &drvdata->supported_cpus))
+		return false;
+
+	return true;
+}
+
+static irqreturn_t arm_trbe_irq_handler(int irq, void *dev)
+{
+	struct perf_output_handle **handle_ptr = dev;
+	struct perf_output_handle *handle = *handle_ptr;
+	enum trbe_fault_action act;
+	u64 status;
+
+	/*
+	 * Ensure the trace is visible to the CPUs and
+	 * any external aborts have been resolved.
+	 */
+	trbe_drain_and_disable_local();
+
+	status = read_sysreg_s(SYS_TRBSR_EL1);
+	/*
+	 * If the pending IRQ was handled by update_buffer callback
+	 * we have nothing to do here.
+	 */
+	if (!is_trbe_irq(status))
+		return IRQ_NONE;
+
+	clr_trbe_irq();
+	isb();
+
+	if (WARN_ON_ONCE(!handle) || !perf_get_aux(handle))
+		return IRQ_NONE;
+
+	if (!is_perf_trbe(handle))
+		return IRQ_NONE;
+
+	/*
+	 * Ensure perf callbacks have completed, which may disable
+	 * the trace buffer in response to a TRUNCATION flag.
+	 */
+	irq_work_run();
+
+	act = trbe_get_fault_act(status);
+	switch (act) {
+	case TRBE_FAULT_ACT_WRAP:
+		trbe_handle_overflow(handle);
+		break;
+	case TRBE_FAULT_ACT_SPURIOUS:
+		trbe_handle_spurious(handle);
+		break;
+	case TRBE_FAULT_ACT_FATAL:
+		trbe_stop_and_truncate_event(handle);
+		break;
+	}
+	return IRQ_HANDLED;
+}
+
+static const struct coresight_ops_sink arm_trbe_sink_ops = {
+	.enable		= arm_trbe_enable,
+	.disable	= arm_trbe_disable,
+	.alloc_buffer	= arm_trbe_alloc_buffer,
+	.free_buffer	= arm_trbe_free_buffer,
+	.update_buffer	= arm_trbe_update_buffer,
+};
+
+static const struct coresight_ops arm_trbe_cs_ops = {
+	.sink_ops	= &arm_trbe_sink_ops,
+};
+
+static ssize_t align_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct trbe_cpudata *cpudata = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%llx\n", cpudata->trbe_align);
+}
+static DEVICE_ATTR_RO(align);
+
+static ssize_t flag_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct trbe_cpudata *cpudata = dev_get_drvdata(dev);
+
+	return sprintf(buf, "%d\n", cpudata->trbe_flag);
+}
+static DEVICE_ATTR_RO(flag);
+
+static struct attribute *arm_trbe_attrs[] = {
+	&dev_attr_align.attr,
+	&dev_attr_flag.attr,
+	NULL,
+};
+
+static const struct attribute_group arm_trbe_group = {
+	.attrs = arm_trbe_attrs,
+};
+
+static const struct attribute_group *arm_trbe_groups[] = {
+	&arm_trbe_group,
+	NULL,
+};
+
+static void arm_trbe_enable_cpu(void *info)
+{
+	struct trbe_drvdata *drvdata = info;
+
+	trbe_reset_local();
+	enable_percpu_irq(drvdata->irq, IRQ_TYPE_NONE);
+}
+
+static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cpu)
+{
+	struct trbe_cpudata *cpudata = per_cpu_ptr(drvdata->cpudata, cpu);
+	struct coresight_device *trbe_csdev = coresight_get_percpu_sink(cpu);
+	struct coresight_desc desc = { 0 };
+	struct device *dev;
+
+	if (WARN_ON(trbe_csdev))
+		return;
+
+	dev = &cpudata->drvdata->pdev->dev;
+	desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu);
+	if (IS_ERR(desc.name))
+		goto cpu_clear;
+
+	desc.type = CORESIGHT_DEV_TYPE_SINK;
+	desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM;
+	desc.ops = &arm_trbe_cs_ops;
+	desc.pdata = dev_get_platdata(dev);
+	desc.groups = arm_trbe_groups;
+	desc.dev = dev;
+	trbe_csdev = coresight_register(&desc);
+	if (IS_ERR(trbe_csdev))
+		goto cpu_clear;
+
+	dev_set_drvdata(&trbe_csdev->dev, cpudata);
+	coresight_set_percpu_sink(cpu, trbe_csdev);
+	return;
+cpu_clear:
+	cpumask_clear_cpu(cpu, &drvdata->supported_cpus);
+}
+
+static void arm_trbe_probe_cpu(void *info)
+{
+	struct trbe_drvdata *drvdata = info;
+	int cpu = smp_processor_id();
+	struct trbe_cpudata *cpudata = per_cpu_ptr(drvdata->cpudata, cpu);
+	u64 trbidr;
+
+	if (WARN_ON(!cpudata))
+		goto cpu_clear;
+
+	if (!is_trbe_available()) {
+		pr_err("TRBE is not implemented on cpu %d\n", cpu);
+		goto cpu_clear;
+	}
+
+	trbidr = read_sysreg_s(SYS_TRBIDR_EL1);
+	if (!is_trbe_programmable(trbidr)) {
+		pr_err("TRBE is owned in higher exception level on cpu %d\n", cpu);
+		goto cpu_clear;
+	}
+
+	cpudata->trbe_align = 1ULL << get_trbe_address_align(trbidr);
+	if (cpudata->trbe_align > SZ_2K) {
+		pr_err("Unsupported alignment on cpu %d\n", cpu);
+		goto cpu_clear;
+	}
+	cpudata->trbe_flag = get_trbe_flag_update(trbidr);
+	cpudata->cpu = cpu;
+	cpudata->drvdata = drvdata;
+	return;
+cpu_clear:
+	cpumask_clear_cpu(cpu, &drvdata->supported_cpus);
+}
+
+static void arm_trbe_remove_coresight_cpu(void *info)
+{
+	int cpu = smp_processor_id();
+	struct trbe_drvdata *drvdata = info;
+	struct trbe_cpudata *cpudata = per_cpu_ptr(drvdata->cpudata, cpu);
+	struct coresight_device *trbe_csdev = coresight_get_percpu_sink(cpu);
+
+	disable_percpu_irq(drvdata->irq);
+	trbe_reset_local();
+	if (trbe_csdev) {
+		coresight_unregister(trbe_csdev);
+		cpudata->drvdata = NULL;
+		coresight_set_percpu_sink(cpu, NULL);
+	}
+}
+
+static int arm_trbe_probe_coresight(struct trbe_drvdata *drvdata)
+{
+	int cpu;
+
+	drvdata->cpudata = alloc_percpu(typeof(*drvdata->cpudata));
+	if (!drvdata->cpudata)
+		return -ENOMEM;
+
+	for_each_cpu(cpu, &drvdata->supported_cpus) {
+		smp_call_function_single(cpu, arm_trbe_probe_cpu, drvdata, 1);
+		if (cpumask_test_cpu(cpu, &drvdata->supported_cpus))
+			arm_trbe_register_coresight_cpu(drvdata, cpu);
+		if (cpumask_test_cpu(cpu, &drvdata->supported_cpus))
+			smp_call_function_single(cpu, arm_trbe_enable_cpu, drvdata, 1);
+	}
+	return 0;
+}
+
+static int arm_trbe_remove_coresight(struct trbe_drvdata *drvdata)
+{
+	int cpu;
+
+	for_each_cpu(cpu, &drvdata->supported_cpus)
+		smp_call_function_single(cpu, arm_trbe_remove_coresight_cpu, drvdata, 1);
+	free_percpu(drvdata->cpudata);
+	return 0;
+}
+
+static int arm_trbe_cpu_startup(unsigned int cpu, struct hlist_node *node)
+{
+	struct trbe_drvdata *drvdata = hlist_entry_safe(node, struct trbe_drvdata, hotplug_node);
+
+	if (cpumask_test_cpu(cpu, &drvdata->supported_cpus)) {
+
+		/*
+		 * If this CPU was not probed for TRBE,
+		 * initialize it now.
+		 */
+		if (!coresight_get_percpu_sink(cpu)) {
+			arm_trbe_probe_cpu(drvdata);
+			if (cpumask_test_cpu(cpu, &drvdata->supported_cpus))
+				arm_trbe_register_coresight_cpu(drvdata, cpu);
+			if (cpumask_test_cpu(cpu, &drvdata->supported_cpus))
+				arm_trbe_enable_cpu(drvdata);
+		} else {
+			arm_trbe_enable_cpu(drvdata);
+		}
+	}
+	return 0;
+}
+
+static int arm_trbe_cpu_teardown(unsigned int cpu, struct hlist_node *node)
+{
+	struct trbe_drvdata *drvdata = hlist_entry_safe(node, struct trbe_drvdata, hotplug_node);
+
+	if (cpumask_test_cpu(cpu, &drvdata->supported_cpus)) {
+		disable_percpu_irq(drvdata->irq);
+		trbe_reset_local();
+	}
+	return 0;
+}
+
+static int arm_trbe_probe_cpuhp(struct trbe_drvdata *drvdata)
+{
+	enum cpuhp_state trbe_online;
+	int ret;
+
+	trbe_online = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, DRVNAME,
+					      arm_trbe_cpu_startup, arm_trbe_cpu_teardown);
+	if (trbe_online < 0)
+		return trbe_online;
+
+	ret = cpuhp_state_add_instance(trbe_online, &drvdata->hotplug_node);
+	if (ret) {
+		cpuhp_remove_multi_state(trbe_online);
+		return ret;
+	}
+	drvdata->trbe_online = trbe_online;
+	return 0;
+}
+
+static void arm_trbe_remove_cpuhp(struct trbe_drvdata *drvdata)
+{
+	cpuhp_remove_multi_state(drvdata->trbe_online);
+}
+
+static int arm_trbe_probe_irq(struct platform_device *pdev,
+			      struct trbe_drvdata *drvdata)
+{
+	int ret;
+
+	drvdata->irq = platform_get_irq(pdev, 0);
+	if (drvdata->irq < 0) {
+		pr_err("IRQ not found for the platform device\n");
+		return drvdata->irq;
+	}
+
+	if (!irq_is_percpu(drvdata->irq)) {
+		pr_err("IRQ is not a PPI\n");
+		return -EINVAL;
+	}
+
+	if (irq_get_percpu_devid_partition(drvdata->irq, &drvdata->supported_cpus))
+		return -EINVAL;
+
+	drvdata->handle = alloc_percpu(struct perf_output_handle *);
+	if (!drvdata->handle)
+		return -ENOMEM;
+
+	ret = request_percpu_irq(drvdata->irq, arm_trbe_irq_handler, DRVNAME, drvdata->handle);
+	if (ret) {
+		free_percpu(drvdata->handle);
+		return ret;
+	}
+	return 0;
+}
+
+static void arm_trbe_remove_irq(struct trbe_drvdata *drvdata)
+{
+	free_percpu_irq(drvdata->irq, drvdata->handle);
+	free_percpu(drvdata->handle);
+}
+
+static int arm_trbe_device_probe(struct platform_device *pdev)
+{
+	struct coresight_platform_data *pdata;
+	struct trbe_drvdata *drvdata;
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	pdata = coresight_get_platform_data(dev);
+	if (IS_ERR(pdata))
+		return PTR_ERR(pdata);
+
+	dev_set_drvdata(dev, drvdata);
+	dev->platform_data = pdata;
+	drvdata->pdev = pdev;
+	ret = arm_trbe_probe_irq(pdev, drvdata);
+	if (ret)
+		return ret;
+
+	ret = arm_trbe_probe_coresight(drvdata);
+	if (ret)
+		goto probe_failed;
+
+	ret = arm_trbe_probe_cpuhp(drvdata);
+	if (ret)
+		goto cpuhp_failed;
+
+	return 0;
+cpuhp_failed:
+	arm_trbe_remove_coresight(drvdata);
+probe_failed:
+	arm_trbe_remove_irq(drvdata);
+	return ret;
+}
+
+static int arm_trbe_device_remove(struct platform_device *pdev)
+{
+	struct trbe_drvdata *drvdata = platform_get_drvdata(pdev);
+
+	arm_trbe_remove_cpuhp(drvdata);
+	arm_trbe_remove_coresight(drvdata);
+	arm_trbe_remove_irq(drvdata);
+	return 0;
+}
+
+static const struct of_device_id arm_trbe_of_match[] = {
+	{ .compatible = "arm,trace-buffer-extension"},
+	{},
+};
+MODULE_DEVICE_TABLE(of, arm_trbe_of_match);
+
+static struct platform_driver arm_trbe_driver = {
+	.driver	= {
+		.name = DRVNAME,
+		.of_match_table = of_match_ptr(arm_trbe_of_match),
+		.suppress_bind_attrs = true,
+	},
+	.probe	= arm_trbe_device_probe,
+	.remove	= arm_trbe_device_remove,
+};
+
+static int __init arm_trbe_init(void)
+{
+	int ret;
+
+	if (arm64_kernel_unmapped_at_el0()) {
+		pr_err("TRBE wouldn't work if kernel gets unmapped at EL0\n");
+		return -EOPNOTSUPP;
+	}
+
+	ret = platform_driver_register(&arm_trbe_driver);
+	if (!ret)
+		return 0;
+
+	pr_err("Error registering %s platform driver\n", DRVNAME);
+	return ret;
+}
+
+static void __exit arm_trbe_exit(void)
+{
+	platform_driver_unregister(&arm_trbe_driver);
+}
+module_init(arm_trbe_init);
+module_exit(arm_trbe_exit);
+
+MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual at arm.com>");
+MODULE_DESCRIPTION("Arm Trace Buffer Extension (TRBE) driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/coresight-trbe.h b/drivers/hwtracing/coresight/coresight-trbe.h
new file mode 100644
index 000000000000..abf3e36082f0
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-trbe.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This contains all required hardware related helper functions for
+ * Trace Buffer Extension (TRBE) driver in the coresight framework.
+ *
+ * Copyright (C) 2020 ARM Ltd.
+ *
+ * Author: Anshuman Khandual <anshuman.khandual at arm.com>
+ */
+#include <linux/coresight.h>
+#include <linux/device.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/smp.h>
+
+#include "coresight-etm-perf.h"
+
+static inline bool is_trbe_available(void)
+{
+	u64 aa64dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1);
+	unsigned int trbe = cpuid_feature_extract_unsigned_field(aa64dfr0, ID_AA64DFR0_TRBE_SHIFT);
+
+	return trbe >= 0b0001;
+}
+
+static inline bool is_trbe_enabled(void)
+{
+	u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+
+	return trblimitr & TRBLIMITR_ENABLE;
+}
+
+#define TRBE_EC_OTHERS		0
+#define TRBE_EC_STAGE1_ABORT	36
+#define TRBE_EC_STAGE2_ABORT	37
+
+static inline int get_trbe_ec(u64 trbsr)
+{
+	return (trbsr >> TRBSR_EC_SHIFT) & TRBSR_EC_MASK;
+}
+
+#define TRBE_BSC_NOT_STOPPED 0
+#define TRBE_BSC_FILLED      1
+#define TRBE_BSC_TRIGGERED   2
+
+static inline int get_trbe_bsc(u64 trbsr)
+{
+	return (trbsr >> TRBSR_BSC_SHIFT) & TRBSR_BSC_MASK;
+}
+
+static inline void clr_trbe_irq(void)
+{
+	u64 trbsr = read_sysreg_s(SYS_TRBSR_EL1);
+
+	trbsr &= ~TRBSR_IRQ;
+	write_sysreg_s(trbsr, SYS_TRBSR_EL1);
+}
+
+static inline bool is_trbe_irq(u64 trbsr)
+{
+	return trbsr & TRBSR_IRQ;
+}
+
+static inline bool is_trbe_trg(u64 trbsr)
+{
+	return trbsr & TRBSR_TRG;
+}
+
+static inline bool is_trbe_wrap(u64 trbsr)
+{
+	return trbsr & TRBSR_WRAP;
+}
+
+static inline bool is_trbe_abort(u64 trbsr)
+{
+	return trbsr & TRBSR_ABORT;
+}
+
+static inline bool is_trbe_running(u64 trbsr)
+{
+	return !(trbsr & TRBSR_STOP);
+}
+
+#define TRBE_TRIG_MODE_STOP		0
+#define TRBE_TRIG_MODE_IRQ		1
+#define TRBE_TRIG_MODE_IGNORE		3
+
+#define TRBE_FILL_MODE_FILL		0
+#define TRBE_FILL_MODE_WRAP		1
+#define TRBE_FILL_MODE_CIRCULAR_BUFFER	3
+
+static inline void set_trbe_disabled(void)
+{
+	u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+
+	trblimitr &= ~TRBLIMITR_ENABLE;
+	write_sysreg_s(trblimitr, SYS_TRBLIMITR_EL1);
+}
+
+static inline bool get_trbe_flag_update(u64 trbidr)
+{
+	return trbidr & TRBIDR_FLAG;
+}
+
+static inline bool is_trbe_programmable(u64 trbidr)
+{
+	return !(trbidr & TRBIDR_PROG);
+}
+
+static inline int get_trbe_address_align(u64 trbidr)
+{
+	return (trbidr >> TRBIDR_ALIGN_SHIFT) & TRBIDR_ALIGN_MASK;
+}
+
+static inline unsigned long get_trbe_write_pointer(void)
+{
+	return read_sysreg_s(SYS_TRBPTR_EL1);
+}
+
+static inline void set_trbe_write_pointer(unsigned long addr)
+{
+	WARN_ON(is_trbe_enabled());
+	write_sysreg_s(addr, SYS_TRBPTR_EL1);
+}
+
+static inline unsigned long get_trbe_limit_pointer(void)
+{
+	u64 trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
+	unsigned long addr = trblimitr & (TRBLIMITR_LIMIT_MASK << TRBLIMITR_LIMIT_SHIFT);
+
+	WARN_ON(!IS_ALIGNED(addr, PAGE_SIZE));
+	return addr;
+}
+
+static inline unsigned long get_trbe_base_pointer(void)
+{
+	u64 trbbaser = read_sysreg_s(SYS_TRBBASER_EL1);
+	unsigned long addr = trbbaser & (TRBBASER_BASE_MASK << TRBBASER_BASE_SHIFT);
+
+	WARN_ON(!IS_ALIGNED(addr, PAGE_SIZE));
+	return addr;
+}
+
+static inline void set_trbe_base_pointer(unsigned long addr)
+{
+	WARN_ON(is_trbe_enabled());
+	WARN_ON(!IS_ALIGNED(addr, (1UL << TRBBASER_BASE_SHIFT)));
+	WARN_ON(!IS_ALIGNED(addr, PAGE_SIZE));
+	write_sysreg_s(addr, SYS_TRBBASER_EL1);
+}
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:06 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:06 +0100
Subject: [PATCH v6 19/20] Documentation: trace: Add documentation for TRBE
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-20-suzuki.poulose@arm.com>

From: Anshuman Khandual <anshuman.khandual at arm.com>

Add documentation for the  TRBE under trace/coresight.

Cc: Jonathan Corbet <corbet at lwn.net>
Cc: linux-doc at vger.kernel.org
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
[ Split from the TRBE driver patch ]
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../trace/coresight/coresight-trbe.rst        | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/trace/coresight/coresight-trbe.rst

diff --git a/Documentation/trace/coresight/coresight-trbe.rst b/Documentation/trace/coresight/coresight-trbe.rst
new file mode 100644
index 000000000000..b9928ef148da
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-trbe.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================
+Trace Buffer Extension (TRBE).
+==============================
+
+    :Author:   Anshuman Khandual <anshuman.khandual at arm.com>
+    :Date:     November 2020
+
+Hardware Description
+--------------------
+
+Trace Buffer Extension (TRBE) is a percpu hardware which captures in system
+memory, CPU traces generated from a corresponding percpu tracing unit. This
+gets plugged in as a coresight sink device because the corresponding trace
+generators (ETE), are plugged in as source device.
+
+The TRBE is not compliant to CoreSight architecture specifications, but is
+driven via the CoreSight driver framework to support the ETE (which is
+CoreSight compliant) integration.
+
+Sysfs files and directories
+---------------------------
+
+The TRBE devices appear on the existing coresight bus alongside the other
+coresight devices::
+
+	>$ ls /sys/bus/coresight/devices
+	trbe0  trbe1  trbe2 trbe3
+
+The ``trbe<N>`` named TRBEs are associated with a CPU.::
+
+	>$ ls /sys/bus/coresight/devices/trbe0/
+        align flag
+
+*Key file items are:-*
+   * ``align``: TRBE write pointer alignment
+   * ``flag``: TRBE updates memory with access and dirty flags
-- 
2.24.1



From suzuki.poulose at arm.com  Mon Apr  5 17:43:07 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon,  5 Apr 2021 17:43:07 +0100
Subject: [PATCH v6 20/20] dts: bindings: Document device tree bindings for Arm
 TRBE
In-Reply-To: <20210405164307.1720226-1-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
Message-ID: <20210405164307.1720226-21-suzuki.poulose@arm.com>

Document the device tree bindings for Trace Buffer Extension (TRBE).

Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Rob Herring <robh at kernel.org>
Cc: devicetree at vger.kernel.org
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 .../devicetree/bindings/arm/trbe.yaml         | 49 +++++++++++++++++++
 MAINTAINERS                                   |  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml

diff --git a/Documentation/devicetree/bindings/arm/trbe.yaml b/Documentation/devicetree/bindings/arm/trbe.yaml
new file mode 100644
index 000000000000..4402d7bfd1fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/trbe.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+# Copyright 2021, Arm Ltd
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/trbe.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: ARM Trace Buffer Extensions
+
+maintainers:
+  - Anshuman Khandual <anshuman.khandual at arm.com>
+
+description: |
+  Arm Trace Buffer Extension (TRBE) is a per CPU component
+  for storing trace generated on the CPU to memory. It is
+  accessed via CPU system registers. The software can verify
+  if it is permitted to use the component by checking the
+  TRBIDR register.
+
+properties:
+  $nodename:
+    const: "trbe"
+  compatible:
+    items:
+      - const: arm,trace-buffer-extension
+
+  interrupts:
+    description: |
+       Exactly 1 PPI must be listed. For heterogeneous systems where
+       TRBE is only supported on a subset of the CPUs, please consult
+       the arm,gic-v3 binding for details on describing a PPI partition.
+    maxItems: 1
+
+required:
+  - compatible
+  - interrupts
+
+additionalProperties: false
+
+examples:
+
+  - |
+   #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+   trbe {
+     compatible = "arm,trace-buffer-extension";
+     interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
+   };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a20a36c724a..471d04bb2d5e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1762,6 +1762,7 @@ F:	Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
 F:	Documentation/devicetree/bindings/arm/coresight-cti.yaml
 F:	Documentation/devicetree/bindings/arm/coresight.txt
 F:	Documentation/devicetree/bindings/arm/ete.yaml
+F:	Documentation/devicetree/bindings/arm/trbe.yaml
 F:	Documentation/trace/coresight/*
 F:	drivers/hwtracing/coresight/*
 F:	include/dt-bindings/arm/coresight-cti-dt.h
-- 
2.24.1



From madvenka at linux.microsoft.com  Mon Apr  5 18:12:08 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 5 Apr 2021 12:12:08 -0500
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
 <20210405222436.4fda9a930676d95e862744af@kernel.org>
 <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>
Message-ID: <380d0437-e205-5eab-3664-f17aa9adc3eb@linux.microsoft.com>



On 4/5/21 9:56 AM, Madhavan T. Venkataraman wrote:
> 
> 
> On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
>> Hi Madhaven,
>>
>> On Sat, 3 Apr 2021 22:29:12 -0500
>> "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:
>>
>>
>>>>> Check for kretprobe
>>>>> ===================
>>>>>
>>>>> For functions with a kretprobe set up, probe code executes on entry
>>>>> to the function and replaces the return address in the stack frame with a
>>>>> kretprobe trampoline. Whenever the function returns, control is
>>>>> transferred to the trampoline. The trampoline eventually returns to the
>>>>> original return address.
>>>>>
>>>>> A stack trace taken while executing in the function (or in functions that
>>>>> get called from the function) will not show the original return address.
>>>>> Similarly, a stack trace taken while executing in the trampoline itself
>>>>> (and functions that get called from the trampoline) will not show the
>>>>> original return address. This means that the caller of the probed function
>>>>> will not show. This makes the stack trace unreliable.
>>>>>
>>>>> Add the kretprobe trampoline to special_functions[].
>>>>>
>>>>> FYI, each task contains a task->kretprobe_instances list that can
>>>>> theoretically be consulted to find the orginal return address. But I am
>>>>> not entirely sure how to safely traverse that list for stack traces
>>>>> not on the current process. So, I have taken the easy way out.
>>>>
>>>> For kretprobes, unwinding from the trampoline or kretprobe handler
>>>> shouldn't be a reliability concern for live patching, for similar
>>>> reasons as above.
>>>>
>>>
>>> Please see previous answer.
>>>
>>>> Otherwise, when unwinding from a blocked task which has
>>>> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
>>>> original return address.  Masami has been working on an interface to
>>>> make that possible for x86.  I assume something similar could be done
>>>> for arm64.
>>>>
>>>
>>> OK. Until that is available, this case needs to be addressed.
>>
>> Actually, I've done that on arm64 :) See below patch.
>> (and I also have a similar code for arm32, what I'm considering is how
>> to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
>> similar.)
>>
>> This is applicable on my x86 series v5
>>
>> https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/
>>
>> Thank you,
>>
>>
> 
> I took a brief look at your changes. Looks reasonable.
> 
> However, for now, I am going to include the kretprobe_trampoline in the special_functions[]
> array until your changes are merged. At that point, it is just a matter of deleting
> kretprobe_trampoline from the special_functions[] array. That is all.
> 
> I hope that is fine with everyone.
> 

Actually, there may still be a problem to solve.

If arch_stack_walk_reliable() is ever called from within kretprobe_trampoline() for debugging or
other purposes after the instance is deleted from the task instance list, it would not be able
to retrieve the original return address.

The stack trace would be unreliable in that case, would it not?

Madhavan



From j.neuschaefer at gmx.net  Mon Apr  5 18:25:54 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Mon, 5 Apr 2021 19:25:54 +0200
Subject: [PATCH 08/14] irqchip: Add driver for WPCM450 interrupt controller
In-Reply-To: <YF4tV+L71Lso94kT@latitude>
References: <20210320181610.680870-1-j.neuschaefer@gmx.net>
 <20210320181610.680870-9-j.neuschaefer@gmx.net>
 <87sg4kiia4.wl-maz@kernel.org> <YF4tV+L71Lso94kT@latitude>
Message-ID: <YGtIItromiJcS+D5@latitude>

On Fri, Mar 26, 2021 at 07:52:07PM +0100, Jonathan Neusch?fer wrote:
> On Wed, Mar 24, 2021 at 05:16:35PM +0000, Marc Zyngier wrote:
> > On Sat, 20 Mar 2021 18:16:04 +0000, Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
[...]
> > > +	/* Disable (mask) all interrupts */
> > > +	writel(0xffffffff, aic->regs + AIC_MDCR);
> > 
> > Consider using relaxed accessors throughout this driver.
> 
> I'll read up on how to use them correctly.

Upon further consideration, I decided not to bother with relaxed MMIO
access, because it doesn't make a difference on the target platform ?
Nuvoton WPCM450 with ARM926 (ARMv5).


Best regards,
Jonathan Neusch?fer
-------------- 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/20210405/b178a0a7/attachment.sig>

From fparent at baylibre.com  Mon Apr  5 18:28:36 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 19:28:36 +0200
Subject: [PATCH] arm64: dts: mediatek: mt8167: add power domains
Message-ID: <20210405172836.2038526-1-fparent@baylibre.com>

Add support for the MT8167 power domains.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 68 ++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 1c5639ead622..156fbdad01fb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -7,6 +7,7 @@
 
 #include <dt-bindings/clock/mt8167-clk.h>
 #include <dt-bindings/memory/mt8167-larb-port.h>
+#include <dt-bindings/power/mt8167-power.h>
 
 #include "mt8167-pinfunc.h"
 
@@ -34,6 +35,73 @@ apmixedsys: apmixedsys at 10018000 {
 			#clock-cells = <1>;
 		};
 
+		scpsys: syscon at 10006000 {
+			compatible = "syscon", "simple-mfd";
+			reg = <0 0x10006000 0 0x1000>;
+			#power-domain-cells = <1>;
+
+			spm: power-controller {
+				compatible = "mediatek,mt8167-power-controller";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				#power-domain-cells = <1>;
+
+				/* power domains of the SoC */
+				power-domain at MT8167_POWER_DOMAIN_MM {
+					reg = <MT8167_POWER_DOMAIN_MM>;
+					clocks = <&topckgen CLK_TOP_SMI_MM>;
+					clock-names = "mm";
+					#power-domain-cells = <0>;
+					mediatek,infracfg = <&infracfg>;
+				};
+
+				power-domain at MT8167_POWER_DOMAIN_VDEC {
+					reg = <MT8167_POWER_DOMAIN_VDEC>;
+					clocks = <&topckgen CLK_TOP_SMI_MM>,
+						 <&topckgen CLK_TOP_RG_VDEC>;
+					clock-names = "mm", "vdec";
+					#power-domain-cells = <0>;
+				};
+
+				power-domain at MT8167_POWER_DOMAIN_ISP {
+					reg = <MT8167_POWER_DOMAIN_ISP>;
+					clocks = <&topckgen CLK_TOP_SMI_MM>;
+					clock-names = "mm";
+					#power-domain-cells = <0>;
+				};
+
+				power-domain at MT8167_POWER_DOMAIN_MFG_ASYNC {
+					reg = <MT8167_POWER_DOMAIN_MFG_ASYNC>;
+					clocks = <&topckgen CLK_TOP_RG_AXI_MFG>,
+						 <&topckgen CLK_TOP_RG_SLOW_MFG>;
+					clock-names = "axi_mfg", "mfg";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					#power-domain-cells = <1>;
+					mediatek,infracfg = <&infracfg>;
+
+					power-domain at MT8167_POWER_DOMAIN_MFG_2D {
+						reg = <MT8167_POWER_DOMAIN_MFG_2D>;
+						#address-cells = <1>;
+						#size-cells = <0>;
+						#power-domain-cells = <1>;
+
+						power-domain at MT8167_POWER_DOMAIN_MFG {
+							reg = <MT8167_POWER_DOMAIN_MFG>;
+							#power-domain-cells = <0>;
+							mediatek,infracfg = <&infracfg>;
+						};
+					};
+				};
+
+				power-domain at MT8167_POWER_DOMAIN_CONN {
+					reg = <MT8167_POWER_DOMAIN_CONN>;
+					#power-domain-cells = <0>;
+					mediatek,infracfg = <&infracfg>;
+				};
+			};
+		};
+
 		imgsys: syscon at 15000000 {
 			compatible = "mediatek,mt8167-imgsys", "syscon";
 			reg = <0 0x15000000 0 0x1000>;
-- 
2.31.0



From mikelley at microsoft.com  Mon Apr  5 18:45:52 2021
From: mikelley at microsoft.com (Michael Kelley)
Date: Mon, 5 Apr 2021 17:45:52 +0000
Subject: [PATCH v9 0/7] Enable Linux guests on Hyper-V on ARM64
In-Reply-To: <MWHPR21MB1593E68A0032D7344A42BD0DD7639@MWHPR21MB1593.namprd21.prod.outlook.com>
References: <1615233439-23346-1-git-send-email-mikelley@microsoft.com>
 <MWHPR21MB1593E68A0032D7344A42BD0DD7639@MWHPR21MB1593.namprd21.prod.outlook.com>
Message-ID: <MWHPR21MB1593C7CFE86E45374FCB4839D7779@MWHPR21MB1593.namprd21.prod.outlook.com>

From: Michael Kelley <mikelley at microsoft.com>
> Sent: Wednesday, March 24, 2021 8:55 AM
> To: will at kernel.org; catalin.marinas at arm.com; Mark Rutland <Mark.Rutland at arm.com>;
> lorenzo.pieralisi at arm.com; sudeep.holla at arm.com
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> hyperv at vger.kernel.org; linux-efi at vger.kernel.org; arnd at arndb.de; wei.liu at kernel.org;
> ardb at kernel.org; daniel.lezcano at linaro.org; KY Srinivasan <kys at microsoft.com>
> Subject: RE: [PATCH v9 0/7] Enable Linux guests on Hyper-V on ARM64
> 
> From: Michael Kelley <mikelley at microsoft.com> Sent: Monday, March 8, 2021 11:57 AM
> >
> > This series enables Linux guests running on Hyper-V on ARM64
> > hardware. New ARM64-specific code in arch/arm64/hyperv initializes
> > Hyper-V, including its interrupts and hypercall mechanism.
> > Existing architecture independent drivers for Hyper-V's VMbus and
> > synthetic devices just work when built for ARM64. Hyper-V code is
> > built and included in the image and modules only if CONFIG_HYPERV
> > is enabled.
> 
> ARM64 maintainers --
> 
> What are the prospects for getting your review and Ack on this patch set?
> We're wanting to get the Hyper-V support on ARM64 finally accepted upstream.
> Previous comments should be addressed in this revision, with perhaps a
> remaining discussion point around the alternate SMCCC hypercall interface
> in Patch 1 that makes use of changes in v1.2 of the SMCCC spec.  There are
> several viable approaches that I've noted in the patch, depending on
> your preferences.
> 
> Michael

Thanks, Mark, for jumping in on the SMCCC hypercall interface.  But I'm still
looking for feedback or ACKs on the other patches in the series.  There's only
one place in Patch 2 of the series that needs the SMCCC v1.2 interface, and I'd
like to be able to respond to any remaining issues with the other patches
while the SMCCC details are finished up.

Michael


From vee.khee.wong at intel.com  Mon Apr  5 19:06:16 2021
From: vee.khee.wong at intel.com (Wong, Vee Khee)
Date: Mon, 5 Apr 2021 18:06:16 +0000
Subject: [PATCH net-next] net: intel: Enable SERDES PHY rx clk for PSE
In-Reply-To: <20210405163357.30902-1-weifeng.voon@intel.com>
References: <20210405163357.30902-1-weifeng.voon@intel.com>
Message-ID: <BYAPR11MB28702C161D1C95E0D5C3A64AAB779@BYAPR11MB2870.namprd11.prod.outlook.com>

On Tue, Apr 06, 2021 at 12:33:57AM +0800, Voon Weifeng wrote: 
>
> EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
> sequence and vice versa.
> 
> Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 10 ++++++++++
>  drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h |  1 +
>  2 files changed, 11 insertions(+)
> 

Why not use "stmmac: intel" for the commit message header?


> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index add95e20548d..a4fec5fe0779 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -153,6 +153,11 @@ static int intel_serdes_powerup(struct net_device
> *ndev, void *priv_data)
>  		return data;
>  	}
> 
> +	/* PSE only - ungate SGMII PHY Rx Clock */
> +	if (intel_priv->is_pse)
> +		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
> +			       0, SERDES_PHY_RX_CLK);
> +
>  	return 0;
>  }
> 
> @@ -168,6 +173,11 @@ static void intel_serdes_powerdown(struct
> net_device *ndev, void *intel_data)
> 
>  	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
> 
> +	/* PSE only - gate SGMII PHY Rx Clock */
> +	if (intel_priv->is_pse)
> +		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
> +			       SERDES_PHY_RX_CLK, 0);
> +
>  	/*  move power state to P3 */
>  	data = mdiobus_read(priv->mii, serdes_phy_addr, SERDES_GCR0);
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
> index e723096c0b15..542acb8ce467 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
> @@ -14,6 +14,7 @@
> 
>  /* SERDES defines */
>  #define SERDES_PLL_CLK		BIT(0)		/* PLL clk valid signal
> */
> +#define SERDES_PHY_RX_CLK	BIT(1)		/* PSE SGMII PHY rx clk */
>  #define SERDES_RST		BIT(2)		/* Serdes Reset */
>  #define SERDES_PWR_ST_MASK	GENMASK(6, 4)	/* Serdes Power
> state*/
>  #define SERDES_PWR_ST_SHIFT	4
> --
> 2.17.1



From krzysztof.kozlowski at canonical.com  Mon Apr  5 19:14:05 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon,  5 Apr 2021 20:14:05 +0200
Subject: [PATCH] i2c: exynos5: correct top kerneldoc
Message-ID: <20210405181405.52189-1-krzysztof.kozlowski@canonical.com>

The top comment is not a kerneldoc, as W=1 build reports:

  drivers/i2c/busses/i2c-exynos5.c:39: warning:
    expecting prototype for i2c(). Prototype was for HSI2C_CTL() instead

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/i2c/busses/i2c-exynos5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 5ac30d95650c..97d4f3ac0abd 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
  * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
  *
  * Copyright (C) 2013 Samsung Electronics Co., Ltd.
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Mon Apr  5 19:15:24 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon,  5 Apr 2021 20:15:24 +0200
Subject: [PATCH] drm/exynos: correct exynos_drm_fimd kerneldoc
Message-ID: <20210405181524.52426-1-krzysztof.kozlowski@canonical.com>

Correct the kerneldoc of fimd_shadow_protect_win() to fix W=1 warnings:

  drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning:
    expecting prototype for shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 49a2e0c53918..ae576122873e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -723,7 +723,7 @@ static void fimd_win_set_colkey(struct fimd_context *ctx, unsigned int win)
 }
 
 /**
- * shadow_protect_win() - disable updating values from shadow registers at vsync
+ * fimd_shadow_protect_win() - disable updating values from shadow registers at vsync
  *
  * @ctx: local driver data
  * @win: window to protect registers for
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Mon Apr  5 19:16:05 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon,  5 Apr 2021 20:16:05 +0200
Subject: [PATCH] ARM: exynos: correct kernel doc in platsmp
Message-ID: <20210405181605.52612-1-krzysztof.kozlowski@canonical.com>

Correct few kerneldoc issues, including W=1 compile warning:

  arch/arm/mach-exynos/platsmp.c:89: warning:
    expecting prototype for exynos_core_power_down(). Prototype was for exynos_cpu_power_down() instead

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/mach-exynos/platsmp.c | 28 +++++++++++++---------------
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index ea0be59f469a..fb4a394ece3a 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -78,12 +78,11 @@ static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
 #endif /* CONFIG_HOTPLUG_CPU */
 
 /**
- * exynos_core_power_down : power down the specified cpu
- * @cpu : the cpu to power down
+ * exynos_cpu_power_down() - power down the specified cpu
+ * @cpu: the cpu to power down
  *
  * Power down the specified cpu. The sequence must be finished by a
  * call to cpu_do_idle()
- *
  */
 void exynos_cpu_power_down(int cpu)
 {
@@ -107,8 +106,8 @@ void exynos_cpu_power_down(int cpu)
 }
 
 /**
- * exynos_cpu_power_up : power up the specified cpu
- * @cpu : the cpu to power up
+ * exynos_cpu_power_up() - power up the specified cpu
+ * @cpu: the cpu to power up
  *
  * Power up the specified cpu
  */
@@ -124,9 +123,8 @@ void exynos_cpu_power_up(int cpu)
 }
 
 /**
- * exynos_cpu_power_state : returns the power state of the cpu
- * @cpu : the cpu to retrieve the power state from
- *
+ * exynos_cpu_power_state() - returns the power state of the cpu
+ * @cpu: the cpu to retrieve the power state from
  */
 int exynos_cpu_power_state(int cpu)
 {
@@ -135,8 +133,8 @@ int exynos_cpu_power_state(int cpu)
 }
 
 /**
- * exynos_cluster_power_down : power down the specified cluster
- * @cluster : the cluster to power down
+ * exynos_cluster_power_down() - power down the specified cluster
+ * @cluster: the cluster to power down
  */
 void exynos_cluster_power_down(int cluster)
 {
@@ -144,8 +142,8 @@ void exynos_cluster_power_down(int cluster)
 }
 
 /**
- * exynos_cluster_power_up : power up the specified cluster
- * @cluster : the cluster to power up
+ * exynos_cluster_power_up() - power up the specified cluster
+ * @cluster: the cluster to power up
  */
 void exynos_cluster_power_up(int cluster)
 {
@@ -154,8 +152,8 @@ void exynos_cluster_power_up(int cluster)
 }
 
 /**
- * exynos_cluster_power_state : returns the power state of the cluster
- * @cluster : the cluster to retrieve the power state from
+ * exynos_cluster_power_state() - returns the power state of the cluster
+ * @cluster: the cluster to retrieve the power state from
  *
  */
 int exynos_cluster_power_state(int cluster)
@@ -165,7 +163,7 @@ int exynos_cluster_power_state(int cluster)
 }
 
 /**
- * exynos_scu_enable : enables SCU for Cortex-A9 based system
+ * exynos_scu_enable() - enables SCU for Cortex-A9 based system
  */
 void exynos_scu_enable(void)
 {
-- 
2.25.1



From clabbe.montjoie at gmail.com  Mon Apr  5 19:39:54 2021
From: clabbe.montjoie at gmail.com (Corentin Labbe)
Date: Mon, 5 Apr 2021 20:39:54 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
Message-ID: <YGtZeofmBv7hXK+a@Red>

Hello

I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.

I successfully upgraded it with a recent Linux.
The DTB I use is the following:
/dts-v1/;
#include "gemini.dtsi"
#include <dt-bindings/input/input.h>
/ {
	model = "Edimax NS-2502";
	compatible = "edimax,ns-2502", "cortina,gemini";
	#address-cells = <1>;
	#size-cells = <1>;
	memory at 0 {
		/* 128 MB */
		device_type = "memory";
		reg = <0x00000000 0x8000000>;
	};
	chosen {
		bootargs = "console=ttyS0,19200n8";
		stdout-path = &uart0;
	};
	mdio0: ethernet-phy {
		compatible = "virtual,mdio-gpio";
		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
		#address-cells = <1>;
		#size-cells = <0>;
		phy0: ethernet-phy at 1 {
			reg = <1>;
			device_type = "ethernet-phy";
		};
	};
	soc {
		flash at 30000000 {
			status = "okay";
			/* 8MB of flash */
			reg = <0x30000000 0x00800000>;
			partition at 0 {
				label = "RedBoot";
				reg = <0x00000000 0x00020000>;
				read-only;
			};
			partition at 20000 {
				label = "kernel";
				reg = <0x00020000 0x00700000>;
			};
			partition at 720000 {
				label = "VCTL";
				reg = <0x00720000 0x00020000>;
				read-only;
			};
			partition at 740000 {
				label = "CurConf";
				reg = <0x00740000 0x000a0000>;
				read-only;
			};
			partition at 7e0000 {
				label = "FIS";
				reg = <0x007e0000 0x00010000>;
				read-only;
			};
		};
		syscon: syscon at 40000000 {
			pinctrl {
				/*
				 * gpio0agrp cover line 0-4
				 * gpio0bgrp cover line 5
				 */
				gpio0_default_pins: pinctrl-gpio0 {
					mux {
						function = "gpio0";
						groups = "gpio0agrp",
						"gpio0bgrp";
					};
				};
			};
		};
		gpio0: gpio at 4d000000 {
			pinctrl-names = "default";
			pinctrl-0 = <&gpio0_default_pins>;
		};
		ethernet at 60000000 {
			status = "okay";
			ethernet-port at 0 {
				phy-mode = "rgmii";
				phy-handle = <&phy0>;
			};
			ethernet-port at 1 {
				/* Not used in this platform */
			};
		};
		usb at 68000000 {
			status = "okay";
		};
		usb at 69000000 {
			status = "okay";
		};
	};
};

This is a bit of copy paste of other DTB.
With it I boot successfully to a shell.

BUT neither ethernet nor USB works.
This is the bootlog:
Flash Block Size = 65536

Storlink SL351x Boot Loader [Linux], version 1.0.9
Built by linux, 10:50:46, Aug  6 2008

Processor: SL3516c2
CPU Rate: 300000000
AHB Bus Clock:150MHz    Ratio:2/1
MAC 1 Address: 00:00:25:02:00:00
MAC 2 Address: 00:01:25:02:00:00
inet addr: 192.168.1.237/255.255.255.0
==> enter ^C to abort booting within 2 seconds ......
Load Kern image from 0x30020000 to 0x800000 size 7340032
Booting Linux on physical CPU 0x0
Linux version 5.12.0-rc5-next-20210401+ (compile at Red) (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r2 p4) 9.3.0, GNU ld (Gentoo 2.34 p6) 2.34.0) #47 PREEMPT Mon Apr 5 20:20:27 CEST 2021
CPU: FA526 [66015261] revision 1 (ARMv4), cr=0000397f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: Edimax NS-2502
Memory policy: Data cache writeback
Zone ranges:
  Normal   [mem 0x0000000000000000-0x0000000007ffffff]
  HighMem  empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
Built 1 zonelists, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS0,19200n8
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 119300K/131072K available (4922K kernel code, 577K rwdata, 1344K rodata, 3340K init, 212K bss, 11772K reserved, 0K cma-reserved, 0K highmem)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Preemptible hierarchical RCU implementation.
        Trampoline variant of Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
random: get_random_bytes called from start_kernel+0x2fc/0x4f0 with crng_init=0
clocksource: FTTMR010-TIMER2: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
Switching to timer-based delay loop, resolution 40ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x81e0 - 0x8228
rcu: Hierarchical SRCU implementation.
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes, linear)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
thermal_sys: Registered thermal governor 'step_wise'
No ATAGs?
pinctrl-gemini 40000000.syscon:pinctrl: detected 3516 chip variant
pinctrl-gemini 40000000.syscon:pinctrl: GLOBAL MISC CTRL at boot: 0x83c22037
pinctrl-gemini 40000000.syscon:pinctrl: flash pin is not set
pinctrl-gemini 40000000.syscon:pinctrl: initialized Gemini pin control driver
random: fast init done
pl08xdmac 67000000.dma-controller: FTDMAC020 1.16 rel 1
pl08xdmac 67000000.dma-controller: FTDMAC020 4 channels, has built-in bridge, AHB0 and AHB1, supports linked lists
pl08xdmac 67000000.dma-controller: initialized 4 virtual memcpy channels
pl08xdmac 67000000.dma-controller: DMA: PL080 rev0 at 0x67000000 irq 27
Gemini SoC 3516 revision c2, set arbitration 00200030
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource FTTMR010-TIMER2
NET: Registered protocol family 2
IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
NET: Registered protocol family 1
Initialise system trusted keyrings
workingset: timestamp_bits=30 max_order=15 bucket_order=0
romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
NET: Registered protocol family 38
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler mq-deadline registered
io scheduler kyber registered
ftgpio010-gpio 4d000000.gpio: FTGPIO010 @(ptrval) registered
ftgpio010-gpio 4e000000.gpio: FTGPIO010 @(ptrval) registered
ftgpio010-gpio 4f000000.gpio: FTGPIO010 @(ptrval) registered
Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled
printk: console [ttyS0] disabled
42000000.serial: ttyS0 at MMIO 0x42000000 (irq = 18, base_baud = 3000000) is a 16550A
printk: console [ttyS0] enabled
brd: module loaded
physmap-flash 30000000.flash: no enabled pin control state
physmap-flash 30000000.flash: no disabled pin control state
physmap-flash 30000000.flash: initialized Gemini-specific physmap control
physmap-flash 30000000.flash: physmap platform flash device: [mem 0x30000000-0x307fffff]
30000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x0000c2 Chip ID 0x0022cb
Support for command set 0002 not present
gen_probe: No supported Vendor Command Set found
physmap-flash 30000000.flash: map_probe failed
libphy: Fixed MDIO Bus: probed
mdio-gpio ethernet-phy: failed to get alias id
libphy: GPIO Bitbanged MDIO: probed
tun: Universal TUN/TAP device driver, 1.6
gmac-gemini 60000000.ethernet: Ethernet device ID: 0x000, revision 0x1
gemini-ethernet-port 60008000.ethernet-port: probe 60008000.ethernet-port ID 0
gemini-ethernet-port 60008000.ethernet-port: using a random ethernet address
RTL8211B Gigabit Ethernet gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)
gemini-ethernet-port 60008000.ethernet-port eth0: irq 30, DMA @ 0x0x60008000, GMAC @ 0x0x6000a000
gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port ID 1
gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
gemini-ethernet-port 6000c000.ethernet-port (unnamed net_device) (uninitialized): PHY init failed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
fotg210-hcd 68000000.usb: Faraday USB2.0 Host Controller
fotg210-hcd 68000000.usb: new USB bus registered, assigned bus number 1
fotg210-hcd 68000000.usb: irq 28, io mem 0x68000000
fotg210-hcd 68000000.usb: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fotg210-hcd 69000000.usb: Faraday USB2.0 Host Controller
fotg210-hcd 69000000.usb: new USB bus registered, assigned bus number 2
fotg210-hcd 69000000.usb: irq 29, io mem 0x69000000
fotg210-hcd 69000000.usb: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
rtc-ftrtc010 45000000.rtc: registered as rtc0
rtc-ftrtc010 45000000.rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)
gemini-poweroff 4b000000.power-controller: other power management IRQ
gemini-poweroff 4b000000.power-controller: Gemini poweroff driver registered
ftwdt010-wdt 41000000.watchdog: FTWDT010 watchdog driver enabled
device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel at redhat.com
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
8021q: 802.1Q VLAN Support v1.8
Loading compiled-in X.509 certificates
Freeing unused kernel memory: 3340K
Kernel memory protection not selected by kernel config.
Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
OK
Starting network: OK
random: crng init done
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Starting sshd: OK

Welcome to Buildroot
ns2502 login: root
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether b6:95:3c:18:98:62 brd ff:ff:ff:ff:ff:ff
3: sit0 at NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
# udhcpc -i eth0
udhcpc: started, v1.33.0
gmac-gemini 60000000.ethernet: allocate 512 pages for queue
gemini-ethernet-port 60008000.ethernet-port eth0: Unsupported PHY speed (-1) on gpio-0:01
gemini-ethernet-port 60008000.ethernet-port eth0: Link is Down
gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: none
udhcpc: socket: Address family not supported by protocol
# gemini-ethernet-port 60008000.ethernet-port eth0: Link is Up - 1Gbps/Full - flow control rx/tx
gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

# udhcpc -i eth0
udhcpc: started, v1.33.0
udhcpc: socket: Address family not supported by protocol


Inserting an USB dongle give nothing.
As shown, udhcp cannot get an IP.
Setting one at hand does not fix anything, ping fail.

Can someone help me bring up at least ethernet ?

Thanks


From mathieu.poirier at linaro.org  Mon Apr  5 20:17:57 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon,  5 Apr 2021 13:17:57 -0600
Subject: [GIT PULL] coresight: Add support for ETE and TRBE
Message-ID: <20210405191757.283122-1-mathieu.poirier@linaro.org>

The following changes since commit a354a64d91eec3e0f8ef0eed575b480fd75b999c:

  KVM: arm64: Disable guest access to trace filter controls (2021-03-24 17:26:38 +0000)

are available in the Git repository at:

  git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE

for you to fetch changes up to 7885b4e43231048654c5a80c0a18844ce3185e64:

  dts: bindings: Document device tree bindings for Arm TRBE (2021-04-05 11:38:04 -0600)

----------------------------------------------------------------
Hi Marc,

As previously agreed, here are the changes to support CoreSight
ETE and TRBE components submitted here[1].

I draw your attention to these:

[PATCH v6 05/20] kvm: arm64: Handle access to TRFCR_EL1
[PATCH v6 06/20] kvm: arm64: Move SPE availability check to VCPU load
[PATCH v6 07/20] arm64: kvm: Enable access to TRBE support for host

They are KVM specific and will need an SoB tag.

Thanks,
Mathieu

[1]. https://lore.kernel.org/linux-arm-kernel/20210405164307.1720226-1-suzuki.poulose at arm.com/T/#t

----------------------------------------------------------------

Anshuman Khandual (5):
      arm64: Add TRBE definitions
      coresight: core: Add support for dedicated percpu sinks
      coresight: sink: Add TRBE driver
      Documentation: coresight: trbe: Sysfs ABI description
      Documentation: trace: Add documentation for TRBE

Suzuki K Poulose (15):
      perf: aux: Add flags for the buffer format
      perf: aux: Add CoreSight PMU buffer formats
      arm64: Add support for trace synchronization barrier
      kvm: arm64: Handle access to TRFCR_EL1
      kvm: arm64: Move SPE availability check to VCPU load
      arm64: kvm: Enable access to TRBE support for host
      coresight: etm4x: Move ETM to prohibited region for disable
      coresight: etm-perf: Allow an event to use different sinks
      coresight: Do not scan for graph if none is present
      coresight: etm4x: Add support for PE OS lock
      coresight: ete: Add support for ETE sysreg access
      coresight: ete: Add support for ETE tracing
      dts: bindings: Document device tree bindings for ETE
      coresight: etm-perf: Handle stale output handles
      dts: bindings: Document device tree bindings for Arm TRBE

 .../ABI/testing/sysfs-bus-coresight-devices-trbe   |   14 +
 Documentation/devicetree/bindings/arm/ete.yaml     |   75 ++
 Documentation/devicetree/bindings/arm/trbe.yaml    |   49 +
 Documentation/trace/coresight/coresight-trbe.rst   |   38 +
 MAINTAINERS                                        |    2 +
 arch/arm64/include/asm/barrier.h                   |    1 +
 arch/arm64/include/asm/el2_setup.h                 |   13 +
 arch/arm64/include/asm/kvm_arm.h                   |    2 +
 arch/arm64/include/asm/kvm_host.h                  |    8 +
 arch/arm64/include/asm/sysreg.h                    |   50 +
 arch/arm64/kernel/hyp-stub.S                       |    3 +-
 arch/arm64/kvm/arm.c                               |    2 +
 arch/arm64/kvm/debug.c                             |   35 +-
 arch/arm64/kvm/hyp/nvhe/debug-sr.c                 |   56 +-
 arch/arm64/kvm/hyp/nvhe/switch.c                   |    1 +
 arch/arm64/kvm/sys_regs.c                          |    1 +
 drivers/hwtracing/coresight/Kconfig                |   24 +-
 drivers/hwtracing/coresight/Makefile               |    1 +
 drivers/hwtracing/coresight/coresight-core.c       |   29 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  119 +-
 drivers/hwtracing/coresight/coresight-etm4x-core.c |  161 ++-
 .../hwtracing/coresight/coresight-etm4x-sysfs.c    |   19 +-
 drivers/hwtracing/coresight/coresight-etm4x.h      |   83 +-
 drivers/hwtracing/coresight/coresight-platform.c   |    6 +
 drivers/hwtracing/coresight/coresight-priv.h       |    3 +
 drivers/hwtracing/coresight/coresight-trbe.c       | 1157 ++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-trbe.h       |  152 +++
 include/linux/coresight.h                          |   13 +
 include/uapi/linux/perf_event.h                    |   13 +-
 29 files changed, 2053 insertions(+), 77 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
 create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
 create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h


From lkp at intel.com  Mon Apr  5 20:19:11 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 6 Apr 2021 03:19:11 +0800
Subject: [PATCH 1/2] of: net: pass the dst buffer to of_get_mac_address()
In-Reply-To: <20210405164643.21130-2-michael@walle.cc>
References: <20210405164643.21130-2-michael@walle.cc>
Message-ID: <202104060306.lmTxeOmW-lkp@intel.com>

Hi Michael,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20210401]
[cannot apply to sunxi/sunxi/for-next xlnx/master wireless-drivers-next/master wireless-drivers/master robh/for-next linus/master v5.12-rc6 v5.12-rc5 v5.12-rc4 v5.12-rc6]
[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]

url:    https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-004940
base:    454c576c3f5e51d60f00a4ac0dde07f4f9d70e9d
config: x86_64-kexec (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/98b333048aecad0da786f9f8c3fe60674442b8cf
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-004940
        git checkout 98b333048aecad0da786f9f8c3fe60674442b8cf
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:630:1: error: conflicting types for 'stmmac_probe_config_dt'
     630 | stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
         | ^~~~~~~~~~~~~~~~~~~~~~
   In file included from drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:20:
   drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h:15:1: note: previous declaration of 'stmmac_probe_config_dt' was here
      15 | stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac);
         | ^~~~~~~~~~~~~~~~~~~~~~
   In file included from include/linux/linkage.h:7,
                    from include/linux/kernel.h:8,
                    from arch/x86/include/asm/percpu.h:27,
                    from arch/x86/include/asm/current.h:6,
                    from include/linux/sched.h:12,
                    from include/linux/ratelimit.h:6,
                    from include/linux/dev_printk.h:16,
                    from include/linux/device.h:15,
                    from include/linux/platform_device.h:13,
                    from drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:11:
   drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:640:19: error: conflicting types for 'stmmac_probe_config_dt'
     640 | EXPORT_SYMBOL_GPL(stmmac_probe_config_dt);
         |                   ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/export.h:98:21: note: in definition of macro '___EXPORT_SYMBOL'
      98 |  extern typeof(sym) sym;       \
         |                     ^~~
   include/linux/export.h:155:34: note: in expansion of macro '__EXPORT_SYMBOL'
     155 | #define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "")
         |                                  ^~~~~~~~~~~~~~~
   include/linux/export.h:159:33: note: in expansion of macro '_EXPORT_SYMBOL'
     159 | #define EXPORT_SYMBOL_GPL(sym)  _EXPORT_SYMBOL(sym, "_gpl")
         |                                 ^~~~~~~~~~~~~~
   drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:640:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
     640 | EXPORT_SYMBOL_GPL(stmmac_probe_config_dt);
         | ^~~~~~~~~~~~~~~~~
   In file included from drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:20:
   drivers/net/ethernet/stmicro/stmmac/stmmac_platform.h:15:1: note: previous declaration of 'stmmac_probe_config_dt' was here
      15 | stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac);
         | ^~~~~~~~~~~~~~~~~~~~~~


vim +/stmmac_probe_config_dt +630 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c

d2ed0a7755fe14 Johan Hovold     2016-11-30  614  
d2ed0a7755fe14 Johan Hovold     2016-11-30  615  /**
d2ed0a7755fe14 Johan Hovold     2016-11-30  616   * stmmac_remove_config_dt - undo the effects of stmmac_probe_config_dt()
d2ed0a7755fe14 Johan Hovold     2016-11-30  617   * @pdev: platform_device structure
d2ed0a7755fe14 Johan Hovold     2016-11-30  618   * @plat: driver data platform structure
d2ed0a7755fe14 Johan Hovold     2016-11-30  619   *
d2ed0a7755fe14 Johan Hovold     2016-11-30  620   * Release resources claimed by stmmac_probe_config_dt().
d2ed0a7755fe14 Johan Hovold     2016-11-30  621   */
d2ed0a7755fe14 Johan Hovold     2016-11-30  622  void stmmac_remove_config_dt(struct platform_device *pdev,
d2ed0a7755fe14 Johan Hovold     2016-11-30  623  			     struct plat_stmmacenet_data *plat)
d2ed0a7755fe14 Johan Hovold     2016-11-30  624  {
4838a54050284d Jose Abreu       2019-06-14  625  	of_node_put(plat->phy_node);
a249708bc2aa1f Julia Lawall     2017-01-17  626  	of_node_put(plat->mdio_node);
d2ed0a7755fe14 Johan Hovold     2016-11-30  627  }
6a228452d11eaf Stefan Roese     2012-03-13  628  #else
402dae0bed98dd Joachim Eastwood 2015-07-17  629  struct plat_stmmacenet_data *
b0003ead75f394 Joachim Eastwood 2015-07-17 @630  stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
6a228452d11eaf Stefan Roese     2012-03-13  631  {
b2a8315a5c655f LABBE Corentin   2017-02-08  632  	return ERR_PTR(-EINVAL);
6a228452d11eaf Stefan Roese     2012-03-13  633  }
d2ed0a7755fe14 Johan Hovold     2016-11-30  634  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28702 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210406/bb3dc480/attachment-0001.gz>

From fparent at baylibre.com  Mon Apr  5 21:03:52 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:03:52 +0200
Subject: [PATCH v2 1/2] dt-bindings: mediatek: mmsys: add mt8167 binding
Message-ID: <20210405200354.2194930-1-fparent@baylibre.com>

Add binding documentation for MT8167 SoC.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
Acked-by: Rob Herring <robh at kernel.org>
---
V2: Rebased + fix typo in commit message.

 .../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt          | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index d8c9108c3b4a..78c50733985c 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -13,6 +13,7 @@ Required Properties:
 	- "mediatek,mt6779-mmsys", "syscon"
 	- "mediatek,mt6797-mmsys", "syscon"
 	- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
+	- "mediatek,mt8167-mmsys", "syscon"
 	- "mediatek,mt8173-mmsys", "syscon"
 	- "mediatek,mt8183-mmsys", "syscon"
 - #clock-cells: Must be 1
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:03:53 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:03:53 +0200
Subject: [PATCH v2 2/2] soc: mediatek: mmsys: Add support for MT8167 SoC
In-Reply-To: <20210405200354.2194930-1-fparent@baylibre.com>
References: <20210405200354.2194930-1-fparent@baylibre.com>
Message-ID: <20210405200354.2194930-2-fparent@baylibre.com>

Add routing table for DSI on MT8167 SoC. The registers are mostly
incompatible with the current defines, so new one for MT8167 are added.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---

V2: Rebased on top of [0]

[0] https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=for-next

 drivers/soc/mediatek/mt8167-mmsys.h | 35 +++++++++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c    | 11 +++++++++
 2 files changed, 46 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8167-mmsys.h

diff --git a/drivers/soc/mediatek/mt8167-mmsys.h b/drivers/soc/mediatek/mt8167-mmsys.h
new file mode 100644
index 000000000000..2772ef5e3934
--- /dev/null
+++ b/drivers/soc/mediatek/mt8167-mmsys.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8167_MMSYS_H
+#define __SOC_MEDIATEK_MT8167_MMSYS_H
+
+#define MT8167_DISP_REG_CONFIG_DISP_OVL0_MOUT_EN	0x030
+#define MT8167_DISP_REG_CONFIG_DISP_DITHER_MOUT_EN	0x038
+#define MT8167_DISP_REG_CONFIG_DISP_COLOR0_SEL_IN	0x058
+#define MT8167_DISP_REG_CONFIG_DISP_DSI0_SEL_IN		0x064
+#define MT8167_DISP_REG_CONFIG_DISP_RDMA0_SOUT_SEL_IN	0x06c
+
+#define MT8167_DITHER_MOUT_EN_RDMA0			0x1
+#define MT8167_RDMA0_SOUT_DSI0				0x2
+#define MT8167_DSI0_SEL_IN_RDMA0			0x1
+
+static const struct mtk_mmsys_routes mt8167_mmsys_routing_table[] = {
+	{
+		DDP_COMPONENT_OVL0, DDP_COMPONENT_COLOR0,
+		MT8167_DISP_REG_CONFIG_DISP_OVL0_MOUT_EN, OVL0_MOUT_EN_COLOR0,
+	}, {
+		DDP_COMPONENT_DITHER, DDP_COMPONENT_RDMA0,
+		MT8167_DISP_REG_CONFIG_DISP_DITHER_MOUT_EN, MT8167_DITHER_MOUT_EN_RDMA0
+	}, {
+		DDP_COMPONENT_OVL0, DDP_COMPONENT_COLOR0,
+		MT8167_DISP_REG_CONFIG_DISP_COLOR0_SEL_IN, COLOR0_SEL_IN_OVL0
+	}, {
+		DDP_COMPONENT_RDMA0, DDP_COMPONENT_DSI0,
+		MT8167_DISP_REG_CONFIG_DISP_DSI0_SEL_IN, MT8167_DSI0_SEL_IN_RDMA0
+	}, {
+		DDP_COMPONENT_RDMA0, DDP_COMPONENT_DSI0,
+		MT8167_DISP_REG_CONFIG_DISP_RDMA0_SOUT_SEL_IN, MT8167_RDMA0_SOUT_DSI0
+	},
+};
+
+#endif /* __SOC_MEDIATEK_MT8167_MMSYS_H */
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 79e55150210e..080660ef11bf 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -11,6 +11,7 @@
 #include <linux/soc/mediatek/mtk-mmsys.h>
 
 #include "mtk-mmsys.h"
+#include "mt8167-mmsys.h"
 #include "mt8183-mmsys.h"
 
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
@@ -33,6 +34,12 @@ static const struct mtk_mmsys_driver_data mt6797_mmsys_driver_data = {
 	.clk_driver = "clk-mt6797-mm",
 };
 
+static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
+	.clk_driver = "clk-mt8167-mm",
+	.routes = mt8167_mmsys_routing_table,
+	.num_routes = ARRAY_SIZE(mt8167_mmsys_routing_table),
+};
+
 static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
 	.clk_driver = "clk-mt8173-mm",
 	.routes = mmsys_default_routing_table,
@@ -138,6 +145,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
 		.compatible = "mediatek,mt6797-mmsys",
 		.data = &mt6797_mmsys_driver_data,
 	},
+	{
+		.compatible = "mediatek,mt8167-mmsys",
+		.data = &mt8167_mmsys_driver_data,
+	},
 	{
 		.compatible = "mediatek,mt8173-mmsys",
 		.data = &mt8173_mmsys_driver_data,
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:08:17 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:08:17 +0200
Subject: [PATCH 1/5] arm64: dts: mediatek: mt8167: add mmsys node
Message-ID: <20210405200821.2203458-1-fparent@baylibre.com>

Add node for MMSYS.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 156fbdad01fb..9d765034dfb0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -125,5 +125,11 @@ pio: pinctrl at 1000b000 {
 			#interrupt-cells = <2>;
 			interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		mmsys: mmsys at 14000000 {
+			compatible = "mediatek,mt8167-mmsys", "syscon";
+			reg = <0 0x14000000 0 0x1000>;
+			#clock-cells = <1>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:08:18 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:08:18 +0200
Subject: [PATCH 2/5] arm64: dts: mediatek: mt8167: add smi_common node
In-Reply-To: <20210405200821.2203458-1-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
Message-ID: <20210405200821.2203458-2-fparent@baylibre.com>

Add the smi_common node.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 9d765034dfb0..4b951f81db9e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -131,5 +131,14 @@ mmsys: mmsys at 14000000 {
 			reg = <0 0x14000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
+
+		smi_common: smi at 14017000 {
+			compatible = "mediatek,mt8167-smi-common";
+			reg = <0 0x14017000 0 0x1000>;
+			clocks = <&mmsys CLK_MM_SMI_COMMON>,
+				 <&mmsys CLK_MM_SMI_COMMON>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:08:19 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:08:19 +0200
Subject: [PATCH 3/5] arm64: dts: mediatek: mt8167: add larb nodes
In-Reply-To: <20210405200821.2203458-1-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
Message-ID: <20210405200821.2203458-3-fparent@baylibre.com>

Add larb nodes for MT8167:
* larb0 is used for display (dsi and hdmi)
* larb1 is used for camera (csi)
* larb2 is used for the video hardware decoder

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 33 ++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 4b951f81db9e..9b352031c5f6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -140,5 +140,38 @@ smi_common: smi at 14017000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
 		};
+
+		larb0: larb at 14016000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x14016000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			mediatek,larbid = <0>;
+			clocks = <&mmsys CLK_MM_SMI_LARB0>,
+				 <&mmsys CLK_MM_SMI_LARB0>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
+		larb1: larb at 15001000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x15001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			mediatek,larbid = <1>;
+			clocks = <&imgsys CLK_IMG_LARB1_SMI>,
+				 <&imgsys CLK_IMG_LARB1_SMI>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
+		};
+
+		larb2: larb at 16010000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x16010000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			mediatek,larbid = <2>;
+			clocks = <&vdecsys CLK_VDEC_CKEN>,
+				 <&vdecsys CLK_VDEC_LARB1_CKEN>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:08:20 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:08:20 +0200
Subject: [PATCH 4/5] arm64: dts: mediatek: mt8167: add iommu node
In-Reply-To: <20210405200821.2203458-1-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
Message-ID: <20210405200821.2203458-4-fparent@baylibre.com>

Add node for the MT8167's IOMMU.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 9b352031c5f6..3ba03ca749b2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -173,5 +173,14 @@ larb2: larb at 16010000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
 		};
+
+		iommu: m4u at 10203000 {
+			cell-index = <0>;
+			compatible = "mediatek,mt8167-m4u";
+			reg = <0 0x10203000 0 0x1000>;
+			mediatek,larbs = <&larb0 &larb1 &larb2>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
+			#iommu-cells = <1>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Mon Apr  5 21:08:21 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Mon,  5 Apr 2021 22:08:21 +0200
Subject: [PATCH 5/5] arm64: dts: mediatek: mt8167: add some DRM nodes
In-Reply-To: <20210405200821.2203458-1-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
Message-ID: <20210405200821.2203458-5-fparent@baylibre.com>

Add all the DRM nodes required to get DSI to work on MT8167 SoC.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 149 +++++++++++++++++++++++
 1 file changed, 149 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 3ba03ca749b2..8ca92d6b203a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -16,6 +16,19 @@
 / {
 	compatible = "mediatek,mt8167";
 
+	aliases {
+		aal0 = &aal;
+		ccorr0 = &ccorr;
+		color0 = &color;
+		dither0 = &dither;
+		dsi0 = &dsi;
+		ovl0 = &ovl0;
+		pwm0 = &disp_pwm;
+		rdma0 = &rdma0;
+		rdma1 = &rdma1;
+		wdma0 = &wdma;
+	};
+
 	soc {
 		topckgen: topckgen at 10000000 {
 			compatible = "mediatek,mt8167-topckgen", "syscon";
@@ -114,6 +127,13 @@ vdecsys: syscon at 16000000 {
 			#clock-cells = <1>;
 		};
 
+		mutex: mutex at 14015000 {
+			compatible = "mediatek,mt8167-disp-mutex";
+			reg = <0 0x14015000 0 0x1000>;
+			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
 		pio: pinctrl at 1000b000 {
 			compatible = "mediatek,mt8167-pinctrl";
 			reg = <0 0x1000b000 0 0x1000>;
@@ -126,6 +146,135 @@ pio: pinctrl at 1000b000 {
 			interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		rdma1: rdma1 at 1400a000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x1400a000 0 0x1000>;
+			interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA1>;
+			mediatek,larb = <&larb0>;
+		};
+
+		disp_pwm: disp_pwm at 1100f000 {
+			compatible = "mediatek,mt8167-disp-pwm",
+				     "mediatek,mt8173-disp-pwn";
+			reg = <0 0x1100f000 0 0x1000>;
+			#pwm-cells = <2>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&topckgen CLK_TOP_PWM_SEL>,
+				 <&topckgen CLK_TOP_PWM_MM>,
+				  <&mmsys CLK_MM_DISP_PWM_26M>,
+				  <&mmsys CLK_MM_DISP_PWM_MM>;
+			clock-names = "pwm_sel",
+				      "pwm_mm",
+				      "main",
+				      "mm";
+			status = "disabled";
+		};
+
+		dsi: dsi at 14012000 {
+			compatible = "mediatek,mt8167-dsi",
+				     "mediatek,mt2701-dsi";
+			reg = <0 0x14012000 0 0x1000>;
+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DSI_ENGINE>,
+				 <&mmsys CLK_MM_DSI_DIGITAL>,
+				 <&mipi_tx>;
+			clock-names = "engine", "digital", "hs";
+			phys = <&mipi_tx>;
+			phy-names = "dphy";
+			status = "disabled";
+		};
+
+		mipi_tx: mipi_dphy at 14018000 {
+			compatible = "mediatek,mt8167-mipi-tx",
+				     "mediatek,mt2701-mipi-tx";
+			reg = <0 0x14018000 0 0x90>;
+			clocks = <&topckgen CLK_TOP_MIPI_26M_DBG>;
+			clock-output-names = "mipi_tx0_pll";
+			#clock-cells = <0>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
+
+		ovl0: ovl0 at 14007000 {
+			compatible = "mediatek,mt8167-disp-ovl",
+				     "mediatek,mt8173-disp-ovl";
+			reg = <0 0x14007000 0 0x1000>;
+			interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_OVL0>;
+			iommus = <&iommu M4U_PORT_DISP_OVL0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		rdma0: rdma0 at 14009000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x14009000 0 0x1000>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		color: color at 1400c000 {
+			compatible = "mediatek,mt8167-disp-color",
+				     "mediatek,mt8173-disp-color";
+			reg = <0 0x1400c000 0 0x1000>;
+			interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_COLOR>;
+		};
+
+		ccorr: ccorr at 1400d000 {
+			compatible = "mediatek,mt8167-disp-ccorr",
+				     "mediatek,mt8183-disp-ccorr";
+			reg = <0 0x1400d000 0 0x1000>;
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_CCORR>;
+		};
+
+		aal: aal at 1400e000 {
+			compatible = "mediatek,mt8167-disp-aal";
+			reg = <0 0x1400e000 0 0x1000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_AAL>;
+		};
+
+		gamma: gamma at 1400f000 {
+			compatible = "mediatek,mt8167-disp-gamma",
+				     "mediatek,mt8173-disp-gamma";
+			reg = <0 0x1400f000 0 0x1000>;
+			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_GAMMA>;
+		};
+
+		dither: dither at 14010000 {
+			compatible = "mediatek,mt8167-disp-dither";
+			reg = <0 0x14010000 0 0x1000>;
+			interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_DITHER>;
+		};
+
+		wdma: wdma0 at 1400b000 {
+			compatible = "mediatek,mt8167-disp-wdma";
+			reg = <0 0x1400b000 0 0x1000>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_WDMA>;
+			iommus = <&iommu M4U_PORT_DISP_WDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
 		mmsys: mmsys at 14000000 {
 			compatible = "mediatek,mt8167-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.31.0



From andrew at lunn.ch  Mon Apr  5 21:36:32 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 5 Apr 2021 22:36:32 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
In-Reply-To: <YGtZeofmBv7hXK+a@Red>
References: <YGtZeofmBv7hXK+a@Red>
Message-ID: <YGt00DdrToMTskp8@lunn.ch>

On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:

> 	mdio0: ethernet-phy {

Not relevant to the brokennes, but this should not be called
ethernet-phy. The example given in
Documentation/devicetree/bindings/net/mdio-gpio.txt is

mdio0: mdio

> 		compatible = "virtual,mdio-gpio";
> 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
> 			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		phy0: ethernet-phy at 1 {
> 			reg = <1>;
> 			device_type = "ethernet-phy";
> 		};
> 	};

So you are using a bit-banging MDIO bus.

> 		gpio0: gpio at 4d000000 {
> 			pinctrl-names = "default";
> 			pinctrl-0 = <&gpio0_default_pins>;
> 		};

and here is the gpio controller.

> 		ethernet at 60000000 {
> 			status = "okay";
> 			ethernet-port at 0 {
> 				phy-mode = "rgmii";
> 				phy-handle = <&phy0>;
> 			};
> 			ethernet-port at 1 {
> 				/* Not used in this platform */
> 			};
> 		};

and this look O.K.

> libphy: Fixed MDIO Bus: probed
> mdio-gpio ethernet-phy: failed to get alias id

That does not look too good. But it is just a warning.

        if (pdev->dev.of_node) {
                bus_id = of_alias_get_id(pdev->dev.of_node, "mdio-gpio");
                if (bus_id < 0) {
                        dev_warn(&pdev->dev, "failed to get alias id\n");
                        bus_id = 0;
                }

If you look at the example in the documentation, it has

aliases {
        mdio-gpio0 = &mdio0;
};

If you add that, i guess this will go away.
  

> libphy: GPIO Bitbanged MDIO: probed
> tun: Universal TUN/TAP device driver, 1.6
> gmac-gemini 60000000.ethernet: Ethernet device ID: 0x000, revision 0x1
> gemini-ethernet-port 60008000.ethernet-port: probe 60008000.ethernet-port ID 0
> gemini-ethernet-port 60008000.ethernet-port: using a random ethernet address
> RTL8211B Gigabit Ethernet gpio-0:01: attached PHY driver (mii_bus:phy_addr=gpio-0:01, irq=POLL)

So a realtek PHY has been found on the MDIO bus. Good.

> gemini-ethernet-port 60008000.ethernet-port eth0: irq 30, DMA @ 0x0x60008000, GMAC @ 0x0x6000a000

and everything looks good.

> gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port ID 1
> gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
> gemini-ethernet-port 6000c000.ethernet-port (unnamed net_device) (uninitialized): PHY init failed

And now it seems to of all gone horribly wrong :-(

This is the second Ethernet interface, the one you have commented as 

/* Not used in this platform */

I _think_ you just need to delete the entry, otherwise it tried to
probe it. And then that probe fails, it looks like it also fails the
working interface :-(
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
>     link/ether b6:95:3c:18:98:62 brd ff:ff:ff:ff:ff:ff
> 3: sit0 at NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
>     link/sit 0.0.0.0 brd 0.0.0.0
> # udhcpc -i eth0
> udhcpc: started, v1.33.0
> gmac-gemini 60000000.ethernet: allocate 512 pages for queue
> gemini-ethernet-port 60008000.ethernet-port eth0: Unsupported PHY speed (-1) on gpio-0:01
> gemini-ethernet-port 60008000.ethernet-port eth0: Link is Down
> gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: none
> udhcpc: socket: Address family not supported by protocol
> # gemini-ethernet-port 60008000.ethernet-port eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> gemini-ethernet-port 60008000.ethernet-port eth0: link flow control: tx
> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> # udhcpc -i eth0
> udhcpc: started, v1.33.0
> udhcpc: socket: Address family not supported by protocol

That suggests the kernel you have build does not have PF_PACKET.
Enable CONFIG_PACKET_DIAG.

       Andrew


From madvenka at linux.microsoft.com  Mon Apr  5 21:43:10 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Mon,  5 Apr 2021 15:43:10 -0500
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack trace
 reliability checks
In-Reply-To: <20210405204313.21346-1-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
Message-ID: <20210405204313.21346-2-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Implement a check_reliability() function that will contain checks for the
presence of various features and conditions that can render the stack trace
unreliable.

Introduce the first reliability check - If a return PC encountered in a
stack trace is not a valid kernel text address, the stack trace is
considered unreliable. It could be some generated code.

Other reliability checks will be added in the future.

These checks will involve checking the return PC to see if it falls inside
any special functions where the stack trace is considered unreliable.
Implement the infrastructure needed for this.

Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/include/asm/stacktrace.h |  2 +
 arch/arm64/kernel/stacktrace.c      | 80 +++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
index eb29b1fe8255..684f65808394 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -59,6 +59,7 @@ struct stackframe {
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 	int graph;
 #endif
+	bool reliable;
 };
 
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
@@ -169,6 +170,7 @@ static inline void start_backtrace(struct stackframe *frame,
 	bitmap_zero(frame->stacks_done, __NR_STACK_TYPES);
 	frame->prev_fp = 0;
 	frame->prev_type = STACK_TYPE_UNKNOWN;
+	frame->reliable = true;
 }
 
 #endif	/* __ASM_STACKTRACE_H */
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..557657d6e6bd 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -18,6 +18,84 @@
 #include <asm/stack_pointer.h>
 #include <asm/stacktrace.h>
 
+struct function_range {
+	unsigned long	start;
+	unsigned long	end;
+};
+
+/*
+ * Special functions where the stack trace is unreliable.
+ */
+static struct function_range	special_functions[] = {
+	{ /* sentinel */ }
+};
+
+static bool is_reliable_function(unsigned long pc)
+{
+	static bool inited = false;
+	struct function_range *func;
+
+	if (!inited) {
+		static char sym[KSYM_NAME_LEN];
+		unsigned long size, offset;
+
+		for (func = special_functions; func->start; func++) {
+			if (kallsyms_lookup(func->start, &size, &offset,
+					    NULL, sym)) {
+				func->start -= offset;
+				func->end = func->start + size;
+			} else {
+				/*
+				 * This is just a label. So, we only need to
+				 * consider that particular location. So, size
+				 * is the size of one Aarch64 instruction.
+				 */
+				func->end = func->start + 4;
+			}
+		}
+		inited = true;
+	}
+
+	for (func = special_functions; func->start; func++) {
+		if (pc >= func->start && pc < func->end)
+			return false;
+	}
+	return true;
+}
+
+/*
+ * Check for the presence of features and conditions that render the stack
+ * trace unreliable.
+ *
+ * Once all such cases have been addressed, this function can aid live
+ * patching (and this comment can be removed).
+ */
+static void check_reliability(struct stackframe *frame)
+{
+	/*
+	 * If the stack trace has already been marked unreliable, just return.
+	 */
+	if (!frame->reliable)
+		return;
+
+	/*
+	 * First, make sure that the return address is a proper kernel text
+	 * address. A NULL or invalid return address probably means there's
+	 * some generated code which __kernel_text_address() doesn't know
+	 * about. Mark the stack trace as not reliable.
+	 */
+	if (!__kernel_text_address(frame->pc)) {
+		frame->reliable = false;
+		return;
+	}
+
+	/*
+	 * Check the reliability of the return PC's function.
+	 */
+	if (!is_reliable_function(frame->pc))
+		frame->reliable = false;
+}
+
 /*
  * AArch64 PCS assigns the frame pointer to x29.
  *
@@ -108,6 +186,8 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 
 	frame->pc = ptrauth_strip_insn_pac(frame->pc);
 
+	check_reliability(frame);
+
 	return 0;
 }
 NOKPROBE_SYMBOL(unwind_frame);
-- 
2.25.1



From madvenka at linux.microsoft.com  Mon Apr  5 21:43:09 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Mon,  5 Apr 2021 15:43:09 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
Message-ID: <20210405204313.21346-1-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

There are a number of places in kernel code where the stack trace is not
reliable. Enhance the unwinder to check for those cases and mark the
stack trace as unreliable. Once all of the checks are in place, the unwinder
can provide a reliable stack trace. But before this can be used for livepatch,
some other entity needs to guarantee that the frame pointers are all set up
correctly in kernel functions. objtool is currently being worked on to
fill that gap.

Except for the return address check, all the other checks involve checking
the return PC of every frame against certain kernel functions. To do this,
implement some infrastructure code:

	- Define a special_functions[] array and populate the array with
	  the special functions

	- Using kallsyms_lookup(), lookup the symbol table entries for the
	  functions and record their address ranges

	- Define an is_reliable_function(pc) to match a return PC against
	  the special functions.

The unwinder calls is_reliable_function(pc) for every return PC and marks
the stack trace as reliable or unreliable accordingly.

Return address check
====================

Check the return PC of every stack frame to make sure that it is a valid
kernel text address (and not some generated code, for example).

Detect EL1 exception frame
==========================

EL1 exceptions can happen on any instruction including instructions in
the frame pointer prolog or epilog. Depending on where exactly they happen,
they could render the stack trace unreliable.

Add all of the EL1 exception handlers to special_functions[].

	- el1_sync()
	- el1_irq()
	- el1_error()
	- el1_sync_invalid()
	- el1_irq_invalid()
	- el1_fiq_invalid()
	- el1_error_invalid()

Detect ftrace frame
===================

When FTRACE executes at the beginning of a traced function, it creates two
frames and calls the tracer function:

	- One frame for the traced function

	- One frame for the caller of the traced function

That gives a sensible stack trace while executing in the tracer function.
When FTRACE returns to the traced function, the frames are popped and
everything is back to normal.

However, in cases like live patch, the tracer function redirects execution
to a different function. When FTRACE returns, control will go to that target
function. A stack trace taken in the tracer function will not show the target
function. The target function is the real function that we want to track.
So, the stack trace is unreliable.

To detect stack traces from a tracer function, add the following to
special_functions[]:

	- ftrace_call + 4

ftrace_call is the label at which the tracer function is patched in. So,
ftrace_call + 4 is its return address. This is what will show up in a
stack trace taken from the tracer function.

When Function Graph Tracing is on, ftrace_graph_caller is patched in
at the label ftrace_graph_call. If a tracer function called before it has
redirected execution as mentioned above, the stack traces taken from within
ftrace_graph_caller will also be unreliable for the same reason as mentioned
above. So, add ftrace_graph_caller to special_functions[] as well.

Also, the Function Graph Tracer modifies the return address of a traced
function to a return trampoline (return_to_handler()) to gather tracing
data on function return. Stack traces taken from the traced function and
functions it calls will not show the original caller of the traced function.
The unwinder handles this case by getting the original caller from FTRACE.

However, stack traces taken from the trampoline itself and functions it calls
are unreliable as the original return address may not be available in
that context. This is because the trampoline calls FTRACE to gather trace
data as well as to obtain the actual return address and FTRACE discards the
record of the original return address along the way.

Add return_to_handler() to special_functions[].

Check for kretprobe
===================

For functions with a kretprobe set up, probe code executes on entry
to the function and replaces the return address in the stack frame with a
kretprobe trampoline. Whenever the function returns, control is
transferred to the trampoline. The trampoline eventually returns to the
original return address.

A stack trace taken while executing in the function (or in functions that
get called from the function) will not show the original return address.
Similarly, a stack trace taken while executing in the trampoline itself
(and functions that get called from the trampoline) will not show the
original return address. This means that the caller of the probed function
will not show. This makes the stack trace unreliable.

Add the kretprobe trampoline to special_functions[].

Optprobes
=========

Optprobes may be implemented in the future for arm64. For optprobes,
the relevant trampoline(s) can be added to special_functions[].
---
Changelog:

v1
	- Define a bool field in struct stackframe. This will indicate if
	  a stack trace is reliable.

	- Implement a special_functions[] array that will be populated
	  with special functions in which the stack trace is considered
	  unreliable.
	
	- Using kallsyms_lookup(), get the address ranges for the special
	  functions and record them.

	- Implement an is_reliable_function(pc). This function will check
	  if a given return PC falls in any of the special functions. If
	  it does, the stack trace is unreliable.

	- Implement check_reliability() function that will check if a
	  stack frame is reliable. Call is_reliable_function() from
	  check_reliability().

	- Before a return PC is checked against special_funtions[], it
	  must be validates as a proper kernel text address. Call
	  __kernel_text_address() from check_reliability().

	- Finally, call check_reliability() from unwind_frame() for
	  each stack frame.

	- Add EL1 exception handlers to special_functions[].

		el1_sync();
		el1_irq();
		el1_error();
		el1_sync_invalid();
		el1_irq_invalid();
		el1_fiq_invalid();
		el1_error_invalid();

	- The above functions are currently defined as LOCAL symbols.
	  Make them global so that they can be referenced from the
	  unwinder code.

	- Add FTRACE trampolines to special_functions[]:

		ftrace_graph_call()
		ftrace_graph_caller()
		return_to_handler()

	- Add the kretprobe trampoline to special functions[]:

		kretprobe_trampoline()

v2
	- Removed the terminating entry { 0, 0 } in special_functions[]
	  and replaced it with the idiom { /* sentinel */ }.

	- Change the ftrace trampoline entry ftrace_graph_call in
	  special_functions[] to ftrace_call + 4 and added explanatory
	  comments.

	- Unnested #ifdefs in special_functions[] for FTRACE.

Madhavan T. Venkataraman (4):
  arm64: Implement infrastructure for stack trace reliability checks
  arm64: Mark a stack trace unreliable if an EL1 exception frame is
    detected
  arm64: Detect FTRACE cases that make the stack trace unreliable
  arm64: Mark stack trace as unreliable if kretprobed functions are
    present

 arch/arm64/include/asm/exception.h  |   8 ++
 arch/arm64/include/asm/stacktrace.h |   2 +
 arch/arm64/kernel/entry-ftrace.S    |  12 ++
 arch/arm64/kernel/entry.S           |  14 +-
 arch/arm64/kernel/stacktrace.c      | 215 ++++++++++++++++++++++++++++
 5 files changed, 244 insertions(+), 7 deletions(-)


base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
-- 
2.25.1



From madvenka at linux.microsoft.com  Mon Apr  5 21:43:11 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Mon,  5 Apr 2021 15:43:11 -0500
Subject: [RFC PATCH v2 2/4] arm64: Mark a stack trace unreliable if an EL1
 exception frame is detected
In-Reply-To: <20210405204313.21346-1-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
Message-ID: <20210405204313.21346-3-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

EL1 exceptions can happen on any instruction including instructions in
the frame pointer prolog or epilog. Depending on where exactly they happen,
they could render the stack trace unreliable.

If an EL1 exception frame is found on the stack, mark the stack trace as
unreliable. Now, the EL1 exception frame is not at any well-known offset
on the stack. It can be anywhere on the stack. In order to properly detect
an EL1 exception frame, the return address must be checked against all of
the possible EL1 exception handlers.

Preemption
==========

Interrupts encountered in kernel code are also EL1 exceptions. At the end
of an interrupt, the interrupt handler checks if the current task must be
preempted for any reason. If so, it calls the preemption code which takes
the task off the CPU. A stack trace taken on the task after the preemption
will show the EL1 frame and will be considered unreliable. This is correct
behavior as preemption can happen practically at any point in code.

Probing
=======

Breakpoints encountered in kernel code are also EL1 exceptions. The probing
infrastructure uses breakpoints for executing probe code. While in the probe
code, the stack trace will show an EL1 frame and will be considered
unreliable. This is also correct behavior.

Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/include/asm/exception.h |  8 +++++++
 arch/arm64/kernel/entry.S          | 14 +++++------
 arch/arm64/kernel/stacktrace.c     | 37 ++++++++++++++++++++++++++++++
 3 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/exception.h b/arch/arm64/include/asm/exception.h
index 6546158d2f2d..4ebd2390ef54 100644
--- a/arch/arm64/include/asm/exception.h
+++ b/arch/arm64/include/asm/exception.h
@@ -35,6 +35,14 @@ asmlinkage void el1_sync_handler(struct pt_regs *regs);
 asmlinkage void el0_sync_handler(struct pt_regs *regs);
 asmlinkage void el0_sync_compat_handler(struct pt_regs *regs);
 
+asmlinkage void el1_sync(void);
+asmlinkage void el1_irq(void);
+asmlinkage void el1_error(void);
+asmlinkage void el1_sync_invalid(void);
+asmlinkage void el1_irq_invalid(void);
+asmlinkage void el1_fiq_invalid(void);
+asmlinkage void el1_error_invalid(void);
+
 asmlinkage void noinstr enter_el1_irq_or_nmi(struct pt_regs *regs);
 asmlinkage void noinstr exit_el1_irq_or_nmi(struct pt_regs *regs);
 asmlinkage void enter_from_user_mode(void);
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a31a0a713c85..9fe3aaeff019 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -630,19 +630,19 @@ SYM_CODE_START_LOCAL(el0_fiq_invalid_compat)
 SYM_CODE_END(el0_fiq_invalid_compat)
 #endif
 
-SYM_CODE_START_LOCAL(el1_sync_invalid)
+SYM_CODE_START(el1_sync_invalid)
 	inv_entry 1, BAD_SYNC
 SYM_CODE_END(el1_sync_invalid)
 
-SYM_CODE_START_LOCAL(el1_irq_invalid)
+SYM_CODE_START(el1_irq_invalid)
 	inv_entry 1, BAD_IRQ
 SYM_CODE_END(el1_irq_invalid)
 
-SYM_CODE_START_LOCAL(el1_fiq_invalid)
+SYM_CODE_START(el1_fiq_invalid)
 	inv_entry 1, BAD_FIQ
 SYM_CODE_END(el1_fiq_invalid)
 
-SYM_CODE_START_LOCAL(el1_error_invalid)
+SYM_CODE_START(el1_error_invalid)
 	inv_entry 1, BAD_ERROR
 SYM_CODE_END(el1_error_invalid)
 
@@ -650,7 +650,7 @@ SYM_CODE_END(el1_error_invalid)
  * EL1 mode handlers.
  */
 	.align	6
-SYM_CODE_START_LOCAL_NOALIGN(el1_sync)
+SYM_CODE_START_NOALIGN(el1_sync)
 	kernel_entry 1
 	mov	x0, sp
 	bl	el1_sync_handler
@@ -658,7 +658,7 @@ SYM_CODE_START_LOCAL_NOALIGN(el1_sync)
 SYM_CODE_END(el1_sync)
 
 	.align	6
-SYM_CODE_START_LOCAL_NOALIGN(el1_irq)
+SYM_CODE_START_NOALIGN(el1_irq)
 	kernel_entry 1
 	gic_prio_irq_setup pmr=x20, tmp=x1
 	enable_da_f
@@ -737,7 +737,7 @@ el0_irq_naked:
 	b	ret_to_user
 SYM_CODE_END(el0_irq)
 
-SYM_CODE_START_LOCAL(el1_error)
+SYM_CODE_START(el1_error)
 	kernel_entry 1
 	mrs	x1, esr_el1
 	gic_prio_kentry_setup tmp=x2
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 557657d6e6bd..fb11e4372891 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -14,6 +14,7 @@
 #include <linux/stacktrace.h>
 
 #include <asm/irq.h>
+#include <asm/exception.h>
 #include <asm/pointer_auth.h>
 #include <asm/stack_pointer.h>
 #include <asm/stacktrace.h>
@@ -25,8 +26,44 @@ struct function_range {
 
 /*
  * Special functions where the stack trace is unreliable.
+ *
+ * EL1 exceptions
+ * ==============
+ *
+ * EL1 exceptions can happen on any instruction including instructions in
+ * the frame pointer prolog or epilog. Depending on where exactly they happen,
+ * they could render the stack trace unreliable.
+ *
+ * If an EL1 exception frame is found on the stack, mark the stack trace as
+ * unreliable. Now, the EL1 exception frame is not at any well-known offset
+ * on the stack. It can be anywhere on the stack. In order to properly detect
+ * an EL1 exception frame, the return address must be checked against all of
+ * the possible EL1 exception handlers.
+ *
+ * Interrupts encountered in kernel code are also EL1 exceptions. At the end
+ * of an interrupt, the current task can get preempted. A stack trace taken
+ * on the task after the preemption will show the EL1 frame and will be
+ * considered unreliable. This is correct behavior as preemption can happen
+ * practically at any point in code.
+ *
+ * Breakpoints encountered in kernel code are also EL1 exceptions. Breakpoints
+ * can happen practically on any instruction. Mark the stack trace as
+ * unreliable. Breakpoints are used for executing probe code. Stack traces
+ * taken while in the probe code will show an EL1 frame and will be considered
+ * unreliable. This is correct behavior.
  */
 static struct function_range	special_functions[] = {
+	/*
+	 * EL1 exception handlers.
+	 */
+	{ (unsigned long) el1_sync, 0 },
+	{ (unsigned long) el1_irq, 0 },
+	{ (unsigned long) el1_error, 0 },
+	{ (unsigned long) el1_sync_invalid, 0 },
+	{ (unsigned long) el1_irq_invalid, 0 },
+	{ (unsigned long) el1_fiq_invalid, 0 },
+	{ (unsigned long) el1_error_invalid, 0 },
+
 	{ /* sentinel */ }
 };
 
-- 
2.25.1



From madvenka at linux.microsoft.com  Mon Apr  5 21:43:12 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Mon,  5 Apr 2021 15:43:12 -0500
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210405204313.21346-1-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
Message-ID: <20210405204313.21346-4-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
for a function, the ftrace infrastructure is called for the function at
the very beginning. Ftrace creates two frames:

	- One for the traced function

	- One for the caller of the traced function

That gives a reliable stack trace while executing in the ftrace code. When
ftrace returns to the traced function, the frames are popped and everything
is back to normal.

However, in cases like live patch, a tracer function may redirect execution
to a different function when it returns. A stack trace taken while still in
the tracer function will not show the target function. The target function
is the real function that we want to track.

So, if an FTRACE frame is detected on the stack, just mark the stack trace
as unreliable. The detection is done by checking the return PC against
FTRACE trampolines.

Also, the Function Graph Tracer modifies the return address of a traced
function to a return trampoline to gather tracing data on function return.
Stack traces taken from that trampoline and functions it calls are
unreliable as the original return address may not be available in
that context. Mark the stack trace unreliable accordingly.

Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/kernel/entry-ftrace.S | 12 +++++++
 arch/arm64/kernel/stacktrace.c   | 61 ++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+)

diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index b3e4f9a088b1..1f0714a50c71 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -86,6 +86,18 @@ SYM_CODE_START(ftrace_caller)
 	b	ftrace_common
 SYM_CODE_END(ftrace_caller)
 
+/*
+ * A stack trace taken from anywhere in the FTRACE trampoline code should be
+ * considered unreliable as a tracer function (patched at ftrace_call) could
+ * potentially set pt_regs->pc and redirect execution to a function different
+ * than the traced function. E.g., livepatch.
+ *
+ * No stack traces are taken in this FTRACE trampoline assembly code. But
+ * they can be taken from C functions that get called from here. The unwinder
+ * checks if a return address falls in this FTRACE trampoline code. See
+ * stacktrace.c. If function calls in this code are changed, please keep the
+ * special_functions[] array in stacktrace.c in sync.
+ */
 SYM_CODE_START(ftrace_common)
 	sub	x0, x30, #AARCH64_INSN_SIZE	// ip (callsite's BL insn)
 	mov	x1, x9				// parent_ip (callsite's LR)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index fb11e4372891..7a3c638d4aeb 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -51,6 +51,52 @@ struct function_range {
  * unreliable. Breakpoints are used for executing probe code. Stack traces
  * taken while in the probe code will show an EL1 frame and will be considered
  * unreliable. This is correct behavior.
+ *
+ * FTRACE
+ * ======
+ *
+ * When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled, the FTRACE trampoline code
+ * is called from a traced function even before the frame pointer prolog.
+ * FTRACE sets up two stack frames (one for the traced function and one for
+ * its caller) so that the unwinder can provide a sensible stack trace for
+ * any tracer function called from the FTRACE trampoline code.
+ *
+ * There are two cases where the stack trace is not reliable.
+ *
+ * (1) The task gets preempted before the two frames are set up. Preemption
+ *     involves an interrupt which is an EL1 exception. The unwinder already
+ *     handles EL1 exceptions.
+ *
+ * (2) The tracer function that gets called by the FTRACE trampoline code
+ *     changes the return PC (e.g., livepatch).
+ *
+ *     Not all tracer functions do that. But to err on the side of safety,
+ *     consider the stack trace as unreliable in all cases.
+ *
+ * When Function Graph Tracer is used, FTRACE modifies the return address of
+ * the traced function in its stack frame to an FTRACE return trampoline
+ * (return_to_handler). When the traced function returns, control goes to
+ * return_to_handler. return_to_handler calls FTRACE to gather tracing data
+ * and to obtain the original return address. Then, return_to_handler returns
+ * to the original return address.
+ *
+ * There are two cases to consider from a stack trace reliability point of
+ * view:
+ *
+ * (1) Stack traces taken within the traced function (and functions that get
+ *     called from there) will show return_to_handler instead of the original
+ *     return address. The original return address can be obtained from FTRACE.
+ *     The unwinder already obtains it and modifies the return PC in its copy
+ *     of the stack frame to the original return address. So, this is handled.
+ *
+ * (2) return_to_handler calls FTRACE as mentioned before. FTRACE discards
+ *     the record of the original return address along the way as it does not
+ *     need to maintain it anymore. This means that the unwinder cannot get
+ *     the original return address beyond that point while the task is still
+ *     executing in return_to_handler. So, consider the stack trace unreliable
+ *     if return_to_handler is detected on the stack.
+ *
+ * NOTE: The unwinder must do (1) before (2).
  */
 static struct function_range	special_functions[] = {
 	/*
@@ -64,6 +110,21 @@ static struct function_range	special_functions[] = {
 	{ (unsigned long) el1_fiq_invalid, 0 },
 	{ (unsigned long) el1_error_invalid, 0 },
 
+	/*
+	 * FTRACE trampolines.
+	 *
+	 * Tracer function gets patched at the label ftrace_call. Its return
+	 * address is the next instruction address.
+	 */
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
+	{ (unsigned long) ftrace_call + 4, 0 },
+#endif
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+	{ (unsigned long) ftrace_graph_caller, 0 },
+	{ (unsigned long) return_to_handler, 0 },
+#endif
+
 	{ /* sentinel */ }
 };
 
-- 
2.25.1



From madvenka at linux.microsoft.com  Mon Apr  5 21:43:13 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Mon,  5 Apr 2021 15:43:13 -0500
Subject: [RFC PATCH v2 4/4] arm64: Mark stack trace as unreliable if
 kretprobed functions are present
In-Reply-To: <20210405204313.21346-1-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
Message-ID: <20210405204313.21346-5-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

When a kretprobe is active for a function, the function's return address
in its stack frame is modified to point to the kretprobe trampoline. When
the function returns, the frame is popped and control is transferred
to the trampoline. The trampoline eventually returns to the original return
address.

If a stack walk is done within the function (or any functions that get
called from there), the stack trace will only show the trampoline and the
not the original caller.

Also, if the trampoline itself and the functions it calls do a stack trace,
that stack trace will also have the same problem. Detect this as well.

If the trampoline is detected in the stack trace, mark the stack trace
as unreliable.

Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/kernel/stacktrace.c | 37 ++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 7a3c638d4aeb..926bd91ffb3f 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -97,6 +97,36 @@ struct function_range {
  *     if return_to_handler is detected on the stack.
  *
  * NOTE: The unwinder must do (1) before (2).
+ *
+ * KPROBES
+ * =======
+ *
+ * There are two types of kprobes:
+ *
+ * (1) Regular kprobes that are placed anywhere in a probed function.
+ *     This is implemented by replacing the probed instruction with a
+ *     breakpoint. When the breakpoint is hit, the kprobe code emulates
+ *     the original instruction in-situ and returns to the next
+ *     instruction.
+ *
+ *     Breakpoints are EL1 exceptions. When the unwinder detects them,
+ *     the stack trace is marked as unreliable as it does not know where
+ *     exactly the exception happened. Detection of EL1 exceptions in
+ *     a stack trace will be done separately.
+ *
+ * (2) Return kprobes that are placed on the return of a probed function.
+ *     In this case, Kprobes sets up an initial breakpoint at the
+ *     beginning of the probed function. When the breakpoint is hit,
+ *     Kprobes replaces the return address in the stack frame with the
+ *     kretprobe_trampoline and records the original return address.
+ *     When the probed function returns, control goes to the trampoline
+ *     which eventually returns to the original return address.
+ *
+ *     Stack traces taken while in the probed function or while in the
+ *     trampoline will show kretprobe_trampoline instead of the original
+ *     return address. Detect this and mark the stack trace unreliable.
+ *     The detection is done by checking if the return PC falls anywhere
+ *     in kretprobe_trampoline.
  */
 static struct function_range	special_functions[] = {
 	/*
@@ -125,6 +155,13 @@ static struct function_range	special_functions[] = {
 	{ (unsigned long) return_to_handler, 0 },
 #endif
 
+	/*
+	 * Kprobe trampolines.
+	 */
+#ifdef CONFIG_KRETPROBES
+	{ (unsigned long) kretprobe_trampoline, 0 },
+#endif
+
 	{ /* sentinel */ }
 };
 
-- 
2.25.1



From martin.blumenstingl at googlemail.com  Mon Apr  5 21:54:04 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Mon, 5 Apr 2021 22:54:04 +0200
Subject: [PATCH 1/3] arm64: dts: meson: remove extra tab from ODROID
 N2/N2+ ext_mdio node
In-Reply-To: <20210329161256.31171-2-christianshewitt@gmail.com>
References: <20210329161256.31171-1-christianshewitt@gmail.com>
 <20210329161256.31171-2-christianshewitt@gmail.com>
Message-ID: <CAFBinCCpUC4eYa=HdcmxLxfBU=4JRpSzr+qGUZoHQRq+u0Ok5g@mail.gmail.com>

On Tue, Mar 30, 2021 at 1:17 AM Christian Hewitt
<christianshewitt at gmail.com> wrote:
>
> Remove an extra tab from the ext_mdio node in the ODROID N2/N2+ common
> dtsi file.
>
> Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From mathieu.poirier at linaro.org  Mon Apr  5 21:56:13 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 5 Apr 2021 14:56:13 -0600
Subject: [PATCH v5 09/10] coresight: syscfg: Add initial configfs support
In-Reply-To: <20210316180400.7184-10-mike.leach@linaro.org>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-10-mike.leach@linaro.org>
Message-ID: <20210405205613.GE145043@xps15>

On Tue, Mar 16, 2021 at 06:03:59PM +0000, Mike Leach wrote:
> Adds configfs subsystem and attributes to the configuration manager
> to enable the listing of loaded configurations and features.
> 
> The default values of feature parameters can be accessed and altered
> from these attributes to affect all installed devices using the feature.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> ---
>  drivers/hwtracing/coresight/Makefile          |   3 +-
>  .../coresight/coresight-syscfg-configfs.c     | 399 ++++++++++++++++++
>  .../coresight/coresight-syscfg-configfs.h     |  45 ++
>  .../hwtracing/coresight/coresight-syscfg.c    |  77 ++++
>  .../hwtracing/coresight/coresight-syscfg.h    |   7 +
>  5 files changed, 530 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> 
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 2707bfef1b76..391c93a08902 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -5,7 +5,8 @@
>  obj-$(CONFIG_CORESIGHT) += coresight.o
>  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
>  		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
> -		coresight-cfg-preload.o coresight-cfg-afdo.o
> +		coresight-cfg-preload.o coresight-cfg-afdo.o \
> +		coresight-syscfg-configfs.o
>  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
>  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
>  		      coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> new file mode 100644
> index 000000000000..7cefad81d1f6
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> @@ -0,0 +1,399 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Linaro Limited, All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +#include <linux/configfs.h>
> +
> +#include "coresight-syscfg-configfs.h"
> +
> +/* create a default ci_type. */
> +static inline struct config_item_type *cscfg_create_ci_type(void)
> +{
> +	struct config_item_type *ci_type;
> +
> +	ci_type = devm_kzalloc(cscfg_device(), sizeof(*ci_type), GFP_KERNEL);
> +	if (ci_type)
> +		ci_type->ct_owner = THIS_MODULE;
> +
> +	return ci_type;
> +}
> +
> +/* configurations sub-group */
> +
> +/* attributes for the config view group */
> +static ssize_t cscfg_cfg_description_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> +							 struct cscfg_fs_config, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%s\n", fs_config->config_desc->description);
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, description);
> +
> +static ssize_t cscfg_cfg_feature_refs_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> +							 struct cscfg_fs_config, group);
> +	const struct cscfg_config_desc *config_desc = fs_config->config_desc;
> +	ssize_t ch_used = 0;
> +	int i;
> +
> +	if (config_desc->nr_feat_refs) {

This check isn't needed.

> +		for (i = 0; i < config_desc->nr_feat_refs; i++) {
> +			ch_used += scnprintf(page + ch_used, PAGE_SIZE - ch_used,
> +					     "%s\n", config_desc->feat_ref_names[i]);
> +		}
> +	}
> +	return ch_used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, feature_refs);
> +
> +/* list preset values in order of features and params */
> +static ssize_t cscfg_cfg_values_show(struct config_item *item, char *page)
> +{
> +	const struct cscfg_feature_desc *feat_desc;
> +	const struct cscfg_config_desc *config_desc;
> +	struct cscfg_fs_preset *fs_preset;
> +	int i, j, val_idx, preset_idx;
> +	ssize_t used = 0;
> +
> +	fs_preset = container_of(to_config_group(item), struct cscfg_fs_preset, group);
> +	config_desc = fs_preset->config_desc;
> +
> +	if (!config_desc->nr_presets)
> +		return 0;
> +
> +	preset_idx = fs_preset->preset_num - 1;
> +
> +	/* start index on the correct array line */
> +	val_idx = config_desc->nr_total_params * preset_idx;
> +
> +	/*
> +	 * A set of presets is the sum of all params in used features,
> +	 * in order of declaration of features and params in the features
> +	 */
> +	for (i = 0; i < config_desc->nr_feat_refs; i++) {
> +		feat_desc = cscfg_get_named_feat_desc(config_desc->feat_ref_names[i]);
> +		for (j = 0; j < feat_desc->nr_params; j++) {
> +			used += scnprintf(page + used, PAGE_SIZE - used,
> +					  "%s.%s = 0x%llx ",
> +					  feat_desc->name,
> +					  feat_desc->params_desc[j].name,
> +					  config_desc->presets[val_idx++]);
> +		}
> +	}
> +	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> +
> +	return used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, values);
> +
> +static struct configfs_attribute *cscfg_config_view_attrs[] = {
> +	&cscfg_cfg_attr_description,
> +	&cscfg_cfg_attr_feature_refs,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_config_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_config_view_attrs,
> +};
> +
> +static struct configfs_attribute *cscfg_config_preset_attrs[] = {
> +	&cscfg_cfg_attr_values,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_config_preset_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_config_preset_attrs,
> +};
> +
> +static int cscfg_add_preset_groups(struct cscfg_fs_config *cfg_view)
> +{
> +	int preset_num;
> +	struct cscfg_fs_preset *cfg_fs_preset;
> +	struct cscfg_config_desc *config_desc = cfg_view->config_desc;
> +	char name[CONFIGFS_ITEM_NAME_LEN];
> +
> +	if (!config_desc->nr_presets)
> +		return 0;
> +
> +	for (preset_num = 1; preset_num <= config_desc->nr_presets; preset_num++) {
> +		cfg_fs_preset = devm_kzalloc(cscfg_device(),
> +					     sizeof(struct cscfg_fs_preset), GFP_KERNEL);
> +
> +		if (!cfg_fs_preset)
> +			return -ENOMEM;
> +
> +		snprintf(name, CONFIGFS_ITEM_NAME_LEN, "preset%d", preset_num);
> +		cfg_fs_preset->preset_num = preset_num;
> +		cfg_fs_preset->config_desc = cfg_view->config_desc;
> +		config_group_init_type_name(&cfg_fs_preset->group, name,
> +					    &cscfg_config_preset_type);
> +		configfs_add_default_group(&cfg_fs_preset->group, &cfg_view->group);
> +	}
> +	return 0;
> +}
> +
> +static struct config_group *cscfg_create_config_group(struct cscfg_config_desc *config_desc)
> +{
> +	struct cscfg_fs_config *cfg_view;
> +	struct device *dev = cscfg_device();
> +	int err;
> +
> +	if (!dev)
> +		return ERR_PTR(-EINVAL);
> +
> +	cfg_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_config), GFP_KERNEL);
> +	if (!cfg_view)
> +		return ERR_PTR(-ENOMEM);
> +
> +	cfg_view->config_desc = config_desc;
> +	config_group_init_type_name(&cfg_view->group, config_desc->name, &cscfg_config_view_type);
> +
> +	/* add in a preset<n> dir for each preset */
> +	err = cscfg_add_preset_groups(cfg_view);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	return &cfg_view->group;
> +}
> +
> +/* attributes for features view */
> +
> +static ssize_t cscfg_feat_description_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%s\n", fs_feat->feat_desc->description);

Either remove the '\n' at the end of fs_feat->feat_desc->description or above,
with a preference toward the former.  The same thing should be done for
cscfg_cfg_description_show().

Otherwise it creates and exta new line when quering from the command line and it
is only a matter of time before the automated tools point it out.

> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, description);
> +
> +static ssize_t cscfg_feat_matches_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +	u32 match_flags = fs_feat->feat_desc->match_flags;
> +	int used = 0;
> +
> +	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL)
> +		used = scnprintf(page, PAGE_SIZE, "SRC_ALL ");
> +
> +	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4)
> +		used += scnprintf(page + used, PAGE_SIZE - used, "SRC_ETMV4 ");
> +
> +	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> +	return used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, matches);
> +
> +static ssize_t cscfg_feat_nr_params_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%d\n", fs_feat->feat_desc->nr_params);
> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, nr_params);
> +
> +/* base feature desc attrib structures */
> +static struct configfs_attribute *cscfg_feature_view_attrs[] = {
> +	&cscfg_feat_attr_description,
> +	&cscfg_feat_attr_matches,
> +	&cscfg_feat_attr_nr_params,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_feature_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_feature_view_attrs,
> +};
> +
> +static ssize_t cscfg_param_value_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> +							 struct cscfg_fs_param, group);
> +	u64 value = param_item->feat_desc->params_desc[param_item->param_idx].value;
> +
> +	return scnprintf(page, PAGE_SIZE, "0x%llx\n", value);
> +}
> +
> +static ssize_t cscfg_param_value_store(struct config_item *item,
> +				       const char *page, size_t size)
> +{
> +	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> +							 struct cscfg_fs_param, group);
> +	struct cscfg_feature_desc *feat_desc = param_item->feat_desc;
> +	int param_idx = param_item->param_idx;
> +	u64 value;
> +	int err;
> +
> +	err = kstrtoull(page, 0, &value);
> +	if (!err)
> +		err = cscfg_update_feat_param_val(feat_desc, param_idx, value);
> +
> +	return err ? err : size;
> +}
> +CONFIGFS_ATTR(cscfg_param_, value);
> +
> +static struct configfs_attribute *cscfg_param_view_attrs[] = {
> +	&cscfg_param_attr_value,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_param_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_param_view_attrs,
> +};
> +
> +/*
> + * configfs has far less functionality provided to add attributes dynamically than sysfs,
> + * and the show and store fns pass the enclosing config_item so the actual attribute cannot
> + * be determined. Therefore we add each item as a group directory, with a value attribute.
> + */
> +static int cscfg_create_params_group_items(struct cscfg_feature_desc *feat_desc,
> +					   struct config_group *params_group)
> +{
> +	struct device *dev = cscfg_device();
> +	struct cscfg_fs_param *param_item;
> +	int i;
> +
> +	/* parameter items - as groups with default_value attribute */
> +	for (i = 0; i < feat_desc->nr_params; i++) {
> +		param_item = devm_kzalloc(dev, sizeof(struct cscfg_fs_param), GFP_KERNEL);
> +		if (!param_item)
> +			return -ENOMEM;
> +		param_item->feat_desc = feat_desc;
> +		param_item->param_idx = i;
> +		config_group_init_type_name(&param_item->group,
> +					    feat_desc->params_desc[i].name,
> +					    &cscfg_param_view_type);
> +		configfs_add_default_group(&param_item->group, params_group);
> +	}
> +	return 0;
> +}
> +
> +static struct config_group *cscfg_create_feature_group(struct cscfg_feature_desc *feat_desc)
> +{
> +	struct cscfg_fs_feature *feat_view;
> +	struct config_item_type *params_group_type;
> +	struct config_group *params_group = NULL;
> +	struct device *dev = cscfg_device();
> +	int item_err;
> +
> +	if (!dev)
> +		return ERR_PTR(-EINVAL);
> +
> +	feat_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_feature), GFP_KERNEL);
> +	if (!feat_view)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (feat_desc->nr_params) {
> +		params_group = devm_kzalloc(dev, sizeof(struct config_group), GFP_KERNEL);
> +		if (!params_group)
> +			return ERR_PTR(-ENOMEM);
> +
> +		params_group_type = cscfg_create_ci_type();
> +		if (!params_group_type)
> +			return ERR_PTR(-ENOMEM);
> +	}
> +
> +	feat_view->feat_desc = feat_desc;
> +	config_group_init_type_name(&feat_view->group,
> +				    feat_desc->name,
> +				    &cscfg_feature_view_type);
> +	if (params_group) {
> +		config_group_init_type_name(params_group, "params", params_group_type);
> +		configfs_add_default_group(params_group, &feat_view->group);
> +		item_err = cscfg_create_params_group_items(feat_desc, params_group);
> +		if (item_err)
> +			return ERR_PTR(item_err);
> +	}
> +	return &feat_view->group;
> +}
> +
> +static struct config_item_type cscfg_configs_type = {
> +	.ct_owner = THIS_MODULE,
> +};
> +
> +static struct config_group cscfg_configs_grp = {
> +	.cg_item = {
> +		.ci_namebuf = "configurations",
> +		.ci_type = &cscfg_configs_type,
> +	},
> +};
> +
> +/* add configuration to configurations group */
> +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc)
> +{
> +	struct config_group *new_group;
> +	int err;
> +
> +	new_group = cscfg_create_config_group(config_desc);
> +	if (IS_ERR(new_group))
> +		return PTR_ERR(new_group);
> +	err =  configfs_register_group(&cscfg_configs_grp, new_group);
> +	return err;
> +}
> +
> +static struct config_item_type cscfg_features_type = {
> +	.ct_owner = THIS_MODULE,
> +};
> +
> +static struct config_group cscfg_features_grp = {
> +	.cg_item = {
> +		.ci_namebuf = "features",
> +		.ci_type = &cscfg_features_type,
> +	},
> +};
> +
> +/* add feature to features group */
> +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc)
> +{
> +	struct config_group *new_group;
> +	int err;
> +
> +	new_group = cscfg_create_feature_group(feat_desc);
> +	if (IS_ERR(new_group))
> +		return PTR_ERR(new_group);
> +	err =  configfs_register_group(&cscfg_features_grp, new_group);
> +	return err;
> +}
> +
> +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr)
> +{
> +	struct configfs_subsystem *subsys;
> +	struct config_item_type *ci_type;
> +
> +	if (!cscfg_mgr)
> +		return -EINVAL;
> +
> +	ci_type = cscfg_create_ci_type();
> +	if (!ci_type)
> +		return -ENOMEM;
> +
> +	subsys = &cscfg_mgr->cfgfs_subsys;
> +	config_item_set_name(&subsys->su_group.cg_item, CSCFG_FS_SUBSYS_NAME);
> +	subsys->su_group.cg_item.ci_type = ci_type;
> +
> +	config_group_init(&subsys->su_group);
> +	mutex_init(&subsys->su_mutex);
> +
> +	/* Add default groups to subsystem */
> +	config_group_init(&cscfg_configs_grp);
> +	configfs_add_default_group(&cscfg_configs_grp, &subsys->su_group);
> +
> +	config_group_init(&cscfg_features_grp);
> +	configfs_add_default_group(&cscfg_features_grp, &subsys->su_group);
> +
> +	return configfs_register_subsystem(subsys);
> +}
> +
> +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr)
> +{
> +	configfs_unregister_subsystem(&cscfg_mgr->cfgfs_subsys);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.h b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> new file mode 100644
> index 000000000000..7d6ffe35ca4c
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Coresight system configuration driver - support for configfs.
> + */
> +
> +#ifndef CORESIGHT_SYSCFG_CONFIGFS_H
> +#define CORESIGHT_SYSCFG_CONFIGFS_H
> +
> +#include <linux/configfs.h>
> +#include "coresight-syscfg.h"
> +
> +#define CSCFG_FS_SUBSYS_NAME "cs-syscfg"
> +
> +/* container for configuration view */
> +struct cscfg_fs_config {
> +	struct cscfg_config_desc *config_desc;
> +	struct config_group group;
> +};
> +
> +/* container for feature view */
> +struct cscfg_fs_feature {
> +	struct cscfg_feature_desc *feat_desc;
> +	struct config_group group;
> +};
> +
> +/* container for parameter view */
> +struct cscfg_fs_param {
> +	int param_idx;
> +	struct cscfg_feature_desc *feat_desc;
> +	struct config_group group;
> +};
> +
> +/* container for preset view */
> +struct cscfg_fs_preset {
> +	int preset_num;
> +	struct cscfg_config_desc *config_desc;
> +	struct config_group group;
> +};
> +
> +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr);
> +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr);
> +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc);
> +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc);
> +
> +#endif /* CORESIGHT_SYSCFG_CONFIGFS_H */
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> index befc379b85b9..3be3828a40a7 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> @@ -9,6 +9,7 @@
>  #include "coresight-config.h"
>  #include "coresight-etm-perf.h"
>  #include "coresight-syscfg.h"
> +#include "coresight-syscfg-configfs.h"
>  
>  /*
>   * cscfg_ API manages configurations and features for the entire coresight
> @@ -288,6 +289,72 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
>  	return 0;
>  }
>  
> +/* get a feature descriptor by name */
> +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name)
> +{
> +	const struct cscfg_feature_desc *feat_desc = NULL, *feat_desc_item;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	list_for_each_entry(feat_desc_item, &cscfg_mgr->feat_desc_list, item) {
> +		if (strcmp(feat_desc_item->name, name) == 0) {
> +			feat_desc = feat_desc_item;
> +			break;
> +		}
> +	}
> +
> +	mutex_unlock(&cscfg_mutex);
> +	return feat_desc;
> +}
> +
> +/* called with cscfg_mutex held */
> +static struct cscfg_feature_csdev *
> +cscfg_csdev_get_feat_from_desc(struct coresight_device *csdev,
> +			       struct cscfg_feature_desc *feat_desc)
> +{
> +	struct cscfg_feature_csdev *feat_csdev;
> +
> +	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
> +		if (feat_csdev->feat_desc == feat_desc)
> +			return feat_csdev;
> +	}
> +	return NULL;
> +}
> +
> +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> +				int param_idx, u64 value)
> +{
> +	int err = 0;
> +	struct cscfg_feature_csdev *feat_csdev;
> +	struct cscfg_registered_csdev *csdev_item;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	/* check if any config active & return busy */
> +	if (atomic_read(&cscfg_mgr->sys_active_cnt)) {
> +		err = -EBUSY;
> +		goto unlock_exit;
> +	}
> +
> +	/* set the value */
> +	if ((param_idx < 0) || (param_idx >= feat_desc->nr_params)) {
> +		err = -EINVAL;
> +		goto unlock_exit;
> +	}
> +	feat_desc->params_desc[param_idx].value = value;
> +
> +	/* update loaded instances.*/
> +	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
> +		feat_csdev = cscfg_csdev_get_feat_from_desc(csdev_item->csdev, feat_desc);
> +		if (feat_csdev)
> +			feat_csdev->params_csdev[param_idx].current_value = value;
> +	}
> +
> +unlock_exit:
> +	mutex_unlock(&cscfg_mutex);
> +	return err;
> +}
> +
>  /*
>   * External API function to load feature and config sets.
>   * Take a 0 terminated array of feature descriptors and/or configuration
> @@ -305,6 +372,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
>  	if (feat_descs) {
>  		while (feat_descs[i]) {
>  			err = cscfg_load_feat(feat_descs[i]);
> +			if (!err)
> +				err = cscfg_configfs_add_feature(feat_descs[i]);
>  			if (err) {
>  				pr_err("coresight-syscfg: Failed to load feature %s\n",
>  				       feat_descs[i]->name);
> @@ -319,6 +388,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
>  	if (config_descs) {
>  		while (config_descs[i]) {
>  			err = cscfg_load_config(config_descs[i]);
> +			if (!err)
> +				err = cscfg_configfs_add_config(config_descs[i]);
>  			if (err) {
>  				pr_err("coresight-syscfg: Failed to load configuration %s\n",
>  				       config_descs[i]->name);
> @@ -608,6 +679,7 @@ int cscfg_create_device(void)
>  	dev->init_name = "cs_system_cfg";
>  
>  	err = device_register(dev);
> +

Spurious change

I am done reviewing your work.  Before sending another revision please
ensure everything works properly when applied on top of the ETE/TRBE patchset[1].
It applies correctly but I'm not sure it does the right thing, especially in
etm_setup_aux() with the per CPU handle changes that have been introduced.

Thanks,
Mathieu

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-ETE-TRBE


>  	if (err)
>  		cscfg_dev_release(dev);
>  
> @@ -624,6 +696,7 @@ void cscfg_clear_device(void)
>  	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
>  		etm_perf_del_symlink_cscfg(cfg_desc);
>  	}
> +	cscfg_configfs_release(cscfg_mgr);
>  	device_unregister(cscfg_device());
>  	mutex_unlock(&cscfg_mutex);
>  }
> @@ -637,6 +710,10 @@ int __init cscfg_init(void)
>  	if (err)
>  		return err;
>  
> +	err = cscfg_configfs_init(cscfg_mgr);
> +	if (err)
> +		goto exit_err;
> +
>  	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
> index 7bb8c8e497ba..8d018efd6ead 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.h
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.h
> @@ -6,6 +6,7 @@
>  #ifndef CORESIGHT_SYSCFG_H
>  #define CORESIGHT_SYSCFG_H
>  
> +#include <linux/configfs.h>
>  #include <linux/coresight.h>
>  #include <linux/device.h>
>  
> @@ -25,6 +26,7 @@
>   * @feat_desc_list:	List of feature descriptors to load into registered devices.
>   * @config_desc_list:	List of system configuration descriptors to load into registered devices.
>   * @sys_active_cnt:	Total number of active config descriptor references.
> + * @cfgfs_subsys:	configfs subsystem used to manage configurations.
>   */
>  struct cscfg_manager {
>  	struct device dev;
> @@ -32,6 +34,7 @@ struct cscfg_manager {
>  	struct list_head feat_desc_list;
>  	struct list_head config_desc_list;
>  	atomic_t sys_active_cnt;
> +	struct configfs_subsystem cfgfs_subsys;
>  };
>  
>  /* get reference to dev in cscfg_manager */
> @@ -57,6 +60,10 @@ struct cscfg_registered_csdev {
>  int __init cscfg_init(void);
>  void cscfg_exit(void);
>  int cscfg_preload(void);
> +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name);
> +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> +				int param_idx, u64 value);
> +
>  
>  /* syscfg manager external API */
>  int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
> -- 
> 2.17.1
> 


From martin.blumenstingl at googlemail.com  Mon Apr  5 21:56:34 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Mon, 5 Apr 2021 22:56:34 +0200
Subject: [PATCH 2/3] arm64: dts: meson: add saradc node to ODROID N2/N2+
In-Reply-To: <20210329161256.31171-3-christianshewitt@gmail.com>
References: <20210329161256.31171-1-christianshewitt@gmail.com>
 <20210329161256.31171-3-christianshewitt@gmail.com>
Message-ID: <CAFBinCAJMvdus+bUjDpJxrATfifG7BstdKi=x_yUEYH0RqhJUQ@mail.gmail.com>

On Tue, Mar 30, 2021 at 1:18 AM Christian Hewitt
<christianshewitt at gmail.com> wrote:
>
> From: Hyeonki Hong <hhk7734 at gmail.com>
>
> Add the meson saradc node to the ODROID N2/N2+ common dtsi.
in general I am fine with this as some SAR ADC channels seem to be on
the pin headers...

[...]
> +&saradc {
> +       status = "okay";
> +};
...but a vref-supply should be provided to get meaningful numbers


From andrew at lunn.ch  Mon Apr  5 22:25:17 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 5 Apr 2021 23:25:17 +0200
Subject: [PATCH 1/2] of: net: pass the dst buffer to of_get_mac_address()
In-Reply-To: <202104060306.lmTxeOmW-lkp@intel.com>
References: <20210405164643.21130-2-michael@walle.cc>
 <202104060306.lmTxeOmW-lkp@intel.com>
Message-ID: <YGuAPb1+AcFTOYdq@lunn.ch>

On Tue, Apr 06, 2021 at 03:19:11AM +0800, kernel test robot wrote:
> Hi Michael,
> 
> I love your patch! Yet something to improve:

Looks correct. You missed the #else case for #ifdef CONFIG_OF in
stmmac_platform.c

Lets see what else 0-day finds before i start reviewing.

      Andrew


From sfr at canb.auug.org.au  Mon Apr  5 23:11:00 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 6 Apr 2021 08:11:00 +1000
Subject: linux-next: Signed-off-by missing for commit in the arm-soc tree
Message-ID: <20210406081100.4a866aa6@canb.auug.org.au>

Hi all,

Commit

  3b493ac0ac04 ("arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices")

is missing a Signed-off-by from its 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/20210406/6e1fb616/attachment.sig>

From sfr at canb.auug.org.au  Mon Apr  5 23:11:47 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 6 Apr 2021 08:11:47 +1000
Subject: linux-next: Signed-off-by missing for commit in the arm-soc tree
In-Reply-To: <20210406081100.4a866aa6@canb.auug.org.au>
References: <20210406081100.4a866aa6@canb.auug.org.au>
Message-ID: <20210406081147.7a5332ed@canb.auug.org.au>

Hi all,

On Tue, 6 Apr 2021 08:11:00 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> Hi all,
> 
> Commit
> 
>   3b493ac0ac04 ("arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices")
> 
> is missing a Signed-off-by from its committer.

Sorry, that commit is in the arm-soc-fixes 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/20210406/17236609/attachment.sig>

From rafal at milecki.pl  Mon Apr  5 23:44:47 2021
From: rafal at milecki.pl (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Tue, 6 Apr 2021 00:44:47 +0200
Subject: [PATCH robh next] dt-bindings: bus: add Broadcom CRU
In-Reply-To: <20210309142241.16259-1-zajec5@gmail.com>
References: <20210309142241.16259-1-zajec5@gmail.com>
Message-ID: <e974306d-8a53-00ca-76c4-c3bea505d334@milecki.pl>

Hi Rob,

On 09.03.2021 15:22, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> CRU is a block used in Northstar devices. It can be seen in the
> bcm5301x.dtsi and this binding documents its proper usage.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>

could you review and push or reject this patch, please?


From khilman at baylibre.com  Mon Apr  5 23:48:18 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 05 Apr 2021 15:48:18 -0700
Subject: [GIT PULL] arm64: dts: amlogic updates for v5.13
Message-ID: <7h5z10mjpp.fsf@baylibre.com>

The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:

  Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64

for you to fetch changes up to 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e:

  arm64: dts: meson: add initial device-tree for MeCool KIII Pro (2021-04-05 15:35:39 -0700)

----------------------------------------------------------------
arm64: dts: amlogic updates for v5.13
- new boards: MeCool KII & KIII, Minix NEO U9-H
- used fixed index for MMC devices

----------------------------------------------------------------
Alexander Stein (1):
      arm64: dts: amlogic: Assign a fixed index to mmc devices

Christian Hewitt (5):
      dt-bindings: arm: amlogic: add support for the Minix NEO U9-H
      arm64: dts: meson: add initial device-tree for Minix NEO U9-H
      dt-bindings: arm: amlogic: add MeCool KII/KIII Pro bindings
      arm64: dts: meson: add initial device-tree for MeCool KII Pro
      arm64: dts: meson: add initial device-tree for MeCool KIII Pro

 Documentation/devicetree/bindings/arm/amlogic.yaml             |   3 +++
 arch/arm64/boot/dts/amlogic/Makefile                           |   3 +++
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi              |   6 +++++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi                      |   6 +++++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts |  86 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts      | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts        | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts


From mhiramat at kernel.org  Tue Apr  6 00:39:45 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Tue, 6 Apr 2021 08:39:45 +0900
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <380d0437-e205-5eab-3664-f17aa9adc3eb@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
 <20210405222436.4fda9a930676d95e862744af@kernel.org>
 <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>
 <380d0437-e205-5eab-3664-f17aa9adc3eb@linux.microsoft.com>
Message-ID: <20210406083945.0ae2f3ca8f02b59759c891b1@kernel.org>

On Mon, 5 Apr 2021 12:12:08 -0500
"Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:

> 
> 
> On 4/5/21 9:56 AM, Madhavan T. Venkataraman wrote:
> > 
> > 
> > On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> >> Hi Madhaven,
> >>
> >> On Sat, 3 Apr 2021 22:29:12 -0500
> >> "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:
> >>
> >>
> >>>>> Check for kretprobe
> >>>>> ===================
> >>>>>
> >>>>> For functions with a kretprobe set up, probe code executes on entry
> >>>>> to the function and replaces the return address in the stack frame with a
> >>>>> kretprobe trampoline. Whenever the function returns, control is
> >>>>> transferred to the trampoline. The trampoline eventually returns to the
> >>>>> original return address.
> >>>>>
> >>>>> A stack trace taken while executing in the function (or in functions that
> >>>>> get called from the function) will not show the original return address.
> >>>>> Similarly, a stack trace taken while executing in the trampoline itself
> >>>>> (and functions that get called from the trampoline) will not show the
> >>>>> original return address. This means that the caller of the probed function
> >>>>> will not show. This makes the stack trace unreliable.
> >>>>>
> >>>>> Add the kretprobe trampoline to special_functions[].
> >>>>>
> >>>>> FYI, each task contains a task->kretprobe_instances list that can
> >>>>> theoretically be consulted to find the orginal return address. But I am
> >>>>> not entirely sure how to safely traverse that list for stack traces
> >>>>> not on the current process. So, I have taken the easy way out.
> >>>>
> >>>> For kretprobes, unwinding from the trampoline or kretprobe handler
> >>>> shouldn't be a reliability concern for live patching, for similar
> >>>> reasons as above.
> >>>>
> >>>
> >>> Please see previous answer.
> >>>
> >>>> Otherwise, when unwinding from a blocked task which has
> >>>> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
> >>>> original return address.  Masami has been working on an interface to
> >>>> make that possible for x86.  I assume something similar could be done
> >>>> for arm64.
> >>>>
> >>>
> >>> OK. Until that is available, this case needs to be addressed.
> >>
> >> Actually, I've done that on arm64 :) See below patch.
> >> (and I also have a similar code for arm32, what I'm considering is how
> >> to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
> >> similar.)
> >>
> >> This is applicable on my x86 series v5
> >>
> >> https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/
> >>
> >> Thank you,
> >>
> >>
> > 
> > I took a brief look at your changes. Looks reasonable.
> > 
> > However, for now, I am going to include the kretprobe_trampoline in the special_functions[]
> > array until your changes are merged. At that point, it is just a matter of deleting
> > kretprobe_trampoline from the special_functions[] array. That is all.
> > 
> > I hope that is fine with everyone.
> > 
> 
> Actually, there may still be a problem to solve.
> 
> If arch_stack_walk_reliable() is ever called from within kretprobe_trampoline() for debugging or
> other purposes after the instance is deleted from the task instance list, it would not be able
> to retrieve the original return address.
> 
> The stack trace would be unreliable in that case, would it not?

Good catch! I'm preparing a patch to fix that case (currently only for x86, see below).
This is currently only for x86. Arm64 kretprobe may have to modify its stack
layout similar to x86 so that unwinder can find the return address from
stack.

Thank you,

>From cdca74a1ebc174062eb99a376072002ae21f7d7e Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu <mhiramat at kernel.org>
Date: Mon, 8 Mar 2021 00:22:51 +0900
Subject: [PATCH] x86/kprobes: Fixup return address in generic trampoline
 handler

In x86, kretprobe trampoline address on the stack frame will
be replaced with the real return address after returning from
trampoline_handler. Before fixing the return address, the real
return address can be found in the current->kretprobe_instances.

However, since there is a window between updating the
current->kretprobe_instances and fixing the address on the stack,
if an interrupt caused at that timing and the interrupt handler
does stacktrace, it may fail to unwind because it can not get
the correct return address from current->kretprobe_instances.

This will minimize that window by fixing the return address
right before updating current->kretprobe_instances.

Signed-off-by: Masami Hiramatsu <mhiramat at kernel.org>
---
 arch/x86/kernel/kprobes/core.c | 14 ++++++++++++--
 kernel/kprobes.c               |  8 ++++++++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 00c5944ae8f6..950b8e873937 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -1032,6 +1032,7 @@ STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
 #undef UNWIND_HINT_FUNC
 #define UNWIND_HINT_FUNC
 #endif
+
 /*
  * When a retprobed function returns, this code saves registers and
  * calls trampoline_handler() runs, which calls the kretprobe's handler.
@@ -1073,6 +1074,16 @@ asm(
 );
 NOKPROBE_SYMBOL(kretprobe_trampoline);
 
+void arch_kretprobe_fixup_return(struct pt_regs *regs,
+				 unsigned long correct_ret_addr)
+{
+	unsigned long *frame_pointer;
+	frame_pointer = ((unsigned long *)&regs->sp) + 1;
+
+	/* Replace fake return address with real one. */
+	*frame_pointer = correct_ret_addr;
+}
+
 /*
  * Called from kretprobe_trampoline
  */
@@ -1090,8 +1101,7 @@ __used __visible void trampoline_handler(struct pt_regs *regs)
 	regs->sp += sizeof(long);
 	frame_pointer = ((unsigned long *)&regs->sp) + 1;
 
-	/* Replace fake return address with real one. */
-	*frame_pointer = kretprobe_trampoline_handler(regs, frame_pointer);
+	kretprobe_trampoline_handler(regs, frame_pointer);
 	/*
 	 * Move flags to sp so that kretprobe_trapmoline can return
 	 * right after popf.
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 12677a463561..3c72df5b31dd 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1899,6 +1899,12 @@ unsigned long __weak kretprobe_find_ret_addr(struct task_struct *tsk,
 }
 NOKPROBE_SYMBOL(kretprobe_find_ret_addr);
 
+void __weak arch_kretprobe_fixup_return(struct pt_regs *regs,
+					unsigned long correct_ret_addr)
+{
+	/* Do nothing by default. */
+}
+
 unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs,
 					     void *frame_pointer)
 {
@@ -1939,6 +1945,8 @@ unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs,
 		first = first->next;
 	}
 
+	arch_kretprobe_fixup_return(regs, (unsigned long)correct_ret_addr);
+
 	/* Unlink all nodes for this frame. */
 	first = current->kretprobe_instances.first;
 	current->kretprobe_instances.first = node->next;
-- 
2.25.1





-- 
Masami Hiramatsu <mhiramat at kernel.org>


From mhiramat at kernel.org  Tue Apr  6 00:40:46 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Tue, 6 Apr 2021 08:40:46 +0900
Subject: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210403170159.gegqjrsrg7jshlne@treble>
 <bd13a433-c060-c501-8e76-5e856d77a225@linux.microsoft.com>
 <20210405222436.4fda9a930676d95e862744af@kernel.org>
 <7dda9af3-1ecf-5e6f-1e46-8870a2a5e550@linux.microsoft.com>
Message-ID: <20210406084046.4f0b946728dc01da09045338@kernel.org>

On Mon, 5 Apr 2021 09:56:48 -0500
"Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:

> 
> 
> On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
> > Hi Madhaven,
> > 
> > On Sat, 3 Apr 2021 22:29:12 -0500
> > "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com> wrote:
> > 
> > 
> >>>> Check for kretprobe
> >>>> ===================
> >>>>
> >>>> For functions with a kretprobe set up, probe code executes on entry
> >>>> to the function and replaces the return address in the stack frame with a
> >>>> kretprobe trampoline. Whenever the function returns, control is
> >>>> transferred to the trampoline. The trampoline eventually returns to the
> >>>> original return address.
> >>>>
> >>>> A stack trace taken while executing in the function (or in functions that
> >>>> get called from the function) will not show the original return address.
> >>>> Similarly, a stack trace taken while executing in the trampoline itself
> >>>> (and functions that get called from the trampoline) will not show the
> >>>> original return address. This means that the caller of the probed function
> >>>> will not show. This makes the stack trace unreliable.
> >>>>
> >>>> Add the kretprobe trampoline to special_functions[].
> >>>>
> >>>> FYI, each task contains a task->kretprobe_instances list that can
> >>>> theoretically be consulted to find the orginal return address. But I am
> >>>> not entirely sure how to safely traverse that list for stack traces
> >>>> not on the current process. So, I have taken the easy way out.
> >>>
> >>> For kretprobes, unwinding from the trampoline or kretprobe handler
> >>> shouldn't be a reliability concern for live patching, for similar
> >>> reasons as above.
> >>>
> >>
> >> Please see previous answer.
> >>
> >>> Otherwise, when unwinding from a blocked task which has
> >>> 'kretprobe_trampoline' on the stack, the unwinder needs a way to get the
> >>> original return address.  Masami has been working on an interface to
> >>> make that possible for x86.  I assume something similar could be done
> >>> for arm64.
> >>>
> >>
> >> OK. Until that is available, this case needs to be addressed.
> > 
> > Actually, I've done that on arm64 :) See below patch.
> > (and I also have a similar code for arm32, what I'm considering is how
> > to unify x86/arm/arm64 kretprobe_find_ret_addr(), since those are very
> > similar.)
> > 
> > This is applicable on my x86 series v5
> > 
> > https://lore.kernel.org/bpf/161676170650.330141.6214727134265514123.stgit at devnote2/
> > 
> > Thank you,
> > 
> > 
> 
> I took a brief look at your changes. Looks reasonable.
> 
> However, for now, I am going to include the kretprobe_trampoline in the special_functions[]
> array until your changes are merged. At that point, it is just a matter of deleting
> kretprobe_trampoline from the special_functions[] array. That is all.
> 
> I hope that is fine with everyone.

Agreed, that is reasonable unless my series is merged. 

Thank you,


-- 
Masami Hiramatsu <mhiramat at kernel.org>


From lkp at intel.com  Tue Apr  6 01:23:58 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 6 Apr 2021 08:23:58 +0800
Subject: [PATCH 2/5] arm64: dts: mediatek: mt8167: add smi_common node
In-Reply-To: <20210405200821.2203458-2-fparent@baylibre.com>
References: <20210405200821.2203458-2-fparent@baylibre.com>
Message-ID: <202104060814.berYSn6V-lkp@intel.com>

Hi Fabien,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on arm/for-next keystone/next soc/for-next rockchip/for-next arm64/for-next/core shawnguo/for-next clk/clk-next v5.12-rc6 next-20210401]
[cannot apply to xlnx/master]
[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]

url:    https://github.com/0day-ci/linux/commits/Fabien-Parent/arm64-dts-mediatek-mt8167-add-mmsys-node/20210406-041016
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r011-20210406 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 2760a808b9916a2839513b7fd7314a464f52481e)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/0day-ci/linux/commit/bbbf216a8432b5af475e4e709bf481475c1af58f
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Fabien-Parent/arm64-dts-mediatek-mt8167-add-mmsys-node/20210406-041016
        git checkout bbbf216a8432b5af475e4e709bf481475c1af58f
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/mediatek/mt8167.dtsi:73.26-27 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35029 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210406/969c0742/attachment-0001.gz>

From sfr at canb.auug.org.au  Tue Apr  6 01:45:11 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 6 Apr 2021 10:45:11 +1000
Subject: linux-next: build warning after merge of the arm-soc tree
Message-ID: <20210406104511.2535b830@canb.auug.org.au>

Hi all,

After merging the arm-soc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/clk/socfpga/clk-gate.c: In function 'socfpga_clk_recalc_rate':
drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  102 |   if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
      |       ^

Exposed by commit

  cdb1e8b4f4c2 ("clk: socfpga: allow compile testing of Stratix 10 / Agilex clocks")
  552418658acd ("clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile test)")

-- 
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/20210406/8f66a97e/attachment.sig>

From evanbenn at chromium.org  Tue Apr  6 02:01:04 2021
From: evanbenn at chromium.org (Evan Benn)
Date: Tue, 6 Apr 2021 11:01:04 +1000
Subject: [PATCH v2] drivers/clocksource/mediatek: Ack and disable
 interrupts on shutdown
In-Reply-To: <67eed9a2-2b97-be1b-3290-948da662ea65@linaro.org>
References: <20210325123446.v2.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid>
 <049946ac-5263-21ee-9651-7295f0bcf387@linaro.org>
 <CAP8nV8rv6bKARZ31fVqcjVgMe+5UyVG8UAyNsm1hDCP2BbRSgw@mail.gmail.com>
 <67eed9a2-2b97-be1b-3290-948da662ea65@linaro.org>
Message-ID: <CAKz_xw1ZSuvqnBHDRVLAV3FZKuen0F9L+gjjP=Hedo6G74ow4w@mail.gmail.com>

On Sat, Apr 3, 2021 at 1:15 AM Daniel Lezcano <daniel.lezcano at linaro.org> wrote:
> >
> > That said I am happy to upload that version if people think it is better.
>
> IMO, it is not in the normal flow to disable/enable the interrupts.

Hi Daniel, no problem.

I will upload the suspend/resume version. Please note the similar fix
to the other timer in this file:

https://patchwork.kernel.org/project/linux-mediatek/patch/1614670085-26229-2-git-send-email-Fengquan.Chen at mediatek.com/

Is doing the same ack/disable.

>
> Does this timer belong to an always-on power domain ?
>

I'm not sure sorry, the datasheet does not seem to say. Maybe mediatek
can answer.


From weifeng.voon at intel.com  Tue Apr  6 02:32:50 2021
From: weifeng.voon at intel.com (Voon Weifeng)
Date: Tue,  6 Apr 2021 09:32:50 +0800
Subject: [PATCH v2 net-next] stmmac: intel: Enable SERDES PHY rx clk for PSE
Message-ID: <20210406013250.17171-1-weifeng.voon@intel.com>

EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
sequence and vice versa.

Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
---
Changes:
 v1 -> v2
 -change subject from "net: intel" to "stmmac: intel"
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 10 ++++++++++
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index add95e20548d..a4fec5fe0779 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -153,6 +153,11 @@ static int intel_serdes_powerup(struct net_device *ndev, void *priv_data)
 		return data;
 	}
 
+	/* PSE only - ungate SGMII PHY Rx Clock */
+	if (intel_priv->is_pse)
+		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
+			       0, SERDES_PHY_RX_CLK);
+
 	return 0;
 }
 
@@ -168,6 +173,11 @@ static void intel_serdes_powerdown(struct net_device *ndev, void *intel_data)
 
 	serdes_phy_addr = intel_priv->mdio_adhoc_addr;
 
+	/* PSE only - gate SGMII PHY Rx Clock */
+	if (intel_priv->is_pse)
+		mdiobus_modify(priv->mii, serdes_phy_addr, SERDES_GCR0,
+			       SERDES_PHY_RX_CLK, 0);
+
 	/*  move power state to P3 */
 	data = mdiobus_read(priv->mii, serdes_phy_addr, SERDES_GCR0);
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
index e723096c0b15..542acb8ce467 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.h
@@ -14,6 +14,7 @@
 
 /* SERDES defines */
 #define SERDES_PLL_CLK		BIT(0)		/* PLL clk valid signal */
+#define SERDES_PHY_RX_CLK	BIT(1)		/* PSE SGMII PHY rx clk */
 #define SERDES_RST		BIT(2)		/* Serdes Reset */
 #define SERDES_PWR_ST_MASK	GENMASK(6, 4)	/* Serdes Power state*/
 #define SERDES_PWR_ST_SHIFT	4
-- 
2.17.1



From aford173 at gmail.com  Tue Apr  6 02:33:42 2021
From: aford173 at gmail.com (Adam Ford)
Date: Mon,  5 Apr 2021 20:33:42 -0500
Subject: [PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus
Message-ID: <20210406013344.124255-1-aford173@gmail.com>

The i.MX8MN has an SPBA bus which covers much of the audio, but
there is a second SPBA bus which covers many of the serial interfaces
like SPI and UARTs currently missing from the device tree. The reference
manual calls the bus handling the audio peripherals SPBA2, and the bus
handling the serial peripherals is called SPBA1.

Rename the existing spba bus to spba2 and add spba1.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 4dac4da38f4c..e961acd237a8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -255,7 +255,7 @@ aips1: bus at 30000000 {
 			#size-cells = <1>;
 			ranges;
 
-			spba: spba-bus at 30000000 {
+			spba2: spba-bus at 30000000 {
 				compatible = "fsl,spba-bus", "simple-bus";
 				#address-cells = <1>;
 				#size-cells = <1>;
@@ -681,80 +681,88 @@ aips3: bus at 30800000 {
 			#size-cells = <1>;
 			ranges;
 
-			ecspi1: spi at 30820000 {
-				compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+			spba1: spba-bus at 30800000 {
+				compatible = "fsl,spba-bus", "simple-bus";
 				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30820000 0x10000>;
-				interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
-					 <&clk IMX8MN_CLK_ECSPI1_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				#size-cells = <1>;
+				reg = <0x30800000 0x100000>;
+				ranges;
 
-			ecspi2: spi at 30830000 {
-				compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30830000 0x10000>;
-				interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
-					 <&clk IMX8MN_CLK_ECSPI2_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				ecspi1: spi at 30820000 {
+					compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30820000 0x10000>;
+					interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_ECSPI1_ROOT>,
+						 <&clk IMX8MN_CLK_ECSPI1_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			ecspi3: spi at 30840000 {
-				compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30840000 0x10000>;
-				interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
-					 <&clk IMX8MN_CLK_ECSPI3_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				ecspi2: spi at 30830000 {
+					compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30830000 0x10000>;
+					interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_ECSPI2_ROOT>,
+						 <&clk IMX8MN_CLK_ECSPI2_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart1: serial at 30860000 {
-				compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
-				reg = <0x30860000 0x10000>;
-				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
-					 <&clk IMX8MN_CLK_UART1_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				ecspi3: spi at 30840000 {
+					compatible = "fsl,imx8mn-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30840000 0x10000>;
+					interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_ECSPI3_ROOT>,
+						 <&clk IMX8MN_CLK_ECSPI3_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart3: serial at 30880000 {
-				compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
-				reg = <0x30880000 0x10000>;
-				interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
-					 <&clk IMX8MN_CLK_UART3_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				uart1: serial at 30860000 {
+					compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+					reg = <0x30860000 0x10000>;
+					interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_UART1_ROOT>,
+						 <&clk IMX8MN_CLK_UART1_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart2: serial at 30890000 {
-				compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
-				reg = <0x30890000 0x10000>;
-				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
-					 <&clk IMX8MN_CLK_UART2_ROOT>;
-				clock-names = "ipg", "per";
-				status = "disabled";
+				uart3: serial at 30880000 {
+					compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+					reg = <0x30880000 0x10000>;
+					interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_UART3_ROOT>,
+						 <&clk IMX8MN_CLK_UART3_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
+
+				uart2: serial at 30890000 {
+					compatible = "fsl,imx8mn-uart", "fsl,imx6q-uart";
+					reg = <0x30890000 0x10000>;
+					interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MN_CLK_UART2_ROOT>,
+						 <&clk IMX8MN_CLK_UART2_ROOT>;
+					clock-names = "ipg", "per";
+					status = "disabled";
+				};
 			};
 
 			crypto: crypto at 30900000 {
-- 
2.25.1



From aford173 at gmail.com  Tue Apr  6 02:33:43 2021
From: aford173 at gmail.com (Adam Ford)
Date: Mon,  5 Apr 2021 20:33:43 -0500
Subject: [PATCH 2/2] arm64: dts: imx8mm: Add spba1 and spba2 buses
In-Reply-To: <20210406013344.124255-1-aford173@gmail.com>
References: <20210406013344.124255-1-aford173@gmail.com>
Message-ID: <20210406013344.124255-2-aford173@gmail.com>

The i.MX8MM reference manual shows there are two spba busses.
SPBA1 handles much of the serial interfaces, and SPBA2 covers much
of the audio.

Add both of them.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index a27e02bee6b4..64aa38fd2b6e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -271,117 +271,125 @@ aips1: bus at 30000000 {
 			#size-cells = <1>;
 			ranges = <0x30000000 0x30000000 0x400000>;
 
-			sai1: sai at 30010000 {
-				#sound-dai-cells = <0>;
-				compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-				reg = <0x30010000 0x10000>;
-				interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_SAI1_IPG>,
-					 <&clk IMX8MM_CLK_SAI1_ROOT>,
-					 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
-				clock-names = "bus", "mclk1", "mclk2", "mclk3";
-				dmas = <&sdma2 0 2 0>, <&sdma2 1 2 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+			spba2: spba-bus at 30000000 {
+				compatible = "fsl,spba-bus", "simple-bus";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x30000000 0x100000>;
+				ranges;
+
+				sai1: sai at 30010000 {
+					#sound-dai-cells = <0>;
+					compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
+					reg = <0x30010000 0x10000>;
+					interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_SAI1_IPG>,
+						 <&clk IMX8MM_CLK_SAI1_ROOT>,
+						 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
+					clock-names = "bus", "mclk1", "mclk2", "mclk3";
+					dmas = <&sdma2 0 2 0>, <&sdma2 1 2 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			sai2: sai at 30020000 {
-				#sound-dai-cells = <0>;
-				compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-				reg = <0x30020000 0x10000>;
-				interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_SAI2_IPG>,
-					<&clk IMX8MM_CLK_SAI2_ROOT>,
-					<&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
-				clock-names = "bus", "mclk1", "mclk2", "mclk3";
-				dmas = <&sdma2 2 2 0>, <&sdma2 3 2 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				sai2: sai at 30020000 {
+					#sound-dai-cells = <0>;
+					compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
+					reg = <0x30020000 0x10000>;
+					interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_SAI2_IPG>,
+						<&clk IMX8MM_CLK_SAI2_ROOT>,
+						<&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
+					clock-names = "bus", "mclk1", "mclk2", "mclk3";
+					dmas = <&sdma2 2 2 0>, <&sdma2 3 2 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			sai3: sai at 30030000 {
-				#sound-dai-cells = <0>;
-				compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-				reg = <0x30030000 0x10000>;
-				interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_SAI3_IPG>,
-					 <&clk IMX8MM_CLK_SAI3_ROOT>,
-					 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
-				clock-names = "bus", "mclk1", "mclk2", "mclk3";
-				dmas = <&sdma2 4 2 0>, <&sdma2 5 2 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				sai3: sai at 30030000 {
+					#sound-dai-cells = <0>;
+					compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
+					reg = <0x30030000 0x10000>;
+					interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_SAI3_IPG>,
+						 <&clk IMX8MM_CLK_SAI3_ROOT>,
+						 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
+					clock-names = "bus", "mclk1", "mclk2", "mclk3";
+					dmas = <&sdma2 4 2 0>, <&sdma2 5 2 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			sai5: sai at 30050000 {
-				#sound-dai-cells = <0>;
-				compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-				reg = <0x30050000 0x10000>;
-				interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_SAI5_IPG>,
-					 <&clk IMX8MM_CLK_SAI5_ROOT>,
-					 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
-				clock-names = "bus", "mclk1", "mclk2", "mclk3";
-				dmas = <&sdma2 8 2 0>, <&sdma2 9 2 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				sai5: sai at 30050000 {
+					#sound-dai-cells = <0>;
+					compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
+					reg = <0x30050000 0x10000>;
+					interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_SAI5_IPG>,
+						 <&clk IMX8MM_CLK_SAI5_ROOT>,
+						 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
+					clock-names = "bus", "mclk1", "mclk2", "mclk3";
+					dmas = <&sdma2 8 2 0>, <&sdma2 9 2 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			sai6: sai at 30060000 {
-				#sound-dai-cells = <0>;
-				compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-				reg = <0x30060000 0x10000>;
-				interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_SAI6_IPG>,
-					 <&clk IMX8MM_CLK_SAI6_ROOT>,
-					 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
-				clock-names = "bus", "mclk1", "mclk2", "mclk3";
-				dmas = <&sdma2 10 2 0>, <&sdma2 11 2 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				sai6: sai at 30060000 {
+					#sound-dai-cells = <0>;
+					compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
+					reg = <0x30060000 0x10000>;
+					interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_SAI6_IPG>,
+						 <&clk IMX8MM_CLK_SAI6_ROOT>,
+						 <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
+					clock-names = "bus", "mclk1", "mclk2", "mclk3";
+					dmas = <&sdma2 10 2 0>, <&sdma2 11 2 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			micfil: audio-controller at 30080000 {
-				compatible = "fsl,imx8mm-micfil";
-				reg = <0x30080000 0x10000>;
-				interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
-					     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
-					     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
-					     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_PDM_IPG>,
-					 <&clk IMX8MM_CLK_PDM_ROOT>,
-					 <&clk IMX8MM_AUDIO_PLL1_OUT>,
-					 <&clk IMX8MM_AUDIO_PLL2_OUT>,
-					 <&clk IMX8MM_CLK_EXT3>;
-				clock-names = "ipg_clk", "ipg_clk_app",
-					      "pll8k", "pll11k", "clkext3";
-				dmas = <&sdma2 24 25 0x80000000>;
-				dma-names = "rx";
-				status = "disabled";
-			};
+				micfil: audio-controller at 30080000 {
+					compatible = "fsl,imx8mm-micfil";
+					reg = <0x30080000 0x10000>;
+					interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+						     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+						     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+						     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_PDM_IPG>,
+						 <&clk IMX8MM_CLK_PDM_ROOT>,
+						 <&clk IMX8MM_AUDIO_PLL1_OUT>,
+						 <&clk IMX8MM_AUDIO_PLL2_OUT>,
+						 <&clk IMX8MM_CLK_EXT3>;
+					clock-names = "ipg_clk", "ipg_clk_app",
+						      "pll8k", "pll11k", "clkext3";
+					dmas = <&sdma2 24 25 0x80000000>;
+					dma-names = "rx";
+					status = "disabled";
+				};
 
-			spdif1: spdif at 30090000 {
-				compatible = "fsl,imx35-spdif";
-				reg = <0x30090000 0x10000>;
-				interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_AUDIO_AHB>, /* core */
-					 <&clk IMX8MM_CLK_24M>, /* rxtx0 */
-					 <&clk IMX8MM_CLK_SPDIF1>, /* rxtx1 */
-					 <&clk IMX8MM_CLK_DUMMY>, /* rxtx2 */
-					 <&clk IMX8MM_CLK_DUMMY>, /* rxtx3 */
-					 <&clk IMX8MM_CLK_DUMMY>, /* rxtx4 */
-					 <&clk IMX8MM_CLK_AUDIO_AHB>, /* rxtx5 */
-					 <&clk IMX8MM_CLK_DUMMY>, /* rxtx6 */
-					 <&clk IMX8MM_CLK_DUMMY>, /* rxtx7 */
-					 <&clk IMX8MM_CLK_DUMMY>; /* spba */
-				clock-names = "core", "rxtx0",
-					      "rxtx1", "rxtx2",
-					      "rxtx3", "rxtx4",
-					      "rxtx5", "rxtx6",
-					      "rxtx7", "spba";
-				dmas = <&sdma2 28 18 0>, <&sdma2 29 18 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
+				spdif1: spdif at 30090000 {
+					compatible = "fsl,imx35-spdif";
+					reg = <0x30090000 0x10000>;
+					interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_AUDIO_AHB>, /* core */
+						 <&clk IMX8MM_CLK_24M>, /* rxtx0 */
+						 <&clk IMX8MM_CLK_SPDIF1>, /* rxtx1 */
+						 <&clk IMX8MM_CLK_DUMMY>, /* rxtx2 */
+						 <&clk IMX8MM_CLK_DUMMY>, /* rxtx3 */
+						 <&clk IMX8MM_CLK_DUMMY>, /* rxtx4 */
+						 <&clk IMX8MM_CLK_AUDIO_AHB>, /* rxtx5 */
+						 <&clk IMX8MM_CLK_DUMMY>, /* rxtx6 */
+						 <&clk IMX8MM_CLK_DUMMY>, /* rxtx7 */
+						 <&clk IMX8MM_CLK_DUMMY>; /* spba */
+					clock-names = "core", "rxtx0",
+						      "rxtx1", "rxtx2",
+						      "rxtx3", "rxtx4",
+						      "rxtx5", "rxtx6",
+						      "rxtx7", "spba";
+					dmas = <&sdma2 28 18 0>, <&sdma2 29 18 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 			};
 
 			gpio1: gpio at 30200000 {
@@ -670,80 +678,88 @@ aips3: bus at 30800000 {
 			ranges = <0x30800000 0x30800000 0x400000>,
 				 <0x8000000 0x8000000 0x10000000>;
 
-			ecspi1: spi at 30820000 {
-				compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
+			spba1: spba-bus at 30800000 {
+				compatible = "fsl,spba-bus", "simple-bus";
 				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30820000 0x10000>;
-				interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_ECSPI1_ROOT>,
-					 <&clk IMX8MM_CLK_ECSPI1_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				#size-cells = <1>;
+				reg = <0x30800000 0x100000>;
+				ranges;
+
+				ecspi1: spi at 30820000 {
+					compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30820000 0x10000>;
+					interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_ECSPI1_ROOT>,
+						 <&clk IMX8MM_CLK_ECSPI1_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 0 7 1>, <&sdma1 1 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			ecspi2: spi at 30830000 {
-				compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30830000 0x10000>;
-				interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_ECSPI2_ROOT>,
-					 <&clk IMX8MM_CLK_ECSPI2_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				ecspi2: spi at 30830000 {
+					compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30830000 0x10000>;
+					interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_ECSPI2_ROOT>,
+						 <&clk IMX8MM_CLK_ECSPI2_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 2 7 1>, <&sdma1 3 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			ecspi3: spi at 30840000 {
-				compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <0x30840000 0x10000>;
-				interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_ECSPI3_ROOT>,
-					 <&clk IMX8MM_CLK_ECSPI3_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				ecspi3: spi at 30840000 {
+					compatible = "fsl,imx8mm-ecspi", "fsl,imx51-ecspi";
+					#address-cells = <1>;
+					#size-cells = <0>;
+					reg = <0x30840000 0x10000>;
+					interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_ECSPI3_ROOT>,
+						 <&clk IMX8MM_CLK_ECSPI3_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 4 7 1>, <&sdma1 5 7 2>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart1: serial at 30860000 {
-				compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
-				reg = <0x30860000 0x10000>;
-				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_UART1_ROOT>,
-					 <&clk IMX8MM_CLK_UART1_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				uart1: serial at 30860000 {
+					compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
+					reg = <0x30860000 0x10000>;
+					interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_UART1_ROOT>,
+						 <&clk IMX8MM_CLK_UART1_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 22 4 0>, <&sdma1 23 4 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart3: serial at 30880000 {
-				compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
-				reg = <0x30880000 0x10000>;
-				interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_UART3_ROOT>,
-					 <&clk IMX8MM_CLK_UART3_ROOT>;
-				clock-names = "ipg", "per";
-				dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
-				dma-names = "rx", "tx";
-				status = "disabled";
-			};
+				uart3: serial at 30880000 {
+					compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
+					reg = <0x30880000 0x10000>;
+					interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_UART3_ROOT>,
+						 <&clk IMX8MM_CLK_UART3_ROOT>;
+					clock-names = "ipg", "per";
+					dmas = <&sdma1 26 4 0>, <&sdma1 27 4 0>;
+					dma-names = "rx", "tx";
+					status = "disabled";
+				};
 
-			uart2: serial at 30890000 {
-				compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
-				reg = <0x30890000 0x10000>;
-				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
-				clocks = <&clk IMX8MM_CLK_UART2_ROOT>,
-					 <&clk IMX8MM_CLK_UART2_ROOT>;
-				clock-names = "ipg", "per";
-				status = "disabled";
+				uart2: serial at 30890000 {
+					compatible = "fsl,imx8mm-uart", "fsl,imx6q-uart";
+					reg = <0x30890000 0x10000>;
+					interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clk IMX8MM_CLK_UART2_ROOT>,
+						 <&clk IMX8MM_CLK_UART2_ROOT>;
+					clock-names = "ipg", "per";
+					status = "disabled";
+				};
 			};
 
 			crypto: crypto at 30900000 {
-- 
2.25.1



From baolu.lu at linux.intel.com  Tue Apr  6 02:48:39 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Tue, 6 Apr 2021 09:48:39 +0800
Subject: [RFC PATCH v3 02/12] iommu: Add an unmap_pages() op for IOMMU
 drivers
In-Reply-To: <20210405191112.28192-3-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-3-isaacm@codeaurora.org>
Message-ID: <bf29730d-ddbc-3898-621d-a6211ad2a709@linux.intel.com>

On 4/6/21 3:11 AM, Isaac J. Manjarres wrote:
> Add a callback for IOMMU drivers to provide a path for the
> IOMMU framework to call into an IOMMU driver, which can call
> into the io-pgtable code, to unmap a virtually contiguous
> range of pages of the same size.
> 
> For IOMMU drivers that do not specify an unmap_pages() callback,
> the existing logic of unmapping memory one page block at a time
> will be used.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> Signed-off-by: Will Deacon <will at kernel.org>
> ---
>   include/linux/iommu.h | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 5e7fe519430a..9cf81242581a 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -193,6 +193,7 @@ struct iommu_iotlb_gather {
>    * @detach_dev: detach device from an iommu domain
>    * @map: map a physically contiguous memory region to an iommu domain
>    * @unmap: unmap a physically contiguous memory region from an iommu domain
> + * @unmap_pages: unmap a number of pages of the same size from an iommu domain
>    * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
>    * @iotlb_sync_map: Sync mappings created recently using @map to the hardware
>    * @iotlb_sync: Flush all queued ranges from the hardware TLBs and empty flush
> @@ -245,6 +246,9 @@ struct iommu_ops {
>   		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
>   	size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
>   		     size_t size, struct iommu_iotlb_gather *iotlb_gather);
> +	size_t (*unmap_pages)(struct iommu_domain *domain, unsigned long iova,
> +			      size_t pgsize, size_t pgcount,
> +			      struct iommu_iotlb_gather *iotlb_gather);
>   	void (*flush_iotlb_all)(struct iommu_domain *domain);
>   	void (*iotlb_sync_map)(struct iommu_domain *domain, unsigned long iova,
>   			       size_t size);
> 

This looks good to me.

Acked-by: Lu Baolu <baolu.lu at linux.intel.com>

Best regards,
baolu


From baolu.lu at linux.intel.com  Tue Apr  6 02:49:21 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Tue, 6 Apr 2021 09:49:21 +0800
Subject: [RFC PATCH v3 04/12] iommu: Add a map_pages() op for IOMMU drivers
In-Reply-To: <20210405191112.28192-5-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-5-isaacm@codeaurora.org>
Message-ID: <f62db5e6-1e2b-8ee0-3198-59fdeb16ee4d@linux.intel.com>

On 4/6/21 3:11 AM, Isaac J. Manjarres wrote:
> Add a callback for IOMMU drivers to provide a path for the
> IOMMU framework to call into an IOMMU driver, which can
> call into the io-pgtable code, to map a physically contiguous
> rnage of pages of the same size.
> 
> For IOMMU drivers that do not specify a map_pages() callback,
> the existing logic of mapping memory one page block at a time
> will be used.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>   include/linux/iommu.h | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 9cf81242581a..528d6a58479e 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -192,6 +192,8 @@ struct iommu_iotlb_gather {
>    * @attach_dev: attach device to an iommu domain
>    * @detach_dev: detach device from an iommu domain
>    * @map: map a physically contiguous memory region to an iommu domain
> + * @map_pages: map a physically contiguous set of pages of the same size to
> + *             an iommu domain.
>    * @unmap: unmap a physically contiguous memory region from an iommu domain
>    * @unmap_pages: unmap a number of pages of the same size from an iommu domain
>    * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
> @@ -244,6 +246,9 @@ struct iommu_ops {
>   	void (*detach_dev)(struct iommu_domain *domain, struct device *dev);
>   	int (*map)(struct iommu_domain *domain, unsigned long iova,
>   		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
> +	int (*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);
>   	size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
>   		     size_t size, struct iommu_iotlb_gather *iotlb_gather);
>   	size_t (*unmap_pages)(struct iommu_domain *domain, unsigned long iova,
> 

This looks good to me.

Acked-by: Lu Baolu <baolu.lu at linux.intel.com>

Best regards,
baolu


From chunfeng.yun at mediatek.com  Tue Apr  6 03:18:12 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Tue, 6 Apr 2021 10:18:12 +0800
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <YGq2YfURFApdJLxb@kroah.com>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03> <YGq2YfURFApdJLxb@kroah.com>
Message-ID: <1617675492.22435.4.camel@mhfsdcap03>

On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> > 
> > I'll test it , thanks
> 
> Did you test this series and find any problems?  If not, I'll go queue
> these up...
Yes, found an issue on the start-split transaction, but not found the
root cause yet :(

> 
> thanks,
> 
> greg k-h


From linqiheng at huawei.com  Tue Apr  6 04:04:33 2021
From: linqiheng at huawei.com (Qiheng Lin)
Date: Tue, 6 Apr 2021 11:04:33 +0800
Subject: [PATCH net-next] net: ethernet: mtk_eth_soc: remove unneeded semicolon
Message-ID: <20210406030433.6540-1-linqiheng@huawei.com>

Eliminate the following coccicheck warning:
 drivers/net/ethernet/mediatek/mtk_ppe.c:270:2-3: Unneeded semicolon

Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
---
 drivers/net/ethernet/mediatek/mtk_ppe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index a1a9959a2461..71e1ccea6e72 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -267,7 +267,7 @@ int mtk_foe_entry_set_ipv6_tuple(struct mtk_foe_entry *entry,
 	default:
 		WARN_ON_ONCE(1);
 		return -EINVAL;
-	};
+	}
 
 	for (i = 0; i < 4; i++)
 		src[i] = be32_to_cpu(src_addr[i]);
-- 
2.31.1



From linqiheng at huawei.com  Tue Apr  6 04:20:51 2021
From: linqiheng at huawei.com (Qiheng Lin)
Date: Tue, 6 Apr 2021 11:20:51 +0800
Subject: [PATCH net-next] mt76: mt7921: remove unneeded semicolon
Message-ID: <20210406032051.7750-1-linqiheng@huawei.com>

Eliminate the following coccicheck warning:
 drivers/net/wireless/mediatek/mt76/mt7921/mac.c:1402:2-3: Unneeded semicolon

Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
---
 drivers/net/wireless/mediatek/mt76/mt7921/mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
index 3f9097481a5e..e56cde3a19ec 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mac.c
@@ -1399,7 +1399,7 @@ void mt7921_mac_work(struct work_struct *work)
 	if (++phy->sta_work_count == 10) {
 		phy->sta_work_count = 0;
 		mt7921_mac_sta_stats_work(phy);
-	};
+	}
 
 	mt7921_mutex_release(phy->dev);
 
-- 
2.31.1



From chuanjia.liu at mediatek.com  Tue Apr  6 04:44:06 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 6 Apr 2021 11:44:06 +0800
Subject: [PATCH v9 0/4] PCI: mediatek: Spilt PCIe node to comply with hardware
 design 
Message-ID: <20210406034410.24381-1-chuanjia.liu@mediatek.com>

There are two independent PCIe controllers in MT2712 and MT7622 platform. Each of them should contain an independent MSI domain.

In old dts architecture, MSI domain will be inherited from the root bridge, and all of the devices will share the same MSI domain.
Hence that, the PCIe devices will not work properly if the irq number which required is more than 32.

Split the PCIe node for MT2712 and MT7622 platform to comply with the hardware design and fix MSI issue.

change note:
  v9:fix kernel-ci bot warning. In the scene of using new dts format,
     when mtk_pcie_parse_port fails, of_node_put don't need to be called.
  v8:remove slot node and fix yaml warning.
  v7:dt-bindings file was modified as suggested by Rob, other file no
     change.
  v6:Fix yaml error. make sure driver compatible with old and 
     new DTS format.
  v5:rebase for 5.9-rc1, no code change. 
  v4:change commit message due to bayes statistical bogofilter
     considers this series patch SPAM.
  v3:rebase for 5.8-rc1. Only collect ack of Ryder, No code change.
  v2:change the allocation of MT2712 PCIe MMIO space due to the
     allocation size is not right in v1.

Chuanjia Liu (4):
 dt-bindings: PCI: mediatek: Update the Device tree bindings
 PCI: mediatek: Add new method to get shared pcie-cfg base address and
	parse node
 arm64: dts: mediatek: Split PCIe node for MT2712 and MT7622
 ARM: dts: mediatek: Update MT7629 PCIe node for new format

 .../bindings/pci/mediatek-pcie-cfg.yaml       |  39 ++++
 .../devicetree/bindings/pci/mediatek-pcie.txt | 201 ++++++++++--------
 arch/arm/boot/dts/mt7629-rfb.dts              |   3 +-
 arch/arm/boot/dts/mt7629.dtsi                 |  45 ++--
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi     |  97 +++++----
 .../dts/mediatek/mt7622-bananapi-bpi-r64.dts  |  16 +-
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts  |   6 +-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi      | 112 +++++-----
 drivers/pci/controller/pcie-mediatek.c        |  52 +++--
 9 files changed, 326 insertions(+), 245 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml

--
2.18.0


From chuanjia.liu at mediatek.com  Tue Apr  6 04:44:09 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 6 Apr 2021 11:44:09 +0800
Subject: [PATCH v9 3/4] arm64: dts: mediatek: Split PCIe node for MT2712 and
 MT7622
In-Reply-To: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
References: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
Message-ID: <20210406034410.24381-4-chuanjia.liu@mediatek.com>

There are two independent PCIe controllers in MT2712 and MT7622
platform. Each of them should contain an independent MSI domain.

In old dts architecture, MSI domain will be inherited from the root
bridge, and all of the devices will share the same MSI domain.
Hence that, the PCIe devices will not work properly if the irq number
which required is more than 32.

Split the PCIe node for MT2712 and MT7622 platform to comply with
the hardware design and fix MSI issue.

Signed-off-by: Chuanjia Liu <chuanjia.liu at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>

---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi     |  97 +++++++--------
 .../dts/mediatek/mt7622-bananapi-bpi-r64.dts  |  16 ++-
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts  |   6 +-
 arch/arm64/boot/dts/mediatek/mt7622.dtsi      | 112 ++++++++++--------
 4 files changed, 118 insertions(+), 113 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index db17d0a4ed57..0e20e13b0942 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -915,64 +915,67 @@
 		};
 	};
 
-	pcie: pcie at 11700000 {
+	pcie1: pcie at 112ff000 {
 		compatible = "mediatek,mt2712-pcie";
 		device_type = "pci";
-		reg = <0 0x11700000 0 0x1000>,
-		      <0 0x112ff000 0 0x1000>;
-		reg-names = "port0", "port1";
+		reg = <0 0x112ff000 0 0x1000>;
+		reg-names = "port1";
+		linux,pci-domain = <1>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-		interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
-			 <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
-			 <&pericfg CLK_PERI_PCIE0>,
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "pcie_irq";
+		clocks = <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
 			 <&pericfg CLK_PERI_PCIE1>;
-		clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
-		phys = <&u3port0 PHY_TYPE_PCIE>, <&u3port1 PHY_TYPE_PCIE>;
-		phy-names = "pcie-phy0", "pcie-phy1";
+		clock-names = "sys_ck1", "ahb_ck1";
+		phys = <&u3port1 PHY_TYPE_PCIE>;
+		phy-names = "pcie-phy1";
 		bus-range = <0x00 0xff>;
-		ranges = <0x82000000 0 0x20000000  0x0 0x20000000  0 0x10000000>;
+		ranges = <0x82000000 0 0x11400000  0x0 0x11400000  0 0x300000>;
+		status = "disabled";
 
-		pcie0: pcie at 0,0 {
-			device_type = "pci";
-			status = "disabled";
-			reg = <0x0000 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+				<0 0 0 2 &pcie_intc1 1>,
+				<0 0 0 3 &pcie_intc1 2>,
+				<0 0 0 4 &pcie_intc1 3>;
+		pcie_intc1: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc0 0>,
-					<0 0 0 2 &pcie_intc0 1>,
-					<0 0 0 3 &pcie_intc0 2>,
-					<0 0 0 4 &pcie_intc0 3>;
-			pcie_intc0: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
+	};
 
-		pcie1: pcie at 1,0 {
-			device_type = "pci";
-			status = "disabled";
-			reg = <0x0800 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+	pcie0: pcie at 11700000 {
+		compatible = "mediatek,mt2712-pcie";
+		device_type = "pci";
+		reg = <0 0x11700000 0 0x1000>;
+		reg-names = "port0";
+		linux,pci-domain = <0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "pcie_irq";
+		clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
+			 <&pericfg CLK_PERI_PCIE0>;
+		clock-names = "sys_ck0", "ahb_ck0";
+		phys = <&u3port0 PHY_TYPE_PCIE>;
+		phy-names = "pcie-phy0";
+		bus-range = <0x00 0xff>;
+		ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
+		status = "disabled";
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+				<0 0 0 2 &pcie_intc0 1>,
+				<0 0 0 3 &pcie_intc0 2>,
+				<0 0 0 4 &pcie_intc0 3>;
+		pcie_intc0: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc1 0>,
-					<0 0 0 2 &pcie_intc1 1>,
-					<0 0 0 3 &pcie_intc1 2>,
-					<0 0 0 4 &pcie_intc1 3>;
-			pcie_intc1: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
 	};
 
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
index 2f77dc40b9b8..2b9bf8dd14ec 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -257,18 +257,16 @@
 	};
 };
 
-&pcie {
+&pcie0 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pcie0_pins>, <&pcie1_pins>;
+	pinctrl-0 = <&pcie0_pins>;
 	status = "okay";
+};
 
-	pcie at 0,0 {
-		status = "okay";
-	};
-
-	pcie at 1,0 {
-		status = "okay";
-	};
+&pcie1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie1_pins>;
+	status = "okay";
 };
 
 &pio {
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index 08ad0ffb24df..182eba502522 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -234,14 +234,10 @@
 	};
 };
 
-&pcie {
+&pcie0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie0_pins>;
 	status = "okay";
-
-	pcie at 0,0 {
-		status = "okay";
-	};
 };
 
 &pio {
diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 7c6d871538a6..df83d531a0f4 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -781,75 +781,83 @@
 		#reset-cells = <1>;
 	};
 
-	pcie: pcie at 1a140000 {
+	pciecfg: pciecfg at 1a140000 {
+		compatible = "mediatek,generic-pciecfg", "syscon";
+		reg = <0 0x1a140000 0 0x1000>;
+	};
+
+	pcie0: pcie at 1a143000 {
 		compatible = "mediatek,mt7622-pcie";
 		device_type = "pci";
-		reg = <0 0x1a140000 0 0x1000>,
-		      <0 0x1a143000 0 0x1000>,
-		      <0 0x1a145000 0 0x1000>;
-		reg-names = "subsys", "port0", "port1";
+		reg = <0 0x1a143000 0 0x1000>;
+		reg-names = "port0";
+		linux,pci-domain = <0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-names = "pcie_irq";
 		clocks = <&pciesys CLK_PCIE_P0_MAC_EN>,
-			 <&pciesys CLK_PCIE_P1_MAC_EN>,
-			 <&pciesys CLK_PCIE_P0_AHB_EN>,
 			 <&pciesys CLK_PCIE_P0_AHB_EN>,
 			 <&pciesys CLK_PCIE_P0_AUX_EN>,
-			 <&pciesys CLK_PCIE_P1_AUX_EN>,
 			 <&pciesys CLK_PCIE_P0_AXI_EN>,
-			 <&pciesys CLK_PCIE_P1_AXI_EN>,
 			 <&pciesys CLK_PCIE_P0_OBFF_EN>,
-			 <&pciesys CLK_PCIE_P1_OBFF_EN>,
-			 <&pciesys CLK_PCIE_P0_PIPE_EN>,
-			 <&pciesys CLK_PCIE_P1_PIPE_EN>;
-		clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1",
-			      "aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1",
-			      "obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1";
+			 <&pciesys CLK_PCIE_P0_PIPE_EN>;
+		clock-names = "sys_ck0", "ahb_ck0", "aux_ck0",
+			      "axi_ck0", "obff_ck0", "pipe_ck0";
+
 		power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
 		bus-range = <0x00 0xff>;
-		ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
+		ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x8000000>;
 		status = "disabled";
 
-		pcie0: pcie at 0,0 {
-			reg = <0x0000 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+				<0 0 0 2 &pcie_intc0 1>,
+				<0 0 0 3 &pcie_intc0 2>,
+				<0 0 0 4 &pcie_intc0 3>;
+		pcie_intc0: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			status = "disabled";
-
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc0 0>,
-					<0 0 0 2 &pcie_intc0 1>,
-					<0 0 0 3 &pcie_intc0 2>,
-					<0 0 0 4 &pcie_intc0 3>;
-			pcie_intc0: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
+	};
 
-		pcie1: pcie at 1,0 {
-			reg = <0x0800 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+	pcie1: pcie at 1a145000 {
+		compatible = "mediatek,mt7622-pcie";
+		device_type = "pci";
+		reg = <0 0x1a145000 0 0x1000>;
+		reg-names = "port1";
+		linux,pci-domain = <1>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-names = "pcie_irq";
+		clocks = <&pciesys CLK_PCIE_P1_MAC_EN>,
+			 /* designer has connect RC1 with p0_ahb clock */
+			 <&pciesys CLK_PCIE_P0_AHB_EN>,
+			 <&pciesys CLK_PCIE_P1_AUX_EN>,
+			 <&pciesys CLK_PCIE_P1_AXI_EN>,
+			 <&pciesys CLK_PCIE_P1_OBFF_EN>,
+			 <&pciesys CLK_PCIE_P1_PIPE_EN>;
+		clock-names = "sys_ck1", "ahb_ck1", "aux_ck1",
+			      "axi_ck1", "obff_ck1", "pipe_ck1";
+
+		power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+		bus-range = <0x00 0xff>;
+		ranges = <0x82000000 0 0x28000000 0x0 0x28000000 0 0x8000000>;
+		status = "disabled";
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+				<0 0 0 2 &pcie_intc1 1>,
+				<0 0 0 3 &pcie_intc1 2>,
+				<0 0 0 4 &pcie_intc1 3>;
+		pcie_intc1: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			status = "disabled";
-
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc1 0>,
-					<0 0 0 2 &pcie_intc1 1>,
-					<0 0 0 3 &pcie_intc1 2>,
-					<0 0 0 4 &pcie_intc1 3>;
-			pcie_intc1: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
 	};
 
-- 
2.18.0

From chuanjia.liu at mediatek.com  Tue Apr  6 04:44:10 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 6 Apr 2021 11:44:10 +0800
Subject: [PATCH v9 4/4] ARM: dts: mediatek: Update MT7629 PCIe node for new
 format
In-Reply-To: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
References: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
Message-ID: <20210406034410.24381-5-chuanjia.liu@mediatek.com>

To match the new dts binding. Remove "subsys",unused
interrupt and slot node.Add "interrupt-names",
"linux,pci-domain" and pciecfg node.

Signed-off-by: Chuanjia Liu <chuanjia.liu at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>

---
 arch/arm/boot/dts/mt7629-rfb.dts |  3 ++-
 arch/arm/boot/dts/mt7629.dtsi    | 45 +++++++++++++++-----------------
 2 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/mt7629-rfb.dts b/arch/arm/boot/dts/mt7629-rfb.dts
index 9980c10c6e29..eb536cbebd9b 100644
--- a/arch/arm/boot/dts/mt7629-rfb.dts
+++ b/arch/arm/boot/dts/mt7629-rfb.dts
@@ -140,9 +140,10 @@
 	};
 };
 
-&pcie {
+&pcie1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pcie_pins>;
+	status = "okay";
 };
 
 &pciephy1 {
diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 5cbb3d244c75..ca6789acf057 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -360,16 +360,21 @@
 			#reset-cells = <1>;
 		};
 
-		pcie: pcie at 1a140000 {
+		pciecfg: pciecfg at 1a140000 {
+			compatible = "mediatek,generic-pciecfg", "syscon";
+			reg = <0x1a140000 0x1000>;
+		};
+
+		pcie1: pcie at 1a145000 {
 			compatible = "mediatek,mt7629-pcie";
 			device_type = "pci";
-			reg = <0x1a140000 0x1000>,
-			      <0x1a145000 0x1000>;
-			reg-names = "subsys","port1";
+			reg = <0x1a145000 0x1000>;
+			reg-names = "port1";
+			linux,pci-domain = <1>;
 			#address-cells = <3>;
 			#size-cells = <2>;
-			interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_LOW>,
-				     <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+			interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-names = "pcie_irq";
 			clocks = <&pciesys CLK_PCIE_P1_MAC_EN>,
 				 <&pciesys CLK_PCIE_P0_AHB_EN>,
 				 <&pciesys CLK_PCIE_P1_AUX_EN>,
@@ -390,26 +395,18 @@
 			power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
 			bus-range = <0x00 0xff>;
 			ranges = <0x82000000 0 0x20000000 0x20000000 0 0x10000000>;
+			status = "disabled";
 
-			pcie1: pcie at 1,0 {
-				device_type = "pci";
-				reg = <0x0800 0 0 0 0>;
-				#address-cells = <3>;
-				#size-cells = <2>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+					<0 0 0 2 &pcie_intc1 1>,
+					<0 0 0 3 &pcie_intc1 2>,
+					<0 0 0 4 &pcie_intc1 3>;
+			pcie_intc1: interrupt-controller {
+				interrupt-controller;
+				#address-cells = <0>;
 				#interrupt-cells = <1>;
-				ranges;
-				num-lanes = <1>;
-				interrupt-map-mask = <0 0 0 7>;
-				interrupt-map = <0 0 0 1 &pcie_intc1 0>,
-						<0 0 0 2 &pcie_intc1 1>,
-						<0 0 0 3 &pcie_intc1 2>,
-						<0 0 0 4 &pcie_intc1 3>;
-
-				pcie_intc1: interrupt-controller {
-					interrupt-controller;
-					#address-cells = <0>;
-					#interrupt-cells = <1>;
-				};
 			};
 		};
 
-- 
2.18.0

From chuanjia.liu at mediatek.com  Tue Apr  6 04:44:08 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 6 Apr 2021 11:44:08 +0800
Subject: [PATCH v9 2/4] PCI: mediatek: Add new method to get shared pcie-cfg
 base address and parse node
In-Reply-To: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
References: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
Message-ID: <20210406034410.24381-3-chuanjia.liu@mediatek.com>

For the new dts format, add a new method to get
shared pcie-cfg base address and parse node.

Signed-off-by: Chuanjia Liu <chuanjia.liu at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek.c | 52 +++++++++++++++++++-------
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 23548b517e4b..65ebcdb8ab57 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -14,6 +14,7 @@
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqdomain.h>
 #include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
 #include <linux/msi.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
@@ -23,6 +24,7 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
+#include <linux/regmap.h>
 #include <linux/reset.h>
 
 #include "../pci.h"
@@ -205,6 +207,7 @@ struct mtk_pcie_port {
  * struct mtk_pcie - PCIe host information
  * @dev: pointer to PCIe device
  * @base: IO mapped register base
+ * @cfg: IO mapped register map for PCIe config
  * @free_ck: free-run reference clock
  * @mem: non-prefetchable memory resource
  * @ports: pointer to PCIe port information
@@ -213,6 +216,7 @@ struct mtk_pcie_port {
 struct mtk_pcie {
 	struct device *dev;
 	void __iomem *base;
+	struct regmap *cfg;
 	struct clk *free_ck;
 
 	struct list_head ports;
@@ -648,7 +652,11 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
 		return err;
 	}
 
-	port->irq = platform_get_irq(pdev, port->slot);
+	if (of_find_property(dev->of_node, "interrupt-names", NULL))
+		port->irq = platform_get_irq_byname(pdev, "pcie_irq");
+	else
+		port->irq = platform_get_irq(pdev, port->slot);
+
 	if (port->irq < 0)
 		return port->irq;
 
@@ -680,6 +688,10 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
 		val |= PCIE_CSR_LTSSM_EN(port->slot) |
 		       PCIE_CSR_ASPM_L1_EN(port->slot);
 		writel(val, pcie->base + PCIE_SYS_CFG_V2);
+	} else if (pcie->cfg) {
+		val = PCIE_CSR_LTSSM_EN(port->slot) |
+		      PCIE_CSR_ASPM_L1_EN(port->slot);
+		regmap_update_bits(pcie->cfg, PCIE_SYS_CFG_V2, val, val);
 	}
 
 	/* Assert all reset signals */
@@ -983,6 +995,7 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
 	struct device *dev = pcie->dev;
 	struct platform_device *pdev = to_platform_device(dev);
 	struct resource *regs;
+	struct device_node *cfg_node;
 	int err;
 
 	/* get shared registers, which are optional */
@@ -995,6 +1008,14 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
 		}
 	}
 
+	cfg_node = of_find_compatible_node(NULL, NULL,
+					   "mediatek,generic-pciecfg");
+	if (cfg_node) {
+		pcie->cfg = syscon_node_to_regmap(cfg_node);
+		if (IS_ERR(pcie->cfg))
+			return PTR_ERR(pcie->cfg);
+	}
+
 	pcie->free_ck = devm_clk_get(dev, "free_ck");
 	if (IS_ERR(pcie->free_ck)) {
 		if (PTR_ERR(pcie->free_ck) == -EPROBE_DEFER)
@@ -1027,22 +1048,27 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
 	struct device *dev = pcie->dev;
 	struct device_node *node = dev->of_node, *child;
 	struct mtk_pcie_port *port, *tmp;
-	int err;
+	int err, slot;
+
+	slot = of_get_pci_domain_nr(dev->of_node);
+	if (slot < 0) {
+		for_each_available_child_of_node(node, child) {
+			err = of_pci_get_devfn(child);
+			if (err < 0) {
+				dev_err(dev, "failed to get devfn: %d\n", err);
+				goto error_put_node;
+			}
 
-	for_each_available_child_of_node(node, child) {
-		int slot;
+			slot = PCI_SLOT(err);
 
-		err = of_pci_get_devfn(child);
-		if (err < 0) {
-			dev_err(dev, "failed to parse devfn: %d\n", err);
-			goto error_put_node;
+			err = mtk_pcie_parse_port(pcie, child, slot);
+			if (err)
+				goto error_put_node;
 		}
-
-		slot = PCI_SLOT(err);
-
-		err = mtk_pcie_parse_port(pcie, child, slot);
+	} else {
+		err = mtk_pcie_parse_port(pcie, node, slot);
 		if (err)
-			goto error_put_node;
+			return err;
 	}
 
 	err = mtk_pcie_subsys_powerup(pcie);
-- 
2.18.0

From chuanjia.liu at mediatek.com  Tue Apr  6 04:44:07 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 6 Apr 2021 11:44:07 +0800
Subject: [PATCH v9 1/4] dt-bindings: PCI: mediatek: Update the Device tree
 bindings
In-Reply-To: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
References: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
Message-ID: <20210406034410.24381-2-chuanjia.liu@mediatek.com>

There are two independent PCIe controllers in MT2712 and MT7622
platform. Each of them should contain an independent MSI domain.

In old dts architecture, MSI domain will be inherited from the root
bridge, and all of the devices will share the same MSI domain.
Hence that, the PCIe devices will not work properly if the irq number
which required is more than 32.

Split the PCIe node for MT2712 and MT7622 platform to comply with
the hardware design and fix MSI issue.

Signed-off-by: Chuanjia Liu <chuanjia.liu at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>

---
 .../bindings/pci/mediatek-pcie-cfg.yaml       |  39 ++++
 .../devicetree/bindings/pci/mediatek-pcie.txt | 201 ++++++++++--------
 2 files changed, 146 insertions(+), 94 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml
new file mode 100644
index 000000000000..841a3d284bbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-cfg.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mediatek-pcie-cfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek PCIECFG controller
+
+maintainers:
+  - Chuanjia Liu <chuanjia.liu at mediatek.com>
+  - Jianjun Wang <jianjun.wang at mediatek.com>
+
+description: |
+  The MediaTek PCIECFG controller controls some feature about
+  LTSSM, ASPM and so on.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,generic-pciecfg
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    pciecfg: pciecfg at 1a140000 {
+        compatible = "mediatek,generic-pciecfg", "syscon";
+        reg = <0x1a140000 0x1000>;
+    };
+...
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index 7468d666763a..604792c9b1dc 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -8,7 +8,7 @@ Required properties:
 	"mediatek,mt7623-pcie"
 	"mediatek,mt7629-pcie"
 - device_type: Must be "pci"
-- reg: Base addresses and lengths of the PCIe subsys and root ports.
+- reg: Base addresses and lengths of the root ports.
 - reg-names: Names of the above areas to use during resource lookup.
 - #address-cells: Address representation for root ports (must be 3)
 - #size-cells: Size representation for root ports (must be 2)
@@ -143,130 +143,143 @@ Examples for MT7623:
 
 Examples for MT2712:
 
-	pcie: pcie at 11700000 {
+	pcie1: pcie at 112ff000 {
 		compatible = "mediatek,mt2712-pcie";
 		device_type = "pci";
-		reg = <0 0x11700000 0 0x1000>,
-		      <0 0x112ff000 0 0x1000>;
-		reg-names = "port0", "port1";
+		reg = <0 0x112ff000 0 0x1000>;
+		reg-names = "port1";
+		linux,pci-domain = <1>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-		interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
-			 <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
-			 <&pericfg CLK_PERI_PCIE0>,
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "pcie_irq";
+		clocks = <&topckgen CLK_TOP_PE2_MAC_P1_SEL>,
 			 <&pericfg CLK_PERI_PCIE1>;
-		clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
-		phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
-		phy-names = "pcie-phy0", "pcie-phy1";
+		clock-names = "sys_ck1", "ahb_ck1";
+		phys = <&u3port1 PHY_TYPE_PCIE>;
+		phy-names = "pcie-phy1";
 		bus-range = <0x00 0xff>;
-		ranges = <0x82000000 0 0x20000000  0x0 0x20000000  0 0x10000000>;
+		ranges = <0x82000000 0 0x11400000  0x0 0x11400000  0 0x300000>;
+		status = "disabled";
 
-		pcie0: pcie at 0,0 {
-			reg = <0x0000 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+				<0 0 0 2 &pcie_intc1 1>,
+				<0 0 0 3 &pcie_intc1 2>,
+				<0 0 0 4 &pcie_intc1 3>;
+		pcie_intc1: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc0 0>,
-					<0 0 0 2 &pcie_intc0 1>,
-					<0 0 0 3 &pcie_intc0 2>,
-					<0 0 0 4 &pcie_intc0 3>;
-			pcie_intc0: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
+	};
 
-		pcie1: pcie at 1,0 {
-			reg = <0x0800 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+	pcie0: pcie at 11700000 {
+		compatible = "mediatek,mt2712-pcie";
+		device_type = "pci";
+		reg = <0 0x11700000 0 0x1000>;
+		reg-names = "port0";
+		linux,pci-domain = <0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "pcie_irq";
+		clocks = <&topckgen CLK_TOP_PE2_MAC_P0_SEL>,
+			 <&pericfg CLK_PERI_PCIE0>;
+		clock-names = "sys_ck0", "ahb_ck0";
+		phys = <&u3port0 PHY_TYPE_PCIE>;
+		phy-names = "pcie-phy0";
+		bus-range = <0x00 0xff>;
+		ranges = <0x82000000 0 0x20000000 0x0 0x20000000 0 0x10000000>;
+		status = "disabled";
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+				<0 0 0 2 &pcie_intc0 1>,
+				<0 0 0 3 &pcie_intc0 2>,
+				<0 0 0 4 &pcie_intc0 3>;
+		pcie_intc0: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc1 0>,
-					<0 0 0 2 &pcie_intc1 1>,
-					<0 0 0 3 &pcie_intc1 2>,
-					<0 0 0 4 &pcie_intc1 3>;
-			pcie_intc1: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
 	};
 
 Examples for MT7622:
 
-	pcie: pcie at 1a140000 {
+	pcie0: pcie at 1a143000 {
 		compatible = "mediatek,mt7622-pcie";
 		device_type = "pci";
-		reg = <0 0x1a140000 0 0x1000>,
-		      <0 0x1a143000 0 0x1000>,
-		      <0 0x1a145000 0 0x1000>;
-		reg-names = "subsys", "port0", "port1";
+		reg = <0 0x1a143000 0 0x1000>;
+		reg-names = "port0";
+		linux,pci-domain = <0>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-names = "pcie_irq";
 		clocks = <&pciesys CLK_PCIE_P0_MAC_EN>,
-			 <&pciesys CLK_PCIE_P1_MAC_EN>,
 			 <&pciesys CLK_PCIE_P0_AHB_EN>,
-			 <&pciesys CLK_PCIE_P1_AHB_EN>,
 			 <&pciesys CLK_PCIE_P0_AUX_EN>,
-			 <&pciesys CLK_PCIE_P1_AUX_EN>,
 			 <&pciesys CLK_PCIE_P0_AXI_EN>,
-			 <&pciesys CLK_PCIE_P1_AXI_EN>,
 			 <&pciesys CLK_PCIE_P0_OBFF_EN>,
-			 <&pciesys CLK_PCIE_P1_OBFF_EN>,
-			 <&pciesys CLK_PCIE_P0_PIPE_EN>,
-			 <&pciesys CLK_PCIE_P1_PIPE_EN>;
-		clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1",
-			      "aux_ck0", "aux_ck1", "axi_ck0", "axi_ck1",
-			      "obff_ck0", "obff_ck1", "pipe_ck0", "pipe_ck1";
-		phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>;
-		phy-names = "pcie-phy0", "pcie-phy1";
+			 <&pciesys CLK_PCIE_P0_PIPE_EN>;
+		clock-names = "sys_ck0", "ahb_ck0", "aux_ck0",
+			      "axi_ck0", "obff_ck0", "pipe_ck0";
+
 		power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
 		bus-range = <0x00 0xff>;
-		ranges = <0x82000000 0 0x20000000  0x0 0x20000000  0 0x10000000>;
+		ranges = <0x82000000 0 0x20000000  0x0 0x20000000  0 0x8000000>;
+		status = "disabled";
 
-		pcie0: pcie at 0,0 {
-			reg = <0x0000 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc0 0>,
+				<0 0 0 2 &pcie_intc0 1>,
+				<0 0 0 3 &pcie_intc0 2>,
+				<0 0 0 4 &pcie_intc0 3>;
+		pcie_intc0: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc0 0>,
-					<0 0 0 2 &pcie_intc0 1>,
-					<0 0 0 3 &pcie_intc0 2>,
-					<0 0 0 4 &pcie_intc0 3>;
-			pcie_intc0: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
+	};
 
-		pcie1: pcie at 1,0 {
-			reg = <0x0800 0 0 0 0>;
-			#address-cells = <3>;
-			#size-cells = <2>;
+	pcie1: pcie at 1a145000 {
+		compatible = "mediatek,mt7622-pcie";
+		device_type = "pci";
+		reg = <0 0x1a145000 0 0x1000>;
+		reg-names = "port1";
+		linux,pci-domain = <1>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-names = "pcie_irq";
+		clocks = <&pciesys CLK_PCIE_P1_MAC_EN>,
+			 /* designer has connect RC1 with p0_ahb clock */
+			 <&pciesys CLK_PCIE_P0_AHB_EN>,
+			 <&pciesys CLK_PCIE_P1_AUX_EN>,
+			 <&pciesys CLK_PCIE_P1_AXI_EN>,
+			 <&pciesys CLK_PCIE_P1_OBFF_EN>,
+			 <&pciesys CLK_PCIE_P1_PIPE_EN>;
+		clock-names = "sys_ck1", "ahb_ck1", "aux_ck1",
+			      "axi_ck1", "obff_ck1", "pipe_ck1";
+
+		power-domains = <&scpsys MT7622_POWER_DOMAIN_HIF0>;
+		bus-range = <0x00 0xff>;
+		ranges = <0x82000000 0 0x28000000  0x0 0x28000000  0 0x8000000>;
+		status = "disabled";
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc1 0>,
+				<0 0 0 2 &pcie_intc1 1>,
+				<0 0 0 3 &pcie_intc1 2>,
+				<0 0 0 4 &pcie_intc1 3>;
+		pcie_intc1: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
 			#interrupt-cells = <1>;
-			ranges;
-			interrupt-map-mask = <0 0 0 7>;
-			interrupt-map = <0 0 0 1 &pcie_intc1 0>,
-					<0 0 0 2 &pcie_intc1 1>,
-					<0 0 0 3 &pcie_intc1 2>,
-					<0 0 0 4 &pcie_intc1 3>;
-			pcie_intc1: interrupt-controller {
-				interrupt-controller;
-				#address-cells = <0>;
-				#interrupt-cells = <1>;
-			};
 		};
 	};
-- 
2.18.0

From jiapeng.chong at linux.alibaba.com  Tue Apr  6 04:59:58 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Tue,  6 Apr 2021 11:59:58 +0800
Subject: [PATCH] usb: gadget: aspeed: Remove unnecessary version.h includes
Message-ID: <1617681598-28165-1-git-send-email-jiapeng.chong@linux.alibaba.com>

"make versioncheck" shows:

./drivers/usb/gadget/udc/aspeed-vhub/hub.c: 33 linux/version.h not
needed.

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/usb/gadget/udc/aspeed-vhub/hub.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/aspeed-vhub/hub.c b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
index 5c7dea5..e5bbc0c 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
@@ -30,7 +30,6 @@
 #include <linux/regmap.h>
 #include <linux/dma-mapping.h>
 #include <linux/bcd.h>
-#include <linux/version.h>
 #include <linux/usb.h>
 #include <linux/usb/hcd.h>
 
-- 
1.8.3.1



From martin.petersen at oracle.com  Tue Apr  6 05:53:17 2021
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Tue,  6 Apr 2021 00:53:17 -0400
Subject: [PATCH 00/11] treewide: address gcc-11 -Wstringop-overread
 warnings
In-Reply-To: <20210322160253.4032422-1-arnd@kernel.org>
References: <20210322160253.4032422-1-arnd@kernel.org>
Message-ID: <161768454091.32082.3141021591391350544.b4-ty@oracle.com>

On Mon, 22 Mar 2021 17:02:38 +0100, Arnd Bergmann wrote:

> The coming gcc release introduces a new warning for string operations
> reading beyond the end of a fixed-length object. After testing
> randconfig kernels for a while, think I have patches for any such
> warnings that came up on x86, arm and arm64.
> 
> Most of these warnings are false-positive ones, either gcc warning
> about something that is entirely correct, or about something that
> looks suspicious but turns out to be correct after all.
> 
> [...]

Applied to 5.13/scsi-queue, thanks!

[09/11] scsi: lpfc: fix gcc -Wstringop-overread warning
        https://git.kernel.org/mkp/scsi/c/ada48ba70f6b

-- 
Martin K. Petersen	Oracle Linux Engineering


From vkoul at kernel.org  Tue Apr  6 06:08:09 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Tue, 6 Apr 2021 10:38:09 +0530
Subject: [PATCH linux-next v2 1/1] phy: Sparx5 Eth SerDes: Use direct
 register operations
In-Reply-To: <20210329141309.612459-2-steen.hegelund@microchip.com>
References: <20210329141309.612459-1-steen.hegelund@microchip.com>
 <20210329141309.612459-2-steen.hegelund@microchip.com>
Message-ID: <YGvsuVMz54R5O7Eb@vkoul-mobl.Dlink>

On 29-03-21, 16:13, Steen Hegelund wrote:
> Use direct register operations instead of a table of register
> information to lower the stack usage.

Applied, thanks

-- 
~Vinod


From vkoul at kernel.org  Tue Apr  6 06:09:29 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Tue, 6 Apr 2021 10:39:29 +0530
Subject: [PATCH] phy: fix resource_size.cocci warnings
In-Reply-To: <20210318232844.GA65886@63b0c5462fda>
References: <202103190711.pUzuZRzG-lkp@intel.com>
 <20210318232844.GA65886@63b0c5462fda>
Message-ID: <YGvtCewknNzLEt7t@vkoul-mobl.Dlink>

On 19-03-21, 07:28, kernel test robot wrote:
> From: kernel test robot <lkp at intel.com>
> 
> drivers/phy/microchip/sparx5_serdes.c:2440:54-57: ERROR: Missing resource_size with iores
> 
> 
>  Use resource_size function on resource object
>  instead of explicit computation.
> 
> Generated by: scripts/coccinelle/api/resource_size.cocci

Applied, thanks

-- 
~Vinod


From gregkh at linuxfoundation.org  Tue Apr  6 06:26:26 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 6 Apr 2021 07:26:26 +0200
Subject: [PATCH] usb: gadget: aspeed: Remove unnecessary version.h includes
In-Reply-To: <1617681598-28165-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1617681598-28165-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <YGvxAmHIgnRMcyuq@kroah.com>

On Tue, Apr 06, 2021 at 11:59:58AM +0800, Jiapeng Chong wrote:
> "make versioncheck" shows:
> 
> ./drivers/usb/gadget/udc/aspeed-vhub/hub.c: 33 linux/version.h not
> needed.

Then you need to fix the tool, and always test-build patches before you
send them out, as this is obviously wrong :(



From chiawei_wang at aspeedtech.com  Tue Apr  6 07:07:00 2021
From: chiawei_wang at aspeedtech.com (ChiaWei Wang)
Date: Tue, 6 Apr 2021 06:07:00 +0000
Subject: [PATCH v2 06/21] ipmi: kcs_bmc_aspeed: Use of match data to
 extract KCS properties
In-Reply-To: <20210319062752.145730-6-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-6-andrew@aj.id.au>
Message-ID: <HK0PR06MB377918E87DEFAC54F8C00D8C91769@HK0PR06MB3779.apcprd06.prod.outlook.com>

I have tried this patch on Intel EGS CRB with AST2600 A1 as the BMC.
Chiawei

Tested-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>

> -----Original Message-----
> From: Andrew Jeffery <andrew at aj.id.au>
> Sent: Friday, March 19, 2021 2:28 PM
> To: openipmi-developer at lists.sourceforge.net; openbmc at lists.ozlabs.org;
> minyard at acm.org
> 
> Unpack and remove the aspeed_kcs_probe_of_v[12]() functions to aid
> rearranging how the private device-driver memory is allocated.
> 
> Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> ---
>  drivers/char/ipmi/kcs_bmc_aspeed.c | 146 ++++++++++++++---------------
>  1 file changed, 68 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
> b/drivers/char/ipmi/kcs_bmc_aspeed.c
> index eefe362f65f0..061f53676206 100644
> --- a/drivers/char/ipmi/kcs_bmc_aspeed.c
> +++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
> @@ -13,6 +13,7 @@
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_address.h>
> +#include <linux/of_device.h>
>  #include <linux/platform_device.h>
>  #include <linux/poll.h>
>  #include <linux/regmap.h>
> @@ -63,6 +64,10 @@ struct aspeed_kcs_bmc {
>  	struct regmap *map;
>  };
> 
> +struct aspeed_kcs_of_ops {
> +	int (*get_channel)(struct platform_device *pdev);
> +	int (*get_io_address)(struct platform_device *pdev); };
> 
>  static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)  { @@ -231,13
> +236,10 @@ static const struct kcs_ioreg
> ast_kcs_bmc_ioregs[KCS_CHANNEL_MAX] = {
>  	{ .idr = LPC_IDR4, .odr = LPC_ODR4, .str = LPC_STR4 },  };
> 
> -static struct kcs_bmc *aspeed_kcs_probe_of_v1(struct platform_device
> *pdev)
> +static int aspeed_kcs_of_v1_get_channel(struct platform_device *pdev)
>  {
> -	struct aspeed_kcs_bmc *priv;
>  	struct device_node *np;
> -	struct kcs_bmc *kcs;
>  	u32 channel;
> -	u32 slave;
>  	int rc;
> 
>  	np = pdev->dev.of_node;
> @@ -245,105 +247,78 @@ static struct kcs_bmc
> *aspeed_kcs_probe_of_v1(struct platform_device *pdev)
>  	rc = of_property_read_u32(np, "kcs_chan", &channel);
>  	if ((rc != 0) || (channel == 0 || channel > KCS_CHANNEL_MAX)) {
>  		dev_err(&pdev->dev, "no valid 'kcs_chan' configured\n");
> -		return ERR_PTR(-EINVAL);
> +		return -EINVAL;
>  	}
> 
> -	kcs = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc),
> channel);
> -	if (!kcs)
> -		return ERR_PTR(-ENOMEM);
> +	return channel;
> +}
> 
> -	priv = kcs_bmc_priv(kcs);
> -	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> -	if (IS_ERR(priv->map)) {
> -		dev_err(&pdev->dev, "Couldn't get regmap\n");
> -		return ERR_PTR(-ENODEV);
> -	}
> +static int aspeed_kcs_of_v1_get_io_address(struct platform_device
> +*pdev) {
> +	u32 slave;
> +	int rc;
> 
> -	rc = of_property_read_u32(np, "kcs_addr", &slave);
> -	if (rc) {
> +	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", &slave);
> +	if (rc || slave > 0xffff) {
>  		dev_err(&pdev->dev, "no valid 'kcs_addr' configured\n");
> -		return ERR_PTR(-EINVAL);
> +		return -EINVAL;
>  	}
> 
> -	kcs->ioreg = ast_kcs_bmc_ioregs[channel - 1];
> -	aspeed_kcs_set_address(kcs, slave);
> -
> -	return kcs;
> -}
> -
> -static int aspeed_kcs_calculate_channel(const struct kcs_ioreg *regs) -{
> -	int i;
> -
> -	for (i = 0; i < ARRAY_SIZE(ast_kcs_bmc_ioregs); i++) {
> -		if (!memcmp(&ast_kcs_bmc_ioregs[i], regs, sizeof(*regs)))
> -			return i + 1;
> -	}
> -
> -	return -EINVAL;
> +	return slave;
>  }
> 
> -static struct kcs_bmc *aspeed_kcs_probe_of_v2(struct platform_device
> *pdev)
> +static int aspeed_kcs_of_v2_get_channel(struct platform_device *pdev)
>  {
> -	struct aspeed_kcs_bmc *priv;
>  	struct device_node *np;
>  	struct kcs_ioreg ioreg;
> -	struct kcs_bmc *kcs;
>  	const __be32 *reg;
> -	int channel;
> -	u32 slave;
> -	int rc;
> +	int i;
> 
>  	np = pdev->dev.of_node;
> 
>  	/* Don't translate addresses, we want offsets for the regmaps */
>  	reg = of_get_address(np, 0, NULL, NULL);
>  	if (!reg)
> -		return ERR_PTR(-EINVAL);
> +		return -EINVAL;
>  	ioreg.idr = be32_to_cpup(reg);
> 
>  	reg = of_get_address(np, 1, NULL, NULL);
>  	if (!reg)
> -		return ERR_PTR(-EINVAL);
> +		return -EINVAL;
>  	ioreg.odr = be32_to_cpup(reg);
> 
>  	reg = of_get_address(np, 2, NULL, NULL);
>  	if (!reg)
> -		return ERR_PTR(-EINVAL);
> +		return -EINVAL;
>  	ioreg.str = be32_to_cpup(reg);
> 
> -	channel = aspeed_kcs_calculate_channel(&ioreg);
> -	if (channel < 0)
> -		return ERR_PTR(channel);
> -
> -	kcs = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc),
> channel);
> -	if (!kcs)
> -		return ERR_PTR(-ENOMEM);
> -
> -	kcs->ioreg = ioreg;
> -
> -	priv = kcs_bmc_priv(kcs);
> -	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> -	if (IS_ERR(priv->map)) {
> -		dev_err(&pdev->dev, "Couldn't get regmap\n");
> -		return ERR_PTR(-ENODEV);
> +	for (i = 0; i < ARRAY_SIZE(ast_kcs_bmc_ioregs); i++) {
> +		if (!memcmp(&ast_kcs_bmc_ioregs[i], &ioreg, sizeof(ioreg)))
> +			return i + 1;
>  	}
> 
> -	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &slave);
> -	if (rc)
> -		return ERR_PTR(rc);
> +	return -EINVAL;
> +}
> 
> -	aspeed_kcs_set_address(kcs, slave);
> +static int aspeed_kcs_of_v2_get_io_address(struct platform_device
> +*pdev) {
> +	uint32_t slave;
> +	int rc;
> 
> -	return kcs;
> +	rc = of_property_read_u32(pdev->dev.of_node, "aspeed,lpc-io-reg",
> &slave);
> +	if (rc || slave > 0xffff)
> +		return -EINVAL;
> +
> +	return slave;
>  }
> 
>  static int aspeed_kcs_probe(struct platform_device *pdev)  {
> +	const struct aspeed_kcs_of_ops *ops;
>  	struct device *dev = &pdev->dev;
>  	struct kcs_bmc *kcs_bmc;
>  	struct device_node *np;
> -	int rc;
> +	int rc, channel, addr;
> 
>  	np = dev->of_node->parent;
>  	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") && @@
> -352,23 +327,28 @@ static int aspeed_kcs_probe(struct platform_device
> *pdev)
>  		dev_err(dev, "unsupported LPC device binding\n");
>  		return -ENODEV;
>  	}
> -
> -	np = dev->of_node;
> -	if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
> -	    of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
> -		kcs_bmc = aspeed_kcs_probe_of_v1(pdev);
> -	else if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc-v2") ||
> -		 of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc-v2"))
> -		kcs_bmc = aspeed_kcs_probe_of_v2(pdev);
> -	else
> +	ops = of_device_get_match_data(&pdev->dev);
> +	if (!ops)
>  		return -EINVAL;
> 
> -	if (IS_ERR(kcs_bmc))
> -		return PTR_ERR(kcs_bmc);
> +	channel = ops->get_channel(pdev);
> +	if (channel < 0)
> +		return channel;
> 
> +	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc),
> channel);
> +	if (!kcs_bmc)
> +		return -ENOMEM;
> +
> +	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
>  	kcs_bmc->io_inputb = aspeed_kcs_inb;
>  	kcs_bmc->io_outputb = aspeed_kcs_outb;
> 
> +	addr = ops->get_io_address(pdev);
> +	if (addr < 0)
> +		return addr;
> +
> +	aspeed_kcs_set_address(kcs_bmc, addr);
> +
>  	rc = aspeed_kcs_config_irq(kcs_bmc, pdev);
>  	if (rc)
>  		return rc;
> @@ -400,11 +380,21 @@ static int aspeed_kcs_remove(struct
> platform_device *pdev)
>  	return 0;
>  }
> 
> +static const struct aspeed_kcs_of_ops of_v1_ops = {
> +	.get_channel = aspeed_kcs_of_v1_get_channel,
> +	.get_io_address = aspeed_kcs_of_v1_get_io_address, };
> +
> +static const struct aspeed_kcs_of_ops of_v2_ops = {
> +	.get_channel = aspeed_kcs_of_v2_get_channel,
> +	.get_io_address = aspeed_kcs_of_v2_get_io_address, };
> +
>  static const struct of_device_id ast_kcs_bmc_match[] = {
> -	{ .compatible = "aspeed,ast2400-kcs-bmc" },
> -	{ .compatible = "aspeed,ast2500-kcs-bmc" },
> -	{ .compatible = "aspeed,ast2400-kcs-bmc-v2" },
> -	{ .compatible = "aspeed,ast2500-kcs-bmc-v2" },
> +	{ .compatible = "aspeed,ast2400-kcs-bmc", .data = &of_v1_ops },
> +	{ .compatible = "aspeed,ast2500-kcs-bmc", .data = &of_v1_ops },
> +	{ .compatible = "aspeed,ast2400-kcs-bmc-v2", .data = &of_v2_ops },
> +	{ .compatible = "aspeed,ast2500-kcs-bmc-v2", .data = &of_v2_ops },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, ast_kcs_bmc_match);
> --
> 2.27.0



From chiawei_wang at aspeedtech.com  Tue Apr  6 07:07:34 2021
From: chiawei_wang at aspeedtech.com (ChiaWei Wang)
Date: Tue, 6 Apr 2021 06:07:34 +0000
Subject: [PATCH v2 13/21] ipmi: kcs_bmc: Decouple the IPMI chardev from
 the core
In-Reply-To: <20210319062752.145730-13-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-13-andrew@aj.id.au>
Message-ID: <HK0PR06MB3779088F39332DA6AEA8B06B91769@HK0PR06MB3779.apcprd06.prod.outlook.com>

I have tried this patch on Intel EGS CRB with AST2600 A1 as the BMC.
Chiawei

Tested-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>

> -----Original Message-----
> From: Andrew Jeffery <andrew at aj.id.au>
> Sent: Friday, March 19, 2021 2:28 PM
> To: openipmi-developer at lists.sourceforge.net; openbmc at lists.ozlabs.org;
> minyard at acm.org
> Subject: [PATCH v2 13/21] ipmi: kcs_bmc: Decouple the IPMI chardev from the
> core
> 
> Now that we have untangled the data-structures, split the userspace interface
> out into its own module. Userspace interfaces and drivers are registered to the
> KCS BMC core to support arbitrary binding of either.
> 
> Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> ---
>  drivers/char/ipmi/Kconfig             | 13 +++++
>  drivers/char/ipmi/Makefile            |  3 +-
>  drivers/char/ipmi/kcs_bmc.c           | 78
> ++++++++++++++++++++++++++-
>  drivers/char/ipmi/kcs_bmc.h           |  4 --
>  drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 33 +++++++++---
>  drivers/char/ipmi/kcs_bmc_client.h    | 14 +++++
>  6 files changed, 132 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig index
> 07847d9a459a..bc5f81899b62 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -124,6 +124,19 @@ config NPCM7XX_KCS_IPMI_BMC
>  	  This support is also available as a module.  If so, the module
>  	  will be called kcs_bmc_npcm7xx.
> 
> +config IPMI_KCS_BMC_CDEV_IPMI
> +	depends on IPMI_KCS_BMC
> +	tristate "IPMI character device interface for BMC KCS devices"
> +	help
> +	  Provides a BMC-side character device implementing IPMI
> +	  semantics for KCS IPMI devices.
> +
> +	  Say YES if you wish to expose KCS devices on the BMC for IPMI
> +	  purposes.
> +
> +	  This support is also available as a module. The module will be
> +	  called kcs_bmc_cdev_ipmi.
> +
>  config ASPEED_BT_IPMI_BMC
>  	depends on ARCH_ASPEED || COMPILE_TEST
>  	depends on REGMAP && REGMAP_MMIO && MFD_SYSCON diff --git
> a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile index
> a302bc865370..fcfa676afddb 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -22,7 +22,8 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
>  obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
>  obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
>  obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> -obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
> +obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> +obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o
>  obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>  obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
>  obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o diff --git
> a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c index
> 266ebec71d6f..694db6ee2a92 100644
> --- a/drivers/char/ipmi/kcs_bmc.c
> +++ b/drivers/char/ipmi/kcs_bmc.c
> @@ -5,7 +5,9 @@
>   */
> 
>  #include <linux/device.h>
> +#include <linux/list.h>
>  #include <linux/module.h>
> +#include <linux/mutex.h>
> 
>  #include "kcs_bmc.h"
> 
> @@ -13,6 +15,11 @@
>  #include "kcs_bmc_device.h"
>  #include "kcs_bmc_client.h"
> 
> +/* Record probed devices and cdevs */
> +static DEFINE_MUTEX(kcs_bmc_lock);
> +static LIST_HEAD(kcs_bmc_devices);
> +static LIST_HEAD(kcs_bmc_cdevs);
> +
>  /* Consumer data access */
> 
>  u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc) @@ -100,16
> +107,83 @@ EXPORT_SYMBOL(kcs_bmc_disable_device);
> 
>  int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc)  {
> -	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> +	struct kcs_bmc_cdev *cdev;
> +	int rc;
> +
> +	spin_lock_init(&kcs_bmc->lock);
> +	kcs_bmc->client = NULL;
> +
> +	mutex_lock(&kcs_bmc_lock);
> +	list_add(&kcs_bmc->entry, &kcs_bmc_devices);
> +	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
> +		rc = cdev->ops->add_device(kcs_bmc);
> +		if (rc)
> +			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel
> %d: %d",
> +				kcs_bmc->channel, rc);
> +	}
> +	mutex_unlock(&kcs_bmc_lock);
> +
> +	return 0;
>  }
>  EXPORT_SYMBOL(kcs_bmc_add_device);
> 
>  int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc)  {
> -	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
> +	struct kcs_bmc_cdev *cdev;
> +	int rc;
> +
> +	mutex_lock(&kcs_bmc_lock);
> +	list_del(&kcs_bmc->entry);
> +	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
> +		rc = cdev->ops->remove_device(kcs_bmc);
> +		if (rc)
> +			dev_err(kcs_bmc->dev, "Failed to remove chardev for KCS
> channel %d: %d",
> +				kcs_bmc->channel, rc);
> +	}
> +	mutex_unlock(&kcs_bmc_lock);
> +
> +	return 0;
>  }
>  EXPORT_SYMBOL(kcs_bmc_remove_device);
> 
> +int kcs_bmc_register_cdev(struct kcs_bmc_cdev *cdev) {
> +	struct kcs_bmc_device *kcs_bmc;
> +	int rc;
> +
> +	mutex_lock(&kcs_bmc_lock);
> +	list_add(&cdev->entry, &kcs_bmc_cdevs);
> +	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
> +		rc = cdev->ops->add_device(kcs_bmc);
> +		if (rc)
> +			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel
> %d: %d",
> +				kcs_bmc->channel, rc);
> +	}
> +	mutex_unlock(&kcs_bmc_lock);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(kcs_bmc_register_cdev);
> +
> +int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev) {
> +	struct kcs_bmc_device *kcs_bmc;
> +	int rc;
> +
> +	mutex_lock(&kcs_bmc_lock);
> +	list_del(&cdev->entry);
> +	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
> +		rc = cdev->ops->remove_device(kcs_bmc);
> +		if (rc)
> +			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel
> %d: %d",
> +				kcs_bmc->channel, rc);
> +	}
> +	mutex_unlock(&kcs_bmc_lock);
> +
> +	return rc;
> +}
> +EXPORT_SYMBOL(kcs_bmc_unregister_cdev);
> +
>  MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>"); diff --git
> a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h index
> 3f266740c759..5deb9a0b8e60 100644
> --- a/drivers/char/ipmi/kcs_bmc.h
> +++ b/drivers/char/ipmi/kcs_bmc.h
> @@ -42,8 +42,4 @@ struct kcs_bmc_device {
>  	spinlock_t lock;
>  	struct kcs_bmc_client *client;
>  };
> -
> -/* Temporary exports while refactoring */ -int
> kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc); -int
> kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);  #endif /*
> __KCS_BMC_H__ */ diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> index 58c42e76483d..df83d67851ac 100644
> --- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> +++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> @@ -469,8 +469,7 @@ static const struct file_operations kcs_bmc_ipmi_fops
> = {  static DEFINE_SPINLOCK(kcs_bmc_ipmi_instances_lock);
>  static LIST_HEAD(kcs_bmc_ipmi_instances);
> 
> -int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc); -int
> kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
> +static int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
>  {
>  	struct kcs_bmc_ipmi *priv;
>  	int rc;
> @@ -512,10 +511,8 @@ int kcs_bmc_ipmi_attach_cdev(struct
> kcs_bmc_device *kcs_bmc)
> 
>  	return 0;
>  }
> -EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
> 
> -int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc); -int
> kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
> +static int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
>  {
>  	struct kcs_bmc_ipmi *priv = NULL, *pos;
> 
> @@ -541,7 +538,31 @@ int kcs_bmc_ipmi_detach_cdev(struct
> kcs_bmc_device *kcs_bmc)
> 
>  	return 0;
>  }
> -EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
> +
> +static const struct kcs_bmc_cdev_ops kcs_bmc_ipmi_cdev_ops = {
> +	.add_device = kcs_bmc_ipmi_attach_cdev,
> +	.remove_device = kcs_bmc_ipmi_detach_cdev, };
> +
> +static struct kcs_bmc_cdev kcs_bmc_ipmi_cdev = {
> +	.ops = &kcs_bmc_ipmi_cdev_ops,
> +};
> +
> +static int kcs_bmc_ipmi_init(void)
> +{
> +	return kcs_bmc_register_cdev(&kcs_bmc_ipmi_cdev);
> +}
> +module_init(kcs_bmc_ipmi_init);
> +
> +static void kcs_bmc_ipmi_exit(void)
> +{
> +	int rc;
> +
> +	rc = kcs_bmc_unregister_cdev(&kcs_bmc_ipmi_cdev);
> +	if (rc)
> +		pr_warn("Failed to remove KCS BMC client: %d", rc); }
> +module_exit(kcs_bmc_ipmi_exit);
> 
>  MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>"); diff
> --git a/drivers/char/ipmi/kcs_bmc_client.h
> b/drivers/char/ipmi/kcs_bmc_client.h
> index 2dd710f4b4aa..d0a7404ff584 100644
> --- a/drivers/char/ipmi/kcs_bmc_client.h
> +++ b/drivers/char/ipmi/kcs_bmc_client.h
> @@ -10,6 +10,17 @@
> 
>  #include "kcs_bmc.h"
> 
> +struct kcs_bmc_cdev_ops {
> +	int (*add_device)(struct kcs_bmc_device *kcs_bmc);
> +	int (*remove_device)(struct kcs_bmc_device *kcs_bmc); };
> +
> +struct kcs_bmc_cdev {
> +	struct list_head entry;
> +
> +	const struct kcs_bmc_cdev_ops *ops;
> +};
> +
>  struct kcs_bmc_client_ops {
>  	int (*event)(struct kcs_bmc_client *client);  }; @@ -20,6 +31,9 @@
> struct kcs_bmc_client {
>  	struct kcs_bmc_device *dev;
>  };
> 
> +int kcs_bmc_register_cdev(struct kcs_bmc_cdev *cdev); int
> +kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev);
> +
>  int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct
> kcs_bmc_client *client);  void kcs_bmc_disable_device(struct
> kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
> 
> --
> 2.27.0



From chiawei_wang at aspeedtech.com  Tue Apr  6 07:09:12 2021
From: chiawei_wang at aspeedtech.com (ChiaWei Wang)
Date: Tue, 6 Apr 2021 06:09:12 +0000
Subject: [PATCH v2 21/21] ipmi: kcs_bmc_aspeed: Optionally apply status
 address
In-Reply-To: <20210319062752.145730-21-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-21-andrew@aj.id.au>
Message-ID: <HK0PR06MB3779BE4C5C6E2758DC60FDCA91769@HK0PR06MB3779.apcprd06.prod.outlook.com>

Reviewed-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>

> -----Original Message-----
> From: Andrew Jeffery <andrew at aj.id.au>
> Sent: Friday, March 19, 2021 2:28 PM
> To: openipmi-developer at lists.sourceforge.net; openbmc at lists.ozlabs.org;
> minyard at acm.org
> Subject: [PATCH v2 21/21] ipmi: kcs_bmc_aspeed: Optionally apply status
> address
> 
> Some Aspeed KCS devices can derive the status register address from the
> address of the data register. As such, the address of the status register can be
> implicit in the configuration if desired. On the other hand, sometimes address
> schemes might be requested that are incompatible with the default addressing
> scheme. Allow these requests where possible if the devicetree specifies the
> status register address.
> 
> Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> ---
>  drivers/char/ipmi/kcs_bmc_aspeed.c | 113 +++++++++++++++++++++--------
>  1 file changed, 81 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c
> b/drivers/char/ipmi/kcs_bmc_aspeed.c
> index 7334b1f51dcc..98789b837690 100644
> --- a/drivers/char/ipmi/kcs_bmc_aspeed.c
> +++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
> @@ -83,6 +83,8 @@
>  #define LPC_STR2             0x040
>  #define LPC_STR3             0x044
>  #define LPC_HICRB            0x100
> +#define     LPC_HICRB_EN16LADR2      BIT(5)
> +#define     LPC_HICRB_EN16LADR1      BIT(4)
>  #define     LPC_HICRB_IBFIE4         BIT(1)
>  #define     LPC_HICRB_LPC4E          BIT(0)
>  #define LPC_HICRC            0x104
> @@ -96,6 +98,11 @@
>  #define LPC_IDR4             0x114
>  #define LPC_ODR4             0x118
>  #define LPC_STR4             0x11C
> +#define LPC_LSADR12	     0x120
> +#define     LPC_LSADR12_LSADR2_MASK  GENMASK(31, 16)
> +#define     LPC_LSADR12_LSADR2_SHIFT 16
> +#define     LPC_LSADR12_LSADR1_MASK  GENMASK(15, 0)
> +#define     LPC_LSADR12_LSADR1_SHIFT 0
> 
>  #define OBE_POLL_PERIOD	     (HZ / 2)
> 
> @@ -123,7 +130,7 @@ struct aspeed_kcs_bmc {
> 
>  struct aspeed_kcs_of_ops {
>  	int (*get_channel)(struct platform_device *pdev);
> -	int (*get_io_address)(struct platform_device *pdev);
> +	int (*get_io_address)(struct platform_device *pdev, u32 addrs[2]);
>  };
> 
>  static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct
> kcs_bmc_device *kcs_bmc) @@ -217,38 +224,64 @@ static void
> aspeed_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask,
>   *     C. KCS4
>   *        D / C : CA4h / CA5h
>   */
> -static void aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u16
> addr)
> +static int aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u32
> +addrs[2], int nr_addrs)
>  {
>  	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 
> -	switch (kcs_bmc->channel) {
> +	if (WARN_ON(nr_addrs < 1 || nr_addrs > 2))
> +		return -EINVAL;
> +
> +	switch (priv->kcs_bmc.channel) {
>  	case 1:
> -		regmap_update_bits(priv->map, LPC_HICR4,
> -				LPC_HICR4_LADR12AS, 0);
> -		regmap_write(priv->map, LPC_LADR12H, addr >> 8);
> -		regmap_write(priv->map, LPC_LADR12L, addr & 0xFF);
> +		regmap_update_bits(priv->map, LPC_HICR4, LPC_HICR4_LADR12AS,
> 0);
> +		regmap_write(priv->map, LPC_LADR12H, addrs[0] >> 8);
> +		regmap_write(priv->map, LPC_LADR12L, addrs[0] & 0xFF);
> +		if (nr_addrs == 2) {
> +			regmap_update_bits(priv->map, LPC_LSADR12,
> LPC_LSADR12_LSADR1_MASK,
> +					   addrs[1] << LPC_LSADR12_LSADR1_SHIFT);
> +
> +			regmap_update_bits(priv->map, LPC_HICRB,
> LPC_HICRB_EN16LADR1,
> +					   LPC_HICRB_EN16LADR1);
> +		}
>  		break;
> 
>  	case 2:
> -		regmap_update_bits(priv->map, LPC_HICR4,
> -				LPC_HICR4_LADR12AS, LPC_HICR4_LADR12AS);
> -		regmap_write(priv->map, LPC_LADR12H, addr >> 8);
> -		regmap_write(priv->map, LPC_LADR12L, addr & 0xFF);
> +		regmap_update_bits(priv->map, LPC_HICR4, LPC_HICR4_LADR12AS,
> LPC_HICR4_LADR12AS);
> +		regmap_write(priv->map, LPC_LADR12H, addrs[0] >> 8);
> +		regmap_write(priv->map, LPC_LADR12L, addrs[0] & 0xFF);
> +		if (nr_addrs == 2) {
> +			regmap_update_bits(priv->map, LPC_LSADR12,
> LPC_LSADR12_LSADR2_MASK,
> +					   addrs[1] << LPC_LSADR12_LSADR2_SHIFT);
> +
> +			regmap_update_bits(priv->map, LPC_HICRB,
> LPC_HICRB_EN16LADR2,
> +					   LPC_HICRB_EN16LADR2);
> +		}
>  		break;
> 
>  	case 3:
> -		regmap_write(priv->map, LPC_LADR3H, addr >> 8);
> -		regmap_write(priv->map, LPC_LADR3L, addr & 0xFF);
> +		if (nr_addrs == 2) {
> +			dev_err(priv->kcs_bmc.dev,
> +				"Channel 3 only supports inferred status IO address\n");
> +			return -EINVAL;
> +		}
> +
> +		regmap_write(priv->map, LPC_LADR3H, addrs[0] >> 8);
> +		regmap_write(priv->map, LPC_LADR3L, addrs[0] & 0xFF);
>  		break;
> 
>  	case 4:
> -		regmap_write(priv->map, LPC_LADR4, ((addr + 1) << 16) |
> -			addr);
> +		if (nr_addrs == 1)
> +			regmap_write(priv->map, LPC_LADR4, ((addrs[0] + 1) << 16) |
> addrs[0]);
> +		else
> +			regmap_write(priv->map, LPC_LADR4, (addrs[1] << 16) |
> addrs[0]);
> +
>  		break;
> 
>  	default:
> -		break;
> +		return -EINVAL;
>  	}
> +
> +	return 0;
>  }
> 
>  static inline int aspeed_kcs_map_serirq_type(u32 dt_type) @@ -462,18
> +495,18 @@ static int aspeed_kcs_of_v1_get_channel(struct platform_device
> *pdev)
>  	return channel;
>  }
> 
> -static int aspeed_kcs_of_v1_get_io_address(struct platform_device *pdev)
> +static int
> +aspeed_kcs_of_v1_get_io_address(struct platform_device *pdev, u32
> +addrs[2])
>  {
> -	u32 slave;
>  	int rc;
> 
> -	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", &slave);
> -	if (rc || slave > 0xffff) {
> +	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", addrs);
> +	if (rc || addrs[0] > 0xffff) {
>  		dev_err(&pdev->dev, "no valid 'kcs_addr' configured\n");
>  		return -EINVAL;
>  	}
> 
> -	return slave;
> +	return 1;
>  }
> 
>  static int aspeed_kcs_of_v2_get_channel(struct platform_device *pdev) @@
> -509,16 +542,27 @@ static int aspeed_kcs_of_v2_get_channel(struct
> platform_device *pdev)
>  	return -EINVAL;
>  }
> 
> -static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
> +static int
> +aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev, u32
> +addrs[2])
>  {
> -	uint32_t slave;
>  	int rc;
> 
> -	rc = of_property_read_u32(pdev->dev.of_node, "aspeed,lpc-io-reg",
> &slave);
> -	if (rc || slave > 0xffff)
> +	rc = of_property_read_variable_u32_array(pdev->dev.of_node,
> +						 "aspeed,lpc-io-reg",
> +						 addrs, 1, 2);
> +	if (rc < 0)
> +		return rc;
> +
> +	if (WARN_ON(rc == 0))
> +		return -EINVAL;
> +
> +	if (addrs[0] > 0xffff)
> +		return -EINVAL;
> +
> +	if (rc == 2 && addrs[1] > 0xffff)
>  		return -EINVAL;
> 
> -	return slave;
> +	return rc;
>  }
> 
>  static int aspeed_kcs_probe(struct platform_device *pdev) @@ -527,9
> +571,11 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>  	struct kcs_bmc_device *kcs_bmc;
>  	struct aspeed_kcs_bmc *priv;
>  	struct device_node *np;
> -	int rc, channel, addr;
>  	bool have_upstream_irq;
>  	u32 upstream_irq[2];
> +	int rc, channel;
> +	int nr_addrs;
> +	u32 addrs[2];
> 
>  	np = pdev->dev.of_node->parent;
>  	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") && @@ -547,9
> +593,9 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>  	if (channel < 0)
>  		return channel;
> 
> -	addr = ops->get_io_address(pdev);
> -	if (addr < 0)
> -		return addr;
> +	nr_addrs = ops->get_io_address(pdev, addrs);
> +	if (nr_addrs < 0)
> +		return nr_addrs;
> 
>  	np = pdev->dev.of_node;
>  	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts",
> upstream_irq, 2); @@ -578,7 +624,9 @@ static int aspeed_kcs_probe(struct
> platform_device *pdev)
>  	priv->obe.remove = false;
>  	timer_setup(&priv->obe.timer, aspeed_kcs_check_obe, 0);
> 
> -	aspeed_kcs_set_address(kcs_bmc, addr);
> +	rc = aspeed_kcs_set_address(kcs_bmc, addrs, nr_addrs);
> +	if (rc)
> +		return rc;
> 
>  	/* Host to BMC IRQ */
>  	rc = aspeed_kcs_config_downstream_irq(kcs_bmc, pdev); @@ -600,7
> +648,8 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>  	if (rc < 0)
>  		return rc;
> 
> -	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n",
> kcs_bmc->channel, addr);
> +	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n",
> +			kcs_bmc->channel, addrs[0]);
> 
>  	return 0;
>  }
> --
> 2.27.0



From vivek.gautam at arm.com  Tue Apr  6 07:24:08 2021
From: vivek.gautam at arm.com (Vivek Kumar Gautam)
Date: Tue, 6 Apr 2021 11:54:08 +0530
Subject: [PATCH RFC v1 15/15] iommu/virtio: Update fault type and reason
 info for viommu fault
In-Reply-To: <YGH+5pHtR6gWnimB@myrica>
References: <20210115121342.15093-1-vivek.gautam@arm.com>
 <20210115121342.15093-16-vivek.gautam@arm.com> <YD/GjQIKkaJ5+UJM@myrica>
 <d8a81406-12c6-a5e1-7297-49c1a0a800ab@arm.com> <YGH+5pHtR6gWnimB@myrica>
Message-ID: <248424c9-04ab-18b1-50f7-b995b6d7b1e2@arm.com>



On 3/29/21 9:53 PM, Jean-Philippe Brucker wrote:
> On Fri, Mar 12, 2021 at 06:39:05PM +0530, Vivek Kumar Gautam wrote:
>> To complete the page request we would also need to send the response back to
>> the host from virtio backend when handling page request. So the virtio
>> command should also be accompanied with a vfio api to send the page request
>> response back to the host. Isn't it?
>> This is where the host smmuv3 can send PRI_RESP command to the device to
>> complete the page fault.
> 
> It looks like Eric already has this in the VFIO series:
> https://lore.kernel.org/linux-iommu/20210223210625.604517-14-eric.auger at redhat.com/

Right, I have taken this change to work on getting the vSVA with 
virtio-iommu.
For this I am adding a new request for virtio-iomm - 
VIRTIO_IOMMU_T_PAGE_RESP, and related struct virtio_iommu_req_page_resp 
that would contain information such as, pasid, grpid, response_code, 
flags, and endpoint. This is inline with struct iommu_page_response.
I will post out the patches for this soon.

Thanks & regards
Vivek

> 
> Thanks,
> Jean
> 


From krzysztof.kozlowski at canonical.com  Tue Apr  6 07:34:36 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 6 Apr 2021 08:34:36 +0200
Subject: linux-next: build warning after merge of the arm-soc tree
In-Reply-To: <20210406104511.2535b830@canb.auug.org.au>
References: <20210406104511.2535b830@canb.auug.org.au>
Message-ID: <190b8e95-2a96-142e-7b98-34318eea6804@canonical.com>


On 06/04/2021 02:45, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the arm-soc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/clk/socfpga/clk-gate.c: In function 'socfpga_clk_recalc_rate':
> drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
>   102 |   if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
>       |       ^
> 
> Exposed by commit
> 
>   cdb1e8b4f4c2 ("clk: socfpga: allow compile testing of Stratix 10 / Agilex clocks")
>   552418658acd ("clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile test)")
> 

Thanks Stephen. This is a result of compile testing and was already
fixed via clk tree. You should not have the warning after all the merges.

https://lore.kernel.org/lkml/20210314110709.32599-1-krzysztof.kozlowski at canonical.com/

Best regards,
Krzysztof


From mhu at silicom.dk  Tue Apr  6 07:42:51 2021
From: mhu at silicom.dk (=?UTF-8?Q?Martin_Hundeb=c3=b8ll?=)
Date: Tue, 6 Apr 2021 08:42:51 +0200
Subject: [PATCH RFC 2/3] fpga: support loading from a pre-allocated buffer
In-Reply-To: <20210402090933.32276-3-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
 <20210402090933.32276-3-nava.manne@xilinx.com>
Message-ID: <531e5970-acc5-fc89-497c-cbff4259a416@silicom.dk>

Hi Nava,

On minor comment below.

On 02/04/2021 11.09, Nava kishore Manne wrote:
> Some systems are memory constrained but they need to load very
> large Configuration files. The FPGA subsystem allows drivers to
> request this Configuration image be loaded from the filesystem,
> but this requires that the entire configuration data be loaded
> into kernel memory first before it's provided to the driver.
> This can lead to a situation where we map the configuration
> data twice, once to load the configuration data into kernel
> memory and once to copy the configuration data into the final
> resting place which is nothing but a dma-able continuous buffer.
> 
> This creates needless memory pressure and delays due to multiple
> copies. Let's add a dmabuf handling support to the fpga manager
> framework that allows drivers to load the Configuration data
> directly from a pre-allocated buffer. This skips the intermediate
> step of allocating a buffer in kernel memory to hold the
> Configuration data.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>   drivers/fpga/fpga-mgr.c       | 126 +++++++++++++++++++++++++++++++++-
>   drivers/fpga/of-fpga-region.c |   3 +
>   include/linux/fpga/fpga-mgr.h |   6 +-
>   3 files changed, 132 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index b85bc47c91a9..13faed61af62 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -8,6 +8,8 @@
>    * With code from the mailing list:
>    * Copyright (C) 2013 Xilinx, Inc.
>    */
> +#include <linux/dma-buf.h>
> +#include <linux/dma-map-ops.h>
>   #include <linux/firmware.h>
>   #include <linux/fpga/fpga-mgr.h>
>   #include <linux/idr.h>
> @@ -306,6 +308,51 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
>   	return rc;
>   }
>   
> +/**
> + * fpga_mgr_buf_load - load fpga from image in dma buffer

s/fpga_mgr_buf_load/fpga_dmabuf_load

// Martin

> + * @mgr:        fpga manager
> + * @info:       fpga image info
> + *
> + * Step the low level fpga manager through the device-specific steps of getting
> + * an FPGA ready to be configured, writing the image to it, then doing whatever
> + * post-configuration steps necessary.  This code assumes the caller got the
> + * mgr pointer from of_fpga_mgr_get() and checked that it is not an error code.
> + *
> + * Return: 0 on success, negative error code otherwise.
> + */
> +static int fpga_dmabuf_load(struct fpga_manager *mgr,
> +			    struct fpga_image_info *info)
> +{
> +	struct dma_buf_attachment *attach;
> +	struct sg_table *sgt;
> +	int ret;
> +
> +	/* create attachment for dmabuf with the user device */
> +	attach = dma_buf_attach(mgr->dmabuf, &mgr->dev);
> +	if (IS_ERR(attach)) {
> +		pr_err("failed to attach dmabuf\n");
> +		ret = PTR_ERR(attach);
> +		goto fail_put;
> +	}
> +
> +	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> +	if (IS_ERR(sgt)) {
> +		ret = PTR_ERR(sgt);
> +		goto fail_detach;
> +	}
> +
> +	info->sgt = sgt;
> +	ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
> +	dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
> +
> +fail_detach:
> +	dma_buf_detach(mgr->dmabuf, attach);
> +fail_put:
> +	dma_buf_put(mgr->dmabuf);
> +
> +	return ret;
> +}
> +
>   /**
>    * fpga_mgr_firmware_load - request firmware and load to fpga
>    * @mgr:	fpga manager
> @@ -358,6 +405,8 @@ static int fpga_mgr_firmware_load(struct fpga_manager *mgr,
>    */
>   int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info)
>   {
> +	if (info->flags & FPGA_MGR_CONFIG_DMA_BUF)
> +		return fpga_dmabuf_load(mgr, info);
>   	if (info->sgt)
>   		return fpga_mgr_buf_load_sg(mgr, info, info->sgt);
>   	if (info->buf && info->count)
> @@ -549,6 +598,62 @@ void fpga_mgr_unlock(struct fpga_manager *mgr)
>   }
>   EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
>   
> +static int fpga_dmabuf_fd_get(struct file *file, char __user *argp)
> +{
> +	struct fpga_manager *mgr =  (struct fpga_manager *)(file->private_data);
> +	int buffd;
> +
> +	if (copy_from_user(&buffd, argp, sizeof(buffd)))
> +		return -EFAULT;
> +
> +	mgr->dmabuf = dma_buf_get(buffd);
> +	if (IS_ERR_OR_NULL(mgr->dmabuf))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static int fpga_device_open(struct inode *inode, struct file *file)
> +{
> +	struct miscdevice *miscdev = file->private_data;
> +	struct fpga_manager *mgr = container_of(miscdev,
> +						struct fpga_manager, miscdev);
> +
> +	file->private_data = mgr;
> +
> +	return 0;
> +}
> +
> +static int fpga_device_release(struct inode *inode, struct file *file)
> +{
> +	return 0;
> +}
> +
> +static long fpga_device_ioctl(struct file *file, unsigned int cmd,
> +			      unsigned long arg)
> +{
> +	char __user *argp = (char __user *)arg;
> +	int err;
> +
> +	switch (cmd) {
> +	case FPGA_IOCTL_LOAD_DMA_BUFF:
> +		err = fpga_dmabuf_fd_get(file, argp);
> +		break;
> +	default:
> +		err = -ENOTTY;
> +	}
> +
> +	return err;
> +}
> +
> +static const struct file_operations fpga_fops = {
> +	.owner		= THIS_MODULE,
> +	.open		= fpga_device_open,
> +	.release	= fpga_device_release,
> +	.unlocked_ioctl	= fpga_device_ioctl,
> +	.compat_ioctl	= fpga_device_ioctl,
> +};
> +
>   /**
>    * fpga_mgr_create - create and initialize a FPGA manager struct
>    * @dev:	fpga manager device from pdev
> @@ -569,8 +674,7 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>   	int id, ret;
>   
>   	if (!mops || !mops->write_complete || !mops->state ||
> -	    !mops->write_init || (!mops->write && !mops->write_sg) ||
> -	    (mops->write && mops->write_sg)) {
> +	    !mops->write_init || (!mops->write && !mops->write_sg)) {
>   		dev_err(dev, "Attempt to register without fpga_manager_ops\n");
>   		return NULL;
>   	}
> @@ -601,10 +705,28 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
>   	mgr->dev.of_node = dev->of_node;
>   	mgr->dev.id = id;
>   
> +	/* Make device dma capable by inheriting from parent's */
> +	set_dma_ops(&mgr->dev, get_dma_ops(dev));
> +	ret = dma_coerce_mask_and_coherent(&mgr->dev, dma_get_mask(dev));
> +	if (ret) {
> +		dev_warn(dev,
> +			 "Failed to set DMA mask %llx.Trying to continue.%x\n",
> +			 dma_get_mask(dev), ret);
> +	}
> +
>   	ret = dev_set_name(&mgr->dev, "fpga%d", id);
>   	if (ret)
>   		goto error_device;
>   
> +	mgr->miscdev.minor = MISC_DYNAMIC_MINOR;
> +	mgr->miscdev.name = kobject_name(&mgr->dev.kobj);
> +	mgr->miscdev.fops = &fpga_fops;
> +	ret = misc_register(&mgr->miscdev);
> +	if (ret) {
> +		pr_err("fpga: failed to register misc device.\n");
> +		goto error_device;
> +	}
> +
>   	return mgr;
>   
>   error_device:
> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
> index 35fc2f3d4bd8..698e3e42ccba 100644
> --- a/drivers/fpga/of-fpga-region.c
> +++ b/drivers/fpga/of-fpga-region.c
> @@ -229,6 +229,9 @@ static struct fpga_image_info *of_fpga_region_parse_ov(
>   	if (of_property_read_bool(overlay, "encrypted-fpga-config"))
>   		info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM;
>   
> +	if (of_property_read_bool(overlay, "fpga-config-from-dmabuf"))
> +		info->flags |= FPGA_MGR_CONFIG_DMA_BUF;
> +
>   	if (!of_property_read_string(overlay, "firmware-name",
>   				     &firmware_name)) {
>   		info->firmware_name = devm_kstrdup(dev, firmware_name,
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 2bc3030a69e5..6208c22f7bed 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -9,6 +9,7 @@
>   #define _LINUX_FPGA_MGR_H
>   
>   #include <linux/mutex.h>
> +#include <linux/miscdevice.h>
>   #include <linux/platform_device.h>
>   
>   struct fpga_manager;
> @@ -73,7 +74,7 @@ enum fpga_mgr_states {
>   #define FPGA_MGR_ENCRYPTED_BITSTREAM	BIT(2)
>   #define FPGA_MGR_BITSTREAM_LSB_FIRST	BIT(3)
>   #define FPGA_MGR_COMPRESSED_BITSTREAM	BIT(4)
> -
> +#define FPGA_MGR_CONFIG_DMA_BUF		BIT(5)
>   /**
>    * struct fpga_image_info - information specific to a FPGA image
>    * @flags: boolean flags as defined above
> @@ -167,6 +168,8 @@ struct fpga_compat_id {
>   struct fpga_manager {
>   	const char *name;
>   	struct device dev;
> +	struct miscdevice miscdev;
> +	struct dma_buf *dmabuf;
>   	struct mutex ref_mutex;
>   	enum fpga_mgr_states state;
>   	struct fpga_compat_id *compat_id;
> @@ -204,4 +207,5 @@ struct fpga_manager *devm_fpga_mgr_create(struct device *dev, const char *name,
>   					  const struct fpga_manager_ops *mops,
>   					  void *priv);
>   
> +#define FPGA_IOCTL_LOAD_DMA_BUFF	_IOWR('R', 1, __u32)
>   #endif /*_LINUX_FPGA_MGR_H */
> 


From u.kleine-koenig at pengutronix.de  Tue Apr  6 07:43:33 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 6 Apr 2021 08:43:33 +0200
Subject: [PATCH v4 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
References: <20210330181755.204339-1-u.kleine-koenig@pengutronix.de>
 <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
Message-ID: <20210406064333.y6v5fejjfzjvwnep@pengutronix.de>

On Tue, Mar 30, 2021 at 08:17:54PM +0200, Uwe Kleine-K?nig wrote:
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/i2c/busses/i2c-imx.c | 11 ++---------
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index b80fdc1f0092..aa156ecc616d 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1405,16 +1405,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
>  	ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
>  
>  	/* Get I2C clock */
> -	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> +	i2c_imx->clk = devm_clk_get_enabled(&pdev->dev, NULL);
>  	if (IS_ERR(i2c_imx->clk))
>  		return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
> -				     "can't get I2C clock\n");
> -
> -	ret = clk_prepare_enable(i2c_imx->clk);
> -	if (ret) {
> -		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
> -		return ret;
> -	}
> +				     "can't get prepared I2C clock\n");
>  
>  	/* Init queue */
>  	init_waitqueue_head(&i2c_imx->queue);
> @@ -1517,7 +1511,6 @@ static int i2c_imx_remove(struct platform_device *pdev)
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq >= 0)
>  		free_irq(irq, i2c_imx);
> -	clk_disable_unprepare(i2c_imx->clk);
>  
>  	pm_runtime_put_noidle(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);

Note this patch is wrong again, the following hunk is missing:

@@ -1481,7 +1481,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
        pm_runtime_disable(&pdev->dev);
        pm_runtime_set_suspended(&pdev->dev);
        pm_runtime_dont_use_autosuspend(&pdev->dev);
-       clk_disable_unprepare(i2c_imx->clk);
        return ret;
 }

Will resend a fixed patch.

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/20210406/5eb76e67/attachment.sig>

From uwe at kleine-koenig.org  Tue Apr  6 07:46:18 2021
From: uwe at kleine-koenig.org (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  6 Apr 2021 08:46:18 +0200
Subject: [PATCH v4.1 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
References: <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
Message-ID: <20210406064618.24194-1-uwe@kleine-koenig.org>

From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/i2c/busses/i2c-imx.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b80fdc1f0092..d6594358cf83 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1405,16 +1405,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
 
 	/* Get I2C clock */
-	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
+	i2c_imx->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(i2c_imx->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
-				     "can't get I2C clock\n");
-
-	ret = clk_prepare_enable(i2c_imx->clk);
-	if (ret) {
-		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
-		return ret;
-	}
+				     "can't get prepared I2C clock\n");
 
 	/* Init queue */
 	init_waitqueue_head(&i2c_imx->queue);
@@ -1487,7 +1481,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-	clk_disable_unprepare(i2c_imx->clk);
 	return ret;
 }
 
@@ -1517,7 +1510,6 @@ static int i2c_imx_remove(struct platform_device *pdev)
 	irq = platform_get_irq(pdev, 0);
 	if (irq >= 0)
 		free_irq(irq, i2c_imx);
-	clk_disable_unprepare(i2c_imx->clk);
 
 	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-- 
2.30.2



From hayashi.kunihiko at socionext.com  Tue Apr  6 07:51:52 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Tue, 06 Apr 2021 15:51:52 +0900
Subject: [PATCH 1/2] ARM: dts: uniphier: Change phy-mode to RGMII-ID to
 enable delay pins for RTL8211E
In-Reply-To: <1615250236-11349-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1615250236-11349-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <20210406155152.FB36.4A936039@socionext.com>

Gentle Ping.
Are there any comments about these two patches?

Thank you,

On Tue, 9 Mar 2021 09:37:15 +0900
Kunihiko Hayashi <hayashi.kunihiko at socionext.com> wrote:

> After applying the commit bbc4d71d6354
> ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the configuration
> register for TXDLY and RXDLY is set correctly.
> 
> Although PXs2 boards have RTL8211E for gigabit network PHY, it turrned out
> that the phy-mode should be RGMII-ID mode. This changes 'phy-mode' property
> to 'rgmii-id' as default.
> 
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
> ---
>  arch/arm/boot/dts/uniphier-pxs2.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> index 4d9f69a..5ba831e 100644
> --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> @@ -583,7 +583,7 @@
>  			clocks = <&sys_clk 6>;
>  			reset-names = "ether";
>  			resets = <&sys_rst 6>;
> -			phy-mode = "rgmii";
> +			phy-mode = "rgmii-id";
>  			local-mac-address = [00 00 00 00 00 00];
>  			socionext,syscon-phy-mode = <&soc_glue 0>;
>  
> -- 
> 2.7.4

---
Best Regards,
Kunihiko Hayashi



From chenxiang66 at hisilicon.com  Tue Apr  6 07:56:53 2021
From: chenxiang66 at hisilicon.com (chenxiang (M))
Date: Tue, 6 Apr 2021 14:56:53 +0800
Subject: [PATCH] iommu: Add device name to iommu map/unmap trace events
In-Reply-To: <20210212105039.GG7302@8bytes.org>
References: <20210209123620.19993-1-saiprakash.ranjan@codeaurora.org>
 <20210212105039.GG7302@8bytes.org>
Message-ID: <626fbcb8-b84f-1522-4ec3-9c7c1f5f7a93@hisilicon.com>

Hi,


? 2021/2/12 18:50, Joerg Roedel ??:
> On Tue, Feb 09, 2021 at 06:06:20PM +0530, Sai Prakash Ranjan wrote:
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 5e7fe519430a..6064187d9bb6 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -87,6 +87,7 @@ struct iommu_domain {
>>   	void *handler_token;
>>   	struct iommu_domain_geometry geometry;
>>   	void *iova_cookie;
>> +	char dev_name[32];
>>   };
> No, definitly not. A domain is a device DMA address space which can be
> used by more than one device. Just look at IOMMU groups with more than
> one member device, in this case just one device name would be very
> misleading.

Is it possible to use group id to identify different domains?


>
> Regards,
>
> 	Joerg
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
> .
>




From o.rempel at pengutronix.de  Tue Apr  6 08:12:13 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Tue, 6 Apr 2021 09:12:13 +0200
Subject: [PATCH v4.1 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210406064618.24194-1-uwe@kleine-koenig.org>
References: <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
 <20210406064618.24194-1-uwe@kleine-koenig.org>
Message-ID: <20210406071213.dxwucpggq6m7hfxi@pengutronix.de>

On Tue, Apr 06, 2021 at 08:46:18AM +0200, Uwe Kleine-K?nig wrote:
> From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Enthusiastically Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>

I hope devm_clk_get_enabled() will go mainline, it reduces dramatically
code and makes my life a lot better ;)

> ---
>  drivers/i2c/busses/i2c-imx.c | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index b80fdc1f0092..d6594358cf83 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1405,16 +1405,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
>  	ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
>  
>  	/* Get I2C clock */
> -	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> +	i2c_imx->clk = devm_clk_get_enabled(&pdev->dev, NULL);
>  	if (IS_ERR(i2c_imx->clk))
>  		return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
> -				     "can't get I2C clock\n");
> -
> -	ret = clk_prepare_enable(i2c_imx->clk);
> -	if (ret) {
> -		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
> -		return ret;
> -	}
> +				     "can't get prepared I2C clock\n");
>  
>  	/* Init queue */
>  	init_waitqueue_head(&i2c_imx->queue);
> @@ -1487,7 +1481,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
>  	pm_runtime_disable(&pdev->dev);
>  	pm_runtime_set_suspended(&pdev->dev);
>  	pm_runtime_dont_use_autosuspend(&pdev->dev);
> -	clk_disable_unprepare(i2c_imx->clk);
>  	return ret;
>  }
>  
> @@ -1517,7 +1510,6 @@ static int i2c_imx_remove(struct platform_device *pdev)
>  	irq = platform_get_irq(pdev, 0);
>  	if (irq >= 0)
>  		free_irq(irq, i2c_imx);
> -	clk_disable_unprepare(i2c_imx->clk);
>  
>  	pm_runtime_put_noidle(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
> -- 
> 2.30.2
> 
> 
> 

-- 
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 arnd at kernel.org  Tue Apr  6 08:14:53 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 6 Apr 2021 09:14:53 +0200
Subject: [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini
 (M1, 2020) devicetree
In-Reply-To: <f9dea9a0-bc52-4e32-417d-ee93dd1c070c@marcan.st>
References: <20210304213902.83903-1-marcan@marcan.st>
 <20210304213902.83903-28-marcan@marcan.st>
 <a94dd533-6aa2-167f-78a5-4fbd2efe7d7e@somainline.org>
 <f9dea9a0-bc52-4e32-417d-ee93dd1c070c@marcan.st>
Message-ID: <CAK8P3a0mi0WGZpc_s75Uz0RvutEqq9Nxr32Czw0z1iV7KYxdMA@mail.gmail.com>

On Mon, Apr 5, 2021 at 7:50 AM Hector Martin <marcan at marcan.st> wrote:
> On 14/03/2021 05.22, Konrad Dybcio wrote:
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20210216073120.qmlaky43t6uelqc4 at kozik-lap/
>
> >> +/*
> >> + * Apple Mac mini (M1, 2020)
> >
> > Not sure if it's necessary, you already state it in model=""
>
> I find it helpful to have identifying info in the top comment, since
> it's easier to locate at a glance than visually searching for the model
> property. Since I also add identifiers that Apple uses to be able to
> cross reference things here, even if it's somewhat duplicative, I think
> it makes sense to keep all of it in the top comment.

Agreed

> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "t8103.dtsi"
> >> +
> >> +/ {
> >> +    compatible = "apple,j274", "apple,t8103", "apple,arm-platform";
> >> +    model = "Apple Mac mini (M1, 2020)";
> >> +
> >> +    aliases {
> >> +            serial0 = &serial0;
> >
> > Isn't this M1-common?
>
> It's common to all existing M1 devices, but in principle there is
> nothing that says that the stdout path has to be the first UART on any
> given device (there is more than one UART, we just aren't declaring the
> others yet in this series). This is a common pattern, see e.g.
> nvidia/tegra210-smaug.dts.

Also, I normally ask for the aliases, chosen and memory nodes to be part of
the .dts file since these are settings that may be set by the bootloader and
are not specific to the SoCs at all.

> >> +    compatible = "apple,t8103", "apple,arm-platform";
> >
> > Please remove this line, it's getting overwritten anyway.
>
> I think it's helpful to document the expected compatible subset to be
> inherited by board files. The Tegra example I linked above does this too.

I'm fine with it either way here, your reasoning makes sense, but I
personally don't ask for these to be added or removed.

> > Other than this, node order seems to be entirely random. Please sort them
> > by address (where applicable) and by name where not, so that this doesn't
> > become a huge mess as we go forward.
>
> Outside of the soc bus I think the order we have makes sense: CPUs
> first, timer (which is part of the CPU complex) next, then fixed clocks.
> There are only a few things that are going to go in here, so I think an
> ad-hoc order like this is okay.
>
> Inside the bus we only have two nodes so far, and they are indeed in the
> wrong order :-). I'll sort them by address. Almost everything else is
> going to go in here in the future, so that should keep things sane.

Sounds good. Ordering by address is a good default, in particular for the
SoC node, but other orders can make sense, too. We used to have some
SoCs that sorted everything alphabetically, but that is less common now.

The main reason for having a fixed sort order is to help with merge conflicts
if we ever get nodes added through different git trees. If both sides add the
same node in the same place, that lets git cleanly resolve the merge, while
adding the same node in different places duplicates it, and adding different
versions in the same place should cause a merge conflict.

        Arnd


From erwan.leray at foss.st.com  Tue Apr  6 08:21:21 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 6 Apr 2021 09:21:21 +0200
Subject: [PATCH 1/2] dt-bindings: serial: stm32: add fifo threshold
 configuration
In-Reply-To: <20210406072122.27384-1-erwan.leray@foss.st.com>
References: <20210406072122.27384-1-erwan.leray@foss.st.com>
Message-ID: <20210406072122.27384-2-erwan.leray@foss.st.com>

Add two optional DT properties, to configure RX and TX fifo threshold:
- st,rx-fifo-threshold-bytes
- st,tx-fifo-threshold-bytes

This patch depends on patch ("dt-bindings: serial: Add rx-tx-swap to stm32-usart").

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>

diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index c69f8464cdf3..e163449bf39e 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -65,6 +65,22 @@ properties:
   linux,rs485-enabled-at-boot-time: true
   rs485-rx-during-tx: true
 
+  st,rx-fifo-threshold-bytes:
+    description:
+      RX FIFO threshold configuration in bytes.
+      If value is set to 1, RX FIFO threshold is disabled.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [1, 2, 4, 8, 12, 14, 16]
+    default: 8
+
+  st,tx-fifo-threshold-bytes:
+    description:
+      TX FIFO threshold configuration in bytes.
+      If value is set to 1, TX FIFO threshold is disabled.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [1, 2, 4, 8, 12, 14, 16]
+    default: 8
+
 allOf:
   - $ref: rs485.yaml#
   - $ref: serial.yaml#
@@ -82,6 +98,17 @@ allOf:
     then:
       properties:
         rx-tx-swap: false
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - st,stm32-uart
+              - st,stm32f7-uart
+    then:
+      properties:
+        st,rx-fifo-threshold-bytes: false
+        st,tx-fifo-threshold-bytes: false
 
 required:
   - compatible
@@ -96,13 +123,15 @@ examples:
   - |
     #include <dt-bindings/clock/stm32mp1-clks.h>
     usart1: serial at 40011000 {
-      compatible = "st,stm32-uart";
+      compatible = "st,stm32h7-uart";
       reg = <0x40011000 0x400>;
       interrupts = <37>;
       clocks = <&rcc 0 164>;
       dmas = <&dma2 2 4 0x414 0x0>,
              <&dma2 7 4 0x414 0x0>;
       dma-names = "rx", "tx";
+      st,rx-fifo-threshold-bytes = <4>;
+      st,tx-fifo-threshold-bytes = <4>;
       rs485-rts-active-low;
     };
 
-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr  6 08:21:20 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 6 Apr 2021 09:21:20 +0200
Subject: [PATCH 0/2] stm32 usart add fifo threshold configuration
Message-ID: <20210406072122.27384-1-erwan.leray@foss.st.com>

This series adds the support for two optional DT properties, to configure
RX and TX FIFO thresholds:
 - st,rx-fifo-threshold-bytes
 - st,tx-fifo-threshold-bytes
This replaces hard-coded 8 bytes threshold. No functional change expected
if unspecified (keep 8 as default).

Erwan Le Ray (1):
  dt-bindings: serial: stm32: add fifo threshold configuration

Fabrice Gasnier (1):
  serial: stm32: add fifo threshold configuration

 .../bindings/serial/st,stm32-uart.yaml        | 31 ++++++++++-
 drivers/tty/serial/stm32-usart.c              | 53 ++++++++++++++++---
 drivers/tty/serial/stm32-usart.h              |  8 +--
 3 files changed, 79 insertions(+), 13 deletions(-)

-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr  6 08:21:22 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 6 Apr 2021 09:21:22 +0200
Subject: [PATCH 2/2] serial: stm32: add fifo threshold configuration
In-Reply-To: <20210406072122.27384-1-erwan.leray@foss.st.com>
References: <20210406072122.27384-1-erwan.leray@foss.st.com>
Message-ID: <20210406072122.27384-3-erwan.leray@foss.st.com>

From: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Add the support for two optional DT properties, to configure RX and TX
FIFO thresholds::
- st,rx-fifo-threshold-bytes
- st,tx-fifo-threshold-bytes
This replaces hard-coded 8 bytes threshold. Keep 8 as the default value if
not specified, for backward compatibility.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray at st.com>

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 4d277804c63e..1be5b69ee567 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -312,7 +312,7 @@ static void stm32_usart_tx_interrupt_enable(struct uart_port *port)
 	 * Enables TX FIFO threashold irq when FIFO is enabled,
 	 * or TX empty irq when FIFO is disabled
 	 */
-	if (stm32_port->fifoen)
+	if (stm32_port->fifoen && stm32_port->txftcfg >= 0)
 		stm32_usart_set_bits(port, ofs->cr3, USART_CR3_TXFTIE);
 	else
 		stm32_usart_set_bits(port, ofs->cr1, USART_CR1_TXEIE);
@@ -323,7 +323,7 @@ static void stm32_usart_tx_interrupt_disable(struct uart_port *port)
 	struct stm32_port *stm32_port = to_stm32_port(port);
 	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
 
-	if (stm32_port->fifoen)
+	if (stm32_port->fifoen && stm32_port->txftcfg >= 0)
 		stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_TXFTIE);
 	else
 		stm32_usart_clr_bits(port, ofs->cr1, USART_CR1_TXEIE);
@@ -801,9 +801,10 @@ static void stm32_usart_set_termios(struct uart_port *port,
 	cr3 = readl_relaxed(port->membase + ofs->cr3);
 	cr3 &= USART_CR3_TXFTIE | USART_CR3_RXFTIE;
 	if (stm32_port->fifoen) {
-		cr3 &= ~(USART_CR3_TXFTCFG_MASK | USART_CR3_RXFTCFG_MASK);
-		cr3 |= USART_CR3_TXFTCFG_HALF << USART_CR3_TXFTCFG_SHIFT;
-		cr3 |= USART_CR3_RXFTCFG_HALF << USART_CR3_RXFTCFG_SHIFT;
+		if (stm32_port->txftcfg >= 0)
+			cr3 |= stm32_port->txftcfg << USART_CR3_TXFTCFG_SHIFT;
+		if (stm32_port->rxftcfg >= 0)
+			cr3 |= stm32_port->rxftcfg << USART_CR3_RXFTCFG_SHIFT;
 	}
 
 	if (cflag & CSTOPB)
@@ -833,7 +834,8 @@ static void stm32_usart_set_termios(struct uart_port *port,
 			, bits);
 
 	if (ofs->rtor != UNDEF_REG && (stm32_port->rx_ch ||
-				       stm32_port->fifoen)) {
+				       (stm32_port->fifoen &&
+					stm32_port->rxftcfg >= 0))) {
 		if (cflag & CSTOPB)
 			bits = bits + 3; /* 1 start bit + 2 stop bits */
 		else
@@ -1021,6 +1023,39 @@ static const struct uart_ops stm32_uart_ops = {
 	.verify_port	= stm32_usart_verify_port,
 };
 
+/*
+ * STM32H7 RX & TX FIFO threshold configuration (CR3 RXFTCFG / TXFTCFG)
+ * Note: 1 isn't a valid value in RXFTCFG / TXFTCFG. In this case,
+ * RXNEIE / TXEIE can be used instead of threshold irqs: RXFTIE / TXFTIE.
+ * So, RXFTCFG / TXFTCFG bitfields values are encoded as array index + 1.
+ */
+static const u32 stm32h7_usart_fifo_thresh_cfg[] = { 1, 2, 4, 8, 12, 14, 16 };
+
+static void stm32_usart_get_ftcfg(struct platform_device *pdev, const char *p,
+				  int *ftcfg)
+{
+	u32 bytes, i;
+
+	/* DT option to get RX & TX FIFO threshold (default to 8 bytes) */
+	if (of_property_read_u32(pdev->dev.of_node, p, &bytes))
+		bytes = 8;
+
+	for (i = 0; i < ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg); i++)
+		if (stm32h7_usart_fifo_thresh_cfg[i] >= bytes)
+			break;
+	if (i >= ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg))
+		i = ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg) - 1;
+
+	dev_dbg(&pdev->dev, "%s set to %d bytes\n", p,
+		stm32h7_usart_fifo_thresh_cfg[i]);
+
+	/* Provide FIFO threshold ftcfg (1 is invalid: threshold irq unused) */
+	if (i)
+		*ftcfg = i - 1;
+	else
+		*ftcfg = -EINVAL;
+}
+
 static void stm32_usart_deinit_port(struct stm32_port *stm32port)
 {
 	clk_disable_unprepare(stm32port->clk);
@@ -1057,6 +1092,12 @@ static int stm32_usart_init_port(struct stm32_port *stm32port,
 		of_property_read_bool(pdev->dev.of_node, "rx-tx-swap");
 
 	stm32port->fifoen = stm32port->info->cfg.has_fifo;
+	if (stm32port->fifoen) {
+		stm32_usart_get_ftcfg(pdev, "st,rx-fifo-threshold-bytes",
+				      &stm32port->rxftcfg);
+		stm32_usart_get_ftcfg(pdev, "st,tx-fifo-threshold-bytes",
+				      &stm32port->txftcfg);
+	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	port->membase = devm_ioremap_resource(&pdev->dev, res);
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 77d1ac082e89..07ac291328cd 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -216,12 +216,6 @@ struct stm32_usart_info stm32h7_info = {
 #define USART_CR3_TXFTCFG_MASK	GENMASK(31, 29)	/* H7 */
 #define USART_CR3_TXFTCFG_SHIFT	29		/* H7 */
 
-/* TX FIFO threashold set to half of its depth */
-#define USART_CR3_TXFTCFG_HALF	0x2
-
-/* RX FIFO threashold set to half of its depth */
-#define USART_CR3_RXFTCFG_HALF	0x2
-
 /* USART_GTPR */
 #define USART_GTPR_PSC_MASK	GENMASK(7, 0)
 #define USART_GTPR_GT_MASK	GENMASK(15, 8)
@@ -273,6 +267,8 @@ struct stm32_port {
 	bool hw_flow_control;
 	bool swap;		 /* swap RX & TX pins */
 	bool fifoen;
+	int rxftcfg;		/* RX FIFO threshold CFG      */
+	int txftcfg;		/* TX FIFO threshold CFG      */
 	bool wakeup_src;
 	int rdr_mask;		/* receive data register mask */
 	struct mctrl_gpios *gpios; /* modem control gpios */
-- 
2.17.1



From u.kleine-koenig at pengutronix.de  Tue Apr  6 08:30:36 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  6 Apr 2021 09:30:36 +0200
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
Message-ID: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>

Given that lowlevel drivers usually cannot implement exactly what a
consumer requests with pwm_apply_state() there is some rounding involved.

pwm_get_state() traditionally returned the setting that was requested most
recently by the consumer (opposed to what was actually implemented in
hardware in reply to the last request). To make this semantic obvious
rename the function.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 Documentation/driver-api/pwm.rst           |  6 +++-
 drivers/clk/clk-pwm.c                      |  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c |  4 +--
 drivers/input/misc/da7280.c                |  2 +-
 drivers/input/misc/pwm-beeper.c            |  2 +-
 drivers/input/misc/pwm-vibra.c             |  4 +--
 drivers/pwm/core.c                         |  4 +--
 drivers/pwm/pwm-atmel-hlcdc.c              |  2 +-
 drivers/pwm/pwm-atmel.c                    |  2 +-
 drivers/pwm/pwm-imx27.c                    |  2 +-
 drivers/pwm/pwm-rockchip.c                 |  2 +-
 drivers/pwm/pwm-stm32-lp.c                 |  4 +--
 drivers/pwm/pwm-sun4i.c                    |  2 +-
 drivers/pwm/sysfs.c                        | 18 ++++++------
 drivers/regulator/pwm-regulator.c          |  4 +--
 drivers/video/backlight/pwm_bl.c           | 10 +++----
 include/linux/pwm.h                        | 34 ++++++++++++++--------
 17 files changed, 59 insertions(+), 45 deletions(-)

diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst
index ab62f1bb0366..381f3c46cdac 100644
--- a/Documentation/driver-api/pwm.rst
+++ b/Documentation/driver-api/pwm.rst
@@ -55,7 +55,11 @@ 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().
 
-The PWM user API also allows one to query the PWM state with pwm_get_state().
+The PWM user API also allows one to query the last applied PWM state with
+pwm_get_last_applied_state(). Note this is different to what the driver has
+actually implemented if the request cannot be implemented exactly with the
+hardware in use. There is currently no way for consumers to get the actually
+implemented settings.
 
 In addition to the PWM state, the PWM API also exposes PWM arguments, which
 are the reference PWM config one should use on this PWM.
diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index da2c8eddfd9f..7cfaff32980b 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -49,7 +49,7 @@ static int clk_pwm_get_duty_cycle(struct clk_hw *hw, struct clk_duty *duty)
 	struct clk_pwm *clk_pwm = to_clk_pwm(hw);
 	struct pwm_state state;
 
-	pwm_get_state(clk_pwm->pwm, &state);
+	pwm_get_last_applied_state(clk_pwm->pwm, &state);
 
 	duty->num = state.duty_cycle;
 	duty->den = state.period;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 5fdf52643150..3aebf9be6b6a 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -627,7 +627,7 @@ static u32 ext_pwm_get_backlight(struct intel_connector *connector, enum pipe un
 	struct intel_panel *panel = &connector->panel;
 	struct pwm_state state;
 
-	pwm_get_state(panel->backlight.pwm, &state);
+	pwm_get_last_applied_state(panel->backlight.pwm, &state);
 	return pwm_get_relative_duty_cycle(&state, 100);
 }
 
@@ -1915,7 +1915,7 @@ static int ext_pwm_setup_backlight(struct intel_connector *connector,
 
 	if (pwm_is_enabled(panel->backlight.pwm)) {
 		/* PWM is already enabled, use existing settings */
-		pwm_get_state(panel->backlight.pwm, &panel->backlight.pwm_state);
+		pwm_get_last_applied_state(panel->backlight.pwm, &panel->backlight.pwm_state);
 
 		level = pwm_get_relative_duty_cycle(&panel->backlight.pwm_state,
 						    100);
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index b08610d6e575..409670be1d2b 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -333,7 +333,7 @@ static int da7280_haptic_set_pwm(struct da7280_haptic *haptics, bool enabled)
 		return -EINVAL;
 	}
 
-	pwm_get_state(haptics->pwm_dev, &state);
+	pwm_get_last_applied_state(haptics->pwm_dev, &state);
 	state.enabled = enabled;
 	if (enabled) {
 		period_mag_multi = (u64)state.period * haptics->gain;
diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
index d6b12477748a..4c5f09201ecf 100644
--- a/drivers/input/misc/pwm-beeper.c
+++ b/drivers/input/misc/pwm-beeper.c
@@ -33,7 +33,7 @@ static int pwm_beeper_on(struct pwm_beeper *beeper, unsigned long period)
 	struct pwm_state state;
 	int error;
 
-	pwm_get_state(beeper->pwm, &state);
+	pwm_get_last_applied_state(beeper->pwm, &state);
 
 	state.enabled = true;
 	state.period = period;
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index 81e777a04b88..d4e286e50aee 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -48,7 +48,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 		vibrator->vcc_on = true;
 	}
 
-	pwm_get_state(vibrator->pwm, &state);
+	pwm_get_last_applied_state(vibrator->pwm, &state);
 	pwm_set_relative_duty_cycle(&state, vibrator->level, 0xffff);
 	state.enabled = true;
 
@@ -59,7 +59,7 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
 	}
 
 	if (vibrator->pwm_dir) {
-		pwm_get_state(vibrator->pwm_dir, &state);
+		pwm_get_last_applied_state(vibrator->pwm_dir, &state);
 		state.duty_cycle = vibrator->direction_duty_cycle;
 		state.enabled = true;
 
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a8eff4b3ee36..cc8a948098eb 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -697,7 +697,7 @@ int pwm_adjust_config(struct pwm_device *pwm)
 	struct pwm_args pargs;
 
 	pwm_get_args(pwm, &pargs);
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	/*
 	 * If the current period is zero it means that either the PWM driver
@@ -1274,7 +1274,7 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
 		struct pwm_device *pwm = &chip->pwms[i];
 		struct pwm_state state;
 
-		pwm_get_state(pwm, &state);
+		pwm_get_last_applied_state(pwm, &state);
 
 		seq_printf(s, " pwm-%-3d (%-20.20s):", i, pwm->label);
 
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index dcbc0489dfd4..cb5fae4056ec 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -198,7 +198,7 @@ static int atmel_hlcdc_pwm_resume(struct device *dev)
 	struct pwm_state state;
 	int ret;
 
-	pwm_get_state(&chip->chip.pwms[0], &state);
+	pwm_get_last_applied_state(&chip->chip.pwms[0], &state);
 
 	/* Re-enable the periph clock it was stopped during suspend. */
 	if (!state.enabled) {
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 5813339b597b..4eee895471a7 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -241,7 +241,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	u32 pres, val;
 	int ret;
 
-	pwm_get_state(pwm, &cstate);
+	pwm_get_last_applied_state(pwm, &cstate);
 
 	if (state->enabled) {
 		if (cstate.enabled &&
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 18055326a2f3..b9d54e209a5c 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -223,7 +223,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	int ret;
 	u32 cr;
 
-	pwm_get_state(pwm, &cstate);
+	pwm_get_last_applied_state(pwm, &cstate);
 
 	clkrate = clk_get_rate(imx->clk_per);
 	c = clkrate * state->period;
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 6ad7d0a50aed..16f99369f4c5 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -198,7 +198,7 @@ static int rockchip_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	if (ret)
 		return ret;
 
-	pwm_get_state(pwm, &curstate);
+	pwm_get_last_applied_state(pwm, &curstate);
 	enabled = curstate.enabled;
 
 	if (state->polarity != curstate.polarity && enabled &&
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 134c14621ee0..c9e10aa1a8ef 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -41,7 +41,7 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	bool reenable;
 	int ret;
 
-	pwm_get_state(pwm, &cstate);
+	pwm_get_last_applied_state(pwm, &cstate);
 	reenable = !cstate.enabled;
 
 	if (!state->enabled) {
@@ -235,7 +235,7 @@ static int __maybe_unused 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_last_applied_state(&priv->chip.pwms[0], &state);
 	if (state.enabled) {
 		dev_err(dev, "The consumer didn't stop us (%s)\n",
 			priv->chip.pwms[0].label);
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index ce5c4fc8da6f..b4ae8190c3e9 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -239,7 +239,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	unsigned long now;
 	bool bypass;
 
-	pwm_get_state(pwm, &cstate);
+	pwm_get_last_applied_state(pwm, &cstate);
 
 	if (!cstate.enabled) {
 		ret = clk_prepare_enable(sun4i_pwm->clk);
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 9903c3a7eced..341def50e2df 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -40,7 +40,7 @@ static ssize_t period_show(struct device *child,
 	const struct pwm_device *pwm = child_to_pwm_device(child);
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return sprintf(buf, "%llu\n", state.period);
 }
@@ -60,7 +60,7 @@ static ssize_t period_store(struct device *child,
 		return ret;
 
 	mutex_lock(&export->lock);
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	state.period = val;
 	ret = pwm_apply_state(pwm, &state);
 	mutex_unlock(&export->lock);
@@ -75,7 +75,7 @@ static ssize_t duty_cycle_show(struct device *child,
 	const struct pwm_device *pwm = child_to_pwm_device(child);
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return sprintf(buf, "%llu\n", state.duty_cycle);
 }
@@ -95,7 +95,7 @@ static ssize_t duty_cycle_store(struct device *child,
 		return ret;
 
 	mutex_lock(&export->lock);
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	state.duty_cycle = val;
 	ret = pwm_apply_state(pwm, &state);
 	mutex_unlock(&export->lock);
@@ -110,7 +110,7 @@ static ssize_t enable_show(struct device *child,
 	const struct pwm_device *pwm = child_to_pwm_device(child);
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return sprintf(buf, "%d\n", state.enabled);
 }
@@ -130,7 +130,7 @@ static ssize_t enable_store(struct device *child,
 
 	mutex_lock(&export->lock);
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	switch (val) {
 	case 0:
@@ -159,7 +159,7 @@ static ssize_t polarity_show(struct device *child,
 	const char *polarity = "unknown";
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	switch (state.polarity) {
 	case PWM_POLARITY_NORMAL:
@@ -192,7 +192,7 @@ static ssize_t polarity_store(struct device *child,
 		return -EINVAL;
 
 	mutex_lock(&export->lock);
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	state.polarity = polarity;
 	ret = pwm_apply_state(pwm, &state);
 	mutex_unlock(&export->lock);
@@ -392,7 +392,7 @@ static struct pwm_export *pwm_class_get_state(struct device *parent,
 	put_device(child);	/* for device_find_child() */
 
 	mutex_lock(&export->lock);
-	pwm_get_state(pwm, state);
+	pwm_get_last_applied_state(pwm, state);
 
 	return export;
 }
diff --git a/drivers/regulator/pwm-regulator.c b/drivers/regulator/pwm-regulator.c
index 7629476d94ae..e8ada29f340a 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -58,7 +58,7 @@ static void pwm_regulator_init_state(struct regulator_dev *rdev)
 	unsigned int dutycycle;
 	int i;
 
-	pwm_get_state(drvdata->pwm, &pwm_state);
+	pwm_get_last_applied_state(drvdata->pwm, &pwm_state);
 	dutycycle = pwm_get_relative_duty_cycle(&pwm_state, 100);
 
 	for (i = 0; i < rdev->desc->n_voltages; i++) {
@@ -155,7 +155,7 @@ static int pwm_regulator_get_voltage(struct regulator_dev *rdev)
 	unsigned int diff_duty;
 	unsigned int voltage;
 
-	pwm_get_state(drvdata->pwm, &pstate);
+	pwm_get_last_applied_state(drvdata->pwm, &pstate);
 
 	voltage = pwm_get_relative_duty_cycle(&pstate, duty_unit);
 
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index e48fded3e414..df950d9b3738 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -44,7 +44,7 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
 	struct pwm_state state;
 	int err;
 
-	pwm_get_state(pb->pwm, &state);
+	pwm_get_last_applied_state(pb->pwm, &state);
 	if (pb->enabled)
 		return;
 
@@ -68,7 +68,7 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
 {
 	struct pwm_state state;
 
-	pwm_get_state(pb->pwm, &state);
+	pwm_get_last_applied_state(pb->pwm, &state);
 	if (!pb->enabled)
 		return;
 
@@ -92,7 +92,7 @@ static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
 	struct pwm_state state;
 	u64 duty_cycle;
 
-	pwm_get_state(pb->pwm, &state);
+	pwm_get_last_applied_state(pb->pwm, &state);
 
 	if (pb->levels)
 		duty_cycle = pb->levels[brightness];
@@ -115,7 +115,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 		brightness = pb->notify(pb->dev, brightness);
 
 	if (brightness > 0) {
-		pwm_get_state(pb->pwm, &state);
+		pwm_get_last_applied_state(pb->pwm, &state);
 		state.duty_cycle = compute_duty_cycle(pb, brightness);
 		pwm_apply_state(pb->pwm, &state);
 		pwm_backlight_power_on(pb);
@@ -567,7 +567,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 		 */
 
 		/* Get the PWM period (in nanoseconds) */
-		pwm_get_state(pb->pwm, &state);
+		pwm_get_last_applied_state(pb->pwm, &state);
 
 		ret = pwm_backlight_brightness_default(&pdev->dev, data,
 						       state.period);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index e4d84d4db293..35782cd4075b 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -88,12 +88,18 @@ struct pwm_device {
 };
 
 /**
- * pwm_get_state() - retrieve the current PWM state
+ * pwm_get_last_applied_state() - retrieve the PWM state that was passed to
+ *                                pwm_apply_state() before
+ *
+ * If pwm_apply_state() wasn't called before the state returned might be what is
+ * actually implemented in the hardware (if supported by the driver) or a
+ * default setting.
+ *
  * @pwm: PWM device
  * @state: state to fill with the current PWM state
  */
-static inline void pwm_get_state(const struct pwm_device *pwm,
-				 struct pwm_state *state)
+static inline void pwm_get_last_applied_state(const struct pwm_device *pwm,
+					      struct pwm_state *state)
 {
 	*state = pwm->state;
 }
@@ -102,7 +108,7 @@ static inline bool pwm_is_enabled(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return state.enabled;
 }
@@ -117,7 +123,7 @@ static inline u64 pwm_get_period(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return state.period;
 }
@@ -132,7 +138,7 @@ static inline u64 pwm_get_duty_cycle(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return state.duty_cycle;
 }
@@ -141,7 +147,7 @@ static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
 {
 	struct pwm_state state;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 
 	return state.polarity;
 }
@@ -175,7 +181,7 @@ static inline void pwm_init_state(const struct pwm_device *pwm,
 	struct pwm_args args;
 
 	/* First get the current state. */
-	pwm_get_state(pwm, state);
+	pwm_get_last_applied_state(pwm, state);
 
 	/* Then fill it with the reference config */
 	pwm_get_args(pwm, &args);
@@ -195,8 +201,12 @@ static inline void pwm_init_state(const struct pwm_device *pwm,
  *
  * For example if you want to get the duty_cycle expressed in percent, call:
  *
- * pwm_get_state(pwm, &state);
+ * pwm_get_last_applied_state(pwm, &state);
  * duty = pwm_get_relative_duty_cycle(&state, 100);
+ *
+ * Note however that this example yields the relative duty cycle that was
+ * requested before which doesn't necessarily exactly matches what is actually
+ * provided by the hardware.
  */
 static inline unsigned int
 pwm_get_relative_duty_cycle(const struct pwm_state *state, unsigned int scale)
@@ -337,7 +347,7 @@ static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
 	if (duty_ns < 0 || period_ns < 0)
 		return -EINVAL;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	if (state.duty_cycle == duty_ns && state.period == period_ns)
 		return 0;
 
@@ -359,7 +369,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
 	if (!pwm)
 		return -EINVAL;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	if (state.enabled)
 		return 0;
 
@@ -378,7 +388,7 @@ static inline void pwm_disable(struct pwm_device *pwm)
 	if (!pwm)
 		return;
 
-	pwm_get_state(pwm, &state);
+	pwm_get_last_applied_state(pwm, &state);
 	if (!state.enabled)
 		return;
 
-- 
2.30.2



From fparent at baylibre.com  Tue Apr  6 08:34:19 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue, 6 Apr 2021 09:34:19 +0200
Subject: [PATCH 2/5] arm64: dts: mediatek: mt8167: add smi_common node
In-Reply-To: <202104060814.berYSn6V-lkp@intel.com>
References: <20210405200821.2203458-2-fparent@baylibre.com>
 <202104060814.berYSn6V-lkp@intel.com>
Message-ID: <CAOwMV_xn2pv1vVoqz5qb+jNsssCKwVtNGG=yEtcA324adau6Rg@mail.gmail.com>

Hi,

I forgot to mention it, but this series depends on
https://patchwork.kernel.org/project/linux-mediatek/patch/20210405172836.2038526-1-fparent at baylibre.com/

On Tue, Apr 6, 2021 at 2:25 AM kernel test robot <lkp at intel.com> wrote:
>
> Hi Fabien,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on arm/for-next keystone/next soc/for-next rockchip/for-next arm64/for-next/core shawnguo/for-next clk/clk-next v5.12-rc6 next-20210401]
> [cannot apply to xlnx/master]
> [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]
>
> url:    https://github.com/0day-ci/linux/commits/Fabien-Parent/arm64-dts-mediatek-mt8167-add-mmsys-node/20210406-041016
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: arm64-randconfig-r011-20210406 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 2760a808b9916a2839513b7fd7314a464f52481e)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # install arm64 cross compiling tool for clang build
>         # apt-get install binutils-aarch64-linux-gnu
>         # https://github.com/0day-ci/linux/commit/bbbf216a8432b5af475e4e709bf481475c1af58f
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Fabien-Parent/arm64-dts-mediatek-mt8167-add-mmsys-node/20210406-041016
>         git checkout bbbf216a8432b5af475e4e709bf481475c1af58f
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
>
> All errors (new ones prefixed by >>):
>
> >> Error: arch/arm64/boot/dts/mediatek/mt8167.dtsi:73.26-27 syntax error
>    FATAL ERROR: Unable to parse input tree
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From jean-philippe at linaro.org  Tue Apr  6 09:01:39 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Tue, 6 Apr 2021 10:01:39 +0200
Subject: [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
In-Reply-To: <20210401171501.GC9447@willie-the-truck>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401171501.GC9447@willie-the-truck>
Message-ID: <YGwVY3W4vk6kve3G@myrica>

On Thu, Apr 01, 2021 at 06:15:02PM +0100, Will Deacon wrote:
> On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote:
> > Add stall support to the SMMUv3 driver, along with a common I/O Page
> > Fault handler.
> > 
> > Since [v13] I added review and ack tags (Thanks!), and a lockdep_assert.
> > It would be good to have all of it in v5.13, since patch 10 introduces
> > the first user for the IOPF interface from patch 6.  But if that's not
> > possible, please pick patches 1-6 so the Vt-d driver can start using
> > them.
> 
> Patches 1-7 look good to me, but I'm not convinced about the utility of
> stalling faults so I'd prefer the later patches to come along with a
> real user.

As others said, it is possible to assign queues from the compression and
crypto accelerators on the Kunpeng920 to userspace, using the uacce char
device (upstream since last year, but waiting for implementations of the
SVA API in IOMMU drivers). I've been using that platform for testing my
code for the past year, with the UADK tool as well as an openssl plugin.

Securely assignig a queue to userspace requires full SVA support in
SMMUv3, which consists of PASID, page table sharing, and I/O page faults.
The first two were already merged, and the third one requires either Stall
or PRI. I'm not submitting PRI support at the moment because there is no
hardware, but the Hisilicon platform implements stall and will be able to
use it right away.

Thanks,
Jean


From linus.walleij at linaro.org  Tue Apr  6 09:15:51 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 6 Apr 2021 10:15:51 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
In-Reply-To: <YGtZeofmBv7hXK+a@Red>
References: <YGtZeofmBv7hXK+a@Red>
Message-ID: <CACRpkdZ_barDrLvD2UBKo+GA-F+g72uMQx8CfRK2YLRodpeyUA@mail.gmail.com>

On Mon, Apr 5, 2021 at 8:39 PM Corentin Labbe <clabbe.montjoie at gmail.com> wrote:

> I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.
> I successfully upgraded it with a recent Linux.

Pretty cool!

>         mdio0: ethernet-phy {
>                 compatible = "virtual,mdio-gpio";
>                 gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
>                         <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>                 phy0: ethernet-phy at 1 {
>                         reg = <1>;
>                         device_type = "ethernet-phy";
>                 };
>         };

This looks like the most typical way to attach an MDIO phy.

I always try to identify the exact component used on the board. Do you have
 a high res board photo?

Realtek RTL82111 is the most common configuration.

Compare to the D-Linux DNS-313 DTS:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/gemini-dlink-dns-313.dts

Try just copying the whole pinctrl-gmii section!


>                 syscon: syscon at 40000000 {
>                         pinctrl {
>                                 /*
>                                  * gpio0agrp cover line 0-4
>                                  * gpio0bgrp cover line 5
>                                  */
>                                 gpio0_default_pins: pinctrl-gpio0 {
>                                         mux {
>                                                 function = "gpio0";
>                                                 groups = "gpio0agrp",
>                                                 "gpio0bgrp";
>                                         };
>                                 };

Change groups to

groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";

So you mux in group h which is where the GPIO 21, 22 go out
to the MDIO on 3516 IIUC. The right mux out is pretty important,
if you have vendor source code, please share so I can check how
they set it up.

> BUT neither ethernet nor USB works.

For USB try this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=gemini-usb&id=cbaf6cdf770b90de5f10bfa5112c679f1dffe948

Pls report progress! I hope we can mainline this device.

Yours,
Linus Walleij


From maz at kernel.org  Tue Apr  6 09:22:29 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 06 Apr 2021 09:22:29 +0100
Subject: [GIT PULL] coresight: Add support for ETE and TRBE
In-Reply-To: <20210405191757.283122-1-mathieu.poirier@linaro.org>
References: <20210405191757.283122-1-mathieu.poirier@linaro.org>
Message-ID: <87o8erq0u2.wl-maz@kernel.org>

Hi Mathieu,

On Mon, 05 Apr 2021 20:17:57 +0100,
Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> 
> The following changes since commit a354a64d91eec3e0f8ef0eed575b480fd75b999c:
> 
>   KVM: arm64: Disable guest access to trace filter controls (2021-03-24 17:26:38 +0000)
> 
> are available in the Git repository at:
> 
>   git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE
> 
> for you to fetch changes up to 7885b4e43231048654c5a80c0a18844ce3185e64:
> 
>   dts: bindings: Document device tree bindings for Arm TRBE (2021-04-05 11:38:04 -0600)
> 
> ----------------------------------------------------------------
> Hi Marc,
> 
> As previously agreed, here are the changes to support CoreSight
> ETE and TRBE components submitted here[1].
> 
> I draw your attention to these:
> 
> [PATCH v6 05/20] kvm: arm64: Handle access to TRFCR_EL1
> [PATCH v6 06/20] kvm: arm64: Move SPE availability check to VCPU load
> [PATCH v6 07/20] arm64: kvm: Enable access to TRBE support for host
> 
> They are KVM specific and will need an SoB tag.

There seem to be a disconnect here, because it works the other way
around.

If I pull this, I obviously cannot add anything to the patches that
are merged (changing stuff would result in changing the commit IDs,
which is exactly the opposite of what we are trying to achieve).

This isn't a problem, as the act of pulling the branch means that I am
happy with that, and the git merge makes it traceable.

However, some of the patches (the KVM ones) do not carry your own SoB,
which is a problem (if you are picking stuff off the list, you need to
add your own SoB). So for the couple of KVM patches, please add my

	Acked-by: Marc Zyngier <maz at kernel.org>

together with your SoB, resend the PR and I'll gladly merge it.

And if you can make sure the subject lines are formatted as:

	"KVM: arm64: Super Duper feature enablement"

that'd be absolutely awesome (but that's just me being annoying...).

Thanks,

	M.

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


From yong.wu at mediatek.com  Tue Apr  6 09:41:22 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 6 Apr 2021 16:41:22 +0800
Subject: [SPAM][PATCH 4/5] arm64: dts: mediatek: mt8167: add iommu node
In-Reply-To: <20210405200821.2203458-4-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
 <20210405200821.2203458-4-fparent@baylibre.com>
Message-ID: <1617698482.26944.5.camel@mhfsdcap03>

On Mon, 2021-04-05 at 22:08 +0200, Fabien Parent wrote:
> Add node for the MT8167's IOMMU.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 9b352031c5f6..3ba03ca749b2 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -173,5 +173,14 @@ larb2: larb at 16010000 {
>  			clock-names = "apb", "smi";
>  			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
>  		};
> +
> +		iommu: m4u at 10203000 {
> +			cell-index = <0>;

Remove this line.

> +			compatible = "mediatek,mt8167-m4u";
> +			reg = <0 0x10203000 0 0x1000>;
> +			mediatek,larbs = <&larb0 &larb1 &larb2>;
> +			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
> +			#iommu-cells = <1>;
> +		};
>  	};
>  };


From yuehaibing at huawei.com  Tue Apr  6 09:50:43 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Tue, 6 Apr 2021 16:50:43 +0800
Subject: [PATCH -next] dmaengine: at_xdmac: Remove unused inline function
 at_xdmac_csize()
Message-ID: <20210406085043.32544-1-yuehaibing@huawei.com>

765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
left behind this, so can remove it.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/dma/at_xdmac.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index fe45ad5d06c4..64a52bf4d737 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -344,17 +344,6 @@ static inline int at_xdmac_chan_is_paused(struct at_xdmac_chan *atchan)
 	return test_bit(AT_XDMAC_CHAN_IS_PAUSED, &atchan->status);
 }
 
-static inline int at_xdmac_csize(u32 maxburst)
-{
-	int csize;
-
-	csize = ffs(maxburst) - 1;
-	if (csize > 4)
-		csize = -EINVAL;
-
-	return csize;
-};
-
 static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
 {
 	return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
-- 
2.17.1



From yong.wu at mediatek.com  Tue Apr  6 09:43:56 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 6 Apr 2021 16:43:56 +0800
Subject: [PATCH 3/5] arm64: dts: mediatek: mt8167: add larb nodes
In-Reply-To: <20210405200821.2203458-3-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
 <20210405200821.2203458-3-fparent@baylibre.com>
Message-ID: <1617698636.26944.8.camel@mhfsdcap03>

On Mon, 2021-04-05 at 22:08 +0200, Fabien Parent wrote:
> Add larb nodes for MT8167:
> * larb0 is used for display (dsi and hdmi)
> * larb1 is used for camera (csi)
> * larb2 is used for the video hardware decoder
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 33 ++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 4b951f81db9e..9b352031c5f6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -140,5 +140,38 @@ smi_common: smi at 14017000 {
>  			clock-names = "apb", "smi";
>  			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
>  		};
> +
> +		larb0: larb at 14016000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x14016000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			mediatek,larbid = <0>;

From [1], This should be: mediatek,larb-id.

Actually this property is unnecessary in this SoC since this larb-id in
the m4u node is consecutive.

[1]
https://elixir.bootlin.com/linux/v5.12-rc2/source/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml#L58

> +			clocks = <&mmsys CLK_MM_SMI_LARB0>,
> +				 <&mmsys CLK_MM_SMI_LARB0>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
> +		};
> +
> +		larb1: larb at 15001000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x15001000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			mediatek,larbid = <1>;
> +			clocks = <&imgsys CLK_IMG_LARB1_SMI>,
> +				 <&imgsys CLK_IMG_LARB1_SMI>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
> +		};
> +
> +		larb2: larb at 16010000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x16010000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			mediatek,larbid = <2>;
> +			clocks = <&vdecsys CLK_VDEC_CKEN>,
> +				 <&vdecsys CLK_VDEC_LARB1_CKEN>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
> +		};
>  	};
>  };


From lee.jones at linaro.org  Tue Apr  6 09:56:05 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 6 Apr 2021 09:56:05 +0100
Subject: [RESEND 00/25] Rid W=1 warnings from HID
In-Reply-To: <20210326143458.508959-1-lee.jones@linaro.org>
References: <20210326143458.508959-1-lee.jones@linaro.org>
Message-ID: <20210406085605.GS2916463@dell>

On Fri, 26 Mar 2021, Lee Jones wrote:

> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> Lee Jones (25):
>   HID: intel-ish-hid: Remove unused variable 'err'
>   HID: ishtp-hid-client: Move variable to where it's actually used
>   HID: intel-ish-hid: pci-ish: Remove unused variable 'ret'
>   HID: intel-ish: Supply some missing param descriptions
>   HID: intel-ish: Fix a naming disparity and a formatting error
>   HID: usbhid: Repair a formatting issue in a struct description
>   HID: intel-ish-hid: Fix a little doc-rot
>   HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses
>   HID: hid-alps: Correct struct misnaming
>   HID: intel-ish-hid: Fix potential copy/paste error
>   HID: hid-core: Fix incorrect function name in header
>   HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in
>     header
>   HID: ishtp-hid-client: Fix incorrect function name report_bad_packet()
>   HID: hid-kye: Fix incorrect function name for kye_tablet_enable()
>   HID: hid-picolcd_core: Remove unused variable 'ret'
>   HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote
>     abuses
>   HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs
>   HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses
>   HID: hid-uclogic-params: Ensure function names are present and correct
>     in kernel-doc headers
>   HID: hid-sensor-custom: Remove unused variable 'ret'
>   HID: wacom_sys: Demote kernel-doc abuse
>   HID: hid-sensor-hub: Remove unused struct member 'quirks'
>   HID: hid-sensor-hub: Move 'hsdev' description to correct struct
>     definition
>   HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues
>   HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning

These have been on the list for a couple of weeks now.

Is there anything I can do to help expedite their merge?

I'm concerned since -rc6 has just been released.

-- 
Lee Jones [???]
Senior Technical Lead - Developer Services
Linaro.org ? Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:43 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:43 +0800
Subject: [PATCHv4 0/6] PCI: layerscape: Add power management support
Message-ID: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

This patch series is to add PCIe power management support for NXP
Layerscape platforms.

Hou Zhiqiang (6):
  PCI: layerscape: Change to use the DWC common link-up check function
  dt-bindings: pci: layerscape-pci: Add a optional property big-endian
  arm64: dts: layerscape: Add big-endian property for PCIe nodes
  dt-bindings: pci: layerscape-pci: Update the description of SCFG
    property
  arm64: dts: ls1043a: Add SCFG phandle for PCIe nodes
  PCI: layerscape: Add power management support

 .../bindings/pci/layerscape-pci.txt           |   6 +-
 .../arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   1 +
 .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi |   6 +
 .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   3 +
 drivers/pci/controller/dwc/pci-layerscape.c   | 450 ++++++++++++++----
 drivers/pci/controller/dwc/pcie-designware.h  |   1 +
 6 files changed, 370 insertions(+), 97 deletions(-)

-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:44 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:44 +0800
Subject: [PATCHv4 1/6] PCI: layerscape: Change to use the DWC common link-up
 check function
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-2-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

The current Layerscape PCIe driver directly uses the physical layer
LTSSM code to check the link-up state, which treats the > L0 states
as link-up. This is not correct, since there is not explicit map
between link-up state and LTSSM. So this patch changes to use the
DWC common link-up check function.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
V4:
 - Rebased against the latest code base

 drivers/pci/controller/dwc/pci-layerscape.c | 140 ++------------------
 1 file changed, 10 insertions(+), 130 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 5b9c625df7b8..71911ca4c589 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -22,12 +22,6 @@
 
 #include "pcie-designware.h"
 
-/* PEX1/2 Misc Ports Status Register */
-#define SCFG_PEXMSCPORTSR(pex_idx)	(0x94 + (pex_idx) * 4)
-#define LTSSM_STATE_SHIFT	20
-#define LTSSM_STATE_MASK	0x3f
-#define LTSSM_PCIE_L0		0x11 /* L0 state */
-
 /* PEX Internal Configuration Registers */
 #define PCIE_STRFMR1		0x71c /* Symbol Timer & Filter Mask Register1 */
 #define PCIE_ABSERR		0x8d0 /* Bridge Slave Error Response Register */
@@ -36,19 +30,12 @@
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
-	u32 lut_offset;
-	u32 ltssm_shift;
-	u32 lut_dbg;
 	const struct dw_pcie_host_ops *ops;
-	const struct dw_pcie_ops *dw_pcie_ops;
 };
 
 struct ls_pcie {
 	struct dw_pcie *pci;
-	void __iomem *lut;
-	struct regmap *scfg;
 	const struct ls_pcie_drvdata *drvdata;
-	int index;
 };
 
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
@@ -83,38 +70,6 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
 	iowrite32(val, pci->dbi_base + PCIE_STRFMR1);
 }
 
-static int ls1021_pcie_link_up(struct dw_pcie *pci)
-{
-	u32 state;
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-
-	if (!pcie->scfg)
-		return 0;
-
-	regmap_read(pcie->scfg, SCFG_PEXMSCPORTSR(pcie->index), &state);
-	state = (state >> LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK;
-
-	if (state < LTSSM_PCIE_L0)
-		return 0;
-
-	return 1;
-}
-
-static int ls_pcie_link_up(struct dw_pcie *pci)
-{
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-	u32 state;
-
-	state = (ioread32(pcie->lut + pcie->drvdata->lut_dbg) >>
-		 pcie->drvdata->ltssm_shift) &
-		 LTSSM_STATE_MASK;
-
-	if (state < LTSSM_PCIE_L0)
-		return 0;
-
-	return 1;
-}
-
 /* Forward error response of outbound non-posted requests */
 static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 {
@@ -139,96 +94,24 @@ static int ls_pcie_host_init(struct pcie_port *pp)
 	return 0;
 }
 
-static int ls1021_pcie_host_init(struct pcie_port *pp)
-{
-	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-	struct device *dev = pci->dev;
-	u32 index[2];
-	int ret;
-
-	pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
-						     "fsl,pcie-scfg");
-	if (IS_ERR(pcie->scfg)) {
-		ret = PTR_ERR(pcie->scfg);
-		dev_err(dev, "No syscfg phandle specified\n");
-		pcie->scfg = NULL;
-		return ret;
-	}
-
-	if (of_property_read_u32_array(dev->of_node,
-				       "fsl,pcie-scfg", index, 2)) {
-		pcie->scfg = NULL;
-		return -EINVAL;
-	}
-	pcie->index = index[1];
-
-	return ls_pcie_host_init(pp);
-}
-
-static const struct dw_pcie_host_ops ls1021_pcie_host_ops = {
-	.host_init = ls1021_pcie_host_init,
-};
-
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 };
 
-static const struct dw_pcie_ops dw_ls1021_pcie_ops = {
-	.link_up = ls1021_pcie_link_up,
-};
-
-static const struct dw_pcie_ops dw_ls_pcie_ops = {
-	.link_up = ls_pcie_link_up,
-};
-
-static const struct ls_pcie_drvdata ls1021_drvdata = {
-	.ops = &ls1021_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls1021_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls1043_drvdata = {
-	.lut_offset = 0x10000,
-	.ltssm_shift = 24,
-	.lut_dbg = 0x7fc,
+static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls1046_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 24,
-	.lut_dbg = 0x407fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls2080_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 0,
-	.lut_dbg = 0x7fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls2088_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 0,
-	.lut_dbg = 0x407fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
-	{ .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
-	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
-	{ .compatible = "fsl,ls1028a-pcie", .data = &ls2088_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
-	{ .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
-	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
-	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
-	{ .compatible = "fsl,ls2088a-pcie", .data = &ls2088_drvdata },
-	{ .compatible = "fsl,ls1088a-pcie", .data = &ls2088_drvdata },
+	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1021a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1043a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2088a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1088a-pcie", .data = &layerscape_drvdata },
 	{ },
 };
 
@@ -250,7 +133,6 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	pcie->drvdata = of_device_get_match_data(dev);
 
 	pci->dev = dev;
-	pci->ops = pcie->drvdata->dw_pcie_ops;
 	pci->pp.ops = pcie->drvdata->ops;
 
 	pcie->pci = pci;
@@ -260,8 +142,6 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	if (IS_ERR(pci->dbi_base))
 		return PTR_ERR(pci->dbi_base);
 
-	pcie->lut = pci->dbi_base + pcie->drvdata->lut_offset;
-
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:45 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:45 +0800
Subject: [PATCHv4 2/6] dt-bindings: pci: layerscape-pci: Add a optional
 property big-endian
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-3-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

This property is to indicate the endianness when accessing the
PEX_LUT and PF register block, so if these registers are
implemented in big-endian, specify this property.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
V4:
 - Rebased against the latest code base

 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 6d898dd4a8e2..d633c1fabdb4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -40,6 +40,10 @@ Required properties:
   of the data transferred from/to the IP block. This can avoid the software
   cache flush/invalid actions, and improve the performance significantly.
 
+Optional properties:
+- big-endian: If the PEX_LUT and PF register block is in big-endian, specify
+  this property.
+
 Example:
 
 	pcie at 3400000 {
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:46 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:46 +0800
Subject: [PATCHv4 3/6] arm64: dts: layerscape: Add big-endian property for
 PCIe nodes
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-4-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Add the big-endian property for LS1012A, LS1043A and LS1046A
PCIe devicetree nodes.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V4:
 - Rebased against the latest code base

 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 9058cfa4980f..ac23e938fd1d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -542,6 +542,7 @@
 					<0000 0 0 2 &gic 0 111 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic 0 112 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 28c51e521cb2..46826752a691 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -890,6 +890,7 @@
 					<0000 0 0 2 &gic 0 111 0x4>,
 					<0000 0 0 3 &gic 0 112 0x4>,
 					<0000 0 0 4 &gic 0 113 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -916,6 +917,7 @@
 					<0000 0 0 2 &gic 0 121 0x4>,
 					<0000 0 0 3 &gic 0 122 0x4>,
 					<0000 0 0 4 &gic 0 123 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -942,6 +944,7 @@
 					<0000 0 0 2 &gic 0 155 0x4>,
 					<0000 0 0 3 &gic 0 156 0x4>,
 					<0000 0 0 4 &gic 0 157 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 39458305e333..f21ee7825d40 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -794,6 +794,7 @@
 					<0000 0 0 2 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -830,6 +831,7 @@
 					<0000 0 0 2 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -866,6 +868,7 @@
 					<0000 0 0 2 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:47 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:47 +0800
Subject: [PATCHv4 4/6] dt-bindings: pci: layerscape-pci: Update the
 description of SCFG property
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-5-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Update the description of the second entry of 'fsl,pcie-scfg' property,
as the LS1043A PCIe controller also has some control registers in SCFG
block, while it has 3 controllers.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
V4:
 - Rebased against the latest code base

 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index d633c1fabdb4..8231f6729385 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -34,7 +34,7 @@ Required properties:
   "intr": The interrupt that is asserted for controller interrupts
 - fsl,pcie-scfg: Must include two entries.
   The first entry must be a link to the SCFG device node
-  The second entry must be '0' or '1' based on physical PCIe controller index.
+  The second entry is the physical PCIe controller index starting from '0'.
   This is used to get SCFG PEXN registers
 - dma-coherent: Indicates that the hardware IP block can ensure the coherency
   of the data transferred from/to the IP block. This can avoid the software
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:48 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:48 +0800
Subject: [PATCHv4 5/6] arm64: dts: ls1043a: Add SCFG phandle for PCIe nodes
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-6-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

The LS1043A PCIe controller has some control registers
in SCFG block, so add the SCFG phandle for each PCIe
controller DT node.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V4:
 - Rebased against the latest code base

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 46826752a691..704e9e249729 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -875,6 +875,7 @@
 			interrupts = <0 118 0x4>, /* controller interrupt */
 				     <0 117 0x4>; /* PME interrupt */
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 0>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
@@ -902,6 +903,7 @@
 			interrupts = <0 128 0x4>,
 				     <0 127 0x4>;
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 1>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
@@ -929,6 +931,7 @@
 			interrupts = <0 162 0x4>,
 				     <0 161 0x4>;
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 2>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Tue Apr  6 10:04:49 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Tue,  6 Apr 2021 17:04:49 +0800
Subject: [PATCHv4 6/6] PCI: layerscape: Add power management support
In-Reply-To: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
References: <20210406090449.36352-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210406090449.36352-7-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Add PME_Turn_Off/PME_TO_Ack handshake sequence, and finally
put the PCIe controller into D3 state after the L2/L3 ready
state transition process completion.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V4:
 - Rebased against the latest code base

 drivers/pci/controller/dwc/pci-layerscape.c  | 382 ++++++++++++++++++-
 drivers/pci/controller/dwc/pcie-designware.h |   1 +
 2 files changed, 381 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 71911ca4c589..868e18b12e4a 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -3,13 +3,16 @@
  * PCIe host controller driver for Freescale Layerscape SoCs
  *
  * Copyright (C) 2014 Freescale Semiconductor.
+ * Copyright 2020 NXP
  *
  * Author: Minghuan Lian <Minghuan.Lian at freescale.com>
  */
 
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
 #include <linux/init.h>
+#include <linux/iopoll.h>
 #include <linux/of_pci.h>
 #include <linux/of_platform.h>
 #include <linux/of_irq.h>
@@ -27,17 +30,60 @@
 #define PCIE_ABSERR		0x8d0 /* Bridge Slave Error Response Register */
 #define PCIE_ABSERR_SETTING	0x9401 /* Forward error of non-posted request */
 
+/* PF Message Command Register */
+#define LS_PCIE_PF_MCR		0x2c
+#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)
+
+/* 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
 
+#define LS_PCIE_IS_L2(v)	\
+	(((v) & PORT_LOGIC_LTSSM_STATE_MASK) == PORT_LOGIC_LTSSM_STATE_L2)
+
+struct ls_pcie;
+
+struct ls_pcie_host_pm_ops {
+	int (*pm_init)(struct ls_pcie *pcie);
+	void (*send_turn_off_message)(struct ls_pcie *pcie);
+	void (*exit_from_l2)(struct ls_pcie *pcie);
+};
+
 struct ls_pcie_drvdata {
+	const u32 pf_off;
+	const u32 lut_off;
 	const struct dw_pcie_host_ops *ops;
+	const struct ls_pcie_host_pm_ops *pm_ops;
 };
 
 struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
+	void __iomem *pf_base;
+	void __iomem *lut_base;
+	bool big_endian;
+	bool ep_presence;
+	bool pm_support;
+	struct regmap *scfg;
+	int index;
 };
 
+#define ls_pcie_lut_readl_addr(addr)	ls_pcie_lut_readl(pcie, addr)
+#define ls_pcie_pf_readl_addr(addr)	ls_pcie_pf_readl(pcie, addr)
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
 
 static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
@@ -78,6 +124,210 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 	iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
 }
 
+static u32 ls_pcie_lut_readl(struct ls_pcie *pcie, u32 off)
+{
+	if (pcie->big_endian)
+		return ioread32be(pcie->lut_base + off);
+
+	return ioread32(pcie->lut_base + off);
+}
+
+static void ls_pcie_lut_writel(struct ls_pcie *pcie, u32 off, u32 val)
+{
+	if (pcie->big_endian)
+		return iowrite32be(val, pcie->lut_base + off);
+
+	return iowrite32(val, pcie->lut_base + off);
+
+}
+
+static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
+{
+	if (pcie->big_endian)
+		return ioread32be(pcie->pf_base + off);
+
+	return ioread32(pcie->pf_base + off);
+}
+
+static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
+{
+	if (pcie->big_endian)
+		return iowrite32be(val, pcie->pf_base + off);
+
+	return iowrite32(val, pcie->pf_base + off);
+
+}
+
+static void ls_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+	int ret;
+
+	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val |= PF_MCR_PTOMR;
+	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+
+	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+				 val, !(val & PF_MCR_PTOMR), 100, 10000);
+	if (ret)
+		dev_info(pcie->pci->dev, "poll turn off message timeout\n");
+}
+
+static void ls1021a_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	if (!pcie->scfg) {
+		dev_dbg(pcie->pci->dev, "SYSCFG is NULL\n");
+		return;
+	}
+
+	/* Send Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
+	val |= PMXMTTURNOFF;
+	regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
+
+	mdelay(10);
+
+	/* Clear Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
+	val &= ~PMXMTTURNOFF;
+	regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
+}
+
+static void ls1043a_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	if (!pcie->scfg) {
+		dev_dbg(pcie->pci->dev, "SYSCFG is NULL\n");
+		return;
+	}
+
+	/* Send Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMECR, &val);
+	val |= PEXPME(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXPMECR, val);
+
+	mdelay(10);
+
+	/* Clear Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMECR, &val);
+	val &= ~PEXPME(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXPMECR, val);
+}
+
+static void ls_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+	int ret;
+
+	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val |= PF_MCR_EXL2S;
+	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+
+	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+				 val, !(val & PF_MCR_EXL2S), 100, 10000);
+	if (ret)
+		dev_info(pcie->pci->dev, "poll exit L2 state timeout\n");
+}
+
+static void ls_pcie_retrain_link(struct ls_pcie *pcie)
+{
+	struct dw_pcie *pci = pcie->pci;
+	u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+	u32 val;
+
+	val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL);
+	val |= PCI_EXP_LNKCTL_RL;
+	dw_pcie_writew_dbi(pci, offset + PCI_EXP_LNKCTL, val);
+}
+
+static void ls1021a_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
+	val |= PEXSR(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
+
+	regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
+	val &= ~PEXSR(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
+
+	mdelay(1);
+
+	ls_pcie_retrain_link(pcie);
+}
+static void ls1043a_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_WE;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_SR;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_SR;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_WE;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	mdelay(1);
+
+	ls_pcie_retrain_link(pcie);
+}
+
+static int ls1021a_pcie_pm_init(struct ls_pcie *pcie)
+{
+	struct device *dev = pcie->pci->dev;
+	u32 index[2];
+	int ret;
+
+	pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
+						     "fsl,pcie-scfg");
+	if (IS_ERR(pcie->scfg)) {
+		ret = PTR_ERR(pcie->scfg);
+		dev_err(dev, "No syscfg phandle specified\n");
+		pcie->scfg = NULL;
+		return ret;
+	}
+
+	ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg",
+					 index, 2);
+	if (ret) {
+		pcie->scfg = NULL;
+		return ret;
+	}
+
+	pcie->index = index[1];
+
+	return 0;
+}
+
+static int ls_pcie_pm_init(struct ls_pcie *pcie)
+{
+	return 0;
+}
+
+static void ls_pcie_set_dstate(struct ls_pcie *pcie, u32 dstate)
+{
+	struct dw_pcie *pci = pcie->pci;
+	u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_PM);
+	u32 val;
+
+	val = dw_pcie_readw_dbi(pci, offset + PCI_PM_CTRL);
+	val &= ~PCI_PM_CTRL_STATE_MASK;
+	val |= dstate;
+	dw_pcie_writew_dbi(pci, offset + PCI_PM_CTRL, val);
+}
+
 static int ls_pcie_host_init(struct pcie_port *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -91,22 +341,63 @@ static int ls_pcie_host_init(struct pcie_port *pp)
 
 	ls_pcie_drop_msg_tlp(pcie);
 
+	if (dw_pcie_link_up(pci)) {
+		dev_dbg(pci->dev, "Endpoint is present\n");
+		pcie->ep_presence = true;
+	}
+
+	if (pcie->drvdata->pm_ops && pcie->drvdata->pm_ops->pm_init &&
+	    !pcie->drvdata->pm_ops->pm_init(pcie))
+		pcie->pm_support = true;
+
 	return 0;
 }
 
+static struct ls_pcie_host_pm_ops ls1021a_pcie_host_pm_ops = {
+	.pm_init = &ls1021a_pcie_pm_init,
+	.send_turn_off_message = &ls1021a_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls1021a_pcie_exit_from_l2,
+};
+
+static struct ls_pcie_host_pm_ops ls1043a_pcie_host_pm_ops = {
+	.pm_init = &ls1021a_pcie_pm_init,
+	.send_turn_off_message = &ls1043a_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls1043a_pcie_exit_from_l2,
+};
+
+static struct ls_pcie_host_pm_ops ls_pcie_host_pm_ops = {
+	.pm_init = &ls_pcie_pm_init,
+	.send_turn_off_message = &ls_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls_pcie_exit_from_l2,
+};
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 };
 
+static const struct ls_pcie_drvdata ls1021a_drvdata = {
+	.ops = &ls_pcie_host_ops,
+	.pm_ops = &ls1021a_pcie_host_pm_ops,
+};
+
+static const struct ls_pcie_drvdata ls1043a_drvdata = {
+	.ops = &ls_pcie_host_ops,
+	.lut_off = 0x10000,
+	.pm_ops = &ls1043a_pcie_host_pm_ops,
+};
+
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.ops = &ls_pcie_host_ops,
+	.lut_off = 0x80000,
+	.pf_off = 0xc0000,
+	.pm_ops = &ls_pcie_host_pm_ops,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
 	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1021a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
 	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &layerscape_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 },
@@ -142,6 +433,14 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	if (IS_ERR(pci->dbi_base))
 		return PTR_ERR(pci->dbi_base);
 
+	pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
+
+	if (pcie->drvdata->lut_off)
+		pcie->lut_base = pci->dbi_base + pcie->drvdata->lut_off;
+
+	if (pcie->drvdata->pf_off)
+		pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
+
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
@@ -150,12 +449,91 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	return dw_pcie_host_init(&pci->pp);
 }
 
+static bool ls_pcie_pm_check(struct ls_pcie *pcie)
+{
+	if (!pcie->ep_presence) {
+		dev_dbg(pcie->pci->dev, "Endpoint isn't present\n");
+		return false;
+	}
+
+	if (!pcie->pm_support)
+		return false;
+
+	return true;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ls_pcie_suspend_noirq(struct device *dev)
+{
+	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	struct dw_pcie *pci = pcie->pci;
+	u32 val;
+	int ret;
+
+	if (!ls_pcie_pm_check(pcie))
+		return 0;
+
+	pcie->drvdata->pm_ops->send_turn_off_message(pcie);
+
+	/* 10ms timeout to check L2 ready */
+	ret = readl_poll_timeout(pci->dbi_base + PCIE_PORT_DEBUG0,
+				 val, LS_PCIE_IS_L2(val), 100, 10000);
+	if (ret) {
+		dev_err(dev, "PCIe link enter L2 timeout! ltssm = 0x%x\n", val);
+		return ret;
+	}
+
+	ls_pcie_set_dstate(pcie, 0x3);
+
+	return 0;
+}
+
+static int ls_pcie_resume_noirq(struct device *dev)
+{
+	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	struct dw_pcie *pci = pcie->pci;
+	int ret;
+
+	if (!ls_pcie_pm_check(pcie))
+		return 0;
+
+	ls_pcie_set_dstate(pcie, 0x0);
+
+	pcie->drvdata->pm_ops->exit_from_l2(pcie);
+
+	dw_pcie_setup_rc(pp);
+
+	/* delay 10 ms to access EP */
+	mdelay(10);
+
+	ret = ls_pcie_host_init(&pci->pp);
+	if (ret) {
+		dev_err(dev, "ls_pcie_host_init failed! ret = 0x%x\n", ret);
+		return ret;
+	}
+
+	ret = dw_pcie_wait_for_link(pci);
+	if (ret) {
+		dev_err(dev, "wait link up timeout! ret = 0x%x\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops ls_pcie_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(ls_pcie_suspend_noirq,
+				      ls_pcie_resume_noirq)
+};
+
 static struct platform_driver ls_pcie_driver = {
 	.probe = ls_pcie_probe,
 	.driver = {
 		.name = "layerscape-pcie",
 		.of_match_table = ls_pcie_of_match,
 		.suppress_bind_attrs = true,
+		.pm = &ls_pcie_pm_ops,
 	},
 };
 builtin_platform_driver(ls_pcie_driver);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 7247c8b01f04..067b48a07100 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -54,6 +54,7 @@
 #define PCIE_PORT_DEBUG0		0x728
 #define PORT_LOGIC_LTSSM_STATE_MASK	0x1f
 #define PORT_LOGIC_LTSSM_STATE_L0	0x11
+#define PORT_LOGIC_LTSSM_STATE_L2	0x15
 #define PCIE_PORT_DEBUG1		0x72C
 #define PCIE_PORT_DEBUG1_LINK_UP		BIT(4)
 #define PCIE_PORT_DEBUG1_LINK_IN_TRAINING	BIT(29)
-- 
2.17.1



From zhiqiang.hou at nxp.com  Tue Apr  6 10:03:38 2021
From: zhiqiang.hou at nxp.com (Z.q. Hou)
Date: Tue, 6 Apr 2021 09:03:38 +0000
Subject: [PATCH 0/4] PCI: dwc: Refine the EP code no functionality change
In-Reply-To: <20210107091123.8616-1-Zhiqiang.Hou@nxp.com>
References: <20210107091123.8616-1-Zhiqiang.Hou@nxp.com>
Message-ID: <HE1PR0402MB33717865894604AE704CD38E84769@HE1PR0402MB3371.eurprd04.prod.outlook.com>

Hi Lorenzo, Rob and Bjorn,

Any comments on this series?

Thanks,
Zhiqiang

> -----Original Message-----
> From: Z.q. Hou <zhiqiang.hou at nxp.com>
> Sent: 2021?1?7? 17:11
> To: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-omap at vger.kernel.org;
> linux-arm-kernel at axis.com; lorenzo.pieralisi at arm.com; robh at kernel.org;
> bhelgaas at google.com
> Cc: kishon at ti.com; M.h. Lian <minghuan.lian at nxp.com>;
> jesper.nilsson at axis.com; jingoohan1 at gmail.com;
> gustavo.pimentel at synopsys.com; hayashi.kunihiko at socionext.com; Z.q.
> Hou <zhiqiang.hou at nxp.com>
> Subject: [PATCH 0/4] PCI: dwc: Refine the EP code no functionality change
> 
> From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
> 
> Tune the EP mode code slightly to make it more readable.
> 
> Hou Zhiqiang (4):
>   PCI: dwc: Change to use an array to store the structure of functions
>   PCI: dwc: Add CFG offset info into function's represented structure
>   PCI: dwc: Rename callback function func_conf_select and its instance
>   PCI: dwc: Change the parameter of function dw_pcie_ep_reset_bar()
> 
>  drivers/pci/controller/dwc/pci-dra7xx.c       |   2 +-
>  .../pci/controller/dwc/pci-layerscape-ep.c    |   8 +-
>  drivers/pci/controller/dwc/pcie-artpec6.c     |   2 +-
>  .../pci/controller/dwc/pcie-designware-ep.c   | 192 ++++++++----------
>  .../pci/controller/dwc/pcie-designware-plat.c |   3 +-
>  drivers/pci/controller/dwc/pcie-designware.h  |  11 +-
>  drivers/pci/controller/dwc/pcie-uniphier-ep.c |   3 +-
>  7 files changed, 96 insertions(+), 125 deletions(-)
> 
> --
> 2.17.1


From weifeng.voon at intel.com  Tue Apr  6 10:05:33 2021
From: weifeng.voon at intel.com (Voon, Weifeng)
Date: Tue, 6 Apr 2021 09:05:33 +0000
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <YGsgHWItHcLFV9Kg@lunn.ch>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
 <YGsgHWItHcLFV9Kg@lunn.ch>
Message-ID: <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>

> > > You have a MAC and an PCS in the stmmac IP block. That then has some
> > > sort of SERDES interface, running 1000BaseX, SGMII, SGMII
> > > overclocked at 2.5G or 25000BaseX. Connected to the SERDES you have
> > > a PHY which converts to copper, giving you 2500BaseT.
> > >
> > > You said earlier, that the PHY can only do 2500BaseT. So it should
> > > be the PHY driver which sets supported to 2500BaseT and no other
> > > speeds.
> > >
> > > You should think about when somebody uses this MAC with a different
> > > PHY, one that can do the full range of 10/half through to 2.5G full.
> > > What generally happens is that the PHY performs auto-neg to
> > > determine the link speed. For 10M-1G speeds the PHY will configure
> > > its SERDES interface to SGMII and phylink will ask the PCS to also
> > > be configured to SGMII. If the PHY negotiates 2500BaseT, it will
> > > configure its side of the SERDES to 2500BaseX or SGMII overclocked
> > > at 2.5G. Again, phylink will ask the PCS to match what the PHY is
> > > doing.
> > >
> > > So, where exactly is the limitation in your hardware? PCS or PHY?
> > The limitation in the hardware is at the PCS side where it is either
> > running in SGMII 2.5G or SGMII 1G speeds.
> > When running on SGMII 2.5G speeds, we disable the in-band AN and use
> > 2.5G speed only
> 
> So there is no actual limitation! The MAC should indicate it can do 10Half
> through to 2500BaseT. And you need to listen to PHYLINK and swap the PCS
> between SGMII to overclocked SGMII when it requests.
> 
> PHYLINK will call stmmac_mac_config() and use state->interface to decide
> how to configure the PCS to match what the PHY is doing.
> 
>      Andrew

The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
overclocking of 2.5 times clock rate to support 2.5G is only able to be
configured in the BIOS during boot time. Kernel driver has no access to 
modify the clock rate for 1Gbps/2.5G mode. The way to determined the 
current 1G/2.5G mode is by reading a dedicated adhoc register through mdio bus.
In short, after the system boot up, it is either in 1G mode or 2.5G mode 
which not able to be changed on the fly. 

Since the stmmac MAC can pair with any PCS and PHY, I still prefer that we tie
this platform specific limitation with the of MAC. As stmmac does handle platform
specific config/limitation. 

What is your thoughts? 

Weifeng


From clabbe.montjoie at gmail.com  Tue Apr  6 10:06:55 2021
From: clabbe.montjoie at gmail.com (Corentin Labbe)
Date: Tue, 6 Apr 2021 11:06:55 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
In-Reply-To: <YGt00DdrToMTskp8@lunn.ch>
References: <YGtZeofmBv7hXK+a@Red>
 <YGt00DdrToMTskp8@lunn.ch>
Message-ID: <YGwkr0qbYqR02Yyh@Red>

Le Mon, Apr 05, 2021 at 10:36:32PM +0200, Andrew Lunn a ?crit :
> On Mon, Apr 05, 2021 at 08:39:54PM +0200, Corentin Labbe wrote:
[ ... ]
> > libphy: Fixed MDIO Bus: probed
> > mdio-gpio ethernet-phy: failed to get alias id
> 
> That does not look too good. But it is just a warning.
> 
>         if (pdev->dev.of_node) {
>                 bus_id = of_alias_get_id(pdev->dev.of_node, "mdio-gpio");
>                 if (bus_id < 0) {
>                         dev_warn(&pdev->dev, "failed to get alias id\n");
>                         bus_id = 0;
>                 }
> 
> If you look at the example in the documentation, it has
> 
> aliases {
>         mdio-gpio0 = &mdio0;
> };
> 
> If you add that, i guess this will go away.
>   

Hello

Yes it go away with this

> > gemini-ethernet-port 6000c000.ethernet-port: probe 6000c000.ethernet-port ID 1
> > gemini-ethernet-port 6000c000.ethernet-port: using a random ethernet address
> > gemini-ethernet-port 6000c000.ethernet-port (unnamed net_device) (uninitialized): PHY init failed
> 
> And now it seems to of all gone horribly wrong :-(
> 
> This is the second Ethernet interface, the one you have commented as 
> 
> /* Not used in this platform */
> 
> I _think_ you just need to delete the entry, otherwise it tried to
> probe it. And then that probe fails, it looks like it also fails the
> working interface :-(

Deleting the entry did no change. It still try to probe it.
I will try to delete second interface in gemini.dtsi just in case...


> > # udhcpc -i eth0
> > udhcpc: started, v1.33.0
> > udhcpc: socket: Address family not supported by protocol
> 
> That suggests the kernel you have build does not have PF_PACKET.
> Enable CONFIG_PACKET_DIAG.

Yes adding it fixed this error message.

Thanks


From joro at 8bytes.org  Tue Apr  6 10:08:18 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Tue, 6 Apr 2021 11:08:18 +0200
Subject: [PATCH] iommu: Add device name to iommu map/unmap trace events
In-Reply-To: <626fbcb8-b84f-1522-4ec3-9c7c1f5f7a93@hisilicon.com>
References: <20210209123620.19993-1-saiprakash.ranjan@codeaurora.org>
 <20210212105039.GG7302@8bytes.org>
 <626fbcb8-b84f-1522-4ec3-9c7c1f5f7a93@hisilicon.com>
Message-ID: <YGwlAqQVSV6k5z9j@8bytes.org>

On Tue, Apr 06, 2021 at 02:56:53PM +0800, chenxiang (M) wrote:
> Is it possible to use group id to identify different domains?

No, the best is to do this during post-processing of your traces by also
keeping tack of domain-device attachments/detachments.

Regards,

	Joerg


From hverkuil-cisco at xs4all.nl  Tue Apr  6 10:24:04 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 6 Apr 2021 11:24:04 +0200
Subject: [PATCH] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not
 default to m
In-Reply-To: <20210331081735.367238-1-geert+renesas@glider.be>
References: <20210331081735.367238-1-geert+renesas@glider.be>
Message-ID: <e566f40a-dcfb-d863-bc6a-369e7972114a@xs4all.nl>

Hi Geert,

On 31/03/2021 10:17, Geert Uytterhoeven wrote:
> The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
> Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
> ARCH_MXC, to prevent asking the user about this driver when configuring
> a kernel without i.MX8 support.
> 
> Drop the "default m" (which means "default y" if CONFIG_MODULES is not
> enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
> additional code.

You do not actually drop 'default m' in the patch. Either the patch or the
commit message is wrong.

Regards,

	Hans

> 
> Fixes: 2db16c6ed72ce644 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
>  drivers/media/platform/imx-jpeg/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/imx-jpeg/Kconfig b/drivers/media/platform/imx-jpeg/Kconfig
> index d875f7c88cdad125..0e3269d06ded30ec 100644
> --- a/drivers/media/platform/imx-jpeg/Kconfig
> +++ b/drivers/media/platform/imx-jpeg/Kconfig
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  config VIDEO_IMX8_JPEG
>  	tristate "IMX8 JPEG Encoder/Decoder"
> +	depends on ARCH_MXC || COMPILE_TEST
>  	depends on VIDEO_DEV && VIDEO_V4L2
>  	select VIDEOBUF2_DMA_CONTIG
>  	select V4L2_MEM2MEM_DEV
> 



From geert+renesas at glider.be  Tue Apr  6 10:32:26 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue,  6 Apr 2021 11:32:26 +0200
Subject: [PATCH v2] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not
 default to m
Message-ID: <129d6bab29b47c265cf0e2a70545e7c0422ce7ba.1617701454.git.geert+renesas@glider.be>

The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
ARCH_MXC, to prevent asking the user about this driver when configuring
a kernel without i.MX8 support.

Drop the "default m" (which means "default y" if CONFIG_MODULES is not
enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
additional code.

Fixes: 2db16c6ed72ce644 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Really drop the "default m".
---
 drivers/media/platform/imx-jpeg/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/imx-jpeg/Kconfig b/drivers/media/platform/imx-jpeg/Kconfig
index d875f7c88cdad125..2fdd648cda80af8e 100644
--- a/drivers/media/platform/imx-jpeg/Kconfig
+++ b/drivers/media/platform/imx-jpeg/Kconfig
@@ -1,11 +1,11 @@
 # SPDX-License-Identifier: GPL-2.0
 config VIDEO_IMX8_JPEG
 	tristate "IMX8 JPEG Encoder/Decoder"
+	depends on ARCH_MXC || COMPILE_TEST
 	depends on VIDEO_DEV && VIDEO_V4L2
 	select VIDEOBUF2_DMA_CONTIG
 	select V4L2_MEM2MEM_DEV
 	select V4L2_JPEG_HELPER
-	default m
 	help
 	  This is a video4linux2 driver for the i.MX8 QXP/QM integrated
 	  JPEG encoder/decoder.
-- 
2.25.1



From geert at linux-m68k.org  Tue Apr  6 10:33:02 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 6 Apr 2021 11:33:02 +0200
Subject: [PATCH] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not
 default to m
In-Reply-To: <e566f40a-dcfb-d863-bc6a-369e7972114a@xs4all.nl>
References: <20210331081735.367238-1-geert+renesas@glider.be>
 <e566f40a-dcfb-d863-bc6a-369e7972114a@xs4all.nl>
Message-ID: <CAMuHMdXCjhDQhtAXir5zd7u=NCsCFhVvB6kmckWkmXbiQJix4A@mail.gmail.com>

Hoi Hans,

On Tue, Apr 6, 2021 at 11:24 AM Hans Verkuil <hverkuil-cisco at xs4all.nl> wrote:
> On 31/03/2021 10:17, Geert Uytterhoeven wrote:
> > The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
> > Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
> > ARCH_MXC, to prevent asking the user about this driver when configuring
> > a kernel without i.MX8 support.
> >
> > Drop the "default m" (which means "default y" if CONFIG_MODULES is not
> > enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
> > additional code.
>
> You do not actually drop 'default m' in the patch. Either the patch or the
> commit message is wrong.

Oops, the patch is wrong.
V2 sent.
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 jani.nikula at linux.intel.com  Tue Apr  6 10:32:58 2021
From: jani.nikula at linux.intel.com (Jani Nikula)
Date: Tue, 06 Apr 2021 12:32:58 +0300
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
Message-ID: <87tuojlpv9.fsf@intel.com>

On Tue, 06 Apr 2021, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote:
> Given that lowlevel drivers usually cannot implement exactly what a
> consumer requests with pwm_apply_state() there is some rounding involved.
>
> pwm_get_state() traditionally returned the setting that was requested most
> recently by the consumer (opposed to what was actually implemented in
> hardware in reply to the last request). To make this semantic obvious
> rename the function.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---

>  drivers/gpu/drm/i915/display/intel_panel.c |  4 +--

Acked-by: Jani Nikula <jani.nikula at intel.com>


-- 
Jani Nikula, Intel Open Source Graphics Center


From maz at kernel.org  Tue Apr  6 10:35:49 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:49 +0100
Subject: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with
 irq_find_mapping()
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-2-maz@kernel.org>

irq_linear_revmap() is supposed to be a fast path for domain
lookups, but it only exposes low-level details of the irqdomain
implementation, details which are better kept private.

The *overhead* between the two is only a function call and
a couple of tests, so it is likely that noone can show any
meaningful difference compared to the cost of taking an
interrupt.

Reimplement irq_linear_revmap() with irq_find_mapping()
in order to preserve source code compatibility, and
rename the internal field for a measure.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 include/linux/irqdomain.h | 22 +++++++++-------------
 kernel/irq/irqdomain.c    |  6 +++---
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 33cacc8af26d..b9600f24878a 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -154,9 +154,9 @@ struct irq_domain_chip_generic;
  * Revmap data, used internally by irq_domain
  * @revmap_direct_max_irq: The largest hwirq that can be set for controllers that
  *                         support direct mapping
- * @revmap_size: Size of the linear map table @linear_revmap[]
+ * @revmap_size: Size of the linear map table @revmap[]
  * @revmap_tree: Radix map tree for hwirqs that don't fit in the linear map
- * @linear_revmap: Linear table of hwirq->virq reverse mappings
+ * @revmap: Linear table of hwirq->virq reverse mappings
  */
 struct irq_domain {
 	struct list_head link;
@@ -180,7 +180,7 @@ struct irq_domain {
 	unsigned int revmap_size;
 	struct radix_tree_root revmap_tree;
 	struct mutex revmap_tree_mutex;
-	unsigned int linear_revmap[];
+	unsigned int revmap[];
 };
 
 /* Irq domain flags */
@@ -396,24 +396,20 @@ static inline unsigned int irq_create_mapping(struct irq_domain *host,
 	return irq_create_mapping_affinity(host, hwirq, NULL);
 }
 
-
 /**
- * irq_linear_revmap() - Find a linux irq from a hw irq number.
+ * irq_find_mapping() - Find a linux irq from a hw irq number.
  * @domain: domain owning this hardware interrupt
  * @hwirq: hardware irq number in that domain space
- *
- * This is a fast path alternative to irq_find_mapping() that can be
- * called directly by irq controller code to save a handful of
- * instructions. It is always safe to call, but won't find irqs mapped
- * using the radix tree.
  */
+extern unsigned int irq_find_mapping(struct irq_domain *host,
+				     irq_hw_number_t hwirq);
+
 static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
 					     irq_hw_number_t hwirq)
 {
-	return hwirq < domain->revmap_size ? domain->linear_revmap[hwirq] : 0;
+	return irq_find_mapping(domain, hwirq);
 }
-extern unsigned int irq_find_mapping(struct irq_domain *host,
-				     irq_hw_number_t hwirq);
+
 extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
 extern int irq_create_strict_mappings(struct irq_domain *domain,
 				      unsigned int irq_base,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index d10ab1d689d5..dfa716305ea9 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -486,7 +486,7 @@ static void irq_domain_clear_mapping(struct irq_domain *domain,
 				     irq_hw_number_t hwirq)
 {
 	if (hwirq < domain->revmap_size) {
-		domain->linear_revmap[hwirq] = 0;
+		domain->revmap[hwirq] = 0;
 	} else {
 		mutex_lock(&domain->revmap_tree_mutex);
 		radix_tree_delete(&domain->revmap_tree, hwirq);
@@ -499,7 +499,7 @@ static void irq_domain_set_mapping(struct irq_domain *domain,
 				   struct irq_data *irq_data)
 {
 	if (hwirq < domain->revmap_size) {
-		domain->linear_revmap[hwirq] = irq_data->irq;
+		domain->revmap[hwirq] = irq_data->irq;
 	} else {
 		mutex_lock(&domain->revmap_tree_mutex);
 		radix_tree_insert(&domain->revmap_tree, hwirq, irq_data);
@@ -920,7 +920,7 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
 
 	/* Check if the hwirq is in the linear revmap. */
 	if (hwirq < domain->revmap_size)
-		return domain->linear_revmap[hwirq];
+		return domain->revmap[hwirq];
 
 	rcu_read_lock();
 	data = radix_tree_lookup(&domain->revmap_tree, hwirq);
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:48 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:48 +0100
Subject: [PATCH 0/9] Cleaning up some of the irqdomain features
Message-ID: <20210406093557.1073423-1-maz@kernel.org>

The irqdomain subsystem has grown quite a lot over the years, and some
of its features are either oddly used or just pretty useless. Some
other helpers expose internals that are likely to change soon.

Here are the bits that I'm trying to get rid of:

- irq_linear_revmap exposes the internals of the domains, and only
  works for linear domains. The supposed speed improvement really
  isn't an argument, as it gets in the way of more significant
  optimisations. Reimplemented in terms of irq_find_mapping, which
  always works, and will eventually go at some point.

- irq_create_strict_mappings is just a way to constraint the
  allocation of irqdescs into a given range, which is better served by
  creating a legacy irqdomain, and shows that the platform really
  needs to catch up with the 21st century.

- irq_create_identity mapping is just a variation on the above, with
  irq==hwirq, although the way it is used is a gross hack in the SH
  code that needs to go.

- irq_domain_add_legacy_isa is, as the names shows, a variation on
  irq_domain_add_legacy with a reservation of 16 interrupts. This is
  only used in the PPC code.

The patches address all of the above, touching some of the ARM, PPC,
and SH code that is affected. Another couple of patches address a MIPS
platform that could use the generic code, and clean some of the
comments in the irqdomain code.

Unless anyone shouts, I'd like to take this into 5.13, as it is the
basis of some further (and deeper) changes in the way irqdomains work.

	M.

Marc Zyngier (9):
  irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping()
  ARM: PXA: Kill use of irq_create_strict_mappings()
  irqchip/jcore-aic: Kill use of irq_create_strict_mappings()
  sh: intc: Drop the use of irq_create_identity_mapping()
  irqdomain: Kill
    irq_create_strict_mappings()/irq_create_identity_mapping()
  mips: netlogic: Use irq_domain_simple_ops for XLP PIC
  irqdomain: Drop references to recusive irqdomain setup
  powerpc: Convert irq_domain_add_legacy_isa use to
    irq_domain_add_legacy
  irqdomain: Kill irq_domain_add_legacy_isa

 Documentation/core-api/irq/irq-domain.rst |  1 -
 arch/arm/mach-pxa/pxa_cplds_irqs.c        | 24 +++++------
 arch/mips/netlogic/common/irq.c           |  6 +--
 arch/powerpc/include/asm/irq.h            |  4 +-
 arch/powerpc/platforms/ps3/interrupt.c    |  4 +-
 arch/powerpc/sysdev/i8259.c               |  3 +-
 arch/powerpc/sysdev/mpic.c                |  2 +-
 arch/powerpc/sysdev/tsi108_pci.c          |  3 +-
 arch/powerpc/sysdev/xics/xics-common.c    |  2 +-
 drivers/irqchip/irq-jcore-aic.c           |  4 +-
 drivers/sh/intc/core.c                    | 50 ++++++++++-------------
 include/linux/irqdomain.h                 | 42 ++++---------------
 kernel/irq/irqdomain.c                    | 49 +++-------------------
 13 files changed, 59 insertions(+), 135 deletions(-)

-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:50 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:50 +0100
Subject: [PATCH 2/9] ARM: PXA: Kill use of irq_create_strict_mappings()
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-3-maz@kernel.org>

irq_create_strict_mappings() is a poor way to allow the use of
a linear IRQ domain as a legacy one. Let's be upfront about
it and use a legacy domain when appropriate.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm/mach-pxa/pxa_cplds_irqs.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-pxa/pxa_cplds_irqs.c b/arch/arm/mach-pxa/pxa_cplds_irqs.c
index 45c19ca96f7a..ec0d9b094744 100644
--- a/arch/arm/mach-pxa/pxa_cplds_irqs.c
+++ b/arch/arm/mach-pxa/pxa_cplds_irqs.c
@@ -147,22 +147,20 @@ static int cplds_probe(struct platform_device *pdev)
 	}
 
 	irq_set_irq_wake(fpga->irq, 1);
-	fpga->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
-					       CPLDS_NB_IRQ,
-					       &cplds_irq_domain_ops, fpga);
+	if (base_irq)
+		fpga->irqdomain = irq_domain_add_legacy(pdev->dev.of_node,
+							CPLDS_NB_IRQ,
+							base_irq, 0,
+							&cplds_irq_domain_ops,
+							fpga);
+	else
+		fpga->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
+							CPLDS_NB_IRQ,
+							&cplds_irq_domain_ops,
+							fpga);
 	if (!fpga->irqdomain)
 		return -ENODEV;
 
-	if (base_irq) {
-		ret = irq_create_strict_mappings(fpga->irqdomain, base_irq, 0,
-						 CPLDS_NB_IRQ);
-		if (ret) {
-			dev_err(&pdev->dev, "couldn't create the irq mapping %d..%d\n",
-				base_irq, base_irq + CPLDS_NB_IRQ);
-			return ret;
-		}
-	}
-
 	return 0;
 }
 
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:51 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:51 +0100
Subject: [PATCH 3/9] irqchip/jcore-aic: Kill use of
 irq_create_strict_mappings()
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-4-maz@kernel.org>

irq_create_strict_mappings() is a poor way to allow the use of
a linear IRQ domain as a legacy one. Let's be upfront about it.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/irqchip/irq-jcore-aic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
index 033bccb41455..5f47d8ee4ae3 100644
--- a/drivers/irqchip/irq-jcore-aic.c
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -100,11 +100,11 @@ static int __init aic_irq_of_init(struct device_node *node,
 	jcore_aic.irq_unmask = noop;
 	jcore_aic.name = "AIC";
 
-	domain = irq_domain_add_linear(node, dom_sz, &jcore_aic_irqdomain_ops,
+	domain = irq_domain_add_legacy(node, dom_sz - min_irq, min_irq, min_irq,
+				       &jcore_aic_irqdomain_ops,
 				       &jcore_aic);
 	if (!domain)
 		return -ENOMEM;
-	irq_create_strict_mappings(domain, min_irq, min_irq, dom_sz - min_irq);
 
 	return 0;
 }
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:52 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:52 +0100
Subject: [PATCH 4/9] sh: intc: Drop the use of irq_create_identity_mapping()
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-5-maz@kernel.org>

Instead of playing games with using irq_create_identity_mapping()
and irq_domain_associate(), drop the use of the former and only
use the latter, together with the allocation of the irq_desc
as needed.

It doesn't make the code less awful, but at least the intent
is clearer.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/sh/intc/core.c | 50 ++++++++++++++++++------------------------
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
index a14684ffe4c1..6c57ee1ce6c4 100644
--- a/drivers/sh/intc/core.c
+++ b/drivers/sh/intc/core.c
@@ -179,6 +179,23 @@ static unsigned int __init save_reg(struct intc_desc_int *d,
 	return 0;
 }
 
+static bool __init intc_map(struct irq_domain *domain, int irq)
+{
+	int res;
+
+	if (!irq_to_desc(irq) && irq_alloc_desc_at(irq, NUMA_NO_NODE) != irq) {
+		pr_err("uname to allocate IRQ %d\n", irq);
+		return false;
+	}
+
+	if (irq_domain_associate(domain, irq, irq)) {
+		pr_err("domain association failure\n");
+		return false;
+	}
+
+	return true;
+}
+
 int __init register_intc_controller(struct intc_desc *desc)
 {
 	unsigned int i, k, smp;
@@ -316,19 +333,8 @@ int __init register_intc_controller(struct intc_desc *desc)
 		if (!vect->enum_id)
 			continue;
 
-		res = irq_create_identity_mapping(d->domain, irq);
-		if (unlikely(res)) {
-			if (res == -EEXIST) {
-				res = irq_domain_associate(d->domain, irq, irq);
-				if (unlikely(res)) {
-					pr_err("domain association failure\n");
-					continue;
-				}
-			} else {
-				pr_err("can't identity map IRQ %d\n", irq);
-				continue;
-			}
-		}
+		if (!intc_map(d->domain, irq))
+			continue;
 
 		intc_irq_xlate_set(irq, vect->enum_id, d);
 		intc_register_irq(desc, d, vect->enum_id, irq);
@@ -345,22 +351,8 @@ int __init register_intc_controller(struct intc_desc *desc)
 			 * IRQ support, each vector still needs to have
 			 * its own backing irq_desc.
 			 */
-			res = irq_create_identity_mapping(d->domain, irq2);
-			if (unlikely(res)) {
-				if (res == -EEXIST) {
-					res = irq_domain_associate(d->domain,
-								   irq2, irq2);
-					if (unlikely(res)) {
-						pr_err("domain association "
-						       "failure\n");
-						continue;
-					}
-				} else {
-					pr_err("can't identity map IRQ %d\n",
-					       irq);
-					continue;
-				}
-			}
+			if (!intc_map(d->domain, irq2))
+				continue;
 
 			vect2->enum_id = 0;
 
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:53 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:53 +0100
Subject: [PATCH 5/9] irqdomain: Kill
 irq_create_strict_mappings()/irq_create_identity_mapping()
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-6-maz@kernel.org>

No user of these APIs are left, remove them.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 include/linux/irqdomain.h |  9 ---------
 kernel/irq/irqdomain.c    | 35 -----------------------------------
 2 files changed, 44 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index b9600f24878a..3997ed9e4d7d 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -411,15 +411,6 @@ static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
 }
 
 extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
-extern int irq_create_strict_mappings(struct irq_domain *domain,
-				      unsigned int irq_base,
-				      irq_hw_number_t hwirq_base, int count);
-
-static inline int irq_create_identity_mapping(struct irq_domain *host,
-					      irq_hw_number_t hwirq)
-{
-	return irq_create_strict_mappings(host, hwirq, hwirq, 1);
-}
 
 extern const struct irq_domain_ops irq_domain_simple_ops;
 
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index dfa716305ea9..0ba761e6b0a8 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -703,41 +703,6 @@ unsigned int irq_create_mapping_affinity(struct irq_domain *domain,
 }
 EXPORT_SYMBOL_GPL(irq_create_mapping_affinity);
 
-/**
- * irq_create_strict_mappings() - Map a range of hw irqs to fixed linux irqs
- * @domain: domain owning the interrupt range
- * @irq_base: beginning of linux IRQ range
- * @hwirq_base: beginning of hardware IRQ range
- * @count: Number of interrupts to map
- *
- * This routine is used for allocating and mapping a range of hardware
- * irqs to linux irqs where the linux irq numbers are at pre-defined
- * locations. For use by controllers that already have static mappings
- * to insert in to the domain.
- *
- * Non-linear users can use irq_create_identity_mapping() for IRQ-at-a-time
- * domain insertion.
- *
- * 0 is returned upon success, while any failure to establish a static
- * mapping is treated as an error.
- */
-int irq_create_strict_mappings(struct irq_domain *domain, unsigned int irq_base,
-			       irq_hw_number_t hwirq_base, int count)
-{
-	struct device_node *of_node;
-	int ret;
-
-	of_node = irq_domain_get_of_node(domain);
-	ret = irq_alloc_descs(irq_base, irq_base, count,
-			      of_node_to_nid(of_node));
-	if (unlikely(ret < 0))
-		return ret;
-
-	irq_domain_associate_many(domain, irq_base, hwirq_base, count);
-	return 0;
-}
-EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
-
 static int irq_domain_translate(struct irq_domain *d,
 				struct irq_fwspec *fwspec,
 				irq_hw_number_t *hwirq, unsigned int *type)
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:55 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:55 +0100
Subject: [PATCH 7/9] irqdomain: Drop references to recusive irqdomain setup
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-8-maz@kernel.org>

It was never completely implemented, and was removed a long time
ago. Adjust the documentation to reflect this.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 kernel/irq/irqdomain.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 0ba761e6b0a8..89474aa88220 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1659,12 +1659,10 @@ void irq_domain_free_irqs(unsigned int virq, unsigned int nr_irqs)
 
 /**
  * irq_domain_alloc_irqs_parent - Allocate interrupts from parent domain
+ * @domain:	Domain below which interrupts must be allocated
  * @irq_base:	Base IRQ number
  * @nr_irqs:	Number of IRQs to allocate
  * @arg:	Allocation data (arch/domain specific)
- *
- * Check whether the domain has been setup recursive. If not allocate
- * through the parent domain.
  */
 int irq_domain_alloc_irqs_parent(struct irq_domain *domain,
 				 unsigned int irq_base, unsigned int nr_irqs,
@@ -1680,11 +1678,9 @@ EXPORT_SYMBOL_GPL(irq_domain_alloc_irqs_parent);
 
 /**
  * irq_domain_free_irqs_parent - Free interrupts from parent domain
+ * @domain:	Domain below which interrupts must be freed
  * @irq_base:	Base IRQ number
  * @nr_irqs:	Number of IRQs to free
- *
- * Check whether the domain has been setup recursive. If not free
- * through the parent domain.
  */
 void irq_domain_free_irqs_parent(struct irq_domain *domain,
 				 unsigned int irq_base, unsigned int nr_irqs)
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:54 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:54 +0100
Subject: [PATCH 6/9] mips: netlogic: Use irq_domain_simple_ops for XLP PIC
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-7-maz@kernel.org>

Use the generic irq_domain_simple_ops structure instead of
a home-grown one.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/mips/netlogic/common/irq.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/mips/netlogic/common/irq.c b/arch/mips/netlogic/common/irq.c
index cf33dd8a487e..c25a2ce5e29f 100644
--- a/arch/mips/netlogic/common/irq.c
+++ b/arch/mips/netlogic/common/irq.c
@@ -276,10 +276,6 @@ asmlinkage void plat_irq_dispatch(void)
 }
 
 #ifdef CONFIG_CPU_XLP
-static const struct irq_domain_ops xlp_pic_irq_domain_ops = {
-	.xlate = irq_domain_xlate_onetwocell,
-};
-
 static int __init xlp_of_pic_init(struct device_node *node,
 					struct device_node *parent)
 {
@@ -324,7 +320,7 @@ static int __init xlp_of_pic_init(struct device_node *node,
 
 	xlp_pic_domain = irq_domain_add_legacy(node, n_picirqs,
 		nlm_irq_to_xirq(socid, PIC_IRQ_BASE), PIC_IRQ_BASE,
-		&xlp_pic_irq_domain_ops, NULL);
+		&irq_domain_simple_ops, NULL);
 	if (xlp_pic_domain == NULL) {
 		pr_err("PIC %pOFn: Creating legacy domain failed!\n", node);
 		return -EINVAL;
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:56 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:56 +0100
Subject: [PATCH 8/9] powerpc: Convert irq_domain_add_legacy_isa use to
 irq_domain_add_legacy
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-9-maz@kernel.org>

irq_domain_add_legacy_isa is a pain. It only exists for the benefit of
two PPC-specific drivers, and creates an ugly dependency between asm/irq.h
and linux/irqdomain.h

Instead, let's convert these two drivers to irq_domain_add_legacy(),
stop using NUM_ISA_INTERRUPTS by directly setting NR_IRQS_LEGACY.

The dependency cannot be broken yet as there is a lot of PPC-related
code that depends on it, but that's the first step towards it.

A followup patch will remove irq_domain_add_legacy_isa.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/powerpc/include/asm/irq.h         | 4 ++--
 arch/powerpc/platforms/ps3/interrupt.c | 4 ++--
 arch/powerpc/sysdev/i8259.c            | 3 ++-
 arch/powerpc/sysdev/mpic.c             | 2 +-
 arch/powerpc/sysdev/tsi108_pci.c       | 3 ++-
 arch/powerpc/sysdev/xics/xics-common.c | 2 +-
 6 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index f3f264e441a7..aeb209144c68 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -23,8 +23,8 @@ extern atomic_t ppc_n_lost_interrupts;
 /* Total number of virq in the platform */
 #define NR_IRQS		CONFIG_NR_IRQS
 
-/* Same thing, used by the generic IRQ code */
-#define NR_IRQS_LEGACY		NUM_ISA_INTERRUPTS
+/* Number of irqs reserved for a legacy isa controller */
+#define NR_IRQS_LEGACY		16
 
 extern irq_hw_number_t virq_to_hw(unsigned int virq);
 
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 78f2339ed5cb..93e367a00452 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -45,7 +45,7 @@
  * implementation equates HV plug value to Linux virq value, constrains each
  * interrupt to have a system wide unique plug number, and limits the range
  * of the plug values to map into the first dword of the bitmaps.  This
- * gives a usable range of plug values of  {NUM_ISA_INTERRUPTS..63}.  Note
+ * gives a usable range of plug values of  {NR_IRQS_LEGACY..63}.  Note
  * that there is no constraint on how many in this set an individual thread
  * can acquire.
  *
@@ -721,7 +721,7 @@ static unsigned int ps3_get_irq(void)
 	}
 
 #if defined(DEBUG)
-	if (unlikely(plug < NUM_ISA_INTERRUPTS || plug > PS3_PLUG_MAX)) {
+	if (unlikely(plug < NR_IRQS_LEGACY || plug > PS3_PLUG_MAX)) {
 		dump_bmp(&per_cpu(ps3_private, 0));
 		dump_bmp(&per_cpu(ps3_private, 1));
 		BUG();
diff --git a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
index c1d76c344351..dc1a151c63d7 100644
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -260,7 +260,8 @@ void i8259_init(struct device_node *node, unsigned long intack_addr)
 	raw_spin_unlock_irqrestore(&i8259_lock, flags);
 
 	/* create a legacy host */
-	i8259_host = irq_domain_add_legacy_isa(node, &i8259_host_ops, NULL);
+	i8259_host = irq_domain_add_legacy(node, NR_IRQS_LEGACY, 0, 0,
+					   &i8259_host_ops, NULL);
 	if (i8259_host == NULL) {
 		printk(KERN_ERR "i8259: failed to allocate irq host !\n");
 		return;
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index b0426f28946a..995fb2ada507 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -602,7 +602,7 @@ static void __init mpic_scan_ht_pics(struct mpic *mpic)
 /* Find an mpic associated with a given linux interrupt */
 static struct mpic *mpic_find(unsigned int irq)
 {
-	if (irq < NUM_ISA_INTERRUPTS)
+	if (irq < NR_IRQS_LEGACY)
 		return NULL;
 
 	return irq_get_chip_data(irq);
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 49f9541954f8..042bb38fa5c2 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -404,7 +404,8 @@ void __init tsi108_pci_int_init(struct device_node *node)
 {
 	DBG("Tsi108_pci_int_init: initializing PCI interrupts\n");
 
-	pci_irq_host = irq_domain_add_legacy_isa(node, &pci_irq_domain_ops, NULL);
+	pci_irq_host = irq_domain_add_legacy(node, NR_IRQS_LEGACY, 0, 0,
+					     &pci_irq_domain_ops, NULL);
 	if (pci_irq_host == NULL) {
 		printk(KERN_ERR "pci_irq_host: failed to allocate irq domain!\n");
 		return;
diff --git a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
index 7e4305c01bac..fdf8db4444b6 100644
--- a/arch/powerpc/sysdev/xics/xics-common.c
+++ b/arch/powerpc/sysdev/xics/xics-common.c
@@ -201,7 +201,7 @@ void xics_migrate_irqs_away(void)
 		struct ics *ics;
 
 		/* We can't set affinity on ISA interrupts */
-		if (virq < NUM_ISA_INTERRUPTS)
+		if (virq < NR_IRQS_LEGACY)
 			continue;
 		/* We only need to migrate enabled IRQS */
 		if (!desc->action)
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 10:35:57 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 10:35:57 +0100
Subject: [PATCH 9/9] irqdomain: Kill irq_domain_add_legacy_isa
In-Reply-To: <20210406093557.1073423-1-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
Message-ID: <20210406093557.1073423-10-maz@kernel.org>

This helper doesn't have a user anymore, let's remove it.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 Documentation/core-api/irq/irq-domain.rst |  1 -
 include/linux/irqdomain.h                 | 11 -----------
 2 files changed, 12 deletions(-)

diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst
index a77c24c27f7b..84e561db468f 100644
--- a/Documentation/core-api/irq/irq-domain.rst
+++ b/Documentation/core-api/irq/irq-domain.rst
@@ -146,7 +146,6 @@ Legacy
 
 	irq_domain_add_simple()
 	irq_domain_add_legacy()
-	irq_domain_add_legacy_isa()
 	irq_domain_create_legacy()
 
 The Legacy mapping is a special case for drivers that already have a
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 3997ed9e4d7d..2a7ecf08d56e 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -45,9 +45,6 @@ struct cpumask;
 struct seq_file;
 struct irq_affinity_desc;
 
-/* Number of irqs reserved for a legacy isa controller */
-#define NUM_ISA_INTERRUPTS	16
-
 #define IRQ_DOMAIN_IRQ_SPEC_PARAMS 16
 
 /**
@@ -346,14 +343,6 @@ static inline struct irq_domain *irq_domain_add_nomap(struct device_node *of_nod
 {
 	return __irq_domain_add(of_node_to_fwnode(of_node), 0, max_irq, max_irq, ops, host_data);
 }
-static inline struct irq_domain *irq_domain_add_legacy_isa(
-				struct device_node *of_node,
-				const struct irq_domain_ops *ops,
-				void *host_data)
-{
-	return irq_domain_add_legacy(of_node, NUM_ISA_INTERRUPTS, 0, 0, ops,
-				     host_data);
-}
 static inline struct irq_domain *irq_domain_add_tree(struct device_node *of_node,
 					 const struct irq_domain_ops *ops,
 					 void *host_data)
-- 
2.29.2



From Al.Grant at arm.com  Tue Apr  6 10:38:32 2021
From: Al.Grant at arm.com (Al Grant)
Date: Tue, 6 Apr 2021 09:38:32 +0000
Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
In-Reply-To: <20210403072346.30430-1-leo.yan@linaro.org>
References: <20210403072346.30430-1-leo.yan@linaro.org>
Message-ID: <AM6PR08MB335124DC0080EA95A817D71786769@AM6PR08MB3351.eurprd08.prod.outlook.com>



> -----Original Message-----
> From: Leo Yan <leo.yan at linaro.org>
> Sent: 03 April 2021 08:24
> To: Arnaldo Carvalho de Melo <acme at kernel.org>; John Garry
> <john.garry at huawei.com>; Will Deacon <will at kernel.org>; Mathieu Poirier
> <mathieu.poirier at linaro.org>; James Clark <James.Clark at arm.com>; Al Grant
> <Al.Grant at arm.com>; Peter Zijlstra <peterz at infradead.org>; Ingo Molnar
> <mingo at redhat.com>; Mark Rutland <Mark.Rutland at arm.com>; Alexander
> Shishkin <alexander.shishkin at linux.intel.com>; Jiri Olsa <jolsa at redhat.com>;
> Namhyung Kim <namhyung at kernel.org>; Adrian Hunter
> <adrian.hunter at intel.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Cc: leo.yan at linaro.org
> Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
> 
> As we know, the timestamp is important for AUX trace; it's mainly used to
> correlate between perf events and AUX trace, allows to generate events with
> time ordered manner.  There have several good examples of enabling timestamp
> for AUX trace (like Intel-pt, Intel-bts, etc).
> 
> Since the conversion between TSC and kernel timestamp has been supported on
> Arm64, TSC is a naming convention from x86, but perf now has reused it to
> support Arm arch timer counter.
> 
> This patch set is to enable timestamp for Arm SPE trace.  It reads out TSC
> parameters from mmap page and stores into auxtrace info structure;

Why not synthesize a PERF_RECORD_TIME_CONV - isn't that specifically to
capture the TSC parameters from the mmap page? If a generic mechanism
exists it would be better to use it, otherwise we'll have to do this again for
future trace formats.

perf_read_tsc_conversion and perf_event__synth_time_conv are currently
in arch/x86/util/tsc.c, but nothing in them is x86-specific and they could be
moved somewhere more generic.

Al


> the TSC
> parameters are used for conversion between timer counter and kernel time and
> which is applied for Arm SPE samples.
> 
> This patch set can be clearly applied on perf/core branch with:
> 
>   commit 6859bc0e78c6 ("perf stat: Improve readability of shadow stats")
> 
> Ths patch series has been tested on Hisilicon D06 platform.
> 
> After:
> 
>   # perf script -F comm,time,cpu,pid,dso,ip,sym
> 
>               perf  2408 [032]   168.680297:  ffffbd1253690a3c perf_event_exec
> ([kernel.kallsyms])
>               perf  2408 [032]   168.680297:  ffffbd1253690a3c perf_event_exec
> ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680317:  ffffbd1253683f50
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680317:  ffffbd1253683f50
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680319:  ffffbd1253683f70
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680319:  ffffbd1253683f70
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680367:  ffffbd12539b03ec
> __arch_clear_user ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440
> kmem_cache_alloc ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440
> kmem_cache_alloc ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440
> kmem_cache_alloc ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680375:  ffffbd1253721440
> kmem_cache_alloc ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
>    false_sharing.e  2408 [032]   168.680376:  ffffbd1253683f70
> perf_iterate_ctx.constprop.0 ([kernel.kallsyms])
> 
> Changes from v1:
> * Rebased patch series on the latest perf/core branch;
> * Fixed the patch for dumping TSC parameters to support both the
>   older and new auxtrace info format.
> 
> 
> Leo Yan (7):
>   perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
>   perf arm-spe: Store TSC parameters in auxtrace info
>   perf arm-spe: Dump TSC parameters
>   perf arm-spe: Convert event kernel time to counter value
>   perf arm-spe: Assign kernel time to synthesized event
>   perf arm-spe: Bail out if the trace is later than perf event
>   perf arm-spe: Don't wait for PERF_RECORD_EXIT event
> 
>  tools/perf/arch/arm64/util/arm-spe.c | 23 +++++++
>  tools/perf/util/arm-spe.c            | 89 +++++++++++++++++++++++-----
>  tools/perf/util/arm-spe.h            |  7 ++-
>  3 files changed, 103 insertions(+), 16 deletions(-)
> 
> --
> 2.25.1



From tony at atomide.com  Tue Apr  6 10:53:49 2021
From: tony at atomide.com (Tony Lindgren)
Date: Tue,  6 Apr 2021 12:53:49 +0300
Subject: [GIT PULL] Few more fixes for omaps for v5.12-rc cycle
Message-ID: <pull-1617702755-711306@atomide.com>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit b3d09a06d89f474cb52664e016849315a97e09d9:

  ARM: OMAP4: PM: update ROM return address for OSWR and OFF (2021-03-17 15:15:52 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.12/fixes-rc6-signed

for you to fetch changes up to fc85dc42a38405099f97aa2af709fe9504a82508:

  ARM: OMAP2+: Fix uninitialized sr_inst (2021-03-31 09:27:41 +0300)

----------------------------------------------------------------
Fixes for omaps for v5.12-rc cycle

Fix swapped mmc device order also for omap3 that got changed with the
recent PROBE_PREFER_ASYNCHRONOUS changes. While eventually the aliases
should be board specific, all the mmc device instances are all there in
the SoC, and we do probe them by default so that PM runtime can idle the
devices if left enabled from the bootloader.

Also included are two compiler warning fixes.

----------------------------------------------------------------
Tony Lindgren (3):
      ARM: OMAP2+: Fix warning for omap_init_time_of()
      ARM: dts: Fix swapped mmc order for omap3
      ARM: OMAP2+: Fix uninitialized sr_inst

 arch/arm/boot/dts/omap3.dtsi        | 3 +++
 arch/arm/mach-omap2/board-generic.c | 2 +-
 arch/arm/mach-omap2/sr_device.c     | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)


From john.garry at huawei.com  Tue Apr  6 10:54:46 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 10:54:46 +0100
Subject: [PATCH v2 1/6] perf metricgroup: Make find_metric() public with
 name change
In-Reply-To: <CAP-5=fVMfK5-rGtx1QjTLz6AQeGr0ruyxuwC3ADt4kriU9wz0A@mail.gmail.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-2-git-send-email-john.garry@huawei.com>
 <CAP-5=fVMfK5-rGtx1QjTLz6AQeGr0ruyxuwC3ADt4kriU9wz0A@mail.gmail.com>
Message-ID: <4b406e70-9ff6-dd26-d9b7-78b094041651@huawei.com>

On 02/04/2021 00:16, Ian Rogers wrote:
> On Thu, Mar 25, 2021 at 3:38 AM John Garry <john.garry at huawei.com> wrote:
>>
>> Function find_metric() is required for the metric processing in the
>> pmu-events testcase, so make it public. Also change the name to include
>> "metricgroup".
> 
> Would it make more sense as "pmu_events_map__find_metric" ?
> 

So all functions apart from one in metricgroup.h are named 
metricgroup__XXX, so I was trying to keep this style - apart from the 
double-underscore (which can be remedied).

Personally I don't think pmu_events_map__find_metric name fits with that 
convention.

Thanks,
John

> Thanks,
> Ian
> 
>> Signed-off-by: John Garry <john.garry at huawei.com>
>> ---
>>   tools/perf/util/metricgroup.c | 5 +++--
>>   tools/perf/util/metricgroup.h | 3 ++-
>>   2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>> index 6acb44ad439b..71a13406e0bd 100644
>> --- a/tools/perf/util/metricgroup.c
>> +++ b/tools/perf/util/metricgroup.c
>> @@ -900,7 +900,8 @@ static int __add_metric(struct list_head *metric_list,
>>                      (match_metric(__pe->metric_group, __metric) ||      \
>>                       match_metric(__pe->metric_name, __metric)))
>>
>> -static struct pmu_event *find_metric(const char *metric, struct pmu_events_map *map)
>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>> +                                        struct pmu_events_map *map)
>>   {
>>          struct pmu_event *pe;
>>          int i;
>> @@ -985,7 +986,7 @@ static int __resolve_metric(struct metric *m,
>>                          struct expr_id *parent;
>>                          struct pmu_event *pe;
>>
>> -                       pe = find_metric(cur->key, map);
>> +                       pe = metrcgroup_find_metric(cur->key, map);
>>                          if (!pe)
>>                                  continue;
>>
>> diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
>> index ed1b9392e624..1674c6a36d74 100644
>> --- a/tools/perf/util/metricgroup.h
>> +++ b/tools/perf/util/metricgroup.h
>> @@ -44,7 +44,8 @@ int metricgroup__parse_groups(const struct option *opt,
>>                                bool metric_no_group,
>>                                bool metric_no_merge,
>>                                struct rblist *metric_events);
>> -
>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>> +                                        struct pmu_events_map *map);
>>   int metricgroup__parse_groups_test(struct evlist *evlist,
>>                                     struct pmu_events_map *map,
>>                                     const char *str,
>> --
>> 2.26.2
>>
> .
> 



From rex-bc.chen at mediatek.com  Tue Apr  6 10:57:39 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Tue, 6 Apr 2021 17:57:39 +0800
Subject: [v3,PATCH 0/3] Convert the mtk_disp driver to aotmic API
Message-ID: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>

Changes since v3:
 - Modify commit message for PATCH 1/3 pwm: mtk_disp: clear the clock operations

Changes since v1:
 - Seperate clock operation as single patch.
 - Seperate apply() as single patch.
 - Seperate get_state() operation as single patch.

Rex-BC Chen (3):
  pwm: mtk_disp: clear the clock operations
  pwm: mtk_disp: convert the driver to atomic API
  pwm: mtk_disp: implement .get_state()

 drivers/pwm/pwm-mtk-disp.c | 179 +++++++++++++++++++++----------------
 1 file changed, 104 insertions(+), 75 deletions(-)

-- 
2.18.0

From rex-bc.chen at mediatek.com  Tue Apr  6 10:57:40 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Tue, 6 Apr 2021 17:57:40 +0800
Subject: [v3,PATCH 1/3] pwm: mtk_disp: clear the clock operations
In-Reply-To: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1617703062-4251-2-git-send-email-rex-bc.chen@mediatek.com>

Remove the clk_prepare from mtk_disp_pwm_probe.
Remove the clk_unprepare from mtk_disp_pwm_remove.

After using atomic API and get_state() function which are implemented in PATCH [2/3], [3/3],
clk_prepare/clk_unprepare are useless in probe/remove function.
So we remove clk_prepare/clk_unprepare in probe/remove fuinction.

Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/pwm/pwm-mtk-disp.c | 23 ++---------------------
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 87c6b4bc5d43..21416a8b6b47 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -192,14 +192,6 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(mdp->clk_mm))
 		return PTR_ERR(mdp->clk_mm);
 
-	ret = clk_prepare(mdp->clk_main);
-	if (ret < 0)
-		return ret;
-
-	ret = clk_prepare(mdp->clk_mm);
-	if (ret < 0)
-		goto disable_clk_main;
-
 	mdp->chip.dev = &pdev->dev;
 	mdp->chip.ops = &mtk_disp_pwm_ops;
 	mdp->chip.base = -1;
@@ -208,7 +200,7 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
 	ret = pwmchip_add(&mdp->chip);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
-		goto disable_clk_mm;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, mdp);
@@ -227,24 +219,13 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
 	}
 
 	return 0;
-
-disable_clk_mm:
-	clk_unprepare(mdp->clk_mm);
-disable_clk_main:
-	clk_unprepare(mdp->clk_main);
-	return ret;
 }
 
 static int mtk_disp_pwm_remove(struct platform_device *pdev)
 {
 	struct mtk_disp_pwm *mdp = platform_get_drvdata(pdev);
-	int ret;
-
-	ret = pwmchip_remove(&mdp->chip);
-	clk_unprepare(mdp->clk_mm);
-	clk_unprepare(mdp->clk_main);
 
-	return ret;
+	return pwmchip_remove(&mdp->chip);
 }
 
 static const struct mtk_pwm_data mt2701_pwm_data = {
-- 
2.18.0

From rex-bc.chen at mediatek.com  Tue Apr  6 10:57:42 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Tue, 6 Apr 2021 17:57:42 +0800
Subject: [v3,PATCH 3/3] pwm: mtk_disp: implement .get_state()
In-Reply-To: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1617703062-4251-4-git-send-email-rex-bc.chen@mediatek.com>

implement get_state function for pwm-mtk-disp

Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/pwm/pwm-mtk-disp.c | 46 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 502228adf718..166e0a8ca703 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -179,8 +179,54 @@ static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	return mtk_disp_pwm_enable(chip, state);
 }
 
+static void mtk_disp_pwm_get_state(struct pwm_chip *chip,
+				   struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
+	u32 clk_div, period, high_width, con0, con1;
+	u64 rate;
+	int err;
+
+	err = clk_prepare_enable(mdp->clk_main);
+	if (err < 0) {
+		dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n", err);
+		return;
+	}
+	err = clk_prepare_enable(mdp->clk_mm);
+	if (err < 0) {
+		dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n", err);
+		clk_disable_unprepare(mdp->clk_main);
+		return;
+	}
+
+	rate = clk_get_rate(mdp->clk_main);
+
+	con0 = readl(mdp->base + mdp->data->con0);
+	con1 = readl(mdp->base + mdp->data->con1);
+
+	state->polarity = con0 & PWM_POLARITY ?
+			  PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
+	state->enabled = !!(con0 & BIT(0));
+
+	clk_div = (con0 & PWM_CLKDIV_MASK) >> PWM_CLKDIV_SHIFT;
+	period = con1 & PWM_PERIOD_MASK;
+	state->period = div_u64(period * (clk_div + 1) * NSEC_PER_SEC, rate);
+	high_width = (con1 & PWM_HIGH_WIDTH_MASK) >> PWM_HIGH_WIDTH_SHIFT;
+	state->duty_cycle = div_u64(high_width * (clk_div + 1) * NSEC_PER_SEC,
+				    rate);
+
+	if (!state->enabled) {
+		clk_disable_unprepare(mdp->clk_mm);
+		clk_disable_unprepare(mdp->clk_main);
+	}
+
+	mdp->enabled = state->enabled;
+}
+
 static const struct pwm_ops mtk_disp_pwm_ops = {
 	.apply = mtk_disp_pwm_apply,
+	.get_state = mtk_disp_pwm_get_state,
 	.owner = THIS_MODULE,
 };
 
-- 
2.18.0

From rex-bc.chen at mediatek.com  Tue Apr  6 10:57:41 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Tue, 6 Apr 2021 17:57:41 +0800
Subject: [v3,PATCH 2/3] pwm: mtk_disp: convert the driver to atomic API
In-Reply-To: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>

Switch the driver to atomic API apply().

Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/pwm/pwm-mtk-disp.c | 114 +++++++++++++++++++------------------
 1 file changed, 58 insertions(+), 56 deletions(-)

diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 21416a8b6b47..502228adf718 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -20,6 +20,7 @@
 #define PWM_CLKDIV_SHIFT	16
 #define PWM_CLKDIV_MAX		0x3ff
 #define PWM_CLKDIV_MASK		(PWM_CLKDIV_MAX << PWM_CLKDIV_SHIFT)
+#define PWM_POLARITY	BIT(2)
 
 #define PWM_PERIOD_BIT_WIDTH	12
 #define PWM_PERIOD_MASK		((1 << PWM_PERIOD_BIT_WIDTH) - 1)
@@ -47,6 +48,7 @@ struct mtk_disp_pwm {
 	struct clk *clk_main;
 	struct clk *clk_mm;
 	void __iomem *base;
+	bool enabled;
 };
 
 static inline struct mtk_disp_pwm *to_mtk_disp_pwm(struct pwm_chip *chip)
@@ -66,11 +68,11 @@ static void mtk_disp_pwm_update_bits(struct mtk_disp_pwm *mdp, u32 offset,
 	writel(value, address);
 }
 
-static int mtk_disp_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
-			       int duty_ns, int period_ns)
+static int mtk_disp_pwm_enable(struct pwm_chip *chip,
+			       const struct pwm_state *state)
 {
 	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
-	u32 clk_div, period, high_width, value;
+	u32 clk_div, period, high_width, value, polarity;
 	u64 div, rate;
 	int err;
 
@@ -84,33 +86,47 @@ static int mtk_disp_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	 * period = (PWM_CLK_RATE * period_ns) / (10^9 * (clk_div + 1)) - 1
 	 * high_width = (PWM_CLK_RATE * duty_ns) / (10^9 * (clk_div + 1))
 	 */
+	if (!mdp->enabled) {
+		err = clk_prepare_enable(mdp->clk_main);
+		if (err < 0) {
+			dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n",
+				err);
+			return err;
+		}
+		err = clk_prepare_enable(mdp->clk_mm);
+		if (err < 0) {
+			dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n",
+				err);
+			clk_disable_unprepare(mdp->clk_main);
+			return err;
+		}
+	}
 	rate = clk_get_rate(mdp->clk_main);
-	clk_div = div_u64(rate * period_ns, NSEC_PER_SEC) >>
+	clk_div = div_u64(rate * state->period, NSEC_PER_SEC) >>
 			  PWM_PERIOD_BIT_WIDTH;
-	if (clk_div > PWM_CLKDIV_MAX)
+	if (clk_div > PWM_CLKDIV_MAX) {
+		dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
+			rate);
+		clk_disable_unprepare(mdp->clk_mm);
+		clk_disable_unprepare(mdp->clk_main);
 		return -EINVAL;
-
+	}
 	div = NSEC_PER_SEC * (clk_div + 1);
-	period = div64_u64(rate * period_ns, div);
+	period = div64_u64(rate * state->period, div);
 	if (period > 0)
 		period--;
 
-	high_width = div64_u64(rate * duty_ns, div);
+	high_width = div64_u64(rate * state->duty_cycle, div);
 	value = period | (high_width << PWM_HIGH_WIDTH_SHIFT);
-
-	err = clk_enable(mdp->clk_main);
-	if (err < 0)
-		return err;
-
-	err = clk_enable(mdp->clk_mm);
-	if (err < 0) {
-		clk_disable(mdp->clk_main);
-		return err;
-	}
+	polarity = 0;
+	if (state->polarity == PWM_POLARITY_INVERSED)
+		polarity = PWM_POLARITY;
 
 	mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
 				 PWM_CLKDIV_MASK,
 				 clk_div << PWM_CLKDIV_SHIFT);
+	mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
+				 PWM_POLARITY, polarity);
 	mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
 				 PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
 				 value);
@@ -122,50 +138,49 @@ static int mtk_disp_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		mtk_disp_pwm_update_bits(mdp, mdp->data->commit,
 					 mdp->data->commit_mask,
 					 0x0);
+	} else {
+		mtk_disp_pwm_update_bits(mdp, mdp->data->bls_debug,
+					 mdp->data->bls_debug_mask,
+					 mdp->data->bls_debug_mask);
+		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
+					 mdp->data->con0_sel,
+					 mdp->data->con0_sel);
 	}
 
-	clk_disable(mdp->clk_mm);
-	clk_disable(mdp->clk_main);
-
+	mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
+				 mdp->data->enable_mask);
+	mdp->enabled = true;
 	return 0;
 }
 
-static int mtk_disp_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int mtk_disp_pwm_disable(struct pwm_chip *chip,
+				const struct pwm_state *state)
 {
 	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
-	int err;
-
-	err = clk_enable(mdp->clk_main);
-	if (err < 0)
-		return err;
 
-	err = clk_enable(mdp->clk_mm);
-	if (err < 0) {
-		clk_disable(mdp->clk_main);
-		return err;
+	mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
+				 0x0);
+	if (mdp->enabled) {
+		clk_disable_unprepare(mdp->clk_mm);
+		clk_disable_unprepare(mdp->clk_main);
 	}
 
-	mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
-				 mdp->data->enable_mask);
+	mdp->enabled = false;
 
 	return 0;
 }
 
-static void mtk_disp_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
 {
-	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
+	if (!state->enabled)
+		return mtk_disp_pwm_disable(chip, state);
 
-	mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
-				 0x0);
-
-	clk_disable(mdp->clk_mm);
-	clk_disable(mdp->clk_main);
+	return mtk_disp_pwm_enable(chip, state);
 }
 
 static const struct pwm_ops mtk_disp_pwm_ops = {
-	.config = mtk_disp_pwm_config,
-	.enable = mtk_disp_pwm_enable,
-	.disable = mtk_disp_pwm_disable,
+	.apply = mtk_disp_pwm_apply,
 	.owner = THIS_MODULE,
 };
 
@@ -205,19 +220,6 @@ static int mtk_disp_pwm_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, mdp);
 
-	/*
-	 * For MT2701, disable double buffer before writing register
-	 * and select manual mode and use PWM_PERIOD/PWM_HIGH_WIDTH.
-	 */
-	if (!mdp->data->has_commit) {
-		mtk_disp_pwm_update_bits(mdp, mdp->data->bls_debug,
-					 mdp->data->bls_debug_mask,
-					 mdp->data->bls_debug_mask);
-		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
-					 mdp->data->con0_sel,
-					 mdp->data->con0_sel);
-	}
-
 	return 0;
 }
 
-- 
2.18.0

From u.kleine-koenig at pengutronix.de  Tue Apr  6 11:07:56 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 6 Apr 2021 12:07:56 +0200
Subject: [v3,PATCH 1/3] pwm: mtk_disp: clear the clock operations
In-Reply-To: <1617703062-4251-2-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
 <1617703062-4251-2-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <20210406100756.ijthlp2j3a3eygdt@pengutronix.de>

Hello,

On Tue, Apr 06, 2021 at 05:57:40PM +0800, Rex-BC Chen wrote:
> Remove the clk_prepare from mtk_disp_pwm_probe.
> Remove the clk_unprepare from mtk_disp_pwm_remove.
> 
> After using atomic API and get_state() function which are implemented
> in PATCH [2/3], [3/3],

Refering to the following patches as 2/3 and 3/3 doesn't make sense once
these patches are applied to a tree.

> clk_prepare/clk_unprepare are useless in probe/remove function.
> So we remove clk_prepare/clk_unprepare in probe/remove fuinction.

Does the driver still work with only this patch applied? If not, please
rearrange and order this patch after the conversion to the atomic API.

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/20210406/1fc6ecd8/attachment.sig>

From tony at atomide.com  Tue Apr  6 11:10:58 2021
From: tony at atomide.com (Tony Lindgren)
Date: Tue,  6 Apr 2021 13:10:58 +0300
Subject: [GIT PULL 1/3] 
Message-ID: <pull-1617703816-65652@atomide.com>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/soc-signed

for you to fetch changes up to 206fa766ca2151d728a0894bdb03688d48564aa0:

  ARM: OMAP1: fix incorrect kernel-doc comment syntax in file (2021-03-31 09:05:42 +0300)

----------------------------------------------------------------
SoC changes for omaps for v5.13

Minor non-urgent fixes for issues found by robots and few typo fixes:

- Use DEFINE_DEBUGFS_ATTRIBUTE

- Add missing of_node_put()

- Use true and false for bool variable

- Use DEFINE_SPINLOCK

- Fix incorrect kerneldoc usage

----------------------------------------------------------------
Aditya Srivastava (2):
      ARM: OMAP2+: fix incorrect kernel-doc comment syntax in file
      ARM: OMAP1: fix incorrect kernel-doc comment syntax in file

Jiapeng Chong (1):
      ARM: OMAP2+: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE

Lifu Chen (1):
      ARM: OMAP2+: Use DEFINE_SPINLOCK() for spinlock

Yang Li (2):
      ARM: OMAP2+: add missing call to of_node_put()
      ARM: OMAP2+: use true and false for bool variable

 arch/arm/mach-omap1/timer.c       |  2 +-
 arch/arm/mach-omap2/omap_hwmod.c  |  1 +
 arch/arm/mach-omap2/omap_twl.c    |  2 +-
 arch/arm/mach-omap2/pm-debug.c    |  4 ++--
 arch/arm/mach-omap2/powerdomain.c | 12 ++++++------
 arch/arm/plat-omap/dma.c          |  3 +--
 6 files changed, 12 insertions(+), 12 deletions(-)


From tony at atomide.com  Tue Apr  6 11:10:59 2021
From: tony at atomide.com (Tony Lindgren)
Date: Tue,  6 Apr 2021 13:10:59 +0300
Subject: [GIT PULL 2/3] 
In-Reply-To: <pull-1617703816-65652@atomide.com>
References: <pull-1617703816-65652@atomide.com>
Message-ID: <pull-1617703816-65652@atomide.com-2>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/dt-v2-signed

for you to fetch changes up to ee368a10d0dfb27bbff36361ea2166f864028a8b:

  ARM: dts: am335x-boneblack.dts: unique gpio-line-names (2021-03-31 08:54:45 +0300)

----------------------------------------------------------------
Devicetree changes for omaps for v5.13

Mostly configures addtional devices for various boards, and
updates the gpio line names for beagle boards so userspace can
optionally find the right lines:

- Use unique gpio line names for am335x-pocketbeagle

- Update omap3-echo led configuration and add ath6kl node

- Fix indentation for am3 tscadc node

- Prepare motorola-cpcap-mapphone for power supply dtbs_check_parsing

- Use unique gpio line names for am335x-boneblack.dts

----------------------------------------------------------------
Andr? Hentschel (2):
      ARM: dts: omap3-echo: Update LED configuration
      ARM: dts: omap3-echo: Add ath6kl node

Dario Binacchi (1):
      ARM: dts: am33xx-l4: fix tscadc at 0 node indentation

Drew Fustini (2):
      ARM: dts: am335x-pocketbeagle: unique gpio-line-names
      ARM: dts: am335x-boneblack.dts: unique gpio-line-names

Sebastian Reichel (1):
      ARM: dts: motorola-cpcap-mapphone: Prepare for dtbs_check parsing

 arch/arm/boot/dts/am335x-boneblack.dts         | 132 +++----
 arch/arm/boot/dts/am335x-pocketbeagle.dts      | 140 ++++----
 arch/arm/boot/dts/am33xx-l4.dtsi               |  28 +-
 arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi |  59 ++-
 arch/arm/boot/dts/omap3-echo.dts               | 476 +++++++++++++++++--------
 5 files changed, 514 insertions(+), 321 deletions(-)


From tony at atomide.com  Tue Apr  6 11:11:00 2021
From: tony at atomide.com (Tony Lindgren)
Date: Tue,  6 Apr 2021 13:11:00 +0300
Subject: [GIT PULL 3/3] 
In-Reply-To: <pull-1617703816-65652@atomide.com>
References: <pull-1617703816-65652@atomide.com>
Message-ID: <pull-1617703816-65652@atomide.com-3>

From: "Tony Lindgren" <tony at atomide.com>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/defconfig-signed

for you to fetch changes up to f6a7ea04ad2044e8f05b55f3bdd3133f468f60d1:

  ARM: omap2plus_defconfig: Add AT25 EEPROM module (2021-03-24 13:46:55 +0200)

----------------------------------------------------------------
Defconfig changes for omaps for v5.13

Update defconfig to have nefilter available as loadable modules
to make the defconfig more usable for networked devices. And we now
select SIMPLE_PM_BUS so it can be dropped. And some devices use
EEPROM_AT25 so let's add it as a loadable module.

----------------------------------------------------------------
Adam Ford (1):
      ARM: omap2plus_defconfig: Add AT25 EEPROM module

Ivan Jelincic (2):
      ARM: omap2plus_defconfig: Update for dropped simple-pm-bus
      ARM: omap2plus_defconfig: Enable Netfilter components as modules

 arch/arm/configs/omap2plus_defconfig | 151 ++++++++++++++++++++++++++++++++++-
 1 file changed, 150 insertions(+), 1 deletion(-)


From Tudor.Ambarus at microchip.com  Tue Apr  6 11:11:53 2021
From: Tudor.Ambarus at microchip.com (Tudor.Ambarus at microchip.com)
Date: Tue, 6 Apr 2021 10:11:53 +0000
Subject: [PATCH -next] dmaengine: at_xdmac: Remove unused inline function
 at_xdmac_csize()
In-Reply-To: <20210406085043.32544-1-yuehaibing@huawei.com>
References: <20210406085043.32544-1-yuehaibing@huawei.com>
Message-ID: <e854d48d-d15b-43f1-07ad-2d545ea94638@microchip.com>

On 4/6/21 11:50 AM, YueHaibing wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
> left behind this, so can remove it.

Checkpatch complains:
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")'

but the change is good:
Reviewed-by: Tudor Ambarus <tudor.ambarus at microchip.com>
> 
> Signed-off-by: YueHaibing <yuehaibing at huawei.com>
> ---
>  drivers/dma/at_xdmac.c | 11 -----------
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index fe45ad5d06c4..64a52bf4d737 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -344,17 +344,6 @@ static inline int at_xdmac_chan_is_paused(struct at_xdmac_chan *atchan)
>         return test_bit(AT_XDMAC_CHAN_IS_PAUSED, &atchan->status);
>  }
> 
> -static inline int at_xdmac_csize(u32 maxburst)
> -{
> -       int csize;
> -
> -       csize = ffs(maxburst) - 1;
> -       if (csize > 4)
> -               csize = -EINVAL;
> -
> -       return csize;
> -};
> -
>  static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
>  {
>         return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
> --
> 2.17.1
> 


From andriy.shevchenko at linux.intel.com  Tue Apr  6 11:13:06 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Tue,  6 Apr 2021 13:13:06 +0300
Subject: [PATCH net-next v1 1/1] stmmac: intel: Drop duplicate ID in the list
 of PCI device IDs
Message-ID: <20210406101306.59162-1-andriy.shevchenko@linux.intel.com>

The PCI device IDs are defined with a prefix PCI_DEVICE_ID.
There is no need to repeat the ID part at the end of each definition.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 60 +++++++++----------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 3d9a57043af2..7f0ce373a63d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -1053,41 +1053,41 @@ static int __maybe_unused intel_eth_pci_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(intel_eth_pm_ops, intel_eth_pci_suspend,
 			 intel_eth_pci_resume);
 
-#define PCI_DEVICE_ID_INTEL_QUARK_ID			0x0937
-#define PCI_DEVICE_ID_INTEL_EHL_RGMII1G_ID		0x4b30
-#define PCI_DEVICE_ID_INTEL_EHL_SGMII1G_ID		0x4b31
-#define PCI_DEVICE_ID_INTEL_EHL_SGMII2G5_ID		0x4b32
+#define PCI_DEVICE_ID_INTEL_QUARK		0x0937
+#define PCI_DEVICE_ID_INTEL_EHL_RGMII1G		0x4b30
+#define PCI_DEVICE_ID_INTEL_EHL_SGMII1G		0x4b31
+#define PCI_DEVICE_ID_INTEL_EHL_SGMII2G5	0x4b32
 /* Intel(R) Programmable Services Engine (Intel(R) PSE) consist of 2 MAC
  * which are named PSE0 and PSE1
  */
-#define PCI_DEVICE_ID_INTEL_EHL_PSE0_RGMII1G_ID		0x4ba0
-#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII1G_ID		0x4ba1
-#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII2G5_ID	0x4ba2
-#define PCI_DEVICE_ID_INTEL_EHL_PSE1_RGMII1G_ID		0x4bb0
-#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII1G_ID		0x4bb1
-#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII2G5_ID	0x4bb2
-#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_0_ID		0x43ac
-#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_1_ID		0x43a2
-#define PCI_DEVICE_ID_INTEL_TGL_SGMII1G_ID		0xa0ac
-#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_0_ID		0x7aac
-#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_1_ID		0x7aad
+#define PCI_DEVICE_ID_INTEL_EHL_PSE0_RGMII1G	0x4ba0
+#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII1G	0x4ba1
+#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII2G5	0x4ba2
+#define PCI_DEVICE_ID_INTEL_EHL_PSE1_RGMII1G	0x4bb0
+#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII1G	0x4bb1
+#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII2G5	0x4bb2
+#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_0	0x43ac
+#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_1	0x43a2
+#define PCI_DEVICE_ID_INTEL_TGL_SGMII1G		0xa0ac
+#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_0	0x7aac
+#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_1	0x7aad
 
 static const struct pci_device_id intel_eth_pci_id_table[] = {
-	{ PCI_DEVICE_DATA(INTEL, QUARK_ID, &quark_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_RGMII1G_ID, &ehl_rgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII1G_ID, &ehl_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII2G5_ID, &ehl_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_RGMII1G_ID, &ehl_pse0_rgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII1G_ID, &ehl_pse0_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII2G5_ID, &ehl_pse0_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_RGMII1G_ID, &ehl_pse1_rgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII1G_ID, &ehl_pse1_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII2G5_ID, &ehl_pse1_sgmii1g_info) },
-	{ PCI_DEVICE_DATA(INTEL, TGL_SGMII1G_ID, &tgl_sgmii1g_phy0_info) },
-	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_0_ID, &tgl_sgmii1g_phy0_info) },
-	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_1_ID, &tgl_sgmii1g_phy1_info) },
-	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_0_ID, &adls_sgmii1g_phy0_info) },
-	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_1_ID, &adls_sgmii1g_phy1_info) },
+	{ PCI_DEVICE_DATA(INTEL, QUARK, &quark_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_RGMII1G, &ehl_rgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII1G, &ehl_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII2G5, &ehl_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_RGMII1G, &ehl_pse0_rgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII1G, &ehl_pse0_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII2G5, &ehl_pse0_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_RGMII1G, &ehl_pse1_rgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII1G, &ehl_pse1_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII2G5, &ehl_pse1_sgmii1g_info) },
+	{ PCI_DEVICE_DATA(INTEL, TGL_SGMII1G, &tgl_sgmii1g_phy0_info) },
+	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_0, &tgl_sgmii1g_phy0_info) },
+	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_1, &tgl_sgmii1g_phy1_info) },
+	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_0, &adls_sgmii1g_phy0_info) },
+	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_1, &adls_sgmii1g_phy1_info) },
 	{}
 };
 MODULE_DEVICE_TABLE(pci, intel_eth_pci_id_table);
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Tue Apr  6 11:19:36 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 6 Apr 2021 12:19:36 +0200
Subject: [v3,PATCH 2/3] pwm: mtk_disp: convert the driver to atomic API
In-Reply-To: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
 <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <20210406101936.uscvtvrd6opm5pgf@pengutronix.de>

Hello,

On Tue, Apr 06, 2021 at 05:57:41PM +0800, Rex-BC Chen wrote:
> @@ -84,33 +86,47 @@ static int mtk_disp_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>  	 * period = (PWM_CLK_RATE * period_ns) / (10^9 * (clk_div + 1)) - 1
>  	 * high_width = (PWM_CLK_RATE * duty_ns) / (10^9 * (clk_div + 1))
>  	 */
> +	if (!mdp->enabled) {
> +		err = clk_prepare_enable(mdp->clk_main);
> +		if (err < 0) {
> +			dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n",
> +				err);

Please use %pe, as this yields better readable error messages.

Also it might be sensible to first use the fact that (without patch 1
from this series) the clocks are always on and then rework the clk usage
in a separate patch.

> +			return err;
> +		}
> +		err = clk_prepare_enable(mdp->clk_mm);
> +		if (err < 0) {
> +			dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n",
> +				err);
> +			clk_disable_unprepare(mdp->clk_main);
> +			return err;
> +		}
> +	}
>  	rate = clk_get_rate(mdp->clk_main);
> -	clk_div = div_u64(rate * period_ns, NSEC_PER_SEC) >>
> +	clk_div = div_u64(rate * state->period, NSEC_PER_SEC) >>
>  			  PWM_PERIOD_BIT_WIDTH;

rate * state->period might overflow, it would be great if this could be
catched. (But I don't consider this a stopper for this series.)

> -	if (clk_div > PWM_CLKDIV_MAX)
> +	if (clk_div > PWM_CLKDIV_MAX) {
> +		dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
> +			rate);

rate is an u64, %d isn't the right format for it. Doesn't this result in
a compiler warning?

> +		clk_disable_unprepare(mdp->clk_mm);
> +		clk_disable_unprepare(mdp->clk_main);
>  		return -EINVAL;
> -
> +	}
>  	div = NSEC_PER_SEC * (clk_div + 1);
> -	period = div64_u64(rate * period_ns, div);
> +	period = div64_u64(rate * state->period, div);
>  	if (period > 0)
>  		period--;
>  
> -	high_width = div64_u64(rate * duty_ns, div);
> +	high_width = div64_u64(rate * state->duty_cycle, div);
>  	value = period | (high_width << PWM_HIGH_WIDTH_SHIFT);
> -
> -	err = clk_enable(mdp->clk_main);
> -	if (err < 0)
> -		return err;
> -
> -	err = clk_enable(mdp->clk_mm);
> -	if (err < 0) {
> -		clk_disable(mdp->clk_main);
> -		return err;
> -	}
> +	polarity = 0;
> +	if (state->polarity == PWM_POLARITY_INVERSED)
> +		polarity = PWM_POLARITY;

I'm unsure if support for polarity should be added en passant in this
patch. Maybe it would be clearer to add is separately.

>  	mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
>  				 PWM_CLKDIV_MASK,
>  				 clk_div << PWM_CLKDIV_SHIFT);
> +	mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
> +				 PWM_POLARITY, polarity);
>  	mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
>  				 PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
>  				 value);

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/20210406/45cb0480/attachment.sig>

From andriy.shevchenko at linux.intel.com  Tue Apr  6 11:22:51 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Tue,  6 Apr 2021 13:22:51 +0300
Subject: [PATCH v2 1/1] time64.h: Consolidated PSEC_PER_SEC definition
Message-ID: <20210406102251.60301-1-andriy.shevchenko@linux.intel.com>

We have currently three users of the PSEC_PER_SEC each of them defining it
individually. Instead, move it to time64.h to be available for everyone.

There is a new user coming with the same constant in use. It will also
make its life easier.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Acked-by: Heiko Stuebner <heiko at sntech.de>
---
v2: added tag (Heiko), rebased on top of newest rc

Since it touches PHY stuff, I assume that the PHY tree is the best
to suck this.

 drivers/net/ethernet/mscc/ocelot_ptp.c           | 2 ++
 drivers/phy/phy-core-mipi-dphy.c                 | 2 --
 drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c | 8 ++++----
 include/soc/mscc/ocelot_ptp.h                    | 2 --
 include/vdso/time64.h                            | 1 +
 5 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot_ptp.c b/drivers/net/ethernet/mscc/ocelot_ptp.c
index a33ab315cc6b..87ad2137ba06 100644
--- a/drivers/net/ethernet/mscc/ocelot_ptp.c
+++ b/drivers/net/ethernet/mscc/ocelot_ptp.c
@@ -4,6 +4,8 @@
  * Copyright (c) 2017 Microsemi Corporation
  * Copyright 2020 NXP
  */
+#include <linux/time64.h>
+
 #include <soc/mscc/ocelot_ptp.h>
 #include <soc/mscc/ocelot_sys.h>
 #include <soc/mscc/ocelot.h>
diff --git a/drivers/phy/phy-core-mipi-dphy.c b/drivers/phy/phy-core-mipi-dphy.c
index 14e0551cd319..77fe65367ce5 100644
--- a/drivers/phy/phy-core-mipi-dphy.c
+++ b/drivers/phy/phy-core-mipi-dphy.c
@@ -12,8 +12,6 @@
 #include <linux/phy/phy.h>
 #include <linux/phy/phy-mipi-dphy.h>
 
-#define PSEC_PER_SEC	1000000000000LL
-
 /*
  * Minimum D-PHY timings based on MIPI D-PHY specification. Derived
  * from the valid ranges specified in Section 6.9, Table 14, Page 41
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
index 8af8c6c5cc02..347dc79a18c1 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c
@@ -11,16 +11,16 @@
 #include <linux/clk-provider.h>
 #include <linux/delay.h>
 #include <linux/init.h>
+#include <linux/mfd/syscon.h>
 #include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/reset.h>
+#include <linux/time64.h>
+
 #include <linux/phy/phy.h>
 #include <linux/phy/phy-mipi-dphy.h>
-#include <linux/pm_runtime.h>
-#include <linux/mfd/syscon.h>
-
-#define PSEC_PER_SEC	1000000000000LL
 
 #define UPDATE(x, h, l)	(((x) << (l)) & GENMASK((h), (l)))
 
diff --git a/include/soc/mscc/ocelot_ptp.h b/include/soc/mscc/ocelot_ptp.h
index 6a7388fa7cc5..ded497d72bdb 100644
--- a/include/soc/mscc/ocelot_ptp.h
+++ b/include/soc/mscc/ocelot_ptp.h
@@ -37,8 +37,6 @@ enum {
 
 #define PTP_CFG_MISC_PTP_EN		BIT(2)
 
-#define PSEC_PER_SEC			1000000000000LL
-
 #define PTP_CFG_CLK_ADJ_CFG_ENA		BIT(0)
 #define PTP_CFG_CLK_ADJ_CFG_DIR		BIT(1)
 
diff --git a/include/vdso/time64.h b/include/vdso/time64.h
index 9d43c3f5e89d..b40cfa2aa33c 100644
--- a/include/vdso/time64.h
+++ b/include/vdso/time64.h
@@ -9,6 +9,7 @@
 #define NSEC_PER_MSEC	1000000L
 #define USEC_PER_SEC	1000000L
 #define NSEC_PER_SEC	1000000000L
+#define PSEC_PER_SEC	1000000000000LL
 #define FSEC_PER_SEC	1000000000000000LL
 
 #endif /* __VDSO_TIME64_H */
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Tue Apr  6 11:27:56 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 6 Apr 2021 12:27:56 +0200
Subject: [v3,PATCH 3/3] pwm: mtk_disp: implement .get_state()
In-Reply-To: <1617703062-4251-4-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
 <1617703062-4251-4-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <20210406102756.4kncasxe4um3q6wi@pengutronix.de>

On Tue, Apr 06, 2021 at 05:57:42PM +0800, Rex-BC Chen wrote:
> implement get_state function for pwm-mtk-disp
> 
> Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>

Ideally you S-o-b line is the last one to show the order in which this
patch went from one person to another.

> ---
>  drivers/pwm/pwm-mtk-disp.c | 46 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
> index 502228adf718..166e0a8ca703 100644
> --- a/drivers/pwm/pwm-mtk-disp.c
> +++ b/drivers/pwm/pwm-mtk-disp.c
> @@ -179,8 +179,54 @@ static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  	return mtk_disp_pwm_enable(chip, state);
>  }
>  
> +static void mtk_disp_pwm_get_state(struct pwm_chip *chip,
> +				   struct pwm_device *pwm,
> +				   struct pwm_state *state)
> +{
> +	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
> +	u32 clk_div, period, high_width, con0, con1;
> +	u64 rate;
> +	int err;
> +
> +	err = clk_prepare_enable(mdp->clk_main);
> +	if (err < 0) {
> +		dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n", err);
> +		return;
> +	}
> +	err = clk_prepare_enable(mdp->clk_mm);
> +	if (err < 0) {
> +		dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n", err);
> +		clk_disable_unprepare(mdp->clk_main);

As before: %pe please

> +		return;
> +	}
> +
> +	rate = clk_get_rate(mdp->clk_main);
> +
> +	con0 = readl(mdp->base + mdp->data->con0);
> +	con1 = readl(mdp->base + mdp->data->con1);
> +
> +	state->polarity = con0 & PWM_POLARITY ?
> +			  PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
> +	state->enabled = !!(con0 & BIT(0));
> +
> +	clk_div = (con0 & PWM_CLKDIV_MASK) >> PWM_CLKDIV_SHIFT;
> +	period = con1 & PWM_PERIOD_MASK;
> +	state->period = div_u64(period * (clk_div + 1) * NSEC_PER_SEC, rate);
> +	high_width = (con1 & PWM_HIGH_WIDTH_MASK) >> PWM_HIGH_WIDTH_SHIFT;
> +	state->duty_cycle = div_u64(high_width * (clk_div + 1) * NSEC_PER_SEC,
> +				    rate);

Please round up these divisions as in .apply() we're rounding down.
Otherwise .get_state isn't the inverse of .apply().

> +
> +	if (!state->enabled) {
> +		clk_disable_unprepare(mdp->clk_mm);
> +		clk_disable_unprepare(mdp->clk_main);

That's wrong, you enabled unconditionally so you should also disable
unconditionally. If you want to prevent that clocks of a running PWM are
disabled by the unused clk initcall, this must be done in .probe() to be
sure it runs exactly once and early enough.

> +	}
> +
> +	mdp->enabled = state->enabled;
> +}
> +

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/20210406/50765544/attachment.sig>

From tjoseph at cadence.com  Tue Apr  6 11:31:48 2021
From: tjoseph at cadence.com (Tom Joseph)
Date: Tue, 6 Apr 2021 10:31:48 +0000
Subject: [PATCH v4 5/7] PCI: cadence: Add support to configure virtual
 functions
In-Reply-To: <20210310160943.7606-6-kishon@ti.com>
References: <20210310160943.7606-1-kishon@ti.com>
 <20210310160943.7606-6-kishon@ti.com>
Message-ID: <MN2PR07MB6208CFBF96B74CA8531E21CCA1769@MN2PR07MB6208.namprd07.prod.outlook.com>


> -----Original Message-----
> From: Kishon Vijay Abraham I <kishon at ti.com>
> Sent: 10 March 2021 16:10
> 
> Now that support for SR-IOV is added in PCIe endpoint core, add support
> to configure virtual functions in the Cadence PCIe EP driver.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  .../pci/controller/cadence/pcie-cadence-ep.c  | 207 ++++++++++++++++--
>  drivers/pci/controller/cadence/pcie-cadence.h |   7 +
>  2 files changed, 197 insertions(+), 17 deletions(-)
> 
Acked-by: Tom Joseph <tjoseph at cadence.com>


From geert at linux-m68k.org  Tue Apr  6 11:32:13 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 6 Apr 2021 12:32:13 +0200
Subject: [PATCH 4/9] sh: intc: Drop the use of
 irq_create_identity_mapping()
In-Reply-To: <20210406093557.1073423-5-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-5-maz@kernel.org>
Message-ID: <CAMuHMdU3vo1AWuDr69WK8-1w38+Q7KturAoL=cFpspZiYr2ssA@mail.gmail.com>

Hi Marc,

On Tue, Apr 6, 2021 at 11:44 AM Marc Zyngier <maz at kernel.org> wrote:
> Instead of playing games with using irq_create_identity_mapping()
> and irq_domain_associate(), drop the use of the former and only
> use the latter, together with the allocation of the irq_desc
> as needed.
>
> It doesn't make the code less awful, but at least the intent
> is clearer.
>
> Signed-off-by: Marc Zyngier <maz at kernel.org>

Thanks for your patch!

> --- a/drivers/sh/intc/core.c
> +++ b/drivers/sh/intc/core.c
> @@ -179,6 +179,23 @@ static unsigned int __init save_reg(struct intc_desc_int *d,
>         return 0;
>  }
>
> +static bool __init intc_map(struct irq_domain *domain, int irq)
> +{
> +       int res;

warning: unused variable ?res? [-Wunused-variable]

> +
> +       if (!irq_to_desc(irq) && irq_alloc_desc_at(irq, NUMA_NO_NODE) != irq) {
> +               pr_err("uname to allocate IRQ %d\n", irq);
> +               return false;
> +       }
> +
> +       if (irq_domain_associate(domain, irq, irq)) {
> +               pr_err("domain association failure\n");
> +               return false;
> +       }
> +
> +       return true;
> +}
> +
>  int __init register_intc_controller(struct intc_desc *desc)
>  {
>         unsigned int i, k, smp;
> @@ -316,19 +333,8 @@ int __init register_intc_controller(struct intc_desc *desc)

warning: unused variable ?res? [-Wunused-variable]

>                 if (!vect->enum_id)
>                         continue;
>
> -               res = irq_create_identity_mapping(d->domain, irq);


> -               if (unlikely(res)) {
> -                       if (res == -EEXIST) {
> -                               res = irq_domain_associate(d->domain, irq, irq);
> -                               if (unlikely(res)) {
> -                                       pr_err("domain association failure\n");
> -                                       continue;
> -                               }
> -                       } else {
> -                               pr_err("can't identity map IRQ %d\n", irq);
> -                               continue;
> -                       }
> -               }
> +               if (!intc_map(d->domain, irq))
> +                       continue;
>
>                 intc_irq_xlate_set(irq, vect->enum_id, d);
>                 intc_register_irq(desc, d, vect->enum_id, irq);

Otherwise this seems to work fine on real hardware (landisk) and qemu
(rts7751r2d).  I did verify that the new function intc_map() is called.

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 hverkuil-cisco at xs4all.nl  Tue Apr  6 11:46:44 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 6 Apr 2021 12:46:44 +0200
Subject: [PATCH v4,2/3] arm64: dts: mt8173: Separating mtk-vcodec-enc
 device node
In-Reply-To: <20210325122625.15100-2-irui.wang@mediatek.com>
References: <20210325122625.15100-1-irui.wang@mediatek.com>
 <20210325122625.15100-2-irui.wang@mediatek.com>
Message-ID: <245594e6-a4c9-0f53-58e3-1b32ca6dc651@xs4all.nl>

Hi Irui,

On 25/03/2021 13:26, Irui Wang wrote:
> There are two separate hardware encoder blocks inside MT8173.
> Split the current mtk-vcodec-enc node to match the hardware architecture.

I've accepted patches 1 & 3, so this patch can be merged by whoever maintains these dts
files.

Regards,

	Hans

> 
> Acked-by: Tiffany Lin <tiffany.lin at mediatek.com>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Signed-off-by: Maoguang Meng <maoguang.meng at mediatek.com>
> Signed-off-by: Irui Wang <irui.wang at mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 60 ++++++++++++------------
>  1 file changed, 31 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 7fa870e4386a..f5950e9fc51d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -1458,14 +1458,11 @@
>  			clock-names = "apb", "smi";
>  		};
>  
> -		vcodec_enc: vcodec at 18002000 {
> +		vcodec_enc_avc: vcodec at 18002000 {
>  			compatible = "mediatek,mt8173-vcodec-enc";
> -			reg = <0 0x18002000 0 0x1000>,	/* VENC_SYS */
> -			      <0 0x19002000 0 0x1000>;	/* VENC_LT_SYS */
> -			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
> -				     <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
> -			mediatek,larb = <&larb3>,
> -					<&larb5>;
> +			reg = <0 0x18002000 0 0x1000>;	/* VENC_SYS */
> +			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
> +			mediatek,larb = <&larb3>;
>  			iommus = <&iommu M4U_PORT_VENC_RCPU>,
>  				 <&iommu M4U_PORT_VENC_REC>,
>  				 <&iommu M4U_PORT_VENC_BSDMA>,
> @@ -1476,29 +1473,12 @@
>  				 <&iommu M4U_PORT_VENC_REF_LUMA>,
>  				 <&iommu M4U_PORT_VENC_REF_CHROMA>,
>  				 <&iommu M4U_PORT_VENC_NBM_RDMA>,
> -				 <&iommu M4U_PORT_VENC_NBM_WDMA>,
> -				 <&iommu M4U_PORT_VENC_RCPU_SET2>,
> -				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> -				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
> -				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
> +				 <&iommu M4U_PORT_VENC_NBM_WDMA>;
>  			mediatek,vpu = <&vpu>;
> -			clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
> -				 <&topckgen CLK_TOP_VENC_SEL>,
> -				 <&topckgen CLK_TOP_UNIVPLL1_D2>,
> -				 <&topckgen CLK_TOP_VENC_LT_SEL>;
> -			clock-names = "venc_sel_src",
> -				      "venc_sel",
> -				      "venc_lt_sel_src",
> -				      "venc_lt_sel";
> -			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
> -					  <&topckgen CLK_TOP_VENC_LT_SEL>;
> -			assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>,
> -						 <&topckgen CLK_TOP_VCODECPLL_370P5>;
> +			clocks = <&topckgen CLK_TOP_VENC_SEL>;
> +			clock-names = "venc_sel";
> +			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
> +			assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
>  		};
>  
>  		jpegdec: jpegdec at 18004000 {
> @@ -1530,5 +1510,27 @@
>  				 <&vencltsys CLK_VENCLT_CKE0>;
>  			clock-names = "apb", "smi";
>  		};
> +
> +		vcodec_enc_vp8: vcodec at 19002000 {
> +			compatible = "mediatek,mt8173-vcodec-enc-vp8";
> +			reg =  <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
> +			interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
> +			iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
> +				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> +				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
> +				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
> +			mediatek,larb = <&larb5>;
> +			mediatek,vpu = <&vpu>;
> +			clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
> +			clock-names = "venc_lt_sel";
> +			assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
> +			assigned-clock-parents =
> +				 <&topckgen CLK_TOP_VCODECPLL_370P5>;
> +		};
>  	};
>  };
> 



From nsaenz at kernel.org  Tue Apr  6 11:47:59 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Tue,  6 Apr 2021 12:47:59 +0200
Subject: [PATCH 0/3] BCM2711 sdhci-iproc improvements
Message-ID: <20210406104802.20898-1-nsaenz@kernel.org>

This is a follow-up series to "BCM2711's sdhci-iproc CMD timeouts"[1],
but since much most of the patches changed I decided to start counting
patch revisions from scratch.

This series tries to address rather odd behavior from BCM2711's
integration of sdhci-iproc (Raspberry Pi 4's SoC). The controller will
timeout on SDHCI CMDs under the following conditions:

 - No SD card plugged in (the card polling thread is running, CD irq disabled).
 - BCM2711's VPU clock configured at 500MHz or more, lower clocks are OK.

There is no specific command that will time out, it seems random.

As an extra to this I also include a small fix, and convert the
controller's bindings to yaml.

Regards,
Nicolas

[1] https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz at kernel.org/

---

Nicolas Saenz Julienne (3):
  dt-bindings: mmc: iproc-sdhci: Convert to json-schema
  mmc: sdhci-iproc: Cap min clock frequency on BCM2711
  mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN on BCM2711

 .../bindings/mmc/brcm,iproc-sdhci.yaml        | 63 +++++++++++++++++++
 .../bindings/mmc/brcm,sdhci-iproc.txt         | 37 -----------
 drivers/mmc/host/sdhci-iproc.c                | 21 ++++++-
 3 files changed, 83 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
 delete mode 100644 Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt

-- 
2.30.2



From nsaenz at kernel.org  Tue Apr  6 11:48:01 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Tue,  6 Apr 2021 12:48:01 +0200
Subject: [PATCH 1/3] dt-bindings: mmc: iproc-sdhci: Convert to json-schema
In-Reply-To: <20210406104802.20898-1-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
Message-ID: <20210406104802.20898-2-nsaenz@kernel.org>

Convert the brcm,iproc-sdhci binding to DT schema format using json-schema

Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>

---

 .../bindings/mmc/brcm,iproc-sdhci.yaml        | 63 +++++++++++++++++++
 .../bindings/mmc/brcm,sdhci-iproc.txt         | 37 -----------
 2 files changed, 63 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
 delete mode 100644 Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt

diff --git a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
new file mode 100644
index 000000000000..6f569fbfa134
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/brcm,iproc-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom IPROC SDHCI controller
+
+maintainers:
+  - Ray Jui <ray.jui at broadcom.com>
+  - Scott Branden <scott.branden at broadcom.com>
+  - Nicolas Saenz Julienne <nsaenz at kernel.org>
+
+allOf:
+  - $ref: mmc-controller.yaml#
+
+properties:
+  compatible:
+    enum:
+      - brcm,bcm2835-sdhci
+      - brcm,bcm2711-emmc2
+      - brcm,sdhci-iproc-cygnus
+      - brcm,sdhci-iproc
+
+  reg:
+    minItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description:
+      Handle to core clock for the sdhci controller.
+
+  sdhci,auto-cmd12:
+    type: boolean
+    description: Specifies that controller should use auto CMD12
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/bcm-cygnus.h>
+
+    mmc at 18041000 {
+      compatible = "brcm,sdhci-iproc-cygnus";
+      reg = <0x18041000 0x100>;
+      interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+      clocks = <&lcpll0_clks BCM_CYGNUS_LCPLL0_SDIO_CLK>;
+      bus-width = <4>;
+      sdhci,auto-cmd12;
+      no-1-8-v;
+    };
+...
diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
deleted file mode 100644
index 09d87cc1182a..000000000000
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-Broadcom IPROC SDHCI controller
-
-This file documents differences between the core properties described
-by mmc.txt and the properties that represent the IPROC SDHCI controller.
-
-Required properties:
-- compatible : Should be one of the following
-	       "brcm,bcm2835-sdhci"
-	       "brcm,bcm2711-emmc2"
-	       "brcm,sdhci-iproc-cygnus"
-	       "brcm,sdhci-iproc"
-
-Use brcm2835-sdhci for the eMMC controller on the BCM2835 (Raspberry Pi) and
-bcm2711-emmc2 for the additional eMMC2 controller on BCM2711.
-
-Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
-restricted to 32bit host accesses to SDHCI registers.
-
-Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
-8, 16, 32-bit host access to SDHCI register.
-
-- clocks : The clock feeding the SDHCI controller.
-
-Optional properties:
-  - sdhci,auto-cmd12: specifies that controller should use auto CMD12.
-
-Example:
-
-sdhci0: sdhci at 18041000 {
-	compatible = "brcm,sdhci-iproc-cygnus";
-	reg = <0x18041000 0x100>;
-	interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
-	clocks = <&lcpll0_clks BCM_CYGNUS_LCPLL0_SDIO_CLK>;
-	bus-width = <4>;
-	sdhci,auto-cmd12;
-	no-1-8-v;
-};
-- 
2.30.2



From nsaenz at kernel.org  Tue Apr  6 11:48:03 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Tue,  6 Apr 2021 12:48:03 +0200
Subject: [PATCH 2/3] mmc: sdhci-iproc: Cap min clock frequency on BCM2711
In-Reply-To: <20210406104802.20898-1-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
Message-ID: <20210406104802.20898-3-nsaenz@kernel.org>

There is a known bug on BCM2711's SDHCI core integration where the
controller will hang when the difference between the core clock and the
bus clock is too great. Specifically this can be reproduced under the
following conditions:

- No SD card plugged in, polling thread is running, probing cards at
  100KHz.
- BCM2711's core clock configured at 500MHz or more.

So set 200MHz as the minimum clock frequency available for that board.

For more information on the issue see this:
https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz at kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca

Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
---
 drivers/mmc/host/sdhci-iproc.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index ddeaf8e1f72f..1ef888e91f73 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -173,6 +173,23 @@ static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host)
 		return pltfm_host->clock;
 }
 
+/*
+ * There is a known bug on BCM2711's SDHCI core integration where the
+ * controller will hang when the difference between the core clock and the bus
+ * clock is too great. Specifically this can be reproduced under the following
+ * conditions:
+ *
+ *  - No SD card plugged in, polling thread is running, probing cards at
+ *    100KHz.
+ *  - BCM2711's core clock configured at 500MHz or more
+ *
+ * So we set 200MHz as the minimum clock frequency available for that SoC.
+ */
+static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host *host)
+{
+	return 200000;
+}
+
 static const struct sdhci_ops sdhci_iproc_ops = {
 	.set_clock = sdhci_set_clock,
 	.get_max_clock = sdhci_iproc_get_max_clock,
@@ -271,6 +288,7 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
 	.set_clock = sdhci_set_clock,
 	.set_power = sdhci_set_power_and_bus_voltage,
 	.get_max_clock = sdhci_iproc_get_max_clock,
+	.get_min_clock = sdhci_iproc_bcm2711_get_min_clock,
 	.set_bus_width = sdhci_set_bus_width,
 	.reset = sdhci_reset,
 	.set_uhs_signaling = sdhci_set_uhs_signaling,
-- 
2.30.2



From nsaenz at kernel.org  Tue Apr  6 11:48:05 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Tue,  6 Apr 2021 12:48:05 +0200
Subject: [PATCH 3/3] mmc: sdhci-iproc: Set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN
 on BCM2711
In-Reply-To: <20210406104802.20898-1-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
Message-ID: <20210406104802.20898-4-nsaenz@kernel.org>

The controller doesn't seem to pick-up on clock changes, so set the
SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN flag to query the clock frequency
directly from the clock.

Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
---
 drivers/mmc/host/sdhci-iproc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 1ef888e91f73..31f61ea474f0 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -295,7 +295,8 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
 };
 
 static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = {
-	.quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
+	.quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 |
+		  SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
 	.ops = &sdhci_iproc_bcm2711_ops,
 };
 
-- 
2.30.2



From matthias.bgg at gmail.com  Tue Apr  6 11:50:15 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 12:50:15 +0200
Subject: [PATCH v4,2/3] arm64: dts: mt8173: Separating mtk-vcodec-enc
 device node
In-Reply-To: <245594e6-a4c9-0f53-58e3-1b32ca6dc651@xs4all.nl>
References: <20210325122625.15100-1-irui.wang@mediatek.com>
 <20210325122625.15100-2-irui.wang@mediatek.com>
 <245594e6-a4c9-0f53-58e3-1b32ca6dc651@xs4all.nl>
Message-ID: <dd87cbf6-1c79-63e1-a92e-7831eaa63f52@gmail.com>



On 06/04/2021 12:46, Hans Verkuil wrote:
> Hi Irui,
> 
> On 25/03/2021 13:26, Irui Wang wrote:
>> There are two separate hardware encoder blocks inside MT8173.
>> Split the current mtk-vcodec-enc node to match the hardware architecture.
> 
> I've accepted patches 1 & 3, so this patch can be merged by whoever maintains these dts
> files.

Thanks for the info, patch 2 is now part of v5.12-next/dts64-2

Regards,
Matthias

> 
> Regards,
> 
> 	Hans
> 
>>
>> Acked-by: Tiffany Lin <tiffany.lin at mediatek.com>
>> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
>> Signed-off-by: Maoguang Meng <maoguang.meng at mediatek.com>
>> Signed-off-by: Irui Wang <irui.wang at mediatek.com>
>> ---
>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 60 ++++++++++++------------
>>  1 file changed, 31 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 7fa870e4386a..f5950e9fc51d 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -1458,14 +1458,11 @@
>>  			clock-names = "apb", "smi";
>>  		};
>>  
>> -		vcodec_enc: vcodec at 18002000 {
>> +		vcodec_enc_avc: vcodec at 18002000 {
>>  			compatible = "mediatek,mt8173-vcodec-enc";
>> -			reg = <0 0x18002000 0 0x1000>,	/* VENC_SYS */
>> -			      <0 0x19002000 0 0x1000>;	/* VENC_LT_SYS */
>> -			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
>> -				     <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
>> -			mediatek,larb = <&larb3>,
>> -					<&larb5>;
>> +			reg = <0 0x18002000 0 0x1000>;	/* VENC_SYS */
>> +			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
>> +			mediatek,larb = <&larb3>;
>>  			iommus = <&iommu M4U_PORT_VENC_RCPU>,
>>  				 <&iommu M4U_PORT_VENC_REC>,
>>  				 <&iommu M4U_PORT_VENC_BSDMA>,
>> @@ -1476,29 +1473,12 @@
>>  				 <&iommu M4U_PORT_VENC_REF_LUMA>,
>>  				 <&iommu M4U_PORT_VENC_REF_CHROMA>,
>>  				 <&iommu M4U_PORT_VENC_NBM_RDMA>,
>> -				 <&iommu M4U_PORT_VENC_NBM_WDMA>,
>> -				 <&iommu M4U_PORT_VENC_RCPU_SET2>,
>> -				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
>> -				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
>> -				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
>> +				 <&iommu M4U_PORT_VENC_NBM_WDMA>;
>>  			mediatek,vpu = <&vpu>;
>> -			clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
>> -				 <&topckgen CLK_TOP_VENC_SEL>,
>> -				 <&topckgen CLK_TOP_UNIVPLL1_D2>,
>> -				 <&topckgen CLK_TOP_VENC_LT_SEL>;
>> -			clock-names = "venc_sel_src",
>> -				      "venc_sel",
>> -				      "venc_lt_sel_src",
>> -				      "venc_lt_sel";
>> -			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>,
>> -					  <&topckgen CLK_TOP_VENC_LT_SEL>;
>> -			assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>,
>> -						 <&topckgen CLK_TOP_VCODECPLL_370P5>;
>> +			clocks = <&topckgen CLK_TOP_VENC_SEL>;
>> +			clock-names = "venc_sel";
>> +			assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
>> +			assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
>>  		};
>>  
>>  		jpegdec: jpegdec at 18004000 {
>> @@ -1530,5 +1510,27 @@
>>  				 <&vencltsys CLK_VENCLT_CKE0>;
>>  			clock-names = "apb", "smi";
>>  		};
>> +
>> +		vcodec_enc_vp8: vcodec at 19002000 {
>> +			compatible = "mediatek,mt8173-vcodec-enc-vp8";
>> +			reg =  <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
>> +			interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
>> +			iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
>> +				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
>> +				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
>> +				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
>> +			mediatek,larb = <&larb5>;
>> +			mediatek,vpu = <&vpu>;
>> +			clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
>> +			clock-names = "venc_lt_sel";
>> +			assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
>> +			assigned-clock-parents =
>> +				 <&topckgen CLK_TOP_VCODECPLL_370P5>;
>> +		};
>>  	};
>>  };
>>
> 


From matthias.bgg at gmail.com  Tue Apr  6 11:53:10 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 12:53:10 +0200
Subject: [PATCH v2 1/8] dt-bindings: timer: Add compatible for Mediatek
 MT8195
In-Reply-To: <11bf6761-8902-bfa5-8577-d397846e7638@linaro.org>
References: <20210319023427.16711-1-seiya.wang@mediatek.com>
 <20210319023427.16711-3-seiya.wang@mediatek.com>
 <bf7ad31e-974a-3e0a-12bd-32973c7c3cbd@gmail.com>
 <11bf6761-8902-bfa5-8577-d397846e7638@linaro.org>
Message-ID: <251f6d99-a7f6-ddbe-096a-95998b86dbed@gmail.com>

Hi Daniel,

On 04/04/2021 22:33, Daniel Lezcano wrote:
> On 29/03/2021 13:52, Matthias Brugger wrote:
>>
>>
>> On 19/03/2021 03:34, Seiya Wang wrote:
>>> This commit adds dt-binding documentation of timer for Mediatek MT8195 SoC
>>> Platform.
>>>
>>> Signed-off-by: Seiya Wang <seiya.wang at mediatek.com>
>>
>> Applied to v5.12-next/dts64
> 
> Usually bindings go through the subsystem maintainer.
> 

Yes I know, although not all maintainers are taking them. I'll coordinate with
you the next time, sorry for any inconvenience caused by this.

Regards,
Matthias


From hverkuil-cisco at xs4all.nl  Tue Apr  6 11:54:51 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 6 Apr 2021 12:54:51 +0200
Subject: [PATCH v8 01/13] dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to
 syscon list
In-Reply-To: <20210401160003.88803-2-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
 <20210401160003.88803-2-benjamin.gaignard@collabora.com>
Message-ID: <430b380d-a437-dfdc-5fe7-c5cfe2a44935@xs4all.nl>

Hi Benjamin,

The commit logs in this series have a few too many grammatical
mistakes. And since I want some other changes as well, I'll just
review the text so it can be fixed in v9.

On 01/04/2021 17:59, Benjamin Gaignard wrote:
> Add 'nxp,imx8mq-vpu-ctrl' in the list of possible syscon.

in -> to

> It will used to access to the VPU control registers.

to the -> the

Regards,

	Hans

> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> Acked-by: Rob Herring <robh at kernel.org>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> ---
> version 8:
>  - Add Lee ack
> 
> version 7:
>  - Add Rob ack
> 
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index f14ae6da0068..ae22c4730613 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -44,6 +44,7 @@ properties:
>                - hisilicon,peri-subctrl
>                - microchip,sparx5-cpu-syscon
>                - mstar,msc313-pmsleep
> +              - nxp,imx8mq-vpu-ctrl
>                - rockchip,px30-qos
>                - rockchip,rk3066-qos
>                - rockchip,rk3288-qos
> 



From matthias.bgg at gmail.com  Tue Apr  6 11:56:04 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 12:56:04 +0200
Subject: [PATCH v2 3/8] dt-bindings: watchdog: Add compatible for Mediatek
 MT8195
In-Reply-To: <20210326014037.GA2144901@robh.at.kernel.org>
References: <20210319023427.16711-1-seiya.wang@mediatek.com>
 <20210319023427.16711-5-seiya.wang@mediatek.com>
 <20210326014037.GA2144901@robh.at.kernel.org>
Message-ID: <32dd4d40-2dd3-fc58-ae2b-642b877085b4@gmail.com>

Hi Wim,

On 26/03/2021 02:40, Rob Herring wrote:
> On Fri, 19 Mar 2021 10:34:22 +0800, Seiya Wang wrote:
>> This commit adds dt-binding documentation of watchdog for Mediatek MT8195 SoC
>> Platform.
>>
>> Signed-off-by: Seiya Wang <seiya.wang at mediatek.com>
>> Reviewed-by: Guenter Roeck <linux at roeck-us.net>
>> ---
>>  Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 +
>>  1 file changed, 1 insertion(+)
>>
> 
> Acked-by: Rob Herring <robh at kernel.org>
> 

I suppose you will take this patch through your tree. If you want me to take it
through the MediaTek SoC tree, please let me know.

Regards,
Matthias


From hverkuil-cisco at xs4all.nl  Tue Apr  6 11:57:50 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 6 Apr 2021 12:57:50 +0200
Subject: [PATCH v8 02/13] dt-bindings: media: nxp,imx8mq-vpu: Update the
 bindings for G2 support
In-Reply-To: <20210401160003.88803-3-benjamin.gaignard@collabora.com>
References: <20210401160003.88803-1-benjamin.gaignard@collabora.com>
 <20210401160003.88803-3-benjamin.gaignard@collabora.com>
Message-ID: <64bcdb7c-37a8-0d6e-1588-db096523725d@xs4all.nl>

On 01/04/2021 17:59, Benjamin Gaignard wrote:
> Introducing G2 hevc video decoder lead to modify the bindings to allow
> to get one node per VPUs.

Introducing the G2 hevc video decoder requires modifications of the bindings to allow
one node per VPU.

> VPUs share one hardware control block which is provided as a phandle on
> an syscon.

an -> a

> Each node got now one reg and one interrupt.

got now -> has now

> Add a compatible for G2 hardware block: nxp,imx8mq-vpu-g2.
> 
> To be compatible with older DT the driver is still capable to use 'ctrl'

use -> use the

> reg-name even if it is deprecated now.

Regards,

	Hans

> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> Reviewed-by: Rob Herring <robh at kernel.org>
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
> version 7:
> - Add Rob and Philipp reviewed-by tag
> - Change syscon phandle name to nxp,imx8m-vpu-ctrl (remove 'q' to be
>   usable for iMX8MM too)
> 
> version 5:
> - This version doesn't break the backward compatibilty between kernel
>   and DT.
> 
>  .../bindings/media/nxp,imx8mq-vpu.yaml        | 53 ++++++++++++-------
>  1 file changed, 34 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> index 762be3f96ce9..18e7d40a5f24 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> @@ -15,22 +15,18 @@ description:
>  
>  properties:
>    compatible:
> -    const: nxp,imx8mq-vpu
> +    oneOf:
> +      - const: nxp,imx8mq-vpu
> +      - const: nxp,imx8mq-vpu-g2
>  
>    reg:
> -    maxItems: 3
> -
> -  reg-names:
> -    items:
> -      - const: g1
> -      - const: g2
> -      - const: ctrl
> +    maxItems: 1
>  
>    interrupts:
> -    maxItems: 2
> +    maxItems: 1
>  
>    interrupt-names:
> -    items:
> +    oneOf:
>        - const: g1
>        - const: g2
>  
> @@ -46,14 +42,18 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  nxp,imx8m-vpu-ctrl:
> +    description: Specifies a phandle to syscon VPU hardware control block
> +    $ref: "/schemas/types.yaml#/definitions/phandle"
> +
>  required:
>    - compatible
>    - reg
> -  - reg-names
>    - interrupts
>    - interrupt-names
>    - clocks
>    - clock-names
> +  - nxp,imx8m-vpu-ctrl
>  
>  additionalProperties: false
>  
> @@ -62,18 +62,33 @@ examples:
>          #include <dt-bindings/clock/imx8mq-clock.h>
>          #include <dt-bindings/interrupt-controller/arm-gic.h>
>  
> -        vpu: video-codec at 38300000 {
> +        vpu_ctrl: syscon at 38320000 {
> +                 compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
> +                 reg = <0x38320000 0x10000>;
> +        };
> +
> +        vpu_g1: video-codec at 38300000 {
>                  compatible = "nxp,imx8mq-vpu";
> -                reg = <0x38300000 0x10000>,
> -                      <0x38310000 0x10000>,
> -                      <0x38320000 0x10000>;
> -                reg-names = "g1", "g2", "ctrl";
> -                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> -                             <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> -                interrupt-names = "g1", "g2";
> +                reg = <0x38300000 0x10000>;
> +                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> +                interrupt-names = "g1";
> +                clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
> +                         <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
> +                         <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
> +                clock-names = "g1", "g2", "bus";
> +                power-domains = <&pgc_vpu>;
> +                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
> +        };
> +
> +        vpu_g2: video-codec at 38310000 {
> +                compatible = "nxp,imx8mq-vpu-g2";
> +                reg = <0x38300000 0x10000>;
> +                interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> +                interrupt-names = "g2";
>                  clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
>                           <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
>                           <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
>                  clock-names = "g1", "g2", "bus";
>                  power-domains = <&pgc_vpu>;
> +                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
>          };
> 



From matthias.bgg at gmail.com  Tue Apr  6 11:58:25 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 12:58:25 +0200
Subject: [PATCH v2 1/2] dt-bindings: mediatek: mmsys: add mt8167 binding
In-Reply-To: <20210405200354.2194930-1-fparent@baylibre.com>
References: <20210405200354.2194930-1-fparent@baylibre.com>
Message-ID: <10e5739f-dfdf-d734-57a6-2b46e5d15220@gmail.com>



On 05/04/2021 22:03, Fabien Parent wrote:
> Add binding documentation for MT8167 SoC.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
> Acked-by: Rob Herring <robh at kernel.org>

Applied both patches to v5.12-next/soc-2

Thanks!

> ---
> V2: Rebased + fix typo in commit message.
> 
>  .../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt          | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> index d8c9108c3b4a..78c50733985c 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> @@ -13,6 +13,7 @@ Required Properties:
>  	- "mediatek,mt6779-mmsys", "syscon"
>  	- "mediatek,mt6797-mmsys", "syscon"
>  	- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
> +	- "mediatek,mt8167-mmsys", "syscon"
>  	- "mediatek,mt8173-mmsys", "syscon"
>  	- "mediatek,mt8183-mmsys", "syscon"
>  - #clock-cells: Must be 1
> 


From matthias.bgg at gmail.com  Tue Apr  6 11:59:55 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 12:59:55 +0200
Subject: [PATCH] arm64: dts: mediatek: mt8167: add power domains
In-Reply-To: <20210405172836.2038526-1-fparent@baylibre.com>
References: <20210405172836.2038526-1-fparent@baylibre.com>
Message-ID: <7e8532e1-710c-3239-4384-cbb10348c4b4@gmail.com>



On 05/04/2021 19:28, Fabien Parent wrote:
> Add support for the MT8167 power domains.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Applied to v5.12-next/dts64-2

Thanks

> ---
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 68 ++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 1c5639ead622..156fbdad01fb 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -7,6 +7,7 @@
>  
>  #include <dt-bindings/clock/mt8167-clk.h>
>  #include <dt-bindings/memory/mt8167-larb-port.h>
> +#include <dt-bindings/power/mt8167-power.h>
>  
>  #include "mt8167-pinfunc.h"
>  
> @@ -34,6 +35,73 @@ apmixedsys: apmixedsys at 10018000 {
>  			#clock-cells = <1>;
>  		};
>  
> +		scpsys: syscon at 10006000 {
> +			compatible = "syscon", "simple-mfd";
> +			reg = <0 0x10006000 0 0x1000>;
> +			#power-domain-cells = <1>;
> +
> +			spm: power-controller {
> +				compatible = "mediatek,mt8167-power-controller";
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				#power-domain-cells = <1>;
> +
> +				/* power domains of the SoC */
> +				power-domain at MT8167_POWER_DOMAIN_MM {
> +					reg = <MT8167_POWER_DOMAIN_MM>;
> +					clocks = <&topckgen CLK_TOP_SMI_MM>;
> +					clock-names = "mm";
> +					#power-domain-cells = <0>;
> +					mediatek,infracfg = <&infracfg>;
> +				};
> +
> +				power-domain at MT8167_POWER_DOMAIN_VDEC {
> +					reg = <MT8167_POWER_DOMAIN_VDEC>;
> +					clocks = <&topckgen CLK_TOP_SMI_MM>,
> +						 <&topckgen CLK_TOP_RG_VDEC>;
> +					clock-names = "mm", "vdec";
> +					#power-domain-cells = <0>;
> +				};
> +
> +				power-domain at MT8167_POWER_DOMAIN_ISP {
> +					reg = <MT8167_POWER_DOMAIN_ISP>;
> +					clocks = <&topckgen CLK_TOP_SMI_MM>;
> +					clock-names = "mm";
> +					#power-domain-cells = <0>;
> +				};
> +
> +				power-domain at MT8167_POWER_DOMAIN_MFG_ASYNC {
> +					reg = <MT8167_POWER_DOMAIN_MFG_ASYNC>;
> +					clocks = <&topckgen CLK_TOP_RG_AXI_MFG>,
> +						 <&topckgen CLK_TOP_RG_SLOW_MFG>;
> +					clock-names = "axi_mfg", "mfg";
> +					#address-cells = <1>;
> +					#size-cells = <0>;
> +					#power-domain-cells = <1>;
> +					mediatek,infracfg = <&infracfg>;
> +
> +					power-domain at MT8167_POWER_DOMAIN_MFG_2D {
> +						reg = <MT8167_POWER_DOMAIN_MFG_2D>;
> +						#address-cells = <1>;
> +						#size-cells = <0>;
> +						#power-domain-cells = <1>;
> +
> +						power-domain at MT8167_POWER_DOMAIN_MFG {
> +							reg = <MT8167_POWER_DOMAIN_MFG>;
> +							#power-domain-cells = <0>;
> +							mediatek,infracfg = <&infracfg>;
> +						};
> +					};
> +				};
> +
> +				power-domain at MT8167_POWER_DOMAIN_CONN {
> +					reg = <MT8167_POWER_DOMAIN_CONN>;
> +					#power-domain-cells = <0>;
> +					mediatek,infracfg = <&infracfg>;
> +				};
> +			};
> +		};
> +
>  		imgsys: syscon at 15000000 {
>  			compatible = "mediatek,mt8167-imgsys", "syscon";
>  			reg = <0 0x15000000 0 0x1000>;
> 


From john.garry at huawei.com  Tue Apr  6 12:00:27 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 12:00:27 +0100
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <YGXPdEAecos4iPVc@krava>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava>
Message-ID: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>

On 01/04/2021 14:49, Jiri Olsa wrote:
> On Thu, Mar 25, 2021 at 06:33:14PM +0800, John Garry wrote:
> 
> SNIP
> 
>> +struct metric {
>> +	struct list_head list;
>> +	struct metric_ref metric_ref;
>> +};
>> +
>> +static int resolve_metric_simple(struct expr_parse_ctx *pctx,
>> +				 struct list_head *compound_list,
>> +				 struct pmu_events_map *map,
>> +				 const char *metric_name)
>> +{
>> +	struct hashmap_entry *cur, *cur_tmp;
>> +	struct metric *metric, *tmp;
>> +	size_t bkt;
>> +	bool all;
>> +	int rc;
>> +
>> +	do {
>> +		all = true;
>> +		hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
>> +			struct metric_ref *ref;
>> +			struct pmu_event *pe;
>> +
>> +			pe = metrcgroup_find_metric(cur->key, map);

*

>> +			if (!pe)
>> +				continue;
>> +
>> +			if (!strcmp(metric_name, (char *)cur->key)) {
>> +				pr_warning("Recursion detected for metric %s\n", metric_name);
>> +				rc = -1;
>> +				goto out_err;
>> +			}
>> +
>> +			all = false;
>> +
>> +			/* The metric key itself needs to go out.. */
>> +			expr__del_id(pctx, cur->key);
>> +
>> +			metric = malloc(sizeof(*metric));
>> +			if (!metric) {
>> +				rc = -ENOMEM;
>> +				goto out_err;
>> +			}
>> +
>> +			ref = &metric->metric_ref;
>> +			ref->metric_name = pe->metric_name;
>> +			ref->metric_expr = pe->metric_expr;
>> +			list_add_tail(&metric->list, compound_list);
>> +
>> +			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> 

Hi Jirka,

> so this might add new items to pctx->ids, I think you need
> to restart the iteration as we do it in __resolve_metric
> otherwise you could miss some new keys

I thought that I was doing this. Indeed, this code is very much like 
__resolve_metric() ;)

So expr__find_other() may add a new item to pctx->ids, and we always 
iterate again, and try to lookup any pmu_events, *, above. If none 
exist, then we have broken down pctx into primitive events aliases and 
unresolvable metrics, and stop iterating. And then unresolvable metrics 
would be found in check_parse_cpu().

As an example, we can deal with metric test1, below, which references 2x 
other metrics:

     {
         "MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * (( ( 
CPU_CLK_UNHALTED.THREAD / 2 ) * ( 1 + CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE 
/ CPU_CLK_UNHALTED.REF_XCLK ) )))",
       "MetricName": "Frontend_Bound",
     },
     {
         "MetricExpr": "( UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 
4 * INT_MISC.RECOVERY_CYCLES ) / (4 * cycles)",
         "MetricName": "Bad_Speculation",
     },
     {
         "MetricExpr": "Bad_Speculation + Frontend_Bound",
         "MetricName": "test1",
     },

Does that satisfy your concern, or have I missed something?

Thanks,
John

> 
> jirka
> 
>> +			if (rc)
>> +				goto out_err;
>> +		}
>> +	} while (!all);
>> +
>> +	return 0;
>> +
>> +out_err:
>> +	list_for_each_entry_safe(metric, tmp, compound_list, list)
>> +		free(metric);
>> +
>> +	return rc;
>> +
>> +}
> 
> SNIP
> 
> .
> 



From broonie at kernel.org  Tue Apr  6 12:02:57 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 12:02:57 +0100
Subject: [RFC PATCH v1 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <9ebc341b-ba5a-db9a-c5e6-17b30d4b1fd4@linux.microsoft.com>
References: <77bd5edeea72d44533c769b1e8c0fea7a9d7eb3a>
 <20210330190955.13707-1-madvenka@linux.microsoft.com>
 <20210330190955.13707-4-madvenka@linux.microsoft.com>
 <20210401142759.GJ4758@sirena.org.uk>
 <0bece48b-5fee-2bd1-752e-66d2b89cc5ad@linux.microsoft.com>
 <20210401182810.GO4758@sirena.org.uk>
 <2a56fe4b-9929-0d8b-aa49-c2b1c1b82b79@linux.microsoft.com>
 <fe2f3b1e-8cb6-05ce-7968-216fed079fe4@linux.microsoft.com>
 <9ebc341b-ba5a-db9a-c5e6-17b30d4b1fd4@linux.microsoft.com>
Message-ID: <20210406110257.GA6443@sirena.org.uk>

On Thu, Apr 01, 2021 at 02:47:11PM -0500, Madhavan T. Venkataraman wrote:
> On 4/1/21 1:53 PM, Madhavan T. Venkataraman wrote:

> > Alternatively, I could just move the SYM_INNER_LABEL(ftrace_graph_call..) to outside the ifdef.

> Or, even better, I could just use ftrace_call+4 because that would be the return
> address for the tracer function at ftrace_call:

> I think that would be cleaner. And, I don't need the complicated comments for ftrace_graph_call.

> Is this acceptable?

I think either of those should be fine.
-------------- 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/20210406/42f5bf54/attachment.sig>

From john.garry at huawei.com  Tue Apr  6 12:02:36 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 12:02:36 +0100
Subject: [PATCH v2 0/6] perf arm64 metricgroup support
In-Reply-To: <247e9484-34c8-544a-e268-b025ecb317fe@linux.ibm.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <20210325203944.GD8931@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <dc17013d-2dcb-8ddf-a15a-e98cad3e2ae3@huawei.com>
 <20210329210717.GF8931@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <247e9484-34c8-544a-e268-b025ecb317fe@linux.ibm.com>
Message-ID: <1d800da3-ec94-3a37-eca9-1d3cf8543ba6@huawei.com>

On 30/03/2021 07:41, kajoljain wrote:
> 
> 
> On 3/30/21 2:37 AM, Paul A. Clarke wrote:
>> On Fri, Mar 26, 2021 at 10:57:40AM +0000, John Garry wrote:
>>> On 25/03/2021 20:39, Paul A. Clarke wrote:
>>>> On Thu, Mar 25, 2021 at 06:33:12PM +0800, John Garry wrote:
>>>>> Metric reuse support is added for pmu-events parse metric testcase.
>>>>> This had been broken on power9 recentlty:
>>>>> https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/
>>>>
>>>> Much better.  Before:
>>>> --
>>>> $ perf test -v 10 2>&1 | grep -i error | wc -l
>>>> 112
>>>> --
>>>> After:
>>>> --
>>>> $ perf test -v 10 2>&1 | grep -i error | wc -l
>>>> 17
>>>> --
>>>>
>>>> And these seem like different types of issues:
>>>> --
>>>> $ perf test -v 10 2>&1 | grep -i error
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_powerbus0_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
>>>> --
>>>>
>>>
>>> This looks suspicious.
>>>
>>> Firstly, does /sys/bus/event_source/devices/nest_mcs01_imc (or others,
>>> above) exist on your system? I guess not.
>>>
>>> Secondly, checking Documentation/powerpc/imc.rst, we have examples of:
>>> nest_mcs01/PM_MCS01_64B_R...
>>>
>>> So is the PMU name correct in the metric file for nest_mcs01_imc? Looking at
>>> the kernel driver file, arch/powerpc/perf/imc-pmu.c, it seems to be correct.
>>> Not sure.
>>
>> I ran with a newer kernel, and the above errors disappeared, replaced with
>> about 10 of:
>> --
>> Error string 'Cannot find PMU `hv_24x7'. Missing kernel support?' help '(null)'
>> --
>>
>> ...but I was running without a hypervisor, so I tried the same kernel on a
>> PowerVM-virtualized system and the "hv_24x7" messages went away, but the
>> "nest" messages returned.  This may all be expected behavior... I confess
>> I haven't followed these new perf capabilities closely.
>>
> 
> Hi Paul/John,
>     This is something expected. For nest-imc we need bare-metal system and for
> hv-24x7 we need VM environment. Since you are checking this test in VM machine,
> there nest events are not supported and hence we are getting this error.
> 
> Thanks,
> Kajol Jain

Cool, so I hope that tested-by or similar can be provided :) [obviously 
pending any changes that come from reviews]

Thanks

> 
>> It's extremely likely that none of these errors has anything to do with your
>> changes. :-
>>
>> PC
>>
> .
> 



From mike.leach at linaro.org  Tue Apr  6 12:08:19 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Tue, 6 Apr 2021 12:08:19 +0100
Subject: [PATCH v5 09/10] coresight: syscfg: Add initial configfs support
In-Reply-To: <20210405205613.GE145043@xps15>
References: <20210316180400.7184-1-mike.leach@linaro.org>
 <20210316180400.7184-10-mike.leach@linaro.org>
 <20210405205613.GE145043@xps15>
Message-ID: <CAJ9a7Vj==w=4ai=DCbT=Ssn=xucvbMFCtsWCVEf3FbBgmHdpPw@mail.gmail.com>

Hi Mathieu,

On Mon, 5 Apr 2021 at 21:56, Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
>
> On Tue, Mar 16, 2021 at 06:03:59PM +0000, Mike Leach wrote:
> > Adds configfs subsystem and attributes to the configuration manager
> > to enable the listing of loaded configurations and features.
> >
> > The default values of feature parameters can be accessed and altered
> > from these attributes to affect all installed devices using the feature.
> >
> > Signed-off-by: Mike Leach <mike.leach at linaro.org>
> > ---
> >  drivers/hwtracing/coresight/Makefile          |   3 +-
> >  .../coresight/coresight-syscfg-configfs.c     | 399 ++++++++++++++++++
> >  .../coresight/coresight-syscfg-configfs.h     |  45 ++
> >  .../hwtracing/coresight/coresight-syscfg.c    |  77 ++++
> >  .../hwtracing/coresight/coresight-syscfg.h    |   7 +
> >  5 files changed, 530 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> >  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> >
> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> > index 2707bfef1b76..391c93a08902 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -5,7 +5,8 @@
> >  obj-$(CONFIG_CORESIGHT) += coresight.o
> >  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
> >               coresight-sysfs.o coresight-syscfg.o coresight-config.o \
> > -             coresight-cfg-preload.o coresight-cfg-afdo.o
> > +             coresight-cfg-preload.o coresight-cfg-afdo.o \
> > +             coresight-syscfg-configfs.o
> >  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
> >  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
> >                     coresight-tmc-etr.o
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> > new file mode 100644
> > index 000000000000..7cefad81d1f6
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> > @@ -0,0 +1,399 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2020 Linaro Limited, All rights reserved.
> > + * Author: Mike Leach <mike.leach at linaro.org>
> > + */
> > +
> > +#include <linux/configfs.h>
> > +
> > +#include "coresight-syscfg-configfs.h"
> > +
> > +/* create a default ci_type. */
> > +static inline struct config_item_type *cscfg_create_ci_type(void)
> > +{
> > +     struct config_item_type *ci_type;
> > +
> > +     ci_type = devm_kzalloc(cscfg_device(), sizeof(*ci_type), GFP_KERNEL);
> > +     if (ci_type)
> > +             ci_type->ct_owner = THIS_MODULE;
> > +
> > +     return ci_type;
> > +}
> > +
> > +/* configurations sub-group */
> > +
> > +/* attributes for the config view group */
> > +static ssize_t cscfg_cfg_description_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> > +                                                      struct cscfg_fs_config, group);
> > +
> > +     return scnprintf(page, PAGE_SIZE, "%s\n", fs_config->config_desc->description);
> > +}
> > +CONFIGFS_ATTR_RO(cscfg_cfg_, description);
> > +
> > +static ssize_t cscfg_cfg_feature_refs_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> > +                                                      struct cscfg_fs_config, group);
> > +     const struct cscfg_config_desc *config_desc = fs_config->config_desc;
> > +     ssize_t ch_used = 0;
> > +     int i;
> > +
> > +     if (config_desc->nr_feat_refs) {
>
> This check isn't needed.
>
Agreed.

> > +             for (i = 0; i < config_desc->nr_feat_refs; i++) {
> > +                     ch_used += scnprintf(page + ch_used, PAGE_SIZE - ch_used,
> > +                                          "%s\n", config_desc->feat_ref_names[i]);
> > +             }
> > +     }
> > +     return ch_used;
> > +}
> > +CONFIGFS_ATTR_RO(cscfg_cfg_, feature_refs);
> > +
> > +/* list preset values in order of features and params */
> > +static ssize_t cscfg_cfg_values_show(struct config_item *item, char *page)
> > +{
> > +     const struct cscfg_feature_desc *feat_desc;
> > +     const struct cscfg_config_desc *config_desc;
> > +     struct cscfg_fs_preset *fs_preset;
> > +     int i, j, val_idx, preset_idx;
> > +     ssize_t used = 0;
> > +
> > +     fs_preset = container_of(to_config_group(item), struct cscfg_fs_preset, group);
> > +     config_desc = fs_preset->config_desc;
> > +
> > +     if (!config_desc->nr_presets)
> > +             return 0;
> > +
> > +     preset_idx = fs_preset->preset_num - 1;
> > +
> > +     /* start index on the correct array line */
> > +     val_idx = config_desc->nr_total_params * preset_idx;
> > +
> > +     /*
> > +      * A set of presets is the sum of all params in used features,
> > +      * in order of declaration of features and params in the features
> > +      */
> > +     for (i = 0; i < config_desc->nr_feat_refs; i++) {
> > +             feat_desc = cscfg_get_named_feat_desc(config_desc->feat_ref_names[i]);
> > +             for (j = 0; j < feat_desc->nr_params; j++) {
> > +                     used += scnprintf(page + used, PAGE_SIZE - used,
> > +                                       "%s.%s = 0x%llx ",
> > +                                       feat_desc->name,
> > +                                       feat_desc->params_desc[j].name,
> > +                                       config_desc->presets[val_idx++]);
> > +             }
> > +     }
> > +     used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> > +
> > +     return used;
> > +}
> > +CONFIGFS_ATTR_RO(cscfg_cfg_, values);
> > +
> > +static struct configfs_attribute *cscfg_config_view_attrs[] = {
> > +     &cscfg_cfg_attr_description,
> > +     &cscfg_cfg_attr_feature_refs,
> > +     NULL,
> > +};
> > +
> > +static struct config_item_type cscfg_config_view_type = {
> > +     .ct_owner = THIS_MODULE,
> > +     .ct_attrs = cscfg_config_view_attrs,
> > +};
> > +
> > +static struct configfs_attribute *cscfg_config_preset_attrs[] = {
> > +     &cscfg_cfg_attr_values,
> > +     NULL,
> > +};
> > +
> > +static struct config_item_type cscfg_config_preset_type = {
> > +     .ct_owner = THIS_MODULE,
> > +     .ct_attrs = cscfg_config_preset_attrs,
> > +};
> > +
> > +static int cscfg_add_preset_groups(struct cscfg_fs_config *cfg_view)
> > +{
> > +     int preset_num;
> > +     struct cscfg_fs_preset *cfg_fs_preset;
> > +     struct cscfg_config_desc *config_desc = cfg_view->config_desc;
> > +     char name[CONFIGFS_ITEM_NAME_LEN];
> > +
> > +     if (!config_desc->nr_presets)
> > +             return 0;
> > +
> > +     for (preset_num = 1; preset_num <= config_desc->nr_presets; preset_num++) {
> > +             cfg_fs_preset = devm_kzalloc(cscfg_device(),
> > +                                          sizeof(struct cscfg_fs_preset), GFP_KERNEL);
> > +
> > +             if (!cfg_fs_preset)
> > +                     return -ENOMEM;
> > +
> > +             snprintf(name, CONFIGFS_ITEM_NAME_LEN, "preset%d", preset_num);
> > +             cfg_fs_preset->preset_num = preset_num;
> > +             cfg_fs_preset->config_desc = cfg_view->config_desc;
> > +             config_group_init_type_name(&cfg_fs_preset->group, name,
> > +                                         &cscfg_config_preset_type);
> > +             configfs_add_default_group(&cfg_fs_preset->group, &cfg_view->group);
> > +     }
> > +     return 0;
> > +}
> > +
> > +static struct config_group *cscfg_create_config_group(struct cscfg_config_desc *config_desc)
> > +{
> > +     struct cscfg_fs_config *cfg_view;
> > +     struct device *dev = cscfg_device();
> > +     int err;
> > +
> > +     if (!dev)
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     cfg_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_config), GFP_KERNEL);
> > +     if (!cfg_view)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     cfg_view->config_desc = config_desc;
> > +     config_group_init_type_name(&cfg_view->group, config_desc->name, &cscfg_config_view_type);
> > +
> > +     /* add in a preset<n> dir for each preset */
> > +     err = cscfg_add_preset_groups(cfg_view);
> > +     if (err)
> > +             return ERR_PTR(err);
> > +
> > +     return &cfg_view->group;
> > +}
> > +
> > +/* attributes for features view */
> > +
> > +static ssize_t cscfg_feat_description_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> > +                                                     struct cscfg_fs_feature, group);
> > +
> > +     return scnprintf(page, PAGE_SIZE, "%s\n", fs_feat->feat_desc->description);
>
> Either remove the '\n' at the end of fs_feat->feat_desc->description or above,
> with a preference toward the former.  The same thing should be done for
> cscfg_cfg_description_show().
>
> Otherwise it creates and exta new line when quering from the command line and it
> is only a matter of time before the automated tools point it out.
>

Will remove here - we cannot control what users are going to put in
their own descriptions. Moreover - it seems that multi-line is
permissible in configfs - see descriptions in the sample code in
./samples/configfs.


> > +}
> > +CONFIGFS_ATTR_RO(cscfg_feat_, description);
> > +
> > +static ssize_t cscfg_feat_matches_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> > +                                                     struct cscfg_fs_feature, group);
> > +     u32 match_flags = fs_feat->feat_desc->match_flags;
> > +     int used = 0;
> > +
> > +     if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL)
> > +             used = scnprintf(page, PAGE_SIZE, "SRC_ALL ");
> > +
> > +     if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4)
> > +             used += scnprintf(page + used, PAGE_SIZE - used, "SRC_ETMV4 ");
> > +
> > +     used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> > +     return used;
> > +}
> > +CONFIGFS_ATTR_RO(cscfg_feat_, matches);
> > +
> > +static ssize_t cscfg_feat_nr_params_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> > +                                                     struct cscfg_fs_feature, group);
> > +
> > +     return scnprintf(page, PAGE_SIZE, "%d\n", fs_feat->feat_desc->nr_params);
> > +}
> > +CONFIGFS_ATTR_RO(cscfg_feat_, nr_params);
> > +
> > +/* base feature desc attrib structures */
> > +static struct configfs_attribute *cscfg_feature_view_attrs[] = {
> > +     &cscfg_feat_attr_description,
> > +     &cscfg_feat_attr_matches,
> > +     &cscfg_feat_attr_nr_params,
> > +     NULL,
> > +};
> > +
> > +static struct config_item_type cscfg_feature_view_type = {
> > +     .ct_owner = THIS_MODULE,
> > +     .ct_attrs = cscfg_feature_view_attrs,
> > +};
> > +
> > +static ssize_t cscfg_param_value_show(struct config_item *item, char *page)
> > +{
> > +     struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> > +                                                      struct cscfg_fs_param, group);
> > +     u64 value = param_item->feat_desc->params_desc[param_item->param_idx].value;
> > +
> > +     return scnprintf(page, PAGE_SIZE, "0x%llx\n", value);
> > +}
> > +
> > +static ssize_t cscfg_param_value_store(struct config_item *item,
> > +                                    const char *page, size_t size)
> > +{
> > +     struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> > +                                                      struct cscfg_fs_param, group);
> > +     struct cscfg_feature_desc *feat_desc = param_item->feat_desc;
> > +     int param_idx = param_item->param_idx;
> > +     u64 value;
> > +     int err;
> > +
> > +     err = kstrtoull(page, 0, &value);
> > +     if (!err)
> > +             err = cscfg_update_feat_param_val(feat_desc, param_idx, value);
> > +
> > +     return err ? err : size;
> > +}
> > +CONFIGFS_ATTR(cscfg_param_, value);
> > +
> > +static struct configfs_attribute *cscfg_param_view_attrs[] = {
> > +     &cscfg_param_attr_value,
> > +     NULL,
> > +};
> > +
> > +static struct config_item_type cscfg_param_view_type = {
> > +     .ct_owner = THIS_MODULE,
> > +     .ct_attrs = cscfg_param_view_attrs,
> > +};
> > +
> > +/*
> > + * configfs has far less functionality provided to add attributes dynamically than sysfs,
> > + * and the show and store fns pass the enclosing config_item so the actual attribute cannot
> > + * be determined. Therefore we add each item as a group directory, with a value attribute.
> > + */
> > +static int cscfg_create_params_group_items(struct cscfg_feature_desc *feat_desc,
> > +                                        struct config_group *params_group)
> > +{
> > +     struct device *dev = cscfg_device();
> > +     struct cscfg_fs_param *param_item;
> > +     int i;
> > +
> > +     /* parameter items - as groups with default_value attribute */
> > +     for (i = 0; i < feat_desc->nr_params; i++) {
> > +             param_item = devm_kzalloc(dev, sizeof(struct cscfg_fs_param), GFP_KERNEL);
> > +             if (!param_item)
> > +                     return -ENOMEM;
> > +             param_item->feat_desc = feat_desc;
> > +             param_item->param_idx = i;
> > +             config_group_init_type_name(&param_item->group,
> > +                                         feat_desc->params_desc[i].name,
> > +                                         &cscfg_param_view_type);
> > +             configfs_add_default_group(&param_item->group, params_group);
> > +     }
> > +     return 0;
> > +}
> > +
> > +static struct config_group *cscfg_create_feature_group(struct cscfg_feature_desc *feat_desc)
> > +{
> > +     struct cscfg_fs_feature *feat_view;
> > +     struct config_item_type *params_group_type;
> > +     struct config_group *params_group = NULL;
> > +     struct device *dev = cscfg_device();
> > +     int item_err;
> > +
> > +     if (!dev)
> > +             return ERR_PTR(-EINVAL);
> > +
> > +     feat_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_feature), GFP_KERNEL);
> > +     if (!feat_view)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     if (feat_desc->nr_params) {
> > +             params_group = devm_kzalloc(dev, sizeof(struct config_group), GFP_KERNEL);
> > +             if (!params_group)
> > +                     return ERR_PTR(-ENOMEM);
> > +
> > +             params_group_type = cscfg_create_ci_type();
> > +             if (!params_group_type)
> > +                     return ERR_PTR(-ENOMEM);
> > +     }
> > +
> > +     feat_view->feat_desc = feat_desc;
> > +     config_group_init_type_name(&feat_view->group,
> > +                                 feat_desc->name,
> > +                                 &cscfg_feature_view_type);
> > +     if (params_group) {
> > +             config_group_init_type_name(params_group, "params", params_group_type);
> > +             configfs_add_default_group(params_group, &feat_view->group);
> > +             item_err = cscfg_create_params_group_items(feat_desc, params_group);
> > +             if (item_err)
> > +                     return ERR_PTR(item_err);
> > +     }
> > +     return &feat_view->group;
> > +}
> > +
> > +static struct config_item_type cscfg_configs_type = {
> > +     .ct_owner = THIS_MODULE,
> > +};
> > +
> > +static struct config_group cscfg_configs_grp = {
> > +     .cg_item = {
> > +             .ci_namebuf = "configurations",
> > +             .ci_type = &cscfg_configs_type,
> > +     },
> > +};
> > +
> > +/* add configuration to configurations group */
> > +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc)
> > +{
> > +     struct config_group *new_group;
> > +     int err;
> > +
> > +     new_group = cscfg_create_config_group(config_desc);
> > +     if (IS_ERR(new_group))
> > +             return PTR_ERR(new_group);
> > +     err =  configfs_register_group(&cscfg_configs_grp, new_group);
> > +     return err;
> > +}
> > +
> > +static struct config_item_type cscfg_features_type = {
> > +     .ct_owner = THIS_MODULE,
> > +};
> > +
> > +static struct config_group cscfg_features_grp = {
> > +     .cg_item = {
> > +             .ci_namebuf = "features",
> > +             .ci_type = &cscfg_features_type,
> > +     },
> > +};
> > +
> > +/* add feature to features group */
> > +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc)
> > +{
> > +     struct config_group *new_group;
> > +     int err;
> > +
> > +     new_group = cscfg_create_feature_group(feat_desc);
> > +     if (IS_ERR(new_group))
> > +             return PTR_ERR(new_group);
> > +     err =  configfs_register_group(&cscfg_features_grp, new_group);
> > +     return err;
> > +}
> > +
> > +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr)
> > +{
> > +     struct configfs_subsystem *subsys;
> > +     struct config_item_type *ci_type;
> > +
> > +     if (!cscfg_mgr)
> > +             return -EINVAL;
> > +
> > +     ci_type = cscfg_create_ci_type();
> > +     if (!ci_type)
> > +             return -ENOMEM;
> > +
> > +     subsys = &cscfg_mgr->cfgfs_subsys;
> > +     config_item_set_name(&subsys->su_group.cg_item, CSCFG_FS_SUBSYS_NAME);
> > +     subsys->su_group.cg_item.ci_type = ci_type;
> > +
> > +     config_group_init(&subsys->su_group);
> > +     mutex_init(&subsys->su_mutex);
> > +
> > +     /* Add default groups to subsystem */
> > +     config_group_init(&cscfg_configs_grp);
> > +     configfs_add_default_group(&cscfg_configs_grp, &subsys->su_group);
> > +
> > +     config_group_init(&cscfg_features_grp);
> > +     configfs_add_default_group(&cscfg_features_grp, &subsys->su_group);
> > +
> > +     return configfs_register_subsystem(subsys);
> > +}
> > +
> > +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr)
> > +{
> > +     configfs_unregister_subsystem(&cscfg_mgr->cfgfs_subsys);
> > +}
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.h b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> > new file mode 100644
> > index 000000000000..7d6ffe35ca4c
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> > @@ -0,0 +1,45 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Coresight system configuration driver - support for configfs.
> > + */
> > +
> > +#ifndef CORESIGHT_SYSCFG_CONFIGFS_H
> > +#define CORESIGHT_SYSCFG_CONFIGFS_H
> > +
> > +#include <linux/configfs.h>
> > +#include "coresight-syscfg.h"
> > +
> > +#define CSCFG_FS_SUBSYS_NAME "cs-syscfg"
> > +
> > +/* container for configuration view */
> > +struct cscfg_fs_config {
> > +     struct cscfg_config_desc *config_desc;
> > +     struct config_group group;
> > +};
> > +
> > +/* container for feature view */
> > +struct cscfg_fs_feature {
> > +     struct cscfg_feature_desc *feat_desc;
> > +     struct config_group group;
> > +};
> > +
> > +/* container for parameter view */
> > +struct cscfg_fs_param {
> > +     int param_idx;
> > +     struct cscfg_feature_desc *feat_desc;
> > +     struct config_group group;
> > +};
> > +
> > +/* container for preset view */
> > +struct cscfg_fs_preset {
> > +     int preset_num;
> > +     struct cscfg_config_desc *config_desc;
> > +     struct config_group group;
> > +};
> > +
> > +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr);
> > +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr);
> > +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc);
> > +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc);
> > +
> > +#endif /* CORESIGHT_SYSCFG_CONFIGFS_H */
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> > index befc379b85b9..3be3828a40a7 100644
> > --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> > @@ -9,6 +9,7 @@
> >  #include "coresight-config.h"
> >  #include "coresight-etm-perf.h"
> >  #include "coresight-syscfg.h"
> > +#include "coresight-syscfg-configfs.h"
> >
> >  /*
> >   * cscfg_ API manages configurations and features for the entire coresight
> > @@ -288,6 +289,72 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
> >       return 0;
> >  }
> >
> > +/* get a feature descriptor by name */
> > +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name)
> > +{
> > +     const struct cscfg_feature_desc *feat_desc = NULL, *feat_desc_item;
> > +
> > +     mutex_lock(&cscfg_mutex);
> > +
> > +     list_for_each_entry(feat_desc_item, &cscfg_mgr->feat_desc_list, item) {
> > +             if (strcmp(feat_desc_item->name, name) == 0) {
> > +                     feat_desc = feat_desc_item;
> > +                     break;
> > +             }
> > +     }
> > +
> > +     mutex_unlock(&cscfg_mutex);
> > +     return feat_desc;
> > +}
> > +
> > +/* called with cscfg_mutex held */
> > +static struct cscfg_feature_csdev *
> > +cscfg_csdev_get_feat_from_desc(struct coresight_device *csdev,
> > +                            struct cscfg_feature_desc *feat_desc)
> > +{
> > +     struct cscfg_feature_csdev *feat_csdev;
> > +
> > +     list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
> > +             if (feat_csdev->feat_desc == feat_desc)
> > +                     return feat_csdev;
> > +     }
> > +     return NULL;
> > +}
> > +
> > +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> > +                             int param_idx, u64 value)
> > +{
> > +     int err = 0;
> > +     struct cscfg_feature_csdev *feat_csdev;
> > +     struct cscfg_registered_csdev *csdev_item;
> > +
> > +     mutex_lock(&cscfg_mutex);
> > +
> > +     /* check if any config active & return busy */
> > +     if (atomic_read(&cscfg_mgr->sys_active_cnt)) {
> > +             err = -EBUSY;
> > +             goto unlock_exit;
> > +     }
> > +
> > +     /* set the value */
> > +     if ((param_idx < 0) || (param_idx >= feat_desc->nr_params)) {
> > +             err = -EINVAL;
> > +             goto unlock_exit;
> > +     }
> > +     feat_desc->params_desc[param_idx].value = value;
> > +
> > +     /* update loaded instances.*/
> > +     list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
> > +             feat_csdev = cscfg_csdev_get_feat_from_desc(csdev_item->csdev, feat_desc);
> > +             if (feat_csdev)
> > +                     feat_csdev->params_csdev[param_idx].current_value = value;
> > +     }
> > +
> > +unlock_exit:
> > +     mutex_unlock(&cscfg_mutex);
> > +     return err;
> > +}
> > +
> >  /*
> >   * External API function to load feature and config sets.
> >   * Take a 0 terminated array of feature descriptors and/or configuration
> > @@ -305,6 +372,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
> >       if (feat_descs) {
> >               while (feat_descs[i]) {
> >                       err = cscfg_load_feat(feat_descs[i]);
> > +                     if (!err)
> > +                             err = cscfg_configfs_add_feature(feat_descs[i]);
> >                       if (err) {
> >                               pr_err("coresight-syscfg: Failed to load feature %s\n",
> >                                      feat_descs[i]->name);
> > @@ -319,6 +388,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
> >       if (config_descs) {
> >               while (config_descs[i]) {
> >                       err = cscfg_load_config(config_descs[i]);
> > +                     if (!err)
> > +                             err = cscfg_configfs_add_config(config_descs[i]);
> >                       if (err) {
> >                               pr_err("coresight-syscfg: Failed to load configuration %s\n",
> >                                      config_descs[i]->name);
> > @@ -608,6 +679,7 @@ int cscfg_create_device(void)
> >       dev->init_name = "cs_system_cfg";
> >
> >       err = device_register(dev);
> > +
>
> Spurious change
>
> I am done reviewing your work.  Before sending another revision please
> ensure everything works properly when applied on top of the ETE/TRBE patchset[1].
> It applies correctly but I'm not sure it does the right thing, especially in
> etm_setup_aux() with the per CPU handle changes that have been introduced.
>

I didn't spot anything that would conflict between the two sets when
reviewing ETE/TRBE a couple of weeks ago - but will check & test
against the suggested branch prior to releasing a v6.

Thanks for the reviews.

Mike


> Thanks,
> Mathieu
>
> [1]. https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-ETE-TRBE
>
>
> >       if (err)
> >               cscfg_dev_release(dev);
> >
> > @@ -624,6 +696,7 @@ void cscfg_clear_device(void)
> >       list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
> >               etm_perf_del_symlink_cscfg(cfg_desc);
> >       }
> > +     cscfg_configfs_release(cscfg_mgr);
> >       device_unregister(cscfg_device());
> >       mutex_unlock(&cscfg_mutex);
> >  }
> > @@ -637,6 +710,10 @@ int __init cscfg_init(void)
> >       if (err)
> >               return err;
> >
> > +     err = cscfg_configfs_init(cscfg_mgr);
> > +     if (err)
> > +             goto exit_err;
> > +
> >       INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
> >       INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
> >       INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
> > diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
> > index 7bb8c8e497ba..8d018efd6ead 100644
> > --- a/drivers/hwtracing/coresight/coresight-syscfg.h
> > +++ b/drivers/hwtracing/coresight/coresight-syscfg.h
> > @@ -6,6 +6,7 @@
> >  #ifndef CORESIGHT_SYSCFG_H
> >  #define CORESIGHT_SYSCFG_H
> >
> > +#include <linux/configfs.h>
> >  #include <linux/coresight.h>
> >  #include <linux/device.h>
> >
> > @@ -25,6 +26,7 @@
> >   * @feat_desc_list:  List of feature descriptors to load into registered devices.
> >   * @config_desc_list:        List of system configuration descriptors to load into registered devices.
> >   * @sys_active_cnt:  Total number of active config descriptor references.
> > + * @cfgfs_subsys:    configfs subsystem used to manage configurations.
> >   */
> >  struct cscfg_manager {
> >       struct device dev;
> > @@ -32,6 +34,7 @@ struct cscfg_manager {
> >       struct list_head feat_desc_list;
> >       struct list_head config_desc_list;
> >       atomic_t sys_active_cnt;
> > +     struct configfs_subsystem cfgfs_subsys;
> >  };
> >
> >  /* get reference to dev in cscfg_manager */
> > @@ -57,6 +60,10 @@ struct cscfg_registered_csdev {
> >  int __init cscfg_init(void);
> >  void cscfg_exit(void);
> >  int cscfg_preload(void);
> > +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name);
> > +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> > +                             int param_idx, u64 value);
> > +
> >
> >  /* syscfg manager external API */
> >  int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
> > --
> > 2.17.1
> >



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From thierry.reding at gmail.com  Tue Apr  6 12:16:31 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 6 Apr 2021 13:16:31 +0200
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
Message-ID: <YGxDD4jVZx/H/Zdr@orome.fritz.box>

On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-K?nig wrote:
> Given that lowlevel drivers usually cannot implement exactly what a
> consumer requests with pwm_apply_state() there is some rounding involved.
> 
> pwm_get_state() traditionally returned the setting that was requested most
> recently by the consumer (opposed to what was actually implemented in
> hardware in reply to the last request). To make this semantic obvious
> rename the function.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  Documentation/driver-api/pwm.rst           |  6 +++-
>  drivers/clk/clk-pwm.c                      |  2 +-
>  drivers/gpu/drm/i915/display/intel_panel.c |  4 +--
>  drivers/input/misc/da7280.c                |  2 +-
>  drivers/input/misc/pwm-beeper.c            |  2 +-
>  drivers/input/misc/pwm-vibra.c             |  4 +--
>  drivers/pwm/core.c                         |  4 +--
>  drivers/pwm/pwm-atmel-hlcdc.c              |  2 +-
>  drivers/pwm/pwm-atmel.c                    |  2 +-
>  drivers/pwm/pwm-imx27.c                    |  2 +-
>  drivers/pwm/pwm-rockchip.c                 |  2 +-
>  drivers/pwm/pwm-stm32-lp.c                 |  4 +--
>  drivers/pwm/pwm-sun4i.c                    |  2 +-
>  drivers/pwm/sysfs.c                        | 18 ++++++------
>  drivers/regulator/pwm-regulator.c          |  4 +--
>  drivers/video/backlight/pwm_bl.c           | 10 +++----
>  include/linux/pwm.h                        | 34 ++++++++++++++--------
>  17 files changed, 59 insertions(+), 45 deletions(-)

Honestly, I don't think this is worth the churn. If you think people
will easily get confused by this then a better solution might be to more
explicitly document the pwm_get_state() function to say exactly what it
returns. But there's no need to make life difficult for everyone by
renaming this to something as cumbersome as this.

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/20210406/4641248e/attachment.sig>

From christophe.leroy at csgroup.eu  Tue Apr  6 12:21:33 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Tue, 6 Apr 2021 13:21:33 +0200
Subject: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with
 irq_find_mapping()
In-Reply-To: <20210406093557.1073423-2-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-2-maz@kernel.org>
Message-ID: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu>



Le 06/04/2021 ? 11:35, Marc Zyngier a ?crit?:
> irq_linear_revmap() is supposed to be a fast path for domain
> lookups, but it only exposes low-level details of the irqdomain
> implementation, details which are better kept private.

Can you elaborate with more details ?

> 
> The *overhead* between the two is only a function call and
> a couple of tests, so it is likely that noone can show any
> meaningful difference compared to the cost of taking an
> interrupt.

Do you have any measurement ?

Can you make the "likely" a certitude ?

> 
> Reimplement irq_linear_revmap() with irq_find_mapping()
> in order to preserve source code compatibility, and
> rename the internal field for a measure.

This is in complete contradiction with commit https://github.com/torvalds/linux/commit/d3dcb436

At that time, irq_linear_revmap() was less complex than what irq_find_mapping() is today, and 
nevertheless it was considered worth restoring in as a fast path. What has changed since then ?

Can you also explain the reason for the renaming of "linear_revmap" into "revmap" ? What is that 
"measure" ?

> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>   include/linux/irqdomain.h | 22 +++++++++-------------
>   kernel/irq/irqdomain.c    |  6 +++---
>   2 files changed, 12 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index 33cacc8af26d..b9600f24878a 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -154,9 +154,9 @@ struct irq_domain_chip_generic;
>    * Revmap data, used internally by irq_domain
>    * @revmap_direct_max_irq: The largest hwirq that can be set for controllers that
>    *                         support direct mapping
> - * @revmap_size: Size of the linear map table @linear_revmap[]
> + * @revmap_size: Size of the linear map table @revmap[]
>    * @revmap_tree: Radix map tree for hwirqs that don't fit in the linear map
> - * @linear_revmap: Linear table of hwirq->virq reverse mappings
> + * @revmap: Linear table of hwirq->virq reverse mappings
>    */
>   struct irq_domain {
>   	struct list_head link;
> @@ -180,7 +180,7 @@ struct irq_domain {
>   	unsigned int revmap_size;
>   	struct radix_tree_root revmap_tree;
>   	struct mutex revmap_tree_mutex;
> -	unsigned int linear_revmap[];
> +	unsigned int revmap[];
>   };
>   
>   /* Irq domain flags */
> @@ -396,24 +396,20 @@ static inline unsigned int irq_create_mapping(struct irq_domain *host,
>   	return irq_create_mapping_affinity(host, hwirq, NULL);
>   }
>   
> -
>   /**
> - * irq_linear_revmap() - Find a linux irq from a hw irq number.
> + * irq_find_mapping() - Find a linux irq from a hw irq number.
>    * @domain: domain owning this hardware interrupt
>    * @hwirq: hardware irq number in that domain space
> - *
> - * This is a fast path alternative to irq_find_mapping() that can be
> - * called directly by irq controller code to save a handful of
> - * instructions. It is always safe to call, but won't find irqs mapped
> - * using the radix tree.
>    */
> +extern unsigned int irq_find_mapping(struct irq_domain *host,
> +				     irq_hw_number_t hwirq);
> +
>   static inline unsigned int irq_linear_revmap(struct irq_domain *domain,
>   					     irq_hw_number_t hwirq)
>   {
> -	return hwirq < domain->revmap_size ? domain->linear_revmap[hwirq] : 0;
> +	return irq_find_mapping(domain, hwirq);
>   }
> -extern unsigned int irq_find_mapping(struct irq_domain *host,
> -				     irq_hw_number_t hwirq);
> +
>   extern unsigned int irq_create_direct_mapping(struct irq_domain *host);
>   extern int irq_create_strict_mappings(struct irq_domain *domain,
>   				      unsigned int irq_base,
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index d10ab1d689d5..dfa716305ea9 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -486,7 +486,7 @@ static void irq_domain_clear_mapping(struct irq_domain *domain,
>   				     irq_hw_number_t hwirq)
>   {
>   	if (hwirq < domain->revmap_size) {
> -		domain->linear_revmap[hwirq] = 0;
> +		domain->revmap[hwirq] = 0;
>   	} else {
>   		mutex_lock(&domain->revmap_tree_mutex);
>   		radix_tree_delete(&domain->revmap_tree, hwirq);
> @@ -499,7 +499,7 @@ static void irq_domain_set_mapping(struct irq_domain *domain,
>   				   struct irq_data *irq_data)
>   {
>   	if (hwirq < domain->revmap_size) {
> -		domain->linear_revmap[hwirq] = irq_data->irq;
> +		domain->revmap[hwirq] = irq_data->irq;
>   	} else {
>   		mutex_lock(&domain->revmap_tree_mutex);
>   		radix_tree_insert(&domain->revmap_tree, hwirq, irq_data);
> @@ -920,7 +920,7 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
>   
>   	/* Check if the hwirq is in the linear revmap. */
>   	if (hwirq < domain->revmap_size)
> -		return domain->linear_revmap[hwirq];
> +		return domain->revmap[hwirq];
>   
>   	rcu_read_lock();
>   	data = radix_tree_lookup(&domain->revmap_tree, hwirq);
> 


From matthias.bgg at gmail.com  Tue Apr  6 12:27:04 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 13:27:04 +0200
Subject: [PATCH 1/5] arm64: dts: mediatek: mt8167: add mmsys node
In-Reply-To: <20210405200821.2203458-1-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
Message-ID: <0cf78980-5e3d-20f5-87cb-cc2488071211@gmail.com>



On 05/04/2021 22:08, Fabien Parent wrote:
> Add node for MMSYS.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Applied to v5.12-next/dts64-2

Thanks

> ---
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 156fbdad01fb..9d765034dfb0 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -125,5 +125,11 @@ pio: pinctrl at 1000b000 {
>  			#interrupt-cells = <2>;
>  			interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
>  		};
> +
> +		mmsys: mmsys at 14000000 {
> +			compatible = "mediatek,mt8167-mmsys", "syscon";
> +			reg = <0 0x14000000 0 0x1000>;
> +			#clock-cells = <1>;
> +		};
>  	};
>  };
> 


From mark.rutland at arm.com  Tue Apr  6 12:27:06 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:27:06 +0100
Subject: [PATCH v5 03/18] mm: add generic function_nocfi macro
In-Reply-To: <20210401233216.2540591-4-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-4-samitolvanen@google.com>
Message-ID: <20210406112656.GA96480@C02TD0UTHF1T.local>

On Thu, Apr 01, 2021 at 04:32:01PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function addresses
> in instrumented C code with jump table addresses. This means that
> __pa_symbol(function) returns the physical address of the jump table
> entry instead of the actual function, which may not work as the jump
> table code will immediately jump to a virtual address that may not be
> mapped.
> 
> To avoid this address space confusion, this change adds a generic
> definition for function_nocfi(), which architectures that support CFI
> can override. The typical implementation of would use inline assembly
> to take the function address, which avoids compiler instrumentation.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>

FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  include/linux/mm.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8ba434287387..22cce9c7dd05 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -124,6 +124,16 @@ extern int mmap_rnd_compat_bits __read_mostly;
>  #define lm_alias(x)	__va(__pa_symbol(x))
>  #endif
>  
> +/*
> + * With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> + * instrumented C code with jump table addresses. Architectures that
> + * support CFI can define this macro to return the actual function address
> + * when needed.
> + */
> +#ifndef function_nocfi
> +#define function_nocfi(x) (x)
> +#endif
> +
>  /*
>   * To prevent common memory management code establishing
>   * a zero page mapping on a read fault.
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From mark.rutland at arm.com  Tue Apr  6 12:27:35 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:27:35 +0100
Subject: [PATCH v5 11/18] psci: use function_nocfi for cpu_resume
In-Reply-To: <20210401233216.2540591-12-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-12-samitolvanen@google.com>
Message-ID: <20210406112735.GB96480@C02TD0UTHF1T.local>

On Thu, Apr 01, 2021 at 04:32:09PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function pointers with
> jump table addresses, which results in __pa_symbol returning the
> physical address of the jump table entry. As the jump table contains
> an immediate jump to an EL1 virtual address, this typically won't
> work as intended. Use function_nocfi to get the actual address of
> cpu_resume.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  drivers/firmware/psci/psci.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index f5fc429cae3f..64344e84bd63 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -325,8 +325,9 @@ static int __init psci_features(u32 psci_func_id)
>  static int psci_suspend_finisher(unsigned long state)
>  {
>  	u32 power_state = state;
> +	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
>  
> -	return psci_ops.cpu_suspend(power_state, __pa_symbol(cpu_resume));
> +	return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
>  }
>  
>  int psci_cpu_suspend_enter(u32 state)
> @@ -344,8 +345,10 @@ int psci_cpu_suspend_enter(u32 state)
>  
>  static int psci_system_suspend(unsigned long unused)
>  {
> +	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
> +
>  	return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
> -			      __pa_symbol(cpu_resume), 0, 0);
> +			      pa_cpu_resume, 0, 0);
>  }
>  
>  static int psci_system_suspend_enter(suspend_state_t state)
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From matthias.bgg at gmail.com  Tue Apr  6 12:27:43 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 13:27:43 +0200
Subject: [PATCH 2/5] arm64: dts: mediatek: mt8167: add smi_common node
In-Reply-To: <20210405200821.2203458-2-fparent@baylibre.com>
References: <20210405200821.2203458-1-fparent@baylibre.com>
 <20210405200821.2203458-2-fparent@baylibre.com>
Message-ID: <d3251cd0-784e-da8e-6065-edd2cccf3e9c@gmail.com>



On 05/04/2021 22:08, Fabien Parent wrote:
> Add the smi_common node.
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Applied to v5.12-next/dts64-2

I'll leave the others for a v2 of the series, as there a small comments.

Regards,
Matthias

> ---
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 9d765034dfb0..4b951f81db9e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -131,5 +131,14 @@ mmsys: mmsys at 14000000 {
>  			reg = <0 0x14000000 0 0x1000>;
>  			#clock-cells = <1>;
>  		};
> +
> +		smi_common: smi at 14017000 {
> +			compatible = "mediatek,mt8167-smi-common";
> +			reg = <0 0x14017000 0 0x1000>;
> +			clocks = <&mmsys CLK_MM_SMI_COMMON>,
> +				 <&mmsys CLK_MM_SMI_COMMON>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
> +		};
>  	};
>  };
> 


From fparent at baylibre.com  Tue Apr  6 12:32:40 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:32:40 +0200
Subject: [PATCH v2 1/3] =?UTF-8?q?=F0=9F=93=A4=20arm64:=20dts:=20mediatek:?=
 =?UTF-8?q?=20mt8167:=20add=20larb=20nodes?=
Message-ID: <20210406113243.2665847-1-fparent@baylibre.com>

Add larb nodes for MT8167:
* larb0 is used for display (dsi and hdmi)
* larb1 is used for camera (csi)
* larb2 is used for the video hardware decoder

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---

Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V2:
	* Removed unneeded mediatek,larb-id property

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 30 ++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 4b951f81db9e..bbddd4b22d3e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -140,5 +140,35 @@ smi_common: smi at 14017000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
 		};
+
+		larb0: larb at 14016000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x14016000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&mmsys CLK_MM_SMI_LARB0>,
+				 <&mmsys CLK_MM_SMI_LARB0>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
+		larb1: larb at 15001000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x15001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&imgsys CLK_IMG_LARB1_SMI>,
+				 <&imgsys CLK_IMG_LARB1_SMI>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
+		};
+
+		larb2: larb at 16010000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x16010000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&vdecsys CLK_VDEC_CKEN>,
+				 <&vdecsys CLK_VDEC_LARB1_CKEN>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Tue Apr  6 12:32:41 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:32:41 +0200
Subject: [PATCH v2 2/3] =?UTF-8?q?=F0=9F=93=A4=20arm64:=20dts:=20mediatek:?=
 =?UTF-8?q?=20mt8167:=20add=20iommu=20node?=
In-Reply-To: <20210406113243.2665847-1-fparent@baylibre.com>
References: <20210406113243.2665847-1-fparent@baylibre.com>
Message-ID: <20210406113243.2665847-2-fparent@baylibre.com>

Add node for the MT8167's IOMMU.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V2:
	* Remove unneeded cell-index property

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index bbddd4b22d3e..9029051624a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -170,5 +170,13 @@ larb2: larb at 16010000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
 		};
+
+		iommu: m4u at 10203000 {
+			compatible = "mediatek,mt8167-m4u";
+			reg = <0 0x10203000 0 0x1000>;
+			mediatek,larbs = <&larb0 &larb1 &larb2>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
+			#iommu-cells = <1>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Tue Apr  6 12:32:42 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:32:42 +0200
Subject: [PATCH v2 3/3] =?UTF-8?q?=F0=9F=93=A4=20arm64:=20dts:=20mediatek:?=
 =?UTF-8?q?=20mt8167:=20add=20some=20DRM=20nodes?=
In-Reply-To: <20210406113243.2665847-1-fparent@baylibre.com>
References: <20210406113243.2665847-1-fparent@baylibre.com>
Message-ID: <20210406113243.2665847-3-fparent@baylibre.com>

Add all the DRM nodes required to get DSI to work on MT8167 SoC.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V2:
	* No changes

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 149 +++++++++++++++++++++++
 1 file changed, 149 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 9029051624a6..17942095944e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -16,6 +16,19 @@
 / {
 	compatible = "mediatek,mt8167";
 
+	aliases {
+		aal0 = &aal;
+		ccorr0 = &ccorr;
+		color0 = &color;
+		dither0 = &dither;
+		dsi0 = &dsi;
+		ovl0 = &ovl0;
+		pwm0 = &disp_pwm;
+		rdma0 = &rdma0;
+		rdma1 = &rdma1;
+		wdma0 = &wdma;
+	};
+
 	soc {
 		topckgen: topckgen at 10000000 {
 			compatible = "mediatek,mt8167-topckgen", "syscon";
@@ -114,6 +127,13 @@ vdecsys: syscon at 16000000 {
 			#clock-cells = <1>;
 		};
 
+		mutex: mutex at 14015000 {
+			compatible = "mediatek,mt8167-disp-mutex";
+			reg = <0 0x14015000 0 0x1000>;
+			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
 		pio: pinctrl at 1000b000 {
 			compatible = "mediatek,mt8167-pinctrl";
 			reg = <0 0x1000b000 0 0x1000>;
@@ -126,6 +146,135 @@ pio: pinctrl at 1000b000 {
 			interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		rdma1: rdma1 at 1400a000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x1400a000 0 0x1000>;
+			interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA1>;
+			mediatek,larb = <&larb0>;
+		};
+
+		disp_pwm: disp_pwm at 1100f000 {
+			compatible = "mediatek,mt8167-disp-pwm",
+				     "mediatek,mt8173-disp-pwn";
+			reg = <0 0x1100f000 0 0x1000>;
+			#pwm-cells = <2>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&topckgen CLK_TOP_PWM_SEL>,
+				 <&topckgen CLK_TOP_PWM_MM>,
+				  <&mmsys CLK_MM_DISP_PWM_26M>,
+				  <&mmsys CLK_MM_DISP_PWM_MM>;
+			clock-names = "pwm_sel",
+				      "pwm_mm",
+				      "main",
+				      "mm";
+			status = "disabled";
+		};
+
+		dsi: dsi at 14012000 {
+			compatible = "mediatek,mt8167-dsi",
+				     "mediatek,mt2701-dsi";
+			reg = <0 0x14012000 0 0x1000>;
+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DSI_ENGINE>,
+				 <&mmsys CLK_MM_DSI_DIGITAL>,
+				 <&mipi_tx>;
+			clock-names = "engine", "digital", "hs";
+			phys = <&mipi_tx>;
+			phy-names = "dphy";
+			status = "disabled";
+		};
+
+		mipi_tx: mipi_dphy at 14018000 {
+			compatible = "mediatek,mt8167-mipi-tx",
+				     "mediatek,mt2701-mipi-tx";
+			reg = <0 0x14018000 0 0x90>;
+			clocks = <&topckgen CLK_TOP_MIPI_26M_DBG>;
+			clock-output-names = "mipi_tx0_pll";
+			#clock-cells = <0>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
+
+		ovl0: ovl0 at 14007000 {
+			compatible = "mediatek,mt8167-disp-ovl",
+				     "mediatek,mt8173-disp-ovl";
+			reg = <0 0x14007000 0 0x1000>;
+			interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_OVL0>;
+			iommus = <&iommu M4U_PORT_DISP_OVL0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		rdma0: rdma0 at 14009000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x14009000 0 0x1000>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		color: color at 1400c000 {
+			compatible = "mediatek,mt8167-disp-color",
+				     "mediatek,mt8173-disp-color";
+			reg = <0 0x1400c000 0 0x1000>;
+			interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_COLOR>;
+		};
+
+		ccorr: ccorr at 1400d000 {
+			compatible = "mediatek,mt8167-disp-ccorr",
+				     "mediatek,mt8183-disp-ccorr";
+			reg = <0 0x1400d000 0 0x1000>;
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_CCORR>;
+		};
+
+		aal: aal at 1400e000 {
+			compatible = "mediatek,mt8167-disp-aal";
+			reg = <0 0x1400e000 0 0x1000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_AAL>;
+		};
+
+		gamma: gamma at 1400f000 {
+			compatible = "mediatek,mt8167-disp-gamma",
+				     "mediatek,mt8173-disp-gamma";
+			reg = <0 0x1400f000 0 0x1000>;
+			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_GAMMA>;
+		};
+
+		dither: dither at 14010000 {
+			compatible = "mediatek,mt8167-disp-dither";
+			reg = <0 0x14010000 0 0x1000>;
+			interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_DITHER>;
+		};
+
+		wdma: wdma0 at 1400b000 {
+			compatible = "mediatek,mt8167-disp-wdma";
+			reg = <0 0x1400b000 0 0x1000>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_WDMA>;
+			iommus = <&iommu M4U_PORT_DISP_WDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
 		mmsys: mmsys at 14000000 {
 			compatible = "mediatek,mt8167-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.31.0



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:48 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:48 +0800
Subject: [PATCH V2 00/18] i2c: imx-lpi2c: New features and bug fixes
Message-ID: <20210406113306.2633595-1-xiaoning.wang@nxp.com>

Hi,

According to V1's feedback, V2 has been modified.
For summary of the changes, please refer to the header of each patch file.

Added some dt-bindings and dts patches.
At the same time, a patch has been added to fix the problem that data larger
than 256 bytes cannot be sent in one frame in PIO mode.

Clark Wang (14):
  i2c: imx-lpi2c: add ipg clk for lpi2c driver
  ARM: dts: imx7ulp: add the missing lpi2c ipg clock
  ARM: dts: imx7ulp: add the missing lpi2c nodes
  ARM64: dts: imx8: add the missing lpi2c ipg clock
  ARM64: dts: imx8: change i2c irq number to non-combined
  i2c: imx-lpi2c: increase PM timeout to avoid operate clk frequently
  i2c: imx-lpi2c: add bus recovery feature
  dt-bindings: i2c: imx-lpi2c: Add bus recovery example
  i2c: imx-lpi2c: fix i2c timing issue
  i2c: imx-lpi2c: fix type char overflow issue when calculating the
    clock cycle
  i2c: imx-lpi2c: add edma mode support
  dt-bindings: i2c: imx-lpi2c: Add dma configuration example
  ARM: dts: imx7ulp: add dma configurations for lpi2c
  ARM: dts: imx7ulp: add the missing status property of lpi2c5
  i2c: imx-lpi2c: fix pio mode cannot send 256+ bytes in one frame

Fugang Duan (1):
  i2c: imx-lpi2c: manage irq resource request/release in runtime pm

Gao Pan (2):
  i2c: imx-lpi2c: directly retrun ISR when detect a NACK
  i2c: imx-lpi2c: add debug message when i2c peripheral clk doesn't work

 .../bindings/i2c/i2c-imx-lpi2c.yaml           |  26 +
 arch/arm/boot/dts/imx7ulp.dtsi                |  50 +-
 .../arm64/boot/dts/freescale/imx8-ss-dma.dtsi |  32 +-
 drivers/i2c/busses/i2c-imx-lpi2c.c            | 506 ++++++++++++++++--
 4 files changed, 548 insertions(+), 66 deletions(-)

-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:49 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:49 +0800
Subject: [PATCH V2 01/18] i2c: imx-lpi2c: directly retrun ISR when detect a
 NACK
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-2-xiaoning.wang@nxp.com>

From: Gao Pan <pandy.gao at nxp.com>

A NACK flag in ISR means i2c bus error. In such codition,
there is no need to do read/write operation. It's better
to return ISR directly and then stop i2c transfer.

Signed-off-by: Gao Pan <pandy.gao at nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong at nxp.com>
---
V2 changes:
 - No change. Has been reviewed by Dong Aisheng <aisheng.dong at nxp.com> in V1.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 9db6ccded5e9..bbf44ac95021 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -507,15 +507,17 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
 	lpi2c_imx_intctrl(lpi2c_imx, 0);
 	temp = readl(lpi2c_imx->base + LPI2C_MSR);
 
+	if (temp & MSR_NDF) {
+		complete(&lpi2c_imx->complete);
+		goto ret;
+	}
+
 	if (temp & MSR_RDF)
 		lpi2c_imx_read_rxfifo(lpi2c_imx);
-
-	if (temp & MSR_TDF)
+	else if (temp & MSR_TDF)
 		lpi2c_imx_write_txfifo(lpi2c_imx);
 
-	if (temp & MSR_NDF)
-		complete(&lpi2c_imx->complete);
-
+ret:
 	return IRQ_HANDLED;
 }
 
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:50 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:50 +0800
Subject: [PATCH V2 02/18] i2c: imx-lpi2c: add ipg clk for lpi2c driver
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-3-xiaoning.wang@nxp.com>

The lpi2c IP needs two clks: ipg clk and per clk. The old lpi2c
driver missed ipg clk. This patch adds ipg clk for lpi2c driver.

Signed-off-by: Gao Pan <pandy.gao at nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Acked-by: Fugang Duan <fugang.duan at nxp.com>
---
V2 changes:
 - Merge two clocks' prepare funtions to lpi2c_imx_clocks_prepare().
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 61 +++++++++++++++++++++---------
 1 file changed, 44 insertions(+), 17 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index bbf44ac95021..89b7b0795f51 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -94,7 +94,8 @@ enum lpi2c_imx_pincfg {
 
 struct lpi2c_imx_struct {
 	struct i2c_adapter	adapter;
-	struct clk		*clk;
+	struct clk		*clk_per;
+	struct clk		*clk_ipg;
 	void __iomem		*base;
 	__u8			*rx_buf;
 	__u8			*tx_buf;
@@ -207,7 +208,7 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
 
 	lpi2c_imx_set_mode(lpi2c_imx);
 
-	clk_rate = clk_get_rate(lpi2c_imx->clk);
+	clk_rate = clk_get_rate(lpi2c_imx->clk_per);
 	if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
 		filt = 0;
 	else
@@ -538,6 +539,34 @@ static const struct of_device_id lpi2c_imx_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, lpi2c_imx_of_match);
 
+static int lpi2c_imx_clocks_prepare(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	int ret = 0;
+
+	ret = clk_prepare_enable(lpi2c_imx->clk_per);
+	if (ret) {
+		dev_err(lpi2c_imx->adapter.dev.parent,
+				"can't enable I2C per clock, ret=%d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lpi2c_imx->clk_ipg);
+	if (ret) {
+		clk_disable_unprepare(lpi2c_imx->clk_per);
+		dev_err(lpi2c_imx->adapter.dev.parent,
+				"can't enable I2C ipg clock, ret=%d\n", ret);
+		return ret;
+	}
+
+	return ret;
+}
+
+static void lpi2c_imx_clocks_unprepare(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	clk_disable_unprepare(lpi2c_imx->clk_ipg);
+	clk_disable_unprepare(lpi2c_imx->clk_per);
+}
+
 static int lpi2c_imx_probe(struct platform_device *pdev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx;
@@ -563,10 +592,16 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	strlcpy(lpi2c_imx->adapter.name, pdev->name,
 		sizeof(lpi2c_imx->adapter.name));
 
-	lpi2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
-	if (IS_ERR(lpi2c_imx->clk)) {
+	lpi2c_imx->clk_per = devm_clk_get(&pdev->dev, "per");
+	if (IS_ERR(lpi2c_imx->clk_per)) {
 		dev_err(&pdev->dev, "can't get I2C peripheral clock\n");
-		return PTR_ERR(lpi2c_imx->clk);
+		return PTR_ERR(lpi2c_imx->clk_per);
+	}
+
+	lpi2c_imx->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
+	if (IS_ERR(lpi2c_imx->clk_ipg)) {
+		dev_err(&pdev->dev, "can't get I2C ipg clock\n");
+		return PTR_ERR(lpi2c_imx->clk_ipg);
 	}
 
 	ret = of_property_read_u32(pdev->dev.of_node,
@@ -584,11 +619,9 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
 	platform_set_drvdata(pdev, lpi2c_imx);
 
-	ret = clk_prepare_enable(lpi2c_imx->clk);
-	if (ret) {
-		dev_err(&pdev->dev, "clk enable failed %d\n", ret);
+	ret = lpi2c_imx_clocks_prepare(lpi2c_imx);
+	if (ret)
 		return ret;
-	}
 
 	pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_TIMEOUT);
 	pm_runtime_use_autosuspend(&pdev->dev);
@@ -635,7 +668,7 @@ static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
 
-	clk_disable_unprepare(lpi2c_imx->clk);
+	lpi2c_imx_clocks_unprepare(lpi2c_imx);
 	pinctrl_pm_select_sleep_state(dev);
 
 	return 0;
@@ -644,16 +677,10 @@ static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
 static int __maybe_unused lpi2c_runtime_resume(struct device *dev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
-	int ret;
 
 	pinctrl_pm_select_default_state(dev);
-	ret = clk_prepare_enable(lpi2c_imx->clk);
-	if (ret) {
-		dev_err(dev, "failed to enable I2C clock, ret=%d\n", ret);
-		return ret;
-	}
 
-	return 0;
+	return lpi2c_imx_clocks_prepare(lpi2c_imx);
 }
 
 static const struct dev_pm_ops lpi2c_pm_ops = {
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:51 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:51 +0800
Subject: [PATCH V2 03/18] ARM: dts: imx7ulp: add the missing lpi2c ipg clock
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-4-xiaoning.wang@nxp.com>

The lpi2c driver has add the missing ipg clock.
So add the ipg clock here for all lpi2c nodes.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 arch/arm/boot/dts/imx7ulp.dtsi | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index b7ea37ad4e55..eb0d4b8f624d 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -328,8 +328,9 @@ lpi2c6: i2c at 40a40000 {
 			compatible = "fsl,imx7ulp-lpi2c";
 			reg = <0x40a40000 0x10000>;
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>;
-			clock-names = "ipg";
+			clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>,
+				 <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>;
+			clock-names = "per", "ipg";
 			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
@@ -340,8 +341,9 @@ lpi2c7: i2c at 40a50000 {
 			compatible = "fsl,imx7ulp-lpi2c";
 			reg = <0x40a50000 0x10000>;
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>;
-			clock-names = "ipg";
+			clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>,
+				 <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>;
+			clock-names = "per", "ipg";
 			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:52 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:52 +0800
Subject: [PATCH V2 04/18] ARM: dts: imx7ulp: add the missing lpi2c nodes
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-5-xiaoning.wang@nxp.com>

Add the missing lpi2c4/5 nodes for imx7ulp.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 arch/arm/boot/dts/imx7ulp.dtsi | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index eb0d4b8f624d..0c51fa79c0bc 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -22,8 +22,10 @@ aliases {
 		gpio1 = &gpio_ptd;
 		gpio2 = &gpio_pte;
 		gpio3 = &gpio_ptf;
-		i2c0 = &lpi2c6;
-		i2c1 = &lpi2c7;
+		i2c0 = &lpi2c4;
+		i2c1 = &lpi2c5;
+		i2c2 = &lpi2c6;
+		i2c3 = &lpi2c7;
 		mmc0 = &usdhc0;
 		mmc1 = &usdhc1;
 		serial0 = &lpuart4;
@@ -145,6 +147,31 @@ sec_jr1: jr at 2000 {
 			};
 		};
 
+		lpi2c4: lpi2c4 at 402b0000 {
+			compatible = "fsl,imx7ulp-lpi2c";
+			reg = <0x402b0000 0x10000>;
+			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc2 IMX7ULP_CLK_LPI2C4>,
+				 <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>;
+			clock-names = "per", "ipg";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPI2C4>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		lpi2c5: lpi2c5 at 402c0000 {
+			compatible = "fsl,imx7ulp-lpi2c";
+			reg = <0x402c0000 0x10000>;
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc2 IMX7ULP_CLK_LPI2C5>,
+				 <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>;
+			clock-names = "per", "ipg";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPI2C5>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+		};
+
 		lpuart4: serial at 402d0000 {
 			compatible = "fsl,imx7ulp-lpuart";
 			reg = <0x402d0000 0x1000>;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:53 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:53 +0800
Subject: [PATCH V2 05/18] ARM64: dts: imx8: add the missing lpi2c ipg clock
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-6-xiaoning.wang@nxp.com>

The lpi2c driver has add the missing ipg clock.
So add the ipg clock here for all lpi2c nodes.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 .../arm64/boot/dts/freescale/imx8-ss-dma.dtsi | 24 ++++++++++++-------
 1 file changed, 16 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 960a802b8b6e..b5ed12a06538 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
@@ -111,8 +111,10 @@ uart3_lpcg: clock-controller at 5a490000 {
 	i2c0: i2c at 5a800000 {
 		reg = <0x5a800000 0x4000>;
 		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&i2c0_lpcg IMX_LPCG_CLK_0>;
-		clock-names = "per";
+		interrupt-parent = <&gic>;
+		clocks = <&i2c0_lpcg IMX_LPCG_CLK_0>,
+			 <&i2c0_lpcg IMX_LPCG_CLK_4>;
+		clock-names = "per", "ipg";
 		assigned-clocks = <&clk IMX_SC_R_I2C_0 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <24000000>;
 		power-domains = <&pd IMX_SC_R_I2C_0>;
@@ -122,8 +124,10 @@ i2c0: i2c at 5a800000 {
 	i2c1: i2c at 5a810000 {
 		reg = <0x5a810000 0x4000>;
 		interrupts = <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&i2c1_lpcg IMX_LPCG_CLK_0>;
-		clock-names = "per";
+		interrupt-parent = <&gic>;
+		clocks = <&i2c1_lpcg IMX_LPCG_CLK_0>,
+			 <&i2c1_lpcg IMX_LPCG_CLK_4>;
+		clock-names = "per", "ipg";
 		assigned-clocks = <&clk IMX_SC_R_I2C_1 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <24000000>;
 		power-domains = <&pd IMX_SC_R_I2C_1>;
@@ -133,8 +137,10 @@ i2c1: i2c at 5a810000 {
 	i2c2: i2c at 5a820000 {
 		reg = <0x5a820000 0x4000>;
 		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&i2c2_lpcg IMX_LPCG_CLK_0>;
-		clock-names = "per";
+		interrupt-parent = <&gic>;
+		clocks = <&i2c2_lpcg IMX_LPCG_CLK_0>,
+			 <&i2c2_lpcg IMX_LPCG_CLK_4>;
+		clock-names = "per", "ipg";
 		assigned-clocks = <&clk IMX_SC_R_I2C_2 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <24000000>;
 		power-domains = <&pd IMX_SC_R_I2C_2>;
@@ -144,8 +150,10 @@ i2c2: i2c at 5a820000 {
 	i2c3: i2c at 5a830000 {
 		reg = <0x5a830000 0x4000>;
 		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&i2c3_lpcg IMX_LPCG_CLK_0>;
-		clock-names = "per";
+		interrupt-parent = <&gic>;
+		clocks = <&i2c3_lpcg IMX_LPCG_CLK_0>,
+			 <&i2c3_lpcg IMX_LPCG_CLK_4>;
+		clock-names = "per", "ipg";
 		assigned-clocks = <&clk IMX_SC_R_I2C_3 IMX_SC_PM_CLK_PER>;
 		assigned-clock-rates = <24000000>;
 		power-domains = <&pd IMX_SC_R_I2C_3>;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:54 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:54 +0800
Subject: [PATCH V2 06/18] ARM64: dts: imx8: change i2c irq number to
 non-combined
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-7-xiaoning.wang@nxp.com>

Combined interrupt number may cause unexcepted irq event when using DMA
and too many interrupts will be generated.
So change all i2c interrupts number to non-combined for
imx8qxp/8qm/8dxl.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
index b5ed12a06538..9ba57f04859b 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
@@ -110,7 +110,7 @@ uart3_lpcg: clock-controller at 5a490000 {
 
 	i2c0: i2c at 5a800000 {
 		reg = <0x5a800000 0x4000>;
-		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-parent = <&gic>;
 		clocks = <&i2c0_lpcg IMX_LPCG_CLK_0>,
 			 <&i2c0_lpcg IMX_LPCG_CLK_4>;
@@ -123,7 +123,7 @@ i2c0: i2c at 5a800000 {
 
 	i2c1: i2c at 5a810000 {
 		reg = <0x5a810000 0x4000>;
-		interrupts = <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-parent = <&gic>;
 		clocks = <&i2c1_lpcg IMX_LPCG_CLK_0>,
 			 <&i2c1_lpcg IMX_LPCG_CLK_4>;
@@ -136,7 +136,7 @@ i2c1: i2c at 5a810000 {
 
 	i2c2: i2c at 5a820000 {
 		reg = <0x5a820000 0x4000>;
-		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-parent = <&gic>;
 		clocks = <&i2c2_lpcg IMX_LPCG_CLK_0>,
 			 <&i2c2_lpcg IMX_LPCG_CLK_4>;
@@ -149,7 +149,7 @@ i2c2: i2c at 5a820000 {
 
 	i2c3: i2c at 5a830000 {
 		reg = <0x5a830000 0x4000>;
-		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-parent = <&gic>;
 		clocks = <&i2c3_lpcg IMX_LPCG_CLK_0>,
 			 <&i2c3_lpcg IMX_LPCG_CLK_4>;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:55 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:55 +0800
Subject: [PATCH V2 07/18] i2c: imx-lpi2c: manage irq resource request/release
 in runtime pm
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-8-xiaoning.wang@nxp.com>

From: Fugang Duan <fugang.duan at nxp.com>

Manage irq resource request/release in runtime pm to save irq domain's
power.

Signed-off-by: Frank Li <Frank.Li at nxp.com>
Signed-off-by: Fugang Duan <fugang.duan at nxp.com>
Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Frank Li <Frank.Li at nxp.com>
---
V2 changes:
 - Change to use request_irq/free_irq.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 89b7b0795f51..333209ba81c1 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -94,6 +94,7 @@ enum lpi2c_imx_pincfg {
 
 struct lpi2c_imx_struct {
 	struct i2c_adapter	adapter;
+	int			irq;
 	struct clk		*clk_per;
 	struct clk		*clk_ipg;
 	void __iomem		*base;
@@ -571,7 +572,7 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx;
 	unsigned int temp;
-	int irq, ret;
+	int ret;
 
 	lpi2c_imx = devm_kzalloc(&pdev->dev, sizeof(*lpi2c_imx), GFP_KERNEL);
 	if (!lpi2c_imx)
@@ -581,9 +582,9 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	if (IS_ERR(lpi2c_imx->base))
 		return PTR_ERR(lpi2c_imx->base);
 
-	irq = platform_get_irq(pdev, 0);
-	if (irq < 0)
-		return irq;
+	lpi2c_imx->irq = platform_get_irq(pdev, 0);
+	if (lpi2c_imx->irq < 0)
+		return lpi2c_imx->irq;
 
 	lpi2c_imx->adapter.owner	= THIS_MODULE;
 	lpi2c_imx->adapter.algo		= &lpi2c_imx_algo;
@@ -609,13 +610,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	if (ret)
 		lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
 
-	ret = devm_request_irq(&pdev->dev, irq, lpi2c_imx_isr, 0,
-			       pdev->name, lpi2c_imx);
-	if (ret) {
-		dev_err(&pdev->dev, "can't claim irq %d\n", irq);
-		return ret;
-	}
-
 	i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
 	platform_set_drvdata(pdev, lpi2c_imx);
 
@@ -668,6 +662,7 @@ static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
 
+	free_irq(lpi2c_imx->irq, lpi2c_imx);
 	lpi2c_imx_clocks_unprepare(lpi2c_imx);
 	pinctrl_pm_select_sleep_state(dev);
 
@@ -677,10 +672,21 @@ static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
 static int __maybe_unused lpi2c_runtime_resume(struct device *dev)
 {
 	struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
+	int ret = 0;
 
 	pinctrl_pm_select_default_state(dev);
+	ret = lpi2c_imx_clocks_prepare(lpi2c_imx);
+	if (ret)
+		return ret;
 
-	return lpi2c_imx_clocks_prepare(lpi2c_imx);
+	ret = request_irq(lpi2c_imx->irq, lpi2c_imx_isr, 0,
+			       dev_name(dev), lpi2c_imx);
+	if (ret) {
+		dev_err(dev, "can't claim irq %d\n", lpi2c_imx->irq);
+		return ret;
+	}
+
+	return ret;
 }
 
 static const struct dev_pm_ops lpi2c_pm_ops = {
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:56 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:56 +0800
Subject: [PATCH V2 08/18] i2c: imx-lpi2c: add debug message when i2c
 peripheral clk doesn't work
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-9-xiaoning.wang@nxp.com>

From: Gao Pan <pandy.gao at nxp.com>

add debug message when i2c peripheral clk rate is 0, then
directly return -EINVAL.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Signed-off-by: Gao Pan <pandy.gao at nxp.com>
Reviewed-by: Andy Duan <fugang.duan at nxp.com>
---
V2 changes:
 - Add my signed-off.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 333209ba81c1..dfec334712c2 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -210,6 +210,11 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
 	lpi2c_imx_set_mode(lpi2c_imx);
 
 	clk_rate = clk_get_rate(lpi2c_imx->clk_per);
+	if (!clk_rate) {
+		dev_dbg(&lpi2c_imx->adapter.dev, "clk_per rate is 0\n");
+		return -EINVAL;
+	}
+
 	if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
 		filt = 0;
 	else
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:57 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:57 +0800
Subject: [PATCH V2 09/18] i2c: imx-lpi2c: increase PM timeout to avoid operate
 clk frequently
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-10-xiaoning.wang@nxp.com>

Switching the clock frequently will affect the data transmission
efficiency, and prolong the timeout to reduce autosuspend times for
lpi2c.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Acked-by: Fugang Duan <fugang.duan at nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong at nxp.com>
---
V2 changes:
 - No change. Has been reviewed by Dong Aisheng <aisheng.dong at nxp.com> in V1.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index dfec334712c2..77ceb743b282 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -75,7 +75,7 @@
 #define I2C_CLK_RATIO	2
 #define CHUNK_DATA	256
 
-#define I2C_PM_TIMEOUT		10 /* ms */
+#define I2C_PM_TIMEOUT		1000 /* ms */
 
 enum lpi2c_imx_mode {
 	STANDARD,	/* 100+Kbps */
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:58 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:58 +0800
Subject: [PATCH V2 10/18] i2c: imx-lpi2c: add bus recovery feature
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-11-xiaoning.wang@nxp.com>

Add bus recovery feature for LPI2C.
Need add gpio pinctrl, scl-gpios and sda-gpios configuration in dts.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - No change. Add dt-bindings in the next patch.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 83 ++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 77ceb743b282..77dd6ee5a4a8 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -18,6 +18,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_gpio.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
@@ -108,6 +109,11 @@ struct lpi2c_imx_struct {
 	unsigned int		txfifosize;
 	unsigned int		rxfifosize;
 	enum lpi2c_imx_mode	mode;
+
+	struct i2c_bus_recovery_info rinfo;
+	struct pinctrl *pinctrl;
+	struct pinctrl_state *pinctrl_pins_default;
+	struct pinctrl_state *pinctrl_pins_gpio;
 };
 
 static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx,
@@ -135,6 +141,8 @@ static int lpi2c_imx_bus_busy(struct lpi2c_imx_struct *lpi2c_imx)
 
 		if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
 			dev_dbg(&lpi2c_imx->adapter.dev, "bus not work\n");
+			if (lpi2c_imx->adapter.bus_recovery_info)
+				i2c_recover_bus(&lpi2c_imx->adapter);
 			return -ETIMEDOUT;
 		}
 		schedule();
@@ -192,6 +200,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct *lpi2c_imx)
 
 		if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
 			dev_dbg(&lpi2c_imx->adapter.dev, "stop timeout\n");
+			if (lpi2c_imx->adapter.bus_recovery_info)
+				i2c_recover_bus(&lpi2c_imx->adapter);
 			break;
 		}
 		schedule();
@@ -329,6 +339,8 @@ static int lpi2c_imx_txfifo_empty(struct lpi2c_imx_struct *lpi2c_imx)
 
 		if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
 			dev_dbg(&lpi2c_imx->adapter.dev, "txfifo empty timeout\n");
+			if (lpi2c_imx->adapter.bus_recovery_info)
+				i2c_recover_bus(&lpi2c_imx->adapter);
 			return -ETIMEDOUT;
 		}
 		schedule();
@@ -528,6 +540,71 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static void lpi2c_imx_prepare_recovery(struct i2c_adapter *adap)
+{
+	struct lpi2c_imx_struct *lpi2c_imx;
+
+	lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
+
+	pinctrl_select_state(lpi2c_imx->pinctrl, lpi2c_imx->pinctrl_pins_gpio);
+}
+
+static void lpi2c_imx_unprepare_recovery(struct i2c_adapter *adap)
+{
+	struct lpi2c_imx_struct *lpi2c_imx;
+
+	lpi2c_imx = container_of(adap, struct lpi2c_imx_struct, adapter);
+
+	pinctrl_select_state(lpi2c_imx->pinctrl, lpi2c_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
+ * described in the device tree by a separate pinctrl state "gpio". If
+ * this is missing this is not a big problem, the only implication is
+ * that we can't do bus recovery.
+ */
+static int lpi2c_imx_init_recovery_info(struct lpi2c_imx_struct *lpi2c_imx,
+		struct platform_device *pdev)
+{
+	struct i2c_bus_recovery_info *rinfo = &lpi2c_imx->rinfo;
+
+	lpi2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
+	if (!lpi2c_imx->pinctrl || IS_ERR(lpi2c_imx->pinctrl)) {
+		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
+		return PTR_ERR(lpi2c_imx->pinctrl);
+	}
+
+	lpi2c_imx->pinctrl_pins_default = pinctrl_lookup_state(lpi2c_imx->pinctrl,
+			PINCTRL_STATE_DEFAULT);
+	lpi2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(lpi2c_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(lpi2c_imx->pinctrl_pins_default) ||
+		   IS_ERR(lpi2c_imx->pinctrl_pins_gpio)) {
+		dev_dbg(&pdev->dev, "recovery information incomplete\n");
+		return 0;
+	}
+
+	dev_info(&pdev->dev, "using scl%s for recovery\n",
+		 rinfo->sda_gpiod ? ",sda" : "");
+
+	rinfo->prepare_recovery = lpi2c_imx_prepare_recovery;
+	rinfo->unprepare_recovery = lpi2c_imx_unprepare_recovery;
+	rinfo->recover_bus = i2c_generic_scl_recovery;
+	lpi2c_imx->adapter.bus_recovery_info = rinfo;
+
+	return 0;
+}
+
 static u32 lpi2c_imx_func(struct i2c_adapter *adapter)
 {
 	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
@@ -632,6 +709,12 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
 	lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
 
+	/* Init optional bus recovery function */
+	ret = lpi2c_imx_init_recovery_info(lpi2c_imx, pdev);
+	/* Give it another chance if pinctrl used is not ready yet */
+	if (ret == -EPROBE_DEFER)
+		goto rpm_disable;
+
 	ret = i2c_add_adapter(&lpi2c_imx->adapter);
 	if (ret)
 		goto rpm_disable;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:32:59 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:32:59 +0800
Subject: [PATCH V2 11/18] dt-bindings: i2c: imx-lpi2c: Add bus recovery example
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-12-xiaoning.wang@nxp.com>

Add i2c bus recovery configuration example.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml     | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
index 29b9447f3b84..0a4b28827dcc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
@@ -42,6 +42,15 @@ properties:
   power-domains:
     maxItems: 1
 
+  pinctrl-names:
+    minItems: 1
+
+  scl-gpios:
+    maxItems: 1
+
+  sda-gpios:
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -61,4 +70,9 @@ examples:
         interrupt-parent = <&intc>;
         interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
         clocks = <&clks IMX7ULP_CLK_LPI2C7>;
+        pinctrl-names = "default","gpio";
+        pinctrl-0 = <&pinctrl_i2c>;
+        pinctrl-1 = <&pinctrl_i2c_recovery>;
+        scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+        sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
     };
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:00 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:00 +0800
Subject: [PATCH V2 12/18] i2c: imx-lpi2c: fix i2c timing issue
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-13-xiaoning.wang@nxp.com>

The clkhi and clklo ratio was not very precise before that can make the
time of START/STOP/HIGH LEVEL out of specification.

Therefore, the calculation of these times has been modified in this patch.
At the same time, the mode rate definition of i2c is corrected.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Fugang Duan <fugang.duan at nxp.com>
---
V2 changes:
 - No change.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 77dd6ee5a4a8..d124c4000823 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -73,17 +73,17 @@
 #define MCFGR1_IGNACK	BIT(9)
 #define MRDR_RXEMPTY	BIT(14)
 
-#define I2C_CLK_RATIO	2
+#define I2C_CLK_RATIO	24 / 59
 #define CHUNK_DATA	256
 
 #define I2C_PM_TIMEOUT		1000 /* ms */
 
 enum lpi2c_imx_mode {
-	STANDARD,	/* 100+Kbps */
-	FAST,		/* 400+Kbps */
-	FAST_PLUS,	/* 1.0+Mbps */
-	HS,		/* 3.4+Mbps */
-	ULTRA_FAST,	/* 5.0+Mbps */
+	STANDARD,	/* <=100Kbps */
+	FAST,		/* <=400Kbps */
+	FAST_PLUS,	/* <=1.0Mbps */
+	HS,		/* <=3.4Mbps */
+	ULTRA_FAST,	/* <=5.0Mbps */
 };
 
 enum lpi2c_imx_pincfg {
@@ -156,13 +156,13 @@ static void lpi2c_imx_set_mode(struct lpi2c_imx_struct *lpi2c_imx)
 	unsigned int bitrate = lpi2c_imx->bitrate;
 	enum lpi2c_imx_mode mode;
 
-	if (bitrate < I2C_MAX_FAST_MODE_FREQ)
+	if (bitrate <= I2C_MAX_STANDARD_MODE_FREQ)
 		mode = STANDARD;
-	else if (bitrate < I2C_MAX_FAST_MODE_PLUS_FREQ)
+	else if (bitrate <= I2C_MAX_FAST_MODE_FREQ)
 		mode = FAST;
-	else if (bitrate < I2C_MAX_HIGH_SPEED_MODE_FREQ)
+	else if (bitrate <= I2C_MAX_FAST_MODE_PLUS_FREQ)
 		mode = FAST_PLUS;
-	else if (bitrate < I2C_MAX_ULTRA_FAST_MODE_FREQ)
+	else if (bitrate <= I2C_MAX_HIGH_SPEED_MODE_FREQ)
 		mode = HS;
 	else
 		mode = ULTRA_FAST;
@@ -209,7 +209,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct *lpi2c_imx)
 	} while (1);
 }
 
-/* CLKLO = I2C_CLK_RATIO * CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2 */
+/* CLKLO = (1 - I2C_CLK_RATIO) * clk_cycle, SETHOLD = CLKHI, DATAVD = CLKHI/2
+   CLKHI = I2C_CLK_RATIO * clk_cycle */
 static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
 {
 	u8 prescale, filt, sethold, clkhi, clklo, datavd;
@@ -232,8 +233,8 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
 
 	for (prescale = 0; prescale <= 7; prescale++) {
 		clk_cycle = clk_rate / ((1 << prescale) * lpi2c_imx->bitrate)
-			    - 3 - (filt >> 1);
-		clkhi = (clk_cycle + I2C_CLK_RATIO) / (I2C_CLK_RATIO + 1);
+			    - (2 + filt) / (1 << prescale);
+		clkhi = clk_cycle * I2C_CLK_RATIO;
 		clklo = clk_cycle - clkhi;
 		if (clklo < 64)
 			break;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:01 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:01 +0800
Subject: [PATCH V2 13/18] i2c: imx-lpi2c: fix type char overflow issue when
 calculating the clock cycle
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-14-xiaoning.wang@nxp.com>

Claim clkhi and clklo as integer type to avoid possible calculation
errors caused by data overflow.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Fugang Duan <fugang.duan at nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong at nxp.com>
---
V2 changes:
 - No change. Has been reviewed by Dong Aisheng <aisheng.dong at nxp.com> in V1.
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index d124c4000823..c2f8e49660ea 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -213,8 +213,8 @@ static void lpi2c_imx_stop(struct lpi2c_imx_struct *lpi2c_imx)
    CLKHI = I2C_CLK_RATIO * clk_cycle */
 static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
 {
-	u8 prescale, filt, sethold, clkhi, clklo, datavd;
-	unsigned int clk_rate, clk_cycle;
+	u8 prescale, filt, sethold, datavd;
+	unsigned int clk_rate, clk_cycle, clkhi, clklo;
 	enum lpi2c_imx_pincfg pincfg;
 	unsigned int temp;
 
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:02 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:02 +0800
Subject: [PATCH V2 14/18] i2c: imx-lpi2c: add edma mode support
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-15-xiaoning.wang@nxp.com>

Add eDMA receive and send mode support.
Support to read and write data larger than 256 bytes in one frame.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Li Jun <jun.li at nxp.com>
---
V2 changes:
 - change marco I2C_USE_PIO to DMA_ERR_I2C_USE_PIO. It is a error code defined
   in this driver to 
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 290 ++++++++++++++++++++++++++++-
 1 file changed, 288 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index c2f8e49660ea..d1a56d52f19f 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -8,6 +8,8 @@
 #include <linux/clk.h>
 #include <linux/completion.h>
 #include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/errno.h>
 #include <linux/i2c.h>
@@ -31,6 +33,7 @@
 #define LPI2C_MCR	0x10	/* i2c contrl register */
 #define LPI2C_MSR	0x14	/* i2c status register */
 #define LPI2C_MIER	0x18	/* i2c interrupt enable */
+#define LPI2C_MDER	0x1C	/* i2c DMA enable */
 #define LPI2C_MCFGR0	0x20	/* i2c master configuration */
 #define LPI2C_MCFGR1	0x24	/* i2c master configuration */
 #define LPI2C_MCFGR2	0x28	/* i2c master configuration */
@@ -72,11 +75,15 @@
 #define MCFGR1_AUTOSTOP	BIT(8)
 #define MCFGR1_IGNACK	BIT(9)
 #define MRDR_RXEMPTY	BIT(14)
+#define MDER_TDDE	BIT(0)
+#define MDER_RDDE	BIT(1)
 
 #define I2C_CLK_RATIO	24 / 59
 #define CHUNK_DATA	256
 
 #define I2C_PM_TIMEOUT		1000 /* ms */
+#define I2C_DMA_THRESHOLD	16 /* bytes */
+#define DMA_ERR_I2C_USE_PIO	(-150)
 
 enum lpi2c_imx_mode {
 	STANDARD,	/* <=100Kbps */
@@ -95,6 +102,7 @@ enum lpi2c_imx_pincfg {
 
 struct lpi2c_imx_struct {
 	struct i2c_adapter	adapter;
+	resource_size_t		phy_addr;
 	int			irq;
 	struct clk		*clk_per;
 	struct clk		*clk_ipg;
@@ -114,6 +122,17 @@ struct lpi2c_imx_struct {
 	struct pinctrl *pinctrl;
 	struct pinctrl_state *pinctrl_pins_default;
 	struct pinctrl_state *pinctrl_pins_gpio;
+
+	bool			can_use_dma;
+	bool			using_dma;
+	bool			xferred;
+	struct i2c_msg		*msg;
+	dma_addr_t		dma_addr;
+	struct dma_chan		*dma_tx;
+	struct dma_chan		*dma_rx;
+	enum dma_data_direction dma_direction;
+	u8			*dma_buf;
+	unsigned int		dma_len;
 };
 
 static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx,
@@ -289,6 +308,9 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct *lpi2c_imx)
 	if (ret)
 		goto rpm_put;
 
+	if (lpi2c_imx->can_use_dma)
+		writel(MDER_TDDE | MDER_RDDE, lpi2c_imx->base + LPI2C_MDER);
+
 	temp = readl(lpi2c_imx->base + LPI2C_MCR);
 	temp |= MCR_MEN;
 	writel(temp, lpi2c_imx->base + LPI2C_MCR);
@@ -462,6 +484,154 @@ static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
 	lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);
 }
 
+static void lpi2c_dma_unmap(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	struct dma_chan *chan = lpi2c_imx->dma_direction == DMA_FROM_DEVICE
+				? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
+
+	dma_unmap_single(chan->device->dev, lpi2c_imx->dma_addr,
+			 lpi2c_imx->dma_len, lpi2c_imx->dma_direction);
+
+	lpi2c_imx->dma_direction = DMA_NONE;
+}
+
+static void lpi2c_cleanup_dma(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	if (lpi2c_imx->dma_direction == DMA_NONE)
+		return;
+	else if (lpi2c_imx->dma_direction == DMA_FROM_DEVICE)
+		dmaengine_terminate_all(lpi2c_imx->dma_rx);
+	else if (lpi2c_imx->dma_direction == DMA_TO_DEVICE)
+		dmaengine_terminate_all(lpi2c_imx->dma_tx);
+
+	lpi2c_dma_unmap(lpi2c_imx);
+}
+
+static void lpi2c_dma_callback(void *data)
+{
+	struct lpi2c_imx_struct *lpi2c_imx = (struct lpi2c_imx_struct *)data;
+
+	lpi2c_dma_unmap(lpi2c_imx);
+	writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
+	lpi2c_imx->xferred = true;
+
+	complete(&lpi2c_imx->complete);
+}
+
+static int lpi2c_dma_submit(struct lpi2c_imx_struct *lpi2c_imx,
+			   struct i2c_msg *msg)
+{
+	bool read = msg->flags & I2C_M_RD;
+	enum dma_data_direction dir = read ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+	struct dma_chan *chan = read ? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
+	struct dma_async_tx_descriptor *txdesc;
+	dma_cookie_t cookie;
+
+	lpi2c_imx->dma_len = read ? msg->len - 1 : msg->len;
+	lpi2c_imx->msg = msg;
+	lpi2c_imx->dma_direction = dir;
+
+	if (IS_ERR(chan))
+		return PTR_ERR(chan);
+
+	lpi2c_imx->dma_addr = dma_map_single(chan->device->dev,
+					     lpi2c_imx->dma_buf,
+					     lpi2c_imx->dma_len, dir);
+	if (dma_mapping_error(chan->device->dev, lpi2c_imx->dma_addr)) {
+		dev_err(&lpi2c_imx->adapter.dev, "dma map failed, use pio\n");
+		return -EINVAL;
+	}
+
+	txdesc = dmaengine_prep_slave_single(chan, lpi2c_imx->dma_addr,
+					lpi2c_imx->dma_len, read ?
+					DMA_DEV_TO_MEM : DMA_MEM_TO_DEV,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!txdesc) {
+		dev_err(&lpi2c_imx->adapter.dev, "dma prep slave sg failed, use pio\n");
+		lpi2c_cleanup_dma(lpi2c_imx);
+		return -EINVAL;
+	}
+
+	reinit_completion(&lpi2c_imx->complete);
+	txdesc->callback = lpi2c_dma_callback;
+	txdesc->callback_param = (void *)lpi2c_imx;
+
+	cookie = dmaengine_submit(txdesc);
+	if (dma_submit_error(cookie)) {
+		dev_err(&lpi2c_imx->adapter.dev, "submitting dma failed, use pio\n");
+		lpi2c_cleanup_dma(lpi2c_imx);
+		return -EINVAL;
+	}
+
+	lpi2c_imx_intctrl(lpi2c_imx, MIER_NDIE);
+
+	dma_async_issue_pending(chan);
+
+	return 0;
+}
+
+static bool is_use_dma(struct lpi2c_imx_struct *lpi2c_imx, struct i2c_msg *msg)
+{
+	if (!lpi2c_imx->can_use_dma)
+		return false;
+
+	if (msg->len < I2C_DMA_THRESHOLD)
+		return false;
+
+	return true;
+}
+
+static int lpi2c_imx_dma_push_rx_cmd(struct lpi2c_imx_struct *lpi2c_imx,
+				 struct i2c_msg *msg)
+{
+	unsigned int temp, rx_remain;
+	unsigned long orig_jiffies = jiffies;
+
+	if ((msg->flags & I2C_M_RD)) {
+		rx_remain = msg->len;
+		do {
+			temp = rx_remain > CHUNK_DATA ?
+				CHUNK_DATA - 1 : rx_remain - 1;
+			temp |= (RECV_DATA << 8);
+			while ((readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff) > (lpi2c_imx->rxfifosize >> 1)) {
+				if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(1000))) {
+					dev_dbg(&lpi2c_imx->adapter.dev, "txfifo empty timeout\n");
+					if (lpi2c_imx->adapter.bus_recovery_info)
+						i2c_recover_bus(&lpi2c_imx->adapter);
+					return -ETIMEDOUT;
+				}
+				schedule();
+			}
+			writel(temp, lpi2c_imx->base + LPI2C_MTDR);
+			rx_remain = rx_remain - (temp & 0xff) - 1;
+		} while (rx_remain > 0);
+	}
+
+	return 0;
+}
+
+static int lpi2c_dma_xfer(struct lpi2c_imx_struct *lpi2c_imx,
+			   struct i2c_msg *msg)
+{
+	int result;
+
+	result = lpi2c_dma_submit(lpi2c_imx, msg);
+	if (!result) {
+		result = lpi2c_imx_dma_push_rx_cmd(lpi2c_imx, msg);
+		if (result)
+			return result;
+		result = lpi2c_imx_msg_complete(lpi2c_imx);
+		return result;
+	}
+
+	/* DMA xfer failed, try to use PIO, clean up dma things */
+	i2c_put_dma_safe_msg_buf(lpi2c_imx->dma_buf, lpi2c_imx->msg,
+				 lpi2c_imx->xferred);
+	lpi2c_cleanup_dma(lpi2c_imx);
+
+	return DMA_ERR_I2C_USE_PIO;
+}
+
 static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
 			  struct i2c_msg *msgs, int num)
 {
@@ -474,6 +644,9 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
 		return result;
 
 	for (i = 0; i < num; i++) {
+		lpi2c_imx->xferred = false;
+		lpi2c_imx->using_dma = false;
+
 		result = lpi2c_imx_start(lpi2c_imx, &msgs[i]);
 		if (result)
 			goto disable;
@@ -482,9 +655,24 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
 		if (num == 1 && msgs[0].len == 0)
 			goto stop;
 
+		if (is_use_dma(lpi2c_imx, &msgs[i])) {
+			lpi2c_imx->using_dma = true;
+
+			writel(0x1, lpi2c_imx->base + LPI2C_MFCR);
+
+			lpi2c_imx->dma_buf = i2c_get_dma_safe_msg_buf(&msgs[i],
+							    I2C_DMA_THRESHOLD);
+			if (lpi2c_imx->dma_buf) {
+				result = lpi2c_dma_xfer(lpi2c_imx, &msgs[i]);
+				if (result != DMA_ERR_I2C_USE_PIO)
+					goto stop;
+			}
+		}
+
+		lpi2c_imx->using_dma = false;
 		lpi2c_imx->delivered = 0;
 		lpi2c_imx->msglen = msgs[i].len;
-		init_completion(&lpi2c_imx->complete);
+		reinit_completion(&lpi2c_imx->complete);
 
 		if (msgs[i].flags & I2C_M_RD)
 			lpi2c_imx_read(lpi2c_imx, &msgs[i]);
@@ -503,7 +691,16 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
 	}
 
 stop:
-	lpi2c_imx_stop(lpi2c_imx);
+	if (!lpi2c_imx->using_dma)
+		lpi2c_imx_stop(lpi2c_imx);
+	else {
+		i2c_put_dma_safe_msg_buf(lpi2c_imx->dma_buf, lpi2c_imx->msg,
+					 lpi2c_imx->xferred);
+		if (result) {
+			lpi2c_cleanup_dma(lpi2c_imx);
+			writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
+		}
+	}
 
 	temp = readl(lpi2c_imx->base + LPI2C_MSR);
 	if ((temp & MSR_NDF) && !result)
@@ -528,6 +725,10 @@ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
 	temp = readl(lpi2c_imx->base + LPI2C_MSR);
 
 	if (temp & MSR_NDF) {
+		if (lpi2c_imx->using_dma) {
+			lpi2c_cleanup_dma(lpi2c_imx);
+			writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
+		}
 		complete(&lpi2c_imx->complete);
 		goto ret;
 	}
@@ -623,6 +824,77 @@ static const struct of_device_id lpi2c_imx_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, lpi2c_imx_of_match);
 
+static void lpi2c_dma_exit(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	if (lpi2c_imx->dma_rx) {
+		dma_release_channel(lpi2c_imx->dma_rx);
+		lpi2c_imx->dma_rx = NULL;
+	}
+
+	if (lpi2c_imx->dma_tx) {
+		dma_release_channel(lpi2c_imx->dma_tx);
+		lpi2c_imx->dma_tx = NULL;
+	}
+}
+
+static int lpi2c_dma_init(struct device *dev,
+			  struct lpi2c_imx_struct *lpi2c_imx)
+{
+	int ret;
+	struct dma_slave_config dma_sconfig;
+
+	/* Prepare for TX DMA: */
+	lpi2c_imx->dma_tx = dma_request_chan(dev, "tx");
+	if (IS_ERR(lpi2c_imx->dma_tx)) {
+		ret = PTR_ERR(lpi2c_imx->dma_tx);
+		dev_err(dev, "can't get the TX DMA channel, error %d!\n", ret);
+		lpi2c_imx->dma_tx = NULL;
+		goto err;
+	}
+
+	dma_sconfig.dst_addr = lpi2c_imx->phy_addr + LPI2C_MTDR;
+	dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.dst_maxburst = 1;
+	dma_sconfig.direction = DMA_MEM_TO_DEV;
+	ret = dmaengine_slave_config(lpi2c_imx->dma_tx, &dma_sconfig);
+	if (ret < 0) {
+		dev_err(dev, "can't configure tx channel (%d)\n", ret);
+		goto fail_tx;
+	}
+
+	/* Prepare for RX DMA: */
+	lpi2c_imx->dma_rx = dma_request_chan(dev, "rx");
+	if (IS_ERR(lpi2c_imx->dma_rx)) {
+		ret = PTR_ERR(lpi2c_imx->dma_rx);
+		dev_err(dev, "can't get the RX DMA channel, error %d\n", ret);
+		lpi2c_imx->dma_rx = NULL;
+		goto fail_tx;
+	}
+
+	dma_sconfig.src_addr = lpi2c_imx->phy_addr + LPI2C_MRDR;
+	dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.src_maxburst = 1;
+	dma_sconfig.direction = DMA_DEV_TO_MEM;
+	ret = dmaengine_slave_config(lpi2c_imx->dma_rx, &dma_sconfig);
+	if (ret < 0) {
+		dev_err(dev, "can't configure rx channel (%d)\n", ret);
+		goto fail_rx;
+	}
+
+	lpi2c_imx->can_use_dma = true;
+	lpi2c_imx->using_dma = false;
+
+	return 0;
+fail_rx:
+	dma_release_channel(lpi2c_imx->dma_rx);
+fail_tx:
+	dma_release_channel(lpi2c_imx->dma_tx);
+err:
+	lpi2c_dma_exit(lpi2c_imx);
+	lpi2c_imx->can_use_dma = false;
+	return ret;
+}
+
 static int lpi2c_imx_clocks_prepare(struct lpi2c_imx_struct *lpi2c_imx)
 {
 	int ret = 0;
@@ -656,15 +928,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	struct lpi2c_imx_struct *lpi2c_imx;
 	unsigned int temp;
 	int ret;
+	struct resource *res;
 
 	lpi2c_imx = devm_kzalloc(&pdev->dev, sizeof(*lpi2c_imx), GFP_KERNEL);
 	if (!lpi2c_imx)
 		return -ENOMEM;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	lpi2c_imx->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(lpi2c_imx->base))
 		return PTR_ERR(lpi2c_imx->base);
 
+	lpi2c_imx->phy_addr = (dma_addr_t)res->start;
 	lpi2c_imx->irq = platform_get_irq(pdev, 0);
 	if (lpi2c_imx->irq < 0)
 		return lpi2c_imx->irq;
@@ -716,6 +991,17 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	if (ret == -EPROBE_DEFER)
 		goto rpm_disable;
 
+	/* Init DMA */
+	lpi2c_imx->dma_direction = DMA_NONE;
+	ret = lpi2c_dma_init(&pdev->dev, lpi2c_imx);
+	if (ret) {
+		dev_err_probe(&pdev->dev, ret, "dma setup error %d, use pio\n", ret);
+		if (ret == -EPROBE_DEFER)
+			goto rpm_disable;
+	}
+
+	init_completion(&lpi2c_imx->complete);
+
 	ret = i2c_add_adapter(&lpi2c_imx->adapter);
 	if (ret)
 		goto rpm_disable;
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:03 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:03 +0800
Subject: [PATCH V2 15/18] dt-bindings: i2c: imx-lpi2c: Add dma configuration
 example
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-16-xiaoning.wang@nxp.com>

Add i2c bus dma mode configuration example.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml       | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
index 0a4b28827dcc..3868fec0cf27 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
@@ -51,6 +51,16 @@ properties:
   sda-gpios:
     maxItems: 1
 
+  dmas:
+    minItems: 2
+    maxItems: 2
+
+  dma-names:
+    minItems: 2
+    maxItems: 2
+    items:
+      enum: [ "tx", "rx" ]
+
 required:
   - compatible
   - reg
@@ -75,4 +85,6 @@ examples:
         pinctrl-1 = <&pinctrl_i2c_recovery>;
         scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
         sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+        dmas = <&edma1 0 16>, <&edma1 0 15>;
+        dma-names = "tx","rx";
     };
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:04 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:04 +0800
Subject: [PATCH V2 16/18] ARM: dts: imx7ulp: add dma configurations for lpi2c
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-17-xiaoning.wang@nxp.com>

Enable dma support for all lpi2c nodes.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 arch/arm/boot/dts/imx7ulp.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index 0c51fa79c0bc..a6681836ca05 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -157,6 +157,8 @@ lpi2c4: lpi2c4 at 402b0000 {
 			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPI2C4>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
+			dmas = <&edma1 0 10>, <&edma1 0 9>;
+			dma-names = "tx","rx";
 			status = "disabled";
 		};
 
@@ -170,6 +172,8 @@ lpi2c5: lpi2c5 at 402c0000 {
 			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPI2C5>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
+			dmas = <&edma1 0 12>, <&edma1 0 11>;
+			dma-names = "tx","rx";
 		};
 
 		lpuart4: serial at 402d0000 {
@@ -361,6 +365,8 @@ lpi2c6: i2c at 40a40000 {
 			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
+			dmas = <&edma1 0 14>, <&edma1 0 13>;
+			dma-names = "tx","rx";
 			status = "disabled";
 		};
 
@@ -374,6 +380,8 @@ lpi2c7: i2c at 40a50000 {
 			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>;
 			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
 			assigned-clock-rates = <48000000>;
+			dmas = <&edma1 0 16>, <&edma1 0 15>;
+			dma-names = "tx","rx";
 			status = "disabled";
 		};
 
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:05 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:05 +0800
Subject: [PATCH V2 17/18] ARM: dts: imx7ulp: add the missing status property
 of lpi2c5
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-18-xiaoning.wang@nxp.com>

Add the missing lpi2c5 status property.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 arch/arm/boot/dts/imx7ulp.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index a6681836ca05..b16441e18231 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -174,6 +174,7 @@ lpi2c5: lpi2c5 at 402c0000 {
 			assigned-clock-rates = <48000000>;
 			dmas = <&edma1 0 12>, <&edma1 0 11>;
 			dma-names = "tx","rx";
+			status = "disabled";
 		};
 
 		lpuart4: serial at 402d0000 {
-- 
2.25.1



From xiaoning.wang at nxp.com  Tue Apr  6 12:33:06 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue,  6 Apr 2021 19:33:06 +0800
Subject: [PATCH V2 18/18] i2c: imx-lpi2c: fix pio mode cannot send 256+ bytes
 in one frame
In-Reply-To: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
Message-ID: <20210406113306.2633595-19-xiaoning.wang@nxp.com>

The next MTDR command should be filled before the last receive command is
fininshed. Otherwise, a NACK will be sent when the current MTDR command
is finished. It causes lpi2c cannot send the next chunk data
successfully.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
V2 changes:
 - New patch added in V2
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 43 +++++++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 3c0f16a79185..8d908b9b5112 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -112,6 +112,7 @@ struct lpi2c_imx_struct {
 	struct completion	complete;
 	unsigned int		msglen;
 	unsigned int		delivered;
+	unsigned int		remain_chunk_num;
 	unsigned int		block_data;
 	unsigned int		bitrate;
 	unsigned int		txfifosize;
@@ -413,6 +414,28 @@ static void lpi2c_imx_write_txfifo(struct lpi2c_imx_struct *lpi2c_imx)
 		complete(&lpi2c_imx->complete);
 }
 
+static void lpi2c_imx_pio_push_rx_cmd(struct lpi2c_imx_struct *lpi2c_imx)
+{
+	unsigned int remaining, temp;
+	u8 last_chunk_num = lpi2c_imx->msglen % CHUNK_DATA;
+
+	if (lpi2c_imx->remain_chunk_num > 0 &&
+		(lpi2c_imx->delivered % CHUNK_DATA) > (CHUNK_DATA >> 1)) {
+		if ((readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff) <=
+						(lpi2c_imx->rxfifosize >> 1)) {
+			if (last_chunk_num)
+				remaining = (lpi2c_imx->remain_chunk_num - 1) *
+					    CHUNK_DATA + last_chunk_num;
+			else
+				remaining = lpi2c_imx->remain_chunk_num * CHUNK_DATA;
+			temp = (remaining > CHUNK_DATA ? CHUNK_DATA : remaining) - 1;
+			temp |= (RECV_DATA << 8);
+			writel(temp, lpi2c_imx->base + LPI2C_MTDR);
+			lpi2c_imx->remain_chunk_num--;
+		}
+	}
+}
+
 static void lpi2c_imx_read_rxfifo(struct lpi2c_imx_struct *lpi2c_imx)
 {
 	unsigned int blocklen, remaining;
@@ -420,10 +443,16 @@ static void lpi2c_imx_read_rxfifo(struct lpi2c_imx_struct *lpi2c_imx)
 
 	do {
 		data = readl(lpi2c_imx->base + LPI2C_MRDR);
-		if (data & MRDR_RXEMPTY)
-			break;
+		if (data & MRDR_RXEMPTY) {
+			if (lpi2c_imx->delivered == lpi2c_imx->msglen ||
+			    lpi2c_imx->block_data)
+				break;
+			else
+				continue;
+		}
 
 		lpi2c_imx->rx_buf[lpi2c_imx->delivered++] = data & 0xff;
+		lpi2c_imx_pio_push_rx_cmd(lpi2c_imx);
 	} while (1);
 
 	/*
@@ -451,13 +480,9 @@ static void lpi2c_imx_read_rxfifo(struct lpi2c_imx_struct *lpi2c_imx)
 		temp = remaining;
 		temp |= (RECV_DATA << 8);
 		writel(temp, lpi2c_imx->base + LPI2C_MTDR);
-	} else if (!(lpi2c_imx->delivered & 0xff)) {
-		temp = (remaining > CHUNK_DATA ? CHUNK_DATA : remaining) - 1;
-		temp |= (RECV_DATA << 8);
-		writel(temp, lpi2c_imx->base + LPI2C_MTDR);
 	}
 
-	lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE);
+	lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);
 }
 
 static void lpi2c_imx_write(struct lpi2c_imx_struct *lpi2c_imx,
@@ -477,6 +502,10 @@ static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
 	lpi2c_imx->block_data = msgs->flags & I2C_M_RECV_LEN;
 
 	lpi2c_imx_set_rx_watermark(lpi2c_imx);
+	if (msgs->len > CHUNK_DATA) {
+		temp = CHUNK_DATA - 1;
+		lpi2c_imx->remain_chunk_num = DIV_ROUND_UP(msgs->len, CHUNK_DATA) - 1;
+	}
 	temp = msgs->len > CHUNK_DATA ? CHUNK_DATA - 1 : msgs->len - 1;
 	temp |= (RECV_DATA << 8);
 	writel(temp, lpi2c_imx->base + LPI2C_MTDR);
-- 
2.25.1



From fparent at baylibre.com  Tue Apr  6 12:36:28 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:36:28 +0200
Subject: [PATCH v3 1/3] arm64: dts: mediatek: mt8167: add larb nodes
Message-ID: <20210406113631.2675029-1-fparent@baylibre.com>

Add larb nodes for MT8167:
* larb0 is used for display (dsi and hdmi)
* larb1 is used for camera (csi)
* larb2 is used for the video hardware decoder

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---

Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V3:
	* Removed unicode character in commit summary
V2:
	* Removed unneeded mediatek,larb-id property

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 30 ++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 4b951f81db9e..bbddd4b22d3e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -140,5 +140,35 @@ smi_common: smi at 14017000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
 		};
+
+		larb0: larb at 14016000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x14016000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&mmsys CLK_MM_SMI_LARB0>,
+				 <&mmsys CLK_MM_SMI_LARB0>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
+		larb1: larb at 15001000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x15001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&imgsys CLK_IMG_LARB1_SMI>,
+				 <&imgsys CLK_IMG_LARB1_SMI>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
+		};
+
+		larb2: larb at 16010000 {
+			compatible = "mediatek,mt8167-smi-larb";
+			reg = <0 0x16010000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			clocks = <&vdecsys CLK_VDEC_CKEN>,
+				 <&vdecsys CLK_VDEC_LARB1_CKEN>;
+			clock-names = "apb", "smi";
+			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Tue Apr  6 12:36:29 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:36:29 +0200
Subject: [PATCH v3 2/3] arm64: dts: mediatek: mt8167: add iommu node
In-Reply-To: <20210406113631.2675029-1-fparent@baylibre.com>
References: <20210406113631.2675029-1-fparent@baylibre.com>
Message-ID: <20210406113631.2675029-2-fparent@baylibre.com>

Add node for the MT8167's IOMMU.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V3:
	* Removed unicode character in commit summary
V2:
	* Remove unneeded cell-index property

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index bbddd4b22d3e..9029051624a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -170,5 +170,13 @@ larb2: larb at 16010000 {
 			clock-names = "apb", "smi";
 			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
 		};
+
+		iommu: m4u at 10203000 {
+			compatible = "mediatek,mt8167-m4u";
+			reg = <0 0x10203000 0 0x1000>;
+			mediatek,larbs = <&larb0 &larb1 &larb2>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
+			#iommu-cells = <1>;
+		};
 	};
 };
-- 
2.31.0



From fparent at baylibre.com  Tue Apr  6 12:36:30 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Tue,  6 Apr 2021 13:36:30 +0200
Subject: [PATCH v3 3/3] arm64: dts: mediatek: mt8167: add some DRM nodes
In-Reply-To: <20210406113631.2675029-1-fparent@baylibre.com>
References: <20210406113631.2675029-1-fparent@baylibre.com>
Message-ID: <20210406113631.2675029-3-fparent@baylibre.com>

Add all the DRM nodes required to get DSI to work on MT8167 SoC.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
---
Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2

V3:
	* Removed unicode character in commit summary
V2:
	* No changes

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 149 +++++++++++++++++++++++
 1 file changed, 149 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 9029051624a6..17942095944e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -16,6 +16,19 @@
 / {
 	compatible = "mediatek,mt8167";
 
+	aliases {
+		aal0 = &aal;
+		ccorr0 = &ccorr;
+		color0 = &color;
+		dither0 = &dither;
+		dsi0 = &dsi;
+		ovl0 = &ovl0;
+		pwm0 = &disp_pwm;
+		rdma0 = &rdma0;
+		rdma1 = &rdma1;
+		wdma0 = &wdma;
+	};
+
 	soc {
 		topckgen: topckgen at 10000000 {
 			compatible = "mediatek,mt8167-topckgen", "syscon";
@@ -114,6 +127,13 @@ vdecsys: syscon at 16000000 {
 			#clock-cells = <1>;
 		};
 
+		mutex: mutex at 14015000 {
+			compatible = "mediatek,mt8167-disp-mutex";
+			reg = <0 0x14015000 0 0x1000>;
+			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+		};
+
 		pio: pinctrl at 1000b000 {
 			compatible = "mediatek,mt8167-pinctrl";
 			reg = <0 0x1000b000 0 0x1000>;
@@ -126,6 +146,135 @@ pio: pinctrl at 1000b000 {
 			interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		rdma1: rdma1 at 1400a000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x1400a000 0 0x1000>;
+			interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA1>;
+			mediatek,larb = <&larb0>;
+		};
+
+		disp_pwm: disp_pwm at 1100f000 {
+			compatible = "mediatek,mt8167-disp-pwm",
+				     "mediatek,mt8173-disp-pwn";
+			reg = <0 0x1100f000 0 0x1000>;
+			#pwm-cells = <2>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&topckgen CLK_TOP_PWM_SEL>,
+				 <&topckgen CLK_TOP_PWM_MM>,
+				  <&mmsys CLK_MM_DISP_PWM_26M>,
+				  <&mmsys CLK_MM_DISP_PWM_MM>;
+			clock-names = "pwm_sel",
+				      "pwm_mm",
+				      "main",
+				      "mm";
+			status = "disabled";
+		};
+
+		dsi: dsi at 14012000 {
+			compatible = "mediatek,mt8167-dsi",
+				     "mediatek,mt2701-dsi";
+			reg = <0 0x14012000 0 0x1000>;
+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DSI_ENGINE>,
+				 <&mmsys CLK_MM_DSI_DIGITAL>,
+				 <&mipi_tx>;
+			clock-names = "engine", "digital", "hs";
+			phys = <&mipi_tx>;
+			phy-names = "dphy";
+			status = "disabled";
+		};
+
+		mipi_tx: mipi_dphy at 14018000 {
+			compatible = "mediatek,mt8167-mipi-tx",
+				     "mediatek,mt2701-mipi-tx";
+			reg = <0 0x14018000 0 0x90>;
+			clocks = <&topckgen CLK_TOP_MIPI_26M_DBG>;
+			clock-output-names = "mipi_tx0_pll";
+			#clock-cells = <0>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
+
+		ovl0: ovl0 at 14007000 {
+			compatible = "mediatek,mt8167-disp-ovl",
+				     "mediatek,mt8173-disp-ovl";
+			reg = <0 0x14007000 0 0x1000>;
+			interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_OVL0>;
+			iommus = <&iommu M4U_PORT_DISP_OVL0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		rdma0: rdma0 at 14009000 {
+			compatible = "mediatek,mt8167-disp-rdma",
+				     "mediatek,mt2701-disp-rdma";
+			reg = <0 0x14009000 0 0x1000>;
+			interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+			iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
+		color: color at 1400c000 {
+			compatible = "mediatek,mt8167-disp-color",
+				     "mediatek,mt8173-disp-color";
+			reg = <0 0x1400c000 0 0x1000>;
+			interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_COLOR>;
+		};
+
+		ccorr: ccorr at 1400d000 {
+			compatible = "mediatek,mt8167-disp-ccorr",
+				     "mediatek,mt8183-disp-ccorr";
+			reg = <0 0x1400d000 0 0x1000>;
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_CCORR>;
+		};
+
+		aal: aal at 1400e000 {
+			compatible = "mediatek,mt8167-disp-aal";
+			reg = <0 0x1400e000 0 0x1000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_AAL>;
+		};
+
+		gamma: gamma at 1400f000 {
+			compatible = "mediatek,mt8167-disp-gamma",
+				     "mediatek,mt8173-disp-gamma";
+			reg = <0 0x1400f000 0 0x1000>;
+			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_GAMMA>;
+		};
+
+		dither: dither at 14010000 {
+			compatible = "mediatek,mt8167-disp-dither";
+			reg = <0 0x14010000 0 0x1000>;
+			interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_DITHER>;
+		};
+
+		wdma: wdma0 at 1400b000 {
+			compatible = "mediatek,mt8167-disp-wdma";
+			reg = <0 0x1400b000 0 0x1000>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
+			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_DISP_WDMA>;
+			iommus = <&iommu M4U_PORT_DISP_WDMA0>;
+			mediatek,larb = <&larb0>;
+		};
+
 		mmsys: mmsys at 14000000 {
 			compatible = "mediatek,mt8167-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.31.0



From mark.rutland at arm.com  Tue Apr  6 12:36:57 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:36:57 +0100
Subject: [PATCH v5 12/18] arm64: implement function_nocfi
In-Reply-To: <20210401233216.2540591-13-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-13-samitolvanen@google.com>
Message-ID: <20210406113657.GC96480@C02TD0UTHF1T.local>

On Thu, Apr 01, 2021 at 04:32:10PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> instrumented C code with jump table addresses. This change implements
> the function_nocfi() macro, which returns the actual function address
> instead.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>

I think that it's unfortunate that we have to drop to assembly here, but
given this is infrequent I agree it's not the end of the world, so:

Acked-by: Mark Rutland <mark.rutland at arm.com>

> ---
>  arch/arm64/include/asm/memory.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..b55410afd3d1 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -321,6 +321,21 @@ static inline void *phys_to_virt(phys_addr_t x)
>  #define virt_to_pfn(x)		__phys_to_pfn(__virt_to_phys((unsigned long)(x)))
>  #define sym_to_pfn(x)		__phys_to_pfn(__pa_symbol(x))
>  
> +#ifdef CONFIG_CFI_CLANG
> +/*
> + * With CONFIG_CFI_CLANG, the compiler replaces function address
> + * references with the address of the function's CFI jump table
> + * entry. The function_nocfi macro always returns the address of the
> + * actual function instead.
> + */
> +#define function_nocfi(x) ({						\
> +	void *addr;							\
> +	asm("adrp %0, " __stringify(x) "\n\t"				\
> +	    "add  %0, %0, :lo12:" __stringify(x) : "=r" (addr));	\

If it's not too painful, could we please move the asm constrain onto its
own line? That makes it slightly easier to read, and aligns with what
we've (mostly) done elsewhere in arm64.

Not a big deal either way, and the ack stands regardless.

Thanks,
Mark.

> +	addr;								\
> +})
> +#endif
> +
>  /*
>   *  virt_to_page(x)	convert a _valid_ virtual address to struct page *
>   *  virt_addr_valid(x)	indicates whether a virtual address is valid
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From will at kernel.org  Tue Apr  6 12:40:32 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 12:40:32 +0100
Subject: [RFC PATCH 3/6] iommu: Use bitmap to calculate page size in
 iommu_pgsize()
In-Reply-To: <7c012a63e8a5ad1856aac08995e6f154@codeaurora.org>
References: <20210401164738.9513-1-will@kernel.org>
 <20210401164738.9513-4-will@kernel.org>
 <7c012a63e8a5ad1856aac08995e6f154@codeaurora.org>
Message-ID: <20210406114032.GA13747@willie-the-truck>

On Thu, Apr 01, 2021 at 06:39:35PM -0700, isaacm at codeaurora.org wrote:
> On 2021-04-01 09:47, Will Deacon wrote:
> > Avoid the potential for shifting values by amounts greater than the
> > width of their type by using a bitmap to compute page size in
> > iommu_pgsize().
> > 
> > Signed-off-by: Will Deacon <will at kernel.org>
> > ---
> >  drivers/iommu/iommu.c | 31 ++++++++++++-------------------
> >  1 file changed, 12 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index d0b0a15dba84..bcd623862bf9 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -8,6 +8,7 @@
> > 
> >  #include <linux/device.h>
> >  #include <linux/kernel.h>
> > +#include <linux/bits.h>
> >  #include <linux/bug.h>
> >  #include <linux/types.h>
> >  #include <linux/init.h>
> > @@ -2360,30 +2361,22 @@ static size_t iommu_pgsize(struct iommu_domain
> > *domain,
> >  			   unsigned long addr_merge, size_t size)
> >  {
> >  	unsigned int pgsize_idx;
> > +	unsigned long pgsizes;
> >  	size_t pgsize;
> > 
> > -	/* Max page size that still fits into 'size' */
> > -	pgsize_idx = __fls(size);
> > +	/* Page sizes supported by the hardware and small enough for @size */
> > +	pgsizes = domain->pgsize_bitmap & GENMASK(__fls(size), 0);
> I've fixed this in the latest RFC for the iommu_map/unmap optimization
> patches,
> but for the sake of completeness: I think this should be GENMASK_ULL, in
> case
> __fls(size) >= 32.

Hmm, but 'size' is a size_t; which architectures have sizeof(size_t) >
sizeof(unsigned long)?

> > -	/* need to consider alignment requirements ? */
> > -	if (likely(addr_merge)) {
> > -		/* Max page size allowed by address */
> > -		unsigned int align_pgsize_idx = __ffs(addr_merge);
> > -		pgsize_idx = min(pgsize_idx, align_pgsize_idx);
> > -	}
> > -
> > -	/* build a mask of acceptable page sizes */
> > -	pgsize = (1UL << (pgsize_idx + 1)) - 1;
> > -
> > -	/* throw away page sizes not supported by the hardware */
> > -	pgsize &= domain->pgsize_bitmap;
> > +	/* Constrain the page sizes further based on the maximum alignment */
> > +	if (likely(addr_merge))
> > +		pgsizes &= GENMASK(__ffs(addr_merge), 0);

This one looks like more of an issue, though, as addr_merge is a
phys_addr_t, which certainly can be 64-bit where unsigned long is 32-bit
(e.g. Armv7 + LPAE)

Rather than make everything _ULL, please can you just do it where we're
actually using the larger types?

Will


From xiaoning.wang at nxp.com  Tue Apr  6 12:41:09 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue, 6 Apr 2021 11:41:09 +0000
Subject: [PATCH V2 14/18] i2c: imx-lpi2c: add edma mode support
In-Reply-To: <20210406113306.2633595-15-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
 <20210406113306.2633595-15-xiaoning.wang@nxp.com>
Message-ID: <AM6PR04MB5623BD8E4658926876EB8A74F3769@AM6PR04MB5623.eurprd04.prod.outlook.com>


> -----Original Message-----
> From: Clark Wang <xiaoning.wang at nxp.com>
> Sent: Tuesday, April 6, 2021 19:33
> To: Aisheng Dong <aisheng.dong at nxp.com>; robh+dt at kernel.org;
> shawnguo at kernel.org; s.hauer at pengutronix.de; festevam at gmail.com
> Cc: kernel at pengutronix.de; dl-linux-imx <linux-imx at nxp.com>; linux-
> i2c at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: [PATCH V2 14/18] i2c: imx-lpi2c: add edma mode support
> 
> Add eDMA receive and send mode support.
> Support to read and write data larger than 256 bytes in one frame.
> 
> Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
> Reviewed-by: Li Jun <jun.li at nxp.com>
> ---
> V2 changes:
>  - change marco I2C_USE_PIO to DMA_ERR_I2C_USE_PIO. It is a error code
> defined
>    in this driver to

It is an error code defined in this driver to identify the DMA sending
error, then driver will try to use PIO to send data.

Best Regards,
Clark Wang
> ---
>  drivers/i2c/busses/i2c-imx-lpi2c.c | 290 ++++++++++++++++++++++++++++-
>  1 file changed, 288 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c
b/drivers/i2c/busses/i2c-imx-
> lpi2c.c
> index c2f8e49660ea..d1a56d52f19f 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -8,6 +8,8 @@
>  #include <linux/clk.h>
>  #include <linux/completion.h>
>  #include <linux/delay.h>
> +#include <linux/dmaengine.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/err.h>
>  #include <linux/errno.h>
>  #include <linux/i2c.h>
> @@ -31,6 +33,7 @@
>  #define LPI2C_MCR	0x10	/* i2c contrl register */
>  #define LPI2C_MSR	0x14	/* i2c status register */
>  #define LPI2C_MIER	0x18	/* i2c interrupt enable */
> +#define LPI2C_MDER	0x1C	/* i2c DMA enable */
>  #define LPI2C_MCFGR0	0x20	/* i2c master configuration */
>  #define LPI2C_MCFGR1	0x24	/* i2c master configuration */
>  #define LPI2C_MCFGR2	0x28	/* i2c master configuration */
> @@ -72,11 +75,15 @@
>  #define MCFGR1_AUTOSTOP	BIT(8)
>  #define MCFGR1_IGNACK	BIT(9)
>  #define MRDR_RXEMPTY	BIT(14)
> +#define MDER_TDDE	BIT(0)
> +#define MDER_RDDE	BIT(1)
> 
>  #define I2C_CLK_RATIO	24 / 59
>  #define CHUNK_DATA	256
> 
>  #define I2C_PM_TIMEOUT		1000 /* ms */
> +#define I2C_DMA_THRESHOLD	16 /* bytes */
> +#define DMA_ERR_I2C_USE_PIO	(-150)
> 
>  enum lpi2c_imx_mode {
>  	STANDARD,	/* <=100Kbps */
> @@ -95,6 +102,7 @@ enum lpi2c_imx_pincfg {
> 
>  struct lpi2c_imx_struct {
>  	struct i2c_adapter	adapter;
> +	resource_size_t		phy_addr;
>  	int			irq;
>  	struct clk		*clk_per;
>  	struct clk		*clk_ipg;
> @@ -114,6 +122,17 @@ struct lpi2c_imx_struct {
>  	struct pinctrl *pinctrl;
>  	struct pinctrl_state *pinctrl_pins_default;
>  	struct pinctrl_state *pinctrl_pins_gpio;
> +
> +	bool			can_use_dma;
> +	bool			using_dma;
> +	bool			xferred;
> +	struct i2c_msg		*msg;
> +	dma_addr_t		dma_addr;
> +	struct dma_chan		*dma_tx;
> +	struct dma_chan		*dma_rx;
> +	enum dma_data_direction dma_direction;
> +	u8			*dma_buf;
> +	unsigned int		dma_len;
>  };
> 
>  static void lpi2c_imx_intctrl(struct lpi2c_imx_struct *lpi2c_imx, @@
-289,6
> +308,9 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct
> *lpi2c_imx)
>  	if (ret)
>  		goto rpm_put;
> 
> +	if (lpi2c_imx->can_use_dma)
> +		writel(MDER_TDDE | MDER_RDDE, lpi2c_imx->base +
> LPI2C_MDER);
> +
>  	temp = readl(lpi2c_imx->base + LPI2C_MCR);
>  	temp |= MCR_MEN;
>  	writel(temp, lpi2c_imx->base + LPI2C_MCR); @@ -462,6 +484,154 @@
> static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
>  	lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);  }
> 
> +static void lpi2c_dma_unmap(struct lpi2c_imx_struct *lpi2c_imx) {
> +	struct dma_chan *chan = lpi2c_imx->dma_direction ==
> DMA_FROM_DEVICE
> +				? lpi2c_imx->dma_rx : lpi2c_imx->dma_tx;
> +
> +	dma_unmap_single(chan->device->dev, lpi2c_imx->dma_addr,
> +			 lpi2c_imx->dma_len, lpi2c_imx->dma_direction);
> +
> +	lpi2c_imx->dma_direction = DMA_NONE;
> +}
> +
> +static void lpi2c_cleanup_dma(struct lpi2c_imx_struct *lpi2c_imx) {
> +	if (lpi2c_imx->dma_direction == DMA_NONE)
> +		return;
> +	else if (lpi2c_imx->dma_direction == DMA_FROM_DEVICE)
> +		dmaengine_terminate_all(lpi2c_imx->dma_rx);
> +	else if (lpi2c_imx->dma_direction == DMA_TO_DEVICE)
> +		dmaengine_terminate_all(lpi2c_imx->dma_tx);
> +
> +	lpi2c_dma_unmap(lpi2c_imx);
> +}
> +
> +static void lpi2c_dma_callback(void *data) {
> +	struct lpi2c_imx_struct *lpi2c_imx = (struct lpi2c_imx_struct
*)data;
> +
> +	lpi2c_dma_unmap(lpi2c_imx);
> +	writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
> +	lpi2c_imx->xferred = true;
> +
> +	complete(&lpi2c_imx->complete);
> +}
> +
> +static int lpi2c_dma_submit(struct lpi2c_imx_struct *lpi2c_imx,
> +			   struct i2c_msg *msg)
> +{
> +	bool read = msg->flags & I2C_M_RD;
> +	enum dma_data_direction dir = read ? DMA_FROM_DEVICE :
> DMA_TO_DEVICE;
> +	struct dma_chan *chan = read ? lpi2c_imx->dma_rx :
lpi2c_imx->dma_tx;
> +	struct dma_async_tx_descriptor *txdesc;
> +	dma_cookie_t cookie;
> +
> +	lpi2c_imx->dma_len = read ? msg->len - 1 : msg->len;
> +	lpi2c_imx->msg = msg;
> +	lpi2c_imx->dma_direction = dir;
> +
> +	if (IS_ERR(chan))
> +		return PTR_ERR(chan);
> +
> +	lpi2c_imx->dma_addr = dma_map_single(chan->device->dev,
> +					     lpi2c_imx->dma_buf,
> +					     lpi2c_imx->dma_len, dir);
> +	if (dma_mapping_error(chan->device->dev, lpi2c_imx->dma_addr)) {
> +		dev_err(&lpi2c_imx->adapter.dev, "dma map failed, use
pio\n");
> +		return -EINVAL;
> +	}
> +
> +	txdesc = dmaengine_prep_slave_single(chan, lpi2c_imx->dma_addr,
> +					lpi2c_imx->dma_len, read ?
> +					DMA_DEV_TO_MEM :
> DMA_MEM_TO_DEV,
> +					DMA_PREP_INTERRUPT |
> DMA_CTRL_ACK);
> +	if (!txdesc) {
> +		dev_err(&lpi2c_imx->adapter.dev, "dma prep slave sg failed,
> use pio\n");
> +		lpi2c_cleanup_dma(lpi2c_imx);
> +		return -EINVAL;
> +	}
> +
> +	reinit_completion(&lpi2c_imx->complete);
> +	txdesc->callback = lpi2c_dma_callback;
> +	txdesc->callback_param = (void *)lpi2c_imx;
> +
> +	cookie = dmaengine_submit(txdesc);
> +	if (dma_submit_error(cookie)) {
> +		dev_err(&lpi2c_imx->adapter.dev, "submitting dma failed, use
> pio\n");
> +		lpi2c_cleanup_dma(lpi2c_imx);
> +		return -EINVAL;
> +	}
> +
> +	lpi2c_imx_intctrl(lpi2c_imx, MIER_NDIE);
> +
> +	dma_async_issue_pending(chan);
> +
> +	return 0;
> +}
> +
> +static bool is_use_dma(struct lpi2c_imx_struct *lpi2c_imx, struct
> +i2c_msg *msg) {
> +	if (!lpi2c_imx->can_use_dma)
> +		return false;
> +
> +	if (msg->len < I2C_DMA_THRESHOLD)
> +		return false;
> +
> +	return true;
> +}
> +
> +static int lpi2c_imx_dma_push_rx_cmd(struct lpi2c_imx_struct *lpi2c_imx,
> +				 struct i2c_msg *msg)
> +{
> +	unsigned int temp, rx_remain;
> +	unsigned long orig_jiffies = jiffies;
> +
> +	if ((msg->flags & I2C_M_RD)) {
> +		rx_remain = msg->len;
> +		do {
> +			temp = rx_remain > CHUNK_DATA ?
> +				CHUNK_DATA - 1 : rx_remain - 1;
> +			temp |= (RECV_DATA << 8);
> +			while ((readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff)
>
> (lpi2c_imx->rxfifosize >> 1)) {
> +				if (time_after(jiffies, orig_jiffies +
> msecs_to_jiffies(1000))) {
> +					dev_dbg(&lpi2c_imx->adapter.dev,
> "txfifo empty timeout\n");
> +					if (lpi2c_imx-
> >adapter.bus_recovery_info)
> +						i2c_recover_bus(&lpi2c_imx-
> >adapter);
> +					return -ETIMEDOUT;
> +				}
> +				schedule();
> +			}
> +			writel(temp, lpi2c_imx->base + LPI2C_MTDR);
> +			rx_remain = rx_remain - (temp & 0xff) - 1;
> +		} while (rx_remain > 0);
> +	}
> +
> +	return 0;
> +}
> +
> +static int lpi2c_dma_xfer(struct lpi2c_imx_struct *lpi2c_imx,
> +			   struct i2c_msg *msg)
> +{
> +	int result;
> +
> +	result = lpi2c_dma_submit(lpi2c_imx, msg);
> +	if (!result) {
> +		result = lpi2c_imx_dma_push_rx_cmd(lpi2c_imx, msg);
> +		if (result)
> +			return result;
> +		result = lpi2c_imx_msg_complete(lpi2c_imx);
> +		return result;
> +	}
> +
> +	/* DMA xfer failed, try to use PIO, clean up dma things */
> +	i2c_put_dma_safe_msg_buf(lpi2c_imx->dma_buf, lpi2c_imx->msg,
> +				 lpi2c_imx->xferred);
> +	lpi2c_cleanup_dma(lpi2c_imx);
> +
> +	return DMA_ERR_I2C_USE_PIO;
> +}
> +
>  static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
>  			  struct i2c_msg *msgs, int num)
>  {
> @@ -474,6 +644,9 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
>  		return result;
> 
>  	for (i = 0; i < num; i++) {
> +		lpi2c_imx->xferred = false;
> +		lpi2c_imx->using_dma = false;
> +
>  		result = lpi2c_imx_start(lpi2c_imx, &msgs[i]);
>  		if (result)
>  			goto disable;
> @@ -482,9 +655,24 @@ static int lpi2c_imx_xfer(struct i2c_adapter
*adapter,
>  		if (num == 1 && msgs[0].len == 0)
>  			goto stop;
> 
> +		if (is_use_dma(lpi2c_imx, &msgs[i])) {
> +			lpi2c_imx->using_dma = true;
> +
> +			writel(0x1, lpi2c_imx->base + LPI2C_MFCR);
> +
> +			lpi2c_imx->dma_buf =
> i2c_get_dma_safe_msg_buf(&msgs[i],
> +
> I2C_DMA_THRESHOLD);
> +			if (lpi2c_imx->dma_buf) {
> +				result = lpi2c_dma_xfer(lpi2c_imx,
&msgs[i]);
> +				if (result != DMA_ERR_I2C_USE_PIO)
> +					goto stop;
> +			}
> +		}
> +
> +		lpi2c_imx->using_dma = false;
>  		lpi2c_imx->delivered = 0;
>  		lpi2c_imx->msglen = msgs[i].len;
> -		init_completion(&lpi2c_imx->complete);
> +		reinit_completion(&lpi2c_imx->complete);
> 
>  		if (msgs[i].flags & I2C_M_RD)
>  			lpi2c_imx_read(lpi2c_imx, &msgs[i]); @@ -503,7
> +691,16 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
>  	}
> 
>  stop:
> -	lpi2c_imx_stop(lpi2c_imx);
> +	if (!lpi2c_imx->using_dma)
> +		lpi2c_imx_stop(lpi2c_imx);
> +	else {
> +		i2c_put_dma_safe_msg_buf(lpi2c_imx->dma_buf, lpi2c_imx-
> >msg,
> +					 lpi2c_imx->xferred);
> +		if (result) {
> +			lpi2c_cleanup_dma(lpi2c_imx);
> +			writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
> +		}
> +	}
> 
>  	temp = readl(lpi2c_imx->base + LPI2C_MSR);
>  	if ((temp & MSR_NDF) && !result)
> @@ -528,6 +725,10 @@ static irqreturn_t lpi2c_imx_isr(int irq, void
*dev_id)
>  	temp = readl(lpi2c_imx->base + LPI2C_MSR);
> 
>  	if (temp & MSR_NDF) {
> +		if (lpi2c_imx->using_dma) {
> +			lpi2c_cleanup_dma(lpi2c_imx);
> +			writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
> +		}
>  		complete(&lpi2c_imx->complete);
>  		goto ret;
>  	}
> @@ -623,6 +824,77 @@ static const struct of_device_id lpi2c_imx_of_match[]
> = {  };  MODULE_DEVICE_TABLE(of, lpi2c_imx_of_match);
> 
> +static void lpi2c_dma_exit(struct lpi2c_imx_struct *lpi2c_imx) {
> +	if (lpi2c_imx->dma_rx) {
> +		dma_release_channel(lpi2c_imx->dma_rx);
> +		lpi2c_imx->dma_rx = NULL;
> +	}
> +
> +	if (lpi2c_imx->dma_tx) {
> +		dma_release_channel(lpi2c_imx->dma_tx);
> +		lpi2c_imx->dma_tx = NULL;
> +	}
> +}
> +
> +static int lpi2c_dma_init(struct device *dev,
> +			  struct lpi2c_imx_struct *lpi2c_imx) {
> +	int ret;
> +	struct dma_slave_config dma_sconfig;
> +
> +	/* Prepare for TX DMA: */
> +	lpi2c_imx->dma_tx = dma_request_chan(dev, "tx");
> +	if (IS_ERR(lpi2c_imx->dma_tx)) {
> +		ret = PTR_ERR(lpi2c_imx->dma_tx);
> +		dev_err(dev, "can't get the TX DMA channel, error %d!\n",
ret);
> +		lpi2c_imx->dma_tx = NULL;
> +		goto err;
> +	}
> +
> +	dma_sconfig.dst_addr = lpi2c_imx->phy_addr + LPI2C_MTDR;
> +	dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +	dma_sconfig.dst_maxburst = 1;
> +	dma_sconfig.direction = DMA_MEM_TO_DEV;
> +	ret = dmaengine_slave_config(lpi2c_imx->dma_tx, &dma_sconfig);
> +	if (ret < 0) {
> +		dev_err(dev, "can't configure tx channel (%d)\n", ret);
> +		goto fail_tx;
> +	}
> +
> +	/* Prepare for RX DMA: */
> +	lpi2c_imx->dma_rx = dma_request_chan(dev, "rx");
> +	if (IS_ERR(lpi2c_imx->dma_rx)) {
> +		ret = PTR_ERR(lpi2c_imx->dma_rx);
> +		dev_err(dev, "can't get the RX DMA channel, error %d\n",
ret);
> +		lpi2c_imx->dma_rx = NULL;
> +		goto fail_tx;
> +	}
> +
> +	dma_sconfig.src_addr = lpi2c_imx->phy_addr + LPI2C_MRDR;
> +	dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
> +	dma_sconfig.src_maxburst = 1;
> +	dma_sconfig.direction = DMA_DEV_TO_MEM;
> +	ret = dmaengine_slave_config(lpi2c_imx->dma_rx, &dma_sconfig);
> +	if (ret < 0) {
> +		dev_err(dev, "can't configure rx channel (%d)\n", ret);
> +		goto fail_rx;
> +	}
> +
> +	lpi2c_imx->can_use_dma = true;
> +	lpi2c_imx->using_dma = false;
> +
> +	return 0;
> +fail_rx:
> +	dma_release_channel(lpi2c_imx->dma_rx);
> +fail_tx:
> +	dma_release_channel(lpi2c_imx->dma_tx);
> +err:
> +	lpi2c_dma_exit(lpi2c_imx);
> +	lpi2c_imx->can_use_dma = false;
> +	return ret;
> +}
> +
>  static int lpi2c_imx_clocks_prepare(struct lpi2c_imx_struct *lpi2c_imx)
{
>  	int ret = 0;
> @@ -656,15 +928,18 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>  	struct lpi2c_imx_struct *lpi2c_imx;
>  	unsigned int temp;
>  	int ret;
> +	struct resource *res;
> 
>  	lpi2c_imx = devm_kzalloc(&pdev->dev, sizeof(*lpi2c_imx),
GFP_KERNEL);
>  	if (!lpi2c_imx)
>  		return -ENOMEM;
> 
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	lpi2c_imx->base = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(lpi2c_imx->base))
>  		return PTR_ERR(lpi2c_imx->base);
> 
> +	lpi2c_imx->phy_addr = (dma_addr_t)res->start;
>  	lpi2c_imx->irq = platform_get_irq(pdev, 0);
>  	if (lpi2c_imx->irq < 0)
>  		return lpi2c_imx->irq;
> @@ -716,6 +991,17 @@ static int lpi2c_imx_probe(struct platform_device
> *pdev)
>  	if (ret == -EPROBE_DEFER)
>  		goto rpm_disable;
> 
> +	/* Init DMA */
> +	lpi2c_imx->dma_direction = DMA_NONE;
> +	ret = lpi2c_dma_init(&pdev->dev, lpi2c_imx);
> +	if (ret) {
> +		dev_err_probe(&pdev->dev, ret, "dma setup error %d, use
> pio\n", ret);
> +		if (ret == -EPROBE_DEFER)
> +			goto rpm_disable;
> +	}
> +
> +	init_completion(&lpi2c_imx->complete);
> +
>  	ret = i2c_add_adapter(&lpi2c_imx->adapter);
>  	if (ret)
>  		goto rpm_disable;
> --
> 2.25.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9583 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210406/569c34d9/attachment-0001.p7s>

From mark.rutland at arm.com  Tue Apr  6 12:41:53 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:41:53 +0100
Subject: [PATCH v5 13/18] arm64: use function_nocfi with __pa_symbol
In-Reply-To: <20210401233216.2540591-14-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-14-samitolvanen@google.com>
Message-ID: <20210406114153.GD96480@C02TD0UTHF1T.local>

On Thu, Apr 01, 2021 at 04:32:11PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function address
> references with the address of the function's CFI jump table
> entry. This means that __pa_symbol(function) returns the physical
> address of the jump table entry, which can lead to address space
> confusion as the jump table points to the function's virtual
> address. Therefore, use the function_nocfi() macro to ensure we are
> always taking the address of the actual function instead.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>
> ---
>  arch/arm64/include/asm/mmu_context.h      | 2 +-
>  arch/arm64/kernel/acpi_parking_protocol.c | 3 ++-
>  arch/arm64/kernel/cpu-reset.h             | 2 +-
>  arch/arm64/kernel/cpufeature.c            | 2 +-
>  arch/arm64/kernel/psci.c                  | 3 ++-
>  arch/arm64/kernel/smp_spin_table.c        | 3 ++-
>  6 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index bd02e99b1a4c..386b96400a57 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -140,7 +140,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
>  		ttbr1 |= TTBR_CNP_BIT;
>  	}
>  
> -	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
> +	replace_phys = (void *)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
>  
>  	cpu_install_idmap();
>  	replace_phys(ttbr1);
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index e7c941d8340d..bfeeb5319abf 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -99,7 +99,8 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>  	 * that read this address need to convert this address to the
>  	 * Boot-Loader's endianness before jumping.
>  	 */
> -	writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
> +	writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
> +		       &mailbox->entry_point);
>  	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
>  
>  	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
> diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
> index ed50e9587ad8..f3adc574f969 100644
> --- a/arch/arm64/kernel/cpu-reset.h
> +++ b/arch/arm64/kernel/cpu-reset.h
> @@ -22,7 +22,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
>  
>  	unsigned long el2_switch = !is_kernel_in_hyp_mode() &&
>  		is_hyp_mode_available();
> -	restart = (void *)__pa_symbol(__cpu_soft_restart);
> +	restart = (void *)__pa_symbol(function_nocfi(__cpu_soft_restart));
>  
>  	cpu_install_idmap();
>  	restart(el2_switch, entry, arg0, arg1, arg2);
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index e5281e1c8f1d..0b2e0d7b13ec 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1462,7 +1462,7 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
>  	if (arm64_use_ng_mappings)
>  		return;
>  
> -	remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
> +	remap_fn = (void *)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
>  
>  	cpu_install_idmap();
>  	remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 62d2bda7adb8..e74bcb57559b 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -38,7 +38,8 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
>  
>  static int cpu_psci_cpu_boot(unsigned int cpu)
>  {
> -	int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
> +	int err = psci_ops.cpu_on(cpu_logical_map(cpu),
> +			__pa_symbol(function_nocfi(secondary_entry)));

Could we use a temporary here, e.g.

	phys_addr_t pa_secondary_entry = __pa_symbol(function_nocfi(secondary_entry));
	int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);

>  	if (err)
>  		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
>  
> diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
> index 056772c26098..4c4e36ded4aa 100644
> --- a/arch/arm64/kernel/smp_spin_table.c
> +++ b/arch/arm64/kernel/smp_spin_table.c
> @@ -88,7 +88,8 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
>  	 * boot-loader's endianness before jumping. This is mandated by
>  	 * the boot protocol.
>  	 */
> -	writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
> +	writeq_relaxed(__pa_symbol(function_nocfi(secondary_holding_pen)),
> +		       release_addr);

Likewise here? e.g. at the start of the function have:

	phys_addr_t pa_holding_pen = __pa_symbol(function_nocfi(secondary_holding_pen));

... then here have:

	writeq_relaxed(pa_holding_pen, release_addr);

With those:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Thanks,
Mark.

>  	__flush_dcache_area((__force void *)release_addr,
>  			    sizeof(*release_addr));
>  
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From broonie at kernel.org  Tue Apr  6 12:43:57 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 12:43:57 +0100
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210406114357.GC6443@sirena.org.uk>

On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-K?nig wrote:
> Given that lowlevel drivers usually cannot implement exactly what a
> consumer requests with pwm_apply_state() there is some rounding involved.

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/20210406/4e45bfdc/attachment.sig>

From will at kernel.org  Tue Apr  6 12:50:41 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 12:50:41 +0100
Subject: [RFC PATCH v3 05/12] iommu: Use bitmap to calculate page size in
 iommu_pgsize()
In-Reply-To: <20210405191112.28192-6-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-6-isaacm@codeaurora.org>
Message-ID: <20210406115040.GB13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:05PM -0700, Isaac J. Manjarres wrote:
> From: Will Deacon <will at kernel.org>
> 
> Avoid the potential for shifting values by amounts greater than the
> width of their type by using a bitmap to compute page size in
> iommu_pgsize().
> 
> Signed-off-by: Will Deacon <will at kernel.org>
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> ---
>  drivers/iommu/iommu.c | 31 ++++++++++++-------------------
>  1 file changed, 12 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d0b0a15dba84..9006397b6604 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -8,6 +8,7 @@
>  
>  #include <linux/device.h>
>  #include <linux/kernel.h>
> +#include <linux/bits.h>
>  #include <linux/bug.h>
>  #include <linux/types.h>
>  #include <linux/init.h>
> @@ -2360,30 +2361,22 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
>  			   unsigned long addr_merge, size_t size)
>  {
>  	unsigned int pgsize_idx;
> +	unsigned long pgsizes;
>  	size_t pgsize;
>  
> -	/* Max page size that still fits into 'size' */
> -	pgsize_idx = __fls(size);
> +	/* Page sizes supported by the hardware and small enough for @size */
> +	pgsizes = domain->pgsize_bitmap & GENMASK_ULL(__fls(size), 0);

See my comments on the other thread, but I don't think it's necessary to use
the _ULL versions everywhere.

Will


From tsbogend at alpha.franken.de  Tue Apr  6 12:36:38 2021
From: tsbogend at alpha.franken.de (Thomas Bogendoerfer)
Date: Tue, 6 Apr 2021 13:36:38 +0200
Subject: [PATCH 6/9] mips: netlogic: Use irq_domain_simple_ops for XLP PIC
In-Reply-To: <20210406093557.1073423-7-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-7-maz@kernel.org>
Message-ID: <20210406113638.GA8277@alpha.franken.de>

On Tue, Apr 06, 2021 at 10:35:54AM +0100, Marc Zyngier wrote:
> Use the generic irq_domain_simple_ops structure instead of
> a home-grown one.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/mips/netlogic/common/irq.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)

Acked-by: Thomas Bogendoerfer <tsbogend at alpha.franken.de>

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]


From will at kernel.org  Tue Apr  6 12:53:56 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 12:53:56 +0100
Subject: [RFC PATCH v3 06/12] iommu: Split 'addr_merge' argument to
 iommu_pgsize() into separate parts
In-Reply-To: <20210405191112.28192-7-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-7-isaacm@codeaurora.org>
Message-ID: <20210406115355.GC13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:06PM -0700, Isaac J. Manjarres wrote:
> From: Will Deacon <will at kernel.org>
> 
> The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
> intended to describe the alignment requirements to consider when
> choosing an appropriate page size. On the iommu_map() path, this address
> is the logical OR of the virtual and physical addresses.
> 
> Subsequent improvements to iommu_pgsize() will need to check the
> alignment of the virtual and physical components of 'addr_merge'
> independently, so pass them in as separate parameters and reconstruct
> 'addr_merge' locally.
> 
> No functional change.
> 
> Signed-off-by: Will Deacon <will at kernel.org>
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> ---
>  drivers/iommu/iommu.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9006397b6604..a3bbf7e310b0 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2357,12 +2357,13 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
>  }
>  EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
>  
> -static size_t iommu_pgsize(struct iommu_domain *domain,
> -			   unsigned long addr_merge, size_t size)
> +static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
> +			   phys_addr_t paddr, size_t size)
>  {
>  	unsigned int pgsize_idx;
>  	unsigned long pgsizes;
>  	size_t pgsize;
> +	phys_addr_t addr_merge = paddr | iova;

Huh, so this was 'unsigned long' before and, given that the pgsize_bitmap
on the domain is also unsigned long, then I think that's fine. So using
that would mean you don't need GENMASK_ULL for this guy either.

Will


From mark.rutland at arm.com  Tue Apr  6 12:53:57 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:53:57 +0100
Subject: [PATCH v5 14/18] arm64: add __nocfi to functions that jump to a
 physical address
In-Reply-To: <20210401233216.2540591-15-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-15-samitolvanen@google.com>
Message-ID: <20210406115357.GE96480@C02TD0UTHF1T.local>

[adding Ard for EFI runtime services bits]

On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote:
> Disable CFI checking for functions that switch to linear mapping and
> make an indirect call to a physical address, since the compiler only
> understands virtual addresses and the CFI check for such indirect calls
> would always fail.

What does physical vs virtual have to do with this? Does the address
actually matter, or is this just a general thing that when calling an
assembly function we won't have a trampoline that the caller expects?

I wonder if we need to do something with asmlinkage here, perhaps?

I didn't spot anything in the seriues handling EFI runtime services
calls, and I strongly suspect we need to do something for those, unless
they're handled implicitly by something else.

> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>
> ---
>  arch/arm64/include/asm/mmu_context.h | 2 +-
>  arch/arm64/kernel/cpu-reset.h        | 8 ++++----
>  arch/arm64/kernel/cpufeature.c       | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index 386b96400a57..d3cef9133539 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void)
>   * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
>   * avoiding the possibility of conflicting TLB entries being allocated.
>   */
> -static inline void cpu_replace_ttbr1(pgd_t *pgdp)
> +static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)

Given these are inlines, what's the effect when these are inlined into a
function that would normally use CFI? Does CFI get supressed for the
whole function, or just the bit that got inlined?

Is there an attribute that we could place on a function pointer to tell
the compiler to not check calls via that pointer? If that existed we'd
be able to scope this much more tightly.

Thanks,
Mark.

>  {
>  	typedef void (ttbr_replace_func)(phys_addr_t);
>  	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
> diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
> index f3adc574f969..9a7b1262ef17 100644
> --- a/arch/arm64/kernel/cpu-reset.h
> +++ b/arch/arm64/kernel/cpu-reset.h
> @@ -13,10 +13,10 @@
>  void __cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
>  	unsigned long arg0, unsigned long arg1, unsigned long arg2);
>  
> -static inline void __noreturn cpu_soft_restart(unsigned long entry,
> -					       unsigned long arg0,
> -					       unsigned long arg1,
> -					       unsigned long arg2)
> +static inline void __noreturn __nocfi cpu_soft_restart(unsigned long entry,
> +						       unsigned long arg0,
> +						       unsigned long arg1,
> +						       unsigned long arg2)
>  {
>  	typeof(__cpu_soft_restart) *restart;
>  
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 0b2e0d7b13ec..c2f94a5206e0 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1445,7 +1445,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>  }
>  
>  #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> -static void
> +static void __nocfi
>  kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
>  {
>  	typedef void (kpti_remap_fn)(int, int, phys_addr_t);
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From will at kernel.org  Tue Apr  6 12:57:40 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 12:57:40 +0100
Subject: [RFC PATCH v3 03/12] iommu/io-pgtable: Introduce map_pages() as
 a page table op
In-Reply-To: <20210405191112.28192-4-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-4-isaacm@codeaurora.org>
Message-ID: <20210406115739.GD13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:03PM -0700, Isaac J. Manjarres wrote:
> Mapping memory into io-pgtables follows the same semantics
> that unmapping memory used to follow (i.e. a buffer will be
> mapped one page block per call to the io-pgtable code). This
> means that it can be optimized in the same way that unmapping
> memory was, so add a map_pages() callback to the io-pgtable
> ops structure, so that a range of pages of the same size
> can be mapped within the same call.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>  include/linux/io-pgtable.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> index 2ed0c057d9e7..019149b204b8 100644
> --- a/include/linux/io-pgtable.h
> +++ b/include/linux/io-pgtable.h
> @@ -143,6 +143,7 @@ struct io_pgtable_cfg {
>   * struct io_pgtable_ops - Page table manipulation API for IOMMU drivers.
>   *
>   * @map:          Map a physically contiguous memory region.
> + * @map_pages:    Map a physically contiguous range of pages of the same size.
>   * @unmap:        Unmap a physically contiguous memory region.
>   * @unmap_pages:  Unmap a range of virtually contiguous pages of the same size.
>   * @iova_to_phys: Translate iova to physical address.
> @@ -153,6 +154,9 @@ struct io_pgtable_cfg {
>  struct io_pgtable_ops {
>  	int (*map)(struct io_pgtable_ops *ops, unsigned long iova,
>  		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
> +	int (*map_pages)(struct io_pgtable_ops *ops, unsigned long iova,
> +			 phys_addr_t paddr, size_t pgsize, size_t pgcount,
> +			 int prot, gfp_t gfp, size_t *mapped);

How about returning 'size_t' and using IS_ERR_VALUE() instead of adding
the extra 'mapped' argument (i.e. return the size of the region mapped
or an error code)? I don't think we realistically need to care about map
sizes that overlap with the error region.

Will


From will at kernel.org  Tue Apr  6 12:58:08 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 12:58:08 +0100
Subject: [RFC PATCH v3 04/12] iommu: Add a map_pages() op for IOMMU drivers
In-Reply-To: <20210405191112.28192-5-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-5-isaacm@codeaurora.org>
Message-ID: <20210406115808.GE13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:04PM -0700, Isaac J. Manjarres wrote:
> Add a callback for IOMMU drivers to provide a path for the
> IOMMU framework to call into an IOMMU driver, which can
> call into the io-pgtable code, to map a physically contiguous
> rnage of pages of the same size.
> 
> For IOMMU drivers that do not specify a map_pages() callback,
> the existing logic of mapping memory one page block at a time
> will be used.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>  include/linux/iommu.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 9cf81242581a..528d6a58479e 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -192,6 +192,8 @@ struct iommu_iotlb_gather {
>   * @attach_dev: attach device to an iommu domain
>   * @detach_dev: detach device from an iommu domain
>   * @map: map a physically contiguous memory region to an iommu domain
> + * @map_pages: map a physically contiguous set of pages of the same size to
> + *             an iommu domain.
>   * @unmap: unmap a physically contiguous memory region from an iommu domain
>   * @unmap_pages: unmap a number of pages of the same size from an iommu domain
>   * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
> @@ -244,6 +246,9 @@ struct iommu_ops {
>  	void (*detach_dev)(struct iommu_domain *domain, struct device *dev);
>  	int (*map)(struct iommu_domain *domain, unsigned long iova,
>  		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
> +	int (*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);

(same comment as for the io-pgtable callback).

Will


From mark.rutland at arm.com  Tue Apr  6 12:58:36 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 6 Apr 2021 12:58:36 +0100
Subject: [PATCH v5 16/18] arm64: ftrace: use function_nocfi for ftrace_call
In-Reply-To: <20210401233216.2540591-17-samitolvanen@google.com>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-17-samitolvanen@google.com>
Message-ID: <20210406115836.GF96480@C02TD0UTHF1T.local>

On Thu, Apr 01, 2021 at 04:32:14PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function pointers with
> jump table addresses, which breaks dynamic ftrace as the address of
> ftrace_call is replaced with the address of ftrace_call.cfi_jt. Use
> function_nocfi() to get the address of the actual function instead.
> 
> Suggested-by: Ben Dai <ben.dai at unisoc.com>
> Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> ---
>  arch/arm64/kernel/ftrace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
> index 86a5cf9bc19a..b5d3ddaf69d9 100644
> --- a/arch/arm64/kernel/ftrace.c
> +++ b/arch/arm64/kernel/ftrace.c
> @@ -55,7 +55,7 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
>  	unsigned long pc;
>  	u32 new;
>  
> -	pc = (unsigned long)&ftrace_call;
> +	pc = (unsigned long)function_nocfi(ftrace_call);

Acked-by: Mark Rutland <mark.rutland at arm.com>

Thanks,
Mark.

>  	new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
>  					  AARCH64_INSN_BRANCH_LINK);
>  
> -- 
> 2.31.0.208.g409f899ff0-goog
> 


From mlevitsk at redhat.com  Tue Apr  6 12:59:14 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Tue, 06 Apr 2021 14:59:14 +0300
Subject: [PATCH v2 0/9] KVM: my debug patch queue
In-Reply-To: <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
 <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>
Message-ID: <27193ea74081023b67ab9c98d7050b1e22655e79.camel@redhat.com>

On Fri, 2021-04-02 at 19:38 +0200, Paolo Bonzini wrote:
> On 01/04/21 15:54, Maxim Levitsky wrote:
> > Hi!
> > 
> > I would like to publish two debug features which were needed for other stuff
> > I work on.
> > 
> > One is the reworked lx-symbols script which now actually works on at least
> > gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
> > for some reason, not related to this patch) and upstream qemu.
> 
> Queued patches 2-5 for now.  6 is okay but it needs a selftest. (e.g. 
> using KVM_VCPU_SET_EVENTS) and the correct name for the constant.

Thanks!
I will do this very soon.

Best regards,
	Maxim Levitsky
> 
> Paolo
> 
> > The other feature is the ability to trap all guest exceptions (on SVM for now)
> > and see them in kvmtrace prior to potential merge to double/triple fault.
> > 
> > This can be very useful and I already had to manually patch KVM a few
> > times for this.
> > I will, once time permits, implement this feature on Intel as well.
> > 
> > V2:
> > 
> >   * Some more refactoring and workarounds for lx-symbols script
> > 
> >   * added KVM_GUESTDBG_BLOCKEVENTS flag to enable 'block interrupts on
> >     single step' together with KVM_CAP_SET_GUEST_DEBUG2 capability
> >     to indicate which guest debug flags are supported.
> > 
> >     This is a replacement for unconditional block of interrupts on single
> >     step that was done in previous version of this patch set.
> >     Patches to qemu to use that feature will be sent soon.
> > 
> >   * Reworked the the 'intercept all exceptions for debug' feature according
> >     to the review feedback:
> > 
> >     - renamed the parameter that enables the feature and
> >       moved it to common kvm module.
> >       (only SVM part is currently implemented though)
> > 
> >     - disable the feature for SEV guests as was suggested during the review
> >     - made the vmexit table const again, as was suggested in the review as well.
> > 
> > Best regards,
> > 	Maxim Levitsky
> > 
> > Maxim Levitsky (9):
> >    scripts/gdb: rework lx-symbols gdb script
> >    KVM: introduce KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: aarch64: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: s390x: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
> >    KVM: SVM: split svm_handle_invalid_exit
> >    KVM: x86: add force_intercept_exceptions_mask
> >    KVM: SVM: implement force_intercept_exceptions_mask
> > 
> >   Documentation/virt/kvm/api.rst    |   4 +
> >   arch/arm64/include/asm/kvm_host.h |   4 +
> >   arch/arm64/kvm/arm.c              |   2 +
> >   arch/arm64/kvm/guest.c            |   5 -
> >   arch/s390/include/asm/kvm_host.h  |   4 +
> >   arch/s390/kvm/kvm-s390.c          |   3 +
> >   arch/x86/include/asm/kvm_host.h   |  12 ++
> >   arch/x86/include/uapi/asm/kvm.h   |   1 +
> >   arch/x86/kvm/svm/svm.c            |  87 +++++++++++--
> >   arch/x86/kvm/svm/svm.h            |   6 +-
> >   arch/x86/kvm/x86.c                |  14 ++-
> >   arch/x86/kvm/x86.h                |   2 +
> >   include/uapi/linux/kvm.h          |   1 +
> >   kernel/module.c                   |   8 +-
> >   scripts/gdb/linux/symbols.py      | 203 ++++++++++++++++++++----------
> >   15 files changed, 272 insertions(+), 84 deletions(-)
> > 




From clabbe.montjoie at gmail.com  Tue Apr  6 13:05:19 2021
From: clabbe.montjoie at gmail.com (Corentin Labbe)
Date: Tue, 6 Apr 2021 14:05:19 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
In-Reply-To: <CACRpkdZ_barDrLvD2UBKo+GA-F+g72uMQx8CfRK2YLRodpeyUA@mail.gmail.com>
References: <YGtZeofmBv7hXK+a@Red>
 <CACRpkdZ_barDrLvD2UBKo+GA-F+g72uMQx8CfRK2YLRodpeyUA@mail.gmail.com>
Message-ID: <YGxOf8pKN8Ip/kCl@Red>

Le Tue, Apr 06, 2021 at 10:15:51AM +0200, Linus Walleij a ?crit :
> On Mon, Apr 5, 2021 at 8:39 PM Corentin Labbe <clabbe.montjoie at gmail.com> wrote:
> 
> > I own an Edimax NS 2502, which is a NAS based on StormLinix 3516.
> > I successfully upgraded it with a recent Linux.
> 
> Pretty cool!
> 
> >         mdio0: ethernet-phy {
> >                 compatible = "virtual,mdio-gpio";
> >                 gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
> >                         <&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
> >                 #address-cells = <1>;
> >                 #size-cells = <0>;
> >                 phy0: ethernet-phy at 1 {
> >                         reg = <1>;
> >                         device_type = "ethernet-phy";
> >                 };
> >         };
> 
> This looks like the most typical way to attach an MDIO phy.
> 
> I always try to identify the exact component used on the board. Do you have
>  a high res board photo?
> 

Hello

You could find photos at http://kernel.montjoie.ovh/gemini/
There are also photos of another SL3516 SoC based device (a SSI 1328 NAS), but I fail to setup a serial on it, so I keep it for later. 

> Realtek RTL82111 is the most common configuration.
> 
> Compare to the D-Linux DNS-313 DTS:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/gemini-dlink-dns-313.dts
> 
> Try just copying the whole pinctrl-gmii section!
> 
> 
> >                 syscon: syscon at 40000000 {
> >                         pinctrl {
> >                                 /*
> >                                  * gpio0agrp cover line 0-4
> >                                  * gpio0bgrp cover line 5
> >                                  */
> >                                 gpio0_default_pins: pinctrl-gpio0 {
> >                                         mux {
> >                                                 function = "gpio0";
> >                                                 groups = "gpio0agrp",
> >                                                 "gpio0bgrp";
> >                                         };
> >                                 };
> 
> Change groups to
> 
> groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";
> 
> So you mux in group h which is where the GPIO 21, 22 go out
> to the MDIO on 3516 IIUC. The right mux out is pretty important,
> if you have vendor source code, please share so I can check how
> they set it up.
> 

No change, probably due to all pinctrl-gemini 40000000.syscon:pinctrl: could not map pin config for "R8 GMAC0 RXDV"
Please see http://kernel.montjoie.ovh/gemini/bootlog6.txt , I have added some pr_info in gmac.
I have put in the directory, the final dtb which I use.

The vendor source could be found at https://www.edimax.com/edimax/mw/cufiles/files/download/OpenSourceCode/transfer/Wireless/NAS/NAS-GPL-source.zip

> > BUT neither ethernet nor USB works.
> 
> For USB try this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=gemini-usb&id=cbaf6cdf770b90de5f10bfa5112c679f1dffe948
> 

One of the USB port is now working.

> Pls report progress! I hope we can mainline this device.
> 

I hope too.
Note that I have also started to work on the gemini crypto driver.

Thanks for your help


From j.neuschaefer at gmx.net  Tue Apr  6 13:09:11 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:11 +0200
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
Message-ID: <20210406120921.2484986-1-j.neuschaefer@gmx.net>

This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.

Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki

Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.

Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
(https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)


v2:
- Various improvements to the AIC irqchip driver, thanks to Marc Zyngier's review
- I dropped the timer patches, which have been applied by Daniel Lezcano
- I dropped the serial patches, which have been applied to tty-next by Greg KH

v1:
- https://lore.kernel.org/lkml/20210320181610.680870-1-j.neuschaefer at gmx.net/

Jonathan Neusch?fer (10):
  dt-bindings: vendor-prefixes: Add Supermicro
  dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string
  dt-bindings: interrupt-controller: Add nuvoton,wpcm450-aic
  dt-bindings: watchdog: npcm: Add nuvoton,wpcm450-wdt
  ARM: npcm: Introduce Nuvoton WPCM450 SoC
  irqchip: Add driver for WPCM450 interrupt controller
  watchdog: npcm: Add support for WPCM450
  ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
  ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450
  MAINTAINERS: Add entry for Nuvoton WPCM450

 .../devicetree/bindings/arm/npcm/npcm.yaml    |   6 +
 .../nuvoton,wpcm450-aic.yaml                  |  39 +++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 .../bindings/watchdog/nuvoton,npcm-wdt.txt    |   3 +-
 MAINTAINERS                                   |   9 +
 arch/arm/boot/dts/Makefile                    |   2 +
 .../nuvoton-wpcm450-supermicro-x9sci-ln4f.dts |  40 +++++
 arch/arm/boot/dts/nuvoton-wpcm450.dtsi        |  76 +++++++++
 arch/arm/mach-npcm/Kconfig                    |  13 +-
 arch/arm/mach-npcm/Makefile                   |   1 +
 arch/arm/mach-npcm/wpcm450.c                  |  13 ++
 drivers/irqchip/Kconfig                       |   6 +
 drivers/irqchip/Makefile                      |   1 +
 drivers/irqchip/irq-wpcm450-aic.c             | 161 ++++++++++++++++++
 drivers/watchdog/npcm_wdt.c                   |   1 +
 15 files changed, 371 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450.dtsi
 create mode 100644 arch/arm/mach-npcm/wpcm450.c
 create mode 100644 drivers/irqchip/irq-wpcm450-aic.c

--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:12 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:12 +0200
Subject: [PATCH v2 01/10] dt-bindings: vendor-prefixes: Add Supermicro
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-2-j.neuschaefer@gmx.net>

Super Micro Computer, Inc. (https://www.supermicro.com/en/), commonly
known as Supermicro, is a manufacturer of server hardware.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
Acked-by: Rob Herring <robh at kernel.org>
---

v2:
- Added Rob's ACK
---
 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 f6064d84a424d..ec6d6ccfbbb3b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1085,6 +1085,8 @@ patternProperties:
     description: Shenzhen Sunchip Technology Co., Ltd
   "^SUNW,.*":
     description: Sun Microsystems, Inc
+  "^supermicro,.*":
+    description: Super Micro Computer, Inc.
   "^silvaco,.*":
     description: Silvaco, Inc.
   "^swir,.*":
--
2.30.2



From cnsztl at gmail.com  Tue Apr  6 13:10:14 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Tue, 6 Apr 2021 20:10:14 +0800
Subject: [PATCH v2] rockchip: enabled LAN port on NanoPi R2S
In-Reply-To: <c12341c8-8590-8314-d59b-3d5903041491@gmail.com>
References: <20210405093423.16149-1-cnsztl@gmail.com>
 <c12341c8-8590-8314-d59b-3d5903041491@gmail.com>
Message-ID: <CAOP2_Tjm9k0n_=_8+kZhFh_xC7o+ne1EWiL2UKWGXpUY+L2vRA@mail.gmail.com>

Hi Johan,

On 2021-04-05 19:03, Johan Jonker <jbx6244 at gmail.com> wrote:
>
> Hi Tianling,
>
> On 4/5/21 11:34 AM, Tianling Shen wrote:
> > From: David Bauer <mail at david-bauer.net>
> >
> > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > This is required for the USB3 attached LAN port to work.
> >
> > Signed-off-by: David Bauer <mail at david-bauer.net>
> > [added device node for USB Ethernet controller]
> > Signed-off-by: Tianling Shen <cnsztl at gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 32 +++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > index faf496d789cf..18936b393d9d 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > @@ -13,6 +13,10 @@
> >       model = "FriendlyElec NanoPi R2S";
> >       compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
> >
> > +     aliases {
> > +             ethernet1 = &r8153;
> > +     };
> > +
> >       chosen {
> >               stdout-path = "serial2:1500000n8";
> >       };
> > @@ -37,6 +41,16 @@
> >               };
> >       };
> >
>
> > +     vcc_rtl8153: vcc-rtl8153-regulator {
>
> sort nodename
>
> > +             compatible = "regulator-fixed";
> > +             gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&rtl8153_en_drv>;
> > +             regulator-always-on;
>
> > +             regulator-name = "vcc_rtl8153";
>
> exception to the sort rule
> sort regulator-name above all other regulator properties
>
> > +             enable-active-high;
>
> sort
>
> ----
> Heiko's sort rules:
>
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
>
> ----

Thank you very much, and I will update it in v3.

>
> > +     };
> > +
> >       leds {
> >               compatible = "gpio-leds";
> >               pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> > @@ -265,6 +279,12 @@
> >                       };
> >               };
> >       };
> > +
> > +     usb {
> > +             rtl8153_en_drv: rtl8153-en-drv {
> > +                     rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > +             };
> > +     };
> >  };
> >
> >  &io_domains {
> > @@ -364,6 +384,18 @@
> >       dr_mode = "host";
> >  };
> >
> > +&usbdrd3 {
> > +     dr_mode = "host";
> > +     status = "okay";
> > +
>
> > +     r8153: usb-eth at 2 {
>
> With YAML undocumented additional properties and nodes generate
> notifications.
> We need a change in the documents below for that.
> rockchip,dwc3.yaml > usb-drd.yaml > usb.yaml
>
> Is there a standard for the usb-eth nodename?
>
> > +             compatible = "realtek,rtl8153";
>
> Since a while Rob has improved has scripts.
> There's no escape anymore.
> Add a YAML document to this serie for "realtek,rtl8153".

This is actually added by another patch[1], but doesn't go to upstream yet.
I'll ask David if he would like to submit it.

Kindly ping David.

1:
https://github.com/openwrt/openwrt/blob/master/target/linux/rockchip/patches-5.10/002-net-usb-r8152-add-LED-configuration-from-OF.patch
https://github.com/openwrt/openwrt/blob/master/target/linux/rockchip/patches-5.10/003-dt-bindings-net-add-RTL8152-binding-documentation.patch

>
> Improve checking for undocumented compatible strings
> https://github.com/devicetree-org/dt-schema/commit/93e7ada8d53af099074cb5d53f7caa12835784e0
>
> > +             reg = <2>;
>
> Why 2 ?
>

This is the device number on the USB bus.

> > +
>
> > +             local-mac-address = [ 00 00 00 00 00 00 ]; /* Filled in by U-Boot */
>
> This is a private property.
> In a generic dts that's up to the user.

Okay I will drop this.

Thanks,
Tianling.

>
> > +     };
> > +};
> > +
> >  &usb_host0_ehci {
> >       status = "okay";
> >  };
> >
>


From j.neuschaefer at gmx.net  Tue Apr  6 13:09:13 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:13 +0200
Subject: [PATCH v2 02/10] dt-bindings: arm: npcm: Add nuvoton,
 wpcm450 compatible string
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-3-j.neuschaefer@gmx.net>

The WPCM450 is an older BMC SoC in the Nuvoton NPCM family, originally
marketed as Winbond WPCM450.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
Acked-by: Rob Herring <robh at kernel.org>
---

This patch requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
(https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)

v2:
- Added Rob's ACK
---
 Documentation/devicetree/bindings/arm/npcm/npcm.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
index 894aefb70652a..95e51378089c9 100644
--- a/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
+++ b/Documentation/devicetree/bindings/arm/npcm/npcm.yaml
@@ -14,6 +14,12 @@ properties:
     const: '/'
   compatible:
     oneOf:
+      - description: WPCM450 based boards
+        items:
+          - enum:
+              - supermicro,x9sci-ln4f-bmc   # Supermicro X9SCI-LN4F server's BMC
+          - const: nuvoton,wpcm450
+
       - description: NPCM750 based boards
         items:
           - enum:
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:14 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:14 +0200
Subject: [PATCH v2 03/10] dt-bindings: interrupt-controller: Add nuvoton,
 wpcm450-aic
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-4-j.neuschaefer@gmx.net>

The WPCM450 AIC ("Advanced Interrupt Controller") is the interrupt
controller found in the Nuvoton WPCM450 SoC and other Winbond/Nuvoton
SoCs.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
Acked-by: Rob Herring <robh at kernel.org>
---

v2:
- Added Rob's ACK
---
 .../nuvoton,wpcm450-aic.yaml                  | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml

diff --git a/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
new file mode 100644
index 0000000000000..9ce6804bdb999
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,wpcm450-aic.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/nuvoton,wpcm450-aic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton WPCM450 Advanced Interrupt Controller bindings
+
+maintainers:
+  - Jonathan Neusch?fer <j.neuschaefer at gmx.net>
+
+properties:
+  '#interrupt-cells':
+    const: 2
+
+  compatible:
+    const: nuvoton,wpcm450-aic
+
+  interrupt-controller: true
+
+  reg:
+    maxItems: 1
+
+additionalProperties: false
+
+required:
+  - '#interrupt-cells'
+  - compatible
+  - reg
+  - interrupt-controller
+
+examples:
+  - |
+    aic: interrupt-controller at b8002000 {
+        compatible = "nuvoton,wpcm450-aic";
+        reg = <0xb8002000 0x1000>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+    };
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:16 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:16 +0200
Subject: [PATCH v2 05/10] ARM: npcm: Introduce Nuvoton WPCM450 SoC
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-6-j.neuschaefer@gmx.net>

The WPCM450 is an older BMC SoC in the Nuvoton NPCM family, originally
marketed as Winbond WPCM450.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---

v2:
- Reorder lines in Makefile by model number (WPCM450 < NPCM7xx)
---
 arch/arm/mach-npcm/Kconfig   | 12 +++++++++++-
 arch/arm/mach-npcm/Makefile  |  1 +
 arch/arm/mach-npcm/wpcm450.c | 13 +++++++++++++
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-npcm/wpcm450.c

diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
index 7f7002dc2b21f..658c8efb4ca14 100644
--- a/arch/arm/mach-npcm/Kconfig
+++ b/arch/arm/mach-npcm/Kconfig
@@ -1,11 +1,21 @@
 # SPDX-License-Identifier: GPL-2.0-only
 menuconfig ARCH_NPCM
 	bool "Nuvoton NPCM Architecture"
-	depends on ARCH_MULTI_V7
+	depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
 	select PINCTRL

 if ARCH_NPCM

+config ARCH_WPCM450
+	bool "Support for WPCM450 BMC (Hermon)"
+	depends on ARCH_MULTI_V5
+	select CPU_ARM926T
+	select NPCM7XX_TIMER
+	help
+	  General support for WPCM450 BMC (Hermon).
+
+	  Winbond/Nuvoton WPCM450 BMC based on the ARM926EJ-S.
+
 config ARCH_NPCM7XX
 	bool "Support for NPCM7xx BMC (Poleg)"
 	depends on ARCH_MULTI_V7
diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile
index 1bc3a70bfab8b..8d61fcd42fb19 100644
--- a/arch/arm/mach-npcm/Makefile
+++ b/arch/arm/mach-npcm/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 AFLAGS_headsmp.o		+= -march=armv7-a

+obj-$(CONFIG_ARCH_WPCM450)	+= wpcm450.o
 obj-$(CONFIG_ARCH_NPCM7XX)	+= npcm7xx.o
 obj-$(CONFIG_SMP)		+= platsmp.o headsmp.o
diff --git a/arch/arm/mach-npcm/wpcm450.c b/arch/arm/mach-npcm/wpcm450.c
new file mode 100644
index 0000000000000..f17b3dab45af3
--- /dev/null
+++ b/arch/arm/mach-npcm/wpcm450.c
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2021 Jonathan Neusch?fer
+
+#include <asm/mach/arch.h>
+
+static const char *const wpcm450_dt_match[] = {
+	"nuvoton,wpcm450",
+	NULL
+};
+
+DT_MACHINE_START(WPCM450_DT, "WPCM450 chip")
+	.dt_compat	= wpcm450_dt_match,
+MACHINE_END
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:17 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:17 +0200
Subject: [PATCH v2 06/10] irqchip: Add driver for WPCM450 interrupt controller
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-7-j.neuschaefer@gmx.net>

The WPCM450 AIC ("Advanced Interrupt Controller") is the interrupt
controller found in the Nuvoton WPCM450 SoC and other Winbond/Nuvoton
SoCs.

The list of registers if based on the AMI vendor kernel and the
Nuvoton W90N745 datasheet.

Although the hardware supports other interrupt modes, the driver only
supports high-level interrupts at the moment, because other modes could
not be tested so far.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---

v2:
- Rename IRQS macro to AIC_NUM_IRQS
- Fix IRQ range check
- Use linux/printk.h header instead of linux/console.h
- Add AIC_SCR_PRIORITY_MASK constant
- Add missing register descriptions
- Remove superfluous printk about IRQ flow type mismatch
- Use BIT() macro
- Rename _ack function to _eoi for accuracy, and use handle_fasteoi_irq
---
 arch/arm/mach-npcm/Kconfig        |   1 +
 drivers/irqchip/Kconfig           |   6 ++
 drivers/irqchip/Makefile          |   1 +
 drivers/irqchip/irq-wpcm450-aic.c | 161 ++++++++++++++++++++++++++++++
 4 files changed, 169 insertions(+)
 create mode 100644 drivers/irqchip/irq-wpcm450-aic.c

diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
index 658c8efb4ca14..a71cf1d189ae5 100644
--- a/arch/arm/mach-npcm/Kconfig
+++ b/arch/arm/mach-npcm/Kconfig
@@ -10,6 +10,7 @@ config ARCH_WPCM450
 	bool "Support for WPCM450 BMC (Hermon)"
 	depends on ARCH_MULTI_V5
 	select CPU_ARM926T
+	select WPCM450_AIC
 	select NPCM7XX_TIMER
 	help
 	  General support for WPCM450 BMC (Hermon).
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e74fa206240a1..baf4efec31c67 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -586,4 +586,10 @@ config MST_IRQ
 	help
 	  Support MStar Interrupt Controller.

+config WPCM450_AIC
+	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
+	depends on ARCH_WPCM450 || COMPILE_TEST
+	help
+	  Support for the interrupt controller in the Nuvoton WPCM450 BMC SoC.
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c59b95a0532c9..bef57937e7296 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_LOONGSON_PCH_MSI)		+= irq-loongson-pch-msi.o
 obj-$(CONFIG_MST_IRQ)			+= irq-mst-intc.o
 obj-$(CONFIG_SL28CPLD_INTC)		+= irq-sl28cpld.o
 obj-$(CONFIG_MACH_REALTEK_RTL)		+= irq-realtek-rtl.o
+obj-$(CONFIG_WPCM450_AIC)		+= irq-wpcm450-aic.o
diff --git a/drivers/irqchip/irq-wpcm450-aic.c b/drivers/irqchip/irq-wpcm450-aic.c
new file mode 100644
index 0000000000000..f3ac392d5bc87
--- /dev/null
+++ b/drivers/irqchip/irq-wpcm450-aic.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright 2021 Jonathan Neusch?fer
+
+#include <linux/irqchip.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/printk.h>
+
+#include <asm/exception.h>
+
+#define AIC_SCR(x)	((x)*4)	/* Source control registers */
+#define AIC_GEN		0x84	/* Interrupt group enable control register */
+#define AIC_GRSR	0x88	/* Interrupt group raw status register */
+#define AIC_IRSR	0x100	/* Interrupt raw status register */
+#define AIC_IASR	0x104	/* Interrupt active status register */
+#define AIC_ISR		0x108	/* Interrupt status register */
+#define AIC_IPER	0x10c	/* Interrupt priority encoding register */
+#define AIC_ISNR	0x110	/* Interrupt source number register */
+#define AIC_IMR		0x114	/* Interrupt mask register */
+#define AIC_OISR	0x118	/* Output interrupt status register */
+#define AIC_MECR	0x120	/* Mask enable command register */
+#define AIC_MDCR	0x124	/* Mask disable command register */
+#define AIC_SSCR	0x128	/* Source set command register */
+#define AIC_SCCR	0x12c	/* Source clear command register */
+#define AIC_EOSCR	0x130	/* End of service command register */
+
+#define AIC_SCR_SRCTYPE_LOW_LEVEL	(0 << 6)
+#define AIC_SCR_SRCTYPE_HIGH_LEVEL	(1 << 6)
+#define AIC_SCR_SRCTYPE_NEG_EDGE	(2 << 6)
+#define AIC_SCR_SRCTYPE_POS_EDGE	(3 << 6)
+#define AIC_SCR_PRIORITY(x)		(x)
+#define AIC_SCR_PRIORITY_MASK		0x7
+
+#define AIC_NUM_IRQS		32
+
+struct wpcm450_aic {
+	void __iomem *regs;
+	struct irq_domain *domain;
+};
+
+static struct wpcm450_aic *aic;
+
+static void wpcm450_aic_init_hw(void)
+{
+	int i;
+
+	/* Disable (mask) all interrupts */
+	writel(0xffffffff, aic->regs + AIC_MDCR);
+
+	/*
+	 * Make sure the interrupt controller is ready to serve new interrupts.
+	 * Reading from IPER indicates that the nIRQ signal may be deasserted,
+	 * and writing to EOSCR indicates that interrupt handling has finished.
+	 */
+	readl(aic->regs + AIC_IPER);
+	writel(0, aic->regs + AIC_EOSCR);
+
+	/* Initialize trigger mode and priority of each interrupt source */
+	for (i = 0; i < AIC_NUM_IRQS; i++)
+		writel(AIC_SCR_SRCTYPE_HIGH_LEVEL | AIC_SCR_PRIORITY(7),
+		       aic->regs + AIC_SCR(i));
+}
+
+static void __exception_irq_entry wpcm450_aic_handle_irq(struct pt_regs *regs)
+{
+	int hwirq;
+
+	/* Determine the interrupt source */
+	/* Read IPER to signal that nIRQ can be de-asserted */
+	hwirq = readl(aic->regs + AIC_IPER) / 4;
+
+	handle_domain_irq(aic->domain, hwirq, regs);
+}
+
+static void wpcm450_aic_eoi(struct irq_data *d)
+{
+	/* Signal end-of-service */
+	writel(0, aic->regs + AIC_EOSCR);
+}
+
+static void wpcm450_aic_mask(struct irq_data *d)
+{
+	unsigned int mask = BIT(d->hwirq);
+
+	/* Disable (mask) the interrupt */
+	writel(mask, aic->regs + AIC_MDCR);
+}
+
+static void wpcm450_aic_unmask(struct irq_data *d)
+{
+	unsigned int mask = BIT(d->hwirq);
+
+	/* Enable (unmask) the interrupt */
+	writel(mask, aic->regs + AIC_MECR);
+}
+
+static int wpcm450_aic_set_type(struct irq_data *d, unsigned int flow_type)
+{
+	/*
+	 * The hardware supports high/low level, as well as rising/falling edge
+	 * modes, and the DT binding accommodates for that, but as long as
+	 * other modes than high level mode are not used and can't be tested,
+	 * they are rejected in this driver.
+	 */
+	if ((flow_type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_HIGH)
+		return -EINVAL;
+
+	return 0;
+}
+
+static struct irq_chip wpcm450_aic_chip = {
+	.name = "wpcm450-aic",
+	.irq_eoi = wpcm450_aic_eoi,
+	.irq_mask = wpcm450_aic_mask,
+	.irq_unmask = wpcm450_aic_unmask,
+	.irq_set_type = wpcm450_aic_set_type,
+};
+
+static int wpcm450_aic_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hwirq)
+{
+	if (hwirq >= AIC_NUM_IRQS)
+		return -EPERM;
+
+	irq_set_chip_and_handler(irq, &wpcm450_aic_chip, handle_fasteoi_irq);
+	irq_set_chip_data(irq, aic);
+	irq_set_probe(irq);
+
+	return 0;
+}
+
+static const struct irq_domain_ops wpcm450_aic_ops = {
+	.map = wpcm450_aic_map,
+	.xlate = irq_domain_xlate_twocell,
+};
+
+static int __init wpcm450_aic_of_init(struct device_node *node,
+				      struct device_node *parent)
+{
+	if (parent)
+		return -EINVAL;
+
+	aic = kzalloc(sizeof(*aic), GFP_KERNEL);
+	if (!aic)
+		return -ENOMEM;
+
+	aic->regs = of_iomap(node, 0);
+	if (!aic->regs) {
+		pr_err("Failed to map WPCM450 AIC registers\n");
+		return -ENOMEM;
+	}
+
+	wpcm450_aic_init_hw();
+
+	set_handle_irq(wpcm450_aic_handle_irq);
+
+	aic->domain = irq_domain_add_linear(node, AIC_NUM_IRQS, &wpcm450_aic_ops, aic);
+
+	return 0;
+}
+
+IRQCHIP_DECLARE(wpcm450_aic, "nuvoton,wpcm450-aic", wpcm450_aic_of_init);
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:15 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:15 +0200
Subject: [PATCH v2 04/10] dt-bindings: watchdog: npcm: Add nuvoton, wpcm450-wdt
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-5-j.neuschaefer@gmx.net>

Add a compatible string for the WPCM450 SoC, which has the same watchdog
timer.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
Acked-by: Rob Herring <robh at kernel.org>
---

v2:
- Added Rob's ACK
---
 .../devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt          | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
index 6d593003c933b..9059f54dc023d 100644
--- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm-wdt.txt
@@ -5,7 +5,8 @@ The watchdog supports a pre-timeout interrupt that fires 10ms before the
 expiry.

 Required properties:
-- compatible      : "nuvoton,npcm750-wdt" for NPCM750 (Poleg).
+- compatible      : "nuvoton,npcm750-wdt" for NPCM750 (Poleg), or
+                    "nuvoton,wpcm450-wdt" for WPCM450 (Hermon).
 - reg             : Offset and length of the register set for the device.
 - interrupts      : Contain the timer interrupt with flags for
                     falling edge.
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:19 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:19 +0200
Subject: [PATCH v2 08/10] ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-9-j.neuschaefer@gmx.net>

The WPCM450 is an older BMC SoC in the Nuvoton NPCM family, originally
marketed as Winbond WPCM450.

This patch adds a devicetree with basic functionality.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---

v2:
- no changes
---
 arch/arm/boot/dts/nuvoton-wpcm450.dtsi | 76 ++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450.dtsi

diff --git a/arch/arm/boot/dts/nuvoton-wpcm450.dtsi b/arch/arm/boot/dts/nuvoton-wpcm450.dtsi
new file mode 100644
index 0000000000000..d7cbeb1874840
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-wpcm450.dtsi
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+// Copyright 2021 Jonathan Neusch?fer
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	compatible = "nuvoton,wpcm450";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,arm926ej-s";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	clk24m: clock-24mhz {
+		/* 24 MHz dummy clock */
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		#clock-cells = <0>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		interrupt-parent = <&aic>;
+		ranges;
+
+		serial0: serial at b8000000 {
+			compatible = "nuvoton,wpcm450-uart";
+			reg = <0xb8000000 0x20>;
+			reg-shift = <2>;
+			interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk24m>;
+			status = "disabled";
+		};
+
+		serial1: serial at b8000100 {
+			compatible = "nuvoton,wpcm450-uart";
+			reg = <0xb8000100 0x20>;
+			reg-shift = <2>;
+			interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk24m>;
+			status = "disabled";
+		};
+
+		timer0: timer at b8001000 {
+			compatible = "nuvoton,wpcm450-timer";
+			interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0xb8001000 0x1c>;
+			clocks = <&clk24m>;
+		};
+
+		watchdog0: watchdog at b800101c {
+			compatible = "nuvoton,wpcm450-wdt";
+			interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0xb800101c 0x4>;
+			clocks = <&clk24m>;
+			status = "disabled";
+		};
+
+		aic: interrupt-controller at b8002000 {
+			compatible = "nuvoton,wpcm450-aic";
+			reg = <0xb8002000 0x1000>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:20 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:20 +0200
Subject: [PATCH v2 09/10] ARM: dts: Add devicetree for Supermicro X9SCi-LN4F
 based on WPCM450
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-10-j.neuschaefer@gmx.net>

The Supermicro X9SCi-LN4F is a server mainboard featuring the WPCM450
BMC. This patch adds a minimal devicetree for Linux running on the BMC.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>


---

v2:
- Group wpcm450 devicetree with npcm7xx devicetrees in the Makefile
---
 arch/arm/boot/dts/Makefile                    |  2 +
 .../nuvoton-wpcm450-supermicro-x9sci-ln4f.dts | 40 +++++++++++++++++++
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e6..5a9d99d5443e4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -333,6 +333,8 @@ dtb-$(CONFIG_ARCH_LPC18XX) += \
 dtb-$(CONFIG_ARCH_LPC32XX) += \
 	lpc3250-ea3250.dtb \
 	lpc3250-phy3250.dtb
+dtb-$(CONFIG_ARCH_WPCM450) += \
+	nuvoton-wpcm450-supermicro-x9sci-ln4f.dtb
 dtb-$(CONFIG_ARCH_NPCM7XX) += \
 	nuvoton-npcm730-gsj.dtb \
 	nuvoton-npcm730-kudo.dtb \
diff --git a/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts b/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
new file mode 100644
index 0000000000000..83f27fbf4e939
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+// Copyright 2021 Jonathan Neusch?fer
+
+/dts-v1/;
+
+/* The last 16 MiB are dedicated to the GPU */
+/memreserve/ 0x07000000 0x01000000;
+
+#include "nuvoton-wpcm450.dtsi"
+
+/ {
+	model = "Supermicro X9SCi-LN4F BMC";
+	compatible = "supermicro,x9sci-ln4f-bmc", "nuvoton,wpcm450";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory at 0 {
+		device_type = "memory";
+		reg = <0 0x08000000>; /* 128 MiB */
+	};
+};
+
+&serial0 {
+	/*
+	 * Debug serial port. TX is exposed on the right pad of unpopulated
+	 * resistor R1247, RX on the right pad of R1162.
+	 */
+	status = "okay";
+};
+
+&serial1 {
+	/* "Serial over LAN" port. Connected to ttyS2 of the host system. */
+	status = "okay";
+};
+
+&watchdog0 {
+	status = "okay";
+};
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:21 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:21 +0200
Subject: [PATCH v2 10/10] MAINTAINERS: Add entry for Nuvoton WPCM450
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-11-j.neuschaefer@gmx.net>

I am adding myself as the maintainer of WPCM450-related code.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---

v2:
- Instead of expanding the NPCM entry, I'm adding a new one only for
  WPCM450.
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d3..661770e8e6fc1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2194,6 +2194,15 @@ F:	drivers/*/*npcm*
 F:	drivers/*/*/*npcm*
 F:	include/dt-bindings/clock/nuvoton,npcm7xx-clock.h

+ARM/NUVOTON WPCM450 ARCHITECTURE
+M:	Jonathan Neusch?fer <j.neuschaefer at gmx.net>
+L:	openbmc at lists.ozlabs.org (moderated for non-subscribers)
+S:	Maintained
+F:	Documentation/devicetree/bindings/*/*wpcm*
+F:	arch/arm/boot/dts/nuvoton-wpcm450*
+F:	arch/arm/mach-npcm/wpcm450.c
+F:	drivers/*/*wpcm*
+
 ARM/OPENMOKO NEO FREERUNNER (GTA02) MACHINE SUPPORT
 L:	openmoko-kernel at lists.openmoko.org (subscribers-only)
 S:	Orphan
--
2.30.2



From j.neuschaefer at gmx.net  Tue Apr  6 13:09:18 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Tue,  6 Apr 2021 14:09:18 +0200
Subject: [PATCH v2 07/10] watchdog: npcm: Add support for WPCM450
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <20210406120921.2484986-8-j.neuschaefer@gmx.net>

Add a compatible string for WPCM450, which has essentially the same
watchdog mechanism as NPCM750.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---

v2:
- Added patch description
---
 drivers/watchdog/npcm_wdt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
index 765577f11c8db..28a24caa2627c 100644
--- a/drivers/watchdog/npcm_wdt.c
+++ b/drivers/watchdog/npcm_wdt.c
@@ -229,6 +229,7 @@ static int npcm_wdt_probe(struct platform_device *pdev)

 #ifdef CONFIG_OF
 static const struct of_device_id npcm_wdt_match[] = {
+	{.compatible = "nuvoton,wpcm450-wdt"},
 	{.compatible = "nuvoton,npcm750-wdt"},
 	{},
 };
--
2.30.2



From maz at kernel.org  Tue Apr  6 13:12:55 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 06 Apr 2021 13:12:55 +0100
Subject: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with
 irq_find_mapping()
In-Reply-To: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-2-maz@kernel.org>
 <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu>
Message-ID: <87lf9vpq60.wl-maz@kernel.org>

Christophe,

On Tue, 06 Apr 2021 12:21:33 +0100,
Christophe Leroy <christophe.leroy at csgroup.eu> wrote:
> 
> 
> 
> Le 06/04/2021 ? 11:35, Marc Zyngier a ?crit?:
> > irq_linear_revmap() is supposed to be a fast path for domain
> > lookups, but it only exposes low-level details of the irqdomain
> > implementation, details which are better kept private.
> 
> Can you elaborate with more details ?

Things like directly picking into the revmap are positively awful, and
doesn't work if the domain has been constructed using the radix
tree. Which on its own is totally broken, because things like
irq_domain_create_hierarchy() will pick an implementation or the
other.

> 
> > 
> > The *overhead* between the two is only a function call and
> > a couple of tests, so it is likely that noone can show any
> > meaningful difference compared to the cost of taking an
> > interrupt.
> 
> Do you have any measurement ?

I did measure things on arm64, and couldn't come up with any
difference other than noise.

> Can you make the "likely" a certitude ?

Of course not. You can always come up with an artificial CPU
implementation that has a very small exception entry overhead, and a
ridiculously slow memory subsystem. Do I care about these? No.

If you can come up with realistic platforms that show a regression
with this patch, I'm all ears.

> 
> > 
> > Reimplement irq_linear_revmap() with irq_find_mapping()
> > in order to preserve source code compatibility, and
> > rename the internal field for a measure.
> 
> This is in complete contradiction with commit https://github.com/torvalds/linux/commit/d3dcb436
> 
> At that time, irq_linear_revmap() was less complex than what
> irq_find_mapping() is today, and nevertheless it was considered worth
> restoring in as a fast path. What has changed since then ?

Over 8 years? Plenty. The use of irqdomains has been generalised, we
have domain hierarchies, and if anything, this commit introduces the
buggy behaviour I was mentioning above. I also don't see any mention
of actual performance in that commit.

And if we're worried about a fast path, being able to directly cache
the irq_data in the revmap, hence skipping the irq_desc lookup that
inevitable follows, is a much more interesting prospect than the "get
useless data quick" that irq_linear_revmap() implements.

This latter optimisation is what I am after.

> Can you also explain the reason for the renaming of "linear_revmap"
> into "revmap" ? What is that "measure" ?

To catch the potential direct use of the reverse map field.

Thanks,

	M.

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


From will at kernel.org  Tue Apr  6 13:15:53 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 13:15:53 +0100
Subject: [RFC PATCH v3 09/12] iommu/io-pgtable-arm: Implement
 arm_lpae_unmap_pages()
In-Reply-To: <20210405191112.28192-10-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-10-isaacm@codeaurora.org>
Message-ID: <20210406121552.GF13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:09PM -0700, Isaac J. Manjarres wrote:
> Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> format.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>  drivers/iommu/io-pgtable-arm.c | 124 +++++++++++++++++++++++++++------
>  1 file changed, 104 insertions(+), 20 deletions(-)

[...]

> +static size_t arm_lpae_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
> +				   size_t pgsize, size_t pgcount,
> +				   struct iommu_iotlb_gather *gather)
> +{
> +	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> +	struct io_pgtable_cfg *cfg = &data->iop.cfg;
> +	arm_lpae_iopte *ptep = data->pgd;
> +	long iaext = (s64)iova >> cfg->ias;
> +	size_t unmapped = 0, unmapped_page;
> +	int last_lvl;
> +	size_t table_size, pages, tbl_offset, max_entries;
> +
> +	if (WARN_ON(!pgsize || (pgsize & cfg->pgsize_bitmap) != pgsize || !pgcount))
> +		return 0;
> +
> +	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> +		iaext = ~iaext;
> +	if (WARN_ON(iaext))
> +		return 0;
> +
> +	/*
> +	 * Calculating the page table size here helps avoid situations where
> +	 * a page range that is being unmapped may be mapped at the same level
> +	 * but not mapped by the same tables. Allowing such a scenario to
> +	 * occur can complicate the logic in arm_lpae_split_blk_unmap().
> +	 */
> +	last_lvl = ARM_LPAE_BLOCK_SIZE_LVL(pgsize, data);
> +
> +	if (last_lvl == data->start_level)
> +		table_size = ARM_LPAE_PGD_SIZE(data);
> +	else
> +		table_size = ARM_LPAE_GRANULE(data);
> +
> +	max_entries = table_size / sizeof(*ptep);
> +
> +	while (pgcount) {
> +		tbl_offset = ARM_LPAE_LVL_IDX(iova, last_lvl, data);
> +		pages = min_t(size_t, pgcount, max_entries - tbl_offset);
> +		unmapped_page = __arm_lpae_unmap(data, gather, iova, pgsize,
> +						 pages, data->start_level,
> +						 ptep);
> +		if (!unmapped_page)
> +			break;
> +
> +		unmapped += unmapped_page;
> +		iova += unmapped_page;
> +		pgcount -= pages;
> +	}

Robin has some comments on the first version of this patch, and I don't think you
addressed them:

https://lore.kernel.org/r/b93fa0b1-e2a4-1aad-8b88-4d0dfecdfef7 at arm.com

I'm inclined to agree that iterating here doesn't make a lot of sense --
we've already come back out of the page-table walk, so I think we should
just return to the caller (who is well prepared to handle a partial unmap).
Same for the map side of things.

If we get numbers showing that this is causing a performance issue, then
we should rework the page-table code to handle this at the lower level
(because I doubt the loop that you have is really worse than returning to
the caller anyway).

Will


From jolsa at redhat.com  Tue Apr  6 13:17:48 2021
From: jolsa at redhat.com (Jiri Olsa)
Date: Tue, 6 Apr 2021 14:17:48 +0200
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava>
 <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
Message-ID: <YGxRbH0XWaj6AWfa@krava>

On Tue, Apr 06, 2021 at 12:00:27PM +0100, John Garry wrote:
> On 01/04/2021 14:49, Jiri Olsa wrote:
> > On Thu, Mar 25, 2021 at 06:33:14PM +0800, John Garry wrote:
> > 
> > SNIP
> > 
> > > +struct metric {
> > > +	struct list_head list;
> > > +	struct metric_ref metric_ref;
> > > +};
> > > +
> > > +static int resolve_metric_simple(struct expr_parse_ctx *pctx,
> > > +				 struct list_head *compound_list,
> > > +				 struct pmu_events_map *map,
> > > +				 const char *metric_name)
> > > +{
> > > +	struct hashmap_entry *cur, *cur_tmp;
> > > +	struct metric *metric, *tmp;
> > > +	size_t bkt;
> > > +	bool all;
> > > +	int rc;
> > > +
> > > +	do {
> > > +		all = true;
> > > +		hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
> > > +			struct metric_ref *ref;
> > > +			struct pmu_event *pe;
> > > +
> > > +			pe = metrcgroup_find_metric(cur->key, map);
> 
> *
> 
> > > +			if (!pe)
> > > +				continue;
> > > +
> > > +			if (!strcmp(metric_name, (char *)cur->key)) {
> > > +				pr_warning("Recursion detected for metric %s\n", metric_name);
> > > +				rc = -1;
> > > +				goto out_err;
> > > +			}
> > > +
> > > +			all = false;
> > > +
> > > +			/* The metric key itself needs to go out.. */
> > > +			expr__del_id(pctx, cur->key);
> > > +
> > > +			metric = malloc(sizeof(*metric));
> > > +			if (!metric) {
> > > +				rc = -ENOMEM;
> > > +				goto out_err;
> > > +			}
> > > +
> > > +			ref = &metric->metric_ref;
> > > +			ref->metric_name = pe->metric_name;
> > > +			ref->metric_expr = pe->metric_expr;
> > > +			list_add_tail(&metric->list, compound_list);
> > > +
> > > +			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > 
> 
> Hi Jirka,
> 
> > so this might add new items to pctx->ids, I think you need
> > to restart the iteration as we do it in __resolve_metric
> > otherwise you could miss some new keys
> 
> I thought that I was doing this. Indeed, this code is very much like
> __resolve_metric() ;)
> 
> So expr__find_other() may add a new item to pctx->ids, and we always iterate
> again, and try to lookup any pmu_events, *, above. If none exist, then we

hm, I don't see that.. so, what you do is:

	hashmap__for_each_entry_safe((&pctx->ids) ....) {

		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
	}

and what I think we need to do is:

	hashmap__for_each_entry_safe((&pctx->ids) ....) {

		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);

		break;	
	}

each time you resolve another metric, you need to restart
the pctx->ids iteration, because there will be new items,
and we are in the middle of it

jirka


> have broken down pctx into primitive events aliases and unresolvable
> metrics, and stop iterating. And then unresolvable metrics would be found in
> check_parse_cpu().
> 
> As an example, we can deal with metric test1, below, which references 2x
> other metrics:
> 
>     {
>         "MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * (( (
> CPU_CLK_UNHALTED.THREAD / 2 ) * ( 1 + CPU_CLK_UNHALTED.ONE_THREAD_ACTIVE /
> CPU_CLK_UNHALTED.REF_XCLK ) )))",
>       "MetricName": "Frontend_Bound",
>     },
>     {
>         "MetricExpr": "( UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4 *
> INT_MISC.RECOVERY_CYCLES ) / (4 * cycles)",
>         "MetricName": "Bad_Speculation",
>     },
>     {
>         "MetricExpr": "Bad_Speculation + Frontend_Bound",
>         "MetricName": "test1",
>     },
> 
> Does that satisfy your concern, or have I missed something?
> 
> Thanks,
> John
> 
> > 
> > jirka
> > 
> > > +			if (rc)
> > > +				goto out_err;
> > > +		}
> > > +	} while (!all);
> > > +
> > > +	return 0;
> > > +
> > > +out_err:
> > > +	list_for_each_entry_safe(metric, tmp, compound_list, list)
> > > +		free(metric);
> > > +
> > > +	return rc;
> > > +
> > > +}
> > 
> > SNIP
> > 
> > .
> > 
> 



From pc at us.ibm.com  Tue Apr  6 13:18:40 2021
From: pc at us.ibm.com (Paul A. Clarke)
Date: Tue, 6 Apr 2021 07:18:40 -0500
Subject: [PATCH v2 0/6] perf arm64 metricgroup support
In-Reply-To: <1d800da3-ec94-3a37-eca9-1d3cf8543ba6@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <20210325203944.GD8931@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <dc17013d-2dcb-8ddf-a15a-e98cad3e2ae3@huawei.com>
 <20210329210717.GF8931@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
 <247e9484-34c8-544a-e268-b025ecb317fe@linux.ibm.com>
 <1d800da3-ec94-3a37-eca9-1d3cf8543ba6@huawei.com>
Message-ID: <20210406121840.GK8931@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>

On Tue, Apr 06, 2021 at 12:02:36PM +0100, John Garry wrote:
> On 30/03/2021 07:41, kajoljain wrote:
> > On 3/30/21 2:37 AM, Paul A. Clarke wrote:
> > > On Fri, Mar 26, 2021 at 10:57:40AM +0000, John Garry wrote:
> > > > On 25/03/2021 20:39, Paul A. Clarke wrote:
> > > > > On Thu, Mar 25, 2021 at 06:33:12PM +0800, John Garry wrote:
> > > > > > Metric reuse support is added for pmu-events parse metric testcase.
> > > > > > This had been broken on power9 recentlty:
> > > > > > https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/
> > > > > 
> > > > > Much better.  Before:
> > > > > --
> > > > > $ perf test -v 10 2>&1 | grep -i error | wc -l
> > > > > 112
> > > > > --
> > > > > After:
> > > > > --
> > > > > $ perf test -v 10 2>&1 | grep -i error | wc -l
> > > > > 17
> > > > > --
> > > > > 
> > > > > And these seem like different types of issues:
> > > > > --
> > > > > $ perf test -v 10 2>&1 | grep -i error
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_powerbus0_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs01_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > Error string 'Cannot find PMU `nest_mcs23_imc'. Missing kernel support?' help '(null)'
> > > > > --
> > > > > 
> > > > 
> > > > This looks suspicious.
> > > > 
> > > > Firstly, does /sys/bus/event_source/devices/nest_mcs01_imc (or others,
> > > > above) exist on your system? I guess not.
> > > > 
> > > > Secondly, checking Documentation/powerpc/imc.rst, we have examples of:
> > > > nest_mcs01/PM_MCS01_64B_R...
> > > > 
> > > > So is the PMU name correct in the metric file for nest_mcs01_imc? Looking at
> > > > the kernel driver file, arch/powerpc/perf/imc-pmu.c, it seems to be correct.
> > > > Not sure.
> > > 
> > > I ran with a newer kernel, and the above errors disappeared, replaced with
> > > about 10 of:
> > > --
> > > Error string 'Cannot find PMU `hv_24x7'. Missing kernel support?' help '(null)'
> > > --
> > > 
> > > ...but I was running without a hypervisor, so I tried the same kernel on a
> > > PowerVM-virtualized system and the "hv_24x7" messages went away, but the
> > > "nest" messages returned.  This may all be expected behavior... I confess
> > > I haven't followed these new perf capabilities closely.
> > > 
> > 
> > Hi Paul/John,
> >     This is something expected. For nest-imc we need bare-metal system and for
> > hv-24x7 we need VM environment. Since you are checking this test in VM machine,
> > there nest events are not supported and hence we are getting this error.
> > 
> > Thanks,
> > Kajol Jain
> 
> Cool, so I hope that tested-by or similar can be provided :) [obviously
> pending any changes that come from reviews]

Certainly!

Tested-by: Paul A. Clarke <pc at us.ibm.com>

PC


From will at kernel.org  Tue Apr  6 13:19:56 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 6 Apr 2021 13:19:56 +0100
Subject: [RFC PATCH v3 11/12] iommu/arm-smmu: Implement the unmap_pages()
 IOMMU driver callback
In-Reply-To: <20210405191112.28192-12-isaacm@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-12-isaacm@codeaurora.org>
Message-ID: <20210406121955.GG13747@willie-the-truck>

On Mon, Apr 05, 2021 at 12:11:11PM -0700, Isaac J. Manjarres wrote:
> Implement the unmap_pages() callback for the ARM SMMU driver
> to allow calls from iommu_unmap to unmap multiple pages of
> the same size in one call.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index d8c6bfde6a61..f29f1fb109f8 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -1225,6 +1225,24 @@ static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
>  	return ret;
>  }
>  
> +static size_t arm_smmu_unmap_pages(struct iommu_domain *domain, unsigned long iova,
> +				   size_t pgsize, size_t pgcount,
> +				   struct iommu_iotlb_gather *iotlb_gather)
> +{
> +	struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
> +	struct arm_smmu_device *smmu = to_smmu_domain(domain)->smmu;
> +	size_t ret;
> +
> +	if (!ops)
> +		return 0;
> +
> +	arm_smmu_rpm_get(smmu);
> +	ret = ops->unmap_pages(ops, iova, pgsize, pgcount, iotlb_gather);
> +	arm_smmu_rpm_put(smmu);
> +
> +	return ret;
> +}

Doesn't this go wrong if we're using the short-descriptor page-table
format? (same for the next patch)

Will


From wangwensheng4 at huawei.com  Tue Apr  6 13:17:59 2021
From: wangwensheng4 at huawei.com (Wang Wensheng)
Date: Tue, 6 Apr 2021 12:17:59 +0000
Subject: [PATCH -next] KVM: arm64: Fix error return code in init_hyp_mode()
Message-ID: <20210406121759.5407-1-wangwensheng4@huawei.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: eeeee7193df0 ("KVM: arm64: Bootstrap PSCI SMC handler in nVHE EL2")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wang Wensheng <wangwensheng4 at huawei.com>
---
 arch/arm64/kvm/arm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 76a7de1..41e0b2a 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1877,8 +1877,10 @@ static int init_hyp_mode(void)
 	if (is_protected_kvm_enabled()) {
 		init_cpu_logical_map();
 
-		if (!init_psci_relay())
+		if (!init_psci_relay()) {
+			err = -ENODEV;
 			goto out_err;
+		}
 	}
 
 	if (is_protected_kvm_enabled()) {
-- 
2.9.4



From linqiheng at huawei.com  Tue Apr  6 13:28:40 2021
From: linqiheng at huawei.com (Qiheng Lin)
Date: Tue, 6 Apr 2021 20:28:40 +0800
Subject: [PATCH -next] PM: AVS: remove redundant dev_err call in
 omap_sr_probe()
Message-ID: <20210406122840.39-1-linqiheng@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
---
 drivers/soc/ti/smartreflex.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
index 5376f3d22f31..06cbee5fd254 100644
--- a/drivers/soc/ti/smartreflex.c
+++ b/drivers/soc/ti/smartreflex.c
@@ -846,10 +846,8 @@ static int omap_sr_probe(struct platform_device *pdev)
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	sr_info->base = devm_ioremap_resource(&pdev->dev, mem);
-	if (IS_ERR(sr_info->base)) {
-		dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
+	if (IS_ERR(sr_info->base))
 		return PTR_ERR(sr_info->base);
-	}
 
 	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 



From vee.khee.wong at linux.intel.com  Tue Apr  6 13:33:58 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Tue, 6 Apr 2021 20:33:58 +0800
Subject: [PATCH net-next v1 1/1] stmmac: intel: Drop duplicate ID in the
 list of PCI device IDs
In-Reply-To: <20210406101306.59162-1-andriy.shevchenko@linux.intel.com>
References: <20210406101306.59162-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210406123358.GA14588@linux.intel.com>

On Tue, Apr 06, 2021 at 01:13:06PM +0300, Andy Shevchenko wrote:
> The PCI device IDs are defined with a prefix PCI_DEVICE_ID.
> There is no need to repeat the ID part at the end of each definition.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Reviewed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>

> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 60 +++++++++----------
>  1 file changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index 3d9a57043af2..7f0ce373a63d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -1053,41 +1053,41 @@ static int __maybe_unused intel_eth_pci_resume(struct device *dev)
>  static SIMPLE_DEV_PM_OPS(intel_eth_pm_ops, intel_eth_pci_suspend,
>  			 intel_eth_pci_resume);
>  
> -#define PCI_DEVICE_ID_INTEL_QUARK_ID			0x0937
> -#define PCI_DEVICE_ID_INTEL_EHL_RGMII1G_ID		0x4b30
> -#define PCI_DEVICE_ID_INTEL_EHL_SGMII1G_ID		0x4b31
> -#define PCI_DEVICE_ID_INTEL_EHL_SGMII2G5_ID		0x4b32
> +#define PCI_DEVICE_ID_INTEL_QUARK		0x0937
> +#define PCI_DEVICE_ID_INTEL_EHL_RGMII1G		0x4b30
> +#define PCI_DEVICE_ID_INTEL_EHL_SGMII1G		0x4b31
> +#define PCI_DEVICE_ID_INTEL_EHL_SGMII2G5	0x4b32
>  /* Intel(R) Programmable Services Engine (Intel(R) PSE) consist of 2 MAC
>   * which are named PSE0 and PSE1
>   */
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE0_RGMII1G_ID		0x4ba0
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII1G_ID		0x4ba1
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII2G5_ID	0x4ba2
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE1_RGMII1G_ID		0x4bb0
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII1G_ID		0x4bb1
> -#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII2G5_ID	0x4bb2
> -#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_0_ID		0x43ac
> -#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_1_ID		0x43a2
> -#define PCI_DEVICE_ID_INTEL_TGL_SGMII1G_ID		0xa0ac
> -#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_0_ID		0x7aac
> -#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_1_ID		0x7aad
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE0_RGMII1G	0x4ba0
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII1G	0x4ba1
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE0_SGMII2G5	0x4ba2
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE1_RGMII1G	0x4bb0
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII1G	0x4bb1
> +#define PCI_DEVICE_ID_INTEL_EHL_PSE1_SGMII2G5	0x4bb2
> +#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_0	0x43ac
> +#define PCI_DEVICE_ID_INTEL_TGLH_SGMII1G_1	0x43a2
> +#define PCI_DEVICE_ID_INTEL_TGL_SGMII1G		0xa0ac
> +#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_0	0x7aac
> +#define PCI_DEVICE_ID_INTEL_ADLS_SGMII1G_1	0x7aad
>  
>  static const struct pci_device_id intel_eth_pci_id_table[] = {
> -	{ PCI_DEVICE_DATA(INTEL, QUARK_ID, &quark_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_RGMII1G_ID, &ehl_rgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII1G_ID, &ehl_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII2G5_ID, &ehl_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_RGMII1G_ID, &ehl_pse0_rgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII1G_ID, &ehl_pse0_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII2G5_ID, &ehl_pse0_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_RGMII1G_ID, &ehl_pse1_rgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII1G_ID, &ehl_pse1_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII2G5_ID, &ehl_pse1_sgmii1g_info) },
> -	{ PCI_DEVICE_DATA(INTEL, TGL_SGMII1G_ID, &tgl_sgmii1g_phy0_info) },
> -	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_0_ID, &tgl_sgmii1g_phy0_info) },
> -	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_1_ID, &tgl_sgmii1g_phy1_info) },
> -	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_0_ID, &adls_sgmii1g_phy0_info) },
> -	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_1_ID, &adls_sgmii1g_phy1_info) },
> +	{ PCI_DEVICE_DATA(INTEL, QUARK, &quark_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_RGMII1G, &ehl_rgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII1G, &ehl_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_SGMII2G5, &ehl_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_RGMII1G, &ehl_pse0_rgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII1G, &ehl_pse0_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE0_SGMII2G5, &ehl_pse0_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_RGMII1G, &ehl_pse1_rgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII1G, &ehl_pse1_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, EHL_PSE1_SGMII2G5, &ehl_pse1_sgmii1g_info) },
> +	{ PCI_DEVICE_DATA(INTEL, TGL_SGMII1G, &tgl_sgmii1g_phy0_info) },
> +	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_0, &tgl_sgmii1g_phy0_info) },
> +	{ PCI_DEVICE_DATA(INTEL, TGLH_SGMII1G_1, &tgl_sgmii1g_phy1_info) },
> +	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_0, &adls_sgmii1g_phy0_info) },
> +	{ PCI_DEVICE_DATA(INTEL, ADLS_SGMII1G_1, &adls_sgmii1g_phy1_info) },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(pci, intel_eth_pci_id_table);
> -- 
> 2.30.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From john.garry at huawei.com  Tue Apr  6 13:43:09 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 13:43:09 +0100
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <YGxRbH0XWaj6AWfa@krava>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava> <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
 <YGxRbH0XWaj6AWfa@krava>
Message-ID: <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>

On 06/04/2021 13:17, Jiri Olsa wrote:
>>>> +			ref = &metric->metric_ref;
>>>> +			ref->metric_name = pe->metric_name;
>>>> +			ref->metric_expr = pe->metric_expr;
>>>> +			list_add_tail(&metric->list, compound_list);
>>>> +
>>>> +			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
>> Hi Jirka,
>>
>>> so this might add new items to pctx->ids, I think you need
>>> to restart the iteration as we do it in __resolve_metric
>>> otherwise you could miss some new keys
>> I thought that I was doing this. Indeed, this code is very much like
>> __resolve_metric();)
>>
>> So expr__find_other() may add a new item to pctx->ids, and we always iterate
>> again, and try to lookup any pmu_events, *, above. If none exist, then we
> hm, I don't see that.. so, what you do is:
> 
> 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> 
> 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> 	}
> 
> and what I think we need to do is:
> 
> 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> 
> 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> 
> 		break;	
> 	}
> 
> each time you resolve another metric, you need to restart
> the pctx->ids iteration, because there will be new items,
> and we are in the middle of it

Sure, but we will restart anyway.

Regardless of this, I don't think what I am doing is safe, i.e. adding 
new items in the middle of the iter, so I will change in the way you 
suggest.

Thanks,
John


From nicolas.ferre at microchip.com  Tue Apr  6 13:45:40 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Tue, 6 Apr 2021 14:45:40 +0200
Subject: [PATCH v4 3/6] pwm: atmel: Simplify using devm_clk_get_prepared()
In-Reply-To: <20210330181755.204339-4-u.kleine-koenig@pengutronix.de>
References: <20210330181755.204339-1-u.kleine-koenig@pengutronix.de>
 <20210330181755.204339-4-u.kleine-koenig@pengutronix.de>
Message-ID: <822218d0-6b28-98d9-c23a-2dc3c3f0c84a@microchip.com>

On 30/03/2021 at 20:17, Uwe Kleine-K?nig wrote:
> With devm_clk_get_prepared() caring to unprepare the clock the error
> path and remove callback can be simplified accordingly.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Looks good to me:
Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>

> ---
>   drivers/pwm/pwm-atmel.c | 15 ++-------------
>   1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index 5813339b597b..d65e23da2582 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -415,16 +415,10 @@ static int atmel_pwm_probe(struct platform_device *pdev)
>          if (IS_ERR(atmel_pwm->base))
>                  return PTR_ERR(atmel_pwm->base);
> 
> -       atmel_pwm->clk = devm_clk_get(&pdev->dev, NULL);
> +       atmel_pwm->clk = devm_clk_get_prepared(&pdev->dev, NULL);
>          if (IS_ERR(atmel_pwm->clk))
>                  return PTR_ERR(atmel_pwm->clk);
> 
> -       ret = clk_prepare(atmel_pwm->clk);
> -       if (ret) {
> -               dev_err(&pdev->dev, "failed to prepare PWM clock\n");
> -               return ret;
> -       }
> -
>          atmel_pwm->chip.dev = &pdev->dev;
>          atmel_pwm->chip.ops = &atmel_pwm_ops;
>          atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> @@ -435,23 +429,18 @@ static int atmel_pwm_probe(struct platform_device *pdev)
>          ret = pwmchip_add(&atmel_pwm->chip);
>          if (ret < 0) {
>                  dev_err(&pdev->dev, "failed to add PWM chip %d\n", ret);
> -               goto unprepare_clk;
> +               return ret;
>          }
> 
>          platform_set_drvdata(pdev, atmel_pwm);
> 
>          return ret;
> -
> -unprepare_clk:
> -       clk_unprepare(atmel_pwm->clk);
> -       return ret;
>   }
> 
>   static int atmel_pwm_remove(struct platform_device *pdev)
>   {
>          struct atmel_pwm_chip *atmel_pwm = platform_get_drvdata(pdev);
> 
> -       clk_unprepare(atmel_pwm->clk);
>          mutex_destroy(&atmel_pwm->isr_lock);
> 
>          return pwmchip_remove(&atmel_pwm->chip);
> --
> 2.30.2
> 


-- 
Nicolas Ferre


From jolsa at redhat.com  Tue Apr  6 13:55:22 2021
From: jolsa at redhat.com (Jiri Olsa)
Date: Tue, 6 Apr 2021 14:55:22 +0200
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava>
 <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
 <YGxRbH0XWaj6AWfa@krava>
 <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>
Message-ID: <YGxaOnUZnNmDg/2P@krava>

On Tue, Apr 06, 2021 at 01:43:09PM +0100, John Garry wrote:
> On 06/04/2021 13:17, Jiri Olsa wrote:
> > > > > +			ref = &metric->metric_ref;
> > > > > +			ref->metric_name = pe->metric_name;
> > > > > +			ref->metric_expr = pe->metric_expr;
> > > > > +			list_add_tail(&metric->list, compound_list);
> > > > > +
> > > > > +			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > > Hi Jirka,
> > > 
> > > > so this might add new items to pctx->ids, I think you need
> > > > to restart the iteration as we do it in __resolve_metric
> > > > otherwise you could miss some new keys
> > > I thought that I was doing this. Indeed, this code is very much like
> > > __resolve_metric();)
> > > 
> > > So expr__find_other() may add a new item to pctx->ids, and we always iterate
> > > again, and try to lookup any pmu_events, *, above. If none exist, then we
> > hm, I don't see that.. so, what you do is:
> > 
> > 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> > 
> > 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > 	}
> > 
> > and what I think we need to do is:
> > 
> > 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> > 
> > 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > 
> > 		break;	
> > 	}
> > 
> > each time you resolve another metric, you need to restart
> > the pctx->ids iteration, because there will be new items,
> > and we are in the middle of it
> 
> Sure, but we will restart anyway.

hum, where? you call expr__find_other and continue to next
pctx->ids item

> 
> Regardless of this, I don't think what I am doing is safe, i.e. adding new
> items in the middle of the iter, so I will change in the way you suggest.

it'll always add items in the middle of the iteration

jirka

> 
> Thanks,
> John
> 



From nicolas.ferre at microchip.com  Tue Apr  6 13:55:38 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Tue, 6 Apr 2021 14:55:38 +0200
Subject: [PATCH v4 4/6] rtc: at91sma9: Simplify using
 devm_clk_get_enabled()
In-Reply-To: <20210330181755.204339-5-u.kleine-koenig@pengutronix.de>
References: <20210330181755.204339-1-u.kleine-koenig@pengutronix.de>
 <20210330181755.204339-5-u.kleine-koenig@pengutronix.de>
Message-ID: <cacffd33-0df6-9c96-78bf-8313821daaee@microchip.com>

On 30/03/2021 at 20:17, Uwe Kleine-K?nig wrote:
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

I do see the benefit:
Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>

Thanks Uwe for taking these drivers as examples! Best regards,
   Nicolas

> ---
>   drivers/rtc/rtc-at91sam9.c | 22 ++++------------------
>   1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
> index 2216be429ab7..b52e7bd26303 100644
> --- a/drivers/rtc/rtc-at91sam9.c
> +++ b/drivers/rtc/rtc-at91sam9.c
> @@ -374,21 +374,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
>                  return -ENOMEM;
>          }
> 
> -       rtc->sclk = devm_clk_get(&pdev->dev, NULL);
> +       rtc->sclk = devm_clk_get_enabled(&pdev->dev, NULL);
>          if (IS_ERR(rtc->sclk))
>                  return PTR_ERR(rtc->sclk);
> 
> -       ret = clk_prepare_enable(rtc->sclk);
> -       if (ret) {
> -               dev_err(&pdev->dev, "Could not enable slow clock\n");
> -               return ret;
> -       }
> -
>          sclk_rate = clk_get_rate(rtc->sclk);
>          if (!sclk_rate || sclk_rate > AT91_RTT_RTPRES) {
>                  dev_err(&pdev->dev, "Invalid slow clock rate\n");
> -               ret = -EINVAL;
> -               goto err_clk;
> +               return -EINVAL;
>          }
> 
>          mr = rtt_readl(rtc, MR);
> @@ -406,7 +399,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
>          rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
>          if (IS_ERR(rtc->rtcdev)) {
>                  ret = PTR_ERR(rtc->rtcdev);
> -               goto err_clk;
> +               return ret;
>          }
> 
>          rtc->rtcdev->ops = &at91_rtc_ops;
> @@ -418,7 +411,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
>                                 dev_name(&rtc->rtcdev->dev), rtc);
>          if (ret) {
>                  dev_dbg(&pdev->dev, "can't share IRQ %d?\n", rtc->irq);
> -               goto err_clk;
> +               return ret;
>          }
> 
>          /* NOTE:  sam9260 rev A silicon has a ROM bug which resets the
> @@ -432,11 +425,6 @@ static int at91_rtc_probe(struct platform_device *pdev)
>                           dev_name(&rtc->rtcdev->dev));
> 
>          return devm_rtc_register_device(rtc->rtcdev);
> -
> -err_clk:
> -       clk_disable_unprepare(rtc->sclk);
> -
> -       return ret;
>   }
> 
>   /*
> @@ -450,8 +438,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
>          /* disable all interrupts */
>          rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
> 
> -       clk_disable_unprepare(rtc->sclk);
> -
>          return 0;
>   }
> 
> --
> 2.30.2
> 


-- 
Nicolas Ferre


From maz at kernel.org  Tue Apr  6 13:58:41 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 13:58:41 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
Message-ID: <20210406125841.1077079-1-maz@kernel.org>

Although the KVM_ARM_VCPU_INIT documentation mention that the
registers are reset to their "initial values", it doesn't
describe what these values are.

Describe this state explicitly.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 Documentation/virt/kvm/api.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 38e327d4b479..e2237e4e10ba 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -3115,6 +3115,16 @@ optional features it should have. ?This will cause a reset of the cpu
 registers to their initial values. ?If this is not called, KVM_RUN will
 return ENOEXEC for that vcpu.
 
+The initial values are defined as:
+	- Processor state:
+		* AArch64: EL1h, D, A, I and F bits set
+		* Aarch32: SVC, D, A, I and F bits set
+	- General Purpose registers, including PC and SP: set to 0
+	- FPSIMD/NEON registers: set to 0
+	- SVE registers: set to 0
+	- System registers: Reset to their architecturally defined
+	  values as for a warm reset to EL1 (resp. SVC)
+
 Note that because some registers reflect machine topology, all vcpus
 should be created before this ioctl is invoked.
 
-- 
2.29.2



From ardb at kernel.org  Tue Apr  6 13:59:28 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 6 Apr 2021 14:59:28 +0200
Subject: [PATCH v5 14/18] arm64: add __nocfi to functions that jump to a
 physical address
In-Reply-To: <20210406115357.GE96480@C02TD0UTHF1T.local>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-15-samitolvanen@google.com>
 <20210406115357.GE96480@C02TD0UTHF1T.local>
Message-ID: <CAMj1kXFHm5rqKqku5=WF-NcsUNmWp4Ymxu7aO9=XkD-LhLr-dA@mail.gmail.com>

On Tue, 6 Apr 2021 at 13:54, Mark Rutland <mark.rutland at arm.com> wrote:
>
> [adding Ard for EFI runtime services bits]
>
> On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote:
> > Disable CFI checking for functions that switch to linear mapping and
> > make an indirect call to a physical address, since the compiler only
> > understands virtual addresses and the CFI check for such indirect calls
> > would always fail.
>
> What does physical vs virtual have to do with this? Does the address
> actually matter, or is this just a general thing that when calling an
> assembly function we won't have a trampoline that the caller expects?
>
> I wonder if we need to do something with asmlinkage here, perhaps?
>
> I didn't spot anything in the seriues handling EFI runtime services
> calls, and I strongly suspect we need to do something for those, unless
> they're handled implicitly by something else.
>

All indirect EFI calls are routed via a asm helper that I originally
added to check whether x18 was corrupted by the firmware. So from the
caller side, we should be fine.

All callees are addresses that are provided by the firmware via tables
in memory, so I would assume that this addresses the callee side as
well. AFAICT, it is never left up to the compiler to emit these
indirect calls, or take the address of a firmware routine.

But a test would be nice :-)

> > Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> > Reviewed-by: Kees Cook <keescook at chromium.org>
> > ---
> >  arch/arm64/include/asm/mmu_context.h | 2 +-
> >  arch/arm64/kernel/cpu-reset.h        | 8 ++++----
> >  arch/arm64/kernel/cpufeature.c       | 2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> > index 386b96400a57..d3cef9133539 100644
> > --- a/arch/arm64/include/asm/mmu_context.h
> > +++ b/arch/arm64/include/asm/mmu_context.h
> > @@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void)
> >   * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
> >   * avoiding the possibility of conflicting TLB entries being allocated.
> >   */
> > -static inline void cpu_replace_ttbr1(pgd_t *pgdp)
> > +static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
>
> Given these are inlines, what's the effect when these are inlined into a
> function that would normally use CFI? Does CFI get supressed for the
> whole function, or just the bit that got inlined?
>
> Is there an attribute that we could place on a function pointer to tell
> the compiler to not check calls via that pointer? If that existed we'd
> be able to scope this much more tightly.
>

I agree that it would be very helpful to be able to define a function
pointer type that is exempt from CFI checks.


From andrea.merello at gmail.com  Tue Apr  6 14:00:43 2021
From: andrea.merello at gmail.com (Andrea Merello)
Date: Tue,  6 Apr 2021 15:00:43 +0200
Subject: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get_cycles()
 not supported
Message-ID: <20210406130045.15491-1-andrea.merello@gmail.com>

Changes wrt v1:
 - rebased on latest kernel tree
 - fix cover letter: does -> doesn't

A real-world problem has been seen with a Zynq-based board running
Debian 10, where ssh daemon takes a really long time to come up at boot.
This is due to lack of random numbers.

Since commit 50ee7529ec450 ("random: try to actively add entropy rather
than passively wait for it") we try to generate entropy whenever we are
in short of random numbers and someone needs them.

This trick works only when CPU cycle counter is available. On ARM this
means that get_cycles() works and in turn read_current_timer() works.

Zynq HW includes two "cadence TTC" timers and the "ARM global timer".
All these pieces of HW are fed by the CPU clock, which dynamically
changes whenever CPU frequency scaling is enabled.

In timer-cadence-ttc driver this scenario is handled by looking at parent
clock changes and adjusting things when required. This is the only usable
clocksource when CPU frequency scaling is in use. arm_global_timer driver
is disabled in Kconfig when CPU_FREQ is enabled for Zynq arch.

Unfortunately timer-cadence-ttc driver doesn't register itself via
register_current_timer_delay() and that ultimately ends up in get_cycles()
to always return zero, causing the aforementioned lack of entropy problem.
I believe that the reason for this is because Cadence TTC counter on Zynq
silicon is only 16-bit wide.

This patchset works around this by implementing in ARM global timer driver
a mechanism to compensate for parent clock variations, similarly to what
it's done in Cadence TTC timer driver, so that it can be used together
with CPU frequency scaling on Zynq arch.

This proved to finally fix the problem on my Zynq-based Z-turn board.

Signed-off-by: Andrea Merello <andrea.merello at gmail.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>

Andrea Merello (2):
  clocksource: arm_global_timer: implement rate compensation whenever
    source clock changes
  arm: zynq: don't disable CONFIG_ARM_GLOBAL_TIMER due to
    CONFIG_CPU_FREQ anymore

 arch/arm/mach-zynq/Kconfig             |   2 +-
 drivers/clocksource/Kconfig            |  14 +++
 drivers/clocksource/arm_global_timer.c | 122 +++++++++++++++++++++++--
 3 files changed, 127 insertions(+), 11 deletions(-)

--
2.17.1


From andrea.merello at gmail.com  Tue Apr  6 14:00:44 2021
From: andrea.merello at gmail.com (Andrea Merello)
Date: Tue,  6 Apr 2021 15:00:44 +0200
Subject: [PATCH v2 1/2] clocksource: arm_global_timer: implement rate
 compensation whenever source clock changes
In-Reply-To: <20210406130045.15491-1-andrea.merello@gmail.com>
References: <20210406130045.15491-1-andrea.merello@gmail.com>
Message-ID: <20210406130045.15491-2-andrea.merello@gmail.com>

This patch adds rate change notification support for the parent clock;
should that clock change, then we try to adjust the our prescaler in order
to compensate (i.e. we adjust to still get the same timer frequency).

This is loosely based on what it's done in timer-cadence-ttc. timer-sun51,
mips-gic-timer and smp_twd.c also seem to look at their parent clock rate
and to perform some kind of adjustment whenever needed.

In this particular case we have only one single counter and prescaler for
all clocksource, clockevent and timer_delay, and we just update it for all
(i.e. we don't let it go and call clockevents_update_freq() to notify to
the kernel that our rate has changed).

Note that, there is apparently no other way to fixup things, because once
we call register_current_timer_delay(), specifying the timer rate, it seems
that that rate is not supposed to change ever.

In order for this mechanism to work, we have to make assumptions about how
much the initial clock is supposed to eventually decrease from the initial
one, and set our initial prescaler to a value that we can eventually
decrease enough to compensate. We provide an option in KConfig for this.

In case we end up in a situation in which we are not able to compensate the
parent clock change, we fail returning NOTIFY_BAD.

This fixes a real-world problem with Zynq arch not being able to use this
driver and CPU_FREQ at the same time (because ARM global timer is fed by
the CPU clock, which may keep changing when CPU_FREQ is enabled).

Signed-off-by: Andrea Merello <andrea.merello at gmail.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
---
 drivers/clocksource/Kconfig            |  13 +++
 drivers/clocksource/arm_global_timer.c | 122 +++++++++++++++++++++++--
 2 files changed, 125 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 39aa21d01e05..19fc5f8883e0 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -358,6 +358,19 @@ config ARM_GLOBAL_TIMER
 	help
 	  This option enables support for the ARM global timer unit.
 
+config ARM_GT_INITIAL_PRESCALER_VAL
+	int "ARM global timer initial prescaler value"
+	default 1
+	depends on ARM_GLOBAL_TIMER
+	help
+	  When the ARM global timer initializes, its current rate is declared
+	  to the kernel and maintained forever. Should it's parent clock
+	  change, the driver tries to fix the timer's internal prescaler.
+	  On some machs (i.e. Zynq) the initial prescaler value thus poses
+	  bounds about how much the parent clock is allowed to decrease or
+	  increase wrt the initial clock value.
+	  This affects CPU_FREQ max delta from the initial frequency.
+
 config ARM_TIMER_SP804
 	bool "Support for Dual Timer SP804 module" if COMPILE_TEST
 	depends on GENERIC_SCHED_CLOCK && CLKDEV_LOOKUP
diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
index 88b2d38a7a61..60a8047fd32e 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -31,6 +31,10 @@
 #define GT_CONTROL_COMP_ENABLE		BIT(1)	/* banked */
 #define GT_CONTROL_IRQ_ENABLE		BIT(2)	/* banked */
 #define GT_CONTROL_AUTO_INC		BIT(3)	/* banked */
+#define GT_CONTROL_PRESCALER_SHIFT      8
+#define GT_CONTROL_PRESCALER_MAX        0xF
+#define GT_CONTROL_PRESCALER_MASK       (GT_CONTROL_PRESCALER_MAX << \
+					 GT_CONTROL_PRESCALER_SHIFT)
 
 #define GT_INT_STATUS	0x0c
 #define GT_INT_STATUS_EVENT_FLAG	BIT(0)
@@ -39,6 +43,7 @@
 #define GT_COMP1	0x14
 #define GT_AUTO_INC	0x18
 
+#define MAX_F_ERR 50
 /*
  * We are expecting to be clocked by the ARM peripheral clock.
  *
@@ -46,7 +51,8 @@
  * the units for all operations.
  */
 static void __iomem *gt_base;
-static unsigned long gt_clk_rate;
+struct notifier_block gt_clk_rate_change_nb;
+static u32 gt_psv_new, gt_psv_bck, gt_target_rate;
 static int gt_ppi;
 static struct clock_event_device __percpu *gt_evt;
 
@@ -96,7 +102,10 @@ static void gt_compare_set(unsigned long delta, int periodic)
 	unsigned long ctrl;
 
 	counter += delta;
-	ctrl = GT_CONTROL_TIMER_ENABLE;
+	ctrl = readl(gt_base + GT_CONTROL);
+	ctrl &= ~(GT_CONTROL_COMP_ENABLE | GT_CONTROL_IRQ_ENABLE |
+		  GT_CONTROL_AUTO_INC | GT_CONTROL_AUTO_INC);
+	ctrl |= GT_CONTROL_TIMER_ENABLE;
 	writel_relaxed(ctrl, gt_base + GT_CONTROL);
 	writel_relaxed(lower_32_bits(counter), gt_base + GT_COMP0);
 	writel_relaxed(upper_32_bits(counter), gt_base + GT_COMP1);
@@ -123,7 +132,7 @@ static int gt_clockevent_shutdown(struct clock_event_device *evt)
 
 static int gt_clockevent_set_periodic(struct clock_event_device *evt)
 {
-	gt_compare_set(DIV_ROUND_CLOSEST(gt_clk_rate, HZ), 1);
+	gt_compare_set(DIV_ROUND_CLOSEST(gt_target_rate, HZ), 1);
 	return 0;
 }
 
@@ -177,7 +186,7 @@ static int gt_starting_cpu(unsigned int cpu)
 	clk->cpumask = cpumask_of(cpu);
 	clk->rating = 300;
 	clk->irq = gt_ppi;
-	clockevents_config_and_register(clk, gt_clk_rate,
+	clockevents_config_and_register(clk, gt_target_rate,
 					1, 0xffffffff);
 	enable_percpu_irq(clk->irq, IRQ_TYPE_NONE);
 	return 0;
@@ -232,9 +241,28 @@ static struct delay_timer gt_delay_timer = {
 	.read_current_timer = gt_read_long,
 };
 
+static void gt_write_presc(u32 psv)
+{
+	u32 reg;
+
+	reg = readl(gt_base + GT_CONTROL);
+	reg &= ~GT_CONTROL_PRESCALER_MASK;
+	reg |= psv << GT_CONTROL_PRESCALER_SHIFT;
+	writel(reg, gt_base + GT_CONTROL);
+}
+
+static u32 gt_read_presc(void)
+{
+	u32 reg;
+
+	reg = readl(gt_base + GT_CONTROL);
+	reg &= GT_CONTROL_PRESCALER_MASK;
+	return reg >> GT_CONTROL_PRESCALER_SHIFT;
+}
+
 static void __init gt_delay_timer_init(void)
 {
-	gt_delay_timer.freq = gt_clk_rate;
+	gt_delay_timer.freq = gt_target_rate;
 	register_current_timer_delay(&gt_delay_timer);
 }
 
@@ -243,18 +271,81 @@ static int __init gt_clocksource_init(void)
 	writel(0, gt_base + GT_CONTROL);
 	writel(0, gt_base + GT_COUNTER0);
 	writel(0, gt_base + GT_COUNTER1);
-	/* enables timer on all the cores */
-	writel(GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
+	/* set prescaler and enable timer on all the cores */
+	writel(((CONFIG_ARM_GT_INITIAL_PRESCALER_VAL - 1) <<
+		GT_CONTROL_PRESCALER_SHIFT)
+	       | GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
 
 #ifdef CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
-	sched_clock_register(gt_sched_clock_read, 64, gt_clk_rate);
+	sched_clock_register(gt_sched_clock_read, 64, gt_target_rate);
 #endif
-	return clocksource_register_hz(&gt_clocksource, gt_clk_rate);
+	return clocksource_register_hz(&gt_clocksource, gt_target_rate);
+}
+
+static int gt_clk_rate_change_cb(struct notifier_block *nb,
+				 unsigned long event, void *data)
+{
+	struct clk_notifier_data *ndata = data;
+
+	switch (event) {
+	case PRE_RATE_CHANGE:
+	{
+		int psv;
+
+		psv = DIV_ROUND_CLOSEST(ndata->new_rate,
+					gt_target_rate);
+
+		if (abs(gt_target_rate - (ndata->new_rate / psv)) > MAX_F_ERR)
+			return NOTIFY_BAD;
+
+		psv--;
+
+		/* prescaler within legal range? */
+		if (psv < 0 || psv > GT_CONTROL_PRESCALER_MAX)
+			return NOTIFY_BAD;
+
+		/*
+		 * store timer clock ctrl register so we can restore it in case
+		 * of an abort.
+		 */
+		gt_psv_bck = gt_read_presc();
+		gt_psv_new = psv;
+		/* scale down: adjust divider in post-change notification */
+		if (ndata->new_rate < ndata->old_rate)
+			return NOTIFY_DONE;
+
+		/* scale up: adjust divider now - before frequency change */
+		gt_write_presc(psv);
+		break;
+	}
+	case POST_RATE_CHANGE:
+		/* scale up: pre-change notification did the adjustment */
+		if (ndata->new_rate > ndata->old_rate)
+			return NOTIFY_OK;
+
+		/* scale down: adjust divider now - after frequency change */
+		gt_write_presc(gt_psv_new);
+		break;
+
+	case ABORT_RATE_CHANGE:
+		/* we have to undo the adjustment in case we scale up */
+		if (ndata->new_rate < ndata->old_rate)
+			return NOTIFY_OK;
+
+		/* restore original register value */
+		gt_write_presc(gt_psv_bck);
+		break;
+	default:
+		return NOTIFY_DONE;
+	}
+
+	return NOTIFY_DONE;
 }
 
 static int __init global_timer_of_register(struct device_node *np)
 {
 	struct clk *gt_clk;
+	static unsigned long gt_clk_rate;
 	int err = 0;
 
 	/*
@@ -292,11 +383,20 @@ static int __init global_timer_of_register(struct device_node *np)
 	}
 
 	gt_clk_rate = clk_get_rate(gt_clk);
+	gt_target_rate = gt_clk_rate / CONFIG_ARM_GT_INITIAL_PRESCALER_VAL;
+	gt_clk_rate_change_nb.notifier_call =
+		gt_clk_rate_change_cb;
+	err = clk_notifier_register(gt_clk, &gt_clk_rate_change_nb);
+	if (err) {
+		pr_warn("Unable to register clock notifier\n");
+		goto out_clk;
+	}
+
 	gt_evt = alloc_percpu(struct clock_event_device);
 	if (!gt_evt) {
 		pr_warn("global-timer: can't allocate memory\n");
 		err = -ENOMEM;
-		goto out_clk;
+		goto out_clk_nb;
 	}
 
 	err = request_percpu_irq(gt_ppi, gt_clockevent_interrupt,
@@ -326,6 +426,8 @@ static int __init global_timer_of_register(struct device_node *np)
 	free_percpu_irq(gt_ppi, gt_evt);
 out_free:
 	free_percpu(gt_evt);
+out_clk_nb:
+	clk_notifier_unregister(gt_clk, &gt_clk_rate_change_nb);
 out_clk:
 	clk_disable_unprepare(gt_clk);
 out_unmap:
-- 
2.17.1



From andrea.merello at gmail.com  Tue Apr  6 14:00:45 2021
From: andrea.merello at gmail.com (Andrea Merello)
Date: Tue,  6 Apr 2021 15:00:45 +0200
Subject: [PATCH v2 2/2] arm: zynq: don't disable CONFIG_ARM_GLOBAL_TIMER due
 to CONFIG_CPU_FREQ anymore
In-Reply-To: <20210406130045.15491-1-andrea.merello@gmail.com>
References: <20210406130045.15491-1-andrea.merello@gmail.com>
Message-ID: <20210406130045.15491-3-andrea.merello@gmail.com>

Now ARM global timer driver could work even if it's source clock rate
changes, so we don't need to disable that driver when cpu frequency scaling
is in use.

This cause Zynq arch to get support for timer delay and get_cycles().

Signed-off-by: Andrea Merello <andrea.merello at gmail.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/mach-zynq/Kconfig  | 2 +-
 drivers/clocksource/Kconfig | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index 43fb941dcd07..a56748d671c4 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -6,7 +6,7 @@ config ARCH_ZYNQ
 	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
-	select ARM_GLOBAL_TIMER if !CPU_FREQ
+	select ARM_GLOBAL_TIMER
 	select CADENCE_TTC_TIMER
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 19fc5f8883e0..9fa28237715a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -360,6 +360,7 @@ config ARM_GLOBAL_TIMER
 
 config ARM_GT_INITIAL_PRESCALER_VAL
 	int "ARM global timer initial prescaler value"
+	default 2 if ARCH_ZYNQ
 	default 1
 	depends on ARM_GLOBAL_TIMER
 	help
-- 
2.17.1



From maz at kernel.org  Tue Apr  6 14:02:41 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 06 Apr 2021 14:02:41 +0100
Subject: [PATCH 4/9] sh: intc: Drop the use of
 irq_create_identity_mapping()
In-Reply-To: <CAMuHMdU3vo1AWuDr69WK8-1w38+Q7KturAoL=cFpspZiYr2ssA@mail.gmail.com>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-5-maz@kernel.org>
 <CAMuHMdU3vo1AWuDr69WK8-1w38+Q7KturAoL=cFpspZiYr2ssA@mail.gmail.com>
Message-ID: <87im4zpnv2.wl-maz@kernel.org>

On Tue, 06 Apr 2021 11:32:13 +0100,
Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> 
> Hi Marc,
> 
> On Tue, Apr 6, 2021 at 11:44 AM Marc Zyngier <maz at kernel.org> wrote:
> > Instead of playing games with using irq_create_identity_mapping()
> > and irq_domain_associate(), drop the use of the former and only
> > use the latter, together with the allocation of the irq_desc
> > as needed.
> >
> > It doesn't make the code less awful, but at least the intent
> > is clearer.
> >
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> 
> Thanks for your patch!
> 
> > --- a/drivers/sh/intc/core.c
> > +++ b/drivers/sh/intc/core.c
> > @@ -179,6 +179,23 @@ static unsigned int __init save_reg(struct intc_desc_int *d,
> >         return 0;
> >  }
> >
> > +static bool __init intc_map(struct irq_domain *domain, int irq)
> > +{
> > +       int res;
> 
> warning: unused variable ?res? [-Wunused-variable]
> 
> > +
> > +       if (!irq_to_desc(irq) && irq_alloc_desc_at(irq, NUMA_NO_NODE) != irq) {
> > +               pr_err("uname to allocate IRQ %d\n", irq);
> > +               return false;
> > +       }
> > +
> > +       if (irq_domain_associate(domain, irq, irq)) {
> > +               pr_err("domain association failure\n");
> > +               return false;
> > +       }
> > +
> > +       return true;
> > +}
> > +
> >  int __init register_intc_controller(struct intc_desc *desc)
> >  {
> >         unsigned int i, k, smp;
> > @@ -316,19 +333,8 @@ int __init register_intc_controller(struct intc_desc *desc)
> 
> warning: unused variable ?res? [-Wunused-variable]

Ah, thanks for spotting these.

> 
> >                 if (!vect->enum_id)
> >                         continue;
> >
> > -               res = irq_create_identity_mapping(d->domain, irq);
> 
> 
> > -               if (unlikely(res)) {
> > -                       if (res == -EEXIST) {
> > -                               res = irq_domain_associate(d->domain, irq, irq);
> > -                               if (unlikely(res)) {
> > -                                       pr_err("domain association failure\n");
> > -                                       continue;
> > -                               }
> > -                       } else {
> > -                               pr_err("can't identity map IRQ %d\n", irq);
> > -                               continue;
> > -                       }
> > -               }
> > +               if (!intc_map(d->domain, irq))
> > +                       continue;
> >
> >                 intc_irq_xlate_set(irq, vect->enum_id, d);
> >                 intc_register_irq(desc, d, vect->enum_id, irq);
> 
> Otherwise this seems to work fine on real hardware (landisk) and qemu
> (rts7751r2d).  I did verify that the new function intc_map() is called.
> 
> Tested-by: Geert Uytterhoeven <geert+renesas at glider.be>

Awesome, thanks Geert.

	M.

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


From nm at ti.com  Tue Apr  6 14:06:57 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 6 Apr 2021 08:06:57 -0500
Subject: [PATCH -next] PM: AVS: remove redundant dev_err call in
 omap_sr_probe()
In-Reply-To: <20210406122840.39-1-linqiheng@huawei.com>
References: <20210406122840.39-1-linqiheng@huawei.com>
Message-ID: <20210406130657.c5edf3pakylxwavr@spoon>

On 20:28-20210406, Qiheng Lin wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
> ---
>  drivers/soc/ti/smartreflex.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
> index 5376f3d22f31..06cbee5fd254 100644
> --- a/drivers/soc/ti/smartreflex.c
> +++ b/drivers/soc/ti/smartreflex.c
> @@ -846,10 +846,8 @@ static int omap_sr_probe(struct platform_device *pdev)
>  
>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	sr_info->base = devm_ioremap_resource(&pdev->dev, mem);
> -	if (IS_ERR(sr_info->base)) {
> -		dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
> +	if (IS_ERR(sr_info->base))
>  		return PTR_ERR(sr_info->base);
> -	}
>  
>  	irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>  
> 
Reviewed-by: Nishanth Menon <nm at ti.com>

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


From matthias.bgg at gmail.com  Tue Apr  6 14:13:15 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 15:13:15 +0200
Subject: [PATCH v3 1/3] arm64: dts: mediatek: mt8167: add larb nodes
In-Reply-To: <20210406113631.2675029-1-fparent@baylibre.com>
References: <20210406113631.2675029-1-fparent@baylibre.com>
Message-ID: <d554d512-34c2-db46-990f-ac3b4fc18557@gmail.com>



On 06/04/2021 13:36, Fabien Parent wrote:
> Add larb nodes for MT8167:
> * larb0 is used for display (dsi and hdmi)
> * larb1 is used for camera (csi)
> * larb2 is used for the video hardware decoder
> 
> Signed-off-by: Fabien Parent <fparent at baylibre.com>

Whole series applied to v5.12-next/dts64-2

Thanks!

> ---
> 
> Note: This series is based on https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/log/?h=v5.12-next/dts64-2
> 
> V3:
> 	* Removed unicode character in commit summary
> V2:
> 	* Removed unneeded mediatek,larb-id property
> 
>  arch/arm64/boot/dts/mediatek/mt8167.dtsi | 30 ++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> index 4b951f81db9e..bbddd4b22d3e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
> @@ -140,5 +140,35 @@ smi_common: smi at 14017000 {
>  			clock-names = "apb", "smi";
>  			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
>  		};
> +
> +		larb0: larb at 14016000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x14016000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			clocks = <&mmsys CLK_MM_SMI_LARB0>,
> +				 <&mmsys CLK_MM_SMI_LARB0>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
> +		};
> +
> +		larb1: larb at 15001000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x15001000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			clocks = <&imgsys CLK_IMG_LARB1_SMI>,
> +				 <&imgsys CLK_IMG_LARB1_SMI>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
> +		};
> +
> +		larb2: larb at 16010000 {
> +			compatible = "mediatek,mt8167-smi-larb";
> +			reg = <0 0x16010000 0 0x1000>;
> +			mediatek,smi = <&smi_common>;
> +			clocks = <&vdecsys CLK_VDEC_CKEN>,
> +				 <&vdecsys CLK_VDEC_LARB1_CKEN>;
> +			clock-names = "apb", "smi";
> +			power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
> +		};
>  	};
>  };
> 


From maz at kernel.org  Tue Apr  6 14:13:36 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 14:13:36 +0100
Subject: [PATCH] KVM: arm64: Mark the kvmarm ML as moderated for
 non-subscribers
Message-ID: <20210406131336.1077633-1-maz@kernel.org>

The kvmarm mailing list is moderated for non-subscriber, but that
was never advertised. Fix this with the hope that people will
eventually subscribe before posting, saving me the hassle of
letting their post through eventually.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 803bd0551512..54b4f2bcfe19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9768,7 +9768,7 @@ R:	James Morse <james.morse at arm.com>
 R:	Alexandru Elisei <alexandru.elisei at arm.com>
 R:	Suzuki K Poulose <suzuki.poulose at arm.com>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-L:	kvmarm at lists.cs.columbia.edu
+L:	kvmarm at lists.cs.columbia.edu (moderated for non-subscribers)
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
 F:	arch/arm64/include/asm/kvm*
-- 
2.29.2



From kernelfans at gmail.com  Tue Apr  6 14:14:20 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Tue,  6 Apr 2021 21:14:20 +0800
Subject: [PATCH] arm64/mm: remove useless trans_pgd_map_page()
Message-ID: <20210406131420.56262-1-kernelfans@gmail.com>

Since the commit 7018d467ff2d ("arm64: trans_pgd: hibernate: idmap the
single page that holds the copy page routines"), trans_pgd_map_page() is
useless.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: James Morse <james.morse at arm.com>
Cc: Matthias Brugger <mbrugger at suse.com>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/trans_pgd.h |  5 +--
 arch/arm64/mm/trans_pgd.c          | 57 ------------------------------
 2 files changed, 1 insertion(+), 61 deletions(-)

diff --git a/arch/arm64/include/asm/trans_pgd.h b/arch/arm64/include/asm/trans_pgd.h
index 5d08e5adf3d5..9b6858c032a5 100644
--- a/arch/arm64/include/asm/trans_pgd.h
+++ b/arch/arm64/include/asm/trans_pgd.h
@@ -15,7 +15,7 @@
 /*
  * trans_alloc_page
  *	- Allocator that should return exactly one zeroed page, if this
- *	  allocator fails, trans_pgd_create_copy() and trans_pgd_map_page()
+ *	  allocator fails, trans_pgd_create_copy() and trans_pgd_idmap_page()
  *	  return -ENOMEM error.
  *
  * trans_alloc_arg
@@ -30,9 +30,6 @@ struct trans_pgd_info {
 int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **trans_pgd,
 			  unsigned long start, unsigned long end);
 
-int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
-		       void *page, unsigned long dst_addr, pgprot_t pgprot);
-
 int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 			 unsigned long *t0sz, void *page);
 
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 527f0a39c3da..a1d936f9559f 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -217,63 +217,6 @@ int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **dst_pgdp,
 	return rc;
 }
 
-/*
- * Add map entry to trans_pgd for a base-size page at PTE level.
- * info:	contains allocator and its argument
- * trans_pgd:	page table in which new map is added.
- * page:	page to be mapped.
- * dst_addr:	new VA address for the page
- * pgprot:	protection for the page.
- *
- * Returns 0 on success, and -ENOMEM on failure.
- */
-int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
-		       void *page, unsigned long dst_addr, pgprot_t pgprot)
-{
-	pgd_t *pgdp;
-	p4d_t *p4dp;
-	pud_t *pudp;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	pgdp = pgd_offset_pgd(trans_pgd, dst_addr);
-	if (pgd_none(READ_ONCE(*pgdp))) {
-		p4dp = trans_alloc(info);
-		if (!pgdp)
-			return -ENOMEM;
-		pgd_populate(NULL, pgdp, p4dp);
-	}
-
-	p4dp = p4d_offset(pgdp, dst_addr);
-	if (p4d_none(READ_ONCE(*p4dp))) {
-		pudp = trans_alloc(info);
-		if (!pudp)
-			return -ENOMEM;
-		p4d_populate(NULL, p4dp, pudp);
-	}
-
-	pudp = pud_offset(p4dp, dst_addr);
-	if (pud_none(READ_ONCE(*pudp))) {
-		pmdp = trans_alloc(info);
-		if (!pmdp)
-			return -ENOMEM;
-		pud_populate(NULL, pudp, pmdp);
-	}
-
-	pmdp = pmd_offset(pudp, dst_addr);
-	if (pmd_none(READ_ONCE(*pmdp))) {
-		ptep = trans_alloc(info);
-		if (!ptep)
-			return -ENOMEM;
-		pmd_populate_kernel(NULL, pmdp, ptep);
-	}
-
-	ptep = pte_offset_kernel(pmdp, dst_addr);
-	set_pte(ptep, pfn_pte(virt_to_pfn(page), pgprot));
-
-	return 0;
-}
-
 /*
  * The page we want to idmap may be outside the range covered by VA_BITS that
  * can be built using the kernel's p?d_populate() helpers. As a one off, for a
-- 
2.29.2



From maz at kernel.org  Tue Apr  6 14:20:48 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue,  6 Apr 2021 14:20:48 +0100
Subject: [PATCH -next] KVM: arm64: Fix error return code in init_hyp_mode()
In-Reply-To: <20210406121759.5407-1-wangwensheng4@huawei.com>
References: <20210406121759.5407-1-wangwensheng4@huawei.com>
Message-ID: <161771524130.1078033.5622332810036336940.b4-ty@kernel.org>

On Tue, 6 Apr 2021 12:17:59 +0000, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.

Applied to kvm-arm64/misc-5.13, thanks!

[1/1] KVM: arm64: Fix error return code in init_hyp_mode()
      commit: 52b9e265d22bccc5843e167da76ab119874e2883

Cheers,

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




From andriy.shevchenko at intel.com  Tue Apr  6 14:22:04 2021
From: andriy.shevchenko at intel.com (Andy Shevchenko)
Date: Tue, 6 Apr 2021 16:22:04 +0300
Subject: [PATCH v29 0/6] JTAG driver introduction
In-Reply-To: <20210115104635.GA2971@home.paul.comp>
References: <20200413222920.4722-1-ernesto.corona@intel.com>
 <20210115104635.GA2971@home.paul.comp>
Message-ID: <YGxgfFBUr6eHJ1Qi@smile.fi.intel.com>

On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote:
> Hello,
> 
> This is a multi-part review of the series, with general notes inline
> in this message, and specific points raised as replies to the
> individual patches.
> 
> On Mon, Apr 13, 2020 at 03:29:14PM -0700, Ernesto Corona wrote:
> > We propose to implement general JTAG interface and infrastructure
> > to communicate with user layer application.
> 
> Working with a Tioga Pass server platform I needed to use the JTAG
> master controller of an ASPEED AST2500 SoC to configure a Lattice
> LCMXO2-4000HC CPLD. I'm mentioning these fine details because that's
> the only proper runtime testing I performed, but my review is not
> limited to that.
> 
> Being a long-time OpenOCD community member, I got familiar with many
> different facilities and protocols offered by hardware JTAG adapters,
> and of wide range of usecases as I was providing end-user
> support. This is my perspective when looking at these patches.
> 
> I have to note that the current v29 version of the series is broken in
> several aspects:

Is it correct that this series is actually abandoned so far?

> 1. The aspeed driver fails probe(), see the driver review for details;
> 
> 2. The uapi include header is unusable;
> 
> 3. The offered userspace implementation wasn't updated to the latest
> API, but even with the changes to make it compile it's still a mess
> too horrible to be used in production;
> 
> Points 1 and 2 will be addressed in separate mails. To workaround
> point 3 I prepared a recipe with an additional patch[0] so that
> mlnx_cpldprog can be at least compiled and used for some minimal
> testing.
> 
> The shortcomings of mlnx_cpldprog are numerous:
> 
> 1. It doesn't consistently choose between hardware and bitbang modes;
> 
> 2. Even though it checks TDO it doesn't print any errors on mismatch
> and continues playing back the SVF as if it's all right;
> 
> 3. It has JTAG speed hardcoded;
> 
> 4. It doesn't implement RUNTEST so with the CPLD I'm using it's always
> _not_ working properly, failing silently;
> 
> 5. It is just awfully slow, taking about 40 minutes to play back a
> file that takes 1.5 minutes with OpenOCD with the same hardware and
> kernel driver.
> 
> So I added support for the proposed API to OpenOCD: patch that applies
> to the version in OpenBMC[1], patch for the latest version[2]. And
> since it can do much more than just playing back SVF I hope this can
> highlight some essential API shortcomings if it's meant to be
> generic. My impression is that in its current state it's not adequate
> for the purpose.
> 
> [0] https://bitbucket.org/paulfertser/mlnx_cpldprog_bitbake
> [1] http://openocd.zylin.com/#/c/5976/
> [2] http://openocd.zylin.com/#/c/5975/

-- 
With Best Regards,
Andy Shevchenko




From roy.im.opensource at diasemi.com  Tue Apr  6 14:22:49 2021
From: roy.im.opensource at diasemi.com (Roy Im)
Date: Tue, 6 Apr 2021 13:22:49 +0000
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
Message-ID: <AM6SPR01MB04C9AC9A426F531B65A7E685769@AM6SPR01MB04.EURPRD10.PROD.OUTLOOK.COM>

On Tue, 06 Apr 2021, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote:
> Given that lowlevel drivers usually cannot implement exactly what a 
> consumer requests with pwm_apply_state() there is some
> rounding involved.
> 
> pwm_get_state() traditionally returned the setting that was requested 
> most recently by the consumer (opposed to what was
> actually implemented in hardware in reply to the last request).
> To make this semantic obvious rename the function.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/input/misc/da7280.c                |  2 +-

Acked-by: Roy Im <roy.im.opensource at diasemi.com>

From john.garry at huawei.com  Tue Apr  6 14:21:11 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 14:21:11 +0100
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <YGxaOnUZnNmDg/2P@krava>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava> <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
 <YGxRbH0XWaj6AWfa@krava> <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>
 <YGxaOnUZnNmDg/2P@krava>
Message-ID: <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>

On 06/04/2021 13:55, Jiri Olsa wrote:
>>>> So expr__find_other() may add a new item to pctx->ids, and we always iterate
>>>> again, and try to lookup any pmu_events, *, above. If none exist, then we
>>> hm, I don't see that.. so, what you do is:
>>>
>>> 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
>>>
>>> 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
>>> 	}
>>>
>>> and what I think we need to do is:
>>>
>>> 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
>>>
>>> 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
>>>
>>> 		break;	
>>> 	}
>>>
>>> each time you resolve another metric, you need to restart
>>> the pctx->ids iteration, because there will be new items,
>>> and we are in the middle of it
>> Sure, but we will restart anyway.
> hum, where? you call expr__find_other and continue to next
> pctx->ids item

We have:

resolve_metric_simple()
{
	bool all;

	do {
		all = true;

		hashmap__for_each_entry_safe(&pctx->ids, ...) {

			pe = metricgroup_find_metric(cur->key, map);
			if (!pe)
				continue;

			...
			all = false;

			expr_del_id(pctx, cur->key);

			...
			rc = expr__find_other(pe->metric_expr, pctx);
			if (rc)
				goto out_err;
		}

	} while (!all);

}

So once we evaluate a pmu_event in pctx->ids in @pe, @all is set false, 
and we would loop again in the do-while loop, regardless of what 
expr__find_other() does (apart from erroring), and so call 
hashmap__for_each_entry_safe(&pctx->ids, ) again.

This is really what is done in __resolve_metric() - indeed, I would use 
that function directly, but it looks hard to extract that from 
metricgroup.c .

Thanks,
John

> 
>> Regardless of this, I don't think what I am doing is safe, i.e. adding new
>> items in the middle of the iter, so I will change in the way you suggest.
> it'll always add items in the middle of the iteration



From robh at kernel.org  Tue Apr  6 14:24:05 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 06 Apr 2021 08:24:05 -0500
Subject: [PATCH V2 11/18] dt-bindings: i2c: imx-lpi2c: Add bus recovery
 example
In-Reply-To: <20210406113306.2633595-12-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
 <20210406113306.2633595-12-xiaoning.wang@nxp.com>
Message-ID: <1617715445.188566.1674501.nullmailer@robh.at.kernel.org>

On Tue, 06 Apr 2021 19:32:59 +0800, Clark Wang wrote:
> Add i2c bus recovery configuration example.
> 
> Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
> ---
> V2 changes:
>  - New patch added in V2
> ---
>  .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml     | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.example.dts:31.37-38 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:377: Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1414: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1462762

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From fercerpav at gmail.com  Tue Apr  6 14:34:20 2021
From: fercerpav at gmail.com (Paul Fertser)
Date: Tue, 6 Apr 2021 16:34:20 +0300
Subject: [PATCH v29 0/6] JTAG driver introduction
In-Reply-To: <YGxgfFBUr6eHJ1Qi@smile.fi.intel.com>
References: <20200413222920.4722-1-ernesto.corona@intel.com>
 <20210115104635.GA2971@home.paul.comp>
 <YGxgfFBUr6eHJ1Qi@smile.fi.intel.com>
Message-ID: <20210406133420.GY10267@home.paul.comp>

Hi Andy, 

On Tue, Apr 06, 2021 at 04:22:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote:
> > I have to note that the current v29 version of the series is broken in
> > several aspects:
> 
> Is it correct that this series is actually abandoned so far?

I have an e-mail from Ernesto sent on 10 Feb 2021 stating they're
going to continue the work.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com


From jolsa at redhat.com  Tue Apr  6 14:34:16 2021
From: jolsa at redhat.com (Jiri Olsa)
Date: Tue, 6 Apr 2021 15:34:16 +0200
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava>
 <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
 <YGxRbH0XWaj6AWfa@krava>
 <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>
 <YGxaOnUZnNmDg/2P@krava>
 <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>
Message-ID: <YGxjWNdZGqWqL87r@krava>

On Tue, Apr 06, 2021 at 02:21:11PM +0100, John Garry wrote:
> On 06/04/2021 13:55, Jiri Olsa wrote:
> > > > > So expr__find_other() may add a new item to pctx->ids, and we always iterate
> > > > > again, and try to lookup any pmu_events, *, above. If none exist, then we
> > > > hm, I don't see that.. so, what you do is:
> > > > 
> > > > 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> > > > 
> > > > 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > > > 	}
> > > > 
> > > > and what I think we need to do is:
> > > > 
> > > > 	hashmap__for_each_entry_safe((&pctx->ids) ....) {
> > > > 
> > > > 		rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
> > > > 
> > > > 		break;	
> > > > 	}
> > > > 
> > > > each time you resolve another metric, you need to restart
> > > > the pctx->ids iteration, because there will be new items,
> > > > and we are in the middle of it
> > > Sure, but we will restart anyway.
> > hum, where? you call expr__find_other and continue to next
> > pctx->ids item
> 
> We have:
> 
> resolve_metric_simple()
> {
> 	bool all;
> 
> 	do {
> 		all = true;
> 
> 		hashmap__for_each_entry_safe(&pctx->ids, ...) {
> 
> 			pe = metricgroup_find_metric(cur->key, map);
> 			if (!pe)
> 				continue;
> 
> 			...
> 			all = false;
> 
> 			expr_del_id(pctx, cur->key);
> 
> 			...
> 			rc = expr__find_other(pe->metric_expr, pctx);
> 			if (rc)
> 				goto out_err;
> 		}
> 
> 	} while (!all);
> 
> }
> 
> So once we evaluate a pmu_event in pctx->ids in @pe, @all is set false, and
> we would loop again in the do-while loop, regardless of what
> expr__find_other() does (apart from erroring), and so call
> hashmap__for_each_entry_safe(&pctx->ids, ) again.

ah ok, so it finishes the hash iteration first and
then restarts it.. ok, I missed that, then it's fine

> 
> This is really what is done in __resolve_metric() - indeed, I would use that
> function directly, but it looks hard to extract that from metricgroup.c .

yea, it's another world ;-) it's better to keep it separated

thanks,
jirka

> 
> Thanks,
> John
> 
> > 
> > > Regardless of this, I don't think what I am doing is safe, i.e. adding new
> > > items in the middle of the iter, so I will change in the way you suggest.
> > it'll always add items in the middle of the iteration
> 



From john.garry at huawei.com  Tue Apr  6 14:38:27 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 6 Apr 2021 14:38:27 +0100
Subject: [PATCH v2 2/6] perf test: Handle metric reuse in pmu-events
 parsing test
In-Reply-To: <YGxjWNdZGqWqL87r@krava>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-3-git-send-email-john.garry@huawei.com>
 <YGXPdEAecos4iPVc@krava> <edfabc52-4b09-be92-7c40-fb2ddfe80596@huawei.com>
 <YGxRbH0XWaj6AWfa@krava> <f5b209b2-1e9e-ebad-b2ed-eda9fe858ec8@huawei.com>
 <YGxaOnUZnNmDg/2P@krava> <49025439-f9e3-0d32-b0a3-ff9f9ff71835@huawei.com>
 <YGxjWNdZGqWqL87r@krava>
Message-ID: <6bb503e4-8d75-62a6-3c10-8478df9c3e44@huawei.com>

On 06/04/2021 14:34, Jiri Olsa wrote:
>>
>> }
>>
>> So once we evaluate a pmu_event in pctx->ids in @pe, @all is set false, and
>> we would loop again in the do-while loop, regardless of what
>> expr__find_other() does (apart from erroring), and so call
>> hashmap__for_each_entry_safe(&pctx->ids, ) again.
> ah ok, so it finishes the hash iteration first and
> then restarts it.. ok, I missed that, then it's fine
>  >> This is really what is done in __resolve_metric() - indeed, I would 
use that
>> function directly, but it looks hard to extract that from metricgroup.c .
> yea, it's another world;-)  it's better to keep it separated

ok, so I'll still add the break statement, as suggested.

I'll also wait to see if Ian or you have a strong feeling about the 
function naming in patch 1/6.

Thanks,
John



From matthias.bgg at gmail.com  Tue Apr  6 14:41:40 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 15:41:40 +0200
Subject: [PATCH v2 2/6] soc: mediatek: devapc: move 'vio_idx_num' info to
 DT
In-Reply-To: <1617259087-5502-2-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-2-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <39794302-7993-4f9c-b28c-577fdb0265a3@gmail.com>



On 01/04/2021 08:38, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> For new ICs, there are multiple devapc HWs for different subsys.
> The number of devices controlled by each devapc (i.e. 'vio_idx_num'
> in the code) varies.
> We move this info from compatible data to DT so that we do not need
> to add n compatible for a certain IC which has n devapc HWs with
> different 'vio_idx_num', respectively.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---
>  drivers/soc/mediatek/mtk-devapc.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> index f1cea04..a0f6fbd 100644
> --- a/drivers/soc/mediatek/mtk-devapc.c
> +++ b/drivers/soc/mediatek/mtk-devapc.c
> @@ -32,9 +32,6 @@ struct mtk_devapc_vio_dbgs {
>  };
>  
>  struct mtk_devapc_data {
> -	/* numbers of violation index */
> -	u32 vio_idx_num;
> -
>  	/* reg offset */
>  	u32 vio_mask_offset;
>  	u32 vio_sta_offset;
> @@ -49,6 +46,7 @@ struct mtk_devapc_data {
>  struct mtk_devapc_context {
>  	struct device *dev;
>  	void __iomem *infra_base;
> +	u32 vio_idx_num;

We should try to stay backwards compatible (newer kernel with older DTS). I
think we don't need to move vio_idx_num to mtk_devapc_context. Just don't
declare it in the per SoC match data. More details see below...

>  	struct clk *infra_clk;
>  	const struct mtk_devapc_data *data;
>  };
> @@ -60,10 +58,10 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
>  
>  	reg = ctx->infra_base + ctx->data->vio_sta_offset;
>  
> -	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> +	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
>  		writel(GENMASK(31, 0), reg + 4 * i);
>  
> -	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
> +	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1), 0),
>  	       reg + 4 * i);
>  }
>  
> @@ -80,15 +78,15 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
>  	else
>  		val = 0;
>  
> -	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> +	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
>  		writel(val, reg + 4 * i);
>  
>  	val = readl(reg + 4 * i);
>  	if (mask)
> -		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> +		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
>  			       0);
>  	else
> -		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> +		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
>  				0);
>  
>  	writel(val, reg + 4 * i);
> @@ -216,7 +214,6 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
>  }
>  
>  static const struct mtk_devapc_data devapc_mt6779 = {
> -	.vio_idx_num = 511,
>  	.vio_mask_offset = 0x0,
>  	.vio_sta_offset = 0x400,
>  	.vio_dbg0_offset = 0x900,
> @@ -256,6 +253,9 @@ static int mtk_devapc_probe(struct platform_device *pdev)
>  	if (!ctx->infra_base)
>  		return -EINVAL;
>  
> +	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
> +		return -EINVAL;
> +

...only read the property if  vio_idx_num == 0.
What do you think?

Regards,
Matthias

>  	devapc_irq = irq_of_parse_and_map(node, 0);
>  	if (!devapc_irq)
>  		return -EINVAL;
> 


From linux at roeck-us.net  Tue Apr  6 14:42:51 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 6 Apr 2021 06:42:51 -0700
Subject: [PATCH v2 07/10] watchdog: npcm: Add support for WPCM450
In-Reply-To: <20210406120921.2484986-8-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <20210406120921.2484986-8-j.neuschaefer@gmx.net>
Message-ID: <6b305447-4873-9bbc-1118-02310919e968@roeck-us.net>

On 4/6/21 5:09 AM, Jonathan Neusch?fer wrote:
> Add a compatible string for WPCM450, which has essentially the same
> watchdog mechanism as NPCM750.
> 
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>

Acked-by: Guenter Roeck <linux at roeck-us.net>

> ---
> 
> v2:
> - Added patch description
> ---
>  drivers/watchdog/npcm_wdt.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
> index 765577f11c8db..28a24caa2627c 100644
> --- a/drivers/watchdog/npcm_wdt.c
> +++ b/drivers/watchdog/npcm_wdt.c
> @@ -229,6 +229,7 @@ static int npcm_wdt_probe(struct platform_device *pdev)
> 
>  #ifdef CONFIG_OF
>  static const struct of_device_id npcm_wdt_match[] = {
> +	{.compatible = "nuvoton,wpcm450-wdt"},
>  	{.compatible = "nuvoton,npcm750-wdt"},
>  	{},
>  };
> --
> 2.30.2
> 



From matthias.bgg at gmail.com  Tue Apr  6 14:43:17 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 15:43:17 +0200
Subject: [PATCH v2 4/6] soc: mediatek: devapc: rename variable for new IC
 support
In-Reply-To: <1617259087-5502-4-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-4-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <a76686d1-3544-fcb9-4c3e-1498ec29ff47@gmail.com>

Regarding the commit subject:
"soc: mediatek: devapc: rename variable for new IC support"
maybe something like:
"soc: mediatek: devapc: rename register variable infra_base"

Other then that looks good to me.

On 01/04/2021 08:38, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> For new ICs, there are multiple devapc HWs for different subsys.
> For example, there is devapc respectively for infra, peri, peri2, etc.
> So we rename the variable 'infra_base' to 'base' for code readability.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---
>  drivers/soc/mediatek/mtk-devapc.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> index 68c3e35..bcf6e3c 100644
> --- a/drivers/soc/mediatek/mtk-devapc.c
> +++ b/drivers/soc/mediatek/mtk-devapc.c
> @@ -45,7 +45,7 @@ struct mtk_devapc_data {
>  
>  struct mtk_devapc_context {
>  	struct device *dev;
> -	void __iomem *infra_base;
> +	void __iomem *base;
>  	u32 vio_idx_num;
>  	struct clk *infra_clk;
>  	const struct mtk_devapc_data *data;
> @@ -56,7 +56,7 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
>  	void __iomem *reg;
>  	int i;
>  
> -	reg = ctx->infra_base + ctx->data->vio_sta_offset;
> +	reg = ctx->base + ctx->data->vio_sta_offset;
>  
>  	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
>  		writel(GENMASK(31, 0), reg + 4 * i);
> @@ -71,7 +71,7 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
>  	u32 val;
>  	int i;
>  
> -	reg = ctx->infra_base + ctx->data->vio_mask_offset;
> +	reg = ctx->base + ctx->data->vio_mask_offset;
>  
>  	if (mask)
>  		val = GENMASK(31, 0);
> @@ -113,11 +113,11 @@ static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
>  	int ret;
>  	u32 val;
>  
> -	pd_vio_shift_sta_reg = ctx->infra_base +
> +	pd_vio_shift_sta_reg = ctx->base +
>  			       ctx->data->vio_shift_sta_offset;
> -	pd_vio_shift_sel_reg = ctx->infra_base +
> +	pd_vio_shift_sel_reg = ctx->base +
>  			       ctx->data->vio_shift_sel_offset;
> -	pd_vio_shift_con_reg = ctx->infra_base +
> +	pd_vio_shift_con_reg = ctx->base +
>  			       ctx->data->vio_shift_con_offset;
>  
>  	/* Find the minimum shift group which has violation */
> @@ -159,8 +159,8 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
>  	void __iomem *vio_dbg0_reg;
>  	void __iomem *vio_dbg1_reg;
>  
> -	vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset;
> -	vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset;
> +	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> +	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
>  
>  	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
>  	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> @@ -198,7 +198,7 @@ static irqreturn_t devapc_violation_irq(int irq_number, void *data)
>   */
>  static void start_devapc(struct mtk_devapc_context *ctx)
>  {
> -	writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset);
> +	writel(BIT(31), ctx->base + ctx->data->apc_con_offset);
>  
>  	mask_module_irq(ctx, false);
>  }
> @@ -210,7 +210,7 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
>  {
>  	mask_module_irq(ctx, true);
>  
> -	writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset);
> +	writel(BIT(2), ctx->base + ctx->data->apc_con_offset);
>  }
>  
>  static const struct mtk_devapc_data devapc_mt6779 = {
> @@ -249,8 +249,8 @@ static int mtk_devapc_probe(struct platform_device *pdev)
>  	ctx->data = of_device_get_match_data(&pdev->dev);
>  	ctx->dev = &pdev->dev;
>  
> -	ctx->infra_base = of_iomap(node, 0);
> -	if (!ctx->infra_base)
> +	ctx->base = of_iomap(node, 0);
> +	if (!ctx->base)
>  		return -EINVAL;
>  
>  	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
> 


From u.kleine-koenig at pengutronix.de  Tue Apr  6 14:43:56 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Tue, 6 Apr 2021 15:43:56 +0200
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <YGxDD4jVZx/H/Zdr@orome.fritz.box>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
 <YGxDD4jVZx/H/Zdr@orome.fritz.box>
Message-ID: <20210406134356.dda74heeshkwdarw@pengutronix.de>

Hello Thierry,

On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-K?nig wrote:
> > Given that lowlevel drivers usually cannot implement exactly what a
> > consumer requests with pwm_apply_state() there is some rounding involved.
> > 
> > pwm_get_state() traditionally returned the setting that was requested most
> > recently by the consumer (opposed to what was actually implemented in
> > hardware in reply to the last request). To make this semantic obvious
> > rename the function.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > ---
> >  Documentation/driver-api/pwm.rst           |  6 +++-
> >  drivers/clk/clk-pwm.c                      |  2 +-
> >  drivers/gpu/drm/i915/display/intel_panel.c |  4 +--
> >  drivers/input/misc/da7280.c                |  2 +-
> >  drivers/input/misc/pwm-beeper.c            |  2 +-
> >  drivers/input/misc/pwm-vibra.c             |  4 +--
> >  drivers/pwm/core.c                         |  4 +--
> >  drivers/pwm/pwm-atmel-hlcdc.c              |  2 +-
> >  drivers/pwm/pwm-atmel.c                    |  2 +-
> >  drivers/pwm/pwm-imx27.c                    |  2 +-
> >  drivers/pwm/pwm-rockchip.c                 |  2 +-
> >  drivers/pwm/pwm-stm32-lp.c                 |  4 +--
> >  drivers/pwm/pwm-sun4i.c                    |  2 +-
> >  drivers/pwm/sysfs.c                        | 18 ++++++------
> >  drivers/regulator/pwm-regulator.c          |  4 +--
> >  drivers/video/backlight/pwm_bl.c           | 10 +++----
> >  include/linux/pwm.h                        | 34 ++++++++++++++--------
> >  17 files changed, 59 insertions(+), 45 deletions(-)
> 
> Honestly, I don't think this is worth the churn. If you think people
> will easily get confused by this then a better solution might be to more
> explicitly document the pwm_get_state() function to say exactly what it
> returns.

I'm not so optimistic that people become aware of the semantic just
because there is documentation describing it and I strongly believe that
a good name for functions is more important than accurate documentation.

If you don't agree, what do you think about the updated wording in
Documentation/driver-api/pwm.rst?

> But there's no need to make life difficult for everyone by
> renaming this to something as cumbersome as this.

I don't expect any merge conflicts (and if still a problem occurs
resolving should be trivial enough). So I obviously don't agree to your
weighing.

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/20210406/adf1022d/attachment.sig>

From matthias.bgg at gmail.com  Tue Apr  6 14:53:16 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 15:53:16 +0200
Subject: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for new
 IC support
In-Reply-To: <1617259087-5502-5-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-5-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>



On 01/04/2021 08:38, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> There are 3 debug info registers in new ICs while in legacy ones,
> we have only 2. When dumping the debug info, we need to check first
> if the 3rd debug register exists and then we can konw how to decipher
> the debug info.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---
>  drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> index bcf6e3c..af55c01 100644
> --- a/drivers/soc/mediatek/mtk-devapc.c
> +++ b/drivers/soc/mediatek/mtk-devapc.c
> @@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
>  			u32 addr_h:4;
>  			u32 resv:4;
>  		} dbg0_bits;
> +
> +		/* Not used, reference only */
> +		struct {
> +			u32 dmnid:6;
> +			u32 vio_w:1;
> +			u32 vio_r:1;
> +			u32 addr_h:4;
> +			u32 resv:20;
> +		} dbg0_bits_ver2;
>  	};
>  
>  	u32 vio_dbg1;
> +	u32 vio_dbg2;
>  };
>  
>  struct mtk_devapc_data {
> @@ -37,6 +47,7 @@ struct mtk_devapc_data {
>  	u32 vio_sta_offset;
>  	u32 vio_dbg0_offset;
>  	u32 vio_dbg1_offset;
> +	u32 vio_dbg2_offset;
>  	u32 apc_con_offset;
>  	u32 vio_shift_sta_offset;
>  	u32 vio_shift_sel_offset;
> @@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
>  	struct mtk_devapc_vio_dbgs vio_dbgs;
>  	void __iomem *vio_dbg0_reg;
>  	void __iomem *vio_dbg1_reg;
> +	void __iomem *vio_dbg2_reg;
> +	u32 vio_addr, bus_id;
>  
>  	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
>  	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> +	vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;

We should read this only if we have version2 of the devapc.

>  
>  	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
>  	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> +	vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
> +
> +	if (!ctx->data->vio_dbg2_offset) {

I think we should add a version field to mtk_devapc_data to distinguish the two
of them.

> +		/* arch version 1 */
> +		bus_id = vio_dbgs.dbg0_bits.mstid;
> +		vio_addr = vio_dbgs.vio_dbg1;
> +	} else {
> +		/* arch version 2 */
> +		bus_id = vio_dbgs.vio_dbg1;
> +		vio_addr = vio_dbgs.vio_dbg2;
> +
> +		/* To align with the bit definition of arch_ver 1 */
> +		vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);

That's magic, better add another variable domain_id and do here:
domain_id = vio_dgbs.dbg0_bits_ver2.dmnid;

> +	}
>  
>  	/* Print violation information */
>  	if (vio_dbgs.dbg0_bits.vio_w)
> @@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
>  		dev_info(ctx->dev, "Read Violation\n");
>  
>  	dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
> -		 vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
> -		 vio_dbgs.vio_dbg1);
> +		 bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
>  }
>  
>  /*
> 


From matthias.bgg at gmail.com  Tue Apr  6 14:55:17 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 15:55:17 +0200
Subject: [PATCH v2 6/6] soc: mediatek: devapc: support mt8192
In-Reply-To: <1617259087-5502-6-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-6-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <f52189e3-26b2-fd44-7059-f3bf0f79fbae@gmail.com>



On 01/04/2021 08:38, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> Add compatible to support mt8192.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---


Looks good, I'd like to see DTS for this as well, although I understand it
depends on the clock patch series. Please note so in either below the '---' or
in a cover letter.

Regards,
Matthias


>  drivers/soc/mediatek/mtk-devapc.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> index af55c01..a5c15b5 100644
> --- a/drivers/soc/mediatek/mtk-devapc.c
> +++ b/drivers/soc/mediatek/mtk-devapc.c
> @@ -251,11 +251,26 @@ static const struct mtk_devapc_data devapc_mt6779 = {
>  	.vio_shift_con_offset = 0xF20,
>  };
>  
> +static const struct mtk_devapc_data devapc_mt8192 = {
> +	.vio_mask_offset = 0x0,
> +	.vio_sta_offset = 0x400,
> +	.vio_dbg0_offset = 0x900,
> +	.vio_dbg1_offset = 0x904,
> +	.vio_dbg2_offset = 0x908,
> +	.apc_con_offset = 0xF00,
> +	.vio_shift_sta_offset = 0xF20,
> +	.vio_shift_sel_offset = 0xF30,
> +	.vio_shift_con_offset = 0xF10,
> +};
> +
>  static const struct of_device_id mtk_devapc_dt_match[] = {
>  	{
>  		.compatible = "mediatek,mt6779-devapc",
>  		.data = &devapc_mt6779,
>  	}, {
> +		.compatible = "mediatek,mt8192-devapc",
> +		.data = &devapc_mt8192,
> +	}, {
>  	},
>  };
>  
> 


From matthias.bgg at gmail.com  Tue Apr  6 15:01:03 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 16:01:03 +0200
Subject: [PATCH v8 2/4] soc: mediatek: add MT6765 scpsys and subdomain
 support
In-Reply-To: <1582279929-11535-3-git-send-email-macpaul.lin@mediatek.com>
References: <1582279929-11535-1-git-send-email-macpaul.lin@mediatek.com>
 <1582279929-11535-3-git-send-email-macpaul.lin@mediatek.com>
Message-ID: <c9cefb0b-2394-e48c-f140-3dab55af2369@gmail.com>



On 21/02/2020 11:12, Macpaul Lin wrote:
> From: Mars Cheng <mars.cheng at mediatek.com>
> 
> This adds scpsys support for MT6765
> Add subdomain support for MT6765:
> isp, mm, connsys, mfg, and cam.
> 
> Signed-off-by: Mars Cheng <mars.cheng at mediatek.com>
> Signed-off-by: Owen Chen <owen.chen at mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin at mediatek.com>
> ---
>  drivers/soc/mediatek/mtk-scpsys.c |  130 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 130 insertions(+)
> 

Unfortunately scpsys is deprecated in the meantime. Please port you patches to
the new mtk-pm-domains.c driver. The biggest difference is, that the domain and
subdomain structure of the pm domains is describe in device tree instead of
hard-coded in the driver.

Regards,
Matthias

> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> index f669d37..9940c6d 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -15,6 +15,7 @@
>  
>  #include <dt-bindings/power/mt2701-power.h>
>  #include <dt-bindings/power/mt2712-power.h>
> +#include <dt-bindings/power/mt6765-power.h>
>  #include <dt-bindings/power/mt6797-power.h>
>  #include <dt-bindings/power/mt7622-power.h>
>  #include <dt-bindings/power/mt7623a-power.h>
> @@ -750,6 +751,120 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>  };
>  
>  /*
> + * MT6765 power domain support
> + */
> +#define SPM_PWR_STATUS_MT6765			0x0180
> +#define SPM_PWR_STATUS_2ND_MT6765		0x0184
> +
> +static const struct scp_domain_data scp_domain_data_mt6765[] = {
> +	[MT6765_POWER_DOMAIN_VCODEC] = {
> +		.name = "vcodec",
> +		.sta_mask = BIT(26),
> +		.ctl_offs = 0x300,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +	[MT6765_POWER_DOMAIN_ISP] = {
> +		.name = "isp",
> +		.sta_mask = BIT(5),
> +		.ctl_offs = 0x308,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.subsys_clk_prefix = "isp",
> +		.bp_table = {
> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
> +				BIT(20), BIT(20)),
> +			BUS_PROT(SMI_TYPE, 0x3C4, 0x3C8, 0, 0x3C0,
> +				BIT(2), BIT(2)),
> +		},
> +	},
> +	[MT6765_POWER_DOMAIN_MM] = {
> +		.name = "mm",
> +		.sta_mask = BIT(3),
> +		.ctl_offs = 0x30C,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.basic_clk_id = {"mm"},
> +		.subsys_clk_prefix = "mm",
> +		.bp_table = {
> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
> +				BIT(16) | BIT(17), BIT(16) | BIT(17)),
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(10) | BIT(11), BIT(10) | BIT(11)),
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(1) | BIT(2), BIT(1) | BIT(2)),
> +		},
> +	},
> +	[MT6765_POWER_DOMAIN_CONN] = {
> +		.name = "conn",
> +		.sta_mask = BIT(1),
> +		.ctl_offs = 0x32C,
> +		.sram_pdn_bits = 0,
> +		.sram_pdn_ack_bits = 0,
> +		.bp_table = {
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(13), BIT(13)),
> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
> +				BIT(18), BIT(18)),
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(14) | BIT(16), BIT(14) | BIT(16)),
> +		},
> +	},
> +	[MT6765_POWER_DOMAIN_MFG_ASYNC] = {
> +		.name = "mfg_async",
> +		.sta_mask = BIT(23),
> +		.ctl_offs = 0x334,
> +		.sram_pdn_bits = 0,
> +		.sram_pdn_ack_bits = 0,
> +		.basic_clk_id = {"mfg"},
> +	},
> +	[MT6765_POWER_DOMAIN_MFG] = {
> +		.name = "mfg",
> +		.sta_mask = BIT(4),
> +		.ctl_offs = 0x338,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +		.bp_table = {
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(25), BIT(25)),
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(21) | BIT(22), BIT(21) | BIT(22)),
> +		}
> +	},
> +	[MT6765_POWER_DOMAIN_CAM] = {
> +		.name = "cam",
> +		.sta_mask = BIT(25),
> +		.ctl_offs = 0x344,
> +		.sram_pdn_bits = GENMASK(8, 9),
> +		.sram_pdn_ack_bits = GENMASK(12, 13),
> +		.subsys_clk_prefix = "cam",
> +		.bp_table = {
> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
> +				BIT(19) | BIT(21), BIT(19) | BIT(21)),
> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
> +				BIT(20), BIT(20)),
> +			BUS_PROT(SMI_TYPE, 0x3C4, 0x3C8, 0, 0x3C0,
> +				BIT(3), BIT(3)),
> +		}
> +	},
> +	[MT6765_POWER_DOMAIN_MFG_CORE0] = {
> +		.name = "mfg_core0",
> +		.sta_mask = BIT(7),
> +		.ctl_offs = 0x34C,
> +		.sram_pdn_bits = GENMASK(8, 8),
> +		.sram_pdn_ack_bits = GENMASK(12, 12),
> +	},
> +};
> +
> +static const struct scp_subdomain scp_subdomain_mt6765[] = {
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_CAM},
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_ISP},
> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_VCODEC},
> +	{MT6765_POWER_DOMAIN_MFG_ASYNC, MT6765_POWER_DOMAIN_MFG},
> +	{MT6765_POWER_DOMAIN_MFG, MT6765_POWER_DOMAIN_MFG_CORE0},
> +};
> +
> +/*
>   * MT6797 power domain support
>   */
>  
> @@ -1032,6 +1147,18 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>  	.bus_prot_reg_update = false,
>  };
>  
> +static const struct scp_soc_data mt6765_data = {
> +	.domains = scp_domain_data_mt6765,
> +	.num_domains = ARRAY_SIZE(scp_domain_data_mt6765),
> +	.subdomains = scp_subdomain_mt6765,
> +	.num_subdomains = ARRAY_SIZE(scp_subdomain_mt6765),
> +	.regs = {
> +		.pwr_sta_offs = SPM_PWR_STATUS_MT6765,
> +		.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6765,
> +	},
> +	.bus_prot_reg_update = true,
> +};
> +
>  static const struct scp_soc_data mt6797_data = {
>  	.domains = scp_domain_data_mt6797,
>  	.num_domains = ARRAY_SIZE(scp_domain_data_mt6797),
> @@ -1088,6 +1215,9 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>  		.compatible = "mediatek,mt2712-scpsys",
>  		.data = &mt2712_data,
>  	}, {
> +		.compatible = "mediatek,mt6765-scpsys",
> +		.data = &mt6765_data,
> +	}, {
>  		.compatible = "mediatek,mt6797-scpsys",
>  		.data = &mt6797_data,
>  	}, {
> 


From matthias.bgg at gmail.com  Tue Apr  6 15:04:32 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 16:04:32 +0200
Subject: [PATCH v8 2/4] soc: mediatek: add MT6765 scpsys and subdomain
 support
In-Reply-To: <c9cefb0b-2394-e48c-f140-3dab55af2369@gmail.com>
References: <1582279929-11535-1-git-send-email-macpaul.lin@mediatek.com>
 <1582279929-11535-3-git-send-email-macpaul.lin@mediatek.com>
 <c9cefb0b-2394-e48c-f140-3dab55af2369@gmail.com>
Message-ID: <116b6067-fc75-b0cd-2da0-900cfdcacb02@gmail.com>

On 06/04/2021 16:01, Matthias Brugger wrote:
> 
> 
> On 21/02/2020 11:12, Macpaul Lin wrote:
>> From: Mars Cheng <mars.cheng at mediatek.com>
>>
>> This adds scpsys support for MT6765
>> Add subdomain support for MT6765:
>> isp, mm, connsys, mfg, and cam.
>>
>> Signed-off-by: Mars Cheng <mars.cheng at mediatek.com>
>> Signed-off-by: Owen Chen <owen.chen at mediatek.com>
>> Signed-off-by: Macpaul Lin <macpaul.lin at mediatek.com>
>> ---
>>  drivers/soc/mediatek/mtk-scpsys.c |  130 +++++++++++++++++++++++++++++++++++++
>>  1 file changed, 130 insertions(+)
>>
> 
> Unfortunately scpsys is deprecated in the meantime. Please port you patches to
> the new mtk-pm-domains.c driver. The biggest difference is, that the domain and
> subdomain structure of the pm domains is describe in device tree instead of
> hard-coded in the driver.
> 

I got confused by the email grouping in my mail client. I already gave the same
feedback in v10 :)

> Regards,
> Matthias
> 
>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>> index f669d37..9940c6d 100644
>> --- a/drivers/soc/mediatek/mtk-scpsys.c
>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
>> @@ -15,6 +15,7 @@
>>  
>>  #include <dt-bindings/power/mt2701-power.h>
>>  #include <dt-bindings/power/mt2712-power.h>
>> +#include <dt-bindings/power/mt6765-power.h>
>>  #include <dt-bindings/power/mt6797-power.h>
>>  #include <dt-bindings/power/mt7622-power.h>
>>  #include <dt-bindings/power/mt7623a-power.h>
>> @@ -750,6 +751,120 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>>  };
>>  
>>  /*
>> + * MT6765 power domain support
>> + */
>> +#define SPM_PWR_STATUS_MT6765			0x0180
>> +#define SPM_PWR_STATUS_2ND_MT6765		0x0184
>> +
>> +static const struct scp_domain_data scp_domain_data_mt6765[] = {
>> +	[MT6765_POWER_DOMAIN_VCODEC] = {
>> +		.name = "vcodec",
>> +		.sta_mask = BIT(26),
>> +		.ctl_offs = 0x300,
>> +		.sram_pdn_bits = GENMASK(8, 8),
>> +		.sram_pdn_ack_bits = GENMASK(12, 12),
>> +	},
>> +	[MT6765_POWER_DOMAIN_ISP] = {
>> +		.name = "isp",
>> +		.sta_mask = BIT(5),
>> +		.ctl_offs = 0x308,
>> +		.sram_pdn_bits = GENMASK(8, 8),
>> +		.sram_pdn_ack_bits = GENMASK(12, 12),
>> +		.subsys_clk_prefix = "isp",
>> +		.bp_table = {
>> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
>> +				BIT(20), BIT(20)),
>> +			BUS_PROT(SMI_TYPE, 0x3C4, 0x3C8, 0, 0x3C0,
>> +				BIT(2), BIT(2)),
>> +		},
>> +	},
>> +	[MT6765_POWER_DOMAIN_MM] = {
>> +		.name = "mm",
>> +		.sta_mask = BIT(3),
>> +		.ctl_offs = 0x30C,
>> +		.sram_pdn_bits = GENMASK(8, 8),
>> +		.sram_pdn_ack_bits = GENMASK(12, 12),
>> +		.basic_clk_id = {"mm"},
>> +		.subsys_clk_prefix = "mm",
>> +		.bp_table = {
>> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
>> +				BIT(16) | BIT(17), BIT(16) | BIT(17)),
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(10) | BIT(11), BIT(10) | BIT(11)),
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(1) | BIT(2), BIT(1) | BIT(2)),
>> +		},
>> +	},
>> +	[MT6765_POWER_DOMAIN_CONN] = {
>> +		.name = "conn",
>> +		.sta_mask = BIT(1),
>> +		.ctl_offs = 0x32C,
>> +		.sram_pdn_bits = 0,
>> +		.sram_pdn_ack_bits = 0,
>> +		.bp_table = {
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(13), BIT(13)),
>> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
>> +				BIT(18), BIT(18)),
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(14) | BIT(16), BIT(14) | BIT(16)),
>> +		},
>> +	},
>> +	[MT6765_POWER_DOMAIN_MFG_ASYNC] = {
>> +		.name = "mfg_async",
>> +		.sta_mask = BIT(23),
>> +		.ctl_offs = 0x334,
>> +		.sram_pdn_bits = 0,
>> +		.sram_pdn_ack_bits = 0,
>> +		.basic_clk_id = {"mfg"},
>> +	},
>> +	[MT6765_POWER_DOMAIN_MFG] = {
>> +		.name = "mfg",
>> +		.sta_mask = BIT(4),
>> +		.ctl_offs = 0x338,
>> +		.sram_pdn_bits = GENMASK(8, 8),
>> +		.sram_pdn_ack_bits = GENMASK(12, 12),
>> +		.bp_table = {
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(25), BIT(25)),
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(21) | BIT(22), BIT(21) | BIT(22)),
>> +		}
>> +	},
>> +	[MT6765_POWER_DOMAIN_CAM] = {
>> +		.name = "cam",
>> +		.sta_mask = BIT(25),
>> +		.ctl_offs = 0x344,
>> +		.sram_pdn_bits = GENMASK(8, 9),
>> +		.sram_pdn_ack_bits = GENMASK(12, 13),
>> +		.subsys_clk_prefix = "cam",
>> +		.bp_table = {
>> +			BUS_PROT(IFR_TYPE, 0x2A8, 0x2AC, 0, 0x258,
>> +				BIT(19) | BIT(21), BIT(19) | BIT(21)),
>> +			BUS_PROT(IFR_TYPE, 0x2A0, 0x2A4, 0, 0x228,
>> +				BIT(20), BIT(20)),
>> +			BUS_PROT(SMI_TYPE, 0x3C4, 0x3C8, 0, 0x3C0,
>> +				BIT(3), BIT(3)),
>> +		}
>> +	},
>> +	[MT6765_POWER_DOMAIN_MFG_CORE0] = {
>> +		.name = "mfg_core0",
>> +		.sta_mask = BIT(7),
>> +		.ctl_offs = 0x34C,
>> +		.sram_pdn_bits = GENMASK(8, 8),
>> +		.sram_pdn_ack_bits = GENMASK(12, 12),
>> +	},
>> +};
>> +
>> +static const struct scp_subdomain scp_subdomain_mt6765[] = {
>> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_CAM},
>> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_ISP},
>> +	{MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_VCODEC},
>> +	{MT6765_POWER_DOMAIN_MFG_ASYNC, MT6765_POWER_DOMAIN_MFG},
>> +	{MT6765_POWER_DOMAIN_MFG, MT6765_POWER_DOMAIN_MFG_CORE0},
>> +};
>> +
>> +/*
>>   * MT6797 power domain support
>>   */
>>  
>> @@ -1032,6 +1147,18 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>>  	.bus_prot_reg_update = false,
>>  };
>>  
>> +static const struct scp_soc_data mt6765_data = {
>> +	.domains = scp_domain_data_mt6765,
>> +	.num_domains = ARRAY_SIZE(scp_domain_data_mt6765),
>> +	.subdomains = scp_subdomain_mt6765,
>> +	.num_subdomains = ARRAY_SIZE(scp_subdomain_mt6765),
>> +	.regs = {
>> +		.pwr_sta_offs = SPM_PWR_STATUS_MT6765,
>> +		.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6765,
>> +	},
>> +	.bus_prot_reg_update = true,
>> +};
>> +
>>  static const struct scp_soc_data mt6797_data = {
>>  	.domains = scp_domain_data_mt6797,
>>  	.num_domains = ARRAY_SIZE(scp_domain_data_mt6797),
>> @@ -1088,6 +1215,9 @@ static void mtk_register_power_domains(struct platform_device *pdev,
>>  		.compatible = "mediatek,mt2712-scpsys",
>>  		.data = &mt2712_data,
>>  	}, {
>> +		.compatible = "mediatek,mt6765-scpsys",
>> +		.data = &mt6765_data,
>> +	}, {
>>  		.compatible = "mediatek,mt6797-scpsys",
>>  		.data = &mt6797_data,
>>  	}, {
>>



From matthias.bgg at gmail.com  Tue Apr  6 15:11:39 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 6 Apr 2021 16:11:39 +0200
Subject: [PATCH 1/2] dt-bindings: mediatek: mmsys: add mt1867 binding
In-Reply-To: <CAAOTY_8LwVDxZnSQAdK7mS8MAFZ1y_0EnSzj3UqeCxq-Tc5FuQ@mail.gmail.com>
References: <20201027160631.608503-1-fparent@baylibre.com>
 <20201030191714.GA4171611@bogus>
 <CAAOTY_8LwVDxZnSQAdK7mS8MAFZ1y_0EnSzj3UqeCxq-Tc5FuQ@mail.gmail.com>
Message-ID: <0038ac16-4ffe-b141-a417-3639857a2998@gmail.com>

Hi Chun-Kuang,

On 10/01/2021 00:17, Chun-Kuang Hu wrote:
> Hi, Matthias:
> 
> Rob Herring <robh at kernel.org> ? 2020?10?31? ?? ??3:17???
>>
>> On Tue, 27 Oct 2020 17:06:29 +0100, Fabien Parent wrote:
>>> Add binding documentation for MT8167 SoC.
> 
> Even though the title need to change to 'mt8167', this patch looks
> good to me. How do you think about this patch? One drm patch [1]
> depend on this patch, if you like this patch, could you applied this
> patch first?
> 
> [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20201023133130.194140-6-fparent at baylibre.com/
> 

I just pushed the latest version [1] of this to v5.12-next/soc-2

I'll try to get this in for v5.13, if not possible we can sync again on how to
fix this.

Regards,
Matthias

[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20210405200354.2194930-1-fparent at baylibre.com/

> Regards,
> Chun-Kuang.
> 
>>>
>>> Signed-off-by: Fabien Parent <fparent at baylibre.com>
>>> ---
>>>  .../devicetree/bindings/arm/mediatek/mediatek,mmsys.txt          | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>
>> Acked-by: Rob Herring <robh at kernel.org>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From claudiu.beznea at microchip.com  Tue Apr  6 15:11:52 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Tue, 6 Apr 2021 17:11:52 +0300
Subject: [PATCH] ARM: configs: at91_dt_defconfig: configs for sam9x60
Message-ID: <20210406141152.10706-1-claudiu.beznea@microchip.com>

Enable CONFIG_NO_HZ_IDLE and CONFIG_HIGH_RES_TIMERS=y to be used
in conjunction with PIT64B present on SAM9X60.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/configs/at91_dt_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
index 6403b064e8dc..bd749977b566 100644
--- a/arch/arm/configs/at91_dt_defconfig
+++ b/arch/arm/configs/at91_dt_defconfig
@@ -1,6 +1,8 @@
 # CONFIG_LOCALVERSION_AUTO is not set
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
-- 
2.25.1



From lkp at intel.com  Tue Apr  6 15:37:08 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 6 Apr 2021 22:37:08 +0800
Subject: [v3,PATCH 2/3] pwm: mtk_disp: convert the driver to atomic API
In-Reply-To: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <202104062217.1uJvXdY2-lkp@intel.com>

Hi Rex-BC,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v5.12-rc6]
[also build test WARNING on next-20210406]
[cannot apply to pwm/for-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]

url:    https://github.com/0day-ci/linux/commits/Rex-BC-Chen/Convert-the-mtk_disp-driver-to-aotmic-API/20210406-180018
base:    e49d033bddf5b565044e2abe4241353959bc9120
config: powerpc64-randconfig-r023-20210406 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project a46f59a747a7273cc439efaf3b4f98d8b63d2f20)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        # https://github.com/0day-ci/linux/commit/0a2486ac437e3b8d36a0bf8ce9648c22e42ffda4
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Rex-BC-Chen/Convert-the-mtk_disp-driver-to-aotmic-API/20210406-180018
        git checkout 0a2486ac437e3b8d36a0bf8ce9648c22e42ffda4
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:155:1: note: expanded from here
   __do_outl
   ^
   arch/powerpc/include/asm/io.h:537:62: note: expanded from macro '__do_outl'
   #define __do_outl(val, port)    writel(val,(PCI_IO_ADDR)_IO_BASE+port);
                                              ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:169:1: note: expanded from here
   __do_insb
   ^
   arch/powerpc/include/asm/io.h:556:56: note: expanded from macro '__do_insb'
   #define __do_insb(p, b, n)      readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
                                          ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:171:1: note: expanded from here
   __do_insw
   ^
   arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw'
   #define __do_insw(p, b, n)      readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
                                          ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:173:1: note: expanded from here
   __do_insl
   ^
   arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl'
   #define __do_insl(p, b, n)      readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
                                          ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:175:1: note: expanded from here
   __do_outsb
   ^
   arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb'
   #define __do_outsb(p, b, n)     writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:51:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsw, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:177:1: note: expanded from here
   __do_outsw
   ^
   arch/powerpc/include/asm/io.h:560:58: note: expanded from macro '__do_outsw'
   #define __do_outsw(p, b, n)     writesw((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
   In file included from drivers/pwm/pwm-mtk-disp.c:10:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:619:
   arch/powerpc/include/asm/io-defs.h:53:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(outsl, (unsigned long p, const void *b, unsigned long c),
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET'
                   __do_##name al;                                 \
                   ^~~~~~~~~~~~~~
   <scratch space>:179:1: note: expanded from here
   __do_outsl
   ^
   arch/powerpc/include/asm/io.h:561:58: note: expanded from macro '__do_outsl'
   #define __do_outsl(p, b, n)     writesl((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
                                           ~~~~~~~~~~~~~~~~~~~~~^
>> drivers/pwm/pwm-mtk-disp.c:109:4: warning: format specifies type 'int' but the argument has type 'u64' (aka 'unsigned long long') [-Wformat]
                           rate);
                           ^~~~
   include/linux/dev_printk.h:112:32: note: expanded from macro 'dev_err'
           _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
                                 ~~~     ^~~~~~~~~~~
   13 warnings generated.


vim +109 drivers/pwm/pwm-mtk-disp.c

    70	
    71	static int mtk_disp_pwm_enable(struct pwm_chip *chip,
    72				       const struct pwm_state *state)
    73	{
    74		struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
    75		u32 clk_div, period, high_width, value, polarity;
    76		u64 div, rate;
    77		int err;
    78	
    79		/*
    80		 * Find period, high_width and clk_div to suit duty_ns and period_ns.
    81		 * Calculate proper div value to keep period value in the bound.
    82		 *
    83		 * period_ns = 10^9 * (clk_div + 1) * (period + 1) / PWM_CLK_RATE
    84		 * duty_ns = 10^9 * (clk_div + 1) * high_width / PWM_CLK_RATE
    85		 *
    86		 * period = (PWM_CLK_RATE * period_ns) / (10^9 * (clk_div + 1)) - 1
    87		 * high_width = (PWM_CLK_RATE * duty_ns) / (10^9 * (clk_div + 1))
    88		 */
    89		if (!mdp->enabled) {
    90			err = clk_prepare_enable(mdp->clk_main);
    91			if (err < 0) {
    92				dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n",
    93					err);
    94				return err;
    95			}
    96			err = clk_prepare_enable(mdp->clk_mm);
    97			if (err < 0) {
    98				dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n",
    99					err);
   100				clk_disable_unprepare(mdp->clk_main);
   101				return err;
   102			}
   103		}
   104		rate = clk_get_rate(mdp->clk_main);
   105		clk_div = div_u64(rate * state->period, NSEC_PER_SEC) >>
   106				  PWM_PERIOD_BIT_WIDTH;
   107		if (clk_div > PWM_CLKDIV_MAX) {
   108			dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
 > 109				rate);
   110			clk_disable_unprepare(mdp->clk_mm);
   111			clk_disable_unprepare(mdp->clk_main);
   112			return -EINVAL;
   113		}
   114		div = NSEC_PER_SEC * (clk_div + 1);
   115		period = div64_u64(rate * state->period, div);
   116		if (period > 0)
   117			period--;
   118	
   119		high_width = div64_u64(rate * state->duty_cycle, div);
   120		value = period | (high_width << PWM_HIGH_WIDTH_SHIFT);
   121		polarity = 0;
   122		if (state->polarity == PWM_POLARITY_INVERSED)
   123			polarity = PWM_POLARITY;
   124	
   125		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   126					 PWM_CLKDIV_MASK,
   127					 clk_div << PWM_CLKDIV_SHIFT);
   128		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   129					 PWM_POLARITY, polarity);
   130		mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
   131					 PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
   132					 value);
   133	
   134		if (mdp->data->has_commit) {
   135			mtk_disp_pwm_update_bits(mdp, mdp->data->commit,
   136						 mdp->data->commit_mask,
   137						 mdp->data->commit_mask);
   138			mtk_disp_pwm_update_bits(mdp, mdp->data->commit,
   139						 mdp->data->commit_mask,
   140						 0x0);
   141		} else {
   142			mtk_disp_pwm_update_bits(mdp, mdp->data->bls_debug,
   143						 mdp->data->bls_debug_mask,
   144						 mdp->data->bls_debug_mask);
   145			mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   146						 mdp->data->con0_sel,
   147						 mdp->data->con0_sel);
   148		}
   149	
   150		mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
   151					 mdp->data->enable_mask);
   152		mdp->enabled = true;
   153		return 0;
   154	}
   155	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210406/2faa85a2/attachment-0001.gz>

From tzungbi at google.com  Tue Apr  6 15:45:40 2021
From: tzungbi at google.com (Tzung-Bi Shih)
Date: Tue,  6 Apr 2021 22:45:40 +0800
Subject: [PATCH] pinctrl: mediatek: use spin lock in mtk_rmw
Message-ID: <20210406144540.3467756-1-tzungbi@google.com>

Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
mutex lock in mtk_rmw.  However the function is possible called from
atomic context.

For example call trace:
  mutex_lock+0x28/0x64
  mtk_rmw+0x38/0x80
  mtk_hw_set_value+0x100/0x138
  mtk_gpio_set+0x48/0x58
  gpiod_set_raw_value_commit+0xf4/0x110
  gpiod_set_value_nocheck+0x4c/0x80
  gpiod_set_value+0x4c/0x6c
  max98357a_daiops_trigger+0x8c/0x9c
  soc_pcm_trigger+0x5c/0x10c

The max98357a_daiops_trigger() could run in either atomic or non-atomic
context.  As a result, dmesg shows some similar messages: "BUG: sleeping
function called from invalid context at kernel/locking/mutex.c:254".

Uses spin lock in mtk_rmw instead.

Fixes: 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.")
Signed-off-by: Tzung-Bi Shih <tzungbi at google.com>
---
 drivers/pinctrl/mediatek/pinctrl-moore.c         | 2 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4 ++--
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 drivers/pinctrl/mediatek/pinctrl-paris.c         | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index f77921957f15..3a4a23c40a71 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -619,7 +619,7 @@ int mtk_moore_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	/* Copy from internal struct mtk_pin_desc to register to the core */
 	pins = devm_kmalloc_array(&pdev->dev, hw->soc->npins, sizeof(*pins),
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index fcf7c3eeee4a..9ffe01a8ceca 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -58,14 +58,14 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set)
 {
 	u32 val;
 
-	mutex_lock(&pctl->lock);
+	spin_lock(&pctl->lock);
 
 	val = mtk_r32(pctl, i, reg);
 	val &= ~mask;
 	val |= set;
 	mtk_w32(pctl, i, reg, val);
 
-	mutex_unlock(&pctl->lock);
+	spin_unlock(&pctl->lock);
 }
 
 static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 65eac708a3b3..13836bb188b7 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -252,7 +252,7 @@ struct mtk_pinctrl {
 	struct mtk_pinctrl_group	*groups;
 	const char          **grp_names;
 	/* lock pin's register resource to avoid multiple threads issue*/
-	struct mutex lock;
+	spinlock_t lock;
 };
 
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 48e823f6d293..85db2e4377f0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -970,7 +970,7 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	err = mtk_pctrl_build_state(pdev);
 	if (err) {
-- 
2.31.0.208.g409f899ff0-goog



From lkp at intel.com  Tue Apr  6 15:52:35 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 6 Apr 2021 22:52:35 +0800
Subject: [v3,PATCH 2/3] pwm: mtk_disp: convert the driver to atomic API
In-Reply-To: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
References: <1617703062-4251-3-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <202104062224.aAWRNKyC-lkp@intel.com>

Hi Rex-BC,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v5.12-rc6]
[also build test WARNING on next-20210401]
[cannot apply to pwm/for-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]

url:    https://github.com/0day-ci/linux/commits/Rex-BC-Chen/Convert-the-mtk_disp-driver-to-aotmic-API/20210406-180018
base:    e49d033bddf5b565044e2abe4241353959bc9120
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/0a2486ac437e3b8d36a0bf8ce9648c22e42ffda4
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Rex-BC-Chen/Convert-the-mtk_disp-driver-to-aotmic-API/20210406-180018
        git checkout 0a2486ac437e3b8d36a0bf8ce9648c22e42ffda4
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=xtensa 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:15,
                    from include/linux/node.h:18,
                    from include/linux/cpu.h:17,
                    from include/linux/of_device.h:5,
                    from drivers/pwm/pwm-mtk-disp.c:13:
   drivers/pwm/pwm-mtk-disp.c: In function 'mtk_disp_pwm_enable':
>> drivers/pwm/pwm-mtk-disp.c:108:22: warning: format '%d' expects argument of type 'int', but argument 3 has type 'u64' {aka 'long long unsigned int'} [-Wformat=]
     108 |   dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
         |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
      19 | #define dev_fmt(fmt) fmt
         |                      ^~~
   drivers/pwm/pwm-mtk-disp.c:108:3: note: in expansion of macro 'dev_err'
     108 |   dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
         |   ^~~~~~~
   drivers/pwm/pwm-mtk-disp.c:108:55: note: format string is defined here
     108 |   dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
         |                                                      ~^
         |                                                       |
         |                                                       int
         |                                                      %lld


vim +108 drivers/pwm/pwm-mtk-disp.c

    70	
    71	static int mtk_disp_pwm_enable(struct pwm_chip *chip,
    72				       const struct pwm_state *state)
    73	{
    74		struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
    75		u32 clk_div, period, high_width, value, polarity;
    76		u64 div, rate;
    77		int err;
    78	
    79		/*
    80		 * Find period, high_width and clk_div to suit duty_ns and period_ns.
    81		 * Calculate proper div value to keep period value in the bound.
    82		 *
    83		 * period_ns = 10^9 * (clk_div + 1) * (period + 1) / PWM_CLK_RATE
    84		 * duty_ns = 10^9 * (clk_div + 1) * high_width / PWM_CLK_RATE
    85		 *
    86		 * period = (PWM_CLK_RATE * period_ns) / (10^9 * (clk_div + 1)) - 1
    87		 * high_width = (PWM_CLK_RATE * duty_ns) / (10^9 * (clk_div + 1))
    88		 */
    89		if (!mdp->enabled) {
    90			err = clk_prepare_enable(mdp->clk_main);
    91			if (err < 0) {
    92				dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n",
    93					err);
    94				return err;
    95			}
    96			err = clk_prepare_enable(mdp->clk_mm);
    97			if (err < 0) {
    98				dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n",
    99					err);
   100				clk_disable_unprepare(mdp->clk_main);
   101				return err;
   102			}
   103		}
   104		rate = clk_get_rate(mdp->clk_main);
   105		clk_div = div_u64(rate * state->period, NSEC_PER_SEC) >>
   106				  PWM_PERIOD_BIT_WIDTH;
   107		if (clk_div > PWM_CLKDIV_MAX) {
 > 108			dev_err(chip->dev, "clock rate is too high: rate = %d Hz\n",
   109				rate);
   110			clk_disable_unprepare(mdp->clk_mm);
   111			clk_disable_unprepare(mdp->clk_main);
   112			return -EINVAL;
   113		}
   114		div = NSEC_PER_SEC * (clk_div + 1);
   115		period = div64_u64(rate * state->period, div);
   116		if (period > 0)
   117			period--;
   118	
   119		high_width = div64_u64(rate * state->duty_cycle, div);
   120		value = period | (high_width << PWM_HIGH_WIDTH_SHIFT);
   121		polarity = 0;
   122		if (state->polarity == PWM_POLARITY_INVERSED)
   123			polarity = PWM_POLARITY;
   124	
   125		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   126					 PWM_CLKDIV_MASK,
   127					 clk_div << PWM_CLKDIV_SHIFT);
   128		mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   129					 PWM_POLARITY, polarity);
   130		mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
   131					 PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
   132					 value);
   133	
   134		if (mdp->data->has_commit) {
   135			mtk_disp_pwm_update_bits(mdp, mdp->data->commit,
   136						 mdp->data->commit_mask,
   137						 mdp->data->commit_mask);
   138			mtk_disp_pwm_update_bits(mdp, mdp->data->commit,
   139						 mdp->data->commit_mask,
   140						 0x0);
   141		} else {
   142			mtk_disp_pwm_update_bits(mdp, mdp->data->bls_debug,
   143						 mdp->data->bls_debug_mask,
   144						 mdp->data->bls_debug_mask);
   145			mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
   146						 mdp->data->con0_sel,
   147						 mdp->data->con0_sel);
   148		}
   149	
   150		mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, mdp->data->enable_mask,
   151					 mdp->data->enable_mask);
   152		mdp->enabled = true;
   153		return 0;
   154	}
   155	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67309 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210406/10d115c1/attachment-0001.gz>

From dinguyen at kernel.org  Tue Apr  6 15:58:35 2021
From: dinguyen at kernel.org (Dinh Nguyen)
Date: Tue,  6 Apr 2021 09:58:35 -0500
Subject: [PATCH] arm: dts: arria10: add lightweight HPS2FPGA bridge
Message-ID: <20210406145835.234546-1-dinguyen@kernel.org>

Add the lightweight HPS2FPGA bridge entry.

Signed-off-by: Dinh Nguyen <dinguyen at kernel.org>
---
 arch/arm/boot/dts/socfpga_arria10.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index a574ea91d9d3..f956c50ec6cf 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -428,6 +428,14 @@ socfpga_axi_setup: stmmac-axi-config {
 			snps,blen = <0 0 0 0 16 0 0>;
 		};
 
+		fpga_bridge0: fpga_bridge at ff200000 {
+			compatible = "altr,socfpga-lwhps2fpga-bridge";
+			reg = <0xff200000 0x100000>;
+			resets = <&rst LWHPS2FPGA_RESET>;
+			clocks = <&l4_main_clk>;
+			status = "disabled";
+		};
+
 		gmac0: ethernet at ff800000 {
 			compatible = "altr,socfpga-stmmac-a10-s10", "snps,dwmac-3.72a", "snps,dwmac";
 			altr,sysmgr-syscon = <&sysmgr 0x44 0>;
-- 
2.25.1



From achin.gupta at arm.com  Tue Apr  6 16:08:21 2021
From: achin.gupta at arm.com (Achin Gupta)
Date: Tue, 6 Apr 2021 16:08:21 +0100
Subject: [PATCH v5 1/7] dt-bindings: Arm: Add Firmware Framework for
 Armv8-A (FF-A) binding
In-Reply-To: <20210330150312.GA284502@robh.at.kernel.org>
References: <20210325143255.1532452-1-sudeep.holla@arm.com>
 <20210325143255.1532452-2-sudeep.holla@arm.com>
 <CAFA6WYMrCzDUHn4O=tM7y+w01LcSPrRu3Awja7io1XtcZPhqYQ@mail.gmail.com>
 <20210326105545.44rdcbrumg3q6i7y@bogus>
 <CAFA6WYNf+Wmb3v56_-hUekn4UwSBe87OGJFehDx7t4iDWgg17g@mail.gmail.com>
 <20210330150312.GA284502@robh.at.kernel.org>
Message-ID: <YGx5Zfj9B7cO8Uso@C02ZJ1BRLVDN>

Hi Rob,

On Tue, Mar 30, 2021 at 10:03:12AM -0500, Rob Herring wrote:
> On Fri, Mar 26, 2021 at 05:26:52PM +0530, Sumit Garg wrote:
> > On Fri, 26 Mar 2021 at 16:25, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > >
> > > On Fri, Mar 26, 2021 at 10:35:23AM +0530, Sumit Garg wrote:
> > > > Hi Sudeep,
> > > >
> > > > Apologies for catching up late on this patch-set.
> > > >
> > > > On Thu, 25 Mar 2021 at 20:05, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > > > >
> > > > > Since the FF-A v1.0 specification doesn't list the UUID of all the
> > > > > partitions in the discovery API, we need to specify the UUID of the
> > > > > partitions that need to be accessed by drivers within the kernel.
> > > > >
> > > >
> > > > Wouldn't we be able to implement auto-discovery of ffa partitions? I
> > > > think enumeration of ffa partitions on FFA bus should be quite similar
> > > > to enumeration of TAs on TEE bus (see [1]). Otherwise we need to put
> > > > these redundant DT entries for every ffa partition which IMHO would
> > > > bloat up device trees for every platform.
> > > >
> > >
> > > Any suggestions on how to ? Clearly spec doesn't have that provision, I
> > > had raised this point in the past. Jens has similar concern and he did
> > > ask the same[1]. As I replied to him in that thread[2].
> > >
> > > I am open to suggestion on how to auto-discover, currently as I see spec
> > > doesn't support it.
> > >
> >
> > Thanks for sharing links to prior discussions and I can see that
> > currently spec doesn't support it. But from an implementation
> > perspective, I can't find any reason that we can't support
> > auto-discover. Have a look at below proposed simple FFA ABI:
> >
> > FFA_LIST_PARTITIONS
> >
> > - No input params.
> > - Returns an array of secure partition UUIDs to which this non-secure
> > virtual/physical FF-A instance is allowed to communicate with.
> >
> > I think with auto-discovery, one of the major benefits is that if the
> > OEM is using a common platform to cater to multiple use-cases which
> > rely on different secure partitions then OEM doesn't have to bother
> > about shipping separate DTs.
>
> +1
>
> DT should not be the dumping ground for everything forgotten to be made
> discoverable. There's not much we can do about h/w, but firmware is
> different and can be changed. In other threads (e.g. PCI config space
> SMC calls), fixing in firmware is the proposed answer. So let's do that
> here.
>
> Maybe if there are implementations shipping and changing is too late
> (yet not too late to use a new binding), then I'd feel differently. But
> being in a spec or not alone is not enough reason alone to accept this.
> It's obvious the spec did not have wide enough review.

The v1.0 specification (released almost one year back) was reviewed by a few
Trusted OS vendors amongst other partners. Nobody provided feedback that a
FFA_LIST_PARTITIONS like discovery mechanism is a gating factor. Hindsight is a
wonderful thing! The ability of discover UUIDs of partitions would indeed be a
very useful thing and this will be added to the next version of the
specification. I think it is worth providing some background in any case.

The usage model envisioned was that a partition would export services that would
be identified by a UUID. An FF-A client that wants to use these services would
query their presence by specifying this UUID. The FF-A discovery ABI returns a
16-bit ID of the partition that implements the services. This ID is more
user-friendly and space efficient than a 16 byte UUID for register and shared
memory based IPC between the client and the server.

For example, OP-TEE would have a UUID to represent the TEE service. The OP-TEE
driver would ask the FF-A driver if there is a partition with a UUID that
provides OP-TEE's TEE service.

The assumption was that a client must identify the service(s) it wants to access
to be able to use FF-A ABIs to talk to the partition that implements them. This
was more important than a discovery mechanism where the client says: I don't
know what I want but please list all the UUIDs of all partitions in the
system. I will then see if I can find anything that I like.

In this model, it was not envisioned that the FF-A driver would carry the UUIDs
of services that its clients could want to access. The client would know the
UUID and the FF-A driver would return the properties of the partition and its ID
to enable further communication.

We did envision the need for the FF-A driver to know the IDs of all the
partitions in the system and their properties e.g. number of vCPUs etc. The
FFA_PARTITION_INFO_GET ABI when invoked with a NULL UUID returns this
information. It is a bit like "grep *.*".

The implementation choice to have an FF-A bus with partitions as devices on it
was made after the specification was released. This was not obvious at all at
the time of writing the specification. Clearly, in this model the FF-A driver
needs to the know the UUIDs. But this does not change the fact that the clients
of the FF-A driver still need to know the UUID of the services they are
interested in.

For v1.0 we are left with no choice but to carry them in the DT. This will be
addressed in v1.1. I see this as a case where implementation choices drive the
evolution of a specification.

I hope you can understand that it was a bit difficult to foresee this usage
model for v1.0 when specification and implementation are temporally separated.

I also think that this issue is different from the cluster **** the PCIe ECAM
SMC discussion is.

I do hope this helps clarify the situation to some extent. Please let me know if
you need any more info or if I have missed anything. Also, apologies for not
getting back sooner as I was on holiday.

cheers,
Achin


From arnd at arndb.de  Tue Apr  6 16:15:01 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 6 Apr 2021 17:15:01 +0200
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>

On Tue, Apr 6, 2021 at 2:09 PM Jonathan Neusch?fer
<j.neuschaefer at gmx.net> wrote:
>
> This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
> SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.
>
> Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki
>
> Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
> Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
> the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.
>
> Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
> (https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)

Hi Jonathan,

It appears these patches are doing roughly the right thing, and we may still
be able to get them into v5.13, but I'm not sure what your plan for maintaining
them is. The two options are that you either send your patches to be picked up
by Joel, or you send everything directly to soc at kernel.org once it's fully
reviewed.

I only noticed your series when patch 9/10 made it into the soc at kernel.org
patchwork because of the Cc, but none of the other ones did.

If you end up with the second option, we can go through what this involves
off-list.

Regarding the Cc:soc at kernel.org, please add that only for patches that
are already reviewed and ready to be picked up, ideally with a cover letter
that describes what the plan is for merging. If you need me to review the
platform code, use my arnd at arndb.de or arnd at kernel.org addresses.

          Arnd


From lorenzo.pieralisi at arm.com  Tue Apr  6 16:29:03 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 6 Apr 2021 16:29:03 +0100
Subject: [PATCH v14 09/10] ACPI/IORT: Enable stall support for platform
 devices
In-Reply-To: <20210401154718.307519-10-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
 <20210401154718.307519-10-jean-philippe@linaro.org>
Message-ID: <20210406152903.GA28301@lpieralisi>

On Thu, Apr 01, 2021 at 05:47:18PM +0200, Jean-Philippe Brucker wrote:
> Copy the "Stall supported" bit, that tells whether a named component
> supports stall, into the dma-can-stall device property.
> 
> Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
> ---
>  drivers/acpi/arm64/iort.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 3912a1f6058e..0828f70cb782 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -968,13 +968,15 @@ static int iort_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
>  static void iort_named_component_init(struct device *dev,
>  				      struct acpi_iort_node *node)
>  {
> -	struct property_entry props[2] = {};
> +	struct property_entry props[3] = {};
>  	struct acpi_iort_named_component *nc;
>  
>  	nc = (struct acpi_iort_named_component *)node->node_data;
>  	props[0] = PROPERTY_ENTRY_U32("pasid-num-bits",
>  				      FIELD_GET(ACPI_IORT_NC_PASID_BITS,
>  						nc->node_flags));
> +	if (nc->node_flags & ACPI_IORT_NC_STALL_SUPPORTED)
> +		props[1] = PROPERTY_ENTRY_BOOL("dma-can-stall");
>  
>  	if (device_add_properties(dev, props))
>  		dev_warn(dev, "Could not add device properties\n");
> -- 
> 2.31.1
> 


From quanyang.wang at windriver.com  Tue Apr  6 16:31:31 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Tue,  6 Apr 2021 23:31:31 +0800
Subject: [V3][PATCH] clk: zynqmp: pll: add set_pll_mode to check condition in
 zynqmp_pll_enable
Message-ID: <20210406153131.601701-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever,
we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this
pll has been enabled. In ATF implementation, it will only assign
the mode to the variable (struct pm_pll *)pll->mode when handling
IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force
ATF send request to PWU to set the pll mode to PLL's register.

There is a scenario that happens in enabling VPLL_INT(clk_id:96):
1) VPLL_INT has been enabled during booting.
2) A driver calls clk_set_rate and according to the rate, the VPLL_INT
   should be set to FRAC mode. Then zynqmp_pll_set_mode is called
   to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point
   ATF just stores the mode to a variable.
3) This driver calls clk_prepare_enable and zynqmp_pll_enable is
   called to try to enable VPLL_INT pll. Because of 1), the function
   zynqmp_pll_enable just returns without doing anything after checking
   that this pll has been enabled.

In the scenario above, the pll mode of VPLL_INT will never be set
successfully. So adding set_pll_mode to check condition to fix it.

Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
V3:
 - add Fixes tag.
V2:
 - add Tested-by tag, thanks Laurent.
 - fix typos in commit message and multiline code comments.
---
 drivers/clk/zynqmp/pll.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
index 92f449ed38e5..0d64268a4a84 100644
--- a/drivers/clk/zynqmp/pll.c
+++ b/drivers/clk/zynqmp/pll.c
@@ -14,10 +14,12 @@
  * struct zynqmp_pll - PLL clock
  * @hw:		Handle between common and hardware-specific interfaces
  * @clk_id:	PLL clock ID
+ * @set_pll_mode:	Whether an IOCTL_SET_PLL_FRAC_MODE request be sent to ATF
  */
 struct zynqmp_pll {
 	struct clk_hw hw;
 	u32 clk_id;
+	bool set_pll_mode;
 };
 
 #define to_zynqmp_pll(_hw)	container_of(_hw, struct zynqmp_pll, hw)
@@ -81,6 +83,8 @@ static inline void zynqmp_pll_set_mode(struct clk_hw *hw, bool on)
 	if (ret)
 		pr_warn_once("%s() PLL set frac mode failed for %s, ret = %d\n",
 			     __func__, clk_name, ret);
+	else
+		clk->set_pll_mode = true;
 }
 
 /**
@@ -240,9 +244,15 @@ static int zynqmp_pll_enable(struct clk_hw *hw)
 	u32 clk_id = clk->clk_id;
 	int ret;
 
-	if (zynqmp_pll_is_enabled(hw))
+	/*
+	 * Don't skip enabling clock if there is an IOCTL_SET_PLL_FRAC_MODE request
+	 * that has been sent to ATF.
+	 */
+	if (zynqmp_pll_is_enabled(hw) && (!clk->set_pll_mode))
 		return 0;
 
+	clk->set_pll_mode = false;
+
 	ret = zynqmp_pm_clock_enable(clk_id);
 	if (ret)
 		pr_warn_once("%s() clock enable failed for %s, ret = %d\n",
-- 
2.25.1



From quanyang.wang at windriver.com  Tue Apr  6 16:40:15 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Tue,  6 Apr 2021 23:40:15 +0800
Subject: [V2][PATCH] clk: zynqmp: move zynqmp_pll_set_mode out of round_rate
 callback
Message-ID: <20210406154015.602779-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The round_rate callback should only perform rate calculation and not
involve calling zynqmp_pll_set_mode to change the pll mode. So let's
move zynqmp_pll_set_mode out of round_rate and to set_rate callback.

Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
Reported-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
V2:
 - add Fixes tag.
---
 drivers/clk/zynqmp/pll.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
index 0d64268a4a84..abe6afbf3407 100644
--- a/drivers/clk/zynqmp/pll.c
+++ b/drivers/clk/zynqmp/pll.c
@@ -104,9 +104,7 @@ static long zynqmp_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 	/* Enable the fractional mode if needed */
 	rate_div = (rate * FRAC_DIV) / *prate;
 	f = rate_div % FRAC_DIV;
-	zynqmp_pll_set_mode(hw, !!f);
-
-	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
+	if (f) {
 		if (rate > PS_PLL_VCO_MAX) {
 			fbdiv = rate / PS_PLL_VCO_MAX;
 			rate = rate / (fbdiv + 1);
@@ -177,10 +175,12 @@ static int zynqmp_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	long rate_div, frac, m, f;
 	int ret;
 
-	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
-		rate_div = (rate * FRAC_DIV) / parent_rate;
+	rate_div = (rate * FRAC_DIV) / parent_rate;
+	f = rate_div % FRAC_DIV;
+	zynqmp_pll_set_mode(hw, !!f);
+
+	if (f) {
 		m = rate_div / FRAC_DIV;
-		f = rate_div % FRAC_DIV;
 		m = clamp_t(u32, m, (PLL_FBDIV_MIN), (PLL_FBDIV_MAX));
 		rate = parent_rate * m;
 		frac = (parent_rate * f) / FRAC_DIV;
-- 
2.25.1



From lorenzo.pieralisi at arm.com  Tue Apr  6 16:42:14 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue,  6 Apr 2021 16:42:14 +0100
Subject: [PATCH v5 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
In-Reply-To: <20210312204556.5387-1-jim2101024@gmail.com>
References: <20210312204556.5387-1-jim2101024@gmail.com>
Message-ID: <161772368880.12349.1551046998078695154.b4-ty@arm.com>

On Fri, 12 Mar 2021 15:45:53 -0500, Jim Quinlan wrote:
> v5 -- Improved (I hope) commit description (Bjorn).
>    -- Rnamed error labels (Krzyszt).
>    -- Fixed typos.
> 
> v4 -- does not rely on a pending commit, unlike v3.
> 
> v3 -- discard commit from v2; instead rely on the new function
>       reset_control_rearm provided in a recent commit [1] applied
>       to reset/next.
>    -- New commit to correct pcie-brcmstb.c usage of a reset controller
>       to use reset/rearm verses deassert/assert.
> 
> [...]

Applied to pci/brcmstb, thanks!

[1/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
      https://git.kernel.org/lpieralisi/pci/c/92b9cb55a9
[2/2] PCI: brcmstb: Use reset/rearm instead of deassert/assert
      https://git.kernel.org/lpieralisi/pci/c/a24fd1d646

Thanks,
Lorenzo


From jbx6244 at gmail.com  Tue Apr  6 16:50:52 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue,  6 Apr 2021 17:50:52 +0200
Subject: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
Message-ID: <20210406155053.29101-1-jbx6244@gmail.com>

Current dts files with 'pwm' nodes are manually verified.
In order to automate this process pwm-rockchip.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 ---------
 .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 66 ++++++++++++++++++++++
 2 files changed, 66 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
deleted file mode 100644
index f70956dea..000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Rockchip PWM controller
-
-Required properties:
- - compatible: should be "rockchip,<name>-pwm"
-   "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
-   "rockchip,rk3288-pwm": found on RK3288 SOC
-   "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
-   "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- - reg: physical base address and length of the controller's registers
- - clocks: See ../clock/clock-bindings.txt
-   - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
-     - There is one clock that's used both to derive the functional clock
-       for the device and as the bus clock.
-   - For newer hardware (rk3328 and future socs): specified by name
-     - "pwm": This is used to derive the functional clock.
-     - "pclk": This is the APB bus clock.
- - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this directory
-   for a description of the cell format.
-
-Example:
-
-	pwm0: pwm at 20030000 {
-		compatible = "rockchip,rk2928-pwm";
-		reg = <0x20030000 0x10>;
-		clocks = <&cru PCLK_PWM01>;
-		#pwm-cells = <2>;
-	};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
new file mode 100644
index 000000000..cfd637d3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PWM controller
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    oneOf:
+      - const: rockchip,rk2928-pwm
+      - const: rockchip,rk3288-pwm
+      - const: rockchip,vop-pwm
+      - items:
+          - enum:
+              - rockchip,rv1108-pwm
+          - const: rockchip,rk3288-pwm
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+    description:
+      For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399)
+        There is one clock that is used both to derive the functional clock
+        for the device and as the bus clock.
+      For newer hardware (rk3328 and future SoCs) that is also specified
+      with clock names.
+        "pwm" is used to derive the functional clock for the device.
+        "pclk" is used as the APB bus clock.
+
+  clock-names:
+    minItems: 1
+    items:
+      - const: pwm
+      - const: pclk
+
+  "#pwm-cells":
+    enum: [2, 3]
+    description:
+      Must be 2 (rk2928) or 3 (rk3288).
+      See pwm.yaml for a description of the cell format.
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - "#pwm-cells"
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3188-cru-common.h>
+    pwm0: pwm at 20030000 {
+      compatible = "rockchip,rk2928-pwm";
+      reg = <0x20030000 0x10>;
+      clocks = <&cru PCLK_PWM01>;
+      #pwm-cells = <2>;
+    };
-- 
2.11.0



From jbx6244 at gmail.com  Tue Apr  6 16:50:53 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue,  6 Apr 2021 17:50:53 +0200
Subject: [PATCH v1 2/2] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210406155053.29101-1-jbx6244@gmail.com>
References: <20210406155053.29101-1-jbx6244@gmail.com>
Message-ID: <20210406155053.29101-2-jbx6244@gmail.com>

The compatible strings below are already in use in the Rockchip
dtsi files, but were somehow never added to a document, so add

"rockchip,rk3328-pwm"

"rockchip,rk3036-pwm", "rockchip,rk2928-pwm"

"rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
"rockchip,rk3399-pwm", "rockchip,rk3288-pwm"

"rockchip,px30-pwm", "rockchip,rk3328-pwm"
"rockchip,rk3308-pwm", "rockchip,rk3328-pwm"

for pwm nodes to pwm-rockchip.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index cfd637d3e..3945d586c 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -14,11 +14,22 @@ properties:
     oneOf:
       - const: rockchip,rk2928-pwm
       - const: rockchip,rk3288-pwm
+      - const: rockchip,rk3328-pwm
       - const: rockchip,vop-pwm
       - items:
+          - const: rockchip,rk3036-pwm
+          - const: rockchip,rk2928-pwm
+      - items:
           - enum:
+              - rockchip,rk3368-pwm
+              - rockchip,rk3399-pwm
               - rockchip,rv1108-pwm
           - const: rockchip,rk3288-pwm
+      - items:
+          - enum:
+              - rockchip,px30-pwm
+              - rockchip,rk3308-pwm
+          - const: rockchip,rk3328-pwm
 
   reg:
     maxItems: 1
-- 
2.11.0



From linux at roeck-us.net  Tue Apr  6 17:09:59 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 6 Apr 2021 09:09:59 -0700
Subject: [PATCH v3 08/15] arm64: socfpga: merge Agilex and N5X into
 ARCH_INTEL_SOCFPGA
In-Reply-To: <20210311152545.1317581-9-krzysztof.kozlowski@canonical.com>
References: <20210311152545.1317581-1-krzysztof.kozlowski@canonical.com>
 <20210311152545.1317581-9-krzysztof.kozlowski@canonical.com>
Message-ID: <20210406160959.GA208060@roeck-us.net>

On Thu, Mar 11, 2021 at 04:25:38PM +0100, Krzysztof Kozlowski wrote:
> Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and
> SoC-part.  Up to a point that N5X uses the same DTSI as Agilex.  From
> the Linux kernel point of view these are flavors of the same
> architecture so there is no need for three top-level arm64
> architectures.  Simplify this by merging all three architectures into
> ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries.
> 
> The side effect is that the INTEL_STRATIX10_SERVICE will now be
> available for both 32-bit and 64-bit Intel SoCFPGA, even though it is
> used only for 64-bit.

Did you try to compile, say, arm:allmodconfig with this patch applied ?
Because for me that results in:

In file included from <command-line>:
drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback':
include/linux/compiler_types.h:320:38: error:
	call to '__compiletime_assert_177' declared with attribute error:
	FIELD_GET: type of reg too small for mask

and lots of similar errors.

Guenter

> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
>  arch/arm64/Kconfig.platforms       | 21 ++++-----------------
>  arch/arm64/boot/dts/intel/Makefile |  6 +++---
>  arch/arm64/configs/defconfig       |  3 +--
>  drivers/clk/Makefile               |  2 --
>  drivers/clk/socfpga/Kconfig        |  4 ++--
>  drivers/firmware/Kconfig           |  2 +-
>  drivers/fpga/Kconfig               |  2 +-
>  drivers/reset/Kconfig              |  2 +-
>  8 files changed, 13 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index ecab67a1afb8..ce50dd129eec 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -8,16 +8,6 @@ config ARCH_ACTIONS
>  	help
>  	  This enables support for the Actions Semiconductor S900 SoC family.
>  
> -config ARCH_AGILEX
> -	bool "Intel's Agilex SoCFPGA Family"
> -	help
> -	  This enables support for Intel's Agilex SoCFPGA Family.
> -
> -config ARCH_N5X
> -	bool "Intel's eASIC N5X SoCFPGA Family"
> -	help
> -	  This enables support for Intel's eASIC N5X SoCFPGA Family.
> -
>  config ARCH_SUNXI
>  	bool "Allwinner sunxi 64-bit SoC Family"
>  	select ARCH_HAS_RESET_CONTROLLER
> @@ -254,14 +244,11 @@ config ARCH_SEATTLE
>  	help
>  	  This enables support for AMD Seattle SOC Family
>  
> -config ARCH_STRATIX10
> -	bool "Altera's Stratix 10 SoCFPGA Family"
> -	select ARCH_INTEL_SOCFPGA
> -	help
> -	  This enables support for Altera's Stratix 10 SoCFPGA Family.
> -
>  config ARCH_INTEL_SOCFPGA
> -	bool
> +	bool "Intel's SoCFPGA ARMv8 Families"
> +	help
> +	  This enables support for Intel's SoCFPGA ARMv8 families:
> +	  Stratix 10 (ex. Altera), Agilex and eASIC N5X.
>  
>  config ARCH_SYNQUACER
>  	bool "Socionext SynQuacer SoC Family"
> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
> index 3a052540605b..0b5477442263 100644
> --- a/arch/arm64/boot/dts/intel/Makefile
> +++ b/arch/arm64/boot/dts/intel/Makefile
> @@ -1,5 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \
> -			     socfpga_agilex_socdk_nand.dtb
> +dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_socdk.dtb \
> +				socfpga_agilex_socdk_nand.dtb \
> +				socfpga_n5x_socdk.dtb
>  dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
> -dtb-$(CONFIG_ARCH_N5X) += socfpga_n5x_socdk.dtb
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d612f633b771..cf8a3009b858 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -28,7 +28,6 @@ CONFIG_KALLSYMS_ALL=y
>  # CONFIG_COMPAT_BRK is not set
>  CONFIG_PROFILING=y
>  CONFIG_ARCH_ACTIONS=y
> -CONFIG_ARCH_AGILEX=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_ARCH_ALPINE=y
>  CONFIG_ARCH_BCM2835=y
> @@ -50,7 +49,7 @@ CONFIG_ARCH_RENESAS=y
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_ARCH_S32=y
>  CONFIG_ARCH_SEATTLE=y
> -CONFIG_ARCH_STRATIX10=y
> +CONFIG_ARCH_INTEL_SOCFPGA=y
>  CONFIG_ARCH_SYNQUACER=y
>  CONFIG_ARCH_TEGRA=y
>  CONFIG_ARCH_SPRD=y
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 1e29e5ad107a..96802294d35a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -105,8 +105,6 @@ obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
>  obj-$(CONFIG_COMMON_CLK_SAMSUNG)	+= samsung/
>  obj-$(CONFIG_CLK_SIFIVE)		+= sifive/
>  obj-$(CONFIG_ARCH_INTEL_SOCFPGA)	+= socfpga/
> -obj-$(CONFIG_ARCH_AGILEX)		+= socfpga/
> -obj-$(CONFIG_ARCH_N5X)			+= socfpga/
>  obj-$(CONFIG_PLAT_SPEAR)		+= spear/
>  obj-y					+= sprd/
>  obj-$(CONFIG_ARCH_STI)			+= st/
> diff --git a/drivers/clk/socfpga/Kconfig b/drivers/clk/socfpga/Kconfig
> index bc102e0f0be0..b6c5b9737174 100644
> --- a/drivers/clk/socfpga/Kconfig
> +++ b/drivers/clk/socfpga/Kconfig
> @@ -2,5 +2,5 @@
>  config CLK_INTEL_SOCFPGA64
>  	bool
>  	# Intel Stratix / Agilex / N5X clock controller support
> -	default (ARCH_AGILEX || ARCH_N5X || ARCH_STRATIX10)
> -	depends on ARCH_AGILEX || ARCH_N5X || ARCH_STRATIX10
> +	default ARM64 && ARCH_INTEL_SOCFPGA
> +	depends on ARM64 && ARCH_INTEL_SOCFPGA
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 3f14dffb9669..6a4e882e448d 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -206,7 +206,7 @@ config FW_CFG_SYSFS_CMDLINE
>  
>  config INTEL_STRATIX10_SERVICE
>  	tristate "Intel Stratix10 Service Layer"
> -	depends on (ARCH_STRATIX10 || ARCH_AGILEX) && HAVE_ARM_SMCCC
> +	depends on ARCH_INTEL_SOCFPGA && HAVE_ARM_SMCCC
>  	default n
>  	help
>  	  Intel Stratix10 service layer runs at privileged exception level,
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 5ff9438b7b46..fd325e9c5ce6 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -60,7 +60,7 @@ config FPGA_MGR_ZYNQ_FPGA
>  
>  config FPGA_MGR_STRATIX10_SOC
>  	tristate "Intel Stratix10 SoC FPGA Manager"
> -	depends on (ARCH_STRATIX10 && INTEL_STRATIX10_SERVICE)
> +	depends on (ARCH_INTEL_SOCFPGA && INTEL_STRATIX10_SERVICE)
>  	help
>  	  FPGA manager driver support for the Intel Stratix10 SoC.
>  
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 4171c6f76385..b1e8efa16166 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -183,7 +183,7 @@ config RESET_SCMI
>  
>  config RESET_SIMPLE
>  	bool "Simple Reset Controller Driver" if COMPILE_TEST
> -	default ARCH_AGILEX || ARCH_ASPEED || ARCH_BCM4908 || ARCH_BITMAIN || ARCH_REALTEK || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARC
> +	default ARCH_ASPEED || ARCH_BCM4908 || ARCH_BITMAIN || ARCH_REALTEK || ARCH_STM32 || (ARCH_INTEL_SOCFPGA && ARM64) || ARCH_SUNXI || ARC
>  	help
>  	  This enables a simple reset controller driver for reset lines that
>  	  that can be asserted and deasserted by toggling bits in a contiguous,
> -- 
> 2.25.1
> 


From krzysztof.kozlowski at canonical.com  Tue Apr  6 17:15:13 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 6 Apr 2021 18:15:13 +0200
Subject: [PATCH v3 08/15] arm64: socfpga: merge Agilex and N5X into
 ARCH_INTEL_SOCFPGA
In-Reply-To: <20210406160959.GA208060@roeck-us.net>
References: <20210311152545.1317581-1-krzysztof.kozlowski@canonical.com>
 <20210311152545.1317581-9-krzysztof.kozlowski@canonical.com>
 <20210406160959.GA208060@roeck-us.net>
Message-ID: <CA+Eumj6C60r4DF24W2GobwB1GrQADLpm5YXLAzHjcjWmrrsE3g@mail.gmail.com>

On Tue, 6 Apr 2021 at 18:10, Guenter Roeck <linux at roeck-us.net> wrote:
>
> On Thu, Mar 11, 2021 at 04:25:38PM +0100, Krzysztof Kozlowski wrote:
> > Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and
> > SoC-part.  Up to a point that N5X uses the same DTSI as Agilex.  From
> > the Linux kernel point of view these are flavors of the same
> > architecture so there is no need for three top-level arm64
> > architectures.  Simplify this by merging all three architectures into
> > ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries.
> >
> > The side effect is that the INTEL_STRATIX10_SERVICE will now be
> > available for both 32-bit and 64-bit Intel SoCFPGA, even though it is
> > used only for 64-bit.
>
> Did you try to compile, say, arm:allmodconfig with this patch applied ?
> Because for me that results in:
>
> In file included from <command-line>:
> drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback':
> include/linux/compiler_types.h:320:38: error:
>         call to '__compiletime_assert_177' declared with attribute error:
>         FIELD_GET: type of reg too small for mask
>
> and lots of similar errors.

Thanks for the report. I fixed that already with:
https://lore.kernel.org/lkml/20210321184650.10926-1-krzysztof.kozlowski at canonical.com/
(and https://lore.kernel.org/lkml/20210404124609.122377-1-dinguyen at kernel.org/ )
but for some reason it did not go to the same tree.

Best regards,
Krzysztof


From dinguyen at kernel.org  Tue Apr  6 17:16:14 2021
From: dinguyen at kernel.org (Dinh Nguyen)
Date: Tue, 6 Apr 2021 11:16:14 -0500
Subject: [PATCH v3 08/15] arm64: socfpga: merge Agilex and N5X into
 ARCH_INTEL_SOCFPGA
In-Reply-To: <20210406160959.GA208060@roeck-us.net>
References: <20210311152545.1317581-1-krzysztof.kozlowski@canonical.com>
 <20210311152545.1317581-9-krzysztof.kozlowski@canonical.com>
 <20210406160959.GA208060@roeck-us.net>
Message-ID: <62dc6f31-b488-64b6-7a05-0a68a678fdd5@kernel.org>



On 4/6/21 11:09 AM, Guenter Roeck wrote:
> On Thu, Mar 11, 2021 at 04:25:38PM +0100, Krzysztof Kozlowski wrote:
>> Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and
>> SoC-part.  Up to a point that N5X uses the same DTSI as Agilex.  From
>> the Linux kernel point of view these are flavors of the same
>> architecture so there is no need for three top-level arm64
>> architectures.  Simplify this by merging all three architectures into
>> ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries.
>>
>> The side effect is that the INTEL_STRATIX10_SERVICE will now be
>> available for both 32-bit and 64-bit Intel SoCFPGA, even though it is
>> used only for 64-bit.
> 
> Did you try to compile, say, arm:allmodconfig with this patch applied ?
> Because for me that results in:
> 
> In file included from <command-line>:
> drivers/firmware/stratix10-rsu.c: In function 'rsu_status_callback':
> include/linux/compiler_types.h:320:38: error:
> 	call to '__compiletime_assert_177' declared with attribute error:
> 	FIELD_GET: type of reg too small for mask
> 
> and lots of similar errors.
> 

There's a patch to fix this in flight to the arm-soc tree.

Dinh


From lorenzo.pieralisi at arm.com  Tue Apr  6 17:23:05 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 6 Apr 2021 17:23:05 +0100
Subject: [PATCH] iommu/arm-smmu-qcom: create qcom_smmu_impl for ACPI boot
In-Reply-To: <20210325170256.GA904837@yoga>
References: <20210301074021.20059-1-shawn.guo@linaro.org>
 <20210325145914.GC15172@willie-the-truck>
 <20210325170256.GA904837@yoga>
Message-ID: <20210406162305.GA28529@lpieralisi>

On Thu, Mar 25, 2021 at 12:02:56PM -0500, Bjorn Andersson wrote:
> On Thu 25 Mar 09:59 CDT 2021, Will Deacon wrote:
> 
> > [+ Lorenzo]
> > 
> > On Mon, Mar 01, 2021 at 03:40:21PM +0800, Shawn Guo wrote:
> > > Though qcom_adreno_smmu_impl is not used by ACPI boot right now,
> > > qcom_smmu_impl is already required at least to boot up Lenovo Flex 5G
> > > laptop.  Let's check asl_compiler_id in IORT header to ensure we are
> > > running a QCOM SMMU and create qcom_smmu_impl for it.
> > > 
> > > !np is used to check ACPI boot, because fwnode of SMMU device is
> > > a static allocation and thus has_acpi_companion() doesn't work here.
> > > 
> > > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> > > ---
> > >  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 33 ++++++++++++++++++++++
> > >  1 file changed, 33 insertions(+)
> > 
> > I don't know what a "asl_compiler_id" is, but it doesn't sound like it
> > has an awful lot to do with the SMMU.
> > 
> 
> I would prefer that we somehow relate this to the particular board,
> rather than all Qualcomm-related ACPI tables. E.g. by relying on the
> SMMU devices having a _HID of QCOM0409.
> 
> Shawn, any reason for this wouldn't be possible?
> 
> > Lorenzo -- any idea what we should be doing here instead? Probably not
> > using ACPI?
> > 
> 
> The 8cx (aka sc8180x) platform comes with Qualcomm's usual SMMU
> stream-mapping quirks and this is one of the patches needed to bring
> enough ACPI support to run the Debian installer that Shawn has been
> working on. After the installer we currently only boot this using DT -
> which already enables the quirk.

I am not sure I follow - can you explain please why this patch (and so
the QCOM SMMU) is actually needed ? I don't get why getting the SMMU
up and running with ACPI is mandatory to complete the process you describe
above (but I am not sure I understood it entirely either - apologies).

Thanks,
Lorenzo


From broonie at kernel.org  Tue Apr  6 17:34:39 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 17:34:39 +0100
Subject: [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 device voltage
 regulators
In-Reply-To: <20210401212148.47033-4-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-4-jim2101024@gmail.com>
Message-ID: <20210406163439.GL6443@sirena.org.uk>

On Thu, Apr 01, 2021 at 05:21:43PM -0400, Jim Quinlan wrote:

> +	/* Look for specific pcie regulators in the RC DT node. */
> +	for_each_property_of_node(np, pp) {
> +		for (i = 0; i < ns; i++)
> +			if (strcmp(supplies[i], pp->name) == 0)

This is broken, the driver knows which supplies are expected, the device
can't function without these supplies so the driver should just
unconditionally request them like any other supply.
-------------- 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/20210406/f7fda5c0/attachment.sig>

From f.fainelli at gmail.com  Tue Apr  6 17:38:46 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 6 Apr 2021 09:38:46 -0700
Subject: [PATCH v5 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
In-Reply-To: <161772368880.12349.1551046998078695154.b4-ty@arm.com>
References: <20210312204556.5387-1-jim2101024@gmail.com>
 <161772368880.12349.1551046998078695154.b4-ty@arm.com>
Message-ID: <be8892ed-cba6-e8c3-6e1d-5a9940af9440@gmail.com>



On 4/6/2021 8:42 AM, Lorenzo Pieralisi wrote:
> On Fri, 12 Mar 2021 15:45:53 -0500, Jim Quinlan wrote:
>> v5 -- Improved (I hope) commit description (Bjorn).
>>    -- Rnamed error labels (Krzyszt).
>>    -- Fixed typos.
>>
>> v4 -- does not rely on a pending commit, unlike v3.
>>
>> v3 -- discard commit from v2; instead rely on the new function
>>       reset_control_rearm provided in a recent commit [1] applied
>>       to reset/next.
>>    -- New commit to correct pcie-brcmstb.c usage of a reset controller
>>       to use reset/rearm verses deassert/assert.
>>
>> [...]
> 
> Applied to pci/brcmstb, thanks!
> 
> [1/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
>       https://git.kernel.org/lpieralisi/pci/c/92b9cb55a9
> [2/2] PCI: brcmstb: Use reset/rearm instead of deassert/assert
>       https://git.kernel.org/lpieralisi/pci/c/a24fd1d646

Thanks a lot!
-- 
Florian


From robh at kernel.org  Tue Apr  6 17:44:11 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 6 Apr 2021 11:44:11 -0500
Subject: [PATCH v4 05/18] dt-bindings: timer: arm,arch_timer: Add
 interrupt-names support
In-Reply-To: <20210402090542.131194-6-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-6-marcan@marcan.st>
Message-ID: <20210406164411.GA1937531@robh.at.kernel.org>

On Fri, 02 Apr 2021 18:05:29 +0900, Hector Martin wrote:
> Not all platforms provide the same set of timers/interrupts, and Linux
> only needs one (plus kvm/guest ones); some platforms are working around
> this by using dummy fake interrupts. Implementing interrupt-names allows
> the devicetree to specify an arbitrary set of available interrupts, so
> the timer code can pick the right one.
> 
> This also adds the hyp-virt timer/interrupt, which was previously not
> expressed in the fixed 4-interrupt form.
> 
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> Acked-by: Marc Zyngier <maz at kernel.org>
> Reviewed-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Hector Martin <marcan at marcan.st>
> ---
>  .../bindings/timer/arm,arch_timer.yaml        | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From broonie at kernel.org  Tue Apr  6 17:47:08 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 17:47:08 +0100
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210401212148.47033-3-jim2101024@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
Message-ID: <20210406164708.GM6443@sirena.org.uk>

On Thu, Apr 01, 2021 at 05:21:42PM -0400, Jim Quinlan wrote:
> Similar to the regulator bindings found in "rockchip-pcie-host.txt", this
> allows optional regulators to be attached and controlled by the PCIe RC
> driver.  That being said, this driver searches in the DT subnode (the EP
> node, eg pci at 0,0) for the regulator property.

> The use of a regulator property in the pcie EP subnode such as
> "vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml
> file at
> 
> https://github.com/devicetree-org/dt-schema/pull/54
> 
> Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
> ---
>  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index f90557f6deb8..f2caa5b3b281 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -64,6 +64,9 @@ properties:
>  
>    aspm-no-l0s: true
>  
> +  vpcie12v-supply: true
> +  vpcie3v3-supply: true
> +

No great problem with having these in the controller node (assming it
accurately describes the hardware) but I do think we ought to also be
able to describe these per slot.
-------------- 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/20210406/85dda0ef/attachment-0001.sig>

From robh at kernel.org  Tue Apr  6 17:47:48 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 6 Apr 2021 11:47:48 -0500
Subject: [PATCH v4 12/18] of/address: Add infrastructure to declare MMIO
 as non-posted
In-Reply-To: <20210402090542.131194-13-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-13-marcan@marcan.st>
Message-ID: <20210406164748.GA1937719@robh.at.kernel.org>

On Fri, Apr 02, 2021 at 06:05:36PM +0900, Hector Martin wrote:
> This implements the 'nonposted-mmio' boolean property. Placing this
> property in a bus marks all direct child devices as requiring
> non-posted MMIO mappings. If no such property is found, the default
> is posted MMIO.
> 
> of_mmio_is_nonposted() performs this check to determine if a given
> device has requested non-posted MMIO.
> 
> of_address_to_resource() uses this to set the IORESOURCE_MEM_NONPOSTED
> flag on resources that require non-posted MMIO.
> 
> of_iomap() and of_io_request_and_map() then use this flag to pick the
> correct ioremap() variant.
> 
> This mechanism is currently restricted to builds that support Apple ARM
> platforms, as an optimization.
> 
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> Signed-off-by: Hector Martin <marcan at marcan.st>
> ---
>  drivers/of/address.c       | 43 ++++++++++++++++++++++++++++++++++++--
>  include/linux/of_address.h |  1 +
>  2 files changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 73ddf2540f3f..6485cc536e81 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -847,6 +847,9 @@ static int __of_address_to_resource(struct device_node *dev,
>  		return -EINVAL;
>  	memset(r, 0, sizeof(struct resource));
>  
> +	if (of_mmio_is_nonposted(dev))
> +		flags |= IORESOURCE_MEM_NONPOSTED;
> +
>  	r->start = taddr;
>  	r->end = taddr + size - 1;
>  	r->flags = flags;
> @@ -896,7 +899,10 @@ void __iomem *of_iomap(struct device_node *np, int index)
>  	if (of_address_to_resource(np, index, &res))
>  		return NULL;
>  
> -	return ioremap(res.start, resource_size(&res));
> +	if (res.flags & IORESOURCE_MEM_NONPOSTED)
> +		return ioremap_np(res.start, resource_size(&res));
> +	else
> +		return ioremap(res.start, resource_size(&res));
>  }
>  EXPORT_SYMBOL(of_iomap);
>  
> @@ -928,7 +934,11 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
>  	if (!request_mem_region(res.start, resource_size(&res), name))
>  		return IOMEM_ERR_PTR(-EBUSY);
>  
> -	mem = ioremap(res.start, resource_size(&res));
> +	if (res.flags & IORESOURCE_MEM_NONPOSTED)
> +		mem = ioremap_np(res.start, resource_size(&res));
> +	else
> +		mem = ioremap(res.start, resource_size(&res));
> +
>  	if (!mem) {
>  		release_mem_region(res.start, resource_size(&res));
>  		return IOMEM_ERR_PTR(-ENOMEM);
> @@ -1094,3 +1104,32 @@ bool of_dma_is_coherent(struct device_node *np)
>  	return false;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/**
> + * of_mmio_is_nonposted - Check if device uses non-posted MMIO
> + * @np:	device node
> + *
> + * Returns true if the "nonposted-mmio" property was found for
> + * the device's bus.
> + *
> + * This is currently only enabled on builds that support Apple ARM devices, as
> + * an optimization.
> + */
> +bool of_mmio_is_nonposted(struct device_node *np)
> +{
> +	struct device_node *parent;
> +	bool nonposted;
> +
> +	if (!IS_ENABLED(CONFIG_ARCH_APPLE))
> +		return false;
> +
> +	parent = of_get_parent(np);
> +	if (!parent)
> +		return false;
> +
> +	nonposted = of_property_read_bool(parent, "nonposted-mmio");
> +
> +	of_node_put(parent);
> +	return nonposted;
> +}
> +EXPORT_SYMBOL_GPL(of_mmio_is_nonposted);

Is this needed outside of of/address.c? If not, please make it static 
and don't export.

With that,

Reviewed-by: Rob Herring <robh at kernel.org>


From danielwa at cisco.com  Tue Apr  6 17:56:10 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Tue, 6 Apr 2021 09:56:10 -0700
Subject: [PATCH v4 00/20] Implement GENERIC_CMDLINE
In-Reply-To: <cover.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <20210406165610.GV2469518@zorba>

On Fri, Apr 02, 2021 at 03:18:01PM +0000, Christophe Leroy wrote:
> The purpose of this series is to improve and enhance the
> handling of kernel boot arguments.
> 
> Current situation is that most if not all architectures are using
> similar options to do some manupulation on command line arguments:
> - Prepend built-in arguments in front of bootloader provided arguments
> - Append built-in arguments after bootloader provided arguments
> - Replace bootloader provided arguments by built-in arguments
> - Use built-in arguments when none is provided by bootloader.
> 
> On some architectures, all the options are possible. On other ones,
> only a subset are available.
> 
> The purpose of this series is to refactor and enhance the
> handling of kernel boot arguments so that every architecture can
> benefit from all possibilities.
> 
> It is first focussed on powerpc but also extends the capability
> for other arches.
> 
> The work has been focussed on minimising the churn in architectures
> by keeping the most commonly used namings.
> 
> Main changes in V4:
> - Included patch from Daniel to replace powerpc's strcpy() by strlcpy()
> - Using strlcpy() instead of zeroing first char + strlcat() (idea taken frm Daniel's series)
> - Reworked the convertion of EFI which was wrong in V3
> - Added "too long" command line handling
> - Changed cmdline macro into a function
> - Done a few fixes in arch (NIOS2, SH, ARM)
> - Taken comments into account (see individual responses for details)
> - Tested on powerpc, build tested on ARM64, X86_64.
> 

Why submit your changes ? My changes have been around for almost 10 years, and
are more widely used. Your changes are very new and unstable, but don't really
solve the needs of people using my series.

I've tried to work with you and I take comments from you, but yet you insist to
submit your own series.

I would suggest this isn't going to go anyplace unless we work together.

I can't really support your changes because, honestly, your changes are really
ugly and they just look more and more like my changes with every passing
iteration .. As the maturity of your changes continue they will just become my
change set.

I've been thru every iteration of these changes, and I see those attempts in
your changes. Everything different in your changes I've tried, and found not to
be useful, then it falls away in later iterations.

When you give me comments on something which I haven't tried I typically
incorporate it.

Daniel


From robh at kernel.org  Tue Apr  6 17:56:45 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 6 Apr 2021 11:56:45 -0500
Subject: [PATCH v4 18/18] arm64: apple: Add initial Apple Mac mini (M1,
 2020) devicetree
In-Reply-To: <20210402090542.131194-19-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-19-marcan@marcan.st>
Message-ID: <20210406165645.GA1942466@robh.at.kernel.org>

On Fri, Apr 02, 2021 at 06:05:42PM +0900, Hector Martin wrote:
> This currently supports:
> 
> * SMP (via spin-tables)
> * AIC IRQs
> * Serial (with earlycon)
> * Framebuffer
> 
> A number of properties are dynamic, and based on system firmware
> decisions that vary from version to version. These are expected
> to be filled in by the loader.
> 
> Signed-off-by: Hector Martin <marcan at marcan.st>
> ---
>  MAINTAINERS                              |   1 +
>  arch/arm64/boot/dts/Makefile             |   1 +
>  arch/arm64/boot/dts/apple/Makefile       |   2 +
>  arch/arm64/boot/dts/apple/t8103-j274.dts |  45 ++++++++
>  arch/arm64/boot/dts/apple/t8103.dtsi     | 135 +++++++++++++++++++++++
>  5 files changed, 184 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/apple/Makefile
>  create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
>  create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi

Reviewed-by: Rob Herring <robh at kernel.org>


From pasha.tatashin at soleen.com  Tue Apr  6 17:58:10 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Tue, 6 Apr 2021 12:58:10 -0400
Subject: [PATCH] arm64/mm: remove useless trans_pgd_map_page()
In-Reply-To: <20210406131420.56262-1-kernelfans@gmail.com>
References: <20210406131420.56262-1-kernelfans@gmail.com>
Message-ID: <CA+CK2bC+irJLOBatFpJJYfZgt6AP5Nu9w3irDVpH-NJ06pGL4g@mail.gmail.com>

Hi Pingfan,

On Tue, Apr 6, 2021 at 9:14 AM Pingfan Liu <kernelfans at gmail.com> wrote:
>
> Since the commit 7018d467ff2d ("arm64: trans_pgd: hibernate: idmap the
> single page that holds the copy page routines"), trans_pgd_map_page() is
> useless.

Let's keep this function for now. This function is used in my version
11 of mmu enabled kexec patches; but not used in version 12 where we
changed to a linear map instead of contiguous map. However, until the
final solution for mmu-enabled kexec lands in the mainline, I think it
is better to keep it.

Thank you,
Pasha


From jim2101024 at gmail.com  Tue Apr  6 17:59:16 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 6 Apr 2021 12:59:16 -0400
Subject: [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 device voltage
 regulators
In-Reply-To: <20210406163439.GL6443@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-4-jim2101024@gmail.com>
 <20210406163439.GL6443@sirena.org.uk>
Message-ID: <CANCKTBvP66su2bXNMbawMfe3T7mpiQsRsG5xLfSPL2BWPNYFyw@mail.gmail.com>

On Tue, Apr 6, 2021 at 12:34 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Thu, Apr 01, 2021 at 05:21:43PM -0400, Jim Quinlan wrote:
>
> > +     /* Look for specific pcie regulators in the RC DT node. */
> > +     for_each_property_of_node(np, pp) {
> > +             for (i = 0; i < ns; i++)
> > +                     if (strcmp(supplies[i], pp->name) == 0)
>
> This is broken, the driver knows which supplies are expected, the device
> can't function without these supplies so the driver should just
> unconditionally request them like any other supply.

Hi  Mark,
Some boards require the regulators, some do not.  So the driver is
only  sure what the names may be if they are present.  If  I put these
names in my struct regulator_bulk_data array and do a
devm_regulator_bulk_get(), I will get the following for the boards
that do not need the regulators (e.g. the RPi SOC):

[    6.823820] brcm-pcie xxx.pcie: supply vpcie12v-supply not found,
using dummy regulator
[    6.832265] brcm-pcie xxx.pcie: supply vpcie3v3-supply not found,
using dummy regulator

IIRC you consider this a debug feature?  Be that as it may, these
lines will confuse our customers and I'd like that they not be printed
if possible.

So I ask you to allow the code as is.  If you still insist, I will
change and resubmit.

Regards,
Jim Quinlan
Broadcom STB


From marcan at marcan.st  Tue Apr  6 17:59:22 2021
From: marcan at marcan.st (Hector Martin)
Date: Wed, 7 Apr 2021 01:59:22 +0900
Subject: [PATCH v4 12/18] of/address: Add infrastructure to declare MMIO
 as non-posted
In-Reply-To: <20210406164748.GA1937719@robh.at.kernel.org>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-13-marcan@marcan.st>
 <20210406164748.GA1937719@robh.at.kernel.org>
Message-ID: <b97eff12-5ace-8f93-99f3-2e391a5492ca@marcan.st>

On 07/04/2021 01.47, Rob Herring wrote:
>> +EXPORT_SYMBOL_GPL(of_mmio_is_nonposted);
> 
> Is this needed outside of of/address.c? If not, please make it static
> and don't export.

Ah, yes, that was cargo culted from of_dma_is_coherent. Not sure how I 
missed that it's obviously unnecessary. Thanks for pointing it out.

> 
> With that,
> 
> Reviewed-by: Rob Herring <robh at kernel.org>

Thanks!

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From ernesto.corona at intel.com  Tue Apr  6 18:00:08 2021
From: ernesto.corona at intel.com (Corona, Ernesto)
Date: Tue, 6 Apr 2021 17:00:08 +0000
Subject: [PATCH v29 0/6] JTAG driver introduction
In-Reply-To: <20210406133420.GY10267@home.paul.comp>
References: <20200413222920.4722-1-ernesto.corona@intel.com>
 <20210115104635.GA2971@home.paul.comp> <YGxgfFBUr6eHJ1Qi@smile.fi.intel.com>
 <20210406133420.GY10267@home.paul.comp>
Message-ID: <DM6PR11MB399360880403A83FFECD597D8B769@DM6PR11MB3993.namprd11.prod.outlook.com>

Hi All,

Paul is right. We already have a v30 and now after Paul's feedback we are doing some changes in preparation for v31.

Regards,

Ernesto

-----Original Message-----
From: Paul Fertser <fercerpav at gmail.com> 
Sent: Tuesday, April 6, 2021 8:34 AM
To: Shevchenko, Andriy <andriy.shevchenko at intel.com>
Cc: Corona, Ernesto <ernesto.corona at intel.com>; linux-aspeed at lists.ozlabs.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-doc at vger.kernel.org
Subject: Re: [PATCH v29 0/6] JTAG driver introduction

Hi Andy, 

On Tue, Apr 06, 2021 at 04:22:04PM +0300, Andy Shevchenko wrote:
> On Fri, Jan 15, 2021 at 01:46:35PM +0300, Paul Fertser wrote:
> > I have to note that the current v29 version of the series is broken 
> > in several aspects:
> 
> Is it correct that this series is actually abandoned so far?

I have an e-mail from Ernesto sent on 10 Feb 2021 stating they're going to continue the work.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com


From samitolvanen at google.com  Tue Apr  6 18:02:56 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Tue, 6 Apr 2021 10:02:56 -0700
Subject: [PATCH v5 12/18] arm64: implement function_nocfi
In-Reply-To: <20210406113657.GC96480@C02TD0UTHF1T.local>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-13-samitolvanen@google.com>
 <20210406113657.GC96480@C02TD0UTHF1T.local>
Message-ID: <CABCJKueabmkC3OXSGHKMKS9wJEeRGHBd3b1hK6fM=mMKkj3b1A@mail.gmail.com>

On Tue, Apr 6, 2021 at 4:37 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Thu, Apr 01, 2021 at 04:32:10PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> > instrumented C code with jump table addresses. This change implements
> > the function_nocfi() macro, which returns the actual function address
> > instead.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> > Reviewed-by: Kees Cook <keescook at chromium.org>
>
> I think that it's unfortunate that we have to drop to assembly here, but
> given this is infrequent I agree it's not the end of the world, so:
>
> Acked-by: Mark Rutland <mark.rutland at arm.com>
>
> > ---
> >  arch/arm64/include/asm/memory.h | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 0aabc3be9a75..b55410afd3d1 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -321,6 +321,21 @@ static inline void *phys_to_virt(phys_addr_t x)
> >  #define virt_to_pfn(x)               __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
> >  #define sym_to_pfn(x)                __phys_to_pfn(__pa_symbol(x))
> >
> > +#ifdef CONFIG_CFI_CLANG
> > +/*
> > + * With CONFIG_CFI_CLANG, the compiler replaces function address
> > + * references with the address of the function's CFI jump table
> > + * entry. The function_nocfi macro always returns the address of the
> > + * actual function instead.
> > + */
> > +#define function_nocfi(x) ({                                         \
> > +     void *addr;                                                     \
> > +     asm("adrp %0, " __stringify(x) "\n\t"                           \
> > +         "add  %0, %0, :lo12:" __stringify(x) : "=r" (addr));        \
>
> If it's not too painful, could we please move the asm constrain onto its
> own line? That makes it slightly easier to read, and aligns with what
> we've (mostly) done elsewhere in arm64.

Sure, I'll change this in the next version.

> Not a big deal either way, and the ack stands regardless.
>
> Thanks,
> Mark.

Sami


From broonie at kernel.org  Tue Apr  6 18:23:21 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 18:23:21 +0100
Subject: [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 device voltage
 regulators
In-Reply-To: <CANCKTBvP66su2bXNMbawMfe3T7mpiQsRsG5xLfSPL2BWPNYFyw@mail.gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-4-jim2101024@gmail.com>
 <20210406163439.GL6443@sirena.org.uk>
 <CANCKTBvP66su2bXNMbawMfe3T7mpiQsRsG5xLfSPL2BWPNYFyw@mail.gmail.com>
Message-ID: <20210406172320.GO6443@sirena.org.uk>

On Tue, Apr 06, 2021 at 12:59:16PM -0400, Jim Quinlan wrote:
> On Tue, Apr 6, 2021 at 12:34 PM Mark Brown <broonie at kernel.org> wrote:
> > On Thu, Apr 01, 2021 at 05:21:43PM -0400, Jim Quinlan wrote:

> > This is broken, the driver knows which supplies are expected, the device
> > can't function without these supplies so the driver should just
> > unconditionally request them like any other supply.

> Some boards require the regulators, some do not.  So the driver is

No, some boards have the supplies described in firmware and some do not.

> only  sure what the names may be if they are present.  If  I put these
> names in my struct regulator_bulk_data array and do a
> devm_regulator_bulk_get(), I will get the following for the boards
> that do not need the regulators (e.g. the RPi SOC):
> 
> [    6.823820] brcm-pcie xxx.pcie: supply vpcie12v-supply not found,
> using dummy regulator
> [    6.832265] brcm-pcie xxx.pcie: supply vpcie3v3-supply not found,
> using dummy regulator

Sure, those are just warnings.

> IIRC you consider this a debug feature?  Be that as it may, these
> lines will confuse our customers and I'd like that they not be printed
> if possible.

You can stop the warnings by updating your firmware to more completely
describe the system - ideally all the supplies in the system would be
described for future proofing.  Or if this is a custom software stack
just delete whatever error checking and warnings you like.  The warnings
are there in case we've not got something mapped properly (eg, if there
were a typo in a property name) and things stop working, it's not great
to just ignore errors.

> So I ask you to allow the code as is.  If you still insist, I will
> change and resubmit.

Remove it, conditional code like this is just as bad in this driver as
it is in every other one.
-------------- 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/20210406/6cf525cd/attachment-0001.sig>

From jim2101024 at gmail.com  Tue Apr  6 18:26:51 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 6 Apr 2021 13:26:51 -0400
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210406164708.GM6443@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
Message-ID: <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>

On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Thu, Apr 01, 2021 at 05:21:42PM -0400, Jim Quinlan wrote:
> > Similar to the regulator bindings found in "rockchip-pcie-host.txt", this
> > allows optional regulators to be attached and controlled by the PCIe RC
> > driver.  That being said, this driver searches in the DT subnode (the EP
> > node, eg pci at 0,0) for the regulator property.
>
> > The use of a regulator property in the pcie EP subnode such as
> > "vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml
> > file at
> >
> > https://github.com/devicetree-org/dt-schema/pull/54
> >
> > Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
> > ---
> >  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index f90557f6deb8..f2caa5b3b281 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -64,6 +64,9 @@ properties:
> >
> >    aspm-no-l0s: true
> >
> > +  vpcie12v-supply: true
> > +  vpcie3v3-supply: true
> > +
>
> No great problem with having these in the controller node (assming it
> accurately describes the hardware) but I do think we ought to also be
> able to describe these per slot.

Hi Mark,
Can you explain what you think that would look like in the DT?
Thanks,
Jim Quinlan
Broadcom STB


From jim2101024 at gmail.com  Tue Apr  6 18:29:40 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 6 Apr 2021 13:29:40 -0400
Subject: [PATCH v4 3/6] PCI: brcmstb: Add control of slot0 device voltage
 regulators
In-Reply-To: <20210406172320.GO6443@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-4-jim2101024@gmail.com>
 <20210406163439.GL6443@sirena.org.uk>
 <CANCKTBvP66su2bXNMbawMfe3T7mpiQsRsG5xLfSPL2BWPNYFyw@mail.gmail.com>
 <20210406172320.GO6443@sirena.org.uk>
Message-ID: <CANCKTBvptjpNLyN-mZqynF=Af_X0X+OVasL==thQKzzBZ5r4yw@mail.gmail.com>

On Tue, Apr 6, 2021 at 1:23 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Tue, Apr 06, 2021 at 12:59:16PM -0400, Jim Quinlan wrote:
> > On Tue, Apr 6, 2021 at 12:34 PM Mark Brown <broonie at kernel.org> wrote:
> > > On Thu, Apr 01, 2021 at 05:21:43PM -0400, Jim Quinlan wrote:
>
> > > This is broken, the driver knows which supplies are expected, the device
> > > can't function without these supplies so the driver should just
> > > unconditionally request them like any other supply.
>
> > Some boards require the regulators, some do not.  So the driver is
>
> No, some boards have the supplies described in firmware and some do not.
True.
>
> > only  sure what the names may be if they are present.  If  I put these
> > names in my struct regulator_bulk_data array and do a
> > devm_regulator_bulk_get(), I will get the following for the boards
> > that do not need the regulators (e.g. the RPi SOC):
> >
> > [    6.823820] brcm-pcie xxx.pcie: supply vpcie12v-supply not found,
> > using dummy regulator
> > [    6.832265] brcm-pcie xxx.pcie: supply vpcie3v3-supply not found,
> > using dummy regulator
>
> Sure, those are just warnings.
>
> > IIRC you consider this a debug feature?  Be that as it may, these
> > lines will confuse our customers and I'd like that they not be printed
> > if possible.
>
> You can stop the warnings by updating your firmware to more completely
> describe the system - ideally all the supplies in the system would be
> described for future proofing.  Or if this is a custom software stack
> just delete whatever error checking and warnings you like.  The warnings
> are there in case we've not got something mapped properly (eg, if there
> were a typo in a property name) and things stop working, it's not great
> to just ignore errors.
A lot of this is really not under our control.
>
> > So I ask you to allow the code as is.  If you still insist, I will
> > change and resubmit.
>
> Remove it, conditional code like this is just as bad in this driver as
> it is in every other one.
I will remove this and resubmit.
Thanks,
Jim Quinlan
Broadcom STB


From broonie at kernel.org  Tue Apr  6 18:32:11 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 6 Apr 2021 18:32:11 +0100
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
Message-ID: <20210406173211.GP6443@sirena.org.uk>

On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:

> > No great problem with having these in the controller node (assming it
> > accurately describes the hardware) but I do think we ought to also be
> > able to describe these per slot.

> Can you explain what you think that would look like in the DT?

I *think* that's just some properties on the nodes for the endpoints,
note that the driver could just ignore them for now.  Not sure where or
if we document any extensions but child nodes are in section 4 of the
v2.1 PCI bus binding.
-------------- 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/20210406/b93cfbeb/attachment.sig>

From mirela.rabulea at oss.nxp.com  Tue Apr  6 18:34:28 2021
From: mirela.rabulea at oss.nxp.com (Mirela Rabulea (OSS))
Date: Tue,  6 Apr 2021 20:34:28 +0300
Subject: [PATCH] media: imx-jpeg: Fix double free in mxc_jpeg_remove
Message-ID: <20210406173428.19283-1-mirela.rabulea@oss.nxp.com>

From: Mirela Rabulea <mirela.rabulea at nxp.com>

The video_unregister_device already calls video_device_release,
so remove video_device_release, to avoid a double free, when removing
the module. This showed up in a repeated rmmod/insmod scenario.

Signed-off-by: Mirela Rabulea <mirela.rabulea at nxp.com>
---
 drivers/media/platform/imx-jpeg/mxc-jpeg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/imx-jpeg/mxc-jpeg.c
index 2d29558f1864..ca1b7e8c65f4 100644
--- a/drivers/media/platform/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/imx-jpeg/mxc-jpeg.c
@@ -2099,7 +2099,6 @@ static int mxc_jpeg_remove(struct platform_device *pdev)
 		mxc_jpeg_free_slot_data(jpeg, slot);
 
 	video_unregister_device(jpeg->dec_vdev);
-	video_device_release(jpeg->dec_vdev);
 	v4l2_m2m_release(jpeg->m2m_dev);
 	v4l2_device_unregister(&jpeg->v4l2_dev);
 	mxc_jpeg_detach_pm_domains(jpeg);
-- 
2.17.1



From danielwa at cisco.com  Tue Apr  6 18:38:36 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Tue, 6 Apr 2021 10:38:36 -0700
Subject: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
In-Reply-To: <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <20210406173836.GW2469518@zorba>

On Fri, Apr 02, 2021 at 03:18:21PM +0000, Christophe Leroy wrote:
> -config CMDLINE_BOOL
> -	bool "Built-in kernel command line"
> -	help
> -	  For most systems, it is firmware or second stage bootloader that
> -	  by default specifies the kernel command line options.  However,
> -	  it might be necessary or advantageous to either override the
> -	  default kernel command line or add a few extra options to it.
> -	  For such cases, this option allows you to hardcode your own
> -	  command line options directly into the kernel.  For that, you
> -	  should choose 'Y' here, and fill in the extra boot arguments
> -	  in CONFIG_CMDLINE.
> -
> -	  The built-in options will be concatenated to the default command
> -	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
> -	  command line will be ignored and replaced by the built-in string.
> -
> -	  Most MIPS systems will normally expect 'N' here and rely upon
> -	  the command line from the firmware or the second-stage bootloader.
> -


See how you complained that I have CMDLINE_BOOL in my changed, and you think it
shouldn't exist.

Yet here mips has it, and you just deleted it with no feature parity in your
changes for this.

In my changes I tried to maintain as much feature parity as I could with the
architectures. I did the same huge conversion a long time ago you've done here to be sure all
platforms have the features needed.

Daniel


From samitolvanen at google.com  Tue Apr  6 18:43:50 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Tue, 6 Apr 2021 10:43:50 -0700
Subject: [PATCH v5 14/18] arm64: add __nocfi to functions that jump to a
 physical address
In-Reply-To: <20210406115357.GE96480@C02TD0UTHF1T.local>
References: <20210401233216.2540591-1-samitolvanen@google.com>
 <20210401233216.2540591-15-samitolvanen@google.com>
 <20210406115357.GE96480@C02TD0UTHF1T.local>
Message-ID: <CABCJKuchDg74Md_He1nKgXKUf=pVEmiaVr_yJXB_yX+tKNhByA@mail.gmail.com>

On Tue, Apr 6, 2021 at 4:54 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> [adding Ard for EFI runtime services bits]
>
> On Thu, Apr 01, 2021 at 04:32:12PM -0700, Sami Tolvanen wrote:
> > Disable CFI checking for functions that switch to linear mapping and
> > make an indirect call to a physical address, since the compiler only
> > understands virtual addresses and the CFI check for such indirect calls
> > would always fail.
>
> What does physical vs virtual have to do with this? Does the address
> actually matter, or is this just a general thing that when calling an
> assembly function we won't have a trampoline that the caller expects?

No, this is about the actual address. The compiler-generated runtime
checks only know about EL1 virtual addresses, so if we switch to a
different address space, all indirect calls will trip CFI.

> I wonder if we need to do something with asmlinkage here, perhaps?
>
> I didn't spot anything in the seriues handling EFI runtime services
> calls, and I strongly suspect we need to do something for those, unless
> they're handled implicitly by something else.
>
> > Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
> > Reviewed-by: Kees Cook <keescook at chromium.org>
> > ---
> >  arch/arm64/include/asm/mmu_context.h | 2 +-
> >  arch/arm64/kernel/cpu-reset.h        | 8 ++++----
> >  arch/arm64/kernel/cpufeature.c       | 2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> >https://www.cnbc.com/2021/04/06/donald-trump-save-america-pac-has-85-million-on-hand-ahead-of-midterms.html
> > diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> > index 386b96400a57..d3cef9133539 100644
> > --- a/arch/arm64/include/asm/mmu_context.h
> > +++ b/arch/arm64/include/asm/mmu_context.h
> > @@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void)
> >   * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
> >   * avoiding the possibility of conflicting TLB entries being allocated.
> >   */
> > -static inline void cpu_replace_ttbr1(pgd_t *pgdp)
> > +static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
>
> Given these are inlines, what's the effect when these are inlined into a
> function that would normally use CFI? Does CFI get supressed for the
> whole function, or just the bit that got inlined?

Just for the bit that gets inlined.

> Is there an attribute that we could place on a function pointer to tell
> the compiler to not check calls via that pointer? If that existed we'd
> be able to scope this much more tightly.

There isn't, but I do agree that this would be a useful feature.

Sami


From asutoshd at codeaurora.org  Tue Apr  6 18:52:41 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Tue,  6 Apr 2021 10:52:41 -0700
Subject: [PATCH v15 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1617731442.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing

Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   2 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  30 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 636 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 519 insertions(+), 241 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Tue Apr  6 18:52:42 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Tue,  6 Apr 2021 10:52:42 -0700
Subject: [PATCH v15 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1617731442.git.asutoshd@codeaurora.org>
References: <cover.1617731442.git.asutoshd@codeaurora.org>
Message-ID: <5536f19fbbcfed1177a63458c6bd0b42ee6aa2e2.1617731442.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   2 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 636 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 502 insertions(+), 228 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..b9105e4 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..8ffbd4a 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..49a918c 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..d463b44 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..cbb5a90 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			scsi_autopm_put_device(hba->sdev_ufs_device);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 58d7f26..2aeb15a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4099,11 +4113,11 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
 	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		scsi_autopm_put_device(hba->sdev_ufs_device);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4815,40 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+			return;
+		}
+	} else {
+		/* device wlun is probed */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4879,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4912,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5034,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5635,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 }
 
 /**
@@ -5604,7 +5653,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5669,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5793,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5835,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5856,14 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7249,7 +7290,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7413,6 +7453,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7890,6 +7933,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8475,7 +8519,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8650,23 +8695,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8674,7 +8703,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8697,17 +8726,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto enable_scaling;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8719,7 +8748,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8747,7 +8776,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8760,7 +8789,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8769,28 +8797,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8812,57 +8821,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
-
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8871,7 +8855,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8919,31 +8903,152 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
-	if (ufshcd_is_clkscaling_supported(hba))
-		ufshcd_clk_scaling_suspend(hba, false);
-
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
+	if (hba->clk_scaling.is_allowed)
+		ufshcd_resume_clkscaling(hba);
 
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	if (pm_runtime_suspended(dev))
+		return 0;
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	scsi_autopm_get_device(sdev);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static void ufshcd_suspend(struct ufs_hba *hba)
+{
+	hba->pm_op_in_progress = 1;
+
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
 	ufshcd_setup_clocks(hba, false);
 	if (ufshcd_is_clkgating_allowed(hba)) {
@@ -8951,6 +9056,43 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	hba->pm_op_in_progress = 0;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	hba->pm_op_in_progress = 1;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
@@ -8965,6 +9107,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8985,21 +9128,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	     !hba->dev_info.b_rpm_dev_flush_capable)
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
@@ -9021,25 +9150,20 @@ EXPORT_SYMBOL(ufshcd_system_suspend);
 
 int ufshcd_system_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_system_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
+
+	hba->is_sys_suspended = false;
 	up(&hba->host_sem);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
 
@@ -9048,23 +9172,23 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
+		ufshcd_suspend(hba);
 out:
-	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_suspend(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_suspend);
 
@@ -9072,37 +9196,25 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_resume);
 
@@ -9116,18 +9228,13 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
 	if (!hba->is_powered)
 		goto out;
 
@@ -9136,10 +9243,8 @@ int ufshcd_shutdown(struct ufs_hba *hba)
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9153,6 +9258,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9456,15 +9563,172 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	pm_runtime_put_noidle(&hba->sdev_ufs_device->sdev_gendev);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * Force it to honor system-suspend.
+	 */
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	/* Refer ufshcd_resume_complete() */
+	pm_runtime_get_noresume(&hba->sdev_ufs_device->sdev_gendev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	ufshcd_wl_shutdown(dev);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		return ret;
+	}
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+		return ret;
+	}
 	return 0;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..40436e3 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From mathieu.poirier at linaro.org  Tue Apr  6 18:58:07 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 6 Apr 2021 11:58:07 -0600
Subject: [GIT PULL] coresight: Add support for ETE and TRBE
In-Reply-To: <87o8erq0u2.wl-maz@kernel.org>
References: <20210405191757.283122-1-mathieu.poirier@linaro.org>
 <87o8erq0u2.wl-maz@kernel.org>
Message-ID: <CANLsYkwijvqGv-EdSSC-F727LczXS0gjBbY-YwJ-0OZkKGTZsg@mail.gmail.com>

On Tue, 6 Apr 2021 at 02:22, Marc Zyngier <maz at kernel.org> wrote:
>
> Hi Mathieu,
>
> On Mon, 05 Apr 2021 20:17:57 +0100,
> Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> >
> > The following changes since commit a354a64d91eec3e0f8ef0eed575b480fd75b999c:
> >
> >   KVM: arm64: Disable guest access to trace filter controls (2021-03-24 17:26:38 +0000)
> >
> > are available in the Git repository at:
> >
> >   git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE
> >
> > for you to fetch changes up to 7885b4e43231048654c5a80c0a18844ce3185e64:
> >
> >   dts: bindings: Document device tree bindings for Arm TRBE (2021-04-05 11:38:04 -0600)
> >
> > ----------------------------------------------------------------
> > Hi Marc,
> >
> > As previously agreed, here are the changes to support CoreSight
> > ETE and TRBE components submitted here[1].
> >
> > I draw your attention to these:
> >
> > [PATCH v6 05/20] kvm: arm64: Handle access to TRFCR_EL1
> > [PATCH v6 06/20] kvm: arm64: Move SPE availability check to VCPU load
> > [PATCH v6 07/20] arm64: kvm: Enable access to TRBE support for host
> >
> > They are KVM specific and will need an SoB tag.
>
> There seem to be a disconnect here, because it works the other way
> around.
>
> If I pull this, I obviously cannot add anything to the patches that
> are merged (changing stuff would result in changing the commit IDs,
> which is exactly the opposite of what we are trying to achieve).
>
> This isn't a problem, as the act of pulling the branch means that I am
> happy with that, and the git merge makes it traceable.
>
> However, some of the patches (the KVM ones) do not carry your own SoB,
> which is a problem (if you are picking stuff off the list, you need to
> add your own SoB). So for the couple of KVM patches, please add my
>

I wasn't clear on how to handle the KVM patches and as such decided to
proceed conservatively...

>         Acked-by: Marc Zyngier <maz at kernel.org>
>
> together with your SoB, resend the PR and I'll gladly merge it.
>

And I didn't want to SoB those patches because I am not in a position
to cast judgement on them, but with your Ack it changes everything.

> And if you can make sure the subject lines are formatted as:
>
>         "KVM: arm64: Super Duper feature enablement"

No problem.

>
> that'd be absolutely awesome (but that's just me being annoying...).
>

I'll do a respin of this in a couple hours.

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


From stefan.wahren at i2se.com  Tue Apr  6 18:59:02 2021
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 6 Apr 2021 19:59:02 +0200
Subject: [PATCH 2/3] mmc: sdhci-iproc: Cap min clock frequency on BCM2711
In-Reply-To: <20210406104802.20898-3-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
 <20210406104802.20898-3-nsaenz@kernel.org>
Message-ID: <2d40b062-5809-15ce-b9d1-651644ff6e22@i2se.com>

Hi Nicolas,

Am 06.04.21 um 12:48 schrieb Nicolas Saenz Julienne:
> There is a known bug on BCM2711's SDHCI core integration where the
> controller will hang when the difference between the core clock and the
> bus clock is too great. Specifically this can be reproduced under the
> following conditions:
>
> - No SD card plugged in, polling thread is running, probing cards at
>   100KHz.
> - BCM2711's core clock configured at 500MHz or more.
>
> So set 200MHz as the minimum clock frequency available for that board.
i think it should be 200 kHz?
>
> For more information on the issue see this:
> https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz at kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca
>
> Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
> Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> ---
>  drivers/mmc/host/sdhci-iproc.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index ddeaf8e1f72f..1ef888e91f73 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -173,6 +173,23 @@ static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host)
>  		return pltfm_host->clock;
>  }
>  
> +/*
> + * There is a known bug on BCM2711's SDHCI core integration where the
> + * controller will hang when the difference between the core clock and the bus
> + * clock is too great. Specifically this can be reproduced under the following
> + * conditions:
> + *
> + *  - No SD card plugged in, polling thread is running, probing cards at
> + *    100KHz.
> + *  - BCM2711's core clock configured at 500MHz or more
> + *
> + * So we set 200MHz as the minimum clock frequency available for that SoC.
> + */
> +static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host *host)
> +{
> +	return 200000;
> +}
> +
>  static const struct sdhci_ops sdhci_iproc_ops = {
>  	.set_clock = sdhci_set_clock,
>  	.get_max_clock = sdhci_iproc_get_max_clock,
> @@ -271,6 +288,7 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
>  	.set_clock = sdhci_set_clock,
>  	.set_power = sdhci_set_power_and_bus_voltage,
>  	.get_max_clock = sdhci_iproc_get_max_clock,
> +	.get_min_clock = sdhci_iproc_bcm2711_get_min_clock,
>  	.set_bus_width = sdhci_set_bus_width,
>  	.reset = sdhci_reset,
>  	.set_uhs_signaling = sdhci_set_uhs_signaling,


From marex at denx.de  Tue Apr  6 19:00:35 2021
From: marex at denx.de (Marek Vasut)
Date: Tue,  6 Apr 2021 20:00:35 +0200
Subject: [PATCH] pinctrl: stm32: Print invalid AF warning inside
 stm32_pctrl_is_function_valid()
Message-ID: <20210406180035.279249-1-marex@denx.de>

The "invalid function %d on pin %d .\n" message is triplicated in the
driver in different variants, just pull it into the function and have
it once in the driver. The bonus is that all variants of the message
now print the pin number and AF consistently, so it is easier to debug
such pinmux problems.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Fabien Dessenne <fabien.dessenne at st.com>
Cc: Alexandre Torgue <alexandre.torgue at st.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index da72e3e5c08d..ad9eb5ed8e81 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -531,6 +531,8 @@ static bool stm32_pctrl_is_function_valid(struct stm32_pinctrl *pctl,
 		break;
 	}
 
+	dev_err(pctl->dev, "invalid function %d on pin %d .\n", fnum, pin_num);
+
 	return false;
 }
 
@@ -545,11 +547,8 @@ static int stm32_pctrl_dt_node_to_map_func(struct stm32_pinctrl *pctl,
 	(*map)[*num_maps].type = PIN_MAP_TYPE_MUX_GROUP;
 	(*map)[*num_maps].data.mux.group = grp->name;
 
-	if (!stm32_pctrl_is_function_valid(pctl, pin, fnum)) {
-		dev_err(pctl->dev, "invalid function %d on pin %d .\n",
-				fnum, pin);
+	if (!stm32_pctrl_is_function_valid(pctl, pin, fnum))
 		return -EINVAL;
-	}
 
 	(*map)[*num_maps].data.mux.function = stm32_gpio_functions[fnum];
 	(*num_maps)++;
@@ -620,7 +619,6 @@ static int stm32_pctrl_dt_subnode_to_map(struct pinctrl_dev *pctldev,
 		func = STM32_GET_PIN_FUNC(pinfunc);
 
 		if (!stm32_pctrl_is_function_valid(pctl, pin, func)) {
-			dev_err(pctl->dev, "invalid function.\n");
 			err = -EINVAL;
 			goto exit;
 		}
@@ -821,11 +819,8 @@ static int stm32_pmx_set_mux(struct pinctrl_dev *pctldev,
 	int pin;
 
 	ret = stm32_pctrl_is_function_valid(pctl, g->pin, function);
-	if (!ret) {
-		dev_err(pctl->dev, "invalid function %d on group %d .\n",
-				function, group);
+	if (!ret)
 		return -EINVAL;
-	}
 
 	range = pinctrl_find_gpio_range_from_pin(pctldev, g->pin);
 	if (!range) {
-- 
2.30.2



From maz at kernel.org  Tue Apr  6 19:16:18 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 06 Apr 2021 19:16:18 +0100
Subject: [PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <20210402090542.131194-16-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-16-marcan@marcan.st>
Message-ID: <87ft03p9cd.wl-maz@kernel.org>

Hi Hector,

On Fri, 02 Apr 2021 10:05:39 +0100,
Hector Martin <marcan at marcan.st> wrote:
> 
> This is the root interrupt controller used on Apple ARM SoCs such as the
> M1. This irqchip driver performs multiple functions:
> 
> * Handles both IRQs and FIQs
> 
> * Drives the AIC peripheral itself (which handles IRQs)
> 
> * Dispatches FIQs to downstream hard-wired clients (currently the ARM
>   timer).
> 
> * Implements a virtual IPI multiplexer to funnel multiple Linux IPIs
>   into a single hardware IPI
> 
> Signed-off-by: Hector Martin <marcan at marcan.st>
> ---
>  MAINTAINERS                     |   2 +
>  drivers/irqchip/Kconfig         |   8 +
>  drivers/irqchip/Makefile        |   1 +
>  drivers/irqchip/irq-apple-aic.c | 837 ++++++++++++++++++++++++++++++++
>  include/linux/cpuhotplug.h      |   1 +
>  5 files changed, 849 insertions(+)
>  create mode 100644 drivers/irqchip/irq-apple-aic.c

[...]

> +static int aic_irq_domain_translate(struct irq_domain *id,
> +				    struct irq_fwspec *fwspec,
> +				    unsigned long *hwirq,
> +				    unsigned int *type)
> +{
> +	struct aic_irq_chip *ic = id->host_data;
> +
> +	if (fwspec->param_count != 3 || !is_of_node(fwspec->fwnode))
> +		return -EINVAL;
> +
> +	switch (fwspec->param[0]) {
> +	case AIC_IRQ:
> +		if (fwspec->param[1] >= ic->nr_hw)
> +			return -EINVAL;
> +		*hwirq = fwspec->param[1];
> +		break;
> +	case AIC_FIQ:
> +		if (fwspec->param[1] >= AIC_NR_FIQ)
> +			return -EINVAL;
> +		*hwirq = ic->nr_hw + fwspec->param[1];
> +
> +		/*
> +		 * In EL1 the non-redirected registers are the guest's,
> +		 * not EL2's, so remap the hwirqs to match.
> +		 */
> +		if (!is_kernel_in_hyp_mode()) {
> +			switch (fwspec->param[1]) {
> +			case AIC_TMR_GUEST_PHYS:
> +				*hwirq = ic->nr_hw + AIC_TMR_HV_PHYS;
> +				break;
> +			case AIC_TMR_GUEST_VIRT:
> +				*hwirq = ic->nr_hw + AIC_TMR_HV_VIRT;
> +				break;
> +			case AIC_TMR_HV_PHYS:
> +			case AIC_TMR_HV_VIRT:
> +				return -ENOENT;
> +			default:
> +				break;
> +			}
> +		}

Urgh, this is nasty. You are internally remapping the hwirq from one
timer to another in order to avoid accessing the enable register
which happens to be an EL2 only register?

The way we normally deal with this kind of things is by providing a
different set of irq_chip callbacks. In this particular case, this
would leave mask/unmask as empty stubs. Or you could move the FIQ
handling to use handle_simple_irq(), because there isn't any callback
that is actually applicable.

It isn't a big deal for now, but that's something we should consider
addressing in the future. With that in mind:

Reviewed-by: Marc Zyngier <maz at kernel.org>

Thanks,

	M.

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


From dinguyen at kernel.org  Tue Apr  6 19:17:13 2021
From: dinguyen at kernel.org (Dinh Nguyen)
Date: Tue, 6 Apr 2021 13:17:13 -0500
Subject: [PATCH v3 01/15] clk: socfpga: allow building N5X clocks with
 ARCH_N5X
In-Reply-To: <161724074854.2260335.2479133227977254546@swboyd.mtv.corp.google.com>
References: <20210311152545.1317581-1-krzysztof.kozlowski@canonical.com>
 <20210311152545.1317581-2-krzysztof.kozlowski@canonical.com>
 <161724074854.2260335.2479133227977254546@swboyd.mtv.corp.google.com>
Message-ID: <c4998896-0339-d03d-0902-ea4725f7688c@kernel.org>



On 3/31/21 8:32 PM, Stephen Boyd wrote:
> Quoting Krzysztof Kozlowski (2021-03-11 07:25:31)
>> The Intel's eASIC N5X (ARCH_N5X) architecture shares a lot with Agilex
>> (ARCH_AGILEX) so it uses the same socfpga_agilex.dtsi, with minor
>> changes.  Also the clock drivers are the same.
>>
>> However the clock drivers won't be build without ARCH_AGILEX.  One could
>> assume that ARCH_N5X simply depends on ARCH_AGILEX but this was not
>> modeled in Kconfig.  In current stage the ARCH_N5X is simply
>> unbootable.
>>
>> Add a separate Kconfig entry for clocks used by both ARCH_N5X and
>> ARCH_AGILEX so the necessary objects will be built if either of them is
>> selected.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
>> ---
> 
> Acked-by: Stephen Boyd <sboyd at kernel.org>
> 
> FYI, Dinh sent some patches to change socfpga code to use clk_hw so it
> may conflict.
> 

I just checked, no conflicts.

Thanks
Dinh


From jim2101024 at gmail.com  Tue Apr  6 19:25:49 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 6 Apr 2021 14:25:49 -0400
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210406173211.GP6443@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
Message-ID: <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>

On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:
>
> > > No great problem with having these in the controller node (assming it
> > > accurately describes the hardware) but I do think we ought to also be
> > > able to describe these per slot.
>
> > Can you explain what you think that would look like in the DT?
>
> I *think* that's just some properties on the nodes for the endpoints,
> note that the driver could just ignore them for now.  Not sure where or
> if we document any extensions but child nodes are in section 4 of the
> v2.1 PCI bus binding.

Hi Mark,

I'm a little confused -- here is how I remember the chronology of the
"DT bindings" commit reviews, please correct me if I'm wrong:

o JimQ submitted a pullreq for using voltage regulators in the same
style as the existing "rockport" PCIe driver.
o After some deliberation, RobH preferred that the voltage regulators
should go into the PCIe subnode device's DT node.
o JimQ put the voltage regulators in the subnode device's DT node.
o MarkB didn't like the fact that the code did a global search for the
regulator since it could not provide the owning struct device* handle.
o RobH relented, and said that if it is just two specific and standard
voltage regulators, perhaps they can go in the parent DT node after
all.
o JimQ put the regulators back in the PCIe node.
o MarkB now wants the regulators to go back into the child node again?

Folks, please advise.

Regards,
Jim Quinlan
Broadcom STB


From jbx6244 at gmail.com  Tue Apr  6 20:04:29 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 6 Apr 2021 21:04:29 +0200
Subject: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210406155053.29101-1-jbx6244@gmail.com>
References: <20210406155053.29101-1-jbx6244@gmail.com>
Message-ID: <8f05dc0d-8fb7-c200-5251-d9e147b1d00d@gmail.com>

Hi,

Question for Heiko:
rv1108.dtsi and rk3328.dtsi have a undocumented "interrupts" property
AFAICT without driver support.
Please advise what to do with it.


See build log:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210406155053.29101-1-jbx6244 at gmail.com/

====

Question for Rob:
It looks like that recent "improvements" with regard to checking for
undocumented compatible strings make it almost impossible to do any
useful dt_checking, let alone for the average user. Maybe reduce the
notification blurb output a bit for things that have nothing to do with
this document. Unable to fall back to previous versions for older kernels.

pip3 install git+https://github.com/devicetree-org/dt-schema.git at master
--upgrade

make ARCH=arm dtbs_check
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

make ARCH=arm64 dtbs_check
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml


On 4/6/21 5:50 PM, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 ---------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 66 ++++++++++++++++++++++
>  2 files changed, 66 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> deleted file mode 100644
> index f70956dea..000000000
> --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -Rockchip PWM controller
> -
> -Required properties:
> - - compatible: should be "rockchip,<name>-pwm"
> -   "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
> -   "rockchip,rk3288-pwm": found on RK3288 SOC
> -   "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
> -   "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
> - - reg: physical base address and length of the controller's registers
> - - clocks: See ../clock/clock-bindings.txt
> -   - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
> -     - There is one clock that's used both to derive the functional clock
> -       for the device and as the bus clock.
> -   - For newer hardware (rk3328 and future socs): specified by name
> -     - "pwm": This is used to derive the functional clock.
> -     - "pclk": This is the APB bus clock.
> - - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this directory
> -   for a description of the cell format.
> -
> -Example:
> -
> -	pwm0: pwm at 20030000 {
> -		compatible = "rockchip,rk2928-pwm";
> -		reg = <0x20030000 0x10>;
> -		clocks = <&cru PCLK_PWM01>;
> -		#pwm-cells = <2>;
> -	};
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> new file mode 100644
> index 000000000..cfd637d3e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PWM controller
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: rockchip,rk2928-pwm
> +      - const: rockchip,rk3288-pwm
> +      - const: rockchip,vop-pwm
> +      - items:
> +          - enum:
> +              - rockchip,rv1108-pwm
> +          - const: rockchip,rk3288-pwm
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 2
> +    description:
> +      For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399)
> +        There is one clock that is used both to derive the functional clock
> +        for the device and as the bus clock.
> +      For newer hardware (rk3328 and future SoCs) that is also specified
> +      with clock names.
> +        "pwm" is used to derive the functional clock for the device.
> +        "pclk" is used as the APB bus clock.
> +
> +  clock-names:
> +    minItems: 1
> +    items:
> +      - const: pwm
> +      - const: pclk
> +
> +  "#pwm-cells":
> +    enum: [2, 3]
> +    description:
> +      Must be 2 (rk2928) or 3 (rk3288).
> +      See pwm.yaml for a description of the cell format.
> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - "#pwm-cells"
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3188-cru-common.h>
> +    pwm0: pwm at 20030000 {
> +      compatible = "rockchip,rk2928-pwm";
> +      reg = <0x20030000 0x10>;
> +      clocks = <&cru PCLK_PWM01>;
> +      #pwm-cells = <2>;
> +    };
> 



From marcan at marcan.st  Tue Apr  6 20:21:46 2021
From: marcan at marcan.st (Hector Martin)
Date: Wed, 7 Apr 2021 04:21:46 +0900
Subject: [PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <87ft03p9cd.wl-maz@kernel.org>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-16-marcan@marcan.st> <87ft03p9cd.wl-maz@kernel.org>
Message-ID: <5a4a0ab4-5a4e-1f1c-f6c6-97439b95e7ee@marcan.st>

On 07/04/2021 03.16, Marc Zyngier wrote:
> Hi Hector,
> 
> On Fri, 02 Apr 2021 10:05:39 +0100,
> Hector Martin <marcan at marcan.st> wrote:
>> +		/*
>> +		 * In EL1 the non-redirected registers are the guest's,
>> +		 * not EL2's, so remap the hwirqs to match.
>> +		 */
>> +		if (!is_kernel_in_hyp_mode()) {
>> +			switch (fwspec->param[1]) {
>> +			case AIC_TMR_GUEST_PHYS:
>> +				*hwirq = ic->nr_hw + AIC_TMR_HV_PHYS;
>> +				break;
>> +			case AIC_TMR_GUEST_VIRT:
>> +				*hwirq = ic->nr_hw + AIC_TMR_HV_VIRT;
>> +				break;
>> +			case AIC_TMR_HV_PHYS:
>> +			case AIC_TMR_HV_VIRT:
>> +				return -ENOENT;
>> +			default:
>> +				break;
>> +			}
>> +		}
> 
> Urgh, this is nasty. You are internally remapping the hwirq from one
> timer to another in order to avoid accessing the enable register
> which happens to be an EL2 only register?

The remapping is to make the IRQs route properly at all.

There are EL2 and EL0 timers, and on GIC each timer goes to its own IRQ. 
But here there are no real IRQs, everything's a FIQ. However, thanks to 
VHE, the EL2 timer shows up as the EL0 timer, and the EL0 timer is 
accessed via EL02 registers, when in EL2. So in EL2/VHE mode, "HV" means 
EL0 and "guest" means EL02, while in EL1, there is no HV and "guest" 
means EL0. And since we figure out which IRQ fired by reading timer 
registers, this is what matters. So I map the guest IRQs to the HV 
hwirqs in EL1 mode, which makes this all work out. Then the timer code 
goes and ends up undoing all this logic again, so we map to separate 
fake "IRQs" only to end up right back at using the same timer registers 
anuway :-)

Really, the ugliness here is that the constant meaning is overloaded. In 
fwspec context they mean what they say on the tin, while in hwirq 
context "HV" means EL0 and "guest" means EL02 (other FIQs would be 
passed through unchanged). Perhaps some additional defines might help 
clarify this? Say, at the top of this file (not in the binding),

/*
  * Pass-through mapping from real timers to the correct registers to
  * access them in EL2/VHE mode. When running in EL1, this gets
  * overridden to access the guest timer using EL0 registers.
  */
#define AIC_TMR_EL0_PHYS AIC_TMR_HV_PHYS
#define AIC_TMR_EL0_VIRT AIC_TMR_HV_VIRT
#define AIC_TMR_EL02_PHYS AIC_TMR_GUEST_PHYS
#define AIC_TMR_EL02_VIRT AIC_TMR_GUEST_VIRT

Then the irqchip/FIQ dispatch side can use the EL* constants, the 
default pass-through mapping is appropriate for VHE/EL2 mode, and 
translation can adjust it for EL1 mode.

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From wsa at the-dreams.de  Tue Apr  6 20:48:56 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 6 Apr 2021 21:48:56 +0200
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
Message-ID: <20210406194856.GF3122@kunai>

On Sat, Mar 13, 2021 at 04:04:24PM +0800, qii.wang at mediatek.com wrote:
> From: Qii Wang <qii.wang at mediatek.com>
> 
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the spec via EXT_CONF register.
> 
> Signed-off-by: Qii Wang <qii.wang at mediatek.com>

I tried to understand from the code what the new binding expresses, but
I don't fully understand it. Is it the maximum clock stretch time?
Because I cannot recall a device which always uses the same delay for
clock stretching.

-------------- 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/20210406/0494fb0f/attachment-0001.sig>

From andrew at lunn.ch  Tue Apr  6 21:06:15 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 6 Apr 2021 22:06:15 +0200
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
 <YGsgHWItHcLFV9Kg@lunn.ch>
 <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
Message-ID: <YGy/N+cRLGTifJSN@lunn.ch>

> The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
> overclocking of 2.5 times clock rate to support 2.5G is only able to be
> configured in the BIOS during boot time. Kernel driver has no access to 
> modify the clock rate for 1Gbps/2.5G mode. The way to determined the 
> current 1G/2.5G mode is by reading a dedicated adhoc register through mdio bus.
> In short, after the system boot up, it is either in 1G mode or 2.5G mode 
> which not able to be changed on the fly. 

Right. It would of been a lot easier if this was in the commit message
from the beginning. Please ensure the next version does say this.

> Since the stmmac MAC can pair with any PCS and PHY, I still prefer that we tie
> this platform specific limitation with the of MAC. As stmmac does handle platform
> specific config/limitation. 

So yes, this needs to be somewhere in the intel specific stmmac code,
with a nice comment explaining what is going on.

What PHY are you using? The Aquantia/Marvell multi-gige phy can do
rate adaptation. So you could fix the MAC-PHY link to 2500BaseX, and
let the PHY internally handle the different line speeds.

    Andrew


From wsa at kernel.org  Tue Apr  6 21:29:01 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 6 Apr 2021 22:29:01 +0200
Subject: [PATCH v4.1 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210406064618.24194-1-uwe@kleine-koenig.org>
References: <20210330181755.204339-6-u.kleine-koenig@pengutronix.de>
 <20210406064618.24194-1-uwe@kleine-koenig.org>
Message-ID: <20210406202901.GB3804@kunai>

On Tue, Apr 06, 2021 at 08:46:18AM +0200, Uwe Kleine-K?nig wrote:
> From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

So, this will go in with the rest of this series?

In that case:

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/20210406/42c67e27/attachment.sig>

From krzysztof.kozlowski at canonical.com  Tue Apr  6 21:30:53 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue,  6 Apr 2021 22:30:53 +0200
Subject: [PATCH] ARM: exynos: correct kernel doc in platsmp
In-Reply-To: <20210405181605.52612-1-krzysztof.kozlowski@canonical.com>
References: <20210405181605.52612-1-krzysztof.kozlowski@canonical.com>
Message-ID: <161774104755.124746.8536738781662816687.b4-ty@canonical.com>

On Mon, 5 Apr 2021 20:16:05 +0200, Krzysztof Kozlowski wrote:
> Correct few kerneldoc issues, including W=1 compile warning:
> 
>   arch/arm/mach-exynos/platsmp.c:89: warning:
>     expecting prototype for exynos_core_power_down(). Prototype was for exynos_cpu_power_down() instead

Applied, thanks!

[1/1] ARM: exynos: correct kernel doc in platsmp
      commit: 6031008780efaada18087eba7ec84fe149f124a9

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


From wsa at kernel.org  Tue Apr  6 21:33:29 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 6 Apr 2021 22:33:29 +0200
Subject: [PATCH] i2c: exynos5: correct top kerneldoc
In-Reply-To: <20210405181405.52189-1-krzysztof.kozlowski@canonical.com>
References: <20210405181405.52189-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210406203329.GC3804@kunai>

On Mon, Apr 05, 2021 at 08:14:05PM +0200, Krzysztof Kozlowski wrote:
> The top comment is not a kerneldoc, as W=1 build reports:
> 
>   drivers/i2c/busses/i2c-exynos5.c:39: warning:
>     expecting prototype for i2c(). Prototype was for HSI2C_CTL() instead
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Applied to for-current, 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/20210406/d102e4bf/attachment.sig>

From wsa at kernel.org  Tue Apr  6 21:40:32 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 6 Apr 2021 22:40:32 +0200
Subject: [PATCH] i2c: stm32f7: avoid ifdef CONFIG_PM_SLEEP for pm callbacks
In-Reply-To: <1615550007-10927-1-git-send-email-alain.volmat@foss.st.com>
References: <1615550007-10927-1-git-send-email-alain.volmat@foss.st.com>
Message-ID: <20210406204032.GD3804@kunai>

On Fri, Mar 12, 2021 at 12:53:27PM +0100, Alain Volmat wrote:
> Avoid CONFIG_PM preprocessor check for pm suspend/resume
> callbacks and identify the functions with __maybe_unused.
> 
> 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/20210406/32e7c88f/attachment.sig>

From arnd at arndb.de  Tue Apr  6 22:44:27 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 6 Apr 2021 23:44:27 +0200
Subject: linux-next: Signed-off-by missing for commit in the arm-soc tree
In-Reply-To: <20210406081147.7a5332ed@canb.auug.org.au>
References: <20210406081100.4a866aa6@canb.auug.org.au>
 <20210406081147.7a5332ed@canb.auug.org.au>
Message-ID: <CAK8P3a1W9oHfx47-_d1ytHN+ZJAQ3ivS4RfcbiVHQ-fU840-ag@mail.gmail.com>

On Tue, Apr 6, 2021 at 12:11 AM Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> Hi all,
>
> On Tue, 6 Apr 2021 08:11:00 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > Commit
> >
> >   3b493ac0ac04 ("arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices")
> >
> > is missing a Signed-off-by from its committer.
>
> Sorry, that commit is in the arm-soc-fixes tree.

Thanks for the report, I've temporarily removed the sunx-fixes branch merge
from the arm/fixes branch and will send the pull request without it.

Maxime, can you fix it up and resend the pull request?
Feel free to add any other fixes that have come up since then.

       Arnd


From leoyang.li at nxp.com  Tue Apr  6 22:45:29 2021
From: leoyang.li at nxp.com (Li Yang)
Date: Tue, 6 Apr 2021 16:45:29 -0500
Subject: [PATCH v6] soc: fsl: enable acpi support in RCPM driver
In-Reply-To: <20210312085822.12136-1-ran.wang_1@nxp.com>
References: <20210312085822.12136-1-ran.wang_1@nxp.com>
Message-ID: <CADRPPNRv_T9o=Kg4dCJ6jFPxOWMY24wgDXCzyTpz3oh_yL+4Tw@mail.gmail.com>

On Fri, Mar 12, 2021 at 2:56 AM Ran Wang <ran.wang_1 at nxp.com> wrote:
>
> From: Peng Ma <peng.ma at nxp.com>
>
> This patch enables ACPI support in RCPM driver.
>
> Signed-off-by: Peng Ma <peng.ma at nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1 at nxp.com>
> ---
> Change in v6:
>  - Remove copyright udpate to rebase on latest mainline
>
> Change in v5:
>  - Fix panic when dev->of_node is null
>
> Change in v4:
>  - Make commit subject more accurate
>  - Remove unrelated new blank line
>
> Change in v3:
>  - Add #ifdef CONFIG_ACPI for acpi_device_id
>  - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
>
> Change in v2:
>  - Update acpi_device_id to fix conflict with other driver
>
>  drivers/soc/fsl/rcpm.c | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
> index 4ace28cab314..7aa997b932d1 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -13,6 +13,7 @@
>  #include <linux/slab.h>
>  #include <linux/suspend.h>
>  #include <linux/kernel.h>
> +#include <linux/acpi.h>
>
>  #define RCPM_WAKEUP_CELL_MAX_SIZE      7
>
> @@ -78,10 +79,14 @@ static int rcpm_pm_prepare(struct device *dev)
>                                 "fsl,rcpm-wakeup", value,
>                                 rcpm->wakeup_cells + 1);
>
> -               /*  Wakeup source should refer to current rcpm device */
> -               if (ret || (np->phandle != value[0]))
> +               if (ret)
>                         continue;
>
> +               if (is_of_node(dev->fwnode))
> +                       /*  Should refer to current rcpm device */
> +                       if (np->phandle != value[0])
> +                               continue;

It looks like that we assume that in the ACPI scenario there will only
be one RCPM controller and all devices are controlled by this single
PM controller.  This probably is true for all existing SoCs with a
RCPM.  But since the driver tried to support multiple RCPMs, maybe we
should continue to support multiple RCPM controllers or at least
mention that in the comment.

> +
>                 /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
>                  * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
>                  * of wakeup source IP contains an integer array: <phandle to
> @@ -172,10 +177,19 @@ static const struct of_device_id rcpm_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rcpm_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id rcpm_acpi_ids[] = {
> +       {"NXP0015",},
> +       { }
> +};
> +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
> +#endif
> +
>  static struct platform_driver rcpm_driver = {
>         .driver = {
>                 .name = "rcpm",
>                 .of_match_table = rcpm_of_match,
> +               .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
>                 .pm     = &rcpm_pm_ops,
>         },
>         .probe = rcpm_probe,
> --
> 2.25.1
>


From leoyang.li at nxp.com  Tue Apr  6 22:52:14 2021
From: leoyang.li at nxp.com (Li Yang)
Date: Tue, 6 Apr 2021 16:52:14 -0500
Subject: [PATCH v1 0/3] Remove qe_io{read,write}* IO accessors
In-Reply-To: <cover.1615053848.git.christophe.leroy@csgroup.eu>
References: <cover.1615053848.git.christophe.leroy@csgroup.eu>
Message-ID: <CADRPPNSx=sbWu9FGujp7=EV7d=dTn+ukvKAgpEHQ5u0vNwR+QQ@mail.gmail.com>

On Sat, Mar 6, 2021 at 12:11 PM Christophe Leroy
<christophe.leroy at csgroup.eu> wrote:
>
> Commit 6ac9b61786cc ("soc: fsl: qe: introduce qe_io{read,write}*
> wrappers") added specific I/O accessors for qe because at that
> time ioread/iowrite functions were sub-optimal on powerpc/32
> compared to the architecture specific in_/out_ IO accessors.
>
> But as ioread/iowrite accessors are now equivalent since
> commit 894fa235eb4c ("powerpc: inline iomap accessors"),
> use them in order to allow removal of the qe specific ones.
>
> Christophe Leroy (3):
>   soc: fsl: qe: replace qe_io{read,write}* wrappers by generic
>     io{read,write}*
>   tty: serial: ucc_uart: replace qe_io{read,write}* wrappers by generic
>     io{read,write}*
>   Revert "soc: fsl: qe: introduce qe_io{read,write}* wrappers"

Series applied.  Thanks.

>
>  drivers/soc/fsl/qe/gpio.c     |  20 +++---
>  drivers/soc/fsl/qe/qe.c       |  24 +++----
>  drivers/soc/fsl/qe/qe_ic.c    |   4 +-
>  drivers/soc/fsl/qe/qe_io.c    |  36 +++++-----
>  drivers/soc/fsl/qe/ucc_fast.c |  68 +++++++++----------
>  drivers/soc/fsl/qe/ucc_slow.c |  42 ++++++------
>  drivers/tty/serial/ucc_uart.c | 124 +++++++++++++++++-----------------
>  include/soc/fsl/qe/qe.h       |  34 +++-------
>  8 files changed, 168 insertions(+), 184 deletions(-)
>
> --
> 2.25.0
>


From j.neuschaefer at gmx.net  Tue Apr  6 22:58:57 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Tue, 6 Apr 2021 23:58:57 +0200
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>
Message-ID: <YGzZofPvT80b5gS5@latitude>

On Tue, Apr 06, 2021 at 05:15:01PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 6, 2021 at 2:09 PM Jonathan Neusch?fer
> <j.neuschaefer at gmx.net> wrote:
> >
> > This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
> > SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.
> >
> > Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki
> >
> > Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
> > Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
> > the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.
> >
> > Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
> > (https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)
> 
> Hi Jonathan,
> 
> It appears these patches are doing roughly the right thing, and we may still
> be able to get them into v5.13, but I'm not sure what your plan for maintaining
> them is. The two options are that you either send your patches to be picked up
> by Joel, or you send everything directly to soc at kernel.org once it's fully
> reviewed.

The route via Joel sounds alright with me. I've Cc'd him on this version
of the series.

> I only noticed your series when patch 9/10 made it into the soc at kernel.org
> patchwork because of the Cc, but none of the other ones did.
> 
> If you end up with the second option, we can go through what this involves
> off-list.
> 
> Regarding the Cc:soc at kernel.org, please add that only for patches that
> are already reviewed and ready to be picked up, ideally with a cover letter
> that describes what the plan is for merging. If you need me to review the
> platform code, use my arnd at arndb.de or arnd at kernel.org addresses.

Ah sorry, soc at kernel.org slipped in automatically because of get_maintainers.pl.

The platform code[1] is rather simple, essentially just hooking up the
nuvoton,wpcm450 compatible string.


Thanks,
Jonathan


[1]: https://lore.kernel.org/lkml/20210406120921.2484986-6-j.neuschaefer at gmx.net/
-------------- 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/20210406/b1f6a782/attachment.sig>

From mathieu.poirier at linaro.org  Tue Apr  6 23:44:37 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  6 Apr 2021 16:44:37 -0600
Subject: [GIT PULL v2] coresight: Add support for ETE and TRBE
Message-ID: <20210406224437.330939-1-mathieu.poirier@linaro.org>

The following changes since commit a354a64d91eec3e0f8ef0eed575b480fd75b999c:

  KVM: arm64: Disable guest access to trace filter controls (2021-03-24 17:26:38 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE

for you to fetch changes up to 4fb13790417a7bf726f3867a5d2b9723efde488b:

  dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600)

----------------------------------------------------------------
Anshuman Khandual (5):
      arm64: Add TRBE definitions
      coresight: core: Add support for dedicated percpu sinks
      coresight: sink: Add TRBE driver
      Documentation: coresight: trbe: Sysfs ABI description
      Documentation: trace: Add documentation for TRBE

Suzuki K Poulose (15):
      perf: aux: Add flags for the buffer format
      perf: aux: Add CoreSight PMU buffer formats
      arm64: Add support for trace synchronization barrier
      KVM: arm64: Handle access to TRFCR_EL1
      KVM: arm64: Move SPE availability check to VCPU load
      arm64: KVM: Enable access to TRBE support for host
      coresight: etm4x: Move ETM to prohibited region for disable
      coresight: etm-perf: Allow an event to use different sinks
      coresight: Do not scan for graph if none is present
      coresight: etm4x: Add support for PE OS lock
      coresight: ete: Add support for ETE sysreg access
      coresight: ete: Add support for ETE tracing
      dts: bindings: Document device tree bindings for ETE
      coresight: etm-perf: Handle stale output handles
      dts: bindings: Document device tree bindings for Arm TRBE

 .../ABI/testing/sysfs-bus-coresight-devices-trbe   |   14 +
 Documentation/devicetree/bindings/arm/ete.yaml     |   75 ++
 Documentation/devicetree/bindings/arm/trbe.yaml    |   49 +
 Documentation/trace/coresight/coresight-trbe.rst   |   38 +
 MAINTAINERS                                        |    2 +
 arch/arm64/include/asm/barrier.h                   |    1 +
 arch/arm64/include/asm/el2_setup.h                 |   13 +
 arch/arm64/include/asm/kvm_arm.h                   |    2 +
 arch/arm64/include/asm/kvm_host.h                  |    8 +
 arch/arm64/include/asm/sysreg.h                    |   50 +
 arch/arm64/kernel/hyp-stub.S                       |    3 +-
 arch/arm64/kvm/arm.c                               |    2 +
 arch/arm64/kvm/debug.c                             |   35 +-
 arch/arm64/kvm/hyp/nvhe/debug-sr.c                 |   56 +-
 arch/arm64/kvm/hyp/nvhe/switch.c                   |    1 +
 arch/arm64/kvm/sys_regs.c                          |    1 +
 drivers/hwtracing/coresight/Kconfig                |   24 +-
 drivers/hwtracing/coresight/Makefile               |    1 +
 drivers/hwtracing/coresight/coresight-core.c       |   29 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  119 +-
 drivers/hwtracing/coresight/coresight-etm4x-core.c |  161 ++-
 .../hwtracing/coresight/coresight-etm4x-sysfs.c    |   19 +-
 drivers/hwtracing/coresight/coresight-etm4x.h      |   83 +-
 drivers/hwtracing/coresight/coresight-platform.c   |    6 +
 drivers/hwtracing/coresight/coresight-priv.h       |    3 +
 drivers/hwtracing/coresight/coresight-trbe.c       | 1157 ++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-trbe.h       |  152 +++
 include/linux/coresight.h                          |   13 +
 include/uapi/linux/perf_event.h                    |   13 +-
 29 files changed, 2053 insertions(+), 77 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
 create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
 create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h


From mathieu.poirier at linaro.org  Wed Apr  7 00:28:37 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 6 Apr 2021 17:28:37 -0600
Subject: [PATCH 1/3] remoteproc: pru: Fixup interrupt-parent logic for fw
 events
In-Reply-To: <20210323223839.17464-2-s-anna@ti.com>
References: <20210323223839.17464-1-s-anna@ti.com>
 <20210323223839.17464-2-s-anna@ti.com>
Message-ID: <20210406232837.GA330882@xps15>

On Tue, Mar 23, 2021 at 05:38:37PM -0500, Suman Anna wrote:
> The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses
> of_irq_find_parent() with PRU device node to get a handle to the PRUSS
> Interrupt Controller at present. This logic however requires that the
> PRU nodes always define a interrupt-parent property. This property is
> neither a required/defined property as per the PRU remoteproc binding,
> nor is relevant from a DT node point of view without any associated
> interrupts. The curret logic finds a wrong interrupt controller and
> fails to perform proper mapping without any interrupt-parent property
> in the PRU nodes.
> 
> Fix this logic to always find and use the sibling interrupt controller.
> Also, while at this, fix the acquired interrupt controller device node
> reference properly.
> 
> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
>  drivers/remoteproc/pru_rproc.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 16979c1cd2f4..a9d07c0751be 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -284,7 +284,7 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  	struct pru_rproc *pru = rproc->priv;
>  	struct pru_irq_rsc *rsc = pru->pru_interrupt_map;
>  	struct irq_fwspec fwspec;
> -	struct device_node *irq_parent;
> +	struct device_node *parent, *irq_parent;
>  	int i, ret = 0;
>  
>  	/* not having pru_interrupt_map is not an error */
> @@ -312,9 +312,16 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  
>  	/*
>  	 * parse and fill in system event to interrupt channel and
> -	 * channel-to-host mapping
> +	 * channel-to-host mapping. The interrupt controller to be used
> +	 * for these mappings for a given PRU remoteproc is always its
> +	 * corresponding sibling PRUSS INTC node.
>  	 */
> -	irq_parent = of_irq_find_parent(pru->dev->of_node);

If I understand correctly when an interrupt controller node wasn't speficied in
the parent this was unwinding until it found one...

> +	parent = of_get_parent(dev_of_node(pru->dev));
> +	if (!parent)
> +		return -ENODEV;
> +
> +	irq_parent = of_get_child_by_name(parent, "interrupt-controller");
> +	of_node_put(parent);
>  	if (!irq_parent) {
>  		kfree(pru->mapped_irq);
>  		return -ENODEV;
> @@ -337,11 +344,13 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  			goto map_fail;
>  		}
>  	}
> +	of_node_put(irq_parent);
>  
>  	return ret;
>  
>  map_fail:
>  	pru_dispose_irq_mapping(pru);
> +	of_node_put(irq_parent);

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  
>  	return ret;
>  }
> -- 
> 2.30.1
> 


From patchwork-bot+netdevbpf at kernel.org  Wed Apr  7 00:30:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Tue, 06 Apr 2021 23:30:10 +0000
Subject: [PATCH net-next] net: ethernet: mtk_eth_soc: remove unneeded
 semicolon
In-Reply-To: <20210406030433.6540-1-linqiheng@huawei.com>
References: <20210406030433.6540-1-linqiheng@huawei.com>
Message-ID: <161775181030.15996.4622517435029624196.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue, 6 Apr 2021 11:04:33 +0800 you wrote:
> Eliminate the following coccicheck warning:
>  drivers/net/ethernet/mediatek/mtk_ppe.c:270:2-3: Unneeded semicolon
> 
> Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_ppe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Here is the summary with links:
  - [net-next] net: ethernet: mtk_eth_soc: remove unneeded semicolon
    https://git.kernel.org/netdev/net-next/c/3b2c32f96edc

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From mathieu.poirier at linaro.org  Wed Apr  7 00:33:10 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 6 Apr 2021 17:33:10 -0600
Subject: [PATCH 2/3] remoteproc: pru: Fix wrong success return value for
 fw events
In-Reply-To: <20210323223839.17464-3-s-anna@ti.com>
References: <20210323223839.17464-1-s-anna@ti.com>
 <20210323223839.17464-3-s-anna@ti.com>
Message-ID: <20210406233310.GB330882@xps15>

On Tue, Mar 23, 2021 at 05:38:38PM -0500, Suman Anna wrote:
> The irq_create_fwspec_mapping() returns a proper virq value on success
> and 0 upon any failure. The pru_handle_intrmap() treats this as an error
> and disposes all firmware event mappings correctly, but is returning
> this incorrect value as is, letting the pru_rproc_start() interpret it
> as a success and boot the PRU.
> 

Very subtle...  I had to look twice to make sure.

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

> Fix this by returning an error value back upon any such failure. While
> at this, revise the error trace to print some meaningful info about the
> failed event.
> 
> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
>  drivers/remoteproc/pru_rproc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index a9d07c0751be..87b43976c51b 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -339,8 +339,10 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  
>  		pru->mapped_irq[i] = irq_create_fwspec_mapping(&fwspec);
>  		if (!pru->mapped_irq[i]) {
> -			dev_err(dev, "failed to get virq\n");
> -			ret = pru->mapped_irq[i];
> +			dev_err(dev, "failed to get virq for fw mapping %d: event %d chnl %d host %d\n",
> +				i, fwspec.param[0], fwspec.param[1],
> +				fwspec.param[2]);
> +			ret = -EINVAL;
>  			goto map_fail;
>  		}
>  	}
> -- 
> 2.30.1
> 


From mathieu.poirier at linaro.org  Wed Apr  7 00:47:47 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 6 Apr 2021 17:47:47 -0600
Subject: [PATCH 3/3] remoteproc: pru: Fix and cleanup firmware interrupt
 mapping logic
In-Reply-To: <20210323223839.17464-4-s-anna@ti.com>
References: <20210323223839.17464-1-s-anna@ti.com>
 <20210323223839.17464-4-s-anna@ti.com>
Message-ID: <20210406234747.GC330882@xps15>

On Tue, Mar 23, 2021 at 05:38:39PM -0500, Suman Anna wrote:
> The PRU firmware interrupt mappings are configured and unconfigured in
> .start() and .stop() callbacks respectively using the variables 'evt_count'
> and a 'mapped_irq' pointer. These variables are modified only during these
> callbacks but are not re-initialized/reset properly during unwind or
> failure paths. These stale values caused a kernel crash while stopping a
> PRU remoteproc running a different firmware with no events on a subsequent
> run after a previous run that was running a firmware with events.
> 
> Fix this crash by ensuring that the evt_count is 0 and the mapped_irq
> pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these
> variables properly during any failures in the .start() callback. While
> at this, the pru_dispose_irq_mapping() callsites are all made to look
> the same, moving any conditional logic to inside the function.
> 
> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
> Reported-by: Vignesh Raghavendra <vigneshr at ti.com>
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
>  drivers/remoteproc/pru_rproc.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 87b43976c51b..5df19acb90ed 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -266,12 +266,17 @@ static void pru_rproc_create_debug_entries(struct rproc *rproc)
>  
>  static void pru_dispose_irq_mapping(struct pru_rproc *pru)
>  {
> -	while (pru->evt_count--) {
> +	if (!pru->mapped_irq)
> +		return;
> +
> +	while (pru->evt_count) {
> +		pru->evt_count--;
>  		if (pru->mapped_irq[pru->evt_count] > 0)
>  			irq_dispose_mapping(pru->mapped_irq[pru->evt_count]);
>  	}
>  
>  	kfree(pru->mapped_irq);
> +	pru->mapped_irq = NULL;
>  }
>  
>  /*
> @@ -324,6 +329,8 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  	of_node_put(parent);
>  	if (!irq_parent) {
>  		kfree(pru->mapped_irq);
> +		pru->mapped_irq = NULL;
> +		pru->evt_count = 0;

Patch 1/3 introduced a check on @parent that doesn't free pru->mapped_irq.  I
would also expect that error path to do the same has what is done here.  And
looking further up I see the error path for !pru->mapped_irq doesn't set
pru->evt_count to zero.

Thanks,
Mathieu

>  		return -ENODEV;
>  	}
>  
> @@ -398,8 +405,7 @@ static int pru_rproc_stop(struct rproc *rproc)
>  	pru_control_write_reg(pru, PRU_CTRL_CTRL, val);
>  
>  	/* dispose irq mapping - new firmware can provide new mapping */
> -	if (pru->mapped_irq)
> -		pru_dispose_irq_mapping(pru);
> +	pru_dispose_irq_mapping(pru);
>  
>  	return 0;
>  }
> -- 
> 2.30.1
> 


From patchwork-bot+netdevbpf at kernel.org  Wed Apr  7 01:20:13 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 07 Apr 2021 00:20:13 +0000
Subject: [PATCH v2 1/1] time64.h: Consolidated PSEC_PER_SEC definition
In-Reply-To: <20210406102251.60301-1-andriy.shevchenko@linux.intel.com>
References: <20210406102251.60301-1-andriy.shevchenko@linux.intel.com>
Message-ID: <161775481302.4854.4555470311488320359.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  6 Apr 2021 13:22:51 +0300 you wrote:
> We have currently three users of the PSEC_PER_SEC each of them defining it
> individually. Instead, move it to time64.h to be available for everyone.
> 
> There is a new user coming with the same constant in use. It will also
> make its life easier.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Acked-by: Heiko Stuebner <heiko at sntech.de>
> 
> [...]

Here is the summary with links:
  - [v2,1/1] time64.h: Consolidated PSEC_PER_SEC definition
    https://git.kernel.org/netdev/net-next/c/a460513ed4b6

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From patchwork-bot+netdevbpf at kernel.org  Wed Apr  7 01:20:12 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 07 Apr 2021 00:20:12 +0000
Subject: [PATCH net-next v1 1/1] stmmac: intel: Drop duplicate ID in the
 list of PCI device IDs
In-Reply-To: <20210406101306.59162-1-andriy.shevchenko@linux.intel.com>
References: <20210406101306.59162-1-andriy.shevchenko@linux.intel.com>
Message-ID: <161775481297.4854.15334694335904751602.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  6 Apr 2021 13:13:06 +0300 you wrote:
> The PCI device IDs are defined with a prefix PCI_DEVICE_ID.
> There is no need to repeat the ID part at the end of each definition.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 60 +++++++++----------
>  1 file changed, 30 insertions(+), 30 deletions(-)

Here is the summary with links:
  - [net-next,v1,1/1] stmmac: intel: Drop duplicate ID in the list of PCI device IDs
    https://git.kernel.org/netdev/net-next/c/3036ec035c4d

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  Wed Apr  7 01:34:13 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 7 Apr 2021 08:34:13 +0800
Subject: [PATCH V2 10/18] i2c: imx-lpi2c: add bus recovery feature
In-Reply-To: <20210406113306.2633595-11-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-11-xiaoning.wang@nxp.com>
Message-ID: <202104070820.hVWN6IhC-lkp@intel.com>

Hi Clark,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on next-20210406]
[cannot apply to wsa/i2c/for-next robh/for-next v5.12-rc6]
[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]

url:    https://github.com/0day-ci/linux/commits/Clark-Wang/i2c-imx-lpi2c-New-features-and-bug-fixes/20210406-193539
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
config: nios2-randconfig-r003-20210406 (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/5853de64dd40e1cc71f0adede924934aee4c4f0e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Clark-Wang/i2c-imx-lpi2c-New-features-and-bug-fixes/20210406-193539
        git checkout 5853de64dd40e1cc71f0adede924934aee4c4f0e
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/i2c/busses/i2c-imx-lpi2c.c: In function 'lpi2c_imx_init_recovery_info':
>> drivers/i2c/busses/i2c-imx-lpi2c.c:583:21: error: implicit declaration of function 'devm_gpiod_get'; did you mean 'devm_gpio_free'? [-Werror=implicit-function-declaration]
     583 |  rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
         |                     ^~~~~~~~~~~~~~
         |                     devm_gpio_free
>> drivers/i2c/busses/i2c-imx-lpi2c.c:583:55: error: 'GPIOD_IN' undeclared (first use in this function); did you mean 'GPIOF_IN'?
     583 |  rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
         |                                                       ^~~~~~~~
         |                                                       GPIOF_IN
   drivers/i2c/busses/i2c-imx-lpi2c.c:583:55: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/i2c/busses/i2c-imx-lpi2c.c:584:55: error: 'GPIOD_OUT_HIGH_OPEN_DRAIN' undeclared (first use in this function)
     584 |  rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
         |                                                       ^~~~~~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +583 drivers/i2c/busses/i2c-imx-lpi2c.c

   560	
   561	/*
   562	 * We switch SCL and SDA to their GPIO function and do some bitbanging
   563	 * for bus recovery. These alternative pinmux settings can be
   564	 * described in the device tree by a separate pinctrl state "gpio". If
   565	 * this is missing this is not a big problem, the only implication is
   566	 * that we can't do bus recovery.
   567	 */
   568	static int lpi2c_imx_init_recovery_info(struct lpi2c_imx_struct *lpi2c_imx,
   569			struct platform_device *pdev)
   570	{
   571		struct i2c_bus_recovery_info *rinfo = &lpi2c_imx->rinfo;
   572	
   573		lpi2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
   574		if (!lpi2c_imx->pinctrl || IS_ERR(lpi2c_imx->pinctrl)) {
   575			dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
   576			return PTR_ERR(lpi2c_imx->pinctrl);
   577		}
   578	
   579		lpi2c_imx->pinctrl_pins_default = pinctrl_lookup_state(lpi2c_imx->pinctrl,
   580				PINCTRL_STATE_DEFAULT);
   581		lpi2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(lpi2c_imx->pinctrl,
   582				"gpio");
 > 583		rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
 > 584		rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
   585	
   586		if (PTR_ERR(rinfo->sda_gpiod) == -EPROBE_DEFER ||
   587		    PTR_ERR(rinfo->scl_gpiod) == -EPROBE_DEFER) {
   588			return -EPROBE_DEFER;
   589		} else if (IS_ERR(rinfo->sda_gpiod) ||
   590			   IS_ERR(rinfo->scl_gpiod) ||
   591			   IS_ERR(lpi2c_imx->pinctrl_pins_default) ||
   592			   IS_ERR(lpi2c_imx->pinctrl_pins_gpio)) {
   593			dev_dbg(&pdev->dev, "recovery information incomplete\n");
   594			return 0;
   595		}
   596	
   597		dev_info(&pdev->dev, "using scl%s for recovery\n",
   598			 rinfo->sda_gpiod ? ",sda" : "");
   599	
   600		rinfo->prepare_recovery = lpi2c_imx_prepare_recovery;
   601		rinfo->unprepare_recovery = lpi2c_imx_unprepare_recovery;
   602		rinfo->recover_bus = i2c_generic_scl_recovery;
   603		lpi2c_imx->adapter.bus_recovery_info = rinfo;
   604	
   605		return 0;
   606	}
   607	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29278 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210407/fce3dacf/attachment-0001.gz>

From ran.wang_1 at nxp.com  Wed Apr  7 02:31:38 2021
From: ran.wang_1 at nxp.com (Ran Wang)
Date: Wed, 7 Apr 2021 01:31:38 +0000
Subject: [PATCH v6] soc: fsl: enable acpi support in RCPM driver
In-Reply-To: <CADRPPNRv_T9o=Kg4dCJ6jFPxOWMY24wgDXCzyTpz3oh_yL+4Tw@mail.gmail.com>
References: <20210312085822.12136-1-ran.wang_1@nxp.com>
 <CADRPPNRv_T9o=Kg4dCJ6jFPxOWMY24wgDXCzyTpz3oh_yL+4Tw@mail.gmail.com>
Message-ID: <AM6PR04MB5413E08499BE566F67AA62ABF1759@AM6PR04MB5413.eurprd04.prod.outlook.com>

Hi Leo,

On Wednesday, April 7, 2021 5:45 AM, Li Yang wrote:
> 
> On Fri, Mar 12, 2021 at 2:56 AM Ran Wang <ran.wang_1 at nxp.com> wrote:
> >
> > From: Peng Ma <peng.ma at nxp.com>
> >
> > This patch enables ACPI support in RCPM driver.
> >
> > Signed-off-by: Peng Ma <peng.ma at nxp.com>
> > Signed-off-by: Ran Wang <ran.wang_1 at nxp.com>
> > ---
> > Change in v6:
> >  - Remove copyright udpate to rebase on latest mainline
> >
> > Change in v5:
> >  - Fix panic when dev->of_node is null
> >
> > Change in v4:
> >  - Make commit subject more accurate
> >  - Remove unrelated new blank line
> >
> > Change in v3:
> >  - Add #ifdef CONFIG_ACPI for acpi_device_id
> >  - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
> >
> > Change in v2:
> >  - Update acpi_device_id to fix conflict with other driver
> >
> >  drivers/soc/fsl/rcpm.c | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> > 4ace28cab314..7aa997b932d1 100644
> > --- a/drivers/soc/fsl/rcpm.c
> > +++ b/drivers/soc/fsl/rcpm.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/slab.h>
> >  #include <linux/suspend.h>
> >  #include <linux/kernel.h>
> > +#include <linux/acpi.h>
> >
> >  #define RCPM_WAKEUP_CELL_MAX_SIZE      7
> >
> > @@ -78,10 +79,14 @@ static int rcpm_pm_prepare(struct device *dev)
> >                                 "fsl,rcpm-wakeup", value,
> >                                 rcpm->wakeup_cells + 1);
> >
> > -               /*  Wakeup source should refer to current rcpm device */
> > -               if (ret || (np->phandle != value[0]))
> > +               if (ret)
> >                         continue;
> >
> > +               if (is_of_node(dev->fwnode))
> > +                       /*  Should refer to current rcpm device */
> > +                       if (np->phandle != value[0])
> > +                               continue;
> 
> It looks like that we assume that in the ACPI scenario there will only be one RCPM controller and all devices are controlled by this single
> PM controller.  This probably is true for all existing SoCs with a RCPM.  But since the driver tried to support multiple RCPMs, maybe we
> should continue to support multiple RCPM controllers or at least mention that in the comment.

How about adding some comment as below:

/* For ACPI mode, currently we assume there is only one RCPM controller existing */

Regards,
Ran

> 
> > +
> >                 /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
> >                  * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
> >                  * of wakeup source IP contains an integer array:
> > <phandle to @@ -172,10 +177,19 @@ static const struct of_device_id
> > rcpm_of_match[] = {  };  MODULE_DEVICE_TABLE(of, rcpm_of_match);
> >
> > +#ifdef CONFIG_ACPI
> > +static const struct acpi_device_id rcpm_acpi_ids[] = {
> > +       {"NXP0015",},
> > +       { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids); #endif
> > +
> >  static struct platform_driver rcpm_driver = {
> >         .driver = {
> >                 .name = "rcpm",
> >                 .of_match_table = rcpm_of_match,
> > +               .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> >                 .pm     = &rcpm_pm_ops,
> >         },
> >         .probe = rcpm_probe,
> > --
> > 2.25.1
> >

From tiantao6 at hisilicon.com  Wed Apr  7 03:18:57 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Wed, 7 Apr 2021 10:18:57 +0800
Subject: [PATCH] rtc: st-lpc: move to use request_irq by IRQF_NO_AUTOEN flag
Message-ID: <1617761937-58318-1-git-send-email-tiantao6@hisilicon.com>

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.

this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
 drivers/rtc/rtc-st-lpc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/rtc-st-lpc.c b/drivers/rtc/rtc-st-lpc.c
index bdb20f6..2df2179 100644
--- a/drivers/rtc/rtc-st-lpc.c
+++ b/drivers/rtc/rtc-st-lpc.c
@@ -218,15 +218,14 @@ static int st_rtc_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	ret = devm_request_irq(&pdev->dev, rtc->irq, st_rtc_handler, 0,
-			       pdev->name, rtc);
+	ret = devm_request_irq(&pdev->dev, rtc->irq, st_rtc_handler,
+			       IRQF_NO_AUTOEN, pdev->name, rtc);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to request irq %i\n", rtc->irq);
 		return ret;
 	}
 
 	enable_irq_wake(rtc->irq);
-	disable_irq(rtc->irq);
 
 	rtc->clk = clk_get(&pdev->dev, NULL);
 	if (IS_ERR(rtc->clk)) {
-- 
2.7.4



From weifeng.voon at intel.com  Wed Apr  7 04:02:21 2021
From: weifeng.voon at intel.com (Voon, Weifeng)
Date: Wed, 7 Apr 2021 03:02:21 +0000
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <YGy/N+cRLGTifJSN@lunn.ch>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
 <YGsgHWItHcLFV9Kg@lunn.ch>
 <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YGy/N+cRLGTifJSN@lunn.ch>
Message-ID: <SN6PR11MB3136E862F38D7C573759989188759@SN6PR11MB3136.namprd11.prod.outlook.com>

> > The limitation is not on the MAC, PCS or the PHY. For Intel mgbe, the
> > overclocking of 2.5 times clock rate to support 2.5G is only able to
> > be configured in the BIOS during boot time. Kernel driver has no
> > access to modify the clock rate for 1Gbps/2.5G mode. The way to
> > determined the current 1G/2.5G mode is by reading a dedicated adhoc
> register through mdio bus.
> > In short, after the system boot up, it is either in 1G mode or 2.5G
> > mode which not able to be changed on the fly.
> 
> Right. It would of been a lot easier if this was in the commit message
> from the beginning. Please ensure the next version does say this.
> 
> > Since the stmmac MAC can pair with any PCS and PHY, I still prefer
> > that we tie this platform specific limitation with the of MAC. As
> > stmmac does handle platform specific config/limitation.
> 
> So yes, this needs to be somewhere in the intel specific stmmac code,
> with a nice comment explaining what is going on.
> 
> What PHY are you using? The Aquantia/Marvell multi-gige phy can do rate
> adaptation. So you could fix the MAC-PHY link to 2500BaseX, and let the
> PHY internally handle the different line speeds.
> 
Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
multi-gige PHY can do rate adaption right? Hence, we still need to take 
care of others PHYs.

Thanks for all the comments, will include them in v3. 

Weifeng


From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:42 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:42 +0800
Subject: [PATCHv5 0/6] PCI: layerscape: Add power management support
Message-ID: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

This patch series is to add PCIe power management support for NXP
Layerscape platforms.

Hou Zhiqiang (6):
  PCI: layerscape: Change to use the DWC common link-up check function
  dt-bindings: pci: layerscape-pci: Add a optional property big-endian
  arm64: dts: layerscape: Add big-endian property for PCIe nodes
  dt-bindings: pci: layerscape-pci: Update the description of SCFG
    property
  arm64: dts: ls1043a: Add SCFG phandle for PCIe nodes
  PCI: layerscape: Add power management support

 .../bindings/pci/layerscape-pci.txt           |   6 +-
 .../arm64/boot/dts/freescale/fsl-ls1012a.dtsi |   1 +
 .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi |   6 +
 .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi |   3 +
 drivers/pci/controller/dwc/pci-layerscape.c   | 450 ++++++++++++++----
 drivers/pci/controller/dwc/pcie-designware.h  |   1 +
 6 files changed, 370 insertions(+), 97 deletions(-)

-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:43 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:43 +0800
Subject: [PATCHv5 1/6] PCI: layerscape: Change to use the DWC common link-up
 check function
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-2-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

The current Layerscape PCIe driver directly uses the physical layer
LTSSM code to check the link-up state, which treats the > L0 states
as link-up. This is not correct, since there is not explicit map
between link-up state and LTSSM. So this patch changes to use the
DWC common link-up check function.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
V5:
 - No change

 drivers/pci/controller/dwc/pci-layerscape.c | 140 ++------------------
 1 file changed, 10 insertions(+), 130 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 5b9c625df7b8..71911ca4c589 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -22,12 +22,6 @@
 
 #include "pcie-designware.h"
 
-/* PEX1/2 Misc Ports Status Register */
-#define SCFG_PEXMSCPORTSR(pex_idx)	(0x94 + (pex_idx) * 4)
-#define LTSSM_STATE_SHIFT	20
-#define LTSSM_STATE_MASK	0x3f
-#define LTSSM_PCIE_L0		0x11 /* L0 state */
-
 /* PEX Internal Configuration Registers */
 #define PCIE_STRFMR1		0x71c /* Symbol Timer & Filter Mask Register1 */
 #define PCIE_ABSERR		0x8d0 /* Bridge Slave Error Response Register */
@@ -36,19 +30,12 @@
 #define PCIE_IATU_NUM		6
 
 struct ls_pcie_drvdata {
-	u32 lut_offset;
-	u32 ltssm_shift;
-	u32 lut_dbg;
 	const struct dw_pcie_host_ops *ops;
-	const struct dw_pcie_ops *dw_pcie_ops;
 };
 
 struct ls_pcie {
 	struct dw_pcie *pci;
-	void __iomem *lut;
-	struct regmap *scfg;
 	const struct ls_pcie_drvdata *drvdata;
-	int index;
 };
 
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
@@ -83,38 +70,6 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
 	iowrite32(val, pci->dbi_base + PCIE_STRFMR1);
 }
 
-static int ls1021_pcie_link_up(struct dw_pcie *pci)
-{
-	u32 state;
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-
-	if (!pcie->scfg)
-		return 0;
-
-	regmap_read(pcie->scfg, SCFG_PEXMSCPORTSR(pcie->index), &state);
-	state = (state >> LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK;
-
-	if (state < LTSSM_PCIE_L0)
-		return 0;
-
-	return 1;
-}
-
-static int ls_pcie_link_up(struct dw_pcie *pci)
-{
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-	u32 state;
-
-	state = (ioread32(pcie->lut + pcie->drvdata->lut_dbg) >>
-		 pcie->drvdata->ltssm_shift) &
-		 LTSSM_STATE_MASK;
-
-	if (state < LTSSM_PCIE_L0)
-		return 0;
-
-	return 1;
-}
-
 /* Forward error response of outbound non-posted requests */
 static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 {
@@ -139,96 +94,24 @@ static int ls_pcie_host_init(struct pcie_port *pp)
 	return 0;
 }
 
-static int ls1021_pcie_host_init(struct pcie_port *pp)
-{
-	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-	struct ls_pcie *pcie = to_ls_pcie(pci);
-	struct device *dev = pci->dev;
-	u32 index[2];
-	int ret;
-
-	pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
-						     "fsl,pcie-scfg");
-	if (IS_ERR(pcie->scfg)) {
-		ret = PTR_ERR(pcie->scfg);
-		dev_err(dev, "No syscfg phandle specified\n");
-		pcie->scfg = NULL;
-		return ret;
-	}
-
-	if (of_property_read_u32_array(dev->of_node,
-				       "fsl,pcie-scfg", index, 2)) {
-		pcie->scfg = NULL;
-		return -EINVAL;
-	}
-	pcie->index = index[1];
-
-	return ls_pcie_host_init(pp);
-}
-
-static const struct dw_pcie_host_ops ls1021_pcie_host_ops = {
-	.host_init = ls1021_pcie_host_init,
-};
-
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 };
 
-static const struct dw_pcie_ops dw_ls1021_pcie_ops = {
-	.link_up = ls1021_pcie_link_up,
-};
-
-static const struct dw_pcie_ops dw_ls_pcie_ops = {
-	.link_up = ls_pcie_link_up,
-};
-
-static const struct ls_pcie_drvdata ls1021_drvdata = {
-	.ops = &ls1021_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls1021_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls1043_drvdata = {
-	.lut_offset = 0x10000,
-	.ltssm_shift = 24,
-	.lut_dbg = 0x7fc,
+static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls1046_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 24,
-	.lut_dbg = 0x407fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls2080_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 0,
-	.lut_dbg = 0x7fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
-};
-
-static const struct ls_pcie_drvdata ls2088_drvdata = {
-	.lut_offset = 0x80000,
-	.ltssm_shift = 0,
-	.lut_dbg = 0x407fc,
-	.ops = &ls_pcie_host_ops,
-	.dw_pcie_ops = &dw_ls_pcie_ops,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
-	{ .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
-	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
-	{ .compatible = "fsl,ls1028a-pcie", .data = &ls2088_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
-	{ .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
-	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
-	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
-	{ .compatible = "fsl,ls2088a-pcie", .data = &ls2088_drvdata },
-	{ .compatible = "fsl,ls1088a-pcie", .data = &ls2088_drvdata },
+	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1021a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1043a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1046a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2080a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2085a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls2088a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1088a-pcie", .data = &layerscape_drvdata },
 	{ },
 };
 
@@ -250,7 +133,6 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	pcie->drvdata = of_device_get_match_data(dev);
 
 	pci->dev = dev;
-	pci->ops = pcie->drvdata->dw_pcie_ops;
 	pci->pp.ops = pcie->drvdata->ops;
 
 	pcie->pci = pci;
@@ -260,8 +142,6 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	if (IS_ERR(pci->dbi_base))
 		return PTR_ERR(pci->dbi_base);
 
-	pcie->lut = pci->dbi_base + pcie->drvdata->lut_offset;
-
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:44 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:44 +0800
Subject: [PATCHv5 2/6] dt-bindings: pci: layerscape-pci: Add a optional
 property big-endian
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-3-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

This property is to indicate the endianness when accessing the
PEX_LUT and PF register block, so if these registers are
implemented in big-endian, specify this property.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
V5:
 - No change

 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 6d898dd4a8e2..d633c1fabdb4 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -40,6 +40,10 @@ Required properties:
   of the data transferred from/to the IP block. This can avoid the software
   cache flush/invalid actions, and improve the performance significantly.
 
+Optional properties:
+- big-endian: If the PEX_LUT and PF register block is in big-endian, specify
+  this property.
+
 Example:
 
 	pcie at 3400000 {
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:45 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:45 +0800
Subject: [PATCHv5 3/6] arm64: dts: layerscape: Add big-endian property for
 PCIe nodes
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-4-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Add the big-endian property for LS1012A, LS1043A and LS1046A
PCIe devicetree nodes.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V5:
 - No change

 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 9058cfa4980f..ac23e938fd1d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -542,6 +542,7 @@
 					<0000 0 0 2 &gic 0 111 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic 0 112 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 28c51e521cb2..46826752a691 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -890,6 +890,7 @@
 					<0000 0 0 2 &gic 0 111 0x4>,
 					<0000 0 0 3 &gic 0 112 0x4>,
 					<0000 0 0 4 &gic 0 113 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -916,6 +917,7 @@
 					<0000 0 0 2 &gic 0 121 0x4>,
 					<0000 0 0 3 &gic 0 122 0x4>,
 					<0000 0 0 4 &gic 0 123 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -942,6 +944,7 @@
 					<0000 0 0 2 &gic 0 155 0x4>,
 					<0000 0 0 3 &gic 0 156 0x4>,
 					<0000 0 0 4 &gic 0 157 0x4>;
+			big-endian;
 			status = "disabled";
 		};
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 39458305e333..f21ee7825d40 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -794,6 +794,7 @@
 					<0000 0 0 2 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -830,6 +831,7 @@
 					<0000 0 0 2 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
@@ -866,6 +868,7 @@
 					<0000 0 0 2 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 3 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
 					<0000 0 0 4 &gic GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+			big-endian;
 			status = "disabled";
 		};
 
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:46 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:46 +0800
Subject: [PATCHv5 4/6] dt-bindings: pci: layerscape-pci: Update the
 description of SCFG property
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-5-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Update the description of the second entry of 'fsl,pcie-scfg' property,
as the LS1043A PCIe controller also has some control registers in SCFG
block, while it has 3 controllers.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
V5:
 - No change

 Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index d633c1fabdb4..8231f6729385 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -34,7 +34,7 @@ Required properties:
   "intr": The interrupt that is asserted for controller interrupts
 - fsl,pcie-scfg: Must include two entries.
   The first entry must be a link to the SCFG device node
-  The second entry must be '0' or '1' based on physical PCIe controller index.
+  The second entry is the physical PCIe controller index starting from '0'.
   This is used to get SCFG PEXN registers
 - dma-coherent: Indicates that the hardware IP block can ensure the coherency
   of the data transferred from/to the IP block. This can avoid the software
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:47 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:47 +0800
Subject: [PATCHv5 5/6] arm64: dts: ls1043a: Add SCFG phandle for PCIe nodes
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-6-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

The LS1043A PCIe controller has some control registers
in SCFG block, so add the SCFG phandle for each PCIe
controller DT node.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V5:
 - No change

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 46826752a691..704e9e249729 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -875,6 +875,7 @@
 			interrupts = <0 118 0x4>, /* controller interrupt */
 				     <0 117 0x4>; /* PME interrupt */
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 0>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
@@ -902,6 +903,7 @@
 			interrupts = <0 128 0x4>,
 				     <0 127 0x4>;
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 1>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
@@ -929,6 +931,7 @@
 			interrupts = <0 162 0x4>,
 				     <0 161 0x4>;
 			interrupt-names = "intr", "pme";
+			fsl,pcie-scfg = <&scfg 2>;
 			#address-cells = <3>;
 			#size-cells = <2>;
 			device_type = "pci";
-- 
2.17.1



From Zhiqiang.Hou at nxp.com  Wed Apr  7 04:09:48 2021
From: Zhiqiang.Hou at nxp.com (Zhiqiang Hou)
Date: Wed,  7 Apr 2021 11:09:48 +0800
Subject: [PATCHv5 6/6] PCI: layerscape: Add power management support
In-Reply-To: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
Message-ID: <20210407030948.3845-7-Zhiqiang.Hou@nxp.com>

From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>

Add PME_Turn_Off/PME_TO_Ack handshake sequence, and finally
put the PCIe controller into D3 state after the L2/L3 ready
state transition process completion.

Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
---
V5:
 - Fix a typo of the parameter given to function dw_pcie_setup_rc()

 drivers/pci/controller/dwc/pci-layerscape.c  | 382 ++++++++++++++++++-
 drivers/pci/controller/dwc/pcie-designware.h |   1 +
 2 files changed, 381 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index 71911ca4c589..868e18b12e4a 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -3,13 +3,16 @@
  * PCIe host controller driver for Freescale Layerscape SoCs
  *
  * Copyright (C) 2014 Freescale Semiconductor.
+ * Copyright 2020 NXP
  *
  * Author: Minghuan Lian <Minghuan.Lian at freescale.com>
  */
 
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
 #include <linux/init.h>
+#include <linux/iopoll.h>
 #include <linux/of_pci.h>
 #include <linux/of_platform.h>
 #include <linux/of_irq.h>
@@ -27,17 +30,60 @@
 #define PCIE_ABSERR		0x8d0 /* Bridge Slave Error Response Register */
 #define PCIE_ABSERR_SETTING	0x9401 /* Forward error of non-posted request */
 
+/* PF Message Command Register */
+#define LS_PCIE_PF_MCR		0x2c
+#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)
+
+/* 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
 
+#define LS_PCIE_IS_L2(v)	\
+	(((v) & PORT_LOGIC_LTSSM_STATE_MASK) == PORT_LOGIC_LTSSM_STATE_L2)
+
+struct ls_pcie;
+
+struct ls_pcie_host_pm_ops {
+	int (*pm_init)(struct ls_pcie *pcie);
+	void (*send_turn_off_message)(struct ls_pcie *pcie);
+	void (*exit_from_l2)(struct ls_pcie *pcie);
+};
+
 struct ls_pcie_drvdata {
+	const u32 pf_off;
+	const u32 lut_off;
 	const struct dw_pcie_host_ops *ops;
+	const struct ls_pcie_host_pm_ops *pm_ops;
 };
 
 struct ls_pcie {
 	struct dw_pcie *pci;
 	const struct ls_pcie_drvdata *drvdata;
+	void __iomem *pf_base;
+	void __iomem *lut_base;
+	bool big_endian;
+	bool ep_presence;
+	bool pm_support;
+	struct regmap *scfg;
+	int index;
 };
 
+#define ls_pcie_lut_readl_addr(addr)	ls_pcie_lut_readl(pcie, addr)
+#define ls_pcie_pf_readl_addr(addr)	ls_pcie_pf_readl(pcie, addr)
 #define to_ls_pcie(x)	dev_get_drvdata((x)->dev)
 
 static bool ls_pcie_is_bridge(struct ls_pcie *pcie)
@@ -78,6 +124,210 @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
 	iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR);
 }
 
+static u32 ls_pcie_lut_readl(struct ls_pcie *pcie, u32 off)
+{
+	if (pcie->big_endian)
+		return ioread32be(pcie->lut_base + off);
+
+	return ioread32(pcie->lut_base + off);
+}
+
+static void ls_pcie_lut_writel(struct ls_pcie *pcie, u32 off, u32 val)
+{
+	if (pcie->big_endian)
+		return iowrite32be(val, pcie->lut_base + off);
+
+	return iowrite32(val, pcie->lut_base + off);
+
+}
+
+static u32 ls_pcie_pf_readl(struct ls_pcie *pcie, u32 off)
+{
+	if (pcie->big_endian)
+		return ioread32be(pcie->pf_base + off);
+
+	return ioread32(pcie->pf_base + off);
+}
+
+static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val)
+{
+	if (pcie->big_endian)
+		return iowrite32be(val, pcie->pf_base + off);
+
+	return iowrite32(val, pcie->pf_base + off);
+
+}
+
+static void ls_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+	int ret;
+
+	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val |= PF_MCR_PTOMR;
+	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+
+	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+				 val, !(val & PF_MCR_PTOMR), 100, 10000);
+	if (ret)
+		dev_info(pcie->pci->dev, "poll turn off message timeout\n");
+}
+
+static void ls1021a_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	if (!pcie->scfg) {
+		dev_dbg(pcie->pci->dev, "SYSCFG is NULL\n");
+		return;
+	}
+
+	/* Send Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
+	val |= PMXMTTURNOFF;
+	regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
+
+	mdelay(10);
+
+	/* Clear Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val);
+	val &= ~PMXMTTURNOFF;
+	regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val);
+}
+
+static void ls1043a_pcie_send_turnoff_msg(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	if (!pcie->scfg) {
+		dev_dbg(pcie->pci->dev, "SYSCFG is NULL\n");
+		return;
+	}
+
+	/* Send Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMECR, &val);
+	val |= PEXPME(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXPMECR, val);
+
+	mdelay(10);
+
+	/* Clear Turn_off message */
+	regmap_read(pcie->scfg, SCFG_PEXPMECR, &val);
+	val &= ~PEXPME(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXPMECR, val);
+}
+
+static void ls_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+	int ret;
+
+	val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR);
+	val |= PF_MCR_EXL2S;
+	ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val);
+
+	ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR,
+				 val, !(val & PF_MCR_EXL2S), 100, 10000);
+	if (ret)
+		dev_info(pcie->pci->dev, "poll exit L2 state timeout\n");
+}
+
+static void ls_pcie_retrain_link(struct ls_pcie *pcie)
+{
+	struct dw_pcie *pci = pcie->pci;
+	u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+	u32 val;
+
+	val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKCTL);
+	val |= PCI_EXP_LNKCTL_RL;
+	dw_pcie_writew_dbi(pci, offset + PCI_EXP_LNKCTL, val);
+}
+
+static void ls1021a_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
+	val |= PEXSR(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
+
+	regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val);
+	val &= ~PEXSR(pcie->index);
+	regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val);
+
+	mdelay(1);
+
+	ls_pcie_retrain_link(pcie);
+}
+static void ls1043a_pcie_exit_from_l2(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_WE;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val |= LDBG_SR;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_SR;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG);
+	val &= ~LDBG_WE;
+	ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val);
+
+	mdelay(1);
+
+	ls_pcie_retrain_link(pcie);
+}
+
+static int ls1021a_pcie_pm_init(struct ls_pcie *pcie)
+{
+	struct device *dev = pcie->pci->dev;
+	u32 index[2];
+	int ret;
+
+	pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
+						     "fsl,pcie-scfg");
+	if (IS_ERR(pcie->scfg)) {
+		ret = PTR_ERR(pcie->scfg);
+		dev_err(dev, "No syscfg phandle specified\n");
+		pcie->scfg = NULL;
+		return ret;
+	}
+
+	ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg",
+					 index, 2);
+	if (ret) {
+		pcie->scfg = NULL;
+		return ret;
+	}
+
+	pcie->index = index[1];
+
+	return 0;
+}
+
+static int ls_pcie_pm_init(struct ls_pcie *pcie)
+{
+	return 0;
+}
+
+static void ls_pcie_set_dstate(struct ls_pcie *pcie, u32 dstate)
+{
+	struct dw_pcie *pci = pcie->pci;
+	u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_PM);
+	u32 val;
+
+	val = dw_pcie_readw_dbi(pci, offset + PCI_PM_CTRL);
+	val &= ~PCI_PM_CTRL_STATE_MASK;
+	val |= dstate;
+	dw_pcie_writew_dbi(pci, offset + PCI_PM_CTRL, val);
+}
+
 static int ls_pcie_host_init(struct pcie_port *pp)
 {
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
@@ -91,22 +341,63 @@ static int ls_pcie_host_init(struct pcie_port *pp)
 
 	ls_pcie_drop_msg_tlp(pcie);
 
+	if (dw_pcie_link_up(pci)) {
+		dev_dbg(pci->dev, "Endpoint is present\n");
+		pcie->ep_presence = true;
+	}
+
+	if (pcie->drvdata->pm_ops && pcie->drvdata->pm_ops->pm_init &&
+	    !pcie->drvdata->pm_ops->pm_init(pcie))
+		pcie->pm_support = true;
+
 	return 0;
 }
 
+static struct ls_pcie_host_pm_ops ls1021a_pcie_host_pm_ops = {
+	.pm_init = &ls1021a_pcie_pm_init,
+	.send_turn_off_message = &ls1021a_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls1021a_pcie_exit_from_l2,
+};
+
+static struct ls_pcie_host_pm_ops ls1043a_pcie_host_pm_ops = {
+	.pm_init = &ls1021a_pcie_pm_init,
+	.send_turn_off_message = &ls1043a_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls1043a_pcie_exit_from_l2,
+};
+
+static struct ls_pcie_host_pm_ops ls_pcie_host_pm_ops = {
+	.pm_init = &ls_pcie_pm_init,
+	.send_turn_off_message = &ls_pcie_send_turnoff_msg,
+	.exit_from_l2 = &ls_pcie_exit_from_l2,
+};
+
 static const struct dw_pcie_host_ops ls_pcie_host_ops = {
 	.host_init = ls_pcie_host_init,
 };
 
+static const struct ls_pcie_drvdata ls1021a_drvdata = {
+	.ops = &ls_pcie_host_ops,
+	.pm_ops = &ls1021a_pcie_host_pm_ops,
+};
+
+static const struct ls_pcie_drvdata ls1043a_drvdata = {
+	.ops = &ls_pcie_host_ops,
+	.lut_off = 0x10000,
+	.pm_ops = &ls1043a_pcie_host_pm_ops,
+};
+
 static const struct ls_pcie_drvdata layerscape_drvdata = {
 	.ops = &ls_pcie_host_ops,
+	.lut_off = 0x80000,
+	.pf_off = 0xc0000,
+	.pm_ops = &ls_pcie_host_pm_ops,
 };
 
 static const struct of_device_id ls_pcie_of_match[] = {
 	{ .compatible = "fsl,ls1012a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1021a-pcie", .data = &layerscape_drvdata },
+	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021a_drvdata },
 	{ .compatible = "fsl,ls1028a-pcie", .data = &layerscape_drvdata },
-	{ .compatible = "fsl,ls1043a-pcie", .data = &layerscape_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 },
@@ -142,6 +433,14 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	if (IS_ERR(pci->dbi_base))
 		return PTR_ERR(pci->dbi_base);
 
+	pcie->big_endian = of_property_read_bool(dev->of_node, "big-endian");
+
+	if (pcie->drvdata->lut_off)
+		pcie->lut_base = pci->dbi_base + pcie->drvdata->lut_off;
+
+	if (pcie->drvdata->pf_off)
+		pcie->pf_base = pci->dbi_base + pcie->drvdata->pf_off;
+
 	if (!ls_pcie_is_bridge(pcie))
 		return -ENODEV;
 
@@ -150,12 +449,91 @@ static int ls_pcie_probe(struct platform_device *pdev)
 	return dw_pcie_host_init(&pci->pp);
 }
 
+static bool ls_pcie_pm_check(struct ls_pcie *pcie)
+{
+	if (!pcie->ep_presence) {
+		dev_dbg(pcie->pci->dev, "Endpoint isn't present\n");
+		return false;
+	}
+
+	if (!pcie->pm_support)
+		return false;
+
+	return true;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ls_pcie_suspend_noirq(struct device *dev)
+{
+	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	struct dw_pcie *pci = pcie->pci;
+	u32 val;
+	int ret;
+
+	if (!ls_pcie_pm_check(pcie))
+		return 0;
+
+	pcie->drvdata->pm_ops->send_turn_off_message(pcie);
+
+	/* 10ms timeout to check L2 ready */
+	ret = readl_poll_timeout(pci->dbi_base + PCIE_PORT_DEBUG0,
+				 val, LS_PCIE_IS_L2(val), 100, 10000);
+	if (ret) {
+		dev_err(dev, "PCIe link enter L2 timeout! ltssm = 0x%x\n", val);
+		return ret;
+	}
+
+	ls_pcie_set_dstate(pcie, 0x3);
+
+	return 0;
+}
+
+static int ls_pcie_resume_noirq(struct device *dev)
+{
+	struct ls_pcie *pcie = dev_get_drvdata(dev);
+	struct dw_pcie *pci = pcie->pci;
+	int ret;
+
+	if (!ls_pcie_pm_check(pcie))
+		return 0;
+
+	ls_pcie_set_dstate(pcie, 0x0);
+
+	pcie->drvdata->pm_ops->exit_from_l2(pcie);
+
+	dw_pcie_setup_rc(&pci->pp);
+
+	/* delay 10 ms to access EP */
+	mdelay(10);
+
+	ret = ls_pcie_host_init(&pci->pp);
+	if (ret) {
+		dev_err(dev, "ls_pcie_host_init failed! ret = 0x%x\n", ret);
+		return ret;
+	}
+
+	ret = dw_pcie_wait_for_link(pci);
+	if (ret) {
+		dev_err(dev, "wait link up timeout! ret = 0x%x\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops ls_pcie_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(ls_pcie_suspend_noirq,
+				      ls_pcie_resume_noirq)
+};
+
 static struct platform_driver ls_pcie_driver = {
 	.probe = ls_pcie_probe,
 	.driver = {
 		.name = "layerscape-pcie",
 		.of_match_table = ls_pcie_of_match,
 		.suppress_bind_attrs = true,
+		.pm = &ls_pcie_pm_ops,
 	},
 };
 builtin_platform_driver(ls_pcie_driver);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 7247c8b01f04..067b48a07100 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -54,6 +54,7 @@
 #define PCIE_PORT_DEBUG0		0x728
 #define PORT_LOGIC_LTSSM_STATE_MASK	0x1f
 #define PORT_LOGIC_LTSSM_STATE_L0	0x11
+#define PORT_LOGIC_LTSSM_STATE_L2	0x15
 #define PCIE_PORT_DEBUG1		0x72C
 #define PCIE_PORT_DEBUG1_LINK_UP		BIT(4)
 #define PCIE_PORT_DEBUG1_LINK_IN_TRAINING	BIT(29)
-- 
2.17.1



From tiantao6 at hisilicon.com  Wed Apr  7 04:15:39 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Wed, 7 Apr 2021 11:15:39 +0800
Subject: [PATCH] mmc: s3cmci: move to use request_irq by IRQF_NO_AUTOEN flag
Message-ID: <1617765339-28946-1-git-send-email-tiantao6@hisilicon.com>

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.

this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
 drivers/mmc/host/s3cmci.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 0ca6f6d..8d5929a 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -1578,17 +1578,12 @@ static int s3cmci_probe(struct platform_device *pdev)
 		goto probe_iounmap;
 	}
 
-	if (request_irq(host->irq, s3cmci_irq, 0, DRIVER_NAME, host)) {
+	if (request_irq(host->irq, s3cmci_irq, IRQF_NO_AUTOEN, DRIVER_NAME, host)) {
 		dev_err(&pdev->dev, "failed to request mci interrupt.\n");
 		ret = -ENOENT;
 		goto probe_iounmap;
 	}
 
-	/* We get spurious interrupts even when we have set the IMSK
-	 * register to ignore everything, so use disable_irq() to make
-	 * ensure we don't lock the system with un-serviceable requests. */
-
-	disable_irq(host->irq);
 	host->irq_state = false;
 
 	/* Depending on the dma state, get a DMA channel to use. */
-- 
2.7.4



From nobuhiro1.iwamatsu at toshiba.co.jp  Wed Apr  7 04:18:39 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Wed,  7 Apr 2021 12:18:39 +0900
Subject: [PATCH 3/3] MAINTAINERS: Add entries for Toshiba Visconti PCIe
 controller
In-Reply-To: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210407031839.386088-4-nobuhiro1.iwamatsu@toshiba.co.jp>

Add entries for Toshiba Visconti PCIe controller binding and driver.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a154939ae27..3e5187c5b8d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2621,11 +2621,13 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
 F:	Documentation/devicetree/bindings/arm/toshiba.yaml
 F:	Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
 F:	Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
+F:	Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
 F:	Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
 F:	Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
 F:	arch/arm64/boot/dts/toshiba/
 F:	drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
 F:	drivers/gpio/gpio-visconti.c
+F:	drivers/pci/controller/dwc/pcie-visconti.c
 F:	drivers/pinctrl/visconti/
 F:	drivers/watchdog/visconti_wdt.c
 N:	visconti
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Wed Apr  7 04:18:38 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Wed,  7 Apr 2021 12:18:38 +0900
Subject: [PATCH 2/3] PCI: dwc: Visoconti: PCIe RC controller driver
In-Reply-To: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210407031839.386088-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add support to PCIe RC controller on Toshiba Visconti ARM SoCs.
PCIe controller is based of Synopsys DesignWare PCIe core.

Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pci/controller/dwc/Kconfig         |  10 +
 drivers/pci/controller/dwc/Makefile        |   1 +
 drivers/pci/controller/dwc/pcie-visconti.c | 358 +++++++++++++++++++++
 3 files changed, 369 insertions(+)
 create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c

diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index b9aaa84452c4..ae125d7cf375 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -286,6 +286,16 @@ config PCIE_TEGRA194_EP
 	  in order to enable device-specific features PCIE_TEGRA194_EP must be
 	  selected. This uses the DesignWare core.
 
+config PCIE_VISCONTI
+	bool "Toshiba VISCONTI PCIe controllers"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	depends on OF && HAS_IOMEM
+	depends on PCI_MSI_IRQ_DOMAIN
+	select PCIE_DW_HOST
+	help
+	  Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
+	  This driver supports TMPV77xx.
+
 config PCIE_UNIPHIER
 	bool "Socionext UniPhier PCIe host controllers"
 	depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index ba7c42f6df6f..46ac5d49dc75 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
 obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
 obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
 obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
+obj-$(CONFIG_PCIE_VISCONTI) += pcie-visconti.o
 
 # The following drivers are for devices that use the generic ACPI
 # pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-visconti.c b/drivers/pci/controller/dwc/pcie-visconti.c
new file mode 100644
index 000000000000..e24f83df41b8
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-visconti.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DWC PCIe RC driver for Toshiba Visconti ARM SoC
+ *
+ * Copyright (C) 2019, 2020 Toshiba Electronic Device & Storage Corporation
+ * Copyright (C) 2020, TOSHIBA CORPORATION
+ *
+ * Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/resource.h>
+#include <linux/types.h>
+
+#include "pcie-designware.h"
+#include "../../pci.h"
+
+struct visconti_pcie {
+	struct dw_pcie *pci;
+	void __iomem *ulreg_base;
+	void __iomem *smu_base;
+	void __iomem *mpu_base;
+	struct clk *refclk;
+	struct clk *sysclk;
+	struct clk *auxclk;
+};
+
+#define PCIE_UL_REG_S_PCIE_MODE		0x00F4
+#define  PCIE_UL_REG_S_PCIE_MODE_EP	0x00
+#define  PCIE_UL_REG_S_PCIE_MODE_RC	0x04
+
+#define PCIE_UL_REG_S_PERSTN_CTRL	0x00F8
+#define  PCIE_UL_IOM_PCIE_PERSTN_I_EN	BIT(3)
+#define  PCIE_UL_DIRECT_PERSTN_EN	BIT(2)
+#define  PCIE_UL_PERSTN_OUT		BIT(1)
+#define  PCIE_UL_DIRECT_PERSTN		BIT(0)
+
+#define PCIE_UL_REG_S_PHY_INIT_02	0x0104
+#define  PCIE_UL_PHY0_SRAM_EXT_LD_DONE	BIT(0)
+
+#define PCIE_UL_REG_S_PHY_INIT_03	0x0108
+#define  PCIE_UL_PHY0_SRAM_INIT_DONE	BIT(0)
+
+#define PCIE_UL_REG_S_INT_EVENT_MASK1	0x0138
+#define  PCIE_UL_CFG_PME_INT		BIT(0)
+#define  PCIE_UL_CFG_LINK_EQ_REQ_INT	BIT(1)
+#define  PCIE_UL_EDMA_INT0		BIT(2)
+#define  PCIE_UL_EDMA_INT1		BIT(3)
+#define  PCIE_UL_EDMA_INT2		BIT(4)
+#define  PCIE_UL_EDMA_INT3		BIT(5)
+#define  PCIE_UL_S_INT_EVENT_MASK1_ALL  (PCIE_UL_CFG_PME_INT | PCIE_UL_CFG_LINK_EQ_REQ_INT | \
+					 PCIE_UL_EDMA_INT0 | PCIE_UL_EDMA_INT1 | \
+					 PCIE_UL_EDMA_INT2 | PCIE_UL_EDMA_INT3)
+
+#define PCIE_UL_REG_S_SB_MON		0x0198
+#define PCIE_UL_REG_S_SIG_MON		0x019C
+#define  PCIE_UL_CORE_RST_N_MON		BIT(0)
+
+#define PCIE_UL_REG_V_SII_DBG_00	0x0844
+#define PCIE_UL_REG_V_SII_GEN_CTRL_01	0x0860
+#define  PCIE_UL_APP_LTSSM_ENABLE	BIT(0)
+
+#define PCIE_UL_REG_V_PHY_ST_00		0x0864
+#define  PCIE_UL_SMLH_LINK_UP		BIT(0)
+
+#define PCIE_UL_REG_V_PHY_ST_02		0x0868
+#define  PCIE_UL_S_DETECT_ACT		0x01
+#define  PCIE_UL_S_L0			0x11
+
+#define PISMU_CKON_PCIE			0x0038
+#define  PISMU_CKON_PCIE_AUX_CLK	BIT(1)
+#define  PISMU_CKON_PCIE_MSTR_ACLK	BIT(0)
+
+#define PISMU_RSOFF_PCIE		0x0538
+#define  PISMU_RSOFF_PCIE_ULREG_RST_N	BIT(1)
+#define  PISMU_RSOFF_PCIE_PWR_UP_RST_N	BIT(0)
+
+#define PCIE_MPU_REG_MP_EN		0x0
+#define  MPU_MP_EN_DISABLE		BIT(0)
+
+#define PCIE_BUS_OFFSET			0x40000000
+
+/* Access registers in PCIe ulreg */
+static inline void visconti_ulreg_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel(val, pcie->ulreg_base + reg);
+}
+
+/* Access registers in PCIe smu */
+static inline void visconti_smu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel(val, pcie->smu_base + reg);
+}
+
+/* Access registers in PCIe mpu */
+static inline void visconti_mpu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel(val, pcie->mpu_base + reg);
+}
+
+static inline u32 visconti_mpu_readl(struct visconti_pcie *pcie, u32 reg)
+{
+	return readl(pcie->mpu_base + reg);
+}
+
+static int visconti_pcie_check_link_status(struct visconti_pcie *pcie)
+{
+	int err;
+	u32 val;
+
+	/* wait for linkup of phy link layer */
+	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_00, val,
+				 (val & PCIE_UL_SMLH_LINK_UP), 1000, 10000);
+	if (err)
+		return err;
+
+	/* wait for linkup of data link layer */
+	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
+				 (val & PCIE_UL_S_DETECT_ACT), 1000, 10000);
+	if (err)
+		return err;
+
+	/* wait for LTSSM Status */
+	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
+				  (val & PCIE_UL_S_L0), 1000, 10000);
+}
+
+static int visconti_pcie_establish_link(struct pcie_port *pp)
+{
+	int ret;
+	u32 val;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_APP_LTSSM_ENABLE, PCIE_UL_REG_V_SII_GEN_CTRL_01);
+
+	ret = visconti_pcie_check_link_status(pcie);
+	if (ret < 0) {
+		dev_info(pci->dev, "Link failure\n");
+		return ret;
+	}
+
+	val = visconti_mpu_readl(pcie, PCIE_MPU_REG_MP_EN);
+	visconti_mpu_writel(pcie, val & ~MPU_MP_EN_DISABLE, PCIE_MPU_REG_MP_EN);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_S_INT_EVENT_MASK1_ALL, PCIE_UL_REG_S_INT_EVENT_MASK1);
+
+	return 0;
+}
+
+static int visconti_pcie_host_init(struct pcie_port *pp)
+{
+	int ret;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+
+	dw_pcie_setup_rc(pp);
+	ret = visconti_pcie_establish_link(pp);
+	if (ret < 0)
+		return ret;
+
+	dw_pcie_wait_for_link(pci);
+
+	return 0;
+}
+
+static const struct dw_pcie_host_ops visconti_pcie_host_ops = {
+	.host_init = visconti_pcie_host_init,
+};
+
+static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 pci_addr)
+{
+	return pci_addr - PCIE_BUS_OFFSET;
+}
+
+static const struct dw_pcie_ops dw_pcie_ops = {
+	.cpu_addr_fixup = visconti_pcie_cpu_addr_fixup,
+};
+
+static int visconti_get_resources(struct platform_device *pdev,
+				  struct visconti_pcie *pcie)
+{
+	struct device *dev = &pdev->dev;
+
+	pcie->pci->dbi_base = devm_platform_ioremap_resource_byname(pdev, "dbi");
+	if (IS_ERR(pcie->pci->dbi_base))
+		return PTR_ERR(pcie->pci->dbi_base);
+
+	pcie->ulreg_base = devm_platform_ioremap_resource_byname(pdev, "ulreg");
+	if (IS_ERR(pcie->ulreg_base))
+		return PTR_ERR(pcie->ulreg_base);
+
+	pcie->smu_base = devm_platform_ioremap_resource_byname(pdev, "smu");
+	if (IS_ERR(pcie->smu_base))
+		return PTR_ERR(pcie->smu_base);
+
+	pcie->mpu_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
+	if (IS_ERR(pcie->mpu_base))
+		return PTR_ERR(pcie->mpu_base);
+
+	pcie->refclk = devm_clk_get(dev, "pcie_refclk");
+	if (IS_ERR(pcie->refclk)) {
+		dev_err(dev, "Failed to get refclk clock: %ld\n", PTR_ERR(pcie->refclk));
+		return PTR_ERR(pcie->refclk);
+	}
+
+	pcie->sysclk = devm_clk_get(dev, "sysclk");
+	if (IS_ERR(pcie->sysclk)) {
+		dev_err(dev, "Failed to get sysclk clock: %ld\n", PTR_ERR(pcie->sysclk));
+		return PTR_ERR(pcie->sysclk);
+	}
+
+	pcie->auxclk = devm_clk_get(dev, "auxclk");
+	if (IS_ERR(pcie->auxclk)) {
+		dev_err(dev, "Failed to get auxclk clock: %ld\n", PTR_ERR(pcie->auxclk));
+		return PTR_ERR(pcie->auxclk);
+	}
+
+	return 0;
+}
+
+static int visconti_device_turnon(struct visconti_pcie *pcie)
+{
+	int err;
+	u32 val;
+
+	visconti_smu_writel(pcie, PISMU_CKON_PCIE_AUX_CLK | PISMU_CKON_PCIE_MSTR_ACLK,
+			    PISMU_CKON_PCIE);
+	ndelay(250);
+
+	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_ULREG_RST_N, PISMU_RSOFF_PCIE);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_REG_S_PCIE_MODE_RC, PCIE_UL_REG_S_PCIE_MODE);
+
+	val = PCIE_UL_IOM_PCIE_PERSTN_I_EN | PCIE_UL_DIRECT_PERSTN_EN | PCIE_UL_DIRECT_PERSTN;
+	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
+	udelay(100);
+
+	val |= PCIE_UL_PERSTN_OUT;
+	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
+	udelay(100);
+
+	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_PWR_UP_RST_N, PISMU_RSOFF_PCIE);
+
+	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_PHY_INIT_03, val,
+				 (val & PCIE_UL_PHY0_SRAM_INIT_DONE), 100, 1000);
+	if (err)
+		return err;
+
+	visconti_ulreg_writel(pcie, PCIE_UL_PHY0_SRAM_EXT_LD_DONE, PCIE_UL_REG_S_PHY_INIT_02);
+
+	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_SIG_MON, val,
+				 (val & PCIE_UL_CORE_RST_N_MON), 100, 1000);
+}
+
+static int visconti_add_pcie_port(struct visconti_pcie *pcie, struct platform_device *pdev)
+{
+	struct dw_pcie *pci = pcie->pci;
+	struct pcie_port *pp = &pci->pp;
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	pp->irq = platform_get_irq_byname(pdev, "intr");
+	if (pp->irq < 0) {
+		dev_err(dev, "interrupt intr is missing");
+		return pp->irq;
+	}
+
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		pp->msi_irq = platform_get_irq_byname(pdev, "msi");
+		if (pp->msi_irq < 0) {
+			dev_err(dev, "interrupt msi is missing");
+			return pp->msi_irq;
+		}
+	}
+
+	pp->ops = &visconti_pcie_host_ops;
+
+	pci->link_gen = of_pci_get_max_link_speed(pdev->dev.of_node);
+	if (pci->link_gen < 0 || pci->link_gen > 3) {
+		pci->link_gen = 3;
+		dev_dbg(dev, "Applied default link speed\n");
+	}
+
+	dev_dbg(dev, "link speed Gen %d", pci->link_gen);
+
+	ret = visconti_device_turnon(pcie);
+	if (ret)
+		goto error;
+
+	ret = dw_pcie_host_init(pp);
+	if (ret)
+		dev_err(dev, "Failed to initialize host\n");
+
+error:
+	return ret;
+}
+
+static int visconti_pcie_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pcie *pcie;
+	struct pcie_port *pp;
+	struct dw_pcie *pci;
+	int ret;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(36));
+	if (ret)
+		return ret;
+
+	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+	if (!pci)
+		return -ENOMEM;
+
+	pp = &pci->pp;
+	pp->num_vectors = MAX_MSI_IRQS;
+
+	pci->dev = dev;
+	pci->ops = &dw_pcie_ops;
+	pcie->pci = pci;
+
+	ret = visconti_get_resources(pdev, pcie);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, pcie);
+
+	return visconti_add_pcie_port(pcie, pdev);
+}
+
+static const struct of_device_id visconti_pcie_match[] = {
+	{ .compatible = "toshiba,visconti-pcie" },
+	{},
+};
+
+static struct platform_driver visconti_pcie_driver = {
+	.probe = visconti_pcie_probe,
+	.driver = {
+		.name = "visconti-pcie",
+		.of_match_table = visconti_pcie_match,
+		.suppress_bind_attrs = true,
+	},
+};
+
+builtin_platform_driver(visconti_pcie_driver);
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Wed Apr  7 04:18:36 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Wed,  7 Apr 2021 12:18:36 +0900
Subject: [PATCH 0/3] PCI: dwc: Visoconti: PCIe RC controller driver
Message-ID: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PCIe driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files.

Best regards,
  Nobuhiro

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

Nobuhiro Iwamatsu (3):
  dt-bindings: pci: Add DT binding for Toshiba Visconti PCIe controller
  PCI: dwc: Visoconti: PCIe RC controller driver
  MAINTAINERS: Add entries for Toshiba Visconti PCIe controller

 .../bindings/pci/toshiba,visconti-pcie.yaml   | 121 ++++++
 MAINTAINERS                                   |   2 +
 drivers/pci/controller/dwc/Kconfig            |  10 +
 drivers/pci/controller/dwc/Makefile           |   1 +
 drivers/pci/controller/dwc/pcie-visconti.c    | 358 ++++++++++++++++++
 5 files changed, 492 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
 create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c

-- 
2.30.0.rc2


From nobuhiro1.iwamatsu at toshiba.co.jp  Wed Apr  7 04:18:37 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Wed,  7 Apr 2021 12:18:37 +0900
Subject: [PATCH 1/3] dt-bindings: pci: Add DT binding for Toshiba Visconti
 PCIe controller
In-Reply-To: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210407031839.386088-2-nobuhiro1.iwamatsu@toshiba.co.jp>

This commit adds the Device Tree binding documentation that allows
to describe the PCIe controller found in Toshiba Visconti SoCs.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 .../bindings/pci/toshiba,visconti-pcie.yaml   | 121 ++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
new file mode 100644
index 000000000000..8ab60c235007
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
@@ -0,0 +1,121 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+description: |+
+  Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP.
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+    const: toshiba,visconti-pcie
+
+  reg:
+    items:
+      - description: Data Bus Interface (DBI) registers.
+      - description: PCIe configuration space region.
+      - description: Visconti specific additional registers.
+      - description: Visconti specific SMU registers
+      - description: Visconti specific memory protection unit registers (MPU)
+
+  reg-names:
+    items:
+      - const: dbi
+      - const: config
+      - const: ulreg
+      - const: smu
+      - const: mpu
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PCIe reference clock
+      - description: PCIe system clock
+      - description: Auxiliary clock
+
+  clock-names:
+    items:
+      - const: pcie_refclk
+      - const: sysclk
+      - const: auxclk
+
+  num-lanes:
+    const: 2
+
+  num-viewport:
+    const: 8
+
+required:
+  - reg
+  - reg-names
+  - interrupts
+  - "#address-cells"
+  - "#size-cells"
+  - "#interrupt-cells"
+  - interrupt-map
+  - interrupt-map-mask
+  - ranges
+  - bus-range
+  - device_type
+  - num-lanes
+  - num-viewport
+  - clocks
+  - clock-names
+  - max-link-speed
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pcie: pcie at 28400000 {
+            compatible = "toshiba,visconti-pcie";
+            reg = <0x0 0x28400000 0x0 0x00400000>,
+                  <0x0 0x70000000 0x0 0x10000000>,
+                  <0x0 0x28050000 0x0 0x00010000>,
+                  <0x0 0x24200000 0x0 0x00002000>,
+                  <0x0 0x24162000 0x0 0x00001000>;
+            reg-names  = "dbi", "config", "ulreg", "smu", "mpu";
+            device_type = "pci";
+            bus-range = <0x00 0xff>;
+            num-lanes = <2>;
+            num-viewport = <8>;
+
+            #address-cells = <3>;
+            #size-cells = <2>;
+            #interrupt-cells = <1>;
+            ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>,
+                     <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>;
+            interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+            interrupt-names = "intr";
+            interrupt-map-mask = <0 0 0 7>;
+            interrupt-map =
+                <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>;
+            clock-names = "pcie_refclk", "sysclk", "auxclk";
+            max-link-speed = <2>;
+
+            status = "disabled";
+        };
+    };
+...
-- 
2.30.0.rc2



From guochun.mao at mediatek.com  Wed Apr  7 04:23:28 2021
From: guochun.mao at mediatek.com (Guochun Mao)
Date: Wed, 7 Apr 2021 11:23:28 +0800
Subject: [PATCH v1 1/1] ubifs: only check replay with inode type to
 judge if inode linked
In-Reply-To: <20210316085214.25024-2-guochun.mao@mediatek.com>
References: <20210316085214.25024-1-guochun.mao@mediatek.com>
 <20210316085214.25024-2-guochun.mao@mediatek.com>
Message-ID: <1617765808.4370.1.camel@mhfsdcap03>

Hi Richard,

Gentle ping.


On Tue, 2021-03-16 at 16:52 +0800, guochun.mao at mediatek.com wrote:
> From: Guochun Mao <guochun.mao at mediatek.com>
> 
> Conside the following case, it just write a big file into flash,
> when complete writing, delete the file, and then power off promptly.
> Next time power on, we'll get a replay list like:
> ...
> LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
> LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
> LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
> ...
> In the replay list, data nodes' deletion are 0, and the inode node's
> deletion is 1. In current logic, the file's dentry will be removed,
> but inode and the flash space it occupied will be reserved.
> User will see that much free space been disappeared.
> 
> We only need to check the deletion value of the following inode type
> node of the replay entry.
> 
> Signed-off-by: Guochun Mao <guochun.mao at mediatek.com>
> ---
>  fs/ubifs/replay.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 0f8a6a16421b..1929ec63a0cb 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
>  	 */
>  	list_for_each_entry_reverse(r, &c->replay_list, list) {
>  		ubifs_assert(c, r->sqnum >= rino->sqnum);
> -		if (key_inum(c, &r->key) == key_inum(c, &rino->key))
> +		if (key_inum(c, &r->key) == key_inum(c, &rino->key) &&
> +		    key_type(c, &r->key) == UBIFS_INO_KEY)
>  			return r->deletion == 0;
>  
>  	}


From flora.fu at mediatek.com  Wed Apr  7 04:27:58 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:27:58 +0800
Subject: [PATCH 0/8] Add Support for MediaTek MT8192 APU Power
Message-ID: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>

The MediaTek AI Processing Unit (APU) is a proprietary hardware
in the SoC to support AI operations.
The series is to create apusys in the SoC folder for developing
the related drivers. Add the apu clocks, basic apu nodes and the
power domain to provide the power controller of APU subsystem.

This series is based on MT8192 clock[1] and PMIC[2] patches.
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=454523
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=458733

Flora Fu (8):
  dt-bindings: clock: Add MT8192 APU clock bindings
  clk: mediatek: mt8192: Add APU clocks support
  dt-bindings: apu: Add MT8192 APU power domain
  dt-bindings: arm: mediatek: Add new document bindings for APU
  dt-bindings: soc: mediatek: apusys: Add new document for APU power
    domain
  soc: mediatek: apu: Add apusys and add apu power domain driver
  arm64: dts: mt8192: Add APU node
  arm64: dts: mt8192: Add APU power domain node

 .../arm/mediatek/mediatek,apusys.yaml         |  56 ++
 .../soc/mediatek/mediatek,apu-pm.yaml         | 146 +++++
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts   |   7 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |  46 ++
 drivers/clk/mediatek/clk-mt8192.c             |  91 +++
 drivers/soc/mediatek/Kconfig                  |  10 +
 drivers/soc/mediatek/Makefile                 |   1 +
 drivers/soc/mediatek/apusys/Makefile          |   2 +
 drivers/soc/mediatek/apusys/mtk-apu-pm.c      | 613 ++++++++++++++++++
 include/dt-bindings/clock/mt8192-clk.h        |  14 +-
 include/dt-bindings/power/mt8192-apu-power.h  |  11 +
 11 files changed, 995 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
 create mode 100644 drivers/soc/mediatek/apusys/Makefile
 create mode 100644 drivers/soc/mediatek/apusys/mtk-apu-pm.c
 create mode 100644 include/dt-bindings/power/mt8192-apu-power.h

-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:27:59 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:27:59 +0800
Subject: [PATCH 1/8] dt-bindings: clock: Add MT8192 APU clock bindings
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-2-git-send-email-flora.fu@mediatek.com>

Add clock bindings for APU on MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 include/dt-bindings/clock/mt8192-clk.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/dt-bindings/clock/mt8192-clk.h b/include/dt-bindings/clock/mt8192-clk.h
index ece5b4c0356c..71e07858f5dc 100644
--- a/include/dt-bindings/clock/mt8192-clk.h
+++ b/include/dt-bindings/clock/mt8192-clk.h
@@ -164,7 +164,15 @@
 #define CLK_TOP_APLL12_DIV9		152
 #define CLK_TOP_SSUSB_TOP_REF		153
 #define CLK_TOP_SSUSB_PHY_REF		154
-#define CLK_TOP_NR_CLK			155
+#define CLK_TOP_DSP_SEL			155
+#define CLK_TOP_DSP1_SEL		156
+#define CLK_TOP_DSP1_NPUPLL_SEL		157
+#define CLK_TOP_DSP2_SEL		158
+#define CLK_TOP_DSP2_NPUPLL_SEL		159
+#define CLK_TOP_DSP5_SEL		160
+#define CLK_TOP_DSP5_APUPLL_SEL		161
+#define CLK_TOP_IPU_IF_SEL		162
+#define CLK_TOP_NR_CLK			163
 
 /* INFRACFG */
 
@@ -309,7 +317,9 @@
 #define CLK_APMIXED_APLL1		8
 #define CLK_APMIXED_APLL2		9
 #define CLK_APMIXED_MIPID26M		10
-#define CLK_APMIXED_NR_CLK		11
+#define CLK_APMIXED_APUPLL		11
+#define CLK_APMIXED_NPUPLL		12
+#define CLK_APMIXED_NR_CLK		13
 
 /* SCP_ADSP */
 
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:01 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:01 +0800
Subject: [PATCH 3/8] dt-bindings: apu: Add MT8192 APU power domain
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-4-git-send-email-flora.fu@mediatek.com>

Create MT8192 APU power domain bindings.
Add top power domain id.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 include/dt-bindings/power/mt8192-apu-power.h | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 include/dt-bindings/power/mt8192-apu-power.h

diff --git a/include/dt-bindings/power/mt8192-apu-power.h b/include/dt-bindings/power/mt8192-apu-power.h
new file mode 100644
index 000000000000..b821bd4811a6
--- /dev/null
+++ b/include/dt-bindings/power/mt8192-apu-power.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT8192_APU_POWER_H
+#define _DT_BINDINGS_POWER_MT8192_APU_POWER_H
+
+#define MT8192_POWER_DOMAIN_APUSYS_TOP	0
+
+#endif
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:06 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:06 +0800
Subject: [PATCH 8/8] arm64: dts: mt8192: Add APU power domain node
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-9-git-send-email-flora.fu@mediatek.com>

Add APU power domain node to MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts |  7 +++++
 arch/arm64/boot/dts/mediatek/mt8192.dtsi    | 29 +++++++++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 1769f3a9b510..9e89efb3dc8a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -65,3 +65,10 @@
 &mt6359_vrf12_ldo_reg {
 	regulator-always-on;
 };
+
+&apuspm {
+	vsram-supply = <&mt6359_vsram_md_ldo_reg>;
+	power-domain at MT8192_POWER_DOMAIN_APUSYS_TOP {
+		domain-supply = <&mt6359_vproc1_buck_reg>;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index b1467ccbe5aa..546c058ef560 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -11,6 +11,7 @@
 #include <dt-bindings/memory/mt8192-larb-port.h>
 #include <dt-bindings/pinctrl/mt8192-pinfunc.h>
 #include <dt-bindings/power/mt8192-power.h>
+#include <dt-bindings/power/mt8192-apu-power.h>
 
 / {
 	compatible = "mediatek,mt8192";
@@ -1033,6 +1034,34 @@
 			#clock-cells = <1>;
 		};
 
+		apuspm: power-domain at 190f0000 {
+			compatible = "mediatek,mt8192-apu-pm", "syscon";
+			reg = <0 0x190f0000 0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#power-domain-cells = <1>;
+			mediatek,scpsys = <&scpsys>;
+			mediatek,apu_conn = <&apu_conn>;
+			mediatek,apu_vcore = <&apu_vcore>;
+
+			power-domain at MT8192_POWER_DOMAIN_APUSYS_TOP {
+				reg = <MT8192_POWER_DOMAIN_APUSYS_TOP>;
+				#power-domain-cells = <0>;
+				clocks = <&topckgen CLK_TOP_DSP_SEL>,
+					 <&topckgen CLK_TOP_IPU_IF_SEL>,
+					 <&clk26m>,
+					 <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+				clock-names = "clk_top_conn",
+					      "clk_top_ipu_if",
+					      "clk_off",
+					      "clk_on_default";
+				assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
+						  <&topckgen CLK_TOP_IPU_IF_SEL>;
+				assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
+							 <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+			};
+		};
+
 		larb13: larb at 1a001000 {
 			compatible = "mediatek,mt8192-smi-larb";
 			reg = <0 0x1a001000 0 0x1000>;
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:00 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:00 +0800
Subject: [PATCH 2/8] clk: mediatek: mt8192: Add APU clocks support
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-3-git-send-email-flora.fu@mediatek.com>

Add APU clocks support on MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 drivers/clk/mediatek/clk-mt8192.c | 91 +++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mt8192.c b/drivers/clk/mediatek/clk-mt8192.c
index bf6a2084a348..4eb61f006306 100644
--- a/drivers/clk/mediatek/clk-mt8192.c
+++ b/drivers/clk/mediatek/clk-mt8192.c
@@ -244,6 +244,65 @@ static const char * const ccu_parents[] = {
 	"univpll_d6_d2"
 };
 
+static const char * const dsp_parents[] = {
+	"clk26m",
+	"univpll_d6_d2",
+	"univpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mmpll_d4",
+	"mainpll_d3",
+	"univpll_d3"
+};
+
+static const char * const dsp1_parents[] = {
+	"clk26m",
+	"npupll_ck",
+	"mainpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mainpll_d3",
+	"univpll_d3",
+	"apupll_ck"
+};
+
+static const char * const dsp1_npupll_parents[] = {
+	"dsp1_sel",
+	"npupll_ck"
+};
+
+static const char * const dsp2_parents[] = {
+	"clk26m",
+	"npupll_ck",
+	"mainpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mainpll_d3",
+	"univpll_d3",
+	"apupll_ck"
+};
+
+static const char * const dsp2_npupll_parents[] = {
+	"dsp2_sel",
+	"npupll_ck"
+};
+
+static const char * const dsp5_parents[] = {
+	"clk26m",
+	"apupll_ck",
+	"univpll_d4_d2",
+	"mainpll_d4",
+	"univpll_d4",
+	"mmpll_d4",
+	"mainpll_d3",
+	"univpll_d3"
+};
+
+static const char * const dsp5_apupll_parents[] = {
+	"dsp5_sel",
+	"apupll_ck"
+};
+
 static const char * const dsp7_parents[] = {
 	"clk26m",
 	"mainpll_d4_d2",
@@ -255,6 +314,17 @@ static const char * const dsp7_parents[] = {
 	"mmpll_d4"
 };
 
+static const char * const ipu_if_parents[] = {
+	"clk26m",
+	"univpll_d6_d2",
+	"mainpll_d4_d2",
+	"univpll_d4_d2",
+	"univpll_d5",
+	"mainpll_d4",
+	"tvdpll_ck",
+	"univpll_d4"
+};
+
 static const char * const mfg_ref_parents[] = {
 	"clk26m",
 	"clk26m",
@@ -734,9 +804,26 @@ static const struct mtk_mux top_mtk_muxes[] = {
 		cam_parents, 0x030, 0x034, 0x038, 16, 4, 23, 0x004, 10),
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_CCU_SEL, "ccu_sel",
 		ccu_parents, 0x030, 0x034, 0x038, 24, 4, 31, 0x004, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP_SEL, "dsp_sel",
+		dsp_parents, 0x040, 0x044, 0x048, 0, 3, 7, 0x004, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP1_SEL, "dsp1_sel",
+		dsp1_parents, 0x040, 0x044, 0x048, 8, 3, 15, 0x004, 13),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP1_NPUPLL_SEL, "dsp1_npupll_sel",
+		dsp1_npupll_parents, 0x040, 0x044, 0x048, 11, 1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP2_SEL, "dsp2_sel",
+		dsp2_parents, 0x040, 0x044, 0x048, 16, 3, 23, 0x004, 14),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP2_NPUPLL_SEL, "dsp2_npupll_sel",
+		dsp2_npupll_parents, 0x040, 0x044, 0x048, 19, 1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP5_SEL, "dsp5_sel",
+		dsp5_parents, 0x040, 0x044, 0x048, 24, 3, 31, 0x004, 15),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP5_APUPLL_SEL, "dsp5_apupll_sel",
+		dsp5_apupll_parents, 0x040, 0x044, 0x048, 27, 1, -1, -1),
 	/* CLK_CFG_4 */
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP7_SEL, "dsp7_sel",
 		dsp7_parents, 0x050, 0x054, 0x058, 0, 3, 7, 0x004, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_IPU_IF_SEL, "ipu_if_sel",
+		ipu_if_parents, 0x050, 0x054, 0x058, 8, 3, 15, 0x004, 17),
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_MFG_REF_SEL, "mfg_ref_sel",
 		mfg_ref_parents, 0x050, 0x054, 0x058, 16, 2, 23, 0x004, 18),
 	MUX_CLR_SET_UPD(CLK_TOP_MFG_PLL_SEL, "mfg_pll_sel",
@@ -1175,6 +1262,10 @@ static const struct mtk_pll_data plls[] = {
 		0, 0, 32, 0x031c, 24, 0x0040, 0x000c, 0, 0x0320, 0),
 	PLL_B(CLK_APMIXED_APLL2, "apll2", 0x032c, 0x033c, 0x00000000,
 		0, 0, 32, 0x0330, 24, 0, 0, 0, 0x0334, 0),
+	PLL_B(CLK_APMIXED_APUPLL, "apupll", 0x03a0, 0x03ac, 0xff000001,
+		HAVE_RST_BAR, BIT(23), 22, 0x03a4, 24, 0, 0, 0, 0x03a4, 0),
+	PLL_B(CLK_APMIXED_NPUPLL, "npupll", 0x03b4, 0x03c0, 0x00000001,
+		0, 0, 22, 0x03b8, 24, 0, 0, 0, 0x03b8, 0),
 };
 
 static struct clk_onecell_data *top_clk_data;
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:04 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:04 +0800
Subject: [PATCH 6/8] soc: mediatek: apu: Add apusys and add apu power domain
 driver
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-7-git-send-email-flora.fu@mediatek.com>

Add the apusys in soc.
Add driver for apu power domains.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 drivers/soc/mediatek/Kconfig             |  10 +
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/apusys/Makefile     |   2 +
 drivers/soc/mediatek/apusys/mtk-apu-pm.c | 613 +++++++++++++++++++++++
 4 files changed, 626 insertions(+)
 create mode 100644 drivers/soc/mediatek/apusys/Makefile
 create mode 100644 drivers/soc/mediatek/apusys/mtk-apu-pm.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..76ee7e354b27 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -5,6 +5,16 @@
 menu "MediaTek SoC drivers"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_APUSYS
+	bool "MediaTek APUSYS Support"
+	select REGMAP
+	select PM_GENERIC_DOMAINS if PM
+	help
+	  Say yes here to add support for the MediaTek AI Processing Unit
+	  Subsystem(APUSYS).
+	  The APUSYS is a proprietary hardware in SoC to support AI
+	  operations.
+
 config MTK_CMDQ
 	tristate "MediaTek CMDQ Support"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index c916b6799baa..4ca2d59b75cb 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_MTK_APUSYS) += apusys/
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
diff --git a/drivers/soc/mediatek/apusys/Makefile b/drivers/soc/mediatek/apusys/Makefile
new file mode 100644
index 000000000000..01c339e35b80
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_MTK_APUSYS) += mtk-apu-pm.o
diff --git a/drivers/soc/mediatek/apusys/mtk-apu-pm.c b/drivers/soc/mediatek/apusys/mtk-apu-pm.c
new file mode 100644
index 000000000000..37f481692cbb
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/mtk-apu-pm.c
@@ -0,0 +1,613 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_clk.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <dt-bindings/power/mt8192-apu-power.h>
+
+#define APU_PD_IPUIF_HW_CG		BIT(0)
+#define APU_PD_RPC_AUTO_BUCK		BIT(1)
+#define APU_PD_CAPS(_pd, _x)		((_pd)->data->caps & (_x))
+
+#define MTK_POLL_DELAY_US               10
+#define MTK_POLL_TIMEOUT                USEC_PER_SEC
+
+/*spm_cross_wake_m01*/
+#define WAKEUP_APU		(0x1 << 0)
+
+/* spm_other_pwr_status*/
+#define PWR_STATUS		(0x1 << 5)
+
+/* rpc_intf_pwr_rdy */
+#define PWR0_RDY		(0x1 << 0)
+
+/* rpc_top_con*/
+#define SLEEP_REQ		BIT(0)
+#define APU_BUCK_ELS_EN		BIT(3)
+
+/*conn_clr, conn1_clr, vcore_clr */
+#define CG_CLR	(0xFFFFFFFF)
+
+/* mt8192 rpc_sw_type */
+#define MT8192_RPC_SW_TYPE0	(0x200)
+#define MT8192_RPC_SW_TYPE1	(0x210)
+#define MT8192_RPC_SW_TYPE2	(0x220)
+#define MT8192_RPC_SW_TYPE3	(0x230)
+#define MT8192_RPC_SW_TYPE4	(0x240)
+#define MT8192_RPC_SW_TYPE6	(0x260)
+#define MT8192_RPC_SW_TYPE7	(0x270)
+
+/* rpc_sw_type*/
+static const struct reg_sequence mt8192_rpc_sw_type[] = {
+	{ MT8192_RPC_SW_TYPE0, 0xFF },
+	{ MT8192_RPC_SW_TYPE2, 0x7 },
+	{ MT8192_RPC_SW_TYPE3, 0x7 },
+	{ MT8192_RPC_SW_TYPE6, 0x3 },
+};
+
+struct apu_top_domain {
+	u32 spm_ext_buck_iso;
+	u32 spm_ext_buck_iso_mask;
+	u32 spm_cross_wake_m01;
+	u32 spm_other_pwr;
+	u32 conn_clr;
+	u32 conn1_clr;
+	u32 vcore_clr;
+	u32 rpc_top_con;
+	u32 rpc_top_con_init_mask;
+	u32 rpc_top_sel;
+	u32 rpc_top_intf_pwr_rdy;
+	const struct reg_sequence *rpc_sw_type;
+	int rpc_sw_ntype;
+};
+
+static struct apu_top_domain mt8192_top_reg = {
+	.spm_ext_buck_iso = 0x39C,
+	.spm_ext_buck_iso_mask = 0x21,
+	.spm_cross_wake_m01 = 0x670,
+	.spm_other_pwr = 0x178,
+	.conn_clr = 0x008,
+	.vcore_clr = 0x008,
+	.rpc_top_con = 0x000,
+	.rpc_top_con_init_mask = 0x49E,
+	.rpc_top_sel = 0x004,
+	.rpc_top_intf_pwr_rdy = 0x044,
+	.rpc_sw_type = mt8192_rpc_sw_type,
+	.rpc_sw_ntype = ARRAY_SIZE(mt8192_rpc_sw_type),
+};
+
+struct apusys {
+	struct device *dev;
+	struct regmap *scpsys;
+	struct regmap *conn;
+	struct regmap *conn1;
+	struct regmap *vcore;
+	struct regmap *rpc;
+	struct regulator *vsram_supply;
+	const struct apu_pm_data *data;
+	struct genpd_onecell_data pd_data;
+	struct generic_pm_domain *domains[];
+};
+
+struct apu_domain {
+	struct generic_pm_domain genpd;
+	const struct apu_domain_data *data;
+	struct apusys *apusys;
+	struct regulator *domain_supply;
+	int num_clks;
+	struct clk_bulk_data *clks;
+	struct clk *clk_top_conn;
+	struct clk *clk_top_ipu_if;
+	struct clk *clk_off;
+	struct clk *clk_on_def;
+};
+
+struct apu_domain_data {
+	int domain_idx;
+	char *name;
+	struct apu_top_domain *topd;
+	u8 caps;
+};
+
+struct apu_pm_data {
+	const struct apu_domain_data *domains_data;
+	int num_domains;
+};
+
+#define to_apu_domain(gpd) container_of(gpd, struct apu_domain, genpd)
+
+static int apu_top_init_hw(struct apu_domain *pd)
+{
+	struct apusys *apusys = pd->apusys;
+	int ret;
+
+	/*
+	 * set memory type to PD or sleep group
+	 * sw_type register for each memory group, set to PD mode default
+	 */
+	if (pd->data->topd->rpc_sw_ntype) {
+		ret = regmap_register_patch(apusys->rpc,
+					    pd->data->topd->rpc_sw_type,
+					    pd->data->topd->rpc_sw_ntype);
+		if (ret < 0) {
+			dev_err(apusys->dev, "Failed to rpc patch: %d\n", ret);
+			return ret;
+		}
+	}
+
+	/* mask RPC IRQ and bypass WFI */
+	regmap_set_bits(apusys->rpc, pd->data->topd->rpc_top_sel,
+			pd->data->topd->rpc_top_con_init_mask);
+
+	if (APU_PD_CAPS(pd, APU_PD_RPC_AUTO_BUCK))
+		regmap_set_bits(apusys->rpc,
+				pd->data->topd->rpc_top_con, APU_BUCK_ELS_EN);
+
+	return 0;
+}
+
+static const struct apu_domain_data apu_domain_data_mt8192[] = {
+	[MT8192_POWER_DOMAIN_APUSYS_TOP] = {
+		.domain_idx = 0,
+		.name = "apu-top",
+		.caps = APU_PD_IPUIF_HW_CG,
+		.topd = &mt8192_top_reg,
+	}
+};
+
+static const struct apu_pm_data mt8192_apu_pm_data = {
+	.domains_data = apu_domain_data_mt8192,
+	.num_domains = ARRAY_SIZE(apu_domain_data_mt8192),
+};
+
+static int apu_top_power_on(struct generic_pm_domain *genpd)
+{
+	struct apu_domain *pd = to_apu_domain(genpd);
+	struct apusys *apusys = pd->apusys;
+	int ret, tmp;
+
+	if (apusys->vsram_supply) {
+		ret = regulator_enable(apusys->vsram_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	if (pd->domain_supply) {
+		ret = regulator_enable(pd->domain_supply);
+		if (ret < 0)
+			goto err_regulator;
+	}
+
+	regmap_clear_bits(apusys->scpsys, pd->data->topd->spm_ext_buck_iso,
+			  pd->data->topd->spm_ext_buck_iso_mask);
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		ret = clk_prepare_enable(pd->clk_top_conn);
+		if (ret) {
+			dev_err(apusys->dev, "Failed enable top_conn clk\n");
+			goto err_clk;
+		}
+
+		ret = clk_set_parent(pd->clk_top_ipu_if, pd->clk_on_def);
+		if (ret) {
+			dev_err(apusys->dev, "Failed set ipu_if mux\n");
+			goto err_clk;
+		}
+
+		/* The ipu_if clock is gatting by HW. Only enable once. */
+		if (!__clk_is_enabled(pd->clk_top_ipu_if)) {
+			ret = clk_prepare_enable(pd->clk_top_ipu_if);
+			if (ret) {
+				dev_err(apusys->dev, "Failed enable ipu_if\n");
+				goto err_clk;
+			}
+		}
+	} else {
+		ret = clk_bulk_prepare_enable(pd->num_clks, pd->clks);
+		if (ret)
+			goto err_clk;
+	}
+
+	regmap_set_bits(apusys->scpsys,
+			pd->data->topd->spm_cross_wake_m01, WAKEUP_APU);
+
+	ret = regmap_read_poll_timeout(apusys->scpsys,
+				       pd->data->topd->spm_other_pwr,
+				       tmp, (tmp & PWR_STATUS) == PWR_STATUS,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top on wait SPM PWR_ACK != 0\n");
+		goto err_clk;
+	}
+
+	ret = regmap_read_poll_timeout(apusys->rpc,
+				       pd->data->topd->rpc_top_intf_pwr_rdy,
+				       tmp, (tmp & PWR0_RDY) == PWR0_RDY,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top on wait RPC PWR_RDY != 0\n");
+		goto err_clk;
+	}
+
+	if (apusys->vcore)
+		regmap_write(apusys->vcore, pd->data->topd->vcore_clr, CG_CLR);
+
+	if (apusys->conn)
+		regmap_write(apusys->conn, pd->data->topd->conn_clr, CG_CLR);
+
+	if (apusys->conn1)
+		regmap_write(apusys->conn1, pd->data->topd->conn1_clr, CG_CLR);
+
+	return 0;
+
+err_clk:
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_disable_unprepare(pd->clk_top_conn);
+		clk_disable_unprepare(pd->clk_top_ipu_if);
+	} else {
+		clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
+	}
+	if (pd->domain_supply)
+		ret = regulator_disable(pd->domain_supply);
+err_regulator:
+	if (apusys->vsram_supply)
+		ret = regulator_disable(apusys->vsram_supply);
+
+	return ret;
+}
+
+static int apu_top_power_off(struct generic_pm_domain *genpd)
+{
+	struct apu_domain *pd = to_apu_domain(genpd);
+	struct apusys *apusys = pd->apusys;
+	int ret, tmp;
+
+	if (apusys->vcore)
+		regmap_write(apusys->vcore, pd->data->topd->vcore_clr, CG_CLR);
+
+	if (apusys->conn)
+		regmap_write(apusys->conn, pd->data->topd->conn_clr, CG_CLR);
+
+	if (apusys->conn1)
+		regmap_write(apusys->conn1, pd->data->topd->conn1_clr, CG_CLR);
+
+	regmap_clear_bits(apusys->scpsys,
+			  pd->data->topd->spm_cross_wake_m01, WAKEUP_APU);
+
+	regmap_set_bits(apusys->rpc, pd->data->topd->rpc_top_con, SLEEP_REQ);
+
+	ret = regmap_read_poll_timeout(apusys->rpc,
+				       pd->data->topd->rpc_top_intf_pwr_rdy,
+				       tmp, (tmp & PWR0_RDY) == 0x0,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top off wait RPC PWR_RDY != 0\n");
+		return ret;
+	}
+
+	ret = regmap_read_poll_timeout(apusys->scpsys,
+				       pd->data->topd->spm_other_pwr, tmp,
+				       (tmp & PWR_STATUS) == 0x0,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top off wait SPM PWR_ACK != 0\n");
+		return ret;
+	}
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_disable_unprepare(pd->clk_top_conn);
+		ret = clk_set_parent(pd->clk_top_ipu_if, pd->clk_off);
+		if (ret) {
+			dev_err(apusys->dev, "Failed set ipu_if rate\n");
+			return ret;
+		}
+	} else {
+		clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
+	}
+
+	regmap_set_bits(apusys->scpsys,
+			pd->data->topd->spm_ext_buck_iso,
+			pd->data->topd->spm_ext_buck_iso_mask);
+
+	if (apusys->vsram_supply) {
+		ret = regulator_disable(apusys->vsram_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	if (pd->domain_supply) {
+		ret = regulator_disable(pd->domain_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+static struct generic_pm_domain *apu_add_one_domain(struct apusys *apusys,
+						    struct device_node *node)
+{
+	const struct apu_domain_data *domain_data;
+	struct apu_domain *pd;
+	int ret;
+	u32 id;
+
+	ret = of_property_read_u32(node, "reg", &id);
+	if (ret) {
+		dev_dbg(apusys->dev, "%pOF: invalid reg: %d\n", node, ret);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (id >= apusys->data->num_domains) {
+		dev_dbg(apusys->dev, "%pOF: invalid id %d\n", node, id);
+		return ERR_PTR(-EINVAL);
+	}
+
+	domain_data = &apusys->data->domains_data[id];
+
+	pd = devm_kzalloc(apusys->dev, sizeof(*pd), GFP_KERNEL);
+	if (!pd)
+		return ERR_PTR(-ENOMEM);
+
+	pd->data   = domain_data;
+	pd->apusys = apusys;
+
+	pd->domain_supply = devm_regulator_get_optional(apusys->dev, "domain");
+	if (IS_ERR(pd->domain_supply))
+		pd->domain_supply = NULL;
+
+	/*
+	 * For HW using ipu_if, the clock is switched to 26M
+	 * when power down top domain and switch to default clock rate
+	 * before power on.
+	 */
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		pd->clk_top_conn = of_clk_get_by_name(node, "clk_top_conn");
+		if (IS_ERR(pd->clk_top_conn)) {
+			dev_err(apusys->dev, "Fail to get clk_top_conn clock\n");
+			ret = PTR_ERR(pd->clk_top_conn);
+			goto err_put_clocks;
+		}
+
+		pd->clk_top_ipu_if = of_clk_get_by_name(node, "clk_top_ipu_if");
+		if (IS_ERR(pd->clk_top_ipu_if)) {
+			dev_err(apusys->dev, "Fail to get clk_top_ipu_if clock\n");
+			ret = PTR_ERR(pd->clk_top_ipu_if);
+			goto err_put_clocks;
+		}
+
+		pd->clk_off = of_clk_get_by_name(node, "clk_off");
+		if (IS_ERR(pd->clk_off)) {
+			dev_err(apusys->dev, "Fail to get clk_off clock\n");
+			ret = PTR_ERR(pd->clk_off);
+			goto err_put_clocks;
+		}
+
+		pd->clk_on_def = of_clk_get_by_name(node, "clk_on_default");
+		if (IS_ERR(pd->clk_on_def)) {
+			dev_err(apusys->dev, "Fail to get clk_on_default clock\n");
+			ret = PTR_ERR(pd->clk_on_def);
+			goto err_put_clocks;
+		}
+	} else {
+		ret = devm_clk_bulk_get_all(apusys->dev, &pd->clks);
+		if (ret < 0) {
+			dev_err(apusys->dev, "failed to get clocks %d\n", ret);
+			return ERR_PTR(ret);
+		}
+		pd->num_clks = ret;
+	}
+
+	if (apusys->domains[id]) {
+		ret = -EINVAL;
+		dev_err(apusys->dev, "domain id %d already exists\n", id);
+		goto err_put_clocks;
+	}
+
+	/* set rpc hw init status */
+	ret = apu_top_init_hw(pd);
+	if (ret < 0) {
+		dev_dbg(apusys->dev, "top init fail ret = %d\n", ret);
+		goto err_put_clocks;
+	}
+
+	if (!pd->data->name)
+		pd->genpd.name = node->name;
+	else
+		pd->genpd.name = pd->data->name;
+	pd->genpd.power_off = apu_top_power_off;
+	pd->genpd.power_on = apu_top_power_on;
+
+	/*
+	 * Initially turn on all domains to make the domains usable
+	 * with !CONFIG_PM and to get the hardware in sync with the
+	 * software.  The unused domains will be switched off during
+	 * late_init time.
+	 */
+	ret = pd->genpd.power_on(&pd->genpd);
+	if (ret < 0) {
+		dev_dbg(apusys->dev, "%pOF: power on domain fail: %d\n",
+			node, ret);
+		goto err_put_clocks;
+	}
+
+	pm_genpd_init(&pd->genpd, NULL, false);
+
+	apusys->domains[id] = &pd->genpd;
+
+	return apusys->pd_data.domains[id];
+
+err_put_clocks:
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_put(pd->clk_top_conn);
+		clk_put(pd->clk_top_ipu_if);
+		clk_put(pd->clk_off);
+		clk_put(pd->clk_on_def);
+	}
+	return ERR_PTR(ret);
+}
+
+static void apu_remove_one_domain(struct apu_domain *pd)
+{
+	int ret;
+
+	if (pd->genpd.power_off)
+		pd->genpd.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.
+	 */
+	ret = pm_genpd_remove(&pd->genpd);
+	if (ret < 0)
+		dev_dbg(pd->apusys->dev,
+			"Remove domain '%s' : %d - state may be inconsistent\n",
+			pd->genpd.name, ret);
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_put(pd->clk_top_conn);
+		clk_put(pd->clk_top_ipu_if);
+		clk_put(pd->clk_off);
+		clk_put(pd->clk_on_def);
+	}
+}
+
+static void apu_domain_cleanup(struct apusys *apusys)
+{
+	struct generic_pm_domain *genpd;
+	struct apu_domain *pd;
+	int i;
+
+	for (i = apusys->pd_data.num_domains - 1; i >= 0; i--) {
+		genpd = apusys->pd_data.domains[i];
+		if (genpd) {
+			pd = to_apu_domain(genpd);
+			apu_remove_one_domain(pd);
+		}
+	}
+}
+
+static const struct of_device_id apu_pm_of_match[] = {
+	{
+		.compatible = "mediatek,mt8192-apu-pm",
+		.data = &mt8192_apu_pm_data,
+	},
+	{ }
+};
+
+static int apu_pm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct genpd_onecell_data *pd_data;
+	const struct apu_pm_data *data;
+	struct device_node *node;
+	struct apusys *apusys;
+	int ret;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data) {
+		dev_dbg(&pdev->dev, "no power domain data\n");
+		return -EINVAL;
+	}
+
+	apusys = devm_kzalloc(dev,
+			      struct_size(apusys, domains, data->num_domains),
+			      GFP_KERNEL);
+	if (!apusys)
+		return -ENOMEM;
+
+	apusys->dev = dev;
+	apusys->data = data;
+	apusys->pd_data.domains = apusys->domains;
+	apusys->pd_data.num_domains = data->num_domains;
+
+	apusys->vsram_supply = devm_regulator_get_optional(dev, "vsram");
+	if (IS_ERR(apusys->vsram_supply)) {
+		ret = PTR_ERR(apusys->vsram_supply);
+		if (ret != -EPROBE_DEFER) {
+			dev_err(dev, "vsram_supply fail, ret=%d", ret);
+			apusys->vsram_supply = NULL;
+		}
+		return ret;
+	}
+
+	/* rpc */
+	apusys->rpc = syscon_node_to_regmap(np);
+	if (IS_ERR(apusys->rpc)) {
+		dev_err(dev, "Unable to get rpc\n");
+		return PTR_ERR(apusys->rpc);
+	}
+
+	/* scpsys */
+	apusys->scpsys = syscon_regmap_lookup_by_phandle(np, "mediatek,scpsys");
+	if (IS_ERR(apusys->scpsys)) {
+		dev_err(dev, "Unable to get scpsys\n");
+		return PTR_ERR(apusys->scpsys);
+	}
+
+	/* apusys conn */
+	apusys->conn = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu_conn");
+	if (IS_ERR(apusys->conn))
+		dev_info(dev, "No optional phandle apu_conn\n");
+
+	/* apusys conn1 */
+	apusys->conn1 = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu_conn1");
+	if (IS_ERR(apusys->conn1))
+		dev_info(dev, "No optional phandle apu_conn1\n");
+
+	/* apusys vcore */
+	apusys->vcore = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu_vcore");
+	if (IS_ERR(apusys->vcore))
+		dev_info(dev, "No optional phandle apu_vcore\n");
+
+	for_each_available_child_of_node(np, node) {
+		struct generic_pm_domain *domain;
+
+		domain = apu_add_one_domain(apusys, node);
+		if (IS_ERR(domain)) {
+			ret = PTR_ERR(domain);
+			of_node_put(node);
+			goto err_cleanup_domains;
+		}
+	}
+
+	ret = of_genpd_add_provider_onecell(np, &apusys->pd_data);
+	if (ret) {
+		dev_dbg(dev, "failed to add provider: %d\n", ret);
+		goto err_cleanup_domains;
+	}
+
+	pd_data = &apusys->pd_data;
+
+	return 0;
+
+err_cleanup_domains:
+	apu_domain_cleanup(apusys);
+	return ret;
+}
+
+static struct platform_driver apu_pm_driver = {
+	.probe = apu_pm_probe,
+	.driver = {
+		.name = "mtk-apu-pm",
+		.suppress_bind_attrs = true,
+		.of_match_table = apu_pm_of_match,
+	},
+};
+builtin_platform_driver(apu_pm_driver);
+
-- 
2.18.0

From leoyang.li at nxp.com  Wed Apr  7 04:38:46 2021
From: leoyang.li at nxp.com (Leo Li)
Date: Wed, 7 Apr 2021 03:38:46 +0000
Subject: [PATCH v6] soc: fsl: enable acpi support in RCPM driver
In-Reply-To: <AM6PR04MB5413E08499BE566F67AA62ABF1759@AM6PR04MB5413.eurprd04.prod.outlook.com>
References: <20210312085822.12136-1-ran.wang_1@nxp.com>
 <CADRPPNRv_T9o=Kg4dCJ6jFPxOWMY24wgDXCzyTpz3oh_yL+4Tw@mail.gmail.com>
 <AM6PR04MB5413E08499BE566F67AA62ABF1759@AM6PR04MB5413.eurprd04.prod.outlook.com>
Message-ID: <VI1PR04MB447896C7673D9B3F77ED3D9C8F759@VI1PR04MB4478.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Ran Wang <ran.wang_1 at nxp.com>
> Sent: Tuesday, April 6, 2021 8:32 PM
> To: Leo Li <leoyang.li at nxp.com>
> Cc: Christophe Leroy <christophe.leroy at csgroup.eu>; linuxppc-dev
> <linuxppc-dev at lists.ozlabs.org>; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; lkml <linux-
> kernel at vger.kernel.org>
> Subject: RE: [PATCH v6] soc: fsl: enable acpi support in RCPM driver
> 
> Hi Leo,
> 
> On Wednesday, April 7, 2021 5:45 AM, Li Yang wrote:
> >
> > On Fri, Mar 12, 2021 at 2:56 AM Ran Wang <ran.wang_1 at nxp.com> wrote:
> > >
> > > From: Peng Ma <peng.ma at nxp.com>
> > >
> > > This patch enables ACPI support in RCPM driver.
> > >
> > > Signed-off-by: Peng Ma <peng.ma at nxp.com>
> > > Signed-off-by: Ran Wang <ran.wang_1 at nxp.com>
> > > ---
> > > Change in v6:
> > >  - Remove copyright udpate to rebase on latest mainline
> > >
> > > Change in v5:
> > >  - Fix panic when dev->of_node is null
> > >
> > > Change in v4:
> > >  - Make commit subject more accurate
> > >  - Remove unrelated new blank line
> > >
> > > Change in v3:
> > >  - Add #ifdef CONFIG_ACPI for acpi_device_id
> > >  - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
> > >
> > > Change in v2:
> > >  - Update acpi_device_id to fix conflict with other driver
> > >
> > >  drivers/soc/fsl/rcpm.c | 18 ++++++++++++++++--
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> > > 4ace28cab314..7aa997b932d1 100644
> > > --- a/drivers/soc/fsl/rcpm.c
> > > +++ b/drivers/soc/fsl/rcpm.c
> > > @@ -13,6 +13,7 @@
> > >  #include <linux/slab.h>
> > >  #include <linux/suspend.h>
> > >  #include <linux/kernel.h>
> > > +#include <linux/acpi.h>
> > >
> > >  #define RCPM_WAKEUP_CELL_MAX_SIZE      7
> > >
> > > @@ -78,10 +79,14 @@ static int rcpm_pm_prepare(struct device *dev)
> > >                                 "fsl,rcpm-wakeup", value,
> > >                                 rcpm->wakeup_cells + 1);
> > >
> > > -               /*  Wakeup source should refer to current rcpm device */
> > > -               if (ret || (np->phandle != value[0]))
> > > +               if (ret)
> > >                         continue;
> > >
> > > +               if (is_of_node(dev->fwnode))
> > > +                       /*  Should refer to current rcpm device */

Better to be /* Only handle devices with fsl,rcpm-wakeup pointing to the current rcpm node*/
> > > +                       if (np->phandle != value[0])
> > > +                               continue;
> >
> > It looks like that we assume that in the ACPI scenario there will only
> > be one RCPM controller and all devices are controlled by this single
> > PM controller.  This probably is true for all existing SoCs with a RCPM.  But
> since the driver tried to support multiple RCPMs, maybe we should continue
> to support multiple RCPM controllers or at least mention that in the
> comment.
> 
> How about adding some comment as below:
> 
> /* For ACPI mode, currently we assume there is only one RCPM controller
> existing */

Ok.  On the other hand, it will be clearer to update the existing comment above.

> 
> Regards,
> Ran
> 
> >
> > > +
> > >                 /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
> > >                  * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
> > >                  * of wakeup source IP contains an integer array:
> > > <phandle to @@ -172,10 +177,19 @@ static const struct of_device_id
> > > rcpm_of_match[] = {  };  MODULE_DEVICE_TABLE(of, rcpm_of_match);
> > >
> > > +#ifdef CONFIG_ACPI
> > > +static const struct acpi_device_id rcpm_acpi_ids[] = {
> > > +       {"NXP0015",},
> > > +       { }
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids); #endif
> > > +
> > >  static struct platform_driver rcpm_driver = {
> > >         .driver = {
> > >                 .name = "rcpm",
> > >                 .of_match_table = rcpm_of_match,
> > > +               .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> > >                 .pm     = &rcpm_pm_ops,
> > >         },
> > >         .probe = rcpm_probe,
> > > --
> > > 2.25.1
> > >

From flora.fu at mediatek.com  Wed Apr  7 04:28:05 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:05 +0800
Subject: [PATCH 7/8] arm64: dts: mt8192: Add APU node
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-8-git-send-email-flora.fu@mediatek.com>

Add APU node to MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index eb17274c3719..b1467ccbe5aa 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1016,6 +1016,23 @@
 			#clock-cells = <1>;
 		};
 
+		apu_mbox: apu_mbox at 19000000 {
+			compatible = "mediatek,mt8192-apu_mbox", "syscon";
+			reg = <0 0x19000000 0 0x1000>;
+		};
+
+		apu_conn: apu_conn at 19020000 {
+			compatible = "mediatek,mt8192-apu_conn", "syscon";
+			reg = <0 0x19020000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
+		apu_vcore: apu_vcore at 19029000 {
+			compatible = "mediatek,mt8192-apu_vcore", "syscon";
+			reg = <0 0x19029000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
 		larb13: larb at 1a001000 {
 			compatible = "mediatek,mt8192-smi-larb";
 			reg = <0 0x1a001000 0 0x1000>;
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:02 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:02 +0800
Subject: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document bindings for
 APU
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>

Document the apusys bindings.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
new file mode 100644
index 000000000000..dc04a46f1bad
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek APUSYS Controller
+
+maintainers:
+  - Flora Fu <flora.fu at mediatek.com>
+
+description:
+  The Mediatek apusys controller provides functional configurations and clocks
+  to the system.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8192-apu_mbox
+          - mediatek,mt8192-apu_conn
+          - mediatek,mt8192-apu_vcore
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    apu_mbox: apu_mbox at 19000000 {
+        compatible = "mediatek,mt8192-apu_mbox", "syscon";
+        reg = <0x19000000 0x1000>;
+    };
+
+  - |
+    apu_conn: apu_conn at 19020000 {
+        compatible = "mediatek,mt8192-apu_conn", "syscon";
+        reg = <0x19020000 0x1000>;
+        #clock-cells = <1>;
+    };
+
+  - |
+    apu_vcore: apu_vcore at 19029000 {
+        compatible = "mediatek,mt8192-apu_vcore", "syscon";
+        reg = <0x19029000 0x1000>;
+        #clock-cells = <1>;
+    };
-- 
2.18.0

From flora.fu at mediatek.com  Wed Apr  7 04:28:03 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Wed, 7 Apr 2021 11:28:03 +0800
Subject: [PATCH 5/8] dt-bindings: soc: mediatek: apusys: Add new document for
 APU power domain
In-Reply-To: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617766086-5502-6-git-send-email-flora.fu@mediatek.com>

Document the bindings for APU power domain on MediaTek SoC.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 .../soc/mediatek/mediatek,apu-pm.yaml         | 146 ++++++++++++++++++
 1 file changed, 146 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
new file mode 100644
index 000000000000..c99e812977f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
@@ -0,0 +1,146 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek APU Power Domains
+
+maintainers:
+  - Flora Fu <flora.fu at mediatek.com>
+
+description: |
+  Mediatek AI Process Unit (APU) include support for power domains which can be
+  powered up/down by software.
+  APU subsys belonging to a power domain should contain a 'power-domains'
+  property that is a phandle for apuspm node representing the domain.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8192-apu-pm
+      - const: syscon
+
+  reg:
+    description: Address range of the APU power domain controller.
+    maxItems: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  '#power-domain-cells':
+    const: 1
+
+  vsram-supply:
+    description: apu sram regulator supply.
+
+  mediatek,scpsys:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys register range.
+
+  mediatek,apu_conn:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu conn register range.
+
+  mediatek,apu_conn1:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu conn1 register range.
+
+  mediatek,apu_vcore:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu vcore register range.
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+    type: object
+    description: |
+      Represents the power domains within the power controller node as
+      documented in Documentation/devicetree/bindings/power/power-domain.yaml.
+
+    properties:
+      reg:
+        description: |
+          Power domain index. Valid values are defined in:
+          "include/dt-bindings/power/mt8182-apu-power.h"
+        maxItems: 1
+
+      '#power-domain-cells':
+        description: |
+          Must be 0 for nodes representing a single PM domain and 1 for nodes
+          providing multiple PM.
+
+      clocks:
+        description: |
+          List of phandles of clocks list. Specify by order according to
+          power-up sequence.
+
+      clock-names:
+        description: |
+          List of names of clocks. Specify by order according to power-up
+          sequence.
+
+      assigned-clocks:
+        maxItems: 2
+
+      assigned-clock-parents:
+        maxItems: 2
+
+      domain-supply:
+        description: domain regulator supply.
+
+    required:
+      - reg
+      - '#power-domain-cells'
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - '#power-domain-cells'
+  - vsram-supply
+  - mediatek,scpsys
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8192-clk.h>
+    #include <dt-bindings/power/mt8192-apu-power.h>
+    apuspm: power-domain at 190f0000 {
+        compatible = "mediatek,mt8192-apu-pm", "syscon";
+        reg = <0x190f0000 0x1000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        #power-domain-cells = <1>;
+        vsram-supply = <&mt6359_vsram_md_ldo_reg>;
+        mediatek,scpsys = <&scpsys>;
+        mediatek,apu_conn = <&apu_conn>;
+        mediatek,apu_vcore = <&apu_vcore>;
+
+        power-domain at MT8192_POWER_DOMAIN_APUSYS_TOP {
+            reg = <MT8192_POWER_DOMAIN_APUSYS_TOP>;
+            #power-domain-cells = <0>;
+            clocks = <&topckgen CLK_TOP_DSP_SEL>,
+                     <&topckgen CLK_TOP_IPU_IF_SEL>,
+                     <&clk26m>,
+                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+            clock-names = "clk_top_conn",
+                          "clk_top_ipu_if",
+                          "clk_off",
+                          "clk_on_default";
+            assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
+                              <&topckgen CLK_TOP_IPU_IF_SEL>;
+            assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
+                                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+            domain-supply = <&mt6359_vproc1_buck_reg>;
+        };
+    };
-- 
2.18.0

From christianshewitt at gmail.com  Wed Apr  7 05:26:08 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Wed,  7 Apr 2021 04:26:08 +0000
Subject: [PATCH v2 2/3] arm64: dts: meson: add saradc node to ODROID N2/N2+
In-Reply-To: <20210407042609.9736-1-christianshewitt@gmail.com>
References: <20210407042609.9736-1-christianshewitt@gmail.com>
Message-ID: <20210407042609.9736-3-christianshewitt@gmail.com>

From: Hyeonki Hong <hhk7734 at gmail.com>

Add the meson saradc node to the ODROID N2/N2+ common dtsi.

Signed-off-by: Hyeonki Hong <hhk7734 at gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
---
 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

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 2f8d574c30c0..0a994668e707 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
@@ -508,6 +508,11 @@
 	status = "okay";
 };
 
+&saradc {
+	status = "okay";
+	vref-supply = <&vddao_1v8>;
+};
+
 /* SD card */
 &sd_emmc_b {
 	status = "okay";
-- 
2.17.1



From christianshewitt at gmail.com  Wed Apr  7 05:26:06 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Wed,  7 Apr 2021 04:26:06 +0000
Subject: [PATCH v2 0/3] arm64: dts: meson: misc ODROID-N2/N2+ changes
Message-ID: <20210407042609.9736-1-christianshewitt@gmail.com>

This series cleans-up and submits some minor patches used in HardKernel
Linux 5.10 and 5.11 images for the ODROID N2/N2+, and fixes a stray tab.

Changes since v1:

- Added reviewed-by's on patches 1/3
- Added my Signed-off-by to patches 2/3
- Added missing vref to patch 2
- Rebased on khilman/v5.13/dt64

Christian Hewitt (1):
  arm64: dts: meson: remove extra tab from ODROID N2/N2+ ext_mdio node

Hyeonki Hong (2):
  arm64: dts: meson: add saradc node to ODROID N2/N2+
  arm64: dts: meson: add GPIO line names to ODROID N2/N2+

 .../dts/amlogic/meson-g12b-odroid-n2.dtsi     | 52 ++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

-- 
2.17.1



From christianshewitt at gmail.com  Wed Apr  7 05:26:07 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Wed,  7 Apr 2021 04:26:07 +0000
Subject: [PATCH v2 1/3] arm64: dts: meson: remove extra tab from ODROID N2/N2+
 ext_mdio node
In-Reply-To: <20210407042609.9736-1-christianshewitt@gmail.com>
References: <20210407042609.9736-1-christianshewitt@gmail.com>
Message-ID: <20210407042609.9736-2-christianshewitt@gmail.com>

Remove an extra tab from the ext_mdio node in the ODROID N2/N2+ common
dtsi file.

Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
---
 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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 58ce569b2ace..2f8d574c30c0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
@@ -410,7 +410,7 @@
 
 &ext_mdio {
 	external_phy: ethernet-phy at 0 {
-		/* Realtek RTL8211F (0x001cc916) */	
+		/* Realtek RTL8211F (0x001cc916) */
 		reg = <0>;
 		max-speed = <1000>;
 
-- 
2.17.1



From christianshewitt at gmail.com  Wed Apr  7 05:26:09 2021
From: christianshewitt at gmail.com (Christian Hewitt)
Date: Wed,  7 Apr 2021 04:26:09 +0000
Subject: [PATCH v2 3/3] arm64: dts: meson: add GPIO line names to ODROID N2/N2+
In-Reply-To: <20210407042609.9736-1-christianshewitt@gmail.com>
References: <20210407042609.9736-1-christianshewitt@gmail.com>
Message-ID: <20210407042609.9736-4-christianshewitt@gmail.com>

From: Hyeonki Hong <hhk7734 at gmail.com>

Add GPIO line-name identifiers to the ODROID N2/N2+ common dtsi.

Signed-off-by: Hyeonki Hong <hhk7734 at gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
---
 .../dts/amlogic/meson-g12b-odroid-n2.dtsi     | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)

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 0a994668e707..473b81c652cf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi
@@ -446,6 +446,51 @@
 };
 
 &gpio {
+	gpio-line-names =
+		/* GPIOZ */
+		"", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "",
+		/* GPIOH */
+		"", "", "", "", "", "", "", "",
+		"",
+		/* BOOT */
+		"", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "",
+		/* GPIOC */
+		"", "", "", "", "", "", "", "",
+		/* GPIOA */
+		"PIN_44", /* GPIOA_0 */
+		"PIN_46", /* GPIOA_1 */
+		"PIN_45", /* GPIOA_2 */
+		"PIN_47", /* GPIOA_3 */
+		"PIN_26", /* GPIOA_4 */
+		"", "", "", "", "", "",
+		"PIN_42", /* GPIOA_11 */
+		"PIN_32", /* GPIOA_12 */
+		"PIN_7",  /* GPIOA_13 */
+		"PIN_27", /* GPIOA_14 */
+		"PIN_28", /* GPIOA_15 */
+		/* GPIOX */
+		"PIN_16", /* GPIOX_0 */
+		"PIN_18", /* GPIOX_1 */
+		"PIN_22", /* GPIOX_2 */
+		"PIN_11", /* GPIOX_3 */
+		"PIN_13", /* GPIOX_4 */
+		"PIN_33", /* GPIOX_5 */
+		"PIN_35", /* GPIOX_6 */
+		"PIN_15", /* GPIOX_7 */
+		"PIN_19", /* GPIOX_8 */
+		"PIN_21", /* GPIOX_9 */
+		"PIN_24", /* GPIOX_10 */
+		"PIN_23", /* GPIOX_11 */
+		"PIN_8",  /* GPIOX_12 */
+		"PIN_10", /* GPIOX_13 */
+		"PIN_29", /* GPIOX_14 */
+		"PIN_31", /* GPIOX_15 */
+		"PIN_12", /* GPIOX_16 */
+		"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
-- 
2.17.1



From dinghao.liu at zju.edu.cn  Wed Apr  7 06:34:02 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Wed,  7 Apr 2021 13:34:02 +0800
Subject: [PATCH] dmaengine: stm32: Fix rumtime PM imbalance in
 stm32_dmamux_resume
Message-ID: <20210407053402.3750-1-dinghao.liu@zju.edu.cn>

pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---
 drivers/dma/stm32-dmamux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
index ef0d0555103d..f9258a63b9c3 100644
--- a/drivers/dma/stm32-dmamux.c
+++ b/drivers/dma/stm32-dmamux.c
@@ -361,7 +361,7 @@ static int stm32_dmamux_resume(struct device *dev)
 	if (ret < 0)
 		return ret;
 
-	ret = pm_runtime_get_sync(dev);
+	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0)
 		return ret;
 
-- 
2.17.1



From gregkh at linuxfoundation.org  Wed Apr  7 06:34:09 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed,  7 Apr 2021 07:34:09 +0200
Subject: [PATCH 10/20] kbuild: arm: use common install script
In-Reply-To: <20210407053419.449796-1-gregkh@linuxfoundation.org>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
Message-ID: <20210407053419.449796-11-gregkh@linuxfoundation.org>

The common scripts/install.sh script will now work for arm, all that
is needed is to add the compressed image type to it.  So add that file
type check and the ability to call /sbin/loadmap after copying the
kernel.  With that we can remove the arm-only version of the file.

Cc: Russell King <linux at armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/Makefile   |  6 ++--
 arch/arm/boot/install.sh | 66 ----------------------------------------
 scripts/install.sh       | 10 +++++-
 3 files changed, 12 insertions(+), 70 deletions(-)
 delete mode 100644 arch/arm/boot/install.sh

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 0b3cd7a33a26..053187f0b714 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -104,15 +104,15 @@ initrd:
 	(echo You must specify INITRD; exit -1)
 
 install:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
+	$(CONFIG_SHELL) $(srctree)/scripts/install.sh "$(KERNELRELEASE)" \
 	$(obj)/Image System.map "$(INSTALL_PATH)"
 
 zinstall:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
+	$(CONFIG_SHELL) $(srctree)/scripts/install.sh "$(KERNELRELEASE)" \
 	$(obj)/zImage System.map "$(INSTALL_PATH)"
 
 uinstall:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
+	$(CONFIG_SHELL) $(srctree)/scripts/install.sh "$(KERNELRELEASE)" \
 	$(obj)/uImage System.map "$(INSTALL_PATH)"
 
 subdir-	    := bootp compressed dts
diff --git a/arch/arm/boot/install.sh b/arch/arm/boot/install.sh
deleted file mode 100644
index 2a45092a40e3..000000000000
--- a/arch/arm/boot/install.sh
+++ /dev/null
@@ -1,66 +0,0 @@
-#!/bin/sh
-#
-# arch/arm/boot/install.sh
-#
-# This file is subject to the terms and conditions of the GNU General Public
-# License.  See the file "COPYING" in the main directory of this archive
-# for more details.
-#
-# Copyright (C) 1995 by Linus Torvalds
-#
-# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
-# Adapted from code in arch/i386/boot/install.sh by Russell King
-#
-# "make install" script for arm architecture
-#
-# Arguments:
-#   $1 - kernel version
-#   $2 - kernel image file
-#   $3 - kernel map file
-#   $4 - default install path (blank if root directory)
-#
-
-verify () {
-	if [ ! -f "$1" ]; then
-		echo ""                                                   1>&2
-		echo " *** Missing file: $1"                              1>&2
-		echo ' *** You need to run "make" before "make install".' 1>&2
-		echo ""                                                   1>&2
-		exit 1
-	fi
-}
-
-# Make sure the files actually exist
-verify "$2"
-verify "$3"
-
-# User may have a custom install script
-if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
-if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-
-if [ "$(basename $2)" = "zImage" ]; then
-# Compressed install
-  echo "Installing compressed kernel"
-  base=vmlinuz
-else
-# Normal install
-  echo "Installing normal kernel"
-  base=vmlinux
-fi
-
-if [ -f $4/$base-$1 ]; then
-  mv $4/$base-$1 $4/$base-$1.old
-fi
-cat $2 > $4/$base-$1
-
-# Install system map file
-if [ -f $4/System.map-$1 ]; then
-  mv $4/System.map-$1 $4/System.map-$1.old
-fi
-cp $3 $4/System.map-$1
-
-if [ -x /sbin/loadmap ]; then
-  /sbin/loadmap
-else
-  echo "You have to install it yourself"
-fi
diff --git a/scripts/install.sh b/scripts/install.sh
index 9c8a22d96255..73067b535ea0 100644
--- a/scripts/install.sh
+++ b/scripts/install.sh
@@ -51,7 +51,8 @@ if [ -x /sbin/"${INSTALLKERNEL}" ]; then exec /sbin/"${INSTALLKERNEL}" "$@"; fi
 
 base=$(basename "$2")
 if [ "$base" = "bzImage" ] ||
-   [ "$base" = "Image.gz" ] ; then
+   [ "$base" = "Image.gz" ] ||
+   [ "$base" = "zImage" ] ; then
 	# Compressed install
 	echo "Installing compressed kernel"
 	base=vmlinuz
@@ -78,6 +79,13 @@ sync
 
 # Some architectures like to call specific bootloader "helper" programs:
 case "${ARCH}" in
+	arm)
+		if [ -x /sbin/loadmap ]; then
+			/sbin/loadmap
+		else
+			echo "You have to install it yourself"
+		fi
+		;;
 	x86)
 		if [ -x /sbin/lilo ]; then
 			/sbin/lilo
-- 
2.31.1



From gregkh at linuxfoundation.org  Wed Apr  7 06:34:08 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed,  7 Apr 2021 07:34:08 +0200
Subject: [PATCH 09/20] kbuild: arm64: use common install script
In-Reply-To: <20210407053419.449796-1-gregkh@linuxfoundation.org>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
Message-ID: <20210407053419.449796-10-gregkh@linuxfoundation.org>

The common scripts/install.sh script will now work for arm65, no changes
needed so convert the arm64 boot Makefile to call it instead of the
arm64-only version of the file and remove the now unused file.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm64/boot/Makefile   |  4 +--
 arch/arm64/boot/install.sh | 60 --------------------------------------
 2 files changed, 2 insertions(+), 62 deletions(-)
 delete mode 100644 arch/arm64/boot/install.sh

diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index cd3414898d10..08c56332dde2 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -37,9 +37,9 @@ $(obj)/Image.lzo: $(obj)/Image FORCE
 	$(call if_changed,lzo)
 
 install:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+	$(CONFIG_SHELL) $(srctree)/scripts/install.sh $(KERNELRELEASE) \
 	$(obj)/Image System.map "$(INSTALL_PATH)"
 
 zinstall:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
+	$(CONFIG_SHELL) $(srctree)/scripts/install.sh $(KERNELRELEASE) \
 	$(obj)/Image.gz System.map "$(INSTALL_PATH)"
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
deleted file mode 100644
index d91e1f022573..000000000000
--- a/arch/arm64/boot/install.sh
+++ /dev/null
@@ -1,60 +0,0 @@
-#!/bin/sh
-#
-# arch/arm64/boot/install.sh
-#
-# This file is subject to the terms and conditions of the GNU General Public
-# License.  See the file "COPYING" in the main directory of this archive
-# for more details.
-#
-# Copyright (C) 1995 by Linus Torvalds
-#
-# Adapted from code in arch/i386/boot/Makefile by H. Peter Anvin
-# Adapted from code in arch/i386/boot/install.sh by Russell King
-#
-# "make install" script for the AArch64 Linux port
-#
-# Arguments:
-#   $1 - kernel version
-#   $2 - kernel image file
-#   $3 - kernel map file
-#   $4 - default install path (blank if root directory)
-#
-
-verify () {
-	if [ ! -f "$1" ]; then
-		echo ""                                                   1>&2
-		echo " *** Missing file: $1"                              1>&2
-		echo ' *** You need to run "make" before "make install".' 1>&2
-		echo ""                                                   1>&2
-		exit 1
-	fi
-}
-
-# Make sure the files actually exist
-verify "$2"
-verify "$3"
-
-# User may have a custom install script
-if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
-if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-
-if [ "$(basename $2)" = "Image.gz" ]; then
-# Compressed install
-  echo "Installing compressed kernel"
-  base=vmlinuz
-else
-# Normal install
-  echo "Installing normal kernel"
-  base=vmlinux
-fi
-
-if [ -f $4/$base-$1 ]; then
-  mv $4/$base-$1 $4/$base-$1.old
-fi
-cat $2 > $4/$base-$1
-
-# Install system map file
-if [ -f $4/System.map-$1 ]; then
-  mv $4/System.map-$1 $4/System.map-$1.old
-fi
-cp $3 $4/System.map-$1
-- 
2.31.1



From kjain at linux.ibm.com  Wed Apr  7 06:39:03 2021
From: kjain at linux.ibm.com (kajoljain)
Date: Wed, 7 Apr 2021 11:09:03 +0530
Subject: [PATCH v2 1/6] perf metricgroup: Make find_metric() public with
 name change
In-Reply-To: <4b406e70-9ff6-dd26-d9b7-78b094041651@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
 <1616668398-144648-2-git-send-email-john.garry@huawei.com>
 <CAP-5=fVMfK5-rGtx1QjTLz6AQeGr0ruyxuwC3ADt4kriU9wz0A@mail.gmail.com>
 <4b406e70-9ff6-dd26-d9b7-78b094041651@huawei.com>
Message-ID: <e5fc65ef-b146-e677-43de-42482c755441@linux.ibm.com>



On 4/6/21 3:24 PM, John Garry wrote:
> On 02/04/2021 00:16, Ian Rogers wrote:
>> On Thu, Mar 25, 2021 at 3:38 AM John Garry <john.garry at huawei.com> wrote:
>>>
>>> Function find_metric() is required for the metric processing in the
>>> pmu-events testcase, so make it public. Also change the name to include
>>> "metricgroup".
>>
>> Would it make more sense as "pmu_events_map__find_metric" ?
>>
> 
> So all functions apart from one in metricgroup.h are named metricgroup__XXX, so I was trying to keep this style - apart from the double-underscore (which can be remedied).
> 
> Personally I don't think pmu_events_map__find_metric name fits with that convention.

I agree, most of the functions in metricgroup.c named as metricgroup__xxx. May be something like metricgroup__find_metric will be better.

Thanks,
Kajol Jain

> 
> Thanks,
> John
> 
>> Thanks,
>> Ian
>>
>>> Signed-off-by: John Garry <john.garry at huawei.com>
>>> ---
>>> ? tools/perf/util/metricgroup.c | 5 +++--
>>> ? tools/perf/util/metricgroup.h | 3 ++-
>>> ? 2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
>>> index 6acb44ad439b..71a13406e0bd 100644
>>> --- a/tools/perf/util/metricgroup.c
>>> +++ b/tools/perf/util/metricgroup.c
>>> @@ -900,7 +900,8 @@ static int __add_metric(struct list_head *metric_list,
>>> ???????????????????? (match_metric(__pe->metric_group, __metric) ||????? \
>>> ????????????????????? match_metric(__pe->metric_name, __metric)))
>>>
>>> -static struct pmu_event *find_metric(const char *metric, struct pmu_events_map *map)
>>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>>> +??????????????????????????????????????? struct pmu_events_map *map)
>>> ? {
>>> ???????? struct pmu_event *pe;
>>> ???????? int i;
>>> @@ -985,7 +986,7 @@ static int __resolve_metric(struct metric *m,
>>> ???????????????????????? struct expr_id *parent;
>>> ???????????????????????? struct pmu_event *pe;
>>>
>>> -?????????????????????? pe = find_metric(cur->key, map);
>>> +?????????????????????? pe = metrcgroup_find_metric(cur->key, map);
>>> ???????????????????????? if (!pe)
>>> ???????????????????????????????? continue;
>>>
>>> diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
>>> index ed1b9392e624..1674c6a36d74 100644
>>> --- a/tools/perf/util/metricgroup.h
>>> +++ b/tools/perf/util/metricgroup.h
>>> @@ -44,7 +44,8 @@ int metricgroup__parse_groups(const struct option *opt,
>>> ?????????????????????????????? bool metric_no_group,
>>> ?????????????????????????????? bool metric_no_merge,
>>> ?????????????????????????????? struct rblist *metric_events);
>>> -
>>> +struct pmu_event *metrcgroup_find_metric(const char *metric,
>>> +??????????????????????????????????????? struct pmu_events_map *map);
>>> ? int metricgroup__parse_groups_test(struct evlist *evlist,
>>> ??????????????????????????????????? struct pmu_events_map *map,
>>> ??????????????????????????????????? const char *str,
>>> -- 
>>> 2.26.2
>>>
>> .
>>
> 


From dinghao.liu at zju.edu.cn  Wed Apr  7 06:46:06 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Wed,  7 Apr 2021 13:46:06 +0800
Subject: [PATCH] media: sun8i-di: Fix rumtime PM imbalance in
 deinterlace_start_streaming
Message-ID: <20210407054606.6252-1-dinghao.liu@zju.edu.cn>

pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---
 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 ed863bf5ea80..671e4a928993 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -589,7 +589,7 @@ static int deinterlace_start_streaming(struct vb2_queue *vq, unsigned int count)
 	int ret;
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 
-- 
2.17.1



From kernelfans at gmail.com  Wed Apr  7 07:00:15 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Wed, 7 Apr 2021 14:00:15 +0800
Subject: [PATCH] arm64/mm: remove useless trans_pgd_map_page()
In-Reply-To: <CA+CK2bC+irJLOBatFpJJYfZgt6AP5Nu9w3irDVpH-NJ06pGL4g@mail.gmail.com>
References: <20210406131420.56262-1-kernelfans@gmail.com>
 <CA+CK2bC+irJLOBatFpJJYfZgt6AP5Nu9w3irDVpH-NJ06pGL4g@mail.gmail.com>
Message-ID: <CAFgQCTu==P_E84SYiRNBOX0qEOooNjF3KbifW5y_xPAHiO_apQ@mail.gmail.com>

On Wed, Apr 7, 2021 at 12:58 AM Pavel Tatashin
<pasha.tatashin at soleen.com> wrote:
>
> Hi Pingfan,
>
> On Tue, Apr 6, 2021 at 9:14 AM Pingfan Liu <kernelfans at gmail.com> wrote:
> >
> > Since the commit 7018d467ff2d ("arm64: trans_pgd: hibernate: idmap the
> > single page that holds the copy page routines"), trans_pgd_map_page() is
> > useless.
>
> Let's keep this function for now. This function is used in my version
> 11 of mmu enabled kexec patches; but not used in version 12 where we
> changed to a linear map instead of contiguous map. However, until the
> final solution for mmu-enabled kexec lands in the mainline, I think it
> is better to keep it.
>
Got it.

Thanks,
Pingfan


From kjain at linux.ibm.com  Wed Apr  7 07:03:19 2021
From: kjain at linux.ibm.com (kajoljain)
Date: Wed, 7 Apr 2021 11:33:19 +0530
Subject: [PATCH v2 0/6] perf arm64 metricgroup support
In-Reply-To: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
References: <1616668398-144648-1-git-send-email-john.garry@huawei.com>
Message-ID: <0c8379f9-c073-ebf8-5335-812f9b30c6cd@linux.ibm.com>



On 3/25/21 4:03 PM, John Garry wrote:
> This series contains support to get basic metricgroups working for
> arm64 CPUs.
> 
> Initial support is added for HiSilicon hip08 platform.
> 
> Some sample usage on Huawei D06 board:
> 
>  $ ./perf list metric    
> 
> List of pre-defined events (to be used in -e): 
> 
> Metrics:     
> 
>   bp_misp_flush
>        [BP misp flush L3 topdown metric]
>   branch_mispredicts
>        [Branch mispredicts L2 topdown metric]
>   core_bound
>        [Core bound L2 topdown metric]
>   divider
>        [Divider L3 topdown metric]
>   exe_ports_util
>        [EXE ports util L3 topdown metric]
>   fetch_bandwidth_bound
>        [Fetch bandwidth bound L2 topdown metric]
>   fetch_latency_bound
>        [Fetch latency bound L2 topdown metric]
>   fsu_stall
>        [FSU stall L3 topdown metric]
>   idle_by_icache_miss
> 
> $ sudo ./perf stat -v -M core_bound sleep 1
> Using CPUID 0x00000000480fd010
> metric expr (exe_stall_cycle - (mem_stall_anyload + armv8_pmuv3_0 at event\=0x7005@)) / cpu_cycles for core_bound
> found event cpu_cycles
> found event armv8_pmuv3_0/event=0x7005/
> found event exe_stall_cycle
> found event mem_stall_anyload
> adding {cpu_cycles -> armv8_pmuv3_0/event=0x7001/
> mem_stall_anyload -> armv8_pmuv3_0/event=0x7004/
> Control descriptor is not initialized
> cpu_cycles: 989433 385050 385050
> armv8_pmuv3_0/event=0x7005/: 19207 385050 385050
> exe_stall_cycle: 900825 385050 385050
> mem_stall_anyload: 253516 385050 385050
> 
> Performance counter stats for 'sleep':
> 
> 989,433      cpu_cycles      #     0.63 core_bound
>   19,207      armv8_pmuv3_0/event=0x7005/
>  900,825      exe_stall_cycle
>  253,516      mem_stall_anyload
> 
>        0.000805809 seconds time elapsed
> 
>        0.000875000 seconds user
>        0.000000000 seconds sys
>        
> perf stat --topdown is not supported, as this requires the CPU PMU to
> expose (alias) events for the TopDown L1 metrics from sysfs, which arm 
> does not do. To get that to work, we probably need to make perf use the
> pmu-events cpumap to learn about those alias events.
> 
> Metric reuse support is added for pmu-events parse metric testcase.
> This had been broken on power9 recentlty:
> https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/ 

Patch set looks good to me.

Reviewed-By: Kajol Jain<kjain at linux.ibm.com>

Thanks,
Kajol jain

> 
> Differences to v1:
> - Add pmu_events_map__find() as arm64-specific function
> - Fix metric reuse for pmu-events parse metric testcase 
> 
> John Garry (6):
>   perf metricgroup: Make find_metric() public with name change
>   perf test: Handle metric reuse in pmu-events parsing test
>   perf pmu: Add pmu_events_map__find()
>   perf vendor events arm64: Add Hisi hip08 L1 metrics
>   perf vendor events arm64: Add Hisi hip08 L2 metrics
>   perf vendor events arm64: Add Hisi hip08 L3 metrics
> 
>  tools/perf/arch/arm64/util/Build              |   1 +
>  tools/perf/arch/arm64/util/pmu.c              |  25 ++
>  .../arch/arm64/hisilicon/hip08/metrics.json   | 233 ++++++++++++++++++
>  tools/perf/tests/pmu-events.c                 |  82 +++++-
>  tools/perf/util/metricgroup.c                 |  12 +-
>  tools/perf/util/metricgroup.h                 |   3 +-
>  tools/perf/util/pmu.c                         |   5 +
>  tools/perf/util/pmu.h                         |   1 +
>  tools/perf/util/s390-sample-raw.c             |   4 +-
>  9 files changed, 355 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/pmu.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
> 


From krzysztof.kozlowski at canonical.com  Wed Apr  7 07:58:27 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed,  7 Apr 2021 08:58:27 +0200
Subject: [GIT PULL 2/3] arm64: dts: exynos: Pull for v5.13
In-Reply-To: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
References: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210407065828.7213-2-krzysztof.kozlowski@canonical.com>

From: Krzysztof Kozlowski <krzk at kernel.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.13

for you to fetch changes up to 7d2636e9d6dd884ae2ec6127f29963d4da0dfe6e:

  arm64: dts: exynos: white-space cleanups (2021-03-19 11:34:55 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v5.13

Two cleanups in DTS without expected impact.

----------------------------------------------------------------
Krzysztof Kozlowski (2):
      arm64: dts: exynos: re-order Slim SSS clocks to match dtschema
      arm64: dts: exynos: white-space cleanups

 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 +-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi            | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)


From krzysztof.kozlowski at canonical.com  Wed Apr  7 07:58:28 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed,  7 Apr 2021 08:58:28 +0200
Subject: [GIT PULL 3/3] ARM: samsung: mach/soc pull for v5.13
In-Reply-To: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
References: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210407065828.7213-3-krzysztof.kozlowski@canonical.com>

From: Krzysztof Kozlowski <krzk at kernel.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.13

for you to fetch changes up to 6031008780efaada18087eba7ec84fe149f124a9:

  ARM: exynos: correct kernel doc in platsmp (2021-04-06 22:30:02 +0200)

----------------------------------------------------------------
Samsung mach/soc changes for v5.13

1. Update Krzysztof Kozlowski's email address in Maintainers.
2. Replace deprecated pwm_request() with pwm_get() in S3C24xx.
3. Correct kerneldoc.

----------------------------------------------------------------
Krzysztof Kozlowski (2):
      MAINTAINERS: use Krzysztof Kozlowski's Canonical address
      ARM: exynos: correct kernel doc in platsmp

Uwe Kleine-K?nig (1):
      ARM: s3c: Use pwm_get() in favour of pwm_request() in RX1950

 MAINTAINERS                     | 24 ++++++++++++------------
 arch/arm/mach-exynos/platsmp.c  | 28 +++++++++++++---------------
 arch/arm/mach-s3c/mach-rx1950.c | 11 ++++++-----
 3 files changed, 31 insertions(+), 32 deletions(-)


From krzysztof.kozlowski at canonical.com  Wed Apr  7 07:58:26 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed,  7 Apr 2021 08:58:26 +0200
Subject: [GIT PULL 1/3] ARM: dts: samsung: Pull for v5.13
Message-ID: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>

From: Krzysztof Kozlowski <krzk at kernel.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.13

for you to fetch changes up to 7f4ebf3e4ce10a1ed8ff2aee5d75568dc3522b2f:

  ARM: dts: exynos: Add front camera support to I9100 (2021-03-28 20:10:09 +0200)

----------------------------------------------------------------
Samsung DTS ARM changes for v5.13

1. Configure battery charger and front camera on GT-I9100 phone.
2. Fix in several boards the Maxim PMIC/MUIC/fuel gauge interrupt flags
   to match real type of interrupt coming from the device.
3. Correct DTS with dtschema.  This brings back the commit adding input
   clock to CMU in Exynos4412 Odroid which was reverted some time ago
   due to unsupported deferred probes (now supported and tested).

----------------------------------------------------------------
Krzysztof Kozlowski (13):
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on GT-I9100
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on P4 Note family
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on Midas family
      ARM: dts: exynos: correct MUIC interrupt trigger level on Midas family
      ARM: dts: exynos: correct PMIC interrupt trigger level on Midas family
      ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid X/U3 family
      ARM: dts: exynos: correct PMIC interrupt trigger level on P4 Note family
      ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250
      ARM: dts: exynos: correct PMIC interrupt trigger level on Snow
      ARM: dts: s5pv210: correct fuel gauge interrupt trigger level on Fascinate family
      ARM: dts: exynos: add input clock to CMU in Exynos4412 Odroid
      ARM: dts: exynos: replace deprecated NTC/Murata compatibles
      ARM: dts: exynos: white-space cleanups

Timon Baetz (2):
      ARM: dts: exynos: add charger supply for I9100
      ARM: dts: exynos: Add front camera support to I9100

 arch/arm/boot/dts/exynos3250-monk.dts           |  4 +-
 arch/arm/boot/dts/exynos3250-rinato.dts         |  4 +-
 arch/arm/boot/dts/exynos4210-i9100.dts          | 56 ++++++++++++++++++++++++-
 arch/arm/boot/dts/exynos4412-midas.dtsi         |  6 +--
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  5 ++-
 arch/arm/boot/dts/exynos4412-odroidx.dts        |  3 +-
 arch/arm/boot/dts/exynos4412-p4note.dtsi        |  4 +-
 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi   | 48 ++++++++++-----------
 arch/arm/boot/dts/exynos5250-smdk5250.dts       |  2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi   |  2 +-
 arch/arm/boot/dts/exynos5410-pinctrl.dtsi       | 28 ++++++-------
 arch/arm/boot/dts/s5pv210-fascinate4g.dts       |  2 +-
 12 files changed, 110 insertions(+), 54 deletions(-)


From krzysztof.kozlowski at canonical.com  Wed Apr  7 08:03:10 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 7 Apr 2021 09:03:10 +0200
Subject: [GIT PULL 1/3] ARM: dts: samsung: Pull for v5.13
In-Reply-To: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
References: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
Message-ID: <33fb7d93-a091-e1d4-e0e6-463c391b6e76@canonical.com>

On 07/04/2021 08:58, Krzysztof Kozlowski wrote:
> From: Krzysztof Kozlowski <krzk at kernel.org>

I still did not update all my tools for new email - this should be
"From" my Canonical address. The tags are signed with the same key with
@canonical.com UID.  The latest key is already in kernel PGP keyring:
https://korg.docs.kernel.org/pgpkeys.html

Best regards,
Krzysztof


From yibin.gong at nxp.com  Wed Apr  7 16:30:44 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:44 +0800
Subject: [PATCH v14 00/12] add ecspi ERR009165 for i.mx6/7 soc family
Message-ID: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>

There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
transfer to be send twice in DMA mode. Please get more information from:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding
new sdma ram script which works in XCH  mode as PIO inside sdma instead
of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be
exist on all legacy i.mx6/7 soc family before i.mx6ul.
NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/
6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips
still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata
or not.
The first two reverted patches should be the same issue, though, it
seems 'fixed' by changing to other shp script. Hope Sean or Sascha could
have the chance to test this patch set if could fix their issues.
Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
on i.mx8mm because the event id is zero.

PS:
   Please get sdma firmware from below linux-firmware and copy it to your
local rootfs /lib/firmware/imx/sdma.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma

v2:
  1.Add commit log for reverted patches.
  2.Add comment for 'ecspi_fixed' in sdma driver.
  3.Add 'fsl,imx6sll-ecspi' compatible instead of 'fsl,imx6ul-ecspi'
    rather than remove.
v3:
  1.Confirm with design team make sure ERR009165 fixed on i.mx6ul/i.mx6ull
    /i.mx6sll, not fixed on i.mx8m/8mm and other i.mx6/7 legacy chips.
    Correct dts related dts patch in v2.
  2.Clean eratta information in binding doc and new 'tx_glitch_fixed' flag
    in spi-imx driver to state ERR009165 fixed or not.
  3.Enlarge burst size to fifo size for tx since tx_wml set to 0 in the
    errata workaroud, thus improve performance as possible.
v4:
  1.Add Ack tag from Mark and Vinod
  2.Remove checking 'event_id1' zero as 'event_id0'.
v5:
  1.Add the last patch for compatible with the current uart driver which
    using rom script, so both uart ram script and rom script supported
    in latest firmware, by default uart rom script used. UART driver
    will be broken without this patch.
v6:
  1.Resend after rebase the latest next branch.
  2.Remove below No.13~No.15 patches of v5 because they were mergered.
  	ARM: dts: imx6ul: add dma support on ecspi
  	ARM: dts: imx6sll: correct sdma compatible
  	arm64: defconfig: Enable SDMA on i.mx8mq/8mm
  3.Revert "dmaengine: imx-sdma: fix context cache" since
    'context_loaded' removed.
v7:
  1.Put the last patch 13/13 'Revert "dmaengine: imx-sdma: fix context
    cache"' to the ahead of 03/13 'Revert "dmaengine: imx-sdma: refine
    to load context only once" so that no building waring during comes out
    during bisect.
  2.Address Sascha's comments, including eliminating any i.mx6sx in this
    series, adding new 'is_imx6ul_ecspi()' instead imx in imx51 and taking
    care SMC bit for PIO.
  3.Add back missing 'Reviewed-by' tag on 08/15(v5):09/13(v7)
   'spi: imx: add new i.mx6ul compatible name in binding doc'
v8:
  1.remove 0003-Revert-dmaengine-imx-sdma-fix-context-cache.patch and merge
    it into 04/13 of v7
  2.add 0005-spi-imx-fallback-to-PIO-if-dma-setup-failure.patch for no any
    ecspi function broken even if sdma firmware not updated.
  3.merge 'tx.dst_maxburst' changes in the two continous patches into one
    patch to avoid confusion.
  4.fix typo 'duplicated'.
v9:
  1. add "spi: imx: add dma_sync_sg_for_device after fallback from dma"
     to fix the potential issue brought by commit bcd8e7761ec9("spi: imx:
     fallback to PIO if dma setup failure") which is the only one patch
     of v8 merged. Thanks Matthias for reporting:
     https://lore.kernel.org/linux-arm-kernel/5d246dd81607bb6e5cb9af86ad4e53f7a7a99c50.camel at ew.tq-group.com/
  2. remove 05/13 of v8 "spi: imx:fallback to PIO if dma setup failure"
     since it's been merged.
v10:
  1. remove 01/13 "spi: imx: add dma_sync_sg_for_device after fallback from dma"
     since there is another independent patch merged:
     -- commit 809b1b04df898 ("spi: introduce fallback to pio")
  2. add "dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script" which
     is used to fix the potential dma_alloc_coherent() failure while this
     patchset applied but sdma firmware may not be ready for long time.
  3. burst size change back from fifo size to normal wml to align with nxp
     internal tree which has been test for years. Overnight with loopback
     test with spidev failed with fifo size, but pass with wml(half of fifo
     size).Seems the whole fifo size fed may cause rxfifo overflow during
     tx shift out while rx shift in.
     "spi: imx: remove ERR009165 workaround on i.mx6ul"
  4. remove 12/13 'dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm'
     since below two similar patches merged:
     -- commit 25962e1a7f1d ("dmaengine: imx-sdma: Fix the event id check to
     include RX event for UART6")
     -- commit 2f57b8d57673 ("dmaengine: imx-sdma: Fix: Remove 'always true'
     comparison")
v11:
  1. change dev_err() to dev_warn_once() in case sdma firmware not loaded to
     eliminate meaningless duplicate log print.
v12:
  1. take care uart_2_mcu_addr/uartsh_2_mcu_addr since such rom scripts are
     now located in the bottom part of sdma_script_start_addrs which are beyond
     the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1. Reported by Frieder as below:
     https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg2263544.html
v13:
  1. rebase with latest linux-next.
  2. remove 09/12 'spi: imx: add new i.mx6ul compatible name in binding doc'
     since it's been converted to yaml already.
  3. add 'Fixes', 'Cc: stable at vger.kernel.org' and 'Test-by' tags for 03,04
     since they are confirmed fix by Richard Leitner:
     https://lkml.org/lkml/2020/8/17/39
     https://www.spinics.net/lists/dmaengine/msg23489.html
  4. fix potential descriptor free unexpected on the next transfer before
     the last channel terminated:
     https://www.spinics.net/lists/dmaengine/msg23400.html
v14:
  1. rebase with latest linux-next.

Robin Gong (12):
  Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
  Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
  Revert "dmaengine: imx-sdma: refine to load context only once"
  dmaengine: imx-sdma: remove duplicated sdma_load_context
  dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script
  dmaengine: imx-sdma: add mcu_2_ecspi script
  spi: imx: fix ERR009165
  spi: imx: remove ERR009165 workaround on i.mx6ul
  dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
  dma: imx-sdma: add i.mx6ul compatible name
  dmaengine: imx-sdma: add uart rom script
  dmaengine: imx-sdma: add terminated list for freed descriptor in
    worker

 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |  1 +
 arch/arm/boot/dts/imx6q.dtsi                       |  2 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     |  8 +-
 drivers/dma/imx-sdma.c                             | 90 ++++++++++++++++------
 drivers/spi/spi-imx.c                              | 49 ++++++++++--
 include/linux/platform_data/dma-imx-sdma.h         |  8 +-
 6 files changed, 122 insertions(+), 36 deletions(-)

-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:45 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:45 +0800
Subject: [PATCH v14 01/12] Revert "ARM: dts: imx6q: Use correct SDMA script
 for SPI5 core"
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-2-git-send-email-yibin.gong@nxp.com>

  There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
  The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
       be sent twice
So revert commit 'df07101e1c4a' firstly.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx6q.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 8d209c1..9caba45 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -177,7 +177,7 @@
 					clocks = <&clks IMX6Q_CLK_ECSPI5>,
 						 <&clks IMX6Q_CLK_ECSPI5>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 11 8 1>, <&sdma 12 8 2>;
+					dmas = <&sdma 11 7 1>, <&sdma 12 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:46 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:46 +0800
Subject: [PATCH v14 02/12] Revert "ARM: dts: imx6: Use correct SDMA script for
 SPI cores"
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-3-git-send-email-yibin.gong@nxp.com>

There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
           be sent twice
So revert commit 'dd4b487b32a3' firstly.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 82e01ce..89c342f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -334,7 +334,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI1>,
 						 <&clks IMX6QDL_CLK_ECSPI1>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 3 8 1>, <&sdma 4 8 2>;
+					dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -348,7 +348,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI2>,
 						 <&clks IMX6QDL_CLK_ECSPI2>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 5 8 1>, <&sdma 6 8 2>;
+					dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -362,7 +362,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI3>,
 						 <&clks IMX6QDL_CLK_ECSPI3>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;
+					dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -376,7 +376,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI4>,
 						 <&clks IMX6QDL_CLK_ECSPI4>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 9 8 1>, <&sdma 10 8 2>;
+					dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:47 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:47 +0800
Subject: [PATCH v14 03/12] Revert "dmaengine: imx-sdma: refine to load context
 only once"
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-4-git-send-email-yibin.gong@nxp.com>

This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because
in spi-imx case, burst length may be changed dynamically.

Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
Cc: <stable at vger.kernel.org>
Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Sascha Hauer <s.hauer at pengutronix.de>
Tested-by: Richard Leitner <richard.leitner at skidata.com>
---
 drivers/dma/imx-sdma.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d5590c0..02f8584 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -379,7 +379,6 @@ struct sdma_channel {
 	unsigned long			watermark_level;
 	u32				shp_addr, per_addr;
 	enum dma_status			status;
-	bool				context_loaded;
 	struct imx_dma_data		data;
 	struct work_struct		terminate_worker;
 };
@@ -954,9 +953,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 	int ret;
 	unsigned long flags;
 
-	if (sdmac->context_loaded)
-		return 0;
-
 	if (sdmac->direction == DMA_DEV_TO_MEM)
 		load_address = sdmac->pc_from_device;
 	else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -999,8 +995,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
 	spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
 
-	sdmac->context_loaded = true;
-
 	return ret;
 }
 
@@ -1039,7 +1033,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 	vchan_get_all_descriptors(&sdmac->vc, &head);
 	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
 	vchan_dma_desc_free_list(&sdmac->vc, &head);
-	sdmac->context_loaded = false;
 }
 
 static int sdma_terminate_all(struct dma_chan *chan)
@@ -1307,7 +1300,6 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
 
 	sdmac->event_id0 = 0;
 	sdmac->event_id1 = 0;
-	sdmac->context_loaded = false;
 
 	sdma_set_channel_priority(sdmac, 0);
 
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:48 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:48 +0800
Subject: [PATCH v14 04/12] dmaengine: imx-sdma: remove duplicated
 sdma_load_context
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-5-git-send-email-yibin.gong@nxp.com>

Since sdma_transfer_init() will do sdma_load_context before any
sdma transfer, no need once more in sdma_config_channel().

Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
Cc: <stable at vger.kernel.org>
Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Vinod Koul <vkoul at kernel.org>
Tested-by: Richard Leitner <richard.leitner at skidata.com>
---
 drivers/dma/imx-sdma.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 02f8584..1c636d2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1107,7 +1107,6 @@ static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 static int sdma_config_channel(struct dma_chan *chan)
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
-	int ret;
 
 	sdma_disable_channel(chan);
 
@@ -1147,9 +1146,7 @@ static int sdma_config_channel(struct dma_chan *chan)
 		sdmac->watermark_level = 0; /* FIXME: M3_BASE_ADDRESS */
 	}
 
-	ret = sdma_load_context(sdmac);
-
-	return ret;
+	return 0;
 }
 
 static int sdma_set_channel_priority(struct sdma_channel *sdmac,
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:49 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:49 +0800
Subject: [PATCH v14 05/12] dmaengine: dma: imx-sdma: add fw_loaded and
 is_ram_script
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-6-git-send-email-yibin.gong@nxp.com>

Add 'fw_loaded' and 'is_ram_script' to check if the script used by channel
is ram script and it's loaded or not, so that could prevent meaningless
following malloc dma descriptor and bd allocate in sdma_transfer_init(),
otherwise memory may be consumed out potentially without free in case
that spi fallback into pio while dma transfer failed by sdma firmware not
ready(next ERR009165 patch depends on sdma RAM scripts/firmware).

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Vinod Koul <vkoul at kernel.org>
---
 drivers/dma/imx-sdma.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1c636d2..78dcfe2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -381,6 +381,7 @@ struct sdma_channel {
 	enum dma_status			status;
 	struct imx_dma_data		data;
 	struct work_struct		terminate_worker;
+	bool				is_ram_script;
 };
 
 #define IMX_DMA_SG_LOOP		BIT(0)
@@ -444,6 +445,7 @@ struct sdma_engine {
 	struct sdma_buffer_descriptor	*bd0;
 	/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/
 	bool				clk_ratio;
+	bool                            fw_loaded;
 };
 
 static int sdma_config_write(struct dma_chan *chan,
@@ -899,6 +901,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 	case IMX_DMATYPE_SSI_DUAL:
 		per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
 		emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+		sdmac->is_ram_script = true;
 		break;
 	case IMX_DMATYPE_SSI_SP:
 	case IMX_DMATYPE_MMC:
@@ -913,6 +916,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 		per_2_emi = sdma->script_addrs->asrc_2_mcu_addr;
 		emi_2_per = sdma->script_addrs->asrc_2_mcu_addr;
 		per_2_per = sdma->script_addrs->per_2_per_addr;
+		sdmac->is_ram_script = true;
 		break;
 	case IMX_DMATYPE_ASRC_SP:
 		per_2_emi = sdma->script_addrs->shp_2_mcu_addr;
@@ -1309,6 +1313,11 @@ static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
 {
 	struct sdma_desc *desc;
 
+	if (!sdmac->sdma->fw_loaded && sdmac->is_ram_script) {
+		dev_warn_once(sdmac->sdma->dev, "sdma firmware not ready!\n");
+		goto err_out;
+	}
+
 	desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
 	if (!desc)
 		goto err_out;
@@ -1559,6 +1568,8 @@ static int sdma_config_write(struct dma_chan *chan,
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
 
+	sdmac->is_ram_script = false;
+
 	if (direction == DMA_DEV_TO_MEM) {
 		sdmac->per_address = dmaengine_cfg->src_addr;
 		sdmac->watermark_level = dmaengine_cfg->src_maxburst *
@@ -1738,6 +1749,8 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
 
 	sdma_add_scripts(sdma, addr);
 
+	sdma->fw_loaded = true;
+
 	dev_info(sdma->dev, "loaded firmware %d.%d\n",
 			header->version_major,
 			header->version_minor);
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:50 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:50 +0800
Subject: [PATCH v14 06/12] dmaengine: imx-sdma: add mcu_2_ecspi script
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-7-git-send-email-yibin.gong@nxp.com>

Add mcu_2_ecspi script to fix ecspi errata ERR009165.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Vinod Koul <vkoul at kernel.org>
---
 drivers/dma/imx-sdma.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 78dcfe2..86bd383 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -892,6 +892,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 		emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
 		break;
 	case IMX_DMATYPE_CSPI:
+		per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+		emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+		sdmac->is_ram_script = true;
+		break;
 	case IMX_DMATYPE_EXT:
 	case IMX_DMATYPE_SSI:
 	case IMX_DMATYPE_SAI:
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:51 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:51 +0800
Subject: [PATCH v14 07/12] spi: imx: fix ERR009165
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-8-git-send-email-yibin.gong@nxp.com>

Change to XCH  mode even in dma mode, please refer to the below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Mark Brown <broonie at kernel.org>
---
 drivers/spi/spi-imx.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4fe767a..cf235b9 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -593,8 +593,8 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
 	spi_imx->spi_bus_clk = clk;
 
-	if (spi_imx->usedma)
-		ctrl |= MX51_ECSPI_CTRL_SMC;
+	/* ERR009165: work in XHC mode as PIO */
+	ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -625,7 +625,7 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
 	 * and enable DMA request.
 	 */
 	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
-		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_TX_WML(0) |
 		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1234,10 +1234,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 {
 	int ret;
 
-	/* use pio mode for i.mx6dl chip TKT238285 */
-	if (of_machine_is_compatible("fsl,imx6dl"))
-		return 0;
-
 	spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
 
 	/* Prepare for TX DMA: */
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:52 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:52 +0800
Subject: [PATCH v14 08/12] spi: imx: remove ERR009165 workaround on i.mx6ul
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-9-git-send-email-yibin.gong@nxp.com>

ERR009165 fixed on i.mx6ul/6ull/6sll. All other i.mx6/7 and
i.mx8m/8mm still need this errata. Please refer to nxp official
errata document from https://www.nxp.com/ .

For removing workaround on those chips. Add new i.mx6ul type.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Mark Brown <broonie at kernel.org>
---
 drivers/spi/spi-imx.c | 47 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index cf235b9..d18ee25 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -59,6 +59,7 @@ enum spi_imx_devtype {
 	IMX35_CSPI,	/* CSPI on all i.mx except above */
 	IMX51_ECSPI,	/* ECSPI on i.mx51 */
 	IMX53_ECSPI,	/* ECSPI on i.mx53 and later */
+	IMX6UL_ECSPI,	/* ERR009165 fix from i.mx6ul */
 };
 
 struct spi_imx_data;
@@ -78,6 +79,11 @@ struct spi_imx_devtype_data {
 	bool has_slavemode;
 	unsigned int fifo_size;
 	bool dynamic_burst;
+	/*
+	 * ERR009165 fixed or not:
+	 * https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+	 */
+	bool tx_glitch_fixed;
 	enum spi_imx_devtype devtype;
 };
 
@@ -134,6 +140,11 @@ static inline int is_imx51_ecspi(struct spi_imx_data *d)
 	return d->devtype_data->devtype == IMX51_ECSPI;
 }
 
+static inline int is_imx6ul_ecspi(struct spi_imx_data *d)
+{
+	return d->devtype_data->devtype == IMX6UL_ECSPI;
+}
+
 static inline int is_imx53_ecspi(struct spi_imx_data *d)
 {
 	return d->devtype_data->devtype == IMX53_ECSPI;
@@ -593,8 +604,14 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
 	spi_imx->spi_bus_clk = clk;
 
-	/* ERR009165: work in XHC mode as PIO */
-	ctrl &= ~MX51_ECSPI_CTRL_SMC;
+	/*
+	 * ERR009165: work in XHC mode instead of SMC as PIO on the chips
+	 * before i.mx6ul.
+	 */
+	if (spi_imx->usedma && spi_imx->devtype_data->tx_glitch_fixed)
+		ctrl |= MX51_ECSPI_CTRL_SMC;
+	else
+		ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -620,12 +637,16 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 
 static void mx51_setup_wml(struct spi_imx_data *spi_imx)
 {
+	u32 tx_wml = 0;
+
+	if (spi_imx->devtype_data->tx_glitch_fixed)
+		tx_wml = spi_imx->wml;
 	/*
 	 * Configure the DMA register: setup the watermark
 	 * and enable DMA request.
 	 */
 	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
-		MX51_ECSPI_DMA_TX_WML(0) |
+		MX51_ECSPI_DMA_TX_WML(tx_wml) |
 		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1019,6 +1040,23 @@ static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
 	.devtype = IMX53_ECSPI,
 };
 
+static struct spi_imx_devtype_data imx6ul_ecspi_devtype_data = {
+	.intctrl = mx51_ecspi_intctrl,
+	.prepare_message = mx51_ecspi_prepare_message,
+	.prepare_transfer = mx51_ecspi_prepare_transfer,
+	.trigger = mx51_ecspi_trigger,
+	.rx_available = mx51_ecspi_rx_available,
+	.reset = mx51_ecspi_reset,
+	.setup_wml = mx51_setup_wml,
+	.fifo_size = 64,
+	.has_dmamode = true,
+	.dynamic_burst = true,
+	.has_slavemode = true,
+	.tx_glitch_fixed = true,
+	.disable = mx51_ecspi_disable,
+	.devtype = IMX6UL_ECSPI,
+};
+
 static const struct of_device_id spi_imx_dt_ids[] = {
 	{ .compatible = "fsl,imx1-cspi", .data = &imx1_cspi_devtype_data, },
 	{ .compatible = "fsl,imx21-cspi", .data = &imx21_cspi_devtype_data, },
@@ -1027,6 +1065,7 @@ static const struct of_device_id spi_imx_dt_ids[] = {
 	{ .compatible = "fsl,imx35-cspi", .data = &imx35_cspi_devtype_data, },
 	{ .compatible = "fsl,imx51-ecspi", .data = &imx51_ecspi_devtype_data, },
 	{ .compatible = "fsl,imx53-ecspi", .data = &imx53_ecspi_devtype_data, },
+	{ .compatible = "fsl,imx6ul-ecspi", .data = &imx6ul_ecspi_devtype_data, },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, spi_imx_dt_ids);
@@ -1604,7 +1643,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	spi_imx->bitbang.master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH \
 					     | SPI_NO_CS;
 	if (is_imx35_cspi(spi_imx) || is_imx51_ecspi(spi_imx) ||
-	    is_imx53_ecspi(spi_imx))
+	    is_imx53_ecspi(spi_imx) || is_imx6ul_ecspi(spi_imx))
 		spi_imx->bitbang.master->mode_bits |= SPI_LOOP | SPI_READY;
 
 	spi_imx->spi_drctl = spi_drctl;
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:53 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:53 +0800
Subject: [PATCH v14 09/12] dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-10-git-send-email-yibin.gong@nxp.com>

ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Vinod Koul <vkoul at kernel.org>
---
 drivers/dma/imx-sdma.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 86bd383..af85116 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -422,6 +422,13 @@ struct sdma_driver_data {
 	int num_events;
 	struct sdma_script_start_addrs	*script_addrs;
 	bool check_ratio;
+	/*
+	 * ecspi ERR009165 fixed should be done in sdma script
+	 * and it has been fixed in soc from i.mx6ul.
+	 * please get more information from the below link:
+	 * https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
+	 */
+	bool ecspi_fixed;
 };
 
 struct sdma_engine {
@@ -542,6 +549,13 @@ static struct sdma_driver_data sdma_imx6q = {
 	.script_addrs = &sdma_script_imx6q,
 };
 
+static struct sdma_driver_data sdma_imx6ul = {
+	.chnenbl0 = SDMA_CHNENBL0_IMX35,
+	.num_events = 48,
+	.script_addrs = &sdma_script_imx6q,
+	.ecspi_fixed = true,
+};
+
 static struct sdma_script_start_addrs sdma_script_imx7d = {
 	.ap_2_ap_addr = 644,
 	.uart_2_mcu_addr = 819,
@@ -575,6 +589,7 @@ static const struct of_device_id sdma_dt_ids[] = {
 	{ .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
 	{ .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
 	{ .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
+	{ .compatible = "fsl,imx6ul-sdma", .data = &sdma_imx6ul, },
 	{ .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
 	{ /* sentinel */ }
 };
@@ -1144,8 +1159,17 @@ static int sdma_config_channel(struct dma_chan *chan)
 			if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
 			    sdmac->peripheral_type == IMX_DMATYPE_ASRC)
 				sdma_set_watermarklevel_for_p2p(sdmac);
-		} else
+		} else {
+			/*
+			 * ERR009165 fixed from i.mx6ul, no errata need,
+			 * set bit31 to let sdma script skip the errata.
+			 */
+			if (sdmac->peripheral_type == IMX_DMATYPE_CSPI &&
+			    sdmac->direction == DMA_MEM_TO_DEV &&
+			    sdmac->sdma->drvdata->ecspi_fixed)
+				__set_bit(31, &sdmac->watermark_level);
 			__set_bit(sdmac->event_id0, sdmac->event_mask);
+		}
 
 		/* Address */
 		sdmac->shp_addr = sdmac->per_address;
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:54 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:54 +0800
Subject: [PATCH v14 10/12] dma: imx-sdma: add i.mx6ul compatible name
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-11-git-send-email-yibin.gong@nxp.com>

Add i.mx6ul compatible name in binding doc.

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index c9e9740..12c316f 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -9,6 +9,7 @@ Required properties:
       "fsl,imx53-sdma"
       "fsl,imx6q-sdma"
       "fsl,imx7d-sdma"
+      "fsl,imx6ul-sdma"
       "fsl,imx8mq-sdma"
       "fsl,imx8mm-sdma"
       "fsl,imx8mn-sdma"
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:55 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:55 +0800
Subject: [PATCH v14 11/12] dmaengine: imx-sdma: add uart rom script
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-12-git-send-email-yibin.gong@nxp.com>

For the compatibility of NXP internal legacy kernel before 4.19 which
is based on uart ram script and upstreaming kernel based on uart rom
script, add both uart ram/rom script in latest sdma firmware. By default
uart rom script used.
Besides, add two multi-fifo scripts for SAI/PDM on i.mx8m/8mm and add
back qspi script miss for v4(i.mx7d/8m/8mm family, but v3 is for i.mx6).

rom script:
        uart_2_mcu_addr
	uartsh_2_mcu_addr /* through spba bus */
am script:
	uart_2_mcu_ram_addr
	uartsh_2_mcu_ram_addr /* through spba bus */

Please get latest sdma firmware from the below and put them into the path
(/lib/firmware/imx/sdma/):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
/tree/imx/sdma

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Acked-by: Vinod Koul <vkoul at kernel.org>
---
 drivers/dma/imx-sdma.c                     | 17 +++++++++++++++--
 include/linux/platform_data/dma-imx-sdma.h |  8 ++++++--
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index af85116..9519b41 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1696,8 +1696,8 @@ static void sdma_issue_pending(struct dma_chan *chan)
 
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1	34
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2	38
-#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3	41
-#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V4	42
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3	45
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V4	46
 
 static void sdma_add_scripts(struct sdma_engine *sdma,
 		const struct sdma_script_start_addrs *addr)
@@ -1721,6 +1721,19 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
 	for (i = 0; i < sdma->script_number; i++)
 		if (addr_arr[i] > 0)
 			saddr_arr[i] = addr_arr[i];
+
+	/*
+	 * get uart_2_mcu_addr/uartsh_2_mcu_addr rom script specially because
+	 * they are now replaced by uart_2_mcu_ram_addr/uartsh_2_mcu_ram_addr
+	 * to be compatible with legacy freescale/nxp sdma firmware, and they
+	 * are located in the bottom part of sdma_script_start_addrs which are
+	 * beyond the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1.
+	 */
+	if (addr->uart_2_mcu_addr)
+		sdma->script_addrs->uart_2_mcu_addr = addr->uart_2_mcu_addr;
+	if (addr->uartsh_2_mcu_addr)
+		sdma->script_addrs->uartsh_2_mcu_addr = addr->uartsh_2_mcu_addr;
+
 }
 
 static void sdma_load_firmware(const struct firmware *fw, void *context)
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 725602d..91dac29 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -20,12 +20,12 @@ struct sdma_script_start_addrs {
 	s32 per_2_firi_addr;
 	s32 mcu_2_firi_addr;
 	s32 uart_2_per_addr;
-	s32 uart_2_mcu_addr;
+	s32 uart_2_mcu_ram_addr;
 	s32 per_2_app_addr;
 	s32 mcu_2_app_addr;
 	s32 per_2_per_addr;
 	s32 uartsh_2_per_addr;
-	s32 uartsh_2_mcu_addr;
+	s32 uartsh_2_mcu_ram_addr;
 	s32 per_2_shp_addr;
 	s32 mcu_2_shp_addr;
 	s32 ata_2_mcu_addr;
@@ -52,6 +52,10 @@ struct sdma_script_start_addrs {
 	s32 zcanfd_2_mcu_addr;
 	s32 zqspi_2_mcu_addr;
 	s32 mcu_2_ecspi_addr;
+	s32 mcu_2_sai_addr;
+	s32 sai_2_mcu_addr;
+	s32 uart_2_mcu_addr;
+	s32 uartsh_2_mcu_addr;
 	/* End of v3 array */
 	s32 mcu_2_zqspi_addr;
 	/* End of v4 array */
-- 
2.7.4



From yibin.gong at nxp.com  Wed Apr  7 16:30:56 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed,  7 Apr 2021 23:30:56 +0800
Subject: [PATCH v14 12/12] dmaengine: imx-sdma: add terminated list for freed
 descriptor in worker
In-Reply-To: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
Message-ID: <1617809456-17693-13-git-send-email-yibin.gong@nxp.com>

Add terminated list for keeping descriptor so that it could be freed in
worker without any potential involving next descriptor raised up before
this descriptor freed, because vchan_get_all_descriptors get all
descriptors including the last terminated descriptor and the next
descriptor, hence, the next descriptor maybe freed unexpectly when it's
done in worker without this patch.
https://www.spinics.net/lists/dmaengine/msg23367.html

Signed-off-by: Robin Gong <yibin.gong at nxp.com>
Reported-by: Richard Leitner <richard.leitner at skidata.com>
---
 drivers/dma/imx-sdma.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 9519b41..4174580 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -381,6 +381,7 @@ struct sdma_channel {
 	enum dma_status			status;
 	struct imx_dma_data		data;
 	struct work_struct		terminate_worker;
+	struct list_head                terminated;
 	bool				is_ram_script;
 };
 
@@ -1041,9 +1042,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 {
 	struct sdma_channel *sdmac = container_of(work, struct sdma_channel,
 						  terminate_worker);
-	unsigned long flags;
-	LIST_HEAD(head);
-
 	/*
 	 * According to NXP R&D team a delay of one BD SDMA cost time
 	 * (maximum is 1ms) should be added after disable of the channel
@@ -1052,10 +1050,7 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 	 */
 	usleep_range(1000, 2000);
 
-	spin_lock_irqsave(&sdmac->vc.lock, flags);
-	vchan_get_all_descriptors(&sdmac->vc, &head);
-	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
-	vchan_dma_desc_free_list(&sdmac->vc, &head);
+	vchan_dma_desc_free_list(&sdmac->vc, &sdmac->terminated);
 }
 
 static int sdma_terminate_all(struct dma_chan *chan)
@@ -1069,6 +1064,13 @@ static int sdma_terminate_all(struct dma_chan *chan)
 
 	if (sdmac->desc) {
 		vchan_terminate_vdesc(&sdmac->desc->vd);
+		/*
+		 * move out current descriptor into terminated list so that
+		 * it could be free in sdma_channel_terminate_work alone
+		 * later without potential involving next descriptor raised
+		 * up before the last descriptor terminated.
+		 */
+		vchan_get_all_descriptors(&sdmac->vc, &sdmac->terminated);
 		sdmac->desc = NULL;
 		schedule_work(&sdmac->terminate_worker);
 	}
@@ -2075,6 +2077,7 @@ static int sdma_probe(struct platform_device *pdev)
 
 		sdmac->channel = i;
 		sdmac->vc.desc_free = sdma_desc_free;
+		INIT_LIST_HEAD(&sdmac->terminated);
 		INIT_WORK(&sdmac->terminate_worker,
 				sdma_channel_terminate_work);
 		/*
-- 
2.7.4



From quan at os.amperecomputing.com  Wed Apr  7 08:23:32 2021
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Wed, 7 Apr 2021 14:23:32 +0700
Subject: [PATCH v2 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver
In-Reply-To: <20210402120137.GA26002@pengutronix.de>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-3-quan@os.amperecomputing.com>
 <20210402120137.GA26002@pengutronix.de>
Message-ID: <82887823-b6b7-3d53-0fe3-571cbb2552c8@os.amperecomputing.com>

On 02/04/2021 19:01, Philipp Zabel wrote:
> Hi Quan,
> 
> On Tue, Mar 30, 2021 at 09:10:28PM +0700, Quan Nguyen wrote:
>> The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
>> in-band IPMI communication with their host in management (BMC) side.
>>
>> This commits adds support specifically for Aspeed AST2500 which commonly
>> used as Board Management Controllers.
>>
>> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
>> ---
> [...]
>> diff --git a/drivers/char/ipmi/ssif_bmc_aspeed.c b/drivers/char/ipmi/ssif_bmc_aspeed.c
>> new file mode 100644
>> index 000000000000..a563fcff5acc
>> --- /dev/null
>> +++ b/drivers/char/ipmi/ssif_bmc_aspeed.c
>> @@ -0,0 +1,132 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * The driver for BMC side of Aspeed SSIF interface
>> + *
>> + * Copyright (c) 2021, Ampere Computing LLC
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/i2c.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/module.h>
>> +#include <linux/poll.h>
>> +#include <linux/iopoll.h>
>> +
>> +#include "ssif_bmc.h"
>> +
>> +struct aspeed_i2c_bus {
>> +	struct i2c_adapter              adap;
>> +	struct device                   *dev;
> 
> This device handle is apparently unused.
> 
>> +	void __iomem                    *base;
>> +	struct reset_control            *rst;
> 
> This reset control handle is unused as well.
> 

Thank for the comment, Philipp.

The main purpose here is to get the aspeed_i2c_bus->base of aspeed_i2c 
driver so that the ASPEED_I2CD_INTR_RX_DONE and 
ASPEED_I2CD_INTR_SLAVE_MATCH can be masked while handling the incoming 
request, otherwise, the process is disturbed because these interrupts 
keep occurring with unwanted value.

Other solution we have in mind is to implement and expose the 
EXPORT_SYMBOL_GPL(i2c_aspeed_configure_slave) from 
drivers/i2c/busses/i2c-aspeed.c

Really appreciate if you could comment more on the solution.

Thanks,
- Quan


From maxime at cerno.tech  Wed Apr  7 08:23:57 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Wed, 7 Apr 2021 09:23:57 +0200
Subject: [PATCH v3 3/4] dt-bindings: arm: add compatible strings for
 Forlinx OKA40i-C
In-Reply-To: <20210401175420.39b75553@NervousEnergy>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-4-i.uvarov@cognitivepilot.com>
 <20210401094001.sh3nvkj5psbdcig5@gilmour>
 <20210401175420.39b75553@NervousEnergy>
Message-ID: <20210407072357.2bq36io23iuhlvbe@gilmour>

Hi,

On Thu, Apr 01, 2021 at 05:55:37PM +0300, Ivan Uvarov wrote:
> On Thu, 1 Apr 2021 11:40:01 +0200
> Maxime Ripard <maxime at cerno.tech> wrote:
> 
> > On Wed, Mar 31, 2021 at 06:56:15PM +0300, Ivan Uvarov wrote:
> > > The OKA40i-C is a carrier/development board for the Forlinx
> > > FETA40i-C SoM based on the Allwinner R40/A40i SoC.
> > > 
> > > This patch adds the relevant dt-binding documentation in
> > > preparation for the next patch, which adds a devicetree for the SoM
> > > and board.
> > > 
> > > Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> > > 
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
> > > b/Documentation/devicetree/bindings/arm/sunxi.yaml index
> > > 08607c7ec1..74f8decd78 100644 ---
> > > a/Documentation/devicetree/bindings/arm/sunxi.yaml +++
> > > b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -224,6
> > > +224,12 @@ properties:
> > >            - const: empire-electronix,m712
> > >            - const: allwinner,sun5i-a13
> > >  
> > > +      - description: Forlinx OKA40i-C Development board
> > > +        items:
> > > +          - const: forlinx,oka40i-c
> > > +          - const: forlinx,feta40i-c
> > > +          - const: allwinner,sun8i-r40
> > > +
> > >        - description: FriendlyARM NanoPi A64
> > >          items:
> > >            - const: friendlyarm,nanopi-a64
> > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > b/Documentation/devicetree/bindings/vendor-prefixes.yaml index
> > > f6064d84a4..e2ea1a731e 100644 ---
> > > a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++
> > > b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -403,6
> > > +403,8 @@ patternProperties: description: Firefly
> > >    "^focaltech,.*":
> > >      description: FocalTech Systems Co.,Ltd
> > > +  "^forlinx,.*":
> > > +    description: Baoding Forlinx Embedded Technology Co., Ltd.
> > >    "^frida,.*":
> > >      description: Shenzhen Frida LCD Co., Ltd.
> > >    "^friendlyarm,.*":
> > > -- 
> > > 2.25.1  
> > 
> > This part needs to be in a separate patch too
> > 
> > Maxime
> > 
> 
> As in, a separate patch for just the vendor prefix?

Exactly :)

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/20210407/83bdf48f/attachment.sig>

From maxime at cerno.tech  Wed Apr  7 08:30:54 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Wed, 7 Apr 2021 09:30:54 +0200
Subject: [PATCH v3 4/4] ARM: dts: sun8i: r40: add devicetree for Forlinx
 FETA40i-C & OKA40i-C
In-Reply-To: <20210401175938.1f6d065c@NervousEnergy>
References: <20210331155616.793550-1-i.uvarov@cognitivepilot.com>
 <20210331155616.793550-5-i.uvarov@cognitivepilot.com>
 <20210401094356.zhijxfoihw73ha7k@gilmour>
 <20210401175938.1f6d065c@NervousEnergy>
Message-ID: <20210407073054.wzus3zmzfksilwcf@gilmour>

On Thu, Apr 01, 2021 at 05:59:38PM +0300, Ivan Uvarov wrote:
> > > +	leds {
> > > +		compatible = "gpio-leds";
> > > +
> > > +		led-5 {
> > > +			gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /*
> > > PH26 */
> > > +			color = <LED_COLOR_ID_GREEN>;
> > > +			function = LED_FUNCTION_STATUS;
> > > +		};
> > > +
> > > +		led-6 {
> > > +			gpios = <&pio 8 15 GPIO_ACTIVE_LOW>; /*
> > > PI15 */
> > > +			color = <LED_COLOR_ID_BLUE>;
> > > +			function = LED_FUNCTION_STATUS;
> > > +		};  
> > 
> > led-5 and led-6? You can start at 0 :)
> > 
> > Looks good otherwise, thanks
> 
> This is how they are labeled on the board, so I kept the names. Should
> I rename them anyway?

No, it makes sense then, just add a comment to make it 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/20210407/67196893/attachment.sig>

From hverkuil at xs4all.nl  Wed Apr  7 08:30:51 2021
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 7 Apr 2021 09:30:51 +0200
Subject: [PATCH v2 00/30] media: atmel: atmel-isc: add support for xisc
In-Reply-To: <20210405155105.162529-1-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
Message-ID: <d12caa29-2ed9-e99a-43ac-a2eb3413f1c6@xs4all.nl>

Hi Eugen,

On 05/04/2021 17:50, Eugen Hristev wrote:
> Hello,
> 
> This series adds support for a variant of the ISC named XISC.
> This block is present in the product named sama7g5.
> 
> I started by moving code around, the code which was specialized for sama5d2
> type of ISC, to have it inside the dedicated sama5d2 file.
> 
> I added several new pipeline elements to the code base, which would be common
> to sama5d2 and the new sama7g5, but only used by the new style pipeline.
> 
> I separated the input and output formats on a per-product separate array.
> 
> I added the new sama7g5 compatible driver for the xisc, which is similar with
> the sama5d2, but with differences in terms of DT, clocks and callbacks to
> specific operations.
> 
> I added the binding for the xisc by copying and modifying the existing
> isc one. I know that it has to be converted to yaml, and I will do that if
> it looks good.

This series looks good to me.

One thing that can be improved in a v3 is a short explanation of the various
abbreviations: CBV, RLP, HIS, DPC, etc.

Regards,

	Hans

> 
> Feedback is appreciated.
> Thanks,
> Eugen
> 
> Changes in v2:
> - Fixed krobot warnings with W=1 regarding functions with no prototype
> - Fixed new sama7g5 driver to use the new subdev fwnode API in kernel 5.12. my driver was
> based on old 5.10 style API.
> 
> Eugen Hristev (30):
>   media: atmel: atmel-isc: specialize gamma table into product specific
>   media: atmel: atmel-isc: specialize driver name constant
>   media: atmel: atmel-isc: add checks for limiting frame sizes
>   media: atmel: atmel-isc: specialize max width and max height
>   media: atmel: atmel-isc: specialize dma cfg
>   media: atmel: atmel-isc: extract CSC submodule config into separate
>     function
>   media: atmel: atmel-isc-base: add id to clock debug message
>   media: atmel: atmel-isc: create register offsets struct
>   media: atmel: atmel-isc: extract CBC submodule config into separate
>     function
>   media: atmel: atmel-isc: add CBC to the reg offsets struct
>   media: atmel: atmel-isc: add SUB422 and SUB420 to register offsets
>   media: atmel: atmel-isc: add RLP to register offsets
>   media: atmel: atmel-isc: add HIS to register offsets
>   media: atmel: atmel-isc: add DMA to register offsets
>   media: atmel: atmel-isc: add support for version register
>   media: atmel: atmel-isc: add his_entry to register offsets
>   media: atmel: atmel-isc: add register description for additional
>     modules
>   media: atmel: atmel-isc: extend pipeline with extra modules
>   media: atmel: atmel-isc: add CC initialization function
>   media: atmel: atmel-isc: create product specific v4l2 controls config
>   media: atmel: atmel-isc: create callback for DPC submodule product
>     specific
>   media: atmel: atmel-isc: create callback for GAM submodule product
>     specific
>   media: atmel: atmel-isc: create callback for RLP submodule product
>     specific
>   media: atmel: atmel-isc: move the formats list into product specific
>     code
>   media: atmel: atmel-isc: create an adapt pipeline callback for product
>     specific
>   media: atmel: atmel-isc-regs: add additional fields for sama7g5 type
>     pipeline
>   media: atmel: atmel-isc-base: add support for more formats and
>     additional pipeline modules
>   dt-bindings: media: atmel: add microchip-xisc binding
>   media: atmel: atmel-isc-sama5d2: remove duplicate define
>   media: atmel: atmel-isc: add microchip-xisc driver
> 
>  .../bindings/media/microchip-xisc.txt         |  64 ++
>  drivers/media/platform/Makefile               |   1 +
>  drivers/media/platform/atmel/Kconfig          |  11 +
>  drivers/media/platform/atmel/Makefile         |   2 +
>  drivers/media/platform/atmel/atmel-isc-base.c | 381 ++++-------
>  drivers/media/platform/atmel/atmel-isc-regs.h | 133 +++-
>  drivers/media/platform/atmel/atmel-isc.h      | 122 +++-
>  .../media/platform/atmel/atmel-sama5d2-isc.c  | 311 ++++++++-
>  .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
>  9 files changed, 1391 insertions(+), 277 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
>  create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c
> 



From hsinyi at chromium.org  Wed Apr  7 08:30:57 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 7 Apr 2021 15:30:57 +0800
Subject: [PATCH v16 2/2] i2c: core: support bus regulator controlling in
 adapter
In-Reply-To: <CAJMQK-jZnQ1pt435Dz=xAbuU=wJcMJkSFSnTtuARTW_rGwRCFg@mail.gmail.com>
References: <20210308043607.957156-1-hsinyi@chromium.org>
 <20210308043607.957156-3-hsinyi@chromium.org>
 <20210308171644.GE4656@sirena.org.uk>
 <CAJMQK-jZnQ1pt435Dz=xAbuU=wJcMJkSFSnTtuARTW_rGwRCFg@mail.gmail.com>
Message-ID: <CAJMQK-jqrBdfROr_XZakQb4v+jB31hvLejcSBZjPo=TYqKar1w@mail.gmail.com>

On Tue, Mar 9, 2021 at 9:34 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> On Tue, Mar 9, 2021 at 1:17 AM Mark Brown <broonie at kernel.org> wrote:
> >
> > On Mon, Mar 08, 2021 at 12:36:07PM +0800, Hsin-Yi Wang wrote:
> >
> > > +     adap->bus_regulator = devm_regulator_get(&adap->dev, "bus");
> > > +     if (IS_ERR(adap->bus_regulator)) {
> > > +             res = PTR_ERR(adap->bus_regulator);
> > > +             goto out_reg;
> > > +     }
> >
> > Idiomatically supplies should be named as they are by the chip datasheet
> > rather than just a generic name like this, and I'm guessing that systems
> > that have supplies like this will often already have something
> > requesting the supply (eg, it's quite common for consumer drivers to do
> > this) under that name.  I can see this being a useful thing to factor
> > out into the core but it seems like it'd be better to have it enabled by
> > having the controllers (or devices) pass a supply name (or possibly
> > requested regulator) to the core rather than by just hard coding a name
> > in the core so bindings look as expected.
> >
>
> I'll move the regulator request into device instead of core in the
> next version. Thanks.
>
Hi Mark,

v17 is sent here:
https://patchwork.kernel.org/project/linux-mediatek/cover/20210309133131.1585838-1-hsinyi at chromium.org/

Thanks.

> > I do also wonder if it's better to put the feature on the clients rather
> > than the controller, I don't think it makes much difference though.


From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:21 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:21 +0200
Subject: [PATCH v9 00/13] Add HANTRO G2/HEVC decoder support for IMX8MQ
Message-ID: <20210407073534.376722-1-benjamin.gaignard@collabora.com>

The IMX8MQ got two VPUs but until now only G1 has been enabled.
This series aim to add the second VPU (aka G2) and provide basic 
HEVC decoding support.

To be able to decode HEVC it is needed to add/update some of the
structures in the uapi. In addition of them one HANTRO dedicated
control is required to inform the driver of the numbre of bits to skip
at the beginning of the slice header.
The hardware require to allocate few auxiliary buffers to store the
references frame or tile size data.

The driver has been tested with fluster test suite stream.
For example with this command: ./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0

Finally the both VPUs will have a node the device-tree and be
independent from v4l2 point of view.

A branch with all the dev is available here:
https://gitlab.collabora.com/benjamin.gaignard/for-upstream/-/commits/upstream_g2_v9

version 9:
 - Corrections in commits messages.
 - Define the dedicated control in hevc-controls.h
 - Add note in documentation.
 - Change max value of the dedicated control.
 - Rebased on media_tree/master branch.

version 8:
 - Add reviewed-by and ack-by tags 
 - Fix the warnings reported by kernel test robot
 - Only patch 9 (adding dedicated control), patch 11 (HEVC support) and
   patch 13 (DT changes) are still missing of review/ack tag.

version 7:
 - Remove 'q' from syscon phandle name to make usable for iMX8MM too.
   Update the bindings documentation.
 - Add review/ack tags.
 - Rebase on top of media_tree/master
 - Be more accurate when computing the size of the memory needed motion
   vectors.
 - Explain why the all clocks need to set in the both DT node.

version 6:
 - fix the errors reported by kernel test robot

version 5:
 - use syscon instead of VPU reset driver.
 - Do not break kernel/DT backward compatibility.
 - Add documentation for dedicated Hantro control.
 - Fix the remarks done by Ezequeil (typo, comments, unused function)
 - Run v4l2-compliance without errors (see below).
 - Do not add field to distinguish version, check postproc reg instead

version 4:
- Split the changes in hevc controls in 2 commits to make them easier to
  review.
- Change hantro_codec_ops run() prototype to return errors   
- Hantro v4l2 dedicated control is now only an integer
- rebase on top of VPU reset changes posted here:
  https://www.spinics.net/lists/arm-kernel/msg878440.html
- Various fix from previous remarks
- Limit the modifications in API to what the driver needs

version 3:
- Fix typo in Hantro v4l2 dedicated control
- Add documentation for the new structures and fields
- Rebased on top of media_tree for-linus-5.12-rc1 tag

version 2:
- remove all change related to scaling
- squash commits to a coherent split
- be more verbose about the added fields
- fix the comments done by Ezequiel about dma_alloc_coherent usage
- fix Dan's comments about control copy, reverse the test logic
in tile_buffer_reallocate, rework some goto and return cases.
- be more verbose about why I change the bindings
- remove all sign-off expect mime since it is confusing
- remove useless clocks in VPUs nodes

./v4l2-compliance -m 1 
v4l2-compliance 1.21.0-4705, 64 bits, 64-bit time_t
v4l2-compliance SHA: 733f7a54f79d 2021-02-03 08:25:49

Compliance test for hantro-vpu device /dev/media1:

Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0

Required ioctls:
	test MEDIA_IOC_DEVICE_INFO: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/media1 open: OK
	test MEDIA_IOC_DEVICE_INFO: OK
	test for unlimited opens: OK

Media Controller ioctls:
	test MEDIA_IOC_G_TOPOLOGY: OK
	Entities: 3 Interfaces: 1 Pads: 4 Links: 4
	test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
	test MEDIA_IOC_SETUP_LINK: OK

Total for hantro-vpu device /dev/media1: 8, Succeeded: 8, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for hantro-vpu device /dev/video1:

Driver Info:
	Driver name      : hantro-vpu
	Card type        : nxp,imx8mq-vpu-g2-dec
	Bus info         : platform: hantro-vpu
	Driver version   : 5.11.0
	Capabilities     : 0x84204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04204000
		Video Memory-to-Memory Multiplanar
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : hantro-vpu
	Model            : hantro-vpu
	Serial           : 
	Bus info         : platform: hantro-vpu
	Media version    : 5.11.0
	Hardware revision: 0x00000000 (0)
	Driver version   : 5.11.0
Interface Info:
	ID               : 0x0300000c
	Type             : V4L Video
Entity Info:
	ID               : 0x00000001 (1)
	Name             : nxp,imx8mq-vpu-g2-dec-source
	Function         : V4L2 I/O
	Pad 0x01000002   : 0: Source
	  Link 0x02000008: to remote pad 0x1000004 of entity 'nxp,imx8mq-vpu-g2-dec-proc': Data, Enabled, Immutable

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video1 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 8 Private Controls: 1

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK (Not Supported)
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
	test VIDIOC_EXPBUF: OK
	test Requests: OK

Total for hantro-vpu device /dev/video1: 46, Succeeded: 46, Failed: 0, Warnings: 0

Grand Total for hantro-vpu device /dev/media1: 54, Succeeded: 54, Failed: 0, Warnings: 0

Benjamin
 
Benjamin Gaignard (13):
  dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to syscon list
  dt-bindings: media: nxp,imx8mq-vpu: Update the bindings for G2 support
  media: hantro: Use syscon instead of 'ctrl' register
  media: hevc: Add fields and flags for hevc PPS
  media: hevc: Add decode params control
  media: hantro: change hantro_codec_ops run prototype to return errors
  media: hantro: Define HEVC codec profiles and supported features
  media: hantro: Only use postproc when post processed formats are
    defined
  media: uapi: Add a control for HANTRO driver
  media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
  media: hantro: Introduce G2/HEVC decoder
  media: hantro: IMX8M: add variant for G2/HEVC codec
  arm64: dts: imx8mq: Add node to G2 hardware

 .../bindings/media/nxp,imx8mq-vpu.yaml        |  53 +-
 .../devicetree/bindings/mfd/syscon.yaml       |   1 +
 .../userspace-api/media/drivers/hantro.rst    |  19 +
 .../userspace-api/media/drivers/index.rst     |   1 +
 .../media/v4l/ext-ctrls-codec.rst             | 108 +++-
 .../media/v4l/vidioc-queryctrl.rst            |   6 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  43 +-
 drivers/media/v4l2-core/v4l2-ctrls.c          |  28 +-
 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |  18 +-
 drivers/staging/media/hantro/hantro_drv.c     |  99 ++-
 .../staging/media/hantro/hantro_g1_h264_dec.c |  10 +-
 .../media/hantro/hantro_g1_mpeg2_dec.c        |   4 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |   6 +-
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |   4 +-
 drivers/staging/media/hantro/hantro_hevc.c    | 327 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  69 +-
 .../staging/media/hantro/hantro_postproc.c    |  14 +
 drivers/staging/media/hantro/hantro_v4l2.c    |   5 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c   | 128 +++-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |   4 +-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |   4 +-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |   6 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   6 +
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  |  12 +-
 include/media/hevc-ctrls.h                    |  46 +-
 30 files changed, 1690 insertions(+), 121 deletions(-)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:22 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:22 +0200
Subject: [PATCH v9 01/13] dt-bindings: mfd: Add 'nxp,
 imx8mq-vpu-ctrl' to syscon list
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-2-benjamin.gaignard@collabora.com>

Add 'nxp,imx8mq-vpu-ctrl' to the list of possible syscon.
It will used to access the VPU control registers.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
version 9:
 - corrections in commit message

version 8:
 - Add Lee ack

version 7:
 - Add Rob ack

 Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index f14ae6da0068..ae22c4730613 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -44,6 +44,7 @@ properties:
               - hisilicon,peri-subctrl
               - microchip,sparx5-cpu-syscon
               - mstar,msc313-pmsleep
+              - nxp,imx8mq-vpu-ctrl
               - rockchip,px30-qos
               - rockchip,rk3066-qos
               - rockchip,rk3288-qos
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:23 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:23 +0200
Subject: [PATCH v9 02/13] dt-bindings: media: nxp,
 imx8mq-vpu: Update the bindings for G2 support
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-3-benjamin.gaignard@collabora.com>

Introducing the G2 hevc video decoder requires modifications of the bindings to allow
one node per VPU.

VPUs share one hardware control block which is provided as a phandle on
a syscon.
Each node has now one reg and one interrupt.
Add a compatible for G2 hardware block: nxp,imx8mq-vpu-g2.

To be compatible with older DT the driver is still capable to use the 'ctrl'
reg-name even if it is deprecated now.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
version 9:
 - Corrections in commit message

version 7:
 - Add Rob and Philipp reviewed-by tag
 - Change syscon phandle name to nxp,imx8m-vpu-ctrl (remove 'q' to be
   usable for iMX8MM too)

version 5:
- This version doesn't break the backward compatibilty between kernel
  and DT.

 .../bindings/media/nxp,imx8mq-vpu.yaml        | 53 ++++++++++++-------
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
index 762be3f96ce9..18e7d40a5f24 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
@@ -15,22 +15,18 @@ description:
 
 properties:
   compatible:
-    const: nxp,imx8mq-vpu
+    oneOf:
+      - const: nxp,imx8mq-vpu
+      - const: nxp,imx8mq-vpu-g2
 
   reg:
-    maxItems: 3
-
-  reg-names:
-    items:
-      - const: g1
-      - const: g2
-      - const: ctrl
+    maxItems: 1
 
   interrupts:
-    maxItems: 2
+    maxItems: 1
 
   interrupt-names:
-    items:
+    oneOf:
       - const: g1
       - const: g2
 
@@ -46,14 +42,18 @@ properties:
   power-domains:
     maxItems: 1
 
+  nxp,imx8m-vpu-ctrl:
+    description: Specifies a phandle to syscon VPU hardware control block
+    $ref: "/schemas/types.yaml#/definitions/phandle"
+
 required:
   - compatible
   - reg
-  - reg-names
   - interrupts
   - interrupt-names
   - clocks
   - clock-names
+  - nxp,imx8m-vpu-ctrl
 
 additionalProperties: false
 
@@ -62,18 +62,33 @@ examples:
         #include <dt-bindings/clock/imx8mq-clock.h>
         #include <dt-bindings/interrupt-controller/arm-gic.h>
 
-        vpu: video-codec at 38300000 {
+        vpu_ctrl: syscon at 38320000 {
+                 compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
+                 reg = <0x38320000 0x10000>;
+        };
+
+        vpu_g1: video-codec at 38300000 {
                 compatible = "nxp,imx8mq-vpu";
-                reg = <0x38300000 0x10000>,
-                      <0x38310000 0x10000>,
-                      <0x38320000 0x10000>;
-                reg-names = "g1", "g2", "ctrl";
-                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
-                             <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
-                interrupt-names = "g1", "g2";
+                reg = <0x38300000 0x10000>;
+                interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "g1";
+                clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
+                         <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
+                         <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
+                clock-names = "g1", "g2", "bus";
+                power-domains = <&pgc_vpu>;
+                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
+        };
+
+        vpu_g2: video-codec at 38310000 {
+                compatible = "nxp,imx8mq-vpu-g2";
+                reg = <0x38300000 0x10000>;
+                interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "g2";
                 clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
                          <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
                          <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
                 clock-names = "g1", "g2", "bus";
                 power-domains = <&pgc_vpu>;
+                nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
         };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:25 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:25 +0200
Subject: [PATCH v9 04/13] media: hevc: Add fields and flags for hevc PPS
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-5-benjamin.gaignard@collabora.com>

Add fields and flags as they are defined in
7.4.3.3.1 "General picture parameter set RBSP semantics of the
H.265 ITU specification.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

 .../userspace-api/media/v4l/ext-ctrls-codec.rst    | 14 ++++++++++++++
 include/media/hevc-ctrls.h                         |  4 ++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index b0de4e6e7ebd..aabcb0e63a5e 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3000,6 +3000,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``num_extra_slice_header_bits``
       -
+    * - __u8
+      - ``num_ref_idx_l0_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l0_active_minus1
+    * - __u8
+      - ``num_ref_idx_l1_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l1_active_minus1
     * - __s8
       - ``init_qp_minus26``
       -
@@ -3110,6 +3116,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT``
       - 0x00040000
       -
+    * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
+      - 0x00080000
+      - Specifies the presence of deblocking filter control syntax elements in
+        the PPS
+    * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING``
+      - 0x00100000
+      - Specifies that tile column boundaries and likewise tile row boundaries
+        are distributed uniformly across the picture
 
 .. raw:: latex
 
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index b4cb2ef02f17..003f819ecb26 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -100,10 +100,14 @@ struct v4l2_ctrl_hevc_sps {
 #define V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER	(1ULL << 16)
 #define V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT		(1ULL << 17)
 #define V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT (1ULL << 18)
+#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT	(1ULL << 19)
+#define V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING			(1ULL << 20)
 
 struct v4l2_ctrl_hevc_pps {
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture parameter set */
 	__u8	num_extra_slice_header_bits;
+	__u8	num_ref_idx_l0_default_active_minus1;
+	__u8	num_ref_idx_l1_default_active_minus1;
 	__s8	init_qp_minus26;
 	__u8	diff_cu_qp_delta_depth;
 	__s8	pps_cb_qp_offset;
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:24 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:24 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl' register
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-4-benjamin.gaignard@collabora.com>

In order to be able to share the control hardware block between
VPUs use a syscon instead a ioremap it in the driver.
To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
phandle is not found look at 'ctrl' reg-name.
With the method it becomes useless to provide a list of register
names so remove it.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
version 9:
 - Corrections in commit message

version 7:
 - Add Philipp reviewed-by tag.
 - Change syscon phandle name.
 
version 5:
 - use syscon instead of VPU reset driver.
 - if DT doesn't provide syscon keep backward compatibilty by using
   'ctrl' reg-name.

 drivers/staging/media/hantro/hantro.h       |  5 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
 2 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 6c1b888abe75..37b9ce04bd4e 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -13,6 +13,7 @@
 #define HANTRO_H_
 
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 #include <linux/videodev2.h>
 #include <linux/wait.h>
 #include <linux/clk.h>
@@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
  * @reg_bases:		Mapped addresses of VPU registers.
  * @enc_base:		Mapped address of VPU encoder register for convenience.
  * @dec_base:		Mapped address of VPU decoder register for convenience.
- * @ctrl_base:		Mapped address of VPU control block.
+ * @ctrl_base:		Regmap of VPU control block.
  * @vpu_mutex:		Mutex to synchronize V4L2 calls.
  * @irqlock:		Spinlock to synchronize access to data structures
  *			shared with interrupt handlers.
@@ -186,7 +187,7 @@ struct hantro_dev {
 	void __iomem **reg_bases;
 	void __iomem *enc_base;
 	void __iomem *dec_base;
-	void __iomem *ctrl_base;
+	struct regmap *ctrl_base;
 
 	struct mutex vpu_mutex;	/* video_device lock */
 	spinlock_t irqlock;
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index c222de075ef4..8d0c3425234b 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -7,6 +7,7 @@
 
 #include <linux/clk.h>
 #include <linux/delay.h>
+#include <linux/mfd/syscon.h>
 
 #include "hantro.h"
 #include "hantro_jpeg.h"
@@ -24,30 +25,28 @@
 #define CTRL_G1_PP_FUSE		0x0c
 #define CTRL_G2_DEC_FUSE	0x10
 
+static const struct regmap_config ctrl_regmap_ctrl = {
+	.reg_bits = 32,
+	.val_bits = 32,
+	.reg_stride = 0x14,
+};
+
 static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
 {
-	u32 val;
-
 	/* Assert */
-	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
-	val &= ~reset_bits;
-	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
+	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
 
 	udelay(2);
 
 	/* Release */
-	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
-	val |= reset_bits;
-	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
+	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
+			   reset_bits, reset_bits);
 }
 
 static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
 {
-	u32 val;
-
-	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
-	val |= clock_bits;
-	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
+	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
+			   clock_bits, clock_bits);
 }
 
 static int imx8mq_runtime_resume(struct hantro_dev *vpu)
@@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
 	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
 
 	/* Set values of the fuse registers */
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
-	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
+	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
+	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
+	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
 
 	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
 
@@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
-	vpu->dec_base = vpu->reg_bases[0];
-	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
+	struct device_node *np = vpu->dev->of_node;
+
+	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
+	if (IS_ERR(vpu->ctrl_base)) {
+		struct resource *res;
+		void __iomem *ctrl;
+
+		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
+		ctrl = devm_ioremap_resource(vpu->dev, res);
+		if (IS_ERR(ctrl))
+			return PTR_ERR(ctrl);
+
+		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
+		if (IS_ERR(vpu->ctrl_base))
+			return PTR_ERR(vpu->ctrl_base);
+	}
 
 	return 0;
 }
@@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
 };
 
 static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
-static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
 
 const struct hantro_variant imx8mq_vpu_variant = {
 	.dec_fmts = imx8m_vpu_dec_fmts,
@@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
 	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
 	.clk_names = imx8mq_clk_names,
 	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
-	.reg_names = imx8mq_reg_names,
-	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
 };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:26 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:26 +0200
Subject: [PATCH v9 05/13] media: hevc: Add decode params control
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-6-benjamin.gaignard@collabora.com>

Add decode params control and the associated structure to group
all the information that are needed to decode a reference frame as
is described in ITU-T Rec. H.265 section "8.3.2 Decoding process
for reference picture set".

Adapt Cedrus driver to these changes.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message

version 8:
 - add Ezequiel review tag

version 7:
 - rebased on top of media_tree/master branch

version 6:
 - fix compilation errors

 .../media/v4l/ext-ctrls-codec.rst             | 94 +++++++++++++++----
 .../media/v4l/vidioc-queryctrl.rst            |  6 ++
 drivers/media/v4l2-core/v4l2-ctrls.c          | 28 ++++--
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  6 ++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 12 ++-
 include/media/hevc-ctrls.h                    | 29 ++++--
 8 files changed, 138 insertions(+), 40 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index aabcb0e63a5e..7b90cb939e9d 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3214,9 +3214,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``pic_struct``
       -
-    * - __u8
-      - ``num_active_dpb_entries``
-      - The number of entries in ``dpb``.
     * - __u8
       - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L0 reference elements as indices in the DPB.
@@ -3224,22 +3221,8 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
       - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L1 reference elements as indices in the DPB.
     * - __u8
-      - ``num_rps_poc_st_curr_before``
-      - The number of reference pictures in the short-term set that come before
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_st_curr_after``
-      - The number of reference pictures in the short-term set that come after
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_lt_curr``
-      - The number of reference pictures in the long-term set.
-    * - __u8
-      - ``padding[7]``
+      - ``padding``
       - Applications and drivers must set this to zero.
-    * - struct :c:type:`v4l2_hevc_dpb_entry`
-      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
-      - The decoded picture buffer, for meta-data about reference frames.
     * - struct :c:type:`v4l2_hevc_pred_weight_table`
       - ``pred_weight_table``
       - The prediction weight coefficients for inter-picture prediction.
@@ -3492,3 +3475,78 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     encoding the next frame queued after setting this control.
     This provides a bitmask which consists of bits [0, LTR_COUNT-1].
     This is applicable to the H264 and HEVC encoders.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)``
+    Specifies various decode parameters, especially the references picture order
+    count (POC) for all the lists (short, long, before, current, after) and the
+    number of entries for each of them.
+    These parameters are defined according to :ref:`hevc`.
+    They are described in section 8.3 "Slice decoding process" of the
+    specification.
+
+.. c:type:: v4l2_ctrl_hevc_decode_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_hevc_decode_params
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - __s32
+      - ``pic_order_cnt_val``
+      - PicOrderCntVal as described in section 8.3.1 "Decoding process
+        for picture order count" of the specification.
+    * - __u8
+      - ``num_active_dpb_entries``
+      - The number of entries in ``dpb``.
+    * - struct :c:type:`v4l2_hevc_dpb_entry`
+      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - The decoded picture buffer, for meta-data about reference frames.
+    * - __u8
+      - ``num_poc_st_curr_before``
+      - The number of reference pictures in the short-term set that come before
+        the current frame.
+    * - __u8
+      - ``num_poc_st_curr_after``
+      - The number of reference pictures in the short-term set that come after
+        the current frame.
+    * - __u8
+      - ``num_poc_lt_curr``
+      - The number of reference pictures in the long-term set.
+    * - __u8
+      - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocLtCurr as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u64
+      - ``flags``
+      - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>`
+
+.. _hevc_decode_params_flags:
+
+``Decode Parameters Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC``
+      - 0x00000001
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC``
+      - 0x00000002
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR``
+      - 0x00000004
+      -
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index 8a285daedc6a..cf8f94693c39 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -495,6 +495,12 @@ See also the examples in :ref:`control`.
       - n/a
       - A struct :c:type:`v4l2_ctrl_vp8_frame`, containing VP8
 	frame parameters for stateless video decoders.
+    * - ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``
+      - n/a
+      - n/a
+      - n/a
+      - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC
+	decoding parameters for stateless video decoders.
 
 .. raw:: latex
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index c7bcc5c25771..9c918766e2c8 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_HEVC_SPS:			return "HEVC Sequence Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_PPS:			return "HEVC Picture Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:		return "HEVC Slice Parameters";
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:		return "HEVC Decode Parameters";
 	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:		return "HEVC Decode Mode";
 	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:		return "HEVC Start Code";
 
@@ -1526,6 +1527,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
 		*type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
 		break;
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
+		*type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
+		break;
 	case V4L2_CID_UNIT_CELL_SIZE:
 		*type = V4L2_CTRL_TYPE_AREA;
 		*flags |= V4L2_CTRL_FLAG_READ_ONLY;
@@ -1895,6 +1899,7 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 	struct v4l2_ctrl_hevc_pps *p_hevc_pps;
 	struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
 	struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;
+	struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;
 	struct v4l2_area *area;
 	void *p = ptr.p + idx * ctrl->elem_size;
 	unsigned int i;
@@ -2170,24 +2175,21 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 		zero_padding(*p_hevc_pps);
 		break;
 
-	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
-		p_hevc_slice_params = p;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		p_hevc_decode_params = p;
 
-		if (p_hevc_slice_params->num_active_dpb_entries >
+		if (p_hevc_decode_params->num_active_dpb_entries >
 		    V4L2_HEVC_DPB_ENTRIES_NUM_MAX)
 			return -EINVAL;
 
-		zero_padding(p_hevc_slice_params->pred_weight_table);
-
-		for (i = 0; i < p_hevc_slice_params->num_active_dpb_entries;
+		for (i = 0; i < p_hevc_decode_params->num_active_dpb_entries;
 		     i++) {
 			struct v4l2_hevc_dpb_entry *dpb_entry =
-				&p_hevc_slice_params->dpb[i];
+				&p_hevc_decode_params->dpb[i];
 
 			zero_padding(*dpb_entry);
 		}
 
-		zero_padding(*p_hevc_slice_params);
 		break;
 
 	case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
@@ -2237,6 +2239,13 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 
 		break;
 
+	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
+		p_hevc_slice_params = p;
+
+		zero_padding(p_hevc_slice_params->pred_weight_table);
+		zero_padding(*p_hevc_slice_params);
+		break;
+
 	case V4L2_CTRL_TYPE_AREA:
 		area = p;
 		if (!area->width || !area->height)
@@ -2938,6 +2947,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
 	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
 		elem_size = sizeof(struct v4l2_ctrl_hevc_slice_params);
 		break;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		elem_size = sizeof(struct v4l2_ctrl_hevc_decode_params);
+		break;
 	case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
 		elem_size = sizeof(struct v4l2_ctrl_hdr10_cll_info);
 		break;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 92812d1a39d4..6f095ae53818 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -151,6 +151,12 @@ static const struct cedrus_control cedrus_controls[] = {
 		},
 		.codec		= CEDRUS_CODEC_VP8,
 	},
+	{
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
+		.codec		= CEDRUS_CODEC_H265,
+	},
 };
 
 #define CEDRUS_CONTROLS_COUNT	ARRAY_SIZE(cedrus_controls)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 15f147dad4cb..930922bd4e46 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -76,6 +76,7 @@ struct cedrus_h265_run {
 	const struct v4l2_ctrl_hevc_sps			*sps;
 	const struct v4l2_ctrl_hevc_pps			*pps;
 	const struct v4l2_ctrl_hevc_slice_params	*slice_params;
+	const struct v4l2_ctrl_hevc_decode_params	*decode_params;
 };
 
 struct cedrus_vp8_run {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index d696b3ec70c0..8a7e44f92812 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -68,6 +68,8 @@ void cedrus_device_run(void *priv)
 			V4L2_CID_MPEG_VIDEO_HEVC_PPS);
 		run.h265.slice_params = cedrus_find_control_data(ctx,
 			V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
+		run.h265.decode_params = cedrus_find_control_data(ctx,
+			V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
 		break;
 
 	case V4L2_PIX_FMT_VP8_FRAME:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
index ce497d0197df..397a4ba5df4c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
@@ -245,6 +245,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	const struct v4l2_ctrl_hevc_sps *sps;
 	const struct v4l2_ctrl_hevc_pps *pps;
 	const struct v4l2_ctrl_hevc_slice_params *slice_params;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
 	const struct v4l2_hevc_pred_weight_table *pred_weight_table;
 	dma_addr_t src_buf_addr;
 	dma_addr_t src_buf_end_addr;
@@ -256,6 +257,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	sps = run->h265.sps;
 	pps = run->h265.pps;
 	slice_params = run->h265.slice_params;
+	decode_params = run->h265.decode_params;
 	pred_weight_table = &slice_params->pred_weight_table;
 
 	/* MV column buffer size and allocation. */
@@ -487,7 +489,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	reg = VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_TC_OFFSET_DIV2(slice_params->slice_tc_offset_div2) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_BETA_OFFSET_DIV2(slice_params->slice_beta_offset_div2) |
-	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(slice_params->num_rps_poc_st_curr_after == 0) |
+	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(decode_params->num_poc_st_curr_after == 0) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CR_QP_OFFSET(slice_params->slice_cr_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CB_QP_OFFSET(slice_params->slice_cb_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_QP_DELTA(slice_params->slice_qp_delta);
@@ -527,8 +529,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	cedrus_write(dev, VE_DEC_H265_NEIGHBOR_INFO_ADDR, reg);
 
 	/* Write decoded picture buffer in pic list. */
-	cedrus_h265_frame_info_write_dpb(ctx, slice_params->dpb,
-					 slice_params->num_active_dpb_entries);
+	cedrus_h265_frame_info_write_dpb(ctx, decode_params->dpb,
+					 decode_params->num_active_dpb_entries);
 
 	/* Output frame. */
 
@@ -545,7 +547,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 0 (for P/B frames). */
 	if (slice_params->slice_type != V4L2_HEVC_SLICE_TYPE_I) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l0,
 					       slice_params->num_ref_idx_l0_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST0);
@@ -564,7 +566,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 1 (for B frames). */
 	if (slice_params->slice_type == V4L2_HEVC_SLICE_TYPE_B) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l1,
 					       slice_params->num_ref_idx_l1_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST1);
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 003f819ecb26..8e0109eea454 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -19,6 +19,7 @@
 #define V4L2_CID_MPEG_VIDEO_HEVC_SPS		(V4L2_CID_CODEC_BASE + 1008)
 #define V4L2_CID_MPEG_VIDEO_HEVC_PPS		(V4L2_CID_CODEC_BASE + 1009)
 #define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS	(V4L2_CID_CODEC_BASE + 1010)
+#define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_BASE + 1012)
 #define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE	(V4L2_CID_CODEC_BASE + 1015)
 #define V4L2_CID_MPEG_VIDEO_HEVC_START_CODE	(V4L2_CID_CODEC_BASE + 1016)
 
@@ -26,6 +27,7 @@
 #define V4L2_CTRL_TYPE_HEVC_SPS 0x0120
 #define V4L2_CTRL_TYPE_HEVC_PPS 0x0121
 #define V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS 0x0122
+#define V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS 0x0124
 
 enum v4l2_mpeg_video_hevc_decode_mode {
 	V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
@@ -194,18 +196,10 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u8	pic_struct;
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	__u8	num_active_dpb_entries;
 	__u8	ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 	__u8	ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 
-	__u8	num_rps_poc_st_curr_before;
-	__u8	num_rps_poc_st_curr_after;
-	__u8	num_rps_poc_lt_curr;
-
-	__u8	padding;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	padding[5];
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
 	struct v4l2_hevc_pred_weight_table pred_weight_table;
@@ -213,4 +207,21 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u64	flags;
 };
 
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC		0x1
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC		0x2
+#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR  0x4
+
+struct v4l2_ctrl_hevc_decode_params {
+	__s32	pic_order_cnt_val;
+	__u8	num_active_dpb_entries;
+	struct	v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	num_poc_st_curr_before;
+	__u8	num_poc_st_curr_after;
+	__u8	num_poc_lt_curr;
+	__u8	poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u64	flags;
+};
+
 #endif
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:28 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:28 +0200
Subject: [PATCH v9 07/13] media: hantro: Define HEVC codec profiles and
 supported features
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-8-benjamin.gaignard@collabora.com>

Define which HEVC profiles (up to level 5.1) and features
(no scaling, no 10 bits) are supported by the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 8:
 - add Ezequiel review tag

 drivers/staging/media/hantro/hantro.h     |  3 ++
 drivers/staging/media/hantro/hantro_drv.c | 58 +++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 37b9ce04bd4e..edb4561a6887 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -35,6 +35,7 @@ struct hantro_codec_ops;
 #define HANTRO_MPEG2_DECODER	BIT(16)
 #define HANTRO_VP8_DECODER	BIT(17)
 #define HANTRO_H264_DECODER	BIT(18)
+#define HANTRO_HEVC_DECODER	BIT(19)
 #define HANTRO_DECODERS		0xffff0000
 
 /**
@@ -100,6 +101,7 @@ struct hantro_variant {
  * @HANTRO_MODE_H264_DEC: H264 decoder.
  * @HANTRO_MODE_MPEG2_DEC: MPEG-2 decoder.
  * @HANTRO_MODE_VP8_DEC: VP8 decoder.
+ * @HANTRO_MODE_HEVC_DEC: HEVC decoder.
  */
 enum hantro_codec_mode {
 	HANTRO_MODE_NONE = -1,
@@ -107,6 +109,7 @@ enum hantro_codec_mode {
 	HANTRO_MODE_H264_DEC,
 	HANTRO_MODE_MPEG2_DEC,
 	HANTRO_MODE_VP8_DEC,
+	HANTRO_MODE_HEVC_DEC,
 };
 
 /*
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 02c5c2f1a88b..d9a3a5ef9330 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -245,6 +245,18 @@ static int hantro_try_ctrl(struct v4l2_ctrl *ctrl)
 		if (sps->bit_depth_luma_minus8 != 0)
 			/* Only 8-bit is supported */
 			return -EINVAL;
+	} else if (ctrl->id == V4L2_CID_MPEG_VIDEO_HEVC_SPS) {
+		const struct v4l2_ctrl_hevc_sps *sps = ctrl->p_new.p_hevc_sps;
+
+		if (sps->bit_depth_luma_minus8 != sps->bit_depth_chroma_minus8)
+			/* Luma and chroma bit depth mismatch */
+			return -EINVAL;
+		if (sps->bit_depth_luma_minus8 != 0)
+			/* Only 8-bit is supported */
+			return -EINVAL;
+		if (sps->flags & V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED)
+			/* No scaling support */
+			return -EINVAL;
 	}
 	return 0;
 }
@@ -351,6 +363,52 @@ static const struct hantro_ctrl controls[] = {
 			.def = V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
 		}
 	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.max = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.def = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_START_CODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.max = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.def = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
+			.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+			.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
+			.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
+			.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
+			.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+			.ops = &hantro_ctrl_ops,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
 	},
 };
 
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:27 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:27 +0200
Subject: [PATCH v9 06/13] media: hantro: change hantro_codec_ops run prototype
 to return errors
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-7-benjamin.gaignard@collabora.com>

Change hantro_codec_ops run prototype from 'void' to 'int'.
This allows the driver to cancel the job if an error occurs while configuring
the hardware.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message

version 8:
 - add Ezequiel review tag

version 5:
 - forward hantro_h264_dec_prepare_run() return value in case
   of error

 drivers/staging/media/hantro/hantro_drv.c     |  4 +++-
 .../staging/media/hantro/hantro_g1_h264_dec.c | 10 +++++++---
 .../media/hantro/hantro_g1_mpeg2_dec.c        |  4 +++-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |  6 ++++--
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |  4 +++-
 drivers/staging/media/hantro/hantro_hw.h      | 19 ++++++++++---------
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |  4 +++-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |  4 +++-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |  6 ++++--
 9 files changed, 40 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 595e82a82728..02c5c2f1a88b 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -161,7 +161,9 @@ static void device_run(void *priv)
 
 	v4l2_m2m_buf_copy_metadata(src, dst, true);
 
-	ctx->codec_ops->run(ctx);
+	if (ctx->codec_ops->run(ctx))
+		goto err_cancel_job;
+
 	return;
 
 err_cancel_job:
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 845bef73d218..5c792b7bcb79 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -273,13 +273,15 @@ static void set_buffers(struct hantro_ctx *ctx)
 	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, G1_REG_ADDR_QTABLE);
 }
 
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
+	int ret;
 
 	/* Prepare the H264 decoder context. */
-	if (hantro_h264_dec_prepare_run(ctx))
-		return;
+	ret = hantro_h264_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
 
 	/* Configure hardware registers. */
 	set_params(ctx);
@@ -301,4 +303,6 @@ void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 			   G1_REG_CONFIG_DEC_CLK_GATE_E,
 			   G1_REG_CONFIG);
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
index 6386a3989bfe..5e8943d31dc5 100644
--- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
@@ -155,7 +155,7 @@ hantro_g1_mpeg2_dec_set_buffers(struct hantro_dev *vpu, struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, backward_addr, G1_REG_REFER3_BASE);
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -248,4 +248,6 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = G1_REG_DEC_E(1);
 	vdpu_write(vpu, reg, G1_SWREG(1));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 57002ba70176..96622a7f8279 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -425,7 +425,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, G1_REG_ADDR_DST);
 }
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -438,7 +438,7 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -498,4 +498,6 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index b88dc4ed06db..56cf261a8e95 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -88,7 +88,7 @@ hantro_h1_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -136,6 +136,8 @@ void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vepu_write(vpu, reg, H1_REG_ENC_CTRL);
+
+	return 0;
 }
 
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx)
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 83b3e42b63a3..6a34ddfa34b7 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -133,14 +133,15 @@ struct hantro_postproc_ctx {
  *		Optional and called from process context.
  * @run:	Start single {en,de)coding job. Called from atomic context
  *		to indicate that a pair of buffers is ready and the hardware
- *		should be programmed and started.
+ *		should be programmed and started. Returns zero if OK, a
+ *		negative value in error cases.
  * @done:	Read back processing results and additional data from hardware.
  * @reset:	Reset the hardware in case of a timeout.
  */
 struct hantro_codec_ops {
 	int (*init)(struct hantro_ctx *ctx);
 	void (*exit)(struct hantro_ctx *ctx);
-	void (*run)(struct hantro_ctx *ctx);
+	int (*run)(struct hantro_ctx *ctx);
 	void (*done)(struct hantro_ctx *ctx);
 	void (*reset)(struct hantro_ctx *ctx);
 };
@@ -176,8 +177,8 @@ void hantro_irq_done(struct hantro_dev *vpu,
 void hantro_start_prepare_run(struct hantro_ctx *ctx);
 void hantro_end_prepare_run(struct hantro_ctx *ctx);
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
 int hantro_jpeg_enc_init(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_exit(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
@@ -185,7 +186,7 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
 dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 				   unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
@@ -216,15 +217,15 @@ hantro_h264_mv_size(unsigned int width, unsigned int height)
 	return 64 * MB_WIDTH(width) * MB_WIDTH(height) + 32;
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_copy_qtable(u8 *qtable,
 	const struct v4l2_ctrl_mpeg2_quantization *ctrl);
 int hantro_mpeg2_dec_init(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_exit(struct hantro_ctx *ctx);
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
 int hantro_vp8_dec_init(struct hantro_ctx *ctx);
 void hantro_vp8_dec_exit(struct hantro_ctx *ctx);
 void hantro_vp8_prob_update(struct hantro_ctx *ctx,
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
index 3498e6124acd..3a27ebef4f38 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
@@ -118,7 +118,7 @@ rk3399_vpu_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -168,4 +168,6 @@ void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 	/* Kick the watchdog and start encoding */
 	hantro_end_prepare_run(ctx);
 	vepu_write(vpu, reg, VEPU_REG_ENCODE_START);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
index f610fa5b4335..4bd3080abbc1 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
@@ -157,7 +157,7 @@ rk3399_vpu_mpeg2_dec_set_buffers(struct hantro_dev *vpu,
 	vdpu_write_relaxed(vpu, backward_addr, VDPU_REG_REFER3_BASE);
 }
 
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -254,4 +254,6 @@ void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = vdpu_read(vpu, VDPU_SWREG(57)) | VDPU_REG_DEC_E(1);
 	vdpu_write(vpu, reg, VDPU_SWREG(57));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
index 8661a3cc1e6b..e5d20fe5b007 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
@@ -503,7 +503,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, VDPU_REG_ADDR_DST);
 }
 
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -516,7 +516,7 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -589,4 +589,6 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	hantro_reg_write(vpu, &vp8_dec_start_dec, 1);
+
+	return 0;
 }
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:30 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:30 +0200
Subject: [PATCH v9 09/13] media: uapi: Add a control for HANTRO driver
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-10-benjamin.gaignard@collabora.com>

The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific requirement so create a dedicated control
for this purpose.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 9:
 - Corrections in commit message.
 - Move control definition in hevc-ctrls.h
 - Add note in documentation to explain that this control
   may change in the futur

version 5:
 - Be even more verbose in control documentation.
 - Do not create class for the control.
version 4:
- The control is now an integer which is enough to provide the numbers
  of bits to skip.
version 3:
- Fix typo in field name

 .../userspace-api/media/drivers/hantro.rst    | 19 +++++++++++++++++++
 .../userspace-api/media/drivers/index.rst     |  1 +
 include/media/hevc-ctrls.h                    | 13 +++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst

diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst
new file mode 100644
index 000000000000..cd9754b4e005
--- /dev/null
+++ b/Documentation/userspace-api/media/drivers/hantro.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Hantro video decoder driver
+===========================
+
+The Hantro video decoder driver implements the following driver-specific controls:
+
+``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
+    Specifies to Hantro HEVC video decoder driver the number of data (in bits) to
+    skip in the slice segment header.
+    If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+    to before syntax element "slice_temporal_mvp_enabled_flag".
+    If IDR, the skipped bits are just "pic_output_flag"
+    (separate_colour_plane_flag is not supported).
+
+.. note::
+
+        This control is not yet part of the public kernel API and
+        it is expected to change.
diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
index 1a9038f5f9fa..12e3c512d718 100644
--- a/Documentation/userspace-api/media/drivers/index.rst
+++ b/Documentation/userspace-api/media/drivers/index.rst
@@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux.
 
 	ccs
 	cx2341x-uapi
+        hantro
 	imx-uapi
 	max2175
 	meye-uapi
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 8e0109eea454..b713eeed1915 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -224,4 +224,17 @@ struct v4l2_ctrl_hevc_decode_params {
 	__u64	flags;
 };
 
+/*  MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */
+#define V4L2_CID_CODEC_HANTRO_BASE				(V4L2_CTRL_CLASS_CODEC | 0x1200)
+/*
+ * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
+ * the number of data (in bits) to skip in the
+ * slice segment header.
+ * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+ * to before syntax element "slice_temporal_mvp_enabled_flag".
+ * If IDR, the skipped bits are just "pic_output_flag"
+ * (separate_colour_plane_flag is not supported).
+ */
+#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP	(V4L2_CID_CODEC_HANTRO_BASE + 0)
+
 #endif
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:29 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:29 +0200
Subject: [PATCH v9 08/13] media: hantro: Only use postproc when post processed
 formats are defined
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-9-benjamin.gaignard@collabora.com>

If the variant doesn't support postprocessed formats make sure it will
be ok.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message

version 8:
 - add Ezequiel review tag

 drivers/staging/media/hantro/hantro.h          |  8 ++------
 drivers/staging/media/hantro/hantro_postproc.c | 14 ++++++++++++++
 drivers/staging/media/hantro/hantro_v4l2.c     |  4 +++-
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index edb4561a6887..7a5ad93466c8 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -414,12 +414,8 @@ hantro_get_dst_buf(struct hantro_ctx *ctx)
 	return v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 }
 
-static inline bool
-hantro_needs_postproc(const struct hantro_ctx *ctx,
-		      const struct hantro_fmt *fmt)
-{
-	return !ctx->is_encoder && fmt->fourcc != V4L2_PIX_FMT_NV12;
-}
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt);
 
 static inline dma_addr_t
 hantro_get_dec_buf_addr(struct hantro_ctx *ctx, struct vb2_buffer *vb)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 6d2a8f2a8f0b..ed8916c950a4 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -50,6 +50,20 @@ const struct hantro_postproc_regs hantro_g1_postproc_regs = {
 	.display_width = {G1_REG_PP_DISPLAY_WIDTH, 0, 0xfff},
 };
 
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder)
+		return false;
+
+	if (!vpu->variant->postproc_fmts)
+		return false;
+
+	return fmt->fourcc != V4L2_PIX_FMT_NV12;
+}
+
 void hantro_postproc_enable(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1bc118e375a1..77d7fe62ce81 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -55,7 +55,9 @@ static const struct hantro_fmt *
 hantro_get_postproc_formats(const struct hantro_ctx *ctx,
 			    unsigned int *num_fmts)
 {
-	if (ctx->is_encoder) {
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder || !vpu->variant->postproc_fmts) {
 		*num_fmts = 0;
 		return NULL;
 	}
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:31 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:31 +0200
Subject: [PATCH v9 10/13] media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-11-benjamin.gaignard@collabora.com>

Make sure that V4L2_PIX_FMT_HEVC_SLICE is correctly handled by the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message

version 8:
 - Add Ezequiel review tag

 drivers/staging/media/hantro/hantro_v4l2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 77d7fe62ce81..0655324fd0d4 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -392,6 +392,7 @@ hantro_update_requires_request(struct hantro_ctx *ctx, u32 fourcc)
 	case V4L2_PIX_FMT_MPEG2_SLICE:
 	case V4L2_PIX_FMT_VP8_FRAME:
 	case V4L2_PIX_FMT_H264_SLICE:
+	case V4L2_PIX_FMT_HEVC_SLICE:
 		ctx->fh.m2m_ctx->out_q_ctx.q.requires_requests = true;
 		break;
 	default:
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:33 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:33 +0200
Subject: [PATCH v9 12/13] media: hantro: IMX8M: add variant for G2/HEVC codec
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-13-benjamin.gaignard@collabora.com>

Add variant to IMX8M to enable G2/HEVC codec.
Define the capabilities for the hardware up to 3840x2160.
G2 doesn't have a postprocessor, uses the same clocks and has it
own interrupt.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message

version 8:
 - Add Ezequiel Reviewed-by tag.

version 7:
 - Add Philipp Reviewed-by tag.

version 5:
 - remove useless postproc fields for G2

version 2:
- remove useless clocks

 drivers/staging/media/hantro/hantro_drv.c   |  1 +
 drivers/staging/media/hantro/hantro_hw.h    |  1 +
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 76 ++++++++++++++++++++-
 3 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 905a69758b37..d6f4958f6292 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -574,6 +574,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_IMX8M
 	{ .compatible = "nxp,imx8mq-vpu", .data = &imx8mq_vpu_variant, },
+	{ .compatible = "nxp,imx8mq-vpu-g2", .data = &imx8mq_vpu_g2_variant },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 41f3d5b92357..682fea1fe914 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -205,6 +205,7 @@ extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant imx8mq_vpu_g2_variant;
 
 extern const struct hantro_postproc_regs hantro_g1_postproc_regs;
 
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index 8d0c3425234b..6de43e0edc36 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -12,6 +12,7 @@
 #include "hantro.h"
 #include "hantro_jpeg.h"
 #include "hantro_g1_regs.h"
+#include "hantro_g2_regs.h"
 
 #define CTRL_SOFT_RESET		0x00
 #define RESET_G1		BIT(1)
@@ -129,6 +130,26 @@ static const struct hantro_fmt imx8m_vpu_dec_fmts[] = {
 	},
 };
 
+static const struct hantro_fmt imx8m_vpu_g2_dec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
+		.codec_mode = HANTRO_MODE_HEVC_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = 48,
+			.max_width = 3840,
+			.step_width = MB_DIM,
+			.min_height = 48,
+			.max_height = 2160,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
 static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 {
 	struct hantro_dev *vpu = dev_id;
@@ -147,6 +168,24 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t imx8m_vpu_g2_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+	state = (status & HEVC_REG_INTERRUPT_DEC_RDY_INT) ?
+		 VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vdpu_write(vpu, 0, HEVC_REG_INTERRUPT);
+	vdpu_write(vpu, HEVC_REG_CONFIG_DEC_CLK_GATE_E, HEVC_REG_CONFIG);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
 	struct device_node *np = vpu->dev->of_node;
@@ -176,6 +215,13 @@ static void imx8m_vpu_g1_reset(struct hantro_ctx *ctx)
 	imx8m_soft_reset(vpu, RESET_G1);
 }
 
+static void imx8m_vpu_g2_reset(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	imx8m_soft_reset(vpu, RESET_G2);
+}
+
 /*
  * Supported codec ops.
  */
@@ -201,16 +247,28 @@ static const struct hantro_codec_ops imx8mq_vpu_codec_ops[] = {
 	},
 };
 
+static const struct hantro_codec_ops imx8mq_vpu_g2_codec_ops[] = {
+	[HANTRO_MODE_HEVC_DEC] = {
+		.run = hantro_g2_hevc_dec_run,
+		.reset = imx8m_vpu_g2_reset,
+		.init = hantro_hevc_dec_init,
+		.exit = hantro_hevc_dec_exit,
+	},
+};
+
 /*
  * VPU variants.
  */
 
 static const struct hantro_irq imx8mq_irqs[] = {
 	{ "g1", imx8m_vpu_g1_irq },
-	{ "g2", NULL /* TODO: imx8m_vpu_g2_irq */ },
 };
 
-static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
+static const struct hantro_irq imx8mq_g2_irqs[] = {
+	{ "g2", imx8m_vpu_g2_irq },
+};
+
+static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus"};
 
 const struct hantro_variant imx8mq_vpu_variant = {
 	.dec_fmts = imx8m_vpu_dec_fmts,
@@ -228,3 +286,17 @@ const struct hantro_variant imx8mq_vpu_variant = {
 	.clk_names = imx8mq_clk_names,
 	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
 };
+
+const struct hantro_variant imx8mq_vpu_g2_variant = {
+	.dec_offset = 0x0,
+	.dec_fmts = imx8m_vpu_g2_dec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(imx8m_vpu_g2_dec_fmts),
+	.codec = HANTRO_HEVC_DECODER,
+	.codec_ops = imx8mq_vpu_g2_codec_ops,
+	.init = imx8mq_vpu_hw_init,
+	.runtime_resume = imx8mq_runtime_resume,
+	.irqs = imx8mq_g2_irqs,
+	.num_irqs = ARRAY_SIZE(imx8mq_g2_irqs),
+	.clk_names = imx8mq_clk_names,
+	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
+};
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:32 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:32 +0200
Subject: [PATCH v9 11/13] media: hantro: Introduce G2/HEVC decoder
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-12-benjamin.gaignard@collabora.com>

Implement all the logic to get G2 hardware decoding HEVC frames.
It supports up level 5.1 HEVC stream.
It doesn't support yet 10 bits formats or the scaling feature.

Add HANTRO HEVC dedicated control to skip some bits at the beginning
of the slice header. That is very specific to this hardware so can't
go into uapi structures. Computing the needed value is complex and requires
information from the stream that only the userland knows so let it
provide the correct value to the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Co-developed-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Signed-off-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Co-developed-by: Ezequiel Garcia <ezequiel at collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel at collabora.com>
---
version 9:
 - Corrections in commit message
 - Change V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP control's max value 

version 8:
 - Fix compilation warnings

version 7:
 - Improve motion vectors requested memory size computation.

 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |   2 +
 drivers/staging/media/hantro/hantro_drv.c     |  36 ++
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 drivers/staging/media/hantro/hantro_hevc.c    | 327 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  49 ++
 7 files changed, 1201 insertions(+)
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile
index 743ce08eb184..0357f1772267 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -9,12 +9,14 @@ hantro-vpu-y += \
 		hantro_h1_jpeg_enc.o \
 		hantro_g1_h264_dec.o \
 		hantro_g1_mpeg2_dec.o \
+		hantro_g2_hevc_dec.o \
 		hantro_g1_vp8_dec.o \
 		rk3399_vpu_hw_jpeg_enc.o \
 		rk3399_vpu_hw_mpeg2_dec.o \
 		rk3399_vpu_hw_vp8_dec.o \
 		hantro_jpeg.o \
 		hantro_h264.o \
+		hantro_hevc.o \
 		hantro_mpeg2.o \
 		hantro_vp8.o
 
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 7a5ad93466c8..6a21d1e95b34 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -222,6 +222,7 @@ struct hantro_dev {
  * @jpeg_enc:		JPEG-encoding context.
  * @mpeg2_dec:		MPEG-2-decoding context.
  * @vp8_dec:		VP8-decoding context.
+ * @hevc_dec:		HEVC-decoding context.
  */
 struct hantro_ctx {
 	struct hantro_dev *dev;
@@ -248,6 +249,7 @@ struct hantro_ctx {
 		struct hantro_jpeg_enc_hw_ctx jpeg_enc;
 		struct hantro_mpeg2_dec_hw_ctx mpeg2_dec;
 		struct hantro_vp8_dec_hw_ctx vp8_dec;
+		struct hantro_hevc_dec_hw_ctx hevc_dec;
 	};
 };
 
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index d9a3a5ef9330..905a69758b37 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -281,6 +281,26 @@ static int hantro_jpeg_s_ctrl(struct v4l2_ctrl *ctrl)
 	return 0;
 }
 
+static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct hantro_ctx *ctx;
+
+	ctx = container_of(ctrl->handler,
+			   struct hantro_ctx, ctrl_handler);
+
+	vpu_debug(1, "s_ctrl: id = %d, val = %d\n", ctrl->id, ctrl->val);
+
+	switch (ctrl->id) {
+	case V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP:
+		ctx->hevc_dec.ctrls.hevc_hdr_skip_length = ctrl->val;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
 	.try_ctrl = hantro_try_ctrl,
 };
@@ -289,6 +309,10 @@ static const struct v4l2_ctrl_ops hantro_jpeg_ctrl_ops = {
 	.s_ctrl = hantro_jpeg_s_ctrl,
 };
 
+static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
+	.s_ctrl = hantro_hevc_s_ctrl,
+};
+
 static const struct hantro_ctrl controls[] = {
 	{
 		.codec = HANTRO_JPEG_ENCODER,
@@ -409,6 +433,18 @@ static const struct hantro_ctrl controls[] = {
 		.cfg = {
 			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
 		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP,
+			.name = "Hantro HEVC slice header skip bytes",
+			.type = V4L2_CTRL_TYPE_INTEGER,
+			.min = 0,
+			.def = 0,
+			.max = 0x100,
+			.step = 1,
+			.ops = &hantro_hevc_ctrl_ops,
+		},
 	},
 };
 
diff --git a/drivers/staging/media/hantro/hantro_g2_hevc_dec.c b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
new file mode 100644
index 000000000000..03a193a50c09
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
@@ -0,0 +1,587 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include "hantro_hw.h"
+#include "hantro_g2_regs.h"
+
+#define HEVC_DEC_MODE	0xC
+
+#define BUS_WIDTH_32		0
+#define BUS_WIDTH_64		1
+#define BUS_WIDTH_128		2
+#define BUS_WIDTH_256		3
+
+static inline void hantro_write_addr(struct hantro_dev *vpu,
+				     unsigned long offset,
+				     dma_addr_t addr)
+{
+	vdpu_write(vpu, addr & 0xffffffff, offset);
+}
+
+static void prepare_tile_info_buffer(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	u16 *p = (u16 *)((u8 *)ctx->hevc_dec.tile_sizes.cpu);
+	unsigned int num_tile_rows = pps->num_tile_rows_minus1 + 1;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int pic_width_in_ctbs, pic_height_in_ctbs;
+	unsigned int max_log2_ctb_size, ctb_size;
+	bool tiles_enabled, uniform_spacing;
+	u32 no_chroma = 0;
+
+	tiles_enabled = !!(pps->flags & V4L2_HEVC_PPS_FLAG_TILES_ENABLED);
+	uniform_spacing = !!(pps->flags & V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING);
+
+	hantro_reg_write(vpu, hevc_tile_e, tiles_enabled);
+
+	max_log2_ctb_size = sps->log2_min_luma_coding_block_size_minus3 + 3 +
+			    sps->log2_diff_max_min_luma_coding_block_size;
+	pic_width_in_ctbs = (sps->pic_width_in_luma_samples +
+			    (1 << max_log2_ctb_size) - 1) >> max_log2_ctb_size;
+	pic_height_in_ctbs = (sps->pic_height_in_luma_samples + (1 << max_log2_ctb_size) - 1)
+			     >> max_log2_ctb_size;
+	ctb_size = 1 << max_log2_ctb_size;
+
+	vpu_debug(1, "Preparing tile sizes buffer for %dx%d CTBs (CTB size %d)\n",
+		  pic_width_in_ctbs, pic_height_in_ctbs, ctb_size);
+
+	if (tiles_enabled) {
+		unsigned int i, j, h;
+
+		vpu_debug(1, "Tiles enabled! %dx%d\n", num_tile_cols, num_tile_rows);
+
+		hantro_reg_write(vpu, hevc_num_tile_rows, num_tile_rows);
+		hantro_reg_write(vpu, hevc_num_tile_cols, num_tile_cols);
+
+		/* write width + height for each tile in pic */
+		if (!uniform_spacing) {
+			u32 tmp_w = 0, tmp_h = 0;
+
+			for (i = 0; i < num_tile_rows; i++) {
+				if (i == num_tile_rows - 1)
+					h = pic_height_in_ctbs - tmp_h;
+				else
+					h = pps->row_height_minus1[i] + 1;
+				tmp_h += h;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, tmp_w = 0; j < num_tile_cols - 1; j++) {
+					tmp_w += pps->column_width_minus1[j] + 1;
+					*p++ = pps->column_width_minus1[j + 1];
+					*p++ = h;
+					if (i == 0 && h == 1 && ctb_size == 16)
+						no_chroma = 1;
+				}
+				/* last column */
+				*p++ = pic_width_in_ctbs - tmp_w;
+				*p++ = h;
+			}
+		} else { /* uniform spacing */
+			u32 tmp, prev_h, prev_w;
+
+			for (i = 0, prev_h = 0; i < num_tile_rows; i++) {
+				tmp = (i + 1) * pic_height_in_ctbs / num_tile_rows;
+				h = tmp - prev_h;
+				prev_h = tmp;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, prev_w = 0; j < num_tile_cols; j++) {
+					tmp = (j + 1) * pic_width_in_ctbs / num_tile_cols;
+					*p++ = tmp - prev_w;
+					*p++ = h;
+					if (j == 0 &&
+					    (pps->column_width_minus1[0] + 1) == 1 &&
+					    ctb_size == 16)
+						no_chroma = 1;
+					prev_w = tmp;
+				}
+			}
+		}
+	} else {
+		hantro_reg_write(vpu, hevc_num_tile_rows, 1);
+		hantro_reg_write(vpu, hevc_num_tile_cols, 1);
+
+		/* There's one tile, with dimensions equal to pic size. */
+		p[0] = pic_width_in_ctbs;
+		p[1] = pic_height_in_ctbs;
+	}
+
+	if (no_chroma)
+		vpu_debug(1, "%s: no chroma!\n", __func__);
+}
+
+static void set_params(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 min_log2_cb_size, max_log2_ctb_size, min_cb_size, max_ctb_size;
+	u32 pic_width_in_min_cbs, pic_height_in_min_cbs;
+	u32 pic_width_aligned, pic_height_aligned;
+	u32 partial_ctb_x, partial_ctb_y;
+
+	hantro_reg_write(vpu, hevc_bit_depth_y_minus8, sps->bit_depth_luma_minus8);
+	hantro_reg_write(vpu, hevc_bit_depth_c_minus8, sps->bit_depth_chroma_minus8);
+
+	hantro_reg_write(vpu, hevc_output_8_bits, 0);
+
+	hantro_reg_write(vpu, hevc_hdr_skip_length, ctrls->hevc_hdr_skip_length);
+
+	min_log2_cb_size = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	max_log2_ctb_size = min_log2_cb_size + sps->log2_diff_max_min_luma_coding_block_size;
+
+	hantro_reg_write(vpu, hevc_min_cb_size, min_log2_cb_size);
+	hantro_reg_write(vpu, hevc_max_cb_size, max_log2_ctb_size);
+
+	min_cb_size = 1 << min_log2_cb_size;
+	max_ctb_size = 1 << max_log2_ctb_size;
+
+	pic_width_in_min_cbs = sps->pic_width_in_luma_samples / min_cb_size;
+	pic_height_in_min_cbs = sps->pic_height_in_luma_samples / min_cb_size;
+	pic_width_aligned = ALIGN(sps->pic_width_in_luma_samples, max_ctb_size);
+	pic_height_aligned = ALIGN(sps->pic_height_in_luma_samples, max_ctb_size);
+
+	partial_ctb_x = !!(sps->pic_width_in_luma_samples != pic_width_aligned);
+	partial_ctb_y = !!(sps->pic_height_in_luma_samples != pic_height_aligned);
+
+	hantro_reg_write(vpu, hevc_partial_ctb_x, partial_ctb_x);
+	hantro_reg_write(vpu, hevc_partial_ctb_y, partial_ctb_y);
+
+	hantro_reg_write(vpu, hevc_pic_width_in_cbs, pic_width_in_min_cbs);
+	hantro_reg_write(vpu, hevc_pic_height_in_cbs, pic_height_in_min_cbs);
+
+	hantro_reg_write(vpu, hevc_pic_width_4x4,
+			 (pic_width_in_min_cbs * min_cb_size) / 4);
+	hantro_reg_write(vpu, hevc_pic_height_4x4,
+			 (pic_height_in_min_cbs * min_cb_size) / 4);
+
+	hantro_reg_write(vpu, hevc_max_inter_hierdepth,
+			 sps->max_transform_hierarchy_depth_inter);
+	hantro_reg_write(vpu, hevc_max_intra_hierdepth,
+			 sps->max_transform_hierarchy_depth_intra);
+	hantro_reg_write(vpu, hevc_min_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2);
+	hantro_reg_write(vpu, hevc_max_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2 +
+			 sps->log2_diff_max_min_luma_transform_block_size);
+
+	hantro_reg_write(vpu, hevc_tempor_mvp_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED) &&
+			 !(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC));
+	hantro_reg_write(vpu, hevc_strong_smooth_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED));
+	hantro_reg_write(vpu, hevc_asym_pred_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_AMP_ENABLED));
+	hantro_reg_write(vpu, hevc_sao_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET));
+	hantro_reg_write(vpu, hevc_sign_data_hide,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED));
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED) {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 1);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, pps->diff_cu_qp_delta_depth);
+	} else {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 0);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, 0);
+	}
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT) {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, pps->pps_cb_qp_offset);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, pps->pps_cr_qp_offset);
+	} else {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, 0);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_filt_offset_beta, pps->pps_beta_offset_div2);
+	hantro_reg_write(vpu, hevc_filt_offset_tc, pps->pps_tc_offset_div2);
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT));
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_bits, pps->num_extra_slice_header_bits);
+	hantro_reg_write(vpu, hevc_slice_chqp_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT));
+	hantro_reg_write(vpu, hevc_weight_bipr_idc,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED));
+	hantro_reg_write(vpu, hevc_transq_bypass,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED));
+	hantro_reg_write(vpu, hevc_list_mod_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT));
+	hantro_reg_write(vpu, hevc_entropy_sync_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_idr_pic_e,
+			 !!(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC));
+	hantro_reg_write(vpu, hevc_parallel_merge,
+			 pps->log2_parallel_merge_level_minus2 + 2);
+	hantro_reg_write(vpu, hevc_pcm_filt_d,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED));
+	hantro_reg_write(vpu, hevc_pcm_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED));
+	if (sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED) {
+		hantro_reg_write(vpu, hevc_max_pcm_size,
+				 sps->log2_diff_max_min_pcm_luma_coding_block_size +
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_min_pcm_size,
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y,
+				 sps->pcm_sample_bit_depth_luma_minus1 + 1);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c,
+				 sps->pcm_sample_bit_depth_chroma_minus1 + 1);
+	} else {
+		hantro_reg_write(vpu, hevc_max_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_min_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_start_code_e, 1);
+	hantro_reg_write(vpu, hevc_init_qp, pps->init_qp_minus26 + 26);
+	hantro_reg_write(vpu, hevc_weight_pred_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_const_intra_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED));
+	hantro_reg_write(vpu, hevc_transform_skip,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED));
+	hantro_reg_write(vpu, hevc_out_filtering_dis,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER));
+	hantro_reg_write(vpu, hevc_filt_ctrl_pres,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT));
+	hantro_reg_write(vpu, hevc_dependent_slice,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT));
+	hantro_reg_write(vpu, hevc_filter_override,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED));
+	hantro_reg_write(vpu, hevc_refidx0_active,
+			 pps->num_ref_idx_l0_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_refidx1_active,
+			 pps->num_ref_idx_l1_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_apf_threshold, 8);
+}
+
+static int find_ref_pic_index(const struct v4l2_hevc_dpb_entry *dpb, int pic_order_cnt)
+{
+	int i;
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		if (dpb[i].pic_order_cnt[0] == pic_order_cnt)
+			return i;
+	}
+
+	return 0x0;
+}
+
+static void set_ref_pic_list(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	u32 list0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	u32 list1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	const struct hantro_reg *ref_pic_regs0[] = {
+		hevc_rlist_f0,
+		hevc_rlist_f1,
+		hevc_rlist_f2,
+		hevc_rlist_f3,
+		hevc_rlist_f4,
+		hevc_rlist_f5,
+		hevc_rlist_f6,
+		hevc_rlist_f7,
+		hevc_rlist_f8,
+		hevc_rlist_f9,
+		hevc_rlist_f10,
+		hevc_rlist_f11,
+		hevc_rlist_f12,
+		hevc_rlist_f13,
+		hevc_rlist_f14,
+		hevc_rlist_f15,
+	};
+	const struct hantro_reg *ref_pic_regs1[] = {
+		hevc_rlist_b0,
+		hevc_rlist_b1,
+		hevc_rlist_b2,
+		hevc_rlist_b3,
+		hevc_rlist_b4,
+		hevc_rlist_b5,
+		hevc_rlist_b6,
+		hevc_rlist_b7,
+		hevc_rlist_b8,
+		hevc_rlist_b9,
+		hevc_rlist_b10,
+		hevc_rlist_b11,
+		hevc_rlist_b12,
+		hevc_rlist_b13,
+		hevc_rlist_b14,
+		hevc_rlist_b15,
+	};
+	unsigned int i, j;
+
+	/* List 0 contains: short term before, short term after and long term */
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	/* Fill the list, copying over and over */
+	i = 0;
+	while (j < ARRAY_SIZE(list0))
+		list0[j++] = list0[i++];
+
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	i = 0;
+	while (j < ARRAY_SIZE(list1))
+		list1[j++] = list1[i++];
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_reg_write(vpu, ref_pic_regs0[i], list0[i]);
+		hantro_reg_write(vpu, ref_pic_regs1[i], list1[i]);
+	}
+}
+
+static int set_ref(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
+	struct hantro_dev *vpu = ctx->dev;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	size_t mv_offset = hantro_hevc_motion_vectors_offset(sps);
+	u32 max_ref_frames;
+	u16 dpb_longterm_e;
+
+	const struct hantro_reg *cur_poc[] = {
+		hevc_cur_poc_00,
+		hevc_cur_poc_01,
+		hevc_cur_poc_02,
+		hevc_cur_poc_03,
+		hevc_cur_poc_04,
+		hevc_cur_poc_05,
+		hevc_cur_poc_06,
+		hevc_cur_poc_07,
+		hevc_cur_poc_08,
+		hevc_cur_poc_09,
+		hevc_cur_poc_10,
+		hevc_cur_poc_11,
+		hevc_cur_poc_12,
+		hevc_cur_poc_13,
+		hevc_cur_poc_14,
+		hevc_cur_poc_15,
+	};
+	unsigned int i;
+
+	max_ref_frames = decode_params->num_poc_lt_curr +
+		decode_params->num_poc_st_curr_before +
+		decode_params->num_poc_st_curr_after;
+	/*
+	 * Set max_ref_frames to non-zero to avoid HW hang when decoding
+	 * badly marked I-frames.
+	 */
+	max_ref_frames = max_ref_frames ? max_ref_frames : 1;
+	hantro_reg_write(vpu, hevc_num_ref_frames, max_ref_frames);
+	hantro_reg_write(vpu, hevc_filter_over_slices,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED));
+	hantro_reg_write(vpu, hevc_filter_over_tiles,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED));
+
+	/*
+	 * Write POC count diff from current pic. For frame decoding only compute
+	 * pic_order_cnt[0] and ignore pic_order_cnt[1] used in field-coding.
+	 */
+	for (i = 0; i < decode_params->num_active_dpb_entries && i < ARRAY_SIZE(cur_poc); i++) {
+		char poc_diff = decode_params->pic_order_cnt_val - dpb[i].pic_order_cnt[0];
+
+		hantro_reg_write(vpu, cur_poc[i], poc_diff);
+	}
+
+	if (i < ARRAY_SIZE(cur_poc)) {
+		/*
+		 * After the references, fill one entry pointing to itself,
+		 * i.e. difference is zero.
+		 */
+		hantro_reg_write(vpu, cur_poc[i], 0);
+		i++;
+	}
+
+	/* Fill the rest with the current picture */
+	for (; i < ARRAY_SIZE(cur_poc); i++)
+		hantro_reg_write(vpu, cur_poc[i], decode_params->pic_order_cnt_val);
+
+	set_ref_pic_list(ctx);
+
+	/* We will only keep the references picture that are still used */
+	ctx->hevc_dec.ref_bufs_used = 0;
+
+	/* Set up addresses of DPB buffers */
+	dpb_longterm_e = 0;
+	for (i = 0; i < decode_params->num_active_dpb_entries &&
+	     i < (V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1); i++) {
+		luma_addr = hantro_hevc_get_ref_buf(ctx, dpb[i].pic_order_cnt[0]);
+		if (!luma_addr)
+			return -ENOMEM;
+
+		chroma_addr = luma_addr + cr_offset;
+		mv_addr = luma_addr + mv_offset;
+
+		if (dpb[i].rps == V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR)
+			dpb_longterm_e |= BIT(V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1 - i);
+
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), mv_addr);
+	}
+
+	luma_addr = hantro_hevc_get_ref_buf(ctx, decode_params->pic_order_cnt_val);
+	if (!luma_addr)
+		return -ENOMEM;
+
+	chroma_addr = luma_addr + cr_offset;
+	mv_addr = luma_addr + mv_offset;
+
+	hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+	hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+	hantro_write_addr(vpu, HEVC_REG_DMV_REF(i++), mv_addr);
+
+	hantro_write_addr(vpu, HEVC_ADDR_DST, luma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_CHR, chroma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_MV, mv_addr);
+
+	hantro_hevc_ref_remove_unused(ctx);
+
+	for (; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), 0);
+	}
+
+	hantro_reg_write(vpu, hevc_refer_lterm_e, dpb_longterm_e);
+
+	return 0;
+}
+
+static void set_buffers(struct hantro_ctx *ctx)
+{
+	struct vb2_v4l2_buffer *src_buf, *dst_buf;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	dma_addr_t src_dma, dst_dma;
+	u32 src_len, src_buf_len;
+
+	src_buf = hantro_get_src_buf(ctx);
+	dst_buf = hantro_get_dst_buf(ctx);
+
+	/* Source (stream) buffer. */
+	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+	src_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+	src_buf_len = vb2_plane_size(&src_buf->vb2_buf, 0);
+
+	hantro_write_addr(vpu, HEVC_ADDR_STR, src_dma);
+	hantro_reg_write(vpu, hevc_stream_len, src_len);
+	hantro_reg_write(vpu, hevc_strm_buffer_len, src_buf_len);
+	hantro_reg_write(vpu, hevc_strm_start_offset, 0);
+	hantro_reg_write(vpu, hevc_write_mvs_e, 1);
+
+	/* Destination (decoded frame) buffer. */
+	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
+
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN, dst_dma);
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN_CHR, dst_dma + cr_offset);
+	hantro_write_addr(vpu, HEVC_ADDR_TILE_SIZE, ctx->hevc_dec.tile_sizes.dma);
+	hantro_write_addr(vpu, HEVC_TILE_FILTER, ctx->hevc_dec.tile_filter.dma);
+	hantro_write_addr(vpu, HEVC_TILE_SAO, ctx->hevc_dec.tile_sao.dma);
+	hantro_write_addr(vpu, HEVC_TILE_BSD, ctx->hevc_dec.tile_bsd.dma);
+}
+
+static void hantro_g2_check_idle(struct hantro_dev *vpu)
+{
+	int i;
+
+	for (i = 0; i < 3; i++) {
+		u32 status;
+
+		/* Make sure the VPU is idle */
+		status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+		if (status & HEVC_REG_INTERRUPT_DEC_E) {
+			dev_warn(vpu->dev, "device still running, aborting");
+			status |= HEVC_REG_INTERRUPT_DEC_ABORT_E | HEVC_REG_INTERRUPT_DEC_IRQ_DIS;
+			vdpu_write(vpu, status, HEVC_REG_INTERRUPT);
+		}
+	}
+}
+
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	int ret;
+
+	hantro_g2_check_idle(vpu);
+
+	/* Prepare HEVC decoder context. */
+	ret = hantro_hevc_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
+
+	/* Configure hardware registers. */
+	set_params(ctx);
+
+	/* set reference pictures */
+	ret = set_ref(ctx);
+	if (ret)
+		return ret;
+
+	set_buffers(ctx);
+	prepare_tile_info_buffer(ctx);
+
+	hantro_end_prepare_run(ctx);
+
+	hantro_reg_write(vpu, hevc_mode, HEVC_DEC_MODE);
+	hantro_reg_write(vpu, hevc_clk_gate_e, 1);
+
+	/* Don't disable output */
+	hantro_reg_write(vpu, hevc_out_dis, 0);
+
+	/* Don't compress buffers */
+	hantro_reg_write(vpu, hevc_ref_compress_bypass, 1);
+
+	/* use NV12 as output format */
+	hantro_reg_write(vpu, hevc_out_rs_e, 1);
+
+	/* Bus width and max burst */
+	hantro_reg_write(vpu, hevc_buswidth, BUS_WIDTH_128);
+	hantro_reg_write(vpu, hevc_max_burst, 16);
+
+	/* Swap */
+	hantro_reg_write(vpu, hevc_strm_swap, 0xf);
+	hantro_reg_write(vpu, hevc_dirmv_swap, 0xf);
+	hantro_reg_write(vpu, hevc_compress_swap, 0xf);
+
+	/* Start decoding! */
+	vdpu_write(vpu, HEVC_REG_INTERRUPT_DEC_E, HEVC_REG_INTERRUPT);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_g2_regs.h b/drivers/staging/media/hantro/hantro_g2_regs.h
new file mode 100644
index 000000000000..a361c9ba911d
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_regs.h
@@ -0,0 +1,198 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2021, Collabora
+ *
+ * Author: Benjamin Gaignard <benjamin.gaignard at collabora.com>
+ */
+
+#ifndef HANTRO_G2_REGS_H_
+#define HANTRO_G2_REGS_H_
+
+#include "hantro.h"
+
+#define G2_SWREG(nr)	((nr) * 4)
+
+#define HEVC_DEC_REG(name, base, shift, mask) \
+	static const struct hantro_reg _hevc_##name[] = { \
+		{ G2_SWREG(base), (shift), (mask) } \
+	}; \
+	static const struct hantro_reg __maybe_unused *hevc_##name = &_hevc_##name[0];
+
+#define HEVC_REG_VERSION		G2_SWREG(0)
+
+#define HEVC_REG_INTERRUPT		G2_SWREG(1)
+#define HEVC_REG_INTERRUPT_DEC_RDY_INT	BIT(12)
+#define HEVC_REG_INTERRUPT_DEC_ABORT_E	BIT(5)
+#define HEVC_REG_INTERRUPT_DEC_IRQ_DIS	BIT(4)
+#define HEVC_REG_INTERRUPT_DEC_E	BIT(0)
+
+HEVC_DEC_REG(strm_swap,		2, 28,	0xf)
+HEVC_DEC_REG(dirmv_swap,	2, 20,	0xf)
+
+HEVC_DEC_REG(mode,		  3, 27, 0x1f)
+HEVC_DEC_REG(compress_swap,	  3, 20, 0xf)
+HEVC_DEC_REG(ref_compress_bypass, 3, 17, 0x1)
+HEVC_DEC_REG(out_rs_e,		  3, 16, 0x1)
+HEVC_DEC_REG(out_dis,		  3, 15, 0x1)
+HEVC_DEC_REG(out_filtering_dis,   3, 14, 0x1)
+HEVC_DEC_REG(write_mvs_e,	  3, 12, 0x1)
+
+HEVC_DEC_REG(pic_width_in_cbs,	4, 19,	0x1ff)
+HEVC_DEC_REG(pic_height_in_cbs,	4, 6,	0x1ff)
+HEVC_DEC_REG(num_ref_frames,	4, 0,	0x1f)
+
+HEVC_DEC_REG(scaling_list_e,	5, 24,	0x1)
+HEVC_DEC_REG(cb_qp_offset,	5, 19,	0x1f)
+HEVC_DEC_REG(cr_qp_offset,	5, 14,	0x1f)
+HEVC_DEC_REG(sign_data_hide,	5, 12,	0x1)
+HEVC_DEC_REG(tempor_mvp_e,	5, 11,	0x1)
+HEVC_DEC_REG(max_cu_qpd_depth,	5, 5,	0x3f)
+HEVC_DEC_REG(cu_qpd_e,		5, 4,	0x1)
+
+HEVC_DEC_REG(stream_len,	6, 0,	0xffffffff)
+
+HEVC_DEC_REG(cabac_init_present, 7, 31, 0x1)
+HEVC_DEC_REG(weight_pred_e,	 7, 28, 0x1)
+HEVC_DEC_REG(weight_bipr_idc,	 7, 26, 0x3)
+HEVC_DEC_REG(filter_over_slices, 7, 25, 0x1)
+HEVC_DEC_REG(filter_over_tiles,  7, 24, 0x1)
+HEVC_DEC_REG(asym_pred_e,	 7, 23, 0x1)
+HEVC_DEC_REG(sao_e,		 7, 22, 0x1)
+HEVC_DEC_REG(pcm_filt_d,	 7, 21, 0x1)
+HEVC_DEC_REG(slice_chqp_present, 7, 20, 0x1)
+HEVC_DEC_REG(dependent_slice,	 7, 19, 0x1)
+HEVC_DEC_REG(filter_override,	 7, 18, 0x1)
+HEVC_DEC_REG(strong_smooth_e,	 7, 17, 0x1)
+HEVC_DEC_REG(filt_offset_beta,	 7, 12, 0x1f)
+HEVC_DEC_REG(filt_offset_tc,	 7, 7,  0x1f)
+HEVC_DEC_REG(slice_hdr_ext_e,	 7, 6,	0x1)
+HEVC_DEC_REG(slice_hdr_ext_bits, 7, 3,	0x7)
+
+HEVC_DEC_REG(const_intra_e,	 8, 31, 0x1)
+HEVC_DEC_REG(filt_ctrl_pres,	 8, 30, 0x1)
+HEVC_DEC_REG(idr_pic_e,		 8, 16, 0x1)
+HEVC_DEC_REG(bit_depth_pcm_y,	 8, 12, 0xf)
+HEVC_DEC_REG(bit_depth_pcm_c,	 8, 8,  0xf)
+HEVC_DEC_REG(bit_depth_y_minus8, 8, 6,  0x3)
+HEVC_DEC_REG(bit_depth_c_minus8, 8, 4,  0x3)
+HEVC_DEC_REG(output_8_bits,	 8, 3,  0x1)
+
+HEVC_DEC_REG(refidx1_active,	9, 19,	0x1f)
+HEVC_DEC_REG(refidx0_active,	9, 14,	0x1f)
+HEVC_DEC_REG(hdr_skip_length,	9, 0,	0x3fff)
+
+HEVC_DEC_REG(start_code_e,	10, 31, 0x1)
+HEVC_DEC_REG(init_qp,		10, 24, 0x3f)
+HEVC_DEC_REG(num_tile_cols,	10, 19, 0x1f)
+HEVC_DEC_REG(num_tile_rows,	10, 14, 0x1f)
+HEVC_DEC_REG(tile_e,		10, 1,	0x1)
+HEVC_DEC_REG(entropy_sync_e,	10, 0,	0x1)
+
+HEVC_DEC_REG(refer_lterm_e,	12, 16, 0xffff)
+HEVC_DEC_REG(min_cb_size,	12, 13, 0x7)
+HEVC_DEC_REG(max_cb_size,	12, 10, 0x7)
+HEVC_DEC_REG(min_pcm_size,	12, 7,  0x7)
+HEVC_DEC_REG(max_pcm_size,	12, 4,  0x7)
+HEVC_DEC_REG(pcm_e,		12, 3,  0x1)
+HEVC_DEC_REG(transform_skip,	12, 2,	0x1)
+HEVC_DEC_REG(transq_bypass,	12, 1,	0x1)
+HEVC_DEC_REG(list_mod_e,	12, 0,	0x1)
+
+HEVC_DEC_REG(min_trb_size,	  13, 13, 0x7)
+HEVC_DEC_REG(max_trb_size,	  13, 10, 0x7)
+HEVC_DEC_REG(max_intra_hierdepth, 13, 7,  0x7)
+HEVC_DEC_REG(max_inter_hierdepth, 13, 4,  0x7)
+HEVC_DEC_REG(parallel_merge,	  13, 0,  0xf)
+
+HEVC_DEC_REG(rlist_f0,		14, 0,	0x1f)
+HEVC_DEC_REG(rlist_f1,		14, 10,	0x1f)
+HEVC_DEC_REG(rlist_f2,		14, 20,	0x1f)
+HEVC_DEC_REG(rlist_b0,		14, 5,	0x1f)
+HEVC_DEC_REG(rlist_b1,		14, 15, 0x1f)
+HEVC_DEC_REG(rlist_b2,		14, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f3,		15, 0,	0x1f)
+HEVC_DEC_REG(rlist_f4,		15, 10, 0x1f)
+HEVC_DEC_REG(rlist_f5,		15, 20, 0x1f)
+HEVC_DEC_REG(rlist_b3,		15, 5,	0x1f)
+HEVC_DEC_REG(rlist_b4,		15, 15, 0x1f)
+HEVC_DEC_REG(rlist_b5,		15, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f6,		16, 0,	0x1f)
+HEVC_DEC_REG(rlist_f7,		16, 10, 0x1f)
+HEVC_DEC_REG(rlist_f8,		16, 20, 0x1f)
+HEVC_DEC_REG(rlist_b6,		16, 5,	0x1f)
+HEVC_DEC_REG(rlist_b7,		16, 15, 0x1f)
+HEVC_DEC_REG(rlist_b8,		16, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f9,		17, 0,	0x1f)
+HEVC_DEC_REG(rlist_f10,		17, 10, 0x1f)
+HEVC_DEC_REG(rlist_f11,		17, 20, 0x1f)
+HEVC_DEC_REG(rlist_b9,		17, 5,	0x1f)
+HEVC_DEC_REG(rlist_b10,		17, 15, 0x1f)
+HEVC_DEC_REG(rlist_b11,		17, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f12,		18, 0,	0x1f)
+HEVC_DEC_REG(rlist_f13,		18, 10, 0x1f)
+HEVC_DEC_REG(rlist_f14,		18, 20, 0x1f)
+HEVC_DEC_REG(rlist_b12,		18, 5,	0x1f)
+HEVC_DEC_REG(rlist_b13,		18, 15, 0x1f)
+HEVC_DEC_REG(rlist_b14,		18, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f15,		19, 0,	0x1f)
+HEVC_DEC_REG(rlist_b15,		19, 5,	0x1f)
+
+HEVC_DEC_REG(partial_ctb_x,	20, 31, 0x1)
+HEVC_DEC_REG(partial_ctb_y,	20, 30, 0x1)
+HEVC_DEC_REG(pic_width_4x4,	20, 16, 0xfff)
+HEVC_DEC_REG(pic_height_4x4,	20, 0,  0xfff)
+
+HEVC_DEC_REG(cur_poc_00,	46, 24,	0xff)
+HEVC_DEC_REG(cur_poc_01,	46, 16,	0xff)
+HEVC_DEC_REG(cur_poc_02,	46, 8,	0xff)
+HEVC_DEC_REG(cur_poc_03,	46, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_04,	47, 24,	0xff)
+HEVC_DEC_REG(cur_poc_05,	47, 16,	0xff)
+HEVC_DEC_REG(cur_poc_06,	47, 8,	0xff)
+HEVC_DEC_REG(cur_poc_07,	47, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_08,	48, 24,	0xff)
+HEVC_DEC_REG(cur_poc_09,	48, 16,	0xff)
+HEVC_DEC_REG(cur_poc_10,	48, 8,	0xff)
+HEVC_DEC_REG(cur_poc_11,	48, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_12,	49, 24, 0xff)
+HEVC_DEC_REG(cur_poc_13,	49, 16, 0xff)
+HEVC_DEC_REG(cur_poc_14,	49, 8,	0xff)
+HEVC_DEC_REG(cur_poc_15,	49, 0,	0xff)
+
+HEVC_DEC_REG(apf_threshold,	55, 0,	0xffff)
+
+HEVC_DEC_REG(clk_gate_e,	58, 16,	0x1)
+HEVC_DEC_REG(buswidth,		58, 8,	0x7)
+HEVC_DEC_REG(max_burst,		58, 0,	0xff)
+
+#define HEVC_REG_CONFIG				G2_SWREG(58)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_E		BIT(16)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_IDLE_E	BIT(17)
+
+#define HEVC_ADDR_DST		(G2_SWREG(65))
+#define HEVC_REG_ADDR_REF(i)	(G2_SWREG(67)  + ((i) * 0x8))
+#define HEVC_ADDR_DST_CHR	(G2_SWREG(99))
+#define HEVC_REG_CHR_REF(i)	(G2_SWREG(101) + ((i) * 0x8))
+#define HEVC_ADDR_DST_MV	(G2_SWREG(133))
+#define HEVC_REG_DMV_REF(i)	(G2_SWREG(135) + ((i) * 0x8))
+#define HEVC_ADDR_TILE_SIZE	(G2_SWREG(167))
+#define HEVC_ADDR_STR		(G2_SWREG(169))
+#define HEVC_SCALING_LIST	(G2_SWREG(171))
+#define HEVC_RASTER_SCAN	(G2_SWREG(175))
+#define HEVC_RASTER_SCAN_CHR	(G2_SWREG(177))
+#define HEVC_TILE_FILTER	(G2_SWREG(179))
+#define HEVC_TILE_SAO		(G2_SWREG(181))
+#define HEVC_TILE_BSD		(G2_SWREG(183))
+
+HEVC_DEC_REG(strm_buffer_len,	258, 0,	0xffffffff)
+HEVC_DEC_REG(strm_start_offset,	259, 0,	0xffffffff)
+
+#endif
diff --git a/drivers/staging/media/hantro/hantro_hevc.c b/drivers/staging/media/hantro/hantro_hevc.c
new file mode 100644
index 000000000000..015197797591
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_hevc.c
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include <linux/types.h>
+#include <media/v4l2-mem2mem.h>
+
+#include "hantro.h"
+#include "hantro_hw.h"
+
+#define VERT_FILTER_RAM_SIZE 8 /* bytes per pixel row */
+/*
+ * BSD control data of current picture at tile border
+ * 128 bits per 4x4 tile = 128/(8*4) bytes per row
+ */
+#define BSD_CTRL_RAM_SIZE 4 /* bytes per pixel row */
+/* tile border coefficients of filter */
+#define VERT_SAO_RAM_SIZE 48 /* bytes per pixel */
+
+#define MAX_TILE_COLS 20
+#define MAX_TILE_ROWS 22
+
+#define UNUSED_REF	-1
+
+#define G2_ALIGN		16
+
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	int bytes_per_pixel = sps->bit_depth_luma_minus8 == 0 ? 1 : 2;
+
+	return sps->pic_width_in_luma_samples *
+	       sps->pic_height_in_luma_samples * bytes_per_pixel;
+}
+
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+
+	return ALIGN((cr_offset * 3) / 2, G2_ALIGN);
+}
+
+static size_t hantro_hevc_mv_size(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	u32 min_cb_log2_size_y = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	u32 ctb_log2_size_y = min_cb_log2_size_y + sps->log2_diff_max_min_luma_coding_block_size;
+	u32 pic_width_in_ctbs_y = (sps->pic_width_in_luma_samples + (1 << ctb_log2_size_y) - 1)
+				  >> ctb_log2_size_y;
+	u32 pic_height_in_ctbs_y = (sps->pic_height_in_luma_samples + (1 << ctb_log2_size_y) - 1)
+				   >> ctb_log2_size_y;
+	size_t mv_size;
+
+	mv_size = pic_width_in_ctbs_y * pic_height_in_ctbs_y *
+		  (1 << (2 * (ctb_log2_size_y - 4))) * 16;
+
+	vpu_debug(4, "%dx%d (CTBs) %zu MV bytes\n",
+		  pic_width_in_ctbs_y, pic_height_in_ctbs_y, mv_size);
+
+	return mv_size;
+}
+
+static size_t hantro_hevc_ref_size(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+
+	return hantro_hevc_motion_vectors_offset(sps) + hantro_hevc_mv_size(sps);
+}
+
+static void hantro_hevc_ref_free(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	struct hantro_dev *vpu = ctx->dev;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs[i].cpu)
+			dma_free_coherent(vpu->dev, hevc_dec->ref_bufs[i].size,
+					  hevc_dec->ref_bufs[i].cpu,
+					  hevc_dec->ref_bufs[i].dma);
+	}
+}
+
+static void hantro_hevc_ref_init(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++)
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+}
+
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
+				   int poc)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Find the reference buffer in already know ones */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == poc) {
+			hevc_dec->ref_bufs_used |= 1 << i;
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	/* Allocate a new reference buffer */
+	for (i = 0; i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF) {
+			if (!hevc_dec->ref_bufs[i].cpu) {
+				struct hantro_dev *vpu = ctx->dev;
+
+				/*
+				 * Allocate the space needed for the raw data +
+				 * motion vector data. Optimizations could be to
+				 * allocate raw data in non coherent memory and only
+				 * clear the motion vector data.
+				 */
+				hevc_dec->ref_bufs[i].cpu =
+					dma_alloc_coherent(vpu->dev,
+							   hantro_hevc_ref_size(ctx),
+							   &hevc_dec->ref_bufs[i].dma,
+							   GFP_KERNEL);
+				if (!hevc_dec->ref_bufs[i].cpu)
+					return 0;
+
+				hevc_dec->ref_bufs[i].size = hantro_hevc_ref_size(ctx);
+			}
+			hevc_dec->ref_bufs_used |= 1 << i;
+			memset(hevc_dec->ref_bufs[i].cpu, 0, hantro_hevc_ref_size(ctx));
+			hevc_dec->ref_bufs_poc[i] = poc;
+
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	return 0;
+}
+
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Just tag buffer as unused, do not free them */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF)
+			continue;
+
+		if (hevc_dec->ref_bufs_used & (1 << i))
+			continue;
+
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+	}
+}
+
+static int tile_buffer_reallocate(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int height64 = (sps->pic_height_in_luma_samples + 63) & ~63;
+	unsigned int size;
+
+	if (num_tile_cols <= 1 ||
+	    num_tile_cols <= hevc_dec->num_tile_cols_allocated)
+		return 0;
+
+	/* Need to reallocate due to tiles passed via PPS */
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+
+	size = VERT_FILTER_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_filter.cpu = dma_alloc_coherent(vpu->dev, size,
+						       &hevc_dec->tile_filter.dma,
+						       GFP_KERNEL);
+	if (!hevc_dec->tile_filter.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_filter.size = size;
+
+	size = VERT_SAO_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_sao.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_sao.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_sao.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_sao.size = size;
+
+	size = BSD_CTRL_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_bsd.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_bsd.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_bsd.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_bsd.size = size;
+
+	hevc_dec->num_tile_cols_allocated = num_tile_cols;
+
+	return 0;
+
+err_free_tile_buffers:
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	return -ENOMEM;
+}
+
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_ctx = &ctx->hevc_dec;
+	struct hantro_hevc_dec_ctrls *ctrls = &hevc_ctx->ctrls;
+	int ret;
+
+	hantro_start_prepare_run(ctx);
+
+	ctrls->decode_params =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
+	if (WARN_ON(!ctrls->decode_params))
+		return -EINVAL;
+
+	ctrls->sps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_SPS);
+	if (WARN_ON(!ctrls->sps))
+		return -EINVAL;
+
+	ctrls->pps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_PPS);
+	if (WARN_ON(!ctrls->pps))
+		return -EINVAL;
+
+	ret = tile_buffer_reallocate(ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+
+	if (hevc_dec->tile_sizes.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sizes.size,
+				  hevc_dec->tile_sizes.cpu,
+				  hevc_dec->tile_sizes.dma);
+	hevc_dec->tile_sizes.cpu = NULL;
+
+	if (hevc_dec->tile_filter.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	hantro_hevc_ref_free(ctx);
+}
+
+int hantro_hevc_dec_init(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	unsigned int size;
+
+	memset(hevc_dec, 0, sizeof(*hevc_dec));
+
+	/*
+	 * Maximum number of tiles times width and height (2 bytes each),
+	 * rounding up to next 16 bytes boundary + one extra 16 byte
+	 * chunk (HW guys wanted to have this).
+	 */
+	size = round_up(MAX_TILE_COLS * MAX_TILE_ROWS * 4 * sizeof(u16) + 16, 16);
+	hevc_dec->tile_sizes.cpu = dma_alloc_coherent(vpu->dev, size,
+						      &hevc_dec->tile_sizes.dma,
+						      GFP_KERNEL);
+	if (!hevc_dec->tile_sizes.cpu)
+		return -ENOMEM;
+
+	hevc_dec->tile_sizes.size = size;
+
+	hantro_hevc_ref_init(ctx);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 6a34ddfa34b7..41f3d5b92357 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -20,6 +20,8 @@
 #define MB_WIDTH(w)		DIV_ROUND_UP(w, MB_DIM)
 #define MB_HEIGHT(h)		DIV_ROUND_UP(h, MB_DIM)
 
+#define NUM_REF_PICTURES	(V4L2_HEVC_DPB_ENTRIES_NUM_MAX + 1)
+
 struct hantro_dev;
 struct hantro_ctx;
 struct hantro_buf;
@@ -95,6 +97,44 @@ struct hantro_h264_dec_hw_ctx {
 	struct hantro_h264_dec_ctrls ctrls;
 };
 
+/**
+ * struct hantro_hevc_dec_ctrls
+ * @decode_params: Decode params
+ * @sps:	SPS info
+ * @pps:	PPS info
+ * @hevc_hdr_skip_length: the number of data (in bits) to skip in the
+ *			  slice segment header syntax after 'slice type'
+ *			  token
+ */
+struct hantro_hevc_dec_ctrls {
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
+	const struct v4l2_ctrl_hevc_sps *sps;
+	const struct v4l2_ctrl_hevc_pps *pps;
+	u32 hevc_hdr_skip_length;
+};
+
+/**
+ * struct hantro_hevc_dec_hw_ctx
+ * @tile_sizes:		Tile sizes buffer
+ * @tile_filter:	Tile vertical filter buffer
+ * @tile_sao:		Tile SAO buffer
+ * @tile_bsd:		Tile BSD control buffer
+ * @dpb:	DPB
+ * @reflists:	P/B0/B1 reflists
+ * @ctrls:	V4L2 controls attached to a run
+ */
+struct hantro_hevc_dec_hw_ctx {
+	struct hantro_aux_buf tile_sizes;
+	struct hantro_aux_buf tile_filter;
+	struct hantro_aux_buf tile_sao;
+	struct hantro_aux_buf tile_bsd;
+	struct hantro_aux_buf ref_bufs[NUM_REF_PICTURES];
+	int ref_bufs_poc[NUM_REF_PICTURES];
+	u32 ref_bufs_used;
+	struct hantro_hevc_dec_ctrls ctrls;
+	unsigned int num_tile_cols_allocated;
+};
+
 /**
  * struct hantro_mpeg2_dec_hw_ctx
  *
@@ -190,6 +230,15 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
+int hantro_hevc_dec_init(struct hantro_ctx *ctx);
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx);
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx);
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx);
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, int poc);
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx);
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps);
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps);
+
 static inline size_t
 hantro_h264_mv_size(unsigned int width, unsigned int height)
 {
-- 
2.25.1



From benjamin.gaignard at collabora.com  Wed Apr  7 08:35:34 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Wed,  7 Apr 2021 09:35:34 +0200
Subject: [PATCH v9 13/13] arm64: dts: imx8mq: Add node to G2 hardware
In-Reply-To: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
Message-ID: <20210407073534.376722-14-benjamin.gaignard@collabora.com>

Split the VPU node in two: one for G1 and one for G2 since they are
different hardware blocks.
Add syscon for the hardware control block.
Remove the reg-names property that is useless.
Each VPU node only needs one interrupt.
Change G2 assigned clock to match the specification.
In both nodes all the clocks need to be assigned to make
sure that the control block will be correctly clocked even if
only one device node is enabled.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 9:
 - Corrections in commit message

version 7:
 - use nxp,imx8m-vpu-ctrl as phandle syscon property name

version 5:
 - use syscon instead of VPU reset

 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 43 ++++++++++++++++++-----
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 17c449e12c2e..65158414d255 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1329,15 +1329,16 @@ usb3_phy1: usb-phy at 382f0040 {
 			status = "disabled";
 		};
 
-		vpu: video-codec at 38300000 {
+		vpu_ctrl: syscon at 38320000 {
+			compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
+			reg = <0x38320000 0x10000>;
+		};
+
+		vpu_g1: video-codec at 38300000 {
 			compatible = "nxp,imx8mq-vpu";
-			reg = <0x38300000 0x10000>,
-			      <0x38310000 0x10000>,
-			      <0x38320000 0x10000>;
-			reg-names = "g1", "g2", "ctrl";
-			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
-				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
-			interrupt-names = "g1", "g2";
+			reg = <0x38300000 0x10000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "g1";
 			clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
 				 <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
 				 <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
@@ -1350,9 +1351,33 @@ vpu: video-codec at 38300000 {
 						 <&clk IMX8MQ_VPU_PLL_OUT>,
 						 <&clk IMX8MQ_SYS1_PLL_800M>,
 						 <&clk IMX8MQ_VPU_PLL>;
-			assigned-clock-rates = <600000000>, <600000000>,
+			assigned-clock-rates = <600000000>, <300000000>,
+					       <800000000>, <0>;
+			power-domains = <&pgc_vpu>;
+			nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
+		};
+
+		vpu_g2: video-codec at 38310000 {
+			compatible = "nxp,imx8mq-vpu-g2";
+			reg = <0x38310000 0x10000>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "g2";
+			clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
+				 <&clk IMX8MQ_CLK_VPU_G2_ROOT>,
+				 <&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
+			clock-names = "g1", "g2",  "bus";
+			assigned-clocks = <&clk IMX8MQ_CLK_VPU_G1>,
+					  <&clk IMX8MQ_CLK_VPU_G2>,
+					  <&clk IMX8MQ_CLK_VPU_BUS>,
+					  <&clk IMX8MQ_VPU_PLL_BYPASS>;
+			assigned-clock-parents = <&clk IMX8MQ_VPU_PLL_OUT>,
+						 <&clk IMX8MQ_VPU_PLL_OUT>,
+						 <&clk IMX8MQ_SYS1_PLL_800M>,
+						 <&clk IMX8MQ_VPU_PLL>;
+			assigned-clock-rates = <600000000>, <300000000>,
 					       <800000000>, <0>;
 			power-domains = <&pgc_vpu>;
+			nxp,imx8m-vpu-ctrl = <&vpu_ctrl>;
 		};
 
 		pcie0: pcie at 33800000 {
-- 
2.25.1



From mchehab+huawei at kernel.org  Wed Apr  7 09:20:39 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed,  7 Apr 2021 10:20:39 +0200
Subject: [PATCH v2 00/19] Fix broken documentation file references
Message-ID: <cover.1617783062.git.mchehab+huawei@kernel.org>

Hi Jon,

As files keep being moved around and DT bindings are 
converted and renamed to yaml, their doc references get 
outdated, pointing to an invalid places.

This series address those. It is based on the top of docs-next tree,
and most patches here are independent from the other ones.

v2:
  - Dropped patches that were already applied, Most of those
    will be following via Jonathan Cameron's iio tree;
  - Dropped patches that don't apply on the top of docs next.
  - Added some new patches fixing other breakages.

PS.:  
  I placed the dropped patches on a separate branch. I'll track 
  them and re-submit any missing ones after -rc1.

Mauro Carvalho Chehab (19):
  MAINTAINERS: update ste,mcde.yaml reference
  MAINTAINERS: update brcm,bcm-v3d.yaml reference
  MAINTAINERS: update fsl,dpaa2-console.yaml reference
  MAINTAINERS: update mtk-sd.yaml reference
  MAINTAINERS: update snps,dw-axi-dmac.yaml reference
  dt-bindings: don't use ../dir for doc references
  dt-bindings: fix references for iio-bindings.txt
  dt-bindings: iommu: mediatek: update mediatek,iommu.yaml references
  dt-bindings: i3c: update i3c.yaml references
  dt-bindings:iio:adc: update motorola,cpcap-adc.yaml reference
  dt-bindings:iio:adc: update dlg,da9150-gpadc.yaml reference
  dt-bindings: power: supply: da9150: update da9150-charger.txt
    reference
  dt-bindings: power: supply: da9150: update da9150-fg.txt reference
  docs: update sysfs-platform_profile.rst reference
  docs: update rcu_dereference.rst reference
  docs: vcpu-requests.rst: fix reference for atomic ops
  docs: replace transation references for reporting-bugs.rst
  docs: translations/zh_CN: fix a typo at 8.Conclusion.rst
  docs: sched-bwc.rst: fix a typo on a doc name

 .../bindings/display/mediatek/mediatek,disp.txt  |  2 +-
 .../devicetree/bindings/hwmon/ntc_thermistor.txt |  2 +-
 .../devicetree/bindings/i3c/cdns,i3c-master.txt  |  6 +++---
 .../bindings/i3c/snps,dw-i3c-master.txt          |  6 +++---
 .../devicetree/bindings/iio/adc/ingenic,adc.yaml |  5 +++--
 .../devicetree/bindings/input/adc-joystick.yaml  |  4 +++-
 .../input/touchscreen/resistive-adc-touch.txt    |  5 ++++-
 .../bindings/media/mediatek-jpeg-decoder.txt     |  2 +-
 .../bindings/media/mediatek-jpeg-encoder.txt     |  2 +-
 .../devicetree/bindings/media/mediatek-mdp.txt   |  2 +-
 .../bindings/media/mediatek-vcodec.txt           |  2 +-
 Documentation/devicetree/bindings/mfd/ab8500.txt |  4 +++-
 Documentation/devicetree/bindings/mfd/da9150.txt |  8 ++++----
 .../devicetree/bindings/mfd/motorola-cpcap.txt   | 16 ++++++++--------
 .../bindings/power/supply/da9150-charger.txt     |  2 +-
 Documentation/scheduler/sched-bwc.rst            |  2 +-
 .../translations/it_IT/process/howto.rst         |  2 +-
 Documentation/translations/ja_JP/howto.rst       |  2 +-
 Documentation/translations/zh_CN/SecurityBugs    |  2 +-
 .../zh_CN/admin-guide/reporting-issues.rst       |  4 ++--
 .../translations/zh_CN/process/8.Conclusion.rst  |  2 +-
 .../translations/zh_CN/process/howto.rst         |  2 +-
 Documentation/virt/kvm/vcpu-requests.rst         |  2 +-
 MAINTAINERS                                      | 10 +++++-----
 include/linux/platform_profile.h                 |  2 +-
 tools/memory-model/Documentation/glossary.txt    |  2 +-
 26 files changed, 54 insertions(+), 46 deletions(-)

-- 
2.30.2




From mchehab+huawei at kernel.org  Wed Apr  7 09:20:47 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed,  7 Apr 2021 10:20:47 +0200
Subject: [PATCH v2 08/19] dt-bindings: iommu: mediatek: update mediatek,
 iommu.yaml references
In-Reply-To: <cover.1617783062.git.mchehab+huawei@kernel.org>
References: <cover.1617783062.git.mchehab+huawei@kernel.org>
Message-ID: <8776972e59432915779acc5bd62d515e5532b612.1617783062.git.mchehab+huawei@kernel.org>

Changeset bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
renamed: Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
to: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml.

Update the cross-references accordingly.

Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 .../devicetree/bindings/display/mediatek/mediatek,disp.txt      | 2 +-
 .../devicetree/bindings/media/mediatek-jpeg-decoder.txt         | 2 +-
 .../devicetree/bindings/media/mediatek-jpeg-encoder.txt         | 2 +-
 Documentation/devicetree/bindings/media/mediatek-mdp.txt        | 2 +-
 Documentation/devicetree/bindings/media/mediatek-vcodec.txt     | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 93b160df3eec..fbb59c9ddda6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -64,7 +64,7 @@ Required properties (DMA function blocks):
 - larb: Should contain a phandle pointing to the local arbiter device as defined
   in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
 - iommus: Should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Optional properties (RDMA function blocks):
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index cf60c5acc0e4..39c1028b2dfb 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -19,7 +19,7 @@ Required properties:
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
   for details.
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
index acfb50375b8a..5e53c6ab52d0 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -17,7 +17,7 @@ Required properties:
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
   for details.
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 
 Example:
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index f4798d04e925..caa24943da33 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -25,7 +25,7 @@ Required properties (DMA function blocks, child node):
         "mediatek,mt8173-mdp-wdma"
         "mediatek,mt8173-mdp-wrot"
 - iommus: should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 - mediatek,larb: must contain the local arbiters in the current Socs, see
   Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8217424fd4bd..a83ebc1a1c7f 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -18,7 +18,7 @@ Required properties:
   "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
   "venc_lt_sel", "vdec_bus_clk_src".
 - iommus : should point to the respective IOMMU block with master port as
-  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
 One of the two following nodes:
 - mediatek,vpu : the node of the video processor unit, if using VPU.
-- 
2.30.2



From joro at 8bytes.org  Wed Apr  7 09:34:30 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Wed, 7 Apr 2021 10:34:30 +0200
Subject: [PATCH v2 1/2] iommu/mediatek-v1: Allow building as module
In-Reply-To: <20210326032337.24578-1-yong.wu@mediatek.com>
References: <20210326032337.24578-1-yong.wu@mediatek.com>
Message-ID: <YG1ulkL15n2MiE7E@8bytes.org>

On Fri, Mar 26, 2021 at 11:23:36AM +0800, Yong Wu wrote:
> This patch only adds support for building the IOMMU-v1 driver as module.
> Correspondingly switch the config to tristate and update the iommu_ops's
> owner to THIS_MODULE.
> 
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>

Applied both, thanks.


From nsaenzjulienne at suse.de  Wed Apr  7 09:44:39 2021
From: nsaenzjulienne at suse.de (Nicolas Saenz Julienne)
Date: Wed, 07 Apr 2021 10:44:39 +0200
Subject: [PATCH 2/3] mmc: sdhci-iproc: Cap min clock frequency on BCM2711
In-Reply-To: <2d40b062-5809-15ce-b9d1-651644ff6e22@i2se.com>
References: <20210406104802.20898-1-nsaenz@kernel.org>
 <20210406104802.20898-3-nsaenz@kernel.org>
 <2d40b062-5809-15ce-b9d1-651644ff6e22@i2se.com>
Message-ID: <25e9fc3bedd8f97dd151b1f36d752f032c6ec628.camel@suse.de>

On Tue, 2021-04-06 at 19:59 +0200, Stefan Wahren wrote:
> Hi Nicolas,
> 
> Am 06.04.21 um 12:48 schrieb Nicolas Saenz Julienne:
> > There is a known bug on BCM2711's SDHCI core integration where the
> > controller will hang when the difference between the core clock and the
> > bus clock is too great. Specifically this can be reproduced under the
> > following conditions:
> > 
> > - No SD card plugged in, polling thread is running, probing cards at
> > ??100KHz.
> > - BCM2711's core clock configured at 500MHz or more.
> > 
> > So set 200MHz as the minimum clock frequency available for that board.
> i think it should be 200 kHz?

Of course... Sorry for that.

Regards,
Nicolas

> > 
> > For more information on the issue see this:
> > https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsaenz at kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca
> > 
> > Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
> > Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> > ---
> > ?drivers/mmc/host/sdhci-iproc.c | 18 ++++++++++++++++++
> > ?1 file changed, 18 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> > index ddeaf8e1f72f..1ef888e91f73 100644
> > --- a/drivers/mmc/host/sdhci-iproc.c
> > +++ b/drivers/mmc/host/sdhci-iproc.c
> > @@ -173,6 +173,23 @@ static unsigned int sdhci_iproc_get_max_clock(struct sdhci_host *host)
> > ?		return pltfm_host->clock;
> > ?}
> > ?
> > 
> > +/*
> > + * There is a known bug on BCM2711's SDHCI core integration where the
> > + * controller will hang when the difference between the core clock and the bus
> > + * clock is too great. Specifically this can be reproduced under the following
> > + * conditions:
> > + *
> > + *  - No SD card plugged in, polling thread is running, probing cards at
> > + *    100KHz.
> > + *  - BCM2711's core clock configured at 500MHz or more
> > + *
> > + * So we set 200MHz as the minimum clock frequency available for that SoC.
> > + */
> > +static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host *host)
> > +{
> > +	return 200000;
> > +}
> > +
> > ?static const struct sdhci_ops sdhci_iproc_ops = {
> > ?	.set_clock = sdhci_set_clock,
> > ?	.get_max_clock = sdhci_iproc_get_max_clock,
> > @@ -271,6 +288,7 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
> > ?	.set_clock = sdhci_set_clock,
> > ?	.set_power = sdhci_set_power_and_bus_voltage,
> > ?	.get_max_clock = sdhci_iproc_get_max_clock,
> > +	.get_min_clock = sdhci_iproc_bcm2711_get_min_clock,
> > ?	.set_bus_width = sdhci_set_bus_width,
> > ?	.reset = sdhci_reset,
> > ?	.set_uhs_signaling = sdhci_set_uhs_signaling,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210407/d68c3ef7/attachment-0001.sig>

From yuzenghui at huawei.com  Wed Apr  7 09:44:48 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Wed, 7 Apr 2021 16:44:48 +0800
Subject: [PATCH] iommu/arm-smmu-v3: Remove the unused fields for
 PREFETCH_CONFIG command
Message-ID: <20210407084448.1838-1-yuzenghui@huawei.com>

Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
command and they're not used by the driver. Remove them.

We can add them back if we're going to use PREFETCH_ADDR in the future.

Signed-off-by: Zenghui Yu <yuzenghui at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 --
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 --
 2 files changed, 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 8594b4a83043..610c9f4b7789 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -245,8 +245,6 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct arm_smmu_cmdq_ent *ent)
 		break;
 	case CMDQ_OP_PREFETCH_CFG:
 		cmd[0] |= FIELD_PREP(CMDQ_PREFETCH_0_SID, ent->prefetch.sid);
-		cmd[1] |= FIELD_PREP(CMDQ_PREFETCH_1_SIZE, ent->prefetch.size);
-		cmd[1] |= ent->prefetch.addr & CMDQ_PREFETCH_1_ADDR_MASK;
 		break;
 	case CMDQ_OP_CFGI_CD:
 		cmd[0] |= FIELD_PREP(CMDQ_CFGI_0_SSID, ent->cfgi.ssid);
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 f985817c967a..83726b6a1cba 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -410,8 +410,6 @@ struct arm_smmu_cmdq_ent {
 		#define CMDQ_OP_PREFETCH_CFG	0x1
 		struct {
 			u32			sid;
-			u8			size;
-			u64			addr;
 		} prefetch;
 
 		#define CMDQ_OP_CFGI_STE	0x3
-- 
2.19.1



From michael.kao at mediatek.com  Wed Apr  7 09:49:14 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Wed, 7 Apr 2021 16:49:14 +0800
Subject: [v7, 3/3] thermal: mediatek: add another get_temp ops for
 thermal sensors
In-Reply-To: <20210316070144.28440-4-michael.kao@mediatek.com>
References: <20210316070144.28440-1-michael.kao@mediatek.com>
 <20210316070144.28440-4-michael.kao@mediatek.com>
Message-ID: <1617785354.12846.0.camel@mtksdccf07>

Hi Maintainers,

Gentle pin for this patch.

Thanks

On Tue, 2021-03-16 at 15:01 +0800, Michael Kao wrote:
> Provide thermal zone to read thermal sensor
> in the SoC. We can read all the thermal sensors
> value in the SoC by the node /sys/class/thermal/
> 
> In mtk_thermal_bank_temperature, return -EAGAIN instead of -EACCESS
> on the first read of sensor that often are bogus values.
> This can avoid following warning on boot:
> 
>   thermal thermal_zone6: failed to read out thermal zone (-13)
> 
> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/thermal/mtk_thermal.c | 100 +++++++++++++++++++++++++---------
>  1 file changed, 75 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 149c6d7fd5a0..57e4f08a947e 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -245,6 +245,11 @@ enum mtk_thermal_version {
>  
>  struct mtk_thermal;
>  
> +struct mtk_thermal_zone {
> +	struct mtk_thermal *mt;
> +	int id;
> +};
> +
>  struct thermal_bank_cfg {
>  	unsigned int num_sensors;
>  	const int *sensors;
> @@ -637,6 +642,30 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>  		mutex_unlock(&mt->lock);
>  }
>  
> +static u32 _get_sensor_temp(struct mtk_thermal *mt, int id)
> +{
> +	u32 raw;
> +	int temp;
> +
> +	raw = readl(mt->thermal_base + mt->conf->msr[id]);
> +
> +	if (mt->conf->version == MTK_THERMAL_V1)
> +		temp = raw_to_mcelsius_v1(mt, id, raw);
> +	else
> +		temp = raw_to_mcelsius_v2(mt, id, raw);
> +
> +	/*
> +	 * The first read of a sensor often contains very high bogus
> +	 * temperature value. Filter these out so that the system does
> +	 * not immediately shut down.
> +	 */
> +
> +	if (temp > 200000)
> +		return -EAGAIN;
> +	else
> +		return temp;
> +}
> +
>  /**
>   * mtk_thermal_bank_temperature - get the temperature of a bank
>   * @bank:	The bank
> @@ -647,28 +676,11 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>  static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>  {
>  	struct mtk_thermal *mt = bank->mt;
> -	const struct mtk_thermal_data *conf = mt->conf;
>  	int i, temp = INT_MIN, max = INT_MIN;
> -	u32 raw;
> -
> -	for (i = 0; i < conf->bank_data[bank->id].num_sensors; i++) {
> -		raw = readl(mt->thermal_base + conf->msr[i]);
>  
> -		if (mt->conf->version == MTK_THERMAL_V1) {
> -			temp = raw_to_mcelsius_v1(
> -				mt, conf->bank_data[bank->id].sensors[i], raw);
> -		} else {
> -			temp = raw_to_mcelsius_v2(
> -				mt, conf->bank_data[bank->id].sensors[i], raw);
> -		}
> +	for (i = 0; i < mt->conf->bank_data[bank->id].num_sensors; i++) {
>  
> -		/*
> -		 * The first read of a sensor often contains very high bogus
> -		 * temperature value. Filter these out so that the system does
> -		 * not immediately shut down.
> -		 */
> -		if (temp > 200000)
> -			temp = 0;
> +		temp = _get_sensor_temp(mt, i);
>  
>  		if (temp > max)
>  			max = temp;
> @@ -679,7 +691,8 @@ static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>  
>  static int mtk_read_temp(void *data, int *temperature)
>  {
> -	struct mtk_thermal *mt = data;
> +	struct mtk_thermal_zone *tz = data;
> +	struct mtk_thermal *mt = tz->mt;
>  	int i;
>  	int tempmax = INT_MIN;
>  
> @@ -698,10 +711,28 @@ static int mtk_read_temp(void *data, int *temperature)
>  	return 0;
>  }
>  
> +static int mtk_read_sensor_temp(void *data, int *temperature)
> +{
> +	struct mtk_thermal_zone *tz = data;
> +	struct mtk_thermal *mt = tz->mt;
> +	int id = tz->id - 1;
> +
> +	if (id < 0)
> +		return -EACCES;
> +
> +	*temperature = _get_sensor_temp(mt, id);
> +
> +	return 0;
> +}
> +
>  static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
>  	.get_temp = mtk_read_temp,
>  };
>  
> +static const struct thermal_zone_of_device_ops mtk_thermal_sensor_ops = {
> +	.get_temp = mtk_read_sensor_temp,
> +};
> +
>  static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>  				  u32 apmixed_phys_base, u32 auxadc_phys_base,
>  				  int ctrl_id)
> @@ -992,6 +1023,7 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  	u64 auxadc_phys_base, apmixed_phys_base;
>  	struct thermal_zone_device *tzdev;
>  	void __iomem *apmixed_base, *auxadc_base;
> +	struct mtk_thermal_zone *tz;
>  
>  	mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
>  	if (!mt)
> @@ -1080,11 +1112,29 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, mt);
>  
> -	tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, mt,
> -						     &mtk_thermal_ops);
> -	if (IS_ERR(tzdev)) {
> -		ret = PTR_ERR(tzdev);
> -		goto err_disable_clk_peri_therm;
> +	for (i = 0; i < mt->conf->num_sensors + 1; i++) {
> +		tz = devm_kmalloc(&pdev->dev, sizeof(*tz), GFP_KERNEL);
> +		if (!tz)
> +			return -ENOMEM;
> +
> +		tz->mt = mt;
> +		tz->id = i;
> +
> +		tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, i, tz, (i == 0) ?
> +							     &mtk_thermal_ops :
> +							     &mtk_thermal_sensor_ops);
> +
> +		if (IS_ERR(tzdev)) {
> +			if (PTR_ERR(tzdev) == -ENODEV) {
> +				dev_warn(&pdev->dev,
> +					 "sensor %d not registered in thermal zone in dt\n", i);
> +				continue;
> +			}
> +			if (PTR_ERR(tzdev) == -EACCES) {
> +				ret = PTR_ERR(tzdev);
> +				goto err_disable_clk_peri_therm;
> +			}
> +		}
>  	}
>  
>  	return 0;


From joro at 8bytes.org  Wed Apr  7 09:55:07 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Wed, 7 Apr 2021 10:55:07 +0200
Subject: [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
In-Reply-To: <20210401154718.307519-1-jean-philippe@linaro.org>
References: <20210401154718.307519-1-jean-philippe@linaro.org>
Message-ID: <YG1za3CYd/Y2JAB3@8bytes.org>

On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote:
> Jean-Philippe Brucker (10):
>   iommu: Fix comment for struct iommu_fwspec
>   iommu/arm-smmu-v3: Use device properties for pasid-num-bits
>   iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
>   iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF
>   uacce: Enable IOMMU_DEV_FEAT_IOPF
>   iommu: Add a page fault handler
>   iommu/arm-smmu-v3: Maintain a SID->device structure

Applied the first 7 patches, thanks.


From joro at 8bytes.org  Wed Apr  7 09:57:19 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Wed, 7 Apr 2021 10:57:19 +0200
Subject: cleanup unused or almost unused IOMMU APIs and the FSL PAMU
 driver v3
In-Reply-To: <20210401155256.298656-1-hch@lst.de>
References: <20210401155256.298656-1-hch@lst.de>
Message-ID: <YG1z7/b0i8WYOMHA@8bytes.org>

On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote:
> Diffstat:
>  arch/powerpc/include/asm/fsl_pamu_stash.h   |   12 
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c     |    5 
>  drivers/iommu/amd/iommu.c                   |   23 
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   75 ---
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |    1 
>  drivers/iommu/arm/arm-smmu/arm-smmu.c       |  111 +---
>  drivers/iommu/arm/arm-smmu/arm-smmu.h       |    2 
>  drivers/iommu/dma-iommu.c                   |    9 
>  drivers/iommu/fsl_pamu.c                    |  293 -----------
>  drivers/iommu/fsl_pamu.h                    |   12 
>  drivers/iommu/fsl_pamu_domain.c             |  688 ++--------------------------
>  drivers/iommu/fsl_pamu_domain.h             |   46 -
>  drivers/iommu/intel/iommu.c                 |   95 ---
>  drivers/iommu/iommu.c                       |  118 +---
>  drivers/soc/fsl/qbman/qman_portal.c         |   55 --
>  drivers/vfio/vfio_iommu_type1.c             |   31 -
>  drivers/vhost/vdpa.c                        |   10 
>  include/linux/io-pgtable.h                  |    4 
>  include/linux/iommu.h                       |   76 ---
>  19 files changed, 203 insertions(+), 1463 deletions(-)

Applied, thanks.


From mason.zhang at mediatek.com  Wed Apr  7 09:49:56 2021
From: mason.zhang at mediatek.com (Mason Zhang)
Date: Wed, 7 Apr 2021 16:49:56 +0800
Subject: [PATCH 1/2] arm64: dts: mediatek: add MT6779 spi master dts node
In-Reply-To: <d3666864-cb46-755c-0d0d-d05ac9af0379@gmail.com>
References: <20210226105918.3057-1-Mason.Zhang@mediatek.com>
 <d3666864-cb46-755c-0d0d-d05ac9af0379@gmail.com>
Message-ID: <1617785396.21900.5.camel@mbjsdccf07>

On Mon, 2021-03-29 at 17:50 +0200, Matthias Brugger wrote:

> Please also update binding description accordingling and add as another patch. I
> wasn't able to find a 2/2 neither. I foudn v1 2/2 which on a quick look seemed
> the same as this patch.

Dear Matthias:

patch 2/2 in this link and this patch has been merged:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210226110109.30500-1-Mason.Zhang at mediatek.com/

so, Please gentle ping on patch 1/2. Thank you~

Thanks
Mason

From michael.kao at mediatek.com  Wed Apr  7 10:08:25 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Wed, 7 Apr 2021 17:08:25 +0800
Subject: [v3,1/3] thermal: mediatek: Relocate driver to mediatek folder
In-Reply-To: <20210312034018.17437-2-michael.kao@mediatek.com>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-2-michael.kao@mediatek.com>
Message-ID: <1617786505.12846.1.camel@mtksdccf07>

Hi Maintainers,
 
Gentle pin for this patch.
 
Thanks


On Fri, 2021-03-12 at 11:40 +0800, Michael Kao wrote:
> Add Mediatek proprietary folder to upstream more thermal zone and cooler
> drivers. Relocate the original thermal controller driver to it and rename
> as soc_temp.c to show its purpose more clearly.
> 
> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> ---
>  drivers/thermal/Kconfig                       | 14 ++++-------
>  drivers/thermal/Makefile                      |  2 +-
>  drivers/thermal/mediatek/Kconfig              | 23 +++++++++++++++++++
>  drivers/thermal/mediatek/Makefile             |  1 +
>  .../{mtk_thermal.c => mediatek/soc_temp.c}    |  0
>  5 files changed, 29 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/thermal/mediatek/Kconfig
>  create mode 100644 drivers/thermal/mediatek/Makefile
>  rename drivers/thermal/{mtk_thermal.c => mediatek/soc_temp.c} (100%)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 7edc8dc6bbab..b2da0a1bda34 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -401,16 +401,10 @@ config DA9062_THERMAL
>  	  zone.
>  	  Compatible with the DA9062 and DA9061 PMICs.
>  
> -config MTK_THERMAL
> -	tristate "Temperature sensor driver for mediatek SoCs"
> -	depends on ARCH_MEDIATEK || COMPILE_TEST
> -	depends on HAS_IOMEM
> -	depends on NVMEM || NVMEM=n
> -	depends on RESET_CONTROLLER
> -	default y
> -	help
> -	  Enable this option if you want to have support for thermal management
> -	  controller present in Mediatek SoCs
> +menu "Mediatek thermal drivers"
> +depends on ARCH_MEDIATEK || COMPILE_TEST
> +source "drivers/thermal/mediatek/Kconfig"
> +endmenu
>  
>  config AMLOGIC_THERMAL
>  	tristate "Amlogic Thermal Support"
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index b64dd50a6629..f9e07c3f529e 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -55,7 +55,7 @@ obj-y				+= st/
>  obj-$(CONFIG_QCOM_TSENS)	+= qcom/
>  obj-y				+= tegra/
>  obj-$(CONFIG_HISI_THERMAL)     += hisi_thermal.o
> -obj-$(CONFIG_MTK_THERMAL)	+= mtk_thermal.o
> +obj-$(CONFIG_MTK_THERMAL)	+= mediatek/
>  obj-$(CONFIG_GENERIC_ADC_THERMAL)	+= thermal-generic-adc.o
>  obj-$(CONFIG_ZX2967_THERMAL)	+= zx2967_thermal.o
>  obj-$(CONFIG_UNIPHIER_THERMAL)	+= uniphier_thermal.o
> diff --git a/drivers/thermal/mediatek/Kconfig b/drivers/thermal/mediatek/Kconfig
> new file mode 100644
> index 000000000000..0351e73170b7
> --- /dev/null
> +++ b/drivers/thermal/mediatek/Kconfig
> @@ -0,0 +1,23 @@
> +config MTK_THERMAL
> +	tristate "Mediatek thermal drivers"
> +	depends on THERMAL_OF
> +	help
> +	  This is the option for Mediatek thermal software
> +	  solutions. Please enable corresponding options to
> +	  get temperature information from thermal sensors or
> +	  turn on throttle mechaisms for thermal mitigation.
> +
> +if MTK_THERMAL
> +
> +config MTK_SOC_THERMAL
> +	tristate "Temperature sensor driver for mediatek SoCs"
> +	depends on HAS_IOMEM
> +	depends on NVMEM
> +	depends on RESET_CONTROLLER
> +	help
> +	  Enable this option if you want to get SoC temperature
> +	  information for Mediatek platforms. This driver
> +	  configures thermal controllers to collect temperature
> +	  via AUXADC interface.
> +
> +endif
> diff --git a/drivers/thermal/mediatek/Makefile b/drivers/thermal/mediatek/Makefile
> new file mode 100644
> index 000000000000..f75313ddce5e
> --- /dev/null
> +++ b/drivers/thermal/mediatek/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_MTK_SOC_THERMAL)	+= soc_temp.o
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mediatek/soc_temp.c
> similarity index 100%
> rename from drivers/thermal/mtk_thermal.c
> rename to drivers/thermal/mediatek/soc_temp.c


From michael.kao at mediatek.com  Wed Apr  7 10:09:06 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Wed, 7 Apr 2021 17:09:06 +0800
Subject: [v3,2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones
In-Reply-To: <20210312034018.17437-3-michael.kao@mediatek.com>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-3-michael.kao@mediatek.com>
Message-ID: <1617786546.12846.2.camel@mtksdccf07>

Hi Maintainers,
 
Gentle pin for this patch.
 
Thanks


On Fri, 2021-03-12 at 11:40 +0800, Michael Kao wrote:
> Add a LVTS (Low voltage thermal sensor) driver to report junction
> temperatures in Mediatek SoC and register the maximum temperature
> of sensors and each sensor as a thermal zone.
> 
> Signed-off-by: Yu-Chia Chang <ethan.chang at mediatek.com>
> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> ---
>  drivers/thermal/mediatek/Kconfig         |   10 +
>  drivers/thermal/mediatek/Makefile        |    1 +
>  drivers/thermal/mediatek/soc_temp_lvts.c | 1287 ++++++++++++++++++++++
>  drivers/thermal/mediatek/soc_temp_lvts.h |  312 ++++++
>  4 files changed, 1610 insertions(+)
>  create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.c
>  create mode 100644 drivers/thermal/mediatek/soc_temp_lvts.h
> 
> diff --git a/drivers/thermal/mediatek/Kconfig b/drivers/thermal/mediatek/Kconfig
> index 0351e73170b7..d716d0372e1e 100644
> --- a/drivers/thermal/mediatek/Kconfig
> +++ b/drivers/thermal/mediatek/Kconfig
> @@ -20,4 +20,14 @@ config MTK_SOC_THERMAL
>  	  configures thermal controllers to collect temperature
>  	  via AUXADC interface.
>  
> +config MTK_SOC_THERMAL_LVTS
> +        tristate "LVTS (Low voltage thermal sensor) driver for Mediatek SoCs"
> +        depends on HAS_IOMEM
> +        depends on NVMEM
> +        depends on RESET_TI_SYSCON
> +        help
> +          Enable this option if you want to get SoC temperature
> +          information for Mediatek platforms. This driver
> +          configures LVTS thermal controllers to collect temperatures
> +          via Analog Serial Interface(ASIF).
>  endif
> diff --git a/drivers/thermal/mediatek/Makefile b/drivers/thermal/mediatek/Makefile
> index f75313ddce5e..16ce166e5916 100644
> --- a/drivers/thermal/mediatek/Makefile
> +++ b/drivers/thermal/mediatek/Makefile
> @@ -1 +1,2 @@
>  obj-$(CONFIG_MTK_SOC_THERMAL)	+= soc_temp.o
> +obj-$(CONFIG_MTK_SOC_THERMAL_LVTS)	+= soc_temp_lvts.o
> diff --git a/drivers/thermal/mediatek/soc_temp_lvts.c b/drivers/thermal/mediatek/soc_temp_lvts.c
> new file mode 100644
> index 000000000000..8153edaaf815
> --- /dev/null
> +++ b/drivers/thermal/mediatek/soc_temp_lvts.c
> @@ -0,0 +1,1287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/nvmem-consumer.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/thermal.h>
> +#include "soc_temp_lvts.h"
> +
> +/*==================================================
> + * Definition or macro function
> + *==================================================
> + */
> +#define STOP_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x00)
> +#define SET_RG_TSFM_LPDLY_V4 (DEVICE_WRITE | RG_TSFM_CTRL_4 << 8 | 0xA6)
> +#define SET_COUNTING_WINDOW_20US1_V4 (DEVICE_WRITE | RG_TSFM_CTRL_2 << 8 | 0x00)
> +#define SET_COUNTING_WINDOW_20US2_V4 (DEVICE_WRITE | RG_TSFM_CTRL_1 << 8 | 0x20)
> +#define TSV2F_CHOP_CKSEL_AND_TSV2F_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_2 << 8 | 0x84)
> +#define TSBG_DEM_CKSEL_X_TSBG_CHOP_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_4 << 8 | 0x7C)
> +#define SET_TS_RSV_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_1 << 8 | 0x8D)
> +#define SET_TS_EN_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 | 0xF4)
> +#define TOGGLE_RG_TSV2F_VCO_RST1_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 | 0xFC)
> +#define TOGGLE_RG_TSV2F_VCO_RST2_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_0 << 8 | 0xF4)
> +
> +#define SET_LVTS_AUTO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_6 << 8 | 0x01)
> +#define SELECT_SENSOR_RCK_V4(id) (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | (id))
> +#define SET_DEVICE_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3 << 8 | 0x78)
> +#define KICK_OFF_RCK_COUNTING_V4 (DEVICE_WRITE | RG_TSFM_CTRL_0 << 8 | 0x02)
> +#define SET_SENSOR_NO_RCK_V4 (DEVICE_WRITE | RG_TSV2F_CTRL_5 << 8 | 0x10)
> +#define SET_DEVICE_LOW_POWER_SINGLE_MODE_V4 (DEVICE_WRITE | RG_TSFM_CTRL_3 << 8	| 0xB8)
> +
> +#define ENABLE_FEATURE(feature)		(lvts_data->feature_bitmap |= (feature))
> +#define DISABLE_FEATURE(feature)	(lvts_data->feature_bitmap &= (~(feature)))
> +#define IS_ENABLE(feature)		(lvts_data->feature_bitmap & (feature))
> +
> +#define DISABLE_THERMAL_HW_REBOOT (-274000)
> +
> +#define CLOCK_26MHZ_CYCLE_NS	(38)
> +#define BUS_ACCESS_US		(2)
> +
> +#define FEATURE_DEVICE_AUTO_RCK	(BIT(0))
> +#define FEATURE_CK26M_ACTIVE	(BIT(1))
> +#define CK26M_ACTIVE   (((lvts_data->feature_bitmap & FEATURE_CK26M_ACTIVE)    \
> +			? 1 : 0) << 30)
> +#define GET_BASE_ADDR(tc_id)	\
> +	(lvts_data->domain[lvts_data->tc[tc_id].domain_index].base	\
> +	+ lvts_data->tc[tc_id].addr_offset)
> +
> +#define SET_TC_SPEED_IN_US(pu, gd, fd, sd) \
> +	{	\
> +		.period_unit = (((pu) * 1000) / (256 * CLOCK_26MHZ_CYCLE_NS)),	\
> +		.group_interval_delay = ((gd) / (pu)),	\
> +		.filter_interval_delay = ((fd) / (pu)),	\
> +		.sensor_interval_delay = ((sd) / (pu)),	\
> +	}
> +
> +#define GET_CAL_DATA_BITMASK(index, h, l)	\
> +	(((index) < lvts_data->num_efuse_addr)	\
> +	? ((lvts_data->efuse[(index)] & GENMASK(h, l)) >> l)	\
> +	: 0)
> +
> +#define GET_CAL_DATA_BIT(index, bit)	\
> +	(((index) < lvts_data->num_efuse_addr)	\
> +	? ((lvts_data->efuse[index] & BIT(bit)) >> (bit))	\
> +	: 0)
> +
> +#define GET_TC_SENSOR_NUM(tc_id)	\
> +	(lvts_data->tc[tc_id].num_sensor)
> +
> +#define ONE_SAMPLE (lvts_data->counting_window_us + 2 * BUS_ACCESS_US)
> +
> +#define NUM_OF_SAMPLE(tc_id)	\
> +	((lvts_data->tc[tc_id].hw_filter < LVTS_FILTER_2) ? 1 :	\
> +	((lvts_data->tc[tc_id].hw_filter > LVTS_FILTER_16_OF_18) ? 1 :	\
> +	((lvts_data->tc[tc_id].hw_filter == LVTS_FILTER_16_OF_18) ? 18 :\
> +	((lvts_data->tc[tc_id].hw_filter == LVTS_FILTER_8_OF_10) ? 10 :	\
> +	(lvts_data->tc[tc_id].hw_filter * 2)))))
> +
> +#define PERIOD_UNIT_US(tc_id)	\
> +	((lvts_data->tc[tc_id].tc_speed.period_unit * 256 *	\
> +	CLOCK_26MHZ_CYCLE_NS) / 1000)
> +#define FILTER_INT_US(tc_id)	\
> +	(lvts_data->tc[tc_id].tc_speed.filter_interval_delay	\
> +	* PERIOD_UNIT_US(tc_id))
> +#define SENSOR_INT_US(tc_id)	\
> +	(lvts_data->tc[tc_id].tc_speed.sensor_interval_delay	\
> +	* PERIOD_UNIT_US(tc_id))
> +#define GROUP_INT_US(tc_id)	\
> +	(lvts_data->tc[tc_id].tc_speed.group_interval_delay	\
> +	* PERIOD_UNIT_US(tc_id))
> +
> +#define SENSOR_LATENCY_US(tc_id) \
> +	((NUM_OF_SAMPLE(tc_id) - 1) * FILTER_INT_US(tc_id)	\
> +	+ NUM_OF_SAMPLE(tc_id) * ONE_SAMPLE)
> +
> +#define GROUP_LATENCY_US(tc_id)	\
> +	(GET_TC_SENSOR_NUM(tc_id) * SENSOR_LATENCY_US(tc_id)	\
> +	+ (GET_TC_SENSOR_NUM(tc_id) - 1) * SENSOR_INT_US(tc_id)	\
> +	+ GROUP_INT_US(tc_id))
> +
> +/*==================================================
> + * LVTS local common code
> + *==================================================
> + */
> +static int lvts_raw_to_temp(struct formula_coeff *co, unsigned int msr_raw)
> +{
> +	/* This function returns degree mC */
> +
> +	int temp;
> +
> +	temp = (co->a * ((unsigned long long)msr_raw)) >> 14;
> +	temp = temp + co->golden_temp * 500 + co->b;
> +
> +	return temp;
> +}
> +
> +static unsigned int lvts_temp_to_raw(struct formula_coeff *co, int temp)
> +{
> +	unsigned int msr_raw;
> +
> +	msr_raw = div_s64((s64)((co->golden_temp * 500 + co->b - temp)) << 14,
> +			 (-1 * co->a));
> +
> +	return msr_raw;
> +}
> +
> +static int lvts_read_all_tc_temperature(struct lvts_data *lvts_data)
> +{
> +	struct tc_settings *tc = lvts_data->tc;
> +	unsigned int i, j, s_index, msr_raw;
> +	int max_temp = 0, current_temp;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +		for (j = 0; j < tc[i].num_sensor; j++) {
> +			s_index = tc[i].sensor_map[j];
> +
> +			msr_raw = readl(LVTSMSR0_0 + base + 0x4 * j) & MRS_RAW_MASK;
> +			current_temp = lvts_raw_to_temp(&lvts_data->coeff, msr_raw);
> +
> +			if (msr_raw == 0)
> +				current_temp = THERMAL_TEMP_INVALID;
> +
> +			max_temp = max(max_temp, current_temp);
> +
> +			lvts_data->sen_data[s_index].msr_raw = msr_raw;
> +			lvts_data->sen_data[s_index].temp = current_temp;
> +		}
> +	}
> +
> +	return max_temp;
> +}
> +
> +static int soc_temp_lvts_read_temp(void *data, int *temperature)
> +{
> +	struct soc_temp_tz *lvts_tz = (struct soc_temp_tz *)data;
> +	struct lvts_data *lvts_data = lvts_tz->lvts_data;
> +
> +	if (lvts_tz->id == 0)
> +		*temperature = lvts_read_all_tc_temperature(lvts_data);
> +	else if (lvts_tz->id - 1 < lvts_data->num_sensor)
> +		*temperature = lvts_data->sen_data[lvts_tz->id - 1].temp;
> +	else
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops soc_temp_lvts_ops = {
> +	.get_temp = soc_temp_lvts_read_temp,
> +};
> +
> +static void lvts_write_device(struct lvts_data *lvts_data, unsigned int data,
> +			      int tc_id)
> +{
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +
> +	writel(data, LVTS_CONFIG_0 + base);
> +
> +	usleep_range(5, 15);
> +}
> +
> +static unsigned int lvts_read_device(struct lvts_data *lvts_data,
> +				     unsigned int reg_idx, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	void __iomem *base;
> +	unsigned int data;
> +	int ret;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +	writel(READ_DEVICE_REG(reg_idx), LVTS_CONFIG_0 + base);
> +
> +	ret = readl_poll_timeout(LVTS_CONFIG_0 + base, data,
> +				 !(data & DEVICE_ACCESS_STARTUS),
> +				 2, 200);
> +	if (ret)
> +		dev_err(dev,
> +			"Error: LVTS %d DEVICE_ACCESS_START didn't ready\n", tc_id);
> +
> +	data = readl(LVTSRDATA0_0 + base);
> +
> +	return data;
> +}
> +
> +static void wait_all_tc_sensing_point_idle(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int mask, error_code, is_error;
> +	void __iomem *base;
> +	int i, cnt, ret;
> +
> +	mask = BIT(10) | BIT(7) | BIT(0);
> +
> +	for (cnt = 0; cnt < 2; cnt++) {
> +		is_error = 0;
> +		for (i = 0; i < lvts_data->num_tc; i++) {
> +			base = GET_BASE_ADDR(i);
> +			ret = readl_poll_timeout(LVTSMSRCTL1_0 + base, error_code,
> +						 !(error_code & mask), 2, 200);
> +			/*
> +			 * Error code
> +			 * 000: IDLE
> +			 * 001: Write transaction
> +			 * 010: Waiting for read after Write
> +			 * 011: Disable Continue fetching on Device
> +			 * 100: Read transaction
> +			 * 101: Set Device special Register for Voltage threshold
> +			 * 111: Set TSMCU number for Fetch
> +			 */
> +			error_code = ((error_code & BIT(10)) >> 8) +
> +				((error_code & BIT(7)) >> 6) +
> +				(error_code & BIT(0));
> +
> +			if (ret)
> +				dev_err(dev,
> +					"Error LVTS %d sensing points aren't idle, error_code %d\n",
> +					i, error_code);
> +
> +			if (error_code != 0)
> +				is_error = 1;
> +		}
> +
> +		if (is_error == 0)
> +			break;
> +	}
> +}
> +
> +static void lvts_reset(struct lvts_data *lvts_data)
> +{
> +	int i;
> +
> +	for (i = 0; i < lvts_data->num_domain; i++) {
> +		if (lvts_data->domain[i].reset)
> +			reset_control_assert(lvts_data->domain[i].reset);
> +
> +		if (lvts_data->domain[i].reset)
> +			reset_control_deassert(lvts_data->domain[i].reset);
> +	}
> +}
> +
> +static void device_identification(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int i, data;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +
> +		writel(ENABLE_LVTS_CTRL_CLK, LVTSCLKEN_0 + base);
> +
> +		lvts_write_device(lvts_data, RESET_ALL_DEVICES, i);
> +
> +		lvts_write_device(lvts_data, READ_BACK_DEVICE_ID, i);
> +
> +		/* Check LVTS device ID */
> +		data = (readl(LVTS_ID_0 + base) & GENMASK(7, 0));
> +		if (data != (0x81 + i))
> +			dev_err(dev, "LVTS_TC_%d, Device ID should be 0x%x, but 0x%x\n",
> +				i, (0x81 + i), data);
> +	}
> +}
> +
> +static void disable_all_sensing_points(struct lvts_data *lvts_data)
> +{
> +	unsigned int i;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +		writel(DISABLE_SENSING_POINT, LVTSMONCTL0_0 + base);
> +	}
> +}
> +
> +static void enable_all_sensing_points(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	unsigned int i, num;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +		num = tc[i].num_sensor;
> +
> +		if (num > ALL_SENSING_POINTS) {
> +			dev_err(dev,
> +				"%s, LVTS%d, illegal number of sensors: %d\n",
> +				__func__, i, tc[i].num_sensor);
> +			continue;
> +		}
> +
> +		writel(ENABLE_SENSING_POINT(num), LVTSMONCTL0_0 + base);
> +	}
> +}
> +
> +static void set_polling_speed(struct lvts_data *lvts_data, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	unsigned int lvts_mon_ctl_1, lvts_mon_ctl_2;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +
> +	lvts_mon_ctl_1 = ((tc[tc_id].tc_speed.group_interval_delay << 20) & GENMASK(29, 20)) |
> +			(tc[tc_id].tc_speed.period_unit & GENMASK(9, 0));
> +	lvts_mon_ctl_2 = ((tc[tc_id].tc_speed.filter_interval_delay << 16) & GENMASK(25, 16)) |
> +			(tc[tc_id].tc_speed.sensor_interval_delay & GENMASK(9, 0));
> +	/*
> +	 * Clock source of LVTS thermal controller is 26MHz.
> +	 * Period unit is a base for all interval delays
> +	 * All interval delays must multiply it to convert a setting to time.
> +	 * Filter interval delay is a delay between two samples of the same sensor
> +	 * Sensor interval delay is a delay between two samples of differnet sensors
> +	 * Group interval delay is a delay between different rounds.
> +	 * For example:
> +	 *     If Period unit = C, filter delay = 1, sensor delay = 2, group delay = 1,
> +	 *     and two sensors, TS1 and TS2, are in a LVTS thermal controller
> +	 *     and then
> +	 *     Period unit = C * 1/26M * 256 = 12 * 38.46ns * 256 = 118.149us
> +	 *     Filter interval delay = 1 * Period unit = 118.149us
> +	 *     Sensor interval delay = 2 * Period unit = 236.298us
> +	 *     Group interval delay = 1 * Period unit = 118.149us
> +	 *
> +	 *     TS1    TS1 ... TS1    TS2    TS2 ... TS2    TS1...
> +	 *        <--> Filter interval delay
> +	 *                       <--> Sensor interval delay
> +	 *                                             <--> Group interval delay
> +	 */
> +	writel(lvts_mon_ctl_1, LVTSMONCTL1_0 + base);
> +	writel(lvts_mon_ctl_2, LVTSMONCTL2_0 + base);
> +
> +	dev_info(dev, "%s %d, LVTSMONCTL1_0= 0x%x,LVTSMONCTL2_0= 0x%x\n",
> +		 __func__, tc_id, readl(LVTSMONCTL1_0 + base),
> +		 readl(LVTSMONCTL2_0 + base));
> +}
> +
> +static void set_hw_filter(struct lvts_data *lvts_data, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	unsigned int option;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +	option = tc[tc_id].hw_filter & 0x7;
> +	/* hw filter
> +	 * 000: Get one sample
> +	 * 001: Get 2 samples and average them
> +	 * 010: Get 4 samples, drop max and min, then average the rest of 2 samples
> +	 * 011: Get 6 samples, drop max and min, then average the rest of 4 samples
> +	 * 100: Get 10 samples, drop max and min, then average the rest of 8 samples
> +	 * 101: Get 18 samples, drop max and min, then average the rest of 16 samples
> +	 */
> +	option = (option << 9) | (option << 6) | (option << 3) | option;
> +
> +	writel(option, LVTSMSRCTL0_0 + base);
> +	dev_info(dev, "%s %d, LVTSMSRCTL0_0= 0x%x\n",
> +		 __func__, tc_id, readl(LVTSMSRCTL0_0 + base));
> +}
> +
> +static int get_dominator_index(struct lvts_data *lvts_data, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	int d_index;
> +
> +	if (tc[tc_id].dominator_sensing_point == ALL_SENSING_POINTS) {
> +		d_index = ALL_SENSING_POINTS;
> +	} else if (tc[tc_id].dominator_sensing_point <
> +		tc[tc_id].num_sensor){
> +		d_index = tc[tc_id].dominator_sensing_point;
> +	} else {
> +		dev_err(dev,
> +			"Error: LVTS%d, dominator_sensing_point= %d should smaller than num_sensor= %d\n",
> +			tc_id, tc[tc_id].dominator_sensing_point,
> +			tc[tc_id].num_sensor);
> +
> +		dev_err(dev, "Use the sensing point 0 as the dominated sensor\n");
> +		d_index = SENSING_POINT0;
> +	}
> +
> +	return d_index;
> +}
> +
> +static void disable_hw_reboot_interrupt(struct lvts_data *lvts_data, int tc_id)
> +{
> +	unsigned int temp;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +
> +	/* LVTS thermal controller has two interrupts for thermal HW reboot
> +	 * One is for AP SW and the other is for RGU
> +	 * The interrupt of AP SW can turn off by a bit of a register, but
> +	 * the other for RGU cannot.
> +	 * To prevent rebooting device accidentally, we are going to add
> +	 * a huge offset to LVTS and make LVTS always report extremely low
> +	 * temperature.
> +	 */
> +
> +	/* After adding the huge offset 0x3FFF, LVTS alawys adds the
> +	 * offset to MSR_RAW.
> +	 * When MSR_RAW is larger, SW will convert lower temperature/
> +	 */
> +	temp = readl(LVTSPROTCTL_0 + base);
> +	writel(temp | 0x3FFF, LVTSPROTCTL_0 + base);
> +
> +	/* Disable the interrupt of AP SW */
> +	temp = readl(LVTSMONINT_0 + base);
> +	writel(temp & ~(STAGE3_INT_EN), LVTSMONINT_0 + base);
> +}
> +
> +static void enable_hw_reboot_interrupt(struct lvts_data *lvts_data, int tc_id)
> +{
> +	unsigned int temp;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +
> +	/* Enable the interrupt of AP SW */
> +	temp = readl(LVTSMONINT_0 + base);
> +	writel(temp | STAGE3_INT_EN, LVTSMONINT_0 + base);
> +	/* Clear the offset */
> +	temp = readl(LVTSPROTCTL_0 + base);
> +	writel(temp & ~PROTOFFSET, LVTSPROTCTL_0 + base);
> +}
> +
> +static void set_tc_hw_reboot_threshold(struct lvts_data *lvts_data,
> +				       int trip_point, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int msr_raw, temp, config, d_index;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +	d_index = get_dominator_index(lvts_data, tc_id);
> +
> +	dev_info(dev, "%s: LVTS%d, the dominator sensing point= %d\n",
> +		 __func__, tc_id, d_index);
> +
> +	disable_hw_reboot_interrupt(lvts_data, tc_id);
> +
> +	temp = readl(LVTSPROTCTL_0 + base);
> +	if (d_index == ALL_SENSING_POINTS) {
> +		/* Maximum of 4 sensing points */
> +		config = (0x1 << 16);
> +		writel(config | temp, LVTSPROTCTL_0 + base);
> +	} else {
> +		/* Select protection sensor */
> +		config = ((d_index << 2) + 0x2) << 16;
> +		writel(config | temp, LVTSPROTCTL_0 + base);
> +	}
> +
> +	msr_raw = lvts_temp_to_raw(&lvts_data->coeff, trip_point);
> +	writel(msr_raw, LVTSPROTTC_0 + base);
> +
> +	enable_hw_reboot_interrupt(lvts_data, tc_id);
> +}
> +
> +static void set_all_tc_hw_reboot(struct lvts_data *lvts_data)
> +{
> +	struct tc_settings *tc = lvts_data->tc;
> +	int i, trip_point;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		trip_point = tc[i].hw_reboot_trip_point;
> +
> +		if (tc[i].num_sensor == 0)
> +			continue;
> +
> +		if (trip_point == DISABLE_THERMAL_HW_REBOOT)
> +			continue;
> +
> +		set_tc_hw_reboot_threshold(lvts_data, trip_point, i);
> +	}
> +}
> +
> +static int lvts_init(struct lvts_data *lvts_data)
> +{
> +	struct platform_ops *ops = &lvts_data->ops;
> +	struct device *dev = lvts_data->dev;
> +	int ret;
> +
> +	ret = clk_prepare_enable(lvts_data->clk);
> +	if (ret) {
> +		dev_err(dev,
> +			"Error: Failed to enable lvts controller clock: %d\n",
> +			ret);
> +		return ret;
> +	}
> +
> +	lvts_reset(lvts_data);
> +
> +	device_identification(lvts_data);
> +	if (ops->device_enable_and_init)
> +		ops->device_enable_and_init(lvts_data);
> +
> +	if (IS_ENABLE(FEATURE_DEVICE_AUTO_RCK)) {
> +		if (ops->device_enable_auto_rck)
> +			ops->device_enable_auto_rck(lvts_data);
> +	} else {
> +		if (ops->device_read_count_rc_n)
> +			ops->device_read_count_rc_n(lvts_data);
> +	}
> +
> +	if (ops->set_cal_data)
> +		ops->set_cal_data(lvts_data);
> +
> +	disable_all_sensing_points(lvts_data);
> +	wait_all_tc_sensing_point_idle(lvts_data);
> +	if (ops->init_controller)
> +		ops->init_controller(lvts_data);
> +	enable_all_sensing_points(lvts_data);
> +
> +	set_all_tc_hw_reboot(lvts_data);
> +
> +	return 0;
> +}
> +
> +static int prepare_calibration_data(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct sensor_cal_data *cal_data = &lvts_data->cal_data;
> +	struct platform_ops *ops = &lvts_data->ops;
> +	int i, offset, size;
> +	char buffer[512];
> +
> +	cal_data->count_r = devm_kcalloc(dev, lvts_data->num_sensor,
> +					 sizeof(*cal_data->count_r), GFP_KERNEL);
> +	if (!cal_data->count_r)
> +		return -ENOMEM;
> +
> +	cal_data->count_rc = devm_kcalloc(dev, lvts_data->num_sensor,
> +					  sizeof(*cal_data->count_rc), GFP_KERNEL);
> +	if (!cal_data->count_rc)
> +		return -ENOMEM;
> +
> +	if (ops->efuse_to_cal_data)
> +		ops->efuse_to_cal_data(lvts_data);
> +
> +	cal_data->use_fake_efuse = 1;
> +	if (cal_data->golden_temp != 0) {
> +		cal_data->use_fake_efuse = 0;
> +	} else {
> +		for (i = 0; i < lvts_data->num_sensor; i++) {
> +			if (cal_data->count_r[i] != 0 ||
> +			    cal_data->count_rc[i] != 0) {
> +				cal_data->use_fake_efuse = 0;
> +				break;
> +			}
> +		}
> +	}
> +
> +	if (cal_data->use_fake_efuse) {
> +		/* It means all efuse data are equal to 0 */
> +		dev_err(dev,
> +			"[lvts_cal] This sample is not calibrated, fake !!\n");
> +
> +		cal_data->golden_temp = cal_data->default_golden_temp;
> +		for (i = 0; i < lvts_data->num_sensor; i++) {
> +			cal_data->count_r[i] = cal_data->default_count_r;
> +			cal_data->count_rc[i] = cal_data->default_count_rc;
> +		}
> +	}
> +
> +	lvts_data->coeff.golden_temp = cal_data->golden_temp;
> +
> +	dev_info(dev, "[lvts_cal] golden_temp = %d\n", cal_data->golden_temp);
> +
> +	size = sizeof(buffer);
> +	offset = snprintf(buffer, size, "[lvts_cal] num:g_count:g_count_rc ");
> +	for (i = 0; i < lvts_data->num_sensor; i++)
> +		offset += snprintf(buffer + offset, size - offset, "%d:%d:%d ",
> +				   i, cal_data->count_r[i], cal_data->count_rc[i]);
> +
> +	buffer[offset] = '\0';
> +	dev_info(dev, "%s\n", buffer);
> +
> +	return 0;
> +}
> +
> +static int get_calibration_data(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	char cell_name[8];
> +	struct nvmem_cell *cell;
> +	u32 *buf;
> +	size_t len;
> +	int i, j, index = 0, ret;
> +
> +	lvts_data->efuse = devm_kcalloc(dev, lvts_data->num_efuse_addr,
> +					sizeof(*lvts_data->efuse), GFP_KERNEL);
> +	if (!lvts_data->efuse)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < lvts_data->num_efuse_block; i++) {
> +		snprintf(cell_name, sizeof(cell_name), "e_data%d", i + 1);
> +		cell = nvmem_cell_get(dev, cell_name);
> +		if (IS_ERR(cell)) {
> +			dev_err(dev, "Error: Failed to get nvmem cell %s\n", cell_name);
> +			return PTR_ERR(cell);
> +		}
> +
> +		buf = (u32 *)nvmem_cell_read(cell, &len);
> +		nvmem_cell_put(cell);
> +
> +		if (IS_ERR(buf))
> +			return PTR_ERR(buf);
> +
> +		for (j = 0; j < (len / sizeof(u32)); j++) {
> +			if (index >= lvts_data->num_efuse_addr) {
> +				dev_err(dev, "Array efuse is going to overflow");
> +				kfree(buf);
> +				return -EINVAL;
> +			}
> +
> +			lvts_data->efuse[index] = buf[j];
> +			index++;
> +		}
> +
> +		kfree(buf);
> +	}
> +
> +	ret = prepare_calibration_data(lvts_data);
> +
> +	return ret;
> +}
> +
> +static int of_update_lvts_data(struct lvts_data *lvts_data,
> +			       struct platform_device *pdev)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct power_domain *domain;
> +	struct resource *res;
> +	unsigned int i;
> +	int ret;
> +
> +	lvts_data->clk = devm_clk_get(dev, "lvts_clk");
> +	if (IS_ERR(lvts_data->clk))
> +		return PTR_ERR(lvts_data->clk);
> +
> +	domain = devm_kcalloc(dev, lvts_data->num_domain, sizeof(*domain), GFP_KERNEL);
> +	if (!domain)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < lvts_data->num_domain; i++) {
> +		/* Get base address */
> +		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> +		if (!res) {
> +			dev_err(dev, "No IO resource, index %d\n", i);
> +			return -ENXIO;
> +		}
> +
> +		domain[i].base = devm_ioremap_resource(dev, res);
> +		if (IS_ERR(domain[i].base)) {
> +			dev_err(dev, "Failed to remap io, index %d\n", i);
> +			return PTR_ERR(domain[i].base);
> +		}
> +
> +		/* Get interrupt number */
> +		res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> +		if (!res) {
> +			dev_err(dev, "No irq resource, index %d\n", i);
> +			return -EINVAL;
> +		}
> +		domain[i].irq_num = res->start;
> +
> +		/* Get reset control */
> +		domain[i].reset = devm_reset_control_get_by_index(dev, i);
> +		if (IS_ERR(domain[i].reset)) {
> +			dev_err(dev, "Failed to get, index %d\n", i);
> +			return PTR_ERR(domain[i].reset);
> +		}
> +	}
> +
> +	lvts_data->domain = domain;
> +
> +	lvts_data->sen_data = devm_kcalloc(dev, lvts_data->num_sensor,
> +					   sizeof(*lvts_data->sen_data), GFP_KERNEL);
> +	if (!lvts_data->sen_data)
> +		return -ENOMEM;
> +
> +	ret = get_calibration_data(lvts_data);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static void lvts_device_close(struct lvts_data *lvts_data)
> +{
> +	unsigned int i;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +		lvts_write_device(lvts_data, RESET_ALL_DEVICES, i);
> +		writel(DISABLE_LVTS_CTRL_CLK, LVTSCLKEN_0 + base);
> +	}
> +}
> +
> +static void lvts_close(struct lvts_data *lvts_data)
> +{
> +	disable_all_sensing_points(lvts_data);
> +	wait_all_tc_sensing_point_idle(lvts_data);
> +	lvts_device_close(lvts_data);
> +	clk_disable_unprepare(lvts_data->clk);
> +}
> +
> +static void tc_irq_handler(struct lvts_data *lvts_data, int tc_id)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int ret = 0;
> +	void __iomem *base;
> +
> +	base = GET_BASE_ADDR(tc_id);
> +
> +	ret = readl(LVTSMONINTSTS_0 + base);
> +	/* Write back to clear interrupt status */
> +	writel(ret, LVTSMONINTSTS_0 + base);
> +
> +	dev_info(dev, "[Thermal IRQ] LVTS thermal controller %d, LVTSMONINTSTS=0x%08x\n",
> +		 tc_id, ret);
> +
> +	if (ret & THERMAL_PROTECTION_STAGE_3)
> +		dev_info(dev,
> +			 "[Thermal IRQ]: Thermal protection stage 3 interrupt triggered\n");
> +}
> +
> +static irqreturn_t irq_handler(int irq, void *dev_id)
> +{
> +	struct lvts_data *lvts_data = (struct lvts_data *)dev_id;
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	unsigned int i, *irq_bitmap;
> +	void __iomem *base;
> +
> +	irq_bitmap = kcalloc(lvts_data->num_domain, sizeof(*irq_bitmap), GFP_ATOMIC);
> +
> +	if (!irq_bitmap)
> +		return IRQ_NONE;
> +
> +	for (i = 0; i < lvts_data->num_domain; i++) {
> +		base = lvts_data->domain[i].base;
> +		irq_bitmap[i] = readl(THERMINTST + base);
> +		dev_info(dev, "%s : THERMINTST = 0x%x\n", __func__, irq_bitmap[i]);
> +	}
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		if ((irq_bitmap[tc[i].domain_index] & tc[i].irq_bit) == 0)
> +			tc_irq_handler(lvts_data, i);
> +	}
> +
> +	kfree(irq_bitmap);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int lvts_register_irq_handler(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int i;
> +	int ret;
> +
> +	for (i = 0; i < lvts_data->num_domain; i++) {
> +		ret = devm_request_irq(dev, lvts_data->domain[i].irq_num, irq_handler,
> +				       IRQF_TRIGGER_HIGH, "mtk_lvts", lvts_data);
> +
> +		if (ret) {
> +			dev_err(dev, "Failed to register LVTS IRQ, ret %d, domain %d irq_num %d\n",
> +				ret, i, lvts_data->domain[i].irq_num);
> +			lvts_close(lvts_data);
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int lvts_register_thermal_zones(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	struct thermal_zone_device *tzdev;
> +	struct soc_temp_tz *lvts_tz;
> +	int i, ret;
> +
> +	for (i = 0; i < lvts_data->num_sensor + 1; i++) {
> +		lvts_tz = devm_kzalloc(dev, sizeof(*lvts_tz), GFP_KERNEL);
> +		if (!lvts_tz) {
> +			lvts_close(lvts_data);
> +			return -ENOMEM;
> +		}
> +
> +		lvts_tz->id = i;
> +		lvts_tz->lvts_data = lvts_data;
> +
> +		tzdev = devm_thermal_zone_of_sensor_register(dev, lvts_tz->id,
> +							     lvts_tz, &soc_temp_lvts_ops);
> +
> +		if (IS_ERR(tzdev)) {
> +			if (lvts_tz->id != 0)
> +				return 0;
> +
> +			ret = PTR_ERR(tzdev);
> +			dev_err(dev, "Error: Failed to register lvts tz %d, ret = %d\n",
> +				lvts_tz->id, ret);
> +			lvts_close(lvts_data);
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static int lvts_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct lvts_data *lvts_data;
> +	int ret;
> +
> +	lvts_data = (struct lvts_data *)of_device_get_match_data(dev);
> +
> +	if (!lvts_data)	{
> +		dev_err(dev, "Error: Failed to get lvts platform data\n");
> +		return -ENODATA;
> +	}
> +
> +	lvts_data->dev = &pdev->dev;
> +
> +	ret = of_update_lvts_data(lvts_data, pdev);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, lvts_data);
> +
> +	ret = lvts_init(lvts_data);
> +	if (ret)
> +		return ret;
> +
> +	ret = lvts_register_irq_handler(lvts_data);
> +	if (ret)
> +		return ret;
> +
> +	ret = lvts_register_thermal_zones(lvts_data);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int lvts_remove(struct platform_device *pdev)
> +{
> +	struct lvts_data *lvts_data;
> +
> +	lvts_data = (struct lvts_data *)platform_get_drvdata(pdev);
> +
> +	lvts_close(lvts_data);
> +
> +	return 0;
> +}
> +
> +static int lvts_suspend(struct platform_device *pdev, pm_message_t state)
> +{
> +	struct lvts_data *lvts_data;
> +
> +	lvts_data = (struct lvts_data *)platform_get_drvdata(pdev);
> +
> +	lvts_close(lvts_data);
> +
> +	return 0;
> +}
> +
> +static int lvts_resume(struct platform_device *pdev)
> +{
> +	int ret;
> +	struct lvts_data *lvts_data;
> +
> +	lvts_data = (struct lvts_data *)platform_get_drvdata(pdev);
> +
> +	ret = lvts_init(lvts_data);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +/*==================================================
> + * LVTS v4 common code
> + *==================================================
> + */
> +static void device_enable_and_init_v4(struct lvts_data *lvts_data)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		lvts_write_device(lvts_data, STOP_COUNTING_V4, i);
> +		lvts_write_device(lvts_data, SET_RG_TSFM_LPDLY_V4, i);
> +		lvts_write_device(lvts_data, SET_COUNTING_WINDOW_20US1_V4, i);
> +		lvts_write_device(lvts_data, SET_COUNTING_WINDOW_20US2_V4, i);
> +		lvts_write_device(lvts_data, TSV2F_CHOP_CKSEL_AND_TSV2F_EN_V4, i);
> +		lvts_write_device(lvts_data, TSBG_DEM_CKSEL_X_TSBG_CHOP_EN_V4, i);
> +		lvts_write_device(lvts_data, SET_TS_RSV_V4, i);
> +		lvts_write_device(lvts_data, SET_TS_EN_V4, i);
> +		lvts_write_device(lvts_data, TOGGLE_RG_TSV2F_VCO_RST1_V4, i);
> +		lvts_write_device(lvts_data, TOGGLE_RG_TSV2F_VCO_RST2_V4, i);
> +	}
> +
> +	lvts_data->counting_window_us = 20;
> +}
> +
> +static void device_enable_auto_rck_v4(struct lvts_data *lvts_data)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++)
> +		lvts_write_device(lvts_data, SET_LVTS_AUTO_RCK_V4, i);
> +}
> +
> +static int device_read_count_rc_n_v4(struct lvts_data *lvts_data)
> +{
> +	/* Resistor-Capacitor Calibration */
> +	/* count_RC_N: count RC now */
> +	struct device *dev = lvts_data->dev;
> +	struct tc_settings *tc = lvts_data->tc;
> +	struct sensor_cal_data *cal_data = &lvts_data->cal_data;
> +	unsigned int offset, size, s_index, data;
> +	void __iomem *base;
> +	int ret, i, j;
> +	char buffer[512];
> +
> +	cal_data->count_rc_now = devm_kcalloc(dev, lvts_data->num_sensor,
> +					      sizeof(*cal_data->count_rc_now), GFP_KERNEL);
> +	if (!cal_data->count_rc_now)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +		for (j = 0; j < tc[i].num_sensor; j++) {
> +			s_index = tc[i].sensor_map[j];
> +
> +			lvts_write_device(lvts_data, SELECT_SENSOR_RCK_V4(j), i);
> +			lvts_write_device(lvts_data, SET_DEVICE_SINGLE_MODE_V4, i);
> +			usleep_range(10, 20);
> +
> +			lvts_write_device(lvts_data, KICK_OFF_RCK_COUNTING_V4, i);
> +			usleep_range(30, 40);
> +
> +			ret = readl_poll_timeout(LVTS_CONFIG_0 + base, data,
> +						 !(data & DEVICE_SENSING_STATUS), 2, 200);
> +			if (ret)
> +				dev_err(dev,
> +					"Error: LVTS %d DEVICE_SENSING_STATUS didn't ready\n", i);
> +
> +			data = lvts_read_device(lvts_data, 0x00, i);
> +
> +			cal_data->count_rc_now[s_index] = (data & GENMASK(23, 0));
> +		}
> +
> +		/* Recover Setting for Normal Access on
> +		 * temperature fetch
> +		 */
> +		lvts_write_device(lvts_data, SET_SENSOR_NO_RCK_V4, i);
> +		lvts_write_device(lvts_data, SET_DEVICE_LOW_POWER_SINGLE_MODE_V4, i);
> +	}
> +
> +	size = sizeof(buffer);
> +	offset = snprintf(buffer, size, "[COUNT_RC_NOW] ");
> +	for (i = 0; i < lvts_data->num_sensor; i++)
> +		offset += snprintf(buffer + offset, size - offset, "%d:%d ",
> +				   i, cal_data->count_rc_now[i]);
> +
> +	buffer[offset] = '\0';
> +	dev_info(dev, "%s\n", buffer);
> +
> +	return 0;
> +}
> +
> +static void set_calibration_data_v4(struct lvts_data *lvts_data)
> +{
> +	struct tc_settings *tc = lvts_data->tc;
> +	struct sensor_cal_data *cal_data = &lvts_data->cal_data;
> +	unsigned int i, j, s_index, e_data;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +
> +		for (j = 0; j < tc[i].num_sensor; j++) {
> +			s_index = tc[i].sensor_map[j];
> +			if (IS_ENABLE(FEATURE_DEVICE_AUTO_RCK))
> +				e_data = cal_data->count_r[s_index];
> +			else
> +				e_data = (((unsigned long long)
> +					cal_data->count_rc_now[s_index]) *
> +					cal_data->count_r[s_index]) >> 14;
> +
> +			writel(e_data, LVTSEDATA00_0 + base + 0x4 * j);
> +		}
> +	}
> +}
> +
> +static void init_controller_v4(struct lvts_data *lvts_data)
> +{
> +	struct device *dev = lvts_data->dev;
> +	unsigned int i;
> +	void __iomem *base;
> +
> +	for (i = 0; i < lvts_data->num_tc; i++) {
> +		base = GET_BASE_ADDR(i);
> +
> +		lvts_write_device(lvts_data, SET_DEVICE_LOW_POWER_SINGLE_MODE_V4, i);
> +
> +		writel(SET_SENSOR_INDEX, LVTSTSSEL_0 + base);
> +		writel(SET_CALC_SCALE_RULES, LVTSCALSCALE_0 + base);
> +
> +		set_polling_speed(lvts_data, i);
> +		set_hw_filter(lvts_data, i);
> +
> +		dev_info(dev, "lvts%d: read all %d sensors in %d us, one in %d us\n",
> +			 i, GET_TC_SENSOR_NUM(i), GROUP_LATENCY_US(i), SENSOR_LATENCY_US(i));
> +	}
> +}
> +
> +/*==================================================
> + * LVTS MT6873
> + *==================================================
> + */
> +
> +#define MT6873_NUM_LVTS (ARRAY_SIZE(mt6873_tc_settings))
> +
> +enum mt6873_lvts_domain {
> +	MT6873_AP_DOMAIN,
> +	MT6873_MCU_DOMAIN,
> +	MT6873_NUM_DOMAIN
> +};
> +
> +enum mt6873_lvts_sensor_enum {
> +	MT6873_TS1_0,
> +	MT6873_TS1_1,
> +	MT6873_TS2_0,
> +	MT6873_TS2_1,
> +	MT6873_TS3_0,
> +	MT6873_TS3_1,
> +	MT6873_TS3_2,
> +	MT6873_TS3_3,
> +	MT6873_TS4_0,
> +	MT6873_TS4_1,
> +	MT6873_TS5_0,
> +	MT6873_TS5_1,
> +	MT6873_TS6_0,
> +	MT6873_TS6_1,
> +	MT6873_TS7_0,
> +	MT6873_TS7_1,
> +	MT6873_TS7_2,
> +	MT6873_NUM_TS
> +};
> +
> +static void mt6873_efuse_to_cal_data(struct lvts_data *lvts_data)
> +{
> +	struct sensor_cal_data *cal_data = &lvts_data->cal_data;
> +
> +	cal_data->golden_temp = GET_CAL_DATA_BITMASK(0, 31, 24);
> +	cal_data->count_r[MT6873_TS1_0] = GET_CAL_DATA_BITMASK(1, 23, 0);
> +	cal_data->count_r[MT6873_TS1_1] = GET_CAL_DATA_BITMASK(2, 23, 0);
> +	cal_data->count_r[MT6873_TS2_0] = GET_CAL_DATA_BITMASK(3, 23, 0);
> +	cal_data->count_r[MT6873_TS2_1] = GET_CAL_DATA_BITMASK(4, 23, 0);
> +	cal_data->count_r[MT6873_TS3_0] = GET_CAL_DATA_BITMASK(5, 23, 0);
> +	cal_data->count_r[MT6873_TS3_1] = GET_CAL_DATA_BITMASK(6, 23, 0);
> +	cal_data->count_r[MT6873_TS3_2] = GET_CAL_DATA_BITMASK(7, 23, 0);
> +	cal_data->count_r[MT6873_TS3_3] = GET_CAL_DATA_BITMASK(8, 23, 0);
> +	cal_data->count_r[MT6873_TS4_0] = GET_CAL_DATA_BITMASK(9, 23, 0);
> +	cal_data->count_r[MT6873_TS4_1] = GET_CAL_DATA_BITMASK(10, 23, 0);
> +	cal_data->count_r[MT6873_TS5_0] = GET_CAL_DATA_BITMASK(11, 23, 0);
> +	cal_data->count_r[MT6873_TS5_1] = GET_CAL_DATA_BITMASK(12, 23, 0);
> +	cal_data->count_r[MT6873_TS6_0] = GET_CAL_DATA_BITMASK(13, 23, 0);
> +	cal_data->count_r[MT6873_TS6_1] = GET_CAL_DATA_BITMASK(14, 23, 0);
> +	cal_data->count_r[MT6873_TS7_0] = GET_CAL_DATA_BITMASK(15, 23, 0);
> +	cal_data->count_r[MT6873_TS7_1] = GET_CAL_DATA_BITMASK(16, 23, 0);
> +	cal_data->count_r[MT6873_TS7_2] = GET_CAL_DATA_BITMASK(17, 23, 0);
> +
> +	cal_data->count_rc[MT6873_TS1_0] = GET_CAL_DATA_BITMASK(21, 23, 0);
> +
> +	cal_data->count_rc[MT6873_TS2_0] = (GET_CAL_DATA_BITMASK(1, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(2, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(3, 31, 24);
> +
> +	cal_data->count_rc[MT6873_TS3_0] = (GET_CAL_DATA_BITMASK(4, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(5, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(6, 31, 24);
> +
> +	cal_data->count_rc[MT6873_TS4_0] = (GET_CAL_DATA_BITMASK(7, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(8, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(9, 31, 24);
> +
> +	cal_data->count_rc[MT6873_TS5_0] = (GET_CAL_DATA_BITMASK(10, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(11, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(12, 31, 24);
> +
> +	cal_data->count_rc[MT6873_TS6_0] = (GET_CAL_DATA_BITMASK(13, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(14, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(15, 31, 24);
> +
> +	cal_data->count_rc[MT6873_TS7_0] = (GET_CAL_DATA_BITMASK(16, 31, 24) << 16) +
> +					   (GET_CAL_DATA_BITMASK(17, 31, 24) << 8) +
> +					    GET_CAL_DATA_BITMASK(18, 31, 24);
> +}
> +
> +static struct tc_settings mt6873_tc_settings[] = {
> +	[0] = {
> +		.domain_index = MT6873_MCU_DOMAIN,
> +		.addr_offset = 0x0,
> +		.num_sensor = 2,
> +		.sensor_map = {MT6873_TS1_0, MT6873_TS1_1},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT1,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(3),
> +	},
> +	[1] = {
> +		.domain_index = MT6873_MCU_DOMAIN,
> +		.addr_offset = 0x100,
> +		.num_sensor = 2,
> +		.sensor_map = {MT6873_TS2_0, MT6873_TS2_1},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT0,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(4),
> +	},
> +	[2] = {
> +		.domain_index = MT6873_MCU_DOMAIN,
> +		.addr_offset = 0x200,
> +		.num_sensor = 4,
> +		.sensor_map = {MT6873_TS3_0, MT6873_TS3_1, MT6873_TS3_2, MT6873_TS3_3},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT0,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(5),
> +	},
> +	[3] = {
> +		.domain_index = MT6873_AP_DOMAIN,
> +		.addr_offset = 0x0,
> +		.num_sensor = 2,
> +		.sensor_map = {MT6873_TS4_0, MT6873_TS4_1},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT0,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(3),
> +	},
> +	[4] = {
> +		.domain_index = MT6873_AP_DOMAIN,
> +		.addr_offset = 0x100,
> +		.num_sensor = 2,
> +		.sensor_map = {MT6873_TS5_0, MT6873_TS5_1},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT1,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(4),
> +	},
> +	[5] = {
> +		.domain_index = MT6873_AP_DOMAIN,
> +		.addr_offset = 0x200,
> +		.num_sensor = 2,
> +		.sensor_map = {MT6873_TS6_0, MT6873_TS6_1},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT1,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(5),
> +	},
> +	[6] = {
> +		.domain_index = MT6873_AP_DOMAIN,
> +		.addr_offset = 0x300,
> +		.num_sensor = 3,
> +		.sensor_map = {MT6873_TS7_0, MT6873_TS7_1, MT6873_TS7_2},
> +		.tc_speed = SET_TC_SPEED_IN_US(118, 118, 118, 118),
> +		.hw_filter = LVTS_FILTER_2_OF_4,
> +		.dominator_sensing_point = SENSING_POINT2,
> +		.hw_reboot_trip_point = 117000,
> +		.irq_bit = BIT(6),
> +	}
> +};
> +
> +static struct lvts_data mt6873_lvts_data = {
> +	.num_domain = MT6873_NUM_DOMAIN,
> +	.num_tc = MT6873_NUM_LVTS,
> +	.tc = mt6873_tc_settings,
> +	.num_sensor = MT6873_NUM_TS,
> +	.ops = {
> +		.efuse_to_cal_data = mt6873_efuse_to_cal_data,
> +		.device_enable_and_init = device_enable_and_init_v4,
> +		.device_enable_auto_rck = device_enable_auto_rck_v4,
> +		.device_read_count_rc_n = device_read_count_rc_n_v4,
> +		.set_cal_data = set_calibration_data_v4,
> +		.init_controller = init_controller_v4,
> +	},
> +	.feature_bitmap = FEATURE_DEVICE_AUTO_RCK,
> +	.num_efuse_addr = 22,
> +	.num_efuse_block = 1,
> +	.cal_data = {
> +		.default_golden_temp = 50,
> +		.default_count_r = 35000,
> +		.default_count_rc = 2750,
> +	},
> +	.coeff = {
> +		.a = -250460,
> +		.b = 250460,
> +	},
> +};
> +
> +/*==================================================
> + *==================================================
> + * Support chips
> + *==================================================
> + */
> +static const struct of_device_id lvts_of_match[] = {
> +	{
> +		.compatible = "mediatek,mt6873-lvts",
> +		.data = (void *)&mt6873_lvts_data,
> +	},
> +	{
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, lvts_of_match);
> +/*==================================================*/
> +static struct platform_driver soc_temp_lvts = {
> +	.probe = lvts_probe,
> +	.remove = lvts_remove,
> +	.suspend = lvts_suspend,
> +	.resume = lvts_resume,
> +	.driver = {
> +		.name = "mtk-soc-temp-lvts",
> +		.of_match_table = lvts_of_match,
> +	},
> +};
> +
> +module_platform_driver(soc_temp_lvts);
> +MODULE_AUTHOR("Yu-Chia Chang <ethan.chang at mediatek.com>");
> +MODULE_AUTHOR("Michael Kao <michael.kao at mediatek.com>");
> +MODULE_DESCRIPTION("Mediatek soc temperature driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/thermal/mediatek/soc_temp_lvts.h b/drivers/thermal/mediatek/soc_temp_lvts.h
> new file mode 100644
> index 000000000000..1d90bdec53c6
> --- /dev/null
> +++ b/drivers/thermal/mediatek/soc_temp_lvts.h
> @@ -0,0 +1,312 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#ifndef __MTK_SOC_TEMP_LVTS_H__
> +#define __MTK_SOC_TEMP_LVTS_H__
> +
> +/* LVTS HW filter settings
> + * 000: Get one sample
> + * 001: Get 2 samples and average them
> + * 010: Get 4 samples, drop max and min, then average the rest of 2 samples
> + * 011: Get 6 samples, drop max and min, then average the rest of 4 samples
> + * 100: Get 10 samples, drop max and min, then average the rest of 8 samples
> + * 101: Get 18 samples, drop max and min, then average the rest of 16 samples
> + */
> +enum lvts_hw_filter {
> +	LVTS_FILTER_1,
> +	LVTS_FILTER_2,
> +	LVTS_FILTER_2_OF_4,
> +	LVTS_FILTER_4_OF_6,
> +	LVTS_FILTER_8_OF_10,
> +	LVTS_FILTER_16_OF_18
> +};
> +
> +enum lvts_sensing_point {
> +	SENSING_POINT0,
> +	SENSING_POINT1,
> +	SENSING_POINT2,
> +	SENSING_POINT3,
> +	ALL_SENSING_POINTS
> +};
> +
> +/*==================================================
> + * Data structure
> + *==================================================
> + */
> +struct lvts_data;
> +
> +struct speed_settings {
> +	unsigned int period_unit;
> +	unsigned int group_interval_delay;
> +	unsigned int filter_interval_delay;
> +	unsigned int sensor_interval_delay;
> +};
> +
> +struct tc_settings {
> +	unsigned int domain_index;
> +	unsigned int addr_offset;
> +	unsigned int num_sensor;
> +	unsigned int sensor_map[ALL_SENSING_POINTS]; /* In sensor ID */
> +	struct speed_settings tc_speed;
> +	/* HW filter setting
> +	 * 000: Get one sample
> +	 * 001: Get 2 samples and average them
> +	 * 010: Get 4 samples, drop max and min, then average the rest of 2 samples
> +	 * 011: Get 6 samples, drop max and min, then average the rest of 4 samples
> +	 * 100: Get 10 samples, drop max and min, then average the rest of 8 samples
> +	 * 101: Get 18 samples, drop max and min, then average the rest of 16 samples
> +	 */
> +	unsigned int hw_filter;
> +	/* Dominator_sensing point is used to select a sensing point
> +	 * and reference its temperature to trigger Thermal HW Reboot
> +	 * When it is ALL_SENSING_POINTS, it will select all sensing points
> +	 */
> +	int dominator_sensing_point;
> +	int hw_reboot_trip_point; /* -274000: Disable HW reboot */
> +	unsigned int irq_bit;
> +};
> +
> +struct formula_coeff {
> +	int a;
> +	int b;
> +	unsigned int golden_temp;
> +};
> +
> +struct sensor_cal_data {
> +	int use_fake_efuse;	/* 1: Use fake efuse, 0: Use real efuse */
> +	unsigned int golden_temp;
> +	unsigned int *count_r;
> +	unsigned int *count_rc;
> +	unsigned int *count_rc_now;
> +
> +	unsigned int default_golden_temp;
> +	unsigned int default_count_r;
> +	unsigned int default_count_rc;
> +};
> +
> +struct platform_ops {
> +	void (*efuse_to_cal_data)(struct lvts_data *lvts_data);
> +	void (*device_enable_and_init)(struct lvts_data *lvts_data);
> +	void (*device_enable_auto_rck)(struct lvts_data *lvts_data);
> +	int (*device_read_count_rc_n)(struct lvts_data *lvts_data);
> +	void (*set_cal_data)(struct lvts_data *lvts_data);
> +	void (*init_controller)(struct lvts_data *lvts_data);
> +};
> +
> +struct power_domain {
> +	void __iomem *base;	/* LVTS base addresses */
> +	unsigned int irq_num;	/* LVTS interrupt numbers */
> +	struct reset_control *reset;
> +};
> +
> +struct sensor_data {
> +	int temp;		/* Current temperature */
> +	unsigned int msr_raw;	/* MSR raw data from LVTS */
> +};
> +
> +struct lvts_data {
> +	struct device *dev;
> +	struct clk *clk;
> +	unsigned int num_domain;
> +	struct power_domain *domain;
> +
> +	int num_tc;			/* Number of LVTS thermal controllers */
> +	struct tc_settings *tc;
> +	int counting_window_us;		/* LVTS device counting window */
> +
> +	int num_sensor;			/* Number of sensors in this platform */
> +	struct sensor_data *sen_data;
> +
> +	struct platform_ops ops;
> +	int feature_bitmap;		/* Show what features are enabled */
> +
> +	unsigned int num_efuse_addr;
> +	unsigned int *efuse;
> +	unsigned int num_efuse_block;	/* Number of contiguous efuse indexes */
> +	struct sensor_cal_data cal_data;
> +	struct formula_coeff coeff;
> +};
> +
> +struct soc_temp_tz {
> +	unsigned int id; /* if id is 0, get max temperature of all sensors */
> +	struct lvts_data *lvts_data;
> +};
> +
> +struct match_entry {
> +	char	chip[32];
> +	struct lvts_data *lvts_data;
> +};
> +
> +struct lvts_match_data {
> +	unsigned int hw_version;
> +	struct match_entry *table;
> +	void (*set_up_common_callbacks)(struct lvts_data *lvts_data);
> +	struct list_head node;
> +};
> +
> +struct lvts_id {
> +	unsigned int hw_version;
> +	char	chip[32];
> +};
> +
> +/*==================================================
> + * LVTS device register
> + *==================================================
> + */
> +#define RG_TSFM_DATA_0	0x00
> +#define RG_TSFM_DATA_1	0x01
> +#define RG_TSFM_DATA_2	0x02
> +#define RG_TSFM_CTRL_0	0x03
> +#define RG_TSFM_CTRL_1	0x04
> +#define RG_TSFM_CTRL_2	0x05
> +#define RG_TSFM_CTRL_3	0x06
> +#define RG_TSFM_CTRL_4	0x07
> +#define RG_TSV2F_CTRL_0	0x08
> +#define RG_TSV2F_CTRL_1	0x09
> +#define RG_TSV2F_CTRL_2	0x0A
> +#define RG_TSV2F_CTRL_3	0x0B
> +#define RG_TSV2F_CTRL_4	0x0C
> +#define RG_TSV2F_CTRL_5	0x0D
> +#define RG_TSV2F_CTRL_6	0x0E
> +#define RG_TEMP_DATA_0	0x10
> +#define RG_TEMP_DATA_1	0x11
> +#define RG_TEMP_DATA_2	0x12
> +#define RG_TEMP_DATA_3	0x13
> +#define RG_RC_DATA_0	0x14
> +#define RG_RC_DATA_1	0x15
> +#define RG_RC_DATA_2	0x16
> +#define RG_RC_DATA_3	0x17
> +#define RG_DIV_DATA_0	0x18
> +#define RG_DIV_DATA_1	0x19
> +#define RG_DIV_DATA_2	0x1A
> +#define RG_DIV_DATA_3	0x1B
> +#define RG_TST_DATA_0	0x70
> +#define RG_TST_DATA_1	0x71
> +#define RG_TST_DATA_2	0x72
> +#define RG_TST_CTRL	0x73
> +#define RG_DBG_FQMTR	0xF0
> +#define RG_DBG_LPSEQ	0xF1
> +#define RG_DBG_STATE	0xF2
> +#define RG_DBG_CHKSUM	0xF3
> +#define RG_DID_LVTS	0xFC
> +#define RG_DID_REV	0xFD
> +#define RG_TSFM_RST	0xFF
> +/*==================================================
> + * LVTS controller register
> + *==================================================
> + */
> +#define LVTSMONCTL0_0	0x000
> +#define LVTS_SINGLE_SENSE	BIT(9)
> +#define ENABLE_SENSING_POINT(num)	(LVTS_SINGLE_SENSE | GENMASK(((num) - 1), 0))
> +#define DISABLE_SENSING_POINT	(LVTS_SINGLE_SENSE | 0x0)
> +#define LVTSMONCTL1_0	0x004
> +#define LVTSMONCTL2_0	0x008
> +#define LVTSMONINT_0	0x00C
> +#define STAGE3_INT_EN	BIT(31)
> +#define LVTSMONINTSTS_0	0x010
> +#define LVTSMONIDET0_0	0x014
> +#define LVTSMONIDET1_0	0x018
> +#define LVTSMONIDET2_0	0x01C
> +#define LVTSMONIDET3_0	0x020
> +#define LVTSH2NTHRE_0	0x024
> +#define LVTSHTHRE_0	0x028
> +#define LVTSCTHRE_0	0x02C
> +#define LVTSOFFSETH_0	0x030
> +#define LVTSOFFSETL_0	0x034
> +#define LVTSMSRCTL0_0	0x038
> +#define LVTSMSRCTL1_0	0x03C
> +#define LVTSTSSEL_0	0x040
> +#define SET_SENSOR_INDEX	0x13121110
> +#define LVTSDEVICETO_0	0x044
> +#define LVTSCALSCALE_0	0x048
> +#define SET_CALC_SCALE_RULES	0x00000300
> +#define LVTS_ID_0	0x04C
> +#define LVTS_CONFIG_0	0x050
> +
> +#define BROADCAST_ID_UPDATE	BIT(26)
> +#define DEVICE_SENSING_STATUS	BIT(25)
> +#define DEVICE_ACCESS_STARTUS	BIT(24)
> +#define WRITE_ACCESS		BIT(16)
> +#define DEVICE_WRITE		(BIT(31) | CK26M_ACTIVE | DEVICE_ACCESS_STARTUS \
> +				| BIT(17) | WRITE_ACCESS)
> +#define DEVICE_READ		(BIT(31) | CK26M_ACTIVE | DEVICE_ACCESS_STARTUS \
> +				| 1 << 17)
> +#define RESET_ALL_DEVICES	(DEVICE_WRITE | RG_TSFM_RST << 8 | 0xFF)
> +#define READ_BACK_DEVICE_ID	(BIT(31) | CK26M_ACTIVE | BROADCAST_ID_UPDATE	\
> +				| DEVICE_ACCESS_STARTUS | BIT(17)	\
> +				| RG_DID_LVTS << 8)
> +#define READ_DEVICE_REG(reg_idx)	(DEVICE_READ | (reg_idx) << 8 | 0x00)
> +#define LVTSEDATA00_0	0x054
> +#define LVTSEDATA01_0	0x058
> +#define LVTSEDATA02_0	0x05C
> +#define LVTSEDATA03_0	0x060
> +#define LVTSMSR0_0	0x090
> +#define MRS_RAW_MASK		GENMASK(15, 0)
> +#define MRS_RAW_VALID_BIT	BIT(16)
> +#define LVTSMSR1_0	0x094
> +#define LVTSMSR2_0	0x098
> +#define LVTSMSR3_0	0x09C
> +#define LVTSIMMD0_0	0x0A0
> +#define LVTSIMMD1_0	0x0A4
> +#define LVTSIMMD2_0	0x0A8
> +#define LVTSIMMD3_0	0x0AC
> +#define LVTSRDATA0_0	0x0B0
> +#define LVTSRDATA1_0	0x0B4
> +#define LVTSRDATA2_0	0x0B8
> +#define LVTSRDATA3_0	0x0BC
> +#define LVTSPROTCTL_0	0x0C0
> +#define PROTOFFSET	GENMASK(15, 0)
> +#define LVTSPROTTA_0	0x0C4
> +#define LVTSPROTTB_0	0x0C8
> +#define LVTSPROTTC_0	0x0CC
> +#define LVTSCLKEN_0	0x0E4
> +#define ENABLE_LVTS_CTRL_CLK	(1)
> +#define DISABLE_LVTS_CTRL_CLK	(0)
> +#define LVTSDBGSEL_0	0x0E8
> +#define LVTSDBGSIG_0	0x0EC
> +#define LVTSSPARE0_0	0x0F0
> +#define LVTSSPARE1_0	0x0F4
> +#define LVTSSPARE2_0	0x0F8
> +#define LVTSSPARE3_0	0x0FC
> +
> +#define THERMINTST	0xF04
> +/*==================================================
> + * LVTS register mask
> + *==================================================
> + */
> +#define THERMAL_COLD_INTERRUPT_0		0x00000001
> +#define THERMAL_HOT_INTERRUPT_0			0x00000002
> +#define THERMAL_LOW_OFFSET_INTERRUPT_0		0x00000004
> +#define THERMAL_HIGH_OFFSET_INTERRUPT_0		0x00000008
> +#define THERMAL_HOT2NORMAL_INTERRUPT_0		0x00000010
> +#define THERMAL_COLD_INTERRUPT_1		0x00000020
> +#define THERMAL_HOT_INTERRUPT_1			0x00000040
> +#define THERMAL_LOW_OFFSET_INTERRUPT_1		0x00000080
> +#define THERMAL_HIGH_OFFSET_INTERRUPT_1		0x00000100
> +#define THERMAL_HOT2NORMAL_INTERRUPT_1		0x00000200
> +#define THERMAL_COLD_INTERRUPT_2		0x00000400
> +#define THERMAL_HOT_INTERRUPT_2			0x00000800
> +#define THERMAL_LOW_OFFSET_INTERRUPT_2		0x00001000
> +#define THERMAL_HIGH_OFFSET_INTERRUPT_2		0x00002000
> +#define THERMAL_HOT2NORMAL_INTERRUPT_2		0x00004000
> +#define THERMAL_AHB_TIMEOUT_INTERRUPT		0x00008000
> +#define THERMAL_DEVICE_TIMEOUT_INTERRUPT	0x00008000
> +#define THERMAL_IMMEDIATE_INTERRUPT_0		0x00010000
> +#define THERMAL_IMMEDIATE_INTERRUPT_1		0x00020000
> +#define THERMAL_IMMEDIATE_INTERRUPT_2		0x00040000
> +#define THERMAL_FILTER_INTERRUPT_0		0x00080000
> +#define THERMAL_FILTER_INTERRUPT_1		0x00100000
> +#define THERMAL_FILTER_INTERRUPT_2		0x00200000
> +#define THERMAL_COLD_INTERRUPT_3		0x00400000
> +#define THERMAL_HOT_INTERRUPT_3			0x00800000
> +#define THERMAL_LOW_OFFSET_INTERRUPT_3		0x01000000
> +#define THERMAL_HIGH_OFFSET_INTERRUPT_3		0x02000000
> +#define THERMAL_HOT2NORMAL_INTERRUPT_3		0x04000000
> +#define THERMAL_IMMEDIATE_INTERRUPT_3		0x08000000
> +#define THERMAL_FILTER_INTERRUPT_3		0x10000000
> +#define THERMAL_PROTECTION_STAGE_1		0x20000000
> +#define THERMAL_PROTECTION_STAGE_2		0x40000000
> +#define THERMAL_PROTECTION_STAGE_3		0x80000000
> +#endif /* __MTK_SOC_TEMP_LVTS_H__ */


From daniel.lezcano at linaro.org  Wed Apr  7 10:10:07 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Wed, 7 Apr 2021 11:10:07 +0200
Subject: [v3,1/3] thermal: mediatek: Relocate driver to mediatek folder
In-Reply-To: <1617786505.12846.1.camel@mtksdccf07>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-2-michael.kao@mediatek.com>
 <1617786505.12846.1.camel@mtksdccf07>
Message-ID: <848df858-1f8d-bcf1-f885-546b70c37b9e@linaro.org>

On 07/04/2021 11:08, Michael Kao wrote:
> Hi Maintainers,
>  
> Gentle pin for this patch.
>  
> Thanks

ack, pong



-- 
<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 fabien.dessenne at foss.st.com  Wed Apr  7 10:25:03 2021
From: fabien.dessenne at foss.st.com (Fabien Dessenne)
Date: Wed, 7 Apr 2021 11:25:03 +0200
Subject: [Linux-stm32] [PATCH] pinctrl: stm32: Print invalid AF warning
 inside stm32_pctrl_is_function_valid()
In-Reply-To: <20210406180035.279249-1-marex@denx.de>
References: <20210406180035.279249-1-marex@denx.de>
Message-ID: <1e7d6e0c-1f7a-e7ca-dda9-d659f3ff744a@foss.st.com>

Hi Marek,

Thank you for the patch!


On 06/04/2021 8:00 pm, Marek Vasut wrote:
> The "invalid function %d on pin %d .\n" message is triplicated in the
> driver in different variants, just pull it into the function and have
> it once in the driver. The bonus is that all variants of the message
> now print the pin number and AF consistently, so it is easier to debug
> such pinmux problems.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>

Acked-by: Fabien Dessenne <fabien.dessenne at foss.st.com>

> Cc: Fabien Dessenne <fabien.dessenne at st.com>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org
> ---
>   drivers/pinctrl/stm32/pinctrl-stm32.c | 13 ++++---------
>   1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
> index da72e3e5c08d..ad9eb5ed8e81 100644
> --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
> @@ -531,6 +531,8 @@ static bool stm32_pctrl_is_function_valid(struct stm32_pinctrl *pctl,
>   		break;
>   	}
>   
> +	dev_err(pctl->dev, "invalid function %d on pin %d .\n", fnum, pin_num);
> +
>   	return false;
>   }
>   
> @@ -545,11 +547,8 @@ static int stm32_pctrl_dt_node_to_map_func(struct stm32_pinctrl *pctl,
>   	(*map)[*num_maps].type = PIN_MAP_TYPE_MUX_GROUP;
>   	(*map)[*num_maps].data.mux.group = grp->name;
>   
> -	if (!stm32_pctrl_is_function_valid(pctl, pin, fnum)) {
> -		dev_err(pctl->dev, "invalid function %d on pin %d .\n",
> -				fnum, pin);
> +	if (!stm32_pctrl_is_function_valid(pctl, pin, fnum))
>   		return -EINVAL;
> -	}
>   
>   	(*map)[*num_maps].data.mux.function = stm32_gpio_functions[fnum];
>   	(*num_maps)++;
> @@ -620,7 +619,6 @@ static int stm32_pctrl_dt_subnode_to_map(struct pinctrl_dev *pctldev,
>   		func = STM32_GET_PIN_FUNC(pinfunc);
>   
>   		if (!stm32_pctrl_is_function_valid(pctl, pin, func)) {
> -			dev_err(pctl->dev, "invalid function.\n");
>   			err = -EINVAL;
>   			goto exit;
>   		}
> @@ -821,11 +819,8 @@ static int stm32_pmx_set_mux(struct pinctrl_dev *pctldev,
>   	int pin;
>   
>   	ret = stm32_pctrl_is_function_valid(pctl, g->pin, function);
> -	if (!ret) {
> -		dev_err(pctl->dev, "invalid function %d on group %d .\n",
> -				function, group);
> +	if (!ret)
>   		return -EINVAL;
> -	}
>   
>   	range = pinctrl_find_gpio_range_from_pin(pctldev, g->pin);
>   	if (!range) {
> 


From maz at kernel.org  Wed Apr  7 10:28:44 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 10:28:44 +0100
Subject: [PATCH v19 3/7] ptp: Reorganize ptp_kvm.c to make it
 arch-independent
In-Reply-To: <20210330145430.996981-4-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-4-maz@kernel.org>
Message-ID: <87eefmpho3.wl-maz@kernel.org>

On Tue, 30 Mar 2021 15:54:26 +0100,
Marc Zyngier <maz at kernel.org> wrote:
> 
> From: Jianyong Wu <jianyong.wu at arm.com>
> 
> Currently, the ptp_kvm module contains a lot of x86-specific code.
> Let's move this code into a new arch-specific file in the same directory,
> and rename the arch-independent file to ptp_kvm_common.c.
> 
> Reviewed-by: Andre Przywara <andre.przywara at arm.com>
> Signed-off-by: Jianyong Wu <jianyong.wu at arm.com>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu at arm.com

Richard, Paolo,

Can I get an Ack on this and patch #7? We're getting pretty close to
the next merge window, and this series has been going on for a couple
of years now...

Thanks,

	M.

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


From linus.walleij at linaro.org  Wed Apr  7 10:34:29 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 7 Apr 2021 11:34:29 +0200
Subject: gemini: sl3516: Mainlining of NS 2502
In-Reply-To: <YGxOf8pKN8Ip/kCl@Red>
References: <YGtZeofmBv7hXK+a@Red>
 <CACRpkdZ_barDrLvD2UBKo+GA-F+g72uMQx8CfRK2YLRodpeyUA@mail.gmail.com>
 <YGxOf8pKN8Ip/kCl@Red>
Message-ID: <CACRpkdYRUXJY_tXamS0vc+RNPDxR2oxdRLbBUk0fmQLp+eYAOA@mail.gmail.com>

On Tue, Apr 6, 2021 at 2:05 PM Corentin Labbe <clabbe.montjoie at gmail.com> wrote:

> You could find photos at http://kernel.montjoie.ovh/gemini/
> There are also photos of another SL3516 SoC based device (a SSI 1328 NAS), but I fail to setup a serial on it, so I keep it for later.

Yeah it is clearly an RTL82111 at least, so this should be possible
to get going.

> > >                 syscon: syscon at 40000000 {
> > >                         pinctrl {
> > >                                 /*
> > >                                  * gpio0agrp cover line 0-4
> > >                                  * gpio0bgrp cover line 5
> > >                                  */
> > >                                 gpio0_default_pins: pinctrl-gpio0 {
> > >                                         mux {
> > >                                                 function = "gpio0";
> > >                                                 groups = "gpio0agrp",
> > >                                                 "gpio0bgrp";
> > >                                         };
> > >                                 };
> >
> > Change groups to
> >
> > groups = "gpio0agrp", "gpio0bgrp", "gpio0hgrp";
> >
> > So you mux in group h which is where the GPIO 21, 22 go out
> > to the MDIO on 3516 IIUC. The right mux out is pretty important,
> > if you have vendor source code, please share so I can check how
> > they set it up.
>
> No change, probably due to all pinctrl-gemini 40000000.syscon:pinctrl: could not map pin config for "R8 GMAC0 RXDV"
> Please see http://kernel.montjoie.ovh/gemini/bootlog6.txt , I have added some pr_info in gmac.
> I have put in the directory, the final dtb which I use.

All this is wrong too:
pinctrl-gemini 40000000.syscon:pinctrl: could not map pin config for
"R8 GMAC0 RXDV"
pinctrl-gemini 40000000.syscon:pinctrl: could not map pin config for
"U11 GMAC1 RXDV"
(...)

This is because we copied the DT config from a 3512 device rather than
3516 ... totally different pins. :/ R8 is the pin on 3512 so they all need
to change to e.g. from "R8 GMAC0 RXDV" to "V8 GMAC0 RXDV".

We need to come up with something unique for this device.

The code for mux is in drivers/pinctrl/pinctrl-gemini.c but can be a bit
terse. This file contains both 3512 and 3516 drivers so check closely
that you are looking at the right variant. The right pin names are in
the array gemini_3516_pins[].

The tricky thing is that I have never seen a SL3516 connected directly to
a simple phy like 82111. They all connect to some kind of switch chip...
So we need to figure out the muxing and pin config for this set-up.

This is what the DIR-685 is using for GMAC0:

                                pinctrl-gmii {
                                        mux {
                                                function = "gmii";
                                                groups = "gmii_gmac0_grp";
                                        };
                                        conf0 {
                                                pins = "V8 GMAC0
RXDV", "T10 GMAC1 RXDV",
                                                     "Y7 GMAC0 RXC",
"Y11 GMAC1 RXC",
                                                     "T8 GMAC0 TXEN",
"W11 GMAC1 TXEN",
                                                     "U8 GMAC0 TXC",
"V11 GMAC1 TXC",
                                                     "W8 GMAC0 RXD0",
"V9 GMAC0 RXD1",
                                                     "Y8 GMAC0 RXD2",
"U9 GMAC0 RXD3",
                                                     "T7 GMAC0 TXD0",
"U6 GMAC0 TXD1",
                                                     "V7 GMAC0 TXD2",
"U7 GMAC0 TXD3",
                                                     "Y12 GMAC1 RXD0",
"V12 GMAC1 RXD1",
                                                     "T11 GMAC1 RXD2",
"W12 GMAC1 RXD3",
                                                     "U10 GMAC1 TXD0",
"Y10 GMAC1 TXD1",
                                                     "W10 GMAC1 TXD2",
"T9 GMAC1 TXD3";
                                                skew-delay = <7>;
                                        };
                                        /* Set up drive strength on
GMAC0 to 16 mA */
                                        conf1 {
                                                groups = "gmii_gmac0_grp";
                                                drive-strength = <16>;
                                        };
                                };

But maybe your device is using GMAC1? I would try GMAC0 first anyway.

> The vendor source could be found at https://www.edimax.com/edimax/mw/cufiles/files/download/OpenSourceCode/transfer/Wireless/NAS/NAS-GPL-source.zip

Normally the kernel should be setting up device resources and
config under arch/arm/mach-sl2312 (never mind the ASIC number...)
but Storlink have hacked the kernel all over the place so the
relevant parts can be hard to find.

The interesting stuff relating to pin control appears when
you grep for SL2312_GLOBAL_BASE.

When the kernel boots some essentials are set up
already in init/main.c (hacky!). But it seems to be the same
as in all Storlink devices.

This part in drivers/net/sl2312_emac.c looks quite interesting:

#ifdef CONFIG_SL3516_ASIC
{
    unsigned int    val;

    /* set GMAC global register */
    val = readl(GMAC_GLOBAL_BASE_ADDR+0x10);
    val = val | 0x005a0000;
    writel(val,GMAC_GLOBAL_BASE_ADDR+0x10);
    writel(0x07f007f0,GMAC_GLOBAL_BASE_ADDR+0x1c);
    writel(0x77770000,GMAC_GLOBAL_BASE_ADDR+0x20);
    writel(0x77770000,GMAC_GLOBAL_BASE_ADDR+0x24);
        val = readl(GMAC_GLOBAL_BASE_ADDR+0x04);
        if((val&(1<<20))==0){           // GMAC1 enable
                val = readl(GMAC_GLOBAL_BASE_ADDR+0x30);
                val = (val & 0xe7ffffff) | 0x08000000;
                writel(val,GMAC_GLOBAL_BASE_ADDR+0x30);
        }

}
#endif

So we need to verify that this corresponds to what you set
up in your device tree (I do it by reading the data sheets and
coparing to the pinctrl-gemini.c code and defines...)

Then we have this:

/* define GPIO pin for MDC/MDIO */

// for gemini ASIC
#ifdef CONFIG_SL3516_ASIC
#define H_MDC_PIN           22
#define H_MDIO_PIN          21
#define G_MDC_PIN           22
#define G_MDIO_PIN          21
#else
(...)

This seems to correspond to your device tree so OK...

But it's annoying that we can't communicate with it.
This is usually because some other device is
"shading" the GPIO lines, i.e. hiding it.

drivers/net/sl_switch.c is not used on your platform (Vitesse switch)
and is a leftover from the Storlink reference design.

> > > BUT neither ethernet nor USB works.
> >
> > For USB try this patch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=gemini-usb&id=cbaf6cdf770b90de5f10bfa5112c679f1dffe948
> >
>
> One of the USB port is now working.

Hey nice! :D

The USB patch is not very widely tested, so it may need some shaping
up.

> Note that I have also started to work on the gemini crypto driver.

I saw some nice debug prints! :D

I always wanted to get that to work, nice that you're working on
it!

Yours,
Linus Walleij


From richard.xnu.clark at gmail.com  Wed Apr  7 10:37:52 2021
From: richard.xnu.clark at gmail.com (richard clark)
Date: Wed, 7 Apr 2021 17:37:52 +0800
Subject: Question: multiple SMMUv3 devices probe
Message-ID: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>

Hi guys,
There're 3 SMMUv3 devices in my arm64 box. I am confused by the below
probe process:

arm_smmu_device_probe(...) --> arm_smmu_set_bus_ops(&arm_smmu_ops):
if (platform_bus_type.iommu_ops != ops) {
        err = bus_set_iommu(&platform_bus_type, ops);
        if (err)
}

so for the 1st smmu device on the platform_bus, the
arm_smmu_device_probe(...) will set the platform_bus_type.iommu_bus =
arm_smmu_ops, so for the arm_smmu_device_probe(...) when probing the
2nd smmu device, the bus_set_iommu() will have no chance be called
since the platform_bus_type.iommu_bus == arm_smmu_ops is true, my
question is how the followed bus_set_iommu(...) being called?

Thanks,
RC


From liuqi115 at huawei.com  Wed Apr  7 10:49:01 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Wed, 7 Apr 2021 17:49:01 +0800
Subject: [PATCH 0/2] drivers/perf: hisi: Add support for PCIe PMU
Message-ID: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>

This patchset adds support for HiSilicon PCIe Performance Monitoring
Unit(PMU). It is a PCIe Root Complex integrated End Point(RCiEP) device
added on Hip09. Each PCIe Core has a PMU RCiEP to monitor multi root
ports and all Endpoints downstream these root ports.

HiSilicon PCIe PMU is supported to collect performance data of PCIe bus,
such as: bandwidth, latency etc.

Qi Liu (2):
  drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
  docs: perf: Add description for HiSilicon PCIe PMU driver

 Documentation/admin-guide/perf/hisi-pcie-pmu.rst |  103 +++
 MAINTAINERS                                      |    6 +
 drivers/perf/Kconfig                             |    2 +
 drivers/perf/Makefile                            |    1 +
 drivers/perf/pci/Kconfig                         |   16 +
 drivers/perf/pci/Makefile                        |    2 +
 drivers/perf/pci/hisilicon/Makefile              |    5 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c       | 1012 ++++++++++++++++++++++
 include/linux/cpuhotplug.h                       |    1 +
 9 files changed, 1148 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

-- 
2.8.1



From liuqi115 at huawei.com  Wed Apr  7 10:49:02 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Wed, 7 Apr 2021 17:49:02 +0800
Subject: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1617788943-52722-2-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
to sample bandwidth, latency, buffer occupation etc.

Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
registered as a pmu in /sys/bus/event_source/devices, so users can
select target PMU, and use filter to do further sets.

Filtering options contains:
event        - select the event.
subevent     - select the subevent.
port         - select target root ports. Information of root ports
               are shown under sysfs.
bdf           - select requester_id of target EP device.
trig_len     - set trigger condition for starting event statistics.
trigger_mode - set trigger mode. 0 means starting to statistic when
               bigger than trigger condition, and 1 means smaller.
thr_len      - set threshold for statistics.
thr_mode     - set threshold mode. 0 means count when bigger than
               threshold, and 1 means smaller.

Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 MAINTAINERS                                |    6 +
 drivers/perf/Kconfig                       |    2 +
 drivers/perf/Makefile                      |    1 +
 drivers/perf/pci/Kconfig                   |   16 +
 drivers/perf/pci/Makefile                  |    2 +
 drivers/perf/pci/hisilicon/Makefile        |    5 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1012 ++++++++++++++++++++++++++++
 include/linux/cpuhotplug.h                 |    1 +
 8 files changed, 1045 insertions(+)
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3353de0..46c7861 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8023,6 +8023,12 @@ W:	http://www.hisilicon.com
 F:	Documentation/admin-guide/perf/hisi-pmu.rst
 F:	drivers/perf/hisilicon
 
+HISILICON PCIE PMU DRIVER
+M:	Qi Liu <liuqi115 at huawei.com>
+S:	Maintained
+F:	Documentation/admin-guide/perf/hisi-pcie-pmu.rst
+F:	drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
+
 HISILICON QM AND ZIP Controller DRIVER
 M:	Zhou Wang <wangzhou1 at hisilicon.com>
 L:	linux-crypto at vger.kernel.org
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 3075cf1..99d4760 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -139,4 +139,6 @@ config ARM_DMC620_PMU
 
 source "drivers/perf/hisilicon/Kconfig"
 
+source "drivers/perf/pci/Kconfig"
+
 endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 5260b11..1208c08 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
 obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
+obj-y += pci/
diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
new file mode 100644
index 0000000..a119486
--- /dev/null
+++ b/drivers/perf/pci/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# PCIe Performance Monitor Drivers
+#
+menu "PCIe Performance Monitor"
+
+config HISI_PCIE_PMU
+	tristate "HiSilicon PCIE PERF PMU"
+	depends on ARM64 && PCI && HISI_PMU
+	help
+	  Provide support for HiSilicon PCIe performance monitoring unit (PMU)
+	  RCiEP devices.
+	  Adds the PCIe PMU into perf events system for monitoring latency,
+	  bandwidth etc.
+
+endmenu
diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
new file mode 100644
index 0000000..a56b1a9
--- /dev/null
+++ b/drivers/perf/pci/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-y += hisilicon/
diff --git a/drivers/perf/pci/hisilicon/Makefile b/drivers/perf/pci/hisilicon/Makefile
new file mode 100644
index 0000000..6f99f52
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+ccflags-y :=  -I $(srctree)/drivers/perf/hisilicon
+
+obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
new file mode 100644
index 0000000..9f9bd9d
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
@@ -0,0 +1,1012 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This driver adds support for PCIe PMU RCiEP device. Related
+ * perf events are bandwidth, bandwidth utilization, latency
+ * etc.
+ *
+ * Copyright (C) 2021 HiSilicon Limited
+ * Author: Qi Liu<liuqi115 at huawei.com>
+ */
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/bug.h>
+#include <linux/cpuhotplug.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/perf_event.h>
+
+#include "hisi_uncore_pmu.h"
+
+/* define registers */
+#define HISI_PCIE_GLOBAL_CTRL		0x00
+#define HISI_PCIE_EVENT_CTRL		0x010
+#define HISI_PCIE_CNT			0x090
+#define HISI_PCIE_EXT_CNT		0x110
+#define HISI_PCIE_INT_STAT		0x150
+#define HISI_PCIE_INT_MASK		0x154
+#define HISI_PCIE_REG_BDF		0xfe0
+#define HISI_PCIE_REG_VERSION		0xfe4
+#define HISI_PCIE_REG_INFO		0xfe8
+#define HISI_PCIE_REG_FREQ		0xfec
+
+/* define PCIE CTRL CMD */
+#define HISI_PCIE_GLOBAL_EN		0x01
+#define HISI_PCIE_GLOBAL_NONE		0
+#define HISI_PCIE_EVENT_EN		BIT(20)
+#define HISI_PCIE_RESET_CNT		BIT(22)
+#define HISI_PCIE_DEFAULT_SET		BIT(34)
+#define HISI_PCIE_THR_EN		BIT(26)
+#define HISI_PCIE_TARGET_EN		BIT(32)
+#define HISI_PCIE_TRIG_EN		BIT(52)
+
+/* define offsets in event ctrl regesiter */
+#define HISI_PCIE_EVENT_M		GENMASK_ULL(7, 0)
+#define HISI_PCIE_SUBEVENT_M		GENMASK_ULL(15, 8)
+#define HISI_PCIE_THR_MODE_M		GENMASK_ULL(27, 27)
+#define HISI_PCIE_THR_M			GENMASK_ULL(31, 28)
+#define HISI_PCIE_TARGET_M		GENMASK_ULL(52, 36)
+#define HISI_PCIE_TRIG_MODE_M		GENMASK_ULL(53, 53)
+#define HISI_PCIE_TRIG_M		GENMASK_ULL(59, 56)
+
+#define HISI_PCIE_MAX_COUNTERS		8
+#define HISI_PCIE_REG_STEP		8
+#define HISI_PCIE_EVENT_MAX		0xa2
+#define HISI_PCIE_SUBEVENT_MAX		0x20
+#define HISI_PCIE_THR_MAX_VAL		10
+#define HISI_PCIE_TRIG_MAX_VAL		10
+#define HISI_PCIE_COUNTER_BITS		64
+#define HISI_PCIE_MAX_PERIOD		BIT_ULL(63)
+
+struct hisi_pcie_pmu {
+	struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
+	struct hlist_node node;
+	struct pci_dev *pdev;
+	struct pmu pmu;
+	void __iomem *base;
+	cpumask_t cpumask;
+	int irq;
+	u32 identifier;
+	/* minimum and maximum bdf of root ports monitored by PMU */
+	u16 bdf_min;
+	u16 bdf_max;
+};
+
+#define to_pcie_pmu(p)  (container_of((p), struct hisi_pcie_pmu, pmu))
+#define GET_PCI_DEVFN(bdf)  ((bdf) & 0xff)
+
+#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)       \
+	static inline u64 hisi_pcie_get_##_name(struct perf_event *event)  \
+	{                                                             \
+		return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
+	}							\
+
+HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
+HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
+HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
+HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
+HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
+HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
+HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
+HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
+
+#define HISI_PCIE_CHECK_EVENTS(name, list)             \
+	static inline bool is_##name##_event(u32 idx)                  \
+	{                                                                   \
+		if ((idx >= list[0] && idx <= list[1]) || idx == list[2])  \
+			return true;                                        \
+		return false;                                               \
+	}
+
+/*
+ * The first element of event list is minimum index of TL-layer events
+ * and the second element is maximum index. The third element is index
+ * of a DL-layer event.
+ */
+static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
+static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
+static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
+static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
+
+HISI_PCIE_CHECK_EVENTS(bw, bw_events_list);
+HISI_PCIE_CHECK_EVENTS(latency, latency_events_list);
+HISI_PCIE_CHECK_EVENTS(bus_util, bus_util_events_list);
+HISI_PCIE_CHECK_EVENTS(buf_util, buf_util_events_list);
+
+static ssize_t hisi_pcie_cpumask_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return  cpumap_print_to_pagebuf(true, buf, &pcie_pmu->cpumask);
+}
+
+static ssize_t hisi_pcie_identifier_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
+}
+
+static ssize_t hisi_pcie_bus_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
+}
+
+static void hisi_pcie_parse_data(struct hisi_pcie_pmu *pcie_pmu, u32 reg_off,
+			       u16 *arg0, u16 *arg1)
+{
+	u32 val = readl(pcie_pmu->base + reg_off);
+
+	*arg0 = val & 0xffff;
+	*arg1 = (val & 0xffff0000) >> 16;
+}
+
+static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
+{
+	return offset + HISI_PCIE_REG_STEP * idx;
+}
+
+static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readl(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u32 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writel(val, pcie_pmu->base + offset);
+}
+
+static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readq(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u64 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writeq(val, pcie_pmu->base + offset);
+}
+
+static u64 hisi_pcie_pmu_get_event(struct perf_event *event)
+{
+	return FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
+	       FIELD_PREP(HISI_PCIE_SUBEVENT_M, hisi_pcie_get_subevent(event));
+}
+
+static u64 hisi_pcie_pmu_get_target(struct perf_event *event)
+{
+	u64 port, val;
+
+	port = hisi_pcie_get_port(event);
+	if (port) {
+		val = FIELD_PREP(HISI_PCIE_TARGET_M, port);
+	} else {
+		val = FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
+		val |= HISI_PCIE_TARGET_EN;
+	}
+
+	return val;
+}
+
+static u64 hisi_pcie_pmu_get_trigger(struct perf_event *event)
+{
+	u64 trig_len, val;
+
+	trig_len = hisi_pcie_get_trig_len(event);
+	if (!trig_len)
+		return 0;
+
+	val = FIELD_PREP(HISI_PCIE_TRIG_M, trig_len);
+	val |= FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
+			  hisi_pcie_get_trig_mode(event));
+	val |= HISI_PCIE_TRIG_EN;
+
+	return val;
+}
+
+static u64 hisi_pcie_pmu_get_thr(struct perf_event *event)
+{
+	u64 thr_len, val;
+
+	thr_len = hisi_pcie_get_thr_len(event);
+	if (!thr_len)
+		return 0;
+
+	val = FIELD_PREP(HISI_PCIE_THR_M, thr_len);
+	val |= FIELD_PREP(HISI_PCIE_THR_MODE_M, hisi_pcie_get_thr_mode(event));
+	val |= HISI_PCIE_THR_EN;
+
+	return val;
+}
+
+static void hisi_pcie_pmu_config_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = HISI_PCIE_DEFAULT_SET;
+	val |= hisi_pcie_pmu_get_event(event);
+	val |= hisi_pcie_pmu_get_target(event);
+	val |= hisi_pcie_pmu_get_trigger(event);
+	val |= hisi_pcie_pmu_get_thr(event);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu, u16 bdf)
+{
+	return bdf <= pcie_pmu->bdf_max && bdf >= pcie_pmu->bdf_min;
+}
+
+static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu *pcie_pmu,
+					    u32 bdf)
+{
+	struct pci_dev *root_port, *pdev;
+
+	pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
+					   PCI_BUS_NUM(bdf),
+					   GET_PCI_DEVFN(bdf));
+	if (!pdev)
+		return false;
+
+	root_port = pcie_find_root_port(pdev);
+	if (!root_port)
+		return false;
+
+	pci_dev_put(pdev);
+	return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
+}
+
+static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
+				       struct hisi_pcie_pmu *pcie_pmu)
+{
+	u32 subev_idx = hisi_pcie_get_subevent(event);
+	u32 event_idx = hisi_pcie_get_event(event);
+	u32 requester_id = hisi_pcie_get_bdf(event);
+
+	if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
+	    event_idx > HISI_PCIE_EVENT_MAX) {
+		pci_err(pcie_pmu->pdev,
+			"Max event index and max subevent index is: %d, %d.\n",
+			HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
+		return false;
+	}
+
+	if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
+		return false;
+
+	if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
+		return false;
+
+	if (requester_id) {
+		if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id)) {
+			pci_err(pcie_pmu->pdev, "Invalid requester id.\n");
+			return false;
+		}
+	}
+
+	return true;
+}
+
+static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
+{
+	struct perf_event *sibling, *leader = event->group_leader;
+	int counters = 1;
+
+	if (!is_software_event(leader)) {
+		if (leader->pmu != event->pmu)
+			return false;
+
+		if (leader != event)
+			counters++;
+	}
+
+	for_each_sibling_event(sibling, event->group_leader) {
+		if (is_software_event(sibling))
+			continue;
+
+		if (sibling->pmu != event->pmu)
+			return false;
+
+		counters++;
+	}
+
+	return counters <= HISI_PCIE_MAX_COUNTERS;
+}
+
+static int hisi_pcie_pmu_event_init(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+
+	event->cpu = cpumask_first(&pcie_pmu->cpumask);
+
+	if (event->attr.type != event->pmu->type)
+		return -ENOENT;
+
+	/* Sampling is not supported */
+	if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
+		return -EOPNOTSUPP;
+
+	/* Per-task mode is not supported */
+	if (event->cpu < 0)
+		return -EINVAL;
+
+	if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
+		pci_err(pcie_pmu->pdev, "Invalid filter!\n");
+		return -EINVAL;
+	}
+
+	if (!hisi_pcie_pmu_validate_event_group(event))
+		return -EINVAL;
+
+	return 0;
+}
+
+static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 val,
+				      u64 val_ext)
+{
+#define CONVERT_DW_TO_BYTE(x)	(sizeof(u32) * (x))
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
+	u32 idx = hisi_pcie_get_event(event);
+
+	if (!val_ext)
+		return 0;
+
+	/*
+	 * the bandwidth, latency, bus utilization and buffer occupancy
+	 * is obtained by the (COMMON_COUNTER and EXT_COUNTER). and other
+	 * features is obtained by COMMON_COUNTER.
+	 */
+	if (is_bw_event(idx)) {
+		if (!val_ext / 1000)
+			return 0;
+
+		/* process data to set unit of bandwidth as "Byte/ms" */
+		return (CONVERT_DW_TO_BYTE(val)) / (val_ext / 1000);
+	}
+
+	if (is_latency_event(idx))
+		/* process data to set unit of latency as "us" */
+		return (val * us_per_cycle) / val_ext;
+
+	if (is_bus_util_event(idx))
+		return (val * us_per_cycle) / val_ext;
+
+	if (is_buf_util_event(idx))
+		return val / (val_ext * us_per_cycle);
+
+	return val;
+}
+
+static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 *cnt,
+				       u64 *cnt_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	*cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
+	*cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
+}
+
+static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 val,
+					u64 val_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
+}
+
+static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
+{
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		if (!pcie_pmu->hw_events[idx])
+			return idx;
+	}
+
+	return -EINVAL;
+}
+
+void hisi_pcie_pmu_read(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
+	u64 new_cnt_ext, prev_cnt_ext;
+	u64 new_cnt, prev_cnt, delta;
+
+	hwc_ext = &hwc->extra_reg;
+	do {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
+	} while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
+				 new_cnt) != prev_cnt);
+
+	hwc_ext->config = new_cnt_ext;
+
+	delta = hisi_pcie_pmu_process_data(event, new_cnt - prev_cnt,
+					   new_cnt_ext - prev_cnt_ext);
+	local64_add(delta, &event->count);
+}
+
+static void hisi_pcie_pmu_set_period(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 val = BIT_ULL(HISI_PCIE_COUNTER_BITS - 1);
+
+	hwc_ext = &hwc->extra_reg;
+	local64_set(&hwc->prev_count, val);
+	hwc_ext->config = 0;
+	hisi_pcie_pmu_write_counter(event, val, 0);
+}
+
+static void hisi_pcie_pmu_enable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					 struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val |= HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_disable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					  struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val &= ~HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_enable_int(struct hisi_pcie_pmu *pcie_pmu,
+				     struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 0);
+}
+
+static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
+				      struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
+}
+
+static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
+					struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_RESET_CNT);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+void hisi_pcie_pmu_start(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 prev_cnt, prev_cnt_ext;
+
+	hwc_ext = &hwc->extra_reg;
+	if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
+		return;
+
+	WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
+	hwc->state = 0;
+
+	hisi_pcie_pmu_config_filter(event);
+	hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_set_period(event);
+
+	if (flags & PERF_EF_RELOAD) {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
+	}
+
+	perf_event_update_userpage(event);
+}
+
+void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_read(event);
+	hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_clear_filter(event);
+	WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
+	hwc->state |= PERF_HES_STOPPED;
+
+	if (hwc->state & PERF_HES_UPTODATE)
+		return;
+
+
+	hwc->state |= PERF_HES_UPTODATE;
+}
+
+int hisi_pcie_pmu_add(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	int idx;
+
+	hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+	idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
+	if (idx < 0)
+		return idx;
+
+	hwc->idx = idx;
+	pcie_pmu->hw_events[idx] = event;
+
+	/* Reset PMC to avoid interference caused by previous statistic. */
+	hisi_pcie_pmu_reset_counter(pcie_pmu, hwc);
+
+	if (flags & PERF_EF_START)
+		hisi_pcie_pmu_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+void hisi_pcie_pmu_del(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_stop(event, PERF_EF_UPDATE);
+	pcie_pmu->hw_events[hwc->idx] = NULL;
+	perf_event_update_userpage(event);
+}
+
+void hisi_pcie_pmu_enable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+	int num;
+
+	for (num = 0; num < HISI_PCIE_MAX_COUNTERS; num++) {
+		if (pcie_pmu->hw_events[num])
+			break;
+	}
+
+	if (num == HISI_PCIE_MAX_COUNTERS)
+		return;
+
+	writel(HISI_PCIE_GLOBAL_EN, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+void hisi_pcie_pmu_disable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+
+	writel(HISI_PCIE_GLOBAL_NONE, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+static irqreturn_t hisi_pcie_pmu_irq(int irq, void *data)
+{
+	struct hisi_pcie_pmu *pcie_pmu = data;
+	irqreturn_t ret = IRQ_NONE;
+	struct perf_event *event;
+	u32 overflown;
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		overflown = hisi_pcie_pmu_readl(pcie_pmu, HISI_PCIE_INT_STAT,
+						idx);
+		if (!overflown)
+			continue;
+
+		/* Clear status of interrupt. */
+		hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_STAT, idx, 1);
+		event = pcie_pmu->hw_events[idx];
+		if (!event)
+			continue;
+
+		hisi_pcie_pmu_read(event);
+		hisi_pcie_pmu_set_period(event);
+		ret = IRQ_HANDLED;
+	}
+
+	return ret;
+}
+
+static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
+				      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int irq, ret;
+
+	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
+	if (ret < 0) {
+		pci_err(pdev, "failed to enable MSI vectors, ret = %d!\n", ret);
+		return ret;
+	}
+
+	irq = pci_irq_vector(pdev, 0);
+	ret = request_irq(irq, hisi_pcie_pmu_irq, IRQF_SHARED, "hisi_pcie_pmu",
+			  pcie_pmu);
+	if (ret) {
+		pci_err(pdev, "failed to register irq, ret = %d!\n", ret);
+		pci_free_irq_vectors(pdev);
+		return ret;
+	}
+
+	pcie_pmu->irq = irq;
+
+	return 0;
+}
+
+static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
+					 struct hisi_pcie_pmu *pcie_pmu)
+{
+	free_irq(pcie_pmu->irq, pcie_pmu);
+	pci_free_irq_vectors(pdev);
+}
+
+static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+
+	if (cpumask_empty(&pcie_pmu->cpumask)) {
+		cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
+		WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
+	}
+
+	return 0;
+}
+
+static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+	unsigned int target;
+
+	if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))
+		return 0;
+
+	/* Choose a new CPU from all online cpus */
+	target = cpumask_any_but(cpu_online_mask, cpu);
+	if (target >= nr_cpu_ids)
+		return 0;
+
+	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
+	WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
+
+	return 0;
+}
+
+/*
+ * Events with the "dl" suffix in their names counts performance in DL layer,
+ * otherswise, event counts performance in TL layer.
+ */
+static struct attribute *hisi_pcie_pmu_events_attr[] = {
+	HISI_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
+	HISI_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
+	HISI_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
+	HISI_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
+	HISI_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
+	HISI_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
+	HISI_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
+	HISI_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
+	HISI_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
+	HISI_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_events_group = {
+	.name = "events",
+	.attrs = hisi_pcie_pmu_events_attr,
+};
+
+static struct attribute *hisi_pcie_pmu_format_attr[] = {
+	HISI_PMU_FORMAT_ATTR(event, "config:0-7"),
+	HISI_PMU_FORMAT_ATTR(subevent, "config:8-15"),
+	HISI_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
+	HISI_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
+	HISI_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
+	HISI_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
+	HISI_PMU_FORMAT_ATTR(port, "config2:0-15"),
+	HISI_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_format_group = {
+	.name = "format",
+	.attrs = hisi_pcie_pmu_format_attr,
+};
+
+static struct device_attribute hisi_pcie_pmu_bus_attr =
+	__ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
+	&hisi_pcie_pmu_bus_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
+	.attrs = hisi_pcie_pmu_bus_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_cpumask_attr =
+	__ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
+	&hisi_pcie_pmu_cpumask_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
+	.attrs = hisi_pcie_pmu_cpumask_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_identifier_attr =
+	__ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
+	&hisi_pcie_pmu_identifier_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
+	.attrs = hisi_pcie_pmu_identifier_attrs,
+};
+
+static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
+	&hisi_pcie_pmu_events_group,
+	&hisi_pcie_pmu_format_group,
+	&hisi_pcie_pmu_bus_attr_group,
+	&hisi_pcie_pmu_cpumask_attr_group,
+	&hisi_pcie_pmu_identifier_attr_group,
+	NULL
+};
+
+static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
+			     struct hisi_pcie_pmu *pcie_pmu)
+{
+	u16 sicl_id, device_id;
+	char *name;
+
+	pcie_pmu->base = pci_ioremap_bar(pdev, 2);
+	if (!pcie_pmu->base) {
+		pci_err(pdev, "ioremap failed for pcie_pmu resource.\n");
+		return -ENOMEM;
+	}
+
+	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_BDF, &pcie_pmu->bdf_min,
+			   &pcie_pmu->bdf_max);
+	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
+			     &sicl_id);
+	name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+			      "hisi_pcie%u_%u", sicl_id, device_id);
+	if (!name) {
+		pci_err(pdev, "failed to allocate name for PMU.\n");
+		return -ENOMEM;
+	}
+
+	pcie_pmu->pdev = pdev;
+	pcie_pmu->identifier = readl(pcie_pmu->base + HISI_PCIE_REG_VERSION);
+	pcie_pmu->pmu = (struct pmu) {
+		.name		= name,
+		.module		= THIS_MODULE,
+		.event_init	= hisi_pcie_pmu_event_init,
+		.pmu_enable	= hisi_pcie_pmu_enable,
+		.pmu_disable	= hisi_pcie_pmu_disable,
+		.add		= hisi_pcie_pmu_add,
+		.del		= hisi_pcie_pmu_del,
+		.start		= hisi_pcie_pmu_start,
+		.stop		= hisi_pcie_pmu_stop,
+		.read		= hisi_pcie_pmu_read,
+		.task_ctx_nr	= perf_invalid_context,
+		.attr_groups	= hisi_pcie_pmu_attr_groups,
+		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
+	};
+
+	return 0;
+}
+
+static int hisi_pcie_init_pmu(struct pci_dev *pdev,
+			      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int ret;
+
+	ret = hisi_pcie_alloc_pmu(pdev, pcie_pmu);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_pmu_irq_register(pdev, pcie_pmu);
+	if (ret)
+		goto err_set_pmu_fail;
+
+	ret = cpuhp_state_add_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				       &pcie_pmu->node);
+	if (ret) {
+		pci_err(pdev, "failed to register hotplug, ret = %d.\n", ret);
+		goto err_irq_unregister;
+	}
+
+	ret = perf_pmu_register(&pcie_pmu->pmu, pcie_pmu->pmu.name, -1);
+	if (ret) {
+		pci_err(pdev, "failed to register PCIe PMU, ret = %d.\n", ret);
+		goto err_hotplug_unregister;
+	}
+
+	return ret;
+
+err_hotplug_unregister:
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+
+err_irq_unregister:
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+
+err_set_pmu_fail:
+	iounmap(pcie_pmu->base);
+
+	return ret;
+}
+
+static void hisi_pcie_uninit_pmu(struct pci_dev *pdev,
+				 struct hisi_pcie_pmu *pcie_pmu)
+{
+	perf_pmu_unregister(&pcie_pmu->pmu);
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+	iounmap(pcie_pmu->base);
+}
+
+static int hisi_pcie_init_dev(struct pci_dev *pdev)
+{
+	int ret;
+
+	ret = pci_enable_device(pdev);
+	if (ret) {
+		pci_err(pdev, "failed to enable pci device, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
+	if (ret < 0) {
+		pci_err(pdev, "failed to request pci mem regions, ret = %d.\n",
+			ret);
+		pci_disable_device(pdev);
+		return ret;
+	}
+
+	pci_set_master(pdev);
+
+	return 0;
+}
+
+static void hisi_pcie_uninit_dev(struct pci_dev *pdev)
+{
+	pci_clear_master(pdev);
+	pci_release_mem_regions(pdev);
+	pci_disable_device(pdev);
+}
+
+static int hisi_pcie_pmu_probe(struct pci_dev *pdev,
+			       const struct pci_device_id *id)
+{
+	struct hisi_pcie_pmu *pcie_pmu;
+	int ret;
+
+	pcie_pmu = devm_kzalloc(&pdev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
+	if (!pcie_pmu)
+		return -ENOMEM;
+
+	ret = hisi_pcie_init_dev(pdev);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_init_pmu(pdev, pcie_pmu);
+	if (ret)
+		hisi_pcie_uninit_dev(pdev);
+
+	pci_set_drvdata(pdev, pcie_pmu);
+
+	return ret;
+}
+
+static void hisi_pcie_pmu_remove(struct pci_dev *pdev)
+{
+	hisi_pcie_uninit_pmu(pdev, pci_get_drvdata(pdev));
+	hisi_pcie_uninit_dev(pdev);
+	pci_set_drvdata(pdev, NULL);
+}
+
+static const struct pci_device_id hisi_pcie_pmu_ids[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12d) },
+	{ 0, }
+};
+MODULE_DEVICE_TABLE(pci, hisi_pcie_pmu_ids);
+
+static struct pci_driver hisi_pcie_pmu_driver = {
+	.name = "hisi_pcie_pmu",
+	.id_table = hisi_pcie_pmu_ids,
+	.probe = hisi_pcie_pmu_probe,
+	.remove = hisi_pcie_pmu_remove,
+};
+
+static int __init hisi_pcie_module_init(void)
+{
+	int ret;
+
+	ret = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				      "AP_PERF_ARM_HISI_PCIE_PMU_ONLINE",
+				      hisi_pcie_pmu_online_cpu,
+				      hisi_pcie_pmu_offline_cpu);
+	if (ret) {
+		pr_err("failed to setup PCIE PMU hotplug, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_register_driver(&hisi_pcie_pmu_driver);
+	if (ret)
+		cpuhp_remove_multi_state(
+				CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+
+	return ret;
+}
+module_init(hisi_pcie_module_init);
+
+static void __exit hisi_pcie_module_exit(void)
+{
+	pci_unregister_driver(&hisi_pcie_pmu_driver);
+	cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+}
+module_exit(hisi_pcie_module_exit);
+
+MODULE_DESCRIPTION("HiSilicon PCIe PMU driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Qi Liu <liuqi115 at huawei.com>");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 113f51f..c17861a 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -174,6 +174,7 @@ enum cpuhp_state {
 	CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
+	CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
 	CPUHP_AP_PERF_ARM_L2X0_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
-- 
2.8.1



From liuqi115 at huawei.com  Wed Apr  7 10:49:03 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Wed, 7 Apr 2021 17:49:03 +0800
Subject: [PATCH 2/2] docs: perf: Add description for HiSilicon PCIe PMU driver
In-Reply-To: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1617788943-52722-3-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported on
HiSilicon HIP09 platform, and document it to provide guidance on how to
use it.

Reviewed-by: John Garry <john.garry at huawei.com>
Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 Documentation/admin-guide/perf/hisi-pcie-pmu.rst | 103 +++++++++++++++++++++++
 1 file changed, 103 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst

diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
new file mode 100644
index 0000000..8942498
--- /dev/null
+++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
@@ -0,0 +1,103 @@
+================================================
+HiSilicon PCIe Performance Monitoring Unit (PMU)
+================================================
+
+HiSilicon PCIe Performance Monitoring Unit (PMU) is a PCIe Root Complex
+integrated End Point(RCiEP) device. On Hip09, each PCIe Core has a PMU RCiEP
+to monitor multi root ports and all Endpoints downstream these root ports.
+
+HiSilicon PCIe PMU is supported to collect performance data of PCIe bus, such
+as: bandwidth, latency etc.
+
+
+HiSilicon PCIe PMU driver
+=========================
+
+The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe
+core id.::
+
+  /sys/bus/event_source/hisi_pcie<sicl>_<core>
+
+PMU driver provides description of available events and filter options in sysfs,
+see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>.
+
+The "format" directory describes all formats of the config (events) and config1
+(filter options) fields of the perf_event_attr structure. The "events" directory
+describes all documented events shown in perf list.
+
+The "identifier" sysfs file allows users to identify the version of the
+PMU hardware device.
+
+The "bus" sysfs file allows users to get the bus number of root ports
+monitored by PMU.
+
+Example usage of perf::
+
+  $# perf list
+  hisi_pcie0_0/bw_rx/ [kernel PMU event]
+  ------------------------------------------
+
+  $# perf stat -e hisi_pcie0_0/bw_rx/ sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported for PCIe PMU.
+
+Filter options
+--------------
+
+1. Target filter
+PMU could only monitor the performance of traffic downstream target root ports
+or traffic of target Endpoint. PCIe PMU driver support "port" and "bdf"
+interfaces for users, and this two interfaces isn't supported at the same time.
+
+-port
+"port" filter can be used in all PCIe PMU events, target root port can be
+selected by configure the bitmap "port". Multi ports can be selected for
+AP-layer-events, and only one port can be selected for TL/DL-layer-events.
+
+For example, if target root port is 0000:00:00.0(x8 lanes), bit0 should be
+selected, port=0x1; if target root port is 0000:00:04.0(x4 lanes), bit8 is set,
+port=0x100; if these two root port are both monitored, port=0x101.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,port=0x1/ sleep 5
+
+-bdf
+
+"bdf" filter can only be used in bandwidth events, target Endpoint is selected
+by configure BDF to "bdf". Counter only counts the bandwidth of message
+requested by target Endpoint.
+
+For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,bdf=0x3900/ sleep 5
+
+2. Trigger filter
+event statistics start when the first time TLP length is greater/smaller
+than trigger condition. You can set the trigger condition by write
+"trig_len", and set the trigger mode by write "trig_mode". This filter can only
+be used in bandwidth events.
+
+For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0"
+means statistics start when TLP length > trigger condition, "trig_mode=1"
+means start When TLP length < condition.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,trig_len=0x4,trig_mode=1/ sleep 5
+
+3. Threshold filter
+counter counts when TLP length within the specified range. You can set the
+threshold by write "thr_len", and set the threshold mode by write "thr_mode".
+This filter can only be used in bandwidth events.
+
+For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means
+statistics when TLP length >= threshold, and "thr_mode=1" means statistics
+when TLP length < threshold.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,thr_len=0x4,thr_mode=1/ sleep 5
-- 
2.8.1



From will at kernel.org  Wed Apr  7 10:54:26 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 10:54:26 +0100
Subject: [RFC PATCH v3 03/12] iommu/io-pgtable: Introduce map_pages() as
 a page table op
In-Reply-To: <75a5d309498b8b41b5e24a2d9d36e78f@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-4-isaacm@codeaurora.org>
 <20210406115739.GD13747@willie-the-truck>
 <75a5d309498b8b41b5e24a2d9d36e78f@codeaurora.org>
Message-ID: <20210407095425.GA15057@willie-the-truck>

On Tue, Apr 06, 2021 at 02:07:41PM -0700, isaacm at codeaurora.org wrote:
> On 2021-04-06 04:57, Will Deacon wrote:
> > On Mon, Apr 05, 2021 at 12:11:03PM -0700, Isaac J. Manjarres wrote:
> > > Mapping memory into io-pgtables follows the same semantics
> > > that unmapping memory used to follow (i.e. a buffer will be
> > > mapped one page block per call to the io-pgtable code). This
> > > means that it can be optimized in the same way that unmapping
> > > memory was, so add a map_pages() callback to the io-pgtable
> > > ops structure, so that a range of pages of the same size
> > > can be mapped within the same call.
> > > 
> > > Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> > > Suggested-by: Will Deacon <will at kernel.org>
> > > ---
> > >  include/linux/io-pgtable.h | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
> > > index 2ed0c057d9e7..019149b204b8 100644
> > > --- a/include/linux/io-pgtable.h
> > > +++ b/include/linux/io-pgtable.h
> > > @@ -143,6 +143,7 @@ struct io_pgtable_cfg {
> > >   * struct io_pgtable_ops - Page table manipulation API for IOMMU
> > > drivers.
> > >   *
> > >   * @map:          Map a physically contiguous memory region.
> > > + * @map_pages:    Map a physically contiguous range of pages of the
> > > same size.
> > >   * @unmap:        Unmap a physically contiguous memory region.
> > >   * @unmap_pages:  Unmap a range of virtually contiguous pages of
> > > the same size.
> > >   * @iova_to_phys: Translate iova to physical address.
> > > @@ -153,6 +154,9 @@ struct io_pgtable_cfg {
> > >  struct io_pgtable_ops {
> > >  	int (*map)(struct io_pgtable_ops *ops, unsigned long iova,
> > >  		   phys_addr_t paddr, size_t size, int prot, gfp_t gfp);
> > > +	int (*map_pages)(struct io_pgtable_ops *ops, unsigned long iova,
> > > +			 phys_addr_t paddr, size_t pgsize, size_t pgcount,
> > > +			 int prot, gfp_t gfp, size_t *mapped);
> > 
> > How about returning 'size_t' and using IS_ERR_VALUE() instead of adding
> > the extra 'mapped' argument (i.e. return the size of the region mapped
> > or an error code)? I don't think we realistically need to care about map
> > sizes that overlap with the error region.
> > 
> I'd given that a shot before, but the problem that I kept running into was
> that
> in case of an error, if I return an error code, I don't know how much memory
> was mapped, so that I can invoke iommu_unmap from __iommu_map with that size
> to
> undo the partial mappings from a map_pages() call.

Ah yes, sorry, I see it now. So keep this as you've got it. Pushing the
cleanup path deeper doesn't feel like the right thing to do.

Will


From marex at denx.de  Wed Apr  7 10:55:56 2021
From: marex at denx.de (Marek Vasut)
Date: Wed, 7 Apr 2021 11:55:56 +0200
Subject: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data
 sampling edge select
In-Reply-To: <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>
References: <20201224061832.92010-1-marex@denx.de>
 <YFfvjyllBa/tqTqI@pendragon.ideasonboard.com>
 <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>
Message-ID: <3a25b8db-8968-0f07-21fe-69fa43f438f5@denx.de>

On 3/22/21 11:29 AM, Marek Vasut wrote:
> On 3/22/21 2:14 AM, Laurent Pinchart wrote:
>> Hi Marek,
> 
> Hi,
> 
> [...]
> 
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml 
>>> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
>>> index e5e3c72630cf..399a6528780a 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
>>> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
>>> @@ -74,6 +74,13 @@ properties:
>>> ????? additionalProperties: false
>>> +? pixelclk-active:
>>> +??? description: |
>>> +????? Data sampling on rising or falling edge.
>>> +????? Use 0 to sample pixel data on rising edge and
>>> +????? Use 1 to sample pixel data on falling edge and
>>> +??? enum: [0, 1]
>>
>> The idea is good, but instead of adding a custom property, how about
>> reusing the pclk-sample property defined in
>> ../../media/video-interfaces.yaml ?
> 
> Repeating myself from V1 discussion ... Either is fine by me, but I 
> think pixelclk-active, which comes from panel-timings.yaml is closer to 
> the video than multimedia bindings.

Was there ever any reply from Rob on this ?


From musamaanjum at gmail.com  Wed Apr  7 10:56:34 2021
From: musamaanjum at gmail.com (Muhammad Usama Anjum)
Date: Wed, 7 Apr 2021 14:56:34 +0500
Subject: [PATCH] ASoC: fsl: sunxi: remove redundant dev_err call
Message-ID: <20210407095634.GA1379642@LEGION>

devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.

Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
---
 sound/soc/fsl/fsl_aud2htx.c   | 4 +---
 sound/soc/fsl/fsl_easrc.c     | 4 +---
 sound/soc/sunxi/sun4i-codec.c | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/fsl/fsl_aud2htx.c b/sound/soc/fsl/fsl_aud2htx.c
index d70d5e75a30c..a328697511f7 100644
--- a/sound/soc/fsl/fsl_aud2htx.c
+++ b/sound/soc/fsl/fsl_aud2htx.c
@@ -198,10 +198,8 @@ static int fsl_aud2htx_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(regs)) {
-		dev_err(&pdev->dev, "failed ioremap\n");
+	if (IS_ERR(regs))
 		return PTR_ERR(regs);
-	}
 
 	aud2htx->regmap = devm_regmap_init_mmio(&pdev->dev, regs,
 						&fsl_aud2htx_regmap_config);
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 5e33afe87c4a..b1765c7d3bcd 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1889,10 +1889,8 @@ static int fsl_easrc_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	regs = devm_ioremap_resource(dev, res);
-	if (IS_ERR(regs)) {
-		dev_err(&pdev->dev, "failed ioremap\n");
+	if (IS_ERR(regs))
 		return PTR_ERR(regs);
-	}
 
 	easrc->paddr = res->start;
 
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 2173991c13db..6f3d9148a185 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1711,10 +1711,8 @@ static int sun4i_codec_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(base)) {
-		dev_err(&pdev->dev, "Failed to map the registers\n");
+	if (IS_ERR(base))
 		return PTR_ERR(base);
-	}
 
 	quirks = of_device_get_match_data(&pdev->dev);
 	if (quirks == NULL) {
-- 
2.25.1



From will at kernel.org  Wed Apr  7 10:57:06 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 10:57:06 +0100
Subject: [RFC PATCH v3 09/12] iommu/io-pgtable-arm: Implement
 arm_lpae_unmap_pages()
In-Reply-To: <8f78f5d051c9d40981fc6868c9245cd3@codeaurora.org>
References: <20210405191112.28192-1-isaacm@codeaurora.org>
 <20210405191112.28192-10-isaacm@codeaurora.org>
 <20210406121552.GF13747@willie-the-truck>
 <8f78f5d051c9d40981fc6868c9245cd3@codeaurora.org>
Message-ID: <20210407095706.GB15057@willie-the-truck>

On Tue, Apr 06, 2021 at 02:02:26PM -0700, isaacm at codeaurora.org wrote:
> On 2021-04-06 05:15, Will Deacon wrote:
> > On Mon, Apr 05, 2021 at 12:11:09PM -0700, Isaac J. Manjarres wrote:
> > > Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> > > format.
> > > 
> > > Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> > > Suggested-by: Will Deacon <will at kernel.org>
> > > ---
> > >  drivers/iommu/io-pgtable-arm.c | 124
> > > +++++++++++++++++++++++++++------
> > >  1 file changed, 104 insertions(+), 20 deletions(-)
> > 
> > [...]
> > 
> > > +static size_t arm_lpae_unmap_pages(struct io_pgtable_ops *ops,
> > > unsigned long iova,
> > > +				   size_t pgsize, size_t pgcount,
> > > +				   struct iommu_iotlb_gather *gather)
> > > +{
> > > +	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
> > > +	struct io_pgtable_cfg *cfg = &data->iop.cfg;
> > > +	arm_lpae_iopte *ptep = data->pgd;
> > > +	long iaext = (s64)iova >> cfg->ias;
> > > +	size_t unmapped = 0, unmapped_page;
> > > +	int last_lvl;
> > > +	size_t table_size, pages, tbl_offset, max_entries;
> > > +
> > > +	if (WARN_ON(!pgsize || (pgsize & cfg->pgsize_bitmap) != pgsize ||
> > > !pgcount))
> > > +		return 0;
> > > +
> > > +	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> > > +		iaext = ~iaext;
> > > +	if (WARN_ON(iaext))
> > > +		return 0;
> > > +
> > > +	/*
> > > +	 * Calculating the page table size here helps avoid situations where
> > > +	 * a page range that is being unmapped may be mapped at the same
> > > level
> > > +	 * but not mapped by the same tables. Allowing such a scenario to
> > > +	 * occur can complicate the logic in arm_lpae_split_blk_unmap().
> > > +	 */
> > > +	last_lvl = ARM_LPAE_BLOCK_SIZE_LVL(pgsize, data);
> > > +
> > > +	if (last_lvl == data->start_level)
> > > +		table_size = ARM_LPAE_PGD_SIZE(data);
> > > +	else
> > > +		table_size = ARM_LPAE_GRANULE(data);
> > > +
> > > +	max_entries = table_size / sizeof(*ptep);
> > > +
> > > +	while (pgcount) {
> > > +		tbl_offset = ARM_LPAE_LVL_IDX(iova, last_lvl, data);
> > > +		pages = min_t(size_t, pgcount, max_entries - tbl_offset);
> > > +		unmapped_page = __arm_lpae_unmap(data, gather, iova, pgsize,
> > > +						 pages, data->start_level,
> > > +						 ptep);
> > > +		if (!unmapped_page)
> > > +			break;
> > > +
> > > +		unmapped += unmapped_page;
> > > +		iova += unmapped_page;
> > > +		pgcount -= pages;
> > > +	}
> > 
> > Robin has some comments on the first version of this patch, and I
> > don't think you
> > addressed them:
> > 
> > https://lore.kernel.org/r/b93fa0b1-e2a4-1aad-8b88-4d0dfecdfef7 at arm.com
> > 
> > I'm inclined to agree that iterating here doesn't make a lot of sense --
> > we've already come back out of the page-table walk, so I think we should
> > just return to the caller (who is well prepared to handle a partial
> > unmap).
> > Same for the map side of things.
> > 
> > If we get numbers showing that this is causing a performance issue, then
> > we should rework the page-table code to handle this at the lower level
> > (because I doubt the loop that you have is really worse than returning
> > to
> > the caller anyway).
> > 
> Sorry, I seem to have overlooked those comments.
> 
> I will go ahead and address them. I think it might be ideal to try to do
> as much work as possible in the io-pgtable level, so as to minimize the
> number
> of indirect calls incurred by jumping back and forth between iommu fwk,
> iommu
> driver, and io-pgtable code.
> 
> Perhaps we can try something like how the linear mappings are created on
> arm64 i.e.
> on the previous level, we can determine how many pages can be unmapped in
> one page table
> in one iteration, and on the subsequent iterations, we can tackle another
> page table at
> the lower level. Looking at the code, it doesn't seem too difficult to add
> this in. Thoughts?

I don't object to getting there eventually, but as an initial step I think
returning back to the caller is perfectly reasonable and will probably make
the patches easier to review. In other words, implement the simple (correct)
thing first, and then have subsequent patches to improve it.

Will


From snawrocki at kernel.org  Wed Apr  7 11:03:39 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Wed, 7 Apr 2021 12:03:39 +0200
Subject: [PATCH] clk: exynos7: Mark aclk_fsys1_200 as critical
In-Reply-To: <20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com>
References: <20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com>
Message-ID: <53be0d9d-a64a-9108-85f0-40ac360757c4@kernel.org>

On 24.10.2020 17:43, Pawe? Chmiel wrote:
> This clock must be always enabled to allow access to any registers in
> fsys1 CMU. Until proper solution based on runtime PM is applied
> (similar to what was done for Exynos5433), mark that clock as critical
> so it won't be disabled.
> 
> It was observed on Samsung Galaxy S6 device (based on Exynos7420), where
> UFS module is probed before pmic used to power that device.
> In this case defer probe was happening and that clock was disabled by
> UFS driver, causing whole boot to hang on next CMU access.
> 
> Signed-off-by: Pawe? Chmiel <pawel.mikolaj.chmiel at gmail.com>
> ---
>   drivers/clk/samsung/clk-exynos7.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos7.c b/drivers/clk/samsung/clk-exynos7.c
> index c1ff715e960c..1048d83f097b 100644
> --- a/drivers/clk/samsung/clk-exynos7.c
> +++ b/drivers/clk/samsung/clk-exynos7.c
> @@ -538,7 +538,8 @@ static const struct samsung_gate_clock top1_gate_clks[] __initconst = {
>   		ENABLE_ACLK_TOP13, 28, CLK_SET_RATE_PARENT |
>   		CLK_IS_CRITICAL, 0),

As this patch can be backported up to the commit that introduced regression
I have applied it instead of your v3, with a comment as below.

+       /*
+        * This clock is required for the CMU_FSYS1 registers access, keep it
+        * enabled permanently until proper runtime PM support is added.
+        */

>   	GATE(CLK_ACLK_FSYS1_200, "aclk_fsys1_200", "dout_aclk_fsys1_200",
> -		ENABLE_ACLK_TOP13, 24, CLK_SET_RATE_PARENT, 0),
> +		ENABLE_ACLK_TOP13, 24, CLK_SET_RATE_PARENT |
> +		CLK_IS_CRITICAL, 0),
>   
>   	GATE(CLK_SCLK_PHY_FSYS1_26M, "sclk_phy_fsys1_26m",
>   		"dout_sclk_phy_fsys1_26m", ENABLE_SCLK_TOP1_FSYS11,
  
--
Regards,
Sylwester


From musamaanjum at gmail.com  Wed Apr  7 11:10:47 2021
From: musamaanjum at gmail.com (Muhammad Usama Anjum)
Date: Wed, 7 Apr 2021 15:10:47 +0500
Subject: [PATCH] staging: axis-fifo: media/meson: remove redundant dev_err call
Message-ID: <20210407101047.GA1491258@LEGION>

devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.

Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
---
 drivers/staging/axis-fifo/axis-fifo.c   | 1 -
 drivers/staging/media/meson/vdec/vdec.c | 8 ++------
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c
index 2bb1c2e9cb57..ed9281089738 100644
--- a/drivers/staging/axis-fifo/axis-fifo.c
+++ b/drivers/staging/axis-fifo/axis-fifo.c
@@ -853,7 +853,6 @@ static int axis_fifo_probe(struct platform_device *pdev)
 	fifo->base_addr = devm_ioremap_resource(fifo->dt_device, r_mem);
 	if (IS_ERR(fifo->base_addr)) {
 		rc = PTR_ERR(fifo->base_addr);
-		dev_err(fifo->dt_device, "can't remap IO resource (%d)\n", rc);
 		goto err_initial;
 	}
 
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 5d4db7a5b4b5..e51d69c4729d 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
 	core->dos_base = devm_ioremap_resource(dev, r);
-	if (IS_ERR(core->dos_base)) {
-		dev_err(dev, "Couldn't remap DOS memory\n");
+	if (IS_ERR(core->dos_base))
 		return PTR_ERR(core->dos_base);
-	}
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
 	core->esparser_base = devm_ioremap_resource(dev, r);
-	if (IS_ERR(core->esparser_base)) {
-		dev_err(dev, "Couldn't remap ESPARSER memory\n");
+	if (IS_ERR(core->esparser_base))
 		return PTR_ERR(core->esparser_base);
-	}
 
 	core->regmap_ao =
 		syscon_regmap_lookup_by_phandle(dev->of_node,
-- 
2.25.1



From michal.simek at xilinx.com  Wed Apr  7 11:13:11 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Wed, 7 Apr 2021 12:13:11 +0200
Subject: [PATCH v2 0/2] Update ZYNQMP clock configuration
In-Reply-To: <20210322061754.1065367-1-punit1.agrawal@toshiba.co.jp>
References: <20210322061754.1065367-1-punit1.agrawal@toshiba.co.jp>
Message-ID: <de18fa79-1e83-30e1-6b41-f41360e22837@xilinx.com>

Hi Stephen,

On 3/22/21 7:17 AM, Punit Agrawal wrote:
> Hi,
> 
> Here are a couple of patches defaulting the ZYNQMP clock configuration
> if it's dependencies are available. The clock driver is needed for
> peripherals such as micro sd card required for booting.
> 
> The second posting adds a patch to drop the redundant dependency on
> ARCH_ZYNQMP requested by Michal.
> 
> Thanks,
> Punit
> 
> Previous posting -
> 
> [0] https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
> 
> Punit Agrawal (2):
>   clk: zynqmp: Enable the driver if ZYNQMP_FIRMWARE is selected
>   clk: zynqmp: Drop dependency on ARCH_ZYNQMP
> 
>  drivers/clk/zynqmp/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Can you please take this series? Or do you want me to take it via my tree?

Thanks,
Michal


From steven.price at arm.com  Wed Apr  7 11:20:18 2021
From: steven.price at arm.com (Steven Price)
Date: Wed, 7 Apr 2021 11:20:18 +0100
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210331184311.GA10737@arm.com>
References: <20210312151902.17853-1-steven.price@arm.com>
 <20210312151902.17853-3-steven.price@arm.com>
 <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com>
 <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
Message-ID: <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>

On 31/03/2021 19:43, Catalin Marinas wrote:
> On Wed, Mar 31, 2021 at 11:41:20AM +0100, Steven Price wrote:
>> On 31/03/2021 10:32, David Hildenbrand wrote:
>>> On 31.03.21 11:21, Catalin Marinas wrote:
>>>> On Wed, Mar 31, 2021 at 09:34:44AM +0200, David Hildenbrand wrote:
>>>>> On 30.03.21 12:30, Catalin Marinas wrote:
>>>>>> On Mon, Mar 29, 2021 at 05:06:51PM +0100, Steven Price wrote:
>>>>>>> On 28/03/2021 13:21, Catalin Marinas wrote:
>>>>>>>> However, the bigger issue is that Stage 2 cannot disable
>>>>>>>> tagging for Stage 1 unless the memory is Non-cacheable or
>>>>>>>> Device at S2. Is there a way to detect what gets mapped in
>>>>>>>> the guest as Normal Cacheable memory and make sure it's
>>>>>>>> only early memory or hotplug but no ZONE_DEVICE (or
>>>>>>>> something else like on-chip memory)???? If we can't
>>>>>>>> guarantee that all Cacheable memory given to a guest
>>>>>>>> supports tags, we should disable the feature altogether.
>>>>>>>
>>>>>>> In stage 2 I believe we only have two types of mapping -
>>>>>>> 'normal' or DEVICE_nGnRE (see stage2_map_set_prot_attr()).
>>>>>>> Filtering out the latter is a case of checking the 'device'
>>>>>>> variable, and makes sense to avoid the overhead you
>>>>>>> describe.
>>>>>>>
>>>>>>> This should also guarantee that all stage-2 cacheable
>>>>>>> memory supports tags,
>>>>>>> as kvm_is_device_pfn() is simply !pfn_valid(), and
>>>>>>> pfn_valid() should only
>>>>>>> be true for memory that Linux considers "normal".
>>>>>
>>>>> If you think "normal" == "normal System RAM", that's wrong; see
>>>>> below.
>>>>
>>>> By "normal" I think both Steven and I meant the Normal Cacheable memory
>>>> attribute (another being the Device memory attribute).
>>
>> Sadly there's no good standardised terminology here. Aarch64 provides the
>> "normal (cacheable)" definition. Memory which is mapped as "Normal
>> Cacheable" is implicitly MTE capable when shared with a guest (because the
>> stage 2 mappings don't allow restricting MTE other than mapping it as Device
>> memory).
>>
>> So MTE also forces us to have a definition of memory which is "bog standard
>> memory"[1] separate from the mapping attributes. This is the main memory
>> which fully supports MTE.
>>
>> Separate from the "bog standard" we have the "special"[1] memory, e.g.
>> ZONE_DEVICE memory may be mapped as "Normal Cacheable" at stage 1 but that
>> memory may not support MTE tags. This memory can only be safely shared with
>> a guest in the following situations:
>>
>>   1. MTE is completely disabled for the guest
>>
>>   2. The stage 2 mappings are 'device' (e.g. DEVICE_nGnRE)
>>
>>   3. We have some guarantee that guest MTE access are in some way safe.
>>
>> (1) is the situation today (without this patch series). But it prevents the
>> guest from using MTE in any form.
>>
>> (2) is pretty terrible for general memory, but is the get-out clause for
>> mapping devices into the guest.
>>
>> (3) isn't something we have any architectural way of discovering. We'd need
>> to know what the device did with the MTE accesses (and any caches between
>> the CPU and the device) to ensure there aren't any side-channels or h/w
>> lockup issues. We'd also need some way of describing this memory to the
>> guest.
>>
>> So at least for the time being the approach is to avoid letting a guest with
>> MTE enabled have access to this sort of memory.
> 
> When a slot is added by the VMM, if it asked MTE in guest (I guess
> that's an opt-in by the VMM, haven't checked the other patches), can we
> reject it if it's is going to be mapped as Normal Cacheable but it is a
> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
> check for ZONE_DEVICE)? This way we don't need to do more expensive
> checks in set_pte_at().

The problem is that KVM allows the VMM to change the memory backing a 
slot while the guest is running. This is obviously useful for the likes 
of migration, but ultimately means that even if you were to do checks at 
the time of slot creation, you would need to repeat the checks at 
set_pte_at() time to ensure a mischievous VMM didn't swap the page for a 
problematic one.

> We could simplify the set_pte_at() further if we require that the VMM
> has a PROT_MTE mapping. This does not mean it cannot have two mappings,
> the other without PROT_MTE. But at least we get a set_pte_at() when
> swapping in which has PROT_MTE.

That is certainly an option - but from what I've seen of trying to 
implement a VMM to support MTE, the PROT_MTE mapping is not what you 
actually want in user space. Two mappings is possible but is likely to 
complicate the VMM.

> We could add another PROT_TAGGED or something which means PG_mte_tagged
> set but still mapped as Normal Untagged. It's just that we are short of
> pte bits for another flag.

That could help here - although it's slightly odd as you're asking the 
kernel to track the tags, but not allowing user space (direct) access to 
them. Like you say using us the precious bits for this seems like it 
might be short-sighted.

> Can we somehow identify when the S2 pte is set and can we get access to
> the prior swap pte? This way we could avoid changes to set_pte_at() for
> S2 faults.
> 

Unless I'm misunderstanding the code the swap information is (only) 
stored in the stage 1 user-space VMM PTE. When we get a stage 2 fault 
this triggers a corresponding access attempt to the VMM's address space. 
It's at this point when populating the VMM's page tables that the swap 
information is discovered.

The problem at the moment is a mismatch regarding whether the page needs 
tags or not. The VMM's mapping can (currently) be !PROT_MTE which means 
we wouldn't normally require restoring/zeroing the tags. However the 
stage 2 access requires that the tags be preserved. Requiring PROT_MTE 
(or PROT_TAGGED as above) would certainly simplify the handling in the 
kernel.

Of course I did propose the 'requiring PROT_MTE' approach before which 
led to a conversation[1] ending with a conclusion[2] that:

    I'd much rather the kernel just
    provided us with an API for what we want, which is (1) the guest
    RAM as just RAM with no tag checking and separately (2) some
    mechanism yet-to-be-designed which lets us bulk copy a page's
    worth of tags for migration.

Which is what I've implemented ;)

Do you think it's worth investigating the PROT_TAGGED approach as a 
middle ground? My gut feeling is that it's a waste of a VM flag, but I 
agree it would certainly make the code cleaner.

Steve

[1] 
https://lore.kernel.org/kvmarm/CAFEAcA85fiqA206FuFANKbV_3GkfY1F8Gv7MP58BgTT81bs9kA at mail.gmail.com/
[2] 
https://lore.kernel.org/kvmarm/CAFEAcA_K47jKSp46DFK-AKWv6MD1pkrEB6FNz=HNGdxmBDCSbw at mail.gmail.com/


From adrian.hunter at intel.com  Wed Apr  7 11:21:25 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Wed, 7 Apr 2021 13:21:25 +0300
Subject: [PATCH v15 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <5536f19fbbcfed1177a63458c6bd0b42ee6aa2e2.1617731442.git.asutoshd@codeaurora.org>
References: <cover.1617731442.git.asutoshd@codeaurora.org>
 <5536f19fbbcfed1177a63458c6bd0b42ee6aa2e2.1617731442.git.asutoshd@codeaurora.org>
Message-ID: <d1e694cb-e3ba-6066-d0c0-8c17120e7ba5@intel.com>

On 6/04/21 8:52 pm, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes.
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

v15 seems to be missing the updates to ufs_debugfs_get/put_user_access
that were in v14:


@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 	up(&hba->host_sem);
 }
 

Also from last comments, the issue below:

<SNIP>

> +#ifdef CONFIG_PM_SLEEP
> +static int ufshcd_wl_poweroff(struct device *dev)
> +{
> +	ufshcd_wl_shutdown(dev);

This turned out to be wrong.  This is a PM op and SCSI has already
quiesced the sdev's.  All that is needed is:

	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);




From john.garry at huawei.com  Wed Apr  7 11:32:47 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:47 +0800
Subject: [PATCH v3 3/6] perf pmu: Add pmu_events_map__find()
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-4-git-send-email-john.garry@huawei.com>

Add a function to find the common PMU map for the system.

For arm64, a special variant is added. This is because arm64 supports
heterogeneous CPU systems. As such, it cannot be guaranteed that the cpumap
is same for all CPUs. So in case of heterogeneous systems, don't return
a cpumap.

Tested-by: Paul A. Clarke <pc at us.ibm.com>
Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 tools/perf/arch/arm64/util/Build  |  1 +
 tools/perf/arch/arm64/util/pmu.c  | 25 +++++++++++++++++++++++++
 tools/perf/tests/pmu-events.c     |  2 +-
 tools/perf/util/metricgroup.c     |  7 +++----
 tools/perf/util/pmu.c             |  5 +++++
 tools/perf/util/pmu.h             |  1 +
 tools/perf/util/s390-sample-raw.c |  4 +---
 7 files changed, 37 insertions(+), 8 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/pmu.c

diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index ead2f2275eee..9fcb4e68add9 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -2,6 +2,7 @@ perf-y += header.o
 perf-y += machine.o
 perf-y += perf_regs.o
 perf-y += tsc.o
+perf-y += pmu.o
 perf-y += kvm-stat.o
 perf-$(CONFIG_DWARF)     += dwarf-regs.o
 perf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
new file mode 100644
index 000000000000..d3259d61ca75
--- /dev/null
+++ b/tools/perf/arch/arm64/util/pmu.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "../../util/cpumap.h"
+#include "../../util/pmu.h"
+
+struct pmu_events_map *pmu_events_map__find(void)
+{
+	struct perf_pmu *pmu = NULL;
+
+	while ((pmu = perf_pmu__scan(pmu))) {
+		if (!is_pmu_core(pmu->name))
+			continue;
+
+		/*
+		 * The cpumap should cover all CPUs. Otherwise, some CPUs may
+		 * not support some events or have different event IDs.
+		 */
+		if (pmu->cpus->nr != cpu__max_cpu())
+			return NULL;
+
+		return perf_pmu__find_map(pmu);
+	}
+
+	return NULL;
+}
diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index cb5b25d2fb27..b8aff8fb50d8 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -539,7 +539,7 @@ static int resolve_metric_simple(struct expr_parse_ctx *pctx,
 
 static int test_parsing(void)
 {
-	struct pmu_events_map *cpus_map = perf_pmu__find_map(NULL);
+	struct pmu_events_map *cpus_map = pmu_events_map__find();
 	struct pmu_events_map *map;
 	struct pmu_event *pe;
 	int i, j, k;
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 37fe34a5d93d..8336dd8e8098 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -618,7 +618,7 @@ static int metricgroup__print_sys_event_iter(struct pmu_event *pe, void *data)
 void metricgroup__print(bool metrics, bool metricgroups, char *filter,
 			bool raw, bool details)
 {
-	struct pmu_events_map *map = perf_pmu__find_map(NULL);
+	struct pmu_events_map *map = pmu_events_map__find();
 	struct pmu_event *pe;
 	int i;
 	struct rblist groups;
@@ -1254,8 +1254,7 @@ int metricgroup__parse_groups(const struct option *opt,
 			      struct rblist *metric_events)
 {
 	struct evlist *perf_evlist = *(struct evlist **)opt->value;
-	struct pmu_events_map *map = perf_pmu__find_map(NULL);
-
+	struct pmu_events_map *map = pmu_events_map__find();
 
 	return parse_groups(perf_evlist, str, metric_no_group,
 			    metric_no_merge, NULL, metric_events, map);
@@ -1274,7 +1273,7 @@ int metricgroup__parse_groups_test(struct evlist *evlist,
 
 bool metricgroup__has_metric(const char *metric)
 {
-	struct pmu_events_map *map = perf_pmu__find_map(NULL);
+	struct pmu_events_map *map = pmu_events_map__find();
 	struct pmu_event *pe;
 	int i;
 
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 88da5cf6aee8..419ef6c4fbc0 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -717,6 +717,11 @@ struct pmu_events_map *perf_pmu__find_map(struct perf_pmu *pmu)
 	return map;
 }
 
+struct pmu_events_map *__weak pmu_events_map__find(void)
+{
+	return perf_pmu__find_map(NULL);
+}
+
 bool pmu_uncore_alias_match(const char *pmu_name, const char *name)
 {
 	char *tmp = NULL, *tok, *str;
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 8164388478c6..012317229488 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -114,6 +114,7 @@ void pmu_add_cpu_aliases_map(struct list_head *head, struct perf_pmu *pmu,
 			     struct pmu_events_map *map);
 
 struct pmu_events_map *perf_pmu__find_map(struct perf_pmu *pmu);
+struct pmu_events_map *pmu_events_map__find(void);
 bool pmu_uncore_alias_match(const char *pmu_name, const char *name);
 void perf_pmu_free_alias(struct perf_pmu_alias *alias);
 
diff --git a/tools/perf/util/s390-sample-raw.c b/tools/perf/util/s390-sample-raw.c
index cfcf8d534d76..08ec3c3ae0ee 100644
--- a/tools/perf/util/s390-sample-raw.c
+++ b/tools/perf/util/s390-sample-raw.c
@@ -160,11 +160,9 @@ static void s390_cpumcfdg_dump(struct perf_sample *sample)
 	const char *color = PERF_COLOR_BLUE;
 	struct cf_ctrset_entry *cep, ce;
 	struct pmu_events_map *map;
-	struct perf_pmu pmu;
 	u64 *p;
 
-	memset(&pmu, 0, sizeof(pmu));
-	map = perf_pmu__find_map(&pmu);
+	map = pmu_events_map__find();
 	while (offset < len) {
 		cep = (struct cf_ctrset_entry *)(buf + offset);
 
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:46 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:46 +0800
Subject: [PATCH v3 2/6] perf test: Handle metric reuse in pmu-events parsing
 test
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-3-git-send-email-john.garry@huawei.com>

The pmu-events parsing test does not handle metric reuse at all.

Introduce some simple handling to resolve metrics who reference other
metrics.

Tested-by: Paul A. Clarke <pc at us.ibm.com>
Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 tools/perf/tests/pmu-events.c | 81 +++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index 0ca6a5a53523..cb5b25d2fb27 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -12,6 +12,7 @@
 #include "util/evlist.h"
 #include "util/expr.h"
 #include "util/parse-events.h"
+#include "metricgroup.h"
 
 struct perf_pmu_test_event {
 	/* used for matching against events from generated pmu-events.c */
@@ -471,6 +472,71 @@ static void expr_failure(const char *msg,
 	pr_debug("On expression %s\n", pe->metric_expr);
 }
 
+struct metric {
+	struct list_head list;
+	struct metric_ref metric_ref;
+};
+
+static int resolve_metric_simple(struct expr_parse_ctx *pctx,
+				 struct list_head *compound_list,
+				 struct pmu_events_map *map,
+				 const char *metric_name)
+{
+	struct hashmap_entry *cur, *cur_tmp;
+	struct metric *metric, *tmp;
+	size_t bkt;
+	bool all;
+	int rc;
+
+	do {
+		all = true;
+		hashmap__for_each_entry_safe((&pctx->ids), cur, cur_tmp, bkt) {
+			struct metric_ref *ref;
+			struct pmu_event *pe;
+
+			pe = metricgroup__find_metric(cur->key, map);
+			if (!pe)
+				continue;
+
+			if (!strcmp(metric_name, (char *)cur->key)) {
+				pr_warning("Recursion detected for metric %s\n", metric_name);
+				rc = -1;
+				goto out_err;
+			}
+
+			all = false;
+
+			/* The metric key itself needs to go out.. */
+			expr__del_id(pctx, cur->key);
+
+			metric = malloc(sizeof(*metric));
+			if (!metric) {
+				rc = -ENOMEM;
+				goto out_err;
+			}
+
+			ref = &metric->metric_ref;
+			ref->metric_name = pe->metric_name;
+			ref->metric_expr = pe->metric_expr;
+			list_add_tail(&metric->list, compound_list);
+
+			rc = expr__find_other(pe->metric_expr, NULL, pctx, 0);
+			if (rc)
+				goto out_err;
+			break; /* The hashmap has been modified, so restart */
+		}
+	} while (!all);
+
+	return 0;
+
+out_err:
+	list_for_each_entry_safe(metric, tmp, compound_list, list)
+		free(metric);
+
+	return rc;
+
+}
+
 static int test_parsing(void)
 {
 	struct pmu_events_map *cpus_map = perf_pmu__find_map(NULL);
@@ -488,7 +554,9 @@ static int test_parsing(void)
 			break;
 		j = 0;
 		for (;;) {
+			struct metric *metric, *tmp;
 			struct hashmap_entry *cur;
+			LIST_HEAD(compound_list);
 			size_t bkt;
 
 			pe = &map->table[j++];
@@ -504,6 +572,13 @@ static int test_parsing(void)
 				continue;
 			}
 
+			if (resolve_metric_simple(&ctx, &compound_list, map,
+						  pe->metric_name)) {
+				expr_failure("Could not resolve metrics", map, pe);
+				ret++;
+				goto exit; /* Don't tolerate errors due to severity */
+			}
+
 			/*
 			 * Add all ids with a made up value. The value may
 			 * trigger divide by zero when subtracted and so try to
@@ -519,6 +594,11 @@ static int test_parsing(void)
 					ret++;
 			}
 
+			list_for_each_entry_safe(metric, tmp, &compound_list, list) {
+				expr__add_ref(&ctx, &metric->metric_ref);
+				free(metric);
+			}
+
 			if (expr__parse(&result, &ctx, pe->metric_expr, 0)) {
 				expr_failure("Parse failed", map, pe);
 				ret++;
@@ -527,6 +607,7 @@ static int test_parsing(void)
 		}
 	}
 	/* TODO: fail when not ok */
+exit:
 	return ret == 0 ? TEST_OK : TEST_SKIP;
 }
 
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:48 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:48 +0800
Subject: [PATCH v3 4/6] perf vendor events arm64: Add Hisi hip08 L1 metrics
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-5-git-send-email-john.garry@huawei.com>

Add L1 metrics. Formula is as consistent as possible with MAN pages
description for these metrics.

Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 .../arch/arm64/hisilicon/hip08/metrics.json   | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json

diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
new file mode 100644
index 000000000000..dc5ff3051639
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
@@ -0,0 +1,30 @@
+[
+    {
+        "MetricExpr": "FETCH_BUBBLE / (4 * CPU_CYCLES)",
+        "PublicDescription": "Frontend bound L1 topdown metric",
+        "BriefDescription": "Frontend bound L1 topdown metric",
+        "MetricGroup": "TopDownL1",
+        "MetricName": "frontend_bound"
+    },
+    {
+        "MetricExpr": "(INST_SPEC - INST_RETIRED) / (4 * CPU_CYCLES)",
+        "PublicDescription": "Bad Speculation L1 topdown metric",
+        "BriefDescription": "Bad Speculation L1 topdown metric",
+        "MetricGroup": "TopDownL1",
+        "MetricName": "bad_speculation"
+    },
+    {
+        "MetricExpr": "INST_RETIRED / (CPU_CYCLES * 4)",
+        "PublicDescription": "Retiring L1 topdown metric",
+        "BriefDescription": "Retiring L1 topdown metric",
+        "MetricGroup": "TopDownL1",
+        "MetricName": "retiring"
+    },
+    {
+        "MetricExpr": "1 - (frontend_bound + bad_speculation + retiring)",
+        "PublicDescription": "Backend Bound L1 topdown metric",
+        "BriefDescription": "Backend Bound L1 topdown metric",
+        "MetricGroup": "TopDownL1",
+        "MetricName": "backend_bound"
+    },
+]
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:45 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:45 +0800
Subject: [PATCH v3 1/6] perf metricgroup: Make find_metric() public with name
 change
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-2-git-send-email-john.garry@huawei.com>

Function find_metric() is required for the metric processing in the
pmu-events testcase, so make it public. Also change the name to include
"metricgroup".

Tested-by: Paul A. Clarke <pc at us.ibm.com>
Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 tools/perf/util/metricgroup.c | 5 +++--
 tools/perf/util/metricgroup.h | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 6acb44ad439b..37fe34a5d93d 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -900,7 +900,8 @@ static int __add_metric(struct list_head *metric_list,
 		    (match_metric(__pe->metric_group, __metric) ||	\
 		     match_metric(__pe->metric_name, __metric)))
 
-static struct pmu_event *find_metric(const char *metric, struct pmu_events_map *map)
+struct pmu_event *metricgroup__find_metric(const char *metric,
+					   struct pmu_events_map *map)
 {
 	struct pmu_event *pe;
 	int i;
@@ -985,7 +986,7 @@ static int __resolve_metric(struct metric *m,
 			struct expr_id *parent;
 			struct pmu_event *pe;
 
-			pe = find_metric(cur->key, map);
+			pe = metricgroup__find_metric(cur->key, map);
 			if (!pe)
 				continue;
 
diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
index ed1b9392e624..1424e7c1af77 100644
--- a/tools/perf/util/metricgroup.h
+++ b/tools/perf/util/metricgroup.h
@@ -44,7 +44,8 @@ int metricgroup__parse_groups(const struct option *opt,
 			      bool metric_no_group,
 			      bool metric_no_merge,
 			      struct rblist *metric_events);
-
+struct pmu_event *metricgroup__find_metric(const char *metric,
+					   struct pmu_events_map *map);
 int metricgroup__parse_groups_test(struct evlist *evlist,
 				   struct pmu_events_map *map,
 				   const char *str,
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:49 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:49 +0800
Subject: [PATCH v3 5/6] perf vendor events arm64: Add Hisi hip08 L2 metrics
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-6-git-send-email-john.garry@huawei.com>

Add L2 metrics.

Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 .../arch/arm64/hisilicon/hip08/metrics.json   | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
index dc5ff3051639..dda898d23c2d 100644
--- a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
@@ -27,4 +27,46 @@
         "MetricGroup": "TopDownL1",
         "MetricName": "backend_bound"
     },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x201d@ / CPU_CYCLES",
+        "PublicDescription": "Fetch latency bound L2 topdown metric",
+        "BriefDescription": "Fetch latency bound L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "fetch_latency_bound"
+    },
+    {
+        "MetricExpr": "frontend_bound - fetch_latency_bound",
+        "PublicDescription": "Fetch bandwidth bound L2 topdown metric",
+        "BriefDescription": "Fetch bandwidth bound L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "fetch_bandwidth_bound"
+    },
+    {
+        "MetricExpr": "(bad_speculation * BR_MIS_PRED) / (BR_MIS_PRED + armv8_pmuv3_0 at event\\=0x2013@)",
+        "PublicDescription": "Branch mispredicts L2 topdown metric",
+        "BriefDescription": "Branch mispredicts L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "branch_mispredicts"
+    },
+    {
+        "MetricExpr": "bad_speculation - branch_mispredicts",
+        "PublicDescription": "Machine clears L2 topdown metric",
+        "BriefDescription": "Machine clears L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "machine_clears"
+    },
+    {
+        "MetricExpr": "(EXE_STALL_CYCLE - (MEM_STALL_ANYLOAD + armv8_pmuv3_0 at event\\=0x7005@)) / CPU_CYCLES",
+        "PublicDescription": "Core bound L2 topdown metric",
+        "BriefDescription": "Core bound L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "core_bound"
+    },
+    {
+        "MetricExpr": "(MEM_STALL_ANYLOAD + armv8_pmuv3_0 at event\\=0x7005@) / CPU_CYCLES",
+        "PublicDescription": "Memory bound L2 topdown metric",
+        "BriefDescription": "Memory bound L2 topdown metric",
+        "MetricGroup": "TopDownL2",
+        "MetricName": "memory_bound"
+    },
 ]
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:50 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:50 +0800
Subject: [PATCH v3 6/6] perf vendor events arm64: Add Hisi hip08 L3 metrics
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <1617791570-165223-7-git-send-email-john.garry@huawei.com>

Add L3 metrics.

Signed-off-by: John Garry <john.garry at huawei.com>
Reviewed-by: Kajol Jain <kjain at linux.ibm.com>
---
 .../arch/arm64/hisilicon/hip08/metrics.json   | 161 ++++++++++++++++++
 1 file changed, 161 insertions(+)

diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
index dda898d23c2d..dda8e59149d2 100644
--- a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
@@ -69,4 +69,165 @@
         "MetricGroup": "TopDownL2",
         "MetricName": "memory_bound"
     },
+    {
+        "MetricExpr": "(((L2I_TLB - L2I_TLB_REFILL) * 15) + (L2I_TLB_REFILL * 100)) / CPU_CYCLES",
+        "PublicDescription": "Idle by itlb miss L3 topdown metric",
+        "BriefDescription": "Idle by itlb miss L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "idle_by_itlb_miss"
+    },
+    {
+        "MetricExpr": "(((L2I_CACHE - L2I_CACHE_REFILL) * 15) + (L2I_CACHE_REFILL * 100)) / CPU_CYCLES",
+        "PublicDescription": "Idle by icache miss L3 topdown metric",
+        "BriefDescription": "Idle by icache miss L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "idle_by_icache_miss"
+    },
+    {
+        "MetricExpr": "(BR_MIS_PRED * 5) / CPU_CYCLES",
+        "PublicDescription": "BP misp flush L3 topdown metric",
+        "BriefDescription": "BP misp flush L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "bp_misp_flush"
+    },
+    {
+        "MetricExpr": "(armv8_pmuv3_0 at event\\=0x2013@ * 5) / CPU_CYCLES",
+        "PublicDescription": "OOO flush L3 topdown metric",
+        "BriefDescription": "OOO flush L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "ooo_flush"
+    },
+    {
+        "MetricExpr": "(armv8_pmuv3_0 at event\\=0x1001@ * 5) / CPU_CYCLES",
+        "PublicDescription": "Static predictor flush L3 topdown metric",
+        "BriefDescription": "Static predictor flush L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "sp_flush"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x1010@ / BR_MIS_PRED",
+        "PublicDescription": "Indirect branch L3 topdown metric",
+        "BriefDescription": "Indirect branch L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "indirect_branch"
+    },
+    {
+        "MetricExpr": "(armv8_pmuv3_0 at event\\=0x1014@ + armv8_pmuv3_0 at event\\=0x1018@) / BR_MIS_PRED",
+        "PublicDescription": "Push branch L3 topdown metric",
+        "BriefDescription": "Push branch L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "push_branch"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x100c@ / BR_MIS_PRED",
+        "PublicDescription": "Pop branch L3 topdown metric",
+        "BriefDescription": "Pop branch L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "pop_branch"
+    },
+    {
+        "MetricExpr": "(BR_MIS_PRED - armv8_pmuv3_0 at event\\=0x1010@ - armv8_pmuv3_0 at event\\=0x1014@ - armv8_pmuv3_0 at event\\=0x1018@ - armv8_pmuv3_0 at event\\=0x100c@) / BR_MIS_PRED",
+        "PublicDescription": "Other branch L3 topdown metric",
+        "BriefDescription": "Other branch L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "other_branch"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x2012@ / armv8_pmuv3_0 at event\\=0x2013@",
+        "PublicDescription": "Nuke flush L3 topdown metric",
+        "BriefDescription": "Nuke flush L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "nuke_flush"
+    },
+    {
+        "MetricExpr": "1 - nuke_flush",
+        "PublicDescription": "Other flush L3 topdown metric",
+        "BriefDescription": "Other flush L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "other_flush"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x2010@ / CPU_CYCLES",
+        "PublicDescription": "Sync stall L3 topdown metric",
+        "BriefDescription": "Sync stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "sync_stall"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x2004@ / CPU_CYCLES",
+        "PublicDescription": "Rob stall L3 topdown metric",
+        "BriefDescription": "Rob stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "rob_stall"
+    },
+    {
+        "MetricExpr": "(armv8_pmuv3_0 at event\\=0x2006@ + armv8_pmuv3_0 at event\\=0x2007@ + armv8_pmuv3_0 at event\\=0x2008@) / CPU_CYCLES",
+        "PublicDescription": "Ptag stall L3 topdown metric",
+        "BriefDescription": "Ptag stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "ptag_stall"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x201e@ / CPU_CYCLES",
+        "PublicDescription": "SaveOpQ stall L3 topdown metric",
+        "BriefDescription": "SaveOpQ stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "saveopq_stall"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x2005@ / CPU_CYCLES",
+        "PublicDescription": "PC buffer stall L3 topdown metric",
+        "BriefDescription": "PC buffer stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "pc_buffer_stall"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x7002@ / CPU_CYCLES",
+        "PublicDescription": "Divider L3 topdown metric",
+        "BriefDescription": "Divider L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "divider"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x7003@ / CPU_CYCLES",
+        "PublicDescription": "FSU stall L3 topdown metric",
+        "BriefDescription": "FSU stall L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "fsu_stall"
+    },
+    {
+        "MetricExpr": "core_bound - divider - fsu_stall",
+        "PublicDescription": "EXE ports util L3 topdown metric",
+        "BriefDescription": "EXE ports util L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "exe_ports_util"
+    },
+    {
+        "MetricExpr": "(MEM_STALL_ANYLOAD - MEM_STALL_L1MISS) / CPU_CYCLES",
+        "PublicDescription": "L1 bound L3 topdown metric",
+        "BriefDescription": "L1 bound L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "l1_bound"
+    },
+    {
+        "MetricExpr": "(MEM_STALL_L1MISS - MEM_STALL_L2MISS) / CPU_CYCLES",
+        "PublicDescription": "L2 bound L3 topdown metric",
+        "BriefDescription": "L2 bound L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "l2_bound"
+    },
+    {
+        "MetricExpr": "MEM_STALL_L2MISS / CPU_CYCLES",
+        "PublicDescription": "Mem bound L3 topdown metric",
+        "BriefDescription": "Mem bound L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "mem_bound"
+    },
+    {
+        "MetricExpr": "armv8_pmuv3_0 at event\\=0x7005@ / CPU_CYCLES",
+        "PublicDescription": "Store bound L3 topdown metric",
+        "BriefDescription": "Store bound L3 topdown metric",
+        "MetricGroup": "TopDownL3",
+        "MetricName": "store_bound"
+    },
 ]
-- 
2.26.2



From john.garry at huawei.com  Wed Apr  7 11:32:44 2021
From: john.garry at huawei.com (John Garry)
Date: Wed, 7 Apr 2021 18:32:44 +0800
Subject: [PATCH v3 0/6] perf arm64 metricgroup support
Message-ID: <1617791570-165223-1-git-send-email-john.garry@huawei.com>

This series contains support to get basic metricgroups working for
arm64 CPUs.

Initial support is added for HiSilicon hip08 platform.

Some sample usage on Huawei D06 board:

 $ ./perf list metric    

List of pre-defined events (to be used in -e): 

Metrics:     

  bp_misp_flush
       [BP misp flush L3 topdown metric]
  branch_mispredicts
       [Branch mispredicts L2 topdown metric]
  core_bound
       [Core bound L2 topdown metric]
  divider
       [Divider L3 topdown metric]
  exe_ports_util
       [EXE ports util L3 topdown metric]
  fetch_bandwidth_bound
       [Fetch bandwidth bound L2 topdown metric]
  fetch_latency_bound
       [Fetch latency bound L2 topdown metric]
  fsu_stall
       [FSU stall L3 topdown metric]
  idle_by_icache_miss

$ sudo ./perf stat -v -M core_bound sleep 1
Using CPUID 0x00000000480fd010
metric expr (exe_stall_cycle - (mem_stall_anyload + armv8_pmuv3_0 at event\=0x7005@)) / cpu_cycles for core_bound
found event cpu_cycles
found event armv8_pmuv3_0/event=0x7005/
found event exe_stall_cycle
found event mem_stall_anyload
adding {cpu_cycles -> armv8_pmuv3_0/event=0x7001/
mem_stall_anyload -> armv8_pmuv3_0/event=0x7004/
Control descriptor is not initialized
cpu_cycles: 989433 385050 385050
armv8_pmuv3_0/event=0x7005/: 19207 385050 385050
exe_stall_cycle: 900825 385050 385050
mem_stall_anyload: 253516 385050 385050

Performance counter stats for 'sleep':

989,433      cpu_cycles      #     0.63 core_bound
  19,207      armv8_pmuv3_0/event=0x7005/
 900,825      exe_stall_cycle
 253,516      mem_stall_anyload

       0.000805809 seconds time elapsed

       0.000875000 seconds user
       0.000000000 seconds sys
       
perf stat --topdown is not supported, as this requires the CPU PMU to
expose (alias) events for the TopDown L1 metrics from sysfs, which arm 
does not do. To get that to work, we probably need to make perf use the
pmu-events cpumap to learn about those alias events.

Metric reuse support is added for pmu-events parse metric testcase.
This had been broken on power9 recently:
https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/ 

Differences to v2:
- Add TB and RB tags (Thanks!)
- Rename metricgroup__find_metric() from metricgroup_find_metric()
- Change resolve_metric_simple() to rescan after any insert

Differences to v1:
- Add pmu_events_map__find() as arm64-specific function
- Fix metric reuse for pmu-events parse metric testcase 

John Garry (6):
  perf metricgroup: Make find_metric() public with name change
  perf test: Handle metric reuse in pmu-events parsing test
  perf pmu: Add pmu_events_map__find()
  perf vendor events arm64: Add Hisi hip08 L1 metrics
  perf vendor events arm64: Add Hisi hip08 L2 metrics
  perf vendor events arm64: Add Hisi hip08 L3 metrics

 tools/perf/arch/arm64/util/Build              |   1 +
 tools/perf/arch/arm64/util/pmu.c              |  25 ++
 .../arch/arm64/hisilicon/hip08/metrics.json   | 233 ++++++++++++++++++
 tools/perf/tests/pmu-events.c                 |  83 ++++++-
 tools/perf/util/metricgroup.c                 |  12 +-
 tools/perf/util/metricgroup.h                 |   3 +-
 tools/perf/util/pmu.c                         |   5 +
 tools/perf/util/pmu.h                         |   1 +
 tools/perf/util/s390-sample-raw.c             |   4 +-
 9 files changed, 356 insertions(+), 11 deletions(-)
 create mode 100644 tools/perf/arch/arm64/util/pmu.c
 create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json

-- 
2.26.2



From will at kernel.org  Wed Apr  7 11:42:10 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 11:42:10 +0100
Subject: [PATCH v2 3/3] iommu: dart: Add DART iommu driver
In-Reply-To: <20210328074009.95932-4-sven@svenpeter.dev>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-4-sven@svenpeter.dev>
Message-ID: <20210407104209.GA15173@willie-the-truck>

On Sun, Mar 28, 2021 at 09:40:09AM +0200, Sven Peter wrote:
> Apple's new SoCs use iommus for almost all peripherals. These Device
> Address Resolution Tables must be setup before these peripherals can
> act as DMA masters.
> 
> Signed-off-by: Sven Peter <sven at svenpeter.dev>
> ---
>  MAINTAINERS                      |   1 +
>  drivers/iommu/Kconfig            |  14 +
>  drivers/iommu/Makefile           |   1 +
>  drivers/iommu/apple-dart-iommu.c | 858 +++++++++++++++++++++++++++++++
>  4 files changed, 874 insertions(+)
>  create mode 100644 drivers/iommu/apple-dart-iommu.c

[...]

> +/* must be called with held domain->lock */
> +static int apple_dart_attach_stream(struct apple_dart_domain *domain,
> +				    struct apple_dart *dart, u32 sid)
> +{
> +	unsigned long flags;
> +	struct apple_dart_stream *stream;
> +	struct io_pgtable_cfg *pgtbl_cfg;
> +	int ret;
> +
> +	list_for_each_entry(stream, &domain->streams, stream_head) {
> +		if (stream->dart == dart && stream->sid == sid) {
> +			stream->num_devices++;
> +			return 0;
> +		}
> +	}
> +
> +	spin_lock_irqsave(&dart->lock, flags);
> +
> +	if (WARN_ON(dart->used_sids & BIT(sid))) {
> +		ret = -EINVAL;
> +		goto error;
> +	}
> +
> +	stream = kzalloc(sizeof(*stream), GFP_KERNEL);
> +	if (!stream) {
> +		ret = -ENOMEM;
> +		goto error;
> +	}

Just in case you missed it, a cocci bot noticed that you're using GFP_KERNEL
to allocate while holding a spinlock here:

https://lore.kernel.org/r/alpine.DEB.2.22.394.2104041724340.2958 at hadrien

Will


From a-govindraju at ti.com  Wed Apr  7 11:43:03 2021
From: a-govindraju at ti.com (Aswath Govindraju)
Date: Wed, 7 Apr 2021 16:13:03 +0530
Subject: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in
 MMCSD1 subsystem
Message-ID: <20210407104303.25950-1-a-govindraju@ti.com>

UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].

Add support by removing the no-1-8-v tag and including the voltage
regulator device tree nodes for power cycling.

[1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1

Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>
---

test logs:
https://pastebin.ubuntu.com/p/vpYbY9QWh8/

 arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  1 -
 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++++++++++++++++++
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index cb340d1b401f..632f32fce4a1 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -301,7 +301,6 @@
 		ti,otap-del-sel = <0x2>;
 		ti,trm-icp = <0x8>;
 		dma-coherent;
-		no-1-8-v;
 	};
 
 	scm_conf: scm-conf at 100000 {
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 9e87fb313a54..6f7292b6fe0a 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -91,6 +91,38 @@
 		#clock-cells = <0>;
 		clock-frequency = <24000000>;
 	};
+
+	evm_12v0: fixedregulator-evm12v0 {
+		/* main supply */
+		compatible = "regulator-fixed";
+		regulator-name = "evm_12v0";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc3v3_io: fixedregulator-vcc3v3io {
+		/* Output of TPS54334 */
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_io";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&evm_12v0>;
+	};
+
+	vdd_mmc1_sd: fixedregulator-sd {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_mmc1_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		enable-active-high;
+		vin-supply = <&vcc3v3_io>;
+		gpio = <&pca9554 4 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &wkup_pmx0 {
@@ -350,6 +382,7 @@
  * disable sdhci1
  */
 &sdhci1 {
+	vmmc-supply = <&vdd_mmc1_sd>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_mmc1_pins_default>;
 	ti,driver-strength-ohm = <50>;
-- 
2.17.1



From will at kernel.org  Wed Apr  7 11:44:29 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 11:44:29 +0100
Subject: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format
In-Reply-To: <20210328074009.95932-2-sven@svenpeter.dev>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-2-sven@svenpeter.dev>
Message-ID: <20210407104425.GB15173@willie-the-truck>

On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> Apple's DART iommu uses a pagetable format that shares some
> similarities with the ones already implemented by io-pgtable.c.
> Add a new format variant to support the required differences
> so that we don't have to duplicate the pagetable handling code.
> 
> Signed-off-by: Sven Peter <sven at svenpeter.dev>
> ---
>  drivers/iommu/io-pgtable-arm.c | 59 ++++++++++++++++++++++++++++++++++
>  drivers/iommu/io-pgtable.c     |  1 +
>  include/linux/io-pgtable.h     |  6 ++++
>  3 files changed, 66 insertions(+)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 87def58e79b5..2f63443fd115 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -127,6 +127,9 @@
>  #define ARM_MALI_LPAE_MEMATTR_IMP_DEF	0x88ULL
>  #define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
>  
> +#define APPLE_DART_PTE_PROT_NO_WRITE (1<<7)
> +#define APPLE_DART_PTE_PROT_NO_READ (1<<8)
> +
>  /* IOPTE accessors */
>  #define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
>  
> @@ -381,6 +384,15 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
>  {
>  	arm_lpae_iopte pte;
>  
> +	if (data->iop.fmt == ARM_APPLE_DART) {
> +		pte = 0;
> +		if (!(prot & IOMMU_WRITE))
> +			pte |= APPLE_DART_PTE_PROT_NO_WRITE;
> +		if (!(prot & IOMMU_READ))
> +			pte |= APPLE_DART_PTE_PROT_NO_READ;
> +		return pte;
> +	}
> +
>  	if (data->iop.fmt == ARM_64_LPAE_S1 ||
>  	    data->iop.fmt == ARM_32_LPAE_S1) {
>  		pte = ARM_LPAE_PTE_nG;
> @@ -1043,6 +1055,48 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
>  	return NULL;
>  }
>  
> +static struct io_pgtable *
> +apple_dart_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> +{
> +	struct arm_lpae_io_pgtable *data;
> +
> +	if (cfg->ias > 36)
> +		return NULL;
> +	if (cfg->oas > 36)
> +		return NULL;
> +
> +	if (!cfg->coherent_walk)
> +		return NULL;

This all feels like IOMMU-specific limitations leaking into the page-table
code here; it doesn't feel so unlikely that future implementations of this
IP might have greater addressing capabilities, for example, and so I don't
see why the page-table code needs to police this.

> +	cfg->pgsize_bitmap &= SZ_16K;
> +	if (!cfg->pgsize_bitmap)
> +		return NULL;

This is worrying (and again, I don't think this belongs here). How is this
thing supposed to work if the CPU is using 4k pages?

Will


From matthias.bgg at gmail.com  Wed Apr  7 12:00:14 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 7 Apr 2021 13:00:14 +0200
Subject: [GIT PULL] soc: mediatek: changes for v5.12 (second round)
Message-ID: <14104322-3a6c-e8eb-cd21-a5343a81aa0f@gmail.com>

Hi Olof and Arnd,

Here comes the second round of soc drivers patches. Hope I'm not too late.

Please have a look.
Best regards,
Matthias

---
The following changes since commit 60d93f64a851d276b23b7ef68ddc638258485d32:

  soc: mediatek: pm-domains: Add a power domain names for mt8167 (2021-04-01
11:36:04 +0200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-soc.2

for you to fetch changes up to 060f7875bd230df1a8f83a988faaee09d693e465:

  soc: mediatek: mmsys: Add support for MT8167 SoC (2021-04-06 12:57:10 +0200)

----------------------------------------------------------------
MT8167:
- add support for mmsys subsystem

----------------------------------------------------------------
Fabien Parent (2):
      dt-bindings: mediatek: mmsys: add mt8167 binding
      soc: mediatek: mmsys: Add support for MT8167 SoC

 .../bindings/arm/mediatek/mediatek,mmsys.txt       |  1 +
 drivers/soc/mediatek/mt8167-mmsys.h                | 35 ++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c                   | 11 +++++++
 3 files changed, 47 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8167-mmsys.h


From matthias.bgg at gmail.com  Wed Apr  7 12:00:20 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 7 Apr 2021 13:00:20 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
Message-ID: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>

Hi Olof and Arnd,

Here comes the second round of arm64 DT patches. Hope I'm not too late.
Basically we add several node to MT8167.

Please have a look.
Regards,
Matthias

---
The following changes since commit a7dceafed43a4a610d340da3703653cca2c50c1d:

  arm64: dts: mediatek: fix reset GPIO level on pumpkin (2021-04-01 11:39:10 +0200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.12-next-dts64.2

for you to fetch changes up to 3a8c657a3b4a70405582bf8e1cc39ff3b55c53f6:

  arm64: dts: mediatek: mt8167: add some DRM nodes (2021-04-06 15:12:40 +0200)

----------------------------------------------------------------
- separate enconder blocks for MT8173

MT8167:
- add power domain node
- add nodes for graphical output (iommu, larb, smi, mmsys)

----------------------------------------------------------------
Fabien Parent (6):
      arm64: dts: mediatek: mt8167: add power domains
      arm64: dts: mediatek: mt8167: add mmsys node
      arm64: dts: mediatek: mt8167: add smi_common node
      arm64: dts: mediatek: mt8167: add larb nodes
      arm64: dts: mediatek: mt8167: add iommu node
      arm64: dts: mediatek: mt8167: add some DRM nodes

Irui Wang (1):
      arm64: dts: mt8173: Separating mtk-vcodec-enc device node

 arch/arm64/boot/dts/mediatek/mt8167.dtsi | 270 +++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |  60 +++----
 2 files changed, 301 insertions(+), 29 deletions(-)


From maz at kernel.org  Wed Apr  7 12:11:21 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 12:11:21 +0100
Subject: [PATCH v2 06/10] irqchip: Add driver for WPCM450 interrupt
 controller
In-Reply-To: <20210406120921.2484986-7-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <20210406120921.2484986-7-j.neuschaefer@gmx.net>
Message-ID: <87czv6pcx2.wl-maz@kernel.org>

On Tue, 06 Apr 2021 13:09:17 +0100,
Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
> 
> The WPCM450 AIC ("Advanced Interrupt Controller") is the interrupt
> controller found in the Nuvoton WPCM450 SoC and other Winbond/Nuvoton
> SoCs.
> 
> The list of registers if based on the AMI vendor kernel and the
> Nuvoton W90N745 datasheet.
> 
> Although the hardware supports other interrupt modes, the driver only
> supports high-level interrupts at the moment, because other modes could
> not be tested so far.
> 
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
> ---
> 
> v2:
> - Rename IRQS macro to AIC_NUM_IRQS
> - Fix IRQ range check
> - Use linux/printk.h header instead of linux/console.h
> - Add AIC_SCR_PRIORITY_MASK constant
> - Add missing register descriptions
> - Remove superfluous printk about IRQ flow type mismatch
> - Use BIT() macro
> - Rename _ack function to _eoi for accuracy, and use handle_fasteoi_irq
> ---
>  arch/arm/mach-npcm/Kconfig        |   1 +
>  drivers/irqchip/Kconfig           |   6 ++
>  drivers/irqchip/Makefile          |   1 +
>  drivers/irqchip/irq-wpcm450-aic.c | 161 ++++++++++++++++++++++++++++++
>  4 files changed, 169 insertions(+)
>  create mode 100644 drivers/irqchip/irq-wpcm450-aic.c
> 
> diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
> index 658c8efb4ca14..a71cf1d189ae5 100644
> --- a/arch/arm/mach-npcm/Kconfig
> +++ b/arch/arm/mach-npcm/Kconfig
> @@ -10,6 +10,7 @@ config ARCH_WPCM450
>  	bool "Support for WPCM450 BMC (Hermon)"
>  	depends on ARCH_MULTI_V5
>  	select CPU_ARM926T
> +	select WPCM450_AIC
>  	select NPCM7XX_TIMER
>  	help
>  	  General support for WPCM450 BMC (Hermon).

I can't take this patch with this particular hunk, as I don't have
this file in my tree. I can either drop this line, or delay the
merging of this patch to a later point in time.

The driver otherwise looks ready.

Thanks,

	M.

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


From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:23 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:23 +0300
Subject: [PATCH v4 0/5] add devicetree for Forlinx FETA40i-C & OKA40i-C
Message-ID: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>

This patch series adds devicetree support for the Forlinx FETA40i-C SoM
and OKA40i-C carrier board/devboard.

The FETA40i-C is an "industrial/automotive" SoM by Forlinx.

SoM specs:
- SoC: R40 or A40i
- PMIC: AXP221S
- RAM: 1GiB/2GiB DDR3 (dual-rank)
- eMMC: 8GB,
- Mates with carrier board via four 80-pin connectors (AXK6F80337YG).

OKA40i-C is a carrier board by the same manufacturer for this SoM,
whose main purpose is as a development board with a variety of
peripherals:

- Power: DC5V barrel or USB OTG or 4.2V Lipo battery
- Video out: HDMI, TV out, LVDS
- WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
- Ethernet: 10/100Mbps
- Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
- USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
- UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
- Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
- Mini PCIe slot with sim holder for WLAN modem
- Smart card holder
- RTC (RX8010SJ)
- Two user LEDs
- Three user buttons (via KeyADC).

Of the board features listed above, support for the following has *NOT*
been tested:
- TV out & LVDS
- SATA
- Smart cards
- KeyADC buttons (no support)

The series consists of five patches, with dependencies as follows:

* Patch 4 depends on patch 3;
* Patch 5 depends on patches 2&4.

The rest are independent, however patch 2 may refuse to apply
without patch 1.

Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
---

Changelog:

v4:
* split dt-bindings patch into separate parts for vendor and device
* add /omit-if-no-ref/ to the mmc3 pins node as well
* add clarifying comment on the naming of user led nodes

v3:
* add compatible string for the SoM
* move regulators aldo3, dcdc{2,3,5}, eldo{2,3} to the SoM .dtsi

v2:
* split patch into series
  * edits to sun8i-r40.dtsi are now in separate patch
* add dt bindings for compatible strings (in separate patch)
* add /omit-if-no-ref/ to the new uart pin nodes
  * preliminary patch adds the keyword to existing nodes for UART0 & UART3
* whitespace fixes as suggested by checkpatch.pl

(draft2 ->) v1: 
* fix indentation from spaces to tabs
* remove commented properties and other extraneous comments
* enable uarts 2,4,5&7 and alias uart3
* update the user-LED bindings
* remove mmc1 & add mmc3 binding
* bring together the max/min microvolts on three regulators
    * The reported 2.5v value in ALDO2 comes from U-Boot, where apparently
      this is the KConfig default for this regulator. The correct voltage
      is 1.8v.
* remove extraneous `always-on`s from regulators dldo1 and eldo2/3
* remove reg_dldo3 node entirely

---

Ivan Uvarov (5):
  ARM: dts: sun8i: r40: add /omit-if-no-ref/ to pinmux nodes for UARTs 0&3
  ARM: dts: sun8i: r40: add pinmux settings for MMC3 and UARTs 2,4,5&7
  dt-bindings: add compatible vendor prefix for Forlinx
  dt-bindings: arm: add compatible for Forlinx OKA40i-C and FETA40i-C
  ARM: dts: sun8i: r40: add devicetree for Forlinx FETA40i-C & OKA40i-C

 .../devicetree/bindings/arm/sunxi.yaml        |   6 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/sun8i-r40-feta40i.dtsi      | 106 +++++++++
 arch/arm/boot/dts/sun8i-r40-oka40i-c.dts      | 203 ++++++++++++++++++
 arch/arm/boot/dts/sun8i-r40.dtsi              |  44 ++++
 6 files changed, 362 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
 create mode 100644 arch/arm/boot/dts/sun8i-r40-oka40i-c.dts

--
2.25.1



From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:26 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:26 +0300
Subject: [PATCH v4 3/5] dt-bindings: add compatible vendor prefix for Forlinx
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210407111428.3755684-4-i.uvarov@cognitivepilot.com>

Baoding Forlinx Embedded Technology Co., Ltd. is the manufacturer of the
Allwinner R40/A40i-powered FETA40i-C SoM and the OKA40i-C dev/carrier board
based on it.

This patch adds the DT vendor prefix for Forlinx in preparation for a
further patch, which includes a devicetree for the OKA40i-C board.

Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a4..e2ea1a731e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -403,6 +403,8 @@ patternProperties:
     description: Firefly
   "^focaltech,.*":
     description: FocalTech Systems Co.,Ltd
+  "^forlinx,.*":
+    description: Baoding Forlinx Embedded Technology Co., Ltd.
   "^frida,.*":
     description: Shenzhen Frida LCD Co., Ltd.
   "^friendlyarm,.*":
-- 
2.25.1



From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:24 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:24 +0300
Subject: [PATCH v4 1/5] ARM: dts: sun8i: r40: add /omit-if-no-ref/ to pinmux
 nodes for UARTs 0&3
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210407111428.3755684-2-i.uvarov@cognitivepilot.com>

This patch adds the /omit-if-no-ref/ keyword to the pio nodes for
UART0 and UART3 pins of the R40 SoC, which would reduce the fdt size on
boards which do not use these UARTs.

Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index d5ad3b9efd..0b257a0779 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -631,16 +631,19 @@ spi1_cs1_pi_pin: spi1-cs1-pi-pin {
 				function = "spi1";
 			};
 
+			/omit-if-no-ref/
 			uart0_pb_pins: uart0-pb-pins {
 				pins = "PB22", "PB23";
 				function = "uart0";
 			};
 
+			/omit-if-no-ref/
 			uart3_pg_pins: uart3-pg-pins {
 				pins = "PG6", "PG7";
 				function = "uart3";
 			};
 
+			/omit-if-no-ref/
 			uart3_rts_cts_pg_pins: uart3-rts-cts-pg-pins {
 				pins = "PG8", "PG9";
 				function = "uart3";
-- 
2.25.1



From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:27 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:27 +0300
Subject: [PATCH v4 4/5] dt-bindings: arm: add compatible for Forlinx OKA40i-C
 and FETA40i-C
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210407111428.3755684-5-i.uvarov@cognitivepilot.com>

The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i SoC.
The OKA40i-C is a carrier/development board by the same company based on
this SoM.

This patch adds compatible strings for these two devices in preparation for
the next patch containing a devicetree for them.

Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 08607c7ec1..74f8decd78 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -224,6 +224,12 @@ properties:
           - const: empire-electronix,m712
           - const: allwinner,sun5i-a13
 
+      - description: Forlinx OKA40i-C Development board
+        items:
+          - const: forlinx,oka40i-c
+          - const: forlinx,feta40i-c
+          - const: allwinner,sun8i-r40
+
       - description: FriendlyARM NanoPi A64
         items:
           - const: friendlyarm,nanopi-a64
-- 
2.25.1



From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:25 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:25 +0300
Subject: [PATCH v4 2/5] ARM: dts: sun8i: r40: add pinmux settings for MMC3 and
 UARTs 2, 4, 5&7
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210407111428.3755684-3-i.uvarov@cognitivepilot.com>

The Forlinx OKA40i-C devboard makes use of UARTs 0,2,3,4,5 and 7 of the R40
SoC, of which UART 0 is connected to an RS232 converter, UART 5 routed to
an RS485 converter, and the rest broken out directly via labeled headers.
The board also contains a micro-SD slot connected to SDC3.

This patch adds settings to R40's pinmux node for MMC3 and those UARTs that
were not already mapped, which would allow us to make use of all available
UARTs and the micro-SD slot on this board in a further patch.

Reviewed-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 0b257a0779..9ad4f0129c 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -357,6 +357,8 @@ mmc3: mmc at 1c12000 {
 			clock-names = "ahb", "mmc";
 			resets = <&ccu RST_BUS_MMC3>;
 			reset-names = "ahb";
+			pinctrl-0 = <&mmc3_pins>;
+			pinctrl-names = "default";
 			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
 			status = "disabled";
 			#address-cells = <1>;
@@ -601,6 +603,15 @@ mmc2_pins: mmc2-pins {
 				bias-pull-up;
 			};
 
+			/omit-if-no-ref/
+			mmc3_pins: mmc3-pins {
+				pins = "PI4", "PI5", "PI6",
+				       "PI7", "PI8", "PI9";
+				function = "mmc3";
+				drive-strength = <30>;
+				bias-pull-up;
+			};
+
 			/omit-if-no-ref/
 			spi0_pc_pins: spi0-pc-pins {
 				pins = "PC0", "PC1", "PC2";
@@ -637,6 +648,18 @@ uart0_pb_pins: uart0-pb-pins {
 				function = "uart0";
 			};
 
+			/omit-if-no-ref/
+			uart2_pi_pins: uart2-pi-pins {
+				pins = "PI18", "PI19";
+				function = "uart2";
+			};
+
+			/omit-if-no-ref/
+			uart2_rts_cts_pi_pins: uart2-rts-cts-pi-pins{
+				pins = "PI16", "PI17";
+				function = "uart2";
+			};
+
 			/omit-if-no-ref/
 			uart3_pg_pins: uart3-pg-pins {
 				pins = "PG6", "PG7";
@@ -648,6 +671,24 @@ uart3_rts_cts_pg_pins: uart3-rts-cts-pg-pins {
 				pins = "PG8", "PG9";
 				function = "uart3";
 			};
+
+			/omit-if-no-ref/
+			uart4_pg_pins: uart4-pg-pins {
+				pins = "PG10", "PG11";
+				function = "uart4";
+			};
+
+			/omit-if-no-ref/
+			uart5_ph_pins: uart5-ph-pins {
+				pins = "PH6", "PH7";
+				function = "uart5";
+			};
+
+			/omit-if-no-ref/
+			uart7_pi_pins: uart7-pi-pins {
+				pins = "PI20", "PI21";
+				function = "uart7";
+			};
 		};
 
 		wdt: watchdog at 1c20c90 {
-- 
2.25.1



From i.uvarov at cognitivepilot.com  Wed Apr  7 12:14:28 2021
From: i.uvarov at cognitivepilot.com (Ivan Uvarov)
Date: Wed,  7 Apr 2021 14:14:28 +0300
Subject: [PATCH v4 5/5] ARM: dts: sun8i: r40: add devicetree for Forlinx
 FETA40i-C & OKA40i-C
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210407111428.3755684-6-i.uvarov@cognitivepilot.com>

The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i.

SoM specifications:

- SoC: R40 or A40i
- PMIC: AXP221S
- RAM: 1GiB/2GiB DDR3 (dual-rank)
- eMMC: 8GB,
- Mates with carrier board via four 80-pin connectors (AXK6F80337YG).

OKA40i-C is a carrier board by the same manufacturer for this SoM,
whose main purpose is as a development board with a wide variety of
peripherals:

- Power: DC5V barrel or USB OTG or 4.2V Lipo battery
- Video out: HDMI, TV out, LVDS
- WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
- Ethernet: 10/100Mbps
- Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
- USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
- UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
- Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
- Mini PCIe slot with sim holder for WLAN modem
- Smart card holder
- RTC (RX8010SJ)
- Two user LEDs
- Three user buttons (via KeyADC).

This patch adds a devicetree for the aforementioned SoM and devboard.
In order to reflect the modularity of this devboard and simplify adding
support for future hardware based on the same SoM, the devicetree is split:
Everything pertaining to the SoM itself is described in a separate .dtsi
file, which is included by the devboard's .dts.

Reviewed-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

 3 files changed, 310 insertions(+)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e7..88aae9de95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1222,6 +1222,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
 	sun8i-r16-nintendo-super-nes-classic.dtb \
 	sun8i-r16-parrot.dtb \
 	sun8i-r40-bananapi-m2-ultra.dtb \
+	sun8i-r40-oka40i-c.dtb \
 	sun8i-s3-elimo-initium.dtb \
 	sun8i-s3-lichee-zero-plus.dtb \
 	sun8i-s3-pinecube.dtb \
diff --git a/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
new file mode 100644
index 0000000000..265e0fa57a
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-r40-feta40i.dtsi
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
+// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
+//  Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
+//  Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
+
+#include "sun8i-r40.dtsi"
+
+&i2c0 {
+	status = "okay";
+
+	axp22x: pmic at 34 {
+		compatible = "x-powers,axp221";
+		reg = <0x34>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+#include "axp22x.dtsi"
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_aldo2>;
+	bus-width = <8>;
+	non-removable;
+	status = "okay";
+};
+
+&pio {
+	pinctrl-names = "default";
+	pinctrl-0 = <&clk_out_a_pin>;
+	vcc-pa-supply = <&reg_dcdc1>;
+	vcc-pc-supply = <&reg_aldo2>;
+	vcc-pd-supply = <&reg_dcdc1>;
+	vcc-pf-supply = <&reg_dldo4>;
+	vcc-pg-supply = <&reg_dldo1>;
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pa";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1100000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi-io";
+};
+
+&reg_dldo4 {
+	regulator-always-on;
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vdd2v5-sata";
+};
+
+&reg_eldo2 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vdd1v2-sata";
+};
+
+&reg_eldo3 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-name = "vcc-pe";
+};
diff --git a/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
new file mode 100644
index 0000000000..0bd1336206
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-r40-oka40i-c.dts
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+// Copyright (C) 2021 Ivan Uvarov <i.uvarov at cognitivepilot.com>
+// Based on the sun8i-r40-bananapi-m2-ultra.dts, which is:
+//	Copyright (C) 2017 Chen-Yu Tsai <wens at csie.org>
+//	Copyright (C) 2017 Icenowy Zheng <icenowy at aosc.io>
+
+/dts-v1/;
+#include "sun8i-r40-feta40i.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "Forlinx OKA40i-C";
+	compatible = "forlinx,oka40i-c", "forlinx,feta40i-c", "allwinner,sun8i-r40";
+
+	aliases {
+		ethernet0 = &gmac;
+		serial0 = &uart0;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5; /* RS485 */
+		serial7 = &uart7;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	connector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+				remote-endpoint = <&hdmi_out_con>;
+			};
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-5 { /* this is how the leds are labeled on the board */
+			gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /* PH26 */
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+		};
+
+		led-6 {
+			gpios = <&pio 8 15 GPIO_ACTIVE_LOW>; /* PI15 */
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
+		};
+	};
+
+	reg_vcc5v0: vcc5v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; // PB10 WIFI_EN
+		clocks = <&ccu CLK_OUTA>;
+		clock-names = "ext_clock";
+	};
+};
+
+&ahci {
+	ahci-supply = <&reg_dldo4>;
+	phy-supply = <&reg_eldo2>;
+	status = "okay";
+};
+
+&de {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_rgmii_pins>;
+	phy-handle = <&phy1>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&reg_dcdc1>;
+	status = "okay";
+};
+
+&gmac_mdio {
+	phy1: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
+&hdmi {
+	status = "okay";
+};
+
+&hdmi_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <&hdmi_con_in>;
+	};
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <4>;
+	cd-gpios = <&pio 8 11 GPIO_ACTIVE_LOW>; // PI11
+	status = "okay";
+};
+
+&mmc3 {
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <4>;
+	cd-gpios = <&pio 8 10 GPIO_ACTIVE_LOW>; // PI10
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
+
+&reg_dc1sw {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-lcd";
+};
+
+&reg_dldo2 {
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&tcon_tv0 {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pb_pins>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2_pi_pins>, <&uart2_rts_cts_pi_pins>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_pg_pins>, <&uart3_rts_cts_pg_pins>;
+	uart-has-rtscts;
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart4_pg_pins>;
+	status = "okay";
+};
+
+&uart5 { /* RS485 */
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart5_ph_pins>;
+	status = "okay";
+};
+
+&uart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart7_pi_pins>;
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_vcc5v0>;
+	usb2_vbus-supply = <&reg_vcc5v0>;
+	status = "okay";
+};
-- 
2.25.1



From matthias.bgg at gmail.com  Wed Apr  7 12:17:22 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 7 Apr 2021 13:17:22 +0200
Subject: [PATCH 1/2] arm64: dts: mediatek: add MT6779 spi master dts node
In-Reply-To: <20210226105918.3057-1-Mason.Zhang@mediatek.com>
References: <20210226105918.3057-1-Mason.Zhang@mediatek.com>
Message-ID: <4e39785a-06a6-4ec5-5930-8a5bf53e4f7b@gmail.com>



On 26/02/2021 11:59, Mason Zhang wrote:
> this patch add spi master dts node for mt6779 SOC.
> 
> Signed-off-by: Mason Zhang <Mason.Zhang at mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt6779.dtsi | 96 ++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> index 370f309d32de..ca72eb09cff9 100644
> --- a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> @@ -219,6 +219,102 @@
>  			status = "disabled";
>  		};
>  
> +		spi0: spi0 at 1100a000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x1100a000 0 0x1000>;
> +			interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				<&topckgen CLK_TOP_SPI>,
> +				<&infracfg_ao CLK_INFRA_SPI0>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";

>From the binding description:
- #address-cells: should be 1.

- #size-cells: should be 0.

We are missing both here. Please fix that.

Apart the binding description is naming PLL, clock mux and clock gate IDs which
do not correspond to the ones used here. It seems that this binding was tailored
for a specific SoC family but never made generic. If you want, please do so and
convert it to yaml.

Regards,
Matthias

> +		};
> +
> +		spi1: spi1 at 11010000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x11010000 0 0x1000>;
> +			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				<&topckgen CLK_TOP_SPI>,
> +				<&infracfg_ao CLK_INFRA_SPI1>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi2: spi2 at 11012000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x11012000 0 0x1000>;
> +			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				 <&topckgen CLK_TOP_SPI>,
> +				<&infracfg_ao CLK_INFRA_SPI2>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi3: spi3 at 11013000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x11013000 0 0x1000>;
> +			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				 <&topckgen CLK_TOP_SPI>,
> +				 <&infracfg_ao CLK_INFRA_SPI3>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi4: spi4 at 11018000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x11018000 0 0x1000>;
> +			interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				 <&topckgen CLK_TOP_SPI>,
> +				 <&infracfg_ao CLK_INFRA_SPI4>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi5: spi5 at 11019000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x11019000 0 0x1000>;
> +			interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				<&topckgen CLK_TOP_SPI>,
> +				<&infracfg_ao CLK_INFRA_SPI5>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi6: spi6 at 1101d000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x1101d000 0 0x1000>;
> +			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				 <&topckgen CLK_TOP_SPI>,
> +				 <&infracfg_ao CLK_INFRA_SPI6>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
> +		spi7: spi7 at 1101e000 {
> +			compatible = "mediatek,mt6779-spi",
> +				     "mediatek,mt6765-spi";
> +			mediatek,pad-select = <0>;
> +			reg = <0 0x1101e000 0 0x1000>;
> +			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_LOW 0>;
> +			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
> +				 <&topckgen CLK_TOP_SPI>,
> +				 <&infracfg_ao CLK_INFRA_SPI7>;
> +			clock-names = "parent-clk", "sel-clk", "spi-clk";
> +		};
> +
>  		audio: clock-controller at 11210000 {
>  			compatible = "mediatek,mt6779-audio", "syscon";
>  			reg = <0 0x11210000 0 0x1000>;
> 


From broonie at kernel.org  Wed Apr  7 12:27:13 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 7 Apr 2021 12:27:13 +0100
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
Message-ID: <20210407112713.GB5510@sirena.org.uk>

On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:

> I'm a little confused -- here is how I remember the chronology of the
> "DT bindings" commit reviews, please correct me if I'm wrong:

> o JimQ submitted a pullreq for using voltage regulators in the same
> style as the existing "rockport" PCIe driver.
> o After some deliberation, RobH preferred that the voltage regulators
> should go into the PCIe subnode device's DT node.
> o JimQ put the voltage regulators in the subnode device's DT node.
> o MarkB didn't like the fact that the code did a global search for the
> regulator since it could not provide the owning struct device* handle.
> o RobH relented, and said that if it is just two specific and standard
> voltage regulators, perhaps they can go in the parent DT node after
> all.
> o JimQ put the regulators back in the PCIe node.
> o MarkB now wants the regulators to go back into the child node again?

...having pointed out a couple of times now that there's no physical
requirement that the supplies be shared between slots never mind with
the controller.  Also note that as I've said depending on what the
actual requirements of the controller node are you might want to have
the regulators in both places, and further note that the driver does not
have to actively use everything in the binding document (although if
it's not using something that turns out to be a requirement it's likely
to run into hardware where that causes bugs at some point).

Frankly I'm not clear why you're trying to handle powering on PCI slots
in a specific driver, surely PCI devices are PCI devices regardless of
the controller?
-------------- 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/20210407/7f7f4bcb/attachment.sig>

From will at kernel.org  Wed Apr  7 12:29:07 2021
From: will at kernel.org (Will Deacon)
Date: Wed,  7 Apr 2021 12:29:07 +0100
Subject: [PATCH] iommu/arm-smmu-v3: Remove the unused fields for
 PREFETCH_CONFIG command
In-Reply-To: <20210407084448.1838-1-yuzenghui@huawei.com>
References: <20210407084448.1838-1-yuzenghui@huawei.com>
Message-ID: <161779144071.3351666.16894933104302748109.b4-ty@kernel.org>

On Wed, 7 Apr 2021 16:44:48 +0800, Zenghui Yu wrote:
> Per SMMUv3 spec, there is no Size and Addr field in the PREFETCH_CONFIG
> command and they're not used by the driver. Remove them.
> 
> We can add them back if we're going to use PREFETCH_ADDR in the future.

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/1] iommu/arm-smmu-v3: Remove the unused fields for PREFETCH_CONFIG command
      https://git.kernel.org/will/c/e0bb4b735404

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From arnd at kernel.org  Wed Apr  7 12:37:54 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 7 Apr 2021 13:37:54 +0200
Subject: [GIT PULL] ARM SoC fixes for v5.12, part 2
Message-ID: <CAK8P3a1QBvqNyReGC9UhYx-GOm3hYB1_xD22E0tmY7k_XqVUSg@mail.gmail.com>

The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3:

  Linux 5.12-rc5 (2021-03-28 15:48:16 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-fixes-5.11-2

for you to fetch changes up to 1180042dc6030c6e26530d4cfe0338fe8e447ca4:

  Merge tag 'mvebu-fixes-5.12-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into
arm/fixes (2021-04-06 23:21:08 +0200)

----------------------------------------------------------------
ARM SoC fixes for v5.12, part 2

Most of the changes again are devicetree fixes, but there are also five
trivial build fixes for issues I found when test building with gcc-11 or
when running 'make W=1', and some OMAP platform specific code fixups.

Broadcom
  - One revert for a Raspberry pi interrupt controller change that
    caused a regression.

TI OMAP:
  - Remove unused duplicate sha2md5_fck clock node that can race with the
    OMAP4_SHA2MD5_CLKCTRL clock node for disable for unused clocks

  - Add aliases for omap4/5 mmc to put the slots back into the right
    order again

  - Fix typo for bionic voltage controllers that accidentally use mpu
    for all instances instead of mpu, core and iva

  - Fix random hangs for droid4 caused by missing fix from TI Android
    kernel tree to do a dummy smc call on cpuidle wakeup path

NXP i.MX:
  - Fix a system failure on imx6qdl-phytec-pfla02 board when booting from
    SD, by adding missing vmmc supply for SD interfaces.

  - Fix address typo in i.MX8MM/Q IOMUXC_SD1_DATA0_GPIO2_IO2 definition.

Marvell mvebu:
  - Fix storm interrupt on Turris Omnia

  - Enable hardware buffer management as it should be

Build fixes for PXA, Freescale, Marvell, OMAP1 an Keystone.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Arnd Bergmann (9):
      Merge tag 'arm-soc/for-5.12/devicetree-part2' of
https://github.com/Broadcom/stblinux into arm/fixes
      Merge tag 'omap-for-v5.12/fixes-rc4-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/fixes
      Merge tag 'imx-fixes-5.12-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/fixes
      ARM: keystone: fix integer overflow warning
      soc/fsl: qbman: fix conflicting alignment attributes
      ARM: omap1: fix building with clang IAS
      ARM: pxa: mainstone: avoid -Woverride-init warning
      ARM: mvebu: avoid clang -Wtautological-constant warning
      Merge tag 'mvebu-fixes-5.12-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into
arm/fixes

Carlos Leija (1):
      ARM: OMAP4: PM: update ROM return address for OSWR and OFF

Florian Fainelli (1):
      Revert "ARM: dts: bcm2711: Add the BSC interrupt controller"

Gregory CLEMENT (1):
      Revert "arm64: dts: marvell: armada-cp110: Switch to per-port
SATA interrupts"

Marek Beh?n (1):
      ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

Oliver St?bler (1):
      arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0

Rui Salvaterra (1):
      ARM: dts: turris-omnia: fix hardware buffer management

Stefan Riedmueller (1):
      ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces

Tony Lindgren (4):
      ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable race
      ARM: dts: Fix moving mmc devices with aliases for omap4 & 5
      Merge branch 'fixes-rc2' into fixes
      ARM: OMAP4: Fix PMIC voltage domains for bionic

 arch/arm/boot/dts/armada-385-turris-omnia.dts  |  4 ++-
 arch/arm/boot/dts/bcm2711.dtsi                 | 12 --------
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi   |  2 ++
 arch/arm/boot/dts/omap4.dtsi                   |  5 ++++
 arch/arm/boot/dts/omap44xx-clocks.dtsi         |  8 ------
 arch/arm/boot/dts/omap5.dtsi                   |  5 ++++
 arch/arm/mach-keystone/keystone.c              |  4 +--
 arch/arm/mach-omap1/ams-delta-fiq-handler.S    |  1 +
 arch/arm/mach-omap2/omap-secure.c              | 39 ++++++++++++++++++++++++++
 arch/arm/mach-omap2/omap-secure.h              |  1 +
 arch/arm/mach-omap2/pmic-cpcap.c               |  4 +--
 arch/arm/mach-pxa/mainstone.c                  |  8 ++++--
 arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h |  2 +-
 arch/arm64/boot/dts/freescale/imx8mq-pinfunc.h |  2 +-
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi  |  6 ++--
 drivers/bus/mvebu-mbus.c                       |  2 +-
 drivers/soc/fsl/qbman/qman.c                   |  2 +-
 17 files changed, 73 insertions(+), 34 deletions(-)


From nicolas.ferre at microchip.com  Wed Apr  7 12:44:15 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Wed, 7 Apr 2021 13:44:15 +0200
Subject: [GIT PULL] ARM: at91: dt for 5.13
Message-ID: <20210407114415.13180-1-nicolas.ferre@microchip.com>

From: Nicolas Ferre <nicolas.ferre at microchip.com>

Arnd, Olof,

Here is first batch of dt changes for 5.13. Please pull.

Thanks, best regards,
  Nicolas

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-5.13

for you to fetch changes up to 4d930c421e3b4f5bb3a9dd6b2eba2b15d458fcb5:

  ARM: dts: at91: sama5d2: add ETB and ETM unit name (2021-04-07 13:33:19 +0200)

----------------------------------------------------------------
AT91 dt for 5.13:

- two little fixes (typo, W=1)
- a change in gpio button keycode for recent boards

----------------------------------------------------------------
Bhaskar Chowdhury (1):
      ARM: dts: at91: Fix a typo

Ludovic Desroches (1):
      ARM: dts: at91: change the key code of the gpio key

Nicolas Ferre (1):
      ARM: dts: at91: sama5d2: add ETB and ETM unit name

 arch/arm/boot/dts/at91-sam9x60ek.dts          | 3 ++-
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts   | 3 ++-
 arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_icp.dts        | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts     | 3 ++-
 arch/arm/boot/dts/at91-sama5d2_xplained.dts   | 3 ++-
 arch/arm/boot/dts/at91-sama5d3_xplained.dts   | 3 ++-
 arch/arm/boot/dts/at91sam9260ek.dts           | 3 ++-
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi   | 3 ++-
 arch/arm/boot/dts/sama5d2.dtsi                | 4 ++--
 arch/arm/boot/dts/sama5d3.dtsi                | 2 +-
 11 files changed, 21 insertions(+), 12 deletions(-)

-- 
Nicolas Ferre


From catalin.marinas at arm.com  Wed Apr  7 12:45:12 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 7 Apr 2021 12:45:12 +0100
Subject: [PATCH] arm64/sve: Rework SVE access trap to convert state in
 registers
In-Reply-To: <20210312190313.24598-1-broonie@kernel.org>
References: <20210312190313.24598-1-broonie@kernel.org>
Message-ID: <20210407114511.GA21451@arm.com>

On Fri, Mar 12, 2021 at 07:03:13PM +0000, Mark Brown wrote:
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index bec5f14b622a..ebb263b2d3b1 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -73,6 +73,7 @@ extern void sve_flush_live(void);
>  extern void sve_load_from_fpsimd_state(struct user_fpsimd_state const *state,
>  				       unsigned long vq_minus_1);
>  extern unsigned int sve_get_vl(void);
> +extern void sve_set_vq(unsigned long vq_minus_1);
>  
>  struct arm64_cpu_capabilities;
>  extern void sve_kernel_enable(const struct arm64_cpu_capabilities *__unused);
> diff --git a/arch/arm64/kernel/entry-fpsimd.S b/arch/arm64/kernel/entry-fpsimd.S
> index 2ca395c25448..3ecec60d3295 100644
> --- a/arch/arm64/kernel/entry-fpsimd.S
> +++ b/arch/arm64/kernel/entry-fpsimd.S
> @@ -48,6 +48,11 @@ SYM_FUNC_START(sve_get_vl)
>  	ret
>  SYM_FUNC_END(sve_get_vl)
>  
> +SYM_FUNC_START(sve_set_vq)
> +	sve_load_vq x0, x1, x2
> +	ret
> +SYM_FUNC_END(sve_set_vq)
> +
>  /*
>   * Load SVE state from FPSIMD state.
>   *
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 062b21f30f94..0f58e45bd3d1 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -926,9 +926,8 @@ void fpsimd_release_task(struct task_struct *dead_task)
>   * Trapped SVE access
>   *
>   * Storage is allocated for the full SVE state, the current FPSIMD
> - * register contents are migrated across, and TIF_SVE is set so that
> - * the SVE access trap will be disabled the next time this task
> - * reaches ret_to_user.
> + * register contents are migrated across, and the access trap is
> + * disabled.
>   *
>   * TIF_SVE should be clear on entry: otherwise, fpsimd_restore_current_state()
>   * would have disabled the SVE access trap for userspace during
> @@ -946,15 +945,24 @@ void do_sve_acc(unsigned int esr, struct pt_regs *regs)
>  
>  	get_cpu_fpsimd_context();
>  
> -	fpsimd_save();
> -
> -	/* Force ret_to_user to reload the registers: */
> -	fpsimd_flush_task_state(current);
> -
> -	fpsimd_to_sve(current);
>  	if (test_and_set_thread_flag(TIF_SVE))
>  		WARN_ON(1); /* SVE access shouldn't have trapped */
>  
> +	/*
> +	 * Convert the FPSIMD state to SVE, zeroing all the state that
> +	 * is not shared with FPSIMD. If (as is likely) the current
> +	 * state is live in the registers then do this there and
> +	 * update our metadata for the current task including
> +	 * disabling the trap, otherwise update our in-memory copy.
> +	 */
> +	if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
> +		sve_set_vq(sve_vq_from_vl(current->thread.sve_vl) - 1);
> +		sve_flush_live();
> +		fpsimd_bind_task_to_cpu();
> +	} else {
> +		fpsimd_to_sve(current);
> +	}
> +
>  	put_cpu_fpsimd_context();
>  }

Just to make sure I understand: in the current code, if
TIF_FOREIGN_FPSTATE is cleared and we trapped (TIF_SVE is also cleared),
the FPSIMD state is transferred to the SVE one in memory and both
TIF_SVE and TIF_FOREIGN_FPSTATE get set. The (potentially stale) SVE
state is subsequently restored via do_notify_resume(). I couldn't find
where we actually zero the in-memory SVE state or save the latest one
via do_el0_svc(). So it looks like we may restore some old SVE state
after a syscall (maybe I'm missing something but it would be nice to
follow zero or preserved approach).

With your patch in the above scenario, we no longer restore the SVE
state from memory. We just flush the live SVE registers and disable
trapping. The assumption here is that (1) when TIF_SVE is cleared, we no
longer care about any of the SVE state (memory or regs) and (2) we only
trap if TIF_SVE was cleared (i.e. we don't have a different scenario of
lazy restoring where TIF_SVE but we still trap). That's fine by me and
matches the code paths but it wasn't entirely clear in the TIF_SVE
description higher up in this file.

The other case is TIF_FOREIGN_FPSTATE being set in do_sve_acc(). Since
we never return to user with this flag set, when can we actually hit the
'else' path in your patch?

-- 
Catalin


From mripard at kernel.org  Wed Apr  7 12:45:29 2021
From: mripard at kernel.org (Maxime Ripard)
Date: Wed, 7 Apr 2021 13:45:29 +0200
Subject: [GIT PULL] Allwinner Fixes for 5.12
Message-ID: <9972a85e-60b7-49f4-a246-db3396dd4764.lettre@localhost>

Hi Arnd, Olof,

Here's the fixes PR rebase with my SoB added

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.12-1

for you to fetch changes up to 7a2f6e69e9c1060a7a09c1f8322ccb8d942b3078:

  arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference (2021-04-07 13:41:47 +0200)

----------------------------------------------------------------
One 32kHz clock fix for the beelink gs1, a CD polarity fix for the SoPine, some
MAINTAINERS maintainance, and a clk / reset switch to our headers.

----------------------------------------------------------------
Andre Przywara (1):
      arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems

Chen-Yu Tsai (1):
      arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices

Jernej Skrabec (1):
      arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference

Maxime Ripard (2):
      MAINTAINERS: Add our new mailing-list
      MAINTAINERS: Match on allwinner keyword


 MAINTAINERS                                             | 2 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 4 ++++
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi    | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ----
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi            | 4 ++--
 5 files changed, 9 insertions(+), 7 deletions(-)


-------------- 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/20210407/77a2bbde/attachment.sig>

From maxime at cerno.tech  Wed Apr  7 12:46:50 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Wed, 7 Apr 2021 13:46:50 +0200
Subject: linux-next: Signed-off-by missing for commit in the arm-soc tree
In-Reply-To: <CAK8P3a1W9oHfx47-_d1ytHN+ZJAQ3ivS4RfcbiVHQ-fU840-ag@mail.gmail.com>
References: <20210406081100.4a866aa6@canb.auug.org.au>
 <20210406081147.7a5332ed@canb.auug.org.au>
 <CAK8P3a1W9oHfx47-_d1ytHN+ZJAQ3ivS4RfcbiVHQ-fU840-ag@mail.gmail.com>
Message-ID: <20210407114650.2ed2p5aqkwwicm3k@gilmour>

On Tue, Apr 06, 2021 at 11:44:27PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 6, 2021 at 12:11 AM Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > On Tue, 6 Apr 2021 08:11:00 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
> > >
> > > Hi all,
> > >
> > > Commit
> > >
> > >   3b493ac0ac04 ("arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices")
> > >
> > > is missing a Signed-off-by from its committer.
> >
> > Sorry, that commit is in the arm-soc-fixes tree.
> 
> Thanks for the report, I've temporarily removed the sunx-fixes branch merge
> from the arm/fixes branch and will send the pull request without it.
> 
> Maxime, can you fix it up and resend the pull request?
> Feel free to add any other fixes that have come up since then.

I just did. Is there a way to prevent this from happening when one
rebase a branch that was partially committed by someone else?

git rebase --signoff doesn't seem to detect if there's already a SoB, so
it might produce duplicates which isn't great either.

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/20210407/b5746644/attachment.sig>

From j.neuschaefer at gmx.net  Wed Apr  7 13:06:39 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Wed, 7 Apr 2021 14:06:39 +0200
Subject: [PATCH v2 06/10] irqchip: Add driver for WPCM450 interrupt
 controller
In-Reply-To: <87czv6pcx2.wl-maz@kernel.org>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <20210406120921.2484986-7-j.neuschaefer@gmx.net>
 <87czv6pcx2.wl-maz@kernel.org>
Message-ID: <YG2gT7C/2P71TYfF@latitude>

On Wed, Apr 07, 2021 at 12:11:21PM +0100, Marc Zyngier wrote:
> On Tue, 06 Apr 2021 13:09:17 +0100,
> Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
...
> > diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
> > index 658c8efb4ca14..a71cf1d189ae5 100644
> > --- a/arch/arm/mach-npcm/Kconfig
> > +++ b/arch/arm/mach-npcm/Kconfig
> > @@ -10,6 +10,7 @@ config ARCH_WPCM450
> >  	bool "Support for WPCM450 BMC (Hermon)"
> >  	depends on ARCH_MULTI_V5
> >  	select CPU_ARM926T
> > +	select WPCM450_AIC
> >  	select NPCM7XX_TIMER
> >  	help
> >  	  General support for WPCM450 BMC (Hermon).
> 
> I can't take this patch with this particular hunk, as I don't have
> this file in my tree. I can either drop this line, or delay the
> merging of this patch to a later point in time.

Hmm, indeed. Please apply the patch without this hunk. I'll reintroduce
it in another patch.

> 
> The driver otherwise looks ready.

Good.

Thanks,
Jonathan
-------------- 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/20210407/de7c4cbb/attachment.sig>

From maz at kernel.org  Wed Apr  7 13:12:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 13:12:07 +0100
Subject: [PATCH v4] irqchip/irq-mst: Support polarity configuration
In-Reply-To: <20210315131848.31840-1-mark-pk.tsai@mediatek.com>
References: <20210315131848.31840-1-mark-pk.tsai@mediatek.com>
Message-ID: <87blaqpa3s.wl-maz@kernel.org>

On Mon, 15 Mar 2021 13:18:48 +0000,
Mark-PK Tsai <mark-pk.tsai at mediatek.com> wrote:
> 
> Support irq polarity configuration and save and restore the config
> when system suspend and resume.
> 
> Signed-off-by: Mark-PK Tsai <mark-pk.tsai at mediatek.com>
> ---
>  drivers/irqchip/irq-mst-intc.c | 94 ++++++++++++++++++++++++++++++++--
>  1 file changed, 91 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mst-intc.c b/drivers/irqchip/irq-mst-intc.c
> index 143657b0cf28..a2ab3f837b96 100644
> --- a/drivers/irqchip/irq-mst-intc.c
> +++ b/drivers/irqchip/irq-mst-intc.c
> @@ -13,15 +13,27 @@
>  #include <linux/of_irq.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/syscore_ops.h>
>  
> -#define INTC_MASK	0x0
> -#define INTC_EOI	0x20
> +#define MST_INTC_MAX_IRQS	64
> +
> +#define INTC_MASK		0x0
> +#define INTC_REV_POLARITY	0x10
> +#define INTC_EOI		0x20
> +
> +#ifdef CONFIG_PM_SLEEP
> +static LIST_HEAD(mst_intc_list);
> +#endif
>  
>  struct mst_intc_chip_data {
>  	raw_spinlock_t	lock;
>  	unsigned int	irq_start, nr_irqs;
>  	void __iomem	*base;
>  	bool		no_eoi;
> +#ifdef CONFIG_PM_SLEEP
> +	struct list_head entry;
> +	u16 saved_polarity_conf[DIV_ROUND_UP(MST_INTC_MAX_IRQS, 16)];
> +#endif
>  };
>  
>  static void mst_set_irq(struct irq_data *d, u32 offset)
> @@ -78,6 +90,20 @@ static void mst_intc_eoi_irq(struct irq_data *d)
>  	irq_chip_eoi_parent(d);
>  }
>  
> +static int mst_irq_chip_set_type(struct irq_data *data, unsigned int type)
> +{
> +	if (type != IRQ_TYPE_EDGE_RISING && type != IRQ_TYPE_EDGE_FALLING &&
> +	    type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_LEVEL_LOW)
> +		return -EINVAL;

All of this amounts to checking for IRQ_TYPE_{NONE,EDGE_BOTH}. Maybe
that's a better option.

> +
> +	if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING)
> +		mst_set_irq(data, INTC_REV_POLARITY);

What happens if the interrupt was set to LEVEL_LOW, then switched to
LEVEL_HIGH? You end up with a stuck reversed polarity.

> +
> +	type = IRQ_TYPE_LEVEL_HIGH;
> +
> +	return irq_chip_set_type_parent(data, type);

I'm going to fix this as below. Shout if you disagree.

Thanks,

	M.

diff --git a/drivers/irqchip/irq-mst-intc.c b/drivers/irqchip/irq-mst-intc.c
index a2ab3f837b96..f6133ae28155 100644
--- a/drivers/irqchip/irq-mst-intc.c
+++ b/drivers/irqchip/irq-mst-intc.c
@@ -92,16 +92,20 @@ static void mst_intc_eoi_irq(struct irq_data *d)
 
 static int mst_irq_chip_set_type(struct irq_data *data, unsigned int type)
 {
-	if (type != IRQ_TYPE_EDGE_RISING && type != IRQ_TYPE_EDGE_FALLING &&
-	    type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_LEVEL_LOW)
-		return -EINVAL;
-
-	if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING)
+	switch (type) {
+	case IRQ_TYPE_LEVEL_LOW:
+	case IRQ_TYPE_EDGE_FALLING:
 		mst_set_irq(data, INTC_REV_POLARITY);
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+	case IRQ_TYPE_EDGE_RISING:
+		mst_clear_irq(data, INTC_REV_POLARITY);
+		break;
+	default:
+		return -EINVAL;
+	}
 
-	type = IRQ_TYPE_LEVEL_HIGH;
-
-	return irq_chip_set_type_parent(data, type);
+	return irq_chip_set_type_parent(data, IRQ_TYPE_LEVEL_HIGH);
 }
 
 static struct irq_chip mst_intc_chip = {

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


From qii.wang at mediatek.com  Wed Apr  7 13:15:06 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Wed, 7 Apr 2021 20:15:06 +0800
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <20210406194856.GF3122@kunai>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
 <20210406194856.GF3122@kunai>
Message-ID: <1617797706.32076.1.camel@mhfsdcap03>

On Tue, 2021-04-06 at 21:48 +0200, Wolfram Sang wrote:
> On Sat, Mar 13, 2021 at 04:04:24PM +0800, qii.wang at mediatek.com wrote:
> > From: Qii Wang <qii.wang at mediatek.com>
> > 
> > tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> > clock-stretching or circuit loss, we could get device
> > clock-stretch time from dts to adjust these parameters
> > to meet the spec via EXT_CONF register.
> > 
> > Signed-off-by: Qii Wang <qii.wang at mediatek.com>
> 
> I tried to understand from the code what the new binding expresses, but
> I don't fully understand it. Is it the maximum clock stretch time?
> Because I cannot recall a device which always uses the same delay for
> clock stretching.
> 

Due to clock stretch, our HW IP cannot meet the ac-timing
spec(tSU;STA,tSU;STO). 
There isn't a same delay for clock stretching, so we need pass a
parameter which can be found through measurement to meet most
conditions.


From will at kernel.org  Wed Apr  7 13:18:56 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 13:18:56 +0100
Subject: [PATCH v2] perf: xgene: Use device_get_match_data() to simplify
 code
In-Reply-To: <1617325838-23369-1-git-send-email-tiantao6@hisilicon.com>
References: <1617325838-23369-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <20210407121856.GB15499@willie-the-truck>

On Fri, Apr 02, 2021 at 09:10:38AM +0800, Tian Tao wrote:
> Use device_get_match_data() here to simplify the code a bit.
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> ---
> v2:handled the case which device_get_match_data() return NULL.
> ---
>  drivers/perf/xgene_pmu.c | 18 ++----------------
>  1 file changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
> index ffe3bde..45f36c1 100644
> --- a/drivers/perf/xgene_pmu.c
> +++ b/drivers/perf/xgene_pmu.c
> @@ -1836,7 +1836,6 @@ static int xgene_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
>  static int xgene_pmu_probe(struct platform_device *pdev)
>  {
>  	const struct xgene_pmu_data *dev_data;
> -	const struct of_device_id *of_id;
>  	struct xgene_pmu *xgene_pmu;
>  	struct resource *res;
>  	int irq, rc;
> @@ -1856,22 +1855,9 @@ static int xgene_pmu_probe(struct platform_device *pdev)
>  	xgene_pmu->dev = &pdev->dev;
>  	platform_set_drvdata(pdev, xgene_pmu);
>  
> -	version = -EINVAL;
> -	of_id = of_match_device(xgene_pmu_of_match, &pdev->dev);
> -	if (of_id) {
> -		dev_data = (const struct xgene_pmu_data *) of_id->data;
> -		version = dev_data->id;
> -	}
> -
> -#ifdef CONFIG_ACPI
> -	if (ACPI_COMPANION(&pdev->dev)) {
> -		const struct acpi_device_id *acpi_id;
> +	dev_data = device_get_match_data(&pdev->dev);
>  
> -		acpi_id = acpi_match_device(xgene_pmu_acpi_match, &pdev->dev);
> -		if (acpi_id)
> -			version = (int) acpi_id->driver_data;
> -	}
> -#endif
> +	version = dev_data ? dev_data->id : -EINVAL;
>  	if (version < 0)
>  		return -ENODEV;

Hmm, looking at this again, are you sure this is right?

When ACPI is being used, the version is encoded directly in the driver_data
pointer of the acpi_device_id structure, yet you seem to dereference that
unconditionally here. How are you testing your patch?

Will


From maz at kernel.org  Wed Apr  7 13:31:12 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed,  7 Apr 2021 13:31:12 +0100
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
Message-ID: <161779861852.1095473.15662659062108361949.b4-ty@kernel.org>

On Tue, 6 Apr 2021 14:09:11 +0200, Jonathan Neusch?fer wrote:
> This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
> SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.
> 
> Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki
> 
> Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
> Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
> the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.
> 
> [...]

Applied to irq/irqchip-next, thanks!

[03/10] dt-bindings: interrupt-controller: Add nuvoton, wpcm450-aic
        commit: 7c18715546203a09f859dac2fe3ea8aceec5f235
[06/10] irqchip: Add driver for WPCM450 interrupt controller
        commit: fead4dd496631707549f414b4059afb86ea8fb80

Cheers,

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




From maz at kernel.org  Wed Apr  7 13:32:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed,  7 Apr 2021 13:32:07 +0100
Subject: (subset) [PATCH 0/5] stm32 usart wakeup rework
In-Reply-To: <20210319184253.5841-1-erwan.leray@foss.st.com>
References: <20210319184253.5841-1-erwan.leray@foss.st.com>
Message-ID: <161779861853.1095473.5644490984272878167.b4-ty@kernel.org>

On Fri, 19 Mar 2021 19:42:48 +0100, Erwan Le Ray wrote:
> This series reworks stm32 usart wakeup management.
> 
> Alexandre Torgue (1):
>   serial: stm32: update wakeup IRQ management
> 
> Erwan Le Ray (4):
>   serial: stm32: rework wakeup management
>   serial: stm32: clean wakeup handling in serial_suspend
>   irqchip/stm32: add usart instances exti direct event support
>   ARM: dts: stm32: Add wakeup management on stm32mp15x UART nodes
> 
> [...]

Applied to irq/irqchip-next, thanks!

[3/5] irqchip/stm32: add usart instances exti direct event support
      commit: e12c455055e9abc7403ce532616c0124a9d85ee7

Cheers,

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




From maz at kernel.org  Wed Apr  7 13:32:18 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed,  7 Apr 2021 13:32:18 +0100
Subject: [PATCH v4] irqchip/irq-mst: Support polarity configuration
In-Reply-To: <20210315131848.31840-1-mark-pk.tsai@mediatek.com>
References: <20210315131848.31840-1-mark-pk.tsai@mediatek.com>
Message-ID: <161779861853.1095473.5298722515366645691.b4-ty@kernel.org>

On Mon, 15 Mar 2021 21:18:48 +0800, Mark-PK Tsai wrote:
> Support irq polarity configuration and save and restore the config
> when system suspend and resume.

Applied to irq/irqchip-next, thanks!

[1/1] irqchip/irq-mst: Support polarity configuration
      commit: ea4aeaa5c88906eb3ca3d7d3d17a45605d2dd0de

Cheers,

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




From mindal at semihalf.com  Wed Apr  7 13:34:38 2021
From: mindal at semihalf.com (Kornel Duleba)
Date: Wed,  7 Apr 2021 14:34:38 +0200
Subject: [PATCH] arm64: dts: fsl-ls1028a: Correct ECAM PCIE window ranges
Message-ID: <20210407123438.224551-1-mindal@semihalf.com>

Currently all PCIE windows point to bus address 0x0, which does not match
the values obtained from hardware during EA.
Replace those values with CPU addresses, since in reality we
have a 1:1 mapping between the two.

Signed-off-by: Kornel Duleba <mindal at semihalf.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 262fbad8f0ec..85c62a6fabb6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -994,19 +994,19 @@ pcie at 1f0000000 { /* Integrated Endpoint Root Complex */
 			msi-map = <0 &its 0x17 0xe>;
 			iommu-map = <0 &smmu 0x17 0xe>;
 				  /* PF0-6 BAR0 - non-prefetchable memory */
-			ranges = <0x82000000 0x0 0x00000000  0x1 0xf8000000  0x0 0x160000
+			ranges = <0x82000000 0x1 0xf8000000  0x1 0xf8000000  0x0 0x160000
 				  /* PF0-6 BAR2 - prefetchable memory */
-				  0xc2000000 0x0 0x00000000  0x1 0xf8160000  0x0 0x070000
+				  0xc2000000 0x1 0xf8160000  0x1 0xf8160000  0x0 0x070000
 				  /* PF0: VF0-1 BAR0 - non-prefetchable memory */
-				  0x82000000 0x0 0x00000000  0x1 0xf81d0000  0x0 0x020000
+				  0x82000000 0x1 0xf81d0000  0x1 0xf81d0000  0x0 0x020000
 				  /* PF0: VF0-1 BAR2 - prefetchable memory */
-				  0xc2000000 0x0 0x00000000  0x1 0xf81f0000  0x0 0x020000
+				  0xc2000000 0x1 0xf81f0000  0x1 0xf81f0000  0x0 0x020000
 				  /* PF1: VF0-1 BAR0 - non-prefetchable memory */
-				  0x82000000 0x0 0x00000000  0x1 0xf8210000  0x0 0x020000
+				  0x82000000 0x1 0xf8210000  0x1 0xf8210000  0x0 0x020000
 				  /* PF1: VF0-1 BAR2 - prefetchable memory */
-				  0xc2000000 0x0 0x00000000  0x1 0xf8230000  0x0 0x020000
+				  0xc2000000 0x1 0xf8230000  0x1 0xf8230000  0x0 0x020000
 				  /* BAR4 (PF5) - non-prefetchable memory */
-				  0x82000000 0x0 0x00000000  0x1 0xfc000000  0x0 0x400000>;
+				  0x82000000 0x1 0xfc000000  0x1 0xfc000000  0x0 0x400000>;
 
 			enetc_port0: ethernet at 0,0 {
 				compatible = "fsl,enetc";
-- 
2.31.1



From will at kernel.org  Wed Apr  7 13:44:37 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 13:44:37 +0100
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
 <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
Message-ID: <20210407124437.GA15622@willie-the-truck>

[Moving Mark to To: since I'd like his view on this]

On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
> >
> > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon <will at kernel.org> wrote:
> > > >
> > > > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > > > From: Raphael Gault <raphael.gault at arm.com>
> > > > >
> > > > > Keep track of event opened with direct access to the hardware counters
> > > > > and modify permissions while they are open.
> > > > >
> > > > > The strategy used here is the same which x86 uses: every time an event
> > > > > is mapped, the permissions are set if required. The atomic field added
> > > > > in the mm_context helps keep track of the different event opened and
> > > > > de-activate the permissions when all are unmapped.
> > > > > We also need to update the permissions in the context switch code so
> > > > > that tasks keep the right permissions.
> > > > >
> > > > > In order to enable 64-bit counters for userspace when available, a new
> > > > > config1 bit is added for userspace to indicate it wants userspace counter
> > > > > access. This bit allows the kernel to decide if chaining should be
> > > > > disabled and chaining and userspace access are incompatible.
> > > > > The modes for config1 are as follows:
> > > > >
> > > > > config1 = 0 or 2 : user access enabled and always 32-bit
> > > > > config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
> > > > > config1 = 3 : user access enabled and counter size matches underlying counter.
> > > >
> > > > In this last case, how does userspace know whether it got a 32-bit or a
> > > > 64-bit counter?
> > >
> > > pmc_width in the user page. If the read loop is correct, then it
> > > doesn't matter to the user.
> >
> > Gotcha; please mention that in this comment,
> >
> > > > > +static void refresh_pmuserenr(void *mm)
> > > > > +{
> > > > > +     if (mm == current->active_mm)
> > > > > +             perf_switch_user_access(mm);
> > > > > +}
> > > > > +
> > > > > +static void armv8pmu_event_mapped(struct perf_event *event, struct mm_struct *mm)
> > > > > +{
> > > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > > +
> > > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > +             return;
> > > > > +
> > > > > +     /*
> > > > > +      * This function relies on not being called concurrently in two
> > > > > +      * tasks in the same mm.  Otherwise one task could observe
> > > > > +      * pmu_direct_access > 1 and return all the way back to
> > > > > +      * userspace with user access disabled while another task is still
> > > > > +      * doing on_each_cpu_mask() to enable user access.
> > > > > +      *
> > > > > +      * For now, this can't happen because all callers hold mmap_lock
> > > > > +      * for write.  If this changes, we'll need a different solution.
> > > > > +      */
> > > > > +     lockdep_assert_held_write(&mm->mmap_lock);
> > > > > +
> > > > > +     if (atomic_inc_return(&mm->context.pmu_direct_access) == 1)
> > > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > > > > +}
> > > >
> > > > Why do we need to cross-call here? Seems like it would be a tonne simpler to
> > > > handle the trap. Is there a reason not to do that?
> > >
> > > Alignment with x86? You didn't like the trap handler either:
> > >
> > > > Hmm... this feels pretty fragile since, although we may expect userspace only
> > > > to trigger this in the context of the specific perf use-case, we don't have
> > > > a way to detect that, so the ABI we're exposing is that EL0 accesses to
> > > > non-existent counters will return 0. I don't really think that's something
> > > > we want to commit to.
> > >
> > > Full mail: https://lore.kernel.org/r/20200928182601.GA11974 at willie-the-truck
> > >
> > > The handler would be different, but we'd still have the problem of not
> > > being able to detect the use case, right?
> >
> > Well hang on, the thing you link to was about _emulating_ the access. I'm
> > not saying we should do that, but rather just enable EL0 PMU access lazily
> > instead of using the IPI. We're going to enable it when we context-switch
> > anyway.
> >
> > The alternative is enabling EL0 access unconditionally and leaving it
> > enabled.
> 
> That BTW is what x86 originally did. This pmu_direct_access stuff came
> about as part of locking down access a bit.
> 
> In any case, I've modified this to trap. It avoids the mmap lock
> dependency too, so that's nice.
> 
> > > > > +
> > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > > +{
> > > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > > +
> > > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > +             return;
> > > > > +
> > > > > +     if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > > >
> > > > Given that the pmu_direct_access field is global per-mm, won't this go
> > > > wrong if multiple PMUs are opened by the same process but only a subset
> > > > are exposed to EL0? Perhaps pmu_direct_access should be treated as a mask
> > > > rather than a counter, so that we can 'and' it with the supported_cpus for
> > > > the PMU we're dealing with.
> > >
> > > It needs to be a count to support multiple events on the same PMU. If
> > > the event is not enabled for EL0, then we'd exit out on the
> > > ARMPMU_EL0_RD_CNTR check. So I think we're fine.
> >
> > I'm still not convinced; pmu_direct_access is shared between PMUs, so
> > testing the result of atomic_dec_and_test() just doesn't make sense to
> > me, as another PMU could be playing with the count.
> 
> How is that a problem? Let's make a concrete example:
> 
> map PMU1:event2 -> pmu_direct_access = 1 -> enable access
> map PMU2:event3 -> pmu_direct_access = 2
> map PMU1:event4 -> pmu_direct_access = 3
> unmap PMU2:event3 -> pmu_direct_access = 2
> unmap PMU1:event2 -> pmu_direct_access = 1
> unmap PMU1:event4 -> pmu_direct_access = 0 -> disable access
> 
> The only issue I can see is PMU2 remains enabled for user access until
> the last unmap. But we're sharing the mm, so who cares? Also, in this
> scenario it is the user's problem to pin themselves to cores sharing a
> PMU. If the user doesn't do that, they get to keep the pieces.

I guess I'm just worried about exposing the counters to userspace after
the PMU driver (or perf core?) thinks that they're no longer exposed in
case we leak other events. However, I'm not sure how this is supposed to
work normally: what happens if e.g. a privileged user has a per-cpu counter
for a kernel event while a task has a counter with direct access -- can that
task read the kernel event out of the PMU registers from userspace?

Will


From andrew at lunn.ch  Wed Apr  7 13:44:39 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 7 Apr 2021 14:44:39 +0200
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <SN6PR11MB3136E862F38D7C573759989188759@SN6PR11MB3136.namprd11.prod.outlook.com>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
 <YGsgHWItHcLFV9Kg@lunn.ch>
 <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YGy/N+cRLGTifJSN@lunn.ch>
 <SN6PR11MB3136E862F38D7C573759989188759@SN6PR11MB3136.namprd11.prod.outlook.com>
Message-ID: <YG2pN8uupbXP7xqU@lunn.ch>

> Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> multi-gige PHY can do rate adaption right?

The Marvell/Marvell multi-gige PHY can also do rate
adaptation. Marvell buying Aquantia made naming messy :-(
I should probably use part numbers.

> Hence, we still need to take care of others PHYs.

Yes, it just makes working around the broken design harder if you want
to get the most out of the hardware.

   Andrew


From yukuai3 at huawei.com  Wed Apr  7 13:53:58 2021
From: yukuai3 at huawei.com (Yu Kuai)
Date: Wed, 7 Apr 2021 20:53:58 +0800
Subject: [PATCH] stm class: initialize static variable in declaration
Message-ID: <20210407125358.4135345-1-yukuai3@huawei.com>

mutex lock can be initialized automatically with DEFINE_MUTEX()
rather than explicitly calling mutex_init().

list head can be initialized automatically with LIST_HEAD() rather
than explicitly calling INIT_LIST_HEAD().

srcu_struct can be initialized automatically with DEFINE_STATIC_SRCU()
rather than explicitly calling init_srcu_struct().

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
---
 drivers/hwtracing/stm/core.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 2712e699ba08..1e13993e7969 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -31,7 +31,7 @@ static unsigned int stm_core_up;
  * stm_source_write() caller, which may want to have as little overhead as
  * possible.
  */
-static struct srcu_struct stm_source_srcu;
+DEFINE_STATIC_SRCU(stm_source_srcu);
 
 static ssize_t masters_show(struct device *dev,
 			    struct device_attribute *attr,
@@ -366,8 +366,8 @@ static int major_match(struct device *dev, const void *data)
  * Modules can implement STM protocol drivers and (un-)register them
  * with the STM class framework.
  */
-static struct list_head stm_pdrv_head;
-static struct mutex stm_pdrv_mutex;
+static LIST_HEAD(stm_pdrv_head);
+static DEFINE_MUTEX(stm_pdrv_mutex);
 
 struct stm_pdrv_entry {
 	struct list_head			entry;
@@ -1324,10 +1324,6 @@ static int __init stm_core_init(void)
 	if (err)
 		goto err_src;
 
-	init_srcu_struct(&stm_source_srcu);
-	INIT_LIST_HEAD(&stm_pdrv_head);
-	mutex_init(&stm_pdrv_mutex);
-
 	/*
 	 * So as to not confuse existing users with a requirement
 	 * to load yet another module, do it here.
-- 
2.25.4



From broonie at kernel.org  Wed Apr  7 13:48:06 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 7 Apr 2021 13:48:06 +0100
Subject: [PATCH] arm64/sve: Rework SVE access trap to convert state in
 registers
In-Reply-To: <20210407114511.GA21451@arm.com>
References: <20210312190313.24598-1-broonie@kernel.org>
 <20210407114511.GA21451@arm.com>
Message-ID: <20210407124806.GC5510@sirena.org.uk>

On Wed, Apr 07, 2021 at 12:45:12PM +0100, Catalin Marinas wrote:
> On Fri, Mar 12, 2021 at 07:03:13PM +0000, Mark Brown wrote:

> > -	/* Force ret_to_user to reload the registers: */
> > -	fpsimd_flush_task_state(current);

> Just to make sure I understand: in the current code, if
> TIF_FOREIGN_FPSTATE is cleared and we trapped (TIF_SVE is also cleared),
> the FPSIMD state is transferred to the SVE one in memory and both
> TIF_SVE and TIF_FOREIGN_FPSTATE get set. The (potentially stale) SVE

Right, TIF_FOREIGN_FPSTATE is unconditionally set in the current code.

> state is subsequently restored via do_notify_resume(). I couldn't find
> where we actually zero the in-memory SVE state or save the latest one
> via do_el0_svc(). So it looks like we may restore some old SVE state
> after a syscall (maybe I'm missing something but it would be nice to
> follow zero or preserved approach).

The state is currently converted via the fpsimd_to_sve() call in the
trap handler, that *should* be dealing with anything required for
conversion.  You're right that this seems to miss zeroing anything
outside of the values it immediately writes - I might be missing
something though.  It's only going to leak information from the current
task and it is within the documented behaviour so it's not a bug but as
such but it does seem cleaner, ought to have a memset() in there
somewhere.

> With your patch in the above scenario, we no longer restore the SVE
> state from memory. We just flush the live SVE registers and disable
> trapping. The assumption here is that (1) when TIF_SVE is cleared, we no
> longer care about any of the SVE state (memory or regs) and (2) we only
> trap if TIF_SVE was cleared (i.e. we don't have a different scenario of
> lazy restoring where TIF_SVE but we still trap). That's fine by me and

Indeed.

> matches the code paths but it wasn't entirely clear in the TIF_SVE
> description higher up in this file.

I'm not seeing what's missing from the discussion there?  It explicitly
says that if TIF_SVE is set we don't trap and if it's clear then we do
trap and which registers are valid in each state which I think makes the
behaviour here clear but perhaps I've been looking at this too much, or
you were looking for this in a slightly different place.

> The other case is TIF_FOREIGN_FPSTATE being set in do_sve_acc(). Since
> we never return to user with this flag set, when can we actually hit the
> 'else' path in your patch?

We'd have to have been preempted between entering the kernel and
actually handling the access trap, I can't think of a scenario where
that would happen but it seemed easier to have the code to handle it
than to make absolutely sure that there was no possible case that I was
missing.  I think we should have the detection code either way in case
it does end up happening somehow but it could be changed to use
WARN_ON_ONCE() or something instead of silently handling it?
-------------- 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/20210407/3308e4f3/attachment.sig>

From linux at armlinux.org.uk  Wed Apr  7 14:00:07 2021
From: linux at armlinux.org.uk (Russell King - ARM Linux admin)
Date: Wed, 7 Apr 2021 14:00:07 +0100
Subject: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac
In-Reply-To: <YG2pN8uupbXP7xqU@lunn.ch>
References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com>
 <YGsMbBW9h4H1y/T8@lunn.ch>
 <CO1PR11MB5044B1F80C412E6F0CAFD5509D779@CO1PR11MB5044.namprd11.prod.outlook.com>
 <YGsgHWItHcLFV9Kg@lunn.ch>
 <SN6PR11MB313690E7953BF715A8F488D688769@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YGy/N+cRLGTifJSN@lunn.ch>
 <SN6PR11MB3136E862F38D7C573759989188759@SN6PR11MB3136.namprd11.prod.outlook.com>
 <YG2pN8uupbXP7xqU@lunn.ch>
Message-ID: <20210407130006.GH1463@shell.armlinux.org.uk>

On Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote:
> > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> > multi-gige PHY can do rate adaption right?
> 
> The Marvell/Marvell multi-gige PHY can also do rate
> adaptation. Marvell buying Aquantia made naming messy :-(
> I should probably use part numbers.
> 
> > Hence, we still need to take care of others PHYs.
> 
> Yes, it just makes working around the broken design harder if you want
> to get the most out of the hardware.

FYI, we really need to come up with a good solution to the rate
adaption issue. What we have today really is not good.

For example, take a MAC that supports only 2500base-X connected to a
PHY that does rate adaption from 2500base-X to media speed.

So, the PHY could be capable of 10, 100, 1G and 2.5G media speeds,
and would advertise those in its supported mask. The MAC however
would only report (via the validate callback) support for 2.5G speed
because that's all that 2500base-X supports.

What we really want when a rate adapting capable PHY is connected is
to ignore what ethtool link modes the MAC supports beyond "does it
support this interface type" and just use the PHY supported mask.
However, that's another property of the PHY that we need to know from
phylib, and it's not clear when that property should be made available.
As we know from Marvell PHYs, it depends on the configurable MAC_TYPE
setting, so could only be available once we've selected an interface
mode for the PHY. On the other hand, we might need to know what
interface mode(s) are available from the PHY and MAC to select an
appropriate mode.

This is not easy problems to overcome; I have had some patches for some
time which allow some combination of MAC and PHY to advertise which
interface mode(s) they support but I haven't been entirely happy with
them to push them upstream - and it would be another phylink API change
which means having to maintain the new and old code until everything
has been updated (thereby making stuff a lot more complex.) After the
last round of phylink API updates and the hostility from people over
that, this is a big demotivating factor.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


From lkp at intel.com  Wed Apr  7 14:08:23 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 7 Apr 2021 21:08:23 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1277/1704] drivers/gpio/gpio-xilinx.c:94:34:
 warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes
 pointer from integer without a cast
Message-ID: <202104072117.6OAcSRYS-lkp@intel.com>

Hi Michal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   914337937cb6a106a2942347d8c8feacd2223299
commit: af0c19b6f15388c554317280433100fd9f3d7d0a [1277/1704] gpio: xilinx: Use xilinx tested gpio driver
config: x86_64-randconfig-s022-20210407 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-279-g6d5d9b42-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/af0c19b6f15388c554317280433100fd9f3d7d0a
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout af0c19b6f15388c554317280433100fd9f3d7d0a
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-xilinx.c:68:25: error: field 'mmchip' has incomplete type
      68 |  struct of_mm_gpio_chip mmchip;
         |                         ^~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_get':
   drivers/gpio/gpio-xilinx.c:94:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror=implicit-function-declaration]
      94 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
>> drivers/gpio/gpio-xilinx.c:94:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   In file included from arch/x86/include/asm/bitops.h:16,
                    from include/linux/bitops.h:26,
                    from drivers/gpio/gpio-xilinx.c:15:
   include/linux/kernel.h:994:32: error: dereferencing pointer to incomplete type 'struct of_mm_gpio_chip'
     994 |  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
         |                                ^~~~~~
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
     330 |   if (!(condition))     \
         |         ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/kernel.h:994:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
     994 |  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
         |  ^~~~~~~~~~~~~~~~
   include/linux/kernel.h:994:20: note: in expansion of macro '__same_type'
     994 |  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
         |                    ^~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:96:6: note: in expansion of macro 'container_of'
      96 |      container_of(mm_gc, struct xgpio_instance, mmchip);
         |      ^~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_set':
   drivers/gpio/gpio-xilinx.c:115:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     115 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_set_multiple':
   drivers/gpio/gpio-xilinx.c:147:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     147 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_dir_in':
   drivers/gpio/gpio-xilinx.c:187:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     187 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_dir_out':
   drivers/gpio/gpio-xilinx.c:218:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     218 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_xlate':
   drivers/gpio/gpio-xilinx.c:274:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     274 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:277:8: error: 'struct gpio_chip' has no member named 'of_gpio_n_cells'
     277 |  if (gc->of_gpio_n_cells == 3 && flags)
         |        ^~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_irq_mask':
   drivers/gpio/gpio-xilinx.c:315:12: warning: conversion from 'long unsigned int' to 'unsigned int' changes value from '18446744071562067967' to '2147483647' [-Woverflow]
     315 |            ~XGPIO_GIER_IE);
   drivers/gpio/gpio-xilinx.c:50:51: note: in definition of macro 'xgpio_writereg'
      50 | # define xgpio_writereg(offset, val) __raw_writel(val, offset)
         |                                                   ^~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_to_irq':
   drivers/gpio/gpio-xilinx.c:392:34: warning: initialization of 'struct of_mm_gpio_chip *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
     392 |  struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
         |                                  ^~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_remove':
   drivers/gpio/gpio-xilinx.c:576:2: error: implicit declaration of function 'of_mm_gpiochip_remove'; did you mean 'gpiochip_remove'? [-Werror=implicit-function-declaration]
     576 |  of_mm_gpiochip_remove(&chip->mmchip);
         |  ^~~~~~~~~~~~~~~~~~~~~
         |  gpiochip_remove
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_of_probe':
   drivers/gpio/gpio-xilinx.c:676:11: error: implicit declaration of function 'of_mm_gpiochip_add'; did you mean 'gpiochip_add'? [-Werror=implicit-function-declaration]
     676 |  status = of_mm_gpiochip_add(np, &chip->mmchip);
         |           ^~~~~~~~~~~~~~~~~~
         |           gpiochip_add
   cc1: some warnings being treated as errors


vim +94 drivers/gpio/gpio-xilinx.c

    52	
    53	/**
    54	 * struct xgpio_instance - Stores information about GPIO device
    55	 * @mmchip: OF GPIO chip for memory mapped banks
    56	 * @mmchip_dual: Pointer to the OF dual gpio chip
    57	 * @gpio_state: GPIO state shadow register
    58	 * @gpio_dir: GPIO direction shadow register
    59	 * @offset: GPIO channel offset
    60	 * @irq_base: GPIO channel irq base address
    61	 * @irq_enable: GPIO irq enable/disable bitfield
    62	 * @no_init: No intitialisation at probe
    63	 * @gpio_lock: Lock used for synchronization
    64	 * @irq_domain: irq_domain of the controller
    65	 * @clk: clock resource for this driver
    66	 */
    67	struct xgpio_instance {
  > 68		struct of_mm_gpio_chip mmchip;
    69		struct of_mm_gpio_chip *mmchip_dual;
    70		u32 gpio_state;
    71		u32 gpio_dir;
    72		u32 offset;
    73		int irq_base;
    74		u32 irq_enable;
    75		bool no_init;
    76		spinlock_t gpio_lock;
    77		struct irq_domain *irq_domain;
    78		struct clk *clk;
    79	};
    80	
    81	/**
    82	 * xgpio_get - Read the specified signal of the GPIO device.
    83	 * @gc:     Pointer to gpio_chip device structure.
    84	 * @gpio:   GPIO signal number.
    85	 *
    86	 * This function reads the specified signal of the GPIO device.
    87	 *
    88	 * Return:
    89	 * 0 if direction of GPIO signals is set as input otherwise it
    90	 * returns negative error value.
    91	 */
    92	static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
    93	{
  > 94		struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
    95		struct xgpio_instance *chip =
    96		    container_of(mm_gc, struct xgpio_instance, mmchip);
    97	
    98		void __iomem *regs = mm_gc->regs + chip->offset;
    99	
   100		return !!(xgpio_readreg(regs + XGPIO_DATA_OFFSET) & BIT(gpio));
   101	}
   102	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31327 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210407/648d690b/attachment-0001.gz>

From lkp at intel.com  Wed Apr  7 14:08:18 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 7 Apr 2021 21:08:18 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1296/1704]
 drivers/usb/dwc3/dwc3-of-simple.c:231:40: sparse: sparse: incorrect type in
 assignment (different address spaces)
Message-ID: <202104072112.ZprHDtoa-lkp@intel.com>

Hi Vishal,

First bad commit (maybe != root cause):

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   914337937cb6a106a2942347d8c8feacd2223299
commit: 0b197959bbbdb68e1da974bd013339f08704b178 [1296/1704] staging: xlnxsync: Fix the uapi header license
config: x86_64-randconfig-s021-20210407 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-279-g6d5d9b42-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/0b197959bbbdb68e1da974bd013339f08704b178
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 0b197959bbbdb68e1da974bd013339f08704b178
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/usb/dwc3/dwc3-of-simple.c:231:40: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected void *platform_data @@     got void [noderef] <asn:2> *regs @@
   drivers/usb/dwc3/dwc3-of-simple.c:231:40: sparse:     expected void *platform_data
   drivers/usb/dwc3/dwc3-of-simple.c:231:40: sparse:     got void [noderef] <asn:2> *regs

vim +231 drivers/usb/dwc3/dwc3-of-simple.c

6d0468b837bc2b Michal Simek 2020-03-16  211  
783997b6a777ef Piyush Mehta 2020-01-23  212  static int dwc3_simple_set_phydata(struct dwc3_of_simple *simple)
783997b6a777ef Piyush Mehta 2020-01-23  213  {
783997b6a777ef Piyush Mehta 2020-01-23  214  	struct device		*dev = simple->dev;
783997b6a777ef Piyush Mehta 2020-01-23  215  	struct device_node	*np = dev->of_node;
783997b6a777ef Piyush Mehta 2020-01-23  216  	struct phy		*phy;
783997b6a777ef Piyush Mehta 2020-01-23  217  
783997b6a777ef Piyush Mehta 2020-01-23  218  	np = of_get_next_child(np, NULL);
783997b6a777ef Piyush Mehta 2020-01-23  219  
783997b6a777ef Piyush Mehta 2020-01-23  220  	if (np) {
783997b6a777ef Piyush Mehta 2020-01-23  221  		phy = of_phy_get(np, "usb3-phy");
783997b6a777ef Piyush Mehta 2020-01-23  222  		if (IS_ERR(phy)) {
783997b6a777ef Piyush Mehta 2020-01-23  223  			dev_err(dev, "%s: Can't find usb3-phy\n", __func__);
783997b6a777ef Piyush Mehta 2020-01-23  224  			return PTR_ERR(phy);
783997b6a777ef Piyush Mehta 2020-01-23  225  		}
783997b6a777ef Piyush Mehta 2020-01-23  226  
783997b6a777ef Piyush Mehta 2020-01-23  227  		/* Store phy for future usage */
783997b6a777ef Piyush Mehta 2020-01-23  228  		simple->phy = phy;
783997b6a777ef Piyush Mehta 2020-01-23  229  
783997b6a777ef Piyush Mehta 2020-01-23  230  		/* assign USB vendor regs addr to phy platform_data */
783997b6a777ef Piyush Mehta 2020-01-23 @231  		phy->dev.platform_data = simple->regs;
783997b6a777ef Piyush Mehta 2020-01-23  232  
783997b6a777ef Piyush Mehta 2020-01-23  233  		phy_put(phy);
783997b6a777ef Piyush Mehta 2020-01-23  234  	} else {
783997b6a777ef Piyush Mehta 2020-01-23  235  		dev_err(dev, "%s: Can't find child node\n", __func__);
783997b6a777ef Piyush Mehta 2020-01-23  236  		return -EINVAL;
783997b6a777ef Piyush Mehta 2020-01-23  237  	}
783997b6a777ef Piyush Mehta 2020-01-23  238  
783997b6a777ef Piyush Mehta 2020-01-23  239  	return 0;
783997b6a777ef Piyush Mehta 2020-01-23  240  }
783997b6a777ef Piyush Mehta 2020-01-23  241  

:::::: The code at line 231 was first introduced by commit
:::::: 783997b6a777efb7efa5fa47602d04a7ddcbee87 dwc3: Add support for setting USB control registers as phy platform data

:::::: TO: Piyush Mehta <piyush.mehta at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33039 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210407/71058241/attachment-0001.gz>

From quan at os.amperecomputing.com  Wed Apr  7 14:09:50 2021
From: quan at os.amperecomputing.com (Quan Nguyen)
Date: Wed, 7 Apr 2021 20:09:50 +0700
Subject: [PATCH v2 0/3] Add Aspeed SSIF BMC driver
In-Reply-To: <20210402142124.GV507977@minyard.net>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210402142124.GV507977@minyard.net>
Message-ID: <0e7fceff-4a01-5cb0-72eb-8b47d598f1c3@os.amperecomputing.com>

Hi Corey,

Thank you for reviewing
I'll put my respond inline below.

-Quan

On 02/04/2021 21:21, Corey Minyard wrote:
> On Tue, Mar 30, 2021 at 09:10:26PM +0700, Quan Nguyen wrote:
>> This series add support for the Aspeed specific SSIF BMC driver which
>> is to perform in-band IPMI communication with the host in management
>> (BMC) side.
> 
> I don't have any specific feedback for this, but I'm wondering if it's
> really necessary.
> 
> Why can't the BMC just open the I2C device and use it?  Is there any
> functionality that this provides that cannot be accomplished from
> userland access to the I2C device?  I don't see any.
>
> If it tied into some existing framework to give abstract access to a BMC
> slave side interface, I'd be ok with this.  But I don't see that.
> 

The SSIF at the BMC side acts as an I2C slave and we think that the 
kernel driver is unavoidable to handle the I2c slave events 
(https://www.kernel.org/doc/html/latest/i2c/slave-interface.html)

And to make it works with existing OpenBMC IPMI stack, a userspace part, 
ssifbridge, is needed (https://github.com/openbmc/ssifbridge). This 
ssifbridge is to connect this driver with the OpenBMC IPMI stack so the 
IPMI stack can communicate via SSIF channel in similar way that was 
implemented with BT and KCS (ie: btbridge/kcsbridge and its corespondent 
kernel drivers (https://github.com/openbmc/btbridge and 
https://github.com/openbmc/kcsbridge))

> Unless there is a big need to have this in the kernel, I'm against
> including this and would suggest you do all this work in userland.
> Perhaps write a library.  Sorry, but I'm trying to do my part to reduce
> unnecessary things in the kernel.
> 
> Thanks,
> 
> -corey
> 


From acme at kernel.org  Wed Apr  7 14:11:23 2021
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Wed, 7 Apr 2021 10:11:23 -0300
Subject: [PATCH v3 0/6] perf arm64 metricgroup support
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <YG2ve4j8IwyJ7W2N@kernel.org>

Em Wed, Apr 07, 2021 at 06:32:44PM +0800, John Garry escreveu:
> This series contains support to get basic metricgroups working for
> arm64 CPUs.
> 
> Initial support is added for HiSilicon hip08 platform.
> 
> Some sample usage on Huawei D06 board:
> 
>  $ ./perf list metric    

Thanks, applied.

- Arnaldo

 
> List of pre-defined events (to be used in -e): 
> 
> Metrics:     
> 
>   bp_misp_flush
>        [BP misp flush L3 topdown metric]
>   branch_mispredicts
>        [Branch mispredicts L2 topdown metric]
>   core_bound
>        [Core bound L2 topdown metric]
>   divider
>        [Divider L3 topdown metric]
>   exe_ports_util
>        [EXE ports util L3 topdown metric]
>   fetch_bandwidth_bound
>        [Fetch bandwidth bound L2 topdown metric]
>   fetch_latency_bound
>        [Fetch latency bound L2 topdown metric]
>   fsu_stall
>        [FSU stall L3 topdown metric]
>   idle_by_icache_miss
> 
> $ sudo ./perf stat -v -M core_bound sleep 1
> Using CPUID 0x00000000480fd010
> metric expr (exe_stall_cycle - (mem_stall_anyload + armv8_pmuv3_0 at event\=0x7005@)) / cpu_cycles for core_bound
> found event cpu_cycles
> found event armv8_pmuv3_0/event=0x7005/
> found event exe_stall_cycle
> found event mem_stall_anyload
> adding {cpu_cycles -> armv8_pmuv3_0/event=0x7001/
> mem_stall_anyload -> armv8_pmuv3_0/event=0x7004/
> Control descriptor is not initialized
> cpu_cycles: 989433 385050 385050
> armv8_pmuv3_0/event=0x7005/: 19207 385050 385050
> exe_stall_cycle: 900825 385050 385050
> mem_stall_anyload: 253516 385050 385050
> 
> Performance counter stats for 'sleep':
> 
> 989,433      cpu_cycles      #     0.63 core_bound
>   19,207      armv8_pmuv3_0/event=0x7005/
>  900,825      exe_stall_cycle
>  253,516      mem_stall_anyload
> 
>        0.000805809 seconds time elapsed
> 
>        0.000875000 seconds user
>        0.000000000 seconds sys
>        
> perf stat --topdown is not supported, as this requires the CPU PMU to
> expose (alias) events for the TopDown L1 metrics from sysfs, which arm 
> does not do. To get that to work, we probably need to make perf use the
> pmu-events cpumap to learn about those alias events.
> 
> Metric reuse support is added for pmu-events parse metric testcase.
> This had been broken on power9 recently:
> https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/ 
> 
> Differences to v2:
> - Add TB and RB tags (Thanks!)
> - Rename metricgroup__find_metric() from metricgroup_find_metric()
> - Change resolve_metric_simple() to rescan after any insert
> 
> Differences to v1:
> - Add pmu_events_map__find() as arm64-specific function
> - Fix metric reuse for pmu-events parse metric testcase 
> 
> John Garry (6):
>   perf metricgroup: Make find_metric() public with name change
>   perf test: Handle metric reuse in pmu-events parsing test
>   perf pmu: Add pmu_events_map__find()
>   perf vendor events arm64: Add Hisi hip08 L1 metrics
>   perf vendor events arm64: Add Hisi hip08 L2 metrics
>   perf vendor events arm64: Add Hisi hip08 L3 metrics
> 
>  tools/perf/arch/arm64/util/Build              |   1 +
>  tools/perf/arch/arm64/util/pmu.c              |  25 ++
>  .../arch/arm64/hisilicon/hip08/metrics.json   | 233 ++++++++++++++++++
>  tools/perf/tests/pmu-events.c                 |  83 ++++++-
>  tools/perf/util/metricgroup.c                 |  12 +-
>  tools/perf/util/metricgroup.h                 |   3 +-
>  tools/perf/util/pmu.c                         |   5 +
>  tools/perf/util/pmu.h                         |   1 +
>  tools/perf/util/s390-sample-raw.c             |   4 +-
>  9 files changed, 356 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/pmu.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/hisilicon/hip08/metrics.json
> 
> -- 
> 2.26.2
> 

-- 

- Arnaldo


From leo.yan at linaro.org  Wed Apr  7 14:15:29 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 7 Apr 2021 21:15:29 +0800
Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
In-Reply-To: <AM6PR08MB335124DC0080EA95A817D71786769@AM6PR08MB3351.eurprd08.prod.outlook.com>
References: <20210403072346.30430-1-leo.yan@linaro.org>
 <AM6PR08MB335124DC0080EA95A817D71786769@AM6PR08MB3351.eurprd08.prod.outlook.com>
Message-ID: <20210407131529.GA585163@leoy-ThinkPad-X240s>

Hi Al,

On Tue, Apr 06, 2021 at 09:38:32AM +0000, Al Grant wrote:

[...]

> > This patch set is to enable timestamp for Arm SPE trace.  It reads out TSC
> > parameters from mmap page and stores into auxtrace info structure;
> 
> Why not synthesize a PERF_RECORD_TIME_CONV - isn't that specifically to
> capture the TSC parameters from the mmap page? If a generic mechanism
> exists it would be better to use it, otherwise we'll have to do this again for
> future trace formats.

Good point!  Actually "perf record" tool has synthesized event
PERF_RECORD_TIME_CONV.  This patch series is studying the
implementation from Intel-PT, so the question is why the existed
implementations (like Intel-PT, Intel-BTS) don't directly use
PERF_RECORD_TIME_CONV for retriving TSC parameters.

I agree using PERF_RECORD_TIME_CONV for TSC parameter is better than
extending auxtrace info.  Will experiment for this.

> perf_read_tsc_conversion and perf_event__synth_time_conv are currently
> in arch/x86/util/tsc.c, but nothing in them is x86-specific and they could be
> moved somewhere more generic.

This is not true on the mainline kernel; these functions have been
moved into the file util/tsc.c.

Thanks for suggestions,
Leo


From maz at kernel.org  Wed Apr  7 14:18:04 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 14:18:04 +0100
Subject: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <20210316134338.18052-3-zhukeqian1@huawei.com>
References: <20210316134338.18052-1-zhukeqian1@huawei.com>
 <20210316134338.18052-3-zhukeqian1@huawei.com>
Message-ID: <878s5up71v.wl-maz@kernel.org>

On Tue, 16 Mar 2021 13:43:38 +0000,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
> 
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
> 
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
> 
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
> 
> This adds device_rough_page_shift() to check these two points when
> selecting block mapping size.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
> 
> Mainly for RFC, not fully tested. I will fully test it when the
> code logic is well accepted.
> 
> ---
>  arch/arm64/kvm/mmu.c | 42 ++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..224aa15eb4d9 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -624,6 +624,36 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>  }
>  
> +/*
> + * Find a mapping size that properly insides the intersection of vma and
> + * memslot. And hva and pa have the same alignment to this mapping size.
> + * It's rough because there are still other restrictions, which will be
> + * checked by the following fault_supports_stage2_huge_mapping().

I don't think these restrictions make complete sense to me. If this is
a PFNMAP VMA, we should use the biggest mapping size that covers the
VMA, and not more than the VMA.

> + */
> +static short device_rough_page_shift(struct kvm_memory_slot *memslot,
> +				     struct vm_area_struct *vma,
> +				     unsigned long hva)
> +{
> +	size_t size = memslot->npages * PAGE_SIZE;
> +	hva_t sec_start = max(memslot->userspace_addr, vma->vm_start);
> +	hva_t sec_end = min(memslot->userspace_addr + size, vma->vm_end);
> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= sec_start &&
> +	    ALIGN(hva, PUD_SIZE) <= sec_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= sec_start &&
> +	    ALIGN(hva, PMD_SIZE) <= sec_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +
>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>  					       unsigned long hva,
>  					       unsigned long map_size)
> @@ -769,7 +799,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  	}
>  
> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> +	/*
> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> +	 * get block mapping for device MMIO region.
> +	 */
>  	mmap_read_lock(current->mm);
>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>  	if (unlikely(!vma)) {
> @@ -780,11 +813,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  
>  	if (is_vm_hugetlb_page(vma))
>  		vma_shift = huge_page_shift(hstate_vma(vma));
> +	else if (vma->vm_flags & VM_PFNMAP)
> +		vma_shift = device_rough_page_shift(memslot, vma, hva);
>  	else
>  		vma_shift = PAGE_SHIFT;
>  
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	if (logging_active) {
>  		force_pte = true;
>  		vma_shift = PAGE_SHIFT;

But why should we downgrade to page-size mappings if logging? This is
a device, and you aren't moving the device around, are you? Or is your
device actually memory with a device mapping that you are trying to
migrate?

>  	}
> @@ -855,7 +889,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  
>  	if (kvm_is_device_pfn(pfn)) {
>  		device = true;
> -		force_pte = true;
> +		force_pte = (vma_pagesize == PAGE_SIZE);
>  	} else if (logging_active && !write_fault) {
>  		/*
>  		 * Only actually map the page as writable if this was a write
> -- 
> 2.19.1
> 
> 

Thanks,

	M.

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


From robh+dt at kernel.org  Wed Apr  7 14:18:58 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Wed, 7 Apr 2021 08:18:58 -0500
Subject: [PATCH 1/3] dt-bindings: pci: Add DT binding for Toshiba Visconti
 PCIe controller
In-Reply-To: <20210407031839.386088-2-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210407031839.386088-2-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <CAL_JsqJew19jBJ-WpGNCK2AD+nUQsQBjJ7-ye9Cgort8AuG8mQ@mail.gmail.com>

On Tue, Apr 6, 2021 at 10:19 PM Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu at toshiba.co.jp> wrote:
>
> This commit adds the Device Tree binding documentation that allows
> to describe the PCIe controller found in Toshiba Visconti SoCs.
>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> ---
>  .../bindings/pci/toshiba,visconti-pcie.yaml   | 121 ++++++++++++++++++
>  1 file changed, 121 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
> new file mode 100644
> index 000000000000..8ab60c235007
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings
> +
> +maintainers:
> +  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> +
> +description: |+
> +  Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP.
> +
> +allOf:
> +  - $ref: /schemas/pci/pci-bus.yaml#
> +
> +properties:
> +  compatible:
> +    const: toshiba,visconti-pcie
> +
> +  reg:
> +    items:
> +      - description: Data Bus Interface (DBI) registers.
> +      - description: PCIe configuration space region.
> +      - description: Visconti specific additional registers.
> +      - description: Visconti specific SMU registers
> +      - description: Visconti specific memory protection unit registers (MPU)
> +
> +  reg-names:
> +    items:
> +      - const: dbi
> +      - const: config
> +      - const: ulreg
> +      - const: smu
> +      - const: mpu
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: PCIe reference clock
> +      - description: PCIe system clock
> +      - description: Auxiliary clock
> +
> +  clock-names:
> +    items:
> +      - const: pcie_refclk
> +      - const: sysclk
> +      - const: auxclk
> +
> +  num-lanes:
> +    const: 2
> +
> +  num-viewport:
> +    const: 8

Drop this, we detect this now.

> +
> +required:

Drop everything that pci-bus.yaml already requires.

> +  - reg
> +  - reg-names
> +  - interrupts
> +  - "#address-cells"
> +  - "#size-cells"
> +  - "#interrupt-cells"
> +  - interrupt-map
> +  - interrupt-map-mask
> +  - ranges
> +  - bus-range

If you support 0-0xff, there's no need for this to be required.

> +  - device_type
> +  - num-lanes
> +  - num-viewport
> +  - clocks
> +  - clock-names
> +  - max-link-speed
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        pcie: pcie at 28400000 {
> +            compatible = "toshiba,visconti-pcie";
> +            reg = <0x0 0x28400000 0x0 0x00400000>,
> +                  <0x0 0x70000000 0x0 0x10000000>,
> +                  <0x0 0x28050000 0x0 0x00010000>,
> +                  <0x0 0x24200000 0x0 0x00002000>,
> +                  <0x0 0x24162000 0x0 0x00001000>;
> +            reg-names  = "dbi", "config", "ulreg", "smu", "mpu";
> +            device_type = "pci";
> +            bus-range = <0x00 0xff>;
> +            num-lanes = <2>;
> +            num-viewport = <8>;
> +
> +            #address-cells = <3>;
> +            #size-cells = <2>;
> +            #interrupt-cells = <1>;
> +            ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>,
> +                     <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>;
> +            interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
> +            interrupt-names = "intr";
> +            interrupt-map-mask = <0 0 0 7>;
> +            interrupt-map =
> +                <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> +                 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> +                 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> +                 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
> +            clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>;
> +            clock-names = "pcie_refclk", "sysclk", "auxclk";
> +            max-link-speed = <2>;
> +
> +            status = "disabled";

Don't show status in examples.

> +        };
> +    };
> +...
> --
> 2.30.0.rc2
>


From yuehaibing at huawei.com  Wed Apr  7 14:25:43 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 21:25:43 +0800
Subject: [PATCH v2 -next] dmaengine: at_xdmac: Remove unused inline function
 at_xdmac_csize()
Message-ID: <20210407132543.23652-1-yuehaibing@huawei.com>

commit 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
left behind this, so can remove it.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus at microchip.com>
---
v2: Fix commit log
---
 drivers/dma/at_xdmac.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index fe45ad5d06c4..64a52bf4d737 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -344,17 +344,6 @@ static inline int at_xdmac_chan_is_paused(struct at_xdmac_chan *atchan)
 	return test_bit(AT_XDMAC_CHAN_IS_PAUSED, &atchan->status);
 }
 
-static inline int at_xdmac_csize(u32 maxburst)
-{
-	int csize;
-
-	csize = ffs(maxburst) - 1;
-	if (csize > 4)
-		csize = -EINVAL;
-
-	return csize;
-};
-
 static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
 {
 	return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
-- 
2.17.1



From andy.shevchenko at gmail.com  Wed Apr  7 14:27:42 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Wed, 7 Apr 2021 16:27:42 +0300
Subject: [PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace
 using ioremap_np
In-Reply-To: <20210402090542.131194-12-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-12-marcan@marcan.st>
Message-ID: <CAHp75Vcghw6=05vbhX5J8sHoo78JMoq5z4w9__XcocrtRVjF3g@mail.gmail.com>

On Fri, Apr 2, 2021 at 12:07 PM Hector Martin <marcan at marcan.st> wrote:
>
> Now that we have ioremap_np(), we can make pci_remap_cfgspace() default
> to it, falling back to ioremap() on platforms where it is not available.
>
> Remove the arm64 implementation, since that is now redundant. Future
> cleanups should be able to do the same for other arches, and eventually
> make the generic pci_remap_cfgspace() unconditional.

...

> +       void __iomem *ret = ioremap_np(offset, size);
> +
> +       if (!ret)
> +               ret = ioremap(offset, size);
> +
> +       return ret;

Usually negative conditions are worse for cognitive functions of human beings.
(On top of that some patterns are applied)

I would rewrite above as

void __iomem *ret;

ret = ioremap_np(offset, size);
if (ret)
  return ret;

return ioremap(offset, size);

-- 
With Best Regards,
Andy Shevchenko


From adrian.hunter at intel.com  Wed Apr  7 14:28:40 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Wed, 7 Apr 2021 16:28:40 +0300
Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
In-Reply-To: <20210407131529.GA585163@leoy-ThinkPad-X240s>
References: <20210403072346.30430-1-leo.yan@linaro.org>
 <AM6PR08MB335124DC0080EA95A817D71786769@AM6PR08MB3351.eurprd08.prod.outlook.com>
 <20210407131529.GA585163@leoy-ThinkPad-X240s>
Message-ID: <0016288d-a490-f8fb-f108-0969b946494e@intel.com>

On 7/04/21 4:15 pm, Leo Yan wrote:
> Hi Al,
> 
> On Tue, Apr 06, 2021 at 09:38:32AM +0000, Al Grant wrote:
> 
> [...]
> 
>>> This patch set is to enable timestamp for Arm SPE trace.  It reads out TSC
>>> parameters from mmap page and stores into auxtrace info structure;
>>
>> Why not synthesize a PERF_RECORD_TIME_CONV - isn't that specifically to
>> capture the TSC parameters from the mmap page? If a generic mechanism
>> exists it would be better to use it, otherwise we'll have to do this again for
>> future trace formats.
> 
> Good point!  Actually "perf record" tool has synthesized event
> PERF_RECORD_TIME_CONV.  This patch series is studying the
> implementation from Intel-PT, so the question is why the existed
> implementations (like Intel-PT, Intel-BTS) don't directly use
> PERF_RECORD_TIME_CONV for retriving TSC parameters.

PERF_RECORD_TIME_CONV was added later because the TSC information is
needed by jitdump.



From vincenzo.frascino at arm.com  Wed Apr  7 14:38:17 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Wed,  7 Apr 2021 14:38:17 +0100
Subject: [PATCH] arm64: mte: Remove unused mte_assign_mem_tag_range()
Message-ID: <20210407133817.23053-1-vincenzo.frascino@arm.com>

mte_assign_mem_tag_range() was added in commit 85f49cae4dfc
("arm64: mte: add in-kernel MTE helpers") in 5.11 but moved out of
mte.S by commit 2cb34276427a ("arm64: kasan: simplify and inline
MTE functions") in 5.12 and renamed to mte_set_mem_tag_range().
2cb34276427a did not delete the old function prototypes in mte.h.

Remove the unused prototype from mte.h.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Reported-by: Derrick McKee <derrick.mckee at gmail.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
 arch/arm64/include/asm/mte.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 9b557a457f24..387279540139 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -47,8 +47,6 @@ long get_mte_ctrl(struct task_struct *task);
 int mte_ptrace_copy_tags(struct task_struct *child, long request,
 			 unsigned long addr, unsigned long data);
 
-void mte_assign_mem_tag_range(void *addr, size_t size);
-
 #else /* CONFIG_ARM64_MTE */
 
 /* unused if !CONFIG_ARM64_MTE, silence the compiler */
@@ -84,10 +82,6 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
 	return -EIO;
 }
 
-static inline void mte_assign_mem_tag_range(void *addr, size_t size)
-{
-}
-
 #endif /* CONFIG_ARM64_MTE */
 
 #endif /* __ASSEMBLY__ */
-- 
2.30.2



From leo.yan at linaro.org  Wed Apr  7 14:40:58 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 7 Apr 2021 21:40:58 +0800
Subject: [PATCH v2 0/7] perf arm-spe: Enable timestamp
In-Reply-To: <0016288d-a490-f8fb-f108-0969b946494e@intel.com>
References: <20210403072346.30430-1-leo.yan@linaro.org>
 <AM6PR08MB335124DC0080EA95A817D71786769@AM6PR08MB3351.eurprd08.prod.outlook.com>
 <20210407131529.GA585163@leoy-ThinkPad-X240s>
 <0016288d-a490-f8fb-f108-0969b946494e@intel.com>
Message-ID: <20210407134058.GB585163@leoy-ThinkPad-X240s>

On Wed, Apr 07, 2021 at 04:28:40PM +0300, Adrian Hunter wrote:
> On 7/04/21 4:15 pm, Leo Yan wrote:
> > Hi Al,
> > 
> > On Tue, Apr 06, 2021 at 09:38:32AM +0000, Al Grant wrote:
> > 
> > [...]
> > 
> >>> This patch set is to enable timestamp for Arm SPE trace.  It reads out TSC
> >>> parameters from mmap page and stores into auxtrace info structure;
> >>
> >> Why not synthesize a PERF_RECORD_TIME_CONV - isn't that specifically to
> >> capture the TSC parameters from the mmap page? If a generic mechanism
> >> exists it would be better to use it, otherwise we'll have to do this again for
> >> future trace formats.
> > 
> > Good point!  Actually "perf record" tool has synthesized event
> > PERF_RECORD_TIME_CONV.  This patch series is studying the
> > implementation from Intel-PT, so the question is why the existed
> > implementations (like Intel-PT, Intel-BTS) don't directly use
> > PERF_RECORD_TIME_CONV for retriving TSC parameters.
> 
> PERF_RECORD_TIME_CONV was added later because the TSC information is
> needed by jitdump.

Thanks for the info, Adrian.

If so, it's good for Arm SPE to use PERF_RECORD_TIME_CONV for TSC
parameters.  Will spin patch series for this.

Leo


From steven.price at arm.com  Wed Apr  7 14:48:00 2021
From: steven.price at arm.com (Steven Price)
Date: Wed, 7 Apr 2021 14:48:00 +0100
Subject: [PATCH v2] arm64: Add __init section marker to some functions
In-Reply-To: <20210330135449.4dcffd7f@xhacker.debian>
References: <20210330135449.4dcffd7f@xhacker.debian>
Message-ID: <ee23634b-c70a-6125-c8dc-3692f100672a@arm.com>

On 30/03/2021 06:54, Jisheng Zhang wrote:
> They are not needed after booting, so mark them as __init to move them
> to the .init section.
> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

Reviewed-by: Steven Price <steven.price at arm.com>

> ---
> Since v1:
>   - add __init section mark to __vdso_init() and __aarch32_alloc_vdso_pages()
> 
>   arch/arm64/include/asm/ptdump.h | 2 +-
>   arch/arm64/kernel/vdso.c        | 4 ++--
>   arch/arm64/mm/ptdump.c          | 4 ++--
>   arch/arm64/mm/ptdump_debugfs.c  | 2 +-
>   4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 38187f74e089..b1dd7ecff7ef 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -23,7 +23,7 @@ struct ptdump_info {
>   
>   void ptdump_walk(struct seq_file *s, struct ptdump_info *info);
>   #ifdef CONFIG_PTDUMP_DEBUGFS
> -void ptdump_debugfs_register(struct ptdump_info *info, const char *name);
> +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) { }
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index cee5d04ea9ad..d1fa288518a7 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -86,7 +86,7 @@ static int vdso_mremap(const struct vm_special_mapping *sm,
>   	return 0;
>   }
>   
> -static int __vdso_init(enum vdso_abi abi)
> +static int __init __vdso_init(enum vdso_abi abi)
>   {
>   	int i;
>   	struct page **vdso_pagelist;
> @@ -326,7 +326,7 @@ static int aarch32_alloc_sigpage(void)
>   	return 0;
>   }
>   
> -static int __aarch32_alloc_vdso_pages(void)
> +static int __init __aarch32_alloc_vdso_pages(void)
>   {
>   
>   	if (!IS_ENABLED(CONFIG_COMPAT_VDSO))
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index 0e050d76b83a..a50e92ea1878 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -337,7 +337,7 @@ void ptdump_walk(struct seq_file *s, struct ptdump_info *info)
>   	ptdump_walk_pgd(&st.ptdump, info->mm, NULL);
>   }
>   
> -static void ptdump_initialize(void)
> +static void __init ptdump_initialize(void)
>   {
>   	unsigned i, j;
>   
> @@ -381,7 +381,7 @@ void ptdump_check_wx(void)
>   		pr_info("Checked W+X mappings: passed, no W+X pages found\n");
>   }
>   
> -static int ptdump_init(void)
> +static int __init ptdump_init(void)
>   {
>   	address_markers[PAGE_END_NR].start_address = PAGE_END;
>   #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
> diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
> index d29d722ec3ec..68bf1a125502 100644
> --- a/arch/arm64/mm/ptdump_debugfs.c
> +++ b/arch/arm64/mm/ptdump_debugfs.c
> @@ -16,7 +16,7 @@ static int ptdump_show(struct seq_file *m, void *v)
>   }
>   DEFINE_SHOW_ATTRIBUTE(ptdump);
>   
> -void ptdump_debugfs_register(struct ptdump_info *info, const char *name)
> +void __init ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>   {
>   	debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
>   }
> 



From steven.price at arm.com  Wed Apr  7 14:48:02 2021
From: steven.price at arm.com (Steven Price)
Date: Wed, 7 Apr 2021 14:48:02 +0100
Subject: [PATCH] arm: ptdump: add __init section marker to three functions
In-Reply-To: <20210330111922.2fb4eaa4@xhacker.debian>
References: <20210330111922.2fb4eaa4@xhacker.debian>
Message-ID: <5893767f-4103-3668-0810-3a0a66dc1c9e@arm.com>

On 30/03/2021 04:19, Jisheng Zhang wrote:
> They are not needed after booting, so mark them as __init to move them
> to the .init section.
> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

Reviewed-by: Steven Price <steven.price at arm.com>

> ---
>   arch/arm/mm/dump.c           | 4 ++--
>   arch/arm/mm/ptdump_debugfs.c | 2 +-
>   2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
> index 93ff0097f00b..fb688003d156 100644
> --- a/arch/arm/mm/dump.c
> +++ b/arch/arm/mm/dump.c
> @@ -420,7 +420,7 @@ void ptdump_walk_pgd(struct seq_file *m, struct ptdump_info *info)
>   	note_page(&st, 0, 0, 0, NULL);
>   }
>   
> -static void ptdump_initialize(void)
> +static void __init ptdump_initialize(void)
>   {
>   	unsigned i, j;
>   
> @@ -466,7 +466,7 @@ void ptdump_check_wx(void)
>   		pr_info("Checked W+X mappings: passed, no W+X pages found\n");
>   }
>   
> -static int ptdump_init(void)
> +static int __init ptdump_init(void)
>   {
>   	ptdump_initialize();
>   	ptdump_debugfs_register(&kernel_ptdump_info, "kernel_page_tables");
> diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
> index 598b636615a2..8df9afac8d81 100644
> --- a/arch/arm/mm/ptdump_debugfs.c
> +++ b/arch/arm/mm/ptdump_debugfs.c
> @@ -24,7 +24,7 @@ static const struct file_operations ptdump_fops = {
>   	.release	= single_release,
>   };
>   
> -void ptdump_debugfs_register(struct ptdump_info *info, const char *name)
> +void __init ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>   {
>   	debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
>   }
> 



From steven.price at arm.com  Wed Apr  7 14:48:04 2021
From: steven.price at arm.com (Steven Price)
Date: Wed, 7 Apr 2021 14:48:04 +0100
Subject: [PATCH] arm: ptdump: convert to DEFINE_SHOW_ATTRIBUTE
In-Reply-To: <20210330112015.738f4365@xhacker.debian>
References: <20210330112015.738f4365@xhacker.debian>
Message-ID: <1f066306-570e-dfc7-8b4f-f787a6d40554@arm.com>

On 30/03/2021 04:20, Jisheng Zhang wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

Reviewed-by: Steven Price <steven.price at arm.com>

> ---
>   arch/arm/mm/ptdump_debugfs.c | 13 +------------
>   1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
> index 8df9afac8d81..318de969ae0f 100644
> --- a/arch/arm/mm/ptdump_debugfs.c
> +++ b/arch/arm/mm/ptdump_debugfs.c
> @@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
>   	ptdump_walk_pgd(m, info);
>   	return 0;
>   }
> -
> -static int ptdump_open(struct inode *inode, struct file *file)
> -{
> -	return single_open(file, ptdump_show, inode->i_private);
> -}
> -
> -static const struct file_operations ptdump_fops = {
> -	.open		= ptdump_open,
> -	.read		= seq_read,
> -	.llseek		= seq_lseek,
> -	.release	= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(ptdump);
>   
>   void __init ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>   {
> 



From hverkuil at xs4all.nl  Wed Apr  7 15:05:26 2021
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 7 Apr 2021 16:05:26 +0200
Subject: [PATCH] staging: axis-fifo: media/meson: remove redundant dev_err
 call
In-Reply-To: <20210407101047.GA1491258@LEGION>
References: <20210407101047.GA1491258@LEGION>
Message-ID: <93218bc8-2cbb-bacc-f985-876a842261c4@xs4all.nl>

Hi Muhammad,

On 07/04/2021 12:10, Muhammad Usama Anjum wrote:
> devm_ioremap_resource() prints error message in itself. Remove the
> dev_err call to avoid redundant error message.

Please split this up into two separate patches! They are independent
changes and these two drivers are maintained by different people as well.

The patch itself looks OK, but it really has to be two separate patches.

Regards,

	Hans

> 
> Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
> ---
>  drivers/staging/axis-fifo/axis-fifo.c   | 1 -
>  drivers/staging/media/meson/vdec/vdec.c | 8 ++------
>  2 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c
> index 2bb1c2e9cb57..ed9281089738 100644
> --- a/drivers/staging/axis-fifo/axis-fifo.c
> +++ b/drivers/staging/axis-fifo/axis-fifo.c
> @@ -853,7 +853,6 @@ static int axis_fifo_probe(struct platform_device *pdev)
>  	fifo->base_addr = devm_ioremap_resource(fifo->dt_device, r_mem);
>  	if (IS_ERR(fifo->base_addr)) {
>  		rc = PTR_ERR(fifo->base_addr);
> -		dev_err(fifo->dt_device, "can't remap IO resource (%d)\n", rc);
>  		goto err_initial;
>  	}
>  
> diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
> index 5d4db7a5b4b5..e51d69c4729d 100644
> --- a/drivers/staging/media/meson/vdec/vdec.c
> +++ b/drivers/staging/media/meson/vdec/vdec.c
> @@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
>  
>  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
>  	core->dos_base = devm_ioremap_resource(dev, r);
> -	if (IS_ERR(core->dos_base)) {
> -		dev_err(dev, "Couldn't remap DOS memory\n");
> +	if (IS_ERR(core->dos_base))
>  		return PTR_ERR(core->dos_base);
> -	}
>  
>  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
>  	core->esparser_base = devm_ioremap_resource(dev, r);
> -	if (IS_ERR(core->esparser_base)) {
> -		dev_err(dev, "Couldn't remap ESPARSER memory\n");
> +	if (IS_ERR(core->esparser_base))
>  		return PTR_ERR(core->esparser_base);
> -	}
>  
>  	core->regmap_ao =
>  		syscon_regmap_lookup_by_phandle(dev->of_node,
> 



From vee.khee.wong at linux.intel.com  Wed Apr  7 15:15:37 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Wed,  7 Apr 2021 22:15:37 +0800
Subject: [PATCH net-next 1/1] net: stmmac: Add support for external trigger
 timestamping
Message-ID: <20210407141537.2129-1-vee.khee.wong@linux.intel.com>

From: Tan Tee Min <tee.min.tan at intel.com>

The Synopsis MAC controller supports auxiliary snapshot feature that
allows user to store a snapshot of the system time based on an external
event.

This patch add supports to the above mentioned feature. Users will be
able to triggered capturing the time snapshot from user-space using
application such as testptp or any other applications that uses the
PTP_EXTTS_REQUEST ioctl request.

Signed-off-by: Tan Tee Min <tee.min.tan at intel.com>
Co-developed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 11 +++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  5 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  3 ++
 .../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 40 +++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 +
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  | 39 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  1 +
 include/linux/stmmac.h                        |  2 +
 8 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 8ba87c0be976..aee3e0b5fb46 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -286,6 +286,13 @@ static int intel_crosststamp(ktime_t *device,
 
 	intel_priv = priv->plat->bsp_priv;
 
+	/* Both internal crosstimestamping and external triggered event
+	 * timestamping cannot be run concurrently.
+	 */
+	if (priv->plat->ext_snapshot_en)
+		return -EBUSY;
+
+	mutex_lock(&priv->aux_ts_lock);
 	/* Enable Internal snapshot trigger */
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value &= ~PTP_ACR_MASK;
@@ -311,6 +318,7 @@ static int intel_crosststamp(ktime_t *device,
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value |= PTP_ACR_ATSFC;
 	writel(acr_value, ptpaddr + PTP_ACR);
+	mutex_unlock(&priv->aux_ts_lock);
 
 	/* Trigger Internal snapshot signal
 	 * Create a rising edge by just toggle the GPO1 to low
@@ -345,6 +353,8 @@ static int intel_crosststamp(ktime_t *device,
 		*system = convert_art_to_tsc(art_time);
 	}
 
+	/* Release the mutex */
+	mutex_unlock(&priv->aux_ts_lock);
 	system->cycles *= intel_priv->crossts_adj;
 
 	return 0;
@@ -510,6 +520,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
 
 	plat->int_snapshot_num = AUX_SNAPSHOT1;
+	plat->ext_snapshot_num = AUX_SNAPSHOT0;
 
 	plat->has_crossts = true;
 	plat->crosststamp = intel_crosststamp;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2b5022ef1e52..2cc91759b91f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -504,6 +504,8 @@ struct stmmac_ops {
 #define stmmac_fpe_irq_status(__priv, __args...) \
 	stmmac_do_callback(__priv, mac, fpe_irq_status, __args)
 
+struct stmmac_priv;
+
 /* PTP and HW Timer helpers */
 struct stmmac_hwtimestamp {
 	void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
@@ -515,6 +517,7 @@ struct stmmac_hwtimestamp {
 			       int add_sub, int gmac4);
 	void (*get_systime) (void __iomem *ioaddr, u64 *systime);
 	void (*get_ptptime)(void __iomem *ioaddr, u64 *ptp_time);
+	void (*timestamp_interrupt)(struct stmmac_priv *priv);
 };
 
 #define stmmac_config_hw_tstamping(__priv, __args...) \
@@ -531,6 +534,8 @@ struct stmmac_hwtimestamp {
 	stmmac_do_void_callback(__priv, ptp, get_systime, __args)
 #define stmmac_get_ptptime(__priv, __args...) \
 	stmmac_do_void_callback(__priv, ptp, get_ptptime, __args)
+#define stmmac_timestamp_interrupt(__priv, __args...) \
+	stmmac_do_void_callback(__priv, ptp, timestamp_interrupt, __args)
 
 /* Helpers to manage the descriptors for chain and ring modes */
 struct stmmac_mode_ops {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..abadcd8cdc41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -239,6 +239,9 @@ struct stmmac_priv {
 	int use_riwt;
 	int irq_wake;
 	spinlock_t ptp_lock;
+	/* Mutex lock for Auxiliary Snapshots */
+	struct mutex aux_ts_lock;
+
 	void __iomem *mmcaddr;
 	void __iomem *ptpaddr;
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 113c51bcc0b5..ec7ec926f27c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -12,8 +12,11 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/delay.h>
+#include <linux/ptp_clock_kernel.h>
 #include "common.h"
 #include "stmmac_ptp.h"
+#include "dwmac4.h"
+#include "stmmac.h"
 
 static void config_hw_tstamping(void __iomem *ioaddr, u32 data)
 {
@@ -163,6 +166,42 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
 	*ptp_time = ns;
 }
 
+static void timestamp_interrupt(struct stmmac_priv *priv)
+{
+	struct ptp_clock_event event;
+	unsigned long flags;
+	u32 num_snapshot;
+	u32 ts_status;
+	u32 tsync_int;
+	u64 ptp_time;
+	int i;
+
+	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
+
+	if (!tsync_int)
+		return;
+
+	/* Read timestamp status to clear interrupt from either external
+	 * timestamp or start/end of PPS.
+	 */
+	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
+
+	if (priv->plat->ext_snapshot_en) {
+		num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
+			       GMAC_TIMESTAMP_ATSNS_SHIFT;
+
+		for (i = 0; i < num_snapshot; i++) {
+			spin_lock_irqsave(&priv->ptp_lock, flags);
+			get_ptptime(priv->ptpaddr, &ptp_time);
+			spin_unlock_irqrestore(&priv->ptp_lock, flags);
+			event.type = PTP_CLOCK_EXTTS;
+			event.index = 0;
+			event.timestamp = ptp_time;
+			ptp_clock_event(priv->ptp_clock, &event);
+		}
+	}
+}
+
 const struct stmmac_hwtimestamp stmmac_ptp = {
 	.config_hw_tstamping = config_hw_tstamping,
 	.init_systime = init_systime,
@@ -171,4 +210,5 @@ const struct stmmac_hwtimestamp stmmac_ptp = {
 	.adjust_systime = adjust_systime,
 	.get_systime = get_systime,
 	.get_ptptime = get_ptptime,
+	.timestamp_interrupt = timestamp_interrupt,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 77285646c5fc..9e57bc3d00a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4989,6 +4989,8 @@ static void stmmac_common_interrupt(struct stmmac_priv *priv)
 			else
 				netif_carrier_off(priv->dev);
 		}
+
+		stmmac_timestamp_interrupt(priv, priv);
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index b164ae22e35f..5300cbae50a0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -135,9 +135,13 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 {
 	struct stmmac_priv *priv =
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
+	void __iomem *ptpaddr = priv->ptpaddr;
+	void __iomem *ioaddr = priv->hw->pcsr;
 	struct stmmac_pps_cfg *cfg;
 	int ret = -EOPNOTSUPP;
 	unsigned long flags;
+	u32 intr_value;
+	u32 acr_value;
 
 	switch (rq->type) {
 	case PTP_CLK_REQ_PEROUT:
@@ -159,6 +163,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 					     priv->systime_flags);
 		spin_unlock_irqrestore(&priv->ptp_lock, flags);
 		break;
+	case PTP_CLK_REQ_EXTTS:
+		priv->plat->ext_snapshot_en = on;
+		mutex_lock(&priv->aux_ts_lock);
+		acr_value = readl(ptpaddr + PTP_ACR);
+		acr_value &= ~PTP_ACR_MASK;
+		if (on) {
+			/* Enable External snapshot trigger */
+			acr_value |= priv->plat->ext_snapshot_num;
+			acr_value |= PTP_ACR_ATSFC;
+			pr_info("Auxiliary Snapshot %d enabled.\n",
+				priv->plat->ext_snapshot_num >>
+				PTP_ACR_ATSEN_SHIFT);
+			/* Enable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value |= GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+
+		} else {
+			pr_info("Auxiliary Snapshot %d disabled.\n",
+				priv->plat->ext_snapshot_num >>
+				PTP_ACR_ATSEN_SHIFT);
+			/* Disable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value &= ~GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+		}
+		writel(acr_value, ptpaddr + PTP_ACR);
+		mutex_unlock(&priv->aux_ts_lock);
+		ret = 0;
+		break;
+
 	default:
 		break;
 	}
@@ -202,7 +237,7 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
 	.name = "stmmac ptp",
 	.max_adj = 62500000,
 	.n_alarm = 0,
-	.n_ext_ts = 0,
+	.n_ext_ts = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_per_out = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_pins = 0,
 	.pps = 0,
@@ -237,8 +272,10 @@ void stmmac_ptp_register(struct stmmac_priv *priv)
 		stmmac_ptp_clock_ops.max_adj = priv->plat->ptp_max_adj;
 
 	stmmac_ptp_clock_ops.n_per_out = priv->dma_cap.pps_out_num;
+	stmmac_ptp_clock_ops.n_ext_ts = priv->dma_cap.aux_snapshot_n;
 
 	spin_lock_init(&priv->ptp_lock);
+	mutex_init(&priv->aux_ts_lock);
 	priv->ptp_clock_ops = stmmac_ptp_clock_ops;
 
 	priv->ptp_clock = ptp_clock_register(&priv->ptp_clock_ops,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index f88727ce4d30..53172a439810 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -73,6 +73,7 @@
 #define	PTP_ACR_ATSEN1		BIT(5)	/* Auxiliary Snapshot 1 Enable */
 #define	PTP_ACR_ATSEN2		BIT(6)	/* Auxiliary Snapshot 2 Enable */
 #define	PTP_ACR_ATSEN3		BIT(7)	/* Auxiliary Snapshot 3 Enable */
+#define	PTP_ACR_ATSEN_SHIFT	5	/* Auxiliary Snapshot shift */
 #define	PTP_ACR_MASK		GENMASK(7, 4)	/* Aux Snapshot Mask */
 #define	PMC_ART_VALUE0		0x01	/* PMC_ART[15:0] timer value */
 #define	PMC_ART_VALUE1		0x02	/* PMC_ART[31:16] timer value */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..97edb31d6310 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -238,6 +238,8 @@ struct plat_stmmacenet_data {
 	struct pci_dev *pdev;
 	bool has_crossts;
 	int int_snapshot_num;
+	int ext_snapshot_num;
+	bool ext_snapshot_en;
 	bool multi_msi_en;
 	int msi_mac_vec;
 	int msi_wol_vec;
-- 
2.25.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:14 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:14 +0800
Subject: [PATCH -next 0/5] Remove redundant dev_err call
Message-ID: <20210407141819.32588-1-yuehaibing@huawei.com>

This patchset remove some redundant dev_err calls

YueHaibing (5):
  crypto: atmel-tdes - Remove redundant dev_err call in
    atmel_tdes_probe()
  crypto: img-hash - Remove redundant dev_err call in img_hash_probe()
  crypto: ux500 - Remove redundant dev_err calls
  crypto: keembay - Remove redundant dev_err calls
  crypto: ccree - Remove redundant dev_err call in init_cc_resources()

 drivers/crypto/atmel-tdes.c                   | 1 -
 drivers/crypto/ccree/cc_driver.c              | 4 +---
 drivers/crypto/img-hash.c                     | 3 ---
 drivers/crypto/keembay/keembay-ocs-aes-core.c | 4 +---
 drivers/crypto/keembay/keembay-ocs-hcu-core.c | 4 +---
 drivers/crypto/ux500/cryp/cryp_core.c         | 1 -
 drivers/crypto/ux500/hash/hash_core.c         | 1 -
 7 files changed, 3 insertions(+), 15 deletions(-)

-- 
2.17.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:19 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:19 +0800
Subject: [PATCH -next 5/5] crypto: ccree - Remove redundant dev_err call in
 init_cc_resources()
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210407141819.32588-6-yuehaibing@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/crypto/ccree/cc_driver.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/crypto/ccree/cc_driver.c b/drivers/crypto/ccree/cc_driver.c
index d0e59e942568..e599ac6dc162 100644
--- a/drivers/crypto/ccree/cc_driver.c
+++ b/drivers/crypto/ccree/cc_driver.c
@@ -352,10 +352,8 @@ static int init_cc_resources(struct platform_device *plat_dev)
 	req_mem_cc_regs = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
 	/* Map registers space */
 	new_drvdata->cc_base = devm_ioremap_resource(dev, req_mem_cc_regs);
-	if (IS_ERR(new_drvdata->cc_base)) {
-		dev_err(dev, "Failed to ioremap registers");
+	if (IS_ERR(new_drvdata->cc_base))
 		return PTR_ERR(new_drvdata->cc_base);
-	}
 
 	dev_dbg(dev, "Got MEM resource (%s): %pR\n", req_mem_cc_regs->name,
 		req_mem_cc_regs);
-- 
2.17.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:15 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:15 +0800
Subject: [PATCH -next 1/5] crypto: atmel-tdes - Remove redundant dev_err call
 in atmel_tdes_probe()
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210407141819.32588-2-yuehaibing@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/crypto/atmel-tdes.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index 4d63cb13a54f..6f01c51e3c37 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers/crypto/atmel-tdes.c
@@ -1217,7 +1217,6 @@ static int atmel_tdes_probe(struct platform_device *pdev)
 
 	tdes_dd->io_base = devm_ioremap_resource(&pdev->dev, tdes_res);
 	if (IS_ERR(tdes_dd->io_base)) {
-		dev_err(dev, "can't ioremap\n");
 		err = PTR_ERR(tdes_dd->io_base);
 		goto err_tasklet_kill;
 	}
-- 
2.17.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:16 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:16 +0800
Subject: [PATCH -next 2/5] crypto: img-hash - Remove redundant dev_err call in
 img_hash_probe()
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210407141819.32588-3-yuehaibing@huawei.com>

devm_platform_ioremap_resource() and devm_ioremap_resource()
will print err msg while failing, so the redundant dev_err call
can be removed.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/crypto/img-hash.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c
index e813115d5432..aa4c7b2af3e2 100644
--- a/drivers/crypto/img-hash.c
+++ b/drivers/crypto/img-hash.c
@@ -963,8 +963,6 @@ static int img_hash_probe(struct platform_device *pdev)
 	hdev->io_base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(hdev->io_base)) {
 		err = PTR_ERR(hdev->io_base);
-		dev_err(dev, "can't ioremap, returned %d\n", err);
-
 		goto res_err;
 	}
 
@@ -972,7 +970,6 @@ static int img_hash_probe(struct platform_device *pdev)
 	hash_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 	hdev->cpu_addr = devm_ioremap_resource(dev, hash_res);
 	if (IS_ERR(hdev->cpu_addr)) {
-		dev_err(dev, "can't ioremap write port\n");
 		err = PTR_ERR(hdev->cpu_addr);
 		goto res_err;
 	}
-- 
2.17.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:18 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:18 +0800
Subject: [PATCH -next 4/5] crypto: keembay - Remove redundant dev_err calls
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210407141819.32588-5-yuehaibing@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/crypto/keembay/keembay-ocs-aes-core.c | 4 +---
 drivers/crypto/keembay/keembay-ocs-hcu-core.c | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/keembay/keembay-ocs-aes-core.c b/drivers/crypto/keembay/keembay-ocs-aes-core.c
index 2ef312866338..e2a39fdaf623 100644
--- a/drivers/crypto/keembay/keembay-ocs-aes-core.c
+++ b/drivers/crypto/keembay/keembay-ocs-aes-core.c
@@ -1623,10 +1623,8 @@ static int kmb_ocs_aes_probe(struct platform_device *pdev)
 	}
 
 	aes_dev->base_reg = devm_ioremap_resource(&pdev->dev, aes_mem);
-	if (IS_ERR(aes_dev->base_reg)) {
-		dev_err(dev, "Failed to get base address\n");
+	if (IS_ERR(aes_dev->base_reg))
 		return PTR_ERR(aes_dev->base_reg);
-	}
 
 	/* Get and request IRQ */
 	aes_dev->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/crypto/keembay/keembay-ocs-hcu-core.c b/drivers/crypto/keembay/keembay-ocs-hcu-core.c
index 322c51a6936f..0379dbf32a4c 100644
--- a/drivers/crypto/keembay/keembay-ocs-hcu-core.c
+++ b/drivers/crypto/keembay/keembay-ocs-hcu-core.c
@@ -1192,10 +1192,8 @@ static int kmb_ocs_hcu_probe(struct platform_device *pdev)
 	}
 
 	hcu_dev->io_base = devm_ioremap_resource(dev, hcu_mem);
-	if (IS_ERR(hcu_dev->io_base)) {
-		dev_err(dev, "Could not io-remap mem resource.\n");
+	if (IS_ERR(hcu_dev->io_base))
 		return PTR_ERR(hcu_dev->io_base);
-	}
 
 	init_completion(&hcu_dev->irq_done);
 
-- 
2.17.1



From yuehaibing at huawei.com  Wed Apr  7 15:18:17 2021
From: yuehaibing at huawei.com (YueHaibing)
Date: Wed, 7 Apr 2021 22:18:17 +0800
Subject: [PATCH -next 3/5] crypto: ux500 - Remove redundant dev_err calls
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210407141819.32588-4-yuehaibing@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: YueHaibing <yuehaibing at huawei.com>
---
 drivers/crypto/ux500/cryp/cryp_core.c | 1 -
 drivers/crypto/ux500/hash/hash_core.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 10fcd682988b..30cdd5253929 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1291,7 +1291,6 @@ static int ux500_cryp_probe(struct platform_device *pdev)
 	device_data->phybase = res->start;
 	device_data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(device_data->base)) {
-		dev_err(dev, "[%s]: ioremap failed!", __func__);
 		ret = PTR_ERR(device_data->base);
 		goto out;
 	}
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 7db15258475f..ecb7412e84e3 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1676,7 +1676,6 @@ static int ux500_hash_probe(struct platform_device *pdev)
 	device_data->phybase = res->start;
 	device_data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(device_data->base)) {
-		dev_err(dev, "%s: ioremap() failed!\n", __func__);
 		ret = PTR_ERR(device_data->base);
 		goto out;
 	}
-- 
2.17.1



From andrew at lunn.ch  Wed Apr  7 15:21:09 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 7 Apr 2021 16:21:09 +0200
Subject: [PATCH net-next 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210407141537.2129-1-vee.khee.wong@linux.intel.com>
References: <20210407141537.2129-1-vee.khee.wong@linux.intel.com>
Message-ID: <YG2/1fbNNIsbafZp@lunn.ch>

On Wed, Apr 07, 2021 at 10:15:37PM +0800, Wong Vee Khee wrote:
> From: Tan Tee Min <tee.min.tan at intel.com>
> 
> The Synopsis MAC controller supports auxiliary snapshot feature that
> allows user to store a snapshot of the system time based on an external
> event.
> 
> This patch add supports to the above mentioned feature. Users will be
> able to triggered capturing the time snapshot from user-space using
> application such as testptp or any other applications that uses the
> PTP_EXTTS_REQUEST ioctl request.

You forgot to Cc: the PTP maintainer.

> @@ -159,6 +163,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
>  					     priv->systime_flags);
>  		spin_unlock_irqrestore(&priv->ptp_lock, flags);
>  		break;
> +	case PTP_CLK_REQ_EXTTS:
> +		priv->plat->ext_snapshot_en = on;
> +		mutex_lock(&priv->aux_ts_lock);
> +		acr_value = readl(ptpaddr + PTP_ACR);
> +		acr_value &= ~PTP_ACR_MASK;
> +		if (on) {
> +			/* Enable External snapshot trigger */
> +			acr_value |= priv->plat->ext_snapshot_num;
> +			acr_value |= PTP_ACR_ATSFC;
> +			pr_info("Auxiliary Snapshot %d enabled.\n",
> +				priv->plat->ext_snapshot_num >>
> +				PTP_ACR_ATSEN_SHIFT);

dev_dbg()?

> +			/* Enable Timestamp Interrupt */
> +			intr_value = readl(ioaddr + GMAC_INT_EN);
> +			intr_value |= GMAC_INT_TSIE;
> +			writel(intr_value, ioaddr + GMAC_INT_EN);
> +
> +		} else {
> +			pr_info("Auxiliary Snapshot %d disabled.\n",
> +				priv->plat->ext_snapshot_num >>
> +				PTP_ACR_ATSEN_SHIFT);

dev_dbg()?

Do you really want to spam the kernel log with this?



From robh at kernel.org  Wed Apr  7 15:27:34 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 7 Apr 2021 09:27:34 -0500
Subject: [PATCH 2/3] PCI: dwc: Visoconti: PCIe RC controller driver
In-Reply-To: <20210407031839.386088-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210407031839.386088-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210407142734.GA3606952@robh.at.kernel.org>

On Wed, Apr 07, 2021 at 12:18:38PM +0900, Nobuhiro Iwamatsu wrote:
> Add support to PCIe RC controller on Toshiba Visconti ARM SoCs.
> PCIe controller is based of Synopsys DesignWare PCIe core.
> 
> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> ---
>  drivers/pci/controller/dwc/Kconfig         |  10 +
>  drivers/pci/controller/dwc/Makefile        |   1 +
>  drivers/pci/controller/dwc/pcie-visconti.c | 358 +++++++++++++++++++++
>  3 files changed, 369 insertions(+)
>  create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index b9aaa84452c4..ae125d7cf375 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -286,6 +286,16 @@ config PCIE_TEGRA194_EP
>  	  in order to enable device-specific features PCIE_TEGRA194_EP must be
>  	  selected. This uses the DesignWare core.
>  
> +config PCIE_VISCONTI
> +	bool "Toshiba VISCONTI PCIe controllers"
> +	depends on ARCH_VISCONTI || COMPILE_TEST
> +	depends on OF && HAS_IOMEM

Is this line really needed? Seems we have a mixture on other drivers.

> +	depends on PCI_MSI_IRQ_DOMAIN
> +	select PCIE_DW_HOST
> +	help
> +	  Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
> +	  This driver supports TMPV77xx.
> +
>  config PCIE_UNIPHIER
>  	bool "Socionext UniPhier PCIe host controllers"
>  	depends on ARCH_UNIPHIER || COMPILE_TEST
> diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> index ba7c42f6df6f..46ac5d49dc75 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
>  obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
>  obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
>  obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
> +obj-$(CONFIG_PCIE_VISCONTI) += pcie-visconti.o
>  
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/controller/dwc/pcie-visconti.c b/drivers/pci/controller/dwc/pcie-visconti.c
> new file mode 100644
> index 000000000000..e24f83df41b8
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pcie-visconti.c
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DWC PCIe RC driver for Toshiba Visconti ARM SoC
> + *
> + * Copyright (C) 2019, 2020 Toshiba Electronic Device & Storage Corporation
> + * Copyright (C) 2020, TOSHIBA CORPORATION
> + *
> + * Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/interrupt.h>
> +#include <linux/init.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +#include <linux/types.h>
> +
> +#include "pcie-designware.h"
> +#include "../../pci.h"
> +
> +struct visconti_pcie {
> +	struct dw_pcie *pci;

Embed this rather than a pointer. 1 less alloc.

> +	void __iomem *ulreg_base;
> +	void __iomem *smu_base;
> +	void __iomem *mpu_base;
> +	struct clk *refclk;
> +	struct clk *sysclk;
> +	struct clk *auxclk;
> +};
> +
> +#define PCIE_UL_REG_S_PCIE_MODE		0x00F4
> +#define  PCIE_UL_REG_S_PCIE_MODE_EP	0x00
> +#define  PCIE_UL_REG_S_PCIE_MODE_RC	0x04
> +
> +#define PCIE_UL_REG_S_PERSTN_CTRL	0x00F8
> +#define  PCIE_UL_IOM_PCIE_PERSTN_I_EN	BIT(3)
> +#define  PCIE_UL_DIRECT_PERSTN_EN	BIT(2)
> +#define  PCIE_UL_PERSTN_OUT		BIT(1)
> +#define  PCIE_UL_DIRECT_PERSTN		BIT(0)
> +
> +#define PCIE_UL_REG_S_PHY_INIT_02	0x0104
> +#define  PCIE_UL_PHY0_SRAM_EXT_LD_DONE	BIT(0)
> +
> +#define PCIE_UL_REG_S_PHY_INIT_03	0x0108
> +#define  PCIE_UL_PHY0_SRAM_INIT_DONE	BIT(0)
> +
> +#define PCIE_UL_REG_S_INT_EVENT_MASK1	0x0138
> +#define  PCIE_UL_CFG_PME_INT		BIT(0)
> +#define  PCIE_UL_CFG_LINK_EQ_REQ_INT	BIT(1)
> +#define  PCIE_UL_EDMA_INT0		BIT(2)
> +#define  PCIE_UL_EDMA_INT1		BIT(3)
> +#define  PCIE_UL_EDMA_INT2		BIT(4)
> +#define  PCIE_UL_EDMA_INT3		BIT(5)
> +#define  PCIE_UL_S_INT_EVENT_MASK1_ALL  (PCIE_UL_CFG_PME_INT | PCIE_UL_CFG_LINK_EQ_REQ_INT | \
> +					 PCIE_UL_EDMA_INT0 | PCIE_UL_EDMA_INT1 | \
> +					 PCIE_UL_EDMA_INT2 | PCIE_UL_EDMA_INT3)
> +
> +#define PCIE_UL_REG_S_SB_MON		0x0198
> +#define PCIE_UL_REG_S_SIG_MON		0x019C
> +#define  PCIE_UL_CORE_RST_N_MON		BIT(0)
> +
> +#define PCIE_UL_REG_V_SII_DBG_00	0x0844
> +#define PCIE_UL_REG_V_SII_GEN_CTRL_01	0x0860
> +#define  PCIE_UL_APP_LTSSM_ENABLE	BIT(0)
> +
> +#define PCIE_UL_REG_V_PHY_ST_00		0x0864
> +#define  PCIE_UL_SMLH_LINK_UP		BIT(0)
> +
> +#define PCIE_UL_REG_V_PHY_ST_02		0x0868
> +#define  PCIE_UL_S_DETECT_ACT		0x01
> +#define  PCIE_UL_S_L0			0x11
> +
> +#define PISMU_CKON_PCIE			0x0038
> +#define  PISMU_CKON_PCIE_AUX_CLK	BIT(1)
> +#define  PISMU_CKON_PCIE_MSTR_ACLK	BIT(0)
> +
> +#define PISMU_RSOFF_PCIE		0x0538
> +#define  PISMU_RSOFF_PCIE_ULREG_RST_N	BIT(1)
> +#define  PISMU_RSOFF_PCIE_PWR_UP_RST_N	BIT(0)
> +
> +#define PCIE_MPU_REG_MP_EN		0x0
> +#define  MPU_MP_EN_DISABLE		BIT(0)
> +
> +#define PCIE_BUS_OFFSET			0x40000000
> +
> +/* Access registers in PCIe ulreg */
> +static inline void visconti_ulreg_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel(val, pcie->ulreg_base + reg);

Do these need ordering WRT DMA? If not, use _relaxed variant.

> +}
> +
> +/* Access registers in PCIe smu */
> +static inline void visconti_smu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel(val, pcie->smu_base + reg);
> +}
> +
> +/* Access registers in PCIe mpu */
> +static inline void visconti_mpu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel(val, pcie->mpu_base + reg);
> +}
> +
> +static inline u32 visconti_mpu_readl(struct visconti_pcie *pcie, u32 reg)
> +{
> +	return readl(pcie->mpu_base + reg);
> +}
> +
> +static int visconti_pcie_check_link_status(struct visconti_pcie *pcie)
> +{
> +	int err;
> +	u32 val;
> +
> +	/* wait for linkup of phy link layer */
> +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_00, val,
> +				 (val & PCIE_UL_SMLH_LINK_UP), 1000, 10000);
> +	if (err)
> +		return err;
> +
> +	/* wait for linkup of data link layer */
> +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> +				 (val & PCIE_UL_S_DETECT_ACT), 1000, 10000);
> +	if (err)
> +		return err;
> +
> +	/* wait for LTSSM Status */
> +	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> +				  (val & PCIE_UL_S_L0), 1000, 10000);
> +}
> +
> +static int visconti_pcie_establish_link(struct pcie_port *pp)
> +{
> +	int ret;
> +	u32 val;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_APP_LTSSM_ENABLE, PCIE_UL_REG_V_SII_GEN_CTRL_01);
> +
> +	ret = visconti_pcie_check_link_status(pcie);
> +	if (ret < 0) {
> +		dev_info(pci->dev, "Link failure\n");
> +		return ret;
> +	}
> +
> +	val = visconti_mpu_readl(pcie, PCIE_MPU_REG_MP_EN);
> +	visconti_mpu_writel(pcie, val & ~MPU_MP_EN_DISABLE, PCIE_MPU_REG_MP_EN);
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_S_INT_EVENT_MASK1_ALL, PCIE_UL_REG_S_INT_EVENT_MASK1);

Seems like all this should be a phy driver.

> +
> +	return 0;
> +}
> +
> +static int visconti_pcie_host_init(struct pcie_port *pp)
> +{
> +	int ret;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> +	dw_pcie_setup_rc(pp);

> +	ret = visconti_pcie_establish_link(pp);
> +	if (ret < 0)
> +		return ret;
> +
> +	dw_pcie_wait_for_link(pci);

The DWC core code does link handling now.

> +
> +	return 0;
> +}
> +
> +static const struct dw_pcie_host_ops visconti_pcie_host_ops = {
> +	.host_init = visconti_pcie_host_init,
> +};
> +
> +static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 pci_addr)
> +{
> +	return pci_addr - PCIE_BUS_OFFSET;
> +}
> +
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +	.cpu_addr_fixup = visconti_pcie_cpu_addr_fixup,
> +};
> +
> +static int visconti_get_resources(struct platform_device *pdev,
> +				  struct visconti_pcie *pcie)
> +{
> +	struct device *dev = &pdev->dev;
> +
> +	pcie->pci->dbi_base = devm_platform_ioremap_resource_byname(pdev, "dbi");
> +	if (IS_ERR(pcie->pci->dbi_base))
> +		return PTR_ERR(pcie->pci->dbi_base);

The DWC core handles this now.

> +
> +	pcie->ulreg_base = devm_platform_ioremap_resource_byname(pdev, "ulreg");
> +	if (IS_ERR(pcie->ulreg_base))
> +		return PTR_ERR(pcie->ulreg_base);
> +
> +	pcie->smu_base = devm_platform_ioremap_resource_byname(pdev, "smu");
> +	if (IS_ERR(pcie->smu_base))
> +		return PTR_ERR(pcie->smu_base);
> +
> +	pcie->mpu_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
> +	if (IS_ERR(pcie->mpu_base))
> +		return PTR_ERR(pcie->mpu_base);
> +
> +	pcie->refclk = devm_clk_get(dev, "pcie_refclk");
> +	if (IS_ERR(pcie->refclk)) {
> +		dev_err(dev, "Failed to get refclk clock: %ld\n", PTR_ERR(pcie->refclk));
> +		return PTR_ERR(pcie->refclk);
> +	}
> +
> +	pcie->sysclk = devm_clk_get(dev, "sysclk");
> +	if (IS_ERR(pcie->sysclk)) {
> +		dev_err(dev, "Failed to get sysclk clock: %ld\n", PTR_ERR(pcie->sysclk));
> +		return PTR_ERR(pcie->sysclk);
> +	}
> +
> +	pcie->auxclk = devm_clk_get(dev, "auxclk");
> +	if (IS_ERR(pcie->auxclk)) {
> +		dev_err(dev, "Failed to get auxclk clock: %ld\n", PTR_ERR(pcie->auxclk));
> +		return PTR_ERR(pcie->auxclk);
> +	}
> +
> +	return 0;
> +}
> +
> +static int visconti_device_turnon(struct visconti_pcie *pcie)
> +{
> +	int err;
> +	u32 val;
> +
> +	visconti_smu_writel(pcie, PISMU_CKON_PCIE_AUX_CLK | PISMU_CKON_PCIE_MSTR_ACLK,
> +			    PISMU_CKON_PCIE);

Clock control? Should be a clock provider then.

> +	ndelay(250);
> +
> +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_ULREG_RST_N, PISMU_RSOFF_PCIE);
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_REG_S_PCIE_MODE_RC, PCIE_UL_REG_S_PCIE_MODE);
> +
> +	val = PCIE_UL_IOM_PCIE_PERSTN_I_EN | PCIE_UL_DIRECT_PERSTN_EN | PCIE_UL_DIRECT_PERSTN;
> +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> +	udelay(100);
> +
> +	val |= PCIE_UL_PERSTN_OUT;
> +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> +	udelay(100);
> +
> +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_PWR_UP_RST_N, PISMU_RSOFF_PCIE);
> +
> +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_PHY_INIT_03, val,
> +				 (val & PCIE_UL_PHY0_SRAM_INIT_DONE), 100, 1000);
> +	if (err)
> +		return err;
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_PHY0_SRAM_EXT_LD_DONE, PCIE_UL_REG_S_PHY_INIT_02);
> +
> +	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_SIG_MON, val,
> +				 (val & PCIE_UL_CORE_RST_N_MON), 100, 1000);
> +}
> +
> +static int visconti_add_pcie_port(struct visconti_pcie *pcie, struct platform_device *pdev)
> +{
> +	struct dw_pcie *pci = pcie->pci;
> +	struct pcie_port *pp = &pci->pp;
> +	struct device *dev = &pdev->dev;
> +	int ret;
> +
> +	pp->irq = platform_get_irq_byname(pdev, "intr");
> +	if (pp->irq < 0) {
> +		dev_err(dev, "interrupt intr is missing");
> +		return pp->irq;
> +	}
> +
> +	if (IS_ENABLED(CONFIG_PCI_MSI)) {
> +		pp->msi_irq = platform_get_irq_byname(pdev, "msi");
> +		if (pp->msi_irq < 0) {
> +			dev_err(dev, "interrupt msi is missing");
> +			return pp->msi_irq;
> +		}
> +	}

DWC core handles this now.

> +
> +	pp->ops = &visconti_pcie_host_ops;
> +
> +	pci->link_gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> +	if (pci->link_gen < 0 || pci->link_gen > 3) {
> +		pci->link_gen = 3;
> +		dev_dbg(dev, "Applied default link speed\n");
> +	}
> +
> +	dev_dbg(dev, "link speed Gen %d", pci->link_gen);
> +
> +	ret = visconti_device_turnon(pcie);
> +	if (ret)
> +		goto error;
> +
> +	ret = dw_pcie_host_init(pp);
> +	if (ret)
> +		dev_err(dev, "Failed to initialize host\n");
> +
> +error:
> +	return ret;
> +}
> +
> +static int visconti_pcie_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct visconti_pcie *pcie;
> +	struct pcie_port *pp;
> +	struct dw_pcie *pci;
> +	int ret;
> +
> +	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(36));
> +	if (ret)
> +		return ret;
> +
> +	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> +	if (!pcie)
> +		return -ENOMEM;
> +
> +	pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> +	if (!pci)
> +		return -ENOMEM;
> +
> +	pp = &pci->pp;
> +	pp->num_vectors = MAX_MSI_IRQS;
> +
> +	pci->dev = dev;
> +	pci->ops = &dw_pcie_ops;
> +	pcie->pci = pci;
> +
> +	ret = visconti_get_resources(pdev, pcie);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, pcie);
> +
> +	return visconti_add_pcie_port(pcie, pdev);
> +}
> +
> +static const struct of_device_id visconti_pcie_match[] = {
> +	{ .compatible = "toshiba,visconti-pcie" },
> +	{},
> +};
> +
> +static struct platform_driver visconti_pcie_driver = {
> +	.probe = visconti_pcie_probe,
> +	.driver = {
> +		.name = "visconti-pcie",
> +		.of_match_table = visconti_pcie_match,
> +		.suppress_bind_attrs = true,
> +	},
> +};
> +
> +builtin_platform_driver(visconti_pcie_driver);
> -- 
> 2.30.0.rc2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From robh at kernel.org  Wed Apr  7 15:28:12 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 07 Apr 2021 09:28:12 -0500
Subject: [PATCH 5/8] dt-bindings: soc: mediatek: apusys: Add new document
 for APU power domain
In-Reply-To: <1617766086-5502-6-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-6-git-send-email-flora.fu@mediatek.com>
Message-ID: <1617805692.253379.3696993.nullmailer@robh.at.kernel.org>

On Wed, 07 Apr 2021 11:28:03 +0800, Flora Fu wrote:
> Document the bindings for APU power domain on MediaTek SoC.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---
>  .../soc/mediatek/mediatek,apu-pm.yaml         | 146 ++++++++++++++++++
>  1 file changed, 146 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.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/soc/mediatek/mediatek,apu-pm.example.dts:19:18: fatal error: dt-bindings/clock/mt8192-clk.h: No such file or directory
   19 |         #include <dt-bindings/clock/mt8192-clk.h>
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [scripts/Makefile.lib:377: Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1414: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1463115

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From minyard at acm.org  Wed Apr  7 15:28:28 2021
From: minyard at acm.org (Corey Minyard)
Date: Wed, 7 Apr 2021 09:28:28 -0500
Subject: [PATCH v2 0/3] Add Aspeed SSIF BMC driver
In-Reply-To: <0e7fceff-4a01-5cb0-72eb-8b47d598f1c3@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210402142124.GV507977@minyard.net>
 <0e7fceff-4a01-5cb0-72eb-8b47d598f1c3@os.amperecomputing.com>
Message-ID: <20210407142828.GE7166@minyard.net>

On Wed, Apr 07, 2021 at 08:09:50PM +0700, Quan Nguyen wrote:
> Hi Corey,
> 
> Thank you for reviewing
> I'll put my respond inline below.
> 
> -Quan
> 
> On 02/04/2021 21:21, Corey Minyard wrote:
> > On Tue, Mar 30, 2021 at 09:10:26PM +0700, Quan Nguyen wrote:
> > > This series add support for the Aspeed specific SSIF BMC driver which
> > > is to perform in-band IPMI communication with the host in management
> > > (BMC) side.
> > 
> > I don't have any specific feedback for this, but I'm wondering if it's
> > really necessary.
> > 
> > Why can't the BMC just open the I2C device and use it?  Is there any
> > functionality that this provides that cannot be accomplished from
> > userland access to the I2C device?  I don't see any.
> > 
> > If it tied into some existing framework to give abstract access to a BMC
> > slave side interface, I'd be ok with this.  But I don't see that.
> > 
> 
> The SSIF at the BMC side acts as an I2C slave and we think that the kernel
> driver is unavoidable to handle the I2c slave events
> (https://www.kernel.org/doc/html/latest/i2c/slave-interface.html)
> 
> And to make it works with existing OpenBMC IPMI stack, a userspace part,
> ssifbridge, is needed (https://github.com/openbmc/ssifbridge). This
> ssifbridge is to connect this driver with the OpenBMC IPMI stack so the IPMI
> stack can communicate via SSIF channel in similar way that was implemented
> with BT and KCS (ie: btbridge/kcsbridge and its corespondent kernel drivers
> (https://github.com/openbmc/btbridge and
> https://github.com/openbmc/kcsbridge))

Dang, I don't know why there's not a generic userland interface for
the slave.  And I've made this mistake before :(.

Anyway, you are right, you need a driver.  I'll review.

-corey

> 
> > Unless there is a big need to have this in the kernel, I'm against
> > including this and would suggest you do all this work in userland.
> > Perhaps write a library.  Sorry, but I'm trying to do my part to reduce
> > unnecessary things in the kernel.
> > 
> > Thanks,
> > 
> > -corey
> > 


From catalin.marinas at arm.com  Wed Apr  7 15:30:20 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 7 Apr 2021 15:30:20 +0100
Subject: [PATCH 09/20] kbuild: arm64: use common install script
In-Reply-To: <20210407053419.449796-10-gregkh@linuxfoundation.org>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
 <20210407053419.449796-10-gregkh@linuxfoundation.org>
Message-ID: <20210407143020.GB21451@arm.com>

On Wed, Apr 07, 2021 at 07:34:08AM +0200, Greg Kroah-Hartman wrote:
> The common scripts/install.sh script will now work for arm65, no changes
> needed so convert the arm64 boot Makefile to call it instead of the
> arm64-only version of the file and remove the now unused file.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Assuming that it does the same thing (it seems to from a quick look):

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From arnd at arndb.de  Wed Apr  7 15:31:44 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 Apr 2021 16:31:44 +0200
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v5.13
In-Reply-To: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>
References: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>
Message-ID: <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>

On Sat, Apr 3, 2021 at 5:06 PM Wei Xu <xuwei5 at hisilicon.com> wrote:
>
> Hi ARM-SoC team,
>
> Please consider to pull the following changes.
> Thanks!

I'd prefer to not break compatibility of old kernels with new dts files
here, as this would prevent installing an old distro with an ebbr
compliant boot loader, for purely cosmetic reasons.  These are used
in the popular 'hikey' boards, which are used in many scenarios,
which makes it fairly likely that someone might want to install
something other than the very latest kernel.

Could you instead keep both the old and the new property in there
for at least a few years?

        Arnd


From s-anna at ti.com  Wed Apr  7 15:32:21 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 09:32:21 -0500
Subject: [PATCH 1/3] remoteproc: pru: Fixup interrupt-parent logic for fw
 events
In-Reply-To: <20210406232837.GA330882@xps15>
References: <20210323223839.17464-1-s-anna@ti.com>
 <20210323223839.17464-2-s-anna@ti.com> <20210406232837.GA330882@xps15>
Message-ID: <00b3fcf3-c3ed-9c2c-712e-952af019f16b@ti.com>

On 4/6/21 6:28 PM, Mathieu Poirier wrote:
> On Tue, Mar 23, 2021 at 05:38:37PM -0500, Suman Anna wrote:
>> The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses
>> of_irq_find_parent() with PRU device node to get a handle to the PRUSS
>> Interrupt Controller at present. This logic however requires that the
>> PRU nodes always define a interrupt-parent property. This property is
>> neither a required/defined property as per the PRU remoteproc binding,
>> nor is relevant from a DT node point of view without any associated
>> interrupts. The curret logic finds a wrong interrupt controller and
>> fails to perform proper mapping without any interrupt-parent property
>> in the PRU nodes.
>>
>> Fix this logic to always find and use the sibling interrupt controller.
>> Also, while at this, fix the acquired interrupt controller device node
>> reference properly.
>>
>> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
>> Signed-off-by: Suman Anna <s-anna at ti.com>
>> ---
>>  drivers/remoteproc/pru_rproc.c | 15 ++++++++++++---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
>> index 16979c1cd2f4..a9d07c0751be 100644
>> --- a/drivers/remoteproc/pru_rproc.c
>> +++ b/drivers/remoteproc/pru_rproc.c
>> @@ -284,7 +284,7 @@ static int pru_handle_intrmap(struct rproc *rproc)
>>  	struct pru_rproc *pru = rproc->priv;
>>  	struct pru_irq_rsc *rsc = pru->pru_interrupt_map;
>>  	struct irq_fwspec fwspec;
>> -	struct device_node *irq_parent;
>> +	struct device_node *parent, *irq_parent;
>>  	int i, ret = 0;
>>  
>>  	/* not having pru_interrupt_map is not an error */
>> @@ -312,9 +312,16 @@ static int pru_handle_intrmap(struct rproc *rproc)
>>  
>>  	/*
>>  	 * parse and fill in system event to interrupt channel and
>> -	 * channel-to-host mapping
>> +	 * channel-to-host mapping. The interrupt controller to be used
>> +	 * for these mappings for a given PRU remoteproc is always its
>> +	 * corresponding sibling PRUSS INTC node.
>>  	 */
>> -	irq_parent = of_irq_find_parent(pru->dev->of_node);
> 
> If I understand correctly when an interrupt controller node wasn't speficied in
> the parent this was unwinding until it found one...

Correct if not specified in each PRU node, and ends up finding the complete
wrong interrupt controller (GIC) as it walks up the tree.

> 
>> +	parent = of_get_parent(dev_of_node(pru->dev));
>> +	if (!parent)
>> +		return -ENODEV;
>> +
>> +	irq_parent = of_get_child_by_name(parent, "interrupt-controller");
>> +	of_node_put(parent);
>>  	if (!irq_parent) {
>>  		kfree(pru->mapped_irq);
>>  		return -ENODEV;
>> @@ -337,11 +344,13 @@ static int pru_handle_intrmap(struct rproc *rproc)
>>  			goto map_fail;
>>  		}
>>  	}
>> +	of_node_put(irq_parent);
>>  
>>  	return ret;
>>  
>>  map_fail:
>>  	pru_dispose_irq_mapping(pru);
>> +	of_node_put(irq_parent);
> 
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

Thanks,
Suman

> 
>>  
>>  	return ret;
>>  }
>> -- 
>> 2.30.1
>>



From s-anna at ti.com  Wed Apr  7 15:34:16 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 09:34:16 -0500
Subject: [PATCH 3/3] remoteproc: pru: Fix and cleanup firmware interrupt
 mapping logic
In-Reply-To: <20210406234747.GC330882@xps15>
References: <20210323223839.17464-1-s-anna@ti.com>
 <20210323223839.17464-4-s-anna@ti.com> <20210406234747.GC330882@xps15>
Message-ID: <98a3bc08-5740-3e2c-0ed6-0381cb20283d@ti.com>

Hi Mathieu,

On 4/6/21 6:47 PM, Mathieu Poirier wrote:
> On Tue, Mar 23, 2021 at 05:38:39PM -0500, Suman Anna wrote:
>> The PRU firmware interrupt mappings are configured and unconfigured in
>> .start() and .stop() callbacks respectively using the variables 'evt_count'
>> and a 'mapped_irq' pointer. These variables are modified only during these
>> callbacks but are not re-initialized/reset properly during unwind or
>> failure paths. These stale values caused a kernel crash while stopping a
>> PRU remoteproc running a different firmware with no events on a subsequent
>> run after a previous run that was running a firmware with events.
>>
>> Fix this crash by ensuring that the evt_count is 0 and the mapped_irq
>> pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these
>> variables properly during any failures in the .start() callback. While
>> at this, the pru_dispose_irq_mapping() callsites are all made to look
>> the same, moving any conditional logic to inside the function.
>>
>> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
>> Reported-by: Vignesh Raghavendra <vigneshr at ti.com>
>> Signed-off-by: Suman Anna <s-anna at ti.com>
>> ---
>>  drivers/remoteproc/pru_rproc.c | 12 +++++++++---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
>> index 87b43976c51b..5df19acb90ed 100644
>> --- a/drivers/remoteproc/pru_rproc.c
>> +++ b/drivers/remoteproc/pru_rproc.c
>> @@ -266,12 +266,17 @@ static void pru_rproc_create_debug_entries(struct rproc *rproc)
>>  
>>  static void pru_dispose_irq_mapping(struct pru_rproc *pru)
>>  {
>> -	while (pru->evt_count--) {
>> +	if (!pru->mapped_irq)
>> +		return;
>> +
>> +	while (pru->evt_count) {
>> +		pru->evt_count--;
>>  		if (pru->mapped_irq[pru->evt_count] > 0)
>>  			irq_dispose_mapping(pru->mapped_irq[pru->evt_count]);
>>  	}
>>  
>>  	kfree(pru->mapped_irq);
>> +	pru->mapped_irq = NULL;
>>  }
>>  
>>  /*
>> @@ -324,6 +329,8 @@ static int pru_handle_intrmap(struct rproc *rproc)
>>  	of_node_put(parent);
>>  	if (!irq_parent) {
>>  		kfree(pru->mapped_irq);
>> +		pru->mapped_irq = NULL;
>> +		pru->evt_count = 0;
> 
> Patch 1/3 introduced a check on @parent that doesn't free pru->mapped_irq.  I
> would also expect that error path to do the same has what is done here.  And
> looking further up I see the error path for !pru->mapped_irq doesn't set
> pru->evt_count to zero.

Good catch, thank you. I will fix these up in v2.

regards
Suman

> 
> Thanks,
> Mathieu
> 
>>  		return -ENODEV;
>>  	}
>>  
>> @@ -398,8 +405,7 @@ static int pru_rproc_stop(struct rproc *rproc)
>>  	pru_control_write_reg(pru, PRU_CTRL_CTRL, val);
>>  
>>  	/* dispose irq mapping - new firmware can provide new mapping */
>> -	if (pru->mapped_irq)
>> -		pru_dispose_irq_mapping(pru);
>> +	pru_dispose_irq_mapping(pru);
>>  
>>  	return 0;
>>  }
>> -- 
>> 2.30.1
>>



From jitao.shi at mediatek.com  Wed Apr  7 15:36:56 2021
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Wed, 7 Apr 2021 22:36:56 +0800
Subject: [PATCH] drm/mediatek: force hsa hsa hfp packets multiple of line num
 to avoid screen shift
Message-ID: <20210407143656.2574-1-jitao.shi@mediatek.com>

The bridge chip ANX7625 require the line packets ending at the sametime
or ANX7625 will shift the screen.

Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a1ff152ef468..e825a80862de 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -194,6 +194,8 @@ struct mtk_dsi {
 	struct clk *hs_clk;
 
 	u32 data_rate;
+	/* force dsi line end without dsi_null data */
+	bool force_dsi_end_without_null;
 
 	unsigned long mode_flags;
 	enum mipi_dsi_pixel_format format;
@@ -495,6 +497,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
 		DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
 	}
 
+	if (dsi->force_dsi_end_without_null) {
+		horizontal_sync_active_byte = roundup(horizontal_sync_active_byte, dsi->lanes) - 2;
+		horizontal_frontporch_byte = roundup(horizontal_frontporch_byte, dsi->lanes) - 2;
+		horizontal_backporch_byte = roundup(horizontal_backporch_byte, dsi->lanes) - 2;
+		horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp + 2) % dsi->lanes;
+	}
+
 	writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
 	writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
 	writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
@@ -1091,6 +1100,9 @@ static int mtk_dsi_probe(struct platform_device *pdev)
 	dsi->bridge.of_node = dev->of_node;
 	dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
 
+	dsi->force_dsi_end_without_null = of_property_read_bool(dev->of_node,
+								"force_dsi_end_without_null");
+
 	drm_bridge_add(&dsi->bridge);
 
 	ret = component_add(&pdev->dev, &mtk_dsi_component_ops);
-- 
2.25.1

From alexandru.elisei at arm.com  Wed Apr  7 15:48:56 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed,  7 Apr 2021 15:48:56 +0100
Subject: [PATCH v3 1/2] Documentation: KVM: Document KVM_GUESTDBG_USE_HW
 control flag for arm64
In-Reply-To: <20210407144857.199746-1-alexandru.elisei@arm.com>
References: <20210407144857.199746-1-alexandru.elisei@arm.com>
Message-ID: <20210407144857.199746-2-alexandru.elisei@arm.com>

Commit 21b6f32f9471 ("KVM: arm64: guest debug, define API headers") added
the arm64 KVM_GUESTDBG_USE_HW flag for the KVM_SET_GUEST_DEBUG ioctl and
commit 834bf88726f0 ("KVM: arm64: enable KVM_CAP_SET_GUEST_DEBUG")
documented and implemented the flag functionality. Since its introduction,
at no point was the flag known by any name other than KVM_GUESTDBG_USE_HW
for the arm64 architecture, so refer to it as such in the documentation.

CC: Paolo Bonzini <pbonzini at redhat.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
---
 Documentation/virt/kvm/api.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 307f2fcf1b02..ffe15e02caca 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -3335,7 +3335,8 @@ The top 16 bits of the control field are architecture specific control
 flags which can include the following:
 
   - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
-  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390, arm64]
+  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390]
+  - KVM_GUESTDBG_USE_HW:        using hardware debug events [arm64]
   - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
   - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
   - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]
-- 
2.31.1



From alexandru.elisei at arm.com  Wed Apr  7 15:48:55 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed,  7 Apr 2021 15:48:55 +0100
Subject: [PATCH v3 0/2] KVM: arm64: Debug fixes
Message-ID: <20210407144857.199746-1-alexandru.elisei@arm.com>

v2 can be found at [1]. Patch #1 in this series is new.

Tested on an odroid-c4 with VHE. vcpu->arch.mdcr_el2 is calculated to be
0x84e66. Without this patch, reading MDCR_EL2 after the first vcpu_load() in
kvm_arch_vcpu_ioctl_run() returns 0, subsequent reads return 0xe66
(FEAT_TFF and FEAT_SPE are not implemented by the PE). With this patch, all
reads, including the first time the VCPU is run, return 0xe66.

Also tested on the odroid-c4 board with a host compiled with
CONFIG_DEBUG_PREEMPT=y by running 2 VMs in parallel, saw no errors in
dmesg.

Changes in v3:

* Patch #1 ("Documentation: KVM: Document KVM_GUESTDBG_USE_HW control flag
  for arm64") is new.
* Rebased on top of v5.12-rc6.
* kvm_arm_setup_mdcr_el2() uses __this_cpu_read() to read the host's
  MDCR_EL2 value and kvm_arm_vcpu_init_debug() calls it with preemption
  disabled.
* Rewrote the condition for setting MDCR_EL2.TDA with the intention to make
  it clearer (to be decided if that's indeed the case).

Changes in v2:

* Moved kvm_arm_vcpu_init_debug() earlier in kvm_vcpu_first_run_init() so
  vcpu->arch.mdcr_el2 is calculated even if kvm_vgic_map_resources() fails.
* Added comment to kvm_arm_setup_mdcr_el2 to explain what testing
  vcpu->guest_debug means.

v1 can be found at [2].

[1] https://www.spinics.net/lists/kvm-arm/msg45999.html
[2] https://www.spinics.net/lists/kvm-arm/msg42959.html

Alexandru Elisei (2):
  Documentation: KVM: Document KVM_GUESTDBG_USE_HW control flag for
    arm64
  KVM: arm64: Initialize VCPU mdcr_el2 before loading it

 Documentation/virt/kvm/api.rst    |  3 +-
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/arm.c              |  2 +
 arch/arm64/kvm/debug.c            | 88 +++++++++++++++++++++----------
 4 files changed, 65 insertions(+), 29 deletions(-)

-- 
2.31.1



From alexandru.elisei at arm.com  Wed Apr  7 15:48:57 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed,  7 Apr 2021 15:48:57 +0100
Subject: [PATCH v3 2/2] KVM: arm64: Initialize VCPU mdcr_el2 before loading it
In-Reply-To: <20210407144857.199746-1-alexandru.elisei@arm.com>
References: <20210407144857.199746-1-alexandru.elisei@arm.com>
Message-ID: <20210407144857.199746-3-alexandru.elisei@arm.com>

When a VCPU is created, the kvm_vcpu struct is initialized to zero in
kvm_vm_ioctl_create_vcpu(). On VHE systems, the first time
vcpu.arch.mdcr_el2 is loaded on hardware is in vcpu_load(), before it is
set to a sensible value in kvm_arm_setup_debug() later in the run loop. The
result is that KVM executes for a short time with MDCR_EL2 set to zero.

This has several unintended consequences:

* Setting MDCR_EL2.HPMN to 0 is constrained unpredictable according to ARM
  DDI 0487G.a, page D13-3820. The behavior specified by the architecture
  in this case is for the PE to behave as if MDCR_EL2.HPMN is set to a
  value less than or equal to PMCR_EL0.N, which means that an unknown
  number of counters are now disabled by MDCR_EL2.HPME, which is zero.

* The host configuration for the other debug features controlled by
  MDCR_EL2 is temporarily lost. This has been harmless so far, as Linux
  doesn't use the other fields, but that might change in the future.

Let's avoid both issues by initializing the VCPU's mdcr_el2 field in
kvm_vcpu_vcpu_first_run_init(), thus making sure that the MDCR_EL2 register
has a consistent value after each vcpu_load().

Fixes: d5a21bcc2995 ("KVM: arm64: Move common VHE/non-VHE trap config in separate functions")
Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/arm.c              |  2 +
 arch/arm64/kvm/debug.c            | 88 +++++++++++++++++++++----------
 3 files changed, 63 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527f7d..858c2fcfc043 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -713,6 +713,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
 static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
 
 void kvm_arm_init_debug(void);
+void kvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7f06ba76698d..455274c704b8 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -580,6 +580,8 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
 
 	vcpu->arch.has_run_once = true;
 
+	kvm_arm_vcpu_init_debug(vcpu);
+
 	if (likely(irqchip_in_kernel(kvm))) {
 		/*
 		 * Map the VGIC hardware resources before running a vcpu the
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index dbc890511631..2484b2cca74b 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -68,6 +68,64 @@ void kvm_arm_init_debug(void)
 	__this_cpu_write(mdcr_el2, kvm_call_hyp_ret(__kvm_get_mdcr_el2));
 }
 
+/**
+ * kvm_arm_setup_mdcr_el2 - configure vcpu mdcr_el2 value
+ *
+ * @vcpu:	the vcpu pointer
+ *
+ * This ensures we will trap access to:
+ *  - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR)
+ *  - Debug ROM Address (MDCR_EL2_TDRA)
+ *  - OS related registers (MDCR_EL2_TDOSA)
+ *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
+ *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
+ */
+static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
+{
+	/*
+	 * This also clears MDCR_EL2_E2PB_MASK to disable guest access
+	 * to the profiling buffer.
+	 */
+	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
+	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
+				MDCR_EL2_TPMS |
+				MDCR_EL2_TTRF |
+				MDCR_EL2_TPMCR |
+				MDCR_EL2_TDRA |
+				MDCR_EL2_TDOSA);
+
+	/* Is the VM being debugged by userspace? */
+	if (vcpu->guest_debug)
+		/* Route all software debug exceptions to EL2 */
+		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
+
+	/*
+	 * Trap debug register access when one of the following is true:
+	 *  - Userspace is using the hardware to debug the guest
+	 *  (KVM_GUESTDBG_USE_HW is set).
+	 *  - The guest is not using debug (KVM_ARM64_DEBUG_DIRTY is clear).
+	 */
+	if ((vcpu->guest_debug & KVM_GUESTDBG_USE_HW) ||
+	    !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY))
+		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
+
+	trace_kvm_arm_set_dreg32("MDCR_EL2", vcpu->arch.mdcr_el2);
+}
+
+/**
+ * kvm_arm_vcpu_init_debug - setup vcpu debug traps
+ *
+ * @vcpu:	the vcpu pointer
+ *
+ * Set vcpu initial mdcr_el2 value.
+ */
+void kvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu)
+{
+	preempt_disable();
+	kvm_arm_setup_mdcr_el2(vcpu);
+	preempt_enable();
+}
+
 /**
  * kvm_arm_reset_debug_ptr - reset the debug ptr to point to the vcpu state
  */
@@ -83,13 +141,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
  * @vcpu:	the vcpu pointer
  *
  * This is called before each entry into the hypervisor to setup any
- * debug related registers. Currently this just ensures we will trap
- * access to:
- *  - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR)
- *  - Debug ROM Address (MDCR_EL2_TDRA)
- *  - OS related registers (MDCR_EL2_TDOSA)
- *  - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
- *  - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
+ * debug related registers.
  *
  * Additionally, KVM only traps guest accesses to the debug registers if
  * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
@@ -101,28 +153,14 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
 
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 {
-	bool trap_debug = !(vcpu->arch.flags & KVM_ARM64_DEBUG_DIRTY);
 	unsigned long mdscr, orig_mdcr_el2 = vcpu->arch.mdcr_el2;
 
 	trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug);
 
-	/*
-	 * This also clears MDCR_EL2_E2PB_MASK to disable guest access
-	 * to the profiling buffer.
-	 */
-	vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
-	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
-				MDCR_EL2_TPMS |
-				MDCR_EL2_TTRF |
-				MDCR_EL2_TPMCR |
-				MDCR_EL2_TDRA |
-				MDCR_EL2_TDOSA);
+	kvm_arm_setup_mdcr_el2(vcpu);
 
 	/* Is Guest debugging in effect? */
 	if (vcpu->guest_debug) {
-		/* Route all software debug exceptions to EL2 */
-		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
-
 		/* Save guest debug state */
 		save_guest_debug_regs(vcpu);
 
@@ -176,7 +214,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 
 			vcpu->arch.debug_ptr = &vcpu->arch.external_debug_state;
 			vcpu->arch.flags |= KVM_ARM64_DEBUG_DIRTY;
-			trap_debug = true;
 
 			trace_kvm_arm_set_regset("BKPTS", get_num_brps(),
 						&vcpu->arch.debug_ptr->dbg_bcr[0],
@@ -191,10 +228,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	BUG_ON(!vcpu->guest_debug &&
 		vcpu->arch.debug_ptr != &vcpu->arch.vcpu_debug_state);
 
-	/* Trap debug register access */
-	if (trap_debug)
-		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
-
 	/* If KDE or MDE are set, perform a full save/restore cycle. */
 	if (vcpu_read_sys_reg(vcpu, MDSCR_EL1) & (DBG_MDSCR_KDE | DBG_MDSCR_MDE))
 		vcpu->arch.flags |= KVM_ARM64_DEBUG_DIRTY;
@@ -203,7 +236,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
 	if (has_vhe() && orig_mdcr_el2 != vcpu->arch.mdcr_el2)
 		write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
 
-	trace_kvm_arm_set_dreg32("MDCR_EL2", vcpu->arch.mdcr_el2);
 	trace_kvm_arm_set_dreg32("MDSCR_EL1", vcpu_read_sys_reg(vcpu, MDSCR_EL1));
 }
 
-- 
2.31.1



From nm at ti.com  Wed Apr  7 15:59:37 2021
From: nm at ti.com (Nishanth Menon)
Date: Wed, 7 Apr 2021 09:59:37 -0500
Subject: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in
 MMCSD1 subsystem
In-Reply-To: <20210407104303.25950-1-a-govindraju@ti.com>
References: <20210407104303.25950-1-a-govindraju@ti.com>
Message-ID: <20210407145937.prvue66guhdls2fw@immovably>

On 16:13-20210407, Aswath Govindraju wrote:
> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
> 
> Add support by removing the no-1-8-v tag and including the voltage
> regulator device tree nodes for power cycling.
> 
> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1
> 
> Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>

> ---
> 
> test logs:
> https://pastebin.ubuntu.com/p/vpYbY9QWh8/
> 
Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already
out). but it does trigger an interesting discussion..

>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  1 -
>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++++++++++++++++++
>  2 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index cb340d1b401f..632f32fce4a1 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -301,7 +301,6 @@
>  		ti,otap-del-sel = <0x2>;
>  		ti,trm-icp = <0x8>;
>  		dma-coherent;
> -		no-1-8-v;
>  	};
>  

Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0,
2.0, 2.1 coming along, the plan for TI was to support older revs via
overlays hoping that older boards will eventually get replaced or die
out of lack of use.. but you do have production on 1.0 -> so would you
rather handle this in overlay OR IOT boards dts introduce no-1-8-v
property?


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


From liam.howlett at oracle.com  Wed Apr  7 16:11:06 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Wed, 7 Apr 2021 15:11:06 +0000
Subject: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in traps
 for setting si_code
Message-ID: <20210407150940.542103-1-Liam.Howlett@Oracle.com>

find_vma() will continue to search upwards until the end of the virtual
memory space.  This means the si_code would almost never be set to
SEGV_MAPERR even when the address falls outside of any VMA.  The result
is that the si_code is not reliable as it may or may not be set to the
correct result, depending on where the address falls in the address
space.

Using find_vma_intersection() allows for what is intended by only
returning a VMA if it falls within the range provided, in this case a
window of 1.

Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---
 arch/arm64/kernel/traps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index a05d34f0e82a..a44007904a64 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
 void arm64_notify_segfault(unsigned long addr)
 {
 	int code;
+	unsigned long ut_addr = untagged_addr(addr);
 
 	mmap_read_lock(current->mm);
-	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
+	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
 		code = SEGV_MAPERR;
 	else
 		code = SEGV_ACCERR;
-- 
2.30.0


From richardcochran at gmail.com  Wed Apr  7 16:13:34 2021
From: richardcochran at gmail.com (Richard Cochran)
Date: Wed, 7 Apr 2021 08:13:34 -0700
Subject: [PATCH v19 3/7] ptp: Reorganize ptp_kvm.c to make it
 arch-independent
In-Reply-To: <87eefmpho3.wl-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-4-maz@kernel.org>
 <87eefmpho3.wl-maz@kernel.org>
Message-ID: <20210407151334.GB7379@hoboy.vegasvil.org>

On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
> On Tue, 30 Mar 2021 15:54:26 +0100,
> Marc Zyngier <maz at kernel.org> wrote:
> > 
> > From: Jianyong Wu <jianyong.wu at arm.com>
> > 
> > Currently, the ptp_kvm module contains a lot of x86-specific code.
> > Let's move this code into a new arch-specific file in the same directory,
> > and rename the arch-independent file to ptp_kvm_common.c.
> > 
> > Reviewed-by: Andre Przywara <andre.przywara at arm.com>
> > Signed-off-by: Jianyong Wu <jianyong.wu at arm.com>
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu at arm.com
> 
> Richard, Paolo,
> 
> Can I get an Ack on this and patch #7? We're getting pretty close to
> the next merge window, and this series has been going on for a couple
> of years now...

For both patches:

Acked-by: Richard Cochran <richardcochran at gmail.com>


From catalin.marinas at arm.com  Wed Apr  7 16:14:58 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 7 Apr 2021 16:14:58 +0100
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com>
 <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
Message-ID: <20210407151458.GC21451@arm.com>

On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> On 31/03/2021 19:43, Catalin Marinas wrote:
> > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > that's an opt-in by the VMM, haven't checked the other patches), can we
> > reject it if it's is going to be mapped as Normal Cacheable but it is a
> > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
> > check for ZONE_DEVICE)? This way we don't need to do more expensive
> > checks in set_pte_at().
> 
> The problem is that KVM allows the VMM to change the memory backing a slot
> while the guest is running. This is obviously useful for the likes of
> migration, but ultimately means that even if you were to do checks at the
> time of slot creation, you would need to repeat the checks at set_pte_at()
> time to ensure a mischievous VMM didn't swap the page for a problematic one.

Does changing the slot require some KVM API call? Can we intercept it
and do the checks there?

Maybe a better alternative for the time being is to add a new
kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns
true _and_ the VMM asked for MTE in guest. We can then only set
PG_mte_tagged if !device.

We can later relax this further to Normal Non-cacheable for ZONE_DEVICE
memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable
if we manage to change the behaviour of the architecture.

> > We could add another PROT_TAGGED or something which means PG_mte_tagged
> > set but still mapped as Normal Untagged. It's just that we are short of
> > pte bits for another flag.
> 
> That could help here - although it's slightly odd as you're asking the
> kernel to track the tags, but not allowing user space (direct) access to
> them. Like you say using us the precious bits for this seems like it might
> be short-sighted.

Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(),
so we already know it's a page potentially containing tags. On
restoring from swap, we need to check for MTE metadata irrespective of
whether the user pte is tagged or not, as you already did in patch 1.
I'll get back to that and look at the potential races.

BTW, after a page is restored from swap, how long do we keep the
metadata around? I think we can delete it as soon as it was restored and
PG_mte_tagged was set. Currently it looks like we only do this when the
actual page was freed or swapoff. I haven't convinced myself that it's
safe to do this for swapoff unless it guarantees that all the ptes
sharing a page have been restored.

-- 
Catalin


From gregkh at linuxfoundation.org  Wed Apr  7 16:18:31 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 7 Apr 2021 17:18:31 +0200
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate
 aspeed,sirq-polarity-sense
In-Reply-To: <20210402182724.20848-2-zev@bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
 <20210402182724.20848-2-zev@bewilderbeest.net>
Message-ID: <YG3NR4bGRjIGZhgx@kroah.com>

On Fri, Apr 02, 2021 at 01:27:21PM -0500, Zev Weiss wrote:
> This property ties SIRQ polarity to SCU register bits that don't
> necessarily have any direct relationship to it; the only use of it
> was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.

Please write that as:
	c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq polarity")

> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> Reviewed-by: Joel Stanley <joel at jms.id.au>
> ---
>  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
>  1 file changed, 1 insertion(+)

What changed from previous versions?  That always goes below the ---
line.

Please fix up and send a v5.

thanks,

greg k-h


From jan.kiszka at siemens.com  Wed Apr  7 16:13:37 2021
From: jan.kiszka at siemens.com (Jan Kiszka)
Date: Wed, 7 Apr 2021 17:13:37 +0200
Subject: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in
 MMCSD1 subsystem
In-Reply-To: <20210407145937.prvue66guhdls2fw@immovably>
References: <20210407104303.25950-1-a-govindraju@ti.com>
 <20210407145937.prvue66guhdls2fw@immovably>
Message-ID: <7d089f1c-6f9e-82fe-fc8a-42c691d4ec40@siemens.com>

On 07.04.21 16:59, Nishanth Menon wrote:
> On 16:13-20210407, Aswath Govindraju wrote:
>> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
>>
>> Add support by removing the no-1-8-v tag and including the voltage
>> regulator device tree nodes for power cycling.
>>
>> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1
>>
>> Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>
> 
>> ---
>>
>> test logs:
>> https://pastebin.ubuntu.com/p/vpYbY9QWh8/
>>
> Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already
> out). but it does trigger an interesting discussion..
> 
>>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  1 -
>>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++++++++++++++++++
>>  2 files changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index cb340d1b401f..632f32fce4a1 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -301,7 +301,6 @@
>>  		ti,otap-del-sel = <0x2>;
>>  		ti,trm-icp = <0x8>;
>>  		dma-coherent;
>> -		no-1-8-v;
>>  	};
>>  
> 
> Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0,
> 2.0, 2.1 coming along, the plan for TI was to support older revs via
> overlays hoping that older boards will eventually get replaced or die
> out of lack of use.. but you do have production on 1.0 -> so would you
> rather handle this in overlay OR IOT boards dts introduce no-1-8-v
> property?

I'm fine with pulling anything needed into our board-specific DTs. Those
pending are for SR1.0 boards only. SR2 will come later and have their
own DTs.

Didn't follow the thread: Where is this patch located wrt my IOT2050
series? Does it come first first, and we would have to rebase? Or would
this change rather have to move the flag to k3-am65-iot2050-common.dtsi?

Thanks a lot for having an eye on these subtle dependencies!

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux


From colin.king at canonical.com  Wed Apr  7 16:24:57 2021
From: colin.king at canonical.com (Colin King)
Date: Wed,  7 Apr 2021 16:24:57 +0100
Subject: [PATCH] clk: uniphier: Fix potential infinite loop
Message-ID: <20210407152457.497346-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of num_parents that is an int type.
There is a potential infinite loop if num_parents is larger than
the u8 loop counter. Fix this by making the loop counter the same
type as num_parents.

Addresses-Coverity: ("Infinite loop")
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
index 462c84321b2d..ce219e0d2a85 100644
--- a/drivers/clk/uniphier/clk-uniphier-mux.c
+++ b/drivers/clk/uniphier/clk-uniphier-mux.c
@@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
 	int num_parents = clk_hw_get_num_parents(hw);
 	int ret;
 	unsigned int val;
-	u8 i;
+	int i;
 
 	ret = regmap_read(mux->regmap, mux->reg, &val);
 	if (ret)
-- 
2.30.2



From david at redhat.com  Wed Apr  7 16:30:05 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 7 Apr 2021 17:30:05 +0200
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210407151458.GC21451@arm.com>
References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com>
 <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
 <20210407151458.GC21451@arm.com>
Message-ID: <396423df-5c30-67f6-fcba-c041c08eef7e@redhat.com>

On 07.04.21 17:14, Catalin Marinas wrote:
> On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
>> On 31/03/2021 19:43, Catalin Marinas wrote:
>>> When a slot is added by the VMM, if it asked for MTE in guest (I guess
>>> that's an opt-in by the VMM, haven't checked the other patches), can we
>>> reject it if it's is going to be mapped as Normal Cacheable but it is a
>>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
>>> check for ZONE_DEVICE)? This way we don't need to do more expensive
>>> checks in set_pte_at().
>>
>> The problem is that KVM allows the VMM to change the memory backing a slot
>> while the guest is running. This is obviously useful for the likes of
>> migration, but ultimately means that even if you were to do checks at the
>> time of slot creation, you would need to repeat the checks at set_pte_at()
>> time to ensure a mischievous VMM didn't swap the page for a problematic one.
> 
> Does changing the slot require some KVM API call? Can we intercept it
> and do the checks there?

User space can simply mmap(MAP_FIXED) the user space area registered in 
a KVM memory slot. You cannot really intercept that. You can only check 
in the KVM MMU code at fault time that the VMA which you hold in your 
hands is still in a proper state. The KVM MMU is synchronous, which 
means that updates to the VMA layout are reflected in the KVM MMU page 
tables -- e.g., via mmu notifier calls.

E.g., in s390x code we cannot handle VMAs with gigantic pages. We check 
that when faulting (creating the links in the page table) via __gmap_link().

You could either check the page itself (ZONE_DEVICE) or might even be 
able to check via the VMA/file.

-- 
Thanks,

David / dhildenb



From nm at ti.com  Wed Apr  7 16:30:38 2021
From: nm at ti.com (Nishanth Menon)
Date: Wed, 7 Apr 2021 10:30:38 -0500
Subject: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in
 MMCSD1 subsystem
In-Reply-To: <7d089f1c-6f9e-82fe-fc8a-42c691d4ec40@siemens.com>
References: <20210407104303.25950-1-a-govindraju@ti.com>
 <20210407145937.prvue66guhdls2fw@immovably>
 <7d089f1c-6f9e-82fe-fc8a-42c691d4ec40@siemens.com>
Message-ID: <20210407153038.fkwoctn4qvlplxfs@probation>

On 17:13-20210407, Jan Kiszka wrote:
> On 07.04.21 16:59, Nishanth Menon wrote:
> > On 16:13-20210407, Aswath Govindraju wrote:
> >> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
> >>
> >> Add support by removing the no-1-8-v tag and including the voltage
> >> regulator device tree nodes for power cycling.
> >>
> >> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1
> >>
> >> Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>
> > 
> >> ---
> >>
> >> test logs:
> >> https://pastebin.ubuntu.com/p/vpYbY9QWh8/
> >>
> > Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already
> > out). but it does trigger an interesting discussion..
> > 
> >>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi      |  1 -
> >>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++++++++++++++++++
> >>  2 files changed, 33 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> >> index cb340d1b401f..632f32fce4a1 100644
> >> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> >> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> >> @@ -301,7 +301,6 @@
> >>  		ti,otap-del-sel = <0x2>;
> >>  		ti,trm-icp = <0x8>;
> >>  		dma-coherent;
> >> -		no-1-8-v;
> >>  	};
> >>  
> > 
> > Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0,
> > 2.0, 2.1 coming along, the plan for TI was to support older revs via
> > overlays hoping that older boards will eventually get replaced or die
> > out of lack of use.. but you do have production on 1.0 -> so would you
> > rather handle this in overlay OR IOT boards dts introduce no-1-8-v
> > property?
> 
> I'm fine with pulling anything needed into our board-specific DTs. Those
> pending are for SR1.0 boards only. SR2 will come later and have their
> own DTs.

OK - I think the safe option will be for Ashwath to add no-1-8-v into
IOT board.dts as part of this patch to maintain bisectability.

> Didn't follow the thread: Where is this patch located wrt my IOT2050
> series? Does it come first first, and we would have to rebase? Or would
> this change rather have to move the flag to k3-am65-iot2050-common.dtsi?

5.13 PR is sent https://lore.kernel.org/linux-arm-kernel/20210405155336.smohb7uzkperqwuz at reflex/
IoT is part of that.. I am guessing Arnd / Olof will pick it up later this week
or weekend once it goes through their checklist.

we are starting to see 5.14 material now, so nothing you need to do from
rebase perspective - testing will be appreciated to make sure that the
new patches have'nt broken your board.

> Thanks a lot for having an eye on these subtle dependencies!

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


From alexandru.elisei at arm.com  Wed Apr  7 16:31:31 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 7 Apr 2021 16:31:31 +0100
Subject: [RFC PATCH v3 1/2] KVM: arm64: Move CMOs from user_mem_abort to
 the fault handlers
In-Reply-To: <20210326031654.3716-2-wangyanan55@huawei.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-2-wangyanan55@huawei.com>
Message-ID: <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>

Hi Yanan,

On 3/26/21 3:16 AM, Yanan Wang wrote:
> We currently uniformly permorm CMOs of D-cache and I-cache in function
> user_mem_abort before calling the fault handlers. If we get concurrent
> guest faults(e.g. translation faults, permission faults) or some really
> unnecessary guest faults caused by BBM, CMOs for the first vcpu are

I can't figure out what BBM means.

> necessary while the others later are not.
>
> By moving CMOs to the fault handlers, we can easily identify conditions
> where they are really needed and avoid the unnecessary ones. As it's a
> time consuming process to perform CMOs especially when flushing a block
> range, so this solution reduces much load of kvm and improve efficiency
> of the page table code.
>
> So let's move both clean of D-cache and invalidation of I-cache to the
> map path and move only invalidation of I-cache to the permission path.
> Since the original APIs for CMOs in mmu.c are only called in function
> user_mem_abort, we now also move them to pgtable.c.
>
> Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h | 31 ---------------
>  arch/arm64/kvm/hyp/pgtable.c     | 68 +++++++++++++++++++++++++-------
>  arch/arm64/kvm/mmu.c             | 23 ++---------
>  3 files changed, 57 insertions(+), 65 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 90873851f677..c31f88306d4e 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -177,37 +177,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
>  	return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
>  }
>  
> -static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
> -{
> -	void *va = page_address(pfn_to_page(pfn));
> -
> -	/*
> -	 * With FWB, we ensure that the guest always accesses memory using
> -	 * cacheable attributes, and we don't have to clean to PoC when
> -	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
> -	 * PoU is not required either in this case.
> -	 */
> -	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
> -		return;
> -
> -	kvm_flush_dcache_to_poc(va, size);
> -}
> -
> -static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
> -						  unsigned long size)
> -{
> -	if (icache_is_aliasing()) {
> -		/* any kind of VIPT cache */
> -		__flush_icache_all();
> -	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
> -		/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */
> -		void *va = page_address(pfn_to_page(pfn));
> -
> -		invalidate_icache_range((unsigned long)va,
> -					(unsigned long)va + size);
> -	}
> -}
> -
>  void kvm_set_way_flush(struct kvm_vcpu *vcpu);
>  void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
>  
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 4d177ce1d536..829a34eea526 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -464,6 +464,43 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot prot,
>  	return 0;
>  }
>  
> +static bool stage2_pte_cacheable(kvm_pte_t pte)
> +{
> +	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
> +	return memattr == PAGE_S2_MEMATTR(NORMAL);
> +}
> +
> +static bool stage2_pte_executable(kvm_pte_t pte)
> +{
> +	return !(pte & KVM_PTE_LEAF_ATTR_HI_S2_XN);
> +}
> +
> +static void stage2_flush_dcache(void *addr, u64 size)
> +{
> +	/*
> +	 * With FWB, we ensure that the guest always accesses memory using
> +	 * cacheable attributes, and we don't have to clean to PoC when
> +	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
> +	 * PoU is not required either in this case.
> +	 */
> +	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
> +		return;
> +
> +	__flush_dcache_area(addr, size);
> +}
> +
> +static void stage2_invalidate_icache(void *addr, u64 size)
> +{
> +	if (icache_is_aliasing()) {
> +		/* Flush any kind of VIPT icache */
> +		__flush_icache_all();
> +	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
> +		/* PIPT or VPIPT at EL2 */
> +		invalidate_icache_range((unsigned long)addr,
> +					(unsigned long)addr + size);
> +	}
> +}
> +
>  static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
>  				      kvm_pte_t *ptep,
>  				      struct stage2_map_data *data)
> @@ -495,6 +532,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
>  		put_page(page);
>  	}
>  
> +	/* Perform CMOs before installation of the new PTE */
> +	if (!kvm_pte_valid(old) || stage2_pte_cacheable(old))

I'm not sure why the stage2_pte_cacheable(old) condition is needed.

kvm_handle_guest_abort() handles three types of stage 2 data or instruction
aborts: translation faults (fault_status == FSC_FAULT), access faults
(fault_status == FSC_ACCESS) and permission faults (fault_status == FSC_PERM).

Access faults are handled in handle_access_fault(), which means user_mem_abort()
handles translation and permission faults. The original code did the dcache clean
+ inval when not a permission fault, which means the CMO was done only on a
translation fault. Translation faults mean that the IPA was not mapped, so the old
entry will always be invalid. Even if we're coalescing multiple last level leaf
entries int oa? block mapping, the table entry which is replaced is invalid
because it's marked as such in stage2_map_walk_table_pre().

Is there something I'm missing?

> +		stage2_flush_dcache(__va(phys), granule);
> +
> +	if (stage2_pte_executable(new))
> +		stage2_invalidate_icache(__va(phys), granule);

This, together with the stage2_attr_walker() changes below, look identical to the
current code in user_mem_abort(). The executable permission is set on an exec
fault (instruction abort not on a stage 2 translation table walk), and as a result
of the fault we either need to map a new page here, or relax permissions in
kvm_pgtable_stage2_relax_perms() -> stage2_attr_walker() below.

Thanks,

Alex

> +
>  	smp_store_release(ptep, new);
>  	get_page(page);
>  	data->phys += granule;
> @@ -651,20 +695,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
>  	return ret;
>  }
>  
> -static void stage2_flush_dcache(void *addr, u64 size)
> -{
> -	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
> -		return;
> -
> -	__flush_dcache_area(addr, size);
> -}
> -
> -static bool stage2_pte_cacheable(kvm_pte_t pte)
> -{
> -	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
> -	return memattr == PAGE_S2_MEMATTR(NORMAL);
> -}
> -
>  static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
>  			       enum kvm_pgtable_walk_flags flag,
>  			       void * const arg)
> @@ -743,8 +773,16 @@ static int stage2_attr_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
>  	 * but worst-case the access flag update gets lost and will be
>  	 * set on the next access instead.
>  	 */
> -	if (data->pte != pte)
> +	if (data->pte != pte) {
> +		/*
> +		 * Invalidate the instruction cache before updating
> +		 * if we are going to add the executable permission.
> +		 */
> +		if (!stage2_pte_executable(*ptep) && stage2_pte_executable(pte))
> +			stage2_invalidate_icache(kvm_pte_follow(pte),
> +						 kvm_granule_size(level));
>  		WRITE_ONCE(*ptep, pte);
> +	}
>  
>  	return 0;
>  }
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 77cb2d28f2a4..1eec9f63bc6f 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -609,16 +609,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
>  	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
>  }
>  
> -static void clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
> -{
> -	__clean_dcache_guest_page(pfn, size);
> -}
> -
> -static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
> -{
> -	__invalidate_icache_guest_page(pfn, size);
> -}
> -
>  static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>  {
>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
> @@ -882,13 +872,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	if (writable)
>  		prot |= KVM_PGTABLE_PROT_W;
>  
> -	if (fault_status != FSC_PERM && !device)
> -		clean_dcache_guest_page(pfn, vma_pagesize);
> -
> -	if (exec_fault) {
> +	if (exec_fault)
>  		prot |= KVM_PGTABLE_PROT_X;
> -		invalidate_icache_guest_page(pfn, vma_pagesize);
> -	}
>  
>  	if (device)
>  		prot |= KVM_PGTABLE_PROT_DEVICE;
> @@ -1144,10 +1129,10 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
>  	trace_kvm_set_spte_hva(hva);
>  
>  	/*
> -	 * We've moved a page around, probably through CoW, so let's treat it
> -	 * just like a translation fault and clean the cache to the PoC.
> +	 * We've moved a page around, probably through CoW, so let's treat
> +	 * it just like a translation fault and the map handler will clean
> +	 * the cache to the PoC.
>  	 */
> -	clean_dcache_guest_page(pfn, PAGE_SIZE);
>  	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
>  	return 0;
>  }


From maz at kernel.org  Wed Apr  7 16:31:04 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 16:31:04 +0100
Subject: [PATCH v19 3/7] ptp: Reorganize ptp_kvm.c to make it
 arch-independent
In-Reply-To: <20210407151334.GB7379@hoboy.vegasvil.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-4-maz@kernel.org>
 <87eefmpho3.wl-maz@kernel.org>
 <20210407151334.GB7379@hoboy.vegasvil.org>
Message-ID: <877dlep0w7.wl-maz@kernel.org>

On Wed, 07 Apr 2021 16:13:34 +0100,
Richard Cochran <richardcochran at gmail.com> wrote:
> 
> On Wed, Apr 07, 2021 at 10:28:44AM +0100, Marc Zyngier wrote:
> > On Tue, 30 Mar 2021 15:54:26 +0100,
> > Marc Zyngier <maz at kernel.org> wrote:
> > > 
> > > From: Jianyong Wu <jianyong.wu at arm.com>
> > > 
> > > Currently, the ptp_kvm module contains a lot of x86-specific code.
> > > Let's move this code into a new arch-specific file in the same directory,
> > > and rename the arch-independent file to ptp_kvm_common.c.
> > > 
> > > Reviewed-by: Andre Przywara <andre.przywara at arm.com>
> > > Signed-off-by: Jianyong Wu <jianyong.wu at arm.com>
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > Link: https://lore.kernel.org/r/20201209060932.212364-4-jianyong.wu at arm.com
> > 
> > Richard, Paolo,
> > 
> > Can I get an Ack on this and patch #7? We're getting pretty close to
> > the next merge window, and this series has been going on for a couple
> > of years now...
> 
> For both patches:
> 
> Acked-by: Richard Cochran <richardcochran at gmail.com>

Cheers Richard, much appreciated.

	M.

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


From alexandru.elisei at arm.com  Wed Apr  7 16:35:55 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 7 Apr 2021 16:35:55 +0100
Subject: [RFC PATCH v3 2/2] KVM: arm64: Distinguish cases of memcache
 allocations completely
In-Reply-To: <20210326031654.3716-3-wangyanan55@huawei.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-3-wangyanan55@huawei.com>
Message-ID: <4348b555-2a38-6f00-8ef0-0d5fd801d753@arm.com>

Hi Yanan,

On 3/26/21 3:16 AM, Yanan Wang wrote:
> With a guest translation fault, the memcache pages are not needed if KVM
> is only about to install a new leaf entry into the existing page table.
> And with a guest permission fault, the memcache pages are also not needed
> for a write_fault in dirty-logging time if KVM is only about to update
> the existing leaf entry instead of collapsing a block entry into a table.
>
> By comparing fault_granule and vma_pagesize, cases that require allocations
> from memcache and cases that don't can be distinguished completely.
>
> Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
> ---
>  arch/arm64/kvm/mmu.c | 25 ++++++++++++-------------
>  1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1eec9f63bc6f..05af40dc60c1 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -810,19 +810,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	gfn = fault_ipa >> PAGE_SHIFT;
>  	mmap_read_unlock(current->mm);
>  
> -	/*
> -	 * Permission faults just need to update the existing leaf entry,
> -	 * and so normally don't require allocations from the memcache. The
> -	 * only exception to this is when dirty logging is enabled at runtime
> -	 * and a write fault needs to collapse a block entry into a table.
> -	 */
> -	if (fault_status != FSC_PERM || (logging_active && write_fault)) {
> -		ret = kvm_mmu_topup_memory_cache(memcache,
> -						 kvm_mmu_cache_min_pages(kvm));
> -		if (ret)
> -			return ret;
> -	}
> -
>  	mmu_seq = vcpu->kvm->mmu_notifier_seq;
>  	/*
>  	 * Ensure the read of mmu_notifier_seq happens before we call
> @@ -880,6 +867,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
>  		prot |= KVM_PGTABLE_PROT_X;
>  
> +	/*
> +	 * Allocations from the memcache are required only when granule of the
> +	 * lookup level where the guest fault happened exceeds vma_pagesize,
> +	 * which means new page tables will be created in the fault handlers.
> +	 */
> +	if (fault_granule > vma_pagesize) {
> +		ret = kvm_mmu_topup_memory_cache(memcache,
> +						 kvm_mmu_cache_min_pages(kvm));
> +		if (ret)
> +			return ret;
> +	}

As I explained in v1 [1], this looks correct to me. I still think that someone
else should have a look, but if Marc decides to pick up this patch as-is, he can
add my Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>.

[1] https://lore.kernel.org/lkml/2c65bff2-be7f-b20c-9265-939bc73185b6 at arm.com/

Thanks,

Alex

> +
>  	/*
>  	 * Under the premise of getting a FSC_PERM fault, we just need to relax
>  	 * permissions only if vma_pagesize equals fault_granule. Otherwise,


From krzysztof.kozlowski at canonical.com  Wed Apr  7 16:44:47 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed,  7 Apr 2021 17:44:47 +0200
Subject: [PATCH] memory: atmel-sdramc: check of_device_get_match_data() return
 value
Message-ID: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com>

If the driver is probed, the of_device_get_match_data() should not
return NULL, however for sanity check its return value.

Addresses-Coverity: Dereference null return value
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/memory/atmel-sdramc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/memory/atmel-sdramc.c b/drivers/memory/atmel-sdramc.c
index 9c49d00c2a96..e09b2617f63d 100644
--- a/drivers/memory/atmel-sdramc.c
+++ b/drivers/memory/atmel-sdramc.c
@@ -45,6 +45,8 @@ static int atmel_ramc_probe(struct platform_device *pdev)
 	struct clk *clk;
 
 	caps = of_device_get_match_data(&pdev->dev);
+	if (!caps)
+		return -EINVAL;
 
 	if (caps->has_ddrck) {
 		clk = devm_clk_get(&pdev->dev, "ddrck");
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Wed Apr  7 16:45:35 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed,  7 Apr 2021 17:45:35 +0200
Subject: [PATCH] memory: samsung: exynos5422-dmc: handle clk_set_parent()
 failure
Message-ID: <20210407154535.70756-1-krzysztof.kozlowski@canonical.com>

clk_set_parent() can fail and ignoring such case could lead to invalid
clock setup for given frequency.

Addresses-Coverity: Unchecked return value
Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/memory/samsung/exynos5422-dmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
index 56f6e65d40cd..9c8318923ed0 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -1293,7 +1293,9 @@ static int exynos5_dmc_init_clks(struct exynos5_dmc *dmc)
 
 	dmc->curr_volt = target_volt;
 
-	clk_set_parent(dmc->mout_mx_mspll_ccore, dmc->mout_spll);
+	ret = clk_set_parent(dmc->mout_mx_mspll_ccore, dmc->mout_spll);
+	if (ret)
+		return ret;
 
 	clk_prepare_enable(dmc->fout_bpll);
 	clk_prepare_enable(dmc->mout_bpll);
-- 
2.25.1



From musamaanjum at gmail.com  Wed Apr  7 16:48:21 2021
From: musamaanjum at gmail.com (Muhammad Usama Anjum)
Date: Wed, 07 Apr 2021 20:48:21 +0500
Subject: [PATCH] staging: axis-fifo: media/meson: remove redundant
 dev_err call
In-Reply-To: <93218bc8-2cbb-bacc-f985-876a842261c4@xs4all.nl>
References: <20210407101047.GA1491258@LEGION>
 <93218bc8-2cbb-bacc-f985-876a842261c4@xs4all.nl>
Message-ID: <5daaeac37cfa5c07a1880ae49b712566a561ba1a.camel@gmail.com>

On Wed, 2021-04-07 at 16:05 +0200, Hans Verkuil wrote:
> Hi Muhammad,
> 
> On 07/04/2021 12:10, Muhammad Usama Anjum wrote:
> > devm_ioremap_resource() prints error message in itself. Remove the
> > dev_err call to avoid redundant error message.
> 
> Please split this up into two separate patches! They are independent
> changes and these two drivers are maintained by different people as well.
> 
> The patch itself looks OK, but it really has to be two separate patches.
> 
Okay. I'll send two separate patches. Thank you.

Regards,
Usama
> Regards,
> 
> 	Hans
> 
> > Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
> > ---
> >  drivers/staging/axis-fifo/axis-fifo.c   | 1 -
> >  drivers/staging/media/meson/vdec/vdec.c | 8 ++------
> >  2 files changed, 2 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c
> > index 2bb1c2e9cb57..ed9281089738 100644
> > --- a/drivers/staging/axis-fifo/axis-fifo.c
> > +++ b/drivers/staging/axis-fifo/axis-fifo.c
> > @@ -853,7 +853,6 @@ static int axis_fifo_probe(struct platform_device *pdev)
> >  	fifo->base_addr = devm_ioremap_resource(fifo->dt_device, r_mem);
> >  	if (IS_ERR(fifo->base_addr)) {
> >  		rc = PTR_ERR(fifo->base_addr);
> > -		dev_err(fifo->dt_device, "can't remap IO resource (%d)\n", rc);
> >  		goto err_initial;
> >  	}
> >  
> > diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
> > index 5d4db7a5b4b5..e51d69c4729d 100644
> > --- a/drivers/staging/media/meson/vdec/vdec.c
> > +++ b/drivers/staging/media/meson/vdec/vdec.c
> > @@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
> >  
> >  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
> >  	core->dos_base = devm_ioremap_resource(dev, r);
> > -	if (IS_ERR(core->dos_base)) {
> > -		dev_err(dev, "Couldn't remap DOS memory\n");
> > +	if (IS_ERR(core->dos_base))
> >  		return PTR_ERR(core->dos_base);
> > -	}
> >  
> >  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
> >  	core->esparser_base = devm_ioremap_resource(dev, r);
> > -	if (IS_ERR(core->esparser_base)) {
> > -		dev_err(dev, "Couldn't remap ESPARSER memory\n");
> > +	if (IS_ERR(core->esparser_base))
> >  		return PTR_ERR(core->esparser_base);
> > -	}
> >  
> >  	core->regmap_ao =
> >  		syscon_regmap_lookup_by_phandle(dev->of_node,
> > 



From maz at kernel.org  Wed Apr  7 16:50:23 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 16:50:23 +0100
Subject: [PATCH v3 1/2] Documentation: KVM: Document KVM_GUESTDBG_USE_HW
 control flag for arm64
In-Reply-To: <20210407144857.199746-2-alexandru.elisei@arm.com>
References: <20210407144857.199746-1-alexandru.elisei@arm.com>
 <20210407144857.199746-2-alexandru.elisei@arm.com>
Message-ID: <875z0yp000.wl-maz@kernel.org>

On Wed, 07 Apr 2021 15:48:56 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Commit 21b6f32f9471 ("KVM: arm64: guest debug, define API headers") added
> the arm64 KVM_GUESTDBG_USE_HW flag for the KVM_SET_GUEST_DEBUG ioctl and
> commit 834bf88726f0 ("KVM: arm64: enable KVM_CAP_SET_GUEST_DEBUG")
> documented and implemented the flag functionality. Since its introduction,
> at no point was the flag known by any name other than KVM_GUESTDBG_USE_HW
> for the arm64 architecture, so refer to it as such in the documentation.
> 
> CC: Paolo Bonzini <pbonzini at redhat.com>
> Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> ---
>  Documentation/virt/kvm/api.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 307f2fcf1b02..ffe15e02caca 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -3335,7 +3335,8 @@ The top 16 bits of the control field are architecture specific control
>  flags which can include the following:
>  
>    - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
> -  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390, arm64]
> +  - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390]
> +  - KVM_GUESTDBG_USE_HW:        using hardware debug events [arm64]
>    - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
>    - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
>    - KVM_GUESTDBG_EXIT_PENDING:  trigger an immediate guest exit [s390]

Huh, nice catch. I wonder why we had that difference. It clearly
wasn't intentional. Eventually, we probably should introduce the same
definition for arm64, and keep the old one as an unfortunate legacy.

Thanks,

	M.

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


From minyard at acm.org  Wed Apr  7 16:50:46 2021
From: minyard at acm.org (Corey Minyard)
Date: Wed, 7 Apr 2021 10:50:46 -0500
Subject: [PATCH v2 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver
In-Reply-To: <20210330141029.20412-3-quan@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-3-quan@os.amperecomputing.com>
Message-ID: <20210407155046.GF7166@minyard.net>

On Tue, Mar 30, 2021 at 09:10:28PM +0700, Quan Nguyen wrote:
> The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
> in-band IPMI communication with their host in management (BMC) side.
> 
> This commits adds support specifically for Aspeed AST2500 which commonly
> used as Board Management Controllers.

Two major comments:

This needs to be two patches: one with the generic SSIF slave code, and
one with the aspeed-specific code.  It's hard to tell that you are
adding generic code otherwise.

If you are going to add a generic interface like this, you need to add
documentation on how to use it, but from userland and from in the
kernel.

And some other comments:

Did you run this through checkpatch?

I think there is a high-level race condition in this code.  Consider the
following sequence:

  1) host writes a request to the BMC
  2) BMC reads the request
  3) host aborts the operation
  4) host write a new request to the BMC
  5) BMC sends the response to the first message

You probably need something to say that a response can only go out if
there is a request that has come in that has been read by the BMC.

Other comments inline.

> 
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
>  drivers/char/ipmi/Kconfig           |  22 +
>  drivers/char/ipmi/Makefile          |   2 +
>  drivers/char/ipmi/ssif_bmc.c        | 645 ++++++++++++++++++++++++++++
>  drivers/char/ipmi/ssif_bmc.h        |  92 ++++
>  drivers/char/ipmi/ssif_bmc_aspeed.c | 132 ++++++
>  5 files changed, 893 insertions(+)
>  create mode 100644 drivers/char/ipmi/ssif_bmc.c
>  create mode 100644 drivers/char/ipmi/ssif_bmc.h
>  create mode 100644 drivers/char/ipmi/ssif_bmc_aspeed.c
> 
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> index 07847d9a459a..45be57023577 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -133,6 +133,28 @@ config ASPEED_BT_IPMI_BMC
>  	  found on Aspeed SOCs (AST2400 and AST2500). The driver
>  	  implements the BMC side of the BT interface.
>  
> +config SSIF_IPMI_BMC
> +	tristate "SSIF IPMI BMC driver"
> +	select I2C
> +	select I2C_SLAVE
> +	help
> +	  This enables the IPMI SMBus system interface (SSIF) at the
> +	  management (BMC) side.
> +
> +	  The driver implements the BMC side of the SMBus system
> +	  interface (SSIF).
> +
> +config ASPEED_SSIF_IPMI_BMC
> +	depends on ARCH_ASPEED || COMPILE_TEST
> +	select SSIF_IPMI_BMC
> +	tristate "Aspeed SSIF IPMI BMC driver"
> +	help
> +	  Provides a driver for the SSIF IPMI interface found on
> +	  Aspeed AST2500 SoC.
> +
> +	  The driver implements the BMC side of the SMBus system
> +	  interface (SSIF), specific for Aspeed AST2500 SoC.
> +
>  config IPMB_DEVICE_INTERFACE
>  	tristate 'IPMB Interface handler'
>  	depends on I2C
> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> index 0822adc2ec41..05b993f7335b 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -27,3 +27,5 @@ obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>  obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
>  obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>  obj-$(CONFIG_IPMB_DEVICE_INTERFACE) += ipmb_dev_int.o
> +obj-$(CONFIG_SSIF_IPMI_BMC) += ssif_bmc.o
> +obj-$(CONFIG_ASPEED_SSIF_IPMI_BMC) += ssif_bmc_aspeed.o
> diff --git a/drivers/char/ipmi/ssif_bmc.c b/drivers/char/ipmi/ssif_bmc.c
> new file mode 100644
> index 000000000000..ae6e8750c795
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc.c
> @@ -0,0 +1,645 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The driver for BMC side of SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/poll.h>
> +#include <linux/sched.h>
> +#include <linux/mutex.h>
> +#include <linux/spinlock.h>
> +
> +#include "ssif_bmc.h"
> +
> +/*
> + * Call in WRITE context
> + */
> +static int send_ssif_bmc_response(struct ssif_bmc_ctx *ssif_bmc, bool non_blocking)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	if (!non_blocking) {
> +retry:
> +		ret = wait_event_interruptible(ssif_bmc->wait_queue,
> +					       !ssif_bmc->response_in_progress);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (ssif_bmc->response_in_progress) {
> +		spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +		if (non_blocking)
> +			return -EAGAIN;
> +
> +		goto retry;
> +	}

This would be a lot more elegant, and work better, if it was:

	
	spin_lock_irqsave(&ssif_bmc->lock, flags);
	while (ssif_bmc->response_in_progress) {
		if (non_blocking) {
			ret = -EAGAIN;
			goto out_unlock;
		}
		spin_unlock_irqrestore(&ssif_bmc->lock, flags);
		ret = wait_event_interruptible(ssif_bmc->wait_queue,
					       !ssif_bmc->response_in_progress);
		if (ret)
			return ret;
		spin_lock_irqsave(&ssif_bmc->lock, flags);
	}

Same with the receive function.  It avoids calling
wait_event_unnterruptible() unless required, and is easier to read.

> +
> +	/*
> +	 * Check the response data length from userspace to determine the type
> +	 * of the response message whether it is single-part or multi-part.
> +	 */
> +	ssif_bmc->is_singlepart_read =
> +		(ssif_msg_len(&ssif_bmc->response) <= (MAX_PAYLOAD_PER_TRANSACTION + 1)) ?
> +		true : false; /* 1: byte of length */
> +
> +	ssif_bmc->response_in_progress = true;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	return 0;
> +}
> +
> +/*
> + * Call in READ context
> + */
> +static int receive_ssif_bmc_request(struct ssif_bmc_ctx *ssif_bmc, bool non_blocking)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	if (!non_blocking) {
> +retry:
> +		ret = wait_event_interruptible(ssif_bmc->wait_queue,
> +					       ssif_bmc->request_available);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (!ssif_bmc->request_available) {
> +		spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +		if (non_blocking)
> +			return -EAGAIN;
> +		goto retry;
> +	}
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	return 0;
> +}
> +
> +/* Handle SSIF message that will be sent to user */
> +static ssize_t ssif_bmc_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	struct ssif_msg msg;
> +	unsigned long flags;
> +	ssize_t ret;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);

If you are sitting on a blocking read here, there's no way to send a
message, do poll, etc because you use the same mutex.  That doesn't seem
like a good idea.

> +
> +	ret = receive_ssif_bmc_request(ssif_bmc, file->f_flags & O_NONBLOCK);
> +	if (ret < 0)
> +		goto out;

This design has some issues.  I'd recommend getting rid of file_mutex
and only using the spinlock.  Claim the spinlock before calling
receive_ssif_bmc_request(), release the spinlock in that function if you
need to block (and document heavily that you do this), and when it
returns you either have an error or there is a message waiting.

You can actually just get rid of receive_ssif_bmc_request() and inline
the code here, if you like.  That might be easier to read.

> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	count = min_t(ssize_t, count, ssif_msg_len(&ssif_bmc->request));
> +	memcpy(&msg, &ssif_bmc->request, count);
> +	ssif_bmc->request_available = false;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	ret = copy_to_user(buf, &msg, count);
> +out:
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +
> +	return (ret < 0) ? ret : count;
> +}
> +
> +/* Handle SSIF message that is written by user */
> +static ssize_t ssif_bmc_write(struct file *file, const char __user *buf, size_t count,
> +			      loff_t *ppos)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	struct ssif_msg msg;
> +	unsigned long flags;
> +	ssize_t ret;
> +
> +	if (count > sizeof(struct ssif_msg))
> +		return -EINVAL;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);
> +
> +	ret = copy_from_user(&msg, buf, count);
> +	if (ret)
> +		goto out;

Same basic comments as the read side.  There is no need, BTW, to grab
the mutex before calling copy_from_user, since it's going into an
internal message buffer.

Speaking of that, ssif_msg is moderately big.  It's probably ok in this
case, but putting big things on the stack is generally frowned upon.

> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (count >= ssif_msg_len(&ssif_bmc->response))
> +		memcpy(&ssif_bmc->response, &msg, count);
> +	else
> +		ret = -EINVAL;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = send_ssif_bmc_response(ssif_bmc, file->f_flags & O_NONBLOCK);
> +	if (!ret && ssif_bmc->set_ssif_bmc_status)
> +		ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_READY);
> +out:
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +
> +	return (ret < 0) ? ret : count;
> +}
> +
> +static long ssif_bmc_ioctl(struct file *file, unsigned int cmd, unsigned long param)
> +{
> +	return 0;

I believe -EINVAL is the right return value here.  Or just remove the
function; it's not necessary if not implemented.

> +}
> +
> +static unsigned int ssif_bmc_poll(struct file *file, poll_table *wait)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	unsigned int mask = 0;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);

With this above comments, this will need to claim the spinlock.  Which
is what you want, anyway, because request_available is set under the
spinlock.

> +	poll_wait(file, &ssif_bmc->wait_queue, wait);
> +
> +	/*
> +	 * The request message is now available so userspace application can
> +	 * get the request
> +	 */
> +	if (ssif_bmc->request_available)
> +		mask |= POLLIN;

Is there a reason you don't implement the write side of this?  That
would seem useful.  Otherwise what's the write side supposed to do if it
gets an EAGAIN from the write()?  I guess, given how this driver works,
that's not really possible if it's used correctly.  But it would provide
a way to know when a response has finished send.

> +
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +	return mask;
> +}
> +
> +/*
> + * System calls to device interface for user apps
> + */
> +static const struct file_operations ssif_bmc_fops = {
> +	.owner		= THIS_MODULE,
> +	.read		= ssif_bmc_read,
> +	.write		= ssif_bmc_write,
> +	.poll		= ssif_bmc_poll,
> +	.unlocked_ioctl	= ssif_bmc_ioctl,
> +};
> +
> +/* Called with ssif_bmc->lock held. */
> +static int handle_request(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	if (ssif_bmc->set_ssif_bmc_status)
> +		ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_BUSY);
> +
> +	/* Request message is available to process */
> +	ssif_bmc->request_available = true;
> +	/*
> +	 * This is the new READ request.
> +	 * Clear the response buffer of the previous transaction
> +	 */
> +	memset(&ssif_bmc->response, 0, sizeof(struct ssif_msg));

This memset doesn't seem necessary.  You don't need to clear the data, I
don't think.

> +	wake_up_all(&ssif_bmc->wait_queue);
> +	return 0;
> +}
> +
> +/* Called with ssif_bmc->lock held. */
> +static int complete_response(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	/* Invalidate response in buffer to denote it having been sent. */
> +	ssif_bmc->response.len = 0;
> +	ssif_bmc->response_in_progress = false;
> +	ssif_bmc->nbytes_processed = 0;
> +	ssif_bmc->remain_len = 0;
> +	memset(&ssif_bmc->response_buf, 0, MAX_PAYLOAD_PER_TRANSACTION);

This memset seems unnecessary.

> +	wake_up_all(&ssif_bmc->wait_queue);
> +	return 0;
> +}
> +
> +static void set_multipart_response_buffer(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 response_len = 0;
> +	int idx = 0;
> +	u8 data_len;
> +
> +	data_len = ssif_bmc->response.len;
> +	switch (ssif_bmc->smbus_cmd) {
> +	case SSIF_IPMI_MULTIPART_READ_START:
> +		/*
> +		 * Read Start length is 32 bytes.
> +		 * Read Start transfer first 30 bytes of IPMI response
> +		 * and 2 special code 0x00, 0x01.
> +		 */
> +		*val = MAX_PAYLOAD_PER_TRANSACTION;
> +		ssif_bmc->remain_len = data_len - MAX_IPMI_DATA_PER_START_TRANSACTION;
> +		ssif_bmc->block_num = 0;
> +
> +		ssif_bmc->response_buf[idx++] = 0x00; /* Start Flag */
> +		ssif_bmc->response_buf[idx++] = 0x01; /* Start Flag */
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.netfn_lun;
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.cmd;
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.payload[0];
> +
> +		response_len = MAX_PAYLOAD_PER_TRANSACTION - idx;
> +
> +		memcpy(&ssif_bmc->response_buf[idx], &ssif_bmc->response.payload[1],
> +		       response_len);
> +		break;
> +
> +	case SSIF_IPMI_MULTIPART_READ_MIDDLE:
> +		/*
> +		 * IPMI READ Middle or READ End messages can carry up to 31 bytes
> +		 * IPMI data plus block number byte.
> +		 */
> +		if (ssif_bmc->remain_len < MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION) {
> +			/*
> +			 * This is READ End message
> +			 *  Return length is the remaining response data length
> +			 *  plus block number
> +			 *  Block number 0xFF is to indicate this is last message
> +			 *
> +			 * Return length is: remain response plus block number
> +			 */
> +			*val = ssif_bmc->remain_len + 1;
> +			ssif_bmc->block_num = 0xFF;
> +			ssif_bmc->response_buf[idx++] = ssif_bmc->block_num;
> +			response_len = ssif_bmc->remain_len;
> +		} else {
> +			/*
> +			 * This is READ Middle message
> +			 *  Response length is the maximum SMBUS transfer length
> +			 *  Block number byte is incremented
> +			 * Return length is maximum SMBUS transfer length
> +			 */
> +			*val = MAX_PAYLOAD_PER_TRANSACTION;
> +			ssif_bmc->remain_len -= MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION;
> +			response_len = MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION;
> +			ssif_bmc->response_buf[idx++] = ssif_bmc->block_num;
> +			ssif_bmc->block_num++;
> +		}
> +
> +		memcpy(&ssif_bmc->response_buf[idx],
> +		       ssif_bmc->response.payload + 1 + ssif_bmc->nbytes_processed,
> +		       response_len);
> +		break;
> +
> +	default:
> +		/* Do not expect to go to this case */
> +		pr_err("Error: Unexpected SMBus command received 0x%x\n", ssif_bmc->smbus_cmd);
> +		break;
> +	}
> +
> +	ssif_bmc->nbytes_processed += response_len;
> +}
> +
> +static void set_singlepart_response_buffer(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf = (u8 *)&ssif_bmc->response;
> +
> +	/*
> +	 * Do not expect the IPMI response has data length 0.
> +	 * With some I2C SMBus controllers (Aspeed I2C), return 0 for
> +	 * the SMBus Read Request callback might cause bad state for
> +	 * the bus. So return 1 byte length so that master will
> +	 * resend the Read Request because the length of response is
> +	 * less than a normal IPMI response.
> +	 *
> +	 * Otherwise, return the length of IPMI response

Umm, shouldn't you reject zero length messages from the user, since that
is invalid?  Then this problem would go away.

> +	 */
> +	*val = (buf[ssif_bmc->msg_idx]) ? buf[ssif_bmc->msg_idx] : 0x1;
> +}
> +
> +/* Process the IPMI response that will be read by master */
> +static void handle_read_processed(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf;
> +	u8 pec_len, addr, len;
> +	u8 pec = 0;
> +
> +	pec_len = ssif_bmc->pec_support ? 1 : 0;
> +	/* PEC - Start Read Address */
> +	addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +	pec = i2c_smbus_pec(pec, &addr, 1);
> +	/* PEC - SSIF Command */
> +	pec = i2c_smbus_pec(pec, &ssif_bmc->smbus_cmd, 1);
> +	/* PEC - Restart Write Address */
> +	addr = addr | 0x01;
> +	pec = i2c_smbus_pec(pec, &addr, 1);
> +
> +	if (ssif_bmc->is_singlepart_read) {
> +		/* Single-part Read processing */
> +		buf = (u8 *)&ssif_bmc->response;
> +
> +		if (ssif_bmc->response.len && ssif_bmc->msg_idx < ssif_bmc->response.len) {
> +			ssif_bmc->msg_idx++;
> +			*val = buf[ssif_bmc->msg_idx];
> +		} else if (ssif_bmc->response.len &&
> +			   (ssif_bmc->msg_idx == ssif_bmc->response.len)) {
> +			ssif_bmc->msg_idx++;
> +			*val = i2c_smbus_pec(pec, buf, ssif_msg_len(&ssif_bmc->response));
> +		} else {
> +			*val = 0;
> +		}
> +		/* Invalidate response buffer to denote it is sent */
> +		if (ssif_bmc->msg_idx + 1 >= (ssif_msg_len(&ssif_bmc->response) + pec_len))
> +			complete_response(ssif_bmc);
> +	} else {
> +		/* Multi-part Read processing */
> +		switch (ssif_bmc->smbus_cmd) {
> +		case SSIF_IPMI_MULTIPART_READ_START:
> +		case SSIF_IPMI_MULTIPART_READ_MIDDLE:
> +			buf = (u8 *)&ssif_bmc->response_buf;
> +			*val = buf[ssif_bmc->msg_idx];
> +			ssif_bmc->msg_idx++;
> +			break;
> +		default:
> +			/* Do not expect to go to this case */
> +			pr_err("Error: Unexpected SMBus command received 0x%x\n",
> +			       ssif_bmc->smbus_cmd);
> +			break;
> +		}
> +		len = (ssif_bmc->block_num == 0xFF) ?
> +		       ssif_bmc->remain_len + 1 : MAX_PAYLOAD_PER_TRANSACTION;
> +		if (ssif_bmc->msg_idx == (len + 1)) {
> +			pec = i2c_smbus_pec(pec, &len, 1);
> +			*val = i2c_smbus_pec(pec, ssif_bmc->response_buf, len);
> +		}
> +		/* Invalidate response buffer to denote last response is sent */
> +		if (ssif_bmc->block_num == 0xFF &&
> +		    ssif_bmc->msg_idx > (ssif_bmc->remain_len + pec_len)) {
> +			complete_response(ssif_bmc);
> +		}
> +	}
> +}
> +
> +static void handle_write_received(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf;
> +	u8 smbus_cmd;
> +
> +	buf = (u8 *)&ssif_bmc->request;
> +	if (ssif_bmc->msg_idx >= sizeof(struct ssif_msg))
> +		return;
> +
> +	smbus_cmd = ssif_bmc->smbus_cmd;
> +	switch (smbus_cmd) {
> +	case SSIF_IPMI_SINGLEPART_WRITE:
> +		/* Single-part write */
> +		buf[ssif_bmc->msg_idx - 1] = *val;
> +		ssif_bmc->msg_idx++;
> +
> +		break;
> +	case SSIF_IPMI_MULTIPART_WRITE_START:
> +		/* Reset length to zero */
> +		if (ssif_bmc->msg_idx == 1)
> +			ssif_bmc->request.len = 0;
> +
> +		fallthrough;
> +	case SSIF_IPMI_MULTIPART_WRITE_MIDDLE:
> +	case SSIF_IPMI_MULTIPART_WRITE_END:
> +		/* Multi-part write, 2nd byte received is length */
> +		if (ssif_bmc->msg_idx == 1) {
> +			ssif_bmc->request.len += *val;
> +			ssif_bmc->recv_len = *val;
> +		} else {
> +			buf[ssif_bmc->msg_idx - 1 +
> +			    ssif_bmc->request.len - ssif_bmc->recv_len]	= *val;
> +		}
> +
> +		ssif_bmc->msg_idx++;
> +
> +		break;
> +	default:
> +		/* Do not expect to go to this case */
> +		pr_err("Error: Unexpected SMBus command received 0x%x\n", ssif_bmc->smbus_cmd);
> +		break;
> +	}
> +}
> +
> +static bool validate_pec(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	u8 rpec = 0, cpec = 0;
> +	bool ret = true;
> +	u8 addr, index;
> +	u8 *buf;
> +
> +	buf = (u8 *)&ssif_bmc->request;
> +	switch (ssif_bmc->smbus_cmd) {
> +	case SSIF_IPMI_SINGLEPART_WRITE:
> +		if ((ssif_bmc->msg_idx - 1) == ssif_msg_len(&ssif_bmc->request)) {
> +			/* PEC is not included */
> +			ssif_bmc->pec_support = false;
> +			return true;
> +		}
> +
> +		if ((ssif_bmc->msg_idx - 1) != (ssif_msg_len(&ssif_bmc->request) + 1))
> +			goto error;
> +
> +		/* PEC is included */
> +		ssif_bmc->pec_support = true;
> +		rpec = buf[ssif_bmc->msg_idx - 2];
> +		addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +		cpec = i2c_smbus_pec(cpec, &addr, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->smbus_cmd, 1);
> +		cpec = i2c_smbus_pec(cpec, buf, ssif_msg_len(&ssif_bmc->request));
> +		if (rpec != cpec) {
> +			pr_err("Bad PEC 0x%02x vs. 0x%02x\n", rpec, cpec);
> +			ret = false;
> +		}
> +
> +		break;
> +	case SSIF_IPMI_MULTIPART_WRITE_START:
> +	case SSIF_IPMI_MULTIPART_WRITE_MIDDLE:
> +	case SSIF_IPMI_MULTIPART_WRITE_END:
> +		index = ssif_bmc->request.len - ssif_bmc->recv_len;
> +		if ((ssif_bmc->msg_idx - 1 + index) == ssif_msg_len(&ssif_bmc->request)) {
> +			/* PEC is not included */
> +			ssif_bmc->pec_support = false;
> +			return true;
> +		}
> +
> +		if ((ssif_bmc->msg_idx - 1 + index) != (ssif_msg_len(&ssif_bmc->request) + 1))
> +			goto error;
> +
> +		/* PEC is included */
> +		ssif_bmc->pec_support = true;
> +		rpec = buf[ssif_bmc->msg_idx - 2 + index];
> +		addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +		cpec = i2c_smbus_pec(cpec, &addr, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->smbus_cmd, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->recv_len, 1);
> +		/* As SMBus specification does not allow the length
> +		 * (byte count) in the Write-Block protocol to be zero.
> +		 * Therefore, it is illegal to have the last Middle
> +		 * transaction in the sequence carry 32-bytes and have
> +		 * a length of ?0? in the End transaction.
> +		 * But some users may try to use this way and we should
> +		 * prevent ssif_bmc driver broken in this case.
> +		 */
> +		if (ssif_bmc->recv_len != 0)
> +			cpec = i2c_smbus_pec(cpec, buf + 1 + index, ssif_bmc->recv_len);
> +
> +		if (rpec != cpec) {
> +			pr_err("Bad PEC 0x%02x vs. 0x%02x\n", rpec, cpec);
> +			ret = false;
> +		}
> +
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return ret;
> +error:
> +	/* Do not expect to go to this case */
> +	pr_err("Error: Unexpected length received %d\n", ssif_msg_len(&ssif_bmc->request));
> +
> +	return false;
> +}
> +
> +static void complete_write_received(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	u8 cmd = ssif_bmc->smbus_cmd;
> +
> +	/* A BMC that receives an invalid PEC shall drop the data for the write
> +	 * transaction and any further transactions (read or write) until
> +	 * the next valid read or write Start transaction is received
> +	 */
> +	if (!validate_pec(ssif_bmc)) {
> +		pr_err("Received invalid PEC\n");
> +		return;
> +	}
> +
> +	if (cmd == SSIF_IPMI_SINGLEPART_WRITE || cmd == SSIF_IPMI_MULTIPART_WRITE_END)
> +		handle_request(ssif_bmc);
> +}
> +
> +/*
> + * Callback function to handle I2C slave events
> + */
> +static int ssif_bmc_cb(struct i2c_client *client, enum i2c_slave_event event, u8 *val)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = i2c_get_clientdata(client);
> +
> +	spin_lock(&ssif_bmc->lock);

You need the _irqsave version here.  You don't know if interrupts are
disabled or not.  Depends on the particular low-level driver.

> +
> +	/* I2C Event Handler:
> +	 *   I2C_SLAVE_READ_REQUESTED	0x0
> +	 *   I2C_SLAVE_WRITE_REQUESTED	0x1
> +	 *   I2C_SLAVE_READ_PROCESSED	0x2
> +	 *   I2C_SLAVE_WRITE_RECEIVED	0x3
> +	 *   I2C_SLAVE_STOP		0x4
> +	 */
> +	switch (event) {
> +	case I2C_SLAVE_READ_REQUESTED:

Shouldn't you NAK if you are expecting a read?

> +		ssif_bmc->msg_idx = 0;
> +		if (ssif_bmc->is_singlepart_read)
> +			set_singlepart_response_buffer(ssif_bmc, val);
> +		else
> +			set_multipart_response_buffer(ssif_bmc, val);
> +		break;
> +
> +	case I2C_SLAVE_WRITE_REQUESTED:

If this happens and you are sending a response, you need to clean up.
In fact, all of these commands need handling if they aren't expected.

> +		ssif_bmc->msg_idx = 0;
> +		break;
> +
> +	case I2C_SLAVE_READ_PROCESSED:
> +		handle_read_processed(ssif_bmc, val);
> +		break;
> +
> +	case I2C_SLAVE_WRITE_RECEIVED:
> +		/*
> +		 * First byte is SMBUS command, not a part of SSIF message.
> +		 * SSIF request buffer starts with msg_idx 1 for the first
> +		 *  buffer byte.
> +		 */
> +		if (ssif_bmc->msg_idx == 0) {
> +			/* SMBUS command can vary (single or multi-part) */
> +			ssif_bmc->smbus_cmd = *val;
> +			ssif_bmc->msg_idx++;
> +		} else {
> +			handle_write_received(ssif_bmc, val);
> +		}
> +
> +		break;
> +
> +	case I2C_SLAVE_STOP:
> +		/*
> +		 * PEC byte is appended at the end of each transaction.
> +		 * Detect PEC is support or not after receiving write request
> +		 * completely.
> +		 */
> +		if (ssif_bmc->last_event == I2C_SLAVE_WRITE_RECEIVED)
> +			complete_write_received(ssif_bmc);
> +		/* Reset message index */
> +		ssif_bmc->msg_idx = 0;
> +		break;
> +
> +	default:
> +		break;
> +	}
> +	ssif_bmc->last_event = event;
> +	spin_unlock(&ssif_bmc->lock);
> +
> +	return 0;
> +}
> +
> +struct ssif_bmc_ctx *ssif_bmc_alloc(struct i2c_client *client, int sizeof_priv)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc;
> +	int ret;
> +
> +	ssif_bmc = devm_kzalloc(&client->dev, sizeof(*ssif_bmc) + sizeof_priv, GFP_KERNEL);
> +	if (!ssif_bmc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	spin_lock_init(&ssif_bmc->lock);
> +
> +	init_waitqueue_head(&ssif_bmc->wait_queue);
> +	ssif_bmc->request_available = false;
> +	ssif_bmc->response_in_progress = false;
> +
> +	mutex_init(&ssif_bmc->file_mutex);
> +
> +	/* Register misc device interface */
> +	ssif_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
> +	ssif_bmc->miscdev.name = DEVICE_NAME;
> +	ssif_bmc->miscdev.fops = &ssif_bmc_fops;
> +	ssif_bmc->miscdev.parent = &client->dev;
> +	ret = misc_register(&ssif_bmc->miscdev);
> +	if (ret)
> +		goto out;
> +
> +	ssif_bmc->client = client;
> +	ssif_bmc->client->flags |= I2C_CLIENT_SLAVE;
> +
> +	/* Register I2C slave */
> +	i2c_set_clientdata(client, ssif_bmc);
> +	ret = i2c_slave_register(client, ssif_bmc_cb);
> +	if (ret) {
> +		misc_deregister(&ssif_bmc->miscdev);
> +		goto out;
> +	}
> +
> +	return ssif_bmc;
> +
> +out:
> +	devm_kfree(&client->dev, ssif_bmc);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(ssif_bmc_alloc);
> +
> +MODULE_AUTHOR("Chuong Tran <chuong at os.amperecomputing.com>");
> +MODULE_AUTHOR("Quan Nguyen <quan at os.amperecomputing.com>");
> +MODULE_DESCRIPTION("Linux device driver of the BMC IPMI SSIF interface.");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/char/ipmi/ssif_bmc.h b/drivers/char/ipmi/ssif_bmc.h
> new file mode 100644
> index 000000000000..a2ee090572db
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * The driver for BMC side of SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +#ifndef __SSIF_BMC_H__
> +#define __SSIF_BMC_H__
> +
> +#define DEVICE_NAME				"ipmi-ssif-host"
> +
> +#define GET_8BIT_ADDR(addr_7bit)		(((addr_7bit) << 1) & 0xff)
> +
> +#define MSG_PAYLOAD_LEN_MAX			252
> +
> +/* A standard SMBus Transaction is limited to 32 data bytes */
> +#define MAX_PAYLOAD_PER_TRANSACTION		32
> +
> +#define MAX_IPMI_DATA_PER_START_TRANSACTION	30
> +#define MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION	31
> +
> +#define SSIF_IPMI_SINGLEPART_WRITE		0x2
> +#define SSIF_IPMI_SINGLEPART_READ		0x3
> +#define SSIF_IPMI_MULTIPART_WRITE_START		0x6
> +#define SSIF_IPMI_MULTIPART_WRITE_MIDDLE	0x7
> +#define SSIF_IPMI_MULTIPART_WRITE_END		0x8
> +#define SSIF_IPMI_MULTIPART_READ_START		0x3
> +#define SSIF_IPMI_MULTIPART_READ_MIDDLE		0x9
> +
> +struct ssif_msg {
> +	u8 len;
> +	u8 netfn_lun;
> +	u8 cmd;
> +	u8 payload[MSG_PAYLOAD_LEN_MAX];
> +} __packed;
> +
> +static inline u32 ssif_msg_len(struct ssif_msg *ssif_msg)
> +{
> +	return ssif_msg->len + 1;
> +}
> +
> +#define SSIF_BMC_BUSY   0x01
> +#define SSIF_BMC_READY  0x02
> +
> +struct ssif_bmc_ctx {
> +	struct i2c_client	*client;
> +	struct miscdevice	miscdev;
> +	u8			smbus_cmd;
> +	struct ssif_msg		request;
> +	bool			request_available;
> +	struct ssif_msg		response;
> +	bool			response_in_progress;
> +	/* Response buffer for Multi-part Read Transaction */
> +	u8			response_buf[MAX_PAYLOAD_PER_TRANSACTION];
> +	/* Flag to identify a Multi-part Read Transaction */
> +	bool			is_singlepart_read;
> +	u8			nbytes_processed;
> +	u8			remain_len;
> +	u8			recv_len;
> +	/* Block Number of a Multi-part Read Transaction */
> +	u8			block_num;
> +	size_t			msg_idx;
> +	enum i2c_slave_event	last_event;
> +	bool			pec_support;
> +	spinlock_t		lock;
> +	wait_queue_head_t	wait_queue;
> +	struct mutex		file_mutex;
> +	void (*set_ssif_bmc_status)(struct ssif_bmc_ctx *ssif_bmc, unsigned int flags);
> +	void			*priv;
> +};
> +
> +static inline struct ssif_bmc_ctx *to_ssif_bmc(struct file *file)
> +{
> +	return container_of(file->private_data, struct ssif_bmc_ctx, miscdev);
> +}
> +
> +struct ssif_bmc_ctx *ssif_bmc_alloc(struct i2c_client *client, int sizeof_priv);
> +
> +#endif /* __SSIF_BMC_H__ */
> diff --git a/drivers/char/ipmi/ssif_bmc_aspeed.c b/drivers/char/ipmi/ssif_bmc_aspeed.c
> new file mode 100644
> index 000000000000..a563fcff5acc
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc_aspeed.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The driver for BMC side of Aspeed SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/poll.h>
> +#include <linux/iopoll.h>
> +
> +#include "ssif_bmc.h"
> +
> +struct aspeed_i2c_bus {
> +	struct i2c_adapter              adap;
> +	struct device                   *dev;
> +	void __iomem                    *base;
> +	struct reset_control            *rst;
> +	/* Synchronizes I/O mem access to base. */
> +	spinlock_t                      lock;
> +};
> +
> +#define ASPEED_I2C_INTR_CTRL_REG	0x0c
> +#define ASPEED_I2CD_INTR_SLAVE_MATCH	BIT(7)
> +#define ASPEED_I2CD_INTR_RX_DONE	BIT(2)
> +static void aspeed_i2c_enable_interrupt(struct aspeed_i2c_bus *bus, unsigned long mask)
> +{
> +	unsigned long current_mask;
> +
> +	current_mask = readl(bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +	writel(current_mask | mask, bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +}
> +
> +static void aspeed_i2c_disable_interrupt(struct aspeed_i2c_bus *bus, unsigned long mask)
> +{
> +	unsigned long current_mask;
> +
> +	current_mask = readl(bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +	writel(current_mask & ~mask, bus->base + ASPEED_I2C_INTR_CTRL_REG);

If there's any other driver that using this register, you are racing
with it.

> +}
> +
> +static void aspeed_set_ssif_bmc_status(struct ssif_bmc_ctx *ssif_bmc, unsigned int status)
> +{
> +	struct aspeed_i2c_bus *bus;
> +	unsigned long flags;
> +
> +	bus = (struct aspeed_i2c_bus *)ssif_bmc->priv;
> +	if (!bus)
> +		return;
> +
> +	spin_lock_irqsave(&bus->lock, flags);

I don't really understand the whole use of this interrupt disable.  What
happens if the host has decided to abort an operation and starts a new
one?  I would think you would want to handle that gracefully.  As it is,
you will sit there waiting for the host to read the response, and it
never will, and you will never get the new transaction.

Plus these don't seem to be interrupts, they seem to be base I2C
disables, which you would really want handled in the I2C driver itself.

I would recommend getting rid of all this and handling a new request
if it comes in.  Then you can just create a generic SSIF BMC compatible
that will work for anything.  Really, if the host has sent a new
message, you need to handle it.

> +
> +	if (status & SSIF_BMC_BUSY) {
> +		/* Ignore RX_DONE and SLAVE_MATCH when slave busy processing */
> +		aspeed_i2c_disable_interrupt(bus, ASPEED_I2CD_INTR_RX_DONE);
> +		aspeed_i2c_disable_interrupt(bus, ASPEED_I2CD_INTR_SLAVE_MATCH);

Why wouldn't you combine these into one call and or the values together?

> +	} else if (status & SSIF_BMC_READY) {
> +		/* Enable RX_DONE and SLAVE_MATCH when slave ready */
> +		aspeed_i2c_enable_interrupt(bus, ASPEED_I2CD_INTR_RX_DONE);
> +		aspeed_i2c_enable_interrupt(bus, ASPEED_I2CD_INTR_SLAVE_MATCH);
> +	}
> +
> +	spin_unlock_irqrestore(&bus->lock, flags);
> +}
> +
> +static int ssif_bmc_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc;
> +
> +	ssif_bmc = ssif_bmc_alloc(client, sizeof(struct aspeed_i2c_bus));
> +	if (IS_ERR(ssif_bmc))
> +		return PTR_ERR(ssif_bmc);
> +
> +	ssif_bmc->priv = i2c_get_adapdata(client->adapter);
> +	ssif_bmc->set_ssif_bmc_status = aspeed_set_ssif_bmc_status;
> +
> +	return 0;
> +}
> +
> +static int ssif_bmc_remove(struct i2c_client *client)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = i2c_get_clientdata(client);
> +
> +	i2c_slave_unregister(client);
> +	misc_deregister(&ssif_bmc->miscdev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id ssif_bmc_match[] = {
> +	{ .compatible = "aspeed,ast2500-ssif-bmc" },
> +	{ },
> +};
> +
> +static const struct i2c_device_id ssif_bmc_id[] = {
> +	{ DEVICE_NAME, 0 },
> +	{ },
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, ssif_bmc_id);
> +
> +static struct i2c_driver ssif_bmc_driver = {
> +	.driver		= {
> +		.name		= DEVICE_NAME,
> +		.of_match_table = ssif_bmc_match,
> +	},
> +	.probe		= ssif_bmc_probe,
> +	.remove		= ssif_bmc_remove,
> +	.id_table	= ssif_bmc_id,
> +};
> +
> +module_i2c_driver(ssif_bmc_driver);
> +
> +MODULE_AUTHOR("Chuong Tran <chuong at os.amperecomputing.com>");
> +MODULE_AUTHOR("Quan Nguyen <quan at os.amperecomputing.com>");
> +MODULE_DESCRIPTION("Linux device driver of Aspeed BMC IPMI SSIF interface.");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.28.0
> 


From steven.price at arm.com  Wed Apr  7 16:52:54 2021
From: steven.price at arm.com (Steven Price)
Date: Wed, 7 Apr 2021 16:52:54 +0100
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210407151458.GC21451@arm.com>
References: <20210327152324.GA28167@arm.com> <20210328122131.GB17535@arm.com>
 <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
 <20210407151458.GC21451@arm.com>
Message-ID: <5e5bf772-1e4d-ca59-a9d8-058a72dfad4f@arm.com>

On 07/04/2021 16:14, Catalin Marinas wrote:
> On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
>> On 31/03/2021 19:43, Catalin Marinas wrote:
>>> When a slot is added by the VMM, if it asked for MTE in guest (I guess
>>> that's an opt-in by the VMM, haven't checked the other patches), can we
>>> reject it if it's is going to be mapped as Normal Cacheable but it is a
>>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
>>> check for ZONE_DEVICE)? This way we don't need to do more expensive
>>> checks in set_pte_at().
>>
>> The problem is that KVM allows the VMM to change the memory backing a slot
>> while the guest is running. This is obviously useful for the likes of
>> migration, but ultimately means that even if you were to do checks at the
>> time of slot creation, you would need to repeat the checks at set_pte_at()
>> time to ensure a mischievous VMM didn't swap the page for a problematic one.
> 
> Does changing the slot require some KVM API call? Can we intercept it
> and do the checks there?

As David has already replied - KVM uses MMU notifiers, so there's not 
really a good place to intercept this before the fault.

> Maybe a better alternative for the time being is to add a new
> kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns
> true _and_ the VMM asked for MTE in guest. We can then only set
> PG_mte_tagged if !device.

KVM already has a kvm_is_device_pfn(), and yes I agree restricting the 
MTE checks to only !kvm_is_device_pfn() makes sense (I have the fix in 
my branch locally).

> We can later relax this further to Normal Non-cacheable for ZONE_DEVICE
> memory (via a new KVM_PGTABLE_PROT_NORMAL_NC) or even Normal Cacheable
> if we manage to change the behaviour of the architecture.

Indeed, it'll be interesting to see whether people want to build MTE 
capable systems with significant quantities of non-MTE capable memory. 
But for a first stage let's stick with either all guest memory (except 
devices) is MTE or you disable MTE for the guest.

>>> We could add another PROT_TAGGED or something which means PG_mte_tagged
>>> set but still mapped as Normal Untagged. It's just that we are short of
>>> pte bits for another flag.
>>
>> That could help here - although it's slightly odd as you're asking the
>> kernel to track the tags, but not allowing user space (direct) access to
>> them. Like you say using us the precious bits for this seems like it might
>> be short-sighted.
> 
> Yeah, let's scrap this idea. We set PG_mte_tagged in user_mem_abort(),
> so we already know it's a page potentially containing tags. On
> restoring from swap, we need to check for MTE metadata irrespective of
> whether the user pte is tagged or not, as you already did in patch 1.
> I'll get back to that and look at the potential races.
> 
> BTW, after a page is restored from swap, how long do we keep the
> metadata around? I think we can delete it as soon as it was restored and
> PG_mte_tagged was set. Currently it looks like we only do this when the
> actual page was freed or swapoff. I haven't convinced myself that it's
> safe to do this for swapoff unless it guarantees that all the ptes
> sharing a page have been restored.
> 

My initial thought was to free the metadata immediately. However it 
turns out that the following sequence can happen:

  1. Swap out a page
  2. Swap the page in *read only*
  3. Discard the page
  4. Swap the page in again

So there's no writing of the swap data again before (3). This works 
nicely with a swap device because after writing a page it stays there 
forever, so if you know it hasn't been modified it's pointless rewriting 
it. Sadly it's not quite so ideal with the MTE tags which are currently 
kept in RAM. Arguably it would make sense to modify the on-disk swap 
format to include the tags - but that would open a whole new can of worms!

swapoff needs to ensure that all the PTEs have been restored because 
after the swapoff has completed the PTEs will be pointing at a swap 
entry which is no longer valid (and could even have been reallocated to 
point to a new swap device). When you issue you a swapoff, Linux will 
scan the mmlist and the page tables of every process to search for swap 
entry PTEs relating to the swap which is being removed (see try_to_unuse()).

Steve


From broonie at kernel.org  Wed Apr  7 16:55:39 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 7 Apr 2021 16:55:39 +0100
Subject: [PATCH] arm64/sve: Rework SVE access trap to convert state in
 registers
In-Reply-To: <20210407124806.GC5510@sirena.org.uk>
References: <20210312190313.24598-1-broonie@kernel.org>
 <20210407114511.GA21451@arm.com>
 <20210407124806.GC5510@sirena.org.uk>
Message-ID: <20210407155539.GF5510@sirena.org.uk>

On Wed, Apr 07, 2021 at 01:48:06PM +0100, Mark Brown wrote:
> On Wed, Apr 07, 2021 at 12:45:12PM +0100, Catalin Marinas wrote:

> > via do_el0_svc(). So it looks like we may restore some old SVE state
> > after a syscall (maybe I'm missing something but it would be nice to
> > follow zero or preserved approach).
> 
> The state is currently converted via the fpsimd_to_sve() call in the
> trap handler, that *should* be dealing with anything required for
> conversion.  You're right that this seems to miss zeroing anything
> outside of the values it immediately writes - I might be missing
> something though.  It's only going to leak information from the current

Actually I found that we do have the zeroing - it's done in sve_alloc()
where we either kzalloc() a new state or memset() an existing state so
that's covered already
-------------- 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/20210407/5a78ae2b/attachment.sig>

From lukasz.luba at arm.com  Wed Apr  7 16:56:00 2021
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Wed, 7 Apr 2021 16:56:00 +0100
Subject: [PATCH] memory: samsung: exynos5422-dmc: handle clk_set_parent()
 failure
In-Reply-To: <20210407154535.70756-1-krzysztof.kozlowski@canonical.com>
References: <20210407154535.70756-1-krzysztof.kozlowski@canonical.com>
Message-ID: <1906533a-e86a-10fe-5bc3-4600af98d579@arm.com>

Hi Krzysztof,

On 4/7/21 4:45 PM, Krzysztof Kozlowski wrote:
> clk_set_parent() can fail and ignoring such case could lead to invalid
> clock setup for given frequency.
> 
> Addresses-Coverity: Unchecked return value
> Fixes: 6e7674c3c6df ("memory: Add DMC driver for Exynos5422")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
>   drivers/memory/samsung/exynos5422-dmc.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
> index 56f6e65d40cd..9c8318923ed0 100644
> --- a/drivers/memory/samsung/exynos5422-dmc.c
> +++ b/drivers/memory/samsung/exynos5422-dmc.c
> @@ -1293,7 +1293,9 @@ static int exynos5_dmc_init_clks(struct exynos5_dmc *dmc)
>   
>   	dmc->curr_volt = target_volt;
>   
> -	clk_set_parent(dmc->mout_mx_mspll_ccore, dmc->mout_spll);
> +	ret = clk_set_parent(dmc->mout_mx_mspll_ccore, dmc->mout_spll);
> +	if (ret)
> +		return ret;
>   
>   	clk_prepare_enable(dmc->fout_bpll);
>   	clk_prepare_enable(dmc->mout_bpll);
> 

Thanks for running these tests and for the patch.
I've checked how many many places this function is used in the kernel
and return is ignored - in a lot of places...

This patch LGTM.

Reviewed-by: Lukasz Luba <lukasz.luba at arm.com>

Regards,
Lukasz


From s-anna at ti.com  Wed Apr  7 16:56:38 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 10:56:38 -0500
Subject: [PATCH v2 0/3] PRU firmware event/interrupt mapping fixes
Message-ID: <20210407155641.5501-1-s-anna@ti.com>

Hi All,

The following is a minor revised version of the series [1] that includes fixes
for various different issues associated with the PRU firmware event/interrupt
mapping configuration logic. Please see the v1 cover-letter [1] for additional
details. 

There are currently no in-kernel dts nodes yet in mainline kernel (first
nodes will appear in v5.13-rc1) so these can be picked up for either v5.13
merge window or the current -rc cycle.

Changes in v2:
 - Picked up Reviewed-by tags on Patches 1 and 2
 - Revised Patch 3 to address additional error cleanup paths as
   pointed out by Mathieu.

regards
Suman

[1] https://patchwork.kernel.org/project/linux-remoteproc/cover/20210323223839.17464-1-s-anna at ti.com/

Suman Anna (3):
  remoteproc: pru: Fixup interrupt-parent logic for fw events
  remoteproc: pru: Fix wrong success return value for fw events
  remoteproc: pru: Fix and cleanup firmware interrupt mapping logic

 drivers/remoteproc/pru_rproc.c | 41 ++++++++++++++++++++++++++--------
 1 file changed, 32 insertions(+), 9 deletions(-)

-- 
2.30.1



From s-anna at ti.com  Wed Apr  7 16:56:39 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 10:56:39 -0500
Subject: [PATCH v2 1/3] remoteproc: pru: Fixup interrupt-parent logic for fw
 events
In-Reply-To: <20210407155641.5501-1-s-anna@ti.com>
References: <20210407155641.5501-1-s-anna@ti.com>
Message-ID: <20210407155641.5501-2-s-anna@ti.com>

The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses
of_irq_find_parent() with PRU device node to get a handle to the PRUSS
Interrupt Controller at present. This logic however requires that the
PRU nodes always define a interrupt-parent property. This property is
neither a required/defined property as per the PRU remoteproc binding,
nor is relevant from a DT node point of view without any associated
interrupts. The current logic finds a wrong interrupt controller and
fails to perform proper mapping without any interrupt-parent property
in the PRU nodes.

Fix this logic to always find and use the sibling interrupt controller.
Also, while at this, fix the acquired interrupt controller device node
reference properly.

Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
Signed-off-by: Suman Anna <s-anna at ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
v2:
 - Fixed one minor typo ((%s/curret/current) in patch description 
 - Picked up Reviewed-by tag
v1: https://patchwork.kernel.org/project/linux-remoteproc/patch/20210323223839.17464-2-s-anna at ti.com/

 drivers/remoteproc/pru_rproc.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 16979c1cd2f4..a9d07c0751be 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -284,7 +284,7 @@ static int pru_handle_intrmap(struct rproc *rproc)
 	struct pru_rproc *pru = rproc->priv;
 	struct pru_irq_rsc *rsc = pru->pru_interrupt_map;
 	struct irq_fwspec fwspec;
-	struct device_node *irq_parent;
+	struct device_node *parent, *irq_parent;
 	int i, ret = 0;
 
 	/* not having pru_interrupt_map is not an error */
@@ -312,9 +312,16 @@ static int pru_handle_intrmap(struct rproc *rproc)
 
 	/*
 	 * parse and fill in system event to interrupt channel and
-	 * channel-to-host mapping
+	 * channel-to-host mapping. The interrupt controller to be used
+	 * for these mappings for a given PRU remoteproc is always its
+	 * corresponding sibling PRUSS INTC node.
 	 */
-	irq_parent = of_irq_find_parent(pru->dev->of_node);
+	parent = of_get_parent(dev_of_node(pru->dev));
+	if (!parent)
+		return -ENODEV;
+
+	irq_parent = of_get_child_by_name(parent, "interrupt-controller");
+	of_node_put(parent);
 	if (!irq_parent) {
 		kfree(pru->mapped_irq);
 		return -ENODEV;
@@ -337,11 +344,13 @@ static int pru_handle_intrmap(struct rproc *rproc)
 			goto map_fail;
 		}
 	}
+	of_node_put(irq_parent);
 
 	return ret;
 
 map_fail:
 	pru_dispose_irq_mapping(pru);
+	of_node_put(irq_parent);
 
 	return ret;
 }
-- 
2.30.1



From s-anna at ti.com  Wed Apr  7 16:56:40 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 10:56:40 -0500
Subject: [PATCH v2 2/3] remoteproc: pru: Fix wrong success return value for fw
 events
In-Reply-To: <20210407155641.5501-1-s-anna@ti.com>
References: <20210407155641.5501-1-s-anna@ti.com>
Message-ID: <20210407155641.5501-3-s-anna@ti.com>

The irq_create_fwspec_mapping() returns a proper virq value on success
and 0 upon any failure. The pru_handle_intrmap() treats this as an error
and disposes all firmware event mappings correctly, but is returning
this incorrect value as is, letting the pru_rproc_start() interpret it
as a success and boot the PRU.

Fix this by returning an error value back upon any such failure. While
at this, revise the error trace to print some meaningful info about the
failed event.

Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
Signed-off-by: Suman Anna <s-anna at ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
v2:
 - No changes, picked up Reviewed-by tag
v1: https://patchwork.kernel.org/project/linux-remoteproc/patch/20210323223839.17464-3-s-anna at ti.com/

 drivers/remoteproc/pru_rproc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index a9d07c0751be..87b43976c51b 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -339,8 +339,10 @@ static int pru_handle_intrmap(struct rproc *rproc)
 
 		pru->mapped_irq[i] = irq_create_fwspec_mapping(&fwspec);
 		if (!pru->mapped_irq[i]) {
-			dev_err(dev, "failed to get virq\n");
-			ret = pru->mapped_irq[i];
+			dev_err(dev, "failed to get virq for fw mapping %d: event %d chnl %d host %d\n",
+				i, fwspec.param[0], fwspec.param[1],
+				fwspec.param[2]);
+			ret = -EINVAL;
 			goto map_fail;
 		}
 	}
-- 
2.30.1



From s-anna at ti.com  Wed Apr  7 16:56:41 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 7 Apr 2021 10:56:41 -0500
Subject: [PATCH v2 3/3] remoteproc: pru: Fix and cleanup firmware interrupt
 mapping logic
In-Reply-To: <20210407155641.5501-1-s-anna@ti.com>
References: <20210407155641.5501-1-s-anna@ti.com>
Message-ID: <20210407155641.5501-4-s-anna@ti.com>

The PRU firmware interrupt mappings are configured and unconfigured in
.start() and .stop() callbacks respectively using the variables 'evt_count'
and a 'mapped_irq' pointer. These variables are modified only during these
callbacks but are not re-initialized/reset properly during unwind or
failure paths. These stale values caused a kernel crash while stopping a
PRU remoteproc running a different firmware with no events on a subsequent
run after a previous run that was running a firmware with events.

Fix this crash by ensuring that the evt_count is 0 and the mapped_irq
pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these
variables properly during any failures in the .start() callback. While
at this, the pru_dispose_irq_mapping() callsites are all made to look
the same, moving any conditional logic to inside the function.

Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
Reported-by: Vignesh Raghavendra <vigneshr at ti.com>
Signed-off-by: Suman Anna <s-anna at ti.com>
---
v2:
 - Fixed two additional cleanup paths in pru_handle_intrmap()
   addressing Mathieu's review comment
v1: https://patchwork.kernel.org/project/linux-remoteproc/patch/20210323223839.17464-4-s-anna at ti.com/

 drivers/remoteproc/pru_rproc.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 87b43976c51b..04863bf23db8 100644
--- a/drivers/remoteproc/pru_rproc.c
+++ b/drivers/remoteproc/pru_rproc.c
@@ -266,12 +266,17 @@ static void pru_rproc_create_debug_entries(struct rproc *rproc)
 
 static void pru_dispose_irq_mapping(struct pru_rproc *pru)
 {
-	while (pru->evt_count--) {
+	if (!pru->mapped_irq)
+		return;
+
+	while (pru->evt_count) {
+		pru->evt_count--;
 		if (pru->mapped_irq[pru->evt_count] > 0)
 			irq_dispose_mapping(pru->mapped_irq[pru->evt_count]);
 	}
 
 	kfree(pru->mapped_irq);
+	pru->mapped_irq = NULL;
 }
 
 /*
@@ -307,8 +312,10 @@ static int pru_handle_intrmap(struct rproc *rproc)
 	pru->evt_count = rsc->num_evts;
 	pru->mapped_irq = kcalloc(pru->evt_count, sizeof(unsigned int),
 				  GFP_KERNEL);
-	if (!pru->mapped_irq)
+	if (!pru->mapped_irq) {
+		pru->evt_count = 0;
 		return -ENOMEM;
+	}
 
 	/*
 	 * parse and fill in system event to interrupt channel and
@@ -317,13 +324,19 @@ static int pru_handle_intrmap(struct rproc *rproc)
 	 * corresponding sibling PRUSS INTC node.
 	 */
 	parent = of_get_parent(dev_of_node(pru->dev));
-	if (!parent)
+	if (!parent) {
+		kfree(pru->mapped_irq);
+		pru->mapped_irq = NULL;
+		pru->evt_count = 0;
 		return -ENODEV;
+	}
 
 	irq_parent = of_get_child_by_name(parent, "interrupt-controller");
 	of_node_put(parent);
 	if (!irq_parent) {
 		kfree(pru->mapped_irq);
+		pru->mapped_irq = NULL;
+		pru->evt_count = 0;
 		return -ENODEV;
 	}
 
@@ -398,8 +411,7 @@ static int pru_rproc_stop(struct rproc *rproc)
 	pru_control_write_reg(pru, PRU_CTRL_CTRL, val);
 
 	/* dispose irq mapping - new firmware can provide new mapping */
-	if (pru->mapped_irq)
-		pru_dispose_irq_mapping(pru);
+	pru_dispose_irq_mapping(pru);
 
 	return 0;
 }
-- 
2.30.1



From maz at kernel.org  Wed Apr  7 16:58:48 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed,  7 Apr 2021 16:58:48 +0100
Subject: [PATCH v3 0/2] KVM: arm64: Debug fixes
In-Reply-To: <20210407144857.199746-1-alexandru.elisei@arm.com>
References: <20210407144857.199746-1-alexandru.elisei@arm.com>
Message-ID: <161781112106.1984801.2208066478824922199.b4-ty@kernel.org>

On Wed, 7 Apr 2021 15:48:55 +0100, Alexandru Elisei wrote:
> v2 can be found at [1]. Patch #1 in this series is new.
> 
> Tested on an odroid-c4 with VHE. vcpu->arch.mdcr_el2 is calculated to be
> 0x84e66. Without this patch, reading MDCR_EL2 after the first vcpu_load() in
> kvm_arch_vcpu_ioctl_run() returns 0, subsequent reads return 0xe66
> (FEAT_TFF and FEAT_SPE are not implemented by the PE). With this patch, all
> reads, including the first time the VCPU is run, return 0xe66.
> 
> [...]

Applied to kvm-arm64/debug-5.13, thanks!

[1/2] Documentation: KVM: Document KVM_GUESTDBG_USE_HW control flag for arm64
      commit: feb5dc3de03711d846f0b729cb12fc05cbe49ccb
[2/2] KVM: arm64: Initialize VCPU mdcr_el2 before loading it
      commit: 263d6287da1433aba11c5b4046388f2cdf49675c

Cheers,

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




From alexandru.elisei at arm.com  Wed Apr  7 16:59:58 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 7 Apr 2021 16:59:58 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <20210406125841.1077079-1-maz@kernel.org>
References: <20210406125841.1077079-1-maz@kernel.org>
Message-ID: <40906aba-3d29-db38-f305-0c32603b34dd@arm.com>

Hi Marc,

On 4/6/21 1:58 PM, Marc Zyngier wrote:
> Although the KVM_ARM_VCPU_INIT documentation mention that the
> registers are reset to their "initial values", it doesn't
> describe what these values are.
>
> Describe this state explicitly.

This is a good idea.

>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  Documentation/virt/kvm/api.rst | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 38e327d4b479..e2237e4e10ba 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -3115,6 +3115,16 @@ optional features it should have. ?This will cause a reset of the cpu
>  registers to their initial values. ?If this is not called, KVM_RUN will
>  return ENOEXEC for that vcpu.
>  
> +The initial values are defined as:
> +	- Processor state:
> +		* AArch64: EL1h, D, A, I and F bits set

That value matches the macro VCPU_RESET_STATE_EL1.

> +		* Aarch32: SVC, D, A, I and F bits set
VCPU_RESET_STATE_SVC doesn't have a D bit; according to ARM DDI 0487G.a, page
G1-5965, CPSR doesn't have a D bit either (I might be reading it wrong).
> +	- General Purpose registers, including PC and SP: set to 0

They are zero'ed explicitly in kvm_reset_vcpu().

> +	- FPSIMD/NEON registers: set to 0

I haven't been able to find where they are initialized explicitly, I assume they
aren't. They are zero because the kvm_vcpu struct is allocated via
kmem_cache_zalloc() in kvm_vm_ioctl_create_vcpu(), so this is correct.

> +	- SVE registers: set to 0

They are zero'ed explicitly in kvm_vcpu_reset_sve().

> +	- System registers: Reset to their architecturally defined
> +	  values as for a warm reset to EL1 (resp. SVC)

This is done in kvm_reset_vcpu() -> kvm_reset_sys_regs(), which from what I can
tell does the right thing, but I haven't checked each and every register.

Assuming the D bit for CPSR/SPSR was a typo and with it removed:

Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks,

Alex

> +
>  Note that because some registers reflect machine topology, all vcpus
>  should be created before this ioctl is invoked.
>  


From chunkuang.hu at kernel.org  Wed Apr  7 16:59:34 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Wed, 7 Apr 2021 23:59:34 +0800
Subject: [PATCH] drm/mediatek: force hsa hsa hfp packets multiple of line
 num to avoid screen shift
In-Reply-To: <20210407143656.2574-1-jitao.shi@mediatek.com>
References: <20210407143656.2574-1-jitao.shi@mediatek.com>
Message-ID: <CAAOTY_9sxEZ-M8dp1w4ac+DR-9ESOxVGfDfhd4d8MkCMsCj7kg@mail.gmail.com>

Hi, Jitao:

Jitao Shi <jitao.shi at mediatek.com> ? 2021?4?7? ?? ??10:37???
>
> The bridge chip ANX7625 require the line packets ending at the sametime
> or ANX7625 will shift the screen.
>
> Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a1ff152ef468..e825a80862de 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -194,6 +194,8 @@ struct mtk_dsi {
>         struct clk *hs_clk;
>
>         u32 data_rate;
> +       /* force dsi line end without dsi_null data */
> +       bool force_dsi_end_without_null;
>
>         unsigned long mode_flags;
>         enum mipi_dsi_pixel_format format;
> @@ -495,6 +497,13 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>                 DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
>         }
>
> +       if (dsi->force_dsi_end_without_null) {
> +               horizontal_sync_active_byte = roundup(horizontal_sync_active_byte, dsi->lanes) - 2;
> +               horizontal_frontporch_byte = roundup(horizontal_frontporch_byte, dsi->lanes) - 2;
> +               horizontal_backporch_byte = roundup(horizontal_backporch_byte, dsi->lanes) - 2;
> +               horizontal_backporch_byte -= (vm->hactive * dsi_tmp_buf_bpp + 2) % dsi->lanes;
> +       }
> +
>         writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
>         writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
>         writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> @@ -1091,6 +1100,9 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>         dsi->bridge.of_node = dev->of_node;
>         dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
>
> +       dsi->force_dsi_end_without_null = of_property_read_bool(dev->of_node,
> +                                                               "force_dsi_end_without_null");

If force_dsi_end_without_null is caused by ANX7625, I think we should
get this information from ANX7625.

Regards,
Chun-Kuang.

> +
>         drm_bridge_add(&dsi->bridge);
>
>         ret = component_add(&pdev->dev, &mtk_dsi_component_ops);
> --
> 2.25.1
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From mathieu.poirier at linaro.org  Wed Apr  7 17:00:04 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  7 Apr 2021 10:00:04 -0600
Subject: [PATCH 1/4] coresight: etm4x: Add ETM PID for Cortex-A78
In-Reply-To: <20210407160007.418053-1-mathieu.poirier@linaro.org>
References: <20210407160007.418053-1-mathieu.poirier@linaro.org>
Message-ID: <20210407160007.418053-2-mathieu.poirier@linaro.org>

From: Sai Prakash Ranjan <saiprakash.ranjan at codeaurora.org>

Add ETM PID for Cortex-A78 to the list of supported ETMs.

Link: https://lore.kernel.org/r/20210213112829.26834-1-saiprakash.ranjan at codeaurora.org
Reviewed-by: Mike Leach <mike.leach at linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan at codeaurora.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 15016f757828..a5b13a7779c3 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -1951,6 +1951,7 @@ static const struct amba_id etm4_ids[] = {
 	CS_AMBA_UCI_ID(0x000bbd05, uci_id_etm4),/* Cortex-A55 */
 	CS_AMBA_UCI_ID(0x000bbd0a, uci_id_etm4),/* Cortex-A75 */
 	CS_AMBA_UCI_ID(0x000bbd0c, uci_id_etm4),/* Neoverse N1 */
+	CS_AMBA_UCI_ID(0x000bbd41, uci_id_etm4),/* Cortex-A78 */
 	CS_AMBA_UCI_ID(0x000f0205, uci_id_etm4),/* Qualcomm Kryo */
 	CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
 	CS_AMBA_UCI_ID(0x000bb802, uci_id_etm4),/* Qualcomm Kryo 385 Cortex-A55 */
-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 17:00:06 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  7 Apr 2021 10:00:06 -0600
Subject: [PATCH 3/4] coresight: core: Fix typo in coresight-core.c
In-Reply-To: <20210407160007.418053-1-mathieu.poirier@linaro.org>
References: <20210407160007.418053-1-mathieu.poirier@linaro.org>
Message-ID: <20210407160007.418053-4-mathieu.poirier@linaro.org>

From: Qi Liu <liuqi115 at huawei.com>

Fix the following checkpatch warning:
WARNING: 'compoment' may be misspelled - perhaps 'component'?

Link: https://lore.kernel.org/r/1616487086-50418-1-git-send-email-liuqi115 at huawei.com
Signed-off-by: Qi Liu <liuqi115 at huawei.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 0062c8935653..b57bea167102 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -86,7 +86,7 @@ static int coresight_id_match(struct device *dev, void *data)
 	    i_csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
 		return 0;
 
-	/* Get the source ID for both compoment */
+	/* Get the source ID for both components */
 	trace_id = source_ops(csdev)->trace_id(csdev);
 	i_trace_id = source_ops(i_csdev)->trace_id(i_csdev);
 
-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 17:00:03 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  7 Apr 2021 10:00:03 -0600
Subject: [PATCH 0/4] coresight: Patches for v5.13
Message-ID: <20210407160007.418053-1-mathieu.poirier@linaro.org>

Hi Greg,

These are the coresight patches I'd like you to consider for
the v5.13 cycle.  There is only 4, the other ones will go
go through Marc's kvmarm tree as previously agreed.

I may have another (big) set coming later this week or early
next week but it may be on the late side for this much code.
We'll see when we get there.

Thanks,
Mathieu   


Mathieu Poirier (1):
  MAINTAINERS: Add CoreSight header files

Qi Liu (1):
  coresight: core: Fix typo in coresight-core.c

Sai Prakash Ranjan (1):
  coresight: etm4x: Add ETM PID for Cortex-A78

Wei Yongjun (1):
  coresight: etm: perf: Make symbol 'format_attr_contextid' static

 MAINTAINERS                                        | 1 +
 drivers/hwtracing/coresight/coresight-core.c       | 2 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c   | 2 +-
 drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 17:00:07 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  7 Apr 2021 10:00:07 -0600
Subject: [PATCH 4/4] MAINTAINERS: Add CoreSight header files
In-Reply-To: <20210407160007.418053-1-mathieu.poirier@linaro.org>
References: <20210407160007.418053-1-mathieu.poirier@linaro.org>
Message-ID: <20210407160007.418053-5-mathieu.poirier@linaro.org>

Adding CoreSight headers to the list of supported files so that maintainers
can be notified when changes are submitted.

Link: https://lore.kernel.org/r/20210326155431.2011889-1-mathieu.poirier at linaro.org
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6ae3955525a9..aa86b4d0bfce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1764,6 +1764,7 @@ F:	Documentation/devicetree/bindings/arm/coresight.txt
 F:	Documentation/trace/coresight/*
 F:	drivers/hwtracing/coresight/*
 F:	include/dt-bindings/arm/coresight-cti-dt.h
+F:	include/linux/coresight*
 F:	tools/perf/arch/arm/util/auxtrace.c
 F:	tools/perf/arch/arm/util/cs-etm.c
 F:	tools/perf/arch/arm/util/cs-etm.h
-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 17:00:05 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  7 Apr 2021 10:00:05 -0600
Subject: [PATCH 2/4] coresight: etm: perf: Make symbol 'format_attr_contextid'
 static
In-Reply-To: <20210407160007.418053-1-mathieu.poirier@linaro.org>
References: <20210407160007.418053-1-mathieu.poirier@linaro.org>
Message-ID: <20210407160007.418053-3-mathieu.poirier@linaro.org>

From: Wei Yongjun <weiyongjun1 at huawei.com>

The sparse tool complains as follows:

drivers/hwtracing/coresight/coresight-etm-perf.c:61:25: warning:
 symbol 'format_attr_contextid' was not declared. Should it be static?

This symbol is not used outside of coresight-etm-perf.c, so this
commit marks it static.

Reported-by: Hulk Robot <hulkci at huawei.com>
Link: https://lore.kernel.org/r/20210308123250.2417947-1-weiyongjun1 at huawei.com
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 0f603b4094f2..bdbb77334329 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -58,7 +58,7 @@ static ssize_t format_attr_contextid_show(struct device *dev,
 	return sprintf(page, "config:%d\n", pid_fmt);
 }
 
-struct device_attribute format_attr_contextid =
+static struct device_attribute format_attr_contextid =
 	__ATTR(contextid, 0444, format_attr_contextid_show, NULL);
 
 static struct attribute *etm_config_formats_attr[] = {
-- 
2.25.1



From lkp at intel.com  Wed Apr  7 17:04:17 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 8 Apr 2021 00:04:17 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1116/1704] drivers/gpio/gpio-xilinx.c:377:12:
 warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned
 int'} changes value from '18446744071562067967' to '2147483647'
Message-ID: <202104080012.H1Kij57h-lkp@intel.com>

Hi Srinivas,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   914337937cb6a106a2942347d8c8feacd2223299
commit: 256f37f6020654ff3d8044852f75542882301a26 [1116/1704] gpio: xilinx: Add irq support to the driver
config: alpha-randconfig-r012-20210407 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/256f37f6020654ff3d8044852f75542882301a26
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 256f37f6020654ff3d8044852f75542882301a26
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-xilinx.c: In function 'xgpio_irq_mask':
>> drivers/gpio/gpio-xilinx.c:377:12: warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value from '18446744071562067967' to '2147483647' [-Woverflow]
     377 |            ~XGPIO_GIER_IE);
   drivers/gpio/gpio-xilinx.c:42:51: note: in definition of macro 'xgpio_writereg'
      42 | # define xgpio_writereg(offset, val) __raw_writel(val, offset)
         |                                                   ^~~
   drivers/gpio/gpio-xilinx.c: In function 'xgpio_irqhandler':
   drivers/gpio/gpio-xilinx.c:472:14: warning: variable 'status' set but not used [-Wunused-but-set-variable]
     472 |  u32 offset, status, channel = 1;
         |              ^~~~~~


vim +377 drivers/gpio/gpio-xilinx.c

   342	
   343	/**
   344	 * xgpiops_irq_mask - Write the specified signal of the GPIO device.
   345	 * @irq_data: per irq and chip data passed down to chip functions
   346	 */
   347	static void xgpio_irq_mask(struct irq_data *irq_data)
   348	{
   349		unsigned long flags;
   350		struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
   351		u32 offset = irq_data->irq - chip->irq_base;
   352		u32 temp;
   353		s32 val;
   354		int index = xgpio_index(chip, 0);
   355	
   356		pr_debug("%s: Disable %d irq, irq_enable_mask 0x%x\n",
   357			 __func__, offset, chip->irq_enable);
   358	
   359		spin_lock_irqsave(&chip->gpio_lock[index], flags);
   360	
   361		chip->irq_enable &= ~BIT(offset);
   362	
   363		if (!chip->irq_enable) {
   364			/* Enable per channel interrupt */
   365			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   366			val = offset - chip->gpio_width[0] + 1;
   367			if (val > 0)
   368				temp &= 1;
   369			else
   370				temp &= 2;
   371			xgpio_writereg(chip->regs + XGPIO_IPIER_OFFSET, temp);
   372	
   373			/* Disable global interrupt if channel interrupts are unused */
   374			temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
   375			if (!temp)
   376				xgpio_writereg(chip->regs + XGPIO_GIER_OFFSET,
 > 377					       ~XGPIO_GIER_IE);
   378		}
   379		spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
   380	}
   381	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23996 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210408/c4710d41/attachment-0001.gz>

From arnd at arndb.de  Wed Apr  7 17:06:44 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 Apr 2021 18:06:44 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
In-Reply-To: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
References: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
Message-ID: <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>

On Wed, Apr 7, 2021 at 1:00 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
> Hi Olof and Arnd,
>
> Here comes the second round of arm64 DT patches. Hope I'm not too late.
> Basically we add several node to MT8167.
> ----------------------------------------------------------------
> Fabien Parent (6):

>       arm64: dts: mediatek: mt8167: add some DRM nodes

I stumbled over this patch adding a lot of aliases:

+       aliases {
+               aal0 = &aal;
+               ccorr0 = &ccorr;
+               color0 = &color;
+               dither0 = &dither;
+               dsi0 = &dsi;
+               ovl0 = &ovl0;
+               pwm0 = &disp_pwm;
+               rdma0 = &rdma0;
+               rdma1 = &rdma1;
+               wdma0 = &wdma;
+       };


Something doesn't quite feel right about this, and I checked with Rob,
who also thinks this looks wrong. I suppose we need to have a set of
well documented alias types rather than just having drivers make up
new ones on the spot.

I also noticed that some of the referenced nodes are missing a DT
binding file, so those need to be added and reviewed as well.

At this point, I'd prefer to drop the entire branch for v5.13 and have
you work it out for the next release.

       Arnd


From musamaanjum at gmail.com  Wed Apr  7 17:09:21 2021
From: musamaanjum at gmail.com (Muhammad Usama Anjum)
Date: Wed, 7 Apr 2021 21:09:21 +0500
Subject: [PATCH] staging: media/meson: remove redundant dev_err call
Message-ID: <20210407160921.GA1504294@LEGION>

devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.

Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
---
 drivers/staging/media/meson/vdec/vdec.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 5d4db7a5b4b5..e51d69c4729d 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
 	core->dos_base = devm_ioremap_resource(dev, r);
-	if (IS_ERR(core->dos_base)) {
-		dev_err(dev, "Couldn't remap DOS memory\n");
+	if (IS_ERR(core->dos_base))
 		return PTR_ERR(core->dos_base);
-	}
 
 	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
 	core->esparser_base = devm_ioremap_resource(dev, r);
-	if (IS_ERR(core->esparser_base)) {
-		dev_err(dev, "Couldn't remap ESPARSER memory\n");
+	if (IS_ERR(core->esparser_base))
 		return PTR_ERR(core->esparser_base);
-	}
 
 	core->regmap_ao =
 		syscon_regmap_lookup_by_phandle(dev->of_node,
-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 17:10:58 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 10:10:58 -0600
Subject: [PATCH v2 3/3] remoteproc: pru: Fix and cleanup firmware
 interrupt mapping logic
In-Reply-To: <20210407155641.5501-4-s-anna@ti.com>
References: <20210407155641.5501-1-s-anna@ti.com>
 <20210407155641.5501-4-s-anna@ti.com>
Message-ID: <20210407161058.GA418374@xps15>

On Wed, Apr 07, 2021 at 10:56:41AM -0500, Suman Anna wrote:
> The PRU firmware interrupt mappings are configured and unconfigured in
> .start() and .stop() callbacks respectively using the variables 'evt_count'
> and a 'mapped_irq' pointer. These variables are modified only during these
> callbacks but are not re-initialized/reset properly during unwind or
> failure paths. These stale values caused a kernel crash while stopping a
> PRU remoteproc running a different firmware with no events on a subsequent
> run after a previous run that was running a firmware with events.
> 
> Fix this crash by ensuring that the evt_count is 0 and the mapped_irq
> pointer is set to NULL in pru_dispose_irq_mapping(). Also, reset these
> variables properly during any failures in the .start() callback. While
> at this, the pru_dispose_irq_mapping() callsites are all made to look
> the same, moving any conditional logic to inside the function.
> 
> Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt configuration")
> Reported-by: Vignesh Raghavendra <vigneshr at ti.com>
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
> v2:
>  - Fixed two additional cleanup paths in pru_handle_intrmap()
>    addressing Mathieu's review comment
> v1: https://patchwork.kernel.org/project/linux-remoteproc/patch/20210323223839.17464-4-s-anna at ti.com/
> 
>  drivers/remoteproc/pru_rproc.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
 
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
> index 87b43976c51b..04863bf23db8 100644
> --- a/drivers/remoteproc/pru_rproc.c
> +++ b/drivers/remoteproc/pru_rproc.c
> @@ -266,12 +266,17 @@ static void pru_rproc_create_debug_entries(struct rproc *rproc)
>  
>  static void pru_dispose_irq_mapping(struct pru_rproc *pru)
>  {
> -	while (pru->evt_count--) {
> +	if (!pru->mapped_irq)
> +		return;
> +
> +	while (pru->evt_count) {
> +		pru->evt_count--;
>  		if (pru->mapped_irq[pru->evt_count] > 0)
>  			irq_dispose_mapping(pru->mapped_irq[pru->evt_count]);
>  	}
>  
>  	kfree(pru->mapped_irq);
> +	pru->mapped_irq = NULL;
>  }
>  
>  /*
> @@ -307,8 +312,10 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  	pru->evt_count = rsc->num_evts;
>  	pru->mapped_irq = kcalloc(pru->evt_count, sizeof(unsigned int),
>  				  GFP_KERNEL);
> -	if (!pru->mapped_irq)
> +	if (!pru->mapped_irq) {
> +		pru->evt_count = 0;
>  		return -ENOMEM;
> +	}
>  
>  	/*
>  	 * parse and fill in system event to interrupt channel and
> @@ -317,13 +324,19 @@ static int pru_handle_intrmap(struct rproc *rproc)
>  	 * corresponding sibling PRUSS INTC node.
>  	 */
>  	parent = of_get_parent(dev_of_node(pru->dev));
> -	if (!parent)
> +	if (!parent) {
> +		kfree(pru->mapped_irq);
> +		pru->mapped_irq = NULL;
> +		pru->evt_count = 0;
>  		return -ENODEV;
> +	}
>  
>  	irq_parent = of_get_child_by_name(parent, "interrupt-controller");
>  	of_node_put(parent);
>  	if (!irq_parent) {
>  		kfree(pru->mapped_irq);
> +		pru->mapped_irq = NULL;
> +		pru->evt_count = 0;
>  		return -ENODEV;
>  	}
>  
> @@ -398,8 +411,7 @@ static int pru_rproc_stop(struct rproc *rproc)
>  	pru_control_write_reg(pru, PRU_CTRL_CTRL, val);
>  
>  	/* dispose irq mapping - new firmware can provide new mapping */
> -	if (pru->mapped_irq)
> -		pru_dispose_irq_mapping(pru);
> +	pru_dispose_irq_mapping(pru);
>  
>  	return 0;
>  }
> -- 
> 2.30.1
> 


From benjamin.tissoires at redhat.com  Wed Apr  7 17:09:22 2021
From: benjamin.tissoires at redhat.com (Benjamin Tissoires)
Date: Wed, 7 Apr 2021 18:09:22 +0200
Subject: [RESEND 00/25] Rid W=1 warnings from HID
In-Reply-To: <20210406085605.GS2916463@dell>
References: <20210326143458.508959-1-lee.jones@linaro.org>
 <20210406085605.GS2916463@dell>
Message-ID: <CAO-hwJ+5Vd6jC2+0pfHLOw3opdXzKoc9pUWzxmBVhSvQvNWMsQ@mail.gmail.com>

On Tue, Apr 6, 2021 at 10:56 AM Lee Jones <lee.jones at linaro.org> wrote:
>
> On Fri, 26 Mar 2021, Lee Jones wrote:
>
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Lee Jones (25):
> >   HID: intel-ish-hid: Remove unused variable 'err'
> >   HID: ishtp-hid-client: Move variable to where it's actually used
> >   HID: intel-ish-hid: pci-ish: Remove unused variable 'ret'
> >   HID: intel-ish: Supply some missing param descriptions
> >   HID: intel-ish: Fix a naming disparity and a formatting error
> >   HID: usbhid: Repair a formatting issue in a struct description
> >   HID: intel-ish-hid: Fix a little doc-rot
> >   HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses
> >   HID: hid-alps: Correct struct misnaming
> >   HID: intel-ish-hid: Fix potential copy/paste error
> >   HID: hid-core: Fix incorrect function name in header
> >   HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in
> >     header
> >   HID: ishtp-hid-client: Fix incorrect function name report_bad_packet()
> >   HID: hid-kye: Fix incorrect function name for kye_tablet_enable()
> >   HID: hid-picolcd_core: Remove unused variable 'ret'
> >   HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote
> >     abuses
> >   HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs
> >   HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses
> >   HID: hid-uclogic-params: Ensure function names are present and correct
> >     in kernel-doc headers
> >   HID: hid-sensor-custom: Remove unused variable 'ret'
> >   HID: wacom_sys: Demote kernel-doc abuse
> >   HID: hid-sensor-hub: Remove unused struct member 'quirks'
> >   HID: hid-sensor-hub: Move 'hsdev' description to correct struct
> >     definition
> >   HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues
> >   HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning
>
> These have been on the list for a couple of weeks now.
>
> Is there anything I can do to help expedite their merge?
>
> I'm concerned since -rc6 has just been released.

Sorry for the delay.

I am currently queuing them locally and running a few tests on them. I
don't expect anything to happen, but better be safe than anything.

FWIW, I am splitting the series in 3:
- 11 patches for intel ish are going to be queued in for-5.13/intel-ish
- the thrustmaster one in for-5.13/thrustmaster
- the rest (13 patches) will be sent in for-5.13/warnings.

Cheers,
Benjamin



From khilman at baylibre.com  Wed Apr  7 17:17:23 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed,  7 Apr 2021 09:17:23 -0700
Subject: [PATCH 0/3] arm64: dts: meson: add support for MeCool
 KII-Pro/KIII-Pro
In-Reply-To: <20210329154753.30074-1-christianshewitt@gmail.com>
References: <20210329154753.30074-1-christianshewitt@gmail.com>
Message-ID: <161781223326.25927.5710421341360861748.b4-ty@baylibre.com>

On Mon, 29 Mar 2021 15:47:50 +0000, Christian Hewitt wrote:
> This series adds support for the MeCool (Videostrong) KII Pro (GXL)
> and KIII Pro (GXM) Android STB devices. These are quite popular due
> to the embedded multi-standard tuner card (which is sadly not-yet
> supported in the kernel). Both devices closely follow the Amlogic
> reference designs with keys/buttons/LED details taken from known-
> working vendor kernel device-trees.
> 
> [...]

Applied, thanks!

[1/3] dt-bindings: arm: amlogic: add MeCool KII/KIII Pro bindings
      commit: 0bbfea7c0469cbe0914c1800b70f607ed7638870
[2/3] arm64: dts: meson: add initial device-tree for MeCool KII Pro
      commit: d5454e7ce24a28bd22beb2fc02f1571b5748dfbb
[3/3] arm64: dts: meson: add initial device-tree for MeCool KIII Pro
      commit: 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e

Best regards,
-- 
Kevin Hilman <khilman at baylibre.com>


From khilman at baylibre.com  Wed Apr  7 17:17:24 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed,  7 Apr 2021 09:17:24 -0700
Subject: [PATCH v2 0/3] arm64: dts: meson: add support for MeCool
 KII-Pro/KIII-Pro
In-Reply-To: <20210402064521.30579-1-christianshewitt@gmail.com>
References: <20210402064521.30579-1-christianshewitt@gmail.com>
Message-ID: <161781223327.25927.15332865097812413350.b4-ty@baylibre.com>

On Fri, 2 Apr 2021 06:45:18 +0000, Christian Hewitt wrote:
> This series adds support for the MeCool (Videostrong) KII Pro (GXL)
> and KIII Pro (GXM) Android STB devices. These are quite popular due
> to the embedded multi-standard tuner card (which is sadly not-yet
> supported in the kernel). Both devices closely follow the Amlogic
> reference designs with keys/buttons/LED details taken from known-
> working vendor kernel device-trees.
> 
> [...]

Applied, thanks!

[1/3] dt-bindings: arm: amlogic: add MeCool KII/KIII Pro bindings
      commit: 0bbfea7c0469cbe0914c1800b70f607ed7638870
[2/3] arm64: dts: meson: add initial device-tree for MeCool KII Pro
      commit: d5454e7ce24a28bd22beb2fc02f1571b5748dfbb
[3/3] arm64: dts: meson: add initial device-tree for MeCool KIII Pro
      commit: 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e

Best regards,
-- 
Kevin Hilman <khilman at baylibre.com>


From mathieu.poirier at linaro.org  Wed Apr  7 17:18:36 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 10:18:36 -0600
Subject: [PATCH V2 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <1617095574-6764-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617095574-6764-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210407161836.GB418374@xps15>

On Tue, Mar 30, 2021 at 05:12:46PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> V2:
>  Patch 1/8, use fsl as vendor, typo fix
>  Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that change.
> 
> This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to parse
> imx,auto-boot
> This patchset depends on [1]
> 
> [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/1617082235-15923-1-git-send-email-peng.fan at oss.nxp.com/
> 
> Peng Fan (8):
>   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
>   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
>   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
>   remoteproc: imx_rproc: make clk optional
>   remoteproc: imx_rproc: parse fsl,auto-boot
>   remoteproc: imx_rproc: initial support for mutilple start/stop method
>   remoteproc: imx_rproc: support i.MX7ULP
>   remoteproc: imx_rproc: support i.MX8MN/P
>

There are glaring checkpatch warning on this set - the "DT compatible string"
ones are fine but the others are not negotiable.  As such I am dropping this set
entirely.
 
>  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
>  drivers/remoteproc/imx_rproc.c                | 170 +++++++++++++++---
>  2 files changed, 159 insertions(+), 22 deletions(-)
> 
> -- 
> 2.30.0
> 


From alexandre.belloni at bootlin.com  Wed Apr  7 17:19:44 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Wed, 7 Apr 2021 18:19:44 +0200
Subject: [PATCH] memory: atmel-sdramc: check of_device_get_match_data()
 return value
In-Reply-To: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com>
References: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com>
Message-ID: <YG3boJNqAoNCBeIB@piout.net>

Hi,

On 07/04/2021 17:44:47+0200, Krzysztof Kozlowski wrote:
> If the driver is probed, the of_device_get_match_data() should not
> return NULL, however for sanity check its return value.
> 

As you say, there is no way this will ever be the case, I don't see the
point of checking the return value, this adds 12 bytes for nothing...

Maybe coverity should be fixed as there are many drivers making the same
(true) assumption and I don't think this is worth the churn.

> Addresses-Coverity: Dereference null return value
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
>  drivers/memory/atmel-sdramc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/memory/atmel-sdramc.c b/drivers/memory/atmel-sdramc.c
> index 9c49d00c2a96..e09b2617f63d 100644
> --- a/drivers/memory/atmel-sdramc.c
> +++ b/drivers/memory/atmel-sdramc.c
> @@ -45,6 +45,8 @@ static int atmel_ramc_probe(struct platform_device *pdev)
>  	struct clk *clk;
>  
>  	caps = of_device_get_match_data(&pdev->dev);
> +	if (!caps)
> +		return -EINVAL;
>  
>  	if (caps->has_ddrck) {
>  		clk = devm_clk_get(&pdev->dev, "ddrck");
> -- 
> 2.25.1
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From maz at kernel.org  Wed Apr  7 17:26:47 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 07 Apr 2021 17:26:47 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <40906aba-3d29-db38-f305-0c32603b34dd@arm.com>
References: <20210406125841.1077079-1-maz@kernel.org>
 <40906aba-3d29-db38-f305-0c32603b34dd@arm.com>
Message-ID: <874kgioybc.wl-maz@kernel.org>

On Wed, 07 Apr 2021 16:59:58 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> On 4/6/21 1:58 PM, Marc Zyngier wrote:
> > Although the KVM_ARM_VCPU_INIT documentation mention that the
> > registers are reset to their "initial values", it doesn't
> > describe what these values are.
> >
> > Describe this state explicitly.
> 
> This is a good idea.

Yeah, it turns out this is something we need for pKVM, because the
reset state is slightly different.

> 
> >
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  Documentation/virt/kvm/api.rst | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> > index 38e327d4b479..e2237e4e10ba 100644
> > --- a/Documentation/virt/kvm/api.rst
> > +++ b/Documentation/virt/kvm/api.rst
> > @@ -3115,6 +3115,16 @@ optional features it should have. ?This will cause a reset of the cpu
> >  registers to their initial values. ?If this is not called, KVM_RUN will
> >  return ENOEXEC for that vcpu.
> >  
> > +The initial values are defined as:
> > +	- Processor state:
> > +		* AArch64: EL1h, D, A, I and F bits set
> 
> That value matches the macro VCPU_RESET_STATE_EL1.
> 
> > +		* Aarch32: SVC, D, A, I and F bits set
> VCPU_RESET_STATE_SVC doesn't have a D bit; according to ARM DDI 0487G.a, page
> G1-5965, CPSR doesn't have a D bit either (I might be reading it wrong).

Meh, copy paste. Thanks for that,

> > +	- General Purpose registers, including PC and SP: set to 0
> 
> They are zero'ed explicitly in kvm_reset_vcpu().
> 
> > +	- FPSIMD/NEON registers: set to 0
> 
> I haven't been able to find where they are initialized explicitly, I
> assume they aren't. They are zero because the kvm_vcpu struct is
> allocated via kmem_cache_zalloc() in kvm_vm_ioctl_create_vcpu(), so
> this is correct.

Indeed. However, this outlines an interesting buglet. Userspace is
allowed to call KVM_ARM_VCPU_INIT at any point, and get the vcpu back
to the reset state.

The lack of explicit wipeout of the FPSIMD file is on its own a bug
which crept in with e47c2055c6 ("KVM: arm64: Make struct kvm_regs
userspace-only"), when kvm_cpu_context started to use user_pt_regs
directly.

I'll fix that separately, thanks for pushing me to have a closer look.

> 
> > +	- SVE registers: set to 0
> 
> They are zero'ed explicitly in kvm_vcpu_reset_sve().
> 
> > +	- System registers: Reset to their architecturally defined
> > +	  values as for a warm reset to EL1 (resp. SVC)
> 
> This is done in kvm_reset_vcpu() -> kvm_reset_sys_regs(), which from
> what I can tell does the right thing, but I haven't checked each and
> every register.
> 
> Assuming the D bit for CPSR/SPSR was a typo and with it removed:
> 
> Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks for that. I'll send the other fix separately.

	M.

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


From mathieu.poirier at linaro.org  Wed Apr  7 17:29:26 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 10:29:26 -0600
Subject: [PATCH V2 1/4] remoteproc: imx: add missing of_node_put
In-Reply-To: <1617082235-15923-2-git-send-email-peng.fan@oss.nxp.com>
References: <1617082235-15923-1-git-send-email-peng.fan@oss.nxp.com>
 <1617082235-15923-2-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210407162926.GC418374@xps15>

On Tue, Mar 30, 2021 at 01:30:32PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> After of_parse_phandle, we need of_node_put to decrease the refcount
> of the device_node.
> 
> Reported-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 6d3207ccbaef..077413319f58 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -459,6 +459,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>  			return err;
>  		}
>  
> +		of_node_put(node);
> +

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  		if (b >= IMX7D_RPROC_MEM_MAX)
>  			break;
>  
> -- 
> 2.30.0
> 


From matthias.bgg at gmail.com  Wed Apr  7 17:34:12 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 7 Apr 2021 18:34:12 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
In-Reply-To: <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>
References: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
 <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>
Message-ID: <01c82108-64a8-33ee-3984-5bd7056a0002@gmail.com>

Hi Arnd,

On 07/04/2021 18:06, Arnd Bergmann wrote:
> On Wed, Apr 7, 2021 at 1:00 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
>>
>> Hi Olof and Arnd,
>>
>> Here comes the second round of arm64 DT patches. Hope I'm not too late.
>> Basically we add several node to MT8167.
>> ----------------------------------------------------------------
>> Fabien Parent (6):
> 
>>       arm64: dts: mediatek: mt8167: add some DRM nodes
> 
> I stumbled over this patch adding a lot of aliases:
> 
> +       aliases {
> +               aal0 = &aal;
> +               ccorr0 = &ccorr;
> +               color0 = &color;
> +               dither0 = &dither;
> +               dsi0 = &dsi;
> +               ovl0 = &ovl0;
> +               pwm0 = &disp_pwm;
> +               rdma0 = &rdma0;
> +               rdma1 = &rdma1;
> +               wdma0 = &wdma;
> +       };
> 
> 
> Something doesn't quite feel right about this, and I checked with Rob,
> who also thinks this looks wrong. I suppose we need to have a set of
> well documented alias types rather than just having drivers make up
> new ones on the spot.

These are needed in the DRM driver, see drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c

I added Chun-Kuang who is the maintainer of the driver. I think it's a good idea
to have this alias described in the binding. Maybe a good excuse to move to yaml
as well :)

> 
> I also noticed that some of the referenced nodes are missing a DT
> binding file, so those need to be added and reviewed as well.

I suppose you are talking about "mediatek,mt8173-vcodec-enc-vp8". The binding
patches are in the media tree [1]. Maybe I supposed wrongly that they will land
in v5.13? Or perhaps I should have mentioned that in the pull request.

If it wasn't about this compatible and you can still remember, please let me
know so that we can fix that :)

I double checked and didn't find any missing binding. Some of them only have the
fallback binding described, maybe that's what you are referring to.

> 
> At this point, I'd prefer to drop the entire branch for v5.13 and have
> you work it out for the next release.
> 

Fair enough, pull request was quite late. I'll queue them for the next round then.

Thanks for having a look,
Matthias

[1]
https://git.linuxtv.org/media_tree.git/commit/?id=dd0008beef0dda915a255691e8b3b0527efaf1d8



From mathieu.poirier at linaro.org  Wed Apr  7 17:36:42 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 10:36:42 -0600
Subject: [PATCH V2 3/4] remoteproc: imx: move memory parsing to rproc_ops
In-Reply-To: <1617082235-15923-4-git-send-email-peng.fan@oss.nxp.com>
References: <1617082235-15923-1-git-send-email-peng.fan@oss.nxp.com>
 <1617082235-15923-4-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210407163642.GD418374@xps15>

On Tue, Mar 30, 2021 at 01:30:34PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Use the rproc_ops::prepare() hook for doing memory resources
> reallocation when reattach an remote procesor.
> 
> Suggested-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index b05aae0ad7a2..7cd09971d1a4 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -317,7 +317,7 @@ static int imx_rproc_mem_release(struct rproc *rproc,
>  	return 0;
>  }
>  
> -static int imx_rproc_parse_memory_regions(struct rproc *rproc)
> +static int imx_rproc_prepare(struct rproc *rproc)
>  {
>  	struct imx_rproc *priv = rproc->priv;
>  	struct device_node *np = priv->dev->of_node;
> @@ -363,10 +363,7 @@ static int imx_rproc_parse_memory_regions(struct rproc *rproc)
>  
>  static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>  {
> -	int ret = imx_rproc_parse_memory_regions(rproc);
> -
> -	if (ret)
> -		return ret;
> +	int ret;
>  
>  	ret = rproc_elf_load_rsc_table(rproc, fw);
>  	if (ret)
> @@ -399,6 +396,7 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>  }
>  
>  static const struct rproc_ops imx_rproc_ops = {
> +	.prepare	= imx_rproc_prepare,
>  	.start		= imx_rproc_start,
>  	.stop		= imx_rproc_stop,
>  	.kick		= imx_rproc_kick,
> -- 
> 2.30.0
> 


From vee.khee.wong at linux.intel.com  Wed Apr  7 17:54:07 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Thu, 8 Apr 2021 00:54:07 +0800
Subject: [PATCH net-next 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <YG2/1fbNNIsbafZp@lunn.ch>
References: <20210407141537.2129-1-vee.khee.wong@linux.intel.com>
 <YG2/1fbNNIsbafZp@lunn.ch>
Message-ID: <20210407165407.GA27820@linux.intel.com>

On Wed, Apr 07, 2021 at 04:21:09PM +0200, Andrew Lunn wrote:
> On Wed, Apr 07, 2021 at 10:15:37PM +0800, Wong Vee Khee wrote:
> > From: Tan Tee Min <tee.min.tan at intel.com>
> > 
> > The Synopsis MAC controller supports auxiliary snapshot feature that
> > allows user to store a snapshot of the system time based on an external
> > event.
> > 
> > This patch add supports to the above mentioned feature. Users will be
> > able to triggered capturing the time snapshot from user-space using
> > application such as testptp or any other applications that uses the
> > PTP_EXTTS_REQUEST ioctl request.
> 
> You forgot to Cc: the PTP maintainer.
>

Will Cc Richard Cochran on v2.
 
> > @@ -159,6 +163,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
> >  					     priv->systime_flags);
> >  		spin_unlock_irqrestore(&priv->ptp_lock, flags);
> >  		break;
> > +	case PTP_CLK_REQ_EXTTS:
> > +		priv->plat->ext_snapshot_en = on;
> > +		mutex_lock(&priv->aux_ts_lock);
> > +		acr_value = readl(ptpaddr + PTP_ACR);
> > +		acr_value &= ~PTP_ACR_MASK;
> > +		if (on) {
> > +			/* Enable External snapshot trigger */
> > +			acr_value |= priv->plat->ext_snapshot_num;
> > +			acr_value |= PTP_ACR_ATSFC;
> > +			pr_info("Auxiliary Snapshot %d enabled.\n",
> > +				priv->plat->ext_snapshot_num >>
> > +				PTP_ACR_ATSEN_SHIFT);
> 
> dev_dbg()?
> 
> > +			/* Enable Timestamp Interrupt */
> > +			intr_value = readl(ioaddr + GMAC_INT_EN);
> > +			intr_value |= GMAC_INT_TSIE;
> > +			writel(intr_value, ioaddr + GMAC_INT_EN);
> > +
> > +		} else {
> > +			pr_info("Auxiliary Snapshot %d disabled.\n",
> > +				priv->plat->ext_snapshot_num >>
> > +				PTP_ACR_ATSEN_SHIFT);
> 
> dev_dbg()?
> 
> Do you really want to spam the kernel log with this?
>

Thanks for the review.
I will switch this to netdev_dbg().
 


From krzysztof.kozlowski at canonical.com  Wed Apr  7 17:55:27 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 7 Apr 2021 18:55:27 +0200
Subject: [PATCH] memory: atmel-sdramc: check of_device_get_match_data()
 return value
In-Reply-To: <YG3boJNqAoNCBeIB@piout.net>
References: <20210407154447.70540-1-krzysztof.kozlowski@canonical.com>
 <YG3boJNqAoNCBeIB@piout.net>
Message-ID: <57470934-d2db-a360-8347-4debe5830f7b@canonical.com>

On 07/04/2021 18:19, Alexandre Belloni wrote:
> Hi,
> 
> On 07/04/2021 17:44:47+0200, Krzysztof Kozlowski wrote:
>> If the driver is probed, the of_device_get_match_data() should not
>> return NULL, however for sanity check its return value.
>>
> 
> As you say, there is no way this will ever be the case, I don't see the
> point of checking the return value, this adds 12 bytes for nothing...
> 
> Maybe coverity should be fixed as there are many drivers making the same
> (true) assumption and I don't think this is worth the churn.

There are also several drivers having this check. To me an explicit NULL
check is better and more readable than non-obvious assumption that the
of_device_id table contains data for each entry and there is no other
bind method (like for OF+I2C drivers). Even if the case is not real,
this is nice, simple and explicit code.

Best regards,
Krzysztof


From zev at bewilderbeest.net  Wed Apr  7 17:56:04 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 7 Apr 2021 11:56:04 -0500
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate
 aspeed,sirq-polarity-sense
In-Reply-To: <YG3NR4bGRjIGZhgx@kroah.com>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
 <20210402182724.20848-2-zev@bewilderbeest.net>
 <YG3NR4bGRjIGZhgx@kroah.com>
Message-ID: <YG3kJC+6gLC6RzzQ@hatter.bewilderbeest.net>

On Wed, Apr 07, 2021 at 10:18:31AM CDT, Greg Kroah-Hartman wrote:
>On Fri, Apr 02, 2021 at 01:27:21PM -0500, Zev Weiss wrote:
>> This property ties SIRQ polarity to SCU register bits that don't
>> necessarily have any direct relationship to it; the only use of it
>> was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.
>
>Please write that as:
>	c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq polarity")
>

Ack, will do.

>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> Reviewed-by: Joel Stanley <joel at jms.id.au>
>> ---
>>  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
>>  1 file changed, 1 insertion(+)
>
>What changed from previous versions?  That always goes below the ---
>line.
>

I included an overview of that in the cover letter 
(https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/); 
is it desirable to also have that duplicated in the individual patches 
in the series?


Zev
Zev



From mathieu.poirier at linaro.org  Wed Apr  7 17:59:43 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 10:59:43 -0600
Subject: [PATCH V2 3/4] remoteproc: imx: move memory parsing to rproc_ops
In-Reply-To: <1617082235-15923-4-git-send-email-peng.fan@oss.nxp.com>
References: <1617082235-15923-1-git-send-email-peng.fan@oss.nxp.com>
 <1617082235-15923-4-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210407165943.GE418374@xps15>

On Tue, Mar 30, 2021 at 01:30:34PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Use the rproc_ops::prepare() hook for doing memory resources
> reallocation when reattach an remote procesor.

s/when reattach an remote/when reattaching a remote/

> 
> Suggested-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index b05aae0ad7a2..7cd09971d1a4 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -317,7 +317,7 @@ static int imx_rproc_mem_release(struct rproc *rproc,
>  	return 0;
>  }
>  
> -static int imx_rproc_parse_memory_regions(struct rproc *rproc)
> +static int imx_rproc_prepare(struct rproc *rproc)
>  {
>  	struct imx_rproc *priv = rproc->priv;
>  	struct device_node *np = priv->dev->of_node;
> @@ -363,10 +363,7 @@ static int imx_rproc_parse_memory_regions(struct rproc *rproc)
>  
>  static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
>  {
> -	int ret = imx_rproc_parse_memory_regions(rproc);
> -
> -	if (ret)
> -		return ret;
> +	int ret;
>  
>  	ret = rproc_elf_load_rsc_table(rproc, fw);
>  	if (ret)
> @@ -399,6 +396,7 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>  }
>  
>  static const struct rproc_ops imx_rproc_ops = {
> +	.prepare	= imx_rproc_prepare,
>  	.start		= imx_rproc_start,
>  	.stop		= imx_rproc_stop,
>  	.kick		= imx_rproc_kick,
> -- 
> 2.30.0
> 


From vee.khee.wong at linux.intel.com  Wed Apr  7 18:04:42 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Thu,  8 Apr 2021 01:04:42 +0800
Subject: [PATCH net-next v2 1/1] net: stmmac: Add support for external trigger
 timestamping
Message-ID: <20210407170442.1641-1-vee.khee.wong@linux.intel.com>

From: Tan Tee Min <tee.min.tan at intel.com>

The Synopsis MAC controller supports auxiliary snapshot feature that
allows user to store a snapshot of the system time based on an external
event.

This patch add supports to the above mentioned feature. Users will be
able to triggered capturing the time snapshot from user-space using
application such as testptp or any other applications that uses the
PTP_EXTTS_REQUEST ioctl request.

Cc: Richard Cochran <richardcochran at gmail.com>
Signed-off-by: Tan Tee Min <tee.min.tan at intel.com>
Co-developed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
v1 -> v2:
Changed from pr_info() to netdev_dbg().

 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 11 +++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  5 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  3 ++
 .../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 40 +++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 +
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  | 39 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  1 +
 include/linux/stmmac.h                        |  2 +
 8 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 8ba87c0be976..aee3e0b5fb46 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -286,6 +286,13 @@ static int intel_crosststamp(ktime_t *device,
 
 	intel_priv = priv->plat->bsp_priv;
 
+	/* Both internal crosstimestamping and external triggered event
+	 * timestamping cannot be run concurrently.
+	 */
+	if (priv->plat->ext_snapshot_en)
+		return -EBUSY;
+
+	mutex_lock(&priv->aux_ts_lock);
 	/* Enable Internal snapshot trigger */
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value &= ~PTP_ACR_MASK;
@@ -311,6 +318,7 @@ static int intel_crosststamp(ktime_t *device,
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value |= PTP_ACR_ATSFC;
 	writel(acr_value, ptpaddr + PTP_ACR);
+	mutex_unlock(&priv->aux_ts_lock);
 
 	/* Trigger Internal snapshot signal
 	 * Create a rising edge by just toggle the GPO1 to low
@@ -345,6 +353,8 @@ static int intel_crosststamp(ktime_t *device,
 		*system = convert_art_to_tsc(art_time);
 	}
 
+	/* Release the mutex */
+	mutex_unlock(&priv->aux_ts_lock);
 	system->cycles *= intel_priv->crossts_adj;
 
 	return 0;
@@ -510,6 +520,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
 
 	plat->int_snapshot_num = AUX_SNAPSHOT1;
+	plat->ext_snapshot_num = AUX_SNAPSHOT0;
 
 	plat->has_crossts = true;
 	plat->crosststamp = intel_crosststamp;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2b5022ef1e52..2cc91759b91f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -504,6 +504,8 @@ struct stmmac_ops {
 #define stmmac_fpe_irq_status(__priv, __args...) \
 	stmmac_do_callback(__priv, mac, fpe_irq_status, __args)
 
+struct stmmac_priv;
+
 /* PTP and HW Timer helpers */
 struct stmmac_hwtimestamp {
 	void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
@@ -515,6 +517,7 @@ struct stmmac_hwtimestamp {
 			       int add_sub, int gmac4);
 	void (*get_systime) (void __iomem *ioaddr, u64 *systime);
 	void (*get_ptptime)(void __iomem *ioaddr, u64 *ptp_time);
+	void (*timestamp_interrupt)(struct stmmac_priv *priv);
 };
 
 #define stmmac_config_hw_tstamping(__priv, __args...) \
@@ -531,6 +534,8 @@ struct stmmac_hwtimestamp {
 	stmmac_do_void_callback(__priv, ptp, get_systime, __args)
 #define stmmac_get_ptptime(__priv, __args...) \
 	stmmac_do_void_callback(__priv, ptp, get_ptptime, __args)
+#define stmmac_timestamp_interrupt(__priv, __args...) \
+	stmmac_do_void_callback(__priv, ptp, timestamp_interrupt, __args)
 
 /* Helpers to manage the descriptors for chain and ring modes */
 struct stmmac_mode_ops {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..abadcd8cdc41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -239,6 +239,9 @@ struct stmmac_priv {
 	int use_riwt;
 	int irq_wake;
 	spinlock_t ptp_lock;
+	/* Mutex lock for Auxiliary Snapshots */
+	struct mutex aux_ts_lock;
+
 	void __iomem *mmcaddr;
 	void __iomem *ptpaddr;
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 113c51bcc0b5..ec7ec926f27c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -12,8 +12,11 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/delay.h>
+#include <linux/ptp_clock_kernel.h>
 #include "common.h"
 #include "stmmac_ptp.h"
+#include "dwmac4.h"
+#include "stmmac.h"
 
 static void config_hw_tstamping(void __iomem *ioaddr, u32 data)
 {
@@ -163,6 +166,42 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
 	*ptp_time = ns;
 }
 
+static void timestamp_interrupt(struct stmmac_priv *priv)
+{
+	struct ptp_clock_event event;
+	unsigned long flags;
+	u32 num_snapshot;
+	u32 ts_status;
+	u32 tsync_int;
+	u64 ptp_time;
+	int i;
+
+	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
+
+	if (!tsync_int)
+		return;
+
+	/* Read timestamp status to clear interrupt from either external
+	 * timestamp or start/end of PPS.
+	 */
+	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
+
+	if (priv->plat->ext_snapshot_en) {
+		num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
+			       GMAC_TIMESTAMP_ATSNS_SHIFT;
+
+		for (i = 0; i < num_snapshot; i++) {
+			spin_lock_irqsave(&priv->ptp_lock, flags);
+			get_ptptime(priv->ptpaddr, &ptp_time);
+			spin_unlock_irqrestore(&priv->ptp_lock, flags);
+			event.type = PTP_CLOCK_EXTTS;
+			event.index = 0;
+			event.timestamp = ptp_time;
+			ptp_clock_event(priv->ptp_clock, &event);
+		}
+	}
+}
+
 const struct stmmac_hwtimestamp stmmac_ptp = {
 	.config_hw_tstamping = config_hw_tstamping,
 	.init_systime = init_systime,
@@ -171,4 +210,5 @@ const struct stmmac_hwtimestamp stmmac_ptp = {
 	.adjust_systime = adjust_systime,
 	.get_systime = get_systime,
 	.get_ptptime = get_ptptime,
+	.timestamp_interrupt = timestamp_interrupt,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 77285646c5fc..9e57bc3d00a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4989,6 +4989,8 @@ static void stmmac_common_interrupt(struct stmmac_priv *priv)
 			else
 				netif_carrier_off(priv->dev);
 		}
+
+		stmmac_timestamp_interrupt(priv, priv);
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index b164ae22e35f..d668c33a0746 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -135,9 +135,13 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 {
 	struct stmmac_priv *priv =
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
+	void __iomem *ptpaddr = priv->ptpaddr;
+	void __iomem *ioaddr = priv->hw->pcsr;
 	struct stmmac_pps_cfg *cfg;
 	int ret = -EOPNOTSUPP;
 	unsigned long flags;
+	u32 intr_value;
+	u32 acr_value;
 
 	switch (rq->type) {
 	case PTP_CLK_REQ_PEROUT:
@@ -159,6 +163,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 					     priv->systime_flags);
 		spin_unlock_irqrestore(&priv->ptp_lock, flags);
 		break;
+	case PTP_CLK_REQ_EXTTS:
+		priv->plat->ext_snapshot_en = on;
+		mutex_lock(&priv->aux_ts_lock);
+		acr_value = readl(ptpaddr + PTP_ACR);
+		acr_value &= ~PTP_ACR_MASK;
+		if (on) {
+			/* Enable External snapshot trigger */
+			acr_value |= priv->plat->ext_snapshot_num;
+			acr_value |= PTP_ACR_ATSFC;
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d enabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Enable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value |= GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+
+		} else {
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d disabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Disable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value &= ~GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+		}
+		writel(acr_value, ptpaddr + PTP_ACR);
+		mutex_unlock(&priv->aux_ts_lock);
+		ret = 0;
+		break;
+
 	default:
 		break;
 	}
@@ -202,7 +237,7 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
 	.name = "stmmac ptp",
 	.max_adj = 62500000,
 	.n_alarm = 0,
-	.n_ext_ts = 0,
+	.n_ext_ts = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_per_out = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_pins = 0,
 	.pps = 0,
@@ -237,8 +272,10 @@ void stmmac_ptp_register(struct stmmac_priv *priv)
 		stmmac_ptp_clock_ops.max_adj = priv->plat->ptp_max_adj;
 
 	stmmac_ptp_clock_ops.n_per_out = priv->dma_cap.pps_out_num;
+	stmmac_ptp_clock_ops.n_ext_ts = priv->dma_cap.aux_snapshot_n;
 
 	spin_lock_init(&priv->ptp_lock);
+	mutex_init(&priv->aux_ts_lock);
 	priv->ptp_clock_ops = stmmac_ptp_clock_ops;
 
 	priv->ptp_clock = ptp_clock_register(&priv->ptp_clock_ops,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index f88727ce4d30..53172a439810 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -73,6 +73,7 @@
 #define	PTP_ACR_ATSEN1		BIT(5)	/* Auxiliary Snapshot 1 Enable */
 #define	PTP_ACR_ATSEN2		BIT(6)	/* Auxiliary Snapshot 2 Enable */
 #define	PTP_ACR_ATSEN3		BIT(7)	/* Auxiliary Snapshot 3 Enable */
+#define	PTP_ACR_ATSEN_SHIFT	5	/* Auxiliary Snapshot shift */
 #define	PTP_ACR_MASK		GENMASK(7, 4)	/* Aux Snapshot Mask */
 #define	PMC_ART_VALUE0		0x01	/* PMC_ART[15:0] timer value */
 #define	PMC_ART_VALUE1		0x02	/* PMC_ART[31:16] timer value */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..97edb31d6310 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -238,6 +238,8 @@ struct plat_stmmacenet_data {
 	struct pci_dev *pdev;
 	bool has_crossts;
 	int int_snapshot_num;
+	int ext_snapshot_num;
+	bool ext_snapshot_en;
 	bool multi_msi_en;
 	int msi_mac_vec;
 	int msi_wol_vec;
-- 
2.25.1



From zackr at vmware.com  Wed Apr  7 18:00:36 2021
From: zackr at vmware.com (Zack Rusin)
Date: Wed, 7 Apr 2021 13:00:36 -0400
Subject: [PATCH] arm64/mm: Fix mapping_dirty_helpers with arm64
In-Reply-To: <20210402112657.GB29774@arm.com>
References: <20210331182344.47987-1-zackr@vmware.com>
 <20210402112657.GB29774@arm.com>
Message-ID: <a44e78dc-0761-cdf4-fbf9-f2395b40aa55@vmware.com>

On 4/2/21 7:26 AM, Catalin Marinas wrote:
> On Wed, Mar 31, 2021 at 02:23:44PM -0400, Zack Rusin wrote:
>> The pagetable walk callbacks in mm/mapping_dirty_helpers.c depend
>> on a set of helpers from which pud_dirty(pud) was missing. I'm
>> assuming mapping_dirty_helpers weren't used on ARM64 before
>> because the missing pud_dirty is causing a compilation error.
>>
>> The drivers/gpu/drm/vmwgfx code uses mapping_dirty_helpers and
>> has been ported to ARM64 but it depends on this code getting in
>> first in order to compile/work.
>>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: Peter Zijlstra <peterz at infradead.org>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Zack Rusin <zackr at vmware.com>
>> ---
>>   arch/arm64/include/asm/pgtable.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 47027796c2f9..ecd80f87a996 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -451,6 +451,7 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
>>   #define pfn_pmd(pfn,prot)	__pmd(__phys_to_pmd_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
>>   #define mk_pmd(page,prot)	pfn_pmd(page_to_pfn(page),prot)
>>   
>> +#define pud_dirty(pud)		pte_dirty(pud_pte(pud))
>>   #define pud_young(pud)		pte_young(pud_pte(pud))
>>   #define pud_mkyoung(pud)	pte_pud(pte_mkyoung(pud_pte(pud)))
>>   #define pud_write(pud)		pte_write(pud_pte(pud))
> 
> I think pud_dirty() should only be defined if
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD which is not the case on
> arm64. Well, the pud_young/mkyoung/write should probably also be removed
> until we have pud pages on arm64.

Agreed. I got confused by pud_young and co being defined here even 
though they're all shielded by CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD 
when they're used and incorrectly assumed the practice was to define 
them for arm64 here whether CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD 
was defined or not.

I'll go ahead and shield the pud_dirty with 
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD in mapping_dirty_helpers.c 
instead.

z


From eugen.hristev at microchip.com  Wed Apr  7 18:00:51 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Wed, 7 Apr 2021 20:00:51 +0300
Subject: [PATCH 1/3] ARM: at91: add new SoC sama7g5
Message-ID: <20210407170053.298056-1-eugen.hristev@microchip.com>

Add new SoC from at91 family : sama7g5

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 arch/arm/mach-at91/Kconfig | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ccd7e80ce943..5eb2a9206f42 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -57,6 +57,13 @@ config SOC_SAMA5D4
 	help
 	  Select this if you are using one of Microchip's SAMA5D4 family SoC.
 
+config SOC_SAMA7G5
+	bool "SAMA7G5 family"
+	depends on ARCH_MULTI_V7
+	select SOC_SAMA7
+	help
+	  Select this if you are using one of Microchip's SAMA7G5 family SoC.
+
 config SOC_AT91RM9200
 	bool "AT91RM9200"
 	depends on ARCH_MULTI_V4T
@@ -191,4 +198,9 @@ config SOC_SAMA5
 config ATMEL_PM
 	bool
 
+config SOC_SAMA7
+	bool
+	select ARM_GIC
+	select MEMORY
+	select SOC_SAM_V7
 endif
-- 
2.25.1



From eugen.hristev at microchip.com  Wed Apr  7 18:00:52 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Wed, 7 Apr 2021 20:00:52 +0300
Subject: [PATCH 2/3] ARM: at91: debug: add sama7g5 low level debug uart
In-Reply-To: <20210407170053.298056-1-eugen.hristev@microchip.com>
References: <20210407170053.298056-1-eugen.hristev@microchip.com>
Message-ID: <20210407170053.298056-2-eugen.hristev@microchip.com>

Add sama7g5 SoC debug uart on Flexcom3. This is the UART that the
ROM bootloader uses.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 arch/arm/Kconfig.debug | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9e0b5e7f12af..7598624ce6dd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -191,6 +191,14 @@ choice
 		  their output to the USART1 port on SAMV7 based
 		  machines.
 
+	config DEBUG_AT91_SAMA7G5_FLEXCOM3
+		bool "Kernel low-level debugging on SAMA7G5 FLEXCOM3"
+		select DEBUG_AT91_UART
+		depends on SOC_SAMA7G5
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on the FLEXCOM3 port of SAMA7G5.
+
 	config DEBUG_BCM2835
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835 && ARCH_MULTI_V6
@@ -1657,6 +1665,7 @@ config DEBUG_UART_PHYS
 	default 0xd4017000 if DEBUG_MMP_UART2
 	default 0xd4018000 if DEBUG_MMP_UART3
 	default 0xe0000000 if DEBUG_SPEAR13XX
+	default 0xe1824200 if DEBUG_AT91_SAMA7G5_FLEXCOM3
 	default 0xe4007000 if DEBUG_HIP04_UART
 	default 0xe6c40000 if DEBUG_RMOBILE_SCIFA0
 	default 0xe6c50000 if DEBUG_RMOBILE_SCIFA1
@@ -1718,6 +1727,7 @@ config DEBUG_UART_VIRT
 	default 0xc8821000 if DEBUG_RV1108_UART1
 	default 0xc8912000 if DEBUG_RV1108_UART0
 	default 0xe0010fe0 if ARCH_RPC
+	default 0xe0824200 if DEBUG_AT91_SAMA7G5_FLEXCOM3
 	default 0xf0010000 if DEBUG_ASM9260_UART
 	default 0xf0100000 if DEBUG_DIGICOLOR_UA0
 	default 0xf01fb000 if DEBUG_NOMADIK_UART
-- 
2.25.1



From eugen.hristev at microchip.com  Wed Apr  7 18:00:53 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Wed, 7 Apr 2021 20:00:53 +0300
Subject: [PATCH 3/3] ARM: at91: Kconfig: select PLL,
 generic clock and utmi support
In-Reply-To: <20210407170053.298056-1-eugen.hristev@microchip.com>
References: <20210407170053.298056-1-eugen.hristev@microchip.com>
Message-ID: <20210407170053.298056-3-eugen.hristev@microchip.com>

From: Claudiu Beznea <claudiu.beznea at microchip.com>

Select PLL, generic clock and UTMI support for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 arch/arm/mach-at91/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 5eb2a9206f42..f52b46bccd85 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -60,6 +60,9 @@ config SOC_SAMA5D4
 config SOC_SAMA7G5
 	bool "SAMA7G5 family"
 	depends on ARCH_MULTI_V7
+	select HAVE_AT91_GENERATED_CLK
+	select HAVE_AT91_SAM9X60_PLL
+	select HAVE_AT91_UTMI
 	select SOC_SAMA7
 	help
 	  Select this if you are using one of Microchip's SAMA7G5 family SoC.
-- 
2.25.1



From mathieu.poirier at linaro.org  Wed Apr  7 18:03:14 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 7 Apr 2021 11:03:14 -0600
Subject: [PATCH V2 4/4] remoteproc: imx_rproc: support remote cores
 booted before Linux Kernel
In-Reply-To: <1617082235-15923-5-git-send-email-peng.fan@oss.nxp.com>
References: <1617082235-15923-1-git-send-email-peng.fan@oss.nxp.com>
 <1617082235-15923-5-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210407170314.GF418374@xps15>

On Tue, Mar 30, 2021 at 01:30:35PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
>  - Add rsc_table to hold the resource table published by remote cores.
>  - Add attach hook.
>  - Add imx_rproc_get_loaded_rsc_table to get resource table published by
>    remote processors.
>  - Add imx_rproc_detect_mode to detect remote cores' working mode.
>

This is describing _what_ is being done rather than _why_ it is done.

Moreover for patches 1 an 3 the subject line is tagged with "imx" while patches
2 and 4 have "imx_rproc".  I don't mind which one is used as long as it is
consistent.
 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 45 ++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 7cd09971d1a4..d6338872c6db 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -95,6 +95,7 @@ struct imx_rproc {
>  	struct mbox_chan		*rx_ch;
>  	struct work_struct		rproc_work;
>  	struct workqueue_struct		*workqueue;
> +	void __iomem			*rsc_table;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> @@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>  			__func__, vqid, err);
>  }
>  
> +static int imx_rproc_attach(struct rproc *rproc)
> +{
> +	return 0;
> +}
> +
> +static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
> +{
> +	struct imx_rproc *priv = rproc->priv;
> +
> +	/* The resource table has already been mapped in imx_rproc_addr_init */
> +	if (!priv->rsc_table)
> +		return NULL;
> +
> +	*table_sz = SZ_1K;
> +	return (struct resource_table *)priv->rsc_table;
> +}
> +
>  static const struct rproc_ops imx_rproc_ops = {
>  	.prepare	= imx_rproc_prepare,
> +	.attach		= imx_rproc_attach,
>  	.start		= imx_rproc_start,
>  	.stop		= imx_rproc_stop,
>  	.kick		= imx_rproc_kick,
> @@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
>  	.load		= rproc_elf_load_segments,
>  	.parse_fw	= imx_rproc_parse_fw,
>  	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> +	.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
>  	.sanity_check	= rproc_elf_sanity_check,
>  	.get_boot_addr	= rproc_elf_get_boot_addr,
>  };
> @@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>  		}
>  		priv->mem[b].sys_addr = res.start;
>  		priv->mem[b].size = resource_size(&res);
> +		if (!strcmp(node->name, "rsc_table"))
> +			priv->rsc_table = priv->mem[b].cpu_addr;
>  		b++;
>  	}
>  
> @@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
>  	mbox_free_channel(priv->rx_ch);
>  }
>  
> +static int imx_rproc_detect_mode(struct imx_rproc *priv)
> +{
> +	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> +	struct device *dev = priv->dev;
> +	int ret;
> +	u32 val;
> +
> +	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
> +	if (ret) {
> +		dev_err(dev, "Failed to read src\n");
> +		return ret;
> +	}
> +
> +	if (!(val & dcfg->src_stop))
> +		priv->rproc->state = RPROC_DETACHED;
> +
> +	return 0;
> +}
> +
>  static int imx_rproc_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  		goto err_put_mbox;
>  	}
>  
> +	ret = imx_rproc_detect_mode(priv);
> +	if (ret)
> +		goto err_put_mbox;
> +

With the above:

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  	priv->clk = devm_clk_get(dev, NULL);
>  	if (IS_ERR(priv->clk)) {
>  		dev_err(dev, "Failed to get clock\n");
> -- 
> 2.30.0
> 


From alexandre.belloni at bootlin.com  Wed Apr  7 18:13:23 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Wed, 7 Apr 2021 19:13:23 +0200
Subject: [PATCH 3/3] ARM: at91: Kconfig: select PLL, generic clock and
 utmi support
In-Reply-To: <20210407170053.298056-3-eugen.hristev@microchip.com>
References: <20210407170053.298056-1-eugen.hristev@microchip.com>
 <20210407170053.298056-3-eugen.hristev@microchip.com>
Message-ID: <YG3oM6DhTwKfPrAG@piout.net>

Hi,

On 07/04/2021 20:00:53+0300, Eugen Hristev wrote:
> From: Claudiu Beznea <claudiu.beznea at microchip.com>
> 
> Select PLL, generic clock and UTMI support for SAMA7G5.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  arch/arm/mach-at91/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 5eb2a9206f42..f52b46bccd85 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -60,6 +60,9 @@ config SOC_SAMA5D4
>  config SOC_SAMA7G5
>  	bool "SAMA7G5 family"
>  	depends on ARCH_MULTI_V7
> +	select HAVE_AT91_GENERATED_CLK
> +	select HAVE_AT91_SAM9X60_PLL
> +	select HAVE_AT91_UTMI

Shouldn't that be squashed in 1/3?

>  	select SOC_SAMA7
>  	help
>  	  Select this if you are using one of Microchip's SAMA7G5 family SoC.
> -- 
> 2.25.1
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From gregkh at linuxfoundation.org  Wed Apr  7 18:25:09 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 7 Apr 2021 19:25:09 +0200
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate
 aspeed,sirq-polarity-sense
In-Reply-To: <YG3kJC+6gLC6RzzQ@hatter.bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
 <20210402182724.20848-2-zev@bewilderbeest.net>
 <YG3NR4bGRjIGZhgx@kroah.com>
 <YG3kJC+6gLC6RzzQ@hatter.bewilderbeest.net>
Message-ID: <YG3q9brKTC4pkQbs@kroah.com>

On Wed, Apr 07, 2021 at 11:56:04AM -0500, Zev Weiss wrote:
> On Wed, Apr 07, 2021 at 10:18:31AM CDT, Greg Kroah-Hartman wrote:
> > On Fri, Apr 02, 2021 at 01:27:21PM -0500, Zev Weiss wrote:
> > > This property ties SIRQ polarity to SCU register bits that don't
> > > necessarily have any direct relationship to it; the only use of it
> > > was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.
> > 
> > Please write that as:
> > 	c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq polarity")
> > 
> 
> Ack, will do.
> 
> > > Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> > > Reviewed-by: Joel Stanley <joel at jms.id.au>
> > > ---
> > >  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
> > >  1 file changed, 1 insertion(+)
> > 
> > What changed from previous versions?  That always goes below the ---
> > line.
> > 
> 
> I included an overview of that in the cover letter (https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/);
> is it desirable to also have that duplicated in the individual patches in
> the series?

Any reason why you didn't include all of the relevant people and mailing
lists in that cover letter?  I've never seen it before :)

But yes, if you do send it to the right group, putting it in 00/XX is
fine.

thanks,

greg k-h


From rppt at kernel.org  Wed Apr  7 18:26:04 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed,  7 Apr 2021 20:26:04 +0300
Subject: [RFC/RFT PATCH 0/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
Message-ID: <20210407172607.8812-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1. 

The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.

With this the core mm will be able to cope with the fact that it cannot use
NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
will be treated correctly even without the need for pfn_valid_within.

The patches are only boot tested on qemu-system-aarch64 so I'd really
appreciate memory stress tests on real hardware.

If this actually works we'll be one step closer to drop custom pfn_valid()
on arm64 altogether.

Mike Rapoport (3):
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is normal memory from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 10 ++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 mm/memblock.c                   | 23 +++++++++++++++++++++--
 8 files changed, 35 insertions(+), 12 deletions(-)


base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.28.0



From rppt at kernel.org  Wed Apr  7 18:26:05 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed,  7 Apr 2021 20:26:05 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
In-Reply-To: <20210407172607.8812-1-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
Message-ID: <20210407172607.8812-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.

The struct pages for MEMBLOCK_NOMAP regions are kept with the default
values set by the memory map initialization which makes it necessary to
have a special treatment for such pages in pfn_valid() and
pfn_valid_within().

Split out initialization of the reserved pages to a function with a
meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
reserved regions and mark struct pages for the NOMAP regions as
PageReserved.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 mm/memblock.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..6b7ea9d86310 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	return end_pfn - start_pfn;
 }
 
+static void __init memmap_init_reserved_pages(void)
+{
+	struct memblock_region *region;
+	phys_addr_t start, end;
+	u64 i;
+
+	/* initialize struct pages for the reserved regions */
+	for_each_reserved_mem_range(i, &start, &end)
+		reserve_bootmem_region(start, end);
+
+	/* and also treat struct pages for the NOMAP regions as PageReserved */
+	for_each_mem_region(region) {
+		if (memblock_is_nomap(region)) {
+			start = region->base;
+			end = start + region->size;
+			reserve_bootmem_region(start, end);
+		}
+	}
+}
+
 static unsigned long __init free_low_memory_core_early(void)
 {
 	unsigned long count = 0;
@@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memblock_clear_hotplug(0, -1);
 
-	for_each_reserved_mem_range(i, &start, &end)
-		reserve_bootmem_region(start, end);
+	memmap_init_reserved_pages();
 
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
-- 
2.28.0



From rppt at kernel.org  Wed Apr  7 18:26:06 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed,  7 Apr 2021 20:26:06 +0300
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <20210407172607.8812-1-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
Message-ID: <20210407172607.8812-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.

Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.

Introduce a dedicated pfn_is_memory() to perform such check and use it
where appropriate.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/include/asm/memory.h | 2 +-
 arch/arm64/include/asm/page.h   | 1 +
 arch/arm64/kvm/mmu.c            | 2 +-
 arch/arm64/mm/init.c            | 6 ++++++
 arch/arm64/mm/ioremap.c         | 4 ++--
 arch/arm64/mm/mmu.c             | 2 +-
 6 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..7e77fdf71b9d 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
-	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
+	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
 })
 
 void dump_mem_limit(void);
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..32b485bcc6ff 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
 typedef struct page *pgtable_t;
 
 extern int pfn_valid(unsigned long);
+extern int pfn_is_memory(unsigned long);
 
 #include <asm/memory.h>
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..ad2ea65a3937 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 
 static bool kvm_is_device_pfn(unsigned long pfn)
 {
-	return !pfn_valid(pfn);
+	return !pfn_is_memory(pfn);
 }
 
 /*
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..258b1905ed4a 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
 }
 EXPORT_SYMBOL(pfn_valid);
 
+int pfn_is_memory(unsigned long pfn)
+{
+	return memblock_is_map_memory(PFN_PHYS(pfn));
+}
+EXPORT_SYMBOL(pfn_is_memory);
+
 static phys_addr_t memory_limit = PHYS_ADDR_MAX;
 
 /*
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b5e83c46b23e..82a369b22ef5 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
 	/*
 	 * Don't allow RAM to be mapped.
 	 */
-	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+	if (WARN_ON(pfn_is_memory(__phys_to_pfn(phys_addr))))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
 void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
 {
 	/* For normal memory we already have a cacheable mapping. */
-	if (pfn_valid(__phys_to_pfn(phys_addr)))
+	if (pfn_is_memory(__phys_to_pfn(phys_addr)))
 		return (void __iomem *)__phys_to_virt(phys_addr);
 
 	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..038d20fe163f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
-	if (!pfn_valid(pfn))
+	if (!pfn_is_memory(pfn))
 		return pgprot_noncached(vma_prot);
 	else if (file->f_flags & O_SYNC)
 		return pgprot_writecombine(vma_prot);
-- 
2.28.0



From rppt at kernel.org  Wed Apr  7 18:26:07 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed,  7 Apr 2021 20:26:07 +0300
Subject: [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210407172607.8812-1-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
Message-ID: <20210407172607.8812-4-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The arm64's version of pfn_valid() differs from the generic because of two
reasons:

* Parts of the memory map are freed during boot. This makes it necessary to
  verify that there is actual physical memory that corresponds to a pfn
  which is done by querying memblock.

* There are NOMAP memory regions. These regions are not mapped in the
  linear map and until the previous commit the struct pages representing
  these areas had default values.

As the consequence of absence of the special treatment of NOMAP regions in
the memory map it was necessary to use memblock_is_map_memory() in
pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
generic mm functionality would not treat a NOMAP page as a normal page.

Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
the rest of core mm will treat them as unusable memory and thus
pfn_valid_within() is no longer required at all and can be disabled by
removing CONFIG_HOLES_IN_ZONE on arm64.

pfn_valid() can be slightly simplified by replacing
memblock_is_map_memory() with memblock_is_memory().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/Kconfig   | 3 ---
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..58e439046d05 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA
 
-config HOLES_IN_ZONE
-	def_bool y
-
 source "kernel/Kconfig.hz"
 
 config ARCH_SPARSEMEM_ENABLE
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 258b1905ed4a..bb6dd406b1f0 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
 
 	/*
 	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_map_memory() check for ZONE_DEVICE based
+	 * memblock_is_memory() check for ZONE_DEVICE based
 	 * addresses will always fail. Even the normal hotplugged
 	 * memory will never have MEMBLOCK_NOMAP flag set in their
 	 * memblock entries. Skip memblock search for all non early
@@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
 		return pfn_section_valid(ms, pfn);
 }
 #endif
-	return memblock_is_map_memory(addr);
+	return memblock_is_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
 
-- 
2.28.0



From zev at bewilderbeest.net  Wed Apr  7 18:55:29 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed, 7 Apr 2021 12:55:29 -0500
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate
 aspeed,sirq-polarity-sense
In-Reply-To: <YG3q9brKTC4pkQbs@kroah.com>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
 <20210402182724.20848-2-zev@bewilderbeest.net>
 <YG3NR4bGRjIGZhgx@kroah.com>
 <YG3kJC+6gLC6RzzQ@hatter.bewilderbeest.net>
 <YG3q9brKTC4pkQbs@kroah.com>
Message-ID: <YG3yEeIRKgTjnDxz@hatter.bewilderbeest.net>

On Wed, Apr 07, 2021 at 12:25:09PM CDT, Greg Kroah-Hartman wrote:
>On Wed, Apr 07, 2021 at 11:56:04AM -0500, Zev Weiss wrote:
>> On Wed, Apr 07, 2021 at 10:18:31AM CDT, Greg Kroah-Hartman wrote:
>> > On Fri, Apr 02, 2021 at 01:27:21PM -0500, Zev Weiss wrote:
>> > > This property ties SIRQ polarity to SCU register bits that don't
>> > > necessarily have any direct relationship to it; the only use of it
>> > > was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.
>> >
>> > Please write that as:
>> > 	c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq polarity")
>> >
>>
>> Ack, will do.
>>
>> > > Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> > > Reviewed-by: Joel Stanley <joel at jms.id.au>
>> > > ---
>> > >  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
>> > >  1 file changed, 1 insertion(+)
>> >
>> > What changed from previous versions?  That always goes below the ---
>> > line.
>> >
>>
>> I included an overview of that in the cover letter (https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/);
>> is it desirable to also have that duplicated in the individual patches in
>> the series?
>
>Any reason why you didn't include all of the relevant people and mailing
>lists in that cover letter?  I've never seen it before :)
>

Ah -- is there a good rule of thumb (or git send-email trick) for that?  
Set-union of get_maintainer.pl over all the patches in the series?  


Zev



From arnd at arndb.de  Wed Apr  7 18:55:17 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 Apr 2021 19:55:17 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
In-Reply-To: <01c82108-64a8-33ee-3984-5bd7056a0002@gmail.com>
References: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
 <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>
 <01c82108-64a8-33ee-3984-5bd7056a0002@gmail.com>
Message-ID: <CAK8P3a37BUdHneO+9+t0Pan3UWZHub-ishcKLNxCbqO0kk0CNw@mail.gmail.com>

On Wed, Apr 7, 2021 at 6:34 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> On 07/04/2021 18:06, Arnd Bergmann wrote:
> > On Wed, Apr 7, 2021 at 1:00 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> >>
> >> Hi Olof and Arnd,
> >>
> >> Here comes the second round of arm64 DT patches. Hope I'm not too late.
> >> Basically we add several node to MT8167.
> >> ----------------------------------------------------------------
> >> Fabien Parent (6):
> >
> >>       arm64: dts: mediatek: mt8167: add some DRM nodes
> >
> > I stumbled over this patch adding a lot of aliases:
> >
> > +       aliases {
> > +               aal0 = &aal;
> > +               ccorr0 = &ccorr;
> > +               color0 = &color;
> > +               dither0 = &dither;
> > +               dsi0 = &dsi;
> > +               ovl0 = &ovl0;
> > +               pwm0 = &disp_pwm;
> > +               rdma0 = &rdma0;
> > +               rdma1 = &rdma1;
> > +               wdma0 = &wdma;
> > +       };
> >
> >
> > Something doesn't quite feel right about this, and I checked with Rob,
> > who also thinks this looks wrong. I suppose we need to have a set of
> > well documented alias types rather than just having drivers make up
> > new ones on the spot.
>
> These are needed in the DRM driver, see drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>
> I added Chun-Kuang who is the maintainer of the driver. I think it's a good idea
> to have this alias described in the binding. Maybe a good excuse to move to yaml
> as well :)

The aliases certainly need to be described in the binding, I think someone
would likely have complained earlier if that was part of the binding.

Moving it to yaml is also a good idea, and required for any new devices.

> > I also noticed that some of the referenced nodes are missing a DT
> > binding file, so those need to be added and reviewed as well.
>
> I suppose you are talking about "mediatek,mt8173-vcodec-enc-vp8". The binding
> patches are in the media tree [1]. Maybe I supposed wrongly that they will land
> in v5.13? Or perhaps I should have mentioned that in the pull request.
>
> If it wasn't about this compatible and you can still remember, please let me
> know so that we can fix that :)
>
> I double checked and didn't find any missing binding. Some of them only have the
> fallback binding described, maybe that's what you are referring to.

Here is what I see for all compatible strings of the added device nodes in
this patch, as of linux-next-20210407:

$ for i in mediatek,mt8167-disp-mutex mediatek,mt8167-disp-rdma
mediatek,mt2701-disp-rdma mediatek,mt8167-disp-pwm
mediatek,mt8173-disp-pwn mediatek,mt8167-dsi mediatek,mt2701-dsi
mediatek,mt8167-mipi-tx mediatek,mt2701-mipi-tx
mediatek,mt8167-disp-ovl mediatek,mt8173-disp-ovl
mediatek,mt8167-disp-rdma mediatek,mt2701-disp-rdma
mediatek,mt8167-disp-color mediatek,mt8173-disp-color
mediatek,mt8167-disp-ccorr mediatek,mt8183-disp-ccorr
mediatek,mt8167-disp-aal mediatek,mt8167-disp-gamma
mediatek,mt8173-disp-gamma mediatek,mt8167-disp-dither
mediatek,mt8167-disp-wdma ; do echo === $i ;  git grep -wl $i
Documentation/devicetree/ ; done

=== mediatek,mt8167-disp-mutex
=== mediatek,mt8167-disp-rdma
=== mediatek,mt2701-disp-rdma
=== mediatek,mt8167-disp-pwm
Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
=== mediatek,mt8173-disp-pwn
=== mediatek,mt8167-dsi
=== mediatek,mt2701-dsi
=== mediatek,mt8167-mipi-tx
=== mediatek,mt2701-mipi-tx
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
=== mediatek,mt8167-disp-ovl
=== mediatek,mt8173-disp-ovl
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
=== mediatek,mt8167-disp-rdma
=== mediatek,mt2701-disp-rdma
=== mediatek,mt8167-disp-color
=== mediatek,mt8173-disp-color
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
=== mediatek,mt8167-disp-ccorr
=== mediatek,mt8183-disp-ccorr
=== mediatek,mt8167-disp-aal
=== mediatek,mt8167-disp-gamma
=== mediatek,mt8173-disp-gamma
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
=== mediatek,mt8167-disp-dither
=== mediatek,mt8167-disp-wdma

So five of the strings are documented, the others are missing. I did not check
the other patches in your branch.

         Arnd


From ndesaulniers at google.com  Wed Apr  7 19:07:26 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Wed, 7 Apr 2021 11:07:26 -0700
Subject: arm-linux-gnueabi-ld: warning: orphan section
 `__cpuidle_method_of_table'
 from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section
 `__cpuidle_method_of_table'
In-Reply-To: <202104071815.lq85YO6c-lkp@intel.com>
References: <202104071815.lq85YO6c-lkp@intel.com>
Message-ID: <CAKwvOdnrSorkpCCshZAav=1rczSTWa5Ji_Nhcd=vzmywAiCoNQ@mail.gmail.com>

On Wed, Apr 7, 2021 at 3:52 AM kernel test robot <lkp at intel.com> wrote:
>
> Hi Kees,
>
> FYI, the error/warning still remains.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   2d743660786ec51f5c1fefd5782bbdee7b227db0
> commit: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd arm/build: Warn on orphan section placement
> date:   7 months ago
> config: arm-randconfig-r033-20210407 (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a17850e251a55bba6d65aefbfeacfa9888cd2cd
>         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>         git fetch --no-tags linus master
>         git checkout 5a17850e251a55bba6d65aefbfeacfa9888cd2cd
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'

Looks like arch/arm/include/asm/cpuidle.h defines
`CPUIDLE_METHOD_OF_DECLARE` to create a static struct in such a
section.  Only arch/arm/mach-omap2/pm33xx-core.c uses that macro.

>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org



-- 
Thanks,
~Nick Desaulniers


From asutoshd at codeaurora.org  Wed Apr  7 19:08:09 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Wed,  7 Apr 2021 11:08:09 -0700
Subject: [PATCH v16 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1617818557.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing


Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  30 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 638 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 523 insertions(+), 243 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Wed Apr  7 19:08:10 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Wed,  7 Apr 2021 11:08:10 -0700
Subject: [PATCH v16 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1617818557.git.asutoshd@codeaurora.org>
References: <cover.1617818557.git.asutoshd@codeaurora.org>
Message-ID: <7be92c0bc3e5f07d5e17bd3b78c01496686ef31e.1617818557.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 638 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 506 insertions(+), 230 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..b9105e4 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..1e8d92b 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..49a918c 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..d463b44 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..cbb5a90 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			scsi_autopm_put_device(hba->sdev_ufs_device);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..08af302 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4099,11 +4113,11 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
 	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		scsi_autopm_put_device(hba->sdev_ufs_device);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4815,40 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+			return;
+		}
+	} else {
+		/* device wlun is probed */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4879,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4912,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5034,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5635,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 }
 
 /**
@@ -5604,7 +5653,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5669,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5793,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5835,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5856,14 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7287,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7450,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7930,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8516,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8692,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8700,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8723,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto enable_scaling;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8745,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8773,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8786,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8794,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8818,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
-
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8852,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,31 +8900,152 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
-	if (ufshcd_is_clkscaling_supported(hba))
-		ufshcd_clk_scaling_suspend(hba, false);
-
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
+	if (hba->clk_scaling.is_allowed)
+		ufshcd_resume_clkscaling(hba);
 
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	if (pm_runtime_suspended(dev))
+		return 0;
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	scsi_autopm_get_device(sdev);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static void ufshcd_suspend(struct ufs_hba *hba)
+{
+	hba->pm_op_in_progress = 1;
+
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
 	ufshcd_setup_clocks(hba, false);
 	if (ufshcd_is_clkgating_allowed(hba)) {
@@ -8948,6 +9053,43 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	hba->pm_op_in_progress = 0;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	hba->pm_op_in_progress = 1;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
@@ -8962,6 +9104,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8982,21 +9125,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	     !hba->dev_info.b_rpm_dev_flush_capable)
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
@@ -9018,25 +9147,20 @@ EXPORT_SYMBOL(ufshcd_system_suspend);
 
 int ufshcd_system_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_system_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
+
+	hba->is_sys_suspended = false;
 	up(&hba->host_sem);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
 
@@ -9045,23 +9169,23 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
+		ufshcd_suspend(hba);
 out:
-	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_suspend(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_suspend);
 
@@ -9069,37 +9193,25 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_resume);
 
@@ -9113,18 +9225,13 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
 	if (!hba->is_powered)
 		goto out;
 
@@ -9133,10 +9240,8 @@ int ufshcd_shutdown(struct ufs_hba *hba)
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9255,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9560,174 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	pm_runtime_put_noidle(&hba->sdev_ufs_device->sdev_gendev);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * Force it to honor system-suspend.
+	 */
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	/* Refer ufshcd_resume_complete() */
+	pm_runtime_get_noresume(&hba->sdev_ufs_device->sdev_gendev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		return ret;
+	}
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+		return ret;
+	}
 	return 0;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..40436e3 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From maz at kernel.org  Wed Apr  7 19:13:08 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed,  7 Apr 2021 19:13:08 +0100
Subject: [PATCH] KVM: arm64: Fully zero the vcpu state on reset
Message-ID: <20210407181308.2265808-1-maz@kernel.org>

On vcpu reset, we expect all the registers to be brought back
to their initial state, which happens to be a bunch of zeroes.

However, some recent commit broke this, and is now leaving a bunch
of registers (such as a FP state) with whatever was left by the
guest. My bad.

Just zero the whole vcpu context on reset. It is more than we
strictly need, but at least we won't miss anything. This also
zeroes the __hyp_running_vcpu pointer, which is always NULL
for a vcpu anyway.

Cc: stable at vger.kernel.org
Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only")
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/reset.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index bd354cd45d28..ef1c49a1a3ad 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -240,8 +240,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 		break;
 	}
 
-	/* Reset core registers */
-	memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+	/* Zero all registers */
+	memset(&vcpu->arch.ctxt, 0, sizeof(vcpu->arch.ctxt));
 	vcpu_gp_regs(vcpu)->pstate = pstate;
 
 	/* Reset system registers */
-- 
2.30.2



From wsa at the-dreams.de  Wed Apr  7 19:19:36 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Wed, 7 Apr 2021 20:19:36 +0200
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <1617797706.32076.1.camel@mhfsdcap03>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
 <20210406194856.GF3122@kunai> <1617797706.32076.1.camel@mhfsdcap03>
Message-ID: <20210407181936.GA1614@kunai>


> Due to clock stretch, our HW IP cannot meet the ac-timing
> spec(tSU;STA,tSU;STO). 
> There isn't a same delay for clock stretching, so we need pass a
> parameter which can be found through measurement to meet most
> conditions.

What about using this existing binding?

- i2c-scl-internal-delay-ns
        Number of nanoseconds the IP core additionally needs to setup SCL.

-------------- 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/20210407/5c5626f3/attachment.sig>

From arnd at arndb.de  Wed Apr  7 19:23:34 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 Apr 2021 20:23:34 +0200
Subject: arm-linux-gnueabi-ld: warning: orphan section
 `__cpuidle_method_of_table'
 from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section
 `__cpuidle_method_of_table'
In-Reply-To: <CAKwvOdnrSorkpCCshZAav=1rczSTWa5Ji_Nhcd=vzmywAiCoNQ@mail.gmail.com>
References: <202104071815.lq85YO6c-lkp@intel.com>
 <CAKwvOdnrSorkpCCshZAav=1rczSTWa5Ji_Nhcd=vzmywAiCoNQ@mail.gmail.com>
Message-ID: <CAK8P3a0NX4bpQUdHBhpo1s2PU465WjAOAPPzifeHuvFGi20NMw@mail.gmail.com>

On Wed, Apr 7, 2021 at 8:07 PM Nick Desaulniers <ndesaulniers at google.com> wrote:
>
> On Wed, Apr 7, 2021 at 3:52 AM kernel test robot <lkp at intel.com> wrote:
> >
> > Hi Kees,
> >
> > FYI, the error/warning still remains.
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head:   2d743660786ec51f5c1fefd5782bbdee7b227db0
> > commit: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd arm/build: Warn on orphan section placement
> > date:   7 months ago
> > config: arm-randconfig-r033-20210407 (attached as .config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> > reproduce (this is a W=1 build):
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> >         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >         git fetch --no-tags linus master
> >         git checkout 5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp at intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
>
> Looks like arch/arm/include/asm/cpuidle.h defines
> `CPUIDLE_METHOD_OF_DECLARE` to create a static struct in such a
> section.  Only arch/arm/mach-omap2/pm33xx-core.c uses that macro.

Nick, Kees,

Should I resend my patch, or are you taking care of it?

https://lore.kernel.org/lkml/20201230155506.1085689-1-arnd at kernel.org/T/#u

         Arnd


From pr-tracker-bot at kernel.org  Wed Apr  7 19:28:13 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Wed, 07 Apr 2021 18:28:13 +0000
Subject: [GIT PULL] ARM SoC fixes for v5.12, part 2
In-Reply-To: <CAK8P3a1QBvqNyReGC9UhYx-GOm3hYB1_xD22E0tmY7k_XqVUSg@mail.gmail.com>
References: <CAK8P3a1QBvqNyReGC9UhYx-GOm3hYB1_xD22E0tmY7k_XqVUSg@mail.gmail.com>
Message-ID: <161782009311.7121.7085895249015339168.pr-tracker-bot@kernel.org>

The pull request you sent on Wed, 7 Apr 2021 13:37:54 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-fixes-5.11-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3a22981230f997846d1cfeb8eadcda8bcc0f7ea8

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From ndesaulniers at google.com  Wed Apr  7 19:28:08 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Wed, 7 Apr 2021 11:28:08 -0700
Subject: arm-linux-gnueabi-ld: warning: orphan section
 `__cpuidle_method_of_table'
 from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section
 `__cpuidle_method_of_table'
In-Reply-To: <CAK8P3a0NX4bpQUdHBhpo1s2PU465WjAOAPPzifeHuvFGi20NMw@mail.gmail.com>
References: <202104071815.lq85YO6c-lkp@intel.com>
 <CAKwvOdnrSorkpCCshZAav=1rczSTWa5Ji_Nhcd=vzmywAiCoNQ@mail.gmail.com>
 <CAK8P3a0NX4bpQUdHBhpo1s2PU465WjAOAPPzifeHuvFGi20NMw@mail.gmail.com>
Message-ID: <CAKwvOdmcKrHqxkS540CZ=24irC5+o=EH_3RkTTQA-Uk9qh43YQ@mail.gmail.com>

On Wed, Apr 7, 2021 at 11:23 AM Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Wed, Apr 7, 2021 at 8:07 PM Nick Desaulniers <ndesaulniers at google.com> wrote:
> >
> > On Wed, Apr 7, 2021 at 3:52 AM kernel test robot <lkp at intel.com> wrote:
> > >
> > > Hi Kees,
> > >
> > > FYI, the error/warning still remains.
> > >
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head:   2d743660786ec51f5c1fefd5782bbdee7b227db0
> > > commit: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd arm/build: Warn on orphan section placement
> > > date:   7 months ago
> > > config: arm-randconfig-r033-20210407 (attached as .config)
> > > compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> > > reproduce (this is a W=1 build):
> > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > >         chmod +x ~/bin/make.cross
> > >         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> > >         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > >         git fetch --no-tags linus master
> > >         git checkout 5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> > >         # save the attached .config to linux build tree
> > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
> > >
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot <lkp at intel.com>
> > >
> > > All warnings (new ones prefixed by >>):
> > >
> > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> >
> > Looks like arch/arm/include/asm/cpuidle.h defines
> > `CPUIDLE_METHOD_OF_DECLARE` to create a static struct in such a
> > section.  Only arch/arm/mach-omap2/pm33xx-core.c uses that macro.
>
> Nick, Kees,
>
> Should I resend my patch, or are you taking care of it?
>
> https://lore.kernel.org/lkml/20201230155506.1085689-1-arnd at kernel.org/T/#u

Your patch looks like it has multiple reviewed-by tags, so it should
be ready to be submitted/merged? Waiting on anything else?
-- 
Thanks,
~Nick Desaulniers


From f.fainelli at gmail.com  Wed Apr  7 19:35:57 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 7 Apr 2021 11:35:57 -0700
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210407112713.GB5510@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
 <20210407112713.GB5510@sirena.org.uk>
Message-ID: <03852d1a-1ee4-fd29-8523-4673c35f83cd@gmail.com>



On 4/7/2021 4:27 AM, Mark Brown wrote:
> On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> 
>> I'm a little confused -- here is how I remember the chronology of the
>> "DT bindings" commit reviews, please correct me if I'm wrong:
> 
>> o JimQ submitted a pullreq for using voltage regulators in the same
>> style as the existing "rockport" PCIe driver.
>> o After some deliberation, RobH preferred that the voltage regulators
>> should go into the PCIe subnode device's DT node.
>> o JimQ put the voltage regulators in the subnode device's DT node.
>> o MarkB didn't like the fact that the code did a global search for the
>> regulator since it could not provide the owning struct device* handle.
>> o RobH relented, and said that if it is just two specific and standard
>> voltage regulators, perhaps they can go in the parent DT node after
>> all.
>> o JimQ put the regulators back in the PCIe node.
>> o MarkB now wants the regulators to go back into the child node again?
> 
> ...having pointed out a couple of times now that there's no physical
> requirement that the supplies be shared between slots never mind with
> the controller.  Also note that as I've said depending on what the
> actual requirements of the controller node are you might want to have
> the regulators in both places, and further note that the driver does not
> have to actively use everything in the binding document (although if
> it's not using something that turns out to be a requirement it's likely
> to run into hardware where that causes bugs at some point).
> 
> Frankly I'm not clear why you're trying to handle powering on PCI slots
> in a specific driver, surely PCI devices are PCI devices regardless of
> the controller?

There is no currently a way to deal with that situation since you have a
chicken and egg problem to solve: there is no pci_device created until
you enumerate the PCI bus, and you cannot enumerate the bus and create
those pci_devices unless you power on the slots/PCIe end-points attached
to the root complex. There are precedents like the rockchip PCIe RC
driver, and yes, we should not be cargo culting this, which is why we
are trying to understand what is it that should be done here and there
has been conflicting advice, or rather our interpretation has led to
perceiving it as a conflicting.

If the regulator had a variation where it supported passing a
device_node reference to look up regulator properties, we could solve
this generically for all devices, that does not exist, and you stated
you will not accept changes like those, fair enough.

When you suggested to look at soundwire for an example of "software
devices", we did that but it was not clear where the sdw_slave would be
created prior to sdw_slave_add(), but this does not matter too much.

Let us say we try to solve this generically using the same idea that we
would pre-populate pci_device prior to calling pci_scan_child_bus(). We
could do something along these lines:

- pci_scan_child_bus() would attempt to walk the list of device_node
children from the PCIe root complex's device_node and call
pci_alloc_dev() for each of these devices that it finds, along with
calling device_initialize() and ensuring that pci_dev::device::of_node
is set correctly by calling pci_set_of_node()/set_dev_node(). Finally we
call list_add_tail() with the pci_bus_sem semaphore held to add that
pci_device to bus->devices such that we can later find them

- from there on we try to get the regulators of those pci_device objects
we just allocated and we try to enable their regulators, either based on
a specific list of supplies or just trying to enable all supplied declared.

- now pci_scan_child_bus() will attempt to scan the bus for real by
reading the pci_device objects ID but we already have such objects, so
we need to update pci_scan_device() to search bus::devices and if
nothing is found we allocate one

Is that roughly what you have in mind as to what should be done?
-- 
Florian


From lkp at intel.com  Wed Apr  7 20:07:15 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 8 Apr 2021 03:07:15 +0800
Subject: [xlnx:xlnx_rebase_v5.4 478/1704]
 drivers/media/platform/xilinx/xilinx-csi2rxss.c:1828 xcsi2rxss_probe() warn:
 always true condition '(rate < 197000000000) => (0-u32max < 197000000000)'
Message-ID: <202104080306.bMDwh9iq-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   914337937cb6a106a2942347d8c8feacd2223299
commit: 8caa8fb47aa0429f2a25100cf4f957463ba00801 [478/1704] v4l: xilinx: xcsi2rxss: Add support for clock framework
config: i386-randconfig-m021-20210407 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

smatch warnings:
drivers/media/platform/xilinx/xilinx-csi2rxss.c:1828 xcsi2rxss_probe() warn: always true condition '(rate < 197000000000) => (0-u32max < 197000000000)'
drivers/media/platform/xilinx/xilinx-csi2rxss.c:1828 xcsi2rxss_probe() warn: impossible condition '(rate > 203000000000) => (0-u32max > 203000000000)'

vim +1828 drivers/media/platform/xilinx/xilinx-csi2rxss.c

  1759	
  1760	static int xcsi2rxss_probe(struct platform_device *pdev)
  1761	{
  1762		struct v4l2_subdev *subdev;
  1763		struct xcsi2rxss_state *xcsi2rxss;
  1764		struct resource *res;
  1765		const struct of_device_id *match;
  1766		struct device_node *node = pdev->dev.of_node;
  1767		u32 i;
  1768		int ret;
  1769		int num_ctrls;
  1770	
  1771		xcsi2rxss = devm_kzalloc(&pdev->dev, sizeof(*xcsi2rxss), GFP_KERNEL);
  1772		if (!xcsi2rxss)
  1773			return -ENOMEM;
  1774	
  1775		mutex_init(&xcsi2rxss->lock);
  1776	
  1777		xcsi2rxss->core.dev = &pdev->dev;
  1778	
  1779		match = of_match_node(xcsi2rxss_of_id_table, node);
  1780		if (!match)
  1781			return -ENODEV;
  1782	
  1783		xcsi2rxss->core.cfg = match->data;
  1784	
  1785		ret = xcsi2rxss_parse_of(xcsi2rxss);
  1786		if (ret < 0)
  1787			return ret;
  1788	
  1789		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  1790		xcsi2rxss->core.iomem = devm_ioremap_resource(xcsi2rxss->core.dev, res);
  1791		if (IS_ERR(xcsi2rxss->core.iomem))
  1792			return PTR_ERR(xcsi2rxss->core.iomem);
  1793	
  1794		if (xcsi2rxss->core.cfg->flags & XCSI_CLK_PROP) {
  1795			unsigned long rate;
  1796	
  1797			ret = clk_prepare_enable(xcsi2rxss->core.lite_aclk);
  1798			if (ret) {
  1799				dev_err(&pdev->dev, "failed to enable lite_aclk (%d)\n",
  1800					ret);
  1801				goto clk_err;
  1802			}
  1803	
  1804			ret = clk_prepare_enable(xcsi2rxss->core.video_aclk);
  1805			if (ret) {
  1806				dev_err(&pdev->dev, "failed to enable video_aclk (%d)\n",
  1807					ret);
  1808				goto video_aclk_err;
  1809			}
  1810	
  1811			ret = clk_prepare_enable(xcsi2rxss->core.dphy_clk_200M);
  1812			if (ret) {
  1813				dev_err(&pdev->dev, "failed to enable dphy clk (%d)\n",
  1814					ret);
  1815				goto dphy_clk_err;
  1816			}
  1817	
  1818			ret = clk_set_rate(xcsi2rxss->core.dphy_clk_200M,
  1819					   XCSI_DPHY_CLK_REQ);
  1820			if (ret) {
  1821				dev_err(&pdev->dev, "failed to set dphy clk rate (%d)\n",
  1822					ret);
  1823	
  1824				goto all_clk_err;
  1825			}
  1826	
  1827			rate = clk_get_rate(xcsi2rxss->core.dphy_clk_200M);
> 1828			if (rate < XCSI_DPHY_CLK_MIN && rate > XCSI_DPHY_CLK_MAX) {
  1829				dev_err(&pdev->dev, "Err DPHY Clock = %lu\n",
  1830					rate);
  1831				ret = -EINVAL;
  1832				goto all_clk_err;
  1833			}
  1834		}
  1835	
  1836		/*
  1837		 * Reset and initialize the core.
  1838		 */
  1839		xcsi2rxss_reset(&xcsi2rxss->core);
  1840	
  1841		xcsi2rxss->core.events =  (struct xcsi2rxss_event *)&xcsi2rxss_events;
  1842	
  1843		if (xcsi2rxss->core.en_vcx) {
  1844			u32 alloc_size;
  1845	
  1846			alloc_size = sizeof(struct xcsi2rxss_event) *
  1847				     XMIPICSISS_VCX_NUM_EVENTS;
  1848			xcsi2rxss->core.vcx_events = devm_kzalloc(&pdev->dev,
  1849								  alloc_size,
  1850								  GFP_KERNEL);
  1851			if (!xcsi2rxss->core.vcx_events) {
  1852				mutex_destroy(&xcsi2rxss->lock);
  1853				return -ENOMEM;
  1854			}
  1855	
  1856			for (i = 0; i < XMIPICSISS_VCX_NUM_EVENTS; i++)
  1857				xcsi2rxss->core.vcx_events[i].mask = 1 << i;
  1858		}
  1859	
  1860		/* Initialize V4L2 subdevice and media entity */
  1861		xcsi2rxss->pads[0].flags = MEDIA_PAD_FL_SOURCE;
  1862		xcsi2rxss->pads[1].flags = MEDIA_PAD_FL_SINK;
  1863	
  1864		/* Initialize the default format */
  1865		memset(&xcsi2rxss->default_format, 0,
  1866			sizeof(xcsi2rxss->default_format));
  1867		xcsi2rxss->default_format.code = xcsi2rxss->vip_format->code;
  1868		xcsi2rxss->default_format.field = V4L2_FIELD_NONE;
  1869		xcsi2rxss->default_format.colorspace = V4L2_COLORSPACE_SRGB;
  1870		xcsi2rxss->default_format.width = XCSI_DEFAULT_WIDTH;
  1871		xcsi2rxss->default_format.height = XCSI_DEFAULT_HEIGHT;
  1872	
  1873		xcsi2rxss->formats[0] = xcsi2rxss->default_format;
  1874		xcsi2rxss->formats[1] = xcsi2rxss->default_format;
  1875	
  1876		/* Initialize V4L2 subdevice and media entity */
  1877		subdev = &xcsi2rxss->subdev;
  1878		v4l2_subdev_init(subdev, &xcsi2rxss_ops);
  1879	
  1880		subdev->dev = &pdev->dev;
  1881		subdev->internal_ops = &xcsi2rxss_internal_ops;
  1882		strlcpy(subdev->name, dev_name(&pdev->dev), sizeof(subdev->name));
  1883	
  1884		subdev->flags |= V4L2_SUBDEV_FL_HAS_EVENTS | V4L2_SUBDEV_FL_HAS_DEVNODE;
  1885	
  1886		subdev->entity.ops = &xcsi2rxss_media_ops;
  1887	
  1888		v4l2_set_subdevdata(subdev, xcsi2rxss);
  1889	
  1890		ret = media_entity_pads_init(&subdev->entity, 2, xcsi2rxss->pads);
  1891		if (ret < 0)
  1892			goto error;
  1893	
  1894		/*
  1895		 * In case the Enable Active Lanes config parameter is not set,
  1896		 * dynamic lane reconfiguration is not allowed.
  1897		 * So V4L2_CID_XILINX_MIPICSISS_ACT_LANES ctrl will not be registered.
  1898		 * Accordingly allocate the number of controls
  1899		 */
  1900		num_ctrls = ARRAY_SIZE(xcsi2rxss_ctrls);
  1901	
  1902		if (!xcsi2rxss->core.enable_active_lanes)
  1903			num_ctrls--;
  1904	
  1905		dev_dbg(xcsi2rxss->core.dev, "# of ctrls = %d\n", num_ctrls);
  1906	
  1907		v4l2_ctrl_handler_init(&xcsi2rxss->ctrl_handler, num_ctrls);
  1908	
  1909		for (i = 0; i < ARRAY_SIZE(xcsi2rxss_ctrls); i++) {
  1910			struct v4l2_ctrl *ctrl;
  1911	
  1912			if (xcsi2rxss_ctrls[i].id ==
  1913				V4L2_CID_XILINX_MIPICSISS_ACT_LANES) {
  1914	
  1915				if (xcsi2rxss->core.enable_active_lanes) {
  1916					xcsi2rxss_ctrls[i].max =
  1917						xcsi2rxss->core.max_num_lanes;
  1918				} else {
  1919					/* Don't register control */
  1920					dev_dbg(xcsi2rxss->core.dev,
  1921							"Skip active lane control\n");
  1922					continue;
  1923				}
  1924			}
  1925	
  1926			dev_dbg(xcsi2rxss->core.dev, "%d ctrl = 0x%x\n",
  1927					i, xcsi2rxss_ctrls[i].id);
  1928			ctrl = v4l2_ctrl_new_custom(&xcsi2rxss->ctrl_handler,
  1929							&xcsi2rxss_ctrls[i], NULL);
  1930			if (!ctrl) {
  1931				dev_err(xcsi2rxss->core.dev, "Failed for %s ctrl\n",
  1932					xcsi2rxss_ctrls[i].name);
  1933				goto error;
  1934			}
  1935		}
  1936	
  1937		dev_dbg(xcsi2rxss->core.dev, "# v4l2 ctrls registered = %d\n", i - 1);
  1938	
  1939		if (xcsi2rxss->ctrl_handler.error) {
  1940			dev_err(&pdev->dev, "failed to add controls\n");
  1941			ret = xcsi2rxss->ctrl_handler.error;
  1942			goto error;
  1943		}
  1944	
  1945		subdev->ctrl_handler = &xcsi2rxss->ctrl_handler;
  1946	
  1947		ret = v4l2_ctrl_handler_setup(&xcsi2rxss->ctrl_handler);
  1948		if (ret < 0) {
  1949			dev_err(&pdev->dev, "failed to set controls\n");
  1950			goto error;
  1951		}
  1952	
  1953		platform_set_drvdata(pdev, xcsi2rxss);
  1954	
  1955		dev_info(xcsi2rxss->core.dev, "Xilinx CSI2 Rx Subsystem device found!\n");
  1956	
  1957		ret = v4l2_async_register_subdev(subdev);
  1958		if (ret < 0) {
  1959			dev_err(&pdev->dev, "failed to register subdev\n");
  1960			goto error;
  1961		}
  1962	
  1963		/* default states for streaming and suspend */
  1964		xcsi2rxss->streaming = false;
  1965		xcsi2rxss->suspended = false;
  1966		return 0;
  1967	
  1968	error:
  1969		v4l2_ctrl_handler_free(&xcsi2rxss->ctrl_handler);
  1970		media_entity_cleanup(&subdev->entity);
  1971		mutex_destroy(&xcsi2rxss->lock);
  1972	
  1973	all_clk_err:
  1974		clk_disable_unprepare(xcsi2rxss->core.dphy_clk_200M);
  1975	dphy_clk_err:
  1976		clk_disable_unprepare(xcsi2rxss->core.video_aclk);
  1977	video_aclk_err:
  1978		clk_disable_unprepare(xcsi2rxss->core.lite_aclk);
  1979	clk_err:
  1980		return ret;
  1981	}
  1982	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32405 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210408/d28562c5/attachment-0001.gz>

From keescook at chromium.org  Wed Apr  7 20:41:45 2021
From: keescook at chromium.org (Kees Cook)
Date: Wed, 7 Apr 2021 12:41:45 -0700
Subject: arm-linux-gnueabi-ld: warning: orphan section
 `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being
 placed in section `__cpuidle_method_of_table'
In-Reply-To: <CAKwvOdmcKrHqxkS540CZ=24irC5+o=EH_3RkTTQA-Uk9qh43YQ@mail.gmail.com>
References: <202104071815.lq85YO6c-lkp@intel.com>
 <CAKwvOdnrSorkpCCshZAav=1rczSTWa5Ji_Nhcd=vzmywAiCoNQ@mail.gmail.com>
 <CAK8P3a0NX4bpQUdHBhpo1s2PU465WjAOAPPzifeHuvFGi20NMw@mail.gmail.com>
 <CAKwvOdmcKrHqxkS540CZ=24irC5+o=EH_3RkTTQA-Uk9qh43YQ@mail.gmail.com>
Message-ID: <202104071241.DDD60D1B49@keescook>

On Wed, Apr 07, 2021 at 11:28:08AM -0700, Nick Desaulniers wrote:
> On Wed, Apr 7, 2021 at 11:23 AM Arnd Bergmann <arnd at arndb.de> wrote:
> >
> > On Wed, Apr 7, 2021 at 8:07 PM Nick Desaulniers <ndesaulniers at google.com> wrote:
> > >
> > > On Wed, Apr 7, 2021 at 3:52 AM kernel test robot <lkp at intel.com> wrote:
> > > >
> > > > Hi Kees,
> > > >
> > > > FYI, the error/warning still remains.
> > > >
> > > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > > head:   2d743660786ec51f5c1fefd5782bbdee7b227db0
> > > > commit: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd arm/build: Warn on orphan section placement
> > > > date:   7 months ago
> > > > config: arm-randconfig-r033-20210407 (attached as .config)
> > > > compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> > > > reproduce (this is a W=1 build):
> > > >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > >         chmod +x ~/bin/make.cross
> > > >         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> > > >         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > >         git fetch --no-tags linus master
> > > >         git checkout 5a17850e251a55bba6d65aefbfeacfa9888cd2cd
> > > >         # save the attached .config to linux build tree
> > > >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
> > > >
> > > > If you fix the issue, kindly add following tag as appropriate
> > > > Reported-by: kernel test robot <lkp at intel.com>
> > > >
> > > > All warnings (new ones prefixed by >>):
> > > >
> > > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > > > >> arm-linux-gnueabi-ld: warning: orphan section `__cpuidle_method_of_table' from `arch/arm/mach-omap2/pm33xx-core.o' being placed in section `__cpuidle_method_of_table'
> > >
> > > Looks like arch/arm/include/asm/cpuidle.h defines
> > > `CPUIDLE_METHOD_OF_DECLARE` to create a static struct in such a
> > > section.  Only arch/arm/mach-omap2/pm33xx-core.c uses that macro.
> >
> > Nick, Kees,
> >
> > Should I resend my patch, or are you taking care of it?
> >
> > https://lore.kernel.org/lkml/20201230155506.1085689-1-arnd at kernel.org/T/#u
> 
> Your patch looks like it has multiple reviewed-by tags, so it should
> be ready to be submitted/merged? Waiting on anything else?

Yeah, that looks ready to go. Does that go via SoC tree or arm32 tree?

-- 
Kees Cook


From broonie at kernel.org  Wed Apr  7 21:07:09 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 7 Apr 2021 21:07:09 +0100
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <03852d1a-1ee4-fd29-8523-4673c35f83cd@gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
 <20210407112713.GB5510@sirena.org.uk>
 <03852d1a-1ee4-fd29-8523-4673c35f83cd@gmail.com>
Message-ID: <20210407200709.GG5510@sirena.org.uk>

On Wed, Apr 07, 2021 at 11:35:57AM -0700, Florian Fainelli wrote:
> On 4/7/2021 4:27 AM, Mark Brown wrote:

> > Frankly I'm not clear why you're trying to handle powering on PCI slots
> > in a specific driver, surely PCI devices are PCI devices regardless of
> > the controller?

> There is no currently a way to deal with that situation since you have a
> chicken and egg problem to solve: there is no pci_device created until
> you enumerate the PCI bus, and you cannot enumerate the bus and create
> those pci_devices unless you power on the slots/PCIe end-points attached
> to the root complex. There are precedents like the rockchip PCIe RC
> driver, and yes, we should not be cargo culting this, which is why we
> are trying to understand what is it that should be done here and there
> has been conflicting advice, or rather our interpretation has led to
> perceiving it as a conflicting.

As you note below I've pointed you at Slimbus which has a similar
problem and solves it at a bus level although it thought of this from
day one which makes life easier; I do think it'd be good to get this
stuff in the driver core since it's an issue that affects every
enumerable bus in the end but nobody's summoned up the enthusiasm for
that (including me).

> If the regulator had a variation where it supported passing a
> device_node reference to look up regulator properties, we could solve
> this generically for all devices, that does not exist, and you stated
> you will not accept changes like those, fair enough.

I'm certainly not enthusiastic about the idea and the likely abuse isn't
inspiring, and of course regulators aren't the only resource that might
be needed to get something up and running and would need to be extended
in the end.  That said I've not seen any concrete proposals either.

> When you suggested to look at soundwire for an example of "software
> devices", we did that but it was not clear where the sdw_slave would be
> created prior to sdw_slave_add(), but this does not matter too much.

Looks like sdw_acpi_find_slaves() and sdw_of_find_slaves().

> Let us say we try to solve this generically using the same idea that we
> would pre-populate pci_device prior to calling pci_scan_child_bus(). We
> could do something along these lines:

...

> - from there on we try to get the regulators of those pci_device objects
> we just allocated and we try to enable their regulators, either based on
> a specific list of supplies or just trying to enable all supplied declared.

I'd suggest specfying the supplies that PCI provides to slots in the
spec with standard names and just using that list, at least as a start.
That'd probably cover most cases and allow the binding to be written at
the generic PCI level rather than having individual devices need to name
their supplies for the binding documentation and validation stuff which
seems easier.  Devices with extra stuff can always extend the binding.

> - now pci_scan_child_bus() will attempt to scan the bus for real by
> reading the pci_device objects ID but we already have such objects, so
> we need to update pci_scan_device() to search bus::devices and if
> nothing is found we allocate one

> Is that roughly what you have in mind as to what should be done?

Yes, pretty much.  Ideally there'd be some way for drivers to get a
callback prior to enumeration to handle any custom stuff for embedded
cases but unless someone actually has a use case for that you could just
punt.
-------------- 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/20210407/8db5964e/attachment.sig>

From will at kernel.org  Wed Apr  7 21:35:37 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 21:35:37 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <20210406125841.1077079-1-maz@kernel.org>
References: <20210406125841.1077079-1-maz@kernel.org>
Message-ID: <20210407203537.GA16011@willie-the-truck>

On Tue, Apr 06, 2021 at 01:58:41PM +0100, Marc Zyngier wrote:
> Although the KVM_ARM_VCPU_INIT documentation mention that the
> registers are reset to their "initial values", it doesn't
> describe what these values are.
> 
> Describe this state explicitly.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  Documentation/virt/kvm/api.rst | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 38e327d4b479..e2237e4e10ba 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -3115,6 +3115,16 @@ optional features it should have. ?This will cause a reset of the cpu
>  registers to their initial values. ?If this is not called, KVM_RUN will
>  return ENOEXEC for that vcpu.
>  
> +The initial values are defined as:
> +	- Processor state:
> +		* AArch64: EL1h, D, A, I and F bits set
> +		* Aarch32: SVC, D, A, I and F bits set

nit, but capitalisation should be "AArch32"

Is "SVC" sufficient, or do we also need to describe Arm vs Thumb?

Will


From alcooperx at gmail.com  Wed Apr  7 21:37:29 2021
From: alcooperx at gmail.com (Alan Cooper)
Date: Wed, 7 Apr 2021 16:37:29 -0400
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
 <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
 <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>
Message-ID: <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>

Nicolas,

I got a better description of the failure and it looks like the bus
clock needs to be limited to 300KHz for a 500MHz core clock.
What's happening is that an internal reset sequence is needed after a
command timeout and the reset signal needs to be asserted for at least
2 ticks of the bus clock. This is done using a 12 bit counter clocked
by the core clock. That means a 500MHz core clock produces a 122KHz
reset signal which is too fast for 2 ticks of the 200KHz bus clock
(100KHz) but is okay for the 300KHz (150Khz) bus clock.

Al

On Mon, Apr 5, 2021 at 4:45 AM Nicolas Saenz Julienne
<nsaenzjulienne at suse.de> wrote:
>
> Hi Alan,
>
> On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
> > Nicolas,
> >
> > Sorry, I just noticed this thread.
> > This is a known bug in some newer Arasan cores.
> > The problem happens when the difference between the core clock and the bus
> > clock is too great.
> > Limiting the clock to 200KHz minimum should be a good fix.
>
> Great, that's what I was hoping to hear :). Out of curiosity, can you share
> more details on how the failure occurs?
>
> > In my experience, it's only eMMC that needs the clock to be retried
>
> > below 400KHz and not SD or SDIO. That's because the CMD signal for
> > eMMC starts out as open-drain during identification and the size of
> > the pull-up on the CMD signal can require the <400KHz clock. Once eMMC
> > is out of identification mode the CMD signal is switched to push-pull
> > and can run at much higher clock rates.
>
> Fair enough, I need to do some tests, some of the compute modules use an eMMC.
>
> > I don't think that SD and SDIO have any open-drain signals, so they
> > shouldn't need to retry at slower clock speeds.
>
> Noted.
>
> > I'm trying to get more detail on the bug, like the exact ratio of core
> > clock to bus clock that causes the problem. When I first found this
> > bug I was told that the failure would not happen at 200KHz, but we
> > were using a 405MHz core clock.
>
> That would be nice to have.
>
> > One other question. Why are you using polling for the SD card, this
> > newer controller supports the interrupt driven "Card Inserted" signal
> > and avoids wasting time polling?
>
> I believe the line isn't routed on RPi4.
>
> > Al
>


From gregory.clement at bootlin.com  Wed Apr  7 21:39:08 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 07 Apr 2021 22:39:08 +0200
Subject: [GIT PULL] ARM: mvebu: dt for v5.13 (#1)
Message-ID: <87v98xbzir.fsf@BL-laptop>

Hi,

Here is the first pull request for dt for mvebu for v5.13.

This one is latter that the other ones, because I've just found a
patch pending since December. I hope it is not too late.

Gregory

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu.git tags/mvebu-dt-5.13-1

for you to fetch changes up to c6dfc019c239c76c179ebbccbac27170ba1e3bb6:

  ARM: dts: mvebu: Add device tree for ATL-x530 Board (2021-04-07 22:31:30 +0200)

----------------------------------------------------------------
mvebu dt for 5.13 (part 1)

Add support for ATL-x530 Board (Armada 38x based)

----------------------------------------------------------------
Aryan Srivastava (1):
      ARM: dts: mvebu: Add device tree for ATL-x530 Board

 arch/arm/boot/dts/Makefile                |   1 +
 arch/arm/boot/dts/armada-385-atl-x530.dts | 235 ++++++++++++++++++++++++++++++
 2 files changed, 236 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-atl-x530.dts
-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From will at kernel.org  Wed Apr  7 21:40:05 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 21:40:05 +0100
Subject: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <1617788943-52722-2-git-send-email-liuqi115@huawei.com>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
 <1617788943-52722-2-git-send-email-liuqi115@huawei.com>
Message-ID: <20210407204004.GB16011@willie-the-truck>

On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> to sample bandwidth, latency, buffer occupation etc.
> 
> Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
> registered as a pmu in /sys/bus/event_source/devices, so users can
> select target PMU, and use filter to do further sets.
> 
> Filtering options contains:
> event        - select the event.
> subevent     - select the subevent.
> port         - select target root ports. Information of root ports
>                are shown under sysfs.
> bdf           - select requester_id of target EP device.
> trig_len     - set trigger condition for starting event statistics.
> trigger_mode - set trigger mode. 0 means starting to statistic when
>                bigger than trigger condition, and 1 means smaller.
> thr_len      - set threshold for statistics.
> thr_mode     - set threshold mode. 0 means count when bigger than
>                threshold, and 1 means smaller.
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

Do you have a link to this review, please?

Will


From gregory.clement at bootlin.com  Wed Apr  7 21:40:47 2021
From: gregory.clement at bootlin.com (Gregory CLEMENT)
Date: Wed, 07 Apr 2021 22:40:47 +0200
Subject: [PATCH v2] ARM: dts: mvebu: Add device tree for ATL-x530 Board
In-Reply-To: <20201130223507.23571-1-aryan.srivastava@alliedtelesis.co.nz>
References: <20201130223507.23571-1-aryan.srivastava@alliedtelesis.co.nz>
Message-ID: <87sg41bzg0.fsf@BL-laptop>

Hello Aryan,

> Add device tree file for x530 board. This has an Armada 385 SoC. Has
> NAND-flash for user storage and SPI for booting. Covers majority of x530
> and GS980MX variants.
>
> Signed-off-by: Aryan Srivastava <aryan.srivastava at alliedtelesis.co.nz>
> Reviewed-by: Chris Packham <chris.packham at alliedtelesis.co.nz>

I don't know why I missed this one but I've finally applied it on
mvebu/dt and sent a pull request for 5.13.

Sorry for this delay.

Thanks,

Gregory


> ---
> Notes:
> 	Changes in v2:
> 	-Adding to Makefile
>
>  arch/arm/boot/dts/Makefile                |   1 +
>  arch/arm/boot/dts/armada-385-atl-x530.dts | 235 ++++++++++++++++++++++
>  2 files changed, 236 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-385-atl-x530.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a60407ad7347..d65d84e9bf9c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1320,6 +1320,7 @@ dtb-$(CONFIG_MACH_ARMADA_375) += \
>  	armada-375-db.dtb
>  dtb-$(CONFIG_MACH_ARMADA_38X) += \
>  	armada-382-rd-ac3x-48g4x2xl.dtb \
> +	armada-385-atl-x530.dtb\
>  	armada-385-clearfog-gtr-s4.dtb \
>  	armada-385-clearfog-gtr-l8.dtb \
>  	armada-385-db-88f6820-amc.dtb \
> diff --git a/arch/arm/boot/dts/armada-385-atl-x530.dts b/arch/arm/boot/dts/armada-385-atl-x530.dts
> new file mode 100644
> index 000000000000..2041bf09c578
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-385-atl-x530.dts
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Armada 385 Allied Telesis x530/GS980MX Board.
> + (x530/AT-GS980MX)
> + *
> + Copyright (C) 2020 Allied Telesis Labs
> + */
> +
> +/dts-v1/;
> +#include "armada-385.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	model = "x530/AT-GS980MX";
> +	compatible = "alliedtelesis,gs980mx", "alliedtelesis,x530", "marvell,armada385", "marvell,armada380";
> +
> +	chosen {
> +		stdout-path = "serial1:115200n8";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x40000000>; /* 1GB */
> +	};
> +
> +	soc {
> +		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
> +			  MBUS_ID(0x01, 0x3d) 0 0xf4800000 0x80000
> +			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
> +
> +		internal-regs {
> +			i2c0: i2c at 11000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&i2c0_pins>;
> +				status = "okay";
> +			};
> +
> +			uart0: serial at 12000 {
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&uart0_pins>;
> +				status = "okay";
> +			};
> +		};
> +	};
> +};
> +
> +&pciec {
> +	status = "okay";
> +};
> +
> +&pcie1 {
> +	status = "okay";
> +	reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>;
> +	reset-delay-us = <400000>;
> +};
> +
> +&pcie2 {
> +	status = "okay";
> +};
> +
> +&devbus_cs1 {
> +	compatible = "marvell,mvebu-devbus";
> +	status = "okay";
> +
> +	devbus,bus-width    = <8>;
> +	devbus,turn-off-ps  = <60000>;
> +	devbus,badr-skew-ps = <0>;
> +	devbus,acc-first-ps = <124000>;
> +	devbus,acc-next-ps  = <248000>;
> +	devbus,rd-setup-ps  = <0>;
> +	devbus,rd-hold-ps   = <0>;
> +
> +	/* Write parameters */
> +	devbus,sync-enable = <0>;
> +	devbus,wr-high-ps  = <60000>;
> +	devbus,wr-low-ps   = <60000>;
> +	devbus,ale-wr-ps   = <60000>;
> +
> +	nvs at 0 {
> +		status = "okay";
> +
> +		compatible = "mtd-ram";
> +		reg = <0 0x00080000>;
> +		bank-width = <1>;
> +		label = "nvs";
> +	};
> +};
> +
> +&pinctrl {
> +	i2c0_gpio_pins: i2c-gpio-pins-0 {
> +		marvell,pins = "mpp2", "mpp3";
> +		marvell,function = "gpio";
> +	};
> +};
> +
> +&i2c0 {
> +	clock-frequency = <100000>;
> +	status = "okay";
> +
> +	pinctrl-names = "default", "gpio";
> +	pinctrl-0 = <&i2c0_pins>;
> +	pinctrl-1 = <&i2c0_gpio_pins>;
> +	scl-gpio = <&gpio0 2 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> +	sda-gpio = <&gpio0 3 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> +
> +	i2c0mux: mux at 71 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "nxp,pca9544";
> +		reg = <0x71>;
> +		i2c-mux-idle-disconnect;
> +
> +		i2c at 0 { /* POE devices MUX */
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +		};
> +
> +		i2c at 1 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <1>;
> +
> +			adt7476_2e: hwmon at 2e {
> +				compatible = "adi,adt7476";
> +				reg = <0x2e>;
> +			};
> +
> +			adt7476_2d: hwmon at 2d {
> +				compatible = "adi,adt7476";
> +				reg = <0x2d>;
> +			};
> +		};
> +
> +		i2c at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <2>;
> +
> +			rtc at 68 {
> +				compatible = "dallas,ds1340";
> +				reg = <0x68>;
> +			};
> +		};
> +
> +		i2c at 3 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <3>;
> +
> +			gpio at 20 {
> +				compatible = "nxp,pca9554";
> +				gpio-controller;
> +				#gpio-cells = <2>;
> +				reg = <0x20>;
> +			};
> +		};
> +	};
> +};
> +
> +&usb0 {
> +	status = "okay";
> +};
> +
> +&spi1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&spi1_pins>;
> +	status = "okay";
> +
> +	spi-flash at 0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "jedec,spi-nor";
> +		reg = <1>; /* Chip select 1 */
> +		spi-max-frequency = <54000000>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition at u-boot {
> +				reg = <0x00000000 0x00100000>;
> +				label = "u-boot";
> +			};
> +			partition at u-boot-env {
> +				reg = <0x00100000 0x00040000>;
> +				label = "u-boot-env";
> +			};
> +			partition at unused {
> +				reg = <0x00140000 0x00e80000>;
> +				label = "unused";
> +			};
> +			partition at idprom {
> +				reg = <0x00fc0000 0x00040000>;
> +				label = "idprom";
> +			};
> +		};
> +	};
> +};
> +
> +&nand_controller {
> +	status = "okay";
> +
> +	nand at 0 {
> +		reg = <0>;
> +		label = "pxa3xx_nand-0";
> +		nand-rb = <0>;
> +		nand-on-flash-bbt;
> +		nand-ecc-strength = <4>;
> +		nand-ecc-step-size = <512>;
> +
> +		marvell,nand-enable-arbiter;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition at user {
> +				reg = <0x00000000 0x0f000000>;
> +				label = "user";
> +			};
> +			partition at errlog {
> +				/* Maximum mtdoops size is 8MB, so set to that. */
> +				reg = <0x0f000000 0x00800000>;
> +				label = "errlog";
> +			};
> +			partition at nand-bbt {
> +				reg = <0x0f800000 0x00800000>;
> +				label = "nand-bbt";
> +			};
> +		};
> +	};
> +};
> +
> -- 
> 2.29.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


From will at kernel.org  Wed Apr  7 21:57:02 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 21:57:02 +0100
Subject: [RFC PATCH v3 1/2] KVM: arm64: Move CMOs from user_mem_abort to
 the fault handlers
In-Reply-To: <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-2-wangyanan55@huawei.com>
 <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>
Message-ID: <20210407205701.GA16198@willie-the-truck>

On Wed, Apr 07, 2021 at 04:31:31PM +0100, Alexandru Elisei wrote:
> On 3/26/21 3:16 AM, Yanan Wang wrote:
> > We currently uniformly permorm CMOs of D-cache and I-cache in function
> > user_mem_abort before calling the fault handlers. If we get concurrent
> > guest faults(e.g. translation faults, permission faults) or some really
> > unnecessary guest faults caused by BBM, CMOs for the first vcpu are
> 
> I can't figure out what BBM means.

Oh, I know that one! BBM means "Break Before Make". Not to be confused with
DBM (Dirty Bit Management) or BFM (Bit Field Move).

Will


From robh at kernel.org  Wed Apr  7 21:58:04 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 7 Apr 2021 15:58:04 -0500
Subject: [PATCH robh next] dt-bindings: bus: add Broadcom CRU
In-Reply-To: <20210309142241.16259-1-zajec5@gmail.com>
References: <20210309142241.16259-1-zajec5@gmail.com>
Message-ID: <20210407205804.GA10597@robh.at.kernel.org>

On Tue, Mar 09, 2021 at 03:22:41PM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> CRU is a block used in Northstar devices. It can be seen in the
> bcm5301x.dtsi and this binding documents its proper usage.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
>  .../devicetree/bindings/bus/brcm,cru.yaml     | 41 +++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/brcm,cru.yaml
> 
> diff --git a/Documentation/devicetree/bindings/bus/brcm,cru.yaml b/Documentation/devicetree/bindings/bus/brcm,cru.yaml
> new file mode 100644
> index 000000000000..c3b1ca53a443
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/brcm,cru.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bus/brcm,cru.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom CRU
> +
> +maintainers:
> +  - Rafa? Mi?ecki <rafal at milecki.pl>
> +
> +description: |
> +  Broadcom CRU ("Clock and Reset Unit" or "Central Resource Unit") is a hardware
> +  block grouping smaller blocks. It contains e.g. clocks, pinctrl, USB PHY and

Are these really separate blocks? I really need to see a complete 
binding for the block.

> +  thermal.
> +
> +allOf:
> +  - $ref: /schemas/simple-bus.yaml#

I don't think this should be a 'simple-bus'. Maybe 'simple-mfd' instead.

> +
> +properties:
> +  compatible:
> +    contains:
> +      const: brcm,cru

This should be SoC specific.

> +
> +  reg:
> +    description: CRU registers
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - reg
> +
> +examples:
> +  - |
> +    cru-bus at 1800c100 {
> +      compatible = "brcm,cru", "simple-bus";
> +      reg = <0x1800c100 0x1d0>;
> +      ranges;
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +    };
> -- 
> 2.26.2
> 


From will at kernel.org  Wed Apr  7 22:03:17 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:03:17 +0100
Subject: [PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace
 using ioremap_np
In-Reply-To: <CAHp75Vcghw6=05vbhX5J8sHoo78JMoq5z4w9__XcocrtRVjF3g@mail.gmail.com>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-12-marcan@marcan.st>
 <CAHp75Vcghw6=05vbhX5J8sHoo78JMoq5z4w9__XcocrtRVjF3g@mail.gmail.com>
Message-ID: <20210407210317.GB16198@willie-the-truck>

On Wed, Apr 07, 2021 at 04:27:42PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 2, 2021 at 12:07 PM Hector Martin <marcan at marcan.st> wrote:
> >
> > Now that we have ioremap_np(), we can make pci_remap_cfgspace() default
> > to it, falling back to ioremap() on platforms where it is not available.
> >
> > Remove the arm64 implementation, since that is now redundant. Future
> > cleanups should be able to do the same for other arches, and eventually
> > make the generic pci_remap_cfgspace() unconditional.
> 
> ...
> 
> > +       void __iomem *ret = ioremap_np(offset, size);
> > +
> > +       if (!ret)
> > +               ret = ioremap(offset, size);
> > +
> > +       return ret;
> 
> Usually negative conditions are worse for cognitive functions of human beings.
> (On top of that some patterns are applied)
> 
> I would rewrite above as
> 
> void __iomem *ret;
> 
> ret = ioremap_np(offset, size);
> if (ret)
>   return ret;
> 
> return ioremap(offset, size);

Looks like it might be one of those rare occasions where the GCC ternary if
extension thingy comes in handy:

	return ioremap_np(offset, size) ?: ioremap(offset, size);

but however it's done, the logic looks good to me and thanks Hector for
updating this:

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Wed Apr  7 22:09:41 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:09:41 +0100
Subject: [PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <20210402090542.131194-16-marcan@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-16-marcan@marcan.st>
Message-ID: <20210407210940.GC16198@willie-the-truck>

On Fri, Apr 02, 2021 at 06:05:39PM +0900, Hector Martin wrote:
> This is the root interrupt controller used on Apple ARM SoCs such as the
> M1. This irqchip driver performs multiple functions:
> 
> * Handles both IRQs and FIQs
> 
> * Drives the AIC peripheral itself (which handles IRQs)
> 
> * Dispatches FIQs to downstream hard-wired clients (currently the ARM
>   timer).
> 
> * Implements a virtual IPI multiplexer to funnel multiple Linux IPIs
>   into a single hardware IPI
> 
> Signed-off-by: Hector Martin <marcan at marcan.st>
> ---
>  MAINTAINERS                     |   2 +
>  drivers/irqchip/Kconfig         |   8 +
>  drivers/irqchip/Makefile        |   1 +
>  drivers/irqchip/irq-apple-aic.c | 837 ++++++++++++++++++++++++++++++++
>  include/linux/cpuhotplug.h      |   1 +
>  5 files changed, 849 insertions(+)
>  create mode 100644 drivers/irqchip/irq-apple-aic.c

Couple of stale comment nits:

> +static void aic_ipi_unmask(struct irq_data *d)
> +{
> +	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
> +	u32 irq_bit = BIT(irqd_to_hwirq(d));
> +
> +	atomic_or(irq_bit, this_cpu_ptr(&aic_vipi_enable));
> +
> +	/*
> +	 * The atomic_or() above must complete before the atomic_read_acquire() below to avoid
> +	 * racing aic_ipi_send_mask().
> +	 */

(the atomic_read_acquire() is now an atomic_read())

> +	smp_mb__after_atomic();
> +
> +	/*
> +	 * If a pending vIPI was unmasked, raise a HW IPI to ourselves.
> +	 * No barriers needed here since this is a self-IPI.
> +	 */
> +	if (atomic_read(this_cpu_ptr(&aic_vipi_flag)) & irq_bit)
> +		aic_ic_write(ic, AIC_IPI_SEND, AIC_IPI_SEND_CPU(smp_processor_id()));
> +}
> +
> +static void aic_ipi_send_mask(struct irq_data *d, const struct cpumask *mask)
> +{
> +	struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
> +	u32 irq_bit = BIT(irqd_to_hwirq(d));
> +	u32 send = 0;
> +	int cpu;
> +	unsigned long pending;
> +
> +	for_each_cpu(cpu, mask) {
> +		/*
> +		 * This sequence is the mirror of the one in aic_ipi_unmask();
> +		 * see the comment there. Additionally, release semantics
> +		 * ensure that the vIPI flag set is ordered after any shared
> +		 * memory accesses that precede it. This therefore also pairs
> +		 * with the atomic_fetch_andnot in aic_handle_ipi().
> +		 */
> +		pending = atomic_fetch_or_release(irq_bit, per_cpu_ptr(&aic_vipi_flag, cpu));
> +
> +		/*
> +		 * The atomic_fetch_or_release() above must complete before the
> +		 * atomic_read_acquire() below to avoid racing aic_ipi_unmask().
> +		 */

(same here)

> +		smp_mb__after_atomic();
> +
> +		if (!(pending & irq_bit) &&
> +		    (atomic_read(per_cpu_ptr(&aic_vipi_enable, cpu)) & irq_bit))
> +			send |= AIC_IPI_SEND_CPU(cpu);
> +	}

But with that:

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Wed Apr  7 22:16:38 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:16:38 +0100
Subject: [PATCH v2 2/3] arm64: Cope with CPUs stuck in VHE mode
In-Reply-To: <20210330173947.999859-3-maz@kernel.org>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-3-maz@kernel.org>
Message-ID: <20210407211637.GD16198@willie-the-truck>

On Tue, Mar 30, 2021 at 06:39:46PM +0100, Marc Zyngier wrote:
> It seems that the CPUs part of the SoC known as Apple M1 have the
> terrible habit of being stuck with HCR_EL2.E2H==1, in violation
> of the architecture.
> 
> Try and work around this deplorable state of affairs by detecting
> the stuck bit early and short-circuit the nVHE dance. Additional
> filtering code ensures that attempts at switching to nVHE from
> the command-line are also ignored.
> 
> It is still unknown whether there are many more such nuggets
> to be found...
> 
> Reported-by: Hector Martin <marcan at marcan.st>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/kernel/head.S           | 39 +++++++++++++++++++++++++++---
>  arch/arm64/kernel/hyp-stub.S       |  8 +++---
>  arch/arm64/kernel/idreg-override.c | 13 +++++++++-
>  3 files changed, 52 insertions(+), 8 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Wed Apr  7 22:18:48 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:18:48 +0100
Subject: [PATCH v2 3/3] arm64: Allow nVHE impaired CPUs to boot without
 CONFIG_ARM64_VHE
In-Reply-To: <20210330173947.999859-4-maz@kernel.org>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-4-maz@kernel.org>
Message-ID: <20210407211848.GE16198@willie-the-truck>

On Tue, Mar 30, 2021 at 06:39:47PM +0100, Marc Zyngier wrote:
> CPUs stuck in VHE mode need some additional care if the kernel
> is compiled without CONFIG_ARM64_VHE.
> 
> Treat this case as another version of a mismatched boot, and
> prevent KVM from being initialised. The machine will boot in
> some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but
> otherwise be functional.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
>  arch/arm64/kvm/va_layout.c    |  9 +++++++++
>  2 files changed, 22 insertions(+), 5 deletions(-)

Hmm, I think we definitely need _something_ here, but it's a bit annoying
to put ourselves into this weird state just for the sake of one stupid
machine.

What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional
instead? Is there a good reason to allow it to be disabled nowadays?

Will


From adrien.grassein at gmail.com  Wed Apr  7 22:21:15 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:15 +0200
Subject: [PATCH v1 0/7] imx-gpcv2 improvements
Message-ID: <20210407212122.626137-1-adrien.grassein@gmail.com>

Hi,

This patch set aims is to add the support of the i.MX8 MM power domains
on the mainline kernel.

To achieve this, I do several patches
  - Check errors when reading or writing registers (concerns i.MX8M base
    implementation);
  - Fix power up/down sequence. Handshake was not checked and it was
    not called at the appropriate time (concerns i.MX8M base
implementaions);
  - Allow domains without power sequence control like the HSIOMIX of the
    i.MX8MM.
  - Add some i.MX8MM domains (HSIO and OTGS);
  - Introduce quirks. For example, i.MX8MM OTG domains should not be
    powered off (seen n the source code of th i.MX ATF). Quirks are
easily upgrable for other cases.
  - Finally I defined power domains into the imx8mm.dtb file.

I know that this kind of patch is rejected by NXP ut the other way
(callin ATF directly) was also rejected.

I also know that NXP is concerned abou adding hundred lines of codes for
each new SOC but it' the way it works on Linux. And the "added code"
mainly consist of adding structures, defines and generic methods for
regmap.

If it's a real problem, maybe we can introduc a new "gpcv3" driver for
i.MX8MM, i.MX8MN and i.MX8MP.

Thanks,  

Adrien Grassein (7):
  soc: imx: gpcv2: check for errors when r/w registers
  soc: imx: gpcv2: Fix power up/down sequence
  soc: imx: gpcv2: allow domains without power sequence control
  dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
  soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
  soc: imx: gpcv2: add quirks to domains
  arm64: dts: imx8mm: add power-domains

 .../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
 drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
 include/dt-bindings/power/imx8mm-power.h      |  21 ++
 4 files changed, 333 insertions(+), 66 deletions(-)
 create mode 100644 include/dt-bindings/power/imx8mm-power.h

-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:17 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:17 +0200
Subject: [PATCH v1 2/7] soc: imx: gpcv2: Fix power up/down sequence
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-3-adrien.grassein@gmail.com>

Power up/down sequence were wrongly scheduled.
The ADB400 were triggered at the bad time.
The Handshake were not checked.

The solution is to:
  - Split power up and power down sequences;
  - Add a register holding the bit to check;

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 235 ++++++++++++++++++++++++++++------------
 1 file changed, 163 insertions(+), 72 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 8ec5b1b817c7..7afb81489f21 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -70,8 +70,11 @@
 #define GPC_PU_PWRHSK			0x1fc
 
 #define IMX8M_GPU_HSK_PWRDNREQN			BIT(6)
+#define IMX8M_GPU_HSK_PWRDNACKN			BIT(26)
 #define IMX8M_VPU_HSK_PWRDNREQN			BIT(5)
+#define IMX8M_VPU_HSK_PWRDNACKN			BIT(25)
 #define IMX8M_DISP_HSK_PWRDNREQN		BIT(4)
+#define IMX8M_DISP_HSK_PWRDNACKN		BIT(24)
 
 /*
  * The PGC offset values in Reference Manual
@@ -102,6 +105,8 @@
 
 #define GPC_CLK_MAX		6
 
+static DEFINE_MUTEX(gpc_pd_mutex);
+
 struct imx_pgc_domain {
 	struct generic_pm_domain genpd;
 	struct regmap *regmap;
@@ -114,7 +119,8 @@ struct imx_pgc_domain {
 	const struct {
 		u32 pxx;
 		u32 map;
-		u32 hsk;
+		u32 hsk_req;
+		u32 hsk_ack;
 	} bits;
 
 	const int voltage;
@@ -127,34 +133,25 @@ struct imx_pgc_domain_data {
 	const struct regmap_access_table *reg_access_table;
 };
 
-static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
-				      bool on)
+static int imx_gpc_pu_pgc_sw_pup_req(struct generic_pm_domain *genpd)
 {
 	struct imx_pgc_domain *domain = container_of(genpd,
 						      struct imx_pgc_domain,
 						      genpd);
-	unsigned int offset = on ?
-		GPC_PU_PGC_SW_PUP_REQ : GPC_PU_PGC_SW_PDN_REQ;
-	const bool enable_power_control = !on;
-	const bool has_regulator = !IS_ERR(domain->regulator);
 	int i, ret = 0;
-	u32 pxx_req;
+	u32 value;
 
-	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-				 domain->bits.map, domain->bits.map);
-	if (ret) {
-		dev_err(domain->dev, "failed to map GPC PGC domain\n");
-		return ret;
-	}
-
-	if (has_regulator && on) {
+	/* Enable regulator if needed */
+	if (!IS_ERR(domain->regulator)) {
 		ret = regulator_enable(domain->regulator);
 		if (ret) {
 			dev_err(domain->dev, "failed to enable regulator\n");
-			goto unmap;
+			return ret;
 		}
 	}
 
+	mutex_lock(&gpc_pd_mutex);
+
 	/* Enable reset clocks for all devices in the domain */
 	for (i = 0; i < domain->num_clks; i++) {
 		ret = clk_prepare_enable(domain->clk[i]);
@@ -164,87 +161,178 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 		}
 	}
 
-	if (enable_power_control) {
-		ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-					 GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+	/* Map the domain to the A53 core */
+	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				 domain->bits.map, domain->bits.map);
+	if (ret) {
+		dev_err(domain->dev, "failed to map GPC PGC domain\n");
+		goto disable_clocks;
+	}
+
+	/* Request Power Up of the domain */
+	ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+				 domain->bits.pxx, domain->bits.pxx);
+	if (ret) {
+		dev_err(domain->dev, "failed to command PGC\n");
+		goto unmap;
+	}
+
+	/*
+	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+	 * for PUP_REQ/PDN_REQ bit to be cleared
+	 */
+	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+				       value,
+				       !(value & domain->bits.pxx),
+				       0, USEC_PER_MSEC);
+	if (ret) {
+		dev_err(domain->dev, "failed to command PGC\n");
+		goto unmap;
+	}
+
+	/* Disable power control */
+	ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+				 GPC_PGC_CTRL_PCR, 0);
+	if (ret) {
+		dev_err(domain->dev, "Failed to disable power control !\n");
+		goto unmap;
+	}
+
+	/* request the ADB400 to power up */
+	if (domain->bits.hsk_req) {
+		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
+				   domain->bits.hsk_req, domain->bits.hsk_req);
+
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
+					       value,
+					       (value & domain->bits.hsk_ack),
+					       0, USEC_PER_MSEC);
+		if (ret)
+			dev_err(domain->dev, "Bad ACK while powering on %s\n",
+				genpd->name);
+	}
+
+	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+			   domain->bits.map, 0);
+
+	/* Disable all clocks */
+	for (i = 0; i < domain->num_clks; i++)
+		clk_disable_unprepare(domain->clk[i]);
+
+	mutex_unlock(&gpc_pd_mutex);
+
+	return 0;
+
+unmap:
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
+
+disable_clocks:
+	for (i--; i >= 0; i--)
+		clk_disable_unprepare(domain->clk[i]);
+
+	mutex_unlock(&gpc_pd_mutex);
+	return ret;
+}
+
+static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
+{
+	struct imx_pgc_domain *domain = container_of(genpd,
+						      struct imx_pgc_domain,
+						      genpd);
+	int i, ret = 0;
+	u32 value;
+
+	mutex_lock(&gpc_pd_mutex);
+
+	/* Enable reset clocks for all devices in the domain */
+	for (i = 0; i < domain->num_clks; i++) {
+		ret = clk_prepare_enable(domain->clk[i]);
 		if (ret) {
-			dev_err(domain->dev, "failed to enable power control\n");
+			dev_err(domain->dev, "failed to enable clocks\n");
 			goto disable_clocks;
 		}
 	}
 
-	if (domain->bits.hsk) {
-		ret = regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
-					 domain->bits.hsk,
-					 on ? domain->bits.hsk : 0);
-		if (ret) {
-			dev_err(domain->dev, "Failed to initiate handshake\n");
-			goto disable_power_control;
-		}
+	/* Map the domain to the A53 core */
+	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				 domain->bits.map, domain->bits.map);
+	if (ret) {
+		dev_err(domain->dev, "failed to map GPC PGC domain\n");
+		goto disable_clocks;
+	}
+
+	/* request the ADB400 to power down */
+	if (domain->bits.hsk_req) {
+		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
+				   domain->bits.hsk_req, 0);
+
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
+					       value,
+					       !(value & domain->bits.hsk_ack),
+					       0, USEC_PER_MSEC);
+		if (ret)
+			dev_err(domain->dev, "Bad ACK while powering down %s\n",
+				genpd->name);
+
 	}
 
-	ret = regmap_update_bits(domain->regmap, offset,
+	/* Enable power control */
+	ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+				 GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+	if (ret) {
+		dev_err(domain->dev, "Failed to enable power control !\n");
+		goto unmap;
+	}
+
+	/* Request Power Down of the domain */
+	ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
 				 domain->bits.pxx, domain->bits.pxx);
 	if (ret) {
 		dev_err(domain->dev, "failed to command PGC\n");
-		goto disable_power_control;
+		goto unmap;
 	}
 
 	/*
 	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
 	 * for PUP_REQ/PDN_REQ bit to be cleared
 	 */
-	ret = regmap_read_poll_timeout(domain->regmap, offset, pxx_req,
-				       !(pxx_req & domain->bits.pxx),
+	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+				       value,
+				       !(value & domain->bits.pxx),
 				       0, USEC_PER_MSEC);
 	if (ret)
 		dev_err(domain->dev, "failed to command PGC\n");
 
-disable_power_control:
-	if (enable_power_control)
-		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				   GPC_PGC_CTRL_PCR, 0);
-
-	if (ret) {
-		/*
-		 * If we were in a process of enabling a
-		 * domain and failed we might as well disable
-		 * the regulator we just enabled. And if it
-		 * was the opposite situation and we failed to
-		 * power down -- keep the regulator on
-		 */
-		on = !on;
+	if (!IS_ERR(domain->regulator)) {
+		ret = regulator_disable(domain->regulator);
+		if (ret)
+			dev_err(domain->dev, "failed to disable regulator\n");
 	}
 
-disable_clocks:
-	/* Disable reset clocks for all devices in the domain */
+	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+			   domain->bits.map, 0);
+
+	/* Disable all clocks */
 	for (i = 0; i < domain->num_clks; i++)
 		clk_disable_unprepare(domain->clk[i]);
 
-	if (has_regulator && !on) {
-		int err;
+	mutex_unlock(&gpc_pd_mutex);
+	return 0;
 
-		err = regulator_disable(domain->regulator);
-		if (err)
-			dev_err(domain->dev,
-				"failed to disable regulator: %d\n", err);
-		/* Preserve earlier error code */
-		ret = ret ?: err;
-	}
 unmap:
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
-	return ret;
-}
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
 
-static int imx_gpc_pu_pgc_sw_pup_req(struct generic_pm_domain *genpd)
-{
-	return imx_gpc_pu_pgc_sw_pxx_req(genpd, true);
-}
+disable_clocks:
+	for (i--; i >= 0; i--)
+		clk_disable_unprepare(domain->clk[i]);
+
+	mutex_unlock(&gpc_pd_mutex);
+	return ret;
 
-static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
-{
-	return imx_gpc_pu_pgc_sw_pxx_req(genpd, false);
 }
 
 static const struct imx_pgc_domain imx7_pgc_domains[] = {
@@ -370,7 +458,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_GPU_SW_Pxx_REQ,
 			.map = IMX8M_GPU_A53_DOMAIN,
-			.hsk = IMX8M_GPU_HSK_PWRDNREQN,
+			.hsk_req = IMX8M_GPU_HSK_PWRDNREQN,
+			.hsk_ack = IMX8M_GPU_HSK_PWRDNACKN
 		},
 		.pgc   = IMX8M_PGC_GPU,
 	},
@@ -382,7 +471,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_VPU_SW_Pxx_REQ,
 			.map = IMX8M_VPU_A53_DOMAIN,
-			.hsk = IMX8M_VPU_HSK_PWRDNREQN,
+			.hsk_req = IMX8M_VPU_HSK_PWRDNREQN,
+			.hsk_ack = IMX8M_VPU_HSK_PWRDNACKN
 		},
 		.pgc   = IMX8M_PGC_VPU,
 	},
@@ -394,7 +484,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_DISP_SW_Pxx_REQ,
 			.map = IMX8M_DISP_A53_DOMAIN,
-			.hsk = IMX8M_DISP_HSK_PWRDNREQN,
+			.hsk_req = IMX8M_DISP_HSK_PWRDNREQN,
+			.hsk_ack = IMX8M_DISP_HSK_PWRDNACKN
 		},
 		.pgc   = IMX8M_PGC_DISP,
 	},
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:16 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:16 +0200
Subject: [PATCH v1 1/7] soc: imx: gpcv2: check for errors when r/w registers
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-2-adrien.grassein@gmail.com>

Errors were not checked after each access to registers
and clocks initialisation.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 62 ++++++++++++++++++++++++++++++-----------
 1 file changed, 45 insertions(+), 17 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index db7e7fc321b1..8ec5b1b817c7 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -140,8 +140,12 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	int i, ret = 0;
 	u32 pxx_req;
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, domain->bits.map);
+	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				 domain->bits.map, domain->bits.map);
+	if (ret) {
+		dev_err(domain->dev, "failed to map GPC PGC domain\n");
+		return ret;
+	}
 
 	if (has_regulator && on) {
 		ret = regulator_enable(domain->regulator);
@@ -152,19 +156,39 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	}
 
 	/* Enable reset clocks for all devices in the domain */
-	for (i = 0; i < domain->num_clks; i++)
-		clk_prepare_enable(domain->clk[i]);
+	for (i = 0; i < domain->num_clks; i++) {
+		ret = clk_prepare_enable(domain->clk[i]);
+		if (ret) {
+			dev_err(domain->dev, "failed to enable clocks\n");
+			goto disable_clocks;
+		}
+	}
 
-	if (enable_power_control)
-		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				   GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+	if (enable_power_control) {
+		ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+					 GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+		if (ret) {
+			dev_err(domain->dev, "failed to enable power control\n");
+			goto disable_clocks;
+		}
+	}
 
-	if (domain->bits.hsk)
-		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
-				   domain->bits.hsk, on ? domain->bits.hsk : 0);
+	if (domain->bits.hsk) {
+		ret = regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
+					 domain->bits.hsk,
+					 on ? domain->bits.hsk : 0);
+		if (ret) {
+			dev_err(domain->dev, "Failed to initiate handshake\n");
+			goto disable_power_control;
+		}
+	}
 
-	regmap_update_bits(domain->regmap, offset,
-			   domain->bits.pxx, domain->bits.pxx);
+	ret = regmap_update_bits(domain->regmap, offset,
+				 domain->bits.pxx, domain->bits.pxx);
+	if (ret) {
+		dev_err(domain->dev, "failed to command PGC\n");
+		goto disable_power_control;
+	}
 
 	/*
 	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
@@ -173,8 +197,15 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	ret = regmap_read_poll_timeout(domain->regmap, offset, pxx_req,
 				       !(pxx_req & domain->bits.pxx),
 				       0, USEC_PER_MSEC);
-	if (ret) {
+	if (ret)
 		dev_err(domain->dev, "failed to command PGC\n");
+
+disable_power_control:
+	if (enable_power_control)
+		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+				   GPC_PGC_CTRL_PCR, 0);
+
+	if (ret) {
 		/*
 		 * If we were in a process of enabling a
 		 * domain and failed we might as well disable
@@ -185,10 +216,7 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 		on = !on;
 	}
 
-	if (enable_power_control)
-		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				   GPC_PGC_CTRL_PCR, 0);
-
+disable_clocks:
 	/* Disable reset clocks for all devices in the domain */
 	for (i = 0; i < domain->num_clks; i++)
 		clk_disable_unprepare(domain->clk[i]);
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:18 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:18 +0200
Subject: [PATCH v1 3/7] soc: imx: gpcv2: allow domains without power sequence
 control
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-4-adrien.grassein@gmail.com>

On new SOCs, some domains does not have power sequence control
registers.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 134 +++++++++++++++++++++-------------------
 1 file changed, 72 insertions(+), 62 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 7afb81489f21..d97a53502753 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -162,40 +162,44 @@ static int imx_gpc_pu_pgc_sw_pup_req(struct generic_pm_domain *genpd)
 	}
 
 	/* Map the domain to the A53 core */
-	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-				 domain->bits.map, domain->bits.map);
-	if (ret) {
-		dev_err(domain->dev, "failed to map GPC PGC domain\n");
-		goto disable_clocks;
+	if (domain->bits.map) {
+		ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+					 domain->bits.map, domain->bits.map);
+		if (ret) {
+			dev_err(domain->dev, "failed to map GPC PGC domain\n");
+			goto disable_clocks;
+		}
 	}
 
 	/* Request Power Up of the domain */
-	ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
-				 domain->bits.pxx, domain->bits.pxx);
-	if (ret) {
-		dev_err(domain->dev, "failed to command PGC\n");
-		goto unmap;
-	}
+	if (domain->bits.pxx) {
+		ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+					 domain->bits.pxx, domain->bits.pxx);
+		if (ret) {
+			dev_err(domain->dev, "failed to command PGC\n");
+			goto unmap;
+		}
 
-	/*
-	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
-	 * for PUP_REQ/PDN_REQ bit to be cleared
-	 */
-	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
-				       value,
-				       !(value & domain->bits.pxx),
-				       0, USEC_PER_MSEC);
-	if (ret) {
-		dev_err(domain->dev, "failed to command PGC\n");
-		goto unmap;
-	}
+		/*
+		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+		 * for PUP_REQ/PDN_REQ bit to be cleared
+		 */
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+					       value,
+					       !(value & domain->bits.pxx),
+					       0, USEC_PER_MSEC);
+		if (ret) {
+			dev_err(domain->dev, "failed to command PGC\n");
+			goto unmap;
+		}
 
-	/* Disable power control */
-	ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				 GPC_PGC_CTRL_PCR, 0);
-	if (ret) {
-		dev_err(domain->dev, "Failed to disable power control !\n");
-		goto unmap;
+		/* Disable power control */
+		ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+					 GPC_PGC_CTRL_PCR, 0);
+		if (ret) {
+			dev_err(domain->dev, "Failed to disable power control !\n");
+			goto unmap;
+		}
 	}
 
 	/* request the ADB400 to power up */
@@ -212,8 +216,9 @@ static int imx_gpc_pu_pgc_sw_pup_req(struct generic_pm_domain *genpd)
 				genpd->name);
 	}
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
 
 	/* Disable all clocks */
 	for (i = 0; i < domain->num_clks; i++)
@@ -256,11 +261,13 @@ static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
 	}
 
 	/* Map the domain to the A53 core */
-	ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-				 domain->bits.map, domain->bits.map);
-	if (ret) {
-		dev_err(domain->dev, "failed to map GPC PGC domain\n");
-		goto disable_clocks;
+	if (domain->bits.map) {
+		ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+					 domain->bits.map, domain->bits.map);
+		if (ret) {
+			dev_err(domain->dev, "failed to map GPC PGC domain\n");
+			goto disable_clocks;
+		}
 	}
 
 	/* request the ADB400 to power down */
@@ -278,32 +285,34 @@ static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
 
 	}
 
-	/* Enable power control */
-	ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				 GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
-	if (ret) {
-		dev_err(domain->dev, "Failed to enable power control !\n");
-		goto unmap;
-	}
+	if (domain->bits.pxx) {
+		/* Enable power control */
+		ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+					 GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+		if (ret) {
+			dev_err(domain->dev, "Failed to enable power control !\n");
+			goto unmap;
+		}
 
-	/* Request Power Down of the domain */
-	ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
-				 domain->bits.pxx, domain->bits.pxx);
-	if (ret) {
-		dev_err(domain->dev, "failed to command PGC\n");
-		goto unmap;
-	}
+		/* Request Power Down of the domain */
+		ret = regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+					 domain->bits.pxx, domain->bits.pxx);
+		if (ret) {
+			dev_err(domain->dev, "failed to command PGC\n");
+			goto unmap;
+		}
 
-	/*
-	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
-	 * for PUP_REQ/PDN_REQ bit to be cleared
-	 */
-	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
-				       value,
-				       !(value & domain->bits.pxx),
-				       0, USEC_PER_MSEC);
-	if (ret)
-		dev_err(domain->dev, "failed to command PGC\n");
+		/*
+		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+		 * for PUP_REQ/PDN_REQ bit to be cleared
+		 */
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+					       value,
+					       !(value & domain->bits.pxx),
+					       0, USEC_PER_MSEC);
+		if (ret)
+			dev_err(domain->dev, "failed to command PGC\n");
+	}
 
 	if (!IS_ERR(domain->regulator)) {
 		ret = regulator_disable(domain->regulator);
@@ -311,8 +320,9 @@ static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
 			dev_err(domain->dev, "failed to disable regulator\n");
 	}
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
 
 	/* Disable all clocks */
 	for (i = 0; i < domain->num_clks; i++)
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:19 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:19 +0200
Subject: [PATCH v1 4/7] dt-bindings: power: fsl,
 imx-gpcv2: add definitions for i.MX8MM
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-5-adrien.grassein@gmail.com>

Update documentation for i.MX8MM.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 .../bindings/power/fsl,imx-gpcv2.yaml         |  7 +++++--
 include/dt-bindings/power/imx8mm-power.h      | 21 +++++++++++++++++++
 2 files changed, 26 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/power/imx8mm-power.h

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
index a96e6dbf1858..04928a173698 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -26,6 +26,7 @@ properties:
     enum:
       - fsl,imx7d-gpc
       - fsl,imx8mq-gpc
+      - fsl,imx8mm-pgc
 
   reg:
     maxItems: 1
@@ -52,8 +53,10 @@ properties:
           reg:
             description: |
               Power domain index. Valid values are defined in
-              include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and
-              include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc
+              include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc,
+              include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc and
+              include/dt-bindings/power/imx8mm-power.h for fsl,imx8mm-gpc
+
             maxItems: 1
 
           clocks:
diff --git a/include/dt-bindings/power/imx8mm-power.h b/include/dt-bindings/power/imx8mm-power.h
new file mode 100644
index 000000000000..bec25fd32394
--- /dev/null
+++ b/include/dt-bindings/power/imx8mm-power.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2021 Adrien Grassein <adrien.grassein at gmail.com>
+ */
+
+#ifndef __DT_BINDINGS_IMX8MM_POWER_H__
+#define __DT_BINDINGS_IMX8MM_POWER_H__
+
+#define IMX8MM_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MM_POWER_DOMAIN_PCIE1	1
+#define IMX8MM_POWER_DOMAIN_USB_OTG1	2
+#define IMX8MM_POWER_DOMAIN_USB_OTG2	3
+#define IMX8MM_POWER_DOMAIN_GPU		4
+#define IMX8MM_POWER_DOMAIN_VPU		5
+#define IMX8MM_POWER_DOMAIN_VPU_G1	6
+#define IMX8MM_POWER_DOMAIN_VPU_G2	7
+#define IMX8MM_POWER_DOMAIN_VPU_H1	8
+#define IMX8MM_POWER_DOMAIN_DISPLAY	9
+#define IMX8MM_POWER_DOMAIN_MIPI	10
+
+#endif
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:20 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:20 +0200
Subject: [PATCH v1 5/7] soc: imx: gpcv2: add HSIOMIX and USB domains for
 i.MX8MM
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-6-adrien.grassein@gmail.com>

Add description for 3 domains of the i.MX8MM:
  - HSIO
  - USB OTG 1
  - USB OTG 2

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 69 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index d97a53502753..571d0381dd87 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -17,6 +17,8 @@
 #include <linux/sizes.h>
 #include <dt-bindings/power/imx7-power.h>
 #include <dt-bindings/power/imx8mq-power.h>
+#include <dt-bindings/power/imx8mm-power.h>
+
 
 #define GPC_LPCR_A_CORE_BSC			0x000
 
@@ -42,6 +44,9 @@
 #define IMX8M_PCIE1_A53_DOMAIN			BIT(3)
 #define IMX8M_MIPI_A53_DOMAIN			BIT(2)
 
+#define IMX8MM_OTG2_A53_DOMAIN			BIT(5)
+#define IMX8MM_OTG1_A53_DOMAIN			BIT(4)
+
 #define GPC_PU_PGC_SW_PUP_REQ		0x0f8
 #define GPC_PU_PGC_SW_PDN_REQ		0x104
 
@@ -65,6 +70,9 @@
 #define IMX8M_PCIE1_SW_Pxx_REQ			BIT(1)
 #define IMX8M_MIPI_SW_Pxx_REQ			BIT(0)
 
+#define IMX8MM_OTG1_SW_Pxx_REQ			BIT(2)
+#define IMX8MM_OTG2_SW_Pxx_REQ			BIT(3)
+
 #define GPC_M4_PU_PDN_FLG		0x1bc
 
 #define GPC_PU_PWRHSK			0x1fc
@@ -76,6 +84,9 @@
 #define IMX8M_DISP_HSK_PWRDNREQN		BIT(4)
 #define IMX8M_DISP_HSK_PWRDNACKN		BIT(24)
 
+#define IMX8MM_HSIO_HSK_PWRDNREQN		(BIT(5) | BIT(6))
+#define IMX8MM_HSIO_HSK_PWRDNACKN		(BIT(23) | BIT(24))
+
 /*
  * The PGC offset values in Reference Manual
  * (Rev. 1, 01/2018 and the older ones) GPC chapter's
@@ -98,6 +109,9 @@
 #define IMX8M_PGC_MIPI_CSI2		28
 #define IMX8M_PGC_PCIE2			29
 
+#define IMX8MM_PGC_OTG1			18
+#define IMX8MM_PGC_OTG2			19
+
 #define GPC_PGC_CTRL(n)			(0x800 + (n) * 0x40)
 #define GPC_PGC_SR(n)			(GPC_PGC_CTRL(n) + 0xc)
 
@@ -572,6 +586,60 @@ static const struct imx_pgc_domain_data imx8m_pgc_domain_data = {
 	.reg_access_table = &imx8m_access_table,
 };
 
+static const struct imx_pgc_domain imx8mm_pgc_domains[] = {
+	[IMX8MM_POWER_DOMAIN_HSIOMIX] = {
+		.genpd = {
+			.name = "hsiomix",
+		},
+		.bits  = {
+			.hsk_req = IMX8MM_HSIO_HSK_PWRDNREQN,
+			.hsk_ack = IMX8MM_HSIO_HSK_PWRDNACKN,
+		},
+	},
+
+	[IMX8MM_POWER_DOMAIN_USB_OTG1] = {
+		.genpd      = {
+			.name = "usb-otg1",
+		},
+		.bits       = {
+			.pxx = IMX8MM_OTG1_SW_Pxx_REQ,
+			.map = IMX8MM_OTG1_A53_DOMAIN,
+		},
+		.pgc        = IMX8MM_PGC_OTG1,
+	},
+
+	[IMX8MM_POWER_DOMAIN_USB_OTG2] = {
+		.genpd      = {
+			.name = "usb-otg2",
+		},
+		.bits       =  {
+			.pxx = IMX8MM_OTG2_SW_Pxx_REQ,
+			.map = IMX8MM_OTG2_A53_DOMAIN,
+		},
+		.pgc        = IMX8MM_PGC_OTG2,
+	},
+};
+
+static const struct regmap_range imx8mm_yes_ranges[] = {
+		regmap_reg_range(GPC_LPCR_A_CORE_BSC,
+				 GPC_PU_PWRHSK),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_OTG1),
+				 GPC_PGC_SR(IMX8MM_PGC_OTG1)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_OTG2),
+				 GPC_PGC_SR(IMX8MM_PGC_OTG2)),
+};
+
+static const struct regmap_access_table imx8mm_access_table = {
+	.yes_ranges	= imx8mm_yes_ranges,
+	.n_yes_ranges	= ARRAY_SIZE(imx8mm_yes_ranges),
+};
+
+static const struct imx_pgc_domain_data imx8mm_pgc_domain_data = {
+	.domains = imx8mm_pgc_domains,
+	.domains_num = ARRAY_SIZE(imx8mm_pgc_domains),
+	.reg_access_table = &imx8mm_access_table,
+};
+
 static int imx_pgc_get_clocks(struct imx_pgc_domain *domain)
 {
 	int i, ret;
@@ -766,6 +834,7 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
 static const struct of_device_id imx_gpcv2_dt_ids[] = {
 	{ .compatible = "fsl,imx7d-gpc", .data = &imx7_pgc_domain_data, },
 	{ .compatible = "fsl,imx8mq-gpc", .data = &imx8m_pgc_domain_data, },
+	{ .compatible = "fsl,imx8mm-gpc", .data = &imx8mm_pgc_domain_data, },
 	{ }
 };
 
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:21 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:21 +0200
Subject: [PATCH v1 6/7] soc: imx: gpcv2: add quirks to domains
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-7-adrien.grassein@gmail.com>

Some domains need quirks during their operation.
For example, on i.MX8MM, USB domains should not be powered off.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 571d0381dd87..592b9808dcd4 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -119,6 +119,10 @@
 
 #define GPC_CLK_MAX		6
 
+/* Quirks */
+//Refuse to poweroff the domain
+#define GPC_QUIRKS_DONT_POWEROFF BIT(0)
+
 static DEFINE_MUTEX(gpc_pd_mutex);
 
 struct imx_pgc_domain {
@@ -139,6 +143,7 @@ struct imx_pgc_domain {
 
 	const int voltage;
 	struct device *dev;
+	const unsigned int quirks;
 };
 
 struct imx_pgc_domain_data {
@@ -263,6 +268,9 @@ static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
 	int i, ret = 0;
 	u32 value;
 
+	if (domain->quirks & GPC_QUIRKS_DONT_POWEROFF)
+		return 0;
+
 	mutex_lock(&gpc_pd_mutex);
 
 	/* Enable reset clocks for all devices in the domain */
@@ -606,6 +614,7 @@ static const struct imx_pgc_domain imx8mm_pgc_domains[] = {
 			.map = IMX8MM_OTG1_A53_DOMAIN,
 		},
 		.pgc        = IMX8MM_PGC_OTG1,
+		.quirks     = GPC_QUIRKS_DONT_POWEROFF,
 	},
 
 	[IMX8MM_POWER_DOMAIN_USB_OTG2] = {
@@ -617,6 +626,7 @@ static const struct imx_pgc_domain imx8mm_pgc_domains[] = {
 			.map = IMX8MM_OTG2_A53_DOMAIN,
 		},
 		.pgc        = IMX8MM_PGC_OTG2,
+		.quirks     = GPC_QUIRKS_DONT_POWEROFF,
 	},
 };
 
-- 
2.25.1



From adrien.grassein at gmail.com  Wed Apr  7 22:21:22 2021
From: adrien.grassein at gmail.com (Adrien Grassein)
Date: Wed,  7 Apr 2021 23:21:22 +0200
Subject: [PATCH v1 7/7] arm64: dts: imx8mm: add power-domains
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <20210407212122.626137-8-adrien.grassein@gmail.com>

Add description for HSIO and USB power-domains.

Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 35 +++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index a27e02bee6b4..028b8930db5a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -4,6 +4,7 @@
  */
 
 #include <dt-bindings/clock/imx8mm-clock.h>
+#include <dt-bindings/power/imx8mm-power.h>
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -600,6 +601,38 @@ src: reset-controller at 30390000 {
 				interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 				#reset-cells = <1>;
 			};
+
+			gpc: gpc at 303a0000 {
+				compatible = "fsl,imx8mm-gpc";
+				reg = <0x303a0000 0x10000>;
+				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-parent = <&gic>;
+				interrupt-controller;
+				#interrupt-cells = <3>;
+
+				pgc {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					pgc_hsiomix: power-domain at IMX8MM_POWER_DOMAIN_HSIOMIX {
+						#power-domain-cells = <0>;
+						reg = <IMX8MM_POWER_DOMAIN_HSIOMIX>;
+						clocks = <&clk IMX8MM_CLK_USB_BUS>;
+					};
+
+					pgc_usb_otg1: power-domain at IMX8MM_POWER_DOMAIN_USB_OTG1 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MM_POWER_DOMAIN_USB_OTG1>;
+						power-domains = <&pgc_hsiomix>;
+					};
+
+					pgc_usb_otg2: power-domain at IMX8MM_POWER_DOMAIN_USB_OTG2 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MM_POWER_DOMAIN_USB_OTG2>;
+						power-domains = <&pgc_hsiomix>;
+					};
+				};
+			};
 		};
 
 		aips2: bus at 30400000 {
@@ -953,6 +986,7 @@ usbotg1: usb at 32e40000 {
 				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
 				fsl,usbphy = <&usbphynop1>;
 				fsl,usbmisc = <&usbmisc1 0>;
+				power-domains = <&pgc_usb_otg1>;
 				status = "disabled";
 			};
 
@@ -972,6 +1006,7 @@ usbotg2: usb at 32e50000 {
 				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
 				fsl,usbphy = <&usbphynop2>;
 				fsl,usbmisc = <&usbmisc2 0>;
+				power-domains = <&pgc_usb_otg2>;
 				status = "disabled";
 			};
 
-- 
2.25.1



From will at kernel.org  Wed Apr  7 22:35:03 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:35:03 +0100
Subject: [PATCH v10 5/6] arm64: entry: Enable random_kstack_offset support
In-Reply-To: <20210401232347.2791257-6-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
 <20210401232347.2791257-6-keescook@chromium.org>
Message-ID: <20210407213502.GA16569@willie-the-truck>

On Thu, Apr 01, 2021 at 04:23:46PM -0700, Kees Cook wrote:
> Allow for a randomized stack offset on a per-syscall basis, with roughly
> 5 bits of entropy. (And include AAPCS rationale AAPCS thanks to Mark
> Rutland.)
> 
> In order to avoid unconditional stack canaries on syscall entry (due to
> the use of alloca()), also disable stack protector to avoid triggering
> needless checks and slowing down the entry path. As there is no general
> way to control stack protector coverage with a function attribute[1],
> this must be disabled at the compilation unit level. This isn't a problem
> here, though, since stack protector was not triggered before: examining
> the resulting syscall.o, there are no changes in canary coverage (none
> before, none now).
> 
> [1] a working __attribute__((no_stack_protector)) has been added to GCC
> and Clang but has not been released in any version yet:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=346b302d09c1e6db56d9fe69048acb32fbb97845
> https://reviews.llvm.org/rG4fbf84c1732fca596ad1d6e96015e19760eb8a9b
> 
> Signed-off-by: Kees Cook <keescook at chromium.org>
> ---
>  arch/arm64/Kconfig          |  1 +
>  arch/arm64/kernel/Makefile  |  5 +++++
>  arch/arm64/kernel/syscall.c | 16 ++++++++++++++++
>  3 files changed, 22 insertions(+)

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Wed Apr  7 22:37:02 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 7 Apr 2021 22:37:02 +0100
Subject: [PATCH v10 3/6] stack: Optionally randomize kernel stack offset
 each syscall
In-Reply-To: <20210401232347.2791257-4-keescook@chromium.org>
References: <20210401232347.2791257-1-keescook@chromium.org>
 <20210401232347.2791257-4-keescook@chromium.org>
Message-ID: <20210407213702.GB16569@willie-the-truck>

On Thu, Apr 01, 2021 at 04:23:44PM -0700, Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
> CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.
> 
> This feature is based on the original idea from the last public release
> of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt
> All the credit for the original idea goes to the PaX team. Note that
> the design and implementation of this upstream randomize_kstack_offset
> feature differs greatly from the RANDKSTACK feature (see below).

[...]

> diff --git a/include/linux/randomize_kstack.h b/include/linux/randomize_kstack.h
> new file mode 100644
> index 000000000000..fd80fab663a9
> --- /dev/null
> +++ b/include/linux/randomize_kstack.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _LINUX_RANDOMIZE_KSTACK_H
> +#define _LINUX_RANDOMIZE_KSTACK_H
> +
> +#include <linux/kernel.h>
> +#include <linux/jump_label.h>
> +#include <linux/percpu-defs.h>
> +
> +DECLARE_STATIC_KEY_MAYBE(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT,
> +			 randomize_kstack_offset);
> +DECLARE_PER_CPU(u32, kstack_offset);
> +
> +/*
> + * Do not use this anywhere else in the kernel. This is used here because
> + * it provides an arch-agnostic way to grow the stack with correct
> + * alignment. Also, since this use is being explicitly masked to a max of
> + * 10 bits, stack-clash style attacks are unlikely. For more details see
> + * "VLAs" in Documentation/process/deprecated.rst
> + */
> +void *__builtin_alloca(size_t size);
> +/*
> + * Use, at most, 10 bits of entropy. We explicitly cap this to keep the
> + * "VLA" from being unbounded (see above). 10 bits leaves enough room for
> + * per-arch offset masks to reduce entropy (by removing higher bits, since
> + * high entropy may overly constrain usable stack space), and for
> + * compiler/arch-specific stack alignment to remove the lower bits.
> + */
> +#define KSTACK_OFFSET_MAX(x)	((x) & 0x3FF)
> +
> +/*
> + * These macros must be used during syscall entry when interrupts and
> + * preempt are disabled, and after user registers have been stored to
> + * the stack.
> + */

This comment is out of date, as this is called from preemptible context on
arm64. Does that matter in terms of offset randomness?

Will


From patchwork-bot+netdevbpf at kernel.org  Wed Apr  7 22:40:09 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 07 Apr 2021 21:40:09 +0000
Subject: [PATCH v2 net-next] stmmac: intel: Enable SERDES PHY rx clk for
 PSE
In-Reply-To: <20210406013250.17171-1-weifeng.voon@intel.com>
References: <20210406013250.17171-1-weifeng.voon@intel.com>
Message-ID: <161783160909.25121.17977461740067314533.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  6 Apr 2021 09:32:50 +0800 you wrote:
> EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
> sequence and vice versa.
> 
> Signed-off-by: Voon Weifeng <weifeng.voon at intel.com>
> ---
> Changes:
>  v1 -> v2
>  -change subject from "net: intel" to "stmmac: intel"
> 
> [...]

Here is the summary with links:
  - [v2,net-next] stmmac: intel: Enable SERDES PHY rx clk for PSE
    https://git.kernel.org/netdev/net-next/c/017d6250ad71

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From f.fainelli at gmail.com  Wed Apr  7 22:43:40 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 7 Apr 2021 14:43:40 -0700
Subject: [PATCH robh next] dt-bindings: bus: add Broadcom CRU
In-Reply-To: <20210407205804.GA10597@robh.at.kernel.org>
References: <20210309142241.16259-1-zajec5@gmail.com>
 <20210407205804.GA10597@robh.at.kernel.org>
Message-ID: <72bb76b7-7155-8b19-c1d0-4409acc0b32c@gmail.com>



On 4/7/2021 1:58 PM, Rob Herring wrote:
> On Tue, Mar 09, 2021 at 03:22:41PM +0100, Rafa? Mi?ecki wrote:
>> From: Rafa? Mi?ecki <rafal at milecki.pl>
>>
>> CRU is a block used in Northstar devices. It can be seen in the
>> bcm5301x.dtsi and this binding documents its proper usage.
>>
>> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
>> ---
>>  .../devicetree/bindings/bus/brcm,cru.yaml     | 41 +++++++++++++++++++
>>  1 file changed, 41 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/bus/brcm,cru.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/bus/brcm,cru.yaml b/Documentation/devicetree/bindings/bus/brcm,cru.yaml
>> new file mode 100644
>> index 000000000000..c3b1ca53a443
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/brcm,cru.yaml
>> @@ -0,0 +1,41 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/bus/brcm,cru.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Broadcom CRU
>> +
>> +maintainers:
>> +  - Rafa? Mi?ecki <rafal at milecki.pl>
>> +
>> +description: |
>> +  Broadcom CRU ("Clock and Reset Unit" or "Central Resource Unit") is a hardware
>> +  block grouping smaller blocks. It contains e.g. clocks, pinctrl, USB PHY and
> 
> Are these really separate blocks? I really need to see a complete 
> binding for the block.

The situation is a bit confusing because the CRU that is being described
here is not the CRU that is being described in the datasheet as a
block... but the registers are still prefixed CRU because they have a
clocking and reset component/function.

There are CRU registers within the DMU (Device Management Unit) and the
DMU is a sundry of various things containing:

- an internal MDIO bus controller (PCU_MDIO_MGT, PCU_MDIO_CMD)
- 4 registers to control and show the internal regulator status
- a collection of PLL and clock controls from 0x1800_c100 through 0x180_c180
- reset controls
- internal MDIO mux
- GPIO/pinmux/drive strength controls
- switch register interrupts
- adaptive voltage scaling registers
- gap
- crystal control

The 0x1d0 size would span all registers mentioned above and end
somewhere in the gap between AVS and XTAL.

> 
>> +  thermal.
>> +
>> +allOf:
>> +  - $ref: /schemas/simple-bus.yaml#
> 
> I don't think this should be a 'simple-bus'. Maybe 'simple-mfd' instead.
> 
>> +
>> +properties:
>> +  compatible:
>> +    contains:
>> +      const: brcm,cru
> 
> This should be SoC specific.

Yes agreed, brcm,bcm5301x-cru at least sine this is common to all
Northstar platforms.
-- 
Florian


From linux at roeck-us.net  Wed Apr  7 22:48:11 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 7 Apr 2021 14:48:11 -0700
Subject: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
In-Reply-To: <1615963949-75320-3-git-send-email-manish.narani@xilinx.com>
References: <1615963949-75320-1-git-send-email-manish.narani@xilinx.com>
 <1615963949-75320-3-git-send-email-manish.narani@xilinx.com>
Message-ID: <20210407214811.GA260719@roeck-us.net>

On Wed, Mar 17, 2021 at 12:22:29PM +0530, Manish Narani wrote:
> Add a new driver for supporting Xilinx platforms. This driver is used
> for some sequence of operations required for Xilinx USB controllers.
> This driver is also used to choose between PIPE clock coming from SerDes
> and the Suspend Clock. Before the controller is out of reset, the clock
> selection should be changed to PIPE clock in order to make the USB
> controller work. There is a register added in Xilinx USB controller
> register space for the same.
> 
> Signed-off-by: Manish Narani <manish.narani at xilinx.com>

Trying this driver with qemu (v6.0.0-rc2) results in:

[   15.184242] dwc3-xilinx ff9d0000.usb: error -ENODEV: failed to assert Reset
[   15.185754] Unable to handle kernel paging request at virtual address 006b6b6b6b6b6b9b
[   15.185994] Mem abort info:
[   15.186065]   ESR = 0x96000004
[   15.186317]   EC = 0x25: DABT (current EL), IL = 32 bits
[   15.186414]   SET = 0, FnV = 0
[   15.186498]   EA = 0, S1PTW = 0
[   15.186579] Data abort info:
[   15.186666]   ISV = 0, ISS = 0x00000004
[   15.186756]   CM = 0, WnR = 0
[   15.186887] [006b6b6b6b6b6b9b] address between user and kernel address ranges
[   15.187436] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[   15.187777] Modules linked in:
[   15.188060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc6-next-20210406-00006-g05407f068fc9-dirty #1
[   15.188265] Hardware name: Xilinx Versal Virtual development board (DT)
[   15.188495] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[   15.188614] pc : __clk_put+0x24/0x138
[   15.188716] lr : __clk_put+0x24/0x138
[   15.188791] sp : ffff80001326bac0
[   15.188853] x29: ffff80001326bac0 x28: ffff00000644ed00
[   15.188982] x27: ffff00000421ecd0 x26: ffff00000421e810
[   15.189076] x25: ffff00000644f100 x24: 0000000000000000
[   15.189170] x23: ffff8000126a2570 x22: 0000000000000005
[   15.189271] x21: ffff00000644ed00 x20: ffff000006449970
[   15.189367] x19: 6b6b6b6b6b6b6b6b x18: 0000000000000010
[   15.189456] x17: 0000000000000001 x16: 0000000000000000
[   15.189546] x15: ffff000003af0490 x14: 00000000000001b7
[   15.189642] x13: ffff000003af0490 x12: 00000000ffffffea
[   15.189729] x11: ffff8000123b6460 x10: 0000000000000080
[   15.189815] x9 : 00000000676993c6 x8 : 00000000676993c6
[   15.189941] x7 : 000000007d152ab3 x6 : ffff800012768480
[   15.190047] x5 : 0000000000000000 x4 : 000000007f97631e
[   15.190139] x3 : 00000000d5bdf2c2 x2 : 000000000000000b
[   15.190233] x1 : ffff000003af0040 x0 : 0000000000000001
[   15.190432] Call trace:
[   15.190506]  __clk_put+0x24/0x138
[   15.190588]  clk_put+0x10/0x20
[   15.190653]  clk_bulk_put+0x3c/0x60
[   15.190724]  devm_clk_bulk_release+0x1c/0x28
[   15.190806]  release_nodes+0x1c0/0x2b0
[   15.190887]  devres_release_all+0x38/0x60
[   15.190963]  really_probe+0x1e4/0x3a8
[   15.191042]  driver_probe_device+0x64/0xc8
...

because of ...

> +
> +	ret = devm_clk_bulk_get_all(priv_data->dev, &priv_data->clks);
> +	if (ret < 0)
> +		return ret;
> +
...
> +
> +err_clk_put:
> +	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
> +	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);

clk_bulk_put_all() is not necessary because of devm_clk_bulk_get_all(),
and results in a double free.

> +static int dwc3_xlnx_remove(struct platform_device *pdev)
> +{
> +	struct dwc3_xlnx	*priv_data = platform_get_drvdata(pdev);
> +	struct device		*dev = &pdev->dev;
> +
> +	of_platform_depopulate(dev);
> +
> +	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
> +	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);

Same here. This will likely crash the driver on unload.

Guenter


From richard.weinberger at gmail.com  Wed Apr  7 22:56:36 2021
From: richard.weinberger at gmail.com (Richard Weinberger)
Date: Wed, 7 Apr 2021 23:56:36 +0200
Subject: [PATCH v1 1/1] ubifs: only check replay with inode type to judge
 if inode linked
In-Reply-To: <20210316085214.25024-2-guochun.mao@mediatek.com>
References: <20210316085214.25024-1-guochun.mao@mediatek.com>
 <20210316085214.25024-2-guochun.mao@mediatek.com>
Message-ID: <CAFLxGvygphmHbhzHJmSO=NQFO_02oSamXVjC5Loj2nCcQWWYNg@mail.gmail.com>

On Tue, Mar 16, 2021 at 10:00 AM <guochun.mao at mediatek.com> wrote:
>
> From: Guochun Mao <guochun.mao at mediatek.com>
>
> Conside the following case, it just write a big file into flash,
> when complete writing, delete the file, and then power off promptly.
> Next time power on, we'll get a replay list like:
> ...
> LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
> LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
> LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
> ...
> In the replay list, data nodes' deletion are 0, and the inode node's
> deletion is 1. In current logic, the file's dentry will be removed,
> but inode and the flash space it occupied will be reserved.
> User will see that much free space been disappeared.
>
> We only need to check the deletion value of the following inode type
> node of the replay entry.
>
> Signed-off-by: Guochun Mao <guochun.mao at mediatek.com>
> ---
>  fs/ubifs/replay.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 0f8a6a16421b..1929ec63a0cb 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
>          */
>         list_for_each_entry_reverse(r, &c->replay_list, list) {
>                 ubifs_assert(c, r->sqnum >= rino->sqnum);
> -               if (key_inum(c, &r->key) == key_inum(c, &rino->key))
> +               if (key_inum(c, &r->key) == key_inum(c, &rino->key) &&
> +                   key_type(c, &r->key) == UBIFS_INO_KEY)

This change makes sense. Thanks a lot for hunting this down.
It will be part of the merge window.

-- 
Thanks,
//richard


From lkp at intel.com  Wed Apr  7 23:03:45 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 8 Apr 2021 06:03:45 +0800
Subject: [arm-platforms:irq/irqchip-next 15/16]
 drivers/irqchip/irq-wpcm450-aic.c:64:35: error: expected '=', ',', ';',
 'asm' or '__attribute__' before 'wpcm450_aic_handle_irq'
Message-ID: <202104080643.SXyQFrVo-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/irqchip-next
head:   ea4aeaa5c88906eb3ca3d7d3d17a45605d2dd0de
commit: fead4dd496631707549f414b4059afb86ea8fb80 [15/16] irqchip: Add driver for WPCM450 interrupt controller
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?id=fead4dd496631707549f414b4059afb86ea8fb80
        git remote add arm-platforms https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
        git fetch --no-tags arm-platforms irq/irqchip-next
        git checkout fead4dd496631707549f414b4059afb86ea8fb80
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=ia64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/irqchip/irq-wpcm450-aic.c:64:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'wpcm450_aic_handle_irq'
      64 | static void __exception_irq_entry wpcm450_aic_handle_irq(struct pt_regs *regs)
         |                                   ^~~~~~~~~~~~~~~~~~~~~~
   In file included from include/linux/of_irq.h:7,
                    from drivers/irqchip/irq-wpcm450-aic.c:6:
   drivers/irqchip/irq-wpcm450-aic.c: In function 'wpcm450_aic_of_init':
>> drivers/irqchip/irq-wpcm450-aic.c:154:17: error: 'wpcm450_aic_handle_irq' undeclared (first use in this function); did you mean 'wpcm450_aic_eoi'?
     154 |  set_handle_irq(wpcm450_aic_handle_irq);
         |                 ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/irq.h:1263:9: note: in definition of macro 'set_handle_irq'
    1263 |   (void)handle_irq;  \
         |         ^~~~~~~~~~
   drivers/irqchip/irq-wpcm450-aic.c:154:17: note: each undeclared identifier is reported only once for each function it appears in
     154 |  set_handle_irq(wpcm450_aic_handle_irq);
         |                 ^~~~~~~~~~~~~~~~~~~~~~
   include/linux/irq.h:1263:9: note: in definition of macro 'set_handle_irq'
    1263 |   (void)handle_irq;  \
         |         ^~~~~~~~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for FRAME_POINTER
   Depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS
   Selected by
   - FAULT_INJECTION_STACKTRACE_FILTER && FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT && !X86_64 && !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86


vim +64 drivers/irqchip/irq-wpcm450-aic.c

    63	
  > 64	static void __exception_irq_entry wpcm450_aic_handle_irq(struct pt_regs *regs)
    65	{
    66		int hwirq;
    67	
    68		/* Determine the interrupt source */
    69		/* Read IPER to signal that nIRQ can be de-asserted */
    70		hwirq = readl(aic->regs + AIC_IPER) / 4;
    71	
    72		handle_domain_irq(aic->domain, hwirq, regs);
    73	}
    74	
    75	static void wpcm450_aic_eoi(struct irq_data *d)
    76	{
    77		/* Signal end-of-service */
    78		writel(0, aic->regs + AIC_EOSCR);
    79	}
    80	
    81	static void wpcm450_aic_mask(struct irq_data *d)
    82	{
    83		unsigned int mask = BIT(d->hwirq);
    84	
    85		/* Disable (mask) the interrupt */
    86		writel(mask, aic->regs + AIC_MDCR);
    87	}
    88	
    89	static void wpcm450_aic_unmask(struct irq_data *d)
    90	{
    91		unsigned int mask = BIT(d->hwirq);
    92	
    93		/* Enable (unmask) the interrupt */
    94		writel(mask, aic->regs + AIC_MECR);
    95	}
    96	
    97	static int wpcm450_aic_set_type(struct irq_data *d, unsigned int flow_type)
    98	{
    99		/*
   100		 * The hardware supports high/low level, as well as rising/falling edge
   101		 * modes, and the DT binding accommodates for that, but as long as
   102		 * other modes than high level mode are not used and can't be tested,
   103		 * they are rejected in this driver.
   104		 */
   105		if ((flow_type & IRQ_TYPE_SENSE_MASK) != IRQ_TYPE_LEVEL_HIGH)
   106			return -EINVAL;
   107	
   108		return 0;
   109	}
   110	
   111	static struct irq_chip wpcm450_aic_chip = {
   112		.name = "wpcm450-aic",
   113		.irq_eoi = wpcm450_aic_eoi,
   114		.irq_mask = wpcm450_aic_mask,
   115		.irq_unmask = wpcm450_aic_unmask,
   116		.irq_set_type = wpcm450_aic_set_type,
   117	};
   118	
   119	static int wpcm450_aic_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hwirq)
   120	{
   121		if (hwirq >= AIC_NUM_IRQS)
   122			return -EPERM;
   123	
   124		irq_set_chip_and_handler(irq, &wpcm450_aic_chip, handle_fasteoi_irq);
   125		irq_set_chip_data(irq, aic);
   126		irq_set_probe(irq);
   127	
   128		return 0;
   129	}
   130	
   131	static const struct irq_domain_ops wpcm450_aic_ops = {
   132		.map = wpcm450_aic_map,
   133		.xlate = irq_domain_xlate_twocell,
   134	};
   135	
   136	static int __init wpcm450_aic_of_init(struct device_node *node,
   137					      struct device_node *parent)
   138	{
   139		if (parent)
   140			return -EINVAL;
   141	
   142		aic = kzalloc(sizeof(*aic), GFP_KERNEL);
   143		if (!aic)
   144			return -ENOMEM;
   145	
   146		aic->regs = of_iomap(node, 0);
   147		if (!aic->regs) {
   148			pr_err("Failed to map WPCM450 AIC registers\n");
   149			return -ENOMEM;
   150		}
   151	
   152		wpcm450_aic_init_hw();
   153	
 > 154		set_handle_irq(wpcm450_aic_handle_irq);
   155	
   156		aic->domain = irq_domain_add_linear(node, AIC_NUM_IRQS, &wpcm450_aic_ops, aic);
   157	
   158		return 0;
   159	}
   160	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 63863 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210408/ef9ee608/attachment-0001.gz>

From l.stach at pengutronix.de  Wed Apr  7 23:13:06 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Thu, 08 Apr 2021 00:13:06 +0200
Subject: [PATCH v1 0/7] imx-gpcv2 improvements
In-Reply-To: <20210407212122.626137-1-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
Message-ID: <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>

Hi Adrien,

I feel like I already mentioned to you some time ago that there is
already a much more complete patch series to add this functionality on
the list [1].

If you want this functionality to go upstream, please help test and
extend this patch series.

Regards,
Lucas

[1] https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.stach at pengutronix.de/

Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> Hi,
> 
> This patch set aims is to add the support of the i.MX8 MM power domains
> on the mainline kernel.
> 
> To achieve this, I do several patches
> ??- Check errors when reading or writing registers (concerns i.MX8M base
> ????implementation);
> ??- Fix power up/down sequence. Handshake was not checked and it was
> ????not called at the appropriate time (concerns i.MX8M base
> implementaions);
> ??- Allow domains without power sequence control like the HSIOMIX of the
> ????i.MX8MM.
> ??- Add some i.MX8MM domains (HSIO and OTGS);
> ??- Introduce quirks. For example, i.MX8MM OTG domains should not be
> ????powered off (seen n the source code of th i.MX ATF). Quirks are
> easily upgrable for other cases.
> ??- Finally I defined power domains into the imx8mm.dtb file.
> 
> I know that this kind of patch is rejected by NXP ut the other way
> (callin ATF directly) was also rejected.
> 
> I also know that NXP is concerned abou adding hundred lines of codes for
> each new SOC but it' the way it works on Linux. And the "added code"
> mainly consist of adding structures, defines and generic methods for
> regmap.
> 
> If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> i.MX8MM, i.MX8MN and i.MX8MP.
> 
> Thanks,  
> 
> Adrien Grassein (7):
> ??soc: imx: gpcv2: check for errors when r/w registers
> ??soc: imx: gpcv2: Fix power up/down sequence
> ??soc: imx: gpcv2: allow domains without power sequence control
> ??dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> ??soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> ??soc: imx: gpcv2: add quirks to domains
> ??arm64: dts: imx8mm: add power-domains
> 
> ?.../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
> ?arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
> ?drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
> ?include/dt-bindings/power/imx8mm-power.h      |  21 ++
> ?4 files changed, 333 insertions(+), 66 deletions(-)
> ?create mode 100644 include/dt-bindings/power/imx8mm-power.h
> 




From fparent at baylibre.com  Wed Apr  7 23:14:50 2021
From: fparent at baylibre.com (Fabien Parent)
Date: Thu, 8 Apr 2021 00:14:50 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
In-Reply-To: <CAK8P3a37BUdHneO+9+t0Pan3UWZHub-ishcKLNxCbqO0kk0CNw@mail.gmail.com>
References: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
 <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>
 <01c82108-64a8-33ee-3984-5bd7056a0002@gmail.com>
 <CAK8P3a37BUdHneO+9+t0Pan3UWZHub-ishcKLNxCbqO0kk0CNw@mail.gmail.com>
Message-ID: <CAOwMV_yQLWwMEQ_f_wHOAipgD1qZgNz2SA2RJDZpNozCKv4vWQ@mail.gmail.com>

Hi Arnd,

On Wed, Apr 7, 2021 at 7:55 PM Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Wed, Apr 7, 2021 at 6:34 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> > On 07/04/2021 18:06, Arnd Bergmann wrote:
> > > On Wed, Apr 7, 2021 at 1:00 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> > >>
> > >> Hi Olof and Arnd,
> > >>
> > >> Here comes the second round of arm64 DT patches. Hope I'm not too late.
> > >> Basically we add several node to MT8167.
> > >> ----------------------------------------------------------------
> > >> Fabien Parent (6):
> > >
> > >>       arm64: dts: mediatek: mt8167: add some DRM nodes
> > >
> > > I stumbled over this patch adding a lot of aliases:
> > >
> > > +       aliases {
> > > +               aal0 = &aal;
> > > +               ccorr0 = &ccorr;
> > > +               color0 = &color;
> > > +               dither0 = &dither;
> > > +               dsi0 = &dsi;
> > > +               ovl0 = &ovl0;
> > > +               pwm0 = &disp_pwm;
> > > +               rdma0 = &rdma0;
> > > +               rdma1 = &rdma1;
> > > +               wdma0 = &wdma;
> > > +       };
> > >
> > >
> > > Something doesn't quite feel right about this, and I checked with Rob,
> > > who also thinks this looks wrong. I suppose we need to have a set of
> > > well documented alias types rather than just having drivers make up
> > > new ones on the spot.
> >
> > These are needed in the DRM driver, see drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> >
> > I added Chun-Kuang who is the maintainer of the driver. I think it's a good idea
> > to have this alias described in the binding. Maybe a good excuse to move to yaml
> > as well :)
>
> The aliases certainly need to be described in the binding, I think someone
> would likely have complained earlier if that was part of the binding.
>
> Moving it to yaml is also a good idea, and required for any new devices.
>
> > > I also noticed that some of the referenced nodes are missing a DT
> > > binding file, so those need to be added and reviewed as well.
> >
> > I suppose you are talking about "mediatek,mt8173-vcodec-enc-vp8". The binding
> > patches are in the media tree [1]. Maybe I supposed wrongly that they will land
> > in v5.13? Or perhaps I should have mentioned that in the pull request.
> >
> > If it wasn't about this compatible and you can still remember, please let me
> > know so that we can fix that :)
> >
> > I double checked and didn't find any missing binding. Some of them only have the
> > fallback binding described, maybe that's what you are referring to.
>
> Here is what I see for all compatible strings of the added device nodes in
> this patch, as of linux-next-20210407:
>
> $ for i in mediatek,mt8167-disp-mutex mediatek,mt8167-disp-rdma
> mediatek,mt2701-disp-rdma mediatek,mt8167-disp-pwm
> mediatek,mt8173-disp-pwn mediatek,mt8167-dsi mediatek,mt2701-dsi
> mediatek,mt8167-mipi-tx mediatek,mt2701-mipi-tx
> mediatek,mt8167-disp-ovl mediatek,mt8173-disp-ovl
> mediatek,mt8167-disp-rdma mediatek,mt2701-disp-rdma
> mediatek,mt8167-disp-color mediatek,mt8173-disp-color
> mediatek,mt8167-disp-ccorr mediatek,mt8183-disp-ccorr
> mediatek,mt8167-disp-aal mediatek,mt8167-disp-gamma
> mediatek,mt8173-disp-gamma mediatek,mt8167-disp-dither
> mediatek,mt8167-disp-wdma ; do echo === $i ;  git grep -wl $i
> Documentation/devicetree/ ; done
>
> === mediatek,mt8167-disp-mutex
> === mediatek,mt8167-disp-rdma
> === mediatek,mt2701-disp-rdma
> === mediatek,mt8167-disp-pwm
> Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> === mediatek,mt8173-disp-pwn
> === mediatek,mt8167-dsi
> === mediatek,mt2701-dsi
> === mediatek,mt8167-mipi-tx
> === mediatek,mt2701-mipi-tx
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> === mediatek,mt8167-disp-ovl
> === mediatek,mt8173-disp-ovl
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> === mediatek,mt8167-disp-rdma
> === mediatek,mt2701-disp-rdma
> === mediatek,mt8167-disp-color
> === mediatek,mt8173-disp-color
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> === mediatek,mt8167-disp-ccorr
> === mediatek,mt8183-disp-ccorr
> === mediatek,mt8167-disp-aal
> === mediatek,mt8167-disp-gamma
> === mediatek,mt8173-disp-gamma
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> === mediatek,mt8167-disp-dither
> === mediatek,mt8167-disp-wdma
>
> So five of the strings are documented, the others are missing. I did not check
> the other patches in your branch.

The binding documentation for these drivers are here [0]. The display
bindings are documented as:
- compatible: "mediatek,<chip>-disp-<function>", one of

The <chip> placeholder is never expanded for all the supported chips.
The 5 existings matches from your grep command comes from the example.
I guess these will be fixed whenever someone converts [0] to yaml.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt?h=v5.12-rc6#n29

>
>          Arnd


From aford173 at gmail.com  Thu Apr  8 00:03:41 2021
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 7 Apr 2021 18:03:41 -0500
Subject: [PATCH v1 0/7] imx-gpcv2 improvements
In-Reply-To: <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
 <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>
Message-ID: <CAHCN7xKePMS2F6sR6iRHrfdLET1Z2=zrXB=79K9HFdW+0VYAJg@mail.gmail.com>

On Wed, Apr 7, 2021 at 5:13 PM Lucas Stach <l.stach at pengutronix.de> wrote:
>
> Hi Adrien,
>
> I feel like I already mentioned to you some time ago that there is
> already a much more complete patch series to add this functionality on
> the list [1].
>
> If you want this functionality to go upstream, please help test and
> extend this patch series.
>
> Regards,
> Lucas
>
> [1] https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.stach at pengutronix.de/

I took Lucas' code and attempted to build upon it to add Nano support.
At some point, someone from NXP thought it would get really hard to
read if we started filling that file with every supported SoC.
To help with that, I created a patch to split the gpcv2 code into a
gcpv2 core functions  with the individual SoC's having separate files
to help keep things a little cleaner, and easier to read:
gpcv2-imx7, gpcv2-imx8mq, gpcv2-imx8mm, and gpcv2-imx8mn, etc.
I was holding off on doing anything with it, because the dt-bindings
appeared to be stalled, and the attempt by Lucas to get the basic
functionality was stalled.

As of right now, it seems like without any changes, I can not get my
Mini or Nano to wake from sleep unless I use a U-Boot and ATF based on
NXP's custom branches.  When using the custom branches, I made some
additional patches to the gpcv2 to add a flag which would prevent
disabling USB OTG on Mini and Nano which appeared to help waking from
sleep, and it matched some of what NXP's custom ATF was doing.

I know there has been some concern about using syscon address the
resets and enables, but I took some work Marek did, and added to it by
adding some flags to the structure which could take the syscon and
write different values to the blk-ctl register depending on whether or
not it was a Mini or Nano (and probably Plus).   Using some of these,
I was able to get the dispmix to come out of reset and enable the
LCDIF on both Mini and Nano, but for some reason, any attempts to
enable the mipi domain were causing failures in other domains, so I
strilpped them out again.  I've withheld posting any of these for the
same reasons I withheld my other patches.

As soon as Lucas' patch [1] above or something similar gets accepted,
can rebase and submit a few of the patches I have.

adam
>
> Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> > Hi,
> >
> > This patch set aims is to add the support of the i.MX8 MM power domains
> > on the mainline kernel.
> >
> > To achieve this, I do several patches
> >   - Check errors when reading or writing registers (concerns i.MX8M base
> >     implementation);
> >   - Fix power up/down sequence. Handshake was not checked and it was
> >     not called at the appropriate time (concerns i.MX8M base
> > implementaions);
> >   - Allow domains without power sequence control like the HSIOMIX of the
> >     i.MX8MM.
> >   - Add some i.MX8MM domains (HSIO and OTGS);
> >   - Introduce quirks. For example, i.MX8MM OTG domains should not be
> >     powered off (seen n the source code of th i.MX ATF). Quirks are
> > easily upgrable for other cases.
> >   - Finally I defined power domains into the imx8mm.dtb file.
> >
> > I know that this kind of patch is rejected by NXP ut the other way
> > (callin ATF directly) was also rejected.
> >
> > I also know that NXP is concerned abou adding hundred lines of codes for
> > each new SOC but it' the way it works on Linux. And the "added code"
> > mainly consist of adding structures, defines and generic methods for
> > regmap.
> >
> > If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> > i.MX8MM, i.MX8MN and i.MX8MP.
> >
> > Thanks,
> >
> > Adrien Grassein (7):
> >   soc: imx: gpcv2: check for errors when r/w registers
> >   soc: imx: gpcv2: Fix power up/down sequence
> >   soc: imx: gpcv2: allow domains without power sequence control
> >   dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> >   soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> >   soc: imx: gpcv2: add quirks to domains
> >   arm64: dts: imx8mm: add power-domains
> >
> >  .../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
> >  drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
> >  include/dt-bindings/power/imx8mm-power.h      |  21 ++
> >  4 files changed, 333 insertions(+), 66 deletions(-)
> >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >
>
>


From nobuhiro1.iwamatsu at toshiba.co.jp  Thu Apr  8 00:15:48 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Thu, 8 Apr 2021 08:15:48 +0900
Subject: [PATCH v2 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210212164144.wcvy7jkxmrysqxux@pengutronix.de>
References: <20210212131910.557581-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212131910.557581-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212164144.wcvy7jkxmrysqxux@pengutronix.de>
Message-ID: <20210407231548.4paov2fb33cpxxui@toshiba.co.jp>

Hi,

Thanks for your review.

On Fri, Feb 12, 2021 at 05:41:44PM +0100, Uwe Kleine-K?nig wrote:
> Hello Nobuhiro,
> 
> On Fri, Feb 12, 2021 at 10:19:10PM +0900, Nobuhiro Iwamatsu wrote:
> > Add driver for the PWM controller on Toshiba Visconti ARM SoC.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > ---
> >  drivers/pwm/Kconfig        |   9 ++
> >  drivers/pwm/Makefile       |   1 +
> >  drivers/pwm/pwm-visconti.c | 173 +++++++++++++++++++++++++++++++++++++
> >  3 files changed, 183 insertions(+)
> >  create mode 100644 drivers/pwm/pwm-visconti.c
> > 

<snip>

> > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > new file mode 100644
> > index 000000000000..2aa140f1ec04
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-visconti.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Toshiba Visconti pulse-width-modulation controller driver
> > + *
> > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > + *
> > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > + *
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/pwm.h>
> > +#include <linux/platform_device.h>
> > +
> > +
> > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > +
> > +#define PIPGM_PWMC_PWMACT		BIT(5)
> > +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> > +#define PIPGM_PWMC_POLARITY_MASK	GENMASK(5, 5)
> > +#define PIPGM_PDUT_MAX			0xFFFF
> > +
> > +struct visconti_pwm_chip {
> > +	struct pwm_chip chip;
> > +	void __iomem *base;
> > +};
> > +
> > +#define to_visconti_chip(chip) \
> > +	container_of(chip, struct visconti_pwm_chip, chip)
> > +
> > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > +			  const struct pwm_state *state)
> 
> Please align the continuation line to the opening parenthesis.
> 

I will fix this. 

> > +{
> > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > +	u32 period, duty, pwmc0;
> > +
> > +	dev_dbg(chip->dev, "%s: ch = %d en = %d p = 0x%llx d = 0x%llx\n", __func__,
> > +		pwm->hwpwm, state->enabled, state->period, state->duty_cycle);
> > +
> > +	/*
> > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > +	 * way the hardware switches atomically from the old setting to the new.
> > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > +	 * at low level at all times.
> 
> Did you just copy my optimal description or is your hardware really that
> nice?

Yes, this hardware works as you wrote.
And I added about the state if the sinnal when this hardware disabled.

> 
> Do you know scripts/checkpatch.pl? I bet it will tell you to limit your
> lines to approx. 80 chars where sensible.

Yes, I know. I ran scripts/checkpatch.pl before send patch.
I understand that the number of characters per line has been changed to
100 characters. Does the pwm driver recommend 80 characters?

> 
> > +	 */
> > +	if (!state->enabled) {
> > +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +		return 0;
> > +	}
> > +
> > +	period = state->period / NSEC_PER_USEC;
> 
> This becomes wrong if state->period > 1000 * 0xffffffff because you
> discard non-zero bits when reducing the size to u32.

Your point is correct. I will fix this.

> 
> > +	duty = state->duty_cycle / NSEC_PER_USEC;
> > +	if (period < 0x10000)
> > +		pwmc0 = 0;
> > +	else if (period < 0x20000)
> > +		pwmc0 = 1;
> > +	else if (period < 0x40000)
> > +		pwmc0 = 2;
> > +	else if (period < 0x80000)
> > +		pwmc0 = 3;
> > +	else
> > +		return -EINVAL;
> 
> This is equivalent to:
> 
> 	pwmc0 = ilog2(period >> 16);
> 	if (pwmc0 > 3)
> 		return -EINVAL;
> 

I see. And I noticed that there was a problem with the above code.
I will use ilog2.

> > +	if (duty > PIPGM_PDUT_MAX)
> > +		return -EINVAL;
> 
> I would expect that this check should only happen after duty is shifted
> below?! I think this cannot happen if you rely on the core to only give
> you states with duty_cycle <= period.

I see. I will fix this.

> 
> > +	period >>= pwmc0;
> > +	duty >>= pwmc0;
> > +
> > +	if (state->polarity == PWM_POLARITY_INVERSED)
> > +		pwmc0 |= PIPGM_PWMC_PWMACT;
> > +
> > +	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> > +	writel(duty, priv->base + PIPGM_PDUT(pwm->hwpwm));
> > +	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> 
> Please implement the following policy:
> 
> Pick the biggest possible period not bigger than the requested period.
> With that pick the biggest possible duty cycle not bigger than the
> requested duty cycle. That means (assuming I understood your hardware
> correctly):
> 
> 	u32 period, duty_cycle;
> 
> 	/*
> 	 * The biggest period the hardware can provide is
> 	 * 	(0xffff << 3) * 1000 ns
> 	 * This value fits easily in an u32, so simplify the maths by
> 	 * capping the values to 32 bit integers.
> 	 */
> 	if (state->period > (0xffff << 3) * 1000)
> 		period = (0xffff << 3) * 1000;
> 	else
> 		period = state->period;
> 
> 	if (state->duty_cycle > period)
> 		duty_cycle = period;
> 	else
> 		duty_cycle = state->duty_cycle;
> 
> 	/*
> 	 * The input clock runs fixed at 1 MHz, so we have only
> 	 * microsecond resolution and so can divide by
> 	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
> 	 */
> 	period /= 1000;
> 	duty_cycle /= 1000;
> 
> 	if (!period)
> 		/* period too small */
> 		return -ERANGE;
> 
> 	/*
> 	 * PWMC controls a divider that divides the input clk by a
> 	 * power of two between 1 and 8. As a smaller divider yields
> 	 * higher precision, pick the smallest possible one.
> 	 */
> 	pwmc0 = ilog2(period >> 16);
> 	BUG_ON(pwmc0 > 3);
> 
> 	period >>= pwmc0;
> 	duty_cycle >>= pwmc0;
> 	
> 	if (state->polarity == PWM_POLARITY_INVERSED)
> 		pwmc0 |= PIPGM_PWMC_PWMACT;
> 			
> 	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> 	writel(duty, priv->base + PIPGM_PDUT(pwm->hwpwm));
> 	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> 

Thank you for your suggestion. I will reconsider based on this code.

> > +	return 0;
> > +}
> > +
> > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > +				   struct pwm_state *state)
> > +{
> > +[...]
> > +}
> 
> Looks good.
> 
> > [...]
> > 
> > +static struct platform_driver visconti_pwm_driver = {
> > +	.driver = {
> > +		.name = "pwm-visconti",
> > +		.of_match_table = visconti_pwm_of_match,
> > +	},
> > +	.probe = visconti_pwm_probe,
> > +	.remove = visconti_pwm_remove,
> > +};
> > +module_platform_driver(visconti_pwm_driver);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>");
> > +MODULE_ALIAS("platform:visconti-pwm");
> 
> This must match the .name field of the platform driver, so it must be
> 
> MODULE_ALIAS("platform:pwm-visconti");

I forgot this mistake. I will fix.

> 
> Best regards
> Uwe

Best regards,
  Nobuhiro


From sfr at canb.auug.org.au  Thu Apr  8 00:56:12 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 8 Apr 2021 09:56:12 +1000
Subject: linux-next: build warning after merge of the mvebu tree
Message-ID: <20210408095612.71e8c56e@canb.auug.org.au>

Hi all,

After merging the mvebu tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

arch/arm/boot/dts/armada-385-atl-x530.dts:171.14-199.4: Warning (spi_bus_reg): /soc/spi at 10680/spi-flash at 0: SPI bus unit address format error, expected "1"

Introduced by commit

  c6dfc019c239 ("ARM: dts: mvebu: Add device tree for ATL-x530 Board")

-- 
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/20210408/bc49a133/attachment.sig>

From jsavitz at redhat.com  Thu Apr  8 01:03:53 2021
From: jsavitz at redhat.com (Joel Savitz)
Date: Wed,  7 Apr 2021 20:03:53 -0400
Subject: [RFC PATCH] drivers: Raspbery Pi Sense Hat
Message-ID: <20210408000353.3571132-1-jsavitz@redhat.com>

From: Joel Savitz <joelsavitz at gmail.com>

This is a forward port of the Rapsberry Pi Sense Hat driver from the
downstream Raspberry Pi kernel tree.

I have slightly consolidated things and done some quick testing of this
driver on Fedora (which comes with the device tree blobs), and I want to
do a bit more testing before submiting the driver for inclusion in
mainline Linux.

I would like to get some feedback from the community on what may need to
be improved, fixed, or changed as early as possible, so this is a request
for comments.

Signed-off-by: Joel Savitz <joelsavitz at gmail.com>
---
 drivers/input/joystick/Kconfig       |   8 +
 drivers/input/joystick/Makefile      |   1 +
 drivers/input/joystick/rpisense-js.c | 147 ++++++++++++++
 drivers/mfd/Kconfig                  |   8 +
 drivers/mfd/Makefile                 |   1 +
 drivers/mfd/rpisense-core.c          | 162 +++++++++++++++
 drivers/video/fbdev/Kconfig          |  13 ++
 drivers/video/fbdev/Makefile         |   1 +
 drivers/video/fbdev/rpisense-fb.c    | 291 +++++++++++++++++++++++++++
 include/linux/mfd/rpisense.h         |  66 ++++++
 10 files changed, 698 insertions(+)
 create mode 100644 drivers/input/joystick/rpisense-js.c
 create mode 100644 drivers/mfd/rpisense-core.c
 create mode 100644 drivers/video/fbdev/rpisense-fb.c
 create mode 100644 include/linux/mfd/rpisense.h

diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 5e38899058c1..1c0025c22bf4 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -389,4 +389,12 @@ config JOYSTICK_N64
 	  Say Y here if you want enable support for the four
 	  built-in controller ports on the Nintendo 64 console.
 
+config JOYSTICK_RPISENSE
+	tristate "Raspberry Pi Sense HAT joystick"
+	depends on GPIOLIB && INPUT
+	select MFD_RPISENSE_CORE
+
+	help
+	  This is the joystick driver for the Raspberry Pi Sense HAT
+
 endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 31d720c9e493..b227e98cd179 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_JOYSTICK_MAPLE)		+= maplecontrol.o
 obj-$(CONFIG_JOYSTICK_N64)		+= n64joy.o
 obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)	+= psxpad-spi.o
 obj-$(CONFIG_JOYSTICK_PXRC)		+= pxrc.o
+obj-$(CONFIG_JOYSTICK_RPISENSE)         += rpisense-js.o
 obj-$(CONFIG_JOYSTICK_SIDEWINDER)	+= sidewinder.o
 obj-$(CONFIG_JOYSTICK_SPACEBALL)	+= spaceball.o
 obj-$(CONFIG_JOYSTICK_SPACEORB)		+= spaceorb.o
diff --git a/drivers/input/joystick/rpisense-js.c b/drivers/input/joystick/rpisense-js.c
new file mode 100644
index 000000000000..41d4bd1fed46
--- /dev/null
+++ b/drivers/input/joystick/rpisense-js.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Raspberry Pi Sense HAT joystick driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ *
+ * Author: Serge Schneider
+ * Adapted for mainline Linux by: Joel Savitz
+ */
+
+#include <linux/module.h>
+#include <linux/mfd/rpisense.h>
+
+static struct rpisense *rpisense;
+static unsigned char keymap[5] = {KEY_DOWN, KEY_RIGHT, KEY_UP, KEY_ENTER, KEY_LEFT,};
+
+static void keys_work_fn(struct work_struct *work)
+{
+	int i;
+	static s32 prev_keys;
+	struct rpisense_js *rpisense_js = &rpisense->joystick;
+	s32 keys = rpisense_reg_read(rpisense, RPISENSE_KEYS);
+	s32 changes = keys ^ prev_keys;
+
+	prev_keys = keys;
+	for (i = 0; i < 5; i++) {
+		if (changes & 1) {
+			input_report_key(rpisense_js->keys_dev,
+					 keymap[i], keys & 1);
+		}
+		changes >>= 1;
+		keys >>= 1;
+	}
+	input_sync(rpisense_js->keys_dev);
+}
+
+static irqreturn_t keys_irq_handler(int irq, void *pdev)
+{
+	struct rpisense_js *rpisense_js = &rpisense->joystick;
+
+	schedule_work(&rpisense_js->keys_work_s);
+	return IRQ_HANDLED;
+}
+
+static int rpisense_js_probe(struct platform_device *pdev)
+{
+	int ret;
+	int i;
+	struct rpisense_js *rpisense_js;
+
+	rpisense = rpisense_get_dev();
+	rpisense_js = &rpisense->joystick;
+
+	INIT_WORK(&rpisense_js->keys_work_s, keys_work_fn);
+
+	rpisense_js->keys_dev = input_allocate_device();
+	if (!rpisense_js->keys_dev) {
+		dev_err(&pdev->dev, "Could not allocate input device.\n");
+		return -ENOMEM;
+	}
+
+	rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY);
+	for (i = 0; i < ARRAY_SIZE(keymap); i++) {
+		set_bit(keymap[i],
+			rpisense_js->keys_dev->keybit);
+	}
+
+	rpisense_js->keys_dev->name = "Raspberry Pi Sense HAT Joystick";
+	rpisense_js->keys_dev->phys = "rpi-sense-joy/input0";
+	rpisense_js->keys_dev->id.bustype = BUS_I2C;
+	rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
+	rpisense_js->keys_dev->keycode = keymap;
+	rpisense_js->keys_dev->keycodesize = sizeof(unsigned char);
+	rpisense_js->keys_dev->keycodemax = ARRAY_SIZE(keymap);
+
+	ret = input_register_device(rpisense_js->keys_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Could not register input device.\n");
+		goto err_keys_alloc;
+	}
+
+	ret = gpiod_direction_input(rpisense_js->keys_desc);
+	if (ret) {
+		dev_err(&pdev->dev, "Could not set keys-int direction.\n");
+		goto err_keys_reg;
+	}
+
+	rpisense_js->keys_irq = gpiod_to_irq(rpisense_js->keys_desc);
+	if (rpisense_js->keys_irq < 0) {
+		dev_err(&pdev->dev, "Could not determine keys-int IRQ.\n");
+		ret = rpisense_js->keys_irq;
+		goto err_keys_reg;
+	}
+
+	ret = devm_request_irq(&pdev->dev, rpisense_js->keys_irq,
+			       keys_irq_handler, IRQF_TRIGGER_RISING,
+			       "keys", &pdev->dev);
+	if (ret) {
+		dev_err(&pdev->dev, "IRQ request failed.\n");
+		goto err_keys_reg;
+	}
+	return 0;
+err_keys_reg:
+	input_unregister_device(rpisense_js->keys_dev);
+err_keys_alloc:
+	input_free_device(rpisense_js->keys_dev);
+	return ret;
+}
+
+static int rpisense_js_remove(struct platform_device *pdev)
+{
+	struct rpisense_js *rpisense_js = &rpisense->joystick;
+
+	input_unregister_device(rpisense_js->keys_dev);
+	input_free_device(rpisense_js->keys_dev);
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id rpisense_js_id[] = {
+	{ .compatible = "raspberrypi,rpi-sense-js" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rpisense_js_id);
+#endif
+
+static struct platform_device_id rpisense_js_device_id[] = {
+	{ .name = "rpi-sense-js" },
+	{ },
+};
+MODULE_DEVICE_TABLE(platform, rpisense_js_device_id);
+
+static struct platform_driver rpisense_js_driver = {
+	.probe = rpisense_js_probe,
+	.remove = rpisense_js_remove,
+	.driver = {
+		.name = "rpi-sense-js",
+		.owner = THIS_MODULE,
+	},
+};
+
+module_platform_driver(rpisense_js_driver);
+
+MODULE_DESCRIPTION("Raspberry Pi Sense HAT joystick driver");
+MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b74efa469e90..8c309e389359 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -11,6 +11,14 @@ config MFD_CORE
 	select IRQ_DOMAIN
 	default n
 
+config MFD_RPISENSE_CORE
+	tristate "Raspberry Pi Sense HAT core functions"
+	depends on I2C
+	select MFD_CORE
+	help
+	  This is the core driver for the Raspberry Pi Sense HAT. This provides
+	  the necessary functions to communicate with the hardware.
+
 config MFD_CS5535
 	tristate "AMD CS5535 and CS5536 southbridge core functions"
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 834f5463af28..7140a8fc36ee 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -263,6 +263,7 @@ obj-$(CONFIG_MFD_ROHM_BD71828)	+= rohm-bd71828.o
 obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
 obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
 obj-$(CONFIG_MFD_KHADAS_MCU) 	+= khadas-mcu.o
+obj-$(CONFIG_MFD_RPISENSE_CORE) += rpisense-core.o
 obj-$(CONFIG_MFD_ACER_A500_EC)	+= acer-ec-a500.o
 
 obj-$(CONFIG_SGI_MFD_IOC3)	+= ioc3.o
diff --git a/drivers/mfd/rpisense-core.c b/drivers/mfd/rpisense-core.c
new file mode 100644
index 000000000000..aa2c394c5e67
--- /dev/null
+++ b/drivers/mfd/rpisense-core.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Raspberry Pi Sense HAT core driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ *
+ * Author: Serge Schneider
+ * Adapted for mainline Linux by: Joel Savitz
+ *
+ *  This driver is based on wm8350 implementation.
+ */
+
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/slab.h>
+
+#include <linux/mfd/rpisense.h>
+
+static struct rpisense *rpisense;
+
+static void rpisense_client_dev_register(struct rpisense *rpisense,
+					 const char *name,
+					 struct platform_device **pdev)
+{
+	int ret;
+
+	*pdev = platform_device_alloc(name, -1);
+	if (*pdev == NULL) {
+		dev_err(rpisense->dev, "Failed to allocate %s\n", name);
+		return;
+	}
+
+	(*pdev)->dev.parent = rpisense->dev;
+	platform_set_drvdata(*pdev, rpisense);
+	ret = platform_device_add(*pdev);
+	if (ret != 0) {
+		dev_err(rpisense->dev, "Failed to register %s: %d\n",
+			name, ret);
+		platform_device_put(*pdev);
+		*pdev = NULL;
+	}
+}
+
+static int rpisense_probe(struct i2c_client *i2c,
+			       const struct i2c_device_id *id)
+{
+	int ret;
+	struct rpisense_js *rpisense_js;
+
+	rpisense = devm_kzalloc(&i2c->dev, sizeof(struct rpisense), GFP_KERNEL);
+	if (rpisense == NULL)
+		return -ENOMEM;
+
+	i2c_set_clientdata(i2c, rpisense);
+	rpisense->dev = &i2c->dev;
+	rpisense->i2c_client = i2c;
+
+	ret = rpisense_reg_read(rpisense, RPISENSE_WAI);
+	if (ret > 0) {
+		if (ret != 's')
+			return -EINVAL;
+	} else {
+		return ret;
+	}
+	ret = rpisense_reg_read(rpisense, RPISENSE_VER);
+	if (ret < 0)
+		return ret;
+
+	dev_info(rpisense->dev,
+		 "Raspberry Pi Sense HAT firmware version %i\n", ret);
+
+	rpisense_js = &rpisense->joystick;
+	rpisense_js->keys_desc = devm_gpiod_get(&i2c->dev,
+						"keys-int", GPIOD_IN);
+	if (IS_ERR(rpisense_js->keys_desc)) {
+		dev_warn(&i2c->dev, "Failed to get keys-int descriptor.\n");
+		rpisense_js->keys_desc = gpio_to_desc(23);
+		if (rpisense_js->keys_desc == NULL) {
+			dev_err(&i2c->dev, "GPIO23 fallback failed.\n");
+			return PTR_ERR(rpisense_js->keys_desc);
+		}
+	}
+	rpisense_client_dev_register(rpisense, "rpi-sense-js",
+				     &(rpisense->joystick.pdev));
+	rpisense_client_dev_register(rpisense, "rpi-sense-fb",
+				     &(rpisense->framebuffer.pdev));
+
+	return 0;
+}
+
+static int rpisense_remove(struct i2c_client *i2c)
+{
+	struct rpisense *rpisense = i2c_get_clientdata(i2c);
+
+	platform_device_unregister(rpisense->joystick.pdev);
+	return 0;
+}
+
+struct rpisense *rpisense_get_dev(void)
+{
+	return rpisense;
+}
+EXPORT_SYMBOL_GPL(rpisense_get_dev);
+
+s32 rpisense_reg_read(struct rpisense *rpisense, int reg)
+{
+	int ret = i2c_smbus_read_byte_data(rpisense->i2c_client, reg);
+
+	if (ret < 0)
+		dev_err(rpisense->dev, "Read from reg %d failed\n", reg);
+	/* Due to the BCM270x I2C clock stretching bug, some values
+	 * may have MSB set. Clear it to avoid incorrect values.
+	 */
+	return ret & 0x7F;
+}
+EXPORT_SYMBOL_GPL(rpisense_reg_read);
+
+int rpisense_block_write(struct rpisense *rpisense, const char *buf, int count)
+{
+	int ret = i2c_master_send(rpisense->i2c_client, buf, count);
+
+	if (ret < 0)
+		dev_err(rpisense->dev, "Block write failed\n");
+	return ret;
+}
+EXPORT_SYMBOL_GPL(rpisense_block_write);
+
+static const struct i2c_device_id rpisense_i2c_id[] = {
+	{ "rpi-sense", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, rpisense_i2c_id);
+
+#ifdef CONFIG_OF
+static const struct of_device_id rpisense_core_id[] = {
+	{ .compatible = "raspberrypi,rpi-sense" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rpisense_core_id);
+#endif
+
+
+static struct i2c_driver rpisense_driver = {
+	.driver = {
+		   .name = "rpi-sense",
+		   .owner = THIS_MODULE,
+	},
+	.probe = rpisense_probe,
+	.remove = rpisense_remove,
+	.id_table = rpisense_i2c_id,
+};
+
+module_i2c_driver(rpisense_driver);
+
+MODULE_DESCRIPTION("Raspberry Pi Sense HAT core driver");
+MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
+MODULE_LICENSE("GPL");
+
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4f02db65dede..2238e36e71e4 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2236,6 +2236,19 @@ config FB_SM712
 	  called sm712fb. If you want to compile it as a module, say M
 	  here and read <file:Documentation/kbuild/modules.rst>.
 
+config FB_RPISENSE
+        tristate "Raspberry Pi Sense HAT framebuffer"
+        depends on FB
+        select MFD_RPISENSE_CORE
+        select FB_SYS_FOPS
+        select FB_SYS_FILLRECT
+        select FB_SYS_COPYAREA
+        select FB_SYS_IMAGEBLIT
+        select FB_DEFERRED_IO
+
+        help
+          This is the framebuffer driver for the Raspberry Pi Sense HAT
+
 source "drivers/video/fbdev/omap/Kconfig"
 source "drivers/video/fbdev/omap2/Kconfig"
 source "drivers/video/fbdev/mmp/Kconfig"
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 477b9624b703..5b17203b7e43 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_FB_MX3)		  += mx3fb.o
 obj-$(CONFIG_FB_DA8XX)		  += da8xx-fb.o
 obj-$(CONFIG_FB_SSD1307)	  += ssd1307fb.o
 obj-$(CONFIG_FB_SIMPLE)           += simplefb.o
+obj-$(CONFIG_FB_RPISENSE)         += rpisense-fb.o
 
 # the test framebuffer is last
 obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
diff --git a/drivers/video/fbdev/rpisense-fb.c b/drivers/video/fbdev/rpisense-fb.c
new file mode 100644
index 000000000000..a90a5ec51fd7
--- /dev/null
+++ b/drivers/video/fbdev/rpisense-fb.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Raspberry Pi Sense HAT framebuffer driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ *
+ * Author: Serge Schneider
+ * Adapted for mainline Linux by: Joel Savitz
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+
+#include <linux/mfd/rpisense.h>
+
+static bool lowlight;
+module_param(lowlight, bool, 0);
+MODULE_PARM_DESC(lowlight, "Reduce LED matrix brightness to one third");
+
+static struct rpisense *rpisense;
+
+struct rpisense_fb_param {
+	char __iomem *vmem;
+	u8 *vmem_work;
+	u32 vmemsize;
+	u8 *gamma;
+};
+
+static u8 gamma_default[32] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01,
+			       0x02, 0x02, 0x03, 0x03, 0x04, 0x05, 0x06, 0x07,
+			       0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0E, 0x0F, 0x11,
+			       0x12, 0x14, 0x15, 0x17, 0x19, 0x1B, 0x1D, 0x1F,};
+
+static u8 gamma_low[32] = {0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+			   0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x02, 0x02,
+			   0x03, 0x03, 0x03, 0x04, 0x04, 0x05, 0x05, 0x06,
+			   0x06, 0x07, 0x07, 0x08, 0x08, 0x09, 0x0A, 0x0A,};
+
+static u8 gamma_user[32];
+
+static u32 pseudo_palette[16];
+
+static struct rpisense_fb_param rpisense_fb_param = {
+	.vmem = NULL,
+	.vmemsize = 128,
+	.gamma = gamma_default,
+};
+
+static struct fb_deferred_io rpisense_fb_defio;
+
+static struct fb_fix_screeninfo rpisense_fb_fix = {
+	.id =		"RPi-Sense FB",
+	.type =		FB_TYPE_PACKED_PIXELS,
+	.visual =	FB_VISUAL_TRUECOLOR,
+	.xpanstep =	0,
+	.ypanstep =	0,
+	.ywrapstep =	0,
+	.accel =	FB_ACCEL_NONE,
+	.line_length =	16,
+};
+
+static struct fb_var_screeninfo rpisense_fb_var = {
+	.xres		= 8,
+	.yres		= 8,
+	.xres_virtual	= 8,
+	.yres_virtual	= 8,
+	.bits_per_pixel = 16,
+	.red		= {11, 5, 0},
+	.green		= {5, 6, 0},
+	.blue		= {0, 5, 0},
+};
+
+static ssize_t rpisense_fb_write(struct fb_info *info,
+				 const char __user *buf, size_t count,
+				 loff_t *ppos)
+{
+	ssize_t res = fb_sys_write(info, buf, count, ppos);
+
+	schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
+	return res;
+}
+
+static void rpisense_fb_fillrect(struct fb_info *info,
+				 const struct fb_fillrect *rect)
+{
+	sys_fillrect(info, rect);
+	schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
+}
+
+static void rpisense_fb_copyarea(struct fb_info *info,
+				 const struct fb_copyarea *area)
+{
+	sys_copyarea(info, area);
+	schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
+}
+
+static void rpisense_fb_imageblit(struct fb_info *info,
+				  const struct fb_image *image)
+{
+	sys_imageblit(info, image);
+	schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
+}
+
+static void rpisense_fb_deferred_io(struct fb_info *info,
+				struct list_head *pagelist)
+{
+	int i;
+	int j;
+	u8 *vmem_work = rpisense_fb_param.vmem_work;
+	u16 *mem = (u16 *)rpisense_fb_param.vmem;
+	u8 *gamma = rpisense_fb_param.gamma;
+
+	vmem_work[0] = 0;
+	for (j = 0; j < 8; j++) {
+		for (i = 0; i < 8; i++) {
+			vmem_work[(j * 24) + i + 1] =
+				gamma[(mem[(j * 8) + i] >> 11) & 0x1F];
+			vmem_work[(j * 24) + (i + 8) + 1] =
+				gamma[(mem[(j * 8) + i] >> 6) & 0x1F];
+			vmem_work[(j * 24) + (i + 16) + 1] =
+				gamma[(mem[(j * 8) + i]) & 0x1F];
+		}
+	}
+	rpisense_block_write(rpisense, vmem_work, 193);
+}
+
+static struct fb_deferred_io rpisense_fb_defio = {
+	.delay		= HZ/100,
+	.deferred_io	= rpisense_fb_deferred_io,
+};
+
+static int rpisense_fb_ioctl(struct fb_info *info, unsigned int cmd,
+			     unsigned long arg)
+{
+	switch (cmd) {
+	case SENSEFB_FBIOGET_GAMMA:
+		if (copy_to_user((void __user *) arg, rpisense_fb_param.gamma,
+				 sizeof(u8[32])))
+			return -EFAULT;
+		return 0;
+	case SENSEFB_FBIOSET_GAMMA:
+		if (copy_from_user(gamma_user, (void __user *)arg,
+				   sizeof(u8[32])))
+			return -EFAULT;
+		rpisense_fb_param.gamma = gamma_user;
+		schedule_delayed_work(&info->deferred_work,
+				      rpisense_fb_defio.delay);
+		return 0;
+	case SENSEFB_FBIORESET_GAMMA:
+		switch (arg) {
+		case 0:
+			rpisense_fb_param.gamma = gamma_default;
+			break;
+		case 1:
+			rpisense_fb_param.gamma = gamma_low;
+			break;
+		case 2:
+			rpisense_fb_param.gamma = gamma_user;
+			break;
+		default:
+			return -EINVAL;
+		}
+		schedule_delayed_work(&info->deferred_work,
+				      rpisense_fb_defio.delay);
+		break;
+	default:
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static struct fb_ops rpisense_fb_ops = {
+	.owner		= THIS_MODULE,
+	.fb_read	= fb_sys_read,
+	.fb_write	= rpisense_fb_write,
+	.fb_fillrect	= rpisense_fb_fillrect,
+	.fb_copyarea	= rpisense_fb_copyarea,
+	.fb_imageblit	= rpisense_fb_imageblit,
+	.fb_ioctl	= rpisense_fb_ioctl,
+};
+
+static int rpisense_fb_probe(struct platform_device *pdev)
+{
+	struct fb_info *info;
+	int ret = -ENOMEM;
+	struct rpisense_fb *rpisense_fb;
+
+	rpisense = rpisense_get_dev();
+	rpisense_fb = &rpisense->framebuffer;
+
+	rpisense_fb_param.vmem = vzalloc(rpisense_fb_param.vmemsize);
+	if (!rpisense_fb_param.vmem)
+		return ret;
+
+	rpisense_fb_param.vmem_work = devm_kmalloc(&pdev->dev, 193, GFP_KERNEL);
+	if (!rpisense_fb_param.vmem_work)
+		goto err_malloc;
+
+	info = framebuffer_alloc(0, &pdev->dev);
+	if (!info) {
+		dev_err(&pdev->dev, "Could not allocate framebuffer.\n");
+		goto err_malloc;
+	}
+	rpisense_fb->info = info;
+
+	rpisense_fb_fix.smem_start = (unsigned long)rpisense_fb_param.vmem;
+	rpisense_fb_fix.smem_len = rpisense_fb_param.vmemsize;
+
+	info->fbops = &rpisense_fb_ops;
+	info->fix = rpisense_fb_fix;
+	info->var = rpisense_fb_var;
+	info->fbdefio = &rpisense_fb_defio;
+	info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB;
+	info->screen_base = rpisense_fb_param.vmem;
+	info->screen_size = rpisense_fb_param.vmemsize;
+	info->pseudo_palette = pseudo_palette;
+
+	if (lowlight)
+		rpisense_fb_param.gamma = gamma_low;
+
+	fb_deferred_io_init(info);
+
+	ret = register_framebuffer(info);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Could not register framebuffer.\n");
+		goto err_fballoc;
+	}
+
+	fb_info(info, "%s frame buffer device\n", info->fix.id);
+	schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
+	return 0;
+err_fballoc:
+	framebuffer_release(info);
+err_malloc:
+	vfree(rpisense_fb_param.vmem);
+	return ret;
+}
+
+static int rpisense_fb_remove(struct platform_device *pdev)
+{
+	struct rpisense_fb *rpisense_fb = &rpisense->framebuffer;
+	struct fb_info *info = rpisense_fb->info;
+
+	if (info) {
+		unregister_framebuffer(info);
+		fb_deferred_io_cleanup(info);
+		framebuffer_release(info);
+		vfree(rpisense_fb_param.vmem);
+	}
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id rpisense_fb_id[] = {
+	{ .compatible = "raspberrypi,rpi-sense-fb" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, rpisense_fb_id);
+#endif
+
+static struct platform_device_id rpisense_fb_device_id[] = {
+	{ .name = "rpi-sense-fb" },
+	{ },
+};
+MODULE_DEVICE_TABLE(platform, rpisense_fb_device_id);
+
+static struct platform_driver rpisense_fb_driver = {
+	.probe = rpisense_fb_probe,
+	.remove = rpisense_fb_remove,
+	.driver = {
+		.name = "rpi-sense-fb",
+		.owner = THIS_MODULE,
+	},
+};
+
+module_platform_driver(rpisense_fb_driver);
+
+MODULE_DESCRIPTION("Raspberry Pi Sense HAT framebuffer driver");
+MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
+MODULE_LICENSE("GPL");
+
diff --git a/include/linux/mfd/rpisense.h b/include/linux/mfd/rpisense.h
new file mode 100644
index 000000000000..0718b6f0eddb
--- /dev/null
+++ b/include/linux/mfd/rpisense.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Raspberry Pi Sense HAT core driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ *
+ * Author: Serge Schneider
+ * Adapted for mainline Linux by: Joel Savitz
+ */
+
+#ifndef __LINUX_MFD_RPISENSE_CORE_H_
+#define __LINUX_MFD_RPISENSE_CORE_H_
+
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/gpio/consumer.h>
+#include <linux/platform_device.h>
+
+/*
+ * Register values.
+ */
+#define RPISENSE_FB			0x00
+#define RPISENSE_WAI			0xF0
+#define RPISENSE_VER			0xF1
+#define RPISENSE_KEYS			0xF2
+#define RPISENSE_EE_WP			0xF3
+
+#define RPISENSE_ID			's'
+
+#define SENSEFB_FBIO_IOC_MAGIC 0xF1
+
+#define SENSEFB_FBIOGET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 0)
+#define SENSEFB_FBIOSET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 1)
+#define SENSEFB_FBIORESET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 2)
+
+struct rpisense_fb {
+	struct platform_device *pdev;
+	struct fb_info *info;
+};
+
+
+struct rpisense_js {
+	struct platform_device *pdev;
+	struct input_dev *keys_dev;
+	struct gpio_desc *keys_desc;
+	struct work_struct keys_work_s;
+	int keys_irq;
+};
+
+
+struct rpisense {
+	struct device *dev;
+	struct i2c_client *i2c_client;
+
+	/* Client devices */
+	struct rpisense_js joystick;
+	struct rpisense_fb framebuffer;
+};
+
+struct rpisense *rpisense_get_dev(void);
+s32 rpisense_reg_read(struct rpisense *rpisense, int reg);
+int rpisense_reg_write(struct rpisense *rpisense, int reg, u16 val);
+int rpisense_block_write(struct rpisense *rpisense, const char *buf, int count);
+
+#endif
-- 
2.27.0



From sboyd at kernel.org  Thu Apr  8 01:26:47 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 07 Apr 2021 17:26:47 -0700
Subject: [PATCH v2 1/2] clk: zynqmp: Enable the driver if ZYNQMP_FIRMWARE
 is selected
In-Reply-To: <20210322061754.1065367-2-punit1.agrawal@toshiba.co.jp>
References: <20210322061754.1065367-1-punit1.agrawal@toshiba.co.jp>
 <20210322061754.1065367-2-punit1.agrawal@toshiba.co.jp>
Message-ID: <161784160735.3790633.4474710839183921640@swboyd.mtv.corp.google.com>

Quoting Punit Agrawal (2021-03-21 23:17:53)
> When booting the kernel on zynqmp based platforms such as Ultra96v2,
> peripheral drivers such as that for the sdcard depend on the presence
> of clocks.
> 
> Enable the clock driver if it's dependencies are compiled to avoid
> building an unbootable kernel.
> 
> Signed-off-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>
> ---

Applied to clk-next


From sboyd at kernel.org  Thu Apr  8 01:26:59 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 07 Apr 2021 17:26:59 -0700
Subject: [PATCH v2 2/2] clk: zynqmp: Drop dependency on ARCH_ZYNQMP
In-Reply-To: <20210322061754.1065367-3-punit1.agrawal@toshiba.co.jp>
References: <20210322061754.1065367-1-punit1.agrawal@toshiba.co.jp>
 <20210322061754.1065367-3-punit1.agrawal@toshiba.co.jp>
Message-ID: <161784161937.3790633.13788714088868174566@swboyd.mtv.corp.google.com>

Quoting Punit Agrawal (2021-03-21 23:17:54)
> The clock driver depends on ZYNQMP_FIRMWARE which in turn depends on
> ARCH_ZYNQMP. Simplify the Kconfig by dropping the redundant dependency
> on ARCH_ZYNQMP as it'll be applied transitively via ZYNQMP_FIRMWARE.
> 
> Signed-off-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>
> ---

Applied to clk-next


From lkp at intel.com  Thu Apr  8 01:28:46 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:28:46 +0800
Subject: [nomadik:ux500-gavini-v5.12-rc2] BUILD SUCCESS
 31cb33f631e75eb074452ea7285e164848035e74
Message-ID: <606e4e3e.VCU6WcSSKcew4juH%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-gavini-v5.12-rc2
branch HEAD: 31cb33f631e75eb074452ea7285e164848035e74  drm/panel: lms397kf04: Add driver for LMS397KF04

elapsed time: 722m

configs tested: 213
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
nios2                               defconfig
arc                          axs101_defconfig
alpha                            alldefconfig
s390                                defconfig
mips                        nlm_xlp_defconfig
m68k                                defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
alpha                            allyesconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
powerpc                      ppc44x_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
mips                          malta_defconfig
m68k                        stmark2_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
sh                          urquell_defconfig
sh                          kfr2r09_defconfig
m68k                        mvme16x_defconfig
xtensa                  audio_kc705_defconfig
xtensa                          iss_defconfig
arm                        spear3xx_defconfig
powerpc                     pq2fads_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
sh                           sh2007_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
arm                          iop32x_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
arm                         bcm2835_defconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
powerpc                   lite5200b_defconfig
ia64                          tiger_defconfig
mips                            gpr_defconfig
mips                     loongson1c_defconfig
powerpc                        warp_defconfig
sh                              ul2_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 01:28:49 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:28:49 +0800
Subject: [nomadik:ux500-skomer-v5.12-rc2] BUILD SUCCESS
 fe6d838d1b8e71e0a936015d45283615031295c1
Message-ID: <606e4e41.BpUurU1rGdFHexs4%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-skomer-v5.12-rc2
branch HEAD: fe6d838d1b8e71e0a936015d45283615031295c1  hacks

elapsed time: 722m

configs tested: 220
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
arc                          axs101_defconfig
powerpc                      chrp32_defconfig
arm                        keystone_defconfig
alpha                            allyesconfig
sh                            shmin_defconfig
mips                           ci20_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
arm                             pxa_defconfig
mips                           ip27_defconfig
arm                          iop32x_defconfig
sh                           sh2007_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
powerpc                      ppc44x_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
mips                          malta_defconfig
m68k                        stmark2_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
csky                                defconfig
sh                          urquell_defconfig
sh                          kfr2r09_defconfig
m68k                        mvme16x_defconfig
xtensa                  audio_kc705_defconfig
xtensa                          iss_defconfig
arm                        spear3xx_defconfig
powerpc                     pq2fads_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
powerpc                   lite5200b_defconfig
ia64                          tiger_defconfig
mips                            gpr_defconfig
mips                     loongson1c_defconfig
powerpc                        warp_defconfig
sh                              ul2_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
parisc                              defconfig
um                             i386_defconfig
arm                        mini2440_defconfig
powerpc                     ksi8560_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From sboyd at kernel.org  Thu Apr  8 01:38:11 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 07 Apr 2021 17:38:11 -0700
Subject: [PATCH mvebu v3 00/10] Armada 37xx: Fix cpufreq changing base CPU
 speed to 800 MHz from 1000 MHz
In-Reply-To: <20210328113102.jk3os7p56kq43yve@pali>
References: <20210114124032.12765-1-pali@kernel.org>
 <20210222194158.12342-1-pali@kernel.org>
 <20210301192024.tgvp6f5zscbknepo@pali> <87a6r8ka6x.fsf@BL-laptop>
 <20210328113102.jk3os7p56kq43yve@pali>
Message-ID: <161784229111.3790633.14149077702883618937@swboyd.mtv.corp.google.com>

Quoting Pali Roh?r (2021-03-28 04:31:02)
> On Friday 12 March 2021 10:12:06 Gregory CLEMENT wrote:
> > Hello Pali,
> > 
> > > Hello Gregory!
> > >
> > > Patches are the for almost two months and more people have tested them.
> > > They are marked with Fixed/CC-stable tags, they should go also into
> > > stable trees as they are fixing CPU scaling and instability issues.
> > >
> > > Are there any issues with these patches? If not, could you please merge
> > > them for upcoming Linux version?
> > 
> > Actually I am not the maintainer of the clk and cpufreq subsystems, so
> > the only thing I can apply is the device tree relative patch.
> > 
> > Gregory
> 
> Hello Gregory! Could you please at least review this patches, so other
> maintainers could merge them?

Maybe it can merge through cpufreq tree? I've already acked the clk
driver patches I believe.


From lkp at intel.com  Thu Apr  8 01:48:03 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:48:03 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 a3c1086c17e44b571410c2594dc54c94779dc918
Message-ID: <606e52c3.UxL0qdLJs0JBxQb9%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: a3c1086c17e44b571410c2594dc54c94779dc918  ARM: dts: clps711x: Add an empty chosen node to top level DTSI

elapsed time: 726m

configs tested: 213
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
nios2                               defconfig
arc                          axs101_defconfig
alpha                            alldefconfig
s390                                defconfig
mips                        nlm_xlp_defconfig
m68k                                defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
alpha                            allyesconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
powerpc                      ppc44x_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
mips                          malta_defconfig
m68k                        stmark2_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
csky                                defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
sh                          urquell_defconfig
sh                          kfr2r09_defconfig
m68k                        mvme16x_defconfig
xtensa                  audio_kc705_defconfig
xtensa                          iss_defconfig
arm                        spear3xx_defconfig
powerpc                     pq2fads_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
sh                           sh2007_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
arm                          iop32x_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
arm                         bcm2835_defconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
powerpc                   lite5200b_defconfig
ia64                          tiger_defconfig
mips                            gpr_defconfig
mips                     loongson1c_defconfig
powerpc                        warp_defconfig
sh                              ul2_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 01:48:07 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:48:07 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS 1180042dc6030c6e26530d4cfe0338fe8e447ca4
Message-ID: <606e52c7./apU2vjBssQTyp69%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: 1180042dc6030c6e26530d4cfe0338fe8e447ca4  Merge tag 'mvebu-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes

elapsed time: 726m

configs tested: 203
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                           ip28_defconfig
arm                         lpc18xx_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
alpha                            allyesconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
powerpc                      ppc44x_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
arm                     eseries_pxa_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
sh                          urquell_defconfig
sh                          kfr2r09_defconfig
m68k                        mvme16x_defconfig
xtensa                  audio_kc705_defconfig
xtensa                          iss_defconfig
arm                        spear3xx_defconfig
powerpc                     pq2fads_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
sh                           sh2007_defconfig
m68k                        stmark2_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
arm                          iop32x_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
sparc                       sparc32_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
mips                     loongson1c_defconfig
powerpc                        warp_defconfig
sh                              ul2_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 01:48:00 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:48:00 +0800
Subject: [soc:mvebu/dt64] BUILD SUCCESS
 99fa8ac5c0f1cf781194dbd04fcd162f4392a9b1
Message-ID: <606e52c0.GFNFNXI19kLoIfIn%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mvebu/dt64
branch HEAD: 99fa8ac5c0f1cf781194dbd04fcd162f4392a9b1  arm64: dts: marvell: enable CP110 UTMI PHY usage

elapsed time: 7414m

configs tested: 533
configs skipped: 133

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     powernv_defconfig
mips                      malta_kvm_defconfig
m68k                        mvme16x_defconfig
powerpc                      ppc40x_defconfig
mips                         tb0226_defconfig
sh                        apsh4ad0a_defconfig
arm                        vexpress_defconfig
powerpc64                        alldefconfig
powerpc                 mpc837x_rdb_defconfig
mips                        workpad_defconfig
xtensa                generic_kc705_defconfig
sh                         microdev_defconfig
arm                            mmp2_defconfig
sparc64                             defconfig
sh                           se7343_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
mips                      pic32mzda_defconfig
mips                         mpc30x_defconfig
mips                         cobalt_defconfig
sh                          rsk7201_defconfig
arm                        clps711x_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
sh                           se7619_defconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
arm                             rpc_defconfig
xtensa                       common_defconfig
powerpc                     ksi8560_defconfig
arm                          lpd270_defconfig
powerpc                     akebono_defconfig
arm                       aspeed_g4_defconfig
sh                          sdk7786_defconfig
csky                             alldefconfig
arm                        spear3xx_defconfig
mips                      fuloong2e_defconfig
arm                          badge4_defconfig
arm                  colibri_pxa270_defconfig
mips                      maltaaprp_defconfig
ia64                                defconfig
sparc                            alldefconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                     kilauea_defconfig
xtensa                  nommu_kc705_defconfig
x86_64                              defconfig
powerpc                      pasemi_defconfig
sh                        edosk7760_defconfig
arc                        nsimosci_defconfig
mips                        qi_lb60_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
powerpc                 canyonlands_defconfig
sh                     sh7710voipgw_defconfig
arm                            mps2_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
microblaze                      mmu_defconfig
powerpc                    ge_imp3a_defconfig
arm                       mainstone_defconfig
arc                         haps_hs_defconfig
sh                        sh7763rdp_defconfig
openrisc                 simple_smp_defconfig
riscv                          rv32_defconfig
powerpc                        fsp2_defconfig
powerpc                      ppc6xx_defconfig
arm                         lpc32xx_defconfig
arm                      footbridge_defconfig
arm                          ep93xx_defconfig
powerpc                         wii_defconfig
h8300                            alldefconfig
m68k                        stmark2_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
powerpc                 mpc836x_mds_defconfig
powerpc                       ebony_defconfig
powerpc64                           defconfig
microblaze                          defconfig
sh                           se7780_defconfig
powerpc                     mpc5200_defconfig
powerpc                     tqm5200_defconfig
arm                      pxa255-idp_defconfig
sh                          lboxre2_defconfig
powerpc                      mgcoge_defconfig
arm                           spitz_defconfig
arm                          imote2_defconfig
arm                            qcom_defconfig
sh                   sh7724_generic_defconfig
mips                malta_qemu_32r6_defconfig
arm                        realview_defconfig
arm                            hisi_defconfig
arm                        shmobile_defconfig
mips                            ar7_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                       sparc32_defconfig
powerpc                      tqm8xx_defconfig
arm                        mvebu_v5_defconfig
m68k                            mac_defconfig
m68k                            q40_defconfig
powerpc                    mvme5100_defconfig
mips                          ath25_defconfig
powerpc                     tqm8540_defconfig
sh                        sh7785lcr_defconfig
riscv                    nommu_virt_defconfig
xtensa                  audio_kc705_defconfig
arm                      integrator_defconfig
arm                           sunxi_defconfig
mips                           ip28_defconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc                 mpc8540_ads_defconfig
mips                         bigsur_defconfig
sh                             sh03_defconfig
powerpc                      katmai_defconfig
arm                         assabet_defconfig
arc                          axs103_defconfig
arm                      tct_hammer_defconfig
powerpc                       eiger_defconfig
sh                              ul2_defconfig
mips                     cu1000-neo_defconfig
ia64                        generic_defconfig
m68k                           sun3_defconfig
arm                           viper_defconfig
mips                        bcm63xx_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
ia64                             allmodconfig
m68k                         amcore_defconfig
m68k                       bvme6000_defconfig
arm                       spear13xx_defconfig
powerpc                     ppa8548_defconfig
sh                          polaris_defconfig
sh                         ap325rxa_defconfig
sh                          urquell_defconfig
sh                           se7705_defconfig
arm                     davinci_all_defconfig
sh                           se7751_defconfig
sh                           sh2007_defconfig
mips                         tb0219_defconfig
mips                           mtx1_defconfig
arm                         s5pv210_defconfig
ia64                             allyesconfig
arm                         at91_dt_defconfig
powerpc                      arches_defconfig
powerpc                  storcenter_defconfig
parisc                generic-32bit_defconfig
powerpc                     mpc83xx_defconfig
arm                      jornada720_defconfig
alpha                            allyesconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
arm                       aspeed_g5_defconfig
sh                        dreamcast_defconfig
ia64                             alldefconfig
arm                        oxnas_v6_defconfig
arm                         orion5x_defconfig
mips                           gcw0_defconfig
mips                           jazz_defconfig
mips                           rs90_defconfig
powerpc                   lite5200b_defconfig
parisc                generic-64bit_defconfig
mips                          malta_defconfig
riscv             nommu_k210_sdcard_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                 mpc836x_rdk_defconfig
nds32                             allnoconfig
powerpc                      ppc64e_defconfig
powerpc                      ppc44x_defconfig
powerpc                     asp8347_defconfig
arm                         socfpga_defconfig
i386                                defconfig
powerpc                     redwood_defconfig
powerpc                     sequoia_defconfig
powerpc                    gamecube_defconfig
sh                 kfr2r09-romimage_defconfig
powerpc                      obs600_defconfig
powerpc                      cm5200_defconfig
m68k                          hp300_defconfig
powerpc                        cell_defconfig
mips                       lemote2f_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     tqm8541_defconfig
sh                         apsh4a3a_defconfig
sh                          r7785rp_defconfig
arm                       versatile_defconfig
arm                          pcm027_defconfig
s390                             allmodconfig
powerpc                    sam440ep_defconfig
arm                           h3600_defconfig
powerpc                     ep8248e_defconfig
arm                        cerfcube_defconfig
mips                   sb1250_swarm_defconfig
arm                        magician_defconfig
mips                        nlm_xlp_defconfig
riscv                    nommu_k210_defconfig
parisc                           allyesconfig
powerpc                 mpc8272_ads_defconfig
arm                          collie_defconfig
arm                        spear6xx_defconfig
openrisc                            defconfig
sh                             shx3_defconfig
s390                             allyesconfig
m68k                         apollo_defconfig
arm                         vf610m4_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
m68k                        m5407c3_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          rsk7203_defconfig
mips                    maltaup_xpa_defconfig
h8300                               defconfig
nios2                               defconfig
sh                               allmodconfig
powerpc                     skiroot_defconfig
mips                           ci20_defconfig
sh                          sdk7780_defconfig
powerpc                           allnoconfig
mips                  cavium_octeon_defconfig
arc                     haps_hs_smp_defconfig
powerpc                 mpc837x_mds_defconfig
arm                           omap1_defconfig
arm                          exynos_defconfig
sh                        edosk7705_defconfig
arm                         cm_x300_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                  iss476-smp_defconfig
ia64                      gensparse_defconfig
sh                     magicpanelr2_defconfig
powerpc                     pq2fads_defconfig
arm                        trizeps4_defconfig
powerpc                          g5_defconfig
arm                         palmz72_defconfig
h8300                    h8300h-sim_defconfig
arm                         shannon_defconfig
powerpc                    klondike_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7269_defconfig
mips                        omega2p_defconfig
arm                        mvebu_v7_defconfig
um                            kunit_defconfig
arm                        mini2440_defconfig
powerpc                      acadia_defconfig
arm                            dove_defconfig
h8300                     edosk2674_defconfig
m68k                             alldefconfig
sh                               j2_defconfig
sh                         ecovec24_defconfig
m68k                       m5249evb_defconfig
arc                          axs101_defconfig
openrisc                  or1klitex_defconfig
arm                            zeus_defconfig
sh                   rts7751r2dplus_defconfig
m68k                        m5272c3_defconfig
powerpc                      chrp32_defconfig
arc                 nsimosci_hs_smp_defconfig
powerpc                     taishan_defconfig
mips                             allmodconfig
s390                       zfcpdump_defconfig
powerpc                      walnut_defconfig
arm                            xcep_defconfig
mips                      maltasmvp_defconfig
sh                          kfr2r09_defconfig
arm                          iop32x_defconfig
sh                           se7712_defconfig
xtensa                          iss_defconfig
arm                          pxa910_defconfig
openrisc                         alldefconfig
mips                     loongson1c_defconfig
arm64                            alldefconfig
openrisc                    or1ksim_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
mips                     decstation_defconfig
arm                        multi_v5_defconfig
arm                         nhk8815_defconfig
arm                           stm32_defconfig
mips                           ip32_defconfig
sh                            migor_defconfig
mips                           ip22_defconfig
arm                          simpad_defconfig
nios2                            allyesconfig
arc                           tb10x_defconfig
powerpc                       maple_defconfig
mips                        maltaup_defconfig
arm                             pxa_defconfig
arm                          ixp4xx_defconfig
sh                           se7721_defconfig
powerpc                     tqm8548_defconfig
powerpc                 mpc8313_rdb_defconfig
ia64                          tiger_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
mips                        nlm_xlr_defconfig
arm                           corgi_defconfig
powerpc                     sbc8548_defconfig
powerpc                    socrates_defconfig
powerpc                     kmeter1_defconfig
powerpc                          allmodconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                          moxart_defconfig
arm                        neponset_defconfig
um                               alldefconfig
arc                            hsdk_defconfig
powerpc                     pseries_defconfig
mips                            gpr_defconfig
arm                       omap2plus_defconfig
powerpc                  mpc885_ads_defconfig
m68k                        mvme147_defconfig
ia64                            zx1_defconfig
sh                          r7780mp_defconfig
mips                       rbtx49xx_defconfig
mips                 decstation_r4k_defconfig
powerpc                      pmac32_defconfig
arm                        keystone_defconfig
xtensa                              defconfig
arm                       imx_v6_v7_defconfig
ia64                         bigsur_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
powerpc                        icon_defconfig
powerpc                       holly_defconfig
powerpc                       ppc64_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                 mpc8560_ads_defconfig
sh                      rts7751r2d1_defconfig
powerpc                     stx_gp3_defconfig
arc                        nsim_700_defconfig
um                               allyesconfig
mips                           ip27_defconfig
arm                           tegra_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
mips                malta_kvm_guest_defconfig
arc                        vdk_hs38_defconfig
mips                          rm200_defconfig
arm                       imx_v4_v5_defconfig
sparc                       sparc64_defconfig
powerpc                 mpc832x_mds_defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
arc                              allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
parisc                              defconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
powerpc                          allyesconfig
x86_64               randconfig-a004-20210406
x86_64               randconfig-a003-20210406
x86_64               randconfig-a005-20210406
x86_64               randconfig-a001-20210406
x86_64               randconfig-a002-20210406
x86_64               randconfig-a006-20210406
x86_64               randconfig-a004-20210404
x86_64               randconfig-a003-20210404
x86_64               randconfig-a005-20210404
x86_64               randconfig-a001-20210404
x86_64               randconfig-a002-20210404
x86_64               randconfig-a006-20210404
i386                 randconfig-a006-20210405
i386                 randconfig-a003-20210405
i386                 randconfig-a001-20210405
i386                 randconfig-a004-20210405
i386                 randconfig-a002-20210405
i386                 randconfig-a005-20210405
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
i386                 randconfig-a006-20210403
i386                 randconfig-a003-20210403
i386                 randconfig-a001-20210403
i386                 randconfig-a004-20210403
i386                 randconfig-a002-20210403
i386                 randconfig-a005-20210403
i386                 randconfig-a006-20210404
i386                 randconfig-a003-20210404
i386                 randconfig-a001-20210404
i386                 randconfig-a004-20210404
i386                 randconfig-a005-20210404
i386                 randconfig-a002-20210404
i386                 randconfig-a006-20210406
i386                 randconfig-a003-20210406
i386                 randconfig-a001-20210406
i386                 randconfig-a004-20210406
i386                 randconfig-a005-20210406
i386                 randconfig-a002-20210406
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210405
x86_64               randconfig-a015-20210405
x86_64               randconfig-a013-20210405
x86_64               randconfig-a011-20210405
x86_64               randconfig-a012-20210405
x86_64               randconfig-a016-20210405
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
x86_64               randconfig-a014-20210403
x86_64               randconfig-a015-20210403
x86_64               randconfig-a011-20210403
x86_64               randconfig-a013-20210403
x86_64               randconfig-a012-20210403
x86_64               randconfig-a016-20210403
i386                 randconfig-a014-20210405
i386                 randconfig-a011-20210405
i386                 randconfig-a016-20210405
i386                 randconfig-a012-20210405
i386                 randconfig-a015-20210405
i386                 randconfig-a013-20210405
i386                 randconfig-a014-20210406
i386                 randconfig-a016-20210406
i386                 randconfig-a011-20210406
i386                 randconfig-a012-20210406
i386                 randconfig-a015-20210406
i386                 randconfig-a013-20210406
i386                 randconfig-a014-20210404
i386                 randconfig-a016-20210404
i386                 randconfig-a011-20210404
i386                 randconfig-a012-20210404
i386                 randconfig-a015-20210404
i386                 randconfig-a013-20210404
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
i386                 randconfig-a014-20210403
i386                 randconfig-a011-20210403
i386                 randconfig-a016-20210403
i386                 randconfig-a012-20210403
i386                 randconfig-a013-20210403
i386                 randconfig-a015-20210403
riscv                             allnoconfig
riscv                               defconfig
um                               allmodconfig
um                                allnoconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210405
x86_64               randconfig-a003-20210405
x86_64               randconfig-a005-20210405
x86_64               randconfig-a001-20210405
x86_64               randconfig-a002-20210405
x86_64               randconfig-a006-20210405
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a004-20210403
x86_64               randconfig-a005-20210403
x86_64               randconfig-a003-20210403
x86_64               randconfig-a001-20210403
x86_64               randconfig-a002-20210403
x86_64               randconfig-a006-20210403
x86_64               randconfig-a014-20210406
x86_64               randconfig-a015-20210406
x86_64               randconfig-a013-20210406
x86_64               randconfig-a011-20210406
x86_64               randconfig-a012-20210406
x86_64               randconfig-a016-20210406
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402
x86_64               randconfig-a014-20210404
x86_64               randconfig-a015-20210404
x86_64               randconfig-a013-20210404
x86_64               randconfig-a011-20210404
x86_64               randconfig-a012-20210404
x86_64               randconfig-a016-20210404

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 01:48:12 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 08:48:12 +0800
Subject: [soc:for-next] BUILD SUCCESS 73a049e384c83d709322d34cee6fcc9a3068a98e
Message-ID: <606e52cc.VMs2kpdolsrt8uSb%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 73a049e384c83d709322d34cee6fcc9a3068a98e  soc: document merges

elapsed time: 726m

configs tested: 208
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
nios2                               defconfig
arc                          axs101_defconfig
alpha                            alldefconfig
s390                                defconfig
mips                        nlm_xlp_defconfig
m68k                                defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
alpha                            allyesconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
powerpc                      ppc44x_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
mips                          malta_defconfig
m68k                        stmark2_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
powerpc                     pq2fads_defconfig
m68k                        mvme16x_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
sh                           sh2007_defconfig
arm                        spear3xx_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
sh                          kfr2r09_defconfig
arm                          iop32x_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
arm                         bcm2835_defconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
powerpc                   lite5200b_defconfig
ia64                          tiger_defconfig
mips                            gpr_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From andrew at aj.id.au  Thu Apr  8 01:57:46 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Thu, 08 Apr 2021 10:27:46 +0930
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <20210319061952.145040-1-andrew@aj.id.au>
References: <20210319061952.145040-1-andrew@aj.id.au>
Message-ID: <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>

Hi Corey,

On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote:
> Hello,
> 
> This series is a bit of a mix of things, but its primary purpose is to
> expose BMC KCS IPMI devices to userspace in a way that enables userspace
> to talk to host firmware using protocols that are not IPMI.
> 
> v1 can be found here:
> 
> https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew at aj.id.au/
> 
> Changes in v2 include:
> 
> * A rebase onto v5.12-rc2
> * Incorporation of off-list feedback on SerIRQ configuration from
>   Chiawei
> * Further validation on hardware for ASPEED KCS devices 2, 3 and 4
> * Lifting the existing single-open constraint of the IPMI chardev
> * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS
>   binding to dt-schema
> * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts
>   property definition for the ASPEED KCS binding
> 
> A new chardev device is added whose implementation exposes the Input
> Data Register (IDR), Output Data Register (ODR) and Status Register
> (STR) via read() and write(), and implements poll() for event
> monitoring.
> 
> The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in
> a way which encoded the IPMI protocol in its behaviour. However, as
> LPC[0] KCS devices give us bi-directional interrupts between the host
> and a BMC with both a data and status byte, they are useful for purposes
> beyond IPMI.
> 
> As a concrete example, libmctp[1] implements a vendor-defined MCTP[2]
> binding using a combination of LPC Firmware cycles for bulk data
> transfer and a KCS device via LPC IO cycles for out-of-band protocol
> control messages[3]. This gives a throughput improvement over the
> standard KCS binding[4] while continuing to exploit the ease of setup of
> the LPC bus for early boot firmware on the host processor.
> 
> The series takes a bit of a winding path to achieve its aim:
> 
> 1. It begins with patches 1-5 put together by Chia-Wei, which I've
> rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
> non-KCS LPC-related ASPEED device drivers in a way that enables the
> SerIRQ patches at the end of the series. With Joel's review I'm hoping
> these 5 can go through the aspeed tree, and that the rest can go through
> the IPMI tree.
> 
> 2. Next, patches 6-13 fairly heavily refactor the KCS support in the
> IPMI part of the tree, re-architecting things such that it's possible to
> support multiple chardev implementations sitting on top of the ASPEED
> and Nuvoton device drivers. However, the KCS code didn't really have
> great separation of concerns as it stood, so even if we disregard the
> multiple-chardev support I think the cleanups are worthwhile.
> 
> 3. Patch 14 adds some interrupt management capabilities to the KCS
> device drivers in preparation for patch 16, which introduces the new
> "raw" KCS device interface. I'm not stoked about the device name/path,
> so if people are looking to bikeshed something then feel free to lay
> into that.
> 
> 4. The remaining patches switch the ASPEED KCS devicetree binding to
> dt-schema, add a new interrupt property to describe the SerIRQ behaviour
> of the device and finally clean up Serial IRQ support in the ASPEED KCS
> driver.
> 
> Rob: The dt-binding patches still come before the relevant driver
> changes, I tried to keep the two close together in the series, hence the
> bindings changes not being patches 1 and 2.
> 
> I've exercised the series under qemu with the rainier-bmc machine plus
> additional patches for KCS support[5]. I've also substituted this series in
> place of a hacky out-of-tree driver that we've been using for the
> libmctp stack and successfully booted the host processor under our
> internal full-platform simulation tools for a Rainier system.
> 
> Note that this work touches the Nuvoton driver as well as ASPEED's, but
> I don't have the capability to test those changes or the IPMI chardev
> path. Tested-by tags would be much appreciated if you can exercise one
> or both.
> 
> Please review!

Unfortunately the cover letter got detached from the rest of the series.

Any chance you can take a look at the patches?

https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew at aj.id.au/

Cheers,

Andrew


From sboyd at kernel.org  Thu Apr  8 02:09:28 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 07 Apr 2021 18:09:28 -0700
Subject: [V2][PATCH] clk: zynqmp: move zynqmp_pll_set_mode out of
 round_rate callback
In-Reply-To: <20210406154015.602779-1-quanyang.wang@windriver.com>
References: <20210406154015.602779-1-quanyang.wang@windriver.com>
Message-ID: <161784416839.3790633.9475983970404006080@swboyd.mtv.corp.google.com>

Quoting quanyang.wang at windriver.com (2021-04-06 08:40:15)
> From: Quanyang Wang <quanyang.wang at windriver.com>
> 
> The round_rate callback should only perform rate calculation and not
> involve calling zynqmp_pll_set_mode to change the pll mode. So let's
> move zynqmp_pll_set_mode out of round_rate and to set_rate callback.
> 
> Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
> Reported-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
> ---

Applied to clk-next


From sboyd at kernel.org  Thu Apr  8 02:09:37 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Wed, 07 Apr 2021 18:09:37 -0700
Subject: [V3][PATCH] clk: zynqmp: pll: add set_pll_mode to check condition
 in zynqmp_pll_enable
In-Reply-To: <20210406153131.601701-1-quanyang.wang@windriver.com>
References: <20210406153131.601701-1-quanyang.wang@windriver.com>
Message-ID: <161784417793.3790633.1172679818900674783@swboyd.mtv.corp.google.com>

Quoting quanyang.wang at windriver.com (2021-04-06 08:31:31)
> From: Quanyang Wang <quanyang.wang at windriver.com>
> 
> If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever,
> we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this
> pll has been enabled. In ATF implementation, it will only assign
> the mode to the variable (struct pm_pll *)pll->mode when handling
> IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force
> ATF send request to PWU to set the pll mode to PLL's register.
> 
> There is a scenario that happens in enabling VPLL_INT(clk_id:96):
> 1) VPLL_INT has been enabled during booting.
> 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT
>    should be set to FRAC mode. Then zynqmp_pll_set_mode is called
>    to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point
>    ATF just stores the mode to a variable.
> 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is
>    called to try to enable VPLL_INT pll. Because of 1), the function
>    zynqmp_pll_enable just returns without doing anything after checking
>    that this pll has been enabled.
> 
> In the scenario above, the pll mode of VPLL_INT will never be set
> successfully. So adding set_pll_mode to check condition to fix it.
> 
> Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver")
> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
> Tested-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> ---

Applied to clk-next


From zev at bewilderbeest.net  Thu Apr  8 02:16:33 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed,  7 Apr 2021 20:16:33 -0500
Subject: [PATCH v5 0/4] serial: 8250_aspeed_vuart: generalized DT properties
Message-ID: <20210408011637.5361-1-zev@bewilderbeest.net>

This series generalizes the aspeed-vuart driver's device tree
properties to cover all the attributes it currently exposes via sysfs.

The aspeed,sirq-polarity-sense property was a bit of a design mistake
in that it ties Aspeed VUART SIRQ polarity to SCU register bits that
aren't really inherently related to it; the first patch in this series
deprecates it (though we hope to eventually remove it).

The rest of the series adds two new properties, aspeed,lpc-io-reg and
aspeed,lpc-interrupts.  The latter allows describing the SIRQ polarity
(along with the interrupt number) directly, providing a simpler
replacement for aspeed,sirq-polarity-sense.


Changes since v4 [3]:
 - fixed commit reference formatting in commit message

Changes since v3 [2]:
 - renamed properties to match aspeed,ast2400-kcs-bmc

Changes since v2 [0]:
 - expanded to also handle sirq number and lpc address in addition to
   sirq polarity
 - added default settings if DT properties not specified
 - refactored existing sysfs code slightly, adding range checks
 - cleaned up 'make dt_binding_check' warnings

Changes since v1 [1]:
 - deprecate and retain aspeed,sirq-polarity-sense instead of removing it
 - drop e3c246d4i dts addition from this series


[0] https://lore.kernel.org/openbmc/20210401005702.28271-1-zev at bewilderbeest.net/
[1] https://lore.kernel.org/openbmc/20210330002338.335-1-zev at bewilderbeest.net/
[2] https://lore.kernel.org/openbmc/20210402004716.15961-1-zev at bewilderbeest.net/
[3] https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/


Zev Weiss (4):
  dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
  drivers/tty/serial/8250: refactor sirq and lpc address setting code
  drivers/tty/serial/8250: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts DT properties
  dt-bindings: serial: 8250: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts

 .../devicetree/bindings/serial/8250.yaml      | 28 +++++-
 drivers/tty/serial/8250/8250_aspeed_vuart.c   | 95 +++++++++++++++----
 2 files changed, 103 insertions(+), 20 deletions(-)

-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  8 02:16:34 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed,  7 Apr 2021 20:16:34 -0500
Subject: [PATCH v5 1/4] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210408011637.5361-1-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
Message-ID: <20210408011637.5361-2-zev@bewilderbeest.net>

This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it was
removed in commit c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq
polarity").

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
       offset and bit number to identify how the SIRQ polarity should be
       configured. One possible data source is the LPC/eSPI mode bit. Only
       applicable to aspeed,ast2500-vuart.
+    deprecated: true
 
 required:
   - reg
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  8 02:16:35 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed,  7 Apr 2021 20:16:35 -0500
Subject: [PATCH v5 2/4] drivers/tty/serial/8250: refactor sirq and lpc address
 setting code
In-Reply-To: <20210408011637.5361-1-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
Message-ID: <20210408011637.5361-3-zev@bewilderbeest.net>

This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers.  While we're at it,
these functions now provide some basic bounds-checking on their
arguments.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..8433f8dbb186 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
 }
 
+static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
+{
+	if (addr > U16_MAX)
+		return -EINVAL;
+
+	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+	return 0;
+}
+
 static ssize_t lpc_address_store(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
-	unsigned long val;
+	u32 val;
 	int err;
 
-	err = kstrtoul(buf, 0, &val);
+	err = kstrtou32(buf, 0, &val);
 	if (err)
 		return err;
 
-	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
-	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
-
-	return count;
+	err = aspeed_vuart_set_lpc_address(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(lpc_address);
@@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
 }
 
+static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
+{
+	u8 reg;
+
+	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
+		return -EINVAL;
+
+	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+	reg |= sirq;
+	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+	return 0;
+}
+
 static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
 			  const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
 	unsigned long val;
 	int err;
-	u8 reg;
 
 	err = kstrtoul(buf, 0, &val);
 	if (err)
 		return err;
 
-	val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
-	val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-
-	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
-	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-	reg |= val;
-	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
-
-	return count;
+	err = aspeed_vuart_set_sirq(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(sirq);
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  8 02:16:36 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed,  7 Apr 2021 20:16:36 -0500
Subject: [PATCH v5 3/4] drivers/tty/serial/8250: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts DT properties
In-Reply-To: <20210408011637.5361-1-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
Message-ID: <20210408011637.5361-4-zev@bewilderbeest.net>

These allow describing all the Aspeed VUART attributes currently
available via sysfs.  aspeed,sirq provides a replacement for the
deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 44 ++++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 8433f8dbb186..75ef006fa24b 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -28,6 +28,10 @@
 #define ASPEED_VUART_ADDRL		0x28
 #define ASPEED_VUART_ADDRH		0x2c
 
+#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
+#define ASPEED_VUART_DEFAULT_SIRQ	4
+#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
+
 struct aspeed_vuart {
 	struct device		*dev;
 	void __iomem		*regs;
@@ -393,7 +397,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 	struct aspeed_vuart *vuart;
 	struct device_node *np;
 	struct resource *res;
-	u32 clk, prop;
+	u32 clk, prop, sirq[2];
+	bool sirq_polarity;
 	int rc;
 
 	np = pdev->dev.of_node;
@@ -501,6 +506,43 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 		of_node_put(sirq_polarity_sense_args.np);
 	}
 
+	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
+	if (rc < 0)
+		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
+
+	rc = aspeed_vuart_set_lpc_address(vuart, prop);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
+		goto err_clk_disable;
+	}
+
+	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
+	if (rc < 0) {
+		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
+		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
+	}
+
+	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts property\n");
+		goto err_clk_disable;
+	}
+
+	switch (sirq[1]) {
+	case IRQ_TYPE_LEVEL_LOW:
+		sirq_polarity = false;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+		sirq_polarity = true;
+		break;
+	default:
+		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts property\n");
+		rc = -EINVAL;
+		goto err_clk_disable;
+	}
+
+	aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
+
 	aspeed_vuart_set_enabled(vuart, true);
 	aspeed_vuart_set_host_tx_discard(vuart, true);
 	platform_set_drvdata(pdev, vuart);
-- 
2.31.1



From zev at bewilderbeest.net  Thu Apr  8 02:16:37 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Wed,  7 Apr 2021 20:16:37 -0500
Subject: [PATCH v5 4/4] dt-bindings: serial: 8250: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts
In-Reply-To: <20210408011637.5361-1-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
Message-ID: <20210408011637.5361-5-zev@bewilderbeest.net>

These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,lpc-interrupts provides
a replacement for the deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..0e82b076e199 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,13 @@ maintainers:
 allOf:
   - $ref: /schemas/serial.yaml#
   - if:
-      required:
-        - aspeed,sirq-polarity-sense
+      anyOf:
+        - required:
+            - aspeed,lpc-io-reg
+        - required:
+            - aspeed,lpc-interrupts
+        - required:
+            - aspeed,sirq-polarity-sense
     then:
       properties:
         compatible:
@@ -190,6 +195,20 @@ properties:
       applicable to aspeed,ast2500-vuart.
     deprecated: true
 
+  aspeed,lpc-io-reg:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      The VUART LPC address.  Only applicable to aspeed,ast2500-vuart.
+
+  aspeed,lpc-interrupts:
+    $ref: "/schemas/types.yaml#/definitions/uint32-array"
+    minItems: 2
+    maxItems: 2
+    description: |
+      A 2-cell property describing the VUART SIRQ number and SIRQ
+      polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH).  Only
+      applicable to aspeed,ast2500-vuart.
+
 required:
   - reg
   - interrupts
@@ -221,6 +240,7 @@ examples:
     };
   - |
     #include <dt-bindings/clock/aspeed-clock.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
     serial at 1e787000 {
         compatible = "aspeed,ast2500-vuart";
         reg = <0x1e787000 0x40>;
@@ -228,7 +248,8 @@ examples:
         interrupts = <8>;
         clocks = <&syscon ASPEED_CLK_APB>;
         no-loopback-test;
-        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
+        aspeed,lpc-io-reg = <0x3f8>;
+        aspeed,lpc-interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
     };
 
 ...
-- 
2.31.1



From peng.fan at oss.nxp.com  Thu Apr  8 02:27:09 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 8 Apr 2021 09:27:09 +0800
Subject: [PATCH v1 0/7] imx-gpcv2 improvements
In-Reply-To: <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
 <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>
Message-ID: <bc59b75b-d5b7-fe0f-6cba-d184cab204d3@oss.nxp.com>

Hi Lucas,

On 2021/4/8 6:13, Lucas Stach wrote:
> Hi Adrien,
> 
> I feel like I already mentioned to you some time ago that there is
> already a much more complete patch series to add this functionality on
> the list [1].
> 
> If you want this functionality to go upstream, please help test and
> extend this patch series.
> 
> Regards,
> Lucas
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.stach at pengutronix.de/

Would you share what's the issue that block this going forward?

Thanks,
Peng.

> 
> Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
>> Hi,
>>
>> This patch set aims is to add the support of the i.MX8 MM power domains
>> on the mainline kernel.
>>
>> To achieve this, I do several patches
>>  ??- Check errors when reading or writing registers (concerns i.MX8M base
>>  ????implementation);
>>  ??- Fix power up/down sequence. Handshake was not checked and it was
>>  ????not called at the appropriate time (concerns i.MX8M base
>> implementaions);
>>  ??- Allow domains without power sequence control like the HSIOMIX of the
>>  ????i.MX8MM.
>>  ??- Add some i.MX8MM domains (HSIO and OTGS);
>>  ??- Introduce quirks. For example, i.MX8MM OTG domains should not be
>>  ????powered off (seen n the source code of th i.MX ATF). Quirks are
>> easily upgrable for other cases.
>>  ??- Finally I defined power domains into the imx8mm.dtb file.
>>
>> I know that this kind of patch is rejected by NXP ut the other way
>> (callin ATF directly) was also rejected.
>>
>> I also know that NXP is concerned abou adding hundred lines of codes for
>> each new SOC but it' the way it works on Linux. And the "added code"
>> mainly consist of adding structures, defines and generic methods for
>> regmap.
>>
>> If it's a real problem, maybe we can introduc a new "gpcv3" driver for
>> i.MX8MM, i.MX8MN and i.MX8MP.
>>
>> Thanks,
>>
>> Adrien Grassein (7):
>>  ??soc: imx: gpcv2: check for errors when r/w registers
>>  ??soc: imx: gpcv2: Fix power up/down sequence
>>  ??soc: imx: gpcv2: allow domains without power sequence control
>>  ??dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
>>  ??soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
>>  ??soc: imx: gpcv2: add quirks to domains
>>  ??arm64: dts: imx8mm: add power-domains
>>
>>  ?.../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
>>  ?arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
>>  ?drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
>>  ?include/dt-bindings/power/imx8mm-power.h      |  21 ++
>>  ?4 files changed, 333 insertions(+), 66 deletions(-)
>>  ?create mode 100644 include/dt-bindings/power/imx8mm-power.h
>>
> 
> 


From richard.xnu.clark at gmail.com  Thu Apr  8 02:31:19 2021
From: richard.xnu.clark at gmail.com (richard clark)
Date: Thu, 8 Apr 2021 09:31:19 +0800
Subject: Question: multiple SMMUv3 devices probe
In-Reply-To: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
References: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
Message-ID: <CAJNi4rOdXLbwyhesFuyD0qQQ92Bp-dtwjZnKjQ5=Uhvy7iP9GA@mail.gmail.com>

> Hi guys,
> There're 3 SMMUv3 devices in my arm64 box. I am confused by the below
> probe process:
>
> arm_smmu_device_probe(...) --> arm_smmu_set_bus_ops(&arm_smmu_ops):
> if (platform_bus_type.iommu_ops != ops) {
>         err = bus_set_iommu(&platform_bus_type, ops);
>         if (err)
> }
>
> so for the 1st smmu device on the platform_bus, the
> arm_smmu_device_probe(...) will set the platform_bus_type.iommu_bus =
> arm_smmu_ops, so for the arm_smmu_device_probe(...) when probing the
> 2nd smmu device, the bus_set_iommu() will have no chance be called
> since the platform_bus_type.iommu_bus == arm_smmu_ops is true, my
> question is how the followed bus_set_iommu(...) being called?
>
> Thanks,
> RC

For this question,  any comments about that? Will, the owner of the
device driver, do you have some any? How about others too?
Thanks,
RC


From steven_lee at aspeedtech.com  Thu Apr  8 02:52:16 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Thu, 8 Apr 2021 09:52:16 +0800
Subject: [PATCH v1 0/2] mmc: sdhci-of-aspeed: Support toggling SD bus signal
Message-ID: <20210408015218.20560-1-steven_lee@aspeedtech.com>

Hello,

This series implements support for toggling SD bus signal voltage by
GPIO pin.

This series has been tested on AST2600-A2 EVB with APLL and 200MHz HCLK
clock source with sdr104, sdr50, sdr25, sdr12 and high speed mode. 
This series were also be tested on AST2600-A1 EVB and AST2500 EVB that
don't have the design of signal voltage toggling by GPIO.

Please help to review.

Regards,
Steven

Steven Lee (2):
  dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio and
    power-switch-gpio
  mmc: sdhci-of-aspeed: Support toggling SD bus signal voltage by GPIO

 .../devicetree/bindings/mmc/aspeed,sdhci.yaml |  25 +++
 drivers/mmc/host/sdhci-of-aspeed.c            | 155 ++++++++++++++++--
 2 files changed, 162 insertions(+), 18 deletions(-)

-- 
2.17.1



From steven_lee at aspeedtech.com  Thu Apr  8 02:52:18 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Thu, 8 Apr 2021 09:52:18 +0800
Subject: [PATCH v1 2/2] mmc: sdhci-of-aspeed: Support toggling SD bus signal
 voltage by GPIO
In-Reply-To: <20210408015218.20560-1-steven_lee@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
Message-ID: <20210408015218.20560-3-steven_lee@aspeedtech.com>

AST2600-A2 EVB provides reference design to support toggling signal
voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
the device tree. It also supporting enabling/disabling SD bus power by
power-gpio.

In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
a 1.8v and a 3.3v power load switch that providing signal voltage to
SD1 bus.
If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
disabled.
If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
voltage is 3.3v, otherwise, 1.8v power load switch will be enabled, SD1
signal voltage becomes 1.8v.

AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and
GPIOV3 as power-switch-gpio.

Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
---
 drivers/mmc/host/sdhci-of-aspeed.c | 155 +++++++++++++++++++++++++----
 1 file changed, 137 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
index 7d8692e90996..a74a03d37915 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -5,6 +5,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/gpio/consumer.h>
 #include <linux/io.h>
 #include <linux/math64.h>
 #include <linux/mmc/host.h>
@@ -30,6 +31,7 @@
 #define   ASPEED_SDC_S0_PHASE_IN_EN	BIT(2)
 #define   ASPEED_SDC_S0_PHASE_OUT_EN	GENMASK(1, 0)
 #define   ASPEED_SDC_PHASE_MAX		31
+#define ASPEED_CLOCK_PHASE 0xf4
 
 struct aspeed_sdc {
 	struct clk *clk;
@@ -58,18 +60,21 @@ struct aspeed_sdhci_phase_desc {
 	struct aspeed_sdhci_tap_desc out;
 };
 
-struct aspeed_sdhci_pdata {
+struct aspeed_sdhci_data {
 	unsigned int clk_div_start;
 	const struct aspeed_sdhci_phase_desc *phase_desc;
 	size_t nr_phase_descs;
+	const struct sdhci_pltfm_data *pdata;
 };
 
 struct aspeed_sdhci {
-	const struct aspeed_sdhci_pdata *pdata;
+	const struct aspeed_sdhci_data *data;
 	struct aspeed_sdc *parent;
 	u32 width_mask;
 	struct mmc_clk_phase_map phase_map;
 	const struct aspeed_sdhci_phase_desc *phase_desc;
+	struct gpio_desc *pwr_pin;
+	struct gpio_desc *pwr_sw_pin;
 };
 
 static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
@@ -209,7 +214,6 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
 	sdhci = sdhci_pltfm_priv(pltfm_host);
 
 	parent = clk_get_rate(pltfm_host->clk);
-
 	sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
 
 	if (clock == 0)
@@ -234,14 +238,13 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
 	 * supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and capture
 	 * the 0-value capability in clk_div_start.
 	 */
-	for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
+	for (div = sdhci->data->clk_div_start; div < 256; div *= 2) {
 		bus = parent / div;
 		if (bus <= clock)
 			break;
 	}
 
 	div >>= 1;
-
 	clk = div << SDHCI_DIVIDER_SHIFT;
 
 	aspeed_sdhci_configure_phase(host, bus);
@@ -292,8 +295,78 @@ static u32 aspeed_sdhci_readl(struct sdhci_host *host, int reg)
 	return val;
 }
 
+static void sdhci_aspeed_set_power(struct sdhci_host *host, unsigned char mode,
+				   unsigned short vdd)
+{
+	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
+	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
+	u8 pwr = 0;
+
+	if (!dev->pwr_pin)
+		return sdhci_set_power(host, mode, vdd);
+
+	if (mode != MMC_POWER_OFF) {
+		switch (1 << vdd) {
+		case MMC_VDD_165_195:
+		/*
+		 * Without a regulator, SDHCI does not support 2.0v
+		 * so we only get here if the driver deliberately
+		 * added the 2.0v range to ocr_avail. Map it to 1.8v
+		 * for the purpose of turning on the power.
+		 */
+		case MMC_VDD_20_21:
+				pwr = SDHCI_POWER_180;
+				break;
+		case MMC_VDD_29_30:
+		case MMC_VDD_30_31:
+				pwr = SDHCI_POWER_300;
+				break;
+		case MMC_VDD_32_33:
+		case MMC_VDD_33_34:
+				pwr = SDHCI_POWER_330;
+				break;
+		default:
+				WARN(1, "%s: Invalid vdd %#x\n",
+				     mmc_hostname(host->mmc), vdd);
+				break;
+		}
+	}
+
+	if (host->pwr == pwr)
+		return;
+
+	host->pwr = pwr;
+
+	if (pwr == 0) {
+		gpiod_set_value(dev->pwr_pin, 0);
+		sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
+	} else {
+		gpiod_set_value(dev->pwr_pin, 1);
+
+		if (dev->pwr_sw_pin) {
+			if (pwr & SDHCI_POWER_330)
+				gpiod_set_value(dev->pwr_sw_pin, 1);
+			else if (pwr & SDHCI_POWER_180)
+				gpiod_set_value(dev->pwr_sw_pin, 0);
+		}
+		pwr |= SDHCI_POWER_ON;
+		sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
+	}
+}
+
+static void aspeed_sdhci_voltage_switch(struct sdhci_host *host)
+{
+	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
+	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
+
+	if (dev->pwr_sw_pin)
+		gpiod_set_value(dev->pwr_sw_pin, 0);
+}
+
 static const struct sdhci_ops aspeed_sdhci_ops = {
 	.read_l = aspeed_sdhci_readl,
+	.set_power = sdhci_aspeed_set_power,
+	.voltage_switch = aspeed_sdhci_voltage_switch,
 	.set_clock = aspeed_sdhci_set_clock,
 	.get_max_clock = aspeed_sdhci_get_max_clock,
 	.set_bus_width = aspeed_sdhci_set_bus_width,
@@ -302,9 +375,14 @@ static const struct sdhci_ops aspeed_sdhci_ops = {
 	.set_uhs_signaling = sdhci_set_uhs_signaling,
 };
 
-static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
+static const struct sdhci_pltfm_data ast2400_sdhci_pdata = {
 	.ops = &aspeed_sdhci_ops,
 	.quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
+	.quirks2 = SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN | SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
+};
+
+static const struct sdhci_pltfm_data ast2600_sdhci_pdata = {
+	.ops = &aspeed_sdhci_ops,
 };
 
 static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
@@ -327,27 +405,28 @@ static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
 
 static int aspeed_sdhci_probe(struct platform_device *pdev)
 {
-	const struct aspeed_sdhci_pdata *aspeed_pdata;
+	const struct aspeed_sdhci_data *aspeed_data;
 	struct sdhci_pltfm_host *pltfm_host;
 	struct aspeed_sdhci *dev;
 	struct sdhci_host *host;
 	struct resource *res;
+	u32 reg_val;
 	int slot;
 	int ret;
 
-	aspeed_pdata = of_device_get_match_data(&pdev->dev);
-	if (!aspeed_pdata) {
+	aspeed_data = of_device_get_match_data(&pdev->dev);
+	if (!aspeed_data) {
 		dev_err(&pdev->dev, "Missing platform configuration data\n");
 		return -EINVAL;
 	}
 
-	host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
+	host = sdhci_pltfm_init(pdev, aspeed_data->pdata, sizeof(*dev));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
 	pltfm_host = sdhci_priv(host);
 	dev = sdhci_pltfm_priv(pltfm_host);
-	dev->pdata = aspeed_pdata;
+	dev->data = aspeed_data;
 	dev->parent = dev_get_drvdata(pdev->dev.parent);
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -358,8 +437,8 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
 	else if (slot >= 2)
 		return -EINVAL;
 
-	if (slot < dev->pdata->nr_phase_descs) {
-		dev->phase_desc = &dev->pdata->phase_desc[slot];
+	if (slot < dev->data->nr_phase_descs) {
+		dev->phase_desc = &dev->data->phase_desc[slot];
 	} else {
 		dev_info(&pdev->dev,
 			 "Phase control not supported for slot %d\n", slot);
@@ -372,6 +451,23 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
 
 	sdhci_get_of_property(pdev);
 
+	if (of_property_read_bool(pdev->dev.parent->of_node, "mmc-hs200-1_8v") ||
+	    of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
+		reg_val = readl(host->ioaddr + 0x40);
+		/* support 1.8V */
+		reg_val |= BIT(26);
+		/* write to sdhci140 or sdhci240 mirror register */
+		writel(reg_val, dev->parent->regs + (0x10 * (slot + 1)));
+	}
+
+	if (of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
+		reg_val = readl(host->ioaddr + 0x44);
+		/* SDR104 */
+		reg_val |= BIT(1);
+		/* write to sdhci144 or sdhci244 mirror register */
+		writel(reg_val, dev->parent->regs + (0x04 + (slot + 1) * 0x10));
+	}
+
 	pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(pltfm_host->clk))
 		return PTR_ERR(pltfm_host->clk);
@@ -389,6 +485,22 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
 	if (dev->phase_desc)
 		mmc_of_parse_clk_phase(host->mmc, &dev->phase_map);
 
+	dev->pwr_pin = devm_gpiod_get(&pdev->dev, "power", GPIOD_OUT_HIGH);
+	if (!IS_ERR(dev->pwr_pin)) {
+		gpiod_set_consumer_name(dev->pwr_pin, "mmc_pwr");
+		gpiod_direction_output(dev->pwr_pin, 1);
+	} else {
+		dev->pwr_pin = NULL;
+	}
+
+	dev->pwr_sw_pin = devm_gpiod_get(&pdev->dev, "power-switch", GPIOD_OUT_HIGH);
+	if (!IS_ERR(dev->pwr_sw_pin)) {
+		gpiod_set_consumer_name(dev->pwr_sw_pin, "mmc_pwr_sw");
+		gpiod_direction_output(dev->pwr_sw_pin, 0);
+	} else {
+		dev->pwr_sw_pin = NULL;
+	}
+
 	ret = sdhci_add_host(host);
 	if (ret)
 		goto err_sdhci_add;
@@ -420,8 +532,9 @@ static int aspeed_sdhci_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct aspeed_sdhci_pdata ast2400_sdhci_pdata = {
+static const struct aspeed_sdhci_data ast2400_sdhci_data = {
 	.clk_div_start = 2,
+	.pdata = &ast2400_sdhci_pdata,
 };
 
 static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
@@ -453,16 +566,17 @@ static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
 	},
 };
 
-static const struct aspeed_sdhci_pdata ast2600_sdhci_pdata = {
+static const struct aspeed_sdhci_data ast2600_sdhci_data = {
 	.clk_div_start = 1,
 	.phase_desc = ast2600_sdhci_phase,
 	.nr_phase_descs = ARRAY_SIZE(ast2600_sdhci_phase),
+	.pdata = &ast2600_sdhci_pdata,
 };
 
 static const struct of_device_id aspeed_sdhci_of_match[] = {
-	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_pdata, },
-	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_pdata, },
-	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_pdata, },
+	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_data, },
+	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_data, },
+	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_data, },
 	{ }
 };
 
@@ -482,6 +596,7 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
 	struct device_node *parent, *child;
 	struct aspeed_sdc *sdc;
 	int ret;
+	u32 timing_phase;
 
 	sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
 	if (!sdc)
@@ -506,6 +621,10 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
 		goto err_clk;
 	}
 
+	if (!of_property_read_u32(pdev->dev.of_node,
+				  "timing-phase", &timing_phase))
+		writel(timing_phase, sdc->regs + ASPEED_CLOCK_PHASE);
+
 	dev_set_drvdata(&pdev->dev, sdc);
 
 	parent = pdev->dev.of_node;
-- 
2.17.1



From steven_lee at aspeedtech.com  Thu Apr  8 02:52:17 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Thu, 8 Apr 2021 09:52:17 +0800
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio and
 power-switch-gpio
In-Reply-To: <20210408015218.20560-1-steven_lee@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
Message-ID: <20210408015218.20560-2-steven_lee@aspeedtech.com>

AST2600-A2 EVB provides the reference design for enabling SD bus power
and toggling SD bus signal voltage by GPIO pins.
Add the definition and example for power-gpio and power-switch-gpio
properties.

In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
a 1.8v and a 3.3v power load switch that providing signal voltage to
SD1 bus.
If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
disabled.
If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
voltage is 3.3v. Otherwise, 1.8v power load switch will be enabled, SD1
signal voltage becomes 1.8v.

AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and GPIOV3
as power-switch-gpio.

Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
---
 .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
index 987b287f3bff..515a74614f3c 100644
--- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -37,6 +37,14 @@ properties:
   clocks:
     maxItems: 1
     description: The SD/SDIO controller clock gate
+  power-gpio:
+    description:
+      The GPIO for enabling/disabling SD bus power.
+    maxItems: 1
+  power-switch-gpio:
+    description:
+      The GPIO for toggling the signal voltage between 3.3v and 1.8v.
+    maxItems: 1
 
 patternProperties:
   "^sdhci@[0-9a-f]+$":
@@ -61,6 +69,14 @@ patternProperties:
       sdhci,auto-cmd12:
         type: boolean
         description: Specifies that controller should use auto CMD12
+      power-gpio:
+        description:
+          The GPIO for enabling/disabling SD bus power.
+        maxItems: 1
+      power-switch-gpio:
+        description:
+          The GPIO for toggling the signal voltage between 3.3v and 1.8v.
+        maxItems: 1
     required:
       - compatible
       - reg
@@ -80,6 +96,7 @@ required:
 examples:
   - |
     #include <dt-bindings/clock/aspeed-clock.h>
+    #include <dt-bindings/gpio/aspeed-gpio.h>
     sdc at 1e740000 {
             compatible = "aspeed,ast2500-sd-controller";
             reg = <0x1e740000 0x100>;
@@ -94,6 +111,10 @@ examples:
                     interrupts = <26>;
                     sdhci,auto-cmd12;
                     clocks = <&syscon ASPEED_CLK_SDIO>;
+                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
+                                     GPIO_ACTIVE_HIGH>;
+                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 1)
+                                     GPIO_ACTIVE_HIGH>;
             };
 
             sdhci1: sdhci at 200 {
@@ -102,5 +123,9 @@ examples:
                     interrupts = <26>;
                     sdhci,auto-cmd12;
                     clocks = <&syscon ASPEED_CLK_SDIO>;
+                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
+                                     GPIO_ACTIVE_HIGH>;
+                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 3)
+                                     GPIO_ACTIVE_HIGH>;
             };
     };
-- 
2.17.1



From dj0227 at 163.com  Thu Apr  8 02:53:12 2021
From: dj0227 at 163.com (Jian Dong)
Date: Thu, 8 Apr 2021 09:53:12 +0800
Subject: [PATCH]  clk: imx: reference preceded by free
In-Reply-To: <161715700800.2260335.7834636340431628632@swboyd.mtv.corp.google.com>
References: <1616469034-9691-1-git-send-email-dj0227@163.com>
 <161715700800.2260335.7834636340431628632@swboyd.mtv.corp.google.com>
Message-ID: <20210408095312.00004267@163.com>

On Tue, 30 Mar 2021 19:16:48 -0700
Stephen Boyd <sboyd at kernel.org> wrote:

> Quoting Jian Dong (2021-03-22 20:10:34)
> > From: Jian Dong <dongjian at yulong.com>
> > 
> >  when register failed, clk will be freed, it will generate dangling
> > pointer problem in later reference. it should return directly.
> > 
> > Signed-off-by: Jian Dong <dongjian at yulong.com>
> > ---  
> 
> Any Fixes tag?

Sorry for late, I'm unfamiliar with tag rule.

For this patch include two files commit 2f77296d3 and fe37b482
maybe likes:

Fixes: 2f77296d3	(clk: imx: add lpcg clock support)
Fixes: fe37b482		(clk: imx: add scu clock common part)

and I noticed this patch has been merged, do I need RESEND again with
tags like above?

Thank you



From peng.fan at oss.nxp.com  Thu Apr  8 02:44:45 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:44:45 +0800
Subject: [PATCH V3 0/4] remoteproc: imx_rproc: support remote cores booted
 early
Message-ID: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

V3:
 Add R-b tag
 Typo fix in Patch 3
 Align the patch subject using remoteproc: imx_rproc:
 Update commit msg in Patch 4

V2:
 Patch [1,3]/4 is new
 Patch 4/4: Update commit message, drop unneeded code that already implemented by core

This patchset is to support booted remote cores could be attached to linux.
- Add missing of_node_put to decrease device node refcount
- Enlarge IMX7D_RPROC_MEM_MAX because need more imx_rproc_mem, such as resource table.
- Following stm32 remoteproc practice, move memory parsing to rproc_ops
- Support attaching booted cores, by adding attach, get loaded resource table and etc.

Peng Fan (4):
  remoteproc: imx_rproc: add missing of_node_put
  remoteproc: imx_rproc: enlarge IMX7D_RPROC_MEM_MAX
  remoteproc: imx_rproc: move memory parsing to rproc_ops
  remoteproc: imx_rproc: support remote cores booted before Linux Kernel

 drivers/remoteproc/imx_rproc.c | 65 ++++++++++++++++++++++++++++------
 1 file changed, 55 insertions(+), 10 deletions(-)

-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:44:46 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:44:46 +0800
Subject: [PATCH V3 1/4] remoteproc: imx_rproc: add missing of_node_put
In-Reply-To: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846289-13496-2-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

After of_parse_phandle, we need of_node_put to decrease the refcount
of the device_node.

Reported-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/remoteproc/imx_rproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6d3207ccbaef..077413319f58 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -459,6 +459,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
 			return err;
 		}
 
+		of_node_put(node);
+
 		if (b >= IMX7D_RPROC_MEM_MAX)
 			break;
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:44:47 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:44:47 +0800
Subject: [PATCH V3 2/4] remoteproc: imx_rproc: enlarge IMX7D_RPROC_MEM_MAX
In-Reply-To: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846289-13496-3-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

8 is not enough when we need more, such as resource table for remote cores
that booted before Linux Kernel, so enlarge IMX7D_RPROC_MEM_MAX to 32.
And also rename it to IMX_RPROC_MEM_MAX which make more sense.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/remoteproc/imx_rproc.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 077413319f58..b05aae0ad7a2 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -48,7 +48,7 @@
 					 | IMX6SX_SW_M4C_NON_SCLR_RST \
 					 | IMX6SX_SW_M4C_RST)
 
-#define IMX7D_RPROC_MEM_MAX		8
+#define IMX_RPROC_MEM_MAX		32
 
 /**
  * struct imx_rproc_mem - slim internal memory structure
@@ -88,7 +88,7 @@ struct imx_rproc {
 	struct regmap			*regmap;
 	struct rproc			*rproc;
 	const struct imx_rproc_dcfg	*dcfg;
-	struct imx_rproc_mem		mem[IMX7D_RPROC_MEM_MAX];
+	struct imx_rproc_mem		mem[IMX_RPROC_MEM_MAX];
 	struct clk			*clk;
 	struct mbox_client		cl;
 	struct mbox_chan		*tx_ch;
@@ -272,7 +272,7 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool *i
 	if (imx_rproc_da_to_sys(priv, da, len, &sys))
 		return NULL;
 
-	for (i = 0; i < IMX7D_RPROC_MEM_MAX; i++) {
+	for (i = 0; i < IMX_RPROC_MEM_MAX; i++) {
 		if (sys >= priv->mem[i].sys_addr && sys + len <
 		    priv->mem[i].sys_addr +  priv->mem[i].size) {
 			unsigned int offset = sys - priv->mem[i].sys_addr;
@@ -425,7 +425,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
 		if (!(att->flags & ATT_OWN))
 			continue;
 
-		if (b >= IMX7D_RPROC_MEM_MAX)
+		if (b >= IMX_RPROC_MEM_MAX)
 			break;
 
 		priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev,
@@ -461,7 +461,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
 
 		of_node_put(node);
 
-		if (b >= IMX7D_RPROC_MEM_MAX)
+		if (b >= IMX_RPROC_MEM_MAX)
 			break;
 
 		/* Not use resource version, because we might share region */
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:44:48 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:44:48 +0800
Subject: [PATCH V3 3/4] remoteproc: imx_rproc: move memory parsing to rproc_ops
In-Reply-To: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846289-13496-4-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Use the rproc_ops::prepare() hook for doing memory resources
reallocation when reattaching a remote procesor.

Suggested-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index b05aae0ad7a2..7cd09971d1a4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -317,7 +317,7 @@ static int imx_rproc_mem_release(struct rproc *rproc,
 	return 0;
 }
 
-static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+static int imx_rproc_prepare(struct rproc *rproc)
 {
 	struct imx_rproc *priv = rproc->priv;
 	struct device_node *np = priv->dev->of_node;
@@ -363,10 +363,7 @@ static int imx_rproc_parse_memory_regions(struct rproc *rproc)
 
 static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
-	int ret = imx_rproc_parse_memory_regions(rproc);
-
-	if (ret)
-		return ret;
+	int ret;
 
 	ret = rproc_elf_load_rsc_table(rproc, fw);
 	if (ret)
@@ -399,6 +396,7 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
 }
 
 static const struct rproc_ops imx_rproc_ops = {
+	.prepare	= imx_rproc_prepare,
 	.start		= imx_rproc_start,
 	.stop		= imx_rproc_stop,
 	.kick		= imx_rproc_kick,
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:44:49 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:44:49 +0800
Subject: [PATCH V3 4/4] remoteproc: imx_rproc: support remote cores booted
 before Linux Kernel
In-Reply-To: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846289-13496-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846289-13496-5-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

 - When remote cores are kicked before Linux Kernel, we are not able
   to get resource table from the firmware elf file, so we need to add
   rsc_table to hold the resource table published by remote cores and
   imx_rproc_get_loaded_rsc_table is to get the resource table.
 - Per remoteproc framework, add attach hook for processor in a detached
   state.
 - Add imx_rproc_detect_mode to detect remote cores' working mode to
   set the state which is required by remoteproc framework.

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 45 ++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7cd09971d1a4..d6338872c6db 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -95,6 +95,7 @@ struct imx_rproc {
 	struct mbox_chan		*rx_ch;
 	struct work_struct		rproc_work;
 	struct workqueue_struct		*workqueue;
+	void __iomem			*rsc_table;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
 			__func__, vqid, err);
 }
 
+static int imx_rproc_attach(struct rproc *rproc)
+{
+	return 0;
+}
+
+static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
+{
+	struct imx_rproc *priv = rproc->priv;
+
+	/* The resource table has already been mapped in imx_rproc_addr_init */
+	if (!priv->rsc_table)
+		return NULL;
+
+	*table_sz = SZ_1K;
+	return (struct resource_table *)priv->rsc_table;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
 	.prepare	= imx_rproc_prepare,
+	.attach		= imx_rproc_attach,
 	.start		= imx_rproc_start,
 	.stop		= imx_rproc_stop,
 	.kick		= imx_rproc_kick,
@@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
 	.load		= rproc_elf_load_segments,
 	.parse_fw	= imx_rproc_parse_fw,
 	.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+	.get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
 	.sanity_check	= rproc_elf_sanity_check,
 	.get_boot_addr	= rproc_elf_get_boot_addr,
 };
@@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
 		}
 		priv->mem[b].sys_addr = res.start;
 		priv->mem[b].size = resource_size(&res);
+		if (!strcmp(node->name, "rsc_table"))
+			priv->rsc_table = priv->mem[b].cpu_addr;
 		b++;
 	}
 
@@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
 	mbox_free_channel(priv->rx_ch);
 }
 
+static int imx_rproc_detect_mode(struct imx_rproc *priv)
+{
+	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+	struct device *dev = priv->dev;
+	int ret;
+	u32 val;
+
+	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
+	if (ret) {
+		dev_err(dev, "Failed to read src\n");
+		return ret;
+	}
+
+	if (!(val & dcfg->src_stop))
+		priv->rproc->state = RPROC_DETACHED;
+
+	return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
 		goto err_put_mbox;
 	}
 
+	ret = imx_rproc_detect_mode(priv);
+	if (ret)
+		goto err_put_mbox;
+
 	priv->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(priv->clk)) {
 		dev_err(dev, "Failed to get clock\n");
-- 
2.30.0



From bjorn.andersson at linaro.org  Thu Apr  8 03:05:40 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 7 Apr 2021 21:05:40 -0500
Subject: [PATCH] iommu/arm-smmu-qcom: create qcom_smmu_impl for ACPI boot
In-Reply-To: <20210406162305.GA28529@lpieralisi>
References: <20210301074021.20059-1-shawn.guo@linaro.org>
 <20210325145914.GC15172@willie-the-truck>
 <20210325170256.GA904837@yoga> <20210406162305.GA28529@lpieralisi>
Message-ID: <20210408020540.GK904837@yoga>

On Tue 06 Apr 11:23 CDT 2021, Lorenzo Pieralisi wrote:

> On Thu, Mar 25, 2021 at 12:02:56PM -0500, Bjorn Andersson wrote:
> > On Thu 25 Mar 09:59 CDT 2021, Will Deacon wrote:
> > 
> > > [+ Lorenzo]
> > > 
> > > On Mon, Mar 01, 2021 at 03:40:21PM +0800, Shawn Guo wrote:
> > > > Though qcom_adreno_smmu_impl is not used by ACPI boot right now,
> > > > qcom_smmu_impl is already required at least to boot up Lenovo Flex 5G
> > > > laptop.  Let's check asl_compiler_id in IORT header to ensure we are
> > > > running a QCOM SMMU and create qcom_smmu_impl for it.
> > > > 
> > > > !np is used to check ACPI boot, because fwnode of SMMU device is
> > > > a static allocation and thus has_acpi_companion() doesn't work here.
> > > > 
> > > > Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> > > > ---
> > > >  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 33 ++++++++++++++++++++++
> > > >  1 file changed, 33 insertions(+)
> > > 
> > > I don't know what a "asl_compiler_id" is, but it doesn't sound like it
> > > has an awful lot to do with the SMMU.
> > > 
> > 
> > I would prefer that we somehow relate this to the particular board,
> > rather than all Qualcomm-related ACPI tables. E.g. by relying on the
> > SMMU devices having a _HID of QCOM0409.
> > 
> > Shawn, any reason for this wouldn't be possible?
> > 
> > > Lorenzo -- any idea what we should be doing here instead? Probably not
> > > using ACPI?
> > > 
> > 
> > The 8cx (aka sc8180x) platform comes with Qualcomm's usual SMMU
> > stream-mapping quirks and this is one of the patches needed to bring
> > enough ACPI support to run the Debian installer that Shawn has been
> > working on. After the installer we currently only boot this using DT -
> > which already enables the quirk.
> 
> I am not sure I follow - can you explain please why this patch (and so
> the QCOM SMMU) is actually needed ? I don't get why getting the SMMU
> up and running with ACPI is mandatory to complete the process you describe
> above (but I am not sure I understood it entirely either - apologies).
> 

The bootloader sets up stream mappings for things such as storage and
display before jumping to Linux and as things are implemented today the
arm-smmu driver is probed.

The problem that arises, which is the reason for this patch, is that
when the arm-smmu driver resets the SMMU it wipes the stream mappings
and the next time the display hardware tries to scan out the EFIFB a
fault is triggered - of the type that happens to trap into one of the
higher security levels - which results in the device rebooting.

The handling of this is implemented by  07a7f2caaa5a
("iommu/arm-smmu-qcom: Read back stream mappings") and f9081b8ff593
("iommu/arm-smmu-qcom: Implement S2CR quirk"), which are activated based
on DT compatibles today.

What Shawn is looking for is a way to enable this quirk for the ACPI
case as well.

Regards,
Bjorn


From peng.fan at oss.nxp.com  Thu Apr  8 02:54:50 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:50 +0800
Subject: [PATCH V3 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
Message-ID: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

V3:
 Add A-b tag for Patch 1/2
 Fix the checkpatch warning for Patch 6,8

V2:
 Patch 1/8, use fsl as vendor, typo fix
 Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that
 change.

This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
parse fsl,auto-boot
This patchset depends on [1]

[1] https://patchwork.kernel.org/project/linux-remoteproc/cover/
    1617846289-13496-1-git-send-email-peng.fan at oss.nxp.com/

Peng Fan (8):
  dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
  dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
  dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
  remoteproc: imx_rproc: make clk optional
  remoteproc: imx_rproc: parse fsl,auto-boot
  remoteproc: imx_rproc: initial support for mutilple start/stop method
  remoteproc: imx_rproc: support i.MX7ULP
  remoteproc: imx_rproc: support i.MX8MN/P

 .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
 drivers/remoteproc/imx_rproc.c                | 170 +++++++++++++++---
 2 files changed, 159 insertions(+), 22 deletions(-)

-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:51 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:51 +0800
Subject: [PATCH V3 1/8] dt-bindings: remoteproc: imx_rproc: add fsl,
 auto-boot property
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-2-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add an optional property "fsl,auto-boot" to indicate remote processor
auto boot.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml       | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 208a628f8d6c..b13bf8d70488 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -49,6 +49,12 @@ properties:
     minItems: 1
     maxItems: 32
 
+  fsl,auto-boot:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Indicate whether need to load the default firmware and start the remote
+      processor automatically.
+
 required:
   - compatible
   - clocks
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:52 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:52 +0800
Subject: [PATCH V3 2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
 support
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-3-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX7ULP compatible.

We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
control of M4 core, M4 core starts by ROM and powers most serivces used
by A7 core, so A7 core has no power to start and stop M4 core. So
clocks and syscon are not required.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml          | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index b13bf8d70488..58bc2a23f97b 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -18,6 +18,7 @@ properties:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
       - fsl,imx7d-cm4
+      - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
 
   clocks:
@@ -57,8 +58,6 @@ properties:
 
 required:
   - compatible
-  - clocks
-  - syscon
 
 additionalProperties: false
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:53 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:53 +0800
Subject: [PATCH V3 3/8] dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-4-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) compatible string

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 58bc2a23f97b..1dc34cf5a4ea 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -17,6 +17,8 @@ properties:
     enum:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
+      - fsl,imx8mn-cm7
+      - fsl,imx8mp-cm7
       - fsl,imx7d-cm4
       - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:54 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:54 +0800
Subject: [PATCH V3 4/8] remoteproc: imx_rproc: make clk optional
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-5-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

To i.MX7ULP, M4 is the master to control everything, so it not need
clk from A7.

Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d6338872c6db..ca17f520d904 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -635,7 +635,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_put_mbox;
 
-	priv->clk = devm_clk_get(dev, NULL);
+	priv->clk = devm_clk_get_optional(dev, NULL);
 	if (IS_ERR(priv->clk)) {
 		dev_err(dev, "Failed to get clock\n");
 		ret = PTR_ERR(priv->clk);
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:55 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:55 +0800
Subject: [PATCH V3 5/8] remoteproc: imx_rproc: parse fsl,auto-boot
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-6-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Parse fsl,auto-boot to indicate whether need remoteproc framework
auto boot or not.

When remote processor is booted before Linux Kernel up, do not parse
fsl,auto-boot. So add an entry to store the working mode of remote
processor. Currently only IMX_RPROC_NORMAL, IMX_RPROC_EARLY_BOOT.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index ca17f520d904..c576e12d3817 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -83,6 +83,16 @@ struct imx_rproc_dcfg {
 	size_t				att_size;
 };
 
+enum imx_rproc_mode {
+	/* Linux load/kick remote core */
+	IMX_RPROC_NORMAL,
+	/*
+	 * remote core booted before kicking Linux, and remote core
+	 * could be stopped & restarted by Linux
+	 */
+	IMX_RPROC_EARLY_BOOT,
+};
+
 struct imx_rproc {
 	struct device			*dev;
 	struct regmap			*regmap;
@@ -96,6 +106,7 @@ struct imx_rproc {
 	struct work_struct		rproc_work;
 	struct workqueue_struct		*workqueue;
 	void __iomem			*rsc_table;
+	enum imx_rproc_mode		mode;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -565,14 +576,18 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	int ret;
 	u32 val;
 
+	priv->mode = IMX_RPROC_NORMAL;
+
 	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
 	if (ret) {
 		dev_err(dev, "Failed to read src\n");
 		return ret;
 	}
 
-	if (!(val & dcfg->src_stop))
+	if (!(val & dcfg->src_stop)) {
+		priv->mode = IMX_RPROC_EARLY_BOOT;
 		priv->rproc->state = RPROC_DETACHED;
+	}
 
 	return 0;
 }
@@ -654,6 +669,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 
 	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
 
+	if (priv->mode == IMX_RPROC_NORMAL)
+		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "rproc_add failed\n");
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:56 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:56 +0800
Subject: [PATCH V3 6/8] remoteproc: imx_rproc: initial support for mutilple
 start/stop method
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-7-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
(start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).

The current SoCs supported are all using IMX_RPROC_MMIO, add a restrict
in probe that only SoCs using IMX_RPROC_MMIO needs syscon regmap to
access registers.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 50 +++++++++++++++++++++++-----------
 1 file changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index c576e12d3817..a7fa9d7fc2d1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -74,6 +74,15 @@ struct imx_rproc_att {
 	int flags;
 };
 
+/* Remote core start/stop method */
+enum imx_rproc_method {
+	IMX_RPROC_NONE,
+	/* Through syscon regmap */
+	IMX_RPROC_MMIO,
+	/* Through ARM SMCCC */
+	IMX_RPROC_SMC,
+};
+
 struct imx_rproc_dcfg {
 	u32				src_reg;
 	u32				src_mask;
@@ -81,6 +90,7 @@ struct imx_rproc_dcfg {
 	u32				src_stop;
 	const struct imx_rproc_att	*att;
 	size_t				att_size;
+	enum imx_rproc_method		method;
 };
 
 enum imx_rproc_mode {
@@ -194,6 +204,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx8mq,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mq),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
@@ -203,6 +214,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx7d,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7d),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
@@ -212,6 +224,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
 	.src_stop	= IMX6SX_M4_STOP,
 	.att		= imx_rproc_att_imx6sx,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx6sx),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static int imx_rproc_start(struct rproc *rproc)
@@ -578,15 +591,17 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 
 	priv->mode = IMX_RPROC_NORMAL;
 
-	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
-	if (ret) {
-		dev_err(dev, "Failed to read src\n");
-		return ret;
-	}
+	if (priv->regmap) {
+		ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
+		if (ret) {
+			dev_err(dev, "Failed to read src\n");
+			return ret;
+		}
 
-	if (!(val & dcfg->src_stop)) {
-		priv->mode = IMX_RPROC_EARLY_BOOT;
-		priv->rproc->state = RPROC_DETACHED;
+		if (!(val & dcfg->src_stop)) {
+			priv->rproc->state = RPROC_DETACHED;
+			priv->mode = IMX_RPROC_EARLY_BOOT;
+		}
 	}
 
 	return 0;
@@ -600,16 +615,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	struct rproc *rproc;
 	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg;
-	struct regmap *regmap;
+	struct regmap *regmap = NULL;
 	int ret;
 
-	regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
-	if (IS_ERR(regmap)) {
-		dev_err(dev, "failed to find syscon\n");
-		return PTR_ERR(regmap);
-	}
-	regmap_attach_dev(dev, regmap, &config);
-
 	/* set some other name then imx */
 	rproc = rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
 			    NULL, sizeof(*priv));
@@ -622,6 +630,16 @@ static int imx_rproc_probe(struct platform_device *pdev)
 		goto err_put_rproc;
 	}
 
+	if (dcfg->method == IMX_RPROC_MMIO) {
+		regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
+		if (IS_ERR(regmap)) {
+			dev_err(dev, "failed to find syscon\n");
+			ret = PTR_ERR(regmap);
+			goto err_put_rproc;
+		}
+		regmap_attach_dev(dev, regmap, &config);
+	}
+
 	priv = rproc->priv;
 	priv->rproc = rproc;
 	priv->regmap = regmap;
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:57 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:57 +0800
Subject: [PATCH V3 7/8] remoteproc: imx_rproc: support i.MX7ULP
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-8-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
and powers most serivces used by A7 core, so A7 core has no power to
start and stop M4 core.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index a7fa9d7fc2d1..b911a7539897 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -147,6 +147,14 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	{ 0x40000000, 0x40000000, 0x80000000, 0 },
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx7ulp[] = {
+	{0x1FFD0000, 0x1FFD0000, 0x30000, ATT_OWN},
+	{0x20000000, 0x20000000, 0x10000, ATT_OWN},
+	{0x2F000000, 0x2F000000, 0x20000, ATT_OWN},
+	{0x2F020000, 0x2F020000, 0x20000, ATT_OWN},
+	{0x60000000, 0x60000000, 0x40000000, 0}
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* OCRAM_S (M4 Boot code) - alias */
@@ -207,6 +215,12 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.method		= IMX_RPROC_MMIO,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx7ulp = {
+	.att		= imx_rproc_att_imx7ulp,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7ulp),
+	.method		= IMX_RPROC_NONE,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -598,12 +612,16 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 			return ret;
 		}
 
-		if (!(val & dcfg->src_stop)) {
-			priv->rproc->state = RPROC_DETACHED;
+		if (!(val & dcfg->src_stop))
 			priv->mode = IMX_RPROC_EARLY_BOOT;
-		}
 	}
 
+	if (dcfg->method == IMX_RPROC_NONE)
+		priv->mode = IMX_RPROC_EARLY_BOOT;
+
+	if (priv->mode == IMX_RPROC_EARLY_BOOT)
+		priv->rproc->state = RPROC_DETACHED;
+
 	return 0;
 }
 
@@ -724,6 +742,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id imx_rproc_of_match[] = {
+	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
 	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 02:54:58 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu,  8 Apr 2021 09:54:58 +0800
Subject: [PATCH V3 8/8] remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1617846898-13662-9-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
SMCCC to start/stop M core, not using regmap interface.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 89 +++++++++++++++++++++++++++++++---
 1 file changed, 82 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index b911a7539897..9351626f09c0 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2017 Pengutronix, Oleksij Rempel <kernel at pengutronix.de>
  */
 
+#include <linux/arm-smccc.h>
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
@@ -50,6 +51,11 @@
 
 #define IMX_RPROC_MEM_MAX		32
 
+#define IMX_SIP_RPROC			0xC2000005
+#define IMX_SIP_RPROC_START		0x00
+#define IMX_SIP_RPROC_STARTED		0x01
+#define IMX_SIP_RPROC_STOP		0x02
+
 /**
  * struct imx_rproc_mem - slim internal memory structure
  * @cpu_addr: MPU virtual address of the memory region
@@ -119,6 +125,36 @@ struct imx_rproc {
 	enum imx_rproc_mode		mode;
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx8mn[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* ITCM   */
+	{ 0x00000000, 0x007E0000, 0x00020000, ATT_OWN },
+	/* OCRAM_S */
+	{ 0x00180000, 0x00180000, 0x00009000, 0 },
+	/* OCRAM */
+	{ 0x00900000, 0x00900000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00920000, 0x00920000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00940000, 0x00940000, 0x00050000, 0 },
+	/* QSPI Code - alias */
+	{ 0x08000000, 0x08000000, 0x08000000, 0 },
+	/* DDR (Code) - alias */
+	{ 0x10000000, 0x40000000, 0x0FFE0000, 0 },
+	/* DTCM */
+	{ 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
+	/* OCRAM_S - alias */
+	{ 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20240000, 0x00940000, 0x00040000, ATT_OWN },
+	/* DDR (Data) */
+	{ 0x40000000, 0x40000000, 0x80000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCML - alias */
@@ -205,6 +241,12 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
 	{ 0x80000000, 0x80000000, 0x60000000, 0 },
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn = {
+	.att		= imx_rproc_att_imx8mn,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mn),
+	.method		= IMX_RPROC_SMC,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -246,12 +288,24 @@ static int imx_rproc_start(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_start);
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_start);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
 	if (ret)
-		dev_err(dev, "Failed to enable M4!\n");
+		dev_err(dev, "Failed to enable remote cores!\n");
 
 	return ret;
 }
@@ -261,12 +315,26 @@ static int imx_rproc_stop(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_stop);
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_stop);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STOP, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		if (res.a1)
+			dev_info(dev, "Not in wfi, force stopped\n");
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
 	if (ret)
-		dev_err(dev, "Failed to stop M4!\n");
+		dev_err(dev, "Failed to stop remote cores\n");
 
 	return ret;
 }
@@ -600,6 +668,7 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 {
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 	u32 val;
 
@@ -616,8 +685,12 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 			priv->mode = IMX_RPROC_EARLY_BOOT;
 	}
 
-	if (dcfg->method == IMX_RPROC_NONE)
+	if (dcfg->method == IMX_RPROC_NONE) {
 		priv->mode = IMX_RPROC_EARLY_BOOT;
+	} else if (dcfg->method == IMX_RPROC_SMC) {
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STARTED, 0, 0, 0, 0, 0, 0, &res);
+		priv->mode = res.a0 ? IMX_RPROC_EARLY_BOOT : IMX_RPROC_NORMAL;
+	}
 
 	if (priv->mode == IMX_RPROC_EARLY_BOOT)
 		priv->rproc->state = RPROC_DETACHED;
@@ -747,6 +820,8 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
 	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
+	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
+	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr  8 03:18:28 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 8 Apr 2021 10:18:28 +0800
Subject: [PATCH V2 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <20210407161836.GB418374@xps15>
References: <1617095574-6764-1-git-send-email-peng.fan@oss.nxp.com>
 <20210407161836.GB418374@xps15>
Message-ID: <f957373f-d078-8591-6c78-d0027f590360@oss.nxp.com>



On 2021/4/8 0:18, Mathieu Poirier wrote:
> On Tue, Mar 30, 2021 at 05:12:46PM +0800, peng.fan at oss.nxp.com wrote:
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> V2:
>>   Patch 1/8, use fsl as vendor, typo fix
>>   Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that change.
>>
>> This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to parse
>> imx,auto-boot
>> This patchset depends on [1]
>>
>> [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/1617082235-15923-1-git-send-email-peng.fan at oss.nxp.com/
>>
>> Peng Fan (8):
>>    dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
>>    dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
>>    dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
>>    remoteproc: imx_rproc: make clk optional
>>    remoteproc: imx_rproc: parse fsl,auto-boot
>>    remoteproc: imx_rproc: initial support for mutilple start/stop method
>>    remoteproc: imx_rproc: support i.MX7ULP
>>    remoteproc: imx_rproc: support i.MX8MN/P
>>
> 
> There are glaring checkpatch warning on this set - the "DT compatible string"
> ones are fine but the others are not negotiable.  As such I am dropping this set
> entirely.

Ah, sorry for this. I just sent out V3 to address all the checkpatch 
warnings.

Thanks,
Peng.

>   
>>   .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
>>   drivers/remoteproc/imx_rproc.c                | 170 +++++++++++++++---
>>   2 files changed, 159 insertions(+), 22 deletions(-)
>>
>> -- 
>> 2.30.0
>>


From cw00.choi at samsung.com  Thu Apr  8 03:47:02 2021
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 8 Apr 2021 11:47:02 +0900
Subject: [PATCH V8 1/8] PM / devfreq: Add cpu based scaling support to
 passive_governor
In-Reply-To: <fbb6c44b-eb77-14ce-9175-3f06030e6e0c@samsung.com>
References: <1616499241-4906-1-git-send-email-andrew-sh.cheng@mediatek.com>
 <CGME20210323113411epcas1p3b4367563007ca91c30201d7fc225bb67@epcas1p3.samsung.com>
 <1616499241-4906-2-git-send-email-andrew-sh.cheng@mediatek.com>
 <233a3bd6-7ab1-5da2-9184-a745eb253d86@samsung.com>
 <1617177820.15067.1.camel@mtksdaap41>
 <2ae8604d-0da6-4243-1b92-81b3917d7d48@samsung.com>
 <cad52436-b291-05bf-236f-7b7cb1fdbbff@samsung.com>
 <1617195800.18432.3.camel@mtksdaap41>
 <fbb6c44b-eb77-14ce-9175-3f06030e6e0c@samsung.com>
Message-ID: <cfdd3973-e4a7-8c09-8a7e-57118a7a3b9b@samsung.com>

On 4/1/21 9:16 AM, Chanwoo Choi wrote:
> On 3/31/21 10:03 PM, andrew-sh.cheng wrote:
>> On Wed, 2021-03-31 at 17:35 +0900, Chanwoo Choi wrote:
>>> On 3/31/21 5:27 PM, Chanwoo Choi wrote:
>>>> Hi,
>>>>
>>>> On 3/31/21 5:03 PM, andrew-sh.cheng wrote:
>>>>> On Thu, 2021-03-25 at 17:14 +0900, Chanwoo Choi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> You are missing to add these patches to linux-pm mailing list.
>>>>>> Need to send them to linu-pm ML.
>>>>>>
>>>>>> Also, before received this series, I tried to clean-up these patches
>>>>>> on testing branch[1]. So that I add my comment with my clean-up case.
>>>>>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!zIrzeDp9vPnm1_SDzVPuzqdHn3zWie9DnfBXaA-j9-CSrVc6aR9_rJQQiw81_CgAPh9XRRs$ 
>>>>>>
>>>>>> And 'Saravana Kannan <skannan at codeaurora.org>' is wrong email address.
>>>>>> Please update the email or drop this email.
>>>>>
>>>>> Hi Chanwoo,
>>>>>
>>>>> Thank you for the advices.
>>>>> I will resend patch v9 (add to linux-pm ML), remove this patch, and note
>>>>> that my patch set base on
>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
>>>>
>>>> I has not yet test this patch[1] on devfreq-testing-passive-gov branch.
>>>> So that if possible, I'd like you to test your patches with this patch[1] 
>>>> and then if there is no problem, could you send the next patches with patch[1]?
>>>>
>>>> [1]https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing-passive-gov&id=39c80d11a8f42dd63ecea1e0df595a0ceb83b454__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJR2cQqZs$ 
>>>
>>>
>>> Sorry for the confusion. I make the devfreq-testing-passive-gov[1]
>>> branch based on latest devfreq-next branch.
>>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
>>>
>>> First of all, if possible, I want to test them[1] with your patches in this series.
>>> And then if there are no any problem, please let me know. After confirmed from you,
>>> I'll send the patches of devfreq-testing-passive-gov[1] branch.
>>> How about that?
>>>
>> Hi Chanwoo~
>>
>> We will use this on Google Chrome project.
>> Google Hsin-Yi has test your patch + my patch set v8 [2~8]
>>
>>     make sure cci devfreqs runs with cpufreq.
>>     suspend resume
>>     speedometer2 benchmark
>> It is okay.
>>
>> Please send the patches of devfreq-testing-passive-gov[1] branch.
>>
>> I will send patch v9 base on yours latter.
> 
> Thanks for your test. I'll send the patches today.

I'm sorry for delay because when I tested the patches
for devfreq parent type on Odroid-xu3, there are some problem
related to lazy linking of OPP. So I'm trying to analyze them.
Unfortunately, we need to postpone these patches to next linux
version.


[snip]

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


From ran.wang_1 at nxp.com  Thu Apr  8 04:03:53 2021
From: ran.wang_1 at nxp.com (Ran Wang)
Date: Thu,  8 Apr 2021 11:03:53 +0800
Subject: [PATCH v7] soc: fsl: enable acpi support in RCPM driver
Message-ID: <20210408030353.37193-1-ran.wang_1@nxp.com>

From: Peng Ma <peng.ma at nxp.com>

This patch enables ACPI support in RCPM driver.

Signed-off-by: Peng Ma <peng.ma at nxp.com>
Signed-off-by: Ran Wang <ran.wang_1 at nxp.com>
---
Change in v7:
 - Update comment for checking RCPM node which refferred to

Change in v6:
 - Remove copyright udpate to rebase on latest mainline

Change in v5:
 - Fix panic when dev->of_node is null

Change in v4:
 - Make commit subject more accurate
 - Remove unrelated new blank line

Change in v3:
 - Add #ifdef CONFIG_ACPI for acpi_device_id
 - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids

Change in v2:
 - Update acpi_device_id to fix conflict with other driver

 drivers/soc/fsl/rcpm.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index 4ace28cab314..90d3f4060b0c 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,7 @@
 #include <linux/slab.h>
 #include <linux/suspend.h>
 #include <linux/kernel.h>
+#include <linux/acpi.h>
 
 #define RCPM_WAKEUP_CELL_MAX_SIZE	7
 
@@ -78,10 +79,20 @@ static int rcpm_pm_prepare(struct device *dev)
 				"fsl,rcpm-wakeup", value,
 				rcpm->wakeup_cells + 1);
 
-		/*  Wakeup source should refer to current rcpm device */
-		if (ret || (np->phandle != value[0]))
+		if (ret)
 			continue;
 
+		/*
+		 * For DT mode, would handle devices with "fsl,rcpm-wakeup"
+		 * pointing to the current RCPM node.
+		 *
+		 * For ACPI mode, currently we assume there is only one
+		 * RCPM controller existing.
+		 */
+		if (is_of_node(dev->fwnode))
+			if (np->phandle != value[0])
+				continue;
+
 		/* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
 		 * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
 		 * of wakeup source IP contains an integer array: <phandle to
@@ -172,10 +183,19 @@ static const struct of_device_id rcpm_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, rcpm_of_match);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id rcpm_acpi_ids[] = {
+	{"NXP0015",},
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
+#endif
+
 static struct platform_driver rcpm_driver = {
 	.driver = {
 		.name = "rcpm",
 		.of_match_table = rcpm_of_match,
+		.acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
 		.pm	= &rcpm_pm_ops,
 	},
 	.probe = rcpm_probe,
-- 
2.25.1



From viresh.kumar at linaro.org  Thu Apr  8 04:45:28 2021
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 8 Apr 2021 09:15:28 +0530
Subject: [RFC PATCH v2 10/10] firmware: arm_scmi: Add virtio transport
In-Reply-To: <20201105212116.411422-11-peter.hilber@opensynergy.com>
References: <20201105212116.411422-1-peter.hilber@opensynergy.com>
 <20201105212116.411422-11-peter.hilber@opensynergy.com>
Message-ID: <CAOh2x==6TH-A8076weSLy7kLqrNZgRgp2GFyAEGGPyikw1rgGg@mail.gmail.com>

On Fri, Nov 6, 2020 at 2:59 AM Peter Hilber
<peter.hilber at opensynergy.com> wrote:

> +static int scmi_vio_probe(struct virtio_device *vdev)
> +{
> +       struct device *dev = &vdev->dev;
> +       struct scmi_vio_channel **vioch;
> +       bool have_vq_rx;
> +       int vq_cnt;
> +       int i;
> +       struct virtqueue *vqs[VIRTIO_SCMI_VQ_MAX_CNT];
> +
> +       vioch = devm_kcalloc(dev, VIRTIO_SCMI_VQ_MAX_CNT, sizeof(*vioch),
> +                            GFP_KERNEL);
> +       if (!vioch)
> +               return -ENOMEM;
> +
> +       have_vq_rx = virtio_has_feature(vdev, VIRTIO_SCMI_F_P2A_CHANNELS);
> +       vq_cnt = have_vq_rx ? VIRTIO_SCMI_VQ_MAX_CNT : 1;
> +
> +       for (i = 0; i < vq_cnt; i++) {
> +               vioch[i] = devm_kzalloc(dev, sizeof(**vioch), GFP_KERNEL);
> +               if (!vioch[i])
> +                       return -ENOMEM;
> +       }
> +
> +       if (have_vq_rx)
> +               vioch[VIRTIO_SCMI_VQ_RX]->is_rx = true;
> +
> +       if (virtio_find_vqs(vdev, vq_cnt, vqs, scmi_vio_complete_callbacks,
> +                           scmi_vio_vqueue_names, NULL)) {
> +               dev_err(dev, "Failed to get %d virtqueue(s)\n", vq_cnt);
> +               return -1;
> +       }
> +       dev_info(dev, "Found %d virtqueue(s)\n", vq_cnt);
> +
> +       for (i = 0; i < vq_cnt; i++) {
> +               spin_lock_init(&vioch[i]->lock);
> +               vioch[i]->vqueue = vqs[i];
> +               vioch[i]->vqueue->priv = vioch[i];

The vqueue->priv field is used by core, you can't update it else
notifications won't work.

> +       }
> +
> +       vdev->priv = vioch;
> +
> +       virtio_device_ready(vdev);
> +
> +       return 0;
> +}

diff --git a/drivers/firmware/arm_scmi/virtio.c
b/drivers/firmware/arm_scmi/virtio.c
index f70aa72f34f1..b1af77341b30 100644
--- a/drivers/firmware/arm_scmi/virtio.c
+++ b/drivers/firmware/arm_scmi/virtio.c
@@ -80,7 +80,8 @@ static int scmi_vio_populate_vq_rx(struct
scmi_vio_channel *vioch,

 static void scmi_vio_complete_cb(struct virtqueue *vqueue)
 {
-       struct scmi_vio_channel *vioch = vqueue->priv;
+       struct scmi_vio_channel **_vioch = vqueue->vdev->priv;
+       struct scmi_vio_channel *vioch = _vioch[vqueue->index];
        unsigned long iflags;
        unsigned int length;

@@ -454,7 +455,6 @@ static int scmi_vio_probe(struct virtio_device *vdev)
        for (i = 0; i < vq_cnt; i++) {
                spin_lock_init(&vioch[i]->lock);
                vioch[i]->vqueue = vqs[i];
-               vioch[i]->vqueue->priv = vioch[i];
        }

        vdev->priv = vioch;


From quanyang.wang at windriver.com  Thu Apr  8 05:02:19 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu,  8 Apr 2021 12:02:19 +0800
Subject: [PATCH 0/4] spi: spi-zynqmp-gpspi: fix some issues 
Message-ID: <20210408040223.23134-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

Hello,

This series fix some issues that occurs when the gqspi driver switches to spi-mem framework.

Hi Amit,
I rewrite the "Subject" and "commit message" of these patches, so they
look different from the ones which you reviewed before. I still keep
your "Reviewed-by" and hope you will not mind.

Regards,
Quanyang Wang

Quanyang Wang (4):
  spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to make
    zynqmp_qspi_exec_op not interruptible
  spi: spi-zynqmp-gqspi: add mutex locking for exec_op
  spi: spi-zynqmp-gqspi: transmit dummy circles by using the
    controller's internal functionality
  spi: spi-zynqmp-gqspi: fix incorrect operating mode in
    zynqmp_qspi_read_op

 drivers/spi/spi-zynqmp-gqspi.c | 53 +++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 26 deletions(-)

-- 
2.25.1



From quanyang.wang at windriver.com  Thu Apr  8 05:02:20 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu,  8 Apr 2021 12:02:20 +0800
Subject: [PATCH 1/4] spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to
 make zynqmp_qspi_exec_op not interruptible
In-Reply-To: <20210408040223.23134-1-quanyang.wang@windriver.com>
References: <20210408040223.23134-1-quanyang.wang@windriver.com>
Message-ID: <20210408040223.23134-2-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

When Ctrl+C occurs during the process of zynqmp_qspi_exec_op, the function
wait_for_completion_interruptible_timeout will return a non-zero value
-ERESTARTSYS immediately. This will disrupt the SPI memory operation
because the data transmitting may begin before the command or address
transmitting completes. Use wait_for_completion_timeout to prevent
the process from being interruptible.

This patch fixes the error as below:
root at xilinx-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 4 Kibyte @ 3d000 --  4 % complete
    (Press Ctrl+C)
[  169.581911] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  170.585907] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  171.589910] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  172.593910] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  173.597907] zynqmp-qspi ff0f0000.spi: Chip select timed out
[  173.603480] spi-nor spi0.0: Erase operation failed.
[  173.608368] spi-nor spi0.0: Attempted to modify a protected sector.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
Reviewed-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..d49ab6575553 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -973,7 +973,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 		zynqmp_gqspi_write(xqspi, GQSPI_IER_OFST,
 				   GQSPI_IER_GENFIFOEMPTY_MASK |
 				   GQSPI_IER_TXNOT_FULL_MASK);
-		if (!wait_for_completion_interruptible_timeout
+		if (!wait_for_completion_timeout
 		    (&xqspi->data_completion, msecs_to_jiffies(1000))) {
 			err = -ETIMEDOUT;
 			kfree(tmpbuf);
@@ -1001,7 +1001,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 				   GQSPI_IER_TXEMPTY_MASK |
 				   GQSPI_IER_GENFIFOEMPTY_MASK |
 				   GQSPI_IER_TXNOT_FULL_MASK);
-		if (!wait_for_completion_interruptible_timeout
+		if (!wait_for_completion_timeout
 		    (&xqspi->data_completion, msecs_to_jiffies(1000))) {
 			err = -ETIMEDOUT;
 			goto return_err;
@@ -1076,7 +1076,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 						   GQSPI_IER_RXEMPTY_MASK);
 			}
 		}
-		if (!wait_for_completion_interruptible_timeout
+		if (!wait_for_completion_timeout
 		    (&xqspi->data_completion, msecs_to_jiffies(1000)))
 			err = -ETIMEDOUT;
 	}
-- 
2.25.1



From quanyang.wang at windriver.com  Thu Apr  8 05:02:21 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu,  8 Apr 2021 12:02:21 +0800
Subject: [PATCH 2/4] spi: spi-zynqmp-gqspi: add mutex locking for exec_op
In-Reply-To: <20210408040223.23134-1-quanyang.wang@windriver.com>
References: <20210408040223.23134-1-quanyang.wang@windriver.com>
Message-ID: <20210408040223.23134-3-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The spi-mem framework has no locking to prevent ctlr->mem_ops->exec_op
from concurrency. So add the locking to zynqmp_qspi_exec_op.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
Reviewed-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index d49ab6575553..3b39461d58b3 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -173,6 +173,7 @@ struct zynqmp_qspi {
 	u32 genfifoentry;
 	enum mode_type mode;
 	struct completion data_completion;
+	struct mutex op_lock;
 };
 
 /**
@@ -951,6 +952,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
 		op->dummy.buswidth, op->data.buswidth);
 
+	mutex_lock(&xqspi->op_lock);
 	zynqmp_qspi_config_op(xqspi, mem->spi);
 	zynqmp_qspi_chipselect(mem->spi, false);
 	genfifoentry |= xqspi->genfifocs;
@@ -1084,6 +1086,7 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 return_err:
 
 	zynqmp_qspi_chipselect(mem->spi, true);
+	mutex_unlock(&xqspi->op_lock);
 
 	return err;
 }
@@ -1156,6 +1159,8 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_pclk;
 	}
 
+	mutex_init(&xqspi->op_lock);
+
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
-- 
2.25.1



From quanyang.wang at windriver.com  Thu Apr  8 05:02:22 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu,  8 Apr 2021 12:02:22 +0800
Subject: [PATCH 3/4] spi: spi-zynqmp-gqspi: transmit dummy circles by using
 the controller's internal functionality
In-Reply-To: <20210408040223.23134-1-quanyang.wang@windriver.com>
References: <20210408040223.23134-1-quanyang.wang@windriver.com>
Message-ID: <20210408040223.23134-4-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

There is a data corruption issue that occurs in the reading operation
(cmd:0x6c) when transmitting common data as dummy circles.

The gqspi controller has the functionality to send dummy clock circles.
When writing data with the fields [receive, transmit, data_xfer] = [0,0,1]
to the Generic FIFO, and configuring the correct SPI mode, the controller
will transmit dummy circles.

So let's switch to hardware dummy cycles transfer to fix this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
Reviewed-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 40 +++++++++++++++-------------------
 1 file changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 3b39461d58b3..cf73a069b759 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -521,7 +521,7 @@ static void zynqmp_qspi_filltxfifo(struct zynqmp_qspi *xqspi, int size)
 {
 	u32 count = 0, intermediate;
 
-	while ((xqspi->bytes_to_transfer > 0) && (count < size)) {
+	while ((xqspi->bytes_to_transfer > 0) && (count < size) && (xqspi->txbuf)) {
 		memcpy(&intermediate, xqspi->txbuf, 4);
 		zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
 
@@ -580,7 +580,7 @@ static void zynqmp_qspi_fillgenfifo(struct zynqmp_qspi *xqspi, u8 nbits,
 		genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
 		genfifoentry |= GQSPI_GENFIFO_TX;
 		transfer_len = xqspi->bytes_to_transfer;
-	} else {
+	} else if (xqspi->rxbuf) {
 		genfifoentry &= ~GQSPI_GENFIFO_TX;
 		genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
 		genfifoentry |= GQSPI_GENFIFO_RX;
@@ -588,6 +588,11 @@ static void zynqmp_qspi_fillgenfifo(struct zynqmp_qspi *xqspi, u8 nbits,
 			transfer_len = xqspi->dma_rx_bytes;
 		else
 			transfer_len = xqspi->bytes_to_receive;
+	} else {
+		/* Sending dummy circles here */
+		genfifoentry &= ~(GQSPI_GENFIFO_TX | GQSPI_GENFIFO_RX);
+		genfifoentry |= GQSPI_GENFIFO_DATA_XFER;
+		transfer_len = xqspi->bytes_to_transfer;
 	}
 	genfifoentry |= zynqmp_qspi_selectspimode(xqspi, nbits);
 	xqspi->genfifoentry = genfifoentry;
@@ -1011,32 +1016,23 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 	}
 
 	if (op->dummy.nbytes) {
-		tmpbuf = kzalloc(op->dummy.nbytes, GFP_KERNEL | GFP_DMA);
-		if (!tmpbuf)
-			return -ENOMEM;
-		memset(tmpbuf, 0xff, op->dummy.nbytes);
-		reinit_completion(&xqspi->data_completion);
-		xqspi->txbuf = tmpbuf;
+		xqspi->txbuf = NULL;
 		xqspi->rxbuf = NULL;
-		xqspi->bytes_to_transfer = op->dummy.nbytes;
+		/*
+		 * xqspi->bytes_to_transfer here represents the dummy circles
+		 * which need to be sent.
+		 */
+		xqspi->bytes_to_transfer = op->dummy.nbytes * 8 / op->dummy.buswidth;
 		xqspi->bytes_to_receive = 0;
-		zynqmp_qspi_write_op(xqspi, op->dummy.buswidth,
+		/*
+		 * Using op->data.buswidth instead of op->dummy.buswidth here because
+		 * we need to use it to configure the correct SPI mode.
+		 */
+		zynqmp_qspi_write_op(xqspi, op->data.buswidth,
 				     genfifoentry);
 		zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
 				   zynqmp_gqspi_read(xqspi, GQSPI_CONFIG_OFST) |
 				   GQSPI_CFG_START_GEN_FIFO_MASK);
-		zynqmp_gqspi_write(xqspi, GQSPI_IER_OFST,
-				   GQSPI_IER_TXEMPTY_MASK |
-				   GQSPI_IER_GENFIFOEMPTY_MASK |
-				   GQSPI_IER_TXNOT_FULL_MASK);
-		if (!wait_for_completion_interruptible_timeout
-		    (&xqspi->data_completion, msecs_to_jiffies(1000))) {
-			err = -ETIMEDOUT;
-			kfree(tmpbuf);
-			goto return_err;
-		}
-
-		kfree(tmpbuf);
 	}
 
 	if (op->data.nbytes) {
-- 
2.25.1



From quanyang.wang at windriver.com  Thu Apr  8 05:02:23 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu,  8 Apr 2021 12:02:23 +0800
Subject: [PATCH 4/4] spi: spi-zynqmp-gqspi: fix incorrect operating mode in
 zynqmp_qspi_read_op
In-Reply-To: <20210408040223.23134-1-quanyang.wang@windriver.com>
References: <20210408040223.23134-1-quanyang.wang@windriver.com>
Message-ID: <20210408040223.23134-5-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

When starting a read operation, we should call zynqmp_qspi_setuprxdma
first to set xqspi->mode according to xqspi->bytes_to_receive and
to calculate correct xqspi->dma_rx_bytes. Then in the function
zynqmp_qspi_fillgenfifo, generate the appropriate command with
operating mode and bytes to transfer, and fill the GENFIFO with
the command to perform the read operation.

Calling zynqmp_qspi_fillgenfifo before zynqmp_qspi_setuprxdma will
result in incorrect transfer length and operating mode. So change
the calling order to fix this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
Reviewed-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index cf73a069b759..036d8ae41c06 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -827,8 +827,8 @@ static void zynqmp_qspi_write_op(struct zynqmp_qspi *xqspi, u8 tx_nbits,
 static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
 				u32 genfifoentry)
 {
-	zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
 	zynqmp_qspi_setuprxdma(xqspi);
+	zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
 }
 
 /**
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:19 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:19 -0400
Subject: [PATCH v13 00/18] arm64: MMU enabled kexec relocation
Message-ID: <20210408040537.2703241-1-pasha.tatashin@soleen.com>

Changelog:
v13:
	- Fixed a hang on ThunderX2, thank you Pingfan Liu for reporting
	  the problem. In relocation function we need civac not ivac, we
	  need to clean data in addition to invalidating it.
	  Since I was using ThunderX2 machine I also measured the new
	  performance data on this large ARM64 server. The MMU improves
	  kexec relocation 190 times on this machine! (see below for
	  raw data). Saves 7.5s during CentOS kexec reboot.
v12:
	- A major change compared to previous version. Instead of using
	  contiguous VA range a copy of linear map is now used to perform
	  copying of segments during relocation as it was agreed in the
	  discussion of version 11 of this project.
	- In addition to using linear map, I also took several ideas from
	  James Morse to better organize the kexec relocation:
	  	1. skip relocation function entirely if that is not needed
		2. remove the PoC flushing function since it is not needed
		   anymore with MMU enabled.
v11:
	- Fixed missing KEXEC_CORE dependency for trans_pgd.c
	- Removed useless "if(rc) return rc" statement (thank you Tyler Hicks)
	- Another 12 patches were accepted into maintainer's get.
	  Re-based patches against:
	  https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
	  Branch: for-next/kexec
v10:
	- Addressed a lot of comments form James Morse and from  Marc Zyngier
	- Added review-by's
	- Synchronized with mainline

v9:	- 9 patches from previous series landed in upstream, so now series
	  is smaller
	- Added two patches from James Morse to address idmap issues for machines
	  with high physical addresses.
	- Addressed comments from Selin Dag about compiling issues. He also tested
	  my series and got similar performance results: ~60 ms instead of ~580 ms
	  with an initramfs size of ~120MB.
v8:
	- Synced with mainline to keep series up-to-date
v7:
	-- Addressed comments from James Morse
	- arm64: hibernate: pass the allocated pgdp to ttbr0
	  Removed "Fixes" tag, and added Added Reviewed-by: James Morse
	- arm64: hibernate: check pgd table allocation
	  Sent out as a standalone patch so it can be sent to stable
	  Series applies on mainline + this patch
	- arm64: hibernate: add trans_pgd public functions
	  Remove second allocation of tmp_pg_dir in swsusp_arch_resume
	  Added Reviewed-by: James Morse <james.morse at arm.com>
	- arm64: kexec: move relocation function setup and clean up
	  Fixed typo in commit log
	  Changed kern_reloc to phys_addr_t types.
	  Added explanation why kern_reloc is needed.
	  Split into four patches:
	  arm64: kexec: make dtb_mem always enabled
	  arm64: kexec: remove unnecessary debug prints
	  arm64: kexec: call kexec_image_info only once
	  arm64: kexec: move relocation function setup
	- arm64: kexec: add expandable argument to relocation function
	  Changed types of new arguments from unsigned long to phys_addr_t.
	  Changed offset prefix to KEXEC_*
	  Split into four patches:
	  arm64: kexec: cpu_soft_restart change argument types
	  arm64: kexec: arm64_relocate_new_kernel clean-ups
	  arm64: kexec: arm64_relocate_new_kernel don't use x0 as temp
	  arm64: kexec: add expandable argument to relocation function
	- arm64: kexec: configure trans_pgd page table for kexec
	  Added invalid entries into EL2 vector table
	  Removed KEXEC_EL2_VECTOR_TABLE_SIZE and KEXEC_EL2_VECTOR_TABLE_OFFSET
	  Copy relocation functions and table into separate pages
	  Changed types in kern_reloc_arg.
	  Split into three patches:
	  arm64: kexec: offset for relocation function
	  arm64: kexec: kexec EL2 vectors
	  arm64: kexec: configure trans_pgd page table for kexec
	- arm64: kexec: enable MMU during kexec relocation
	  Split into two patches:
	  arm64: kexec: enable MMU during kexec relocation
	  arm64: kexec: remove head from relocation argument
v6:
	- Sync with mainline tip
	- Added Acked's from Dave Young
v5:
	- Addressed comments from Matthias Brugger: added review-by's, improved
	  comments, and made cleanups to swsusp_arch_resume() in addition to
	  create_safe_exec_page().
	- Synced with mainline tip.
v4:
	- Addressed comments from James Morse.
	- Split "check pgd table allocation" into two patches, and moved to
	  the beginning of series  for simpler backport of the fixes.
	  Added "Fixes:" tags to commit logs.
	- Changed "arm64, hibernate:" to "arm64: hibernate:"
	- Added Reviewed-by's
	- Moved "add PUD_SECT_RDONLY" earlier in series to be with other
	  clean-ups
	- Added "Derived from:" to arch/arm64/mm/trans_pgd.c
	- Removed "flags" from trans_info
	- Changed .trans_alloc_page assumption to return zeroed page.
	- Simplify changes to trans_pgd_map_page(), by keeping the old
	  code.
	- Simplify changes to trans_pgd_create_copy, by keeping the old
	  code.
	- Removed: "add trans_pgd_create_empty"
	- replace init_mm with NULL, and keep using non "__" version of
	  populate functions.
v3:
	- Split changes to create_safe_exec_page() into several patches for
	  easier review as request by Mark Rutland. This is why this series
	  has 3 more patches.
	- Renamed trans_table to tans_pgd as agreed with Mark. The header
	  comment in trans_pgd.c explains that trans stands for
	  transitional page tables. Meaning they are used in transition
	  between two kernels.
v2:
	- Fixed hibernate bug reported by James Morse
	- Addressed comments from James Morse:
	  * More incremental changes to trans_table
	  * Removed TRANS_FORCEMAP
	  * Added kexec reboot data for image with 380M in size.

Enable MMU during kexec relocation in order to improve reboot performance.

If kexec functionality is used for a fast system update, with a minimal
downtime, the relocation of kernel + initramfs takes a significant portion
of reboot.

The reason for slow relocation is because it is done without MMU, and thus
not benefiting from D-Cache.

Performance data
----------------

Cavium ThunderX2:
Kernel Image size: 38M Iniramfs size: 46M Total relocation size: 84M
MMU-disabled:
relocation	7.489539915s
MMU-enabled:
relocation	0.03946095s

Relocation performance is improved 190 times.

Broadcom Stingray:
For this experiment, the size of kernel plus initramfs is small, only 25M.
If initramfs was larger, than the improvements would be greater, as time
spent in relocation is proportional to the size of relocation.

MMU-disabled::
kernel shutdown	0.022131328s
relocation	0.440510736s
kernel startup	0.294706768s

Relocation was taking: 58.2% of reboot time

MMU-enabled:
kernel shutdown	0.032066576s
relocation	0.022158152s
kernel startup	0.296055880s

Now: Relocation takes 6.3% of reboot time

Total reboot is x2.16 times faster.

With bigger userland (fitImage 380M), the reboot time is improved by 3.57s,
and is reduced from 3.9s down to 0.33s

Previous approaches and discussions
-----------------------------------
v12: https://lore.kernel.org/lkml/20210303002230.1083176-1-pasha.tatashin at soleen.com
v11: https://lore.kernel.org/lkml/20210127172706.617195-1-pasha.tatashin at soleen.com
v10: https://lore.kernel.org/linux-arm-kernel/20210125191923.1060122-1-pasha.tatashin at soleen.com
v9: https://lore.kernel.org/lkml/20200326032420.27220-1-pasha.tatashin at soleen.com
v8: https://lore.kernel.org/lkml/20191204155938.2279686-1-pasha.tatashin at soleen.com
v7: https://lore.kernel.org/lkml/20191016200034.1342308-1-pasha.tatashin at soleen.com
v6: https://lore.kernel.org/lkml/20191004185234.31471-1-pasha.tatashin at soleen.com
v5: https://lore.kernel.org/lkml/20190923203427.294286-1-pasha.tatashin at soleen.com
v4: https://lore.kernel.org/lkml/20190909181221.309510-1-pasha.tatashin at soleen.com
v3: https://lore.kernel.org/lkml/20190821183204.23576-1-pasha.tatashin at soleen.com
v2: https://lore.kernel.org/lkml/20190817024629.26611-1-pasha.tatashin at soleen.com
v1: https://lore.kernel.org/lkml/20190801152439.11363-1-pasha.tatashin at soleen.com

James Morse (4):
  arm64: hyp-stub: Check the size of the HYP stub's vectors
  arm64: hyp-stub: Move invalid vector entries into the vectors
  arm64: hyp-stub: Move el1_sync into the vectors
  arm64: kexec: Use dcache ops macros instead of open-coding

Pavel Tatashin (13):
  arm64: kernel: add helper for booted at EL2 and not VHE
  arm64: trans_pgd: hibernate: Add trans_pgd_copy_el2_vectors
  arm64: hibernate: abstract ttrb0 setup function
  arm64: kexec: flush image and lists during kexec load time
  arm64: kexec: skip relocation code for inplace kexec
  arm64: kexec: pass kimage as the only argument to relocation function
  arm64: kexec: kexec may require EL2 vectors
  arm64: kexec: relocate in EL1 mode
  arm64: kexec: use ld script for relocation function
  arm64: kexec: install a copy of the linear-map
  arm64: kexec: keep MMU enabled during kexec relocation
  arm64: kexec: remove the pre-kexec PoC maintenance
  arm64: kexec: Remove cpu-reset.h

Pingfan Liu (1):
  arm64/mm: remove useless trans_pgd_map_page()

 arch/arm64/Kconfig                   |   2 +-
 arch/arm64/include/asm/assembler.h   |  31 ++++-
 arch/arm64/include/asm/kexec.h       |  12 ++
 arch/arm64/include/asm/mmu_context.h |  24 ++++
 arch/arm64/include/asm/sections.h    |   1 +
 arch/arm64/include/asm/trans_pgd.h   |   8 +-
 arch/arm64/include/asm/virt.h        |   8 ++
 arch/arm64/kernel/asm-offsets.c      |  11 ++
 arch/arm64/kernel/cpu-reset.S        |   7 +-
 arch/arm64/kernel/cpu-reset.h        |  32 -----
 arch/arm64/kernel/hibernate-asm.S    |  20 ----
 arch/arm64/kernel/hibernate.c        |  56 +++------
 arch/arm64/kernel/hyp-stub.S         |  95 +++++++--------
 arch/arm64/kernel/machine_kexec.c    | 168 +++++++++++++++------------
 arch/arm64/kernel/relocate_kernel.S  |  72 ++++++------
 arch/arm64/kernel/sdei.c             |   2 +-
 arch/arm64/kernel/vmlinux.lds.S      |  19 +++
 arch/arm64/mm/trans_pgd.c            |  77 ++++--------
 18 files changed, 315 insertions(+), 330 deletions(-)
 delete mode 100644 arch/arm64/kernel/cpu-reset.h

-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:20 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:20 -0400
Subject: [PATCH v13 01/18] arm64: hyp-stub: Check the size of the HYP stub's
 vectors
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-2-pasha.tatashin@soleen.com>

From: James Morse <james.morse at arm.com>

Hibernate contains a set of temporary EL2 vectors used to 'park'
EL2 somewhere safe while all the memory is thrown in the air.
Making kexec do its relocations with the MMU on means they have to
be done at EL1, so EL2 has to be parked. This means yet another
set of vectors.

All these things do is HVC_SET_VECTORS and HVC_SOFT_RESTART, both
of which are implemented by the hyp-stub. Lets copy it instead
of re-inventing it.

To do this the hyp-stub's entrails need to be packed neatly inside
its 2K vectors.

Start by moving the final 2K alignment inside the end marker, and
add a build check that we didn't overflow 2K.

Signed-off-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/hyp-stub.S | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 5eccbd62fec8..572b28646005 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -41,9 +41,13 @@ SYM_CODE_START(__hyp_stub_vectors)
 	ventry	el1_irq_invalid			// IRQ 32-bit EL1
 	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
 	ventry	el1_error_invalid		// Error 32-bit EL1
+	.align 11
+SYM_INNER_LABEL(__hyp_stub_vectors_end, SYM_L_LOCAL)
 SYM_CODE_END(__hyp_stub_vectors)
 
-	.align 11
+# Check the __hyp_stub_vectors didn't overflow
+.org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K
+
 
 SYM_CODE_START_LOCAL(el1_sync)
 	cmp	x0, #HVC_SET_VECTORS
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:21 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:21 -0400
Subject: [PATCH v13 02/18] arm64: hyp-stub: Move invalid vector entries into
 the vectors
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-3-pasha.tatashin@soleen.com>

From: James Morse <james.morse at arm.com>

Most of the hyp-stub's vector entries are invalid. These are each
a unique function that branches to itself. To move these into the
vectors, merge the ventry and invalid_vector macros and give each
one a unique name.

This means we can copy the hyp-stub as it is self contained within
its vectors.

Signed-off-by: James Morse <james.morse at arm.com>

[Fixed merging issues]

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/hyp-stub.S | 56 +++++++++++++++---------------------
 1 file changed, 23 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 572b28646005..ff329c5c074d 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -16,31 +16,38 @@
 #include <asm/ptrace.h>
 #include <asm/virt.h>
 
+.macro invalid_vector	label
+SYM_CODE_START_LOCAL(\label)
+	.align 7
+	b	\label
+SYM_CODE_END(\label)
+.endm
+
 	.text
 	.pushsection	.hyp.text, "ax"
 
 	.align 11
 
 SYM_CODE_START(__hyp_stub_vectors)
-	ventry	el2_sync_invalid		// Synchronous EL2t
-	ventry	el2_irq_invalid			// IRQ EL2t
-	ventry	el2_fiq_invalid			// FIQ EL2t
-	ventry	el2_error_invalid		// Error EL2t
+	invalid_vector	hyp_stub_el2t_sync_invalid	// Synchronous EL2t
+	invalid_vector	hyp_stub_el2t_irq_invalid	// IRQ EL2t
+	invalid_vector	hyp_stub_el2t_fiq_invalid	// FIQ EL2t
+	invalid_vector	hyp_stub_el2t_error_invalid	// Error EL2t
 
-	ventry	el2_sync_invalid		// Synchronous EL2h
-	ventry	el2_irq_invalid			// IRQ EL2h
-	ventry	el2_fiq_invalid			// FIQ EL2h
-	ventry	el2_error_invalid		// Error EL2h
+	invalid_vector	hyp_stub_el2h_sync_invalid	// Synchronous EL2h
+	invalid_vector	hyp_stub_el2h_irq_invalid	// IRQ EL2h
+	invalid_vector	hyp_stub_el2h_fiq_invalid	// FIQ EL2h
+	invalid_vector	hyp_stub_el2h_error_invalid	// Error EL2h
 
 	ventry	el1_sync			// Synchronous 64-bit EL1
-	ventry	el1_irq_invalid			// IRQ 64-bit EL1
-	ventry	el1_fiq_invalid			// FIQ 64-bit EL1
-	ventry	el1_error_invalid		// Error 64-bit EL1
-
-	ventry	el1_sync_invalid		// Synchronous 32-bit EL1
-	ventry	el1_irq_invalid			// IRQ 32-bit EL1
-	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
-	ventry	el1_error_invalid		// Error 32-bit EL1
+	invalid_vector	hyp_stub_el1_irq_invalid	// IRQ 64-bit EL1
+	invalid_vector	hyp_stub_el1_fiq_invalid	// FIQ 64-bit EL1
+	invalid_vector	hyp_stub_el1_error_invalid	// Error 64-bit EL1
+
+	invalid_vector	hyp_stub_32b_el1_sync_invalid	// Synchronous 32-bit EL1
+	invalid_vector	hyp_stub_32b_el1_irq_invalid	// IRQ 32-bit EL1
+	invalid_vector	hyp_stub_32b_el1_fiq_invalid	// FIQ 32-bit EL1
+	invalid_vector	hyp_stub_32b_el1_error_invalid	// Error 32-bit EL1
 	.align 11
 SYM_INNER_LABEL(__hyp_stub_vectors_end, SYM_L_LOCAL)
 SYM_CODE_END(__hyp_stub_vectors)
@@ -173,23 +180,6 @@ SYM_CODE_END(enter_vhe)
 
 	.popsection
 
-.macro invalid_vector	label
-SYM_CODE_START_LOCAL(\label)
-	b \label
-SYM_CODE_END(\label)
-.endm
-
-	invalid_vector	el2_sync_invalid
-	invalid_vector	el2_irq_invalid
-	invalid_vector	el2_fiq_invalid
-	invalid_vector	el2_error_invalid
-	invalid_vector	el1_sync_invalid
-	invalid_vector	el1_irq_invalid
-	invalid_vector	el1_fiq_invalid
-	invalid_vector	el1_error_invalid
-
-	.popsection
-
 /*
  * __hyp_set_vectors: Call this after boot to set the initial hypervisor
  * vectors as part of hypervisor installation.  On an SMP system, this should
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:22 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:22 -0400
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-4-pasha.tatashin@soleen.com>

From: James Morse <james.morse at arm.com>

The hyp-stub's el1_sync code doesn't do very much, this can easily fit
in the vectors.

With this, all of the hyp-stubs behaviour is contained in its vectors.
This lets kexec and hibernate copy the hyp-stub when they need its
behaviour, instead of re-implementing it.

Signed-off-by: James Morse <james.morse at arm.com>

[Fixed merging issues]

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index ff329c5c074d..d1a73d0f74e0 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label)
 	.align 7
 	b	\label
 SYM_CODE_END(\label)
+.endm
+
+.macro hyp_stub_el1_sync
+SYM_CODE_START_LOCAL(hyp_stub_el1_sync)
+	.align 7
+	cmp	x0, #HVC_SET_VECTORS
+	b.ne	2f
+	msr	vbar_el2, x1
+	b	9f
+
+2:	cmp	x0, #HVC_SOFT_RESTART
+	b.ne	3f
+	mov	x0, x2
+	mov	x2, x4
+	mov	x4, x1
+	mov	x1, x3
+	br	x4				// no return
+
+3:	cmp	x0, #HVC_RESET_VECTORS
+	beq	9f				// Nothing to reset!
+
+	/* Someone called kvm_call_hyp() against the hyp-stub... */
+	mov_q	x0, HVC_STUB_ERR
+	eret
+
+9:	mov	x0, xzr
+	eret
+SYM_CODE_END(hyp_stub_el1_sync)
 .endm
 
 	.text
@@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors)
 	invalid_vector	hyp_stub_el2h_fiq_invalid	// FIQ EL2h
 	invalid_vector	hyp_stub_el2h_error_invalid	// Error EL2h
 
-	ventry	el1_sync			// Synchronous 64-bit EL1
+	hyp_stub_el1_sync				// Synchronous 64-bit EL1
 	invalid_vector	hyp_stub_el1_irq_invalid	// IRQ 64-bit EL1
 	invalid_vector	hyp_stub_el1_fiq_invalid	// FIQ 64-bit EL1
 	invalid_vector	hyp_stub_el1_error_invalid	// Error 64-bit EL1
@@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors)
 # Check the __hyp_stub_vectors didn't overflow
 .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K
 
-
-SYM_CODE_START_LOCAL(el1_sync)
-	cmp	x0, #HVC_SET_VECTORS
-	b.ne	1f
-	msr	vbar_el2, x1
-	b	9f
-
-1:	cmp	x0, #HVC_VHE_RESTART
-	b.eq	mutate_to_vhe
-
-2:	cmp	x0, #HVC_SOFT_RESTART
-	b.ne	3f
-	mov	x0, x2
-	mov	x2, x4
-	mov	x4, x1
-	mov	x1, x3
-	br	x4				// no return
-
-3:	cmp	x0, #HVC_RESET_VECTORS
-	beq	9f				// Nothing to reset!
-
-	/* Someone called kvm_call_hyp() against the hyp-stub... */
-	mov_q	x0, HVC_STUB_ERR
-	eret
-
-9:	mov	x0, xzr
-	eret
-SYM_CODE_END(el1_sync)
-
 // nVHE? No way! Give me the real thing!
 SYM_CODE_START_LOCAL(mutate_to_vhe)
 	// Sanity check: MMU *must* be off
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:24 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:24 -0400
Subject: [PATCH v13 05/18] arm64: trans_pgd: hibernate: Add
 trans_pgd_copy_el2_vectors
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-6-pasha.tatashin@soleen.com>

Users of trans_pgd may also need a copy of vector table because it is
also may be overwritten if a linear map can be overwritten.

Move setup of EL2 vectors from hibernate to trans_pgd, so it can be
later shared with kexec as well.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/trans_pgd.h |  3 +++
 arch/arm64/include/asm/virt.h      |  3 +++
 arch/arm64/kernel/hibernate.c      | 28 ++++++++++------------------
 arch/arm64/mm/trans_pgd.c          | 20 ++++++++++++++++++++
 4 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/trans_pgd.h b/arch/arm64/include/asm/trans_pgd.h
index 5d08e5adf3d5..e0760e52d36d 100644
--- a/arch/arm64/include/asm/trans_pgd.h
+++ b/arch/arm64/include/asm/trans_pgd.h
@@ -36,4 +36,7 @@ int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
 int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 			 unsigned long *t0sz, void *page);
 
+int trans_pgd_copy_el2_vectors(struct trans_pgd_info *info,
+			       phys_addr_t *el2_vectors);
+
 #endif /* _ASM_TRANS_TABLE_H */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 4216c8623538..bfbb66018114 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -67,6 +67,9 @@
  */
 extern u32 __boot_cpu_mode[2];
 
+extern char __hyp_stub_vectors[];
+#define ARM64_VECTOR_TABLE_LEN	SZ_2K
+
 void __hyp_set_vectors(phys_addr_t phys_vector_base);
 void __hyp_reset_vectors(void);
 
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index c764574a1acb..0b8bad8bb6eb 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -48,12 +48,6 @@
  */
 extern int in_suspend;
 
-/* temporary el2 vectors in the __hibernate_exit_text section. */
-extern char hibernate_el2_vectors[];
-
-/* hyp-stub vectors, used to restore el2 during resume from hibernate. */
-extern char __hyp_stub_vectors[];
-
 /*
  * The logical cpu number we should resume on, initialised to a non-cpu
  * number.
@@ -428,6 +422,7 @@ int swsusp_arch_resume(void)
 	void *zero_page;
 	size_t exit_size;
 	pgd_t *tmp_pg_dir;
+	phys_addr_t el2_vectors;
 	void __noreturn (*hibernate_exit)(phys_addr_t, phys_addr_t, void *,
 					  void *, phys_addr_t, phys_addr_t);
 	struct trans_pgd_info trans_info = {
@@ -455,6 +450,14 @@ int swsusp_arch_resume(void)
 		return -ENOMEM;
 	}
 
+	if (is_hyp_callable()) {
+		rc = trans_pgd_copy_el2_vectors(&trans_info, &el2_vectors);
+		if (rc) {
+			pr_err("Failed to setup el2 vectors\n");
+			return rc;
+		}
+	}
+
 	exit_size = __hibernate_exit_text_end - __hibernate_exit_text_start;
 	/*
 	 * Copy swsusp_arch_suspend_exit() to a safe page. This will generate
@@ -467,25 +470,14 @@ int swsusp_arch_resume(void)
 		return rc;
 	}
 
-	/*
-	 * The hibernate exit text contains a set of el2 vectors, that will
-	 * be executed at el2 with the mmu off in order to reload hyp-stub.
-	 */
-	__flush_dcache_area(hibernate_exit, exit_size);
-
 	/*
 	 * KASLR will cause the el2 vectors to be in a different location in
 	 * the resumed kernel. Load hibernate's temporary copy into el2.
 	 *
 	 * We can skip this step if we booted at EL1, or are running with VHE.
 	 */
-	if (is_hyp_callable()) {
-		phys_addr_t el2_vectors = (phys_addr_t)hibernate_exit;
-		el2_vectors += hibernate_el2_vectors -
-			       __hibernate_exit_text_start;     /* offset */
-
+	if (is_hyp_callable())
 		__hyp_set_vectors(el2_vectors);
-	}
 
 	hibernate_exit(virt_to_phys(tmp_pg_dir), resume_hdr.ttbr1_el1,
 		       resume_hdr.reenter_kernel, restore_pblist,
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 527f0a39c3da..61549451ed3a 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -322,3 +322,23 @@ int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 
 	return 0;
 }
+
+/*
+ * Create a copy of the vector table so we can call HVC_SET_VECTORS or
+ * HVC_SOFT_RESTART from contexts where the table may be overwritten.
+ */
+int trans_pgd_copy_el2_vectors(struct trans_pgd_info *info,
+			       phys_addr_t *el2_vectors)
+{
+	void *hyp_stub = trans_alloc(info);
+
+	if (!hyp_stub)
+		return -ENOMEM;
+	*el2_vectors = virt_to_phys(hyp_stub);
+	memcpy(hyp_stub, &__hyp_stub_vectors, ARM64_VECTOR_TABLE_LEN);
+	__flush_icache_range((unsigned long)hyp_stub,
+			     (unsigned long)hyp_stub + ARM64_VECTOR_TABLE_LEN);
+	__flush_dcache_area(hyp_stub, ARM64_VECTOR_TABLE_LEN);
+
+	return 0;
+}
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:23 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:23 -0400
Subject: [PATCH v13 04/18] arm64: kernel: add helper for booted at EL2 and not
 VHE
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-5-pasha.tatashin@soleen.com>

Replace places that contain logic like this:
	is_hyp_mode_available() && !is_kernel_in_hyp_mode()

With a dedicated boolean function  is_hyp_callable(). This will be needed
later in kexec in order to sooner switch back to EL2.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/virt.h | 5 +++++
 arch/arm64/kernel/cpu-reset.h | 3 +--
 arch/arm64/kernel/hibernate.c | 9 +++------
 arch/arm64/kernel/sdei.c      | 2 +-
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7379f35ae2c6..4216c8623538 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -128,6 +128,11 @@ static __always_inline bool is_protected_kvm_enabled(void)
 		return cpus_have_final_cap(ARM64_KVM_PROTECTED_MODE);
 }
 
+static inline bool is_hyp_callable(void)
+{
+	return is_hyp_mode_available() && !is_kernel_in_hyp_mode();
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* ! __ASM__VIRT_H */
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index ed50e9587ad8..1922e7a690f8 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -20,8 +20,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
 {
 	typeof(__cpu_soft_restart) *restart;
 
-	unsigned long el2_switch = !is_kernel_in_hyp_mode() &&
-		is_hyp_mode_available();
+	unsigned long el2_switch = is_hyp_callable();
 	restart = (void *)__pa_symbol(__cpu_soft_restart);
 
 	cpu_install_idmap();
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index b1cef371df2b..c764574a1acb 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -48,9 +48,6 @@
  */
 extern int in_suspend;
 
-/* Do we need to reset el2? */
-#define el2_reset_needed() (is_hyp_mode_available() && !is_kernel_in_hyp_mode())
-
 /* temporary el2 vectors in the __hibernate_exit_text section. */
 extern char hibernate_el2_vectors[];
 
@@ -125,7 +122,7 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
 	hdr->reenter_kernel	= _cpu_resume;
 
 	/* We can't use __hyp_get_vectors() because kvm may still be loaded */
-	if (el2_reset_needed())
+	if (is_hyp_callable())
 		hdr->__hyp_stub_vectors = __pa_symbol(__hyp_stub_vectors);
 	else
 		hdr->__hyp_stub_vectors = 0;
@@ -387,7 +384,7 @@ int swsusp_arch_suspend(void)
 		dcache_clean_range(__idmap_text_start, __idmap_text_end);
 
 		/* Clean kvm setup code to PoC? */
-		if (el2_reset_needed()) {
+		if (is_hyp_callable()) {
 			dcache_clean_range(__hyp_idmap_text_start, __hyp_idmap_text_end);
 			dcache_clean_range(__hyp_text_start, __hyp_text_end);
 		}
@@ -482,7 +479,7 @@ int swsusp_arch_resume(void)
 	 *
 	 * We can skip this step if we booted at EL1, or are running with VHE.
 	 */
-	if (el2_reset_needed()) {
+	if (is_hyp_callable()) {
 		phys_addr_t el2_vectors = (phys_addr_t)hibernate_exit;
 		el2_vectors += hibernate_el2_vectors -
 			       __hibernate_exit_text_start;     /* offset */
diff --git a/arch/arm64/kernel/sdei.c b/arch/arm64/kernel/sdei.c
index 2c7ca449dd51..af0ac2f920cf 100644
--- a/arch/arm64/kernel/sdei.c
+++ b/arch/arm64/kernel/sdei.c
@@ -200,7 +200,7 @@ unsigned long sdei_arch_get_entry_point(int conduit)
 	 * dropped to EL1 because we don't support VHE, then we can't support
 	 * SDEI.
 	 */
-	if (is_hyp_mode_available() && !is_kernel_in_hyp_mode()) {
+	if (is_hyp_callable()) {
 		pr_err("Not supported on this hardware/boot configuration\n");
 		goto out_err;
 	}
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:25 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:25 -0400
Subject: [PATCH v13 06/18] arm64: hibernate: abstract ttrb0 setup function
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-7-pasha.tatashin@soleen.com>

Currently, only hibernate sets custom ttbr0 with safe idmaped function.
Kexec, is also going to be using this functinality when relocation code
is going to be idmapped.

Move the setup seqeuence to a dedicated cpu_install_ttbr0() for custom
ttbr0.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/mmu_context.h | 24 ++++++++++++++++++++++++
 arch/arm64/kernel/hibernate.c        | 21 +--------------------
 2 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index bd02e99b1a4c..f64d0d5e1b1f 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -115,6 +115,30 @@ static inline void cpu_install_idmap(void)
 	cpu_switch_mm(lm_alias(idmap_pg_dir), &init_mm);
 }
 
+/*
+ * Load our new page tables. A strict BBM approach requires that we ensure that
+ * TLBs are free of any entries that may overlap with the global mappings we are
+ * about to install.
+ *
+ * For a real hibernate/resume/kexec cycle TTBR0 currently points to a zero
+ * page, but TLBs may contain stale ASID-tagged entries (e.g. for EFI runtime
+ * services), while for a userspace-driven test_resume cycle it points to
+ * userspace page tables (and we must point it at a zero page ourselves).
+ *
+ * We change T0SZ as part of installing the idmap. This is undone by
+ * cpu_uninstall_idmap() in __cpu_suspend_exit().
+ */
+static inline void cpu_install_ttbr0(phys_addr_t ttbr0, unsigned long t0sz)
+{
+	cpu_set_reserved_ttbr0();
+	local_flush_tlb_all();
+	__cpu_set_tcr_t0sz(t0sz);
+
+	/* avoid cpu_switch_mm() and its SW-PAN and CNP interactions */
+	write_sysreg(ttbr0, ttbr0_el1);
+	isb();
+}
+
 /*
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 0b8bad8bb6eb..ded5115bcb63 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -206,26 +206,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
 	if (rc)
 		return rc;
 
-	/*
-	 * Load our new page tables. A strict BBM approach requires that we
-	 * ensure that TLBs are free of any entries that may overlap with the
-	 * global mappings we are about to install.
-	 *
-	 * For a real hibernate/resume cycle TTBR0 currently points to a zero
-	 * page, but TLBs may contain stale ASID-tagged entries (e.g. for EFI
-	 * runtime services), while for a userspace-driven test_resume cycle it
-	 * points to userspace page tables (and we must point it at a zero page
-	 * ourselves).
-	 *
-	 * We change T0SZ as part of installing the idmap. This is undone by
-	 * cpu_uninstall_idmap() in __cpu_suspend_exit().
-	 */
-	cpu_set_reserved_ttbr0();
-	local_flush_tlb_all();
-	__cpu_set_tcr_t0sz(t0sz);
-	write_sysreg(trans_ttbr0, ttbr0_el1);
-	isb();
-
+	cpu_install_ttbr0(trans_ttbr0, t0sz);
 	*phys_dst_addr = virt_to_phys(page);
 
 	return 0;
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:27 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:27 -0400
Subject: [PATCH v13 08/18] arm64: kexec: skip relocation code for inplace kexec
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-9-pasha.tatashin@soleen.com>

In case of kdump or when segments are already in place the relocation
is not needed, therefore the setup of relocation function and call to
it can be skipped.

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
Suggested-by: James Morse <james.morse at arm.com>
---
 arch/arm64/kernel/machine_kexec.c   | 34 ++++++++++++++++++-----------
 arch/arm64/kernel/relocate_kernel.S |  3 ---
 2 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 3a034bc25709..b150b65f0b84 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -139,21 +139,23 @@ int machine_kexec_post_load(struct kimage *kimage)
 {
 	void *reloc_code = page_to_virt(kimage->control_code_page);
 
-	/* If in place flush new kernel image, else flush lists and buffers */
-	if (kimage->head & IND_DONE)
+	/* If in place, relocation is not used, only flush next kernel */
+	if (kimage->head & IND_DONE) {
 		kexec_segment_flush(kimage);
-	else
-		kexec_list_flush(kimage);
+		kexec_image_info(kimage);
+		return 0;
+	}
 
 	memcpy(reloc_code, arm64_relocate_new_kernel,
 	       arm64_relocate_new_kernel_size);
 	kimage->arch.kern_reloc = __pa(reloc_code);
-	kexec_image_info(kimage);
 
 	/* Flush the reloc_code in preparation for its execution. */
 	__flush_dcache_area(reloc_code, arm64_relocate_new_kernel_size);
 	flush_icache_range((uintptr_t)reloc_code, (uintptr_t)reloc_code +
 			   arm64_relocate_new_kernel_size);
+	kexec_list_flush(kimage);
+	kexec_image_info(kimage);
 
 	return 0;
 }
@@ -180,19 +182,25 @@ void machine_kexec(struct kimage *kimage)
 	local_daif_mask();
 
 	/*
-	 * cpu_soft_restart will shutdown the MMU, disable data caches, then
-	 * transfer control to the kern_reloc which contains a copy of
-	 * the arm64_relocate_new_kernel routine.  arm64_relocate_new_kernel
-	 * uses physical addressing to relocate the new image to its final
-	 * position and transfers control to the image entry point when the
-	 * relocation is complete.
+	 * Both restart and cpu_soft_restart will shutdown the MMU, disable data
+	 * caches. However, restart will start new kernel or purgatory directly,
+	 * cpu_soft_restart will transfer control to arm64_relocate_new_kernel
 	 * In kexec case, kimage->start points to purgatory assuming that
 	 * kernel entry and dtb address are embedded in purgatory by
 	 * userspace (kexec-tools).
 	 * In kexec_file case, the kernel starts directly without purgatory.
 	 */
-	cpu_soft_restart(kimage->arch.kern_reloc, kimage->head, kimage->start,
-			 kimage->arch.dtb_mem);
+	if (kimage->head & IND_DONE) {
+		typeof(__cpu_soft_restart) *restart;
+
+		cpu_install_idmap();
+		restart = (void *)__pa_symbol(__cpu_soft_restart);
+		restart(is_hyp_callable(), kimage->start, kimage->arch.dtb_mem,
+			0, 0);
+	} else {
+		cpu_soft_restart(kimage->arch.kern_reloc, kimage->head,
+				 kimage->start, kimage->arch.dtb_mem);
+	}
 
 	BUG(); /* Should never get here. */
 }
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index b78ea5de97a4..8058fabe0a76 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -32,8 +32,6 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	mov	x16, x0				/* x16 = kimage_head */
 	mov	x14, xzr			/* x14 = entry ptr */
 	mov	x13, xzr			/* x13 = copy dest */
-	/* Check if the new image needs relocation. */
-	tbnz	x16, IND_DONE_BIT, .Ldone
 	raw_dcache_line_size x15, x1		/* x15 = dcache line size */
 .Lloop:
 	and	x12, x16, PAGE_MASK		/* x12 = addr */
@@ -65,7 +63,6 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 .Lnext:
 	ldr	x16, [x14], #8			/* entry = *ptr++ */
 	tbz	x16, IND_DONE_BIT, .Lloop	/* while (!(entry & DONE)) */
-.Ldone:
 	/* wait for writes from copy_page to finish */
 	dsb	nsh
 	ic	iallu
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:26 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:26 -0400
Subject: [PATCH v13 07/18] arm64: kexec: flush image and lists during kexec
 load time
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-8-pasha.tatashin@soleen.com>

Currently, during kexec load we are copying relocation function and
flushing it. However, we can also flush kexec relocation buffers and
if new kernel image is already in place (i.e. crash kernel), we can
also flush the new kernel image itself.

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/machine_kexec.c | 49 +++++++++++++++----------------
 1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 90a335c74442..3a034bc25709 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -59,23 +59,6 @@ void machine_kexec_cleanup(struct kimage *kimage)
 	/* Empty routine needed to avoid build errors. */
 }
 
-int machine_kexec_post_load(struct kimage *kimage)
-{
-	void *reloc_code = page_to_virt(kimage->control_code_page);
-
-	memcpy(reloc_code, arm64_relocate_new_kernel,
-	       arm64_relocate_new_kernel_size);
-	kimage->arch.kern_reloc = __pa(reloc_code);
-	kexec_image_info(kimage);
-
-	/* Flush the reloc_code in preparation for its execution. */
-	__flush_dcache_area(reloc_code, arm64_relocate_new_kernel_size);
-	flush_icache_range((uintptr_t)reloc_code, (uintptr_t)reloc_code +
-			   arm64_relocate_new_kernel_size);
-
-	return 0;
-}
-
 /**
  * machine_kexec_prepare - Prepare for a kexec reboot.
  *
@@ -152,6 +135,29 @@ static void kexec_segment_flush(const struct kimage *kimage)
 	}
 }
 
+int machine_kexec_post_load(struct kimage *kimage)
+{
+	void *reloc_code = page_to_virt(kimage->control_code_page);
+
+	/* If in place flush new kernel image, else flush lists and buffers */
+	if (kimage->head & IND_DONE)
+		kexec_segment_flush(kimage);
+	else
+		kexec_list_flush(kimage);
+
+	memcpy(reloc_code, arm64_relocate_new_kernel,
+	       arm64_relocate_new_kernel_size);
+	kimage->arch.kern_reloc = __pa(reloc_code);
+	kexec_image_info(kimage);
+
+	/* Flush the reloc_code in preparation for its execution. */
+	__flush_dcache_area(reloc_code, arm64_relocate_new_kernel_size);
+	flush_icache_range((uintptr_t)reloc_code, (uintptr_t)reloc_code +
+			   arm64_relocate_new_kernel_size);
+
+	return 0;
+}
+
 /**
  * machine_kexec - Do the kexec reboot.
  *
@@ -169,13 +175,6 @@ void machine_kexec(struct kimage *kimage)
 	WARN(in_kexec_crash && (stuck_cpus || smp_crash_stop_failed()),
 		"Some CPUs may be stale, kdump will be unreliable.\n");
 
-	/* Flush the kimage list and its buffers. */
-	kexec_list_flush(kimage);
-
-	/* Flush the new image if already in place. */
-	if ((kimage != kexec_crash_image) && (kimage->head & IND_DONE))
-		kexec_segment_flush(kimage);
-
 	pr_info("Bye!\n");
 
 	local_daif_mask();
@@ -250,8 +249,6 @@ void arch_kexec_protect_crashkres(void)
 {
 	int i;
 
-	kexec_segment_flush(kexec_crash_image);
-
 	for (i = 0; i < kexec_crash_image->nr_segments; i++)
 		set_memory_valid(
 			__phys_to_virt(kexec_crash_image->segment[i].mem),
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:28 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:28 -0400
Subject: [PATCH v13 09/18] arm64: kexec: Use dcache ops macros instead of
 open-coding
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-10-pasha.tatashin@soleen.com>

From: James Morse <james.morse at arm.com>

kexec does dcache maintenance when it re-writes all memory. Our
dcache_by_line_op macro depends on reading the sanitised DminLine
from memory. Kexec may have overwritten this, so open-codes the
sequence.

dcache_by_line_op is a whole set of macros, it uses dcache_line_size
which uses read_ctr for the sanitsed DminLine. Reading the DminLine
is the first thing the dcache_by_line_op does.

Rename dcache_by_line_op dcache_by_myline_op and take DminLine as
an argument. Kexec can now use the slightly smaller macro.

This makes up-coming changes to the dcache maintenance easier on
the eye.

Code generated by the existing callers is unchanged.

Signed-off-by: James Morse <james.morse at arm.com>

[Fixed merging issues]

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/assembler.h  | 12 ++++++++----
 arch/arm64/kernel/relocate_kernel.S | 13 +++----------
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index ca31594d3d6c..29061b76aab6 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -371,10 +371,9 @@ alternative_else
 alternative_endif
 	.endm
 
-	.macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
-	dcache_line_size \tmp1, \tmp2
+	.macro dcache_by_myline_op op, domain, kaddr, size, linesz, tmp2
 	add	\size, \kaddr, \size
-	sub	\tmp2, \tmp1, #1
+	sub	\tmp2, \linesz, #1
 	bic	\kaddr, \kaddr, \tmp2
 9998:
 	.ifc	\op, cvau
@@ -394,12 +393,17 @@ alternative_endif
 	.endif
 	.endif
 	.endif
-	add	\kaddr, \kaddr, \tmp1
+	add	\kaddr, \kaddr, \linesz
 	cmp	\kaddr, \size
 	b.lo	9998b
 	dsb	\domain
 	.endm
 
+	.macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
+	dcache_line_size \tmp1, \tmp2
+	dcache_by_myline_op \op, \domain, \kaddr, \size, \tmp1, \tmp2
+	.endm
+
 /*
  * Macro to perform an instruction cache maintenance for the interval
  * [start, end)
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index 8058fabe0a76..718037bef560 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -41,16 +41,9 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	tbz	x16, IND_SOURCE_BIT, .Ltest_indirection
 
 	/* Invalidate dest page to PoC. */
-	mov     x2, x13
-	add     x20, x2, #PAGE_SIZE
-	sub     x1, x15, #1
-	bic     x2, x2, x1
-2:	dc      ivac, x2
-	add     x2, x2, x15
-	cmp     x2, x20
-	b.lo    2b
-	dsb     sy
-
+	mov	x2, x13
+	mov	x1, #PAGE_SIZE
+	dcache_by_myline_op ivac, sy, x2, x1, x15, x20
 	copy_page x13, x12, x1, x2, x3, x4, x5, x6, x7, x8
 	b	.Lnext
 .Ltest_indirection:
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:29 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:29 -0400
Subject: [PATCH v13 10/18] arm64: kexec: pass kimage as the only argument to
 relocation function
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-11-pasha.tatashin@soleen.com>

Currently, kexec relocation function (arm64_relocate_new_kernel) accepts
the following arguments:

head:		start of array that contains relocation information.
entry:		entry point for new kernel or purgatory.
dtb_mem:	first and only argument to entry.

The number of arguments cannot be easily expended, because this
function is also called from HVC_SOFT_RESTART, which preserves only
three arguments. And, also arm64_relocate_new_kernel is written in
assembly but called without stack, thus no place to move extra arguments
to free registers.

Soon, we will need to pass more arguments: once we enable MMU we
will need to pass information about page tables.

Pass kimage to arm64_relocate_new_kernel, and teach it to get the
required fields from kimage.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/asm-offsets.c     |  7 +++++++
 arch/arm64/kernel/machine_kexec.c   |  6 ++++--
 arch/arm64/kernel/relocate_kernel.S | 10 ++++------
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index a36e2fc330d4..0c92e193f866 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -9,6 +9,7 @@
 
 #include <linux/arm_sdei.h>
 #include <linux/sched.h>
+#include <linux/kexec.h>
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
 #include <linux/kvm_host.h>
@@ -153,6 +154,12 @@ int main(void)
   DEFINE(PTRAUTH_USER_KEY_APGA,		offsetof(struct ptrauth_keys_user, apga));
   DEFINE(PTRAUTH_KERNEL_KEY_APIA,	offsetof(struct ptrauth_keys_kernel, apia));
   BLANK();
+#endif
+#ifdef CONFIG_KEXEC_CORE
+  DEFINE(KIMAGE_ARCH_DTB_MEM,		offsetof(struct kimage, arch.dtb_mem));
+  DEFINE(KIMAGE_HEAD,			offsetof(struct kimage, head));
+  DEFINE(KIMAGE_START,			offsetof(struct kimage, start));
+  BLANK();
 #endif
   return 0;
 }
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index b150b65f0b84..2e734e4ae12e 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -83,6 +83,8 @@ static void kexec_list_flush(struct kimage *kimage)
 {
 	kimage_entry_t *entry;
 
+	__flush_dcache_area(kimage, sizeof(*kimage));
+
 	for (entry = &kimage->head; ; entry++) {
 		unsigned int flag;
 		void *addr;
@@ -198,8 +200,8 @@ void machine_kexec(struct kimage *kimage)
 		restart(is_hyp_callable(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
-		cpu_soft_restart(kimage->arch.kern_reloc, kimage->head,
-				 kimage->start, kimage->arch.dtb_mem);
+		cpu_soft_restart(kimage->arch.kern_reloc, virt_to_phys(kimage),
+				 0, 0);
 	}
 
 	BUG(); /* Should never get here. */
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index 718037bef560..36b4496524c3 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -27,9 +27,7 @@
  */
 SYM_CODE_START(arm64_relocate_new_kernel)
 	/* Setup the list loop variables. */
-	mov	x18, x2				/* x18 = dtb address */
-	mov	x17, x1				/* x17 = kimage_start */
-	mov	x16, x0				/* x16 = kimage_head */
+	ldr	x16, [x0, #KIMAGE_HEAD]		/* x16 = kimage_head */
 	mov	x14, xzr			/* x14 = entry ptr */
 	mov	x13, xzr			/* x13 = copy dest */
 	raw_dcache_line_size x15, x1		/* x15 = dcache line size */
@@ -63,12 +61,12 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	isb
 
 	/* Start new image. */
-	mov	x0, x18
+	ldr	x4, [x0, #KIMAGE_START]		/* relocation start */
+	ldr	x0, [x0, #KIMAGE_ARCH_DTB_MEM]	/* dtb address */
 	mov	x1, xzr
 	mov	x2, xzr
 	mov	x3, xzr
-	br	x17
-
+	br	x4
 SYM_CODE_END(arm64_relocate_new_kernel)
 
 .align 3	/* To keep the 64-bit values below naturally aligned. */
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:31 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:31 -0400
Subject: [PATCH v13 12/18] arm64: kexec: relocate in EL1 mode
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-13-pasha.tatashin@soleen.com>

Since we are going to keep MMU enabled during relocation, we need to
keep EL1 mode throughout the relocation.

Keep EL1 enabled, and switch EL2 only before enterying the new world.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/cpu-reset.h       |  3 +--
 arch/arm64/kernel/machine_kexec.c   |  4 ++--
 arch/arm64/kernel/relocate_kernel.S | 13 +++++++++++--
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index 1922e7a690f8..f6d95512fec6 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -20,11 +20,10 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
 {
 	typeof(__cpu_soft_restart) *restart;
 
-	unsigned long el2_switch = is_hyp_callable();
 	restart = (void *)__pa_symbol(__cpu_soft_restart);
 
 	cpu_install_idmap();
-	restart(el2_switch, entry, arg0, arg1, arg2);
+	restart(0, entry, arg0, arg1, arg2);
 	unreachable();
 }
 
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index fb03b6676fb9..d5940b7889f8 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -231,8 +231,8 @@ void machine_kexec(struct kimage *kimage)
 	} else {
 		if (is_hyp_callable())
 			__hyp_set_vectors(kimage->arch.el2_vectors);
-		cpu_soft_restart(kimage->arch.kern_reloc, virt_to_phys(kimage),
-				 0, 0);
+		cpu_soft_restart(kimage->arch.kern_reloc,
+				 virt_to_phys(kimage), 0, 0);
 	}
 
 	BUG(); /* Should never get here. */
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index 36b4496524c3..df023b82544b 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -13,6 +13,7 @@
 #include <asm/kexec.h>
 #include <asm/page.h>
 #include <asm/sysreg.h>
+#include <asm/virt.h>
 
 /*
  * arm64_relocate_new_kernel - Put a 2nd stage image in place and boot it.
@@ -61,12 +62,20 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	isb
 
 	/* Start new image. */
+	ldr	x1, [x0, #KIMAGE_ARCH_EL2_VECTORS]	/* relocation start */
+	cbz	x1, .Lel1
+	ldr	x1, [x0, #KIMAGE_START]		/* relocation start */
+	ldr	x2, [x0, #KIMAGE_ARCH_DTB_MEM]	/* dtb address */
+	mov	x3, xzr
+	mov	x4, xzr
+	mov     x0, #HVC_SOFT_RESTART
+	hvc	#0				/* Jumps from el2 */
+.Lel1:
 	ldr	x4, [x0, #KIMAGE_START]		/* relocation start */
 	ldr	x0, [x0, #KIMAGE_ARCH_DTB_MEM]	/* dtb address */
-	mov	x1, xzr
 	mov	x2, xzr
 	mov	x3, xzr
-	br	x4
+	br	x4				/* Jumps from el1 */
 SYM_CODE_END(arm64_relocate_new_kernel)
 
 .align 3	/* To keep the 64-bit values below naturally aligned. */
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:30 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:30 -0400
Subject: [PATCH v13 11/18] arm64: kexec: kexec may require EL2 vectors
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-12-pasha.tatashin@soleen.com>

If we have a EL2 mode without VHE, the EL2 vectors are needed in order
to switch to EL2 and jump to new world with hypervisor privileges.

In preporation to MMU enabled relocation, configure our EL2 table now.

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/Kconfig                |  2 +-
 arch/arm64/include/asm/kexec.h    |  1 +
 arch/arm64/kernel/asm-offsets.c   |  1 +
 arch/arm64/kernel/machine_kexec.c | 31 +++++++++++++++++++++++++++++++
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..0e876d980a1f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1149,7 +1149,7 @@ config CRASH_DUMP
 
 config TRANS_TABLE
 	def_bool y
-	depends on HIBERNATION
+	depends on HIBERNATION || KEXEC_CORE
 
 config XEN_DOM0
 	def_bool y
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 9befcd87e9a8..305cf0840ed3 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -96,6 +96,7 @@ struct kimage_arch {
 	void *dtb;
 	phys_addr_t dtb_mem;
 	phys_addr_t kern_reloc;
+	phys_addr_t el2_vectors;
 	/* Core ELF header buffer */
 	void *elf_headers;
 	unsigned long elf_headers_mem;
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 0c92e193f866..2e3278df1fc3 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -157,6 +157,7 @@ int main(void)
 #endif
 #ifdef CONFIG_KEXEC_CORE
   DEFINE(KIMAGE_ARCH_DTB_MEM,		offsetof(struct kimage, arch.dtb_mem));
+  DEFINE(KIMAGE_ARCH_EL2_VECTORS,	offsetof(struct kimage, arch.el2_vectors));
   DEFINE(KIMAGE_HEAD,			offsetof(struct kimage, head));
   DEFINE(KIMAGE_START,			offsetof(struct kimage, start));
   BLANK();
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 2e734e4ae12e..fb03b6676fb9 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -20,6 +20,7 @@
 #include <asm/mmu.h>
 #include <asm/mmu_context.h>
 #include <asm/page.h>
+#include <asm/trans_pgd.h>
 
 #include "cpu-reset.h"
 
@@ -42,7 +43,9 @@ static void _kexec_image_info(const char *func, int line,
 	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",
@@ -137,9 +140,27 @@ static void kexec_segment_flush(const struct kimage *kimage)
 	}
 }
 
+/* Allocates pages for kexec page table */
+static void *kexec_page_alloc(void *arg)
+{
+	struct kimage *kimage = (struct kimage *)arg;
+	struct page *page = kimage_alloc_control_pages(kimage, 0);
+
+	if (!page)
+		return NULL;
+
+	memset(page_address(page), 0, PAGE_SIZE);
+
+	return page_address(page);
+}
+
 int machine_kexec_post_load(struct kimage *kimage)
 {
 	void *reloc_code = page_to_virt(kimage->control_code_page);
+	struct trans_pgd_info info = {
+		.trans_alloc_page	= kexec_page_alloc,
+		.trans_alloc_arg	= kimage,
+	};
 
 	/* If in place, relocation is not used, only flush next kernel */
 	if (kimage->head & IND_DONE) {
@@ -148,6 +169,14 @@ int machine_kexec_post_load(struct kimage *kimage)
 		return 0;
 	}
 
+	kimage->arch.el2_vectors = 0;
+	if (is_hyp_callable()) {
+		int rc = trans_pgd_copy_el2_vectors(&info,
+						    &kimage->arch.el2_vectors);
+		if (rc)
+			return rc;
+	}
+
 	memcpy(reloc_code, arm64_relocate_new_kernel,
 	       arm64_relocate_new_kernel_size);
 	kimage->arch.kern_reloc = __pa(reloc_code);
@@ -200,6 +229,8 @@ void machine_kexec(struct kimage *kimage)
 		restart(is_hyp_callable(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
+		if (is_hyp_callable())
+			__hyp_set_vectors(kimage->arch.el2_vectors);
 		cpu_soft_restart(kimage->arch.kern_reloc, virt_to_phys(kimage),
 				 0, 0);
 	}
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:33 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:33 -0400
Subject: [PATCH v13 14/18] arm64: kexec: install a copy of the linear-map
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-15-pasha.tatashin@soleen.com>

To perform the kexec relocations with the MMU enabled, we need a copy
of the linear map.

Create one, and install it from the relocation code. This has to be done
from the assembly code as it will be idmapped with TTBR0. The kernel
runs in TTRB1, so can't use the break-before-make sequence on the mapping
it is executing from.

The makes no difference yet as the relocation code runs with the MMU
disabled.

Co-developed-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/assembler.h  | 19 +++++++++++++++++++
 arch/arm64/include/asm/kexec.h      |  2 ++
 arch/arm64/kernel/asm-offsets.c     |  2 ++
 arch/arm64/kernel/hibernate-asm.S   | 20 --------------------
 arch/arm64/kernel/machine_kexec.c   | 16 ++++++++++++++--
 arch/arm64/kernel/relocate_kernel.S |  3 +++
 6 files changed, 40 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 29061b76aab6..3ce8131ad660 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -425,6 +425,25 @@ USER(\label, ic	ivau, \tmp2)			// invalidate I line PoU
 	isb
 	.endm
 
+/*
+ * To prevent the possibility of old and new partial table walks being visible
+ * in the tlb, switch the ttbr to a zero page when we invalidate the old
+ * records. D4.7.1 'General TLB maintenance requirements' in ARM DDI 0487A.i
+ * Even switching to our copied tables will cause a changed output address at
+ * each stage of the walk.
+ */
+	.macro break_before_make_ttbr_switch zero_page, page_table, tmp, tmp2
+	phys_to_ttbr \tmp, \zero_page
+	msr	ttbr1_el1, \tmp
+	isb
+	tlbi	vmalle1
+	dsb	nsh
+	phys_to_ttbr \tmp, \page_table
+	offset_ttbr1 \tmp, \tmp2
+	msr	ttbr1_el1, \tmp
+	isb
+	.endm
+
 /*
  * reset_pmuserenr_el0 - reset PMUSERENR_EL0 if PMUv3 present
  */
diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 305cf0840ed3..59ac166daf53 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -97,6 +97,8 @@ struct kimage_arch {
 	phys_addr_t dtb_mem;
 	phys_addr_t kern_reloc;
 	phys_addr_t el2_vectors;
+	phys_addr_t ttbr1;
+	phys_addr_t zero_page;
 	/* Core ELF header buffer */
 	void *elf_headers;
 	unsigned long elf_headers_mem;
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 2e3278df1fc3..609362b5aa76 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -158,6 +158,8 @@ int main(void)
 #ifdef CONFIG_KEXEC_CORE
   DEFINE(KIMAGE_ARCH_DTB_MEM,		offsetof(struct kimage, arch.dtb_mem));
   DEFINE(KIMAGE_ARCH_EL2_VECTORS,	offsetof(struct kimage, arch.el2_vectors));
+  DEFINE(KIMAGE_ARCH_ZERO_PAGE,		offsetof(struct kimage, arch.zero_page));
+  DEFINE(KIMAGE_ARCH_TTBR1,		offsetof(struct kimage, arch.ttbr1));
   DEFINE(KIMAGE_HEAD,			offsetof(struct kimage, head));
   DEFINE(KIMAGE_START,			offsetof(struct kimage, start));
   BLANK();
diff --git a/arch/arm64/kernel/hibernate-asm.S b/arch/arm64/kernel/hibernate-asm.S
index 8ccca660034e..a31e621ba867 100644
--- a/arch/arm64/kernel/hibernate-asm.S
+++ b/arch/arm64/kernel/hibernate-asm.S
@@ -15,26 +15,6 @@
 #include <asm/page.h>
 #include <asm/virt.h>
 
-/*
- * To prevent the possibility of old and new partial table walks being visible
- * in the tlb, switch the ttbr to a zero page when we invalidate the old
- * records. D4.7.1 'General TLB maintenance requirements' in ARM DDI 0487A.i
- * Even switching to our copied tables will cause a changed output address at
- * each stage of the walk.
- */
-.macro break_before_make_ttbr_switch zero_page, page_table, tmp, tmp2
-	phys_to_ttbr \tmp, \zero_page
-	msr	ttbr1_el1, \tmp
-	isb
-	tlbi	vmalle1
-	dsb	nsh
-	phys_to_ttbr \tmp, \page_table
-	offset_ttbr1 \tmp, \tmp2
-	msr	ttbr1_el1, \tmp
-	isb
-.endm
-
-
 /*
  * Resume from hibernate
  *
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index f1451d807708..c875ef522e53 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -153,6 +153,8 @@ static void *kexec_page_alloc(void *arg)
 
 int machine_kexec_post_load(struct kimage *kimage)
 {
+	int rc;
+	pgd_t *trans_pgd;
 	void *reloc_code = page_to_virt(kimage->control_code_page);
 	long reloc_size;
 	struct trans_pgd_info info = {
@@ -169,12 +171,22 @@ int machine_kexec_post_load(struct kimage *kimage)
 
 	kimage->arch.el2_vectors = 0;
 	if (is_hyp_callable()) {
-		int rc = trans_pgd_copy_el2_vectors(&info,
-						    &kimage->arch.el2_vectors);
+		rc = trans_pgd_copy_el2_vectors(&info,
+						&kimage->arch.el2_vectors);
 		if (rc)
 			return rc;
 	}
 
+	/* Create a copy of the linear map */
+	trans_pgd = kexec_page_alloc(kimage);
+	if (!trans_pgd)
+		return -ENOMEM;
+	rc = trans_pgd_create_copy(&info, &trans_pgd, PAGE_OFFSET, PAGE_END);
+	if (rc)
+		return rc;
+	kimage->arch.ttbr1 = __pa(trans_pgd);
+	kimage->arch.zero_page = __pa(empty_zero_page);
+
 	reloc_size = __relocate_new_kernel_end - __relocate_new_kernel_start;
 	memcpy(reloc_code, __relocate_new_kernel_start, reloc_size);
 	kimage->arch.kern_reloc = __pa(reloc_code);
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index 7a600ba33ae1..e83b6380907d 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -29,10 +29,13 @@
  */
 SYM_CODE_START(arm64_relocate_new_kernel)
 	/* Setup the list loop variables. */
+	ldr	x18, [x0, #KIMAGE_ARCH_ZERO_PAGE] /* x18 = zero page for BBM */
+	ldr	x17, [x0, #KIMAGE_ARCH_TTBR1]	/* x17 = linear map copy */
 	ldr	x16, [x0, #KIMAGE_HEAD]		/* x16 = kimage_head */
 	mov	x14, xzr			/* x14 = entry ptr */
 	mov	x13, xzr			/* x13 = copy dest */
 	raw_dcache_line_size x15, x1		/* x15 = dcache line size */
+	break_before_make_ttbr_switch	x18, x17, x1, x2 /* set linear map */
 .Lloop:
 	and	x12, x16, PAGE_MASK		/* x12 = addr */
 
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:34 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:34 -0400
Subject: [PATCH v13 15/18] arm64: kexec: keep MMU enabled during kexec
 relocation
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-16-pasha.tatashin@soleen.com>

Now, that we have linear map page tables configured, keep MMU enabled
to allow faster relocation of segments to final destination.


Cavium ThunderX2:
Kernel Image size: 38M Iniramfs size: 46M Total relocation size: 84M
MMU-disabled:
relocation	7.489539915s
MMU-enabled:
relocation	0.03946095s

Broadcom Stingray:
The performance data: for a moderate size kernel + initramfs: 25M the
relocation was taking 0.382s, with enabled MMU it now takes
0.019s only or x20 improvement.

The time is proportional to the size of relocation, therefore if initramfs
is larger, 100M it could take over a second.

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/kexec.h      |  3 +++
 arch/arm64/kernel/asm-offsets.c     |  1 +
 arch/arm64/kernel/machine_kexec.c   | 16 ++++++++++----
 arch/arm64/kernel/relocate_kernel.S | 33 +++++++++++++++++++----------
 4 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 59ac166daf53..5fc87b51f8a9 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -97,8 +97,11 @@ struct kimage_arch {
 	phys_addr_t dtb_mem;
 	phys_addr_t kern_reloc;
 	phys_addr_t el2_vectors;
+	phys_addr_t ttbr0;
 	phys_addr_t ttbr1;
 	phys_addr_t zero_page;
+	unsigned long phys_offset;
+	unsigned long t0sz;
 	/* Core ELF header buffer */
 	void *elf_headers;
 	unsigned long elf_headers_mem;
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 609362b5aa76..ec7bb80aedc8 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -159,6 +159,7 @@ int main(void)
   DEFINE(KIMAGE_ARCH_DTB_MEM,		offsetof(struct kimage, arch.dtb_mem));
   DEFINE(KIMAGE_ARCH_EL2_VECTORS,	offsetof(struct kimage, arch.el2_vectors));
   DEFINE(KIMAGE_ARCH_ZERO_PAGE,		offsetof(struct kimage, arch.zero_page));
+  DEFINE(KIMAGE_ARCH_PHYS_OFFSET,	offsetof(struct kimage, arch.phys_offset));
   DEFINE(KIMAGE_ARCH_TTBR1,		offsetof(struct kimage, arch.ttbr1));
   DEFINE(KIMAGE_HEAD,			offsetof(struct kimage, head));
   DEFINE(KIMAGE_START,			offsetof(struct kimage, start));
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index c875ef522e53..d5c8aefc66f3 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -190,6 +190,11 @@ int machine_kexec_post_load(struct kimage *kimage)
 	reloc_size = __relocate_new_kernel_end - __relocate_new_kernel_start;
 	memcpy(reloc_code, __relocate_new_kernel_start, reloc_size);
 	kimage->arch.kern_reloc = __pa(reloc_code);
+	rc = trans_pgd_idmap_page(&info, &kimage->arch.ttbr0,
+				  &kimage->arch.t0sz, reloc_code);
+	if (rc)
+		return rc;
+	kimage->arch.phys_offset = virt_to_phys(kimage) - (long)kimage;
 
 	/* Flush the reloc_code in preparation for its execution. */
 	__flush_dcache_area(reloc_code, reloc_size);
@@ -223,9 +228,9 @@ void machine_kexec(struct kimage *kimage)
 	local_daif_mask();
 
 	/*
-	 * Both restart and cpu_soft_restart will shutdown the MMU, disable data
+	 * Both restart and kernel_reloc will shutdown the MMU, disable data
 	 * caches. However, restart will start new kernel or purgatory directly,
-	 * cpu_soft_restart will transfer control to arm64_relocate_new_kernel
+	 * kernel_reloc contains the body of arm64_relocate_new_kernel
 	 * In kexec case, kimage->start points to purgatory assuming that
 	 * kernel entry and dtb address are embedded in purgatory by
 	 * userspace (kexec-tools).
@@ -239,10 +244,13 @@ void machine_kexec(struct kimage *kimage)
 		restart(is_hyp_callable(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
+		void (*kernel_reloc)(struct kimage *kimage);
+
 		if (is_hyp_callable())
 			__hyp_set_vectors(kimage->arch.el2_vectors);
-		cpu_soft_restart(kimage->arch.kern_reloc,
-				 virt_to_phys(kimage), 0, 0);
+		cpu_install_ttbr0(kimage->arch.ttbr0, kimage->arch.t0sz);
+		kernel_reloc = (void *)kimage->arch.kern_reloc;
+		kernel_reloc(kimage);
 	}
 
 	BUG(); /* Should never get here. */
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index e83b6380907d..433a57b3d76e 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -4,6 +4,8 @@
  *
  * Copyright (C) Linaro.
  * Copyright (C) Huawei Futurewei Technologies.
+ * Copyright (C) 2020, Microsoft Corporation.
+ * Pavel Tatashin <pasha.tatashin at soleen.com>
  */
 
 #include <linux/kexec.h>
@@ -15,6 +17,15 @@
 #include <asm/sysreg.h>
 #include <asm/virt.h>
 
+.macro turn_off_mmu tmp1, tmp2
+	mrs	\tmp1, sctlr_el1
+	mov_q	\tmp2, SCTLR_ELx_FLAGS
+	bic	\tmp1, \tmp1, \tmp2
+	pre_disable_mmu_workaround
+	msr	sctlr_el1, \tmp1
+	isb
+.endm
+
 .pushsection    ".kexec_relocate.text", "ax"
 /*
  * arm64_relocate_new_kernel - Put a 2nd stage image in place and boot it.
@@ -32,22 +43,21 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	ldr	x18, [x0, #KIMAGE_ARCH_ZERO_PAGE] /* x18 = zero page for BBM */
 	ldr	x17, [x0, #KIMAGE_ARCH_TTBR1]	/* x17 = linear map copy */
 	ldr	x16, [x0, #KIMAGE_HEAD]		/* x16 = kimage_head */
-	mov	x14, xzr			/* x14 = entry ptr */
-	mov	x13, xzr			/* x13 = copy dest */
+	ldr	x22, [x0, #KIMAGE_ARCH_PHYS_OFFSET]	/* x22 phys_offset */
 	raw_dcache_line_size x15, x1		/* x15 = dcache line size */
 	break_before_make_ttbr_switch	x18, x17, x1, x2 /* set linear map */
 .Lloop:
 	and	x12, x16, PAGE_MASK		/* x12 = addr */
-
+	sub	x12, x12, x22			/* Convert x12 to virt */
 	/* Test the entry flags. */
 .Ltest_source:
 	tbz	x16, IND_SOURCE_BIT, .Ltest_indirection
 
 	/* Invalidate dest page to PoC. */
-	mov	x2, x13
-	mov	x1, #PAGE_SIZE
-	dcache_by_myline_op ivac, sy, x2, x1, x15, x20
+	mov	x19, x13
 	copy_page x13, x12, x1, x2, x3, x4, x5, x6, x7, x8
+	mov	x1, #PAGE_SIZE
+	dcache_by_myline_op civac, sy, x19, x1, x15, x20
 	b	.Lnext
 .Ltest_indirection:
 	tbz	x16, IND_INDIRECTION_BIT, .Ltest_destination
@@ -64,19 +74,20 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	ic	iallu
 	dsb	nsh
 	isb
+	ldr	x4, [x0, #KIMAGE_START]			/* relocation start */
+	ldr	x1, [x0, #KIMAGE_ARCH_EL2_VECTORS]	/* relocation start */
+	ldr	x0, [x0, #KIMAGE_ARCH_DTB_MEM]		/* dtb address */
+	turn_off_mmu x12, x13
 
 	/* Start new image. */
-	ldr	x1, [x0, #KIMAGE_ARCH_EL2_VECTORS]	/* relocation start */
 	cbz	x1, .Lel1
-	ldr	x1, [x0, #KIMAGE_START]		/* relocation start */
-	ldr	x2, [x0, #KIMAGE_ARCH_DTB_MEM]	/* dtb address */
+	mov	x1, x4				/* relocation start */
+	mov	x2, x0				/* dtb address */
 	mov	x3, xzr
 	mov	x4, xzr
 	mov     x0, #HVC_SOFT_RESTART
 	hvc	#0				/* Jumps from el2 */
 .Lel1:
-	ldr	x4, [x0, #KIMAGE_START]		/* relocation start */
-	ldr	x0, [x0, #KIMAGE_ARCH_DTB_MEM]	/* dtb address */
 	mov	x2, xzr
 	mov	x3, xzr
 	br	x4				/* Jumps from el1 */
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:32 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:32 -0400
Subject: [PATCH v13 13/18] arm64: kexec: use ld script for relocation function
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-14-pasha.tatashin@soleen.com>

Currently, relocation code declares start and end variables
which are used to compute its size.

The better way to do this is to use ld script incited, and put relocation
function in its own section.

Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/sections.h   |  1 +
 arch/arm64/kernel/machine_kexec.c   | 14 ++++++--------
 arch/arm64/kernel/relocate_kernel.S | 15 ++-------------
 arch/arm64/kernel/vmlinux.lds.S     | 19 +++++++++++++++++++
 4 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/arch/arm64/include/asm/sections.h b/arch/arm64/include/asm/sections.h
index 2f36b16a5b5d..31e459af89f6 100644
--- a/arch/arm64/include/asm/sections.h
+++ b/arch/arm64/include/asm/sections.h
@@ -20,5 +20,6 @@ extern char __exittext_begin[], __exittext_end[];
 extern char __irqentry_text_start[], __irqentry_text_end[];
 extern char __mmuoff_data_start[], __mmuoff_data_end[];
 extern char __entry_tramp_text_start[], __entry_tramp_text_end[];
+extern char __relocate_new_kernel_start[], __relocate_new_kernel_end[];
 
 #endif /* __ASM_SECTIONS_H */
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index d5940b7889f8..f1451d807708 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -20,14 +20,11 @@
 #include <asm/mmu.h>
 #include <asm/mmu_context.h>
 #include <asm/page.h>
+#include <asm/sections.h>
 #include <asm/trans_pgd.h>
 
 #include "cpu-reset.h"
 
-/* Global variables for the arm64_relocate_new_kernel routine. */
-extern const unsigned char arm64_relocate_new_kernel[];
-extern const unsigned long arm64_relocate_new_kernel_size;
-
 /**
  * kexec_image_info - For debugging output.
  */
@@ -157,6 +154,7 @@ static void *kexec_page_alloc(void *arg)
 int machine_kexec_post_load(struct kimage *kimage)
 {
 	void *reloc_code = page_to_virt(kimage->control_code_page);
+	long reloc_size;
 	struct trans_pgd_info info = {
 		.trans_alloc_page	= kexec_page_alloc,
 		.trans_alloc_arg	= kimage,
@@ -177,14 +175,14 @@ int machine_kexec_post_load(struct kimage *kimage)
 			return rc;
 	}
 
-	memcpy(reloc_code, arm64_relocate_new_kernel,
-	       arm64_relocate_new_kernel_size);
+	reloc_size = __relocate_new_kernel_end - __relocate_new_kernel_start;
+	memcpy(reloc_code, __relocate_new_kernel_start, reloc_size);
 	kimage->arch.kern_reloc = __pa(reloc_code);
 
 	/* Flush the reloc_code in preparation for its execution. */
-	__flush_dcache_area(reloc_code, arm64_relocate_new_kernel_size);
+	__flush_dcache_area(reloc_code, reloc_size);
 	flush_icache_range((uintptr_t)reloc_code, (uintptr_t)reloc_code +
-			   arm64_relocate_new_kernel_size);
+			   reloc_size);
 	kexec_list_flush(kimage);
 	kexec_image_info(kimage);
 
diff --git a/arch/arm64/kernel/relocate_kernel.S b/arch/arm64/kernel/relocate_kernel.S
index df023b82544b..7a600ba33ae1 100644
--- a/arch/arm64/kernel/relocate_kernel.S
+++ b/arch/arm64/kernel/relocate_kernel.S
@@ -15,6 +15,7 @@
 #include <asm/sysreg.h>
 #include <asm/virt.h>
 
+.pushsection    ".kexec_relocate.text", "ax"
 /*
  * arm64_relocate_new_kernel - Put a 2nd stage image in place and boot it.
  *
@@ -77,16 +78,4 @@ SYM_CODE_START(arm64_relocate_new_kernel)
 	mov	x3, xzr
 	br	x4				/* Jumps from el1 */
 SYM_CODE_END(arm64_relocate_new_kernel)
-
-.align 3	/* To keep the 64-bit values below naturally aligned. */
-
-.Lcopy_end:
-.org	KEXEC_CONTROL_PAGE_SIZE
-
-/*
- * arm64_relocate_new_kernel_size - Number of bytes to copy to the
- * control_code_page.
- */
-.globl arm64_relocate_new_kernel_size
-arm64_relocate_new_kernel_size:
-	.quad	.Lcopy_end - arm64_relocate_new_kernel
+.popsection
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7eea7888bb02..0d9d5e6af66f 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -12,6 +12,7 @@
 #include <asm/cache.h>
 #include <asm/hyp_image.h>
 #include <asm/kernel-pgtable.h>
+#include <asm/kexec.h>
 #include <asm/memory.h>
 #include <asm/page.h>
 
@@ -92,6 +93,16 @@ jiffies = jiffies_64;
 #define HIBERNATE_TEXT
 #endif
 
+#ifdef CONFIG_KEXEC_CORE
+#define KEXEC_TEXT					\
+	. = ALIGN(SZ_4K);				\
+	__relocate_new_kernel_start = .;		\
+	*(.kexec_relocate.text)				\
+	__relocate_new_kernel_end = .;
+#else
+#define KEXEC_TEXT
+#endif
+
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
 #define TRAMP_TEXT					\
 	. = ALIGN(PAGE_SIZE);				\
@@ -152,6 +163,7 @@ SECTIONS
 			HYPERVISOR_TEXT
 			IDMAP_TEXT
 			HIBERNATE_TEXT
+			KEXEC_TEXT
 			TRAMP_TEXT
 			*(.fixup)
 			*(.gnu.warning)
@@ -336,3 +348,10 @@ ASSERT(swapper_pg_dir - reserved_pg_dir == RESERVED_SWAPPER_OFFSET,
 ASSERT(swapper_pg_dir - tramp_pg_dir == TRAMP_SWAPPER_OFFSET,
        "TRAMP_SWAPPER_OFFSET is wrong!")
 #endif
+
+#ifdef CONFIG_KEXEC_CORE
+/* kexec relocation code should fit into one KEXEC_CONTROL_PAGE_SIZE */
+ASSERT(__relocate_new_kernel_end - (__relocate_new_kernel_start & ~(SZ_4K - 1))
+	<= SZ_4K, "kexec relocation code is too big or misaligned")
+ASSERT(KEXEC_CONTROL_PAGE_SIZE >= SZ_4K, "KEXEC_CONTROL_PAGE_SIZE is brokern")
+#endif
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:35 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:35 -0400
Subject: [PATCH v13 16/18] arm64: kexec: remove the pre-kexec PoC maintenance
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-17-pasha.tatashin@soleen.com>

Now that kexec does its relocations with the MMU enabled, we no longer
need to clean the relocation data to the PoC.

Co-developed-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/kernel/machine_kexec.c | 40 -------------------------------
 1 file changed, 40 deletions(-)

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index d5c8aefc66f3..a1c9bee0cddd 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -76,45 +76,6 @@ int machine_kexec_prepare(struct kimage *kimage)
 	return 0;
 }
 
-/**
- * kexec_list_flush - Helper to flush the kimage list and source pages to PoC.
- */
-static void kexec_list_flush(struct kimage *kimage)
-{
-	kimage_entry_t *entry;
-
-	__flush_dcache_area(kimage, sizeof(*kimage));
-
-	for (entry = &kimage->head; ; entry++) {
-		unsigned int flag;
-		void *addr;
-
-		/* flush the list entries. */
-		__flush_dcache_area(entry, sizeof(kimage_entry_t));
-
-		flag = *entry & IND_FLAGS;
-		if (flag == IND_DONE)
-			break;
-
-		addr = phys_to_virt(*entry & PAGE_MASK);
-
-		switch (flag) {
-		case IND_INDIRECTION:
-			/* Set entry point just before the new list page. */
-			entry = (kimage_entry_t *)addr - 1;
-			break;
-		case IND_SOURCE:
-			/* flush the source pages. */
-			__flush_dcache_area(addr, PAGE_SIZE);
-			break;
-		case IND_DESTINATION:
-			break;
-		default:
-			BUG();
-		}
-	}
-}
-
 /**
  * kexec_segment_flush - Helper to flush the kimage segments to PoC.
  */
@@ -200,7 +161,6 @@ int machine_kexec_post_load(struct kimage *kimage)
 	__flush_dcache_area(reloc_code, reloc_size);
 	flush_icache_range((uintptr_t)reloc_code, (uintptr_t)reloc_code +
 			   reloc_size);
-	kexec_list_flush(kimage);
 	kexec_image_info(kimage);
 
 	return 0;
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:37 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:37 -0400
Subject: [PATCH v13 18/18] arm64/mm: remove useless trans_pgd_map_page()
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-19-pasha.tatashin@soleen.com>

From: Pingfan Liu <kernelfans at gmail.com>

The intend of trans_pgd_map_page() was to map contigous range of VA
memory to the memory that is getting relocated during kexec. However,
since we are now using linear map instead of contigous range this
function is not needed

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
[Changed commit message]
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/trans_pgd.h |  5 +--
 arch/arm64/mm/trans_pgd.c          | 57 ------------------------------
 2 files changed, 1 insertion(+), 61 deletions(-)

diff --git a/arch/arm64/include/asm/trans_pgd.h b/arch/arm64/include/asm/trans_pgd.h
index e0760e52d36d..234353df2f13 100644
--- a/arch/arm64/include/asm/trans_pgd.h
+++ b/arch/arm64/include/asm/trans_pgd.h
@@ -15,7 +15,7 @@
 /*
  * trans_alloc_page
  *	- Allocator that should return exactly one zeroed page, if this
- *	  allocator fails, trans_pgd_create_copy() and trans_pgd_map_page()
+ *	  allocator fails, trans_pgd_create_copy() and trans_pgd_idmap_page()
  *	  return -ENOMEM error.
  *
  * trans_alloc_arg
@@ -30,9 +30,6 @@ struct trans_pgd_info {
 int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **trans_pgd,
 			  unsigned long start, unsigned long end);
 
-int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
-		       void *page, unsigned long dst_addr, pgprot_t pgprot);
-
 int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 			 unsigned long *t0sz, void *page);
 
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 61549451ed3a..e24a749013c1 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -217,63 +217,6 @@ int trans_pgd_create_copy(struct trans_pgd_info *info, pgd_t **dst_pgdp,
 	return rc;
 }
 
-/*
- * Add map entry to trans_pgd for a base-size page at PTE level.
- * info:	contains allocator and its argument
- * trans_pgd:	page table in which new map is added.
- * page:	page to be mapped.
- * dst_addr:	new VA address for the page
- * pgprot:	protection for the page.
- *
- * Returns 0 on success, and -ENOMEM on failure.
- */
-int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
-		       void *page, unsigned long dst_addr, pgprot_t pgprot)
-{
-	pgd_t *pgdp;
-	p4d_t *p4dp;
-	pud_t *pudp;
-	pmd_t *pmdp;
-	pte_t *ptep;
-
-	pgdp = pgd_offset_pgd(trans_pgd, dst_addr);
-	if (pgd_none(READ_ONCE(*pgdp))) {
-		p4dp = trans_alloc(info);
-		if (!pgdp)
-			return -ENOMEM;
-		pgd_populate(NULL, pgdp, p4dp);
-	}
-
-	p4dp = p4d_offset(pgdp, dst_addr);
-	if (p4d_none(READ_ONCE(*p4dp))) {
-		pudp = trans_alloc(info);
-		if (!pudp)
-			return -ENOMEM;
-		p4d_populate(NULL, p4dp, pudp);
-	}
-
-	pudp = pud_offset(p4dp, dst_addr);
-	if (pud_none(READ_ONCE(*pudp))) {
-		pmdp = trans_alloc(info);
-		if (!pmdp)
-			return -ENOMEM;
-		pud_populate(NULL, pudp, pmdp);
-	}
-
-	pmdp = pmd_offset(pudp, dst_addr);
-	if (pmd_none(READ_ONCE(*pmdp))) {
-		ptep = trans_alloc(info);
-		if (!ptep)
-			return -ENOMEM;
-		pmd_populate_kernel(NULL, pmdp, ptep);
-	}
-
-	ptep = pte_offset_kernel(pmdp, dst_addr);
-	set_pte(ptep, pfn_pte(virt_to_pfn(page), pgprot));
-
-	return 0;
-}
-
 /*
  * The page we want to idmap may be outside the range covered by VA_BITS that
  * can be built using the kernel's p?d_populate() helpers. As a one off, for a
-- 
2.25.1



From pasha.tatashin at soleen.com  Thu Apr  8 05:05:36 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu,  8 Apr 2021 00:05:36 -0400
Subject: [PATCH v13 17/18] arm64: kexec: Remove cpu-reset.h
In-Reply-To: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
Message-ID: <20210408040537.2703241-18-pasha.tatashin@soleen.com>

This header contains only cpu_soft_restart() which is never used directly
anymore. So, remove this header, and rename the helper to be
cpu_soft_restart().

Suggested-by: James Morse <james.morse at arm.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
---
 arch/arm64/include/asm/kexec.h    |  6 ++++++
 arch/arm64/kernel/cpu-reset.S     |  7 +++----
 arch/arm64/kernel/cpu-reset.h     | 30 ------------------------------
 arch/arm64/kernel/machine_kexec.c |  6 ++----
 4 files changed, 11 insertions(+), 38 deletions(-)
 delete mode 100644 arch/arm64/kernel/cpu-reset.h

diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
index 5fc87b51f8a9..ee71ae3b93ed 100644
--- a/arch/arm64/include/asm/kexec.h
+++ b/arch/arm64/include/asm/kexec.h
@@ -90,6 +90,12 @@ static inline void crash_prepare_suspend(void) {}
 static inline void crash_post_resume(void) {}
 #endif
 
+#if defined(CONFIG_KEXEC_CORE)
+void cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
+		      unsigned long arg0, unsigned long arg1,
+		      unsigned long arg2);
+#endif
+
 #define ARCH_HAS_KIMAGE_ARCH
 
 struct kimage_arch {
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 37721eb6f9a1..5d47d6c92634 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -16,8 +16,7 @@
 .pushsection    .idmap.text, "awx"
 
 /*
- * __cpu_soft_restart(el2_switch, entry, arg0, arg1, arg2) - Helper for
- * cpu_soft_restart.
+ * cpu_soft_restart(el2_switch, entry, arg0, arg1, arg2)
  *
  * @el2_switch: Flag to indicate a switch to EL2 is needed.
  * @entry: Location to jump to for soft reset.
@@ -29,7 +28,7 @@
  * branch to what would be the reset vector. It must be executed with the
  * flat identity mapping.
  */
-SYM_CODE_START(__cpu_soft_restart)
+SYM_CODE_START(cpu_soft_restart)
 	/* Clear sctlr_el1 flags. */
 	mrs	x12, sctlr_el1
 	mov_q	x13, SCTLR_ELx_FLAGS
@@ -51,6 +50,6 @@ SYM_CODE_START(__cpu_soft_restart)
 	mov	x1, x3				// arg1
 	mov	x2, x4				// arg2
 	br	x8
-SYM_CODE_END(__cpu_soft_restart)
+SYM_CODE_END(cpu_soft_restart)
 
 .popsection
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
deleted file mode 100644
index f6d95512fec6..000000000000
--- a/arch/arm64/kernel/cpu-reset.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * CPU reset routines
- *
- * Copyright (C) 2015 Huawei Futurewei Technologies.
- */
-
-#ifndef _ARM64_CPU_RESET_H
-#define _ARM64_CPU_RESET_H
-
-#include <asm/virt.h>
-
-void __cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
-	unsigned long arg0, unsigned long arg1, unsigned long arg2);
-
-static inline void __noreturn cpu_soft_restart(unsigned long entry,
-					       unsigned long arg0,
-					       unsigned long arg1,
-					       unsigned long arg2)
-{
-	typeof(__cpu_soft_restart) *restart;
-
-	restart = (void *)__pa_symbol(__cpu_soft_restart);
-
-	cpu_install_idmap();
-	restart(0, entry, arg0, arg1, arg2);
-	unreachable();
-}
-
-#endif
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index a1c9bee0cddd..ef7ba93f2bd6 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -23,8 +23,6 @@
 #include <asm/sections.h>
 #include <asm/trans_pgd.h>
 
-#include "cpu-reset.h"
-
 /**
  * kexec_image_info - For debugging output.
  */
@@ -197,10 +195,10 @@ void machine_kexec(struct kimage *kimage)
 	 * In kexec_file case, the kernel starts directly without purgatory.
 	 */
 	if (kimage->head & IND_DONE) {
-		typeof(__cpu_soft_restart) *restart;
+		typeof(cpu_soft_restart) *restart;
 
 		cpu_install_idmap();
-		restart = (void *)__pa_symbol(__cpu_soft_restart);
+		restart = (void *)__pa_symbol(cpu_soft_restart);
 		restart(is_hyp_callable(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
-- 
2.25.1



From flora.fu at mediatek.com  Thu Apr  8 05:03:51 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 8 Apr 2021 12:03:51 +0800
Subject: [PATCH 5/8] dt-bindings: soc: mediatek: apusys: Add new
 document for APU power domain
In-Reply-To: <1617805692.253379.3696993.nullmailer@robh.at.kernel.org>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-6-git-send-email-flora.fu@mediatek.com>
 <1617805692.253379.3696993.nullmailer@robh.at.kernel.org>
Message-ID: <1617854631.5654.9.camel@mtksdccf07>

Hi, Rob, 

The error is resulted from some un-merged patch.

Please note that the patch depends MT8192 clock patches which haven't yet been accepted.
https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/

Thanks for your review.

On Wed, 2021-04-07 at 09:28 -0500, Rob Herring wrote:
> On Wed, 07 Apr 2021 11:28:03 +0800, Flora Fu wrote:
> > Document the bindings for APU power domain on MediaTek SoC.
> > 
> > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > ---
> >  .../soc/mediatek/mediatek,apu-pm.yaml         | 146 ++++++++++++++++++
> >  1 file changed, 146 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.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/soc/mediatek/mediatek,apu-pm.example.dts:19:18: fatal error: dt-bindings/clock/mt8192-clk.h: No such file or directory
>    19 |         #include <dt-bindings/clock/mt8192-clk.h>
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[1]: *** [scripts/Makefile.lib:377: Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.example.dt.yaml] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:1414: dt_binding_check] Error 2
> 
> See https://urldefense.com/v3/__https://patchwork.ozlabs.org/patch/1463115__;!!CTRNKA9wMg0ARbw!0XUn1LcNHfvUShNClpM_yH73TAR9qdm29SZMckasoCQ8UzeKS-vZW0QUu3Ssn-s6$ 
> 
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
> 
> 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.
> 



From lkp at intel.com  Thu Apr  8 05:30:23 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 12:30:23 +0800
Subject: [soc:k3/dt] BUILD SUCCESS
 112e5934ff3a7505e583365213a27f990922b76b
Message-ID: <606e86df.gsI+LxirtW1MA6+n%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git k3/dt
branch HEAD: 112e5934ff3a7505e583365213a27f990922b76b  arm64: dts: ti: k3-am64-main: Fix ospi compatible

elapsed time: 729m

configs tested: 180
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
arc                          axs101_defconfig
powerpc                      chrp32_defconfig
arm                        keystone_defconfig
alpha                            allyesconfig
sh                            shmin_defconfig
mips                           ci20_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
arm                        oxnas_v6_defconfig
powerpc                      ppc44x_defconfig
mips                           ip28_defconfig
arm                         lpc18xx_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
arm                     eseries_pxa_defconfig
m68k                        m5407c3_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
csky                                defconfig
m68k                        stmark2_defconfig
arm                        spear3xx_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
mips                  maltasmvp_eva_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
sh                          kfr2r09_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
m68k                            q40_defconfig
sparc                       sparc32_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
mips                           gcw0_defconfig
m68k                       m5249evb_defconfig
sh                        sh7763rdp_defconfig
h8300                               defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
um                               allyesconfig
nios2                         3c120_defconfig
powerpc                      ppc40x_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
arm                          iop32x_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210407
x86_64               randconfig-a003-20210407
x86_64               randconfig-a005-20210407
x86_64               randconfig-a001-20210407
x86_64               randconfig-a002-20210407
x86_64               randconfig-a006-20210407

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 05:30:20 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 12:30:20 +0800
Subject: [soc:amlogic/dt] BUILD SUCCESS
 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e
Message-ID: <606e86dc.cSItoN826kCpqO3I%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git amlogic/dt
branch HEAD: 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e  arm64: dts: meson: add initial device-tree for MeCool KIII Pro

elapsed time: 3197m

configs tested: 345
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
mips                        workpad_defconfig
xtensa                generic_kc705_defconfig
sh                         microdev_defconfig
arm                            mmp2_defconfig
sparc64                             defconfig
sh                           se7343_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
mips                      pic32mzda_defconfig
mips                         mpc30x_defconfig
mips                         cobalt_defconfig
sh                          rsk7201_defconfig
arm                        clps711x_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
sh                           se7619_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
mips                      fuloong2e_defconfig
arm                          badge4_defconfig
arm                  colibri_pxa270_defconfig
mips                      maltaaprp_defconfig
ia64                                defconfig
sparc                            alldefconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
arc                         haps_hs_defconfig
sh                        sh7763rdp_defconfig
xtensa                       common_defconfig
openrisc                 simple_smp_defconfig
riscv                          rv32_defconfig
powerpc                        fsp2_defconfig
powerpc                      ppc6xx_defconfig
sh                        apsh4ad0a_defconfig
arm                         lpc32xx_defconfig
arm                      footbridge_defconfig
arm                          ep93xx_defconfig
powerpc                         wii_defconfig
h8300                            alldefconfig
m68k                        stmark2_defconfig
arc                        nsimosci_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
powerpc                 mpc836x_mds_defconfig
arm                            qcom_defconfig
sh                   sh7724_generic_defconfig
mips                malta_qemu_32r6_defconfig
arm                        realview_defconfig
mips                        qi_lb60_defconfig
arm                            hisi_defconfig
arm                        shmobile_defconfig
mips                            ar7_defconfig
arm                           spitz_defconfig
arm                        oxnas_v6_defconfig
powerpc                      ppc44x_defconfig
m68k                            q40_defconfig
powerpc                    mvme5100_defconfig
mips                          ath25_defconfig
powerpc                     tqm8540_defconfig
sh                        sh7785lcr_defconfig
riscv                    nommu_virt_defconfig
arm                     am200epdkit_defconfig
xtensa                  audio_kc705_defconfig
arm                      integrator_defconfig
arm                           sunxi_defconfig
mips                           ip28_defconfig
arm                         lpc18xx_defconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
ia64                             allmodconfig
arm                           corgi_defconfig
sparc                       sparc32_defconfig
um                            kunit_defconfig
arm                         at91_dt_defconfig
powerpc                      arches_defconfig
powerpc                  storcenter_defconfig
m68k                         amcore_defconfig
alpha                            allyesconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
powerpc                   lite5200b_defconfig
parisc                generic-64bit_defconfig
mips                          malta_defconfig
riscv             nommu_k210_sdcard_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                 mpc836x_rdk_defconfig
nds32                             allnoconfig
powerpc                      ppc64e_defconfig
powerpc                      katmai_defconfig
mips                           mtx1_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
powerpc                     tqm8541_defconfig
arm                     eseries_pxa_defconfig
sh                         apsh4a3a_defconfig
sh                          r7785rp_defconfig
arm                       versatile_defconfig
arm                          pcm027_defconfig
m68k                           sun3_defconfig
riscv                    nommu_k210_defconfig
mips                           gcw0_defconfig
parisc                           allyesconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
powerpc                   motionpro_defconfig
sh                          sdk7786_defconfig
powerpc                     stx_gp3_defconfig
m68k                        m5407c3_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
arm                      tct_hammer_defconfig
csky                             alldefconfig
mips                           rs90_defconfig
m68k                       bvme6000_defconfig
sh                           se7780_defconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
csky                                defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
mips                  cavium_octeon_defconfig
arc                     haps_hs_smp_defconfig
m68k                         apollo_defconfig
powerpc                 mpc837x_mds_defconfig
mips                        nlm_xlp_defconfig
arm                           omap1_defconfig
arm                          exynos_defconfig
sh                           sh2007_defconfig
sh                        edosk7705_defconfig
xtensa                  nommu_kc705_defconfig
sh                          polaris_defconfig
mips                         db1xxx_defconfig
arm                           stm32_defconfig
powerpc                       ppc64_defconfig
s390                             allmodconfig
alpha                               defconfig
ia64                      gensparse_defconfig
sh                     magicpanelr2_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                     pq2fads_defconfig
arm                        trizeps4_defconfig
arm                        spear3xx_defconfig
mips                         tb0219_defconfig
arm                       mainstone_defconfig
h8300                    h8300h-sim_defconfig
arm                         shannon_defconfig
powerpc                     tqm5200_defconfig
powerpc                    klondike_defconfig
mips                     cu1000-neo_defconfig
mips                          rb532_defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
mips                  maltasmvp_eva_defconfig
m68k                       m5249evb_defconfig
mips                        omega2p_defconfig
arm                             rpc_defconfig
microblaze                      mmu_defconfig
powerpc                     kilauea_defconfig
arc                          axs101_defconfig
openrisc                  or1klitex_defconfig
arm                        spear6xx_defconfig
mips                    maltaup_xpa_defconfig
arm                      jornada720_defconfig
arm                            zeus_defconfig
sh                   rts7751r2dplus_defconfig
s390                       zfcpdump_defconfig
powerpc                      walnut_defconfig
arm                            xcep_defconfig
mips                      maltasmvp_defconfig
sh                 kfr2r09-romimage_defconfig
sh                          sdk7780_defconfig
sh                        edosk7760_defconfig
sh                          kfr2r09_defconfig
arm                          iop32x_defconfig
arm64                            alldefconfig
mips                       lemote2f_defconfig
openrisc                    or1ksim_defconfig
powerpc                      chrp32_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
nios2                            allyesconfig
mips                           ip32_defconfig
arm                          pxa168_defconfig
arc                           tb10x_defconfig
powerpc                       maple_defconfig
mips                        maltaup_defconfig
powerpc                mpc7448_hpc2_defconfig
powerpc                     tqm8548_defconfig
powerpc                 mpc8313_rdb_defconfig
arm                       aspeed_g4_defconfig
ia64                          tiger_defconfig
mips                        nlm_xlr_defconfig
powerpc                     skiroot_defconfig
powerpc                     kmeter1_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                        vexpress_defconfig
um                               alldefconfig
m68k                       m5208evb_defconfig
arc                            hsdk_defconfig
powerpc                     pseries_defconfig
mips                   sb1250_swarm_defconfig
mips                     loongson1c_defconfig
h8300                               defconfig
sh                          rsk7264_defconfig
powerpc                 canyonlands_defconfig
mips                        vocore2_defconfig
arm                       aspeed_g5_defconfig
arm                           viper_defconfig
mips                 decstation_r4k_defconfig
powerpc                     akebono_defconfig
arc                 nsimosci_hs_smp_defconfig
arm                        keystone_defconfig
xtensa                              defconfig
arm                       imx_v6_v7_defconfig
sh                               j2_defconfig
ia64                         bigsur_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                    vt8500_v6_v7_defconfig
powerpc                 mpc8560_ads_defconfig
powerpc                     sequoia_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                           allnoconfig
arm                           tegra_defconfig
powerpc                      tqm8xx_defconfig
um                               allyesconfig
arm                      pxa255-idp_defconfig
xtensa                          iss_defconfig
nios2                         3c120_defconfig
powerpc                      ppc40x_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                     tqm8560_defconfig
arc                        vdk_hs38_defconfig
sh                          rsk7203_defconfig
sparc                       sparc64_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
x86_64               randconfig-a004-20210406
x86_64               randconfig-a003-20210406
x86_64               randconfig-a005-20210406
x86_64               randconfig-a001-20210406
x86_64               randconfig-a002-20210406
x86_64               randconfig-a006-20210406
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210406
i386                 randconfig-a003-20210406
i386                 randconfig-a001-20210406
i386                 randconfig-a004-20210406
i386                 randconfig-a005-20210406
i386                 randconfig-a002-20210406
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210406
i386                 randconfig-a016-20210406
i386                 randconfig-a011-20210406
i386                 randconfig-a012-20210406
i386                 randconfig-a015-20210406
i386                 randconfig-a013-20210406
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                             allnoconfig
riscv                               defconfig
um                               allmodconfig
um                                allnoconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210406
x86_64               randconfig-a015-20210406
x86_64               randconfig-a013-20210406
x86_64               randconfig-a011-20210406
x86_64               randconfig-a012-20210406
x86_64               randconfig-a016-20210406
x86_64               randconfig-a004-20210407
x86_64               randconfig-a003-20210407
x86_64               randconfig-a005-20210407
x86_64               randconfig-a001-20210407
x86_64               randconfig-a002-20210407
x86_64               randconfig-a006-20210407

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Thu Apr  8 05:30:11 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 12:30:11 +0800
Subject: [soc:omap/dt-2] BUILD SUCCESS ee368a10d0dfb27bbff36361ea2166f864028a8b
Message-ID: <606e86d3.dGmgVarbNuD77jLm%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git omap/dt-2
branch HEAD: ee368a10d0dfb27bbff36361ea2166f864028a8b  ARM: dts: am335x-boneblack.dts: unique gpio-line-names

elapsed time: 11362m

configs tested: 239
configs skipped: 114

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
arm                        oxnas_v6_defconfig
powerpc                      ppc44x_defconfig
mips                           ip28_defconfig
arm                         lpc18xx_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
mips                         db1xxx_defconfig
arm                        cerfcube_defconfig
arm                           tegra_defconfig
sh                              ul2_defconfig
arm                        neponset_defconfig
m68k                         amcore_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
alpha                            allyesconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
arm                     eseries_pxa_defconfig
m68k                        m5407c3_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                            titan_defconfig
arm                        mini2440_defconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
arm                        mvebu_v7_defconfig
x86_64                           alldefconfig
sparc64                             defconfig
m68k                        stmark2_defconfig
arm                        spear3xx_defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                        magician_defconfig
arm                          exynos_defconfig
h8300                               defconfig
arm                  colibri_pxa300_defconfig
arm                         axm55xx_defconfig
mips                  maltasmvp_eva_defconfig
arm                      footbridge_defconfig
powerpc                      katmai_defconfig
mips                             allmodconfig
powerpc                      makalu_defconfig
arm                        multi_v7_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
sh                          kfr2r09_defconfig
arm                          iop32x_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
mips                        workpad_defconfig
sh                           se7722_defconfig
arm                         lpc32xx_defconfig
xtensa                       common_defconfig
arm                     am200epdkit_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
mips                         cobalt_defconfig
m68k                            q40_defconfig
sparc                       sparc32_defconfig
mips                        nlm_xlr_defconfig
sh                          rsk7201_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
powerpc                 mpc834x_mds_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
arm                         bcm2835_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
mips                           gcw0_defconfig
m68k                       m5249evb_defconfig
sh                        sh7763rdp_defconfig
powerpc                         ps3_defconfig
arm                            xcep_defconfig
alpha                               defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                       eiger_defconfig
arm                        multi_v5_defconfig
arm                       spear13xx_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
m68k                       bvme6000_defconfig
powerpc                      ppc40x_defconfig
arm                            mps2_defconfig
sh                     magicpanelr2_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
mips                            ar7_defconfig
powerpc                        fsp2_defconfig
um                               allyesconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
csky                                defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a004-20210407
x86_64               randconfig-a003-20210407
x86_64               randconfig-a005-20210407
x86_64               randconfig-a001-20210407
x86_64               randconfig-a002-20210407
x86_64               randconfig-a006-20210407

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From anshuman.khandual at arm.com  Thu Apr  8 06:12:43 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 8 Apr 2021 10:42:43 +0530
Subject: [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210407172607.8812-4-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-4-rppt@kernel.org>
Message-ID: <7bc09505-72f1-e297-40a9-639b3e9b1c61@arm.com>


On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>   verify that there is actual physical memory that corresponds to a pfn
>   which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>   linear map and until the previous commit the struct pages representing
>   these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.

But what about the memory map that are freed during boot (mentioned above).
Would not they still cause CONFIG_HOLES_IN_ZONE to be applicable and hence
pfn_valid_within() ?

> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().

Just to understand this better, pfn_valid() will now return true for all
MEMBLOCK_NOMAP based memory but that is okay as core MM would still ignore
them as unusable memory for being PageReserved().

> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  arch/arm64/Kconfig   | 3 ---
>  arch/arm64/mm/init.c | 4 ++--
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>  	def_bool y
>  	depends on NUMA
>  
> -config HOLES_IN_ZONE
> -	def_bool y
> -
>  source "kernel/Kconfig.hz"
>  
>  config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 258b1905ed4a..bb6dd406b1f0 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>  
>  	/*
>  	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>  	 * addresses will always fail. Even the normal hotplugged
>  	 * memory will never have MEMBLOCK_NOMAP flag set in their
>  	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>  		return pfn_section_valid(ms, pfn);
>  }
>  #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);
>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> 


From anshuman.khandual at arm.com  Thu Apr  8 06:14:58 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 8 Apr 2021 10:44:58 +0530
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <20210407172607.8812-3-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
Message-ID: <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>


On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.

Should there be a comment affirming this semantics interpretation, above the
generic pfn_valid() in include/linux/mmzone.h ?

> 
> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> linear map vs those that require ioremap() to access them.
> 
> Introduce a dedicated pfn_is_memory() to perform such check and use it
> where appropriate.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  arch/arm64/include/asm/memory.h | 2 +-
>  arch/arm64/include/asm/page.h   | 1 +
>  arch/arm64/kvm/mmu.c            | 2 +-
>  arch/arm64/mm/init.c            | 6 ++++++
>  arch/arm64/mm/ioremap.c         | 4 ++--
>  arch/arm64/mm/mmu.c             | 2 +-
>  6 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..7e77fdf71b9d 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>  
>  #define virt_addr_valid(addr)	({					\
>  	__typeof__(addr) __addr = __tag_reset(addr);			\
> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
>  })
>  
>  void dump_mem_limit(void);
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 012cffc574e8..32b485bcc6ff 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>  typedef struct page *pgtable_t;
>  
>  extern int pfn_valid(unsigned long);
> +extern int pfn_is_memory(unsigned long);
>  
>  #include <asm/memory.h>
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..ad2ea65a3937 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !pfn_is_memory(pfn);
>  }
>  
>  /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..258b1905ed4a 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> +int pfn_is_memory(unsigned long pfn)
> +{
> +	return memblock_is_map_memory(PFN_PHYS(pfn));
> +}
> +EXPORT_SYMBOL(pfn_is_memory);> +

Should not this be generic though ? There is nothing platform or arm64
specific in here. Wondering as pfn_is_memory() just indicates that the
pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
instead ? Regardless, it's fine either way.

>  static phys_addr_t memory_limit = PHYS_ADDR_MAX;
>  
>  /*
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index b5e83c46b23e..82a369b22ef5 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
>  	/*
>  	 * Don't allow RAM to be mapped.
>  	 */
> -	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> +	if (WARN_ON(pfn_is_memory(__phys_to_pfn(phys_addr))))
>  		return NULL;
>  
>  	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> @@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
>  void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
>  {
>  	/* For normal memory we already have a cacheable mapping. */
> -	if (pfn_valid(__phys_to_pfn(phys_addr)))
> +	if (pfn_is_memory(__phys_to_pfn(phys_addr)))
>  		return (void __iomem *)__phys_to_virt(phys_addr);
>  
>  	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 5d9550fdb9cf..038d20fe163f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
>  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>  			      unsigned long size, pgprot_t vma_prot)
>  {
> -	if (!pfn_valid(pfn))
> +	if (!pfn_is_memory(pfn))
>  		return pgprot_noncached(vma_prot);
>  	else if (file->f_flags & O_SYNC)
>  		return pgprot_writecombine(vma_prot);
> 


From anshuman.khandual at arm.com  Thu Apr  8 06:16:18 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 8 Apr 2021 10:46:18 +0530
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <20210407172607.8812-2-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
Message-ID: <064dad68-ca9f-14d3-7859-5321001fbca4@arm.com>



On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().
> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.

This would definitely need updating the comment for MEMBLOCK_NOMAP definition
in include/linux/memblock.h just to make the semantics is clear, though arm64
is currently the only user for MEMBLOCK_NOMAP.

> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  mm/memblock.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..6b7ea9d86310 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>  	return end_pfn - start_pfn;
>  }
>  
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}
> +}
> +
>  static unsigned long __init free_low_memory_core_early(void)
>  {
>  	unsigned long count = 0;
> @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
>  
>  	memblock_clear_hotplug(0, -1);
>  
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>  
>  	/*
>  	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 


From anshuman.khandual at arm.com  Thu Apr  8 06:19:02 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 8 Apr 2021 10:49:02 +0530
Subject: [RFC/RFT PATCH 0/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210407172607.8812-1-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
Message-ID: <2f68ea11-7c56-1c55-f0be-3aad7188c00a@arm.com>

Adding James here.

+ James Morse <james.morse at arm.com>

On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> Hi,
> 
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1. 

That would be really great for arm64 platform as it will save CPU cycles on
many generic MM paths, given that our pfn_valid() has been expensive.

> 
> The idea is to mark NOMAP pages as reserved in the memory map and restore

Though I am not really sure, would that possibly be problematic for UEFI/EFI
use cases as it might have just treated them as normal struct pages till now.

> the intended semantics of pfn_valid() to designate availability of struct
> page for a pfn.

Right, that would be better as the current semantics is not ideal.

> 
> With this the core mm will be able to cope with the fact that it cannot use
> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> will be treated correctly even without the need for pfn_valid_within.
> 
> The patches are only boot tested on qemu-system-aarch64 so I'd really
> appreciate memory stress tests on real hardware.

Did some preliminary memory stress tests on a guest with portions of memory
marked as MEMBLOCK_NOMAP and did not find any obvious problem. But this might
require some testing on real UEFI environment with firmware using MEMBLOCK_NOMAP
memory to make sure that changing these struct pages to PageReserved() is safe.


> 
> If this actually works we'll be one step closer to drop custom pfn_valid()
> on arm64 altogether.

Right, planning to rework and respin the RFC originally sent last month.

https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/


From jianjun.wang at mediatek.com  Thu Apr  8 06:45:07 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Thu, 8 Apr 2021 13:45:07 +0800
Subject: [v9,3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
In-Reply-To: <20210324030510.29177-4-jianjun.wang@mediatek.com>
References: <20210324030510.29177-1-jianjun.wang@mediatek.com>
 <20210324030510.29177-4-jianjun.wang@mediatek.com>
Message-ID: <1617860707.5995.3.camel@mhfsdcap03>

Hi Bjorn, Lorenzo,

Just gentle ping for this patch set, please kindly let me know your
comments about this patch set.

Thanks.

On Wed, 2021-03-24 at 11:05 +0800, Jianjun Wang wrote:
> MediaTek's PCIe host controller has three generation HWs, the new
> generation HW is an individual bridge, it supports Gen3 speed and
> compatible with Gen2, Gen1 speed.
> 
> Add support for new Gen3 controller which can be found on MT8192.
> 
> Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
> Acked-by: Ryder Lee <ryder.lee at mediatek.com>
> ---
>  drivers/pci/controller/Kconfig              |  13 +
>  drivers/pci/controller/Makefile             |   1 +
>  drivers/pci/controller/pcie-mediatek-gen3.c | 464 ++++++++++++++++++++
>  3 files changed, 478 insertions(+)
>  create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c
> 
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 5aa8977d7b0f..1e925ac47279 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -233,6 +233,19 @@ config PCIE_MEDIATEK
>  	  Say Y here if you want to enable PCIe controller support on
>  	  MediaTek SoCs.
>  
> +config PCIE_MEDIATEK_GEN3
> +	tristate "MediaTek Gen3 PCIe controller"
> +	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	depends on PCI_MSI_IRQ_DOMAIN
> +	help
> +	  Adds support for PCIe Gen3 MAC controller for MediaTek SoCs.
> +	  This PCIe controller is compatible with Gen3, Gen2 and Gen1 speed,
> +	  and support up to 256 MSI interrupt numbers for
> +	  multi-function devices.
> +
> +	  Say Y here if you want to enable Gen3 PCIe controller support on
> +	  MediaTek SoCs.
> +
>  config VMD
>  	depends on PCI_MSI && X86_64 && SRCU
>  	tristate "Intel Volume Management Device Driver"
> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
> index e4559f2182f2..579973327815 100644
> --- a/drivers/pci/controller/Makefile
> +++ b/drivers/pci/controller/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
>  obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
>  obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
>  obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> +obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o
>  obj-$(CONFIG_PCIE_MICROCHIP_HOST) += pcie-microchip-host.o
>  obj-$(CONFIG_VMD) += vmd.o
>  obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> new file mode 100644
> index 000000000000..3546e53b3c85
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -0,0 +1,464 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek PCIe host controller driver.
> + *
> + * Copyright (c) 2020 MediaTek Inc.
> + * Author: Jianjun Wang <jianjun.wang at mediatek.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/reset.h>
> +
> +#include "../pci.h"
> +
> +#define PCIE_SETTING_REG		0x80
> +#define PCIE_PCI_IDS_1			0x9c
> +#define PCI_CLASS(class)		(class << 8)
> +#define PCIE_RC_MODE			BIT(0)
> +
> +#define PCIE_CFGNUM_REG			0x140
> +#define PCIE_CFG_DEVFN(devfn)		((devfn) & GENMASK(7, 0))
> +#define PCIE_CFG_BUS(bus)		(((bus) << 8) & GENMASK(15, 8))
> +#define PCIE_CFG_BYTE_EN(bytes)		(((bytes) << 16) & GENMASK(19, 16))
> +#define PCIE_CFG_FORCE_BYTE_EN		BIT(20)
> +#define PCIE_CFG_OFFSET_ADDR		0x1000
> +#define PCIE_CFG_HEADER(bus, devfn) \
> +	(PCIE_CFG_BUS(bus) | PCIE_CFG_DEVFN(devfn))
> +
> +#define PCIE_RST_CTRL_REG		0x148
> +#define PCIE_MAC_RSTB			BIT(0)
> +#define PCIE_PHY_RSTB			BIT(1)
> +#define PCIE_BRG_RSTB			BIT(2)
> +#define PCIE_PE_RSTB			BIT(3)
> +
> +#define PCIE_LTSSM_STATUS_REG		0x150
> +
> +#define PCIE_LINK_STATUS_REG		0x154
> +#define PCIE_PORT_LINKUP		BIT(8)
> +
> +#define PCIE_TRANS_TABLE_BASE_REG	0x800
> +#define PCIE_ATR_SRC_ADDR_MSB_OFFSET	0x4
> +#define PCIE_ATR_TRSL_ADDR_LSB_OFFSET	0x8
> +#define PCIE_ATR_TRSL_ADDR_MSB_OFFSET	0xc
> +#define PCIE_ATR_TRSL_PARAM_OFFSET	0x10
> +#define PCIE_ATR_TLB_SET_OFFSET		0x20
> +
> +#define PCIE_MAX_TRANS_TABLES		8
> +#define PCIE_ATR_EN			BIT(0)
> +#define PCIE_ATR_SIZE(size) \
> +	(((((size) - 1) << 1) & GENMASK(6, 1)) | PCIE_ATR_EN)
> +#define PCIE_ATR_ID(id)			((id) & GENMASK(3, 0))
> +#define PCIE_ATR_TYPE_MEM		PCIE_ATR_ID(0)
> +#define PCIE_ATR_TYPE_IO		PCIE_ATR_ID(1)
> +#define PCIE_ATR_TLP_TYPE(type)		(((type) << 16) & GENMASK(18, 16))
> +#define PCIE_ATR_TLP_TYPE_MEM		PCIE_ATR_TLP_TYPE(0)
> +#define PCIE_ATR_TLP_TYPE_IO		PCIE_ATR_TLP_TYPE(2)
> +
> +/**
> + * struct mtk_pcie_port - 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
> + * @clks: PCIe clocks
> + * @num_clks: PCIe clocks count for this port
> + */
> +struct mtk_pcie_port {
> +	struct device *dev;
> +	void __iomem *base;
> +	phys_addr_t reg_base;
> +	struct reset_control *mac_reset;
> +	struct reset_control *phy_reset;
> +	struct phy *phy;
> +	struct clk_bulk_data *clks;
> +	int num_clks;
> +};
> +
> +/**
> + * mtk_pcie_config_tlp_header() - Configure a configuration TLP header
> + * @bus: PCI bus to query
> + * @devfn: device/function number
> + * @where: offset in config space
> + * @size: data size in TLP header
> + *
> + * Set byte enable field and device information in configuration TLP header.
> + */
> +static void mtk_pcie_config_tlp_header(struct pci_bus *bus, unsigned int devfn,
> +					int where, int size)
> +{
> +	struct mtk_pcie_port *port = bus->sysdata;
> +	int bytes;
> +	u32 val;
> +
> +	bytes = (GENMASK(size - 1, 0) & 0xf) << (where & 0x3);
> +
> +	val = PCIE_CFG_FORCE_BYTE_EN | PCIE_CFG_BYTE_EN(bytes) |
> +	      PCIE_CFG_HEADER(bus->number, devfn);
> +
> +	writel_relaxed(val, port->base + PCIE_CFGNUM_REG);
> +}
> +
> +static void __iomem *mtk_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
> +				      int where)
> +{
> +	struct mtk_pcie_port *port = bus->sysdata;
> +
> +	return port->base + PCIE_CFG_OFFSET_ADDR + where;
> +}
> +
> +static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
> +				int where, int size, u32 *val)
> +{
> +	mtk_pcie_config_tlp_header(bus, devfn, where, size);
> +
> +	return pci_generic_config_read32(bus, devfn, where, size, val);
> +}
> +
> +static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
> +				 int where, int size, u32 val)
> +{
> +	mtk_pcie_config_tlp_header(bus, devfn, where, size);
> +
> +	if (size <= 2)
> +		val <<= (where & 0x3) * 8;
> +
> +	return pci_generic_config_write32(bus, devfn, where, 4, val);
> +}
> +
> +static struct pci_ops mtk_pcie_ops = {
> +	.map_bus = mtk_pcie_map_bus,
> +	.read  = mtk_pcie_config_read,
> +	.write = mtk_pcie_config_write,
> +};
> +
> +static int mtk_pcie_set_trans_table(struct mtk_pcie_port *port,
> +				    resource_size_t cpu_addr,
> +				    resource_size_t pci_addr,
> +				    resource_size_t size,
> +				    unsigned long type, int num)
> +{
> +	void __iomem *table;
> +	u32 val;
> +
> +	if (num >= PCIE_MAX_TRANS_TABLES) {
> +		dev_err(port->dev, "not enough translate table for addr: %#llx, limited to [%d]\n",
> +			(unsigned long long)cpu_addr, PCIE_MAX_TRANS_TABLES);
> +		return -ENODEV;
> +	}
> +
> +	table = port->base + PCIE_TRANS_TABLE_BASE_REG +
> +		num * PCIE_ATR_TLB_SET_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;
> +	else
> +		val = PCIE_ATR_TYPE_MEM | PCIE_ATR_TLP_TYPE_MEM;
> +
> +	writel_relaxed(val, table + PCIE_ATR_TRSL_PARAM_OFFSET);
> +
> +	return 0;
> +}
> +
> +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> +{
> +	struct resource_entry *entry;
> +	struct pci_host_bridge *host = pci_host_bridge_from_priv(port);
> +	unsigned int table_index = 0;
> +	int err;
> +	u32 val;
> +
> +	/* Set as RC mode */
> +	val = readl_relaxed(port->base + PCIE_SETTING_REG);
> +	val |= PCIE_RC_MODE;
> +	writel_relaxed(val, port->base + PCIE_SETTING_REG);
> +
> +	/* Set class code */
> +	val = readl_relaxed(port->base + PCIE_PCI_IDS_1);
> +	val &= ~GENMASK(31, 8);
> +	val |= PCI_CLASS(PCI_CLASS_BRIDGE_PCI << 8);
> +	writel_relaxed(val, port->base + PCIE_PCI_IDS_1);
> +
> +	/* Assert all reset signals */
> +	val = readl_relaxed(port->base + PCIE_RST_CTRL_REG);
> +	val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
> +	writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
> +
> +	/*
> +	 * Described in PCIe CEM specification setctions 2.2 (PERST# Signal)
> +	 * and 2.2.1 (Initial Power-Up (G3 to S0)).
> +	 * The deassertion of PERST# should be delayed 100ms (TPVPERL)
> +	 * for the power and clock to become stable.
> +	 */
> +	msleep(100);
> +
> +	/* De-assert reset signals */
> +	val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB);
> +	writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
> +
> +	/* Check if the link is up or not */
> +	err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_REG, val,
> +				 !!(val & PCIE_PORT_LINKUP), 20,
> +				 PCI_PM_D3COLD_WAIT * USEC_PER_MSEC);
> +	if (err) {
> +		val = readl_relaxed(port->base + PCIE_LTSSM_STATUS_REG);
> +		dev_err(port->dev, "PCIe link down, ltssm reg val: %#x\n", val);
> +		return err;
> +	}
> +
> +	/* Set PCIe translation windows */
> +	resource_list_for_each_entry(entry, &host->windows) {
> +		struct resource *res = entry->res;
> +		unsigned long type = resource_type(res);
> +		resource_size_t cpu_addr;
> +		resource_size_t pci_addr;
> +		resource_size_t size;
> +		const char *range_type;
> +
> +		if (type == IORESOURCE_IO) {
> +			cpu_addr = pci_pio_to_address(res->start);
> +			range_type = "IO";
> +		} else if (type == IORESOURCE_MEM) {
> +			cpu_addr = res->start;
> +			range_type = "MEM";
> +		} else {
> +			continue;
> +		}
> +
> +		pci_addr = res->start - entry->offset;
> +		size = resource_size(res);
> +		err = mtk_pcie_set_trans_table(port, cpu_addr, pci_addr, size,
> +					       type, table_index);
> +		if (err)
> +			return err;
> +
> +		dev_dbg(port->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;
> +}
> +
> +static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
> +{
> +	struct device *dev = port->dev;
> +	struct platform_device *pdev = to_platform_device(dev);
> +	struct resource *regs;
> +	int ret;
> +
> +	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
> +	port->base = devm_ioremap_resource(dev, regs);
> +	if (IS_ERR(port->base)) {
> +		dev_err(dev, "failed to map register base\n");
> +		return PTR_ERR(port->base);
> +	}
> +
> +	port->reg_base = regs->start;
> +
> +	port->phy_reset = devm_reset_control_get_optional_exclusive(dev, "phy");
> +	if (IS_ERR(port->phy_reset)) {
> +		ret = PTR_ERR(port->phy_reset);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(dev, "failed to get PHY reset\n");
> +
> +		return ret;
> +	}
> +
> +	port->mac_reset = devm_reset_control_get_optional_exclusive(dev, "mac");
> +	if (IS_ERR(port->mac_reset)) {
> +		ret = PTR_ERR(port->mac_reset);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(dev, "failed to get MAC reset\n");
> +
> +		return ret;
> +	}
> +
> +	port->phy = devm_phy_optional_get(dev, "pcie-phy");
> +	if (IS_ERR(port->phy)) {
> +		ret = PTR_ERR(port->phy);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(dev, "failed to get PHY\n");
> +
> +		return ret;
> +	}
> +
> +	port->num_clks = devm_clk_bulk_get_all(dev, &port->clks);
> +	if (port->num_clks < 0) {
> +		dev_err(dev, "failed to get clocks\n");
> +		return port->num_clks;
> +	}
> +
> +	return 0;
> +}
> +
> +static int mtk_pcie_power_up(struct mtk_pcie_port *port)
> +{
> +	struct device *dev = port->dev;
> +	int err;
> +
> +	/* PHY power on and enable pipe clock */
> +	reset_control_deassert(port->phy_reset);
> +
> +	err = phy_init(port->phy);
> +	if (err) {
> +		dev_err(dev, "failed to initialize PHY\n");
> +		goto err_phy_init;
> +	}
> +
> +	err = phy_power_on(port->phy);
> +	if (err) {
> +		dev_err(dev, "failed to power on PHY\n");
> +		goto err_phy_on;
> +	}
> +
> +	/* MAC power on and enable transaction layer clocks */
> +	reset_control_deassert(port->mac_reset);
> +
> +	pm_runtime_enable(dev);
> +	pm_runtime_get_sync(dev);
> +
> +	err = clk_bulk_prepare_enable(port->num_clks, port->clks);
> +	if (err) {
> +		dev_err(dev, "failed to enable clocks\n");
> +		goto err_clk_init;
> +	}
> +
> +	return 0;
> +
> +err_clk_init:
> +	pm_runtime_put_sync(dev);
> +	pm_runtime_disable(dev);
> +	reset_control_assert(port->mac_reset);
> +	phy_power_off(port->phy);
> +err_phy_on:
> +	phy_exit(port->phy);
> +err_phy_init:
> +	reset_control_assert(port->phy_reset);
> +
> +	return err;
> +}
> +
> +static void mtk_pcie_power_down(struct mtk_pcie_port *port)
> +{
> +	clk_bulk_disable_unprepare(port->num_clks, port->clks);
> +
> +	pm_runtime_put_sync(port->dev);
> +	pm_runtime_disable(port->dev);
> +	reset_control_assert(port->mac_reset);
> +
> +	phy_power_off(port->phy);
> +	phy_exit(port->phy);
> +	reset_control_assert(port->phy_reset);
> +}
> +
> +static int mtk_pcie_setup(struct mtk_pcie_port *port)
> +{
> +	int err;
> +
> +	err = mtk_pcie_parse_port(port);
> +	if (err)
> +		return err;
> +
> +	/* Don't touch the hardware registers before power up */
> +	err = mtk_pcie_power_up(port);
> +	if (err)
> +		return err;
> +
> +	/* Try link up */
> +	err = mtk_pcie_startup_port(port);
> +	if (err)
> +		goto err_setup;
> +
> +	return 0;
> +
> +err_setup:
> +	mtk_pcie_power_down(port);
> +
> +	return err;
> +}
> +
> +static int mtk_pcie_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct mtk_pcie_port *port;
> +	struct pci_host_bridge *host;
> +	int err;
> +
> +	host = devm_pci_alloc_host_bridge(dev, sizeof(*port));
> +	if (!host)
> +		return -ENOMEM;
> +
> +	port = pci_host_bridge_priv(host);
> +
> +	port->dev = dev;
> +	platform_set_drvdata(pdev, port);
> +
> +	err = mtk_pcie_setup(port);
> +	if (err)
> +		return err;
> +
> +	host->ops = &mtk_pcie_ops;
> +	host->sysdata = port;
> +
> +	err = pci_host_probe(host);
> +	if (err) {
> +		mtk_pcie_power_down(port);
> +		return err;
> +	}
> +
> +	return 0;
> +}
> +
> +static int mtk_pcie_remove(struct platform_device *pdev)
> +{
> +	struct mtk_pcie_port *port = platform_get_drvdata(pdev);
> +	struct pci_host_bridge *host = pci_host_bridge_from_priv(port);
> +
> +	pci_lock_rescan_remove();
> +	pci_stop_root_bus(host->bus);
> +	pci_remove_root_bus(host->bus);
> +	pci_unlock_rescan_remove();
> +
> +	mtk_pcie_power_down(port);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id mtk_pcie_of_match[] = {
> +	{ .compatible = "mediatek,mt8192-pcie" },
> +	{},
> +};
> +
> +static struct platform_driver mtk_pcie_driver = {
> +	.probe = mtk_pcie_probe,
> +	.remove = mtk_pcie_remove,
> +	.driver = {
> +		.name = "mtk-pcie",
> +		.of_match_table = mtk_pcie_of_match,
> +	},
> +};
> +
> +module_platform_driver(mtk_pcie_driver);
> +MODULE_LICENSE("GPL v2");


From rppt at kernel.org  Thu Apr  8 06:48:09 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 08:48:09 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <064dad68-ca9f-14d3-7859-5321001fbca4@arm.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <064dad68-ca9f-14d3-7859-5321001fbca4@arm.com>
Message-ID: <YG6ZGW1EtOe9pZV7@kernel.org>

On Thu, Apr 08, 2021 at 10:46:18AM +0530, Anshuman Khandual wrote:
> 
> 
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved region just before the memory is freed from memblock to the buddy
> > page allocator.
> > 
> > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > values set by the memory map initialization which makes it necessary to
> > have a special treatment for such pages in pfn_valid() and
> > pfn_valid_within().
> > 
> > Split out initialization of the reserved pages to a function with a
> > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> > reserved regions and mark struct pages for the NOMAP regions as
> > PageReserved.
> 
> This would definitely need updating the comment for MEMBLOCK_NOMAP definition
> in include/linux/memblock.h just to make the semantics is clear,

Sure

> though arm64 is currently the only user for MEMBLOCK_NOMAP.

> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >  mm/memblock.c | 23 +++++++++++++++++++++--
> >  1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..6b7ea9d86310 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
> >  	return end_pfn - start_pfn;
> >  }
> >  
> > +static void __init memmap_init_reserved_pages(void)
> > +{
> > +	struct memblock_region *region;
> > +	phys_addr_t start, end;
> > +	u64 i;
> > +
> > +	/* initialize struct pages for the reserved regions */
> > +	for_each_reserved_mem_range(i, &start, &end)
> > +		reserve_bootmem_region(start, end);
> > +
> > +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> > +	for_each_mem_region(region) {
> > +		if (memblock_is_nomap(region)) {
> > +			start = region->base;
> > +			end = start + region->size;
> > +			reserve_bootmem_region(start, end);
> > +		}
> > +	}
> > +}
> > +
> >  static unsigned long __init free_low_memory_core_early(void)
> >  {
> >  	unsigned long count = 0;
> > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
> >  
> >  	memblock_clear_hotplug(0, -1);
> >  
> > -	for_each_reserved_mem_range(i, &start, &end)
> > -		reserve_bootmem_region(start, end);
> > +	memmap_init_reserved_pages();
> >  
> >  	/*
> >  	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> > 

-- 
Sincerely yours,
Mike.


From nina-cm.wu at mediatek.com  Thu Apr  8 06:57:01 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 8 Apr 2021 13:57:01 +0800
Subject: [PATCH v2 2/6] soc: mediatek: devapc: move 'vio_idx_num' info
 to DT
In-Reply-To: <39794302-7993-4f9c-b28c-577fdb0265a3@gmail.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-2-git-send-email-nina-cm.wu@mediatek.com>
 <39794302-7993-4f9c-b28c-577fdb0265a3@gmail.com>
Message-ID: <1617861421.8874.3.camel@mtksdccf07>

Hi, Matthias


On Tue, 2021-04-06 at 15:41 +0200, Matthias Brugger wrote:
> 
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu at mediatek.com>
> > 
> > For new ICs, there are multiple devapc HWs for different subsys.
> > The number of devices controlled by each devapc (i.e. 'vio_idx_num'
> > in the code) varies.
> > We move this info from compatible data to DT so that we do not need
> > to add n compatible for a certain IC which has n devapc HWs with
> > different 'vio_idx_num', respectively.
> > 
> > Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-devapc.c | 18 +++++++++---------
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index f1cea04..a0f6fbd 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -32,9 +32,6 @@ struct mtk_devapc_vio_dbgs {
> >  };
> >  
> >  struct mtk_devapc_data {
> > -	/* numbers of violation index */
> > -	u32 vio_idx_num;
> > -
> >  	/* reg offset */
> >  	u32 vio_mask_offset;
> >  	u32 vio_sta_offset;
> > @@ -49,6 +46,7 @@ struct mtk_devapc_data {
> >  struct mtk_devapc_context {
> >  	struct device *dev;
> >  	void __iomem *infra_base;
> > +	u32 vio_idx_num;
> 
> We should try to stay backwards compatible (newer kernel with older DTS). I
> think we don't need to move vio_idx_num to mtk_devapc_context. Just don't
> declare it in the per SoC match data. More details see below...
> 
> >  	struct clk *infra_clk;
> >  	const struct mtk_devapc_data *data;
> >  };
> > @@ -60,10 +58,10 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
> >  
> >  	reg = ctx->infra_base + ctx->data->vio_sta_offset;
> >  
> > -	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> > +	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
> >  		writel(GENMASK(31, 0), reg + 4 * i);
> >  
> > -	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
> > +	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1), 0),
> >  	       reg + 4 * i);
> >  }
> >  
> > @@ -80,15 +78,15 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
> >  	else
> >  		val = 0;
> >  
> > -	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
> > +	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
> >  		writel(val, reg + 4 * i);
> >  
> >  	val = readl(reg + 4 * i);
> >  	if (mask)
> > -		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> > +		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
> >  			       0);
> >  	else
> > -		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
> > +		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num - 1),
> >  				0);
> >  
> >  	writel(val, reg + 4 * i);
> > @@ -216,7 +214,6 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
> >  }
> >  
> >  static const struct mtk_devapc_data devapc_mt6779 = {
> > -	.vio_idx_num = 511,
> >  	.vio_mask_offset = 0x0,
> >  	.vio_sta_offset = 0x400,
> >  	.vio_dbg0_offset = 0x900,
> > @@ -256,6 +253,9 @@ static int mtk_devapc_probe(struct platform_device *pdev)
> >  	if (!ctx->infra_base)
> >  		return -EINVAL;
> >  
> > +	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
> > +		return -EINVAL;
> > +
> 
> ...only read the property if  vio_idx_num == 0.
> What do you think?
> 
> Regards,
> Matthias
> 

Good idea. I will fix it in the next version.

Thanks


> >  	devapc_irq = irq_of_parse_and_map(node, 0);
> >  	if (!devapc_irq)
> >  		return -EINVAL;
> > 


From rppt at kernel.org  Thu Apr  8 07:00:52 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 09:00:52 +0300
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
 <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
Message-ID: <YG6cFKKimksg+FX3@kernel.org>

On Thu, Apr 08, 2021 at 10:44:58AM +0530, Anshuman Khandual wrote:
> 
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing else.
> 
> Should there be a comment affirming this semantics interpretation, above the
> generic pfn_valid() in include/linux/mmzone.h ?

Yeah, that would have been helpful :)
 
> > 
> > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > linear map vs those that require ioremap() to access them.
> > 
> > Introduce a dedicated pfn_is_memory() to perform such check and use it
> > where appropriate.
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >  arch/arm64/include/asm/memory.h | 2 +-
> >  arch/arm64/include/asm/page.h   | 1 +
> >  arch/arm64/kvm/mmu.c            | 2 +-
> >  arch/arm64/mm/init.c            | 6 ++++++
> >  arch/arm64/mm/ioremap.c         | 4 ++--
> >  arch/arm64/mm/mmu.c             | 2 +-
> >  6 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 0aabc3be9a75..7e77fdf71b9d 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >  
> >  #define virt_addr_valid(addr)	({					\
> >  	__typeof__(addr) __addr = __tag_reset(addr);			\
> > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
> >  })
> >  
> >  void dump_mem_limit(void);
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 012cffc574e8..32b485bcc6ff 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> >  typedef struct page *pgtable_t;
> >  
> >  extern int pfn_valid(unsigned long);
> > +extern int pfn_is_memory(unsigned long);
> >  
> >  #include <asm/memory.h>
> >  
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 8711894db8c2..ad2ea65a3937 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> >  
> >  static bool kvm_is_device_pfn(unsigned long pfn)
> >  {
> > -	return !pfn_valid(pfn);
> > +	return !pfn_is_memory(pfn);
> >  }
> >  
> >  /*
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 3685e12aba9b..258b1905ed4a 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > +int pfn_is_memory(unsigned long pfn)
> > +{
> > +	return memblock_is_map_memory(PFN_PHYS(pfn));
> > +}
> > +EXPORT_SYMBOL(pfn_is_memory);> +
> 
> Should not this be generic though ? There is nothing platform or arm64
> specific in here.

As NOMAP itself is quite ARM specific, this check is currently only
relevant for arm64 and maybe arm32.
But probably having an EXPORT_SYMBOL wrapper for memblock_is_map_memory(),
say in memblock does make sense for all architectures that have
KEEP_MEMBLOCK.

> Wondering as pfn_is_memory() just indicates that the
> pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
> instead ? Regardless, it's fine either way.

Yeah, I agree that naming could be better here. I think that for a generic name
we'd need pfn_is_directly_mapped() so that it can be used on x86 ;-)
 
> >  static phys_addr_t memory_limit = PHYS_ADDR_MAX;
> >  
> >  /*
> > diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> > index b5e83c46b23e..82a369b22ef5 100644
> > --- a/arch/arm64/mm/ioremap.c
> > +++ b/arch/arm64/mm/ioremap.c
> > @@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
> >  	/*
> >  	 * Don't allow RAM to be mapped.
> >  	 */
> > -	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> > +	if (WARN_ON(pfn_is_memory(__phys_to_pfn(phys_addr))))
> >  		return NULL;
> >  
> >  	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> > @@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
> >  void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
> >  {
> >  	/* For normal memory we already have a cacheable mapping. */
> > -	if (pfn_valid(__phys_to_pfn(phys_addr)))
> > +	if (pfn_is_memory(__phys_to_pfn(phys_addr)))
> >  		return (void __iomem *)__phys_to_virt(phys_addr);
> >  
> >  	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 5d9550fdb9cf..038d20fe163f 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
> >  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> >  			      unsigned long size, pgprot_t vma_prot)
> >  {
> > -	if (!pfn_valid(pfn))
> > +	if (!pfn_is_memory(pfn))
> >  		return pgprot_noncached(vma_prot);
> >  	else if (file->f_flags & O_SYNC)
> >  		return pgprot_writecombine(vma_prot);
> > 

-- 
Sincerely yours,
Mike.


From nina-cm.wu at mediatek.com  Thu Apr  8 06:58:21 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 8 Apr 2021 13:58:21 +0800
Subject: [PATCH v2 4/6] soc: mediatek: devapc: rename variable for new
 IC support
In-Reply-To: <a76686d1-3544-fcb9-4c3e-1498ec29ff47@gmail.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-4-git-send-email-nina-cm.wu@mediatek.com>
 <a76686d1-3544-fcb9-4c3e-1498ec29ff47@gmail.com>
Message-ID: <1617861501.8874.4.camel@mtksdccf07>

Hi, Matthias

On Tue, 2021-04-06 at 15:43 +0200, Matthias Brugger wrote:
> Regarding the commit subject:
> "soc: mediatek: devapc: rename variable for new IC support"
> maybe something like:
> "soc: mediatek: devapc: rename register variable infra_base"
> 
> Other then that looks good to me.
> 

OK. I will fix it in the next version.

Thanks

> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu at mediatek.com>
> > 
> > For new ICs, there are multiple devapc HWs for different subsys.
> > For example, there is devapc respectively for infra, peri, peri2, etc.
> > So we rename the variable 'infra_base' to 'base' for code readability.
> > 
> > Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-devapc.c | 24 ++++++++++++------------
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index 68c3e35..bcf6e3c 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -45,7 +45,7 @@ struct mtk_devapc_data {
> >  
> >  struct mtk_devapc_context {
> >  	struct device *dev;
> > -	void __iomem *infra_base;
> > +	void __iomem *base;
> >  	u32 vio_idx_num;
> >  	struct clk *infra_clk;
> >  	const struct mtk_devapc_data *data;
> > @@ -56,7 +56,7 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
> >  	void __iomem *reg;
> >  	int i;
> >  
> > -	reg = ctx->infra_base + ctx->data->vio_sta_offset;
> > +	reg = ctx->base + ctx->data->vio_sta_offset;
> >  
> >  	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num - 1); i++)
> >  		writel(GENMASK(31, 0), reg + 4 * i);
> > @@ -71,7 +71,7 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
> >  	u32 val;
> >  	int i;
> >  
> > -	reg = ctx->infra_base + ctx->data->vio_mask_offset;
> > +	reg = ctx->base + ctx->data->vio_mask_offset;
> >  
> >  	if (mask)
> >  		val = GENMASK(31, 0);
> > @@ -113,11 +113,11 @@ static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
> >  	int ret;
> >  	u32 val;
> >  
> > -	pd_vio_shift_sta_reg = ctx->infra_base +
> > +	pd_vio_shift_sta_reg = ctx->base +
> >  			       ctx->data->vio_shift_sta_offset;
> > -	pd_vio_shift_sel_reg = ctx->infra_base +
> > +	pd_vio_shift_sel_reg = ctx->base +
> >  			       ctx->data->vio_shift_sel_offset;
> > -	pd_vio_shift_con_reg = ctx->infra_base +
> > +	pd_vio_shift_con_reg = ctx->base +
> >  			       ctx->data->vio_shift_con_offset;
> >  
> >  	/* Find the minimum shift group which has violation */
> > @@ -159,8 +159,8 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> >  	void __iomem *vio_dbg0_reg;
> >  	void __iomem *vio_dbg1_reg;
> >  
> > -	vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset;
> > -	vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset;
> > +	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> > +	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> >  
> >  	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
> >  	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> > @@ -198,7 +198,7 @@ static irqreturn_t devapc_violation_irq(int irq_number, void *data)
> >   */
> >  static void start_devapc(struct mtk_devapc_context *ctx)
> >  {
> > -	writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset);
> > +	writel(BIT(31), ctx->base + ctx->data->apc_con_offset);
> >  
> >  	mask_module_irq(ctx, false);
> >  }
> > @@ -210,7 +210,7 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
> >  {
> >  	mask_module_irq(ctx, true);
> >  
> > -	writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset);
> > +	writel(BIT(2), ctx->base + ctx->data->apc_con_offset);
> >  }
> >  
> >  static const struct mtk_devapc_data devapc_mt6779 = {
> > @@ -249,8 +249,8 @@ static int mtk_devapc_probe(struct platform_device *pdev)
> >  	ctx->data = of_device_get_match_data(&pdev->dev);
> >  	ctx->dev = &pdev->dev;
> >  
> > -	ctx->infra_base = of_iomap(node, 0);
> > -	if (!ctx->infra_base)
> > +	ctx->base = of_iomap(node, 0);
> > +	if (!ctx->base)
> >  		return -EINVAL;
> >  
> >  	if (of_property_read_u32(node, "vio_idx_num", &ctx->vio_idx_num))
> > 


From michal.simek at xilinx.com  Thu Apr  8 07:08:10 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 8 Apr 2021 08:08:10 +0200
Subject: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
In-Reply-To: <20210407214811.GA260719@roeck-us.net>
References: <1615963949-75320-1-git-send-email-manish.narani@xilinx.com>
 <1615963949-75320-3-git-send-email-manish.narani@xilinx.com>
 <20210407214811.GA260719@roeck-us.net>
Message-ID: <ee280235-736d-1689-d324-b090c21106c9@xilinx.com>

Hi Guenter,

On 4/7/21 11:48 PM, Guenter Roeck wrote:
> On Wed, Mar 17, 2021 at 12:22:29PM +0530, Manish Narani wrote:
>> Add a new driver for supporting Xilinx platforms. This driver is used
>> for some sequence of operations required for Xilinx USB controllers.
>> This driver is also used to choose between PIPE clock coming from SerDes
>> and the Suspend Clock. Before the controller is out of reset, the clock
>> selection should be changed to PIPE clock in order to make the USB
>> controller work. There is a register added in Xilinx USB controller
>> register space for the same.
>>
>> Signed-off-by: Manish Narani <manish.narani at xilinx.com>
> 
> Trying this driver with qemu (v6.0.0-rc2) results in:
> 
> [   15.184242] dwc3-xilinx ff9d0000.usb: error -ENODEV: failed to assert Reset
> [   15.185754] Unable to handle kernel paging request at virtual address 006b6b6b6b6b6b9b
> [   15.185994] Mem abort info:
> [   15.186065]   ESR = 0x96000004
> [   15.186317]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   15.186414]   SET = 0, FnV = 0
> [   15.186498]   EA = 0, S1PTW = 0
> [   15.186579] Data abort info:
> [   15.186666]   ISV = 0, ISS = 0x00000004
> [   15.186756]   CM = 0, WnR = 0
> [   15.186887] [006b6b6b6b6b6b9b] address between user and kernel address ranges
> [   15.187436] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> [   15.187777] Modules linked in:
> [   15.188060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc6-next-20210406-00006-g05407f068fc9-dirty #1
> [   15.188265] Hardware name: Xilinx Versal Virtual development board (DT)
> [   15.188495] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
> [   15.188614] pc : __clk_put+0x24/0x138
> [   15.188716] lr : __clk_put+0x24/0x138
> [   15.188791] sp : ffff80001326bac0
> [   15.188853] x29: ffff80001326bac0 x28: ffff00000644ed00
> [   15.188982] x27: ffff00000421ecd0 x26: ffff00000421e810
> [   15.189076] x25: ffff00000644f100 x24: 0000000000000000
> [   15.189170] x23: ffff8000126a2570 x22: 0000000000000005
> [   15.189271] x21: ffff00000644ed00 x20: ffff000006449970
> [   15.189367] x19: 6b6b6b6b6b6b6b6b x18: 0000000000000010
> [   15.189456] x17: 0000000000000001 x16: 0000000000000000
> [   15.189546] x15: ffff000003af0490 x14: 00000000000001b7
> [   15.189642] x13: ffff000003af0490 x12: 00000000ffffffea
> [   15.189729] x11: ffff8000123b6460 x10: 0000000000000080
> [   15.189815] x9 : 00000000676993c6 x8 : 00000000676993c6
> [   15.189941] x7 : 000000007d152ab3 x6 : ffff800012768480
> [   15.190047] x5 : 0000000000000000 x4 : 000000007f97631e
> [   15.190139] x3 : 00000000d5bdf2c2 x2 : 000000000000000b
> [   15.190233] x1 : ffff000003af0040 x0 : 0000000000000001
> [   15.190432] Call trace:
> [   15.190506]  __clk_put+0x24/0x138
> [   15.190588]  clk_put+0x10/0x20
> [   15.190653]  clk_bulk_put+0x3c/0x60
> [   15.190724]  devm_clk_bulk_release+0x1c/0x28
> [   15.190806]  release_nodes+0x1c0/0x2b0
> [   15.190887]  devres_release_all+0x38/0x60
> [   15.190963]  really_probe+0x1e4/0x3a8
> [   15.191042]  driver_probe_device+0x64/0xc8
> ...
> 
> because of ...
> 
>> +
>> +	ret = devm_clk_bulk_get_all(priv_data->dev, &priv_data->clks);
>> +	if (ret < 0)
>> +		return ret;
>> +
> ...
>> +
>> +err_clk_put:
>> +	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
>> +	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
> 
> clk_bulk_put_all() is not necessary because of devm_clk_bulk_get_all(),
> and results in a double free.
> 
>> +static int dwc3_xlnx_remove(struct platform_device *pdev)
>> +{
>> +	struct dwc3_xlnx	*priv_data = platform_get_drvdata(pdev);
>> +	struct device		*dev = &pdev->dev;
>> +
>> +	of_platform_depopulate(dev);
>> +
>> +	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
>> +	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
> 
> Same here. This will likely crash the driver on unload.
It looks like that you directly created the patch. Isn't it better to
send it yourself? Or do you want Manish to create it based on guidance
above?

Manish: Can you please take a look at this?

Thanks,
Michal


From nina-cm.wu at mediatek.com  Thu Apr  8 07:09:28 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 8 Apr 2021 14:09:28 +0800
Subject: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for
 new IC support
In-Reply-To: <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-5-git-send-email-nina-cm.wu@mediatek.com>
 <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>
Message-ID: <1617862168.8874.13.camel@mtksdccf07>

Hi, Matthias

On Tue, 2021-04-06 at 15:53 +0200, Matthias Brugger wrote:
> 
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu at mediatek.com>
> > 
> > There are 3 debug info registers in new ICs while in legacy ones,
> > we have only 2. When dumping the debug info, we need to check first
> > if the 3rd debug register exists and then we can konw how to decipher
> > the debug info.
> > 
> > Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> > ---
> >  drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index bcf6e3c..af55c01 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
> >  			u32 addr_h:4;
> >  			u32 resv:4;
> >  		} dbg0_bits;
> > +
> > +		/* Not used, reference only */
> > +		struct {
> > +			u32 dmnid:6;
> > +			u32 vio_w:1;
> > +			u32 vio_r:1;
> > +			u32 addr_h:4;
> > +			u32 resv:20;
> > +		} dbg0_bits_ver2;
> >  	};
> >  
> >  	u32 vio_dbg1;
> > +	u32 vio_dbg2;
> >  };
> >  
> >  struct mtk_devapc_data {
> > @@ -37,6 +47,7 @@ struct mtk_devapc_data {
> >  	u32 vio_sta_offset;
> >  	u32 vio_dbg0_offset;
> >  	u32 vio_dbg1_offset;
> > +	u32 vio_dbg2_offset;
> >  	u32 apc_con_offset;
> >  	u32 vio_shift_sta_offset;
> >  	u32 vio_shift_sel_offset;
> > @@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> >  	struct mtk_devapc_vio_dbgs vio_dbgs;
> >  	void __iomem *vio_dbg0_reg;
> >  	void __iomem *vio_dbg1_reg;
> > +	void __iomem *vio_dbg2_reg;
> > +	u32 vio_addr, bus_id;
> >  
> >  	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> >  	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> > +	vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
> 
> We should read this only if we have version2 of the devapc.
> 

You're right.
It is not good to read vio_dbg2_reg in version one. Even though we will
only get the value from offset 0 (which is not expected) instead of
doing any real harm. (like causing bus hang)


> >  
> >  	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
> >  	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> > +	vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
> > +
> > +	if (!ctx->data->vio_dbg2_offset) {
> 
> I think we should add a version field to mtk_devapc_data to distinguish the two
> of them.

OK.
I will try to add this field in the next version

> 
> > +		/* arch version 1 */
> > +		bus_id = vio_dbgs.dbg0_bits.mstid;
> > +		vio_addr = vio_dbgs.vio_dbg1;
> > +	} else {
> > +		/* arch version 2 */
> > +		bus_id = vio_dbgs.vio_dbg1;
> > +		vio_addr = vio_dbgs.vio_dbg2;
> > +
> > +		/* To align with the bit definition of arch_ver 1 */
> > +		vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);
> 
> That's magic, better add another variable domain_id and do here:
> domain_id = vio_dgbs.dbg0_bits_ver2.dmnid;
> 

OK.
I will fix it up in the next version.

Thanks

> > +	}
> >  
> >  	/* Print violation information */
> >  	if (vio_dbgs.dbg0_bits.vio_w)
> > @@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> >  		dev_info(ctx->dev, "Read Violation\n");
> >  
> >  	dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
> > -		 vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
> > -		 vio_dbgs.vio_dbg1);
> > +		 bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
> >  }
> >  
> >  /*
> > 


From rppt at kernel.org  Thu Apr  8 07:17:58 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 09:17:58 +0300
Subject: [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <7bc09505-72f1-e297-40a9-639b3e9b1c61@arm.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-4-rppt@kernel.org>
 <7bc09505-72f1-e297-40a9-639b3e9b1c61@arm.com>
Message-ID: <YG6gFi5/3O2OsYYH@kernel.org>

On Thu, Apr 08, 2021 at 10:42:43AM +0530, Anshuman Khandual wrote:
> 
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> > 
> > * Parts of the memory map are freed during boot. This makes it necessary to
> >   verify that there is actual physical memory that corresponds to a pfn
> >   which is done by querying memblock.
> > 
> > * There are NOMAP memory regions. These regions are not mapped in the
> >   linear map and until the previous commit the struct pages representing
> >   these areas had default values.
> > 
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> > 
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> But what about the memory map that are freed during boot (mentioned above).
> Would not they still cause CONFIG_HOLES_IN_ZONE to be applicable and hence
> pfn_valid_within() ?

The CONFIG_HOLES_IN_ZONE name is misleading as actually pfn_valid_within()
is only required for holes within a MAX_ORDER_NR_PAGES blocks (see comment
near pfn_valid_within() definition in mmzone.h). The freeing of the memory
map during boot avoids breaking MAX_ORDER blocks and the holes for which
memory map is freed are always aligned at MAX_ORDER.

AFAIU, the only case when there could be a hole in a MAX_ORDER block is
when EFI/ACPI reserves memory for its use and this memory becomes NOMAP in
the kernel. We still create struct pages for this memory, but they never
get values other than defaults, so core mm has no idea that this memory
should be touched, hence the need for pfn_valid_within() aliased to
pfn_valid() on arm64.
 
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> 
> Just to understand this better, pfn_valid() will now return true for all
> MEMBLOCK_NOMAP based memory but that is okay as core MM would still ignore
> them as unusable memory for being PageReserved().

Right, pfn_valid() will return true for all memory, including
MEMBLOCK_NOMAP. Since core mm deals with PageResrved() for memory used by
the firmware, e.g. on x86, I don't see why it won't work on arm64.
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >  arch/arm64/Kconfig   | 3 ---
> >  arch/arm64/mm/init.c | 4 ++--
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> >  	def_bool y
> >  	depends on NUMA
> >  
> > -config HOLES_IN_ZONE
> > -	def_bool y
> > -
> >  source "kernel/Kconfig.hz"
> >  
> >  config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 258b1905ed4a..bb6dd406b1f0 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >  
> >  	/*
> >  	 * ZONE_DEVICE memory does not have the memblock entries.
> > -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> > +	 * memblock_is_memory() check for ZONE_DEVICE based
> >  	 * addresses will always fail. Even the normal hotplugged
> >  	 * memory will never have MEMBLOCK_NOMAP flag set in their
> >  	 * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> >  		return pfn_section_valid(ms, pfn);
> >  }
> >  #endif
> > -	return memblock_is_map_memory(addr);
> > +	return memblock_is_memory(addr);
> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > 

-- 
Sincerely yours,
Mike.


From nina-cm.wu at mediatek.com  Thu Apr  8 07:14:09 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Thu, 8 Apr 2021 14:14:09 +0800
Subject: [PATCH v2 6/6] soc: mediatek: devapc: support mt8192
In-Reply-To: <f52189e3-26b2-fd44-7059-f3bf0f79fbae@gmail.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <1617259087-5502-6-git-send-email-nina-cm.wu@mediatek.com>
 <f52189e3-26b2-fd44-7059-f3bf0f79fbae@gmail.com>
Message-ID: <1617862449.8874.16.camel@mtksdccf07>

Hi, Matthias

On Tue, 2021-04-06 at 15:55 +0200, Matthias Brugger wrote:
> 
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu at mediatek.com>
> > 
> > Add compatible to support mt8192.
> > 
> > Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> > ---
> 
> 
> Looks good, I'd like to see DTS for this as well, although I understand it
> depends on the clock patch series. Please note so in either below the '---' or
> in a cover letter.
> 
> Regards,
> Matthias
> 

I will add devapc nodes in DTS in the next version.

Thanks

> 
> >  drivers/soc/mediatek/mtk-devapc.c | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index af55c01..a5c15b5 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -251,11 +251,26 @@ static const struct mtk_devapc_data devapc_mt6779 = {
> >  	.vio_shift_con_offset = 0xF20,
> >  };
> >  
> > +static const struct mtk_devapc_data devapc_mt8192 = {
> > +	.vio_mask_offset = 0x0,
> > +	.vio_sta_offset = 0x400,
> > +	.vio_dbg0_offset = 0x900,
> > +	.vio_dbg1_offset = 0x904,
> > +	.vio_dbg2_offset = 0x908,
> > +	.apc_con_offset = 0xF00,
> > +	.vio_shift_sta_offset = 0xF20,
> > +	.vio_shift_sel_offset = 0xF30,
> > +	.vio_shift_con_offset = 0xF10,
> > +};
> > +
> >  static const struct of_device_id mtk_devapc_dt_match[] = {
> >  	{
> >  		.compatible = "mediatek,mt6779-devapc",
> >  		.data = &devapc_mt6779,
> >  	}, {
> > +		.compatible = "mediatek,mt8192-devapc",
> > +		.data = &devapc_mt8192,
> > +	}, {
> >  	},
> >  };
> >  
> > 


From rppt at kernel.org  Thu Apr  8 07:27:53 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 09:27:53 +0300
Subject: [RFC/RFT PATCH 0/3] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <2f68ea11-7c56-1c55-f0be-3aad7188c00a@arm.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <2f68ea11-7c56-1c55-f0be-3aad7188c00a@arm.com>
Message-ID: <YG6iaZJI/RiUwXzv@kernel.org>

On Thu, Apr 08, 2021 at 10:49:02AM +0530, Anshuman Khandual wrote:
> Adding James here.
> 
> + James Morse <james.morse at arm.com>
> 
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > Hi,
> > 
> > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> > pfn_valid_within() to 1. 
> 
> That would be really great for arm64 platform as it will save CPU cycles on
> many generic MM paths, given that our pfn_valid() has been expensive.
> 
> > 
> > The idea is to mark NOMAP pages as reserved in the memory map and restore
> 
> Though I am not really sure, would that possibly be problematic for UEFI/EFI
> use cases as it might have just treated them as normal struct pages till now.

I don't think there should be a problem because now the struct pages for
UEFI/ACPI never got to be used by the core mm. They were (rightfully)
skipped by memblock_free_all() from one side and pfn_valid() and
pfn_valid_within() return false for them in various pfn walkers from the
other side.
 
> > the intended semantics of pfn_valid() to designate availability of struct
> > page for a pfn.
> 
> Right, that would be better as the current semantics is not ideal.
> 
> > 
> > With this the core mm will be able to cope with the fact that it cannot use
> > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> > will be treated correctly even without the need for pfn_valid_within.
> > 
> > The patches are only boot tested on qemu-system-aarch64 so I'd really
> > appreciate memory stress tests on real hardware.
> 
> Did some preliminary memory stress tests on a guest with portions of memory
> marked as MEMBLOCK_NOMAP and did not find any obvious problem. But this might
> require some testing on real UEFI environment with firmware using MEMBLOCK_NOMAP
> memory to make sure that changing these struct pages to PageReserved() is safe.

I surely have no access for such machines :)
 
> > If this actually works we'll be one step closer to drop custom pfn_valid()
> > on arm64 altogether.
> 
> Right, planning to rework and respin the RFC originally sent last month.
> 
> https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/

-- 
Sincerely yours,
Mike.


From gregkh at linuxfoundation.org  Thu Apr  8 07:37:12 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 8 Apr 2021 08:37:12 +0200
Subject: [PATCH v4 1/4] dt-bindings: serial: 8250: deprecate
 aspeed,sirq-polarity-sense
In-Reply-To: <YG3yEeIRKgTjnDxz@hatter.bewilderbeest.net>
References: <20210402182724.20848-1-zev@bewilderbeest.net>
 <20210402182724.20848-2-zev@bewilderbeest.net>
 <YG3NR4bGRjIGZhgx@kroah.com>
 <YG3kJC+6gLC6RzzQ@hatter.bewilderbeest.net>
 <YG3q9brKTC4pkQbs@kroah.com>
 <YG3yEeIRKgTjnDxz@hatter.bewilderbeest.net>
Message-ID: <YG6kmNBhGhe0JGwA@kroah.com>

On Wed, Apr 07, 2021 at 12:55:29PM -0500, Zev Weiss wrote:
> On Wed, Apr 07, 2021 at 12:25:09PM CDT, Greg Kroah-Hartman wrote:
> > On Wed, Apr 07, 2021 at 11:56:04AM -0500, Zev Weiss wrote:
> > > On Wed, Apr 07, 2021 at 10:18:31AM CDT, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 02, 2021 at 01:27:21PM -0500, Zev Weiss wrote:
> > > > > This property ties SIRQ polarity to SCU register bits that don't
> > > > > necessarily have any direct relationship to it; the only use of it
> > > > > was removed in commit c82bf6e133d30e0f9172a20807814fa28aef0f67.
> > > >
> > > > Please write that as:
> > > > 	c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq polarity")
> > > >
> > > 
> > > Ack, will do.
> > > 
> > > > > Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> > > > > Reviewed-by: Joel Stanley <joel at jms.id.au>
> > > > > ---
> > > > >  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > >
> > > > What changed from previous versions?  That always goes below the ---
> > > > line.
> > > >
> > > 
> > > I included an overview of that in the cover letter (https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/);
> > > is it desirable to also have that duplicated in the individual patches in
> > > the series?
> > 
> > Any reason why you didn't include all of the relevant people and mailing
> > lists in that cover letter?  I've never seen it before :)
> > 
> 
> Ah -- is there a good rule of thumb (or git send-email trick) for that?
> Set-union of get_maintainer.pl over all the patches in the series?

There might be a git send-email trick, but I don't know it :(


From nobuhiro1.iwamatsu at toshiba.co.jp  Thu Apr  8 07:37:19 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Thu, 8 Apr 2021 15:37:19 +0900
Subject: [PATCH 1/3] dt-bindings: pci: Add DT binding for Toshiba
 Visconti PCIe controller
In-Reply-To: <CAL_JsqJew19jBJ-WpGNCK2AD+nUQsQBjJ7-ye9Cgort8AuG8mQ@mail.gmail.com>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210407031839.386088-2-nobuhiro1.iwamatsu@toshiba.co.jp>
 <CAL_JsqJew19jBJ-WpGNCK2AD+nUQsQBjJ7-ye9Cgort8AuG8mQ@mail.gmail.com>
Message-ID: <20210408063719.jxh27ez375ezx3dc@toshiba.co.jp>

Hi,

Thanks for your review.

On Wed, Apr 07, 2021 at 08:18:58AM -0500, Rob Herring wrote:
> On Tue, Apr 6, 2021 at 10:19 PM Nobuhiro Iwamatsu
> <nobuhiro1.iwamatsu at toshiba.co.jp> wrote:
> >
> > This commit adds the Device Tree binding documentation that allows
> > to describe the PCIe controller found in Toshiba Visconti SoCs.
> >
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > ---
> >  .../bindings/pci/toshiba,visconti-pcie.yaml   | 121 ++++++++++++++++++
> >  1 file changed, 121 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
> > new file mode 100644
> > index 000000000000..8ab60c235007
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
> > @@ -0,0 +1,121 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings
> > +
> > +maintainers:
> > +  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > +
> > +description: |+
> > +  Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP.
> > +
> > +allOf:
> > +  - $ref: /schemas/pci/pci-bus.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    const: toshiba,visconti-pcie
> > +
> > +  reg:
> > +    items:
> > +      - description: Data Bus Interface (DBI) registers.
> > +      - description: PCIe configuration space region.
> > +      - description: Visconti specific additional registers.
> > +      - description: Visconti specific SMU registers
> > +      - description: Visconti specific memory protection unit registers (MPU)
> > +
> > +  reg-names:
> > +    items:
> > +      - const: dbi
> > +      - const: config
> > +      - const: ulreg
> > +      - const: smu
> > +      - const: mpu
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +
> > +  clocks:
> > +    items:
> > +      - description: PCIe reference clock
> > +      - description: PCIe system clock
> > +      - description: Auxiliary clock
> > +
> > +  clock-names:
> > +    items:
> > +      - const: pcie_refclk
> > +      - const: sysclk
> > +      - const: auxclk
> > +
> > +  num-lanes:
> > +    const: 2
> > +
> > +  num-viewport:
> > +    const: 8
> 
> Drop this, we detect this now.
> 

OK, I will drop this.

> > +
> > +required:
> 
> Drop everything that pci-bus.yaml already requires.

OK, I will check pci-bus.yaml, and update this.

> 
> > +  - reg
> > +  - reg-names
> > +  - interrupts
> > +  - "#address-cells"
> > +  - "#size-cells"
> > +  - "#interrupt-cells"
> > +  - interrupt-map
> > +  - interrupt-map-mask
> > +  - ranges
> > +  - bus-range
> 
> If you support 0-0xff, there's no need for this to be required.
> 

OK, this device supports 0x0 -0xff, I will drop.

> > +  - device_type
> > +  - num-lanes
> > +  - num-viewport
> > +  - clocks
> > +  - clock-names
> > +  - max-link-speed
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +    soc {
> > +        #address-cells = <2>;
> > +        #size-cells = <2>;
> > +
> > +        pcie: pcie at 28400000 {
> > +            compatible = "toshiba,visconti-pcie";
> > +            reg = <0x0 0x28400000 0x0 0x00400000>,
> > +                  <0x0 0x70000000 0x0 0x10000000>,
> > +                  <0x0 0x28050000 0x0 0x00010000>,
> > +                  <0x0 0x24200000 0x0 0x00002000>,
> > +                  <0x0 0x24162000 0x0 0x00001000>;
> > +            reg-names  = "dbi", "config", "ulreg", "smu", "mpu";
> > +            device_type = "pci";
> > +            bus-range = <0x00 0xff>;
> > +            num-lanes = <2>;
> > +            num-viewport = <8>;
> > +
> > +            #address-cells = <3>;
> > +            #size-cells = <2>;
> > +            #interrupt-cells = <1>;
> > +            ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>,
> > +                     <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>;
> > +            interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
> > +            interrupt-names = "intr";
> > +            interrupt-map-mask = <0 0 0 7>;
> > +            interrupt-map =
> > +                <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> > +                 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> > +                 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
> > +                 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
> > +            clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>;
> > +            clock-names = "pcie_refclk", "sysclk", "auxclk";
> > +            max-link-speed = <2>;
> > +
> > +            status = "disabled";
> 
> Don't show status in examples.

OK, I will drop.

> 
> > +        };
> > +    };
> > +...
> > --
> > 2.30.0.rc2
> >
> 

Best regards,
  Nobuhiro



From lee.jones at linaro.org  Thu Apr  8 08:06:05 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 8 Apr 2021 08:06:05 +0100
Subject: [RESEND 00/25] Rid W=1 warnings from HID
In-Reply-To: <CAO-hwJ+5Vd6jC2+0pfHLOw3opdXzKoc9pUWzxmBVhSvQvNWMsQ@mail.gmail.com>
References: <20210326143458.508959-1-lee.jones@linaro.org>
 <20210406085605.GS2916463@dell>
 <CAO-hwJ+5Vd6jC2+0pfHLOw3opdXzKoc9pUWzxmBVhSvQvNWMsQ@mail.gmail.com>
Message-ID: <20210408070605.GC2961413@dell>

On Wed, 07 Apr 2021, Benjamin Tissoires wrote:

> On Tue, Apr 6, 2021 at 10:56 AM Lee Jones <lee.jones at linaro.org> wrote:
> >
> > On Fri, 26 Mar 2021, Lee Jones wrote:
> >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > > niggly little warnings.
> > >
> > > Lee Jones (25):
> > >   HID: intel-ish-hid: Remove unused variable 'err'
> > >   HID: ishtp-hid-client: Move variable to where it's actually used
> > >   HID: intel-ish-hid: pci-ish: Remove unused variable 'ret'
> > >   HID: intel-ish: Supply some missing param descriptions
> > >   HID: intel-ish: Fix a naming disparity and a formatting error
> > >   HID: usbhid: Repair a formatting issue in a struct description
> > >   HID: intel-ish-hid: Fix a little doc-rot
> > >   HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses
> > >   HID: hid-alps: Correct struct misnaming
> > >   HID: intel-ish-hid: Fix potential copy/paste error
> > >   HID: hid-core: Fix incorrect function name in header
> > >   HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in
> > >     header
> > >   HID: ishtp-hid-client: Fix incorrect function name report_bad_packet()
> > >   HID: hid-kye: Fix incorrect function name for kye_tablet_enable()
> > >   HID: hid-picolcd_core: Remove unused variable 'ret'
> > >   HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote
> > >     abuses
> > >   HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs
> > >   HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses
> > >   HID: hid-uclogic-params: Ensure function names are present and correct
> > >     in kernel-doc headers
> > >   HID: hid-sensor-custom: Remove unused variable 'ret'
> > >   HID: wacom_sys: Demote kernel-doc abuse
> > >   HID: hid-sensor-hub: Remove unused struct member 'quirks'
> > >   HID: hid-sensor-hub: Move 'hsdev' description to correct struct
> > >     definition
> > >   HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues
> > >   HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning
> >
> > These have been on the list for a couple of weeks now.
> >
> > Is there anything I can do to help expedite their merge?
> >
> > I'm concerned since -rc6 has just been released.
> 
> Sorry for the delay.
> 
> I am currently queuing them locally and running a few tests on them. I
> don't expect anything to happen, but better be safe than anything.
> 
> FWIW, I am splitting the series in 3:
> - 11 patches for intel ish are going to be queued in for-5.13/intel-ish
> - the thrustmaster one in for-5.13/thrustmaster
> - the rest (13 patches) will be sent in for-5.13/warnings.

Sounds good to me.  Thanks Benjamin.

-- 
Lee Jones [???]
Senior Technical Lead - Developer Services
Linaro.org ? Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


From liushixin2 at huawei.com  Thu Apr  8 08:18:31 2021
From: liushixin2 at huawei.com (Shixin Liu)
Date: Thu, 8 Apr 2021 15:18:31 +0800
Subject: [PATCH -next 1/7] crypto: sun4i-ss - Fix PM reference leak when
 pm_runtime_get_sync() fails
Message-ID: <20210408071831.836638-1-liushixin2@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
---
 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 2 +-
 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c   | 2 +-
 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c   | 2 +-
 drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c
index c2e6f5ed1d79..dec79fa3ebaf 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c
@@ -561,7 +561,7 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
 				    sizeof(struct sun4i_cipher_req_ctx) +
 				    crypto_skcipher_reqsize(op->fallback_tfm));
 
-	err = pm_runtime_get_sync(op->ss->dev);
+	err = pm_runtime_resume_and_get(op->ss->dev);
 	if (err < 0)
 		goto error_pm;
 
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
index ef224d5e4903..44b8fc4b786d 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c
@@ -454,7 +454,7 @@ static int sun4i_ss_probe(struct platform_device *pdev)
 	 * this info could be useful
 	 */
 
-	err = pm_runtime_get_sync(ss->dev);
+	err = pm_runtime_resume_and_get(ss->dev);
 	if (err < 0)
 		goto error_pm;
 
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
index c1b4585e9bbc..d28292762b32 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c
@@ -27,7 +27,7 @@ int sun4i_hash_crainit(struct crypto_tfm *tfm)
 	algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
 	op->ss = algt->ss;
 
-	err = pm_runtime_get_sync(op->ss->dev);
+	err = pm_runtime_resume_and_get(op->ss->dev);
 	if (err < 0)
 		return err;
 
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
index 443160a114bb..491fcb7b81b4 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
@@ -29,7 +29,7 @@ int sun4i_ss_prng_generate(struct crypto_rng *tfm, const u8 *src,
 	algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng);
 	ss = algt->ss;
 
-	err = pm_runtime_get_sync(ss->dev);
+	err = pm_runtime_resume_and_get(ss->dev);
 	if (err < 0)
 		return err;
 
-- 
2.25.1



From liushixin2 at huawei.com  Thu Apr  8 08:18:32 2021
From: liushixin2 at huawei.com (Shixin Liu)
Date: Thu, 8 Apr 2021 15:18:32 +0800
Subject: [PATCH -next 2/7] crypto: sun8i-ss - Fix PM reference leak when
 pm_runtime_get_sync() fails
Message-ID: <20210408071832.836691-1-liushixin2@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
---
 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +-
 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index f945750b65d9..9ef1c85c4aaa 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -354,7 +354,7 @@ int sun8i_ss_cipher_init(struct crypto_tfm *tfm)
 	op->enginectx.op.prepare_request = NULL;
 	op->enginectx.op.unprepare_request = NULL;
 
-	err = pm_runtime_get_sync(op->ss->dev);
+	err = pm_runtime_resume_and_get(op->ss->dev);
 	if (err < 0) {
 		dev_err(op->ss->dev, "pm error %d\n", err);
 		goto error_pm;
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index e0ddc684798d..80e89066dbd1 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -753,7 +753,7 @@ static int sun8i_ss_probe(struct platform_device *pdev)
 	if (err)
 		goto error_alg;
 
-	err = pm_runtime_get_sync(ss->dev);
+	err = pm_runtime_resume_and_get(ss->dev);
 	if (err < 0)
 		goto error_alg;
 
-- 
2.25.1



From liushixin2 at huawei.com  Thu Apr  8 08:18:33 2021
From: liushixin2 at huawei.com (Shixin Liu)
Date: Thu, 8 Apr 2021 15:18:33 +0800
Subject: [PATCH -next 3/7] crypto: sun8i-ce - Fix PM reference leak in
 sun8i_ce_probe()
Message-ID: <20210408071833.836741-1-liushixin2@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
---
 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 158422ff5695..00194d1d9ae6 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -932,7 +932,7 @@ static int sun8i_ce_probe(struct platform_device *pdev)
 	if (err)
 		goto error_alg;
 
-	err = pm_runtime_get_sync(ce->dev);
+	err = pm_runtime_resume_and_get(ce->dev);
 	if (err < 0)
 		goto error_alg;
 
-- 
2.25.1



From liushixin2 at huawei.com  Thu Apr  8 08:18:36 2021
From: liushixin2 at huawei.com (Shixin Liu)
Date: Thu, 8 Apr 2021 15:18:36 +0800
Subject: [PATCH -next 5/7] crypto: stm32/cryp - Fix PM reference leak on
 stm32-cryp.c
Message-ID: <20210408071836.836842-1-liushixin2@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
---
 drivers/crypto/stm32/stm32-cryp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
index 2a4793176c71..7389a0536ff0 100644
--- a/drivers/crypto/stm32/stm32-cryp.c
+++ b/drivers/crypto/stm32/stm32-cryp.c
@@ -542,7 +542,7 @@ static int stm32_cryp_hw_init(struct stm32_cryp *cryp)
 	int ret;
 	u32 cfg, hw_mode;
 
-	pm_runtime_get_sync(cryp->dev);
+	pm_runtime_resume_and_get(cryp->dev);
 
 	/* Disable interrupt */
 	stm32_cryp_write(cryp, CRYP_IMSCR, 0);
@@ -2043,7 +2043,7 @@ static int stm32_cryp_remove(struct platform_device *pdev)
 	if (!cryp)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(cryp->dev);
+	ret = pm_runtime_resume_and_get(cryp->dev);
 	if (ret < 0)
 		return ret;
 
-- 
2.25.1



From liushixin2 at huawei.com  Thu Apr  8 08:18:35 2021
From: liushixin2 at huawei.com (Shixin Liu)
Date: Thu, 8 Apr 2021 15:18:35 +0800
Subject: [PATCH -next 4/7] crypto: stm32/hash - Fix PM reference leak on
 stm32-hash.c
Message-ID: <20210408071835.836791-1-liushixin2@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
---
 drivers/crypto/stm32/stm32-hash.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/stm32/stm32-hash.c b/drivers/crypto/stm32/stm32-hash.c
index 7ac0573ef663..389de9e3302d 100644
--- a/drivers/crypto/stm32/stm32-hash.c
+++ b/drivers/crypto/stm32/stm32-hash.c
@@ -813,7 +813,7 @@ static void stm32_hash_finish_req(struct ahash_request *req, int err)
 static int stm32_hash_hw_init(struct stm32_hash_dev *hdev,
 			      struct stm32_hash_request_ctx *rctx)
 {
-	pm_runtime_get_sync(hdev->dev);
+	pm_runtime_resume_and_get(hdev->dev);
 
 	if (!(HASH_FLAGS_INIT & hdev->flags)) {
 		stm32_hash_write(hdev, HASH_CR, HASH_CR_INIT);
@@ -962,7 +962,7 @@ static int stm32_hash_export(struct ahash_request *req, void *out)
 	u32 *preg;
 	unsigned int i;
 
-	pm_runtime_get_sync(hdev->dev);
+	pm_runtime_resume_and_get(hdev->dev);
 
 	while ((stm32_hash_read(hdev, HASH_SR) & HASH_SR_BUSY))
 		cpu_relax();
@@ -1000,7 +1000,7 @@ static int stm32_hash_import(struct ahash_request *req, const void *in)
 
 	preg = rctx->hw_context;
 
-	pm_runtime_get_sync(hdev->dev);
+	pm_runtime_resume_and_get(hdev->dev);
 
 	stm32_hash_write(hdev, HASH_IMR, *preg++);
 	stm32_hash_write(hdev, HASH_STR, *preg++);
@@ -1566,7 +1566,7 @@ static int stm32_hash_remove(struct platform_device *pdev)
 	if (!hdev)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(hdev->dev);
+	ret = pm_runtime_resume_and_get(hdev->dev);
 	if (ret < 0)
 		return ret;
 
-- 
2.25.1



From jean-philippe at linaro.org  Thu Apr  8 08:25:14 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Thu, 8 Apr 2021 09:25:14 +0200
Subject: Question: multiple SMMUv3 devices probe
In-Reply-To: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
References: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
Message-ID: <YG6v2m1P8cbhRnJU@myrica>

Hi,

On Wed, Apr 07, 2021 at 05:37:52PM +0800, richard clark wrote:
> Hi guys,
> There're 3 SMMUv3 devices in my arm64 box. I am confused by the below
> probe process:
> 
> arm_smmu_device_probe(...) --> arm_smmu_set_bus_ops(&arm_smmu_ops):
> if (platform_bus_type.iommu_ops != ops) {
>         err = bus_set_iommu(&platform_bus_type, ops);
>         if (err)
> }
> 
> so for the 1st smmu device on the platform_bus, the
> arm_smmu_device_probe(...) will set the platform_bus_type.iommu_bus =
> arm_smmu_ops, so for the arm_smmu_device_probe(...) when probing the
> 2nd smmu device, the bus_set_iommu() will have no chance be called
> since the platform_bus_type.iommu_bus == arm_smmu_ops is true, my
> question is how the followed bus_set_iommu(...) being called?

arm_smmu_ops is the same for all SMMU devices, so bus_set_iommu() only
needs to be called once.

Thanks,
Jean


From arnd at arndb.de  Thu Apr  8 08:26:30 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 09:26:30 +0200
Subject: [GIT PULL] arm64: dts: mediatek: changes for v5.13 (second round)
In-Reply-To: <CAOwMV_yQLWwMEQ_f_wHOAipgD1qZgNz2SA2RJDZpNozCKv4vWQ@mail.gmail.com>
References: <22814673-e9fe-f65b-cc0f-b02be4f90d1a@gmail.com>
 <CAK8P3a0bp3CUzOQHSX5KYt44j-Njk_u2P=0q-ZQ0HcTBiVVVSA@mail.gmail.com>
 <01c82108-64a8-33ee-3984-5bd7056a0002@gmail.com>
 <CAK8P3a37BUdHneO+9+t0Pan3UWZHub-ishcKLNxCbqO0kk0CNw@mail.gmail.com>
 <CAOwMV_yQLWwMEQ_f_wHOAipgD1qZgNz2SA2RJDZpNozCKv4vWQ@mail.gmail.com>
Message-ID: <CAK8P3a2Qg-uz0kMXFMrvRjUv3NRvZXjTwS1P5MDvFk3feYaBzg@mail.gmail.com>

On Thu, Apr 8, 2021 at 12:14 AM Fabien Parent <fparent at baylibre.com> wrote:
> On Wed, Apr 7, 2021 at 7:55 PM Arnd Bergmann <arnd at arndb.de> wrote:
> > On Wed, Apr 7, 2021 at 6:34 PM Matthias Brugger <matthias.bgg at gmail.com> wrote:
> > > On 07/04/2021 18:06, Arnd Bergmann wrote:
> >
> > So five of the strings are documented, the others are missing. I did not check
> > the other patches in your branch.
>
> The binding documentation for these drivers are here [0]. The display
> bindings are documented as:
> - compatible: "mediatek,<chip>-disp-<function>", one of
>
> The <chip> placeholder is never expanded for all the supported chips.
> The 5 existings matches from your grep command comes from the example.
> I guess these will be fixed whenever someone converts [0] to yaml.

Ok. I suppose the wildcards just didn't get caught in the initial review of the
binding. The way the binding is defined is not all that helpful since the entire
point of having chip specific strings is to allow having different bindings for
future chips that have different requirements.

There is still an open question on what to do to replace the aliases. At least
since they are not part of the documented binding, it is fairly easy to argue
that the drivers should not rely on them, and we can still change them.
I also see that as late as last november, there were still incompatible
code changes to the ad-hoc binding in
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c, so I'm not too worried
about breaking existing dts files that relied on it.

I don't claim to understand how the various blocks all fit together here,
but I would expect that this can all be replaced with just having
references to phandles for the other nodes in one place.

Are the aliases in this case actually board specific, or do they just
document how the SoC is wired up?

       Arnd


From zhukeqian1 at huawei.com  Thu Apr  8 08:28:18 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 8 Apr 2021 15:28:18 +0800
Subject: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <878s5up71v.wl-maz@kernel.org>
References: <20210316134338.18052-1-zhukeqian1@huawei.com>
 <20210316134338.18052-3-zhukeqian1@huawei.com> <878s5up71v.wl-maz@kernel.org>
Message-ID: <9f74392b-1086-a85e-72d8-f7bd99d65ea7@huawei.com>

Hi Marc,

On 2021/4/7 21:18, Marc Zyngier wrote:
> On Tue, 16 Mar 2021 13:43:38 +0000,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> The MMIO region of a device maybe huge (GB level), try to use
>> block mapping in stage2 to speedup both map and unmap.
>>
>> Compared to normal memory mapping, we should consider two more
>> points when try block mapping for MMIO region:
>>
>> 1. For normal memory mapping, the PA(host physical address) and
>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>> the HVA to request hugepage, so we don't need to consider PA
>> alignment when verifing block mapping. But for device memory
>> mapping, the PA and HVA may have different alignment.
>>
>> 2. For normal memory mapping, we are sure hugepage size properly
>> fit into vma, so we don't check whether the mapping size exceeds
>> the boundary of vma. But for device memory mapping, we should pay
>> attention to this.
>>
>> This adds device_rough_page_shift() to check these two points when
>> selecting block mapping size.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> ---
>>
>> Mainly for RFC, not fully tested. I will fully test it when the
>> code logic is well accepted.
>>
>> ---
>>  arch/arm64/kvm/mmu.c | 42 ++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 38 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index c59af5ca01b0..224aa15eb4d9 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -624,6 +624,36 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>>  }
>>  
>> +/*
>> + * Find a mapping size that properly insides the intersection of vma and
>> + * memslot. And hva and pa have the same alignment to this mapping size.
>> + * It's rough because there are still other restrictions, which will be
>> + * checked by the following fault_supports_stage2_huge_mapping().
> 
> I don't think these restrictions make complete sense to me. If this is
> a PFNMAP VMA, we should use the biggest mapping size that covers the
> VMA, and not more than the VMA.
But as described by kvm_arch_prepare_memory_region(), the memslot may not fully
cover the VMA. If that's true and we just consider the boundary of the VMA, our
block mapping may beyond the boundary of memslot. Is this a problem?

> 
>> + */
>> +static short device_rough_page_shift(struct kvm_memory_slot *memslot,
>> +				     struct vm_area_struct *vma,
>> +				     unsigned long hva)
>> +{
>> +	size_t size = memslot->npages * PAGE_SIZE;
>> +	hva_t sec_start = max(memslot->userspace_addr, vma->vm_start);
>> +	hva_t sec_end = min(memslot->userspace_addr + size, vma->vm_end);
>> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>> +
>> +#ifndef __PAGETABLE_PMD_FOLDED
>> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PUD_SIZE) >= sec_start &&
>> +	    ALIGN(hva, PUD_SIZE) <= sec_end)
>> +		return PUD_SHIFT;
>> +#endif
>> +
>> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PMD_SIZE) >= sec_start &&
>> +	    ALIGN(hva, PMD_SIZE) <= sec_end)
>> +		return PMD_SHIFT;
>> +
>> +	return PAGE_SHIFT;
>> +}
>> +
>>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>>  					       unsigned long hva,
>>  					       unsigned long map_size)
>> @@ -769,7 +799,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  		return -EFAULT;
>>  	}
>>  
>> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
>> +	/*
>> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
>> +	 * get block mapping for device MMIO region.
>> +	 */
>>  	mmap_read_lock(current->mm);
>>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>>  	if (unlikely(!vma)) {
>> @@ -780,11 +813,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (is_vm_hugetlb_page(vma))
>>  		vma_shift = huge_page_shift(hstate_vma(vma));
>> +	else if (vma->vm_flags & VM_PFNMAP)
>> +		vma_shift = device_rough_page_shift(memslot, vma, hva);
>>  	else
>>  		vma_shift = PAGE_SHIFT;
>>  
>> -	if (logging_active ||
>> -	    (vma->vm_flags & VM_PFNMAP)) {
>> +	if (logging_active) {
>>  		force_pte = true;
>>  		vma_shift = PAGE_SHIFT;
> 
> But why should we downgrade to page-size mappings if logging? This is
> a device, and you aren't moving the device around, are you? Or is your
> device actually memory with a device mapping that you are trying to
> migrate?
Thanks for the point. We should not move the device around, so we do not
need to consider logging when we build mapping for device.

I found that logging_active is per memslot and we're sure it's always false
for memslot with PFNMAP VMA, because the kvm_arch_prepare_memory_region()
forbids that. Then I think we're OK here.

Thanks,
Keqian

> 
>>  	}
>> @@ -855,7 +889,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (kvm_is_device_pfn(pfn)) {
>>  		device = true;
>> -		force_pte = true;
>> +		force_pte = (vma_pagesize == PAGE_SIZE);
>>  	} else if (logging_active && !write_fault) {
>>  		/*
>>  		 * Only actually map the page as writable if this was a write
>> -- 
>> 2.19.1
>>
>>
> 
> Thanks,
> 
> 	M.
> 


From linus.walleij at linaro.org  Thu Apr  8 08:29:10 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 8 Apr 2021 09:29:10 +0200
Subject: [PATCH] pinctrl: stm32: Print invalid AF warning inside
 stm32_pctrl_is_function_valid()
In-Reply-To: <20210406180035.279249-1-marex@denx.de>
References: <20210406180035.279249-1-marex@denx.de>
Message-ID: <CACRpkdaZmwoFwqinoX63cZaoauL7jGpK6kMW6pULkBn8aP=D3A@mail.gmail.com>

On Tue, Apr 6, 2021 at 8:00 PM Marek Vasut <marex at denx.de> wrote:

> The "invalid function %d on pin %d .\n" message is triplicated in the
> driver in different variants, just pull it into the function and have
> it once in the driver. The bonus is that all variants of the message
> now print the pin number and AF consistently, so it is easier to debug
> such pinmux problems.
>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabien Dessenne <fabien.dessenne at st.com>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org

Patch applied.

Yours,
Linus Walleij


From sboyd at kernel.org  Thu Apr  8 08:41:18 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Thu, 08 Apr 2021 00:41:18 -0700
Subject: [PATCH]  clk: imx: reference preceded by free
In-Reply-To: <20210408095312.00004267@163.com>
References: <1616469034-9691-1-git-send-email-dj0227@163.com>
 <161715700800.2260335.7834636340431628632@swboyd.mtv.corp.google.com>
 <20210408095312.00004267@163.com>
Message-ID: <161786767850.3790633.2996848068001353291@swboyd.mtv.corp.google.com>

Quoting Jian Dong (2021-04-07 18:53:12)
> On Tue, 30 Mar 2021 19:16:48 -0700
> Stephen Boyd <sboyd at kernel.org> wrote:
> 
> > Quoting Jian Dong (2021-03-22 20:10:34)
> > > From: Jian Dong <dongjian at yulong.com>
> > > 
> > >  when register failed, clk will be freed, it will generate dangling
> > > pointer problem in later reference. it should return directly.
> > > 
> > > Signed-off-by: Jian Dong <dongjian at yulong.com>
> > > ---  
> > 
> > Any Fixes tag?
> 
> Sorry for late, I'm unfamiliar with tag rule.
> 
> For this patch include two files commit 2f77296d3 and fe37b482
> maybe likes:
> 
> Fixes: 2f77296d3        (clk: imx: add lpcg clock support)
> Fixes: fe37b482         (clk: imx: add scu clock common part)
> 
> and I noticed this patch has been merged, do I need RESEND again with
> tags like above?
> 

Looks like Abel already picked it up so no need to resend.


From linus.walleij at linaro.org  Thu Apr  8 08:50:45 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  8 Apr 2021 09:50:45 +0200
Subject: [PATCH] ARM/spi: spear: Drop PL022 num_chipselect
Message-ID: <20210408075045.3435046-1-linus.walleij@linaro.org>

A previous refactoring moved the chip select number handling
to the SPI core and we missed a leftover platform data user
in the ST spear platform. The spear is not using this
chipselect or PL022 for anything and should be using device
tree like the rest of the platform so just delete the
offending platform data.

Cc: Viresh Kumar <vireshk at kernel.org>
Cc: Shiraz Hashim <shiraz.linux.kernel at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
Mark: please apply this as a fix to the SPI tree unless there
are protests.
---
 arch/arm/mach-spear/spear320.c |  2 --
 arch/arm/mach-spear/spear3xx.c | 10 ----------
 2 files changed, 12 deletions(-)

diff --git a/arch/arm/mach-spear/spear320.c b/arch/arm/mach-spear/spear320.c
index 0958f68a21e2..926d5a243238 100644
--- a/arch/arm/mach-spear/spear320.c
+++ b/arch/arm/mach-spear/spear320.c
@@ -195,14 +195,12 @@ static struct pl022_ssp_controller spear320_ssp_data[] = {
 		.dma_filter = pl08x_filter_id,
 		.dma_tx_param = "ssp1_tx",
 		.dma_rx_param = "ssp1_rx",
-		.num_chipselect = 2,
 	}, {
 		.bus_id = 2,
 		.enable_dma = 1,
 		.dma_filter = pl08x_filter_id,
 		.dma_tx_param = "ssp2_tx",
 		.dma_rx_param = "ssp2_rx",
-		.num_chipselect = 2,
 	}
 };
 
diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
index 8537fcffe5a8..f83321d5e353 100644
--- a/arch/arm/mach-spear/spear3xx.c
+++ b/arch/arm/mach-spear/spear3xx.c
@@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
 	.dma_filter = pl08x_filter_id,
 	.dma_tx_param = "ssp0_tx",
 	.dma_rx_param = "ssp0_rx",
-	/*
-	 * This is number of spi devices that can be connected to spi. There are
-	 * two type of chipselects on which slave devices can work. One is chip
-	 * select provided by spi masters other is controlled through external
-	 * gpio's. We can't use chipselect provided from spi master (because as
-	 * soon as FIFO becomes empty, CS is disabled and transfer ends). So
-	 * this number now depends on number of gpios available for spi. each
-	 * slave on each master requires a separate gpio pin.
-	 */
-	.num_chipselect = 2,
 };
 
 /* dmac device registration */
-- 
2.29.2



From viresh.kumar at linaro.org  Thu Apr  8 08:56:26 2021
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 8 Apr 2021 13:26:26 +0530
Subject: [PATCH] ARM/spi: spear: Drop PL022 num_chipselect
In-Reply-To: <20210408075045.3435046-1-linus.walleij@linaro.org>
References: <20210408075045.3435046-1-linus.walleij@linaro.org>
Message-ID: <20210408075626.gkbbs3wd3bme3vgd@vireshk-i7>

On 08-04-21, 09:50, Linus Walleij wrote:
> A previous refactoring moved the chip select number handling
> to the SPI core and we missed a leftover platform data user
> in the ST spear platform. The spear is not using this
> chipselect or PL022 for anything and should be using device
> tree like the rest of the platform so just delete the
> offending platform data.
> 
> Cc: Viresh Kumar <vireshk at kernel.org>
> Cc: Shiraz Hashim <shiraz.linux.kernel at gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> Mark: please apply this as a fix to the SPI tree unless there
> are protests.

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From lkp at intel.com  Thu Apr  8 08:55:35 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 08 Apr 2021 15:55:35 +0800
Subject: [soc:at91/dt] BUILD SUCCESS 4d930c421e3b4f5bb3a9dd6b2eba2b15d458fcb5
Message-ID: <606eb6f7.Uqe5xJ/+atHlh++8%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git at91/dt
branch HEAD: 4d930c421e3b4f5bb3a9dd6b2eba2b15d458fcb5  ARM: dts: at91: sama5d2: add ETB and ETM unit name

elapsed time: 1154m

configs tested: 231
configs skipped: 102

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
nds32                            alldefconfig
powerpc                   motionpro_defconfig
powerpc                 linkstation_defconfig
mips                       capcella_defconfig
arm                          pxa168_defconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                             allyesconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_itx_defconfig
mips                  maltasmvp_eva_defconfig
arm                       netwinder_defconfig
arm                     am200epdkit_defconfig
mips                          rb532_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
mips                         tb0287_defconfig
arm                         lpc18xx_defconfig
powerpc                      ep88xc_defconfig
arm                     eseries_pxa_defconfig
sparc                            alldefconfig
sparc                       sparc32_defconfig
arm                        oxnas_v6_defconfig
powerpc                      ppc44x_defconfig
arm                  colibri_pxa300_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
arm                         bcm2835_defconfig
m68k                         apollo_defconfig
arm                            hisi_defconfig
arm                         assabet_defconfig
mips                            e55_defconfig
powerpc64                           defconfig
powerpc                    mvme5100_defconfig
m68k                          sun3x_defconfig
arm                         mv78xx0_defconfig
m68k                         amcore_defconfig
alpha                            allyesconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
s390                       zfcpdump_defconfig
nios2                         3c120_defconfig
m68k                        m5407c3_defconfig
powerpc                    klondike_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
sh                   sh7770_generic_defconfig
arm                          collie_defconfig
nds32                               defconfig
m68k                       m5208evb_defconfig
mips                          malta_defconfig
m68k                        stmark2_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
sh                          sdk7780_defconfig
powerpc                      arches_defconfig
csky                             alldefconfig
powerpc                           allnoconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
csky                                defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
powerpc                     pq2fads_defconfig
m68k                        mvme16x_defconfig
mips                           rs90_defconfig
sh                             shx3_defconfig
sh                           sh2007_defconfig
arm                        spear3xx_defconfig
arm                         axm55xx_defconfig
arm                      footbridge_defconfig
arm                            zeus_defconfig
openrisc                  or1klitex_defconfig
sh                   rts7751r2dplus_defconfig
sh                          kfr2r09_defconfig
arm                          iop32x_defconfig
powerpc                 mpc832x_rdb_defconfig
powerpc                      ppc64e_defconfig
sh                           se7343_defconfig
sh                        sh7785lcr_defconfig
sh                          rsk7201_defconfig
powerpc                      chrp32_defconfig
mips                      fuloong2e_defconfig
arm                            pleb_defconfig
sh                        sh7757lcr_defconfig
powerpc                       maple_defconfig
arm                        shmobile_defconfig
mips                        maltaup_defconfig
riscv             nommu_k210_sdcard_defconfig
arc                                 defconfig
xtensa                generic_kc705_defconfig
powerpc                    adder875_defconfig
mips                        jmr3927_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
powerpc                     sbc8548_defconfig
powerpc                        warp_defconfig
sh                          lboxre2_defconfig
arm                             rpc_defconfig
arm                        vexpress_defconfig
powerpc                          allmodconfig
powerpc                 mpc834x_mds_defconfig
sh                           se7721_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
alpha                            alldefconfig
m68k                        m5307c3_defconfig
arm                      tct_hammer_defconfig
powerpc                   lite5200b_defconfig
ia64                          tiger_defconfig
mips                            gpr_defconfig
mips                           gcw0_defconfig
m68k                       m5249evb_defconfig
sh                        sh7763rdp_defconfig
h8300                               defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
arm                     davinci_all_defconfig
sh                      rts7751r2d1_defconfig
powerpc                      mgcoge_defconfig
powerpc                         wii_defconfig
powerpc                     stx_gp3_defconfig
sh                          rsk7203_defconfig
powerpc                      pcm030_defconfig
arm                       multi_v4t_defconfig
arm                       spear13xx_defconfig
powerpc                      ppc40x_defconfig
sh                         ap325rxa_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nios2                            allyesconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210407
x86_64               randconfig-a003-20210407
x86_64               randconfig-a005-20210407
x86_64               randconfig-a001-20210407
x86_64               randconfig-a002-20210407
x86_64               randconfig-a006-20210407
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From u.kleine-koenig at pengutronix.de  Thu Apr  8 08:59:20 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 8 Apr 2021 09:59:20 +0200
Subject: [PATCH v2 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210407231548.4paov2fb33cpxxui@toshiba.co.jp>
References: <20210212131910.557581-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212131910.557581-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212164144.wcvy7jkxmrysqxux@pengutronix.de>
 <20210407231548.4paov2fb33cpxxui@toshiba.co.jp>
Message-ID: <20210408075920.rfrcqxec2yvepj3y@pengutronix.de>

Hello Nobuhiro,

On Thu, Apr 08, 2021 at 08:15:48AM +0900, Nobuhiro Iwamatsu wrote:
> > > +	/*
> > > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > > +	 * way the hardware switches atomically from the old setting to the new.
> > > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > > +	 * at low level at all times.
> > 
> > Did you just copy my optimal description or is your hardware really that
> > nice?
> 
> Yes, this hardware works as you wrote.
> And I added about the state if the sinnal when this hardware disabled.
> 
> > 
> > Do you know scripts/checkpatch.pl? I bet it will tell you to limit your
> > lines to approx. 80 chars where sensible.
> 
> Yes, I know. I ran scripts/checkpatch.pl before send patch.
> I understand that the number of characters per line has been changed to
> 100 characters. Does the pwm driver recommend 80 characters?

For free-text comments I'd still recommend 80, yes. For code lines I'd
be indeed more lax, as a line break in function calls reduces readability.

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/20210408/1cfa0274/attachment.sig>

From maz at kernel.org  Thu Apr  8 09:00:30 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  8 Apr 2021 09:00:30 +0100
Subject: [PATCH] irqchip/wpcm450: Drop COMPILE_TEST
Message-ID: <20210408080030.2277572-1-maz@kernel.org>

This driver is (for now) ARM specific, and currently doesn't
build with a variety of architectures (ia64, RISC-V, x86_64
at the very least).

Drop COMPILE_TEST from Kconfig until it gets sorted out.

Cc: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
Reported-by: Stephen Rothwell <sfr at canb.auug.org.au>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/irqchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 38ad9dcf42c3..715eb4366e35 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -579,7 +579,7 @@ config MST_IRQ
 
 config WPCM450_AIC
 	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
-	depends on ARCH_WPCM450 || COMPILE_TEST
+	depends on ARCH_WPCM450
 	help
 	  Support for the interrupt controller in the Nuvoton WPCM450 BMC SoC.
 
-- 
2.30.2



From patrice.chotard at foss.st.com  Thu Apr  8 09:04:05 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Thu, 8 Apr 2021 10:04:05 +0200
Subject: [PATCH] rtc: st-lpc: move to use request_irq by IRQF_NO_AUTOEN
 flag
In-Reply-To: <1617761937-58318-1-git-send-email-tiantao6@hisilicon.com>
References: <1617761937-58318-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <1df61277-23b0-0351-7373-2e1e5c9f6651@foss.st.com>

Hi Tian

On 4/7/21 4:18 AM, Tian Tao wrote:
> disable_irq() after request_irq() still has a time gap in which
> interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
> disable IRQ auto-enable because of requesting.
> 
> this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
> is being merged: https://lore.kernel.org/patchwork/patch/1388765/
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> ---
>  drivers/rtc/rtc-st-lpc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-st-lpc.c b/drivers/rtc/rtc-st-lpc.c
> index bdb20f6..2df2179 100644
> --- a/drivers/rtc/rtc-st-lpc.c
> +++ b/drivers/rtc/rtc-st-lpc.c
> @@ -218,15 +218,14 @@ static int st_rtc_probe(struct platform_device *pdev)
>  		return -EINVAL;
>  	}
>  
> -	ret = devm_request_irq(&pdev->dev, rtc->irq, st_rtc_handler, 0,
> -			       pdev->name, rtc);
> +	ret = devm_request_irq(&pdev->dev, rtc->irq, st_rtc_handler,
> +			       IRQF_NO_AUTOEN, pdev->name, rtc);
>  	if (ret) {
>  		dev_err(&pdev->dev, "Failed to request irq %i\n", rtc->irq);
>  		return ret;
>  	}
>  
>  	enable_irq_wake(rtc->irq);
> -	disable_irq(rtc->irq);
>  
>  	rtc->clk = clk_get(&pdev->dev, NULL);
>  	if (IS_ERR(rtc->clk)) {
> 

Reviewed-by: Patrice Chotard <patrice.chotard at foss.st.com>

Thanks
Patrice


From j.neuschaefer at gmx.net  Thu Apr  8 09:45:52 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Thu, 8 Apr 2021 10:45:52 +0200
Subject: [PATCH] irqchip/wpcm450: Drop COMPILE_TEST
In-Reply-To: <20210408080030.2277572-1-maz@kernel.org>
References: <20210408080030.2277572-1-maz@kernel.org>
Message-ID: <YG7CwB0lMWJGylt7@latitude>

On Thu, Apr 08, 2021 at 09:00:30AM +0100, Marc Zyngier wrote:
> This driver is (for now) ARM specific, and currently doesn't
> build with a variety of architectures (ia64, RISC-V, x86_64
> at the very least).
> 
> Drop COMPILE_TEST from Kconfig until it gets sorted out.
> 
> Cc: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
> Reported-by: Stephen Rothwell <sfr at canb.auug.org.au>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---

Reviewed-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>

>  drivers/irqchip/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 38ad9dcf42c3..715eb4366e35 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -579,7 +579,7 @@ config MST_IRQ
>  
>  config WPCM450_AIC
>  	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
> -	depends on ARCH_WPCM450 || COMPILE_TEST
> +	depends on ARCH_WPCM450

I guess I could use (COMPILE_TEST && ARM) or something?


Thanks,
Jonathan
-------------- 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/20210408/0316ee91/attachment.sig>

From Jonathan.Cameron at Huawei.com  Thu Apr  8 10:01:57 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Thu, 8 Apr 2021 10:01:57 +0100
Subject: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <20210407204004.GB16011@willie-the-truck>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
 <1617788943-52722-2-git-send-email-liuqi115@huawei.com>
 <20210407204004.GB16011@willie-the-truck>
Message-ID: <20210408100157.000062f0@Huawei.com>

On Wed, 7 Apr 2021 21:40:05 +0100
Will Deacon <will at kernel.org> wrote:

> On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> > PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> > to sample bandwidth, latency, buffer occupation etc.
> > 
> > Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
> > registered as a pmu in /sys/bus/event_source/devices, so users can
> > select target PMU, and use filter to do further sets.
> > 
> > Filtering options contains:
> > event        - select the event.
> > subevent     - select the subevent.
> > port         - select target root ports. Information of root ports
> >                are shown under sysfs.
> > bdf           - select requester_id of target EP device.
> > trig_len     - set trigger condition for starting event statistics.
> > trigger_mode - set trigger mode. 0 means starting to statistic when
> >                bigger than trigger condition, and 1 means smaller.
> > thr_len      - set threshold for statistics.
> > thr_mode     - set threshold mode. 0 means count when bigger than
> >                threshold, and 1 means smaller.
> > 
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>  
> 
> Do you have a link to this review, please?

Internal review, so drop the tag.

Jonathan

> 
> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



From dinghao.liu at zju.edu.cn  Thu Apr  8 10:08:27 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Thu,  8 Apr 2021 17:08:27 +0800
Subject: [PATCH] media: imx: imx7-mipi-csis: Fix runtime PM imbalance in
 mipi_csis_s_stream
Message-ID: <20210408090827.32612-1-dinghao.liu@zju.edu.cn>

When v4l2_subdev_call() fails, a pairing PM usage counter
decrement is needed to keep the counter balanced. It's the
same for the following error paths in case 'enable' is on.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index a01a7364b4b9..2a3fff231a40 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -627,21 +627,26 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 			return ret;
 		}
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
-		if (ret < 0)
+		if (ret < 0) {
+			pm_runtime_put_noidle(&state->pdev->dev);
 			return ret;
+		}
 	}
 
 	mutex_lock(&state->lock);
 	if (enable) {
 		if (state->flags & ST_SUSPENDED) {
 			ret = -EBUSY;
+			pm_runtime_put_noidle(&state->pdev->dev);
 			goto unlock;
 		}
 
 		mipi_csis_start_stream(state);
 		ret = v4l2_subdev_call(state->src_sd, video, s_stream, 1);
-		if (ret < 0)
+		if (ret < 0) {
+			pm_runtime_put_noidle(&state->pdev->dev);
 			goto unlock;
+		}
 
 		mipi_csis_log_counters(state, true);
 
-- 
2.17.1



From david at redhat.com  Thu Apr  8 10:20:09 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 11:20:09 +0200
Subject: [PATCH v1 0/2] drivers: don't select DMA_CMA or CMA
Message-ID: <20210408092011.52763-1-david@redhat.com>

Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
three drivers that select these options. Random drivers should not
override user settings of such core knobs. Let's use "imply DMA_CMA"
instead, such that user configuration and dependencies are respected.

Cc: Joel Stanley <joel at jms.id.au>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Andrew Jeffery <andrew at aj.id.au>
Cc: Lucas Stach <l.stach at pengutronix.de>
Cc: Russell King <linux+etnaviv at armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: Masahiro Yamada <masahiroy at kernel.org>
Cc: Randy Dunlap <rdunlap at infradead.org>
Cc: Peter Collingbourne <pcc at google.com>
Cc: linux-aspeed at lists.ozlabs.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: etnaviv at lists.freedesktop.org
Cc: linux-fbdev at vger.kernel.org

David Hildenbrand (2):
  drivers/video/fbdev: don't select DMA_CMA
  drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv

 drivers/gpu/drm/aspeed/Kconfig  | 3 +--
 drivers/gpu/drm/etnaviv/Kconfig | 3 +--
 drivers/video/fbdev/Kconfig     | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

-- 
2.30.2



From david at redhat.com  Thu Apr  8 10:20:11 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 11:20:11 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <20210408092011.52763-1-david@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
Message-ID: <20210408092011.52763-3-david@redhat.com>

Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.

"This is similar to "select" as it enforces a lower limit on another
 symbol except that the "implied" symbol's value may still be set to n
 from a direct dependency or with a visible prompt."

Implying DRM_CMA should be sufficient, as that depends on CMA.

Note: If this is a real dependency, we should use "depends on DMA_CMA"
instead -  but I assume the driver can work without CMA just fine --
esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.

Signed-off-by: David Hildenbrand <david at redhat.com>
---
 drivers/gpu/drm/aspeed/Kconfig  | 3 +--
 drivers/gpu/drm/etnaviv/Kconfig | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
index 5e95bcea43e9..a055f763d230 100644
--- a/drivers/gpu/drm/aspeed/Kconfig
+++ b/drivers/gpu/drm/aspeed/Kconfig
@@ -6,9 +6,8 @@ config DRM_ASPEED_GFX
 	depends on MMU
 	select DRM_KMS_HELPER
 	select DRM_KMS_CMA_HELPER
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
-	select CMA if HAVE_DMA_CONTIGUOUS
 	select MFD_SYSCON
+	imply DRM_CMA
 	help
 	  Chose this option if you have an ASPEED AST2500 SOC Display
 	  Controller (aka GFX).
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index faa7fc68b009..5f5576b7221a 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -9,9 +9,8 @@ config DRM_ETNAVIV
 	select THERMAL if DRM_ETNAVIV_THERMAL
 	select TMPFS
 	select WANT_DEV_COREDUMP
-	select CMA if HAVE_DMA_CONTIGUOUS
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
 	select DRM_SCHED
+	imply DMA_CMA
 	help
 	  DRM driver for Vivante GPUs.
 
-- 
2.30.2



From david at redhat.com  Thu Apr  8 10:20:10 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 11:20:10 +0200
Subject: [PATCH v1 1/2] drivers/video/fbdev: don't select DMA_CMA
In-Reply-To: <20210408092011.52763-1-david@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
Message-ID: <20210408092011.52763-2-david@redhat.com>

Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.

"This is similar to "select" as it enforces a lower limit on another
 symbol except that the "implied" symbol's value may still be set to n
 from a direct dependency or with a visible prompt."

Implying DRM_CMA should be sufficient, as that depends on CMA.

Note: If this is a real dependency, we should use "depends on DMA_CMA"
instead -  but I assume the driver can work without CMA just fine --
esp. when we wouldn't have HAVE_DMA_CONTIGUOUS or CMA right now.

Signed-off-by: David Hildenbrand <david at redhat.com>
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4f02db65dede..d37cd5341e1b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2186,7 +2186,7 @@ config FB_HYPERV
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_DEFERRED_IO
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
+	imply DMA_CMA
 	help
 	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
 
-- 
2.30.2



From pbrobinson at gmail.com  Thu Apr  8 10:21:21 2021
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 8 Apr 2021 10:21:21 +0100
Subject: [RFC PATCH] drivers: Raspbery Pi Sense Hat
In-Reply-To: <20210408000353.3571132-1-jsavitz@redhat.com>
References: <20210408000353.3571132-1-jsavitz@redhat.com>
Message-ID: <CALeDE9OP0vCiL7dtVzN9r0tkkBT6zXabZT6guFCYx0yWZ3AWsw@mail.gmail.com>

 " Hi Joel,

> This is a forward port of the Rapsberry Pi Sense Hat driver from the
> downstream Raspberry Pi kernel tree.

Please copy/reference the original author of the driver that is being
forward ported if it's not you.

> I have slightly consolidated things and done some quick testing of this
> driver on Fedora (which comes with the device tree blobs), and I want to
> do a bit more testing before submiting the driver for inclusion in
> mainline Linux.
>
> I would like to get some feedback from the community on what may need to
> be improved, fixed, or changed as early as possible, so this is a request
> for comments.

Without reviewing the actual drivers I would suggest:
1) split each driver out into a separate patch with a cover letter for
the series
2) Each of the drivers will also need to have their subsystem mailing
lists copied. Something like "./scripts/get_maintainer.pl -f
drivers/input/Kconfig" should give you this information
3) I suspect each of the drivers will also need a DT bindings added to
Documentation/devicetree/bindings/ as a separate patch

Peter

> Signed-off-by: Joel Savitz <joelsavitz at gmail.com>
> ---
>  drivers/input/joystick/Kconfig       |   8 +
>  drivers/input/joystick/Makefile      |   1 +
>  drivers/input/joystick/rpisense-js.c | 147 ++++++++++++++
>  drivers/mfd/Kconfig                  |   8 +
>  drivers/mfd/Makefile                 |   1 +
>  drivers/mfd/rpisense-core.c          | 162 +++++++++++++++
>  drivers/video/fbdev/Kconfig          |  13 ++
>  drivers/video/fbdev/Makefile         |   1 +
>  drivers/video/fbdev/rpisense-fb.c    | 291 +++++++++++++++++++++++++++
>  include/linux/mfd/rpisense.h         |  66 ++++++
>  10 files changed, 698 insertions(+)
>  create mode 100644 drivers/input/joystick/rpisense-js.c
>  create mode 100644 drivers/mfd/rpisense-core.c
>  create mode 100644 drivers/video/fbdev/rpisense-fb.c
>  create mode 100644 include/linux/mfd/rpisense.h
>
> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
> index 5e38899058c1..1c0025c22bf4 100644
> --- a/drivers/input/joystick/Kconfig
> +++ b/drivers/input/joystick/Kconfig
> @@ -389,4 +389,12 @@ config JOYSTICK_N64
>           Say Y here if you want enable support for the four
>           built-in controller ports on the Nintendo 64 console.
>
> +config JOYSTICK_RPISENSE
> +       tristate "Raspberry Pi Sense HAT joystick"
> +       depends on GPIOLIB && INPUT
> +       select MFD_RPISENSE_CORE
> +
> +       help
> +         This is the joystick driver for the Raspberry Pi Sense HAT
> +
>  endif
> diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
> index 31d720c9e493..b227e98cd179 100644
> --- a/drivers/input/joystick/Makefile
> +++ b/drivers/input/joystick/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_JOYSTICK_MAPLE)          += maplecontrol.o
>  obj-$(CONFIG_JOYSTICK_N64)             += n64joy.o
>  obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)      += psxpad-spi.o
>  obj-$(CONFIG_JOYSTICK_PXRC)            += pxrc.o
> +obj-$(CONFIG_JOYSTICK_RPISENSE)         += rpisense-js.o
>  obj-$(CONFIG_JOYSTICK_SIDEWINDER)      += sidewinder.o
>  obj-$(CONFIG_JOYSTICK_SPACEBALL)       += spaceball.o
>  obj-$(CONFIG_JOYSTICK_SPACEORB)                += spaceorb.o
> diff --git a/drivers/input/joystick/rpisense-js.c b/drivers/input/joystick/rpisense-js.c
> new file mode 100644
> index 000000000000..41d4bd1fed46
> --- /dev/null
> +++ b/drivers/input/joystick/rpisense-js.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Raspberry Pi Sense HAT joystick driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mfd/rpisense.h>
> +
> +static struct rpisense *rpisense;
> +static unsigned char keymap[5] = {KEY_DOWN, KEY_RIGHT, KEY_UP, KEY_ENTER, KEY_LEFT,};
> +
> +static void keys_work_fn(struct work_struct *work)
> +{
> +       int i;
> +       static s32 prev_keys;
> +       struct rpisense_js *rpisense_js = &rpisense->joystick;
> +       s32 keys = rpisense_reg_read(rpisense, RPISENSE_KEYS);
> +       s32 changes = keys ^ prev_keys;
> +
> +       prev_keys = keys;
> +       for (i = 0; i < 5; i++) {
> +               if (changes & 1) {
> +                       input_report_key(rpisense_js->keys_dev,
> +                                        keymap[i], keys & 1);
> +               }
> +               changes >>= 1;
> +               keys >>= 1;
> +       }
> +       input_sync(rpisense_js->keys_dev);
> +}
> +
> +static irqreturn_t keys_irq_handler(int irq, void *pdev)
> +{
> +       struct rpisense_js *rpisense_js = &rpisense->joystick;
> +
> +       schedule_work(&rpisense_js->keys_work_s);
> +       return IRQ_HANDLED;
> +}
> +
> +static int rpisense_js_probe(struct platform_device *pdev)
> +{
> +       int ret;
> +       int i;
> +       struct rpisense_js *rpisense_js;
> +
> +       rpisense = rpisense_get_dev();
> +       rpisense_js = &rpisense->joystick;
> +
> +       INIT_WORK(&rpisense_js->keys_work_s, keys_work_fn);
> +
> +       rpisense_js->keys_dev = input_allocate_device();
> +       if (!rpisense_js->keys_dev) {
> +               dev_err(&pdev->dev, "Could not allocate input device.\n");
> +               return -ENOMEM;
> +       }
> +
> +       rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY);
> +       for (i = 0; i < ARRAY_SIZE(keymap); i++) {
> +               set_bit(keymap[i],
> +                       rpisense_js->keys_dev->keybit);
> +       }
> +
> +       rpisense_js->keys_dev->name = "Raspberry Pi Sense HAT Joystick";
> +       rpisense_js->keys_dev->phys = "rpi-sense-joy/input0";
> +       rpisense_js->keys_dev->id.bustype = BUS_I2C;
> +       rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
> +       rpisense_js->keys_dev->keycode = keymap;
> +       rpisense_js->keys_dev->keycodesize = sizeof(unsigned char);
> +       rpisense_js->keys_dev->keycodemax = ARRAY_SIZE(keymap);
> +
> +       ret = input_register_device(rpisense_js->keys_dev);
> +       if (ret) {
> +               dev_err(&pdev->dev, "Could not register input device.\n");
> +               goto err_keys_alloc;
> +       }
> +
> +       ret = gpiod_direction_input(rpisense_js->keys_desc);
> +       if (ret) {
> +               dev_err(&pdev->dev, "Could not set keys-int direction.\n");
> +               goto err_keys_reg;
> +       }
> +
> +       rpisense_js->keys_irq = gpiod_to_irq(rpisense_js->keys_desc);
> +       if (rpisense_js->keys_irq < 0) {
> +               dev_err(&pdev->dev, "Could not determine keys-int IRQ.\n");
> +               ret = rpisense_js->keys_irq;
> +               goto err_keys_reg;
> +       }
> +
> +       ret = devm_request_irq(&pdev->dev, rpisense_js->keys_irq,
> +                              keys_irq_handler, IRQF_TRIGGER_RISING,
> +                              "keys", &pdev->dev);
> +       if (ret) {
> +               dev_err(&pdev->dev, "IRQ request failed.\n");
> +               goto err_keys_reg;
> +       }
> +       return 0;
> +err_keys_reg:
> +       input_unregister_device(rpisense_js->keys_dev);
> +err_keys_alloc:
> +       input_free_device(rpisense_js->keys_dev);
> +       return ret;
> +}
> +
> +static int rpisense_js_remove(struct platform_device *pdev)
> +{
> +       struct rpisense_js *rpisense_js = &rpisense->joystick;
> +
> +       input_unregister_device(rpisense_js->keys_dev);
> +       input_free_device(rpisense_js->keys_dev);
> +       return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id rpisense_js_id[] = {
> +       { .compatible = "raspberrypi,rpi-sense-js" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, rpisense_js_id);
> +#endif
> +
> +static struct platform_device_id rpisense_js_device_id[] = {
> +       { .name = "rpi-sense-js" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(platform, rpisense_js_device_id);
> +
> +static struct platform_driver rpisense_js_driver = {
> +       .probe = rpisense_js_probe,
> +       .remove = rpisense_js_remove,
> +       .driver = {
> +               .name = "rpi-sense-js",
> +               .owner = THIS_MODULE,
> +       },
> +};
> +
> +module_platform_driver(rpisense_js_driver);
> +
> +MODULE_DESCRIPTION("Raspberry Pi Sense HAT joystick driver");
> +MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b74efa469e90..8c309e389359 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -11,6 +11,14 @@ config MFD_CORE
>         select IRQ_DOMAIN
>         default n
>
> +config MFD_RPISENSE_CORE
> +       tristate "Raspberry Pi Sense HAT core functions"
> +       depends on I2C
> +       select MFD_CORE
> +       help
> +         This is the core driver for the Raspberry Pi Sense HAT. This provides
> +         the necessary functions to communicate with the hardware.
> +
>  config MFD_CS5535
>         tristate "AMD CS5535 and CS5536 southbridge core functions"
>         select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 834f5463af28..7140a8fc36ee 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -263,6 +263,7 @@ obj-$(CONFIG_MFD_ROHM_BD71828)      += rohm-bd71828.o
>  obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
>  obj-$(CONFIG_MFD_STMFX)        += stmfx.o
>  obj-$(CONFIG_MFD_KHADAS_MCU)   += khadas-mcu.o
> +obj-$(CONFIG_MFD_RPISENSE_CORE) += rpisense-core.o
>  obj-$(CONFIG_MFD_ACER_A500_EC) += acer-ec-a500.o
>
>  obj-$(CONFIG_SGI_MFD_IOC3)     += ioc3.o
> diff --git a/drivers/mfd/rpisense-core.c b/drivers/mfd/rpisense-core.c
> new file mode 100644
> index 000000000000..aa2c394c5e67
> --- /dev/null
> +++ b/drivers/mfd/rpisense-core.c
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Raspberry Pi Sense HAT core driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + *
> + *  This driver is based on wm8350 implementation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/slab.h>
> +
> +#include <linux/mfd/rpisense.h>
> +
> +static struct rpisense *rpisense;
> +
> +static void rpisense_client_dev_register(struct rpisense *rpisense,
> +                                        const char *name,
> +                                        struct platform_device **pdev)
> +{
> +       int ret;
> +
> +       *pdev = platform_device_alloc(name, -1);
> +       if (*pdev == NULL) {
> +               dev_err(rpisense->dev, "Failed to allocate %s\n", name);
> +               return;
> +       }
> +
> +       (*pdev)->dev.parent = rpisense->dev;
> +       platform_set_drvdata(*pdev, rpisense);
> +       ret = platform_device_add(*pdev);
> +       if (ret != 0) {
> +               dev_err(rpisense->dev, "Failed to register %s: %d\n",
> +                       name, ret);
> +               platform_device_put(*pdev);
> +               *pdev = NULL;
> +       }
> +}
> +
> +static int rpisense_probe(struct i2c_client *i2c,
> +                              const struct i2c_device_id *id)
> +{
> +       int ret;
> +       struct rpisense_js *rpisense_js;
> +
> +       rpisense = devm_kzalloc(&i2c->dev, sizeof(struct rpisense), GFP_KERNEL);
> +       if (rpisense == NULL)
> +               return -ENOMEM;
> +
> +       i2c_set_clientdata(i2c, rpisense);
> +       rpisense->dev = &i2c->dev;
> +       rpisense->i2c_client = i2c;
> +
> +       ret = rpisense_reg_read(rpisense, RPISENSE_WAI);
> +       if (ret > 0) {
> +               if (ret != 's')
> +                       return -EINVAL;
> +       } else {
> +               return ret;
> +       }
> +       ret = rpisense_reg_read(rpisense, RPISENSE_VER);
> +       if (ret < 0)
> +               return ret;
> +
> +       dev_info(rpisense->dev,
> +                "Raspberry Pi Sense HAT firmware version %i\n", ret);
> +
> +       rpisense_js = &rpisense->joystick;
> +       rpisense_js->keys_desc = devm_gpiod_get(&i2c->dev,
> +                                               "keys-int", GPIOD_IN);
> +       if (IS_ERR(rpisense_js->keys_desc)) {
> +               dev_warn(&i2c->dev, "Failed to get keys-int descriptor.\n");
> +               rpisense_js->keys_desc = gpio_to_desc(23);
> +               if (rpisense_js->keys_desc == NULL) {
> +                       dev_err(&i2c->dev, "GPIO23 fallback failed.\n");
> +                       return PTR_ERR(rpisense_js->keys_desc);
> +               }
> +       }
> +       rpisense_client_dev_register(rpisense, "rpi-sense-js",
> +                                    &(rpisense->joystick.pdev));
> +       rpisense_client_dev_register(rpisense, "rpi-sense-fb",
> +                                    &(rpisense->framebuffer.pdev));
> +
> +       return 0;
> +}
> +
> +static int rpisense_remove(struct i2c_client *i2c)
> +{
> +       struct rpisense *rpisense = i2c_get_clientdata(i2c);
> +
> +       platform_device_unregister(rpisense->joystick.pdev);
> +       return 0;
> +}
> +
> +struct rpisense *rpisense_get_dev(void)
> +{
> +       return rpisense;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_get_dev);
> +
> +s32 rpisense_reg_read(struct rpisense *rpisense, int reg)
> +{
> +       int ret = i2c_smbus_read_byte_data(rpisense->i2c_client, reg);
> +
> +       if (ret < 0)
> +               dev_err(rpisense->dev, "Read from reg %d failed\n", reg);
> +       /* Due to the BCM270x I2C clock stretching bug, some values
> +        * may have MSB set. Clear it to avoid incorrect values.
> +        */
> +       return ret & 0x7F;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_reg_read);
> +
> +int rpisense_block_write(struct rpisense *rpisense, const char *buf, int count)
> +{
> +       int ret = i2c_master_send(rpisense->i2c_client, buf, count);
> +
> +       if (ret < 0)
> +               dev_err(rpisense->dev, "Block write failed\n");
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_block_write);
> +
> +static const struct i2c_device_id rpisense_i2c_id[] = {
> +       { "rpi-sense", 0 },
> +       { }
> +};
> +MODULE_DEVICE_TABLE(i2c, rpisense_i2c_id);
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id rpisense_core_id[] = {
> +       { .compatible = "raspberrypi,rpi-sense" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, rpisense_core_id);
> +#endif
> +
> +
> +static struct i2c_driver rpisense_driver = {
> +       .driver = {
> +                  .name = "rpi-sense",
> +                  .owner = THIS_MODULE,
> +       },
> +       .probe = rpisense_probe,
> +       .remove = rpisense_remove,
> +       .id_table = rpisense_i2c_id,
> +};
> +
> +module_i2c_driver(rpisense_driver);
> +
> +MODULE_DESCRIPTION("Raspberry Pi Sense HAT core driver");
> +MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
> +MODULE_LICENSE("GPL");
> +
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 4f02db65dede..2238e36e71e4 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2236,6 +2236,19 @@ config FB_SM712
>           called sm712fb. If you want to compile it as a module, say M
>           here and read <file:Documentation/kbuild/modules.rst>.
>
> +config FB_RPISENSE
> +        tristate "Raspberry Pi Sense HAT framebuffer"
> +        depends on FB
> +        select MFD_RPISENSE_CORE
> +        select FB_SYS_FOPS
> +        select FB_SYS_FILLRECT
> +        select FB_SYS_COPYAREA
> +        select FB_SYS_IMAGEBLIT
> +        select FB_DEFERRED_IO
> +
> +        help
> +          This is the framebuffer driver for the Raspberry Pi Sense HAT
> +
>  source "drivers/video/fbdev/omap/Kconfig"
>  source "drivers/video/fbdev/omap2/Kconfig"
>  source "drivers/video/fbdev/mmp/Kconfig"
> diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
> index 477b9624b703..5b17203b7e43 100644
> --- a/drivers/video/fbdev/Makefile
> +++ b/drivers/video/fbdev/Makefile
> @@ -129,6 +129,7 @@ obj-$(CONFIG_FB_MX3)                  += mx3fb.o
>  obj-$(CONFIG_FB_DA8XX)           += da8xx-fb.o
>  obj-$(CONFIG_FB_SSD1307)         += ssd1307fb.o
>  obj-$(CONFIG_FB_SIMPLE)           += simplefb.o
> +obj-$(CONFIG_FB_RPISENSE)         += rpisense-fb.o
>
>  # the test framebuffer is last
>  obj-$(CONFIG_FB_VIRTUAL)          += vfb.o
> diff --git a/drivers/video/fbdev/rpisense-fb.c b/drivers/video/fbdev/rpisense-fb.c
> new file mode 100644
> index 000000000000..a90a5ec51fd7
> --- /dev/null
> +++ b/drivers/video/fbdev/rpisense-fb.c
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Raspberry Pi Sense HAT framebuffer driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/string.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +#include <linux/delay.h>
> +#include <linux/fb.h>
> +#include <linux/init.h>
> +
> +#include <linux/mfd/rpisense.h>
> +
> +static bool lowlight;
> +module_param(lowlight, bool, 0);
> +MODULE_PARM_DESC(lowlight, "Reduce LED matrix brightness to one third");
> +
> +static struct rpisense *rpisense;
> +
> +struct rpisense_fb_param {
> +       char __iomem *vmem;
> +       u8 *vmem_work;
> +       u32 vmemsize;
> +       u8 *gamma;
> +};
> +
> +static u8 gamma_default[32] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01,
> +                              0x02, 0x02, 0x03, 0x03, 0x04, 0x05, 0x06, 0x07,
> +                              0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0E, 0x0F, 0x11,
> +                              0x12, 0x14, 0x15, 0x17, 0x19, 0x1B, 0x1D, 0x1F,};
> +
> +static u8 gamma_low[32] = {0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
> +                          0x01, 0x01, 0x01, 0x01, 0x01, 0x02, 0x02, 0x02,
> +                          0x03, 0x03, 0x03, 0x04, 0x04, 0x05, 0x05, 0x06,
> +                          0x06, 0x07, 0x07, 0x08, 0x08, 0x09, 0x0A, 0x0A,};
> +
> +static u8 gamma_user[32];
> +
> +static u32 pseudo_palette[16];
> +
> +static struct rpisense_fb_param rpisense_fb_param = {
> +       .vmem = NULL,
> +       .vmemsize = 128,
> +       .gamma = gamma_default,
> +};
> +
> +static struct fb_deferred_io rpisense_fb_defio;
> +
> +static struct fb_fix_screeninfo rpisense_fb_fix = {
> +       .id =           "RPi-Sense FB",
> +       .type =         FB_TYPE_PACKED_PIXELS,
> +       .visual =       FB_VISUAL_TRUECOLOR,
> +       .xpanstep =     0,
> +       .ypanstep =     0,
> +       .ywrapstep =    0,
> +       .accel =        FB_ACCEL_NONE,
> +       .line_length =  16,
> +};
> +
> +static struct fb_var_screeninfo rpisense_fb_var = {
> +       .xres           = 8,
> +       .yres           = 8,
> +       .xres_virtual   = 8,
> +       .yres_virtual   = 8,
> +       .bits_per_pixel = 16,
> +       .red            = {11, 5, 0},
> +       .green          = {5, 6, 0},
> +       .blue           = {0, 5, 0},
> +};
> +
> +static ssize_t rpisense_fb_write(struct fb_info *info,
> +                                const char __user *buf, size_t count,
> +                                loff_t *ppos)
> +{
> +       ssize_t res = fb_sys_write(info, buf, count, ppos);
> +
> +       schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
> +       return res;
> +}
> +
> +static void rpisense_fb_fillrect(struct fb_info *info,
> +                                const struct fb_fillrect *rect)
> +{
> +       sys_fillrect(info, rect);
> +       schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
> +}
> +
> +static void rpisense_fb_copyarea(struct fb_info *info,
> +                                const struct fb_copyarea *area)
> +{
> +       sys_copyarea(info, area);
> +       schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
> +}
> +
> +static void rpisense_fb_imageblit(struct fb_info *info,
> +                                 const struct fb_image *image)
> +{
> +       sys_imageblit(info, image);
> +       schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
> +}
> +
> +static void rpisense_fb_deferred_io(struct fb_info *info,
> +                               struct list_head *pagelist)
> +{
> +       int i;
> +       int j;
> +       u8 *vmem_work = rpisense_fb_param.vmem_work;
> +       u16 *mem = (u16 *)rpisense_fb_param.vmem;
> +       u8 *gamma = rpisense_fb_param.gamma;
> +
> +       vmem_work[0] = 0;
> +       for (j = 0; j < 8; j++) {
> +               for (i = 0; i < 8; i++) {
> +                       vmem_work[(j * 24) + i + 1] =
> +                               gamma[(mem[(j * 8) + i] >> 11) & 0x1F];
> +                       vmem_work[(j * 24) + (i + 8) + 1] =
> +                               gamma[(mem[(j * 8) + i] >> 6) & 0x1F];
> +                       vmem_work[(j * 24) + (i + 16) + 1] =
> +                               gamma[(mem[(j * 8) + i]) & 0x1F];
> +               }
> +       }
> +       rpisense_block_write(rpisense, vmem_work, 193);
> +}
> +
> +static struct fb_deferred_io rpisense_fb_defio = {
> +       .delay          = HZ/100,
> +       .deferred_io    = rpisense_fb_deferred_io,
> +};
> +
> +static int rpisense_fb_ioctl(struct fb_info *info, unsigned int cmd,
> +                            unsigned long arg)
> +{
> +       switch (cmd) {
> +       case SENSEFB_FBIOGET_GAMMA:
> +               if (copy_to_user((void __user *) arg, rpisense_fb_param.gamma,
> +                                sizeof(u8[32])))
> +                       return -EFAULT;
> +               return 0;
> +       case SENSEFB_FBIOSET_GAMMA:
> +               if (copy_from_user(gamma_user, (void __user *)arg,
> +                                  sizeof(u8[32])))
> +                       return -EFAULT;
> +               rpisense_fb_param.gamma = gamma_user;
> +               schedule_delayed_work(&info->deferred_work,
> +                                     rpisense_fb_defio.delay);
> +               return 0;
> +       case SENSEFB_FBIORESET_GAMMA:
> +               switch (arg) {
> +               case 0:
> +                       rpisense_fb_param.gamma = gamma_default;
> +                       break;
> +               case 1:
> +                       rpisense_fb_param.gamma = gamma_low;
> +                       break;
> +               case 2:
> +                       rpisense_fb_param.gamma = gamma_user;
> +                       break;
> +               default:
> +                       return -EINVAL;
> +               }
> +               schedule_delayed_work(&info->deferred_work,
> +                                     rpisense_fb_defio.delay);
> +               break;
> +       default:
> +               return -EINVAL;
> +       }
> +       return 0;
> +}
> +
> +static struct fb_ops rpisense_fb_ops = {
> +       .owner          = THIS_MODULE,
> +       .fb_read        = fb_sys_read,
> +       .fb_write       = rpisense_fb_write,
> +       .fb_fillrect    = rpisense_fb_fillrect,
> +       .fb_copyarea    = rpisense_fb_copyarea,
> +       .fb_imageblit   = rpisense_fb_imageblit,
> +       .fb_ioctl       = rpisense_fb_ioctl,
> +};
> +
> +static int rpisense_fb_probe(struct platform_device *pdev)
> +{
> +       struct fb_info *info;
> +       int ret = -ENOMEM;
> +       struct rpisense_fb *rpisense_fb;
> +
> +       rpisense = rpisense_get_dev();
> +       rpisense_fb = &rpisense->framebuffer;
> +
> +       rpisense_fb_param.vmem = vzalloc(rpisense_fb_param.vmemsize);
> +       if (!rpisense_fb_param.vmem)
> +               return ret;
> +
> +       rpisense_fb_param.vmem_work = devm_kmalloc(&pdev->dev, 193, GFP_KERNEL);
> +       if (!rpisense_fb_param.vmem_work)
> +               goto err_malloc;
> +
> +       info = framebuffer_alloc(0, &pdev->dev);
> +       if (!info) {
> +               dev_err(&pdev->dev, "Could not allocate framebuffer.\n");
> +               goto err_malloc;
> +       }
> +       rpisense_fb->info = info;
> +
> +       rpisense_fb_fix.smem_start = (unsigned long)rpisense_fb_param.vmem;
> +       rpisense_fb_fix.smem_len = rpisense_fb_param.vmemsize;
> +
> +       info->fbops = &rpisense_fb_ops;
> +       info->fix = rpisense_fb_fix;
> +       info->var = rpisense_fb_var;
> +       info->fbdefio = &rpisense_fb_defio;
> +       info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB;
> +       info->screen_base = rpisense_fb_param.vmem;
> +       info->screen_size = rpisense_fb_param.vmemsize;
> +       info->pseudo_palette = pseudo_palette;
> +
> +       if (lowlight)
> +               rpisense_fb_param.gamma = gamma_low;
> +
> +       fb_deferred_io_init(info);
> +
> +       ret = register_framebuffer(info);
> +       if (ret < 0) {
> +               dev_err(&pdev->dev, "Could not register framebuffer.\n");
> +               goto err_fballoc;
> +       }
> +
> +       fb_info(info, "%s frame buffer device\n", info->fix.id);
> +       schedule_delayed_work(&info->deferred_work, rpisense_fb_defio.delay);
> +       return 0;
> +err_fballoc:
> +       framebuffer_release(info);
> +err_malloc:
> +       vfree(rpisense_fb_param.vmem);
> +       return ret;
> +}
> +
> +static int rpisense_fb_remove(struct platform_device *pdev)
> +{
> +       struct rpisense_fb *rpisense_fb = &rpisense->framebuffer;
> +       struct fb_info *info = rpisense_fb->info;
> +
> +       if (info) {
> +               unregister_framebuffer(info);
> +               fb_deferred_io_cleanup(info);
> +               framebuffer_release(info);
> +               vfree(rpisense_fb_param.vmem);
> +       }
> +
> +       return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id rpisense_fb_id[] = {
> +       { .compatible = "raspberrypi,rpi-sense-fb" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, rpisense_fb_id);
> +#endif
> +
> +static struct platform_device_id rpisense_fb_device_id[] = {
> +       { .name = "rpi-sense-fb" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(platform, rpisense_fb_device_id);
> +
> +static struct platform_driver rpisense_fb_driver = {
> +       .probe = rpisense_fb_probe,
> +       .remove = rpisense_fb_remove,
> +       .driver = {
> +               .name = "rpi-sense-fb",
> +               .owner = THIS_MODULE,
> +       },
> +};
> +
> +module_platform_driver(rpisense_fb_driver);
> +
> +MODULE_DESCRIPTION("Raspberry Pi Sense HAT framebuffer driver");
> +MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
> +MODULE_LICENSE("GPL");
> +
> diff --git a/include/linux/mfd/rpisense.h b/include/linux/mfd/rpisense.h
> new file mode 100644
> index 000000000000..0718b6f0eddb
> --- /dev/null
> +++ b/include/linux/mfd/rpisense.h
> @@ -0,0 +1,66 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Raspberry Pi Sense HAT core driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + */
> +
> +#ifndef __LINUX_MFD_RPISENSE_CORE_H_
> +#define __LINUX_MFD_RPISENSE_CORE_H_
> +
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/platform_device.h>
> +
> +/*
> + * Register values.
> + */
> +#define RPISENSE_FB                    0x00
> +#define RPISENSE_WAI                   0xF0
> +#define RPISENSE_VER                   0xF1
> +#define RPISENSE_KEYS                  0xF2
> +#define RPISENSE_EE_WP                 0xF3
> +
> +#define RPISENSE_ID                    's'
> +
> +#define SENSEFB_FBIO_IOC_MAGIC 0xF1
> +
> +#define SENSEFB_FBIOGET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 0)
> +#define SENSEFB_FBIOSET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 1)
> +#define SENSEFB_FBIORESET_GAMMA _IO(SENSEFB_FBIO_IOC_MAGIC, 2)
> +
> +struct rpisense_fb {
> +       struct platform_device *pdev;
> +       struct fb_info *info;
> +};
> +
> +
> +struct rpisense_js {
> +       struct platform_device *pdev;
> +       struct input_dev *keys_dev;
> +       struct gpio_desc *keys_desc;
> +       struct work_struct keys_work_s;
> +       int keys_irq;
> +};
> +
> +
> +struct rpisense {
> +       struct device *dev;
> +       struct i2c_client *i2c_client;
> +
> +       /* Client devices */
> +       struct rpisense_js joystick;
> +       struct rpisense_fb framebuffer;
> +};
> +
> +struct rpisense *rpisense_get_dev(void);
> +s32 rpisense_reg_read(struct rpisense *rpisense, int reg);
> +int rpisense_reg_write(struct rpisense *rpisense, int reg, u16 val);
> +int rpisense_block_write(struct rpisense *rpisense, const char *buf, int count);
> +
> +#endif
> --
> 2.27.0
>
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


From wangyanan55 at huawei.com  Thu Apr  8 10:23:11 2021
From: wangyanan55 at huawei.com (wangyanan (Y))
Date: Thu, 8 Apr 2021 17:23:11 +0800
Subject: [RFC PATCH v3 1/2] KVM: arm64: Move CMOs from user_mem_abort to
 the fault handlers
In-Reply-To: <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-2-wangyanan55@huawei.com>
 <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>
Message-ID: <b688cf37-16e6-d068-d97f-146c64afca08@huawei.com>

Hi Alex,

On 2021/4/7 23:31, Alexandru Elisei wrote:
> Hi Yanan,
>
> On 3/26/21 3:16 AM, Yanan Wang wrote:
>> We currently uniformly permorm CMOs of D-cache and I-cache in function
>> user_mem_abort before calling the fault handlers. If we get concurrent
>> guest faults(e.g. translation faults, permission faults) or some really
>> unnecessary guest faults caused by BBM, CMOs for the first vcpu are
> I can't figure out what BBM means.
Just as Will has explained, it's Break-Before-Make rule. When we need to
replace an old table entry with a new one, we should firstly invalidate
the old table entry(Break), before installation of the new entry(Make).

And I think this patch mainly introduces benefits in two specific scenarios:
1) In a VM startup, it will improve efficiency of handling page faults 
incurred
by vCPUs, when initially populating stage2 page tables.
2) After live migration, the heavy workload will be resumed on the 
destination
VMs, however all the stage2 page tables need to be rebuilt.
>> necessary while the others later are not.
>>
>> By moving CMOs to the fault handlers, we can easily identify conditions
>> where they are really needed and avoid the unnecessary ones. As it's a
>> time consuming process to perform CMOs especially when flushing a block
>> range, so this solution reduces much load of kvm and improve efficiency
>> of the page table code.
>>
>> So let's move both clean of D-cache and invalidation of I-cache to the
>> map path and move only invalidation of I-cache to the permission path.
>> Since the original APIs for CMOs in mmu.c are only called in function
>> user_mem_abort, we now also move them to pgtable.c.
>>
>> Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
>> ---
>>   arch/arm64/include/asm/kvm_mmu.h | 31 ---------------
>>   arch/arm64/kvm/hyp/pgtable.c     | 68 +++++++++++++++++++++++++-------
>>   arch/arm64/kvm/mmu.c             | 23 ++---------
>>   3 files changed, 57 insertions(+), 65 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> index 90873851f677..c31f88306d4e 100644
>> --- a/arch/arm64/include/asm/kvm_mmu.h
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -177,37 +177,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
>>   	return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
>>   }
>>   
>> -static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
>> -{
>> -	void *va = page_address(pfn_to_page(pfn));
>> -
>> -	/*
>> -	 * With FWB, we ensure that the guest always accesses memory using
>> -	 * cacheable attributes, and we don't have to clean to PoC when
>> -	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
>> -	 * PoU is not required either in this case.
>> -	 */
>> -	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>> -		return;
>> -
>> -	kvm_flush_dcache_to_poc(va, size);
>> -}
>> -
>> -static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
>> -						  unsigned long size)
>> -{
>> -	if (icache_is_aliasing()) {
>> -		/* any kind of VIPT cache */
>> -		__flush_icache_all();
>> -	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
>> -		/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */
>> -		void *va = page_address(pfn_to_page(pfn));
>> -
>> -		invalidate_icache_range((unsigned long)va,
>> -					(unsigned long)va + size);
>> -	}
>> -}
>> -
>>   void kvm_set_way_flush(struct kvm_vcpu *vcpu);
>>   void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
>>   
>> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>> index 4d177ce1d536..829a34eea526 100644
>> --- a/arch/arm64/kvm/hyp/pgtable.c
>> +++ b/arch/arm64/kvm/hyp/pgtable.c
>> @@ -464,6 +464,43 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot prot,
>>   	return 0;
>>   }
>>   
>> +static bool stage2_pte_cacheable(kvm_pte_t pte)
>> +{
>> +	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
>> +	return memattr == PAGE_S2_MEMATTR(NORMAL);
>> +}
>> +
>> +static bool stage2_pte_executable(kvm_pte_t pte)
>> +{
>> +	return !(pte & KVM_PTE_LEAF_ATTR_HI_S2_XN);
>> +}
>> +
>> +static void stage2_flush_dcache(void *addr, u64 size)
>> +{
>> +	/*
>> +	 * With FWB, we ensure that the guest always accesses memory using
>> +	 * cacheable attributes, and we don't have to clean to PoC when
>> +	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
>> +	 * PoU is not required either in this case.
>> +	 */
>> +	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>> +		return;
>> +
>> +	__flush_dcache_area(addr, size);
>> +}
>> +
>> +static void stage2_invalidate_icache(void *addr, u64 size)
>> +{
>> +	if (icache_is_aliasing()) {
>> +		/* Flush any kind of VIPT icache */
>> +		__flush_icache_all();
>> +	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
>> +		/* PIPT or VPIPT at EL2 */
>> +		invalidate_icache_range((unsigned long)addr,
>> +					(unsigned long)addr + size);
>> +	}
>> +}
>> +
>>   static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
>>   				      kvm_pte_t *ptep,
>>   				      struct stage2_map_data *data)
>> @@ -495,6 +532,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
>>   		put_page(page);
>>   	}
>>   
>> +	/* Perform CMOs before installation of the new PTE */
>> +	if (!kvm_pte_valid(old) || stage2_pte_cacheable(old))
> I'm not sure why the stage2_pte_cacheable(old) condition is needed.
>
> kvm_handle_guest_abort() handles three types of stage 2 data or instruction
> aborts: translation faults (fault_status == FSC_FAULT), access faults
> (fault_status == FSC_ACCESS) and permission faults (fault_status == FSC_PERM).
>
> Access faults are handled in handle_access_fault(), which means user_mem_abort()
> handles translation and permission faults.
Yes, and we are certain that it's a translation fault here in 
stage2_map_walker_try_leaf.
> The original code did the dcache clean
> + inval when not a permission fault, which means the CMO was done only on a
> translation fault. Translation faults mean that the IPA was not mapped, so the old
> entry will always be invalid. Even if we're coalescing multiple last level leaf
> entries int oa? block mapping, the table entry which is replaced is invalid
> because it's marked as such in stage2_map_walk_table_pre().
>
> Is there something I'm missing?
I originally thought that we could possibly have a translation fault on 
a valid stage2 table
descriptor due to some special cases, and that's the reason 
stage2_pte_cacheable(old)
condition exits, but I can't image any scenario like this.

I think your above explanation is right, maybe I should just drop that 
condition.
>
>> +		stage2_flush_dcache(__va(phys), granule);
>> +
>> +	if (stage2_pte_executable(new))
>> +		stage2_invalidate_icache(__va(phys), granule);
> This, together with the stage2_attr_walker() changes below, look identical to the
> current code in user_mem_abort(). The executable permission is set on an exec
> fault (instruction abort not on a stage 2 translation table walk), and as a result
> of the fault we either need to map a new page here, or relax permissions in
> kvm_pgtable_stage2_relax_perms() -> stage2_attr_walker() below.
I agree.
Do you mean this part of change is right?

Thanks,
Yanan
> Thanks,
>
> Alex
>
>> +
>>   	smp_store_release(ptep, new);
>>   	get_page(page);
>>   	data->phys += granule;
>> @@ -651,20 +695,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
>>   	return ret;
>>   }
>>   
>> -static void stage2_flush_dcache(void *addr, u64 size)
>> -{
>> -	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>> -		return;
>> -
>> -	__flush_dcache_area(addr, size);
>> -}
>> -
>> -static bool stage2_pte_cacheable(kvm_pte_t pte)
>> -{
>> -	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
>> -	return memattr == PAGE_S2_MEMATTR(NORMAL);
>> -}
>> -
>>   static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
>>   			       enum kvm_pgtable_walk_flags flag,
>>   			       void * const arg)
>> @@ -743,8 +773,16 @@ static int stage2_attr_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
>>   	 * but worst-case the access flag update gets lost and will be
>>   	 * set on the next access instead.
>>   	 */
>> -	if (data->pte != pte)
>> +	if (data->pte != pte) {
>> +		/*
>> +		 * Invalidate the instruction cache before updating
>> +		 * if we are going to add the executable permission.
>> +		 */
>> +		if (!stage2_pte_executable(*ptep) && stage2_pte_executable(pte))
>> +			stage2_invalidate_icache(kvm_pte_follow(pte),
>> +						 kvm_granule_size(level));
>>   		WRITE_ONCE(*ptep, pte);
>> +	}
>>   
>>   	return 0;
>>   }
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 77cb2d28f2a4..1eec9f63bc6f 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -609,16 +609,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
>>   	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
>>   }
>>   
>> -static void clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
>> -{
>> -	__clean_dcache_guest_page(pfn, size);
>> -}
>> -
>> -static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
>> -{
>> -	__invalidate_icache_guest_page(pfn, size);
>> -}
>> -
>>   static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>   {
>>   	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>> @@ -882,13 +872,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	if (writable)
>>   		prot |= KVM_PGTABLE_PROT_W;
>>   
>> -	if (fault_status != FSC_PERM && !device)
>> -		clean_dcache_guest_page(pfn, vma_pagesize);
>> -
>> -	if (exec_fault) {
>> +	if (exec_fault)
>>   		prot |= KVM_PGTABLE_PROT_X;
>> -		invalidate_icache_guest_page(pfn, vma_pagesize);
>> -	}
>>   
>>   	if (device)
>>   		prot |= KVM_PGTABLE_PROT_DEVICE;
>> @@ -1144,10 +1129,10 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
>>   	trace_kvm_set_spte_hva(hva);
>>   
>>   	/*
>> -	 * We've moved a page around, probably through CoW, so let's treat it
>> -	 * just like a translation fault and clean the cache to the PoC.
>> +	 * We've moved a page around, probably through CoW, so let's treat
>> +	 * it just like a translation fault and the map handler will clean
>> +	 * the cache to the PoC.
>>   	 */
>> -	clean_dcache_guest_page(pfn, PAGE_SIZE);
>>   	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
>>   	return 0;
>>   }
> .


From dinghao.liu at zju.edu.cn  Thu Apr  8 10:25:59 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Thu,  8 Apr 2021 17:25:59 +0800
Subject: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
Message-ID: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>

When platform_get_irq() fails, a pairing PM usage counter
increment is needed to keep the counter balanced. It's the
same for the following error paths.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---
 drivers/spi/spi-zynqmp-gqspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..95963a2de64a 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1197,6 +1197,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	return 0;
 
 clk_dis_all:
+	pm_runtime_get_noresume(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	clk_disable_unprepare(xqspi->refclk);
-- 
2.17.1



From wangyanan55 at huawei.com  Thu Apr  8 10:31:18 2021
From: wangyanan55 at huawei.com (wangyanan (Y))
Date: Thu, 8 Apr 2021 17:31:18 +0800
Subject: [RFC PATCH v3 2/2] KVM: arm64: Distinguish cases of memcache
 allocations completely
In-Reply-To: <4348b555-2a38-6f00-8ef0-0d5fd801d753@arm.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-3-wangyanan55@huawei.com>
 <4348b555-2a38-6f00-8ef0-0d5fd801d753@arm.com>
Message-ID: <2f7872af-b5dc-9e81-574d-928849ad473c@huawei.com>


On 2021/4/7 23:35, Alexandru Elisei wrote:
> Hi Yanan,
>
> On 3/26/21 3:16 AM, Yanan Wang wrote:
>> With a guest translation fault, the memcache pages are not needed if KVM
>> is only about to install a new leaf entry into the existing page table.
>> And with a guest permission fault, the memcache pages are also not needed
>> for a write_fault in dirty-logging time if KVM is only about to update
>> the existing leaf entry instead of collapsing a block entry into a table.
>>
>> By comparing fault_granule and vma_pagesize, cases that require allocations
>> from memcache and cases that don't can be distinguished completely.
>>
>> Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
>> ---
>>   arch/arm64/kvm/mmu.c | 25 ++++++++++++-------------
>>   1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 1eec9f63bc6f..05af40dc60c1 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -810,19 +810,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	gfn = fault_ipa >> PAGE_SHIFT;
>>   	mmap_read_unlock(current->mm);
>>   
>> -	/*
>> -	 * Permission faults just need to update the existing leaf entry,
>> -	 * and so normally don't require allocations from the memcache. The
>> -	 * only exception to this is when dirty logging is enabled at runtime
>> -	 * and a write fault needs to collapse a block entry into a table.
>> -	 */
>> -	if (fault_status != FSC_PERM || (logging_active && write_fault)) {
>> -		ret = kvm_mmu_topup_memory_cache(memcache,
>> -						 kvm_mmu_cache_min_pages(kvm));
>> -		if (ret)
>> -			return ret;
>> -	}
>> -
>>   	mmu_seq = vcpu->kvm->mmu_notifier_seq;
>>   	/*
>>   	 * Ensure the read of mmu_notifier_seq happens before we call
>> @@ -880,6 +867,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
>>   		prot |= KVM_PGTABLE_PROT_X;
>>   
>> +	/*
>> +	 * Allocations from the memcache are required only when granule of the
>> +	 * lookup level where the guest fault happened exceeds vma_pagesize,
>> +	 * which means new page tables will be created in the fault handlers.
>> +	 */
>> +	if (fault_granule > vma_pagesize) {
>> +		ret = kvm_mmu_topup_memory_cache(memcache,
>> +						 kvm_mmu_cache_min_pages(kvm));
>> +		if (ret)
>> +			return ret;
>> +	}
> As I explained in v1 [1], this looks correct to me. I still think that someone
> else should have a look, but if Marc decides to pick up this patch as-is, he can
> add my Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>.
Thanks again for this, Alex!

Hi Marc, Will,
Any thoughts about this patch?

Thanks,
Yanan
> [1] https://lore.kernel.org/lkml/2c65bff2-be7f-b20c-9265-939bc73185b6 at arm.com/
>
> Thanks,
>
> Alex
>
>> +
>>   	/*
>>   	 * Under the premise of getting a FSC_PERM fault, we just need to relax
>>   	 * permissions only if vma_pagesize equals fault_granule. Otherwise,
> .


From nobuhiro1.iwamatsu at toshiba.co.jp  Thu Apr  8 10:34:09 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Thu, 8 Apr 2021 18:34:09 +0900
Subject: [PATCH 2/3] PCI: dwc: Visoconti: PCIe RC controller driver
In-Reply-To: <20210407142734.GA3606952@robh.at.kernel.org>
References: <20210407031839.386088-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210407031839.386088-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210407142734.GA3606952@robh.at.kernel.org>
Message-ID: <20210408093409.v7djeagids4j7pad@toshiba.co.jp>

Hi,

Thanks for your review.

On Wed, Apr 07, 2021 at 09:27:34AM -0500, Rob Herring wrote:
> On Wed, Apr 07, 2021 at 12:18:38PM +0900, Nobuhiro Iwamatsu wrote:
> > Add support to PCIe RC controller on Toshiba Visconti ARM SoCs.
> > PCIe controller is based of Synopsys DesignWare PCIe core.
> > 
> > Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > ---
> >  drivers/pci/controller/dwc/Kconfig         |  10 +
> >  drivers/pci/controller/dwc/Makefile        |   1 +
> >  drivers/pci/controller/dwc/pcie-visconti.c | 358 +++++++++++++++++++++
> >  3 files changed, 369 insertions(+)
> >  create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c
> > 
> > diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> > index b9aaa84452c4..ae125d7cf375 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -286,6 +286,16 @@ config PCIE_TEGRA194_EP
> >  	  in order to enable device-specific features PCIE_TEGRA194_EP must be
> >  	  selected. This uses the DesignWare core.
> >  
> > +config PCIE_VISCONTI
> > +	bool "Toshiba VISCONTI PCIe controllers"
> > +	depends on ARCH_VISCONTI || COMPILE_TEST
> > +	depends on OF && HAS_IOMEM
> 
> Is this line really needed? Seems we have a mixture on other drivers.

hmm, thanks. I will remove this.

> 
> > +	depends on PCI_MSI_IRQ_DOMAIN
> > +	select PCIE_DW_HOST
> > +	help
> > +	  Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
> > +	  This driver supports TMPV77xx.
> > +
> >  config PCIE_UNIPHIER
> >  	bool "Socionext UniPhier PCIe host controllers"
> >  	depends on ARCH_UNIPHIER || COMPILE_TEST
> > diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> > index ba7c42f6df6f..46ac5d49dc75 100644
> > --- a/drivers/pci/controller/dwc/Makefile
> > +++ b/drivers/pci/controller/dwc/Makefile
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
> >  obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
> >  obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
> >  obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
> > +obj-$(CONFIG_PCIE_VISCONTI) += pcie-visconti.o
> >  
> >  # The following drivers are for devices that use the generic ACPI
> >  # pci_root.c driver but don't support standard ECAM config access.
> > diff --git a/drivers/pci/controller/dwc/pcie-visconti.c b/drivers/pci/controller/dwc/pcie-visconti.c
> > new file mode 100644
> > index 000000000000..e24f83df41b8
> > --- /dev/null
> > +++ b/drivers/pci/controller/dwc/pcie-visconti.c
> > @@ -0,0 +1,358 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DWC PCIe RC driver for Toshiba Visconti ARM SoC
> > + *
> > + * Copyright (C) 2019, 2020 Toshiba Electronic Device & Storage Corporation
> > + * Copyright (C) 2020, TOSHIBA CORPORATION
> > + *
> > + * Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > + *
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/gpio.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/init.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/kernel.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/pci.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/resource.h>
> > +#include <linux/types.h>
> > +
> > +#include "pcie-designware.h"
> > +#include "../../pci.h"
> > +
> > +struct visconti_pcie {
> > +	struct dw_pcie *pci;
> 
> Embed this rather than a pointer. 1 less alloc.

I see. I will change .

> 
> > +	void __iomem *ulreg_base;
> > +	void __iomem *smu_base;
> > +	void __iomem *mpu_base;
> > +	struct clk *refclk;
> > +	struct clk *sysclk;
> > +	struct clk *auxclk;
> > +};
> > +
> > +#define PCIE_UL_REG_S_PCIE_MODE		0x00F4
> > +#define  PCIE_UL_REG_S_PCIE_MODE_EP	0x00
> > +#define  PCIE_UL_REG_S_PCIE_MODE_RC	0x04
> > +
> > +#define PCIE_UL_REG_S_PERSTN_CTRL	0x00F8
> > +#define  PCIE_UL_IOM_PCIE_PERSTN_I_EN	BIT(3)
> > +#define  PCIE_UL_DIRECT_PERSTN_EN	BIT(2)
> > +#define  PCIE_UL_PERSTN_OUT		BIT(1)
> > +#define  PCIE_UL_DIRECT_PERSTN		BIT(0)
> > +
> > +#define PCIE_UL_REG_S_PHY_INIT_02	0x0104
> > +#define  PCIE_UL_PHY0_SRAM_EXT_LD_DONE	BIT(0)
> > +
> > +#define PCIE_UL_REG_S_PHY_INIT_03	0x0108
> > +#define  PCIE_UL_PHY0_SRAM_INIT_DONE	BIT(0)
> > +
> > +#define PCIE_UL_REG_S_INT_EVENT_MASK1	0x0138
> > +#define  PCIE_UL_CFG_PME_INT		BIT(0)
> > +#define  PCIE_UL_CFG_LINK_EQ_REQ_INT	BIT(1)
> > +#define  PCIE_UL_EDMA_INT0		BIT(2)
> > +#define  PCIE_UL_EDMA_INT1		BIT(3)
> > +#define  PCIE_UL_EDMA_INT2		BIT(4)
> > +#define  PCIE_UL_EDMA_INT3		BIT(5)
> > +#define  PCIE_UL_S_INT_EVENT_MASK1_ALL  (PCIE_UL_CFG_PME_INT | PCIE_UL_CFG_LINK_EQ_REQ_INT | \
> > +					 PCIE_UL_EDMA_INT0 | PCIE_UL_EDMA_INT1 | \
> > +					 PCIE_UL_EDMA_INT2 | PCIE_UL_EDMA_INT3)
> > +
> > +#define PCIE_UL_REG_S_SB_MON		0x0198
> > +#define PCIE_UL_REG_S_SIG_MON		0x019C
> > +#define  PCIE_UL_CORE_RST_N_MON		BIT(0)
> > +
> > +#define PCIE_UL_REG_V_SII_DBG_00	0x0844
> > +#define PCIE_UL_REG_V_SII_GEN_CTRL_01	0x0860
> > +#define  PCIE_UL_APP_LTSSM_ENABLE	BIT(0)
> > +
> > +#define PCIE_UL_REG_V_PHY_ST_00		0x0864
> > +#define  PCIE_UL_SMLH_LINK_UP		BIT(0)
> > +
> > +#define PCIE_UL_REG_V_PHY_ST_02		0x0868
> > +#define  PCIE_UL_S_DETECT_ACT		0x01
> > +#define  PCIE_UL_S_L0			0x11
> > +
> > +#define PISMU_CKON_PCIE			0x0038
> > +#define  PISMU_CKON_PCIE_AUX_CLK	BIT(1)
> > +#define  PISMU_CKON_PCIE_MSTR_ACLK	BIT(0)
> > +
> > +#define PISMU_RSOFF_PCIE		0x0538
> > +#define  PISMU_RSOFF_PCIE_ULREG_RST_N	BIT(1)
> > +#define  PISMU_RSOFF_PCIE_PWR_UP_RST_N	BIT(0)
> > +
> > +#define PCIE_MPU_REG_MP_EN		0x0
> > +#define  MPU_MP_EN_DISABLE		BIT(0)
> > +
> > +#define PCIE_BUS_OFFSET			0x40000000
> > +
> > +/* Access registers in PCIe ulreg */
> > +static inline void visconti_ulreg_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> > +{
> > +	writel(val, pcie->ulreg_base + reg);
> 
> Do these need ordering WRT DMA? If not, use _relaxed variant.

This and others does not required WRT DMA. I will change to use _relaxed functions.

> 
> > +}
> > +
> > +/* Access registers in PCIe smu */
> > +static inline void visconti_smu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> > +{
> > +	writel(val, pcie->smu_base + reg);
> > +}
> > +
> > +/* Access registers in PCIe mpu */
> > +static inline void visconti_mpu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> > +{
> > +	writel(val, pcie->mpu_base + reg);
> > +}
> > +
> > +static inline u32 visconti_mpu_readl(struct visconti_pcie *pcie, u32 reg)
> > +{
> > +	return readl(pcie->mpu_base + reg);
> > +}
> > +
> > +static int visconti_pcie_check_link_status(struct visconti_pcie *pcie)
> > +{
> > +	int err;
> > +	u32 val;
> > +
> > +	/* wait for linkup of phy link layer */
> > +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_00, val,
> > +				 (val & PCIE_UL_SMLH_LINK_UP), 1000, 10000);
> > +	if (err)
> > +		return err;
> > +
> > +	/* wait for linkup of data link layer */
> > +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> > +				 (val & PCIE_UL_S_DETECT_ACT), 1000, 10000);
> > +	if (err)
> > +		return err;
> > +
> > +	/* wait for LTSSM Status */
> > +	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> > +				  (val & PCIE_UL_S_L0), 1000, 10000);
> > +}
> > +
> > +static int visconti_pcie_establish_link(struct pcie_port *pp)
> > +{
> > +	int ret;
> > +	u32 val;
> > +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > +	struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);
> > +
> > +	visconti_ulreg_writel(pcie, PCIE_UL_APP_LTSSM_ENABLE, PCIE_UL_REG_V_SII_GEN_CTRL_01);
> > +
> > +	ret = visconti_pcie_check_link_status(pcie);
> > +	if (ret < 0) {
> > +		dev_info(pci->dev, "Link failure\n");
> > +		return ret;
> > +	}
> > +
> > +	val = visconti_mpu_readl(pcie, PCIE_MPU_REG_MP_EN);
> > +	visconti_mpu_writel(pcie, val & ~MPU_MP_EN_DISABLE, PCIE_MPU_REG_MP_EN);
> > +
> > +	visconti_ulreg_writel(pcie, PCIE_UL_S_INT_EVENT_MASK1_ALL, PCIE_UL_REG_S_INT_EVENT_MASK1);
> 
> Seems like all this should be a phy driver.
> 

I see. I will consider if it can be replaced with a phy driver.


> > +
> > +	return 0;
> > +}
> > +
> > +static int visconti_pcie_host_init(struct pcie_port *pp)
> > +{
> > +	int ret;
> > +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > +
> > +	dw_pcie_setup_rc(pp);
> 
> > +	ret = visconti_pcie_establish_link(pp);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	dw_pcie_wait_for_link(pci);
> 
> The DWC core code does link handling now.
> 

OK, I will check this.

> > +
> > +	return 0;
> > +}
> > +
> > +static const struct dw_pcie_host_ops visconti_pcie_host_ops = {
> > +	.host_init = visconti_pcie_host_init,
> > +};
> > +
> > +static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 pci_addr)
> > +{
> > +	return pci_addr - PCIE_BUS_OFFSET;
> > +}
> > +
> > +static const struct dw_pcie_ops dw_pcie_ops = {
> > +	.cpu_addr_fixup = visconti_pcie_cpu_addr_fixup,
> > +};
> > +
> > +static int visconti_get_resources(struct platform_device *pdev,
> > +				  struct visconti_pcie *pcie)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +
> > +	pcie->pci->dbi_base = devm_platform_ioremap_resource_byname(pdev, "dbi");
> > +	if (IS_ERR(pcie->pci->dbi_base))
> > +		return PTR_ERR(pcie->pci->dbi_base);
> 
> The DWC core handles this now.

OK, I will drop this.

> 
> > +
> > +	pcie->ulreg_base = devm_platform_ioremap_resource_byname(pdev, "ulreg");
> > +	if (IS_ERR(pcie->ulreg_base))
> > +		return PTR_ERR(pcie->ulreg_base);
> > +
> > +	pcie->smu_base = devm_platform_ioremap_resource_byname(pdev, "smu");
> > +	if (IS_ERR(pcie->smu_base))
> > +		return PTR_ERR(pcie->smu_base);
> > +
> > +	pcie->mpu_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
> > +	if (IS_ERR(pcie->mpu_base))
> > +		return PTR_ERR(pcie->mpu_base);
> > +
> > +	pcie->refclk = devm_clk_get(dev, "pcie_refclk");
> > +	if (IS_ERR(pcie->refclk)) {
> > +		dev_err(dev, "Failed to get refclk clock: %ld\n", PTR_ERR(pcie->refclk));
> > +		return PTR_ERR(pcie->refclk);
> > +	}
> > +
> > +	pcie->sysclk = devm_clk_get(dev, "sysclk");
> > +	if (IS_ERR(pcie->sysclk)) {
> > +		dev_err(dev, "Failed to get sysclk clock: %ld\n", PTR_ERR(pcie->sysclk));
> > +		return PTR_ERR(pcie->sysclk);
> > +	}
> > +
> > +	pcie->auxclk = devm_clk_get(dev, "auxclk");
> > +	if (IS_ERR(pcie->auxclk)) {
> > +		dev_err(dev, "Failed to get auxclk clock: %ld\n", PTR_ERR(pcie->auxclk));
> > +		return PTR_ERR(pcie->auxclk);
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int visconti_device_turnon(struct visconti_pcie *pcie)
> > +{
> > +	int err;
> > +	u32 val;
> > +
> > +	visconti_smu_writel(pcie, PISMU_CKON_PCIE_AUX_CLK | PISMU_CKON_PCIE_MSTR_ACLK,
> > +			    PISMU_CKON_PCIE);
> 
> Clock control? Should be a clock provider then.
> 

Visconti does not have clock driver yet, I'm also developping a driver for this,
but it's still in the process. I plan to replace it with a clock driver later.
And I should have written this in the commit message.


> > +	ndelay(250);
> > +
> > +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_ULREG_RST_N, PISMU_RSOFF_PCIE);
> > +
> > +	visconti_ulreg_writel(pcie, PCIE_UL_REG_S_PCIE_MODE_RC, PCIE_UL_REG_S_PCIE_MODE);
> > +
> > +	val = PCIE_UL_IOM_PCIE_PERSTN_I_EN | PCIE_UL_DIRECT_PERSTN_EN | PCIE_UL_DIRECT_PERSTN;
> > +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> > +	udelay(100);
> > +
> > +	val |= PCIE_UL_PERSTN_OUT;
> > +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> > +	udelay(100);
> > +
> > +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_PWR_UP_RST_N, PISMU_RSOFF_PCIE);
> > +
> > +	err = readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_PHY_INIT_03, val,
> > +				 (val & PCIE_UL_PHY0_SRAM_INIT_DONE), 100, 1000);
> > +	if (err)
> > +		return err;
> > +
> > +	visconti_ulreg_writel(pcie, PCIE_UL_PHY0_SRAM_EXT_LD_DONE, PCIE_UL_REG_S_PHY_INIT_02);
> > +
> > +	return readl_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_SIG_MON, val,
> > +				 (val & PCIE_UL_CORE_RST_N_MON), 100, 1000);
> > +}
> > +
> > +static int visconti_add_pcie_port(struct visconti_pcie *pcie, struct platform_device *pdev)
> > +{
> > +	struct dw_pcie *pci = pcie->pci;
> > +	struct pcie_port *pp = &pci->pp;
> > +	struct device *dev = &pdev->dev;
> > +	int ret;
> > +
> > +	pp->irq = platform_get_irq_byname(pdev, "intr");
> > +	if (pp->irq < 0) {
> > +		dev_err(dev, "interrupt intr is missing");
> > +		return pp->irq;
> > +	}
> > +
> > +	if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > +		pp->msi_irq = platform_get_irq_byname(pdev, "msi");
> > +		if (pp->msi_irq < 0) {
> > +			dev_err(dev, "interrupt msi is missing");
> > +			return pp->msi_irq;
> > +		}
> > +	}
> 
> DWC core handles this now.

OK, I will drop this.

Best regards,
  Nobuhiro



From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:10 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:10 +0800
Subject: [PATCH 2/6] usb: xhci-mtk: check return value in suspend/resume hooks
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617874514-12282-2-git-send-email-chunfeng.yun@mediatek.com>

Return error number if encounter errors during suspend and resume.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c1bc40289833..a74764ab914a 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -630,18 +630,12 @@ static int xhci_mtk_remove(struct platform_device *dev)
 	return 0;
 }
 
-/*
- * if ip sleep fails, and all clocks are disabled, access register will hang
- * AHB bus, so stop polling roothubs to avoid regs access on bus suspend.
- * and no need to check whether ip sleep failed or not; this will cause SPM
- * to wake up system immediately after system suspend complete if ip sleep
- * fails, it is what we wanted.
- */
 static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 {
 	struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
 	struct usb_hcd *hcd = mtk->hcd;
 	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+	int ret;
 
 	xhci_dbg(xhci, "%s: stop port polling\n", __func__);
 	clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
@@ -649,10 +643,21 @@ static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 	clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
 	del_timer_sync(&xhci->shared_hcd->rh_timer);
 
-	xhci_mtk_host_disable(mtk);
+	ret = xhci_mtk_host_disable(mtk);
+	if (ret)
+		goto restart_poll_rh;
+
 	xhci_mtk_clks_disable(mtk);
 	usb_wakeup_set(mtk, true);
 	return 0;
+
+restart_poll_rh:
+	xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+	set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
+	usb_hcd_poll_rh_status(xhci->shared_hcd);
+	set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+	usb_hcd_poll_rh_status(hcd);
+	return ret;
 }
 
 static int __maybe_unused xhci_mtk_resume(struct device *dev)
@@ -660,10 +665,16 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
 	struct usb_hcd *hcd = mtk->hcd;
 	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+	int ret;
 
 	usb_wakeup_set(mtk, false);
-	xhci_mtk_clks_enable(mtk);
-	xhci_mtk_host_enable(mtk);
+	ret = xhci_mtk_clks_enable(mtk);
+	if (ret)
+		goto enable_wakeup;
+
+	ret = xhci_mtk_host_enable(mtk);
+	if (ret)
+		goto disable_clks;
 
 	xhci_dbg(xhci, "%s: restart port polling\n", __func__);
 	set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
@@ -671,6 +682,12 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
 	usb_hcd_poll_rh_status(hcd);
 	return 0;
+
+disable_clks:
+	xhci_mtk_clks_disable(mtk);
+enable_wakeup:
+	usb_wakeup_set(mtk, true);
+	return ret;
 }
 
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
-- 
2.18.0

From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:11 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:11 +0800
Subject: [PATCH 3/6] dt-bindings: usb: mtk-xhci: add wakeup interrupt
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617874514-12282-3-git-send-email-chunfeng.yun@mediatek.com>

Add an interrupt which is EINT usually to support runtime PM,
meanwhile add "interrupt-names" property, for backward
compatibility, it's optional and used when wakeup interrupt
exists

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml  | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index 45bf4ea00c9e..4fe8a301d03f 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -46,7 +46,18 @@ properties:
       - const: ippc  # optional, only needed for case 1.
 
   interrupts:
-    maxItems: 1
+    description:
+      use "interrupts-extended" when the interrupts are connected to the
+      separate interrupt controllers
+    minItems: 1
+    items:
+      - description: xHCI host controller interrupt
+      - description: optional, wakeup interrupt used to support runtime PM
+
+  interrupt-names:
+    items:
+      - const: host
+      - const: wakeup
 
   power-domains:
     description: A phandle to USB power domain node to control USB's MTCMOS
-- 
2.18.0

From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:09 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:09 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend hook
 called
Message-ID: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>

When the dedicated wake irq is level trigger, enable it before
calling runtime_suspend, will trigger an interrupt.

e.g.
for a low level trigger type, it's low level at running time (0),
and becomes high level when enters suspend (runtime_suspend (1) is
called), a wakeup signal at (2) make it become low level, wake irq
will be triggered.

                ------------------
               |           ^     ^|
----------------           |     | --------------
 |<---(0)--->|<--(1)--|   (3)   (2)    (4)

if we enable the wake irq before calling runtime_suspend during (0),
an interrupt will arise, it causes resume immediately;
enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
will works.

This patch seems no side effect on edge trigger wake irq.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/base/power/runtime.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index a46a7e30881b..796739a015a5 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 	__update_runtime_status(dev, RPM_SUSPENDING);
 
 	callback = RPM_GET_CALLBACK(dev, runtime_suspend);
-
-	dev_pm_enable_wake_irq_check(dev, true);
 	retval = rpm_callback(callback, dev);
 	if (retval)
 		goto fail;
 
+	dev_pm_enable_wake_irq_check(dev, true);
+
  no_callback:
 	__update_runtime_status(dev, RPM_SUSPENDED);
 	pm_runtime_deactivate_timer(dev);
@@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 	return retval;
 
  fail:
-	dev_pm_disable_wake_irq_check(dev);
 	__update_runtime_status(dev, RPM_ACTIVE);
 	dev->power.deferred_resume = false;
 	wake_up_all(&dev->power.wait_queue);
-- 
2.18.0

From adrian.hunter at intel.com  Thu Apr  8 10:38:00 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Thu, 8 Apr 2021 12:38:00 +0300
Subject: [PATCH v16 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <7be92c0bc3e5f07d5e17bd3b78c01496686ef31e.1617818557.git.asutoshd@codeaurora.org>
References: <cover.1617818557.git.asutoshd@codeaurora.org>
 <7be92c0bc3e5f07d5e17bd3b78c01496686ef31e.1617818557.git.asutoshd@codeaurora.org>
Message-ID: <d30c2dc2-6334-1515-b548-a898939ec9ee@intel.com>

On 7/04/21 9:08 pm, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes.
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

<SNIP>

> +#ifdef CONFIG_PM_SLEEP
> +static int ufshcd_wl_poweroff(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);

Should be:

	struct scsi_device *sdev = to_scsi_device(dev);
	struct ufs_hba *hba = shost_priv(sdev->host);

> +
> +	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
> +	return 0;
> +}
> +#endif


From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:12 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:12 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>

A dedicated wakeup irq will be used to handle runtime suspend/resume,
we use dev_pm_set_dedicated_wake_irq API to take care of requesting
and attaching wakeup irq, then the suspend/resume framework will help
to enable/disable wakeup irq.

The runtime PM is default off since some platforms may not support it.
users can enable it via power/control (set "auto") in sysfs.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
 1 file changed, 124 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index a74764ab914a..30927f4064d4 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -16,6 +16,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
+#include <linux/pm_wakeirq.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
 			mtk->uwk_reg_base, mtk->uwk_vers);
 
 	return PTR_ERR_OR_ZERO(mtk->uwk);
-
 }
 
 static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
@@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct usb_hcd *hcd;
 	int ret = -ENODEV;
+	int wakeup_irq;
 	int irq;
 
 	if (usb_disabled())
@@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	irq = platform_get_irq_byname_optional(pdev, "host");
+	if (irq < 0) {
+		if (irq == -EPROBE_DEFER)
+			return irq;
+
+		/* for backward compatibility */
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return irq;
+	}
+
+	wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
+	if (wakeup_irq == -EPROBE_DEFER)
+		return wakeup_irq;
+
 	mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
 	/* optional property, ignore the error if it does not exist */
 	of_property_read_u32(node, "mediatek,u3p-dis-msk",
@@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	pm_runtime_set_active(dev);
+	pm_runtime_use_autosuspend(dev);
+	pm_runtime_set_autosuspend_delay(dev, 4000);
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
-	device_enable_async_suspend(dev);
 
 	ret = xhci_mtk_ldos_enable(mtk);
 	if (ret)
@@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_ldos;
 
-	irq = platform_get_irq(pdev, 0);
-	if (irq < 0) {
-		ret = irq;
-		goto disable_clk;
-	}
-
 	hcd = usb_create_hcd(driver, dev, dev_name(dev));
 	if (!hcd) {
 		ret = -ENOMEM;
@@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto dealloc_usb2_hcd;
 
+	if (wakeup_irq > 0) {
+		ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
+		if (ret) {
+			dev_err(dev, "set wakeup irq %d failed\n", wakeup_irq);
+			goto dealloc_usb3_hcd;
+		}
+		dev_info(dev, "wakeup irq %d\n", wakeup_irq);
+	}
+
+	device_enable_async_suspend(dev);
+	pm_runtime_mark_last_busy(dev);
+	pm_runtime_put_autosuspend(dev);
+	pm_runtime_forbid(dev);
+
 	return 0;
 
+dealloc_usb3_hcd:
+	usb_remove_hcd(xhci->shared_hcd);
+	xhci->shared_hcd = NULL;
+
 dealloc_usb2_hcd:
 	usb_remove_hcd(hcd);
 
@@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	xhci_mtk_ldos_disable(mtk);
 
 disable_pm:
-	pm_runtime_put_sync(dev);
+	pm_runtime_put_sync_autosuspend(dev);
 	pm_runtime_disable(dev);
 	return ret;
 }
 
-static int xhci_mtk_remove(struct platform_device *dev)
+static int xhci_mtk_remove(struct platform_device *pdev)
 {
-	struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
+	struct xhci_hcd_mtk *mtk = platform_get_drvdata(pdev);
 	struct usb_hcd	*hcd = mtk->hcd;
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
 	struct usb_hcd  *shared_hcd = xhci->shared_hcd;
+	struct device *dev = &pdev->dev;
 
-	pm_runtime_put_noidle(&dev->dev);
-	pm_runtime_disable(&dev->dev);
+	pm_runtime_get_sync(dev);
+	xhci->xhc_state |= XHCI_STATE_REMOVING;
+	dev_pm_clear_wake_irq(dev);
+	device_init_wakeup(dev, false);
 
 	usb_remove_hcd(shared_hcd);
 	xhci->shared_hcd = NULL;
-	device_init_wakeup(&dev->dev, false);
-
 	usb_remove_hcd(hcd);
 	usb_put_hcd(shared_hcd);
 	usb_put_hcd(hcd);
@@ -627,6 +658,10 @@ static int xhci_mtk_remove(struct platform_device *dev)
 	xhci_mtk_clks_disable(mtk);
 	xhci_mtk_ldos_disable(mtk);
 
+	pm_runtime_disable(dev);
+	pm_runtime_put_noidle(dev);
+	pm_runtime_set_suspended(dev);
+
 	return 0;
 }
 
@@ -690,10 +725,83 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	return ret;
 }
 
+static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
+{
+	u32 suspended_ports;
+	u32 status;
+	int num_ports;
+	int i;
+
+	num_ports = rhub->num_ports;
+	suspended_ports = rhub->bus_state.suspended_ports;
+	for (i = 0; i < num_ports; i++) {
+		if (!(suspended_ports & BIT(i))) {
+			status = readl(rhub->ports[i]->addr);
+			if (status & PORT_CONNECT)
+				return -EBUSY;
+		}
+	}
+
+	return 0;
+}
+
+/*
+ * check the bus whether it could suspend or not
+ * the bus will suspend if the downstream ports are already suspended,
+ * or no devices connected.
+ */
+static int check_bus_status(struct xhci_hcd *xhci)
+{
+	int ret;
+
+	ret = check_rhub_status(xhci, &xhci->usb3_rhub);
+	if (ret)
+		return ret;
+
+	return check_rhub_status(xhci, &xhci->usb2_rhub);
+}
+
+static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
+{
+	struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
+	struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+	int ret = 0;
+
+	if (xhci->xhc_state)
+		return -ESHUTDOWN;
+
+	if (device_may_wakeup(dev)) {
+		ret = check_bus_status(xhci);
+		if (!ret)
+			ret = xhci_mtk_suspend(dev);
+	}
+
+	/* -EBUSY: let PM automatically reschedule another autosuspend */
+	return ret ? -EBUSY : 0;
+}
+
+static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
+{
+	struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
+	struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+	int ret = 0;
+
+	if (xhci->xhc_state)
+		return -ESHUTDOWN;
+
+	if (device_may_wakeup(dev))
+		ret = xhci_mtk_resume(dev);
+
+	return ret;
+}
+
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
+	SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
+			   xhci_mtk_runtime_resume, NULL)
 };
-#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
+
+#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
 
 static const struct of_device_id mtk_xhci_of_match[] = {
 	{ .compatible = "mediatek,mt8173-xhci"},
-- 
2.18.0

From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:13 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:13 +0800
Subject: [PATCH 5/6] usb: xhci-mtk: use clock bulk to get clocks
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617874514-12282-5-git-send-email-chunfeng.yun@mediatek.com>

Use clock bulk helpers to get/enable/disable clocks, meanwhile
make sys_ck optional, then will be easier to handle clocks.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 109 +++++++-----------------------------
 drivers/usb/host/xhci-mtk.h |  10 ++--
 2 files changed, 24 insertions(+), 95 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 30927f4064d4..d4c455eecb8d 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -7,7 +7,6 @@
  *  Chunfeng Yun <chunfeng.yun at mediatek.com>
  */
 
-#include <linux/clk.h>
 #include <linux/dma-mapping.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
@@ -220,89 +219,6 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
 	return xhci_mtk_host_enable(mtk);
 }
 
-static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
-{
-	struct device *dev = mtk->dev;
-
-	mtk->sys_clk = devm_clk_get(dev, "sys_ck");
-	if (IS_ERR(mtk->sys_clk)) {
-		dev_err(dev, "fail to get sys_ck\n");
-		return PTR_ERR(mtk->sys_clk);
-	}
-
-	mtk->xhci_clk = devm_clk_get_optional(dev, "xhci_ck");
-	if (IS_ERR(mtk->xhci_clk))
-		return PTR_ERR(mtk->xhci_clk);
-
-	mtk->ref_clk = devm_clk_get_optional(dev, "ref_ck");
-	if (IS_ERR(mtk->ref_clk))
-		return PTR_ERR(mtk->ref_clk);
-
-	mtk->mcu_clk = devm_clk_get_optional(dev, "mcu_ck");
-	if (IS_ERR(mtk->mcu_clk))
-		return PTR_ERR(mtk->mcu_clk);
-
-	mtk->dma_clk = devm_clk_get_optional(dev, "dma_ck");
-	return PTR_ERR_OR_ZERO(mtk->dma_clk);
-}
-
-static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
-{
-	int ret;
-
-	ret = clk_prepare_enable(mtk->ref_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable ref_clk\n");
-		goto ref_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->sys_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable sys_clk\n");
-		goto sys_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->xhci_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable xhci_clk\n");
-		goto xhci_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->mcu_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable mcu_clk\n");
-		goto mcu_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->dma_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable dma_clk\n");
-		goto dma_clk_err;
-	}
-
-	return 0;
-
-dma_clk_err:
-	clk_disable_unprepare(mtk->mcu_clk);
-mcu_clk_err:
-	clk_disable_unprepare(mtk->xhci_clk);
-xhci_clk_err:
-	clk_disable_unprepare(mtk->sys_clk);
-sys_clk_err:
-	clk_disable_unprepare(mtk->ref_clk);
-ref_clk_err:
-	return ret;
-}
-
-static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
-{
-	clk_disable_unprepare(mtk->dma_clk);
-	clk_disable_unprepare(mtk->mcu_clk);
-	clk_disable_unprepare(mtk->xhci_clk);
-	clk_disable_unprepare(mtk->sys_clk);
-	clk_disable_unprepare(mtk->ref_clk);
-}
-
 /* only clocks can be turn off for ip-sleep wakeup mode */
 static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk *mtk, bool enable)
 {
@@ -367,6 +283,19 @@ static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
 		usb_wakeup_ip_sleep_set(mtk, enable);
 }
 
+static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
+{
+	struct clk_bulk_data *clks = mtk->clks;
+
+	clks[0].id = "sys_ck";
+	clks[1].id = "xhci_ck";
+	clks[2].id = "ref_ck";
+	clks[3].id = "mcu_ck";
+	clks[4].id = "dma_ck";
+
+	return devm_clk_bulk_get_optional(mtk->dev, BULK_CLKS_NUM, clks);
+}
+
 static int xhci_mtk_ldos_enable(struct xhci_hcd_mtk *mtk)
 {
 	int ret;
@@ -522,7 +451,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_pm;
 
-	ret = xhci_mtk_clks_enable(mtk);
+	ret = clk_bulk_prepare_enable(BULK_CLKS_NUM, mtk->clks);
 	if (ret)
 		goto disable_ldos;
 
@@ -625,7 +554,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	usb_put_hcd(hcd);
 
 disable_clk:
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 
 disable_ldos:
 	xhci_mtk_ldos_disable(mtk);
@@ -655,7 +584,7 @@ static int xhci_mtk_remove(struct platform_device *pdev)
 	usb_put_hcd(shared_hcd);
 	usb_put_hcd(hcd);
 	xhci_mtk_sch_exit(mtk);
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 	xhci_mtk_ldos_disable(mtk);
 
 	pm_runtime_disable(dev);
@@ -682,7 +611,7 @@ static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 	if (ret)
 		goto restart_poll_rh;
 
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 	usb_wakeup_set(mtk, true);
 	return 0;
 
@@ -703,7 +632,7 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	int ret;
 
 	usb_wakeup_set(mtk, false);
-	ret = xhci_mtk_clks_enable(mtk);
+	ret = clk_bulk_prepare_enable(BULK_CLKS_NUM, mtk->clks);
 	if (ret)
 		goto enable_wakeup;
 
@@ -719,7 +648,7 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	return 0;
 
 disable_clks:
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 enable_wakeup:
 	usb_wakeup_set(mtk, true);
 	return ret;
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 621ec1a85009..11996edc1967 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -9,8 +9,12 @@
 #ifndef _XHCI_MTK_H_
 #define _XHCI_MTK_H_
 
+#include <linux/clk.h>
+
 #include "xhci.h"
 
+#define BULK_CLKS_NUM	5
+
 /**
  * To simplify scheduler algorithm, set a upper limit for ESIT,
  * if a synchromous ep's ESIT is larger than @XHCI_MTK_MAX_ESIT,
@@ -140,11 +144,7 @@ struct xhci_hcd_mtk {
 	int u3p_dis_msk;
 	struct regulator *vusb33;
 	struct regulator *vbus;
-	struct clk *sys_clk;	/* sys and mac clock */
-	struct clk *xhci_clk;
-	struct clk *ref_clk;
-	struct clk *mcu_clk;
-	struct clk *dma_clk;
+	struct clk_bulk_data clks[BULK_CLKS_NUM];
 	struct regmap *pericfg;
 	struct phy **phys;
 	int num_phys;
-- 
2.18.0

From chunfeng.yun at mediatek.com  Thu Apr  8 10:35:14 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:35:14 +0800
Subject: [PATCH 6/6] usb: xhci-mtk: remove unused members
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617874514-12282-6-git-send-email-chunfeng.yun@mediatek.com>

Now some members about phys and wakeup are not used anymore,
remove them.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 11996edc1967..7940593a3445 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -145,9 +145,6 @@ struct xhci_hcd_mtk {
 	struct regulator *vusb33;
 	struct regulator *vbus;
 	struct clk_bulk_data clks[BULK_CLKS_NUM];
-	struct regmap *pericfg;
-	struct phy **phys;
-	int num_phys;
 	bool lpm_support;
 	/* usb remote wakeup */
 	bool uwk_en;
-- 
2.18.0

From gongruiqi1 at huawei.com  Thu Apr  8 11:03:29 2021
From: gongruiqi1 at huawei.com (Ruiqi Gong)
Date: Thu, 8 Apr 2021 06:03:29 -0400
Subject: [PATCH -next] thermal: bcm2835: remove redundant dev_err call in
 bcm2835_thermal_probe()
Message-ID: <20210408100329.7585-1-gongruiqi1@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ruiqi Gong <gongruiqi1 at huawei.com>
---
 drivers/thermal/broadcom/bcm2835_thermal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c b/drivers/thermal/broadcom/bcm2835_thermal.c
index 3199977f1e73..c8e4344d5a3d 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -184,7 +184,6 @@ static int bcm2835_thermal_probe(struct platform_device *pdev)
 	data->regs = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(data->regs)) {
 		err = PTR_ERR(data->regs);
-		dev_err(&pdev->dev, "Could not get registers: %d\n", err);
 		return err;
 	}
 



From chunfeng.yun at mediatek.com  Thu Apr  8 10:51:35 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Thu, 8 Apr 2021 17:51:35 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1617875495.12105.10.camel@mhfsdcap03>

Hi Ikjoon,

On Thu, 2021-04-08 at 17:35 +0800, Chunfeng Yun wrote:
> A dedicated wakeup irq will be used to handle runtime suspend/resume,
> we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> and attaching wakeup irq, then the suspend/resume framework will help
> to enable/disable wakeup irq.
> 
> The runtime PM is default off since some platforms may not support it.
> users can enable it via power/control (set "auto") in sysfs.
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
>  1 file changed, 124 insertions(+), 16 deletions(-)

Please help to test the series on mt8192 chromebook, thanks a lot


From xuwei5 at hisilicon.com  Thu Apr  8 10:52:47 2021
From: xuwei5 at hisilicon.com (Wei Xu)
Date: Thu, 8 Apr 2021 17:52:47 +0800
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v5.13
In-Reply-To: <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>
References: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>
 <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>
Message-ID: <606ED26F.4080009@hisilicon.com>

Hi Arnd,

On 2021/4/7 22:31, Arnd Bergmann wrote:
> On Sat, Apr 3, 2021 at 5:06 PM Wei Xu <xuwei5 at hisilicon.com> wrote:
>>
>> Hi ARM-SoC team,
>>
>> Please consider to pull the following changes.
>> Thanks!
> 
> I'd prefer to not break compatibility of old kernels with new dts files
> here, as this would prevent installing an old distro with an ebbr
> compliant boot loader, for purely cosmetic reasons.  These are used
> in the popular 'hikey' boards, which are used in many scenarios,
> which makes it fairly likely that someone might want to install
> something other than the very latest kernel.
> 
> Could you instead keep both the old and the new property in there
> for at least a few years?

Got it and it does make sense.
I will sync with Zhen Lei to see whether he want to do the change or not. 
And then I will send out the new pull request.
Thanks!

Best Regards,
Wei

> 
>         Arnd
> .
> 


From thunder.leizhen at huawei.com  Thu Apr  8 10:53:36 2021
From: thunder.leizhen at huawei.com (Leizhen (ThunderTown))
Date: Thu, 8 Apr 2021 17:53:36 +0800
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v5.13
In-Reply-To: <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>
References: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>
 <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>
Message-ID: <028b2fd0-854f-a683-22be-36f3af5b5784@huawei.com>



On 2021/4/7 22:31, Arnd Bergmann wrote:
> On Sat, Apr 3, 2021 at 5:06 PM Wei Xu <xuwei5 at hisilicon.com> wrote:
>>
>> Hi ARM-SoC team,
>>
>> Please consider to pull the following changes.
>> Thanks!
> 
> I'd prefer to not break compatibility of old kernels with new dts files
> here, as this would prevent installing an old distro with an ebbr
> compliant boot loader, for purely cosmetic reasons.  These are used

However, it seems unlikely that users only upgrade dts without upgrading the driver.

> in the popular 'hikey' boards, which are used in many scenarios,
> which makes it fairly likely that someone might want to install
> something other than the very latest kernel.
> 
> Could you instead keep both the old and the new property in there
> for at least a few years?
> 
>         Arnd
> 
> .
> 



From rppt at kernel.org  Thu Apr  8 10:56:02 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 12:56:02 +0300
Subject: [PATCH v1 1/2] drivers/video/fbdev: don't select DMA_CMA
In-Reply-To: <20210408092011.52763-2-david@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-2-david@redhat.com>
Message-ID: <YG7TMt0cgGucCPUX@kernel.org>

On Thu, Apr 08, 2021 at 11:20:10AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
> 
> "This is similar to "select" as it enforces a lower limit on another
>  symbol except that the "implied" symbol's value may still be set to n
>  from a direct dependency or with a visible prompt."
> 
> Implying DRM_CMA should be sufficient, as that depends on CMA.

	  ^ DMA_CMA ?

> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> instead -  but I assume the driver can work without CMA just fine --
> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS or CMA right now.
> 
> Signed-off-by: David Hildenbrand <david at redhat.com>
> ---
>  drivers/video/fbdev/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 4f02db65dede..d37cd5341e1b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2186,7 +2186,7 @@ config FB_HYPERV
>  	select FB_CFB_COPYAREA
>  	select FB_CFB_IMAGEBLIT
>  	select FB_DEFERRED_IO
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> +	imply DMA_CMA
>  	help
>  	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
>  
> -- 
> 2.30.2
> 

-- 
Sincerely yours,
Mike.


From rppt at kernel.org  Thu Apr  8 10:56:53 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 12:56:53 +0300
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <20210408092011.52763-3-david@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
Message-ID: <YG7TZa8VP458QS5y@kernel.org>

On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
> 
> "This is similar to "select" as it enforces a lower limit on another
>  symbol except that the "implied" symbol's value may still be set to n
>  from a direct dependency or with a visible prompt."
> 
> Implying DRM_CMA should be sufficient, as that depends on CMA.

          ^ DMA_CMA
> 
> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> instead -  but I assume the driver can work without CMA just fine --
> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> 
> Signed-off-by: David Hildenbrand <david at redhat.com>
> ---
>  drivers/gpu/drm/aspeed/Kconfig  | 3 +--
>  drivers/gpu/drm/etnaviv/Kconfig | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
> index 5e95bcea43e9..a055f763d230 100644
> --- a/drivers/gpu/drm/aspeed/Kconfig
> +++ b/drivers/gpu/drm/aspeed/Kconfig
> @@ -6,9 +6,8 @@ config DRM_ASPEED_GFX
>  	depends on MMU
>  	select DRM_KMS_HELPER
>  	select DRM_KMS_CMA_HELPER
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS
> -	select CMA if HAVE_DMA_CONTIGUOUS
>  	select MFD_SYSCON
> +	imply DRM_CMA

Ditto

>  	help
>  	  Chose this option if you have an ASPEED AST2500 SOC Display
>  	  Controller (aka GFX).
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index faa7fc68b009..5f5576b7221a 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -9,9 +9,8 @@ config DRM_ETNAVIV
>  	select THERMAL if DRM_ETNAVIV_THERMAL
>  	select TMPFS
>  	select WANT_DEV_COREDUMP
> -	select CMA if HAVE_DMA_CONTIGUOUS
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS
>  	select DRM_SCHED
> +	imply DMA_CMA
>  	help
>  	  DRM driver for Vivante GPUs.
>  
> -- 
> 2.30.2
> 

-- 
Sincerely yours,
Mike.


From Ludovic.Desroches at microchip.com  Thu Apr  8 10:56:59 2021
From: Ludovic.Desroches at microchip.com (Ludovic.Desroches at microchip.com)
Date: Thu, 8 Apr 2021 09:56:59 +0000
Subject: [PATCH v2 -next] dmaengine: at_xdmac: Remove unused inline
 function at_xdmac_csize()
In-Reply-To: <20210407132543.23652-1-yuehaibing@huawei.com>
References: <20210407132543.23652-1-yuehaibing@huawei.com>
Message-ID: <20210408095658.ev5pziemtwtx4op2@sekiro>

On Wed, Apr 07, 2021 at 09:25:43PM +0800, YueHaibing wrote:
> 
> commit 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
> left behind this, so can remove it.
> 
> Signed-off-by: YueHaibing <yuehaibing at huawei.com>
> Reviewed-by: Tudor Ambarus <tudor.ambarus at microchip.com>

Acked-by: Ludovic Desroches <ludovic.desroches at microchip.com>

Thanks for the cleanup.

Regards,
Ludovic

> ---
> v2: Fix commit log
> ---
>  drivers/dma/at_xdmac.c | 11 -----------
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index fe45ad5d06c4..64a52bf4d737 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -344,17 +344,6 @@ static inline int at_xdmac_chan_is_paused(struct at_xdmac_chan *atchan)
>         return test_bit(AT_XDMAC_CHAN_IS_PAUSED, &atchan->status);
>  }
> 
> -static inline int at_xdmac_csize(u32 maxburst)
> -{
> -       int csize;
> -
> -       csize = ffs(maxburst) - 1;
> -       if (csize > 4)
> -               csize = -EINVAL;
> -
> -       return csize;
> -};
> -
>  static inline bool at_xdmac_chan_is_peripheral_xfer(u32 cfg)
>  {
>         return cfg & AT_XDMAC_CC_TYPE_PER_TRAN;
> --
> 2.17.1
> 

From david at redhat.com  Thu Apr  8 10:57:31 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 11:57:31 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <YG7TZa8VP458QS5y@kernel.org>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com> <YG7TZa8VP458QS5y@kernel.org>
Message-ID: <9826d7ef-7f7e-987e-c305-7ae3c533d591@redhat.com>

On 08.04.21 11:56, Mike Rapoport wrote:
> On Thu, Apr 08, 2021 at 11:20:11AM +0200, David Hildenbrand wrote:
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>> dependencies and manual overrides.
>>
>> "This is similar to "select" as it enforces a lower limit on another
>>   symbol except that the "implied" symbol's value may still be set to n
>>   from a direct dependency or with a visible prompt."
>>
>> Implying DRM_CMA should be sufficient, as that depends on CMA.
> 
>            ^ DMA_CMA
>>
>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>> instead -  but I assume the driver can work without CMA just fine --
>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> Signed-off-by: David Hildenbrand <david at redhat.com>
>> ---
>>   drivers/gpu/drm/aspeed/Kconfig  | 3 +--
>>   drivers/gpu/drm/etnaviv/Kconfig | 3 +--
>>   2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
>> index 5e95bcea43e9..a055f763d230 100644
>> --- a/drivers/gpu/drm/aspeed/Kconfig
>> +++ b/drivers/gpu/drm/aspeed/Kconfig
>> @@ -6,9 +6,8 @@ config DRM_ASPEED_GFX
>>   	depends on MMU
>>   	select DRM_KMS_HELPER
>>   	select DRM_KMS_CMA_HELPER
>> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS
>> -	select CMA if HAVE_DMA_CONTIGUOUS
>>   	select MFD_SYSCON
>> +	imply DRM_CMA
> 
> Ditto

Gah, thanks!


-- 
Thanks,

David / dhildenb



From daniel at ffwll.ch  Thu Apr  8 11:05:13 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 8 Apr 2021 12:05:13 +0200
Subject: [PATCH 3/3] mm: unexport follow_pfn
In-Reply-To: <20210329133101.GA1168973@nvidia.com>
References: <20210316153303.3216674-1-daniel.vetter@ffwll.ch>
 <20210316153303.3216674-4-daniel.vetter@ffwll.ch>
 <20210329133101.GA1168973@nvidia.com>
Message-ID: <YG7VWWkvnv2IPEXt@phenom.ffwll.local>

On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > other ones have been switched over to unsafe_follow_pfn because they
> > cannot be fixed without breaking userspace api.
> > 
> > Argueably the vfio code is still racy, but that's kinda a bigger
> 
> vfio and kvm

Hm I thought kvm is non-racy due to the mmu notifier catch races?

> 
> > picture. But since it does leak the pte beyond where it drops the pt
> > lock, without anything else like an mmu notifier guaranteeing
> > coherence, the problem is at least clearly visible in the vfio code.
> > So good enough with me.
> > 
> > I've decided to keep the explanation that after dropping the pt lock
> > you must have an mmu notifier if you keep using the pte somehow by
> > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > function.
> > 
> > Cc: 3pvd at google.com
> > Cc: Jann Horn <jannh at google.com>
> > Cc: Paolo Bonzini <pbonzini at redhat.com>
> > Cc: Jason Gunthorpe <jgg at nvidia.com>
> > Cc: Cornelia Huck <cohuck at redhat.com>
> > Cc: Peter Xu <peterx at redhat.com>
> > Cc: Alex Williamson <alex.williamson at redhat.com>
> > Cc: linux-mm at kvack.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-samsung-soc at vger.kernel.org
> > Cc: linux-media at vger.kernel.org
> > Cc: kvm at vger.kernel.org
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > --- 
> >  include/linux/mm.h |  2 --
> >  mm/memory.c        | 26 +++++---------------------
> >  mm/nommu.c         | 13 +------------
> >  3 files changed, 6 insertions(+), 35 deletions(-)
> 
> Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>

Thanks for your r-b tags, I'll add them.
-Daniel

> 
> Jason

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From david at redhat.com  Thu Apr  8 11:05:21 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 12:05:21 +0200
Subject: [PATCH v2 0/2] drivers: don't select DMA_CMA or CMA
Message-ID: <20210408100523.63356-1-david@redhat.com>

Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
three drivers that select these options. Random drivers should not
override user settings of such core knobs. Let's use "imply DMA_CMA"
instead, such that user configuration and dependencies are respected.

v1 -> v2:
- Fix DRM_CMA -> DMA_CMA

Cc: Joel Stanley <joel at jms.id.au>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Andrew Jeffery <andrew at aj.id.au>
Cc: Lucas Stach <l.stach at pengutronix.de>
Cc: Russell King <linux+etnaviv at armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: Masahiro Yamada <masahiroy at kernel.org>
Cc: Randy Dunlap <rdunlap at infradead.org>
Cc: Peter Collingbourne <pcc at google.com>
Cc: linux-aspeed at lists.ozlabs.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: etnaviv at lists.freedesktop.org
Cc: linux-fbdev at vger.kernel.org

David Hildenbrand (2):
  drivers/video/fbdev: don't select DMA_CMA
  drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv

 drivers/gpu/drm/aspeed/Kconfig  | 3 +--
 drivers/gpu/drm/etnaviv/Kconfig | 3 +--
 drivers/video/fbdev/Kconfig     | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

-- 
2.30.2



From david at redhat.com  Thu Apr  8 11:05:22 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 12:05:22 +0200
Subject: [PATCH v2 1/2] drivers/video/fbdev: don't select DMA_CMA
In-Reply-To: <20210408100523.63356-1-david@redhat.com>
References: <20210408100523.63356-1-david@redhat.com>
Message-ID: <20210408100523.63356-2-david@redhat.com>

Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.

"This is similar to "select" as it enforces a lower limit on another
 symbol except that the "implied" symbol's value may still be set to n
 from a direct dependency or with a visible prompt."

Implying DMA_CMA should be sufficient, as that depends on CMA.

Note: If this is a real dependency, we should use "depends on DMA_CMA"
instead -  but I assume the driver can work without CMA just fine --
esp. when we wouldn't have HAVE_DMA_CONTIGUOUS or CMA right now.

Signed-off-by: David Hildenbrand <david at redhat.com>
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4f02db65dede..d37cd5341e1b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2186,7 +2186,7 @@ config FB_HYPERV
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_DEFERRED_IO
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
+	imply DMA_CMA
 	help
 	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
 
-- 
2.30.2



From david at redhat.com  Thu Apr  8 11:05:23 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu,  8 Apr 2021 12:05:23 +0200
Subject: [PATCH v2 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <20210408100523.63356-1-david@redhat.com>
References: <20210408100523.63356-1-david@redhat.com>
Message-ID: <20210408100523.63356-3-david@redhat.com>

Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
dependencies and manual overrides.

"This is similar to "select" as it enforces a lower limit on another
 symbol except that the "implied" symbol's value may still be set to n
 from a direct dependency or with a visible prompt."

Implying DMA_CMA should be sufficient, as that depends on CMA.

Note: If this is a real dependency, we should use "depends on DMA_CMA"
instead -  but I assume the driver can work without CMA just fine --
esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.

Signed-off-by: David Hildenbrand <david at redhat.com>
---
 drivers/gpu/drm/aspeed/Kconfig  | 3 +--
 drivers/gpu/drm/etnaviv/Kconfig | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
index 5e95bcea43e9..b35bb1aa9b91 100644
--- a/drivers/gpu/drm/aspeed/Kconfig
+++ b/drivers/gpu/drm/aspeed/Kconfig
@@ -6,9 +6,8 @@ config DRM_ASPEED_GFX
 	depends on MMU
 	select DRM_KMS_HELPER
 	select DRM_KMS_CMA_HELPER
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
-	select CMA if HAVE_DMA_CONTIGUOUS
 	select MFD_SYSCON
+	imply DMA_CMA
 	help
 	  Chose this option if you have an ASPEED AST2500 SOC Display
 	  Controller (aka GFX).
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index faa7fc68b009..5f5576b7221a 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -9,9 +9,8 @@ config DRM_ETNAVIV
 	select THERMAL if DRM_ETNAVIV_THERMAL
 	select TMPFS
 	select WANT_DEV_COREDUMP
-	select CMA if HAVE_DMA_CONTIGUOUS
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
 	select DRM_SCHED
+	imply DMA_CMA
 	help
 	  DRM driver for Vivante GPUs.
 
-- 
2.30.2



From arnd at arndb.de  Thu Apr  8 11:15:05 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 12:15:05 +0200
Subject: [GIT,PULL] arm64: dts: hisilicon dts updates for v5.13
In-Reply-To: <028b2fd0-854f-a683-22be-36f3af5b5784@huawei.com>
References: <744291cd-a66f-dedb-fe7a-752a9032d6cd@hisilicon.com>
 <CAK8P3a31XFD7smyK0R41uX9fw+P6zPDLEgJoXz99imYS8urENQ@mail.gmail.com>
 <028b2fd0-854f-a683-22be-36f3af5b5784@huawei.com>
Message-ID: <CAK8P3a0So6USwL0FYtzbFotJeBZw87p2kX86hHDyF+WFPvrD1Q@mail.gmail.com>

On Thu, Apr 8, 2021 at 11:53 AM Leizhen (ThunderTown)
<thunder.leizhen at huawei.com> wrote:
> On 2021/4/7 22:31, Arnd Bergmann wrote:
> > On Sat, Apr 3, 2021 at 5:06 PM Wei Xu <xuwei5 at hisilicon.com> wrote:
> >>
> >> Hi ARM-SoC team,
> >>
> >> Please consider to pull the following changes.
> >> Thanks!
> >
> > I'd prefer to not break compatibility of old kernels with new dts files
> > here, as this would prevent installing an old distro with an ebbr
> > compliant boot loader, for purely cosmetic reasons.  These are used
>
> However, it seems unlikely that users only upgrade dts without upgrading the driver.

The typical scenario is that you upgrade the OS by installing a new
kernel first, and then updating the DT. However, you might want to
still boot into an older kernel, e.g. for testing purposes when something
breaks, or to have multiple operating systems installed in parallel,
picking the rootfs through grub2.

           Arnd


From rppt at kernel.org  Thu Apr  8 11:16:59 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 8 Apr 2021 13:16:59 +0300
Subject: [PATCH v2 0/2] drivers: don't select DMA_CMA or CMA
In-Reply-To: <20210408100523.63356-1-david@redhat.com>
References: <20210408100523.63356-1-david@redhat.com>
Message-ID: <YG7YGxN83VxtKAeo@kernel.org>

On Thu, Apr 08, 2021 at 12:05:21PM +0200, David Hildenbrand wrote:
> Trying to set CONFIG_CMA=y with CONFIG_DMA_CMA=n revealed that we have
> three drivers that select these options. Random drivers should not
> override user settings of such core knobs. Let's use "imply DMA_CMA"
> instead, such that user configuration and dependencies are respected.
> 
> v1 -> v2:
> - Fix DRM_CMA -> DMA_CMA
> 
> Cc: Joel Stanley <joel at jms.id.au>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Andrew Jeffery <andrew at aj.id.au>
> Cc: Lucas Stach <l.stach at pengutronix.de>
> Cc: Russell King <linux+etnaviv at armlinux.org.uk>
> Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: Masahiro Yamada <masahiroy at kernel.org>
> Cc: Randy Dunlap <rdunlap at infradead.org>
> Cc: Peter Collingbourne <pcc at google.com>
> Cc: linux-aspeed at lists.ozlabs.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: etnaviv at lists.freedesktop.org
> Cc: linux-fbdev at vger.kernel.org
> 
> David Hildenbrand (2):
>   drivers/video/fbdev: don't select DMA_CMA
>   drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
> 
>  drivers/gpu/drm/aspeed/Kconfig  | 3 +--
>  drivers/gpu/drm/etnaviv/Kconfig | 3 +--
>  drivers/video/fbdev/Kconfig     | 2 +-
>  3 files changed, 3 insertions(+), 5 deletions(-)

Acked-by: Mike Rapoport <rppt at linux.ibm.com>

> -- 
> 2.30.2
> 

-- 
Sincerely yours,
Mike.


From arnd at arndb.de  Thu Apr  8 11:20:50 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 12:20:50 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <20210408092011.52763-3-david@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
Message-ID: <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>

On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david at redhat.com> wrote:
>
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> dependencies and manual overrides.
>
> "This is similar to "select" as it enforces a lower limit on another
>  symbol except that the "implied" symbol's value may still be set to n
>  from a direct dependency or with a visible prompt."
>
> Implying DRM_CMA should be sufficient, as that depends on CMA.
>
> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> instead -  but I assume the driver can work without CMA just fine --
> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.

'imply' is almost never the right solution, and it tends to cause more
problems than it solves.

In particular, it does not prevent a configuration with 'DRM_CMA=m'
and 'DRMA_ASPEED_GFX=y', or any build failures from such
a configuration.

If you want this kind of soft dependency, you need
'depends on DRM_CMA || !DRM_CMA'.

         Arnd


From maz at kernel.org  Thu Apr  8 11:24:05 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 11:24:05 +0100
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <20210408040537.2703241-4-pasha.tatashin@soleen.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
Message-ID: <480272f8fb3e46d24a0ee1418fb85809@kernel.org>

On 2021-04-08 05:05, Pavel Tatashin wrote:
> From: James Morse <james.morse at arm.com>
> 
> The hyp-stub's el1_sync code doesn't do very much, this can easily fit
> in the vectors.
> 
> With this, all of the hyp-stubs behaviour is contained in its vectors.
> This lets kexec and hibernate copy the hyp-stub when they need its
> behaviour, instead of re-implementing it.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> 
> [Fixed merging issues]

That's a pretty odd fix IMO.

> 
> Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
> ---
>  arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------
>  1 file changed, 29 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm64/kernel/hyp-stub.S 
> b/arch/arm64/kernel/hyp-stub.S
> index ff329c5c074d..d1a73d0f74e0 100644
> --- a/arch/arm64/kernel/hyp-stub.S
> +++ b/arch/arm64/kernel/hyp-stub.S
> @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label)
>  	.align 7
>  	b	\label
>  SYM_CODE_END(\label)
> +.endm
> +
> +.macro hyp_stub_el1_sync
> +SYM_CODE_START_LOCAL(hyp_stub_el1_sync)
> +	.align 7
> +	cmp	x0, #HVC_SET_VECTORS
> +	b.ne	2f
> +	msr	vbar_el2, x1
> +	b	9f
> +
> +2:	cmp	x0, #HVC_SOFT_RESTART
> +	b.ne	3f
> +	mov	x0, x2
> +	mov	x2, x4
> +	mov	x4, x1
> +	mov	x1, x3
> +	br	x4				// no return
> +
> +3:	cmp	x0, #HVC_RESET_VECTORS
> +	beq	9f				// Nothing to reset!
> +
> +	/* Someone called kvm_call_hyp() against the hyp-stub... */
> +	mov_q	x0, HVC_STUB_ERR
> +	eret
> +
> +9:	mov	x0, xzr
> +	eret
> +SYM_CODE_END(hyp_stub_el1_sync)

You said you tested this on a TX2. I guess you don't care whether
it runs VHE or not...

         M.

>  .endm
> 
>  	.text
> @@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors)
>  	invalid_vector	hyp_stub_el2h_fiq_invalid	// FIQ EL2h
>  	invalid_vector	hyp_stub_el2h_error_invalid	// Error EL2h
> 
> -	ventry	el1_sync			// Synchronous 64-bit EL1
> +	hyp_stub_el1_sync				// Synchronous 64-bit EL1
>  	invalid_vector	hyp_stub_el1_irq_invalid	// IRQ 64-bit EL1
>  	invalid_vector	hyp_stub_el1_fiq_invalid	// FIQ 64-bit EL1
>  	invalid_vector	hyp_stub_el1_error_invalid	// Error 64-bit EL1
> @@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors)
>  # Check the __hyp_stub_vectors didn't overflow
>  .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K
> 
> -
> -SYM_CODE_START_LOCAL(el1_sync)
> -	cmp	x0, #HVC_SET_VECTORS
> -	b.ne	1f
> -	msr	vbar_el2, x1
> -	b	9f
> -
> -1:	cmp	x0, #HVC_VHE_RESTART
> -	b.eq	mutate_to_vhe
> -
> -2:	cmp	x0, #HVC_SOFT_RESTART
> -	b.ne	3f
> -	mov	x0, x2
> -	mov	x2, x4
> -	mov	x4, x1
> -	mov	x1, x3
> -	br	x4				// no return
> -
> -3:	cmp	x0, #HVC_RESET_VECTORS
> -	beq	9f				// Nothing to reset!
> -
> -	/* Someone called kvm_call_hyp() against the hyp-stub... */
> -	mov_q	x0, HVC_STUB_ERR
> -	eret
> -
> -9:	mov	x0, xzr
> -	eret
> -SYM_CODE_END(el1_sync)
> -
>  // nVHE? No way! Give me the real thing!
>  SYM_CODE_START_LOCAL(mutate_to_vhe)
>  	// Sanity check: MMU *must* be off

-- 
Jazz is not dead. It just smells funny...


From Eugen.Hristev at microchip.com  Thu Apr  8 11:24:24 2021
From: Eugen.Hristev at microchip.com (Eugen.Hristev at microchip.com)
Date: Thu, 8 Apr 2021 10:24:24 +0000
Subject: [PATCH 3/3] ARM: at91: Kconfig: select PLL, generic clock and
 utmi support
In-Reply-To: <YG3oM6DhTwKfPrAG@piout.net>
References: <20210407170053.298056-1-eugen.hristev@microchip.com>
 <20210407170053.298056-3-eugen.hristev@microchip.com>
 <YG3oM6DhTwKfPrAG@piout.net>
Message-ID: <7efa1037-eef4-0b34-1ad3-7ee0c61afadf@microchip.com>

On 4/7/21 8:13 PM, Alexandre Belloni wrote:
> Hi,
> 
> On 07/04/2021 20:00:53+0300, Eugen Hristev wrote:
>> From: Claudiu Beznea <claudiu.beznea at microchip.com>
>>
>> Select PLL, generic clock and UTMI support for SAMA7G5.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>> ---
>>   arch/arm/mach-at91/Kconfig | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
>> index 5eb2a9206f42..f52b46bccd85 100644
>> --- a/arch/arm/mach-at91/Kconfig
>> +++ b/arch/arm/mach-at91/Kconfig
>> @@ -60,6 +60,9 @@ config SOC_SAMA5D4
>>   config SOC_SAMA7G5
>>        bool "SAMA7G5 family"
>>        depends on ARCH_MULTI_V7
>> +     select HAVE_AT91_GENERATED_CLK
>> +     select HAVE_AT91_SAM9X60_PLL
>> +     select HAVE_AT91_UTMI
> 
> Shouldn't that be squashed in 1/3?

I kept the original contributions of each author. I can squash it into a 
single patch if it's cleaner.

Eugen
> 
>>        select SOC_SAMA7
>>        help
>>          Select this if you are using one of Microchip's SAMA7G5 family SoC.
>> --
>> 2.25.1
>>
> 
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 


From david at redhat.com  Thu Apr  8 11:27:02 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 12:27:02 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
Message-ID: <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>

On 08.04.21 12:20, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david at redhat.com> wrote:
>>
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>> dependencies and manual overrides.
>>
>> "This is similar to "select" as it enforces a lower limit on another
>>   symbol except that the "implied" symbol's value may still be set to n
>>   from a direct dependency or with a visible prompt."
>>
>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>
>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>> instead -  but I assume the driver can work without CMA just fine --
>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> 
> 'imply' is almost never the right solution, and it tends to cause more
> problems than it solves.

I thought that was the case with "select" :)

> 
> In particular, it does not prevent a configuration with 'DRM_CMA=m'

I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.

> and 'DRMA_ASPEED_GFX=y', or any build failures from such
> a configuration.

I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work 
just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?

> 
> If you want this kind of soft dependency, you need
> 'depends on DRM_CMA || !DRM_CMA'.

Seriously? I think the point of imply is "please enable if possible and 
not prevented by someone else". Your example looks more like a NOP - no? 
Or will it have the same effect?


-- 
Thanks,

David / dhildenb



From maz at kernel.org  Thu Apr  8 11:31:42 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 11:31:42 +0100
Subject: [PATCH v2 3/3] arm64: Allow nVHE impaired CPUs to boot without
 CONFIG_ARM64_VHE
In-Reply-To: <20210407211848.GE16198@willie-the-truck>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-4-maz@kernel.org>
 <20210407211848.GE16198@willie-the-truck>
Message-ID: <8474e539259346842178f51a26d59d74@kernel.org>

On 2021-04-07 22:18, Will Deacon wrote:
> On Tue, Mar 30, 2021 at 06:39:47PM +0100, Marc Zyngier wrote:
>> CPUs stuck in VHE mode need some additional care if the kernel
>> is compiled without CONFIG_ARM64_VHE.
>> 
>> Treat this case as another version of a mismatched boot, and
>> prevent KVM from being initialised. The machine will boot in
>> some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but
>> otherwise be functional.
>> 
>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>> ---
>>  arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
>>  arch/arm64/kvm/va_layout.c    |  9 +++++++++
>>  2 files changed, 22 insertions(+), 5 deletions(-)
> 
> Hmm, I think we definitely need _something_ here, but it's a bit 
> annoying
> to put ourselves into this weird state just for the sake of one stupid
> machine.

Which is why I'm not keen at all on this patch, and I'm happy to see
the machine die a painful death. We really can't be blamed for 
terminally
buggy HW, which the M1 obviously is.

> What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional
> instead? Is there a good reason to allow it to be disabled nowadays?

What do we do for the other camp, aka people really wanting to run nVHE
without any command line parameter? I can't see why you'd want to do
that, but hey, that's only me.

I'd be quite happy to see CONFIG_ARM64_VHE go though. Let me know if you
want a patch doing that instead.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...


From xiaoning.wang at nxp.com  Thu Apr  8 11:33:46 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Thu,  8 Apr 2021 18:33:46 +0800
Subject: [PATCH] spi: imx: add 16/32 bits per word support for slave mode
Message-ID: <20210408103347.244313-1-xiaoning.wang@nxp.com>

Enable 16/32 bits per word support for spi-imx slave mode.
It only support 8 bits per word in slave mode before.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
Reviewed-by: Haibo Chen <haibo.chen at nxp.com>
---
 drivers/spi/spi-imx.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 4fe767acaca7..24ba7ab1b05d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -386,7 +386,12 @@ static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
 
 static void mx53_ecspi_rx_slave(struct spi_imx_data *spi_imx)
 {
-	u32 val = be32_to_cpu(readl(spi_imx->base + MXC_CSPIRXDATA));
+	u32 val = readl(spi_imx->base + MXC_CSPIRXDATA);
+
+	if (spi_imx->bits_per_word <= 8)
+		val = be32_to_cpu(val);
+	else if (spi_imx->bits_per_word <= 16)
+		val = (val << 16) | (val >> 16);
 
 	if (spi_imx->rx_buf) {
 		int n_bytes = spi_imx->slave_burst % sizeof(val);
@@ -415,7 +420,11 @@ static void mx53_ecspi_tx_slave(struct spi_imx_data *spi_imx)
 	if (spi_imx->tx_buf) {
 		memcpy(((u8 *)&val) + sizeof(val) - n_bytes,
 		       spi_imx->tx_buf, n_bytes);
-		val = cpu_to_be32(val);
+		if (spi_imx->bits_per_word <= 8)
+			val = cpu_to_be32(val);
+		else if (spi_imx->bits_per_word <= 16)
+			val = (val << 16) | (val >> 16);
+
 		spi_imx->tx_buf += n_bytes;
 	}
 
-- 
2.25.1



From xiaoning.wang at nxp.com  Thu Apr  8 11:33:47 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Thu,  8 Apr 2021 18:33:47 +0800
Subject: [PATCH] spi: imx: add a check for speed_hz before calculating the
 clock
In-Reply-To: <20210408103347.244313-1-xiaoning.wang@nxp.com>
References: <20210408103347.244313-1-xiaoning.wang@nxp.com>
Message-ID: <20210408103347.244313-2-xiaoning.wang@nxp.com>

When some drivers use spi to send data, spi_transfer->speed_hz is
not assigned. If spidev->max_speed_hz is not assigned as well, it
will cause an error in configuring the clock.
Add a check for these two values before configuring the clock. An
error will be returned when they are not assigned.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
 drivers/spi/spi-imx.c | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 24ba7ab1b05d..01f27b4d7384 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -66,8 +66,7 @@ struct spi_imx_data;
 struct spi_imx_devtype_data {
 	void (*intctrl)(struct spi_imx_data *, int);
 	int (*prepare_message)(struct spi_imx_data *, struct spi_message *);
-	int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *,
-				struct spi_transfer *);
+	int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *);
 	void (*trigger)(struct spi_imx_data *);
 	int (*rx_available)(struct spi_imx_data *);
 	void (*reset)(struct spi_imx_data *);
@@ -581,11 +580,10 @@ static int mx51_ecspi_prepare_message(struct spi_imx_data *spi_imx,
 }
 
 static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
-				       struct spi_device *spi,
-				       struct spi_transfer *t)
+				       struct spi_device *spi)
 {
 	u32 ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
-	u32 clk = t->speed_hz, delay;
+	u32 clk, delay;
 
 	/* Clear BL field and set the right value */
 	ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
@@ -599,7 +597,7 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	/* set clock speed */
 	ctrl &= ~(0xf << MX51_ECSPI_CTRL_POSTDIV_OFFSET |
 		  0xf << MX51_ECSPI_CTRL_PREDIV_OFFSET);
-	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
+	ctrl |= mx51_ecspi_clkdiv(spi_imx, spi_imx->spi_bus_clk, &clk);
 	spi_imx->spi_bus_clk = clk;
 
 	if (spi_imx->usedma)
@@ -711,13 +709,12 @@ static int mx31_prepare_message(struct spi_imx_data *spi_imx,
 }
 
 static int mx31_prepare_transfer(struct spi_imx_data *spi_imx,
-				 struct spi_device *spi,
-				 struct spi_transfer *t)
+				 struct spi_device *spi)
 {
 	unsigned int reg = MX31_CSPICTRL_ENABLE | MX31_CSPICTRL_MASTER;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, spi_imx->spi_bus_clk, &clk) <<
 		MX31_CSPICTRL_DR_SHIFT;
 	spi_imx->spi_bus_clk = clk;
 
@@ -816,14 +813,13 @@ static int mx21_prepare_message(struct spi_imx_data *spi_imx,
 }
 
 static int mx21_prepare_transfer(struct spi_imx_data *spi_imx,
-				 struct spi_device *spi,
-				 struct spi_transfer *t)
+				 struct spi_device *spi)
 {
 	unsigned int reg = MX21_CSPICTRL_ENABLE | MX21_CSPICTRL_MASTER;
 	unsigned int max = is_imx27_cspi(spi_imx) ? 16 : 18;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, t->speed_hz, max, &clk)
+	reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, spi_imx->spi_bus_clk, max, &clk)
 		<< MX21_CSPICTRL_DR_SHIFT;
 	spi_imx->spi_bus_clk = clk;
 
@@ -892,13 +888,12 @@ static int mx1_prepare_message(struct spi_imx_data *spi_imx,
 }
 
 static int mx1_prepare_transfer(struct spi_imx_data *spi_imx,
-				struct spi_device *spi,
-				struct spi_transfer *t)
+				struct spi_device *spi)
 {
 	unsigned int reg = MX1_CSPICTRL_ENABLE | MX1_CSPICTRL_MASTER;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, spi_imx->spi_bus_clk, &clk) <<
 		MX1_CSPICTRL_DR_SHIFT;
 	spi_imx->spi_bus_clk = clk;
 
@@ -1177,6 +1172,16 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 	if (!t)
 		return 0;
 
+	if (!t->speed_hz) {
+		if (!spi->max_speed_hz) {
+			dev_err(&spi->dev, "no speed_hz provided!\n");
+			return -EINVAL;
+		}
+		dev_dbg(&spi->dev, "using spi->max_speed_hz!\n");
+		spi_imx->spi_bus_clk = spi->max_speed_hz;
+	} else
+		spi_imx->spi_bus_clk = t->speed_hz;
+
 	spi_imx->bits_per_word = t->bits_per_word;
 
 	/*
@@ -1218,7 +1223,7 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->slave_burst = t->len;
 	}
 
-	spi_imx->devtype_data->prepare_transfer(spi_imx, spi, t);
+	spi_imx->devtype_data->prepare_transfer(spi_imx, spi);
 
 	return 0;
 }
-- 
2.25.1



From michal.simek at xilinx.com  Thu Apr  8 11:33:47 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 8 Apr 2021 12:33:47 +0200
Subject: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
References: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
Message-ID: <17b5d33f-ce96-dc07-05f7-41d87f53a3d0@xilinx.com>

++

On 4/8/21 11:25 AM, Dinghao Liu wrote:
> When platform_get_irq() fails, a pairing PM usage counter
> increment is needed to keep the counter balanced. It's the
> same for the following error paths.
> 
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> ---
>  drivers/spi/spi-zynqmp-gqspi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> index c8fa6ee18ae7..95963a2de64a 100644
> --- a/drivers/spi/spi-zynqmp-gqspi.c
> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -1197,6 +1197,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>  	return 0;
>  
>  clk_dis_all:
> +	pm_runtime_get_noresume(&pdev->dev);
>  	pm_runtime_set_suspended(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
>  	clk_disable_unprepare(xqspi->refclk);
> 


From maz at kernel.org  Thu Apr  8 11:36:34 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 11:36:34 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <20210407203537.GA16011@willie-the-truck>
References: <20210406125841.1077079-1-maz@kernel.org>
 <20210407203537.GA16011@willie-the-truck>
Message-ID: <bbb4d999fe0bc9762c930dafa56a8847@kernel.org>

On 2021-04-07 21:35, Will Deacon wrote:
> On Tue, Apr 06, 2021 at 01:58:41PM +0100, Marc Zyngier wrote:
>> Although the KVM_ARM_VCPU_INIT documentation mention that the
>> registers are reset to their "initial values", it doesn't
>> describe what these values are.
>> 
>> Describe this state explicitly.
>> 
>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>> ---
>>  Documentation/virt/kvm/api.rst | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>> 
>> diff --git a/Documentation/virt/kvm/api.rst 
>> b/Documentation/virt/kvm/api.rst
>> index 38e327d4b479..e2237e4e10ba 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -3115,6 +3115,16 @@ optional features it should have. ?This will 
>> cause a reset of the cpu
>>  registers to their initial values. ?If this is not called, KVM_RUN 
>> will
>>  return ENOEXEC for that vcpu.
>> 
>> +The initial values are defined as:
>> +	- Processor state:
>> +		* AArch64: EL1h, D, A, I and F bits set
>> +		* Aarch32: SVC, D, A, I and F bits set
> 
> nit, but capitalisation should be "AArch32"
> 
> Is "SVC" sufficient, or do we also need to describe Arm vs Thumb?

SVC doesn't describe the instruction set, but we don't say that PSR.T
is set, which implies ARM.

I can add something like "All other bits are set to 0", if that makes it
clearer.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...


From david at redhat.com  Thu Apr  8 11:36:59 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 12:36:59 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
Message-ID: <0b1928a8-99c3-f1f1-ad66-40145199d9bc@redhat.com>

On 08.04.21 12:27, David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
>> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david at redhat.com> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>>> dependencies and manual overrides.
>>>
>>> "This is similar to "select" as it enforces a lower limit on another
>>>    symbol except that the "implied" symbol's value may still be set to n
>>>    from a direct dependency or with a visible prompt."
>>>
>>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>>
>>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>>> instead -  but I assume the driver can work without CMA just fine --
>>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> 'imply' is almost never the right solution, and it tends to cause more
>> problems than it solves.
> 
> I thought that was the case with "select" :)
> 
>>
>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
> 
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
> 
>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>> a configuration.
> 
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
> 
>>
>> If you want this kind of soft dependency, you need
>> 'depends on DRM_CMA || !DRM_CMA'.
> 
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else". Your example looks more like a NOP - no?
> Or will it have the same effect?

I just tried (remove CONFIG_DMA_CMA from .config followed by make) and 
the default will be set to "N" (when querying the user). So it indeed 
looks like a NOP - unless I am missing something.

-- 
Thanks,

David / dhildenb



From maz at kernel.org  Thu Apr  8 11:43:19 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 11:43:19 +0100
Subject: [PATCH] irqchip/wpcm450: Drop COMPILE_TEST
In-Reply-To: <YG7CwB0lMWJGylt7@latitude>
References: <20210408080030.2277572-1-maz@kernel.org>
 <YG7CwB0lMWJGylt7@latitude>
Message-ID: <0dd30fb16e1b9d9c7fe226cc102f8fac@kernel.org>

On 2021-04-08 09:45, Jonathan Neusch?fer wrote:
> On Thu, Apr 08, 2021 at 09:00:30AM +0100, Marc Zyngier wrote:
>> This driver is (for now) ARM specific, and currently doesn't
>> build with a variety of architectures (ia64, RISC-V, x86_64
>> at the very least).
>> 
>> Drop COMPILE_TEST from Kconfig until it gets sorted out.
>> 
>> Cc: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
>> Reported-by: Stephen Rothwell <sfr at canb.auug.org.au>
>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>> ---
> 
> Reviewed-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>

Thanks for that.

> 
>>  drivers/irqchip/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>> index 38ad9dcf42c3..715eb4366e35 100644
>> --- a/drivers/irqchip/Kconfig
>> +++ b/drivers/irqchip/Kconfig
>> @@ -579,7 +579,7 @@ config MST_IRQ
>> 
>>  config WPCM450_AIC
>>  	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
>> -	depends on ARCH_WPCM450 || COMPILE_TEST
>> +	depends on ARCH_WPCM450
> 
> I guess I could use (COMPILE_TEST && ARM) or something?

One of the major interest of COMPILE_TEST to be able to check code
cross-architecture. For code that cannot compile cross-architecture,
I'm not sure it matters much.

We can achieve the same result by enabling multi-platform builds (and
this system should probably end-up in multi_v5_defconfig).

         M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Thu Apr  8 11:44:46 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 12:44:46 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
Message-ID: <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>

On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand <david at redhat.com> wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david at redhat.com> wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> >> dependencies and manual overrides.
> >>
> >> "This is similar to "select" as it enforces a lower limit on another
> >>   symbol except that the "implied" symbol's value may still be set to n
> >>   from a direct dependency or with a visible prompt."
> >>
> >> Implying DRM_CMA should be sufficient, as that depends on CMA.
> >>
> >> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> >> instead -  but I assume the driver can work without CMA just fine --
> >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> >
> > 'imply' is almost never the right solution, and it tends to cause more
> > problems than it solves.
>
> I thought that was the case with "select" :)

Yes, but that's a different set of problems

> >
> > In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.

Ok, at least that makes it easier.

> > and 'DRMA_ASPEED_GFX=y', or any build failures from such
> > a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?

I thought you were trying to solve the problem where DRMA_ASPEED_GFX
can optionally link against CMA but would fail to build when the CMA code
is in a loadable module.

If the problem you are trying to solve is a different one, you need a different
solution, not what I posted above.

> > If you want this kind of soft dependency, you need
> > 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else".

That used to be the meaning, but it changed a few years ago. Now
it means "when a used manually turns on this symbol, turn on the
implied one as well, but let them turn it off again if they choose".

This is pretty much a NOP.

> Your example looks more like a NOP - no?
> Or will it have the same effect?

The example I gave is only meaningful if both are tristate, which is
not the case here as you explain.

It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".

      Arnd


From will at kernel.org  Thu Apr  8 11:53:35 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 11:53:35 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <bbb4d999fe0bc9762c930dafa56a8847@kernel.org>
References: <20210406125841.1077079-1-maz@kernel.org>
 <20210407203537.GA16011@willie-the-truck>
 <bbb4d999fe0bc9762c930dafa56a8847@kernel.org>
Message-ID: <20210408105334.GA17280@willie-the-truck>

On Thu, Apr 08, 2021 at 11:36:34AM +0100, Marc Zyngier wrote:
> On 2021-04-07 21:35, Will Deacon wrote:
> > On Tue, Apr 06, 2021 at 01:58:41PM +0100, Marc Zyngier wrote:
> > > Although the KVM_ARM_VCPU_INIT documentation mention that the
> > > registers are reset to their "initial values", it doesn't
> > > describe what these values are.
> > > 
> > > Describe this state explicitly.
> > > 
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > ---
> > >  Documentation/virt/kvm/api.rst | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/Documentation/virt/kvm/api.rst
> > > b/Documentation/virt/kvm/api.rst
> > > index 38e327d4b479..e2237e4e10ba 100644
> > > --- a/Documentation/virt/kvm/api.rst
> > > +++ b/Documentation/virt/kvm/api.rst
> > > @@ -3115,6 +3115,16 @@ optional features it should have. ?This will
> > > cause a reset of the cpu
> > >  registers to their initial values. ?If this is not called, KVM_RUN
> > > will
> > >  return ENOEXEC for that vcpu.
> > > 
> > > +The initial values are defined as:
> > > +	- Processor state:
> > > +		* AArch64: EL1h, D, A, I and F bits set
> > > +		* Aarch32: SVC, D, A, I and F bits set
> > 
> > nit, but capitalisation should be "AArch32"
> > 
> > Is "SVC" sufficient, or do we also need to describe Arm vs Thumb?
> 
> SVC doesn't describe the instruction set, but we don't say that PSR.T
> is set, which implies ARM.

Ah yes, thanks.

> I can add something like "All other bits are set to 0", if that makes it
> clearer.

I think that would be worth adding. With that and the minor typo fix:

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Thu Apr  8 11:58:23 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 11:58:23 +0100
Subject: [PATCH v2 3/3] arm64: Allow nVHE impaired CPUs to boot without
 CONFIG_ARM64_VHE
In-Reply-To: <8474e539259346842178f51a26d59d74@kernel.org>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-4-maz@kernel.org>
 <20210407211848.GE16198@willie-the-truck>
 <8474e539259346842178f51a26d59d74@kernel.org>
Message-ID: <20210408105823.GB17280@willie-the-truck>

On Thu, Apr 08, 2021 at 11:31:42AM +0100, Marc Zyngier wrote:
> On 2021-04-07 22:18, Will Deacon wrote:
> > On Tue, Mar 30, 2021 at 06:39:47PM +0100, Marc Zyngier wrote:
> > > CPUs stuck in VHE mode need some additional care if the kernel
> > > is compiled without CONFIG_ARM64_VHE.
> > > 
> > > Treat this case as another version of a mismatched boot, and
> > > prevent KVM from being initialised. The machine will boot in
> > > some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but
> > > otherwise be functional.
> > > 
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
> > >  arch/arm64/kvm/va_layout.c    |  9 +++++++++
> > >  2 files changed, 22 insertions(+), 5 deletions(-)
> > 
> > Hmm, I think we definitely need _something_ here, but it's a bit
> > annoying
> > to put ourselves into this weird state just for the sake of one stupid
> > machine.
> 
> Which is why I'm not keen at all on this patch, and I'm happy to see
> the machine die a painful death. We really can't be blamed for terminally
> buggy HW, which the M1 obviously is.

Perhaps, but it's not clear at all how the problem manifests and so we
_will_ be blamed when things go wonky, especially as the real culprits
all seem to be hiding...

> > What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional
> > instead? Is there a good reason to allow it to be disabled nowadays?
> 
> What do we do for the other camp, aka people really wanting to run nVHE
> without any command line parameter? I can't see why you'd want to do
> that, but hey, that's only me.

They can pass the command-line parameter, no? If we ever get CMDLINE_EXTEND
support back, they could even add it in there!

> I'd be quite happy to see CONFIG_ARM64_VHE go though. Let me know if you
> want a patch doing that instead.

Yes please.

Will


From david at redhat.com  Thu Apr  8 12:00:47 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 13:00:47 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
Message-ID: <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>

>>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>>
>> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
> 
> Ok, at least that makes it easier.
> 
>>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>>> a configuration.
>>
>> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
>> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
> 
> I thought you were trying to solve the problem where DRMA_ASPEED_GFX
> can optionally link against CMA but would fail to build when the CMA code
> is in a loadable module.

Yes. I was trying to say: it works with this patch just fine. The issue 
you described does not seem to apply (DRM_CMA=m).

> 
>> Your example looks more like a NOP - no?
>> Or will it have the same effect?
> 
> The example I gave is only meaningful if both are tristate, which is
> not the case here as you explain.

Okay, thanks.

> 
> It is a somewhat awkward way to say "prevent this symbol from
> being =y if the dependency is =m".

What would be the right thing to do in the case here then to achieve the 
"if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?

One approach could be to have for DMA_CMA

default y if DRMA_ASPEED_GFX

but it feels like the wrong way to tackle this.

Thanks!

-- 
Thanks,

David / dhildenb



From marcan at marcan.st  Thu Apr  8 12:01:25 2021
From: marcan at marcan.st (Hector Martin)
Date: Thu, 8 Apr 2021 20:01:25 +0900
Subject: [PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace
 using ioremap_np
In-Reply-To: <20210407210317.GB16198@willie-the-truck>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-12-marcan@marcan.st>
 <CAHp75Vcghw6=05vbhX5J8sHoo78JMoq5z4w9__XcocrtRVjF3g@mail.gmail.com>
 <20210407210317.GB16198@willie-the-truck>
Message-ID: <a89af1a3-b065-fca3-19d8-b7fd5ca2f1ae@marcan.st>

On 08/04/2021 06.03, Will Deacon wrote:
>> I would rewrite above as
>>
>> void __iomem *ret;
>>
>> ret = ioremap_np(offset, size);
>> if (ret)
>>    return ret;
>>
>> return ioremap(offset, size);
> 
> Looks like it might be one of those rare occasions where the GCC ternary if
> extension thingy comes in handy:
> 
> 	return ioremap_np(offset, size) ?: ioremap(offset, size);

Today I learned that this one is kosher in kernel code. Handy! Let's go 
with that.

> Acked-by: Will Deacon <will at kernel.org>

Thanks!

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From michael at walle.cc  Thu Apr  8 12:02:19 2021
From: michael at walle.cc (Michael Walle)
Date: Thu,  8 Apr 2021 13:02:19 +0200
Subject: [PATCH 2/2] arm64: defconfig: enable Layerscape EDAC driver
In-Reply-To: <20210408110219.20149-1-michael@walle.cc>
References: <20210408110219.20149-1-michael@walle.cc>
Message-ID: <20210408110219.20149-2-michael@walle.cc>

Most Layerscape SoCs support ECC error reporting for the memory
controller. Enable the corresponding module. In particular, this will
enable EDAC support on the Kontron sl28 board which comes with ECC
memory.

Signed-off-by: Michael Walle <michael at walle.cc>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 99e8a8fb5b4e..c7a62bc6df7c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -883,6 +883,7 @@ CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_LEDS_TRIGGER_PANIC=y
 CONFIG_EDAC=y
 CONFIG_EDAC_GHES=y
+CONFIG_EDAC_LAYERSCAPE=m
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_DS1307=m
 CONFIG_RTC_DRV_HYM8563=m
-- 
2.20.1



From marcan at marcan.st  Thu Apr  8 12:02:21 2021
From: marcan at marcan.st (Hector Martin)
Date: Thu, 8 Apr 2021 20:02:21 +0900
Subject: [PATCH v4 15/18] irqchip/apple-aic: Add support for the Apple
 Interrupt Controller
In-Reply-To: <20210407210940.GC16198@willie-the-truck>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-16-marcan@marcan.st>
 <20210407210940.GC16198@willie-the-truck>
Message-ID: <b8f4f049-d576-2f35-b980-9303ee8969c7@marcan.st>

On 08/04/2021 06.09, Will Deacon wrote:
> Couple of stale comment nits:

[...]

> But with that:
> 
> Acked-by: Will Deacon <will at kernel.org>

Fixed those for the PR, thanks!

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From michael at walle.cc  Thu Apr  8 12:02:18 2021
From: michael at walle.cc (Michael Walle)
Date: Thu,  8 Apr 2021 13:02:18 +0200
Subject: [PATCH 1/2] arm64: dts: ls1028a: fix memory node
Message-ID: <20210408110219.20149-1-michael@walle.cc>

While enabling EDAC support for the LS1028A it was discovered that the
memory node has a wrong endianness setting as well as a wrong interrupt
assignment. Fix both.

This was tested on a sl28 board. To force ECC errors, you can use the
error injection supported by the controller in hardware (with
CONFIG_EDAC_DEBUG enabled):

 # enable error injection
 $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl
 # flip lowest bit of the data
 $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo

Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC")
Signed-off-by: Michael Walle <michael at walle.cc>
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 9506f0669ead..040a3e529bf1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -197,8 +197,8 @@
 		ddr: memory-controller at 1080000 {
 			compatible = "fsl,qoriq-memory-controller";
 			reg = <0x0 0x1080000 0x0 0x1000>;
-			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
-			big-endian;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			little-endian;
 		};
 
 		dcfg: syscon at 1e00000 {
-- 
2.20.1



From yukuai3 at huawei.com  Thu Apr  8 12:15:12 2021
From: yukuai3 at huawei.com (Yu Kuai)
Date: Thu, 8 Apr 2021 19:15:12 +0800
Subject: [PATCH 1/3] mtd: rawnand: mtk: remove redundant dev_err call in
 mtk_ecc_probe()
In-Reply-To: <20210408111514.1011020-1-yukuai3@huawei.com>
References: <20210408111514.1011020-1-yukuai3@huawei.com>
Message-ID: <20210408111514.1011020-2-yukuai3@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
---
 drivers/mtd/nand/raw/mtk_ecc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/mtk_ecc.c b/drivers/mtd/nand/raw/mtk_ecc.c
index 75f1fa3d4d35..c437d97debb8 100644
--- a/drivers/mtd/nand/raw/mtk_ecc.c
+++ b/drivers/mtd/nand/raw/mtk_ecc.c
@@ -515,10 +515,8 @@ static int mtk_ecc_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	ecc->regs = devm_ioremap_resource(dev, res);
-	if (IS_ERR(ecc->regs)) {
-		dev_err(dev, "failed to map regs: %ld\n", PTR_ERR(ecc->regs));
+	if (IS_ERR(ecc->regs))
 		return PTR_ERR(ecc->regs);
-	}
 
 	ecc->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(ecc->clk)) {
-- 
2.25.4



From yukuai3 at huawei.com  Thu Apr  8 12:15:11 2021
From: yukuai3 at huawei.com (Yu Kuai)
Date: Thu, 8 Apr 2021 19:15:11 +0800
Subject: [PATCH 0/3] code optimization for mtd
Message-ID: <20210408111514.1011020-1-yukuai3@huawei.com>

Yu Kuai (3):
  mtd: rawnand: mtk: remove redundant dev_err call in mtk_ecc_probe()
  mtd: plat-ram: remove redundant dev_err call in platram_probe()
  mtd: phram: Fix error return code in phram_setup()

 drivers/mtd/devices/phram.c    | 1 +
 drivers/mtd/maps/plat-ram.c    | 1 -
 drivers/mtd/nand/raw/mtk_ecc.c | 4 +---
 3 files changed, 2 insertions(+), 4 deletions(-)

-- 
2.25.4



From yukuai3 at huawei.com  Thu Apr  8 12:15:14 2021
From: yukuai3 at huawei.com (Yu Kuai)
Date: Thu, 8 Apr 2021 19:15:14 +0800
Subject: [PATCH 3/3] mtd: phram: Fix error return code in phram_setup()
In-Reply-To: <20210408111514.1011020-1-yukuai3@huawei.com>
References: <20210408111514.1011020-1-yukuai3@huawei.com>
Message-ID: <20210408111514.1011020-4-yukuai3@huawei.com>

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
---
 drivers/mtd/devices/phram.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index 5b04ae6c3057..6ed6c51fac69 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -270,6 +270,7 @@ static int phram_setup(const char *val)
 	if (len == 0 || erasesize == 0 || erasesize > len
 	    || erasesize > UINT_MAX || rem) {
 		parse_err("illegal erasesize or len\n");
+		ret = -EINVAL;
 		goto error;
 	}
 
-- 
2.25.4



From yukuai3 at huawei.com  Thu Apr  8 12:15:13 2021
From: yukuai3 at huawei.com (Yu Kuai)
Date: Thu, 8 Apr 2021 19:15:13 +0800
Subject: [PATCH 2/3] mtd: plat-ram: remove redundant dev_err call in
 platram_probe()
In-Reply-To: <20210408111514.1011020-1-yukuai3@huawei.com>
References: <20210408111514.1011020-1-yukuai3@huawei.com>
Message-ID: <20210408111514.1011020-3-yukuai3@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
---
 drivers/mtd/maps/plat-ram.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mtd/maps/plat-ram.c b/drivers/mtd/maps/plat-ram.c
index 0bec7c791d17..cedd8ef9a6bf 100644
--- a/drivers/mtd/maps/plat-ram.c
+++ b/drivers/mtd/maps/plat-ram.c
@@ -127,7 +127,6 @@ static int platram_probe(struct platform_device *pdev)
 	info->map.virt = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(info->map.virt)) {
 		err = PTR_ERR(info->map.virt);
-		dev_err(&pdev->dev, "failed to ioremap() region\n");
 		goto exit_free;
 	}
 
-- 
2.25.4



From mark.rutland at arm.com  Thu Apr  8 12:08:15 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 8 Apr 2021 12:08:15 +0100
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <20210407124437.GA15622@willie-the-truck>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
 <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
 <20210407124437.GA15622@willie-the-truck>
Message-ID: <20210408110800.GA32792@C02TD0UTHF1T.local>

On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> [Moving Mark to To: since I'd like his view on this]
> 
> On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
> > >
> > > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon <will at kernel.org> wrote:
> > > > >
> > > > > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > > > > From: Raphael Gault <raphael.gault at arm.com>

> > > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > > > +{
> > > > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > > > +
> > > > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > > +             return;
> > > > > > +
> > > > > > +     if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > > > >
> > > > > Given that the pmu_direct_access field is global per-mm, won't this go
> > > > > wrong if multiple PMUs are opened by the same process but only a subset
> > > > > are exposed to EL0? Perhaps pmu_direct_access should be treated as a mask
> > > > > rather than a counter, so that we can 'and' it with the supported_cpus for
> > > > > the PMU we're dealing with.
> > > >
> > > > It needs to be a count to support multiple events on the same PMU. If
> > > > the event is not enabled for EL0, then we'd exit out on the
> > > > ARMPMU_EL0_RD_CNTR check. So I think we're fine.
> > >
> > > I'm still not convinced; pmu_direct_access is shared between PMUs, so
> > > testing the result of atomic_dec_and_test() just doesn't make sense to
> > > me, as another PMU could be playing with the count.
> > 
> > How is that a problem? Let's make a concrete example:
> > 
> > map PMU1:event2 -> pmu_direct_access = 1 -> enable access
> > map PMU2:event3 -> pmu_direct_access = 2
> > map PMU1:event4 -> pmu_direct_access = 3
> > unmap PMU2:event3 -> pmu_direct_access = 2
> > unmap PMU1:event2 -> pmu_direct_access = 1
> > unmap PMU1:event4 -> pmu_direct_access = 0 -> disable access
> > 
> > The only issue I can see is PMU2 remains enabled for user access until
> > the last unmap. But we're sharing the mm, so who cares? Also, in this
> > scenario it is the user's problem to pin themselves to cores sharing a
> > PMU. If the user doesn't do that, they get to keep the pieces.
> 
> I guess I'm just worried about exposing the counters to userspace after
> the PMU driver (or perf core?) thinks that they're no longer exposed in
> case we leak other events.

IMO that's not practically different from the single-PMU case (i.e.
multi-PMU isn't material, either we have a concern with leaking or we
don't); more on that below.

While it looks odd to place this on the mm, I don't think it's the end
of the world.

> However, I'm not sure how this is supposed to work normally: what
> happens if e.g. a privileged user has a per-cpu counter for a kernel
> event while a task has a counter with direct access -- can that task
> read the kernel event out of the PMU registers from userspace?

Yes -- userspace could go read any counters even though it isn't
supposed to, and could potentially infer information from those. It
won't have access to the config registers or kernel data structures, so
it isn't guaranteed to know what the even is or when it is
context-switched/reprogrammed/etc.

If we believe that's a problem, then it's difficult to do anything
robust other than denying userspace access entirely, since disabling
userspace access while in use would surprise applications, and denying
privileged events would need some global state that we consult at event
creation time (in addition to being an inversion of privilege).

IIRC there was some fuss about this a while back on x86; I'll go dig and
see what I can find, unless Peter has a memory...

Thanks,
Mark.


From yeweihua4 at huawei.com  Thu Apr  8 12:06:38 2021
From: yeweihua4 at huawei.com (Ye Weihua)
Date: Thu, 8 Apr 2021 19:06:38 +0800
Subject: [PATCH -next] i2c: imx: Fix PM reference leak in i2c_imx_reg_slave()
Message-ID: <20210408110638.200761-1-yeweihua4@huawei.com>

The PM reference count is not expected to be incremented on return in
these functions.

However, pm_runtime_get_sync() will increment the PM reference count
even on failure. forgetting to put the reference again will result in
a leak.

Replace it with pm_runtime_resume_and_get() to keep the usage counter
balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>
---
 drivers/i2c/busses/i2c-imx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b80fdc1f0092..dc5ca71906db 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -801,7 +801,7 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
 	i2c_imx->last_slave_event = I2C_SLAVE_STOP;
 
 	/* Resume */
-	ret = pm_runtime_get_sync(i2c_imx->adapter.dev.parent);
+	ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
 	if (ret < 0) {
 		dev_err(&i2c_imx->adapter.dev, "failed to resume i2c controller");
 		return ret;
@@ -1253,7 +1253,7 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
 	struct imx_i2c_struct *i2c_imx = i2c_get_adapdata(adapter);
 	int result;
 
-	result = pm_runtime_get_sync(i2c_imx->adapter.dev.parent);
+	result = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
 	if (result < 0)
 		return result;
 
@@ -1496,7 +1496,7 @@ static int i2c_imx_remove(struct platform_device *pdev)
 	struct imx_i2c_struct *i2c_imx = platform_get_drvdata(pdev);
 	int irq, ret;
 
-	ret = pm_runtime_get_sync(&pdev->dev);
+	ret = pm_runtime_resume_and_get(&pdev->dev);
 	if (ret < 0)
 		return ret;
 
-- 
2.17.1



From marcan at marcan.st  Thu Apr  8 12:13:44 2021
From: marcan at marcan.st (Hector Martin)
Date: Thu, 8 Apr 2021 20:13:44 +0900
Subject: [PATCH v2 1/3] arm64: cpufeature: Allow early filtering of
 feature override
In-Reply-To: <20210330173947.999859-2-maz@kernel.org>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-2-maz@kernel.org>
Message-ID: <2891836d-c208-a1ea-3119-006e7f3135b7@marcan.st>

On 31/03/2021 02.39, Marc Zyngier wrote:
> + * @mask		Mask of the features that are overriden by @val

FYI, I checkpatched this by accident and it pointed out a typo 
('overridden').

It also complained about a tab thing in the next patch (the last hunk 
has a tab followed by 8 spaces), though that was just carried over from 
the line before the patch.

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From yeweihua4 at huawei.com  Thu Apr  8 12:19:30 2021
From: yeweihua4 at huawei.com (Ye Weihua)
Date: Thu, 8 Apr 2021 19:19:30 +0800
Subject: [PATCH -next] i2c: imx-lpi2c: fix PM reference leak in
 lpi2c_imx_master_enable()
Message-ID: <20210408111930.203574-1-yeweihua4@huawei.com>

The PM reference count is not expected to be incremented on return in
ipi2c_imx_master_enable().

However, pm_runtime_get_sync() will increment the PM reference count
even on failure. forgetting to put the reference again will result in
a leak.

Replace it with pm_runtime_resume_and_get() to keep the usage counter
balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>
---
 drivers/i2c/busses/i2c-imx-lpi2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 9db6ccded5e9..8b9ba055c418 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -259,7 +259,7 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct *lpi2c_imx)
 	unsigned int temp;
 	int ret;
 
-	ret = pm_runtime_get_sync(lpi2c_imx->adapter.dev.parent);
+	ret = pm_runtime_resume_and_get(lpi2c_imx->adapter.dev.parent);
 	if (ret < 0)
 		return ret;
 
-- 
2.17.1



From pulehui at huawei.com  Thu Apr  8 12:23:52 2021
From: pulehui at huawei.com (Pu Lehui)
Date: Thu, 8 Apr 2021 19:23:52 +0800
Subject: [PATCH -next] i2c: cadence: Fix PM reference leak in
 cdns_i2c_master_xfer()
Message-ID: <20210408112352.211173-1-pulehui@huawei.com>

pm_runtime_get_sync() will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
counter balanced.

Signed-off-by: Pu Lehui <pulehui at huawei.com>
---
 drivers/i2c/busses/i2c-cadence.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index e4b7f2a951ad..e8eae8725900 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -789,7 +789,7 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
 	bool change_role = false;
 #endif
 
-	ret = pm_runtime_get_sync(id->dev);
+	ret = pm_runtime_resume_and_get(id->dev);
 	if (ret < 0)
 		return ret;
 
@@ -911,7 +911,7 @@ static int cdns_reg_slave(struct i2c_client *slave)
 	if (slave->flags & I2C_CLIENT_TEN)
 		return -EAFNOSUPPORT;
 
-	ret = pm_runtime_get_sync(id->dev);
+	ret = pm_runtime_resume_and_get(id->dev);
 	if (ret < 0)
 		return ret;
 
-- 
2.17.1



From pulehui at huawei.com  Thu Apr  8 12:24:48 2021
From: pulehui at huawei.com (Pu Lehui)
Date: Thu, 8 Apr 2021 19:24:48 +0800
Subject: [PATCH -next] i2c: img-scb: fix PM reference leak in img_i2c_xfer()
Message-ID: <20210408112448.211380-1-pulehui@huawei.com>

pm_runtime_get_sync() will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
counter balanced.

Signed-off-by: Pu Lehui <pulehui at huawei.com>
---
 drivers/i2c/busses/i2c-img-scb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c
index 98a89301ed2a..8e987945ed45 100644
--- a/drivers/i2c/busses/i2c-img-scb.c
+++ b/drivers/i2c/busses/i2c-img-scb.c
@@ -1057,7 +1057,7 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
 			atomic = true;
 	}
 
-	ret = pm_runtime_get_sync(adap->dev.parent);
+	ret = pm_runtime_resume_and_get(adap->dev.parent);
 	if (ret < 0)
 		return ret;
 
@@ -1158,7 +1158,7 @@ static int img_i2c_init(struct img_i2c *i2c)
 	u32 rev;
 	int ret;
 
-	ret = pm_runtime_get_sync(i2c->adap.dev.parent);
+	ret = pm_runtime_resume_and_get(i2c->adap.dev.parent);
 	if (ret < 0)
 		return ret;
 
-- 
2.17.1



From andy.shevchenko at gmail.com  Thu Apr  8 12:24:50 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 8 Apr 2021 14:24:50 +0300
Subject: [PATCH v4 11/18] asm-generic/io.h: implement pci_remap_cfgspace
 using ioremap_np
In-Reply-To: <a89af1a3-b065-fca3-19d8-b7fd5ca2f1ae@marcan.st>
References: <20210402090542.131194-1-marcan@marcan.st>
 <20210402090542.131194-12-marcan@marcan.st>
 <CAHp75Vcghw6=05vbhX5J8sHoo78JMoq5z4w9__XcocrtRVjF3g@mail.gmail.com>
 <20210407210317.GB16198@willie-the-truck>
 <a89af1a3-b065-fca3-19d8-b7fd5ca2f1ae@marcan.st>
Message-ID: <CAHp75Vdyug5zbSpGSDEK9hUY+y+ZLDeAyLsc2HAjEzczCpDOSQ@mail.gmail.com>

On Thu, Apr 8, 2021 at 2:01 PM Hector Martin <marcan at marcan.st> wrote:
> On 08/04/2021 06.03, Will Deacon wrote:
> >> I would rewrite above as
> >>
> >> void __iomem *ret;
> >>
> >> ret = ioremap_np(offset, size);
> >> if (ret)
> >>    return ret;
> >>
> >> return ioremap(offset, size);
> >
> > Looks like it might be one of those rare occasions where the GCC ternary if
> > extension thingy comes in handy:
> >
> >       return ioremap_np(offset, size) ?: ioremap(offset, size);
>
> Today I learned that this one is kosher in kernel code. Handy! Let's go
> with that.

It depends on the maintainer. Greg, for example, doesn't  like this. I
have no strong opinion (I use both variants on case-by-case basis),
though I think in headers better to spell out all conditionals
clearly.

-- 
With Best Regards,
Andy Shevchenko


From chun-jie.chen at mediatek.com  Thu Apr  8 12:28:49 2021
From: chun-jie.chen at mediatek.com (20181221120906 created)
Date: Thu, 8 Apr 2021 19:28:49 +0800
Subject: [RESEND PATCH v7 00/22] Mediatek MT8192 clock support
In-Reply-To: <20210324104110.13383-1-chun-jie.chen@mediatek.com>
References: <20210324104110.13383-1-chun-jie.chen@mediatek.com>
Message-ID: <1617881329.6756.3.camel@mtksdccf07>

On Wed, 2021-03-24 at 18:40 +0800, Chun-Jie Chen (???) wrote:

Hi Maintainers,
 
Gentle pin for this patch series.
 
Thanks

> reason for resending v7:
> - add review history from series below
> [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405295__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBXEY4iHa$
> 
> change since v6:
> - update from series below
> [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405295__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBXEY4iHa$
> - fix DT bindings fail
> - fix checkpatch warning
> - update mux ops without gate control
> 
> change since v5:
> - remove unused clocks by rolling Tinghan's patches[1][2] into series
> [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=398781__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBS6llsNi$
> [2] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405143__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBfBntgEt$
> - remove dts related patches from series
> 
> change since v4:
> - merge some subsystem into same driver
> - add a generic probe function to reduce duplicated code
> 
> changes since v3:
> - add critical clocks
> - split large patches into small ones
> 
> changes since v2:
> - update and split dt-binding documents by functionalities
> - add error checking in probe() function
> - fix incorrect clock relation and add critical clocks
> - update license identifier and minor fix of coding style
> 
> changes since v1:
> - fix asymmetrical control of PLL
> - have en_mask used as divider enable mask on all MediaTek SoC
> 
> chun-jie.chen (22):
>   dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c
>     wrapper controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of mdpsys
>     controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of msdc
>     controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of scp adsp
>     controller
>   dt-bindings: ARM: Mediatek: Document bindings of MT8192 clock
>     controllers
>   clk: mediatek: Add dt-bindings of MT8192 clocks
>   clk: mediatek: Fix asymmetrical PLL enable and disable control
>   clk: mediatek: Add configurable enable control to mtk_pll_data
>   clk: mediatek: Add mtk_clk_simple_probe() to simplify clock providers
>   clk: mediatek: Add MT8192 basic clocks support
>   clk: mediatek: Add MT8192 audio clock support
>   clk: mediatek: Add MT8192 camsys clock support
>   clk: mediatek: Add MT8192 imgsys clock support
>   clk: mediatek: Add MT8192 imp i2c wrapper clock support
>   clk: mediatek: Add MT8192 ipesys clock support
>   clk: mediatek: Add MT8192 mdpsys clock support
>   clk: mediatek: Add MT8192 mfgcfg clock support
>   clk: mediatek: Add MT8192 mmsys clock support
>   clk: mediatek: Add MT8192 msdc clock support
>   clk: mediatek: Add MT8192 scp adsp clock support
>   clk: mediatek: Add MT8192 vdecsys clock support
>   clk: mediatek: Add MT8192 vencsys clock support
> 
>  .../arm/mediatek/mediatek,apmixedsys.txt      |    1 +
>  .../bindings/arm/mediatek/mediatek,audsys.txt |    1 +
>  .../bindings/arm/mediatek/mediatek,camsys.txt |   22 +
>  .../bindings/arm/mediatek/mediatek,imgsys.txt |    2 +
>  .../arm/mediatek/mediatek,imp_iic_wrap.yaml   |   80 +
>  .../arm/mediatek/mediatek,infracfg.txt        |    1 +
>  .../bindings/arm/mediatek/mediatek,ipesys.txt |    1 +
>  .../arm/mediatek/mediatek,mdpsys.yaml         |   40 +
>  .../bindings/arm/mediatek/mediatek,mfgcfg.txt |    1 +
>  .../bindings/arm/mediatek/mediatek,mmsys.txt  |    1 +
>  .../bindings/arm/mediatek/mediatek,msdc.yaml  |   48 +
>  .../arm/mediatek/mediatek,pericfg.yaml        |    1 +
>  .../arm/mediatek/mediatek,scp-adsp.yaml       |   40 +
>  .../arm/mediatek/mediatek,topckgen.txt        |    1 +
>  .../arm/mediatek/mediatek,vdecsys.txt         |    8 +
>  .../arm/mediatek/mediatek,vencsys.txt         |    1 +
>  drivers/clk/mediatek/Kconfig                  |   80 +
>  drivers/clk/mediatek/Makefile                 |   13 +
>  drivers/clk/mediatek/clk-mt8192-aud.c         |  118 ++
>  drivers/clk/mediatek/clk-mt8192-cam.c         |  107 ++
>  drivers/clk/mediatek/clk-mt8192-img.c         |   70 +
>  .../clk/mediatek/clk-mt8192-imp_iic_wrap.c    |  119 ++
>  drivers/clk/mediatek/clk-mt8192-ipe.c         |   57 +
>  drivers/clk/mediatek/clk-mt8192-mdp.c         |   82 +
>  drivers/clk/mediatek/clk-mt8192-mfg.c         |   50 +
>  drivers/clk/mediatek/clk-mt8192-mm.c          |  108 ++
>  drivers/clk/mediatek/clk-mt8192-msdc.c        |   85 ++
>  drivers/clk/mediatek/clk-mt8192-scp_adsp.c    |   50 +
>  drivers/clk/mediatek/clk-mt8192-vdec.c        |   94 ++
>  drivers/clk/mediatek/clk-mt8192-venc.c        |   53 +
>  drivers/clk/mediatek/clk-mt8192.c             | 1326 +++++++++++++++++
>  drivers/clk/mediatek/clk-mtk.c                |   23 +
>  drivers/clk/mediatek/clk-mtk.h                |   28 +-
>  drivers/clk/mediatek/clk-mux.c                |    9 +-
>  drivers/clk/mediatek/clk-mux.h                |   18 +-
>  drivers/clk/mediatek/clk-pll.c                |   31 +-
>  include/dt-bindings/clock/mt8192-clk.h        |  585 ++++++++
>  37 files changed, 3335 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-aud.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-cam.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-imp_iic_wrap.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-ipe.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mdp.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mfg.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-msdc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-scp_adsp.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192.c
>  create mode 100644 include/dt-bindings/clock/mt8192-clk.h
> 
> --
> 2.18.0
> 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBdxKKU1e$


From michal.simek at xilinx.com  Thu Apr  8 12:30:51 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 8 Apr 2021 13:30:51 +0200
Subject: [PATCH -next] i2c: cadence: Fix PM reference leak in
 cdns_i2c_master_xfer()
In-Reply-To: <20210408112352.211173-1-pulehui@huawei.com>
References: <20210408112352.211173-1-pulehui@huawei.com>
Message-ID: <1132644d-4cf0-a620-3adf-08245dd890ba@xilinx.com>



On 4/8/21 1:23 PM, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
> 
> Signed-off-by: Pu Lehui <pulehui at huawei.com>
> ---
>  drivers/i2c/busses/i2c-cadence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index e4b7f2a951ad..e8eae8725900 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -789,7 +789,7 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
>  	bool change_role = false;
>  #endif
>  
> -	ret = pm_runtime_get_sync(id->dev);
> +	ret = pm_runtime_resume_and_get(id->dev);
>  	if (ret < 0)
>  		return ret;
>  
> @@ -911,7 +911,7 @@ static int cdns_reg_slave(struct i2c_client *slave)
>  	if (slave->flags & I2C_CLIENT_TEN)
>  		return -EAFNOSUPPORT;
>  
> -	ret = pm_runtime_get_sync(id->dev);
> +	ret = pm_runtime_resume_and_get(id->dev);
>  	if (ret < 0)
>  		return ret;
>  
> 

Ravi/Shubhrajyoti: Please take a look at this.

Thanks,
Michal


From daniel at ffwll.ch  Thu Apr  8 12:38:17 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 8 Apr 2021 13:38:17 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
Message-ID: <YG7rKfJkTDJorqvY@phenom.ffwll.local>

On Thu, Apr 08, 2021 at 12:20:50PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david at redhat.com> wrote:
> >
> > Random drivers should not override a user configuration of core knobs
> > (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> > dependencies and manual overrides.
> >
> > "This is similar to "select" as it enforces a lower limit on another
> >  symbol except that the "implied" symbol's value may still be set to n
> >  from a direct dependency or with a visible prompt."
> >
> > Implying DRM_CMA should be sufficient, as that depends on CMA.
> >
> > Note: If this is a real dependency, we should use "depends on DMA_CMA"
> > instead -  but I assume the driver can work without CMA just fine --
> > esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> 
> 'imply' is almost never the right solution, and it tends to cause more
> problems than it solves.
> 
> In particular, it does not prevent a configuration with 'DRM_CMA=m'
> and 'DRMA_ASPEED_GFX=y', or any build failures from such
> a configuration.
> 
> If you want this kind of soft dependency, you need
> 'depends on DRM_CMA || !DRM_CMA'.

The problem is that depends on is a real pain for users to find their
drivers. This is why we have a ton of select, because the kconfig ui tends
to suck.

If you want to change this, we need automatic conflict resolution like apt
and other package managers have, with suggestions how to fix the config if
you want to enable a driver, but some of its requirements are missing. The
current approach of hiding driver symbols complete if any of their
dependencies are off is really not great.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From pbonzini at redhat.com  Thu Apr  8 12:40:59 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 8 Apr 2021 13:40:59 +0200
Subject: [PATCH 3/3] mm: unexport follow_pfn
In-Reply-To: <YG7VWWkvnv2IPEXt@phenom.ffwll.local>
References: <20210316153303.3216674-1-daniel.vetter@ffwll.ch>
 <20210316153303.3216674-4-daniel.vetter@ffwll.ch>
 <20210329133101.GA1168973@nvidia.com> <YG7VWWkvnv2IPEXt@phenom.ffwll.local>
Message-ID: <5f956a46-da38-e72a-edaa-3b746a275f1e@redhat.com>

On 08/04/21 12:05, Daniel Vetter wrote:
> On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
>> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
>>> Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
>>> follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
>>> follow_pte()")) have lost their callsites of follow_pfn(). All the
>>> other ones have been switched over to unsafe_follow_pfn because they
>>> cannot be fixed without breaking userspace api.
>>>
>>> Argueably the vfio code is still racy, but that's kinda a bigger
>>
>> vfio and kvm
> 
> Hm I thought kvm is non-racy due to the mmu notifier catch races?

No, but the plan is indeed to have some struct for each page that uses 
follow_pfn and update it from the MMU notifiers.

Paolo

>>
>>> picture. But since it does leak the pte beyond where it drops the pt
>>> lock, without anything else like an mmu notifier guaranteeing
>>> coherence, the problem is at least clearly visible in the vfio code.
>>> So good enough with me.
>>>
>>> I've decided to keep the explanation that after dropping the pt lock
>>> you must have an mmu notifier if you keep using the pte somehow by
>>> adjusting it and moving it into the kerneldoc for the new follow_pte()
>>> function.
>>>
>>> Cc: 3pvd at google.com
>>> Cc: Jann Horn <jannh at google.com>
>>> Cc: Paolo Bonzini <pbonzini at redhat.com>
>>> Cc: Jason Gunthorpe <jgg at nvidia.com>
>>> Cc: Cornelia Huck <cohuck at redhat.com>
>>> Cc: Peter Xu <peterx at redhat.com>
>>> Cc: Alex Williamson <alex.williamson at redhat.com>
>>> Cc: linux-mm at kvack.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-samsung-soc at vger.kernel.org
>>> Cc: linux-media at vger.kernel.org
>>> Cc: kvm at vger.kernel.org
>>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>>> ---
>>>   include/linux/mm.h |  2 --
>>>   mm/memory.c        | 26 +++++---------------------
>>>   mm/nommu.c         | 13 +------------
>>>   3 files changed, 6 insertions(+), 35 deletions(-)
>>
>> Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
> 
> Thanks for your r-b tags, I'll add them.
> -Daniel
> 
>>
>> Jason
> 



From benjamin.tissoires at redhat.com  Thu Apr  8 12:43:52 2021
From: benjamin.tissoires at redhat.com (Benjamin Tissoires)
Date: Thu, 8 Apr 2021 13:43:52 +0200
Subject: [RESEND 00/25] Rid W=1 warnings from HID
In-Reply-To: <20210408070605.GC2961413@dell>
References: <20210326143458.508959-1-lee.jones@linaro.org>
 <20210406085605.GS2916463@dell>
 <CAO-hwJ+5Vd6jC2+0pfHLOw3opdXzKoc9pUWzxmBVhSvQvNWMsQ@mail.gmail.com>
 <20210408070605.GC2961413@dell>
Message-ID: <CAO-hwJJrn4mzPwzYvusGNa6KhLZ+kCn=svzgGJD=6q+Urz=YsA@mail.gmail.com>

On Thu, Apr 8, 2021 at 9:06 AM Lee Jones <lee.jones at linaro.org> wrote:
>
> On Wed, 07 Apr 2021, Benjamin Tissoires wrote:
>
> > On Tue, Apr 6, 2021 at 10:56 AM Lee Jones <lee.jones at linaro.org> wrote:
> > >
> > > On Fri, 26 Mar 2021, Lee Jones wrote:
> > >
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel builds, which are currently overwhelmingly riddled with
> > > > niggly little warnings.
> > > >
> > > > Lee Jones (25):
> > > >   HID: intel-ish-hid: Remove unused variable 'err'
> > > >   HID: ishtp-hid-client: Move variable to where it's actually used
> > > >   HID: intel-ish-hid: pci-ish: Remove unused variable 'ret'
> > > >   HID: intel-ish: Supply some missing param descriptions
> > > >   HID: intel-ish: Fix a naming disparity and a formatting error
> > > >   HID: usbhid: Repair a formatting issue in a struct description
> > > >   HID: intel-ish-hid: Fix a little doc-rot
> > > >   HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses
> > > >   HID: hid-alps: Correct struct misnaming
> > > >   HID: intel-ish-hid: Fix potential copy/paste error
> > > >   HID: hid-core: Fix incorrect function name in header
> > > >   HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in
> > > >     header
> > > >   HID: ishtp-hid-client: Fix incorrect function name report_bad_packet()
> > > >   HID: hid-kye: Fix incorrect function name for kye_tablet_enable()
> > > >   HID: hid-picolcd_core: Remove unused variable 'ret'
> > > >   HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote
> > > >     abuses
> > > >   HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs
> > > >   HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses
> > > >   HID: hid-uclogic-params: Ensure function names are present and correct
> > > >     in kernel-doc headers
> > > >   HID: hid-sensor-custom: Remove unused variable 'ret'
> > > >   HID: wacom_sys: Demote kernel-doc abuse
> > > >   HID: hid-sensor-hub: Remove unused struct member 'quirks'
> > > >   HID: hid-sensor-hub: Move 'hsdev' description to correct struct
> > > >     definition
> > > >   HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues
> > > >   HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning
> > >
> > > These have been on the list for a couple of weeks now.
> > >
> > > Is there anything I can do to help expedite their merge?
> > >
> > > I'm concerned since -rc6 has just been released.
> >
> > Sorry for the delay.
> >
> > I am currently queuing them locally and running a few tests on them. I
> > don't expect anything to happen, but better be safe than anything.
> >
> > FWIW, I am splitting the series in 3:
> > - 11 patches for intel ish are going to be queued in for-5.13/intel-ish
> > - the thrustmaster one in for-5.13/thrustmaster
> > - the rest (13 patches) will be sent in for-5.13/warnings.
>
> Sounds good to me.  Thanks Benjamin.
>
After a few attempts at fixing my CI, I have now pushed this series as
mentioned previously.

Cheers,
Benjamin



From daniel at ffwll.ch  Thu Apr  8 12:44:06 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 8 Apr 2021 13:44:06 +0200
Subject: [PATCH 3/3] mm: unexport follow_pfn
In-Reply-To: <5f956a46-da38-e72a-edaa-3b746a275f1e@redhat.com>
References: <20210316153303.3216674-1-daniel.vetter@ffwll.ch>
 <20210316153303.3216674-4-daniel.vetter@ffwll.ch>
 <20210329133101.GA1168973@nvidia.com>
 <YG7VWWkvnv2IPEXt@phenom.ffwll.local>
 <5f956a46-da38-e72a-edaa-3b746a275f1e@redhat.com>
Message-ID: <YG7shmP1WdfguDQf@phenom.ffwll.local>

On Thu, Apr 08, 2021 at 01:40:59PM +0200, Paolo Bonzini wrote:
> On 08/04/21 12:05, Daniel Vetter wrote:
> > On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > > > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > > > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > > > other ones have been switched over to unsafe_follow_pfn because they
> > > > cannot be fixed without breaking userspace api.
> > > > 
> > > > Argueably the vfio code is still racy, but that's kinda a bigger
> > > 
> > > vfio and kvm
> > 
> > Hm I thought kvm is non-racy due to the mmu notifier catch races?
> 
> No, but the plan is indeed to have some struct for each page that uses
> follow_pfn and update it from the MMU notifiers.

Thanks for clarifying, I've fixed the commit message to mention both vfio
and kvm as Jason suggested. I didn't know that the follow_pte usage in kvm
still has some gaps wrt what's invalidated with mmu notifiers.

Thanks, Daniel

> 
> Paolo
> 
> > > 
> > > > picture. But since it does leak the pte beyond where it drops the pt
> > > > lock, without anything else like an mmu notifier guaranteeing
> > > > coherence, the problem is at least clearly visible in the vfio code.
> > > > So good enough with me.
> > > > 
> > > > I've decided to keep the explanation that after dropping the pt lock
> > > > you must have an mmu notifier if you keep using the pte somehow by
> > > > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > > > function.
> > > > 
> > > > Cc: 3pvd at google.com
> > > > Cc: Jann Horn <jannh at google.com>
> > > > Cc: Paolo Bonzini <pbonzini at redhat.com>
> > > > Cc: Jason Gunthorpe <jgg at nvidia.com>
> > > > Cc: Cornelia Huck <cohuck at redhat.com>
> > > > Cc: Peter Xu <peterx at redhat.com>
> > > > Cc: Alex Williamson <alex.williamson at redhat.com>
> > > > Cc: linux-mm at kvack.org
> > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > Cc: linux-samsung-soc at vger.kernel.org
> > > > Cc: linux-media at vger.kernel.org
> > > > Cc: kvm at vger.kernel.org
> > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > > ---
> > > >   include/linux/mm.h |  2 --
> > > >   mm/memory.c        | 26 +++++---------------------
> > > >   mm/nommu.c         | 13 +------------
> > > >   3 files changed, 6 insertions(+), 35 deletions(-)
> > > 
> > > Reviewed-by: Jason Gunthorpe <jgg at nvidia.com>
> > 
> > Thanks for your r-b tags, I'll add them.
> > -Daniel
> > 
> > > 
> > > Jason
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From arnd at arndb.de  Thu Apr  8 12:44:22 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 13:44:22 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
Message-ID: <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>

On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david at redhat.com> wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>
> One approach could be to have for DMA_CMA
>
> default y if DRMA_ASPEED_GFX
>
> but it feels like the wrong way to tackle this.

I'm still not sure what you are trying to achieve. Is the idea only to provide
a useful default for DMA_CMA depending on which drivers are enabled?

This is something you could do using a hidden helper symbol like

config DRMA_ASPEED_GFX
       bool "Aspeed display driver"
       select DRM_WANT_CMA

config DRM_WANT_CMA
       bool
       help
          Select this from any driver that benefits from CMA being enabled

config DMA_CMA
       bool "Use CMA helpers for DRM"
       default DRM_WANT_CMA

         Arnd


From heying24 at huawei.com  Thu Apr  8 12:48:50 2021
From: heying24 at huawei.com (He Ying)
Date: Thu, 8 Apr 2021 07:48:50 -0400
Subject: [PATCH v2 -next] phy: phy-mtk-mipi-dsi: Remove redundant dev_err call
 in mtk_mipi_tx_probe()
Message-ID: <20210408114850.14422-1-heying24@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reviewed-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: He Ying <heying24 at huawei.com>
---
v2:
- Use 'return PTR_ERR();' instead of 'ret = PTR_ERR();return ret;'.

 drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index c51114d8e437..01cf31633019 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -151,9 +151,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	mipi_tx->regs = devm_ioremap_resource(dev, mem);
 	if (IS_ERR(mipi_tx->regs)) {
-		ret = PTR_ERR(mipi_tx->regs);
-		dev_err(dev, "Failed to get memory resource: %d\n", ret);
-		return ret;
+		return PTR_ERR(mipi_tx->regs);
 	}
 
 	ref_clk = devm_clk_get(dev, NULL);
-- 
2.17.1



From j.neuschaefer at gmx.net  Thu Apr  8 12:51:33 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Thu, 8 Apr 2021 13:51:33 +0200
Subject: [PATCH] irqchip/wpcm450: Drop COMPILE_TEST
In-Reply-To: <0dd30fb16e1b9d9c7fe226cc102f8fac@kernel.org>
References: <20210408080030.2277572-1-maz@kernel.org>
 <YG7CwB0lMWJGylt7@latitude>
 <0dd30fb16e1b9d9c7fe226cc102f8fac@kernel.org>
Message-ID: <YG7uRcKSGAxJDSuW@latitude>

On Thu, Apr 08, 2021 at 11:43:19AM +0100, Marc Zyngier wrote:
> On 2021-04-08 09:45, Jonathan Neusch?fer wrote:
[...]
> > I guess I could use (COMPILE_TEST && ARM) or something?
> 
> One of the major interest of COMPILE_TEST to be able to check code
> cross-architecture. For code that cannot compile cross-architecture,
> I'm not sure it matters much.
> 
> We can achieve the same result by enabling multi-platform builds (and
> this system should probably end-up in multi_v5_defconfig).

Alright, thanks for the explanation.


Jonathan
-------------- 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/20210408/a689627c/attachment.sig>

From heying24 at huawei.com  Thu Apr  8 12:55:30 2021
From: heying24 at huawei.com (He Ying)
Date: Thu, 8 Apr 2021 07:55:30 -0400
Subject: [PATCH v2 -next] phy: phy-mtk-hdmi: Remove redundant dev_err call in
 mtk_hdmi_phy_probe()
Message-ID: <20210408115530.15673-1-heying24@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: He Ying <heying24 at huawei.com>
---
v2:
- Use 'return PTR_ERR()' instead of 'ret = PTR_ERR();return ret;'.

 drivers/phy/mediatek/phy-mtk-hdmi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 8313bd517e4c..8ad8f717ef43 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -119,9 +119,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	hdmi_phy->regs = devm_ioremap_resource(dev, mem);
 	if (IS_ERR(hdmi_phy->regs)) {
-		ret = PTR_ERR(hdmi_phy->regs);
-		dev_err(dev, "Failed to get memory resource: %d\n", ret);
-		return ret;
+		return PTR_ERR(hdmi_phy->regs);
 	}
 
 	ref_clk = devm_clk_get(dev, "pll_ref");
-- 
2.17.1



From david at redhat.com  Thu Apr  8 13:00:48 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 14:00:48 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
Message-ID: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>

On 08.04.21 13:44, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david at redhat.com> wrote:
>>>
>>> It is a somewhat awkward way to say "prevent this symbol from
>>> being =y if the dependency is =m".
>>
>> What would be the right thing to do in the case here then to achieve the
>> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>>
>> One approach could be to have for DMA_CMA
>>
>> default y if DRMA_ASPEED_GFX
>>
>> but it feels like the wrong way to tackle this.
> 
> I'm still not sure what you are trying to achieve. Is the idea only to provide
> a useful default for DMA_CMA depending on which drivers are enabled?

"Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n)."

Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to 
set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with 
e.g., DRMA_ASPEED_GFX=y because it will always override my (user!) 
setting -- even though it doesn't really always need it. Using "select" 
is the problem here.

> 
> This is something you could do using a hidden helper symbol like
> 
> config DRMA_ASPEED_GFX
>         bool "Aspeed display driver"
>         select DRM_WANT_CMA
> 
> config DRM_WANT_CMA
>         bool
>         help
>            Select this from any driver that benefits from CMA being enabled
> 
> config DMA_CMA
>         bool "Use CMA helpers for DRM"
>         default DRM_WANT_CMA
> 
>           Arnd
> 

That's precisely what I had first, with an additional "WANT_CMA" --  but 
looking at the number of such existing options (I was able to spot 1 !) 
I wondered if there is a better approach to achieve the same; "imply" 
sounded like a good candidate.

-- 
Thanks,

David / dhildenb



From jolsa at redhat.com  Thu Apr  8 13:06:37 2021
From: jolsa at redhat.com (Jiri Olsa)
Date: Thu, 8 Apr 2021 14:06:37 +0200
Subject: [PATCH v3 0/6] perf arm64 metricgroup support
In-Reply-To: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
References: <1617791570-165223-1-git-send-email-john.garry@huawei.com>
Message-ID: <YG7xzXjFzIr9lQlz@krava>

On Wed, Apr 07, 2021 at 06:32:44PM +0800, John Garry wrote:
> This series contains support to get basic metricgroups working for
> arm64 CPUs.
> 
> Initial support is added for HiSilicon hip08 platform.
> 
> Some sample usage on Huawei D06 board:
> 
>  $ ./perf list metric    
> 
> List of pre-defined events (to be used in -e): 
> 
> Metrics:     
> 
>   bp_misp_flush
>        [BP misp flush L3 topdown metric]
>   branch_mispredicts
>        [Branch mispredicts L2 topdown metric]
>   core_bound
>        [Core bound L2 topdown metric]
>   divider
>        [Divider L3 topdown metric]
>   exe_ports_util
>        [EXE ports util L3 topdown metric]
>   fetch_bandwidth_bound
>        [Fetch bandwidth bound L2 topdown metric]
>   fetch_latency_bound
>        [Fetch latency bound L2 topdown metric]
>   fsu_stall
>        [FSU stall L3 topdown metric]
>   idle_by_icache_miss
> 
> $ sudo ./perf stat -v -M core_bound sleep 1
> Using CPUID 0x00000000480fd010
> metric expr (exe_stall_cycle - (mem_stall_anyload + armv8_pmuv3_0 at event\=0x7005@)) / cpu_cycles for core_bound
> found event cpu_cycles
> found event armv8_pmuv3_0/event=0x7005/
> found event exe_stall_cycle
> found event mem_stall_anyload
> adding {cpu_cycles -> armv8_pmuv3_0/event=0x7001/
> mem_stall_anyload -> armv8_pmuv3_0/event=0x7004/
> Control descriptor is not initialized
> cpu_cycles: 989433 385050 385050
> armv8_pmuv3_0/event=0x7005/: 19207 385050 385050
> exe_stall_cycle: 900825 385050 385050
> mem_stall_anyload: 253516 385050 385050
> 
> Performance counter stats for 'sleep':
> 
> 989,433      cpu_cycles      #     0.63 core_bound
>   19,207      armv8_pmuv3_0/event=0x7005/
>  900,825      exe_stall_cycle
>  253,516      mem_stall_anyload
> 
>        0.000805809 seconds time elapsed
> 
>        0.000875000 seconds user
>        0.000000000 seconds sys
>        
> perf stat --topdown is not supported, as this requires the CPU PMU to
> expose (alias) events for the TopDown L1 metrics from sysfs, which arm 
> does not do. To get that to work, we probably need to make perf use the
> pmu-events cpumap to learn about those alias events.
> 
> Metric reuse support is added for pmu-events parse metric testcase.
> This had been broken on power9 recently:
> https://lore.kernel.org/lkml/20210324015418.GC8931 at li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com/ 
> 
> Differences to v2:
> - Add TB and RB tags (Thanks!)
> - Rename metricgroup__find_metric() from metricgroup_find_metric()
> - Change resolve_metric_simple() to rescan after any insert

Acked-by: Jiri Olsa <jolsa at redhat.com>

thanks,
jirka



From arnd at arndb.de  Thu Apr  8 13:12:33 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 14:12:33 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
Message-ID: <CAK8P3a3v2aY3CNLED5NkONJ6bS74WgLu=KCTwr1pKjnAmDeSjw@mail.gmail.com>

On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand <david at redhat.com> wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david at redhat.com> wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would be the right thing to do in the case here then to achieve the
> >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
> >>
> >> One approach could be to have for DMA_CMA
> >>
> >> default y if DRMA_ASPEED_GFX
> >>
> >> but it feels like the wrong way to tackle this.
> >
> > I'm still not sure what you are trying to achieve. Is the idea only to provide
> > a useful default for DMA_CMA depending on which drivers are enabled?
>
> "Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n)."
>
> Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
> set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
> e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
> setting -- even though it doesn't really always need it. Using "select"
> is the problem here.

I agree on the part of removing the 'select' if we don't need it. The
part I couldn't figure out was what the 'imply' is supposed to help with.
Most other users that added imply tried (and failed) to fix a build problem.

> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> >         bool "Aspeed display driver"
> >         select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> >         bool
> >         help
> >            Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> >         bool "Use CMA helpers for DRM"
> >         default DRM_WANT_CMA
> >
> >           Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" --  but
> looking at the number of such existing options (I was able to spot 1 !)
> I wondered if there is a better approach to achieve the same; "imply"
> sounded like a good candidate.

I can probably find a couple more, but regardless of how many others
exist, this would be a much clearer way of doing it than 'imply' since it
has none of the ambiguity and misuse problems.

I think the reason we don't see more is that generally speaking, those
defaults are widely ignored anyway. You almost always start out with
a defconfig file that contains everything you know you need, and then
you add bits to that. Having the default in any form only helps to
make that defconfig file one line shorter, while requiring other users
to add another line to turn it off when they do not want it.

         Arnd


From minyard at acm.org  Thu Apr  8 13:14:41 2021
From: minyard at acm.org (Corey Minyard)
Date: Thu, 8 Apr 2021 07:14:41 -0500
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
References: <20210319061952.145040-1-andrew@aj.id.au>
 <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
Message-ID: <20210408121441.GG7166@minyard.net>

On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote:
> Hi Corey,
> 
> On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote:
> > Hello,
> > 
> > This series is a bit of a mix of things, but its primary purpose is to
> > expose BMC KCS IPMI devices to userspace in a way that enables userspace
> > to talk to host firmware using protocols that are not IPMI.
> > 
> > v1 can be found here:
> > 
> > https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew at aj.id.au/
> > 
> > Changes in v2 include:
> > 
> > * A rebase onto v5.12-rc2
> > * Incorporation of off-list feedback on SerIRQ configuration from
> >   Chiawei
> > * Further validation on hardware for ASPEED KCS devices 2, 3 and 4
> > * Lifting the existing single-open constraint of the IPMI chardev
> > * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS
> >   binding to dt-schema
> > * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts
> >   property definition for the ASPEED KCS binding
> > 
> > A new chardev device is added whose implementation exposes the Input
> > Data Register (IDR), Output Data Register (ODR) and Status Register
> > (STR) via read() and write(), and implements poll() for event
> > monitoring.
> > 
> > The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in
> > a way which encoded the IPMI protocol in its behaviour. However, as
> > LPC[0] KCS devices give us bi-directional interrupts between the host
> > and a BMC with both a data and status byte, they are useful for purposes
> > beyond IPMI.
> > 
> > As a concrete example, libmctp[1] implements a vendor-defined MCTP[2]
> > binding using a combination of LPC Firmware cycles for bulk data
> > transfer and a KCS device via LPC IO cycles for out-of-band protocol
> > control messages[3]. This gives a throughput improvement over the
> > standard KCS binding[4] while continuing to exploit the ease of setup of
> > the LPC bus for early boot firmware on the host processor.
> > 
> > The series takes a bit of a winding path to achieve its aim:
> > 
> > 1. It begins with patches 1-5 put together by Chia-Wei, which I've
> > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
> > non-KCS LPC-related ASPEED device drivers in a way that enables the
> > SerIRQ patches at the end of the series. With Joel's review I'm hoping
> > these 5 can go through the aspeed tree, and that the rest can go through
> > the IPMI tree.
> > 
> > 2. Next, patches 6-13 fairly heavily refactor the KCS support in the
> > IPMI part of the tree, re-architecting things such that it's possible to
> > support multiple chardev implementations sitting on top of the ASPEED
> > and Nuvoton device drivers. However, the KCS code didn't really have
> > great separation of concerns as it stood, so even if we disregard the
> > multiple-chardev support I think the cleanups are worthwhile.
> > 
> > 3. Patch 14 adds some interrupt management capabilities to the KCS
> > device drivers in preparation for patch 16, which introduces the new
> > "raw" KCS device interface. I'm not stoked about the device name/path,
> > so if people are looking to bikeshed something then feel free to lay
> > into that.
> > 
> > 4. The remaining patches switch the ASPEED KCS devicetree binding to
> > dt-schema, add a new interrupt property to describe the SerIRQ behaviour
> > of the device and finally clean up Serial IRQ support in the ASPEED KCS
> > driver.
> > 
> > Rob: The dt-binding patches still come before the relevant driver
> > changes, I tried to keep the two close together in the series, hence the
> > bindings changes not being patches 1 and 2.
> > 
> > I've exercised the series under qemu with the rainier-bmc machine plus
> > additional patches for KCS support[5]. I've also substituted this series in
> > place of a hacky out-of-tree driver that we've been using for the
> > libmctp stack and successfully booted the host processor under our
> > internal full-platform simulation tools for a Rainier system.
> > 
> > Note that this work touches the Nuvoton driver as well as ASPEED's, but
> > I don't have the capability to test those changes or the IPMI chardev
> > path. Tested-by tags would be much appreciated if you can exercise one
> > or both.
> > 
> > Please review!
> 
> Unfortunately the cover letter got detached from the rest of the series.
> 
> Any chance you can take a look at the patches?

There were some minor concerns that were unanswered, and there really
was no review by others for many of the patches.

I would like this patch set, it makes some good cleanups.  But I would
like some more review and testing by others, if possible.  I'm fairly
sure it has already been done, it just needs to be documented.

-corey

> 
> https://lore.kernel.org/linux-arm-kernel/20210319062752.145730-1-andrew at aj.id.au/
> 
> Cheers,
> 
> Andrew


From thierry.reding at gmail.com  Thu Apr  8 13:22:32 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 8 Apr 2021 14:22:32 +0200
Subject: [PATCH v2 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210408075920.rfrcqxec2yvepj3y@pengutronix.de>
References: <20210212131910.557581-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212131910.557581-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212164144.wcvy7jkxmrysqxux@pengutronix.de>
 <20210407231548.4paov2fb33cpxxui@toshiba.co.jp>
 <20210408075920.rfrcqxec2yvepj3y@pengutronix.de>
Message-ID: <YG71iGoLHDxNgke4@orome.fritz.box>

On Thu, Apr 08, 2021 at 09:59:20AM +0200, Uwe Kleine-K?nig wrote:
> Hello Nobuhiro,
> 
> On Thu, Apr 08, 2021 at 08:15:48AM +0900, Nobuhiro Iwamatsu wrote:
> > > > +	/*
> > > > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > > > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > > > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > > > +	 * way the hardware switches atomically from the old setting to the new.
> > > > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > > > +	 * at low level at all times.
> > > 
> > > Did you just copy my optimal description or is your hardware really that
> > > nice?
> > 
> > Yes, this hardware works as you wrote.
> > And I added about the state if the sinnal when this hardware disabled.
> > 
> > > 
> > > Do you know scripts/checkpatch.pl? I bet it will tell you to limit your
> > > lines to approx. 80 chars where sensible.
> > 
> > Yes, I know. I ran scripts/checkpatch.pl before send patch.
> > I understand that the number of characters per line has been changed to
> > 100 characters. Does the pwm driver recommend 80 characters?
> 
> For free-text comments I'd still recommend 80, yes. For code lines I'd
> be indeed more lax, as a line break in function calls reduces readability.

Let's not start making any special rules. It becomes impossible for
anyone to keep track of those. If checkpatch doesn't complain for
comments that exceed 80 characters, I will not reject based on that.

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/20210408/c325a134/attachment-0001.sig>

From dafna.hirschfeld at collabora.com  Thu Apr  8 13:28:42 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Thu,  8 Apr 2021 14:28:42 +0200
Subject: [PATCH] iommu/mediatek: always enable the clk on resume
Message-ID: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>

In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:

[    1.586104] infra_m4u already disabled
[    1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[    1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[    1.598108] Modules linked in:
[    1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[    1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[    1.617487] Hardware name: Google Elm (DT)
[    1.617491] Workqueue: pm pm_runtime_work
[    1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)

[    1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[    1.659297] pc : clk_core_disable+0xb0/0xb8
[    1.663475] lr : clk_core_disable+0xb0/0xb8
[    1.667652] sp : ffff800011b9bbe0
[    1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[    1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[    1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[    1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[    1.692189] x21: 000000000000000a x20: ffff0000c0048500
[    1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[    1.702804] x17: 0000000000000000 x16: 0000000000000000
[    1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[    1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[    1.718727] x11: 0720072007200720 x10: 0720072007200720
[    1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[    1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[    1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[    1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[    1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[    1.750572] Call trace:
[    1.753010]  clk_core_disable+0xb0/0xb8
[    1.756840]  clk_core_disable_lock+0x24/0x40
[    1.761105]  clk_disable+0x20/0x30
[    1.764501]  mtk_iommu_runtime_suspend+0x88/0xa8
[    1.769114]  pm_generic_runtime_suspend+0x2c/0x48
[    1.773815]  __rpm_callback+0xe0/0x178
[    1.777559]  rpm_callback+0x24/0x88
[    1.781041]  rpm_suspend+0xdc/0x470
[    1.784523]  rpm_idle+0x12c/0x170
[    1.787831]  pm_runtime_work+0xa8/0xc0
[    1.791573]  process_one_work+0x1e8/0x360
[    1.795580]  worker_thread+0x44/0x478
[    1.799237]  kthread+0x150/0x158
[    1.802460]  ret_from_fork+0x10/0x30
[    1.806034] ---[ end trace 82402920ef64573b ]---
[    1.810728] ------------[ cut here ]------------

In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume.

Fixes: commit c0b57581b73b ("iommu/mediatek: Add power-domain operation")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld at collabora.com>
---
 drivers/iommu/mtk_iommu.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd..e168a682806a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -688,13 +688,6 @@ static const struct iommu_ops mtk_iommu_ops = {
 static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 {
 	u32 regval;
-	int ret;
-
-	ret = clk_prepare_enable(data->bclk);
-	if (ret) {
-		dev_err(data->dev, "Failed to enable iommu bclk(%d)\n", ret);
-		return ret;
-	}
 
 	if (data->plat_data->m4u_plat == M4U_MT8173) {
 		regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
@@ -760,7 +753,6 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 	if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
 			     dev_name(data->dev), (void *)data)) {
 		writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
-		clk_disable_unprepare(data->bclk);
 		dev_err(data->dev, "Failed @ IRQ-%d Request\n", data->irq);
 		return -ENODEV;
 	}
@@ -977,14 +969,19 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
 	void __iomem *base = data->base;
 	int ret;
 
-	/* Avoid first resume to affect the default value of registers below. */
-	if (!m4u_dom)
-		return 0;
 	ret = clk_prepare_enable(data->bclk);
 	if (ret) {
 		dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
 		return ret;
 	}
+
+	/*
+	 * Uppon first resume, only enable the clk and return, since the values of the
+	 * registers are not yet set.
+	 */
+	if (!m4u_dom)
+		return 0;
+
 	writel_relaxed(reg->wr_len_ctrl, base + REG_MMU_WR_LEN_CTRL);
 	writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
 	writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
-- 
2.17.1



From miquel.raynal at bootlin.com  Thu Apr  8 13:46:10 2021
From: miquel.raynal at bootlin.com (Miquel Raynal)
Date: Thu, 8 Apr 2021 14:46:10 +0200
Subject: [PATCH 3/3] mtd: phram: Fix error return code in phram_setup()
In-Reply-To: <20210408111514.1011020-4-yukuai3@huawei.com>
References: <20210408111514.1011020-1-yukuai3@huawei.com>
 <20210408111514.1011020-4-yukuai3@huawei.com>
Message-ID: <20210408144610.0c0686ae@xps13>

Hi Yu,

Yu Kuai <yukuai3 at huawei.com> wrote on Thu, 8 Apr 2021 19:15:14 +0800:

> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
> ---
>  drivers/mtd/devices/phram.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
> index 5b04ae6c3057..6ed6c51fac69 100644
> --- a/drivers/mtd/devices/phram.c
> +++ b/drivers/mtd/devices/phram.c
> @@ -270,6 +270,7 @@ static int phram_setup(const char *val)
>  	if (len == 0 || erasesize == 0 || erasesize > len
>  	    || erasesize > UINT_MAX || rem) {
>  		parse_err("illegal erasesize or len\n");
> +		ret = -EINVAL;
>  		goto error;
>  	}
>  

It looks like you're doing the opposite of what you say.

Thanks,
Miqu?l


From michael at walle.cc  Thu Apr  8 13:48:16 2021
From: michael at walle.cc (Michael Walle)
Date: Thu, 08 Apr 2021 14:48:16 +0200
Subject: [RFC PATCH 2/6] mtd: spi-nor: core: consolidate read op creation
In-Reply-To: <20210311191216.7363-3-p.yadav@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-3-p.yadav@ti.com>
Message-ID: <22d1042e061e355b0ddd122ef1228535@walle.cc>

Am 2021-03-11 20:12, schrieb Pratyush Yadav:
> Currently the spi_mem_op to read from the flash is used in two places:
> spi_nor_create_read_dirmap() and spi_nor_spimem_read_data(). In a later
> commit this number will increase to three. Instead of repeating the 
> same
> code thrice, add a function that returns a template of the read op. The
> callers can then fill in the details like address, data length, data
> buffer location.
> 
> Signed-off-by: Pratyush Yadav <p.yadav at ti.com>

Reviewed-by: Michael Walle <michael at walle.cc>


From linus.walleij at linaro.org  Thu Apr  8 13:49:51 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 8 Apr 2021 14:49:51 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
Message-ID: <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>

On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:

> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> >         bool "Aspeed display driver"
> >         select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> >         bool
> >         help
> >            Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> >         bool "Use CMA helpers for DRM"
> >         default DRM_WANT_CMA
> >
> >           Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" --  but
> looking at the number of such existing options (I was able to spot 1 !)

If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:

drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig

certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.

Yours,
Linus Walleij


From john.garry at huawei.com  Thu Apr  8 13:55:02 2021
From: john.garry at huawei.com (John Garry)
Date: Thu, 8 Apr 2021 13:55:02 +0100
Subject: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <20210408100157.000062f0@Huawei.com>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
 <1617788943-52722-2-git-send-email-liuqi115@huawei.com>
 <20210407204004.GB16011@willie-the-truck>
 <20210408100157.000062f0@Huawei.com>
Message-ID: <16a7a3f8-82b5-a113-57c0-a9d575c649bd@huawei.com>

On 08/04/2021 10:01, Jonathan Cameron wrote:
> On Wed, 7 Apr 2021 21:40:05 +0100
> Will Deacon <will at kernel.org> wrote:
> 
>> On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
>>> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
>>> to sample bandwidth, latency, buffer occupation etc.
>>>
>>> Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
>>> registered as a pmu in /sys/bus/event_source/devices, so users can
>>> select target PMU, and use filter to do further sets.
>>>
>>> Filtering options contains:
>>> event        - select the event.
>>> subevent     - select the subevent.
>>> port         - select target root ports. Information of root ports
>>>                 are shown under sysfs.
>>> bdf           - select requester_id of target EP device.
>>> trig_len     - set trigger condition for starting event statistics.
>>> trigger_mode - set trigger mode. 0 means starting to statistic when
>>>                 bigger than trigger condition, and 1 means smaller.
>>> thr_len      - set threshold for statistics.
>>> thr_mode     - set threshold mode. 0 means count when bigger than
>>>                 threshold, and 1 means smaller.
>>>
>>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
>>
>> Do you have a link to this review, please?
> 
> Internal review, so drop the tag.
> 
> Jonathan

Hi Will,

Are you implying that you would rather that any review for these drivers 
is done in public on the lists?

Cheers,
John


From maz at kernel.org  Thu Apr  8 14:05:55 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 14:05:55 +0100
Subject: [PATCH v2 3/3] arm64: Allow nVHE impaired CPUs to boot without
 CONFIG_ARM64_VHE
In-Reply-To: <20210408105823.GB17280@willie-the-truck>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-4-maz@kernel.org>
 <20210407211848.GE16198@willie-the-truck>
 <8474e539259346842178f51a26d59d74@kernel.org>
 <20210408105823.GB17280@willie-the-truck>
Message-ID: <8735w1orik.wl-maz@kernel.org>

On Thu, 08 Apr 2021 11:58:23 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> On Thu, Apr 08, 2021 at 11:31:42AM +0100, Marc Zyngier wrote:
> > On 2021-04-07 22:18, Will Deacon wrote:
> > > On Tue, Mar 30, 2021 at 06:39:47PM +0100, Marc Zyngier wrote:
> > > > CPUs stuck in VHE mode need some additional care if the kernel
> > > > is compiled without CONFIG_ARM64_VHE.
> > > > 
> > > > Treat this case as another version of a mismatched boot, and
> > > > prevent KVM from being initialised. The machine will boot in
> > > > some bizarre state, using TPIDR_EL1 instead of TPIDR_EL2, but
> > > > otherwise be functional.
> > > > 
> > > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > > ---
> > > >  arch/arm64/include/asm/virt.h | 18 +++++++++++++-----
> > > >  arch/arm64/kvm/va_layout.c    |  9 +++++++++
> > > >  2 files changed, 22 insertions(+), 5 deletions(-)
> > > 
> > > Hmm, I think we definitely need _something_ here, but it's a bit
> > > annoying
> > > to put ourselves into this weird state just for the sake of one stupid
> > > machine.
> > 
> > Which is why I'm not keen at all on this patch, and I'm happy to see
> > the machine die a painful death. We really can't be blamed for terminally
> > buggy HW, which the M1 obviously is.
> 
> Perhaps, but it's not clear at all how the problem manifests and so we
> _will_ be blamed when things go wonky, especially as the real culprits
> all seem to be hiding...
> 
> > > What if we dropped CONFIG_ARM64_VHE and made the VHE code unconditional
> > > instead? Is there a good reason to allow it to be disabled nowadays?
> > 
> > What do we do for the other camp, aka people really wanting to run nVHE
> > without any command line parameter? I can't see why you'd want to do
> > that, but hey, that's only me.
> 
> They can pass the command-line parameter, no? If we ever get CMDLINE_EXTEND
> support back, they could even add it in there!

My point was that they could do it *without* the parameter. No skin
off my nose anyway.

> 
> > I'd be quite happy to see CONFIG_ARM64_VHE go though. Let me know if you
> > want a patch doing that instead.
> 
> Yes please.

Right, let me repost the series then.

	M.

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


From maz at kernel.org  Thu Apr  8 14:10:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  8 Apr 2021 14:10:09 +0100
Subject: [PATCH v3 2/3] arm64: Cope with CPUs stuck in VHE mode
In-Reply-To: <20210408131010.1109027-1-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
Message-ID: <20210408131010.1109027-3-maz@kernel.org>

It seems that the CPUs part of the SoC known as Apple M1 have the
terrible habit of being stuck with HCR_EL2.E2H==1, in violation
of the architecture.

Try and work around this deplorable state of affairs by detecting
the stuck bit early and short-circuit the nVHE dance. Additional
filtering code ensures that attempts at switching to nVHE from
the command-line are also ignored.

It is still unknown whether there are many more such nuggets
to be found...

Reported-by: Hector Martin <marcan at marcan.st>
Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kernel/head.S           | 39 +++++++++++++++++++++++++++---
 arch/arm64/kernel/hyp-stub.S       |  8 +++---
 arch/arm64/kernel/idreg-override.c | 13 +++++++++-
 3 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 840bda1869e9..96873dfa67fd 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -477,14 +477,13 @@ EXPORT_SYMBOL(kimage_vaddr)
  * booted in EL1 or EL2 respectively.
  */
 SYM_FUNC_START(init_kernel_el)
-	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
-	msr	sctlr_el1, x0
-
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
 	b.eq	init_el2
 
 SYM_INNER_LABEL(init_el1, SYM_L_LOCAL)
+	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
+	msr	sctlr_el1, x0
 	isb
 	mov_q	x0, INIT_PSTATE_EL1
 	msr	spsr_el1, x0
@@ -504,9 +503,43 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
 	msr	vbar_el2, x0
 	isb
 
+	/*
+	 * Fruity CPUs seem to have HCR_EL2.E2H set to RES1,
+	 * making it impossible to start in nVHE mode. Is that
+	 * compliant with the architecture? Absolutely not!
+	 */
+	mrs	x0, hcr_el2
+	and	x0, x0, #HCR_E2H
+	cbz	x0, 1f
+
+	/* Switching to VHE requires a sane SCTLR_EL1 as a start */
+	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
+	msr_s	SYS_SCTLR_EL12, x0
+
+	/*
+	 * Force an eret into a helper "function", and let it return
+	 * to our original caller... This makes sure that we have
+	 * initialised the basic PSTATE state.
+	 */
+	mov	x0, #INIT_PSTATE_EL2
+	msr	spsr_el1, x0
+	adr	x0, __cpu_stick_to_vhe
+	msr	elr_el1, x0
+	eret
+
+1:
+	mov_q	x0, INIT_SCTLR_EL1_MMU_OFF
+	msr	sctlr_el1, x0
+
 	msr	elr_el2, lr
 	mov	w0, #BOOT_CPU_MODE_EL2
 	eret
+
+__cpu_stick_to_vhe:
+	mov	x0, #HVC_VHE_RESTART
+	hvc	#0
+	mov	x0, #BOOT_CPU_MODE_EL2
+	ret
 SYM_FUNC_END(init_kernel_el)
 
 /*
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 5eccbd62fec8..9c9b4d8fc395 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -27,12 +27,12 @@ SYM_CODE_START(__hyp_stub_vectors)
 	ventry	el2_fiq_invalid			// FIQ EL2t
 	ventry	el2_error_invalid		// Error EL2t
 
-	ventry	el2_sync_invalid		// Synchronous EL2h
+	ventry	elx_sync			// Synchronous EL2h
 	ventry	el2_irq_invalid			// IRQ EL2h
 	ventry	el2_fiq_invalid			// FIQ EL2h
 	ventry	el2_error_invalid		// Error EL2h
 
-	ventry	el1_sync			// Synchronous 64-bit EL1
+	ventry	elx_sync			// Synchronous 64-bit EL1
 	ventry	el1_irq_invalid			// IRQ 64-bit EL1
 	ventry	el1_fiq_invalid			// FIQ 64-bit EL1
 	ventry	el1_error_invalid		// Error 64-bit EL1
@@ -45,7 +45,7 @@ SYM_CODE_END(__hyp_stub_vectors)
 
 	.align 11
 
-SYM_CODE_START_LOCAL(el1_sync)
+SYM_CODE_START_LOCAL(elx_sync)
 	cmp	x0, #HVC_SET_VECTORS
 	b.ne	1f
 	msr	vbar_el2, x1
@@ -71,7 +71,7 @@ SYM_CODE_START_LOCAL(el1_sync)
 
 9:	mov	x0, xzr
 	eret
-SYM_CODE_END(el1_sync)
+SYM_CODE_END(elx_sync)
 
 // nVHE? No way! Give me the real thing!
 SYM_CODE_START_LOCAL(mutate_to_vhe)
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index be92fcd319a1..e628c8ce1ffe 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -29,11 +29,22 @@ struct ftr_set_desc {
 	} 				fields[];
 };
 
+static bool __init mmfr1_vh_filter(u64 val)
+{
+	/*
+	 * If we ever reach this point while running VHE, we're
+	 * guaranteed to be on one of these funky, VHE-stuck CPUs. If
+	 * the user was trying to force nVHE on us, proceed with
+	 * attitude adjustment.
+	 */
+	return !(is_kernel_in_hyp_mode() && val == 0);
+}
+
 static const struct ftr_set_desc mmfr1 __initconst = {
 	.name		= "id_aa64mmfr1",
 	.override	= &id_aa64mmfr1_override,
 	.fields		= {
-	        { "vh", ID_AA64MMFR1_VHE_SHIFT },
+		{ "vh", ID_AA64MMFR1_VHE_SHIFT, mmfr1_vh_filter },
 		{}
 	},
 };
-- 
2.29.2



From maz at kernel.org  Thu Apr  8 14:10:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  8 Apr 2021 14:10:07 +0100
Subject: [PATCH v3 0/3] arm64: Dealing with VHE-only CPUs
Message-ID: <20210408131010.1109027-1-maz@kernel.org>

This short series is a rewrite of [0] after some reviewing from
Will. It simplifies the esoteric "stay at EL2" path, and move the
feature override code where it actually belongs, allowing us to tell
the user that no, nVHE isn't a thing on these system.

The last patch rids us of CONFIG_ARM64_VHE, which has been the default
for longer than I can remember.

This allows the infamous M1 to boot (tested on a M1 Mini).

Note: the last patch will conflict with the KVM SVE series, so I'd
like to take that patch (or the series) via the KVM tree to avoid
extra moaning^Wfriction.

* From v2 [2]:
   - Fixed typos and spacing issues
   - Dropped the mVHE on VHE patch
   - Added a patch removing the CONFIG_ARM64_VHE option altogether
   - Collected Ack from Will

* From v1 [1]:
  - added a comment describing the mapping various states
    the override mask/val tuple can describe
  - added a patch to prevent KVM from initialising, treating
    the lack of CONFIG_ARM64_VHE as a mismatched boot

[0] https://lore.kernel.org/r/20210304213902.83903-2-marcan at marcan.st
[1] https://lore.kernel.org/r/20210325124721.941182-1-maz at kernel.org
[2] https://lore.kernel.org/r/20210330173947.999859-1-maz at kernel.org

Marc Zyngier (3):
  arm64: cpufeature: Allow early filtering of feature override
  arm64: Cope with CPUs stuck in VHE mode
  arm64: Get rid of CONFIG_ARM64_VHE

 .../admin-guide/kernel-parameters.txt         |  3 +-
 arch/arm64/Kconfig                            | 20 ----------
 arch/arm64/include/asm/cpufeature.h           | 17 ++++++++
 arch/arm64/kernel/cpufeature.c                | 10 +++--
 arch/arm64/kernel/head.S                      | 39 +++++++++++++++++--
 arch/arm64/kernel/hyp-stub.S                  | 10 ++---
 arch/arm64/kernel/idreg-override.c            | 26 ++++++++++++-
 7 files changed, 89 insertions(+), 36 deletions(-)

-- 
2.29.2



From maz at kernel.org  Thu Apr  8 14:10:08 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  8 Apr 2021 14:10:08 +0100
Subject: [PATCH v3 1/3] arm64: cpufeature: Allow early filtering of feature
 override
In-Reply-To: <20210408131010.1109027-1-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
Message-ID: <20210408131010.1109027-2-maz@kernel.org>

Some CPUs are broken enough that some overrides need to be rejected
at the earliest opportunity. In some cases, that's right at cpu
feature override time.

Provide the necessary infrastructure to filter out overrides,
and to report such filtered out overrides to the core cpufeature code.

Acked-by: Will Deacon <will at kernel.org>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/include/asm/cpufeature.h | 17 +++++++++++++++++
 arch/arm64/kernel/cpufeature.c      |  6 ++++++
 arch/arm64/kernel/idreg-override.c  | 13 +++++++++++++
 3 files changed, 36 insertions(+)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 61177bac49fa..338840c00e8e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -63,6 +63,23 @@ struct arm64_ftr_bits {
 	s64		safe_val; /* safe value for FTR_EXACT features */
 };
 
+/*
+ * Describe the early feature override to the core override code:
+ *
+ * @val			Values that are to be merged into the final
+ *			sanitised value of the register. Only the bitfields
+ *			set to 1 in @mask are valid
+ * @mask		Mask of the features that are overridden by @val
+ *
+ * A @mask field set to full-1 indicates that the corresponding field
+ * in @val is a valid override.
+ *
+ * A @mask field set to full-0 with the corresponding @val field set
+ * to full-0 denotes that this field has no override
+ *
+ * A @mask field set to full-0 with the corresponding @val field set
+ * to full-1 denotes thath this field has an invalid override.
+ */
 struct arm64_ftr_override {
 	u64		val;
 	u64		mask;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 066030717a4c..6de15deaa912 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -809,6 +809,12 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
 					reg->name,
 					ftrp->shift + ftrp->width - 1,
 					ftrp->shift, str, tmp);
+		} else if ((ftr_mask & reg->override->val) == ftr_mask) {
+			reg->override->val &= ~ftr_mask;
+			pr_warn("%s[%d:%d]: impossible override, ignored\n",
+				reg->name,
+				ftrp->shift + ftrp->width - 1,
+				ftrp->shift);
 		}
 
 		val = arm64_ftr_set_value(ftrp, val, ftr_new);
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 83f1c4b92095..be92fcd319a1 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -25,6 +25,7 @@ struct ftr_set_desc {
 	struct {
 		char			name[FTR_DESC_FIELD_LEN];
 		u8			shift;
+		bool			(*filter)(u64 val);
 	} 				fields[];
 };
 
@@ -124,6 +125,18 @@ static void __init match_options(const char *cmdline)
 			if (find_field(cmdline, regs[i], f, &v))
 				continue;
 
+			/*
+			 * If an override gets filtered out, advertise
+			 * it by setting the value to 0xf, but
+			 * clearing the mask... Yes, this is fragile.
+			 */
+			if (regs[i]->fields[f].filter &&
+			    !regs[i]->fields[f].filter(v)) {
+				regs[i]->override->val  |= mask;
+				regs[i]->override->mask &= ~mask;
+				continue;
+			}
+
 			regs[i]->override->val  &= ~mask;
 			regs[i]->override->val  |= (v << shift) & mask;
 			regs[i]->override->mask |= mask;
-- 
2.29.2



From maz at kernel.org  Thu Apr  8 14:10:10 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu,  8 Apr 2021 14:10:10 +0100
Subject: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE
In-Reply-To: <20210408131010.1109027-1-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
Message-ID: <20210408131010.1109027-4-maz@kernel.org>

CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
and has been enabled by default for almost all that time.

Given that newer systems that are VHE capable are finally becoming
available, and that some systems are even incapable of not running VHE,
drop the configuration altogether.

Anyone willing to stick to non-VHE on VHE hardware for obscure
reasons should use the 'kvm-arm.mode=nvhe' command-line option.

Suggested-by: Will Deacon <will at kernel.org>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 .../admin-guide/kernel-parameters.txt         |  3 +--
 arch/arm64/Kconfig                            | 20 -------------------
 arch/arm64/kernel/cpufeature.c                |  4 ----
 arch/arm64/kernel/hyp-stub.S                  |  2 --
 4 files changed, 1 insertion(+), 28 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..18f8bb3024f4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2279,8 +2279,7 @@
 				   state is kept private from the host.
 				   Not valid if the kernel is running in EL2.
 
-			Defaults to VHE/nVHE based on hardware support and
-			the value of CONFIG_ARM64_VHE.
+			Defaults to VHE/nVHE based on hardware support.
 
 	kvm-arm.vgic_v3_group0_trap=
 			[KVM,ARM] Trap guest accesses to GICv3 group-0
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5656e7aacd69..e9fbb0b45793 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1416,19 +1416,6 @@ config ARM64_USE_LSE_ATOMICS
 	  built with binutils >= 2.25 in order for the new instructions
 	  to be used.
 
-config ARM64_VHE
-	bool "Enable support for Virtualization Host Extensions (VHE)"
-	default y
-	help
-	  Virtualization Host Extensions (VHE) allow the kernel to run
-	  directly at EL2 (instead of EL1) on processors that support
-	  it. This leads to better performance for KVM, as they reduce
-	  the cost of the world switch.
-
-	  Selecting this option allows the VHE feature to be detected
-	  at runtime, and does not affect processors that do not
-	  implement this feature.
-
 endmenu
 
 menu "ARMv8.2 architectural features"
@@ -1684,7 +1671,6 @@ endmenu
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
-	depends on !KVM || ARM64_VHE
 	help
 	  The Scalable Vector Extension (SVE) is an extension to the AArch64
 	  execution state which complements and extends the SIMD functionality
@@ -1713,12 +1699,6 @@ config ARM64_SVE
 	  booting the kernel.  If unsure and you are not observing these
 	  symptoms, you should assume that it is safe to say Y.
 
-	  CPUs that support SVE are architecturally required to support the
-	  Virtualization Host Extensions (VHE), so the kernel makes no
-	  provision for supporting SVE alongside KVM without VHE enabled.
-	  Thus, you will need to enable CONFIG_ARM64_VHE if you want to support
-	  KVM in the same kernel image.
-
 config ARM64_MODULE_PLTS
 	bool "Use PLTs to allow module memory to spill over into vmalloc area"
 	depends on MODULES
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 6de15deaa912..fa6023ac3548 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1623,7 +1623,6 @@ int get_cpu_with_amu_feat(void)
 }
 #endif
 
-#ifdef CONFIG_ARM64_VHE
 static bool runs_at_el2(const struct arm64_cpu_capabilities *entry, int __unused)
 {
 	return is_kernel_in_hyp_mode();
@@ -1642,7 +1641,6 @@ static void cpu_copy_el2regs(const struct arm64_cpu_capabilities *__unused)
 	if (!alternative_is_applied(ARM64_HAS_VIRT_HOST_EXTN))
 		write_sysreg(read_sysreg(tpidr_el1), tpidr_el2);
 }
-#endif
 
 static void cpu_has_fwb(const struct arm64_cpu_capabilities *__unused)
 {
@@ -1845,7 +1843,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
 		.matches = has_no_hw_prefetch,
 	},
-#ifdef CONFIG_ARM64_VHE
 	{
 		.desc = "Virtualization Host Extensions",
 		.capability = ARM64_HAS_VIRT_HOST_EXTN,
@@ -1853,7 +1850,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = runs_at_el2,
 		.cpu_enable = cpu_copy_el2regs,
 	},
-#endif	/* CONFIG_ARM64_VHE */
 	{
 		.desc = "32-bit EL0 Support",
 		.capability = ARM64_HAS_32BIT_EL0,
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 9c9b4d8fc395..74ad3db061d1 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -224,7 +224,6 @@ SYM_FUNC_END(__hyp_reset_vectors)
  * Entry point to switch to VHE if deemed capable
  */
 SYM_FUNC_START(switch_to_vhe)
-#ifdef CONFIG_ARM64_VHE
 	// Need to have booted at EL2
 	adr_l	x1, __boot_cpu_mode
 	ldr	w0, [x1]
@@ -240,6 +239,5 @@ SYM_FUNC_START(switch_to_vhe)
 	mov	x0, #HVC_VHE_RESTART
 	hvc	#0
 1:
-#endif
 	ret
 SYM_FUNC_END(switch_to_vhe)
-- 
2.29.2



From maz at kernel.org  Thu Apr  8 14:11:34 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 14:11:34 +0100
Subject: [PATCH v2 1/3] arm64: cpufeature: Allow early filtering of
 feature override
In-Reply-To: <2891836d-c208-a1ea-3119-006e7f3135b7@marcan.st>
References: <20210330173947.999859-1-maz@kernel.org>
 <20210330173947.999859-2-maz@kernel.org>
 <2891836d-c208-a1ea-3119-006e7f3135b7@marcan.st>
Message-ID: <87zgy8or95.wl-maz@kernel.org>

On Thu, 08 Apr 2021 12:13:44 +0100,
Hector Martin <marcan at marcan.st> wrote:
> 
> On 31/03/2021 02.39, Marc Zyngier wrote:
> > + * @mask		Mask of the features that are overriden by @val
> 
> FYI, I checkpatched this by accident and it pointed out a typo
> ('overridden').

My prefered fix would be not to run checkpatch, but since you found
it... ;-)

> It also complained about a tab thing in the next patch (the last hunk
> has a tab followed by 8 spaces), though that was just carried over
> from the line before the patch.

Fixed both in v3 which I just posted.

Thanks,

	M.

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


From maz at kernel.org  Thu Apr  8 14:14:18 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 14:14:18 +0100
Subject: [PATCH] KVM: arm64: Clarify vcpu reset behaviour
In-Reply-To: <20210408105334.GA17280@willie-the-truck>
References: <20210406125841.1077079-1-maz@kernel.org>
 <20210407203537.GA16011@willie-the-truck>
 <bbb4d999fe0bc9762c930dafa56a8847@kernel.org>
 <20210408105334.GA17280@willie-the-truck>
Message-ID: <87y2dsor4l.wl-maz@kernel.org>

On Thu, 08 Apr 2021 11:53:35 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> On Thu, Apr 08, 2021 at 11:36:34AM +0100, Marc Zyngier wrote:
> > On 2021-04-07 21:35, Will Deacon wrote:
> > > On Tue, Apr 06, 2021 at 01:58:41PM +0100, Marc Zyngier wrote:
> > > > Although the KVM_ARM_VCPU_INIT documentation mention that the
> > > > registers are reset to their "initial values", it doesn't
> > > > describe what these values are.
> > > > 
> > > > Describe this state explicitly.
> > > > 
> > > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > > ---
> > > >  Documentation/virt/kvm/api.rst | 10 ++++++++++
> > > >  1 file changed, 10 insertions(+)
> > > > 
> > > > diff --git a/Documentation/virt/kvm/api.rst
> > > > b/Documentation/virt/kvm/api.rst
> > > > index 38e327d4b479..e2237e4e10ba 100644
> > > > --- a/Documentation/virt/kvm/api.rst
> > > > +++ b/Documentation/virt/kvm/api.rst
> > > > @@ -3115,6 +3115,16 @@ optional features it should have. ?This will
> > > > cause a reset of the cpu
> > > >  registers to their initial values. ?If this is not called, KVM_RUN
> > > > will
> > > >  return ENOEXEC for that vcpu.
> > > > 
> > > > +The initial values are defined as:
> > > > +	- Processor state:
> > > > +		* AArch64: EL1h, D, A, I and F bits set
> > > > +		* Aarch32: SVC, D, A, I and F bits set
> > > 
> > > nit, but capitalisation should be "AArch32"
> > > 
> > > Is "SVC" sufficient, or do we also need to describe Arm vs Thumb?
> > 
> > SVC doesn't describe the instruction set, but we don't say that PSR.T
> > is set, which implies ARM.
> 
> Ah yes, thanks.
> 
> > I can add something like "All other bits are set to 0", if that makes it
> > clearer.
> 
> I think that would be worth adding. With that and the minor typo fix:
> 
> Acked-by: Will Deacon <will at kernel.org>

Now fixed.

Thanks,

	M.

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


From arnd at arndb.de  Thu Apr  8 14:19:19 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 15:19:19 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
Message-ID: <CAK8P3a2Wu7tT-YajfdXSSVvg5MYMEnEy3APJ83DcLeJdGkkSrQ@mail.gmail.com>

On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > >         bool "Aspeed display driver"
> > >         select DRM_WANT_CMA
> > >
> > > config DRM_WANT_CMA
> > >         bool
> > >         help
> > >            Select this from any driver that benefits from CMA being enabled
> > >
> > > config DMA_CMA
> > >         bool "Use CMA helpers for DRM"
> > >         default DRM_WANT_CMA
> > >
> > >           Arnd
> > >
> >
> > That's precisely what I had first, with an additional "WANT_CMA" --  but
> > looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.

Are there any that don't select either of the helpers and
still want CMA? If not, it would be easy to just add

   default  DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER

and skipt the extra symbol.

        Arnd


From clare.chenhui at huawei.com  Thu Apr  8 14:21:50 2021
From: clare.chenhui at huawei.com (Chen Hui)
Date: Thu, 8 Apr 2021 21:21:50 +0800
Subject: [PATCH -next] drm/mediatek: Remove redundant dev_err calls
Message-ID: <20210408132150.200583-1-clare.chenhui@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err calls to avoid redundant
error messages.

Signed-off-by: Chen Hui <clare.chenhui at huawei.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 +---
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 63f411ab393b..d9b6f3b100dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -112,10 +112,8 @@ static int mtk_disp_color_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	priv->regs = devm_ioremap_resource(dev, res);
-	if (IS_ERR(priv->regs)) {
-		dev_err(dev, "failed to ioremap color\n");
+	if (IS_ERR(priv->regs))
 		return PTR_ERR(priv->regs);
-	}
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	ret = cmdq_dev_get_client_reg(dev, &priv->cmdq_reg, 0);
 	if (ret)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 3ebf91e0ab41..ad5df3f9d477 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -146,10 +146,8 @@ static int mtk_disp_gamma_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	priv->regs = devm_ioremap_resource(dev, res);
-	if (IS_ERR(priv->regs)) {
-		dev_err(dev, "failed to ioremap gamma\n");
+	if (IS_ERR(priv->regs))
 		return PTR_ERR(priv->regs);
-	}
 
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	ret = cmdq_dev_get_client_reg(dev, &priv->cmdq_reg, 0);
-- 
2.17.1



From yukuai3 at huawei.com  Thu Apr  8 14:26:09 2021
From: yukuai3 at huawei.com (yukuai (C))
Date: Thu, 8 Apr 2021 21:26:09 +0800
Subject: [PATCH 3/3] mtd: phram: Fix error return code in phram_setup()
In-Reply-To: <20210408144610.0c0686ae@xps13>
References: <20210408111514.1011020-1-yukuai3@huawei.com>
 <20210408111514.1011020-4-yukuai3@huawei.com> <20210408144610.0c0686ae@xps13>
Message-ID: <cc02de9c-6315-3fa6-4b0a-4287b2713484@huawei.com>

On 2021/04/08 20:46, Miquel Raynal wrote:
> Hi Yu,
> 
> Yu Kuai <yukuai3 at huawei.com> wrote on Thu, 8 Apr 2021 19:15:14 +0800:
> 
>> Fix to return a negative error code from the error handling
>> case instead of 0, as done elsewhere in this function.
>>
>> Reported-by: Hulk Robot <hulkci at huawei.com>
>> Signed-off-by: Yu Kuai <yukuai3 at huawei.com>
>> ---
>>   drivers/mtd/devices/phram.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
>> index 5b04ae6c3057..6ed6c51fac69 100644
>> --- a/drivers/mtd/devices/phram.c
>> +++ b/drivers/mtd/devices/phram.c
>> @@ -270,6 +270,7 @@ static int phram_setup(const char *val)
>>   	if (len == 0 || erasesize == 0 || erasesize > len
>>   	    || erasesize > UINT_MAX || rem) {
>>   		parse_err("illegal erasesize or len\n");
>> +		ret = -EINVAL;
>>   		goto error;
>>   	}
>>   
> 
> It looks like you're doing the opposite of what you say.
> 
Hi,

sorry about that, I misunderstood 'fix to'.

Thanks
Yu Kuai
> Thanks,
> Miqu?l
> .
> 


From will at kernel.org  Thu Apr  8 14:28:05 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 14:28:05 +0100
Subject: [PATCH 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <16a7a3f8-82b5-a113-57c0-a9d575c649bd@huawei.com>
References: <1617788943-52722-1-git-send-email-liuqi115@huawei.com>
 <1617788943-52722-2-git-send-email-liuqi115@huawei.com>
 <20210407204004.GB16011@willie-the-truck>
 <20210408100157.000062f0@Huawei.com>
 <16a7a3f8-82b5-a113-57c0-a9d575c649bd@huawei.com>
Message-ID: <20210408132805.GA17873@willie-the-truck>

Hi John,

On Thu, Apr 08, 2021 at 01:55:02PM +0100, John Garry wrote:
> On 08/04/2021 10:01, Jonathan Cameron wrote:
> > On Wed, 7 Apr 2021 21:40:05 +0100
> > Will Deacon <will at kernel.org> wrote:
> > 
> > > On Wed, Apr 07, 2021 at 05:49:02PM +0800, Qi Liu wrote:
> > > > PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> > > > to sample bandwidth, latency, buffer occupation etc.
> > > > 
> > > > Each PMU RCiEP device monitors multiple root ports, and each RCiEP is
> > > > registered as a pmu in /sys/bus/event_source/devices, so users can
> > > > select target PMU, and use filter to do further sets.
> > > > 
> > > > Filtering options contains:
> > > > event        - select the event.
> > > > subevent     - select the subevent.
> > > > port         - select target root ports. Information of root ports
> > > >                 are shown under sysfs.
> > > > bdf           - select requester_id of target EP device.
> > > > trig_len     - set trigger condition for starting event statistics.
> > > > trigger_mode - set trigger mode. 0 means starting to statistic when
> > > >                 bigger than trigger condition, and 1 means smaller.
> > > > thr_len      - set threshold for statistics.
> > > > thr_mode     - set threshold mode. 0 means count when bigger than
> > > >                 threshold, and 1 means smaller.
> > > > 
> > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> > > 
> > > Do you have a link to this review, please?
> > 
> > Internal review, so drop the tag.
> > 
> > Jonathan
> 
> Hi Will,
> 
> Are you implying that you would rather that any review for these drivers is
> done in public on the lists?

Absolutely! If I can see that you and/or Jonathan have given the thing a
good going through, then it's a lot easier to merge the patches. But just
having the tag doesn't help much, as I don't know whether it was a concerted
review effort or a "yeah, this function is about what I thought, cheers"
type of review.

That's not to say internal patch review isn't a useful tool in some
circumstances (e.g. somebody new to the kernel, confidential stuff,
prototyping), but the vast majority of the time I'd say having the review
on the public lists is the best bet.

Will


From will at kernel.org  Thu Apr  8 14:29:59 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 14:29:59 +0100
Subject: [GIT PULL] iommu/arm-smmu: Updates for 5.13
Message-ID: <20210408132959.GB17873@willie-the-truck>

Hi Joerg,

There's hardly anything on the SMMU front for 5.13, but please pull
these regardless. Summary in the tag.

Cheers,

Will

--->8

The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:

  Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)

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 e0bb4b73540495111ff2723e41cf5add2f031021:

  iommu/arm-smmu-v3: Remove the unused fields for PREFETCH_CONFIG command (2021-04-07 11:30:40 +0100)

----------------------------------------------------------------
Arm SMMU updates for 5.13

- SMMUv3:

  * Drop vestigial PREFETCH_ADDR support

  * Elide TLB sync logic for empty gather

  * Fix "Service Failure Mode" handling

- SMMUv2:

  * New Qualcomm compatible string

----------------------------------------------------------------
Sai Prakash Ranjan (1):
      dt-bindings: arm-smmu: Add compatible for SC7280 SoC

Xiang Chen (1):
      iommu/arm-smmu-v3: Add a check to avoid invalid iotlb sync

Zenghui Yu (1):
      iommu/arm-smmu-v3: Remove the unused fields for PREFETCH_CONFIG command

Zhen Lei (1):
      iommu/arm-smmu-v3: add bit field SFM into GERROR_ERR_MASK

 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           | 5 +++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h           | 4 +---
 3 files changed, 5 insertions(+), 5 deletions(-)


From lujialin4 at huawei.com  Thu Apr  8 14:36:30 2021
From: lujialin4 at huawei.com (Lu Jialin)
Date: Thu, 8 Apr 2021 21:36:30 +0800
Subject: [PATCH -next] media: sun8i: Fix PM reference leak in
 deinterlace_start_streaming()
Message-ID: <20210408133630.56299-1-lujialin4@huawei.com>


pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Lu Jialin <lujialin4 at huawei.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 ed863bf5ea80..671e4a928993 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -589,7 +589,7 @@ static int deinterlace_start_streaming(struct vb2_queue *vq, unsigned int count)
 	int ret;
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 



From broonie at kernel.org  Thu Apr  8 14:43:47 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 14:43:47 +0100
Subject: [PATCH] spi: imx: add a check for speed_hz before calculating
 the clock
In-Reply-To: <20210408103347.244313-2-xiaoning.wang@nxp.com>
References: <20210408103347.244313-1-xiaoning.wang@nxp.com>
 <20210408103347.244313-2-xiaoning.wang@nxp.com>
Message-ID: <20210408134347.GE4516@sirena.org.uk>

On Thu, Apr 08, 2021 at 06:33:47PM +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.

> Add a check for these two values before configuring the clock. An
> error will be returned when they are not assigned.

For the case where the transfer speed is not set __spi_validate() will
take the controller's maximum speed so the controller should just be
able to unconditionally use the transfer's speed.  Your issue is
therefore that the controllers are sometimes not setting a maximum
speed which this doesn't seem to fix AFAICT?  I'd expect the driver to
be able to work one out based on the input clock.

>  struct spi_imx_devtype_data {
>  	void (*intctrl)(struct spi_imx_data *, int);
>  	int (*prepare_message)(struct spi_imx_data *, struct spi_message *);
> -	int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *,
> -				struct spi_transfer *);
> +	int (*prepare_transfer)(struct spi_imx_data *, struct spi_device *);
>  	void (*trigger)(struct spi_imx_data *);
>  	int (*rx_available)(struct spi_imx_data *);
>  	void (*reset)(struct spi_imx_data *);

This seems to be a fairly big and surprising refactoring for the
described change.  It's quite hard to tie the change to the changelog.
-------------- 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/20210408/3689a325/attachment.sig>

From andriy.shevchenko at linux.intel.com  Thu Apr  8 14:44:01 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu, 8 Apr 2021 16:44:01 +0300
Subject: [RESEND PATCH v4 3/3] gpio: xilinx: Utilize generic
 bitmap_get_value and _set_value
In-Reply-To: <d150bd18acc767c86c23ec06cc2abd5ca74ccbbb.1617380819.git.syednwaris@gmail.com>
References: <cover.1617380819.git.syednwaris@gmail.com>
 <d150bd18acc767c86c23ec06cc2abd5ca74ccbbb.1617380819.git.syednwaris@gmail.com>
Message-ID: <YG8IoWznJEzwfigA@smile.fi.intel.com>

On Fri, Apr 02, 2021 at 10:07:36PM +0530, Syed Nayyar Waris wrote:
> This patch reimplements the xgpio_set_multiple() function in
> drivers/gpio/gpio-xilinx.c to use the new generic functions:
> bitmap_get_value() and bitmap_set_value(). The code is now simpler
> to read and understand. Moreover, instead of looping for each bit
> in xgpio_set_multiple() function, now we can check each channel at
> a time and save cycles.

As promised, I have looked at this with a fresh eye and NAK from me. Sorry.
This is less than a half baked solution. I spent couple of evenings, so
I'll come up with full conversion of this driver to the bitmap API.
And yes, as I have told you like half a year before, bitmap_get_value32() and
bitmap_set_value32() is much more useful (and I actually implemented them
locally for the sake of conversion).

So, summarize this I do not think we have real users of the proposed API.

-- 
With Best Regards,
Andy Shevchenko




From clare.chenhui at huawei.com  Thu Apr  8 14:48:56 2021
From: clare.chenhui at huawei.com (Chen Hui)
Date: Thu, 8 Apr 2021 21:48:56 +0800
Subject: [PATCH -next] clk: samsung: Remove redundant dev_err calls
Message-ID: <20210408134856.207305-1-clare.chenhui@huawei.com>

There is error message within devm_ioremap_resource
already, so remove the dev_err calls to avoid redundant
error messages.

Signed-off-by: Chen Hui <clare.chenhui at huawei.com>
---
 drivers/clk/samsung/clk-exynos4412-isp.c | 4 +---
 drivers/clk/samsung/clk-s5pv210-audss.c  | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4412-isp.c b/drivers/clk/samsung/clk-exynos4412-isp.c
index 4b9e73608c21..b69e381b8c0c 100644
--- a/drivers/clk/samsung/clk-exynos4412-isp.c
+++ b/drivers/clk/samsung/clk-exynos4412-isp.c
@@ -115,10 +115,8 @@ static int __init exynos4x12_isp_clk_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	reg_base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(reg_base)) {
-		dev_err(dev, "failed to map registers\n");
+	if (IS_ERR(reg_base))
 		return PTR_ERR(reg_base);
-	}
 
 	exynos4x12_save_isp = samsung_clk_alloc_reg_dump(exynos4x12_clk_isp_save,
 					ARRAY_SIZE(exynos4x12_clk_isp_save));
diff --git a/drivers/clk/samsung/clk-s5pv210-audss.c b/drivers/clk/samsung/clk-s5pv210-audss.c
index 14985ebd043b..a7827a120695 100644
--- a/drivers/clk/samsung/clk-s5pv210-audss.c
+++ b/drivers/clk/samsung/clk-s5pv210-audss.c
@@ -72,10 +72,8 @@ static int s5pv210_audss_clk_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	reg_base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(reg_base)) {
-		dev_err(&pdev->dev, "failed to map audss registers\n");
+	if (IS_ERR(reg_base))
 		return PTR_ERR(reg_base);
-	}
 
 	clk_data = devm_kzalloc(&pdev->dev,
 				struct_size(clk_data, hws, AUDSS_MAX_CLKS),
-- 
2.17.1



From linus.walleij at linaro.org  Thu Apr  8 14:55:58 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 8 Apr 2021 15:55:58 +0200
Subject: [PATCH v9 00/22] pinctrl: add BCM63XX pincontrol support
In-Reply-To: <609f038d-3037-5cda-b489-f0816eb95658@gmail.com>
References: <20210324081923.20379-1-noltari@gmail.com>
 <CACRpkdZE55ixxSp6H1SKx19trGE_uVGgkLttzAVQuLzw4=Jutw@mail.gmail.com>
 <609f038d-3037-5cda-b489-f0816eb95658@gmail.com>
Message-ID: <CACRpkdZubgHyBqPnZxOw7QXgf=AHMcb1E0Y7bj5v3v_Am+3Ttw@mail.gmail.com>

On Tue, Mar 30, 2021 at 10:57 AM ?lvaro Fern?ndez Rojas
<noltari at gmail.com> wrote:

> > Now, what about a patch set for the IRQ support? :)
>
> If you could give me some guidance on that matter it would be much
> appreciated, because your comments [1] are now outdated since I switched
> to GPIO_REGMAP
> [1]
> http://patchwork.ozlabs.org/project/linux-gpio/patch/20210225164216.21124-3-noltari at gmail.com/

I think it mostly holds: GPIOLIB_IRQCHIP should always be used if there
is a reasonably straight-forward interrupts whether cascaded or hierarchical.
Very few exceptions there. If there is one IRQ line per GPIO
line, the hierarchical support should be used as outlined. GPIO_REGMAP
should be mostly (famous last words) orthogonal.

Yours,
Linus Walleij


From rmfrfs at gmail.com  Thu Apr  8 14:57:02 2021
From: rmfrfs at gmail.com (Rui Miguel Silva)
Date: Thu, 8 Apr 2021 14:57:02 +0100
Subject: [PATCH] media: imx: imx7-mipi-csis: Fix runtime PM imbalance in
 mipi_csis_s_stream
In-Reply-To: <20210408090827.32612-1-dinghao.liu@zju.edu.cn>
References: <20210408090827.32612-1-dinghao.liu@zju.edu.cn>
Message-ID: <20210408135702.f7ikjvwirvtzsarv@arch-thunder.localdomain>

Hi Liu,
Thanks for your patch.

On Thu, Apr 08, 2021 at 05:08:27PM +0800, Dinghao Liu wrote:
> When v4l2_subdev_call() fails, a pairing PM usage counter
> decrement is needed to keep the counter balanced. It's the
> same for the following error paths in case 'enable' is on.
> 
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> ---
>  drivers/staging/media/imx/imx7-mipi-csis.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> index a01a7364b4b9..2a3fff231a40 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -627,21 +627,26 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
>  			return ret;
>  		}
>  		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
> -		if (ret < 0)
> +		if (ret < 0) {
> +			pm_runtime_put_noidle(&state->pdev->dev);

I think here we should go completely pm_runtime_put to call the
mipi_csis_pm_suspend down the line, right?

>  			return ret;
> +		}
>  	}
>  
>  	mutex_lock(&state->lock);
>  	if (enable) {
>  		if (state->flags & ST_SUSPENDED) {
>  			ret = -EBUSY;
> +			pm_runtime_put_noidle(&state->pdev->dev);

since we are in ST_SUSPENDED state, for sure the pm counter was
already 0.

>  			goto unlock;
>  		}
>  
>  		mipi_csis_start_stream(state);
>  		ret = v4l2_subdev_call(state->src_sd, video, s_stream, 1);
> -		if (ret < 0)
> +		if (ret < 0) {
> +			pm_runtime_put_noidle(&state->pdev->dev);

here also we need the pm_runtime_put, maybe just changing the unlock
tag bellow from:
    if (!enable)
        pm_runtime_put(&state->pdev->dev);

to 
    if (!enable || (ret < 0))
        pm_runtime_put(&state->pdev->dev);

will not hurt the first case and will complete the suspend routine
afterward in the second case.

------
Cheers,
     Rui
>  			goto unlock;
> +		}
>  
>  		mipi_csis_log_counters(state, true);
>  
> -- 
> 2.17.1
> 
> 


From will at kernel.org  Thu Apr  8 14:58:07 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 14:58:07 +0100
Subject: [RFC PATCH v4 12/15] iommu/io-pgtable-arm-v7s: Implement
 arm_v7s_unmap_pages()
In-Reply-To: <20210408045241.27316-13-isaacm@codeaurora.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-13-isaacm@codeaurora.org>
Message-ID: <20210408135807.GA17998@willie-the-truck>

On Wed, Apr 07, 2021 at 09:52:38PM -0700, Isaac J. Manjarres wrote:
> Implement the unmap_pages() callback for the ARM v7s io-pgtable
> format.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> ---
>  drivers/iommu/io-pgtable-arm-v7s.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index d4004bcf333a..5e203e03c352 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -710,15 +710,32 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
>  	return __arm_v7s_unmap(data, gather, iova, size, lvl + 1, ptep);
>  }
>  
> -static size_t arm_v7s_unmap(struct io_pgtable_ops *ops, unsigned long iova,
> -			    size_t size, struct iommu_iotlb_gather *gather)
> +static size_t arm_v7s_unmap_pages(struct io_pgtable_ops *ops, unsigned long iova,
> +				  size_t pgsize, size_t pgcount,
> +				  struct iommu_iotlb_gather *gather)
>  {
>  	struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
> +	size_t unmapped = 0, ret;
>  
>  	if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
>  		return 0;
>  
> -	return __arm_v7s_unmap(data, gather, iova, size, 1, data->pgd);
> +	while (pgcount--) {
> +		ret = __arm_v7s_unmap(data, gather, iova, pgsize, 1, data->pgd);
> +		if (!ret)
> +			break;
> +
> +		unmapped += pgsize;
> +		iova += pgsize;
> +	}
> +
> +	return unmapped;
> +}

Wait -- don't you need to hook this up somewhere (likewise for ->map_pages)?
How are you testing this?

Will


From will at kernel.org  Thu Apr  8 14:59:02 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 14:59:02 +0100
Subject: [RFC PATCH v4 06/15] iommu: Split 'addr_merge' argument to
 iommu_pgsize() into separate parts
In-Reply-To: <20210408045241.27316-7-isaacm@codeaurora.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-7-isaacm@codeaurora.org>
Message-ID: <20210408135901.GB17998@willie-the-truck>

On Wed, Apr 07, 2021 at 09:52:32PM -0700, Isaac J. Manjarres wrote:
> From: Will Deacon <will at kernel.org>
> 
> The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
> intended to describe the alignment requirements to consider when
> choosing an appropriate page size. On the iommu_map() path, this address
> is the logical OR of the virtual and physical addresses.
> 
> Subsequent improvements to iommu_pgsize() will need to check the
> alignment of the virtual and physical components of 'addr_merge'
> independently, so pass them in as separate parameters and reconstruct
> 'addr_merge' locally.
> 
> No functional change.
> 
> Signed-off-by: Will Deacon <will at kernel.org>
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> ---
>  drivers/iommu/iommu.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index bcd623862bf9..ab689611a03b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2357,12 +2357,13 @@ phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
>  }
>  EXPORT_SYMBOL_GPL(iommu_iova_to_phys);
>  
> -static size_t iommu_pgsize(struct iommu_domain *domain,
> -			   unsigned long addr_merge, size_t size)
> +static size_t iommu_pgsize(struct iommu_domain *domain, unsigned long iova,
> +			   phys_addr_t paddr, size_t size)
>  {
>  	unsigned int pgsize_idx;
>  	unsigned long pgsizes;
>  	size_t pgsize;
> +	phys_addr_t addr_merge = paddr | iova;

^^^ this needs to be 'unsigned long' as it was before (otherwise using
GENMASK _is_ a problem).

Will


From will at kernel.org  Thu Apr  8 14:59:26 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 14:59:26 +0100
Subject: [RFC PATCH v4 09/15] iommu/io-pgtable-arm: Prepare PTE methods
 for handling multiple entries
In-Reply-To: <20210408045241.27316-10-isaacm@codeaurora.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-10-isaacm@codeaurora.org>
Message-ID: <20210408135925.GC17998@willie-the-truck>

On Wed, Apr 07, 2021 at 09:52:35PM -0700, Isaac J. Manjarres wrote:
> The PTE methods currently operate on a single entry. In preparation
> for manipulating multiple PTEs in one map or unmap call, allow them
> to handle multiple PTEs.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/io-pgtable-arm.c | 78 +++++++++++++++++++---------------
>  1 file changed, 44 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 87def58e79b5..ea66b10c04c4 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -232,20 +232,23 @@ static void __arm_lpae_free_pages(void *pages, size_t size,
>  	free_pages((unsigned long)pages, get_order(size));
>  }
>  
> -static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep,
> +static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep, int num_entries,
>  				struct io_pgtable_cfg *cfg)
>  {
>  	dma_sync_single_for_device(cfg->iommu_dev, __arm_lpae_dma_addr(ptep),
> -				   sizeof(*ptep), DMA_TO_DEVICE);
> +				   sizeof(*ptep) * num_entries, DMA_TO_DEVICE);
>  }

Have you tested this with CONFIG_DMA_API_DEBUG=y? I _think_ it should be
ok as long as we don't attempt to sync across a page boundary, but it would
be good to give it a spin just to check.

Will


From hch at infradead.org  Thu Apr  8 15:02:30 2021
From: hch at infradead.org (Christoph Hellwig)
Date: Thu, 8 Apr 2021 15:02:30 +0100
Subject: [RFC PATCH v4 09/15] iommu/io-pgtable-arm: Prepare PTE methods
 for handling multiple entries
In-Reply-To: <20210408135925.GC17998@willie-the-truck>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-10-isaacm@codeaurora.org>
 <20210408135925.GC17998@willie-the-truck>
Message-ID: <20210408140230.GA3884124@infradead.org>

On Thu, Apr 08, 2021 at 02:59:26PM +0100, Will Deacon wrote:
> > -static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep,
> > +static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep, int num_entries,
> >  				struct io_pgtable_cfg *cfg)
> >  {
> >  	dma_sync_single_for_device(cfg->iommu_dev, __arm_lpae_dma_addr(ptep),
> > -				   sizeof(*ptep), DMA_TO_DEVICE);
> > +				   sizeof(*ptep) * num_entries, DMA_TO_DEVICE);
> >  }
> 
> Have you tested this with CONFIG_DMA_API_DEBUG=y? I _think_ it should be
> ok as long as we don't attempt to sync across a page boundary, but it would
> be good to give it a spin just to check.

syncing over a page boundary is perfectly fine.  It just needs to say in
the bounds of the original mapping.


From broonie at kernel.org  Thu Apr  8 15:05:23 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 15:05:23 +0100
Subject: [PATCH] spi: imx: add a check for speed_hz before calculating
 the clock
In-Reply-To: <20210408103347.244313-2-xiaoning.wang@nxp.com>
References: <20210408103347.244313-1-xiaoning.wang@nxp.com>
 <20210408103347.244313-2-xiaoning.wang@nxp.com>
Message-ID: <20210408140523.GH4516@sirena.org.uk>

On Thu, Apr 08, 2021 at 06:33:47PM +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.

Please don't send new patches in reply to other threads, this makes it
harder to follow what current versions of things are and causes problems
for tools.
-------------- 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/20210408/5497f1f8/attachment.sig>

From catalin.marinas at arm.com  Thu Apr  8 15:18:55 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 8 Apr 2021 15:18:55 +0100
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <5e5bf772-1e4d-ca59-a9d8-058a72dfad4f@arm.com>
References: <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
 <20210407151458.GC21451@arm.com>
 <5e5bf772-1e4d-ca59-a9d8-058a72dfad4f@arm.com>
Message-ID: <20210408141853.GA7676@arm.com>

On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> On 07/04/2021 16:14, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> > > On 31/03/2021 19:43, Catalin Marinas wrote:
> > > > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > > > that's an opt-in by the VMM, haven't checked the other patches), can we
> > > > reject it if it's is going to be mapped as Normal Cacheable but it is a
> > > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
> > > > check for ZONE_DEVICE)? This way we don't need to do more expensive
> > > > checks in set_pte_at().
> > > 
> > > The problem is that KVM allows the VMM to change the memory backing a slot
> > > while the guest is running. This is obviously useful for the likes of
> > > migration, but ultimately means that even if you were to do checks at the
> > > time of slot creation, you would need to repeat the checks at set_pte_at()
> > > time to ensure a mischievous VMM didn't swap the page for a problematic one.
> > 
> > Does changing the slot require some KVM API call? Can we intercept it
> > and do the checks there?
> 
> As David has already replied - KVM uses MMU notifiers, so there's not really
> a good place to intercept this before the fault.
> 
> > Maybe a better alternative for the time being is to add a new
> > kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns
> > true _and_ the VMM asked for MTE in guest. We can then only set
> > PG_mte_tagged if !device.
> 
> KVM already has a kvm_is_device_pfn(), and yes I agree restricting the MTE
> checks to only !kvm_is_device_pfn() makes sense (I have the fix in my branch
> locally).

Indeed, you can skip it if kvm_is_device_pfn(). In addition, with MTE,
I'd also mark a pfn as 'device' in user_mem_abort() if
pfn_to_online_page() is NULL as we don't want to map it as Cacheable in
Stage 2. It's unlikely that we'll trip over this path but just in case.

(can we have a ZONE_DEVICE _online_ pfn or by definition they are
considered offline?)

> > BTW, after a page is restored from swap, how long do we keep the
> > metadata around? I think we can delete it as soon as it was restored and
> > PG_mte_tagged was set. Currently it looks like we only do this when the
> > actual page was freed or swapoff. I haven't convinced myself that it's
> > safe to do this for swapoff unless it guarantees that all the ptes
> > sharing a page have been restored.
> 
> My initial thought was to free the metadata immediately. However it turns
> out that the following sequence can happen:
> 
>  1. Swap out a page
>  2. Swap the page in *read only*
>  3. Discard the page
>  4. Swap the page in again
> 
> So there's no writing of the swap data again before (3). This works nicely
> with a swap device because after writing a page it stays there forever, so
> if you know it hasn't been modified it's pointless rewriting it. Sadly it's
> not quite so ideal with the MTE tags which are currently kept in RAM.

I missed this scenario. So we need to keep it around as long as the
corresponding swap storage is still valid.

-- 
Catalin


From will at kernel.org  Thu Apr  8 15:20:14 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 15:20:14 +0100
Subject: [RFC PATCH v4 09/15] iommu/io-pgtable-arm: Prepare PTE methods
 for handling multiple entries
In-Reply-To: <20210408140230.GA3884124@infradead.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-10-isaacm@codeaurora.org>
 <20210408135925.GC17998@willie-the-truck>
 <20210408140230.GA3884124@infradead.org>
Message-ID: <20210408142014.GD17998@willie-the-truck>

On Thu, Apr 08, 2021 at 03:02:30PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 08, 2021 at 02:59:26PM +0100, Will Deacon wrote:
> > > -static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep,
> > > +static void __arm_lpae_sync_pte(arm_lpae_iopte *ptep, int num_entries,
> > >  				struct io_pgtable_cfg *cfg)
> > >  {
> > >  	dma_sync_single_for_device(cfg->iommu_dev, __arm_lpae_dma_addr(ptep),
> > > -				   sizeof(*ptep), DMA_TO_DEVICE);
> > > +				   sizeof(*ptep) * num_entries, DMA_TO_DEVICE);
> > >  }
> > 
> > Have you tested this with CONFIG_DMA_API_DEBUG=y? I _think_ it should be
> > ok as long as we don't attempt to sync across a page boundary, but it would
> > be good to give it a spin just to check.
> 
> syncing over a page boundary is perfectly fine.  It just needs to say in
> the bounds of the original mapping.

Yes, you're right. I got the CPU page size mixed up with the IOMMU page
size, so I think we're good as the allocations here are made at IOMMU
page size granularity.

Will


From will at kernel.org  Thu Apr  8 15:32:11 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 15:32:11 +0100
Subject: [RFC PATCH v4 10/15] iommu/io-pgtable-arm: Implement
 arm_lpae_unmap_pages()
In-Reply-To: <20210408045241.27316-11-isaacm@codeaurora.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-11-isaacm@codeaurora.org>
Message-ID: <20210408143211.GE17998@willie-the-truck>

On Wed, Apr 07, 2021 at 09:52:36PM -0700, Isaac J. Manjarres wrote:
> Implement the unmap_pages() callback for the ARM LPAE io-pgtable
> format.
> 
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> Suggested-by: Will Deacon <will at kernel.org>
> ---
>  drivers/iommu/io-pgtable-arm.c | 70 ++++++++++++++++++++++------------
>  1 file changed, 45 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index ea66b10c04c4..6700685f81d4 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -253,8 +253,8 @@ static void __arm_lpae_set_pte(arm_lpae_iopte *ptep, arm_lpae_iopte pte,
>  
>  static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
>  			       struct iommu_iotlb_gather *gather,
> -			       unsigned long iova, size_t size, int lvl,
> -			       arm_lpae_iopte *ptep);
> +			       unsigned long iova, size_t size, size_t pgcount,
> +			       int lvl, arm_lpae_iopte *ptep);
>  
>  static void __arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>  				phys_addr_t paddr, arm_lpae_iopte prot,
> @@ -298,7 +298,7 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>  			size_t sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
>  
>  			tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
> -			if (__arm_lpae_unmap(data, NULL, iova + i * sz, sz,
> +			if (__arm_lpae_unmap(data, NULL, iova + i * sz, sz, 1,
>  					     lvl, tblp) != sz) {
>  				WARN_ON(1);
>  				return -EINVAL;
> @@ -526,14 +526,14 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>  				       struct iommu_iotlb_gather *gather,
>  				       unsigned long iova, size_t size,
>  				       arm_lpae_iopte blk_pte, int lvl,
> -				       arm_lpae_iopte *ptep)
> +				       arm_lpae_iopte *ptep, size_t pgcount)
>  {
>  	struct io_pgtable_cfg *cfg = &data->iop.cfg;
>  	arm_lpae_iopte pte, *tablep;
>  	phys_addr_t blk_paddr;
>  	size_t tablesz = ARM_LPAE_GRANULE(data);
>  	size_t split_sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
> -	int i, unmap_idx = -1;
> +	int i, unmap_idx_start = -1, num_entries = 0, max_entries;
>  
>  	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
>  		return 0;
> @@ -542,15 +542,18 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>  	if (!tablep)
>  		return 0; /* Bytes unmapped */
>  
> -	if (size == split_sz)
> -		unmap_idx = ARM_LPAE_LVL_IDX(iova, lvl, data);
> +	if (size == split_sz) {
> +		unmap_idx_start = ARM_LPAE_LVL_IDX(iova, lvl, data);
> +		max_entries = (tablesz >> ilog2(sizeof(pte))) - unmap_idx_start;
> +		num_entries = min_t(int, pgcount, max_entries);
> +	}
>  
>  	blk_paddr = iopte_to_paddr(blk_pte, data);
>  	pte = iopte_prot(blk_pte);
>  
>  	for (i = 0; i < tablesz / sizeof(pte); i++, blk_paddr += split_sz) {

Given that we already have a 'tablesz / sizeof(pte)' expression here, I'd be
inclined to have either a local variable or a macro helper to get at the
ptes_per_table value that you also need to compute max_entries.

>  		/* Unmap! */
> -		if (i == unmap_idx)
> +		if (i >= unmap_idx_start && i < (unmap_idx_start + num_entries))
>  			continue;
>  
>  		__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, &tablep[i]);
> @@ -568,38 +571,45 @@ static size_t arm_lpae_split_blk_unmap(struct arm_lpae_io_pgtable *data,
>  			return 0;
>  
>  		tablep = iopte_deref(pte, data);
> -	} else if (unmap_idx >= 0) {
> -		io_pgtable_tlb_add_page(&data->iop, gather, iova, size);
> -		return size;
> +	} else if (unmap_idx_start >= 0) {
> +		for (i = 0; i < num_entries; i++)
> +			io_pgtable_tlb_add_page(&data->iop, gather, iova + i * size, size);

I suppose we could add a count paramater to the iotlb gather stuff in
future too, but for now this is fine as this series is already pretty big.

Will


From will at kernel.org  Thu Apr  8 15:32:33 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 15:32:33 +0100
Subject: [RFC PATCH v4 12/15] iommu/io-pgtable-arm-v7s: Implement
 arm_v7s_unmap_pages()
In-Reply-To: <342d453c1e5d737122b43be006de6077@codeaurora.org>
References: <20210408045241.27316-1-isaacm@codeaurora.org>
 <20210408045241.27316-13-isaacm@codeaurora.org>
 <20210408135807.GA17998@willie-the-truck>
 <342d453c1e5d737122b43be006de6077@codeaurora.org>
Message-ID: <20210408143232.GF17998@willie-the-truck>

On Thu, Apr 08, 2021 at 07:19:29AM -0700, isaacm at codeaurora.org wrote:
> On 2021-04-08 06:58, Will Deacon wrote:
> > On Wed, Apr 07, 2021 at 09:52:38PM -0700, Isaac J. Manjarres wrote:
> > > Implement the unmap_pages() callback for the ARM v7s io-pgtable
> > > format.
> > > 
> > > Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> > > ---
> > >  drivers/iommu/io-pgtable-arm-v7s.c | 23 ++++++++++++++++++++---
> > >  1 file changed, 20 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> > > b/drivers/iommu/io-pgtable-arm-v7s.c
> > > index d4004bcf333a..5e203e03c352 100644
> > > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > > @@ -710,15 +710,32 @@ static size_t __arm_v7s_unmap(struct
> > > arm_v7s_io_pgtable *data,
> > >  	return __arm_v7s_unmap(data, gather, iova, size, lvl + 1, ptep);
> > >  }
> > > 
> > > -static size_t arm_v7s_unmap(struct io_pgtable_ops *ops, unsigned
> > > long iova,
> > > -			    size_t size, struct iommu_iotlb_gather *gather)
> > > +static size_t arm_v7s_unmap_pages(struct io_pgtable_ops *ops,
> > > unsigned long iova,
> > > +				  size_t pgsize, size_t pgcount,
> > > +				  struct iommu_iotlb_gather *gather)
> > >  {
> > >  	struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
> > > +	size_t unmapped = 0, ret;
> > > 
> > >  	if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
> > >  		return 0;
> > > 
> > > -	return __arm_v7s_unmap(data, gather, iova, size, 1, data->pgd);
> > > +	while (pgcount--) {
> > > +		ret = __arm_v7s_unmap(data, gather, iova, pgsize, 1, data->pgd);
> > > +		if (!ret)
> > > +			break;
> > > +
> > > +		unmapped += pgsize;
> > > +		iova += pgsize;
> > > +	}
> > > +
> > > +	return unmapped;
> > > +}
> > 
> > Wait -- don't you need to hook this up somewhere (likewise for
> > ->map_pages)?
> Done. Likewise for map_pages(). I'm not sure how the compiler didn't catch
> this; I'm compile testing this, as I don't have hardware that uses the short
> descriptor format.

Damn, neither do I :/ My seattle has all the memory high up iirc.

Will


From vincenzo.frascino at arm.com  Thu Apr  8 15:37:23 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Thu,  8 Apr 2021 15:37:23 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
Message-ID: <20210408143723.13024-1-vincenzo.frascino@arm.com>

The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
race with another CPU doing a set_tsk_thread_flag() and the flag can be
lost in the process.

Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
exit_to_user_mode() to address the problem.

Note: Moving the check in entry-common allows to use set_thread_flag()
which is safe.

Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous
tag check faults")
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Reported-by: Will Deacon <will at kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
 arch/arm64/include/asm/mte.h     |  8 ++++++++
 arch/arm64/kernel/entry-common.c |  6 ++++++
 arch/arm64/kernel/entry.S        | 30 ------------------------------
 arch/arm64/kernel/mte.c          | 25 +++++++++++++++++++++++--
 4 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 9b557a457f24..188f778c6f7b 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
 void mte_invalidate_tags_area(int type);
 void *mte_allocate_tag_storage(void);
 void mte_free_tag_storage(char *storage);
+void check_mte_async_tcf0(void);
+void clear_mte_async_tcf0(void);
 
 #ifdef CONFIG_ARM64_MTE
 
@@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
 {
 	return -EIO;
 }
+void check_mte_async_tcf0(void)
+{
+}
+void clear_mte_async_tcf0(void)
+{
+}
 
 static inline void mte_assign_mem_tag_range(void *addr, size_t size)
 {
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9d3588450473..837d3624a1d5 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
 	CT_WARN_ON(ct_state() != CONTEXT_USER);
 	user_exit_irqoff();
 	trace_hardirqs_off_finish();
+
+	/* Check for asynchronous tag check faults in user space */
+	check_mte_async_tcf0();
 }
 
 asmlinkage void noinstr exit_to_user_mode(void)
 {
+	/* Ignore asynchronous tag check faults in the uaccess routines */
+	clear_mte_async_tcf0();
+
 	trace_hardirqs_on_prepare();
 	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
 	user_enter_irqoff();
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a31a0a713c85..fafd74ae5021 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -147,32 +147,6 @@ alternative_cb_end
 .L__asm_ssbd_skip\@:
 	.endm
 
-	/* Check for MTE asynchronous tag check faults */
-	.macro check_mte_async_tcf, flgs, tmp
-#ifdef CONFIG_ARM64_MTE
-alternative_if_not ARM64_MTE
-	b	1f
-alternative_else_nop_endif
-	mrs_s	\tmp, SYS_TFSRE0_EL1
-	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
-	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
-	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
-	str	\flgs, [tsk, #TSK_TI_FLAGS]
-	msr_s	SYS_TFSRE0_EL1, xzr
-1:
-#endif
-	.endm
-
-	/* Clear the MTE asynchronous tag check faults */
-	.macro clear_mte_async_tcf
-#ifdef CONFIG_ARM64_MTE
-alternative_if ARM64_MTE
-	dsb	ish
-	msr_s	SYS_TFSRE0_EL1, xzr
-alternative_else_nop_endif
-#endif
-	.endm
-
 	.macro mte_set_gcr, tmp, tmp2
 #ifdef CONFIG_ARM64_MTE
 	/*
@@ -243,8 +217,6 @@ alternative_else_nop_endif
 	ldr	x19, [tsk, #TSK_TI_FLAGS]
 	disable_step_tsk x19, x20
 
-	/* Check for asynchronous tag check faults in user space */
-	check_mte_async_tcf x19, x22
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
@@ -775,8 +747,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
 	cbnz	x2, work_pending
 finish_ret_to_user:
 	user_enter_irqoff
-	/* Ignore asynchronous tag check faults in the uaccess routines */
-	clear_mte_async_tcf
 	enable_step_tsk x19, x2
 #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
 	bl	stackleak_erase
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index b3c70a612c7a..e759b0eca47e 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -166,14 +166,35 @@ static void set_gcr_el1_excl(u64 excl)
 	 */
 }
 
+void check_mte_async_tcf0(void)
+{
+	/*
+	 * dsb(ish) is not required before the register read
+	 * because the TFSRE0_EL1 is automatically synchronized
+	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
+	 * is set.
+	 */
+	u64 tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
+
+	if (tcf0 & SYS_TFSR_EL1_TF0)
+		set_thread_flag(TIF_MTE_ASYNC_FAULT);
+
+	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
+void clear_mte_async_tcf0(void)
+{
+	dsb(ish);
+	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
 void flush_mte_state(void)
 {
 	if (!system_supports_mte())
 		return;
 
 	/* clear any pending asynchronous tag fault */
-	dsb(ish);
-	write_sysreg_s(0, SYS_TFSRE0_EL1);
+	clear_mte_async_tcf0();
 	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
 	/* disable tag checking */
 	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
-- 
2.30.2



From pasha.tatashin at soleen.com  Thu Apr  8 15:45:18 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu, 8 Apr 2021 10:45:18 -0400
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
Message-ID: <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:24 AM Marc Zyngier <maz at kernel.org> wrote:
>
> On 2021-04-08 05:05, Pavel Tatashin wrote:
> > From: James Morse <james.morse at arm.com>
> >
> > The hyp-stub's el1_sync code doesn't do very much, this can easily fit
> > in the vectors.
> >
> > With this, all of the hyp-stubs behaviour is contained in its vectors.
> > This lets kexec and hibernate copy the hyp-stub when they need its
> > behaviour, instead of re-implementing it.
> >
> > Signed-off-by: James Morse <james.morse at arm.com>
> >
> > [Fixed merging issues]
>
> That's a pretty odd fix IMO.
>
> >
> > Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
> > ---
> >  arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------
> >  1 file changed, 29 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/hyp-stub.S
> > b/arch/arm64/kernel/hyp-stub.S
> > index ff329c5c074d..d1a73d0f74e0 100644
> > --- a/arch/arm64/kernel/hyp-stub.S
> > +++ b/arch/arm64/kernel/hyp-stub.S
> > @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label)
> >       .align 7
> >       b       \label
> >  SYM_CODE_END(\label)
> > +.endm
> > +
> > +.macro hyp_stub_el1_sync
> > +SYM_CODE_START_LOCAL(hyp_stub_el1_sync)
> > +     .align 7
> > +     cmp     x0, #HVC_SET_VECTORS
> > +     b.ne    2f
> > +     msr     vbar_el2, x1
> > +     b       9f
> > +
> > +2:   cmp     x0, #HVC_SOFT_RESTART
> > +     b.ne    3f
> > +     mov     x0, x2
> > +     mov     x2, x4
> > +     mov     x4, x1
> > +     mov     x1, x3
> > +     br      x4                              // no return
> > +
> > +3:   cmp     x0, #HVC_RESET_VECTORS
> > +     beq     9f                              // Nothing to reset!
> > +
> > +     /* Someone called kvm_call_hyp() against the hyp-stub... */
> > +     mov_q   x0, HVC_STUB_ERR
> > +     eret
> > +
> > +9:   mov     x0, xzr
> > +     eret
> > +SYM_CODE_END(hyp_stub_el1_sync)
>
> You said you tested this on a TX2. I guess you don't care whether
> it runs VHE or not...

Hi Marc,

Thank you for noticing this. Not sure how this missmerge happened. I
have added the missing case, and VHE is initialized correctly during
boot.
[   14.698175] kvm [1]: VHE mode initialized successfully

During normal boot, kexec reboot, and kdump reboot. I will respin the
series and send the version 14 soon.

Thanks,
Pasha

>
>          M.
>
> >  .endm
> >
> >       .text
> > @@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors)
> >       invalid_vector  hyp_stub_el2h_fiq_invalid       // FIQ EL2h
> >       invalid_vector  hyp_stub_el2h_error_invalid     // Error EL2h
> >
> > -     ventry  el1_sync                        // Synchronous 64-bit EL1
> > +     hyp_stub_el1_sync                               // Synchronous 64-bit EL1
> >       invalid_vector  hyp_stub_el1_irq_invalid        // IRQ 64-bit EL1
> >       invalid_vector  hyp_stub_el1_fiq_invalid        // FIQ 64-bit EL1
> >       invalid_vector  hyp_stub_el1_error_invalid      // Error 64-bit EL1
> > @@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors)
> >  # Check the __hyp_stub_vectors didn't overflow
> >  .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K
> >
> > -
> > -SYM_CODE_START_LOCAL(el1_sync)
> > -     cmp     x0, #HVC_SET_VECTORS
> > -     b.ne    1f
> > -     msr     vbar_el2, x1
> > -     b       9f
> > -
> > -1:   cmp     x0, #HVC_VHE_RESTART
> > -     b.eq    mutate_to_vhe
> > -
> > -2:   cmp     x0, #HVC_SOFT_RESTART
> > -     b.ne    3f
> > -     mov     x0, x2
> > -     mov     x2, x4
> > -     mov     x4, x1
> > -     mov     x1, x3
> > -     br      x4                              // no return
> > -
> > -3:   cmp     x0, #HVC_RESET_VECTORS
> > -     beq     9f                              // Nothing to reset!
> > -
> > -     /* Someone called kvm_call_hyp() against the hyp-stub... */
> > -     mov_q   x0, HVC_STUB_ERR
> > -     eret
> > -
> > -9:   mov     x0, xzr
> > -     eret
> > -SYM_CODE_END(el1_sync)
> > -
> >  // nVHE? No way! Give me the real thing!
> >  SYM_CODE_START_LOCAL(mutate_to_vhe)
> >       // Sanity check: MMU *must* be off
>
> --
> Jazz is not dead. It just smells funny...


From asutoshd at codeaurora.org  Thu Apr  8 15:49:18 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Thu,  8 Apr 2021 07:49:18 -0700
Subject: [PATCH v17 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1617893198.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v16 -> v17:
- Addressed Adrian's & Daejun's comments

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing


Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  30 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 642 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 526 insertions(+), 244 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Thu Apr  8 15:49:19 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Thu,  8 Apr 2021 07:49:19 -0700
Subject: [PATCH v17 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1617893198.git.asutoshd@codeaurora.org>
References: <cover.1617893198.git.asutoshd@codeaurora.org>
Message-ID: <1b3d53dad245a7166f3f67a4c65f3a731e6600b3.1617893198.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +--
 drivers/scsi/ufs/ufshcd.c          | 642 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |   6 +
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 509 insertions(+), 231 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..b9105e4 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..1e8d92b 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..49a918c 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..d463b44 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..cbb5a90 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			scsi_autopm_put_device(hba->sdev_ufs_device);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..a0e6478 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4098,12 +4112,13 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	}
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
-	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+	if (update &&
+	    !pm_runtime_suspended(&hba->sdev_ufs_device->sdev_gendev)) {
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		scsi_autopm_put_device(hba->sdev_ufs_device);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4816,40 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+			return;
+		}
+	} else {
+		/* device wlun is probed */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4880,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4913,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5035,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5636,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
 }
 
 /**
@@ -5604,7 +5654,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5670,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5794,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5836,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5857,14 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7288,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7451,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7931,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8517,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8693,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8701,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8724,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto enable_scaling;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8746,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8774,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8787,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8795,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8819,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
-
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8853,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,31 +8901,152 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
-	if (ufshcd_is_clkscaling_supported(hba))
-		ufshcd_clk_scaling_suspend(hba, false);
-
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
+	if (hba->clk_scaling.is_allowed)
+		ufshcd_resume_clkscaling(hba);
 
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	if (pm_runtime_suspended(dev))
+		return 0;
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	scsi_autopm_get_device(sdev);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static void ufshcd_suspend(struct ufs_hba *hba)
+{
+	hba->pm_op_in_progress = 1;
+
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
 	ufshcd_setup_clocks(hba, false);
 	if (ufshcd_is_clkgating_allowed(hba)) {
@@ -8948,6 +9054,43 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	hba->pm_op_in_progress = 0;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	hba->pm_op_in_progress = 1;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
@@ -8962,6 +9105,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8982,21 +9126,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	     !hba->dev_info.b_rpm_dev_flush_capable)
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
@@ -9018,25 +9148,20 @@ EXPORT_SYMBOL(ufshcd_system_suspend);
 
 int ufshcd_system_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_system_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
+
+	hba->is_sys_suspended = false;
 	up(&hba->host_sem);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
 
@@ -9045,23 +9170,23 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
+		ufshcd_suspend(hba);
 out:
-	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_suspend(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_suspend);
 
@@ -9069,37 +9194,25 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
 	ktime_t start = ktime_get();
 
 	if (!hba->is_powered)
 		goto out;
 	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
+		ufshcd_resume(hba);
 out:
-	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
+	trace_ufshcd_runtime_resume(dev_name(hba->dev), 0,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	return ret;
+	return 0;
 }
 EXPORT_SYMBOL(ufshcd_runtime_resume);
 
@@ -9113,18 +9226,13 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
 	if (!hba->is_powered)
 		goto out;
 
@@ -9133,10 +9241,8 @@ int ufshcd_shutdown(struct ufs_hba *hba)
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9256,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		scsi_autopm_get_device(hba->sdev_ufs_device);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9561,175 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	pm_runtime_put_noidle(&hba->sdev_ufs_device->sdev_gendev);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * Force it to honor system-suspend.
+	 */
+	scsi_autopm_get_device(hba->sdev_ufs_device);
+	/* Refer ufshcd_resume_complete() */
+	pm_runtime_get_noresume(&hba->sdev_ufs_device->sdev_gendev);
+	scsi_autopm_put_device(hba->sdev_ufs_device);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba = shost_priv(sdev->host);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		return ret;
+	}
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret) {
+		ufs_debugfs_exit();
+		scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+		return ret;
+	}
 	return 0;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..40436e3 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:55:56 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:55:56 +0300
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
Message-ID: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>

The change in the series has been inspired by [1], which, I think,
can be improved. Here I present the view how it can be done.

The series marked as RFT since I have no hardware and I perform
compile test only.

The patches 1 and 2 can be (independently) applied for v5.13, but I'm not in
hurry with the series, due to above (lack of real testing). So I'm flexible in
a way how it can be proceed.

[1]: cover.1617380819.git.syednwaris at gmail.com

Andy Shevchenko (5):
  bitmap: Make bitmap_remap() and bitmap_bitremap() available to users
  gpio: xilinx: Correct kernel doc for xgpio_probe()
  gpio: xilinx: Introduce xgpio_read_chan() / xgpio_write_chan()
  gpio: xilinx: Switch to use bitmap APIs
  gpio: xilinx: No need to disable IRQs in the handler

 drivers/gpio/gpio-xilinx.c | 377 ++++++++++++++++++-------------------
 lib/bitmap.c               |   5 +-
 2 files changed, 190 insertions(+), 192 deletions(-)

-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:55:59 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:55:59 +0300
Subject: [PATCH v1 3/5] gpio: xilinx: Introduce xgpio_read_chan() /
 xgpio_write_chan()
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408145601.68651-4-andriy.shevchenko@linux.intel.com>

With the new helpers, i.e. xgpio_read_chan() / xgpio_write_chan(),
the code is easier to read and maintain. No functional changes
intended.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/gpio/gpio-xilinx.c | 68 +++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 136557e7dd3c..e6c78409ab3a 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -23,7 +23,8 @@
 #define XGPIO_DATA_OFFSET   (0x0)	/* Data register  */
 #define XGPIO_TRI_OFFSET    (0x4)	/* I/O direction register  */
 
-#define XGPIO_CHANNEL_OFFSET	0x8
+#define XGPIO_CHANNEL0_OFFSET	0x0
+#define XGPIO_CHANNEL1_OFFSET	0x8
 
 #define XGPIO_GIER_OFFSET	0x11c /* Global Interrupt Enable */
 #define XGPIO_GIER_IE		BIT(31)
@@ -79,12 +80,26 @@ static inline int xgpio_index(struct xgpio_instance *chip, int gpio)
 	return 0;
 }
 
-static inline int xgpio_regoffset(struct xgpio_instance *chip, int gpio)
+static inline int xgpio_regoffset(struct xgpio_instance *chip, int ch)
 {
-	if (xgpio_index(chip, gpio))
-		return XGPIO_CHANNEL_OFFSET;
+	switch (ch) {
+	case 0:
+		return XGPIO_CHANNEL0_OFFSET;
+	case 1:
+		return XGPIO_CHANNEL1_OFFSET;
+	default:
+		return -EINVAL;
+	}
+}
 
-	return 0;
+static inline u32 xgpio_read_chan(struct xgpio_instance *chip, int reg, int ch)
+{
+	return xgpio_readreg(chip->regs + reg + xgpio_regoffset(chip, ch));
+}
+
+static inline void xgpio_write_chan(struct xgpio_instance *chip, int reg, int ch, u32 v)
+{
+	xgpio_writereg(chip->regs + reg + xgpio_regoffset(chip, ch), v);
 }
 
 static inline int xgpio_offset(struct xgpio_instance *chip, int gpio)
@@ -109,12 +124,13 @@ static inline int xgpio_offset(struct xgpio_instance *chip, int gpio)
 static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
 {
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
+	int index = xgpio_index(chip, gpio);
+	int offset = xgpio_offset(chip, gpio);
 	u32 val;
 
-	val = xgpio_readreg(chip->regs + XGPIO_DATA_OFFSET +
-			    xgpio_regoffset(chip, gpio));
+	val = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
 
-	return !!(val & BIT(xgpio_offset(chip, gpio)));
+	return !!(val & BIT(offset));
 }
 
 /**
@@ -141,8 +157,7 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 	else
 		chip->gpio_state[index] &= ~BIT(offset);
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       xgpio_regoffset(chip, gpio), chip->gpio_state[index]);
+	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
@@ -172,9 +187,8 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 			break;
 		/* Once finished with an index write it out to the register */
 		if (index !=  xgpio_index(chip, i)) {
-			xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-				       index * XGPIO_CHANNEL_OFFSET,
-				       chip->gpio_state[index]);
+			xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index,
+					 chip->gpio_state[index]);
 			spin_unlock_irqrestore(&chip->gpio_lock, flags);
 			index =  xgpio_index(chip, i);
 			spin_lock_irqsave(&chip->gpio_lock, flags);
@@ -188,8 +202,7 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 		}
 	}
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-		       index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
+	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
@@ -214,8 +227,7 @@ static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
 
 	/* Set the GPIO bit in shadow register and set direction as input */
 	chip->gpio_dir[index] |= BIT(offset);
-	xgpio_writereg(chip->regs + XGPIO_TRI_OFFSET +
-		       xgpio_regoffset(chip, gpio), chip->gpio_dir[index]);
+	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, index, chip->gpio_dir[index]);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 
@@ -248,13 +260,11 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
 		chip->gpio_state[index] |= BIT(offset);
 	else
 		chip->gpio_state[index] &= ~BIT(offset);
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
-			xgpio_regoffset(chip, gpio), chip->gpio_state[index]);
+	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
 
 	/* Clear the GPIO bit in shadow register and set direction as output */
 	chip->gpio_dir[index] &= ~BIT(offset);
-	xgpio_writereg(chip->regs + XGPIO_TRI_OFFSET +
-			xgpio_regoffset(chip, gpio), chip->gpio_dir[index]);
+	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, index, chip->gpio_dir[index]);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 
@@ -267,16 +277,14 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
  */
 static void xgpio_save_regs(struct xgpio_instance *chip)
 {
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET,	chip->gpio_state[0]);
-	xgpio_writereg(chip->regs + XGPIO_TRI_OFFSET, chip->gpio_dir[0]);
+	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, 0, chip->gpio_state[0]);
+	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, 0, chip->gpio_dir[0]);
 
 	if (!chip->gpio_width[1])
 		return;
 
-	xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET + XGPIO_CHANNEL_OFFSET,
-		       chip->gpio_state[1]);
-	xgpio_writereg(chip->regs + XGPIO_TRI_OFFSET + XGPIO_CHANNEL_OFFSET,
-		       chip->gpio_dir[1]);
+	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, 1, chip->gpio_state[1]);
+	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, 1, chip->gpio_dir[1]);
 }
 
 static int xgpio_request(struct gpio_chip *chip, unsigned int offset)
@@ -434,8 +442,7 @@ static void xgpio_irq_unmask(struct irq_data *irq_data)
 			xgpio_writereg(chip->regs + XGPIO_IPISR_OFFSET, val);
 
 		/* Update GPIO IRQ read data before enabling interrupt*/
-		val = xgpio_readreg(chip->regs + XGPIO_DATA_OFFSET +
-				    index * XGPIO_CHANNEL_OFFSET);
+		val = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
 		chip->gpio_last_irq_read[index] = val;
 
 		/* Enable per channel interrupt */
@@ -512,8 +519,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 			unsigned int irq;
 
 			spin_lock_irqsave(&chip->gpio_lock, flags);
-			data = xgpio_readreg(chip->regs + XGPIO_DATA_OFFSET +
-					     index * XGPIO_CHANNEL_OFFSET);
+			data = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
 			rising_events = data &
 					~chip->gpio_last_irq_read[index] &
 					chip->irq_enable[index] &
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:55:58 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:55:58 +0300
Subject: [PATCH v1 2/5] gpio: xilinx: Correct kernel doc for xgpio_probe()
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408145601.68651-3-andriy.shevchenko@linux.intel.com>

Kernel doc validator complains:

.../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe(). Prototype was for xgpio_probe() instead

Correct as suggested by changing the name of the function in the doc..

Fixes: 749564ffd52d ("gpio/xilinx: Convert the driver to platform device interface")
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/gpio/gpio-xilinx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index b411d3156e0b..136557e7dd3c 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -542,7 +542,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 }
 
 /**
- * xgpio_of_probe - Probe method for the GPIO device.
+ * xgpio_probe - Probe method for the GPIO device.
  * @pdev: pointer to the platform device
  *
  * Return:
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:56:00 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:56:00 +0300
Subject: [PATCH v1 4/5] gpio: xilinx: Switch to use bitmap APIs
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408145601.68651-5-andriy.shevchenko@linux.intel.com>

It seems that Xilinx GPIO driver operates with bit arrays longer than 32 and
thus can leverage bitmap APIs for that. It makes code better to understand.

The ->probe() function is modified to try read properties for both channels
since is_dual check makes only sense for the amount of pins used for the second
channel. On top of that kzalloc() guarantees zero initial values for the fields
in the private data structure, hence drop unneeded conditionals and assignments.

The change is inspired by Syed Nayyar Waris' ideas about bitmap API extension.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/gpio/gpio-xilinx.c | 350 ++++++++++++++++++-------------------
 1 file changed, 171 insertions(+), 179 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index e6c78409ab3a..98d90b4c4d2b 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -5,6 +5,7 @@
  * Copyright 2008 - 2013 Xilinx, Inc.
  */
 
+#include <linux/bitmap.h>
 #include <linux/bitops.h>
 #include <linux/clk.h>
 #include <linux/errno.h>
@@ -44,40 +45,56 @@
  * struct xgpio_instance - Stores information about GPIO device
  * @gc: GPIO chip
  * @regs: register block
- * @gpio_width: GPIO width for every channel
- * @gpio_state: GPIO write state shadow register
- * @gpio_last_irq_read: GPIO read state register from last interrupt
- * @gpio_dir: GPIO direction shadow register
+ * @hw_map: GPIO pin mapping on hardware side
+ * @sw_map: GPIO pin mapping on software side
+ * @state: GPIO write state shadow register
+ * @last_irq_read: GPIO read state register from last interrupt
+ * @dir: GPIO direction shadow register
  * @gpio_lock: Lock used for synchronization
  * @irq: IRQ used by GPIO device
  * @irqchip: IRQ chip
- * @irq_enable: GPIO IRQ enable/disable bitfield
- * @irq_rising_edge: GPIO IRQ rising edge enable/disable bitfield
- * @irq_falling_edge: GPIO IRQ falling edge enable/disable bitfield
+ * @enable: GPIO IRQ enable/disable bitfield
+ * @rising_edge: GPIO IRQ rising edge enable/disable bitfield
+ * @falling_edge: GPIO IRQ falling edge enable/disable bitfield
  * @clk: clock resource for this driver
  */
 struct xgpio_instance {
 	struct gpio_chip gc;
 	void __iomem *regs;
-	unsigned int gpio_width[2];
-	u32 gpio_state[2];
-	u32 gpio_last_irq_read[2];
-	u32 gpio_dir[2];
+	DECLARE_BITMAP(hw_map, 64);
+	DECLARE_BITMAP(sw_map, 64);
+	DECLARE_BITMAP(state, 64);
+	DECLARE_BITMAP(last_irq_read, 64);
+	DECLARE_BITMAP(dir, 64);
 	spinlock_t gpio_lock;	/* For serializing operations */
 	int irq;
 	struct irq_chip irqchip;
-	u32 irq_enable[2];
-	u32 irq_rising_edge[2];
-	u32 irq_falling_edge[2];
+	DECLARE_BITMAP(enable, 64);
+	DECLARE_BITMAP(rising_edge, 64);
+	DECLARE_BITMAP(falling_edge, 64);
 	struct clk *clk;
 };
 
-static inline int xgpio_index(struct xgpio_instance *chip, int gpio)
+static inline int xgpio_to_bit(struct xgpio_instance *chip, int gpio)
 {
-	if (gpio >= chip->gpio_width[0])
-		return 1;
+	return bitmap_bitremap(gpio, chip->sw_map, chip->hw_map, chip->gc.ngpio);
+}
 
-	return 0;
+static inline u32 xgpio_get_value32(const unsigned long *map, int bit)
+{
+	const size_t index = BIT_WORD(bit);
+	const unsigned long offset = (bit % BITS_PER_LONG) & BIT(5);
+
+	return (map[index] >> offset) & 0xFFFFFFFFul;
+}
+
+static inline void xgpio_set_value32(unsigned long *map, int bit, u32 v)
+{
+	const size_t index = BIT_WORD(bit);
+	const unsigned long offset = (bit % BITS_PER_LONG) & BIT(5);
+
+	map[index] &= ~(0xFFFFFFFFul << offset);
+	map[index] |= v << offset;
 }
 
 static inline int xgpio_regoffset(struct xgpio_instance *chip, int ch)
@@ -92,22 +109,32 @@ static inline int xgpio_regoffset(struct xgpio_instance *chip, int ch)
 	}
 }
 
-static inline u32 xgpio_read_chan(struct xgpio_instance *chip, int reg, int ch)
+static void xgpio_read_ch(struct xgpio_instance *chip, int reg, int bit, unsigned long *a)
 {
-	return xgpio_readreg(chip->regs + reg + xgpio_regoffset(chip, ch));
+	void __iomem *addr = chip->regs + reg + xgpio_regoffset(chip, bit / 32);
+	xgpio_set_value32(a, bit, xgpio_readreg(addr));
 }
 
-static inline void xgpio_write_chan(struct xgpio_instance *chip, int reg, int ch, u32 v)
+static void xgpio_write_ch(struct xgpio_instance *chip, int reg, int bit, unsigned long *a)
 {
-	xgpio_writereg(chip->regs + reg + xgpio_regoffset(chip, ch), v);
+	void __iomem *addr = chip->regs + reg + xgpio_regoffset(chip, bit / 32);
+	xgpio_writereg(addr, xgpio_get_value32(a, bit));
 }
 
-static inline int xgpio_offset(struct xgpio_instance *chip, int gpio)
+static void xgpio_read_ch_all(struct xgpio_instance *chip, int reg, unsigned long *a)
 {
-	if (xgpio_index(chip, gpio))
-		return gpio - chip->gpio_width[0];
+	int bit, lastbit = xgpio_to_bit(chip, chip->gc.ngpio - 1);
 
-	return gpio;
+	for (bit = 0; bit <= lastbit ; bit += 32)
+		xgpio_read_ch(chip, reg, bit, a);
+}
+
+static void xgpio_write_ch_all(struct xgpio_instance *chip, int reg, unsigned long *a)
+{
+	int bit, lastbit = xgpio_to_bit(chip, chip->gc.ngpio - 1);
+
+	for (bit = 0; bit <= lastbit ; bit += 32)
+		xgpio_write_ch(chip, reg, bit, a);
 }
 
 /**
@@ -124,13 +151,12 @@ static inline int xgpio_offset(struct xgpio_instance *chip, int gpio)
 static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
 {
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, gpio);
-	int offset = xgpio_offset(chip, gpio);
-	u32 val;
+	int bit = xgpio_to_bit(chip, gpio);
+	DECLARE_BITMAP(state, 64);
 
-	val = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
+	xgpio_read_ch(chip, XGPIO_DATA_OFFSET, bit, state);
 
-	return !!(val & BIT(offset));
+	return test_bit(bit, state);
 }
 
 /**
@@ -146,18 +172,14 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 {
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index =  xgpio_index(chip, gpio);
-	int offset =  xgpio_offset(chip, gpio);
+	int bit = xgpio_to_bit(chip, gpio);
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
 	/* Write to GPIO signal and set its direction to output */
-	if (val)
-		chip->gpio_state[index] |= BIT(offset);
-	else
-		chip->gpio_state[index] &= ~BIT(offset);
+	__assign_bit(bit, chip->state, val);
 
-	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
+	xgpio_write_ch(chip, XGPIO_DATA_OFFSET, bit, chip->state);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
@@ -174,35 +196,22 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 			       unsigned long *bits)
 {
+	DECLARE_BITMAP(hw_mask, 64);
+	DECLARE_BITMAP(hw_bits, 64);
+	DECLARE_BITMAP(state, 64);
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index = xgpio_index(chip, 0);
-	int offset, i;
+
+	bitmap_remap(hw_mask, mask, chip->sw_map, chip->hw_map, 64);
+	bitmap_remap(hw_bits, bits, chip->sw_map, chip->hw_map, 64);
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
-	/* Write to GPIO signals */
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		/* Once finished with an index write it out to the register */
-		if (index !=  xgpio_index(chip, i)) {
-			xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index,
-					 chip->gpio_state[index]);
-			spin_unlock_irqrestore(&chip->gpio_lock, flags);
-			index =  xgpio_index(chip, i);
-			spin_lock_irqsave(&chip->gpio_lock, flags);
-		}
-		if (__test_and_clear_bit(i, mask)) {
-			offset =  xgpio_offset(chip, i);
-			if (test_bit(i, bits))
-				chip->gpio_state[index] |= BIT(offset);
-			else
-				chip->gpio_state[index] &= ~BIT(offset);
-		}
-	}
+	bitmap_replace(state, chip->state, hw_bits, hw_mask, gc->ngpio);
 
-	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
+	xgpio_write_ch_all(chip, XGPIO_DATA_OFFSET, state);
+
+	bitmap_copy(chip->state, state, gc->ngpio);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
@@ -220,14 +229,13 @@ static int xgpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
 {
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index =  xgpio_index(chip, gpio);
-	int offset =  xgpio_offset(chip, gpio);
+	int bit = xgpio_to_bit(chip, gpio);
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
 	/* Set the GPIO bit in shadow register and set direction as input */
-	chip->gpio_dir[index] |= BIT(offset);
-	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, index, chip->gpio_dir[index]);
+	__set_bit(bit, chip->dir);
+	xgpio_write_ch(chip, XGPIO_TRI_OFFSET, bit, chip->dir);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 
@@ -250,21 +258,17 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
 {
 	unsigned long flags;
 	struct xgpio_instance *chip = gpiochip_get_data(gc);
-	int index =  xgpio_index(chip, gpio);
-	int offset =  xgpio_offset(chip, gpio);
+	int bit = xgpio_to_bit(chip, gpio);
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
 	/* Write state of GPIO signal */
-	if (val)
-		chip->gpio_state[index] |= BIT(offset);
-	else
-		chip->gpio_state[index] &= ~BIT(offset);
-	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, index, chip->gpio_state[index]);
+	__assign_bit(bit, chip->state, val);
+	xgpio_write_ch(chip, XGPIO_DATA_OFFSET, bit, chip->state);
 
 	/* Clear the GPIO bit in shadow register and set direction as output */
-	chip->gpio_dir[index] &= ~BIT(offset);
-	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, index, chip->gpio_dir[index]);
+	__clear_bit(bit, chip->dir);
+	xgpio_write_ch(chip, XGPIO_TRI_OFFSET, bit, chip->dir);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 
@@ -277,14 +281,8 @@ static int xgpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
  */
 static void xgpio_save_regs(struct xgpio_instance *chip)
 {
-	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, 0, chip->gpio_state[0]);
-	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, 0, chip->gpio_dir[0]);
-
-	if (!chip->gpio_width[1])
-		return;
-
-	xgpio_write_chan(chip, XGPIO_DATA_OFFSET, 1, chip->gpio_state[1]);
-	xgpio_write_chan(chip, XGPIO_TRI_OFFSET, 1, chip->gpio_dir[1]);
+	xgpio_write_ch_all(chip, XGPIO_DATA_OFFSET, chip->state);
+	xgpio_write_ch_all(chip, XGPIO_TRI_OFFSET, chip->dir);
 }
 
 static int xgpio_request(struct gpio_chip *chip, unsigned int offset)
@@ -399,18 +397,17 @@ static void xgpio_irq_mask(struct irq_data *irq_data)
 	unsigned long flags;
 	struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
 	int irq_offset = irqd_to_hwirq(irq_data);
-	int index = xgpio_index(chip, irq_offset);
-	int offset = xgpio_offset(chip, irq_offset);
+	int bit = xgpio_to_bit(chip, irq_offset);
+	u32 mask = BIT(bit / 32), temp;
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
-	chip->irq_enable[index] &= ~BIT(offset);
+	__clear_bit(bit, chip->enable);
 
-	if (!chip->irq_enable[index]) {
+	if (xgpio_get_value32(chip->enable, bit) == 0) {
 		/* Disable per channel interrupt */
-		u32 temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
-
-		temp &= ~BIT(index);
+		temp = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
+		temp &= ~mask;
 		xgpio_writereg(chip->regs + XGPIO_IPIER_OFFSET, temp);
 	}
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
@@ -425,29 +422,26 @@ static void xgpio_irq_unmask(struct irq_data *irq_data)
 	unsigned long flags;
 	struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
 	int irq_offset = irqd_to_hwirq(irq_data);
-	int index = xgpio_index(chip, irq_offset);
-	int offset = xgpio_offset(chip, irq_offset);
-	u32 old_enable = chip->irq_enable[index];
+	int bit = xgpio_to_bit(chip, irq_offset);
+	u32 old_enable = xgpio_get_value32(chip->enable, bit);
+	u32 mask = BIT(bit / 32), val;
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
-	chip->irq_enable[index] |= BIT(offset);
+	__set_bit(bit, chip->enable);
 
-	if (!old_enable) {
+	if (old_enable == 0) {
 		/* Clear any existing per-channel interrupts */
-		u32 val = xgpio_readreg(chip->regs + XGPIO_IPISR_OFFSET) &
-			BIT(index);
-
-		if (val)
-			xgpio_writereg(chip->regs + XGPIO_IPISR_OFFSET, val);
+		val = xgpio_readreg(chip->regs + XGPIO_IPISR_OFFSET);
+		val &= mask;
+		xgpio_writereg(chip->regs + XGPIO_IPISR_OFFSET, val);
 
 		/* Update GPIO IRQ read data before enabling interrupt*/
-		val = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
-		chip->gpio_last_irq_read[index] = val;
+		xgpio_read_ch(chip, XGPIO_DATA_OFFSET, bit, chip->last_irq_read);
 
 		/* Enable per channel interrupt */
 		val = xgpio_readreg(chip->regs + XGPIO_IPIER_OFFSET);
-		val |= BIT(index);
+		val |= mask;
 		xgpio_writereg(chip->regs + XGPIO_IPIER_OFFSET, val);
 	}
 
@@ -466,8 +460,7 @@ static int xgpio_set_irq_type(struct irq_data *irq_data, unsigned int type)
 {
 	struct xgpio_instance *chip = irq_data_get_irq_chip_data(irq_data);
 	int irq_offset = irqd_to_hwirq(irq_data);
-	int index = xgpio_index(chip, irq_offset);
-	int offset = xgpio_offset(chip, irq_offset);
+	int bit = xgpio_to_bit(chip, irq_offset);
 
 	/*
 	 * The Xilinx GPIO hardware provides a single interrupt status
@@ -477,16 +470,16 @@ static int xgpio_set_irq_type(struct irq_data *irq_data, unsigned int type)
 	 */
 	switch (type & IRQ_TYPE_SENSE_MASK) {
 	case IRQ_TYPE_EDGE_BOTH:
-		chip->irq_rising_edge[index] |= BIT(offset);
-		chip->irq_falling_edge[index] |= BIT(offset);
+		__set_bit(bit, chip->rising_edge);
+		__set_bit(bit, chip->falling_edge);
 		break;
 	case IRQ_TYPE_EDGE_RISING:
-		chip->irq_rising_edge[index] |= BIT(offset);
-		chip->irq_falling_edge[index] &= ~BIT(offset);
+		__set_bit(bit, chip->rising_edge);
+		__clear_bit(bit, chip->falling_edge);
 		break;
 	case IRQ_TYPE_EDGE_FALLING:
-		chip->irq_rising_edge[index] &= ~BIT(offset);
-		chip->irq_falling_edge[index] |= BIT(offset);
+		__clear_bit(bit, chip->rising_edge);
+		__set_bit(bit, chip->falling_edge);
 		break;
 	default:
 		return -EINVAL;
@@ -503,46 +496,43 @@ static int xgpio_set_irq_type(struct irq_data *irq_data, unsigned int type)
 static void xgpio_irqhandler(struct irq_desc *desc)
 {
 	struct xgpio_instance *chip = irq_desc_get_handler_data(desc);
+	struct gpio_chip *gc = &chip->gc;
 	struct irq_chip *irqchip = irq_desc_get_chip(desc);
-	u32 num_channels = chip->gpio_width[1] ? 2 : 1;
-	u32 offset = 0, index;
-	u32 status = xgpio_readreg(chip->regs + XGPIO_IPISR_OFFSET);
+	DECLARE_BITMAP(rising, 64);
+	DECLARE_BITMAP(falling, 64);
+	DECLARE_BITMAP(all, 64);
+	u32 status;
+	u32 bit;
+	unsigned long flags;
 
+	status = xgpio_readreg(chip->regs + XGPIO_IPISR_OFFSET);
 	xgpio_writereg(chip->regs + XGPIO_IPISR_OFFSET, status);
 
 	chained_irq_enter(irqchip, desc);
-	for (index = 0; index < num_channels; index++) {
-		if ((status & BIT(index))) {
-			unsigned long rising_events, falling_events, all_events;
-			unsigned long flags;
-			u32 data, bit;
-			unsigned int irq;
-
-			spin_lock_irqsave(&chip->gpio_lock, flags);
-			data = xgpio_read_chan(chip, XGPIO_DATA_OFFSET, index);
-			rising_events = data &
-					~chip->gpio_last_irq_read[index] &
-					chip->irq_enable[index] &
-					chip->irq_rising_edge[index];
-			falling_events = ~data &
-					 chip->gpio_last_irq_read[index] &
-					 chip->irq_enable[index] &
-					 chip->irq_falling_edge[index];
-			dev_dbg(chip->gc.parent,
-				"IRQ chan %u rising 0x%lx falling 0x%lx\n",
-				index, rising_events, falling_events);
-			all_events = rising_events | falling_events;
-			chip->gpio_last_irq_read[index] = data;
-			spin_unlock_irqrestore(&chip->gpio_lock, flags);
-
-			for_each_set_bit(bit, &all_events, 32) {
-				irq = irq_find_mapping(chip->gc.irq.domain,
-						       offset + bit);
-				generic_handle_irq(irq);
-			}
-		}
-		offset += chip->gpio_width[index];
-	}
+
+	spin_lock_irqsave(&chip->gpio_lock, flags);
+
+	xgpio_read_ch_all(chip, XGPIO_DATA_OFFSET, all);
+
+	bitmap_complement(rising, chip->last_irq_read, 64);
+	bitmap_and(rising, rising, all, 64);
+	bitmap_and(rising, rising, chip->enable, 64);
+	bitmap_and(rising, rising, chip->rising_edge, 64);
+
+	bitmap_complement(falling, all, 64);
+	bitmap_and(falling, falling, chip->last_irq_read, 64);
+	bitmap_and(falling, falling, chip->enable, 64);
+	bitmap_and(falling, falling, chip->falling_edge, 64);
+
+	bitmap_copy(chip->last_irq_read, all, 64);
+	bitmap_or(all, rising, falling, 64);
+
+	spin_unlock_irqrestore(&chip->gpio_lock, flags);
+
+	dev_dbg(gc->parent, "IRQ rising %*pb falling %*pb\n", 64, rising, 64, falling);
+
+	for_each_set_bit(bit, all, 64)
+		generic_handle_irq(irq_find_mapping(gc->irq.domain, bit));
 
 	chained_irq_exit(irqchip, desc);
 }
@@ -562,6 +552,9 @@ static int xgpio_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	u32 is_dual = 0;
 	u32 cells = 2;
+	u32 width[2];
+	u32 state[2];
+	u32 dir[2];
 	struct gpio_irq_chip *girq;
 	u32 temp;
 
@@ -571,13 +564,25 @@ static int xgpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, chip);
 
+	/* First, check if the device is dual-channel */
+	of_property_read_u32(np, "xlnx,is-dual", &is_dual);
+
+	/* Setup defaults */
+	memset32(width, 0, ARRAY_SIZE(width));
+	memset32(state, 0, ARRAY_SIZE(state));
+	memset32(dir, 0xFFFFFFFF, ARRAY_SIZE(dir));
+
 	/* Update GPIO state shadow register with default value */
-	if (of_property_read_u32(np, "xlnx,dout-default", &chip->gpio_state[0]))
-		chip->gpio_state[0] = 0x0;
+	of_property_read_u32(np, "xlnx,dout-default", &state[0]);
+	of_property_read_u32(np, "xlnx,dout-default-2", &state[1]);
+
+	bitmap_from_arr32(chip->state, state, 64);
 
 	/* Update GPIO direction shadow register with default value */
-	if (of_property_read_u32(np, "xlnx,tri-default", &chip->gpio_dir[0]))
-		chip->gpio_dir[0] = 0xFFFFFFFF;
+	of_property_read_u32(np, "xlnx,tri-default", &dir[0]);
+	of_property_read_u32(np, "xlnx,tri-default-2", &dir[1]);
+
+	bitmap_from_arr32(chip->dir, dir, 64);
 
 	/* Update cells with gpio-cells value */
 	if (of_property_read_u32(np, "#gpio-cells", &cells))
@@ -592,42 +597,29 @@ static int xgpio_probe(struct platform_device *pdev)
 	 * Check device node and parent device node for device width
 	 * and assume default width of 32
 	 */
-	if (of_property_read_u32(np, "xlnx,gpio-width", &chip->gpio_width[0]))
-		chip->gpio_width[0] = 32;
+	if (of_property_read_u32(np, "xlnx,gpio-width", &width[0]))
+		width[0] = 32;
 
-	if (chip->gpio_width[0] > 32)
+	if (width[0] > 32)
 		return -EINVAL;
 
-	spin_lock_init(&chip->gpio_lock);
+	if (is_dual && of_property_read_u32(np, "xlnx,gpio2-width", &width[1]))
+		width[1] = 32;
 
-	if (of_property_read_u32(np, "xlnx,is-dual", &is_dual))
-		is_dual = 0;
-
-	if (is_dual) {
-		/* Update GPIO state shadow register with default value */
-		if (of_property_read_u32(np, "xlnx,dout-default-2",
-					 &chip->gpio_state[1]))
-			chip->gpio_state[1] = 0x0;
-
-		/* Update GPIO direction shadow register with default value */
-		if (of_property_read_u32(np, "xlnx,tri-default-2",
-					 &chip->gpio_dir[1]))
-			chip->gpio_dir[1] = 0xFFFFFFFF;
-
-		/*
-		 * Check device node and parent device node for device width
-		 * and assume default width of 32
-		 */
-		if (of_property_read_u32(np, "xlnx,gpio2-width",
-					 &chip->gpio_width[1]))
-			chip->gpio_width[1] = 32;
-
-		if (chip->gpio_width[1] > 32)
-			return -EINVAL;
-	}
+	if (width[1] > 32)
+		return -EINVAL;
+
+	/* Setup software pin mapping */
+	bitmap_set(chip->sw_map, 0, width[0] + width[1]);
+
+	/* Setup hardware pin mapping */
+	bitmap_set(chip->hw_map,  0, width[0]);
+	bitmap_set(chip->hw_map, 32, width[1]);
+
+	spin_lock_init(&chip->gpio_lock);
 
 	chip->gc.base = -1;
-	chip->gc.ngpio = chip->gpio_width[0] + chip->gpio_width[1];
+	chip->gc.ngpio = bitmap_weight(chip->hw_map, 64);
 	chip->gc.parent = &pdev->dev;
 	chip->gc.direction_input = xgpio_dir_in;
 	chip->gc.direction_output = xgpio_dir_out;
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:55:57 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:55:57 +0300
Subject: [PATCH v1 1/5] bitmap: Make bitmap_remap() and bitmap_bitremap()
 available to users
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408145601.68651-2-andriy.shevchenko@linux.intel.com>

Currently the bitmap_remap() and bitmap_bitremap() are available
only for CONFIG_NUMA=y case, while some users may benefit out of it
and being independent to NUMA code. Make them available to users
by moving out of ifdeffery and exporting for modules.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 lib/bitmap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 74ceb02f45e3..7b6b2a67a6a6 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -784,8 +784,6 @@ int bitmap_parse(const char *start, unsigned int buflen,
 }
 EXPORT_SYMBOL(bitmap_parse);
 
-
-#ifdef CONFIG_NUMA
 /**
  * bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
  *	@buf: pointer to a bitmap
@@ -894,6 +892,7 @@ void bitmap_remap(unsigned long *dst, const unsigned long *src,
 			set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
 	}
 }
+EXPORT_SYMBOL(bitmap_remap);
 
 /**
  * bitmap_bitremap - Apply map defined by a pair of bitmaps to a single bit
@@ -931,7 +930,9 @@ int bitmap_bitremap(int oldbit, const unsigned long *old,
 	else
 		return bitmap_ord_to_pos(new, n % w, bits);
 }
+EXPORT_SYMBOL(bitmap_bitremap);
 
+#ifdef CONFIG_NUMA
 /**
  * bitmap_onto - translate one bitmap relative to another
  *	@dst: resulting translated bitmap
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Thu Apr  8 15:56:01 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 17:56:01 +0300
Subject: [PATCH v1 5/5] gpio: xilinx: No need to disable IRQs in the handler
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408145601.68651-6-andriy.shevchenko@linux.intel.com>

In IRQ handler interrupts are already disabled, hence no need
to repeat it. Even in the threaded case, it is not a problem
because IRQ framework keeps interrupt disabled there as well.
Remove disabling IRQ part in the handler.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/gpio/gpio-xilinx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 98d90b4c4d2b..d5a08dcdd677 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -503,14 +503,13 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 	DECLARE_BITMAP(all, 64);
 	u32 status;
 	u32 bit;
-	unsigned long flags;
 
 	status = xgpio_readreg(chip->regs + XGPIO_IPISR_OFFSET);
 	xgpio_writereg(chip->regs + XGPIO_IPISR_OFFSET, status);
 
 	chained_irq_enter(irqchip, desc);
 
-	spin_lock_irqsave(&chip->gpio_lock, flags);
+	spin_lock(&chip->gpio_lock);
 
 	xgpio_read_ch_all(chip, XGPIO_DATA_OFFSET, all);
 
@@ -527,7 +526,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 	bitmap_copy(chip->last_irq_read, all, 64);
 	bitmap_or(all, rising, falling, 64);
 
-	spin_unlock_irqrestore(&chip->gpio_lock, flags);
+	spin_unlock(&chip->gpio_lock);
 
 	dev_dbg(gc->parent, "IRQ rising %*pb falling %*pb\n", 64, rising, 64, falling);
 
-- 
2.30.2



From will at kernel.org  Thu Apr  8 15:56:04 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 15:56:04 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408143723.13024-1-vincenzo.frascino@arm.com>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
Message-ID: <20210408145604.GB18211@willie-the-truck>

On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> race with another CPU doing a set_tsk_thread_flag() and the flag can be
> lost in the process.

Actually, it's all the *other* flags that get lost!

> Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> exit_to_user_mode() to address the problem.
> 
> Note: Moving the check in entry-common allows to use set_thread_flag()
> which is safe.
> 
> Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous
> tag check faults")
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Reported-by: Will Deacon <will at kernel.org>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> ---
>  arch/arm64/include/asm/mte.h     |  8 ++++++++
>  arch/arm64/kernel/entry-common.c |  6 ++++++
>  arch/arm64/kernel/entry.S        | 30 ------------------------------
>  arch/arm64/kernel/mte.c          | 25 +++++++++++++++++++++++--
>  4 files changed, 37 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 9b557a457f24..188f778c6f7b 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
>  void mte_invalidate_tags_area(int type);
>  void *mte_allocate_tag_storage(void);
>  void mte_free_tag_storage(char *storage);
> +void check_mte_async_tcf0(void);
> +void clear_mte_async_tcf0(void);
>  
>  #ifdef CONFIG_ARM64_MTE
>  
> @@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
>  {
>  	return -EIO;
>  }
> +void check_mte_async_tcf0(void)
> +{
> +}
> +void clear_mte_async_tcf0(void)
> +{
> +}
>  
>  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
>  {
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 9d3588450473..837d3624a1d5 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
>  	CT_WARN_ON(ct_state() != CONTEXT_USER);
>  	user_exit_irqoff();
>  	trace_hardirqs_off_finish();
> +
> +	/* Check for asynchronous tag check faults in user space */
> +	check_mte_async_tcf0();
>  }

Is enter_from_user_mode() always called when we enter the kernel from EL0?
afaict, some paths (e.g. el0_irq()) only end up calling it if
CONTEXT_TRACKING or TRACE_IRQFLAGS are enabled.

>  
>  asmlinkage void noinstr exit_to_user_mode(void)
>  {
> +	/* Ignore asynchronous tag check faults in the uaccess routines */
> +	clear_mte_async_tcf0();
> +

and this one seems to be called even less often.

Will


From maz at kernel.org  Thu Apr  8 16:01:40 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 16:01:40 +0100
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
 <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
Message-ID: <87v98wom5n.wl-maz@kernel.org>

On Thu, 08 Apr 2021 15:45:18 +0100,
Pavel Tatashin <pasha.tatashin at soleen.com> wrote:
> 
> On Thu, Apr 8, 2021 at 6:24 AM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On 2021-04-08 05:05, Pavel Tatashin wrote:
> > > From: James Morse <james.morse at arm.com>
> > >
> > > The hyp-stub's el1_sync code doesn't do very much, this can easily fit
> > > in the vectors.
> > >
> > > With this, all of the hyp-stubs behaviour is contained in its vectors.
> > > This lets kexec and hibernate copy the hyp-stub when they need its
> > > behaviour, instead of re-implementing it.
> > >
> > > Signed-off-by: James Morse <james.morse at arm.com>
> > >
> > > [Fixed merging issues]
> >
> > That's a pretty odd fix IMO.
> >
> > >
> > > Signed-off-by: Pavel Tatashin <pasha.tatashin at soleen.com>
> > > ---
> > >  arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------
> > >  1 file changed, 29 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/hyp-stub.S
> > > b/arch/arm64/kernel/hyp-stub.S
> > > index ff329c5c074d..d1a73d0f74e0 100644
> > > --- a/arch/arm64/kernel/hyp-stub.S
> > > +++ b/arch/arm64/kernel/hyp-stub.S
> > > @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label)
> > >       .align 7
> > >       b       \label
> > >  SYM_CODE_END(\label)
> > > +.endm
> > > +
> > > +.macro hyp_stub_el1_sync
> > > +SYM_CODE_START_LOCAL(hyp_stub_el1_sync)
> > > +     .align 7
> > > +     cmp     x0, #HVC_SET_VECTORS
> > > +     b.ne    2f
> > > +     msr     vbar_el2, x1
> > > +     b       9f
> > > +
> > > +2:   cmp     x0, #HVC_SOFT_RESTART
> > > +     b.ne    3f
> > > +     mov     x0, x2
> > > +     mov     x2, x4
> > > +     mov     x4, x1
> > > +     mov     x1, x3
> > > +     br      x4                              // no return
> > > +
> > > +3:   cmp     x0, #HVC_RESET_VECTORS
> > > +     beq     9f                              // Nothing to reset!
> > > +
> > > +     /* Someone called kvm_call_hyp() against the hyp-stub... */
> > > +     mov_q   x0, HVC_STUB_ERR
> > > +     eret
> > > +
> > > +9:   mov     x0, xzr
> > > +     eret
> > > +SYM_CODE_END(hyp_stub_el1_sync)
> >
> > You said you tested this on a TX2. I guess you don't care whether
> > it runs VHE or not...
> 
> Hi Marc,
> 
> Thank you for noticing this. Not sure how this missmerge happened. I
> have added the missing case, and VHE is initialized correctly during
> boot.
> [   14.698175] kvm [1]: VHE mode initialized successfully
> 
> During normal boot, kexec reboot, and kdump reboot. I will respin the
> series and send the version 14 soon.

Please give people a chance to review this lot first. This isn't code
that is easy to digest, and immediate re-spinning does more harm than
good (this isn't targeting 5.13, I would assume).

Thanks,

	M.

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


From mark.rutland at arm.com  Thu Apr  8 16:06:23 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 8 Apr 2021 16:06:23 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408145604.GB18211@willie-the-truck>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
 <20210408145604.GB18211@willie-the-truck>
Message-ID: <20210408150612.GA37165@C02TD0UTHF1T.local>

On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> > race with another CPU doing a set_tsk_thread_flag() and the flag can be
> > lost in the process.
> 
> Actually, it's all the *other* flags that get lost!
> 
> > Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> > exit_to_user_mode() to address the problem.
> > 
> > Note: Moving the check in entry-common allows to use set_thread_flag()
> > which is safe.
> > 
> > Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous
> > tag check faults")
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Reported-by: Will Deacon <will at kernel.org>
> > Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> > ---
> >  arch/arm64/include/asm/mte.h     |  8 ++++++++
> >  arch/arm64/kernel/entry-common.c |  6 ++++++
> >  arch/arm64/kernel/entry.S        | 30 ------------------------------
> >  arch/arm64/kernel/mte.c          | 25 +++++++++++++++++++++++--
> >  4 files changed, 37 insertions(+), 32 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> > index 9b557a457f24..188f778c6f7b 100644
> > --- a/arch/arm64/include/asm/mte.h
> > +++ b/arch/arm64/include/asm/mte.h
> > @@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
> >  void mte_invalidate_tags_area(int type);
> >  void *mte_allocate_tag_storage(void);
> >  void mte_free_tag_storage(char *storage);
> > +void check_mte_async_tcf0(void);
> > +void clear_mte_async_tcf0(void);
> >  
> >  #ifdef CONFIG_ARM64_MTE
> >  
> > @@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
> >  {
> >  	return -EIO;
> >  }
> > +void check_mte_async_tcf0(void)
> > +{
> > +}
> > +void clear_mte_async_tcf0(void)
> > +{
> > +}
> >  
> >  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
> >  {
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 9d3588450473..837d3624a1d5 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
> >  	CT_WARN_ON(ct_state() != CONTEXT_USER);
> >  	user_exit_irqoff();
> >  	trace_hardirqs_off_finish();
> > +
> > +	/* Check for asynchronous tag check faults in user space */
> > +	check_mte_async_tcf0();
> >  }
> 
> Is enter_from_user_mode() always called when we enter the kernel from EL0?
> afaict, some paths (e.g. el0_irq()) only end up calling it if
> CONTEXT_TRACKING or TRACE_IRQFLAGS are enabled.

Currently everything that's in {enter,exit}_from_user_mode() only
matters when either CONTEXT_TRACKING or TRACE_IRQFLAGS is selected (and
expands to an empty stub otherwise).

We could drop the ifdeffery in user_{enter,exit}_irqoff() to have them
called regardless, or add CONFIG_MTE to the list.

> >  asmlinkage void noinstr exit_to_user_mode(void)
> >  {
> > +	/* Ignore asynchronous tag check faults in the uaccess routines */
> > +	clear_mte_async_tcf0();
> > +
> 
> and this one seems to be called even less often.

This is always done in ret_to_user, so (modulo ifdeferry above) all
returns to EL0 call this.

Thanks,
Mark.


From andriy.shevchenko at linux.intel.com  Thu Apr  8 16:08:08 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu, 8 Apr 2021 18:08:08 +0300
Subject: [PATCH v1 4/5] gpio: xilinx: Switch to use bitmap APIs
In-Reply-To: <20210408145601.68651-5-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <20210408145601.68651-5-andriy.shevchenko@linux.intel.com>
Message-ID: <YG8cWBkcF8ulHW0D@smile.fi.intel.com>

On Thu, Apr 08, 2021 at 05:56:00PM +0300, Andy Shevchenko wrote:
> It seems that Xilinx GPIO driver operates with bit arrays longer than 32 and
> thus can leverage bitmap APIs for that. It makes code better to understand.
> 
> The ->probe() function is modified to try read properties for both channels
> since is_dual check makes only sense for the amount of pins used for the second
> channel. On top of that kzalloc() guarantees zero initial values for the fields
> in the private data structure, hence drop unneeded conditionals and assignments.
> 
> The change is inspired by Syed Nayyar Waris' ideas about bitmap API extension.

As I was afraid in the cover letter, I found some mistakes already.
In any case, I'll wait for the comments and test of other patches if possible.

Out of curiosity, below I point out the issues.

...

> +	return bitmap_bitremap(gpio, chip->sw_map, chip->hw_map, chip->gc.ngpio);

Seems we have to use 64 instead of ngpio here.

...

> +	bitmap_replace(state, chip->state, hw_bits, hw_mask, gc->ngpio);

Ditto.

...

> +	bitmap_copy(chip->state, state, gc->ngpio);

Ditto.

...

> +	for_each_set_bit(bit, all, 64)
> +		generic_handle_irq(irq_find_mapping(gc->irq.domain, bit));

Here should be used gpio actually and ngpio IIUC.

-- 
With Best Regards,
Andy Shevchenko




From arnd at kernel.org  Thu Apr  8 16:08:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 8 Apr 2021 17:08:26 +0200
Subject: New 'make dtbs_check W=1' warnings
Message-ID: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>

Greetings to all Arm platform maintainers,

I've just gone through the DT merges I've received so far and, with a
little help from Rob,
managed to run 'make dtbs_check W=1' before and after, to see what
warnings we get.
The good news is that the number of warnings is going down, but
unfortunately there
is still an unmanageable amount of remaining warnings, and some new
ones crept in.

I'm still working on my tooling for this, to catch these better, but
ideally I think we should
try to not introduce new warnings. I think some platforms are already
clean, and I did
not see any new warnings for mvebu, samsung and broadcom. There were a lot of
warnings from .dtsi files, and I probably did an incomplete job at
deduplicating those.

See below for the other platforms, and the new warnings that I found.
If these are
valid, please send a fixup before the merge window, and let me know if
you have ideas
for how we should handle these in the future.

For this merge window, I don't think any of them are show-stoppers (Rob, let me
know if you disagree), but in the long run we may want to gradually enforce
a rule about not merging changes that introduce any new warnings, in order to
have a chance of cleaning up the existing ones.

       Arnd

arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer at 19:
interrupts: [[18, 1], [19, 1]] is too long
arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope at 68:
interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long
arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope at 68:
interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long
arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer at 1c:
interrupts: [[18, 1], [19, 1]] is too long

arch/arm/boot/dts/omap5-cm-t54.dt.yaml: gpmc at 50000000: 'clocks' is a
dependency of 'clock-names'
arch/arm/boot/dts/omap5-igep0050.dt.yaml: gpmc at 50000000: 'clocks' is a
dependency of 'clock-names'
arch/arm/boot/dts/omap5-sbc-t54.dt.yaml: gpmc at 50000000: 'clocks' is a
dependency of 'clock-names'
arch/arm/boot/dts/omap5-uevm.dt.yaml: gpmc at 50000000: 'clocks' is a
dependency of 'clock-names'

arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dt.yaml:
pin-controller at 50002000: 'ltdc' does not match any of the regexes:
'-[0-9]*$', '^gpio@[0-9a-f]*$', 'pinctrl-[0-9]+'

arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does
not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
'pinctrl-[0-9]+'
arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm at 73C000' does not
match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
'pinctrl-[0-9]+'

amlogic/meson-gxl-s905d-mecool-kii-pro.dts:31.19-42.4: Warning
(avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxl-s905d-mecool-kii-pro.dts:37.12-41.5: Warning
(unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit
name, but no reg or ranges property
amlogic/meson-gxm-mecool-kiii-pro.dts:36.19-47.4: Warning
(avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxm-mecool-kiii-pro.dts:42.12-46.5: Warning
(unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit
name, but no reg or ranges property
amlogic/meson-gxm-minix-neo-u9h.dts:42.19-53.4: Warning
(avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxm-minix-neo-u9h.dts:48.12-52.5: Warning
(unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit
name, but no reg or ranges property
amlogic/meson-gxl-s805x-p241.dt.yaml: serial at 84c0: 'uart-has-rtscts'
does not match any of the regexes: 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller at 5400:
'sound-name-prefix' does not match any of the regexes:
'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml:
audio-controller at c8832000: 'AVDD-supply', 'sound-name-prefix' do not
match any f the regexes: 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth:
clock-names: ['lpo'] is too short
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth:
clock-names:0: 'txco' was expected
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clocks:
[[23]] is too short
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000:
eth-phy-mux: {'type': 'object'} is not allowed for {'compatible':
['mdio-mux-mmioreg', 'mdio-mux'], '#address-cells': [[1]],
'#size-cells': [[0]], 'reg': [[0, 1372, 0, 4]], 'mux-mask':
[[4294967295]], 'mdio-parent-bus': [[35]], 'mdio at e40908ff': {'reg':
[[3825797375]], '#address-cells': [[1]], '#size-cells': [[0]],
'ethernet-phy at 8': {'compatible': ['ethernet-phy-id0181.4400'],
'interrupts': [[0, 9, 4]], 'reg': [[8]], 'max-speed': [[100]],
'phandle': [[36]]}}, 'mdio at 2009087f': {'reg': [[537462911]],
'#address-cells': [[1]], '#size-cells': [[0]]}}
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000: rng:
{'type': 'object'} is not allowed for {'compatible':
['amlogic,meson-rng'], 'reg': [[0, 0, 0, 4]], 'clocks': [[3, 25]],
'clock-names': ['core']}
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: hdmi-tx at c883a000:
'sound-name-prefix' does not match any of the regexes: pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: ir at 580:
linux,rc-map-name:0: 'rc-mecool-kii-pro' is not one of
['rc-adstech-dvb-t-ci', 'rc-alink-dtu-m', 'rc-anysee',
'rc-apac-viewcomp',..., 'rc-zx-irdec']
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: leds: 'blue' does not
match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: serial at 84c0:
'bluetooth', 'uart-has-rtscts' do not match any of the regexes:
'pinctrl-0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do
not atch any of the regexes: '^dai-link-[0-9]+$', 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'clocks' is a
dependency of 'assigned-clocks'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: audio-routing:
['AU2 INL', 'ACODEC LOLP', 'AU2 INR', 'ACODEC LORP', AU2 INL', 'ACODEC
LOLN', 'AU2 INR', 'ACODEC LORN', 'Lineout', 'AU2 OUTL', 'Lineout',
'AU2 OUTR'] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-0:sound-dai:0: [63, 0, 0] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-0:sound-dai:0:1: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-0:sound-dai:0:2: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-1:sound-dai:0: [63, 0, 1] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-1:sound-dai:0:1: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound:
dai-link-1:sound-dai:0:2: missing phandle tag in 1
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: vpu at d0100000:
'amlogic,canvas' does not match any of the regexes: 'pinctrl-[0-9]+'

freescale/imx8-ss-audio.dtsi:16.33-21.4: Warning (simple_bus_reg):
/bus at 59000000/clock-audio-ipg: missing or empty reg/ranges property
freescale/imx8-ss-conn.dtsi:16.31-21.4: Warning (simple_bus_reg):
/bus at 5b000000/clock-conn-axi: missing or empty reg/ranges property
freescale/imx8-ss-conn.dtsi:23.31-28.4: Warning (simple_bus_reg):
/bus at 5b000000/clock-conn-ahb: missing or empty reg/ranges property
freescale/imx8-ss-conn.dtsi:30.31-35.4: Warning (simple_bus_reg):
/bus at 5b000000/clock-conn-ipg: missing or empty reg/ranges property
freescale/imx8-ss-dma.dtsi:16.29-21.4: Warning (simple_bus_reg):
/bus at 5a000000/clock-dma-ipg: missing or empty reg/ranges property
freescale/imx8-ss-lsio.dtsi:16.31-21.4: Warning (simple_bus_reg):
/bus at 5d000000/clock-lsio-mem: missing or empty reg/ranges property
freescale/imx8-ss-lsio.dtsi:23.31-28.4: Warning (simple_bus_reg):
/bus at 5d000000/clock-lsio-bus: missing or empty reg/ranges property
freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet at 7: 'sfp' does not
match any of the regexes: 'pinctrl-[0-9]+'
freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet at 8: 'sfp' does not
match any of the regexes: 'pinctrl-[0-9]+'
freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet at 9: 'sfp' does not
match any of the regexes: 'pinctrl-[0-9]+'
freescale/fsl-lx2160a-clearfog-cx.dt.yaml: ethernet at a: 'sfp' does not
match any of the regexes: 'pinctrl-[0-9]+'
freescale/fsl-lx2160a-honeycomb.dt.yaml: power-controller at 1e34040:
'#power-domain-cells' is a required property

mediatek/mt8183-pumpkin.dts:35.36-39.5: Warning (unit_address_vs_reg):
/reserved-memory/scp_mem_region: node has a reg or ranges property,
but no unit name
mediatek/mt8183-pumpkin.dts:58.8-64.4: Warning (unit_address_vs_reg):
/ntc at 0: node has a unit name, but no reg or ranges property
mediatek/mt8183.dtsi:1106.26-1112.6: Warning (unit_address_format):
/soc/t-phy at 11f40000/usb-phy at 0700: unit name should not have leading 0s
mediatek/mt8183.dtsi:1234.22-1246.5: Warning
(avoid_unnecessary_addr_size): /soc/dsi at 14014000: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
mediatek/mt8183.dtsi:676.17-795.5: Warning (simple_bus_reg):
/soc/thermal-zones: missing or empty reg/ranges property
mediatek/mt8183.dtsi:684.30-688.8: Warning (unit_address_vs_reg):
/soc/thermal-zones/cpu_thermal/trips/trip-point at 0: node has a unit
name, but no reg or ranges property
mediatek/mt8183-evb.dt.yaml: soc: thermal-zones: {'type': 'object'} is
not allowed for {'cpu_thermal': {'polling-delay-passive': [[100]],
'polling-delay': [[500]], 'thermal-sensors': [[41, 0]...
'pinctrl-[0-9]+'
mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625 at 58:
'#address-cells', '#size-cells', 'panel_flags', 'port at 0', 'port at 1' do
not match any of the regexes: 'pinctrl-[0-9]+'
mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: anx7625 at 58: 'ports' is a
required property
mediatek/mt8183-kukui-jacuzzi-damu.dt.yaml: cros_ec: 'mtk,rpmsg-name'
does not match any of the regexes: '^#.*', ...

qcom/sc7180.dtsi:1204.21-1220.6: Warning
(avoid_unnecessary_addr_size): /soc at 0/geniqup at ac0000/i2c at a8c000:
unnecessary #address-cells/#size-cells without "ranges" or child "reg"
property
qcom/sc7180.dtsi:965.21-981.6: Warning (avoid_unnecessary_addr_size):
/soc at 0/geniqup at 8c0000/i2c at 890000: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
qcom/sdm845.dtsi:3912.23-4045.5: Warning (simple_bus_reg):
/soc at 0/camss at a00000: simple-bus unit address format error, expected
"acb3000"
qcom/sdm845.dtsi:4041.10-4044.6: Warning (graph_child_address):
/soc at 0/camss at a00000/ports: graph node has single child node 'port at 0',
#address-cells/#size-cells are not necessary
qcom/sdm845.dtsi:4102.32-4129.5: Warning (simple_bus_reg):
/soc at 0/dsi-opp-table: missing or empty reg/ranges property
ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg):
/bus at f4000/interrupt-controller0: missing or empty reg/ranges property
ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg):
/bus at f4000/dmss: missing or empty reg/ranges property
ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg):
/bus at f4000/bus at 4000000/interrupt-controller1: missing or empty
reg/ranges property
qcom/msm8916-samsung-a5u-eur.dt.yaml: spmi at 200f000: reg: [[33615872,
4096], [37748736, 4194304], [46137344, 4194304], [58720256, 2097152],
[33595392, 8448]] is too long
qcom/sc7180-trogdor-lazor-r0.dt.yaml: gmu at 506a000: compatible:0:
'qcom,adreno-gmu-618.0' is not one of ['qcom,adreno-gmu-630.2']
qcom/sc7180-trogdor-lazor-r1-kb.dt.yaml: memory at 80900000:
'device_type' is a required property
qcom/sdm850-lenovo-yoga-c630.dt.yaml: memory at 97b00000: 'device_type'
is a required property

renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports:
'port at 0' is a required property
renesas/r8a779a0-falcon.dt.yaml: thermal-zones: 'sensor-thermal1',
'sensor-thermal2', 'sensor-thermal3', 'sensor-thermal4',
'sensor-thermal5' do not match any of the regexes:
'^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
renesas/r8a779a0-falcon.dt.yaml: timer at e61e0000: compatible:0:
'renesas,tmu-r8a779a0' is not one of ['renesas,tmu-r8a7740',
'renesas,tmu-r8a774a1', 'renesas,tmu-r8a774b1',
'renesas,tmu-r8a774c0', 'renesas,tmu-r8a774e1', 'renesas,tmu-r8a7778',
'renesas,tmu-r8a7779', 'renesas,tmu-r8a7795', 'renesas,tmu-r8a7796',
'renesas,tmu-r8a77961', 'renesas,tmu-r8a77965',
'renesas,tmu-r8a77970', 'renesas,tmu-r8a77980',
'renesas,tmu-r8a77990', 'renesas,tmu-r8a77995']

rockchip/rk3399-khadas-edge-v.dt.yaml: usb at fe800000:
#address-cells:0:0: 1 was expected

ti/k3-am642-evm.dt.yaml: bus at 4000000: interrupt-controller1: {'type':
'object'} is not allowed for {'compatible': ['ti,sci-intr'],
'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]],
'phandle': [[5]]}
ti/k3-am642-evm.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not
allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]],
'#size-cells': [[2]], 'dma-ranges': True, 'ranges':  'phandle':
[[7]]}}
ti/k3-am642-evm.dt.yaml: bus at f4000: interrupt-controller0: {'type':
'object'} is not allowed for {'compatible': ['ti,sci-intr'],
'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]],
'phandle': [[15]]}
ti/k3-am642-evm.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns',
'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of
the regexes: '^partition@', 'pinctrl-[0-9]+'
ti/k3-am642-sk.dt.yaml: bus at 4000000: interrupt-controller1: {'type':
'object'} is not allowed for {'compatible': ['ti,sci-intr'],
'ti,intr-trigger-type': [[1]], ...
ti/k3-am642-sk.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not
allowed for {'compatible': ['simple-mfd'], ...
ti/k3-am642-sk.dt.yaml: bus at f4000: interrupt-controller0: {'type':
'object'} is not allowed for {'compatible': ['ti,sci-intr'],
'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]],
'phandle': [[11]]}
ti/k3-am642-sk.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns',
'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of
the regexes: '^partition@', 'pinctrl-[0-9]+'
ti/k3-j7200-common-proc-board.dt.yaml: flash at 0: 'cdns,read-delay',
'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do
not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'


From joro at 8bytes.org  Thu Apr  8 16:11:47 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 8 Apr 2021 17:11:47 +0200
Subject: [GIT PULL] iommu/arm-smmu: Updates for 5.13
In-Reply-To: <20210408132959.GB17873@willie-the-truck>
References: <20210408132959.GB17873@willie-the-truck>
Message-ID: <YG8dMwcBGsoiNC9H@8bytes.org>

On Thu, Apr 08, 2021 at 02:29:59PM +0100, Will Deacon wrote:
>   git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-updates

Pulled, thanks Will.



From alexandru.elisei at arm.com  Thu Apr  8 16:14:11 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 8 Apr 2021 16:14:11 +0100
Subject: [PATCH v6 06/20] kvm: arm64: Move SPE availability check to VCPU
 load
In-Reply-To: <20210405164307.1720226-7-suzuki.poulose@arm.com>
References: <20210405164307.1720226-1-suzuki.poulose@arm.com>
 <20210405164307.1720226-7-suzuki.poulose@arm.com>
Message-ID: <a5b99e5d-2658-45e6-443d-9bb047a2ddd1@arm.com>

Hi Suzuki,

On 4/5/21 5:42 PM, Suzuki K Poulose wrote:
> At the moment, we check the availability of SPE on the given
> CPU (i.e, SPE is implemented and is allowed at the host) during
> every guest entry. This can be optimized a bit by moving the
> check to vcpu_load time and recording the availability of the
> feature on the current CPU via a new flag. This will also be useful
> for adding the TRBE support.
>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Will Deacon <will at kernel.org>
> Cc: Alexandru Elisei <Alexandru.Elisei at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h  |  5 +++++
>  arch/arm64/kvm/arm.c               |  2 ++
>  arch/arm64/kvm/debug.c             | 23 +++++++++++++++++++++++
>  arch/arm64/kvm/hyp/nvhe/debug-sr.c | 22 +++++++++-------------
>  4 files changed, 39 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 3d10e6527f7d..acc2b45dd433 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -400,6 +400,7 @@ struct kvm_vcpu_arch {
>  #define KVM_ARM64_GUEST_HAS_PTRAUTH	(1 << 7) /* PTRAUTH exposed to guest */
>  #define KVM_ARM64_PENDING_EXCEPTION	(1 << 8) /* Exception pending */
>  #define KVM_ARM64_EXCEPT_MASK		(7 << 9) /* Target EL/MODE */
> +#define KVM_ARM64_DEBUG_STATE_SAVE_SPE	(1 << 12) /* Save SPE context if active  */

Would you consider renaming the flag to something more generic, like
KVM_ARM64_CPU_HAS_SPE or KVM_ARM64_HOST_HAS_SPE (or something else that you
fancy)? I'm thinking that it might be possible for the flag to be used for
something else in the future.

Also, the comment is somewhat misleading, the flag tells KVM that the physical CPU
has FEAT_SPE, not that the host is actually using SPE. That check is done in the
world switch code.

>  
>  /*
>   * When KVM_ARM64_PENDING_EXCEPTION is set, KVM_ARM64_EXCEPT_MASK can
> @@ -734,6 +735,10 @@ static inline bool kvm_pmu_counter_deferred(struct perf_event_attr *attr)
>  	return (!has_vhe() && attr->exclude_host);
>  }
>  
> +/* Flags for host debug state */
> +void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu);
> +void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
> +
>  #ifdef CONFIG_KVM /* Avoid conflicts with core headers if CONFIG_KVM=n */
>  static inline int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
>  {
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 7f06ba76698d..954752208509 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -416,10 +416,12 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>  
>  	if (vcpu_has_ptrauth(vcpu))
>  		vcpu_ptrauth_disable(vcpu);
> +	kvm_arch_vcpu_load_debug_state_flags(vcpu);
>  }
>  
>  void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  {
> +	kvm_arch_vcpu_put_debug_state_flags(vcpu);
>  	kvm_arch_vcpu_put_fp(vcpu);
>  	if (has_vhe())
>  		kvm_vcpu_put_sysregs_vhe(vcpu);

This looks like the correct approach to me. kvm_arch_vcpu_{load,put} are called
when the VCPU is moved around to another physical CPU, so it makes sense to have
the checks here.

> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index dbc890511631..b6d2c33ad1df 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -231,3 +231,26 @@ void kvm_arm_clear_debug(struct kvm_vcpu *vcpu)
>  		}
>  	}
>  }
> +
> +void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
> +{
> +	u64 dfr0;
> +
> +	/* For VHE, there is nothing to do */
> +	if (has_vhe())
> +		return;
> +
> +	dfr0 = read_sysreg(id_aa64dfr0_el1);
> +	/*
> +	 * If SPE is present on this CPU and is available at current EL,
> +	 * we may need to check if the host state needs to be saved.
> +	 */
> +	if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_PMSVER_SHIFT) &&
> +	    !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(SYS_PMBIDR_EL1_P_SHIFT)))
> +		vcpu->arch.flags |= KVM_ARM64_DEBUG_STATE_SAVE_SPE;
> +}

This also looks correct, and it matches the equivalent checks that were removed
from __debug_save_spe().

> +
> +void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> +{
> +	vcpu->arch.flags &= ~KVM_ARM64_DEBUG_STATE_SAVE_SPE;
> +}
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index f401724f12ef..e6ee9b7faec6 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -21,17 +21,11 @@ static void __debug_save_spe(u64 *pmscr_el1)
>  	/* Clear pmscr in case of early return */
>  	*pmscr_el1 = 0;
>  
> -	/* SPE present on this CPU? */
> -	if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> -						  ID_AA64DFR0_PMSVER_SHIFT))
> -		return;
> -
> -	/* Yes; is it owned by EL3? */
> -	reg = read_sysreg_s(SYS_PMBIDR_EL1);
> -	if (reg & BIT(SYS_PMBIDR_EL1_P_SHIFT))
> -		return;
> -
> -	/* No; is the host actually using the thing? */
> +	/*
> +	 * At this point, we know that this CPU implements

Nitpick: the line length looks suspiciously short here.

Thanks,

Alex

> +	 * SPE and is available to the host.
> +	 * Check if the host is actually using it ?
> +	 */
>  	reg = read_sysreg_s(SYS_PMBLIMITR_EL1);
>  	if (!(reg & BIT(SYS_PMBLIMITR_EL1_E_SHIFT)))
>  		return;
> @@ -61,7 +55,8 @@ static void __debug_restore_spe(u64 pmscr_el1)
>  void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu)
>  {
>  	/* Disable and flush SPE data generation */
> -	__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);
> +	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
> +		__debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1);
>  }
>  
>  void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
> @@ -71,7 +66,8 @@ void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
>  
>  void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu)
>  {
> -	__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
> +	if (vcpu->arch.flags & KVM_ARM64_DEBUG_STATE_SAVE_SPE)
> +		__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
>  }
>  
>  void __debug_switch_to_host(struct kvm_vcpu *vcpu)


From broonie at kernel.org  Thu Apr  8 16:15:27 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 16:15:27 +0100
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <20210405204313.21346-2-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-2-madvenka@linux.microsoft.com>
Message-ID: <20210408151527.GM4516@sirena.org.uk>

On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> Implement a check_reliability() function that will contain checks for the
> presence of various features and conditions that can render the stack trace
> unreliable.

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/20210408/889421eb/attachment.sig>

From mark.rutland at arm.com  Thu Apr  8 16:18:37 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 8 Apr 2021 16:18:37 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408143723.13024-1-vincenzo.frascino@arm.com>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
Message-ID: <20210408151837.GB37165@C02TD0UTHF1T.local>

Hi Vincenzo,

On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> race with another CPU doing a set_tsk_thread_flag() and the flag can be
> lost in the process.
> 
> Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> exit_to_user_mode() to address the problem.

Beware that these are called at critical points of the entry sequence,
so we need to take care that nothing is instrumented (e.g. we can only
safely use noinstr functions here).

> Note: Moving the check in entry-common allows to use set_thread_flag()
> which is safe.
> 
> Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous
> tag check faults")
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Reported-by: Will Deacon <will at kernel.org>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> ---
>  arch/arm64/include/asm/mte.h     |  8 ++++++++
>  arch/arm64/kernel/entry-common.c |  6 ++++++
>  arch/arm64/kernel/entry.S        | 30 ------------------------------
>  arch/arm64/kernel/mte.c          | 25 +++++++++++++++++++++++--
>  4 files changed, 37 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 9b557a457f24..188f778c6f7b 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
>  void mte_invalidate_tags_area(int type);
>  void *mte_allocate_tag_storage(void);
>  void mte_free_tag_storage(char *storage);
> +void check_mte_async_tcf0(void);
> +void clear_mte_async_tcf0(void);
>  
>  #ifdef CONFIG_ARM64_MTE
>  
> @@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
>  {
>  	return -EIO;
>  }
> +void check_mte_async_tcf0(void)
> +{
> +}
> +void clear_mte_async_tcf0(void)
> +{
> +}

Were these meant to be static inline?

>  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
>  {
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 9d3588450473..837d3624a1d5 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
>  	CT_WARN_ON(ct_state() != CONTEXT_USER);
>  	user_exit_irqoff();
>  	trace_hardirqs_off_finish();
> +
> +	/* Check for asynchronous tag check faults in user space */
> +	check_mte_async_tcf0();
>  }
>  
>  asmlinkage void noinstr exit_to_user_mode(void)
>  {
> +	/* Ignore asynchronous tag check faults in the uaccess routines */
> +	clear_mte_async_tcf0();
> +
>  	trace_hardirqs_on_prepare();
>  	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
>  	user_enter_irqoff();
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index a31a0a713c85..fafd74ae5021 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -147,32 +147,6 @@ alternative_cb_end
>  .L__asm_ssbd_skip\@:
>  	.endm
>  
> -	/* Check for MTE asynchronous tag check faults */
> -	.macro check_mte_async_tcf, flgs, tmp
> -#ifdef CONFIG_ARM64_MTE
> -alternative_if_not ARM64_MTE
> -	b	1f
> -alternative_else_nop_endif
> -	mrs_s	\tmp, SYS_TFSRE0_EL1
> -	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
> -	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
> -	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
> -	str	\flgs, [tsk, #TSK_TI_FLAGS]
> -	msr_s	SYS_TFSRE0_EL1, xzr
> -1:
> -#endif
> -	.endm
> -
> -	/* Clear the MTE asynchronous tag check faults */
> -	.macro clear_mte_async_tcf
> -#ifdef CONFIG_ARM64_MTE
> -alternative_if ARM64_MTE
> -	dsb	ish
> -	msr_s	SYS_TFSRE0_EL1, xzr
> -alternative_else_nop_endif
> -#endif
> -	.endm
> -
>  	.macro mte_set_gcr, tmp, tmp2
>  #ifdef CONFIG_ARM64_MTE
>  	/*
> @@ -243,8 +217,6 @@ alternative_else_nop_endif
>  	ldr	x19, [tsk, #TSK_TI_FLAGS]
>  	disable_step_tsk x19, x20
>  
> -	/* Check for asynchronous tag check faults in user space */
> -	check_mte_async_tcf x19, x22
>  	apply_ssbd 1, x22, x23
>  
>  	ptrauth_keys_install_kernel tsk, x20, x22, x23
> @@ -775,8 +747,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
>  	cbnz	x2, work_pending
>  finish_ret_to_user:
>  	user_enter_irqoff
> -	/* Ignore asynchronous tag check faults in the uaccess routines */
> -	clear_mte_async_tcf
>  	enable_step_tsk x19, x2
>  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>  	bl	stackleak_erase
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index b3c70a612c7a..e759b0eca47e 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -166,14 +166,35 @@ static void set_gcr_el1_excl(u64 excl)
>  	 */
>  }
>  
> +void check_mte_async_tcf0(void)

As above, this'll need to be noinstr. I also reckon we should put this
in the header so that it can be inlined.

> +{
> +	/*
> +	 * dsb(ish) is not required before the register read
> +	 * because the TFSRE0_EL1 is automatically synchronized
> +	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
> +	 * is set.
> +	 */
> +	u64 tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);

Shouldn't we have an MTE feature check first?

> +
> +	if (tcf0 & SYS_TFSR_EL1_TF0)
> +		set_thread_flag(TIF_MTE_ASYNC_FAULT);
> +
> +	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}
> +
> +void clear_mte_async_tcf0(void)
> +{
> +	dsb(ish);
> +	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}

Likewise here on all counts.

Thanks,
Mark.

>  void flush_mte_state(void)
>  {
>  	if (!system_supports_mte())
>  		return;
>  
>  	/* clear any pending asynchronous tag fault */
> -	dsb(ish);
> -	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +	clear_mte_async_tcf0();
>  	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
>  	/* disable tag checking */
>  	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
> -- 
> 2.30.2
> 


From vincenzo.frascino at arm.com  Thu Apr  8 16:23:27 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Thu, 8 Apr 2021 16:23:27 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408150612.GA37165@C02TD0UTHF1T.local>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
 <20210408145604.GB18211@willie-the-truck>
 <20210408150612.GA37165@C02TD0UTHF1T.local>
Message-ID: <e3c6fa5b-82a2-dfd9-859b-efbb9970c5e5@arm.com>



On 4/8/21 4:06 PM, Mark Rutland wrote:
> On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
>> On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
>>> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
>>> race with another CPU doing a set_tsk_thread_flag() and the flag can be
>>> lost in the process.
>>
>> Actually, it's all the *other* flags that get lost!
>>

You are right, I need to explain this better.

...

-- 
Regards,
Vincenzo


From arnd at kernel.org  Thu Apr  8 16:24:19 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:19 +0200
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <20210404164914.712946-1-bjorn.andersson@linaro.org>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
Message-ID: <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Sun, 4 Apr 2021 11:49:14 -0500, Bjorn Andersson wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13
> 
> [...]

I noticed a couple of new warnings from 'make dtbs_check W=1':

qcom/sc7180.dtsi:1204.21-1220.6: Warning (avoid_unnecessary_addr_size): /soc at 0/geniqup at ac0000/i2c at a8c000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
qcom/sc7180.dtsi:965.21-981.6: Warning (avoid_unnecessary_addr_size): /soc at 0/geniqup at 8c0000/i2c at 890000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sdm845.dtsi:3912.23-4045.5: Warning (simple_bus_reg): /soc at 0/camss at a00000: simple-bus unit address format error, expected "acb3000"
qcom/sdm845.dtsi:4041.10-4044.6: Warning (graph_child_address): /soc at 0/camss at a00000/ports: graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
qcom/sdm845.dtsi:4102.32-4129.5: Warning (simple_bus_reg): /soc at 0/dsi-opp-table: missing or empty reg/ranges property
qcom/msm8916-samsung-a5u-eur.dt.yaml: spmi at 200f000: reg: [[33615872, 4096], [37748736, 4194304], [46137344, 4194304], [58720256, 2097152], [33595392, 8448]] is too long
qcom/sc7180-trogdor-lazor-r0.dt.yaml: gmu at 506a000: compatible:0: 'qcom,adreno-gmu-618.0' is not one of ['qcom,adreno-gmu-630.2']
qcom/sc7180-trogdor-lazor-r1-kb.dt.yaml: memory at 80900000: 'device_type' is a required property
qcom/sdm850-lenovo-yoga-c630.dt.yaml: memory at 97b00000: 'device_type' is a required property

Maybe see if you can address these in a follow-up, to avoid regressions.

Merged into arm/dt, thanks!

merge commit: 61bac46eed14ad73cd41c5b7075350fef78ca4be

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:20 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:20 +0200
Subject: [GIT PULL] Renesas ARM DT updates for v5.13 (take two)
In-Reply-To: <cover.1617359678.git.geert+renesas@glider.be>
References: <cover.1617359678.git.geert+renesas@glider.be>
Message-ID: <161789462010.1629934.8245364544434971043.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 2 Apr 2021 12:37:15 +0200, Geert Uytterhoeven wrote:
> 	Hi arm-soc folks,
> 
> The following changes since commit c8aebc1346522d3569690867ce3996642ad52e01:
> 
>   arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding (2021-03-16 09:58:00 +0100)
> 
> are available in the Git repository at:
> 
> [...]

Merged into arm/dt, thanks!

There were a couple of added warnings from 'make dtbs_check W=1':

renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports: 'port at 0' is a required property
renesas/r8a779a0-falcon.dt.yaml: thermal-zones: 'sensor-thermal1', 'sensor-thermal2', 'sensor-thermal3', 'sensor-thermal4', 'sensor-thermal5' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'
renesas/r8a779a0-falcon.dt.yaml: timer at e61e0000: compatible:0: 'renesas,tmu-r8a779a0' is not one of ['renesas,tmu-r8a7740', 'renesas,tmu-r8a774a1', 'renesas,tmu-r8a774b1', 'renesas,tmu-r8a774c0', 'renesas,tmu-r8a774e1', 'renesas,tmu-r8a7778', 'renesas,tmu-r8a7779', 'renesas,tmu-r8a7795', 'renesas,tmu-r8a7796', 'renesas,tmu-r8a77961', 'renesas,tmu-r8a77965', 'renesas,tmu-r8a77970', 'renesas,tmu-r8a77980', 'renesas,tmu-r8a77990', 'renesas,tmu-r8a77995']

merge commit: 85af259bcce7a4d6936da72fd84757502a2c5b5e

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:21 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:21 +0200
Subject: [GIT PULL] ARM: mvebu: dt64 for v5.13 (#1)
In-Reply-To: <874kgocs7t.fsf@BL-laptop>
References: <874kgocs7t.fsf@BL-laptop>
Message-ID: <161789462026.1629934.18198415044078612678.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 02 Apr 2021 23:05:42 +0200, Gregory CLEMENT wrote:
> Here is the first pull request for dt64 for mvebu for v5.13.
> 
> Gregory
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> [...]

Merged into arm/dt, thanks!

merge commit: d1e3a9efb2afabad584f385b3bd58ec27ebf490a

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:22 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:22 +0200
Subject: [GIT PULL] arm64: dts: amlogic updates for v5.13
In-Reply-To: <7h5z10mjpp.fsf@baylibre.com>
References: <7h5z10mjpp.fsf@baylibre.com>
Message-ID: <161789493793.1630479.15784072871445378505.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 05 Apr 2021 15:48:18 -0700, Kevin Hilman wrote:
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
> 
> [...]

Merged into arm/dt, thanks!

Can you have a look at these added warnings from 'make dtbs_check W=1'?

amlogic/meson-gxl-s905d-mecool-kii-pro.dts:31.19-42.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxl-s905d-mecool-kii-pro.dts:37.12-41.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
amlogic/meson-gxm-mecool-kiii-pro.dts:36.19-47.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxm-mecool-kiii-pro.dts:42.12-46.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
amlogic/meson-gxm-minix-neo-u9h.dts:42.19-53.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
amlogic/meson-gxm-minix-neo-u9h.dts:48.12-52.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
amlogic/meson-gxl-s805x-p241.dt.yaml: serial at 84c0: 'uart-has-rtscts' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller at 5400:
'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml:
audio-controller at c8832000: 'AVDD-supply', 'sound-name-prefix' do not match any f the regexes: 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names: ['lpo'] is too short
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names:0: 'txco' was expected
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clocks: [[23]] is too short
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000: eth-phy-mux: {'type': 'object'} is not allowed for {'compatible': ['mdio-mux-mmioreg', 'mdio-mux'], '#address-cells': [[1]], '#size-cells': [[0]], 'reg': [[0, 1372, 0, 4]], 'mux-mask': [[4294967295]], 'mdio-parent-bus': [[35]], 'mdio at e40908ff': {'reg': [[3825797375]], '#address-cells': [[1]], '#size-cells': [[0]], 'ethernet-phy at 8': {'compatible': ['ethernet-phy-id0181.4400'], 'interrupts': [[0, 9, 4]], 'reg': [[8]], 'max-speed': [[100]], 'phandle': [[36]]}}, 'mdio at 2009087f': {'reg': [[537462911]], '#address-cells': [[1]], '#size-cells': [[0]]}}
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000: rng: {'type': 'object'} is not allowed for {'compatible': ['amlogic,meson-rng'], 'reg': [[0, 0, 0, 4]], 'clocks': [[3, 25]], 'clock-names': ['core']}
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: hdmi-tx at c883a000: 'sound-name-prefix' does not match any of the regexes: pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: ir at 580: linux,rc-map-name:0: 'rc-mecool-kii-pro' is not one of ['rc-adstech-dvb-t-ci', 'rc-alink-dtu-m', 'rc-anysee', 'rc-apac-viewcomp',..., 'rc-zx-irdec']
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: serial at 84c0: 'bluetooth', 'uart-has-rtscts' do not match any of the regexes:
'pinctrl-0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not atch any of the regexes: '^dai-link-[0-9]+$', 'pinctrl-[0-9]+'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: audio-routing: ['AU2 INL', 'ACODEC LOLP', 'AU2 INR', 'ACODEC LORP', AU2 INL', 'ACODEC LOLN', 'AU2 INR', 'ACODEC LORN', 'Lineout', 'AU2 OUTL', 'Lineout', 'AU2 OUTR'] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0: [63, 0, 0] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0: [63, 0, 1] is too long
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:1: missing phandle tag in 0
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:2: missing phandle tag in 1
amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: vpu at d0100000: 'amlogic,canvas' does not match any of the regexes: 'pinctrl-[0-9]+'

merge commit: aa1e345ade42ba90ab868750acab27a360998af1

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:23 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:23 +0200
Subject: [GIT PULL 1/3] ARM: dts: samsung: Pull for v5.13
In-Reply-To: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
References: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
Message-ID: <161789493809.1630479.13120302214696813911.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 7 Apr 2021 08:58:26 +0200, Krzysztof Kozlowski wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.13
> 
> [...]

Merged into arm/dt, thanks!

I also merged the corresponding 64-bit branch.

merge commit: 59206cf877be3a93dff0ea270bb1dd14f3010799

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:24 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:24 +0200
Subject: [GIT PULL] Allwinner Device Tree Changes for 5.13
In-Reply-To: <8a3e3271-bebe-4d27-a9e7-7b7a6311a38d.lettre@localhost>
References: <8a3e3271-bebe-4d27-a9e7-7b7a6311a38d.lettre@localhost>
Message-ID: <161789462018.1629934.16112481410782715304.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 2 Apr 2021 15:52:36 +0200, Maxime Ripard wrote:
> Please pull the following changes for the next release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 0d310a3791f6823cf5dcfec5666c1b8cfe6b149b

       Arnd


From nicolas.ferre at microchip.com  Thu Apr  8 16:24:39 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Thu, 8 Apr 2021 17:24:39 +0200
Subject: [PATCH 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <21bd4417-a754-8ee6-370e-4fb4e0f1fef9@microchip.com>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-23-claudiu.beznea@microchip.com>
 <YGSc1L8yW0KniOsx@piout.net>
 <a908274a-c4d2-faab-54a4-31fd0ffeab7e@microchip.com>
 <21bd4417-a754-8ee6-370e-4fb4e0f1fef9@microchip.com>
Message-ID: <51dbcf0b-4ee6-10c9-9598-a451cca16905@microchip.com>

On 01/04/2021 at 12:24, Claudiu Beznea - M18063 wrote:
> On 01.04.2021 12:38, Claudiu Beznea - M18063 wrote:
>> On 31.03.2021 19:01, Alexandre Belloni wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On 31/03/2021 13:59:06+0300, Claudiu Beznea wrote:
>>>> From: Eugen Hristev <eugen.hristev at microchip.com>
>>>>
>>>> Introduce new family of SoCs, sama7, and first SoC, sama7g5.
>>>>
>>>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>>>> ---
>>>>   arch/arm/mach-at91/Makefile |  1 +
>>>>   arch/arm/mach-at91/sama7.c  | 48 +++++++++++++++++++++++++++++++++++++
>>>>   2 files changed, 49 insertions(+)
>>>>   create mode 100644 arch/arm/mach-at91/sama7.c
>>>>
>>>> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
>>>> index f565490f1b70..6cc6624cddac 100644
>>>> --- a/arch/arm/mach-at91/Makefile
>>>> +++ b/arch/arm/mach-at91/Makefile
>>>> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_AT91SAM9)    += at91sam9.o
>>>>   obj-$(CONFIG_SOC_SAM9X60)    += sam9x60.o
>>>>   obj-$(CONFIG_SOC_SAMA5)              += sama5.o
>>>>   obj-$(CONFIG_SOC_SAMV7)              += samv7.o
>>>> +obj-$(CONFIG_SOC_SAMA7)              += sama7.o
>>>>
>>>>   # Power Management
>>>>   obj-$(CONFIG_ATMEL_PM)               += pm.o pm_suspend.o
>>>> diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
>>>> new file mode 100644
>>>> index 000000000000..e04cadb569ad
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-at91/sama7.c
>>>> @@ -0,0 +1,48 @@
>>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>>> +/*
>>>> + * Setup code for SAMA7
>>>> + *
>>>> + * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
>>>> + *
>>>> + */
>>>> +
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_platform.h>
>>>> +
>>>> +#include <asm/mach/arch.h>
>>>> +#include <asm/system_misc.h>
>>>> +
>>>> +#include "generic.h"
>>>> +
>>>> +static void __init sama7_common_init(void)
>>>> +{
>>>> +     of_platform_default_populate(NULL, NULL, NULL);
>>>
>>> Is this necessary? This is left as a workaround for the old SoCs using
>>> pinctrl-at91. I guess this will be using pio4 so this has to be removed.
>>
>> OK, I'll have a look. BTW, SAMA5D2 which is also using PIO4 calls
>> of_platform_default_populate(NULL, NULL, NULL);
> 
> Without this call the PM code (arch/arm/mach-at/pm.c) is not able to locate
> proper DT nodes:
> 
> [    0.194615] at91_pm_backup_init: failed to find securam device!
> [    0.201393] at91_pm_sram_init: failed to find sram device!
> [    0.207449] AT91: PM not supported, due to no SRAM allocated

Okay, so we can't afford removing these calls to sama5d2 and upcoming 
sama7g5 right now.

Is it a common pattern to have to reach DT content in the early stages 
that explicit call to of_platform_default_populate() tries to solve?

Best regards,
   Nicolas


>>>> +}
>>>> +
>>>> +static void __init sama7_dt_device_init(void)
>>>> +{
>>>> +     sama7_common_init();
>>>> +}
>>>> +
>>>> +static const char *const sama7_dt_board_compat[] __initconst = {
>>>> +     "microchip,sama7",
>>>> +     NULL
>>>> +};
>>>> +
>>>> +DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
>>>> +     /* Maintainer: Microchip */
>>>> +     .init_machine   = sama7_dt_device_init,
>>>> +     .dt_compat      = sama7_dt_board_compat,
>>>> +MACHINE_END
>>>> +
>>>> +static const char *const sama7g5_dt_board_compat[] __initconst = {
>>>> +     "microchip,sama7g5",
>>>> +     NULL
>>>> +};
>>>> +
>>>> +DT_MACHINE_START(sama7g5_dt, "Microchip SAMA7G5")
>>>> +     /* Maintainer: Microchip */
>>>> +     .init_machine   = sama7_dt_device_init,
>>>> +     .dt_compat      = sama7g5_dt_board_compat,
>>>> +MACHINE_END
>>>> +
>>>> --
>>>> 2.25.1
>>>>
>>>
>>> --
>>> Alexandre Belloni, co-owner and COO, Bootlin
>>> Embedded Linux and Kernel engineering
>>> https://bootlin.com
>>>
>>
> 


-- 
Nicolas Ferre


From arnd at kernel.org  Thu Apr  8 16:24:25 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:25 +0200
Subject: [GIT PULL] ARM: at91: dt for 5.13
In-Reply-To: <20210407114415.13180-1-nicolas.ferre@microchip.com>
References: <20210407114415.13180-1-nicolas.ferre@microchip.com>
Message-ID: <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 7 Apr 2021 13:44:15 +0200, nicolas.ferre at microchip.com wrote:
> Arnd, Olof,
> 
> Here is first batch of dt changes for 5.13. Please pull.
> 
> Thanks, best regards,
>   Nicolas
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
> [...]

Merged into arm/dt, thanks!

I saw two new warnings from 'make dtbs_check W=1':

arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'
arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm at 73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'

merge commit: e2b064fec8e49112f7dac779fcec12ded40728c2

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:26 +0200
Subject: [GIT PULL] arm64: dts: TI K3 updates for v5.13
In-Reply-To: <20210405155336.smohb7uzkperqwuz@reflex>
References: <20210405155336.smohb7uzkperqwuz@reflex>
Message-ID: <161789493785.1630479.2066806618809349698.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 5 Apr 2021 10:53:36 -0500, Nishanth Menon wrote:
> Please pull the following device tree changes for v5.13 cycle.
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
> [...]

Merged into arm/dt, thanks!

There are a couple added warnings from 'make W=1 dtbs_check' though:

ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus at f4000/interrupt-controller0: missing or empty reg/ranges property
ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus at f4000/dmss: missing or empty reg/ranges property
ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus at f4000/bus at 4000000/interrupt-controller1: missing or empty reg/ranges property

ti/k3-am642-evm.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]}
ti/k3-am642-evm.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges':  'phandle': [[7]]}}
ti/k3-am642-evm.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
ti/k3-am642-evm.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
ti/k3-am642-sk.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ...
ti/k3-am642-sk.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ...
ti/k3-am642-sk.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
ti/k3-am642-sk.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
ti/k3-j7200-common-proc-board.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'


merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296

       Arnd


From arnd at kernel.org  Thu Apr  8 16:24:28 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:24:28 +0200
Subject: [GIT PULL 2/3]
In-Reply-To: <pull-1617703816-65652@atomide.com-2>
References: <pull-1617703816-65652@atomide.com>
 <pull-1617703816-65652@atomide.com-2>
Message-ID: <161789493801.1630479.6840938905799812191.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 6 Apr 2021 13:10:59 +0300, Tony Lindgren wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/dt-v2-signed
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 36de77e35f3bc0fed0f1999f9c5731513be89a45

       Arnd


From alexandre.belloni at bootlin.com  Thu Apr  8 16:25:28 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Thu, 8 Apr 2021 17:25:28 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
Message-ID: <YG8gaHqlJ+oCfkTt@piout.net>

Hi,

On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote:
> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does
> not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
> 'pinctrl-[0-9]+'
> arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm at 73C000' does not
> match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
> 'pinctrl-[0-9]+'
> 

This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB
and ETM unit name"), trying to fix another warning.

I guess this is because
Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From vincenzo.frascino at arm.com  Thu Apr  8 16:26:25 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Thu, 8 Apr 2021 16:26:25 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408151837.GB37165@C02TD0UTHF1T.local>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
 <20210408151837.GB37165@C02TD0UTHF1T.local>
Message-ID: <cff8d16e-c1a9-3f10-7c7f-06fb569741ce@arm.com>



On 4/8/21 4:18 PM, Mark Rutland wrote:
> Hi Vincenzo,
> 
> On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
>> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
>> race with another CPU doing a set_tsk_thread_flag() and the flag can be
>> lost in the process.
>>
>> Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
>> exit_to_user_mode() to address the problem.
> 
> Beware that these are called at critical points of the entry sequence,
> so we need to take care that nothing is instrumented (e.g. we can only
> safely use noinstr functions here).
> 

Sure, I will add noinstr in the next version of the patch.

>> Note: Moving the check in entry-common allows to use set_thread_flag()
>> which is safe.
>>
>> Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous
>> tag check faults")
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Reported-by: Will Deacon <will at kernel.org>
>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
>> ---
>>  arch/arm64/include/asm/mte.h     |  8 ++++++++
>>  arch/arm64/kernel/entry-common.c |  6 ++++++
>>  arch/arm64/kernel/entry.S        | 30 ------------------------------
>>  arch/arm64/kernel/mte.c          | 25 +++++++++++++++++++++++--
>>  4 files changed, 37 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
>> index 9b557a457f24..188f778c6f7b 100644
>> --- a/arch/arm64/include/asm/mte.h
>> +++ b/arch/arm64/include/asm/mte.h
>> @@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
>>  void mte_invalidate_tags_area(int type);
>>  void *mte_allocate_tag_storage(void);
>>  void mte_free_tag_storage(char *storage);
>> +void check_mte_async_tcf0(void);
>> +void clear_mte_async_tcf0(void);
>>  
>>  #ifdef CONFIG_ARM64_MTE
>>  
>> @@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
>>  {
>>  	return -EIO;
>>  }
>> +void check_mte_async_tcf0(void)
>> +{
>> +}
>> +void clear_mte_async_tcf0(void)
>> +{
>> +}
> 
> Were these meant to be static inline?
> 

Agree, it definitely needs static inline here.

>>  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
>>  {
>> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
>> index 9d3588450473..837d3624a1d5 100644
>> --- a/arch/arm64/kernel/entry-common.c
>> +++ b/arch/arm64/kernel/entry-common.c
>> @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
>>  	CT_WARN_ON(ct_state() != CONTEXT_USER);
>>  	user_exit_irqoff();
>>  	trace_hardirqs_off_finish();
>> +
>> +	/* Check for asynchronous tag check faults in user space */
>> +	check_mte_async_tcf0();
>>  }
>>  
>>  asmlinkage void noinstr exit_to_user_mode(void)
>>  {
>> +	/* Ignore asynchronous tag check faults in the uaccess routines */
>> +	clear_mte_async_tcf0();
>> +
>>  	trace_hardirqs_on_prepare();
>>  	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
>>  	user_enter_irqoff();
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index a31a0a713c85..fafd74ae5021 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -147,32 +147,6 @@ alternative_cb_end
>>  .L__asm_ssbd_skip\@:
>>  	.endm
>>  
>> -	/* Check for MTE asynchronous tag check faults */
>> -	.macro check_mte_async_tcf, flgs, tmp
>> -#ifdef CONFIG_ARM64_MTE
>> -alternative_if_not ARM64_MTE
>> -	b	1f
>> -alternative_else_nop_endif
>> -	mrs_s	\tmp, SYS_TFSRE0_EL1
>> -	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
>> -	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
>> -	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
>> -	str	\flgs, [tsk, #TSK_TI_FLAGS]
>> -	msr_s	SYS_TFSRE0_EL1, xzr
>> -1:
>> -#endif
>> -	.endm
>> -
>> -	/* Clear the MTE asynchronous tag check faults */
>> -	.macro clear_mte_async_tcf
>> -#ifdef CONFIG_ARM64_MTE
>> -alternative_if ARM64_MTE
>> -	dsb	ish
>> -	msr_s	SYS_TFSRE0_EL1, xzr
>> -alternative_else_nop_endif
>> -#endif
>> -	.endm
>> -
>>  	.macro mte_set_gcr, tmp, tmp2
>>  #ifdef CONFIG_ARM64_MTE
>>  	/*
>> @@ -243,8 +217,6 @@ alternative_else_nop_endif
>>  	ldr	x19, [tsk, #TSK_TI_FLAGS]
>>  	disable_step_tsk x19, x20
>>  
>> -	/* Check for asynchronous tag check faults in user space */
>> -	check_mte_async_tcf x19, x22
>>  	apply_ssbd 1, x22, x23
>>  
>>  	ptrauth_keys_install_kernel tsk, x20, x22, x23
>> @@ -775,8 +747,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
>>  	cbnz	x2, work_pending
>>  finish_ret_to_user:
>>  	user_enter_irqoff
>> -	/* Ignore asynchronous tag check faults in the uaccess routines */
>> -	clear_mte_async_tcf
>>  	enable_step_tsk x19, x2
>>  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>  	bl	stackleak_erase
>> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
>> index b3c70a612c7a..e759b0eca47e 100644
>> --- a/arch/arm64/kernel/mte.c
>> +++ b/arch/arm64/kernel/mte.c
>> @@ -166,14 +166,35 @@ static void set_gcr_el1_excl(u64 excl)
>>  	 */
>>  }
>>  
>> +void check_mte_async_tcf0(void)
> 
> As above, this'll need to be noinstr. I also reckon we should put this
> in the header so that it can be inlined.
> 

Yes, I agree.

>> +{
>> +	/*
>> +	 * dsb(ish) is not required before the register read
>> +	 * because the TFSRE0_EL1 is automatically synchronized
>> +	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
>> +	 * is set.
>> +	 */
>> +	u64 tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
> 
> Shouldn't we have an MTE feature check first?
> 

Indeed, I will add it in the next version.

>> +
>> +	if (tcf0 & SYS_TFSR_EL1_TF0)
>> +		set_thread_flag(TIF_MTE_ASYNC_FAULT);
>> +
>> +	write_sysreg_s(0, SYS_TFSRE0_EL1);
>> +}
>> +
>> +void clear_mte_async_tcf0(void)
>> +{
>> +	dsb(ish);
>> +	write_sysreg_s(0, SYS_TFSRE0_EL1);
>> +}
> 
> Likewise here on all counts.
> 

I will add noinstr and the check in the next version.

> Thanks,
> Mark.
> 
>>  void flush_mte_state(void)
>>  {
>>  	if (!system_supports_mte())
>>  		return;
>>  
>>  	/* clear any pending asynchronous tag fault */
>> -	dsb(ish);
>> -	write_sysreg_s(0, SYS_TFSRE0_EL1);
>> +	clear_mte_async_tcf0();
>>  	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
>>  	/* disable tag checking */
>>  	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
>> -- 
>> 2.30.2
>>

-- 
Regards,
Vincenzo


From nicolas.ferre at microchip.com  Thu Apr  8 16:30:14 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Thu, 8 Apr 2021 17:30:14 +0200
Subject: [PATCH 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <20210331105908.23027-23-claudiu.beznea@microchip.com>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-23-claudiu.beznea@microchip.com>
Message-ID: <3d39d952-03f2-0952-72ee-b639fd4339f2@microchip.com>

Hi,

On 31/03/2021 at 12:59, Claudiu Beznea wrote:
> From: Eugen Hristev <eugen.hristev at microchip.com>
> 
> Introduce new family of SoCs, sama7, and first SoC, sama7g5.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> ---
>   arch/arm/mach-at91/Makefile |  1 +
>   arch/arm/mach-at91/sama7.c  | 48 +++++++++++++++++++++++++++++++++++++
>   2 files changed, 49 insertions(+)
>   create mode 100644 arch/arm/mach-at91/sama7.c
> 
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index f565490f1b70..6cc6624cddac 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_AT91SAM9)	+= at91sam9.o
>   obj-$(CONFIG_SOC_SAM9X60)	+= sam9x60.o
>   obj-$(CONFIG_SOC_SAMA5)		+= sama5.o
>   obj-$(CONFIG_SOC_SAMV7)		+= samv7.o
> +obj-$(CONFIG_SOC_SAMA7)		+= sama7.o

Nit: alphabetic order tells that it should be before samv7

>   
>   # Power Management
>   obj-$(CONFIG_ATMEL_PM)		+= pm.o pm_suspend.o
> diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
> new file mode 100644
> index 000000000000..e04cadb569ad
> --- /dev/null
> +++ b/arch/arm/mach-at91/sama7.c
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Setup code for SAMA7
> + *
> + * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
> + *
> + */
> +
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/system_misc.h>
> +
> +#include "generic.h"
> +
> +static void __init sama7_common_init(void)
> +{
> +	of_platform_default_populate(NULL, NULL, NULL);
> +}
> +
> +static void __init sama7_dt_device_init(void)
> +{
> +	sama7_common_init();
> +}
> +
> +static const char *const sama7_dt_board_compat[] __initconst = {
> +	"microchip,sama7",
> +	NULL
> +};
> +
> +DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
> +	/* Maintainer: Microchip */
> +	.init_machine	= sama7_dt_device_init,
> +	.dt_compat	= sama7_dt_board_compat,
> +MACHINE_END
> +
> +static const char *const sama7g5_dt_board_compat[] __initconst = {
> +	"microchip,sama7g5",
> +	NULL
> +};
> +
> +DT_MACHINE_START(sama7g5_dt, "Microchip SAMA7G5")
> +	/* Maintainer: Microchip */
> +	.init_machine	= sama7_dt_device_init,
> +	.dt_compat	= sama7g5_dt_board_compat,
> +MACHINE_END

I'm not sure we need two DT_MACHINE_START() entries and associated 
functions right now. Probably the most generic one is sufficient.
We can add such distinction in the future if the need arises.

Regards,
   Nicolas

-- 
Nicolas Ferre


From andriy.shevchenko at linux.intel.com  Thu Apr  8 16:31:08 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu,  8 Apr 2021 18:31:08 +0300
Subject: [PATCH 1/1] drivers/gpio/gpio-xilinx.c (updated): bitmap-fix
In-Reply-To: <YG8cWBkcF8ulHW0D@smile.fi.intel.com>
References: <YG8cWBkcF8ulHW0D@smile.fi.intel.com>
Message-ID: <20210408153108.81738-1-andriy.shevchenko@linux.intel.com>

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/gpio/gpio-xilinx.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index d5a08dcdd677..109b32104867 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -75,9 +75,14 @@ struct xgpio_instance {
 	struct clk *clk;
 };
 
+static inline int xgpio_from_bit(struct xgpio_instance *chip, int bit)
+{
+	return bitmap_bitremap(bit, chip->hw_map, chip->sw_map, 64);
+}
+
 static inline int xgpio_to_bit(struct xgpio_instance *chip, int gpio)
 {
-	return bitmap_bitremap(gpio, chip->sw_map, chip->hw_map, chip->gc.ngpio);
+	return bitmap_bitremap(gpio, chip->sw_map, chip->hw_map, 64);
 }
 
 static inline u32 xgpio_get_value32(const unsigned long *map, int bit)
@@ -207,11 +212,11 @@ static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
 
 	spin_lock_irqsave(&chip->gpio_lock, flags);
 
-	bitmap_replace(state, chip->state, hw_bits, hw_mask, gc->ngpio);
+	bitmap_replace(state, chip->state, hw_bits, hw_mask, 64);
 
 	xgpio_write_ch_all(chip, XGPIO_DATA_OFFSET, state);
 
-	bitmap_copy(chip->state, state, gc->ngpio);
+	bitmap_copy(chip->state, state, 64);
 
 	spin_unlock_irqrestore(&chip->gpio_lock, flags);
 }
@@ -501,6 +506,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 	DECLARE_BITMAP(rising, 64);
 	DECLARE_BITMAP(falling, 64);
 	DECLARE_BITMAP(all, 64);
+	int irq_offset;
 	u32 status;
 	u32 bit;
 
@@ -530,8 +536,10 @@ static void xgpio_irqhandler(struct irq_desc *desc)
 
 	dev_dbg(gc->parent, "IRQ rising %*pb falling %*pb\n", 64, rising, 64, falling);
 
-	for_each_set_bit(bit, all, 64)
-		generic_handle_irq(irq_find_mapping(gc->irq.domain, bit));
+	for_each_set_bit(bit, all, 64) {
+		irq_offset = xgpio_from_bit(chip, bit);
+		generic_handle_irq(irq_find_mapping(gc->irq.domain, irq_offset));
+	}
 
 	chained_irq_exit(irqchip, desc);
 }
-- 
2.30.2



From alexandru.elisei at arm.com  Thu Apr  8 16:36:40 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 8 Apr 2021 16:36:40 +0100
Subject: [PATCH] KVM: arm64: Fully zero the vcpu state on reset
In-Reply-To: <20210407181308.2265808-1-maz@kernel.org>
References: <20210407181308.2265808-1-maz@kernel.org>
Message-ID: <c34842b2-215a-e9d0-7d9d-a8cd64ed1171@arm.com>

Hi Marc,

On 4/7/21 7:13 PM, Marc Zyngier wrote:
> On vcpu reset, we expect all the registers to be brought back
> to their initial state, which happens to be a bunch of zeroes.
>
> However, some recent commit broke this, and is now leaving a bunch
> of registers (such as a FP state) with whatever was left by the
> guest. My bad.
>
> Just zero the whole vcpu context on reset. It is more than we
> strictly need, but at least we won't miss anything. This also
> zeroes the __hyp_running_vcpu pointer, which is always NULL
> for a vcpu anyway.

Had a look at struct kvm_cpu_context and indeed the only field which doesn't
represent a guest register is __hyp_running_vcpu. Did a grep for all the places
where __hyp_running_vcpu is used, and indeed the assumption is that for a guest
the pointer is NULL, as __sysreg_restore_el1_state() relies on it.

>
> Cc: stable at vger.kernel.org
> Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only")
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/kvm/reset.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index bd354cd45d28..ef1c49a1a3ad 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -240,8 +240,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  		break;
>  	}
>  
> -	/* Reset core registers */
> -	memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
> +	/* Zero all registers */
> +	memset(&vcpu->arch.ctxt, 0, sizeof(vcpu->arch.ctxt));

Checked that code earlier in the function does not touch the guest registers from
vcpu->arch.ctxt, to make sure we're not overwriting other reset values by mistake.
Looks good to me:

Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks,

Alex

>  	vcpu_gp_regs(vcpu)->pstate = pstate;
>  
>  	/* Reset system registers */


From valentin.schneider at arm.com  Thu Apr  8 16:43:16 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:16 +0100
Subject: [RFC PATCH 00/10] irqchip/irq-gic: Optimize masking by leveraging
 EOImode=1
Message-ID: <20210408154326.3988781-1-valentin.schneider@arm.com>

Hi folks!

This is the spiritual successor to [1], which was over 6 years ago (!).

Background
==========

GIC mechanics
+++++++++++++

There are three IRQ operations:
o Acknowledge. This gives us the IRQ number that interrupted us, and also
  - raises the running priority of the CPU interface to that of the IRQ
  - sets the active bit of the IRQ
o Priority Drop. This "clears" the running priority.
o Deactivate. This clears the active bit of the IRQ.

o The CPU interface has a running priority value. No interrupt of lower or
  equal priority will be signaled to the CPU attached to that interface. On
  Linux, we only have two priority values: pNMIs at highest priority, and
  everything else at the other priority.
o Most GIC interrupts have an "active" bit. This bit is set on Acknowledge
  and cleared on Deactivate. A given interrupt cannot be re-signaled to a
  CPU if it has its active bit set (i.e. if it "fires" again while it's
  being handled).

EOImode fun
+++++++++++

In EOImode=0, Priority Drop and Deactivate are undissociable. The
(simplified) interrupt handling flow is as follows: 

  <~IRQ>
    Acknowledge
    Priority Drop + Deactivate
    <interrupts can once again be signaled, once interrupts are re-enabled>

With EOImode=1, we can invoke each operation individually. This gives us:

  <~IRQ>
    Acknowledge
    Priority Drop
    <*other* interrupts can be signaled from here, once interrupts are re-enabled>
    Deactivate
    <*this* interrupt can be signaled again>

What this means is that with EOImode=1, any interrupt is kept "masked" by
its active bit between Priority Drop and Deactivate.

Threaded IRQs and ONESHOT
=========================

ONESHOT threaded IRQs must remain masked between the main handler and the
threaded handler. Right now we do this using the conventional irq_mask()
operations, which looks like this: 

 <irq handler>
   Acknowledge
   Priority Drop   
   irq_mask()
   Deactivate

 <threaded handler>
   irq_unmask()

However, masking for the GICs means poking the distributor, and there's no
sysreg for that - it's an MMIO access. We've seen above that our IRQ
handling can give us masking "for free", and this is what this patch set is
all about. It turns the above handling into:

  <irq handler>
    Acknowledge
    Priority Drop

  <threaded handler>
    Deactivate

No irq_mask() => fewer MMIO accesses => happier users (or so I've been
told). This is especially relevant to PREEMPT_RT which forces threaded
IRQs.
    
Testing
=======

GICv2
+++++

I've tested this on my Juno with forced irqthreads. This makes the pl011
IRQ into a threaded ONESHOT IRQ, so I spammed my keyboard into the console
and verified via ftrace that there were no irq_mask() / irq_unmask()
involved.

GICv3
+++++

I've tested this on my Ampere eMAG, which uncovered "fun" interactions with
the MSI domains. Did the same trick as the Juno with the pl011.

pNMIs cause said eMAG to freeze, but that's true even without my patches. I
did try them out under QEMU+KVM and that looked fine, although that means I
only got to test EOImode=0. I'll try to dig into this when I get some more
cycles.

TODOs
=====

MSI hierarchy story
+++++++++++++++++++

I 'hate' patch 8/10 because it's so very easy to break. See changelog for
my thoughts on the thing.

Performance numbers
+++++++++++++++++++

The whole point of this was to shave off some time spent issuing requests
to the distributor. On my Juno the IRQ for eth0 gets forcefully threaded
and thus becomes a ONESHOT threaded IRQ - I've tried to test this with
netperf, but the delta is lost in the noise (and there is quite a lot of
noise, unfortunately).

I'm still looking for something I can benchmark on the eMAG to get some
GICv3 results.

Links
=====

[1]: https://lore.kernel.org/lkml/1414235215-10468-1-git-send-email-marc.zyngier at arm.com/

Valentin Schneider (10):
  genirq: Add chip flag to denote automatic IRQ (un)masking
  genirq: Define irq_ack() and irq_eoi() helpers
  genirq: Employ ack_irq() and eoi_irq() where relevant
  genirq: Add handle_strict_flow_irq() flow handler
  genirq: Let purely flow-masked ONESHOT irqs through
    unmask_threaded_irq()
  genirq: Don't mask IRQ within flow handler if IRQ is flow-masked
  genirq, irq-gic-v3: Make NMI flow handlers use ->irq_ack() if
    available
  irqchip/gic-v3-its: Use irq_chip_ack_parent()
  irqchip/gic: Convert to handle_strict_flow_irq()
  irqchip/gic-v3: Convert to handle_strict_flow_irq()

 drivers/irqchip/irq-gic-v3-its-pci-msi.c |   1 +
 drivers/irqchip/irq-gic-v3-its.c         |   1 +
 drivers/irqchip/irq-gic-v3.c             |  27 ++++--
 drivers/irqchip/irq-gic.c                |  14 ++-
 include/linux/irq.h                      |  15 ++-
 kernel/irq/chip.c                        | 117 +++++++++++++++++++----
 kernel/irq/debugfs.c                     |   2 +
 kernel/irq/internals.h                   |   7 ++
 kernel/irq/manage.c                      |   2 +-
 9 files changed, 154 insertions(+), 32 deletions(-)

--
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:18 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:18 +0100
Subject: [RFC PATCH 02/10] genirq: Define irq_ack() and irq_eoi() helpers
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-3-valentin.schneider@arm.com>

The newly-added IRQCHIP_AUTOMASKS_FLOW flag requires some additional
bookkeeping around chip->{irq_ack, irq_eoi}() calls. Define wrappers around
those chip callbacks to drive the IRQD_IRQ_FLOW_MASKED state of an IRQ when
the chip has the IRQCHIP_AUTOMASKS_FLOW flag.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 kernel/irq/chip.c      | 16 ++++++++++++++++
 kernel/irq/internals.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 18c3b0e1568a..046b4486c88c 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -408,6 +408,22 @@ void irq_percpu_disable(struct irq_desc *desc, unsigned int cpu)
 	cpumask_clear_cpu(cpu, desc->percpu_enabled);
 }
 
+void ack_irq(struct irq_desc *desc)
+{
+	desc->irq_data.chip->irq_ack(&desc->irq_data);
+
+	if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW)
+		irq_state_set_flow_masked(desc);
+}
+
+void eoi_irq(struct irq_desc *desc)
+{
+	desc->irq_data.chip->irq_eoi(&desc->irq_data);
+
+	if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW)
+		irq_state_clr_flow_masked(desc);
+}
+
 static inline void mask_ack_irq(struct irq_desc *desc)
 {
 	if (desc->irq_data.chip->irq_mask_ack) {
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index b6c1cceddec0..090bd7868845 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -87,6 +87,8 @@ extern void irq_enable(struct irq_desc *desc);
 extern void irq_disable(struct irq_desc *desc);
 extern void irq_percpu_enable(struct irq_desc *desc, unsigned int cpu);
 extern void irq_percpu_disable(struct irq_desc *desc, unsigned int cpu);
+extern void irq_ack(struct irq_desc *desc);
+extern void irq_eoi(struct irq_desc *desc);
 extern void mask_irq(struct irq_desc *desc);
 extern void unmask_irq(struct irq_desc *desc);
 extern void unmask_threaded_irq(struct irq_desc *desc);
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:19 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:19 +0100
Subject: [RFC PATCH 03/10] genirq: Employ ack_irq() and eoi_irq() where
 relevant
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-4-valentin.schneider@arm.com>

This can easily be coccinelle'd to replace all existing chip->irq_{ack,
eoi} callsites, however not all callsites benefit from this
replacement: fasteoi flow handlers for instance only deal with an
->irq_eoi() callback. Instead, only patch callsites that can benefit from
the added functionality.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 kernel/irq/chip.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 046b4486c88c..936ef247b13d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -429,10 +429,12 @@ static inline void mask_ack_irq(struct irq_desc *desc)
 	if (desc->irq_data.chip->irq_mask_ack) {
 		desc->irq_data.chip->irq_mask_ack(&desc->irq_data);
 		irq_state_set_masked(desc);
+		if (desc->irq_data.chip->flags & IRQCHIP_AUTOMASKS_FLOW)
+			irq_state_set_flow_masked(desc);
 	} else {
 		mask_irq(desc);
 		if (desc->irq_data.chip->irq_ack)
-			desc->irq_data.chip->irq_ack(&desc->irq_data);
+			ack_irq(desc);
 	}
 }
 
@@ -463,7 +465,7 @@ void unmask_threaded_irq(struct irq_desc *desc)
 	struct irq_chip *chip = desc->irq_data.chip;
 
 	if (chip->flags & IRQCHIP_EOI_THREADED)
-		chip->irq_eoi(&desc->irq_data);
+		eoi_irq(desc);
 
 	unmask_irq(desc);
 }
@@ -680,7 +682,7 @@ EXPORT_SYMBOL_GPL(handle_level_irq);
 static void cond_unmask_eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
 {
 	if (!(desc->istate & IRQS_ONESHOT)) {
-		chip->irq_eoi(&desc->irq_data);
+		eoi_irq(desc);
 		return;
 	}
 	/*
@@ -691,10 +693,10 @@ static void cond_unmask_eoi_irq(struct irq_desc *desc, struct irq_chip *chip)
 	 */
 	if (!irqd_irq_disabled(&desc->irq_data) &&
 	    irqd_irq_masked(&desc->irq_data) && !desc->threads_oneshot) {
-		chip->irq_eoi(&desc->irq_data);
+		eoi_irq(desc);
 		unmask_irq(desc);
 	} else if (!(chip->flags & IRQCHIP_EOI_THREADED)) {
-		chip->irq_eoi(&desc->irq_data);
+		eoi_irq(desc);
 	}
 }
 
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:17 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:17 +0100
Subject: [RFC PATCH 01/10] genirq: Add chip flag to denote automatic IRQ
 (un)masking
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-2-valentin.schneider@arm.com>

Some IRQ chips such as the Arm GICs automagically mask / unmask an
IRQ during the handling of said IRQ. This renders further mask / unmask
operations within the flow handlers redundant, which we do want to leverage
as masking by itself is not cheap (Distributor access via MMIO for GICs).

This is different from having a chip->irq_mask_ack() callback as this
masking is:
- inherent to the chip->irq_ack() and *cannot* be omitted
- a *different* masking state than chip->irq_mask() (chip->irq_mask() is
  idempotent, chip->irq_ack() really isn't)

Add a chip flag, IRQCHIP_AUTOMASKS_FLOW, to denote chips with such
behaviour. Add a new IRQ data flag, IRQD_IRQ_FLOW_MASKED, to keep this
flow-induced mask state separate from regular mask / unmask operations
(IRQD_IRQ_MASKED).

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 include/linux/irq.h    | 10 ++++++++++
 kernel/irq/chip.c      |  5 +++++
 kernel/irq/debugfs.c   |  2 ++
 kernel/irq/internals.h |  5 +++++
 4 files changed, 22 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index bee82809107c..580b1b6b1799 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -219,6 +219,8 @@ struct irq_data {
  *				  irq_chip::irq_set_affinity() when deactivated.
  * IRQD_IRQ_ENABLED_ON_SUSPEND	- Interrupt is enabled on suspend by irq pm if
  *				  irqchip have flag IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
+ * IRQD_IRQ_FLOW_MASKED         - Interrupt is masked by ACK. Only EOI can
+ *                                clear this.
  */
 enum {
 	IRQD_TRIGGER_MASK		= 0xf,
@@ -245,6 +247,7 @@ enum {
 	IRQD_HANDLE_ENFORCE_IRQCTX	= (1 << 28),
 	IRQD_AFFINITY_ON_ACTIVATE	= (1 << 29),
 	IRQD_IRQ_ENABLED_ON_SUSPEND	= (1 << 30),
+	IRQD_IRQ_FLOW_MASKED            = (1 << 31),
 };
 
 #define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -349,6 +352,11 @@ static inline bool irqd_irq_masked(struct irq_data *d)
 	return __irqd_to_state(d) & IRQD_IRQ_MASKED;
 }
 
+static inline bool irqd_irq_flow_masked(struct irq_data *d)
+{
+	return __irqd_to_state(d) & IRQD_IRQ_FLOW_MASKED;
+}
+
 static inline bool irqd_irq_inprogress(struct irq_data *d)
 {
 	return __irqd_to_state(d) & IRQD_IRQ_INPROGRESS;
@@ -567,6 +575,7 @@ struct irq_chip {
  * IRQCHIP_SUPPORTS_NMI:              Chip can deliver NMIs, only for root irqchips
  * IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND:  Invokes __enable_irq()/__disable_irq() for wake irqs
  *                                    in the suspend path if they are in disabled state
+ * IRQCHIP_AUTOMASKS_FLOW:            chip->ack() masks and chip->eoi() unmasks
  */
 enum {
 	IRQCHIP_SET_TYPE_MASKED			= (1 <<  0),
@@ -579,6 +588,7 @@ enum {
 	IRQCHIP_SUPPORTS_LEVEL_MSI		= (1 <<  7),
 	IRQCHIP_SUPPORTS_NMI			= (1 <<  8),
 	IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND	= (1 <<  9),
+	IRQCHIP_AUTOMASKS_FLOW                  = (1 <<  10),
 };
 
 #include <linux/irqdesc.h>
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 8cc8e5713287..18c3b0e1568a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -173,6 +173,11 @@ static void irq_state_clr_masked(struct irq_desc *desc)
 	irqd_clear(&desc->irq_data, IRQD_IRQ_MASKED);
 }
 
+static void irq_state_clr_flow_masked(struct irq_desc *desc)
+{
+	irqd_clear(&desc->irq_data, IRQD_IRQ_FLOW_MASKED);
+}
+
 static void irq_state_clr_started(struct irq_desc *desc)
 {
 	irqd_clear(&desc->irq_data, IRQD_IRQ_STARTED);
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index e4cff358b437..3ae83622d701 100644
--- a/kernel/irq/debugfs.c
+++ b/kernel/irq/debugfs.c
@@ -58,6 +58,7 @@ static const struct irq_bit_descr irqchip_flags[] = {
 	BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
 	BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
 	BIT_MASK_DESCR(IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND),
+	BIT_MASK_DESCR(IRQCHIP_AUTOMASKS_FLOW),
 };
 
 static void
@@ -103,6 +104,7 @@ static const struct irq_bit_descr irqdata_states[] = {
 	BIT_MASK_DESCR(IRQD_IRQ_STARTED),
 	BIT_MASK_DESCR(IRQD_IRQ_DISABLED),
 	BIT_MASK_DESCR(IRQD_IRQ_MASKED),
+	BIT_MASK_DESCR(IRQD_IRQ_FLOW_MASKED),
 	BIT_MASK_DESCR(IRQD_IRQ_INPROGRESS),
 
 	BIT_MASK_DESCR(IRQD_PER_CPU),
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index 54363527feea..b6c1cceddec0 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -245,6 +245,11 @@ static inline void irq_state_set_masked(struct irq_desc *desc)
 	irqd_set(&desc->irq_data, IRQD_IRQ_MASKED);
 }
 
+static inline void irq_state_set_flow_masked(struct irq_desc *desc)
+{
+	irqd_set(&desc->irq_data, IRQD_IRQ_FLOW_MASKED);
+}
+
 #undef __irqd_to_state
 
 static inline void __kstat_incr_irqs_this_cpu(struct irq_desc *desc)
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:22 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:22 +0100
Subject: [RFC PATCH 06/10] genirq: Don't mask IRQ within flow handler if IRQ
 is flow-masked
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-7-valentin.schneider@arm.com>

mask_irq() lets an IRQ with IRQD_IRQ_FLOW_MASKED set be further masked via
chip->irq_mask(). This is necessary for unhandled IRQs as we want to keep
them masked beyond eoi_irq() (which clears IRQD_IRQ_FLOW_MASKED).

This is however not necessary in paths that do end up handling the IRQ and
are bounded by a final eoi_irq() - this is the case for chips with
IRQCHIP_AUTOMASKS_FLOW and IRQCHIP_EOI_THREADED.

Make handle_strict_flow_irq() leverage IRQCHIP_AUTOMASKS_FLOW and issue an
ack_irq() rather than a mask_ack_irq() when possible.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 kernel/irq/chip.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6c033b0044cb..1add0b4f0662 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -909,10 +909,9 @@ void handle_strict_flow_irq(struct irq_desc *desc)
 	struct irq_chip *chip = desc->irq_data.chip;
 
 	raw_spin_lock(&desc->lock);
-	mask_ack_irq(desc);
 
 	if (!irq_may_run(desc))
-		goto out;
+		goto out_mask;
 
 	desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
 
@@ -922,10 +921,21 @@ void handle_strict_flow_irq(struct irq_desc *desc)
 	 */
 	if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
 		desc->istate |= IRQS_PENDING;
-		goto out;
+		goto out_mask;
 	}
 
 	kstat_incr_irqs_this_cpu(desc);
+	/*
+	 * Masking is required if IRQ is ONESHOT and we can't rely on the
+	 * flow-masking persisting down to irq_finalize_oneshot()
+	 * (in the IRQ thread).
+	 */
+	if ((desc->istate & IRQS_ONESHOT) &&
+	    (!(chip->flags & IRQCHIP_AUTOMASKS_FLOW) ||
+	     !(chip->flags & IRQCHIP_EOI_THREADED)))
+		mask_ack_irq(desc);
+	else
+		ack_irq(desc);
 
 	handle_irq_event(desc);
 
@@ -933,7 +943,8 @@ void handle_strict_flow_irq(struct irq_desc *desc)
 
 	raw_spin_unlock(&desc->lock);
 	return;
-out:
+out_mask:
+	mask_ack_irq(desc);
 	/*
 	 * XXX: this is where IRQCHIP_EOI_IF_HANDLED would be checked, but
 	 * it's conceptually incompatible with this handler (it breaks the
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:20 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:20 +0100
Subject: [RFC PATCH 04/10] genirq: Add handle_strict_flow_irq() flow handler
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-5-valentin.schneider@arm.com>

The GIC family of irqchips have been so far treated as "fasteoi"
chips. As handle_fasteoi_irq() states, this implies:

 *	Only a single callback will be issued to the chip: an ->eoi()
 *	call when the interrupt has been serviced.

However, the GICs have an operating mode (EOImode=1) which requires an
additional chip interaction during the IRQ handling. Said operating mode
already has some uses with virtualization, but could also be leveraged to
slightly optimize ONESHOT IRQs.

This extra interaction is currently hidden away in the drivers, but further
exploiting its effects (see IRQD_IRQ_FLOW_MASKED) requires lifting it from
the driver code into core code. It so happens that it fits the role of
->irq_ack(); unfortunately, the GICs require both callbacks to be strictly
paired with one another: for a given IRQ activation, there must be a single
->irq_ack() followed by a single ->irq_eoi(). No more, no less, and in that
order.

Introduce a new flow handler which guarantees said ack / eoi pairing. Note
that it is strikingly similar to handle_fasteoi_mask_irq() for now, but
will be further modified in later patches

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 include/linux/irq.h |  1 +
 kernel/irq/chip.c   | 48 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 580b1b6b1799..b605f0929d97 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -661,6 +661,7 @@ extern void handle_edge_irq(struct irq_desc *desc);
 extern void handle_edge_eoi_irq(struct irq_desc *desc);
 extern void handle_simple_irq(struct irq_desc *desc);
 extern void handle_untracked_irq(struct irq_desc *desc);
+extern void handle_strict_flow_irq(struct irq_desc *desc);
 extern void handle_percpu_irq(struct irq_desc *desc);
 extern void handle_percpu_devid_irq(struct irq_desc *desc);
 extern void handle_bad_irq(struct irq_desc *desc);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 936ef247b13d..6c033b0044cb 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -896,6 +896,54 @@ void handle_edge_eoi_irq(struct irq_desc *desc)
 }
 #endif
 
+/**
+ *	handle_strict_flow_irq - irq handler for strict controllers
+ *	@desc:	the interrupt description structure for this irq
+ *
+ *      Ensures strict pairing of ->ack() and ->eoi() for any IRQ passing
+ *      through here. The ->eoi() may be deferred to the tail of the IRQ thread
+ *      for ONESHOT IRQs.
+ */
+void handle_strict_flow_irq(struct irq_desc *desc)
+{
+	struct irq_chip *chip = desc->irq_data.chip;
+
+	raw_spin_lock(&desc->lock);
+	mask_ack_irq(desc);
+
+	if (!irq_may_run(desc))
+		goto out;
+
+	desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
+
+	/*
+	 * If it's disabled or no action available then keep it masked and
+	 * get out of here:
+	 */
+	if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
+		desc->istate |= IRQS_PENDING;
+		goto out;
+	}
+
+	kstat_incr_irqs_this_cpu(desc);
+
+	handle_irq_event(desc);
+
+	cond_unmask_eoi_irq(desc, chip);
+
+	raw_spin_unlock(&desc->lock);
+	return;
+out:
+	/*
+	 * XXX: this is where IRQCHIP_EOI_IF_HANDLED would be checked, but
+	 * it's conceptually incompatible with this handler (it breaks the
+	 * strict pairing)
+	 */
+	eoi_irq(desc);
+	raw_spin_unlock(&desc->lock);
+}
+EXPORT_SYMBOL_GPL(handle_strict_flow_irq);
+
 /**
  *	handle_percpu_irq - Per CPU local irq handler
  *	@desc:	the interrupt description structure for this irq
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:24 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:24 +0100
Subject: [RFC PATCH 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent()
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-9-valentin.schneider@arm.com>

Subsequent patches will make the GIC irqchips use a flow handler that
issues an ->irq_ack(). irqchips of child domains need to handle this.

Note: I'm very much not fond of this; this is treacherous and explodes if
any parent chip doesn't have an ->ack() callback. It turns out okay with
EOImode=0 because handle_fasteoi_irq() doesn't issue any ->ack(), but that
is very fragile at best.

An alternative would be to
o make irq_chip_ack_parent() check the callback against NULL
o make irq_chip_ack_parent() the default chip->irq_ack() via
  MSI_FLAG_USE_DEF_CHIP_OPS.

XXX: what about pMSI and fMSI ?

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 drivers/irqchip/irq-gic-v3-its-pci-msi.c | 1 +
 drivers/irqchip/irq-gic-v3-its.c         | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index ad2810c017ed..5bc2787ee86a 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -27,6 +27,7 @@ static struct irq_chip its_msi_irq_chip = {
 	.name			= "ITS-MSI",
 	.irq_unmask		= its_unmask_msi_irq,
 	.irq_mask		= its_mask_msi_irq,
+	.irq_ack		= irq_chip_ack_parent,
 	.irq_eoi		= irq_chip_eoi_parent,
 	.irq_write_msi_msg	= pci_msi_domain_write_msg,
 };
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index c3485b230d70..d6856750c084 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1971,6 +1971,7 @@ static struct irq_chip its_irq_chip = {
 	.name			= "ITS",
 	.irq_mask		= its_mask_irq,
 	.irq_unmask		= its_unmask_irq,
+	.irq_ack		= irq_chip_ack_parent,
 	.irq_eoi		= irq_chip_eoi_parent,
 	.irq_set_affinity	= its_set_affinity,
 	.irq_compose_msi_msg	= its_irq_compose_msi_msg,
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:23 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:23 +0100
Subject: [RFC PATCH 07/10] genirq,
 irq-gic-v3: Make NMI flow handlers use ->irq_ack() if available
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-8-valentin.schneider@arm.com>

Subsequent patches will make the gic-v3 irqchip use an ->irq_ack()
callback. As a preparation, make the NMI flow handlers call said callback
if it is available.

Since this departs from the fasteoi scheme of only issuing a suffix
->eoi(), rename the NMI flow handlers.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 drivers/irqchip/irq-gic-v3.c |  4 ++--
 include/linux/irq.h          |  4 ++--
 kernel/irq/chip.c            | 25 ++++++++++++++-----------
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 94b89258d045..242a8fc5ec86 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -484,10 +484,10 @@ static int gic_irq_nmi_setup(struct irq_data *d)
 		/* Setting up PPI as NMI, only switch handler for first NMI */
 		if (!refcount_inc_not_zero(&ppi_nmi_refs[idx])) {
 			refcount_set(&ppi_nmi_refs[idx], 1);
-			desc->handle_irq = handle_percpu_devid_fasteoi_nmi;
+			desc->handle_irq = handle_percpu_devid_nmi;
 		}
 	} else {
-		desc->handle_irq = handle_fasteoi_nmi;
+		desc->handle_irq = handle_nmi;
 	}
 
 	gic_irq_set_prio(d, GICD_INT_NMI_PRI);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index b605f0929d97..c39f46e37487 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -667,8 +667,8 @@ extern void handle_percpu_devid_irq(struct irq_desc *desc);
 extern void handle_bad_irq(struct irq_desc *desc);
 extern void handle_nested_irq(unsigned int irq);
 
-extern void handle_fasteoi_nmi(struct irq_desc *desc);
-extern void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc);
+extern void handle_nmi(struct irq_desc *desc);
+extern void handle_percpu_devid_nmi(struct irq_desc *desc);
 
 extern int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg);
 extern int irq_chip_pm_get(struct irq_data *data);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 1add0b4f0662..ea077333d676 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -748,18 +748,16 @@ void handle_fasteoi_irq(struct irq_desc *desc)
 EXPORT_SYMBOL_GPL(handle_fasteoi_irq);
 
 /**
- *	handle_fasteoi_nmi - irq handler for NMI interrupt lines
+ *	handle_nmi - irq handler for NMI interrupt lines
  *	@desc:	the interrupt description structure for this irq
  *
  *	A simple NMI-safe handler, considering the restrictions
  *	from request_nmi.
  *
- *	Only a single callback will be issued to the chip: an ->eoi()
- *	call when the interrupt has been serviced. This enables support
- *	for modern forms of interrupt handlers, which handle the flow
- *	details in hardware, transparently.
+ *      An ->ack() callback will be issued before servicing the interrupt,
+ *      followed by an ->eoi() call.
  */
-void handle_fasteoi_nmi(struct irq_desc *desc)
+void handle_nmi(struct irq_desc *desc)
 {
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	struct irqaction *action = desc->action;
@@ -768,6 +766,9 @@ void handle_fasteoi_nmi(struct irq_desc *desc)
 
 	__kstat_incr_irqs_this_cpu(desc);
 
+	if (chip->irq_ack)
+		chip->irq_ack(&desc->irq_data);
+
 	trace_irq_handler_entry(irq, action);
 	/*
 	 * NMIs cannot be shared, there is only one action.
@@ -778,7 +779,7 @@ void handle_fasteoi_nmi(struct irq_desc *desc)
 	if (chip->irq_eoi)
 		chip->irq_eoi(&desc->irq_data);
 }
-EXPORT_SYMBOL_GPL(handle_fasteoi_nmi);
+EXPORT_SYMBOL_GPL(handle_nmi);
 
 /**
  *	handle_edge_irq - edge type IRQ handler
@@ -1027,14 +1028,13 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
 }
 
 /**
- * handle_percpu_devid_fasteoi_nmi - Per CPU local NMI handler with per cpu
+ * handle_percpu_devid_nmi - Per CPU local NMI handler with per cpu
  *				     dev ids
  * @desc:	the interrupt description structure for this irq
  *
- * Similar to handle_fasteoi_nmi, but handling the dev_id cookie
- * as a percpu pointer.
+ * Similar to handle_nmi, but handling the dev_id cookie as a percpu pointer.
  */
-void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
+void handle_percpu_devid_nmi(struct irq_desc *desc)
 {
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	struct irqaction *action = desc->action;
@@ -1043,6 +1043,9 @@ void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
 
 	__kstat_incr_irqs_this_cpu(desc);
 
+	if (chip->irq_ack)
+		chip->irq_ack(&desc->irq_data);
+
 	trace_irq_handler_entry(irq, action);
 	res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
 	trace_irq_handler_exit(irq, action, res);
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:21 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:21 +0100
Subject: [RFC PATCH 05/10] genirq: Let purely flow-masked ONESHOT irqs through
 unmask_threaded_irq()
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-6-valentin.schneider@arm.com>

A subsequent patch will let IRQs end up in irq_finalize_oneshot() without
IRQD_IRQ_MASKED, but with IRQD_IRQ_FLOW_MASKED set instead. Let such IRQs
receive their final ->irq_eoi().

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 kernel/irq/manage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index e976c4927b25..59c8056d6714 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1076,7 +1076,7 @@ static void irq_finalize_oneshot(struct irq_desc *desc,
 	desc->threads_oneshot &= ~action->thread_mask;
 
 	if (!desc->threads_oneshot && !irqd_irq_disabled(&desc->irq_data) &&
-	    irqd_irq_masked(&desc->irq_data))
+	    (irqd_irq_masked(&desc->irq_data) || irqd_irq_flow_masked(&desc->irq_data)))
 		unmask_threaded_irq(desc);
 
 out_unlock:
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:25 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:25 +0100
Subject: [RFC PATCH 09/10] irqchip/gic: Convert to handle_strict_flow_irq()
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-10-valentin.schneider@arm.com>

Now that the proper infrastructure is in place, convert the irq-gic chip to
use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.

For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOI write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.

The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.

EOImode=0 handling remains unchanged.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 drivers/irqchip/irq-gic.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index b1d9c22caf2e..4919478c3e41 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -344,8 +344,6 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)
 		if (unlikely(irqnr >= 1020))
 			break;
 
-		if (static_branch_likely(&supports_deactivate_key))
-			writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);
 		isb();
 
 		/*
@@ -1012,7 +1010,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 		break;
 	default:
 		irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data,
-				    handle_fasteoi_irq, NULL, NULL);
+				    static_branch_likely(&supports_deactivate_key) ?
+				    handle_strict_flow_irq : handle_fasteoi_irq,
+				    NULL, NULL);
 		irq_set_probe(irq);
 		irqd_set_single_target(irqd);
 		break;
@@ -1116,8 +1116,16 @@ static void gic_init_chip(struct gic_chip_data *gic, struct device *dev,
 
 	if (use_eoimode1) {
 		gic->chip.irq_mask = gic_eoimode1_mask_irq;
+		gic->chip.irq_ack = gic_eoi_irq;
 		gic->chip.irq_eoi = gic_eoimode1_eoi_irq;
 		gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity;
+
+		/*
+		 * eoimode0 shouldn't expose FLOW_MASK because the priority
+		 * drop is undissociable from the deactivation, and we do need
+		 * the priority drop to happen within the flow handler.
+		 */
+		gic->chip.flags |= IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED;
 	}
 
 	if (gic == &gic_data[0]) {
-- 
2.25.1



From valentin.schneider at arm.com  Thu Apr  8 16:43:26 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu,  8 Apr 2021 16:43:26 +0100
Subject: [RFC PATCH 10/10] irqchip/gic-v3: Convert to handle_strict_flow_irq()
In-Reply-To: <20210408154326.3988781-1-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
Message-ID: <20210408154326.3988781-11-valentin.schneider@arm.com>

Now that the proper infrastructure is in place, convert the irq-gic-v3 chip
to use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW.

For EOImode=1, the Priority Drop is moved from gic_handle_irq() into
chip->irq_ack(). This effectively pushes the EOIR write down into
->handle_irq(), but doesn't change its ordering wrt the irqaction
handling.

The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the
->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This
means a threaded ONESHOT IRQ can now be handled entirely without a single
chip->irq_mask() call.

Despite not having an Active state, LPIs are made to use
handle_strict_flow_irq() as well. This lets them re-use
gic_eoimode1_chip.irq_ack() as Priority Drop, rather than special-case them
in gic_handle_irq().

EOImode=0 handling remains unchanged.

Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
---
 drivers/irqchip/irq-gic-v3.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 242a8fc5ec86..da73398117a7 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -626,8 +626,6 @@ static inline void gic_handle_nmi(u32 irqnr, struct pt_regs *regs)
 	if (irqs_enabled)
 		nmi_enter();
 
-	if (static_branch_likely(&supports_deactivate_key))
-		gic_write_eoir(irqnr);
 	/*
 	 * Leave the PSR.I bit set to prevent other NMIs to be
 	 * received while handling this one.
@@ -663,9 +661,11 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 	if ((irqnr >= 1020 && irqnr <= 1023))
 		return;
 
-	if (static_branch_likely(&supports_deactivate_key))
-		gic_write_eoir(irqnr);
-	else
+	/*
+	 * eoimode1 will give us an isb in handle_domain_irq(), before
+	 * handle_irq_event().
+	 */
+	if (!static_branch_likely(&supports_deactivate_key))
 		isb();
 
 	if (handle_domain_irq(gic_data.domain, irqnr, regs)) {
@@ -1276,6 +1276,7 @@ static struct irq_chip gic_eoimode1_chip = {
 	.name			= "GICv3",
 	.irq_mask		= gic_eoimode1_mask_irq,
 	.irq_unmask		= gic_unmask_irq,
+	.irq_ack                = gic_eoi_irq,
 	.irq_eoi		= gic_eoimode1_eoi_irq,
 	.irq_set_type		= gic_set_type,
 	.irq_set_affinity	= gic_set_affinity,
@@ -1288,7 +1289,9 @@ static struct irq_chip gic_eoimode1_chip = {
 	.ipi_send_mask		= gic_ipi_send_mask,
 	.flags			= IRQCHIP_SET_TYPE_MASKED |
 				  IRQCHIP_SKIP_SET_WAKE |
-				  IRQCHIP_MASK_ON_SUSPEND,
+				  IRQCHIP_MASK_ON_SUSPEND |
+				  IRQCHIP_AUTOMASKS_FLOW |
+				  IRQCHIP_EOI_THREADED,
 };
 
 static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
@@ -1312,7 +1315,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 	case SPI_RANGE:
 	case ESPI_RANGE:
 		irq_domain_set_info(d, irq, hw, chip, d->host_data,
-				    handle_fasteoi_irq, NULL, NULL);
+				    static_branch_likely(&supports_deactivate_key) ?
+				    handle_strict_flow_irq : handle_fasteoi_irq,
+				    NULL, NULL);
 		irq_set_probe(irq);
 		irqd_set_single_target(irqd);
 		break;
@@ -1321,7 +1326,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 		if (!gic_dist_supports_lpis())
 			return -EPERM;
 		irq_domain_set_info(d, irq, hw, chip, d->host_data,
-				    handle_fasteoi_irq, NULL, NULL);
+				    static_branch_likely(&supports_deactivate_key) ?
+				    handle_strict_flow_irq : handle_fasteoi_irq,
+				    NULL, NULL);
 		break;
 
 	default:
-- 
2.25.1



From arnd at kernel.org  Thu Apr  8 16:49:27 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:49:27 +0200
Subject: [GIT PULL] Qualcomm driver updates for 5.13
In-Reply-To: <20210404164951.713045-1-bjorn.andersson@linaro.org>
References: <20210404164951.713045-1-bjorn.andersson@linaro.org>
Message-ID: <161789693288.1636044.1145984086185945508.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Sun, 4 Apr 2021 11:49:51 -0500, Bjorn Andersson wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-5.13
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 207481077b07d53cb378bc5dc71ae5379c91e8a8

       Arnd


From arnd at kernel.org  Thu Apr  8 16:49:28 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:49:28 +0200
Subject: [GIT PULL] SoCFPGA firmware update for v5.13
In-Reply-To: <20210405155026.86309-1-dinguyen@kernel.org>
References: <20210405155026.86309-1-dinguyen@kernel.org>
Message-ID: <161789693296.1636044.15606458085850254179.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Mon, 5 Apr 2021 10:50:26 -0500, Dinh Nguyen wrote:
> Please pull in this patch for v5.13.
> 
> Thanks,
> Dinh
> 
> The following changes since commit 4483397b03536506535d611b0cb28a81a69e8edf:
> 
>   ARM: socfpga: drop ARCH_SOCFPGA (2021-03-23 11:03:36 -0500)
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 0ffc253e2e0ea7b0a1a6b73f019ba38dfe7a3e44

       Arnd


From arnd at kernel.org  Thu Apr  8 16:49:31 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:49:31 +0200
Subject: [GIT PULL] soc: mediatek: changes for v5.12 (second round)
In-Reply-To: <14104322-3a6c-e8eb-cd21-a5343a81aa0f@gmail.com>
References: <14104322-3a6c-e8eb-cd21-a5343a81aa0f@gmail.com>
Message-ID: <161789693304.1636044.1039014965097284178.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 7 Apr 2021 13:00:14 +0200, Matthias Brugger wrote:
> Here comes the second round of soc drivers patches. Hope I'm not too late.
> 
> Please have a look.
> Best regards,
> Matthias

Merged into arm/drivers, thanks!

merge commit: 4a3c88952e13172bde13bbb718265805861bcab2

       Arnd


From arnd at kernel.org  Thu Apr  8 16:49:32 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:49:32 +0200
Subject: [GIT PULL] firmware: arm_scmi: updates for v5.13
In-Reply-To: <20210331100657.ilu63i4swnr3zp4e@bogus>
References: <20210331100657.ilu63i4swnr3zp4e@bogus>
Message-ID: <161789693280.1636044.5523561185670345817.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 31 Mar 2021 11:06:57 +0100, Sudeep Holla wrote:
> Please pull !
> 
> All the drivers files have been acked by respective maintainers.
> There is a conflict with IIO tree in linux-next with right fix there,
> we might get same conflict depending on what gets merged first upstream.
> 
> Regards,
> Sudeep
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 4be3f47e1bd5c9be4c4b95de5f3531f062a28a66

       Arnd


From arnd at kernel.org  Thu Apr  8 16:50:23 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:50:23 +0200
Subject: [GIT PULL] Qualcomm fix for 5.12
In-Reply-To: <20210404155604.712236-1-bjorn.andersson@linaro.org>
References: <20210404155604.712236-1-bjorn.andersson@linaro.org>
Message-ID: <161789701046.1636297.9206583528663846986.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Sun, 4 Apr 2021 10:56:04 -0500, Bjorn Andersson wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-fixes-for-5.12
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: aa68a77863b3fa74aa6659c7cb46ce708a09429f

       Arnd


From arnd at kernel.org  Thu Apr  8 16:50:24 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 17:50:24 +0200
Subject: [GIT PULL] Allwinner Fixes for 5.12
In-Reply-To: <9972a85e-60b7-49f4-a246-db3396dd4764.lettre@localhost>
References: <9972a85e-60b7-49f4-a246-db3396dd4764.lettre@localhost>
Message-ID: <161789701009.1636297.18213875716036354287.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 7 Apr 2021 13:45:29 +0200, Maxime Ripard wrote:
> Here's the fixes PR rebase with my SoB added
> 
> Please pull the following changes for the current release.
> 
> Thanks!
> Maxime
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: 974be36e1ca987a1940eb6894a2b5bb631049791

       Arnd


From marcan at marcan.st  Thu Apr  8 16:55:28 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri, 9 Apr 2021 00:55:28 +0900
Subject: [GIT PULL] Apple M1 SoC platform bring-up for 5.13
Message-ID: <bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st>

Hi Arnd and all,

Here's the final version of the M1 SoC bring-up series, based on
v4 which was reviewed here:

https://lore.kernel.org/linux-arm-kernel/20210402090542.131194-1-marcan at marcan.st/T/#u

Changes since v4 as reviewed:

* Sort DT soc bus nodes by address (NFC)
* Introduce defines to better represent the meaning of hwirq IDs in
   the AIC driver (NFC)
* Update stale comments in AIC (NFC)
* Make of_mmio_is_nonposted static and not exported (export change only)
* Rewrite pci_remap_cfgspace() more succintly using ?: operator (NFC)
* Update FIQ series merge to arm64/for-next/fiq
* Remove the nVHE series (we will let this go through amd64 on its own)

The public key that signed the tag is available here:

https://mrcn.st/pub

Or pull e22a629a4c515dd5 from keys.gnupg.net or pgp.mit.edu.

Cheers,
Hector

The following changes since commit 847bea3d08af9158ae9e17b43632d6aa4f1702a0:

   Merge remote-tracking branch 'arm64/for-next/fiq' (2021-04-08 19:21:57 +0900)

are available in the Git repository at:

   https://github.com/AsahiLinux/linux.git tags/m1-soc-bringup-v5

for you to fetch changes up to 7d2d16ccf15d8eb84accfaf44a0b324f36e39588:

   arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree (2021-04-08 20:18:41 +0900)

----------------------------------------------------------------
Apple M1 SoC platform bring-up

This series brings up initial support for the Apple M1 SoC, used in the
2020 Mac Mini, MacBook Pro, and MacBook Air models.

The following features are supported in this initial port:

- UART (samsung-style) with earlycon support
- Interrupts, including affinity and IPIs (Apple Interrupt Controller)
- SMP (through standard spin-table support)
- simplefb-based framebuffer
- Devicetree for the Mac Mini (should work for the others too at this
   stage)

== Merge notes ==

This tag is based on v5.12-rc3 and includes the following two
dependencies merged in:

* Tip of arm64/for-next/fiq: 3889ba70102e
   This is a hard (build) dependency that adds support for FIQ
   interrupts, which is required for this SoC and the included AIC
   irqchip driver. It is already merged in the arm64 tree.

* From tty/tty-next: 71b25f4df984
   This commit includes the Samsung UART changes that have already
   been merged into the tty tree. It is nominally a soft dependency,
   but if this series is merged first it would trigger devicetree
   validation failures as the DT included in it depends on bindings
   introduced in the tty tree.

   There was a merge conflict here. It has been resolved the same
   way gregkh resolved it in a later tty merge, and both tty-next
   and torvalds/master merge cleanly with this series at this time.

This series additionally depends on the nVHE changes in [1] to boot,
but we are letting those get merged through arm64.

[1] https://lore.kernel.org/linux-arm-kernel/20210408131010.1109027-1-maz at kernel.org/T/#u

== Testing notes ==

This has been tested on an Apple M1 Mac Mini booting to a framebuffer
and serial console, with SMP and KASLR, with an arm64 defconfig
(+ CONFIG_FB_SIMPLE for the fb). In addition, the AIC driver now
supports running in EL1, tested in UP mode only.

== About the hardware ==

These machines officially support booting unsigned/user-provided
XNU-like kernels, with a very different boot protocol and devicetree
format. We are developing an initial bootloader, m1n1 [1], to take care
of as many hardware peculiarities as possible and present a standard
Linux arm64 boot protocol and device tree. In the future, I expect that
production setups will add U-Boot and perhaps GRUB into the boot chain,
to make the boot process similar to other ARM64 platforms.

The machines expose their debug UART over USB Type C, triggered with
vendor-specific USB-PD commands. Currently, the easiest way to get a
serial console on these machines is to use a second M1 box and a simple
USB C cable [2]. You can also build a DIY interface using an Arduino, a
FUSB302 chip or board, and a 1.2V UART-TTL adapter [3]. In the coming
weeks we will be designing an open hardware project to provide
serial/debug connectivity to these machines (and, hopefully, also
support other UART-over-Type C setups from other vendors). Please
contact me privately if you are interested in getting an early prototype
version of one of these devices.

We also have WIP/not merged yet support for loading kernels and
interacting via dwc3 usb-gadget, which works with a standard C-C or C-A
cable and any Linux host.

A quickstart guide to booting Linux kernels on these machines is
available at [4], and we are documenting the hardware at [5].

[1] https://github.com/AsahiLinux/m1n1/
[2] https://github.com/AsahiLinux/macvdmtool/
[3] https://github.com/AsahiLinux/vdmtool/
[4] https://github.com/AsahiLinux/docs/wiki/Developer-Quickstart
[5] https://github.com/AsahiLinux/docs/wiki

== Project Blurb ==

Asahi Linux is an open community project dedicated to developing and
maintaining mainline support for Apple Silicon on Linux. Feel free to
drop by #asahi and #asahi-dev on freenode to chat with us, or check
our website for more information on the project:

https://asahilinux.org/

Signed-off-by: Hector Martin <marcan at marcan.st>

----------------------------------------------------------------
Arnd Bergmann (1):
       docs: driver-api: device-io: Document I/O access functions

Hector Martin (17):
       dt-bindings: vendor-prefixes: Add apple prefix
       dt-bindings: arm: apple: Add bindings for Apple ARM platforms
       dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles
       arm64: cputype: Add CPU implementor & types for the Apple M1 cores
       dt-bindings: timer: arm,arch_timer: Add interrupt-names support
       arm64: arch_timer: Implement support for interrupt-names
       asm-generic/io.h:  Add a non-posted variant of ioremap()
       docs: driver-api: device-io: Document ioremap() variants & access funcs
       arm64: Implement ioremap_np() to map MMIO as nGnRnE
       asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
       of/address: Add infrastructure to declare MMIO as non-posted
       arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h
       dt-bindings: interrupt-controller: Add DT bindings for apple-aic
       irqchip/apple-aic: Add support for the Apple Interrupt Controller
       arm64: Kconfig: Introduce CONFIG_ARCH_APPLE
       dt-bindings: display: Add apple,simple-framebuffer
       arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree

  Documentation/devicetree/bindings/arm/apple.yaml   |  64 ++
  Documentation/devicetree/bindings/arm/cpus.yaml    |   2 +
  .../bindings/display/simple-framebuffer.yaml       |   5 +
  .../bindings/interrupt-controller/apple,aic.yaml   |  88 +++
  .../devicetree/bindings/timer/arm,arch_timer.yaml  |  19 +
  .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
  Documentation/driver-api/device-io.rst             | 356 +++++++++
  Documentation/driver-api/driver-model/devres.rst   |   1 +
  MAINTAINERS                                        |  14 +
  arch/arm64/Kconfig.platforms                       |   7 +
  arch/arm64/boot/dts/Makefile                       |   1 +
  arch/arm64/boot/dts/apple/Makefile                 |   2 +
  arch/arm64/boot/dts/apple/t8103-j274.dts           |  45 ++
  arch/arm64/boot/dts/apple/t8103.dtsi               | 135 ++++
  arch/arm64/configs/defconfig                       |   1 +
  arch/arm64/include/asm/cputype.h                   |   6 +
  arch/arm64/include/asm/io.h                        |  11 +-
  arch/arm64/include/asm/sysreg.h                    |  60 ++
  arch/sparc/include/asm/io_64.h                     |   4 +
  drivers/clocksource/arm_arch_timer.c               |  24 +-
  drivers/irqchip/Kconfig                            |   8 +
  drivers/irqchip/Makefile                           |   1 +
  drivers/irqchip/irq-apple-aic.c                    | 852 +++++++++++++++++++++
  drivers/of/address.c                               |  43 +-
  include/asm-generic/io.h                           |  22 +-
  include/asm-generic/iomap.h                        |   9 +
  include/clocksource/arm_arch_timer.h               |   1 +
  .../dt-bindings/interrupt-controller/apple-aic.h   |  15 +
  include/linux/cpuhotplug.h                         |   1 +
  include/linux/io.h                                 |  18 +-
  include/linux/ioport.h                             |   1 +
  include/linux/irqchip/arm-gic-v3.h                 |  56 --
  lib/devres.c                                       |  22 +
  33 files changed, 1816 insertions(+), 80 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/arm/apple.yaml
  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
  create mode 100644 arch/arm64/boot/dts/apple/Makefile
  create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
  create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi
  create mode 100644 drivers/irqchip/irq-apple-aic.c
  create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h


From robh at kernel.org  Thu Apr  8 16:59:06 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 10:59:06 -0500
Subject: [PATCH v5 1/4] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210408011637.5361-2-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-2-zev@bewilderbeest.net>
Message-ID: <20210408155906.GA1553685@robh.at.kernel.org>

On Wed, 07 Apr 2021 20:16:34 -0500, Zev Weiss wrote:
> This property ties SIRQ polarity to SCU register bits that don't
> necessarily have any direct relationship to it; the only use of it was
> removed in commit c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq
> polarity").
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> Reviewed-by: Joel Stanley <joel at jms.id.au>
> ---
>  Documentation/devicetree/bindings/serial/8250.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From alexandru.elisei at arm.com  Thu Apr  8 16:59:12 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 8 Apr 2021 16:59:12 +0100
Subject: [RFC PATCH v3 1/2] KVM: arm64: Move CMOs from user_mem_abort to
 the fault handlers
In-Reply-To: <b688cf37-16e6-d068-d97f-146c64afca08@huawei.com>
References: <20210326031654.3716-1-wangyanan55@huawei.com>
 <20210326031654.3716-2-wangyanan55@huawei.com>
 <cd6c8a86-b7b2-3d3e-121a-c9d1cb23c4b3@arm.com>
 <b688cf37-16e6-d068-d97f-146c64afca08@huawei.com>
Message-ID: <94911842-d55d-bd6f-74ea-a947c09584c2@arm.com>

Hi Yanan,

On 4/8/21 10:23 AM, wangyanan (Y) wrote:
> Hi Alex,
>
> On 2021/4/7 23:31, Alexandru Elisei wrote:
>> Hi Yanan,
>>
>> On 3/26/21 3:16 AM, Yanan Wang wrote:
>>> We currently uniformly permorm CMOs of D-cache and I-cache in function
>>> user_mem_abort before calling the fault handlers. If we get concurrent
>>> guest faults(e.g. translation faults, permission faults) or some really
>>> unnecessary guest faults caused by BBM, CMOs for the first vcpu are
>> I can't figure out what BBM means.
> Just as Will has explained, it's Break-Before-Make rule. When we need to
> replace an old table entry with a new one, we should firstly invalidate
> the old table entry(Break), before installation of the new entry(Make).

Got it, thank you and Will for the explanation.

>
>
> And I think this patch mainly introduces benefits in two specific scenarios:
> 1) In a VM startup, it will improve efficiency of handling page faults incurred
> by vCPUs, when initially populating stage2 page tables.
> 2) After live migration, the heavy workload will be resumed on the destination
> VMs, however all the stage2 page tables need to be rebuilt.
>>> necessary while the others later are not.
>>>
>>> By moving CMOs to the fault handlers, we can easily identify conditions
>>> where they are really needed and avoid the unnecessary ones. As it's a
>>> time consuming process to perform CMOs especially when flushing a block
>>> range, so this solution reduces much load of kvm and improve efficiency
>>> of the page table code.
>>>
>>> So let's move both clean of D-cache and invalidation of I-cache to the
>>> map path and move only invalidation of I-cache to the permission path.
>>> Since the original APIs for CMOs in mmu.c are only called in function
>>> user_mem_abort, we now also move them to pgtable.c.
>>>
>>> Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
>>> ---
>>> ? arch/arm64/include/asm/kvm_mmu.h | 31 ---------------
>>> ? arch/arm64/kvm/hyp/pgtable.c???? | 68 +++++++++++++++++++++++++-------
>>> ? arch/arm64/kvm/mmu.c???????????? | 23 ++---------
>>> ? 3 files changed, 57 insertions(+), 65 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>>> index 90873851f677..c31f88306d4e 100644
>>> --- a/arch/arm64/include/asm/kvm_mmu.h
>>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>>> @@ -177,37 +177,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu
>>> *vcpu)
>>> ????? return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
>>> ? }
>>> ? -static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long
>>> size)
>>> -{
>>> -??? void *va = page_address(pfn_to_page(pfn));
>>> -
>>> -??? /*
>>> -???? * With FWB, we ensure that the guest always accesses memory using
>>> -???? * cacheable attributes, and we don't have to clean to PoC when
>>> -???? * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
>>> -???? * PoU is not required either in this case.
>>> -???? */
>>> -??? if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>>> -??????? return;
>>> -
>>> -??? kvm_flush_dcache_to_poc(va, size);
>>> -}
>>> -
>>> -static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
>>> -????????????????????????? unsigned long size)
>>> -{
>>> -??? if (icache_is_aliasing()) {
>>> -??????? /* any kind of VIPT cache */
>>> -??????? __flush_icache_all();
>>> -??? } else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
>>> -??????? /* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */
>>> -??????? void *va = page_address(pfn_to_page(pfn));
>>> -
>>> -??????? invalidate_icache_range((unsigned long)va,
>>> -??????????????????? (unsigned long)va + size);
>>> -??? }
>>> -}
>>> -
>>> ? void kvm_set_way_flush(struct kvm_vcpu *vcpu);
>>> ? void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
>>> ? diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>>> index 4d177ce1d536..829a34eea526 100644
>>> --- a/arch/arm64/kvm/hyp/pgtable.c
>>> +++ b/arch/arm64/kvm/hyp/pgtable.c
>>> @@ -464,6 +464,43 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot
>>> prot,
>>> ????? return 0;
>>> ? }
>>> ? +static bool stage2_pte_cacheable(kvm_pte_t pte)
>>> +{
>>> +??? u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
>>> +??? return memattr == PAGE_S2_MEMATTR(NORMAL);
>>> +}
>>> +
>>> +static bool stage2_pte_executable(kvm_pte_t pte)
>>> +{
>>> +??? return !(pte & KVM_PTE_LEAF_ATTR_HI_S2_XN);
>>> +}
>>> +
>>> +static void stage2_flush_dcache(void *addr, u64 size)
>>> +{
>>> +??? /*
>>> +???? * With FWB, we ensure that the guest always accesses memory using
>>> +???? * cacheable attributes, and we don't have to clean to PoC when
>>> +???? * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
>>> +???? * PoU is not required either in this case.
>>> +???? */
>>> +??? if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>>> +??????? return;
>>> +
>>> +??? __flush_dcache_area(addr, size);
>>> +}
>>> +
>>> +static void stage2_invalidate_icache(void *addr, u64 size)
>>> +{
>>> +??? if (icache_is_aliasing()) {
>>> +??????? /* Flush any kind of VIPT icache */
>>> +??????? __flush_icache_all();
>>> +??? } else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
>>> +??????? /* PIPT or VPIPT at EL2 */
>>> +??????? invalidate_icache_range((unsigned long)addr,
>>> +??????????????????? (unsigned long)addr + size);
>>> +??? }
>>> +}
>>> +
>>> ? static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
>>> ??????????????????????? kvm_pte_t *ptep,
>>> ??????????????????????? struct stage2_map_data *data)
>>> @@ -495,6 +532,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end,
>>> u32 level,
>>> ????????? put_page(page);
>>> ????? }
>>> ? +??? /* Perform CMOs before installation of the new PTE */
>>> +??? if (!kvm_pte_valid(old) || stage2_pte_cacheable(old))
>> I'm not sure why the stage2_pte_cacheable(old) condition is needed.
>>
>> kvm_handle_guest_abort() handles three types of stage 2 data or instruction
>> aborts: translation faults (fault_status == FSC_FAULT), access faults
>> (fault_status == FSC_ACCESS) and permission faults (fault_status == FSC_PERM).
>>
>> Access faults are handled in handle_access_fault(), which means user_mem_abort()
>> handles translation and permission faults.
> Yes, and we are certain that it's a translation fault here in
> stage2_map_walker_try_leaf.
>> The original code did the dcache clean
>> + inval when not a permission fault, which means the CMO was done only on a
>> translation fault. Translation faults mean that the IPA was not mapped, so the old
>> entry will always be invalid. Even if we're coalescing multiple last level leaf
>> entries int oa? block mapping, the table entry which is replaced is invalid
>> because it's marked as such in stage2_map_walk_table_pre().
>>
>> Is there something I'm missing?
> I originally thought that we could possibly have a translation fault on a valid
> stage2 table
> descriptor due to some special cases, and that's the reason
> stage2_pte_cacheable(old)
> condition exits, but I can't image any scenario like this.
>
> I think your above explanation is right, maybe I should just drop that condition.
>>
>>> +??????? stage2_flush_dcache(__va(phys), granule);
>>> +
>>> +??? if (stage2_pte_executable(new))
>>> +??????? stage2_invalidate_icache(__va(phys), granule);
>> This, together with the stage2_attr_walker() changes below, look identical to the
>> current code in user_mem_abort(). The executable permission is set on an exec
>> fault (instruction abort not on a stage 2 translation table walk), and as a result
>> of the fault we either need to map a new page here, or relax permissions in
>> kvm_pgtable_stage2_relax_perms() -> stage2_attr_walker() below.
> I agree.
> Do you mean this part of change is right?

Yes, I was trying to explain that the behaviour with regard to icache invalidation
from this patch is identical to the current behaviour of user_mem_abort ()
(without this patch).

Thanks,

Alex

>
> Thanks,
> Yanan
>> Thanks,
>>
>> Alex
>>
>>> +
>>> ????? smp_store_release(ptep, new);
>>> ????? get_page(page);
>>> ????? data->phys += granule;
>>> @@ -651,20 +695,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64
>>> addr, u64 size,
>>> ????? return ret;
>>> ? }
>>> ? -static void stage2_flush_dcache(void *addr, u64 size)
>>> -{
>>> -??? if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
>>> -??????? return;
>>> -
>>> -??? __flush_dcache_area(addr, size);
>>> -}
>>> -
>>> -static bool stage2_pte_cacheable(kvm_pte_t pte)
>>> -{
>>> -??? u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
>>> -??? return memattr == PAGE_S2_MEMATTR(NORMAL);
>>> -}
>>> -
>>> ? static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
>>> ???????????????????? enum kvm_pgtable_walk_flags flag,
>>> ???????????????????? void * const arg)
>>> @@ -743,8 +773,16 @@ static int stage2_attr_walker(u64 addr, u64 end, u32
>>> level, kvm_pte_t *ptep,
>>> ?????? * but worst-case the access flag update gets lost and will be
>>> ?????? * set on the next access instead.
>>> ?????? */
>>> -??? if (data->pte != pte)
>>> +??? if (data->pte != pte) {
>>> +??????? /*
>>> +???????? * Invalidate the instruction cache before updating
>>> +???????? * if we are going to add the executable permission.
>>> +???????? */
>>> +??????? if (!stage2_pte_executable(*ptep) && stage2_pte_executable(pte))
>>> +??????????? stage2_invalidate_icache(kvm_pte_follow(pte),
>>> +???????????????????????? kvm_granule_size(level));
>>> ????????? WRITE_ONCE(*ptep, pte);
>>> +??? }
>>> ? ????? return 0;
>>> ? }
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 77cb2d28f2a4..1eec9f63bc6f 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -609,16 +609,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm
>>> *kvm,
>>> ????? kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
>>> ? }
>>> ? -static void clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
>>> -{
>>> -??? __clean_dcache_guest_page(pfn, size);
>>> -}
>>> -
>>> -static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
>>> -{
>>> -??? __invalidate_icache_guest_page(pfn, size);
>>> -}
>>> -
>>> ? static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>> ? {
>>> ????? send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>>> @@ -882,13 +872,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
>>> phys_addr_t fault_ipa,
>>> ????? if (writable)
>>> ????????? prot |= KVM_PGTABLE_PROT_W;
>>> ? -??? if (fault_status != FSC_PERM && !device)
>>> -??????? clean_dcache_guest_page(pfn, vma_pagesize);
>>> -
>>> -??? if (exec_fault) {
>>> +??? if (exec_fault)
>>> ????????? prot |= KVM_PGTABLE_PROT_X;
>>> -??????? invalidate_icache_guest_page(pfn, vma_pagesize);
>>> -??? }
>>> ? ????? if (device)
>>> ????????? prot |= KVM_PGTABLE_PROT_DEVICE;
>>> @@ -1144,10 +1129,10 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long
>>> hva, pte_t pte)
>>> ????? trace_kvm_set_spte_hva(hva);
>>> ? ????? /*
>>> -???? * We've moved a page around, probably through CoW, so let's treat it
>>> -???? * just like a translation fault and clean the cache to the PoC.
>>> +???? * We've moved a page around, probably through CoW, so let's treat
>>> +???? * it just like a translation fault and the map handler will clean
>>> +???? * the cache to the PoC.
>>> ?????? */
>>> -??? clean_dcache_guest_page(pfn, PAGE_SIZE);
>>> ????? handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
>>> ????? return 0;
>>> ? }
>> .


From robh at kernel.org  Thu Apr  8 17:00:19 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 11:00:19 -0500
Subject: [PATCH v5 4/4] dt-bindings: serial: 8250: add aspeed, lpc-io-reg
 and aspeed, lpc-interrupts
In-Reply-To: <20210408011637.5361-5-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-5-zev@bewilderbeest.net>
Message-ID: <20210408160019.GA1555403@robh.at.kernel.org>

On Wed, 07 Apr 2021 20:16:37 -0500, Zev Weiss wrote:
> These correspond to the existing lpc_address, sirq, and sirq_polarity
> sysfs attributes; the second element of aspeed,lpc-interrupts provides
> a replacement for the deprecated aspeed,sirq-polarity-sense property.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
>  1 file changed, 24 insertions(+), 3 deletions(-)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From bjorn.andersson at linaro.org  Thu Apr  8 17:06:57 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Thu, 8 Apr 2021 11:06:57 -0500
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
 <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
Message-ID: <YG8qIfFdY+As5tye@builder.lan>

On Thu 08 Apr 10:24 CDT 2021, Arnd Bergmann wrote:

> From: Arnd Bergmann <arnd at arndb.de>
> 
> On Sun, 4 Apr 2021 11:49:14 -0500, Bjorn Andersson wrote:
> > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> > 
> >   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13
> > 
> > [...]
> 
> I noticed a couple of new warnings from 'make dtbs_check W=1':
> 
> qcom/sc7180.dtsi:1204.21-1220.6: Warning (avoid_unnecessary_addr_size): /soc at 0/geniqup at ac0000/i2c at a8c000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
> qcom/sc7180.dtsi:965.21-981.6: Warning (avoid_unnecessary_addr_size): /soc at 0/geniqup at 8c0000/i2c at 890000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property qcom/sdm845.dtsi:3912.23-4045.5: Warning (simple_bus_reg): /soc at 0/camss at a00000: simple-bus unit address format error, expected "acb3000"
> qcom/sdm845.dtsi:4041.10-4044.6: Warning (graph_child_address): /soc at 0/camss at a00000/ports: graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
> qcom/sdm845.dtsi:4102.32-4129.5: Warning (simple_bus_reg): /soc at 0/dsi-opp-table: missing or empty reg/ranges property
> qcom/msm8916-samsung-a5u-eur.dt.yaml: spmi at 200f000: reg: [[33615872, 4096], [37748736, 4194304], [46137344, 4194304], [58720256, 2097152], [33595392, 8448]] is too long
> qcom/sc7180-trogdor-lazor-r0.dt.yaml: gmu at 506a000: compatible:0: 'qcom,adreno-gmu-618.0' is not one of ['qcom,adreno-gmu-630.2']
> qcom/sc7180-trogdor-lazor-r1-kb.dt.yaml: memory at 80900000: 'device_type' is a required property
> qcom/sdm850-lenovo-yoga-c630.dt.yaml: memory at 97b00000: 'device_type' is a required property
> 

I saw your other email regarding these and per Rob's request we've
ramped up our effort on cleaning these out. I've however still not
figured out a good way to incorporate the dtbs_check in my patch
handling workflow.

> Maybe see if you can address these in a follow-up, to avoid regressions.
> 

I'm about to send you a another set of pull requests with some more
goodies that was lingering on the list. I will take a look to see if I
can follow up on that with some fixes for above warnings - and take
another look at incorporating dtbs_check in my workflow.

> Merged into arm/dt, thanks!
> 

Thank you!
Bjorn

> merge commit: 61bac46eed14ad73cd41c5b7075350fef78ca4be
> 
>        Arnd


From nsaenzjulienne at suse.de  Thu Apr  8 17:16:09 2021
From: nsaenzjulienne at suse.de (Nicolas Saenz Julienne)
Date: Thu, 08 Apr 2021 18:16:09 +0200
Subject: [RFC PATCH] drivers: Raspbery Pi Sense Hat
In-Reply-To: <20210408000353.3571132-1-jsavitz@redhat.com>
References: <20210408000353.3571132-1-jsavitz@redhat.com>
Message-ID: <544611301cff5db027582f531880c41a87569116.camel@suse.de>

Hi Joel, thanks for having a look at this.

On Wed, 2021-04-07 at 20:03 -0400, Joel Savitz wrote:
> From: Joel Savitz <joelsavitz at gmail.com>
> 
> This is a forward port of the Rapsberry Pi Sense Hat driver from the
> downstream Raspberry Pi kernel tree.
> 
> I have slightly consolidated things and done some quick testing of this
> driver on Fedora (which comes with the device tree blobs), and I want to
> do a bit more testing before submiting the driver for inclusion in
> mainline Linux.
> 
> I would like to get some feedback from the community on what may need to
> be improved, fixed, or changed as early as possible, so this is a request
> for comments.
> 
> Signed-off-by: Joel Savitz <joelsavitz at gmail.com>
> ---

Some random comments:

 - Can you share more info on the HW, is this a uC on the other side? etc...
 - A driver that depends on DT should have bindings.
 - Please have a look at a modern MFD device handles things. New APIs appeared.
   See for example the 'atc260x' driver available in linux-next.
 - Try to use regmap so as not having to export functions across modules.
 - No need to explicitly schedule the interrupt in the joystick driver. New IRQ
   APIs can handle that. See devm_request_threaded_irq().
 - I don't think adding new FB drivers is possible, the whole subsystem is in
   the process of being deprecated. I believe there is an equivalent framework
   in DRM to cater for these simple FB devices.

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210408/9786aa6b/attachment.sig>

From michal.simek at xilinx.com  Thu Apr  8 17:16:53 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 8 Apr 2021 18:16:53 +0200
Subject: [PATCH v1 2/5] gpio: xilinx: Correct kernel doc for xgpio_probe()
In-Reply-To: <20210408145601.68651-3-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <20210408145601.68651-3-andriy.shevchenko@linux.intel.com>
Message-ID: <c40ae975-5e11-8873-6784-1fa4303591f9@xilinx.com>



On 4/8/21 4:55 PM, Andy Shevchenko wrote:
> Kernel doc validator complains:
> 
> .../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe(). Prototype was for xgpio_probe() instead
> 
> Correct as suggested by changing the name of the function in the doc..
> 
> Fixes: 749564ffd52d ("gpio/xilinx: Convert the driver to platform device interface")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> ---
>  drivers/gpio/gpio-xilinx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index b411d3156e0b..136557e7dd3c 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -542,7 +542,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
>  }
>  
>  /**
> - * xgpio_of_probe - Probe method for the GPIO device.
> + * xgpio_probe - Probe method for the GPIO device.
>   * @pdev: pointer to the platform device
>   *
>   * Return:
> 

Reviewed-by: Michal Simek <michal.simek at xilinx.com>

Thanks,
Michal


From robh at kernel.org  Thu Apr  8 17:20:16 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 11:20:16 -0500
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
Message-ID: <20210408162016.GA1556444@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie at kernel.org> wrote:
> >
> > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:
> >
> > > > No great problem with having these in the controller node (assming it
> > > > accurately describes the hardware) but I do think we ought to also be
> > > > able to describe these per slot.

PCIe is effectively point to point, so there's only 1 slot unless 
there's a PCIe switch in the middle. If that's the case, then it's all 
more complicated.

> > > Can you explain what you think that would look like in the DT?
> >
> > I *think* that's just some properties on the nodes for the endpoints,
> > note that the driver could just ignore them for now.  Not sure where or
> > if we document any extensions but child nodes are in section 4 of the
> > v2.1 PCI bus binding.
> 
> Hi Mark,
> 
> I'm a little confused -- here is how I remember the chronology of the
> "DT bindings" commit reviews, please correct me if I'm wrong:
> 
> o JimQ submitted a pullreq for using voltage regulators in the same
> style as the existing "rockport" PCIe driver.
> o After some deliberation, RobH preferred that the voltage regulators
> should go into the PCIe subnode device's DT node.

IIRC, that's because you said there isn't a standard slot.

> o JimQ put the voltage regulators in the subnode device's DT node.
> o MarkB didn't like the fact that the code did a global search for the
> regulator since it could not provide the owning struct device* handle.
> o RobH relented, and said that if it is just two specific and standard
> voltage regulators, perhaps they can go in the parent DT node after
> all.
> o JimQ put the regulators back in the PCIe node.
> o MarkB now wants the regulators to go back into the child node again?
> 
> Folks, please advise.
> 
> Regards,
> Jim Quinlan
> Broadcom STB


From krzysztof.kozlowski at canonical.com  Thu Apr  8 17:21:54 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 8 Apr 2021 18:21:54 +0200
Subject: [PATCH -next] clk: samsung: Remove redundant dev_err calls
In-Reply-To: <20210408134856.207305-1-clare.chenhui@huawei.com>
References: <20210408134856.207305-1-clare.chenhui@huawei.com>
Message-ID: <38c703df-2bfc-6492-ab2f-344ffc2647a1@canonical.com>

On 08/04/2021 15:48, Chen Hui wrote:
> There is error message within devm_ioremap_resource
> already, so remove the dev_err calls to avoid redundant
> error messages.
> 
> Signed-off-by: Chen Hui <clare.chenhui at huawei.com>
> ---
>  drivers/clk/samsung/clk-exynos4412-isp.c | 4 +---
>  drivers/clk/samsung/clk-s5pv210-audss.c  | 4 +---
>  2 files changed, 2 insertions(+), 6 deletions(-)


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Best regards,
Krzysztof


From pasha.tatashin at soleen.com  Thu Apr  8 17:28:42 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Thu, 8 Apr 2021 12:28:42 -0400
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <87v98wom5n.wl-maz@kernel.org>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
 <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
 <87v98wom5n.wl-maz@kernel.org>
Message-ID: <CA+CK2bB9M05UKfvu66_wMK1u_HBvRws4R0KxPgTu4vPdKuGy9w@mail.gmail.com>

> > Thank you for noticing this. Not sure how this missmerge happened. I
> > have added the missing case, and VHE is initialized correctly during
> > boot.
> > [   14.698175] kvm [1]: VHE mode initialized successfully
> >
> > During normal boot, kexec reboot, and kdump reboot. I will respin the
> > series and send the version 14 soon.
>
> Please give people a chance to review this lot first. This isn't code
> that is easy to digest, and immediate re-spinning does more harm than
> good (this isn't targeting 5.13, I would assume).
>

There are people who are testing this series, this is why I wanted to
respin. But, I will wait for review comments before sending the next
version. In the meantime I will send a fixed version of this patch as
a reply to this thread instead.

Thanks,
Pasha


From broonie at kernel.org  Thu Apr  8 17:33:45 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 17:33:45 +0100
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210408162016.GA1556444@robh.at.kernel.org>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
 <20210408162016.GA1556444@robh.at.kernel.org>
Message-ID: <20210408163345.GO4516@sirena.org.uk>

On Thu, Apr 08, 2021 at 11:20:16AM -0500, Rob Herring wrote:
> On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie at kernel.org> wrote:

> > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:

> > > > > No great problem with having these in the controller node (assming it
> > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > able to describe these per slot.

> PCIe is effectively point to point, so there's only 1 slot unless 
> there's a PCIe switch in the middle. If that's the case, then it's all 
> more complicated.

So even for PCIe that case exists, and it's not entirely clear to me
that this is all definitively PCIe specific.

> > o After some deliberation, RobH preferred that the voltage regulators
> > should go into the PCIe subnode device's DT node.

> IIRC, that's because you said there isn't a standard slot.

I recall some message in the thread that said both cases exist even with
this specific system.
-------------- 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/20210408/f822dd19/attachment.sig>

From nicolas.ferre at microchip.com  Thu Apr  8 17:34:37 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Thu, 8 Apr 2021 18:34:37 +0200
Subject: [GIT PULL] ARM: at91: dt for 5.13
In-Reply-To: <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
References: <20210407114415.13180-1-nicolas.ferre@microchip.com>
 <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
Message-ID: <71b2bd27-0d3b-3331-4f79-85b22594e20b@microchip.com>

Hi Arnd,

On 08/04/2021 at 17:24, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> On Wed, 7 Apr 2021 13:44:15 +0200, nicolas.ferre at microchip.com wrote:
>> Arnd, Olof,
>>
>> Here is first batch of dt changes for 5.13. Please pull.
>>
>> Thanks, best regards,
>>    Nicolas
>>
>> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
>>
>> [...]
> 
> Merged into arm/dt, thanks!
> 
> I saw two new warnings from 'make dtbs_check W=1':
> 
> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'
> arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm at 73C000' does not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'

Oh, got it: it's the upper case letter withing the etm hex address. I 
used this one to mach what was done in the reg property. I'm fixing both 
of them and sending the patch to the ml right now.

Tell me if I add it to a subsequent pull-request or if you prefer to 
take it the soonest in order to not generate additional warnings upstream.

BTW, I now have a dtschema at the proper level of support for running 
"make dtbs_check W=1" and will do it before sending pull-requests in the 
future.

Thanks for the heads-up. Best regards,
   Nicolas

> 
> merge commit: e2b064fec8e49112f7dac779fcec12ded40728c2
> 
>         Arnd
> 


-- 
Nicolas Ferre


From nm at ti.com  Thu Apr  8 17:34:39 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 8 Apr 2021 11:34:39 -0500
Subject: [GIT PULL] arm64: dts: TI K3 updates for v5.13
In-Reply-To: <161789493785.1630479.2066806618809349698.b4-ty@arndb.de>
References: <20210405155336.smohb7uzkperqwuz@reflex>
 <161789493785.1630479.2066806618809349698.b4-ty@arndb.de>
Message-ID: <20210408163439.x7pz7bitwmu7aenl@freckled>

On 17:24-20210408, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> On Mon, 5 Apr 2021 10:53:36 -0500, Nishanth Menon wrote:
> > Please pull the following device tree changes for v5.13 cycle.
> > 
> > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> > 
> >   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> > 
> > are available in the Git repository at:
> > 
> > [...]
> 
> Merged into arm/dt, thanks!

Thanks.
> 
> There are a couple added warnings from 'make W=1 dtbs_check' though:
> 
> ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus at f4000/interrupt-controller0: missing or empty reg/ranges property
> ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus at f4000/dmss: missing or empty reg/ranges property
> ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus at f4000/bus at 4000000/interrupt-controller1: missing or empty reg/ranges property
> 
> ti/k3-am642-evm.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]}
> ti/k3-am642-evm.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges':  'phandle': [[7]]}}
> ti/k3-am642-evm.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
> ti/k3-am642-evm.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-am642-sk.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ...
> ti/k3-am642-sk.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ...
> ti/k3-am642-sk.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
> ti/k3-am642-sk.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-j7200-common-proc-board.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> 
> 
> merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296


We have a bunch of problems with interrupt controller definitions -
attempts in [1] [2] did'nt seem to come to any form of conclusion yet.

Cdns is a convert from txt to yaml and is queued on Marks' tree[3]

These issues pre-existed in existing definitions and/or convertion
from txt and we are already working to make sure we try and reach a
conclusion soon[4]. I am guessing from your note that it is high time we
put our foot down on txt bindings and clean yamls, I will ensure we
follow up on that.


[1] https://lore.kernel.org/linux-devicetree/CAL_Jsq++DyiKG9smQGx9FAPDJnVrezcXNb0Y5uh-5_2GBzTQpQ at mail.gmail.com/#t
[2] https://lore.kernel.org/linux-arm-kernel/20210311215914.pgpz2yymmfqlainl at episode/ 
[3] https://lore.kernel.org/linux-arm-kernel/161726952255.2486.16196604421904035265.b4-ty at kernel.org/
[4] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc at finally/
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From catalin.marinas at arm.com  Thu Apr  8 17:43:27 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 8 Apr 2021 17:43:27 +0100
Subject: [PATCH] arm64/sve: Rework SVE access trap to convert state in
 registers
In-Reply-To: <20210407124806.GC5510@sirena.org.uk>
References: <20210312190313.24598-1-broonie@kernel.org>
 <20210407114511.GA21451@arm.com>
 <20210407124806.GC5510@sirena.org.uk>
Message-ID: <20210408164327.GB7676@arm.com>

On Wed, Apr 07, 2021 at 01:48:06PM +0100, Mark Brown wrote:
> On Wed, Apr 07, 2021 at 12:45:12PM +0100, Catalin Marinas wrote:
> > The other case is TIF_FOREIGN_FPSTATE being set in do_sve_acc(). Since
> > we never return to user with this flag set, when can we actually hit the
> > 'else' path in your patch?
> 
> We'd have to have been preempted between entering the kernel and
> actually handling the access trap, I can't think of a scenario where
> that would happen but it seemed easier to have the code to handle it
> than to make absolutely sure that there was no possible case that I was
> missing.  I think we should have the detection code either way in case
> it does end up happening somehow but it could be changed to use
> WARN_ON_ONCE() or something instead of silently handling it?

If we get preempted before do_sve_acc() (and that's possible as the
interrupts are enabled), if the interrupted thread wakes up on another
CPU it will have TIF_FOREIGN_FPSTATE set so that it retrieves the new
state.

So the patch looks fine to me.

-- 
Catalin


From david at redhat.com  Thu Apr  8 17:44:23 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 18:44:23 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
Message-ID: <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>

On 08.04.21 14:49, Linus Walleij wrote:
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:
> 
>>> This is something you could do using a hidden helper symbol like
>>>
>>> config DRMA_ASPEED_GFX
>>>          bool "Aspeed display driver"
>>>          select DRM_WANT_CMA
>>>
>>> config DRM_WANT_CMA
>>>          bool
>>>          help
>>>             Select this from any driver that benefits from CMA being enabled
>>>
>>> config DMA_CMA
>>>          bool "Use CMA helpers for DRM"
>>>          default DRM_WANT_CMA
>>>
>>>            Arnd
>>>
>>
>> That's precisely what I had first, with an additional "WANT_CMA" --  but
>> looking at the number of such existing options (I was able to spot 1 !)
> 
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
> 

:) I actually wanted to convert them to "depends on DMA_CMA" but ran 
into recursive dependencies ...

> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig

I was assuming these are "real" dependencies. Will it also work without 
DMA_CMA?

> 
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.

"wants" as in "desires to use but can life without" or "wants" as in 
"really needs it". ?

-- 
Thanks,

David / dhildenb



From jgg at ziepe.ca  Thu Apr  8 17:46:12 2021
From: jgg at ziepe.ca (Jason Gunthorpe)
Date: Thu, 8 Apr 2021 13:46:12 -0300
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <YG7rKfJkTDJorqvY@phenom.ffwll.local>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <YG7rKfJkTDJorqvY@phenom.ffwll.local>
Message-ID: <20210408164612.GD227011@ziepe.ca>

On Thu, Apr 08, 2021 at 01:38:17PM +0200, Daniel Vetter wrote:

> If you want to change this, we need automatic conflict resolution like apt
> and other package managers have, with suggestions how to fix the config if
> you want to enable a driver, but some of its requirements are missing. The
> current approach of hiding driver symbols complete if any of their
> dependencies are off is really not great.

+1 to this.. 

Though Kconfig is basically already unusuable unless you have hours to
carefully craft the kconfig you need to get out.

I'm not sure trying to optimize this by abusing the existing language
rules is such a good idea.

I gave a very half hearted go at a simple heuristic solution solve for
kconfig a while ago. It is good enough to sometimes automate a kconfig
task, but it is not so nice.

I use it to do things like "turn on all RDMA drivers" which is quite
a hard to do by hand.

It looks liked heursitics need a lot of fine tuning as the
conditionals are complex enough that it is hard to guess which branch
is going to yield a success.

Jason


From nicolas.ferre at microchip.com  Thu Apr  8 17:44:43 2021
From: nicolas.ferre at microchip.com (nicolas.ferre at microchip.com)
Date: Thu, 8 Apr 2021 18:44:43 +0200
Subject: [PATCH] ARM: dts: at91: sama5d2/trivial: fix letter case for etm hex
 address
In-Reply-To: <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
References: <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
Message-ID: <20210408164443.38941-1-nicolas.ferre@microchip.com>

From: Nicolas Ferre <nicolas.ferre at microchip.com>

Fix the etm node hex address to lower case for matching regexp
specification and removing the additional warning that looks like:

arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does not
match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
'pinctrl-[0-9]+'

Reported-by: Arnd Bergmann <arnd at kernel.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre at microchip.com>
---
 arch/arm/boot/dts/sama5d2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index a27294394508..801969c113d6 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -56,9 +56,9 @@ etb_in: endpoint {
 		};
 	};
 
-	etm at 73C000 {
+	etm at 73c000 {
 		compatible = "arm,coresight-etm3x", "arm,primecell";
-		reg = <0x73C000 0x1000>;
+		reg = <0x73c000 0x1000>;
 
 		clocks = <&pmc PMC_TYPE_CORE PMC_MCK>;
 		clock-names = "apb_pclk";
-- 
2.31.1



From yury.norov at gmail.com  Thu Apr  8 17:52:54 2021
From: yury.norov at gmail.com (Yury Norov)
Date: Thu, 8 Apr 2021 09:52:54 -0700
Subject: [PATCH v1 1/5] bitmap: Make bitmap_remap() and bitmap_bitremap()
 available to users
In-Reply-To: <20210408145601.68651-2-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <20210408145601.68651-2-andriy.shevchenko@linux.intel.com>
Message-ID: <20210408165254.GA1186882@yury-ThinkPad>

On Thu, Apr 08, 2021 at 05:55:57PM +0300, Andy Shevchenko wrote:
> Currently the bitmap_remap() and bitmap_bitremap() are available
> only for CONFIG_NUMA=y case, while some users may benefit out of it
> and being independent to NUMA code. Make them available to users
> by moving out of ifdeffery and exporting for modules.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> ---
>  lib/bitmap.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 74ceb02f45e3..7b6b2a67a6a6 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -784,8 +784,6 @@ int bitmap_parse(const char *start, unsigned int buflen,
>  }
>  EXPORT_SYMBOL(bitmap_parse);
>  
> -
> -#ifdef CONFIG_NUMA
>  /**
>   * bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
>   *	@buf: pointer to a bitmap
> @@ -894,6 +892,7 @@ void bitmap_remap(unsigned long *dst, const unsigned long *src,
>  			set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
>  	}
>  }
> +EXPORT_SYMBOL(bitmap_remap);
>  
>  /**
>   * bitmap_bitremap - Apply map defined by a pair of bitmaps to a single bit
> @@ -931,7 +930,9 @@ int bitmap_bitremap(int oldbit, const unsigned long *old,
>  	else
>  		return bitmap_ord_to_pos(new, n % w, bits);
>  }
> +EXPORT_SYMBOL(bitmap_bitremap);
>  
> +#ifdef CONFIG_NUMA
>  /**
>   * bitmap_onto - translate one bitmap relative to another
>   *	@dst: resulting translated bitmap
> -- 
> 2.30.2

Acked-by: Yury Norov <yury.norov at gmail.com>


From broonie at kernel.org  Thu Apr  8 17:54:31 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  8 Apr 2021 17:54:31 +0100
Subject: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
References: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
Message-ID: <161790025317.17096.4281795778439539038.b4-ty@kernel.org>

On Thu, 8 Apr 2021 17:25:59 +0800, Dinghao Liu wrote:
> When platform_get_irq() fails, a pairing PM usage counter
> increment is needed to keep the counter balanced. It's the
> same for the following error paths.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe
      commit: a21fbc42807b15b74b0891bd557063e6acf4fcae

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 Apr  8 17:54:33 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  8 Apr 2021 17:54:33 +0100
Subject: [PATCH] ARM/spi: spear: Drop PL022 num_chipselect
In-Reply-To: <20210408075045.3435046-1-linus.walleij@linaro.org>
References: <20210408075045.3435046-1-linus.walleij@linaro.org>
Message-ID: <161790025316.17096.6364777976598906991.b4-ty@kernel.org>

On Thu, 8 Apr 2021 09:50:45 +0200, Linus Walleij wrote:
> A previous refactoring moved the chip select number handling
> to the SPI core and we missed a leftover platform data user
> in the ST spear platform. The spear is not using this
> chipselect or PL022 for anything and should be using device
> tree like the rest of the platform so just delete the
> offending platform data.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] ARM/spi: spear: Drop PL022 num_chipselect
      commit: d570838efb6fb3154cbd08ab1b22d1f6442b1e78

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 Apr  8 17:54:43 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu,  8 Apr 2021 17:54:43 +0100
Subject: [PATCH] ASoC: fsl: sunxi: remove redundant dev_err call
In-Reply-To: <20210407095634.GA1379642@LEGION>
References: <20210407095634.GA1379642@LEGION>
Message-ID: <161790012549.16915.4440454202344762892.b4-ty@kernel.org>

On Wed, 7 Apr 2021 14:56:34 +0500, Muhammad Usama Anjum wrote:
> devm_ioremap_resource() prints error message in itself. Remove the
> dev_err call to avoid redundant error message.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: fsl: sunxi: remove redundant dev_err call
      commit: a93799d55fd479f540ed97066e69114aa7709787

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 jim2101024 at gmail.com  Thu Apr  8 17:58:05 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Thu, 8 Apr 2021 12:58:05 -0400
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210408162016.GA1556444@robh.at.kernel.org>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
 <20210408162016.GA1556444@robh.at.kernel.org>
Message-ID: <CANCKTBv_g9FPcBCOi-JxEDrrQWFhNcdsfDATFBydwnLiebj-HA@mail.gmail.com>

On Thu, Apr 8, 2021 at 12:20 PM Rob Herring <robh at kernel.org> wrote:
>
> On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie at kernel.org> wrote:
> > >
> > > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:
> > >
> > > > > No great problem with having these in the controller node (assming it
> > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > able to describe these per slot.
>
> PCIe is effectively point to point, so there's only 1 slot unless
> there's a PCIe switch in the middle. If that's the case, then it's all
> more complicated.
>
> > > > Can you explain what you think that would look like in the DT?
> > >
> > > I *think* that's just some properties on the nodes for the endpoints,
> > > note that the driver could just ignore them for now.  Not sure where or
> > > if we document any extensions but child nodes are in section 4 of the
> > > v2.1 PCI bus binding.
> >
> > Hi Mark,
> >
> > I'm a little confused -- here is how I remember the chronology of the
> > "DT bindings" commit reviews, please correct me if I'm wrong:
> >
> > o JimQ submitted a pullreq for using voltage regulators in the same
> > style as the existing "rockport" PCIe driver.
> > o After some deliberation, RobH preferred that the voltage regulators
> > should go into the PCIe subnode device's DT node.
>
> IIRC, that's because you said there isn't a standard slot.
Admittedly, I'm not exactly sure what you mean by a "standard slot".
Our PCIIe HW does not support  hotplug or have a presence bit or
anything like that.  Our root complex has one port; it can only
directly connect to a single switch or endpoint. This connection shows
up as slot0.  The voltage regulator(s) involved depend on a GPIO that
turns the power  on/off for the connected device/chip.  The gpio pin
can vary from board to board but this is easily handled in our DT.
Some boards have regulators that are always on and not associated with
a GPIO pin -- these have no representation in our DT.

Regards,
Jim


>
> > o JimQ put the voltage regulators in the subnode device's DT node.
> > o MarkB didn't like the fact that the code did a global search for the
> > regulator since it could not provide the owning struct device* handle.
> > o RobH relented, and said that if it is just two specific and standard
> > voltage regulators, perhaps they can go in the parent DT node after
> > all.
> > o JimQ put the regulators back in the PCIe node.
> > o MarkB now wants the regulators to go back into the child node again?
> >
> > Folks, please advise.
> >
> > Regards,
> > Jim Quinlan
> > Broadcom STB


From broonie at kernel.org  Thu Apr  8 17:58:25 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 17:58:25 +0100
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <20210405204313.21346-4-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
Message-ID: <20210408165825.GP4516@sirena.org.uk>

On Mon, Apr 05, 2021 at 03:43:12PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
> for a function, the ftrace infrastructure is called for the function at
> the very beginning. Ftrace creates two frames:

This looks good to me however I'd really like someone who has a firmer
understanding of what ftrace is doing to double check as it is entirely
likely that I am missing cases here, it seems likely that if I am
missing stuff it's extra stuff that needs to be added and we're not
actually making use of the reliability information yet.
-------------- 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/20210408/17237121/attachment.sig>

From will at kernel.org  Thu Apr  8 17:59:14 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 17:59:14 +0100
Subject: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE
In-Reply-To: <20210408131010.1109027-4-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
 <20210408131010.1109027-4-maz@kernel.org>
Message-ID: <20210408165912.GA18321@willie-the-truck>

On Thu, Apr 08, 2021 at 02:10:10PM +0100, Marc Zyngier wrote:
> CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
> and has been enabled by default for almost all that time.
> 
> Given that newer systems that are VHE capable are finally becoming
> available, and that some systems are even incapable of not running VHE,
> drop the configuration altogether.
> 
> Anyone willing to stick to non-VHE on VHE hardware for obscure
> reasons should use the 'kvm-arm.mode=nvhe' command-line option.
> 
> Suggested-by: Will Deacon <will at kernel.org>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |  3 +--
>  arch/arm64/Kconfig                            | 20 -------------------
>  arch/arm64/kernel/cpufeature.c                |  4 ----
>  arch/arm64/kernel/hyp-stub.S                  |  2 --
>  4 files changed, 1 insertion(+), 28 deletions(-)

Huh, I was really expecting to see ARM64_VHE crop up in some Makefiles, but
it doesn't seem to! So:

Acked-by: Will Deacon <will at kernel.org>

Will


From maz at kernel.org  Thu Apr  8 18:00:14 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 18:00:14 +0100
Subject: [PATCH v2 1/4] arm64: Document requirements for fine grained
 traps at boot
In-Reply-To: <20210401180942.35815-2-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
 <20210401180942.35815-2-broonie@kernel.org>
Message-ID: <87tuogogo1.wl-maz@kernel.org>

On Thu, 01 Apr 2021 19:09:39 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
> to small sets of registers and instructions from EL1 and EL0, access to
> which is controlled by EL3.  Require access to it so that it is
> available to us in future and so that we can ensure these traps are
> disabled during boot.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  Documentation/arm64/booting.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 7552dbc1cc54..92ec0bea1af5 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -270,6 +270,12 @@ Before jumping into the kernel, the following conditions must be met:
>        having 0b1 set for the corresponding bit for each of the auxiliary
>        counters present.
>  
> +  For CPUs with the Fine Grained Traps (FEAT_FGT) extension present:
> +
> +  - If EL3 is present and the kernel is entered at EL2:
> +
> +    - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
> +
>  The requirements described above for CPU mode, caches, MMUs, architected
>  timers, coherency and system registers apply to all CPUs.  All CPUs must
>  enter the kernel in the same exception level.

Acked-by: Marc Zyngier <maz at kernel.org>

	M.

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


From maz at kernel.org  Thu Apr  8 18:00:55 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 18:00:55 +0100
Subject: [PATCH v2 2/4] arm64: Disable fine grained traps on boot
In-Reply-To: <20210401180942.35815-3-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
 <20210401180942.35815-3-broonie@kernel.org>
Message-ID: <87sg40ogmw.wl-maz@kernel.org>

On Thu, 01 Apr 2021 19:09:40 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
> to small sets of registers and instructions from EL1 and EL0.  Currently
> Linux makes no use of this feature, ensure that it is not active at boot by
> disabling the traps during EL2 setup.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>

Reviewed-by: Marc Zyngier <maz at kernel.org>

	M.

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


From maz at kernel.org  Thu Apr  8 18:02:19 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 18:02:19 +0100
Subject: [PATCH v2 3/4] arm64: Require that system registers at all
 visible ELs be initialized
In-Reply-To: <20210401180942.35815-4-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
 <20210401180942.35815-4-broonie@kernel.org>
Message-ID: <87r1jkogkk.wl-maz@kernel.org>

On Thu, 01 Apr 2021 19:09:41 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> Currently we require that software at a higher exception level initialise
> all registers at the exception level the kernel will be entered prior to
> starting the kernel in order to ensure that there is nothing uninitialised
> which could result in an UNKNOWN state while running the kernel. The
> expectation is that the software running at the highest exception levels
> will be tightly coupled to the system and can ensure that all available
> features are appropriately initialised and that the kernel can initialise
> anything else.
> 
> There is a gap here in the case where new registers are added to lower
> exception levels that require initialisation but the kernel does not yet
> understand them. Extend the requirement to also include exception levels
> below the one where the kernel is entered to cover this.
> 
> Suggested-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Mark Brown <broonie at kernel.org>

Acked-by: Marc Zyngier <maz at kernel.org>

	M.

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


From will at kernel.org  Thu Apr  8 18:03:54 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 8 Apr 2021 18:03:54 +0100
Subject: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210408150612.GA37165@C02TD0UTHF1T.local>
References: <20210408143723.13024-1-vincenzo.frascino@arm.com>
 <20210408145604.GB18211@willie-the-truck>
 <20210408150612.GA37165@C02TD0UTHF1T.local>
Message-ID: <20210408170354.GB18321@willie-the-truck>

On Thu, Apr 08, 2021 at 04:06:23PM +0100, Mark Rutland wrote:
> On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> > On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > > index 9d3588450473..837d3624a1d5 100644
> > > --- a/arch/arm64/kernel/entry-common.c
> > > +++ b/arch/arm64/kernel/entry-common.c
> > > @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
> > >  	CT_WARN_ON(ct_state() != CONTEXT_USER);
> > >  	user_exit_irqoff();
> > >  	trace_hardirqs_off_finish();
> > > +
> > > +	/* Check for asynchronous tag check faults in user space */
> > > +	check_mte_async_tcf0();
> > >  }
> > 
> > Is enter_from_user_mode() always called when we enter the kernel from EL0?
> > afaict, some paths (e.g. el0_irq()) only end up calling it if
> > CONTEXT_TRACKING or TRACE_IRQFLAGS are enabled.
> 
> Currently everything that's in {enter,exit}_from_user_mode() only
> matters when either CONTEXT_TRACKING or TRACE_IRQFLAGS is selected (and
> expands to an empty stub otherwise).
> 
> We could drop the ifdeffery in user_{enter,exit}_irqoff() to have them
> called regardless, or add CONFIG_MTE to the list.

I'm always in favour of dropping ifdeffery if it's getting in the way.

> > >  asmlinkage void noinstr exit_to_user_mode(void)
> > >  {
> > > +	/* Ignore asynchronous tag check faults in the uaccess routines */
> > > +	clear_mte_async_tcf0();
> > > +
> > 
> > and this one seems to be called even less often.
> 
> This is always done in ret_to_user, so (modulo ifdeferry above) all
> returns to EL0 call this.

Right, I was just saying that if you disabled those CONFIG options then this
isn't called _at all_ whereas I think enter_from_user_mode() still is on
some paths.

Will


From maz at kernel.org  Thu Apr  8 18:16:03 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 18:16:03 +0100
Subject: [PATCH v2 4/4] arm64: Document values for system registers on boot
In-Reply-To: <20210401180942.35815-5-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
 <20210401180942.35815-5-broonie@kernel.org>
Message-ID: <87pmz4ofxo.wl-maz@kernel.org>

Hi Mark,

On Thu, 01 Apr 2021 19:09:42 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> When booting require that the system registers available at or below the
> exception level the kernel is entered be initialised but do not specify
> what values should be used in the general case, creating some potential
> for issues if the kernel does not subsequently configure those registers
> explicitly (for example if they are not yet used by the kernel) or where
> their effects may create issues during early configuration.
> 
> Specify that where the architecture provides a reset value that value
> must be used.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  Documentation/arm64/booting.rst | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 4fcc00add117..d49f568eb79d 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -205,7 +205,9 @@ Before jumping into the kernel, the following conditions must be met:
>    All writable architected system registers at or below the exception
>    level where the kernel image will be entered must be initialised by
>    software at a higher exception level to prevent execution in an UNKNOWN
> -  state.
> +  state.  Where these architected system registers have reset values
> +  specified by the architecture they must be initialised to those values
> +  unless specified more specifically.
>  
>    - SCR_EL3.FIQ must have the same value across all CPUs the kernel is
>      executing on.
> -- 
> 2.20.1
> 
> 

Is that always enforceable? Is that even desirable?

Take for example ICC_SRE_EL2.SRE. The reset value for that bit is
0. But it is extremely likely that the FW has set this bit to 1 in
order to be able to use interrupts with the sysreg interface. However,
as outlined in the GIC spec:

<quote>
If software changes this bit from 1 to 0, the results are UNPREDICTABLE.
</quote>

We could go and specify this one, but I fear there is a lot of things
we'd have to make explicit...

Thanks,

	M.

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


From broonie at kernel.org  Thu Apr  8 18:17:15 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 18:17:15 +0100
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <20210405204313.21346-2-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-2-madvenka@linux.microsoft.com>
Message-ID: <20210408171715.GQ4516@sirena.org.uk>

On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka at linux.microsoft.com wrote:

> These checks will involve checking the return PC to see if it falls inside
> any special functions where the stack trace is considered unreliable.
> Implement the infrastructure needed for this.

Following up again based on an off-list discussion with Mark Rutland:
while I think this is a reasonable implementation for specifically
listing functions that cause problems we could make life easier for
ourselves by instead using annotations at the call sites to put things
into sections which indicate that they're unsafe for unwinding, we can
then check for any address in one of those sections (or possibly do the
reverse and check for any address in a section we specifically know is
safe) rather than having to enumerate problematic functions in the
unwinder.  This also has the advantage of not having a list that's
separate to the functions themselves so it's less likely that the
unwinder will get out of sync with the rest of the code as things evolve.

We already have SYM_CODE_START() annotations in the code for assembly
functions that aren't using the standard calling convention which should
help a lot here, we could add a variant of that for things that we know
are safe on stacks (like those we expect to find at the bottom of
stacks).
-------------- 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/20210408/331347dd/attachment-0001.sig>

From maz at kernel.org  Thu Apr  8 18:24:25 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 18:24:25 +0100
Subject: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE
In-Reply-To: <20210408165912.GA18321@willie-the-truck>
References: <20210408131010.1109027-1-maz@kernel.org>
 <20210408131010.1109027-4-maz@kernel.org>
 <20210408165912.GA18321@willie-the-truck>
Message-ID: <87o8eoofjq.wl-maz@kernel.org>

On Thu, 08 Apr 2021 17:59:14 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> On Thu, Apr 08, 2021 at 02:10:10PM +0100, Marc Zyngier wrote:
> > CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
> > and has been enabled by default for almost all that time.
> > 
> > Given that newer systems that are VHE capable are finally becoming
> > available, and that some systems are even incapable of not running VHE,
> > drop the configuration altogether.
> > 
> > Anyone willing to stick to non-VHE on VHE hardware for obscure
> > reasons should use the 'kvm-arm.mode=nvhe' command-line option.
> > 
> > Suggested-by: Will Deacon <will at kernel.org>
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  .../admin-guide/kernel-parameters.txt         |  3 +--
> >  arch/arm64/Kconfig                            | 20 -------------------
> >  arch/arm64/kernel/cpufeature.c                |  4 ----
> >  arch/arm64/kernel/hyp-stub.S                  |  2 --
> >  4 files changed, 1 insertion(+), 28 deletions(-)
> 
> Huh, I was really expecting to see ARM64_VHE crop up in some Makefiles, but
> it doesn't seem to! So:

It was a design decision from the very beginning that all the VHE code
would always be compiled in to avoid bitrot. It probably helped
weeding out some early bugs.

> Acked-by: Will Deacon <will at kernel.org>

Thanks,

	M.

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


From broonie at kernel.org  Thu Apr  8 18:33:00 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 8 Apr 2021 18:33:00 +0100
Subject: [PATCH v2 4/4] arm64: Document values for system registers on boot
In-Reply-To: <87pmz4ofxo.wl-maz@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
 <20210401180942.35815-5-broonie@kernel.org>
 <87pmz4ofxo.wl-maz@kernel.org>
Message-ID: <20210408173300.GR4516@sirena.org.uk>

On Thu, Apr 08, 2021 at 06:16:03PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > Specify that where the architecture provides a reset value that value
> > must be used.

> >    level where the kernel image will be entered must be initialised by
> >    software at a higher exception level to prevent execution in an UNKNOWN
> > -  state.
> > +  state.  Where these architected system registers have reset values
> > +  specified by the architecture they must be initialised to those values
> > +  unless specified more specifically.

> Is that always enforceable? Is that even desirable?

I'm not convinced on either front frankly, like I said in the cover
letter I was worrying that it is too strict a requirement.  I couldn't
think of a better/more appropriate wording and figured it might start a
discussion.

> Take for example ICC_SRE_EL2.SRE. The reset value for that bit is
> 0. But it is extremely likely that the FW has set this bit to 1 in
> order to be able to use interrupts with the sysreg interface. However,
> as outlined in the GIC spec:

> <quote>
> If software changes this bit from 1 to 0, the results are UNPREDICTABLE.
> </quote>

That definitely means it's unenforcable without an explict override for
that case, having now seen that case I'm sure there's others.

> We could go and specify this one, but I fear there is a lot of things
> we'd have to make explicit...

Yeah, that's pushing me towards dropping this patch.  We could add a
general statement recommending that people use the defaults without
actually requiring it but that's just vague and unenforcable instead of
strict and unimplementable which isn't particularly better.  If we're
going to have to keep updating the document it's going to be less effort
all round to just update for cases we can't handle in code rather than
keep on adding exceptions and require firmware to reset lots of stuff we
don't *really* have strict requirements for.
-------------- 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/20210408/8015603d/attachment.sig>

From s.nawrocki at samsung.com  Thu Apr  8 18:37:57 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Thu, 8 Apr 2021 19:37:57 +0200
Subject: [PATCH -next] clk: samsung: Remove redundant dev_err calls
In-Reply-To: <38c703df-2bfc-6492-ab2f-344ffc2647a1@canonical.com>
References: <20210408134856.207305-1-clare.chenhui@huawei.com>
 <CGME20210408162200eucas1p2054f6241f2bad360e52ec09dd112583d@eucas1p2.samsung.com>
 <38c703df-2bfc-6492-ab2f-344ffc2647a1@canonical.com>
Message-ID: <e8ac725b-b1f5-1631-53bb-fcd0e6c44a96@samsung.com>

On 08.04.2021 18:21, Krzysztof Kozlowski wrote:
> On 08/04/2021 15:48, Chen Hui wrote:
>> There is error message within devm_ioremap_resource
>> already, so remove the dev_err calls to avoid redundant
>> error messages.
>>
>> Signed-off-by: Chen Hui <clare.chenhui at huawei.com>
>> ---
>>  drivers/clk/samsung/clk-exynos4412-isp.c | 4 +---
>>  drivers/clk/samsung/clk-s5pv210-audss.c  | 4 +---
>>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Thank you, patch applied.


From rafael at kernel.org  Thu Apr  8 18:41:10 2021
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 8 Apr 2021 19:41:10 +0200
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>

On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
>
> When the dedicated wake irq is level trigger, enable it before
> calling runtime_suspend, will trigger an interrupt.
>
> e.g.
> for a low level trigger type, it's low level at running time (0),
> and becomes high level when enters suspend (runtime_suspend (1) is
> called), a wakeup signal at (2) make it become low level, wake irq
> will be triggered.
>
>                 ------------------
>                |           ^     ^|
> ----------------           |     | --------------
>  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
>
> if we enable the wake irq before calling runtime_suspend during (0),
> an interrupt will arise, it causes resume immediately;

But that's necessary to avoid missing a wakeup interrupt, isn't it?

> enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
> will works.
>
> This patch seems no side effect on edge trigger wake irq.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/base/power/runtime.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index a46a7e30881b..796739a015a5 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>         __update_runtime_status(dev, RPM_SUSPENDING);
>
>         callback = RPM_GET_CALLBACK(dev, runtime_suspend);
> -
> -       dev_pm_enable_wake_irq_check(dev, true);
>         retval = rpm_callback(callback, dev);
>         if (retval)
>                 goto fail;
>
> +       dev_pm_enable_wake_irq_check(dev, true);
> +
>   no_callback:
>         __update_runtime_status(dev, RPM_SUSPENDED);
>         pm_runtime_deactivate_timer(dev);
> @@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>         return retval;
>
>   fail:
> -       dev_pm_disable_wake_irq_check(dev);
>         __update_runtime_status(dev, RPM_ACTIVE);
>         dev->power.deferred_resume = false;
>         wake_up_all(&dev->power.wait_queue);
> --
> 2.18.0
>


From robh at kernel.org  Thu Apr  8 18:41:42 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 12:41:42 -0500
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <20210406164708.GM6443@sirena.org.uk>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
Message-ID: <20210408174142.GB1556444@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 05:47:08PM +0100, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 05:21:42PM -0400, Jim Quinlan wrote:
> > Similar to the regulator bindings found in "rockchip-pcie-host.txt", this
> > allows optional regulators to be attached and controlled by the PCIe RC
> > driver.  That being said, this driver searches in the DT subnode (the EP
> > node, eg pci at 0,0) for the regulator property.
> 
> > The use of a regulator property in the pcie EP subnode such as
> > "vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml
> > file at
> > 
> > https://github.com/devicetree-org/dt-schema/pull/54
> > 
> > Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
> > ---
> >  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index f90557f6deb8..f2caa5b3b281 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -64,6 +64,9 @@ properties:
> >  
> >    aspm-no-l0s: true
> >  
> > +  vpcie12v-supply: true
> > +  vpcie3v3-supply: true
> > +
> 
> No great problem with having these in the controller node (assming it
> accurately describes the hardware) but I do think we ought to also be
> able to describe these per slot.

My hesistancy here is child nodes are already defined to be devices, not 
slots. That's generally the same thing though. However, 'reg' is a bit 
problematic as it includes the bus number which is dynamically 
assigned. (This is a mismatch between true OpenFirmware and FDT as OF 
was designed to populate the DT with what was discovered and that 
includes some runtime config such as bus number assignments.) Maybe we 
just say for FDT, the bus number is always 0 and ignored. In any case, 
there needs to be some thought on this as well as the more complicated 
case of devices needing device specific setup to be enumerated.

Rob


From alexandre.belloni at bootlin.com  Thu Apr  8 18:44:10 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Thu, 8 Apr 2021 19:44:10 +0200
Subject: [PATCH 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <51dbcf0b-4ee6-10c9-9598-a451cca16905@microchip.com>
References: <20210331105908.23027-1-claudiu.beznea@microchip.com>
 <20210331105908.23027-23-claudiu.beznea@microchip.com>
 <YGSc1L8yW0KniOsx@piout.net>
 <a908274a-c4d2-faab-54a4-31fd0ffeab7e@microchip.com>
 <21bd4417-a754-8ee6-370e-4fb4e0f1fef9@microchip.com>
 <51dbcf0b-4ee6-10c9-9598-a451cca16905@microchip.com>
Message-ID: <YG9A6gRAZTbUVb8+@piout.net>

On 08/04/2021 17:24:39+0200, Nicolas Ferre wrote:
> On 01/04/2021 at 12:24, Claudiu Beznea - M18063 wrote:
> > On 01.04.2021 12:38, Claudiu Beznea - M18063 wrote:
> > > On 31.03.2021 19:01, Alexandre Belloni wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > > 
> > > > On 31/03/2021 13:59:06+0300, Claudiu Beznea wrote:
> > > > > From: Eugen Hristev <eugen.hristev at microchip.com>
> > > > > 
> > > > > Introduce new family of SoCs, sama7, and first SoC, sama7g5.
> > > > > 
> > > > > Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> > > > > Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> > > > > ---
> > > > >   arch/arm/mach-at91/Makefile |  1 +
> > > > >   arch/arm/mach-at91/sama7.c  | 48 +++++++++++++++++++++++++++++++++++++
> > > > >   2 files changed, 49 insertions(+)
> > > > >   create mode 100644 arch/arm/mach-at91/sama7.c
> > > > > 
> > > > > diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> > > > > index f565490f1b70..6cc6624cddac 100644
> > > > > --- a/arch/arm/mach-at91/Makefile
> > > > > +++ b/arch/arm/mach-at91/Makefile
> > > > > @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_AT91SAM9)    += at91sam9.o
> > > > >   obj-$(CONFIG_SOC_SAM9X60)    += sam9x60.o
> > > > >   obj-$(CONFIG_SOC_SAMA5)              += sama5.o
> > > > >   obj-$(CONFIG_SOC_SAMV7)              += samv7.o
> > > > > +obj-$(CONFIG_SOC_SAMA7)              += sama7.o
> > > > > 
> > > > >   # Power Management
> > > > >   obj-$(CONFIG_ATMEL_PM)               += pm.o pm_suspend.o
> > > > > diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
> > > > > new file mode 100644
> > > > > index 000000000000..e04cadb569ad
> > > > > --- /dev/null
> > > > > +++ b/arch/arm/mach-at91/sama7.c
> > > > > @@ -0,0 +1,48 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +/*
> > > > > + * Setup code for SAMA7
> > > > > + *
> > > > > + * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
> > > > > + *
> > > > > + */
> > > > > +
> > > > > +#include <linux/of.h>
> > > > > +#include <linux/of_platform.h>
> > > > > +
> > > > > +#include <asm/mach/arch.h>
> > > > > +#include <asm/system_misc.h>
> > > > > +
> > > > > +#include "generic.h"
> > > > > +
> > > > > +static void __init sama7_common_init(void)
> > > > > +{
> > > > > +     of_platform_default_populate(NULL, NULL, NULL);
> > > > 
> > > > Is this necessary? This is left as a workaround for the old SoCs using
> > > > pinctrl-at91. I guess this will be using pio4 so this has to be removed.
> > > 
> > > OK, I'll have a look. BTW, SAMA5D2 which is also using PIO4 calls
> > > of_platform_default_populate(NULL, NULL, NULL);
> > 
> > Without this call the PM code (arch/arm/mach-at/pm.c) is not able to locate
> > proper DT nodes:
> > 
> > [    0.194615] at91_pm_backup_init: failed to find securam device!
> > [    0.201393] at91_pm_sram_init: failed to find sram device!
> > [    0.207449] AT91: PM not supported, due to no SRAM allocated
> 
> Okay, so we can't afford removing these calls to sama5d2 and upcoming
> sama7g5 right now.
> 
> Is it a common pattern to have to reach DT content in the early stages that
> explicit call to of_platform_default_populate() tries to solve?
> 

That's fine, I didn't remember about that one, we can keep the call.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From manish.narani at xilinx.com  Thu Apr  8 18:54:06 2021
From: manish.narani at xilinx.com (Manish Narani)
Date: Thu, 8 Apr 2021 23:24:06 +0530
Subject: [PATCH 0/2] Fix for a bug and a kernel-doc warning in Xilinx DWC3
Message-ID: <1617904448-74611-1-git-send-email-manish.narani@xilinx.com>

This patch series resolves a kernel-doc warning and a clk freeing bug
that was causing a crash.

This patch series is on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/dwc3?id=84770f028fabab4cb66188d583ed12652f30576b

Manish Narani (2):
  usb: dwc3: Resolve kernel-doc warning for Xilinx DWC3 driver
  usb: dwc3: xilinx: Remove the extra freeing of clocks

 drivers/usb/dwc3/dwc3-xilinx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
2.1.1



From manish.narani at xilinx.com  Thu Apr  8 18:54:07 2021
From: manish.narani at xilinx.com (Manish Narani)
Date: Thu, 8 Apr 2021 23:24:07 +0530
Subject: [PATCH 1/2] usb: dwc3: Resolve kernel-doc warning for Xilinx DWC3
 driver
In-Reply-To: <1617904448-74611-1-git-send-email-manish.narani@xilinx.com>
References: <1617904448-74611-1-git-send-email-manish.narani@xilinx.com>
Message-ID: <1617904448-74611-2-git-send-email-manish.narani@xilinx.com>

The kernel-doc run gave a warning for Xilinx DWC3 driver:

drivers/usb/dwc3/dwc3-xilinx.c:27: warning: expecting prototype for
dwc3(). Prototype was for XLNX_USB_PHY_RST_EN() instead

Basically it was due to an extra '*' in line:2. This patch fixes the same.

Signed-off-by: Manish Narani <manish.narani at xilinx.com>
Reported-by: kernel test robot <lkp at intel.com>
---
 drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index a59e149..f42f4cb 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
-/**
+/*
  * dwc3-xilinx.c - Xilinx DWC3 controller specific glue driver
  *
  * Authors: Manish Narani <manish.narani at xilinx.com>
-- 
2.1.1



From manish.narani at xilinx.com  Thu Apr  8 18:54:08 2021
From: manish.narani at xilinx.com (Manish Narani)
Date: Thu, 8 Apr 2021 23:24:08 +0530
Subject: [PATCH 2/2] usb: dwc3: xilinx: Remove the extra freeing of clocks
In-Reply-To: <1617904448-74611-1-git-send-email-manish.narani@xilinx.com>
References: <1617904448-74611-1-git-send-email-manish.narani@xilinx.com>
Message-ID: <1617904448-74611-3-git-send-email-manish.narani@xilinx.com>

The clocks are configured by devm_clk_bulk_get_all() in this driver. In
case of any error the clocks freeing will be handled automatically.
There is no need to explicitly free the clocks. Fix the same.

Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
Signed-off-by: Manish Narani <manish.narani at xilinx.com>
---
 drivers/usb/dwc3/dwc3-xilinx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index f42f4cb..9cc3ad7 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -271,7 +271,6 @@ static int dwc3_xlnx_probe(struct platform_device *pdev)
 
 err_clk_put:
 	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
-	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
 
 	return ret;
 }
@@ -284,7 +283,6 @@ static int dwc3_xlnx_remove(struct platform_device *pdev)
 	of_platform_depopulate(dev);
 
 	clk_bulk_disable_unprepare(priv_data->num_clocks, priv_data->clks);
-	clk_bulk_put_all(priv_data->num_clocks, priv_data->clks);
 	priv_data->num_clocks = 0;
 
 	pm_runtime_disable(dev);
-- 
2.1.1



From robh at kernel.org  Thu Apr  8 18:55:38 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 12:55:38 -0500
Subject: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb
 endpoint device voltage regulators
In-Reply-To: <CANCKTBv_g9FPcBCOi-JxEDrrQWFhNcdsfDATFBydwnLiebj-HA@mail.gmail.com>
References: <20210401212148.47033-1-jim2101024@gmail.com>
 <20210401212148.47033-3-jim2101024@gmail.com>
 <20210406164708.GM6443@sirena.org.uk>
 <CANCKTBsiujTkOdh60etBqF_hE8exg6m9TDxkGHVVAGVS2SFCcQ@mail.gmail.com>
 <20210406173211.GP6443@sirena.org.uk>
 <CANCKTBv63b4bGepZbDp1wmFrOeddiDikoXbheMjHhbguAbR2sA@mail.gmail.com>
 <20210408162016.GA1556444@robh.at.kernel.org>
 <CANCKTBv_g9FPcBCOi-JxEDrrQWFhNcdsfDATFBydwnLiebj-HA@mail.gmail.com>
Message-ID: <20210408175538.GA1688320@robh.at.kernel.org>

On Thu, Apr 08, 2021 at 12:58:05PM -0400, Jim Quinlan wrote:
> On Thu, Apr 8, 2021 at 12:20 PM Rob Herring <robh at kernel.org> wrote:
> >
> > On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown <broonie at kernel.org> wrote:
> > > >
> > > > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown <broonie at kernel.org> wrote:
> > > >
> > > > > > No great problem with having these in the controller node (assming it
> > > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > > able to describe these per slot.
> >
> > PCIe is effectively point to point, so there's only 1 slot unless
> > there's a PCIe switch in the middle. If that's the case, then it's all
> > more complicated.
> >
> > > > > Can you explain what you think that would look like in the DT?
> > > >
> > > > I *think* that's just some properties on the nodes for the endpoints,
> > > > note that the driver could just ignore them for now.  Not sure where or
> > > > if we document any extensions but child nodes are in section 4 of the
> > > > v2.1 PCI bus binding.
> > >
> > > Hi Mark,
> > >
> > > I'm a little confused -- here is how I remember the chronology of the
> > > "DT bindings" commit reviews, please correct me if I'm wrong:
> > >
> > > o JimQ submitted a pullreq for using voltage regulators in the same
> > > style as the existing "rockport" PCIe driver.
> > > o After some deliberation, RobH preferred that the voltage regulators
> > > should go into the PCIe subnode device's DT node.
> >
> > IIRC, that's because you said there isn't a standard slot.
> Admittedly, I'm not exactly sure what you mean by a "standard slot".
> Our PCIIe HW does not support  hotplug or have a presence bit or
> anything like that.  Our root complex has one port; it can only
> directly connect to a single switch or endpoint. This connection shows
> up as slot0.  The voltage regulator(s) involved depend on a GPIO that
> turns the power  on/off for the connected device/chip.  The gpio pin
> can vary from board to board but this is easily handled in our DT.
> Some boards have regulators that are always on and not associated with
> a GPIO pin -- these have no representation in our DT.

By standard slot, I mean you have standard voltage rails 12V and 3.3V 
(or 1.5 and 3.3 for mini PCIe) and PERST# signal, no other extra 
things to make a device discoverable, and the timing for 
those rails and PERST# follow what the spec defines.

There's also CLKREQ, WAKE, and hotplug detect signals, but I think those 
are all optional and could be tied off. I think most PCI h/w is not 
hotplug capable.

Rob


From catalin.marinas at arm.com  Thu Apr  8 18:59:46 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  8 Apr 2021 18:59:46 +0100
Subject: (subset) [PATCH v2 0/4] arm64: Booting clarifications and fine
 grained traps setup
In-Reply-To: <20210401180942.35815-1-broonie@kernel.org>
References: <20210401180942.35815-1-broonie@kernel.org>
Message-ID: <161790477698.12021.16767223295653028174.b4-ty@arm.com>

On Thu, 1 Apr 2021 19:09:38 +0100, Mark Brown wrote:
> Currently there are a number of areas where we are not explicit about
> how system registers should be configured when booting the kernel,
> provide more detailed guidance to help ensure people get things right.
> I'm not entirely happy with the wording on use of specified reset values
> so it is a separate patch at the end, I worry that the requirement is
> too strict.
> 
> [...]

Applied to arm64 (for-next/fgt-boot-init), thanks!

[1/4] arm64: Document requirements for fine grained traps at boot
      https://git.kernel.org/arm64/c/3e237387bb76
[2/4] arm64: Disable fine grained traps on boot
      https://git.kernel.org/arm64/c/31c00d2aeaa2
[3/4] arm64: Require that system registers at all visible ELs be initialized
      https://git.kernel.org/arm64/c/230800cd315c

-- 
Catalin



From catalin.marinas at arm.com  Thu Apr  8 19:00:01 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  8 Apr 2021 19:00:01 +0100
Subject: [PATCH] arm64/sve: Rework SVE access trap to convert state in
 registers
In-Reply-To: <20210312190313.24598-1-broonie@kernel.org>
References: <20210312190313.24598-1-broonie@kernel.org>
Message-ID: <161790479237.12189.6781606675801945218.b4-ty@arm.com>

On Fri, 12 Mar 2021 19:03:13 +0000, Mark Brown wrote:
> When we enable SVE usage in userspace after taking a SVE access trap we
> need to ensure that the portions of the register state that are not
> shared with the FPSIMD registers are zeroed. Currently we do this by
> forcing the FPSIMD registers to be saved to the task struct and converting
> them there. This is wasteful in the common case where the task state is
> loaded into the registers and we will immediately return to userspace
> since we can initialise the SVE state directly in registers instead of
> accessing multiple copies of the register state in memory.
> 
> [...]

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64/sve: Rework SVE access trap to convert state in registers
      https://git.kernel.org/arm64/c/cccb78ce89c4

-- 
Catalin



From catalin.marinas at arm.com  Thu Apr  8 19:00:10 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  8 Apr 2021 19:00:10 +0100
Subject: [PATCH v2] arm64: Add __init section marker to some functions
In-Reply-To: <20210330135449.4dcffd7f@xhacker.debian>
References: <20210330135449.4dcffd7f@xhacker.debian>
Message-ID: <161790479237.12189.15625395810024773914.b4-ty@arm.com>

On Tue, 30 Mar 2021 13:54:49 +0800, Jisheng Zhang wrote:
> They are not needed after booting, so mark them as __init to move them
> to the .init section.

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64: Add __init section marker to some functions
      https://git.kernel.org/arm64/c/a7dcf58ae5d2

-- 
Catalin



From catalin.marinas at arm.com  Thu Apr  8 19:00:21 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  8 Apr 2021 19:00:21 +0100
Subject: [PATCH] arm64: mte: Remove unused mte_assign_mem_tag_range()
In-Reply-To: <20210407133817.23053-1-vincenzo.frascino@arm.com>
References: <20210407133817.23053-1-vincenzo.frascino@arm.com>
Message-ID: <161790479237.12189.16889750597145288261.b4-ty@arm.com>

On Wed, 7 Apr 2021 14:38:17 +0100, Vincenzo Frascino wrote:
> mte_assign_mem_tag_range() was added in commit 85f49cae4dfc
> ("arm64: mte: add in-kernel MTE helpers") in 5.11 but moved out of
> mte.S by commit 2cb34276427a ("arm64: kasan: simplify and inline
> MTE functions") in 5.12 and renamed to mte_set_mem_tag_range().
> 2cb34276427a did not delete the old function prototypes in mte.h.
> 
> Remove the unused prototype from mte.h.

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64: mte: Remove unused mte_assign_mem_tag_range()
      https://git.kernel.org/arm64/c/df652a16a657

-- 
Catalin



From catalin.marinas at arm.com  Thu Apr  8 19:00:34 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu,  8 Apr 2021 19:00:34 +0100
Subject: [PATCH v3 0/3] arm64: Dealing with VHE-only CPUs
In-Reply-To: <20210408131010.1109027-1-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
Message-ID: <161790482835.12515.10609657000878058204.b4-ty@arm.com>

On Thu, 8 Apr 2021 14:10:07 +0100, Marc Zyngier wrote:
> This short series is a rewrite of [0] after some reviewing from
> Will. It simplifies the esoteric "stay at EL2" path, and move the
> feature override code where it actually belongs, allowing us to tell
> the user that no, nVHE isn't a thing on these system.
> 
> The last patch rids us of CONFIG_ARM64_VHE, which has been the default
> for longer than I can remember.
> 
> [...]

Applied to arm64 (for-next/vhe-only), thanks!

[1/3] arm64: cpufeature: Allow early filtering of feature override
      https://git.kernel.org/arm64/c/cac642c12a80
[2/3] arm64: Cope with CPUs stuck in VHE mode
      https://git.kernel.org/arm64/c/31a32b49b80f
[3/3] arm64: Get rid of CONFIG_ARM64_VHE
      https://git.kernel.org/arm64/c/2d726d0db6ac

-- 
Catalin



From maz at kernel.org  Thu Apr  8 19:08:18 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 08 Apr 2021 19:08:18 +0100
Subject: [PATCH v3 0/3] arm64: Dealing with VHE-only CPUs
In-Reply-To: <161790482835.12515.10609657000878058204.b4-ty@arm.com>
References: <20210408131010.1109027-1-maz@kernel.org>
 <161790482835.12515.10609657000878058204.b4-ty@arm.com>
Message-ID: <b66950afb25d795046fb67177f566dad@kernel.org>

On 2021-04-08 19:00, Catalin Marinas wrote:
> On Thu, 8 Apr 2021 14:10:07 +0100, Marc Zyngier wrote:
>> This short series is a rewrite of [0] after some reviewing from
>> Will. It simplifies the esoteric "stay at EL2" path, and move the
>> feature override code where it actually belongs, allowing us to tell
>> the user that no, nVHE isn't a thing on these system.
>> 
>> The last patch rids us of CONFIG_ARM64_VHE, which has been the default
>> for longer than I can remember.
>> 
>> [...]
> 
> Applied to arm64 (for-next/vhe-only), thanks!
> 
> [1/3] arm64: cpufeature: Allow early filtering of feature override
>       https://git.kernel.org/arm64/c/cac642c12a80
> [2/3] arm64: Cope with CPUs stuck in VHE mode
>       https://git.kernel.org/arm64/c/31a32b49b80f
> [3/3] arm64: Get rid of CONFIG_ARM64_VHE
>       https://git.kernel.org/arm64/c/2d726d0db6ac

Thanks Catalin.

In order to avoid conflicts with my SVE branch, I've taken this branch
into the kvmarm tree.

Please let me know if you decide to drop it for any reason, and I'll do
the same on my side.

Cheers,

         M.
-- 
Jazz is not dead. It just smells funny...


From david at redhat.com  Thu Apr  8 19:16:17 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 8 Apr 2021 20:16:17 +0200
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210408141853.GA7676@arm.com>
References: <e0b88560-34e1-dcc4-aaa7-9a7a5b771824@arm.com>
 <20210330103013.GD18075@arm.com>
 <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
 <20210407151458.GC21451@arm.com>
 <5e5bf772-1e4d-ca59-a9d8-058a72dfad4f@arm.com>
 <20210408141853.GA7676@arm.com>
Message-ID: <bfcd1c41-92fb-d4ee-34b1-7beb6b6c9fd8@redhat.com>

On 08.04.21 16:18, Catalin Marinas wrote:
> On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
>> On 07/04/2021 16:14, Catalin Marinas wrote:
>>> On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
>>>> On 31/03/2021 19:43, Catalin Marinas wrote:
>>>>> When a slot is added by the VMM, if it asked for MTE in guest (I guess
>>>>> that's an opt-in by the VMM, haven't checked the other patches), can we
>>>>> reject it if it's is going to be mapped as Normal Cacheable but it is a
>>>>> ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
>>>>> check for ZONE_DEVICE)? This way we don't need to do more expensive
>>>>> checks in set_pte_at().
>>>>
>>>> The problem is that KVM allows the VMM to change the memory backing a slot
>>>> while the guest is running. This is obviously useful for the likes of
>>>> migration, but ultimately means that even if you were to do checks at the
>>>> time of slot creation, you would need to repeat the checks at set_pte_at()
>>>> time to ensure a mischievous VMM didn't swap the page for a problematic one.
>>>
>>> Does changing the slot require some KVM API call? Can we intercept it
>>> and do the checks there?
>>
>> As David has already replied - KVM uses MMU notifiers, so there's not really
>> a good place to intercept this before the fault.
>>
>>> Maybe a better alternative for the time being is to add a new
>>> kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns
>>> true _and_ the VMM asked for MTE in guest. We can then only set
>>> PG_mte_tagged if !device.
>>
>> KVM already has a kvm_is_device_pfn(), and yes I agree restricting the MTE
>> checks to only !kvm_is_device_pfn() makes sense (I have the fix in my branch
>> locally).
> 
> Indeed, you can skip it if kvm_is_device_pfn(). In addition, with MTE,
> I'd also mark a pfn as 'device' in user_mem_abort() if
> pfn_to_online_page() is NULL as we don't want to map it as Cacheable in
> Stage 2. It's unlikely that we'll trip over this path but just in case.
> 
> (can we have a ZONE_DEVICE _online_ pfn or by definition they are
> considered offline?)

By definition (and implementation) offline. When you get a page = 
pfn_to_online_page() with page != NULL, that one should never be 
ZONE_DEVICE (otherwise it would be a BUG).

As I said, things are different when exposing dax memory via dax/kmem to 
the buddy. But then, we are no longer talking about ZONE_DEVICE.

-- 
Thanks,

David / dhildenb



From catalin.marinas at arm.com  Thu Apr  8 19:21:12 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 8 Apr 2021 19:21:12 +0100
Subject: [PATCH v10 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <bfcd1c41-92fb-d4ee-34b1-7beb6b6c9fd8@redhat.com>
References: <8977120b-841d-4882-2472-6e403bc9c797@redhat.com>
 <20210331092109.GA21921@arm.com>
 <d545a051-a02a-4c3a-0afe-66612839ba32@redhat.com>
 <86a968c8-7a0e-44a4-28c3-bac62c2b7d65@arm.com>
 <20210331184311.GA10737@arm.com>
 <e2612bd8-b356-a9cd-cfdf-26f4aa813578@arm.com>
 <20210407151458.GC21451@arm.com>
 <5e5bf772-1e4d-ca59-a9d8-058a72dfad4f@arm.com>
 <20210408141853.GA7676@arm.com>
 <bfcd1c41-92fb-d4ee-34b1-7beb6b6c9fd8@redhat.com>
Message-ID: <20210408182112.GC7676@arm.com>

On Thu, Apr 08, 2021 at 08:16:17PM +0200, David Hildenbrand wrote:
> On 08.04.21 16:18, Catalin Marinas wrote:
> > On Wed, Apr 07, 2021 at 04:52:54PM +0100, Steven Price wrote:
> > > On 07/04/2021 16:14, Catalin Marinas wrote:
> > > > On Wed, Apr 07, 2021 at 11:20:18AM +0100, Steven Price wrote:
> > > > > On 31/03/2021 19:43, Catalin Marinas wrote:
> > > > > > When a slot is added by the VMM, if it asked for MTE in guest (I guess
> > > > > > that's an opt-in by the VMM, haven't checked the other patches), can we
> > > > > > reject it if it's is going to be mapped as Normal Cacheable but it is a
> > > > > > ZONE_DEVICE (i.e. !kvm_is_device_pfn() + one of David's suggestions to
> > > > > > check for ZONE_DEVICE)? This way we don't need to do more expensive
> > > > > > checks in set_pte_at().
> > > > > 
> > > > > The problem is that KVM allows the VMM to change the memory backing a slot
> > > > > while the guest is running. This is obviously useful for the likes of
> > > > > migration, but ultimately means that even if you were to do checks at the
> > > > > time of slot creation, you would need to repeat the checks at set_pte_at()
> > > > > time to ensure a mischievous VMM didn't swap the page for a problematic one.
> > > > 
> > > > Does changing the slot require some KVM API call? Can we intercept it
> > > > and do the checks there?
> > > 
> > > As David has already replied - KVM uses MMU notifiers, so there's not really
> > > a good place to intercept this before the fault.
> > > 
> > > > Maybe a better alternative for the time being is to add a new
> > > > kvm_is_zone_device_pfn() and force KVM_PGTABLE_PROT_DEVICE if it returns
> > > > true _and_ the VMM asked for MTE in guest. We can then only set
> > > > PG_mte_tagged if !device.
> > > 
> > > KVM already has a kvm_is_device_pfn(), and yes I agree restricting the MTE
> > > checks to only !kvm_is_device_pfn() makes sense (I have the fix in my branch
> > > locally).
> > 
> > Indeed, you can skip it if kvm_is_device_pfn(). In addition, with MTE,
> > I'd also mark a pfn as 'device' in user_mem_abort() if
> > pfn_to_online_page() is NULL as we don't want to map it as Cacheable in
> > Stage 2. It's unlikely that we'll trip over this path but just in case.
> > 
> > (can we have a ZONE_DEVICE _online_ pfn or by definition they are
> > considered offline?)
> 
> By definition (and implementation) offline. When you get a page =
> pfn_to_online_page() with page != NULL, that one should never be ZONE_DEVICE
> (otherwise it would be a BUG).
> 
> As I said, things are different when exposing dax memory via dax/kmem to the
> buddy. But then, we are no longer talking about ZONE_DEVICE.

Thanks David, it's clear now.

-- 
Catalin


From samitolvanen at google.com  Thu Apr  8 19:28:25 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:25 -0700
Subject: [PATCH v6 00/18] Add support for Clang CFI
Message-ID: <20210408182843.1754385-1-samitolvanen@google.com>

This series adds support for Clang's Control-Flow Integrity (CFI)
checking. With CFI, the compiler injects a runtime check before 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. For more details, see:

  https://clang.llvm.org/docs/ControlFlowIntegrity.html

The first patch contains build system changes and error handling,
and implements support for cross-module indirect call checking. The
remaining patches address issues caused by the compiler
instrumentation. These include fixing known type mismatches, as well
as issues with address space confusion and cross-module function
address equality.

These patches add support only for arm64, but I'll post patches also
for x86_64 after we address the remaining issues there, including
objtool support.

You can also pull this series from

  https://github.com/samitolvanen/linux.git cfi-v6

---
Changes in v6:
 - Added temporary variables and moved assembly constraints to a
   separate line based on Mark's suggestions.

Changes in v5:
 - Changed module.lds.S to only include <asm/page.h> when CFI is
   enabled to fix the MIPS build.
 - Added a patch that fixes dynamic ftrace with CFI on arm64.

Changes in v4:
 - Per Mark's suggestion, dropped __pa_function() and renamed
   __va_function() to function_nocfi().
 - Added a comment to function_nocfi() to explain what it does.
 - Updated the psci patch to use an intermediate variable for
   the physical address for clarity.

Changes in v3:
 - Added a patch to change list_sort() callers treewide to use
   const pointers instead of simply removing the internal casts.
 - Changed cleanup_symbol_name() to return bool.
 - Changed module.lds.S to drop the .eh_frame section only with
   CONFIG_CFI_CLANG.
 - Switched to synchronize_rcu() in update_shadow().

Changes in v2:
 - Fixed .text merging in module.lds.S.
 - Added WARN_ON_FUNCTION_MISMATCH() and changed kernel/thread.c
   and kernel/workqueue.c to use the macro instead.


Sami Tolvanen (18):
  add support for Clang CFI
  cfi: add __cficanonical
  mm: add generic function_nocfi macro
  module: ensure __cfi_check alignment
  workqueue: use WARN_ON_FUNCTION_MISMATCH
  kthread: use WARN_ON_FUNCTION_MISMATCH
  kallsyms: strip ThinLTO hashes from static functions
  bpf: disable CFI in dispatcher functions
  treewide: Change list_sort to use const pointers
  lkdtm: use function_nocfi
  psci: use function_nocfi for cpu_resume
  arm64: implement function_nocfi
  arm64: use function_nocfi with __pa_symbol
  arm64: add __nocfi to functions that jump to a physical address
  arm64: add __nocfi to __apply_alternatives
  arm64: ftrace: use function_nocfi for ftrace_call
  KVM: arm64: Disable CFI for nVHE
  arm64: allow CONFIG_CFI_CLANG to be selected

 Makefile                                      |  17 +
 arch/Kconfig                                  |  45 +++
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/memory.h               |  16 +
 arch/arm64/include/asm/mmu_context.h          |   4 +-
 arch/arm64/kernel/acpi_parking_protocol.c     |   3 +-
 arch/arm64/kernel/alternative.c               |   4 +-
 arch/arm64/kernel/cpu-reset.h                 |  10 +-
 arch/arm64/kernel/cpufeature.c                |   4 +-
 arch/arm64/kernel/ftrace.c                    |   2 +-
 arch/arm64/kernel/psci.c                      |   3 +-
 arch/arm64/kernel/smp_spin_table.c            |   3 +-
 arch/arm64/kvm/hyp/nvhe/Makefile              |   6 +-
 arch/arm64/kvm/vgic/vgic-its.c                |   8 +-
 arch/arm64/kvm/vgic/vgic.c                    |   3 +-
 block/blk-mq-sched.c                          |   3 +-
 block/blk-mq.c                                |   3 +-
 drivers/acpi/nfit/core.c                      |   3 +-
 drivers/acpi/numa/hmat.c                      |   3 +-
 drivers/clk/keystone/sci-clk.c                |   4 +-
 drivers/firmware/psci/psci.c                  |   7 +-
 drivers/gpu/drm/drm_modes.c                   |   3 +-
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |   3 +-
 drivers/gpu/drm/i915/gvt/debugfs.c            |   2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |   3 +-
 drivers/gpu/drm/radeon/radeon_cs.c            |   4 +-
 .../hw/usnic/usnic_uiom_interval_tree.c       |   3 +-
 drivers/interconnect/qcom/bcm-voter.c         |   2 +-
 drivers/md/raid5.c                            |   3 +-
 drivers/misc/lkdtm/usercopy.c                 |   2 +-
 drivers/misc/sram.c                           |   4 +-
 drivers/nvme/host/core.c                      |   3 +-
 .../controller/cadence/pcie-cadence-host.c    |   3 +-
 drivers/spi/spi-loopback-test.c               |   3 +-
 fs/btrfs/raid56.c                             |   3 +-
 fs/btrfs/tree-log.c                           |   3 +-
 fs/btrfs/volumes.c                            |   3 +-
 fs/ext4/fsmap.c                               |   4 +-
 fs/gfs2/glock.c                               |   3 +-
 fs/gfs2/log.c                                 |   2 +-
 fs/gfs2/lops.c                                |   3 +-
 fs/iomap/buffered-io.c                        |   3 +-
 fs/ubifs/gc.c                                 |   7 +-
 fs/ubifs/replay.c                             |   4 +-
 fs/xfs/scrub/bitmap.c                         |   4 +-
 fs/xfs/xfs_bmap_item.c                        |   4 +-
 fs/xfs/xfs_buf.c                              |   6 +-
 fs/xfs/xfs_extent_busy.c                      |   4 +-
 fs/xfs/xfs_extent_busy.h                      |   3 +-
 fs/xfs/xfs_extfree_item.c                     |   4 +-
 fs/xfs/xfs_refcount_item.c                    |   4 +-
 fs/xfs/xfs_rmap_item.c                        |   4 +-
 include/asm-generic/bug.h                     |  16 +
 include/asm-generic/vmlinux.lds.h             |  20 +-
 include/linux/bpf.h                           |   4 +-
 include/linux/cfi.h                           |  41 +++
 include/linux/compiler-clang.h                |   3 +
 include/linux/compiler_types.h                |   8 +
 include/linux/init.h                          |   6 +-
 include/linux/list_sort.h                     |   7 +-
 include/linux/mm.h                            |  10 +
 include/linux/module.h                        |  13 +-
 include/linux/pci.h                           |   4 +-
 init/Kconfig                                  |   2 +-
 kernel/Makefile                               |   4 +
 kernel/cfi.c                                  | 329 ++++++++++++++++++
 kernel/kallsyms.c                             |  55 ++-
 kernel/kthread.c                              |   3 +-
 kernel/module.c                               |  43 +++
 kernel/workqueue.c                            |   2 +-
 lib/list_sort.c                               |  17 +-
 lib/test_list_sort.c                          |   3 +-
 net/tipc/name_table.c                         |   4 +-
 scripts/Makefile.modfinal                     |   2 +-
 scripts/module.lds.S                          |  19 +-
 75 files changed, 760 insertions(+), 113 deletions(-)
 create mode 100644 include/linux/cfi.h
 create mode 100644 kernel/cfi.c


base-commit: e0a472fffe435af52ea4e21e1e0001c5c8ffc6c7
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:26 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:26 -0700
Subject: [PATCH v6 01/18] add support for Clang CFI
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-2-samitolvanen@google.com>

This change adds support for Clang?s forward-edge Control Flow
Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
injects a runtime check before 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. For more details, see:

  https://clang.llvm.org/docs/ControlFlowIntegrity.html

Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
visibility to possible call targets. Kernel modules are supported
with Clang?s cross-DSO CFI mode, which allows checking between
independently compiled components.

With CFI enabled, the compiler injects a __cfi_check() function into
the kernel and each module for validating local call targets. For
cross-module calls that cannot be validated locally, the compiler
calls the global __cfi_slowpath_diag() function, which determines
the target module and calls the correct __cfi_check() function. This
patch includes a slowpath implementation that uses __module_address()
to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
shadow map that speeds up module look-ups by ~3x.

Clang implements indirect call checking using jump tables and
offers two methods of generating them. With canonical jump tables,
the compiler renames each address-taken function to <function>.cfi
and points the original symbol to a jump table entry, which passes
__cfi_check() validation. This isn?t compatible with stand-alone
assembly code, which the compiler doesn?t instrument, and would
result in indirect calls to assembly code to fail. Therefore, we
default to using non-canonical jump tables instead, where the compiler
generates a local jump table entry <function>.cfi_jt for each
address-taken function, and replaces all references to the function
with the address of the jump table entry.

Note that because non-canonical jump table addresses are local
to each component, they break cross-module function address
equality. Specifically, the address of a global function will be
different in each module, as it's replaced with the address of a local
jump table entry. If this address is passed to a different module,
it won?t match the address of the same function taken there. This
may break code that relies on comparing addresses passed from other
components.

CFI checking can be disabled in a function with the __nocfi attribute.
Additionally, CFI can be disabled for an entire compilation unit by
filtering out CC_FLAGS_CFI.

By default, CFI failures result in a kernel panic to stop a potential
exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
kernel prints out a rate-limited warning instead, and allows execution
to continue. This option is helpful for locating type mismatches, but
should only be enabled during development.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 Makefile                          |  17 ++
 arch/Kconfig                      |  45 ++++
 include/asm-generic/bug.h         |  16 ++
 include/asm-generic/vmlinux.lds.h |  20 +-
 include/linux/cfi.h               |  41 ++++
 include/linux/compiler-clang.h    |   2 +
 include/linux/compiler_types.h    |   4 +
 include/linux/init.h              |   2 +-
 include/linux/module.h            |  13 +-
 init/Kconfig                      |   2 +-
 kernel/Makefile                   |   4 +
 kernel/cfi.c                      | 329 ++++++++++++++++++++++++++++++
 kernel/module.c                   |  43 ++++
 scripts/Makefile.modfinal         |   2 +-
 14 files changed, 534 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/cfi.h
 create mode 100644 kernel/cfi.c

diff --git a/Makefile b/Makefile
index cc77fd45ca64..427f75249d5e 100644
--- a/Makefile
+++ b/Makefile
@@ -920,6 +920,23 @@ KBUILD_AFLAGS	+= -fno-lto
 export CC_FLAGS_LTO
 endif
 
+ifdef CONFIG_CFI_CLANG
+CC_FLAGS_CFI	:= -fsanitize=cfi \
+		   -fsanitize-cfi-cross-dso \
+		   -fno-sanitize-cfi-canonical-jump-tables \
+		   -fno-sanitize-trap=cfi \
+		   -fno-sanitize-blacklist
+
+ifdef CONFIG_CFI_PERMISSIVE
+CC_FLAGS_CFI	+= -fsanitize-recover=cfi
+endif
+
+# If LTO flags are filtered out, we must also filter out CFI.
+CC_FLAGS_LTO	+= $(CC_FLAGS_CFI)
+KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
+export CC_FLAGS_CFI
+endif
+
 ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_32B
 KBUILD_CFLAGS += -falign-functions=32
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index ecfd3520b676..f6a85ba6cba2 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -692,6 +692,51 @@ config LTO_CLANG_THIN
 	  If unsure, say Y.
 endchoice
 
+config ARCH_SUPPORTS_CFI_CLANG
+	bool
+	help
+	  An architecture should select this option if it can support Clang's
+	  Control-Flow Integrity (CFI) checking.
+
+config CFI_CLANG
+	bool "Use Clang's Control Flow Integrity (CFI)"
+	depends on LTO_CLANG && ARCH_SUPPORTS_CFI_CLANG
+	# Clang >= 12:
+	# - https://bugs.llvm.org/show_bug.cgi?id=46258
+	# - https://bugs.llvm.org/show_bug.cgi?id=47479
+	depends on CLANG_VERSION >= 120000
+	select KALLSYMS
+	help
+	  This option enables Clang?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 Clang's documentation:
+
+	    https://clang.llvm.org/docs/ControlFlowIntegrity.html
+
+config CFI_CLANG_SHADOW
+	bool "Use CFI shadow to speed up cross-module checks"
+	default y
+	depends on CFI_CLANG && MODULES
+	help
+	  If you select this option, the kernel builds a fast look-up table of
+	  CFI check functions in loaded modules to reduce performance overhead.
+
+	  If unsure, say Y.
+
+config CFI_PERMISSIVE
+	bool "Use CFI in permissive mode"
+	depends on CFI_CLANG
+	help
+	  When selected, Control Flow Integrity (CFI) violations result in a
+	  warning instead of a kernel panic. This option should only be used
+	  for finding indirect call type mismatches during development.
+
+	  If unsure, say N.
+
 config HAVE_ARCH_WITHIN_STACK_FRAMES
 	bool
 	help
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 76a10e0dca9f..b402494883b6 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -241,6 +241,22 @@ void __warn(const char *file, int line, void *caller, unsigned taint,
 # define WARN_ON_SMP(x)			({0;})
 #endif
 
+/*
+ * WARN_ON_FUNCTION_MISMATCH() warns if a value doesn't match a
+ * function address, and can be useful for catching issues with
+ * callback functions, for example.
+ *
+ * With CONFIG_CFI_CLANG, the warning is disabled because the
+ * compiler replaces function addresses taken in C code with
+ * local jump table addresses, which breaks cross-module function
+ * address equality.
+ */
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_MODULES)
+# define WARN_ON_FUNCTION_MISMATCH(x, fn) ({ 0; })
+#else
+# define WARN_ON_FUNCTION_MISMATCH(x, fn) WARN_ON_ONCE((x) != (fn))
+#endif
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 0331d5d49551..40a9c101565e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -544,6 +544,22 @@
 	. = ALIGN((align));						\
 	__end_rodata = .;
 
+
+/*
+ * .text..L.cfi.jumptable.* contain Control-Flow Integrity (CFI)
+ * jump table entries.
+ */
+#ifdef CONFIG_CFI_CLANG
+#define TEXT_CFI_JT							\
+		. = ALIGN(PMD_SIZE);					\
+		__cfi_jt_start = .;					\
+		*(.text..L.cfi.jumptable .text..L.cfi.jumptable.*)	\
+		. = ALIGN(PMD_SIZE);					\
+		__cfi_jt_end = .;
+#else
+#define TEXT_CFI_JT
+#endif
+
 /*
  * Non-instrumentable text section
  */
@@ -570,6 +586,7 @@
 		NOINSTR_TEXT						\
 		*(.text..refcount)					\
 		*(.ref.text)						\
+		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 
@@ -974,7 +991,8 @@
  * keep any .init_array.* sections.
  * https://bugs.llvm.org/show_bug.cgi?id=46478
  */
-#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
+#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN) || \
+	defined(CONFIG_CFI_CLANG)
 # ifdef CONFIG_CONSTRUCTORS
 #  define SANITIZER_DISCARDS						\
 	*(.eh_frame)
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
new file mode 100644
index 000000000000..879744aaa6e0
--- /dev/null
+++ b/include/linux/cfi.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Clang Control Flow Integrity (CFI) support.
+ *
+ * Copyright (C) 2021 Google LLC
+ */
+#ifndef _LINUX_CFI_H
+#define _LINUX_CFI_H
+
+#ifdef CONFIG_CFI_CLANG
+typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
+
+/* Compiler-generated function in each module, and the kernel */
+extern void __cfi_check(uint64_t id, void *ptr, void *diag);
+
+/*
+ * Force the compiler to generate a CFI jump table entry for a function
+ * and store the jump table address to __cfi_jt_<function>.
+ */
+#define __CFI_ADDRESSABLE(fn, __attr) \
+	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
+
+#ifdef CONFIG_CFI_CLANG_SHADOW
+
+extern void cfi_module_add(struct module *mod, unsigned long base_addr);
+extern void cfi_module_remove(struct module *mod, unsigned long base_addr);
+
+#else
+
+static inline void cfi_module_add(struct module *mod, unsigned long base_addr) {}
+static inline void cfi_module_remove(struct module *mod, unsigned long base_addr) {}
+
+#endif /* CONFIG_CFI_CLANG_SHADOW */
+
+#else /* !CONFIG_CFI_CLANG */
+
+#define __CFI_ADDRESSABLE(fn, __attr)
+
+#endif /* CONFIG_CFI_CLANG */
+
+#endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index d217c382b02d..6de9d0c9377e 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -61,3 +61,5 @@
 #if __has_feature(shadow_call_stack)
 # define __noscs	__attribute__((__no_sanitize__("shadow-call-stack")))
 #endif
+
+#define __nocfi		__attribute__((__no_sanitize__("cfi")))
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index e5dd5a4ae946..796935a37e37 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -242,6 +242,10 @@ struct ftrace_likely_data {
 # define __noscs
 #endif
 
+#ifndef __nocfi
+# define __nocfi
+#endif
+
 #ifndef asm_volatile_goto
 #define asm_volatile_goto(x...) asm goto(x)
 #endif
diff --git a/include/linux/init.h b/include/linux/init.h
index 31f54de58429..b3ea15348fbd 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
 
 /* These are for everybody (although not all archs will actually
    discard it in modules) */
-#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline
+#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline __nocfi
 #define __initdata	__section(".init.data")
 #define __initconst	__section(".init.rodata")
 #define __exitdata	__section(".exit.data")
diff --git a/include/linux/module.h b/include/linux/module.h
index da4b6fbe8ebe..8100bb477d86 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -26,6 +26,7 @@
 #include <linux/tracepoint-defs.h>
 #include <linux/srcu.h>
 #include <linux/static_call_types.h>
+#include <linux/cfi.h>
 
 #include <linux/percpu.h>
 #include <asm/module.h>
@@ -128,13 +129,17 @@ extern void cleanup_module(void);
 #define module_init(initfn)					\
 	static inline initcall_t __maybe_unused __inittest(void)		\
 	{ return initfn; }					\
-	int init_module(void) __copy(initfn) __attribute__((alias(#initfn)));
+	int init_module(void) __copy(initfn)			\
+		__attribute__((alias(#initfn)));		\
+	__CFI_ADDRESSABLE(init_module, __initdata);
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)					\
 	static inline exitcall_t __maybe_unused __exittest(void)		\
 	{ return exitfn; }					\
-	void cleanup_module(void) __copy(exitfn) __attribute__((alias(#exitfn)));
+	void cleanup_module(void) __copy(exitfn)		\
+		__attribute__((alias(#exitfn)));		\
+	__CFI_ADDRESSABLE(cleanup_module, __exitdata);
 
 #endif
 
@@ -376,6 +381,10 @@ struct module {
 	const s32 *crcs;
 	unsigned int num_syms;
 
+#ifdef CONFIG_CFI_CLANG
+	cfi_check_fn cfi_check;
+#endif
+
 	/* Kernel parameters. */
 #ifdef CONFIG_SYSFS
 	struct mutex param_lock;
diff --git a/init/Kconfig b/init/Kconfig
index 5f5c776ef192..5babea38e346 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2296,7 +2296,7 @@ endif # MODULES
 
 config MODULES_TREE_LOOKUP
 	def_bool y
-	depends on PERF_EVENTS || TRACING
+	depends on PERF_EVENTS || TRACING || CFI_CLANG
 
 config INIT_ALL_POSSIBLE
 	bool
diff --git a/kernel/Makefile b/kernel/Makefile
index 320f1f3941b7..e8a6715f38dc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -41,6 +41,9 @@ KCSAN_SANITIZE_kcov.o := n
 UBSAN_SANITIZE_kcov.o := n
 CFLAGS_kcov.o := $(call cc-option, -fno-conserve-stack) -fno-stack-protector
 
+# Don't instrument error handlers
+CFLAGS_REMOVE_cfi.o := $(CC_FLAGS_CFI)
+
 obj-y += sched/
 obj-y += locking/
 obj-y += power/
@@ -111,6 +114,7 @@ obj-$(CONFIG_BPF) += bpf/
 obj-$(CONFIG_KCSAN) += kcsan/
 obj-$(CONFIG_SHADOW_CALL_STACK) += scs.o
 obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call.o
+obj-$(CONFIG_CFI_CLANG) += cfi.o
 
 obj-$(CONFIG_PERF_EVENTS) += events/
 
diff --git a/kernel/cfi.c b/kernel/cfi.c
new file mode 100644
index 000000000000..e17a56639766
--- /dev/null
+++ b/kernel/cfi.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clang Control Flow Integrity (CFI) error and slowpath handling.
+ *
+ * Copyright (C) 2021 Google LLC
+ */
+
+#include <linux/hardirq.h>
+#include <linux/kallsyms.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/printk.h>
+#include <linux/ratelimit.h>
+#include <linux/rcupdate.h>
+#include <linux/vmalloc.h>
+#include <asm/cacheflush.h>
+#include <asm/set_memory.h>
+
+/* Compiler-defined handler names */
+#ifdef CONFIG_CFI_PERMISSIVE
+#define cfi_failure_handler	__ubsan_handle_cfi_check_fail
+#else
+#define cfi_failure_handler	__ubsan_handle_cfi_check_fail_abort
+#endif
+
+static inline void handle_cfi_failure(void *ptr)
+{
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
+		WARN_RATELIMIT(1, "CFI failure (target: %pS):\n", ptr);
+	else
+		panic("CFI failure (target: %pS)\n", ptr);
+}
+
+#ifdef CONFIG_MODULES
+#ifdef CONFIG_CFI_CLANG_SHADOW
+/*
+ * Index type. A 16-bit index can address at most (2^16)-2 pages (taking
+ * into account SHADOW_INVALID), i.e. ~256M with 4k pages.
+ */
+typedef u16 shadow_t;
+#define SHADOW_INVALID		((shadow_t)~0UL)
+
+struct cfi_shadow {
+	/* Page index for the beginning of the shadow */
+	unsigned long base;
+	/* An array of __cfi_check locations (as indices to the shadow) */
+	shadow_t shadow[1];
+} __packed;
+
+/*
+ * The shadow covers ~128M from the beginning of the module region. If
+ * the region is larger, we fall back to __module_address for the rest.
+ */
+#define __SHADOW_RANGE		(_UL(SZ_128M) >> PAGE_SHIFT)
+
+/* The in-memory size of struct cfi_shadow, always at least one page */
+#define __SHADOW_PAGES		((__SHADOW_RANGE * sizeof(shadow_t)) >> PAGE_SHIFT)
+#define SHADOW_PAGES		max(1UL, __SHADOW_PAGES)
+#define SHADOW_SIZE		(SHADOW_PAGES << PAGE_SHIFT)
+
+/* The actual size of the shadow array, minus metadata */
+#define SHADOW_ARR_SIZE		(SHADOW_SIZE - offsetof(struct cfi_shadow, shadow))
+#define SHADOW_ARR_SLOTS	(SHADOW_ARR_SIZE / sizeof(shadow_t))
+
+static DEFINE_MUTEX(shadow_update_lock);
+static struct cfi_shadow __rcu *cfi_shadow __read_mostly;
+
+/* Returns the index in the shadow for the given address */
+static inline int ptr_to_shadow(const struct cfi_shadow *s, unsigned long ptr)
+{
+	unsigned long index;
+	unsigned long page = ptr >> PAGE_SHIFT;
+
+	if (unlikely(page < s->base))
+		return -1; /* Outside of module area */
+
+	index = page - s->base;
+
+	if (index >= SHADOW_ARR_SLOTS)
+		return -1; /* Cannot be addressed with shadow */
+
+	return (int)index;
+}
+
+/* Returns the page address for an index in the shadow */
+static inline unsigned long shadow_to_ptr(const struct cfi_shadow *s,
+	int index)
+{
+	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
+		return 0;
+
+	return (s->base + index) << PAGE_SHIFT;
+}
+
+/* Returns the __cfi_check function address for the given shadow location */
+static inline unsigned long shadow_to_check_fn(const struct cfi_shadow *s,
+	int index)
+{
+	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
+		return 0;
+
+	if (unlikely(s->shadow[index] == SHADOW_INVALID))
+		return 0;
+
+	/* __cfi_check is always page aligned */
+	return (s->base + s->shadow[index]) << PAGE_SHIFT;
+}
+
+static void prepare_next_shadow(const struct cfi_shadow __rcu *prev,
+		struct cfi_shadow *next)
+{
+	int i, index, check;
+
+	/* Mark everything invalid */
+	memset(next->shadow, 0xFF, SHADOW_ARR_SIZE);
+
+	if (!prev)
+		return; /* No previous shadow */
+
+	/* If the base address didn't change, an update is not needed */
+	if (prev->base == next->base) {
+		memcpy(next->shadow, prev->shadow, SHADOW_ARR_SIZE);
+		return;
+	}
+
+	/* Convert the previous shadow to the new address range */
+	for (i = 0; i < SHADOW_ARR_SLOTS; ++i) {
+		if (prev->shadow[i] == SHADOW_INVALID)
+			continue;
+
+		index = ptr_to_shadow(next, shadow_to_ptr(prev, i));
+		if (index < 0)
+			continue;
+
+		check = ptr_to_shadow(next,
+				shadow_to_check_fn(prev, prev->shadow[i]));
+		if (check < 0)
+			continue;
+
+		next->shadow[index] = (shadow_t)check;
+	}
+}
+
+static void add_module_to_shadow(struct cfi_shadow *s, struct module *mod,
+			unsigned long min_addr, unsigned long max_addr)
+{
+	int check_index;
+	unsigned long check = (unsigned long)mod->cfi_check;
+	unsigned long ptr;
+
+	if (unlikely(!PAGE_ALIGNED(check))) {
+		pr_warn("cfi: not using shadow for module %s\n", mod->name);
+		return;
+	}
+
+	check_index = ptr_to_shadow(s, check);
+	if (check_index < 0)
+		return; /* Module not addressable with shadow */
+
+	/* For each page, store the check function index in the shadow */
+	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
+		int index = ptr_to_shadow(s, ptr);
+
+		if (index >= 0) {
+			/* Each page must only contain one module */
+			WARN_ON_ONCE(s->shadow[index] != SHADOW_INVALID);
+			s->shadow[index] = (shadow_t)check_index;
+		}
+	}
+}
+
+static void remove_module_from_shadow(struct cfi_shadow *s, struct module *mod,
+		unsigned long min_addr, unsigned long max_addr)
+{
+	unsigned long ptr;
+
+	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
+		int index = ptr_to_shadow(s, ptr);
+
+		if (index >= 0)
+			s->shadow[index] = SHADOW_INVALID;
+	}
+}
+
+typedef void (*update_shadow_fn)(struct cfi_shadow *, struct module *,
+			unsigned long min_addr, unsigned long max_addr);
+
+static void update_shadow(struct module *mod, unsigned long base_addr,
+		update_shadow_fn fn)
+{
+	struct cfi_shadow *prev;
+	struct cfi_shadow *next;
+	unsigned long min_addr, max_addr;
+
+	next = vmalloc(SHADOW_SIZE);
+
+	mutex_lock(&shadow_update_lock);
+	prev = rcu_dereference_protected(cfi_shadow,
+					 mutex_is_locked(&shadow_update_lock));
+
+	if (next) {
+		next->base = base_addr >> PAGE_SHIFT;
+		prepare_next_shadow(prev, next);
+
+		min_addr = (unsigned long)mod->core_layout.base;
+		max_addr = min_addr + mod->core_layout.text_size;
+		fn(next, mod, min_addr & PAGE_MASK, max_addr & PAGE_MASK);
+
+		set_memory_ro((unsigned long)next, SHADOW_PAGES);
+	}
+
+	rcu_assign_pointer(cfi_shadow, next);
+	mutex_unlock(&shadow_update_lock);
+	synchronize_rcu();
+
+	if (prev) {
+		set_memory_rw((unsigned long)prev, SHADOW_PAGES);
+		vfree(prev);
+	}
+}
+
+void cfi_module_add(struct module *mod, unsigned long base_addr)
+{
+	update_shadow(mod, base_addr, add_module_to_shadow);
+}
+
+void cfi_module_remove(struct module *mod, unsigned long base_addr)
+{
+	update_shadow(mod, base_addr, remove_module_from_shadow);
+}
+
+static inline cfi_check_fn ptr_to_check_fn(const struct cfi_shadow __rcu *s,
+	unsigned long ptr)
+{
+	int index;
+
+	if (unlikely(!s))
+		return NULL; /* No shadow available */
+
+	index = ptr_to_shadow(s, ptr);
+	if (index < 0)
+		return NULL; /* Cannot be addressed with shadow */
+
+	return (cfi_check_fn)shadow_to_check_fn(s, index);
+}
+
+static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn;
+
+	rcu_read_lock_sched();
+	fn = ptr_to_check_fn(rcu_dereference_sched(cfi_shadow), ptr);
+	rcu_read_unlock_sched();
+
+	return fn;
+}
+
+#else /* !CONFIG_CFI_CLANG_SHADOW */
+
+static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
+{
+	return NULL;
+}
+
+#endif /* CONFIG_CFI_CLANG_SHADOW */
+
+static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn = NULL;
+	struct module *mod;
+
+	rcu_read_lock_sched();
+	mod = __module_address(ptr);
+	if (mod)
+		fn = mod->cfi_check;
+	rcu_read_unlock_sched();
+
+	return fn;
+}
+
+static inline cfi_check_fn find_check_fn(unsigned long ptr)
+{
+	cfi_check_fn fn = NULL;
+
+	if (is_kernel_text(ptr))
+		return __cfi_check;
+
+	/*
+	 * Indirect call checks can happen when RCU is not watching. Both
+	 * the shadow and __module_address use RCU, so we need to wake it
+	 * up if necessary.
+	 */
+	RCU_NONIDLE({
+		if (IS_ENABLED(CONFIG_CFI_CLANG_SHADOW))
+			fn = find_shadow_check_fn(ptr);
+
+		if (!fn)
+			fn = find_module_check_fn(ptr);
+	});
+
+	return fn;
+}
+
+void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+{
+	cfi_check_fn fn = find_check_fn((unsigned long)ptr);
+
+	if (likely(fn))
+		fn(id, ptr, diag);
+	else /* Don't allow unchecked modules */
+		handle_cfi_failure(ptr);
+}
+EXPORT_SYMBOL(__cfi_slowpath_diag);
+
+#else /* !CONFIG_MODULES */
+
+void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+{
+	handle_cfi_failure(ptr); /* No modules */
+}
+EXPORT_SYMBOL(__cfi_slowpath_diag);
+
+#endif /* CONFIG_MODULES */
+
+void cfi_failure_handler(void *data, void *ptr, void *vtable)
+{
+	handle_cfi_failure(ptr);
+}
+EXPORT_SYMBOL(cfi_failure_handler);
diff --git a/kernel/module.c b/kernel/module.c
index 30479355ab85..20fb004e7d8d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2146,6 +2146,8 @@ void __weak module_arch_freeing_init(struct module *mod)
 {
 }
 
+static void cfi_cleanup(struct module *mod);
+
 /* Free a module, remove from lists, etc. */
 static void free_module(struct module *mod)
 {
@@ -2187,6 +2189,9 @@ static void free_module(struct module *mod)
 	synchronize_rcu();
 	mutex_unlock(&module_mutex);
 
+	/* Clean up CFI for the module. */
+	cfi_cleanup(mod);
+
 	/* This may be empty, but that's OK */
 	module_arch_freeing_init(mod);
 	module_memfree(mod->init_layout.base);
@@ -3866,6 +3871,8 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,
 	return 0;
 }
 
+static void cfi_init(struct module *mod);
+
 /*
  * Allocate and load the module: note that size of section 0 is always
  * zero, and we rely on this for optional sections.
@@ -3997,6 +4004,9 @@ static int load_module(struct load_info *info, const char __user *uargs,
 
 	flush_module_icache(mod);
 
+	/* Setup CFI for the module. */
+	cfi_init(mod);
+
 	/* Now copy in args */
 	mod->args = strndup_user(uargs, ~0UL >> 1);
 	if (IS_ERR(mod->args)) {
@@ -4070,6 +4080,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
 	synchronize_rcu();
 	kfree(mod->args);
  free_arch_cleanup:
+	cfi_cleanup(mod);
 	module_arch_cleanup(mod);
  free_modinfo:
 	free_modinfo(mod);
@@ -4415,6 +4426,38 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, const char *,
 #endif /* CONFIG_LIVEPATCH */
 #endif /* CONFIG_KALLSYMS */
 
+static void cfi_init(struct module *mod)
+{
+#ifdef CONFIG_CFI_CLANG
+	initcall_t *init;
+	exitcall_t *exit;
+
+	rcu_read_lock_sched();
+	mod->cfi_check = (cfi_check_fn)
+		find_kallsyms_symbol_value(mod, "__cfi_check");
+	init = (initcall_t *)
+		find_kallsyms_symbol_value(mod, "__cfi_jt_init_module");
+	exit = (exitcall_t *)
+		find_kallsyms_symbol_value(mod, "__cfi_jt_cleanup_module");
+	rcu_read_unlock_sched();
+
+	/* Fix init/exit functions to point to the CFI jump table */
+	if (init)
+		mod->init = *init;
+	if (exit)
+		mod->exit = *exit;
+
+	cfi_module_add(mod, module_addr_min);
+#endif
+}
+
+static void cfi_cleanup(struct module *mod)
+{
+#ifdef CONFIG_CFI_CLANG
+	cfi_module_remove(mod, module_addr_min);
+#endif
+}
+
 /* Maximum number of characters written by module_flags() */
 #define MODULE_FLAGS_BUF_SIZE (TAINT_FLAGS_COUNT + 4)
 
diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
index 735e11e9041b..dd87cea9fba7 100644
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@ -23,7 +23,7 @@ modname = $(notdir $(@:.mod.o=))
 part-of-module = y
 
 quiet_cmd_cc_o_c = CC [M]  $@
-      cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
+      cmd_cc_o_c = $(CC) $(filter-out $(CC_FLAGS_CFI), $(c_flags)) -c -o $@ $<
 
 %.mod.o: %.mod.c FORCE
 	$(call if_changed_dep,cc_o_c)
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:27 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:27 -0700
Subject: [PATCH v6 02/18] cfi: add __cficanonical
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-3-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces a function address taken
in C code with the address of a local jump table entry, which passes
runtime indirect call checks. However, the compiler won't replace
addresses taken in assembly code, which will result in a CFI failure
if we later jump to such an address in instrumented C code. The code
generated for the non-canonical jump table looks this:

  <noncanonical.cfi_jt>: /* In C, &noncanonical points here */
	jmp noncanonical
  ...
  <noncanonical>:        /* function body */
	...

This change adds the __cficanonical attribute, which tells the
compiler to use a canonical jump table for the function instead. This
means the compiler will rename the actual function to <function>.cfi
and points the original symbol to the jump table entry instead:

  <canonical>:           /* jump table entry */
	jmp canonical.cfi
  ...
  <canonical.cfi>:       /* function body */
	...

As a result, the address taken in assembly, or other non-instrumented
code always points to the jump table and therefore, can be used for
indirect calls in instrumented code without tripping CFI checks.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>   # pci.h
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 include/linux/compiler-clang.h | 1 +
 include/linux/compiler_types.h | 4 ++++
 include/linux/init.h           | 4 ++--
 include/linux/pci.h            | 4 ++--
 4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 6de9d0c9377e..adbe76b203e2 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -63,3 +63,4 @@
 #endif
 
 #define __nocfi		__attribute__((__no_sanitize__("cfi")))
+#define __cficanonical	__attribute__((__cfi_canonical_jump_table__))
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 796935a37e37..d29bda7f6ebd 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -246,6 +246,10 @@ struct ftrace_likely_data {
 # define __nocfi
 #endif
 
+#ifndef __cficanonical
+# define __cficanonical
+#endif
+
 #ifndef asm_volatile_goto
 #define asm_volatile_goto(x...) asm goto(x)
 #endif
diff --git a/include/linux/init.h b/include/linux/init.h
index b3ea15348fbd..045ad1650ed1 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -220,8 +220,8 @@ extern bool initcall_debug;
 	__initcall_name(initstub, __iid, id)
 
 #define __define_initcall_stub(__stub, fn)			\
-	int __init __stub(void);				\
-	int __init __stub(void)					\
+	int __init __cficanonical __stub(void);			\
+	int __init __cficanonical __stub(void)			\
 	{ 							\
 		return fn();					\
 	}							\
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 86c799c97b77..39684b72db91 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1944,8 +1944,8 @@ enum pci_fixup_pass {
 #ifdef CONFIG_LTO_CLANG
 #define __DECLARE_PCI_FIXUP_SECTION(sec, name, vendor, device, class,	\
 				  class_shift, hook, stub)		\
-	void stub(struct pci_dev *dev);					\
-	void stub(struct pci_dev *dev)					\
+	void __cficanonical stub(struct pci_dev *dev);			\
+	void __cficanonical stub(struct pci_dev *dev)			\
 	{ 								\
 		hook(dev); 						\
 	}								\
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:28 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:28 -0700
Subject: [PATCH v6 03/18] mm: add generic function_nocfi macro
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-4-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function addresses
in instrumented C code with jump table addresses. This means that
__pa_symbol(function) returns the physical address of the jump table
entry instead of the actual function, which may not work as the jump
table code will immediately jump to a virtual address that may not be
mapped.

To avoid this address space confusion, this change adds a generic
definition for function_nocfi(), which architectures that support CFI
can override. The typical implementation of would use inline assembly
to take the function address, which avoids compiler instrumentation.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 include/linux/mm.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..22cce9c7dd05 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -124,6 +124,16 @@ extern int mmap_rnd_compat_bits __read_mostly;
 #define lm_alias(x)	__va(__pa_symbol(x))
 #endif
 
+/*
+ * With CONFIG_CFI_CLANG, the compiler replaces function addresses in
+ * instrumented C code with jump table addresses. Architectures that
+ * support CFI can define this macro to return the actual function address
+ * when needed.
+ */
+#ifndef function_nocfi
+#define function_nocfi(x) (x)
+#endif
+
 /*
  * To prevent common memory management code establishing
  * a zero page mapping on a read fault.
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:30 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:30 -0700
Subject: [PATCH v6 05/18] workqueue: use WARN_ON_FUNCTION_MISMATCH
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-6-samitolvanen@google.com>

With CONFIG_CFI_CLANG, a callback function passed to
__queue_delayed_work from a module points to a jump table entry
defined in the module instead of the one used in the core kernel,
which breaks function address equality in this check:

  WARN_ON_ONCE(timer->function != delayed_work_timer_fn);

Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
when CFI and modules are both enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 kernel/workqueue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 79f2319543ce..b19d759e55a5 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1630,7 +1630,7 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq,
 	struct work_struct *work = &dwork->work;
 
 	WARN_ON_ONCE(!wq);
-	WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
+	WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn);
 	WARN_ON_ONCE(timer_pending(timer));
 	WARN_ON_ONCE(!list_empty(&work->entry));
 
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:31 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:31 -0700
Subject: [PATCH v6 06/18] kthread: use WARN_ON_FUNCTION_MISMATCH
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-7-samitolvanen@google.com>

With CONFIG_CFI_CLANG, a callback function passed to
__kthread_queue_delayed_work from a module points to a jump table
entry defined in the module instead of the one used in the core
kernel, which breaks function address equality in this check:

  WARN_ON_ONCE(timer->function != ktead_delayed_work_timer_fn);

Use WARN_ON_FUNCTION_MISMATCH() instead to disable the warning
when CFI and modules are both enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 kernel/kthread.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 1578973c5740..a1972eba2917 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -963,7 +963,8 @@ static void __kthread_queue_delayed_work(struct kthread_worker *worker,
 	struct timer_list *timer = &dwork->timer;
 	struct kthread_work *work = &dwork->work;
 
-	WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn);
+	WARN_ON_FUNCTION_MISMATCH(timer->function,
+				  kthread_delayed_work_timer_fn);
 
 	/*
 	 * If @delay is 0, queue @dwork->work immediately.  This is for
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:33 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:33 -0700
Subject: [PATCH v6 08/18] bpf: disable CFI in dispatcher functions
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-9-samitolvanen@google.com>

BPF dispatcher functions are patched at runtime to perform direct
instead of indirect calls. Disable CFI for the dispatcher functions to
avoid conflicts.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 include/linux/bpf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3625f019767d..2f46f98479e1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -650,7 +650,7 @@ struct bpf_dispatcher {
 	struct bpf_ksym ksym;
 };
 
-static __always_inline unsigned int bpf_dispatcher_nop_func(
+static __always_inline __nocfi unsigned int bpf_dispatcher_nop_func(
 	const void *ctx,
 	const struct bpf_insn *insnsi,
 	unsigned int (*bpf_func)(const void *,
@@ -678,7 +678,7 @@ void bpf_trampoline_put(struct bpf_trampoline *tr);
 }
 
 #define DEFINE_BPF_DISPATCHER(name)					\
-	noinline unsigned int bpf_dispatcher_##name##_func(		\
+	noinline __nocfi unsigned int bpf_dispatcher_##name##_func(	\
 		const void *ctx,					\
 		const struct bpf_insn *insnsi,				\
 		unsigned int (*bpf_func)(const void *,			\
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:34 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:34 -0700
Subject: [PATCH v6 09/18] treewide: Change list_sort to use const pointers
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-10-samitolvanen@google.com>

list_sort() internally casts the comparison function passed to it
to a different type with constant struct list_head pointers, and
uses this pointer to call the functions, which trips indirect call
Control-Flow Integrity (CFI) checking.

Instead of removing the consts, this change defines the
list_cmp_func_t type and changes the comparison function types of
all list_sort() callers to use const pointers, thus avoiding type
mismatches.

Suggested-by: Nick Desaulniers <ndesaulniers at google.com>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>
Reviewed-by: Christoph Hellwig <hch at lst.de>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nick Desaulniers <ndesaulniers at google.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/kvm/vgic/vgic-its.c                  |  8 ++++----
 arch/arm64/kvm/vgic/vgic.c                      |  3 ++-
 block/blk-mq-sched.c                            |  3 ++-
 block/blk-mq.c                                  |  3 ++-
 drivers/acpi/nfit/core.c                        |  3 ++-
 drivers/acpi/numa/hmat.c                        |  3 ++-
 drivers/clk/keystone/sci-clk.c                  |  4 ++--
 drivers/gpu/drm/drm_modes.c                     |  3 ++-
 drivers/gpu/drm/i915/gt/intel_engine_user.c     |  3 ++-
 drivers/gpu/drm/i915/gvt/debugfs.c              |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c   |  3 ++-
 drivers/gpu/drm/radeon/radeon_cs.c              |  4 ++--
 .../hw/usnic/usnic_uiom_interval_tree.c         |  3 ++-
 drivers/interconnect/qcom/bcm-voter.c           |  2 +-
 drivers/md/raid5.c                              |  3 ++-
 drivers/misc/sram.c                             |  4 ++--
 drivers/nvme/host/core.c                        |  3 ++-
 .../pci/controller/cadence/pcie-cadence-host.c  |  3 ++-
 drivers/spi/spi-loopback-test.c                 |  3 ++-
 fs/btrfs/raid56.c                               |  3 ++-
 fs/btrfs/tree-log.c                             |  3 ++-
 fs/btrfs/volumes.c                              |  3 ++-
 fs/ext4/fsmap.c                                 |  4 ++--
 fs/gfs2/glock.c                                 |  3 ++-
 fs/gfs2/log.c                                   |  2 +-
 fs/gfs2/lops.c                                  |  3 ++-
 fs/iomap/buffered-io.c                          |  3 ++-
 fs/ubifs/gc.c                                   |  7 ++++---
 fs/ubifs/replay.c                               |  4 ++--
 fs/xfs/scrub/bitmap.c                           |  4 ++--
 fs/xfs/xfs_bmap_item.c                          |  4 ++--
 fs/xfs/xfs_buf.c                                |  6 +++---
 fs/xfs/xfs_extent_busy.c                        |  4 ++--
 fs/xfs/xfs_extent_busy.h                        |  3 ++-
 fs/xfs/xfs_extfree_item.c                       |  4 ++--
 fs/xfs/xfs_refcount_item.c                      |  4 ++--
 fs/xfs/xfs_rmap_item.c                          |  4 ++--
 include/linux/list_sort.h                       |  7 ++++---
 lib/list_sort.c                                 | 17 ++++++-----------
 lib/test_list_sort.c                            |  3 ++-
 net/tipc/name_table.c                           |  4 ++--
 41 files changed, 90 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 40cbaca81333..b9518f94bd43 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2190,8 +2190,8 @@ static int vgic_its_restore_ite(struct vgic_its *its, u32 event_id,
 	return offset;
 }
 
-static int vgic_its_ite_cmp(void *priv, struct list_head *a,
-			    struct list_head *b)
+static int vgic_its_ite_cmp(void *priv, const struct list_head *a,
+			    const struct list_head *b)
 {
 	struct its_ite *itea = container_of(a, struct its_ite, ite_list);
 	struct its_ite *iteb = container_of(b, struct its_ite, ite_list);
@@ -2329,8 +2329,8 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
 	return offset;
 }
 
-static int vgic_its_device_cmp(void *priv, struct list_head *a,
-			       struct list_head *b)
+static int vgic_its_device_cmp(void *priv, const struct list_head *a,
+			       const struct list_head *b)
 {
 	struct its_device *deva = container_of(a, struct its_device, dev_list);
 	struct its_device *devb = container_of(b, struct its_device, dev_list);
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1c597c9885fa..15b666200f0b 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -255,7 +255,8 @@ static struct kvm_vcpu *vgic_target_oracle(struct vgic_irq *irq)
  * Return negative if "a" sorts before "b", 0 to preserve order, and positive
  * to sort "b" before "a".
  */
-static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int vgic_irq_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct vgic_irq *irqa = container_of(a, struct vgic_irq, ap_list);
 	struct vgic_irq *irqb = container_of(b, struct vgic_irq, ap_list);
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index e1e997af89a0..3ebd6f10f728 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -75,7 +75,8 @@ void blk_mq_sched_restart(struct blk_mq_hw_ctx *hctx)
 	blk_mq_run_hw_queue(hctx, true);
 }
 
-static int sched_rq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int sched_rq_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct request *rqa = container_of(a, struct request, queuelist);
 	struct request *rqb = container_of(b, struct request, queuelist);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d4d7c1caa439..4e3a70ab5be1 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1895,7 +1895,8 @@ void blk_mq_insert_requests(struct blk_mq_hw_ctx *hctx, struct blk_mq_ctx *ctx,
 	spin_unlock(&ctx->lock);
 }
 
-static int plug_rq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int plug_rq_cmp(void *priv, const struct list_head *a,
+		       const struct list_head *b)
 {
 	struct request *rqa = container_of(a, struct request, queuelist);
 	struct request *rqb = container_of(b, struct request, queuelist);
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 8c5dde628405..d15e3ee93b5b 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1195,7 +1195,8 @@ static int __nfit_mem_init(struct acpi_nfit_desc *acpi_desc,
 	return 0;
 }
 
-static int nfit_mem_cmp(void *priv, struct list_head *_a, struct list_head *_b)
+static int nfit_mem_cmp(void *priv, const struct list_head *_a,
+		const struct list_head *_b)
 {
 	struct nfit_mem *a = container_of(_a, typeof(*a), list);
 	struct nfit_mem *b = container_of(_b, typeof(*b), list);
diff --git a/drivers/acpi/numa/hmat.c b/drivers/acpi/numa/hmat.c
index cb73a5d6ea76..137a5dd880c2 100644
--- a/drivers/acpi/numa/hmat.c
+++ b/drivers/acpi/numa/hmat.c
@@ -558,7 +558,8 @@ static bool hmat_update_best(u8 type, u32 value, u32 *best)
 	return updated;
 }
 
-static int initiator_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int initiator_cmp(void *priv, const struct list_head *a,
+			 const struct list_head *b)
 {
 	struct memory_initiator *ia;
 	struct memory_initiator *ib;
diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
index aaf31abe1c8f..7e1b136e71ae 100644
--- a/drivers/clk/keystone/sci-clk.c
+++ b/drivers/clk/keystone/sci-clk.c
@@ -503,8 +503,8 @@ static int ti_sci_scan_clocks_from_fw(struct sci_clk_provider *provider)
 
 #else
 
-static int _cmp_sci_clk_list(void *priv, struct list_head *a,
-			     struct list_head *b)
+static int _cmp_sci_clk_list(void *priv, const struct list_head *a,
+			     const struct list_head *b)
 {
 	struct sci_clk *ca = container_of(a, struct sci_clk, node);
 	struct sci_clk *cb = container_of(b, struct sci_clk, node);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1ac67d4505e0..6662d0457ad6 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1290,7 +1290,8 @@ EXPORT_SYMBOL(drm_mode_prune_invalid);
  * Negative if @lh_a is better than @lh_b, zero if they're equivalent, or
  * positive if @lh_b is better than @lh_a.
  */
-static int drm_mode_compare(void *priv, struct list_head *lh_a, struct list_head *lh_b)
+static int drm_mode_compare(void *priv, const struct list_head *lh_a,
+			    const struct list_head *lh_b)
 {
 	struct drm_display_mode *a = list_entry(lh_a, struct drm_display_mode, head);
 	struct drm_display_mode *b = list_entry(lh_b, struct drm_display_mode, head);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 34e6096f196e..da21d2a10cc9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -49,7 +49,8 @@ static const u8 uabi_classes[] = {
 	[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
 };
 
-static int engine_cmp(void *priv, struct list_head *A, struct list_head *B)
+static int engine_cmp(void *priv, const struct list_head *A,
+		      const struct list_head *B)
 {
 	const struct intel_engine_cs *a =
 		container_of((struct rb_node *)A, typeof(*a), uabi_node);
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c b/drivers/gpu/drm/i915/gvt/debugfs.c
index 62e6a14ad58e..9f1c209d9251 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -41,7 +41,7 @@ struct diff_mmio {
 
 /* Compare two diff_mmio items. */
 static int mmio_offset_compare(void *priv,
-	struct list_head *a, struct list_head *b)
+	const struct list_head *a, const struct list_head *b)
 {
 	struct diff_mmio *ma;
 	struct diff_mmio *mb;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index c1adea8765a9..52b9c39e0155 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1076,7 +1076,8 @@ static int igt_ppgtt_shrink_boom(void *arg)
 	return exercise_ppgtt(arg, shrink_boom);
 }
 
-static int sort_holes(void *priv, struct list_head *A, struct list_head *B)
+static int sort_holes(void *priv, const struct list_head *A,
+		      const struct list_head *B)
 {
 	struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack);
 	struct drm_mm_node *b = list_entry(B, typeof(*b), hole_stack);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c
index 35e937d39b51..1a5c3db1d53b 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -393,8 +393,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
 	return 0;
 }
 
-static int cmp_size_smaller_first(void *priv, struct list_head *a,
-				  struct list_head *b)
+static int cmp_size_smaller_first(void *priv, const struct list_head *a,
+				  const struct list_head *b)
 {
 	struct radeon_bo_list *la = list_entry(a, struct radeon_bo_list, tv.head);
 	struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list, tv.head);
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c b/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
index d399523206c7..29d71267af78 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom_interval_tree.c
@@ -83,7 +83,8 @@ usnic_uiom_interval_node_alloc(long int start, long int last, int ref_cnt,
 	return interval;
 }
 
-static int interval_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int interval_cmp(void *priv, const struct list_head *a,
+			const struct list_head *b)
 {
 	struct usnic_uiom_interval_node *node_a, *node_b;
 
diff --git a/drivers/interconnect/qcom/bcm-voter.c b/drivers/interconnect/qcom/bcm-voter.c
index 1cc565bce2f4..d1591a28b743 100644
--- a/drivers/interconnect/qcom/bcm-voter.c
+++ b/drivers/interconnect/qcom/bcm-voter.c
@@ -39,7 +39,7 @@ struct bcm_voter {
 	u32 tcs_wait;
 };
 
-static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
+static int cmp_vcd(void *priv, const struct list_head *a, const struct list_head *b)
 {
 	const struct qcom_icc_bcm *bcm_a = list_entry(a, struct qcom_icc_bcm, list);
 	const struct qcom_icc_bcm *bcm_b = list_entry(b, struct qcom_icc_bcm, list);
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 5d57a5bd171f..841e1c1aa5e6 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -953,7 +953,8 @@ static void dispatch_bio_list(struct bio_list *tmp)
 		submit_bio_noacct(bio);
 }
 
-static int cmp_stripe(void *priv, struct list_head *a, struct list_head *b)
+static int cmp_stripe(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	const struct r5pending_data *da = list_entry(a,
 				struct r5pending_data, sibling);
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 6c1a23cb3e8c..202bf951e909 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -144,8 +144,8 @@ static void sram_free_partitions(struct sram_dev *sram)
 	}
 }
 
-static int sram_reserve_cmp(void *priv, struct list_head *a,
-					struct list_head *b)
+static int sram_reserve_cmp(void *priv, const struct list_head *a,
+					const struct list_head *b)
 {
 	struct sram_reserve *ra = list_entry(a, struct sram_reserve, list);
 	struct sram_reserve *rb = list_entry(b, struct sram_reserve, list);
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 0896e21642be..5eaaa51a5e30 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3855,7 +3855,8 @@ static int nvme_init_ns_head(struct nvme_ns *ns, unsigned nsid,
 	return ret;
 }
 
-static int ns_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int ns_cmp(void *priv, const struct list_head *a,
+		const struct list_head *b)
 {
 	struct nvme_ns *nsa = container_of(a, struct nvme_ns, list);
 	struct nvme_ns *nsb = container_of(b, struct nvme_ns, list);
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 73dcf8cf98fb..ae1c55503513 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -345,7 +345,8 @@ static int cdns_pcie_host_bar_config(struct cdns_pcie_rc *rc,
 	return 0;
 }
 
-static int cdns_pcie_host_dma_ranges_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int cdns_pcie_host_dma_ranges_cmp(void *priv, const struct list_head *a,
+					 const struct list_head *b)
 {
 	struct resource_entry *entry1, *entry2;
 
diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index df981e55c24c..f1cf2232f0b5 100644
--- a/drivers/spi/spi-loopback-test.c
+++ b/drivers/spi/spi-loopback-test.c
@@ -454,7 +454,8 @@ struct rx_ranges {
 	u8 *end;
 };
 
-static int rx_ranges_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int rx_ranges_cmp(void *priv, const struct list_head *a,
+			 const struct list_head *b)
 {
 	struct rx_ranges *rx_a = list_entry(a, struct rx_ranges, list);
 	struct rx_ranges *rx_b = list_entry(b, struct rx_ranges, list);
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index 8c31357f08ed..f4139de63b2e 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1634,7 +1634,8 @@ struct btrfs_plug_cb {
 /*
  * rbios on the plug list are sorted for easier merging.
  */
-static int plug_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int plug_cmp(void *priv, const struct list_head *a,
+		    const struct list_head *b)
 {
 	struct btrfs_raid_bio *ra = container_of(a, struct btrfs_raid_bio,
 						 plug_list);
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 92a368627791..00a88bd8105e 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -4136,7 +4136,8 @@ static noinline int copy_items(struct btrfs_trans_handle *trans,
 	return ret;
 }
 
-static int extent_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int extent_cmp(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	struct extent_map *em1, *em2;
 
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1c6810bbaf8b..912dd8b9f156 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1224,7 +1224,8 @@ static int open_fs_devices(struct btrfs_fs_devices *fs_devices,
 	return 0;
 }
 
-static int devid_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int devid_cmp(void *priv, const struct list_head *a,
+		     const struct list_head *b)
 {
 	struct btrfs_device *dev1, *dev2;
 
diff --git a/fs/ext4/fsmap.c b/fs/ext4/fsmap.c
index 4c2a9fe30067..4493ef0c715e 100644
--- a/fs/ext4/fsmap.c
+++ b/fs/ext4/fsmap.c
@@ -354,8 +354,8 @@ static unsigned int ext4_getfsmap_find_sb(struct super_block *sb,
 
 /* Compare two fsmap items. */
 static int ext4_getfsmap_compare(void *priv,
-				 struct list_head *a,
-				 struct list_head *b)
+				 const struct list_head *a,
+				 const struct list_head *b)
 {
 	struct ext4_fsmap *fa;
 	struct ext4_fsmap *fb;
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 9567520d79f7..c06a6cdf05de 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1732,7 +1732,8 @@ void gfs2_glock_complete(struct gfs2_glock *gl, int ret)
 	spin_unlock(&gl->gl_lockref.lock);
 }
 
-static int glock_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int glock_cmp(void *priv, const struct list_head *a,
+		     const struct list_head *b)
 {
 	struct gfs2_glock *gla, *glb;
 
diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
index 6410281546f9..88649b43fcff 100644
--- a/fs/gfs2/log.c
+++ b/fs/gfs2/log.c
@@ -695,7 +695,7 @@ void log_flush_wait(struct gfs2_sbd *sdp)
 	}
 }
 
-static int ip_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int ip_cmp(void *priv, const struct list_head *a, const struct list_head *b)
 {
 	struct gfs2_inode *ipa, *ipb;
 
diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index a82f4747aa8d..b4809967efc6 100644
--- a/fs/gfs2/lops.c
+++ b/fs/gfs2/lops.c
@@ -634,7 +634,8 @@ static void gfs2_check_magic(struct buffer_head *bh)
 	kunmap_atomic(kaddr);
 }
 
-static int blocknr_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int blocknr_cmp(void *priv, const struct list_head *a,
+		       const struct list_head *b)
 {
 	struct gfs2_bufdata *bda, *bdb;
 
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 414769a6ad11..0129e6bab985 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1155,7 +1155,8 @@ iomap_ioend_try_merge(struct iomap_ioend *ioend, struct list_head *more_ioends,
 EXPORT_SYMBOL_GPL(iomap_ioend_try_merge);
 
 static int
-iomap_ioend_compare(void *priv, struct list_head *a, struct list_head *b)
+iomap_ioend_compare(void *priv, const struct list_head *a,
+		const struct list_head *b)
 {
 	struct iomap_ioend *ia = container_of(a, struct iomap_ioend, io_list);
 	struct iomap_ioend *ib = container_of(b, struct iomap_ioend, io_list);
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index a4aaeea63893..dc3e26e9ed7b 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -102,7 +102,8 @@ static int switch_gc_head(struct ubifs_info *c)
  * This function compares data nodes @a and @b. Returns %1 if @a has greater
  * inode or block number, and %-1 otherwise.
  */
-static int data_nodes_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int data_nodes_cmp(void *priv, const struct list_head *a,
+			  const struct list_head *b)
 {
 	ino_t inuma, inumb;
 	struct ubifs_info *c = priv;
@@ -145,8 +146,8 @@ static int data_nodes_cmp(void *priv, struct list_head *a, struct list_head *b)
  * first and sorted by length in descending order. Directory entry nodes go
  * after inode nodes and are sorted in ascending hash valuer order.
  */
-static int nondata_nodes_cmp(void *priv, struct list_head *a,
-			     struct list_head *b)
+static int nondata_nodes_cmp(void *priv, const struct list_head *a,
+			     const struct list_head *b)
 {
 	ino_t inuma, inumb;
 	struct ubifs_info *c = priv;
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 0f8a6a16421b..4d17e5382b74 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -298,8 +298,8 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r)
  * entries @a and @b by comparing their sequence numer.  Returns %1 if @a has
  * greater sequence number and %-1 otherwise.
  */
-static int replay_entries_cmp(void *priv, struct list_head *a,
-			      struct list_head *b)
+static int replay_entries_cmp(void *priv, const struct list_head *a,
+			      const struct list_head *b)
 {
 	struct ubifs_info *c = priv;
 	struct replay_entry *ra, *rb;
diff --git a/fs/xfs/scrub/bitmap.c b/fs/xfs/scrub/bitmap.c
index f88694f22d05..813b5f219113 100644
--- a/fs/xfs/scrub/bitmap.c
+++ b/fs/xfs/scrub/bitmap.c
@@ -63,8 +63,8 @@ xbitmap_init(
 static int
 xbitmap_range_cmp(
 	void			*priv,
-	struct list_head	*a,
-	struct list_head	*b)
+	const struct list_head	*a,
+	const struct list_head	*b)
 {
 	struct xbitmap_range	*ap;
 	struct xbitmap_range	*bp;
diff --git a/fs/xfs/xfs_bmap_item.c b/fs/xfs/xfs_bmap_item.c
index 2344757ede63..e3a691937e92 100644
--- a/fs/xfs/xfs_bmap_item.c
+++ b/fs/xfs/xfs_bmap_item.c
@@ -265,8 +265,8 @@ xfs_trans_log_finish_bmap_update(
 static int
 xfs_bmap_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_bmap_intent		*ba;
 	struct xfs_bmap_intent		*bb;
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 37a1d12762d8..592800c8852f 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -2124,9 +2124,9 @@ xfs_buf_delwri_queue(
  */
 static int
 xfs_buf_cmp(
-	void		*priv,
-	struct list_head *a,
-	struct list_head *b)
+	void			*priv,
+	const struct list_head	*a,
+	const struct list_head	*b)
 {
 	struct xfs_buf	*ap = container_of(a, struct xfs_buf, b_list);
 	struct xfs_buf	*bp = container_of(b, struct xfs_buf, b_list);
diff --git a/fs/xfs/xfs_extent_busy.c b/fs/xfs/xfs_extent_busy.c
index ef17c1f6db32..a4075685d9eb 100644
--- a/fs/xfs/xfs_extent_busy.c
+++ b/fs/xfs/xfs_extent_busy.c
@@ -629,8 +629,8 @@ xfs_extent_busy_wait_all(
 int
 xfs_extent_busy_ag_cmp(
 	void			*priv,
-	struct list_head	*l1,
-	struct list_head	*l2)
+	const struct list_head	*l1,
+	const struct list_head	*l2)
 {
 	struct xfs_extent_busy	*b1 =
 		container_of(l1, struct xfs_extent_busy, list);
diff --git a/fs/xfs/xfs_extent_busy.h b/fs/xfs/xfs_extent_busy.h
index 990ab3891971..8aea07100092 100644
--- a/fs/xfs/xfs_extent_busy.h
+++ b/fs/xfs/xfs_extent_busy.h
@@ -58,7 +58,8 @@ void
 xfs_extent_busy_wait_all(struct xfs_mount *mp);
 
 int
-xfs_extent_busy_ag_cmp(void *priv, struct list_head *a, struct list_head *b);
+xfs_extent_busy_ag_cmp(void *priv, const struct list_head *a,
+	const struct list_head *b);
 
 static inline void xfs_extent_busy_sort(struct list_head *list)
 {
diff --git a/fs/xfs/xfs_extfree_item.c b/fs/xfs/xfs_extfree_item.c
index 93223ebb3372..2424230ca2c3 100644
--- a/fs/xfs/xfs_extfree_item.c
+++ b/fs/xfs/xfs_extfree_item.c
@@ -397,8 +397,8 @@ xfs_trans_free_extent(
 static int
 xfs_extent_free_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_extent_free_item	*ra;
diff --git a/fs/xfs/xfs_refcount_item.c b/fs/xfs/xfs_refcount_item.c
index 07ebccbbf4df..746f4eda724c 100644
--- a/fs/xfs/xfs_refcount_item.c
+++ b/fs/xfs/xfs_refcount_item.c
@@ -269,8 +269,8 @@ xfs_trans_log_finish_refcount_update(
 static int
 xfs_refcount_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_refcount_intent	*ra;
diff --git a/fs/xfs/xfs_rmap_item.c b/fs/xfs/xfs_rmap_item.c
index 49cebd68b672..dc4f0c9f0897 100644
--- a/fs/xfs/xfs_rmap_item.c
+++ b/fs/xfs/xfs_rmap_item.c
@@ -337,8 +337,8 @@ xfs_trans_log_finish_rmap_update(
 static int
 xfs_rmap_update_diff_items(
 	void				*priv,
-	struct list_head		*a,
-	struct list_head		*b)
+	const struct list_head		*a,
+	const struct list_head		*b)
 {
 	struct xfs_mount		*mp = priv;
 	struct xfs_rmap_intent		*ra;
diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
index 20f178c24e9d..453105f74e05 100644
--- a/include/linux/list_sort.h
+++ b/include/linux/list_sort.h
@@ -6,8 +6,9 @@
 
 struct list_head;
 
+typedef int __attribute__((nonnull(2,3))) (*list_cmp_func_t)(void *,
+		const struct list_head *, const struct list_head *);
+
 __attribute__((nonnull(2,3)))
-void list_sort(void *priv, struct list_head *head,
-	       int (*cmp)(void *priv, struct list_head *a,
-			  struct list_head *b));
+void list_sort(void *priv, struct list_head *head, list_cmp_func_t cmp);
 #endif
diff --git a/lib/list_sort.c b/lib/list_sort.c
index 52f0c258c895..a926d96ffd44 100644
--- a/lib/list_sort.c
+++ b/lib/list_sort.c
@@ -7,16 +7,13 @@
 #include <linux/list_sort.h>
 #include <linux/list.h>
 
-typedef int __attribute__((nonnull(2,3))) (*cmp_func)(void *,
-		struct list_head const *, struct list_head const *);
-
 /*
  * Returns a list organized in an intermediate format suited
  * to chaining of merge() calls: null-terminated, no reserved or
  * sentinel head node, "prev" links not maintained.
  */
 __attribute__((nonnull(2,3,4)))
-static struct list_head *merge(void *priv, cmp_func cmp,
+static struct list_head *merge(void *priv, list_cmp_func_t cmp,
 				struct list_head *a, struct list_head *b)
 {
 	struct list_head *head, **tail = &head;
@@ -52,7 +49,7 @@ static struct list_head *merge(void *priv, cmp_func cmp,
  * throughout.
  */
 __attribute__((nonnull(2,3,4,5)))
-static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
+static void merge_final(void *priv, list_cmp_func_t cmp, struct list_head *head,
 			struct list_head *a, struct list_head *b)
 {
 	struct list_head *tail = head;
@@ -185,9 +182,7 @@ static void merge_final(void *priv, cmp_func cmp, struct list_head *head,
  * 2^(k+1) - 1 (second merge of case 5 when x == 2^(k-1) - 1).
  */
 __attribute__((nonnull(2,3)))
-void list_sort(void *priv, struct list_head *head,
-		int (*cmp)(void *priv, struct list_head *a,
-			struct list_head *b))
+void list_sort(void *priv, struct list_head *head, list_cmp_func_t cmp)
 {
 	struct list_head *list = head->next, *pending = NULL;
 	size_t count = 0;	/* Count of pending */
@@ -227,7 +222,7 @@ void list_sort(void *priv, struct list_head *head,
 		if (likely(bits)) {
 			struct list_head *a = *tail, *b = a->prev;
 
-			a = merge(priv, (cmp_func)cmp, b, a);
+			a = merge(priv, cmp, b, a);
 			/* Install the merged result in place of the inputs */
 			a->prev = b->prev;
 			*tail = a;
@@ -249,10 +244,10 @@ void list_sort(void *priv, struct list_head *head,
 
 		if (!next)
 			break;
-		list = merge(priv, (cmp_func)cmp, pending, list);
+		list = merge(priv, cmp, pending, list);
 		pending = next;
 	}
 	/* The final merge, rebuilding prev links */
-	merge_final(priv, (cmp_func)cmp, head, pending, list);
+	merge_final(priv, cmp, head, pending, list);
 }
 EXPORT_SYMBOL(list_sort);
diff --git a/lib/test_list_sort.c b/lib/test_list_sort.c
index 1f017d3b610e..00daaf23316f 100644
--- a/lib/test_list_sort.c
+++ b/lib/test_list_sort.c
@@ -56,7 +56,8 @@ static int __init check(struct debug_el *ela, struct debug_el *elb)
 	return 0;
 }
 
-static int __init cmp(void *priv, struct list_head *a, struct list_head *b)
+static int __init cmp(void *priv, const struct list_head *a,
+		      const struct list_head *b)
 {
 	struct debug_el *ela, *elb;
 
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index ee5ac40ea2b6..f8141443f2e2 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -397,8 +397,8 @@ static struct publication *tipc_service_remove_publ(struct service_range *sr,
  * Code reused: time_after32() for the same purpose
  */
 #define publication_after(pa, pb) time_after32((pa)->id, (pb)->id)
-static int tipc_publ_sort(void *priv, struct list_head *a,
-			  struct list_head *b)
+static int tipc_publ_sort(void *priv, const struct list_head *a,
+			  const struct list_head *b)
 {
 	struct publication *pa, *pb;
 
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:32 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:32 -0700
Subject: [PATCH v6 07/18] kallsyms: strip ThinLTO hashes from static functions
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-8-samitolvanen@google.com>

With CONFIG_CFI_CLANG and ThinLTO, Clang appends a hash to the names
of all static functions not marked __used. This can break userspace
tools that don't expect the function name to change, so strip out the
hash from the output.

Suggested-by: Jack Pham <jackp at codeaurora.org>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 kernel/kallsyms.c | 55 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 8043a90aa50e..c851ca0ed357 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -161,6 +161,27 @@ static unsigned long kallsyms_sym_address(int idx)
 	return kallsyms_relative_base - 1 - kallsyms_offsets[idx];
 }
 
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_LTO_CLANG_THIN)
+/*
+ * LLVM appends a hash to static function names when ThinLTO and CFI are
+ * both enabled, i.e. foo() becomes foo$707af9a22804d33c81801f27dcfe489b.
+ * This causes confusion and potentially breaks user space tools, so we
+ * strip the suffix from expanded symbol names.
+ */
+static inline bool cleanup_symbol_name(char *s)
+{
+	char *res;
+
+	res = strrchr(s, '$');
+	if (res)
+		*res = '\0';
+
+	return res != NULL;
+}
+#else
+static inline bool cleanup_symbol_name(char *s) { return false; }
+#endif
+
 /* Lookup the address for this symbol. Returns 0 if not found. */
 unsigned long kallsyms_lookup_name(const char *name)
 {
@@ -173,6 +194,9 @@ unsigned long kallsyms_lookup_name(const char *name)
 
 		if (strcmp(namebuf, name) == 0)
 			return kallsyms_sym_address(i);
+
+		if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0)
+			return kallsyms_sym_address(i);
 	}
 	return module_kallsyms_lookup_name(name);
 }
@@ -303,7 +327,9 @@ const char *kallsyms_lookup(unsigned long addr,
 				       namebuf, KSYM_NAME_LEN);
 		if (modname)
 			*modname = NULL;
-		return namebuf;
+
+		ret = namebuf;
+		goto found;
 	}
 
 	/* See if it's in a module or a BPF JITed image. */
@@ -316,11 +342,16 @@ const char *kallsyms_lookup(unsigned long addr,
 	if (!ret)
 		ret = ftrace_mod_address_lookup(addr, symbolsize,
 						offset, modname, namebuf);
+
+found:
+	cleanup_symbol_name(namebuf);
 	return ret;
 }
 
 int lookup_symbol_name(unsigned long addr, char *symname)
 {
+	int res;
+
 	symname[0] = '\0';
 	symname[KSYM_NAME_LEN - 1] = '\0';
 
@@ -331,15 +362,23 @@ int lookup_symbol_name(unsigned long addr, char *symname)
 		/* Grab name */
 		kallsyms_expand_symbol(get_symbol_offset(pos),
 				       symname, KSYM_NAME_LEN);
-		return 0;
+		goto found;
 	}
 	/* See if it's in a module. */
-	return lookup_module_symbol_name(addr, symname);
+	res = lookup_module_symbol_name(addr, symname);
+	if (res)
+		return res;
+
+found:
+	cleanup_symbol_name(symname);
+	return 0;
 }
 
 int lookup_symbol_attrs(unsigned long addr, unsigned long *size,
 			unsigned long *offset, char *modname, char *name)
 {
+	int res;
+
 	name[0] = '\0';
 	name[KSYM_NAME_LEN - 1] = '\0';
 
@@ -351,10 +390,16 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long *size,
 		kallsyms_expand_symbol(get_symbol_offset(pos),
 				       name, KSYM_NAME_LEN);
 		modname[0] = '\0';
-		return 0;
+		goto found;
 	}
 	/* See if it's in a module. */
-	return lookup_module_symbol_attrs(addr, size, offset, modname, name);
+	res = lookup_module_symbol_attrs(addr, size, offset, modname, name);
+	if (res)
+		return res;
+
+found:
+	cleanup_symbol_name(name);
+	return 0;
 }
 
 /* Look up a kernel symbol and return it in a text buffer. */
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:35 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:35 -0700
Subject: [PATCH v6 10/18] lkdtm: use function_nocfi
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-11-samitolvanen@google.com>

To ensure we take the actual address of a function in kernel text,
use function_nocfi. Otherwise, with CONFIG_CFI_CLANG, the compiler
replaces the address with a pointer to the CFI jump table, which is
actually in the module when compiled with CONFIG_LKDTM=m.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Acked-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 drivers/misc/lkdtm/usercopy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 109e8d4302c1..15d220ef35a5 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -314,7 +314,7 @@ void lkdtm_USERCOPY_KERNEL(void)
 
 	pr_info("attempting bad copy_to_user from kernel text: %px\n",
 		vm_mmap);
-	if (copy_to_user((void __user *)user_addr, vm_mmap,
+	if (copy_to_user((void __user *)user_addr, function_nocfi(vm_mmap),
 			 unconst + PAGE_SIZE)) {
 		pr_warn("copy_to_user failed, but lacked Oops\n");
 		goto free_user;
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:29 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:29 -0700
Subject: [PATCH v6 04/18] module: ensure __cfi_check alignment
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-5-samitolvanen@google.com>

CONFIG_CFI_CLANG_SHADOW assumes the __cfi_check() function is page
aligned and at the beginning of the .text section. While Clang would
normally align the function correctly, it fails to do so for modules
with no executable code.

This change ensures the correct __cfi_check() location and
alignment. It also discards the .eh_frame section, which Clang can
generate with certain sanitizers, such as CFI.

Link: https://bugs.llvm.org/show_bug.cgi?id=46293
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Jessica Yu <jeyu at kernel.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 scripts/module.lds.S | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 2c52535f9b56..04c5685c25cf 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -3,10 +3,20 @@
  * Archs are free to supply their own linker scripts.  ld will
  * combine them automatically.
  */
+#ifdef CONFIG_CFI_CLANG
+# include <asm/page.h>
+# define ALIGN_CFI 		ALIGN(PAGE_SIZE)
+# define SANITIZER_DISCARDS	*(.eh_frame)
+#else
+# define ALIGN_CFI
+# define SANITIZER_DISCARDS
+#endif
+
 SECTIONS {
 	/DISCARD/ : {
 		*(.discard)
 		*(.discard.*)
+		SANITIZER_DISCARDS
 	}
 
 	__ksymtab		0 : { *(SORT(___ksymtab+*)) }
@@ -41,7 +51,14 @@ SECTIONS {
 		*(.rodata..L*)
 	}
 
-	.text : { *(.text .text.[0-9a-zA-Z_]*) }
+	/*
+	 * With CONFIG_CFI_CLANG, we assume __cfi_check is at the beginning
+	 * of the .text section, and is aligned to PAGE_SIZE.
+	 */
+	.text : ALIGN_CFI {
+		*(.text.__cfi_check)
+		*(.text .text.[0-9a-zA-Z_]* .text..L.cfi*)
+	}
 #endif
 }
 
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:36 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:36 -0700
Subject: [PATCH v6 11/18] psci: use function_nocfi for cpu_resume
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-12-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function pointers with
jump table addresses, which results in __pa_symbol returning the
physical address of the jump table entry. As the jump table contains
an immediate jump to an EL1 virtual address, this typically won't
work as intended. Use function_nocfi to get the actual address of
cpu_resume.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 drivers/firmware/psci/psci.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f5fc429cae3f..64344e84bd63 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -325,8 +325,9 @@ static int __init psci_features(u32 psci_func_id)
 static int psci_suspend_finisher(unsigned long state)
 {
 	u32 power_state = state;
+	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
 
-	return psci_ops.cpu_suspend(power_state, __pa_symbol(cpu_resume));
+	return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
 }
 
 int psci_cpu_suspend_enter(u32 state)
@@ -344,8 +345,10 @@ int psci_cpu_suspend_enter(u32 state)
 
 static int psci_system_suspend(unsigned long unused)
 {
+	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+
 	return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
-			      __pa_symbol(cpu_resume), 0, 0);
+			      pa_cpu_resume, 0, 0);
 }
 
 static int psci_system_suspend_enter(suspend_state_t state)
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:37 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:37 -0700
Subject: [PATCH v6 12/18] arm64: implement function_nocfi
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-13-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function addresses in
instrumented C code with jump table addresses. This change implements
the function_nocfi() macro, which returns the actual function address
instead.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/include/asm/memory.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..3a6f9df63606 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -321,6 +321,22 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define virt_to_pfn(x)		__phys_to_pfn(__virt_to_phys((unsigned long)(x)))
 #define sym_to_pfn(x)		__phys_to_pfn(__pa_symbol(x))
 
+#ifdef CONFIG_CFI_CLANG
+/*
+ * With CONFIG_CFI_CLANG, the compiler replaces function address
+ * references with the address of the function's CFI jump table
+ * entry. The function_nocfi macro always returns the address of the
+ * actual function instead.
+ */
+#define function_nocfi(x) ({						\
+	void *addr;							\
+	asm("adrp %0, " __stringify(x) "\n\t"				\
+	    "add  %0, %0, :lo12:" __stringify(x)			\
+	    : "=r" (addr));						\
+	addr;								\
+})
+#endif
+
 /*
  *  virt_to_page(x)	convert a _valid_ virtual address to struct page *
  *  virt_addr_valid(x)	indicates whether a virtual address is valid
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:38 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:38 -0700
Subject: [PATCH v6 13/18] arm64: use function_nocfi with __pa_symbol
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-14-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function address
references with the address of the function's CFI jump table
entry. This means that __pa_symbol(function) returns the physical
address of the jump table entry, which can lead to address space
confusion as the jump table points to the function's virtual
address. Therefore, use the function_nocfi() macro to ensure we are
always taking the address of the actual function instead.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/include/asm/mmu_context.h      | 2 +-
 arch/arm64/kernel/acpi_parking_protocol.c | 3 ++-
 arch/arm64/kernel/cpu-reset.h             | 2 +-
 arch/arm64/kernel/cpufeature.c            | 2 +-
 arch/arm64/kernel/psci.c                  | 3 ++-
 arch/arm64/kernel/smp_spin_table.c        | 3 ++-
 6 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index bd02e99b1a4c..386b96400a57 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -140,7 +140,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 		ttbr1 |= TTBR_CNP_BIT;
 	}
 
-	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
+	replace_phys = (void *)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
 
 	cpu_install_idmap();
 	replace_phys(ttbr1);
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index e7c941d8340d..bfeeb5319abf 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -99,7 +99,8 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * that read this address need to convert this address to the
 	 * Boot-Loader's endianness before jumping.
 	 */
-	writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
+	writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
+		       &mailbox->entry_point);
 	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
 
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index ed50e9587ad8..f3adc574f969 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -22,7 +22,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long entry,
 
 	unsigned long el2_switch = !is_kernel_in_hyp_mode() &&
 		is_hyp_mode_available();
-	restart = (void *)__pa_symbol(__cpu_soft_restart);
+	restart = (void *)__pa_symbol(function_nocfi(__cpu_soft_restart));
 
 	cpu_install_idmap();
 	restart(el2_switch, entry, arg0, arg1, arg2);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e5281e1c8f1d..0b2e0d7b13ec 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1462,7 +1462,7 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 	if (arm64_use_ng_mappings)
 		return;
 
-	remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
+	remap_fn = (void *)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
 
 	cpu_install_idmap();
 	remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 62d2bda7adb8..ab7f4c476104 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -38,7 +38,8 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
 
 static int cpu_psci_cpu_boot(unsigned int cpu)
 {
-	int err = psci_ops.cpu_on(cpu_logical_map(cpu), __pa_symbol(secondary_entry));
+	phys_addr_t pa_secondary_entry = __pa_symbol(function_nocfi(secondary_entry));
+	int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);
 	if (err)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
 
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 056772c26098..c45a83512805 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -66,6 +66,7 @@ static int smp_spin_table_cpu_init(unsigned int cpu)
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
 	__le64 __iomem *release_addr;
+	phys_addr_t pa_holding_pen = __pa_symbol(function_nocfi(secondary_holding_pen));
 
 	if (!cpu_release_addr[cpu])
 		return -ENODEV;
@@ -88,7 +89,7 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
 	 * boot-loader's endianness before jumping. This is mandated by
 	 * the boot protocol.
 	 */
-	writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
+	writeq_relaxed(pa_holding_pen, release_addr);
 	__flush_dcache_area((__force void *)release_addr,
 			    sizeof(*release_addr));
 
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:40 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:40 -0700
Subject: [PATCH v6 15/18] arm64: add __nocfi to __apply_alternatives
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-16-samitolvanen@google.com>

__apply_alternatives makes indirect calls to functions whose address
is taken in assembly code using the alternative_cb macro. With
non-canonical CFI, the compiler won't replace these function
references with the jump table addresses, which trips CFI. Disable CFI
checking in the function to work around the issue.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/kernel/alternative.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 1184c44ea2c7..abc84636af07 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -133,8 +133,8 @@ static void clean_dcache_range_nopatch(u64 start, u64 end)
 	} while (cur += d_size, cur < end);
 }
 
-static void __apply_alternatives(void *alt_region,  bool is_module,
-				 unsigned long *feature_mask)
+static void __nocfi __apply_alternatives(void *alt_region,  bool is_module,
+					 unsigned long *feature_mask)
 {
 	struct alt_instr *alt;
 	struct alt_region *region = alt_region;
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:39 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:39 -0700
Subject: [PATCH v6 14/18] arm64: add __nocfi to functions that jump to a
 physical address
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-15-samitolvanen@google.com>

Disable CFI checking for functions that switch to linear mapping and
make an indirect call to a physical address, since the compiler only
understands virtual addresses and the CFI check for such indirect calls
would always fail.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/kernel/cpu-reset.h        | 8 ++++----
 arch/arm64/kernel/cpufeature.c       | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 386b96400a57..d3cef9133539 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -119,7 +119,7 @@ static inline void cpu_install_idmap(void)
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
  */
-static inline void cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
 {
 	typedef void (ttbr_replace_func)(phys_addr_t);
 	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index f3adc574f969..9a7b1262ef17 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -13,10 +13,10 @@
 void __cpu_soft_restart(unsigned long el2_switch, unsigned long entry,
 	unsigned long arg0, unsigned long arg1, unsigned long arg2);
 
-static inline void __noreturn cpu_soft_restart(unsigned long entry,
-					       unsigned long arg0,
-					       unsigned long arg1,
-					       unsigned long arg2)
+static inline void __noreturn __nocfi cpu_soft_restart(unsigned long entry,
+						       unsigned long arg0,
+						       unsigned long arg1,
+						       unsigned long arg2)
 {
 	typeof(__cpu_soft_restart) *restart;
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 0b2e0d7b13ec..c2f94a5206e0 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1445,7 +1445,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 }
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
-static void
+static void __nocfi
 kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 {
 	typedef void (kpti_remap_fn)(int, int, phys_addr_t);
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:41 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:41 -0700
Subject: [PATCH v6 16/18] arm64: ftrace: use function_nocfi for ftrace_call
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-17-samitolvanen@google.com>

With CONFIG_CFI_CLANG, the compiler replaces function pointers with
jump table addresses, which breaks dynamic ftrace as the address of
ftrace_call is replaced with the address of ftrace_call.cfi_jt. Use
function_nocfi() to get the address of the actual function instead.

Suggested-by: Ben Dai <ben.dai at unisoc.com>
Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/kernel/ftrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 86a5cf9bc19a..b5d3ddaf69d9 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -55,7 +55,7 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
 	unsigned long pc;
 	u32 new;
 
-	pc = (unsigned long)&ftrace_call;
+	pc = (unsigned long)function_nocfi(ftrace_call);
 	new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
 					  AARCH64_INSN_BRANCH_LINK);
 
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:42 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:42 -0700
Subject: [PATCH v6 17/18] KVM: arm64: Disable CFI for nVHE
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-18-samitolvanen@google.com>

Disable CFI for the nVHE code to avoid address space confusion.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/kvm/hyp/nvhe/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index a6707df4f6c0..fb24a0f022ad 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -75,9 +75,9 @@ quiet_cmd_hyprel = HYPREL  $@
 quiet_cmd_hypcopy = HYPCOPY $@
       cmd_hypcopy = $(OBJCOPY) --prefix-symbols=__kvm_nvhe_ $< $@
 
-# Remove ftrace and Shadow Call Stack CFLAGS.
-# This is equivalent to the 'notrace' and '__noscs' annotations.
-KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
+# Remove ftrace, Shadow Call Stack, and CFI CFLAGS.
+# This is equivalent to the 'notrace', '__noscs', and '__nocfi' annotations.
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS) $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
 
 # KVM nVHE code is run at a different exception code with a different map, so
 # compiler instrumentation that inserts callbacks or checks into the code may
-- 
2.31.1.295.g9ea45b61b8-goog



From samitolvanen at google.com  Thu Apr  8 19:28:43 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu,  8 Apr 2021 11:28:43 -0700
Subject: [PATCH v6 18/18] arm64: allow CONFIG_CFI_CLANG to be selected
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <20210408182843.1754385-19-samitolvanen@google.com>

Select ARCH_SUPPORTS_CFI_CLANG to allow CFI to be enabled.

Signed-off-by: Sami Tolvanen <samitolvanen at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
Tested-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..d7395772b6b8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -75,6 +75,7 @@ config ARM64
 	select ARCH_SUPPORTS_SHADOW_CALL_STACK if CC_HAVE_SHADOW_CALL_STACK
 	select ARCH_SUPPORTS_LTO_CLANG if CPU_LITTLE_ENDIAN
 	select ARCH_SUPPORTS_LTO_CLANG_THIN
+	select ARCH_SUPPORTS_CFI_CLANG
 	select ARCH_SUPPORTS_ATOMIC_RMW
 	select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && (GCC_VERSION >= 50000 || CC_IS_CLANG)
 	select ARCH_SUPPORTS_NUMA_BALANCING
-- 
2.31.1.295.g9ea45b61b8-goog



From robh at kernel.org  Thu Apr  8 19:38:17 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 13:38:17 -0500
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <20210408110800.GA32792@C02TD0UTHF1T.local>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
 <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
 <20210407124437.GA15622@willie-the-truck>
 <20210408110800.GA32792@C02TD0UTHF1T.local>
Message-ID: <CAL_Jsq+H_asWWrHiCk-PBS8xDEGpBL1__dRyrPXdBYgRBBw2vA@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > [Moving Mark to To: since I'd like his view on this]
> >
> > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
> > > >
> > > > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > > > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon <will at kernel.org> wrote:
> > > > > >
> > > > > > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > > > > > From: Raphael Gault <raphael.gault at arm.com>
>
> > > > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > > > > +{
> > > > > > > +     struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > > > > +
> > > > > > > +     if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > > > +             return;
> > > > > > > +
> > > > > > > +     if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > > > > +             on_each_cpu_mask(&armpmu->supported_cpus, refresh_pmuserenr, mm, 1);
> > > > > >
> > > > > > Given that the pmu_direct_access field is global per-mm, won't this go
> > > > > > wrong if multiple PMUs are opened by the same process but only a subset
> > > > > > are exposed to EL0? Perhaps pmu_direct_access should be treated as a mask
> > > > > > rather than a counter, so that we can 'and' it with the supported_cpus for
> > > > > > the PMU we're dealing with.
> > > > >
> > > > > It needs to be a count to support multiple events on the same PMU. If
> > > > > the event is not enabled for EL0, then we'd exit out on the
> > > > > ARMPMU_EL0_RD_CNTR check. So I think we're fine.
> > > >
> > > > I'm still not convinced; pmu_direct_access is shared between PMUs, so
> > > > testing the result of atomic_dec_and_test() just doesn't make sense to
> > > > me, as another PMU could be playing with the count.
> > >
> > > How is that a problem? Let's make a concrete example:
> > >
> > > map PMU1:event2 -> pmu_direct_access = 1 -> enable access
> > > map PMU2:event3 -> pmu_direct_access = 2
> > > map PMU1:event4 -> pmu_direct_access = 3
> > > unmap PMU2:event3 -> pmu_direct_access = 2
> > > unmap PMU1:event2 -> pmu_direct_access = 1
> > > unmap PMU1:event4 -> pmu_direct_access = 0 -> disable access
> > >
> > > The only issue I can see is PMU2 remains enabled for user access until
> > > the last unmap. But we're sharing the mm, so who cares? Also, in this
> > > scenario it is the user's problem to pin themselves to cores sharing a
> > > PMU. If the user doesn't do that, they get to keep the pieces.
> >
> > I guess I'm just worried about exposing the counters to userspace after
> > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > case we leak other events.
>
> IMO that's not practically different from the single-PMU case (i.e.
> multi-PMU isn't material, either we have a concern with leaking or we
> don't); more on that below.
>
> While it looks odd to place this on the mm, I don't think it's the end
> of the world.
>
> > However, I'm not sure how this is supposed to work normally: what
> > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > event while a task has a counter with direct access -- can that task
> > read the kernel event out of the PMU registers from userspace?
>
> Yes -- userspace could go read any counters even though it isn't
> supposed to, and could potentially infer information from those. It
> won't have access to the config registers or kernel data structures, so
> it isn't guaranteed to know what the even is or when it is
> context-switched/reprogrammed/etc.
>
> If we believe that's a problem, then it's difficult to do anything
> robust other than denying userspace access entirely, since disabling
> userspace access while in use would surprise applications, and denying
> privileged events would need some global state that we consult at event
> creation time (in addition to being an inversion of privilege).
>
> IIRC there was some fuss about this a while back on x86; I'll go dig and
> see what I can find, unless Peter has a memory...

Maybe this one[1].

Rob

[1] https://lore.kernel.org/lkml/20200730123815.18518-1-kan.liang at linux.intel.com/


From marex at denx.de  Thu Apr  8 19:57:25 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:25 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and GATE
 clock
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-2-marex@denx.de>

The ETHCK_K are modeled as composite clock of MUX and GATE, however per
STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. Peripheral
clock distribution for Ethernet, ETHPTPDIV divider is attached past the
ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN gate.
Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
in use, ETHCKEN gate can be turned off. Current driver does not permit
that, fix it.

This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent clock
to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
ETHPTP_K remain functional as before.

[1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
    Figure 83. Peripheral clock distribution for Ethernet
    https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 drivers/clk/clk-stm32mp1.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index a875649df8b8..a7c7f544ee5d 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -1949,7 +1949,6 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 	KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
 	KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
 	KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
-	KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
 
 	/* Particulary Kernel Clocks (no mux or no gate) */
 	MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
@@ -1958,11 +1957,16 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 	MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
 	MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
 
-	COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
+	COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
 		  CLK_SET_RATE_NO_REPARENT,
 		  _NO_GATE,
 		  _MMUX(M_ETHCK),
-		  _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
+		  _NO_DIV),
+
+	MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
+
+	DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |
+	    CLK_SET_RATE_NO_REPARENT, RCC_ETHCKSELR, 4, 4, 0),
 
 	/* RTC clock */
 	DIV(NO_ID, "ck_hse_rtc", "ck_hse", 0, RCC_RTCDIVR, 0, 6, 0),
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:24 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:24 +0200
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
Message-ID: <20210408185731.135511-1-marex@denx.de>

The implementation of ETH_RX_CLK/ETH_REF_CLK handling on STM32MP1 currently
does not permit selecting the RX clock input from SoC pad, the RX clock are
hard-wired to eth_clk_fb. This cover letter describes multiple unsuccessful
attempts at solving this problem and a proposed partial solution.

The problem is that in stm32mp151.dtsi, the "st,stm32mp1-dwmac" compatible
ethernet requests mac-clk-rx = <&rcc ETHRX> as MAC RX clock, which per [1]
page 576 maps to clk_rx_i signal. Upon closer inspection of clk-stm32mp1.c,
the ETHRX clock 1) only models G_ETHRX gate, which represents ETHRXEN bit,
and 2) sets ETHRX clock parent to ck_axi. Both are wrong for the following
reasons:
1) ETHRX clock are composite clock of gate and two muxes, which ultimately
   permit selecting ETHRX clock parent to be either eth_clk_fb or external
   ETH_RX_CLK/ETH_REF_CLOCK clock from SoC pad. Because only the gate part
   is modeled, the clock topology is wrong and it is not possible to select
   the ETHRX clock parent using the clock framework at all.
2) ETHRX clock are supplied from a mux controlled by ETH_SEL[2] (from
   SYSCFG), which is supplied from a mux controlled by ETH_REF_CLK_SEL
   (from SYSCFG), which is supplied either by ETH_RX_CLK/ETH_REF_CLK
   from pad OR internally from eth_clk_fb clock, which maps to ETHCK_K
   clock. Hence, ETHRX can never be supplied by ck_axi.

Another unique feature of ETHRX clock muxes is that they are controlled
via SYSCFG block instead of being part of the RCC block. This is a rather
unfortunate design, as it creates dependency between RCC, SYSCFG and DWMAC.
Currently, those clock muxes are configured in the dwmac4 driver through
syscon interface to SYSCFG block, based on custom device tree properties --
st,eth-clk-sel and st,eth-ref-clk-sel -- this is clearly not the correct
approach.

First approach was to implement ETHRX clock including muxes in clk-stm32mp1.c.
This means RCC clock driver, clk-stm32mp1.c, must obtain access to SYSCFG IP
registers via some syscon_regmap_lookup_by_phandle() when registering ETHRX
clock in RCC driver probe, so that it can read out SYSCFG register state to
determine the current mux state, and later toggle the mux bits. The problem
here is that the SYSCFG requires clock which are provided by RCC, so
syscon_regmap_lookup_by_phandle() fails with EPROBE_DEFER because the clock
are not available yet in RCC clock driver probe, so there is cyclic dependency
between RCC and SYSCFG.

Similar approach would be to turn SYSCFG into simple-bus and implement
separate SYSCFG clock sub-driver, which would register single clock mux with
two parents -- ETHCK_K and ETH_RX_CLK -- and would only control the SYSCFG
clock mux bits. The problem here is similar, for RCC driver to register the
ETHRX clock, the ETHRX clock must have a parent clock, however the parent
clock are not ready yet, because this new SYSCFG clock sub-driver requires
SYSCFG register clock, which only become available once RCC finishes probing,
so there again is a cyclic dependency between RCC and SYSCFG.

One possible solution could be to defer obtaining the SYSCFG regmap handle
until later point, i.e. only once a register access to SYSCFG is required
the first time. This could permit us to register the mux in the RCC driver
including a mux which requires SYSCFG access via syscon, although this would
likely still run into problems during probe, since the clock framework would
call .get_parent() during mux registration and trigger the SYSCFG access.

All the above still only discusses the clock part of the problem. Even if
the clock cyclic dependencies could be solved, it would be necessary to
resolve legacy dwmac st,eth-clk-sel and st,eth-ref-clk-sel DT properties
and avoid DT ABI break.

So in the end, this series takes a different approach and only partly solves
the problem. This series splits ETHCK_K, so the ETHCK_K gate could be turned
off and adds support for selecting ETHRX clock parent clock via DT. This then
permits e.g. DHCOM to select MCO2 as ETHRX clock source and the clock tree is
then correctly set up.

[1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
    Figure 83. Peripheral clock distribution for Ethernet
    https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf

Marek Vasut (7):
  clk: stm32mp1: Split ETHCK_K into separate MUX and GATE clock
  clk: stm32mp1: The dev is always NULL, replace it with np
  clk: stm32mp1: Register clock with device_node pointer
  clk: stm32mp1: Add parent_data to ETHRX clock
  ARM: dts: stm32: Add alternate pinmux for ethernet0 pins
  ARM: dts: stm32: Add alternate pinmux for mco2 pins
  ARM: dts: stm32: Switch DWMAC RMII clock to MCO2 on DHCOM

 arch/arm/boot/dts/stm32mp15-pinctrl.dtsi     |  49 +++++++
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi |  20 ++-
 drivers/clk/clk-stm32mp1.c                   | 134 +++++++++++--------
 3 files changed, 146 insertions(+), 57 deletions(-)

Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org

-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:27 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:27 +0200
Subject: [PATCH 3/7] clk: stm32mp1: Register clock with device_node pointer
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-4-marex@denx.de>

Use of_clk_hw_register() where applicable to associate device_node with
the newly registered clock, elsewhere use functions which permit passing
the device node to newly registered clock.

There are two exceptions, _clk_hw_register_fixed_factor() does not pass
the device_node pointer to new fixed factor clock and neither does
clk_stm32_register_composite(), because there is so far no way to do
that.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
NOTE: But if this patch is acceptable, the _clk_hw_register_fixed_factor()
      and clk_stm32_register_composite() can be easily fixed up too.
---
 drivers/clk/clk-stm32mp1.c | 44 ++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index cf5a1d055c5a..85bba1ee5fbd 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -384,14 +384,11 @@ _clk_hw_register_gate(struct device_node *np,
 {
 	struct gate_cfg *gate_cfg = cfg->cfg;
 
-	return clk_hw_register_gate(NULL,
-				    cfg->name,
-				    cfg->parent_name,
-				    cfg->flags,
-				    gate_cfg->reg_off + base,
-				    gate_cfg->bit_idx,
-				    gate_cfg->gate_flags,
-				    lock);
+	return __clk_hw_register_gate(NULL, np, cfg->name, cfg->parent_name,
+				      NULL, NULL, cfg->flags,
+				      gate_cfg->reg_off + base,
+				      gate_cfg->bit_idx,
+				      gate_cfg->gate_flags, lock);
 }
 
 static struct clk_hw *
@@ -415,16 +412,12 @@ _clk_hw_register_divider_table(struct device_node *np,
 {
 	struct div_cfg *div_cfg = cfg->cfg;
 
-	return clk_hw_register_divider_table(NULL,
-					     cfg->name,
-					     cfg->parent_name,
-					     cfg->flags,
-					     div_cfg->reg_off + base,
-					     div_cfg->shift,
-					     div_cfg->width,
-					     div_cfg->div_flags,
-					     div_cfg->table,
-					     lock);
+	return __clk_hw_register_divider(NULL, np, cfg->name, cfg->parent_name,
+					 NULL, NULL, cfg->flags,
+					 div_cfg->reg_off + base,
+					 div_cfg->shift, div_cfg->width,
+					 div_cfg->div_flags, div_cfg->table,
+					 lock);
 }
 
 static struct clk_hw *
@@ -435,10 +428,11 @@ _clk_hw_register_mux(struct device_node *np,
 {
 	struct mux_cfg *mux_cfg = cfg->cfg;
 
-	return clk_hw_register_mux(NULL, cfg->name, cfg->parent_names,
-				   cfg->num_parents, cfg->flags,
-				   mux_cfg->reg_off + base, mux_cfg->shift,
-				   mux_cfg->width, mux_cfg->mux_flags, lock);
+	return __clk_hw_register_mux(NULL, np, cfg->name, cfg->num_parents,
+				     cfg->parent_names, NULL, NULL, cfg->flags,
+				     mux_cfg->reg_off + base, mux_cfg->shift,
+				     BIT(mux_cfg->width) - 1,
+				     mux_cfg->mux_flags, NULL, lock);
 }
 
 /* MP1 Gate clock with set & clear registers */
@@ -598,7 +592,7 @@ clk_stm32_register_gate_ops(struct device_node *np,
 
 	hw->init = &init;
 
-	ret = clk_hw_register(NULL, hw);
+	ret = of_clk_hw_register(np, hw);
 	if (ret)
 		hw = ERR_PTR(ret);
 
@@ -889,7 +883,7 @@ static struct clk_hw *clk_register_pll(struct device_node *np, const char *name,
 	element->lock = lock;
 
 	hw = &element->hw;
-	err = clk_hw_register(NULL, hw);
+	err = of_clk_hw_register(np, hw);
 
 	if (err) {
 		kfree(element);
@@ -1021,7 +1015,7 @@ static struct clk_hw *clk_register_cktim(struct device_node *np, const char *nam
 	tim_ker->timpre = timpre;
 
 	hw = &tim_ker->hw;
-	err = clk_hw_register(NULL, hw);
+	err = of_clk_hw_register(np, hw);
 
 	if (err) {
 		kfree(tim_ker);
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:26 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:26 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it with np
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-3-marex@denx.de>

Instead of passing around $dev to all the registration functions, which
is always NULL, pass around struct device_node pointer $np. This way it
is possible to use of_clk_hw_register*() functions and/or register clock
with associated $np pointer.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 drivers/clk/clk-stm32mp1.c | 56 +++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index a7c7f544ee5d..cf5a1d055c5a 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -317,7 +317,7 @@ struct clock_config {
 	int num_parents;
 	unsigned long flags;
 	void *cfg;
-	struct clk_hw * (*func)(struct device *dev,
+	struct clk_hw * (*func)(struct device_node *np,
 				struct clk_hw_onecell_data *clk_data,
 				void __iomem *base, spinlock_t *lock,
 				const struct clock_config *cfg);
@@ -377,14 +377,14 @@ struct stm32_composite_cfg {
 };
 
 static struct clk_hw *
-_clk_hw_register_gate(struct device *dev,
+_clk_hw_register_gate(struct device_node *np,
 		      struct clk_hw_onecell_data *clk_data,
 		      void __iomem *base, spinlock_t *lock,
 		      const struct clock_config *cfg)
 {
 	struct gate_cfg *gate_cfg = cfg->cfg;
 
-	return clk_hw_register_gate(dev,
+	return clk_hw_register_gate(NULL,
 				    cfg->name,
 				    cfg->parent_name,
 				    cfg->flags,
@@ -395,27 +395,27 @@ _clk_hw_register_gate(struct device *dev,
 }
 
 static struct clk_hw *
-_clk_hw_register_fixed_factor(struct device *dev,
+_clk_hw_register_fixed_factor(struct device_node *np,
 			      struct clk_hw_onecell_data *clk_data,
 			      void __iomem *base, spinlock_t *lock,
 			      const struct clock_config *cfg)
 {
 	struct fixed_factor_cfg *ff_cfg = cfg->cfg;
 
-	return clk_hw_register_fixed_factor(dev, cfg->name, cfg->parent_name,
+	return clk_hw_register_fixed_factor(NULL, cfg->name, cfg->parent_name,
 					    cfg->flags, ff_cfg->mult,
 					    ff_cfg->div);
 }
 
 static struct clk_hw *
-_clk_hw_register_divider_table(struct device *dev,
+_clk_hw_register_divider_table(struct device_node *np,
 			       struct clk_hw_onecell_data *clk_data,
 			       void __iomem *base, spinlock_t *lock,
 			       const struct clock_config *cfg)
 {
 	struct div_cfg *div_cfg = cfg->cfg;
 
-	return clk_hw_register_divider_table(dev,
+	return clk_hw_register_divider_table(NULL,
 					     cfg->name,
 					     cfg->parent_name,
 					     cfg->flags,
@@ -428,14 +428,14 @@ _clk_hw_register_divider_table(struct device *dev,
 }
 
 static struct clk_hw *
-_clk_hw_register_mux(struct device *dev,
+_clk_hw_register_mux(struct device_node *np,
 		     struct clk_hw_onecell_data *clk_data,
 		     void __iomem *base, spinlock_t *lock,
 		     const struct clock_config *cfg)
 {
 	struct mux_cfg *mux_cfg = cfg->cfg;
 
-	return clk_hw_register_mux(dev, cfg->name, cfg->parent_names,
+	return clk_hw_register_mux(NULL, cfg->name, cfg->parent_names,
 				   cfg->num_parents, cfg->flags,
 				   mux_cfg->reg_off + base, mux_cfg->shift,
 				   mux_cfg->width, mux_cfg->mux_flags, lock);
@@ -570,7 +570,7 @@ _get_stm32_gate(void __iomem *base,
 }
 
 static struct clk_hw *
-clk_stm32_register_gate_ops(struct device *dev,
+clk_stm32_register_gate_ops(struct device_node *np,
 			    const char *name,
 			    const char *parent_name,
 			    unsigned long flags,
@@ -598,7 +598,7 @@ clk_stm32_register_gate_ops(struct device *dev,
 
 	hw->init = &init;
 
-	ret = clk_hw_register(dev, hw);
+	ret = clk_hw_register(NULL, hw);
 	if (ret)
 		hw = ERR_PTR(ret);
 
@@ -606,7 +606,7 @@ clk_stm32_register_gate_ops(struct device *dev,
 }
 
 static struct clk_hw *
-clk_stm32_register_composite(struct device *dev,
+clk_stm32_register_composite(struct device_node *np,
 			     const char *name, const char * const *parent_names,
 			     int num_parents, void __iomem *base,
 			     const struct stm32_composite_cfg *cfg,
@@ -655,7 +655,7 @@ clk_stm32_register_composite(struct device *dev,
 		}
 	}
 
-	return clk_hw_register_composite(dev, name, parent_names, num_parents,
+	return clk_hw_register_composite(NULL, name, parent_names, num_parents,
 				       mux_hw, mux_ops, div_hw, div_ops,
 				       gate_hw, gate_ops, flags);
 }
@@ -863,7 +863,7 @@ static const struct clk_ops pll_ops = {
 	.is_enabled	= pll_is_enabled,
 };
 
-static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
+static struct clk_hw *clk_register_pll(struct device_node *np, const char *name,
 				       const char *parent_name,
 				       void __iomem *reg,
 				       unsigned long flags,
@@ -889,7 +889,7 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	element->lock = lock;
 
 	hw = &element->hw;
-	err = clk_hw_register(dev, hw);
+	err = clk_hw_register(NULL, hw);
 
 	if (err) {
 		kfree(element);
@@ -993,7 +993,7 @@ static const struct clk_ops timer_ker_ops = {
 
 };
 
-static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
+static struct clk_hw *clk_register_cktim(struct device_node *np, const char *name,
 					 const char *parent_name,
 					 unsigned long flags,
 					 void __iomem *apbdiv,
@@ -1021,7 +1021,7 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	tim_ker->timpre = timpre;
 
 	hw = &tim_ker->hw;
-	err = clk_hw_register(dev, hw);
+	err = clk_hw_register(NULL, hw);
 
 	if (err) {
 		kfree(tim_ker);
@@ -1035,14 +1035,14 @@ struct stm32_pll_cfg {
 	u32 offset;
 };
 
-static struct clk_hw *_clk_register_pll(struct device *dev,
+static struct clk_hw *_clk_register_pll(struct device_node *np,
 					struct clk_hw_onecell_data *clk_data,
 					void __iomem *base, spinlock_t *lock,
 					const struct clock_config *cfg)
 {
 	struct stm32_pll_cfg *stm_pll_cfg = cfg->cfg;
 
-	return clk_register_pll(dev, cfg->name, cfg->parent_name,
+	return clk_register_pll(np, cfg->name, cfg->parent_name,
 				base + stm_pll_cfg->offset, cfg->flags, lock);
 }
 
@@ -1051,25 +1051,25 @@ struct stm32_cktim_cfg {
 	u32 offset_timpre;
 };
 
-static struct clk_hw *_clk_register_cktim(struct device *dev,
+static struct clk_hw *_clk_register_cktim(struct device_node *np,
 					  struct clk_hw_onecell_data *clk_data,
 					  void __iomem *base, spinlock_t *lock,
 					  const struct clock_config *cfg)
 {
 	struct stm32_cktim_cfg *cktim_cfg = cfg->cfg;
 
-	return clk_register_cktim(dev, cfg->name, cfg->parent_name, cfg->flags,
+	return clk_register_cktim(np, cfg->name, cfg->parent_name, cfg->flags,
 				  cktim_cfg->offset_apbdiv + base,
 				  cktim_cfg->offset_timpre + base, lock);
 }
 
 static struct clk_hw *
-_clk_stm32_register_gate(struct device *dev,
+_clk_stm32_register_gate(struct device_node *np,
 			 struct clk_hw_onecell_data *clk_data,
 			 void __iomem *base, spinlock_t *lock,
 			 const struct clock_config *cfg)
 {
-	return clk_stm32_register_gate_ops(dev,
+	return clk_stm32_register_gate_ops(np,
 				    cfg->name,
 				    cfg->parent_name,
 				    cfg->flags,
@@ -1079,12 +1079,12 @@ _clk_stm32_register_gate(struct device *dev,
 }
 
 static struct clk_hw *
-_clk_stm32_register_composite(struct device *dev,
+_clk_stm32_register_composite(struct device_node *np,
 			      struct clk_hw_onecell_data *clk_data,
 			      void __iomem *base, spinlock_t *lock,
 			      const struct clock_config *cfg)
 {
-	return clk_stm32_register_composite(dev, cfg->name, cfg->parent_names,
+	return clk_stm32_register_composite(np, cfg->name, cfg->parent_names,
 					    cfg->num_parents, base, cfg->cfg,
 					    cfg->flags, lock);
 }
@@ -2020,7 +2020,7 @@ static const struct of_device_id stm32mp1_match_data[] = {
 	{ }
 };
 
-static int stm32_register_hw_clk(struct device *dev,
+static int stm32_register_hw_clk(struct device_node *np,
 				 struct clk_hw_onecell_data *clk_data,
 				 void __iomem *base, spinlock_t *lock,
 				 const struct clock_config *cfg)
@@ -2031,7 +2031,7 @@ static int stm32_register_hw_clk(struct device *dev,
 	hws = clk_data->hws;
 
 	if (cfg->func)
-		hw = (*cfg->func)(dev, clk_data, base, lock, cfg);
+		hw = (*cfg->func)(np, clk_data, base, lock, cfg);
 
 	if (IS_ERR(hw)) {
 		pr_err("Unable to register %s\n", cfg->name);
@@ -2077,7 +2077,7 @@ static int stm32_rcc_init(struct device_node *np,
 		hws[n] = ERR_PTR(-ENOENT);
 
 	for (n = 0; n < data->num; n++) {
-		err = stm32_register_hw_clk(NULL, clk_data, base, &rlock,
+		err = stm32_register_hw_clk(np, clk_data, base, &rlock,
 					    &data->cfg[n]);
 		if (err) {
 			pr_err("%s: can't register  %s\n", __func__,
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:28 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:28 +0200
Subject: [PATCH 4/7] clk: stm32mp1: Add parent_data to ETHRX clock
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-5-marex@denx.de>

Pass parent_data to ETHRX clock with new fw_name = "ETH_RX_CLK/ETH_REF_CLK".
By default, this change has no impact on the operation of the clock driver.
However, due to the fw_name, it permits DT to override ETHRX clock parent,
which might be needed in case the ETHRX clock are supplied by external clock
source.

Example of MCO2 supplying clock to ETH_RX_CLK via external pad-to-pad wire:
&rcc {
         clocks = <&rcc CK_MCO2>;
         clock-names = "ETH_RX_CLK/ETH_REF_CLK";
};

Note that while this patch permits to implement this rare usecase, the issue
with ethernet RX and TX input clock modeling on MP1 is far more complex and
requires more core plumbing.

[1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
    Figure 83. Peripheral clock distribution for Ethernet
    https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 drivers/clk/clk-stm32mp1.c | 36 ++++++++++++++++++++++++++++++++----
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 85bba1ee5fbd..f9a9960945c6 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -152,6 +152,10 @@ static const char * const eth_src[] = {
 	"pll4_p", "pll3_q"
 };
 
+const struct clk_parent_data ethrx_src[] = {
+	{ .name = "ethck_k", .fw_name = "ETH_RX_CLK/ETH_REF_CLK" },
+};
+
 static const char * const rng_src[] = {
 	"ck_csi", "pll4_r", "ck_lse", "ck_lsi"
 };
@@ -314,6 +318,7 @@ struct clock_config {
 	const char *name;
 	const char *parent_name;
 	const char * const *parent_names;
+	const struct clk_parent_data *parent_data;
 	int num_parents;
 	unsigned long flags;
 	void *cfg;
@@ -567,6 +572,7 @@ static struct clk_hw *
 clk_stm32_register_gate_ops(struct device_node *np,
 			    const char *name,
 			    const char *parent_name,
+			    const struct clk_parent_data *parent_data,
 			    unsigned long flags,
 			    void __iomem *base,
 			    const struct stm32_gate_cfg *cfg,
@@ -577,7 +583,10 @@ clk_stm32_register_gate_ops(struct device_node *np,
 	int ret;
 
 	init.name = name;
-	init.parent_names = &parent_name;
+	if (parent_name)
+		init.parent_names = &parent_name;
+	if (parent_data)
+		init.parent_data = parent_data;
 	init.num_parents = 1;
 	init.flags = flags;
 
@@ -602,6 +611,7 @@ clk_stm32_register_gate_ops(struct device_node *np,
 static struct clk_hw *
 clk_stm32_register_composite(struct device_node *np,
 			     const char *name, const char * const *parent_names,
+			     const struct clk_parent_data *parent_data,
 			     int num_parents, void __iomem *base,
 			     const struct stm32_composite_cfg *cfg,
 			     unsigned long flags, spinlock_t *lock)
@@ -1066,6 +1076,7 @@ _clk_stm32_register_gate(struct device_node *np,
 	return clk_stm32_register_gate_ops(np,
 				    cfg->name,
 				    cfg->parent_name,
+				    cfg->parent_data,
 				    cfg->flags,
 				    base,
 				    cfg->cfg,
@@ -1079,8 +1090,8 @@ _clk_stm32_register_composite(struct device_node *np,
 			      const struct clock_config *cfg)
 {
 	return clk_stm32_register_composite(np, cfg->name, cfg->parent_names,
-					    cfg->num_parents, base, cfg->cfg,
-					    cfg->flags, lock);
+					    cfg->parent_data, cfg->num_parents,
+					    base, cfg->cfg, cfg->flags, lock);
 }
 
 #define GATE(_id, _name, _parent, _flags, _offset, _bit_idx, _gate_flags)\
@@ -1187,6 +1198,16 @@ _clk_stm32_register_composite(struct device_node *np,
 	.func		= _clk_stm32_register_gate,\
 }
 
+#define STM32_GATE_PDATA(_id, _name, _parent, _flags, _gate)\
+{\
+	.id		= _id,\
+	.name		= _name,\
+	.parent_data	= _parent,\
+	.flags		= _flags,\
+	.cfg		= (struct stm32_gate_cfg *) {_gate},\
+	.func		= _clk_stm32_register_gate,\
+}
+
 #define _STM32_GATE(_gate_offset, _gate_bit_idx, _gate_flags, _mgate, _ops)\
 	(&(struct stm32_gate_cfg) {\
 		&(struct gate_cfg) {\
@@ -1220,6 +1241,10 @@ _clk_stm32_register_composite(struct device_node *np,
 	STM32_GATE(_id, _name, _parent, _flags,\
 		   _STM32_MGATE(_mgate))
 
+#define MGATE_MP1_PDATA(_id, _name, _parent, _flags, _mgate)\
+	STM32_GATE_PDATA(_id, _name, _parent, _flags,\
+		   _STM32_MGATE(_mgate))
+
 #define _STM32_DIV(_div_offset, _div_shift, _div_width,\
 		   _div_flags, _div_table, _ops)\
 	.div = &(struct stm32_div_cfg) {\
@@ -1279,6 +1304,9 @@ _clk_stm32_register_composite(struct device_node *np,
 #define PCLK(_id, _name, _parent, _flags, _mgate)\
 	MGATE_MP1(_id, _name, _parent, _flags, _mgate)
 
+#define PCLK_PDATA(_id, _name, _parent, _flags, _mgate)\
+	MGATE_MP1_PDATA(_id, _name, _parent, _flags, _mgate)
+
 #define KCLK(_id, _name, _parents, _flags, _mgate, _mmux)\
 	     COMPOSITE(_id, _name, _parents, CLK_OPS_PARENT_ENABLE |\
 		       CLK_SET_RATE_NO_REPARENT | _flags,\
@@ -1886,7 +1914,7 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 	PCLK(MDMA, "mdma", "ck_axi", 0, G_MDMA),
 	PCLK(GPU, "gpu", "ck_axi", 0, G_GPU),
 	PCLK(ETHTX, "ethtx", "ck_axi", 0, G_ETHTX),
-	PCLK(ETHRX, "ethrx", "ck_axi", 0, G_ETHRX),
+	PCLK_PDATA(ETHRX, "ethrx", ethrx_src, 0, G_ETHRX),
 	PCLK(ETHMAC, "ethmac", "ck_axi", 0, G_ETHMAC),
 	PCLK(FMC, "fmc", "ck_axi", CLK_IGNORE_UNUSED, G_FMC),
 	PCLK(QSPI, "qspi", "ck_axi", CLK_IGNORE_UNUSED, G_QSPI),
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:29 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:29 +0200
Subject: [PATCH 5/7] ARM: dts: stm32: Add alternate pinmux for ethernet0 pins
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-6-marex@denx.de>

Add another mux option for ethernet0 pins, this is used on DHCOM when
the ethernet PHY 50 MHz clock is generated by the MCO2 on PG2 pin and
then fed back via PA1 pin.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 34 ++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 060baa8b7e9d..08ab62c9f254 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -305,6 +305,40 @@ pins1 {
 		};
 	};
 
+	ethernet0_rmii_pins_b: rmii-1 {
+		pins1 {
+			pinmux = <STM32_PINMUX('G', 13, AF11)>, /* ETH1_RMII_TXD0 */
+				 <STM32_PINMUX('G', 14, AF11)>, /* ETH1_RMII_TXD1 */
+				 <STM32_PINMUX('B', 11, AF11)>, /* ETH1_RMII_TX_EN */
+				 <STM32_PINMUX('A', 1, AF11)>,  /* ETH1_RMII_REF_CLK */
+				 <STM32_PINMUX('A', 2, AF11)>,  /* ETH1_MDIO */
+				 <STM32_PINMUX('C', 1, AF11)>;  /* ETH1_MDC */
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <2>;
+		};
+		pins2 {
+			pinmux = <STM32_PINMUX('C', 4, AF11)>,  /* ETH1_RMII_RXD0 */
+				 <STM32_PINMUX('C', 5, AF11)>,  /* ETH1_RMII_RXD1 */
+				 <STM32_PINMUX('A', 7, AF11)>;  /* ETH1_RMII_CRS_DV */
+			bias-disable;
+		};
+	};
+
+	ethernet0_rmii_sleep_pins_b: rmii-sleep-1 {
+		pins1 {
+			pinmux = <STM32_PINMUX('G', 13, ANALOG)>, /* ETH1_RMII_TXD0 */
+				 <STM32_PINMUX('G', 14, ANALOG)>, /* ETH1_RMII_TXD1 */
+				 <STM32_PINMUX('B', 11, ANALOG)>, /* ETH1_RMII_TX_EN */
+				 <STM32_PINMUX('A', 2, ANALOG)>,  /* ETH1_MDIO */
+				 <STM32_PINMUX('C', 1, ANALOG)>,  /* ETH1_MDC */
+				 <STM32_PINMUX('C', 4, ANALOG)>,  /* ETH1_RMII_RXD0 */
+				 <STM32_PINMUX('C', 5, ANALOG)>,  /* ETH1_RMII_RXD1 */
+				 <STM32_PINMUX('A', 1, ANALOG)>,  /* ETH1_RMII_REF_CLK */
+				 <STM32_PINMUX('A', 7, ANALOG)>;  /* ETH1_RMII_CRS_DV */
+		};
+	};
+
 	fmc_pins_a: fmc-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('D', 4, AF12)>, /* FMC_NOE */
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:30 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:30 +0200
Subject: [PATCH 6/7] ARM: dts: stm32: Add alternate pinmux for mco2 pins
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-7-marex@denx.de>

Add pinmux option for MCO2 pin. This is used on DHCOM when the
ethernet PHY 50 MHz clock is generated by the MCO2 on PG2 pin.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
index 08ab62c9f254..f003c05c24c3 100644
--- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
@@ -849,6 +849,21 @@ pins {
 		};
 	};
 
+	mco2_pins_a: mco2-0 {
+		pins {
+			pinmux = <STM32_PINMUX('G', 2, AF1)>; /* MCO2 */
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <2>;
+		};
+	};
+
+	mco2_sleep_pins_a: mco2-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('G', 2, ANALOG)>; /* MCO2 */
+		};
+	};
+
 	m_can1_pins_a: m-can1-0 {
 		pins1 {
 			pinmux = <STM32_PINMUX('H', 13, AF9)>; /* CAN1_TX */
-- 
2.30.2



From marex at denx.de  Thu Apr  8 19:57:31 2021
From: marex at denx.de (Marek Vasut)
Date: Thu,  8 Apr 2021 20:57:31 +0200
Subject: [PATCH 7/7] ARM: dts: stm32: Switch DWMAC RMII clock to MCO2 on DHCOM
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <20210408185731.135511-8-marex@denx.de>

The DHCOM SoM has two options for supplying ETHRX clock to the DWMAC
block and PHY. Either (1) ETHCK_K generates 50 MHz clock on ETH_CLK
pad for the PHY and the same 50 MHz clock are fed back to ETHRX via
internal eth_clk_fb clock connection OR (2) ETH_CLK is not used at
all, MCO2 generates 50 MHz clock on MCO2 output pad for the PHY and
the same MCO2 clock are fed back into ETHRX via ETH_RX_CLK input pad
using external pad-to-pad connection.

Option (1) has two downsides. ETHCK_K is supplied directly from either
PLL3_Q or PLL4_P, hence the PLL output is limited to exactly 50 MHz and
since the same PLL output is also used to supply SDMMC blocks, the
performance of SD and eMMC access is affected. The second downside is
that using this option, the EMI of the SoM is higher.

Option (2) solves both of those problems, so implement it here. In this
case, the PLL4_P is no longer limited and can be operated faster, at
100 MHz, which improves SDMMC performance (read performance is improved
from ~41 MiB/s to ~57 MiB/s with dd if=/dev/mmcblk1 of=/dev/null bs=64M
count=1). The EMI interference also decreases.

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Christophe Roullier <christophe.roullier at foss.st.com>
Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Cc: Patrice Chotard <patrice.chotard at foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
Cc: Stephen Boyd <swboyd at chromium.org>
Cc: linux-clk at vger.kernel.org
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
index 272a1a67a9ad..4c7c06a7aea0 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
@@ -114,15 +114,29 @@ &dts {
 	status = "okay";
 };
 
+&rcc {
+	/* Connect MCO2 output to ETH_RX_CLK input via pad-pad connection */
+	clocks = <&rcc CK_MCO2>;
+	clock-names = "ETH_RX_CLK/ETH_REF_CLK";
+
+	/*
+	 * Set PLL4P output to 100 MHz to supply SDMMC with faster clock,
+	 * set MCO2 output to 50 MHz to supply ETHRX clock with PLL4P/2,
+	 * so that MCO2 behaves as a divider for the ETHRX clock here.
+	 */
+	assigned-clocks = <&rcc CK_MCO2>, <&rcc PLL4_P>;
+	assigned-clock-parents = <&rcc PLL4_P>;
+	assigned-clock-rates = <50000000>, <100000000>;
+};
+
 &ethernet0 {
 	status = "okay";
-	pinctrl-0 = <&ethernet0_rmii_pins_a>;
-	pinctrl-1 = <&ethernet0_rmii_sleep_pins_a>;
+	pinctrl-0 = <&ethernet0_rmii_pins_b &mco2_pins_a>;
+	pinctrl-1 = <&ethernet0_rmii_sleep_pins_b &mco2_sleep_pins_a>;
 	pinctrl-names = "default", "sleep";
 	phy-mode = "rmii";
 	max-speed = <100>;
 	phy-handle = <&phy0>;
-	st,eth-ref-clk-sel;
 	phy-reset-gpios = <&gpioh 3 GPIO_ACTIVE_LOW>;
 
 	mdio0 {
-- 
2.30.2



From robh at kernel.org  Thu Apr  8 20:04:08 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 14:04:08 -0500
Subject: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
In-Reply-To: <20210406173836.GW2469518@zorba>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>
 <20210406173836.GW2469518@zorba>
Message-ID: <20210408190408.GA1724284@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 10:38:36AM -0700, Daniel Walker wrote:
> On Fri, Apr 02, 2021 at 03:18:21PM +0000, Christophe Leroy wrote:
> > -config CMDLINE_BOOL
> > -	bool "Built-in kernel command line"
> > -	help
> > -	  For most systems, it is firmware or second stage bootloader that
> > -	  by default specifies the kernel command line options.  However,
> > -	  it might be necessary or advantageous to either override the
> > -	  default kernel command line or add a few extra options to it.
> > -	  For such cases, this option allows you to hardcode your own
> > -	  command line options directly into the kernel.  For that, you
> > -	  should choose 'Y' here, and fill in the extra boot arguments
> > -	  in CONFIG_CMDLINE.
> > -
> > -	  The built-in options will be concatenated to the default command
> > -	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
> > -	  command line will be ignored and replaced by the built-in string.
> > -
> > -	  Most MIPS systems will normally expect 'N' here and rely upon
> > -	  the command line from the firmware or the second-stage bootloader.
> > -
> 
> 
> See how you complained that I have CMDLINE_BOOL in my changed, and you think it
> shouldn't exist.
> 
> Yet here mips has it, and you just deleted it with no feature parity in your
> changes for this.

AFAICT, CMDLINE_BOOL equates to a non-empty or empty CONFIG_CMDLINE. You 
seem to need it just because you have CMDLINE_PREPEND and 
CMDLINE_APPEND. If that's not it, what feature is missing? CMDLINE_BOOL 
is not a feature, but an implementation detail.

Rob


From madvenka at linux.microsoft.com  Thu Apr  8 20:23:39 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 8 Apr 2021 14:23:39 -0500
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210408165825.GP4516@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
 <20210408165825.GP4516@sirena.org.uk>
Message-ID: <eacc6098-a15f-c07a-2730-cb16cb8e1982@linux.microsoft.com>



On 4/8/21 11:58 AM, Mark Brown wrote:
> On Mon, Apr 05, 2021 at 03:43:12PM -0500, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>
>> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
>> for a function, the ftrace infrastructure is called for the function at
>> the very beginning. Ftrace creates two frames:
> 
> This looks good to me however I'd really like someone who has a firmer
> understanding of what ftrace is doing to double check as it is entirely
> likely that I am missing cases here, it seems likely that if I am
> missing stuff it's extra stuff that needs to be added and we're not
> actually making use of the reliability information yet.
> 

OK. So, do you have some specific reviewer(s) in mind? Apart from yourself, Mark Rutland and
Josh Poimboeuf, these are some reviewers I can think of (in alphabetical order):

AKASHI Takahiro <takahiro.akashi at linaro.org>
Ard Biesheuvel <ard.biesheuvel at linaro.org>
Catalin Marinas <catalin.marinas at arm.com>
Josh Poimboeuf <jpoimboe at redhat.com>
Steven Rostedt (VMware) <rostedt at goodmis.org>
Torsten Duwe <duwe at suse.de>
Will Deacon <will at kernel.org>

Sorry if I missed out any of the other experts.

Thanks.

Madhavan                                                 


From krzysztof.kozlowski at canonical.com  Thu Apr  8 20:25:28 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 8 Apr 2021 21:25:28 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
Message-ID: <70873555-ab01-feb0-536b-d4b60ac89768@canonical.com>

On 08/04/2021 17:08, Arnd Bergmann wrote:
> Greetings to all Arm platform maintainers,
> 
> I've just gone through the DT merges I've received so far and, with a
> little help from Rob,
> managed to run 'make dtbs_check W=1' before and after, to see what
> warnings we get.
> The good news is that the number of warnings is going down, but
> unfortunately there
> is still an unmanageable amount of remaining warnings, and some new
> ones crept in.
> 
> I'm still working on my tooling for this, to catch these better, but
> ideally I think we should
> try to not introduce new warnings. I think some platforms are already
> clean, and I did
> not see any new warnings for mvebu, samsung and broadcom. There were a lot of
> warnings from .dtsi files, and I probably did an incomplete job at
> deduplicating those.
> 
> See below for the other platforms, and the new warnings that I found.
> If these are
> valid, please send a fixup before the merge window, and let me know if
> you have ideas
> for how we should handle these in the future.
> 
> For this merge window, I don't think any of them are show-stoppers (Rob, let me
> know if you disagree), but in the long run we may want to gradually enforce
> a rule about not merging changes that introduce any new warnings, in order to
> have a chance of cleaning up the existing ones.

+1 for such rule, although the best would be to get a report about new
warnings on posted patches or shortly after applying, e.g. via 0-day
kbuild robot.

Best regards,
Krzysztof


From stefan.wahren at i2se.com  Thu Apr  8 20:29:06 2021
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 8 Apr 2021 21:29:06 +0200
Subject: [RFC PATCH] drivers: Raspbery Pi Sense Hat
In-Reply-To: <20210408000353.3571132-1-jsavitz@redhat.com>
References: <20210408000353.3571132-1-jsavitz@redhat.com>
Message-ID: <cb1c8254-adc2-14c5-8ce4-b15ab5c5f06e@i2se.com>

Hi Joel,

Am 08.04.21 um 02:03 schrieb Joel Savitz:
> From: Joel Savitz <joelsavitz at gmail.com>
>
> This is a forward port of the Rapsberry Pi Sense Hat driver from the
> downstream Raspberry Pi kernel tree.
>
> I have slightly consolidated things and done some quick testing of this
> driver on Fedora (which comes with the device tree blobs), and I want to
> do a bit more testing before submiting the driver for inclusion in
> mainline Linux.

at first some general comments:

- keep in mind that the drivers shouldn't make any assumption of the
target platform
- always run scripts/checkpatch.pl before submission

>
> I would like to get some feedback from the community on what may need to
> be improved, fixed, or changed as early as possible, so this is a request
> for comments.
>
> Signed-off-by: Joel Savitz <joelsavitz at gmail.com>
> ---
>  drivers/input/joystick/Kconfig       |   8 +
>  drivers/input/joystick/Makefile      |   1 +
>  drivers/input/joystick/rpisense-js.c | 147 ++++++++++++++
>  drivers/mfd/Kconfig                  |   8 +
>  drivers/mfd/Makefile                 |   1 +
>  drivers/mfd/rpisense-core.c          | 162 +++++++++++++++
>  drivers/video/fbdev/Kconfig          |  13 ++
>  drivers/video/fbdev/Makefile         |   1 +
>  drivers/video/fbdev/rpisense-fb.c    | 291 +++++++++++++++++++++++++++
>  include/linux/mfd/rpisense.h         |  66 ++++++
>  10 files changed, 698 insertions(+)
>  create mode 100644 drivers/input/joystick/rpisense-js.c
>  create mode 100644 drivers/mfd/rpisense-core.c
>  create mode 100644 drivers/video/fbdev/rpisense-fb.c
>  create mode 100644 include/linux/mfd/rpisense.h
>
> diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
> index 5e38899058c1..1c0025c22bf4 100644
> --- a/drivers/input/joystick/Kconfig
> +++ b/drivers/input/joystick/Kconfig
> @@ -389,4 +389,12 @@ config JOYSTICK_N64
>  	  Say Y here if you want enable support for the four
>  	  built-in controller ports on the Nintendo 64 console.
>  
> +config JOYSTICK_RPISENSE
> +	tristate "Raspberry Pi Sense HAT joystick"
> +	depends on GPIOLIB && INPUT
> +	select MFD_RPISENSE_CORE
> +
> +	help
> +	  This is the joystick driver for the Raspberry Pi Sense HAT
> +
>  endif
> diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
> index 31d720c9e493..b227e98cd179 100644
> --- a/drivers/input/joystick/Makefile
> +++ b/drivers/input/joystick/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_JOYSTICK_MAPLE)		+= maplecontrol.o
>  obj-$(CONFIG_JOYSTICK_N64)		+= n64joy.o
>  obj-$(CONFIG_JOYSTICK_PSXPAD_SPI)	+= psxpad-spi.o
>  obj-$(CONFIG_JOYSTICK_PXRC)		+= pxrc.o
> +obj-$(CONFIG_JOYSTICK_RPISENSE)         += rpisense-js.o
>  obj-$(CONFIG_JOYSTICK_SIDEWINDER)	+= sidewinder.o
>  obj-$(CONFIG_JOYSTICK_SPACEBALL)	+= spaceball.o
>  obj-$(CONFIG_JOYSTICK_SPACEORB)		+= spaceorb.o
> diff --git a/drivers/input/joystick/rpisense-js.c b/drivers/input/joystick/rpisense-js.c
> new file mode 100644
> index 000000000000..41d4bd1fed46
> --- /dev/null
> +++ b/drivers/input/joystick/rpisense-js.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Raspberry Pi Sense HAT joystick driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mfd/rpisense.h>
> +
> +static struct rpisense *rpisense;
please try to avoid such limitation. It's preferred to allow multiple
instances of input drivers.
> +static unsigned char keymap[5] = {KEY_DOWN, KEY_RIGHT, KEY_UP, KEY_ENTER, KEY_LEFT,};
please try to avoid magic numbers
> +
> +static void keys_work_fn(struct work_struct *work)
> +{
> +	int i;
> +	static s32 prev_keys;
> +	struct rpisense_js *rpisense_js = &rpisense->joystick;
> +	s32 keys = rpisense_reg_read(rpisense, RPISENSE_KEYS);
> +	s32 changes = keys ^ prev_keys;
> +
> +	prev_keys = keys;
> +	for (i = 0; i < 5; i++) {
> +		if (changes & 1) {
> +			input_report_key(rpisense_js->keys_dev,
> +					 keymap[i], keys & 1);
> +		}
> +		changes >>= 1;
> +		keys >>= 1;
> +	}
> +	input_sync(rpisense_js->keys_dev);
> +}
> +
> +static irqreturn_t keys_irq_handler(int irq, void *pdev)
> +{
> +	struct rpisense_js *rpisense_js = &rpisense->joystick;
> +
> +	schedule_work(&rpisense_js->keys_work_s);
> +	return IRQ_HANDLED;
> +}
> +
> +static int rpisense_js_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	int i;
> +	struct rpisense_js *rpisense_js;
> +
> +	rpisense = rpisense_get_dev();
> +	rpisense_js = &rpisense->joystick;
> +
> +	INIT_WORK(&rpisense_js->keys_work_s, keys_work_fn);
> +
> +	rpisense_js->keys_dev = input_allocate_device();
> +	if (!rpisense_js->keys_dev) {
> +		dev_err(&pdev->dev, "Could not allocate input device.\n");
> +		return -ENOMEM;
> +	}
> +
> +	rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY);
> +	for (i = 0; i < ARRAY_SIZE(keymap); i++) {
> +		set_bit(keymap[i],
> +			rpisense_js->keys_dev->keybit);
> +	}
> +
> +	rpisense_js->keys_dev->name = "Raspberry Pi Sense HAT Joystick";
> +	rpisense_js->keys_dev->phys = "rpi-sense-joy/input0";
> +	rpisense_js->keys_dev->id.bustype = BUS_I2C;
> +	rpisense_js->keys_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
> +	rpisense_js->keys_dev->keycode = keymap;
> +	rpisense_js->keys_dev->keycodesize = sizeof(unsigned char);
> +	rpisense_js->keys_dev->keycodemax = ARRAY_SIZE(keymap);
> +
> +	ret = input_register_device(rpisense_js->keys_dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Could not register input device.\n");
> +		goto err_keys_alloc;
> +	}
> +
> +	ret = gpiod_direction_input(rpisense_js->keys_desc);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Could not set keys-int direction.\n");
> +		goto err_keys_reg;
> +	}
> +
> +	rpisense_js->keys_irq = gpiod_to_irq(rpisense_js->keys_desc);
> +	if (rpisense_js->keys_irq < 0) {
> +		dev_err(&pdev->dev, "Could not determine keys-int IRQ.\n");
> +		ret = rpisense_js->keys_irq;
> +		goto err_keys_reg;
> +	}
> +
> +	ret = devm_request_irq(&pdev->dev, rpisense_js->keys_irq,
> +			       keys_irq_handler, IRQF_TRIGGER_RISING,
> +			       "keys", &pdev->dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "IRQ request failed.\n");
> +		goto err_keys_reg;
> +	}
> +	return 0;
> +err_keys_reg:
> +	input_unregister_device(rpisense_js->keys_dev);
> +err_keys_alloc:
> +	input_free_device(rpisense_js->keys_dev);
> +	return ret;
> +}
> +
> +static int rpisense_js_remove(struct platform_device *pdev)
> +{
> +	struct rpisense_js *rpisense_js = &rpisense->joystick;
> +
> +	input_unregister_device(rpisense_js->keys_dev);
> +	input_free_device(rpisense_js->keys_dev);
> +	return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id rpisense_js_id[] = {
> +	{ .compatible = "raspberrypi,rpi-sense-js" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, rpisense_js_id);
> +#endif
> +
> +static struct platform_device_id rpisense_js_device_id[] = {
> +	{ .name = "rpi-sense-js" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(platform, rpisense_js_device_id);
> +
> +static struct platform_driver rpisense_js_driver = {
> +	.probe = rpisense_js_probe,
> +	.remove = rpisense_js_remove,
> +	.driver = {
> +		.name = "rpi-sense-js",
> +		.owner = THIS_MODULE,
please drop this line
> +	},
> +};
> +
> +module_platform_driver(rpisense_js_driver);
> +
> +MODULE_DESCRIPTION("Raspberry Pi Sense HAT joystick driver");
> +MODULE_AUTHOR("Serge Schneider <serge at raspberrypi.org>");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b74efa469e90..8c309e389359 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -11,6 +11,14 @@ config MFD_CORE
>  	select IRQ_DOMAIN
>  	default n
>  
> +config MFD_RPISENSE_CORE
> +	tristate "Raspberry Pi Sense HAT core functions"
> +	depends on I2C
> +	select MFD_CORE
> +	help
> +	  This is the core driver for the Raspberry Pi Sense HAT. This provides
> +	  the necessary functions to communicate with the hardware.
> +
>  config MFD_CS5535
>  	tristate "AMD CS5535 and CS5536 southbridge core functions"
>  	select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 834f5463af28..7140a8fc36ee 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -263,6 +263,7 @@ obj-$(CONFIG_MFD_ROHM_BD71828)	+= rohm-bd71828.o
>  obj-$(CONFIG_MFD_ROHM_BD718XX)	+= rohm-bd718x7.o
>  obj-$(CONFIG_MFD_STMFX) 	+= stmfx.o
>  obj-$(CONFIG_MFD_KHADAS_MCU) 	+= khadas-mcu.o
> +obj-$(CONFIG_MFD_RPISENSE_CORE) += rpisense-core.o
>  obj-$(CONFIG_MFD_ACER_A500_EC)	+= acer-ec-a500.o
>  
>  obj-$(CONFIG_SGI_MFD_IOC3)	+= ioc3.o
> diff --git a/drivers/mfd/rpisense-core.c b/drivers/mfd/rpisense-core.c
> new file mode 100644
> index 000000000000..aa2c394c5e67
> --- /dev/null
> +++ b/drivers/mfd/rpisense-core.c
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Raspberry Pi Sense HAT core driver
> + * http://raspberrypi.org
> + *
> + * Copyright (C) 2015 Raspberry Pi
> + *
> + * Author: Serge Schneider
> + * Adapted for mainline Linux by: Joel Savitz
> + *
> + *  This driver is based on wm8350 implementation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +#include <linux/slab.h>
> +
> +#include <linux/mfd/rpisense.h>
> +
> +static struct rpisense *rpisense;
> +
> +static void rpisense_client_dev_register(struct rpisense *rpisense,
> +					 const char *name,
> +					 struct platform_device **pdev)
> +{
> +	int ret;
> +
> +	*pdev = platform_device_alloc(name, -1);
> +	if (*pdev == NULL) {
> +		dev_err(rpisense->dev, "Failed to allocate %s\n", name);
> +		return;
> +	}
> +
> +	(*pdev)->dev.parent = rpisense->dev;
> +	platform_set_drvdata(*pdev, rpisense);
> +	ret = platform_device_add(*pdev);
> +	if (ret != 0) {
> +		dev_err(rpisense->dev, "Failed to register %s: %d\n",
> +			name, ret);
> +		platform_device_put(*pdev);
> +		*pdev = NULL;
> +	}
> +}
> +
> +static int rpisense_probe(struct i2c_client *i2c,
> +			       const struct i2c_device_id *id)
> +{
> +	int ret;
> +	struct rpisense_js *rpisense_js;
> +
> +	rpisense = devm_kzalloc(&i2c->dev, sizeof(struct rpisense), GFP_KERNEL);
> +	if (rpisense == NULL)
> +		return -ENOMEM;
> +
> +	i2c_set_clientdata(i2c, rpisense);
> +	rpisense->dev = &i2c->dev;
> +	rpisense->i2c_client = i2c;
> +
> +	ret = rpisense_reg_read(rpisense, RPISENSE_WAI);
> +	if (ret > 0) {
> +		if (ret != 's')
> +			return -EINVAL;
this would be a good place for a error message like "Unable to detect
Raspberry Pi Sense HAT"
> +	} else {
> +		return ret;
> +	}
> +	ret = rpisense_reg_read(rpisense, RPISENSE_VER);
> +	if (ret < 0)
> +		return ret;
> +
> +	dev_info(rpisense->dev,
> +		 "Raspberry Pi Sense HAT firmware version %i\n", ret);
> +
> +	rpisense_js = &rpisense->joystick;
> +	rpisense_js->keys_desc = devm_gpiod_get(&i2c->dev,
> +						"keys-int", GPIOD_IN);
> +	if (IS_ERR(rpisense_js->keys_desc)) {
> +		dev_warn(&i2c->dev, "Failed to get keys-int descriptor.\n");
> +		rpisense_js->keys_desc = gpio_to_desc(23);
Unfortunately we cannot keep this fallback, because it's platform dependent.
> +		if (rpisense_js->keys_desc == NULL) {
> +			dev_err(&i2c->dev, "GPIO23 fallback failed.\n");
> +			return PTR_ERR(rpisense_js->keys_desc);
> +		}
> +	}
> +	rpisense_client_dev_register(rpisense, "rpi-sense-js",
> +				     &(rpisense->joystick.pdev));
> +	rpisense_client_dev_register(rpisense, "rpi-sense-fb",
> +				     &(rpisense->framebuffer.pdev));
> +
> +	return 0;
> +}
> +
> +static int rpisense_remove(struct i2c_client *i2c)
> +{
> +	struct rpisense *rpisense = i2c_get_clientdata(i2c);
> +
> +	platform_device_unregister(rpisense->joystick.pdev);
> +	return 0;
> +}
> +
> +struct rpisense *rpisense_get_dev(void)
> +{
> +	return rpisense;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_get_dev);
> +
> +s32 rpisense_reg_read(struct rpisense *rpisense, int reg)
> +{
> +	int ret = i2c_smbus_read_byte_data(rpisense->i2c_client, reg);
> +
> +	if (ret < 0)
> +		dev_err(rpisense->dev, "Read from reg %d failed\n", reg);
> +	/* Due to the BCM270x I2C clock stretching bug, some values
In upstream BCM283x is the more common naming for the SoC
> +	 * may have MSB set. Clear it to avoid incorrect values.
> +	 */
> +	return ret & 0x7F;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_reg_read);
> +
> +int rpisense_block_write(struct rpisense *rpisense, const char *buf, int count)
> +{
> +	int ret = i2c_master_send(rpisense->i2c_client, buf, count);
> +
> +	if (ret < 0)
> +		dev_err(rpisense->dev, "Block write failed\n");
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(rpisense_block_write);
> +
> +static const struct i2c_device_id rpisense_i2c_id[] = {
> +	{ "rpi-sense", 0 },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, rpisense_i2c_id);
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id rpisense_core_id[] = {
> +	{ .compatible = "raspberrypi,rpi-sense" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, rpisense_core_id);
> +#endif
> +
> +
> +static struct i2c_driver rpisense_driver = {
> +	.driver = {
> +		   .name = "rpi-sense",
> +		   .owner = THIS_MODULE,
please drop this line



From madvenka at linux.microsoft.com  Thu Apr  8 20:30:09 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 8 Apr 2021 14:30:09 -0500
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <20210408171715.GQ4516@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-2-madvenka@linux.microsoft.com>
 <20210408171715.GQ4516@sirena.org.uk>
Message-ID: <69b6924b-88f6-6c40-7b18-8cdf15d92bd1@linux.microsoft.com>



On 4/8/21 12:17 PM, Mark Brown wrote:
> On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka at linux.microsoft.com wrote:
> 
>> These checks will involve checking the return PC to see if it falls inside
>> any special functions where the stack trace is considered unreliable.
>> Implement the infrastructure needed for this.
> 
> Following up again based on an off-list discussion with Mark Rutland:
> while I think this is a reasonable implementation for specifically
> listing functions that cause problems we could make life easier for
> ourselves by instead using annotations at the call sites to put things
> into sections which indicate that they're unsafe for unwinding, we can
> then check for any address in one of those sections (or possibly do the
> reverse and check for any address in a section we specifically know is
> safe) rather than having to enumerate problematic functions in the
> unwinder.  This also has the advantage of not having a list that's
> separate to the functions themselves so it's less likely that the
> unwinder will get out of sync with the rest of the code as things evolve.
> 
> We already have SYM_CODE_START() annotations in the code for assembly
> functions that aren't using the standard calling convention which should
> help a lot here, we could add a variant of that for things that we know
> are safe on stacks (like those we expect to find at the bottom of
> stacks).
> 

As I already mentioned before, I like the idea of sections. The only reason that I did
not try it was that I have to address FTRACE trampolines and the kretprobe_trampoline
(and optprobes in the future).

I have the following options:

1. Create a common section (I will have to come up with an appropriate name) and put
   all such functions in that one section.

2. Create one section for each logical type (exception section, ftrace section and
   kprobe section) or some such.

3. Use the section idea only for the el1 exceptions. For the others use the current
   special_functions[] approach.

Which one do you and Mark Rutland prefer? Or, is there another choice?

Madhavan


From robh at kernel.org  Thu Apr  8 20:41:48 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 14:41:48 -0500
Subject: [PATCH v4 18/20] x86: Convert to GENERIC_CMDLINE
In-Reply-To: <ab0fd4477964cdbf99e3dd2965a455aa3e738e4b.1617375802.git.christophe.leroy@csgroup.eu>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <ab0fd4477964cdbf99e3dd2965a455aa3e738e4b.1617375802.git.christophe.leroy@csgroup.eu>
Message-ID: <20210408194148.GB1724284@robh.at.kernel.org>

On Fri, Apr 02, 2021 at 03:18:20PM +0000, Christophe Leroy wrote:
> This converts the architecture to GENERIC_CMDLINE.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
>  arch/x86/Kconfig        | 45 ++---------------------------------------
>  arch/x86/kernel/setup.c | 17 ++--------------
>  2 files changed, 4 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a20684d56b4b..66b384228ca3 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -104,6 +104,7 @@ config X86
>  	select ARCH_USE_QUEUED_SPINLOCKS
>  	select ARCH_USE_SYM_ANNOTATIONS
>  	select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
> +	select ARCH_WANT_CMDLINE_PREPEND_BY_DEFAULT

Seems to be non-existent kconfig option.

>  	select ARCH_WANT_DEFAULT_BPF_JIT	if X86_64
>  	select ARCH_WANTS_DYNAMIC_TASK_STRUCT
>  	select ARCH_WANT_HUGE_PMD_SHARE
> @@ -118,6 +119,7 @@ config X86
>  	select EDAC_SUPPORT
>  	select GENERIC_CLOCKEVENTS_BROADCAST	if X86_64 || (X86_32 && X86_LOCAL_APIC)
>  	select GENERIC_CLOCKEVENTS_MIN_ADJUST
> +	select GENERIC_CMDLINE
>  	select GENERIC_CMOS_UPDATE
>  	select GENERIC_CPU_AUTOPROBE
>  	select GENERIC_CPU_VULNERABILITIES
> @@ -2358,49 +2360,6 @@ choice
>  
>  endchoice
>  
> -config CMDLINE_BOOL
> -	bool "Built-in kernel command line"
> -	help
> -	  Allow for specifying boot arguments to the kernel at
> -	  build time.  On some systems (e.g. embedded ones), it is
> -	  necessary or convenient to provide some or all of the
> -	  kernel boot arguments with the kernel itself (that is,
> -	  to not rely on the boot loader to provide them.)
> -
> -	  To compile command line arguments into the kernel,
> -	  set this option to 'Y', then fill in the
> -	  boot arguments in CONFIG_CMDLINE.
> -
> -	  Systems with fully functional boot loaders (i.e. non-embedded)
> -	  should leave this option set to 'N'.
> -
> -config CMDLINE
> -	string "Built-in kernel command string"
> -	depends on CMDLINE_BOOL
> -	default ""
> -	help
> -	  Enter arguments here that should be compiled into the kernel
> -	  image and used at boot time.  If the boot loader provides a
> -	  command line at boot time, it is appended to this string to
> -	  form the full kernel command line, when the system boots.
> -
> -	  However, you can use the CONFIG_CMDLINE_FORCE option to
> -	  change this behavior.
> -
> -	  In most cases, the command line (whether built-in or provided
> -	  by the boot loader) should specify the device for the root
> -	  file system.
> -
> -config CMDLINE_FORCE
> -	bool "Built-in command line overrides boot loader arguments"
> -	depends on CMDLINE_BOOL && CMDLINE != ""
> -	help
> -	  Set this option to 'Y' to have the kernel ignore the boot loader
> -	  command line, and use ONLY the built-in command line.
> -
> -	  This is used to work around broken boot loaders.  This should
> -	  be set to 'N' under normal conditions.
> -
>  config MODIFY_LDT_SYSCALL
>  	bool "Enable the LDT (local descriptor table)" if EXPERT
>  	default y
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 6f2de58eeb54..3f274b02e51c 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -5,6 +5,7 @@
>   * This file contains the setup_arch() code, which handles the architecture-dependent
>   * parts of early kernel initialization.
>   */
> +#include <linux/cmdline.h>
>  #include <linux/console.h>
>  #include <linux/crash_dump.h>
>  #include <linux/dma-map-ops.h>
> @@ -161,9 +162,6 @@ unsigned long saved_video_mode;
>  #define RAMDISK_LOAD_FLAG		0x4000
>  
>  static char __initdata command_line[COMMAND_LINE_SIZE];
> -#ifdef CONFIG_CMDLINE_BOOL
> -static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
> -#endif
>  
>  #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
>  struct edd edd;
> @@ -883,18 +881,7 @@ void __init setup_arch(char **cmdline_p)
>  	bss_resource.start = __pa_symbol(__bss_start);
>  	bss_resource.end = __pa_symbol(__bss_stop)-1;
>  
> -#ifdef CONFIG_CMDLINE_BOOL
> -#ifdef CONFIG_CMDLINE_FORCE
> -	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> -	if (builtin_cmdline[0]) {
> -		/* append boot loader cmdline to builtin */
> -		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> -		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> -		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -	}
> -#endif
> -#endif
> +	cmdline_build(boot_command_line, boot_command_line);
>  
>  	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
>  	*cmdline_p = command_line;

Once this is all done, I wonder if we can get rid of the strlcpy and 
perhaps also cmdline_p.

Rob


From krzysztof.kozlowski at canonical.com  Thu Apr  8 20:50:29 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu,  8 Apr 2021 21:50:29 +0200
Subject: [PATCH] pinctrl: samsung: use 'int' for register masks in Exynos
Message-ID: <20210408195029.69974-1-krzysztof.kozlowski@canonical.com>

The Special Function Registers on all Exynos SoC, including ARM64, are
32-bit wide, so entire driver uses matching functions like readl() or
writel().  On 64-bit ARM using unsigned long for register masks:
1. makes little sense as immediately after bitwise operation it will be
   cast to 32-bit value when calling writel(),
2. is actually error-prone because it might promote other operands to
   64-bit.

Addresses-Coverity: Unintentional integer overflow
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

---

Not tested on ARM64.

Dear Linus,

Please apply it directly, I don't have any patches for Samsung pinctrl
in my tree.
---
 drivers/pinctrl/samsung/pinctrl-exynos.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0cd7f33cdf25..2b99f4130e1e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -55,7 +55,7 @@ static void exynos_irq_mask(struct irq_data *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 mask;
+	unsigned int mask;
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&bank->slock, flags);
@@ -83,7 +83,7 @@ static void exynos_irq_unmask(struct irq_data *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 mask;
+	unsigned int mask;
 	unsigned long flags;
 
 	/*
@@ -483,7 +483,7 @@ static void exynos_irq_eint0_15(struct irq_desc *desc)
 	chained_irq_exit(chip, desc);
 }
 
-static inline void exynos_irq_demux_eint(unsigned long pend,
+static inline void exynos_irq_demux_eint(unsigned int pend,
 						struct irq_domain *domain)
 {
 	unsigned int irq;
@@ -500,8 +500,8 @@ static void exynos_irq_demux_eint16_31(struct irq_desc *desc)
 {
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	struct exynos_muxed_weint_data *eintd = irq_desc_get_handler_data(desc);
-	unsigned long pend;
-	unsigned long mask;
+	unsigned int pend;
+	unsigned int mask;
 	int i;
 
 	chained_irq_enter(chip, desc);
-- 
2.25.1



From arnd at kernel.org  Thu Apr  8 20:59:06 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 21:59:06 +0200
Subject: [GIT PULL] Few more fixes for omaps for v5.12-rc cycle
In-Reply-To: <pull-1617702755-711306@atomide.com>
References: <pull-1617702755-711306@atomide.com>
Message-ID: <161791193691.1658989.4646630397638417333.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 6 Apr 2021 12:53:49 +0300, Tony Lindgren wrote:
> The following changes since commit b3d09a06d89f474cb52664e016849315a97e09d9:
> 
>   ARM: OMAP4: PM: update ROM return address for OSWR and OFF (2021-03-17 15:15:52 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.12/fixes-rc6-signed
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: b9a9786a13ea158ee3b23614217f2e3158178421

       Arnd


From arnd at kernel.org  Thu Apr  8 21:00:12 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:00:12 +0200
Subject: [GIT PULL] Apple M1 SoC platform bring-up for 5.13
In-Reply-To: <bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st>
References: <bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st>
Message-ID: <161791200652.1659138.4978126472531717438.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 00:55:28 +0900, Hector Martin wrote:
> Here's the final version of the M1 SoC bring-up series, based on
> v4 which was reviewed here:
> 
> https://lore.kernel.org/linux-arm-kernel/20210402090542.131194-1-marcan at marcan.st/T/#u
> 
> Changes since v4 as reviewed:
> 
> * Sort DT soc bus nodes by address (NFC)
> * Introduce defines to better represent the meaning of hwirq IDs in
>    the AIC driver (NFC)
> * Update stale comments in AIC (NFC)
> * Make of_mmio_is_nonposted static and not exported (export change only)
> * Rewrite pci_remap_cfgspace() more succintly using ?: operator (NFC)
> * Update FIQ series merge to arm64/for-next/fiq
> * Remove the nVHE series (we will let this go through amd64 on its own)
> 
> [...]

Merged into arm/apple-m1, thanks!

merge commit: 1bb2fd3880d479a7a1bf833baee731ae69f09060

       Arnd


From arnd at kernel.org  Thu Apr  8 21:03:32 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:03:32 +0200
Subject: [GIT PULL 3/3] ARM: samsung: mach/soc pull for v5.13
In-Reply-To: <20210407065828.7213-3-krzysztof.kozlowski@canonical.com>
References: <20210407065828.7213-1-krzysztof.kozlowski@canonical.com>
 <20210407065828.7213-3-krzysztof.kozlowski@canonical.com>
Message-ID: <161791219775.1659621.2558335087414364117.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 7 Apr 2021 08:58:28 +0200, Krzysztof Kozlowski wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.13
> 
> [...]

Merged into arm/soc, thanks!

merge commit: a0c97a6bd63019707f16d36812a5aa2fce3fe29f

       Arnd


From arnd at kernel.org  Thu Apr  8 21:03:33 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:03:33 +0200
Subject: [GIT PULL 1/3]
In-Reply-To: <pull-1617703816-65652@atomide.com>
References: <pull-1617703816-65652@atomide.com>
Message-ID: <161791219767.1659621.8262556060310725064.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 6 Apr 2021 13:10:58 +0300, Tony Lindgren wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/soc-signed
> 
> [...]

Merged into arm/soc, thanks!

merge commit: f47e8e14373a731ab4fbd08615b2694ce1fc5142

       Arnd


From arnd at kernel.org  Thu Apr  8 21:03:34 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:03:34 +0200
Subject: [GIT,PULL] arm: hisilicon: SoC updates for v5.13
In-Reply-To: <eba8b55e-0969-8ca2-eca3-7c471cb0ff6f@hisilicon.com>
References: <eba8b55e-0969-8ca2-eca3-7c471cb0ff6f@hisilicon.com>
Message-ID: <161791219759.1659621.15630743637327308533.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Sat, 3 Apr 2021 22:59:06 +0800, Wei Xu wrote:
> Please consider to pull the following changes.
> Thanks!
> 
> Best Regards,
> Wei

Merged into arm/soc, thanks!

merge commit: d74b25572a4f567b1a200a68dc0d9a9ec9d15390

       Arnd


From arnd at kernel.org  Thu Apr  8 21:04:44 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 8 Apr 2021 22:04:44 +0200
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <YG8qIfFdY+As5tye@builder.lan>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
 <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
 <YG8qIfFdY+As5tye@builder.lan>
Message-ID: <CAK8P3a2v6yUVi395ixJRer2wyNVNXB-uypCqw5ts327ST=fHPg@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:06 PM Bjorn Andersson
<bjorn.andersson at linaro.org> wrote:
> On Thu 08 Apr 10:24 CDT 2021, Arnd Bergmann wrote:
> > Maybe see if you can address these in a follow-up, to avoid regressions.
> >
>
> I'm about to send you a another set of pull requests with some more
> goodies that was lingering on the list. I will take a look to see if I
> can follow up on that with some fixes for above warnings - and take
> another look at incorporating dtbs_check in my workflow.

Ok, sounds good. As I mentioned, I'm also just learning how to use
dtbs_check properly. Unfortunately, it takes ages to run on a
non-parallel build,
and using 'make -j32' as I normally do means the output gets reordered
with every run.

It's probably ok if you figure out how to only run it for the files you
actually change in the Qualcomm tree.

       Arnd


From robh at kernel.org  Thu Apr  8 21:08:00 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 15:08:00 -0500
Subject: [RFC PATCH v6 1/1] cmdline: Add capability to both append and
 prepend at the same time
In-Reply-To: <34d20d1dbb88f26d418b33985557b0475374a1a5.1617556785.git.christophe.leroy@csgroup.eu>
References: <34d20d1dbb88f26d418b33985557b0475374a1a5.1617556785.git.christophe.leroy@csgroup.eu>
Message-ID: <CAL_JsqJ=UNfptbNHR5XAS9BQRv3C5+YonW9rwypA5gGt2N7bGQ@mail.gmail.com>

On Sun, Apr 4, 2021 at 12:20 PM Christophe Leroy
<christophe.leroy at csgroup.eu> wrote:
>
> One user has expressed the need to both append and prepend some
> built-in parameters to the command line provided by the bootloader.
>
> Allthough it is a corner case, it is easy to implement so let's do it.
>
> When the user chooses to prepend the bootloader provided command line
> with the built-in command line, he is offered the possibility to enter
> an additionnal built-in command line to be appended after the
> bootloader provided command line.
>
> It is a complementary feature which has no impact on the already
> existing ones and/or the existing defconfig.
>
> Suggested-by: Daniel Walker <danielwa at cisco.com>
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
> Sending this out as an RFC, applies on top of the series
> ("Implement GENERIC_CMDLINE"). I will add it to the series next spin
> unless someone is against it.

Well, it works, but you are working around the existing kconfig and
the result is not great. You'd never design it this way.

Rob


From arnd at kernel.org  Thu Apr  8 21:13:41 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 8 Apr 2021 22:13:41 +0200
Subject: [GIT PULL] arm64: dts: TI K3 updates for v5.13
In-Reply-To: <20210408163439.x7pz7bitwmu7aenl@freckled>
References: <20210405155336.smohb7uzkperqwuz@reflex>
 <161789493785.1630479.2066806618809349698.b4-ty@arndb.de>
 <20210408163439.x7pz7bitwmu7aenl@freckled>
Message-ID: <CAK8P3a0r3knGP5XxSz_K4zj4=iMNg_UysJLS8jdgqAZunLfLLw@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:34 PM Nishanth Menon <nm at ti.com> wrote:
> On 17:24-20210408, Arnd Bergmann wrote:
> >
> > ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus at f4000/interrupt-controller0: missing or empty reg/ranges property
> > ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus at f4000/dmss: missing or empty reg/ranges property
> > ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus at f4000/bus at 4000000/interrupt-controller1: missing or empty reg/ranges property
> >
> > ti/k3-am642-evm.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]}
> > ti/k3-am642-evm.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges':  'phandle': [[7]]}}
> > ti/k3-am642-evm.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
> > ti/k3-am642-evm.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > ti/k3-am642-sk.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ...
> > ti/k3-am642-sk.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ...
> > ti/k3-am642-sk.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
> > ti/k3-am642-sk.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > ti/k3-j7200-common-proc-board.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> >
> >
> > merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296
>
>
> We have a bunch of problems with interrupt controller definitions -
> attempts in [1] [2] did'nt seem to come to any form of conclusion yet.
>
> Cdns is a convert from txt to yaml and is queued on Marks' tree[3]

Ok, thanks for taking a look

> These issues pre-existed in existing definitions and/or convertion
> from txt and we are already working to make sure we try and reach a
> conclusion soon[4]. I am guessing from your note that it is high time we
> put our foot down on txt bindings and clean yamls, I will ensure we
> follow up on that.

I'm still trying to figure out how to best script it, my intention was to
only list issues that got introduced in the latest patches rather than
the existing problems.

On the other hand, it would indeed help to address any issues that
are going to come up in every newly added board first, and then
eventually get to all the remaining warnings for issues with the
yaml bindings.

       Arnd


From robh at kernel.org  Thu Apr  8 21:14:12 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 15:14:12 -0500
Subject: [PATCH v4 3/5] dt-bindings: add compatible vendor prefix for
 Forlinx
In-Reply-To: <20210407111428.3755684-4-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
 <20210407111428.3755684-4-i.uvarov@cognitivepilot.com>
Message-ID: <20210408201412.GA1887265@robh.at.kernel.org>

On Wed, 07 Apr 2021 14:14:26 +0300, Ivan Uvarov wrote:
> Baoding Forlinx Embedded Technology Co., Ltd. is the manufacturer of the
> Allwinner R40/A40i-powered FETA40i-C SoM and the OKA40i-C dev/carrier board
> based on it.
> 
> This patch adds the DT vendor prefix for Forlinx in preparation for a
> further patch, which includes a devicetree for the OKA40i-C board.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr  8 21:14:35 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 15:14:35 -0500
Subject: [PATCH v4 4/5] dt-bindings: arm: add compatible for Forlinx
 OKA40i-C and FETA40i-C
In-Reply-To: <20210407111428.3755684-5-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
 <20210407111428.3755684-5-i.uvarov@cognitivepilot.com>
Message-ID: <20210408201435.GA1887854@robh.at.kernel.org>

On Wed, 07 Apr 2021 14:14:27 +0300, Ivan Uvarov wrote:
> The FETA40i-C is a SoM by Forlinx based on the Allwinner R40/A40i SoC.
> The OKA40i-C is a carrier/development board by the same company based on
> this SoM.
> 
> This patch adds compatible strings for these two devices in preparation for
> the next patch containing a devicetree for them.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>
> 
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From arnd at kernel.org  Thu Apr  8 21:15:51 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 8 Apr 2021 22:15:51 +0200
Subject: [GIT PULL] ARM: at91: dt for 5.13
In-Reply-To: <71b2bd27-0d3b-3331-4f79-85b22594e20b@microchip.com>
References: <20210407114415.13180-1-nicolas.ferre@microchip.com>
 <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
 <71b2bd27-0d3b-3331-4f79-85b22594e20b@microchip.com>
Message-ID: <CAK8P3a1dyccHquEoSv4kECw-=RKNQAFVQap-DYTX-sDfwEPTGQ@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:35 PM Nicolas Ferre
<nicolas.ferre at microchip.com> wrote:
> On 08/04/2021 at 17:24, Arnd Bergmann wrote:
> Oh, got it: it's the upper case letter withing the etm hex address. I
> used this one to mach what was done in the reg property. I'm fixing both
> of them and sending the patch to the ml right now.

Ok

> Tell me if I add it to a subsequent pull-request or if you prefer to
> take it the soonest in order to not generate additional warnings upstream.

I'd like to have it before the merge window, but don't bother making it
an additional pull request if you already plan for another pull request with
5.13 material.

Thanks,

       Arnd


From krzysztof.kozlowski at canonical.com  Thu Apr  8 21:16:22 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu,  8 Apr 2021 22:16:22 +0200
Subject: [PATCH] iommu: exynos: remove unneeded local variable initialization
Message-ID: <20210408201622.78009-1-krzysztof.kozlowski@canonical.com>

The initialization of 'fault_addr' local variable is not needed as it is
shortly after overwritten.

Addresses-Coverity: Unused value
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/iommu/exynos-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index de324b4eedfe..8fa9a591fb96 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -407,7 +407,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	struct sysmmu_drvdata *data = dev_id;
 	const struct sysmmu_fault_info *finfo;
 	unsigned int i, n, itype;
-	sysmmu_iova_t fault_addr = -1;
+	sysmmu_iova_t fault_addr;
 	unsigned short reg_status, reg_clear;
 	int ret = -ENOSYS;
 
-- 
2.25.1



From arnd at kernel.org  Thu Apr  8 21:20:04 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:20:04 +0200
Subject: [GIT PULL] Qualcomm ARM64 defconfig udpate for 5.13
In-Reply-To: <20210404164841.712845-1-bjorn.andersson@linaro.org>
References: <20210404164841.712845-1-bjorn.andersson@linaro.org>
Message-ID: <161791320105.1663026.16468860660574153145.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Sun, 4 Apr 2021 11:48:41 -0500, Bjorn Andersson wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -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-5.13
> 
> [...]

Merged into arm/defconfig, thanks!

merge commit: d515102f56a02b68c5cc840880b45730736df73d

       Arnd


From arnd at kernel.org  Thu Apr  8 21:20:05 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:20:05 +0200
Subject: [GIT PULL 3/3]
In-Reply-To: <pull-1617703816-65652@atomide.com-3>
References: <pull-1617703816-65652@atomide.com>
 <pull-1617703816-65652@atomide.com-3>
Message-ID: <161791320105.1663026.3535744727493035044.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Tue, 6 Apr 2021 13:11:00 +0300, Tony Lindgren wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.13/defconfig-signed
> 
> [...]

Merged into arm/defconfig, thanks!

merge commit: 2de5bb995656312ac1464ee29294140e9aacd642

       Arnd


From arnd at kernel.org  Thu Apr  8 21:20:55 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu,  8 Apr 2021 22:20:55 +0200
Subject: [GIT PULL] ARM: mvebu: dt for v5.13 (#1)
In-Reply-To: <87v98xbzir.fsf@BL-laptop>
References: <87v98xbzir.fsf@BL-laptop>
Message-ID: <161791324990.1663215.15241029409271472842.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 07 Apr 2021 22:39:08 +0200, Gregory CLEMENT wrote:
> Here is the first pull request for dt for mvebu for v5.13.
> 
> This one is latter that the other ones, because I've just found a
> patch pending since December. I hope it is not too late.
> 
> Gregory
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
> [...]

Merged into arm/dt, thanks!

merge commit: e3e1276295a4c5eddc31dd297e8f6af275ca9c4f

       Arnd


From arnd at arndb.de  Thu Apr  8 21:29:15 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 Apr 2021 22:29:15 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
 <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>
Message-ID: <CAK8P3a3sqZBo8-zye1yiZuD2uMUr0oE_q_QfaK9K54TEgd1Cdw@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david at redhat.com> wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>>          bool "Aspeed display driver"
> >>>          select DRM_WANT_CMA
> >>>
> >>> config DRM_WANT_CMA
> >>>          bool
> >>>          help
> >>>             Select this from any driver that benefits from CMA being enabled
> >>>
> >>> config DMA_CMA
> >>>          bool "Use CMA helpers for DRM"
> >>>          default DRM_WANT_CMA
> >>>
> >>>            Arnd
> >>>
> >>
> >> That's precisely what I had first, with an additional "WANT_CMA" --  but
> >> looking at the number of such existing options (I was able to spot 1 !)
> >
> > If you do this it probably makes sense to fix a few other drivers
> > Kconfig in the process. It's not just a problem with your driver.
> > "my" drivers:
> >
>
> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
> into recursive dependencies ...
>
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig

Right, this is the main problem caused by using 'select' to
force-enable symbols that other drivers depend on.

Usually, the answer is to be consistent about the use of 'select'
and 'depends on', using the former only to enable symbols that
are hidden, while using 'depends on' for anything that is an
actual build time dependency.

> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?

I think in this case, it is fairly likely to work without DMA_CMA when the
probe function gets called during a fresh boot, but fairly likely to fail if
it gets called after the system has run for long enough to fragment the
free memory.

The point of DMA_CMA is to make it work reliably.

      Arnd


From sboyd at kernel.org  Thu Apr  8 21:32:23 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Thu, 08 Apr 2021 13:32:23 -0700
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <161791394374.3790633.266453595355045932@swboyd.mtv.corp.google.com>

Quoting Marek Vasut (2021-04-08 11:57:24)
> The implementation of ETH_RX_CLK/ETH_REF_CLK handling on STM32MP1 currently
> does not permit selecting the RX clock input from SoC pad, the RX clock are
> hard-wired to eth_clk_fb. This cover letter describes multiple unsuccessful
> attempts at solving this problem and a proposed partial solution.

Please use <sboyd at kernel.org> for clk patches, or run get_maintainer.pl


From nm at ti.com  Thu Apr  8 21:33:48 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 8 Apr 2021 15:33:48 -0500
Subject: [GIT PULL] arm64: dts: TI K3 updates for v5.13
In-Reply-To: <CAK8P3a0r3knGP5XxSz_K4zj4=iMNg_UysJLS8jdgqAZunLfLLw@mail.gmail.com>
References: <20210405155336.smohb7uzkperqwuz@reflex>
 <161789493785.1630479.2066806618809349698.b4-ty@arndb.de>
 <20210408163439.x7pz7bitwmu7aenl@freckled>
 <CAK8P3a0r3knGP5XxSz_K4zj4=iMNg_UysJLS8jdgqAZunLfLLw@mail.gmail.com>
Message-ID: <20210408203348.vafestu55hpw3zeq@bluff>

On 22:13-20210408, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:34 PM Nishanth Menon <nm at ti.com> wrote:
> > On 17:24-20210408, Arnd Bergmann wrote:
> > >
> > > ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): /bus at f4000/interrupt-controller0: missing or empty reg/ranges property
> > > ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus at f4000/dmss: missing or empty reg/ranges property
> > > ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): /bus at f4000/bus at 4000000/interrupt-controller1: missing or empty reg/ranges property
> > >
> > > ti/k3-am642-evm.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': [[5]]}
> > > ti/k3-am642-evm.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': [[2]], 'dma-ranges': True, 'ranges':  'phandle': [[7]]}}
> > > ti/k3-am642-evm.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
> > > ti/k3-am642-evm.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > > ti/k3-am642-sk.dt.yaml: bus at 4000000: interrupt-controller1: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], ...
> > > ti/k3-am642-sk.dt.yaml: bus at f4000: dmss: {'type': 'object'} is not allowed for {'compatible': ['simple-mfd'], ...
> > > ti/k3-am642-sk.dt.yaml: bus at f4000: interrupt-controller0: {'type': 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
> > > ti/k3-am642-sk.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > > ti/k3-j7200-common-proc-board.dt.yaml: flash at 0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > >
> > >
> > > merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296
> >
> >
> > We have a bunch of problems with interrupt controller definitions -
> > attempts in [1] [2] did'nt seem to come to any form of conclusion yet.
> >
> > Cdns is a convert from txt to yaml and is queued on Marks' tree[3]
> 
> Ok, thanks for taking a look
> 

Apologies on not flagging in my PR itself.

> > These issues pre-existed in existing definitions and/or convertion
> > from txt and we are already working to make sure we try and reach a
> > conclusion soon[4]. I am guessing from your note that it is high time we
> > put our foot down on txt bindings and clean yamls, I will ensure we
> > follow up on that.
> 
> I'm still trying to figure out how to best script it, my intention was to
> only list issues that got introduced in the latest patches rather than
> the existing problems.

I had done a bit of scripting around this already in my checker:
https://github.com/nmenon/kernel_patch_verify/blob/master/kernel_patch_verify#L212
Though it never works quite right all the time.. So, i do run explicit
checks afterwards to try and catch these.. and containerizing them
helped deployment aspects(developers having different schema package
versions) in control as well.

but yeah, a clean way of doing things still eludes me.

> 
> On the other hand, it would indeed help to address any issues that
> are going to come up in every newly added board first, and then
> eventually get to all the remaining warnings for issues with the
> yaml bindings.

yep, some of the troubles I had has relation to schema checks getting
stricter after I had queued things up, and then having to make a
choice :(. But internally, I am tracking those in our tracking system
and team has been given a headsup that we cleanup yamls before we add
any further nodes.

> 

The following also need to be converted to yaml (internal
JIRA tracking already done).

Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
Documentation/devicetree/bindings/gpio/gpio-davinci.txt
Documentation/devicetree/bindings/i2c/i2c-omap.txt
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
Documentation/devicetree/bindings/pci/pci-keystone.txt
Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
Documentation/devicetree/bindings/serial/omap_serial.txt
Documentation/devicetree/bindings/spi/omap-spi.txt

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


From robh at kernel.org  Thu Apr  8 21:43:54 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 15:43:54 -0500
Subject: [PATCH v2 1/6] dt-bindings: devapc: Update bindings
In-Reply-To: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <20210408204354.GA1926089@robh.at.kernel.org>

On Thu, Apr 01, 2021 at 02:38:02PM +0800, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>

Every change is an 'update'. Perhaps mention mt8192 in the subject.

> 
> To support newer hardware architecture of devapc,
> update device tree bindings.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---
>  Documentation/devicetree/bindings/soc/mediatek/devapc.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> index 31e4d3c..42b284e 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> @@ -20,11 +20,17 @@ properties:
>    compatible:
>      enum:
>        - mediatek,mt6779-devapc
> +      - mediatek,mt8192-devapc
>  
>    reg:
>      description: The base address of devapc register bank
>      maxItems: 1
>  
> +  vio-idx-num:

Needs a vendor prefix.

> +    description: The number of the devices controlled by devapc
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maxItems: 1
> +
>    interrupts:
>      description: A single interrupt specifier
>      maxItems: 1
> @@ -40,6 +46,7 @@ properties:
>  required:
>    - compatible
>    - reg
> +  - vio-idx-num
>    - interrupts
>    - clocks
>    - clock-names
> @@ -54,6 +61,7 @@ examples:
>      devapc: devapc at 10207000 {
>        compatible = "mediatek,mt6779-devapc";
>        reg = <0x10207000 0x1000>;
> +      vio-idx-num = <511>;
>        interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
>        clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>;
>        clock-names = "devapc-infra-clock";
> -- 
> 2.6.4
> 


From leoyang.li at nxp.com  Thu Apr  8 22:33:02 2021
From: leoyang.li at nxp.com (Li Yang)
Date: Thu, 8 Apr 2021 16:33:02 -0500
Subject: [PATCH v7] soc: fsl: enable acpi support in RCPM driver
In-Reply-To: <20210408030353.37193-1-ran.wang_1@nxp.com>
References: <20210408030353.37193-1-ran.wang_1@nxp.com>
Message-ID: <CADRPPNR4_rmPPrQ2mhVY1zqShTm4vdg_v4iAUt_gxdo7jmOg5Q@mail.gmail.com>

On Wed, Apr 7, 2021 at 9:58 PM Ran Wang <ran.wang_1 at nxp.com> wrote:
>
> From: Peng Ma <peng.ma at nxp.com>
>
> This patch enables ACPI support in RCPM driver.
>
> Signed-off-by: Peng Ma <peng.ma at nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1 at nxp.com>

Applied for next.  Thanks.

> ---
> Change in v7:
>  - Update comment for checking RCPM node which refferred to
>
> Change in v6:
>  - Remove copyright udpate to rebase on latest mainline
>
> Change in v5:
>  - Fix panic when dev->of_node is null
>
> Change in v4:
>  - Make commit subject more accurate
>  - Remove unrelated new blank line
>
> Change in v3:
>  - Add #ifdef CONFIG_ACPI for acpi_device_id
>  - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
>
> Change in v2:
>  - Update acpi_device_id to fix conflict with other driver
>
>  drivers/soc/fsl/rcpm.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
> index 4ace28cab314..90d3f4060b0c 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -13,6 +13,7 @@
>  #include <linux/slab.h>
>  #include <linux/suspend.h>
>  #include <linux/kernel.h>
> +#include <linux/acpi.h>
>
>  #define RCPM_WAKEUP_CELL_MAX_SIZE      7
>
> @@ -78,10 +79,20 @@ static int rcpm_pm_prepare(struct device *dev)
>                                 "fsl,rcpm-wakeup", value,
>                                 rcpm->wakeup_cells + 1);
>
> -               /*  Wakeup source should refer to current rcpm device */
> -               if (ret || (np->phandle != value[0]))
> +               if (ret)
>                         continue;
>
> +               /*
> +                * For DT mode, would handle devices with "fsl,rcpm-wakeup"
> +                * pointing to the current RCPM node.
> +                *
> +                * For ACPI mode, currently we assume there is only one
> +                * RCPM controller existing.
> +                */
> +               if (is_of_node(dev->fwnode))
> +                       if (np->phandle != value[0])
> +                               continue;
> +
>                 /* Property "#fsl,rcpm-wakeup-cells" of rcpm node defines the
>                  * number of IPPDEXPCR register cells, and "fsl,rcpm-wakeup"
>                  * of wakeup source IP contains an integer array: <phandle to
> @@ -172,10 +183,19 @@ static const struct of_device_id rcpm_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rcpm_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id rcpm_acpi_ids[] = {
> +       {"NXP0015",},
> +       { }
> +};
> +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
> +#endif
> +
>  static struct platform_driver rcpm_driver = {
>         .driver = {
>                 .name = "rcpm",
>                 .of_match_table = rcpm_of_match,
> +               .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
>                 .pm     = &rcpm_pm_ops,
>         },
>         .probe = rcpm_probe,
> --
> 2.25.1
>


From linus.walleij at linaro.org  Thu Apr  8 22:45:23 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 8 Apr 2021 23:45:23 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
 <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>
Message-ID: <CACRpkdbMLBzG_Q=-XzjsWvpofHyRv7sdB697mHLaRu4F=+GC-g@mail.gmail.com>

On Thu, Apr 8, 2021 at 6:44 PM David Hildenbrand <david at redhat.com> wrote:

> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
>
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?

It will mostly work but that is only because the reservations are
mostly contiguous anyway because they are done early and
are small. The hardware requires contiguous buffers in all
three cases. I'm not sure I always got it right.

> > certainly needs this as well, and pretty much anything that is
> > selecting DRM_KMS_CMA_HELPER or
> > DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> "wants" as in "desires to use but can life without" or "wants" as in
> "really needs it". ?

I don't know the exact semantics of using DRM_KMS_CMA*
without actually using DMA_CMA. I suspect small allocations
will be contiguous and big allocations will start to fragment?
but it's just my guess. I guess "really need it"?

Yours,
Linus Walleij


From arnd at kernel.org  Thu Apr  8 22:47:38 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 8 Apr 2021 23:47:38 +0200
Subject: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE
In-Reply-To: <20210408131010.1109027-4-maz@kernel.org>
References: <20210408131010.1109027-1-maz@kernel.org>
 <20210408131010.1109027-4-maz@kernel.org>
Message-ID: <CAK8P3a2+=LjnLtgvGx3s9i3X_9ypHZ6pEfObcjBtV2sVRrTmzw@mail.gmail.com>

On Thu, Apr 8, 2021 at 3:10 PM Marc Zyngier <maz at kernel.org> wrote:
>
> CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
> and has been enabled by default for almost all that time.
>
> Given that newer systems that are VHE capable are finally becoming
> available, and that some systems are even incapable of not running VHE,
> drop the configuration altogether.
>
> Anyone willing to stick to non-VHE on VHE hardware for obscure
> reasons should use the 'kvm-arm.mode=nvhe' command-line option.

Have you considered adding options to do the reverse logic for this
and other features, such as making support for the old non-VHE
optional at compile time?

I understand that so far the rule is (almost) always that an arm64 kernel
should run on any Armv8.0-A or higher system regardless of configuration,
but the now announced Armv9.0-A definition might be the chance to
introduce the concept of a minimum level the way we do on other
architectures (e.g. armv6/v6k/v7 or k8/pentium4/core2/atom/generic).

The way I can see this working would be to have a single user-visible
option that controls whether the kernel supports only Armv9.0-A/Armv8.5-A
and assumes all mandatory features of that are present, or it remains
as before and supports all implementations back to the first v8.

This would help eliminate the runtime detection for not just VHE but
also LSE, LPA, PAN, etc. Not sure how significant the cost of any of
those are in terms of runtime performance and/or code size, but it
would feel nice to be able to build a kernel that can actually rely
on sane hardware features even if it will take a few more years before
that hardware becomes common enough to actually get some distros
ship a kernel that requires v8.5/v9.0.

        Arnd


From dmitry.baryshkov at linaro.org  Thu Apr  8 22:53:12 2021
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 9 Apr 2021 00:53:12 +0300
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <CAK8P3a2v6yUVi395ixJRer2wyNVNXB-uypCqw5ts327ST=fHPg@mail.gmail.com>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
 <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
 <YG8qIfFdY+As5tye@builder.lan>
 <CAK8P3a2v6yUVi395ixJRer2wyNVNXB-uypCqw5ts327ST=fHPg@mail.gmail.com>
Message-ID: <CAA8EJpq4r0-XTouJTxnNdO8tgydenb+LjDykWORSNeLb3vSqMg@mail.gmail.com>

On Thu, 8 Apr 2021 at 23:05, Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Thu, Apr 8, 2021 at 6:06 PM Bjorn Andersson
> <bjorn.andersson at linaro.org> wrote:
> > On Thu 08 Apr 10:24 CDT 2021, Arnd Bergmann wrote:
> > > Maybe see if you can address these in a follow-up, to avoid regressions.
> > >
> >
> > I'm about to send you a another set of pull requests with some more
> > goodies that was lingering on the list. I will take a look to see if I
> > can follow up on that with some fixes for above warnings - and take
> > another look at incorporating dtbs_check in my workflow.
>
> Ok, sounds good. As I mentioned, I'm also just learning how to use
> dtbs_check properly. Unfortunately, it takes ages to run on a
> non-parallel build,
> and using 'make -j32' as I normally do means the output gets reordered
> with every run.
>
> It's probably ok if you figure out how to only run it for the files you
> actually change in the Qualcomm tree.

Disabling all non-Qualcomm arches makes `make dtbs_check` a little bit
less painful.

-- 
With best wishes
Dmitry


From linus.walleij at linaro.org  Thu Apr  8 23:11:43 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 9 Apr 2021 00:11:43 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
Message-ID: <CACRpkdZ8iDwH5EPiZxGzEU5p-69A5X+MUEskooe21u_j12n5Ww@mail.gmail.com>

On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:

> arch/arm/boot/dts/ste-href520-tvk.dt.yaml: accelerometer at 19:
> interrupts: [[18, 1], [19, 1]] is too long
> arch/arm/boot/dts/ste-hrefprev60-tvk.dt.yaml: gyroscope at 68:
> interrupts-extended: [[22, 0, 1], [21, 31, 1]] is too long
> arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: gyroscope at 68:
> interrupts-extended: [[25, 0, 1], [24, 31, 1]] is too long
> arch/arm/boot/dts/ste-hrefv60plus-tvk.dt.yaml: accelerometer at 1c:
> interrupts: [[18, 1], [19, 1]] is too long

These warnings are all because the bindings in
Documentation/devicetree/bindings/iio/st,st-sensors.yaml
are slightly incorrect. Several sensors have more than 1 IRQ.

I was working on a refined version of the bindings but got
sidetracked.
https://lore.kernel.org/linux-iio/20210104093343.2134410-1-linus.walleij at linaro.org/

I'll try to get to it.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr  8 23:14:26 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 9 Apr 2021 00:14:26 +0200
Subject: [GIT PULL] Apple M1 SoC platform bring-up for 5.13
In-Reply-To: <bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st>
References: <bdb18e9f-fcd7-1e31-2224-19c0e5090706@marcan.st>
Message-ID: <CACRpkdaijbDoV2rSQsgO3XKnj_Hde8CU9JQ+V9gGePYjvCWJhA@mail.gmail.com>

On Thu, Apr 8, 2021 at 5:55 PM Hector Martin <marcan at marcan.st> wrote:

> Hi Arnd and all,
>
> Here's the final version of the M1 SoC bring-up series, based on
> v4 which was reviewed here:
>
> https://lore.kernel.org/linux-arm-kernel/20210402090542.131194-1-marcan at marcan.st/T/#u

Excellent work on this series Hector, thanks for working so hard on this!

Yours,
Linus Walleij


From lkp at intel.com  Thu Apr  8 23:25:47 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 9 Apr 2021 06:25:47 +0800
Subject: [soc:socfpga/drivers-2 10/16] drivers/clk/socfpga/clk-gate.c:102:7:
 warning: cast to smaller integer type 'int' from 'void *'
Message-ID: <202104090637.L7vdvTaA-lkp@intel.com>

Hi Krzysztof,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git socfpga/drivers-2
head:   38ad957b04c5c2c9effc6336365187dae1301051
commit: 552418658acd6302e971c7137cb7d3108e464829 [10/16] clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile test)
config: arm64-randconfig-r016-20210408 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 56ea2e2fdd691136d5e6631fa0e447173694b82c)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=552418658acd6302e971c7137cb7d3108e464829
        git remote add soc https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
        git fetch --no-tags soc socfpga/drivers-2
        git checkout 552418658acd6302e971c7137cb7d3108e464829
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/clk/socfpga/clk-gate.c:102:7: warning: cast to smaller integer type 'int' from 'void *' [-Wvoid-pointer-to-int-cast]
                   if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
                       ^~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning generated.


vim +102 drivers/clk/socfpga/clk-gate.c

97259e99bdc914 Steffen Trumtrar 2014-01-06   89  
97259e99bdc914 Steffen Trumtrar 2014-01-06   90  static unsigned long socfpga_clk_recalc_rate(struct clk_hw *hwclk,
97259e99bdc914 Steffen Trumtrar 2014-01-06   91  	unsigned long parent_rate)
97259e99bdc914 Steffen Trumtrar 2014-01-06   92  {
97259e99bdc914 Steffen Trumtrar 2014-01-06   93  	struct socfpga_gate_clk *socfpgaclk = to_socfpga_gate_clk(hwclk);
97259e99bdc914 Steffen Trumtrar 2014-01-06   94  	u32 div = 1, val;
97259e99bdc914 Steffen Trumtrar 2014-01-06   95  
97259e99bdc914 Steffen Trumtrar 2014-01-06   96  	if (socfpgaclk->fixed_div)
97259e99bdc914 Steffen Trumtrar 2014-01-06   97  		div = socfpgaclk->fixed_div;
97259e99bdc914 Steffen Trumtrar 2014-01-06   98  	else if (socfpgaclk->div_reg) {
97259e99bdc914 Steffen Trumtrar 2014-01-06   99  		val = readl(socfpgaclk->div_reg) >> socfpgaclk->shift;
25d4d341d31b34 Andy Shevchenko  2015-07-13  100  		val &= GENMASK(socfpgaclk->width - 1, 0);
97259e99bdc914 Steffen Trumtrar 2014-01-06  101  		/* Check for GPIO_DB_CLK by its offset */
97259e99bdc914 Steffen Trumtrar 2014-01-06 @102  		if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
97259e99bdc914 Steffen Trumtrar 2014-01-06  103  			div = val + 1;
97259e99bdc914 Steffen Trumtrar 2014-01-06  104  		else
97259e99bdc914 Steffen Trumtrar 2014-01-06  105  			div = (1 << val);
97259e99bdc914 Steffen Trumtrar 2014-01-06  106  	}
97259e99bdc914 Steffen Trumtrar 2014-01-06  107  
97259e99bdc914 Steffen Trumtrar 2014-01-06  108  	return parent_rate / div;
97259e99bdc914 Steffen Trumtrar 2014-01-06  109  }
97259e99bdc914 Steffen Trumtrar 2014-01-06  110  

:::::: The code at line 102 was first introduced by commit
:::::: 97259e99bdc9144d071815536f1dbc2e41c6b5a8 clk: socfpga: split clk code

:::::: TO: Steffen Trumtrar <s.trumtrar at pengutronix.de>
:::::: CC: Mike Turquette <mturquette at linaro.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 41886 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/b8d8aa9d/attachment-0001.gz>

From keescook at chromium.org  Thu Apr  8 23:59:53 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu, 8 Apr 2021 15:59:53 -0700
Subject: [PATCH v6 00/18] Add support for Clang CFI
In-Reply-To: <20210408182843.1754385-1-samitolvanen@google.com>
References: <20210408182843.1754385-1-samitolvanen@google.com>
Message-ID: <202104081558.9A5FE3A@keescook>

On Thu, Apr 08, 2021 at 11:28:25AM -0700, Sami Tolvanen wrote:
> This series adds support for Clang's Control-Flow Integrity (CFI)
> checking. With CFI, the compiler injects a runtime check before 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. For more details, see:
> 
>   https://clang.llvm.org/docs/ControlFlowIntegrity.html
> 
> The first patch contains build system changes and error handling,
> and implements support for cross-module indirect call checking. The
> remaining patches address issues caused by the compiler
> instrumentation. These include fixing known type mismatches, as well
> as issues with address space confusion and cross-module function
> address equality.
> 
> These patches add support only for arm64, but I'll post patches also
> for x86_64 after we address the remaining issues there, including
> objtool support.
> 
> You can also pull this series from
> 
>   https://github.com/samitolvanen/linux.git cfi-v6

This is working quite well for me and it looks like there are
good reviews. I'm going to toss it in linux-next unless anyone has
objections. I'm very excited to start using this. :)

-Kees

-- 
Kees Cook


From marex at denx.de  Fri Apr  9 00:00:01 2021
From: marex at denx.de (Marek Vasut)
Date: Fri,  9 Apr 2021 01:00:01 +0200
Subject: [PATCH] ARM: dts: stm32: Rework LAN8710Ai PHY reset on DHCOM SoM
Message-ID: <20210408230001.310215-1-marex@denx.de>

The Microchip LAN8710Ai PHY requires XTAL1/CLKIN external clock to be
enabled when the nRST is toggled according to datasheet Microchip
LAN8710A/LAN8710Ai DS00002164B page 35 section 3.8.5.1 Hardware Reset:
  "
  A Hardware reset is asserted by driving the nRST input pin low. When
  driven, nRST should be held low for the minimum time detailed in
  Section 5.5.3, "Power-On nRST & Configuration Strap Timing," on page
  59 to ensure a proper transceiver reset. During a Hardware reset, an
  external clock must be supplied to the XTAL1/CLKIN signal.
  "
This is accidentally fulfilled in the current setup, where ETHCK_K is used
to supply both PHY XTAL1/CLKIN and is also fed back through eth_clk_fb to
supply ETHRX clock of the DWMAC. Hence, the DWMAC enables ETHRX clock,
that has ETHCK_K as parent, so ETHCK_K clock are also enabled, and then
the PHY reset toggles.

However, this is not always the case, e.g. in case the PHY XTAL1/CLKIN
clock are supplied by some other clock source than ETHCK_K or in case
ETHRX clock are not supplied by ETHCK_K. In the later case, ETHCK_K would
be kept disabled, while ETHRX clock would be enabled, so the PHY would
not be receiving XTAL1/CLKIN clock and the reset would fail.

Improve the DT by adding the PHY clock phandle into the PHY node, which
then also requires moving the PHY reset GPIO specifier in the same place
and that then also requires correct PHY reset GPIO timing, so add that
too.

A brief note regarding the timing, the datasheet says the reset should
stay asserted for at least 100uS and software should wait at least 200nS
after deassertion. Set both delays to 500uS which should be plenty.

Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at st.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: Patrick Delaunay <patrick.delaunay at st.com>
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
index 272a1a67a9ad..31d08423a32f 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
@@ -123,7 +123,6 @@ &ethernet0 {
 	max-speed = <100>;
 	phy-handle = <&phy0>;
 	st,eth-ref-clk-sel;
-	phy-reset-gpios = <&gpioh 3 GPIO_ACTIVE_LOW>;
 
 	mdio0 {
 		#address-cells = <1>;
@@ -132,6 +131,13 @@ mdio0 {
 
 		phy0: ethernet-phy at 1 {
 			reg = <1>;
+			/* LAN8710Ai */
+			compatible = "ethernet-phy-id0007.c0f0",
+				     "ethernet-phy-ieee802.3-c22";
+			clocks = <&rcc ETHCK_K>;
+			reset-gpios = <&gpioh 3 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <500>;
+			reset-deassert-us = <500>;
 			interrupt-parent = <&gpioi>;
 			interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 		};
-- 
2.30.2



From bjorn.andersson at linaro.org  Fri Apr  9 00:05:22 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Thu, 8 Apr 2021 18:05:22 -0500
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <CAA8EJpq4r0-XTouJTxnNdO8tgydenb+LjDykWORSNeLb3vSqMg@mail.gmail.com>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
 <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
 <YG8qIfFdY+As5tye@builder.lan>
 <CAK8P3a2v6yUVi395ixJRer2wyNVNXB-uypCqw5ts327ST=fHPg@mail.gmail.com>
 <CAA8EJpq4r0-XTouJTxnNdO8tgydenb+LjDykWORSNeLb3vSqMg@mail.gmail.com>
Message-ID: <20210408230522.GS904837@yoga>

On Thu 08 Apr 16:53 CDT 2021, Dmitry Baryshkov wrote:

> On Thu, 8 Apr 2021 at 23:05, Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > On Thu, Apr 8, 2021 at 6:06 PM Bjorn Andersson
> > <bjorn.andersson at linaro.org> wrote:
> > > On Thu 08 Apr 10:24 CDT 2021, Arnd Bergmann wrote:
> > > > Maybe see if you can address these in a follow-up, to avoid regressions.
> > > >
> > >
> > > I'm about to send you a another set of pull requests with some more
> > > goodies that was lingering on the list. I will take a look to see if I
> > > can follow up on that with some fixes for above warnings - and take
> > > another look at incorporating dtbs_check in my workflow.
> >
> > Ok, sounds good. As I mentioned, I'm also just learning how to use
> > dtbs_check properly. Unfortunately, it takes ages to run on a
> > non-parallel build,
> > and using 'make -j32' as I normally do means the output gets reordered
> > with every run.
> >
> > It's probably ok if you figure out how to only run it for the files you
> > actually change in the Qualcomm tree.
> 
> Disabling all non-Qualcomm arches makes `make dtbs_check` a little bit
> less painful.
> 

Yes, this is a trick I'm applying as well.

It would however be nice if one didn't have to disable CONFIG_ARCH_* to
achieve this, or even better if one could run dtbs_check on a single
.dtb. In particular since many of the warnings are resolved by fixing
the bindings, which causes dtbs_check to recheck all files.

Regards,
Bjorn


From sfr at canb.auug.org.au  Fri Apr  9 00:24:17 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 9 Apr 2021 09:24:17 +1000
Subject: linux-next: build warning after merge of the mvebu tree
In-Reply-To: <20210408095612.71e8c56e@canb.auug.org.au>
References: <20210408095612.71e8c56e@canb.auug.org.au>
Message-ID: <20210409092417.36b22630@canb.auug.org.au>

Hi all,

On Thu, 8 Apr 2021 09:56:12 +1000 Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>
> After merging the mvebu tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> arch/arm/boot/dts/armada-385-atl-x530.dts:171.14-199.4: Warning (spi_bus_reg): /soc/spi at 10680/spi-flash at 0: SPI bus unit address format error, expected "1"
> 
> Introduced by commit
> 
>   c6dfc019c239 ("ARM: dts: mvebu: Add device tree for ATL-x530 Board")

This is now a warning after the merge of 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/20210409/3710eaf5/attachment.sig>

From madvenka at linux.microsoft.com  Fri Apr  9 00:30:22 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Thu, 8 Apr 2021 18:30:22 -0500
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <69b6924b-88f6-6c40-7b18-8cdf15d92bd1@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-2-madvenka@linux.microsoft.com>
 <20210408171715.GQ4516@sirena.org.uk>
 <69b6924b-88f6-6c40-7b18-8cdf15d92bd1@linux.microsoft.com>
Message-ID: <eb905f70-a963-6257-c597-89e008675539@linux.microsoft.com>



On 4/8/21 2:30 PM, Madhavan T. Venkataraman wrote:
> 
> 
> On 4/8/21 12:17 PM, Mark Brown wrote:
>> On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka at linux.microsoft.com wrote:
>>
>>> These checks will involve checking the return PC to see if it falls inside
>>> any special functions where the stack trace is considered unreliable.
>>> Implement the infrastructure needed for this.
>>
>> Following up again based on an off-list discussion with Mark Rutland:
>> while I think this is a reasonable implementation for specifically
>> listing functions that cause problems we could make life easier for
>> ourselves by instead using annotations at the call sites to put things
>> into sections which indicate that they're unsafe for unwinding, we can
>> then check for any address in one of those sections (or possibly do the
>> reverse and check for any address in a section we specifically know is
>> safe) rather than having to enumerate problematic functions in the
>> unwinder.  This also has the advantage of not having a list that's
>> separate to the functions themselves so it's less likely that the
>> unwinder will get out of sync with the rest of the code as things evolve.
>>
>> We already have SYM_CODE_START() annotations in the code for assembly
>> functions that aren't using the standard calling convention which should
>> help a lot here, we could add a variant of that for things that we know
>> are safe on stacks (like those we expect to find at the bottom of
>> stacks).
>>
> 
> As I already mentioned before, I like the idea of sections. The only reason that I did
> not try it was that I have to address FTRACE trampolines and the kretprobe_trampoline
> (and optprobes in the future).
> 
> I have the following options:
> 
> 1. Create a common section (I will have to come up with an appropriate name) and put
>    all such functions in that one section.
> 
> 2. Create one section for each logical type (exception section, ftrace section and
>    kprobe section) or some such.
> 

For now, I will start with idea 2. I will create a special section for each class of
functions (EL1 exception handlers, FTRACE trampolines, KPROBE trampolines). Instead of a
special functions array, I will implement a special_sections array. The rest of the code
should just fall into place.

Let me know if you prefer something different.

Thanks.

Madhavan

> 3. Use the section idea only for the el1 exceptions. For the others use the current
>    special_functions[] approach.
> 
> Which one do you and Mark Rutland prefer? Or, is there another choice?
> 
> Madhavan
> 


From dmitry.baryshkov at linaro.org  Fri Apr  9 00:41:38 2021
From: dmitry.baryshkov at linaro.org (Dmitry Baryshkov)
Date: Fri, 9 Apr 2021 02:41:38 +0300
Subject: [GIT PULL] Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <20210408230522.GS904837@yoga>
References: <20210404164914.712946-1-bjorn.andersson@linaro.org>
 <161789462034.1629934.2631576576205147984.b4-ty@arndb.de>
 <YG8qIfFdY+As5tye@builder.lan>
 <CAK8P3a2v6yUVi395ixJRer2wyNVNXB-uypCqw5ts327ST=fHPg@mail.gmail.com>
 <CAA8EJpq4r0-XTouJTxnNdO8tgydenb+LjDykWORSNeLb3vSqMg@mail.gmail.com>
 <20210408230522.GS904837@yoga>
Message-ID: <CAA8EJprO7jwqaKXXk70hzDJnTU6iX6i2Vk1OxkrwDKFFQQSyEw@mail.gmail.com>

On Fri, 9 Apr 2021 at 02:05, Bjorn Andersson <bjorn.andersson at linaro.org> wrote:
>
> On Thu 08 Apr 16:53 CDT 2021, Dmitry Baryshkov wrote:
>
> > On Thu, 8 Apr 2021 at 23:05, Arnd Bergmann <arnd at kernel.org> wrote:
> > >
> > > On Thu, Apr 8, 2021 at 6:06 PM Bjorn Andersson
> > > <bjorn.andersson at linaro.org> wrote:
> > > > On Thu 08 Apr 10:24 CDT 2021, Arnd Bergmann wrote:
> > > > > Maybe see if you can address these in a follow-up, to avoid regressions.
> > > > >
> > > >
> > > > I'm about to send you a another set of pull requests with some more
> > > > goodies that was lingering on the list. I will take a look to see if I
> > > > can follow up on that with some fixes for above warnings - and take
> > > > another look at incorporating dtbs_check in my workflow.
> > >
> > > Ok, sounds good. As I mentioned, I'm also just learning how to use
> > > dtbs_check properly. Unfortunately, it takes ages to run on a
> > > non-parallel build,
> > > and using 'make -j32' as I normally do means the output gets reordered
> > > with every run.
> > >
> > > It's probably ok if you figure out how to only run it for the files you
> > > actually change in the Qualcomm tree.
> >
> > Disabling all non-Qualcomm arches makes `make dtbs_check` a little bit
> > less painful.
> >
>
> Yes, this is a trick I'm applying as well.
>
> It would however be nice if one didn't have to disable CONFIG_ARCH_* to
> achieve this, or even better if one could run dtbs_check on a single
> .dtb. In particular since many of the warnings are resolved by fixing
> the bindings, which causes dtbs_check to recheck all files.

As a quick hack: add the following rule to the top-level Makefile:

%.dt.yaml: include/config/kernel.release scripts_dtc
        $(Q)$(MAKE) $(build)=Documentation/devicetree/bindings
Documentation/devicetree/bindings/processed-schema.json
        $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ CHECK_DTBS=y

Now you can run checks for a single device tree by running 'make
ARCH=arm64 ...... sdm845-db845.dy.yaml'

I don't know if it's worth including this into the upstream source tree.

-- 
With best wishes
Dmitry


From andrew at aj.id.au  Fri Apr  9 00:46:35 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 09:16:35 +0930
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <20210408121441.GG7166@minyard.net>
References: <20210319061952.145040-1-andrew@aj.id.au>
 <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
 <20210408121441.GG7166@minyard.net>
Message-ID: <6ff29d26-543a-4790-abb4-ebaa3f8d0265@www.fastmail.com>



On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote:
> On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote:
> > Hi Corey,
> > 
> > On Fri, 19 Mar 2021, at 16:49, Andrew Jeffery wrote:
> > > Hello,
> > > 
> > > This series is a bit of a mix of things, but its primary purpose is to
> > > expose BMC KCS IPMI devices to userspace in a way that enables userspace
> > > to talk to host firmware using protocols that are not IPMI.
> > > 
> > > v1 can be found here:
> > > 
> > > https://lore.kernel.org/openbmc/20210219142523.3464540-1-andrew at aj.id.au/
> > > 
> > > Changes in v2 include:
> > > 
> > > * A rebase onto v5.12-rc2
> > > * Incorporation of off-list feedback on SerIRQ configuration from
> > >   Chiawei
> > > * Further validation on hardware for ASPEED KCS devices 2, 3 and 4
> > > * Lifting the existing single-open constraint of the IPMI chardev
> > > * Fixes addressing Rob's feedback on the conversion of the ASPEED KCS
> > >   binding to dt-schema
> > > * Fixes addressing Rob's feedback on the new aspeed,lpc-interrupts
> > >   property definition for the ASPEED KCS binding
> > > 
> > > A new chardev device is added whose implementation exposes the Input
> > > Data Register (IDR), Output Data Register (ODR) and Status Register
> > > (STR) via read() and write(), and implements poll() for event
> > > monitoring.
> > > 
> > > The existing /dev/ipmi-kcs* chardev interface exposes the KCS devices in
> > > a way which encoded the IPMI protocol in its behaviour. However, as
> > > LPC[0] KCS devices give us bi-directional interrupts between the host
> > > and a BMC with both a data and status byte, they are useful for purposes
> > > beyond IPMI.
> > > 
> > > As a concrete example, libmctp[1] implements a vendor-defined MCTP[2]
> > > binding using a combination of LPC Firmware cycles for bulk data
> > > transfer and a KCS device via LPC IO cycles for out-of-band protocol
> > > control messages[3]. This gives a throughput improvement over the
> > > standard KCS binding[4] while continuing to exploit the ease of setup of
> > > the LPC bus for early boot firmware on the host processor.
> > > 
> > > The series takes a bit of a winding path to achieve its aim:
> > > 
> > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've
> > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
> > > non-KCS LPC-related ASPEED device drivers in a way that enables the
> > > SerIRQ patches at the end of the series. With Joel's review I'm hoping
> > > these 5 can go through the aspeed tree, and that the rest can go through
> > > the IPMI tree.
> > > 
> > > 2. Next, patches 6-13 fairly heavily refactor the KCS support in the
> > > IPMI part of the tree, re-architecting things such that it's possible to
> > > support multiple chardev implementations sitting on top of the ASPEED
> > > and Nuvoton device drivers. However, the KCS code didn't really have
> > > great separation of concerns as it stood, so even if we disregard the
> > > multiple-chardev support I think the cleanups are worthwhile.
> > > 
> > > 3. Patch 14 adds some interrupt management capabilities to the KCS
> > > device drivers in preparation for patch 16, which introduces the new
> > > "raw" KCS device interface. I'm not stoked about the device name/path,
> > > so if people are looking to bikeshed something then feel free to lay
> > > into that.
> > > 
> > > 4. The remaining patches switch the ASPEED KCS devicetree binding to
> > > dt-schema, add a new interrupt property to describe the SerIRQ behaviour
> > > of the device and finally clean up Serial IRQ support in the ASPEED KCS
> > > driver.
> > > 
> > > Rob: The dt-binding patches still come before the relevant driver
> > > changes, I tried to keep the two close together in the series, hence the
> > > bindings changes not being patches 1 and 2.
> > > 
> > > I've exercised the series under qemu with the rainier-bmc machine plus
> > > additional patches for KCS support[5]. I've also substituted this series in
> > > place of a hacky out-of-tree driver that we've been using for the
> > > libmctp stack and successfully booted the host processor under our
> > > internal full-platform simulation tools for a Rainier system.
> > > 
> > > Note that this work touches the Nuvoton driver as well as ASPEED's, but
> > > I don't have the capability to test those changes or the IPMI chardev
> > > path. Tested-by tags would be much appreciated if you can exercise one
> > > or both.
> > > 
> > > Please review!
> > 
> > Unfortunately the cover letter got detached from the rest of the series.
> > 
> > Any chance you can take a look at the patches?
> 
> There were some minor concerns that were unanswered, and there really
> was no review by others for many of the patches.

Right; I was planning to clean up the minor concerns once I'd received 
some more feedback. I could have done a better job of communicating 
that :)

> 
> I would like this patch set, it makes some good cleanups.  But I would
> like some more review and testing by others, if possible. 

No worries. I'm trying to rope some others in to take a look.

Thanks for the response.

Andrew


From robh+dt at kernel.org  Fri Apr  9 00:59:49 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 18:59:49 -0500
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <YG8gaHqlJ+oCfkTt@piout.net>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <YG8gaHqlJ+oCfkTt@piout.net>
Message-ID: <CAL_JsqJD7Tx4o2J3vFCGMNPcJmi7LtbZN00oSUdT7bDXo3UF1Q@mail.gmail.com>

On Thu, Apr 8, 2021 at 10:25 AM Alexandre Belloni
<alexandre.belloni at bootlin.com> wrote:
>
> Hi,
>
> On 08/04/2021 17:08:26+0200, Arnd Bergmann wrote:
> > arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm at 73C000' does
> > not match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
> > 'pinctrl-[0-9]+'
> > arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm at 73C000' does not
> > match any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$',
> > 'pinctrl-[0-9]+'
> >
>
> This was introduced by 4d930c421e3b ("ARM: dts: at91: sama5d2: add ETB
> and ETM unit name"), trying to fix another warning.
>
> I guess this is because
> Documentation/devicetree/bindings/arm/coresight.txt is not yaml yet.

No, I believe it's from the uppercase hex.

Rob


From robh+dt at kernel.org  Fri Apr  9 01:08:29 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 8 Apr 2021 19:08:29 -0500
Subject: [PATCHv5 6/6] PCI: layerscape: Add power management support
In-Reply-To: <20210407030948.3845-7-Zhiqiang.Hou@nxp.com>
References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com>
 <20210407030948.3845-7-Zhiqiang.Hou@nxp.com>
Message-ID: <CAL_JsqJjZKMB57oa-TtkBnGLRNa_V6+_upn9Cw55YHKre+b0oQ@mail.gmail.com>

On Tue, Apr 6, 2021 at 10:04 PM Zhiqiang Hou <Zhiqiang.Hou at nxp.com> wrote:
>
> From: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
>
> Add PME_Turn_Off/PME_TO_Ack handshake sequence, and finally
> put the PCIe controller into D3 state after the L2/L3 ready
> state transition process completion.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at nxp.com>
> ---
> V5:
>  - Fix a typo of the parameter given to function dw_pcie_setup_rc()
>
>  drivers/pci/controller/dwc/pci-layerscape.c  | 382 ++++++++++++++++++-
>  drivers/pci/controller/dwc/pcie-designware.h |   1 +
>  2 files changed, 381 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Fri Apr  9 01:26:10 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 9 Apr 2021 08:26:10 +0800
Subject: [soc:apple/m1-main 13/20] include/linux/io.h:98:34: warning:
 pointer/integer type mismatch in conditional expression ('int' and 'void *')
Message-ID: <202104090804.z14OP6te-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git apple/m1-main
head:   7d2d16ccf15d8eb84accfaf44a0b324f36e39588
commit: b10eb2d50911f98a8f1cacf00b1b677339593f4c [13/20] asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
config: powerpc64-randconfig-r024-20210408 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dd453a1389b6a7e6d9214b449d3c54981b1a89b6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=b10eb2d50911f98a8f1cacf00b1b677339593f4c
        git remote add soc https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
        git fetch --no-tags soc apple/m1-main
        git checkout b10eb2d50911f98a8f1cacf00b1b677339593f4c
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ^
>> include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
--
   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ^
>> include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
   make[2]: *** [scripts/Makefile.build:116: arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1235: prepare0] Error 2
   make[1]: Target 'modules_prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'modules_prepare' not remade because of errors.
--
   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
   include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ^
>> include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
   make[2]: *** [scripts/Makefile.build:116: arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1235: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +98 include/linux/io.h

    81	
    82	#ifdef CONFIG_PCI
    83	/*
    84	 * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
    85	 * Posting") mandate non-posted configuration transactions. This default
    86	 * implementation attempts to use the ioremap_np() API to provide this
    87	 * on arches that support it, and falls back to ioremap() on those that
    88	 * don't. Overriding this function is deprecated; arches that properly
    89	 * support non-posted accesses should implement ioremap_np() instead, which
    90	 * this default implementation can then use to return mappings compliant with
    91	 * the PCI specification.
    92	 */
    93	#ifndef pci_remap_cfgspace
    94	#define pci_remap_cfgspace pci_remap_cfgspace
    95	static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
    96						       size_t size)
    97	{
  > 98		return ioremap_np(offset, size) ?: ioremap(offset, size);
    99	}
   100	#endif
   101	#endif
   102	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 24146 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/508ddee8/attachment-0001.gz>

From lkp at intel.com  Fri Apr  9 01:31:24 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 9 Apr 2021 08:31:24 +0800
Subject: [soc:apple/m1-main 13/20] include/linux/io.h:98:9: error: implicit
 declaration of function 'ioremap_np'
Message-ID: <202104090818.4JeO325F-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git apple/m1-main
head:   7d2d16ccf15d8eb84accfaf44a0b324f36e39588
commit: b10eb2d50911f98a8f1cacf00b1b677339593f4c [13/20] asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
config: powerpc64-randconfig-r021-20210408 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dd453a1389b6a7e6d9214b449d3c54981b1a89b6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?id=b10eb2d50911f98a8f1cacf00b1b677339593f4c
        git remote add soc https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
        git fetch --no-tags soc apple/m1-main
        git checkout b10eb2d50911f98a8f1cacf00b1b677339593f4c
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
>> include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ^
>> include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
--
   In file included from arch/powerpc/kernel/asm-offsets.c:23:
   In file included from include/linux/suspend.h:5:
   In file included from include/linux/swap.h:9:
   In file included from include/linux/memcontrol.h:13:
   In file included from include/linux/cgroup.h:26:
   In file included from include/linux/kernel_stat.h:9:
   In file included from include/linux/interrupt.h:11:
   In file included from include/linux/hardirq.h:10:
   In file included from arch/powerpc/include/asm/hardirq.h:6:
   In file included from include/linux/irq.h:20:
>> include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ^
>> include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
           return ioremap_np(offset, size) ?: ioremap(offset, size);
                  ~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~
   1 warning and 1 error generated.
   make[2]: *** [scripts/Makefile.build:116: arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1235: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +/ioremap_np +98 include/linux/io.h

    81	
    82	#ifdef CONFIG_PCI
    83	/*
    84	 * The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
    85	 * Posting") mandate non-posted configuration transactions. This default
    86	 * implementation attempts to use the ioremap_np() API to provide this
    87	 * on arches that support it, and falls back to ioremap() on those that
    88	 * don't. Overriding this function is deprecated; arches that properly
    89	 * support non-posted accesses should implement ioremap_np() instead, which
    90	 * this default implementation can then use to return mappings compliant with
    91	 * the PCI specification.
    92	 */
    93	#ifndef pci_remap_cfgspace
    94	#define pci_remap_cfgspace pci_remap_cfgspace
    95	static inline void __iomem *pci_remap_cfgspace(phys_addr_t offset,
    96						       size_t size)
    97	{
  > 98		return ioremap_np(offset, size) ?: ioremap(offset, size);
    99	}
   100	#endif
   101	#endif
   102	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29365 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/63118f0d/attachment-0001.gz>

From weiyongjun1 at huawei.com  Fri Apr  9 02:22:13 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Fri, 9 Apr 2021 01:22:13 +0000
Subject: [PATCH -next] coresight: trbe: Fix return value check in
 arm_trbe_register_coresight_cpu()
Message-ID: <20210409012213.3664473-1-weiyongjun1@huawei.com>

In case of error, the function devm_kasprintf() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.

Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 5ce239875c98..176868496879 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -871,7 +871,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
 
 	dev = &cpudata->drvdata->pdev->dev;
 	desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu);
-	if (IS_ERR(desc.name))
+	if (!desc.name)
 		goto cpu_clear;
 
 	desc.type = CORESIGHT_DEV_TYPE_SINK;



From weiyongjun1 at huawei.com  Fri Apr  9 02:32:15 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Fri, 9 Apr 2021 01:32:15 +0000
Subject: [PATCH -next] coresight: core: Make symbol 'csdev_sink' static
Message-ID: <20210409013215.488823-1-weiyongjun1@huawei.com>

The sparse tool complains as follows:

drivers/hwtracing/coresight/coresight-core.c:26:1: warning:
 symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static?

This symbol is not used outside of coresight-core.c, so this
commit marks it static.

Fixes: 2cd87a7b293d ("coresight: core: Add support for dedicated percpu sinks")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 drivers/hwtracing/coresight/coresight-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 3e779e1619ed..6c68d34d956e 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -23,7 +23,7 @@
 #include "coresight-priv.h"
 
 static DEFINE_MUTEX(coresight_mutex);
-DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
+static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
 
 /**
  * struct coresight_node - elements of a path, from source to sink



From danielwa at cisco.com  Fri Apr  9 02:23:49 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Thu, 8 Apr 2021 18:23:49 -0700
Subject: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
In-Reply-To: <20210408190408.GA1724284@robh.at.kernel.org>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>
 <20210406173836.GW2469518@zorba>
 <20210408190408.GA1724284@robh.at.kernel.org>
Message-ID: <20210409012349.GG3981976@zorba>

On Thu, Apr 08, 2021 at 02:04:08PM -0500, Rob Herring wrote:
> On Tue, Apr 06, 2021 at 10:38:36AM -0700, Daniel Walker wrote:
> > On Fri, Apr 02, 2021 at 03:18:21PM +0000, Christophe Leroy wrote:
> > > -config CMDLINE_BOOL
> > > -	bool "Built-in kernel command line"
> > > -	help
> > > -	  For most systems, it is firmware or second stage bootloader that
> > > -	  by default specifies the kernel command line options.  However,
> > > -	  it might be necessary or advantageous to either override the
> > > -	  default kernel command line or add a few extra options to it.
> > > -	  For such cases, this option allows you to hardcode your own
> > > -	  command line options directly into the kernel.  For that, you
> > > -	  should choose 'Y' here, and fill in the extra boot arguments
> > > -	  in CONFIG_CMDLINE.
> > > -
> > > -	  The built-in options will be concatenated to the default command
> > > -	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
> > > -	  command line will be ignored and replaced by the built-in string.
> > > -
> > > -	  Most MIPS systems will normally expect 'N' here and rely upon
> > > -	  the command line from the firmware or the second-stage bootloader.
> > > -
> > 
> > 
> > See how you complained that I have CMDLINE_BOOL in my changed, and you think it
> > shouldn't exist.
> > 
> > Yet here mips has it, and you just deleted it with no feature parity in your
> > changes for this.
> 
> AFAICT, CMDLINE_BOOL equates to a non-empty or empty CONFIG_CMDLINE. You 
> seem to need it just because you have CMDLINE_PREPEND and 
> CMDLINE_APPEND. If that's not it, what feature is missing? CMDLINE_BOOL 
> is not a feature, but an implementation detail.

Not true.

It makes it easier to turn it all off inside the Kconfig , so it's for usability
and multiple architecture have it even with just CMDLINE as I was commenting
here.

Daniel


From quanyang.wang at windriver.com  Fri Apr  9 02:33:30 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Fri, 9 Apr 2021 09:33:30 +0800
Subject: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <17b5d33f-ce96-dc07-05f7-41d87f53a3d0@xilinx.com>
References: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
 <17b5d33f-ce96-dc07-05f7-41d87f53a3d0@xilinx.com>
Message-ID: <ef4555a6-1674-d9c0-6401-cdf43780a014@windriver.com>

Hi Dinghao,

On 4/8/21 6:33 PM, Michal Simek wrote:
> ++
>
> On 4/8/21 11:25 AM, Dinghao Liu wrote:
>> When platform_get_irq() fails, a pairing PM usage counter
>> increment is needed to keep the counter balanced. It's the
>> same for the following error paths.
>>
>> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
>> ---
>>   drivers/spi/spi-zynqmp-gqspi.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
>> index c8fa6ee18ae7..95963a2de64a 100644
>> --- a/drivers/spi/spi-zynqmp-gqspi.c
>> +++ b/drivers/spi/spi-zynqmp-gqspi.c
>> @@ -1197,6 +1197,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>>   	return 0;
>>   
>>   clk_dis_all:
>> +	pm_runtime_get_noresume(&pdev->dev);
>>   	pm_runtime_set_suspended(&pdev->dev);
>>   	pm_runtime_disable(&pdev->dev);
>>   	clk_disable_unprepare(xqspi->refclk);
>>
The imbalance is because pm_runtime_put_autosuspend is called to make 
counter to be -1.

It looks strange that there is no counter increament op before 
pm_runtime_put_autosuspend.

In my limited understanding, it should look like:

......

pm_runtime_enable

pm_runtime_get_sync ? //increase counter to one to resume device

DO OPERATIONS HERE

pm_runtime_mark_last_busy
pm_runtime_put_autosuspend ? //decrease counter to zero and trigger suspend

return 0;

error_path:

pm_runtime_put_sync

pm_runtime_disable

return err;


Am I missing something?

Thanks,

Quanyang




From chunfeng.yun at mediatek.com  Fri Apr  9 02:34:00 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 09:34:00 +0800
Subject: [PATCH v2 -next] phy: phy-mtk-hdmi: Remove redundant dev_err
 call in mtk_hdmi_phy_probe()
In-Reply-To: <20210408115530.15673-1-heying24@huawei.com>
References: <20210408115530.15673-1-heying24@huawei.com>
Message-ID: <1617932040.12105.11.camel@mhfsdcap03>

On Thu, 2021-04-08 at 07:55 -0400, He Ying wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: He Ying <heying24 at huawei.com>
> ---
> v2:
> - Use 'return PTR_ERR()' instead of 'ret = PTR_ERR();return ret;'.
> 
>  drivers/phy/mediatek/phy-mtk-hdmi.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c b/drivers/phy/mediatek/phy-mtk-hdmi.c
> index 8313bd517e4c..8ad8f717ef43 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
> @@ -119,9 +119,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
>  	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	hdmi_phy->regs = devm_ioremap_resource(dev, mem);
>  	if (IS_ERR(hdmi_phy->regs)) {
> -		ret = PTR_ERR(hdmi_phy->regs);
> -		dev_err(dev, "Failed to get memory resource: %d\n", ret);
> -		return ret;
> +		return PTR_ERR(hdmi_phy->regs);
>  	}
Reviewed-by: Chunfeng Yun <chunfeng.yun at mediatek.com>

Thanks a lot
>  
>  	ref_clk = devm_clk_get(dev, "pll_ref");


From chunfeng.yun at mediatek.com  Fri Apr  9 02:53:31 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 09:53:31 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
Message-ID: <1617933211.12105.22.camel@mhfsdcap03>

On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > When the dedicated wake irq is level trigger, enable it before
> > calling runtime_suspend, will trigger an interrupt.
> >
> > e.g.
> > for a low level trigger type, it's low level at running time (0),
> > and becomes high level when enters suspend (runtime_suspend (1) is
> > called), a wakeup signal at (2) make it become low level, wake irq
> > will be triggered.
> >
> >                 ------------------
> >                |           ^     ^|
> > ----------------           |     | --------------
> >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> >
> > if we enable the wake irq before calling runtime_suspend during (0),
> > an interrupt will arise, it causes resume immediately;
> 
> But that's necessary to avoid missing a wakeup interrupt, isn't it?
That's also what I worry about.
It may happen if the trigger level only keeps a very short time, and the
interrupt controller can't process it timely, but I don't think it
follow the level trigger mechanism, the HW should latch it until the ISR
is called. right?

> 
> > enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
> > will works.
> >
> > This patch seems no side effect on edge trigger wake irq.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> >  drivers/base/power/runtime.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index a46a7e30881b..796739a015a5 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> >         __update_runtime_status(dev, RPM_SUSPENDING);
> >
> >         callback = RPM_GET_CALLBACK(dev, runtime_suspend);
> > -
> > -       dev_pm_enable_wake_irq_check(dev, true);
> >         retval = rpm_callback(callback, dev);
> >         if (retval)
> >                 goto fail;
> >
> > +       dev_pm_enable_wake_irq_check(dev, true);
> > +
> >   no_callback:
> >         __update_runtime_status(dev, RPM_SUSPENDED);
> >         pm_runtime_deactivate_timer(dev);
> > @@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> >         return retval;
> >
> >   fail:
> > -       dev_pm_disable_wake_irq_check(dev);
> >         __update_runtime_status(dev, RPM_ACTIVE);
> >         dev->power.deferred_resume = false;
> >         wake_up_all(&dev->power.wait_queue);
> > --
> > 2.18.0
> >


From chenlifu at huawei.com  Fri Apr  9 02:55:15 2021
From: chenlifu at huawei.com (Chen Lifu)
Date: Fri, 9 Apr 2021 09:55:15 +0800
Subject: [PATCH -next] ARM: spear: Fix build error with CONFIG_ARCH_SPEAR3XX
Message-ID: <20210409015515.258653-1-chenlifu@huawei.com>

commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
We get build error when CONFIG_ARCH_SPEAR3XX is set:
arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has no member named 'num_chipselect'
   42 |  .num_chipselect = 2,
      |   ^~~~~~~~~~~~~~
arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   42 |  .num_chipselect = 2,
      |                    ^

Fix the issue by deleting the initialization of 'num_chipselect'
in spear3xx.c.

Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Chen Lifu <chenlifu at huawei.com>
---
 arch/arm/mach-spear/spear3xx.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
index 8537fcffe5a8..f83321d5e353 100644
--- a/arch/arm/mach-spear/spear3xx.c
+++ b/arch/arm/mach-spear/spear3xx.c
@@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
 	.dma_filter = pl08x_filter_id,
 	.dma_tx_param = "ssp0_tx",
 	.dma_rx_param = "ssp0_rx",
-	/*
-	 * This is number of spi devices that can be connected to spi. There are
-	 * two type of chipselects on which slave devices can work. One is chip
-	 * select provided by spi masters other is controlled through external
-	 * gpio's. We can't use chipselect provided from spi master (because as
-	 * soon as FIFO becomes empty, CS is disabled and transfer ends). So
-	 * this number now depends on number of gpios available for spi. each
-	 * slave on each master requires a separate gpio pin.
-	 */
-	.num_chipselect = 2,
 };
 
 /* dmac device registration */



From Mason.Zhang at mediatek.com  Fri Apr  9 02:56:52 2021
From: Mason.Zhang at mediatek.com (Mason Zhang)
Date: Fri, 9 Apr 2021 09:56:52 +0800
Subject: [PATCH v2 1/1] arm64: dts: mediatek: add MT6779 spi master dts node
Message-ID: <20210409015651.11474-1-Mason.Zhang@mediatek.com>

This patch add address-cells && size-cells in spi node based on patch v1.

Signed-off-by: Mason Zhang <Mason.Zhang at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt6779.dtsi | 112 +++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
index 370f309d32de..c81e76865d1b 100644
--- a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
@@ -219,6 +219,118 @@
 			status = "disabled";
 		};
 
+		spi0: spi0 at 1100a000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x1100a000 0 0x1000>;
+			interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				<&topckgen CLK_TOP_SPI>,
+				<&infracfg_ao CLK_INFRA_SPI0>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi1: spi1 at 11010000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x11010000 0 0x1000>;
+			interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				<&topckgen CLK_TOP_SPI>,
+				<&infracfg_ao CLK_INFRA_SPI1>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi2: spi2 at 11012000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x11012000 0 0x1000>;
+			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				 <&topckgen CLK_TOP_SPI>,
+				<&infracfg_ao CLK_INFRA_SPI2>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi3: spi3 at 11013000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x11013000 0 0x1000>;
+			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				 <&topckgen CLK_TOP_SPI>,
+				 <&infracfg_ao CLK_INFRA_SPI3>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi4: spi4 at 11018000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x11018000 0 0x1000>;
+			interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				 <&topckgen CLK_TOP_SPI>,
+				 <&infracfg_ao CLK_INFRA_SPI4>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi5: spi5 at 11019000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x11019000 0 0x1000>;
+			interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				<&topckgen CLK_TOP_SPI>,
+				<&infracfg_ao CLK_INFRA_SPI5>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi6: spi6 at 1101d000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x1101d000 0 0x1000>;
+			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				 <&topckgen CLK_TOP_SPI>,
+				 <&infracfg_ao CLK_INFRA_SPI6>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
+		spi7: spi7 at 1101e000 {
+			compatible = "mediatek,mt6779-spi",
+				     "mediatek,mt6765-spi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			mediatek,pad-select = <0>;
+			reg = <0 0x1101e000 0 0x1000>;
+			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_LOW 0>;
+			clocks = <&topckgen CLK_TOP_MAINPLL_D5_D2>,
+				 <&topckgen CLK_TOP_SPI>,
+				 <&infracfg_ao CLK_INFRA_SPI7>;
+			clock-names = "parent-clk", "sel-clk", "spi-clk";
+		};
+
 		audio: clock-controller at 11210000 {
 			compatible = "mediatek,mt6779-audio", "syscon";
 			reg = <0 0x11210000 0 0x1000>;
-- 
2.18.0

From qiulaibin at huawei.com  Fri Apr  9 03:33:49 2021
From: qiulaibin at huawei.com (Laibin Qiu)
Date: Fri, 9 Apr 2021 10:33:49 +0800
Subject: [PATCH -next] mmc: owl-mmc: Remove unnecessary error log
Message-ID: <20210409023349.3325907-1-qiulaibin@huawei.com>

devm_ioremap_resource() has recorded error log, so it's
unnecessary to record log again.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>
---
 drivers/mmc/host/owl-mmc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/owl-mmc.c b/drivers/mmc/host/owl-mmc.c
index 5490962dc8e5..3dc143b03939 100644
--- a/drivers/mmc/host/owl-mmc.c
+++ b/drivers/mmc/host/owl-mmc.c
@@ -581,7 +581,6 @@ static int owl_mmc_probe(struct platform_device *pdev)
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	owl_host->base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(owl_host->base)) {
-		dev_err(&pdev->dev, "Failed to remap registers\n");
 		ret = PTR_ERR(owl_host->base);
 		goto err_free_host;
 	}
-- 
2.25.1



From qiulaibin at huawei.com  Fri Apr  9 03:38:01 2021
From: qiulaibin at huawei.com (Laibin Qiu)
Date: Fri, 9 Apr 2021 10:38:01 +0800
Subject: [PATCH -next] mmc: sdhci-st: Remove unnecessary error log
Message-ID: <20210409023801.3326572-1-qiulaibin@huawei.com>

devm_ioremap_resource() has recorded error log, so it's
unnecessary to record log again.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>
---
 drivers/mmc/host/sdhci-st.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
index 78941ac3a1d6..d41582c21aa3 100644
--- a/drivers/mmc/host/sdhci-st.c
+++ b/drivers/mmc/host/sdhci-st.c
@@ -400,10 +400,8 @@ static int sdhci_st_probe(struct platform_device *pdev)
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 					   "top-mmc-delay");
 	pdata->top_ioaddr = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(pdata->top_ioaddr)) {
-		dev_warn(&pdev->dev, "FlashSS Top Dly registers not available");
+	if (IS_ERR(pdata->top_ioaddr))
 		pdata->top_ioaddr = NULL;
-	}
 
 	pltfm_host->clk = clk;
 	pdata->icnclk = icnclk;
-- 
2.25.1



From chunfeng.yun at mediatek.com  Fri Apr  9 03:39:07 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 10:39:07 +0800
Subject: [RFC PATCH] usb: core: reduce power-on-good delay time of root hub
Message-ID: <1617935947-24045-1-git-send-email-chunfeng.yun@mediatek.com>

Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.

Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/core/hub.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 73f4482d833a..22ea1f4f2d66 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -148,8 +148,10 @@ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
 {
 	unsigned delay = hub->descriptor->bPwrOn2PwrGood * 2;
 
-	/* Wait at least 100 msec for power to become stable */
-	return max(delay, 100U);
+	if (!hub->hdev->parent)	/* root hub */
+		return delay;
+	else /* Wait at least 100 msec for power to become stable */
+		return max(delay, 100U);
 }
 
 static inline int hub_port_debounce_be_connected(struct usb_hub *hub,
-- 
2.18.0

From mason.zhang at mediatek.com  Fri Apr  9 03:27:17 2021
From: mason.zhang at mediatek.com (Mason Zhang)
Date: Fri, 9 Apr 2021 10:27:17 +0800
Subject: [PATCH 1/2] arm64: dts: mediatek: add MT6779 spi master dts node
In-Reply-To: <4e39785a-06a6-4ec5-5930-8a5bf53e4f7b@gmail.com>
References: <20210226105918.3057-1-Mason.Zhang@mediatek.com>
 <4e39785a-06a6-4ec5-5930-8a5bf53e4f7b@gmail.com>
Message-ID: <1617935237.16711.6.camel@mbjsdccf07>

On Wed, 2021-04-07 at 13:17 +0200, Matthias Brugger wrote:
> 
> From the binding description:
> - #address-cells: should be 1.
> 
> - #size-cells: should be 0.
> 
> We are missing both here. Please fix that.
> 
> Apart the binding description is naming PLL, clock mux and clock gate IDs which
> do not correspond to the ones used here. It seems that this binding was tailored
> for a specific SoC family but never made generic. If you want, please do so and
> convert it to yaml.


Dear Matthias:

	I have update patch v2:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409015651.11474-1-Mason.Zhang at mediatek.com/

	Please gentle ping on this patch. Thanks~
	
Thanks
Mason

				       		









From chunfeng.yun at mediatek.com  Fri Apr  9 04:04:34 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 11:04:34 +0800
Subject: [PATCH] irqchip: gic-pm: remove redundant error log of clock bulk
Message-ID: <1617937474-24630-1-git-send-email-chunfeng.yun@mediatek.com>

There is error log in clk_bulk_prepare/enable()

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/irqchip/irq-gic-pm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-pm.c b/drivers/irqchip/irq-gic-pm.c
index 1337cec..b60e185 100644
--- a/drivers/irqchip/irq-gic-pm.c
+++ b/drivers/irqchip/irq-gic-pm.c
@@ -30,10 +30,8 @@ static int gic_runtime_resume(struct device *dev)
 	int ret;
 
 	ret = clk_bulk_prepare_enable(data->num_clocks, chip_pm->clks);
-	if (ret) {
-		dev_err(dev, "clk_enable failed: %d\n", ret);
+	if (ret)
 		return ret;
-	}
 
 	/*
 	 * On the very first resume, the pointer to chip_pm->chip_data
-- 
1.8.1.1.dirty

From chunfeng.yun at mediatek.com  Fri Apr  9 04:07:10 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 11:07:10 +0800
Subject: [PATCH] phy: qcom-qmp: remove redundant error of clock bulk
Message-ID: <1617937630-24832-1-git-send-email-chunfeng.yun@mediatek.com>

There is error log in clk_bulk_prepare/enable()

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 9cdebe7..f14b8be 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -3598,10 +3598,8 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 	}
 
 	ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
-	if (ret) {
-		dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
+	if (ret)
 		goto err_rst;
-	}
 
 	if (cfg->has_phy_dp_com_ctrl) {
 		qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
@@ -4035,10 +4033,8 @@ static int __maybe_unused qcom_qmp_phy_runtime_resume(struct device *dev)
 	}
 
 	ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
-	if (ret) {
-		dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
+	if (ret)
 		return ret;
-	}
 
 	ret = clk_prepare_enable(qphy->pipe_clk);
 	if (ret) {
-- 
1.8.1.1.dirty

From keescook at chromium.org  Fri Apr  9 04:08:18 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu, 8 Apr 2021 20:08:18 -0700
Subject: [PATCH 09/20] kbuild: arm64: use common install script
In-Reply-To: <20210407053419.449796-10-gregkh@linuxfoundation.org>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
 <20210407053419.449796-10-gregkh@linuxfoundation.org>
Message-ID: <202104082007.88622E72F@keescook>

On Wed, Apr 07, 2021 at 07:34:08AM +0200, Greg Kroah-Hartman wrote:
> The common scripts/install.sh script will now work for arm65, no changes

nit: arm64

> needed so convert the arm64 boot Makefile to call it instead of the
> arm64-only version of the file and remove the now unused file.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

With that fixed:

Reviewed-by: Kees Cook <keescook at chromium.org>

-- 
Kees Cook


From keescook at chromium.org  Fri Apr  9 04:09:41 2021
From: keescook at chromium.org (Kees Cook)
Date: Thu, 8 Apr 2021 20:09:41 -0700
Subject: [PATCH 10/20] kbuild: arm: use common install script
In-Reply-To: <20210407053419.449796-11-gregkh@linuxfoundation.org>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
 <20210407053419.449796-11-gregkh@linuxfoundation.org>
Message-ID: <202104082009.5334E9CA@keescook>

On Wed, Apr 07, 2021 at 07:34:09AM +0200, Greg Kroah-Hartman wrote:
> The common scripts/install.sh script will now work for arm, all that
> is needed is to add the compressed image type to it.  So add that file
> type check and the ability to call /sbin/loadmap after copying the
> kernel.  With that we can remove the arm-only version of the file.
> 
> Cc: Russell King <linux at armlinux.org.uk>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

Reviewed-by: Kees Cook <keescook at chromium.org>

-- 
Kees Cook


From joel at jms.id.au  Fri Apr  9 04:18:55 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 03:18:55 +0000
Subject: [PATCH v2 01/21] dt-bindings: aspeed-lpc: Remove LPC partitioning
In-Reply-To: <20210319062752.145730-1-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
Message-ID: <CACPK8Xdw3+2Rt=tQ-ciusyK=W6BaP_DR4FSFp0qDuPq5z8MPBQ@mail.gmail.com>

On Fri, 19 Mar 2021 at 06:28, Andrew Jeffery <andrew at aj.id.au> wrote:
>
> From: "Chia-Wei, Wang" <chiawei_wang at aspeedtech.com>
>
> The LPC controller has no concept of the BMC and the Host partitions.
> This patch fixes the documentation by removing the description on LPC
> partitions. The register offsets illustrated in the DTS node examples
> are also fixed to adapt to the LPC DTS change.

Is this accurate:

 The node examples change their reg address to be an offset from the
LPC HC to be an offset from the base of the LPC region.

Reviewed-by: Joel Stanley <joel at jms.id.au>

>
> Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> Reviewed-by: Andrew Jeffery <andrew at aj.id.au>
> Acked-by: Rob Herring <robh at kernel.org>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> ---
>  .../devicetree/bindings/mfd/aspeed-lpc.txt    | 100 +++++-------------
>  1 file changed, 25 insertions(+), 75 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index d0a38ba8b9ce..936aa108eab4 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -9,13 +9,7 @@ primary use case of the Aspeed LPC controller is as a slave on the bus
>  conditions it can also take the role of bus master.
>
>  The LPC controller is represented as a multi-function device to account for the
> -mix of functionality it provides. The principle split is between the register
> -layout at the start of the I/O space which is, to quote the Aspeed datasheet,
> -"basically compatible with the [LPC registers from the] popular BMC controller
> -H8S/2168[1]", and everything else, where everything else is an eclectic
> -collection of functions with a esoteric register layout. "Everything else",
> -here labeled the "host" portion of the controller, includes, but is not limited
> -to:
> +mix of functionality, which includes, but is not limited to:
>
>  * An IPMI Block Transfer[2] Controller
>
> @@ -44,80 +38,36 @@ Required properties
>  ===================
>
>  - compatible:  One of:
> -               "aspeed,ast2400-lpc", "simple-mfd"
> -               "aspeed,ast2500-lpc", "simple-mfd"
> -               "aspeed,ast2600-lpc", "simple-mfd"
> +               "aspeed,ast2400-lpc-v2", "simple-mfd", "syscon"
> +               "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon"
> +               "aspeed,ast2600-lpc-v2", "simple-mfd", "syscon"
>
>  - reg:         contains the physical address and length values of the Aspeed
>                  LPC memory region.
>
>  - #address-cells: <1>
>  - #size-cells: <1>
> -- ranges:      Maps 0 to the physical address and length of the LPC memory
> -                region
> -
> -Required LPC Child nodes
> -========================
> -
> -BMC Node
> ---------
> -
> -- compatible:  One of:
> -               "aspeed,ast2400-lpc-bmc"
> -               "aspeed,ast2500-lpc-bmc"
> -               "aspeed,ast2600-lpc-bmc"
> -
> -- reg:         contains the physical address and length values of the
> -                H8S/2168-compatible LPC controller memory region
> -
> -Host Node
> ----------
> -
> -- compatible:   One of:
> -               "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
> -               "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
> -               "aspeed,ast2600-lpc-host", "simple-mfd", "syscon"
> -
> -- reg:         contains the address and length values of the host-related
> -                register space for the Aspeed LPC controller
> -
> -- #address-cells: <1>
> -- #size-cells: <1>
> -- ranges:      Maps 0 to the address and length of the host-related LPC memory
> +- ranges:      Maps 0 to the physical address and length of the LPC memory
>                  region
>
>  Example:
>
>  lpc: lpc at 1e789000 {
> -       compatible = "aspeed,ast2500-lpc", "simple-mfd";
> +       compatible = "aspeed,ast2500-lpc-v2", "simple-mfd", "syscon";
>         reg = <0x1e789000 0x1000>;
>
>         #address-cells = <1>;
>         #size-cells = <1>;
>         ranges = <0x0 0x1e789000 0x1000>;
>
> -       lpc_bmc: lpc-bmc at 0 {
> -               compatible = "aspeed,ast2500-lpc-bmc";
> +       lpc_snoop: lpc-snoop at 0 {
> +               compatible = "aspeed,ast2600-lpc-snoop";
>                 reg = <0x0 0x80>;
> -       };
> -
> -       lpc_host: lpc-host at 80 {
> -               compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
> -               reg = <0x80 0x1e0>;
> -               reg-io-width = <4>;
> -
> -               #address-cells = <1>;
> -               #size-cells = <1>;
> -               ranges = <0x0 0x80 0x1e0>;
> +               interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
> +               snoop-ports = <0x80>;
>         };
>  };
>
> -BMC Node Children
> -==================
> -
> -
> -Host Node Children
> -==================
>
>  LPC Host Interface Controller
>  -------------------
> @@ -149,14 +99,12 @@ Optional properties:
>
>  Example:
>
> -lpc-host at 80 {
> -       lpc_ctrl: lpc-ctrl at 0 {
> -               compatible = "aspeed,ast2500-lpc-ctrl";
> -               reg = <0x0 0x80>;
> -               clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
> -               memory-region = <&flash_memory>;
> -               flash = <&spi>;
> -       };
> +lpc_ctrl: lpc-ctrl at 80 {
> +       compatible = "aspeed,ast2500-lpc-ctrl";
> +       reg = <0x80 0x80>;
> +       clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
> +       memory-region = <&flash_memory>;
> +       flash = <&spi>;
>  };
>
>  LPC Host Controller
> @@ -179,9 +127,9 @@ Required properties:
>
>  Example:
>
> -lhc: lhc at 20 {
> +lhc: lhc at a0 {
>         compatible = "aspeed,ast2500-lhc";
> -       reg = <0x20 0x24 0x48 0x8>;
> +       reg = <0xa0 0x24 0xc8 0x8>;
>  };
>
>  LPC reset control
> @@ -192,16 +140,18 @@ state of the LPC bus. Some systems may chose to modify this configuration.
>
>  Required properties:
>
> - - compatible:         "aspeed,ast2600-lpc-reset" or
> -                       "aspeed,ast2500-lpc-reset"
> -                       "aspeed,ast2400-lpc-reset"
> + - compatible:         One of:
> +                       "aspeed,ast2600-lpc-reset";
> +                       "aspeed,ast2500-lpc-reset";
> +                       "aspeed,ast2400-lpc-reset";
> +
>   - reg:                        offset and length of the IP in the LHC memory region
>   - #reset-controller   indicates the number of reset cells expected
>
>  Example:
>
> -lpc_reset: reset-controller at 18 {
> +lpc_reset: reset-controller at 98 {
>          compatible = "aspeed,ast2500-lpc-reset";
> -        reg = <0x18 0x4>;
> +        reg = <0x98 0x4>;
>          #reset-cells = <1>;
>  };
> --
> 2.27.0
>


From zweiss at equinix.com  Fri Apr  9 04:24:49 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 03:24:49 +0000
Subject: [PATCH v2 06/21] ipmi: kcs_bmc_aspeed: Use of match data to
 extract KCS properties
In-Reply-To: <20210319062752.145730-6-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-6-andrew@aj.id.au>
Message-ID: <YG/JAGZmzu7TlCxa@packtop>

On Fri, Mar 19, 2021 at 01:27:37AM CDT, Andrew Jeffery wrote:
>Unpack and remove the aspeed_kcs_probe_of_v[12]() functions to aid
>rearranging how the private device-driver memory is allocated.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc_aspeed.c | 146 ++++++++++++++---------------
> 1 file changed, 68 insertions(+), 78 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index eefe362f65f0..061f53676206 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
>+#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/poll.h>
> #include <linux/regmap.h>
>@@ -63,6 +64,10 @@ struct aspeed_kcs_bmc {
> 	struct regmap *map;
> };
>
>+struct aspeed_kcs_of_ops {
>+	int (*get_channel)(struct platform_device *pdev);
>+	int (*get_io_address)(struct platform_device *pdev);
>+};
>
> static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> {
>@@ -231,13 +236,10 @@ static const struct kcs_ioreg ast_kcs_bmc_ioregs[KCS_CHANNEL_MAX] = {
> 	{ .idr = LPC_IDR4, .odr = LPC_ODR4, .str = LPC_STR4 },
> };
>
>-static struct kcs_bmc *aspeed_kcs_probe_of_v1(struct platform_device *pdev)
>+static int aspeed_kcs_of_v1_get_channel(struct platform_device *pdev)
> {
>-	struct aspeed_kcs_bmc *priv;
> 	struct device_node *np;
>-	struct kcs_bmc *kcs;
> 	u32 channel;
>-	u32 slave;
> 	int rc;
>
> 	np = pdev->dev.of_node;
>@@ -245,105 +247,78 @@ static struct kcs_bmc *aspeed_kcs_probe_of_v1(struct platform_device *pdev)
> 	rc = of_property_read_u32(np, "kcs_chan", &channel);
> 	if ((rc != 0) || (channel == 0 || channel > KCS_CHANNEL_MAX)) {
> 		dev_err(&pdev->dev, "no valid 'kcs_chan' configured\n");
>-		return ERR_PTR(-EINVAL);
>+		return -EINVAL;
> 	}
>
>-	kcs = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>-	if (!kcs)
>-		return ERR_PTR(-ENOMEM);
>+	return channel;
>+}
>
>-	priv = kcs_bmc_priv(kcs);
>-	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>-	if (IS_ERR(priv->map)) {
>-		dev_err(&pdev->dev, "Couldn't get regmap\n");
>-		return ERR_PTR(-ENODEV);
>-	}
>+static int aspeed_kcs_of_v1_get_io_address(struct platform_device *pdev)
>+{
>+	u32 slave;
>+	int rc;
>
>-	rc = of_property_read_u32(np, "kcs_addr", &slave);
>-	if (rc) {
>+	rc = of_property_read_u32(pdev->dev.of_node, "kcs_addr", &slave);
>+	if (rc || slave > 0xffff) {
> 		dev_err(&pdev->dev, "no valid 'kcs_addr' configured\n");
>-		return ERR_PTR(-EINVAL);
>+		return -EINVAL;
> 	}
>
>-	kcs->ioreg = ast_kcs_bmc_ioregs[channel - 1];
>-	aspeed_kcs_set_address(kcs, slave);
>-
>-	return kcs;
>-}
>-
>-static int aspeed_kcs_calculate_channel(const struct kcs_ioreg *regs)
>-{
>-	int i;
>-
>-	for (i = 0; i < ARRAY_SIZE(ast_kcs_bmc_ioregs); i++) {
>-		if (!memcmp(&ast_kcs_bmc_ioregs[i], regs, sizeof(*regs)))
>-			return i + 1;
>-	}
>-
>-	return -EINVAL;
>+	return slave;
> }
>
>-static struct kcs_bmc *aspeed_kcs_probe_of_v2(struct platform_device *pdev)
>+static int aspeed_kcs_of_v2_get_channel(struct platform_device *pdev)
> {
>-	struct aspeed_kcs_bmc *priv;
> 	struct device_node *np;
> 	struct kcs_ioreg ioreg;
>-	struct kcs_bmc *kcs;
> 	const __be32 *reg;
>-	int channel;
>-	u32 slave;
>-	int rc;
>+	int i;
>
> 	np = pdev->dev.of_node;
>
> 	/* Don't translate addresses, we want offsets for the regmaps */
> 	reg = of_get_address(np, 0, NULL, NULL);
> 	if (!reg)
>-		return ERR_PTR(-EINVAL);
>+		return -EINVAL;
> 	ioreg.idr = be32_to_cpup(reg);
>
> 	reg = of_get_address(np, 1, NULL, NULL);
> 	if (!reg)
>-		return ERR_PTR(-EINVAL);
>+		return -EINVAL;
> 	ioreg.odr = be32_to_cpup(reg);
>
> 	reg = of_get_address(np, 2, NULL, NULL);
> 	if (!reg)
>-		return ERR_PTR(-EINVAL);
>+		return -EINVAL;
> 	ioreg.str = be32_to_cpup(reg);
>
>-	channel = aspeed_kcs_calculate_channel(&ioreg);
>-	if (channel < 0)
>-		return ERR_PTR(channel);
>-
>-	kcs = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>-	if (!kcs)
>-		return ERR_PTR(-ENOMEM);
>-
>-	kcs->ioreg = ioreg;
>-
>-	priv = kcs_bmc_priv(kcs);
>-	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>-	if (IS_ERR(priv->map)) {
>-		dev_err(&pdev->dev, "Couldn't get regmap\n");
>-		return ERR_PTR(-ENODEV);
>+	for (i = 0; i < ARRAY_SIZE(ast_kcs_bmc_ioregs); i++) {
>+		if (!memcmp(&ast_kcs_bmc_ioregs[i], &ioreg, sizeof(ioreg)))
>+			return i + 1;

Did some patches perhaps get a bit jumbled during a rebase here or
something?  This patch removes the only initialization of priv->map
I can see, with patch #10 later reintroducing it, but in the interim
it seems like it would be in a fairly broken state (I'm guessing its
removal wasn't really intended to be part of this).

> 	}
>
>-	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &slave);
>-	if (rc)
>-		return ERR_PTR(rc);
>+	return -EINVAL;
>+}
>
>-	aspeed_kcs_set_address(kcs, slave);
>+static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
>+{
>+	uint32_t slave;
>+	int rc;
>
>-	return kcs;
>+	rc = of_property_read_u32(pdev->dev.of_node, "aspeed,lpc-io-reg", &slave);
>+	if (rc || slave > 0xffff)
>+		return -EINVAL;
>+
>+	return slave;
> }
>
> static int aspeed_kcs_probe(struct platform_device *pdev)
> {
>+	const struct aspeed_kcs_of_ops *ops;
> 	struct device *dev = &pdev->dev;
> 	struct kcs_bmc *kcs_bmc;
> 	struct device_node *np;
>-	int rc;
>+	int rc, channel, addr;
>
> 	np = dev->of_node->parent;
> 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
>@@ -352,23 +327,28 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 		dev_err(dev, "unsupported LPC device binding\n");
> 		return -ENODEV;
> 	}
>-
>-	np = dev->of_node;
>-	if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc") ||
>-	    of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc"))
>-		kcs_bmc = aspeed_kcs_probe_of_v1(pdev);
>-	else if (of_device_is_compatible(np, "aspeed,ast2400-kcs-bmc-v2") ||
>-		 of_device_is_compatible(np, "aspeed,ast2500-kcs-bmc-v2"))
>-		kcs_bmc = aspeed_kcs_probe_of_v2(pdev);
>-	else
>+	ops = of_device_get_match_data(&pdev->dev);
>+	if (!ops)
> 		return -EINVAL;
>
>-	if (IS_ERR(kcs_bmc))
>-		return PTR_ERR(kcs_bmc);
>+	channel = ops->get_channel(pdev);
>+	if (channel < 0)
>+		return channel;
>
>+	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>+	if (!kcs_bmc)
>+		return -ENOMEM;
>+
>+	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
> 	kcs_bmc->io_inputb = aspeed_kcs_inb;
> 	kcs_bmc->io_outputb = aspeed_kcs_outb;
>
>+	addr = ops->get_io_address(pdev);
>+	if (addr < 0)
>+		return addr;
>+
>+	aspeed_kcs_set_address(kcs_bmc, addr);
>+
> 	rc = aspeed_kcs_config_irq(kcs_bmc, pdev);
> 	if (rc)
> 		return rc;
>@@ -400,11 +380,21 @@ static int aspeed_kcs_remove(struct platform_device *pdev)
> 	return 0;
> }
>
>+static const struct aspeed_kcs_of_ops of_v1_ops = {
>+	.get_channel = aspeed_kcs_of_v1_get_channel,
>+	.get_io_address = aspeed_kcs_of_v1_get_io_address,
>+};
>+
>+static const struct aspeed_kcs_of_ops of_v2_ops = {
>+	.get_channel = aspeed_kcs_of_v2_get_channel,
>+	.get_io_address = aspeed_kcs_of_v2_get_io_address,
>+};
>+
> static const struct of_device_id ast_kcs_bmc_match[] = {
>-	{ .compatible = "aspeed,ast2400-kcs-bmc" },
>-	{ .compatible = "aspeed,ast2500-kcs-bmc" },
>-	{ .compatible = "aspeed,ast2400-kcs-bmc-v2" },
>-	{ .compatible = "aspeed,ast2500-kcs-bmc-v2" },
>+	{ .compatible = "aspeed,ast2400-kcs-bmc", .data = &of_v1_ops },
>+	{ .compatible = "aspeed,ast2500-kcs-bmc", .data = &of_v1_ops },
>+	{ .compatible = "aspeed,ast2400-kcs-bmc-v2", .data = &of_v2_ops },
>+	{ .compatible = "aspeed,ast2500-kcs-bmc-v2", .data = &of_v2_ops },
> 	{ }
> };
> MODULE_DEVICE_TABLE(of, ast_kcs_bmc_match);
>-- 
>2.27.0
>

From nina-cm.wu at mediatek.com  Fri Apr  9 04:30:30 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 11:30:30 +0800
Subject: [PATCH v2 1/6] dt-bindings: devapc: Update bindings
In-Reply-To: <20210408204354.GA1926089@robh.at.kernel.org>
References: <1617259087-5502-1-git-send-email-nina-cm.wu@mediatek.com>
 <20210408204354.GA1926089@robh.at.kernel.org>
Message-ID: <1617939030.29552.2.camel@mtksdccf07>

Hi, Rob

On Thu, 2021-04-08 at 15:43 -0500, Rob Herring wrote:
> On Thu, Apr 01, 2021 at 02:38:02PM +0800, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> Every change is an 'update'. Perhaps mention mt8192 in the subject.
> 

OK.
I will try to make it clear in the next version.

> > 
> > To support newer hardware architecture of devapc,
> > update device tree bindings.
> > 
> > Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> > ---
> >  Documentation/devicetree/bindings/soc/mediatek/devapc.yaml | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > index 31e4d3c..42b284e 100644
> > --- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > @@ -20,11 +20,17 @@ properties:
> >    compatible:
> >      enum:
> >        - mediatek,mt6779-devapc
> > +      - mediatek,mt8192-devapc
> >  
> >    reg:
> >      description: The base address of devapc register bank
> >      maxItems: 1
> >  
> > +  vio-idx-num:
> 
> Needs a vendor prefix.

OK.
I will fix it in the next version.

Thanks.

> 
> > +    description: The number of the devices controlled by devapc
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    maxItems: 1
> > +
> >    interrupts:
> >      description: A single interrupt specifier
> >      maxItems: 1
> > @@ -40,6 +46,7 @@ properties:
> >  required:
> >    - compatible
> >    - reg
> > +  - vio-idx-num
> >    - interrupts
> >    - clocks
> >    - clock-names
> > @@ -54,6 +61,7 @@ examples:
> >      devapc: devapc at 10207000 {
> >        compatible = "mediatek,mt6779-devapc";
> >        reg = <0x10207000 0x1000>;
> > +      vio-idx-num = <511>;
> >        interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
> >        clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>;
> >        clock-names = "devapc-infra-clock";
> > -- 
> > 2.6.4
> > 


From joel at jms.id.au  Fri Apr  9 04:35:34 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 03:35:34 +0000
Subject: [PATCH v2 03/21] ipmi: kcs: aspeed: Adapt to new LPC DTS layout
In-Reply-To: <20210319062752.145730-3-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-3-andrew@aj.id.au>
Message-ID: <CACPK8XfkvBA+9_WFb96oEa4F1vDPd90hG+M2Y-Ek=Xt5FUFqmQ@mail.gmail.com>

On Fri, 19 Mar 2021 at 06:28, Andrew Jeffery <andrew at aj.id.au> wrote:
>
> From: "Chia-Wei, Wang" <chiawei_wang at aspeedtech.com>
>
> Add check against LPC device v2 compatible string to
> ensure that the fixed device tree layout is adopted.
> The LPC register offsets are also fixed accordingly.
>
> Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> Reviewed-by: Andrew Jeffery <andrew at aj.id.au>
> Acked-by: Haiyue Wang <haiyue.wang at linux.intel.com>

Reviewed-by: Joel Stanley <joel at jms.id.au>


From wangyanan55 at huawei.com  Fri Apr  9 04:36:50 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Fri, 9 Apr 2021 11:36:50 +0800
Subject: [PATCH v4 0/2] KVM: arm64: Improve efficiency of stage2 page table
Message-ID: <20210409033652.28316-1-wangyanan55@huawei.com>

Hi,

This series makes some efficiency improvement of stage2 page table code,
and there are some test results to quantify the benefit of each patch.

Changelogs:
v3->v4:
- perform D-cache flush if we are not mapping device memory
- rebased on top of mainline v5.12-rc6
- v3: https://lore.kernel.org/lkml/20210326031654.3716-1-wangyanan55 at huawei.com/

v2->v3:
- drop patch #3 in v2
- retest v3 based on v5.12-rc2
- v2: https://lore.kernel.org/lkml/20210310094319.18760-1-wangyanan55 at huawei.com/

v1->v2:
- rebased on top of mainline v5.12-rc2
- also move CMOs of I-cache to the fault handlers
- retest v2 based on v5.12-rc2
- v1: https://lore.kernel.org/lkml/20210208112250.163568-1-wangyanan55 at huawei.com/

About this v4 series:
Patch #1:
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.

By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the page table code.

So let's move both clean of D-cache and invalidation of I-cache to the
map path and move only invalidation of I-cache to the permission path.
Since the original APIs for CMOs in mmu.c are only called in function
user_mem_abort, we now also move them to pgtable.c.

After this patch, in function stage2_map_walker_try_leaf (map path),
we flush D-cache if we are not mapping device memory and invalidate
I-cache if we are adding executable permission. And in the function
stage2_attr_walker (permission path), we invalidate I-cache if we are
adding executable permission. The logic is consistent with current
code in user_mem_abort (without this patch).

The following results represent the benefit of patch #1 alone, and they
were tested by [1] (kvm/selftest) that I have posted recently.
[1] https://lore.kernel.org/lkml/20210302125751.19080-1-wangyanan55 at huawei.com/

When there are muitiple vcpus concurrently accessing the same memory region,
we can test the execution time of KVM creating new mappings, updating the
permissions of old mappings from RO to RW, and rebuilding the blocks after
they have been split.

hardware platform: HiSilicon Kunpeng920 Server
host kernel: Linux mainline v5.12-rc2

cmdline: ./kvm_page_table_test -m 4 -s anonymous -b 1G -v 80
           (80 vcpus, 1G memory, page mappings(normal 4K))
KVM_CREATE_MAPPINGS: before 104.35s -> after  90.42s  +13.35%
KVM_UPDATE_MAPPINGS: before  78.64s -> after  75.45s  + 4.06%

cmdline: ./kvm_page_table_test -m 4 -s anonymous_thp -b 20G -v 40
           (40 vcpus, 20G memory, block mappings(THP 2M))
KVM_CREATE_MAPPINGS: before  15.66s -> after   6.92s  +55.80%
KVM_UPDATE_MAPPINGS: before 178.80s -> after 123.35s  +31.00%
KVM_REBUILD_BLOCKS:  before 187.34s -> after 131.76s  +30.65%

cmdline: ./kvm_page_table_test -m 4 -s anonymous_hugetlb_1gb -b 20G -v 40
           (40 vcpus, 20G memory, block mappings(HUGETLB 1G))
KVM_CREATE_MAPPINGS: before 104.54s -> after   3.70s  +96.46%
KVM_UPDATE_MAPPINGS: before 174.20s -> after 115.94s  +33.44%
KVM_REBUILD_BLOCKS:  before 103.95s -> after   2.96s  +97.15%

Patch #2:
A new method to distinguish cases of memcache allocations is introduced.
By comparing fault_granule and vma_pagesize, cases that require allocations
from memcache and cases that don't can be distinguished completely.

Yanan Wang (2):
  KVM: arm64: Move CMOs from user_mem_abort to the fault handlers
  KVM: arm64: Distinguish cases of memcache allocations completely

 arch/arm64/include/asm/kvm_mmu.h | 31 ---------------
 arch/arm64/kvm/hyp/pgtable.c     | 68 +++++++++++++++++++++++++-------
 arch/arm64/kvm/mmu.c             | 48 ++++++++--------------
 3 files changed, 69 insertions(+), 78 deletions(-)

-- 
2.19.1



From wangyanan55 at huawei.com  Fri Apr  9 04:36:51 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Fri, 9 Apr 2021 11:36:51 +0800
Subject: [PATCH v4 1/2] KVM: arm64: Move CMOs from user_mem_abort to the fault
 handlers
In-Reply-To: <20210409033652.28316-1-wangyanan55@huawei.com>
References: <20210409033652.28316-1-wangyanan55@huawei.com>
Message-ID: <20210409033652.28316-2-wangyanan55@huawei.com>

We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.

By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the page table code.

So let's move both clean of D-cache and invalidation of I-cache to the
map path and move only invalidation of I-cache to the permission path.
Since the original APIs for CMOs in mmu.c are only called in function
user_mem_abort, we now also move them to pgtable.c.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 31 ---------------
 arch/arm64/kvm/hyp/pgtable.c     | 68 +++++++++++++++++++++++++-------
 arch/arm64/kvm/mmu.c             | 23 ++---------
 3 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 90873851f677..c31f88306d4e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -177,37 +177,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 	return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
 }
 
-static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	void *va = page_address(pfn_to_page(pfn));
-
-	/*
-	 * With FWB, we ensure that the guest always accesses memory using
-	 * cacheable attributes, and we don't have to clean to PoC when
-	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
-	 * PoU is not required either in this case.
-	 */
-	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
-		return;
-
-	kvm_flush_dcache_to_poc(va, size);
-}
-
-static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
-						  unsigned long size)
-{
-	if (icache_is_aliasing()) {
-		/* any kind of VIPT cache */
-		__flush_icache_all();
-	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
-		/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */
-		void *va = page_address(pfn_to_page(pfn));
-
-		invalidate_icache_range((unsigned long)va,
-					(unsigned long)va + size);
-	}
-}
-
 void kvm_set_way_flush(struct kvm_vcpu *vcpu);
 void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
 
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 4d177ce1d536..0e811c86fd06 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -464,6 +464,43 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot prot,
 	return 0;
 }
 
+static bool stage2_pte_cacheable(kvm_pte_t pte)
+{
+	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
+	return memattr == PAGE_S2_MEMATTR(NORMAL);
+}
+
+static bool stage2_pte_executable(kvm_pte_t pte)
+{
+	return !(pte & KVM_PTE_LEAF_ATTR_HI_S2_XN);
+}
+
+static void stage2_flush_dcache(void *addr, u64 size)
+{
+	/*
+	 * With FWB, we ensure that the guest always accesses memory using
+	 * cacheable attributes, and we don't have to clean to PoC when
+	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
+	 * PoU is not required either in this case.
+	 */
+	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
+		return;
+
+	__flush_dcache_area(addr, size);
+}
+
+static void stage2_invalidate_icache(void *addr, u64 size)
+{
+	if (icache_is_aliasing()) {
+		/* Flush any kind of VIPT icache */
+		__flush_icache_all();
+	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
+		/* PIPT or VPIPT at EL2 */
+		invalidate_icache_range((unsigned long)addr,
+					(unsigned long)addr + size);
+	}
+}
+
 static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 				      kvm_pte_t *ptep,
 				      struct stage2_map_data *data)
@@ -495,6 +532,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 		put_page(page);
 	}
 
+	/* Perform CMOs before installation of the new PTE */
+	if (stage2_pte_cacheable(new))
+		stage2_flush_dcache(__va(phys), granule);
+
+	if (stage2_pte_executable(new))
+		stage2_invalidate_icache(__va(phys), granule);
+
 	smp_store_release(ptep, new);
 	get_page(page);
 	data->phys += granule;
@@ -651,20 +695,6 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
 	return ret;
 }
 
-static void stage2_flush_dcache(void *addr, u64 size)
-{
-	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
-		return;
-
-	__flush_dcache_area(addr, size);
-}
-
-static bool stage2_pte_cacheable(kvm_pte_t pte)
-{
-	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
-	return memattr == PAGE_S2_MEMATTR(NORMAL);
-}
-
 static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 			       enum kvm_pgtable_walk_flags flag,
 			       void * const arg)
@@ -743,8 +773,16 @@ static int stage2_attr_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 	 * but worst-case the access flag update gets lost and will be
 	 * set on the next access instead.
 	 */
-	if (data->pte != pte)
+	if (data->pte != pte) {
+		/*
+		 * Invalidate the instruction cache before updating
+		 * if we are going to add the executable permission.
+		 */
+		if (!stage2_pte_executable(*ptep) && stage2_pte_executable(pte))
+			stage2_invalidate_icache(kvm_pte_follow(pte),
+						 kvm_granule_size(level));
 		WRITE_ONCE(*ptep, pte);
+	}
 
 	return 0;
 }
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f2a4..1eec9f63bc6f 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -609,16 +609,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
 	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
 }
 
-static void clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	__clean_dcache_guest_page(pfn, size);
-}
-
-static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	__invalidate_icache_guest_page(pfn, size);
-}
-
 static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
 {
 	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
@@ -882,13 +872,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (writable)
 		prot |= KVM_PGTABLE_PROT_W;
 
-	if (fault_status != FSC_PERM && !device)
-		clean_dcache_guest_page(pfn, vma_pagesize);
-
-	if (exec_fault) {
+	if (exec_fault)
 		prot |= KVM_PGTABLE_PROT_X;
-		invalidate_icache_guest_page(pfn, vma_pagesize);
-	}
 
 	if (device)
 		prot |= KVM_PGTABLE_PROT_DEVICE;
@@ -1144,10 +1129,10 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 	trace_kvm_set_spte_hva(hva);
 
 	/*
-	 * We've moved a page around, probably through CoW, so let's treat it
-	 * just like a translation fault and clean the cache to the PoC.
+	 * We've moved a page around, probably through CoW, so let's treat
+	 * it just like a translation fault and the map handler will clean
+	 * the cache to the PoC.
 	 */
-	clean_dcache_guest_page(pfn, PAGE_SIZE);
 	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
 	return 0;
 }
-- 
2.19.1



From wangyanan55 at huawei.com  Fri Apr  9 04:36:52 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Fri, 9 Apr 2021 11:36:52 +0800
Subject: [PATCH v4 2/2] KVM: arm64: Distinguish cases of memcache allocations
 completely
In-Reply-To: <20210409033652.28316-1-wangyanan55@huawei.com>
References: <20210409033652.28316-1-wangyanan55@huawei.com>
Message-ID: <20210409033652.28316-3-wangyanan55@huawei.com>

With a guest translation fault, the memcache pages are not needed if KVM
is only about to install a new leaf entry into the existing page table.
And with a guest permission fault, the memcache pages are also not needed
for a write_fault in dirty-logging time if KVM is only about to update
the existing leaf entry instead of collapsing a block entry into a table.

By comparing fault_granule and vma_pagesize, cases that require allocations
from memcache and cases that don't can be distinguished completely.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 1eec9f63bc6f..05af40dc60c1 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -810,19 +810,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	gfn = fault_ipa >> PAGE_SHIFT;
 	mmap_read_unlock(current->mm);
 
-	/*
-	 * Permission faults just need to update the existing leaf entry,
-	 * and so normally don't require allocations from the memcache. The
-	 * only exception to this is when dirty logging is enabled at runtime
-	 * and a write fault needs to collapse a block entry into a table.
-	 */
-	if (fault_status != FSC_PERM || (logging_active && write_fault)) {
-		ret = kvm_mmu_topup_memory_cache(memcache,
-						 kvm_mmu_cache_min_pages(kvm));
-		if (ret)
-			return ret;
-	}
-
 	mmu_seq = vcpu->kvm->mmu_notifier_seq;
 	/*
 	 * Ensure the read of mmu_notifier_seq happens before we call
@@ -880,6 +867,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
 		prot |= KVM_PGTABLE_PROT_X;
 
+	/*
+	 * Allocations from the memcache are required only when granule of the
+	 * lookup level where the guest fault happened exceeds vma_pagesize,
+	 * which means new page tables will be created in the fault handlers.
+	 */
+	if (fault_granule > vma_pagesize) {
+		ret = kvm_mmu_topup_memory_cache(memcache,
+						 kvm_mmu_cache_min_pages(kvm));
+		if (ret)
+			return ret;
+	}
+
 	/*
 	 * Under the premise of getting a FSC_PERM fault, we just need to relax
 	 * permissions only if vma_pagesize equals fault_granule. Otherwise,
-- 
2.19.1



From joel at jms.id.au  Fri Apr  9 04:36:57 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 03:36:57 +0000
Subject: [PATCH v2 04/21] pinctrl: aspeed-g5: Adapt to new LPC device tree
 layout
In-Reply-To: <20210319062752.145730-4-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-4-andrew@aj.id.au>
Message-ID: <CACPK8Xfre_HriZXa10GVRvzxM51_6jkxCrXi-Ofto6cCKcLw4g@mail.gmail.com>

On Fri, 19 Mar 2021 at 06:28, Andrew Jeffery <andrew at aj.id.au> wrote:
>
> From: "Chia-Wei, Wang" <chiawei_wang at aspeedtech.com>
>
> Add check against LPC device v2 compatible string to
> ensure that the fixed device tree layout is adopted.
> The LPC register offsets are also fixed accordingly.
>
> Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> Reviewed-by: Andrew Jeffery <andrew at aj.id.au>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>

Reviewed-by: Joel Stanley <joel at jms.id.au>


From f.fainelli at gmail.com  Fri Apr  9 04:37:21 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 8 Apr 2021 20:37:21 -0700
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
Message-ID: <632cbdec-e477-212c-f5a8-81151915fdeb@gmail.com>



On 4/8/2021 8:08 AM, Arnd Bergmann wrote:
> Greetings to all Arm platform maintainers,
> 
> I've just gone through the DT merges I've received so far and, with a
> little help from Rob,
> managed to run 'make dtbs_check W=1' before and after, to see what
> warnings we get.
> The good news is that the number of warnings is going down, but
> unfortunately there
> is still an unmanageable amount of remaining warnings, and some new
> ones crept in.
> 
> I'm still working on my tooling for this, to catch these better, but
> ideally I think we should
> try to not introduce new warnings. I think some platforms are already
> clean, and I did
> not see any new warnings for mvebu, samsung and broadcom. There were a lot of
> warnings from .dtsi files, and I probably did an incomplete job at
> deduplicating those.

There are definitively a ton of warnings for Broacom DTS files, a number
of those warnings exist because the bindings were not converted to YAML.
Rafal, do you think you could help me with taking care of the
BCM5301X/4908 warnings?
-- 
Florian


From joel at jms.id.au  Fri Apr  9 04:38:36 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 03:38:36 +0000
Subject: [PATCH v2 05/21] soc: aspeed: Adapt to new LPC device tree layout
In-Reply-To: <20210319062752.145730-5-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-5-andrew@aj.id.au>
Message-ID: <CACPK8XcFX9Ljo8K9XzhtCnTXKS0muknzrV6=SU6Wh5jJSPdNAg@mail.gmail.com>

On Fri, 19 Mar 2021 at 06:28, Andrew Jeffery <andrew at aj.id.au> wrote:
>
> From: "Chia-Wei, Wang" <chiawei_wang at aspeedtech.com>
>
> Add check against LPC device v2 compatible string to
> ensure that the fixed device tree layout is adopted.
> The LPC register offsets are also fixed accordingly.
>
> Signed-off-by: Chia-Wei Wang <chiawei_wang at aspeedtech.com>
> Reviewed-by: Andrew Jeffery <andrew at aj.id.au>

Reviewed-by: Joel Stanley <joel at jms.id.au>


From lushenming at huawei.com  Fri Apr  9 04:44:17 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:17 +0800
Subject: [RFC PATCH v3 5/8] vfio/type1: VFIO_IOMMU_ENABLE_IOPF
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-6-lushenming@huawei.com>

Since enabling IOPF for devices may lead to a slow ramp up of performance,
we add an ioctl VFIO_IOMMU_ENABLE_IOPF to make it configurable. And the
IOPF enabling of a VFIO device includes setting IOMMU_DEV_FEAT_IOPF and
registering the VFIO IOPF handler.

Note that VFIO_IOMMU_DISABLE_IOPF is not supported since there may be
inflight page faults when disabling.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio_iommu_type1.c | 223 +++++++++++++++++++++++++++++++-
 include/uapi/linux/vfio.h       |   6 +
 2 files changed, 226 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 01e296c6dc9e..7df5711e743a 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -71,6 +71,7 @@ struct vfio_iommu {
 	struct rb_root		dma_list;
 	struct blocking_notifier_head notifier;
 	struct mmu_notifier	mn;
+	struct mm_struct	*mm;
 	unsigned int		dma_avail;
 	unsigned int		vaddr_invalid_count;
 	uint64_t		pgsize_bitmap;
@@ -81,6 +82,7 @@ struct vfio_iommu {
 	bool			dirty_page_tracking;
 	bool			pinned_page_dirty_scope;
 	bool			container_open;
+	bool			iopf_enabled;
 };
 
 struct vfio_domain {
@@ -461,6 +463,38 @@ vfio_find_iopf_group(struct iommu_group *iommu_group)
 	return node ? iopf_group : NULL;
 }
 
+static void vfio_link_iopf_group(struct vfio_iopf_group *new)
+{
+	struct rb_node **link, *parent = NULL;
+	struct vfio_iopf_group *iopf_group;
+
+	mutex_lock(&iopf_group_list_lock);
+
+	link = &iopf_group_list.rb_node;
+
+	while (*link) {
+		parent = *link;
+		iopf_group = rb_entry(parent, struct vfio_iopf_group, node);
+
+		if (new->iommu_group < iopf_group->iommu_group)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+
+	rb_link_node(&new->node, parent, link);
+	rb_insert_color(&new->node, &iopf_group_list);
+
+	mutex_unlock(&iopf_group_list_lock);
+}
+
+static void vfio_unlink_iopf_group(struct vfio_iopf_group *old)
+{
+	mutex_lock(&iopf_group_list_lock);
+	rb_erase(&old->node, &iopf_group_list);
+	mutex_unlock(&iopf_group_list_lock);
+}
+
 static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
 {
 	struct mm_struct *mm;
@@ -2363,6 +2397,68 @@ static void vfio_iommu_iova_insert_copy(struct vfio_iommu *iommu,
 	list_splice_tail(iova_copy, iova);
 }
 
+static int vfio_dev_domian_nested(struct device *dev, int *nested)
+{
+	struct iommu_domain *domain;
+
+	domain = iommu_get_domain_for_dev(dev);
+	if (!domain)
+		return -ENODEV;
+
+	return iommu_domain_get_attr(domain, DOMAIN_ATTR_NESTING, nested);
+}
+
+static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data);
+
+static int dev_enable_iopf(struct device *dev, void *data)
+{
+	int *enabled_dev_cnt = data;
+	int nested;
+	u32 flags;
+	int ret;
+
+	ret = iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_IOPF);
+	if (ret)
+		return ret;
+
+	ret = vfio_dev_domian_nested(dev, &nested);
+	if (ret)
+		goto out_disable;
+
+	if (nested)
+		flags = FAULT_REPORT_NESTED_L2;
+	else
+		flags = FAULT_REPORT_FLAT;
+
+	ret = iommu_register_device_fault_handler(dev,
+				vfio_iommu_type1_dma_map_iopf, flags, dev);
+	if (ret)
+		goto out_disable;
+
+	(*enabled_dev_cnt)++;
+	return 0;
+
+out_disable:
+	iommu_dev_disable_feature(dev, IOMMU_DEV_FEAT_IOPF);
+	return ret;
+}
+
+static int dev_disable_iopf(struct device *dev, void *data)
+{
+	int *enabled_dev_cnt = data;
+
+	if (enabled_dev_cnt && *enabled_dev_cnt <= 0)
+		return -1;
+
+	WARN_ON(iommu_unregister_device_fault_handler(dev));
+	WARN_ON(iommu_dev_disable_feature(dev, IOMMU_DEV_FEAT_IOPF));
+
+	if (enabled_dev_cnt)
+		(*enabled_dev_cnt)--;
+
+	return 0;
+}
+
 static int vfio_iommu_type1_attach_group(void *iommu_data,
 					 struct iommu_group *iommu_group)
 {
@@ -2376,6 +2472,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	struct iommu_domain_geometry geo;
 	LIST_HEAD(iova_copy);
 	LIST_HEAD(group_resv_regions);
+	int iopf_enabled_dev_cnt = 0;
+	struct vfio_iopf_group *iopf_group = NULL;
 
 	mutex_lock(&iommu->lock);
 
@@ -2453,6 +2551,24 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	if (ret)
 		goto out_domain;
 
+	if (iommu->iopf_enabled) {
+		ret = iommu_group_for_each_dev(iommu_group, &iopf_enabled_dev_cnt,
+					       dev_enable_iopf);
+		if (ret)
+			goto out_detach;
+
+		iopf_group = kzalloc(sizeof(*iopf_group), GFP_KERNEL);
+		if (!iopf_group) {
+			ret = -ENOMEM;
+			goto out_detach;
+		}
+
+		iopf_group->iommu_group = iommu_group;
+		iopf_group->iommu = iommu;
+
+		vfio_link_iopf_group(iopf_group);
+	}
+
 	/* Get aperture info */
 	iommu_domain_get_attr(domain->domain, DOMAIN_ATTR_GEOMETRY, &geo);
 
@@ -2534,9 +2650,11 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	vfio_test_domain_fgsp(domain);
 
 	/* replay mappings on new domains */
-	ret = vfio_iommu_replay(iommu, domain);
-	if (ret)
-		goto out_detach;
+	if (!iommu->iopf_enabled) {
+		ret = vfio_iommu_replay(iommu, domain);
+		if (ret)
+			goto out_detach;
+	}
 
 	if (resv_msi) {
 		ret = iommu_get_msi_cookie(domain->domain, resv_msi_base);
@@ -2567,6 +2685,15 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	iommu_domain_free(domain->domain);
 	vfio_iommu_iova_free(&iova_copy);
 	vfio_iommu_resv_free(&group_resv_regions);
+	if (iommu->iopf_enabled) {
+		if (iopf_group) {
+			vfio_unlink_iopf_group(iopf_group);
+			kfree(iopf_group);
+		}
+
+		iommu_group_for_each_dev(iommu_group, &iopf_enabled_dev_cnt,
+					 dev_disable_iopf);
+	}
 out_free:
 	kfree(domain);
 	kfree(group);
@@ -2728,6 +2855,19 @@ static void vfio_iommu_type1_detach_group(void *iommu_data,
 		if (!group)
 			continue;
 
+		if (iommu->iopf_enabled) {
+			struct vfio_iopf_group *iopf_group;
+
+			iopf_group = vfio_find_iopf_group(iommu_group);
+			if (!WARN_ON(!iopf_group)) {
+				vfio_unlink_iopf_group(iopf_group);
+				kfree(iopf_group);
+			}
+
+			iommu_group_for_each_dev(iommu_group, NULL,
+						 dev_disable_iopf);
+		}
+
 		vfio_iommu_detach_group(domain, group);
 		update_dirty_scope = !group->pinned_page_dirty_scope;
 		list_del(&group->next);
@@ -2846,6 +2986,11 @@ static void vfio_iommu_type1_release(void *iommu_data)
 
 	vfio_iommu_iova_free(&iommu->iova_list);
 
+	if (iommu->iopf_enabled) {
+		mmu_notifier_unregister(&iommu->mn, iommu->mm);
+		mmdrop(iommu->mm);
+	}
+
 	kfree(iommu);
 }
 
@@ -3441,6 +3586,76 @@ static const struct mmu_notifier_ops vfio_iommu_type1_mn_ops = {
 	.invalidate_range	= mn_invalidate_range,
 };
 
+static int vfio_iommu_type1_enable_iopf(struct vfio_iommu *iommu)
+{
+	struct vfio_domain *d;
+	struct vfio_group *g;
+	struct vfio_iopf_group *iopf_group;
+	int enabled_dev_cnt = 0;
+	int ret;
+
+	if (!current->mm)
+		return -ENODEV;
+
+	mutex_lock(&iommu->lock);
+
+	mmgrab(current->mm);
+	iommu->mm = current->mm;
+	iommu->mn.ops = &vfio_iommu_type1_mn_ops;
+	ret = mmu_notifier_register(&iommu->mn, current->mm);
+	if (ret)
+		goto out_drop;
+
+	list_for_each_entry(d, &iommu->domain_list, next) {
+		list_for_each_entry(g, &d->group_list, next) {
+			ret = iommu_group_for_each_dev(g->iommu_group,
+					&enabled_dev_cnt, dev_enable_iopf);
+			if (ret)
+				goto out_unwind;
+
+			iopf_group = kzalloc(sizeof(*iopf_group), GFP_KERNEL);
+			if (!iopf_group) {
+				ret = -ENOMEM;
+				goto out_unwind;
+			}
+
+			iopf_group->iommu_group = g->iommu_group;
+			iopf_group->iommu = iommu;
+
+			vfio_link_iopf_group(iopf_group);
+		}
+	}
+
+	iommu->iopf_enabled = true;
+	goto out_unlock;
+
+out_unwind:
+	list_for_each_entry(d, &iommu->domain_list, next) {
+		list_for_each_entry(g, &d->group_list, next) {
+			iopf_group = vfio_find_iopf_group(g->iommu_group);
+			if (iopf_group) {
+				vfio_unlink_iopf_group(iopf_group);
+				kfree(iopf_group);
+			}
+
+			if (iommu_group_for_each_dev(g->iommu_group,
+					&enabled_dev_cnt, dev_disable_iopf))
+				goto out_unregister;
+		}
+	}
+
+out_unregister:
+	mmu_notifier_unregister(&iommu->mn, current->mm);
+
+out_drop:
+	iommu->mm = NULL;
+	mmdrop(current->mm);
+
+out_unlock:
+	mutex_unlock(&iommu->lock);
+	return ret;
+}
+
 static long vfio_iommu_type1_ioctl(void *iommu_data,
 				   unsigned int cmd, unsigned long arg)
 {
@@ -3457,6 +3672,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 		return vfio_iommu_type1_unmap_dma(iommu, arg);
 	case VFIO_IOMMU_DIRTY_PAGES:
 		return vfio_iommu_type1_dirty_pages(iommu, arg);
+	case VFIO_IOMMU_ENABLE_IOPF:
+		return vfio_iommu_type1_enable_iopf(iommu);
 	default:
 		return -ENOTTY;
 	}
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 8ce36c1d53ca..5497036bebdc 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -1208,6 +1208,12 @@ struct vfio_iommu_type1_dirty_bitmap_get {
 
 #define VFIO_IOMMU_DIRTY_PAGES             _IO(VFIO_TYPE, VFIO_BASE + 17)
 
+/*
+ * IOCTL to enable IOPF for the container.
+ * Called right after VFIO_SET_IOMMU.
+ */
+#define VFIO_IOMMU_ENABLE_IOPF             _IO(VFIO_TYPE, VFIO_BASE + 18)
+
 /* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
 
 /*
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:18 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:18 +0800
Subject: [RFC PATCH v3 6/8] vfio/type1: No need to statically pin and map if
 IOPF enabled
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-7-lushenming@huawei.com>

If IOPF enabled for the VFIO container, there is no need to statically
pin and map the entire DMA range, we can do it on demand. And unmap
according to the IOPF mapped bitmap when removing vfio_dma.

Note that we still mark all pages dirty even if IOPF enabled, we may
add IOPF-based fine grained dirty tracking support in the future.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio_iommu_type1.c | 38 +++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 7df5711e743a..dcc93c3b258c 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -175,6 +175,7 @@ struct vfio_iopf_group {
 #define IOPF_MAPPED_BITMAP_GET(dma, i)	\
 			      ((dma->iopf_mapped_bitmap[(i) / BITS_PER_LONG]	\
 			       >> ((i) % BITS_PER_LONG)) & 0x1)
+#define IOPF_MAPPED_BITMAP_BYTES(n)	DIRTY_BITMAP_BYTES(n)
 
 #define WAITED 1
 
@@ -959,7 +960,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 	 * already pinned and accounted. Accouting should be done if there is no
 	 * iommu capable domain in the container.
 	 */
-	do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
+	do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) ||
+			iommu->iopf_enabled;
 
 	for (i = 0; i < npage; i++) {
 		struct vfio_pfn *vpfn;
@@ -1048,7 +1050,8 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
 
 	mutex_lock(&iommu->lock);
 
-	do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
+	do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) ||
+			iommu->iopf_enabled;
 	for (i = 0; i < npage; i++) {
 		struct vfio_dma *dma;
 		dma_addr_t iova;
@@ -1169,7 +1172,7 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma,
 	if (!dma->size)
 		return 0;
 
-	if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
+	if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) || iommu->iopf_enabled)
 		return 0;
 
 	/*
@@ -1306,11 +1309,20 @@ static void vfio_unmap_partial_iopf(struct vfio_iommu *iommu,
 	}
 }
 
+static void vfio_dma_clean_iopf(struct vfio_iommu *iommu, struct vfio_dma *dma)
+{
+	vfio_unmap_partial_iopf(iommu, dma, dma->iova, dma->iova + dma->size);
+
+	kfree(dma->iopf_mapped_bitmap);
+}
+
 static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
 {
 	WARN_ON(!RB_EMPTY_ROOT(&dma->pfn_list));
 	vfio_unmap_unpin(iommu, dma, true);
 	vfio_unlink_dma(iommu, dma);
+	if (iommu->iopf_enabled)
+		vfio_dma_clean_iopf(iommu, dma);
 	put_task_struct(dma->task);
 	vfio_dma_bitmap_free(dma);
 	if (dma->vaddr_invalid) {
@@ -1359,7 +1371,8 @@ static int update_user_bitmap(u64 __user *bitmap, struct vfio_iommu *iommu,
 	 * mark all pages dirty if any IOMMU capable device is not able
 	 * to report dirty pages and all pages are pinned and mapped.
 	 */
-	if (iommu->num_non_pinned_groups && dma->iommu_mapped)
+	if (iommu->num_non_pinned_groups &&
+	    (dma->iommu_mapped || iommu->iopf_enabled))
 		bitmap_set(dma->bitmap, 0, nbits);
 
 	if (shift) {
@@ -1772,6 +1785,16 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
 		goto out_unlock;
 	}
 
+	if (iommu->iopf_enabled) {
+		dma->iopf_mapped_bitmap = kvzalloc(IOPF_MAPPED_BITMAP_BYTES(
+						size >> PAGE_SHIFT), GFP_KERNEL);
+		if (!dma->iopf_mapped_bitmap) {
+			ret = -ENOMEM;
+			kfree(dma);
+			goto out_unlock;
+		}
+	}
+
 	iommu->dma_avail--;
 	dma->iova = iova;
 	dma->vaddr = vaddr;
@@ -1811,8 +1834,11 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
 	/* Insert zero-sized and grow as we map chunks of it */
 	vfio_link_dma(iommu, dma);
 
-	/* Don't pin and map if container doesn't contain IOMMU capable domain*/
-	if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
+	/*
+	 * Don't pin and map if container doesn't contain IOMMU capable domain,
+	 * or IOPF enabled for the container.
+	 */
+	if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) || iommu->iopf_enabled)
 		dma->size = size;
 	else
 		ret = vfio_pin_map_dma(iommu, dma, size);
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:13 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:13 +0800
Subject: [RFC PATCH v3 1/8] iommu: Evolve the device fault reporting framework
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-2-lushenming@huawei.com>

This patch follows the discussion here:

https://lore.kernel.org/linux-acpi/YAaxjmJW+ZMvrhac at myrica/

Besides SVA/vSVA, such as VFIO may also enable (2nd level) IOPF to remove
pinning restriction. In order to better support more scenarios of using
device faults, we extend iommu_register_fault_handler() with flags and
introduce FAULT_REPORT_ to describe the device fault reporting capability
under a specific configuration.

Note that we don't further distinguish recoverable and unrecoverable faults
by flags in the fault reporting cap, having PAGE_FAULT_REPORT_ +
UNRECOV_FAULT_REPORT_ seems not a clean way.

In addition, still take VFIO as an example, in nested mode, the 1st level
and 2nd level fault reporting may be configured separately and currently
each device can only register one iommu dev fault handler, so we add a
handler update interface for this.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  3 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 18 ++++--
 drivers/iommu/iommu.c                         | 56 ++++++++++++++++++-
 include/linux/iommu.h                         | 19 ++++++-
 include/uapi/linux/iommu.h                    |  4 ++
 5 files changed, 90 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 ee66d1f4cb81..e6d766fb8f1a 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
@@ -482,7 +482,8 @@ static int arm_smmu_master_sva_enable_iopf(struct arm_smmu_master *master)
 	if (ret)
 		return ret;
 
-	ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf, dev);
+	ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
+						  FAULT_REPORT_FLAT, dev);
 	if (ret) {
 		iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
 		return 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 53abad8fdd91..51843f54a87f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1448,10 +1448,6 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
 		return -EOPNOTSUPP;
 	}
 
-	/* Stage-2 is always pinned at the moment */
-	if (evt[1] & EVTQ_1_S2)
-		return -EFAULT;
-
 	if (evt[1] & EVTQ_1_RnW)
 		perm |= IOMMU_FAULT_PERM_READ;
 	else
@@ -1469,26 +1465,36 @@ static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
 			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
 			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
 			.perm = perm,
-			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
 		};
 
 		if (ssid_valid) {
 			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
 			flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
 		}
+
+		if (evt[1] & EVTQ_1_S2) {
+			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_L2;
+			flt->prm.addr = FIELD_GET(EVTQ_3_IPA, evt[3]);
+		} else
+			flt->prm.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]);
 	} else {
 		flt->type = IOMMU_FAULT_DMA_UNRECOV;
 		flt->event = (struct iommu_fault_unrecoverable) {
 			.reason = reason,
 			.flags = IOMMU_FAULT_UNRECOV_ADDR_VALID,
 			.perm = perm,
-			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
 		};
 
 		if (ssid_valid) {
 			flt->event.flags |= IOMMU_FAULT_UNRECOV_PASID_VALID;
 			flt->event.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
 		}
+
+		if (evt[1] & EVTQ_1_S2) {
+			flt->event.flags |= IOMMU_FAULT_UNRECOV_L2;
+			flt->event.addr = FIELD_GET(EVTQ_3_IPA, evt[3]);
+		} else
+			flt->event.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]);
 	}
 
 	mutex_lock(&smmu->streams_mutex);
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..b50b526b45ac 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1056,6 +1056,40 @@ int iommu_group_unregister_notifier(struct iommu_group *group,
 }
 EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
 
+/*
+ * iommu_update_device_fault_handler - Update the device fault handler via flags
+ * @dev: the device
+ * @mask: bits(not set) to clear
+ * @set: bits to set
+ *
+ * Update the device fault handler installed by
+ * iommu_register_device_fault_handler().
+ *
+ * Return 0 on success, or an error.
+ */
+int iommu_update_device_fault_handler(struct device *dev, u32 mask, u32 set)
+{
+	struct dev_iommu *param = dev->iommu;
+	int ret = 0;
+
+	if (!param)
+		return -EINVAL;
+
+	mutex_lock(&param->lock);
+
+	if (param->fault_param) {
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	param->fault_param->flags = (param->fault_param->flags & mask) | set;
+
+out_unlock:
+	mutex_unlock(&param->lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_update_device_fault_handler);
+
 /**
  * iommu_register_device_fault_handler() - Register a device fault handler
  * @dev: the device
@@ -1076,11 +1110,16 @@ EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
  */
 int iommu_register_device_fault_handler(struct device *dev,
 					iommu_dev_fault_handler_t handler,
-					void *data)
+					u32 flags, void *data)
 {
 	struct dev_iommu *param = dev->iommu;
 	int ret = 0;
 
+	/* Only under one configuration. */
+	if (flags & FAULT_REPORT_FLAT &&
+	    flags & (FAULT_REPORT_NESTED_L1 | FAULT_REPORT_NESTED_L2))
+		return -EINVAL;
+
 	if (!param)
 		return -EINVAL;
 
@@ -1099,6 +1138,7 @@ int iommu_register_device_fault_handler(struct device *dev,
 		goto done_unlock;
 	}
 	param->fault_param->handler = handler;
+	param->fault_param->flags = flags;
 	param->fault_param->data = data;
 	mutex_init(&param->fault_param->lock);
 	INIT_LIST_HEAD(&param->fault_param->faults);
@@ -1177,6 +1217,20 @@ int iommu_report_device_fault(struct device *dev, struct iommu_fault_event *evt)
 		goto done_unlock;
 	}
 
+	if (!(fparam->flags & FAULT_REPORT_FLAT)) {
+		bool l2;
+
+		if (evt->fault.type == IOMMU_FAULT_PAGE_REQ)
+			l2 = evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_L2;
+		if (evt->fault.type == IOMMU_FAULT_DMA_UNRECOV)
+			l2 = evt->fault.event.flags & IOMMU_FAULT_UNRECOV_L2;
+
+		if (l2 && !(fparam->flags & FAULT_REPORT_NESTED_L2))
+			return -EOPNOTSUPP;
+		if (!l2 && !(fparam->flags & FAULT_REPORT_NESTED_L1))
+			return -EOPNOTSUPP;
+	}
+
 	if (evt->fault.type == IOMMU_FAULT_PAGE_REQ &&
 	    (evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
 		evt_pending = kmemdup(evt, sizeof(struct iommu_fault_event),
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 86d688c4418f..28dbca3c6d60 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -352,12 +352,19 @@ struct iommu_fault_event {
 /**
  * struct iommu_fault_param - per-device IOMMU fault data
  * @handler: Callback function to handle IOMMU faults at device level
+ * @flags: FAULT_REPORT_ indicates the fault reporting capability under
+ *	   a specific configuration (1st/2nd-level-only(FLAT), or nested).
+ *	   Nested mode needs to specify which level/stage is concerned.
  * @data: handler private data
  * @faults: holds the pending faults which needs response
  * @lock: protect pending faults list
  */
 struct iommu_fault_param {
 	iommu_dev_fault_handler_t handler;
+#define FAULT_REPORT_FLAT			(1 << 0)
+#define FAULT_REPORT_NESTED_L1			(1 << 1)
+#define FAULT_REPORT_NESTED_L2			(1 << 2)
+	u32 flags;
 	void *data;
 	struct list_head faults;
 	struct mutex lock;
@@ -509,9 +516,11 @@ extern int iommu_group_register_notifier(struct iommu_group *group,
 					 struct notifier_block *nb);
 extern int iommu_group_unregister_notifier(struct iommu_group *group,
 					   struct notifier_block *nb);
+extern int iommu_update_device_fault_handler(struct device *dev,
+					     u32 mask, u32 set);
 extern int iommu_register_device_fault_handler(struct device *dev,
 					iommu_dev_fault_handler_t handler,
-					void *data);
+					u32 flags, void *data);
 
 extern int iommu_unregister_device_fault_handler(struct device *dev);
 
@@ -873,10 +882,16 @@ static inline int iommu_group_unregister_notifier(struct iommu_group *group,
 	return 0;
 }
 
+static inline int iommu_update_device_fault_handler(struct device *dev,
+						    u32 mask, u32 set)
+{
+	return -ENODEV;
+}
+
 static inline
 int iommu_register_device_fault_handler(struct device *dev,
 					iommu_dev_fault_handler_t handler,
-					void *data)
+					u32 flags, void *data)
 {
 	return -ENODEV;
 }
diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
index e1d9e75f2c94..f6db9c8c970c 100644
--- a/include/uapi/linux/iommu.h
+++ b/include/uapi/linux/iommu.h
@@ -71,6 +71,7 @@ struct iommu_fault_unrecoverable {
 #define IOMMU_FAULT_UNRECOV_PASID_VALID		(1 << 0)
 #define IOMMU_FAULT_UNRECOV_ADDR_VALID		(1 << 1)
 #define IOMMU_FAULT_UNRECOV_FETCH_ADDR_VALID	(1 << 2)
+#define IOMMU_FAULT_UNRECOV_L2			(1 << 3)
 	__u32	flags;
 	__u32	pasid;
 	__u32	perm;
@@ -85,6 +86,8 @@ struct iommu_fault_unrecoverable {
  *         When IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID is set, the page response
  *         must have the same PASID value as the page request. When it is clear,
  *         the page response should not have a PASID.
+ *         If IOMMU_FAULT_PAGE_REQUEST_L2 is set, the fault occurred at the
+ *         second level/stage, otherwise, occurred at the first level.
  * @pasid: Process Address Space ID
  * @grpid: Page Request Group Index
  * @perm: requested page permissions (IOMMU_FAULT_PERM_* values)
@@ -96,6 +99,7 @@ struct iommu_fault_page_request {
 #define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE	(1 << 1)
 #define IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA	(1 << 2)
 #define IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID	(1 << 3)
+#define IOMMU_FAULT_PAGE_REQUEST_L2		(1 << 4)
 	__u32	flags;
 	__u32	pasid;
 	__u32	grpid;
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:16 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:16 +0800
Subject: [RFC PATCH v3 4/8] vfio/type1: Pre-map more pages than requested in
 the IOPF handling
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-5-lushenming@huawei.com>

To optimize for fewer page fault handlings, we can pre-map more pages
than requested at once.

Note that IOPF_PREMAP_LEN is just an arbitrary value for now, which we
could try further tuning.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio_iommu_type1.c | 131 ++++++++++++++++++++++++++++++--
 1 file changed, 123 insertions(+), 8 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 1cb9d1f2717b..01e296c6dc9e 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -3217,6 +3217,91 @@ static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
 	return -EINVAL;
 }
 
+/*
+ * To optimize for fewer page fault handlings, try to
+ * pre-map more pages than requested.
+ */
+#define IOPF_PREMAP_LEN		512
+
+/*
+ * Return 0 on success or a negative error code, the
+ * number of pages contiguously pinned is in @pinned.
+ */
+static int pin_pages_iopf(struct vfio_dma *dma, unsigned long vaddr,
+			  unsigned long npages, unsigned long *pfn_base,
+			  unsigned long *pinned, struct vfio_batch *batch)
+{
+	struct mm_struct *mm;
+	unsigned long pfn;
+	int ret = 0;
+	*pinned = 0;
+
+	mm = get_task_mm(dma->task);
+	if (!mm)
+		return -ENODEV;
+
+	if (batch->size) {
+		*pfn_base = page_to_pfn(batch->pages[batch->offset]);
+		pfn = *pfn_base;
+	} else {
+		*pfn_base = 0;
+	}
+
+	while (npages) {
+		if (!batch->size) {
+			unsigned long req_pages = min_t(unsigned long, npages,
+							batch->capacity);
+
+			ret = vaddr_get_pfns(mm, vaddr, req_pages, dma->prot,
+					     &pfn, batch->pages);
+			if (ret < 0)
+				goto out;
+
+			batch->size = ret;
+			batch->offset = 0;
+			ret = 0;
+
+			if (!*pfn_base)
+				*pfn_base = pfn;
+		}
+
+		while (true) {
+			if (pfn != *pfn_base + *pinned)
+				goto out;
+
+			(*pinned)++;
+			npages--;
+			vaddr += PAGE_SIZE;
+			batch->offset++;
+			batch->size--;
+
+			if (!batch->size)
+				break;
+
+			pfn = page_to_pfn(batch->pages[batch->offset]);
+		}
+
+		if (unlikely(disable_hugepages))
+			break;
+	}
+
+out:
+	if (batch->size == 1 && !batch->offset) {
+		put_pfn(pfn, dma->prot);
+		batch->size = 0;
+	}
+
+	mmput(mm);
+	return ret;
+}
+
+static void unpin_pages_iopf(struct vfio_dma *dma,
+			     unsigned long pfn, unsigned long npages)
+{
+	while (npages--)
+		put_pfn(pfn++, dma->prot);
+}
+
 /* VFIO I/O Page Fault handler */
 static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 {
@@ -3225,9 +3310,11 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 	struct vfio_iopf_group *iopf_group;
 	struct vfio_iommu *iommu;
 	struct vfio_dma *dma;
+	struct vfio_batch batch;
 	dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
 	int access_flags = 0;
-	unsigned long bit_offset, vaddr, pfn;
+	size_t premap_len, map_len, mapped_len = 0;
+	unsigned long bit_offset, vaddr, pfn, i, npages;
 	int ret;
 	enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
 	struct iommu_page_response resp = {0};
@@ -3263,19 +3350,47 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 	if (IOPF_MAPPED_BITMAP_GET(dma, bit_offset))
 		goto out_success;
 
+	premap_len = IOPF_PREMAP_LEN << PAGE_SHIFT;
+	npages = dma->size >> PAGE_SHIFT;
+	map_len = PAGE_SIZE;
+	for (i = bit_offset + 1; i < npages; i++) {
+		if (map_len >= premap_len || IOPF_MAPPED_BITMAP_GET(dma, i))
+			break;
+		map_len += PAGE_SIZE;
+	}
 	vaddr = iova - dma->iova + dma->vaddr;
+	vfio_batch_init(&batch);
 
-	if (vfio_pin_page_external(dma, vaddr, &pfn, false))
-		goto out_invalid;
+	while (map_len) {
+		ret = pin_pages_iopf(dma, vaddr + mapped_len,
+				     map_len >> PAGE_SHIFT, &pfn,
+				     &npages, &batch);
+		if (!npages)
+			break;
 
-	if (vfio_iommu_map(iommu, iova, pfn, 1, dma->prot)) {
-		put_pfn(pfn, dma->prot);
-		goto out_invalid;
+		if (vfio_iommu_map(iommu, iova + mapped_len, pfn,
+				   npages, dma->prot)) {
+			unpin_pages_iopf(dma, pfn, npages);
+			vfio_batch_unpin(&batch, dma);
+			break;
+		}
+
+		bitmap_set(dma->iopf_mapped_bitmap,
+			   bit_offset + (mapped_len >> PAGE_SHIFT), npages);
+
+		unpin_pages_iopf(dma, pfn, npages);
+
+		map_len -= npages << PAGE_SHIFT;
+		mapped_len += npages << PAGE_SHIFT;
+
+		if (ret)
+			break;
 	}
 
-	bitmap_set(dma->iopf_mapped_bitmap, bit_offset, 1);
+	vfio_batch_fini(&batch);
 
-	put_pfn(pfn, dma->prot);
+	if (!mapped_len)
+		goto out_invalid;
 
 out_success:
 	status = IOMMU_PAGE_RESP_SUCCESS;
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:12 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:12 +0800
Subject: [RFC PATCH v3 0/8] Add IOPF support for VFIO passthrough
Message-ID: <20210409034420.1799-1-lushenming@huawei.com>

Hi,

Requesting for your comments and suggestions. :-)

The static pinning and mapping problem in VFIO and possible solutions
have been discussed a lot [1, 2]. One of the solutions is to add I/O
Page Fault support for VFIO devices. Different from those relatively
complicated software approaches such as presenting a vIOMMU that provides
the DMA buffer information (might include para-virtualized optimizations),
IOPF mainly depends on the hardware faulting capability, such as the PCIe
PRI extension or Arm SMMU stall model. What's more, the IOPF support in
the IOMMU driver has already been implemented in SVA [3]. So we add IOPF
support for VFIO passthrough based on the IOPF part of SVA in this series.

We have measured its performance with UADK [4] (passthrough an accelerator
to a VM(1U16G)) on Hisilicon Kunpeng920 board (and compared with host SVA):

Run hisi_sec_test...
 - with varying sending times and message lengths
 - with/without IOPF enabled (speed slowdown)

when msg_len = 1MB (and PREMAP_LEN (in Patch 4) = 1):
            slowdown (num of faults)
 times      VFIO IOPF      host SVA
 1          63.4% (518)    82.8% (512)
 100        22.9% (1058)   47.9% (1024)
 1000       2.6% (1071)    8.5% (1024)

when msg_len = 10MB (and PREMAP_LEN = 512):
            slowdown (num of faults)
 times      VFIO IOPF
 1          32.6% (13)
 100        3.5% (26)
 1000       1.6% (26)

History:

v2 -> v3
 - Nit fixes.
 - No reason to disable reporting the unrecoverable faults. (baolu)
 - Maintain a global IOPF enabled group list.
 - Split the pre-mapping optimization to be a separate patch.
 - Add selective faulting support (use vfio_pin_pages to indicate the
   non-faultable scope and add a new struct vfio_range to record it,
   untested). (Kevin)

v1 -> v2
 - Numerous improvements following the suggestions. Thanks a lot to all
   of you.

Note that PRI is not supported at the moment since there is no hardware.

Links:
[1] Lesokhin I, et al. Page Fault Support for Network Controllers. In ASPLOS,
    2016.
[2] Tian K, et al. coIOMMU: A Virtual IOMMU with Cooperative DMA Buffer Tracking
    for Efficient Memory Management in Direct I/O. In USENIX ATC, 2020.
[3] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210401154718.307519-1-jean-philippe at linaro.org/
[4] https://github.com/Linaro/uadk

Thanks,
Shenming


Shenming Lu (8):
  iommu: Evolve the device fault reporting framework
  vfio/type1: Add a page fault handler
  vfio/type1: Add an MMU notifier to avoid pinning
  vfio/type1: Pre-map more pages than requested in the IOPF handling
  vfio/type1: VFIO_IOMMU_ENABLE_IOPF
  vfio/type1: No need to statically pin and map if IOPF enabled
  vfio/type1: Add selective DMA faulting support
  vfio: Add nested IOPF support

 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |    3 +-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |   18 +-
 drivers/iommu/iommu.c                         |   56 +-
 drivers/vfio/vfio.c                           |   85 +-
 drivers/vfio/vfio_iommu_type1.c               | 1000 ++++++++++++++++-
 include/linux/iommu.h                         |   19 +-
 include/linux/vfio.h                          |   13 +
 include/uapi/linux/iommu.h                    |    4 +
 include/uapi/linux/vfio.h                     |    6 +
 9 files changed, 1181 insertions(+), 23 deletions(-)

-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:14 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:14 +0800
Subject: [RFC PATCH v3 2/8] vfio/type1: Add a page fault handler
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-3-lushenming@huawei.com>

VFIO manages the DMA mapping itself. To support IOPF (on-demand paging)
for VFIO (IOMMU capable) devices, we add a VFIO page fault handler to
serve the reported page faults from the IOMMU driver.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio_iommu_type1.c | 114 ++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45cbfd4879a5..ab0ff60ee207 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -101,6 +101,7 @@ struct vfio_dma {
 	struct task_struct	*task;
 	struct rb_root		pfn_list;	/* Ex-user pinned pfn list */
 	unsigned long		*bitmap;
+	unsigned long		*iopf_mapped_bitmap;
 };
 
 struct vfio_batch {
@@ -141,6 +142,16 @@ struct vfio_regions {
 	size_t len;
 };
 
+/* A global IOPF enabled group list */
+static struct rb_root iopf_group_list = RB_ROOT;
+static DEFINE_MUTEX(iopf_group_list_lock);
+
+struct vfio_iopf_group {
+	struct rb_node		node;
+	struct iommu_group	*iommu_group;
+	struct vfio_iommu	*iommu;
+};
+
 #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)	\
 					(!list_empty(&iommu->domain_list))
 
@@ -157,6 +168,10 @@ struct vfio_regions {
 #define DIRTY_BITMAP_PAGES_MAX	 ((u64)INT_MAX)
 #define DIRTY_BITMAP_SIZE_MAX	 DIRTY_BITMAP_BYTES(DIRTY_BITMAP_PAGES_MAX)
 
+#define IOPF_MAPPED_BITMAP_GET(dma, i)	\
+			      ((dma->iopf_mapped_bitmap[(i) / BITS_PER_LONG]	\
+			       >> ((i) % BITS_PER_LONG)) & 0x1)
+
 #define WAITED 1
 
 static int put_pfn(unsigned long pfn, int prot);
@@ -416,6 +431,34 @@ static int vfio_iova_put_vfio_pfn(struct vfio_dma *dma, struct vfio_pfn *vpfn)
 	return ret;
 }
 
+/*
+ * Helper functions for iopf_group_list
+ */
+static struct vfio_iopf_group *
+vfio_find_iopf_group(struct iommu_group *iommu_group)
+{
+	struct vfio_iopf_group *iopf_group;
+	struct rb_node *node;
+
+	mutex_lock(&iopf_group_list_lock);
+
+	node = iopf_group_list.rb_node;
+
+	while (node) {
+		iopf_group = rb_entry(node, struct vfio_iopf_group, node);
+
+		if (iommu_group < iopf_group->iommu_group)
+			node = node->rb_left;
+		else if (iommu_group > iopf_group->iommu_group)
+			node = node->rb_right;
+		else
+			break;
+	}
+
+	mutex_unlock(&iopf_group_list_lock);
+	return node ? iopf_group : NULL;
+}
+
 static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
 {
 	struct mm_struct *mm;
@@ -3106,6 +3149,77 @@ static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
 	return -EINVAL;
 }
 
+/* VFIO I/O Page Fault handler */
+static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
+{
+	struct device *dev = (struct device *)data;
+	struct iommu_group *iommu_group;
+	struct vfio_iopf_group *iopf_group;
+	struct vfio_iommu *iommu;
+	struct vfio_dma *dma;
+	dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
+	int access_flags = 0;
+	unsigned long bit_offset, vaddr, pfn;
+	int ret;
+	enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
+	struct iommu_page_response resp = {0};
+
+	if (fault->type != IOMMU_FAULT_PAGE_REQ)
+		return -EOPNOTSUPP;
+
+	iommu_group = iommu_group_get(dev);
+	if (!iommu_group)
+		return -ENODEV;
+
+	iopf_group = vfio_find_iopf_group(iommu_group);
+	iommu_group_put(iommu_group);
+	if (!iopf_group)
+		return -ENODEV;
+
+	iommu = iopf_group->iommu;
+
+	mutex_lock(&iommu->lock);
+
+	ret = vfio_find_dma_valid(iommu, iova, PAGE_SIZE, &dma);
+	if (ret < 0)
+		goto out_invalid;
+
+	if (fault->prm.perm & IOMMU_FAULT_PERM_READ)
+		access_flags |= IOMMU_READ;
+	if (fault->prm.perm & IOMMU_FAULT_PERM_WRITE)
+		access_flags |= IOMMU_WRITE;
+	if ((dma->prot & access_flags) != access_flags)
+		goto out_invalid;
+
+	bit_offset = (iova - dma->iova) >> PAGE_SHIFT;
+	if (IOPF_MAPPED_BITMAP_GET(dma, bit_offset))
+		goto out_success;
+
+	vaddr = iova - dma->iova + dma->vaddr;
+
+	if (vfio_pin_page_external(dma, vaddr, &pfn, true))
+		goto out_invalid;
+
+	if (vfio_iommu_map(iommu, iova, pfn, 1, dma->prot)) {
+		if (put_pfn(pfn, dma->prot))
+			vfio_lock_acct(dma, -1, true);
+		goto out_invalid;
+	}
+
+	bitmap_set(dma->iopf_mapped_bitmap, bit_offset, 1);
+
+out_success:
+	status = IOMMU_PAGE_RESP_SUCCESS;
+
+out_invalid:
+	mutex_unlock(&iommu->lock);
+	resp.version		= IOMMU_PAGE_RESP_VERSION_1;
+	resp.grpid		= fault->prm.grpid;
+	resp.code		= status;
+	iommu_page_response(dev, &resp);
+	return 0;
+}
+
 static long vfio_iommu_type1_ioctl(void *iommu_data,
 				   unsigned int cmd, unsigned long arg)
 {
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:20 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:20 +0800
Subject: [RFC PATCH v3 8/8] vfio: Add nested IOPF support
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-9-lushenming@huawei.com>

To set up nested mode, drivers such as vfio_pci need to register a
handler to receive stage/level 1 faults from the IOMMU, but since
currently each device can only have one iommu dev fault handler,
and if stage 2 IOPF is already enabled (VFIO_IOMMU_ENABLE_IOPF),
we choose to update the registered handler (a consolidated one) via
flags (set FAULT_REPORT_NESTED_L1), and further deliver the received
stage 1 faults in the handler to the guest through a newly added
vfio_device_ops callback.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio.c             | 81 +++++++++++++++++++++++++++++++++
 drivers/vfio/vfio_iommu_type1.c | 49 +++++++++++++++++++-
 include/linux/vfio.h            | 12 +++++
 3 files changed, 141 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 44c8dfabf7de..4245f15914bf 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2356,6 +2356,87 @@ struct iommu_domain *vfio_group_iommu_domain(struct vfio_group *group)
 }
 EXPORT_SYMBOL_GPL(vfio_group_iommu_domain);
 
+/*
+ * Register/Update the VFIO IOPF handler to receive
+ * nested stage/level 1 faults.
+ */
+int vfio_iommu_dev_fault_handler_register_nested(struct device *dev)
+{
+	struct vfio_container *container;
+	struct vfio_group *group;
+	struct vfio_iommu_driver *driver;
+	int ret;
+
+	if (!dev)
+		return -EINVAL;
+
+	group = vfio_group_get_from_dev(dev);
+	if (!group)
+		return -ENODEV;
+
+	ret = vfio_group_add_container_user(group);
+	if (ret)
+		goto out;
+
+	container = group->container;
+	driver = container->iommu_driver;
+	if (likely(driver && driver->ops->register_handler))
+		ret = driver->ops->register_handler(container->iommu_data, dev);
+	else
+		ret = -ENOTTY;
+
+	vfio_group_try_dissolve_container(group);
+
+out:
+	vfio_group_put(group);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_register_nested);
+
+int vfio_iommu_dev_fault_handler_unregister_nested(struct device *dev)
+{
+	struct vfio_container *container;
+	struct vfio_group *group;
+	struct vfio_iommu_driver *driver;
+	int ret;
+
+	if (!dev)
+		return -EINVAL;
+
+	group = vfio_group_get_from_dev(dev);
+	if (!group)
+		return -ENODEV;
+
+	ret = vfio_group_add_container_user(group);
+	if (ret)
+		goto out;
+
+	container = group->container;
+	driver = container->iommu_driver;
+	if (likely(driver && driver->ops->unregister_handler))
+		ret = driver->ops->unregister_handler(container->iommu_data, dev);
+	else
+		ret = -ENOTTY;
+
+	vfio_group_try_dissolve_container(group);
+
+out:
+	vfio_group_put(group);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_unregister_nested);
+
+int vfio_transfer_iommu_fault(struct device *dev, struct iommu_fault *fault)
+{
+	struct vfio_device *device = dev_get_drvdata(dev);
+
+	if (unlikely(!device->ops->transfer))
+		return -EOPNOTSUPP;
+
+	return device->ops->transfer(device->device_data, fault);
+}
+EXPORT_SYMBOL_GPL(vfio_transfer_iommu_fault);
+
 /**
  * Module/class support
  */
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index ba2b5a1cf6e9..9d1adeddb303 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -3821,13 +3821,32 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 	struct vfio_batch batch;
 	struct vfio_range *range;
 	dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
-	int access_flags = 0;
+	int access_flags = 0, nested;
 	size_t premap_len, map_len, mapped_len = 0;
 	unsigned long bit_offset, vaddr, pfn, i, npages;
 	int ret;
 	enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
 	struct iommu_page_response resp = {0};
 
+	if (vfio_dev_domian_nested(dev, &nested))
+		return -ENODEV;
+
+	/*
+	 * When configured in nested mode, further deliver the
+	 * stage/level 1 faults to the guest.
+	 */
+	if (nested) {
+		bool l2;
+
+		if (fault->type == IOMMU_FAULT_PAGE_REQ)
+			l2 = fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_L2;
+		if (fault->type == IOMMU_FAULT_DMA_UNRECOV)
+			l2 = fault->event.flags & IOMMU_FAULT_UNRECOV_L2;
+
+		if (!l2)
+			return vfio_transfer_iommu_fault(dev, fault);
+	}
+
 	if (fault->type != IOMMU_FAULT_PAGE_REQ)
 		return -EOPNOTSUPP;
 
@@ -4201,6 +4220,32 @@ static void vfio_iommu_type1_notify(void *iommu_data,
 	wake_up_all(&iommu->vaddr_wait);
 }
 
+static int vfio_iommu_type1_register_handler(void *iommu_data,
+					     struct device *dev)
+{
+	struct vfio_iommu *iommu = iommu_data;
+
+	if (iommu->iopf_enabled)
+		return iommu_update_device_fault_handler(dev, ~0,
+						FAULT_REPORT_NESTED_L1);
+	else
+		return iommu_register_device_fault_handler(dev,
+						vfio_iommu_type1_dma_map_iopf,
+						FAULT_REPORT_NESTED_L1, dev);
+}
+
+static int vfio_iommu_type1_unregister_handler(void *iommu_data,
+					       struct device *dev)
+{
+	struct vfio_iommu *iommu = iommu_data;
+
+	if (iommu->iopf_enabled)
+		return iommu_update_device_fault_handler(dev,
+						~FAULT_REPORT_NESTED_L1, 0);
+	else
+		return iommu_unregister_device_fault_handler(dev);
+}
+
 static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
 	.name			= "vfio-iommu-type1",
 	.owner			= THIS_MODULE,
@@ -4216,6 +4261,8 @@ static const struct vfio_iommu_driver_ops vfio_iommu_driver_ops_type1 = {
 	.dma_rw			= vfio_iommu_type1_dma_rw,
 	.group_iommu_domain	= vfio_iommu_type1_group_iommu_domain,
 	.notify			= vfio_iommu_type1_notify,
+	.register_handler	= vfio_iommu_type1_register_handler,
+	.unregister_handler	= vfio_iommu_type1_unregister_handler,
 };
 
 static int __init vfio_iommu_type1_init(void)
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index a7b426d579df..4621d8f0395d 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -29,6 +29,8 @@
  * @match: Optional device name match callback (return: 0 for no-match, >0 for
  *         match, -errno for abort (ex. match with insufficient or incorrect
  *         additional args)
+ * @transfer: Optional. Transfer the received stage/level 1 faults to the guest
+ *            for nested mode.
  */
 struct vfio_device_ops {
 	char	*name;
@@ -43,6 +45,7 @@ struct vfio_device_ops {
 	int	(*mmap)(void *device_data, struct vm_area_struct *vma);
 	void	(*request)(void *device_data, unsigned int count);
 	int	(*match)(void *device_data, char *buf);
+	int	(*transfer)(void *device_data, struct iommu_fault *fault);
 };
 
 extern struct iommu_group *vfio_iommu_group_get(struct device *dev);
@@ -100,6 +103,10 @@ struct vfio_iommu_driver_ops {
 						   struct iommu_group *group);
 	void		(*notify)(void *iommu_data,
 				  enum vfio_iommu_notify_type event);
+	int		(*register_handler)(void *iommu_data,
+					    struct device *dev);
+	int		(*unregister_handler)(void *iommu_data,
+					      struct device *dev);
 };
 
 extern int vfio_register_iommu_driver(const struct vfio_iommu_driver_ops *ops);
@@ -161,6 +168,11 @@ extern int vfio_unregister_notifier(struct device *dev,
 struct kvm;
 extern void vfio_group_set_kvm(struct vfio_group *group, struct kvm *kvm);
 
+extern int vfio_iommu_dev_fault_handler_register_nested(struct device *dev);
+extern int vfio_iommu_dev_fault_handler_unregister_nested(struct device *dev);
+extern int vfio_transfer_iommu_fault(struct device *dev,
+				     struct iommu_fault *fault);
+
 /*
  * Sub-module helpers
  */
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:19 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:19 +0800
Subject: [RFC PATCH v3 7/8] vfio/type1: Add selective DMA faulting support
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-8-lushenming@huawei.com>

Some devices only allow selective DMA faulting. Similar to the selective
dirty page tracking, the vendor driver can call vfio_pin_pages() to
indicate the non-faultable scope, we add a new struct vfio_range to
record it, then when the IOPF handler receives any page request out
of the scope, we can directly return with an invalid response.

Suggested-by: Kevin Tian <kevin.tian at intel.com>
Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio.c             |   4 +-
 drivers/vfio/vfio_iommu_type1.c | 357 +++++++++++++++++++++++++++++++-
 include/linux/vfio.h            |   1 +
 3 files changed, 358 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 38779e6fd80c..44c8dfabf7de 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -2013,7 +2013,8 @@ int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn, int npage)
 	container = group->container;
 	driver = container->iommu_driver;
 	if (likely(driver && driver->ops->unpin_pages))
-		ret = driver->ops->unpin_pages(container->iommu_data, user_pfn,
+		ret = driver->ops->unpin_pages(container->iommu_data,
+					       group->iommu_group, user_pfn,
 					       npage);
 	else
 		ret = -ENOTTY;
@@ -2112,6 +2113,7 @@ int vfio_group_unpin_pages(struct vfio_group *group,
 	driver = container->iommu_driver;
 	if (likely(driver && driver->ops->unpin_pages))
 		ret = driver->ops->unpin_pages(container->iommu_data,
+					       group->iommu_group,
 					       user_iova_pfn, npage);
 	else
 		ret = -ENOTTY;
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index dcc93c3b258c..ba2b5a1cf6e9 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -150,10 +150,19 @@ struct vfio_regions {
 static struct rb_root iopf_group_list = RB_ROOT;
 static DEFINE_MUTEX(iopf_group_list_lock);
 
+struct vfio_range {
+	struct rb_node		node;
+	dma_addr_t		base_iova;
+	size_t			span;
+	unsigned int		ref_count;
+};
+
 struct vfio_iopf_group {
 	struct rb_node		node;
 	struct iommu_group	*iommu_group;
 	struct vfio_iommu	*iommu;
+	struct rb_root		pinned_range_list;
+	bool			selective_faulting;
 };
 
 #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)	\
@@ -496,6 +505,255 @@ static void vfio_unlink_iopf_group(struct vfio_iopf_group *old)
 	mutex_unlock(&iopf_group_list_lock);
 }
 
+/*
+ * Helper functions for range list, handle one page at a time.
+ */
+static struct vfio_range *vfio_find_range(struct rb_root *range_list,
+					  dma_addr_t iova)
+{
+	struct rb_node *node = range_list->rb_node;
+	struct vfio_range *range;
+
+	while (node) {
+		range = rb_entry(node, struct vfio_range, node);
+
+		if (iova + PAGE_SIZE <= range->base_iova)
+			node = node->rb_left;
+		else if (iova >= range->base_iova + range->span)
+			node = node->rb_right;
+		else
+			return range;
+	}
+
+	return NULL;
+}
+
+/* Do the possible merge adjacent to the input range. */
+static void vfio_merge_range_list(struct rb_root *range_list,
+				  struct vfio_range *range)
+{
+	struct rb_node *node_prev = rb_prev(&range->node);
+	struct rb_node *node_next = rb_next(&range->node);
+
+	if (node_next) {
+		struct vfio_range *range_next = rb_entry(node_next,
+							 struct vfio_range,
+							 node);
+
+		if (range_next->base_iova == (range->base_iova + range->span) &&
+		    range_next->ref_count == range->ref_count) {
+			rb_erase(node_next, range_list);
+			range->span += range_next->span;
+			kfree(range_next);
+		}
+	}
+
+	if (node_prev) {
+		struct vfio_range *range_prev = rb_entry(node_prev,
+							 struct vfio_range,
+							 node);
+
+		if (range->base_iova == (range_prev->base_iova + range_prev->span)
+		    && range->ref_count == range_prev->ref_count) {
+			rb_erase(&range->node, range_list);
+			range_prev->span += range->span;
+			kfree(range);
+		}
+	}
+}
+
+static void vfio_link_range(struct rb_root *range_list, struct vfio_range *new)
+{
+	struct rb_node **link, *parent = NULL;
+	struct vfio_range *range;
+
+	link = &range_list->rb_node;
+
+	while (*link) {
+		parent = *link;
+		range = rb_entry(parent, struct vfio_range, node);
+
+		if (new->base_iova < range->base_iova)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+
+	rb_link_node(&new->node, parent, link);
+	rb_insert_color(&new->node, range_list);
+
+	vfio_merge_range_list(range_list, new);
+}
+
+static int vfio_add_to_range_list(struct rb_root *range_list,
+				  dma_addr_t iova)
+{
+	struct vfio_range *range = vfio_find_range(range_list, iova);
+
+	if (range) {
+		struct vfio_range *new_prev, *new_next;
+		size_t span_prev, span_next;
+
+		/* May split the found range into three parts. */
+		span_prev = iova - range->base_iova;
+		span_next = range->span - span_prev - PAGE_SIZE;
+
+		if (span_prev) {
+			new_prev = kzalloc(sizeof(*new_prev), GFP_KERNEL);
+			if (!new_prev)
+				return -ENOMEM;
+
+			new_prev->base_iova = range->base_iova;
+			new_prev->span = span_prev;
+			new_prev->ref_count = range->ref_count;
+		}
+
+		if (span_next) {
+			new_next = kzalloc(sizeof(*new_next), GFP_KERNEL);
+			if (!new_next) {
+				if (span_prev)
+					kfree(new_prev);
+				return -ENOMEM;
+			}
+
+			new_next->base_iova = iova + PAGE_SIZE;
+			new_next->span = span_next;
+			new_next->ref_count = range->ref_count;
+		}
+
+		range->base_iova = iova;
+		range->span = PAGE_SIZE;
+		range->ref_count++;
+		vfio_merge_range_list(range_list, range);
+
+		if (span_prev)
+			vfio_link_range(range_list, new_prev);
+
+		if (span_next)
+			vfio_link_range(range_list, new_next);
+	} else {
+		struct vfio_range *new;
+
+		new = kzalloc(sizeof(*new), GFP_KERNEL);
+		if (!new)
+			return -ENOMEM;
+
+		new->base_iova = iova;
+		new->span = PAGE_SIZE;
+		new->ref_count = 1;
+
+		vfio_link_range(range_list, new);
+	}
+
+	return 0;
+}
+
+static int vfio_remove_from_range_list(struct rb_root *range_list,
+				       dma_addr_t iova)
+{
+	struct vfio_range *range = vfio_find_range(range_list, iova);
+	struct vfio_range *news[3];
+	size_t span_prev, span_in, span_next;
+	int i, num_news;
+
+	if (!range)
+		return 0;
+
+	span_prev = iova - range->base_iova;
+	span_in = range->ref_count > 1 ? PAGE_SIZE : 0;
+	span_next = range->span - span_prev - PAGE_SIZE;
+
+	num_news = (int)!!span_prev + (int)!!span_in + (int)!!span_next;
+	if (!num_news) {
+		rb_erase(&range->node, range_list);
+		kfree(range);
+		return 0;
+	}
+
+	for (i = 0; i < num_news - 1; i++) {
+		news[i] = kzalloc(sizeof(struct vfio_range), GFP_KERNEL);
+		if (!news[i]) {
+			if (i > 0)
+				kfree(news[0]);
+			return -ENOMEM;
+		}
+	}
+	/* Reuse the found range. */
+	news[i] = range;
+
+	i = 0;
+	if (span_prev) {
+		news[i]->base_iova = range->base_iova;
+		news[i]->span = span_prev;
+		news[i++]->ref_count = range->ref_count;
+	}
+	if (span_in) {
+		news[i]->base_iova = iova;
+		news[i]->span = span_in;
+		news[i++]->ref_count = range->ref_count - 1;
+	}
+	if (span_next) {
+		news[i]->base_iova = iova + PAGE_SIZE;
+		news[i]->span = span_next;
+		news[i]->ref_count = range->ref_count;
+	}
+
+	vfio_merge_range_list(range_list, range);
+
+	for (i = 0; i < num_news - 1; i++)
+		vfio_link_range(range_list, news[i]);
+
+	return 0;
+}
+
+static void vfio_range_list_free(struct rb_root *range_list)
+{
+	struct rb_node *n;
+
+	while ((n = rb_first(range_list))) {
+		struct vfio_range *range = rb_entry(n, struct vfio_range, node);
+
+		rb_erase(&range->node, range_list);
+		kfree(range);
+	}
+}
+
+static int vfio_range_list_get_copy(struct vfio_iopf_group *iopf_group,
+				    struct rb_root *range_list_copy)
+{
+	struct rb_root *range_list = &iopf_group->pinned_range_list;
+	struct rb_node *n, **link = &range_list_copy->rb_node, *parent = NULL;
+	int ret;
+
+	for (n = rb_first(range_list); n; n = rb_next(n)) {
+		struct vfio_range *range, *range_copy;
+
+		range = rb_entry(n, struct vfio_range, node);
+
+		range_copy = kzalloc(sizeof(*range_copy), GFP_KERNEL);
+		if (!range_copy) {
+			ret = -ENOMEM;
+			goto out_free;
+		}
+
+		range_copy->base_iova = range->base_iova;
+		range_copy->span = range->span;
+		range_copy->ref_count = range->ref_count;
+
+		rb_link_node(&range_copy->node, parent, link);
+		rb_insert_color(&range_copy->node, range_list_copy);
+
+		parent = *link;
+		link = &(*link)->rb_right;
+	}
+
+	return 0;
+
+out_free:
+	vfio_range_list_free(range_list_copy);
+	return ret;
+}
+
 static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async)
 {
 	struct mm_struct *mm;
@@ -910,6 +1168,9 @@ static int vfio_unpin_page_external(struct vfio_dma *dma, dma_addr_t iova,
 	return unlocked;
 }
 
+static struct vfio_group *find_iommu_group(struct vfio_domain *domain,
+					   struct iommu_group *iommu_group);
+
 static int vfio_iommu_type1_pin_pages(void *iommu_data,
 				      struct iommu_group *iommu_group,
 				      unsigned long *user_pfn,
@@ -923,6 +1184,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 	struct vfio_dma *dma;
 	bool do_accounting;
 	dma_addr_t iova;
+	struct vfio_iopf_group *iopf_group = NULL;
+	struct rb_root range_list_copy = RB_ROOT;
 
 	if (!iommu || !user_pfn || !phys_pfn)
 		return -EINVAL;
@@ -955,6 +1218,31 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 		goto pin_done;
 	}
 
+	/*
+	 * Some devices only allow selective DMA faulting. Similar to the
+	 * selective dirty tracking, the vendor driver can call vfio_pin_pages()
+	 * to indicate the non-faultable scope, and we record it to filter
+	 * out the invalid page requests in the IOPF handler.
+	 */
+	if (iommu->iopf_enabled) {
+		iopf_group = vfio_find_iopf_group(iommu_group);
+		if (iopf_group) {
+			/*
+			 * We don't want to work on the original range
+			 * list as the list gets modified and in case
+			 * of failure we have to retain the original
+			 * list. Get a copy here.
+			 */
+			ret = vfio_range_list_get_copy(iopf_group,
+						       &range_list_copy);
+			if (ret)
+				goto pin_done;
+		} else {
+			WARN_ON(!find_iommu_group(iommu->external_domain,
+						  iommu_group));
+		}
+	}
+
 	/*
 	 * If iommu capable domain exist in the container then all pages are
 	 * already pinned and accounted. Accouting should be done if there is no
@@ -981,6 +1269,15 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 		vpfn = vfio_iova_get_vfio_pfn(dma, iova);
 		if (vpfn) {
 			phys_pfn[i] = vpfn->pfn;
+			if (iopf_group) {
+				ret = vfio_add_to_range_list(&range_list_copy,
+							     iova);
+				if (ret) {
+					vfio_unpin_page_external(dma, iova,
+								 do_accounting);
+					goto pin_unwind;
+				}
+			}
 			continue;
 		}
 
@@ -997,6 +1294,15 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 			goto pin_unwind;
 		}
 
+		if (iopf_group) {
+			ret = vfio_add_to_range_list(&range_list_copy, iova);
+			if (ret) {
+				vfio_unpin_page_external(dma, iova,
+							 do_accounting);
+				goto pin_unwind;
+			}
+		}
+
 		if (iommu->dirty_page_tracking) {
 			unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
 
@@ -1010,6 +1316,13 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 	}
 	ret = i;
 
+	if (iopf_group) {
+		vfio_range_list_free(&iopf_group->pinned_range_list);
+		iopf_group->pinned_range_list.rb_node = range_list_copy.rb_node;
+		if (!iopf_group->selective_faulting)
+			iopf_group->selective_faulting = true;
+	}
+
 	group = vfio_iommu_find_iommu_group(iommu, iommu_group);
 	if (!group->pinned_page_dirty_scope) {
 		group->pinned_page_dirty_scope = true;
@@ -1019,6 +1332,8 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 	goto pin_done;
 
 pin_unwind:
+	if (iopf_group)
+		vfio_range_list_free(&range_list_copy);
 	phys_pfn[i] = 0;
 	for (j = 0; j < i; j++) {
 		dma_addr_t iova;
@@ -1034,12 +1349,14 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
 }
 
 static int vfio_iommu_type1_unpin_pages(void *iommu_data,
+					struct iommu_group *iommu_group,
 					unsigned long *user_pfn,
 					int npage)
 {
 	struct vfio_iommu *iommu = iommu_data;
+	struct vfio_iopf_group *iopf_group = NULL;
 	bool do_accounting;
-	int i;
+	int i, ret;
 
 	if (!iommu || !user_pfn)
 		return -EINVAL;
@@ -1050,6 +1367,13 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
 
 	mutex_lock(&iommu->lock);
 
+	if (iommu->iopf_enabled) {
+		iopf_group = vfio_find_iopf_group(iommu_group);
+		if (!iopf_group)
+			WARN_ON(!find_iommu_group(iommu->external_domain,
+						  iommu_group));
+	}
+
 	do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) ||
 			iommu->iopf_enabled;
 	for (i = 0; i < npage; i++) {
@@ -1058,14 +1382,24 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
 
 		iova = user_pfn[i] << PAGE_SHIFT;
 		dma = vfio_find_dma(iommu, iova, PAGE_SIZE);
-		if (!dma)
+		if (!dma) {
+			ret = -EINVAL;
 			goto unpin_exit;
+		}
+
+		if (iopf_group) {
+			ret = vfio_remove_from_range_list(
+					&iopf_group->pinned_range_list, iova);
+			if (ret)
+				goto unpin_exit;
+		}
+
 		vfio_unpin_page_external(dma, iova, do_accounting);
 	}
 
 unpin_exit:
 	mutex_unlock(&iommu->lock);
-	return i > npage ? npage : (i > 0 ? i : -EINVAL);
+	return i > npage ? npage : (i > 0 ? i : ret);
 }
 
 static long vfio_sync_unpin(struct vfio_dma *dma, struct vfio_domain *domain,
@@ -2591,6 +2925,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 
 		iopf_group->iommu_group = iommu_group;
 		iopf_group->iommu = iommu;
+		iopf_group->pinned_range_list = RB_ROOT;
 
 		vfio_link_iopf_group(iopf_group);
 	}
@@ -2886,6 +3221,8 @@ static void vfio_iommu_type1_detach_group(void *iommu_data,
 
 			iopf_group = vfio_find_iopf_group(iommu_group);
 			if (!WARN_ON(!iopf_group)) {
+				WARN_ON(!RB_EMPTY_ROOT(
+						&iopf_group->pinned_range_list));
 				vfio_unlink_iopf_group(iopf_group);
 				kfree(iopf_group);
 			}
@@ -3482,6 +3819,7 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 	struct vfio_iommu *iommu;
 	struct vfio_dma *dma;
 	struct vfio_batch batch;
+	struct vfio_range *range;
 	dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
 	int access_flags = 0;
 	size_t premap_len, map_len, mapped_len = 0;
@@ -3506,6 +3844,12 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 
 	mutex_lock(&iommu->lock);
 
+	if (iopf_group->selective_faulting) {
+		range = vfio_find_range(&iopf_group->pinned_range_list, iova);
+		if (!range)
+			goto out_invalid;
+	}
+
 	ret = vfio_find_dma_valid(iommu, iova, PAGE_SIZE, &dma);
 	if (ret < 0)
 		goto out_invalid;
@@ -3523,6 +3867,12 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 
 	premap_len = IOPF_PREMAP_LEN << PAGE_SHIFT;
 	npages = dma->size >> PAGE_SHIFT;
+	if (iopf_group->selective_faulting) {
+		dma_addr_t range_end = range->base_iova + range->span;
+
+		if (range_end < dma->iova + dma->size)
+			npages = (range_end - dma->iova) >> PAGE_SHIFT;
+	}
 	map_len = PAGE_SIZE;
 	for (i = bit_offset + 1; i < npages; i++) {
 		if (map_len >= premap_len || IOPF_MAPPED_BITMAP_GET(dma, i))
@@ -3647,6 +3997,7 @@ static int vfio_iommu_type1_enable_iopf(struct vfio_iommu *iommu)
 
 			iopf_group->iommu_group = g->iommu_group;
 			iopf_group->iommu = iommu;
+			iopf_group->pinned_range_list = RB_ROOT;
 
 			vfio_link_iopf_group(iopf_group);
 		}
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index b7e18bde5aa8..a7b426d579df 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -87,6 +87,7 @@ struct vfio_iommu_driver_ops {
 				     int npage, int prot,
 				     unsigned long *phys_pfn);
 	int		(*unpin_pages)(void *iommu_data,
+				       struct iommu_group *group,
 				       unsigned long *user_pfn, int npage);
 	int		(*register_notifier)(void *iommu_data,
 					     unsigned long *events,
-- 
2.19.1



From lushenming at huawei.com  Fri Apr  9 04:44:15 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Fri, 9 Apr 2021 11:44:15 +0800
Subject: [RFC PATCH v3 3/8] vfio/type1: Add an MMU notifier to avoid pinning
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <20210409034420.1799-4-lushenming@huawei.com>

To avoid pinning pages when they are mapped in IOMMU page tables, we
add an MMU notifier to tell the addresses which are no longer valid
and try to unmap them.

Signed-off-by: Shenming Lu <lushenming at huawei.com>
---
 drivers/vfio/vfio_iommu_type1.c | 112 +++++++++++++++++++++++++++++++-
 1 file changed, 109 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index ab0ff60ee207..1cb9d1f2717b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -40,6 +40,7 @@
 #include <linux/notifier.h>
 #include <linux/dma-iommu.h>
 #include <linux/irqdomain.h>
+#include <linux/mmu_notifier.h>
 
 #define DRIVER_VERSION  "0.2"
 #define DRIVER_AUTHOR   "Alex Williamson <alex.williamson at redhat.com>"
@@ -69,6 +70,7 @@ struct vfio_iommu {
 	struct mutex		lock;
 	struct rb_root		dma_list;
 	struct blocking_notifier_head notifier;
+	struct mmu_notifier	mn;
 	unsigned int		dma_avail;
 	unsigned int		vaddr_invalid_count;
 	uint64_t		pgsize_bitmap;
@@ -1204,6 +1206,72 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma,
 	return unlocked;
 }
 
+/* Unmap the IOPF mapped pages in the specified range. */
+static void vfio_unmap_partial_iopf(struct vfio_iommu *iommu,
+				    struct vfio_dma *dma,
+				    dma_addr_t start, dma_addr_t end)
+{
+	struct iommu_iotlb_gather *gathers;
+	struct vfio_domain *d;
+	int i, num_domains = 0;
+
+	list_for_each_entry(d, &iommu->domain_list, next)
+		num_domains++;
+
+	gathers = kzalloc(sizeof(*gathers) * num_domains, GFP_KERNEL);
+	if (gathers) {
+		for (i = 0; i < num_domains; i++)
+			iommu_iotlb_gather_init(&gathers[i]);
+	}
+
+	while (start < end) {
+		unsigned long bit_offset;
+		size_t len;
+
+		bit_offset = (start - dma->iova) >> PAGE_SHIFT;
+
+		for (len = 0; start + len < end; len += PAGE_SIZE) {
+			if (!IOPF_MAPPED_BITMAP_GET(dma,
+					bit_offset + (len >> PAGE_SHIFT)))
+				break;
+		}
+
+		if (len) {
+			i = 0;
+			list_for_each_entry(d, &iommu->domain_list, next) {
+				size_t unmapped;
+
+				if (gathers)
+					unmapped = iommu_unmap_fast(d->domain,
+								    start, len,
+								    &gathers[i++]);
+				else
+					unmapped = iommu_unmap(d->domain,
+							       start, len);
+
+				if (WARN_ON(unmapped != len))
+					goto out;
+			}
+
+			bitmap_clear(dma->iopf_mapped_bitmap,
+				     bit_offset, len >> PAGE_SHIFT);
+
+			cond_resched();
+		}
+
+		start += (len + PAGE_SIZE);
+	}
+
+out:
+	if (gathers) {
+		i = 0;
+		list_for_each_entry(d, &iommu->domain_list, next)
+			iommu_iotlb_sync(d->domain, &gathers[i++]);
+
+		kfree(gathers);
+	}
+}
+
 static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
 {
 	WARN_ON(!RB_EMPTY_ROOT(&dma->pfn_list));
@@ -3197,17 +3265,18 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 
 	vaddr = iova - dma->iova + dma->vaddr;
 
-	if (vfio_pin_page_external(dma, vaddr, &pfn, true))
+	if (vfio_pin_page_external(dma, vaddr, &pfn, false))
 		goto out_invalid;
 
 	if (vfio_iommu_map(iommu, iova, pfn, 1, dma->prot)) {
-		if (put_pfn(pfn, dma->prot))
-			vfio_lock_acct(dma, -1, true);
+		put_pfn(pfn, dma->prot);
 		goto out_invalid;
 	}
 
 	bitmap_set(dma->iopf_mapped_bitmap, bit_offset, 1);
 
+	put_pfn(pfn, dma->prot);
+
 out_success:
 	status = IOMMU_PAGE_RESP_SUCCESS;
 
@@ -3220,6 +3289,43 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
 	return 0;
 }
 
+static void mn_invalidate_range(struct mmu_notifier *mn, struct mm_struct *mm,
+				unsigned long start, unsigned long end)
+{
+	struct vfio_iommu *iommu = container_of(mn, struct vfio_iommu, mn);
+	struct rb_node *n;
+	int ret;
+
+	mutex_lock(&iommu->lock);
+
+	ret = vfio_wait_all_valid(iommu);
+	if (WARN_ON(ret < 0))
+		return;
+
+	for (n = rb_first(&iommu->dma_list); n; n = rb_next(n)) {
+		struct vfio_dma *dma = rb_entry(n, struct vfio_dma, node);
+		unsigned long start_n, end_n;
+
+		if (end <= dma->vaddr || start >= dma->vaddr + dma->size)
+			continue;
+
+		start_n = ALIGN_DOWN(max_t(unsigned long, start, dma->vaddr),
+				     PAGE_SIZE);
+		end_n = ALIGN(min_t(unsigned long, end, dma->vaddr + dma->size),
+			      PAGE_SIZE);
+
+		vfio_unmap_partial_iopf(iommu, dma,
+					start_n - dma->vaddr + dma->iova,
+					end_n - dma->vaddr + dma->iova);
+	}
+
+	mutex_unlock(&iommu->lock);
+}
+
+static const struct mmu_notifier_ops vfio_iommu_type1_mn_ops = {
+	.invalidate_range	= mn_invalidate_range,
+};
+
 static long vfio_iommu_type1_ioctl(void *iommu_data,
 				   unsigned int cmd, unsigned long arg)
 {
-- 
2.19.1



From zweiss at equinix.com  Fri Apr  9 04:56:01 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 03:56:01 +0000
Subject: [PATCH v2 09/21] ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmi
In-Reply-To: <20210319062752.145730-9-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-9-andrew@aj.id.au>
Message-ID: <YG/QUCIdEzW1ghVA@packtop>

On Fri, Mar 19, 2021 at 01:27:40AM CDT, Andrew Jeffery wrote:
>Take steps towards defining a coherent API to separate the KCS device
>drivers from the userspace interface. Decreasing the coupling will
>improve the separation of concerns and enable the introduction of
>alternative userspace interfaces.
>
>For now, simply split the chardev logic out to a separate file. The code
>continues to build into the same module.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/Makefile            |   2 +-
> drivers/char/ipmi/kcs_bmc.c           | 423 +------------------------
> drivers/char/ipmi/kcs_bmc.h           |  10 +-
> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 428 ++++++++++++++++++++++++++
> 4 files changed, 451 insertions(+), 412 deletions(-)
> create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>
>diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>index 0822adc2ec41..a302bc865370 100644
>--- a/drivers/char/ipmi/Makefile
>+++ b/drivers/char/ipmi/Makefile
>@@ -22,7 +22,7 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
> obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
> obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
>-obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
>+obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
> obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index c4336c1f2d6d..ef5c48ffe74a 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -3,446 +3,51 @@
>  * Copyright (c) 2015-2018, Intel Corporation.
>  */
>
>-#define pr_fmt(fmt) "kcs-bmc: " fmt
>-
>-#include <linux/errno.h>
>-#include <linux/io.h>
>-#include <linux/ipmi_bmc.h>
> #include <linux/module.h>
>-#include <linux/platform_device.h>
>-#include <linux/poll.h>
>-#include <linux/sched.h>
>-#include <linux/slab.h>
>
> #include "kcs_bmc.h"
>
>-#define DEVICE_NAME "ipmi-kcs"
>-
>-#define KCS_MSG_BUFSIZ    1000
>-
>-#define KCS_ZERO_DATA     0
>-
>-
>-/* IPMI 2.0 - Table 9-1, KCS Interface Status Register Bits */
>-#define KCS_STATUS_STATE(state) (state << 6)
>-#define KCS_STATUS_STATE_MASK   GENMASK(7, 6)
>-#define KCS_STATUS_CMD_DAT      BIT(3)
>-#define KCS_STATUS_SMS_ATN      BIT(2)
>-#define KCS_STATUS_IBF          BIT(1)
>-#define KCS_STATUS_OBF          BIT(0)
>-
>-/* IPMI 2.0 - Table 9-2, KCS Interface State Bits */
>-enum kcs_states {
>-	IDLE_STATE  = 0,
>-	READ_STATE  = 1,
>-	WRITE_STATE = 2,
>-	ERROR_STATE = 3,
>-};
>-
>-/* IPMI 2.0 - Table 9-3, KCS Interface Control Codes */
>-#define KCS_CMD_GET_STATUS_ABORT  0x60
>-#define KCS_CMD_WRITE_START       0x61
>-#define KCS_CMD_WRITE_END         0x62
>-#define KCS_CMD_READ_BYTE         0x68
>-
>-static inline u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
>+u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> {
> 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> }
>+EXPORT_SYMBOL(kcs_bmc_read_data);
>
>-static inline void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
>+void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> {
> 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> }
>+EXPORT_SYMBOL(kcs_bmc_write_data);
>
>-static inline u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
>+u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> {
> 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> }
>+EXPORT_SYMBOL(kcs_bmc_read_status);
>
>-static inline void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
>+void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> {
> 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> }
>+EXPORT_SYMBOL(kcs_bmc_write_status);
>
>-static void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
>+void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> {
> 	kcs_bmc->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> }
>+EXPORT_SYMBOL(kcs_bmc_update_status);
>
>-static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
>-{
>-	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
>-					KCS_STATUS_STATE(state));
>-}
>-
>-static void kcs_force_abort(struct kcs_bmc *kcs_bmc)
>-{
>-	set_state(kcs_bmc, ERROR_STATE);
>-	kcs_bmc_read_data(kcs_bmc);
>-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-
>-	kcs_bmc->phase = KCS_PHASE_ERROR;
>-	kcs_bmc->data_in_avail = false;
>-	kcs_bmc->data_in_idx = 0;
>-}
>-
>-static void kcs_bmc_handle_data(struct kcs_bmc *kcs_bmc)
>-{
>-	u8 data;
>-
>-	switch (kcs_bmc->phase) {
>-	case KCS_PHASE_WRITE_START:
>-		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
>-		fallthrough;
>-
>-	case KCS_PHASE_WRITE_DATA:
>-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>-			set_state(kcs_bmc, WRITE_STATE);
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>-						kcs_bmc_read_data(kcs_bmc);
>-		} else {
>-			kcs_force_abort(kcs_bmc);
>-			kcs_bmc->error = KCS_LENGTH_ERROR;
>-		}
>-		break;
>-
>-	case KCS_PHASE_WRITE_END_CMD:
>-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>-			set_state(kcs_bmc, READ_STATE);
>-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>-						kcs_bmc_read_data(kcs_bmc);
>-			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
>-			kcs_bmc->data_in_avail = true;
>-			wake_up_interruptible(&kcs_bmc->queue);
>-		} else {
>-			kcs_force_abort(kcs_bmc);
>-			kcs_bmc->error = KCS_LENGTH_ERROR;
>-		}
>-		break;
>-
>-	case KCS_PHASE_READ:
>-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
>-			set_state(kcs_bmc, IDLE_STATE);
>-
>-		data = kcs_bmc_read_data(kcs_bmc);
>-		if (data != KCS_CMD_READ_BYTE) {
>-			set_state(kcs_bmc, ERROR_STATE);
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-			break;
>-		}
>-
>-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-			kcs_bmc->phase = KCS_PHASE_IDLE;
>-			break;
>-		}
>-
>-		kcs_bmc_write_data(kcs_bmc,
>-			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
>-		break;
>-
>-	case KCS_PHASE_ABORT_ERROR1:
>-		set_state(kcs_bmc, READ_STATE);
>-		kcs_bmc_read_data(kcs_bmc);
>-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
>-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
>-		break;
>-
>-	case KCS_PHASE_ABORT_ERROR2:
>-		set_state(kcs_bmc, IDLE_STATE);
>-		kcs_bmc_read_data(kcs_bmc);
>-		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-		kcs_bmc->phase = KCS_PHASE_IDLE;
>-		break;
>-
>-	default:
>-		kcs_force_abort(kcs_bmc);
>-		break;
>-	}
>-}
>-
>-static void kcs_bmc_handle_cmd(struct kcs_bmc *kcs_bmc)
>-{
>-	u8 cmd;
>-
>-	set_state(kcs_bmc, WRITE_STATE);
>-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-
>-	cmd = kcs_bmc_read_data(kcs_bmc);
>-	switch (cmd) {
>-	case KCS_CMD_WRITE_START:
>-		kcs_bmc->phase = KCS_PHASE_WRITE_START;
>-		kcs_bmc->error = KCS_NO_ERROR;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>-		break;
>-
>-	case KCS_CMD_WRITE_END:
>-		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
>-			kcs_force_abort(kcs_bmc);
>-			break;
>-		}
>-
>-		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
>-		break;
>-
>-	case KCS_CMD_GET_STATUS_ABORT:
>-		if (kcs_bmc->error == KCS_NO_ERROR)
>-			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
>-
>-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>-		break;
>-
>-	default:
>-		kcs_force_abort(kcs_bmc);
>-		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
>-		break;
>-	}
>-}
>-
>+int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);

This declaration looks a bit out of place here; should it be in
kcs_bmc.h instead?

> int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> {
>-	unsigned long flags;
>-	int ret = -ENODATA;
>-	u8 status;
>-
>-	spin_lock_irqsave(&kcs_bmc->lock, flags);
>-
>-	status = kcs_bmc_read_status(kcs_bmc);
>-	if (status & KCS_STATUS_IBF) {
>-		if (!kcs_bmc->running)
>-			kcs_force_abort(kcs_bmc);
>-		else if (status & KCS_STATUS_CMD_DAT)
>-			kcs_bmc_handle_cmd(kcs_bmc);
>-		else
>-			kcs_bmc_handle_data(kcs_bmc);
>-
>-		ret = 0;
>-	}
>-
>-	spin_unlock_irqrestore(&kcs_bmc->lock, flags);
>-
>-	return ret;
>+	return kcs_bmc_ipmi_event(kcs_bmc);
> }
> EXPORT_SYMBOL(kcs_bmc_handle_event);
>
>-static inline struct kcs_bmc *to_kcs_bmc(struct file *filp)
>-{
>-	return container_of(filp->private_data, struct kcs_bmc, miscdev);
>-}
>-
>-static int kcs_bmc_open(struct inode *inode, struct file *filp)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-	int ret = 0;
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (!kcs_bmc->running)
>-		kcs_bmc->running = 1;
>-	else
>-		ret = -EBUSY;
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	return ret;
>-}
>-
>-static __poll_t kcs_bmc_poll(struct file *filp, poll_table *wait)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-	__poll_t mask = 0;
>-
>-	poll_wait(filp, &kcs_bmc->queue, wait);
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->data_in_avail)
>-		mask |= EPOLLIN;
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	return mask;
>-}
>-
>-static ssize_t kcs_bmc_read(struct file *filp, char __user *buf,
>-			    size_t count, loff_t *ppos)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-	bool data_avail;
>-	size_t data_len;
>-	ssize_t ret;
>-
>-	if (!(filp->f_flags & O_NONBLOCK))
>-		wait_event_interruptible(kcs_bmc->queue,
>-					 kcs_bmc->data_in_avail);
>-
>-	mutex_lock(&kcs_bmc->mutex);
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	data_avail = kcs_bmc->data_in_avail;
>-	if (data_avail) {
>-		data_len = kcs_bmc->data_in_idx;
>-		memcpy(kcs_bmc->kbuffer, kcs_bmc->data_in, data_len);
>-	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	if (!data_avail) {
>-		ret = -EAGAIN;
>-		goto out_unlock;
>-	}
>-
>-	if (count < data_len) {
>-		pr_err("channel=%u with too large data : %zu\n",
>-			kcs_bmc->channel, data_len);
>-
>-		spin_lock_irq(&kcs_bmc->lock);
>-		kcs_force_abort(kcs_bmc);
>-		spin_unlock_irq(&kcs_bmc->lock);
>-
>-		ret = -EOVERFLOW;
>-		goto out_unlock;
>-	}
>-
>-	if (copy_to_user(buf, kcs_bmc->kbuffer, data_len)) {
>-		ret = -EFAULT;
>-		goto out_unlock;
>-	}
>-
>-	ret = data_len;
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->phase == KCS_PHASE_WRITE_DONE) {
>-		kcs_bmc->phase = KCS_PHASE_WAIT_READ;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>-	} else {
>-		ret = -EAGAIN;
>-	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-out_unlock:
>-	mutex_unlock(&kcs_bmc->mutex);
>-
>-	return ret;
>-}
>-
>-static ssize_t kcs_bmc_write(struct file *filp, const char __user *buf,
>-			     size_t count, loff_t *ppos)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-	ssize_t ret;
>-
>-	/* a minimum response size '3' : netfn + cmd + ccode */
>-	if (count < 3 || count > KCS_MSG_BUFSIZ)
>-		return -EINVAL;
>-
>-	mutex_lock(&kcs_bmc->mutex);
>-
>-	if (copy_from_user(kcs_bmc->kbuffer, buf, count)) {
>-		ret = -EFAULT;
>-		goto out_unlock;
>-	}
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->phase == KCS_PHASE_WAIT_READ) {
>-		kcs_bmc->phase = KCS_PHASE_READ;
>-		kcs_bmc->data_out_idx = 1;
>-		kcs_bmc->data_out_len = count;
>-		memcpy(kcs_bmc->data_out, kcs_bmc->kbuffer, count);
>-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->data_out[0]);
>-		ret = count;
>-	} else {
>-		ret = -EINVAL;
>-	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-out_unlock:
>-	mutex_unlock(&kcs_bmc->mutex);
>-
>-	return ret;
>-}
>-
>-static long kcs_bmc_ioctl(struct file *filp, unsigned int cmd,
>-			  unsigned long arg)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-	long ret = 0;
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-
>-	switch (cmd) {
>-	case IPMI_BMC_IOCTL_SET_SMS_ATN:
>-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
>-		break;
>-
>-	case IPMI_BMC_IOCTL_CLEAR_SMS_ATN:
>-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, 0);
>-		break;
>-
>-	case IPMI_BMC_IOCTL_FORCE_ABORT:
>-		kcs_force_abort(kcs_bmc);
>-		break;
>-
>-	default:
>-		ret = -EINVAL;
>-		break;
>-	}
>-
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	return ret;
>-}
>-
>-static int kcs_bmc_release(struct inode *inode, struct file *filp)
>-{
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>-
>-	spin_lock_irq(&kcs_bmc->lock);
>-	kcs_bmc->running = 0;
>-	kcs_force_abort(kcs_bmc);
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	return 0;
>-}
>-
>-static const struct file_operations kcs_bmc_fops = {
>-	.owner          = THIS_MODULE,
>-	.open           = kcs_bmc_open,
>-	.read           = kcs_bmc_read,
>-	.write          = kcs_bmc_write,
>-	.release        = kcs_bmc_release,
>-	.poll           = kcs_bmc_poll,
>-	.unlocked_ioctl = kcs_bmc_ioctl,
>-};
>-
>+struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);

Similarly here.

> struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel)
> {
>-	struct kcs_bmc *kcs_bmc;
>-
>-	kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, GFP_KERNEL);
>-	if (!kcs_bmc)
>-		return NULL;
>-
>-	spin_lock_init(&kcs_bmc->lock);
>-	kcs_bmc->channel = channel;
>-
>-	mutex_init(&kcs_bmc->mutex);
>-	init_waitqueue_head(&kcs_bmc->queue);
>-
>-	kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-
>-	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
>-	kcs_bmc->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s%u",
>-					       DEVICE_NAME, channel);
>-	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
>-	    !kcs_bmc->miscdev.name)
>-		return NULL;
>-	kcs_bmc->miscdev.fops = &kcs_bmc_fops;
>-
>-	return kcs_bmc;
>+	return kcs_bmc_ipmi_alloc(dev, sizeof_priv, channel);
> }
> EXPORT_SYMBOL(kcs_bmc_alloc);
>
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index 970f53892f2d..febea0c8deb4 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -104,6 +104,12 @@ static inline void *kcs_bmc_priv(struct kcs_bmc *kcs_bmc)
> }
>
> int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv,
>-					u32 channel);
>+struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel);
>+
>+u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>+void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>+u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc);
>+void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data);
>+void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val);
>+
> #endif /* __KCS_BMC_H__ */
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>new file mode 100644
>index 000000000000..82c77994e481
>--- /dev/null
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>@@ -0,0 +1,428 @@
>+// SPDX-License-Identifier: GPL-2.0
>+/*
>+ * Copyright (c) 2015-2018, Intel Corporation.
>+ */
>+
>+#define pr_fmt(fmt) "kcs-bmc: " fmt
>+
>+#include <linux/errno.h>
>+#include <linux/io.h>
>+#include <linux/ipmi_bmc.h>
>+#include <linux/module.h>
>+#include <linux/platform_device.h>
>+#include <linux/poll.h>
>+#include <linux/sched.h>
>+#include <linux/slab.h>
>+
>+#include "kcs_bmc.h"
>+
>+#define DEVICE_NAME "ipmi-kcs"
>+
>+#define KCS_MSG_BUFSIZ    1000
>+
>+#define KCS_ZERO_DATA     0
>+
>+
>+/* IPMI 2.0 - Table 9-1, KCS Interface Status Register Bits */
>+#define KCS_STATUS_STATE(state) (state << 6)
>+#define KCS_STATUS_STATE_MASK   GENMASK(7, 6)
>+#define KCS_STATUS_CMD_DAT      BIT(3)
>+#define KCS_STATUS_SMS_ATN      BIT(2)
>+#define KCS_STATUS_IBF          BIT(1)
>+#define KCS_STATUS_OBF          BIT(0)
>+
>+/* IPMI 2.0 - Table 9-2, KCS Interface State Bits */
>+enum kcs_states {
>+	IDLE_STATE  = 0,
>+	READ_STATE  = 1,
>+	WRITE_STATE = 2,
>+	ERROR_STATE = 3,
>+};
>+
>+/* IPMI 2.0 - Table 9-3, KCS Interface Control Codes */
>+#define KCS_CMD_GET_STATUS_ABORT  0x60
>+#define KCS_CMD_WRITE_START       0x61
>+#define KCS_CMD_WRITE_END         0x62
>+#define KCS_CMD_READ_BYTE         0x68
>+
>+static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
>+{
>+	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
>+					KCS_STATUS_STATE(state));
>+}
>+
>+static void kcs_bmc_ipmi_force_abort(struct kcs_bmc *kcs_bmc)
>+{
>+	set_state(kcs_bmc, ERROR_STATE);
>+	kcs_bmc_read_data(kcs_bmc);
>+	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+
>+	kcs_bmc->phase = KCS_PHASE_ERROR;
>+	kcs_bmc->data_in_avail = false;
>+	kcs_bmc->data_in_idx = 0;
>+}
>+
>+static void kcs_bmc_ipmi_handle_data(struct kcs_bmc *kcs_bmc)
>+{
>+	u8 data;
>+
>+	switch (kcs_bmc->phase) {
>+	case KCS_PHASE_WRITE_START:
>+		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
>+		fallthrough;
>+
>+	case KCS_PHASE_WRITE_DATA:
>+		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>+			set_state(kcs_bmc, WRITE_STATE);
>+			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>+						kcs_bmc_read_data(kcs_bmc);
>+		} else {
>+			kcs_bmc_ipmi_force_abort(kcs_bmc);
>+			kcs_bmc->error = KCS_LENGTH_ERROR;
>+		}
>+		break;
>+
>+	case KCS_PHASE_WRITE_END_CMD:
>+		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>+			set_state(kcs_bmc, READ_STATE);
>+			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>+						kcs_bmc_read_data(kcs_bmc);
>+			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
>+			kcs_bmc->data_in_avail = true;
>+			wake_up_interruptible(&kcs_bmc->queue);
>+		} else {
>+			kcs_bmc_ipmi_force_abort(kcs_bmc);
>+			kcs_bmc->error = KCS_LENGTH_ERROR;
>+		}
>+		break;
>+
>+	case KCS_PHASE_READ:
>+		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
>+			set_state(kcs_bmc, IDLE_STATE);
>+
>+		data = kcs_bmc_read_data(kcs_bmc);
>+		if (data != KCS_CMD_READ_BYTE) {
>+			set_state(kcs_bmc, ERROR_STATE);
>+			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+			break;
>+		}
>+
>+		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
>+			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+			kcs_bmc->phase = KCS_PHASE_IDLE;
>+			break;
>+		}
>+
>+		kcs_bmc_write_data(kcs_bmc,
>+			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
>+		break;
>+
>+	case KCS_PHASE_ABORT_ERROR1:
>+		set_state(kcs_bmc, READ_STATE);
>+		kcs_bmc_read_data(kcs_bmc);
>+		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
>+		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
>+		break;
>+
>+	case KCS_PHASE_ABORT_ERROR2:
>+		set_state(kcs_bmc, IDLE_STATE);
>+		kcs_bmc_read_data(kcs_bmc);
>+		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+		kcs_bmc->phase = KCS_PHASE_IDLE;
>+		break;
>+
>+	default:
>+		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		break;
>+	}
>+}
>+
>+static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc *kcs_bmc)
>+{
>+	u8 cmd;
>+
>+	set_state(kcs_bmc, WRITE_STATE);
>+	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+
>+	cmd = kcs_bmc_read_data(kcs_bmc);
>+	switch (cmd) {
>+	case KCS_CMD_WRITE_START:
>+		kcs_bmc->phase = KCS_PHASE_WRITE_START;
>+		kcs_bmc->error = KCS_NO_ERROR;
>+		kcs_bmc->data_in_avail = false;
>+		kcs_bmc->data_in_idx = 0;
>+		break;
>+
>+	case KCS_CMD_WRITE_END:
>+		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
>+			kcs_bmc_ipmi_force_abort(kcs_bmc);
>+			break;
>+		}
>+
>+		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
>+		break;
>+
>+	case KCS_CMD_GET_STATUS_ABORT:
>+		if (kcs_bmc->error == KCS_NO_ERROR)
>+			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
>+
>+		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
>+		kcs_bmc->data_in_avail = false;
>+		kcs_bmc->data_in_idx = 0;
>+		break;
>+
>+	default:
>+		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
>+		break;
>+	}
>+}
>+
>+int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);

Another instance...

>+int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc)
>+{
>+	unsigned long flags;
>+	int ret = -ENODATA;
>+	u8 status;
>+
>+	spin_lock_irqsave(&kcs_bmc->lock, flags);
>+
>+	status = kcs_bmc_read_status(kcs_bmc);
>+	if (status & KCS_STATUS_IBF) {
>+		if (!kcs_bmc->running)
>+			kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		else if (status & KCS_STATUS_CMD_DAT)
>+			kcs_bmc_ipmi_handle_cmd(kcs_bmc);
>+		else
>+			kcs_bmc_ipmi_handle_data(kcs_bmc);
>+
>+		ret = 0;
>+	}
>+
>+	spin_unlock_irqrestore(&kcs_bmc->lock, flags);
>+
>+	return ret;
>+}
>+EXPORT_SYMBOL(kcs_bmc_ipmi_event);
>+
>+static inline struct kcs_bmc *to_kcs_bmc(struct file *filp)
>+{
>+	return container_of(filp->private_data, struct kcs_bmc, miscdev);
>+}
>+
>+static int kcs_bmc_ipmi_open(struct inode *inode, struct file *filp)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	int ret = 0;
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (!kcs_bmc->running)
>+		kcs_bmc->running = 1;
>+	else
>+		ret = -EBUSY;
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	return ret;
>+}
>+
>+static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	__poll_t mask = 0;
>+
>+	poll_wait(filp, &kcs_bmc->queue, wait);
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (kcs_bmc->data_in_avail)
>+		mask |= EPOLLIN;
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	return mask;
>+}
>+
>+static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
>+			    size_t count, loff_t *ppos)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	bool data_avail;
>+	size_t data_len;
>+	ssize_t ret;
>+
>+	if (!(filp->f_flags & O_NONBLOCK))
>+		wait_event_interruptible(kcs_bmc->queue,
>+					 kcs_bmc->data_in_avail);
>+
>+	mutex_lock(&kcs_bmc->mutex);
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	data_avail = kcs_bmc->data_in_avail;
>+	if (data_avail) {
>+		data_len = kcs_bmc->data_in_idx;
>+		memcpy(kcs_bmc->kbuffer, kcs_bmc->data_in, data_len);
>+	}
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	if (!data_avail) {
>+		ret = -EAGAIN;
>+		goto out_unlock;
>+	}
>+
>+	if (count < data_len) {
>+		pr_err("channel=%u with too large data : %zu\n",
>+			kcs_bmc->channel, data_len);
>+
>+		spin_lock_irq(&kcs_bmc->lock);
>+		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		spin_unlock_irq(&kcs_bmc->lock);
>+
>+		ret = -EOVERFLOW;
>+		goto out_unlock;
>+	}
>+
>+	if (copy_to_user(buf, kcs_bmc->kbuffer, data_len)) {
>+		ret = -EFAULT;
>+		goto out_unlock;
>+	}
>+
>+	ret = data_len;
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (kcs_bmc->phase == KCS_PHASE_WRITE_DONE) {
>+		kcs_bmc->phase = KCS_PHASE_WAIT_READ;
>+		kcs_bmc->data_in_avail = false;
>+		kcs_bmc->data_in_idx = 0;
>+	} else {
>+		ret = -EAGAIN;
>+	}
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+out_unlock:
>+	mutex_unlock(&kcs_bmc->mutex);
>+
>+	return ret;
>+}
>+
>+static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
>+			     size_t count, loff_t *ppos)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	ssize_t ret;
>+
>+	/* a minimum response size '3' : netfn + cmd + ccode */
>+	if (count < 3 || count > KCS_MSG_BUFSIZ)
>+		return -EINVAL;
>+
>+	mutex_lock(&kcs_bmc->mutex);
>+
>+	if (copy_from_user(kcs_bmc->kbuffer, buf, count)) {
>+		ret = -EFAULT;
>+		goto out_unlock;
>+	}
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (kcs_bmc->phase == KCS_PHASE_WAIT_READ) {
>+		kcs_bmc->phase = KCS_PHASE_READ;
>+		kcs_bmc->data_out_idx = 1;
>+		kcs_bmc->data_out_len = count;
>+		memcpy(kcs_bmc->data_out, kcs_bmc->kbuffer, count);
>+		kcs_bmc_write_data(kcs_bmc, kcs_bmc->data_out[0]);
>+		ret = count;
>+	} else {
>+		ret = -EINVAL;
>+	}
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+out_unlock:
>+	mutex_unlock(&kcs_bmc->mutex);
>+
>+	return ret;
>+}
>+
>+static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
>+			  unsigned long arg)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	long ret = 0;
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+
>+	switch (cmd) {
>+	case IPMI_BMC_IOCTL_SET_SMS_ATN:
>+		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
>+		break;
>+
>+	case IPMI_BMC_IOCTL_CLEAR_SMS_ATN:
>+		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, 0);
>+		break;
>+
>+	case IPMI_BMC_IOCTL_FORCE_ABORT:
>+		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		break;
>+
>+	default:
>+		ret = -EINVAL;
>+		break;
>+	}
>+
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	return ret;
>+}
>+
>+static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
>+{
>+	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	kcs_bmc->running = 0;
>+	kcs_bmc_ipmi_force_abort(kcs_bmc);
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	return 0;
>+}
>+
>+static const struct file_operations kcs_bmc_fops = {
>+	.owner          = THIS_MODULE,
>+	.open           = kcs_bmc_ipmi_open,
>+	.read           = kcs_bmc_ipmi_read,
>+	.write          = kcs_bmc_ipmi_write,
>+	.release        = kcs_bmc_ipmi_release,
>+	.poll           = kcs_bmc_ipmi_poll,
>+	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
>+};
>+
>+struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);

Here too.

>+struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
>+{
>+	struct kcs_bmc *kcs_bmc;
>+
>+	kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, GFP_KERNEL);
>+	if (!kcs_bmc)
>+		return NULL;
>+
>+	spin_lock_init(&kcs_bmc->lock);
>+	kcs_bmc->channel = channel;
>+
>+	mutex_init(&kcs_bmc->mutex);
>+	init_waitqueue_head(&kcs_bmc->queue);
>+
>+	kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+
>+	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
>+	kcs_bmc->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s%u",
>+					       DEVICE_NAME, channel);
>+	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
>+	    !kcs_bmc->miscdev.name)
>+		return NULL;
>+	kcs_bmc->miscdev.fops = &kcs_bmc_fops;
>+
>+	return kcs_bmc;
>+}
>+EXPORT_SYMBOL(kcs_bmc_ipmi_alloc);
>+
>+MODULE_LICENSE("GPL v2");
>+MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>+MODULE_DESCRIPTION("KCS BMC to handle the IPMI request from system software");
>-- 
>2.27.0
>

From zweiss at equinix.com  Fri Apr  9 04:57:12 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 03:57:12 +0000
Subject: [PATCH v2 10/21] ipmi: kcs_bmc: Turn the driver data-structures
 inside-out
In-Reply-To: <20210319062752.145730-10-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-10-andrew@aj.id.au>
Message-ID: <YG/Ql9z9X/mtOSvl@packtop>

On Fri, Mar 19, 2021 at 01:27:41AM CDT, Andrew Jeffery wrote:
>Make the KCS device drivers responsible for allocating their own memory.
>
>Until now the private data for the device driver was allocated internal
>to the private data for the chardev interface. This coupling required
>the slightly awkward API of passing through the struct size for the
>driver private data to the chardev constructor, and then retrieving a
>pointer to the driver private data from the allocated chardev memory.
>
>In addition to being awkward, the arrangement prevents the
>implementation of alternative userspace interfaces as the device driver
>private data is not independent.
>
>Peel a layer off the onion and turn the data-structures inside out by
>exploiting container_of() and embedding `struct kcs_device` in the
>driver private data.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc.c           | 15 +++++--
> drivers/char/ipmi/kcs_bmc.h           | 12 ++----
> drivers/char/ipmi/kcs_bmc_aspeed.c    | 60 ++++++++++++++++-----------
> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 60 ++++++++++++++++++---------
> drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 37 ++++++++++-------
> 5 files changed, 113 insertions(+), 71 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index ef5c48ffe74a..709b6bdec165 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -44,12 +44,19 @@ int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> }
> EXPORT_SYMBOL(kcs_bmc_handle_event);
>
>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel)
>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);

Another declaration perhaps intended for kcs_bmc.h?

>+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
> {
>-	return kcs_bmc_ipmi_alloc(dev, sizeof_priv, channel);
>+	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> }
>-EXPORT_SYMBOL(kcs_bmc_alloc);
>+EXPORT_SYMBOL(kcs_bmc_add_device);
>+
>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);

Here too.

>+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
>+{
>+	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
>+}
>+EXPORT_SYMBOL(kcs_bmc_remove_device);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index febea0c8deb4..bf0ae327997f 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -67,6 +67,8 @@ struct kcs_ioreg {
> };
>
> struct kcs_bmc {
>+	struct device *dev;
>+
> 	spinlock_t lock;
>
> 	u32 channel;
>@@ -94,17 +96,11 @@ struct kcs_bmc {
> 	u8 *kbuffer;
>
> 	struct miscdevice miscdev;
>-
>-	unsigned long priv[];
> };
>
>-static inline void *kcs_bmc_priv(struct kcs_bmc *kcs_bmc)
>-{
>-	return kcs_bmc->priv;
>-}
>-
> int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel);
>+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>
> u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
> void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 630cf095560e..0416ac78ce68 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -61,6 +61,8 @@
> #define LPC_STR4             0x11C
>
> struct aspeed_kcs_bmc {
>+	struct kcs_bmc kcs_bmc;
>+
> 	struct regmap *map;
> };
>
>@@ -69,9 +71,14 @@ struct aspeed_kcs_of_ops {
> 	int (*get_io_address)(struct platform_device *pdev);
> };
>
>+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
>+{
>+	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
>+}
>+
> static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> {
>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	u32 val = 0;
> 	int rc;
>
>@@ -83,7 +90,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>
> static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> {
>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	int rc;
>
> 	rc = regmap_write(priv->map, reg, data);
>@@ -92,7 +99,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>
> static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
> {
>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	int rc;
>
> 	rc = regmap_update_bits(priv->map, reg, mask, val);
>@@ -114,7 +121,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
>  */
> static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> {
>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>
> 	switch (kcs_bmc->channel) {
> 	case 1:
>@@ -148,7 +155,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>
> static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> {
>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>
> 	switch (kcs_bmc->channel) {
> 	case 1:
>@@ -323,16 +330,16 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
> static int aspeed_kcs_probe(struct platform_device *pdev)
> {
> 	const struct aspeed_kcs_of_ops *ops;
>-	struct device *dev = &pdev->dev;
>+	struct aspeed_kcs_bmc *priv;
> 	struct kcs_bmc *kcs_bmc;
> 	struct device_node *np;
> 	int rc, channel, addr;
>
>-	np = dev->of_node->parent;
>+	np = pdev->dev.of_node->parent;
> 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
> 	    !of_device_is_compatible(np, "aspeed,ast2500-lpc-v2") &&
> 	    !of_device_is_compatible(np, "aspeed,ast2600-lpc-v2")) {
>-		dev_err(dev, "unsupported LPC device binding\n");
>+		dev_err(&pdev->dev, "unsupported LPC device binding\n");
> 		return -ENODEV;
> 	}
> 	ops = of_device_get_match_data(&pdev->dev);
>@@ -343,18 +350,27 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	if (channel < 0)
> 		return channel;
>
>-	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>-	if (!kcs_bmc)
>+	addr = ops->get_io_address(pdev);
>+	if (addr < 0)
>+		return addr;
>+
>+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>+	if (!priv)
> 		return -ENOMEM;
>
>+	kcs_bmc = &priv->kcs_bmc;
>+	kcs_bmc->dev = &pdev->dev;
>+	kcs_bmc->channel = channel;
> 	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
> 	kcs_bmc->io_inputb = aspeed_kcs_inb;
> 	kcs_bmc->io_outputb = aspeed_kcs_outb;
> 	kcs_bmc->io_updateb = aspeed_kcs_updateb;
>
>-	addr = ops->get_io_address(pdev);
>-	if (addr < 0)
>-		return addr;
>+	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>+	if (IS_ERR(priv->map)) {
>+		dev_err(&pdev->dev, "Couldn't get regmap\n");
>+		return -ENODEV;
>+	}

The reanimated priv->map initialization I suspect wasn't meant to
have been removed in the first place...

>
> 	aspeed_kcs_set_address(kcs_bmc, addr);
>
>@@ -362,29 +378,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	if (rc)
> 		return rc;
>
>-	dev_set_drvdata(dev, kcs_bmc);
>+	platform_set_drvdata(pdev, priv);
>
> 	aspeed_kcs_enable_channel(kcs_bmc, true);
>
>-	rc = misc_register(&kcs_bmc->miscdev);
>-	if (rc) {
>-		dev_err(dev, "Unable to register device\n");
>+	rc = kcs_bmc_add_device(&priv->kcs_bmc);
>+	if (rc < 0)
> 		return rc;
>-	}
>
>-	dev_dbg(&pdev->dev,
>-		"Probed KCS device %d (IDR=0x%x, ODR=0x%x, STR=0x%x)\n",
>-		kcs_bmc->channel, kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr,
>-		kcs_bmc->ioreg.str);
>+	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n", kcs_bmc->channel, addr);

Is the dbg->info change here intentional?  (I have no particular
objection if so, but it's often a change I make myself during
testing/debugging and then forget to revert...)

>
> 	return 0;
> }
>
> static int aspeed_kcs_remove(struct platform_device *pdev)
> {
>-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
>+	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
>+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>
>-	misc_deregister(&kcs_bmc->miscdev);
>+	kcs_bmc_remove_device(kcs_bmc);

Should we propagate the return value outward here?

>
> 	return 0;
> }
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>index 82c77994e481..0ca71c135a1a 100644
>--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>@@ -382,7 +382,7 @@ static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
> 	return 0;
> }
>
>-static const struct file_operations kcs_bmc_fops = {
>+static const struct file_operations kcs_bmc_ipmi_fops = {
> 	.owner          = THIS_MODULE,
> 	.open           = kcs_bmc_ipmi_open,
> 	.read           = kcs_bmc_ipmi_read,
>@@ -392,36 +392,58 @@ static const struct file_operations kcs_bmc_fops = {
> 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
> };
>
>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);

Errant declaration again?

>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
> {
>-	struct kcs_bmc *kcs_bmc;
>-
>-	kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, GFP_KERNEL);
>-	if (!kcs_bmc)
>-		return NULL;
>+	int rc;
>
> 	spin_lock_init(&kcs_bmc->lock);
>-	kcs_bmc->channel = channel;
>-
> 	mutex_init(&kcs_bmc->mutex);
> 	init_waitqueue_head(&kcs_bmc->queue);
>
>-	kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>
> 	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
>-	kcs_bmc->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s%u",
>-					       DEVICE_NAME, channel);
>+	kcs_bmc->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u",
>+					       DEVICE_NAME, kcs_bmc->channel);
> 	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
> 	    !kcs_bmc->miscdev.name)
>-		return NULL;
>-	kcs_bmc->miscdev.fops = &kcs_bmc_fops;
>+		return -ENOMEM;
>
>-	return kcs_bmc;
>+	kcs_bmc->miscdev.fops = &kcs_bmc_ipmi_fops;
>+
>+	rc = misc_register(&kcs_bmc->miscdev);
>+	if (rc) {
>+		dev_err(kcs_bmc->dev, "Unable to register device: %d\n", rc);
>+		return rc;
>+	}
>+
>+	dev_info(kcs_bmc->dev, "Initialised IPMI client for channel %d", kcs_bmc->channel);
>+
>+	return 0;
>+}
>+EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
>+
>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);

Same here.

>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc)
>+{
>+	misc_deregister(&kcs_bmc->miscdev);
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	kcs_bmc->running = 0;
>+	kcs_bmc_ipmi_force_abort(kcs_bmc);
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	devm_kfree(kcs_bmc->dev, kcs_bmc->kbuffer);
>+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_out);
>+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_in);
>+	devm_kfree(kcs_bmc->dev, kcs_bmc);
>+
>+	return 0;
> }
>-EXPORT_SYMBOL(kcs_bmc_ipmi_alloc);
>+EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>index 1f44aadec9e8..5d017498dc69 100644
>--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>@@ -65,6 +65,8 @@ struct npcm7xx_kcs_reg {
> };
>
> struct npcm7xx_kcs_bmc {
>+	struct kcs_bmc kcs_bmc;
>+
> 	struct regmap *map;
>
> 	const struct npcm7xx_kcs_reg *reg;
>@@ -76,9 +78,14 @@ static const struct npcm7xx_kcs_reg npcm7xx_kcs_reg_tbl[KCS_CHANNEL_MAX] = {
> 	{ .sts = KCS3ST, .dob = KCS3DO, .dib = KCS3DI, .ctl = KCS3CTL, .ie = KCS3IE },
> };
>
>+static inline struct npcm7xx_kcs_bmc *to_npcm7xx_kcs_bmc(struct kcs_bmc *kcs_bmc)
>+{
>+	return container_of(kcs_bmc, struct npcm7xx_kcs_bmc, kcs_bmc);
>+}
>+
> static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> {
>-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	u32 val = 0;
> 	int rc;
>
>@@ -90,7 +97,7 @@ static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>
> static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> {
>-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	int rc;
>
> 	rc = regmap_write(priv->map, reg, data);
>@@ -99,7 +106,7 @@ static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>
> static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 data)
> {
>-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	int rc;
>
> 	rc = regmap_update_bits(priv->map, reg, mask, data);
>@@ -108,7 +115,7 @@ static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 da
>
> static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> {
>-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>
> 	regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
> 			   enable ? KCS_CTL_IBFIE : 0);
>@@ -155,11 +162,10 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> 		return -ENODEV;
> 	}
>
>-	kcs_bmc = kcs_bmc_alloc(dev, sizeof(*priv), chan);
>-	if (!kcs_bmc)
>+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>+	if (!priv)
> 		return -ENOMEM;
>
>-	priv = kcs_bmc_priv(kcs_bmc);
> 	priv->map = syscon_node_to_regmap(dev->parent->of_node);
> 	if (IS_ERR(priv->map)) {
> 		dev_err(dev, "Couldn't get regmap\n");
>@@ -167,6 +173,9 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> 	}
> 	priv->reg = &npcm7xx_kcs_reg_tbl[chan - 1];
>
>+	kcs_bmc = &priv->kcs_bmc;
>+	kcs_bmc->dev = &pdev->dev;
>+	kcs_bmc->channel = chan;
> 	kcs_bmc->ioreg.idr = priv->reg->dib;
> 	kcs_bmc->ioreg.odr = priv->reg->dob;
> 	kcs_bmc->ioreg.str = priv->reg->sts;
>@@ -174,31 +183,27 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> 	kcs_bmc->io_outputb = npcm7xx_kcs_outb;
> 	kcs_bmc->io_updateb = npcm7xx_kcs_updateb;
>
>-	dev_set_drvdata(dev, kcs_bmc);
>+	platform_set_drvdata(pdev, priv);
>
> 	npcm7xx_kcs_enable_channel(kcs_bmc, true);
> 	rc = npcm7xx_kcs_config_irq(kcs_bmc, pdev);
> 	if (rc)
> 		return rc;
>
>-	rc = misc_register(&kcs_bmc->miscdev);
>-	if (rc) {
>-		dev_err(dev, "Unable to register device\n");
>-		return rc;
>-	}
>
> 	pr_info("channel=%u idr=0x%x odr=0x%x str=0x%x\n",
> 		chan,
> 		kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr, kcs_bmc->ioreg.str);
>
>-	return 0;
>+	return kcs_bmc_add_device(kcs_bmc);
> }
>
> static int npcm7xx_kcs_remove(struct platform_device *pdev)
> {
>-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
>+	struct npcm7xx_kcs_bmc *priv = platform_get_drvdata(pdev);
>+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>
>-	misc_deregister(&kcs_bmc->miscdev);
>+	kcs_bmc_remove_device(kcs_bmc);

As with the corresponding aspeed code, should we propagate the return
value here?

>
> 	return 0;
> }
>-- 
>2.27.0
>

From zweiss at equinix.com  Fri Apr  9 05:01:21 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 04:01:21 +0000
Subject: [PATCH v2 11/21] ipmi: kcs_bmc: Split headers into device and
 client
In-Reply-To: <20210319062752.145730-11-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-11-andrew@aj.id.au>
Message-ID: <YG/RkB07Wh69/xdu@packtop>

On Fri, Mar 19, 2021 at 01:27:42AM CDT, Andrew Jeffery wrote:
>Strengthen the distinction between code that abstracts the
>implementation of the KCS behaviours (device drivers) and code that
>exploits KCS behaviours (clients). Neither needs to know about the APIs
>required by the other, so provide separate headers.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc.c           | 21 ++++++++++-----
> drivers/char/ipmi/kcs_bmc.h           | 30 ++++++++++-----------
> drivers/char/ipmi/kcs_bmc_aspeed.c    | 20 +++++++++-----
> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 39 ++++++++++++++++++---------
> drivers/char/ipmi/kcs_bmc_client.h    | 29 ++++++++++++++++++++
> drivers/char/ipmi/kcs_bmc_device.h    | 19 +++++++++++++
> drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 20 +++++++++-----
> 7 files changed, 129 insertions(+), 49 deletions(-)
> create mode 100644 drivers/char/ipmi/kcs_bmc_client.h
> create mode 100644 drivers/char/ipmi/kcs_bmc_device.h
>
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index 709b6bdec165..1046ce2bbefc 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -1,46 +1,52 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
>  * Copyright (c) 2015-2018, Intel Corporation.
>+ * Copyright (c) 2021, IBM Corp.
>  */
>
> #include <linux/module.h>
>
> #include "kcs_bmc.h"
>
>+/* Implement both the device and client interfaces here */
>+#include "kcs_bmc_device.h"
>+#include "kcs_bmc_client.h"
>+
>+/* Consumer data access */
>+
> u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> {
>-	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
>+	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> }
> EXPORT_SYMBOL(kcs_bmc_read_data);
>
> void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> {
>-	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
>+	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> }
> EXPORT_SYMBOL(kcs_bmc_write_data);
>
> u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> {
>-	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
>+	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> }
> EXPORT_SYMBOL(kcs_bmc_read_status);
>
> void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> {
>-	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
>+	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> }
> EXPORT_SYMBOL(kcs_bmc_write_status);
>
> void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> {
>-	kcs_bmc->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
>+	kcs_bmc->ops->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> }
> EXPORT_SYMBOL(kcs_bmc_update_status);
>
>-int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);
> int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> {
>-	return kcs_bmc_ipmi_event(kcs_bmc);
>+	return kcs_bmc->client.ops->event(&kcs_bmc->client);
> }
> EXPORT_SYMBOL(kcs_bmc_handle_event);
>
>@@ -60,4 +66,5 @@ EXPORT_SYMBOL(kcs_bmc_remove_device);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>+MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
> MODULE_DESCRIPTION("KCS BMC to handle the IPMI request from system software");
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index bf0ae327997f..a1350e567723 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -8,6 +8,15 @@
>
> #include <linux/miscdevice.h>
>
>+#include "kcs_bmc_client.h"
>+
>+#define KCS_BMC_EVENT_NONE	0
>+#define KCS_BMC_EVENT_HANDLED	1

Is there a particular reason we're introducing these macros and using an
int return type for kcs_bmc_client_ops.event instead of just having it
be irqreturn_t?  Other event types or outcomes we're anticipating needing
to handle maybe?

>+
>+#define KCS_BMC_STR_OBF		BIT(0)
>+#define KCS_BMC_STR_IBF		BIT(1)
>+#define KCS_BMC_STR_CMD_DAT	BIT(3)

The first two of these macros are used later in the series, but the third
doesn't end up used at all I think?

>+
> /* Different phases of the KCS BMC module.
>  *  KCS_PHASE_IDLE:
>  *            BMC should not be expecting nor sending any data.
>@@ -66,19 +75,21 @@ struct kcs_ioreg {
> 	u32 str;
> };
>
>+struct kcs_bmc_device_ops;
>+
> struct kcs_bmc {
> 	struct device *dev;
>
>+	const struct kcs_bmc_device_ops *ops;
>+
>+	struct kcs_bmc_client client;
>+
> 	spinlock_t lock;
>
> 	u32 channel;
> 	int running;
>
>-	/* Setup by BMC KCS controller driver */
> 	struct kcs_ioreg ioreg;
>-	u8 (*io_inputb)(struct kcs_bmc *kcs_bmc, u32 reg);
>-	void (*io_outputb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 b);
>-	void (*io_updateb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val);
>
> 	enum kcs_phases phase;
> 	enum kcs_errors error;
>@@ -97,15 +108,4 @@ struct kcs_bmc {
>
> 	struct miscdevice miscdev;
> };
>-
>-int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>-
>-u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>-void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>-u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc);
>-void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data);
>-void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val);
>-
> #endif /* __KCS_BMC_H__ */
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 0416ac78ce68..1b313355b1c8 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -21,7 +21,7 @@
> #include <linux/slab.h>
> #include <linux/timer.h>
>
>-#include "kcs_bmc.h"
>+#include "kcs_bmc_device.h"
>
>
> #define DEVICE_NAME     "ast-kcs-bmc"
>@@ -220,14 +220,22 @@ static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> 	}
> }
>
>+static const struct kcs_bmc_device_ops aspeed_kcs_ops = {
>+	.io_inputb = aspeed_kcs_inb,
>+	.io_outputb = aspeed_kcs_outb,
>+	.io_updateb = aspeed_kcs_updateb,
>+};
>+
> static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> {
> 	struct kcs_bmc *kcs_bmc = arg;
>+	int rc;
>
>-	if (!kcs_bmc_handle_event(kcs_bmc))
>-		return IRQ_HANDLED;
>+	rc = kcs_bmc_handle_event(kcs_bmc);
>+	if (rc < 0)
>+		dev_warn(kcs_bmc->dev, "Failed to service irq: %d\n", rc);
>
>-	return IRQ_NONE;
>+	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> }
>
> static int aspeed_kcs_config_irq(struct kcs_bmc *kcs_bmc,
>@@ -362,9 +370,7 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 	kcs_bmc->dev = &pdev->dev;
> 	kcs_bmc->channel = channel;
> 	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
>-	kcs_bmc->io_inputb = aspeed_kcs_inb;
>-	kcs_bmc->io_outputb = aspeed_kcs_outb;
>-	kcs_bmc->io_updateb = aspeed_kcs_updateb;
>+	kcs_bmc->ops = &aspeed_kcs_ops;
>
> 	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> 	if (IS_ERR(priv->map)) {
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>index 0ca71c135a1a..fd852d8abe48 100644
>--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>@@ -22,7 +22,6 @@
>
> #define KCS_ZERO_DATA     0
>
>-
> /* IPMI 2.0 - Table 9-1, KCS Interface Status Register Bits */
> #define KCS_STATUS_STATE(state) (state << 6)
> #define KCS_STATUS_STATE_MASK   GENMASK(7, 6)
>@@ -179,12 +178,19 @@ static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc *kcs_bmc)
> 	}
> }
>
>-int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc)
>+static inline struct kcs_bmc *client_to_kcs_bmc(struct kcs_bmc_client *client)
> {
>+	return container_of(client, struct kcs_bmc, client);
>+}
>+
>+static int kcs_bmc_ipmi_event(struct kcs_bmc_client *client)
>+{
>+	struct kcs_bmc *kcs_bmc;
> 	unsigned long flags;
>-	int ret = -ENODATA;
> 	u8 status;
>+	int ret;
>+
>+	kcs_bmc = client_to_kcs_bmc(client);
>
> 	spin_lock_irqsave(&kcs_bmc->lock, flags);
>
>@@ -197,23 +203,28 @@ int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc)
> 		else
> 			kcs_bmc_ipmi_handle_data(kcs_bmc);
>
>-		ret = 0;
>+		ret = KCS_BMC_EVENT_HANDLED;
>+	} else {
>+		ret = KCS_BMC_EVENT_NONE;
> 	}
>
> 	spin_unlock_irqrestore(&kcs_bmc->lock, flags);
>
> 	return ret;
> }
>-EXPORT_SYMBOL(kcs_bmc_ipmi_event);
>
>-static inline struct kcs_bmc *to_kcs_bmc(struct file *filp)
>+static const struct kcs_bmc_client_ops kcs_bmc_ipmi_client_ops = {
>+	.event = kcs_bmc_ipmi_event,
>+};
>+
>+static inline struct kcs_bmc *file_to_kcs_bmc(struct file *filp)
> {
> 	return container_of(filp->private_data, struct kcs_bmc, miscdev);
> }
>
> static int kcs_bmc_ipmi_open(struct inode *inode, struct file *filp)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> 	int ret = 0;
>
> 	spin_lock_irq(&kcs_bmc->lock);
>@@ -228,7 +239,7 @@ static int kcs_bmc_ipmi_open(struct inode *inode, struct file *filp)
>
> static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> 	__poll_t mask = 0;
>
> 	poll_wait(filp, &kcs_bmc->queue, wait);
>@@ -244,7 +255,7 @@ static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> 			    size_t count, loff_t *ppos)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> 	bool data_avail;
> 	size_t data_len;
> 	ssize_t ret;
>@@ -306,7 +317,7 @@ static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> 			     size_t count, loff_t *ppos)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> 	ssize_t ret;
>
> 	/* a minimum response size '3' : netfn + cmd + ccode */
>@@ -342,7 +353,7 @@ static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
> 			  unsigned long arg)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> 	long ret = 0;
>
> 	spin_lock_irq(&kcs_bmc->lock);
>@@ -372,7 +383,7 @@ static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
>
> static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
> {
>-	struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
>+	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>
> 	spin_lock_irq(&kcs_bmc->lock);
> 	kcs_bmc->running = 0;
>@@ -401,6 +412,8 @@ int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
> 	mutex_init(&kcs_bmc->mutex);
> 	init_waitqueue_head(&kcs_bmc->queue);
>
>+	kcs_bmc->client.dev = kcs_bmc;
>+	kcs_bmc->client.ops = &kcs_bmc_ipmi_client_ops;
> 	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> 	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> 	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>diff --git a/drivers/char/ipmi/kcs_bmc_client.h b/drivers/char/ipmi/kcs_bmc_client.h
>new file mode 100644
>index 000000000000..140631d157d8
>--- /dev/null
>+++ b/drivers/char/ipmi/kcs_bmc_client.h
>@@ -0,0 +1,29 @@
>+/* SPDX-License-Identifier: GPL-2.0 */
>+/* Copyright (c) 2021, IBM Corp. */
>+
>+#ifndef __KCS_BMC_CONSUMER_H__
>+#define __KCS_BMC_CONSUMER_H__
>+
>+#include <linux/list.h>
>+#include <linux/notifier.h>
>+#include <stdbool.h>
>+
>+struct kcs_bmc;
>+struct kcs_bmc_client_ops;
>+
>+struct kcs_bmc_client {
>+	const struct kcs_bmc_client_ops *ops;
>+
>+	struct kcs_bmc *dev;
>+};
>+
>+struct kcs_bmc_client_ops {
>+	int (*event)(struct kcs_bmc_client *client);
>+};
>+
>+u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>+void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>+u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc);
>+void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data);
>+void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val);
>+#endif
>diff --git a/drivers/char/ipmi/kcs_bmc_device.h b/drivers/char/ipmi/kcs_bmc_device.h
>new file mode 100644
>index 000000000000..33462174516d
>--- /dev/null
>+++ b/drivers/char/ipmi/kcs_bmc_device.h
>@@ -0,0 +1,19 @@
>+/* SPDX-License-Identifier: GPL-2.0 */
>+/* Copyright (c) 2021, IBM Corp. */
>+
>+#ifndef __KCS_BMC_DEVICE_H__
>+#define __KCS_BMC_DEVICE_H__
>+
>+#include "kcs_bmc.h"
>+
>+struct kcs_bmc_device_ops {
>+	u8 (*io_inputb)(struct kcs_bmc *kcs_bmc, u32 reg);
>+	void (*io_outputb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 b);
>+	void (*io_updateb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 b);
>+};
>+
>+int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>+
>+#endif
>diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>index 5d017498dc69..1d21697fc585 100644
>--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>@@ -17,7 +17,7 @@
> #include <linux/regmap.h>
> #include <linux/slab.h>
>
>-#include "kcs_bmc.h"
>+#include "kcs_bmc_device.h"
>
> #define DEVICE_NAME	"npcm-kcs-bmc"
> #define KCS_CHANNEL_MAX	3
>@@ -127,11 +127,13 @@ static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> static irqreturn_t npcm7xx_kcs_irq(int irq, void *arg)
> {
> 	struct kcs_bmc *kcs_bmc = arg;
>+	int rc;
>
>-	if (!kcs_bmc_handle_event(kcs_bmc))
>-		return IRQ_HANDLED;
>+	rc = kcs_bmc_handle_event(kcs_bmc);
>+	if (rc < 0)
>+		dev_warn(kcs_bmc->dev, "Failed to service irq: %d\n", rc);
>
>-	return IRQ_NONE;
>+	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> }
>
> static int npcm7xx_kcs_config_irq(struct kcs_bmc *kcs_bmc,
>@@ -148,6 +150,12 @@ static int npcm7xx_kcs_config_irq(struct kcs_bmc *kcs_bmc,
> 				dev_name(dev), kcs_bmc);
> }
>
>+static const struct kcs_bmc_device_ops npcm7xx_kcs_ops = {
>+	.io_inputb = npcm7xx_kcs_inb,
>+	.io_outputb = npcm7xx_kcs_outb,
>+	.io_updateb = npcm7xx_kcs_updateb,
>+};
>+
> static int npcm7xx_kcs_probe(struct platform_device *pdev)
> {
> 	struct device *dev = &pdev->dev;
>@@ -179,9 +187,7 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> 	kcs_bmc->ioreg.idr = priv->reg->dib;
> 	kcs_bmc->ioreg.odr = priv->reg->dob;
> 	kcs_bmc->ioreg.str = priv->reg->sts;
>-	kcs_bmc->io_inputb = npcm7xx_kcs_inb;
>-	kcs_bmc->io_outputb = npcm7xx_kcs_outb;
>-	kcs_bmc->io_updateb = npcm7xx_kcs_updateb;
>+	kcs_bmc->ops = &npcm7xx_kcs_ops;
>
> 	platform_set_drvdata(pdev, priv);
>
>-- 
>2.27.0
>

From viresh.kumar at linaro.org  Fri Apr  9 05:03:15 2021
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Fri, 9 Apr 2021 09:33:15 +0530
Subject: [PATCH -next] ARM: spear: Fix build error with
 CONFIG_ARCH_SPEAR3XX
In-Reply-To: <20210409015515.258653-1-chenlifu@huawei.com>
References: <20210409015515.258653-1-chenlifu@huawei.com>
Message-ID: <20210409040315.vc55eogaxs4zu4xb@vireshk-i7>

On 09-04-21, 09:55, Chen Lifu wrote:
> commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
> deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
> We get build error when CONFIG_ARCH_SPEAR3XX is set:
> arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has no member named 'num_chipselect'
>    42 |  .num_chipselect = 2,
>       |   ^~~~~~~~~~~~~~
> arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>    42 |  .num_chipselect = 2,
>       |                    ^
> 
> Fix the issue by deleting the initialization of 'num_chipselect'
> in spear3xx.c.
> 
> Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Chen Lifu <chenlifu at huawei.com>
> ---
>  arch/arm/mach-spear/spear3xx.c | 10 ----------
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
> index 8537fcffe5a8..f83321d5e353 100644
> --- a/arch/arm/mach-spear/spear3xx.c
> +++ b/arch/arm/mach-spear/spear3xx.c
> @@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
>  	.dma_filter = pl08x_filter_id,
>  	.dma_tx_param = "ssp0_tx",
>  	.dma_rx_param = "ssp0_rx",
> -	/*
> -	 * This is number of spi devices that can be connected to spi. There are
> -	 * two type of chipselects on which slave devices can work. One is chip
> -	 * select provided by spi masters other is controlled through external
> -	 * gpio's. We can't use chipselect provided from spi master (because as
> -	 * soon as FIFO becomes empty, CS is disabled and transfer ends). So
> -	 * this number now depends on number of gpios available for spi. each
> -	 * slave on each master requires a separate gpio pin.
> -	 */
> -	.num_chipselect = 2,
>  };

A patch is already applied by Mark to fix this issue.

-- 
viresh


From joel at jms.id.au  Fri Apr  9 05:07:41 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 04:07:41 +0000
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <6ff29d26-543a-4790-abb4-ebaa3f8d0265@www.fastmail.com>
References: <20210319061952.145040-1-andrew@aj.id.au>
 <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
 <20210408121441.GG7166@minyard.net>
 <6ff29d26-543a-4790-abb4-ebaa3f8d0265@www.fastmail.com>
Message-ID: <CACPK8Xc5HC7TZ6cUDH6+uHQO1LQCZE0YeENua1sE8nDXs0R2mg@mail.gmail.com>

On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew at aj.id.au> wrote:
> On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote:
> > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote:

> > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've
> > > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
> > > > non-KCS LPC-related ASPEED device drivers in a way that enables the
> > > > SerIRQ patches at the end of the series. With Joel's review I'm hoping
> > > > these 5 can go through the aspeed tree, and that the rest can go through
> > > > the IPMI tree.

> > > >
> > > > Please review!
> > >
> > > Unfortunately the cover letter got detached from the rest of the series.
> > >
> > > Any chance you can take a look at the patches?
> >
> > There were some minor concerns that were unanswered, and there really
> > was no review by others for many of the patches.
>
> Right; I was planning to clean up the minor concerns once I'd received
> some more feedback. I could have done a better job of communicating
> that :)

I'll merge the first five through the aspeed tree this coming merge
window. We have acks from the relevant maintainers.

Arnd: would you prefer that this come as it's own pull request, or as
part of the device tree branch?

Andrew, Corey: once I've got my pull requests out I'll look at
reviewing the rest of the series. Perhaps it would pay to re-send that
hunk of patches Andrew with the nits fixed?

Cheers,

Joel


From zweiss at equinix.com  Fri Apr  9 05:07:14 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 04:07:14 +0000
Subject: [PATCH v2 12/21] ipmi: kcs_bmc: Strip private client data from
 struct kcs_bmc
In-Reply-To: <20210319062752.145730-12-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-12-andrew@aj.id.au>
Message-ID: <YG/S8UdjT8TH6cqs@packtop>

On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
>Move all client-private data out of `struct kcs_bmc` into the KCS client
>implementation.
>
>With this change the KCS BMC core code now only concerns itself with
>abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
>expected separation of concerns. Further, the change clears the path for
>implementation of alternative userspace interfaces.
>
>The chardev data-structures are rearranged in the same manner applied to
>the KCS device driver data-structures in an earlier patch - `struct
>kcs_bmc_client` is embedded in the client's private data and we exploit
>container_of() to translate as required.
>
>Finally, now that it is free of client data, `struct kcs_bmc` is renamed
>to `struct kcs_bmc_device` to contrast `struct kcs_bmc_client`.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc.c           |  68 +++-
> drivers/char/ipmi/kcs_bmc.h           |  86 +-----
> drivers/char/ipmi/kcs_bmc_aspeed.c    |  22 +-
> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 428 ++++++++++++++++----------
> drivers/char/ipmi/kcs_bmc_client.h    |  28 +-
> drivers/char/ipmi/kcs_bmc_device.h    |  12 +-
> drivers/char/ipmi/kcs_bmc_npcm7xx.c   |  20 +-
> 7 files changed, 368 insertions(+), 296 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index 1046ce2bbefc..266ebec71d6f 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -4,6 +4,7 @@
>  * Copyright (c) 2021, IBM Corp.
>  */
>
>+#include <linux/device.h>
> #include <linux/module.h>
>
> #include "kcs_bmc.h"
>@@ -14,51 +15,96 @@
>
> /* Consumer data access */
>
>-u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
>+u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc)
> {
> 	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> }
> EXPORT_SYMBOL(kcs_bmc_read_data);
>
>-void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
>+void kcs_bmc_write_data(struct kcs_bmc_device *kcs_bmc, u8 data)
> {
> 	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> }
> EXPORT_SYMBOL(kcs_bmc_write_data);
>
>-u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
>+u8 kcs_bmc_read_status(struct kcs_bmc_device *kcs_bmc)
> {
> 	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> }
> EXPORT_SYMBOL(kcs_bmc_read_status);
>
>-void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
>+void kcs_bmc_write_status(struct kcs_bmc_device *kcs_bmc, u8 data)
> {
> 	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> }
> EXPORT_SYMBOL(kcs_bmc_write_status);
>
>-void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
>+void kcs_bmc_update_status(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 val)
> {
> 	kcs_bmc->ops->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> }
> EXPORT_SYMBOL(kcs_bmc_update_status);
>
>-int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
>+int kcs_bmc_handle_event(struct kcs_bmc_device *kcs_bmc)
> {
>-	return kcs_bmc->client.ops->event(&kcs_bmc->client);
>+	struct kcs_bmc_client *client;
>+	int rc;
>+
>+	spin_lock(&kcs_bmc->lock);
>+	client = kcs_bmc->client;
>+	if (client) {
>+		rc = client->ops->event(client);
>+	} else {
>+		u8 status;
>+
>+		status = kcs_bmc_read_status(kcs_bmc);
>+		if (status & KCS_BMC_STR_IBF) {
>+			/* Ack the event by reading the data */
>+			kcs_bmc_read_data(kcs_bmc);
>+			rc = KCS_BMC_EVENT_HANDLED;
>+		} else {
>+			rc = KCS_BMC_EVENT_NONE;
>+		}
>+	}
>+	spin_unlock(&kcs_bmc->lock);
>+
>+	return rc;
> }
> EXPORT_SYMBOL(kcs_bmc_handle_event);
>
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
>+int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
>+{
>+	int rc;
>+
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (kcs_bmc->client) {
>+		rc = -EBUSY;
>+	} else {
>+		kcs_bmc->client = client;
>+		rc = 0;
>+	}
>+	spin_unlock_irq(&kcs_bmc->lock);
>+
>+	return rc;
>+}
>+EXPORT_SYMBOL(kcs_bmc_enable_device);
>+
>+void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
>+{
>+	spin_lock_irq(&kcs_bmc->lock);
>+	if (client == kcs_bmc->client)
>+		kcs_bmc->client = NULL;

Is there any situation in which a non-matching client could be passed in
here?  Might we consider issuing a warning of some sort or returning an
error to the caller if so?

>+	spin_unlock_irq(&kcs_bmc->lock);
>+}
>+EXPORT_SYMBOL(kcs_bmc_disable_device);
>+
>+int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc)
> {
> 	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> }
> EXPORT_SYMBOL(kcs_bmc_add_device);
>
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
>+int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc)
> {
> 	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
> }
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index a1350e567723..3f266740c759 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -6,9 +6,7 @@
> #ifndef __KCS_BMC_H__
> #define __KCS_BMC_H__
>
>-#include <linux/miscdevice.h>
>-
>-#include "kcs_bmc_client.h"
>+#include <linux/list.h>
>
> #define KCS_BMC_EVENT_NONE	0
> #define KCS_BMC_EVENT_HANDLED	1
>@@ -17,53 +15,6 @@
> #define KCS_BMC_STR_IBF		BIT(1)
> #define KCS_BMC_STR_CMD_DAT	BIT(3)
>
>-/* Different phases of the KCS BMC module.
>- *  KCS_PHASE_IDLE:
>- *            BMC should not be expecting nor sending any data.
>- *  KCS_PHASE_WRITE_START:
>- *            BMC is receiving a WRITE_START command from system software.
>- *  KCS_PHASE_WRITE_DATA:
>- *            BMC is receiving a data byte from system software.
>- *  KCS_PHASE_WRITE_END_CMD:
>- *            BMC is waiting a last data byte from system software.
>- *  KCS_PHASE_WRITE_DONE:
>- *            BMC has received the whole request from system software.
>- *  KCS_PHASE_WAIT_READ:
>- *            BMC is waiting the response from the upper IPMI service.
>- *  KCS_PHASE_READ:
>- *            BMC is transferring the response to system software.
>- *  KCS_PHASE_ABORT_ERROR1:
>- *            BMC is waiting error status request from system software.
>- *  KCS_PHASE_ABORT_ERROR2:
>- *            BMC is waiting for idle status afer error from system software.
>- *  KCS_PHASE_ERROR:
>- *            BMC has detected a protocol violation at the interface level.
>- */
>-enum kcs_phases {
>-	KCS_PHASE_IDLE,
>-
>-	KCS_PHASE_WRITE_START,
>-	KCS_PHASE_WRITE_DATA,
>-	KCS_PHASE_WRITE_END_CMD,
>-	KCS_PHASE_WRITE_DONE,
>-
>-	KCS_PHASE_WAIT_READ,
>-	KCS_PHASE_READ,
>-
>-	KCS_PHASE_ABORT_ERROR1,
>-	KCS_PHASE_ABORT_ERROR2,
>-	KCS_PHASE_ERROR
>-};
>-
>-/* IPMI 2.0 - Table 9-4, KCS Interface Status Codes */
>-enum kcs_errors {
>-	KCS_NO_ERROR                = 0x00,
>-	KCS_ABORTED_BY_COMMAND      = 0x01,
>-	KCS_ILLEGAL_CONTROL_CODE    = 0x02,
>-	KCS_LENGTH_ERROR            = 0x06,
>-	KCS_UNSPECIFIED_ERROR       = 0xFF
>-};
>-
> /* IPMI 2.0 - 9.5, KCS Interface Registers
>  * @idr: Input Data Register
>  * @odr: Output Data Register
>@@ -76,36 +27,23 @@ struct kcs_ioreg {
> };
>
> struct kcs_bmc_device_ops;
>+struct kcs_bmc_client;
>+
>+struct kcs_bmc_device {
>+	struct list_head entry;
>
>-struct kcs_bmc {
> 	struct device *dev;
>-
>-	const struct kcs_bmc_device_ops *ops;
>-
>-	struct kcs_bmc_client client;
>-
>-	spinlock_t lock;
>-
> 	u32 channel;
>-	int running;
>
> 	struct kcs_ioreg ioreg;
>
>-	enum kcs_phases phase;
>-	enum kcs_errors error;
>+	const struct kcs_bmc_device_ops *ops;
>
>-	wait_queue_head_t queue;
>-	bool data_in_avail;
>-	int  data_in_idx;
>-	u8  *data_in;
>-
>-	int  data_out_idx;
>-	int  data_out_len;
>-	u8  *data_out;
>-
>-	struct mutex mutex;
>-	u8 *kbuffer;
>-
>-	struct miscdevice miscdev;
>+	spinlock_t lock;
>+	struct kcs_bmc_client *client;
> };
>+
>+/* Temporary exports while refactoring */
>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
> #endif /* __KCS_BMC_H__ */
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 1b313355b1c8..6f26e7366c0b 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -61,7 +61,7 @@
> #define LPC_STR4             0x11C
>
> struct aspeed_kcs_bmc {
>-	struct kcs_bmc kcs_bmc;
>+	struct kcs_bmc_device kcs_bmc;
>
> 	struct regmap *map;
> };
>@@ -71,12 +71,12 @@ struct aspeed_kcs_of_ops {
> 	int (*get_io_address)(struct platform_device *pdev);
> };
>
>-static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
>+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc_device *kcs_bmc)
> {
> 	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
> }
>
>-static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>+static u8 aspeed_kcs_inb(struct kcs_bmc_device *kcs_bmc, u32 reg)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	u32 val = 0;
>@@ -88,7 +88,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> 	return rc == 0 ? (u8) val : 0;
> }
>
>-static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>+static void aspeed_kcs_outb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 data)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	int rc;
>@@ -97,7 +97,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> 	WARN(rc != 0, "regmap_write() failed: %d\n", rc);
> }
>
>-static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
>+static void aspeed_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 val)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> 	int rc;
>@@ -119,7 +119,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
>  *     C. KCS4
>  *        D / C : CA4h / CA5h
>  */
>-static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>+static void aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u16 addr)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>
>@@ -153,7 +153,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> 	}
> }
>
>-static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>+static void aspeed_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enable)
> {
> 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>
>@@ -228,7 +228,7 @@ static const struct kcs_bmc_device_ops aspeed_kcs_ops = {
>
> static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> {
>-	struct kcs_bmc *kcs_bmc = arg;
>+	struct kcs_bmc_device *kcs_bmc = arg;
> 	int rc;
>
> 	rc = kcs_bmc_handle_event(kcs_bmc);
>@@ -238,7 +238,7 @@ static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> 	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> }
>
>-static int aspeed_kcs_config_irq(struct kcs_bmc *kcs_bmc,
>+static int aspeed_kcs_config_irq(struct kcs_bmc_device *kcs_bmc,
> 			struct platform_device *pdev)
> {
> 	struct device *dev = &pdev->dev;
>@@ -338,8 +338,8 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
> static int aspeed_kcs_probe(struct platform_device *pdev)
> {
> 	const struct aspeed_kcs_of_ops *ops;
>+	struct kcs_bmc_device *kcs_bmc;
> 	struct aspeed_kcs_bmc *priv;
>-	struct kcs_bmc *kcs_bmc;
> 	struct device_node *np;
> 	int rc, channel, addr;
>
>@@ -400,7 +400,7 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> static int aspeed_kcs_remove(struct platform_device *pdev)
> {
> 	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
>-	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>+	struct kcs_bmc_device *kcs_bmc = &priv->kcs_bmc;
>
> 	kcs_bmc_remove_device(kcs_bmc);
>
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>index fd852d8abe48..58c42e76483d 100644
>--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>@@ -8,13 +8,88 @@
> #include <linux/errno.h>
> #include <linux/io.h>
> #include <linux/ipmi_bmc.h>
>+#include <linux/list.h>
>+#include <linux/miscdevice.h>
> #include <linux/module.h>
>+#include <linux/mutex.h>
> #include <linux/platform_device.h>
> #include <linux/poll.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
>
>-#include "kcs_bmc.h"
>+#include "kcs_bmc_client.h"
>+
>+/* Different phases of the KCS BMC module.
>+ *  KCS_PHASE_IDLE:
>+ *            BMC should not be expecting nor sending any data.
>+ *  KCS_PHASE_WRITE_START:
>+ *            BMC is receiving a WRITE_START command from system software.
>+ *  KCS_PHASE_WRITE_DATA:
>+ *            BMC is receiving a data byte from system software.
>+ *  KCS_PHASE_WRITE_END_CMD:
>+ *            BMC is waiting a last data byte from system software.
>+ *  KCS_PHASE_WRITE_DONE:
>+ *            BMC has received the whole request from system software.
>+ *  KCS_PHASE_WAIT_READ:
>+ *            BMC is waiting the response from the upper IPMI service.
>+ *  KCS_PHASE_READ:
>+ *            BMC is transferring the response to system software.
>+ *  KCS_PHASE_ABORT_ERROR1:
>+ *            BMC is waiting error status request from system software.
>+ *  KCS_PHASE_ABORT_ERROR2:
>+ *            BMC is waiting for idle status afer error from system software.
>+ *  KCS_PHASE_ERROR:
>+ *            BMC has detected a protocol violation at the interface level.
>+ */
>+enum kcs_ipmi_phases {
>+	KCS_PHASE_IDLE,
>+
>+	KCS_PHASE_WRITE_START,
>+	KCS_PHASE_WRITE_DATA,
>+	KCS_PHASE_WRITE_END_CMD,
>+	KCS_PHASE_WRITE_DONE,
>+
>+	KCS_PHASE_WAIT_READ,
>+	KCS_PHASE_READ,
>+
>+	KCS_PHASE_ABORT_ERROR1,
>+	KCS_PHASE_ABORT_ERROR2,
>+	KCS_PHASE_ERROR
>+};
>+
>+/* IPMI 2.0 - Table 9-4, KCS Interface Status Codes */
>+enum kcs_ipmi_errors {
>+	KCS_NO_ERROR                = 0x00,
>+	KCS_ABORTED_BY_COMMAND      = 0x01,
>+	KCS_ILLEGAL_CONTROL_CODE    = 0x02,
>+	KCS_LENGTH_ERROR            = 0x06,
>+	KCS_UNSPECIFIED_ERROR       = 0xFF
>+};
>+
>+struct kcs_bmc_ipmi {
>+	struct list_head entry;
>+
>+	struct kcs_bmc_client client;
>+
>+	spinlock_t lock;
>+
>+	enum kcs_ipmi_phases phase;
>+	enum kcs_ipmi_errors error;
>+
>+	wait_queue_head_t queue;
>+	bool data_in_avail;
>+	int  data_in_idx;
>+	u8  *data_in;
>+
>+	int  data_out_idx;
>+	int  data_out_len;
>+	u8  *data_out;
>+
>+	struct mutex mutex;
>+	u8 *kbuffer;
>+
>+	struct miscdevice miscdev;
>+};
>
> #define DEVICE_NAME "ipmi-kcs"
>
>@@ -44,171 +119,169 @@ enum kcs_states {
> #define KCS_CMD_WRITE_END         0x62
> #define KCS_CMD_READ_BYTE         0x68
>
>-static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
>+static inline void set_state(struct kcs_bmc_ipmi *priv, u8 state)
> {
>-	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
>-					KCS_STATUS_STATE(state));
>+	kcs_bmc_update_status(priv->client.dev, KCS_STATUS_STATE_MASK, KCS_STATUS_STATE(state));
> }
>
>-static void kcs_bmc_ipmi_force_abort(struct kcs_bmc *kcs_bmc)
>+static void kcs_bmc_ipmi_force_abort(struct kcs_bmc_ipmi *priv)
> {
>-	set_state(kcs_bmc, ERROR_STATE);
>-	kcs_bmc_read_data(kcs_bmc);
>-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+	set_state(priv, ERROR_STATE);
>+	kcs_bmc_read_data(priv->client.dev);
>+	kcs_bmc_write_data(priv->client.dev, KCS_ZERO_DATA);
>
>-	kcs_bmc->phase = KCS_PHASE_ERROR;
>-	kcs_bmc->data_in_avail = false;
>-	kcs_bmc->data_in_idx = 0;
>+	priv->phase = KCS_PHASE_ERROR;
>+	priv->data_in_avail = false;
>+	priv->data_in_idx = 0;
> }
>
>-static void kcs_bmc_ipmi_handle_data(struct kcs_bmc *kcs_bmc)
>+static void kcs_bmc_ipmi_handle_data(struct kcs_bmc_ipmi *priv)
> {
>+	struct kcs_bmc_device *dev;
> 	u8 data;
>
>-	switch (kcs_bmc->phase) {
>+	dev = priv->client.dev;
>+
>+	switch (priv->phase) {
> 	case KCS_PHASE_WRITE_START:
>-		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
>+		priv->phase = KCS_PHASE_WRITE_DATA;
> 		fallthrough;
>
> 	case KCS_PHASE_WRITE_DATA:
>-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>-			set_state(kcs_bmc, WRITE_STATE);
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>-						kcs_bmc_read_data(kcs_bmc);
>+		if (priv->data_in_idx < KCS_MSG_BUFSIZ) {
>+			set_state(priv, WRITE_STATE);
>+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
>+			priv->data_in[priv->data_in_idx++] = kcs_bmc_read_data(dev);
> 		} else {
>-			kcs_bmc_ipmi_force_abort(kcs_bmc);
>-			kcs_bmc->error = KCS_LENGTH_ERROR;
>+			kcs_bmc_ipmi_force_abort(priv);
>+			priv->error = KCS_LENGTH_ERROR;
> 		}
> 		break;
>
> 	case KCS_PHASE_WRITE_END_CMD:
>-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>-			set_state(kcs_bmc, READ_STATE);
>-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>-						kcs_bmc_read_data(kcs_bmc);
>-			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
>-			kcs_bmc->data_in_avail = true;
>-			wake_up_interruptible(&kcs_bmc->queue);
>+		if (priv->data_in_idx < KCS_MSG_BUFSIZ) {
>+			set_state(priv, READ_STATE);
>+			priv->data_in[priv->data_in_idx++] = kcs_bmc_read_data(dev);
>+			priv->phase = KCS_PHASE_WRITE_DONE;
>+			priv->data_in_avail = true;
>+			wake_up_interruptible(&priv->queue);
> 		} else {
>-			kcs_bmc_ipmi_force_abort(kcs_bmc);
>-			kcs_bmc->error = KCS_LENGTH_ERROR;
>+			kcs_bmc_ipmi_force_abort(priv);
>+			priv->error = KCS_LENGTH_ERROR;
> 		}
> 		break;
>
> 	case KCS_PHASE_READ:
>-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
>-			set_state(kcs_bmc, IDLE_STATE);
>+		if (priv->data_out_idx == priv->data_out_len)
>+			set_state(priv, IDLE_STATE);
>
>-		data = kcs_bmc_read_data(kcs_bmc);
>+		data = kcs_bmc_read_data(dev);
> 		if (data != KCS_CMD_READ_BYTE) {
>-			set_state(kcs_bmc, ERROR_STATE);
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+			set_state(priv, ERROR_STATE);
>+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
> 			break;
> 		}
>
>-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
>-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-			kcs_bmc->phase = KCS_PHASE_IDLE;
>+		if (priv->data_out_idx == priv->data_out_len) {
>+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
>+			priv->phase = KCS_PHASE_IDLE;
> 			break;
> 		}
>
>-		kcs_bmc_write_data(kcs_bmc,
>-			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
>+		kcs_bmc_write_data(dev, priv->data_out[priv->data_out_idx++]);
> 		break;
>
> 	case KCS_PHASE_ABORT_ERROR1:
>-		set_state(kcs_bmc, READ_STATE);
>-		kcs_bmc_read_data(kcs_bmc);
>-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
>-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
>+		set_state(priv, READ_STATE);
>+		kcs_bmc_read_data(dev);
>+		kcs_bmc_write_data(dev, priv->error);
>+		priv->phase = KCS_PHASE_ABORT_ERROR2;
> 		break;
>
> 	case KCS_PHASE_ABORT_ERROR2:
>-		set_state(kcs_bmc, IDLE_STATE);
>-		kcs_bmc_read_data(kcs_bmc);
>-		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>-		kcs_bmc->phase = KCS_PHASE_IDLE;
>+		set_state(priv, IDLE_STATE);
>+		kcs_bmc_read_data(dev);
>+		kcs_bmc_write_data(dev, KCS_ZERO_DATA);
>+		priv->phase = KCS_PHASE_IDLE;
> 		break;
>
> 	default:
>-		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		kcs_bmc_ipmi_force_abort(priv);
> 		break;
> 	}
> }
>
>-static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc *kcs_bmc)
>+static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc_ipmi *priv)
> {
> 	u8 cmd;
>
>-	set_state(kcs_bmc, WRITE_STATE);
>-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>+	set_state(priv, WRITE_STATE);
>+	kcs_bmc_write_data(priv->client.dev, KCS_ZERO_DATA);
>
>-	cmd = kcs_bmc_read_data(kcs_bmc);
>+	cmd = kcs_bmc_read_data(priv->client.dev);
> 	switch (cmd) {
> 	case KCS_CMD_WRITE_START:
>-		kcs_bmc->phase = KCS_PHASE_WRITE_START;
>-		kcs_bmc->error = KCS_NO_ERROR;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>+		priv->phase = KCS_PHASE_WRITE_START;
>+		priv->error = KCS_NO_ERROR;
>+		priv->data_in_avail = false;
>+		priv->data_in_idx = 0;
> 		break;
>
> 	case KCS_CMD_WRITE_END:
>-		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
>-			kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		if (priv->phase != KCS_PHASE_WRITE_DATA) {
>+			kcs_bmc_ipmi_force_abort(priv);
> 			break;
> 		}
>
>-		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
>+		priv->phase = KCS_PHASE_WRITE_END_CMD;
> 		break;
>
> 	case KCS_CMD_GET_STATUS_ABORT:
>-		if (kcs_bmc->error == KCS_NO_ERROR)
>-			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
>+		if (priv->error == KCS_NO_ERROR)
>+			priv->error = KCS_ABORTED_BY_COMMAND;
>
>-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>+		priv->phase = KCS_PHASE_ABORT_ERROR1;
>+		priv->data_in_avail = false;
>+		priv->data_in_idx = 0;
> 		break;
>
> 	default:
>-		kcs_bmc_ipmi_force_abort(kcs_bmc);
>-		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
>+		kcs_bmc_ipmi_force_abort(priv);
>+		priv->error = KCS_ILLEGAL_CONTROL_CODE;
> 		break;
> 	}
> }
>
>-static inline struct kcs_bmc *client_to_kcs_bmc(struct kcs_bmc_client *client)
>+static inline struct kcs_bmc_ipmi *client_to_kcs_bmc_ipmi(struct kcs_bmc_client *client)
> {
>-	return container_of(client, struct kcs_bmc, client);
>+	return container_of(client, struct kcs_bmc_ipmi, client);
> }
>
> static int kcs_bmc_ipmi_event(struct kcs_bmc_client *client)
> {
>-	struct kcs_bmc *kcs_bmc;
>-	unsigned long flags;
>+	struct kcs_bmc_ipmi *priv;
> 	u8 status;
> 	int ret;
>
>-	kcs_bmc = client_to_kcs_bmc(client);
>+	priv = client_to_kcs_bmc_ipmi(client);
>+	if (!priv)
>+		return KCS_BMC_EVENT_NONE;
>
>-	spin_lock_irqsave(&kcs_bmc->lock, flags);
>+	spin_lock(&priv->lock);
>
>-	status = kcs_bmc_read_status(kcs_bmc);
>+	status = kcs_bmc_read_status(client->dev);
> 	if (status & KCS_STATUS_IBF) {
>-		if (!kcs_bmc->running)
>-			kcs_bmc_ipmi_force_abort(kcs_bmc);
>-		else if (status & KCS_STATUS_CMD_DAT)
>-			kcs_bmc_ipmi_handle_cmd(kcs_bmc);
>+		if (status & KCS_STATUS_CMD_DAT)
>+			kcs_bmc_ipmi_handle_cmd(priv);
> 		else
>-			kcs_bmc_ipmi_handle_data(kcs_bmc);
>+			kcs_bmc_ipmi_handle_data(priv);
>
> 		ret = KCS_BMC_EVENT_HANDLED;
> 	} else {
> 		ret = KCS_BMC_EVENT_NONE;
> 	}
>
>-	spin_unlock_irqrestore(&kcs_bmc->lock, flags);
>+	spin_unlock(&priv->lock);
>
> 	return ret;
> }
>@@ -217,37 +290,29 @@ static const struct kcs_bmc_client_ops kcs_bmc_ipmi_client_ops = {
> 	.event = kcs_bmc_ipmi_event,
> };
>
>-static inline struct kcs_bmc *file_to_kcs_bmc(struct file *filp)
>+static inline struct kcs_bmc_ipmi *to_kcs_bmc(struct file *filp)
> {
>-	return container_of(filp->private_data, struct kcs_bmc, miscdev);
>+	return container_of(filp->private_data, struct kcs_bmc_ipmi, miscdev);
> }
>
> static int kcs_bmc_ipmi_open(struct inode *inode, struct file *filp)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>-	int ret = 0;
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (!kcs_bmc->running)
>-		kcs_bmc->running = 1;
>-	else
>-		ret = -EBUSY;
>-	spin_unlock_irq(&kcs_bmc->lock);
>-
>-	return ret;
>+	return kcs_bmc_enable_device(priv->client.dev, &priv->client);
> }
>
> static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> 	__poll_t mask = 0;
>
>-	poll_wait(filp, &kcs_bmc->queue, wait);
>+	poll_wait(filp, &priv->queue, wait);
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->data_in_avail)
>+	spin_lock_irq(&priv->lock);
>+	if (priv->data_in_avail)
> 		mask |= EPOLLIN;
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_unlock_irq(&priv->lock);
>
> 	return mask;
> }
>@@ -255,24 +320,24 @@ static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> 			    size_t count, loff_t *ppos)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> 	bool data_avail;
> 	size_t data_len;
> 	ssize_t ret;
>
> 	if (!(filp->f_flags & O_NONBLOCK))
>-		wait_event_interruptible(kcs_bmc->queue,
>-					 kcs_bmc->data_in_avail);
>+		wait_event_interruptible(priv->queue,
>+					 priv->data_in_avail);
>
>-	mutex_lock(&kcs_bmc->mutex);
>+	mutex_lock(&priv->mutex);
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	data_avail = kcs_bmc->data_in_avail;
>+	spin_lock_irq(&priv->lock);
>+	data_avail = priv->data_in_avail;
> 	if (data_avail) {
>-		data_len = kcs_bmc->data_in_idx;
>-		memcpy(kcs_bmc->kbuffer, kcs_bmc->data_in, data_len);
>+		data_len = priv->data_in_idx;
>+		memcpy(priv->kbuffer, priv->data_in, data_len);
> 	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_unlock_irq(&priv->lock);
>
> 	if (!data_avail) {
> 		ret = -EAGAIN;
>@@ -281,35 +346,35 @@ static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
>
> 	if (count < data_len) {
> 		pr_err("channel=%u with too large data : %zu\n",
>-			kcs_bmc->channel, data_len);
>+			priv->client.dev->channel, data_len);
>
>-		spin_lock_irq(&kcs_bmc->lock);
>-		kcs_bmc_ipmi_force_abort(kcs_bmc);
>-		spin_unlock_irq(&kcs_bmc->lock);
>+		spin_lock_irq(&priv->lock);
>+		kcs_bmc_ipmi_force_abort(priv);
>+		spin_unlock_irq(&priv->lock);
>
> 		ret = -EOVERFLOW;
> 		goto out_unlock;
> 	}
>
>-	if (copy_to_user(buf, kcs_bmc->kbuffer, data_len)) {
>+	if (copy_to_user(buf, priv->kbuffer, data_len)) {
> 		ret = -EFAULT;
> 		goto out_unlock;
> 	}
>
> 	ret = data_len;
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->phase == KCS_PHASE_WRITE_DONE) {
>-		kcs_bmc->phase = KCS_PHASE_WAIT_READ;
>-		kcs_bmc->data_in_avail = false;
>-		kcs_bmc->data_in_idx = 0;
>+	spin_lock_irq(&priv->lock);
>+	if (priv->phase == KCS_PHASE_WRITE_DONE) {
>+		priv->phase = KCS_PHASE_WAIT_READ;
>+		priv->data_in_avail = false;
>+		priv->data_in_idx = 0;
> 	} else {
> 		ret = -EAGAIN;
> 	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_unlock_irq(&priv->lock);
>
> out_unlock:
>-	mutex_unlock(&kcs_bmc->mutex);
>+	mutex_unlock(&priv->mutex);
>
> 	return ret;
> }
>@@ -317,35 +382,35 @@ static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> 			     size_t count, loff_t *ppos)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> 	ssize_t ret;
>
> 	/* a minimum response size '3' : netfn + cmd + ccode */
> 	if (count < 3 || count > KCS_MSG_BUFSIZ)
> 		return -EINVAL;
>
>-	mutex_lock(&kcs_bmc->mutex);
>+	mutex_lock(&priv->mutex);
>
>-	if (copy_from_user(kcs_bmc->kbuffer, buf, count)) {
>+	if (copy_from_user(priv->kbuffer, buf, count)) {
> 		ret = -EFAULT;
> 		goto out_unlock;
> 	}
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->phase == KCS_PHASE_WAIT_READ) {
>-		kcs_bmc->phase = KCS_PHASE_READ;
>-		kcs_bmc->data_out_idx = 1;
>-		kcs_bmc->data_out_len = count;
>-		memcpy(kcs_bmc->data_out, kcs_bmc->kbuffer, count);
>-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->data_out[0]);
>+	spin_lock_irq(&priv->lock);
>+	if (priv->phase == KCS_PHASE_WAIT_READ) {
>+		priv->phase = KCS_PHASE_READ;
>+		priv->data_out_idx = 1;
>+		priv->data_out_len = count;
>+		memcpy(priv->data_out, priv->kbuffer, count);
>+		kcs_bmc_write_data(priv->client.dev, priv->data_out[0]);
> 		ret = count;
> 	} else {
> 		ret = -EINVAL;
> 	}
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_unlock_irq(&priv->lock);
>
> out_unlock:
>-	mutex_unlock(&kcs_bmc->mutex);
>+	mutex_unlock(&priv->mutex);
>
> 	return ret;
> }
>@@ -353,22 +418,22 @@ static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
> 			  unsigned long arg)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> 	long ret = 0;
>
>-	spin_lock_irq(&kcs_bmc->lock);
>+	spin_lock_irq(&priv->lock);
>
> 	switch (cmd) {
> 	case IPMI_BMC_IOCTL_SET_SMS_ATN:
>-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
>+		kcs_bmc_update_status(priv->client.dev, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
> 		break;
>
> 	case IPMI_BMC_IOCTL_CLEAR_SMS_ATN:
>-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, 0);
>+		kcs_bmc_update_status(priv->client.dev, KCS_STATUS_SMS_ATN, 0);
> 		break;
>
> 	case IPMI_BMC_IOCTL_FORCE_ABORT:
>-		kcs_bmc_ipmi_force_abort(kcs_bmc);
>+		kcs_bmc_ipmi_force_abort(priv);
> 		break;
>
> 	default:
>@@ -376,19 +441,17 @@ static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
> 		break;
> 	}
>
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_unlock_irq(&priv->lock);
>
> 	return ret;
> }
>
> static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
> {
>-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
>+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	kcs_bmc->running = 0;
>-	kcs_bmc_ipmi_force_abort(kcs_bmc);
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	kcs_bmc_ipmi_force_abort(priv);
>+	kcs_bmc_disable_device(priv->client.dev, &priv->client);
>
> 	return 0;
> }
>@@ -403,56 +466,78 @@ static const struct file_operations kcs_bmc_ipmi_fops = {
> 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
> };
>
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
>+static DEFINE_SPINLOCK(kcs_bmc_ipmi_instances_lock);
>+static LIST_HEAD(kcs_bmc_ipmi_instances);
>+
>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
> {
>+	struct kcs_bmc_ipmi *priv;
> 	int rc;
>
>-	spin_lock_init(&kcs_bmc->lock);
>-	mutex_init(&kcs_bmc->mutex);
>-	init_waitqueue_head(&kcs_bmc->queue);
>-
>-	kcs_bmc->client.dev = kcs_bmc;
>-	kcs_bmc->client.ops = &kcs_bmc_ipmi_client_ops;
>-	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>-
>-	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
>-	kcs_bmc->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u",
>-					       DEVICE_NAME, kcs_bmc->channel);
>-	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
>-	    !kcs_bmc->miscdev.name)
>+	priv = devm_kzalloc(kcs_bmc->dev, sizeof(*priv), GFP_KERNEL);
>+	if (!priv)
> 		return -ENOMEM;
>
>-	kcs_bmc->miscdev.fops = &kcs_bmc_ipmi_fops;
>+	spin_lock_init(&priv->lock);
>+	mutex_init(&priv->mutex);
>
>-	rc = misc_register(&kcs_bmc->miscdev);
>+	init_waitqueue_head(&priv->queue);
>+
>+	priv->client.dev = kcs_bmc;
>+	priv->client.ops = &kcs_bmc_ipmi_client_ops;
>+	priv->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	priv->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+	priv->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>+
>+	priv->miscdev.minor = MISC_DYNAMIC_MINOR;
>+	priv->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u", DEVICE_NAME,
>+					   kcs_bmc->channel);
>+	if (!priv->data_in || !priv->data_out || !priv->kbuffer || !priv->miscdev.name)
>+		return -EINVAL;
>+
>+	priv->miscdev.fops = &kcs_bmc_ipmi_fops;
>+
>+	rc = misc_register(&priv->miscdev);
> 	if (rc) {
> 		dev_err(kcs_bmc->dev, "Unable to register device: %d\n", rc);
> 		return rc;
> 	}
>
>+	spin_lock_irq(&kcs_bmc_ipmi_instances_lock);
>+	list_add(&priv->entry, &kcs_bmc_ipmi_instances);
>+	spin_unlock_irq(&kcs_bmc_ipmi_instances_lock);
>+
> 	dev_info(kcs_bmc->dev, "Initialised IPMI client for channel %d", kcs_bmc->channel);
>
> 	return 0;
> }
> EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
>
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc)
>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
> {
>-	misc_deregister(&kcs_bmc->miscdev);
>+	struct kcs_bmc_ipmi *priv = NULL, *pos;
>
>-	spin_lock_irq(&kcs_bmc->lock);
>-	kcs_bmc->running = 0;
>-	kcs_bmc_ipmi_force_abort(kcs_bmc);
>-	spin_unlock_irq(&kcs_bmc->lock);
>+	spin_lock_irq(&kcs_bmc_ipmi_instances_lock);
>+	list_for_each_entry(pos, &kcs_bmc_ipmi_instances, entry) {
>+		if (pos->client.dev == kcs_bmc) {
>+			priv = pos;
>+			list_del(&pos->entry);
>+			break;
>+		}
>+	}
>+	spin_unlock_irq(&kcs_bmc_ipmi_instances_lock);
>
>-	devm_kfree(kcs_bmc->dev, kcs_bmc->kbuffer);
>-	devm_kfree(kcs_bmc->dev, kcs_bmc->data_out);
>-	devm_kfree(kcs_bmc->dev, kcs_bmc->data_in);
>-	devm_kfree(kcs_bmc->dev, kcs_bmc);
>+	if (!priv)
>+		return 0;

Would -ENOENT or something be appropriate here if the thing we're trying
to detach isn't found?

>+
>+	misc_deregister(&priv->miscdev);
>+	kcs_bmc_disable_device(priv->client.dev, &priv->client);
>+	devm_kfree(kcs_bmc->dev, priv->kbuffer);
>+	devm_kfree(kcs_bmc->dev, priv->data_out);
>+	devm_kfree(kcs_bmc->dev, priv->data_in);
>+	devm_kfree(kcs_bmc->dev, priv);
>
> 	return 0;
> }
>@@ -460,4 +545,5 @@ EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>+MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
> MODULE_DESCRIPTION("KCS BMC to handle the IPMI request from system software");
>diff --git a/drivers/char/ipmi/kcs_bmc_client.h b/drivers/char/ipmi/kcs_bmc_client.h
>index 140631d157d8..2dd710f4b4aa 100644
>--- a/drivers/char/ipmi/kcs_bmc_client.h
>+++ b/drivers/char/ipmi/kcs_bmc_client.h
>@@ -8,22 +8,24 @@
> #include <linux/notifier.h>
> #include <stdbool.h>
>
>-struct kcs_bmc;
>-struct kcs_bmc_client_ops;
>-
>-struct kcs_bmc_client {
>-	const struct kcs_bmc_client_ops *ops;
>-
>-	struct kcs_bmc *dev;
>-};
>+#include "kcs_bmc.h"
>
> struct kcs_bmc_client_ops {
> 	int (*event)(struct kcs_bmc_client *client);
> };
>
>-u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>-void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>-u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc);
>-void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data);
>-void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val);
>+struct kcs_bmc_client {
>+	const struct kcs_bmc_client_ops *ops;
>+
>+	struct kcs_bmc_device *dev;
>+};
>+
>+int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
>+void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
>+
>+u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc);
>+void kcs_bmc_write_data(struct kcs_bmc_device *kcs_bmc, u8 data);
>+u8 kcs_bmc_read_status(struct kcs_bmc_device *kcs_bmc);
>+void kcs_bmc_write_status(struct kcs_bmc_device *kcs_bmc, u8 data);
>+void kcs_bmc_update_status(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 val);
> #endif
>diff --git a/drivers/char/ipmi/kcs_bmc_device.h b/drivers/char/ipmi/kcs_bmc_device.h
>index 33462174516d..57b7174b2bac 100644
>--- a/drivers/char/ipmi/kcs_bmc_device.h
>+++ b/drivers/char/ipmi/kcs_bmc_device.h
>@@ -7,13 +7,13 @@
> #include "kcs_bmc.h"
>
> struct kcs_bmc_device_ops {
>-	u8 (*io_inputb)(struct kcs_bmc *kcs_bmc, u32 reg);
>-	void (*io_outputb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 b);
>-	void (*io_updateb)(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 b);
>+	u8 (*io_inputb)(struct kcs_bmc_device *kcs_bmc, u32 reg);
>+	void (*io_outputb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 b);
>+	void (*io_updateb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 b);
> };
>
>-int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>-int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>+int kcs_bmc_handle_event(struct kcs_bmc_device *kcs_bmc);
>+int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc);
>+int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc);
>
> #endif
>diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>index 1d21697fc585..dce93ec895fc 100644
>--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>@@ -65,7 +65,7 @@ struct npcm7xx_kcs_reg {
> };
>
> struct npcm7xx_kcs_bmc {
>-	struct kcs_bmc kcs_bmc;
>+	struct kcs_bmc_device kcs_bmc;
>
> 	struct regmap *map;
>
>@@ -78,12 +78,12 @@ static const struct npcm7xx_kcs_reg npcm7xx_kcs_reg_tbl[KCS_CHANNEL_MAX] = {
> 	{ .sts = KCS3ST, .dob = KCS3DO, .dib = KCS3DI, .ctl = KCS3CTL, .ie = KCS3IE },
> };
>
>-static inline struct npcm7xx_kcs_bmc *to_npcm7xx_kcs_bmc(struct kcs_bmc *kcs_bmc)
>+static inline struct npcm7xx_kcs_bmc *to_npcm7xx_kcs_bmc(struct kcs_bmc_device *kcs_bmc)
> {
> 	return container_of(kcs_bmc, struct npcm7xx_kcs_bmc, kcs_bmc);
> }
>
>-static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>+static u8 npcm7xx_kcs_inb(struct kcs_bmc_device *kcs_bmc, u32 reg)
> {
> 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	u32 val = 0;
>@@ -95,7 +95,7 @@ static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> 	return rc == 0 ? (u8)val : 0;
> }
>
>-static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>+static void npcm7xx_kcs_outb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 data)
> {
> 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	int rc;
>@@ -104,7 +104,7 @@ static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> 	WARN(rc != 0, "regmap_write() failed: %d\n", rc);
> }
>
>-static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 data)
>+static void npcm7xx_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 data)
> {
> 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> 	int rc;
>@@ -113,7 +113,7 @@ static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 da
> 	WARN(rc != 0, "regmap_update_bits() failed: %d\n", rc);
> }
>
>-static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>+static void npcm7xx_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enable)
> {
> 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>
>@@ -126,7 +126,7 @@ static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>
> static irqreturn_t npcm7xx_kcs_irq(int irq, void *arg)
> {
>-	struct kcs_bmc *kcs_bmc = arg;
>+	struct kcs_bmc_device *kcs_bmc = arg;
> 	int rc;
>
> 	rc = kcs_bmc_handle_event(kcs_bmc);
>@@ -136,7 +136,7 @@ static irqreturn_t npcm7xx_kcs_irq(int irq, void *arg)
> 	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> }
>
>-static int npcm7xx_kcs_config_irq(struct kcs_bmc *kcs_bmc,
>+static int npcm7xx_kcs_config_irq(struct kcs_bmc_device *kcs_bmc,
> 				  struct platform_device *pdev)
> {
> 	struct device *dev = &pdev->dev;
>@@ -160,7 +160,7 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> {
> 	struct device *dev = &pdev->dev;
> 	struct npcm7xx_kcs_bmc *priv;
>-	struct kcs_bmc *kcs_bmc;
>+	struct kcs_bmc_device *kcs_bmc;
> 	u32 chan;
> 	int rc;
>
>@@ -207,7 +207,7 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> static int npcm7xx_kcs_remove(struct platform_device *pdev)
> {
> 	struct npcm7xx_kcs_bmc *priv = platform_get_drvdata(pdev);
>-	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>+	struct kcs_bmc_device *kcs_bmc = &priv->kcs_bmc;
>
> 	kcs_bmc_remove_device(kcs_bmc);
>
>-- 
>2.27.0
>

From lkp at intel.com  Fri Apr  9 05:13:20 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:13:20 +0800
Subject: [soc:drivers/optee-fix] BUILD SUCCESS
 7ccdcaace80810175bd20b2ece856b42edd43991
Message-ID: <606fd460.X0K6103g487IHL67%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/optee-fix
branch HEAD: 7ccdcaace80810175bd20b2ece856b42edd43991  tee: optee: fix build error caused by recent optee tracepoints feature

elapsed time: 722m

configs tested: 159
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                         rt305x_defconfig
um                                allnoconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
m68k                        m5407c3_defconfig
arm                            lart_defconfig
arm                           spitz_defconfig
arm                         palmz72_defconfig
arm                         lpc32xx_defconfig
ia64                             alldefconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      ppc6xx_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
xtensa                  cadence_csp_defconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
arc                     nsimosci_hs_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                  storcenter_defconfig
arm                         s5pv210_defconfig
ia64                         bigsur_defconfig
arm                         orion5x_defconfig
m68k                        stmark2_defconfig
mips                     loongson1b_defconfig
mips                  decstation_64_defconfig
powerpc                      ppc64e_defconfig
mips                          rb532_defconfig
powerpc                 mpc834x_mds_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
parisc                           allyesconfig
um                           x86_64_defconfig
arc                    vdk_hs38_smp_defconfig
arm                           u8500_defconfig
arm                          ixp4xx_defconfig
sh                  sh7785lcr_32bit_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm64                            alldefconfig
s390                          debug_defconfig
arc                        vdk_hs38_defconfig
sh                           se7751_defconfig
mips                      pic32mzda_defconfig
arm                   milbeaut_m10v_defconfig
arm                           h5000_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                  colibri_pxa270_defconfig
mips                    maltaup_xpa_defconfig
powerpc                     mpc83xx_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
arm                         shannon_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                         at91_dt_defconfig
arm                        realview_defconfig
x86_64                           alldefconfig
arm                        mvebu_v7_defconfig
arm                          collie_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:13:10 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:13:10 +0800
Subject: [soc:mediatek/defconfig] BUILD SUCCESS
 f6dc45610879f88b1c37c07c8342f6764bcd55f4
Message-ID: <606fd456.+kIu7wRNin/11AoL%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/defconfig
branch HEAD: f6dc45610879f88b1c37c07c8342f6764bcd55f4  arm64: defconfig: Enable options to support panel display for Mediatek Chromebooks

elapsed time: 12592m

configs tested: 162
configs skipped: 141

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      ppc6xx_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
xtensa                  cadence_csp_defconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
arc                     nsimosci_hs_defconfig
powerpc                       ebony_defconfig
arm                           stm32_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
powerpc                      ppc64e_defconfig
mips                          rb532_defconfig
powerpc                 mpc834x_mds_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
parisc                           allyesconfig
riscv                               defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
sh                           se7722_defconfig
mips                  maltasmvp_eva_defconfig
arm                         s5pv210_defconfig
sh                             shx3_defconfig
sh                   rts7751r2dplus_defconfig
arm                            lart_defconfig
arm64                            alldefconfig
arm                    vt8500_v6_v7_defconfig
mips                        qi_lb60_defconfig
riscv                          rv32_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                  colibri_pxa270_defconfig
mips                           ip22_defconfig
mips                    maltaup_xpa_defconfig
powerpc                     mpc83xx_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
arm                         shannon_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                         at91_dt_defconfig
mips                  decstation_64_defconfig
alpha                            allyesconfig
arm                        realview_defconfig
x86_64                           alldefconfig
arm                        mvebu_v7_defconfig
sh                  sh7785lcr_32bit_defconfig
arm                          collie_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:12:59 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:12:59 +0800
Subject: [soc:drivers/memory-tegra] BUILD SUCCESS
 d8d5cbc619e86b8f2167ae40d029a9d07e97b303
Message-ID: <606fd44b.G4PnGa9kq2I+0GQk%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/memory-tegra
branch HEAD: d8d5cbc619e86b8f2167ae40d029a9d07e97b303  dt-bindings: memory: tegra20: mc: Convert to schema

elapsed time: 10648m

configs tested: 326
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                     powernv_defconfig
mips                      malta_kvm_defconfig
m68k                        mvme16x_defconfig
powerpc                      ppc40x_defconfig
mips                         tb0226_defconfig
mips                         rt305x_defconfig
um                                allnoconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
xtensa                generic_kc705_defconfig
arm                      footbridge_defconfig
arm                        trizeps4_defconfig
arm                       aspeed_g4_defconfig
riscv                    nommu_k210_defconfig
m68k                          amiga_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
mips                          rm200_defconfig
parisc                generic-64bit_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
powerpc                   bluestone_defconfig
sh                          rsk7264_defconfig
powerpc                      ppc64e_defconfig
powerpc                     tqm8548_defconfig
sh                           se7619_defconfig
mips                      fuloong2e_defconfig
powerpc                     sequoia_defconfig
arm                          ixp4xx_defconfig
arm                          pxa910_defconfig
arm                          lpd270_defconfig
powerpc                      tqm8xx_defconfig
arm                         hackkit_defconfig
arm                        mvebu_v5_defconfig
mips                          rb532_defconfig
m68k                            mac_defconfig
powerpc                      mgcoge_defconfig
powerpc                 linkstation_defconfig
sh                            migor_defconfig
mips                       lemote2f_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                             allmodconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
arm                       omap2plus_defconfig
arm                        spear6xx_defconfig
arm                          pcm027_defconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      ppc6xx_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
xtensa                  cadence_csp_defconfig
powerpc                  mpc866_ads_defconfig
powerpc               mpc834x_itxgp_defconfig
m68k                          atari_defconfig
x86_64                           alldefconfig
arm                          exynos_defconfig
mips                        nlm_xlp_defconfig
s390                                defconfig
powerpc                      makalu_defconfig
openrisc                    or1ksim_defconfig
arm                         shannon_defconfig
xtensa                  audio_kc705_defconfig
powerpc                      acadia_defconfig
powerpc                     mpc512x_defconfig
sh                   rts7751r2dplus_defconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
arc                     nsimosci_hs_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
mips                           ip27_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
mips                          malta_defconfig
arm                        magician_defconfig
arm                       spear13xx_defconfig
powerpc                     ksi8560_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                       h8s-sim_defconfig
arm                          badge4_defconfig
mips                      loongson3_defconfig
arm                        shmobile_defconfig
m68k                         apollo_defconfig
xtensa                          iss_defconfig
sh                          rsk7201_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
parisc                           allyesconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
arm                           u8500_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                    amigaone_defconfig
sh                           se7724_defconfig
powerpc                         wii_defconfig
arm                       multi_v4t_defconfig
sh                        sh7785lcr_defconfig
mips                        qi_lb60_defconfig
arm                           tegra_defconfig
powerpc                       maple_defconfig
powerpc                     rainier_defconfig
sh                        dreamcast_defconfig
mips                            e55_defconfig
riscv                               defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
arm                          pxa3xx_defconfig
um                           x86_64_defconfig
powerpc                           allnoconfig
arm                             rpc_defconfig
sparc64                             defconfig
arm                            zeus_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                        edosk7760_defconfig
sh                         ecovec24_defconfig
mips                      maltaaprp_defconfig
arm                            lart_defconfig
arm64                            alldefconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
mips                           gcw0_defconfig
mips                        omega2p_defconfig
arm                         palmz72_defconfig
arm                          pxa168_defconfig
sh                           se7780_defconfig
arc                        vdk_hs38_defconfig
sh                           se7751_defconfig
mips                      pic32mzda_defconfig
arm                   milbeaut_m10v_defconfig
arc                 nsimosci_hs_smp_defconfig
sh                ecovec24-romimage_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
arm                          imote2_defconfig
m68k                             alldefconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
arm                  colibri_pxa270_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
ia64                             allyesconfig
powerpc                 mpc837x_rdb_defconfig
arm                            xcep_defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
mips                    maltaup_xpa_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
sh                           se7750_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
powerpc                 xes_mpc85xx_defconfig
arm                         at91_dt_defconfig
mips                  decstation_64_defconfig
um                               allmodconfig
arm                      jornada720_defconfig
arm                        realview_defconfig
arm                        mvebu_v7_defconfig
arm                          collie_defconfig
sh                             sh03_defconfig
sh                           se7712_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a004-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
x86_64               randconfig-a004-20210402
x86_64               randconfig-a005-20210402
x86_64               randconfig-a003-20210402
x86_64               randconfig-a001-20210402
x86_64               randconfig-a002-20210402
x86_64               randconfig-a006-20210402
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
x86_64               randconfig-a014-20210401
x86_64               randconfig-a015-20210401
x86_64               randconfig-a011-20210401
x86_64               randconfig-a013-20210401
x86_64               randconfig-a012-20210401
x86_64               randconfig-a016-20210401
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a014-20210402
i386                 randconfig-a016-20210402
i386                 randconfig-a011-20210402
i386                 randconfig-a012-20210402
i386                 randconfig-a013-20210402
i386                 randconfig-a015-20210402
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:13:02 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:13:02 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 0a8e73301d2b071a9e4ceb1901773502d50b897a
Message-ID: <606fd44e.O7NP3ADEOE9MHuh9%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: 0a8e73301d2b071a9e4ceb1901773502d50b897a  Merge tag 'memory-controller-drv-tegra-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

elapsed time: 722m

configs tested: 107
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                         axm55xx_defconfig
m68k                            q40_defconfig
m68k                        m5307c3_defconfig
ia64                          tiger_defconfig
mips                       bmips_be_defconfig
arm                          pxa168_defconfig
s390                          debug_defconfig
arm                          pxa3xx_defconfig
um                           x86_64_defconfig
arc                        vdk_hs38_defconfig
sh                           se7751_defconfig
mips                      pic32mzda_defconfig
arm                   milbeaut_m10v_defconfig
arm                           h5000_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                  colibri_pxa270_defconfig
mips                           ip22_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
arm                        realview_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:12:51 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:12:51 +0800
Subject: [soc:socfpga/drivers-2] BUILD SUCCESS WITH WARNING
 38ad957b04c5c2c9effc6336365187dae1301051
Message-ID: <606fd443.fhMx98kk6kZICn9z%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git socfpga/drivers-2
branch HEAD: 38ad957b04c5c2c9effc6336365187dae1301051  firmware: stratix10-svc: build only on 64-bit ARM

Warning reports:

https://lore.kernel.org/linux-arm-kernel/202104090637.L7vdvTaA-lkp at intel.com

Warning in current branch:

drivers/clk/socfpga/clk-gate.c:102:7: warning: cast to smaller integer type 'int' from 'void *' [-Wvoid-pointer-to-int-cast]

Warning ids grouped by kconfigs:

clang_recent_errors
`-- arm64-randconfig-r016-20210408
    `-- drivers-clk-socfpga-clk-gate.c:warning:cast-to-smaller-integer-type-int-from-void

elapsed time: 722m

configs tested: 159
configs skipped: 2

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                         rt305x_defconfig
um                                allnoconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
m68k                        m5407c3_defconfig
arm                            lart_defconfig
arm                           spitz_defconfig
arm                         palmz72_defconfig
arm                         lpc32xx_defconfig
ia64                             alldefconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      ppc6xx_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
xtensa                  cadence_csp_defconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
arc                     nsimosci_hs_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                  storcenter_defconfig
arm                         s5pv210_defconfig
ia64                         bigsur_defconfig
arm                         orion5x_defconfig
m68k                        stmark2_defconfig
mips                     loongson1b_defconfig
mips                  decstation_64_defconfig
powerpc                      ppc64e_defconfig
mips                          rb532_defconfig
powerpc                 mpc834x_mds_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
parisc                           allyesconfig
um                           x86_64_defconfig
arc                    vdk_hs38_smp_defconfig
arm                           u8500_defconfig
arm                          ixp4xx_defconfig
sh                  sh7785lcr_32bit_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm64                            alldefconfig
s390                          debug_defconfig
arc                        vdk_hs38_defconfig
sh                           se7751_defconfig
mips                      pic32mzda_defconfig
arm                   milbeaut_m10v_defconfig
arm                           h5000_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                  colibri_pxa270_defconfig
mips                    maltaup_xpa_defconfig
powerpc                     mpc83xx_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
arm                         shannon_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                         at91_dt_defconfig
arm                        realview_defconfig
x86_64                           alldefconfig
arm                        mvebu_v7_defconfig
arm                          collie_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:13:16 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:13:16 +0800
Subject: [soc:mediatek/drivers] BUILD SUCCESS
 060f7875bd230df1a8f83a988faaee09d693e465
Message-ID: <606fd45c.MStRjO4/PcNE133J%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/drivers
branch HEAD: 060f7875bd230df1a8f83a988faaee09d693e465  soc: mediatek: mmsys: Add support for MT8167 SoC

elapsed time: 3817m

configs tested: 291
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
mips                      pic32mzda_defconfig
mips                         mpc30x_defconfig
mips                         cobalt_defconfig
sh                          rsk7201_defconfig
arm                        clps711x_defconfig
sh                         microdev_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
sh                           se7619_defconfig
mips                         rt305x_defconfig
um                                allnoconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
mips                      fuloong2e_defconfig
arm                          badge4_defconfig
arm                  colibri_pxa270_defconfig
mips                      maltaaprp_defconfig
ia64                                defconfig
sparc                            alldefconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
powerpc                    amigaone_defconfig
powerpc                        fsp2_defconfig
powerpc                      ppc6xx_defconfig
sh                        apsh4ad0a_defconfig
arm                         lpc32xx_defconfig
arm                      footbridge_defconfig
arm                          ep93xx_defconfig
powerpc                         wii_defconfig
h8300                            alldefconfig
m68k                        stmark2_defconfig
arc                        nsimosci_defconfig
arm                            qcom_defconfig
sh                   sh7724_generic_defconfig
mips                malta_qemu_32r6_defconfig
arm                        realview_defconfig
mips                        qi_lb60_defconfig
arm                            hisi_defconfig
arm                        shmobile_defconfig
mips                            ar7_defconfig
arm                           spitz_defconfig
m68k                            q40_defconfig
powerpc                    mvme5100_defconfig
powerpc                     tqm8540_defconfig
sh                        sh7785lcr_defconfig
mips                          ath25_defconfig
riscv                    nommu_virt_defconfig
arm                     am200epdkit_defconfig
xtensa                  audio_kc705_defconfig
arm                      integrator_defconfig
arm                           sunxi_defconfig
m68k                        m5407c3_defconfig
arm                            lart_defconfig
arm                         palmz72_defconfig
ia64                             alldefconfig
nds32                             allnoconfig
mips                           mtx1_defconfig
arc                     nsimosci_hs_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                 mpc832x_mds_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
xtensa                  cadence_csp_defconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                  storcenter_defconfig
arm                         s5pv210_defconfig
ia64                         bigsur_defconfig
arm                         orion5x_defconfig
xtensa                generic_kc705_defconfig
arm                           omap1_defconfig
arm                          exynos_defconfig
sh                        edosk7705_defconfig
xtensa                  nommu_kc705_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                     pq2fads_defconfig
arm                       versatile_defconfig
arm                        trizeps4_defconfig
arm                         shannon_defconfig
powerpc                     tqm5200_defconfig
arc                      axs103_smp_defconfig
sh                         apsh4a3a_defconfig
powerpc                    klondike_defconfig
mips                     cu1000-neo_defconfig
mips                          rb532_defconfig
powerpc                      ppc64e_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                       m5249evb_defconfig
mips                        omega2p_defconfig
arm                             rpc_defconfig
microblaze                      mmu_defconfig
powerpc                     kilauea_defconfig
arc                          axs101_defconfig
openrisc                  or1klitex_defconfig
arm                        spear6xx_defconfig
mips                    maltaup_xpa_defconfig
arm                      jornada720_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
parisc                           allyesconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm64                            alldefconfig
h8300                    h8300h-sim_defconfig
mips                       lemote2f_defconfig
openrisc                    or1ksim_defconfig
sh                          sdk7780_defconfig
mips                        bcm47xx_defconfig
mips                           ip32_defconfig
arm                          pxa168_defconfig
nios2                            allyesconfig
powerpc                   motionpro_defconfig
arc                           tb10x_defconfig
mips                       bmips_be_defconfig
arm                         lpc18xx_defconfig
mips                  maltasmvp_eva_defconfig
powerpc                mpc7448_hpc2_defconfig
s390                       zfcpdump_defconfig
powerpc                     tqm8548_defconfig
arm                            zeus_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                        vexpress_defconfig
um                               alldefconfig
m68k                       m5208evb_defconfig
arc                            hsdk_defconfig
powerpc                     pseries_defconfig
mips                   sb1250_swarm_defconfig
arc                        vdk_hs38_defconfig
sh                           se7751_defconfig
arm                   milbeaut_m10v_defconfig
arm                           h5000_defconfig
arm                       aspeed_g5_defconfig
ia64                      gensparse_defconfig
arm                           viper_defconfig
mips                 decstation_r4k_defconfig
arc                 nsimosci_hs_smp_defconfig
parisc                generic-64bit_defconfig
arm                       imx_v6_v7_defconfig
sh                               j2_defconfig
powerpc                     mpc5200_defconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                    vt8500_v6_v7_defconfig
mips                           gcw0_defconfig
powerpc                 mpc8560_ads_defconfig
arm                            mmp2_defconfig
powerpc                     sequoia_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
arm                           tegra_defconfig
powerpc                     mpc83xx_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
arc                         haps_hs_defconfig
sparc64                             defconfig
arm                      pxa255-idp_defconfig
xtensa                          iss_defconfig
powerpc                 mpc837x_mds_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                         at91_dt_defconfig
mips                  decstation_64_defconfig
x86_64                           alldefconfig
arm                        mvebu_v7_defconfig
arm                          collie_defconfig
powerpc                      tqm8xx_defconfig
arm                       aspeed_g4_defconfig
m68k                         apollo_defconfig
arm                          pcm027_defconfig
arm                     davinci_all_defconfig
sh                          rsk7203_defconfig
sh                          sdk7786_defconfig
sparc                       sparc64_defconfig
powerpc                         ps3_defconfig
arm                          gemini_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210406
x86_64               randconfig-a003-20210406
x86_64               randconfig-a005-20210406
x86_64               randconfig-a001-20210406
x86_64               randconfig-a002-20210406
x86_64               randconfig-a006-20210406
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a004-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a006-20210406
i386                 randconfig-a003-20210406
i386                 randconfig-a001-20210406
i386                 randconfig-a004-20210406
i386                 randconfig-a005-20210406
i386                 randconfig-a002-20210406
i386                 randconfig-a014-20210406
i386                 randconfig-a016-20210406
i386                 randconfig-a011-20210406
i386                 randconfig-a012-20210406
i386                 randconfig-a015-20210406
i386                 randconfig-a013-20210406
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210406
x86_64               randconfig-a015-20210406
x86_64               randconfig-a013-20210406
x86_64               randconfig-a011-20210406
x86_64               randconfig-a012-20210406
x86_64               randconfig-a016-20210406
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 05:13:25 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 12:13:25 +0800
Subject: [soc:drivers/memory] BUILD SUCCESS
 25dcca7fedcd4e31cb368ad846bfd738c0c6307c
Message-ID: <606fd465.Whe6zsKJhkECI3gL%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/memory
branch HEAD: 25dcca7fedcd4e31cb368ad846bfd738c0c6307c  memory: pl353: fix mask of ECC page_size config register

elapsed time: 5092m

configs tested: 379
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
mips                        workpad_defconfig
xtensa                generic_kc705_defconfig
sh                         microdev_defconfig
arm                            mmp2_defconfig
sparc64                             defconfig
sh                           se7343_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
mips                      pic32mzda_defconfig
mips                         mpc30x_defconfig
mips                         cobalt_defconfig
sh                          rsk7201_defconfig
arm                        clps711x_defconfig
powerpc                      bamboo_defconfig
mips                      pistachio_defconfig
sh                           se7619_defconfig
powerpc                     akebono_defconfig
arm                       aspeed_g4_defconfig
sh                          sdk7786_defconfig
csky                             alldefconfig
arm                        spear3xx_defconfig
arm                          lpd270_defconfig
powerpc                         ps3_defconfig
sh                        edosk7760_defconfig
arm                        realview_defconfig
arm                           omap1_defconfig
riscv             nommu_k210_sdcard_defconfig
mips                      fuloong2e_defconfig
arm                          badge4_defconfig
arm                  colibri_pxa270_defconfig
mips                      maltaaprp_defconfig
ia64                                defconfig
sparc                            alldefconfig
mips                        qi_lb60_defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
powerpc                 canyonlands_defconfig
sh                     sh7710voipgw_defconfig
arm                            mps2_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
powerpc                    ge_imp3a_defconfig
arm                       mainstone_defconfig
arc                         haps_hs_defconfig
sh                        sh7763rdp_defconfig
xtensa                       common_defconfig
openrisc                 simple_smp_defconfig
riscv                          rv32_defconfig
powerpc                    amigaone_defconfig
powerpc                        fsp2_defconfig
powerpc                      ppc6xx_defconfig
sh                        apsh4ad0a_defconfig
arm                         lpc32xx_defconfig
arm                      footbridge_defconfig
arm                          ep93xx_defconfig
powerpc                         wii_defconfig
h8300                            alldefconfig
m68k                        stmark2_defconfig
arc                        nsimosci_defconfig
arm                            qcom_defconfig
sh                   sh7724_generic_defconfig
mips                malta_qemu_32r6_defconfig
arm                            hisi_defconfig
arm                        shmobile_defconfig
mips                            ar7_defconfig
arm                           spitz_defconfig
m68k                            q40_defconfig
powerpc                    mvme5100_defconfig
mips                          ath25_defconfig
powerpc                     tqm8540_defconfig
sh                        sh7785lcr_defconfig
riscv                    nommu_virt_defconfig
arm                     am200epdkit_defconfig
xtensa                  audio_kc705_defconfig
arm                      integrator_defconfig
arm                           sunxi_defconfig
arm                           corgi_defconfig
um                            kunit_defconfig
sh                           se7705_defconfig
arm                     davinci_all_defconfig
sh                           se7751_defconfig
sh                           sh2007_defconfig
mips                         tb0219_defconfig
mips                           mtx1_defconfig
arm                         s5pv210_defconfig
ia64                             allyesconfig
arm                         at91_dt_defconfig
mips                             allyesconfig
powerpc                      arches_defconfig
powerpc                  storcenter_defconfig
powerpc                   lite5200b_defconfig
parisc                generic-64bit_defconfig
mips                          malta_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                      ppc64e_defconfig
powerpc                      katmai_defconfig
powerpc                      ppc44x_defconfig
nds32                             allnoconfig
arc                     nsimosci_hs_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                 mpc832x_mds_defconfig
xtensa                  cadence_csp_defconfig
m68k                          hp300_defconfig
arm                         lubbock_defconfig
powerpc                        cell_defconfig
mips                       lemote2f_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                     tqm8541_defconfig
sh                         apsh4a3a_defconfig
sh                          r7785rp_defconfig
arm                       versatile_defconfig
s390                             allmodconfig
arm                          pcm027_defconfig
m68k                           sun3_defconfig
arm                        magician_defconfig
powerpc                     kilauea_defconfig
mips                        nlm_xlp_defconfig
xtensa                         virt_defconfig
powerpc                     redwood_defconfig
m68k                       m5475evb_defconfig
arm                          collie_defconfig
riscv                    nommu_k210_defconfig
mips                           gcw0_defconfig
sh                             espt_defconfig
sh                            hp6xx_defconfig
parisc                           allyesconfig
mips                           ip28_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
sparc                            allyesconfig
mips                           xway_defconfig
arm                        keystone_defconfig
powerpc                   motionpro_defconfig
powerpc                     stx_gp3_defconfig
arm                      tct_hammer_defconfig
mips                           rs90_defconfig
m68k                       bvme6000_defconfig
sh                           se7780_defconfig
mips                  cavium_octeon_defconfig
arc                     haps_hs_smp_defconfig
m68k                         apollo_defconfig
powerpc                 mpc837x_mds_defconfig
arm                          exynos_defconfig
sh                        edosk7705_defconfig
xtensa                  nommu_kc705_defconfig
arm                       imx_v4_v5_defconfig
um                                allnoconfig
arc                                 defconfig
powerpc                     pq2fads_defconfig
arm                         mv78xx0_defconfig
ia64                      gensparse_defconfig
sh                     magicpanelr2_defconfig
arm                        trizeps4_defconfig
powerpc                      ep88xc_defconfig
arm                         palmz72_defconfig
alpha                            allyesconfig
h8300                    h8300h-sim_defconfig
mips                      loongson3_defconfig
arm                         shannon_defconfig
powerpc                     tqm5200_defconfig
arc                      axs103_smp_defconfig
powerpc                    klondike_defconfig
mips                     cu1000-neo_defconfig
mips                          rb532_defconfig
powerpc                 mpc834x_mds_defconfig
h8300                     edosk2674_defconfig
m68k                             alldefconfig
sh                               j2_defconfig
sh                         ecovec24_defconfig
m68k                       m5249evb_defconfig
mips                        omega2p_defconfig
arm                             rpc_defconfig
microblaze                      mmu_defconfig
arc                          axs101_defconfig
openrisc                  or1klitex_defconfig
arm                        spear6xx_defconfig
mips                    maltaup_xpa_defconfig
arm                      jornada720_defconfig
sh                          landisk_defconfig
riscv                               defconfig
s390                       zfcpdump_defconfig
powerpc                      walnut_defconfig
arm                            xcep_defconfig
mips                      maltasmvp_defconfig
sh                 kfr2r09-romimage_defconfig
sh                          sdk7780_defconfig
powerpc                     mpc5200_defconfig
openrisc                         alldefconfig
mips                     loongson1c_defconfig
mips                        bcm63xx_defconfig
arm64                            alldefconfig
openrisc                    or1ksim_defconfig
arm                           stm32_defconfig
mips                           ip32_defconfig
sh                            migor_defconfig
mips                           ip22_defconfig
nios2                            allyesconfig
mips                        bcm47xx_defconfig
arm                          pxa168_defconfig
arc                           tb10x_defconfig
mips                       bmips_be_defconfig
arm                             pxa_defconfig
powerpc                      ppc40x_defconfig
arm                          ixp4xx_defconfig
sh                           se7721_defconfig
arm                         lpc18xx_defconfig
mips                  maltasmvp_eva_defconfig
powerpc                     tqm8548_defconfig
sh                           se7722_defconfig
sh                             shx3_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                 mpc8313_rdb_defconfig
ia64                          tiger_defconfig
powerpc                   currituck_defconfig
arm                       aspeed_g5_defconfig
powerpc                     sbc8548_defconfig
i386                                defconfig
mips                      malta_kvm_defconfig
powerpc                     skiroot_defconfig
arm                            zeus_defconfig
powerpc                        warp_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                        vexpress_defconfig
um                               alldefconfig
m68k                       m5208evb_defconfig
m68k                        m5407c3_defconfig
arc                            hsdk_defconfig
powerpc                     pseries_defconfig
mips                   sb1250_swarm_defconfig
arm                            lart_defconfig
arm                       omap2plus_defconfig
alpha                               defconfig
s390                          debug_defconfig
arc                        vdk_hs38_defconfig
arm                   milbeaut_m10v_defconfig
arm                           h5000_defconfig
arm                           viper_defconfig
mips                 decstation_r4k_defconfig
arc                 nsimosci_hs_smp_defconfig
powerpc                      pmac32_defconfig
xtensa                              defconfig
arm                       imx_v6_v7_defconfig
ia64                         bigsur_defconfig
m68k                          amiga_defconfig
mips                            gpr_defconfig
arm                          simpad_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                 mpc8560_ads_defconfig
powerpc                     sequoia_defconfig
arm                           tegra_defconfig
powerpc                     mpc83xx_defconfig
arm                            dove_defconfig
mips                          rm200_defconfig
parisc                              defconfig
powerpc                 xes_mpc85xx_defconfig
mips                  decstation_64_defconfig
x86_64                           alldefconfig
arm                        mvebu_v7_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                      tqm8xx_defconfig
sh                          rsk7203_defconfig
sparc                       sparc64_defconfig
arm                          gemini_defconfig
arm                          iop32x_defconfig
ia64                             allmodconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
csky                                defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
s390                             allyesconfig
s390                                defconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210406
x86_64               randconfig-a003-20210406
x86_64               randconfig-a005-20210406
x86_64               randconfig-a001-20210406
x86_64               randconfig-a002-20210406
x86_64               randconfig-a006-20210406
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210406
i386                 randconfig-a003-20210406
i386                 randconfig-a001-20210406
i386                 randconfig-a004-20210406
i386                 randconfig-a005-20210406
i386                 randconfig-a002-20210406
i386                 randconfig-a006-20210405
i386                 randconfig-a003-20210405
i386                 randconfig-a001-20210405
i386                 randconfig-a004-20210405
i386                 randconfig-a002-20210405
i386                 randconfig-a005-20210405
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a014-20210405
x86_64               randconfig-a015-20210405
x86_64               randconfig-a013-20210405
x86_64               randconfig-a011-20210405
x86_64               randconfig-a012-20210405
x86_64               randconfig-a016-20210405
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
i386                 randconfig-a014-20210406
i386                 randconfig-a016-20210406
i386                 randconfig-a011-20210406
i386                 randconfig-a012-20210406
i386                 randconfig-a015-20210406
i386                 randconfig-a013-20210406
i386                 randconfig-a014-20210405
i386                 randconfig-a011-20210405
i386                 randconfig-a016-20210405
i386                 randconfig-a012-20210405
i386                 randconfig-a015-20210405
i386                 randconfig-a013-20210405
riscv                             allnoconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210405
x86_64               randconfig-a003-20210405
x86_64               randconfig-a005-20210405
x86_64               randconfig-a001-20210405
x86_64               randconfig-a002-20210405
x86_64               randconfig-a006-20210405
x86_64               randconfig-a014-20210406
x86_64               randconfig-a015-20210406
x86_64               randconfig-a013-20210406
x86_64               randconfig-a011-20210406
x86_64               randconfig-a012-20210406
x86_64               randconfig-a016-20210406
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From andrew at aj.id.au  Fri Apr  9 05:14:25 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 13:44:25 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v1_2/2]_mmc:_sdhci-of-aspeed:_Support_toggling_SD_b?=
 =?UTF-8?Q?us_signal_voltage_by_GPIO?=
In-Reply-To: <20210408015218.20560-3-steven_lee@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-3-steven_lee@aspeedtech.com>
Message-ID: <acaa2cc2-9b12-442e-a767-3c4b41affa21@www.fastmail.com>

Hi Steven,

On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> AST2600-A2 EVB provides reference design to support toggling signal
> voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
> the device tree.

Is this something you think we need support for beyond the EVB? It 
sounds a lot like a knob to enable testing of different SD/MMC power 
configurations and not something that you'd otherwise see in a system 
design.

> It also supporting enabling/disabling SD bus power by
> power-gpio.

This sounds like it could be useful but I'll defer to Ulf with regards 
to the binding.

> 
> In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> a 1.8v and a 3.3v power load switch that providing signal voltage to
> SD1 bus.
> If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> disabled.
> If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> voltage is 3.3v, otherwise, 1.8v power load switch will be enabled, SD1
> signal voltage becomes 1.8v.
> 
> AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and
> GPIOV3 as power-switch-gpio.
> 
> Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> ---
>  drivers/mmc/host/sdhci-of-aspeed.c | 155 +++++++++++++++++++++++++----
>  1 file changed, 137 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-aspeed.c 
> b/drivers/mmc/host/sdhci-of-aspeed.c
> index 7d8692e90996..a74a03d37915 100644
> --- a/drivers/mmc/host/sdhci-of-aspeed.c
> +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> @@ -5,6 +5,7 @@
>  #include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
> +#include <linux/gpio/consumer.h>
>  #include <linux/io.h>
>  #include <linux/math64.h>
>  #include <linux/mmc/host.h>
> @@ -30,6 +31,7 @@
>  #define   ASPEED_SDC_S0_PHASE_IN_EN	BIT(2)
>  #define   ASPEED_SDC_S0_PHASE_OUT_EN	GENMASK(1, 0)
>  #define   ASPEED_SDC_PHASE_MAX		31
> +#define ASPEED_CLOCK_PHASE 0xf4

This isn't related to the power GPIOs, and we already have phase 
support as suggested by the macros immediately above the one you've 
added here.

Please remove it and make use of the existing mmc phase devicetree 
binding and driver support.

>  
>  struct aspeed_sdc {
>  	struct clk *clk;
> @@ -58,18 +60,21 @@ struct aspeed_sdhci_phase_desc {
>  	struct aspeed_sdhci_tap_desc out;
>  };
>  
> -struct aspeed_sdhci_pdata {
> +struct aspeed_sdhci_data {

Why are we renaming this? It looks like it creates a lot of noise in 
the patch. The data it captured was platform data, hence 'pdata' in the 
name. In my opinon it's fine if we also have a member called pdata.

>  	unsigned int clk_div_start;
>  	const struct aspeed_sdhci_phase_desc *phase_desc;
>  	size_t nr_phase_descs;
> +	const struct sdhci_pltfm_data *pdata;
>  };
>  
>  struct aspeed_sdhci {
> -	const struct aspeed_sdhci_pdata *pdata;
> +	const struct aspeed_sdhci_data *data;
>  	struct aspeed_sdc *parent;
>  	u32 width_mask;
>  	struct mmc_clk_phase_map phase_map;
>  	const struct aspeed_sdhci_phase_desc *phase_desc;
> +	struct gpio_desc *pwr_pin;
> +	struct gpio_desc *pwr_sw_pin;
>  };
>  
>  static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
> @@ -209,7 +214,6 @@ static void aspeed_sdhci_set_clock(struct 
> sdhci_host *host, unsigned int clock)
>  	sdhci = sdhci_pltfm_priv(pltfm_host);
>  
>  	parent = clk_get_rate(pltfm_host->clk);
> -

Unrelated whitespace cleanup.

>  	sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
>  
>  	if (clock == 0)
> @@ -234,14 +238,13 @@ static void aspeed_sdhci_set_clock(struct 
> sdhci_host *host, unsigned int clock)
>  	 * supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and 
> capture
>  	 * the 0-value capability in clk_div_start.
>  	 */
> -	for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
> +	for (div = sdhci->data->clk_div_start; div < 256; div *= 2) {
>  		bus = parent / div;
>  		if (bus <= clock)
>  			break;
>  	}
>  
>  	div >>= 1;
> -

Unrelated whitespace cleanup.

>  	clk = div << SDHCI_DIVIDER_SHIFT;
>  
>  	aspeed_sdhci_configure_phase(host, bus);
> @@ -292,8 +295,78 @@ static u32 aspeed_sdhci_readl(struct sdhci_host 
> *host, int reg)
>  	return val;
>  }
>  
> +static void sdhci_aspeed_set_power(struct sdhci_host *host, unsigned char mode,
> +				   unsigned short vdd)
> +{
> +	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
> +	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
> +	u8 pwr = 0;
> +
> +	if (!dev->pwr_pin)
> +		return sdhci_set_power(host, mode, vdd);
> +
> +	if (mode != MMC_POWER_OFF) {
> +		switch (1 << vdd) {
> +		case MMC_VDD_165_195:
> +		/*
> +		 * Without a regulator, SDHCI does not support 2.0v
> +		 * so we only get here if the driver deliberately
> +		 * added the 2.0v range to ocr_avail. Map it to 1.8v
> +		 * for the purpose of turning on the power.
> +		 */
> +		case MMC_VDD_20_21:
> +				pwr = SDHCI_POWER_180;
> +				break;
> +		case MMC_VDD_29_30:
> +		case MMC_VDD_30_31:
> +				pwr = SDHCI_POWER_300;
> +				break;
> +		case MMC_VDD_32_33:
> +		case MMC_VDD_33_34:
> +				pwr = SDHCI_POWER_330;
> +				break;
> +		default:
> +				WARN(1, "%s: Invalid vdd %#x\n",
> +				     mmc_hostname(host->mmc), vdd);
> +				break;
> +		}
> +	}
> +
> +	if (host->pwr == pwr)
> +		return;
> +
> +	host->pwr = pwr;
> +
> +	if (pwr == 0) {

Shouldn't we be testing against an SDHCI_POWER_* macro?

> +		gpiod_set_value(dev->pwr_pin, 0);
> +		sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> +	} else {
> +		gpiod_set_value(dev->pwr_pin, 1);
> +
> +		if (dev->pwr_sw_pin) {
> +			if (pwr & SDHCI_POWER_330)
> +				gpiod_set_value(dev->pwr_sw_pin, 1);
> +			else if (pwr & SDHCI_POWER_180)
> +				gpiod_set_value(dev->pwr_sw_pin, 0);
> +		}
> +		pwr |= SDHCI_POWER_ON;
> +		sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
> +	}
> +}
> +
> +static void aspeed_sdhci_voltage_switch(struct sdhci_host *host)
> +{
> +	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
> +	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
> +
> +	if (dev->pwr_sw_pin)
> +		gpiod_set_value(dev->pwr_sw_pin, 0);
> +}
> +
>  static const struct sdhci_ops aspeed_sdhci_ops = {
>  	.read_l = aspeed_sdhci_readl,
> +	.set_power = sdhci_aspeed_set_power,
> +	.voltage_switch = aspeed_sdhci_voltage_switch,
>  	.set_clock = aspeed_sdhci_set_clock,
>  	.get_max_clock = aspeed_sdhci_get_max_clock,
>  	.set_bus_width = aspeed_sdhci_set_bus_width,
> @@ -302,9 +375,14 @@ static const struct sdhci_ops aspeed_sdhci_ops = {
>  	.set_uhs_signaling = sdhci_set_uhs_signaling,
>  };
>  
> -static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
> +static const struct sdhci_pltfm_data ast2400_sdhci_pdata = {
>  	.ops = &aspeed_sdhci_ops,
>  	.quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> +	.quirks2 = SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN | 
> SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> +};
> +
> +static const struct sdhci_pltfm_data ast2600_sdhci_pdata = {
> +	.ops = &aspeed_sdhci_ops,
>  };
>  
>  static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> @@ -327,27 +405,28 @@ static inline int 
> aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
>  
>  static int aspeed_sdhci_probe(struct platform_device *pdev)
>  {
> -	const struct aspeed_sdhci_pdata *aspeed_pdata;
> +	const struct aspeed_sdhci_data *aspeed_data;
>  	struct sdhci_pltfm_host *pltfm_host;
>  	struct aspeed_sdhci *dev;
>  	struct sdhci_host *host;
>  	struct resource *res;
> +	u32 reg_val;
>  	int slot;
>  	int ret;
>  
> -	aspeed_pdata = of_device_get_match_data(&pdev->dev);
> -	if (!aspeed_pdata) {
> +	aspeed_data = of_device_get_match_data(&pdev->dev);
> +	if (!aspeed_data) {
>  		dev_err(&pdev->dev, "Missing platform configuration data\n");
>  		return -EINVAL;
>  	}
>  
> -	host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
> +	host = sdhci_pltfm_init(pdev, aspeed_data->pdata, sizeof(*dev));
>  	if (IS_ERR(host))
>  		return PTR_ERR(host);
>  
>  	pltfm_host = sdhci_priv(host);
>  	dev = sdhci_pltfm_priv(pltfm_host);
> -	dev->pdata = aspeed_pdata;
> +	dev->data = aspeed_data;
>  	dev->parent = dev_get_drvdata(pdev->dev.parent);
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -358,8 +437,8 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
>  	else if (slot >= 2)
>  		return -EINVAL;
>  
> -	if (slot < dev->pdata->nr_phase_descs) {
> -		dev->phase_desc = &dev->pdata->phase_desc[slot];
> +	if (slot < dev->data->nr_phase_descs) {
> +		dev->phase_desc = &dev->data->phase_desc[slot];
>  	} else {
>  		dev_info(&pdev->dev,
>  			 "Phase control not supported for slot %d\n", slot);
> @@ -372,6 +451,23 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
>  
>  	sdhci_get_of_property(pdev);
>  
> +	if (of_property_read_bool(pdev->dev.parent->of_node, "mmc-hs200-1_8v") ||
> +	    of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
> +		reg_val = readl(host->ioaddr + 0x40);

Shouldn't this use  sdhci_readl()?

> +		/* support 1.8V */
> +		reg_val |= BIT(26);
> +		/* write to sdhci140 or sdhci240 mirror register */
> +		writel(reg_val, dev->parent->regs + (0x10 * (slot + 1)));

I think I prefer a helper for this, like 
aspeed_sdc_set_slot_capability(dev->parent, reg_val, slot, cap_idx), 
rather than poking the global SD controller config space from the SDHCI 
driver.

> +	}
> +
> +	if (of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
> +		reg_val = readl(host->ioaddr + 0x44);
> +		/* SDR104 */
> +		reg_val |= BIT(1);
> +		/* write to sdhci144 or sdhci244 mirror register */
> +		writel(reg_val, dev->parent->regs + (0x04 + (slot + 1) * 0x10));

As above.

> +	}
> +
>  	pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
>  	if (IS_ERR(pltfm_host->clk))
>  		return PTR_ERR(pltfm_host->clk);
> @@ -389,6 +485,22 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
>  	if (dev->phase_desc)
>  		mmc_of_parse_clk_phase(host->mmc, &dev->phase_map);
>  
> +	dev->pwr_pin = devm_gpiod_get(&pdev->dev, "power", GPIOD_OUT_HIGH);

Shouldn't this use devm_gpiod_get_optional()?

> +	if (!IS_ERR(dev->pwr_pin)) {
> +		gpiod_set_consumer_name(dev->pwr_pin, "mmc_pwr");
> +		gpiod_direction_output(dev->pwr_pin, 1);
> +	} else {
> +		dev->pwr_pin = NULL;
> +	}
> +
> +	dev->pwr_sw_pin = devm_gpiod_get(&pdev->dev, "power-switch", GPIOD_OUT_HIGH);

Shouldn't this use devm_gpiod_get_optional()?

> +	if (!IS_ERR(dev->pwr_sw_pin)) {
> +		gpiod_set_consumer_name(dev->pwr_sw_pin, "mmc_pwr_sw");
> +		gpiod_direction_output(dev->pwr_sw_pin, 0);
> +	} else {
> +		dev->pwr_sw_pin = NULL;
> +	}
> +
>  	ret = sdhci_add_host(host);
>  	if (ret)
>  		goto err_sdhci_add;
> @@ -420,8 +532,9 @@ static int aspeed_sdhci_remove(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static const struct aspeed_sdhci_pdata ast2400_sdhci_pdata = {
> +static const struct aspeed_sdhci_data ast2400_sdhci_data = {
>  	.clk_div_start = 2,
> +	.pdata = &ast2400_sdhci_pdata,
>  };
>  
>  static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
> @@ -453,16 +566,17 @@ static const struct aspeed_sdhci_phase_desc 
> ast2600_sdhci_phase[] = {
>  	},
>  };
>  
> -static const struct aspeed_sdhci_pdata ast2600_sdhci_pdata = {
> +static const struct aspeed_sdhci_data ast2600_sdhci_data = {
>  	.clk_div_start = 1,
>  	.phase_desc = ast2600_sdhci_phase,
>  	.nr_phase_descs = ARRAY_SIZE(ast2600_sdhci_phase),
> +	.pdata = &ast2600_sdhci_pdata,
>  };
>  
>  static const struct of_device_id aspeed_sdhci_of_match[] = {
> -	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_pdata, },
> -	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_pdata, },
> -	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_pdata, },
> +	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_data, },
> +	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_data, },
> +	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_data, },
>  	{ }
>  };
>  
> @@ -482,6 +596,7 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
>  	struct device_node *parent, *child;
>  	struct aspeed_sdc *sdc;
>  	int ret;
> +	u32 timing_phase;
>  
>  	sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
>  	if (!sdc)
> @@ -506,6 +621,10 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
>  		goto err_clk;
>  	}
>  
> +	if (!of_property_read_u32(pdev->dev.of_node,
> +				  "timing-phase", &timing_phase))
> +		writel(timing_phase, sdc->regs + ASPEED_CLOCK_PHASE);

As mentioned at the top, please use the existing phase bindings.

Cheers,

Andrew


From zweiss at equinix.com  Fri Apr  9 05:35:30 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 04:35:30 +0000
Subject: [PATCH v2 13/21] ipmi: kcs_bmc: Decouple the IPMI chardev from
 the core
In-Reply-To: <20210319062752.145730-13-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-13-andrew@aj.id.au>
Message-ID: <YG/ZkanVAypmjCba@packtop>

On Fri, Mar 19, 2021 at 01:27:44AM CDT, Andrew Jeffery wrote:
>Now that we have untangled the data-structures, split the userspace
>interface out into its own module. Userspace interfaces and drivers are
>registered to the KCS BMC core to support arbitrary binding of either.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/Kconfig             | 13 +++++
> drivers/char/ipmi/Makefile            |  3 +-
> drivers/char/ipmi/kcs_bmc.c           | 78 ++++++++++++++++++++++++++-
> drivers/char/ipmi/kcs_bmc.h           |  4 --
> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 33 +++++++++---
> drivers/char/ipmi/kcs_bmc_client.h    | 14 +++++
> 6 files changed, 132 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
>index 07847d9a459a..bc5f81899b62 100644
>--- a/drivers/char/ipmi/Kconfig
>+++ b/drivers/char/ipmi/Kconfig
>@@ -124,6 +124,19 @@ config NPCM7XX_KCS_IPMI_BMC
> 	  This support is also available as a module.  If so, the module
> 	  will be called kcs_bmc_npcm7xx.
>
>+config IPMI_KCS_BMC_CDEV_IPMI
>+	depends on IPMI_KCS_BMC
>+	tristate "IPMI character device interface for BMC KCS devices"
>+	help
>+	  Provides a BMC-side character device implementing IPMI
>+	  semantics for KCS IPMI devices.
>+
>+	  Say YES if you wish to expose KCS devices on the BMC for IPMI
>+	  purposes.
>+
>+	  This support is also available as a module. The module will be
>+	  called kcs_bmc_cdev_ipmi.
>+
> config ASPEED_BT_IPMI_BMC
> 	depends on ARCH_ASPEED || COMPILE_TEST
> 	depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
>diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>index a302bc865370..fcfa676afddb 100644
>--- a/drivers/char/ipmi/Makefile
>+++ b/drivers/char/ipmi/Makefile
>@@ -22,7 +22,8 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
> obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
> obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
>-obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
>+obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
>+obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o
> obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index 266ebec71d6f..694db6ee2a92 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -5,7 +5,9 @@
>  */
>
> #include <linux/device.h>
>+#include <linux/list.h>
> #include <linux/module.h>
>+#include <linux/mutex.h>
>
> #include "kcs_bmc.h"
>
>@@ -13,6 +15,11 @@
> #include "kcs_bmc_device.h"
> #include "kcs_bmc_client.h"
>
>+/* Record probed devices and cdevs */
>+static DEFINE_MUTEX(kcs_bmc_lock);
>+static LIST_HEAD(kcs_bmc_devices);
>+static LIST_HEAD(kcs_bmc_cdevs);
>+
> /* Consumer data access */
>
> u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc)
>@@ -100,16 +107,83 @@ EXPORT_SYMBOL(kcs_bmc_disable_device);
>
> int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc)
> {
>-	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
>+	struct kcs_bmc_cdev *cdev;
>+	int rc;
>+
>+	spin_lock_init(&kcs_bmc->lock);
>+	kcs_bmc->client = NULL;
>+
>+	mutex_lock(&kcs_bmc_lock);
>+	list_add(&kcs_bmc->entry, &kcs_bmc_devices);
>+	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
>+		rc = cdev->ops->add_device(kcs_bmc);
>+		if (rc)
>+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",
>+				kcs_bmc->channel, rc);
>+	}
>+	mutex_unlock(&kcs_bmc_lock);
>+
>+	return 0;

We're ignoring failed ->add_device() calls here?

> }
> EXPORT_SYMBOL(kcs_bmc_add_device);
>
> int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc)
> {
>-	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
>+	struct kcs_bmc_cdev *cdev;
>+	int rc;
>+
>+	mutex_lock(&kcs_bmc_lock);
>+	list_del(&kcs_bmc->entry);
>+	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
>+		rc = cdev->ops->remove_device(kcs_bmc);
>+		if (rc)
>+			dev_err(kcs_bmc->dev, "Failed to remove chardev for KCS channel %d: %d",
>+				kcs_bmc->channel, rc);
>+	}
>+	mutex_unlock(&kcs_bmc_lock);
>+
>+	return 0;

Similarly with the return value here...

> }
> EXPORT_SYMBOL(kcs_bmc_remove_device);
>
>+int kcs_bmc_register_cdev(struct kcs_bmc_cdev *cdev)
>+{
>+	struct kcs_bmc_device *kcs_bmc;
>+	int rc;
>+
>+	mutex_lock(&kcs_bmc_lock);
>+	list_add(&cdev->entry, &kcs_bmc_cdevs);
>+	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
>+		rc = cdev->ops->add_device(kcs_bmc);
>+		if (rc)
>+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",
>+				kcs_bmc->channel, rc);
>+	}
>+	mutex_unlock(&kcs_bmc_lock);
>+
>+	return 0;

...return value again here...

>+}
>+EXPORT_SYMBOL(kcs_bmc_register_cdev);
>+
>+int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev)
>+{
>+	struct kcs_bmc_device *kcs_bmc;
>+	int rc;
>+
>+	mutex_lock(&kcs_bmc_lock);
>+	list_del(&cdev->entry);
>+	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
>+		rc = cdev->ops->remove_device(kcs_bmc);
>+		if (rc)
>+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",

s/add/remove/

Might also want to differentiate the *_device() error messages from the
*_cdev() ones a bit more?

>+				kcs_bmc->channel, rc);
>+	}
>+	mutex_unlock(&kcs_bmc_lock);
>+
>+	return rc;

...but this one is a bit incongruous, propagating the return value of
only the last ->remove_device() call.

(I'd have expected this to trigger a warning about returning a
potentially uninitialized 'rc', but in some manual testing it doesn't
seem to do so for me...not certain why.)

>+}
>+EXPORT_SYMBOL(kcs_bmc_unregister_cdev);
>+
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index 3f266740c759..5deb9a0b8e60 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -42,8 +42,4 @@ struct kcs_bmc_device {
> 	spinlock_t lock;
> 	struct kcs_bmc_client *client;
> };
>-
>-/* Temporary exports while refactoring */
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
> #endif /* __KCS_BMC_H__ */
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>index 58c42e76483d..df83d67851ac 100644
>--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>@@ -469,8 +469,7 @@ static const struct file_operations kcs_bmc_ipmi_fops = {
> static DEFINE_SPINLOCK(kcs_bmc_ipmi_instances_lock);
> static LIST_HEAD(kcs_bmc_ipmi_instances);
>
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
>-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
>+static int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
> {
> 	struct kcs_bmc_ipmi *priv;
> 	int rc;
>@@ -512,10 +511,8 @@ int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
>
> 	return 0;
> }
>-EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
>
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
>-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
>+static int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
> {
> 	struct kcs_bmc_ipmi *priv = NULL, *pos;
>
>@@ -541,7 +538,31 @@ int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
>
> 	return 0;
> }
>-EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
>+
>+static const struct kcs_bmc_cdev_ops kcs_bmc_ipmi_cdev_ops = {
>+	.add_device = kcs_bmc_ipmi_attach_cdev,
>+	.remove_device = kcs_bmc_ipmi_detach_cdev,
>+};
>+
>+static struct kcs_bmc_cdev kcs_bmc_ipmi_cdev = {
>+	.ops = &kcs_bmc_ipmi_cdev_ops,
>+};
>+
>+static int kcs_bmc_ipmi_init(void)
>+{
>+	return kcs_bmc_register_cdev(&kcs_bmc_ipmi_cdev);
>+}
>+module_init(kcs_bmc_ipmi_init);
>+
>+static void kcs_bmc_ipmi_exit(void)
>+{
>+	int rc;
>+
>+	rc = kcs_bmc_unregister_cdev(&kcs_bmc_ipmi_cdev);
>+	if (rc)
>+		pr_warn("Failed to remove KCS BMC client: %d", rc);
>+}
>+module_exit(kcs_bmc_ipmi_exit);
>
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>diff --git a/drivers/char/ipmi/kcs_bmc_client.h b/drivers/char/ipmi/kcs_bmc_client.h
>index 2dd710f4b4aa..d0a7404ff584 100644
>--- a/drivers/char/ipmi/kcs_bmc_client.h
>+++ b/drivers/char/ipmi/kcs_bmc_client.h
>@@ -10,6 +10,17 @@
>
> #include "kcs_bmc.h"
>
>+struct kcs_bmc_cdev_ops {
>+	int (*add_device)(struct kcs_bmc_device *kcs_bmc);
>+	int (*remove_device)(struct kcs_bmc_device *kcs_bmc);
>+};
>+
>+struct kcs_bmc_cdev {
>+	struct list_head entry;
>+
>+	const struct kcs_bmc_cdev_ops *ops;
>+};
>+
> struct kcs_bmc_client_ops {
> 	int (*event)(struct kcs_bmc_client *client);
> };
>@@ -20,6 +31,9 @@ struct kcs_bmc_client {
> 	struct kcs_bmc_device *dev;
> };
>
>+int kcs_bmc_register_cdev(struct kcs_bmc_cdev *cdev);
>+int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev);
>+
> int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
> void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
>
>-- 
>2.27.0
>

From joel at jms.id.au  Fri Apr  9 05:37:34 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 04:37:34 +0000
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <YGzZofPvT80b5gS5@latitude>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>
 <YGzZofPvT80b5gS5@latitude>
Message-ID: <CACPK8XdbwbsbJuZmvsFqJ+x5viu652vpfR1kwB4Gu+khRHNt_g@mail.gmail.com>

On Tue, 6 Apr 2021 at 21:59, Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
>
> On Tue, Apr 06, 2021 at 05:15:01PM +0200, Arnd Bergmann wrote:
> > On Tue, Apr 6, 2021 at 2:09 PM Jonathan Neusch?fer
> > <j.neuschaefer at gmx.net> wrote:
> > >
> > > This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
> > > SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.
> > >
> > > Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki
> > >
> > > Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
> > > Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
> > > the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.
> > >
> > > Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
> > > (https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)
> >
> > Hi Jonathan,
> >
> > It appears these patches are doing roughly the right thing, and we may still
> > be able to get them into v5.13, but I'm not sure what your plan for maintaining
> > them is. The two options are that you either send your patches to be picked up
> > by Joel, or you send everything directly to soc at kernel.org once it's fully
> > reviewed.
>
> The route via Joel sounds alright with me. I've Cc'd him on this version
> of the series.

I've had a look at the series and it looks good to me:

Reviewed-by: Joel Stanley <joel at jms.id.au>

Nice work Jonathan.

I'll put this in it's own branch along with the bindings change it
depends on and send a pull request to Arnd for v5.13.

Cheers,

Joel


From zweiss at equinix.com  Fri Apr  9 05:37:18 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 04:37:18 +0000
Subject: [PATCH v2 14/21] ipmi: kcs_bmc: Allow clients to control KCS IRQ
 state
In-Reply-To: <20210319062752.145730-14-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-14-andrew@aj.id.au>
Message-ID: <YG/Z/eZCES65fXQi@packtop>

On Fri, Mar 19, 2021 at 01:27:45AM CDT, Andrew Jeffery wrote:
>Add a mechanism for controlling whether the client associated with a
>KCS device will receive Input Buffer Full (IBF) and Output Buffer Empty
>(OBE) events. This enables an abstract implementation of poll() for KCS
>devices.
>
>A wart in the implementation is that the ASPEED KCS devices don't
>support an OBE interrupt for the BMC. Instead we pretend it has one by
>polling the status register waiting for the Output Buffer Full (OBF) bit
>to clear, and generating an event when OBE is observed.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc.c         |   6 ++
> drivers/char/ipmi/kcs_bmc.h         |   3 +
> drivers/char/ipmi/kcs_bmc_aspeed.c  | 150 ++++++++++++++++++----------
> drivers/char/ipmi/kcs_bmc_client.h  |   2 +
> drivers/char/ipmi/kcs_bmc_device.h  |   1 +
> drivers/char/ipmi/kcs_bmc_npcm7xx.c |  25 ++++-
> 6 files changed, 130 insertions(+), 57 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index 694db6ee2a92..05bbb72418b2 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -184,6 +184,12 @@ int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev)
> }
> EXPORT_SYMBOL(kcs_bmc_unregister_cdev);
>
>+void kcs_bmc_update_event_mask(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 events)
>+{
>+	kcs_bmc->ops->irq_mask_update(kcs_bmc, mask, events);
>+}
>+EXPORT_SYMBOL(kcs_bmc_update_event_mask);
>+
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>index 5deb9a0b8e60..11fff935218c 100644
>--- a/drivers/char/ipmi/kcs_bmc.h
>+++ b/drivers/char/ipmi/kcs_bmc.h
>@@ -11,6 +11,9 @@
> #define KCS_BMC_EVENT_NONE	0
> #define KCS_BMC_EVENT_HANDLED	1
>
>+#define KCS_BMC_EVENT_TYPE_OBE	BIT(0)
>+#define KCS_BMC_EVENT_TYPE_IBF	BIT(1)
>+
> #define KCS_BMC_STR_OBF		BIT(0)
> #define KCS_BMC_STR_IBF		BIT(1)
> #define KCS_BMC_STR_CMD_DAT	BIT(3)
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 6f26e7366c0b..5f26471c038c 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -60,10 +60,18 @@
> #define LPC_ODR4             0x118
> #define LPC_STR4             0x11C
>
>+#define OBE_POLL_PERIOD	     (HZ / 2)
>+
> struct aspeed_kcs_bmc {
> 	struct kcs_bmc_device kcs_bmc;
>
> 	struct regmap *map;
>+
>+	struct {
>+		spinlock_t lock;
>+		bool remove;
>+		struct timer_list timer;
>+	} obe;
> };
>
> struct aspeed_kcs_of_ops {
>@@ -159,68 +167,89 @@ static void aspeed_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enabl
>
> 	switch (kcs_bmc->channel) {
> 	case 1:
>-		if (enable) {
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF1, LPC_HICR2_IBFIF1);
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC1E, LPC_HICR0_LPC1E);
>-		} else {
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC1E, 0);
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF1, 0);
>-		}
>-		break;
>-
>+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC1E, enable * LPC_HICR0_LPC1E);
>+		return;
> 	case 2:
>-		if (enable) {
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF2, LPC_HICR2_IBFIF2);
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC2E, LPC_HICR0_LPC2E);
>-		} else {
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC2E, 0);
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF2, 0);
>-		}
>-		break;
>-
>+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC2E, enable * LPC_HICR0_LPC2E);
>+		return;
> 	case 3:
>-		if (enable) {
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF3, LPC_HICR2_IBFIF3);
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC3E, LPC_HICR0_LPC3E);
>-			regmap_update_bits(priv->map, LPC_HICR4,
>-					LPC_HICR4_KCSENBL, LPC_HICR4_KCSENBL);
>-		} else {
>-			regmap_update_bits(priv->map, LPC_HICR0,
>-					LPC_HICR0_LPC3E, 0);
>-			regmap_update_bits(priv->map, LPC_HICR4,
>-					LPC_HICR4_KCSENBL, 0);
>-			regmap_update_bits(priv->map, LPC_HICR2,
>-					LPC_HICR2_IBFIF3, 0);
>-		}
>-		break;
>-
>+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC3E, enable * LPC_HICR0_LPC3E);
>+		regmap_update_bits(priv->map, LPC_HICR4,
>+				   LPC_HICR4_KCSENBL, enable * LPC_HICR4_KCSENBL);
>+		return;
> 	case 4:
>-		if (enable)
>-			regmap_update_bits(priv->map, LPC_HICRB,
>-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E,
>-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E);
>+		regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_LPC4E, enable * LPC_HICRB_LPC4E);
>+		return;
>+	default:
>+		pr_warn("%s: Unsupported channel: %d", __func__, kcs_bmc->channel);
>+		return;
>+	}
>+}
>+
>+static void aspeed_kcs_check_obe(struct timer_list *timer)
>+{
>+	struct aspeed_kcs_bmc *priv = container_of(timer, struct aspeed_kcs_bmc, obe.timer);
>+	unsigned long flags;
>+	u8 str;
>+
>+	spin_lock_irqsave(&priv->obe.lock, flags);
>+	if (priv->obe.remove) {
>+		spin_unlock_irqrestore(&priv->obe.lock, flags);
>+		return;
>+	}
>+
>+	str = aspeed_kcs_inb(&priv->kcs_bmc, priv->kcs_bmc.ioreg.str);
>+	if (str & KCS_BMC_STR_OBF) {
>+		mod_timer(timer, jiffies + OBE_POLL_PERIOD);
>+		spin_unlock_irqrestore(&priv->obe.lock, flags);
>+		return;
>+	}
>+	spin_unlock_irqrestore(&priv->obe.lock, flags);
>+
>+	kcs_bmc_handle_event(&priv->kcs_bmc);
>+}
>+
>+static void aspeed_kcs_irq_mask_update(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 state)
>+{
>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>+
>+	/* We don't have an OBE IRQ, emulate it */
>+	if (KCS_BMC_EVENT_TYPE_OBE & mask) {
>+		if (KCS_BMC_EVENT_TYPE_OBE & state)
>+			mod_timer(&priv->obe.timer, jiffies + OBE_POLL_PERIOD);
> 		else
>-			regmap_update_bits(priv->map, LPC_HICRB,
>-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E,
>-					0);
>-		break;
>+			del_timer(&priv->obe.timer);
>+	}
>
>-	default:
>-		break;
>+	if (KCS_BMC_EVENT_TYPE_IBF & mask) {
>+		const bool enable = !!(KCS_BMC_EVENT_TYPE_IBF & state);

Totally superficial nitpick: the operand ordering for the bitmask tests
in this function seem a bit inconsistent with what I think is the usual
style of 'variable & BITMASK_MACRO' (reminiscent of "yoda
conditionals").

>+
>+		switch (kcs_bmc->channel) {
>+		case 1:
>+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF1,
>+					   enable * LPC_HICR2_IBFIF1);
>+			return;
>+		case 2:
>+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF2,
>+					   enable * LPC_HICR2_IBFIF2);
>+			return;
>+		case 3:
>+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF3,
>+					   enable * LPC_HICR2_IBFIF3);
>+			return;
>+		case 4:
>+			regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_IBFIF4,
>+					   enable * LPC_HICRB_IBFIF4);
>+			return;
>+		default:
>+			pr_warn("%s: Unsupported channel: %d", __func__, kcs_bmc->channel);
>+			return;
>+		}
> 	}
> }
>
> static const struct kcs_bmc_device_ops aspeed_kcs_ops = {
>+	.irq_mask_update = aspeed_kcs_irq_mask_update,
> 	.io_inputb = aspeed_kcs_inb,
> 	.io_outputb = aspeed_kcs_outb,
> 	.io_updateb = aspeed_kcs_updateb,
>@@ -378,6 +407,10 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> 		return -ENODEV;
> 	}
>
>+	spin_lock_init(&priv->obe.lock);
>+	priv->obe.remove = false;
>+	timer_setup(&priv->obe.timer, aspeed_kcs_check_obe, 0);
>+
> 	aspeed_kcs_set_address(kcs_bmc, addr);
>
> 	rc = aspeed_kcs_config_irq(kcs_bmc, pdev);
>@@ -386,6 +419,8 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>
> 	platform_set_drvdata(pdev, priv);
>
>+	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
>+				   KCS_BMC_EVENT_TYPE_IBF);
> 	aspeed_kcs_enable_channel(kcs_bmc, true);
>
> 	rc = kcs_bmc_add_device(&priv->kcs_bmc);
>@@ -404,6 +439,15 @@ static int aspeed_kcs_remove(struct platform_device *pdev)
>
> 	kcs_bmc_remove_device(kcs_bmc);
>
>+	aspeed_kcs_enable_channel(kcs_bmc, false);
>+	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
>+
>+	/* Make sure it's proper dead */
>+	spin_lock_irq(&priv->obe.lock);
>+	priv->obe.remove = true;
>+	spin_unlock_irq(&priv->obe.lock);
>+	del_timer_sync(&priv->obe.timer);
>+
> 	return 0;
> }
>
>diff --git a/drivers/char/ipmi/kcs_bmc_client.h b/drivers/char/ipmi/kcs_bmc_client.h
>index d0a7404ff584..456796da33de 100644
>--- a/drivers/char/ipmi/kcs_bmc_client.h
>+++ b/drivers/char/ipmi/kcs_bmc_client.h
>@@ -37,6 +37,8 @@ int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev);
> int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
> void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
>
>+void kcs_bmc_update_event_mask(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 events);
>+
> u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc);
> void kcs_bmc_write_data(struct kcs_bmc_device *kcs_bmc, u8 data);
> u8 kcs_bmc_read_status(struct kcs_bmc_device *kcs_bmc);
>diff --git a/drivers/char/ipmi/kcs_bmc_device.h b/drivers/char/ipmi/kcs_bmc_device.h
>index 57b7174b2bac..f1ca8912496a 100644
>--- a/drivers/char/ipmi/kcs_bmc_device.h
>+++ b/drivers/char/ipmi/kcs_bmc_device.h
>@@ -7,6 +7,7 @@
> #include "kcs_bmc.h"
>
> struct kcs_bmc_device_ops {
>+	void (*irq_mask_update)(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 enable);
> 	u8 (*io_inputb)(struct kcs_bmc_device *kcs_bmc, u32 reg);
> 	void (*io_outputb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 b);
> 	void (*io_updateb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 b);
>diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>index dce93ec895fc..c2032728a03d 100644
>--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>@@ -38,6 +38,7 @@
> #define KCS2CTL		0x2A
> #define KCS3CTL		0x3C
> #define    KCS_CTL_IBFIE	BIT(0)
>+#define    KCS_CTL_OBEIE	BIT(0)
>
> #define KCS1IE		0x1C
> #define KCS2IE		0x2E
>@@ -117,13 +118,23 @@ static void npcm7xx_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enab
> {
> 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>
>-	regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
>-			   enable ? KCS_CTL_IBFIE : 0);
>-
> 	regmap_update_bits(priv->map, priv->reg->ie, KCS_IE_IRQE | KCS_IE_HIRQE,
> 			   enable ? KCS_IE_IRQE | KCS_IE_HIRQE : 0);
> }
>
>+static void npcm7xx_kcs_irq_mask_update(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 state)
>+{
>+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>+
>+	if (KCS_BMC_EVENT_TYPE_OBE & mask)
>+		regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_OBEIE,
>+				   !!(KCS_BMC_EVENT_TYPE_OBE & state) * KCS_CTL_OBEIE);
>+
>+	if (KCS_BMC_EVENT_TYPE_IBF & mask)
>+		regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
>+				   !!(KCS_BMC_EVENT_TYPE_IBF & state) * KCS_CTL_IBFIE);

Same operand ordering thing here...

>+}
>+
> static irqreturn_t npcm7xx_kcs_irq(int irq, void *arg)
> {
> 	struct kcs_bmc_device *kcs_bmc = arg;
>@@ -151,6 +162,7 @@ static int npcm7xx_kcs_config_irq(struct kcs_bmc_device *kcs_bmc,
> }
>
> static const struct kcs_bmc_device_ops npcm7xx_kcs_ops = {
>+	.irq_mask_update = npcm7xx_kcs_irq_mask_update,
> 	.io_inputb = npcm7xx_kcs_inb,
> 	.io_outputb = npcm7xx_kcs_outb,
> 	.io_updateb = npcm7xx_kcs_updateb,
>@@ -191,11 +203,13 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
>
> 	platform_set_drvdata(pdev, priv);
>
>-	npcm7xx_kcs_enable_channel(kcs_bmc, true);
> 	rc = npcm7xx_kcs_config_irq(kcs_bmc, pdev);
> 	if (rc)
> 		return rc;
>
>+	npcm7xx_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
>+				    KCS_BMC_EVENT_TYPE_IBF);
>+	npcm7xx_kcs_enable_channel(kcs_bmc, true);
>
> 	pr_info("channel=%u idr=0x%x odr=0x%x str=0x%x\n",
> 		chan,
>@@ -211,6 +225,9 @@ static int npcm7xx_kcs_remove(struct platform_device *pdev)
>
> 	kcs_bmc_remove_device(kcs_bmc);
>
>+	npcm7xx_kcs_enable_channel(kcs_bmc, false);
>+	npcm7xx_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
>+
> 	return 0;
> }
>
>-- 
>2.27.0
>

From hsinyi at chromium.org  Fri Apr  9 05:53:14 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri,  9 Apr 2021 12:53:14 +0800
Subject: [PATCH 2/2] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210409045314.3420733-1-hsinyi@chromium.org>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
Message-ID: <20210409045314.3420733-2-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Fri Apr  9 05:53:13 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri,  9 Apr 2021 12:53:13 +0800
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
Message-ID: <20210409045314.3420733-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning. So set panel orientation in dsi before drm_dev_register() is
called.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..45a702ee09f3 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -205,6 +205,7 @@ struct mtk_dsi {
 	u32 irq_data;
 	wait_queue_head_t irq_wait_queue;
 	const struct mtk_dsi_driver_data *driver_data;
+	enum drm_panel_orientation orientation;
 };
 
 static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
@@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 	}
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
+	drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
+
 	return 0;
 
 err_cleanup_encoder:
@@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
 			ret = PTR_ERR(dsi->next_bridge);
 			goto err_unregister_host;
 		}
+
+		ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
+		if (ret) {
+			dev_err(dev, "failed to get panel orientation %d\n", ret);
+			return ret;
+		}
 	}
 
 	dsi->driver_data = of_device_get_match_data(dev);
-- 
2.31.1.295.g9ea45b61b8-goog



From andrew at aj.id.au  Fri Apr  9 06:06:16 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 14:36:16 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v5_2/4]_drivers/tty/serial/8250:_refactor_sirq_and_?=
 =?UTF-8?Q?lpc_address_setting_code?=
In-Reply-To: <20210408011637.5361-3-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-3-zev@bewilderbeest.net>
Message-ID: <db7271d8-8d13-4a8c-a7ba-564e4e769ea5@www.fastmail.com>



On Thu, 8 Apr 2021, at 10:46, Zev Weiss wrote:
> This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
> out of the sysfs store functions in preparation for adding DT
> properties that will be poking the same registers.  While we're at it,
> these functions now provide some basic bounds-checking on their
> arguments.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
>  1 file changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c 
> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> index c33e02cbde93..8433f8dbb186 100644
> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> @@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
>  	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
>  }
>  
> +static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
> +{
> +	if (addr > U16_MAX)
> +		return -EINVAL;
> +
> +	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
> +	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
> +
> +	return 0;
> +}
> +
>  static ssize_t lpc_address_store(struct device *dev,
>  				 struct device_attribute *attr,
>  				 const char *buf, size_t count)
>  {
>  	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
> -	unsigned long val;
> +	u32 val;
>  	int err;
>  
> -	err = kstrtoul(buf, 0, &val);
> +	err = kstrtou32(buf, 0, &val);
>  	if (err)
>  		return err;
>  
> -	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
> -	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
> -
> -	return count;
> +	err = aspeed_vuart_set_lpc_address(vuart, val);
> +	return err ? : count;
>  }
>  
>  static DEVICE_ATTR_RW(lpc_address);
> @@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
>  	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
>  }
>  
> +static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
> +{
> +	u8 reg;
> +
> +	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
> +		return -EINVAL;
> +
> +	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
> +	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;

This might be less verbose if we reordered things a little:

```
sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
if (sirq & ASPEED_VUART_GCRB_HOST_SIRQ_MASK)
	return -EINVAL;
sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
```

But otherwise it looks okay, so

Reviewed-by: Andrew Jeffery <andrew at aj.id.au>

> +
> +	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
> +	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
> +	reg |= sirq;
> +	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
> +
> +	return 0;
> +}
> +
>  static ssize_t sirq_store(struct device *dev, struct device_attribute 
> *attr,
>  			  const char *buf, size_t count)
>  {
>  	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
>  	unsigned long val;
>  	int err;
> -	u8 reg;
>  
>  	err = kstrtoul(buf, 0, &val);
>  	if (err)
>  		return err;
>  
> -	val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
> -	val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
> -
> -	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
> -	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
> -	reg |= val;
> -	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
> -
> -	return count;
> +	err = aspeed_vuart_set_sirq(vuart, val);
> +	return err ? : count;
>  }
>  
>  static DEVICE_ATTR_RW(sirq);
> -- 
> 2.31.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


From zweiss at equinix.com  Fri Apr  9 06:07:11 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:07:11 +0000
Subject: [PATCH v2 15/21] ipmi: kcs_bmc: Don't enforce single-open policy
 in the kernel
In-Reply-To: <20210319062752.145730-15-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-15-andrew@aj.id.au>
Message-ID: <YG/g/poZLwO34QH7@packtop>

On Fri, Mar 19, 2021 at 01:27:46AM CDT, Andrew Jeffery wrote:
>Soon it will be possible for one KCS device to have multiple associated
>chardevs exposed to userspace (for IPMI and raw-style access). However,
>don't prevent userspace from:
>
>1. Opening more than one chardev at a time, or
>2. Opening the same chardev more than once.
>
>System behaviour is undefined for both classes of multiple access, so
>userspace must manage itself accordingly.
>
>The implementation delivers IBF and OBF events to the first chardev
>client to associate with the KCS device. An open on a related chardev
>cannot associate its client with the KCS device and so will not
>receive notification of events. However, any fd on any chardev may race
>their accesses to the data and status registers.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> drivers/char/ipmi/kcs_bmc.c         | 34 ++++++++++-------------------
> drivers/char/ipmi/kcs_bmc_aspeed.c  |  3 +--
> drivers/char/ipmi/kcs_bmc_npcm7xx.c |  3 +--
> 3 files changed, 14 insertions(+), 26 deletions(-)
>
>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>index 05bbb72418b2..2fafa9541934 100644
>--- a/drivers/char/ipmi/kcs_bmc.c
>+++ b/drivers/char/ipmi/kcs_bmc.c
>@@ -55,24 +55,12 @@ EXPORT_SYMBOL(kcs_bmc_update_status);
> int kcs_bmc_handle_event(struct kcs_bmc_device *kcs_bmc)
> {
> 	struct kcs_bmc_client *client;
>-	int rc;
>+	int rc = KCS_BMC_EVENT_NONE;
>
> 	spin_lock(&kcs_bmc->lock);
> 	client = kcs_bmc->client;
>-	if (client) {
>+	if (!WARN_ON_ONCE(!client))
> 		rc = client->ops->event(client);

The double-negation split by a macro seems a bit confusing to me
readability-wise; could we simplify to something like

	if (client)
		rc = client->ops->event(client);
	else
		WARN_ONCE();

?

>-	} else {
>-		u8 status;
>-
>-		status = kcs_bmc_read_status(kcs_bmc);
>-		if (status & KCS_BMC_STR_IBF) {
>-			/* Ack the event by reading the data */
>-			kcs_bmc_read_data(kcs_bmc);
>-			rc = KCS_BMC_EVENT_HANDLED;
>-		} else {
>-			rc = KCS_BMC_EVENT_NONE;
>-		}
>-	}
> 	spin_unlock(&kcs_bmc->lock);
>
> 	return rc;
>@@ -81,26 +69,28 @@ EXPORT_SYMBOL(kcs_bmc_handle_event);
>
> int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
> {
>-	int rc;
>-
> 	spin_lock_irq(&kcs_bmc->lock);
>-	if (kcs_bmc->client) {
>-		rc = -EBUSY;
>-	} else {
>+	if (!kcs_bmc->client) {
>+		u8 mask = KCS_BMC_EVENT_TYPE_IBF;
>+
> 		kcs_bmc->client = client;
>-		rc = 0;
>+		kcs_bmc_update_event_mask(kcs_bmc, mask, mask);
> 	}
> 	spin_unlock_irq(&kcs_bmc->lock);
>
>-	return rc;
>+	return 0;

Since this function appears to be infallible now, should it just return
void?  (Might be more churn than it's worth...shrug.)

> }
> EXPORT_SYMBOL(kcs_bmc_enable_device);
>
> void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
> {
> 	spin_lock_irq(&kcs_bmc->lock);
>-	if (client == kcs_bmc->client)
>+	if (client == kcs_bmc->client) {
>+		u8 mask = KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE;
>+
>+		kcs_bmc_update_event_mask(kcs_bmc, mask, 0);
> 		kcs_bmc->client = NULL;
>+	}
> 	spin_unlock_irq(&kcs_bmc->lock);
> }
> EXPORT_SYMBOL(kcs_bmc_disable_device);
>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>index 5f26471c038c..271845eb2e26 100644
>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>@@ -419,8 +419,7 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>
> 	platform_set_drvdata(pdev, priv);
>
>-	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
>-				   KCS_BMC_EVENT_TYPE_IBF);
>+	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
> 	aspeed_kcs_enable_channel(kcs_bmc, true);
>
> 	rc = kcs_bmc_add_device(&priv->kcs_bmc);
>diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>index c2032728a03d..fdf35cad2eba 100644
>--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>@@ -207,8 +207,7 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> 	if (rc)
> 		return rc;
>
>-	npcm7xx_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
>-				    KCS_BMC_EVENT_TYPE_IBF);
>+	npcm7xx_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
> 	npcm7xx_kcs_enable_channel(kcs_bmc, true);
>
> 	pr_info("channel=%u idr=0x%x odr=0x%x str=0x%x\n",
>-- 
>2.27.0
>

From andrew at aj.id.au  Fri Apr  9 06:14:54 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 14:44:54 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v5_3/4]_drivers/tty/serial/8250:_add_aspeed,
 _lpc-io?= =?UTF-8?Q?-reg_and_aspeed,_lpc-interrupts_DT_properties?=
In-Reply-To: <20210408011637.5361-4-zev@bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-4-zev@bewilderbeest.net>
Message-ID: <3eef2478-c5b8-4f14-a937-16bbe0a3e05a@www.fastmail.com>

Hi Zev,

A couple of minor comments:

On Thu, 8 Apr 2021, at 10:46, Zev Weiss wrote:
> These allow describing all the Aspeed VUART attributes currently
> available via sysfs.  aspeed,sirq

aspeed,lpc-interrupts now

> provides a replacement for the
> deprecated aspeed,sirq-polarity-sense property.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 44 ++++++++++++++++++++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c 
> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> index 8433f8dbb186..75ef006fa24b 100644
> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> @@ -28,6 +28,10 @@
>  #define ASPEED_VUART_ADDRL		0x28
>  #define ASPEED_VUART_ADDRH		0x2c
>  
> +#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
> +#define ASPEED_VUART_DEFAULT_SIRQ	4
> +#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
> +
>  struct aspeed_vuart {
>  	struct device		*dev;
>  	void __iomem		*regs;
> @@ -393,7 +397,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>  	struct aspeed_vuart *vuart;
>  	struct device_node *np;
>  	struct resource *res;
> -	u32 clk, prop;
> +	u32 clk, prop, sirq[2];
> +	bool sirq_polarity;
>  	int rc;
>  
>  	np = pdev->dev.of_node;
> @@ -501,6 +506,43 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>  		of_node_put(sirq_polarity_sense_args.np);
>  	}
>  
> +	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
> +	if (rc < 0)
> +		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
> +
> +	rc = aspeed_vuart_set_lpc_address(vuart, prop);
> +	if (rc < 0) {
> +		dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
> +		goto err_clk_disable;
> +	}
> +
> +	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
> +	if (rc < 0) {
> +		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
> +		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
> +	}
> +
> +	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
> +	if (rc < 0) {
> +		dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts > property\n");
> +		goto err_clk_disable;
> +	}
> +
> +	switch (sirq[1]) {
> +	case IRQ_TYPE_LEVEL_LOW:
> +		sirq_polarity = false;
> +		break;
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		sirq_polarity = true;
> +		break;
> +	default:
> +		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts 
> property\n");
> +		rc = -EINVAL;
> +		goto err_clk_disable;
> +	}

A bit ugly open-coding the mapping and error handling, maybe worth a helper?

Looks okay otherwise.

Cheers,

Andrew


From zweiss at equinix.com  Fri Apr  9 06:15:35 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:15:35 +0000
Subject: [PATCH v2 17/21] dt-bindings: ipmi: Convert ASPEED KCS binding to
 schema
In-Reply-To: <20210319062752.145730-17-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-17-andrew@aj.id.au>
Message-ID: <YG/i9lSxxCMIzkRs@packtop>

On Fri, Mar 19, 2021 at 01:27:48AM CDT, Andrew Jeffery wrote:
>Given the deprecated binding, improve the ability to detect issues in
>the platform devicetrees. Further, a subsequent patch will introduce a
>new interrupts property for specifying SerIRQ behaviour, so convert
>before we do any further additions.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 +++++++++++++++++++
> .../bindings/ipmi/aspeed-kcs-bmc.txt          | 33 -------
> 2 files changed, 92 insertions(+), 33 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
> delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>
>diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>new file mode 100644
>index 000000000000..697ca575454f
>--- /dev/null
>+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>@@ -0,0 +1,92 @@
>+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>+%YAML 1.2
>+---
>+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml
>+$schema: http://devicetree.org/meta-schemas/core.yaml
>+
>+title: ASPEED BMC KCS Devices
>+
>+maintainers:
>+  - Andrew Jeffery <andrew at aj.id.au>
>+
>+description: |
>+  The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS)
>+  interfaces on the LPC bus for in-band IPMI communication with their host.
>+
>+properties:
>+  compatible:
>+    oneOf:
>+      - description: Channel ID derived from reg
>+        items:
>+          enum:
>+            - aspeed,ast2400-kcs-bmc-v2
>+            - aspeed,ast2500-kcs-bmc-v2
>+            - aspeed,ast2600-kcs-bmc

Should this have a "-v2" suffix?

>+
>+      - description: Old-style with explicit channel ID, no reg
>+        deprecated: true
>+        items:
>+          enum:
>+            - aspeed,ast2400-kcs-bmc
>+            - aspeed,ast2500-kcs-bmc
>+
>+  interrupts:
>+    maxItems: 1
>+
>+  reg:
>+    # maxItems: 3
>+    items:
>+      - description: IDR register
>+      - description: ODR register
>+      - description: STR register
>+
>+  aspeed,lpc-io-reg:
>+    $ref: '/schemas/types.yaml#/definitions/uint32-array'
>+    minItems: 1
>+    maxItems: 2
>+    description: |
>+      The host CPU LPC IO data and status addresses for the device. For most
>+      channels the status address is derived from the data address, but the
>+      status address may be optionally provided.
>+
>+  kcs_chan:
>+    deprecated: true
>+    $ref: '/schemas/types.yaml#/definitions/uint32'
>+    description: The LPC channel number in the controller
>+
>+  kcs_addr:
>+    deprecated: true
>+    $ref: '/schemas/types.yaml#/definitions/uint32'
>+    description: The host CPU IO map address
>+
>+required:
>+  - compatible
>+  - interrupts
>+
>+additionalProperties: false
>+
>+allOf:
>+  - if:
>+      properties:
>+        compatible:
>+          contains:
>+            enum:
>+              - aspeed,ast2400-kcs-bmc
>+              - aspeed,ast2500-kcs-bmc
>+    then:
>+      required:
>+        - kcs_chan
>+        - kcs_addr
>+    else:
>+      required:
>+        - reg
>+        - aspeed,lpc-io-reg
>+
>+examples:
>+  - |
>+    kcs3: kcs at 24 {
>+        compatible = "aspeed,ast2600-kcs-bmc";

And likewise here.

>+        reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
>+        aspeed,lpc-io-reg = <0xca2>;
>+        interrupts = <8>;
>+    };
>diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>deleted file mode 100644
>index 193e71ca96b0..000000000000
>--- a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>+++ /dev/null
>@@ -1,33 +0,0 @@
>-# Aspeed KCS (Keyboard Controller Style) IPMI interface
>-
>-The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
>-(Baseboard Management Controllers) and the KCS interface can be
>-used to perform in-band IPMI communication with their host.
>-
>-## v1
>-Required properties:
>-- compatible : should be one of
>-    "aspeed,ast2400-kcs-bmc"
>-    "aspeed,ast2500-kcs-bmc"
>-- interrupts : interrupt generated by the controller
>-- kcs_chan : The LPC channel number in the controller
>-- kcs_addr : The host CPU IO map address
>-
>-## v2
>-Required properties:
>-- compatible : should be one of
>-    "aspeed,ast2400-kcs-bmc-v2"
>-    "aspeed,ast2500-kcs-bmc-v2"
>-- reg : The address and size of the IDR, ODR and STR registers
>-- interrupts : interrupt generated by the controller
>-- aspeed,lpc-io-reg : The host CPU LPC IO address for the device
>-
>-Example:
>-
>-    kcs3: kcs at 24 {
>-        compatible = "aspeed,ast2500-kcs-bmc-v2";
>-        reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
>-        aspeed,lpc-reg = <0xca2>;
>-        interrupts = <8>;
>-        status = "okay";
>-    };
>-- 
>2.27.0
>

From mani at kernel.org  Fri Apr  9 06:16:13 2021
From: mani at kernel.org (Manivannan Sadhasivam)
Date: Fri, 9 Apr 2021 10:46:13 +0530
Subject: [PATCH -next] mmc: owl-mmc: Remove unnecessary error log
In-Reply-To: <20210409023349.3325907-1-qiulaibin@huawei.com>
References: <20210409023349.3325907-1-qiulaibin@huawei.com>
Message-ID: <20210409051613.GA4376@work>

On Fri, Apr 09, 2021 at 10:33:49AM +0800, Laibin Qiu wrote:
> devm_ioremap_resource() has recorded error log, so it's
> unnecessary to record log again.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>

Reviewed-by: Manivannan Sadhasivam <mani at kernel.org>

Thanks,
Mani

> ---
>  drivers/mmc/host/owl-mmc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/owl-mmc.c b/drivers/mmc/host/owl-mmc.c
> index 5490962dc8e5..3dc143b03939 100644
> --- a/drivers/mmc/host/owl-mmc.c
> +++ b/drivers/mmc/host/owl-mmc.c
> @@ -581,7 +581,6 @@ static int owl_mmc_probe(struct platform_device *pdev)
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	owl_host->base = devm_ioremap_resource(&pdev->dev, res);
>  	if (IS_ERR(owl_host->base)) {
> -		dev_err(&pdev->dev, "Failed to remap registers\n");
>  		ret = PTR_ERR(owl_host->base);
>  		goto err_free_host;
>  	}
> -- 
> 2.25.1
> 


From zweiss at equinix.com  Fri Apr  9 06:17:28 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:17:28 +0000
Subject: [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device
 interface
In-Reply-To: <20210319062752.145730-16-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
Message-ID: <YG/jZyx3huwqewgX@packtop>

On Fri, Mar 19, 2021 at 01:27:47AM CDT, Andrew Jeffery wrote:
>The existing IPMI chardev encodes IPMI behaviours as the name suggests.
>However, KCS devices are useful beyond IPMI (or keyboards), as they
>provide a means to generate IRQs and exchange arbitrary data between a
>BMC and its host system.
>
>Implement a "raw" KCS character device that exposes the IDR, ODR and STR
>registers to userspace via read() and write() implemented on a character
>device:
>
>+--------+--------+---------+
>| Offset | read() | write() |
>+--------+--------+---------+
>|   0    |   IDR  |   ODR   |
>+--------+--------+---------+
>|   1    |   STR  |   STR   |
>+--------+--------+---------+
>
>This interface allows userspace to implement arbitrary (though somewhat
>inefficient) protocols for exchanging information between a BMC and host
>firmware. Conceptually the KCS interface can be used as an out-of-band
>machanism for interrupt-signaled control messages while bulk data

Typo ("mechanism")

>transfers occur over more appropriate interfaces between the BMC and the
>host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
>
>poll() is provided, which will wait for IBF or OBE conditions for data
>reads and writes respectively. Reads of STR on its own never blocks,
>though accessing both offsets in the one system call may block if the
>data registers are not ready.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>---
> Documentation/ABI/testing/dev-raw-kcs |  25 ++
> drivers/char/ipmi/Kconfig             |  17 +
> drivers/char/ipmi/Makefile            |   1 +
> drivers/char/ipmi/kcs_bmc_cdev_raw.c  | 443 ++++++++++++++++++++++++++
> 4 files changed, 486 insertions(+)
> create mode 100644 Documentation/ABI/testing/dev-raw-kcs
> create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c
>
>diff --git a/Documentation/ABI/testing/dev-raw-kcs b/Documentation/ABI/testing/dev-raw-kcs
>new file mode 100644
>index 000000000000..06e7e2071562
>--- /dev/null
>+++ b/Documentation/ABI/testing/dev-raw-kcs
>@@ -0,0 +1,25 @@
>+What:		/dev/raw-kcs*
>+Date:		2021-02-15
>+KernelVersion:	5.13
>+Contact:	openbmc at lists.ozlabs.org
>+Contact:	openipmi-developer at lists.sourceforge.net
>+Contact:	Andrew Jeffery <andrew at aj.id.au>
>+Description:	``/dev/raw-kcs*`` exposes to userspace the data and
>+		status registers of Keyboard-Controller-Style (KCS) IPMI
>+		interfaces via read() and write() syscalls. Direct
>+		exposure of the data and status registers enables
>+		inefficient but arbitrary protocols to be implemented
>+		over the device. A typical approach is to use KCS
>+		devices for out-of-band signalling for bulk data
>+		transfers over other interfaces between a Baseboard
>+		Management Controller and its host.
>+
>+		+--------+--------+---------+
>+		| Offset | read() | write() |
>+		+--------+--------+---------+
>+		|   0    |   IDR  |   ODR   |
>+		+--------+--------+---------+
>+		|   1    |   STR  |   STR   |
>+		+--------+--------+---------+
>+
>+Users:		libmctp: https://github.com/openbmc/libmctp
>diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
>index bc5f81899b62..273ac1a1f870 100644
>--- a/drivers/char/ipmi/Kconfig
>+++ b/drivers/char/ipmi/Kconfig
>@@ -137,6 +137,23 @@ config IPMI_KCS_BMC_CDEV_IPMI
> 	  This support is also available as a module. The module will be
> 	  called kcs_bmc_cdev_ipmi.
>
>+config IPMI_KCS_BMC_CDEV_RAW
>+	depends on IPMI_KCS_BMC
>+	tristate "Raw character device interface for BMC KCS devices"
>+	help
>+	  Provides a BMC-side character device directly exposing the
>+	  data and status registers of a KCS device to userspace. While
>+	  KCS devices are commonly used to implement IPMI message
>+	  passing, they provide a general interface for exchange of
>+	  interrupts, data and status information between the BMC and
>+	  its host.
>+
>+	  Say YES if you wish to use the KCS devices to implement
>+	  protocols that are not IPMI.
>+
>+	  This support is also available as a module. The module will be
>+	  called kcs_bmc_cdev_raw.
>+
> config ASPEED_BT_IPMI_BMC
> 	depends on ARCH_ASPEED || COMPILE_TEST
> 	depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
>diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>index fcfa676afddb..c8cc248ddd90 100644
>--- a/drivers/char/ipmi/Makefile
>+++ b/drivers/char/ipmi/Makefile
>@@ -24,6 +24,7 @@ obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o
>+obj-$(CONFIG_IPMI_KCS_BMC_CDEV_RAW) += kcs_bmc_cdev_raw.o
> obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_raw.c b/drivers/char/ipmi/kcs_bmc_cdev_raw.c
>new file mode 100644
>index 000000000000..bdd258648c8e
>--- /dev/null
>+++ b/drivers/char/ipmi/kcs_bmc_cdev_raw.c
>@@ -0,0 +1,443 @@
>+// SPDX-License-Identifier: GPL-2.0-or-later
>+/* Copyright (c) 2021 IBM Corp. */
>+
>+#include <linux/delay.h>
>+#include <linux/device.h>
>+#include <linux/errno.h>
>+#include <linux/fs.h>
>+#include <linux/list.h>
>+#include <linux/miscdevice.h>
>+#include <linux/module.h>
>+#include <linux/poll.h>
>+
>+#include "kcs_bmc_client.h"
>+
>+#define DEVICE_NAME "raw-kcs"
>+
>+struct kcs_bmc_raw {
>+	struct list_head entry;
>+
>+	struct kcs_bmc_client client;
>+
>+	wait_queue_head_t queue;
>+	u8 events;
>+	bool writable;
>+	bool readable;
>+	u8 idr;
>+
>+	struct miscdevice miscdev;
>+};
>+
>+static inline struct kcs_bmc_raw *client_to_kcs_bmc_raw(struct kcs_bmc_client *client)
>+{
>+	return container_of(client, struct kcs_bmc_raw, client);
>+}
>+
>+/* Call under priv->queue.lock */
>+static void kcs_bmc_raw_update_event_mask(struct kcs_bmc_raw *priv, u8 mask, u8 state)
>+{
>+	kcs_bmc_update_event_mask(priv->client.dev, mask, state);
>+	priv->events &= ~mask;
>+	priv->events |= state & mask;
>+}
>+
>+static int kcs_bmc_raw_event(struct kcs_bmc_client *client)
>+{
>+	struct kcs_bmc_raw *priv;
>+	struct device *dev;
>+	u8 status, handled;
>+
>+	priv = client_to_kcs_bmc_raw(client);
>+	dev = priv->miscdev.this_device;
>+
>+	spin_lock(&priv->queue.lock);
>+
>+	status = kcs_bmc_read_status(client->dev);
>+	handled = 0;
>+
>+	if ((priv->events & KCS_BMC_EVENT_TYPE_IBF) && (status & KCS_BMC_STR_IBF)) {
>+		if (priv->readable)
>+			dev_err(dev, "Storm brewing!");

That seems a *touch* cryptic...

>+
>+		dev_dbg(dev, "Disabling IDR events for back-pressure\n");
>+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_IBF, 0);
>+		priv->idr = kcs_bmc_read_data(client->dev);
>+		priv->readable = true;
>+
>+		dev_dbg(dev, "IDR read, waking waiters\n");
>+		wake_up_locked(&priv->queue);
>+
>+		handled |= KCS_BMC_EVENT_TYPE_IBF;
>+	}
>+
>+	if ((priv->events & KCS_BMC_EVENT_TYPE_OBE) && !(status & KCS_BMC_STR_OBF)) {
>+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
>+		priv->writable = true;
>+
>+		dev_dbg(dev, "ODR writable, waking waiters\n");
>+		wake_up_locked(&priv->queue);
>+
>+		handled |= KCS_BMC_EVENT_TYPE_OBE;
>+	}
>+
>+	spin_unlock(&priv->queue.lock);
>+
>+	return handled ? KCS_BMC_EVENT_HANDLED : KCS_BMC_EVENT_NONE;

Hm, if we're just treating it as a boolean here, is there any need to
muck around with setting specific bits of 'handled' in the if-blocks
above?

>+}
>+
>+static const struct kcs_bmc_client_ops kcs_bmc_raw_client_ops = {
>+	.event = kcs_bmc_raw_event,
>+};
>+
>+static inline struct kcs_bmc_raw *file_to_kcs_bmc_raw(struct file *filp)
>+{
>+	return container_of(filp->private_data, struct kcs_bmc_raw, miscdev);
>+}
>+
>+static int kcs_bmc_raw_open(struct inode *inode, struct file *filp)
>+{
>+	struct kcs_bmc_raw *priv = file_to_kcs_bmc_raw(filp);
>+
>+	return kcs_bmc_enable_device(priv->client.dev, &priv->client);
>+}
>+
>+static bool kcs_bmc_raw_prepare_obe(struct kcs_bmc_raw *priv)
>+{
>+	bool writable;
>+
>+	/* Enable the OBE event so we can catch the host clearing OBF */
>+	kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, KCS_BMC_EVENT_TYPE_OBE);
>+
>+	/* Now that we'll catch an OBE event, check if it's already occurred */
>+	writable = !(kcs_bmc_read_status(priv->client.dev) & KCS_BMC_STR_OBF);
>+
>+	/* If OBF is clear we've missed the OBE event, so disable it */
>+	if (writable)
>+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
>+
>+	return writable;
>+}
>+
>+static __poll_t kcs_bmc_raw_poll(struct file *filp, poll_table *wait)
>+{
>+	struct kcs_bmc_raw *priv;
>+	__poll_t events = 0;
>+
>+	priv = file_to_kcs_bmc_raw(filp);
>+
>+	poll_wait(filp, &priv->queue, wait);
>+
>+	spin_lock_irq(&priv->queue.lock);
>+	if (kcs_bmc_raw_prepare_obe(priv))
>+		events |= (EPOLLOUT | EPOLLWRNORM);
>+
>+	if (priv->readable || (kcs_bmc_read_status(priv->client.dev) & KCS_BMC_STR_IBF))
>+		events |= (EPOLLIN | EPOLLRDNORM);
>+	spin_unlock_irq(&priv->queue.lock);
>+
>+	return events;
>+}
>+
>+static ssize_t kcs_bmc_raw_read(struct file *filp, char __user *buf,
>+			     size_t count, loff_t *ppos)
>+{
>+	struct kcs_bmc_device *kcs_bmc;
>+	struct kcs_bmc_raw *priv;
>+	bool read_idr, read_str;
>+	struct device *dev;
>+	u8 idr, str;
>+	ssize_t rc;
>+
>+	priv = file_to_kcs_bmc_raw(filp);
>+	kcs_bmc = priv->client.dev;
>+	dev = priv->miscdev.this_device;
>+
>+	if (!count)
>+		return 0;
>+
>+	if (count > 2 || *ppos > 1)
>+		return -EINVAL;
>+
>+	if (*ppos + count > 2)
>+		return -EINVAL;
>+
>+	read_idr = (*ppos == 0);
>+	read_str = (*ppos == 1) || (count == 2);
>+
>+	spin_lock_irq(&priv->queue.lock);
>+	if (read_idr) {
>+		dev_dbg(dev, "Waiting for IBF\n");
>+		str = kcs_bmc_read_status(kcs_bmc);
>+		if ((filp->f_flags & O_NONBLOCK) && (str & KCS_BMC_STR_IBF)) {
>+			rc = -EWOULDBLOCK;
>+			goto out;
>+		}
>+
>+		rc = wait_event_interruptible_locked(priv->queue,
>+						     priv->readable || (str & KCS_BMC_STR_IBF));
>+		if (rc < 0)
>+			goto out;
>+
>+		if (signal_pending(current)) {
>+			dev_dbg(dev, "Interrupted waiting for IBF\n");
>+			rc = -EINTR;
>+			goto out;
>+		}
>+
>+		/*
>+		 * Re-enable events prior to possible read of IDR (which clears
>+		 * IBF) to ensure we receive interrupts for subsequent writes
>+		 * to IDR. Writes to IDR by the host should not occur while IBF
>+		 * is set.
>+		 */
>+		dev_dbg(dev, "Woken by IBF, enabling IRQ\n");
>+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_IBF,
>+					      KCS_BMC_EVENT_TYPE_IBF);
>+
>+		/* Read data out of IDR into internal storage if necessary */
>+		if (!priv->readable) {
>+			WARN(!(str & KCS_BMC_STR_IBF), "Unknown reason for wakeup!");
>+
>+			priv->idr = kcs_bmc_read_data(kcs_bmc);
>+		}
>+
>+		/* Copy data from internal storage to userspace */
>+		idr = priv->idr;
>+
>+		/* We're done consuming the internally stored value */
>+		priv->readable = false;
>+	}
>+
>+	if (read_str) {
>+		str = kcs_bmc_read_status(kcs_bmc);
>+		if (*ppos == 0 || priv->readable)
>+			/*
>+			 * If we got this far with `*ppos == 0` then we've read
>+			 * data out of IDR, so set IBF when reporting back to
>+			 * userspace so userspace knows the IDR value is valid.
>+			 */
>+			str |= KCS_BMC_STR_IBF;
>+
>+		dev_dbg(dev, "Read status 0x%x\n", str);
>+
>+	}
>+
>+	rc = count;
>+out:
>+	spin_unlock_irq(&priv->queue.lock);
>+
>+	if (rc < 0)
>+		return rc;
>+
>+	/* Now copy the data in to the userspace buffer */
>+
>+	if (read_idr)
>+		if (copy_to_user(buf++, &idr, sizeof(idr)))
>+			return -EFAULT;
>+
>+	if (read_str)
>+		if (copy_to_user(buf, &str, sizeof(str)))
>+			return -EFAULT;
>+
>+	return count;
>+}
>+
>+static ssize_t kcs_bmc_raw_write(struct file *filp, const char __user *buf,
>+			      size_t count, loff_t *ppos)
>+{
>+	struct kcs_bmc_device *kcs_bmc;
>+	bool write_odr, write_str;
>+	struct kcs_bmc_raw *priv;
>+	struct device *dev;
>+	uint8_t data[2];
>+	ssize_t result;
>+	u8 str;
>+
>+	priv = file_to_kcs_bmc_raw(filp);
>+	kcs_bmc = priv->client.dev;
>+	dev = priv->miscdev.this_device;
>+
>+	if (!count)
>+		return count;
>+
>+	if (count > 2)
>+		return -EINVAL;
>+
>+	if (*ppos >= 2)
>+		return -EINVAL;
>+
>+	if (*ppos + count > 2)
>+		return -EINVAL;
>+
>+	if (copy_from_user(data, buf, count))
>+		return -EFAULT;
>+
>+	write_odr = (*ppos == 0);
>+	write_str = (*ppos == 1) || (count == 2);
>+
>+	spin_lock_irq(&priv->queue.lock);
>+
>+	/* Always write status before data, we generate the SerIRQ by writing ODR */
>+	if (write_str) {
>+		/* The index of STR in the userspace buffer depends on whether ODR is written */
>+		str = data[*ppos == 0];
>+		if (!(str & KCS_BMC_STR_OBF))
>+			dev_warn(dev, "Clearing OBF with status write: 0x%x\n", str);
>+		dev_dbg(dev, "Writing status 0x%x\n", str);
>+		kcs_bmc_write_status(kcs_bmc, str);
>+	}
>+
>+	if (write_odr) {
>+		/* If we're writing ODR it's always the first byte in the buffer */
>+		u8 odr = data[0];
>+
>+		str = kcs_bmc_read_status(kcs_bmc);
>+		if (str & KCS_BMC_STR_OBF) {
>+			if (filp->f_flags & O_NONBLOCK) {
>+				result = -EWOULDBLOCK;
>+				goto out;
>+			}
>+
>+			priv->writable = kcs_bmc_raw_prepare_obe(priv);
>+
>+			/* Now either OBF is already clear, or we'll get an OBE event to wake us */
>+			dev_dbg(dev, "Waiting for OBF to clear\n");
>+			wait_event_interruptible_locked(priv->queue, priv->writable);
>+
>+			if (signal_pending(current)) {
>+				kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
>+				result = -EINTR;
>+				goto out;
>+			}
>+
>+			WARN_ON(kcs_bmc_read_status(kcs_bmc) & KCS_BMC_STR_OBF);
>+		}
>+
>+		dev_dbg(dev, "Writing 0x%x to ODR\n", odr);
>+		kcs_bmc_write_data(kcs_bmc, odr);
>+	}
>+
>+	result = count;
>+out:
>+	spin_unlock_irq(&priv->queue.lock);
>+
>+	return result;
>+}
>+
>+static int kcs_bmc_raw_release(struct inode *inode, struct file *filp)
>+{
>+	struct kcs_bmc_raw *priv = file_to_kcs_bmc_raw(filp);
>+
>+	kcs_bmc_disable_device(priv->client.dev, &priv->client);
>+
>+	return 0;
>+}
>+
>+static const struct file_operations kcs_bmc_raw_fops = {
>+	.owner          = THIS_MODULE,
>+	.open		= kcs_bmc_raw_open,
>+	.llseek		= no_seek_end_llseek,
>+	.read           = kcs_bmc_raw_read,
>+	.write          = kcs_bmc_raw_write,
>+	.poll		= kcs_bmc_raw_poll,
>+	.release	= kcs_bmc_raw_release,
>+};
>+
>+static DEFINE_SPINLOCK(kcs_bmc_raw_instances_lock);
>+static LIST_HEAD(kcs_bmc_raw_instances);
>+
>+static int kcs_bmc_raw_attach_cdev(struct kcs_bmc_device *kcs_bmc)
>+{
>+	struct kcs_bmc_raw *priv;
>+	int rc;
>+
>+	priv = devm_kzalloc(kcs_bmc->dev, sizeof(*priv), GFP_KERNEL);
>+	if (!priv)
>+		return -ENOMEM;
>+
>+	priv->client.dev = kcs_bmc;
>+	priv->client.ops = &kcs_bmc_raw_client_ops;
>+
>+	init_waitqueue_head(&priv->queue);
>+	priv->writable = false;
>+	priv->readable = false;
>+
>+	priv->miscdev.minor = MISC_DYNAMIC_MINOR;
>+	priv->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u", DEVICE_NAME,
>+					   kcs_bmc->channel);
>+	if (!priv->miscdev.name)
>+		return -EINVAL;
>+
>+	priv->miscdev.fops = &kcs_bmc_raw_fops;
>+
>+	/* Initialise our expected events. Listen for IBF but ignore OBE until necessary */
>+	kcs_bmc_raw_update_event_mask(priv, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
>+				      KCS_BMC_EVENT_TYPE_IBF);
>+
>+	rc = misc_register(&priv->miscdev);
>+	if (rc) {
>+		dev_err(kcs_bmc->dev, "Unable to register device\n");
>+		return rc;
>+	}
>+
>+	spin_lock_irq(&kcs_bmc_raw_instances_lock);
>+	list_add(&priv->entry, &kcs_bmc_raw_instances);
>+	spin_unlock_irq(&kcs_bmc_raw_instances_lock);
>+
>+	dev_info(kcs_bmc->dev, "Initialised raw client for channel %d", kcs_bmc->channel);
>+
>+	return 0;
>+}
>+
>+static int kcs_bmc_raw_detach_cdev(struct kcs_bmc_device *kcs_bmc)
>+{
>+	struct kcs_bmc_raw *priv = NULL, *pos;
>+
>+	spin_lock_irq(&kcs_bmc_raw_instances_lock);
>+	list_for_each_entry(pos, &kcs_bmc_raw_instances, entry) {
>+		if (pos->client.dev == kcs_bmc) {
>+			priv = pos;
>+			list_del(&pos->entry);
>+			break;
>+		}
>+	}
>+	spin_unlock_irq(&kcs_bmc_raw_instances_lock);
>+
>+	if (!priv)
>+		return 0;

Similarly to patch #12, might we want to indicate some sort of failure
here, or is this a normal/expected case?

>+
>+	misc_deregister(&priv->miscdev);
>+	kcs_bmc_disable_device(kcs_bmc, &priv->client);
>+	devm_kfree(priv->client.dev->dev, priv);
>+
>+	return 0;
>+}
>+
>+static const struct kcs_bmc_cdev_ops kcs_bmc_raw_cdev_ops = {
>+	.add_device = kcs_bmc_raw_attach_cdev,
>+	.remove_device = kcs_bmc_raw_detach_cdev,
>+};
>+
>+static struct kcs_bmc_cdev kcs_bmc_raw_cdev = {
>+	.ops = &kcs_bmc_raw_cdev_ops,
>+};
>+
>+static int kcs_bmc_raw_init(void)
>+{
>+	return kcs_bmc_register_cdev(&kcs_bmc_raw_cdev);
>+}
>+module_init(kcs_bmc_raw_init);
>+
>+static void kcs_bmc_raw_exit(void)
>+{
>+	int rc;
>+
>+	rc = kcs_bmc_unregister_cdev(&kcs_bmc_raw_cdev);
>+	if (rc)
>+		pr_warn("Failed to remove KCS BMC client: %d", rc);
>+}
>+module_exit(kcs_bmc_raw_exit);
>+
>+MODULE_LICENSE("GPL v2");
>+MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
>+MODULE_DESCRIPTION("Character device for raw access to a KCS device");
>-- 
>2.27.0
>

From andrew at aj.id.au  Fri Apr  9 06:24:08 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 14:54:08 +0930
Subject: [PATCH v2 01/21] dt-bindings: aspeed-lpc: Remove LPC partitioning
In-Reply-To: <CACPK8Xdw3+2Rt=tQ-ciusyK=W6BaP_DR4FSFp0qDuPq5z8MPBQ@mail.gmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <CACPK8Xdw3+2Rt=tQ-ciusyK=W6BaP_DR4FSFp0qDuPq5z8MPBQ@mail.gmail.com>
Message-ID: <a181f404-ea59-4956-abe3-60d0bee917d2@www.fastmail.com>



On Fri, 9 Apr 2021, at 12:48, Joel Stanley wrote:
> On Fri, 19 Mar 2021 at 06:28, Andrew Jeffery <andrew at aj.id.au> wrote:
> >
> > From: "Chia-Wei, Wang" <chiawei_wang at aspeedtech.com>
> >
> > The LPC controller has no concept of the BMC and the Host partitions.
> > This patch fixes the documentation by removing the description on LPC
> > partitions. The register offsets illustrated in the DTS node examples
> > are also fixed to adapt to the LPC DTS change.
> 
> Is this accurate:
> 
>  The node examples change their reg address to be an offset from the
> LPC HC to be an offset from the base of the LPC region.

Everything becomes based from the start of the LPC region, yes.

Andrew


From rafal at milecki.pl  Fri Apr  9 06:27:36 2021
From: rafal at milecki.pl (=?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?=)
Date: Fri, 09 Apr 2021 07:27:36 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <632cbdec-e477-212c-f5a8-81151915fdeb@gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <632cbdec-e477-212c-f5a8-81151915fdeb@gmail.com>
Message-ID: <903fdcef324310c97627ada4bbc77ebb@milecki.pl>

On 2021-04-09 05:37, Florian Fainelli wrote:
> On 4/8/2021 8:08 AM, Arnd Bergmann wrote:
>> Greetings to all Arm platform maintainers,
>> 
>> I've just gone through the DT merges I've received so far and, with a
>> little help from Rob,
>> managed to run 'make dtbs_check W=1' before and after, to see what
>> warnings we get.
>> The good news is that the number of warnings is going down, but
>> unfortunately there
>> is still an unmanageable amount of remaining warnings, and some new
>> ones crept in.
>> 
>> I'm still working on my tooling for this, to catch these better, but
>> ideally I think we should
>> try to not introduce new warnings. I think some platforms are already
>> clean, and I did
>> not see any new warnings for mvebu, samsung and broadcom. There were a 
>> lot of
>> warnings from .dtsi files, and I probably did an incomplete job at
>> deduplicating those.
> 
> There are definitively a ton of warnings for Broacom DTS files, a 
> number
> of those warnings exist because the bindings were not converted to 
> YAML.
> Rafal, do you think you could help me with taking care of the
> BCM5301X/4908 warnings?

Sure, I got rid of one or two warnings already, I'll keep working on 
that.


From ikjn at chromium.org  Fri Apr  9 06:32:04 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Fri, 9 Apr 2021 13:32:04 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <CAATdQgCQ5Gm1CNEbVgLFiFcgDX0yP5G=48Fa29WYbpSuz25WXg@mail.gmail.com>

Hi Chunfeng,

On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
>
> When the dedicated wake irq is level trigger, enable it before
> calling runtime_suspend, will trigger an interrupt.
>
> e.g.
> for a low level trigger type, it's low level at running time (0),
> and becomes high level when enters suspend (runtime_suspend (1) is
> called), a wakeup signal at (2) make it become low level, wake irq
> will be triggered.
>
>                 ------------------
>                |           ^     ^|
> ----------------           |     | --------------
>  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
>

Can't we just use a falling edge type for this irq line?

> if we enable the wake irq before calling runtime_suspend during (0),
> an interrupt will arise, it causes resume immediately;
> enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
> will works.
>
> This patch seems no side effect on edge trigger wake irq.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/base/power/runtime.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index a46a7e30881b..796739a015a5 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>         __update_runtime_status(dev, RPM_SUSPENDING);
>
>         callback = RPM_GET_CALLBACK(dev, runtime_suspend);
> -
> -       dev_pm_enable_wake_irq_check(dev, true);
>         retval = rpm_callback(callback, dev);
>         if (retval)
>                 goto fail;
>
> +       dev_pm_enable_wake_irq_check(dev, true);
> +
>   no_callback:
>         __update_runtime_status(dev, RPM_SUSPENDED);
>         pm_runtime_deactivate_timer(dev);
> @@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>         return retval;
>
>   fail:
> -       dev_pm_disable_wake_irq_check(dev);
>         __update_runtime_status(dev, RPM_ACTIVE);
>         dev->power.deferred_resume = false;
>         wake_up_all(&dev->power.wait_queue);
> --
> 2.18.0
>


From zweiss at equinix.com  Fri Apr  9 06:32:01 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:32:01 +0000
Subject: [PATCH v2 07/21] ipmi: kcs_bmc: Make status update atomic
In-Reply-To: <20210319062752.145730-7-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-7-andrew@aj.id.au>
Message-ID: <YG/m0Hh4BRGRnm7u@packtop>

On Fri, Mar 19, 2021 at 01:27:38AM CDT, Andrew Jeffery wrote:
>Enable more efficient implementation of read-modify-write sequences.
>Both device drivers for the KCS BMC stack use regmaps. The new callback
>allows us to exploit regmap_update_bits().
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From andrew at aj.id.au  Fri Apr  9 06:33:10 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:03:10 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_17/21]_dt-bindings:_ipmi:_Convert_ASPEED_KCS_bin?=
 =?UTF-8?Q?ding_to_schema?=
In-Reply-To: <YG/i9lSxxCMIzkRs@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-17-andrew@aj.id.au> <YG/i9lSxxCMIzkRs@packtop>
Message-ID: <29937129-3a17-4a32-a723-191b693a1e0c@www.fastmail.com>



On Fri, 9 Apr 2021, at 14:45, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:48AM CDT, Andrew Jeffery wrote:
> >Given the deprecated binding, improve the ability to detect issues in
> >the platform devicetrees. Further, a subsequent patch will introduce a
> >new interrupts property for specifying SerIRQ behaviour, so convert
> >before we do any further additions.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 +++++++++++++++++++
> > .../bindings/ipmi/aspeed-kcs-bmc.txt          | 33 -------
> > 2 files changed, 92 insertions(+), 33 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
> > delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
> >
> >diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
> >new file mode 100644
> >index 000000000000..697ca575454f
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
> >@@ -0,0 +1,92 @@
> >+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >+%YAML 1.2
> >+---
> >+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml
> >+$schema: http://devicetree.org/meta-schemas/core.yaml
> >+
> >+title: ASPEED BMC KCS Devices
> >+
> >+maintainers:
> >+  - Andrew Jeffery <andrew at aj.id.au>
> >+
> >+description: |
> >+  The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS)
> >+  interfaces on the LPC bus for in-band IPMI communication with their host.
> >+
> >+properties:
> >+  compatible:
> >+    oneOf:
> >+      - description: Channel ID derived from reg
> >+        items:
> >+          enum:
> >+            - aspeed,ast2400-kcs-bmc-v2
> >+            - aspeed,ast2500-kcs-bmc-v2
> >+            - aspeed,ast2600-kcs-bmc
> 
> Should this have a "-v2" suffix?

Well, that was kind of a matter of perspective. The 2600 compatible was 
added after we'd done the v2 of the binding for the 2400 and 2500 so it 
never needed correcting. But it is a case of "don't use the deprecated 
properties with the 2600 compatible".

I don't think a change is necessary?

Cheers,

Andrew


From zweiss at equinix.com  Fri Apr  9 06:33:30 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:33:30 +0000
Subject: [PATCH v2 08/21] ipmi: kcs_bmc: Rename {read, write}_{status,
 data}() functions
In-Reply-To: <20210319062752.145730-8-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-8-andrew@aj.id.au>
Message-ID: <YG/nKd3ERFYPoLhZ@packtop>

On Fri, Mar 19, 2021 at 01:27:39AM CDT, Andrew Jeffery wrote:
>Rename the functions in preparation for separating the IPMI chardev out
>from the KCS BMC core.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From nadeem at cadence.com  Fri Apr  9 06:38:32 2021
From: nadeem at cadence.com (Nadeem Athani)
Date: Fri, 9 Apr 2021 07:38:32 +0200
Subject: [PATCH] PCI: cadence: LTSSM Detect Quiet state minimum delay setting.
Message-ID: <20210409053832.29512-1-nadeem@cadence.com>

Adding a quirk flag "quirk_detect_quiet_flag" to program the minimum time
that LTSSM waits on entering Detect.Quiet state.
Setting this to 2ms for TI j721e SOC as a workaround to resolve a bug in
IP.
In future revisions this setting will not be required.

As per PCIe specification, all Receivers must meet the Z-RX-DC
specification for 2.5 GT/s within 1ms of entering Detect.Quiet LTSSM
substate. The LTSSM must stay in this substate until the ZRXDC
specification for 2.5 GT/s is met.

00 : 0us minimum wait time in Detect.Quiet state.
01 : 100us minimum wait time in Detect.Quiet state.
10 : 1ms minimum wait time in Detect.Quiet state.
11 : 2ms minimum wait time in Detect.Quiet state.

Signed-off-by: Nadeem Athani <nadeem at cadence.com>
---
 drivers/pci/controller/cadence/pci-j721e.c         |  6 ++++++
 drivers/pci/controller/cadence/pcie-cadence-ep.c   | 21 +++++++++++++++++++++
 drivers/pci/controller/cadence/pcie-cadence-host.c | 21 +++++++++++++++++++++
 drivers/pci/controller/cadence/pcie-cadence.h      | 12 ++++++++++++
 4 files changed, 60 insertions(+)

diff --git a/drivers/pci/controller/cadence/pci-j721e.c b/drivers/pci/controller/cadence/pci-j721e.c
index 35e61048e133..40ebe698e179 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -67,6 +67,7 @@ enum j721e_pcie_mode {
 struct j721e_pcie_data {
 	enum j721e_pcie_mode	mode;
 	bool quirk_retrain_flag;
+	bool quirk_detect_quiet_flag;
 };
 
 static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
@@ -284,10 +285,12 @@ static struct pci_ops cdns_ti_pcie_host_ops = {
 static const struct j721e_pcie_data j721e_pcie_rc_data = {
 	.mode = PCI_MODE_RC,
 	.quirk_retrain_flag = true,
+	.quirk_detect_quiet_flag = true,
 };
 
 static const struct j721e_pcie_data j721e_pcie_ep_data = {
 	.mode = PCI_MODE_EP,
+	.quirk_detect_quiet_flag = true,
 };
 
 static const struct of_device_id of_j721e_pcie_match[] = {
@@ -394,6 +397,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
 		bridge->ops = &cdns_ti_pcie_host_ops;
 		rc = pci_host_bridge_priv(bridge);
 		rc->quirk_retrain_flag = data->quirk_retrain_flag;
+		rc->quirk_detect_quiet_flag = data->quirk_detect_quiet_flag;
 
 		cdns_pcie = &rc->pcie;
 		cdns_pcie->dev = dev;
@@ -460,6 +464,8 @@ static int j721e_pcie_probe(struct platform_device *pdev)
 			goto err_get_sync;
 		}
 
+		ep->quirk_detect_quiet_flag = data->quirk_detect_quiet_flag;
+
 		cdns_pcie = &ep->pcie;
 		cdns_pcie->dev = dev;
 		cdns_pcie->ops = &j721e_pcie_ops;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 897cdde02bd8..245771f03c21 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -552,6 +552,23 @@ static const struct pci_epc_ops cdns_pcie_epc_ops = {
 	.get_features	= cdns_pcie_ep_get_features,
 };
 
+static void cdns_pcie_detect_quiet_min_delay_set(struct cdns_pcie_ep *ep)
+{
+	struct cdns_pcie *pcie = &ep->pcie;
+	u32 delay = 0x3;
+	u32 ltssm_control_cap;
+
+	/*
+	 * Set the LTSSM Detect Quiet state min. delay to 2ms.
+	 */
+
+	ltssm_control_cap = cdns_pcie_readl(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP);
+	ltssm_control_cap = ((ltssm_control_cap &
+			    ~CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK) |
+			    CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay));
+
+	cdns_pcie_writel(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP, ltssm_control_cap);
+}
 
 int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 {
@@ -623,6 +640,10 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 	ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE;
 	/* Reserve region 0 for IRQs */
 	set_bit(0, &ep->ob_region_map);
+
+	if (ep->quirk_detect_quiet_flag)
+		cdns_pcie_detect_quiet_min_delay_set(ep);
+
 	spin_lock_init(&ep->lock);
 
 	return 0;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 73dcf8cf98fb..0ed2bfac4855 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -461,6 +461,24 @@ static int cdns_pcie_host_init(struct device *dev,
 	return cdns_pcie_host_init_address_translation(rc);
 }
 
+static void cdns_pcie_detect_quiet_min_delay_set(struct cdns_pcie_rc *rc)
+{
+	struct cdns_pcie *pcie = &rc->pcie;
+	u32 delay = 0x3;
+	u32 ltssm_control_cap;
+
+	/*
+	 * Set the LTSSM Detect Quiet state min. delay to 2ms.
+	 */
+
+	ltssm_control_cap = cdns_pcie_readl(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP);
+	ltssm_control_cap = ((ltssm_control_cap &
+			    ~CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK) |
+			    CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay));
+
+	cdns_pcie_writel(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP, ltssm_control_cap);
+}
+
 int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
 {
 	struct device *dev = rc->pcie.dev;
@@ -497,6 +515,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
 		return PTR_ERR(rc->cfg_base);
 	rc->cfg_res = res;
 
+	if (rc->quirk_detect_quiet_flag)
+		cdns_pcie_detect_quiet_min_delay_set(rc);
+
 	ret = cdns_pcie_start_link(pcie);
 	if (ret) {
 		dev_err(dev, "Failed to start link\n");
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
index 254d2570f8c9..d074475fe887 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -189,6 +189,14 @@
 /* AXI link down register */
 #define CDNS_PCIE_AT_LINKDOWN (CDNS_PCIE_AT_BASE + 0x0824)
 
+/* LTSSM Capabilities register */
+#define CDNS_PCIE_LTSSM_CONTROL_CAP             (CDNS_PCIE_LM_BASE + 0x0054)
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK  GENMASK(2, 1)
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT 1
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay) \
+	 (((delay) << CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT) & \
+	 CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK)
+
 enum cdns_pcie_rp_bar {
 	RP_BAR_UNDEFINED = -1,
 	RP_BAR0,
@@ -292,6 +300,7 @@ struct cdns_pcie {
  * @avail_ib_bar: Satus of RP_BAR0, RP_BAR1 and	RP_NO_BAR if it's free or
  *                available
  * @quirk_retrain_flag: Retrain link as quirk for PCIe Gen2
+ * @quirk_detect_quiet_flag: LTSSM Detect Quiet min delay set as quirk
  */
 struct cdns_pcie_rc {
 	struct cdns_pcie	pcie;
@@ -301,6 +310,7 @@ struct cdns_pcie_rc {
 	u32			device_id;
 	bool			avail_ib_bar[CDNS_PCIE_RP_MAX_IB];
 	bool                    quirk_retrain_flag;
+	bool			quirk_detect_quiet_flag;
 };
 
 /**
@@ -331,6 +341,7 @@ struct cdns_pcie_epf {
  *        registers fields (RMW) accessible by both remote RC and EP to
  *        minimize time between read and write
  * @epf: Structure to hold info about endpoint function
+ * @quirk_detect_quiet_flag: LTSSM Detect Quiet min delay set as quirk
  */
 struct cdns_pcie_ep {
 	struct cdns_pcie	pcie;
@@ -345,6 +356,7 @@ struct cdns_pcie_ep {
 	/* protect writing to PCI_STATUS while raising legacy interrupts */
 	spinlock_t		lock;
 	struct cdns_pcie_epf	*epf;
+	bool                    quirk_detect_quiet_flag;
 };
 
 
-- 
2.15.0



From tony at atomide.com  Fri Apr  9 06:39:18 2021
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 9 Apr 2021 08:39:18 +0300
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <1617933211.12105.22.camel@mhfsdcap03>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
 <1617933211.12105.22.camel@mhfsdcap03>
Message-ID: <YG/ohhh3Tyet6InQ@atomide.com>

* Chunfeng Yun <chunfeng.yun at mediatek.com> [210409 01:54]:
> On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote:
> > On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > >
> > > When the dedicated wake irq is level trigger, enable it before
> > > calling runtime_suspend, will trigger an interrupt.
> > >
> > > e.g.
> > > for a low level trigger type, it's low level at running time (0),
> > > and becomes high level when enters suspend (runtime_suspend (1) is
> > > called), a wakeup signal at (2) make it become low level, wake irq
> > > will be triggered.
> > >
> > >                 ------------------
> > >                |           ^     ^|
> > > ----------------           |     | --------------
> > >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> > >
> > > if we enable the wake irq before calling runtime_suspend during (0),
> > > an interrupt will arise, it causes resume immediately;
> > 
> > But that's necessary to avoid missing a wakeup interrupt, isn't it?
> That's also what I worry about.

Yeah sounds like this patch will lead into missed wakeirqs.

Regards,

Tony


From andrew at aj.id.au  Fri Apr  9 06:39:30 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:09:30 +0930
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <CACPK8Xc5HC7TZ6cUDH6+uHQO1LQCZE0YeENua1sE8nDXs0R2mg@mail.gmail.com>
References: <20210319061952.145040-1-andrew@aj.id.au>
 <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
 <20210408121441.GG7166@minyard.net>
 <6ff29d26-543a-4790-abb4-ebaa3f8d0265@www.fastmail.com>
 <CACPK8Xc5HC7TZ6cUDH6+uHQO1LQCZE0YeENua1sE8nDXs0R2mg@mail.gmail.com>
Message-ID: <b718a500-87e9-4958-a15f-56e024837ec8@www.fastmail.com>

On Fri, 9 Apr 2021, at 13:37, Joel Stanley wrote:
> On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew at aj.id.au> wrote:
> > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote:
> > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote:
> 
> > > > > 1. It begins with patches 1-5 put together by Chia-Wei, which I've
> > > > > rebased on v5.12-rc2. These fix the ASPEED LPC bindings and other
> > > > > non-KCS LPC-related ASPEED device drivers in a way that enables the
> > > > > SerIRQ patches at the end of the series. With Joel's review I'm hoping
> > > > > these 5 can go through the aspeed tree, and that the rest can go through
> > > > > the IPMI tree.
> 
> > > > >
> > > > > Please review!
> > > >
> > > > Unfortunately the cover letter got detached from the rest of the series.
> > > >
> > > > Any chance you can take a look at the patches?
> > >
> > > There were some minor concerns that were unanswered, and there really
> > > was no review by others for many of the patches.
> >
> > Right; I was planning to clean up the minor concerns once I'd received
> > some more feedback. I could have done a better job of communicating
> > that :)
> 
> I'll merge the first five through the aspeed tree this coming merge
> window. We have acks from the relevant maintainers.
> 
> Arnd: would you prefer that this come as it's own pull request, or as
> part of the device tree branch?
> 
> Andrew, Corey: once I've got my pull requests out I'll look at
> reviewing the rest of the series. Perhaps it would pay to re-send that
> hunk of patches Andrew with the nits fixed?

Yep; Zev has done some reviews for me so I'll address those, rebase on 
your tree once you've sent out the pull-req and send out a v3.

Corey: Are you okay with that for now?

Cheers,

Andrew


From zweiss at equinix.com  Fri Apr  9 06:40:06 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:40:06 +0000
Subject: [PATCH v2 20/21] ipmi: kcs_bmc_aspeed: Fix IBFIE typo from
 datasheet
In-Reply-To: <20210319062752.145730-20-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-20-andrew@aj.id.au>
Message-ID: <YG/otW6XwZFT6fPy@packtop>

On Fri, Mar 19, 2021 at 01:27:51AM CDT, Andrew Jeffery wrote:
>Input Buffer Full Interrupt Enable (IBFIE) is typoed as IBFIF for some
>registers in the datasheet. Fix the driver to use the sensible acronym.
>
>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From tony at atomide.com  Fri Apr  9 06:40:36 2021
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 9 Apr 2021 08:40:36 +0300
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <CAATdQgCQ5Gm1CNEbVgLFiFcgDX0yP5G=48Fa29WYbpSuz25WXg@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAATdQgCQ5Gm1CNEbVgLFiFcgDX0yP5G=48Fa29WYbpSuz25WXg@mail.gmail.com>
Message-ID: <YG/o1ERNkcaYAV9y@atomide.com>

* Ikjoon Jang <ikjn at chromium.org> [210409 05:33]:
> Hi Chunfeng,
> 
> On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > When the dedicated wake irq is level trigger, enable it before
> > calling runtime_suspend, will trigger an interrupt.
> >
> > e.g.
> > for a low level trigger type, it's low level at running time (0),
> > and becomes high level when enters suspend (runtime_suspend (1) is
> > called), a wakeup signal at (2) make it become low level, wake irq
> > will be triggered.
> >
> >                 ------------------
> >                |           ^     ^|
> > ----------------           |     | --------------
> >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> >
> 
> Can't we just use a falling edge type for this irq line?

Sounds reasonable to me :)

Tony


From zweiss at equinix.com  Fri Apr  9 06:44:05 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 05:44:05 +0000
Subject: [PATCH v2 17/21] dt-bindings: ipmi: Convert ASPEED KCS binding to
 schema
In-Reply-To: <29937129-3a17-4a32-a723-191b693a1e0c@www.fastmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-17-andrew@aj.id.au> <YG/i9lSxxCMIzkRs@packtop>
 <29937129-3a17-4a32-a723-191b693a1e0c@www.fastmail.com>
Message-ID: <YG/ppKEAs5EBUao3@packtop>

On Fri, Apr 09, 2021 at 12:33:10AM CDT, Andrew Jeffery wrote:
>
>
>On Fri, 9 Apr 2021, at 14:45, Zev Weiss wrote:
>> On Fri, Mar 19, 2021 at 01:27:48AM CDT, Andrew Jeffery wrote:
>> >Given the deprecated binding, improve the ability to detect issues in
>> >the platform devicetrees. Further, a subsequent patch will introduce a
>> >new interrupts property for specifying SerIRQ behaviour, so convert
>> >before we do any further additions.
>> >
>> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>> >---
>> > .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 +++++++++++++++++++
>> > .../bindings/ipmi/aspeed-kcs-bmc.txt          | 33 -------
>> > 2 files changed, 92 insertions(+), 33 deletions(-)
>> > create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>> > delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>> >
>> >diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>> >new file mode 100644
>> >index 000000000000..697ca575454f
>> >--- /dev/null
>> >+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>> >@@ -0,0 +1,92 @@
>> >+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> >+%YAML 1.2
>> >+---
>> >+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml
>> >+$schema: http://devicetree.org/meta-schemas/core.yaml
>> >+
>> >+title: ASPEED BMC KCS Devices
>> >+
>> >+maintainers:
>> >+  - Andrew Jeffery <andrew at aj.id.au>
>> >+
>> >+description: |
>> >+  The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS)
>> >+  interfaces on the LPC bus for in-band IPMI communication with their host.
>> >+
>> >+properties:
>> >+  compatible:
>> >+    oneOf:
>> >+      - description: Channel ID derived from reg
>> >+        items:
>> >+          enum:
>> >+            - aspeed,ast2400-kcs-bmc-v2
>> >+            - aspeed,ast2500-kcs-bmc-v2
>> >+            - aspeed,ast2600-kcs-bmc
>>
>> Should this have a "-v2" suffix?
>
>Well, that was kind of a matter of perspective. The 2600 compatible was
>added after we'd done the v2 of the binding for the 2400 and 2500 so it
>never needed correcting. But it is a case of "don't use the deprecated
>properties with the 2600 compatible".
>
>I don't think a change is necessary?
>

It just looked inconsistent with the corresponding string in the
ast_kcs_bmc_match[] table; perhaps that should be changed instead then?


Zev


From joel at jms.id.au  Fri Apr  9 06:45:11 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri,  9 Apr 2021 15:15:11 +0930
Subject: [PATCH] ARM: config: Add WPCM to multi v5
Message-ID: <20210409054511.1534181-1-joel@jms.id.au>

This is a newly added ARM926 platform that is not covered by any other
defconfigs.

Signed-off-by: Joel Stanley <joel at jms.id.au>
---
 arch/arm/configs/multi_v5_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 9f862b21b40a..80a3ae02d759 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -33,6 +33,8 @@ CONFIG_SOC_IMX25=y
 CONFIG_SOC_IMX27=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_KIRKWOOD=y
+CONFIG_ARCH_NPCM=y
+CONFIG_ARCH_WPCM450=y
 CONFIG_ARCH_ORION5X=y
 CONFIG_MACH_DB88F5281=y
 CONFIG_MACH_RD88F5182=y
@@ -178,6 +180,7 @@ CONFIG_THERMAL=y
 CONFIG_KIRKWOOD_THERMAL=y
 CONFIG_AT91SAM9X_WATCHDOG=y
 CONFIG_ORION_WATCHDOG=y
+CONFIG_NPCM7XX_WATCHDOG=y
 CONFIG_IMX2_WDT=y
 CONFIG_MFD_ATMEL_HLCDC=y
 # CONFIG_ABX500_CORE is not set
-- 
2.30.2



From ikjn at chromium.org  Fri Apr  9 06:45:49 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Fri, 9 Apr 2021 13:45:49 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <CAATdQgArnkdmbZefF4h7xp6=j-wHLgdQs1K0cDv06sP4eVdHmw@mail.gmail.com>

On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
>
> A dedicated wakeup irq will be used to handle runtime suspend/resume,
> we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> and attaching wakeup irq, then the suspend/resume framework will help
> to enable/disable wakeup irq.
>
> The runtime PM is default off since some platforms may not support it.
> users can enable it via power/control (set "auto") in sysfs.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
>  1 file changed, 124 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index a74764ab914a..30927f4064d4 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -16,6 +16,7 @@
>  #include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/pm_wakeirq.h>
>  #include <linux/regmap.h>
>  #include <linux/regulator/consumer.h>
>
> @@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
>                         mtk->uwk_reg_base, mtk->uwk_vers);
>
>         return PTR_ERR_OR_ZERO(mtk->uwk);
> -
>  }
>
>  static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
> @@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>         struct resource *res;
>         struct usb_hcd *hcd;
>         int ret = -ENODEV;
> +       int wakeup_irq;
>         int irq;
>
>         if (usb_disabled())
> @@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>         if (ret)
>                 return ret;
>
> +       irq = platform_get_irq_byname_optional(pdev, "host");
> +       if (irq < 0) {
> +               if (irq == -EPROBE_DEFER)
> +                       return irq;
> +
> +               /* for backward compatibility */
> +               irq = platform_get_irq(pdev, 0);
> +               if (irq < 0)
> +                       return irq;
> +       }
> +
> +       wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
> +       if (wakeup_irq == -EPROBE_DEFER)
> +               return wakeup_irq;
> +
>         mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
>         /* optional property, ignore the error if it does not exist */
>         of_property_read_u32(node, "mediatek,u3p-dis-msk",
> @@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>                 return ret;
>         }
>
> +       pm_runtime_set_active(dev);
> +       pm_runtime_use_autosuspend(dev);
> +       pm_runtime_set_autosuspend_delay(dev, 4000);
>         pm_runtime_enable(dev);
>         pm_runtime_get_sync(dev);
> -       device_enable_async_suspend(dev);
>
>         ret = xhci_mtk_ldos_enable(mtk);
>         if (ret)
> @@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>         if (ret)
>                 goto disable_ldos;
>
> -       irq = platform_get_irq(pdev, 0);
> -       if (irq < 0) {
> -               ret = irq;
> -               goto disable_clk;
> -       }
> -
>         hcd = usb_create_hcd(driver, dev, dev_name(dev));
>         if (!hcd) {
>                 ret = -ENOMEM;
> @@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>         if (ret)
>                 goto dealloc_usb2_hcd;
>
> +       if (wakeup_irq > 0) {
> +               ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
> +               if (ret) {
> +                       dev_err(dev, "set wakeup irq %d failed\n", wakeup_irq);
> +                       goto dealloc_usb3_hcd;
> +               }
> +               dev_info(dev, "wakeup irq %d\n", wakeup_irq);
> +       }
> +
> +       device_enable_async_suspend(dev);
> +       pm_runtime_mark_last_busy(dev);
> +       pm_runtime_put_autosuspend(dev);
> +       pm_runtime_forbid(dev);
> +
>         return 0;
>
> +dealloc_usb3_hcd:
> +       usb_remove_hcd(xhci->shared_hcd);
> +       xhci->shared_hcd = NULL;
> +
>  dealloc_usb2_hcd:
>         usb_remove_hcd(hcd);
>
> @@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>         xhci_mtk_ldos_disable(mtk);
>
>  disable_pm:
> -       pm_runtime_put_sync(dev);
> +       pm_runtime_put_sync_autosuspend(dev);
>         pm_runtime_disable(dev);
>         return ret;
>  }
>
> -static int xhci_mtk_remove(struct platform_device *dev)
> +static int xhci_mtk_remove(struct platform_device *pdev)
>  {
> -       struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
> +       struct xhci_hcd_mtk *mtk = platform_get_drvdata(pdev);
>         struct usb_hcd  *hcd = mtk->hcd;
>         struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>         struct usb_hcd  *shared_hcd = xhci->shared_hcd;
> +       struct device *dev = &pdev->dev;
>
> -       pm_runtime_put_noidle(&dev->dev);
> -       pm_runtime_disable(&dev->dev);
> +       pm_runtime_get_sync(dev);
> +       xhci->xhc_state |= XHCI_STATE_REMOVING;
> +       dev_pm_clear_wake_irq(dev);
> +       device_init_wakeup(dev, false);
>
>         usb_remove_hcd(shared_hcd);
>         xhci->shared_hcd = NULL;
> -       device_init_wakeup(&dev->dev, false);
> -
>         usb_remove_hcd(hcd);
>         usb_put_hcd(shared_hcd);
>         usb_put_hcd(hcd);
> @@ -627,6 +658,10 @@ static int xhci_mtk_remove(struct platform_device *dev)
>         xhci_mtk_clks_disable(mtk);
>         xhci_mtk_ldos_disable(mtk);
>
> +       pm_runtime_disable(dev);
> +       pm_runtime_put_noidle(dev);
> +       pm_runtime_set_suspended(dev);
> +
>         return 0;
>  }
>
> @@ -690,10 +725,83 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
>         return ret;
>  }
>
> +static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
> +{
> +       u32 suspended_ports;
> +       u32 status;
> +       int num_ports;
> +       int i;
> +
> +       num_ports = rhub->num_ports;
> +       suspended_ports = rhub->bus_state.suspended_ports;
> +       for (i = 0; i < num_ports; i++) {
> +               if (!(suspended_ports & BIT(i))) {
> +                       status = readl(rhub->ports[i]->addr);
> +                       if (status & PORT_CONNECT)

So this pm_runtime support is activated only when there's no devices
connected at all?
I think this will always return -EBUSY with my board having an on-board hub
connected to both rhubs.

> +                               return -EBUSY;
> +               }
> +       }
> +
> +       return 0;
> +}
> +
> +/*
> + * check the bus whether it could suspend or not
> + * the bus will suspend if the downstream ports are already suspended,
> + * or no devices connected.
> + */
> +static int check_bus_status(struct xhci_hcd *xhci)
> +{
> +       int ret;
> +
> +       ret = check_rhub_status(xhci, &xhci->usb3_rhub);
> +       if (ret)
> +               return ret;
> +
> +       return check_rhub_status(xhci, &xhci->usb2_rhub);
> +}
> +
> +static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
> +{
> +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> +       int ret = 0;
> +
> +       if (xhci->xhc_state)
> +               return -ESHUTDOWN;
> +
> +       if (device_may_wakeup(dev)) {
> +               ret = check_bus_status(xhci);
> +               if (!ret)
> +                       ret = xhci_mtk_suspend(dev);
> +       }
> +
> +       /* -EBUSY: let PM automatically reschedule another autosuspend */
> +       return ret ? -EBUSY : 0;
> +}
> +
> +static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
> +{
> +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> +       int ret = 0;
> +
> +       if (xhci->xhc_state)
> +               return -ESHUTDOWN;
> +
> +       if (device_may_wakeup(dev))
> +               ret = xhci_mtk_resume(dev);
> +
> +       return ret;
> +}
> +
>  static const struct dev_pm_ops xhci_mtk_pm_ops = {
>         SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
> +       SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
> +                          xhci_mtk_runtime_resume, NULL)
>  };
> -#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
> +
> +#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
>
>  static const struct of_device_id mtk_xhci_of_match[] = {
>         { .compatible = "mediatek,mt8173-xhci"},
> --
> 2.18.0
>


From tan.shaopeng at fujitsu.com  Fri Apr  9 06:46:28 2021
From: tan.shaopeng at fujitsu.com (tan.shaopeng at fujitsu.com)
Date: Fri, 9 Apr 2021 05:46:28 +0000
Subject: About add an A64FX cache control function into resctrl
Message-ID: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>

Hello


I'm Tan Shaopeng from Fujitsu Limited. 

I?m trying to implement Fujitsu A64FX?s cache related features. 
It is a cache partitioning function we called sector cache function 
that using the value of the tag that is upper 8 bits of the 64bit 
address and the value of the sector cache register to control virtual 
cache capacity of the L1D&L2 cache. 

A few days ago, when I sent a driver that realizes this function to 
ARM64 kernel community, Will Deacon and Arnd Bergmann suggested 
an idea to add the sector cache function of A64FX into resctrl. 
https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5OcZ=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/ 

Based on my study, I think the sector cache function of A64FX can be 
added into the allocation features of resctrl after James' resctrl 
rework has finished. But, in order to implement this function, 
more interfaces for resctrl are need. The details are as follow, 
and could you give me some advice? 

[Sector cache function] 
The sector cache function split cache into multiple sectors and 
control them separately. It is implemented on the L1D cache and 
L2 cache in the A64FX processor and can be controlled individually 
for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache 
and L2 cache has 4 sectors. Which L1D sector is used is specified 
by the value of [57:56] bits of address, how many ways of sector 
are specified by the value of register (IMP_SCCR_L1_EL0). 
Which L2 sector is used is specified by the value of [56] bits of 
address, and how many ways of sector are specified by value of register 
(IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1, IMP_SCCR_SET1_L2_EL1). 

For more details of sector cache function, 
see A64FX HPC extension specification (1.2. Sector cache) in 
https://github.com/fujitsu/A64FX 

[Difference between resctrl(CAT) and this sector cache function] 
L2/L3 CAT (Cache Allocation Technology) enables the user to specify 
some physical partition of cache space that an application can fill. 
A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function 
enables a user to specify number of ways each sector uses. 
Therefore, for CAT it is enough to specify a cache portion for 
each cache_id (socket). On the other hand, sector cache needs to 
specify cache portion of each sector for each cache_id, and following 
extension to resctrl interface is needed to support sector cache. 

[Idear for A64FX sector cache function control interface (schemata file details)] 
L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;?  
L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;? 

?L1: Add a new interface to control the L1D cache. 
?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for each sector. 
?cwbm?Specify the number of ways in each sector as a bitmap (percentage), 
  but the bitmap does not indicate the location of the cache. 
* In the sector cache function, L2 sector cache way setting register is 
  shared among PEs (Processor Element) in shared domain. If two PEs 
  which share L2 cache belongs to different resource groups, one resource 
  group's L2 setting will affect to other resource group's L2 setting. 
* Since A64FX does not support MPAM, it is not necessary to consider 
  how to switch between MPAM and sector cache function now. 

Some questions: 
1.I'm still studying about RDT, could you tell me whether RDT has 
  the similar mechanism with sector cache function? 
2.In RDT, L3 cache is shared among cores in socket. If two cores which 
  share L3 cache belongs to different resource groups, one resource 
  group's L3 setting will affect to other resource group's L3 setting? 
3.Is this approach acceptable? could you give me some advice? 


Best regards 
Tan Shaopeng 



From andrew at aj.id.au  Fri Apr  9 06:48:21 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:18:21 +0930
Subject: [PATCH v2 09/21] ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmi
In-Reply-To: <YG/QUCIdEzW1ghVA@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-9-andrew@aj.id.au> <YG/QUCIdEzW1ghVA@packtop>
Message-ID: <6aa7c000-da09-4058-96b4-f330193c7fc6@www.fastmail.com>



On Fri, 9 Apr 2021, at 13:26, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:40AM CDT, Andrew Jeffery wrote:
> >Take steps towards defining a coherent API to separate the KCS device
> >drivers from the userspace interface. Decreasing the coupling will
> >improve the separation of concerns and enable the introduction of
> >alternative userspace interfaces.
> >
> >For now, simply split the chardev logic out to a separate file. The code
> >continues to build into the same module.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/Makefile            |   2 +-
> > drivers/char/ipmi/kcs_bmc.c           | 423 +------------------------
> > drivers/char/ipmi/kcs_bmc.h           |  10 +-
> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 428 ++++++++++++++++++++++++++
> > 4 files changed, 451 insertions(+), 412 deletions(-)
> > create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >
> >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> >index 0822adc2ec41..a302bc865370 100644
> >--- a/drivers/char/ipmi/Makefile
> >+++ b/drivers/char/ipmi/Makefile
> >@@ -22,7 +22,7 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
> > obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
> > obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> >-obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> >+obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
> > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> > obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index c4336c1f2d6d..ef5c48ffe74a 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -3,446 +3,51 @@
> >  * Copyright (c) 2015-2018, Intel Corporation.
> >  */
> >
> >-#define pr_fmt(fmt) "kcs-bmc: " fmt
> >-
> >-#include <linux/errno.h>
> >-#include <linux/io.h>
> >-#include <linux/ipmi_bmc.h>
> > #include <linux/module.h>
> >-#include <linux/platform_device.h>
> >-#include <linux/poll.h>
> >-#include <linux/sched.h>
> >-#include <linux/slab.h>
> >
> > #include "kcs_bmc.h"
> >
> >-#define DEVICE_NAME "ipmi-kcs"
> >-
> >-#define KCS_MSG_BUFSIZ    1000
> >-
> >-#define KCS_ZERO_DATA     0
> >-
> >-
> >-/* IPMI 2.0 - Table 9-1, KCS Interface Status Register Bits */
> >-#define KCS_STATUS_STATE(state) (state << 6)
> >-#define KCS_STATUS_STATE_MASK   GENMASK(7, 6)
> >-#define KCS_STATUS_CMD_DAT      BIT(3)
> >-#define KCS_STATUS_SMS_ATN      BIT(2)
> >-#define KCS_STATUS_IBF          BIT(1)
> >-#define KCS_STATUS_OBF          BIT(0)
> >-
> >-/* IPMI 2.0 - Table 9-2, KCS Interface State Bits */
> >-enum kcs_states {
> >-	IDLE_STATE  = 0,
> >-	READ_STATE  = 1,
> >-	WRITE_STATE = 2,
> >-	ERROR_STATE = 3,
> >-};
> >-
> >-/* IPMI 2.0 - Table 9-3, KCS Interface Control Codes */
> >-#define KCS_CMD_GET_STATUS_ABORT  0x60
> >-#define KCS_CMD_WRITE_START       0x61
> >-#define KCS_CMD_WRITE_END         0x62
> >-#define KCS_CMD_READ_BYTE         0x68
> >-
> >-static inline u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> >+u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> > {
> > 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> > }
> >+EXPORT_SYMBOL(kcs_bmc_read_data);
> >
> >-static inline void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> >+void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> > {
> > 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> > }
> >+EXPORT_SYMBOL(kcs_bmc_write_data);
> >
> >-static inline u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> >+u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> > {
> > 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> > }
> >+EXPORT_SYMBOL(kcs_bmc_read_status);
> >
> >-static inline void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> >+void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> > {
> > 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> > }
> >+EXPORT_SYMBOL(kcs_bmc_write_status);
> >
> >-static void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> >+void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> > {
> > 	kcs_bmc->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> > }
> >+EXPORT_SYMBOL(kcs_bmc_update_status);
> >
> >-static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
> >-{
> >-	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
> >-					KCS_STATUS_STATE(state));
> >-}
> >-
> >-static void kcs_force_abort(struct kcs_bmc *kcs_bmc)
> >-{
> >-	set_state(kcs_bmc, ERROR_STATE);
> >-	kcs_bmc_read_data(kcs_bmc);
> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-
> >-	kcs_bmc->phase = KCS_PHASE_ERROR;
> >-	kcs_bmc->data_in_avail = false;
> >-	kcs_bmc->data_in_idx = 0;
> >-}
> >-
> >-static void kcs_bmc_handle_data(struct kcs_bmc *kcs_bmc)
> >-{
> >-	u8 data;
> >-
> >-	switch (kcs_bmc->phase) {
> >-	case KCS_PHASE_WRITE_START:
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
> >-		fallthrough;
> >-
> >-	case KCS_PHASE_WRITE_DATA:
> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
> >-			set_state(kcs_bmc, WRITE_STATE);
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
> >-						kcs_bmc_read_data(kcs_bmc);
> >-		} else {
> >-			kcs_force_abort(kcs_bmc);
> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
> >-		}
> >-		break;
> >-
> >-	case KCS_PHASE_WRITE_END_CMD:
> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
> >-			set_state(kcs_bmc, READ_STATE);
> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
> >-						kcs_bmc_read_data(kcs_bmc);
> >-			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
> >-			kcs_bmc->data_in_avail = true;
> >-			wake_up_interruptible(&kcs_bmc->queue);
> >-		} else {
> >-			kcs_force_abort(kcs_bmc);
> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
> >-		}
> >-		break;
> >-
> >-	case KCS_PHASE_READ:
> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
> >-			set_state(kcs_bmc, IDLE_STATE);
> >-
> >-		data = kcs_bmc_read_data(kcs_bmc);
> >-		if (data != KCS_CMD_READ_BYTE) {
> >-			set_state(kcs_bmc, ERROR_STATE);
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-			break;
> >-		}
> >-
> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-			kcs_bmc->phase = KCS_PHASE_IDLE;
> >-			break;
> >-		}
> >-
> >-		kcs_bmc_write_data(kcs_bmc,
> >-			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
> >-		break;
> >-
> >-	case KCS_PHASE_ABORT_ERROR1:
> >-		set_state(kcs_bmc, READ_STATE);
> >-		kcs_bmc_read_data(kcs_bmc);
> >-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
> >-		break;
> >-
> >-	case KCS_PHASE_ABORT_ERROR2:
> >-		set_state(kcs_bmc, IDLE_STATE);
> >-		kcs_bmc_read_data(kcs_bmc);
> >-		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-		kcs_bmc->phase = KCS_PHASE_IDLE;
> >-		break;
> >-
> >-	default:
> >-		kcs_force_abort(kcs_bmc);
> >-		break;
> >-	}
> >-}
> >-
> >-static void kcs_bmc_handle_cmd(struct kcs_bmc *kcs_bmc)
> >-{
> >-	u8 cmd;
> >-
> >-	set_state(kcs_bmc, WRITE_STATE);
> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-
> >-	cmd = kcs_bmc_read_data(kcs_bmc);
> >-	switch (cmd) {
> >-	case KCS_CMD_WRITE_START:
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_START;
> >-		kcs_bmc->error = KCS_NO_ERROR;
> >-		kcs_bmc->data_in_avail = false;
> >-		kcs_bmc->data_in_idx = 0;
> >-		break;
> >-
> >-	case KCS_CMD_WRITE_END:
> >-		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
> >-			kcs_force_abort(kcs_bmc);
> >-			break;
> >-		}
> >-
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
> >-		break;
> >-
> >-	case KCS_CMD_GET_STATUS_ABORT:
> >-		if (kcs_bmc->error == KCS_NO_ERROR)
> >-			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
> >-
> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
> >-		kcs_bmc->data_in_avail = false;
> >-		kcs_bmc->data_in_idx = 0;
> >-		break;
> >-
> >-	default:
> >-		kcs_force_abort(kcs_bmc);
> >-		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
> >-		break;
> >-	}
> >-}
> >-
> >+int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);
> 
> This declaration looks a bit out of place here; should it be in
> kcs_bmc.h instead?

These are only temporary and get removed later on in the series after 
some shuffling of the code.

Andrew


From sfr at canb.auug.org.au  Fri Apr  9 06:52:57 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 9 Apr 2021 15:52:57 +1000
Subject: linux-next: manual merge of the irqchip tree with the arm-soc tree
Message-ID: <20210409155257.47f66922@canb.auug.org.au>

Hi all,

Today's linux-next merge of the irqchip tree got conflicts in:

  drivers/irqchip/Kconfig
  drivers/irqchip/Makefile

between commit:

  76cde2639411 ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")

from the arm-soc tree and commits:

  fead4dd49663 ("irqchip: Add driver for WPCM450 interrupt controller")
  94bc94209a66 ("irqchip/wpcm450: Drop COMPILE_TEST")

from the irqchip 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 drivers/irqchip/Kconfig
index d3a14f304ec8,715eb4366e35..000000000000
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@@ -577,12 -577,10 +577,18 @@@ config MST_IR
  	help
  	  Support MStar Interrupt Controller.
  
 +config APPLE_AIC
 +	bool "Apple Interrupt Controller (AIC)"
 +	depends on ARM64
 +	default ARCH_APPLE
 +	help
 +	  Support for the Apple Interrupt Controller found on Apple Silicon SoCs,
 +	  such as the M1.
 +
+ config WPCM450_AIC
+ 	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
+ 	depends on ARCH_WPCM450
+ 	help
+ 	  Support for the interrupt controller in the Nuvoton WPCM450 BMC SoC.
+ 
  endmenu
diff --cc drivers/irqchip/Makefile
index eb6a515f0f64,bef57937e729..000000000000
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -113,4 -113,4 +113,5 @@@ obj-$(CONFIG_LOONGSON_PCH_MSI)		+= irq-
  obj-$(CONFIG_MST_IRQ)			+= irq-mst-intc.o
  obj-$(CONFIG_SL28CPLD_INTC)		+= irq-sl28cpld.o
  obj-$(CONFIG_MACH_REALTEK_RTL)		+= irq-realtek-rtl.o
 +obj-$(CONFIG_APPLE_AIC)			+= irq-apple-aic.o
+ obj-$(CONFIG_WPCM450_AIC)		+= irq-wpcm450-aic.o
-------------- 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/20210409/0892b391/attachment.sig>

From andrew at aj.id.au  Fri Apr  9 06:59:09 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:29:09 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_10/21]_ipmi:_kcs=5Fbmc:_Turn_the_driver_data-str?=
 =?UTF-8?Q?uctures_inside-out?=
In-Reply-To: <YG/Ql9z9X/mtOSvl@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-10-andrew@aj.id.au> <YG/Ql9z9X/mtOSvl@packtop>
Message-ID: <ea34ee69-a266-4737-8450-4695d2d0fbd4@www.fastmail.com>



On Fri, 9 Apr 2021, at 13:27, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:41AM CDT, Andrew Jeffery wrote:
> >Make the KCS device drivers responsible for allocating their own memory.
> >
> >Until now the private data for the device driver was allocated internal
> >to the private data for the chardev interface. This coupling required
> >the slightly awkward API of passing through the struct size for the
> >driver private data to the chardev constructor, and then retrieving a
> >pointer to the driver private data from the allocated chardev memory.
> >
> >In addition to being awkward, the arrangement prevents the
> >implementation of alternative userspace interfaces as the device driver
> >private data is not independent.
> >
> >Peel a layer off the onion and turn the data-structures inside out by
> >exploiting container_of() and embedding `struct kcs_device` in the
> >driver private data.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/kcs_bmc.c           | 15 +++++--
> > drivers/char/ipmi/kcs_bmc.h           | 12 ++----
> > drivers/char/ipmi/kcs_bmc_aspeed.c    | 60 ++++++++++++++++-----------
> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 60 ++++++++++++++++++---------
> > drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 37 ++++++++++-------
> > 5 files changed, 113 insertions(+), 71 deletions(-)
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index ef5c48ffe74a..709b6bdec165 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -44,12 +44,19 @@ int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> > }
> > EXPORT_SYMBOL(kcs_bmc_handle_event);
> >
> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
> >-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel)
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
> 
> Another declaration perhaps intended for kcs_bmc.h?

These are temporary while the code gets shuffled around. The symbol 
name is an implementation detail, not a "public" part of the API; after 
some further shuffling these are eventually assigned as callbacks in an 
ops struct.

> 
> >+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
> > {
> >-	return kcs_bmc_ipmi_alloc(dev, sizeof_priv, channel);
> >+	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> > }
> >-EXPORT_SYMBOL(kcs_bmc_alloc);
> >+EXPORT_SYMBOL(kcs_bmc_add_device);
> >+
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
> 
> Here too.
> 
> >+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
> >+{
> >+	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_remove_device);
> >
> > MODULE_LICENSE("GPL v2");
> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> >diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
> >index febea0c8deb4..bf0ae327997f 100644
> >--- a/drivers/char/ipmi/kcs_bmc.h
> >+++ b/drivers/char/ipmi/kcs_bmc.h
> >@@ -67,6 +67,8 @@ struct kcs_ioreg {
> > };
> >
> > struct kcs_bmc {
> >+	struct device *dev;
> >+
> > 	spinlock_t lock;
> >
> > 	u32 channel;
> >@@ -94,17 +96,11 @@ struct kcs_bmc {
> > 	u8 *kbuffer;
> >
> > 	struct miscdevice miscdev;
> >-
> >-	unsigned long priv[];
> > };
> >
> >-static inline void *kcs_bmc_priv(struct kcs_bmc *kcs_bmc)
> >-{
> >-	return kcs_bmc->priv;
> >-}
> >-
> > int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
> >-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel);
> >+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
> >+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
> >
> > u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
> > void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
> >diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >index 630cf095560e..0416ac78ce68 100644
> >--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
> >+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >@@ -61,6 +61,8 @@
> > #define LPC_STR4             0x11C
> >
> > struct aspeed_kcs_bmc {
> >+	struct kcs_bmc kcs_bmc;
> >+
> > 	struct regmap *map;
> > };
> >
> >@@ -69,9 +71,14 @@ struct aspeed_kcs_of_ops {
> > 	int (*get_io_address)(struct platform_device *pdev);
> > };
> >
> >+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
> >+{
> >+	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
> >+}
> >+
> > static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> > {
> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	u32 val = 0;
> > 	int rc;
> >
> >@@ -83,7 +90,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> >
> > static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> > {
> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	int rc;
> >
> > 	rc = regmap_write(priv->map, reg, data);
> >@@ -92,7 +99,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> >
> > static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
> > {
> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	int rc;
> >
> > 	rc = regmap_update_bits(priv->map, reg, mask, val);
> >@@ -114,7 +121,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
> >  */
> > static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> > {
> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> >
> > 	switch (kcs_bmc->channel) {
> > 	case 1:
> >@@ -148,7 +155,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> >
> > static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> > {
> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> >
> > 	switch (kcs_bmc->channel) {
> > 	case 1:
> >@@ -323,16 +330,16 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
> > static int aspeed_kcs_probe(struct platform_device *pdev)
> > {
> > 	const struct aspeed_kcs_of_ops *ops;
> >-	struct device *dev = &pdev->dev;
> >+	struct aspeed_kcs_bmc *priv;
> > 	struct kcs_bmc *kcs_bmc;
> > 	struct device_node *np;
> > 	int rc, channel, addr;
> >
> >-	np = dev->of_node->parent;
> >+	np = pdev->dev.of_node->parent;
> > 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
> > 	    !of_device_is_compatible(np, "aspeed,ast2500-lpc-v2") &&
> > 	    !of_device_is_compatible(np, "aspeed,ast2600-lpc-v2")) {
> >-		dev_err(dev, "unsupported LPC device binding\n");
> >+		dev_err(&pdev->dev, "unsupported LPC device binding\n");
> > 		return -ENODEV;
> > 	}
> > 	ops = of_device_get_match_data(&pdev->dev);
> >@@ -343,18 +350,27 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> > 	if (channel < 0)
> > 		return channel;
> >
> >-	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
> >-	if (!kcs_bmc)
> >+	addr = ops->get_io_address(pdev);
> >+	if (addr < 0)
> >+		return addr;
> >+
> >+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> >+	if (!priv)
> > 		return -ENOMEM;
> >
> >+	kcs_bmc = &priv->kcs_bmc;
> >+	kcs_bmc->dev = &pdev->dev;
> >+	kcs_bmc->channel = channel;
> > 	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
> > 	kcs_bmc->io_inputb = aspeed_kcs_inb;
> > 	kcs_bmc->io_outputb = aspeed_kcs_outb;
> > 	kcs_bmc->io_updateb = aspeed_kcs_updateb;
> >
> >-	addr = ops->get_io_address(pdev);
> >-	if (addr < 0)
> >-		return addr;
> >+	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
> >+	if (IS_ERR(priv->map)) {
> >+		dev_err(&pdev->dev, "Couldn't get regmap\n");
> >+		return -ENODEV;
> >+	}
> 
> The reanimated priv->map initialization I suspect wasn't meant to
> have been removed in the first place...

Yeah, I'll have to go back and figure out what went wrong there!

Thanks for catching that.

> 
> >
> > 	aspeed_kcs_set_address(kcs_bmc, addr);
> >
> >@@ -362,29 +378,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> > 	if (rc)
> > 		return rc;
> >
> >-	dev_set_drvdata(dev, kcs_bmc);
> >+	platform_set_drvdata(pdev, priv);
> >
> > 	aspeed_kcs_enable_channel(kcs_bmc, true);
> >
> >-	rc = misc_register(&kcs_bmc->miscdev);
> >-	if (rc) {
> >-		dev_err(dev, "Unable to register device\n");
> >+	rc = kcs_bmc_add_device(&priv->kcs_bmc);
> >+	if (rc < 0)
> > 		return rc;
> >-	}
> >
> >-	dev_dbg(&pdev->dev,
> >-		"Probed KCS device %d (IDR=0x%x, ODR=0x%x, STR=0x%x)\n",
> >-		kcs_bmc->channel, kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr,
> >-		kcs_bmc->ioreg.str);
> >+	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n", kcs_bmc->channel, addr);
> 
> Is the dbg->info change here intentional?  (I have no particular
> objection if so, but it's often a change I make myself during
> testing/debugging and then forget to revert...)

Yeah, it was possibly something I forgot to revert. If others have 
issues with it staying at dev_info() I'll switch it back.

> 
> >
> > 	return 0;
> > }
> >
> > static int aspeed_kcs_remove(struct platform_device *pdev)
> > {
> >-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
> >+	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
> >+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
> >
> >-	misc_deregister(&kcs_bmc->miscdev);
> >+	kcs_bmc_remove_device(kcs_bmc);
> 
> Should we propagate the return value outward here?

Probably!

> 
> >
> > 	return 0;
> > }
> >diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >index 82c77994e481..0ca71c135a1a 100644
> >--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >@@ -382,7 +382,7 @@ static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
> > 	return 0;
> > }
> >
> >-static const struct file_operations kcs_bmc_fops = {
> >+static const struct file_operations kcs_bmc_ipmi_fops = {
> > 	.owner          = THIS_MODULE,
> > 	.open           = kcs_bmc_ipmi_open,
> > 	.read           = kcs_bmc_ipmi_read,
> >@@ -392,36 +392,58 @@ static const struct file_operations kcs_bmc_fops = {
> > 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
> > };
> >
> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
> 
> Errant declaration again?

As previously explained.

> 
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
> > {
> >-	struct kcs_bmc *kcs_bmc;
> >-
> >-	kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, GFP_KERNEL);
> >-	if (!kcs_bmc)
> >-		return NULL;
> >+	int rc;
> >
> > 	spin_lock_init(&kcs_bmc->lock);
> >-	kcs_bmc->channel = channel;
> >-
> > 	mutex_init(&kcs_bmc->mutex);
> > 	init_waitqueue_head(&kcs_bmc->queue);
> >
> >-	kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >-	kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >-	kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >
> > 	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
> >-	kcs_bmc->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s%u",
> >-					       DEVICE_NAME, channel);
> >+	kcs_bmc->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u",
> >+					       DEVICE_NAME, kcs_bmc->channel);
> > 	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
> > 	    !kcs_bmc->miscdev.name)
> >-		return NULL;
> >-	kcs_bmc->miscdev.fops = &kcs_bmc_fops;
> >+		return -ENOMEM;
> >
> >-	return kcs_bmc;
> >+	kcs_bmc->miscdev.fops = &kcs_bmc_ipmi_fops;
> >+
> >+	rc = misc_register(&kcs_bmc->miscdev);
> >+	if (rc) {
> >+		dev_err(kcs_bmc->dev, "Unable to register device: %d\n", rc);
> >+		return rc;
> >+	}
> >+
> >+	dev_info(kcs_bmc->dev, "Initialised IPMI client for channel %d", kcs_bmc->channel);
> >+
> >+	return 0;
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
> >+
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
> 
> Same here.

Same explanation.

> 
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc)
> >+{
> >+	misc_deregister(&kcs_bmc->miscdev);
> >+
> >+	spin_lock_irq(&kcs_bmc->lock);
> >+	kcs_bmc->running = 0;
> >+	kcs_bmc_ipmi_force_abort(kcs_bmc);
> >+	spin_unlock_irq(&kcs_bmc->lock);
> >+
> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->kbuffer);
> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_out);
> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_in);
> >+	devm_kfree(kcs_bmc->dev, kcs_bmc);
> >+
> >+	return 0;
> > }
> >-EXPORT_SYMBOL(kcs_bmc_ipmi_alloc);
> >+EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
> >
> > MODULE_LICENSE("GPL v2");
> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> >diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >index 1f44aadec9e8..5d017498dc69 100644
> >--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >@@ -65,6 +65,8 @@ struct npcm7xx_kcs_reg {
> > };
> >
> > struct npcm7xx_kcs_bmc {
> >+	struct kcs_bmc kcs_bmc;
> >+
> > 	struct regmap *map;
> >
> > 	const struct npcm7xx_kcs_reg *reg;
> >@@ -76,9 +78,14 @@ static const struct npcm7xx_kcs_reg npcm7xx_kcs_reg_tbl[KCS_CHANNEL_MAX] = {
> > 	{ .sts = KCS3ST, .dob = KCS3DO, .dib = KCS3DI, .ctl = KCS3CTL, .ie = KCS3IE },
> > };
> >
> >+static inline struct npcm7xx_kcs_bmc *to_npcm7xx_kcs_bmc(struct kcs_bmc *kcs_bmc)
> >+{
> >+	return container_of(kcs_bmc, struct npcm7xx_kcs_bmc, kcs_bmc);
> >+}
> >+
> > static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> > {
> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> > 	u32 val = 0;
> > 	int rc;
> >
> >@@ -90,7 +97,7 @@ static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> >
> > static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> > {
> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> > 	int rc;
> >
> > 	rc = regmap_write(priv->map, reg, data);
> >@@ -99,7 +106,7 @@ static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> >
> > static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 data)
> > {
> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> > 	int rc;
> >
> > 	rc = regmap_update_bits(priv->map, reg, mask, data);
> >@@ -108,7 +115,7 @@ static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 da
> >
> > static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> > {
> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> >
> > 	regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
> > 			   enable ? KCS_CTL_IBFIE : 0);
> >@@ -155,11 +162,10 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> > 		return -ENODEV;
> > 	}
> >
> >-	kcs_bmc = kcs_bmc_alloc(dev, sizeof(*priv), chan);
> >-	if (!kcs_bmc)
> >+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> >+	if (!priv)
> > 		return -ENOMEM;
> >
> >-	priv = kcs_bmc_priv(kcs_bmc);
> > 	priv->map = syscon_node_to_regmap(dev->parent->of_node);
> > 	if (IS_ERR(priv->map)) {
> > 		dev_err(dev, "Couldn't get regmap\n");
> >@@ -167,6 +173,9 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> > 	}
> > 	priv->reg = &npcm7xx_kcs_reg_tbl[chan - 1];
> >
> >+	kcs_bmc = &priv->kcs_bmc;
> >+	kcs_bmc->dev = &pdev->dev;
> >+	kcs_bmc->channel = chan;
> > 	kcs_bmc->ioreg.idr = priv->reg->dib;
> > 	kcs_bmc->ioreg.odr = priv->reg->dob;
> > 	kcs_bmc->ioreg.str = priv->reg->sts;
> >@@ -174,31 +183,27 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
> > 	kcs_bmc->io_outputb = npcm7xx_kcs_outb;
> > 	kcs_bmc->io_updateb = npcm7xx_kcs_updateb;
> >
> >-	dev_set_drvdata(dev, kcs_bmc);
> >+	platform_set_drvdata(pdev, priv);
> >
> > 	npcm7xx_kcs_enable_channel(kcs_bmc, true);
> > 	rc = npcm7xx_kcs_config_irq(kcs_bmc, pdev);
> > 	if (rc)
> > 		return rc;
> >
> >-	rc = misc_register(&kcs_bmc->miscdev);
> >-	if (rc) {
> >-		dev_err(dev, "Unable to register device\n");
> >-		return rc;
> >-	}
> >
> > 	pr_info("channel=%u idr=0x%x odr=0x%x str=0x%x\n",
> > 		chan,
> > 		kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr, kcs_bmc->ioreg.str);
> >
> >-	return 0;
> >+	return kcs_bmc_add_device(kcs_bmc);
> > }
> >
> > static int npcm7xx_kcs_remove(struct platform_device *pdev)
> > {
> >-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
> >+	struct npcm7xx_kcs_bmc *priv = platform_get_drvdata(pdev);
> >+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
> >
> >-	misc_deregister(&kcs_bmc->miscdev);
> >+	kcs_bmc_remove_device(kcs_bmc);
> 
> As with the corresponding aspeed code, should we propagate the return
> value here?

I'll address this.

Thanks for the review!

Andrew


From andrew at aj.id.au  Fri Apr  9 07:06:48 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:36:48 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_11/21]_ipmi:_kcs=5Fbmc:_Split_headers_into_devic?=
 =?UTF-8?Q?e_and_client?=
In-Reply-To: <YG/RkB07Wh69/xdu@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-11-andrew@aj.id.au> <YG/RkB07Wh69/xdu@packtop>
Message-ID: <e5c84ec2-5fe7-4f29-866a-331f652edd79@www.fastmail.com>



On Fri, 9 Apr 2021, at 13:31, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:42AM CDT, Andrew Jeffery wrote:
> >Strengthen the distinction between code that abstracts the
> >implementation of the KCS behaviours (device drivers) and code that
> >exploits KCS behaviours (clients). Neither needs to know about the APIs
> >required by the other, so provide separate headers.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/kcs_bmc.c           | 21 ++++++++++-----
> > drivers/char/ipmi/kcs_bmc.h           | 30 ++++++++++-----------
> > drivers/char/ipmi/kcs_bmc_aspeed.c    | 20 +++++++++-----
> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 39 ++++++++++++++++++---------
> > drivers/char/ipmi/kcs_bmc_client.h    | 29 ++++++++++++++++++++
> > drivers/char/ipmi/kcs_bmc_device.h    | 19 +++++++++++++
> > drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 20 +++++++++-----
> > 7 files changed, 129 insertions(+), 49 deletions(-)
> > create mode 100644 drivers/char/ipmi/kcs_bmc_client.h
> > create mode 100644 drivers/char/ipmi/kcs_bmc_device.h
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index 709b6bdec165..1046ce2bbefc 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -1,46 +1,52 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> >  * Copyright (c) 2015-2018, Intel Corporation.
> >+ * Copyright (c) 2021, IBM Corp.
> >  */
> >
> > #include <linux/module.h>
> >
> > #include "kcs_bmc.h"
> >
> >+/* Implement both the device and client interfaces here */
> >+#include "kcs_bmc_device.h"
> >+#include "kcs_bmc_client.h"
> >+
> >+/* Consumer data access */
> >+
> > u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> > {
> >-	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> >+	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> > }
> > EXPORT_SYMBOL(kcs_bmc_read_data);
> >
> > void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> > {
> >-	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> >+	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> > }
> > EXPORT_SYMBOL(kcs_bmc_write_data);
> >
> > u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> > {
> >-	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> >+	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> > }
> > EXPORT_SYMBOL(kcs_bmc_read_status);
> >
> > void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> > {
> >-	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> >+	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> > }
> > EXPORT_SYMBOL(kcs_bmc_write_status);
> >
> > void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> > {
> >-	kcs_bmc->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> >+	kcs_bmc->ops->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> > }
> > EXPORT_SYMBOL(kcs_bmc_update_status);
> >
> >-int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);
> > int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> > {
> >-	return kcs_bmc_ipmi_event(kcs_bmc);
> >+	return kcs_bmc->client.ops->event(&kcs_bmc->client);
> > }
> > EXPORT_SYMBOL(kcs_bmc_handle_event);
> >
> >@@ -60,4 +66,5 @@ EXPORT_SYMBOL(kcs_bmc_remove_device);
> >
> > MODULE_LICENSE("GPL v2");
> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> >+MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
> > MODULE_DESCRIPTION("KCS BMC to handle the IPMI request from system software");
> >diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
> >index bf0ae327997f..a1350e567723 100644
> >--- a/drivers/char/ipmi/kcs_bmc.h
> >+++ b/drivers/char/ipmi/kcs_bmc.h
> >@@ -8,6 +8,15 @@
> >
> > #include <linux/miscdevice.h>
> >
> >+#include "kcs_bmc_client.h"
> >+
> >+#define KCS_BMC_EVENT_NONE	0
> >+#define KCS_BMC_EVENT_HANDLED	1
> 
> Is there a particular reason we're introducing these macros and using an
> int return type for kcs_bmc_client_ops.event instead of just having it
> be irqreturn_t?  Other event types or outcomes we're anticipating needing
> to handle maybe?

In earlier iterations of the patches I was doing some extra work in the 
event handling path and felt it was useful at the time. However I've 
refactored things a little and this may have outlived its usefulness.

I'll reasses!

> 
> >+
> >+#define KCS_BMC_STR_OBF		BIT(0)
> >+#define KCS_BMC_STR_IBF		BIT(1)
> >+#define KCS_BMC_STR_CMD_DAT	BIT(3)
> 
> The first two of these macros are used later in the series, but the third
> doesn't end up used at all I think?

I think I just added it as documentation as the hardware-defined bits 
aren't contiguous.

Andrew


From yeweihua4 at huawei.com  Fri Apr  9 07:11:25 2021
From: yeweihua4 at huawei.com (Ye Weihua)
Date: Fri, 9 Apr 2021 14:11:25 +0800
Subject: [PATCH -next] hwrng: exynos - fix PM reference leak in
 exynos_trng_probe()
Message-ID: <20210409061125.214255-1-yeweihua4@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>
---
 drivers/char/hw_random/exynos-trng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8dd2d..666246bc8cca 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -132,7 +132,7 @@ static int exynos_trng_probe(struct platform_device *pdev)
 		return PTR_ERR(trng->mem);
 
 	pm_runtime_enable(&pdev->dev);
-	ret = pm_runtime_get_sync(&pdev->dev);
+	ret = pm_runtime_resume_and_get(&pdev->dev);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not get runtime PM.\n");
 		goto err_pm_get;
-- 
2.17.1



From joel at jms.id.au  Fri Apr  9 07:14:27 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 06:14:27 +0000
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13
Message-ID: <CACPK8Xe-KV5BeQwOH6NKC1++FCVqwwNCGBh7hEbBORfrmxfTtQ@mail.gmail.com>

Hello Soc maintainers,

Here's a pull request from me for the ASPEED and Nuvoton changes
targeting the v5.13 merge window. As you can see I've chosen to
arrange the pull request as one single "BMC-related" set of changes.
If we choose to continue with this, in the future I will cover the
ASPEED, NPCM and soon to be merged WPCM (legacy Nuvoton) systems.

The following changes since commit ee33e2fb3d70267de00f7c0b09e7e3b309a686df:

  ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree (2021-04-08 11:21:05 +0930)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc.git
tags/bmc-5.13-devicetree

for you to fetch changes up to ee33e2fb3d70267de00f7c0b09e7e3b309a686df:

  ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree (2021-04-08 11:21:05 +0930)

----------------------------------------------------------------
BMC device tree updates for 5.13

The ASPEED and Nuvoton pull request now comes as a combined BMC pull
request.

 - New machines

  * ASRock E3C246D4I, an AST2500 BMC for an Xeon E-2100/E-2200 mini-ITX
    system
  * Quanta GBS, an NPCM730 BMC for an x86 server

 - Power10 BMC updates for Everest and Rainier

 - GPIO line names for Mihawk

----------------------------------------------------------------

Alpana Kumari (2):
      ARM: dts: aspeed: rainier: Add presence GPIOs
      ARM: dts: aspeed: everest: GPIOs support

Brandon Wyman (2):
      ARM: dts: aspeed: rainier: Add gpio-keys-polled for fans
      ARM: dts: aspeed: everest: Add power supply i2c devices

Eddie James (7):
      ARM: dts: aspeed: rainier: Add additional processor CFAMs
      ARM: dts: aspeed: rainier: Enable fan watchdog
      ARM: dts: aspeed: rainier 4U: Fix fan configuration
      ARM: dts: aspeed: everest: Add FSI CFAMs and re-number engines
      ARM: dts: aspeed: everest: Add RTC
      ARM: dts: aspeed: everest: Enable fan watchdog
      ARM: dts: aspeed: Add Rainier 1S4U machine

George Hung (1):
      ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree

Jim Wright (1):
      ARM: dts: aspeed: everest: Add UCD90320 power sequencer

Joel Stanley (2):
      ARM: dts: aspeed: rainier: Add missing fan nodes
      ARM: dts: aspeed: everest: Add size/address cells

Matthew Barth (2):
      ARM: dts: aspeed: everest: Add max31785 fan controller device
      ARM: dts: aspeed: everest: Add pca9552 fan presence

Nichole Wang (1):
      ARM: dts: aspeed: mihawk: Add GPIO line names

Priyanga Ramasamy (1):
      ARM: dts: aspeed: everest: Add I2C components

Vishwanatha Subbanna (1):
      ARM: dts: aspeed: rainier: Add directly controlled LEDs

Zev Weiss (1):
      ARM: dts: aspeed: Add ASRock E3C246D4I BMC


From andrew at aj.id.au  Fri Apr  9 07:15:29 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:45:29 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_12/21]_ipmi:_kcs=5Fbmc:_Strip_private_client_dat?=
 =?UTF-8?Q?a_from_struct_kcs=5Fbmc?=
In-Reply-To: <YG/S8UdjT8TH6cqs@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-12-andrew@aj.id.au> <YG/S8UdjT8TH6cqs@packtop>
Message-ID: <c96c9a2f-6c9c-4dd3-ba20-13e7f76aec37@www.fastmail.com>



On Fri, 9 Apr 2021, at 13:37, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:43AM CDT, Andrew Jeffery wrote:
> >Move all client-private data out of `struct kcs_bmc` into the KCS client
> >implementation.
> >
> >With this change the KCS BMC core code now only concerns itself with
> >abstract `struct kcs_bmc` and `struct kcs_bmc_client` types, achieving
> >expected separation of concerns. Further, the change clears the path for
> >implementation of alternative userspace interfaces.
> >
> >The chardev data-structures are rearranged in the same manner applied to
> >the KCS device driver data-structures in an earlier patch - `struct
> >kcs_bmc_client` is embedded in the client's private data and we exploit
> >container_of() to translate as required.
> >
> >Finally, now that it is free of client data, `struct kcs_bmc` is renamed
> >to `struct kcs_bmc_device` to contrast `struct kcs_bmc_client`.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/kcs_bmc.c           |  68 +++-
> > drivers/char/ipmi/kcs_bmc.h           |  86 +-----
> > drivers/char/ipmi/kcs_bmc_aspeed.c    |  22 +-
> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 428 ++++++++++++++++----------
> > drivers/char/ipmi/kcs_bmc_client.h    |  28 +-
> > drivers/char/ipmi/kcs_bmc_device.h    |  12 +-
> > drivers/char/ipmi/kcs_bmc_npcm7xx.c   |  20 +-
> > 7 files changed, 368 insertions(+), 296 deletions(-)
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index 1046ce2bbefc..266ebec71d6f 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -4,6 +4,7 @@
> >  * Copyright (c) 2021, IBM Corp.
> >  */
> >
> >+#include <linux/device.h>
> > #include <linux/module.h>
> >
> > #include "kcs_bmc.h"
> >@@ -14,51 +15,96 @@
> >
> > /* Consumer data access */
> >
> >-u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
> >+u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc)
> > {
> > 	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
> > }
> > EXPORT_SYMBOL(kcs_bmc_read_data);
> >
> >-void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
> >+void kcs_bmc_write_data(struct kcs_bmc_device *kcs_bmc, u8 data)
> > {
> > 	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
> > }
> > EXPORT_SYMBOL(kcs_bmc_write_data);
> >
> >-u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
> >+u8 kcs_bmc_read_status(struct kcs_bmc_device *kcs_bmc)
> > {
> > 	return kcs_bmc->ops->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
> > }
> > EXPORT_SYMBOL(kcs_bmc_read_status);
> >
> >-void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
> >+void kcs_bmc_write_status(struct kcs_bmc_device *kcs_bmc, u8 data)
> > {
> > 	kcs_bmc->ops->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
> > }
> > EXPORT_SYMBOL(kcs_bmc_write_status);
> >
> >-void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
> >+void kcs_bmc_update_status(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 val)
> > {
> > 	kcs_bmc->ops->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
> > }
> > EXPORT_SYMBOL(kcs_bmc_update_status);
> >
> >-int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
> >+int kcs_bmc_handle_event(struct kcs_bmc_device *kcs_bmc)
> > {
> >-	return kcs_bmc->client.ops->event(&kcs_bmc->client);
> >+	struct kcs_bmc_client *client;
> >+	int rc;
> >+
> >+	spin_lock(&kcs_bmc->lock);
> >+	client = kcs_bmc->client;
> >+	if (client) {
> >+		rc = client->ops->event(client);
> >+	} else {
> >+		u8 status;
> >+
> >+		status = kcs_bmc_read_status(kcs_bmc);
> >+		if (status & KCS_BMC_STR_IBF) {
> >+			/* Ack the event by reading the data */
> >+			kcs_bmc_read_data(kcs_bmc);
> >+			rc = KCS_BMC_EVENT_HANDLED;
> >+		} else {
> >+			rc = KCS_BMC_EVENT_NONE;
> >+		}
> >+	}
> >+	spin_unlock(&kcs_bmc->lock);
> >+
> >+	return rc;
> > }
> > EXPORT_SYMBOL(kcs_bmc_handle_event);
> >
> >-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
> >-int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
> >+int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
> >+{
> >+	int rc;
> >+
> >+	spin_lock_irq(&kcs_bmc->lock);
> >+	if (kcs_bmc->client) {
> >+		rc = -EBUSY;
> >+	} else {
> >+		kcs_bmc->client = client;
> >+		rc = 0;
> >+	}
> >+	spin_unlock_irq(&kcs_bmc->lock);
> >+
> >+	return rc;
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_enable_device);
> >+
> >+void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client)
> >+{
> >+	spin_lock_irq(&kcs_bmc->lock);
> >+	if (client == kcs_bmc->client)
> >+		kcs_bmc->client = NULL;
> 
> Is there any situation in which a non-matching client could be passed in
> here?

Yes; this allows the chardev modules to just unconditionally call 
kcs_bmc_disable_device() without having to duplicate the state tracking 
done here.

>  Might we consider issuing a warning of some sort or returning an
> error to the caller if so?

No, see above.

> 
> >+	spin_unlock_irq(&kcs_bmc->lock);
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_disable_device);
> >+
> >+int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc)
> > {
> > 	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> > }
> > EXPORT_SYMBOL(kcs_bmc_add_device);
> >
> >-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
> >-int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
> >+int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc)
> > {
> > 	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
> > }
> >diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
> >index a1350e567723..3f266740c759 100644
> >--- a/drivers/char/ipmi/kcs_bmc.h
> >+++ b/drivers/char/ipmi/kcs_bmc.h
> >@@ -6,9 +6,7 @@
> > #ifndef __KCS_BMC_H__
> > #define __KCS_BMC_H__
> >
> >-#include <linux/miscdevice.h>
> >-
> >-#include "kcs_bmc_client.h"
> >+#include <linux/list.h>
> >
> > #define KCS_BMC_EVENT_NONE	0
> > #define KCS_BMC_EVENT_HANDLED	1
> >@@ -17,53 +15,6 @@
> > #define KCS_BMC_STR_IBF		BIT(1)
> > #define KCS_BMC_STR_CMD_DAT	BIT(3)
> >
> >-/* Different phases of the KCS BMC module.
> >- *  KCS_PHASE_IDLE:
> >- *            BMC should not be expecting nor sending any data.
> >- *  KCS_PHASE_WRITE_START:
> >- *            BMC is receiving a WRITE_START command from system software.
> >- *  KCS_PHASE_WRITE_DATA:
> >- *            BMC is receiving a data byte from system software.
> >- *  KCS_PHASE_WRITE_END_CMD:
> >- *            BMC is waiting a last data byte from system software.
> >- *  KCS_PHASE_WRITE_DONE:
> >- *            BMC has received the whole request from system software.
> >- *  KCS_PHASE_WAIT_READ:
> >- *            BMC is waiting the response from the upper IPMI service.
> >- *  KCS_PHASE_READ:
> >- *            BMC is transferring the response to system software.
> >- *  KCS_PHASE_ABORT_ERROR1:
> >- *            BMC is waiting error status request from system software.
> >- *  KCS_PHASE_ABORT_ERROR2:
> >- *            BMC is waiting for idle status afer error from system software.
> >- *  KCS_PHASE_ERROR:
> >- *            BMC has detected a protocol violation at the interface level.
> >- */
> >-enum kcs_phases {
> >-	KCS_PHASE_IDLE,
> >-
> >-	KCS_PHASE_WRITE_START,
> >-	KCS_PHASE_WRITE_DATA,
> >-	KCS_PHASE_WRITE_END_CMD,
> >-	KCS_PHASE_WRITE_DONE,
> >-
> >-	KCS_PHASE_WAIT_READ,
> >-	KCS_PHASE_READ,
> >-
> >-	KCS_PHASE_ABORT_ERROR1,
> >-	KCS_PHASE_ABORT_ERROR2,
> >-	KCS_PHASE_ERROR
> >-};
> >-
> >-/* IPMI 2.0 - Table 9-4, KCS Interface Status Codes */
> >-enum kcs_errors {
> >-	KCS_NO_ERROR                = 0x00,
> >-	KCS_ABORTED_BY_COMMAND      = 0x01,
> >-	KCS_ILLEGAL_CONTROL_CODE    = 0x02,
> >-	KCS_LENGTH_ERROR            = 0x06,
> >-	KCS_UNSPECIFIED_ERROR       = 0xFF
> >-};
> >-
> > /* IPMI 2.0 - 9.5, KCS Interface Registers
> >  * @idr: Input Data Register
> >  * @odr: Output Data Register
> >@@ -76,36 +27,23 @@ struct kcs_ioreg {
> > };
> >
> > struct kcs_bmc_device_ops;
> >+struct kcs_bmc_client;
> >+
> >+struct kcs_bmc_device {
> >+	struct list_head entry;
> >
> >-struct kcs_bmc {
> > 	struct device *dev;
> >-
> >-	const struct kcs_bmc_device_ops *ops;
> >-
> >-	struct kcs_bmc_client client;
> >-
> >-	spinlock_t lock;
> >-
> > 	u32 channel;
> >-	int running;
> >
> > 	struct kcs_ioreg ioreg;
> >
> >-	enum kcs_phases phase;
> >-	enum kcs_errors error;
> >+	const struct kcs_bmc_device_ops *ops;
> >
> >-	wait_queue_head_t queue;
> >-	bool data_in_avail;
> >-	int  data_in_idx;
> >-	u8  *data_in;
> >-
> >-	int  data_out_idx;
> >-	int  data_out_len;
> >-	u8  *data_out;
> >-
> >-	struct mutex mutex;
> >-	u8 *kbuffer;
> >-
> >-	struct miscdevice miscdev;
> >+	spinlock_t lock;
> >+	struct kcs_bmc_client *client;
> > };
> >+
> >+/* Temporary exports while refactoring */
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
> > #endif /* __KCS_BMC_H__ */
> >diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >index 1b313355b1c8..6f26e7366c0b 100644
> >--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
> >+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >@@ -61,7 +61,7 @@
> > #define LPC_STR4             0x11C
> >
> > struct aspeed_kcs_bmc {
> >-	struct kcs_bmc kcs_bmc;
> >+	struct kcs_bmc_device kcs_bmc;
> >
> > 	struct regmap *map;
> > };
> >@@ -71,12 +71,12 @@ struct aspeed_kcs_of_ops {
> > 	int (*get_io_address)(struct platform_device *pdev);
> > };
> >
> >-static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
> >+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc_device *kcs_bmc)
> > {
> > 	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
> > }
> >
> >-static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> >+static u8 aspeed_kcs_inb(struct kcs_bmc_device *kcs_bmc, u32 reg)
> > {
> > 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	u32 val = 0;
> >@@ -88,7 +88,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
> > 	return rc == 0 ? (u8) val : 0;
> > }
> >
> >-static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> >+static void aspeed_kcs_outb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 data)
> > {
> > 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	int rc;
> >@@ -97,7 +97,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
> > 	WARN(rc != 0, "regmap_write() failed: %d\n", rc);
> > }
> >
> >-static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
> >+static void aspeed_kcs_updateb(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 val)
> > {
> > 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> > 	int rc;
> >@@ -119,7 +119,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
> >  *     C. KCS4
> >  *        D / C : CA4h / CA5h
> >  */
> >-static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> >+static void aspeed_kcs_set_address(struct kcs_bmc_device *kcs_bmc, u16 addr)
> > {
> > 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> >
> >@@ -153,7 +153,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
> > 	}
> > }
> >
> >-static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
> >+static void aspeed_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enable)
> > {
> > 	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> >
> >@@ -228,7 +228,7 @@ static const struct kcs_bmc_device_ops aspeed_kcs_ops = {
> >
> > static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> > {
> >-	struct kcs_bmc *kcs_bmc = arg;
> >+	struct kcs_bmc_device *kcs_bmc = arg;
> > 	int rc;
> >
> > 	rc = kcs_bmc_handle_event(kcs_bmc);
> >@@ -238,7 +238,7 @@ static irqreturn_t aspeed_kcs_irq(int irq, void *arg)
> > 	return rc == KCS_BMC_EVENT_HANDLED ? IRQ_HANDLED : IRQ_NONE;
> > }
> >
> >-static int aspeed_kcs_config_irq(struct kcs_bmc *kcs_bmc,
> >+static int aspeed_kcs_config_irq(struct kcs_bmc_device *kcs_bmc,
> > 			struct platform_device *pdev)
> > {
> > 	struct device *dev = &pdev->dev;
> >@@ -338,8 +338,8 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
> > static int aspeed_kcs_probe(struct platform_device *pdev)
> > {
> > 	const struct aspeed_kcs_of_ops *ops;
> >+	struct kcs_bmc_device *kcs_bmc;
> > 	struct aspeed_kcs_bmc *priv;
> >-	struct kcs_bmc *kcs_bmc;
> > 	struct device_node *np;
> > 	int rc, channel, addr;
> >
> >@@ -400,7 +400,7 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> > static int aspeed_kcs_remove(struct platform_device *pdev)
> > {
> > 	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
> >-	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
> >+	struct kcs_bmc_device *kcs_bmc = &priv->kcs_bmc;
> >
> > 	kcs_bmc_remove_device(kcs_bmc);
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >index fd852d8abe48..58c42e76483d 100644
> >--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
> >@@ -8,13 +8,88 @@
> > #include <linux/errno.h>
> > #include <linux/io.h>
> > #include <linux/ipmi_bmc.h>
> >+#include <linux/list.h>
> >+#include <linux/miscdevice.h>
> > #include <linux/module.h>
> >+#include <linux/mutex.h>
> > #include <linux/platform_device.h>
> > #include <linux/poll.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> >
> >-#include "kcs_bmc.h"
> >+#include "kcs_bmc_client.h"
> >+
> >+/* Different phases of the KCS BMC module.
> >+ *  KCS_PHASE_IDLE:
> >+ *            BMC should not be expecting nor sending any data.
> >+ *  KCS_PHASE_WRITE_START:
> >+ *            BMC is receiving a WRITE_START command from system software.
> >+ *  KCS_PHASE_WRITE_DATA:
> >+ *            BMC is receiving a data byte from system software.
> >+ *  KCS_PHASE_WRITE_END_CMD:
> >+ *            BMC is waiting a last data byte from system software.
> >+ *  KCS_PHASE_WRITE_DONE:
> >+ *            BMC has received the whole request from system software.
> >+ *  KCS_PHASE_WAIT_READ:
> >+ *            BMC is waiting the response from the upper IPMI service.
> >+ *  KCS_PHASE_READ:
> >+ *            BMC is transferring the response to system software.
> >+ *  KCS_PHASE_ABORT_ERROR1:
> >+ *            BMC is waiting error status request from system software.
> >+ *  KCS_PHASE_ABORT_ERROR2:
> >+ *            BMC is waiting for idle status afer error from system software.
> >+ *  KCS_PHASE_ERROR:
> >+ *            BMC has detected a protocol violation at the interface level.
> >+ */
> >+enum kcs_ipmi_phases {
> >+	KCS_PHASE_IDLE,
> >+
> >+	KCS_PHASE_WRITE_START,
> >+	KCS_PHASE_WRITE_DATA,
> >+	KCS_PHASE_WRITE_END_CMD,
> >+	KCS_PHASE_WRITE_DONE,
> >+
> >+	KCS_PHASE_WAIT_READ,
> >+	KCS_PHASE_READ,
> >+
> >+	KCS_PHASE_ABORT_ERROR1,
> >+	KCS_PHASE_ABORT_ERROR2,
> >+	KCS_PHASE_ERROR
> >+};
> >+
> >+/* IPMI 2.0 - Table 9-4, KCS Interface Status Codes */
> >+enum kcs_ipmi_errors {
> >+	KCS_NO_ERROR                = 0x00,
> >+	KCS_ABORTED_BY_COMMAND      = 0x01,
> >+	KCS_ILLEGAL_CONTROL_CODE    = 0x02,
> >+	KCS_LENGTH_ERROR            = 0x06,
> >+	KCS_UNSPECIFIED_ERROR       = 0xFF
> >+};
> >+
> >+struct kcs_bmc_ipmi {
> >+	struct list_head entry;
> >+
> >+	struct kcs_bmc_client client;
> >+
> >+	spinlock_t lock;
> >+
> >+	enum kcs_ipmi_phases phase;
> >+	enum kcs_ipmi_errors error;
> >+
> >+	wait_queue_head_t queue;
> >+	bool data_in_avail;
> >+	int  data_in_idx;
> >+	u8  *data_in;
> >+
> >+	int  data_out_idx;
> >+	int  data_out_len;
> >+	u8  *data_out;
> >+
> >+	struct mutex mutex;
> >+	u8 *kbuffer;
> >+
> >+	struct miscdevice miscdev;
> >+};
> >
> > #define DEVICE_NAME "ipmi-kcs"
> >
> >@@ -44,171 +119,169 @@ enum kcs_states {
> > #define KCS_CMD_WRITE_END         0x62
> > #define KCS_CMD_READ_BYTE         0x68
> >
> >-static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
> >+static inline void set_state(struct kcs_bmc_ipmi *priv, u8 state)
> > {
> >-	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
> >-					KCS_STATUS_STATE(state));
> >+	kcs_bmc_update_status(priv->client.dev, KCS_STATUS_STATE_MASK, KCS_STATUS_STATE(state));
> > }
> >
> >-static void kcs_bmc_ipmi_force_abort(struct kcs_bmc *kcs_bmc)
> >+static void kcs_bmc_ipmi_force_abort(struct kcs_bmc_ipmi *priv)
> > {
> >-	set_state(kcs_bmc, ERROR_STATE);
> >-	kcs_bmc_read_data(kcs_bmc);
> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >+	set_state(priv, ERROR_STATE);
> >+	kcs_bmc_read_data(priv->client.dev);
> >+	kcs_bmc_write_data(priv->client.dev, KCS_ZERO_DATA);
> >
> >-	kcs_bmc->phase = KCS_PHASE_ERROR;
> >-	kcs_bmc->data_in_avail = false;
> >-	kcs_bmc->data_in_idx = 0;
> >+	priv->phase = KCS_PHASE_ERROR;
> >+	priv->data_in_avail = false;
> >+	priv->data_in_idx = 0;
> > }
> >
> >-static void kcs_bmc_ipmi_handle_data(struct kcs_bmc *kcs_bmc)
> >+static void kcs_bmc_ipmi_handle_data(struct kcs_bmc_ipmi *priv)
> > {
> >+	struct kcs_bmc_device *dev;
> > 	u8 data;
> >
> >-	switch (kcs_bmc->phase) {
> >+	dev = priv->client.dev;
> >+
> >+	switch (priv->phase) {
> > 	case KCS_PHASE_WRITE_START:
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
> >+		priv->phase = KCS_PHASE_WRITE_DATA;
> > 		fallthrough;
> >
> > 	case KCS_PHASE_WRITE_DATA:
> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
> >-			set_state(kcs_bmc, WRITE_STATE);
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
> >-						kcs_bmc_read_data(kcs_bmc);
> >+		if (priv->data_in_idx < KCS_MSG_BUFSIZ) {
> >+			set_state(priv, WRITE_STATE);
> >+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
> >+			priv->data_in[priv->data_in_idx++] = kcs_bmc_read_data(dev);
> > 		} else {
> >-			kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
> >+			kcs_bmc_ipmi_force_abort(priv);
> >+			priv->error = KCS_LENGTH_ERROR;
> > 		}
> > 		break;
> >
> > 	case KCS_PHASE_WRITE_END_CMD:
> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
> >-			set_state(kcs_bmc, READ_STATE);
> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
> >-						kcs_bmc_read_data(kcs_bmc);
> >-			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
> >-			kcs_bmc->data_in_avail = true;
> >-			wake_up_interruptible(&kcs_bmc->queue);
> >+		if (priv->data_in_idx < KCS_MSG_BUFSIZ) {
> >+			set_state(priv, READ_STATE);
> >+			priv->data_in[priv->data_in_idx++] = kcs_bmc_read_data(dev);
> >+			priv->phase = KCS_PHASE_WRITE_DONE;
> >+			priv->data_in_avail = true;
> >+			wake_up_interruptible(&priv->queue);
> > 		} else {
> >-			kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
> >+			kcs_bmc_ipmi_force_abort(priv);
> >+			priv->error = KCS_LENGTH_ERROR;
> > 		}
> > 		break;
> >
> > 	case KCS_PHASE_READ:
> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
> >-			set_state(kcs_bmc, IDLE_STATE);
> >+		if (priv->data_out_idx == priv->data_out_len)
> >+			set_state(priv, IDLE_STATE);
> >
> >-		data = kcs_bmc_read_data(kcs_bmc);
> >+		data = kcs_bmc_read_data(dev);
> > 		if (data != KCS_CMD_READ_BYTE) {
> >-			set_state(kcs_bmc, ERROR_STATE);
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >+			set_state(priv, ERROR_STATE);
> >+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
> > 			break;
> > 		}
> >
> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-			kcs_bmc->phase = KCS_PHASE_IDLE;
> >+		if (priv->data_out_idx == priv->data_out_len) {
> >+			kcs_bmc_write_data(dev, KCS_ZERO_DATA);
> >+			priv->phase = KCS_PHASE_IDLE;
> > 			break;
> > 		}
> >
> >-		kcs_bmc_write_data(kcs_bmc,
> >-			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
> >+		kcs_bmc_write_data(dev, priv->data_out[priv->data_out_idx++]);
> > 		break;
> >
> > 	case KCS_PHASE_ABORT_ERROR1:
> >-		set_state(kcs_bmc, READ_STATE);
> >-		kcs_bmc_read_data(kcs_bmc);
> >-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
> >+		set_state(priv, READ_STATE);
> >+		kcs_bmc_read_data(dev);
> >+		kcs_bmc_write_data(dev, priv->error);
> >+		priv->phase = KCS_PHASE_ABORT_ERROR2;
> > 		break;
> >
> > 	case KCS_PHASE_ABORT_ERROR2:
> >-		set_state(kcs_bmc, IDLE_STATE);
> >-		kcs_bmc_read_data(kcs_bmc);
> >-		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >-		kcs_bmc->phase = KCS_PHASE_IDLE;
> >+		set_state(priv, IDLE_STATE);
> >+		kcs_bmc_read_data(dev);
> >+		kcs_bmc_write_data(dev, KCS_ZERO_DATA);
> >+		priv->phase = KCS_PHASE_IDLE;
> > 		break;
> >
> > 	default:
> >-		kcs_bmc_ipmi_force_abort(kcs_bmc);
> >+		kcs_bmc_ipmi_force_abort(priv);
> > 		break;
> > 	}
> > }
> >
> >-static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc *kcs_bmc)
> >+static void kcs_bmc_ipmi_handle_cmd(struct kcs_bmc_ipmi *priv)
> > {
> > 	u8 cmd;
> >
> >-	set_state(kcs_bmc, WRITE_STATE);
> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
> >+	set_state(priv, WRITE_STATE);
> >+	kcs_bmc_write_data(priv->client.dev, KCS_ZERO_DATA);
> >
> >-	cmd = kcs_bmc_read_data(kcs_bmc);
> >+	cmd = kcs_bmc_read_data(priv->client.dev);
> > 	switch (cmd) {
> > 	case KCS_CMD_WRITE_START:
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_START;
> >-		kcs_bmc->error = KCS_NO_ERROR;
> >-		kcs_bmc->data_in_avail = false;
> >-		kcs_bmc->data_in_idx = 0;
> >+		priv->phase = KCS_PHASE_WRITE_START;
> >+		priv->error = KCS_NO_ERROR;
> >+		priv->data_in_avail = false;
> >+		priv->data_in_idx = 0;
> > 		break;
> >
> > 	case KCS_CMD_WRITE_END:
> >-		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
> >-			kcs_bmc_ipmi_force_abort(kcs_bmc);
> >+		if (priv->phase != KCS_PHASE_WRITE_DATA) {
> >+			kcs_bmc_ipmi_force_abort(priv);
> > 			break;
> > 		}
> >
> >-		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
> >+		priv->phase = KCS_PHASE_WRITE_END_CMD;
> > 		break;
> >
> > 	case KCS_CMD_GET_STATUS_ABORT:
> >-		if (kcs_bmc->error == KCS_NO_ERROR)
> >-			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
> >+		if (priv->error == KCS_NO_ERROR)
> >+			priv->error = KCS_ABORTED_BY_COMMAND;
> >
> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
> >-		kcs_bmc->data_in_avail = false;
> >-		kcs_bmc->data_in_idx = 0;
> >+		priv->phase = KCS_PHASE_ABORT_ERROR1;
> >+		priv->data_in_avail = false;
> >+		priv->data_in_idx = 0;
> > 		break;
> >
> > 	default:
> >-		kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
> >+		kcs_bmc_ipmi_force_abort(priv);
> >+		priv->error = KCS_ILLEGAL_CONTROL_CODE;
> > 		break;
> > 	}
> > }
> >
> >-static inline struct kcs_bmc *client_to_kcs_bmc(struct kcs_bmc_client *client)
> >+static inline struct kcs_bmc_ipmi *client_to_kcs_bmc_ipmi(struct kcs_bmc_client *client)
> > {
> >-	return container_of(client, struct kcs_bmc, client);
> >+	return container_of(client, struct kcs_bmc_ipmi, client);
> > }
> >
> > static int kcs_bmc_ipmi_event(struct kcs_bmc_client *client)
> > {
> >-	struct kcs_bmc *kcs_bmc;
> >-	unsigned long flags;
> >+	struct kcs_bmc_ipmi *priv;
> > 	u8 status;
> > 	int ret;
> >
> >-	kcs_bmc = client_to_kcs_bmc(client);
> >+	priv = client_to_kcs_bmc_ipmi(client);
> >+	if (!priv)
> >+		return KCS_BMC_EVENT_NONE;
> >
> >-	spin_lock_irqsave(&kcs_bmc->lock, flags);
> >+	spin_lock(&priv->lock);
> >
> >-	status = kcs_bmc_read_status(kcs_bmc);
> >+	status = kcs_bmc_read_status(client->dev);
> > 	if (status & KCS_STATUS_IBF) {
> >-		if (!kcs_bmc->running)
> >-			kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-		else if (status & KCS_STATUS_CMD_DAT)
> >-			kcs_bmc_ipmi_handle_cmd(kcs_bmc);
> >+		if (status & KCS_STATUS_CMD_DAT)
> >+			kcs_bmc_ipmi_handle_cmd(priv);
> > 		else
> >-			kcs_bmc_ipmi_handle_data(kcs_bmc);
> >+			kcs_bmc_ipmi_handle_data(priv);
> >
> > 		ret = KCS_BMC_EVENT_HANDLED;
> > 	} else {
> > 		ret = KCS_BMC_EVENT_NONE;
> > 	}
> >
> >-	spin_unlock_irqrestore(&kcs_bmc->lock, flags);
> >+	spin_unlock(&priv->lock);
> >
> > 	return ret;
> > }
> >@@ -217,37 +290,29 @@ static const struct kcs_bmc_client_ops kcs_bmc_ipmi_client_ops = {
> > 	.event = kcs_bmc_ipmi_event,
> > };
> >
> >-static inline struct kcs_bmc *file_to_kcs_bmc(struct file *filp)
> >+static inline struct kcs_bmc_ipmi *to_kcs_bmc(struct file *filp)
> > {
> >-	return container_of(filp->private_data, struct kcs_bmc, miscdev);
> >+	return container_of(filp->private_data, struct kcs_bmc_ipmi, miscdev);
> > }
> >
> > static int kcs_bmc_ipmi_open(struct inode *inode, struct file *filp)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >-	int ret = 0;
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	if (!kcs_bmc->running)
> >-		kcs_bmc->running = 1;
> >-	else
> >-		ret = -EBUSY;
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >-
> >-	return ret;
> >+	return kcs_bmc_enable_device(priv->client.dev, &priv->client);
> > }
> >
> > static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> > 	__poll_t mask = 0;
> >
> >-	poll_wait(filp, &kcs_bmc->queue, wait);
> >+	poll_wait(filp, &priv->queue, wait);
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	if (kcs_bmc->data_in_avail)
> >+	spin_lock_irq(&priv->lock);
> >+	if (priv->data_in_avail)
> > 		mask |= EPOLLIN;
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_unlock_irq(&priv->lock);
> >
> > 	return mask;
> > }
> >@@ -255,24 +320,24 @@ static __poll_t kcs_bmc_ipmi_poll(struct file *filp, poll_table *wait)
> > static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> > 			    size_t count, loff_t *ppos)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> > 	bool data_avail;
> > 	size_t data_len;
> > 	ssize_t ret;
> >
> > 	if (!(filp->f_flags & O_NONBLOCK))
> >-		wait_event_interruptible(kcs_bmc->queue,
> >-					 kcs_bmc->data_in_avail);
> >+		wait_event_interruptible(priv->queue,
> >+					 priv->data_in_avail);
> >
> >-	mutex_lock(&kcs_bmc->mutex);
> >+	mutex_lock(&priv->mutex);
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	data_avail = kcs_bmc->data_in_avail;
> >+	spin_lock_irq(&priv->lock);
> >+	data_avail = priv->data_in_avail;
> > 	if (data_avail) {
> >-		data_len = kcs_bmc->data_in_idx;
> >-		memcpy(kcs_bmc->kbuffer, kcs_bmc->data_in, data_len);
> >+		data_len = priv->data_in_idx;
> >+		memcpy(priv->kbuffer, priv->data_in, data_len);
> > 	}
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_unlock_irq(&priv->lock);
> >
> > 	if (!data_avail) {
> > 		ret = -EAGAIN;
> >@@ -281,35 +346,35 @@ static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> >
> > 	if (count < data_len) {
> > 		pr_err("channel=%u with too large data : %zu\n",
> >-			kcs_bmc->channel, data_len);
> >+			priv->client.dev->channel, data_len);
> >
> >-		spin_lock_irq(&kcs_bmc->lock);
> >-		kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-		spin_unlock_irq(&kcs_bmc->lock);
> >+		spin_lock_irq(&priv->lock);
> >+		kcs_bmc_ipmi_force_abort(priv);
> >+		spin_unlock_irq(&priv->lock);
> >
> > 		ret = -EOVERFLOW;
> > 		goto out_unlock;
> > 	}
> >
> >-	if (copy_to_user(buf, kcs_bmc->kbuffer, data_len)) {
> >+	if (copy_to_user(buf, priv->kbuffer, data_len)) {
> > 		ret = -EFAULT;
> > 		goto out_unlock;
> > 	}
> >
> > 	ret = data_len;
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	if (kcs_bmc->phase == KCS_PHASE_WRITE_DONE) {
> >-		kcs_bmc->phase = KCS_PHASE_WAIT_READ;
> >-		kcs_bmc->data_in_avail = false;
> >-		kcs_bmc->data_in_idx = 0;
> >+	spin_lock_irq(&priv->lock);
> >+	if (priv->phase == KCS_PHASE_WRITE_DONE) {
> >+		priv->phase = KCS_PHASE_WAIT_READ;
> >+		priv->data_in_avail = false;
> >+		priv->data_in_idx = 0;
> > 	} else {
> > 		ret = -EAGAIN;
> > 	}
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_unlock_irq(&priv->lock);
> >
> > out_unlock:
> >-	mutex_unlock(&kcs_bmc->mutex);
> >+	mutex_unlock(&priv->mutex);
> >
> > 	return ret;
> > }
> >@@ -317,35 +382,35 @@ static ssize_t kcs_bmc_ipmi_read(struct file *filp, char __user *buf,
> > static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> > 			     size_t count, loff_t *ppos)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> > 	ssize_t ret;
> >
> > 	/* a minimum response size '3' : netfn + cmd + ccode */
> > 	if (count < 3 || count > KCS_MSG_BUFSIZ)
> > 		return -EINVAL;
> >
> >-	mutex_lock(&kcs_bmc->mutex);
> >+	mutex_lock(&priv->mutex);
> >
> >-	if (copy_from_user(kcs_bmc->kbuffer, buf, count)) {
> >+	if (copy_from_user(priv->kbuffer, buf, count)) {
> > 		ret = -EFAULT;
> > 		goto out_unlock;
> > 	}
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	if (kcs_bmc->phase == KCS_PHASE_WAIT_READ) {
> >-		kcs_bmc->phase = KCS_PHASE_READ;
> >-		kcs_bmc->data_out_idx = 1;
> >-		kcs_bmc->data_out_len = count;
> >-		memcpy(kcs_bmc->data_out, kcs_bmc->kbuffer, count);
> >-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->data_out[0]);
> >+	spin_lock_irq(&priv->lock);
> >+	if (priv->phase == KCS_PHASE_WAIT_READ) {
> >+		priv->phase = KCS_PHASE_READ;
> >+		priv->data_out_idx = 1;
> >+		priv->data_out_len = count;
> >+		memcpy(priv->data_out, priv->kbuffer, count);
> >+		kcs_bmc_write_data(priv->client.dev, priv->data_out[0]);
> > 		ret = count;
> > 	} else {
> > 		ret = -EINVAL;
> > 	}
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_unlock_irq(&priv->lock);
> >
> > out_unlock:
> >-	mutex_unlock(&kcs_bmc->mutex);
> >+	mutex_unlock(&priv->mutex);
> >
> > 	return ret;
> > }
> >@@ -353,22 +418,22 @@ static ssize_t kcs_bmc_ipmi_write(struct file *filp, const char __user *buf,
> > static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
> > 			  unsigned long arg)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> > 	long ret = 0;
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >+	spin_lock_irq(&priv->lock);
> >
> > 	switch (cmd) {
> > 	case IPMI_BMC_IOCTL_SET_SMS_ATN:
> >-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
> >+		kcs_bmc_update_status(priv->client.dev, KCS_STATUS_SMS_ATN, KCS_STATUS_SMS_ATN);
> > 		break;
> >
> > 	case IPMI_BMC_IOCTL_CLEAR_SMS_ATN:
> >-		kcs_bmc_update_status(kcs_bmc, KCS_STATUS_SMS_ATN, 0);
> >+		kcs_bmc_update_status(priv->client.dev, KCS_STATUS_SMS_ATN, 0);
> > 		break;
> >
> > 	case IPMI_BMC_IOCTL_FORCE_ABORT:
> >-		kcs_bmc_ipmi_force_abort(kcs_bmc);
> >+		kcs_bmc_ipmi_force_abort(priv);
> > 		break;
> >
> > 	default:
> >@@ -376,19 +441,17 @@ static long kcs_bmc_ipmi_ioctl(struct file *filp, unsigned int cmd,
> > 		break;
> > 	}
> >
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_unlock_irq(&priv->lock);
> >
> > 	return ret;
> > }
> >
> > static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
> > {
> >-	struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
> >+	struct kcs_bmc_ipmi *priv = to_kcs_bmc(filp);
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	kcs_bmc->running = 0;
> >-	kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	kcs_bmc_ipmi_force_abort(priv);
> >+	kcs_bmc_disable_device(priv->client.dev, &priv->client);
> >
> > 	return 0;
> > }
> >@@ -403,56 +466,78 @@ static const struct file_operations kcs_bmc_ipmi_fops = {
> > 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
> > };
> >
> >-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
> >-int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
> >+static DEFINE_SPINLOCK(kcs_bmc_ipmi_instances_lock);
> >+static LIST_HEAD(kcs_bmc_ipmi_instances);
> >+
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc);
> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc_device *kcs_bmc)
> > {
> >+	struct kcs_bmc_ipmi *priv;
> > 	int rc;
> >
> >-	spin_lock_init(&kcs_bmc->lock);
> >-	mutex_init(&kcs_bmc->mutex);
> >-	init_waitqueue_head(&kcs_bmc->queue);
> >-
> >-	kcs_bmc->client.dev = kcs_bmc;
> >-	kcs_bmc->client.ops = &kcs_bmc_ipmi_client_ops;
> >-	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >-	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >-	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >-
> >-	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
> >-	kcs_bmc->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u",
> >-					       DEVICE_NAME, kcs_bmc->channel);
> >-	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
> >-	    !kcs_bmc->miscdev.name)
> >+	priv = devm_kzalloc(kcs_bmc->dev, sizeof(*priv), GFP_KERNEL);
> >+	if (!priv)
> > 		return -ENOMEM;
> >
> >-	kcs_bmc->miscdev.fops = &kcs_bmc_ipmi_fops;
> >+	spin_lock_init(&priv->lock);
> >+	mutex_init(&priv->mutex);
> >
> >-	rc = misc_register(&kcs_bmc->miscdev);
> >+	init_waitqueue_head(&priv->queue);
> >+
> >+	priv->client.dev = kcs_bmc;
> >+	priv->client.ops = &kcs_bmc_ipmi_client_ops;
> >+	priv->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+	priv->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+	priv->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
> >+
> >+	priv->miscdev.minor = MISC_DYNAMIC_MINOR;
> >+	priv->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u", DEVICE_NAME,
> >+					   kcs_bmc->channel);
> >+	if (!priv->data_in || !priv->data_out || !priv->kbuffer || !priv->miscdev.name)
> >+		return -EINVAL;
> >+
> >+	priv->miscdev.fops = &kcs_bmc_ipmi_fops;
> >+
> >+	rc = misc_register(&priv->miscdev);
> > 	if (rc) {
> > 		dev_err(kcs_bmc->dev, "Unable to register device: %d\n", rc);
> > 		return rc;
> > 	}
> >
> >+	spin_lock_irq(&kcs_bmc_ipmi_instances_lock);
> >+	list_add(&priv->entry, &kcs_bmc_ipmi_instances);
> >+	spin_unlock_irq(&kcs_bmc_ipmi_instances_lock);
> >+
> > 	dev_info(kcs_bmc->dev, "Initialised IPMI client for channel %d", kcs_bmc->channel);
> >
> > 	return 0;
> > }
> > EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
> >
> >-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
> >-int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc)
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc);
> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc_device *kcs_bmc)
> > {
> >-	misc_deregister(&kcs_bmc->miscdev);
> >+	struct kcs_bmc_ipmi *priv = NULL, *pos;
> >
> >-	spin_lock_irq(&kcs_bmc->lock);
> >-	kcs_bmc->running = 0;
> >-	kcs_bmc_ipmi_force_abort(kcs_bmc);
> >-	spin_unlock_irq(&kcs_bmc->lock);
> >+	spin_lock_irq(&kcs_bmc_ipmi_instances_lock);
> >+	list_for_each_entry(pos, &kcs_bmc_ipmi_instances, entry) {
> >+		if (pos->client.dev == kcs_bmc) {
> >+			priv = pos;
> >+			list_del(&pos->entry);
> >+			break;
> >+		}
> >+	}
> >+	spin_unlock_irq(&kcs_bmc_ipmi_instances_lock);
> >
> >-	devm_kfree(kcs_bmc->dev, kcs_bmc->kbuffer);
> >-	devm_kfree(kcs_bmc->dev, kcs_bmc->data_out);
> >-	devm_kfree(kcs_bmc->dev, kcs_bmc->data_in);
> >-	devm_kfree(kcs_bmc->dev, kcs_bmc);
> >+	if (!priv)
> >+		return 0;
> 
> Would -ENOENT or something be appropriate here if the thing we're trying
> to detach isn't found?

Maybe -ENODEV. Let me think about this.

Cheers,

Andrew


From krzk at kernel.org  Fri Apr  9 07:17:06 2021
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Fri, 9 Apr 2021 08:17:06 +0200
Subject: [PATCH -next] hwrng: exynos - fix PM reference leak in
 exynos_trng_probe()
In-Reply-To: <20210409061125.214255-1-yeweihua4@huawei.com>
References: <20210409061125.214255-1-yeweihua4@huawei.com>
Message-ID: <CAJKOXPfvg1o1kTqm7=E6BmXe06=SwE413fqz=VDHnAGcfMW0ow@mail.gmail.com>

On Fri, 9 Apr 2021 at 08:11, Ye Weihua <yeweihua4 at huawei.com> wrote:
>
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
>
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>

Hi,

The same Lukasz' comment applies here as for Qinglang's patch from
November 2020 - resume also needs fix up.

Best regards,
Krzysztof


From zweiss at equinix.com  Fri Apr  9 07:25:27 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 06:25:27 +0000
Subject: [PATCH v2 10/21] ipmi: kcs_bmc: Turn the driver data-structures
 inside-out
In-Reply-To: <ea34ee69-a266-4737-8450-4695d2d0fbd4@www.fastmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-10-andrew@aj.id.au> <YG/Ql9z9X/mtOSvl@packtop>
 <ea34ee69-a266-4737-8450-4695d2d0fbd4@www.fastmail.com>
Message-ID: <YG/zVv4XOo1HoLd1@packtop>

On Fri, Apr 09, 2021 at 12:59:09AM CDT, Andrew Jeffery wrote:
>
>
>On Fri, 9 Apr 2021, at 13:27, Zev Weiss wrote:
>> On Fri, Mar 19, 2021 at 01:27:41AM CDT, Andrew Jeffery wrote:
>> >Make the KCS device drivers responsible for allocating their own memory.
>> >
>> >Until now the private data for the device driver was allocated internal
>> >to the private data for the chardev interface. This coupling required
>> >the slightly awkward API of passing through the struct size for the
>> >driver private data to the chardev constructor, and then retrieving a
>> >pointer to the driver private data from the allocated chardev memory.
>> >
>> >In addition to being awkward, the arrangement prevents the
>> >implementation of alternative userspace interfaces as the device driver
>> >private data is not independent.
>> >
>> >Peel a layer off the onion and turn the data-structures inside out by
>> >exploiting container_of() and embedding `struct kcs_device` in the
>> >driver private data.
>> >
>> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>> >---
>> > drivers/char/ipmi/kcs_bmc.c           | 15 +++++--
>> > drivers/char/ipmi/kcs_bmc.h           | 12 ++----
>> > drivers/char/ipmi/kcs_bmc_aspeed.c    | 60 ++++++++++++++++-----------
>> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 60 ++++++++++++++++++---------
>> > drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 37 ++++++++++-------
>> > 5 files changed, 113 insertions(+), 71 deletions(-)
>> >
>> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>> >index ef5c48ffe74a..709b6bdec165 100644
>> >--- a/drivers/char/ipmi/kcs_bmc.c
>> >+++ b/drivers/char/ipmi/kcs_bmc.c
>> >@@ -44,12 +44,19 @@ int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
>> > }
>> > EXPORT_SYMBOL(kcs_bmc_handle_event);
>> >
>> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>> >-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel)
>> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>>
>> Another declaration perhaps intended for kcs_bmc.h?
>
>These are temporary while the code gets shuffled around. The symbol
>name is an implementation detail, not a "public" part of the API; after
>some further shuffling these are eventually assigned as callbacks in an
>ops struct.
>

Okay, that makes sense.

>>
>> >+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
>> > {
>> >-	return kcs_bmc_ipmi_alloc(dev, sizeof_priv, channel);
>> >+	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
>> > }
>> >-EXPORT_SYMBOL(kcs_bmc_alloc);
>> >+EXPORT_SYMBOL(kcs_bmc_add_device);
>> >+
>> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
>>
>> Here too.
>>
>> >+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
>> >+{
>> >+	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
>> >+}
>> >+EXPORT_SYMBOL(kcs_bmc_remove_device);
>> >
>> > MODULE_LICENSE("GPL v2");
>> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>> >diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>> >index febea0c8deb4..bf0ae327997f 100644
>> >--- a/drivers/char/ipmi/kcs_bmc.h
>> >+++ b/drivers/char/ipmi/kcs_bmc.h
>> >@@ -67,6 +67,8 @@ struct kcs_ioreg {
>> > };
>> >
>> > struct kcs_bmc {
>> >+	struct device *dev;
>> >+
>> > 	spinlock_t lock;
>> >
>> > 	u32 channel;
>> >@@ -94,17 +96,11 @@ struct kcs_bmc {
>> > 	u8 *kbuffer;
>> >
>> > 	struct miscdevice miscdev;
>> >-
>> >-	unsigned long priv[];
>> > };
>> >
>> >-static inline void *kcs_bmc_priv(struct kcs_bmc *kcs_bmc)
>> >-{
>> >-	return kcs_bmc->priv;
>> >-}
>> >-
>> > int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>> >-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel);
>> >+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>> >+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>> >
>> > u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>> > void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>> >diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>> >index 630cf095560e..0416ac78ce68 100644
>> >--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>> >+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>> >@@ -61,6 +61,8 @@
>> > #define LPC_STR4             0x11C
>> >
>> > struct aspeed_kcs_bmc {
>> >+	struct kcs_bmc kcs_bmc;
>> >+
>> > 	struct regmap *map;
>> > };
>> >
>> >@@ -69,9 +71,14 @@ struct aspeed_kcs_of_ops {
>> > 	int (*get_io_address)(struct platform_device *pdev);
>> > };
>> >
>> >+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
>> >+{
>> >+	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
>> >+}
>> >+
>> > static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>> > {
>> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>> > 	u32 val = 0;
>> > 	int rc;
>> >
>> >@@ -83,7 +90,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>> >
>> > static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>> > {
>> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>> > 	int rc;
>> >
>> > 	rc = regmap_write(priv->map, reg, data);
>> >@@ -92,7 +99,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>> >
>> > static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
>> > {
>> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>> > 	int rc;
>> >
>> > 	rc = regmap_update_bits(priv->map, reg, mask, val);
>> >@@ -114,7 +121,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
>> >  */
>> > static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>> > {
>> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>> >
>> > 	switch (kcs_bmc->channel) {
>> > 	case 1:
>> >@@ -148,7 +155,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>> >
>> > static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>> > {
>> >-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>> >
>> > 	switch (kcs_bmc->channel) {
>> > 	case 1:
>> >@@ -323,16 +330,16 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
>> > static int aspeed_kcs_probe(struct platform_device *pdev)
>> > {
>> > 	const struct aspeed_kcs_of_ops *ops;
>> >-	struct device *dev = &pdev->dev;
>> >+	struct aspeed_kcs_bmc *priv;
>> > 	struct kcs_bmc *kcs_bmc;
>> > 	struct device_node *np;
>> > 	int rc, channel, addr;
>> >
>> >-	np = dev->of_node->parent;
>> >+	np = pdev->dev.of_node->parent;
>> > 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
>> > 	    !of_device_is_compatible(np, "aspeed,ast2500-lpc-v2") &&
>> > 	    !of_device_is_compatible(np, "aspeed,ast2600-lpc-v2")) {
>> >-		dev_err(dev, "unsupported LPC device binding\n");
>> >+		dev_err(&pdev->dev, "unsupported LPC device binding\n");
>> > 		return -ENODEV;
>> > 	}
>> > 	ops = of_device_get_match_data(&pdev->dev);
>> >@@ -343,18 +350,27 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>> > 	if (channel < 0)
>> > 		return channel;
>> >
>> >-	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>> >-	if (!kcs_bmc)
>> >+	addr = ops->get_io_address(pdev);
>> >+	if (addr < 0)
>> >+		return addr;
>> >+
>> >+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> >+	if (!priv)
>> > 		return -ENOMEM;
>> >
>> >+	kcs_bmc = &priv->kcs_bmc;
>> >+	kcs_bmc->dev = &pdev->dev;
>> >+	kcs_bmc->channel = channel;
>> > 	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
>> > 	kcs_bmc->io_inputb = aspeed_kcs_inb;
>> > 	kcs_bmc->io_outputb = aspeed_kcs_outb;
>> > 	kcs_bmc->io_updateb = aspeed_kcs_updateb;
>> >
>> >-	addr = ops->get_io_address(pdev);
>> >-	if (addr < 0)
>> >-		return addr;
>> >+	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>> >+	if (IS_ERR(priv->map)) {
>> >+		dev_err(&pdev->dev, "Couldn't get regmap\n");
>> >+		return -ENODEV;
>> >+	}
>>
>> The reanimated priv->map initialization I suspect wasn't meant to
>> have been removed in the first place...
>
>Yeah, I'll have to go back and figure out what went wrong there!
>
>Thanks for catching that.
>
>>
>> >
>> > 	aspeed_kcs_set_address(kcs_bmc, addr);
>> >
>> >@@ -362,29 +378,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>> > 	if (rc)
>> > 		return rc;
>> >
>> >-	dev_set_drvdata(dev, kcs_bmc);
>> >+	platform_set_drvdata(pdev, priv);
>> >
>> > 	aspeed_kcs_enable_channel(kcs_bmc, true);
>> >
>> >-	rc = misc_register(&kcs_bmc->miscdev);
>> >-	if (rc) {
>> >-		dev_err(dev, "Unable to register device\n");
>> >+	rc = kcs_bmc_add_device(&priv->kcs_bmc);
>> >+	if (rc < 0)
>> > 		return rc;
>> >-	}
>> >
>> >-	dev_dbg(&pdev->dev,
>> >-		"Probed KCS device %d (IDR=0x%x, ODR=0x%x, STR=0x%x)\n",
>> >-		kcs_bmc->channel, kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr,
>> >-		kcs_bmc->ioreg.str);
>> >+	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n", kcs_bmc->channel, addr);
>>
>> Is the dbg->info change here intentional?  (I have no particular
>> objection if so, but it's often a change I make myself during
>> testing/debugging and then forget to revert...)
>
>Yeah, it was possibly something I forgot to revert. If others have
>issues with it staying at dev_info() I'll switch it back.
>
>>
>> >
>> > 	return 0;
>> > }
>> >
>> > static int aspeed_kcs_remove(struct platform_device *pdev)
>> > {
>> >-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
>> >+	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
>> >+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>> >
>> >-	misc_deregister(&kcs_bmc->miscdev);
>> >+	kcs_bmc_remove_device(kcs_bmc);
>>
>> Should we propagate the return value outward here?
>
>Probably!
>
>>
>> >
>> > 	return 0;
>> > }
>> >diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>> >index 82c77994e481..0ca71c135a1a 100644
>> >--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>> >+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>> >@@ -382,7 +382,7 @@ static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
>> > 	return 0;
>> > }
>> >
>> >-static const struct file_operations kcs_bmc_fops = {
>> >+static const struct file_operations kcs_bmc_ipmi_fops = {
>> > 	.owner          = THIS_MODULE,
>> > 	.open           = kcs_bmc_ipmi_open,
>> > 	.read           = kcs_bmc_ipmi_read,
>> >@@ -392,36 +392,58 @@ static const struct file_operations kcs_bmc_fops = {
>> > 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
>> > };
>> >
>> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>> >-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
>> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>>
>> Errant declaration again?
>
>As previously explained.
>

This one seems like a slightly different category, because...

>>
>> >+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)

...it's immediately followed by the definition of the very same function
that it just declared, so I can't see how its presence or absence could
make any functional difference to anything.  (So perhaps I should have
said "redundant" instead of "errant...again".)

It's fairly trivial of course given that it's gone by the end of the
series, but as long as there's going to be another iteration anyway it
seems like we might as well tidy it up?

>> > {
>> >-	struct kcs_bmc *kcs_bmc;
>> >-
>> >-	kcs_bmc = devm_kzalloc(dev, sizeof(*kcs_bmc) + sizeof_priv, GFP_KERNEL);
>> >-	if (!kcs_bmc)
>> >-		return NULL;
>> >+	int rc;
>> >
>> > 	spin_lock_init(&kcs_bmc->lock);
>> >-	kcs_bmc->channel = channel;
>> >-
>> > 	mutex_init(&kcs_bmc->mutex);
>> > 	init_waitqueue_head(&kcs_bmc->queue);
>> >
>> >-	kcs_bmc->data_in = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >-	kcs_bmc->data_out = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >-	kcs_bmc->kbuffer = devm_kmalloc(dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >+	kcs_bmc->data_in = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >+	kcs_bmc->data_out = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >+	kcs_bmc->kbuffer = devm_kmalloc(kcs_bmc->dev, KCS_MSG_BUFSIZ, GFP_KERNEL);
>> >
>> > 	kcs_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
>> >-	kcs_bmc->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s%u",
>> >-					       DEVICE_NAME, channel);
>> >+	kcs_bmc->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u",
>> >+					       DEVICE_NAME, kcs_bmc->channel);
>> > 	if (!kcs_bmc->data_in || !kcs_bmc->data_out || !kcs_bmc->kbuffer ||
>> > 	    !kcs_bmc->miscdev.name)
>> >-		return NULL;
>> >-	kcs_bmc->miscdev.fops = &kcs_bmc_fops;
>> >+		return -ENOMEM;
>> >
>> >-	return kcs_bmc;
>> >+	kcs_bmc->miscdev.fops = &kcs_bmc_ipmi_fops;
>> >+
>> >+	rc = misc_register(&kcs_bmc->miscdev);
>> >+	if (rc) {
>> >+		dev_err(kcs_bmc->dev, "Unable to register device: %d\n", rc);
>> >+		return rc;
>> >+	}
>> >+
>> >+	dev_info(kcs_bmc->dev, "Initialised IPMI client for channel %d", kcs_bmc->channel);
>> >+
>> >+	return 0;
>> >+}
>> >+EXPORT_SYMBOL(kcs_bmc_ipmi_attach_cdev);
>> >+
>> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
>>
>> Same here.
>
>Same explanation.
>

Also a "category 2" I think.

>>
>> >+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc)
>> >+{
>> >+	misc_deregister(&kcs_bmc->miscdev);
>> >+
>> >+	spin_lock_irq(&kcs_bmc->lock);
>> >+	kcs_bmc->running = 0;
>> >+	kcs_bmc_ipmi_force_abort(kcs_bmc);
>> >+	spin_unlock_irq(&kcs_bmc->lock);
>> >+
>> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->kbuffer);
>> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_out);
>> >+	devm_kfree(kcs_bmc->dev, kcs_bmc->data_in);
>> >+	devm_kfree(kcs_bmc->dev, kcs_bmc);
>> >+
>> >+	return 0;
>> > }
>> >-EXPORT_SYMBOL(kcs_bmc_ipmi_alloc);
>> >+EXPORT_SYMBOL(kcs_bmc_ipmi_detach_cdev);
>> >
>> > MODULE_LICENSE("GPL v2");
>> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>> >diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>> >index 1f44aadec9e8..5d017498dc69 100644
>> >--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>> >+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
>> >@@ -65,6 +65,8 @@ struct npcm7xx_kcs_reg {
>> > };
>> >
>> > struct npcm7xx_kcs_bmc {
>> >+	struct kcs_bmc kcs_bmc;
>> >+
>> > 	struct regmap *map;
>> >
>> > 	const struct npcm7xx_kcs_reg *reg;
>> >@@ -76,9 +78,14 @@ static const struct npcm7xx_kcs_reg npcm7xx_kcs_reg_tbl[KCS_CHANNEL_MAX] = {
>> > 	{ .sts = KCS3ST, .dob = KCS3DO, .dib = KCS3DI, .ctl = KCS3CTL, .ie = KCS3IE },
>> > };
>> >
>> >+static inline struct npcm7xx_kcs_bmc *to_npcm7xx_kcs_bmc(struct kcs_bmc *kcs_bmc)
>> >+{
>> >+	return container_of(kcs_bmc, struct npcm7xx_kcs_bmc, kcs_bmc);
>> >+}
>> >+
>> > static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>> > {
>> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>> > 	u32 val = 0;
>> > 	int rc;
>> >
>> >@@ -90,7 +97,7 @@ static u8 npcm7xx_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>> >
>> > static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>> > {
>> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>> > 	int rc;
>> >
>> > 	rc = regmap_write(priv->map, reg, data);
>> >@@ -99,7 +106,7 @@ static void npcm7xx_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>> >
>> > static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 data)
>> > {
>> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>> > 	int rc;
>> >
>> > 	rc = regmap_update_bits(priv->map, reg, mask, data);
>> >@@ -108,7 +115,7 @@ static void npcm7xx_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 da
>> >
>> > static void npcm7xx_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>> > {
>> >-	struct npcm7xx_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
>> >
>> > 	regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
>> > 			   enable ? KCS_CTL_IBFIE : 0);
>> >@@ -155,11 +162,10 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
>> > 		return -ENODEV;
>> > 	}
>> >
>> >-	kcs_bmc = kcs_bmc_alloc(dev, sizeof(*priv), chan);
>> >-	if (!kcs_bmc)
>> >+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> >+	if (!priv)
>> > 		return -ENOMEM;
>> >
>> >-	priv = kcs_bmc_priv(kcs_bmc);
>> > 	priv->map = syscon_node_to_regmap(dev->parent->of_node);
>> > 	if (IS_ERR(priv->map)) {
>> > 		dev_err(dev, "Couldn't get regmap\n");
>> >@@ -167,6 +173,9 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
>> > 	}
>> > 	priv->reg = &npcm7xx_kcs_reg_tbl[chan - 1];
>> >
>> >+	kcs_bmc = &priv->kcs_bmc;
>> >+	kcs_bmc->dev = &pdev->dev;
>> >+	kcs_bmc->channel = chan;
>> > 	kcs_bmc->ioreg.idr = priv->reg->dib;
>> > 	kcs_bmc->ioreg.odr = priv->reg->dob;
>> > 	kcs_bmc->ioreg.str = priv->reg->sts;
>> >@@ -174,31 +183,27 @@ static int npcm7xx_kcs_probe(struct platform_device *pdev)
>> > 	kcs_bmc->io_outputb = npcm7xx_kcs_outb;
>> > 	kcs_bmc->io_updateb = npcm7xx_kcs_updateb;
>> >
>> >-	dev_set_drvdata(dev, kcs_bmc);
>> >+	platform_set_drvdata(pdev, priv);
>> >
>> > 	npcm7xx_kcs_enable_channel(kcs_bmc, true);
>> > 	rc = npcm7xx_kcs_config_irq(kcs_bmc, pdev);
>> > 	if (rc)
>> > 		return rc;
>> >
>> >-	rc = misc_register(&kcs_bmc->miscdev);
>> >-	if (rc) {
>> >-		dev_err(dev, "Unable to register device\n");
>> >-		return rc;
>> >-	}
>> >
>> > 	pr_info("channel=%u idr=0x%x odr=0x%x str=0x%x\n",
>> > 		chan,
>> > 		kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr, kcs_bmc->ioreg.str);
>> >
>> >-	return 0;
>> >+	return kcs_bmc_add_device(kcs_bmc);
>> > }
>> >
>> > static int npcm7xx_kcs_remove(struct platform_device *pdev)
>> > {
>> >-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
>> >+	struct npcm7xx_kcs_bmc *priv = platform_get_drvdata(pdev);
>> >+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>> >
>> >-	misc_deregister(&kcs_bmc->miscdev);
>> >+	kcs_bmc_remove_device(kcs_bmc);
>>
>> As with the corresponding aspeed code, should we propagate the return
>> value here?
>
>I'll address this.
>
>Thanks for the review!
>
>Andrew

From andrew at aj.id.au  Fri Apr  9 07:24:33 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 15:54:33 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_13/21]_ipmi:_kcs=5Fbmc:_Decouple_the_IPMI_charde?=
 =?UTF-8?Q?v_from_the_core?=
In-Reply-To: <YG/ZkanVAypmjCba@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-13-andrew@aj.id.au> <YG/ZkanVAypmjCba@packtop>
Message-ID: <386cc03a-f6d0-45b6-a27b-fc204dedbcac@www.fastmail.com>



On Fri, 9 Apr 2021, at 14:05, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:44AM CDT, Andrew Jeffery wrote:
> >Now that we have untangled the data-structures, split the userspace
> >interface out into its own module. Userspace interfaces and drivers are
> >registered to the KCS BMC core to support arbitrary binding of either.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/Kconfig             | 13 +++++
> > drivers/char/ipmi/Makefile            |  3 +-
> > drivers/char/ipmi/kcs_bmc.c           | 78 ++++++++++++++++++++++++++-
> > drivers/char/ipmi/kcs_bmc.h           |  4 --
> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 33 +++++++++---
> > drivers/char/ipmi/kcs_bmc_client.h    | 14 +++++
> > 6 files changed, 132 insertions(+), 13 deletions(-)
> >
> >diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> >index 07847d9a459a..bc5f81899b62 100644
> >--- a/drivers/char/ipmi/Kconfig
> >+++ b/drivers/char/ipmi/Kconfig
> >@@ -124,6 +124,19 @@ config NPCM7XX_KCS_IPMI_BMC
> > 	  This support is also available as a module.  If so, the module
> > 	  will be called kcs_bmc_npcm7xx.
> >
> >+config IPMI_KCS_BMC_CDEV_IPMI
> >+	depends on IPMI_KCS_BMC
> >+	tristate "IPMI character device interface for BMC KCS devices"
> >+	help
> >+	  Provides a BMC-side character device implementing IPMI
> >+	  semantics for KCS IPMI devices.
> >+
> >+	  Say YES if you wish to expose KCS devices on the BMC for IPMI
> >+	  purposes.
> >+
> >+	  This support is also available as a module. The module will be
> >+	  called kcs_bmc_cdev_ipmi.
> >+
> > config ASPEED_BT_IPMI_BMC
> > 	depends on ARCH_ASPEED || COMPILE_TEST
> > 	depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
> >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> >index a302bc865370..fcfa676afddb 100644
> >--- a/drivers/char/ipmi/Makefile
> >+++ b/drivers/char/ipmi/Makefile
> >@@ -22,7 +22,8 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
> > obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
> > obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> >-obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
> >+obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> >+obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o
> > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> > obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index 266ebec71d6f..694db6ee2a92 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -5,7 +5,9 @@
> >  */
> >
> > #include <linux/device.h>
> >+#include <linux/list.h>
> > #include <linux/module.h>
> >+#include <linux/mutex.h>
> >
> > #include "kcs_bmc.h"
> >
> >@@ -13,6 +15,11 @@
> > #include "kcs_bmc_device.h"
> > #include "kcs_bmc_client.h"
> >
> >+/* Record probed devices and cdevs */
> >+static DEFINE_MUTEX(kcs_bmc_lock);
> >+static LIST_HEAD(kcs_bmc_devices);
> >+static LIST_HEAD(kcs_bmc_cdevs);
> >+
> > /* Consumer data access */
> >
> > u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc)
> >@@ -100,16 +107,83 @@ EXPORT_SYMBOL(kcs_bmc_disable_device);
> >
> > int kcs_bmc_add_device(struct kcs_bmc_device *kcs_bmc)
> > {
> >-	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
> >+	struct kcs_bmc_cdev *cdev;
> >+	int rc;
> >+
> >+	spin_lock_init(&kcs_bmc->lock);
> >+	kcs_bmc->client = NULL;
> >+
> >+	mutex_lock(&kcs_bmc_lock);
> >+	list_add(&kcs_bmc->entry, &kcs_bmc_devices);
> >+	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
> >+		rc = cdev->ops->add_device(kcs_bmc);
> >+		if (rc)
> >+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",
> >+				kcs_bmc->channel, rc);
> >+	}
> >+	mutex_unlock(&kcs_bmc_lock);
> >+
> >+	return 0;
> 
> We're ignoring failed ->add_device() calls here?

Yep. If one chardev module is failing to accept new devices we don't 
want to not add them to the remaining chardev modules.

What would the caller do with a error return value? Maybe it should 
just be void.

> 
> > }
> > EXPORT_SYMBOL(kcs_bmc_add_device);
> >
> > int kcs_bmc_remove_device(struct kcs_bmc_device *kcs_bmc)
> > {
> >-	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
> >+	struct kcs_bmc_cdev *cdev;
> >+	int rc;
> >+
> >+	mutex_lock(&kcs_bmc_lock);
> >+	list_del(&kcs_bmc->entry);
> >+	list_for_each_entry(cdev, &kcs_bmc_cdevs, entry) {
> >+		rc = cdev->ops->remove_device(kcs_bmc);
> >+		if (rc)
> >+			dev_err(kcs_bmc->dev, "Failed to remove chardev for KCS channel %d: %d",
> >+				kcs_bmc->channel, rc);
> >+	}
> >+	mutex_unlock(&kcs_bmc_lock);
> >+
> >+	return 0;
> 
> Similarly with the return value here...

As above.

> 
> > }
> > EXPORT_SYMBOL(kcs_bmc_remove_device);
> >
> >+int kcs_bmc_register_cdev(struct kcs_bmc_cdev *cdev)
> >+{
> >+	struct kcs_bmc_device *kcs_bmc;
> >+	int rc;
> >+
> >+	mutex_lock(&kcs_bmc_lock);
> >+	list_add(&cdev->entry, &kcs_bmc_cdevs);
> >+	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
> >+		rc = cdev->ops->add_device(kcs_bmc);
> >+		if (rc)
> >+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",
> >+				kcs_bmc->channel, rc);
> >+	}
> >+	mutex_unlock(&kcs_bmc_lock);
> >+
> >+	return 0;
> 
> ...return value again here...

As above.

> 
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_register_cdev);
> >+
> >+int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev)
> >+{
> >+	struct kcs_bmc_device *kcs_bmc;
> >+	int rc;
> >+
> >+	mutex_lock(&kcs_bmc_lock);
> >+	list_del(&cdev->entry);
> >+	list_for_each_entry(kcs_bmc, &kcs_bmc_devices, entry) {
> >+		rc = cdev->ops->remove_device(kcs_bmc);
> >+		if (rc)
> >+			dev_err(kcs_bmc->dev, "Failed to add chardev for KCS channel %d: %d",
> 
> s/add/remove/

Thanks.

> 
> Might also want to differentiate the *_device() error messages from the
> *_cdev() ones a bit more?

I'll look into it.

> 
> >+				kcs_bmc->channel, rc);
> >+	}
> >+	mutex_unlock(&kcs_bmc_lock);
> >+
> >+	return rc;
> 
> ...but this one is a bit incongruous, propagating the return value of
> only the last ->remove_device() call.

Hah. good catch.

Andrew


From joel at jms.id.au  Fri Apr  9 07:29:52 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 06:29:52 +0000
Subject: [GIT PULL] ARM: aspeed: lpc changes for 5.13
Message-ID: <CACPK8Xcb12LsVr7CUaXXjQskKbVjb7x+jgueG1Hik-kBPWtDSg@mail.gmail.com>

Hello Soc maintainers,

This is a pull request containing a slightly messy device tree and
associated driver changes for the ASPEED systems. It corrects some
design decisions made when first mainlining support for the BMC
devices on the LPC bus that have stopped us from being able to write
drivers for eg. KCS.

Andrew has worked with Chai-Wei from ASPEED on this process. These set
of changes have acks from the maintainers, and allow Andrew to go
ahead with fixing the KCS drivers in the future. The branch should
apply with no conflicts no matter which order it is merged.

If you would like to handle this another way then let me know.

The following changes since commit 489774ff5db943642751f4f0fdac9033239208c6:

  soc: aspeed: Adapt to new LPC device tree layout (2021-04-09 13:39:22 +0930)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc.git
tags/aspeed-5.13-lpc

for you to fetch changes up to 489774ff5db943642751f4f0fdac9033239208c6:

  soc: aspeed: Adapt to new LPC device tree layout (2021-04-09 13:39:22 +0930)

----------------------------------------------------------------
ASPEED LPC updates for 5.13

These patches fix the ASPEED LPC bindings and LPC-related device drivers
so in the future the KCS driver can properly use the hardware.

----------------------------------------------------------------
Chia-Wei, Wang (5):
      dt-bindings: aspeed-lpc: Remove LPC partitioning
      ARM: dts: Remove LPC BMC and Host partitions
      ipmi: kcs: aspeed: Adapt to new LPC DTS layout
      pinctrl: aspeed-g5: Adapt to new LPC device tree layout
      soc: aspeed: Adapt to new LPC device tree layout


From zev at bewilderbeest.net  Fri Apr  9 07:35:39 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri, 9 Apr 2021 01:35:39 -0500
Subject: [PATCH v5 3/4] drivers/tty/serial/8250: add aspeed, lpc-io-reg
 and aspeed, lpc-interrupts DT properties
In-Reply-To: <3eef2478-c5b8-4f14-a937-16bbe0a3e05a@www.fastmail.com>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-4-zev@bewilderbeest.net>
 <3eef2478-c5b8-4f14-a937-16bbe0a3e05a@www.fastmail.com>
Message-ID: <YG/1u/kxl12sIO0V@hatter.bewilderbeest.net>

On Fri, Apr 09, 2021 at 12:14:54AM CDT, Andrew Jeffery wrote:
>Hi Zev,
>
>A couple of minor comments:
>
>On Thu, 8 Apr 2021, at 10:46, Zev Weiss wrote:
>> These allow describing all the Aspeed VUART attributes currently
>> available via sysfs.  aspeed,sirq
>
>aspeed,lpc-interrupts now

Ah right, thanks.

>
>> provides a replacement for the
>> deprecated aspeed,sirq-polarity-sense property.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 44 ++++++++++++++++++++-
>>  1 file changed, 43 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> index 8433f8dbb186..75ef006fa24b 100644
>> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> @@ -28,6 +28,10 @@
>>  #define ASPEED_VUART_ADDRL		0x28
>>  #define ASPEED_VUART_ADDRH		0x2c
>>
>> +#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
>> +#define ASPEED_VUART_DEFAULT_SIRQ	4
>> +#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
>> +
>>  struct aspeed_vuart {
>>  	struct device		*dev;
>>  	void __iomem		*regs;
>> @@ -393,7 +397,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>>  	struct aspeed_vuart *vuart;
>>  	struct device_node *np;
>>  	struct resource *res;
>> -	u32 clk, prop;
>> +	u32 clk, prop, sirq[2];
>> +	bool sirq_polarity;
>>  	int rc;
>>
>>  	np = pdev->dev.of_node;
>> @@ -501,6 +506,43 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>>  		of_node_put(sirq_polarity_sense_args.np);
>>  	}
>>
>> +	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
>> +	if (rc < 0)
>> +		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
>> +
>> +	rc = aspeed_vuart_set_lpc_address(vuart, prop);
>> +	if (rc < 0) {
>> +		dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
>> +		goto err_clk_disable;
>> +	}
>> +
>> +	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
>> +	if (rc < 0) {
>> +		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
>> +		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
>> +	}
>> +
>> +	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
>> +	if (rc < 0) {
>> +		dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts > property\n");
>> +		goto err_clk_disable;
>> +	}
>> +
>> +	switch (sirq[1]) {
>> +	case IRQ_TYPE_LEVEL_LOW:
>> +		sirq_polarity = false;
>> +		break;
>> +	case IRQ_TYPE_LEVEL_HIGH:
>> +		sirq_polarity = true;
>> +		break;
>> +	default:
>> +		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts
>> property\n");
>> +		rc = -EINVAL;
>> +		goto err_clk_disable;
>> +	}
>
>A bit ugly open-coding the mapping and error handling, maybe worth a helper?
>

Yeah, that sounds reasonable -- will do.

Thanks!


Zev



From gregkh at linuxfoundation.org  Fri Apr  9 07:37:36 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 9 Apr 2021 08:37:36 +0200
Subject: [PATCH 09/20] kbuild: arm64: use common install script
In-Reply-To: <202104082007.88622E72F@keescook>
References: <20210407053419.449796-1-gregkh@linuxfoundation.org>
 <20210407053419.449796-10-gregkh@linuxfoundation.org>
 <202104082007.88622E72F@keescook>
Message-ID: <YG/2MKfa19d2sF6l@kroah.com>

On Thu, Apr 08, 2021 at 08:08:18PM -0700, Kees Cook wrote:
> On Wed, Apr 07, 2021 at 07:34:08AM +0200, Greg Kroah-Hartman wrote:
> > The common scripts/install.sh script will now work for arm65, no changes
> 
> nit: arm64

Hah!

Thanks for the reviews, I'll be doing a new series soon based on
Masahiro's reviews.

thanks,

greg k-h


From andrew at aj.id.au  Fri Apr  9 07:39:09 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 16:09:09 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_14/21]_ipmi:_kcs=5Fbmc:_Allow_clients_to_control?=
 =?UTF-8?Q?_KCS_IRQ_state?=
In-Reply-To: <YG/Z/eZCES65fXQi@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-14-andrew@aj.id.au> <YG/Z/eZCES65fXQi@packtop>
Message-ID: <f0ade4c4-4f7e-4fed-98a3-580e27ae408f@www.fastmail.com>



On Fri, 9 Apr 2021, at 14:07, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:45AM CDT, Andrew Jeffery wrote:
> >Add a mechanism for controlling whether the client associated with a
> >KCS device will receive Input Buffer Full (IBF) and Output Buffer Empty
> >(OBE) events. This enables an abstract implementation of poll() for KCS
> >devices.
> >
> >A wart in the implementation is that the ASPEED KCS devices don't
> >support an OBE interrupt for the BMC. Instead we pretend it has one by
> >polling the status register waiting for the Output Buffer Full (OBF) bit
> >to clear, and generating an event when OBE is observed.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > drivers/char/ipmi/kcs_bmc.c         |   6 ++
> > drivers/char/ipmi/kcs_bmc.h         |   3 +
> > drivers/char/ipmi/kcs_bmc_aspeed.c  | 150 ++++++++++++++++++----------
> > drivers/char/ipmi/kcs_bmc_client.h  |   2 +
> > drivers/char/ipmi/kcs_bmc_device.h  |   1 +
> > drivers/char/ipmi/kcs_bmc_npcm7xx.c |  25 ++++-
> > 6 files changed, 130 insertions(+), 57 deletions(-)
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
> >index 694db6ee2a92..05bbb72418b2 100644
> >--- a/drivers/char/ipmi/kcs_bmc.c
> >+++ b/drivers/char/ipmi/kcs_bmc.c
> >@@ -184,6 +184,12 @@ int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev)
> > }
> > EXPORT_SYMBOL(kcs_bmc_unregister_cdev);
> >
> >+void kcs_bmc_update_event_mask(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 events)
> >+{
> >+	kcs_bmc->ops->irq_mask_update(kcs_bmc, mask, events);
> >+}
> >+EXPORT_SYMBOL(kcs_bmc_update_event_mask);
> >+
> > MODULE_LICENSE("GPL v2");
> > MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
> > MODULE_AUTHOR("Andrew Jeffery <andrew at aj.id.au>");
> >diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
> >index 5deb9a0b8e60..11fff935218c 100644
> >--- a/drivers/char/ipmi/kcs_bmc.h
> >+++ b/drivers/char/ipmi/kcs_bmc.h
> >@@ -11,6 +11,9 @@
> > #define KCS_BMC_EVENT_NONE	0
> > #define KCS_BMC_EVENT_HANDLED	1
> >
> >+#define KCS_BMC_EVENT_TYPE_OBE	BIT(0)
> >+#define KCS_BMC_EVENT_TYPE_IBF	BIT(1)
> >+
> > #define KCS_BMC_STR_OBF		BIT(0)
> > #define KCS_BMC_STR_IBF		BIT(1)
> > #define KCS_BMC_STR_CMD_DAT	BIT(3)
> >diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >index 6f26e7366c0b..5f26471c038c 100644
> >--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
> >+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
> >@@ -60,10 +60,18 @@
> > #define LPC_ODR4             0x118
> > #define LPC_STR4             0x11C
> >
> >+#define OBE_POLL_PERIOD	     (HZ / 2)
> >+
> > struct aspeed_kcs_bmc {
> > 	struct kcs_bmc_device kcs_bmc;
> >
> > 	struct regmap *map;
> >+
> >+	struct {
> >+		spinlock_t lock;
> >+		bool remove;
> >+		struct timer_list timer;
> >+	} obe;
> > };
> >
> > struct aspeed_kcs_of_ops {
> >@@ -159,68 +167,89 @@ static void aspeed_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enabl
> >
> > 	switch (kcs_bmc->channel) {
> > 	case 1:
> >-		if (enable) {
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF1, LPC_HICR2_IBFIF1);
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC1E, LPC_HICR0_LPC1E);
> >-		} else {
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC1E, 0);
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF1, 0);
> >-		}
> >-		break;
> >-
> >+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC1E, enable * LPC_HICR0_LPC1E);
> >+		return;
> > 	case 2:
> >-		if (enable) {
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF2, LPC_HICR2_IBFIF2);
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC2E, LPC_HICR0_LPC2E);
> >-		} else {
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC2E, 0);
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF2, 0);
> >-		}
> >-		break;
> >-
> >+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC2E, enable * LPC_HICR0_LPC2E);
> >+		return;
> > 	case 3:
> >-		if (enable) {
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF3, LPC_HICR2_IBFIF3);
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC3E, LPC_HICR0_LPC3E);
> >-			regmap_update_bits(priv->map, LPC_HICR4,
> >-					LPC_HICR4_KCSENBL, LPC_HICR4_KCSENBL);
> >-		} else {
> >-			regmap_update_bits(priv->map, LPC_HICR0,
> >-					LPC_HICR0_LPC3E, 0);
> >-			regmap_update_bits(priv->map, LPC_HICR4,
> >-					LPC_HICR4_KCSENBL, 0);
> >-			regmap_update_bits(priv->map, LPC_HICR2,
> >-					LPC_HICR2_IBFIF3, 0);
> >-		}
> >-		break;
> >-
> >+		regmap_update_bits(priv->map, LPC_HICR0, LPC_HICR0_LPC3E, enable * LPC_HICR0_LPC3E);
> >+		regmap_update_bits(priv->map, LPC_HICR4,
> >+				   LPC_HICR4_KCSENBL, enable * LPC_HICR4_KCSENBL);
> >+		return;
> > 	case 4:
> >-		if (enable)
> >-			regmap_update_bits(priv->map, LPC_HICRB,
> >-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E,
> >-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E);
> >+		regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_LPC4E, enable * LPC_HICRB_LPC4E);
> >+		return;
> >+	default:
> >+		pr_warn("%s: Unsupported channel: %d", __func__, kcs_bmc->channel);
> >+		return;
> >+	}
> >+}
> >+
> >+static void aspeed_kcs_check_obe(struct timer_list *timer)
> >+{
> >+	struct aspeed_kcs_bmc *priv = container_of(timer, struct aspeed_kcs_bmc, obe.timer);
> >+	unsigned long flags;
> >+	u8 str;
> >+
> >+	spin_lock_irqsave(&priv->obe.lock, flags);
> >+	if (priv->obe.remove) {
> >+		spin_unlock_irqrestore(&priv->obe.lock, flags);
> >+		return;
> >+	}
> >+
> >+	str = aspeed_kcs_inb(&priv->kcs_bmc, priv->kcs_bmc.ioreg.str);
> >+	if (str & KCS_BMC_STR_OBF) {
> >+		mod_timer(timer, jiffies + OBE_POLL_PERIOD);
> >+		spin_unlock_irqrestore(&priv->obe.lock, flags);
> >+		return;
> >+	}
> >+	spin_unlock_irqrestore(&priv->obe.lock, flags);
> >+
> >+	kcs_bmc_handle_event(&priv->kcs_bmc);
> >+}
> >+
> >+static void aspeed_kcs_irq_mask_update(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 state)
> >+{
> >+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
> >+
> >+	/* We don't have an OBE IRQ, emulate it */
> >+	if (KCS_BMC_EVENT_TYPE_OBE & mask) {
> >+		if (KCS_BMC_EVENT_TYPE_OBE & state)
> >+			mod_timer(&priv->obe.timer, jiffies + OBE_POLL_PERIOD);
> > 		else
> >-			regmap_update_bits(priv->map, LPC_HICRB,
> >-					LPC_HICRB_IBFIF4 | LPC_HICRB_LPC4E,
> >-					0);
> >-		break;
> >+			del_timer(&priv->obe.timer);
> >+	}
> >
> >-	default:
> >-		break;
> >+	if (KCS_BMC_EVENT_TYPE_IBF & mask) {
> >+		const bool enable = !!(KCS_BMC_EVENT_TYPE_IBF & state);
> 
> Totally superficial nitpick: the operand ordering for the bitmask tests
> in this function seem a bit inconsistent with what I think is the usual
> style of 'variable & BITMASK_MACRO' (reminiscent of "yoda
> conditionals").

Haha, I'm not sure what possessed me here.

> 
> >+
> >+		switch (kcs_bmc->channel) {
> >+		case 1:
> >+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF1,
> >+					   enable * LPC_HICR2_IBFIF1);
> >+			return;
> >+		case 2:
> >+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF2,
> >+					   enable * LPC_HICR2_IBFIF2);
> >+			return;
> >+		case 3:
> >+			regmap_update_bits(priv->map, LPC_HICR2, LPC_HICR2_IBFIF3,
> >+					   enable * LPC_HICR2_IBFIF3);
> >+			return;
> >+		case 4:
> >+			regmap_update_bits(priv->map, LPC_HICRB, LPC_HICRB_IBFIF4,
> >+					   enable * LPC_HICRB_IBFIF4);
> >+			return;
> >+		default:
> >+			pr_warn("%s: Unsupported channel: %d", __func__, kcs_bmc->channel);
> >+			return;
> >+		}
> > 	}
> > }
> >
> > static const struct kcs_bmc_device_ops aspeed_kcs_ops = {
> >+	.irq_mask_update = aspeed_kcs_irq_mask_update,
> > 	.io_inputb = aspeed_kcs_inb,
> > 	.io_outputb = aspeed_kcs_outb,
> > 	.io_updateb = aspeed_kcs_updateb,
> >@@ -378,6 +407,10 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> > 		return -ENODEV;
> > 	}
> >
> >+	spin_lock_init(&priv->obe.lock);
> >+	priv->obe.remove = false;
> >+	timer_setup(&priv->obe.timer, aspeed_kcs_check_obe, 0);
> >+
> > 	aspeed_kcs_set_address(kcs_bmc, addr);
> >
> > 	rc = aspeed_kcs_config_irq(kcs_bmc, pdev);
> >@@ -386,6 +419,8 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
> >
> > 	platform_set_drvdata(pdev, priv);
> >
> >+	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
> >+				   KCS_BMC_EVENT_TYPE_IBF);
> > 	aspeed_kcs_enable_channel(kcs_bmc, true);
> >
> > 	rc = kcs_bmc_add_device(&priv->kcs_bmc);
> >@@ -404,6 +439,15 @@ static int aspeed_kcs_remove(struct platform_device *pdev)
> >
> > 	kcs_bmc_remove_device(kcs_bmc);
> >
> >+	aspeed_kcs_enable_channel(kcs_bmc, false);
> >+	aspeed_kcs_irq_mask_update(kcs_bmc, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE), 0);
> >+
> >+	/* Make sure it's proper dead */
> >+	spin_lock_irq(&priv->obe.lock);
> >+	priv->obe.remove = true;
> >+	spin_unlock_irq(&priv->obe.lock);
> >+	del_timer_sync(&priv->obe.timer);
> >+
> > 	return 0;
> > }
> >
> >diff --git a/drivers/char/ipmi/kcs_bmc_client.h b/drivers/char/ipmi/kcs_bmc_client.h
> >index d0a7404ff584..456796da33de 100644
> >--- a/drivers/char/ipmi/kcs_bmc_client.h
> >+++ b/drivers/char/ipmi/kcs_bmc_client.h
> >@@ -37,6 +37,8 @@ int kcs_bmc_unregister_cdev(struct kcs_bmc_cdev *cdev);
> > int kcs_bmc_enable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
> > void kcs_bmc_disable_device(struct kcs_bmc_device *kcs_bmc, struct kcs_bmc_client *client);
> >
> >+void kcs_bmc_update_event_mask(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 events);
> >+
> > u8 kcs_bmc_read_data(struct kcs_bmc_device *kcs_bmc);
> > void kcs_bmc_write_data(struct kcs_bmc_device *kcs_bmc, u8 data);
> > u8 kcs_bmc_read_status(struct kcs_bmc_device *kcs_bmc);
> >diff --git a/drivers/char/ipmi/kcs_bmc_device.h b/drivers/char/ipmi/kcs_bmc_device.h
> >index 57b7174b2bac..f1ca8912496a 100644
> >--- a/drivers/char/ipmi/kcs_bmc_device.h
> >+++ b/drivers/char/ipmi/kcs_bmc_device.h
> >@@ -7,6 +7,7 @@
> > #include "kcs_bmc.h"
> >
> > struct kcs_bmc_device_ops {
> >+	void (*irq_mask_update)(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 enable);
> > 	u8 (*io_inputb)(struct kcs_bmc_device *kcs_bmc, u32 reg);
> > 	void (*io_outputb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 b);
> > 	void (*io_updateb)(struct kcs_bmc_device *kcs_bmc, u32 reg, u8 mask, u8 b);
> >diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >index dce93ec895fc..c2032728a03d 100644
> >--- a/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
> >@@ -38,6 +38,7 @@
> > #define KCS2CTL		0x2A
> > #define KCS3CTL		0x3C
> > #define    KCS_CTL_IBFIE	BIT(0)
> >+#define    KCS_CTL_OBEIE	BIT(0)
> >
> > #define KCS1IE		0x1C
> > #define KCS2IE		0x2E
> >@@ -117,13 +118,23 @@ static void npcm7xx_kcs_enable_channel(struct kcs_bmc_device *kcs_bmc, bool enab
> > {
> > 	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> >
> >-	regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
> >-			   enable ? KCS_CTL_IBFIE : 0);
> >-
> > 	regmap_update_bits(priv->map, priv->reg->ie, KCS_IE_IRQE | KCS_IE_HIRQE,
> > 			   enable ? KCS_IE_IRQE | KCS_IE_HIRQE : 0);
> > }
> >
> >+static void npcm7xx_kcs_irq_mask_update(struct kcs_bmc_device *kcs_bmc, u8 mask, u8 state)
> >+{
> >+	struct npcm7xx_kcs_bmc *priv = to_npcm7xx_kcs_bmc(kcs_bmc);
> >+
> >+	if (KCS_BMC_EVENT_TYPE_OBE & mask)
> >+		regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_OBEIE,
> >+				   !!(KCS_BMC_EVENT_TYPE_OBE & state) * KCS_CTL_OBEIE);
> >+
> >+	if (KCS_BMC_EVENT_TYPE_IBF & mask)
> >+		regmap_update_bits(priv->map, priv->reg->ctl, KCS_CTL_IBFIE,
> >+				   !!(KCS_BMC_EVENT_TYPE_IBF & state) * KCS_CTL_IBFIE);
> 
> Same operand ordering thing here...

Ack.

Andrew


From joel at jms.id.au  Fri Apr  9 07:46:27 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 9 Apr 2021 06:46:27 +0000
Subject: [GIT PULL] ARM: nuvoton: Add WPCM450 support
Message-ID: <CACPK8Xdj20TcJckH8fx757ACa4hT4j3bZEctT0Przjv8XJd7KA@mail.gmail.com>

Hello Soc maintainers,

Here's a support for a Nuvoton soc contributed by Jonathan. There are
changes for the irq controller, timer and serial port that have been
merged by other maintainers. I've picked up the arch and device tree
changes on his behalf to go through the soc tree.

The following changes since commit 09e6d2b71ae673dccf9f59f0fc1e17109113b6f4:

  ARM: config: Add WPCM to multi v5 (2021-04-09 15:18:40 +0930)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc.git
tags/bmc-5.13-wpcm450

for you to fetch changes up to 09e6d2b71ae673dccf9f59f0fc1e17109113b6f4:

  ARM: config: Add WPCM to multi v5 (2021-04-09 15:18:40 +0930)

----------------------------------------------------------------
Nuvoton WPCM450 BMC SoC

This adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
SoC but still commonly found on eBay, mostly in Supermicro X9 server
boards.

Third-party documentation is available at:
https://github.com/neuschaefer/wpcm450/wiki

The code has been contributed by Jonathan Neusch?fer who has also
stepped forward to maintain the soc.

----------------------------------------------------------------
Joel Stanley (1):
      ARM: config: Add WPCM to multi v5

Jonathan Neusch?fer (10):
      dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML
      ARM: dts: Add board-specific compatible string to npcm750-evb devicetree
      dt-bindings: vendor-prefixes: Add Supermicro
      dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string
      dt-bindings: watchdog: npcm: Add nuvoton,wpcm450-wdt
      ARM: npcm: Introduce Nuvoton WPCM450 SoC
      watchdog: npcm: Add support for WPCM450
      ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
      ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450
      MAINTAINERS: Add entry for Nuvoton WPCM450


From andrew at aj.id.au  Fri Apr  9 07:46:52 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 16:16:52 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?=
 =?UTF-8?Q?vice_interface?=
In-Reply-To: <YG/jZyx3huwqewgX@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au> <YG/jZyx3huwqewgX@packtop>
Message-ID: <c24bdd7a-64f6-4f4b-bd40-640efea8b059@www.fastmail.com>



On Fri, 9 Apr 2021, at 14:47, Zev Weiss wrote:
> On Fri, Mar 19, 2021 at 01:27:47AM CDT, Andrew Jeffery wrote:
> >The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> >However, KCS devices are useful beyond IPMI (or keyboards), as they
> >provide a means to generate IRQs and exchange arbitrary data between a
> >BMC and its host system.
> >
> >Implement a "raw" KCS character device that exposes the IDR, ODR and STR
> >registers to userspace via read() and write() implemented on a character
> >device:
> >
> >+--------+--------+---------+
> >| Offset | read() | write() |
> >+--------+--------+---------+
> >|   0    |   IDR  |   ODR   |
> >+--------+--------+---------+
> >|   1    |   STR  |   STR   |
> >+--------+--------+---------+
> >
> >This interface allows userspace to implement arbitrary (though somewhat
> >inefficient) protocols for exchanging information between a BMC and host
> >firmware. Conceptually the KCS interface can be used as an out-of-band
> >machanism for interrupt-signaled control messages while bulk data
> 
> Typo ("mechanism")

Ack.

> 
> >transfers occur over more appropriate interfaces between the BMC and the
> >host (which may lack their own interrupt mechanism, e.g. LPC FW cycles).
> >
> >poll() is provided, which will wait for IBF or OBE conditions for data
> >reads and writes respectively. Reads of STR on its own never blocks,
> >though accessing both offsets in the one system call may block if the
> >data registers are not ready.
> >
> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
> >---
> > Documentation/ABI/testing/dev-raw-kcs |  25 ++
> > drivers/char/ipmi/Kconfig             |  17 +
> > drivers/char/ipmi/Makefile            |   1 +
> > drivers/char/ipmi/kcs_bmc_cdev_raw.c  | 443 ++++++++++++++++++++++++++
> > 4 files changed, 486 insertions(+)
> > create mode 100644 Documentation/ABI/testing/dev-raw-kcs
> > create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_raw.c
> >
> >diff --git a/Documentation/ABI/testing/dev-raw-kcs b/Documentation/ABI/testing/dev-raw-kcs
> >new file mode 100644
> >index 000000000000..06e7e2071562
> >--- /dev/null
> >+++ b/Documentation/ABI/testing/dev-raw-kcs
> >@@ -0,0 +1,25 @@
> >+What:		/dev/raw-kcs*
> >+Date:		2021-02-15
> >+KernelVersion:	5.13
> >+Contact:	openbmc at lists.ozlabs.org
> >+Contact:	openipmi-developer at lists.sourceforge.net
> >+Contact:	Andrew Jeffery <andrew at aj.id.au>
> >+Description:	``/dev/raw-kcs*`` exposes to userspace the data and
> >+		status registers of Keyboard-Controller-Style (KCS) IPMI
> >+		interfaces via read() and write() syscalls. Direct
> >+		exposure of the data and status registers enables
> >+		inefficient but arbitrary protocols to be implemented
> >+		over the device. A typical approach is to use KCS
> >+		devices for out-of-band signalling for bulk data
> >+		transfers over other interfaces between a Baseboard
> >+		Management Controller and its host.
> >+
> >+		+--------+--------+---------+
> >+		| Offset | read() | write() |
> >+		+--------+--------+---------+
> >+		|   0    |   IDR  |   ODR   |
> >+		+--------+--------+---------+
> >+		|   1    |   STR  |   STR   |
> >+		+--------+--------+---------+
> >+
> >+Users:		libmctp: https://github.com/openbmc/libmctp
> >diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> >index bc5f81899b62..273ac1a1f870 100644
> >--- a/drivers/char/ipmi/Kconfig
> >+++ b/drivers/char/ipmi/Kconfig
> >@@ -137,6 +137,23 @@ config IPMI_KCS_BMC_CDEV_IPMI
> > 	  This support is also available as a module. The module will be
> > 	  called kcs_bmc_cdev_ipmi.
> >
> >+config IPMI_KCS_BMC_CDEV_RAW
> >+	depends on IPMI_KCS_BMC
> >+	tristate "Raw character device interface for BMC KCS devices"
> >+	help
> >+	  Provides a BMC-side character device directly exposing the
> >+	  data and status registers of a KCS device to userspace. While
> >+	  KCS devices are commonly used to implement IPMI message
> >+	  passing, they provide a general interface for exchange of
> >+	  interrupts, data and status information between the BMC and
> >+	  its host.
> >+
> >+	  Say YES if you wish to use the KCS devices to implement
> >+	  protocols that are not IPMI.
> >+
> >+	  This support is also available as a module. The module will be
> >+	  called kcs_bmc_cdev_raw.
> >+
> > config ASPEED_BT_IPMI_BMC
> > 	depends on ARCH_ASPEED || COMPILE_TEST
> > 	depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
> >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> >index fcfa676afddb..c8cc248ddd90 100644
> >--- a/drivers/char/ipmi/Makefile
> >+++ b/drivers/char/ipmi/Makefile
> >@@ -24,6 +24,7 @@ obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
> > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
> > obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
> > obj-$(CONFIG_IPMI_KCS_BMC_CDEV_IPMI) += kcs_bmc_cdev_ipmi.o
> >+obj-$(CONFIG_IPMI_KCS_BMC_CDEV_RAW) += kcs_bmc_cdev_raw.o
> > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
> > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
> > obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
> >diff --git a/drivers/char/ipmi/kcs_bmc_cdev_raw.c b/drivers/char/ipmi/kcs_bmc_cdev_raw.c
> >new file mode 100644
> >index 000000000000..bdd258648c8e
> >--- /dev/null
> >+++ b/drivers/char/ipmi/kcs_bmc_cdev_raw.c
> >@@ -0,0 +1,443 @@
> >+// SPDX-License-Identifier: GPL-2.0-or-later
> >+/* Copyright (c) 2021 IBM Corp. */
> >+
> >+#include <linux/delay.h>
> >+#include <linux/device.h>
> >+#include <linux/errno.h>
> >+#include <linux/fs.h>
> >+#include <linux/list.h>
> >+#include <linux/miscdevice.h>
> >+#include <linux/module.h>
> >+#include <linux/poll.h>
> >+
> >+#include "kcs_bmc_client.h"
> >+
> >+#define DEVICE_NAME "raw-kcs"
> >+
> >+struct kcs_bmc_raw {
> >+	struct list_head entry;
> >+
> >+	struct kcs_bmc_client client;
> >+
> >+	wait_queue_head_t queue;
> >+	u8 events;
> >+	bool writable;
> >+	bool readable;
> >+	u8 idr;
> >+
> >+	struct miscdevice miscdev;
> >+};
> >+
> >+static inline struct kcs_bmc_raw *client_to_kcs_bmc_raw(struct kcs_bmc_client *client)
> >+{
> >+	return container_of(client, struct kcs_bmc_raw, client);
> >+}
> >+
> >+/* Call under priv->queue.lock */
> >+static void kcs_bmc_raw_update_event_mask(struct kcs_bmc_raw *priv, u8 mask, u8 state)
> >+{
> >+	kcs_bmc_update_event_mask(priv->client.dev, mask, state);
> >+	priv->events &= ~mask;
> >+	priv->events |= state & mask;
> >+}
> >+
> >+static int kcs_bmc_raw_event(struct kcs_bmc_client *client)
> >+{
> >+	struct kcs_bmc_raw *priv;
> >+	struct device *dev;
> >+	u8 status, handled;
> >+
> >+	priv = client_to_kcs_bmc_raw(client);
> >+	dev = priv->miscdev.this_device;
> >+
> >+	spin_lock(&priv->queue.lock);
> >+
> >+	status = kcs_bmc_read_status(client->dev);
> >+	handled = 0;
> >+
> >+	if ((priv->events & KCS_BMC_EVENT_TYPE_IBF) && (status & KCS_BMC_STR_IBF)) {
> >+		if (priv->readable)
> >+			dev_err(dev, "Storm brewing!");
> 
> That seems a *touch* cryptic...

Uh, yeah. That wasn't meant to be there in that form.

> 
> >+
> >+		dev_dbg(dev, "Disabling IDR events for back-pressure\n");
> >+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_IBF, 0);
> >+		priv->idr = kcs_bmc_read_data(client->dev);
> >+		priv->readable = true;
> >+
> >+		dev_dbg(dev, "IDR read, waking waiters\n");
> >+		wake_up_locked(&priv->queue);
> >+
> >+		handled |= KCS_BMC_EVENT_TYPE_IBF;
> >+	}
> >+
> >+	if ((priv->events & KCS_BMC_EVENT_TYPE_OBE) && !(status & KCS_BMC_STR_OBF)) {
> >+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
> >+		priv->writable = true;
> >+
> >+		dev_dbg(dev, "ODR writable, waking waiters\n");
> >+		wake_up_locked(&priv->queue);
> >+
> >+		handled |= KCS_BMC_EVENT_TYPE_OBE;
> >+	}
> >+
> >+	spin_unlock(&priv->queue.lock);
> >+
> >+	return handled ? KCS_BMC_EVENT_HANDLED : KCS_BMC_EVENT_NONE;
> 
> Hm, if we're just treating it as a boolean here, is there any need to
> muck around with setting specific bits of 'handled' in the if-blocks
> above?

I don't think it matters? If we want to debug we can print the handled bitmask.

> 
> >+}
> >+
> >+static const struct kcs_bmc_client_ops kcs_bmc_raw_client_ops = {
> >+	.event = kcs_bmc_raw_event,
> >+};
> >+
> >+static inline struct kcs_bmc_raw *file_to_kcs_bmc_raw(struct file *filp)
> >+{
> >+	return container_of(filp->private_data, struct kcs_bmc_raw, miscdev);
> >+}
> >+
> >+static int kcs_bmc_raw_open(struct inode *inode, struct file *filp)
> >+{
> >+	struct kcs_bmc_raw *priv = file_to_kcs_bmc_raw(filp);
> >+
> >+	return kcs_bmc_enable_device(priv->client.dev, &priv->client);
> >+}
> >+
> >+static bool kcs_bmc_raw_prepare_obe(struct kcs_bmc_raw *priv)
> >+{
> >+	bool writable;
> >+
> >+	/* Enable the OBE event so we can catch the host clearing OBF */
> >+	kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, KCS_BMC_EVENT_TYPE_OBE);
> >+
> >+	/* Now that we'll catch an OBE event, check if it's already occurred */
> >+	writable = !(kcs_bmc_read_status(priv->client.dev) & KCS_BMC_STR_OBF);
> >+
> >+	/* If OBF is clear we've missed the OBE event, so disable it */
> >+	if (writable)
> >+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
> >+
> >+	return writable;
> >+}
> >+
> >+static __poll_t kcs_bmc_raw_poll(struct file *filp, poll_table *wait)
> >+{
> >+	struct kcs_bmc_raw *priv;
> >+	__poll_t events = 0;
> >+
> >+	priv = file_to_kcs_bmc_raw(filp);
> >+
> >+	poll_wait(filp, &priv->queue, wait);
> >+
> >+	spin_lock_irq(&priv->queue.lock);
> >+	if (kcs_bmc_raw_prepare_obe(priv))
> >+		events |= (EPOLLOUT | EPOLLWRNORM);
> >+
> >+	if (priv->readable || (kcs_bmc_read_status(priv->client.dev) & KCS_BMC_STR_IBF))
> >+		events |= (EPOLLIN | EPOLLRDNORM);
> >+	spin_unlock_irq(&priv->queue.lock);
> >+
> >+	return events;
> >+}
> >+
> >+static ssize_t kcs_bmc_raw_read(struct file *filp, char __user *buf,
> >+			     size_t count, loff_t *ppos)
> >+{
> >+	struct kcs_bmc_device *kcs_bmc;
> >+	struct kcs_bmc_raw *priv;
> >+	bool read_idr, read_str;
> >+	struct device *dev;
> >+	u8 idr, str;
> >+	ssize_t rc;
> >+
> >+	priv = file_to_kcs_bmc_raw(filp);
> >+	kcs_bmc = priv->client.dev;
> >+	dev = priv->miscdev.this_device;
> >+
> >+	if (!count)
> >+		return 0;
> >+
> >+	if (count > 2 || *ppos > 1)
> >+		return -EINVAL;
> >+
> >+	if (*ppos + count > 2)
> >+		return -EINVAL;
> >+
> >+	read_idr = (*ppos == 0);
> >+	read_str = (*ppos == 1) || (count == 2);
> >+
> >+	spin_lock_irq(&priv->queue.lock);
> >+	if (read_idr) {
> >+		dev_dbg(dev, "Waiting for IBF\n");
> >+		str = kcs_bmc_read_status(kcs_bmc);
> >+		if ((filp->f_flags & O_NONBLOCK) && (str & KCS_BMC_STR_IBF)) {
> >+			rc = -EWOULDBLOCK;
> >+			goto out;
> >+		}
> >+
> >+		rc = wait_event_interruptible_locked(priv->queue,
> >+						     priv->readable || (str & KCS_BMC_STR_IBF));
> >+		if (rc < 0)
> >+			goto out;
> >+
> >+		if (signal_pending(current)) {
> >+			dev_dbg(dev, "Interrupted waiting for IBF\n");
> >+			rc = -EINTR;
> >+			goto out;
> >+		}
> >+
> >+		/*
> >+		 * Re-enable events prior to possible read of IDR (which clears
> >+		 * IBF) to ensure we receive interrupts for subsequent writes
> >+		 * to IDR. Writes to IDR by the host should not occur while IBF
> >+		 * is set.
> >+		 */
> >+		dev_dbg(dev, "Woken by IBF, enabling IRQ\n");
> >+		kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_IBF,
> >+					      KCS_BMC_EVENT_TYPE_IBF);
> >+
> >+		/* Read data out of IDR into internal storage if necessary */
> >+		if (!priv->readable) {
> >+			WARN(!(str & KCS_BMC_STR_IBF), "Unknown reason for wakeup!");
> >+
> >+			priv->idr = kcs_bmc_read_data(kcs_bmc);
> >+		}
> >+
> >+		/* Copy data from internal storage to userspace */
> >+		idr = priv->idr;
> >+
> >+		/* We're done consuming the internally stored value */
> >+		priv->readable = false;
> >+	}
> >+
> >+	if (read_str) {
> >+		str = kcs_bmc_read_status(kcs_bmc);
> >+		if (*ppos == 0 || priv->readable)
> >+			/*
> >+			 * If we got this far with `*ppos == 0` then we've read
> >+			 * data out of IDR, so set IBF when reporting back to
> >+			 * userspace so userspace knows the IDR value is valid.
> >+			 */
> >+			str |= KCS_BMC_STR_IBF;
> >+
> >+		dev_dbg(dev, "Read status 0x%x\n", str);
> >+
> >+	}
> >+
> >+	rc = count;
> >+out:
> >+	spin_unlock_irq(&priv->queue.lock);
> >+
> >+	if (rc < 0)
> >+		return rc;
> >+
> >+	/* Now copy the data in to the userspace buffer */
> >+
> >+	if (read_idr)
> >+		if (copy_to_user(buf++, &idr, sizeof(idr)))
> >+			return -EFAULT;
> >+
> >+	if (read_str)
> >+		if (copy_to_user(buf, &str, sizeof(str)))
> >+			return -EFAULT;
> >+
> >+	return count;
> >+}
> >+
> >+static ssize_t kcs_bmc_raw_write(struct file *filp, const char __user *buf,
> >+			      size_t count, loff_t *ppos)
> >+{
> >+	struct kcs_bmc_device *kcs_bmc;
> >+	bool write_odr, write_str;
> >+	struct kcs_bmc_raw *priv;
> >+	struct device *dev;
> >+	uint8_t data[2];
> >+	ssize_t result;
> >+	u8 str;
> >+
> >+	priv = file_to_kcs_bmc_raw(filp);
> >+	kcs_bmc = priv->client.dev;
> >+	dev = priv->miscdev.this_device;
> >+
> >+	if (!count)
> >+		return count;
> >+
> >+	if (count > 2)
> >+		return -EINVAL;
> >+
> >+	if (*ppos >= 2)
> >+		return -EINVAL;
> >+
> >+	if (*ppos + count > 2)
> >+		return -EINVAL;
> >+
> >+	if (copy_from_user(data, buf, count))
> >+		return -EFAULT;
> >+
> >+	write_odr = (*ppos == 0);
> >+	write_str = (*ppos == 1) || (count == 2);
> >+
> >+	spin_lock_irq(&priv->queue.lock);
> >+
> >+	/* Always write status before data, we generate the SerIRQ by writing ODR */
> >+	if (write_str) {
> >+		/* The index of STR in the userspace buffer depends on whether ODR is written */
> >+		str = data[*ppos == 0];
> >+		if (!(str & KCS_BMC_STR_OBF))
> >+			dev_warn(dev, "Clearing OBF with status write: 0x%x\n", str);
> >+		dev_dbg(dev, "Writing status 0x%x\n", str);
> >+		kcs_bmc_write_status(kcs_bmc, str);
> >+	}
> >+
> >+	if (write_odr) {
> >+		/* If we're writing ODR it's always the first byte in the buffer */
> >+		u8 odr = data[0];
> >+
> >+		str = kcs_bmc_read_status(kcs_bmc);
> >+		if (str & KCS_BMC_STR_OBF) {
> >+			if (filp->f_flags & O_NONBLOCK) {
> >+				result = -EWOULDBLOCK;
> >+				goto out;
> >+			}
> >+
> >+			priv->writable = kcs_bmc_raw_prepare_obe(priv);
> >+
> >+			/* Now either OBF is already clear, or we'll get an OBE event to wake us */
> >+			dev_dbg(dev, "Waiting for OBF to clear\n");
> >+			wait_event_interruptible_locked(priv->queue, priv->writable);
> >+
> >+			if (signal_pending(current)) {
> >+				kcs_bmc_raw_update_event_mask(priv, KCS_BMC_EVENT_TYPE_OBE, 0);
> >+				result = -EINTR;
> >+				goto out;
> >+			}
> >+
> >+			WARN_ON(kcs_bmc_read_status(kcs_bmc) & KCS_BMC_STR_OBF);
> >+		}
> >+
> >+		dev_dbg(dev, "Writing 0x%x to ODR\n", odr);
> >+		kcs_bmc_write_data(kcs_bmc, odr);
> >+	}
> >+
> >+	result = count;
> >+out:
> >+	spin_unlock_irq(&priv->queue.lock);
> >+
> >+	return result;
> >+}
> >+
> >+static int kcs_bmc_raw_release(struct inode *inode, struct file *filp)
> >+{
> >+	struct kcs_bmc_raw *priv = file_to_kcs_bmc_raw(filp);
> >+
> >+	kcs_bmc_disable_device(priv->client.dev, &priv->client);
> >+
> >+	return 0;
> >+}
> >+
> >+static const struct file_operations kcs_bmc_raw_fops = {
> >+	.owner          = THIS_MODULE,
> >+	.open		= kcs_bmc_raw_open,
> >+	.llseek		= no_seek_end_llseek,
> >+	.read           = kcs_bmc_raw_read,
> >+	.write          = kcs_bmc_raw_write,
> >+	.poll		= kcs_bmc_raw_poll,
> >+	.release	= kcs_bmc_raw_release,
> >+};
> >+
> >+static DEFINE_SPINLOCK(kcs_bmc_raw_instances_lock);
> >+static LIST_HEAD(kcs_bmc_raw_instances);
> >+
> >+static int kcs_bmc_raw_attach_cdev(struct kcs_bmc_device *kcs_bmc)
> >+{
> >+	struct kcs_bmc_raw *priv;
> >+	int rc;
> >+
> >+	priv = devm_kzalloc(kcs_bmc->dev, sizeof(*priv), GFP_KERNEL);
> >+	if (!priv)
> >+		return -ENOMEM;
> >+
> >+	priv->client.dev = kcs_bmc;
> >+	priv->client.ops = &kcs_bmc_raw_client_ops;
> >+
> >+	init_waitqueue_head(&priv->queue);
> >+	priv->writable = false;
> >+	priv->readable = false;
> >+
> >+	priv->miscdev.minor = MISC_DYNAMIC_MINOR;
> >+	priv->miscdev.name = devm_kasprintf(kcs_bmc->dev, GFP_KERNEL, "%s%u", DEVICE_NAME,
> >+					   kcs_bmc->channel);
> >+	if (!priv->miscdev.name)
> >+		return -EINVAL;
> >+
> >+	priv->miscdev.fops = &kcs_bmc_raw_fops;
> >+
> >+	/* Initialise our expected events. Listen for IBF but ignore OBE until necessary */
> >+	kcs_bmc_raw_update_event_mask(priv, (KCS_BMC_EVENT_TYPE_IBF | KCS_BMC_EVENT_TYPE_OBE),
> >+				      KCS_BMC_EVENT_TYPE_IBF);
> >+
> >+	rc = misc_register(&priv->miscdev);
> >+	if (rc) {
> >+		dev_err(kcs_bmc->dev, "Unable to register device\n");
> >+		return rc;
> >+	}
> >+
> >+	spin_lock_irq(&kcs_bmc_raw_instances_lock);
> >+	list_add(&priv->entry, &kcs_bmc_raw_instances);
> >+	spin_unlock_irq(&kcs_bmc_raw_instances_lock);
> >+
> >+	dev_info(kcs_bmc->dev, "Initialised raw client for channel %d", kcs_bmc->channel);
> >+
> >+	return 0;
> >+}
> >+
> >+static int kcs_bmc_raw_detach_cdev(struct kcs_bmc_device *kcs_bmc)
> >+{
> >+	struct kcs_bmc_raw *priv = NULL, *pos;
> >+
> >+	spin_lock_irq(&kcs_bmc_raw_instances_lock);
> >+	list_for_each_entry(pos, &kcs_bmc_raw_instances, entry) {
> >+		if (pos->client.dev == kcs_bmc) {
> >+			priv = pos;
> >+			list_del(&pos->entry);
> >+			break;
> >+		}
> >+	}
> >+	spin_unlock_irq(&kcs_bmc_raw_instances_lock);
> >+
> >+	if (!priv)
> >+		return 0;
> 
> Similarly to patch #12, might we want to indicate some sort of failure
> here, or is this a normal/expected case?

I replied on 12/21, I'll have another think about it.

Cheers,

Andrew


From xiangyang3 at huawei.com  Fri Apr  9 07:46:58 2021
From: xiangyang3 at huawei.com (Xiang Yang)
Date: Fri, 9 Apr 2021 14:46:58 +0800
Subject: [PATCH -next] media: sunxi: sun8i-rotate: fix PM reference leak in
 rotate_start_streaming()
Message-ID: <20210409064658.90493-1-xiangyang3@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>
---
 .../platform/sunxi/sun8i-rotate/sun8i_rotate.c      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
index 3f81dd17755c..fbcca59a0517 100644
--- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
+++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
@@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
 		struct device *dev = ctx->dev->dev;
 		int ret;
 
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 



From masahiroy at kernel.org  Fri Apr  9 07:46:47 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Fri, 9 Apr 2021 15:46:47 +0900
Subject: [PATCH] clk: uniphier: Fix potential infinite loop
In-Reply-To: <20210407152457.497346-1-colin.king@canonical.com>
References: <20210407152457.497346-1-colin.king@canonical.com>
Message-ID: <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>

On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king at canonical.com> wrote:
>
> From: Colin Ian King <colin.king at canonical.com>
>
> The for-loop iterates with a u8 loop counter i and compares this
> with the loop upper limit of num_parents that is an int type.
> There is a potential infinite loop if num_parents is larger than
> the u8 loop counter. Fix this by making the loop counter the same
> type as num_parents.
>
> Addresses-Coverity: ("Infinite loop")
> Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
> index 462c84321b2d..ce219e0d2a85 100644
> --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
>         int num_parents = clk_hw_get_num_parents(hw);
>         int ret;
>         unsigned int val;
> -       u8 i;
> +       int i;
>
>         ret = regmap_read(mux->regmap, mux->reg, &val);
>         if (ret)
> --
> 2.30.2
>

clk_hw_get_num_parents() returns 'unsigned int', so
I think 'num_parents' should also have been 'unsigned int'.

Maybe, the loop counter 'i' also should be 'unsigned int' then?


-- 
Best Regards
Masahiro Yamada


From wanjiabing at vivo.com  Fri Apr  9 07:49:20 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Fri,  9 Apr 2021 14:49:20 +0800
Subject: [PATCH] arm: mach-s3c: Remove unnecessary break
Message-ID: <20210409064920.1096367-1-wanjiabing@vivo.com>

There is a return above the break.
The break here is unnecessary. Remove it.

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 arch/arm/mach-s3c/mach-rx1950.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-s3c/mach-rx1950.c b/arch/arm/mach-s3c/mach-rx1950.c
index 6e19add158a9..9da94686001a 100644
--- a/arch/arm/mach-s3c/mach-rx1950.c
+++ b/arch/arm/mach-s3c/mach-rx1950.c
@@ -271,7 +271,6 @@ static int rx1950_led_blink_set(struct gpio_desc *desc, int state,
 		break;
 	default:
 		return -EINVAL;
-		break;
 	}
 
 	if (delay_on && delay_off && !*delay_on && !*delay_off)
-- 
2.25.1



From chenlifu at huawei.com  Fri Apr  9 07:51:21 2021
From: chenlifu at huawei.com (chenlifu)
Date: Fri, 9 Apr 2021 14:51:21 +0800
Subject: [PATCH -next] ARM: spear: Fix build error with
 CONFIG_ARCH_SPEAR3XX
In-Reply-To: <20210409040315.vc55eogaxs4zu4xb@vireshk-i7>
References: <20210409015515.258653-1-chenlifu@huawei.com>
 <20210409040315.vc55eogaxs4zu4xb@vireshk-i7>
Message-ID: <f4285a1b-9da5-d86b-95ec-cc8513936cde@huawei.com>


? 2021/4/9 12:03, Viresh Kumar ??:
> On 09-04-21, 09:55, Chen Lifu wrote:
>> commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
>> deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
>> We get build error when CONFIG_ARCH_SPEAR3XX is set:
>> arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controller' has no member named 'num_chipselect'
>>     42 |  .num_chipselect = 2,
>>        |   ^~~~~~~~~~~~~~
>> arch/arm/mach-spear/spear3xx.c:42:20: warning: initialization of 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>>     42 |  .num_chipselect = 2,
>>        |                    ^
>>
>> Fix the issue by deleting the initialization of 'num_chipselect'
>> in spear3xx.c.
>>
>> Fixes: 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
>> Reported-by: Hulk Robot <hulkci at huawei.com>
>> Signed-off-by: Chen Lifu <chenlifu at huawei.com>
>> ---
>>   arch/arm/mach-spear/spear3xx.c | 10 ----------
>>   1 file changed, 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-spear/spear3xx.c b/arch/arm/mach-spear/spear3xx.c
>> index 8537fcffe5a8..f83321d5e353 100644
>> --- a/arch/arm/mach-spear/spear3xx.c
>> +++ b/arch/arm/mach-spear/spear3xx.c
>> @@ -30,16 +30,6 @@ struct pl022_ssp_controller pl022_plat_data = {
>>   	.dma_filter = pl08x_filter_id,
>>   	.dma_tx_param = "ssp0_tx",
>>   	.dma_rx_param = "ssp0_rx",
>> -	/*
>> -	 * This is number of spi devices that can be connected to spi. There are
>> -	 * two type of chipselects on which slave devices can work. One is chip
>> -	 * select provided by spi masters other is controlled through external
>> -	 * gpio's. We can't use chipselect provided from spi master (because as
>> -	 * soon as FIFO becomes empty, CS is disabled and transfer ends). So
>> -	 * this number now depends on number of gpios available for spi. each
>> -	 * slave on each master requires a separate gpio pin.
>> -	 */
>> -	.num_chipselect = 2,
>>   };
> 
> A patch is already applied by Mark to fix this issue.
> 

Thanks.

---
Chen Lifu


From zev at bewilderbeest.net  Fri Apr  9 08:01:04 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri, 9 Apr 2021 02:01:04 -0500
Subject: [PATCH v5 2/4] drivers/tty/serial/8250: refactor sirq and lpc
 address setting code
In-Reply-To: <db7271d8-8d13-4a8c-a7ba-564e4e769ea5@www.fastmail.com>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-3-zev@bewilderbeest.net>
 <db7271d8-8d13-4a8c-a7ba-564e4e769ea5@www.fastmail.com>
Message-ID: <YG/7sFv+2AlLKbZ5@hatter.bewilderbeest.net>

On Fri, Apr 09, 2021 at 12:06:16AM CDT, Andrew Jeffery wrote:
>
>
>On Thu, 8 Apr 2021, at 10:46, Zev Weiss wrote:
>> This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
>> out of the sysfs store functions in preparation for adding DT
>> properties that will be poking the same registers.  While we're at it,
>> these functions now provide some basic bounds-checking on their
>> arguments.
>>
>> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
>> ---
>>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
>>  1 file changed, 35 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> index c33e02cbde93..8433f8dbb186 100644
>> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
>> @@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
>>  	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
>>  }
>>
>> +static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
>> +{
>> +	if (addr > U16_MAX)
>> +		return -EINVAL;
>> +
>> +	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
>> +	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
>> +
>> +	return 0;
>> +}
>> +
>>  static ssize_t lpc_address_store(struct device *dev,
>>  				 struct device_attribute *attr,
>>  				 const char *buf, size_t count)
>>  {
>>  	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
>> -	unsigned long val;
>> +	u32 val;
>>  	int err;
>>
>> -	err = kstrtoul(buf, 0, &val);
>> +	err = kstrtou32(buf, 0, &val);
>>  	if (err)
>>  		return err;
>>
>> -	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
>> -	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
>> -
>> -	return count;
>> +	err = aspeed_vuart_set_lpc_address(vuart, val);
>> +	return err ? : count;
>>  }
>>
>>  static DEVICE_ATTR_RW(lpc_address);
>> @@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
>>  	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
>>  }
>>
>> +static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
>> +{
>> +	u8 reg;
>> +
>> +	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
>> +		return -EINVAL;
>> +
>> +	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
>> +	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
>
>This might be less verbose if we reordered things a little:
>
>```
>sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
>if (sirq & ASPEED_VUART_GCRB_HOST_SIRQ_MASK)
>	return -EINVAL;
>sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
>```

Hmm, that (or something similar, perhaps with a '~' on the mask in the 
if condition?) does seem like it'd be a nice improvement, though I 
suppose it'd also mean we'd fail to reject some way-out-of-range sirq 
values (e.g. if it had its MSB set) -- so I think I'll leave it as is, 
just in the name of thoroughness/paranoia?

>
>But otherwise it looks okay, so
>
>Reviewed-by: Andrew Jeffery <andrew at aj.id.au>
>

Thanks.



From andrew at aj.id.au  Fri Apr  9 08:11:23 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 16:41:23 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v5_2/4]_drivers/tty/serial/8250:_refactor_sirq_and_?=
 =?UTF-8?Q?lpc_address_setting_code?=
In-Reply-To: <YG/7sFv+2AlLKbZ5@hatter.bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-3-zev@bewilderbeest.net>
 <db7271d8-8d13-4a8c-a7ba-564e4e769ea5@www.fastmail.com>
 <YG/7sFv+2AlLKbZ5@hatter.bewilderbeest.net>
Message-ID: <f0dd410b-53af-400d-ba79-334c55eff854@beta.fastmail.com>



On Fri, 9 Apr 2021, at 16:31, Zev Weiss wrote:
> On Fri, Apr 09, 2021 at 12:06:16AM CDT, Andrew Jeffery wrote:
> >
> >
> >On Thu, 8 Apr 2021, at 10:46, Zev Weiss wrote:
> >> This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
> >> out of the sysfs store functions in preparation for adding DT
> >> properties that will be poking the same registers.  While we're at it,
> >> these functions now provide some basic bounds-checking on their
> >> arguments.
> >>
> >> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> >> ---
> >>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
> >>  1 file changed, 35 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> index c33e02cbde93..8433f8dbb186 100644
> >> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> >> @@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
> >>  	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
> >>  }
> >>
> >> +static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
> >> +{
> >> +	if (addr > U16_MAX)
> >> +		return -EINVAL;
> >> +
> >> +	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
> >> +	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
> >> +
> >> +	return 0;
> >> +}
> >> +
> >>  static ssize_t lpc_address_store(struct device *dev,
> >>  				 struct device_attribute *attr,
> >>  				 const char *buf, size_t count)
> >>  {
> >>  	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
> >> -	unsigned long val;
> >> +	u32 val;
> >>  	int err;
> >>
> >> -	err = kstrtoul(buf, 0, &val);
> >> +	err = kstrtou32(buf, 0, &val);
> >>  	if (err)
> >>  		return err;
> >>
> >> -	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
> >> -	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
> >> -
> >> -	return count;
> >> +	err = aspeed_vuart_set_lpc_address(vuart, val);
> >> +	return err ? : count;
> >>  }
> >>
> >>  static DEVICE_ATTR_RW(lpc_address);
> >> @@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
> >>  	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
> >>  }
> >>
> >> +static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
> >> +{
> >> +	u8 reg;
> >> +
> >> +	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
> >> +		return -EINVAL;
> >> +
> >> +	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
> >> +	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
> >
> >This might be less verbose if we reordered things a little:
> >
> >```
> >sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
> >if (sirq & ASPEED_VUART_GCRB_HOST_SIRQ_MASK)
> >	return -EINVAL;
> >sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
> >```
> 
> Hmm, that (or something similar, perhaps with a '~' on the mask in the 
> if condition?) does seem like it'd be a nice improvement, though I 
> suppose it'd also mean we'd fail to reject some way-out-of-range sirq 
> values (e.g. if it had its MSB set) -- so I think I'll leave it as is, 
> just in the name of thoroughness/paranoia?

Yeah, fair enough. I was considering smaller errors :)

Andrew


From michael.kao at mediatek.com  Fri Apr  9 08:11:58 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Fri, 9 Apr 2021 15:11:58 +0800
Subject: [PATCH 1/1] arm64: dts: mt8183-kukui: Enable thermal Tboard
Message-ID: <20210409071158.2346-1-michael.kao@mediatek.com>

Add Tboard thermal sensor settings.

pull-up voltage: 1800 mv
pull-up resistor: 75K

Vsense = pull-up voltage * Rntc / ( pull-up resistor + Rntc )
AuxIn = Vsense * 4096 / 1500

TEST=boot kukui
     check /sys/class/thermal/thermal_zone*/type
     check /sys/class/thermal/thermal_zone*/temp

Signed-off-by: Michael Kao <michael.kao at mediatek.com>
Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 14 ++++++++++++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi       |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index bf2ad1294dd3..202acb542b12 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -801,6 +801,20 @@
 	status = "okay";
 };
 
+&thermal_zones {
+	Tboard1 {
+		polling-delay = <1000>; /* milliseconds */
+		polling-delay-passive = <0>; /* milliseconds */
+		thermal-sensors = <&tboard_thermistor1>;
+	};
+
+	Tboard2 {
+		polling-delay = <1000>; /* milliseconds */
+		polling-delay-passive = <0>; /* milliseconds */
+		thermal-sensors = <&tboard_thermistor2>;
+	};
+};
+
 &u3phy {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 1ad0a1d55d53..f0719dbef249 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -673,7 +673,7 @@
 			nvmem-cell-names = "calibration-data";
 		};
 
-		thermal-zones {
+		thermal_zones: thermal-zones {
 			cpu_thermal: cpu_thermal {
 				polling-delay-passive = <100>;
 				polling-delay = <500>;
-- 
2.18.0

From hsinyi at chromium.org  Fri Apr  9 08:16:44 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri, 9 Apr 2021 15:16:44 +0800
Subject: [PATCH 1/1] arm64: dts: mt8183-kukui: Enable thermal Tboard
In-Reply-To: <20210409071158.2346-1-michael.kao@mediatek.com>
References: <20210409071158.2346-1-michael.kao@mediatek.com>
Message-ID: <CAJMQK-gXfR2Ca-Ay5fwcRgQ4F6h4xXVt1bbAL+3LFwgotwYREA@mail.gmail.com>

On Fri, Apr 9, 2021 at 3:12 PM Michael Kao <michael.kao at mediatek.com> wrote:
>
> Add Tboard thermal sensor settings.
>
> pull-up voltage: 1800 mv
> pull-up resistor: 75K
>
> Vsense = pull-up voltage * Rntc / ( pull-up resistor + Rntc )
> AuxIn = Vsense * 4096 / 1500
>
> TEST=boot kukui
>      check /sys/class/thermal/thermal_zone*/type
>      check /sys/class/thermal/thermal_zone*/temp
the TEST lines can be removed.

>
> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> ---

Tested-by: Hsin-Yi Wang <hsinyi at chromium.org>

This removes following error:
[   10.882325] generic-adc-thermal thermal-sensor1: Thermal zone
sensor register failed: -19
[   10.911912] generic-adc-thermal thermal-sensor2: Thermal zone
sensor register failed: -19

>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 14 ++++++++++++++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi       |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index bf2ad1294dd3..202acb542b12 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -801,6 +801,20 @@
>         status = "okay";
>  };
>
> +&thermal_zones {
> +       Tboard1 {
> +               polling-delay = <1000>; /* milliseconds */
> +               polling-delay-passive = <0>; /* milliseconds */
> +               thermal-sensors = <&tboard_thermistor1>;
> +       };
> +
> +       Tboard2 {
> +               polling-delay = <1000>; /* milliseconds */
> +               polling-delay-passive = <0>; /* milliseconds */
> +               thermal-sensors = <&tboard_thermistor2>;
> +       };
> +};
> +
>  &u3phy {
>         status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 1ad0a1d55d53..f0719dbef249 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -673,7 +673,7 @@
>                         nvmem-cell-names = "calibration-data";
>                 };
>
> -               thermal-zones {
> +               thermal_zones: thermal-zones {
>                         cpu_thermal: cpu_thermal {
>                                 polling-delay-passive = <100>;
>                                 polling-delay = <500>;
> --
> 2.18.0
>


From arnd at kernel.org  Fri Apr  9 08:17:35 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 09:17:35 +0200
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13
In-Reply-To: <CACPK8Xe-KV5BeQwOH6NKC1++FCVqwwNCGBh7hEbBORfrmxfTtQ@mail.gmail.com>
References: <CACPK8Xe-KV5BeQwOH6NKC1++FCVqwwNCGBh7hEbBORfrmxfTtQ@mail.gmail.com>
Message-ID: <161795265048.1749935.15830124997910239772.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 06:14:27 +0000, Joel Stanley wrote:
> Here's a pull request from me for the ASPEED and Nuvoton changes
> targeting the v5.13 merge window. As you can see I've chosen to
> arrange the pull request as one single "BMC-related" set of changes.
> If we choose to continue with this, in the future I will cover the
> ASPEED, NPCM and soon to be merged WPCM (legacy Nuvoton) systems.
> 
> The following changes since commit ee33e2fb3d70267de00f7c0b09e7e3b309a686df:
> 
> [...]

Merged into arm/dt, thanks!

merge commit: e3bbc53ac8827babb5001037883e4edd2068168d

       Arnd


From arnd at kernel.org  Fri Apr  9 08:18:20 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 09:18:20 +0200
Subject: [GIT PULL] ARM: aspeed: lpc changes for 5.13
In-Reply-To: <CACPK8Xcb12LsVr7CUaXXjQskKbVjb7x+jgueG1Hik-kBPWtDSg@mail.gmail.com>
References: <CACPK8Xcb12LsVr7CUaXXjQskKbVjb7x+jgueG1Hik-kBPWtDSg@mail.gmail.com>
Message-ID: <161795267844.1750068.14862109207368145425.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 06:29:52 +0000, Joel Stanley wrote:
> This is a pull request containing a slightly messy device tree and
> associated driver changes for the ASPEED systems. It corrects some
> design decisions made when first mainlining support for the BMC
> devices on the LPC bus that have stopped us from being able to write
> drivers for eg. KCS.
> 
> Andrew has worked with Chai-Wei from ASPEED on this process. These set
> of changes have acks from the maintainers, and allow Andrew to go
> ahead with fixing the KCS drivers in the future. The branch should
> apply with no conflicts no matter which order it is merged.
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: d60f314b93b637e9721c406f5a61cf2157e59b48

       Arnd


From arnd at kernel.org  Fri Apr  9 08:18:49 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 09:18:49 +0200
Subject: [GIT PULL] ARM: nuvoton: Add WPCM450 support
In-Reply-To: <CACPK8Xdj20TcJckH8fx757ACa4hT4j3bZEctT0Przjv8XJd7KA@mail.gmail.com>
References: <CACPK8Xdj20TcJckH8fx757ACa4hT4j3bZEctT0Przjv8XJd7KA@mail.gmail.com>
Message-ID: <161795272593.1750291.13960701815040145569.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 06:46:27 +0000, Joel Stanley wrote:
> Here's a support for a Nuvoton soc contributed by Jonathan. There are
> changes for the irq controller, timer and serial port that have been
> merged by other maintainers. I've picked up the arch and device tree
> changes on his behalf to go through the soc tree.
> 
> The following changes since commit 09e6d2b71ae673dccf9f59f0fc1e17109113b6f4:
> 
>   ARM: config: Add WPCM to multi v5 (2021-04-09 15:18:40 +0930)
> 
> [...]

Merged into arm/newsoc, thanks!

merge commit: 39b95079f68cf17888a4cee93ad3c4acc3854b38

       Arnd


From arnd at kernel.org  Fri Apr  9 08:32:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 09:32:26 +0200
Subject: [PATCH] ARM: dts: mvebu: fix SPI device node
Message-ID: <20210409073252.1764731-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

dtc warns about a mismatched address:

arch/arm/boot/dts/armada-385-atl-x530.dts:171.14-199.4: Warning (spi_bus_reg): /soc/spi at 10680/spi-flash at 0: SPI bus unit address format error, expected "1"

I assume the "reg" property is correct here, so adjust the unit address
accordingly.

Fixes: c6dfc019c239 ("ARM: dts: mvebu: Add device tree for ATL-x530 Board")
Reported-by: Stephen Rothwell <sfr at canb.auug.org.au>
Reported-by: kernelci.org bot <bot at kernelci.org>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
I applied this fixup to the arm/dt branch on top of the new file, this
will be part of linux-next and the v5.13 pull request

 arch/arm/boot/dts/armada-385-atl-x530.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-385-atl-x530.dts b/arch/arm/boot/dts/armada-385-atl-x530.dts
index 2041bf09c578..ed3f41c7df71 100644
--- a/arch/arm/boot/dts/armada-385-atl-x530.dts
+++ b/arch/arm/boot/dts/armada-385-atl-x530.dts
@@ -168,7 +168,7 @@ &spi1 {
 	pinctrl-0 = <&spi1_pins>;
 	status = "okay";
 
-	spi-flash at 0 {
+	spi-flash at 1 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "jedec,spi-nor";
-- 
2.29.2



From zev at bewilderbeest.net  Fri Apr  9 08:38:38 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri, 9 Apr 2021 02:38:38 -0500
Subject: [PATCH v5 2/4] drivers/tty/serial/8250: refactor sirq and lpc
 address setting code
In-Reply-To: <CAHp75Vd6kk0E-kALEGOhsg=YHKhmKLY6cpCTdviOFenO4p1-2A@mail.gmail.com>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-3-zev@bewilderbeest.net>
 <CAHp75Vd6kk0E-kALEGOhsg=YHKhmKLY6cpCTdviOFenO4p1-2A@mail.gmail.com>
Message-ID: <YHAEfn4li6F8L9JC@hatter.bewilderbeest.net>

On Fri, Apr 09, 2021 at 02:24:08AM CDT, Andy Shevchenko wrote:
>On Thursday, April 8, 2021, Zev Weiss <zev at bewilderbeest.net> wrote:
>
>> This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
>> out of the sysfs store functions in preparation for adding DT
>> properties that will be poking the same registers.  While we're at it,
>> these functions now provide some basic bounds-checking on their
>> arguments.
>>
>>
>
>Please, use prefix ?serial: 8250_aspeed_vuart:? instead of what you have in
>the subject line. I think I have told this already
>
>

Ah, sorry -- I fixed the cover letter after your first comment (which 
had definitely been under-tagged); for the patches themselves I was 
following the example of the last patch in that particular area 
(8d310c9107a2), though I guess that wasn't the right model to follow.  
I'll use the requested format in the future.




From patrice.chotard at foss.st.com  Fri Apr  9 08:42:03 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Fri, 9 Apr 2021 09:42:03 +0200
Subject: [PATCH -next] mmc: sdhci-st: Remove unnecessary error log
In-Reply-To: <20210409023801.3326572-1-qiulaibin@huawei.com>
References: <20210409023801.3326572-1-qiulaibin@huawei.com>
Message-ID: <39dd50a7-6e85-49e4-8072-e88fcc471714@foss.st.com>

Hi Laibin

On 4/9/21 4:38 AM, Laibin Qiu wrote:
> devm_ioremap_resource() has recorded error log, so it's
> unnecessary to record log again.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>
> ---
>  drivers/mmc/host/sdhci-st.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
> index 78941ac3a1d6..d41582c21aa3 100644
> --- a/drivers/mmc/host/sdhci-st.c
> +++ b/drivers/mmc/host/sdhci-st.c
> @@ -400,10 +400,8 @@ static int sdhci_st_probe(struct platform_device *pdev)
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>  					   "top-mmc-delay");
>  	pdata->top_ioaddr = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(pdata->top_ioaddr)) {
> -		dev_warn(&pdev->dev, "FlashSS Top Dly registers not available");
> +	if (IS_ERR(pdata->top_ioaddr))
>  		pdata->top_ioaddr = NULL;
> -	}
>  
>  	pltfm_host->clk = clk;
>  	pdata->icnclk = icnclk;
> 

Reviewed-by: Patrice Chotard <patrice.chotard at foss.st.com>

Thanks
Patrice


From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr  9 08:44:28 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri, 9 Apr 2021 16:44:28 +0900
Subject: [PATCH v2 1/2] dt-bindings: pwm: Add bindings for Toshiba
 Visconti PWM Controller
In-Reply-To: <20210305202224.GA583007@robh.at.kernel.org>
References: <20210212131910.557581-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210212131910.557581-2-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210305202224.GA583007@robh.at.kernel.org>
Message-ID: <20210409074428.hg7ys5he6iuqzhm6@toshiba.co.jp>

Hi,

On Fri, Mar 05, 2021 at 02:22:24PM -0600, Rob Herring wrote:
> On Fri, Feb 12, 2021 at 10:19:09PM +0900, Nobuhiro Iwamatsu wrote:
> > Add bindings for the Toshiba Visconti PWM Controller.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > ---
> >  .../bindings/pwm/toshiba,pwm-visconti.yaml    | 43 +++++++++++++++++++
> >  1 file changed, 43 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
> > new file mode 100644
> > index 000000000000..f11558cdc32f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
> > @@ -0,0 +1,43 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/toshiba,pwm-visconti.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba Visconti PWM Controller
> > +
> > +maintainers:
> > +  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - const: toshiba,pwm-visconti
> 
> The 'normal' order is: toshiba,visconti-pwm

I see, I will change to it.

> 
> Otherwise,
> 
> Reviewed-by: Rob Herring <robh at kernel.org>
> 

Thanks!

Best regards,
  Nobuhiro


From dinghao.liu at zju.edu.cn  Fri Apr  9 08:53:37 2021
From: dinghao.liu at zju.edu.cn (dinghao.liu at zju.edu.cn)
Date: Fri, 9 Apr 2021 15:53:37 +0800 (GMT+08:00)
Subject: [PATCH] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <ef4555a6-1674-d9c0-6401-cdf43780a014@windriver.com>
References: <20210408092559.3824-1-dinghao.liu@zju.edu.cn>
 <17b5d33f-ce96-dc07-05f7-41d87f53a3d0@xilinx.com>
 <ef4555a6-1674-d9c0-6401-cdf43780a014@windriver.com>
Message-ID: <2b385fb0.45344.178b59f4790.Coremail.dinghao.liu@zju.edu.cn>

> Hi Dinghao,
> 
> On 4/8/21 6:33 PM, Michal Simek wrote:
> > ++
> >
> > On 4/8/21 11:25 AM, Dinghao Liu wrote:
> >> When platform_get_irq() fails, a pairing PM usage counter
> >> increment is needed to keep the counter balanced. It's the
> >> same for the following error paths.
> >>
> >> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> >> ---
> >>   drivers/spi/spi-zynqmp-gqspi.c | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> >> index c8fa6ee18ae7..95963a2de64a 100644
> >> --- a/drivers/spi/spi-zynqmp-gqspi.c
> >> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> >> @@ -1197,6 +1197,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
> >>   	return 0;
> >>   
> >>   clk_dis_all:
> >> +	pm_runtime_get_noresume(&pdev->dev);
> >>   	pm_runtime_set_suspended(&pdev->dev);
> >>   	pm_runtime_disable(&pdev->dev);
> >>   	clk_disable_unprepare(xqspi->refclk);
> >>
> The imbalance is because pm_runtime_put_autosuspend is called to make 
> counter to be -1.
> 
> It looks strange that there is no counter increament op before 
> pm_runtime_put_autosuspend.
> 
> In my limited understanding, it should look like:
> 
> ......
> 
> pm_runtime_enable
> 
> pm_runtime_get_sync ? //increase counter to one to resume device
> 
> DO OPERATIONS HERE
> 
> pm_runtime_mark_last_busy
> pm_runtime_put_autosuspend ? //decrease counter to zero and trigger suspend
> 
> return 0;
> 
> error_path:
> 
> pm_runtime_put_sync
> 
> pm_runtime_disable
> 
> return err;
> 
> 
> Am I missing something?
> 

Thanks for point out this! Usually there is an increment refcount in a 
_probe function and a decrement refcount in a _remove function. Sometimes 
the refcount decrement is in the _probe and the increment is in the _remove. 
But the refcount is balanced in both cases. So I think zynqmp_qspi_remove()
needs a refcount increment to fix this bug.

Regards,
Dinghao

From herbert at gondor.apana.org.au  Fri Apr  9 08:54:13 2021
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 9 Apr 2021 17:54:13 +1000
Subject: [PATCH][next] crypto: sun8i-ss: Fix memory leak of pad
In-Reply-To: <20210401151827.2015960-1-colin.king@canonical.com>
References: <20210401151827.2015960-1-colin.king@canonical.com>
Message-ID: <20210409075413.GH31447@gondor.apana.org.au>

On Thu, Apr 01, 2021 at 04:18:27PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> It appears there are several failure return paths that don't seem
> to be free'ing pad. Fix these.
> 
> Addresses-Coverity: ("Resource leak")
> Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)

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 arnd at kernel.org  Fri Apr  9 08:55:53 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 9 Apr 2021 09:55:53 +0200
Subject: [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device
 interface
In-Reply-To: <20210319062752.145730-16-andrew@aj.id.au>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
Message-ID: <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>

On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
>
> The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> However, KCS devices are useful beyond IPMI (or keyboards), as they
> provide a means to generate IRQs and exchange arbitrary data between a
> BMC and its host system.

I only noticed the series after Joel asked about the DT changes on the arm
side. One question though:

How does this related to the drivers/input/serio/ framework that also talks
to the keyboard controller for things that are not keyboards? Are these
separate communication channels on adjacent I/O ports, or does there
need to be some arbitration?

       Arnd


From j.neuschaefer at gmx.net  Fri Apr  9 08:57:47 2021
From: j.neuschaefer at gmx.net (Jonathan =?utf-8?Q?Neusch=C3=A4fer?=)
Date: Fri, 9 Apr 2021 09:57:47 +0200
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <CACPK8XdbwbsbJuZmvsFqJ+x5viu652vpfR1kwB4Gu+khRHNt_g@mail.gmail.com>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>
 <YGzZofPvT80b5gS5@latitude>
 <CACPK8XdbwbsbJuZmvsFqJ+x5viu652vpfR1kwB4Gu+khRHNt_g@mail.gmail.com>
Message-ID: <YHAI+x4OXBKvJkUH@latitude>

On Fri, Apr 09, 2021 at 04:37:34AM +0000, Joel Stanley wrote:
> On Tue, 6 Apr 2021 at 21:59, Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
> >
> > On Tue, Apr 06, 2021 at 05:15:01PM +0200, Arnd Bergmann wrote:
> > > On Tue, Apr 6, 2021 at 2:09 PM Jonathan Neusch?fer
> > > <j.neuschaefer at gmx.net> wrote:
> > > >
> > > > This series adds basic support for the Nuvoton WPCM450 BMC SoC. It's an older
> > > > SoC but still commonly found on eBay, mostly in Supermicro X9 server boards.
> > > >
> > > > Third-party documentation is available at: https://github.com/neuschaefer/wpcm450/wiki
> > > >
> > > > Patches 1-4 add devicetree bindings for the WPCM450 SoC and its various parts.
> > > > Patches 5-7 add arch and driver support. Patches 8 and 9 add a devicetree for
> > > > the SoC and a board based on it. Patch 10 finally updates the MAINTAINERS file.
> > > >
> > > > Patch 2 requires "dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML"
> > > > (https://lore.kernel.org/lkml/20210320164023.614059-1-j.neuschaefer at gmx.net/)
> > >
> > > Hi Jonathan,
> > >
> > > It appears these patches are doing roughly the right thing, and we may still
> > > be able to get them into v5.13, but I'm not sure what your plan for maintaining
> > > them is. The two options are that you either send your patches to be picked up
> > > by Joel, or you send everything directly to soc at kernel.org once it's fully
> > > reviewed.
> >
> > The route via Joel sounds alright with me. I've Cc'd him on this version
> > of the series.
> 
> I've had a look at the series and it looks good to me:
> 
> Reviewed-by: Joel Stanley <joel at jms.id.au>
> 
> Nice work Jonathan.
> 
> I'll put this in it's own branch along with the bindings change it
> depends on and send a pull request to Arnd for v5.13.

Thanks a bunch!

A few patches are going through other branches (IRQ bindings+driver;
watchdog bindings+driver probably, I guess). That leaves the following
patches to go into your branch, AFAIUI:

[PATCH v2 01/10] dt-bindings: vendor-prefixes: Add Supermicro
[PATCH v2 02/10] dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string
[PATCH v2 05/10] ARM: npcm: Introduce Nuvoton WPCM450 SoC
[PATCH v2 08/10] ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
[PATCH v2 09/10] ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450
[PATCH v2 10/10] MAINTAINERS: Add entry for Nuvoton WPCM450


Jonathan
-------------- 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/20210409/e7f4c791/attachment.sig>

From dinghao.liu at zju.edu.cn  Fri Apr  9 08:59:53 2021
From: dinghao.liu at zju.edu.cn (dinghao.liu at zju.edu.cn)
Date: Fri, 9 Apr 2021 15:59:53 +0800 (GMT+08:00)
Subject: [PATCH] media: imx: imx7-mipi-csis: Fix runtime PM
 imbalance in mipi_csis_s_stream
In-Reply-To: <20210408135702.f7ikjvwirvtzsarv@arch-thunder.localdomain>
References: <20210408090827.32612-1-dinghao.liu@zju.edu.cn>
 <20210408135702.f7ikjvwirvtzsarv@arch-thunder.localdomain>
Message-ID: <5025467a.453b6.178b5a50321.Coremail.dinghao.liu@zju.edu.cn>

> Hi Liu,
> Thanks for your patch.
> 
> On Thu, Apr 08, 2021 at 05:08:27PM +0800, Dinghao Liu wrote:
> > When v4l2_subdev_call() fails, a pairing PM usage counter
> > decrement is needed to keep the counter balanced. It's the
> > same for the following error paths in case 'enable' is on.
> > 
> > Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> > ---
> >  drivers/staging/media/imx/imx7-mipi-csis.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> > index a01a7364b4b9..2a3fff231a40 100644
> > --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> > +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> > @@ -627,21 +627,26 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
> >  			return ret;
> >  		}
> >  		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
> > -		if (ret < 0)
> > +		if (ret < 0) {
> > +			pm_runtime_put_noidle(&state->pdev->dev);
> 
> I think here we should go completely pm_runtime_put to call the
> mipi_csis_pm_suspend down the line, right?
> 
> >  			return ret;
> > +		}
> >  	}
> >  
> >  	mutex_lock(&state->lock);
> >  	if (enable) {
> >  		if (state->flags & ST_SUSPENDED) {
> >  			ret = -EBUSY;
> > +			pm_runtime_put_noidle(&state->pdev->dev);
> 
> since we are in ST_SUSPENDED state, for sure the pm counter was
> already 0.
> 
> >  			goto unlock;
> >  		}
> >  
> >  		mipi_csis_start_stream(state);
> >  		ret = v4l2_subdev_call(state->src_sd, video, s_stream, 1);
> > -		if (ret < 0)
> > +		if (ret < 0) {
> > +			pm_runtime_put_noidle(&state->pdev->dev);
> 
> here also we need the pm_runtime_put, maybe just changing the unlock
> tag bellow from:
>     if (!enable)
>         pm_runtime_put(&state->pdev->dev);
> 
> to 
>     if (!enable || (ret < 0))
>         pm_runtime_put(&state->pdev->dev);
> 
> will not hurt the first case and will complete the suspend routine
> afterward in the second case.
> 

This is much clearer, thanks! I will fix this and send a new patch soon.

Regards,
Dinghao

From arnd at arndb.de  Fri Apr  9 09:04:34 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 9 Apr 2021 10:04:34 +0200
Subject: [PATCH v2 00/10] Initial support for Nuvoton WPCM450 BMC SoC
In-Reply-To: <YHAI+x4OXBKvJkUH@latitude>
References: <20210406120921.2484986-1-j.neuschaefer@gmx.net>
 <CAK8P3a0VfnUucvZNkA9PdxrWiYUOkisV00v-375PmgQYp4aXoQ@mail.gmail.com>
 <YGzZofPvT80b5gS5@latitude>
 <CACPK8XdbwbsbJuZmvsFqJ+x5viu652vpfR1kwB4Gu+khRHNt_g@mail.gmail.com>
 <YHAI+x4OXBKvJkUH@latitude>
Message-ID: <CAK8P3a18ySEmCzkdD-GmQSPFUza_TK3OBPk0Grbz_aFW72+g7g@mail.gmail.com>

On Fri, Apr 9, 2021 at 9:58 AM Jonathan Neusch?fer
<j.neuschaefer at gmx.net> wrote:
> On Fri, Apr 09, 2021 at 04:37:34AM +0000, Joel Stanley wrote:
> > On Tue, 6 Apr 2021 at 21:59, Jonathan Neusch?fer <j.neuschaefer at gmx.net> wrote:
> > I've had a look at the series and it looks good to me:
> >
> > Reviewed-by: Joel Stanley <joel at jms.id.au>
> >
> > Nice work Jonathan.
> >
> > I'll put this in it's own branch along with the bindings change it
> > depends on and send a pull request to Arnd for v5.13.
>
> Thanks a bunch!
>
> A few patches are going through other branches (IRQ bindings+driver;
> watchdog bindings+driver probably, I guess). That leaves the following
> patches to go into your branch, AFAIUI:
>
> [PATCH v2 01/10] dt-bindings: vendor-prefixes: Add Supermicro
> [PATCH v2 02/10] dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string
> [PATCH v2 05/10] ARM: npcm: Introduce Nuvoton WPCM450 SoC
> [PATCH v2 08/10] ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
> [PATCH v2 09/10] ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450
> [PATCH v2 10/10] MAINTAINERS: Add entry for Nuvoton WPCM450

Actually for an initial merge, we sometimes just put all the patches into one
branch in the soc tree to avoid conflicts. Unfortunately we already have a
(trivial) conflict now anyway since I merged the irqchip driver for the Apple
M1 SoC through the soc tree but the wpcm irqchip through the irqchip tree.

You did nothing wrong here, this would have just been a way to make the
initial merge a bit easier, and have a tree that is more easily bisectible
when one branch in the merge window contains all the code that is
needed for booting.

        Arnd


From david at redhat.com  Fri Apr  9 09:07:01 2021
From: david at redhat.com (David Hildenbrand)
Date: Fri, 9 Apr 2021 10:07:01 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a2Wu7tT-YajfdXSSVvg5MYMEnEy3APJ83DcLeJdGkkSrQ@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
 <CAK8P3a2Wu7tT-YajfdXSSVvg5MYMEnEy3APJ83DcLeJdGkkSrQ@mail.gmail.com>
Message-ID: <e6fa1b72-24ca-28bc-0115-7ceceb101e96@redhat.com>

On 08.04.21 15:19, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>>
>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:
>>
>>>> This is something you could do using a hidden helper symbol like
>>>>
>>>> config DRMA_ASPEED_GFX
>>>>          bool "Aspeed display driver"
>>>>          select DRM_WANT_CMA
>>>>
>>>> config DRM_WANT_CMA
>>>>          bool
>>>>          help
>>>>             Select this from any driver that benefits from CMA being enabled
>>>>
>>>> config DMA_CMA
>>>>          bool "Use CMA helpers for DRM"
>>>>          default DRM_WANT_CMA
>>>>
>>>>            Arnd
>>>>
>>>
>>> That's precisely what I had first, with an additional "WANT_CMA" --  but
>>> looking at the number of such existing options (I was able to spot 1 !)
>>
>> If you do this it probably makes sense to fix a few other drivers
>> Kconfig in the process. It's not just a problem with your driver.
>> "my" drivers:
>>
>> drivers/gpu/drm/mcde/Kconfig
>> drivers/gpu/drm/pl111/Kconfig
>> drivers/gpu/drm/tve200/Kconfig
>>
>> certainly needs this as well, and pretty much anything that is
>> selecting DRM_KMS_CMA_HELPER or
>> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
> 
> Are there any that don't select either of the helpers and
> still want CMA? If not, it would be easy to just add
> 
>     default  DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
> 
> and skipt the extra symbol.

That sounds like a reasonable thing to do. I'll look into that.

-- 
Thanks,

David / dhildenb



From qperret at google.com  Fri Apr  9 09:08:11 2021
From: qperret at google.com (Quentin Perret)
Date: Fri, 9 Apr 2021 08:08:11 +0000
Subject: [PATCH v4 1/2] KVM: arm64: Move CMOs from user_mem_abort to the
 fault handlers
In-Reply-To: <20210409033652.28316-2-wangyanan55@huawei.com>
References: <20210409033652.28316-1-wangyanan55@huawei.com>
 <20210409033652.28316-2-wangyanan55@huawei.com>
Message-ID: <YHALa38PPQBceqF9@google.com>

Hi Yanan,

On Friday 09 Apr 2021 at 11:36:51 (+0800), Yanan Wang wrote:
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> +static void stage2_invalidate_icache(void *addr, u64 size)
> +{
> +	if (icache_is_aliasing()) {
> +		/* Flush any kind of VIPT icache */
> +		__flush_icache_all();
> +	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
> +		/* PIPT or VPIPT at EL2 */
> +		invalidate_icache_range((unsigned long)addr,
> +					(unsigned long)addr + size);
> +	}
> +}
> +

I would recommend to try and rebase this patch on kvmarm/next because
we've made a few changes in pgtable.c recently. It is now linked into
the EL2 NVHE code which means there are constraints on what can be used
from there -- you'll need a bit of extra work to make some of these
functions available to EL2.

Thanks,
Quentin


From arnd at arndb.de  Fri Apr  9 09:13:36 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 9 Apr 2021 10:13:36 +0200
Subject: [PATCH v2 00/21] ipmi: Allow raw access to KCS devices
In-Reply-To: <CACPK8Xc5HC7TZ6cUDH6+uHQO1LQCZE0YeENua1sE8nDXs0R2mg@mail.gmail.com>
References: <20210319061952.145040-1-andrew@aj.id.au>
 <2db77e16-3f44-4c02-a7ba-a4fac8141ae3@www.fastmail.com>
 <20210408121441.GG7166@minyard.net>
 <6ff29d26-543a-4790-abb4-ebaa3f8d0265@www.fastmail.com>
 <CACPK8Xc5HC7TZ6cUDH6+uHQO1LQCZE0YeENua1sE8nDXs0R2mg@mail.gmail.com>
Message-ID: <CAK8P3a2ch82=QccNZboa-e1tVaotyJfGFTfqDuQCO0xPVitXgA@mail.gmail.com>

On Fri, Apr 9, 2021 at 6:09 AM Joel Stanley <joel at jms.id.au> wrote:
> On Thu, 8 Apr 2021 at 23:47, Andrew Jeffery <andrew at aj.id.au> wrote:
> > On Thu, 8 Apr 2021, at 21:44, Corey Minyard wrote:
> > > On Thu, Apr 08, 2021 at 10:27:46AM +0930, Andrew Jeffery wrote:
> > > There were some minor concerns that were unanswered, and there really
> > > was no review by others for many of the patches.
> >
> > Right; I was planning to clean up the minor concerns once I'd received
> > some more feedback. I could have done a better job of communicating
> > that :)
>
> I'll merge the first five through the aspeed tree this coming merge
> window. We have acks from the relevant maintainers.
>
> Arnd: would you prefer that this come as it's own pull request, or as
> part of the device tree branch?

When you are unsure, it's almost never wrong to go for a separate
branch, which gives you a chance to have a concise description
of the contents in the tag. This would be particularly helpful if there
are incompatible changes to the DT binding that require a justification.

If you are only adding a few DT nodes to existing files, then merging
these through the regular branch is probably easier.

       Arnd


From daniel.lezcano at linaro.org  Fri Apr  9 09:16:04 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 9 Apr 2021 10:16:04 +0200
Subject: [v7, 3/3] thermal: mediatek: add another get_temp ops for thermal
 sensors
In-Reply-To: <20210316070144.28440-4-michael.kao@mediatek.com>
References: <20210316070144.28440-1-michael.kao@mediatek.com>
 <20210316070144.28440-4-michael.kao@mediatek.com>
Message-ID: <dac1f9bc-6caa-9cb7-97d6-882a8bd20fea@linaro.org>

On 16/03/2021 08:01, Michael Kao wrote:
> Provide thermal zone to read thermal sensor
> in the SoC. We can read all the thermal sensors
> value in the SoC by the node /sys/class/thermal/
> 
> In mtk_thermal_bank_temperature, return -EAGAIN instead of -EACCESS
> on the first read of sensor that often are bogus values.
> This can avoid following warning on boot:
> 
>   thermal thermal_zone6: failed to read out thermal zone (-13)

This patch is changing more things than described in the changelog.

Is it possible to share some technical details about how the sensor(s)
are working or point to some documentation if any ? and possibly the
layout ?

IIUC there is a fake thermal zone zero with the purpose of aggregating
all the other sensors by taking the max temperature of all the sensors.

This patch adds a thermal zone per sensor, and each sensor is per CPU.
CPU0 being actually the max of all the other sensors, right ?


> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/thermal/mtk_thermal.c | 100 +++++++++++++++++++++++++---------
>  1 file changed, 75 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 149c6d7fd5a0..57e4f08a947e 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -245,6 +245,11 @@ enum mtk_thermal_version {
>  
>  struct mtk_thermal;
>  
> +struct mtk_thermal_zone {
> +	struct mtk_thermal *mt;
> +	int id;
> +};
> +
>  struct thermal_bank_cfg {
>  	unsigned int num_sensors;
>  	const int *sensors;
> @@ -637,6 +642,30 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>  		mutex_unlock(&mt->lock);
>  }
>  
> +static u32 _get_sensor_temp(struct mtk_thermal *mt, int id)
> +{
> +	u32 raw;
> +	int temp;
> +
> +	raw = readl(mt->thermal_base + mt->conf->msr[id]);
> +
> +	if (mt->conf->version == MTK_THERMAL_V1)
> +		temp = raw_to_mcelsius_v1(mt, id, raw);
> +	else
> +		temp = raw_to_mcelsius_v2(mt, id, raw);
> +
> +	/*
> +	 * The first read of a sensor often contains very high bogus
> +	 * temperature value. Filter these out so that the system does
> +	 * not immediately shut down.
> +	 */
> +
> +	if (temp > 200000)
> +		return -EAGAIN;
> +	else
> +		return temp;
> +}
> +
>  /**
>   * mtk_thermal_bank_temperature - get the temperature of a bank
>   * @bank:	The bank
> @@ -647,28 +676,11 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>  static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>  {
>  	struct mtk_thermal *mt = bank->mt;
> -	const struct mtk_thermal_data *conf = mt->conf;
>  	int i, temp = INT_MIN, max = INT_MIN;
> -	u32 raw;
> -
> -	for (i = 0; i < conf->bank_data[bank->id].num_sensors; i++) {
> -		raw = readl(mt->thermal_base + conf->msr[i]);
>  
> -		if (mt->conf->version == MTK_THERMAL_V1) {
> -			temp = raw_to_mcelsius_v1(
> -				mt, conf->bank_data[bank->id].sensors[i], raw);
> -		} else {
> -			temp = raw_to_mcelsius_v2(
> -				mt, conf->bank_data[bank->id].sensors[i], raw);
> -		}
> +	for (i = 0; i < mt->conf->bank_data[bank->id].num_sensors; i++) {
>  
> -		/*
> -		 * The first read of a sensor often contains very high bogus
> -		 * temperature value. Filter these out so that the system does
> -		 * not immediately shut down.
> -		 */
> -		if (temp > 200000)
> -			temp = 0;
> +		temp = _get_sensor_temp(mt, i);
>  
>  		if (temp > max)
>  			max = temp;
> @@ -679,7 +691,8 @@ static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>  
>  static int mtk_read_temp(void *data, int *temperature)
>  {
> -	struct mtk_thermal *mt = data;
> +	struct mtk_thermal_zone *tz = data;
> +	struct mtk_thermal *mt = tz->mt;
>  	int i;
>  	int tempmax = INT_MIN;
>  
> @@ -698,10 +711,28 @@ static int mtk_read_temp(void *data, int *temperature)
>  	return 0;
>  }
>  
> +static int mtk_read_sensor_temp(void *data, int *temperature)
> +{
> +	struct mtk_thermal_zone *tz = data;
> +	struct mtk_thermal *mt = tz->mt;
> +	int id = tz->id - 1;
> +
> +	if (id < 0)
> +		return -EACCES;
> +
> +	*temperature = _get_sensor_temp(mt, id);
> +
> +	return 0;
> +}
> +
>  static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
>  	.get_temp = mtk_read_temp,
>  };
>  
> +static const struct thermal_zone_of_device_ops mtk_thermal_sensor_ops = {
> +	.get_temp = mtk_read_sensor_temp,
> +};
> +
>  static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>  				  u32 apmixed_phys_base, u32 auxadc_phys_base,
>  				  int ctrl_id)
> @@ -992,6 +1023,7 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  	u64 auxadc_phys_base, apmixed_phys_base;
>  	struct thermal_zone_device *tzdev;
>  	void __iomem *apmixed_base, *auxadc_base;
> +	struct mtk_thermal_zone *tz;
>  
>  	mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
>  	if (!mt)
> @@ -1080,11 +1112,29 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, mt);
>  
> -	tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, mt,
> -						     &mtk_thermal_ops);
> -	if (IS_ERR(tzdev)) {
> -		ret = PTR_ERR(tzdev);
> -		goto err_disable_clk_peri_therm;
> +	for (i = 0; i < mt->conf->num_sensors + 1; i++) {
> +		tz = devm_kmalloc(&pdev->dev, sizeof(*tz), GFP_KERNEL);
> +		if (!tz)
> +			return -ENOMEM;
> +
> +		tz->mt = mt;
> +		tz->id = i;
> +
> +		tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, i, tz, (i == 0) ?
> +							     &mtk_thermal_ops :
> +							     &mtk_thermal_sensor_ops);
> +
> +		if (IS_ERR(tzdev)) {
> +			if (PTR_ERR(tzdev) == -ENODEV) {
> +				dev_warn(&pdev->dev,
> +					 "sensor %d not registered in thermal zone in dt\n", i);
> +				continue;
> +			}
> +			if (PTR_ERR(tzdev) == -EACCES) {
> +				ret = PTR_ERR(tzdev);
> +				goto err_disable_clk_peri_therm;
> +			}
> +		}
>  	}
>  
>  	return 0;
> 


-- 
<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 nina-cm.wu at mediatek.com  Fri Apr  9 09:19:31 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:31 +0800
Subject: [PATCH v3 1/7] dt-bindings: devapc: Add 'vio-idx-num' field to
 support mt8192
Message-ID: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
We add a field 'vio-idx-num' in DT to indicate the number of
devices controlled by each devapc.
To be backward compatible with old ICs which have only one devapc
HW, this field is not required. The 'vio-idx-num' info will be set
in compatible data instead.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
index 31e4d3c..909e524 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -20,11 +20,17 @@ properties:
   compatible:
     enum:
       - mediatek,mt6779-devapc
+      - mediatek,mt8192-devapc
 
   reg:
     description: The base address of devapc register bank
     maxItems: 1
 
+  mediatek,vio-idx-num:
+    description: The number of the devices controlled by devapc
+    $ref: /schemas/types.yaml#/definitions/uint32
+    maxItems: 1
+
   interrupts:
     description: A single interrupt specifier
     maxItems: 1
-- 
2.6.4

From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:32 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:32 +0800
Subject: [PATCH v3 2/7] soc: mediatek: devapc: get 'vio_idx_num' info from DT
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-2-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
The number of devices controlled by each devapc (i.e. 'vio_idx_num')
will be set in DT for per devapc node.
On the other hand, for old ICs which have only one devapc HW, the
'vio_idx_num' info is set in compatible data.
To be backward compatible, the 'vio_idx_num' in compatible data is set
as the default value. Only when the default value is 0 will we get the
'vio_idx_num' from DT.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index f1cea04..71643d1 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -32,7 +32,7 @@ struct mtk_devapc_vio_dbgs {
 };
 
 struct mtk_devapc_data {
-	/* numbers of violation index */
+	/* default numbers of violation index */
 	u32 vio_idx_num;
 
 	/* reg offset */
@@ -51,6 +51,9 @@ struct mtk_devapc_context {
 	void __iomem *infra_base;
 	struct clk *infra_clk;
 	const struct mtk_devapc_data *data;
+
+	/* numbers of violation index */
+	u32 vio_idx_num;
 };
 
 static void clear_vio_status(struct mtk_devapc_context *ctx)
@@ -60,10 +63,10 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
 
 	reg = ctx->infra_base + ctx->data->vio_sta_offset;
 
-	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num) - 1; i++)
 		writel(GENMASK(31, 0), reg + 4 * i);
 
-	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1, 0),
+	writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num) - 1, 0),
 	       reg + 4 * i);
 }
 
@@ -80,15 +83,15 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
 	else
 		val = 0;
 
-	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num) - 1; i++)
+	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num) - 1; i++)
 		writel(val, reg + 4 * i);
 
 	val = readl(reg + 4 * i);
 	if (mask)
-		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+		val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num) - 1,
 			       0);
 	else
-		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num) - 1,
+		val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->vio_idx_num) - 1,
 				0);
 
 	writel(val, reg + 4 * i);
@@ -256,6 +259,16 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 	if (!ctx->infra_base)
 		return -EINVAL;
 
+	/* Set vio_idx_num to default value.
+	 * If the value is 0, get the info from DT.
+	 */
+	ctx->vio_idx_num = ctx->data->vio_idx_num;
+	if (!ctx->vio_idx_num)
+		if (of_property_read_u32(node,
+					 "vio-idx-num",
+					 &ctx->vio_idx_num))
+			return -EINVAL;
+
 	devapc_irq = irq_of_parse_and_map(node, 0);
 	if (!devapc_irq)
 		return -EINVAL;
-- 
2.6.4

From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:33 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:33 +0800
Subject: [PATCH v3 3/7] soc: mediatek: devapc: add shared flag to IRQ
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-3-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
They all share the same IRQ number.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index 71643d1..6d58a75 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -281,7 +281,7 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 		return -EINVAL;
 
 	ret = devm_request_irq(&pdev->dev, devapc_irq, devapc_violation_irq,
-			       IRQF_TRIGGER_NONE, "devapc", ctx);
+			       IRQF_TRIGGER_NONE | IRQF_SHARED, "devapc", ctx);
 	if (ret) {
 		clk_disable_unprepare(ctx->infra_clk);
 		return ret;
-- 
2.6.4

From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:36 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:36 +0800
Subject: [PATCH v3 6/7] soc: mediatek: devapc: support mt8192
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-6-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

Add compatible to support mt8192.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index bdc8fe9..84dd6a2 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -265,11 +265,27 @@ static const struct mtk_devapc_data devapc_mt6779 = {
 	.vio_shift_con_offset = 0xF20,
 };
 
+static const struct mtk_devapc_data devapc_mt8192 = {
+	.version = 2,
+	.vio_mask_offset = 0x0,
+	.vio_sta_offset = 0x400,
+	.vio_dbg0_offset = 0x900,
+	.vio_dbg1_offset = 0x904,
+	.vio_dbg2_offset = 0x908,
+	.apc_con_offset = 0xF00,
+	.vio_shift_sta_offset = 0xF20,
+	.vio_shift_sel_offset = 0xF30,
+	.vio_shift_con_offset = 0xF10,
+};
+
 static const struct of_device_id mtk_devapc_dt_match[] = {
 	{
 		.compatible = "mediatek,mt6779-devapc",
 		.data = &devapc_mt6779,
 	}, {
+		.compatible = "mediatek,mt8192-devapc",
+		.data = &devapc_mt8192,
+	}, {
 	},
 };
 
-- 
2.6.4

From dinghao.liu at zju.edu.cn  Fri Apr  9 09:22:25 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Fri,  9 Apr 2021 16:22:25 +0800
Subject: [PATCH] [v2] media: imx: imx7-mipi-csis: Fix runtime PM imbalance in
 mipi_csis_s_stream
Message-ID: <20210409082225.22461-1-dinghao.liu@zju.edu.cn>

When v4l2_subdev_call() fails, a pairing PM usage counter
decrement is needed to keep the counter balanced. It's the
same for the following error paths in case 'enable' is on.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---

Changelog:

v2: - Use pm_runtime_put() to balance the refcount.
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index a01a7364b4b9..6f3e8a15e7c4 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -628,7 +628,7 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 		}
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
 		if (ret < 0)
-			return ret;
+			goto pm_put;
 	}
 
 	mutex_lock(&state->lock);
@@ -657,7 +657,8 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 
 unlock:
 	mutex_unlock(&state->lock);
-	if (!enable)
+pm_put:
+	if (!enable || (ret < 0))
 		pm_runtime_put(&state->pdev->dev);
 
 	return ret;
-- 
2.17.1



From masahiroy at kernel.org  Fri Apr  9 09:24:20 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Fri, 9 Apr 2021 17:24:20 +0900
Subject: [PATCH v2 05/13] mmc: sdhci-cadence: Add Pensando Elba SoC support
In-Reply-To: <CAPDyKFpg1qJD0r54sBC3hCoFey_+gwAL1n2o-aGwnAzAan5p7w@mail.gmail.com>
References: <20210329015938.20316-1-brad@pensando.io>
 <20210329015938.20316-6-brad@pensando.io>
 <CAPDyKFpg1qJD0r54sBC3hCoFey_+gwAL1n2o-aGwnAzAan5p7w@mail.gmail.com>
Message-ID: <CAK7LNAQYptL=wJ1ofauX41oV+bZRaSq1V5FabMz4eyZBzxDQaw@mail.gmail.com>

On Tue, Mar 30, 2021 at 7:31 PM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> + Masahiro Yamada (main author of the driver)
>
> On Mon, 29 Mar 2021 at 03:59, Brad Larson <brad at pensando.io> wrote:
> >
> > Add support for Pensando Elba SoC which explicitly controls
> > byte-lane enables on writes.  Refactor to allow platform
> > specific write ops.
> >
> > Signed-off-by: Brad Larson <brad at pensando.io>
> > ---
> >  drivers/mmc/host/Kconfig              |  15 +++
> >  drivers/mmc/host/Makefile             |   1 +
> >  drivers/mmc/host/sdhci-cadence-elba.c | 137 ++++++++++++++++++++++++++
>
> By looking at the amount of code changes that seem to be needed to
> support the Pensando Elba variant, I don't think it's necessary to
> split this into a separate file.
>
> Unless Yamada-san has a different opinion, I would rather just stick
> with using sdhci-cadence.c.


I agree with Ulf.


BTW, this patch cannot probe
"pensando,elba-emmc"
when CONFIG_MMC_SDHCI_CADENCE_ELBA=m.




>
> >  drivers/mmc/host/sdhci-cadence.c      |  81 ++++++++-------
> >  drivers/mmc/host/sdhci-cadence.h      |  68 +++++++++++++
> >  5 files changed, 260 insertions(+), 42 deletions(-)
> >  create mode 100644 drivers/mmc/host/sdhci-cadence-elba.c
> >  create mode 100644 drivers/mmc/host/sdhci-cadence.h
> >
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index b236dfe2e879..65ea323c06f2 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -250,6 +250,21 @@ config MMC_SDHCI_CADENCE
> >
> >           If unsure, say N.
> >
> > +config MMC_SDHCI_CADENCE_ELBA
> > +       tristate "SDHCI support for the Pensando/Cadence SD/SDIO/eMMC controller"
> > +       depends on ARCH_PENSANDO_ELBA_SOC
> > +       depends on MMC_SDHCI
> > +       depends on OF
> > +       depends on MMC_SDHCI_CADENCE
> > +       depends on MMC_SDHCI_PLTFM
> > +       select MMC_SDHCI_IO_ACCESSORS
>
> According to the comment above - then you should probably just extend
> the conditions for when building MMC_SDHCI_CADENCE, rather than having
> to add a new Kconfig for "*_ELBA".
>
> > +       help
> > +         This selects the Pensando/Cadence SD/SDIO/eMMC controller.
> > +
> > +         If you have a controller with this interface, say Y or M here.
> > +
> > +         If unsure, say N.
> > +
> >  config MMC_SDHCI_CNS3XXX
> >         tristate "SDHCI support on the Cavium Networks CNS3xxx SoC"
> >         depends on ARCH_CNS3XXX || COMPILE_TEST
> > diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> > index 6df5c4774260..f2a6d50e64de 100644
> > --- a/drivers/mmc/host/Makefile
> > +++ b/drivers/mmc/host/Makefile
> > @@ -80,6 +80,7 @@ obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
> >
> >  obj-$(CONFIG_MMC_SDHCI_PLTFM)          += sdhci-pltfm.o
> >  obj-$(CONFIG_MMC_SDHCI_CADENCE)                += sdhci-cadence.o
> > +obj-$(CONFIG_MMC_SDHCI_CADENCE_ELBA)   += sdhci-cadence-elba.o
> >  obj-$(CONFIG_MMC_SDHCI_CNS3XXX)                += sdhci-cns3xxx.o
> >  obj-$(CONFIG_MMC_SDHCI_ESDHC_MCF)       += sdhci-esdhc-mcf.o
> >  obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)      += sdhci-esdhc-imx.o
> > diff --git a/drivers/mmc/host/sdhci-cadence-elba.c b/drivers/mmc/host/sdhci-cadence-elba.c
> > new file mode 100644
> > index 000000000000..ec23f43de407
> > --- /dev/null
> > +++ b/drivers/mmc/host/sdhci-cadence-elba.c
> > @@ -0,0 +1,137 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2020 Pensando Systems, Inc.
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/bits.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/module.h>
> > +#include <linux/mmc/host.h>
> > +#include <linux/mmc/mmc.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +
> > +#include "sdhci-pltfm.h"
> > +#include "sdhci-cadence.h"
> > +
> > +// delay regs address
>
> Please don't use "//" when adding comments, but instead "/* ... */".
> This applies to several more places of the patch.
>
> > +#define SDIO_REG_HRS4          0x10

This is the same as SDHCI_CDNS_HRS04



> > +#define REG_DELAY_HS           0x00

This is the same as SDHCI_CDNS_PHY_DLY_SD_HS


> > +#define REG_DELAY_DEFAULT      0x01


This is the same as SDHCI_CDNS_PHY_DLY_SD_DEFAULT



> > +#define REG_DELAY_UHSI_SDR50   0x04

This is the same as SDHCI_CDNS_PHY_DLY_UHS_SDR50



> > +#define REG_DELAY_UHSI_DDR50   0x05


This is the same as SDHCI_CDNS_PHY_DLY_UHS_DDR50



> > +
> > +static void elba_write_l(struct sdhci_host *host, u32 val, int reg)
> > +{
> > +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> > +       unsigned long flags;
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(0x78, priv->ctl_addr);
> > +       writel(val, host->ioaddr + reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
> > +}
> > +
> > +static void elba_write_w(struct sdhci_host *host, u16 val, int reg)
> > +{
> > +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> > +       unsigned long flags;
> > +       u32 m = (reg & 0x3);
> > +       u32 msk = (0x3 << (m));
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(msk << 3, priv->ctl_addr);
> > +       writew(val, host->ioaddr + reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
> > +}
> > +
> > +static void elba_write_b(struct sdhci_host *host, u8 val, int reg)
> > +{
> > +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> > +       unsigned long flags;
> > +       u32 m = (reg & 0x3);
> > +       u32 msk = (0x1 << (m));
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(msk << 3, priv->ctl_addr);
> > +       writeb(val, host->ioaddr + reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
> > +}
> > +
> > +static void elba_priv_write_l(struct sdhci_cdns_priv *priv,
> > +               u32 val, void __iomem *reg)
> > +{
> > +       unsigned long flags;
> > +
> > +       spin_lock_irqsave(&priv->wrlock, flags);
> > +       writel(0x78, priv->ctl_addr);
> > +       writel(val, reg);
> > +       spin_unlock_irqrestore(&priv->wrlock, flags);
> > +}


Maybe, can this avoid code duplication?

static void elba_hrs_write_l(struct sdhci_cdns_priv *priv,
                              u32 val, int reg)
{
        unsigned long flags;

        spin_lock_irqsave(&priv->wrlock, flags);
        writel(0x78, priv->ctl_addr);
        writel(val, priv->hrs_addr + reg);
        spin_unlock_irqrestore(&priv->wrlock, flags);
}

static void elba_write_l(struct sdhci_host *host, u32 val, int reg)
{
        elba_hrs_write_l(sdhci_cdns_priv(host), val, SDHCI_CDNS_SRS_BASE + reg);
}







> > +
> > +static const struct sdhci_ops sdhci_elba_ops = {
> > +       .write_l = elba_write_l,
> > +       .write_w = elba_write_w,
> > +       .write_b = elba_write_b,
> > +       .set_clock = sdhci_set_clock,
> > +       .get_timeout_clock = sdhci_cdns_get_timeout_clock,
> > +       .set_bus_width = sdhci_set_bus_width,
> > +       .reset = sdhci_reset,
> > +       .set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
> > +};
> > +
> > +static void sd4_set_dlyvr(struct sdhci_host *host,
> > +                         unsigned char addr, unsigned char data)
>
> Please, try to think of a better function name that's more
> descriptive. Moreover, please use a common prefix for functions that
> is used on elba.
>
> > +{
> > +       unsigned long dlyrv_reg;
> > +
> > +       dlyrv_reg = ((unsigned long)data << 8);
> > +       dlyrv_reg |= addr;
> > +
> > +       // set data and address
> > +       writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4);
> > +       dlyrv_reg |= (1uL << 24uL);
> > +       // send write request
> > +       writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4);
> > +       dlyrv_reg &= ~(1uL << 24);
> > +       // clear write request
> > +       writel(dlyrv_reg, host->ioaddr + SDIO_REG_HRS4);


This seems to be equivalent to sdhci_cdns_write_phy_reg().




> > +}
> > +
> > +static void phy_config(struct sdhci_host *host)
>
> Ditto.
>
> > +{
> > +       sd4_set_dlyvr(host, REG_DELAY_DEFAULT, 0x04);
> > +       sd4_set_dlyvr(host, REG_DELAY_HS, 0x04);
> > +       sd4_set_dlyvr(host, REG_DELAY_UHSI_SDR50, 0x06);
> > +       sd4_set_dlyvr(host, REG_DELAY_UHSI_DDR50, 0x16);


Hard-code board (or chip) specific parameters to the driver?

This should go to DT properties.

See Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml





> > +}
> > +
> > +static int elba_drv_init(struct platform_device *pdev)
> > +{
> > +       struct sdhci_host *host = platform_get_drvdata(pdev);
> > +       struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> > +       struct resource *iomem;
> > +       void __iomem *ioaddr;
> > +
> > +       host->mmc->caps |= (MMC_CAP_1_8V_DDR | MMC_CAP_8_BIT_DATA);
> > +       iomem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > +       if (!iomem)
> > +               return -ENOMEM;
> > +       ioaddr = devm_ioremap_resource(&pdev->dev, iomem);
> > +       if (IS_ERR(ioaddr))
> > +               return PTR_ERR(ioaddr);



Use  devm_platform_ioremap_resource(pdev, 1)







> > +       priv->ctl_addr = ioaddr;
> > +       priv->priv_write_l = elba_priv_write_l;
> > +       spin_lock_init(&priv->wrlock);
> > +       writel(0x78, priv->ctl_addr);
> > +       phy_config(host);
> > +       return 0;
> > +}
> > +
> > +const struct sdhci_cdns_drv_data sdhci_elba_drv_data = {
> > +       .init = elba_drv_init,
> > +       .pltfm_data = {
> > +               .ops = &sdhci_elba_ops,
> > +       },
> > +};
> > diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> > index 6f2de54a5987..d1ae996c3824 100644
> > --- a/drivers/mmc/host/sdhci-cadence.c
> > +++ b/drivers/mmc/host/sdhci-cadence.c
> > @@ -14,6 +14,7 @@
> >  #include <linux/of_device.h>
> >
> >  #include "sdhci-pltfm.h"
> > +#include "sdhci-cadence.h"
> >
> >  /* HRS - Host Register Set (specific to Cadence) */
> >  #define SDHCI_CDNS_HRS04               0x10            /* PHY access port */
> > @@ -59,23 +60,6 @@
> >   */
> >  #define SDHCI_CDNS_MAX_TUNING_LOOP     40
> >
> > -struct sdhci_cdns_phy_param {
> > -       u8 addr;
> > -       u8 data;
> > -};
> > -
> > -struct sdhci_cdns_priv {
> > -       void __iomem *hrs_addr;
> > -       bool enhanced_strobe;
> > -       unsigned int nr_phy_params;
> > -       struct sdhci_cdns_phy_param phy_params[];
> > -};
> > -
> > -struct sdhci_cdns_phy_cfg {
> > -       const char *property;
> > -       u8 addr;
> > -};
> > -
> >  static const struct sdhci_cdns_phy_cfg sdhci_cdns_phy_cfgs[] = {
> >         { "cdns,phy-input-delay-sd-highspeed", SDHCI_CDNS_PHY_DLY_SD_HS, },
> >         { "cdns,phy-input-delay-legacy", SDHCI_CDNS_PHY_DLY_SD_DEFAULT, },
> > @@ -104,17 +88,17 @@ static int sdhci_cdns_write_phy_reg(struct sdhci_cdns_priv *priv,
> >
> >         tmp = FIELD_PREP(SDHCI_CDNS_HRS04_WDATA, data) |
> >               FIELD_PREP(SDHCI_CDNS_HRS04_ADDR, addr);
> > -       writel(tmp, reg);
> > +       sdhci_cdns_priv_writel(priv, tmp, reg);
> >
> >         tmp |= SDHCI_CDNS_HRS04_WR;
> > -       writel(tmp, reg);
> > +       sdhci_cdns_priv_writel(priv, tmp, reg);
> >
> >         ret = readl_poll_timeout(reg, tmp, tmp & SDHCI_CDNS_HRS04_ACK, 0, 10);
> >         if (ret)
> >                 return ret;
> >
> >         tmp &= ~SDHCI_CDNS_HRS04_WR;
> > -       writel(tmp, reg);
> > +       sdhci_cdns_priv_writel(priv, tmp, reg);
> >
> >         ret = readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS04_ACK),
> >                                  0, 10);
> > @@ -167,14 +151,7 @@ static int sdhci_cdns_phy_init(struct sdhci_cdns_priv *priv)
> >         return 0;
> >  }
> >
> > -static void *sdhci_cdns_priv(struct sdhci_host *host)
> > -{
> > -       struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > -
> > -       return sdhci_pltfm_priv(pltfm_host);
> > -}
> > -
> > -static unsigned int sdhci_cdns_get_timeout_clock(struct sdhci_host *host)
> > +unsigned int sdhci_cdns_get_timeout_clock(struct sdhci_host *host)
> >  {
> >         /*
> >          * Cadence's spec says the Timeout Clock Frequency is the same as the
> > @@ -191,7 +168,7 @@ static void sdhci_cdns_set_emmc_mode(struct sdhci_cdns_priv *priv, u32 mode)
> >         tmp = readl(priv->hrs_addr + SDHCI_CDNS_HRS06);
> >         tmp &= ~SDHCI_CDNS_HRS06_MODE;
> >         tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_MODE, mode);
> > -       writel(tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
> > +       sdhci_cdns_priv_writel(priv, tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
> >  }
> >
> >  static u32 sdhci_cdns_get_emmc_mode(struct sdhci_cdns_priv *priv)
> > @@ -223,7 +200,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
> >          */
> >         for (i = 0; i < 2; i++) {
> >                 tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
> > -               writel(tmp, reg);
> > +               sdhci_cdns_priv_writel(priv, tmp, reg);
> >
> >                 ret = readl_poll_timeout(reg, tmp,
> >                                          !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
> > @@ -272,10 +249,13 @@ static int sdhci_cdns_execute_tuning(struct sdhci_host *host, u32 opcode)
> >                 return -EIO;
> >         }
> >
> > +       dev_info(mmc_dev(host->mmc), "tuning val %d streak end %d max %d\n",
> > +                end_of_streak - max_streak / 2, end_of_streak, max_streak);
> > +
> >         return sdhci_cdns_set_tune_val(host, end_of_streak - max_streak / 2);
> >  }
> >
> > -static void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
> > +void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
> >                                          unsigned int timing)
> >  {
> >         struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> > @@ -318,13 +298,17 @@ static const struct sdhci_ops sdhci_cdns_ops = {
> >         .set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
> >  };
> >
> > -static const struct sdhci_pltfm_data sdhci_cdns_uniphier_pltfm_data = {
> > -       .ops = &sdhci_cdns_ops,
> > -       .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> > +static const struct sdhci_cdns_drv_data sdhci_cdns_uniphier_drv_data = {
> > +       .pltfm_data = {
> > +               .ops = &sdhci_cdns_ops,
> > +               .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> > +       },
> >  };
> >
> > -static const struct sdhci_pltfm_data sdhci_cdns_pltfm_data = {
> > -       .ops = &sdhci_cdns_ops,
> > +static const struct sdhci_cdns_drv_data sdhci_cdns_drv_data = {
> > +       .pltfm_data = {
> > +               .ops = &sdhci_cdns_ops,
> > +       },
> >  };
> >
> >  static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
> > @@ -350,7 +334,7 @@ static void sdhci_cdns_hs400_enhanced_strobe(struct mmc_host *mmc,
> >  static int sdhci_cdns_probe(struct platform_device *pdev)
> >  {
> >         struct sdhci_host *host;
> > -       const struct sdhci_pltfm_data *data;
> > +       const struct sdhci_cdns_drv_data *data;
> >         struct sdhci_pltfm_host *pltfm_host;
> >         struct sdhci_cdns_priv *priv;
> >         struct clk *clk;
> > @@ -369,10 +353,10 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
> >
> >         data = of_device_get_match_data(dev);
> >         if (!data)
> > -               data = &sdhci_cdns_pltfm_data;
> > +               data = &sdhci_cdns_drv_data;
> >
> >         nr_phy_params = sdhci_cdns_phy_param_count(dev->of_node);
> > -       host = sdhci_pltfm_init(pdev, data,
> > +       host = sdhci_pltfm_init(pdev, &data->pltfm_data,
> >                                 struct_size(priv, phy_params, nr_phy_params));
> >         if (IS_ERR(host)) {
> >                 ret = PTR_ERR(host);
> > @@ -389,11 +373,18 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
> >         host->ioaddr += SDHCI_CDNS_SRS_BASE;
> >         host->mmc_host_ops.hs400_enhanced_strobe =
> >                                 sdhci_cdns_hs400_enhanced_strobe;
> > -       sdhci_enable_v4_mode(host);
> > -       __sdhci_read_caps(host, &version, NULL, NULL);
> >
> >         sdhci_get_of_property(pdev);
> >
> > +       if (data->init) {
> > +               ret = data->init(pdev);
> > +               if (ret)
> > +                       goto free;
> > +       }
> > +
> > +       sdhci_enable_v4_mode(host);
> > +       __sdhci_read_caps(host, &version, NULL, NULL);
> > +
> >         ret = mmc_of_parse(host->mmc);
> >         if (ret)
> >                 goto free;
> > @@ -453,8 +444,14 @@ static const struct dev_pm_ops sdhci_cdns_pm_ops = {
> >  static const struct of_device_id sdhci_cdns_match[] = {
> >         {
> >                 .compatible = "socionext,uniphier-sd4hc",
> > -               .data = &sdhci_cdns_uniphier_pltfm_data,
> > +               .data = &sdhci_cdns_uniphier_drv_data,
> >         },
> > +#ifdef CONFIG_MMC_SDHCI_CADENCE_ELBA
>
> No need to hide this minor piece of code behind ifdefs.
>
> > +       {
> > +               .compatible = "pensando,elba-emmc",
> > +               .data = &sdhci_elba_drv_data
> > +       },
> > +#endif
> >         { .compatible = "cdns,sd4hc" },
> >         { /* sentinel */ }
> >  };
> > diff --git a/drivers/mmc/host/sdhci-cadence.h b/drivers/mmc/host/sdhci-cadence.h
> > new file mode 100644
> > index 000000000000..bf48e8d13430
> > --- /dev/null
> > +++ b/drivers/mmc/host/sdhci-cadence.h
>
> This new header file can go away too, if you fold in all the code in
> the common c-file.
>
> > @@ -0,0 +1,68 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright (C) 2016 Socionext Inc.
> > + *   Author: Masahiro Yamada <yamada.masahiro at socionext.com>
> > + */
> > +
> > +#ifndef _SDHCI_CADENCE_H_
> > +#define _SDHCI_CADENCE_H_
> > +
> > +struct sdhci_cdns_phy_param {
> > +       u8 addr;
> > +       u8 data;
> > +};
> > +
> > +struct sdhci_cdns_priv {
> > +       void __iomem *hrs_addr;
> > +#ifdef CONFIG_MMC_SDHCI_CADENCE_ELBA
> > +       void __iomem *ctl_addr; /* write control */
> > +       spinlock_t wrlock;      /* write lock */
> > +#endif
> > +       bool enhanced_strobe;
> > +       void (*priv_write_l)(struct sdhci_cdns_priv *priv, u32 val,
> > +                            void __iomem *reg); /* for cadence-elba.c */
> > +       unsigned int nr_phy_params;
> > +       struct sdhci_cdns_phy_param phy_params[];
> > +};
> > +
> > +struct sdhci_cdns_phy_cfg {
> > +       const char *property;
> > +       u8 addr;
> > +};
> > +
> > +struct sdhci_cdns_drv_data {
> > +       int (*init)(struct platform_device *pdev);
> > +       const struct sdhci_pltfm_data pltfm_data;
> > +};
> > +
> > +static inline void *sdhci_cdns_priv(struct sdhci_host *host)
> > +{
> > +       struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > +
> > +       return sdhci_pltfm_priv(pltfm_host);
> > +}
> > +
> > +/*
> > + * The Pensando Elba SoC explicitly controls byte-lane enables on writes,
> > + * which includes writes to the HRS registers.
> > + * sdhci_cdns_priv_writel() is used in the common sdhci-cadence.c code
> > + * to write HRS registers, and this function dispatches to the specific
> > + * code.
> > + */
> > +static inline void sdhci_cdns_priv_writel(struct sdhci_cdns_priv *priv,
> > +               u32 val, void __iomem *reg)
> > +{
> > +       if (unlikely(priv->priv_write_l))
> > +               priv->priv_write_l(priv, val, reg);
> > +       else
> > +               writel(val, reg);
> > +}
> > +
> > +#ifdef CONFIG_MMC_SDHCI_CADENCE_ELBA
> > +extern const struct sdhci_cdns_drv_data sdhci_elba_drv_data;
> > +#endif
> > +
> > +unsigned int sdhci_cdns_get_timeout_clock(struct sdhci_host *host);
> > +void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host, unsigned int timing);
> > +
> > +#endif
>
> Kind regards
> Uffe



--
Best Regards
Masahiro Yamada


From tudor.ambarus at microchip.com  Fri Apr  9 09:25:22 2021
From: tudor.ambarus at microchip.com (Tudor Ambarus)
Date: Fri, 9 Apr 2021 11:25:22 +0300
Subject: [PATCH] pinctrl: at91-pio4: Fix slew rate disablement
Message-ID: <20210409082522.625168-1-tudor.ambarus@microchip.com>

The slew rate was enabled by default for each configuration of the
pin. In case the pin had more than one configuration, even if
we set the slew rate as disabled in the device tree, the next pin
configuration would set again the slew rate enabled by default,
overwriting the slew rate disablement.
Instead of enabling the slew rate by default for each pin configuration,
enable the slew rate by default just once per pin, regardless of the
number of configurations. This way the slew rate disablement will also
work for cases where pins have multiple configurations.

Fixes: 440b144978ba ("pinctrl: at91-pio4: add support for slew-rate")
Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index a5d328808e4c..4c01d8471ffa 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -801,6 +801,10 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
 
 	conf = atmel_pin_config_read(pctldev, pin_id);
 
+	/* Keep slew rate enabled by default. */
+	if (atmel_pioctrl->slew_rate_support)
+		conf |= ATMEL_PIO_SR_MASK;
+
 	for (i = 0; i < num_configs; i++) {
 		unsigned int param = pinconf_to_config_param(configs[i]);
 		unsigned int arg = pinconf_to_config_argument(configs[i]);
@@ -808,10 +812,6 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
 		dev_dbg(pctldev->dev, "%s: pin=%u, config=0x%lx\n",
 			__func__, pin_id, configs[i]);
 
-		/* Keep slew rate enabled by default. */
-		if (atmel_pioctrl->slew_rate_support)
-			conf |= ATMEL_PIO_SR_MASK;
-
 		switch (param) {
 		case PIN_CONFIG_BIAS_DISABLE:
 			conf &= (~ATMEL_PIO_PUEN_MASK);
-- 
2.25.1



From maz at kernel.org  Fri Apr  9 09:28:58 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 09 Apr 2021 09:28:58 +0100
Subject: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE
In-Reply-To: <CAK8P3a2+=LjnLtgvGx3s9i3X_9ypHZ6pEfObcjBtV2sVRrTmzw@mail.gmail.com>
References: <20210408131010.1109027-1-maz@kernel.org>
 <20210408131010.1109027-4-maz@kernel.org>
 <CAK8P3a2+=LjnLtgvGx3s9i3X_9ypHZ6pEfObcjBtV2sVRrTmzw@mail.gmail.com>
Message-ID: <87mtu7oo8l.wl-maz@kernel.org>

On Thu, 08 Apr 2021 22:47:38 +0100,
Arnd Bergmann <arnd at kernel.org> wrote:
> 
> On Thu, Apr 8, 2021 at 3:10 PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
> > and has been enabled by default for almost all that time.
> >
> > Given that newer systems that are VHE capable are finally becoming
> > available, and that some systems are even incapable of not running VHE,
> > drop the configuration altogether.
> >
> > Anyone willing to stick to non-VHE on VHE hardware for obscure
> > reasons should use the 'kvm-arm.mode=nvhe' command-line option.
> 
> Have you considered adding options to do the reverse logic for this
> and other features, such as making support for the old non-VHE
> optional at compile time?

This nVHE code is exclusively limited to KVM, because the whole point
of VHE is that the EL1 kernel can run at EL2 completely unchanged.
Furthermore, nVHE has properties that VHE cannot deliver, such as
memory isolation between host and guests.

So no, I wouldn't consider make it optional at compile time. Instead,
I would consider jettisoning the nVHE EL2 code after init to save a
handful of pages when running on a VHE-capable system in VHE mode.

> 
> I understand that so far the rule is (almost) always that an arm64 kernel
> should run on any Armv8.0-A or higher system regardless of configuration,
> but the now announced Armv9.0-A definition might be the chance to
> introduce the concept of a minimum level the way we do on other
> architectures (e.g. armv6/v6k/v7 or k8/pentium4/core2/atom/generic).
>
> The way I can see this working would be to have a single user-visible
> option that controls whether the kernel supports only Armv9.0-A/Armv8.5-A
> and assumes all mandatory features of that are present, or it remains
> as before and supports all implementations back to the first v8.

The view that v8.5/v9 is a monolithic setup with a set of mandatory
option is unfortunately disconnected from reality. Reality is that an
implementer picks and chooses whatever feature set they want
irrespective of what the architecture says, and the architecture
revision is nothing but an index into the documentation.

Features that were mandatory often become optional, and/or are further
made unimplementable due to some other extension of the architecture.
We also have the extremely common case where a feature that is usable
on a host isn't virtualisable, meaning that the kernel gets exposed
different feature sets depending on whether it runs bare-metal or not,
which puts another nail on the "per-revision feature set" coffin.

The ARM architecture is effectively a mix-and-match system, where you
choose the feature set you want for a single vertically integrated
application, and not a nice linear progression of features that land
in bulk.

> This would help eliminate the runtime detection for not just VHE but
> also LSE, LPA, PAN, etc. Not sure how significant the cost of any of
> those are in terms of runtime performance and/or code size, but it
> would feel nice to be able to build a kernel that can actually rely
> on sane hardware features even if it will take a few more years before
> that hardware becomes common enough to actually get some distros
> ship a kernel that requires v8.5/v9.0.

We went there with 32bit because we were forced to: different ISAs,
different page table formats. I would rather keep a single kernel
until we get to that point of divergence *or* that we can demonstrate
such a significant performance/maintenance improvement that it'd be
silly not to do it.

The published architecture does not hint at such changes yet, nor has
performance overhead been reported due to "feature bloat". The current
feature discovery and runtime patching seems adequate and saves us
from the bitrot effect that multiple configurations inevitably would
trigger.

So at the moment, I am strongly in favor of keeping the current
"single kernel" approach, and even drop more of the existing
configuration symbols (though some have ugly toolchain constraints).

Thanks,

	M.

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


From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:35 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:35 +0800
Subject: [PATCH v3 5/7] soc: mediatek: devapc: add debug register for new IC
 support
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-5-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

There are 3 debug info registers in new ICs while in legacy ones,
we have only 2. We add a 'version' field in compatible data to
decide how we extract the debug info.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 43 +++++++++++++++++++++++++++++++++++----
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index f5d63c5..bdc8fe9 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -26,12 +26,24 @@ struct mtk_devapc_vio_dbgs {
 			u32 addr_h:4;
 			u32 resv:4;
 		} dbg0_bits;
+
+		struct {
+			u32 dmnid:6;
+			u32 vio_w:1;
+			u32 vio_r:1;
+			u32 addr_h:4;
+			u32 resv:20;
+		} dbg0_bits_ver2;
 	};
 
 	u32 vio_dbg1;
+	u32 vio_dbg2;
 };
 
 struct mtk_devapc_data {
+	/* architecture version */
+	u32 version;
+
 	/* default numbers of violation index */
 	u32 vio_idx_num;
 
@@ -40,6 +52,7 @@ struct mtk_devapc_data {
 	u32 vio_sta_offset;
 	u32 vio_dbg0_offset;
 	u32 vio_dbg1_offset;
+	u32 vio_dbg2_offset;
 	u32 apc_con_offset;
 	u32 vio_shift_sta_offset;
 	u32 vio_shift_sel_offset;
@@ -163,22 +176,43 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
 	struct mtk_devapc_vio_dbgs vio_dbgs;
 	void __iomem *vio_dbg0_reg;
 	void __iomem *vio_dbg1_reg;
+	void __iomem *vio_dbg2_reg;
+	u32 vio_addr, bus_id, domain_id;
+	u32 vio_w, vio_r;
 
 	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
 	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
+	vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
 
 	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
 	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
+	if (ctx->data->version == 2U)
+		vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
+
+	if (ctx->data->version == 1U) {
+		/* arch version 1 */
+		bus_id = vio_dbgs.dbg0_bits.mstid;
+		vio_addr = vio_dbgs.vio_dbg1;
+		domain_id = vio_dbgs.dbg0_bits.dmnid;
+		vio_w = vio_dbgs.dbg0_bits.vio_w;
+		vio_r = vio_dbgs.dbg0_bits.vio_r;
+	} else {
+		/* arch version 2 */
+		bus_id = vio_dbgs.vio_dbg1;
+		vio_addr = vio_dbgs.vio_dbg2;
+		domain_id = vio_dbgs.dbg0_bits_ver2.dmnid;
+		vio_w = vio_dbgs.dbg0_bits_ver2.vio_w;
+		vio_r = vio_dbgs.dbg0_bits_ver2.vio_r;
+	}
 
 	/* Print violation information */
-	if (vio_dbgs.dbg0_bits.vio_w)
+	if (vio_w)
 		dev_info(ctx->dev, "Write Violation\n");
-	else if (vio_dbgs.dbg0_bits.vio_r)
+	else if (vio_r)
 		dev_info(ctx->dev, "Read Violation\n");
 
 	dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
-		 vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
-		 vio_dbgs.vio_dbg1);
+		 bus_id, domain_id, vio_addr);
 }
 
 /*
@@ -219,6 +253,7 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
 }
 
 static const struct mtk_devapc_data devapc_mt6779 = {
+	.version = 1,
 	.vio_idx_num = 511,
 	.vio_mask_offset = 0x0,
 	.vio_sta_offset = 0x400,
-- 
2.6.4

From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:34 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:34 +0800
Subject: [PATCH v3 4/7] soc: mediatek: devapc: rename register variable
 infra_base
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-4-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

For new ICs, there are multiple devapc HWs for different subsys.
For example, there is devapc respectively for infra, peri, peri2, etc.
So we rename the variable 'infra_base' to 'base' for code readability.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
 drivers/soc/mediatek/mtk-devapc.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
index 6d58a75..f5d63c5 100644
--- a/drivers/soc/mediatek/mtk-devapc.c
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -48,7 +48,7 @@ struct mtk_devapc_data {
 
 struct mtk_devapc_context {
 	struct device *dev;
-	void __iomem *infra_base;
+	void __iomem *base;
 	struct clk *infra_clk;
 	const struct mtk_devapc_data *data;
 
@@ -61,7 +61,7 @@ static void clear_vio_status(struct mtk_devapc_context *ctx)
 	void __iomem *reg;
 	int i;
 
-	reg = ctx->infra_base + ctx->data->vio_sta_offset;
+	reg = ctx->base + ctx->data->vio_sta_offset;
 
 	for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->vio_idx_num) - 1; i++)
 		writel(GENMASK(31, 0), reg + 4 * i);
@@ -76,7 +76,7 @@ static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
 	u32 val;
 	int i;
 
-	reg = ctx->infra_base + ctx->data->vio_mask_offset;
+	reg = ctx->base + ctx->data->vio_mask_offset;
 
 	if (mask)
 		val = GENMASK(31, 0);
@@ -118,11 +118,11 @@ static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
 	int ret;
 	u32 val;
 
-	pd_vio_shift_sta_reg = ctx->infra_base +
+	pd_vio_shift_sta_reg = ctx->base +
 			       ctx->data->vio_shift_sta_offset;
-	pd_vio_shift_sel_reg = ctx->infra_base +
+	pd_vio_shift_sel_reg = ctx->base +
 			       ctx->data->vio_shift_sel_offset;
-	pd_vio_shift_con_reg = ctx->infra_base +
+	pd_vio_shift_con_reg = ctx->base +
 			       ctx->data->vio_shift_con_offset;
 
 	/* Find the minimum shift group which has violation */
@@ -164,8 +164,8 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
 	void __iomem *vio_dbg0_reg;
 	void __iomem *vio_dbg1_reg;
 
-	vio_dbg0_reg = ctx->infra_base + ctx->data->vio_dbg0_offset;
-	vio_dbg1_reg = ctx->infra_base + ctx->data->vio_dbg1_offset;
+	vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
+	vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
 
 	vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
 	vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
@@ -203,7 +203,7 @@ static irqreturn_t devapc_violation_irq(int irq_number, void *data)
  */
 static void start_devapc(struct mtk_devapc_context *ctx)
 {
-	writel(BIT(31), ctx->infra_base + ctx->data->apc_con_offset);
+	writel(BIT(31), ctx->base + ctx->data->apc_con_offset);
 
 	mask_module_irq(ctx, false);
 }
@@ -215,7 +215,7 @@ static void stop_devapc(struct mtk_devapc_context *ctx)
 {
 	mask_module_irq(ctx, true);
 
-	writel(BIT(2), ctx->infra_base + ctx->data->apc_con_offset);
+	writel(BIT(2), ctx->base + ctx->data->apc_con_offset);
 }
 
 static const struct mtk_devapc_data devapc_mt6779 = {
@@ -255,8 +255,8 @@ static int mtk_devapc_probe(struct platform_device *pdev)
 	ctx->data = of_device_get_match_data(&pdev->dev);
 	ctx->dev = &pdev->dev;
 
-	ctx->infra_base = of_iomap(node, 0);
-	if (!ctx->infra_base)
+	ctx->base = of_iomap(node, 0);
+	if (!ctx->base)
 		return -EINVAL;
 
 	/* Set vio_idx_num to default value.
-- 
2.6.4

From nina-cm.wu at mediatek.com  Fri Apr  9 09:19:37 2021
From: nina-cm.wu at mediatek.com (Nina Wu)
Date: Fri, 9 Apr 2021 16:19:37 +0800
Subject: [PATCH v3 7/7] arm64: dts: mt8192: Add devapc node
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <1617956377-4075-7-git-send-email-nina-cm.wu@mediatek.com>

From: Nina Wu <Nina-CM.Wu at mediatek.com>

Add devapc nodes to mt8192.

Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
---
This patch depends on "Add dt-bindings of MT8192 clocks" [1]
and "Add mt8192 clock controllers" [2]

[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/20210331083854.7650-2-chun-jie.chen at mediatek.com/
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 36 ++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index fe24cc6..4f5fb62 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -518,6 +518,33 @@
 			clock-names = "clk13m";
 		};
 
+		devapc_infra: devapc at 10207000 {
+			compatible = "mediatek,mt8192-devapc";
+			reg = <0 0x10207000 0 0x1000>;
+			vio-idx-num = <367>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&infracfg CLK_INFRA_DEVICE_APC>;
+			clock-names = "devapc-infra-clock";
+		};
+
+		devapc_peri: devapc at 10274000 {
+			compatible = "mediatek,mt8192-devapc";
+			reg = <0 0x10274000 0 0x1000>;
+			vio-idx-num = <292>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&infracfg CLK_INFRA_DEVICE_APC>;
+			clock-names = "devapc-infra-clock";
+		};
+
+		devapc_peri2: devapc at 10275000 {
+			compatible = "mediatek,mt8192-devapc";
+			reg = <0 0x10275000 0 0x1000>;
+			vio-idx-num = <242>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&infracfg CLK_INFRA_DEVICE_APC>;
+			clock-names = "devapc-infra-clock";
+		};
+
 		scp_adsp: syscon at 10720000 {
 			compatible = "mediatek,mt8192-scp_adsp", "syscon";
 			reg = <0 0x10720000 0 0x1000>;
@@ -662,6 +689,15 @@
 			status = "disabled";
 		};
 
+		devapc_peri_par: devapc at 11020000 {
+			compatible = "mediatek,mt8192-devapc";
+			reg = <0 0x11020000 0 0x1000>;
+			vio-idx-num = <58>;
+			interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&infracfg CLK_INFRA_DEVICE_APC>;
+			clock-names = "devapc-infra-clock";
+		};
+
 		nor_flash: spi at 11234000 {
 			compatible = "mediatek,mt8192-nor";
 			reg = <0 0x11234000 0 0xe0>;
-- 
2.6.4

From david at redhat.com  Fri Apr  9 09:09:51 2021
From: david at redhat.com (David Hildenbrand)
Date: Fri, 9 Apr 2021 10:09:51 +0200
Subject: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from
 aspeed or etnaviv
In-Reply-To: <CAK8P3a3sqZBo8-zye1yiZuD2uMUr0oE_q_QfaK9K54TEgd1Cdw@mail.gmail.com>
References: <20210408092011.52763-1-david@redhat.com>
 <20210408092011.52763-3-david@redhat.com>
 <CAK8P3a09LdJ-87ZrN28y=t8Sa0zL-3NOvEWhkStMY+2EbO7UAw@mail.gmail.com>
 <cd14d4b4-da82-b21c-2cd6-8e474d97b955@redhat.com>
 <CAK8P3a0Wg1mGZoBkD_RwMx-jzQNK2krrDxDQV5uhCHoyz-e=dw@mail.gmail.com>
 <7496ac87-9676-1b4e-3444-c2a662ec376b@redhat.com>
 <CAK8P3a1tVwkDbtvKi8atkrg1-CfoQHGrXLCzn_uo+=dfZJfdQA@mail.gmail.com>
 <3a2d64a7-8425-8daf-17ee-95b9f0c635f9@redhat.com>
 <CACRpkdYizKGhtYzE+22oZAduLNCOGP9Vbp=LQbXG1C-a+MyMcg@mail.gmail.com>
 <2ef3b65c-c0ef-7bbe-0e05-39ee8f2bae48@redhat.com>
 <CAK8P3a3sqZBo8-zye1yiZuD2uMUr0oE_q_QfaK9K54TEgd1Cdw@mail.gmail.com>
Message-ID: <b78f2ec2-3c47-f435-6d5e-fb7330ff3907@redhat.com>

On 08.04.21 22:29, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david at redhat.com> wrote:
>> On 08.04.21 14:49, Linus Walleij wrote:
>>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david at redhat.com> wrote:
>>>
>>>>> This is something you could do using a hidden helper symbol like
>>>>>
>>>>> config DRMA_ASPEED_GFX
>>>>>           bool "Aspeed display driver"
>>>>>           select DRM_WANT_CMA
>>>>>
>>>>> config DRM_WANT_CMA
>>>>>           bool
>>>>>           help
>>>>>              Select this from any driver that benefits from CMA being enabled
>>>>>
>>>>> config DMA_CMA
>>>>>           bool "Use CMA helpers for DRM"
>>>>>           default DRM_WANT_CMA
>>>>>
>>>>>             Arnd
>>>>>
>>>>
>>>> That's precisely what I had first, with an additional "WANT_CMA" --  but
>>>> looking at the number of such existing options (I was able to spot 1 !)
>>>
>>> If you do this it probably makes sense to fix a few other drivers
>>> Kconfig in the process. It's not just a problem with your driver.
>>> "my" drivers:
>>>
>>
>> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
>> into recursive dependencies ...
>>
>>> drivers/gpu/drm/mcde/Kconfig
>>> drivers/gpu/drm/pl111/Kconfig
>>> drivers/gpu/drm/tve200/Kconfig
> 
> Right, this is the main problem caused by using 'select' to
> force-enable symbols that other drivers depend on.
> 
> Usually, the answer is to be consistent about the use of 'select'
> and 'depends on', using the former only to enable symbols that
> are hidden, while using 'depends on' for anything that is an
> actual build time dependency.
> 
>> I was assuming these are "real" dependencies. Will it also work without
>> DMA_CMA?
> 
> I think in this case, it is fairly likely to work without DMA_CMA when the
> probe function gets called during a fresh boot, but fairly likely to fail if
> it gets called after the system has run for long enough to fragment the
> free memory.
> 
> The point of DMA_CMA is to make it work reliably.

Right, and even at runtime there is no guarantee that DMA_CMA will do 
anything -- especially if we don't reserve a CMA region (e.g., "cma=X").

So this really sounds like a

"desires DMA_CMA"

and achieving that via an additional symbol or via "default y if ..." 
for DMA_CMA sounds reasonable.

Thanks!

-- 
Thanks,

David / dhildenb



From daniel.lezcano at linaro.org  Fri Apr  9 09:09:59 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 9 Apr 2021 10:09:59 +0200
Subject: [v7,1/3] arm64: dts: mt8183: add thermal zone node
In-Reply-To: <20210316070144.28440-2-michael.kao@mediatek.com>
References: <20210316070144.28440-1-michael.kao@mediatek.com>
 <20210316070144.28440-2-michael.kao@mediatek.com>
Message-ID: <f7003979-0210-882e-bb28-f24047e18061@linaro.org>

On 16/03/2021 08:01, Michael Kao wrote:
> From: "michael.kao" <michael.kao at mediatek.com>
> 
> Add thermal zone node to Mediatek MT8183 dts file.
> 
> Evaluate the thermal zone every 500ms while not cooling
> and every 100ms when passive cooling is performed.
> 
> Signed-off-by: Matthias Kaehlcke <mka at chromium.org>
> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 85 ++++++++++++++++++++++++
>  1 file changed, 85 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7..d3550af06408 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -657,6 +657,87 @@
>  			status = "disabled";
>  		};
>  
> +		thermal: thermal at 1100b000 {
> +			#thermal-sensor-cells = <1>;
> +			compatible = "mediatek,mt8183-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			clocks = <&infracfg CLK_INFRA_THERM>,
> +				 <&infracfg CLK_INFRA_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&infracfg  MT8183_INFRACFG_AO_THERM_SW_RST>;
> +			interrupts = <0 76 IRQ_TYPE_LEVEL_LOW>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +			nvmem-cells = <&thermal_calibration>;
> +			nvmem-cell-names = "calibration-data";
> +		};
> +
> +		thermal-zones {
> +			cpu_thermal: cpu_thermal {
> +				polling-delay-passive = <100>;
> +				polling-delay = <500>;
> +				thermal-sensors = <&thermal 0>;
> +				sustainable-power = <5000>;
> +			};
> +
> +			/* The tzts1 ~ tzts6 don't need to polling */
> +			/* The tzts1 ~ tzts6 don't need to thermal throttle */
> +
> +			tzts1: tzts1 {
> +				polling-delay-passive = <0>;
> +				polling-delay = <0>;
> +				thermal-sensors = <&thermal 1>;
> +				sustainable-power = <5000>;
> +				trips {};
> +				cooling-maps {};
> +			};

What is the point of defining the sustainable power with no cooling
device associated ?



-- 
<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 Fengquan.Chen at mediatek.com  Fri Apr  9 09:36:06 2021
From: Fengquan.Chen at mediatek.com (Fengquan Chen)
Date: Fri, 9 Apr 2021 16:36:06 +0800
Subject: [PATCH] [v3,
 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq clear
 flow on shutdown
Message-ID: <1617957367-479-1-git-send-email-Fengquan.Chen@mediatek.com>

mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
clear any pending systimer irq when shutdown to avoid suspend aborted
due to timer irq pending

Also as for systimer in mediatek socs, there must be firstly enable
timer before clear systimer irq

Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer")
Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>

Fengquan Chen (1):
  [v3, 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq
    clear flow on shutdown

 drivers/clocksource/timer-mediatek.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
1.8.1.1.dirty

From colin.king at canonical.com  Fri Apr  9 09:42:14 2021
From: colin.king at canonical.com (Colin Ian King)
Date: Fri, 9 Apr 2021 09:42:14 +0100
Subject: [PATCH] clk: uniphier: Fix potential infinite loop
In-Reply-To: <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>
References: <20210407152457.497346-1-colin.king@canonical.com>
 <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>
Message-ID: <fa2328c5-e082-0bb7-0e87-741a4c698123@canonical.com>

On 09/04/2021 07:46, Masahiro Yamada wrote:
> On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king at canonical.com> wrote:
>>
>> From: Colin Ian King <colin.king at canonical.com>
>>
>> The for-loop iterates with a u8 loop counter i and compares this
>> with the loop upper limit of num_parents that is an int type.
>> There is a potential infinite loop if num_parents is larger than
>> the u8 loop counter. Fix this by making the loop counter the same
>> type as num_parents.
>>
>> Addresses-Coverity: ("Infinite loop")
>> Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
>> Signed-off-by: Colin Ian King <colin.king at canonical.com>
>> ---
>>  drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
>> index 462c84321b2d..ce219e0d2a85 100644
>> --- a/drivers/clk/uniphier/clk-uniphier-mux.c
>> +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
>> @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
>>         int num_parents = clk_hw_get_num_parents(hw);
>>         int ret;
>>         unsigned int val;
>> -       u8 i;
>> +       int i;
>>
>>         ret = regmap_read(mux->regmap, mux->reg, &val);
>>         if (ret)
>> --
>> 2.30.2
>>
> 
> clk_hw_get_num_parents() returns 'unsigned int', so
> I think 'num_parents' should also have been 'unsigned int'.
> 
> Maybe, the loop counter 'i' also should be 'unsigned int' then?
> 
> 
Good point. I'll send a V2.


From narmstrong at baylibre.com  Fri Apr  9 09:43:08 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri,  9 Apr 2021 10:43:08 +0200
Subject: [PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167
Message-ID: <20210409084308.481185-1-narmstrong@baylibre.com>

On MT8167, only CEA modes and anything using a clock below 148500 is
supported for HDMI. This change adds some checks to make sure the
video format is OK for MT8167.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..991e2e935b93 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,8 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
 	bool tz_disabled;
+	unsigned long max_mode_clock;
+	bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
 			return MODE_BAD;
 	}
 
+	if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+		return MODE_BAD;
+
+	if (hdmi->conf->max_mode_clock &&
+	    mode->clock > hdmi->conf->max_mode_clock)
+		return MODE_CLOCK_HIGH;
+
 	if (mode->clock < 27000)
 		return MODE_CLOCK_LOW;
 	if (mode->clock > 297000)
@@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
 	.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+	.max_mode_clock = 148500,
+	.cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
 	{ .compatible = "mediatek,mt2701-hdmi",
 	  .data = &mtk_hdmi_conf_mt2701,
 	},
+	{ .compatible = "mediatek,mt8167-hdmi",
+	  .data = &mtk_hdmi_conf_mt8167,
+	},
 	{ .compatible = "mediatek,mt8173-hdmi",
 	},
 	{}
-- 
2.25.1



From chunfeng.yun at mediatek.com  Fri Apr  9 09:43:19 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 16:43:19 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <CAATdQgCQ5Gm1CNEbVgLFiFcgDX0yP5G=48Fa29WYbpSuz25WXg@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAATdQgCQ5Gm1CNEbVgLFiFcgDX0yP5G=48Fa29WYbpSuz25WXg@mail.gmail.com>
Message-ID: <1617957799.12105.31.camel@mhfsdcap03>

On Fri, 2021-04-09 at 13:32 +0800, Ikjoon Jang wrote:
> Hi Chunfeng,
> 
> On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > When the dedicated wake irq is level trigger, enable it before
> > calling runtime_suspend, will trigger an interrupt.
> >
> > e.g.
> > for a low level trigger type, it's low level at running time (0),
> > and becomes high level when enters suspend (runtime_suspend (1) is
> > called), a wakeup signal at (2) make it become low level, wake irq
> > will be triggered.
> >
> >                 ------------------
> >                |           ^     ^|
> > ----------------           |     | --------------
> >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> >
> 
> Can't we just use a falling edge type for this irq line?
I'll try it, but the original code still doesn't process above mentioned
case.

> 
> > if we enable the wake irq before calling runtime_suspend during (0),
> > an interrupt will arise, it causes resume immediately;
> > enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
> > will works.
> >
> > This patch seems no side effect on edge trigger wake irq.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> >  drivers/base/power/runtime.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index a46a7e30881b..796739a015a5 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> >         __update_runtime_status(dev, RPM_SUSPENDING);
> >
> >         callback = RPM_GET_CALLBACK(dev, runtime_suspend);
> > -
> > -       dev_pm_enable_wake_irq_check(dev, true);
> >         retval = rpm_callback(callback, dev);
> >         if (retval)
> >                 goto fail;
> >
> > +       dev_pm_enable_wake_irq_check(dev, true);
> > +
> >   no_callback:
> >         __update_runtime_status(dev, RPM_SUSPENDED);
> >         pm_runtime_deactivate_timer(dev);
> > @@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> >         return retval;
> >
> >   fail:
> > -       dev_pm_disable_wake_irq_check(dev);
> >         __update_runtime_status(dev, RPM_ACTIVE);
> >         dev->power.deferred_resume = false;
> >         wake_up_all(&dev->power.wait_queue);
> > --
> > 2.18.0
> >


From chunfeng.yun at mediatek.com  Fri Apr  9 09:36:02 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 16:36:02 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <YG/ohhh3Tyet6InQ@atomide.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
 <1617933211.12105.22.camel@mhfsdcap03> <YG/ohhh3Tyet6InQ@atomide.com>
Message-ID: <1617957362.12105.27.camel@mhfsdcap03>

On Fri, 2021-04-09 at 08:39 +0300, Tony Lindgren wrote:
> * Chunfeng Yun <chunfeng.yun at mediatek.com> [210409 01:54]:
> > On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote:
> > > On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > > >
> > > > When the dedicated wake irq is level trigger, enable it before
> > > > calling runtime_suspend, will trigger an interrupt.
> > > >
> > > > e.g.
> > > > for a low level trigger type, it's low level at running time (0),
> > > > and becomes high level when enters suspend (runtime_suspend (1) is
> > > > called), a wakeup signal at (2) make it become low level, wake irq
> > > > will be triggered.
> > > >
> > > >                 ------------------
> > > >                |           ^     ^|
> > > > ----------------           |     | --------------
> > > >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> > > >
> > > > if we enable the wake irq before calling runtime_suspend during (0),
> > > > an interrupt will arise, it causes resume immediately;
> > > 
> > > But that's necessary to avoid missing a wakeup interrupt, isn't it?
> > That's also what I worry about.
> 
> Yeah sounds like this patch will lead into missed wakeirqs.
If miss level trigger wakeirqs, that means HW doesn't latch it? is it HW
limitation?
> 
> Regards,
> 
> Tony


From Fengquan.Chen at mediatek.com  Fri Apr  9 09:36:07 2021
From: Fengquan.Chen at mediatek.com (Fengquan Chen)
Date: Fri, 9 Apr 2021 16:36:07 +0800
Subject: [PATCH] [v3,
 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq clear
 flow on shutdown
In-Reply-To: <1617957367-479-1-git-send-email-Fengquan.Chen@mediatek.com>
References: <1617957367-479-1-git-send-email-Fengquan.Chen@mediatek.com>
Message-ID: <1617957367-479-2-git-send-email-Fengquan.Chen@mediatek.com>

mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
clear any pending systimer irq when shutdown to avoid suspend aborted
due to timer irq pending

Also as for systimer in mediatek socs, there must be firstly enable
timer before clear systimer irq

Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for
		system timer")
Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>

Change-Id: I1cd408cef4af4c5d7965eab27eda305ee4356315
---
 drivers/clocksource/timer-mediatek.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 9318edc..6461fd3 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -60,9 +60,9 @@
  * SYST_CON_EN: Clock enable. Shall be set to
  *   - Start timer countdown.
  *   - Allow timeout ticks being updated.
- *   - Allow changing interrupt functions.
+ *   - Allow changing interrupt status,like clear irq pending.
  *
- * SYST_CON_IRQ_EN: Set to allow interrupt.
+ * SYST_CON_IRQ_EN: Set to enable interrupt.
  *
  * SYST_CON_IRQ_CLR: Set to clear interrupt.
  */
@@ -75,6 +75,7 @@
 static void mtk_syst_ack_irq(struct timer_of *to)
 {
 	/* Clear and disable interrupt */
+	writel(SYST_CON_EN, SYST_CON_REG(to));
 	writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
 }
 
@@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
 
 static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
 {
+	/* Clear any irq */
+	mtk_syst_ack_irq(to_timer_of(clkevt));
+
 	/* Disable timer */
 	writel(0, SYST_CON_REG(to_timer_of(clkevt)));
 
-- 
1.8.1.1.dirty

From zweiss at equinix.com  Fri Apr  9 09:46:38 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 08:46:38 +0000
Subject: [PATCH v2 17/21] dt-bindings: ipmi: Convert ASPEED KCS binding to
 schema
In-Reply-To: <YG/ppKEAs5EBUao3@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-17-andrew@aj.id.au> <YG/i9lSxxCMIzkRs@packtop>
 <29937129-3a17-4a32-a723-191b693a1e0c@www.fastmail.com>
 <YG/ppKEAs5EBUao3@packtop>
Message-ID: <YHAUbTeoxRFBUjMi@packtop>

On Fri, Apr 09, 2021 at 12:44:04AM CDT, Zev Weiss wrote:
>On Fri, Apr 09, 2021 at 12:33:10AM CDT, Andrew Jeffery wrote:
>>
>>
>>On Fri, 9 Apr 2021, at 14:45, Zev Weiss wrote:
>>>On Fri, Mar 19, 2021 at 01:27:48AM CDT, Andrew Jeffery wrote:
>>>>Given the deprecated binding, improve the ability to detect issues in
>>>>the platform devicetrees. Further, a subsequent patch will introduce a
>>>>new interrupts property for specifying SerIRQ behaviour, so convert
>>>>before we do any further additions.
>>>>
>>>>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>>>>---
>>>> .../bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml | 92 +++++++++++++++++++
>>>> .../bindings/ipmi/aspeed-kcs-bmc.txt          | 33 -------
>>>> 2 files changed, 92 insertions(+), 33 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>>>> delete mode 100644 Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt
>>>>
>>>>diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>>>>new file mode 100644
>>>>index 000000000000..697ca575454f
>>>>--- /dev/null
>>>>+++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml
>>>>@@ -0,0 +1,92 @@
>>>>+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>+%YAML 1.2
>>>>+---
>>>>+$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml
>>>>+$schema: http://devicetree.org/meta-schemas/core.yaml
>>>>+
>>>>+title: ASPEED BMC KCS Devices
>>>>+
>>>>+maintainers:
>>>>+  - Andrew Jeffery <andrew at aj.id.au>
>>>>+
>>>>+description: |
>>>>+  The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS)
>>>>+  interfaces on the LPC bus for in-band IPMI communication with their host.
>>>>+
>>>>+properties:
>>>>+  compatible:
>>>>+    oneOf:
>>>>+      - description: Channel ID derived from reg
>>>>+        items:
>>>>+          enum:
>>>>+            - aspeed,ast2400-kcs-bmc-v2
>>>>+            - aspeed,ast2500-kcs-bmc-v2
>>>>+            - aspeed,ast2600-kcs-bmc
>>>
>>>Should this have a "-v2" suffix?
>>
>>Well, that was kind of a matter of perspective. The 2600 compatible was
>>added after we'd done the v2 of the binding for the 2400 and 2500 so it
>>never needed correcting. But it is a case of "don't use the deprecated
>>properties with the 2600 compatible".
>>
>>I don't think a change is necessary?
>>
>
>It just looked inconsistent with the corresponding string in the
>ast_kcs_bmc_match[] table; perhaps that should be changed instead then?
>

...except I realize now I only saw the 2600 v2 string in the match table
because I put it there myself in the process of resolving a conflict
when applying your series to the openbmc dev-5.10 branch for testing
purposes.  So nevermind on this.

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From andrew at aj.id.au  Fri Apr  9 09:51:29 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Fri, 09 Apr 2021 18:21:29 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?=
 =?UTF-8?Q?vice_interface?=
In-Reply-To: <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
Message-ID: <f0029c4c-6bf9-49a1-ac94-b718eab01d14@beta.fastmail.com>

Hi Arnd,

On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> >
> > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > provide a means to generate IRQs and exchange arbitrary data between a
> > BMC and its host system.
> 
> I only noticed the series after Joel asked about the DT changes on the arm
> side. One question though:
> 
> How does this related to the drivers/input/serio/ framework that also talks
> to the keyboard controller for things that are not keyboards? Are these
> separate communication channels on adjacent I/O ports, or does there
> need to be some arbitration?

Good questions! I'll look into serio and get back to you.

Andrew


From rmfrfs at gmail.com  Fri Apr  9 09:53:17 2021
From: rmfrfs at gmail.com (Rui Miguel Silva)
Date: Fri, 9 Apr 2021 09:53:17 +0100
Subject: [PATCH] [v2] media: imx: imx7-mipi-csis: Fix runtime PM
 imbalance in mipi_csis_s_stream
In-Reply-To: <20210409082225.22461-1-dinghao.liu@zju.edu.cn>
References: <20210409082225.22461-1-dinghao.liu@zju.edu.cn>
Message-ID: <20210409085317.ycj273fqwbmowfqb@arch-thunder.localdomain>

Hi Liu,
Many thanks for the patch.

On Fri, Apr 09, 2021 at 04:22:25PM +0800, Dinghao Liu wrote:
> When v4l2_subdev_call() fails, a pairing PM usage counter
> decrement is needed to keep the counter balanced. It's the
> same for the following error paths in case 'enable' is on.
> 
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>

LGTM
Reviewed-by: Rui Miguel Silva <rmfrfs at gmail.com>

------
Cheers,
     Rui
> ---
> 
> Changelog:
> 
> v2: - Use pm_runtime_put() to balance the refcount.
> ---
>  drivers/staging/media/imx/imx7-mipi-csis.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> index a01a7364b4b9..6f3e8a15e7c4 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -628,7 +628,7 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
>  		}
>  		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
>  		if (ret < 0)
> -			return ret;
> +			goto pm_put;
>  	}
>  
>  	mutex_lock(&state->lock);
> @@ -657,7 +657,8 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
>  
>  unlock:
>  	mutex_unlock(&state->lock);
> -	if (!enable)
> +pm_put:
> +	if (!enable || (ret < 0))
>  		pm_runtime_put(&state->pdev->dev);
>  
>  	return ret;
> -- 
> 2.17.1
> 
> 


From chunfeng.yun at mediatek.com  Fri Apr  9 09:54:01 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 9 Apr 2021 16:54:01 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <CAATdQgArnkdmbZefF4h7xp6=j-wHLgdQs1K0cDv06sP4eVdHmw@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
 <CAATdQgArnkdmbZefF4h7xp6=j-wHLgdQs1K0cDv06sP4eVdHmw@mail.gmail.com>
Message-ID: <1617958441.12105.39.camel@mhfsdcap03>

On Fri, 2021-04-09 at 13:45 +0800, Ikjoon Jang wrote:
> On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > A dedicated wakeup irq will be used to handle runtime suspend/resume,
> > we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> > and attaching wakeup irq, then the suspend/resume framework will help
> > to enable/disable wakeup irq.
> >
> > The runtime PM is default off since some platforms may not support it.
> > users can enable it via power/control (set "auto") in sysfs.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > ---
> >  drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
> >  1 file changed, 124 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index a74764ab914a..30927f4064d4 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -16,6 +16,7 @@
> >  #include <linux/of.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/pm_runtime.h>
> > +#include <linux/pm_wakeirq.h>
> >  #include <linux/regmap.h>
> >  #include <linux/regulator/consumer.h>
> >
> > @@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
> >                         mtk->uwk_reg_base, mtk->uwk_vers);
> >
> >         return PTR_ERR_OR_ZERO(mtk->uwk);
> > -
> >  }
> >
> >  static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
> > @@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >         struct resource *res;
> >         struct usb_hcd *hcd;
> >         int ret = -ENODEV;
> > +       int wakeup_irq;
> >         int irq;
> >
> >         if (usb_disabled())
> > @@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >         if (ret)
> >                 return ret;
> >
> > +       irq = platform_get_irq_byname_optional(pdev, "host");
> > +       if (irq < 0) {
> > +               if (irq == -EPROBE_DEFER)
> > +                       return irq;
> > +
> > +               /* for backward compatibility */
> > +               irq = platform_get_irq(pdev, 0);
> > +               if (irq < 0)
> > +                       return irq;
> > +       }
> > +
> > +       wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
> > +       if (wakeup_irq == -EPROBE_DEFER)
> > +               return wakeup_irq;
> > +
> >         mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
> >         /* optional property, ignore the error if it does not exist */
> >         of_property_read_u32(node, "mediatek,u3p-dis-msk",
> > @@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >                 return ret;
> >         }
> >
> > +       pm_runtime_set_active(dev);
> > +       pm_runtime_use_autosuspend(dev);
> > +       pm_runtime_set_autosuspend_delay(dev, 4000);
> >         pm_runtime_enable(dev);
> >         pm_runtime_get_sync(dev);
> > -       device_enable_async_suspend(dev);
> >
> >         ret = xhci_mtk_ldos_enable(mtk);
> >         if (ret)
> > @@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >         if (ret)
> >                 goto disable_ldos;
> >
> > -       irq = platform_get_irq(pdev, 0);
> > -       if (irq < 0) {
> > -               ret = irq;
> > -               goto disable_clk;
> > -       }
> > -
> >         hcd = usb_create_hcd(driver, dev, dev_name(dev));
> >         if (!hcd) {
> >                 ret = -ENOMEM;
> > @@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >         if (ret)
> >                 goto dealloc_usb2_hcd;
> >
> > +       if (wakeup_irq > 0) {
> > +               ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
> > +               if (ret) {
> > +                       dev_err(dev, "set wakeup irq %d failed\n", wakeup_irq);
> > +                       goto dealloc_usb3_hcd;
> > +               }
> > +               dev_info(dev, "wakeup irq %d\n", wakeup_irq);
> > +       }
> > +
> > +       device_enable_async_suspend(dev);
> > +       pm_runtime_mark_last_busy(dev);
> > +       pm_runtime_put_autosuspend(dev);
> > +       pm_runtime_forbid(dev);
> > +
> >         return 0;
> >
> > +dealloc_usb3_hcd:
> > +       usb_remove_hcd(xhci->shared_hcd);
> > +       xhci->shared_hcd = NULL;
> > +
> >  dealloc_usb2_hcd:
> >         usb_remove_hcd(hcd);
> >
> > @@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> >         xhci_mtk_ldos_disable(mtk);
> >
> >  disable_pm:
> > -       pm_runtime_put_sync(dev);
> > +       pm_runtime_put_sync_autosuspend(dev);
> >         pm_runtime_disable(dev);
> >         return ret;
> >  }
> >
> > -static int xhci_mtk_remove(struct platform_device *dev)
> > +static int xhci_mtk_remove(struct platform_device *pdev)
> >  {
> > -       struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
> > +       struct xhci_hcd_mtk *mtk = platform_get_drvdata(pdev);
> >         struct usb_hcd  *hcd = mtk->hcd;
> >         struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >         struct usb_hcd  *shared_hcd = xhci->shared_hcd;
> > +       struct device *dev = &pdev->dev;
> >
> > -       pm_runtime_put_noidle(&dev->dev);
> > -       pm_runtime_disable(&dev->dev);
> > +       pm_runtime_get_sync(dev);
> > +       xhci->xhc_state |= XHCI_STATE_REMOVING;
> > +       dev_pm_clear_wake_irq(dev);
> > +       device_init_wakeup(dev, false);
> >
> >         usb_remove_hcd(shared_hcd);
> >         xhci->shared_hcd = NULL;
> > -       device_init_wakeup(&dev->dev, false);
> > -
> >         usb_remove_hcd(hcd);
> >         usb_put_hcd(shared_hcd);
> >         usb_put_hcd(hcd);
> > @@ -627,6 +658,10 @@ static int xhci_mtk_remove(struct platform_device *dev)
> >         xhci_mtk_clks_disable(mtk);
> >         xhci_mtk_ldos_disable(mtk);
> >
> > +       pm_runtime_disable(dev);
> > +       pm_runtime_put_noidle(dev);
> > +       pm_runtime_set_suspended(dev);
> > +
> >         return 0;
> >  }
> >
> > @@ -690,10 +725,83 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
> >         return ret;
> >  }
> >
> > +static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
> > +{
> > +       u32 suspended_ports;
> > +       u32 status;
> > +       int num_ports;
> > +       int i;
> > +
> > +       num_ports = rhub->num_ports;
> > +       suspended_ports = rhub->bus_state.suspended_ports;
> > +       for (i = 0; i < num_ports; i++) {
> > +               if (!(suspended_ports & BIT(i))) {
> > +                       status = readl(rhub->ports[i]->addr);
> > +                       if (status & PORT_CONNECT)
> 
> So this pm_runtime support is activated only when there's no devices
> connected at all?
No, if the connected devices also support runtime suspend, it will enter
suspend mode when no data transfer, then the controller can enter
suspend too
> I think this will always return -EBUSY with my board having an on-board hub
> connected to both rhubs.
the on-board hub supports runtime suspend by default, so if no devices
connected, it will enter suspend

> 
> > +                               return -EBUSY;
> > +               }
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +/*
> > + * check the bus whether it could suspend or not
> > + * the bus will suspend if the downstream ports are already suspended,
> > + * or no devices connected.
> > + */
> > +static int check_bus_status(struct xhci_hcd *xhci)
> > +{
> > +       int ret;
> > +
> > +       ret = check_rhub_status(xhci, &xhci->usb3_rhub);
> > +       if (ret)
> > +               return ret;
> > +
> > +       return check_rhub_status(xhci, &xhci->usb2_rhub);
> > +}
> > +
> > +static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
> > +{
> > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > +       int ret = 0;
> > +
> > +       if (xhci->xhc_state)
> > +               return -ESHUTDOWN;
> > +
> > +       if (device_may_wakeup(dev)) {
> > +               ret = check_bus_status(xhci);
> > +               if (!ret)
> > +                       ret = xhci_mtk_suspend(dev);
> > +       }
> > +
> > +       /* -EBUSY: let PM automatically reschedule another autosuspend */
> > +       return ret ? -EBUSY : 0;
> > +}
> > +
> > +static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
> > +{
> > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > +       int ret = 0;
> > +
> > +       if (xhci->xhc_state)
> > +               return -ESHUTDOWN;
> > +
> > +       if (device_may_wakeup(dev))
> > +               ret = xhci_mtk_resume(dev);
> > +
> > +       return ret;
> > +}
> > +
> >  static const struct dev_pm_ops xhci_mtk_pm_ops = {
> >         SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
> > +       SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
> > +                          xhci_mtk_runtime_resume, NULL)
> >  };
> > -#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
> > +
> > +#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
> >
> >  static const struct of_device_id mtk_xhci_of_match[] = {
> >         { .compatible = "mediatek,mt8173-xhci"},
> > --
> > 2.18.0
> >


From lkp at intel.com  Fri Apr  9 09:53:28 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:28 +0800
Subject: [soc:omap/soc] BUILD SUCCESS 206fa766ca2151d728a0894bdb03688d48564aa0
Message-ID: <60701608./0t5lpfq9iDQWqnc%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git omap/soc
branch HEAD: 206fa766ca2151d728a0894bdb03688d48564aa0  ARM: OMAP1: fix incorrect kernel-doc comment syntax in file

elapsed time: 13065m

configs tested: 160
configs skipped: 118

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
nios2                         3c120_defconfig
xtensa                    xip_kc705_defconfig
openrisc                            defconfig
mips                           rs90_defconfig
arm                         s3c2410_defconfig
powerpc                 mpc836x_rdk_defconfig
xtensa                         virt_defconfig
sh                            titan_defconfig
arm                        mini2440_defconfig
powerpc                    amigaone_defconfig
x86_64                           alldefconfig
sparc64                             defconfig
sh                          sdk7780_defconfig
m68k                          amiga_defconfig
sh                               j2_defconfig
arm                        magician_defconfig
arm                          exynos_defconfig
h8300                               defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
nds32                               defconfig
powerpc                     rainier_defconfig
sh                           se7780_defconfig
mips                        workpad_defconfig
sh                           se7722_defconfig
arm                         lpc32xx_defconfig
xtensa                       common_defconfig
sh                        sh7757lcr_defconfig
arm                     am200epdkit_defconfig
sh                           se7343_defconfig
ia64                            zx1_defconfig
mips                         cobalt_defconfig
nios2                               defconfig
powerpc                     pq2fads_defconfig
powerpc                      obs600_defconfig
mips                        bcm47xx_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                      ppc44x_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                    vt8500_v6_v7_defconfig
powerpc                 mpc8272_ads_defconfig
powerpc                       eiger_defconfig
arm                        multi_v5_defconfig
arm                       spear13xx_defconfig
mips                         rt305x_defconfig
arm                            xcep_defconfig
riscv                               defconfig
sh                  sh7785lcr_32bit_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                             allnoconfig
csky                                defconfig
alpha                               defconfig
nios2                            allyesconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
arc                              allyesconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210330
x86_64               randconfig-a003-20210330
x86_64               randconfig-a002-20210330
x86_64               randconfig-a001-20210330
x86_64               randconfig-a005-20210330
x86_64               randconfig-a006-20210330
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
i386                 randconfig-a004-20210330
i386                 randconfig-a006-20210330
i386                 randconfig-a003-20210330
i386                 randconfig-a002-20210330
i386                 randconfig-a001-20210330
i386                 randconfig-a005-20210330
i386                 randconfig-a006-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a015-20210330
i386                 randconfig-a011-20210330
i386                 randconfig-a014-20210330
i386                 randconfig-a013-20210330
i386                 randconfig-a016-20210330
i386                 randconfig-a012-20210330
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a012-20210330
x86_64               randconfig-a015-20210330
x86_64               randconfig-a014-20210330
x86_64               randconfig-a016-20210330
x86_64               randconfig-a013-20210330
x86_64               randconfig-a011-20210330
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a004-20210331
x86_64               randconfig-a003-20210331
x86_64               randconfig-a002-20210331
x86_64               randconfig-a001-20210331
x86_64               randconfig-a005-20210331
x86_64               randconfig-a006-20210331

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:30 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:30 +0800
Subject: [soc:mvebu/dt] BUILD SUCCESS c6dfc019c239c76c179ebbccbac27170ba1e3bb6
Message-ID: <6070160a.vARNa6yz2os5qQvr%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mvebu/dt
branch HEAD: c6dfc019c239c76c179ebbccbac27170ba1e3bb6  ARM: dts: mvebu: Add device tree for ATL-x530 Board

elapsed time: 728m

configs tested: 93
configs skipped: 80

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
i386                             allyesconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
arc                     nsimosci_hs_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
ia64                                defconfig
m68k                                defconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
arc                                 defconfig
parisc                              defconfig
s390                                defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
arc                              allyesconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:38 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:38 +0800
Subject: [soc:arm/apple-m1] BUILD SUCCESS
 1bb2fd3880d479a7a1bf833baee731ae69f09060
Message-ID: <60701612.pNTgp6y7yrjbx9Rq%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/apple-m1
branch HEAD: 1bb2fd3880d479a7a1bf833baee731ae69f09060  Merge tag 'm1-soc-bringup-v5' of https://github.com/AsahiLinux/linux into arm/apple-m1

elapsed time: 729m

configs tested: 70
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
m68k                          hp300_defconfig
sh                          polaris_defconfig
arm                          gemini_defconfig
sparc                               defconfig
arm                        spear3xx_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:25 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:25 +0800
Subject: [soc:hisilicon/soc] BUILD SUCCESS
 c1ce9d8081a9fca5fd1b2e48bcc20e5dc3387302
Message-ID: <60701605.gu+WV20HdUyWmQ/H%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git hisilicon/soc
branch HEAD: c1ce9d8081a9fca5fd1b2e48bcc20e5dc3387302  ARM: hisi: use the correct HiSilicon copyright

elapsed time: 10054m

configs tested: 247
configs skipped: 115

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          rsk7203_defconfig
arc                    vdk_hs38_smp_defconfig
mips                       rbtx49xx_defconfig
arm                           h5000_defconfig
powerpc                     powernv_defconfig
mips                      malta_kvm_defconfig
m68k                        mvme16x_defconfig
powerpc                      ppc40x_defconfig
mips                         tb0226_defconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
xtensa                generic_kc705_defconfig
arm                      footbridge_defconfig
arm                        trizeps4_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
alpha                            alldefconfig
arm                           sama5_defconfig
sh                         apsh4a3a_defconfig
arm                           omap1_defconfig
mips                          rm200_defconfig
parisc                generic-64bit_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
mips                      fuloong2e_defconfig
powerpc                     sequoia_defconfig
arm                          ixp4xx_defconfig
arm                          pxa910_defconfig
arm                          lpd270_defconfig
mips                     cu1830-neo_defconfig
mips                     cu1000-neo_defconfig
mips                             allmodconfig
mips                      pistachio_defconfig
riscv                          rv32_defconfig
powerpc                 mpc836x_mds_defconfig
powerpc                     redwood_defconfig
parisc                generic-32bit_defconfig
mips                            gpr_defconfig
powerpc                     tqm8540_defconfig
sh                     magicpanelr2_defconfig
ia64                             allmodconfig
m68k                       bvme6000_defconfig
arm                       spear13xx_defconfig
s390                                defconfig
powerpc                      makalu_defconfig
openrisc                    or1ksim_defconfig
arm                             pxa_defconfig
mips                        workpad_defconfig
nios2                         10m50_defconfig
arm                          iop32x_defconfig
ia64                             alldefconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
h8300                            alldefconfig
arc                     nsimosci_hs_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8540_ads_defconfig
arc                        nsim_700_defconfig
arm                         lpc32xx_defconfig
powerpc                     tqm8560_defconfig
powerpc                      tqm8xx_defconfig
mips                           ip27_defconfig
arm                        cerfcube_defconfig
m68k                           sun3_defconfig
powerpc                     ksi8560_defconfig
powerpc                     tqm5200_defconfig
powerpc                      katmai_defconfig
m68k                        mvme147_defconfig
sh                           sh2007_defconfig
mips                   sb1250_swarm_defconfig
arm                        shmobile_defconfig
m68k                         apollo_defconfig
xtensa                          iss_defconfig
sh                          rsk7201_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm                     am200epdkit_defconfig
h8300                    h8300h-sim_defconfig
sh                          lboxre2_defconfig
powerpc                    amigaone_defconfig
sh                           se7724_defconfig
powerpc                         wii_defconfig
arm                       multi_v4t_defconfig
sh                        sh7785lcr_defconfig
mips                        qi_lb60_defconfig
arm                           tegra_defconfig
mips                        vocore2_defconfig
powerpc                 mpc8315_rdb_defconfig
arm                             rpc_defconfig
sparc64                             defconfig
powerpc                 mpc834x_mds_defconfig
arm                            zeus_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
powerpc                       eiger_defconfig
ia64                         bigsur_defconfig
xtensa                       common_defconfig
mips                           gcw0_defconfig
mips                        omega2p_defconfig
arm                         palmz72_defconfig
arm                          pxa168_defconfig
sh                           se7780_defconfig
arc                 nsimosci_hs_smp_defconfig
sh                ecovec24-romimage_defconfig
powerpc                   lite5200b_defconfig
arm                         s5pv210_defconfig
arm                          imote2_defconfig
mips                         tb0219_defconfig
mips                malta_qemu_32r6_defconfig
arm                           corgi_defconfig
m68k                       m5208evb_defconfig
mips                       capcella_defconfig
arm                          exynos_defconfig
powerpc                 mpc837x_rdb_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
mips                           ci20_defconfig
powerpc                  iss476-smp_defconfig
sh                           se7750_defconfig
riscv                    nommu_k210_defconfig
arm                         lpc18xx_defconfig
arm                          moxart_defconfig
s390                             allyesconfig
sh                             sh03_defconfig
sh                           se7712_defconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                             allnoconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a004-20210402
x86_64               randconfig-a005-20210402
x86_64               randconfig-a003-20210402
x86_64               randconfig-a001-20210402
x86_64               randconfig-a002-20210402
x86_64               randconfig-a006-20210402
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a006-20210402
i386                 randconfig-a003-20210402
i386                 randconfig-a001-20210402
i386                 randconfig-a004-20210402
i386                 randconfig-a005-20210402
i386                 randconfig-a002-20210402
i386                 randconfig-a006-20210401
i386                 randconfig-a003-20210401
i386                 randconfig-a001-20210401
i386                 randconfig-a004-20210401
i386                 randconfig-a002-20210401
i386                 randconfig-a005-20210401
x86_64               randconfig-a006-20210408
i386                 randconfig-a014-20210402
i386                 randconfig-a016-20210402
i386                 randconfig-a011-20210402
i386                 randconfig-a012-20210402
i386                 randconfig-a013-20210402
i386                 randconfig-a015-20210402
i386                 randconfig-a014-20210401
i386                 randconfig-a011-20210401
i386                 randconfig-a016-20210401
i386                 randconfig-a012-20210401
i386                 randconfig-a013-20210401
i386                 randconfig-a015-20210401
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210401
x86_64               randconfig-a005-20210401
x86_64               randconfig-a003-20210401
x86_64               randconfig-a001-20210401
x86_64               randconfig-a002-20210401
x86_64               randconfig-a006-20210401
x86_64               randconfig-a014-20210402
x86_64               randconfig-a015-20210402
x86_64               randconfig-a011-20210402
x86_64               randconfig-a013-20210402
x86_64               randconfig-a012-20210402
x86_64               randconfig-a016-20210402
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:40 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:40 +0800
Subject: [soc:arm/soc] BUILD SUCCESS a0c97a6bd63019707f16d36812a5aa2fce3fe29f
Message-ID: <60701614.vUUG07aQ6n3c6wS1%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/soc
branch HEAD: a0c97a6bd63019707f16d36812a5aa2fce3fe29f  Merge tag 'samsung-soc-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc

elapsed time: 729m

configs tested: 105
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
arc                     nsimosci_hs_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
ia64                                defconfig
ia64                             allmodconfig
ia64                             allyesconfig
m68k                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                            allyesconfig
arc                              allyesconfig
arc                                 defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
s390                             allyesconfig
parisc                           allyesconfig
parisc                              defconfig
s390                                defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
riscv                            allyesconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:46 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:46 +0800
Subject: [soc:apple/m1-dependency] BUILD SUCCESS
 847bea3d08af9158ae9e17b43632d6aa4f1702a0
Message-ID: <6070161a.HyuahjDJ7fBB2QQb%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git apple/m1-dependency
branch HEAD: 847bea3d08af9158ae9e17b43632d6aa4f1702a0  Merge remote-tracking branch 'arm64/for-next/fiq'

elapsed time: 729m

configs tested: 105
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
arc                     nsimosci_hs_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
ia64                             allmodconfig
ia64                             allyesconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
m68k                                defconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                            allyesconfig
arc                              allyesconfig
arc                                 defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                                defconfig
s390                             allmodconfig
s390                             allyesconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
riscv                            allyesconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:43 +0800
Subject: [soc:arm/defconfig] BUILD SUCCESS
 2de5bb995656312ac1464ee29294140e9aacd642
Message-ID: <60701617.K4Cfzi9D2xtbBzC6%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/defconfig
branch HEAD: 2de5bb995656312ac1464ee29294140e9aacd642  Merge tag 'omap-for-v5.13/defconfig-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/defconfig

elapsed time: 729m

configs tested: 93
configs skipped: 80

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
i386                             allyesconfig
mips                         rt305x_defconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
arm                        clps711x_defconfig
xtensa                    xip_kc705_defconfig
m68k                       bvme6000_defconfig
h8300                            alldefconfig
arc                     nsimosci_hs_defconfig
sh                          landisk_defconfig
powerpc                      arches_defconfig
mips                          rb532_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
arm                             mxs_defconfig
mips                          malta_defconfig
arm                           u8500_defconfig
arm                            zeus_defconfig
arm                      footbridge_defconfig
powerpc                        warp_defconfig
mips                           ip22_defconfig
m68k                          multi_defconfig
sh                          lboxre2_defconfig
arm                            xcep_defconfig
riscv                               defconfig
ia64                            zx1_defconfig
sh                  sh7785lcr_32bit_defconfig
ia64                                defconfig
m68k                                defconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
arc                                 defconfig
parisc                              defconfig
s390                                defconfig
s390                             allmodconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
arc                              allyesconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a013-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 09:53:49 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 16:53:49 +0800
Subject: [soc:apple/m1-main] BUILD REGRESSION
 7d2d16ccf15d8eb84accfaf44a0b324f36e39588
Message-ID: <6070161d.SQF8SQfxfwOcNaYP%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git apple/m1-main
branch HEAD: 7d2d16ccf15d8eb84accfaf44a0b324f36e39588  arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree

Error/Warning reports:

https://lore.kernel.org/linux-arm-kernel/202104090804.z14OP6te-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104090818.4JeO325F-lkp at intel.com

Error/Warning in current branch:

include/linux/io.h:98:34: warning: pointer/integer type mismatch in conditional expression ('int' and 'void *') [-Wconditional-type-mismatch]
include/linux/io.h:98:9: error: implicit declaration of function 'ioremap_np' [-Werror,-Wimplicit-function-declaration]

Error/Warning ids grouped by kconfigs:

clang_recent_errors
|-- powerpc64-randconfig-r021-20210408
|   |-- include-linux-io.h:error:implicit-declaration-of-function-ioremap_np-Werror-Wimplicit-function-declaration
|   `-- include-linux-io.h:warning:pointer-integer-type-mismatch-in-conditional-expression-(-int-and-void-)
`-- powerpc64-randconfig-r024-20210408
    `-- include-linux-io.h:warning:pointer-integer-type-mismatch-in-conditional-expression-(-int-and-void-)

elapsed time: 729m

configs tested: 66
configs skipped: 2

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From wangyanan55 at huawei.com  Fri Apr  9 09:59:08 2021
From: wangyanan55 at huawei.com (wangyanan (Y))
Date: Fri, 9 Apr 2021 16:59:08 +0800
Subject: [PATCH v4 1/2] KVM: arm64: Move CMOs from user_mem_abort to the
 fault handlers
In-Reply-To: <YHALa38PPQBceqF9@google.com>
References: <20210409033652.28316-1-wangyanan55@huawei.com>
 <20210409033652.28316-2-wangyanan55@huawei.com> <YHALa38PPQBceqF9@google.com>
Message-ID: <67c497cc-5a74-e431-a9bc-d05582998bbe@huawei.com>

Hi Quentin,

On 2021/4/9 16:08, Quentin Perret wrote:
> Hi Yanan,
>
> On Friday 09 Apr 2021 at 11:36:51 (+0800), Yanan Wang wrote:
>> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>> +static void stage2_invalidate_icache(void *addr, u64 size)
>> +{
>> +	if (icache_is_aliasing()) {
>> +		/* Flush any kind of VIPT icache */
>> +		__flush_icache_all();
>> +	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
>> +		/* PIPT or VPIPT at EL2 */
>> +		invalidate_icache_range((unsigned long)addr,
>> +					(unsigned long)addr + size);
>> +	}
>> +}
>> +
> I would recommend to try and rebase this patch on kvmarm/next because
> we've made a few changes in pgtable.c recently. It is now linked into
> the EL2 NVHE code which means there are constraints on what can be used
> from there -- you'll need a bit of extra work to make some of these
> functions available to EL2.
I see, thanks for reminding me this.
I will work on kvmarm/next and send a new version later.

Thanks,
Yanan
>
> Thanks,
> Quentin
> .


From maz at kernel.org  Fri Apr  9 10:00:33 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 09 Apr 2021 10:00:33 +0100
Subject: [PATCH v4 1/2] KVM: arm64: Move CMOs from user_mem_abort to the
 fault handlers
In-Reply-To: <YHALa38PPQBceqF9@google.com>
References: <20210409033652.28316-1-wangyanan55@huawei.com>
 <20210409033652.28316-2-wangyanan55@huawei.com>
 <YHALa38PPQBceqF9@google.com>
Message-ID: <87lf9romry.wl-maz@kernel.org>

On Fri, 09 Apr 2021 09:08:11 +0100,
Quentin Perret <qperret at google.com> wrote:
> 
> Hi Yanan,
> 
> On Friday 09 Apr 2021 at 11:36:51 (+0800), Yanan Wang wrote:
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > +static void stage2_invalidate_icache(void *addr, u64 size)
> > +{
> > +	if (icache_is_aliasing()) {
> > +		/* Flush any kind of VIPT icache */
> > +		__flush_icache_all();
> > +	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
> > +		/* PIPT or VPIPT at EL2 */
> > +		invalidate_icache_range((unsigned long)addr,
> > +					(unsigned long)addr + size);
> > +	}
> > +}
> > +
> 
> I would recommend to try and rebase this patch on kvmarm/next because
> we've made a few changes in pgtable.c recently. It is now linked into
> the EL2 NVHE code which means there are constraints on what can be used
> from there -- you'll need a bit of extra work to make some of these
> functions available to EL2.

That's an interesting point.

I wonder whether we are missing something on the i-side for VPITP +
host stage-2 due to switching HCR_EL2.VM. We haven't changed the VMID
(still 0), but I can't bring myself to be sure it doesn't affect the
icache in this case...

	M.

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


From colin.king at canonical.com  Fri Apr  9 10:01:03 2021
From: colin.king at canonical.com (Colin King)
Date: Fri,  9 Apr 2021 10:01:03 +0100
Subject: [PATCH][V2] clk: uniphier: Fix potential infinite loop
Message-ID: <20210409090104.629722-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of num_parents that is an int type.
There is a potential infinite loop if num_parents is larger than
the u8 loop counter. Fix this by making the loop counter the same
type as num_parents.  Also make num_parents an unsigned int to
match the return type of the call to clk_hw_get_num_parents.

Addresses-Coverity: ("Infinite loop")
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---

V2: Make num_parents an unsigned int to match return type of
    clk_hw_get_num_parents().

---
 drivers/clk/uniphier/clk-uniphier-mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
index 462c84321b2d..1998e9d4cfc0 100644
--- a/drivers/clk/uniphier/clk-uniphier-mux.c
+++ b/drivers/clk/uniphier/clk-uniphier-mux.c
@@ -31,10 +31,10 @@ static int uniphier_clk_mux_set_parent(struct clk_hw *hw, u8 index)
 static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
 {
 	struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
-	int num_parents = clk_hw_get_num_parents(hw);
+	unsigned int num_parents = clk_hw_get_num_parents(hw);
 	int ret;
 	unsigned int val;
-	u8 i;
+	unsigned int i;
 
 	ret = regmap_read(mux->regmap, mux->reg, &val);
 	if (ret)
-- 
2.30.2



From colin.king at canonical.com  Fri Apr  9 10:01:04 2021
From: colin.king at canonical.com (Colin King)
Date: Fri,  9 Apr 2021 10:01:04 +0100
Subject: [PATCH][V2] clk: uniphier: Fix potential infinite loop
In-Reply-To: <20210409090104.629722-1-colin.king@canonical.com>
References: <20210409090104.629722-1-colin.king@canonical.com>
Message-ID: <20210409090104.629722-2-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The for-loop iterates with a u8 loop counter i and compares this
with the loop upper limit of num_parents that is an int type.
There is a potential infinite loop if num_parents is larger than
the u8 loop counter. Fix this by making the loop counter the same
type as num_parents.  Also make num_parents an unsigned int to
match the return type of the call to clk_hw_get_num_parents.

Addresses-Coverity: ("Infinite loop")
Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---

V2: Make num_parents an unsigned int to match return type of
    clk_hw_get_num_parents().

---
 drivers/clk/uniphier/clk-uniphier-mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
index 462c84321b2d..1998e9d4cfc0 100644
--- a/drivers/clk/uniphier/clk-uniphier-mux.c
+++ b/drivers/clk/uniphier/clk-uniphier-mux.c
@@ -31,10 +31,10 @@ static int uniphier_clk_mux_set_parent(struct clk_hw *hw, u8 index)
 static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
 {
 	struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
-	int num_parents = clk_hw_get_num_parents(hw);
+	unsigned int num_parents = clk_hw_get_num_parents(hw);
 	int ret;
 	unsigned int val;
-	u8 i;
+	unsigned int i;
 
 	ret = regmap_read(mux->regmap, mux->reg, &val);
 	if (ret)
-- 
2.30.2



From anshuman.khandual at arm.com  Fri Apr  9 10:05:07 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri, 9 Apr 2021 14:35:07 +0530
Subject: [PATCH -next] coresight: core: Make symbol 'csdev_sink' static
In-Reply-To: <20210409013215.488823-1-weiyongjun1@huawei.com>
References: <20210409013215.488823-1-weiyongjun1@huawei.com>
Message-ID: <291c6015-dbef-553b-c756-9d5acd1d9fe2@arm.com>



On 4/9/21 7:02 AM, Wei Yongjun wrote:
> The sparse tool complains as follows:
> 
> drivers/hwtracing/coresight/coresight-core.c:26:1: warning:
>  symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static?
> 
> This symbol is not used outside of coresight-core.c, so this
> commit marks it static.

commit ? It is not on the tree yet. s/commit/change instead.

> 
> Fixes: 2cd87a7b293d ("coresight: core: Add support for dedicated percpu sinks")

There is no functional problem that this patch is proposing to fix
and hence the "Fixes:" tag is not warranted. Suzuki/Matihieu ?

> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
> ---
>  drivers/hwtracing/coresight/coresight-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 3e779e1619ed..6c68d34d956e 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -23,7 +23,7 @@
>  #include "coresight-priv.h"
>  
>  static DEFINE_MUTEX(coresight_mutex);
> -DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
> +static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
>  
>  /**
>   * struct coresight_node - elements of a path, from source to sink
> 

Otherwise LGTM. As csdev_sink is not being used outside coresight-core.c
file after the introduction of coresight_[set|get]_percpu_sink() helpers.


From dan.carpenter at oracle.com  Fri Apr  9 10:06:26 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 9 Apr 2021 12:06:26 +0300
Subject: [kbuild] Re: [PATCH net-next v2 1/2] of: net: pass the dst buffer to
 of_get_mac_address()
In-Reply-To: <20210406153725.10059-2-michael@walle.cc>
Message-ID: <20210409090626.GG6048@kadam>

Hi Michael,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:    https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030 
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git  cc0626c2aaed8e475efdd85fa374b497a7192e35
config: x86_64-randconfig-m001-20210406 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

smatch warnings:
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2069 axienet_probe() warn: passing a valid pointer to 'PTR_ERR'

vim +/PTR_ERR +2069 drivers/net/ethernet/xilinx/xilinx_axienet_main.c

2be586205ca2b8 Srikanth Thokala    2015-05-05  1832  static int axienet_probe(struct platform_device *pdev)
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1833  {
8495659bf93c8e Srikanth Thokala    2015-05-05  1834  	int ret;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1835  	struct device_node *np;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1836  	struct axienet_local *lp;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1837  	struct net_device *ndev;
28ef9ebdb64c6f Robert Hancock      2019-06-06  1838  	struct resource *ethres;
411b125c6ace1f Michael Walle       2021-04-06  1839  	u8 mac_addr[ETH_ALEN];
                                                        ^^^^^^^^^^^^^^^^^^^^^^

5fff0151b3244d Andre Przywara      2020-03-24  1840  	int addr_width = 32;
8495659bf93c8e Srikanth Thokala    2015-05-05  1841  	u32 value;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1842  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1843  	ndev = alloc_etherdev(sizeof(*lp));
41de8d4cff21a2 Joe Perches         2012-01-29  1844  	if (!ndev)
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1845  		return -ENOMEM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1846  
95219aa538e11d Srikanth Thokala    2015-05-05  1847  	platform_set_drvdata(pdev, ndev);
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1848  
95219aa538e11d Srikanth Thokala    2015-05-05  1849  	SET_NETDEV_DEV(ndev, &pdev->dev);
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1850  	ndev->flags &= ~IFF_MULTICAST;  /* clear multicast */
28e24c62ab3062 Eric Dumazet        2013-12-02  1851  	ndev->features = NETIF_F_SG;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1852  	ndev->netdev_ops = &axienet_netdev_ops;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1853  	ndev->ethtool_ops = &axienet_ethtool_ops;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1854  
d894be57ca92c8 Jarod Wilson        2016-10-20  1855  	/* MTU range: 64 - 9000 */
d894be57ca92c8 Jarod Wilson        2016-10-20  1856  	ndev->min_mtu = 64;
d894be57ca92c8 Jarod Wilson        2016-10-20  1857  	ndev->max_mtu = XAE_JUMBO_MTU;
d894be57ca92c8 Jarod Wilson        2016-10-20  1858  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1859  	lp = netdev_priv(ndev);
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1860  	lp->ndev = ndev;
95219aa538e11d Srikanth Thokala    2015-05-05  1861  	lp->dev = &pdev->dev;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1862  	lp->options = XAE_OPTION_DEFAULTS;
8b09ca823ffb4e Robert Hancock      2019-06-06  1863  	lp->rx_bd_num = RX_BD_NUM_DEFAULT;
8b09ca823ffb4e Robert Hancock      2019-06-06  1864  	lp->tx_bd_num = TX_BD_NUM_DEFAULT;
57baf8cc70ea4c Robert Hancock      2021-02-12  1865  
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1866  	lp->axi_clk = devm_clk_get_optional(&pdev->dev, "s_axi_lite_clk");
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1867  	if (!lp->axi_clk) {
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1868  		/* For backward compatibility, if named AXI clock is not present,
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1869  		 * treat the first clock specified as the AXI clock.
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1870  		 */
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1871  		lp->axi_clk = devm_clk_get_optional(&pdev->dev, NULL);
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1872  	}
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1873  	if (IS_ERR(lp->axi_clk)) {
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1874  		ret = PTR_ERR(lp->axi_clk);
57baf8cc70ea4c Robert Hancock      2021-02-12  1875  		goto free_netdev;
57baf8cc70ea4c Robert Hancock      2021-02-12  1876  	}
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1877  	ret = clk_prepare_enable(lp->axi_clk);
57baf8cc70ea4c Robert Hancock      2021-02-12  1878  	if (ret) {
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1879  		dev_err(&pdev->dev, "Unable to enable AXI clock: %d\n", ret);
57baf8cc70ea4c Robert Hancock      2021-02-12  1880  		goto free_netdev;
57baf8cc70ea4c Robert Hancock      2021-02-12  1881  	}
57baf8cc70ea4c Robert Hancock      2021-02-12  1882  
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1883  	lp->misc_clks[0].id = "axis_clk";
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1884  	lp->misc_clks[1].id = "ref_clk";
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1885  	lp->misc_clks[2].id = "mgt_clk";
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1886  
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1887  	ret = devm_clk_bulk_get_optional(&pdev->dev, XAE_NUM_MISC_CLOCKS, lp->misc_clks);
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1888  	if (ret)
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1889  		goto cleanup_clk;
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1890  
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1891  	ret = clk_bulk_prepare_enable(XAE_NUM_MISC_CLOCKS, lp->misc_clks);
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1892  	if (ret)
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1893  		goto cleanup_clk;
b11bfb9a19f9d7 Robert Hancock      2021-03-25  1894  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1895  	/* Map device registers */
46aa27df885321 Srikanth Thokala    2015-05-05  1896  	ethres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
46aa27df885321 Srikanth Thokala    2015-05-05  1897  	lp->regs = devm_ioremap_resource(&pdev->dev, ethres);
fcc028c106e575 Krzysztof Kozlowski 2015-07-09  1898  	if (IS_ERR(lp->regs)) {
fcc028c106e575 Krzysztof Kozlowski 2015-07-09  1899  		ret = PTR_ERR(lp->regs);
59cd4f19267a0a Robert Hancock      2021-03-11  1900  		goto cleanup_clk;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1901  	}
7fa0043d5c74c6 Robert Hancock      2019-06-11  1902  	lp->regs_start = ethres->start;
46aa27df885321 Srikanth Thokala    2015-05-05  1903  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1904  	/* Setup checksum offload, but default to off if not specified */
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1905  	lp->features = 0;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1906  
8495659bf93c8e Srikanth Thokala    2015-05-05  1907  	ret = of_property_read_u32(pdev->dev.of_node, "xlnx,txcsum", &value);
8495659bf93c8e Srikanth Thokala    2015-05-05  1908  	if (!ret) {
8495659bf93c8e Srikanth Thokala    2015-05-05  1909  		switch (value) {
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1910  		case 1:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1911  			lp->csum_offload_on_tx_path =
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1912  				XAE_FEATURE_PARTIAL_TX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1913  			lp->features |= XAE_FEATURE_PARTIAL_TX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1914  			/* Can checksum TCP/UDP over IPv4. */
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1915  			ndev->features |= NETIF_F_IP_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1916  			break;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1917  		case 2:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1918  			lp->csum_offload_on_tx_path =
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1919  				XAE_FEATURE_FULL_TX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1920  			lp->features |= XAE_FEATURE_FULL_TX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1921  			/* Can checksum TCP/UDP over IPv4. */
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1922  			ndev->features |= NETIF_F_IP_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1923  			break;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1924  		default:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1925  			lp->csum_offload_on_tx_path = XAE_NO_CSUM_OFFLOAD;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1926  		}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1927  	}
8495659bf93c8e Srikanth Thokala    2015-05-05  1928  	ret = of_property_read_u32(pdev->dev.of_node, "xlnx,rxcsum", &value);
8495659bf93c8e Srikanth Thokala    2015-05-05  1929  	if (!ret) {
8495659bf93c8e Srikanth Thokala    2015-05-05  1930  		switch (value) {
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1931  		case 1:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1932  			lp->csum_offload_on_rx_path =
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1933  				XAE_FEATURE_PARTIAL_RX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1934  			lp->features |= XAE_FEATURE_PARTIAL_RX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1935  			break;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1936  		case 2:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1937  			lp->csum_offload_on_rx_path =
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1938  				XAE_FEATURE_FULL_RX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1939  			lp->features |= XAE_FEATURE_FULL_RX_CSUM;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1940  			break;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1941  		default:
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1942  			lp->csum_offload_on_rx_path = XAE_NO_CSUM_OFFLOAD;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1943  		}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1944  	}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1945  	/* For supporting jumbo frames, the Axi Ethernet hardware must have
f080a8c35d8932 Srikanth Thokala    2015-05-05  1946  	 * a larger Rx/Tx Memory. Typically, the size must be large so that
f080a8c35d8932 Srikanth Thokala    2015-05-05  1947  	 * we can enable jumbo option and start supporting jumbo frames.
f080a8c35d8932 Srikanth Thokala    2015-05-05  1948  	 * Here we check for memory allocated for Rx/Tx in the hardware from
f080a8c35d8932 Srikanth Thokala    2015-05-05  1949  	 * the device-tree and accordingly set flags.
f080a8c35d8932 Srikanth Thokala    2015-05-05  1950  	 */
8495659bf93c8e Srikanth Thokala    2015-05-05  1951  	of_property_read_u32(pdev->dev.of_node, "xlnx,rxmem", &lp->rxmem);
ee06b1728b9564 Alvaro G. M         2017-07-17  1952  
6c8f06bb2e5147 Robert Hancock      2021-02-12  1953  	lp->switch_x_sgmii = of_property_read_bool(pdev->dev.of_node,
6c8f06bb2e5147 Robert Hancock      2021-02-12  1954  						   "xlnx,switch-x-sgmii");
6c8f06bb2e5147 Robert Hancock      2021-02-12  1955  
ee06b1728b9564 Alvaro G. M         2017-07-17  1956  	/* Start with the proprietary, and broken phy_type */
ee06b1728b9564 Alvaro G. M         2017-07-17  1957  	ret = of_property_read_u32(pdev->dev.of_node, "xlnx,phy-type", &value);
ee06b1728b9564 Alvaro G. M         2017-07-17  1958  	if (!ret) {
ee06b1728b9564 Alvaro G. M         2017-07-17  1959  		netdev_warn(ndev, "Please upgrade your device tree binary blob to use phy-mode");
ee06b1728b9564 Alvaro G. M         2017-07-17  1960  		switch (value) {
ee06b1728b9564 Alvaro G. M         2017-07-17  1961  		case XAE_PHY_TYPE_MII:
ee06b1728b9564 Alvaro G. M         2017-07-17  1962  			lp->phy_mode = PHY_INTERFACE_MODE_MII;
ee06b1728b9564 Alvaro G. M         2017-07-17  1963  			break;
ee06b1728b9564 Alvaro G. M         2017-07-17  1964  		case XAE_PHY_TYPE_GMII:
ee06b1728b9564 Alvaro G. M         2017-07-17  1965  			lp->phy_mode = PHY_INTERFACE_MODE_GMII;
ee06b1728b9564 Alvaro G. M         2017-07-17  1966  			break;
ee06b1728b9564 Alvaro G. M         2017-07-17  1967  		case XAE_PHY_TYPE_RGMII_2_0:
ee06b1728b9564 Alvaro G. M         2017-07-17  1968  			lp->phy_mode = PHY_INTERFACE_MODE_RGMII_ID;
ee06b1728b9564 Alvaro G. M         2017-07-17  1969  			break;
ee06b1728b9564 Alvaro G. M         2017-07-17  1970  		case XAE_PHY_TYPE_SGMII:
ee06b1728b9564 Alvaro G. M         2017-07-17  1971  			lp->phy_mode = PHY_INTERFACE_MODE_SGMII;
ee06b1728b9564 Alvaro G. M         2017-07-17  1972  			break;
ee06b1728b9564 Alvaro G. M         2017-07-17  1973  		case XAE_PHY_TYPE_1000BASE_X:
ee06b1728b9564 Alvaro G. M         2017-07-17  1974  			lp->phy_mode = PHY_INTERFACE_MODE_1000BASEX;
ee06b1728b9564 Alvaro G. M         2017-07-17  1975  			break;
ee06b1728b9564 Alvaro G. M         2017-07-17  1976  		default:
ee06b1728b9564 Alvaro G. M         2017-07-17  1977  			ret = -EINVAL;
59cd4f19267a0a Robert Hancock      2021-03-11  1978  			goto cleanup_clk;
ee06b1728b9564 Alvaro G. M         2017-07-17  1979  		}
ee06b1728b9564 Alvaro G. M         2017-07-17  1980  	} else {
0c65b2b90d13c1 Andrew Lunn         2019-11-04  1981  		ret = of_get_phy_mode(pdev->dev.of_node, &lp->phy_mode);
0c65b2b90d13c1 Andrew Lunn         2019-11-04  1982  		if (ret)
59cd4f19267a0a Robert Hancock      2021-03-11  1983  			goto cleanup_clk;
ee06b1728b9564 Alvaro G. M         2017-07-17  1984  	}
6c8f06bb2e5147 Robert Hancock      2021-02-12  1985  	if (lp->switch_x_sgmii && lp->phy_mode != PHY_INTERFACE_MODE_SGMII &&
6c8f06bb2e5147 Robert Hancock      2021-02-12  1986  	    lp->phy_mode != PHY_INTERFACE_MODE_1000BASEX) {
6c8f06bb2e5147 Robert Hancock      2021-02-12  1987  		dev_err(&pdev->dev, "xlnx,switch-x-sgmii only supported with SGMII or 1000BaseX\n");
6c8f06bb2e5147 Robert Hancock      2021-02-12  1988  		ret = -EINVAL;
59cd4f19267a0a Robert Hancock      2021-03-11  1989  		goto cleanup_clk;
6c8f06bb2e5147 Robert Hancock      2021-02-12  1990  	}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1991  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  1992  	/* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
95219aa538e11d Srikanth Thokala    2015-05-05  1993  	np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
28ef9ebdb64c6f Robert Hancock      2019-06-06  1994  	if (np) {
28ef9ebdb64c6f Robert Hancock      2019-06-06  1995  		struct resource dmares;
28ef9ebdb64c6f Robert Hancock      2019-06-06  1996  
46aa27df885321 Srikanth Thokala    2015-05-05  1997  		ret = of_address_to_resource(np, 0, &dmares);
46aa27df885321 Srikanth Thokala    2015-05-05  1998  		if (ret) {
28ef9ebdb64c6f Robert Hancock      2019-06-06  1999  			dev_err(&pdev->dev,
28ef9ebdb64c6f Robert Hancock      2019-06-06  2000  				"unable to get DMA resource\n");
fa3a419d2f674b Wen Yang            2019-03-22  2001  			of_node_put(np);
59cd4f19267a0a Robert Hancock      2021-03-11  2002  			goto cleanup_clk;
46aa27df885321 Srikanth Thokala    2015-05-05  2003  		}
28ef9ebdb64c6f Robert Hancock      2019-06-06  2004  		lp->dma_regs = devm_ioremap_resource(&pdev->dev,
28ef9ebdb64c6f Robert Hancock      2019-06-06  2005  						     &dmares);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2006  		lp->rx_irq = irq_of_parse_and_map(np, 1);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2007  		lp->tx_irq = irq_of_parse_and_map(np, 0);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2008  		of_node_put(np);
d6349e3e14c7f7 Andre Przywara      2020-03-24  2009  		lp->eth_irq = platform_get_irq_optional(pdev, 0);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2010  	} else {
28ef9ebdb64c6f Robert Hancock      2019-06-06  2011  		/* Check for these resources directly on the Ethernet node. */
28ef9ebdb64c6f Robert Hancock      2019-06-06  2012  		struct resource *res = platform_get_resource(pdev,
28ef9ebdb64c6f Robert Hancock      2019-06-06  2013  							     IORESOURCE_MEM, 1);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2014  		lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2015  		lp->rx_irq = platform_get_irq(pdev, 1);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2016  		lp->tx_irq = platform_get_irq(pdev, 0);
d6349e3e14c7f7 Andre Przywara      2020-03-24  2017  		lp->eth_irq = platform_get_irq_optional(pdev, 2);
28ef9ebdb64c6f Robert Hancock      2019-06-06  2018  	}
fcc028c106e575 Krzysztof Kozlowski 2015-07-09  2019  	if (IS_ERR(lp->dma_regs)) {
46aa27df885321 Srikanth Thokala    2015-05-05  2020  		dev_err(&pdev->dev, "could not map DMA regs\n");
fcc028c106e575 Krzysztof Kozlowski 2015-07-09  2021  		ret = PTR_ERR(lp->dma_regs);
59cd4f19267a0a Robert Hancock      2021-03-11  2022  		goto cleanup_clk;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2023  	}
cb59c87dbc8be2 Michal Simek        2013-01-10  2024  	if ((lp->rx_irq <= 0) || (lp->tx_irq <= 0)) {
95219aa538e11d Srikanth Thokala    2015-05-05  2025  		dev_err(&pdev->dev, "could not determine irqs\n");
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2026  		ret = -ENOMEM;
59cd4f19267a0a Robert Hancock      2021-03-11  2027  		goto cleanup_clk;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2028  	}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2029  
f735c40ed93cca Andre Przywara      2020-03-24  2030  	/* Autodetect the need for 64-bit DMA pointers.
f735c40ed93cca Andre Przywara      2020-03-24  2031  	 * When the IP is configured for a bus width bigger than 32 bits,
f735c40ed93cca Andre Przywara      2020-03-24  2032  	 * writing the MSB registers is mandatory, even if they are all 0.
f735c40ed93cca Andre Przywara      2020-03-24  2033  	 * We can detect this case by writing all 1's to one such register
f735c40ed93cca Andre Przywara      2020-03-24  2034  	 * and see if that sticks: when the IP is configured for 32 bits
f735c40ed93cca Andre Przywara      2020-03-24  2035  	 * only, those registers are RES0.
f735c40ed93cca Andre Przywara      2020-03-24  2036  	 * Those MSB registers were introduced in IP v7.1, which we check first.
f735c40ed93cca Andre Przywara      2020-03-24  2037  	 */
f735c40ed93cca Andre Przywara      2020-03-24  2038  	if ((axienet_ior(lp, XAE_ID_OFFSET) >> 24) >= 0x9) {
f735c40ed93cca Andre Przywara      2020-03-24  2039  		void __iomem *desc = lp->dma_regs + XAXIDMA_TX_CDESC_OFFSET + 4;
f735c40ed93cca Andre Przywara      2020-03-24  2040  
f735c40ed93cca Andre Przywara      2020-03-24  2041  		iowrite32(0x0, desc);
f735c40ed93cca Andre Przywara      2020-03-24  2042  		if (ioread32(desc) == 0) {	/* sanity check */
f735c40ed93cca Andre Przywara      2020-03-24  2043  			iowrite32(0xffffffff, desc);
f735c40ed93cca Andre Przywara      2020-03-24  2044  			if (ioread32(desc) > 0) {
f735c40ed93cca Andre Przywara      2020-03-24  2045  				lp->features |= XAE_FEATURE_DMA_64BIT;
5fff0151b3244d Andre Przywara      2020-03-24  2046  				addr_width = 64;
f735c40ed93cca Andre Przywara      2020-03-24  2047  				dev_info(&pdev->dev,
f735c40ed93cca Andre Przywara      2020-03-24  2048  					 "autodetected 64-bit DMA range\n");
f735c40ed93cca Andre Przywara      2020-03-24  2049  			}
f735c40ed93cca Andre Przywara      2020-03-24  2050  			iowrite32(0x0, desc);
f735c40ed93cca Andre Przywara      2020-03-24  2051  		}
f735c40ed93cca Andre Przywara      2020-03-24  2052  	}
f735c40ed93cca Andre Przywara      2020-03-24  2053  
5fff0151b3244d Andre Przywara      2020-03-24  2054  	ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(addr_width));
5fff0151b3244d Andre Przywara      2020-03-24  2055  	if (ret) {
5fff0151b3244d Andre Przywara      2020-03-24  2056  		dev_err(&pdev->dev, "No suitable DMA available\n");
59cd4f19267a0a Robert Hancock      2021-03-11  2057  		goto cleanup_clk;
5fff0151b3244d Andre Przywara      2020-03-24  2058  	}
5fff0151b3244d Andre Przywara      2020-03-24  2059  
522856cefaf09d Robert Hancock      2019-06-06  2060  	/* Check for Ethernet core IRQ (optional) */
522856cefaf09d Robert Hancock      2019-06-06  2061  	if (lp->eth_irq <= 0)
522856cefaf09d Robert Hancock      2019-06-06  2062  		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
522856cefaf09d Robert Hancock      2019-06-06  2063  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2064  	/* Retrieve the MAC address */
411b125c6ace1f Michael Walle       2021-04-06  2065  	ret = of_get_mac_address(pdev->dev.of_node, mac_addr);
411b125c6ace1f Michael Walle       2021-04-06  2066  	if (!ret) {
411b125c6ace1f Michael Walle       2021-04-06  2067  		axienet_set_mac_address(ndev, mac_addr);
411b125c6ace1f Michael Walle       2021-04-06  2068  	} else {
d05a9ed5c3a773 Robert Hancock      2019-06-06 @2069  		dev_warn(&pdev->dev, "could not find MAC address property: %ld\n",
d05a9ed5c3a773 Robert Hancock      2019-06-06  2070  			 PTR_ERR(mac_addr));
                                                                         ^^^^^^^^^^^^^^^^^
mac_addr isn't an error pointer.

411b125c6ace1f Michael Walle       2021-04-06  2071  		axienet_set_mac_address(ndev, NULL);
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2072  	}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2073  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31129 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/bc5a5d99/attachment-0001.gz>
-------------- next part --------------
_______________________________________________
kbuild mailing list -- kbuild at lists.01.org
To unsubscribe send an email to kbuild-leave at lists.01.org

From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr  9 10:07:07 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri,  9 Apr 2021 18:07:07 +0900
Subject: [PATCH v3 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Message-ID: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation and device driver.

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

Updates:

  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm
      - Change filename to toshiba,visconti-pwm.yaml.
      - Add Reviewed-by tag from Rob.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
      - Set compatible toshiba,pwm-visconti only.
      - Drop unnecessary comments.

  pwm: visconti: Add Toshiba Visconti SoC PWM support
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm.
      - Fix MODULE_ALIAS to platform:pwm-visconti, again.
      - Align continuation line to the opening parenthesis.
      - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only.
      - Add prefix for the register defines.
      - Drop struct device from struct visconti_pwm_chip.
      - Use '>>' instead of '/'.
      - Drop error message by devm_platform_ioremap_resource().
      - Use dev_err_probe instead of dev_err.
      - Change dev_info to dev_dbg.
      - Remove some empty lines.
      - Fix MODULE_ALIAS to platform:pwm-visconti.
      - Add .get_state() function.
      - Use the author name and email address to MODULE_AUTHOR.
      - Add more comment to function of the hardware.
      - Support .get_status() function.
      - Use NSEC_PER_USEC instead of 1000.
      - Alphabetically sorted for Makefile and Kconfig.
      - Added check for set value in visconti_pwm_apply().

Nobuhiro Iwamatsu (2):
  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
  pwm: visconti: Add Toshiba Visconti SoC PWM support

 .../bindings/pwm/toshiba,visconti-pwm.yaml    |  43 ++++
 drivers/pwm/Kconfig                           |   9 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-visconti.c                    | 193 ++++++++++++++++++
 4 files changed, 246 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,visconti-pwm.yaml
 create mode 100644 drivers/pwm/pwm-visconti.c

-- 
2.30.0.rc2


From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr  9 10:07:09 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri,  9 Apr 2021 18:07:09 +0900
Subject: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add driver for the PWM controller on Toshiba Visconti ARM SoC.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pwm/Kconfig        |   9 ++
 drivers/pwm/Makefile       |   1 +
 drivers/pwm/pwm-visconti.c | 193 +++++++++++++++++++++++++++++++++++++
 3 files changed, 203 insertions(+)
 create mode 100644 drivers/pwm/pwm-visconti.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..8ae68d6203fb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -601,6 +601,15 @@ config PWM_TWL_LED
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-twl-led.
 
+config PWM_VISCONTI
+	tristate "Toshiba Visconti PWM support"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	help
+	  PWM Subsystem driver support for Toshiba Visconti SoCs.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-visconti.
+
 config PWM_VT8500
 	tristate "vt8500 PWM support"
 	depends on ARCH_VT8500 || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..d43b1e17e8e1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
+obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
 obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
new file mode 100644
index 000000000000..ff4a5f5b0009
--- /dev/null
+++ b/drivers/pwm/pwm-visconti.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Toshiba Visconti pulse-width-modulation controller driver
+ *
+ * Copyright (c) 2020 TOSHIBA CORPORATION
+ * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
+ *
+ * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pwm.h>
+#include <linux/platform_device.h>
+
+#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
+#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
+#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
+
+#define PIPGM_PWMC_PWMACT		BIT(5)
+#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
+#define PIPGM_PWMC_POLARITY_MASK	GENMASK(5, 5)
+
+struct visconti_pwm_chip {
+	struct pwm_chip chip;
+	void __iomem *base;
+};
+
+#define to_visconti_chip(chip) \
+	container_of(chip, struct visconti_pwm_chip, chip)
+
+static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
+	u32 period, duty_cycle, pwmc0;
+
+	dev_dbg(chip->dev, "%s: ch = %d en = %d p = 0x%llx d = 0x%llx\n", __func__,
+		pwm->hwpwm, state->enabled, state->period, state->duty_cycle);
+
+	/*
+	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
+	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
+	 * the period register (PCSR) is written and the currently running period is completed. This
+	 * way the hardware switches atomically from the old setting to the new.
+	 * Also, disabling the hardware completes the currently running period and keeps the output
+	 * at low level at all times.
+	 */
+	if (!state->enabled) {
+		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
+		return 0;
+	}
+
+	/*
+	 * The biggest period the hardware can provide is
+	 *	(0xffff << 3) * 1000 ns
+	 * This value fits easily in an u32, so simplify the maths by
+	 * capping the values to 32 bit integers.
+	 */
+	if (state->period > (0xffff << 3) * 1000)
+		period = (0xffff << 3) * 1000;
+	else
+		period = state->period;
+
+	if (state->duty_cycle > period)
+		duty_cycle = period;
+	else
+		duty_cycle = state->duty_cycle;
+
+	/*
+	 * The input clock runs fixed at 1 MHz, so we have only
+	 * microsecond resolution and so can divide by
+	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
+	 */
+	period /= 1000;
+	duty_cycle /= 1000;
+
+	if (!period)
+		/* period too small */
+		return -ERANGE;
+
+	/*
+	 * PWMC controls a divider that divides the input clk by a
+	 * power of two between 1 and 8. As a smaller divider yields
+	 * higher precision, pick the smallest possible one.
+	 */
+	if (period > 0xffff) {
+		pwmc0 = ilog2(period >> 16);
+		BUG_ON(pwmc0 > 3);
+	} else
+		pwmc0 = 0;
+
+	period >>= pwmc0;
+	duty_cycle >>= pwmc0;
+
+	if (state->polarity == PWM_POLARITY_INVERSED)
+		pwmc0 |= PIPGM_PWMC_PWMACT;
+	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
+	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
+	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
+
+	return 0;
+}
+
+static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
+	u32 period, duty, pwmc0, pwmc0_clk;
+
+	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
+	if (period)
+		state->enabled = true;
+	else
+		state->enabled = false;
+
+	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
+	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
+	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
+
+	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
+	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
+	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
+		state->polarity = PWM_POLARITY_INVERSED;
+	else
+		state->polarity = PWM_POLARITY_NORMAL;
+}
+
+static const struct pwm_ops visconti_pwm_ops = {
+	.apply = visconti_pwm_apply,
+	.get_state = visconti_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int visconti_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pwm_chip *priv;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &visconti_pwm_ops;
+	priv->chip.base = -1;
+	priv->chip.npwm = 4;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
+
+	dev_dbg(&pdev->dev, "visconti PWM registered\n");
+
+	return 0;
+}
+
+static int visconti_pwm_remove(struct platform_device *pdev)
+{
+	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
+
+	return pwmchip_remove(&priv->chip);
+}
+
+static const struct of_device_id visconti_pwm_of_match[] = {
+	{ .compatible = "toshiba,visconti-pwm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, visconti_pwm_of_match);
+
+static struct platform_driver visconti_pwm_driver = {
+	.driver = {
+		.name = "pwm-visconti",
+		.of_match_table = visconti_pwm_of_match,
+	},
+	.probe = visconti_pwm_probe,
+	.remove = visconti_pwm_remove,
+};
+module_platform_driver(visconti_pwm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>");
+MODULE_ALIAS("platform:pwm-visconti");
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr  9 10:07:08 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri,  9 Apr 2021 18:07:08 +0900
Subject: [PATCH v3 1/2] dt-bindings: pwm: Add bindings for Toshiba Visconti
 PWM Controller
In-Reply-To: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210409090709.1918021-2-nobuhiro1.iwamatsu@toshiba.co.jp>

Add bindings for the Toshiba Visconti PWM Controller.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pwm/toshiba,visconti-pwm.yaml    | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,visconti-pwm.yaml

diff --git a/Documentation/devicetree/bindings/pwm/toshiba,visconti-pwm.yaml b/Documentation/devicetree/bindings/pwm/toshiba,visconti-pwm.yaml
new file mode 100644
index 000000000000..9e32e7dbb2f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/toshiba,visconti-pwm.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/toshiba,visconti-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti PWM Controller
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,visconti-pwm
+
+  reg:
+    maxItems: 1
+
+  '#pwm-cells':
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pwm: pwm at 241c0000 {
+            compatible = "toshiba,visconti-pwm";
+            reg = <0 0x241c0000 0 0x1000>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&pwm_mux>;
+            #pwm-cells = <2>;
+        };
+    };
-- 
2.30.0.rc2



From liuqi115 at huawei.com  Fri Apr  9 10:05:57 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Fri, 9 Apr 2021 17:05:57 +0800
Subject: [PATCH v2 2/2] docs: perf: Add description for HiSilicon PCIe PMU
 driver
In-Reply-To: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1617959157-22956-3-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported on
HiSilicon HIP09 platform. Document it to provide guidance on how to
use it.

Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---

 Documentation/admin-guide/perf/hisi-pcie-pmu.rst | 104 +++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst

diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
new file mode 100644
index 0000000..2084b53
--- /dev/null
+++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
@@ -0,0 +1,104 @@
+================================================
+HiSilicon PCIe Performance Monitoring Unit (PMU)
+================================================
+
+HiSilicon PCIe Performance Monitoring Unit (PMU) is a PCIe Root Complex
+integrated End Point (RCiEP) device. On Hip09, each PCIe Core has a PMU RCiEP
+to monitor multi Root Ports and all Endpoints downstream these Root Ports.
+
+HiSilicon PCIe PMU is supported to collect performance data of PCIe bus, such
+as: bandwidth, latency etc.
+
+
+HiSilicon PCIe PMU driver
+=========================
+
+The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe
+Core id.::
+
+  /sys/bus/event_source/hisi_pcie<sicl>_<core>
+
+PMU driver provides description of available events and filter options in sysfs,
+see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>.
+
+The "format" directory describes all formats of the config (events) and config1
+(filter options) fields of the perf_event_attr structure. The "events" directory
+describes all documented events shown in perf list.
+
+The "identifier" sysfs file allows users to identify the version of the
+PMU hardware device.
+
+The "bus" sysfs file allows users to get the bus number of Root Ports
+monitored by PMU.
+
+Example usage of perf::
+
+  $# perf list
+  hisi_pcie0_0/bw_rx/ [kernel PMU event]
+  ------------------------------------------
+
+  $# perf stat -e hisi_pcie0_0/bw_rx/ sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported for PCIe PMU.
+
+Filter options
+--------------
+
+1. Target filter
+PMU could only monitor the performance of traffic downstream target Root Ports
+or downstream target Endpoint. PCIe PMU driver support "port" and "bdf"
+interfaces for users, and these two interfaces aren't supported at the same
+time.
+
+-port
+"port" filter can be used in all PCIe PMU events, target Root Port can be
+selected by configuring the 16-bits-bitmap "port". Multi ports can be selected
+for AP-layer-events, and only one port can be selected for TL/DL-layer-events.
+
+For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of bitmap
+should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 lanes),
+bit8 is set, port=0x100; if these two Root Ports are both monitored, port=0x101.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,port=0x1/ sleep 5
+
+-bdf
+
+"bdf" filter can only be used in bandwidth events, target Endpoint is selected
+by configuring BDF to "bdf". Counter only counts the bandwidth of message
+requested by target Endpoint.
+
+For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,bdf=0x3900/ sleep 5
+
+2. Trigger filter
+Event statistics start when the first time TLP length is greater/smaller
+than trigger condition. You can set the trigger condition by writing "trig_len",
+and set the trigger mode by writing "trig_mode". This filter can only be used
+in bandwidth events.
+
+For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0"
+means statistics start when TLP length > trigger condition, "trig_mode=1"
+means start when TLP length < condition.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,trig_len=0x4,trig_mode=1/ sleep 5
+
+3. Threshold filter
+Counter counts when TLP length within the specified range. You can set the
+threshold by writing "thr_len", and set the threshold mode by writing
+"thr_mode". This filter can only be used in bandwidth events.
+
+For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means
+counter counts when TLP length >= threshold, and "thr_mode=1" means counts
+when TLP length < threshold.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,thr_len=0x4,thr_mode=1/ sleep 5
-- 
2.8.1



From liuqi115 at huawei.com  Fri Apr  9 10:05:55 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Fri, 9 Apr 2021 17:05:55 +0800
Subject: [PATCH v2 0/2] drivers/perf: hisi: Add support for PCIe PMU
Message-ID: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>

This patchset adds support for HiSilicon PCIe Performance Monitoring
Unit(PMU). It is a PCIe Root Complex integrated End Point(RCiEP) device
added on Hip09. Each PCIe Core has a PMU RCiEP to monitor multi root
ports and all Endpoints downstream these root ports.

HiSilicon PCIe PMU is supported to collect performance data of PCIe bus,
such as: bandwidth, latency etc.

Changes since v1:
- Drop the internal Reviewed-by tag.
- Fix some build warnings when W=1.

Qi Liu (2):
  drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
  docs: perf: Add description for HiSilicon PCIe PMU driver

 Documentation/admin-guide/perf/hisi-pcie-pmu.rst |  104 +++
 MAINTAINERS                                      |    6 +
 drivers/perf/Kconfig                             |    2 +
 drivers/perf/Makefile                            |    1 +
 drivers/perf/pci/Kconfig                         |   16 +
 drivers/perf/pci/Makefile                        |    2 +
 drivers/perf/pci/hisilicon/Makefile              |    5 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c       | 1011 ++++++++++++++++++++++
 include/linux/cpuhotplug.h                       |    1 +
 9 files changed, 1148 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

-- 
2.8.1



From liuqi115 at huawei.com  Fri Apr  9 10:05:56 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Fri, 9 Apr 2021 17:05:56 +0800
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1617959157-22956-2-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
to sample bandwidth, latency, buffer occupation etc.

Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
registered as a PMU in /sys/bus/event_source/devices, so users can
select target PMU, and use filter to do further sets.

Filtering options contains:
event        - select the event.
subevent     - select the subevent.
port         - select target Root Ports. Information of Root Ports
               are shown under sysfs.
bdf          - select requester_id of target EP device.
trig_len     - set trigger condition for starting event statistics.
trigger_mode - set trigger mode. 0 means starting to statistic when
               bigger than trigger condition, and 1 means smaller.
thr_len      - set threshold for statistics.
thr_mode     - set threshold mode. 0 means count when bigger than
               threshold, and 1 means smaller.

Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 MAINTAINERS                                |    6 +
 drivers/perf/Kconfig                       |    2 +
 drivers/perf/Makefile                      |    1 +
 drivers/perf/pci/Kconfig                   |   16 +
 drivers/perf/pci/Makefile                  |    2 +
 drivers/perf/pci/hisilicon/Makefile        |    5 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1011 ++++++++++++++++++++++++++++
 include/linux/cpuhotplug.h                 |    1 +
 8 files changed, 1044 insertions(+)
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3353de0..46c7861 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8023,6 +8023,12 @@ W:	http://www.hisilicon.com
 F:	Documentation/admin-guide/perf/hisi-pmu.rst
 F:	drivers/perf/hisilicon
 
+HISILICON PCIE PMU DRIVER
+M:	Qi Liu <liuqi115 at huawei.com>
+S:	Maintained
+F:	Documentation/admin-guide/perf/hisi-pcie-pmu.rst
+F:	drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
+
 HISILICON QM AND ZIP Controller DRIVER
 M:	Zhou Wang <wangzhou1 at hisilicon.com>
 L:	linux-crypto at vger.kernel.org
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 3075cf1..99d4760 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -139,4 +139,6 @@ config ARM_DMC620_PMU
 
 source "drivers/perf/hisilicon/Kconfig"
 
+source "drivers/perf/pci/Kconfig"
+
 endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 5260b11..1208c08 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
 obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
+obj-y += pci/
diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
new file mode 100644
index 0000000..a119486
--- /dev/null
+++ b/drivers/perf/pci/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# PCIe Performance Monitor Drivers
+#
+menu "PCIe Performance Monitor"
+
+config HISI_PCIE_PMU
+	tristate "HiSilicon PCIE PERF PMU"
+	depends on ARM64 && PCI && HISI_PMU
+	help
+	  Provide support for HiSilicon PCIe performance monitoring unit (PMU)
+	  RCiEP devices.
+	  Adds the PCIe PMU into perf events system for monitoring latency,
+	  bandwidth etc.
+
+endmenu
diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
new file mode 100644
index 0000000..a56b1a9
--- /dev/null
+++ b/drivers/perf/pci/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-y += hisilicon/
diff --git a/drivers/perf/pci/hisilicon/Makefile b/drivers/perf/pci/hisilicon/Makefile
new file mode 100644
index 0000000..6f99f52
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+ccflags-y :=  -I $(srctree)/drivers/perf/hisilicon
+
+obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
new file mode 100644
index 0000000..ac0e444
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
@@ -0,0 +1,1011 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This driver adds support for PCIe PMU RCiEP device. Related
+ * perf events are bandwidth, bandwidth utilization, latency
+ * etc.
+ *
+ * Copyright (C) 2021 HiSilicon Limited
+ * Author: Qi Liu<liuqi115 at huawei.com>
+ */
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/bug.h>
+#include <linux/cpuhotplug.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/perf_event.h>
+
+#include "hisi_uncore_pmu.h"
+
+/* Define registers */
+#define HISI_PCIE_GLOBAL_CTRL		0x00
+#define HISI_PCIE_EVENT_CTRL		0x010
+#define HISI_PCIE_CNT			0x090
+#define HISI_PCIE_EXT_CNT		0x110
+#define HISI_PCIE_INT_STAT		0x150
+#define HISI_PCIE_INT_MASK		0x154
+#define HISI_PCIE_REG_BDF		0xfe0
+#define HISI_PCIE_REG_VERSION		0xfe4
+#define HISI_PCIE_REG_INFO		0xfe8
+#define HISI_PCIE_REG_FREQ		0xfec
+
+/* Define PCIE CTRL CMD */
+#define HISI_PCIE_GLOBAL_EN		0x01
+#define HISI_PCIE_GLOBAL_NONE		0
+#define HISI_PCIE_EVENT_EN		BIT(20)
+#define HISI_PCIE_RESET_CNT		BIT(22)
+#define HISI_PCIE_DEFAULT_SET		BIT(34)
+#define HISI_PCIE_THR_EN		BIT(26)
+#define HISI_PCIE_TARGET_EN		BIT(32)
+#define HISI_PCIE_TRIG_EN		BIT(52)
+
+/* Define offsets in event ctrl regesiter */
+#define HISI_PCIE_EVENT_M		GENMASK_ULL(7, 0)
+#define HISI_PCIE_SUBEVENT_M		GENMASK_ULL(15, 8)
+#define HISI_PCIE_THR_MODE_M		GENMASK_ULL(27, 27)
+#define HISI_PCIE_THR_M			GENMASK_ULL(31, 28)
+#define HISI_PCIE_TARGET_M		GENMASK_ULL(52, 36)
+#define HISI_PCIE_TRIG_MODE_M		GENMASK_ULL(53, 53)
+#define HISI_PCIE_TRIG_M		GENMASK_ULL(59, 56)
+
+#define HISI_PCIE_MAX_COUNTERS		8
+#define HISI_PCIE_REG_STEP		8
+#define HISI_PCIE_EVENT_MAX		0xa2
+#define HISI_PCIE_SUBEVENT_MAX		0x20
+#define HISI_PCIE_THR_MAX_VAL		10
+#define HISI_PCIE_TRIG_MAX_VAL		10
+#define HISI_PCIE_COUNTER_BITS		64
+#define HISI_PCIE_MAX_PERIOD		BIT_ULL(63)
+
+struct hisi_pcie_pmu {
+	struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
+	struct hlist_node node;
+	struct pci_dev *pdev;
+	struct pmu pmu;
+	void __iomem *base;
+	cpumask_t cpumask;
+	int irq;
+	u32 identifier;
+	/* Minimum and maximum bdf of root ports monitored by PMU */
+	u16 bdf_min;
+	u16 bdf_max;
+};
+
+#define to_pcie_pmu(p)  (container_of((p), struct hisi_pcie_pmu, pmu))
+#define GET_PCI_DEVFN(bdf)  ((bdf) & 0xff)
+
+#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)       \
+	static inline u64 hisi_pcie_get_##_name(struct perf_event *event)  \
+	{                                                             \
+		return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
+	}							\
+
+HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
+HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
+HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
+HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
+HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
+HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
+HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
+HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
+
+#define HISI_PCIE_CHECK_EVENTS(name, list)             \
+	static inline bool is_##name##_event(u32 idx)                  \
+	{                                                                   \
+		if ((idx >= list[0] && idx <= list[1]) || idx == list[2])  \
+			return true;                                        \
+		return false;                                               \
+	}
+
+/*
+ * The first element of event list is minimum index of TL-layer events
+ * and the second element is maximum index. The third element is index
+ * of a DL-layer event.
+ */
+static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
+static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
+static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
+static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
+
+HISI_PCIE_CHECK_EVENTS(bw, bw_events_list);
+HISI_PCIE_CHECK_EVENTS(latency, latency_events_list);
+HISI_PCIE_CHECK_EVENTS(bus_util, bus_util_events_list);
+HISI_PCIE_CHECK_EVENTS(buf_util, buf_util_events_list);
+
+static ssize_t hisi_pcie_cpumask_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return cpumap_print_to_pagebuf(true, buf, &pcie_pmu->cpumask);
+}
+
+static ssize_t hisi_pcie_identifier_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
+}
+
+static ssize_t hisi_pcie_bus_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
+}
+
+static void hisi_pcie_parse_data(struct hisi_pcie_pmu *pcie_pmu, u32 reg_off,
+			       u16 *arg0, u16 *arg1)
+{
+	u32 val = readl(pcie_pmu->base + reg_off);
+
+	*arg0 = val & 0xffff;
+	*arg1 = (val & 0xffff0000) >> 16;
+}
+
+static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
+{
+	return offset + HISI_PCIE_REG_STEP * idx;
+}
+
+static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readl(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u32 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writel(val, pcie_pmu->base + offset);
+}
+
+static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readq(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u64 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writeq(val, pcie_pmu->base + offset);
+}
+
+static u64 hisi_pcie_pmu_get_event(struct perf_event *event)
+{
+	return FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
+	       FIELD_PREP(HISI_PCIE_SUBEVENT_M, hisi_pcie_get_subevent(event));
+}
+
+static u64 hisi_pcie_pmu_get_target(struct perf_event *event)
+{
+	u64 port, val;
+
+	port = hisi_pcie_get_port(event);
+	if (port) {
+		val = FIELD_PREP(HISI_PCIE_TARGET_M, port);
+	} else {
+		val = FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
+		val |= HISI_PCIE_TARGET_EN;
+	}
+
+	return val;
+}
+
+static u64 hisi_pcie_pmu_get_trigger(struct perf_event *event)
+{
+	u64 trig_len, val;
+
+	trig_len = hisi_pcie_get_trig_len(event);
+	if (!trig_len)
+		return 0;
+
+	val = FIELD_PREP(HISI_PCIE_TRIG_M, trig_len);
+	val |= FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
+			  hisi_pcie_get_trig_mode(event));
+	val |= HISI_PCIE_TRIG_EN;
+
+	return val;
+}
+
+static u64 hisi_pcie_pmu_get_thr(struct perf_event *event)
+{
+	u64 thr_len, val;
+
+	thr_len = hisi_pcie_get_thr_len(event);
+	if (!thr_len)
+		return 0;
+
+	val = FIELD_PREP(HISI_PCIE_THR_M, thr_len);
+	val |= FIELD_PREP(HISI_PCIE_THR_MODE_M, hisi_pcie_get_thr_mode(event));
+	val |= HISI_PCIE_THR_EN;
+
+	return val;
+}
+
+static void hisi_pcie_pmu_config_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = HISI_PCIE_DEFAULT_SET;
+	val |= hisi_pcie_pmu_get_event(event);
+	val |= hisi_pcie_pmu_get_target(event);
+	val |= hisi_pcie_pmu_get_trigger(event);
+	val |= hisi_pcie_pmu_get_thr(event);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu, u16 bdf)
+{
+	return bdf <= pcie_pmu->bdf_max && bdf >= pcie_pmu->bdf_min;
+}
+
+static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu *pcie_pmu,
+					    u32 bdf)
+{
+	struct pci_dev *root_port, *pdev;
+
+	pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
+					   PCI_BUS_NUM(bdf),
+					   GET_PCI_DEVFN(bdf));
+	if (!pdev)
+		return false;
+
+	root_port = pcie_find_root_port(pdev);
+	if (!root_port)
+		return false;
+
+	pci_dev_put(pdev);
+	return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
+}
+
+static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
+				       struct hisi_pcie_pmu *pcie_pmu)
+{
+	u32 subev_idx = hisi_pcie_get_subevent(event);
+	u32 event_idx = hisi_pcie_get_event(event);
+	u32 requester_id = hisi_pcie_get_bdf(event);
+
+	if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
+	    event_idx > HISI_PCIE_EVENT_MAX) {
+		pci_err(pcie_pmu->pdev,
+			"Max event index and max subevent index is: %d, %d.\n",
+			HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
+		return false;
+	}
+
+	if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
+		return false;
+
+	if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
+		return false;
+
+	if (requester_id) {
+		if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id)) {
+			pci_err(pcie_pmu->pdev, "Invalid requester id.\n");
+			return false;
+		}
+	}
+
+	return true;
+}
+
+static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
+{
+	struct perf_event *sibling, *leader = event->group_leader;
+	int counters = 1;
+
+	if (!is_software_event(leader)) {
+		if (leader->pmu != event->pmu)
+			return false;
+
+		if (leader != event)
+			counters++;
+	}
+
+	for_each_sibling_event(sibling, event->group_leader) {
+		if (is_software_event(sibling))
+			continue;
+
+		if (sibling->pmu != event->pmu)
+			return false;
+
+		counters++;
+	}
+
+	return counters <= HISI_PCIE_MAX_COUNTERS;
+}
+
+static int hisi_pcie_pmu_event_init(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+
+	event->cpu = cpumask_first(&pcie_pmu->cpumask);
+
+	if (event->attr.type != event->pmu->type)
+		return -ENOENT;
+
+	/* Sampling is not supported. */
+	if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
+		return -EOPNOTSUPP;
+
+	/* Per-task mode is not supported. */
+	if (event->cpu < 0)
+		return -EINVAL;
+
+	if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
+		pci_err(pcie_pmu->pdev, "Invalid filter!\n");
+		return -EINVAL;
+	}
+
+	if (!hisi_pcie_pmu_validate_event_group(event))
+		return -EINVAL;
+
+	return 0;
+}
+
+static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 val,
+				      u64 val_ext)
+{
+#define CONVERT_DW_TO_BYTE(x)	(sizeof(u32) * (x))
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
+	u32 idx = hisi_pcie_get_event(event);
+
+	if (!val_ext)
+		return 0;
+
+	/*
+	 * The bandwidth, latency, bus utilization and buffer occupancy
+	 * are obtained by the (COMMON_COUNTER and EXT_COUNTER). And other
+	 * features are obtained by COMMON_COUNTER.
+	 */
+	if (is_bw_event(idx)) {
+		if (!val_ext / 1000)
+			return 0;
+
+		/* Process data to set unit of bandwidth as "Byte/ms". */
+		return (CONVERT_DW_TO_BYTE(val)) / (val_ext / 1000);
+	}
+
+	if (is_latency_event(idx))
+		/* Process data to set unit of latency as "us". */
+		return (val * us_per_cycle) / val_ext;
+
+	if (is_bus_util_event(idx))
+		return (val * us_per_cycle) / val_ext;
+
+	if (is_buf_util_event(idx))
+		return val / (val_ext * us_per_cycle);
+
+	return val;
+}
+
+static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 *cnt,
+				       u64 *cnt_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	*cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
+	*cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
+}
+
+static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 val,
+					u64 val_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
+}
+
+static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
+{
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		if (!pcie_pmu->hw_events[idx])
+			return idx;
+	}
+
+	return -EINVAL;
+}
+
+static void hisi_pcie_pmu_read(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
+	u64 new_cnt_ext, prev_cnt_ext;
+	u64 new_cnt, prev_cnt, delta;
+
+	hwc_ext = &hwc->extra_reg;
+	do {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
+	} while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
+				 new_cnt) != prev_cnt);
+
+	hwc_ext->config = new_cnt_ext;
+
+	delta = hisi_pcie_pmu_process_data(event, new_cnt - prev_cnt,
+					   new_cnt_ext - prev_cnt_ext);
+	local64_add(delta, &event->count);
+}
+
+static void hisi_pcie_pmu_set_period(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 val = BIT_ULL(HISI_PCIE_COUNTER_BITS - 1);
+
+	hwc_ext = &hwc->extra_reg;
+	local64_set(&hwc->prev_count, val);
+	hwc_ext->config = 0;
+	hisi_pcie_pmu_write_counter(event, val, 0);
+}
+
+static void hisi_pcie_pmu_enable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					 struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val |= HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_disable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					  struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val &= ~HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_enable_int(struct hisi_pcie_pmu *pcie_pmu,
+				     struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 0);
+}
+
+static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
+				      struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
+}
+
+static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
+					struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_RESET_CNT);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+static void hisi_pcie_pmu_start(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 prev_cnt, prev_cnt_ext;
+
+	hwc_ext = &hwc->extra_reg;
+	if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
+		return;
+
+	WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
+	hwc->state = 0;
+
+	hisi_pcie_pmu_config_filter(event);
+	hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_set_period(event);
+
+	if (flags & PERF_EF_RELOAD) {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
+	}
+
+	perf_event_update_userpage(event);
+}
+
+static void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_read(event);
+	hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_clear_filter(event);
+	WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
+	hwc->state |= PERF_HES_STOPPED;
+
+	if (hwc->state & PERF_HES_UPTODATE)
+		return;
+
+	hwc->state |= PERF_HES_UPTODATE;
+}
+
+static int hisi_pcie_pmu_add(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	int idx;
+
+	hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+	idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
+	if (idx < 0)
+		return idx;
+
+	hwc->idx = idx;
+	pcie_pmu->hw_events[idx] = event;
+
+	/* Reset PMC to avoid interference caused by previous statistic. */
+	hisi_pcie_pmu_reset_counter(pcie_pmu, hwc);
+
+	if (flags & PERF_EF_START)
+		hisi_pcie_pmu_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+static void hisi_pcie_pmu_del(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_stop(event, PERF_EF_UPDATE);
+	pcie_pmu->hw_events[hwc->idx] = NULL;
+	perf_event_update_userpage(event);
+}
+
+static void hisi_pcie_pmu_enable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+	int num;
+
+	for (num = 0; num < HISI_PCIE_MAX_COUNTERS; num++) {
+		if (pcie_pmu->hw_events[num])
+			break;
+	}
+
+	if (num == HISI_PCIE_MAX_COUNTERS)
+		return;
+
+	writel(HISI_PCIE_GLOBAL_EN, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+static void hisi_pcie_pmu_disable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+
+	writel(HISI_PCIE_GLOBAL_NONE, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+static irqreturn_t hisi_pcie_pmu_irq(int irq, void *data)
+{
+	struct hisi_pcie_pmu *pcie_pmu = data;
+	irqreturn_t ret = IRQ_NONE;
+	struct perf_event *event;
+	u32 overflown;
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		overflown = hisi_pcie_pmu_readl(pcie_pmu, HISI_PCIE_INT_STAT,
+						idx);
+		if (!overflown)
+			continue;
+
+		/* Clear status of interrupt. */
+		hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_STAT, idx, 1);
+		event = pcie_pmu->hw_events[idx];
+		if (!event)
+			continue;
+
+		hisi_pcie_pmu_read(event);
+		hisi_pcie_pmu_set_period(event);
+		ret = IRQ_HANDLED;
+	}
+
+	return ret;
+}
+
+static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
+				      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int irq, ret;
+
+	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
+	if (ret < 0) {
+		pci_err(pdev, "Failed to enable MSI vectors, ret = %d!\n", ret);
+		return ret;
+	}
+
+	irq = pci_irq_vector(pdev, 0);
+	ret = request_irq(irq, hisi_pcie_pmu_irq, IRQF_SHARED, "hisi_pcie_pmu",
+			  pcie_pmu);
+	if (ret) {
+		pci_err(pdev, "Failed to register irq, ret = %d!\n", ret);
+		pci_free_irq_vectors(pdev);
+		return ret;
+	}
+
+	pcie_pmu->irq = irq;
+
+	return 0;
+}
+
+static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
+					 struct hisi_pcie_pmu *pcie_pmu)
+{
+	free_irq(pcie_pmu->irq, pcie_pmu);
+	pci_free_irq_vectors(pdev);
+}
+
+static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+
+	if (cpumask_empty(&pcie_pmu->cpumask)) {
+		cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
+		WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
+	}
+
+	return 0;
+}
+
+static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+	unsigned int target;
+
+	if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))
+		return 0;
+
+	/* Choose a new CPU from all online cpus. */
+	target = cpumask_any_but(cpu_online_mask, cpu);
+	if (target >= nr_cpu_ids)
+		return 0;
+
+	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
+	WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
+
+	return 0;
+}
+
+/*
+ * Events with the "dl" suffix in their names count performance in DL layer,
+ * otherswise, events count performance in TL layer.
+ */
+static struct attribute *hisi_pcie_pmu_events_attr[] = {
+	HISI_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
+	HISI_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
+	HISI_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
+	HISI_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
+	HISI_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
+	HISI_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
+	HISI_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
+	HISI_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
+	HISI_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
+	HISI_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_events_group = {
+	.name = "events",
+	.attrs = hisi_pcie_pmu_events_attr,
+};
+
+static struct attribute *hisi_pcie_pmu_format_attr[] = {
+	HISI_PMU_FORMAT_ATTR(event, "config:0-7"),
+	HISI_PMU_FORMAT_ATTR(subevent, "config:8-15"),
+	HISI_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
+	HISI_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
+	HISI_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
+	HISI_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
+	HISI_PMU_FORMAT_ATTR(port, "config2:0-15"),
+	HISI_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_format_group = {
+	.name = "format",
+	.attrs = hisi_pcie_pmu_format_attr,
+};
+
+static struct device_attribute hisi_pcie_pmu_bus_attr =
+	__ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
+	&hisi_pcie_pmu_bus_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
+	.attrs = hisi_pcie_pmu_bus_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_cpumask_attr =
+	__ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
+	&hisi_pcie_pmu_cpumask_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
+	.attrs = hisi_pcie_pmu_cpumask_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_identifier_attr =
+	__ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
+	&hisi_pcie_pmu_identifier_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
+	.attrs = hisi_pcie_pmu_identifier_attrs,
+};
+
+static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
+	&hisi_pcie_pmu_events_group,
+	&hisi_pcie_pmu_format_group,
+	&hisi_pcie_pmu_bus_attr_group,
+	&hisi_pcie_pmu_cpumask_attr_group,
+	&hisi_pcie_pmu_identifier_attr_group,
+	NULL
+};
+
+static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
+			     struct hisi_pcie_pmu *pcie_pmu)
+{
+	u16 sicl_id, device_id;
+	char *name;
+
+	pcie_pmu->base = pci_ioremap_bar(pdev, 2);
+	if (!pcie_pmu->base) {
+		pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
+		return -ENOMEM;
+	}
+
+	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_BDF, &pcie_pmu->bdf_min,
+			   &pcie_pmu->bdf_max);
+	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
+			     &sicl_id);
+	name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+			      "hisi_pcie%u_%u", sicl_id, device_id);
+	if (!name) {
+		pci_err(pdev, "Failed to allocate name for PMU.\n");
+		return -ENOMEM;
+	}
+
+	pcie_pmu->pdev = pdev;
+	pcie_pmu->identifier = readl(pcie_pmu->base + HISI_PCIE_REG_VERSION);
+	pcie_pmu->pmu = (struct pmu) {
+		.name		= name,
+		.module		= THIS_MODULE,
+		.event_init	= hisi_pcie_pmu_event_init,
+		.pmu_enable	= hisi_pcie_pmu_enable,
+		.pmu_disable	= hisi_pcie_pmu_disable,
+		.add		= hisi_pcie_pmu_add,
+		.del		= hisi_pcie_pmu_del,
+		.start		= hisi_pcie_pmu_start,
+		.stop		= hisi_pcie_pmu_stop,
+		.read		= hisi_pcie_pmu_read,
+		.task_ctx_nr	= perf_invalid_context,
+		.attr_groups	= hisi_pcie_pmu_attr_groups,
+		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
+	};
+
+	return 0;
+}
+
+static int hisi_pcie_init_pmu(struct pci_dev *pdev,
+			      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int ret;
+
+	ret = hisi_pcie_alloc_pmu(pdev, pcie_pmu);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_pmu_irq_register(pdev, pcie_pmu);
+	if (ret)
+		goto err_set_pmu_fail;
+
+	ret = cpuhp_state_add_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				       &pcie_pmu->node);
+	if (ret) {
+		pci_err(pdev, "Failed to register hotplug, ret = %d.\n", ret);
+		goto err_irq_unregister;
+	}
+
+	ret = perf_pmu_register(&pcie_pmu->pmu, pcie_pmu->pmu.name, -1);
+	if (ret) {
+		pci_err(pdev, "Failed to register PCIe PMU, ret = %d.\n", ret);
+		goto err_hotplug_unregister;
+	}
+
+	return ret;
+
+err_hotplug_unregister:
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+
+err_irq_unregister:
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+
+err_set_pmu_fail:
+	iounmap(pcie_pmu->base);
+
+	return ret;
+}
+
+static void hisi_pcie_uninit_pmu(struct pci_dev *pdev,
+				 struct hisi_pcie_pmu *pcie_pmu)
+{
+	perf_pmu_unregister(&pcie_pmu->pmu);
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+	iounmap(pcie_pmu->base);
+}
+
+static int hisi_pcie_init_dev(struct pci_dev *pdev)
+{
+	int ret;
+
+	ret = pci_enable_device(pdev);
+	if (ret) {
+		pci_err(pdev, "Failed to enable pci device, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
+	if (ret < 0) {
+		pci_err(pdev, "Failed to request pci mem regions, ret = %d.\n",
+			ret);
+		pci_disable_device(pdev);
+		return ret;
+	}
+
+	pci_set_master(pdev);
+
+	return 0;
+}
+
+static void hisi_pcie_uninit_dev(struct pci_dev *pdev)
+{
+	pci_clear_master(pdev);
+	pci_release_mem_regions(pdev);
+	pci_disable_device(pdev);
+}
+
+static int hisi_pcie_pmu_probe(struct pci_dev *pdev,
+			       const struct pci_device_id *id)
+{
+	struct hisi_pcie_pmu *pcie_pmu;
+	int ret;
+
+	pcie_pmu = devm_kzalloc(&pdev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
+	if (!pcie_pmu)
+		return -ENOMEM;
+
+	ret = hisi_pcie_init_dev(pdev);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_init_pmu(pdev, pcie_pmu);
+	if (ret)
+		hisi_pcie_uninit_dev(pdev);
+
+	pci_set_drvdata(pdev, pcie_pmu);
+
+	return ret;
+}
+
+static void hisi_pcie_pmu_remove(struct pci_dev *pdev)
+{
+	hisi_pcie_uninit_pmu(pdev, pci_get_drvdata(pdev));
+	hisi_pcie_uninit_dev(pdev);
+	pci_set_drvdata(pdev, NULL);
+}
+
+static const struct pci_device_id hisi_pcie_pmu_ids[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12d) },
+	{ 0, }
+};
+MODULE_DEVICE_TABLE(pci, hisi_pcie_pmu_ids);
+
+static struct pci_driver hisi_pcie_pmu_driver = {
+	.name = "hisi_pcie_pmu",
+	.id_table = hisi_pcie_pmu_ids,
+	.probe = hisi_pcie_pmu_probe,
+	.remove = hisi_pcie_pmu_remove,
+};
+
+static int __init hisi_pcie_module_init(void)
+{
+	int ret;
+
+	ret = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				      "AP_PERF_ARM_HISI_PCIE_PMU_ONLINE",
+				      hisi_pcie_pmu_online_cpu,
+				      hisi_pcie_pmu_offline_cpu);
+	if (ret) {
+		pr_err("Failed to setup PCIE PMU hotplug, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_register_driver(&hisi_pcie_pmu_driver);
+	if (ret)
+		cpuhp_remove_multi_state(
+				CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+
+	return ret;
+}
+module_init(hisi_pcie_module_init);
+
+static void __exit hisi_pcie_module_exit(void)
+{
+	pci_unregister_driver(&hisi_pcie_pmu_driver);
+	cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+}
+module_exit(hisi_pcie_module_exit);
+
+MODULE_DESCRIPTION("HiSilicon PCIe PMU driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Qi Liu <liuqi115 at huawei.com>");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 113f51f..c17861a 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -174,6 +174,7 @@ enum cpuhp_state {
 	CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
+	CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
 	CPUHP_AP_PERF_ARM_L2X0_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
-- 
2.8.1



From anshuman.khandual at arm.com  Fri Apr  9 10:12:39 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Fri, 9 Apr 2021 14:42:39 +0530
Subject: [PATCH -next] coresight: trbe: Fix return value check in
 arm_trbe_register_coresight_cpu()
In-Reply-To: <20210409012213.3664473-1-weiyongjun1@huawei.com>
References: <20210409012213.3664473-1-weiyongjun1@huawei.com>
Message-ID: <51e3225a-1abb-1c52-93cc-c6935f0c4b52@arm.com>



On 4/9/21 6:52 AM, Wei Yongjun wrote:
> In case of error, the function devm_kasprintf() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test.

Right.

> 
> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")

Again, dont think this warrants "Fixes:" tag as there were no
functional problem to be fixed here.

> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
> ---
>  drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 5ce239875c98..176868496879 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -871,7 +871,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
>  
>  	dev = &cpudata->drvdata->pdev->dev;
>  	desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu);
> -	if (IS_ERR(desc.name))
> +	if (!desc.name)
>  		goto cpu_clear;
>  
>  	desc.type = CORESIGHT_DEV_TYPE_SINK;
>

LGTM.


From Jonathan.Cameron at Huawei.com  Fri Apr  9 10:17:25 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 9 Apr 2021 10:17:25 +0100
Subject: [RFC PATCH 01/10] genirq: Add chip flag to denote automatic IRQ
 (un)masking
In-Reply-To: <20210408154326.3988781-2-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
 <20210408154326.3988781-2-valentin.schneider@arm.com>
Message-ID: <20210409101725.00007271@Huawei.com>

On Thu, 8 Apr 2021 16:43:17 +0100
Valentin Schneider <valentin.schneider at arm.com> wrote:

> Some IRQ chips such as the Arm GICs automagically mask / unmask an
> IRQ during the handling of said IRQ. This renders further mask / unmask
> operations within the flow handlers redundant, which we do want to leverage
> as masking by itself is not cheap (Distributor access via MMIO for GICs).
> 
> This is different from having a chip->irq_mask_ack() callback as this
> masking is:
> - inherent to the chip->irq_ack() and *cannot* be omitted
> - a *different* masking state than chip->irq_mask() (chip->irq_mask() is
>   idempotent, chip->irq_ack() really isn't)
> 
> Add a chip flag, IRQCHIP_AUTOMASKS_FLOW, to denote chips with such
> behaviour. Add a new IRQ data flag, IRQD_IRQ_FLOW_MASKED, to keep this
> flow-induced mask state separate from regular mask / unmask operations
> (IRQD_IRQ_MASKED).
> 
> Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
Hi Valentin,

One totally trivial thing noticed whilst reading.

> ---
>  include/linux/irq.h    | 10 ++++++++++
>  kernel/irq/chip.c      |  5 +++++
>  kernel/irq/debugfs.c   |  2 ++
>  kernel/irq/internals.h |  5 +++++
>  4 files changed, 22 insertions(+)
> 
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index bee82809107c..580b1b6b1799 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -219,6 +219,8 @@ struct irq_data {
>   *				  irq_chip::irq_set_affinity() when deactivated.
>   * IRQD_IRQ_ENABLED_ON_SUSPEND	- Interrupt is enabled on suspend by irq pm if
>   *				  irqchip have flag IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
> + * IRQD_IRQ_FLOW_MASKED         - Interrupt is masked by ACK. Only EOI can
> + *                                clear this.

Nitpick of the day : Seems text above is using tabs for white space blocks
whereas you have used spaces. Make it consistent.
It's not consistent in the file so I guess you could clean that up, or
just go with making it consistent in this block.

>   */
>  enum {
>  	IRQD_TRIGGER_MASK		= 0xf,
> @@ -245,6 +247,7 @@ enum {
>  	IRQD_HANDLE_ENFORCE_IRQCTX	= (1 << 28),
>  	IRQD_AFFINITY_ON_ACTIVATE	= (1 << 29),
>  	IRQD_IRQ_ENABLED_ON_SUSPEND	= (1 << 30),
> +	IRQD_IRQ_FLOW_MASKED            = (1 << 31),
>  };
>  
>  #define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
> @@ -349,6 +352,11 @@ static inline bool irqd_irq_masked(struct irq_data *d)
>  	return __irqd_to_state(d) & IRQD_IRQ_MASKED;
>  }
>  
> +static inline bool irqd_irq_flow_masked(struct irq_data *d)
> +{
> +	return __irqd_to_state(d) & IRQD_IRQ_FLOW_MASKED;
> +}
> +
>  static inline bool irqd_irq_inprogress(struct irq_data *d)
>  {
>  	return __irqd_to_state(d) & IRQD_IRQ_INPROGRESS;
> @@ -567,6 +575,7 @@ struct irq_chip {
>   * IRQCHIP_SUPPORTS_NMI:              Chip can deliver NMIs, only for root irqchips
>   * IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND:  Invokes __enable_irq()/__disable_irq() for wake irqs
>   *                                    in the suspend path if they are in disabled state
> + * IRQCHIP_AUTOMASKS_FLOW:            chip->ack() masks and chip->eoi() unmasks
>   */
>  enum {
>  	IRQCHIP_SET_TYPE_MASKED			= (1 <<  0),
> @@ -579,6 +588,7 @@ enum {
>  	IRQCHIP_SUPPORTS_LEVEL_MSI		= (1 <<  7),
>  	IRQCHIP_SUPPORTS_NMI			= (1 <<  8),
>  	IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND	= (1 <<  9),
> +	IRQCHIP_AUTOMASKS_FLOW                  = (1 <<  10),
>  };
>  
>  #include <linux/irqdesc.h>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 8cc8e5713287..18c3b0e1568a 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -173,6 +173,11 @@ static void irq_state_clr_masked(struct irq_desc *desc)
>  	irqd_clear(&desc->irq_data, IRQD_IRQ_MASKED);
>  }
>  
> +static void irq_state_clr_flow_masked(struct irq_desc *desc)
> +{
> +	irqd_clear(&desc->irq_data, IRQD_IRQ_FLOW_MASKED);
> +}
> +
>  static void irq_state_clr_started(struct irq_desc *desc)
>  {
>  	irqd_clear(&desc->irq_data, IRQD_IRQ_STARTED);
> diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
> index e4cff358b437..3ae83622d701 100644
> --- a/kernel/irq/debugfs.c
> +++ b/kernel/irq/debugfs.c
> @@ -58,6 +58,7 @@ static const struct irq_bit_descr irqchip_flags[] = {
>  	BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
>  	BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
>  	BIT_MASK_DESCR(IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND),
> +	BIT_MASK_DESCR(IRQCHIP_AUTOMASKS_FLOW),
>  };
>  
>  static void
> @@ -103,6 +104,7 @@ static const struct irq_bit_descr irqdata_states[] = {
>  	BIT_MASK_DESCR(IRQD_IRQ_STARTED),
>  	BIT_MASK_DESCR(IRQD_IRQ_DISABLED),
>  	BIT_MASK_DESCR(IRQD_IRQ_MASKED),
> +	BIT_MASK_DESCR(IRQD_IRQ_FLOW_MASKED),
>  	BIT_MASK_DESCR(IRQD_IRQ_INPROGRESS),
>  
>  	BIT_MASK_DESCR(IRQD_PER_CPU),
> diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
> index 54363527feea..b6c1cceddec0 100644
> --- a/kernel/irq/internals.h
> +++ b/kernel/irq/internals.h
> @@ -245,6 +245,11 @@ static inline void irq_state_set_masked(struct irq_desc *desc)
>  	irqd_set(&desc->irq_data, IRQD_IRQ_MASKED);
>  }
>  
> +static inline void irq_state_set_flow_masked(struct irq_desc *desc)
> +{
> +	irqd_set(&desc->irq_data, IRQD_IRQ_FLOW_MASKED);
> +}
> +
>  #undef __irqd_to_state
>  
>  static inline void __kstat_incr_irqs_this_cpu(struct irq_desc *desc)



From xiao33522 at qq.com  Fri Apr  9 10:21:49 2021
From: xiao33522 at qq.com (xiao33522 at qq.com)
Date: Fri,  9 Apr 2021 17:21:49 +0800
Subject: [PATCH] net: Fix comment errors
Message-ID: <tencent_801704F87BFD7D6AC6353210D4DB31DBD806@qq.com>

From: xiaolinkui <xiaolinkui at kylinos.cn>

clk_scr_i should be clk_csr_i.

Signed-off-by: xiaolinkui <xiaolinkui at kylinos.cn>
---
 include/linux/stmmac.h         | 12 ++++++------
 include/linux/sxgbe_platform.h | 12 ++++++------
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index a302982de2d7..19e4344283df 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -28,12 +28,12 @@
  * This could also be configured at run time using CPU freq framework. */
 
 /* MDC Clock Selection define*/
-#define	STMMAC_CSR_60_100M	0x0	/* MDC = clk_scr_i/42 */
-#define	STMMAC_CSR_100_150M	0x1	/* MDC = clk_scr_i/62 */
-#define	STMMAC_CSR_20_35M	0x2	/* MDC = clk_scr_i/16 */
-#define	STMMAC_CSR_35_60M	0x3	/* MDC = clk_scr_i/26 */
-#define	STMMAC_CSR_150_250M	0x4	/* MDC = clk_scr_i/102 */
-#define	STMMAC_CSR_250_300M	0x5	/* MDC = clk_scr_i/122 */
+#define	STMMAC_CSR_60_100M	0x0	/* MDC = clk_csr_i/42 */
+#define	STMMAC_CSR_100_150M	0x1	/* MDC = clk_csr_i/62 */
+#define	STMMAC_CSR_20_35M	0x2	/* MDC = clk_csr_i/16 */
+#define	STMMAC_CSR_35_60M	0x3	/* MDC = clk_csr_i/26 */
+#define	STMMAC_CSR_150_250M	0x4	/* MDC = clk_csr_i/102 */
+#define	STMMAC_CSR_250_300M	0x5	/* MDC = clk_csr_i/122 */
 
 /* MTL algorithms identifiers */
 #define MTL_TX_ALGORITHM_WRR	0x0
diff --git a/include/linux/sxgbe_platform.h b/include/linux/sxgbe_platform.h
index 966146f7267a..d56bbd32e966 100644
--- a/include/linux/sxgbe_platform.h
+++ b/include/linux/sxgbe_platform.h
@@ -13,12 +13,12 @@
 #include <linux/phy.h>
 
 /* MDC Clock Selection define*/
-#define SXGBE_CSR_100_150M	0x0	/* MDC = clk_scr_i/62 */
-#define SXGBE_CSR_150_250M	0x1	/* MDC = clk_scr_i/102 */
-#define SXGBE_CSR_250_300M	0x2	/* MDC = clk_scr_i/122 */
-#define SXGBE_CSR_300_350M	0x3	/* MDC = clk_scr_i/142 */
-#define SXGBE_CSR_350_400M	0x4	/* MDC = clk_scr_i/162 */
-#define SXGBE_CSR_400_500M	0x5	/* MDC = clk_scr_i/202 */
+#define SXGBE_CSR_100_150M	0x0	/* MDC = clk_csr_i/62 */
+#define SXGBE_CSR_150_250M	0x1	/* MDC = clk_csr_i/102 */
+#define SXGBE_CSR_250_300M	0x2	/* MDC = clk_csr_i/122 */
+#define SXGBE_CSR_300_350M	0x3	/* MDC = clk_csr_i/142 */
+#define SXGBE_CSR_350_400M	0x4	/* MDC = clk_csr_i/162 */
+#define SXGBE_CSR_400_500M	0x5	/* MDC = clk_csr_i/202 */
 
 /* Platfrom data for platform device structure's
  * platform_data field
-- 
2.17.1



From lkp at intel.com  Fri Apr  9 10:24:01 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 09 Apr 2021 17:24:01 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS b9a9786a13ea158ee3b23614217f2e3158178421
Message-ID: <60701d31.K1nLoAAoVu9BkkEn%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: b9a9786a13ea158ee3b23614217f2e3158178421  Merge tag 'omap-for-v5.12/fixes-rc6-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes

elapsed time: 759m

configs tested: 70
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
m68k                          hp300_defconfig
sh                          polaris_defconfig
arm                          gemini_defconfig
sparc                               defconfig
arm                        spear3xx_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From Fengquan.Chen at mediatek.com  Fri Apr  9 10:22:42 2021
From: Fengquan.Chen at mediatek.com (Fengquan Chen)
Date: Fri, 9 Apr 2021 17:22:42 +0800
Subject: [PATCH] [v4,
 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq clear
 flow on shutdown
In-Reply-To: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>
References: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>
Message-ID: <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>

mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
clear any pending systimer irq when shutdown to avoid suspend aborted
due to timer irq pending

Also as for systimer in mediatek socs, there must be firstly enable
timer before clear systimer irq

Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer")
Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>

---
 drivers/clocksource/timer-mediatek.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 9318edc..6461fd3 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -60,9 +60,9 @@
  * SYST_CON_EN: Clock enable. Shall be set to
  *   - Start timer countdown.
  *   - Allow timeout ticks being updated.
- *   - Allow changing interrupt functions.
+ *   - Allow changing interrupt status,like clear irq pending.
  *
- * SYST_CON_IRQ_EN: Set to allow interrupt.
+ * SYST_CON_IRQ_EN: Set to enable interrupt.
  *
  * SYST_CON_IRQ_CLR: Set to clear interrupt.
  */
@@ -75,6 +75,7 @@
 static void mtk_syst_ack_irq(struct timer_of *to)
 {
 	/* Clear and disable interrupt */
+	writel(SYST_CON_EN, SYST_CON_REG(to));
 	writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
 }
 
@@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
 
 static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
 {
+	/* Clear any irq */
+	mtk_syst_ack_irq(to_timer_of(clkevt));
+
 	/* Disable timer */
 	writel(0, SYST_CON_REG(to_timer_of(clkevt)));
 
-- 
1.8.1.1.dirty

From roger.lu at mediatek.com  Fri Apr  9 10:28:27 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:27 +0800
Subject: [PATCH v15 6/7] arm64: dts: mt8192: add svs device information
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-7-roger.lu@mediatek.com>

add compitable/reg/irq/clock/efuse/reset setting in svs node

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 34 ++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index fe24cc66ff7a..e9816a56d87b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -270,6 +270,14 @@
 			compatible = "mediatek,mt8192-infracfg", "syscon";
 			reg = <0 0x10001000 0 0x1000>;
 			#clock-cells = <1>;
+
+			infracfg_rst: reset-controller {
+				compatible = "mediatek,infra-reset", "ti,syscon-reset";
+				#reset-cells = <1>;
+				ti,reset-bits = <
+					0x150 5 0x154 5 0 0     (ASSERT_SET | DEASSERT_SET | STATUS_NONE) /* 0: svs */
+				>;
+			};
 		};
 
 		pericfg: syscon at 10003000 {
@@ -564,6 +572,20 @@
 			status = "disabled";
 		};
 
+		svs: svs at 1100b000 {
+			compatible = "mediatek,mt8192-svs";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&infracfg CLK_INFRA_THERM>;
+			clock-names = "main";
+			nvmem-cells = <&svs_calibration>,
+				      <&lvts_e_data1>;
+			nvmem-cell-names = "svs-calibration-data",
+					   "t-calibration-data";
+			resets = <&infracfg_rst 0>;
+			reset-names = "svs_rst";
+		};
+
 		spi1: spi at 11010000 {
 			compatible = "mediatek,mt8192-spi",
 				     "mediatek,mt6765-spi";
@@ -681,6 +703,18 @@
 			#clock-cells = <1>;
 		};
 
+		efuse: efuse at 11c10000 {
+			compatible = "mediatek,efuse";
+			reg = <0 0x11c10000 0 0x1000>;
+
+			lvts_e_data1: data1 {
+				reg = <0x1C0 0x58>;
+			};
+			svs_calibration: calib at 580 {
+				reg = <0x580 0x68>;
+			};
+		};
+
 		i2c3: i2c3 at 11cb0000 {
 			compatible = "mediatek,mt8192-i2c";
 			reg = <0 0x11cb0000 0 0x1000>,
-- 
2.18.0

From roger.lu at mediatek.com  Fri Apr  9 10:28:26 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:26 +0800
Subject: [PATCH v15 5/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-6-roger.lu@mediatek.com>

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/soc/mediatek/mtk-svs.yaml         | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index a855ced410f8..59342e627b67 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -22,6 +22,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt8183-svs
+      - mediatek,mt8192-svs
 
   reg:
     maxItems: 1
@@ -51,6 +52,13 @@ properties:
       - const: svs-calibration-data
       - const: t-calibration-data
 
+  resets:
+    maxItems: 1
+
+  reset-names:
+    items:
+      - const: svs_rst
+
 required:
   - compatible
   - reg
-- 
2.18.0

From roger.lu at mediatek.com  Fri Apr  9 10:28:22 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:22 +0800
Subject: [PATCH v15 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-2-roger.lu@mediatek.com>

Document the binding for enabling mtk svs on MediaTek SoC.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/soc/mediatek/mtk-svs.yaml        | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
new file mode 100644
index 000000000000..a855ced410f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Smart Voltage Scaling (SVS) Device Tree Bindings
+
+maintainers:
+  - Roger Lu <roger.lu at mediatek.com>
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Kevin Hilman <khilman at kernel.org>
+
+description: |+
+  The SVS engine is a piece of hardware which has several
+  controllers(banks) for calculating suitable voltage to
+  different power domains(CPU/GPU/CCI) according to
+  chip process corner, temperatures and other factors. Then DVFS
+  driver could apply SVS bank voltage to PMIC/Buck.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8183-svs
+
+  reg:
+    maxItems: 1
+    description: Address range of the MTK SVS controller.
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: Main clock for MTK SVS controller to work.
+
+  clock-names:
+    const: main
+
+  nvmem-cells:
+    minItems: 1
+    maxItems: 2
+    description:
+      Phandle to the calibration data provided by a nvmem device.
+    items:
+      - description: SVS efuse for SVS controller
+      - description: Thermal efuse for SVS controller
+
+  nvmem-cell-names:
+    items:
+      - const: svs-calibration-data
+      - const: t-calibration-data
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - nvmem-cells
+  - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8183-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        svs at 1100b000 {
+            compatible = "mediatek,mt8183-svs";
+            reg = <0 0x1100b000 0 0x1000>;
+            interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+            clocks = <&infracfg CLK_INFRA_THERM>;
+            clock-names = "main";
+            nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
+            nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
+        };
+    };
-- 
2.18.0

From nsaenzjulienne at suse.de  Fri Apr  9 10:28:48 2021
From: nsaenzjulienne at suse.de (Nicolas Saenz Julienne)
Date: Fri, 09 Apr 2021 11:28:48 +0200
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
 <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
 <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>
 <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>
Message-ID: <a046159f5feb2ad777a35f109a19edeb294c7027.camel@suse.de>

Hi Al,

On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
> Nicolas,
> 
> I got a better description of the failure and it looks like the bus
> clock needs to be limited to 300KHz for a 500MHz core clock.
> What's happening is that an internal reset sequence is needed after a
> command timeout and the reset signal needs to be asserted for at least
> 2 ticks of the bus clock. This is done using a 12 bit counter clocked
> by the core clock. That means a 500MHz core clock produces a 122KHz
> reset signal which is too fast for 2 ticks of the 200KHz bus clock
> (100KHz) but is okay for the 300KHz (150Khz) bus clock.

Thanks for the info. I'll work something out.

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/28329d49/attachment.sig>

From roger.lu at mediatek.com  Fri Apr  9 10:28:21 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:21 +0800
Subject: [PATCH v15 0/7] soc: mediatek: SVS: introduce MTK SVS
Message-ID: <20210409092828.23939-1-roger.lu@mediatek.com>

1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
After retrieving subsys device, SVS driver does device_link_add() to make sure probe/suspend callback priority.
3. SVS dts refers to reset controller [4] to help reset SVS HW.

#mt8183 SVS related patches
[1] https://patchwork.kernel.org/patch/11193513/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/20201013102358.22588-2-michael.kao at mediatek.com/
[3] https://patchwork.kernel.org/project/linux-mediatek/patch/20200306041345.259332-3-drinkcat at chromium.org/

#mt8192 SVS related patches
[1] https://patchwork.kernel.org/patch/11193513/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/20201223074944.2061-1-michael.kao at mediatek.com/
[3] https://lore.kernel.org/patchwork/patch/1360551/
[4] https://patchwork.kernel.org/project/linux-mediatek/patch/20200817030324.5690-5-crystal.guo at mediatek.com/

changes since v14:
- fix coverities
- call regulator_set_mode() after regulator_enable()
- save SVS registers into svsb->reg_data[SVSB_PHASE_ERROR] when svs_error_isr_handler() happens

Roger Lu (7):
  [v15,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
  [v15,2/7] arm64: dts: mt8183: add svs device information
  [v15,3/7] soc: mediatek: SVS: introduce MTK SVS engine
  [v15,4/7] soc: mediatek: SVS: add debug commands
  [v15,5/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
  [v15,6/7] arm64: dts: mt8192: add svs device information
  [v15,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver

 .../bindings/soc/mediatek/mtk-svs.yaml        |   92 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      |   18 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |   34 +
 drivers/soc/mediatek/Kconfig                  |   10 +
 drivers/soc/mediatek/Makefile                 |    1 +
 drivers/soc/mediatek/mtk-svs.c                | 2500 +++++++++++++++++
 6 files changed, 2655 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
 create mode 100644 drivers/soc/mediatek/mtk-svs.c


From Fengquan.Chen at mediatek.com  Fri Apr  9 10:22:41 2021
From: Fengquan.Chen at mediatek.com (Fengquan Chen)
Date: Fri, 9 Apr 2021 17:22:41 +0800
Subject: [v4,
 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq clear
 flow on shutdown
Message-ID: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>


Fengquan Chen (1):
  [v4, 1/1] clocksource/drivers/timer-mediatek: optimize systimer irq clear flow on shutdown

 drivers/clocksource/timer-mediatek.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
1.8.1.1.dirty

From roger.lu at mediatek.com  Fri Apr  9 10:28:25 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:25 +0800
Subject: [PATCH v15 4/7] soc: mediatek: SVS: add debug commands
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-5-roger.lu@mediatek.com>

The purpose of SVS is to help find the suitable voltages
for DVFS. Therefore, if SVS bank voltages are concerned
to be wrong, we can adjust SVS bank voltages by this patch.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 328 +++++++++++++++++++++++++++++++++
 1 file changed, 328 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 7d134d47f871..39f29d9e4fc7 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -6,6 +6,7 @@
 #include <linux/bits.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
+#include <linux/debugfs.h>
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
@@ -24,6 +25,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
+#include <linux/seq_file.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/thermal.h>
@@ -60,6 +62,39 @@
 #define SVSB_INTSTS_COMPLETE		0x1
 #define SVSB_INTSTS_CLEAN		0x00ffffff
 
+#define debug_fops_ro(name)						\
+	static int svs_##name##_debug_open(struct inode *inode,		\
+					   struct file *filp)		\
+	{								\
+		return single_open(filp, svs_##name##_debug_show,	\
+				   inode->i_private);			\
+	}								\
+	static const struct file_operations svs_##name##_debug_fops = {	\
+		.owner = THIS_MODULE,					\
+		.open = svs_##name##_debug_open,			\
+		.read = seq_read,					\
+		.llseek = seq_lseek,					\
+		.release = single_release,				\
+	}
+
+#define debug_fops_rw(name)						\
+	static int svs_##name##_debug_open(struct inode *inode,		\
+					   struct file *filp)		\
+	{								\
+		return single_open(filp, svs_##name##_debug_show,	\
+				   inode->i_private);			\
+	}								\
+	static const struct file_operations svs_##name##_debug_fops = {	\
+		.owner = THIS_MODULE,					\
+		.open = svs_##name##_debug_open,			\
+		.read = seq_read,					\
+		.write = svs_##name##_debug_write,			\
+		.llseek = seq_lseek,					\
+		.release = single_release,				\
+	}
+
+#define svs_dentry(name)	{__stringify(name), &svs_##name##_debug_fops}
+
 static DEFINE_SPINLOCK(mtk_svs_lock);
 
 /*
@@ -81,6 +116,7 @@ enum svsb_phase {
 	SVSB_PHASE_INIT01,
 	SVSB_PHASE_INIT02,
 	SVSB_PHASE_MON,
+	SVSB_PHASE_NUM,
 };
 
 enum svs_reg_index {
@@ -138,6 +174,7 @@ enum svs_reg_index {
 	SPARE2,
 	SPARE3,
 	THSLPEVEB,
+	SVS_REG_NUM,
 };
 
 static const u32 svs_regs_v2[] = {
@@ -242,6 +279,7 @@ struct thermal_parameter {
  * @opp_volts: signed-off voltages from default opp table
  * @freqs_pct: percent of "opp_freqs / freq_base" for bank init
  * @volts: bank voltages
+ * @reg_data: bank register data of each phase
  * @freq_base: reference frequency for bank init
  * @vboot: voltage request for bank init01 stage only
  * @volt_step: bank voltage step
@@ -260,6 +298,7 @@ struct thermal_parameter {
  * @opp_count: bank opp count
  * @int_st: bank interrupt identification
  * @sw_id: bank software identification
+ * @hw_id: bank hardware identification
  * @ctl0: bank thermal sensor selection
  * @cpu_id: cpu core id for SVS CPU only
  *
@@ -286,6 +325,7 @@ struct svs_bank {
 	u32 opp_volts[16];
 	u32 freqs_pct[16];
 	u32 volts[16];
+	u32 reg_data[SVSB_PHASE_NUM][SVS_REG_NUM];
 	u32 freq_base;
 	u32 vboot;
 	u32 volt_step;
@@ -323,6 +363,7 @@ struct svs_bank {
 	u32 opp_count;
 	u32 int_st;
 	u32 sw_id;
+	u32 hw_id;
 	u32 ctl0;
 	u32 cpu_id;
 };
@@ -638,11 +679,15 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
 static inline void svs_init01_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
 		 __func__, svs_readl(svsp, VDESIGN74),
 		 svs_readl(svsp, VDESIGN30), svs_readl(svsp, DCVALUES));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_INIT01][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->phase = SVSB_PHASE_INIT01;
 	svsb->dc_voffset_in = ~(svs_readl(svsp, DCVALUES) & GENMASK(15, 0)) + 1;
 	if (svsb->init01_volt_flag == SVSB_INIT01_VOLT_IGNORE ||
@@ -662,11 +707,15 @@ static inline void svs_init01_isr_handler(struct svs_platform *svsp)
 static inline void svs_init02_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
 		 __func__, svs_readl(svsp, VOP74), svs_readl(svsp, VOP30),
 		 svs_readl(svsp, DCVALUES));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_INIT02][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->phase = SVSB_PHASE_INIT02;
 	svsp->get_vops(svsp);
 
@@ -677,6 +726,10 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
 static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
+
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_MON][rg_i] = svs_readl(svsp, rg_i);
 
 	svsb->phase = SVSB_PHASE_MON;
 	svsb->temp = svs_readl(svsp, TEMP) & GENMASK(7, 0);
@@ -688,6 +741,7 @@ static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
 static inline void svs_error_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
 		__func__, svs_readl(svsp, CORESEL));
@@ -697,6 +751,9 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
 		svs_readl(svsp, SMSTATE0), svs_readl(svsp, SMSTATE1));
 	dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl(svsp, TEMP));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_ERROR][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->mode_support = SVSB_MODE_ALL_DISABLE;
 	svsb->phase = SVSB_PHASE_ERROR;
 
@@ -1406,9 +1463,271 @@ static int svs_resume(struct device *dev)
 	return 0;
 }
 
+/*
+ * svs_dump_debug_show - dump svs/thermal efuse and svs banks' registers
+ */
+static int svs_dump_debug_show(struct seq_file *m, void *p)
+{
+	struct svs_platform *svsp = (struct svs_platform *)m->private;
+	struct svs_bank *svsb;
+	unsigned long svs_reg_addr;
+	u32 idx, i, j;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse && svsp->efuse[i])
+			seq_printf(m, "M_HW_RES%d = 0x%08x\n",
+				   i, svsp->efuse[i]);
+
+	for (i = 0; i < svsp->tefuse_num; i++)
+		if (svsp->tefuse)
+			seq_printf(m, "THERMAL_EFUSE%d = 0x%08x\n",
+				   i, svsp->tefuse[i]);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		for (i = SVSB_PHASE_INIT01; i <= SVSB_PHASE_MON; i++) {
+			seq_printf(m, "Bank_number = %u\n", svsb->hw_id);
+
+			if (i == SVSB_PHASE_INIT01 || i == SVSB_PHASE_INIT02)
+				seq_printf(m, "mode = init%d\n", i);
+			else if (i == SVSB_PHASE_MON)
+				seq_puts(m, "mode = mon\n");
+			else
+				seq_puts(m, "mode = error\n");
+
+			for (j = DESCHAR; j < SVS_REG_NUM; j++) {
+				svs_reg_addr = (unsigned long)(svsp->base +
+							       svsp->regs[j]);
+				seq_printf(m, "0x%08lx = 0x%08x\n",
+					   svs_reg_addr, svsb->reg_data[i][j]);
+			}
+		}
+	}
+
+	return 0;
+}
+
+debug_fops_ro(dump);
+
+/*
+ * svs_enable_debug_show - show svs bank current enable phase
+ */
+static int svs_enable_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+	if (svsb->phase == SVSB_PHASE_INIT01)
+		seq_puts(m, "init1\n");
+	else if (svsb->phase == SVSB_PHASE_INIT02)
+		seq_puts(m, "init2\n");
+	else if (svsb->phase == SVSB_PHASE_MON)
+		seq_puts(m, "mon mode\n");
+	else if (svsb->phase == SVSB_PHASE_ERROR)
+		seq_puts(m, "disabled\n");
+	else
+		seq_puts(m, "unknown\n");
+
+	return 0;
+}
+
+/*
+ * svs_enable_debug_write - we only support svs bank disable control
+ */
+static ssize_t svs_enable_debug_write(struct file *filp,
+				      const char __user *buffer,
+				      size_t count, loff_t *pos)
+{
+	struct svs_bank *svsb = file_inode(filp)->i_private;
+	struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
+	unsigned long flags;
+	int enabled, ret;
+	char *buf = NULL;
+
+	if (count >= PAGE_SIZE)
+		return -EINVAL;
+
+	buf = (char *)memdup_user_nul(buffer, count);
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	ret = kstrtoint(buf, 10, &enabled);
+	if (ret)
+		return ret;
+
+	if (!enabled) {
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+		svs_switch_bank(svsp);
+		svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+		svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		svsb->phase = SVSB_PHASE_ERROR;
+		svs_adjust_pm_opp_volts(svsb, true);
+	}
+
+	kfree(buf);
+
+	return count;
+}
+
+debug_fops_rw(enable);
+
+/*
+ * svs_status_debug_show - show svs bank's tzone_temp/voltages/freqs_pct
+ * and its corresponding opp-table's opp_freqs/opp_volts
+ */
+static int svs_status_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+	struct dev_pm_opp *opp;
+	int tzone_temp = 0, ret;
+	u32 i;
+
+	ret = svs_get_bank_zone_temperature(svsb->tzone_name, &tzone_temp);
+	if (ret)
+		seq_printf(m, "%s: no \"%s\" zone?\n", svsb->name,
+			   svsb->tzone_name);
+	else
+		seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+						 svsb->opp_freqs[i], true);
+		if (IS_ERR(opp)) {
+			seq_printf(m, "%s: cannot find freq = %u (%ld)\n",
+				   svsb->name, svsb->opp_freqs[i],
+				   PTR_ERR(opp));
+			return PTR_ERR(opp);
+		}
+
+		seq_printf(m, "opp_freqs[%02u]: %u, opp_volts[%02u]: %lu, ",
+			   i, svsb->opp_freqs[i], i,
+			   dev_pm_opp_get_voltage(opp));
+		seq_printf(m, "svsb_volts[%02u]: 0x%x, freqs_pct[%02u]: %u\n",
+			   i, svsb->volts[i], i, svsb->freqs_pct[i]);
+		dev_pm_opp_put(opp);
+	}
+
+	return 0;
+}
+
+debug_fops_ro(status);
+
+/*
+ * svs_volt_offset_debug_show - show svs bank's voltage offset
+ */
+static int svs_volt_offset_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+	seq_printf(m, "%d\n", svsb->volt_offset);
+
+	return 0;
+}
+
+/*
+ * svs_volt_offset_debug_write - write svs bank's voltage offset
+ */
+static ssize_t svs_volt_offset_debug_write(struct file *filp,
+					   const char __user *buffer,
+					   size_t count, loff_t *pos)
+{
+	struct svs_bank *svsb = file_inode(filp)->i_private;
+	char *buf = NULL;
+	s32 volt_offset;
+
+	if (count >= PAGE_SIZE)
+		return -EINVAL;
+
+	buf = (char *)memdup_user_nul(buffer, count);
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	if (!kstrtoint(buf, 10, &volt_offset)) {
+		svsb->volt_offset = volt_offset;
+		svs_adjust_pm_opp_volts(svsb, true);
+	}
+
+	kfree(buf);
+
+	return count;
+}
+
+debug_fops_rw(volt_offset);
+
+static int svs_create_svs_debug_cmds(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct dentry *svs_dir, *svsb_dir, *file_entry;
+	const char *d = "/sys/kernel/debug/svs";
+	u32 i, idx;
+
+	struct svs_dentry {
+		const char *name;
+		const struct file_operations *fops;
+	};
+
+	struct svs_dentry svs_entries[] = {
+		svs_dentry(dump),
+	};
+
+	struct svs_dentry svsb_entries[] = {
+		svs_dentry(enable),
+		svs_dentry(status),
+		svs_dentry(volt_offset),
+	};
+
+	svs_dir = debugfs_create_dir("svs", NULL);
+	if (IS_ERR(svs_dir)) {
+		dev_err(svsp->dev, "cannot create %s: %ld\n",
+			d, PTR_ERR(svs_dir));
+		return 0;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(svs_entries); i++) {
+		file_entry = debugfs_create_file(svs_entries[i].name, 0664,
+						 svs_dir, svsp,
+						 svs_entries[i].fops);
+		if (IS_ERR(file_entry)) {
+			dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+				d, svs_entries[i].name, PTR_ERR(file_entry));
+			return PTR_ERR(file_entry);
+		}
+	}
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		svsb_dir = debugfs_create_dir(svsb->name, svs_dir);
+		if (IS_ERR(svsb_dir)) {
+			dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+				d, svsb->name, PTR_ERR(svsb_dir));
+			return PTR_ERR(svsb_dir);
+		}
+
+		for (i = 0; i < ARRAY_SIZE(svsb_entries); i++) {
+			file_entry = debugfs_create_file(svsb_entries[i].name,
+							 0664, svsb_dir, svsb,
+							 svsb_entries[i].fops);
+			if (IS_ERR(file_entry)) {
+				dev_err(svsp->dev, "no %s/%s/%s?: %ld\n",
+					d, svsb->name, svsb_entries[i].name,
+					PTR_ERR(file_entry));
+				return PTR_ERR(file_entry);
+			}
+		}
+	}
+
+	return 0;
+}
+
 static struct svs_bank svs_mt8183_banks[] = {
 	{
 		.sw_id			= SVSB_CPU_LITTLE,
+		.hw_id			= 0,
 		.cpu_id			= 0,
 		.tzone_name		= "tzts4",
 		.buck_name		= "proc",
@@ -1444,6 +1763,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 	},
 	{
 		.sw_id			= SVSB_CPU_BIG,
+		.hw_id			= 1,
 		.cpu_id			= 4,
 		.tzone_name		= "tzts5",
 		.buck_name		= "proc",
@@ -1479,6 +1799,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 	},
 	{
 		.sw_id			= SVSB_CCI,
+		.hw_id			= 2,
 		.tzone_name		= "tzts4",
 		.buck_name		= "proc",
 		.pd_req			= false,
@@ -1513,6 +1834,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 	},
 	{
 		.sw_id			= SVSB_GPU,
+		.hw_id			= 3,
 		.tzone_name		= "tzts2",
 		.buck_name		= "mali",
 		.pd_req			= true,
@@ -1678,6 +2000,12 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_iounmap;
 	}
 
+	ret = svs_create_svs_debug_cmds(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
+		goto svs_probe_iounmap;
+	}
+
 	return 0;
 
 svs_probe_iounmap:
-- 
2.18.0

From roger.lu at mediatek.com  Fri Apr  9 10:28:24 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:24 +0800
Subject: [PATCH v15 3/7] soc: mediatek: SVS: introduce MTK SVS engine
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-4-roger.lu@mediatek.com>

The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/Kconfig   |   10 +
 drivers/soc/mediatek/Makefile  |    1 +
 drivers/soc/mediatek/mtk-svs.c | 1707 ++++++++++++++++++++++++++++++++
 3 files changed, 1718 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-svs.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..3c3eedea35f7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -73,4 +73,14 @@ config MTK_MMSYS
 	  Say yes here to add support for the MediaTek Multimedia
 	  Subsystem (MMSYS).
 
+config MTK_SVS
+	tristate "MediaTek Smart Voltage Scaling(SVS)"
+	depends on MTK_EFUSE && NVMEM
+	help
+	  The Smart Voltage Scaling(SVS) engine is a piece of hardware
+	  which has several controllers(banks) for calculating suitable
+	  voltage to different power domains(CPU/GPU/CCI) according to
+	  chip process corner, temperatures and other factors. Then DVFS
+	  driver could apply SVS bank voltage to PMIC/Buck.
+
 endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 90270f8114ed..0e9e703c931a 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
 obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
+obj-$(CONFIG_MTK_SVS) += mtk-svs.o
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
new file mode 100644
index 000000000000..7d134d47f871
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -0,0 +1,1707 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/thermal.h>
+
+/* svs bank 1-line sw id */
+#define SVSB_CPU_LITTLE			BIT(0)
+#define SVSB_CPU_BIG			BIT(1)
+#define SVSB_CCI			BIT(2)
+#define SVSB_GPU			BIT(3)
+
+/* svs bank mode support */
+#define SVSB_MODE_ALL_DISABLE		0
+#define SVSB_MODE_INIT01		BIT(1)
+#define SVSB_MODE_INIT02		BIT(2)
+#define SVSB_MODE_MON			BIT(3)
+
+/* svs bank init01 condition */
+#define SVSB_INIT01_VOLT_IGNORE		BIT(1)
+#define SVSB_INIT01_VOLT_INC_ONLY	BIT(2)
+#define SVSB_INIT01_CLK_EN		BIT(31)
+
+/* svs bank common setting */
+#define SVSB_TZONE_HIGH_TEMP_MAX	U32_MAX
+#define SVSB_RUNCONFIG_DEFAULT		0x80000000
+#define SVSB_DC_SIGNED_BIT		0x8000
+#define SVSB_INTEN_INIT0x		0x00005f01
+#define SVSB_INTEN_MONVOPEN		0x00ff0000
+#define SVSB_EN_OFF			0x0
+#define SVSB_EN_MASK			0x7
+#define SVSB_EN_INIT01			0x1
+#define SVSB_EN_INIT02			0x5
+#define SVSB_EN_MON			0x2
+#define SVSB_INTSTS_MONVOP		0x00ff0000
+#define SVSB_INTSTS_COMPLETE		0x1
+#define SVSB_INTSTS_CLEAN		0x00ffffff
+
+static DEFINE_SPINLOCK(mtk_svs_lock);
+
+/*
+ * enum svsb_phase - svs bank phase enumeration
+ * @SVSB_PHASE_INIT01: basic init for svs bank
+ * @SVSB_PHASE_INIT02: svs bank can provide voltages
+ * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
+ * @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
+ *
+ * Each svs bank has its own independent phase. We enable each svs bank by
+ * running their phase orderly. However, When svs bank encounters unexpected
+ * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
+ *
+ * svs bank general phase-enabled order:
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
+ */
+enum svsb_phase {
+	SVSB_PHASE_ERROR = 0,
+	SVSB_PHASE_INIT01,
+	SVSB_PHASE_INIT02,
+	SVSB_PHASE_MON,
+};
+
+enum svs_reg_index {
+	DESCHAR = 0,
+	TEMPCHAR,
+	DETCHAR,
+	AGECHAR,
+	DCCONFIG,
+	AGECONFIG,
+	FREQPCT30,
+	FREQPCT74,
+	LIMITVALS,
+	VBOOT,
+	DETWINDOW,
+	CONFIG,
+	TSCALCS,
+	RUNCONFIG,
+	SVSEN,
+	INIT2VALS,
+	DCVALUES,
+	AGEVALUES,
+	VOP30,
+	VOP74,
+	TEMP,
+	INTSTS,
+	INTSTSRAW,
+	INTEN,
+	CHKINT,
+	CHKSHIFT,
+	STATUS,
+	VDESIGN30,
+	VDESIGN74,
+	DVT30,
+	DVT74,
+	AGECOUNT,
+	SMSTATE0,
+	SMSTATE1,
+	CTL0,
+	DESDETSEC,
+	TEMPAGESEC,
+	CTRLSPARE0,
+	CTRLSPARE1,
+	CTRLSPARE2,
+	CTRLSPARE3,
+	CORESEL,
+	THERMINTST,
+	INTST,
+	THSTAGE0ST,
+	THSTAGE1ST,
+	THSTAGE2ST,
+	THAHBST0,
+	THAHBST1,
+	SPARE0,
+	SPARE1,
+	SPARE2,
+	SPARE3,
+	THSLPEVEB,
+};
+
+static const u32 svs_regs_v2[] = {
+	[DESCHAR]		= 0xc00,
+	[TEMPCHAR]		= 0xc04,
+	[DETCHAR]		= 0xc08,
+	[AGECHAR]		= 0xc0c,
+	[DCCONFIG]		= 0xc10,
+	[AGECONFIG]		= 0xc14,
+	[FREQPCT30]		= 0xc18,
+	[FREQPCT74]		= 0xc1c,
+	[LIMITVALS]		= 0xc20,
+	[VBOOT]			= 0xc24,
+	[DETWINDOW]		= 0xc28,
+	[CONFIG]		= 0xc2c,
+	[TSCALCS]		= 0xc30,
+	[RUNCONFIG]		= 0xc34,
+	[SVSEN]			= 0xc38,
+	[INIT2VALS]		= 0xc3c,
+	[DCVALUES]		= 0xc40,
+	[AGEVALUES]		= 0xc44,
+	[VOP30]			= 0xc48,
+	[VOP74]			= 0xc4c,
+	[TEMP]			= 0xc50,
+	[INTSTS]		= 0xc54,
+	[INTSTSRAW]		= 0xc58,
+	[INTEN]			= 0xc5c,
+	[CHKINT]		= 0xc60,
+	[CHKSHIFT]		= 0xc64,
+	[STATUS]		= 0xc68,
+	[VDESIGN30]		= 0xc6c,
+	[VDESIGN74]		= 0xc70,
+	[DVT30]			= 0xc74,
+	[DVT74]			= 0xc78,
+	[AGECOUNT]		= 0xc7c,
+	[SMSTATE0]		= 0xc80,
+	[SMSTATE1]		= 0xc84,
+	[CTL0]			= 0xc88,
+	[DESDETSEC]		= 0xce0,
+	[TEMPAGESEC]		= 0xce4,
+	[CTRLSPARE0]		= 0xcf0,
+	[CTRLSPARE1]		= 0xcf4,
+	[CTRLSPARE2]		= 0xcf8,
+	[CTRLSPARE3]		= 0xcfc,
+	[CORESEL]		= 0xf00,
+	[THERMINTST]		= 0xf04,
+	[INTST]			= 0xf08,
+	[THSTAGE0ST]		= 0xf0c,
+	[THSTAGE1ST]		= 0xf10,
+	[THSTAGE2ST]		= 0xf14,
+	[THAHBST0]		= 0xf18,
+	[THAHBST1]		= 0xf1c,
+	[SPARE0]		= 0xf20,
+	[SPARE1]		= 0xf24,
+	[SPARE2]		= 0xf28,
+	[SPARE3]		= 0xf2c,
+	[THSLPEVEB]		= 0xf30,
+};
+
+/*
+ * struct thermal_parameter - This is for storing thermal efuse data.
+ * We calculate thermal efuse data to produce "mts" and "bts" for
+ * svs bank mon mode.
+ */
+struct thermal_parameter {
+	int adc_ge_t;
+	int adc_oe_t;
+	int ge;
+	int oe;
+	int gain;
+	int o_vtsabb;
+	int o_vtsmcu1;
+	int o_vtsmcu2;
+	int o_vtsmcu3;
+	int o_vtsmcu4;
+	int o_vtsmcu5;
+	int degc_cali;
+	int adc_cali_en_t;
+	int o_slope;
+	int o_slope_sign;
+	int ts_id;
+};
+
+/*
+ * struct svs_bank - svs bank representation
+ * @dev: svs bank device
+ * @opp_dev: device for opp table/buck control
+ * @pd_dev: power domain device for SoC mtcmos control
+ * @init_completion: the timeout completion for bank init
+ * @buck: phandle of the regulator
+ * @lock: mutex lock to protect voltage update process
+ * @phase: bank current phase
+ * @name: bank name
+ * @tzone_name: thermal zone name
+ * @buck_name: regulator name
+ * @suspended: suspend flag of this bank
+ * @pd_req: bank's power-domain on request
+ * @enable_pm_runtime_ever: bank enables pm-runtime flag
+ * @volt_offset: bank voltage offset controlled by svs software
+ * @mode_support: bank mode support.
+ * @opp_freqs: signed-off frequencies from default opp table
+ * @opp_volts: signed-off voltages from default opp table
+ * @freqs_pct: percent of "opp_freqs / freq_base" for bank init
+ * @volts: bank voltages
+ * @freq_base: reference frequency for bank init
+ * @vboot: voltage request for bank init01 stage only
+ * @volt_step: bank voltage step
+ * @volt_base: bank voltage base
+ * @init01_volt_flag: bank init01 voltage flag
+ * @vmax: bank voltage maximum
+ * @vmin: bank voltage minimum
+ * @temp: bank temperature
+ * @temp_upper_bound: bank temperature upper bound
+ * @temp_lower_bound: bank temperature lower bound
+ * @tzone_high_temp: thermal zone high temperature threshold
+ * @tzone_high_temp_offset: thermal zone high temperature offset
+ * @tzone_low_temp: thermal zone low temperature threshold
+ * @tzone_low_temp_offset: thermal zone low temperature offset
+ * @core_sel: bank selection
+ * @opp_count: bank opp count
+ * @int_st: bank interrupt identification
+ * @sw_id: bank software identification
+ * @ctl0: bank thermal sensor selection
+ * @cpu_id: cpu core id for SVS CPU only
+ *
+ * Other structure members which are not listed above are svs platform
+ * efuse data for bank init
+ */
+struct svs_bank {
+	struct device *dev;
+	struct device *opp_dev;
+	struct device *pd_dev;
+	struct completion init_completion;
+	struct regulator *buck;
+	struct mutex lock;	/* lock to protect voltage update process */
+	enum svsb_phase phase;
+	char *name;
+	char *tzone_name;
+	char *buck_name;
+	bool suspended;
+	bool pd_req;
+	bool enable_pm_runtime_ever;
+	s32 volt_offset;
+	u32 mode_support;
+	u32 opp_freqs[16];
+	u32 opp_volts[16];
+	u32 freqs_pct[16];
+	u32 volts[16];
+	u32 freq_base;
+	u32 vboot;
+	u32 volt_step;
+	u32 volt_base;
+	u32 init01_volt_flag;
+	u32 vmax;
+	u32 vmin;
+	u32 bts;
+	u32 mts;
+	u32 bdes;
+	u32 mdes;
+	u32 mtdes;
+	u32 dcbdet;
+	u32 dcmdet;
+	u32 dthi;
+	u32 dtlo;
+	u32 det_window;
+	u32 det_max;
+	u32 age_config;
+	u32 age_voffset_in;
+	u32 agem;
+	u32 dc_config;
+	u32 dc_voffset_in;
+	u32 dvt_fixed;
+	u32 vco;
+	u32 chk_shift;
+	u32 temp;
+	u32 temp_upper_bound;
+	u32 temp_lower_bound;
+	u32 tzone_high_temp;
+	u32 tzone_high_temp_offset;
+	u32 tzone_low_temp;
+	u32 tzone_low_temp_offset;
+	u32 core_sel;
+	u32 opp_count;
+	u32 int_st;
+	u32 sw_id;
+	u32 ctl0;
+	u32 cpu_id;
+};
+
+/*
+ * struct svs_platform - svs platform data
+ * @dev: svs platform device
+ * @base: svs platform register address base
+ * @main_clk: main clock for svs bank
+ * @pbank: phandle of svs bank and needs to be protected by spin_lock
+ * @banks: phandle of the banks that support
+ * @efuse_parsing: phandle of efuse parsing function
+ * @set_freqs_pct: phandle of set frequencies percent function
+ * @get_vops: phandle of  get bank voltages function
+ * @irqflags: irq settings flags
+ * @rst: svs reset control
+ * @regs: phandle to the registers map
+ * @efuse_num: the total number of svs platform efuse
+ * @tefuse_num: the total number of thermal efuse
+ * @bank_num: the total number of banks
+ * @efuse_check: the svs efuse check index
+ * @efuse: svs platform efuse data received from NVMEM framework
+ * @tefuse: thermal efuse data received from NVMEM framework
+ * @name: svs platform name
+ */
+struct svs_platform {
+	struct device *dev;
+	void __iomem *base;
+	struct clk *main_clk;
+	struct svs_bank *pbank;
+	struct svs_bank *banks;
+	bool (*efuse_parsing)(struct svs_platform *svsp);
+	void (*set_freqs_pct)(struct svs_platform *svsp);
+	void (*get_vops)(struct svs_platform *svsp);
+	unsigned long irqflags;
+	struct reset_control *rst;
+	const u32 *regs;
+	char *name;
+	size_t efuse_num;
+	size_t tefuse_num;
+	u32 bank_num;
+	u32 efuse_check;
+	u32 *efuse;
+	u32 *tefuse;
+};
+
+static u32 percent(u32 numerator, u32 denominator)
+{
+	/* If not divide 1000, "numerator * 100" will have data overflow. */
+	numerator /= 1000;
+	denominator /= 1000;
+
+	return DIV_ROUND_UP(numerator * 100, denominator);
+}
+
+static u32 svs_readl(struct svs_platform *svsp, enum svs_reg_index rg_i)
+{
+	return readl(svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_writel(struct svs_platform *svsp, u32 val,
+		       enum svs_reg_index rg_i)
+{
+	writel(val, svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_switch_bank(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svs_writel(svsp, svsb->core_sel, CORESEL);
+}
+
+static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
+				     u32 svsb_volt_base)
+{
+	return (svsb_volt * svsb_volt_step) + svsb_volt_base;
+}
+
+static int svs_get_bank_zone_temperature(const char *tzone_name,
+					 int *tzone_temp)
+{
+	struct thermal_zone_device *tzd;
+
+	tzd = thermal_zone_get_zone_by_name(tzone_name);
+	if (IS_ERR(tzd))
+		return PTR_ERR(tzd);
+
+	return thermal_zone_get_temp(tzd, tzone_temp);
+}
+
+static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
+{
+	int tzone_temp = 0, ret = -EPERM;
+	u32 i, svsb_volt, opp_volt, temp_offset = 0;
+
+	mutex_lock(&svsb->lock);
+
+	/*
+	 * If svs bank is suspended, it means signed-off voltages are applied.
+	 * Don't need to update opp voltage anymore.
+	 */
+	if (svsb->suspended && !force_update) {
+		dev_notice(svsb->dev, "bank is suspended\n");
+		ret = -EPERM;
+		goto unlock_mutex;
+	}
+
+	/* Get thermal effect */
+	if (svsb->phase == SVSB_PHASE_MON) {
+		if (svsb->temp > svsb->temp_upper_bound &&
+		    svsb->temp < svsb->temp_lower_bound) {
+			dev_warn(svsb->dev, "svsb temp = 0x%x?\n", svsb->temp);
+			ret = -EINVAL;
+			goto unlock_mutex;
+		}
+
+		ret = svs_get_bank_zone_temperature(svsb->tzone_name,
+						    &tzone_temp);
+		if (ret) {
+			dev_err(svsb->dev, "no %s? (%d), run default volts\n",
+				svsb->tzone_name, ret);
+			svsb->phase = SVSB_PHASE_ERROR;
+		}
+
+		if (tzone_temp >= svsb->tzone_high_temp)
+			temp_offset += svsb->tzone_high_temp_offset;
+		else if (tzone_temp <= svsb->tzone_low_temp)
+			temp_offset += svsb->tzone_low_temp_offset;
+	}
+
+	/* vmin <= svsb_volt (opp_volt) <= signed-off (default) voltage */
+	for (i = 0; i < svsb->opp_count; i++) {
+		if (svsb->phase == SVSB_PHASE_MON) {
+			svsb_volt = max(svsb->volts[i] + svsb->volt_offset +
+					temp_offset, svsb->vmin);
+			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+							     svsb->volt_step,
+							     svsb->volt_base);
+		} else if (svsb->phase == SVSB_PHASE_INIT02) {
+			svsb_volt = max(svsb->volts[i] + svsb->volt_offset,
+					svsb->vmin);
+			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+							     svsb->volt_step,
+							     svsb->volt_base);
+		} else if (svsb->phase == SVSB_PHASE_ERROR) {
+			opp_volt = svsb->opp_volts[i];
+		} else {
+			dev_err(svsb->dev, "unknown phase: %u?\n", svsb->phase);
+			ret = -EINVAL;
+			goto unlock_mutex;
+		}
+
+		opp_volt = min(opp_volt, svsb->opp_volts[i]);
+		ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+						svsb->opp_freqs[i],
+						opp_volt, opp_volt,
+						svsb->opp_volts[i]);
+		if (ret) {
+			dev_err(svsb->dev, "set voltage fail: %d\n", ret);
+			goto unlock_mutex;
+		}
+	}
+
+unlock_mutex:
+	mutex_unlock(&svsb->lock);
+
+	return ret;
+}
+
+static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
+{
+	u32 vx;
+
+	if (v0 == v1 || f0 == f1)
+		return v0;
+
+	/* *100 to have decimal fraction factor */
+	vx = (v0 * 100) - ((((v0 - v1) * 100) / (f0 - f1)) * (f0 - fx));
+
+	return DIV_ROUND_UP(vx, 100);
+}
+
+static void svs_get_vops_v2(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 temp, i;
+
+	temp = svs_readl(svsp, VOP74);
+	svsb->volts[14] = (temp >> 24) & GENMASK(7, 0);
+	svsb->volts[12] = (temp >> 16) & GENMASK(7, 0);
+	svsb->volts[10] = (temp >> 8)  & GENMASK(7, 0);
+	svsb->volts[8] = (temp & GENMASK(7, 0));
+
+	temp = svs_readl(svsp, VOP30);
+	svsb->volts[6] = (temp >> 24) & GENMASK(7, 0);
+	svsb->volts[4] = (temp >> 16) & GENMASK(7, 0);
+	svsb->volts[2] = (temp >> 8)  & GENMASK(7, 0);
+	svsb->volts[0] = (temp & GENMASK(7, 0));
+
+	for (i = 0; i <= 12; i += 2)
+		svsb->volts[i + 1] =
+			interpolate(svsb->freqs_pct[i],
+				    svsb->freqs_pct[i + 2],
+				    svsb->volts[i],
+				    svsb->volts[i + 2],
+				    svsb->freqs_pct[i + 1]);
+
+	svsb->volts[15] =
+		interpolate(svsb->freqs_pct[12],
+			    svsb->freqs_pct[14],
+			    svsb->volts[12],
+			    svsb->volts[14],
+			    svsb->freqs_pct[15]);
+}
+
+static void svs_set_freqs_pct_v2(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svs_writel(svsp,
+		   (svsb->freqs_pct[14] << 24) |
+		   (svsb->freqs_pct[12] << 16) |
+		   (svsb->freqs_pct[10] << 8) |
+		   svsb->freqs_pct[8],
+		   FREQPCT74);
+
+	svs_writel(svsp,
+		   (svsb->freqs_pct[6] << 24) |
+		   (svsb->freqs_pct[4] << 16) |
+		   (svsb->freqs_pct[2] << 8) |
+		   svsb->freqs_pct[0],
+		   FREQPCT30);
+}
+
+static void svs_set_bank_phase(struct svs_platform *svsp,
+			       enum svsb_phase target_phase)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 des_char, temp_char, det_char, limit_vals;
+	u32 init2vals, ts_calcs, val, filter, i;
+
+	svs_switch_bank(svsp);
+
+	des_char = (svsb->bdes << 8) | svsb->mdes;
+	svs_writel(svsp, des_char, DESCHAR);
+
+	temp_char = (svsb->vco << 16) | (svsb->mtdes << 8) | svsb->dvt_fixed;
+	svs_writel(svsp, temp_char, TEMPCHAR);
+
+	det_char = (svsb->dcbdet << 8) | svsb->dcmdet;
+	svs_writel(svsp, det_char, DETCHAR);
+
+	svs_writel(svsp, svsb->dc_config, DCCONFIG);
+	svs_writel(svsp, svsb->age_config, AGECONFIG);
+
+	if (!svsb->agem) {
+		svs_writel(svsp, SVSB_RUNCONFIG_DEFAULT, RUNCONFIG);
+	} else {
+		val = 0x0;
+
+		for (i = 0; i < 24; i += 2) {
+			filter = 0x3 << i;
+
+			if (!(svsb->age_config & filter))
+				val |= (0x1 << i);
+			else
+				val |= (svsb->age_config & filter);
+		}
+		svs_writel(svsp, val, RUNCONFIG);
+	}
+
+	svsp->set_freqs_pct(svsp);
+
+	limit_vals = (svsb->vmax << 24) | (svsb->vmin << 16) |
+		     (svsb->dthi << 8) | svsb->dtlo;
+	svs_writel(svsp, limit_vals, LIMITVALS);
+	svs_writel(svsp, svsb->vboot, VBOOT);
+	svs_writel(svsp, svsb->det_window, DETWINDOW);
+	svs_writel(svsp, svsb->det_max, CONFIG);
+
+	if (svsb->chk_shift)
+		svs_writel(svsp, svsb->chk_shift, CHKSHIFT);
+
+	if (svsb->ctl0)
+		svs_writel(svsp, svsb->ctl0, CTL0);
+
+	svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+
+	switch (target_phase) {
+	case SVSB_PHASE_INIT01:
+		svs_writel(svsp, SVSB_INTEN_INIT0x, INTEN);
+		svs_writel(svsp, SVSB_EN_INIT01, SVSEN);
+		break;
+	case SVSB_PHASE_INIT02:
+		svs_writel(svsp, SVSB_INTEN_INIT0x, INTEN);
+		init2vals = (svsb->age_voffset_in << 16) | svsb->dc_voffset_in;
+		svs_writel(svsp, init2vals, INIT2VALS);
+		svs_writel(svsp, SVSB_EN_INIT02, SVSEN);
+		break;
+	case SVSB_PHASE_MON:
+		ts_calcs = (svsb->bts << 12) | svsb->mts;
+		svs_writel(svsp, ts_calcs, TSCALCS);
+		svs_writel(svsp, SVSB_INTEN_MONVOPEN, INTEN);
+		svs_writel(svsp, SVSB_EN_MON, SVSEN);
+		break;
+	default:
+		WARN_ON(1);
+		break;
+	}
+}
+
+static inline void svs_init01_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
+		 __func__, svs_readl(svsp, VDESIGN74),
+		 svs_readl(svsp, VDESIGN30), svs_readl(svsp, DCVALUES));
+
+	svsb->phase = SVSB_PHASE_INIT01;
+	svsb->dc_voffset_in = ~(svs_readl(svsp, DCVALUES) & GENMASK(15, 0)) + 1;
+	if (svsb->init01_volt_flag == SVSB_INIT01_VOLT_IGNORE ||
+	    ((svsb->dc_voffset_in & SVSB_DC_SIGNED_BIT) &&
+	     svsb->init01_volt_flag == SVSB_INIT01_VOLT_INC_ONLY))
+		svsb->dc_voffset_in = 0;
+
+	svsb->age_voffset_in = svs_readl(svsp, AGEVALUES) & GENMASK(15, 0);
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+
+	/* svs init01 clock gating */
+	svsb->core_sel &= ~SVSB_INIT01_CLK_EN;
+}
+
+static inline void svs_init02_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
+		 __func__, svs_readl(svsp, VOP74), svs_readl(svsp, VOP30),
+		 svs_readl(svsp, DCVALUES));
+
+	svsb->phase = SVSB_PHASE_INIT02;
+	svsp->get_vops(svsp);
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+}
+
+static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svsb->phase = SVSB_PHASE_MON;
+	svsb->temp = svs_readl(svsp, TEMP) & GENMASK(7, 0);
+	svsp->get_vops(svsp);
+
+	svs_writel(svsp, SVSB_INTSTS_MONVOP, INTSTS);
+}
+
+static inline void svs_error_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
+		__func__, svs_readl(svsp, CORESEL));
+	dev_err(svsb->dev, "SVSEN = 0x%08x, INTSTS = 0x%08x\n",
+		svs_readl(svsp, SVSEN), svs_readl(svsp, INTSTS));
+	dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
+		svs_readl(svsp, SMSTATE0), svs_readl(svsp, SMSTATE1));
+	dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl(svsp, TEMP));
+
+	svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+	svsb->phase = SVSB_PHASE_ERROR;
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+}
+
+static irqreturn_t svs_isr(int irq, void *data)
+{
+	struct svs_platform *svsp = data;
+	struct svs_bank *svsb = NULL;
+	unsigned long flags;
+	u32 idx, int_sts, svs_en;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		WARN_ON(!svsb);
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+
+		/* Find out which svs bank fires interrupt */
+		if (svsb->int_st & svs_readl(svsp, INTST)) {
+			spin_unlock_irqrestore(&mtk_svs_lock, flags);
+			continue;
+		}
+
+		if (!svsb->suspended) {
+			svs_switch_bank(svsp);
+			int_sts = svs_readl(svsp, INTSTS);
+			svs_en = svs_readl(svsp, SVSEN);
+
+			if (int_sts == SVSB_INTSTS_COMPLETE &&
+			    ((svs_en & SVSB_EN_MASK) == SVSB_EN_INIT01))
+				svs_init01_isr_handler(svsp);
+			else if ((int_sts == SVSB_INTSTS_COMPLETE) &&
+				 ((svs_en & SVSB_EN_MASK) == SVSB_EN_INIT02))
+				svs_init02_isr_handler(svsp);
+			else if ((int_sts & SVSB_INTSTS_MONVOP))
+				svs_mon_mode_isr_handler(svsp);
+			else
+				svs_error_isr_handler(svsp);
+		}
+
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+		break;
+	}
+
+	if (svsb->phase != SVSB_PHASE_INIT01)
+		svs_adjust_pm_opp_volts(svsb, false);
+
+	if (svsb->phase == SVSB_PHASE_INIT01 ||
+	    svsb->phase == SVSB_PHASE_INIT02)
+		complete(&svsb->init_completion);
+
+	return IRQ_HANDLED;
+}
+
+static void svs_mon_mode(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	unsigned long flags;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_MON))
+			continue;
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_MON);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+	}
+}
+
+static int svs_init02(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	unsigned long flags, time_left;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT02))
+			continue;
+
+		reinit_completion(&svsb->init_completion);
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_INIT02);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		time_left =
+			wait_for_completion_timeout(&svsb->init_completion,
+						    msecs_to_jiffies(5000));
+		if (!time_left) {
+			dev_err(svsb->dev, "init02 completion timeout\n");
+			return -EBUSY;
+		}
+	}
+
+	return 0;
+}
+
+static int svs_init01(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct pm_qos_request *qos_request;
+	unsigned long flags, time_left;
+	bool search_done;
+	int ret = 0;
+	u32 opp_freqs, opp_vboot, buck_volt, idx, i;
+
+	qos_request = kzalloc(sizeof(*qos_request), GFP_KERNEL);
+	if (!qos_request)
+		return -ENOMEM;
+
+	/* Let CPUs leave idle-off state for initializing svs_init01. */
+	cpu_latency_qos_add_request(qos_request, 0);
+
+	/*
+	 * Sometimes two svs banks use the same buck.
+	 * Therefore, we set each svs bank to vboot voltage first.
+	 */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		search_done = false;
+
+		if (svsb->pd_req) {
+			ret = regulator_enable(svsb->buck);
+			if (ret) {
+				dev_err(svsb->dev, "%s enable fail: %d\n",
+					svsb->buck_name, ret);
+				goto init01_finish;
+			}
+
+			if (!pm_runtime_enabled(svsb->pd_dev)) {
+				pm_runtime_enable(svsb->pd_dev);
+				svsb->enable_pm_runtime_ever = true;
+			}
+
+			ret = pm_runtime_get_sync(svsb->pd_dev);
+			if (ret < 0) {
+				dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
+				goto init01_finish;
+			}
+		}
+
+		if (regulator_set_mode(svsb->buck, REGULATOR_MODE_FAST))
+			dev_notice(svsb->dev, "set fast mode fail\n");
+
+		/*
+		 * Find the fastest freq that can be run at vboot and
+		 * fix to that freq until svs_init01 is done.
+		 */
+		opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+						      svsb->volt_step,
+						      svsb->volt_base);
+
+		for (i = 0; i < svsb->opp_count; i++) {
+			opp_freqs = svsb->opp_freqs[i];
+			if (!search_done && svsb->opp_volts[i] <= opp_vboot) {
+				ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+								opp_freqs,
+								opp_vboot,
+								opp_vboot,
+								opp_vboot);
+				if (ret) {
+					dev_err(svsb->dev,
+						"set voltage fail: %d\n", ret);
+					goto init01_finish;
+				}
+
+				search_done = true;
+			} else {
+				dev_pm_opp_disable(svsb->opp_dev,
+						   svsb->opp_freqs[i]);
+			}
+		}
+	}
+
+	/* svs bank init01 begins */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+						      svsb->volt_step,
+						      svsb->volt_base);
+
+		buck_volt = regulator_get_voltage(svsb->buck);
+		if (buck_volt != opp_vboot) {
+			dev_err(svsb->dev,
+				"buck voltage: %u, expected vboot: %u\n",
+				buck_volt, opp_vboot);
+			ret = -EPERM;
+			goto init01_finish;
+		}
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_INIT01);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		time_left =
+			wait_for_completion_timeout(&svsb->init_completion,
+						    msecs_to_jiffies(5000));
+		if (!time_left) {
+			dev_err(svsb->dev, "init01 completion timeout\n");
+			ret = -EBUSY;
+			goto init01_finish;
+		}
+	}
+
+init01_finish:
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		for (i = 0; i < svsb->opp_count; i++)
+			dev_pm_opp_enable(svsb->opp_dev, svsb->opp_freqs[i]);
+
+		if (regulator_set_mode(svsb->buck, REGULATOR_MODE_NORMAL))
+			dev_notice(svsb->dev, "fail to set normal mode\n");
+
+		if (svsb->pd_req) {
+			if (pm_runtime_put_sync(svsb->pd_dev))
+				dev_err(svsb->dev, "mtcmos off fail\n");
+
+			if (svsb->enable_pm_runtime_ever) {
+				pm_runtime_disable(svsb->pd_dev);
+				svsb->enable_pm_runtime_ever = false;
+			}
+
+			if (regulator_disable(svsb->buck))
+				dev_err(svsb->dev, "%s disable fail: %d\n",
+					svsb->buck_name, ret);
+		}
+	}
+
+	cpu_latency_qos_remove_request(qos_request);
+	kfree(qos_request);
+
+	return ret;
+}
+
+static int svs_start(struct svs_platform *svsp)
+{
+	int ret;
+
+	ret = svs_init01(svsp);
+	if (ret)
+		return ret;
+
+	ret = svs_init02(svsp);
+	if (ret)
+		return ret;
+
+	svs_mon_mode(svsp);
+
+	return 0;
+}
+
+static struct device *svs_get_subsys_device(struct svs_platform *svsp,
+					    const char *node_name)
+{
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	np = of_find_node_by_name(NULL, node_name);
+	if (!np) {
+		dev_err(svsp->dev, "cannot find %s node\n", node_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev) {
+		of_node_put(np);
+		dev_err(svsp->dev, "cannot find pdev by %s\n", node_name);
+		return ERR_PTR(-ENXIO);
+	}
+
+	of_node_put(np);
+
+	return &pdev->dev;
+}
+
+static struct device *svs_add_device_link(struct svs_platform *svsp,
+					  const char *node_name)
+{
+	struct device *dev;
+	struct device_link *sup_link;
+
+	if (!node_name) {
+		dev_err(svsp->dev, "node name cannot be null\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	dev = svs_get_subsys_device(svsp, node_name);
+	if (IS_ERR(dev))
+		return dev;
+
+	sup_link = device_link_add(svsp->dev, dev,
+				   DL_FLAG_AUTOREMOVE_CONSUMER);
+	if (!sup_link) {
+		dev_err(svsp->dev, "sup_link is NULL\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return dev;
+}
+
+static int svs_resource_setup(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct dev_pm_opp *opp;
+	unsigned long freq;
+	int count, ret;
+	u32 idx, i;
+
+	dev_set_drvdata(svsp->dev, svsp);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			svsb->name = "SVSB_CPU_LITTLE";
+			break;
+		case SVSB_CPU_BIG:
+			svsb->name = "SVSB_CPU_BIG";
+			break;
+		case SVSB_CCI:
+			svsb->name = "SVSB_CCI";
+			break;
+		case SVSB_GPU:
+			svsb->name = "SVSB_GPU";
+			break;
+		default:
+			WARN_ON(1);
+			return -EINVAL;
+		}
+
+		svsb->dev = devm_kzalloc(svsp->dev, sizeof(*svsb->dev),
+					 GFP_KERNEL);
+		if (!svsb->dev)
+			return -ENOMEM;
+
+		ret = dev_set_name(svsb->dev, "%s", svsb->name);
+		if (ret)
+			return ret;
+
+		dev_set_drvdata(svsb->dev, svsp);
+
+		ret = dev_pm_opp_of_add_table(svsb->opp_dev);
+		if (ret) {
+			dev_err(svsb->dev, "add opp table fail: %d\n", ret);
+			return ret;
+		}
+
+		mutex_init(&svsb->lock);
+		init_completion(&svsb->init_completion);
+
+		svsb->buck = devm_regulator_get_optional(svsb->opp_dev,
+							 svsb->buck_name);
+		if (IS_ERR(svsb->buck)) {
+			dev_err(svsb->dev, "cannot get \"%s-supply\"\n",
+				svsb->buck_name);
+			return PTR_ERR(svsb->buck);
+		}
+
+		count = dev_pm_opp_get_opp_count(svsb->opp_dev);
+		if (svsb->opp_count != count) {
+			dev_err(svsb->dev,
+				"opp_count not \"%u\" but get \"%d\"?\n",
+				svsb->opp_count, count);
+			return count;
+		}
+
+		for (i = 0, freq = U32_MAX; i < svsb->opp_count; i++, freq--) {
+			opp = dev_pm_opp_find_freq_floor(svsb->opp_dev, &freq);
+			if (IS_ERR(opp)) {
+				dev_err(svsb->dev, "cannot find freq = %ld\n",
+					PTR_ERR(opp));
+				return PTR_ERR(opp);
+			}
+
+			svsb->opp_freqs[i] = freq;
+			svsb->opp_volts[i] = dev_pm_opp_get_voltage(opp);
+			svsb->freqs_pct[i] = percent(svsb->opp_freqs[i],
+						     svsb->freq_base);
+			dev_pm_opp_put(opp);
+		}
+	}
+
+	return 0;
+}
+
+static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
+{
+	struct thermal_parameter tp;
+	struct svs_bank *svsb;
+	bool mon_mode_support = true;
+	int format[6], x_roomt[6], tb_roomt = 0;
+	struct nvmem_cell *cell;
+	u32 idx, i, ft_pgm, mts, temp0, temp1, temp2;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse[i])
+			dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+				 i, svsp->efuse[i]);
+
+	/* Svs efuse parsing */
+	ft_pgm = (svsp->efuse[0] >> 4) & GENMASK(3, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (ft_pgm <= 1)
+			svsb->init01_volt_flag = SVSB_INIT01_VOLT_IGNORE;
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			svsb->bdes = svsp->efuse[16] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[16] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[16] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[16] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 10;
+			else
+				svsb->volt_offset += 2;
+			break;
+		case SVSB_CPU_BIG:
+			svsb->bdes = svsp->efuse[18] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[18] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[18] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[18] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = svsp->efuse[17] & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 15;
+			else
+				svsb->volt_offset += 12;
+			break;
+		case SVSB_CCI:
+			svsb->bdes = svsp->efuse[4] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[4] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[4] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[4] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = (svsp->efuse[5] >> 16) & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 10;
+			else
+				svsb->volt_offset += 2;
+			break;
+		case SVSB_GPU:
+			svsb->bdes = svsp->efuse[6] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[6] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[6] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[6] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = svsp->efuse[5] & GENMASK(7, 0);
+
+			if (ft_pgm >= 2) {
+				svsb->freq_base = 800000000; /* 800MHz */
+				svsb->dvt_fixed = 2;
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	/* Get thermal efuse by nvmem */
+	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev, "no thermal cell, no mon mode\n");
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_num);
+	svsp->tefuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	/* Thermal efuse parsing */
+	tp.adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
+	tp.adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
+
+	tp.o_vtsmcu1 = (svsp->tefuse[0] >> 17) & GENMASK(8, 0);
+	tp.o_vtsmcu2 = (svsp->tefuse[0] >> 8) & GENMASK(8, 0);
+	tp.o_vtsmcu3 = svsp->tefuse[1] & GENMASK(8, 0);
+	tp.o_vtsmcu4 = (svsp->tefuse[2] >> 23) & GENMASK(8, 0);
+	tp.o_vtsmcu5 = (svsp->tefuse[2] >> 5) & GENMASK(8, 0);
+	tp.o_vtsabb = (svsp->tefuse[2] >> 14) & GENMASK(8, 0);
+
+	tp.degc_cali = (svsp->tefuse[0] >> 1) & GENMASK(5, 0);
+	tp.adc_cali_en_t = svsp->tefuse[0] & BIT(0);
+	tp.o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
+
+	tp.ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
+	tp.o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+
+	if (tp.adc_cali_en_t == 1) {
+		if (!tp.ts_id)
+			tp.o_slope = 0;
+
+		if ((tp.adc_ge_t < 265 || tp.adc_ge_t > 758) ||
+		    (tp.adc_oe_t < 265 || tp.adc_oe_t > 758) ||
+		    (tp.o_vtsmcu1 < -8 || tp.o_vtsmcu1 > 484) ||
+		    (tp.o_vtsmcu2 < -8 || tp.o_vtsmcu2 > 484) ||
+		    (tp.o_vtsmcu3 < -8 || tp.o_vtsmcu3 > 484) ||
+		    (tp.o_vtsmcu4 < -8 || tp.o_vtsmcu4 > 484) ||
+		    (tp.o_vtsmcu5 < -8 || tp.o_vtsmcu5 > 484) ||
+		    (tp.o_vtsabb < -8 || tp.o_vtsabb > 484) ||
+		    (tp.degc_cali < 1 || tp.degc_cali > 63)) {
+			dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
+			mon_mode_support = false;
+		}
+	} else {
+		dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+		mon_mode_support = false;
+	}
+
+	if (!mon_mode_support) {
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	tp.ge = ((tp.adc_ge_t - 512) * 10000) / 4096;
+	tp.oe = (tp.adc_oe_t - 512);
+	tp.gain = (10000 + tp.ge);
+
+	format[0] = (tp.o_vtsmcu1 + 3350 - tp.oe);
+	format[1] = (tp.o_vtsmcu2 + 3350 - tp.oe);
+	format[2] = (tp.o_vtsmcu3 + 3350 - tp.oe);
+	format[3] = (tp.o_vtsmcu4 + 3350 - tp.oe);
+	format[4] = (tp.o_vtsmcu5 + 3350 - tp.oe);
+	format[5] = (tp.o_vtsabb + 3350 - tp.oe);
+
+	for (i = 0; i < 6; i++)
+		x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / tp.gain;
+
+	temp0 = (10000 * 100000 / tp.gain) * 15 / 18;
+
+	if (!tp.o_slope_sign)
+		mts = (temp0 * 10) / (1534 + tp.o_slope * 10);
+	else
+		mts = (temp0 * 10) / (1534 - tp.o_slope * 10);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		svsb->mts = mts;
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			tb_roomt = x_roomt[3];
+			break;
+		case SVSB_CPU_BIG:
+			tb_roomt = x_roomt[4];
+			break;
+		case SVSB_CCI:
+			tb_roomt = x_roomt[3];
+			break;
+		case SVSB_GPU:
+			tb_roomt = x_roomt[1];
+			break;
+		default:
+			break;
+		}
+
+		temp0 = (tp.degc_cali * 10 / 2);
+		temp1 = ((10000 * 100000 / 4096 / tp.gain) *
+			 tp.oe + tb_roomt * 10) * 15 / 18;
+
+		if (!tp.o_slope_sign)
+			temp2 = temp1 * 100 / (1534 + tp.o_slope * 10);
+		else
+			temp2 = temp1 * 100 / (1534 - tp.o_slope * 10);
+
+		svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
+	}
+
+	return true;
+}
+
+static bool svs_is_supported(struct svs_platform *svsp)
+{
+	struct nvmem_cell *cell;
+
+	/* Get svs efuse by nvmem */
+	cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev,
+			"no \"svs-calibration-data\" from dts? disable svs\n");
+		return false;
+	}
+
+	svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_num);
+	svsp->efuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	if (!svsp->efuse[svsp->efuse_check]) {
+		dev_err(svsp->dev, "svs_efuse[%u] = 0x%x?\n",
+			svsp->efuse_check, svsp->efuse[svsp->efuse_check]);
+		return false;
+	}
+
+	return svsp->efuse_parsing(svsp);
+}
+
+static int svs_suspend(struct device *dev)
+{
+	struct svs_platform *svsp = dev_get_drvdata(dev);
+	struct svs_bank *svsb;
+	unsigned long flags;
+	int ret;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		/* Wait if svs_isr() is still in process. */
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_switch_bank(svsp);
+		svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+		svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		svsb->suspended = true;
+		if (svsb->phase != SVSB_PHASE_INIT01) {
+			svsb->phase = SVSB_PHASE_ERROR;
+			svs_adjust_pm_opp_volts(svsb, true);
+		}
+	}
+
+	if (svsp->rst) {
+		ret = reset_control_assert(svsp->rst);
+		if (ret) {
+			dev_err(svsp->dev, "cannot assert reset %d\n", ret);
+			return ret;
+		}
+	}
+
+	clk_disable_unprepare(svsp->main_clk);
+
+	return 0;
+}
+
+static int svs_resume(struct device *dev)
+{
+	struct svs_platform *svsp = dev_get_drvdata(dev);
+	struct svs_bank *svsb;
+	int ret;
+	u32 idx;
+
+	ret = clk_prepare_enable(svsp->main_clk);
+	if (ret) {
+		dev_err(svsp->dev, "cannot enable main_clk, disable svs\n");
+		return ret;
+	}
+
+	if (svsp->rst) {
+		ret = reset_control_deassert(svsp->rst);
+		if (ret) {
+			dev_err(svsp->dev, "cannot deassert reset %d\n", ret);
+			return ret;
+		}
+	}
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		svsb->suspended = false;
+	}
+
+	ret = svs_init02(svsp);
+	if (ret)
+		return ret;
+
+	svs_mon_mode(svsp);
+
+	return 0;
+}
+
+static struct svs_bank svs_mt8183_banks[] = {
+	{
+		.sw_id			= SVSB_CPU_LITTLE,
+		.cpu_id			= 0,
+		.tzone_name		= "tzts4",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.init01_volt_flag	= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1989000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x64,
+		.vmin			= 0x18,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0000,
+		.int_st			= BIT(0),
+		.ctl0			= 0x00010001,
+	},
+	{
+		.sw_id			= SVSB_CPU_BIG,
+		.cpu_id			= 4,
+		.tzone_name		= "tzts5",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.init01_volt_flag	= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1989000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x58,
+		.vmin			= 0x10,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0001,
+		.int_st			= BIT(1),
+		.ctl0			= 0x00000001,
+	},
+	{
+		.sw_id			= SVSB_CCI,
+		.tzone_name		= "tzts4",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.init01_volt_flag	= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1196000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x64,
+		.vmin			= 0x18,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0002,
+		.int_st			= BIT(2),
+		.ctl0			= 0x00100003,
+	},
+	{
+		.sw_id			= SVSB_GPU,
+		.tzone_name		= "tzts2",
+		.buck_name		= "mali",
+		.pd_req			= true,
+		.init01_volt_flag	= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02 |
+					  SVSB_MODE_MON,
+		.opp_count		= 16,
+		.freq_base		= 900000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x40,
+		.vmin			= 0x14,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x3,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 3,
+		.core_sel		= 0x8fff0003,
+		.int_st			= BIT(3),
+		.ctl0			= 0x00050001,
+	},
+};
+
+static int svs_get_svs_mt8183_platform_data(struct svs_platform *svsp)
+{
+	struct device *dev;
+	struct svs_bank *svsb;
+	u32 idx;
+
+	svsp->name = "mt8183-svs";
+	svsp->banks = svs_mt8183_banks;
+	svsp->efuse_parsing = svs_mt8183_efuse_parsing;
+	svsp->set_freqs_pct = svs_set_freqs_pct_v2;
+	svsp->get_vops = svs_get_vops_v2;
+	svsp->regs = svs_regs_v2;
+	svsp->irqflags = IRQF_TRIGGER_LOW | IRQF_ONESHOT;
+	svsp->rst = NULL;
+	svsp->bank_num = ARRAY_SIZE(svs_mt8183_banks);
+	svsp->efuse_check = 2;
+
+	dev = svs_add_device_link(svsp, "thermal");
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+		case SVSB_CPU_BIG:
+			svsb->opp_dev = get_cpu_device(svsb->cpu_id);
+			break;
+		case SVSB_CCI:
+			svsb->opp_dev = svs_add_device_link(svsp, "cci");
+			break;
+		case SVSB_GPU:
+			svsb->opp_dev = svs_add_device_link(svsp, "mali");
+			svsb->pd_dev = svs_add_device_link(svsp,
+							   "mali_gpu_core2");
+			if (IS_ERR(svsb->pd_dev))
+				return PTR_ERR(svsb->pd_dev);
+			break;
+		default:
+			WARN_ON(1);
+			return -EINVAL;
+		}
+
+		if (IS_ERR(svsb->opp_dev))
+			return PTR_ERR(svsb->opp_dev);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id mtk_svs_of_match[] = {
+	{
+		.compatible = "mediatek,mt8183-svs",
+		.data = &svs_get_svs_mt8183_platform_data,
+	}, {
+		/* Sentinel */
+	},
+};
+
+static int svs_probe(struct platform_device *pdev)
+{
+	int (*svs_get_svs_platform_data)(struct svs_platform *svsp);
+	struct svs_platform *svsp;
+	unsigned int svsp_irq;
+	int ret;
+
+	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
+	if (!svsp)
+		return -ENOMEM;
+
+	svs_get_svs_platform_data = of_device_get_match_data(&pdev->dev);
+	if (!svs_get_svs_platform_data) {
+		dev_err(svsp->dev, "no svs platform data? why?\n");
+		return -EPERM;
+	}
+
+	svsp->dev = &pdev->dev;
+	ret = svs_get_svs_platform_data(svsp);
+	if (ret) {
+		dev_err_probe(svsp->dev, ret, "fail to get svsp data\n");
+		return ret;
+	}
+
+	if (!svs_is_supported(svsp)) {
+		dev_notice(svsp->dev, "svs is not supported\n");
+		return -EPERM;
+	}
+
+	ret = svs_resource_setup(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs resource setup fail: %d\n", ret);
+		return ret;
+	}
+
+	svsp_irq = irq_of_parse_and_map(svsp->dev->of_node, 0);
+	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+					svsp->irqflags, svsp->name, svsp);
+	if (ret) {
+		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+			svsp_irq, ret);
+		return ret;
+	}
+
+	svsp->main_clk = devm_clk_get(svsp->dev, "main");
+	if (IS_ERR(svsp->main_clk)) {
+		dev_err(svsp->dev, "failed to get clock: %ld\n",
+			PTR_ERR(svsp->main_clk));
+		return PTR_ERR(svsp->main_clk);
+	}
+
+	ret = clk_prepare_enable(svsp->main_clk);
+	if (ret) {
+		dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
+		return ret;
+	}
+
+	svsp->base = of_iomap(svsp->dev->of_node, 0);
+	if (IS_ERR_OR_NULL(svsp->base)) {
+		dev_err(svsp->dev, "cannot find svs register base\n");
+		ret = -EINVAL;
+		goto svs_probe_clk_disable;
+	}
+
+	ret = svs_start(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs start fail: %d\n", ret);
+		goto svs_probe_iounmap;
+	}
+
+	return 0;
+
+svs_probe_iounmap:
+	iounmap(svsp->base);
+
+svs_probe_clk_disable:
+	clk_disable_unprepare(svsp->main_clk);
+
+	return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(svs_pm_ops, svs_suspend, svs_resume);
+
+static struct platform_driver svs_driver = {
+	.probe	= svs_probe,
+	.driver	= {
+		.name		= "mtk-svs",
+		.pm		= &svs_pm_ops,
+		.of_match_table	= of_match_ptr(mtk_svs_of_match),
+	},
+};
+
+module_platform_driver(svs_driver);
+
+MODULE_AUTHOR("Roger Lu <roger.lu at mediatek.com>");
+MODULE_DESCRIPTION("MediaTek SVS driver");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0

From roger.lu at mediatek.com  Fri Apr  9 10:28:23 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:23 +0800
Subject: [PATCH v15 2/7] arm64: dts: mt8183: add svs device information
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-3-roger.lu@mediatek.com>

add compitable/reg/irq/clock/efuse setting in svs node

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145f13..441d617ece43 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -657,6 +657,18 @@
 			status = "disabled";
 		};
 
+		svs: svs at 1100b000 {
+			compatible = "mediatek,mt8183-svs";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&infracfg CLK_INFRA_THERM>;
+			clock-names = "main";
+			nvmem-cells = <&svs_calibration>,
+				      <&thermal_calibration>;
+			nvmem-cell-names = "svs-calibration-data",
+					   "t-calibration-data";
+		};
+
 		pwm0: pwm at 1100e000 {
 			compatible = "mediatek,mt8183-disp-pwm";
 			reg = <0 0x1100e000 0 0x1000>;
@@ -941,9 +953,15 @@
 			reg = <0 0x11f10000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			thermal_calibration: calib at 180 {
+				reg = <0x180 0xc>;
+			};
 			mipi_tx_calibration: calib at 190 {
 				reg = <0x190 0xc>;
 			};
+			svs_calibration: calib at 580 {
+				reg = <0x580 0x64>;
+			};
 		};
 
 		u3phy: usb-phy at 11f40000 {
-- 
2.18.0

From roger.lu at mediatek.com  Fri Apr  9 10:28:28 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Fri, 9 Apr 2021 17:28:28 +0800
Subject: [PATCH v15 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
In-Reply-To: <20210409092828.23939-1-roger.lu@mediatek.com>
References: <20210409092828.23939-1-roger.lu@mediatek.com>
Message-ID: <20210409092828.23939-8-roger.lu@mediatek.com>

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 477 ++++++++++++++++++++++++++++++++-
 1 file changed, 471 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 39f29d9e4fc7..e179ad7c2b35 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -36,6 +36,10 @@
 #define SVSB_CCI			BIT(2)
 #define SVSB_GPU			BIT(3)
 
+/* svs bank 2-line type */
+#define SVSB_LOW			BIT(4)
+#define SVSB_HIGH			BIT(5)
+
 /* svs bank mode support */
 #define SVSB_MODE_ALL_DISABLE		0
 #define SVSB_MODE_INIT01		BIT(1)
@@ -281,6 +285,7 @@ struct thermal_parameter {
  * @volts: bank voltages
  * @reg_data: bank register data of each phase
  * @freq_base: reference frequency for bank init
+ * @turn_freq_base: refenrece frequency for turn point
  * @vboot: voltage request for bank init01 stage only
  * @volt_step: bank voltage step
  * @volt_base: bank voltage base
@@ -301,6 +306,8 @@ struct thermal_parameter {
  * @hw_id: bank hardware identification
  * @ctl0: bank thermal sensor selection
  * @cpu_id: cpu core id for SVS CPU only
+ * @turn_pt: turn point informs which opp_volt calculated by high/low bank.
+ * @type: bank type to represent it is 2-line (high/low) bank or 1-line bank.
  *
  * Other structure members which are not listed above are svs platform
  * efuse data for bank init
@@ -327,6 +334,7 @@ struct svs_bank {
 	u32 volts[16];
 	u32 reg_data[SVSB_PHASE_NUM][SVS_REG_NUM];
 	u32 freq_base;
+	u32 turn_freq_base;
 	u32 vboot;
 	u32 volt_step;
 	u32 volt_base;
@@ -366,6 +374,8 @@ struct svs_bank {
 	u32 hw_id;
 	u32 ctl0;
 	u32 cpu_id;
+	u32 turn_pt;
+	u32 type;
 };
 
 /*
@@ -443,6 +453,37 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
 	return (svsb_volt * svsb_volt_step) + svsb_volt_base;
 }
 
+static u32 svs_opp_volt_to_bank_volt(u32 opp_u_volt, u32 svsb_volt_step,
+				     u32 svsb_volt_base)
+{
+	return (opp_u_volt - svsb_volt_base) / svsb_volt_step;
+}
+
+static int svs_sync_bank_volts_from_opp(struct svs_bank *svsb)
+{
+	struct dev_pm_opp *opp;
+	u32 i, opp_u_volt;
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+						 svsb->opp_freqs[i],
+						 true);
+		if (IS_ERR(opp)) {
+			dev_err(svsb->dev, "cannot find freq = %u (%ld)\n",
+				svsb->opp_freqs[i], PTR_ERR(opp));
+			return PTR_ERR(opp);
+		}
+
+		opp_u_volt = dev_pm_opp_get_voltage(opp);
+		svsb->volts[i] = svs_opp_volt_to_bank_volt(opp_u_volt,
+							   svsb->volt_step,
+							   svsb->volt_base);
+		dev_pm_opp_put(opp);
+	}
+
+	return 0;
+}
+
 static int svs_get_bank_zone_temperature(const char *tzone_name,
 					 int *tzone_temp)
 {
@@ -458,7 +499,7 @@ static int svs_get_bank_zone_temperature(const char *tzone_name,
 static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 {
 	int tzone_temp = 0, ret = -EPERM;
-	u32 i, svsb_volt, opp_volt, temp_offset = 0;
+	u32 i, svsb_volt, opp_volt, temp_offset = 0, opp_start, opp_stop;
 
 	mutex_lock(&svsb->lock);
 
@@ -472,6 +513,21 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 		goto unlock_mutex;
 	}
 
+	/*
+	 * 2-line bank updates its corresponding opp volts.
+	 * 1-line bank updates all opp volts.
+	 */
+	if (svsb->type == SVSB_HIGH) {
+		opp_start = 0;
+		opp_stop = svsb->turn_pt;
+	} else if (svsb->type == SVSB_LOW) {
+		opp_start = svsb->turn_pt;
+		opp_stop = svsb->opp_count;
+	} else {
+		opp_start = 0;
+		opp_stop = svsb->opp_count;
+	}
+
 	/* Get thermal effect */
 	if (svsb->phase == SVSB_PHASE_MON) {
 		if (svsb->temp > svsb->temp_upper_bound &&
@@ -493,10 +549,16 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 			temp_offset += svsb->tzone_high_temp_offset;
 		else if (tzone_temp <= svsb->tzone_low_temp)
 			temp_offset += svsb->tzone_low_temp_offset;
+
+		/* 2-line bank takes thermal factor to update all opp volts */
+		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+			opp_start = 0;
+			opp_stop = svsb->opp_count;
+		}
 	}
 
 	/* vmin <= svsb_volt (opp_volt) <= signed-off (default) voltage */
-	for (i = 0; i < svsb->opp_count; i++) {
+	for (i = opp_start; i < opp_stop; i++) {
 		if (svsb->phase == SVSB_PHASE_MON) {
 			svsb_volt = max(svsb->volts[i] + svsb->volt_offset +
 					temp_offset, svsb->vmin);
@@ -547,6 +609,182 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
 	return DIV_ROUND_UP(vx, 100);
 }
 
+static void svs_get_vops_v3(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 i, vop_i, *vop, vop74, vop30, mask7_0 = GENMASK(7, 0);
+	u32 b_sft, bits8 = 8, shift_byte = 0, reg_4bytes = 4;
+	u32 middle_index = (svsb->opp_count / 2);
+	u32 opp_start = 0, opp_stop = 0, turn_pt = svsb->turn_pt;
+
+	/* get vops v3 doesn't use mon mode voltages */
+	if (svsb->phase == SVSB_PHASE_MON)
+		return;
+
+	vop74 = svs_readl(svsp, VOP74);
+	vop30 = svs_readl(svsp, VOP30);
+
+	if (turn_pt < middle_index) {
+		if (svsb->type == SVSB_HIGH) {
+			/* We attain volts[0 ~ (turn_pt - 1)] */
+			for (i = 0; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/*
+			 * We attain volts[turn_pt] +
+			 * volts[vop_i ~ (opp_count - 1)]
+			 */
+			vop_i = svsb->opp_count - 7;
+			svsb->volts[turn_pt] = vop30 & mask7_0;
+			shift_byte++;
+			for (i = vop_i; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+
+			/*
+			 * We attain volts[turn_pt + 1 ~ (vop_i - 1)]
+			 * by interpolate
+			 */
+			for (i = turn_pt + 1; i < vop_i; i++)
+				svsb->volts[i] =
+					interpolate(svsb->freqs_pct[turn_pt],
+						    svsb->freqs_pct[vop_i],
+						    svsb->volts[turn_pt],
+						    svsb->volts[vop_i],
+						    svsb->freqs_pct[i]);
+		}
+	} else {
+		if (svsb->type == SVSB_HIGH) {
+			/* We attain volts[0] + volts[vop_i ~ (turn_pt - 1)] */
+			vop_i = turn_pt - 7;
+			svsb->volts[0] = vop30 & mask7_0;
+			shift_byte++;
+			for (i = vop_i; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+
+			/* We attain volts[1 ~ (vop_i - 1)] by interpolate */
+			for (i = 1; i < vop_i; i++)
+				svsb->volts[i] =
+					interpolate(svsb->freqs_pct[0],
+						    svsb->freqs_pct[vop_i],
+						    svsb->volts[0],
+						    svsb->volts[vop_i],
+						    svsb->freqs_pct[i]);
+		} else if (svsb->type == SVSB_LOW) {
+			/* We attain volts[turn_pt ~ (opp_count - 1)] */
+			for (i = turn_pt; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+		}
+	}
+
+	if (svsb->type == SVSB_HIGH) {
+		opp_start = 0;
+		opp_stop = svsb->turn_pt;
+	} else if (svsb->type == SVSB_LOW) {
+		opp_start = svsb->turn_pt;
+		opp_stop = svsb->opp_count;
+	}
+
+	for (i = opp_start; i < opp_stop; i++)
+		svsb->volts[i] -= svsb->dvt_fixed;
+}
+
+static void svs_set_freqs_pct_v3(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 i, freq_i, *freq_pct, freq_pct74 = 0;
+	u32 freq_pct30 = svsb->freqs_pct[0];
+	u32 b_sft, bits8 = 8, shift_byte = 0, reg_4bytes = 4;
+	u32 middle_index = (svsb->opp_count / 2);
+	u32 turn_pt = middle_index;
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		if (svsb->opp_freqs[i] <= svsb->turn_freq_base) {
+			svsb->turn_pt = i;
+			break;
+		}
+	}
+
+	turn_pt = svsb->turn_pt;
+
+	/* Target is to fill out freq_pct74 / freq_pct30 */
+	if (turn_pt < middle_index) {
+		if (svsb->type == SVSB_HIGH) {
+			/* We select freqs_pct[0 ~ (turn_pt - 1)] */
+			for (i = 0; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/*
+			 * We select freqs_pct[turn_pt] +
+			 * freqs_pct[(opp_count - 7) ~ (opp_count -1)]
+			 */
+			freq_pct30 = svsb->freqs_pct[turn_pt];
+			shift_byte++;
+			freq_i = svsb->opp_count - 7;
+			for (i = freq_i; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		}
+	} else {
+		if (svsb->type == SVSB_HIGH) {
+			/*
+			 * We select freqs_pct[0] +
+			 * freqs_pct[(turn_pt - 7) ~ (turn_pt - 1)]
+			 */
+			freq_pct30 = svsb->freqs_pct[0];
+			shift_byte++;
+			freq_i = turn_pt - 7;
+			for (i = freq_i; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/* We select freqs_pct[turn_pt ~ (opp_count - 1)] */
+			for (i = turn_pt; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		}
+	}
+
+	svs_writel(svsp, freq_pct74, FREQPCT74);
+	svs_writel(svsp, freq_pct30, FREQPCT30);
+}
+
 static void svs_get_vops_v2(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
@@ -858,6 +1096,25 @@ static int svs_init02(struct svs_platform *svsp)
 		}
 	}
 
+	/*
+	 * 2-line high/low bank update its corresponding opp voltages only.
+	 * Therefore, we sync voltages from opp for high/low bank voltages
+	 * consistency.
+	 */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT02))
+			continue;
+
+		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+			if (svs_sync_bank_volts_from_opp(svsb)) {
+				dev_err(svsb->dev, "sync volt fail\n");
+				return -EPERM;
+			}
+		}
+	}
+
 	return 0;
 }
 
@@ -1104,7 +1361,12 @@ static int svs_resource_setup(struct svs_platform *svsp)
 			svsb->name = "SVSB_CCI";
 			break;
 		case SVSB_GPU:
-			svsb->name = "SVSB_GPU";
+			if (svsb->type == SVSB_HIGH)
+				svsb->name = "SVSB_GPU_HIGH";
+			else if (svsb->type == SVSB_LOW)
+				svsb->name = "SVSB_GPU_LOW";
+			else
+				svsb->name = "SVSB_GPU";
 			break;
 		default:
 			WARN_ON(1);
@@ -1166,6 +1428,88 @@ static int svs_resource_setup(struct svs_platform *svsp)
 	return 0;
 }
 
+static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct nvmem_cell *cell;
+	u32 idx, i, ft_pgm, vmin, golden_temp;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse[i])
+			dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+				 i, svsp->efuse[i]);
+
+	/* Svs efuse parsing */
+	ft_pgm = svsp->efuse[0] & GENMASK(7, 0);
+	vmin = (svsp->efuse[19] >> 4) & GENMASK(1, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->sw_id != SVSB_GPU)
+			return false;
+
+		if (vmin == 0x1)
+			svsb->vmin = 0x1e;
+
+		if (ft_pgm == 0)
+			svsb->init01_volt_flag = SVSB_INIT01_VOLT_IGNORE;
+
+		if (svsb->type == SVSB_LOW) {
+			svsb->mtdes = svsp->efuse[10] & GENMASK(7, 0);
+			svsb->bdes = (svsp->efuse[10] >> 16) & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[10] >> 24) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[17]) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[17] >> 8) & GENMASK(7, 0);
+			svsb->vmax += svsb->dvt_fixed;
+		} else if (svsb->type == SVSB_HIGH) {
+			svsb->mtdes = svsp->efuse[9] & GENMASK(7, 0);
+			svsb->bdes = (svsp->efuse[9] >> 16) & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[9] >> 24) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[17] >> 24) & GENMASK(7, 0);
+			svsb->vmax += svsb->dvt_fixed;
+		}
+	}
+
+	/* Thermal efuse parsing */
+	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev, "no thermal cell, no mon mode\n");
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_num);
+	svsp->tefuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	for (i = 0; i < svsp->tefuse_num; i++)
+		if (svsp->tefuse[i] != 0)
+			break;
+
+	if (i == svsp->tefuse_num)
+		golden_temp = 50; /* All thermal efuse data are 0 */
+	else
+		golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->sw_id != SVSB_GPU)
+			return false;
+
+		svsb->mts = 500;
+		svsb->bts = (((500 * golden_temp + 250460) / 1000) - 25) * 4;
+	}
+
+	return true;
+}
+
 static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 {
 	struct thermal_parameter tp;
@@ -1588,10 +1932,11 @@ static int svs_status_debug_show(struct seq_file *m, void *v)
 
 	ret = svs_get_bank_zone_temperature(svsb->tzone_name, &tzone_temp);
 	if (ret)
-		seq_printf(m, "%s: no \"%s\" zone?\n", svsb->name,
-			   svsb->tzone_name);
+		seq_printf(m, "%s: no \"%s\" zone? turn_pt = %u\n",
+			   svsb->name, svsb->tzone_name, svsb->turn_pt);
 	else
-		seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+		seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
+			   svsb->name, tzone_temp, svsb->turn_pt);
 
 	for (i = 0; i < svsb->opp_count; i++) {
 		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
@@ -1724,6 +2069,81 @@ static int svs_create_svs_debug_cmds(struct svs_platform *svsp)
 	return 0;
 }
 
+static struct svs_bank svs_mt8192_banks[] = {
+	{
+		.sw_id			= SVSB_GPU,
+		.hw_id			= 0,
+		.tzone_name		= "gpu1",
+		.buck_name		= "mali",
+		.mode_support		= SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 688000000,
+		.turn_freq_base		= 688000000,
+		.vboot			= 0x38,
+		.volt_step		= 6250,
+		.volt_base		= 400000,
+		.volt_offset		= 0,
+		.vmax			= 0x60,
+		.vmin			= 0x1a,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x1,
+		.dvt_fixed		= 0x1,
+		.vco			= 0x18,
+		.chk_shift		= 0x87,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= 85000,
+		.tzone_high_temp_offset	= 0,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 7,
+		.core_sel		= 0x0fff0100,
+		.int_st			= BIT(0),
+		.ctl0			= 0x00540003,
+		.type			= SVSB_LOW,
+	},
+	{
+		.sw_id			= SVSB_GPU,
+		.hw_id			= 1,
+		.tzone_name		= "gpu1",
+		.buck_name		= "mali",
+		.mode_support		= SVSB_MODE_INIT02 | SVSB_MODE_MON,
+		.opp_count		= 16,
+		.freq_base		= 902000000,
+		.turn_freq_base		= 688000000,
+		.vboot			= 0x38,
+		.volt_step		= 6250,
+		.volt_base		= 400000,
+		.volt_offset		= 0,
+		.vmax			= 0x60,
+		.vmin			= 0x1a,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x1,
+		.dvt_fixed		= 0x6,
+		.vco			= 0x18,
+		.chk_shift		= 0x87,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= 85000,
+		.tzone_high_temp_offset	= 0,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 7,
+		.core_sel		= 0x0fff0101,
+		.int_st			= BIT(1),
+		.ctl0			= 0x00540003,
+		.type			= SVSB_HIGH,
+	},
+};
+
 static struct svs_bank svs_mt8183_banks[] = {
 	{
 		.sw_id			= SVSB_CPU_LITTLE,
@@ -1870,6 +2290,48 @@ static struct svs_bank svs_mt8183_banks[] = {
 	},
 };
 
+static int svs_get_svs_mt8192_platform_data(struct svs_platform *svsp)
+{
+	struct device *dev;
+	struct svs_bank *svsb;
+	u32 idx;
+
+	svsp->name = "mt8192-svs";
+	svsp->banks = svs_mt8192_banks;
+	svsp->efuse_parsing = svs_mt8192_efuse_parsing;
+	svsp->set_freqs_pct = svs_set_freqs_pct_v3;
+	svsp->get_vops = svs_get_vops_v3;
+	svsp->regs = svs_regs_v2;
+	svsp->irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+	svsp->bank_num = ARRAY_SIZE(svs_mt8192_banks);
+	svsp->efuse_check = 9;
+
+	svsp->rst = devm_reset_control_get_optional(svsp->dev, "svs_rst");
+	if (IS_ERR(svsp->rst)) {
+		dev_err_probe(svsp->dev, PTR_ERR(svsp->rst),
+			      "cannot get svs reset control\n");
+		return PTR_ERR(svsp->rst);
+	}
+
+	dev = svs_add_device_link(svsp, "lvts");
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->type == SVSB_HIGH)
+			svsb->opp_dev = svs_add_device_link(svsp, "mali");
+		else if (svsb->type == SVSB_LOW)
+			svsb->opp_dev = svs_get_subsys_device(svsp, "mali");
+
+		if (IS_ERR(svsb->opp_dev))
+			return PTR_ERR(svsb->opp_dev);
+	}
+
+	return 0;
+}
+
 static int svs_get_svs_mt8183_platform_data(struct svs_platform *svsp)
 {
 	struct device *dev;
@@ -1925,6 +2387,9 @@ static const struct of_device_id mtk_svs_of_match[] = {
 	{
 		.compatible = "mediatek,mt8183-svs",
 		.data = &svs_get_svs_mt8183_platform_data,
+	}, {
+		.compatible = "mediatek,mt8192-svs",
+		.data = &svs_get_svs_mt8192_platform_data,
 	}, {
 		/* Sentinel */
 	},
-- 
2.18.0

From weiyongjun1 at huawei.com  Fri Apr  9 10:49:00 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Fri, 9 Apr 2021 09:49:00 +0000
Subject: [PATCH -next v2] coresight: core: Make symbol 'csdev_sink' static
Message-ID: <20210409094900.1902783-1-weiyongjun1@huawei.com>

The sparse tool complains as follows:

drivers/hwtracing/coresight/coresight-core.c:26:1: warning:
 symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static?

As csdev_sink is not used outside of coresight-core.c after the
introduction of coresight_[set|get]_percpu_sink() helpers, this
change marks it static.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
v1 -> v2: remove fixes tag and description.
---
 drivers/hwtracing/coresight/coresight-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 3e779e1619ed..6c68d34d956e 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -23,7 +23,7 @@
 #include "coresight-priv.h"
 
 static DEFINE_MUTEX(coresight_mutex);
-DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
+static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
 
 /**
  * struct coresight_node - elements of a path, from source to sink



From weiyongjun1 at huawei.com  Fri Apr  9 10:49:01 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Fri, 9 Apr 2021 09:49:01 +0000
Subject: [PATCH -next v2] coresight: trbe: Fix return value check in
 arm_trbe_register_coresight_cpu()
Message-ID: <20210409094901.1903622-1-weiyongjun1@huawei.com>

In case of error, the function devm_kasprintf() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
v1 -> v2: remove fixes tag.
---
 drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
index 5ce239875c98..176868496879 100644
--- a/drivers/hwtracing/coresight/coresight-trbe.c
+++ b/drivers/hwtracing/coresight/coresight-trbe.c
@@ -871,7 +871,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
 
 	dev = &cpudata->drvdata->pdev->dev;
 	desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu);
-	if (IS_ERR(desc.name))
+	if (!desc.name)
 		goto cpu_clear;
 
 	desc.type = CORESIGHT_DEV_TYPE_SINK;



From yebin10 at huawei.com  Fri Apr  9 10:51:36 2021
From: yebin10 at huawei.com (Ye Bin)
Date: Fri, 9 Apr 2021 17:51:36 +0800
Subject: [PATCH -next] char: xilinx_hwicap: use DEFINE_MUTEX() for mutex lock
Message-ID: <20210409095136.2293754-1-yebin10@huawei.com>

mutex lock can be initialized automatically with DEFINE_MUTEX()
rather than explicitly calling mutex_init().

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ye Bin <yebin10 at huawei.com>
---
 drivers/char/xilinx_hwicap/xilinx_hwicap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
index 067396bedf22..4d586233dfa4 100644
--- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
+++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
@@ -111,7 +111,7 @@
 /* An array, which is set to true when the device is registered. */
 static DEFINE_MUTEX(hwicap_mutex);
 static bool probed_devices[HWICAP_DEVICES];
-static struct mutex icap_sem;
+static DEFINE_MUTEX(icap_sem);
 
 static struct class *icap_class;
 
@@ -857,7 +857,6 @@ static int __init hwicap_module_init(void)
 	int retval;
 
 	icap_class = class_create(THIS_MODULE, "xilinx_config");
-	mutex_init(&icap_sem);
 
 	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
 	retval = register_chrdev_region(devt,



From yebin10 at huawei.com  Fri Apr  9 10:51:52 2021
From: yebin10 at huawei.com (Ye Bin)
Date: Fri, 9 Apr 2021 17:51:52 +0800
Subject: [PATCH -next] soc: fsl: qe: use DEFINE_SPINLOCK() for spinlock
Message-ID: <20210409095152.2294487-1-yebin10@huawei.com>

spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Ye Bin <yebin10 at huawei.com>
---
 drivers/soc/fsl/qe/qe_common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
index 654e9246ce6b..a0cb8e746879 100644
--- a/drivers/soc/fsl/qe/qe_common.c
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -26,7 +26,7 @@
 #include <soc/fsl/qe/qe.h>
 
 static struct gen_pool *muram_pool;
-static spinlock_t cpm_muram_lock;
+static DEFINE_SPINLOCK(cpm_muram_lock);
 static void __iomem *muram_vbase;
 static phys_addr_t muram_pbase;
 
@@ -54,7 +54,6 @@ int cpm_muram_init(void)
 	if (muram_pbase)
 		return 0;
 
-	spin_lock_init(&cpm_muram_lock);
 	np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
 	if (!np) {
 		/* try legacy bindings */



From eric.auger at redhat.com  Fri Apr  9 10:50:44 2021
From: eric.auger at redhat.com (Auger Eric)
Date: Fri, 9 Apr 2021 11:50:44 +0200
Subject: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
In-Reply-To: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <3f17f414-e602-6c63-6d8c-e37237e27ced@redhat.com>

Hi Shameer,

On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> RFC v1 --> v2:
> ?- Added a generic interface for IOMMU drivers to retrieve all the 
> ? ?RMR info associated with a given IOMMU.
> ?- SMMUv3 driver gets the RMR list during probe() and installs
> ?? bypass STEs for all the SIDs in the RMR list. This is to keep
>  ? the ongoing traffic alive(if any) during SMMUv3 reset. This is
>    based on the suggestions received for v1 to take care of the
>    EFI framebuffer use case. Only sanity tested for now.
> ?- During the probe/attach device, SMMUv3 driver reserves any
> ? ?RMR region associated with the device such that there is a unity
> ? ?mapping for them in SMMU.
> ---? ??
> 
> The series adds support to IORT RMR nodes specified in IORT
> Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
> ranges that are used by endpoints and require a unity mapping
> in SMMU.
> 
> We have faced issues with 3408iMR RAID controller cards which
> fail to boot when SMMU is enabled. This is because these controllers
> make use of host memory for various caching related purposes and when
> SMMU is enabled the iMR firmware fails to access these memory regions
> as there is no mapping for them. IORT RMR provides a way for UEFI to
> describe and report these memory regions so that the kernel can make
> a unity mapping for these in SMMU.
> 
> RFC because, Patch #1 is to update the actbl2.h and should be done
> through acpica update. I have send out a pull request[1] for that.

What is the state of this series? I wondered if I should consider using
it for nested SMMU to avoid handling nested binding for MSI, as
suggested by Jean. Are there any blocker?

Thanks

Eric
> 
> Tests:
> 
> With a UEFI, that reports the RMR for the dev,
> ....
> [16F0h 5872   1]                         Type : 06
> [16F1h 5873   2]                       Length : 007C
> [16F3h 5875   1]                     Revision : 00
> [1038h 0056   2]                     Reserved : 00000000
> [1038h 0056   2]                   Identifier : 00000000
> [16F8h 5880   4]                Mapping Count : 00000001
> [16FCh 5884   4]               Mapping Offset : 00000040
> 
> [1700h 5888   4]    Number of RMR Descriptors : 00000002
> [1704h 5892   4]        RMR Descriptor Offset : 00000018
> 
> [1708h 5896   8]          Base Address of RMR : 0000E6400000
> [1710h 5904   8]                Length of RMR : 000000100000
> [1718h 5912   4]                     Reserved : 00000000
> 
> [171Ch 5916   8]          Base Address of RMR : 0000000027B00000
> [1724h 5924   8]                Length of RMR : 0000000000C00000
> [172Ch 5932   4]                     Reserved : 00000000
> 
> [1730h 5936   4]                   Input base : 00000000
> [1734h 5940   4]                     ID Count : 00000001
> [1738h 5944   4]                  Output Base : 00000003
> [173Ch 5948   4]             Output Reference : 00000064
> [1740h 5952   4]        Flags (decoded below) : 00000001
>                                Single Mapping : 1
> ...
> 
> Without the series the RAID controller initialization fails as
> below,
> 
> ...
> [   12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache        : Yes   
> [   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0                                                                         
> [   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state 
> [  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready                                    
> [  106.695186] megaraid_sas 0000:03:00.0: System Register set:                  
> [  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.                                                                   
> [  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407      
> estuary:/$
> 
> With the series, now the kernel has direct mapping for the dev as
> below,
> 
> estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions                      
> 0x0000000008000000 0x00000000080fffff msi                                       
> 0x0000000027b00000 0x00000000286fffff direct                                    
> 0x00000000e6400000 0x00000000e64fffff direct                                    
> estuary:/$
> 
> ....
> [   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0      max_lds: 32                                                                      
> [   12.746628] megaraid_sas 0000:03:00.0: controller type       : iMR(0MB)      
> [   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  : Enabled                                                                               
> [   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes           
> [   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes           
> [   12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs                                                                 
> [   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support     : Yes   
> [   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support    : No    
> [   12.819179] megaraid_sas 0000:03:00.0: NVME page size        : (4096)        
> [   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000                                                    
> [   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done                     
> [   12.873932] megaraid_sas 0000:03:00.0: pci id                : (0x1000)/(0x0017)/(0x19e5)/(0xd213)                                                           
> [   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no            
> [   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no            
> [   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     : enabled       
> 
> RAID controller init is now success and can detect the drives
> attached as well.
> 
> Thanks,
> Shameer
> 
> [0]. https://developer.arm.com/documentation/den0049/latest/
> [1]. https://github.com/acpica/acpica/pull/638
> 
> Shameer Kolothum (8):
>   ACPICA: IORT: Update for revision E
>   ACPI/IORT: Add support for RMR node parsing
>   iommu/dma: Introduce generic helper to retrieve RMR info
>   ACPI/IORT: Add RMR memory regions reservation helper
>   iommu/arm-smmu-v3: Introduce strtab init helper
>   iommu/arm-smmu-v3: Add bypass flag to?arm_smmu_write_strtab_ent()
>   iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
>   iommu/arm-smmu-v3: Reserve any RMR regions associated with a?dev
> 
>  drivers/acpi/arm64/iort.c                   | 182 +++++++++++++++++++-
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |   2 +
>  drivers/iommu/dma-iommu.c                   |  39 +++++
>  include/acpi/actbl2.h                       |  25 ++-
>  include/linux/acpi_iort.h                   |   6 +
>  include/linux/dma-iommu.h                   |   7 +
>  include/linux/iommu.h                       |  16 ++
>  8 files changed, 367 insertions(+), 22 deletions(-)
> 



From andy.shevchenko at gmail.com  Fri Apr  9 10:51:34 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 9 Apr 2021 12:51:34 +0300
Subject: [PATCH v5 2/4] drivers/tty/serial/8250: refactor sirq and lpc
 address setting code
In-Reply-To: <YHAEfn4li6F8L9JC@hatter.bewilderbeest.net>
References: <20210408011637.5361-1-zev@bewilderbeest.net>
 <20210408011637.5361-3-zev@bewilderbeest.net>
 <CAHp75Vd6kk0E-kALEGOhsg=YHKhmKLY6cpCTdviOFenO4p1-2A@mail.gmail.com>
 <YHAEfn4li6F8L9JC@hatter.bewilderbeest.net>
Message-ID: <CAHp75VfpE-AvhzN216KwJvxQ25euGTN_kziJ0hKxYCOXXA2BTw@mail.gmail.com>

On Fri, Apr 9, 2021 at 10:38 AM Zev Weiss <zev at bewilderbeest.net> wrote:
>
> On Fri, Apr 09, 2021 at 02:24:08AM CDT, Andy Shevchenko wrote:
> >On Thursday, April 8, 2021, Zev Weiss <zev at bewilderbeest.net> wrote:
> >
> >> This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
> >> out of the sysfs store functions in preparation for adding DT
> >> properties that will be poking the same registers.  While we're at it,
> >> these functions now provide some basic bounds-checking on their
> >> arguments.
> >>
> >>
> >
> >Please, use prefix ?serial: 8250_aspeed_vuart:? instead of what you have in
> >the subject line. I think I have told this already
> >
> >
>
> Ah, sorry -- I fixed the cover letter after your first comment (which
> had definitely been under-tagged); for the patches themselves I was
> following the example of the last patch in that particular area
> (8d310c9107a2), though I guess that wasn't the right model to follow.
> I'll use the requested format in the future.

Just random amount of most recent patches against 8250 driver:

e47eb5241a8f serial: 8250: Avoid new transfers when shutting down
e49950d3e737 serial: 8250_dma: use linear buffer for transmit
34255381fabd serial: 8250_port: Try to run DMA Rx on timeout condition
7d7dec450a66 8250_tegra: clean up tegra_uart_handle_break
c3ae3dc896fa serial: 8250_pci: Drop bogus __refdata annotation
d96f04d347e4 serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
6e4e636e0e3e serial: 8250-mtk: Fix reference leak in mtk8250_probe
a609c58086e3 tty: serial: 8250: 8250_port: Move prototypes to shared location
6f9918504129 serial: 8250: 8250_omap: Fix unused variable warning
d4548b14dd7e serial: 8250: 8250_omap: Fix possible array out of bounds access
912ab37c7987 serial: 8250_mtk: Fix uart_get_baud_rate warning
439c7183e5b9 serial: 8250: 8250_omap: Disable RX interrupt after DMA enable
32ed248042d1 tty: serial: 8250: serial_cs: Remove unused/unchecked
variable 'err'
85985a3dcd74 serial: 8250_dw: Fix clk-notifier/port suspend deadlock
c8dff3aa8241 serial: 8250: Skip uninitialized TTY port baud rate update
7718453e3696 serial: 8250: Discard RTS/DTS setting from clock update method
409cc4541ade serial: 8250_fsl: Fix TX interrupt handling condition
3c5a87be170a serial: 8250_pci: Add Realtek 816a and 816b
ea4de367e57d tty: serial: 8250_mtk: set regshift for mmio32
57cee0713118 serial: 8250_pci: Remove unused function get_pci_irq()
11361610b005 serial: 8250_fsl: Add ACPI support




-- 
With Best Regards,
Andy Shevchenko


From wangqing at vivo.com  Fri Apr  9 10:55:42 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri,  9 Apr 2021 17:55:42 +0800
Subject: [PATCH] watchdog: mtk: support pre-timeout when the bark irq is
 available
Message-ID: <1617962142-28795-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

By default, the pretimeout notification shall occur one second earlier
than the timeout.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..8b919cc
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
 	int ret;
 
-	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
 	if (ret < 0)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
 	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= WDT_MODE_IRQ_EN;
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+				   unsigned int timeout)
+{
+	wdd->pretimeout = timeout;
+	return mtk_wdt_start(wdd);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +271,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +294,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err,irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +306,21 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark", &mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = 1;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From Claudiu.Beznea at microchip.com  Fri Apr  9 10:59:42 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Fri, 9 Apr 2021 09:59:42 +0000
Subject: [PATCH] pinctrl: at91-pio4: Fix slew rate disablement
In-Reply-To: <20210409082522.625168-1-tudor.ambarus@microchip.com>
References: <20210409082522.625168-1-tudor.ambarus@microchip.com>
Message-ID: <b85dae59-d3fa-33fe-9b38-b441169d0765@microchip.com>

On 09.04.2021 11:25, Tudor Ambarus wrote:
> The slew rate was enabled by default for each configuration of the
> pin. In case the pin had more than one configuration, even if
> we set the slew rate as disabled in the device tree, the next pin
> configuration would set again the slew rate enabled by default,
> overwriting the slew rate disablement.
> Instead of enabling the slew rate by default for each pin configuration,
> enable the slew rate by default just once per pin, regardless of the
> number of configurations. This way the slew rate disablement will also
> work for cases where pins have multiple configurations.
> 
> Fixes: 440b144978ba ("pinctrl: at91-pio4: add support for slew-rate")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>

Reviewed-by: Claudiu Beznea <claudiu.beznea at microchip.com>


> ---
>  drivers/pinctrl/pinctrl-at91-pio4.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
> index a5d328808e4c..4c01d8471ffa 100644
> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> @@ -801,6 +801,10 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
>  
>  	conf = atmel_pin_config_read(pctldev, pin_id);
>  
> +	/* Keep slew rate enabled by default. */
> +	if (atmel_pioctrl->slew_rate_support)
> +		conf |= ATMEL_PIO_SR_MASK;
> +
>  	for (i = 0; i < num_configs; i++) {
>  		unsigned int param = pinconf_to_config_param(configs[i]);
>  		unsigned int arg = pinconf_to_config_argument(configs[i]);
> @@ -808,10 +812,6 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
>  		dev_dbg(pctldev->dev, "%s: pin=%u, config=0x%lx\n",
>  			__func__, pin_id, configs[i]);
>  
> -		/* Keep slew rate enabled by default. */
> -		if (atmel_pioctrl->slew_rate_support)
> -			conf |= ATMEL_PIO_SR_MASK;
> -
>  		switch (param) {
>  		case PIN_CONFIG_BIAS_DISABLE:
>  			conf &= (~ATMEL_PIO_PUEN_MASK);
> 


From shameerali.kolothum.thodi at huawei.com  Fri Apr  9 11:08:10 2021
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Fri, 9 Apr 2021 10:08:10 +0000
Subject: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
In-Reply-To: <3f17f414-e602-6c63-6d8c-e37237e27ced@redhat.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
 <3f17f414-e602-6c63-6d8c-e37237e27ced@redhat.com>
Message-ID: <42d4cf49e52f4844b218763f705add62@huawei.com>

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger at redhat.com]
> Sent: 09 April 2021 10:51
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
> iommu at lists.linux-foundation.org; devel at acpica.org
> Cc: Linuxarm <linuxarm at huawei.com>; steven.price at arm.com; Guohanjun
> (Hanjun Guo) <guohanjun at huawei.com>; Sami.Mujawar at arm.com;
> robin.murphy at arm.com; wanghuiqiang <wanghuiqiang at huawei.com>
> Subject: Re: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
> 
> Hi Shameer,
> 
> On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> > RFC v1 --> v2:
> > ?- Added a generic interface for IOMMU drivers to retrieve all the
> > ? ?RMR info associated with a given IOMMU.
> > ?- SMMUv3 driver gets the RMR list during probe() and installs
> > ?? bypass STEs for all the SIDs in the RMR list. This is to keep
> >  ? the ongoing traffic alive(if any) during SMMUv3 reset. This is
> >    based on the suggestions received for v1 to take care of the
> >    EFI framebuffer use case. Only sanity tested for now.
> > ?- During the probe/attach device, SMMUv3 driver reserves any
> > ? ?RMR region associated with the device such that there is a unity
> > ? ?mapping for them in SMMU.
> > ---
> >
> > The series adds support to IORT RMR nodes specified in IORT
> > Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
> > ranges that are used by endpoints and require a unity mapping
> > in SMMU.
> >
> > We have faced issues with 3408iMR RAID controller cards which
> > fail to boot when SMMU is enabled. This is because these controllers
> > make use of host memory for various caching related purposes and when
> > SMMU is enabled the iMR firmware fails to access these memory regions
> > as there is no mapping for them. IORT RMR provides a way for UEFI to
> > describe and report these memory regions so that the kernel can make
> > a unity mapping for these in SMMU.
> >
> > RFC because, Patch #1 is to update the actbl2.h and should be done
> > through acpica update. I have send out a pull request[1] for that.
> 
> What is the state of this series? I wondered if I should consider using
> it for nested SMMU to avoid handling nested binding for MSI, as
> suggested by Jean. Are there any blocker?

There were few issues with the revision E spec and those are now sorted 
with an updated E.b.

The ACPICA pull request for E.b is now merged[1] and the Linux header
update patch[2] is also out there(I think it is now queued for 5.13).

I will soon respin this series.

Thanks,
Shameer

1. https://github.com/acpica/acpica/pull/682
2. https://lore.kernel.org/linux-acpi/20210406213028.718796-22-erik.kaneda at intel.com/

> 
> Thanks
> 
> Eric
> >
> > Tests:
> >
> > With a UEFI, that reports the RMR for the dev,
> > ....
> > [16F0h 5872   1]                         Type : 06
> > [16F1h 5873   2]                       Length : 007C
> > [16F3h 5875   1]                     Revision : 00
> > [1038h 0056   2]                     Reserved : 00000000
> > [1038h 0056   2]                   Identifier : 00000000
> > [16F8h 5880   4]                Mapping Count : 00000001
> > [16FCh 5884   4]               Mapping Offset : 00000040
> >
> > [1700h 5888   4]    Number of RMR Descriptors : 00000002
> > [1704h 5892   4]        RMR Descriptor Offset : 00000018
> >
> > [1708h 5896   8]          Base Address of RMR : 0000E6400000
> > [1710h 5904   8]                Length of RMR : 000000100000
> > [1718h 5912   4]                     Reserved : 00000000
> >
> > [171Ch 5916   8]          Base Address of RMR : 0000000027B00000
> > [1724h 5924   8]                Length of RMR : 0000000000C00000
> > [172Ch 5932   4]                     Reserved : 00000000
> >
> > [1730h 5936   4]                   Input base : 00000000
> > [1734h 5940   4]                     ID Count : 00000001
> > [1738h 5944   4]                  Output Base : 00000003
> > [173Ch 5948   4]             Output Reference : 00000064
> > [1740h 5952   4]        Flags (decoded below) : 00000001
> >                                Single Mapping : 1
> > ...
> >
> > Without the series the RAID controller initialization fails as
> > below,
> >
> > ...
> > [   12.631117] megaraid_sas 0000:03:00.0: FW supports sync
> cache        : Yes
> > [   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is
> called outbound_intr_mask:0x40000009
> > [   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED
> for SCSI host 0
> > [   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to
> ready state
> > [  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault
> code:0x10000 subcode:0x0 func:megasas_transition_to_ready
> > [  106.695186] megaraid_sas 0000:03:00.0: System Register set:
> > [  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to
> ready for scsi0.
> > [  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw
> 6407
> > estuary:/$
> >
> > With the series, now the kernel has direct mapping for the dev as
> > below,
> >
> > estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions
> > 0x0000000008000000 0x00000000080fffff msi
> > 0x0000000027b00000 0x00000000286fffff direct
> > 0x00000000e6400000 0x00000000e64fffff direct
> > estuary:/$
> >
> > ....
> > [   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is
> called outbound_intr_mask:0x40000009
> > [   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs:
> 0      max_lds: 32
> > [   12.746628] megaraid_sas 0000:03:00.0: controller type       :
> iMR(0MB)
> > [   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  :
> Enabled
> > [   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes
> > [   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes
> > [   12.771931] megaraid_sas 0000:03:00.0: FW provided TM
> TaskAbort/Reset timeou: 6 secs/60 secs
> > [   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map
> support     : Yes
> > [   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining
> support    : No
> > [   12.819179] megaraid_sas 0000:03:00.0: NVME page size        :
> (4096)
> > [   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is
> called outbound_intr_mask:0x40000000
> > [   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done
> > [   12.873932] megaraid_sas 0000:03:00.0: pci id                :
> (0x1000)/(0x0017)/(0x19e5)/(0xd213)
> > [   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no
> > [   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no
> > [   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     :
> enabled
> >
> > RAID controller init is now success and can detect the drives
> > attached as well.
> >
> > Thanks,
> > Shameer
> >
> > [0]. https://developer.arm.com/documentation/den0049/latest/
> > [1]. https://github.com/acpica/acpica/pull/638
> >
> > Shameer Kolothum (8):
> >   ACPICA: IORT: Update for revision E
> >   ACPI/IORT: Add support for RMR node parsing
> >   iommu/dma: Introduce generic helper to retrieve RMR info
> >   ACPI/IORT: Add RMR memory regions reservation helper
> >   iommu/arm-smmu-v3: Introduce strtab init helper
> >   iommu/arm-smmu-v3: Add bypass flag to?arm_smmu_write_strtab_ent()
> >   iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
> >   iommu/arm-smmu-v3: Reserve any RMR regions associated with a?dev
> >
> >  drivers/acpi/arm64/iort.c                   | 182
> +++++++++++++++++++-
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |   2 +
> >  drivers/iommu/dma-iommu.c                   |  39 +++++
> >  include/acpi/actbl2.h                       |  25 ++-
> >  include/linux/acpi_iort.h                   |   6 +
> >  include/linux/dma-iommu.h                   |   7 +
> >  include/linux/iommu.h                       |  16 ++
> >  8 files changed, 367 insertions(+), 22 deletions(-)
> >


From sfr at canb.auug.org.au  Fri Apr  9 11:13:16 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 9 Apr 2021 20:13:16 +1000
Subject: linux-next: build failure after merge of the arm-soc tree
Message-ID: <20210409201316.6c9295a4@canb.auug.org.au>

Hi all,

After merging the arm-soc tree, today's linux-next build (powerpc
allnoconfig) failed like this:

drivers/of/address.c: In function 'of_iomap':
drivers/of/address.c:907:10: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
  907 |   return ioremap_np(res.start, resource_size(&res));
      |          ^~~~~~~~~~
      |          ioremap_wt
drivers/of/address.c:907:10: warning: returning 'int' from a function with return type 'void *' makes pointer from integer without a cast [-Wint-conversion]
  907 |   return ioremap_np(res.start, resource_size(&res));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/of/address.c: In function 'of_io_request_and_map':
drivers/of/address.c:942:7: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  942 |   mem = ioremap_np(res.start, resource_size(&res));
      |       ^
lib/devres.c: In function '__devm_ioremap':
lib/devres.c:47:10: error: implicit declaration of function 'ioremap_np'; did you mean 'ioremap_wt'? [-Werror=implicit-function-declaration]
   47 |   addr = ioremap_np(offset, size);
      |          ^~~~~~~~~~
      |          ioremap_wt
lib/devres.c:47:8: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   47 |   addr = ioremap_np(offset, size);
      |        ^

Caused by commits

  7c566bb5e4d5 ("asm-generic/io.h:  Add a non-posted variant of ioremap()")
  89897f739d7b ("of/address: Add infrastructure to declare MMIO as non-posted")
(and maybe some others)

I have reverted 86332e9e3477..7d2d16ccf15d for today.

-- 
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/20210409/6af4581f/attachment.sig>

From vincenzo.frascino at arm.com  Fri Apr  9 11:19:02 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Fri,  9 Apr 2021 11:19:02 +0100
Subject: [PATCH v2] arm64: mte: Move MTE TCF0 check in entry-common
Message-ID: <20210409101902.2800-1-vincenzo.frascino@arm.com>

The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
race with another CPU doing a set_tsk_thread_flag() and all the other flags
can be lost in the process.

Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
exit_to_user_mode() to address the problem.

Note: Moving the check in entry-common allows to use set_thread_flag()
which is safe.

Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous tag check faults")
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: stable at vger.kernel.org
Reported-by: Will Deacon <will at kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
 arch/arm64/include/asm/mte.h     |  8 ++++++++
 arch/arm64/kernel/entry-common.c |  6 ++++++
 arch/arm64/kernel/entry.S        | 34 --------------------------------
 arch/arm64/kernel/mte.c          | 33 +++++++++++++++++++++++++++++--
 4 files changed, 45 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 9b557a457f24..2ecb2156dac1 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -31,6 +31,8 @@ void mte_invalidate_tags(int type, pgoff_t offset);
 void mte_invalidate_tags_area(int type);
 void *mte_allocate_tag_storage(void);
 void mte_free_tag_storage(char *storage);
+void noinstr check_mte_async_tcf0(void);
+void noinstr clear_mte_async_tcf0(void);
 
 #ifdef CONFIG_ARM64_MTE
 
@@ -83,6 +85,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
 {
 	return -EIO;
 }
+static inline void check_mte_async_tcf0(void)
+{
+}
+static inline void clear_mte_async_tcf0(void)
+{
+}
 
 static inline void mte_assign_mem_tag_range(void *addr, size_t size)
 {
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9d3588450473..837d3624a1d5 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
 	CT_WARN_ON(ct_state() != CONTEXT_USER);
 	user_exit_irqoff();
 	trace_hardirqs_off_finish();
+
+	/* Check for asynchronous tag check faults in user space */
+	check_mte_async_tcf0();
 }
 
 asmlinkage void noinstr exit_to_user_mode(void)
 {
+	/* Ignore asynchronous tag check faults in the uaccess routines */
+	clear_mte_async_tcf0();
+
 	trace_hardirqs_on_prepare();
 	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
 	user_enter_irqoff();
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a31a0a713c85..fb57df0d453f 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -34,15 +34,11 @@
  * user and kernel mode.
  */
 	.macro user_exit_irqoff
-#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
 	bl	enter_from_user_mode
-#endif
 	.endm
 
 	.macro user_enter_irqoff
-#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
 	bl	exit_to_user_mode
-#endif
 	.endm
 
 	.macro	clear_gp_regs
@@ -147,32 +143,6 @@ alternative_cb_end
 .L__asm_ssbd_skip\@:
 	.endm
 
-	/* Check for MTE asynchronous tag check faults */
-	.macro check_mte_async_tcf, flgs, tmp
-#ifdef CONFIG_ARM64_MTE
-alternative_if_not ARM64_MTE
-	b	1f
-alternative_else_nop_endif
-	mrs_s	\tmp, SYS_TFSRE0_EL1
-	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
-	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
-	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
-	str	\flgs, [tsk, #TSK_TI_FLAGS]
-	msr_s	SYS_TFSRE0_EL1, xzr
-1:
-#endif
-	.endm
-
-	/* Clear the MTE asynchronous tag check faults */
-	.macro clear_mte_async_tcf
-#ifdef CONFIG_ARM64_MTE
-alternative_if ARM64_MTE
-	dsb	ish
-	msr_s	SYS_TFSRE0_EL1, xzr
-alternative_else_nop_endif
-#endif
-	.endm
-
 	.macro mte_set_gcr, tmp, tmp2
 #ifdef CONFIG_ARM64_MTE
 	/*
@@ -243,8 +213,6 @@ alternative_else_nop_endif
 	ldr	x19, [tsk, #TSK_TI_FLAGS]
 	disable_step_tsk x19, x20
 
-	/* Check for asynchronous tag check faults in user space */
-	check_mte_async_tcf x19, x22
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
@@ -775,8 +743,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
 	cbnz	x2, work_pending
 finish_ret_to_user:
 	user_enter_irqoff
-	/* Ignore asynchronous tag check faults in the uaccess routines */
-	clear_mte_async_tcf
 	enable_step_tsk x19, x2
 #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
 	bl	stackleak_erase
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index b3c70a612c7a..84a942c25870 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64 excl)
 	 */
 }
 
-void flush_mte_state(void)
+void noinstr check_mte_async_tcf0(void)
+{
+	u64 tcf0;
+
+	if (!system_supports_mte())
+		return;
+
+	/*
+	 * dsb(ish) is not required before the register read
+	 * because the TFSRE0_EL1 is automatically synchronized
+	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
+	 * is set.
+	 */
+	tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
+
+	if (tcf0 & SYS_TFSR_EL1_TF0)
+		set_thread_flag(TIF_MTE_ASYNC_FAULT);
+
+	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
+void noinstr clear_mte_async_tcf0(void)
 {
 	if (!system_supports_mte())
 		return;
 
-	/* clear any pending asynchronous tag fault */
 	dsb(ish);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
+void flush_mte_state(void)
+{
+	if (!system_supports_mte())
+		return;
+
+	/* clear any pending asynchronous tag fault */
+	clear_mte_async_tcf0();
 	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
 	/* disable tag checking */
 	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
-- 
2.30.2



From christophe.leroy at csgroup.eu  Fri Apr  9 11:20:49 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 9 Apr 2021 12:20:49 +0200
Subject: [PATCH v4 18/20] x86: Convert to GENERIC_CMDLINE
In-Reply-To: <20210408194148.GB1724284@robh.at.kernel.org>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <ab0fd4477964cdbf99e3dd2965a455aa3e738e4b.1617375802.git.christophe.leroy@csgroup.eu>
 <20210408194148.GB1724284@robh.at.kernel.org>
Message-ID: <834c4850-5541-b5c2-0b7b-d7d960ab2629@csgroup.eu>



Le 08/04/2021 ? 21:41, Rob Herring a ?crit?:
> On Fri, Apr 02, 2021 at 03:18:20PM +0000, Christophe Leroy wrote:
>> This converts the architecture to GENERIC_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   arch/x86/Kconfig        | 45 ++---------------------------------------
>>   arch/x86/kernel/setup.c | 17 ++--------------
>>   2 files changed, 4 insertions(+), 58 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index a20684d56b4b..66b384228ca3 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -104,6 +104,7 @@ config X86
>>   	select ARCH_USE_QUEUED_SPINLOCKS
>>   	select ARCH_USE_SYM_ANNOTATIONS
>>   	select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
>> +	select ARCH_WANT_CMDLINE_PREPEND_BY_DEFAULT
> 
> Seems to be non-existent kconfig option.

Oops. Added in v5.

>> @@ -883,18 +881,7 @@ void __init setup_arch(char **cmdline_p)
>>   	bss_resource.start = __pa_symbol(__bss_start);
>>   	bss_resource.end = __pa_symbol(__bss_stop)-1;
>>   
>> -#ifdef CONFIG_CMDLINE_BOOL
>> -#ifdef CONFIG_CMDLINE_FORCE
>> -	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> -#else
>> -	if (builtin_cmdline[0]) {
>> -		/* append boot loader cmdline to builtin */
>> -		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
>> -		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
>> -		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> -	}
>> -#endif
>> -#endif
>> +	cmdline_build(boot_command_line, boot_command_line);
>>   
>>   	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
>>   	*cmdline_p = command_line;
> 
> Once this is all done, I wonder if we can get rid of the strlcpy and
> perhaps also cmdline_p.
> 

It seems rather complicated, in init/main.c you have heavy manipulations of command lines which 
seems to be done in setup_command_line() which seems to add stuff in front of command lines, at the 
end we end up with several command lines:

/* Untouched saved command line (eg. for /proc) */
char *saved_command_line;
/* Command line for parameter parsing */
static char *static_command_line;
/* Untouched extra command line */
static char *extra_command_line;

Some of them come from the cmdline_p which others are from boot_command_line.

I think a cleanup on all that stuff would be worth it as a further step.


From john.garry at huawei.com  Fri Apr  9 11:22:36 2021
From: john.garry at huawei.com (John Garry)
Date: Fri, 9 Apr 2021 11:22:36 +0100
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
 <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
Message-ID: <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>

On 09/04/2021 10:05, Qi Liu wrote:
> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> to sample bandwidth, latency, buffer occupation etc.
> 
> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
> registered as a PMU in /sys/bus/event_source/devices, so users can
> select target PMU, and use filter to do further sets.
> 
> Filtering options contains:
> event        - select the event.
> subevent     - select the subevent.
> port         - select target Root Ports. Information of Root Ports
>                 are shown under sysfs.
> bdf          - select requester_id of target EP device.
> trig_len     - set trigger condition for starting event statistics.
> trigger_mode - set trigger mode. 0 means starting to statistic when
>                 bigger than trigger condition, and 1 means smaller.
> thr_len      - set threshold for statistics.
> thr_mode     - set threshold mode. 0 means count when bigger than
>                 threshold, and 1 means smaller.
> 
> Signed-off-by: Qi Liu <liuqi115 at huawei.com>
> ---
>   MAINTAINERS                                |    6 +
>   drivers/perf/Kconfig                       |    2 +
>   drivers/perf/Makefile                      |    1 +
>   drivers/perf/pci/Kconfig                   |   16 +
>   drivers/perf/pci/Makefile                  |    2 +
>   drivers/perf/pci/hisilicon/Makefile        |    5 +
>   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1011 ++++++++++++++++++++++++++++
>   include/linux/cpuhotplug.h                 |    1 +
>   8 files changed, 1044 insertions(+)
>   create mode 100644 drivers/perf/pci/Kconfig
>   create mode 100644 drivers/perf/pci/Makefile
>   create mode 100644 drivers/perf/pci/hisilicon/Makefile
>   create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3353de0..46c7861 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8023,6 +8023,12 @@ W:	http://www.hisilicon.com
>   F:	Documentation/admin-guide/perf/hisi-pmu.rst
>   F:	drivers/perf/hisilicon
>   
> +HISILICON PCIE PMU DRIVER
> +M:	Qi Liu <liuqi115 at huawei.com>
> +S:	Maintained
> +F:	Documentation/admin-guide/perf/hisi-pcie-pmu.rst

nit: this does not exist yet...

> +F:	drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> +
>   HISILICON QM AND ZIP Controller DRIVER
>   M:	Zhou Wang <wangzhou1 at hisilicon.com>
>   L:	linux-crypto at vger.kernel.org
> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> index 3075cf1..99d4760 100644
> --- a/drivers/perf/Kconfig
> +++ b/drivers/perf/Kconfig
> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>   
>   source "drivers/perf/hisilicon/Kconfig"
>   
> +source "drivers/perf/pci/Kconfig"
> +
>   endmenu
> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> index 5260b11..1208c08 100644
> --- a/drivers/perf/Makefile
> +++ b/drivers/perf/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>   obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>   obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>   obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
> +obj-y += pci/
> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
> new file mode 100644
> index 0000000..a119486
> --- /dev/null
> +++ b/drivers/perf/pci/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# PCIe Performance Monitor Drivers
> +#
> +menu "PCIe Performance Monitor"
> +
> +config HISI_PCIE_PMU
> +	tristate "HiSilicon PCIE PERF PMU"
> +	depends on ARM64 && PCI && HISI_PMU

What from HISI_PMU is needed? I couldn't find anything here

> +	help
> +	  Provide support for HiSilicon PCIe performance monitoring unit (PMU)
> +	  RCiEP devices.
> +	  Adds the PCIe PMU into perf events system for monitoring latency,
> +	  bandwidth etc.
> +
> +endmenu
> diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
> new file mode 100644
> index 0000000..a56b1a9
> --- /dev/null
> +++ b/drivers/perf/pci/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y += hisilicon/
> diff --git a/drivers/perf/pci/hisilicon/Makefile b/drivers/perf/pci/hisilicon/Makefile
> new file mode 100644
> index 0000000..6f99f52
> --- /dev/null
> +++ b/drivers/perf/pci/hisilicon/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +ccflags-y :=  -I $(srctree)/drivers/perf/hisilicon
> +
> +obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
> diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> new file mode 100644
> index 0000000..ac0e444
> --- /dev/null
> +++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> @@ -0,0 +1,1011 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * This driver adds support for PCIe PMU RCiEP device. Related
> + * perf events are bandwidth, bandwidth utilization, latency
> + * etc.
> + *
> + * Copyright (C) 2021 HiSilicon Limited
> + * Author: Qi Liu<liuqi115 at huawei.com>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/bitmap.h>
> +#include <linux/bug.h>
> +#include <linux/cpuhotplug.h>
> +#include <linux/cpumask.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/perf_event.h>
> +
> +#include "hisi_uncore_pmu.h"
> +
> +/* Define registers */
> +#define HISI_PCIE_GLOBAL_CTRL		0x00
> +#define HISI_PCIE_EVENT_CTRL		0x010
> +#define HISI_PCIE_CNT			0x090
> +#define HISI_PCIE_EXT_CNT		0x110
> +#define HISI_PCIE_INT_STAT		0x150
> +#define HISI_PCIE_INT_MASK		0x154
> +#define HISI_PCIE_REG_BDF		0xfe0
> +#define HISI_PCIE_REG_VERSION		0xfe4
> +#define HISI_PCIE_REG_INFO		0xfe8
> +#define HISI_PCIE_REG_FREQ		0xfec
> +
> +/* Define PCIE CTRL CMD */
> +#define HISI_PCIE_GLOBAL_EN		0x01
> +#define HISI_PCIE_GLOBAL_NONE		0
> +#define HISI_PCIE_EVENT_EN		BIT(20)
> +#define HISI_PCIE_RESET_CNT		BIT(22)
> +#define HISI_PCIE_DEFAULT_SET		BIT(34)
> +#define HISI_PCIE_THR_EN		BIT(26)
> +#define HISI_PCIE_TARGET_EN		BIT(32)
> +#define HISI_PCIE_TRIG_EN		BIT(52)
> +
> +/* Define offsets in event ctrl regesiter */
> +#define HISI_PCIE_EVENT_M		GENMASK_ULL(7, 0)
> +#define HISI_PCIE_SUBEVENT_M		GENMASK_ULL(15, 8)
> +#define HISI_PCIE_THR_MODE_M		GENMASK_ULL(27, 27)
> +#define HISI_PCIE_THR_M			GENMASK_ULL(31, 28)
> +#define HISI_PCIE_TARGET_M		GENMASK_ULL(52, 36)
> +#define HISI_PCIE_TRIG_MODE_M		GENMASK_ULL(53, 53)
> +#define HISI_PCIE_TRIG_M		GENMASK_ULL(59, 56)
> +
> +#define HISI_PCIE_MAX_COUNTERS		8
> +#define HISI_PCIE_REG_STEP		8
> +#define HISI_PCIE_EVENT_MAX		0xa2
> +#define HISI_PCIE_SUBEVENT_MAX		0x20
> +#define HISI_PCIE_THR_MAX_VAL		10
> +#define HISI_PCIE_TRIG_MAX_VAL		10
> +#define HISI_PCIE_COUNTER_BITS		64
> +#define HISI_PCIE_MAX_PERIOD		BIT_ULL(63)
> +
> +struct hisi_pcie_pmu {
> +	struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
> +	struct hlist_node node;
> +	struct pci_dev *pdev;
> +	struct pmu pmu;
> +	void __iomem *base;
> +	cpumask_t cpumask;
> +	int irq;
> +	u32 identifier;
> +	/* Minimum and maximum bdf of root ports monitored by PMU */
> +	u16 bdf_min;
> +	u16 bdf_max;
> +};
> +
> +#define to_pcie_pmu(p)  (container_of((p), struct hisi_pcie_pmu, pmu))
> +#define GET_PCI_DEVFN(bdf)  ((bdf) & 0xff)
> +
> +#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)       \
> +	static inline u64 hisi_pcie_get_##_name(struct perf_event *event)  \
> +	{                                                             \
> +		return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
> +	}							\
> +
> +HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
> +HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
> +HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
> +HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
> +HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
> +
> +#define HISI_PCIE_CHECK_EVENTS(name, list)             \

"check" in a function name is too vague, as it does not imply any 
side-effect from calling this function.

And I think "build" or similar would be good to be included in the macro 
name.

> +	static inline bool is_##name##_event(u32 idx)                  \

why inline?

> +	{                                                                   \
> +		if ((idx >= list[0] && idx <= list[1]) || idx == list[2])  \
> +			return true;                                        \
> +		return false;                                               \

isn't this just:
{
	return (idx >= list[0] && idx <= list[1]) || idx == list[2])
}

> +	}
> +
> +/*
> + * The first element of event list is minimum index of TL-layer events
> + * and the second element is maximum index. The third element is index
> + * of a DL-layer event.
> + */
> +static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
> +static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
> +static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
> +static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
> +
> +HISI_PCIE_CHECK_EVENTS(bw, bw_events_list);
> +HISI_PCIE_CHECK_EVENTS(latency, latency_events_list);
> +HISI_PCIE_CHECK_EVENTS(bus_util, bus_util_events_list);
> +HISI_PCIE_CHECK_EVENTS(buf_util, buf_util_events_list);

Surely the macro can be fixed such that you need to have:
HISI_PCIE_CHECK_EVENTS(buf_util);


> +
> +static ssize_t hisi_pcie_cpumask_show(struct device *dev,
> +				      struct device_attribute *attr, char *buf)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
> +
> +	return cpumap_print_to_pagebuf(true, buf, &pcie_pmu->cpumask);
> +}
> +
> +static ssize_t hisi_pcie_identifier_show(struct device *dev,
> +					 struct device_attribute *attr,
> +					 char *buf)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
> +
> +	return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
> +}
> +
> +static ssize_t hisi_pcie_bus_show(struct device *dev,
> +				  struct device_attribute *attr, char *buf)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
> +
> +	return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
> +}
> +
> +static void hisi_pcie_parse_data(struct hisi_pcie_pmu *pcie_pmu, u32 reg_off,

hisi_pcie_parse_data() name is way too vague. I mean, parse what data?

is there is some standard format register we use for various data types, 
then make that clear please

> +			       u16 *arg0, u16 *arg1)
> +{
> +	u32 val = readl(pcie_pmu->base + reg_off);
> +
> +	*arg0 = val & 0xffff;
> +	*arg1 = (val & 0xffff0000) >> 16;
> +}
> +
> +static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
> +{
> +	return offset + HISI_PCIE_REG_STEP * idx;
> +}
> +
> +static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
> +			       u32 idx)
> +{
> +	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
> +
> +	return readl(pcie_pmu->base + offset);
> +}
> +
> +static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
> +				 u32 idx, u32 val)
> +{
> +	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
> +
> +	writel(val, pcie_pmu->base + offset);
> +}
> +
> +static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
> +			       u32 idx)
> +{
> +	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
> +
> +	return readq(pcie_pmu->base + offset);
> +}
> +
> +static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
> +				 u32 idx, u64 val)
> +{
> +	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
> +
> +	writeq(val, pcie_pmu->base + offset);
> +}
> +
> +static u64 hisi_pcie_pmu_get_event(struct perf_event *event)

that function name is too vague

> +{
> +	return FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
> +	       FIELD_PREP(HISI_PCIE_SUBEVENT_M, hisi_pcie_get_subevent(event));
> +}
> +
> +static u64 hisi_pcie_pmu_get_target(struct perf_event *event)

same here

> +{
> +	u64 port, val;
> +
> +	port = hisi_pcie_get_port(event);
> +	if (port) {
> +		val = FIELD_PREP(HISI_PCIE_TARGET_M, port);
> +	} else {
> +		val = FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
> +		val |= HISI_PCIE_TARGET_EN;
> +	}
> +
> +	return val;
> +}
> +
> +static u64 hisi_pcie_pmu_get_trigger(struct perf_event *event)

and here

what you really seem to be doing is getting the formatted fields for the 
register


Having all these call-once functions seem to make life a bit more 
difficult...

> +{
> +	u64 trig_len, val;
> +
> +	trig_len = hisi_pcie_get_trig_len(event);
> +	if (!trig_len)
> +		return 0;
> +
> +	val = FIELD_PREP(HISI_PCIE_TRIG_M, trig_len);
> +	val |= FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
> +			  hisi_pcie_get_trig_mode(event));
> +	val |= HISI_PCIE_TRIG_EN;
> +
> +	return val;
> +}
> +
> +static u64 hisi_pcie_pmu_get_thr(struct perf_event *event)
> +{
> +	u64 thr_len, val;
> +
> +	thr_len = hisi_pcie_get_thr_len(event);
> +	if (!thr_len)
> +		return 0;
> +
> +	val = FIELD_PREP(HISI_PCIE_THR_M, thr_len);
> +	val |= FIELD_PREP(HISI_PCIE_THR_MODE_M, hisi_pcie_get_thr_mode(event));
> +	val |= HISI_PCIE_THR_EN;
> +
> +	return val;
> +}
> +
> +static void hisi_pcie_pmu_config_filter(struct perf_event *event)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +	u32 idx = hwc->idx;
> +	u64 val;
> +
> +	val = HISI_PCIE_DEFAULT_SET;
> +	val |= hisi_pcie_pmu_get_event(event);
> +	val |= hisi_pcie_pmu_get_target(event);
> +	val |= hisi_pcie_pmu_get_trigger(event);
> +	val |= hisi_pcie_pmu_get_thr(event);
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
> +}
> +
> +static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
> +			     HISI_PCIE_DEFAULT_SET);
> +}
> +
> +static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu, u16 bdf)
> +{
> +	return bdf <= pcie_pmu->bdf_max && bdf >= pcie_pmu->bdf_min;

nit: it is standard to have:

	if (x >= min && x <= max)

i.e. have min on the left

2nd nit: it is passed bdf, yet "port" is in the name


> +}
> +
> +static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu *pcie_pmu,
> +					    u32 bdf)
> +{
> +	struct pci_dev *root_port, *pdev;
> +
> +	pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
> +					   PCI_BUS_NUM(bdf),
> +					   GET_PCI_DEVFN(bdf));
> +	if (!pdev)
> +		return false;
> +
> +	root_port = pcie_find_root_port(pdev);
> +	if (!root_port)
> +		return false;
> +
> +	pci_dev_put(pdev);
> +	return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
> +}
> +
> +static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
> +				       struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	u32 subev_idx = hisi_pcie_get_subevent(event);
> +	u32 event_idx = hisi_pcie_get_event(event);
> +	u32 requester_id = hisi_pcie_get_bdf(event);
> +
> +	if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
> +	    event_idx > HISI_PCIE_EVENT_MAX) {
> +		pci_err(pcie_pmu->pdev,
> +			"Max event index and max subevent index is: %d, %d.\n",
> +			HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);

if this is just going to be fed back to userspace, I don't see why we 
need a kernel log

and the only caller also triggers an error message, which I doubt is needed

> +		return false;
> +	}
> +
> +	if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
> +		return false;
> +
> +	if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
> +		return false;
> +
> +	if (requester_id) {
> +		if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id)) {
> +			pci_err(pcie_pmu->pdev, "Invalid requester id.\n");

see previous comments

> +			return false;
> +		}
> +	}
> +
> +	return true;
> +}
> +
> +static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
> +{
> +	struct perf_event *sibling, *leader = event->group_leader;
> +	int counters = 1;
> +
> +	if (!is_software_event(leader)) {
> +		if (leader->pmu != event->pmu)
> +			return false;
> +
> +		if (leader != event)
> +			counters++;
> +	}
> +
> +	for_each_sibling_event(sibling, event->group_leader) {
> +		if (is_software_event(sibling))
> +			continue;
> +
> +		if (sibling->pmu != event->pmu)
> +			return false;
> +
> +		counters++;
> +	}
> +
> +	return counters <= HISI_PCIE_MAX_COUNTERS;
> +}
> +
> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +
> +	event->cpu = cpumask_first(&pcie_pmu->cpumask);
> +
> +	if (event->attr.type != event->pmu->type)
> +		return -ENOENT;
> +
> +	/* Sampling is not supported. */
> +	if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> +		return -EOPNOTSUPP;
> +
> +	/* Per-task mode is not supported. */
> +	if (event->cpu < 0)

cpumask_first() gives an unsigned int - this can never happen

> +		return -EINVAL;
> +
> +	if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
> +		pci_err(pcie_pmu->pdev, "Invalid filter!\n");
> +		return -EINVAL;
> +	}
> +
> +	if (!hisi_pcie_pmu_validate_event_group(event))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 val,

function name too vague, as are the argument names

> +				      u64 val_ext)
> +{
> +#define CONVERT_DW_TO_BYTE(x)	(sizeof(u32) * (x))
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
> +	u32 idx = hisi_pcie_get_event(event);
> +
> +	if (!val_ext)
> +		return 0;
> +
> +	/*
> +	 * The bandwidth, latency, bus utilization and buffer occupancy
> +	 * are obtained by the (COMMON_COUNTER and EXT_COUNTER). And other
> +	 * features are obtained by COMMON_COUNTER.
> +	 */
> +	if (is_bw_event(idx)) {
> +		if (!val_ext / 1000)
> +			return 0;
> +
> +		/* Process data to set unit of bandwidth as "Byte/ms". */
> +		return (CONVERT_DW_TO_BYTE(val)) / (val_ext / 1000);
> +	}
> +
> +	if (is_latency_event(idx))
> +		/* Process data to set unit of latency as "us". */

it's not a good programming practice to put comments after an if 
statement like this

> +		return (val * us_per_cycle) / val_ext;
> +
> +	if (is_bus_util_event(idx))
> +		return (val * us_per_cycle) / val_ext;
> +
> +	if (is_buf_util_event(idx))
> +		return val / (val_ext * us_per_cycle);
> +
> +	return val;
> +}
> +
> +static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 *cnt,
> +				       u64 *cnt_ext)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u32 idx = event->hw.idx;
> +
> +	*cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
> +	*cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
> +}
> +
> +static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 val,
> +					u64 val_ext)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u32 idx = event->hw.idx;
> +
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
> +}
> +
> +static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	int idx;
> +
> +	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
> +		if (!pcie_pmu->hw_events[idx])
> +			return idx;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static void hisi_pcie_pmu_read(struct perf_event *event)
> +{
> +	struct hw_perf_event *hwc = &event->hw;
> +	struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
> +	u64 new_cnt_ext, prev_cnt_ext;
> +	u64 new_cnt, prev_cnt, delta;
> +
> +	hwc_ext = &hwc->extra_reg;
> +	do {
> +		prev_cnt = local64_read(&hwc->prev_count);
> +		prev_cnt_ext = hwc_ext->config;
> +		hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
> +	} while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
> +				 new_cnt) != prev_cnt);
> +
> +	hwc_ext->config = new_cnt_ext;
> +
> +	delta = hisi_pcie_pmu_process_data(event, new_cnt - prev_cnt,
> +					   new_cnt_ext - prev_cnt_ext);
> +	local64_add(delta, &event->count);
> +}
> +
> +static void hisi_pcie_pmu_set_period(struct perf_event *event)
> +{
> +	struct hw_perf_event *hwc = &event->hw;
> +	struct hw_perf_event_extra *hwc_ext;
> +	u64 val = BIT_ULL(HISI_PCIE_COUNTER_BITS - 1);
> +
> +	hwc_ext = &hwc->extra_reg;
> +	local64_set(&hwc->prev_count, val);
> +	hwc_ext->config = 0;
> +	hisi_pcie_pmu_write_counter(event, val, 0);
> +}
> +
> +static void hisi_pcie_pmu_enable_counter(struct hisi_pcie_pmu *pcie_pmu,
> +					 struct hw_perf_event *hwc)
> +{
> +	u32 idx = hwc->idx;
> +	u64 val;
> +
> +	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
> +	val |= HISI_PCIE_EVENT_EN;
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
> +}
> +
> +static void hisi_pcie_pmu_disable_counter(struct hisi_pcie_pmu *pcie_pmu,
> +					  struct hw_perf_event *hwc)
> +{
> +	u32 idx = hwc->idx;
> +	u64 val;
> +
> +	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
> +	val &= ~HISI_PCIE_EVENT_EN;
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
> +}
> +
> +static void hisi_pcie_pmu_enable_int(struct hisi_pcie_pmu *pcie_pmu,
> +				     struct hw_perf_event *hwc)
> +{
> +	u32 idx = hwc->idx;
> +
> +	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 0);
> +}
> +
> +static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
> +				      struct hw_perf_event *hwc)
> +{
> +	u32 idx = hwc->idx;
> +
> +	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
> +}
> +
> +static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
> +					struct hw_perf_event *hwc)
> +{
> +	u32 idx = hwc->idx;
> +
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
> +			     HISI_PCIE_RESET_CNT);
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
> +			     HISI_PCIE_DEFAULT_SET);
> +}
> +
> +static void hisi_pcie_pmu_start(struct perf_event *event, int flags)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +	struct hw_perf_event_extra *hwc_ext;
> +	u64 prev_cnt, prev_cnt_ext;
> +
> +	hwc_ext = &hwc->extra_reg;
> +	if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
> +		return;
> +
> +	WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
> +	hwc->state = 0;
> +
> +	hisi_pcie_pmu_config_filter(event);
> +	hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
> +	hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
> +	hisi_pcie_pmu_set_period(event);
> +
> +	if (flags & PERF_EF_RELOAD) {
> +		prev_cnt = local64_read(&hwc->prev_count);
> +		prev_cnt_ext = hwc_ext->config;
> +		hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
> +	}
> +
> +	perf_event_update_userpage(event);
> +}
> +
> +static void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +
> +	hisi_pcie_pmu_read(event);

why do this - it just reads a register? and so why not check the return 
value?

> +	hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
> +	hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
> +	hisi_pcie_pmu_clear_filter(event);
> +	WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
> +	hwc->state |= PERF_HES_STOPPED;
> +
> +	if (hwc->state & PERF_HES_UPTODATE)
> +		return;
> +
> +	hwc->state |= PERF_HES_UPTODATE;
> +}
> +
> +static int hisi_pcie_pmu_add(struct perf_event *event, int flags)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +	int idx;
> +
> +	hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
> +	idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
> +	if (idx < 0)
> +		return idx;
> +
> +	hwc->idx = idx;
> +	pcie_pmu->hw_events[idx] = event;
> +
> +	/* Reset PMC to avoid interference caused by previous statistic. */

what is PMC?

> +	hisi_pcie_pmu_reset_counter(pcie_pmu, hwc);
> +
> +	if (flags & PERF_EF_START)
> +		hisi_pcie_pmu_start(event, PERF_EF_RELOAD);
> +
> +	return 0;
> +}
> +
> +static void hisi_pcie_pmu_del(struct perf_event *event, int flags)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	struct hw_perf_event *hwc = &event->hw;
> +
> +	hisi_pcie_pmu_stop(event, PERF_EF_UPDATE);
> +	pcie_pmu->hw_events[hwc->idx] = NULL;
> +	perf_event_update_userpage(event);
> +}
> +
> +static void hisi_pcie_pmu_enable(struct pmu *pmu)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
> +	int num;
> +
> +	for (num = 0; num < HISI_PCIE_MAX_COUNTERS; num++) {
> +		if (pcie_pmu->hw_events[num])
> +			break;
> +	}
> +
> +	if (num == HISI_PCIE_MAX_COUNTERS)
> +		return;
> +
> +	writel(HISI_PCIE_GLOBAL_EN, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
> +}
> +
> +static void hisi_pcie_pmu_disable(struct pmu *pmu)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
> +
> +	writel(HISI_PCIE_GLOBAL_NONE, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
> +}
> +
> +static irqreturn_t hisi_pcie_pmu_irq(int irq, void *data)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = data;
> +	irqreturn_t ret = IRQ_NONE;
> +	struct perf_event *event;
> +	u32 overflown;
> +	int idx;
> +
> +	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
> +		overflown = hisi_pcie_pmu_readl(pcie_pmu, HISI_PCIE_INT_STAT,
> +						idx);
> +		if (!overflown)
> +			continue;
> +
> +		/* Clear status of interrupt. */
> +		hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_STAT, idx, 1);
> +		event = pcie_pmu->hw_events[idx];
> +		if (!event)
> +			continue;
> +
> +		hisi_pcie_pmu_read(event);
> +		hisi_pcie_pmu_set_period(event);
> +		ret = IRQ_HANDLED;
> +	}
> +
> +	return ret;
> +}
> +
> +static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
> +				      struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	int irq, ret;
> +
> +	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
> +	if (ret < 0) {
> +		pci_err(pdev, "Failed to enable MSI vectors, ret = %d!\n", ret);
> +		return ret;
> +	}
> +
> +	irq = pci_irq_vector(pdev, 0);
> +	ret = request_irq(irq, hisi_pcie_pmu_irq, IRQF_SHARED, "hisi_pcie_pmu",


is this interrupt line really shared?

> +			  pcie_pmu);
> +	if (ret) {
> +		pci_err(pdev, "Failed to register irq, ret = %d!\n", ret);
> +		pci_free_irq_vectors(pdev);
> +		return ret;
> +	}
> +
> +	pcie_pmu->irq = irq;
> +
> +	return 0;
> +}
> +
> +static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
> +					 struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	free_irq(pcie_pmu->irq, pcie_pmu);
> +	pci_free_irq_vectors(pdev);
> +}
> +
> +static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
> +					 struct hisi_pcie_pmu, node);
> +
> +	if (cpumask_empty(&pcie_pmu->cpumask)) {
> +		cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
> +		WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
> +	}
> +
> +	return 0;
> +}
> +
> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
> +					 struct hisi_pcie_pmu, node);
> +	unsigned int target;
> +
> +	if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))

I do wonder why we even need maintain pcie_pmu->cpumask

Can't we just use cpu_online_mask as appropiate instead?

> +		return 0;
> +
> +	/* Choose a new CPU from all online cpus. */
> +	target = cpumask_any_but(cpu_online_mask, cpu);
> +	if (target >= nr_cpu_ids)
> +		return 0;
> +
> +	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
> +	WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
> +
> +	return 0;
> +}
> +
> +/*
> + * Events with the "dl" suffix in their names count performance in DL layer,
> + * otherswise, events count performance in TL layer.
> + */
> +static struct attribute *hisi_pcie_pmu_events_attr[] = {
> +	HISI_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
> +	HISI_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
> +	HISI_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
> +	HISI_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
> +	HISI_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
> +	HISI_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
> +	HISI_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
> +	HISI_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
> +	HISI_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
> +	HISI_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),

it would be nice to see JSONs for these as well with full event descriptions

> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_events_group = {
> +	.name = "events",
> +	.attrs = hisi_pcie_pmu_events_attr,
> +};
> +
> +static struct attribute *hisi_pcie_pmu_format_attr[] = {
> +	HISI_PMU_FORMAT_ATTR(event, "config:0-7"),
> +	HISI_PMU_FORMAT_ATTR(subevent, "config:8-15"),
> +	HISI_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
> +	HISI_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
> +	HISI_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
> +	HISI_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
> +	HISI_PMU_FORMAT_ATTR(port, "config2:0-15"),
> +	HISI_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_format_group = {
> +	.name = "format",
> +	.attrs = hisi_pcie_pmu_format_attr,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_bus_attr =
> +	__ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
> +	&hisi_pcie_pmu_bus_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
> +	.attrs = hisi_pcie_pmu_bus_attrs,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_cpumask_attr =
> +	__ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
> +	&hisi_pcie_pmu_cpumask_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
> +	.attrs = hisi_pcie_pmu_cpumask_attrs,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_identifier_attr =
> +	__ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
> +	&hisi_pcie_pmu_identifier_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
> +	.attrs = hisi_pcie_pmu_identifier_attrs,
> +};
> +
> +static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
> +	&hisi_pcie_pmu_events_group,
> +	&hisi_pcie_pmu_format_group,
> +	&hisi_pcie_pmu_bus_attr_group,
> +	&hisi_pcie_pmu_cpumask_attr_group,
> +	&hisi_pcie_pmu_identifier_attr_group,
> +	NULL
> +};
> +
> +static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
> +			     struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	u16 sicl_id, device_id;
> +	char *name;
> +
> +	pcie_pmu->base = pci_ioremap_bar(pdev, 2);
> +	if (!pcie_pmu->base) {
> +		pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
> +		return -ENOMEM;
> +	}
> +
> +	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_BDF, &pcie_pmu->bdf_min,
> +			   &pcie_pmu->bdf_max);
> +	hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
> +			     &sicl_id);
> +	name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
> +			      "hisi_pcie%u_%u", sicl_id, device_id);
> +	if (!name) {
> +		pci_err(pdev, "Failed to allocate name for PMU.\n");

no need for that log

> +		return -ENOMEM;
> +	}
> +
> +	pcie_pmu->pdev = pdev;
> +	pcie_pmu->identifier = readl(pcie_pmu->base + HISI_PCIE_REG_VERSION);
> +	pcie_pmu->pmu = (struct pmu) {
> +		.name		= name,
> +		.module		= THIS_MODULE,
> +		.event_init	= hisi_pcie_pmu_event_init,
> +		.pmu_enable	= hisi_pcie_pmu_enable,
> +		.pmu_disable	= hisi_pcie_pmu_disable,
> +		.add		= hisi_pcie_pmu_add,
> +		.del		= hisi_pcie_pmu_del,
> +		.start		= hisi_pcie_pmu_start,
> +		.stop		= hisi_pcie_pmu_stop,
> +		.read		= hisi_pcie_pmu_read,
> +		.task_ctx_nr	= perf_invalid_context,
> +		.attr_groups	= hisi_pcie_pmu_attr_groups,
> +		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
> +	};
> +
> +	return 0;
> +}
> +
> +static int hisi_pcie_init_pmu(struct pci_dev *pdev,
> +			      struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	int ret;
> +
> +	ret = hisi_pcie_alloc_pmu(pdev, pcie_pmu);
> +	if (ret)
> +		return ret;
> +
> +	ret = hisi_pcie_pmu_irq_register(pdev, pcie_pmu);
> +	if (ret)
> +		goto err_set_pmu_fail;
> +
> +	ret = cpuhp_state_add_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
> +				       &pcie_pmu->node);
> +	if (ret) {
> +		pci_err(pdev, "Failed to register hotplug, ret = %d.\n", ret);
> +		goto err_irq_unregister;
> +	}
> +
> +	ret = perf_pmu_register(&pcie_pmu->pmu, pcie_pmu->pmu.name, -1);
> +	if (ret) {
> +		pci_err(pdev, "Failed to register PCIe PMU, ret = %d.\n", ret);
> +		goto err_hotplug_unregister;
> +	}
> +
> +	return ret;
> +
> +err_hotplug_unregister:
> +	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
> +				    &pcie_pmu->node);
> +	irq_set_affinity_hint(pcie_pmu->irq, NULL);
> +
> +err_irq_unregister:
> +	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
> +
> +err_set_pmu_fail:
> +	iounmap(pcie_pmu->base);
> +
> +	return ret;
> +}
> +
> +static void hisi_pcie_uninit_pmu(struct pci_dev *pdev,
> +				 struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	perf_pmu_unregister(&pcie_pmu->pmu);
> +	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
> +				    &pcie_pmu->node);
> +	irq_set_affinity_hint(pcie_pmu->irq, NULL);
> +	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
> +	iounmap(pcie_pmu->base);
> +}
> +
> +static int hisi_pcie_init_dev(struct pci_dev *pdev)
> +{
> +	int ret;
> +
> +	ret = pci_enable_device(pdev);
> +	if (ret) {
> +		pci_err(pdev, "Failed to enable pci device, ret = %d.\n", ret);
> +		return ret;
> +	}
> +
> +	ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
> +	if (ret < 0) {
> +		pci_err(pdev, "Failed to request pci mem regions, ret = %d.\n",
> +			ret);
> +		pci_disable_device(pdev);
> +		return ret;
> +	}
> +
> +	pci_set_master(pdev);
> +
> +	return 0;
> +}
> +
> +static void hisi_pcie_uninit_dev(struct pci_dev *pdev)
> +{
> +	pci_clear_master(pdev);
> +	pci_release_mem_regions(pdev);
> +	pci_disable_device(pdev);
> +}
> +
> +static int hisi_pcie_pmu_probe(struct pci_dev *pdev,
> +			       const struct pci_device_id *id)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu;
> +	int ret;
> +
> +	pcie_pmu = devm_kzalloc(&pdev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
> +	if (!pcie_pmu)
> +		return -ENOMEM;
> +
> +	ret = hisi_pcie_init_dev(pdev);
> +	if (ret)
> +		return ret;
> +
> +	ret = hisi_pcie_init_pmu(pdev, pcie_pmu);
> +	if (ret)
> +		hisi_pcie_uninit_dev(pdev);
> +
> +	pci_set_drvdata(pdev, pcie_pmu);
> +
> +	return ret;
> +}
> +
> +static void hisi_pcie_pmu_remove(struct pci_dev *pdev)
> +{
> +	hisi_pcie_uninit_pmu(pdev, pci_get_drvdata(pdev));

passing both pdev and pci_get_drvdata(pdev) should not be needed

> +	hisi_pcie_uninit_dev(pdev);
> +	pci_set_drvdata(pdev, NULL); > +}
> +
> +static const struct pci_device_id hisi_pcie_pmu_ids[] = {
> +	{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12d) },
> +	{ 0, }
> +};
> +MODULE_DEVICE_TABLE(pci, hisi_pcie_pmu_ids);
> +
> +static struct pci_driver hisi_pcie_pmu_driver = {
> +	.name = "hisi_pcie_pmu",
> +	.id_table = hisi_pcie_pmu_ids,
> +	.probe = hisi_pcie_pmu_probe,
> +	.remove = hisi_pcie_pmu_remove,
> +};
> +
> +static int __init hisi_pcie_module_init(void)
> +{
> +	int ret;
> +
> +	ret = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
> +				      "AP_PERF_ARM_HISI_PCIE_PMU_ONLINE",
> +				      hisi_pcie_pmu_online_cpu,
> +				      hisi_pcie_pmu_offline_cpu);
> +	if (ret) {
> +		pr_err("Failed to setup PCIE PMU hotplug, ret = %d.\n", ret);
> +		return ret;
> +	}
> +
> +	ret = pci_register_driver(&hisi_pcie_pmu_driver);
> +	if (ret)
> +		cpuhp_remove_multi_state(
> +				CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
> +
> +	return ret;
> +}
> +module_init(hisi_pcie_module_init);
> +
> +static void __exit hisi_pcie_module_exit(void)
> +{
> +	pci_unregister_driver(&hisi_pcie_pmu_driver);
> +	cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
> +}
> +module_exit(hisi_pcie_module_exit);
> +
> +MODULE_DESCRIPTION("HiSilicon PCIe PMU driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Qi Liu <liuqi115 at huawei.com>");
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 113f51f..c17861a 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -174,6 +174,7 @@ enum cpuhp_state {
>   	CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
>   	CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
>   	CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
> +	CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>   	CPUHP_AP_PERF_ARM_L2X0_ONLINE,
>   	CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
>   	CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
> 



From valentin.schneider at arm.com  Fri Apr  9 11:34:07 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Fri, 09 Apr 2021 11:34:07 +0100
Subject: [RFC PATCH 01/10] genirq: Add chip flag to denote automatic IRQ
 (un)masking
In-Reply-To: <20210409101725.00007271@Huawei.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
 <20210408154326.3988781-2-valentin.schneider@arm.com>
 <20210409101725.00007271@Huawei.com>
Message-ID: <875z0voig0.mognet@arm.com>

Hi Jonathan,

Thanks for taking a peek :)

On 09/04/21 10:17, Jonathan Cameron wrote:
> On Thu, 8 Apr 2021 16:43:17 +0100
> Valentin Schneider <valentin.schneider at arm.com> wrote:
>> diff --git a/include/linux/irq.h b/include/linux/irq.h
>> index bee82809107c..580b1b6b1799 100644
>> --- a/include/linux/irq.h
>> +++ b/include/linux/irq.h
>> @@ -219,6 +219,8 @@ struct irq_data {
>>   *				  irq_chip::irq_set_affinity() when deactivated.
>>   * IRQD_IRQ_ENABLED_ON_SUSPEND	- Interrupt is enabled on suspend by irq pm if
>>   *				  irqchip have flag IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND set.
>> + * IRQD_IRQ_FLOW_MASKED         - Interrupt is masked by ACK. Only EOI can
>> + *                                clear this.
>
> Nitpick of the day : Seems text above is using tabs for white space blocks
> whereas you have used spaces. Make it consistent.
> It's not consistent in the file so I guess you could clean that up, or
> just go with making it consistent in this block.
>

I usually let my editor take the wheel when it comes to whitespace vs tabs,
but it does look like it's not aligned with the rest here.


From mike.leach at linaro.org  Fri Apr  9 11:37:12 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:12 +0100
Subject: [PATCH v6 00/10]  CoreSight configuration management; ETM strobing
Message-ID: <20210409103722.26290-1-mike.leach@linaro.org>

This patchset introduces initial concepts in CoreSight system
configuration management support. to allow more detailed and complex
programming to be applied to CoreSight systems during trace capture.

Configurations consist of 2 elements:-
1) Features - programming combinations for devices, applied to a class of
device on the system (all ETMv4), or individual devices.
2) Configurations - a set of programmed features used when the named
configuration is selected.

Features and configurations are declared as a data table, a set of register,
resource and parameter requirements. Features and configurations are loaded
into the system by the virtual cs_syscfg device. This then matches features
to any registered devices and loads the feature into them.

Individual device classes that support feature and configuration register
with cs_syscfg.

Once loaded a configuration can be enabled for a specific trace run.
Configurations are registered with the perf cs_etm event as entries in
cs_etm/events. These can be selected on the perf command line as follows:-

perf record -e cs_etm/<config_name>/ ...

This patch set has one pre-loaded configuration and feature.
A named "strobing" feature is provided for ETMv4.
A named "autofdo" configuration is provided. This configuration enables
strobing on any ETM in used.

Thus the command:
perf record -e cs_etm/autofdo/ ...

will trace the supplied application while enabling the "autofdo" configuation
on each ETM as it is enabled by perf. This in turn will enable strobing for
the ETM - with default parameters. Parameters can be adjusted using configfs.

The sink used in the trace run will be automatically selected.

A configuration can supply up to 15 of preset parameter values, which will
subsitute in parameter values for any feature used in the configuration.

Selection of preset values as follows
perf record -e cs_etm/autofdo,preset=1/ ...

(valid presets 1-N, where N is the number supplied in the configuration, not
exceeding 15. preset=0 is the same as not selecting a preset.)

Applies to & tested against coresight/next-ETE-TRBE (5.12-rc3 base)

Changes since v5:

1) Fix code style issues from auto-build reports, as
Reported-by: kernel test robot <lkp at intel.com>
2) Update comments to get consistent docs for API functions.
3) remove unused #define from autofdo example.
4) fix perf code style issues from patch 4 (Mathieu)
5) fix configfs code style issues from patch 9. (Mathieu)

Changes since v4: (based on comments from Matthieu and Suzuki).
No large functional changes - primarily code improvements and naming schema.
1) Updated entire set to ensure a consistent naming scheme was used for
variables and struct members that refer to the key objects in the system.
Suffixes _desc used for all references to feature and configuraion descriptors,
suffix _csdev used for all references to load feature and configs in the csdev
instances. (Mathieu & Suzuki).
2) Dropped the 'configurations' sub dir in cs_etm perf directories as superfluous
with the configfs containing the same information. (Mathieu).
3) Simplified perf handling code (suzuki)
4) Multiple simplifications and improvements for code readability (Matthieu
and Suzuki)

Changes since v3: (Primarily based on comments from Matthieu)
1) Locking mechanisms simplified.
2) Removed the possibility to enable features independently from
configurations.Only configurations can be enabled now. Simplifies programming
logic.
3) Configuration now uses an activate->enable mechanism. This means that perf
will activate a selected configuration at the start of a session (during
setup_aux), and disable at the end of a session (around free_aux)
The active configuration and associated features will be programmed into the
CoreSight device instances when they are enabled. This locks the configuration
into the system while in use. Parameters cannot be altered while this is
in place. This mechanism will be extended in future for dynamic load / unload
of configurations to prevent removal while in use.
4) Removed the custom bus / driver as un-necessary. A single device is
registered to own perf fs elements and configfs.
5) Various other minor issues addressed.

Changes since v2:
1) Added documentation file.
2) Altered cs_syscfg driver to no longer be coresight_device based, and moved
to its own custom bus to remove it from the main coresight bus. (Mathieu)
3) Added configfs support to inspect and control loaded configurations and
features. Allows listing of preset values (Yabin Cui)
4) Dropped sysfs support for adjusting feature parameters on the per device
basis, in favour of a single point adjustment in configfs that is pushed to all
device instances.
5) Altered how the config and preset command line options are handled in perf
and the drivers. (Mathieu and Suzuki).
6) Fixes for various issues and technical points (Mathieu, Yabin)

Changes since v1:
1) Moved preloaded configurations and features out of individual drivers.
2) Added cs_syscfg driver to manage configurations and features. Individual
drivers register with cs_syscfg indicating support for config, and provide
matching information that the system uses to load features into the drivers.
This allows individual drivers to be updated on an as needed basis - and
removes the need to consider devices that cannot benefit from configuration -
static replicators, funnels, tpiu.
3) Added perf selection of configuarations.
4) Rebased onto the coresight module loading set. 

To follow in future revisions / sets:-
a) load of additional config and features by loadable module.
b) load of additional config and features by configfs
c) enhanced resource management for ETMv4 and checking features have sufficient
resources to be enabled.
d) ECT and CTI support for configuration and features.

Mike Leach (10):
  coresight: syscfg: Initial coresight system configuration
  coresight: syscfg: Add registration and feature loading for cs devices
  coresight: config: Add configuration and feature generic functions
  coresight: etm-perf: update to handle configuration selection
  coresight: syscfg: Add API to activate and enable configurations
  coresight: etm-perf: Update to activate selected configuration
  coresight: etm4x: Add complex configuration handlers to etmv4
  coresight: config: Add preloaded configurations
  coresight: syscfg: Add initial configfs support
  Documentation: coresight: Add documentation for CoreSight config

 .../trace/coresight/coresight-config.rst      | 244 ++++++
 Documentation/trace/coresight/coresight.rst   |  16 +
 drivers/hwtracing/coresight/Makefile          |   7 +-
 .../hwtracing/coresight/coresight-cfg-afdo.c  | 147 ++++
 .../coresight/coresight-cfg-preload.c         |  27 +
 .../coresight/coresight-cfg-preload.h         |  11 +
 .../hwtracing/coresight/coresight-config.c    | 275 ++++++
 .../hwtracing/coresight/coresight-config.h    | 253 ++++++
 drivers/hwtracing/coresight/coresight-core.c  |  12 +-
 .../hwtracing/coresight/coresight-etm-perf.c  | 150 +++-
 .../hwtracing/coresight/coresight-etm-perf.h  |  12 +-
 .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  30 +
 .../coresight/coresight-etm4x-core.c          |  38 +-
 .../coresight/coresight-etm4x-sysfs.c         |   3 +
 .../coresight/coresight-syscfg-configfs.c     | 396 +++++++++
 .../coresight/coresight-syscfg-configfs.h     |  45 +
 .../hwtracing/coresight/coresight-syscfg.c    | 804 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |  81 ++
 include/linux/coresight.h                     |   7 +
 20 files changed, 2704 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/trace/coresight/coresight-config.rst
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h
 create mode 100644 drivers/hwtracing/coresight/coresight-config.c
 create mode 100644 drivers/hwtracing/coresight/coresight-config.h
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h

-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:15 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:15 +0100
Subject: [PATCH v6 03/10] coresight: config: Add configuration and feature
 generic functions
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-4-mike.leach@linaro.org>

Adds a set of generic support functions that allow devices to set and save
features values on the device, and enable and disable configurations.

Additional functions for other common operations including feature
reset.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-config.c    | 275 ++++++++++++++++++
 .../hwtracing/coresight/coresight-config.h    |   9 +
 .../hwtracing/coresight/coresight-syscfg.c    |   3 +-
 4 files changed, 287 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-config.c

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 3d037f17aade..63ecfc3cf66d 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o coresight-syscfg.o
+		coresight-sysfs.o coresight-syscfg.o coresight-config.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-config.c b/drivers/hwtracing/coresight/coresight-config.c
new file mode 100644
index 000000000000..3c501e027bc0
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-config.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/sysfs.h>
+#include "coresight-config.h"
+#include "coresight-priv.h"
+
+/*
+ * This provides a set of generic functions that operate on configurations
+ * and features to manage the handling of parameters, the programming and
+ * saving of registers used by features on devices.
+ */
+
+/*
+ * Write the value held in the register structure into the driver internal memory
+ * location.
+ */
+static void cscfg_set_reg(struct cscfg_regval_csdev *reg_csdev)
+{
+	u32 *p_val32 = (u32 *)reg_csdev->driver_regval;
+	u32 tmp32 = reg_csdev->reg_desc.val32;
+
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT) {
+		*((u64 *)reg_csdev->driver_regval) = reg_csdev->reg_desc.val64;
+		return;
+	}
+
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_MASK) {
+		tmp32 = *p_val32;
+		tmp32 &= ~reg_csdev->reg_desc.mask32;
+		tmp32 |= reg_csdev->reg_desc.val32 & reg_csdev->reg_desc.mask32;
+	}
+	*p_val32 = tmp32;
+}
+
+/*
+ * Read the driver value into the reg if this is marked as one we want to save.
+ */
+static void cscfg_save_reg(struct cscfg_regval_csdev *reg_csdev)
+{
+	if (!(reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_SAVE))
+		return;
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT)
+		reg_csdev->reg_desc.val64 = *(u64 *)(reg_csdev->driver_regval);
+	else
+		reg_csdev->reg_desc.val32 = *(u32 *)(reg_csdev->driver_regval);
+}
+
+/*
+ * Some register values are set from parameters. Initialise these registers
+ * from the current parameter values.
+ */
+static void cscfg_init_reg_param(struct cscfg_feature_csdev *feat_csdev,
+				 struct cscfg_regval_desc *reg_desc,
+				 struct cscfg_regval_csdev *reg_csdev)
+{
+	struct cscfg_parameter_csdev *param_csdev;
+
+	/* for param, load routines have validated the index */
+	param_csdev = &feat_csdev->params_csdev[reg_desc->param_idx];
+	param_csdev->reg_csdev = reg_csdev;
+	param_csdev->val64 = reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT;
+
+	if (param_csdev->val64)
+		reg_csdev->reg_desc.val64 = param_csdev->current_value;
+	else
+		reg_csdev->reg_desc.val32 = (u32)param_csdev->current_value;
+}
+
+/* set values into the driver locations referenced in cscfg_reg_csdev */
+static int cscfg_set_on_enable(struct cscfg_feature_csdev *feat_csdev)
+{
+	int i;
+
+	spin_lock(feat_csdev->drv_spinlock);
+	for (i = 0; i < feat_csdev->nr_regs; i++)
+		cscfg_set_reg(&feat_csdev->regs_csdev[i]);
+	spin_unlock(feat_csdev->drv_spinlock);
+	dev_dbg(&feat_csdev->csdev->dev, "Feature %s: %s",
+		feat_csdev->feat_desc->name, "set on enable");
+	return 0;
+}
+
+/* copy back values from the driver locations referenced in cscfg_reg_csdev */
+static void cscfg_save_on_disable(struct cscfg_feature_csdev *feat_csdev)
+{
+	int i;
+
+	spin_lock(feat_csdev->drv_spinlock);
+	for (i = 0; i < feat_csdev->nr_regs; i++)
+		cscfg_save_reg(&feat_csdev->regs_csdev[i]);
+	spin_unlock(feat_csdev->drv_spinlock);
+	dev_dbg(&feat_csdev->csdev->dev, "Feature %s: %s",
+		feat_csdev->feat_desc->name, "save on disable");
+}
+
+/* default reset - restore default values */
+void cscfg_reset_feat(struct cscfg_feature_csdev *feat_csdev)
+{
+	struct cscfg_regval_desc *reg_desc;
+	struct cscfg_regval_csdev *reg_csdev;
+	int i;
+
+	/*
+	 * set the default values for all parameters and regs from the
+	 * relevant static descriptors.
+	 */
+	for (i = 0; i < feat_csdev->nr_params; i++)
+		feat_csdev->params_csdev[i].current_value =
+			feat_csdev->feat_desc->params_desc[i].value;
+
+	for (i = 0; i < feat_csdev->nr_regs; i++) {
+		reg_desc = &feat_csdev->feat_desc->regs_desc[i];
+		reg_csdev = &feat_csdev->regs_csdev[i];
+		reg_csdev->reg_desc.type = reg_desc->type;
+
+		/* check if reg set from a parameter otherwise desc default */
+		if (reg_desc->type & CS_CFG_REG_TYPE_VAL_PARAM)
+			cscfg_init_reg_param(feat_csdev, reg_desc, reg_csdev);
+		else
+			/*
+			 * for normal values the union between val64 & val32 + mask32
+			 * allows us to init using the 64 bit value
+			 */
+			reg_csdev->reg_desc.val64 = reg_desc->val64;
+	}
+}
+
+/*
+ * For the selected presets, we set the register associated with the parameter, to
+ * the value of the preset index associated with the parameter.
+ */
+static int cscfg_update_presets(struct cscfg_config_csdev *config_csdev, int preset)
+{
+	int i, j, val_idx = 0, nr_cfg_params;
+	struct cscfg_parameter_csdev *param_csdev;
+	struct cscfg_feature_csdev *feat_csdev;
+	const struct cscfg_config_desc *config_desc = config_csdev->config_desc;
+	const char *name;
+	const u64 *preset_base;
+	u64 val;
+
+	/* preset in range 1 to nr_presets */
+	if (preset < 1 || preset > config_desc->nr_presets)
+		return -EINVAL;
+	/*
+	 * Go through the array of features, assigning preset values to
+	 * feature parameters in the order they appear.
+	 * There should be precisely the same number of preset values as the
+	 * sum of number of parameters over all the features - but we will
+	 * ensure there is no overrun.
+	 */
+	nr_cfg_params = config_desc->nr_total_params;
+	preset_base = &config_desc->presets[(preset - 1) * nr_cfg_params];
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		if (!feat_csdev->nr_params)
+			continue;
+
+		for (j = 0; j < feat_csdev->nr_params; j++) {
+			param_csdev = &feat_csdev->params_csdev[j];
+			name = feat_csdev->feat_desc->params_desc[j].name;
+			val = preset_base[val_idx++];
+			if (param_csdev->val64) {
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%lld)", name, val);
+				param_csdev->reg_csdev->reg_desc.val64 = val;
+			} else {
+				param_csdev->reg_csdev->reg_desc.val32 = (u32)val;
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%d)", name, (u32)val);
+			}
+		}
+
+		/* exit early if all params filled */
+		if (val_idx >= nr_cfg_params)
+			break;
+	}
+	return 0;
+}
+
+/*
+ * if we are not using a preset, then need to update the feature params
+ * with current values. This sets the register associated with the parameter
+ * with the current value of that parameter.
+ */
+static int cscfg_update_curr_params(struct cscfg_config_csdev *config_csdev)
+{
+	int i, j;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_parameter_csdev *param_csdev;
+	const char *name;
+	u64 val;
+
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		if (!feat_csdev->nr_params)
+			continue;
+		for (j = 0; j < feat_csdev->nr_params; j++) {
+			param_csdev = &feat_csdev->params_csdev[j];
+			name = feat_csdev->feat_desc->params_desc[j].name;
+			val = param_csdev->current_value;
+			if (param_csdev->val64) {
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%lld)", name, val);
+				param_csdev->reg_csdev->reg_desc.val64 = val;
+			} else {
+				param_csdev->reg_csdev->reg_desc.val32 = (u32)val;
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%d)", name, (u32)val);
+			}
+		}
+	}
+	return 0;
+}
+
+/*
+ * Configuration values will be programmed into the driver locations if enabling, or read
+ * from relevant locations on disable.
+ */
+static int cscfg_prog_config(struct cscfg_config_csdev *config_csdev, bool enable)
+{
+	int i, err = 0;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct coresight_device *csdev;
+
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		csdev = feat_csdev->csdev;
+		dev_dbg(&csdev->dev, "cfg %s;  %s feature:%s", config_csdev->config_desc->name,
+			enable ? "enable" : "disable", feat_csdev->feat_desc->name);
+
+		if (enable)
+			err = cscfg_set_on_enable(feat_csdev);
+		else
+			cscfg_save_on_disable(feat_csdev);
+
+		if (err)
+			break;
+	}
+	return err;
+}
+
+/*
+ * Enable configuration for the device. Will result in the internal driver data
+ * being updated ready for programming into the device.
+ *
+ * @config_csdev:	config_csdev to set.
+ * @preset:		preset values to use - 0 for default.
+ */
+int cscfg_csdev_enable_config(struct cscfg_config_csdev *config_csdev, int preset)
+{
+	int err = 0;
+
+	if (preset)
+		err = cscfg_update_presets(config_csdev, preset);
+	else
+		err = cscfg_update_curr_params(config_csdev);
+	if (!err)
+		err = cscfg_prog_config(config_csdev, true);
+	if (!err)
+		config_csdev->enabled = true;
+	return err;
+}
+
+void cscfg_csdev_disable_config(struct cscfg_config_csdev *config_csdev)
+{
+	if (config_csdev->enabled) {
+		cscfg_prog_config(config_csdev, false);
+		config_csdev->enabled = false;
+	}
+}
diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 685fb46ce893..5a39cbbc38a4 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -237,4 +237,13 @@ struct cscfg_csdev_feat_ops {
 			 struct cscfg_feature_csdev *feat_csdev);
 };
 
+/* coresight config helper functions*/
+
+/* enable / disable config on a device - called with appropriate locks set.*/
+int cscfg_csdev_enable_config(struct cscfg_config_csdev *config_csdev, int preset);
+void cscfg_csdev_disable_config(struct cscfg_config_csdev *config_csdev);
+
+/* reset a feature to default values */
+void cscfg_reset_feat(struct cscfg_feature_csdev *feat_csdev);
+
 #endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index e93e62c1efbb..c7f48d6b48f5 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -190,9 +190,10 @@ static int cscfg_load_feat_csdev(struct coresight_device *csdev,
 	if (err)
 		return err;
 
-	/* add to internal csdev feature list */
+	/* add to internal csdev feature list & initialise using reset call */
 	mutex_lock(&cscfg_csdev_mutex);
 	list_add(&feat_csdev->node, &csdev->feature_csdev_list);
+	cscfg_reset_feat(feat_csdev);
 	mutex_unlock(&cscfg_csdev_mutex);
 
 	return 0;
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:17 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:17 +0100
Subject: [PATCH v6 05/10] coresight: syscfg: Add API to activate and enable
 configurations
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-6-mike.leach@linaro.org>

Configurations are first activated, then when any coresight device is
enabled, the active configurations are checked and any matching
one is enabled.

This patch provides the activation / enable API.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |   2 +
 .../hwtracing/coresight/coresight-syscfg.c    | 172 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |   8 +
 include/linux/coresight.h                     |   2 +
 4 files changed, 184 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 0667581822c1..25eb6c632692 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -127,6 +127,7 @@ struct cscfg_feature_desc {
  * @nr_total_params:	Sum of all parameters declared by used features
  * @presets:		Array of preset values.
  * @event_ea:		Extended attribute for perf event value
+ * @active_cnt:		ref count for activate on this configuration.
  *
  */
 struct cscfg_config_desc {
@@ -139,6 +140,7 @@ struct cscfg_config_desc {
 	int nr_total_params;
 	const u64 *presets; /* nr_presets * nr_total_params */
 	struct dev_ext_attribute *event_ea;
+	atomic_t active_cnt;
 };
 
 /**
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index e35f8c0ac2f8..b234e45c153f 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -283,6 +283,7 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 		return err;
 
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
+	atomic_set(&config_desc->active_cnt, 0);
 	return 0;
 }
 
@@ -468,6 +469,176 @@ void cscfg_unregister_csdev(struct coresight_device *csdev)
 }
 EXPORT_SYMBOL_GPL(cscfg_unregister_csdev);
 
+/**
+ * cscfg_csdev_reset_feats - reset features for a CoreSight device.
+ *
+ * Resets all parameters and register values for any features loaded
+ * into @csdev to their default values.
+ *
+ * @csdev: The CoreSight device.
+ */
+void cscfg_csdev_reset_feats(struct coresight_device *csdev)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	if (list_empty(&csdev->feature_csdev_list))
+		goto unlock_exit;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node)
+		cscfg_reset_feat(feat_csdev);
+
+unlock_exit:
+	mutex_unlock(&cscfg_csdev_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_reset_feats);
+
+/**
+ * cscfg_activate_config -  Mark a configuration descriptor as active.
+ *
+ * This will be seen when csdev devices are enabled in the system.
+ * Only activated configurations can be enabled on individual devices.
+ * Activation protects the configuration from alteration or removal while
+ * active.
+ *
+ * Selection by hash value - generated from the configuration name when it
+ * was loaded and added to the cs_etm/configurations file system for selection
+ * by perf.
+ *
+ * Increments the configuration descriptor active count and the global active
+ * count.
+ *
+ * @cfg_hash: Hash value of the selected configuration name.
+ */
+int cscfg_activate_config(unsigned long cfg_hash)
+{
+	struct cscfg_config_desc *config_desc;
+	int err = -EINVAL;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
+			/*
+			 * increment the global active count - control changes to
+			 * active configurations
+			 */
+			atomic_inc(&cscfg_mgr->sys_active_cnt);
+
+			/*
+			 * mark the descriptor as active so enable config on a
+			 * device instance will use it
+			 */
+			atomic_inc(&config_desc->active_cnt);
+
+			err = 0;
+			dev_dbg(cscfg_device(), "Activate config %s.\n", config_desc->name);
+			break;
+		}
+	}
+	mutex_unlock(&cscfg_mutex);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_activate_config);
+
+/**
+ * cscfg_deactivate_config -  Mark a config descriptor as inactive.
+ *
+ * Decrement the configuration and global active counts.
+ *
+ * @cfg_hash: Hash value of the selected configuration name.
+ */
+void cscfg_deactivate_config(unsigned long cfg_hash)
+{
+	struct cscfg_config_desc *config_desc;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
+			atomic_dec(&config_desc->active_cnt);
+			atomic_dec(&cscfg_mgr->sys_active_cnt);
+			dev_dbg(cscfg_device(), "Deactivate config %s.\n", config_desc->name);
+			break;
+		}
+	}
+	mutex_unlock(&cscfg_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_deactivate_config);
+
+/**
+ * cscfg_csdev_enable_active_config - Enable matching active configuration for device.
+ *
+ * Enables the configuration selected by @cfg_hash if the configuration is supported
+ * on the device and has been activated.
+ *
+ * If active and supported the CoreSight device @csdev will be programmed with the
+ * configuration, using @preset parameters.
+ *
+ * Should be called before driver hardware enable for the requested device, prior to
+ * programming and enabling the physical hardware.
+ *
+ * @csdev:	CoreSight device to program.
+ * @cfg_hash:	Selector for the configuration.
+ * @preset:	Preset parameter values to use, 0 for current / default values.
+ */
+int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
+				     unsigned long cfg_hash, int preset)
+{
+	struct cscfg_config_csdev *config_csdev_active = NULL, *config_csdev_item;
+	const struct cscfg_config_desc *config_desc;
+	int err = 0;
+
+	/* quickly check global count */
+	if (!atomic_read(&cscfg_mgr->sys_active_cnt))
+		return 0;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	list_for_each_entry(config_csdev_item, &csdev->config_csdev_list, node) {
+		config_desc = config_csdev_item->config_desc;
+		if ((atomic_read(&config_desc->active_cnt)) &&
+		    ((unsigned long)config_desc->event_ea->var == cfg_hash)) {
+			config_csdev_active = config_csdev_item;
+			break;
+		}
+	}
+	if (config_csdev_active) {
+		err = cscfg_csdev_enable_config(config_csdev_active, preset);
+		if (!err)
+			csdev->active_cscfg_ctxt = (void *)config_csdev_active;
+	}
+	mutex_unlock(&cscfg_csdev_mutex);
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_enable_active_config);
+
+/**
+ * cscfg_csdev_disable_active_config - disable an active config on the device.
+ *
+ * Disables the active configuration on the CoreSight device @csdev.
+ * Disable will save the values of any registers marked in the configurations
+ * as save on disable.
+ *
+ * Should be called after driver hardware disable for the requested device,
+ * after disabling the physical hardware and reading back registers.
+ *
+ * @csdev: The CoreSight device.
+ */
+void cscfg_csdev_disable_active_config(struct coresight_device *csdev)
+{
+	struct cscfg_config_csdev *config_csdev;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	config_csdev = (struct cscfg_config_csdev *)csdev->active_cscfg_ctxt;
+	if (config_csdev) {
+		cscfg_csdev_disable_config(config_csdev);
+		csdev->active_cscfg_ctxt = NULL;
+	}
+	mutex_unlock(&cscfg_csdev_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_disable_active_config);
+
 /* Initialise system configuration management device. */
 
 struct device *cscfg_device(void)
@@ -536,6 +707,7 @@ int __init cscfg_init(void)
 	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
+	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
 
 	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
 	return 0;
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 5bcae3b374c6..a52775890670 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -24,12 +24,14 @@
  * @csdev_desc_list:	List of coresight devices registered with the configuration manager.
  * @feat_desc_list:	List of feature descriptors to load into registered devices.
  * @config_desc_list:	List of system configuration descriptors to load into registered devices.
+ * @sys_active_cnt:	Total number of active config descriptor references.
  */
 struct cscfg_manager {
 	struct device dev;
 	struct list_head csdev_desc_list;
 	struct list_head feat_desc_list;
 	struct list_head config_desc_list;
+	atomic_t sys_active_cnt;
 };
 
 /* get reference to dev in cscfg_manager */
@@ -61,5 +63,11 @@ int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
 int cscfg_register_csdev(struct coresight_device *csdev, u32 match_flags,
 			 struct cscfg_csdev_feat_ops *ops);
 void cscfg_unregister_csdev(struct coresight_device *csdev);
+int cscfg_activate_config(unsigned long cfg_hash);
+void cscfg_deactivate_config(unsigned long cfg_hash);
+void cscfg_csdev_reset_feats(struct coresight_device *csdev);
+int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
+				     unsigned long cfg_hash, int preset);
+void cscfg_csdev_disable_active_config(struct coresight_device *csdev);
 
 #endif /* CORESIGHT_SYSCFG_H */
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 6fb516e1b22e..a348049ee08b 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -222,6 +222,7 @@ struct coresight_sysfs_link {
  * @has_conns_grp: Have added a "connections" group for sysfs links.
  * @feature_csdev_list: List of complex feature programming added to the device.
  * @config_csdev_list:  List of system configurations added to the device.
+ * @active_cscfg_ctxt:  Context information for current active system configuration.
  */
 struct coresight_device {
 	struct coresight_platform_data *pdata;
@@ -246,6 +247,7 @@ struct coresight_device {
 	/* system configuration and feature lists */
 	struct list_head feature_csdev_list;
 	struct list_head config_csdev_list;
+	void *active_cscfg_ctxt;
 };
 
 /*
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:16 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:16 +0100
Subject: [PATCH v6 04/10] coresight: etm-perf: update to handle configuration
 selection
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-5-mike.leach@linaro.org>

Loaded coresight configurations are registered in the cs_etm\events sub
directory. This extends the etm-perf code to handle these registrations,
and the cs_syscfg driver to perform the registration on load.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |   2 +
 .../hwtracing/coresight/coresight-etm-perf.c  | 134 ++++++++++++++----
 .../hwtracing/coresight/coresight-etm-perf.h  |   8 ++
 .../hwtracing/coresight/coresight-syscfg.c    |  11 ++
 4 files changed, 127 insertions(+), 28 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 5a39cbbc38a4..0667581822c1 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -126,6 +126,7 @@ struct cscfg_feature_desc {
  * @nr_presets:		Number of sets of presets supplied by this configuration.
  * @nr_total_params:	Sum of all parameters declared by used features
  * @presets:		Array of preset values.
+ * @event_ea:		Extended attribute for perf event value
  *
  */
 struct cscfg_config_desc {
@@ -137,6 +138,7 @@ struct cscfg_config_desc {
 	int nr_presets;
 	int nr_total_params;
 	const u64 *presets; /* nr_presets * nr_total_params */
+	struct dev_ext_attribute *event_ea;
 };
 
 /**
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 15310c72f89f..26b4bca156aa 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -18,8 +18,10 @@
 #include <linux/types.h>
 #include <linux/workqueue.h>
 
+#include "coresight-config.h"
 #include "coresight-etm-perf.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static struct pmu etm_pmu;
 static bool etm_perf_up;
@@ -57,8 +59,13 @@ PMU_FORMAT_ATTR(contextid1,	"config:" __stringify(ETM_OPT_CTXTID));
 PMU_FORMAT_ATTR(contextid2,	"config:" __stringify(ETM_OPT_CTXTID2));
 PMU_FORMAT_ATTR(timestamp,	"config:" __stringify(ETM_OPT_TS));
 PMU_FORMAT_ATTR(retstack,	"config:" __stringify(ETM_OPT_RETSTK));
+/* preset - if sink ID is used as a configuration selector */
+PMU_FORMAT_ATTR(preset,		"config:0-3");
 /* Sink ID - same for all ETMs */
 PMU_FORMAT_ATTR(sinkid,		"config2:0-31");
+/* config ID - set if a system configuration is selected */
+PMU_FORMAT_ATTR(configid,	"config2:32-63");
+
 
 /*
  * contextid always traces the "PID".  The PID is in CONTEXTIDR_EL1
@@ -88,6 +95,8 @@ static struct attribute *etm_config_formats_attr[] = {
 	&format_attr_timestamp.attr,
 	&format_attr_retstack.attr,
 	&format_attr_sinkid.attr,
+	&format_attr_preset.attr,
+	&format_attr_configid.attr,
 	NULL,
 };
 
@@ -105,9 +114,19 @@ static const struct attribute_group etm_pmu_sinks_group = {
 	.attrs  = etm_config_sinks_attr,
 };
 
+static struct attribute *etm_config_events_attr[] = {
+	NULL,
+};
+
+static const struct attribute_group etm_pmu_events_group = {
+	.name   = "events",
+	.attrs  = etm_config_events_attr,
+};
+
 static const struct attribute_group *etm_pmu_attr_groups[] = {
 	&etm_pmu_format_group,
 	&etm_pmu_sinks_group,
+	&etm_pmu_events_group,
 	NULL,
 };
 
@@ -286,7 +305,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	INIT_WORK(&event_data->work, free_event_data);
 
 	/* First get the selected sink from user space. */
-	if (event->attr.config2) {
+	if (event->attr.config2 & GENMASK_ULL(31, 0)) {
 		id = (u32)event->attr.config2;
 		sink = user_sink = coresight_get_sink_by_id(id);
 	}
@@ -658,68 +677,127 @@ static ssize_t etm_perf_sink_name_show(struct device *dev,
 	return scnprintf(buf, PAGE_SIZE, "0x%lx\n", (unsigned long)(ea->var));
 }
 
-int etm_perf_add_symlink_sink(struct coresight_device *csdev)
+static struct dev_ext_attribute *
+etm_perf_add_symlink_group(struct device *dev, const char *name, const char *group_name)
 {
-	int ret;
+	struct dev_ext_attribute *ea;
 	unsigned long hash;
-	const char *name;
+	int ret;
 	struct device *pmu_dev = etm_pmu.dev;
-	struct device *dev = &csdev->dev;
-	struct dev_ext_attribute *ea;
-
-	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
-	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
-		return -EINVAL;
-
-	if (csdev->ea != NULL)
-		return -EINVAL;
 
 	if (!etm_perf_up)
-		return -EPROBE_DEFER;
+		return ERR_PTR(-EPROBE_DEFER);
 
 	ea = devm_kzalloc(dev, sizeof(*ea), GFP_KERNEL);
 	if (!ea)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
-	name = dev_name(dev);
-	/* See function coresight_get_sink_by_id() to know where this is used */
+	/*
+	 * If this function is called adding a sink then the hash is used for
+	 * sink selection - see function coresight_get_sink_by_id().
+	 * If adding a configuration then the hash is used for selection in
+	 * cscfg_activate_config()
+	 */
 	hash = hashlen_hash(hashlen_string(NULL, name));
 
 	sysfs_attr_init(&ea->attr.attr);
 	ea->attr.attr.name = devm_kstrdup(dev, name, GFP_KERNEL);
 	if (!ea->attr.attr.name)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	ea->attr.attr.mode = 0444;
-	ea->attr.show = etm_perf_sink_name_show;
 	ea->var = (unsigned long *)hash;
 
 	ret = sysfs_add_file_to_group(&pmu_dev->kobj,
-				      &ea->attr.attr, "sinks");
+				      &ea->attr.attr, group_name);
 
-	if (!ret)
-		csdev->ea = ea;
+	return ret ? ERR_PTR(ret) : ea;
+}
 
-	return ret;
+int etm_perf_add_symlink_sink(struct coresight_device *csdev)
+{
+	const char *name;
+	struct device *dev = &csdev->dev;
+	int err = 0;
+
+	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+		return -EINVAL;
+
+	if (csdev->ea != NULL)
+		return -EINVAL;
+
+	name = dev_name(dev);
+	csdev->ea = etm_perf_add_symlink_group(dev, name, "sinks");
+	if (IS_ERR(csdev->ea)) {
+		err = PTR_ERR(csdev->ea);
+		csdev->ea = NULL;
+	} else
+		csdev->ea->attr.show = etm_perf_sink_name_show;
+
+	return err;
 }
 
-void etm_perf_del_symlink_sink(struct coresight_device *csdev)
+static void etm_perf_del_symlink_group(struct dev_ext_attribute *ea, const char *group_name)
 {
 	struct device *pmu_dev = etm_pmu.dev;
-	struct dev_ext_attribute *ea = csdev->ea;
 
+	sysfs_remove_file_from_group(&pmu_dev->kobj,
+				     &ea->attr.attr, group_name);
+}
+
+void etm_perf_del_symlink_sink(struct coresight_device *csdev)
+{
 	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
 	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
 		return;
 
-	if (!ea)
+	if (!csdev->ea)
 		return;
 
-	sysfs_remove_file_from_group(&pmu_dev->kobj,
-				     &ea->attr.attr, "sinks");
+	etm_perf_del_symlink_group(csdev->ea, "sinks");
 	csdev->ea = NULL;
 }
 
+static ssize_t etm_perf_cscfg_event_show(struct device *dev,
+					 struct device_attribute *dattr,
+					 char *buf)
+{
+	struct dev_ext_attribute *ea;
+
+	ea = container_of(dattr, struct dev_ext_attribute, attr);
+	return scnprintf(buf, PAGE_SIZE, "configid=0x%lx\n", (unsigned long)(ea->var));
+}
+
+int etm_perf_add_symlink_cscfg(struct device *dev, struct cscfg_config_desc *config_desc)
+{
+	int err = 0;
+
+	if (config_desc->event_ea != NULL)
+		return 0;
+
+	config_desc->event_ea = etm_perf_add_symlink_group(dev, config_desc->name, "events");
+
+	/* set the show function to the custom cscfg event */
+	if (!IS_ERR(config_desc->event_ea))
+		config_desc->event_ea->attr.show = etm_perf_cscfg_event_show;
+	else {
+		err = PTR_ERR(config_desc->event_ea);
+		config_desc->event_ea = NULL;
+	}
+
+	return err;
+}
+
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc)
+{
+	if (!config_desc->event_ea)
+		return;
+
+	etm_perf_del_symlink_group(config_desc->event_ea, "events");
+	config_desc->event_ea = NULL;
+}
+
 int __init etm_perf_init(void)
 {
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 29d90dfeba31..ba617fe2217e 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -11,6 +11,7 @@
 #include "coresight-priv.h"
 
 struct coresight_device;
+struct cscfg_config_desc;
 
 /*
  * In both ETMv3 and v4 the maximum number of address comparator implentable
@@ -69,6 +70,9 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 		return data->snk_config;
 	return NULL;
 }
+int etm_perf_add_symlink_cscfg(struct device *dev,
+			       struct cscfg_config_desc *config_desc);
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc);
 #else
 static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
 { return -EINVAL; }
@@ -79,6 +83,10 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 {
 	return NULL;
 }
+int etm_perf_add_symlink_cscfg(struct device *dev,
+			       struct cscfg_config_desc *config_desc)
+{ return -EINVAL; }
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc) {}
 
 #endif /* CONFIG_CORESIGHT */
 
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index c7f48d6b48f5..e35f8c0ac2f8 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -7,6 +7,7 @@
 #include <linux/platform_device.h>
 
 #include "coresight-config.h"
+#include "coresight-etm-perf.h"
 #include "coresight-syscfg.h"
 
 /*
@@ -276,6 +277,11 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	if (err)
 		return err;
 
+	/* add config to perf fs to allow selection */
+	err = etm_perf_add_symlink_cscfg(cscfg_device(), config_desc);
+	if (err)
+		return err;
+
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
 	return 0;
 }
@@ -508,7 +514,12 @@ static int cscfg_create_device(void)
 
 static void cscfg_clear_device(void)
 {
+	struct cscfg_config_desc *cfg_desc;
+
 	mutex_lock(&cscfg_mutex);
+	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
+		etm_perf_del_symlink_cscfg(cfg_desc);
+	}
 	device_unregister(cscfg_device());
 	mutex_unlock(&cscfg_mutex);
 }
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:18 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:18 +0100
Subject: [PATCH v6 06/10] coresight: etm-perf: Update to activate selected
 configuration
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-7-mike.leach@linaro.org>

Add calls to activate the selected configuration as perf starts
and stops the tracing session.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 14 +++++++++++++-
 drivers/hwtracing/coresight/coresight-etm-perf.h |  2 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 26b4bca156aa..560baefdfed8 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -215,6 +215,10 @@ static void free_event_data(struct work_struct *work)
 	/* Free the sink buffers, if there are any */
 	free_sink_buffer(event_data);
 
+	/* clear any configuration we were using */
+	if (event_data->cfg_hash)
+		cscfg_deactivate_config(event_data->cfg_hash);
+
 	for_each_cpu(cpu, mask) {
 		struct list_head **ppath;
 
@@ -292,7 +296,7 @@ static bool sinks_compatible(struct coresight_device *a,
 static void *etm_setup_aux(struct perf_event *event, void **pages,
 			   int nr_pages, bool overwrite)
 {
-	u32 id;
+	u32 id, cfg_hash;
 	int cpu = event->cpu;
 	cpumask_t *mask;
 	struct coresight_device *sink = NULL;
@@ -310,6 +314,14 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 		sink = user_sink = coresight_get_sink_by_id(id);
 	}
 
+	/* check if user wants a coresight configuration selected */
+	cfg_hash = (u32)((event->attr.config2 & GENMASK_ULL(63, 32)) >> 32);
+	if (cfg_hash) {
+		if (cscfg_activate_config(cfg_hash))
+			goto err;
+		event_data->cfg_hash = cfg_hash;
+	}
+
 	mask = &event_data->mask;
 
 	/*
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index ba617fe2217e..468f7799ab4f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -49,12 +49,14 @@ struct etm_filters {
  * @work:		Handle to free allocated memory outside IRQ context.
  * @mask:		Hold the CPU(s) this event was set for.
  * @snk_config:		The sink configuration.
+ * @cfg_hash:		The hash id of any coresight config selected.
  * @path:		An array of path, each slot for one CPU.
  */
 struct etm_event_data {
 	struct work_struct work;
 	cpumask_t mask;
 	void *snk_config;
+	u32 cfg_hash;
 	struct list_head * __percpu *path;
 };
 
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:13 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:13 +0100
Subject: [PATCH v6 01/10] coresight: syscfg: Initial coresight system
 configuration
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-2-mike.leach@linaro.org>

Creates an system management API to allow complex configurations and
features to be programmed into a CoreSight infrastructure.

A feature is defined as a programming set for a device or class of
devices.

A configuration is a set of features across the system that are enabled
for a trace session.

The API will manage system wide configuration, and allow complex
programmed features to be added to individual device instances, and
provide for system wide configuration selection on trace capture
operations.

This patch creates the initial data object and the initial API for
loading configurations and features.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-config.h    | 142 +++++++++++++
 drivers/hwtracing/coresight/coresight-core.c  |  12 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |   2 +-
 .../hwtracing/coresight/coresight-etm-perf.h  |   2 +-
 .../hwtracing/coresight/coresight-syscfg.c    | 199 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |  46 ++++
 7 files changed, 401 insertions(+), 4 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-config.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index d60816509755..3d037f17aade 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o
+		coresight-sysfs.o coresight-syscfg.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
new file mode 100644
index 000000000000..21aa7464dcdc
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -0,0 +1,142 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#ifndef _CORESIGHT_CORESIGHT_CONFIG_H
+#define _CORESIGHT_CORESIGHT_CONFIG_H
+
+#include <linux/coresight.h>
+#include <linux/types.h>
+
+/* CoreSight Configuration Management - component and system wide configuration */
+
+/*
+ * Register type flags for register value descriptor:
+ * describe how the value is interpreted, and handled.
+ */
+#define CS_CFG_REG_TYPE_STD		0x80	/* reg is standard reg */
+#define CS_CFG_REG_TYPE_RESOURCE	0x40	/* reg is a resource */
+#define CS_CFG_REG_TYPE_VAL_PARAM	0x08	/* reg value uses param */
+#define CS_CFG_REG_TYPE_VAL_MASK	0x04	/* reg value bit masked */
+#define CS_CFG_REG_TYPE_VAL_64BIT	0x02	/* reg value 64 bit */
+#define CS_CFG_REG_TYPE_VAL_SAVE	0x01	/* reg value save on disable */
+
+/*
+ * flags defining what device class a feature will match to when processing a
+ * system configuration - used by config data and devices.
+ */
+#define CS_CFG_MATCH_CLASS_SRC_ALL	0x0001	/* match any source */
+#define CS_CFG_MATCH_CLASS_SRC_ETM4	0x0002	/* match any ETMv4 device */
+
+/* flags defining device instance matching - used in config match desc data. */
+#define CS_CFG_MATCH_INST_ANY		0x80000000 /* any instance of a class */
+
+/*
+ * Limit number of presets in a configuration
+ * This is related to the number of bits (4) we use to select the preset on
+ * the perf command line. Preset 0 is always none selected.
+ * See PMU_FORMAT_ATTR(preset, "config:0-3") in coresight-etm-perf.c
+ */
+#define CS_CFG_CONFIG_PRESET_MAX 15
+
+/**
+ * Parameter descriptor for a device feature.
+ *
+ * @name:  Name of parameter.
+ * @value: Initial or default value.
+ */
+struct cscfg_parameter_desc {
+	const char *name;
+	u64 value;
+};
+
+/**
+ * Representation of register value and a descriptor of register usage.
+ *
+ * Used as a descriptor in the feature descriptors.
+ * Used as a value in when in a feature loading into a csdev.
+ *
+ * Supports full 64 bit register value, or 32 bit value with optional mask
+ * value.
+ *
+ * @type:	define register usage and interpretation.
+ * @offset:	the address offset for register in the hardware device (per device specification).
+ * @hw_info:	optional hardware device type specific information. (ETM / CTI specific etc)
+ * @val64:	64 bit value.
+ * @val32:	32 bit value.
+ * @mask32:	32 bit mask when using 32 bit value to access device register - if mask type.
+ * @param_idx:	parameter index value into parameter array if param type.
+ */
+struct cscfg_regval_desc {
+	struct {
+		u32 type:8;
+		u32 offset:12;
+		u32 hw_info:12;
+	};
+	union {
+		u64 val64;
+		struct {
+			u32 val32;
+			u32 mask32;
+		};
+		u32 param_idx;
+	};
+};
+
+/**
+ * Device feature descriptor - combination of registers and parameters to
+ * program a device to implement a specific complex function.
+ *
+ * @name:	 feature name.
+ * @description: brief description of the feature.
+ * @item:	 List entry.
+ * @match_flags: matching information if loading into a device
+ * @nr_params:   number of parameters used.
+ * @params_desc: array of parameters used.
+ * @nr_regs:	 number of registers used.
+ * @regs_desc:	 array of registers used.
+ */
+struct cscfg_feature_desc {
+	const char *name;
+	const char *description;
+	struct list_head item;
+	u32 match_flags;
+	int nr_params;
+	struct cscfg_parameter_desc *params_desc;
+	int nr_regs;
+	struct cscfg_regval_desc *regs_desc;
+};
+
+/**
+ * Configuration descriptor - describes selectable system configuration.
+ *
+ * A configuration describes device features in use, and may provide preset
+ * values for the parameters in those features.
+ *
+ * A single set of presets is the sum of the parameters declared by
+ * all the features in use - this value is @nr_total_params.
+ *
+ * @name:		name of the configuration - used for selection.
+ * @description:	description of the purpose of the configuration.
+ * @item:		list entry.
+ * @nr_feat_refs:	Number of features used in this configuration.
+ * @feat_ref_names:	references to features used in this configuration.
+ * @nr_presets:		Number of sets of presets supplied by this configuration.
+ * @nr_total_params:	Sum of all parameters declared by used features
+ * @presets:		Array of preset values.
+ *
+ */
+struct cscfg_config_desc {
+	const char *name;
+	const char *description;
+	struct list_head item;
+	int nr_feat_refs;
+	const char **feat_ref_names;
+	int nr_presets;
+	int nr_total_params;
+	const u64 *presets; /* nr_presets * nr_total_params */
+};
+
+#endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index 55c645616bf6..6e5641905ce0 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -21,6 +21,7 @@
 
 #include "coresight-etm-perf.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static DEFINE_MUTEX(coresight_mutex);
 DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
@@ -1764,13 +1765,22 @@ static int __init coresight_init(void)
 
 	ret = etm_perf_init();
 	if (ret)
-		bus_unregister(&coresight_bustype);
+		goto exit_bus_unregister;
 
+	/* initialise the coresight syscfg API */
+	ret = cscfg_init();
+	if (!ret)
+		return 0;
+
+	etm_perf_exit();
+exit_bus_unregister:
+	bus_unregister(&coresight_bustype);
 	return ret;
 }
 
 static void __exit coresight_exit(void)
 {
+	cscfg_exit();
 	etm_perf_exit();
 	bus_unregister(&coresight_bustype);
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f123c26b9f54..15310c72f89f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -748,7 +748,7 @@ int __init etm_perf_init(void)
 	return ret;
 }
 
-void __exit etm_perf_exit(void)
+void etm_perf_exit(void)
 {
 	perf_pmu_unregister(&etm_pmu);
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 3e4f2ad5e193..29d90dfeba31 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -83,6 +83,6 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 #endif /* CONFIG_CORESIGHT */
 
 int __init etm_perf_init(void);
-void __exit etm_perf_exit(void);
+void etm_perf_exit(void);
 
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
new file mode 100644
index 000000000000..417db3f92c2f
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/platform_device.h>
+
+#include "coresight-config.h"
+#include "coresight-syscfg.h"
+
+/*
+ * cscfg_ API manages configurations and features for the entire coresight
+ * infrastructure.
+ *
+ * It allows the loading of configurations and features, and loads these into
+ * coresight devices as appropriate.
+ */
+
+/* protect the cscsg_data and device */
+static DEFINE_MUTEX(cscfg_mutex);
+
+/* only one of these */
+static struct cscfg_manager *cscfg_mgr;
+
+/* load features and configuations into the lists */
+
+/* check feature list for a named feature - call with mutex locked. */
+static bool cscfg_match_list_feat(const char *name)
+{
+	struct cscfg_feature_desc *feat_desc;
+
+	list_for_each_entry(feat_desc, &cscfg_mgr->feat_desc_list, item) {
+		if (strcmp(feat_desc->name, name) == 0)
+			return true;
+	}
+	return false;
+}
+
+/* check all feat needed for cfg are in the list - call with mutex locked. */
+static int cscfg_check_feat_for_cfg(struct cscfg_config_desc *config_desc)
+{
+	int i;
+
+	for (i = 0; i < config_desc->nr_feat_refs; i++)
+		if (!cscfg_match_list_feat(config_desc->feat_ref_names[i]))
+			return -EINVAL;
+	return 0;
+}
+
+/*
+ * load feature - add to feature list.
+ */
+static int cscfg_load_feat(struct cscfg_feature_desc *feat_desc)
+{
+	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
+
+	return 0;
+}
+
+/*
+ * load config into the system - validate used features exist then add to
+ * config list.
+ */
+static int cscfg_load_config(struct cscfg_config_desc *config_desc)
+{
+	int err;
+
+	/* validate features are present */
+	err = cscfg_check_feat_for_cfg(config_desc);
+	if (err)
+		return err;
+
+	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
+	return 0;
+}
+
+/**
+ * cscfg_load_config_sets - API function to load feature and config sets.
+ *
+ * Take a 0 terminated array of feature descriptors and/or configuration
+ * descriptors and load into the system.
+ * Features are loaded first to ensure configuration dependencies can be met.
+ *
+ * @config_descs: 0 terminated array of configuration descriptors.
+ * @feat_descs:   0 terminated array of feature descriptors.
+ */
+int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
+			   struct cscfg_feature_desc **feat_descs)
+{
+	int err, i = 0;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* load features first */
+	if (feat_descs) {
+		while (feat_descs[i]) {
+			err = cscfg_load_feat(feat_descs[i]);
+			if (err) {
+				pr_err("coresight-syscfg: Failed to load feature %s\n",
+				       feat_descs[i]->name);
+				goto exit_unlock;
+			}
+			i++;
+		}
+	}
+
+	/* next any configurations to check feature dependencies */
+	i = 0;
+	if (config_descs) {
+		while (config_descs[i]) {
+			err = cscfg_load_config(config_descs[i]);
+			if (err) {
+				pr_err("coresight-syscfg: Failed to load configuration %s\n",
+				       config_descs[i]->name);
+				goto exit_unlock;
+			}
+			i++;
+		}
+	}
+
+exit_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_load_config_sets);
+
+/* Initialise system configuration management device. */
+
+struct device *cscfg_device(void)
+{
+	return cscfg_mgr ? &cscfg_mgr->dev : NULL;
+}
+
+/* Must have a release function or the kernel will complain on module unload */
+static void cscfg_dev_release(struct device *dev)
+{
+	kfree(cscfg_mgr);
+	cscfg_mgr = NULL;
+}
+
+/* a device is needed to "own" some kernel elements such as sysfs entries.  */
+static int cscfg_create_device(void)
+{
+	struct device *dev;
+	int err = -ENOMEM;
+
+	mutex_lock(&cscfg_mutex);
+	if (cscfg_mgr) {
+		err = -EINVAL;
+		goto create_dev_exit_unlock;
+	}
+
+	cscfg_mgr = kzalloc(sizeof(struct cscfg_manager), GFP_KERNEL);
+	if (!cscfg_mgr)
+		goto create_dev_exit_unlock;
+
+	/* setup the device */
+	dev = cscfg_device();
+	dev->release = cscfg_dev_release;
+	dev->init_name = "cs_system_cfg";
+
+	err = device_register(dev);
+	if (err)
+		cscfg_dev_release(dev);
+
+create_dev_exit_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+
+static void cscfg_clear_device(void)
+{
+	mutex_lock(&cscfg_mutex);
+	device_unregister(cscfg_device());
+	mutex_unlock(&cscfg_mutex);
+}
+
+/* Initialise system config management API device  */
+int __init cscfg_init(void)
+{
+	int err = 0;
+
+	err = cscfg_create_device();
+	if (err)
+		return err;
+
+	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
+	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
+	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
+
+	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
+	return 0;
+}
+
+void cscfg_exit(void)
+{
+	cscfg_clear_device();
+}
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
new file mode 100644
index 000000000000..18be9b58cd0b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Coresight system configuration driver.
+ */
+
+#ifndef CORESIGHT_SYSCFG_H
+#define CORESIGHT_SYSCFG_H
+
+#include <linux/coresight.h>
+#include <linux/device.h>
+
+#include "coresight-config.h"
+
+/**
+ * System configuration manager device.
+ *
+ * Contains lists of the loaded configurations and features, plus a list of CoreSight devices
+ * registered with the system as supporting configuration management.
+ *
+ * Need a device to 'own' some coresight system wide sysfs entries in
+ * perf events, configfs etc.
+ *
+ * @dev:		The device.
+ * @csdev_desc_list:	List of coresight devices registered with the configuration manager.
+ * @feat_desc_list:	List of feature descriptors to load into registered devices.
+ * @config_desc_list:	List of system configuration descriptors to load into registered devices.
+ */
+struct cscfg_manager {
+	struct device dev;
+	struct list_head csdev_desc_list;
+	struct list_head feat_desc_list;
+	struct list_head config_desc_list;
+};
+
+/* get reference to dev in cscfg_manager */
+struct device *cscfg_device(void);
+
+/* internal core operations for cscfg */
+int __init cscfg_init(void);
+void cscfg_exit(void);
+
+/* syscfg manager external API */
+int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
+			   struct cscfg_feature_desc **feat_descs);
+
+#endif /* CORESIGHT_SYSCFG_H */
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:14 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:14 +0100
Subject: [PATCH v6 02/10] coresight: syscfg: Add registration and feature
 loading for cs devices
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-3-mike.leach@linaro.org>

API for individual devices to register with the syscfg management
system is added.

Devices register with matching information, and any features or
configurations that match will be loaded into the device.

The feature and configuration loading is extended so that on load these
are loaded into any currently registered devices. This allows
configuration loading after devices have been registered.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |  98 +++++
 .../hwtracing/coresight/coresight-syscfg.c    | 338 +++++++++++++++++-
 .../hwtracing/coresight/coresight-syscfg.h    |  19 +
 include/linux/coresight.h                     |   5 +
 4 files changed, 459 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 21aa7464dcdc..685fb46ce893 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -139,4 +139,102 @@ struct cscfg_config_desc {
 	const u64 *presets; /* nr_presets * nr_total_params */
 };
 
+/**
+ * config register instance - part of a loaded feature.
+ *                            maps register values to csdev driver structures
+ *
+ * @reg_desc:		value to use when setting feature on device / store for
+ *			readback of volatile values.
+ * @driver_regval:	pointer to internal driver element used to set the value
+ *			in hardware.
+ */
+struct cscfg_regval_csdev {
+	struct cscfg_regval_desc reg_desc;
+	void *driver_regval;
+};
+
+/**
+ * config parameter instance - part of a loaded feature.
+ *
+ * @feat_csdev:		parent feature
+ * @reg_csdev:		register value updated by this parameter.
+ * @current_value:	current value of parameter - may be set by user via
+ *			sysfs, or modified during device operation.
+ * @val64:		true if 64 bit value
+ */
+struct cscfg_parameter_csdev {
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_regval_csdev *reg_csdev;
+	u64 current_value;
+	bool val64;
+};
+
+/**
+ * Feature instance loaded into a CoreSight device.
+ *
+ * When a feature is loaded into a specific device, then this structure holds
+ * the connections between the register / parameter values used and the
+ * internal data structures that are written when the feature is enabled.
+ *
+ * Since applying a feature modifies internal data structures in the device,
+ * then we have a reference to the device spinlock to protect access to these
+ * structures (@drv_spinlock).
+ *
+ * @feat_desc:		pointer to the static descriptor for this feature.
+ * @csdev:		parent CoreSight device instance.
+ * @node:		list entry into feature list for this device.
+ * @drv_spinlock:	device spinlock for access to driver register data.
+ * @nr_params:		number of parameters.
+ * @params_csdev:	current parameter values on this device
+ * @nr_regs:		number of registers to be programmed.
+ * @regs_csdev:		Programming details for the registers
+ */
+struct cscfg_feature_csdev {
+	const struct cscfg_feature_desc *feat_desc;
+	struct coresight_device *csdev;
+	struct list_head node;
+	spinlock_t *drv_spinlock;
+	int nr_params;
+	struct cscfg_parameter_csdev *params_csdev;
+	int nr_regs;
+	struct cscfg_regval_csdev *regs_csdev;
+};
+
+/**
+ * Configuration instance when loaded into a CoreSight device.
+ *
+ * The instance contains references to loaded features on this device that are
+ * used by the configuration.
+ *
+ * @config_desc:reference to the descriptor for this configuration
+ * @csdev:	parent coresight device for this configuration instance.
+ * @enabled:	true if configuration is enabled on this device.
+ * @node:	list entry within the coresight device
+ * @nr_feat:	Number of features on this device that are used in the
+ *		configuration.
+ * @feats_csdev:references to the device features to enable.
+ */
+struct cscfg_config_csdev {
+	const struct cscfg_config_desc *config_desc;
+	struct coresight_device *csdev;
+	bool enabled;
+	struct list_head node;
+	int nr_feat;
+	struct cscfg_feature_csdev *feats_csdev[0];
+};
+
+/**
+ * Coresight device operations.
+ *
+ * Registered coresight devices provide these operations to manage feature
+ * instances compatible with the device hardware and drivers
+ *
+ * @load_feat:	Pass a feature descriptor into the device and create the
+ *		loaded feature instance (struct cscfg_feature_csdev).
+ */
+struct cscfg_csdev_feat_ops {
+	int (*load_feat)(struct coresight_device *csdev,
+			 struct cscfg_feature_csdev *feat_csdev);
+};
+
 #endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 417db3f92c2f..e93e62c1efbb 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -25,6 +25,199 @@ static struct cscfg_manager *cscfg_mgr;
 
 /* load features and configuations into the lists */
 
+/* protect the cfg lists in the csdev instances */
+static DEFINE_MUTEX(cscfg_csdev_mutex);
+
+/* get name feature instance from a coresight device list of features */
+static struct cscfg_feature_csdev *
+cscfg_get_feat_csdev(struct coresight_device *csdev, const char *name)
+{
+	struct cscfg_feature_csdev *feat_csdev = NULL;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
+		if (strcmp(feat_csdev->feat_desc->name, name) == 0)
+			return feat_csdev;
+	}
+	return NULL;
+}
+
+/* allocate the device config instance - with max number of used features */
+static struct cscfg_config_csdev *
+cscfg_alloc_csdev_cfg(struct coresight_device *csdev, int nr_feats)
+{
+	struct cscfg_config_csdev *config_csdev = NULL;
+	struct device *dev = csdev->dev.parent;
+
+	/* this is being allocated using the devm for the coresight device */
+	config_csdev = devm_kzalloc(dev,
+				    offsetof(struct cscfg_config_csdev, feats_csdev[nr_feats]),
+				    GFP_KERNEL);
+	if (!config_csdev)
+		return NULL;
+
+	config_csdev->csdev = csdev;
+	return config_csdev;
+}
+
+/* Load a config into a device if there are any feature matches between config and device */
+static int cscfg_add_csdev_cfg(struct coresight_device *csdev,
+			       struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_config_csdev *config_csdev = NULL;
+	struct cscfg_feature_csdev *feat_csdev;
+	int i;
+
+	/* look at each required feature and see if it matches any feature on the device */
+	for (i = 0; i < config_desc->nr_feat_refs; i++) {
+		/* look for a matching name */
+		feat_csdev = cscfg_get_feat_csdev(csdev, config_desc->feat_ref_names[i]);
+		if (feat_csdev) {
+			/*
+			 * At least one feature on this device matches the config
+			 * add a config instance to the device and a reference to the feature.
+			 */
+			if (!config_csdev) {
+				config_csdev = cscfg_alloc_csdev_cfg(csdev,
+								     config_desc->nr_feat_refs);
+				if (!config_csdev)
+					return -ENOMEM;
+				config_csdev->config_desc = config_desc;
+			}
+			config_csdev->feats_csdev[config_csdev->nr_feat++] = feat_csdev;
+		}
+	}
+	/* if matched features, add config to device.*/
+	if (config_csdev) {
+		mutex_lock(&cscfg_csdev_mutex);
+		list_add(&config_csdev->node, &csdev->config_csdev_list);
+		mutex_unlock(&cscfg_csdev_mutex);
+	}
+
+	return 0;
+}
+
+/*
+ * Add the config to the set of registered devices - call with mutex locked.
+ * Iterates through devices - any device that matches one or more of the
+ * configuration features will load it, the others will ignore it.
+ */
+static int cscfg_add_cfg_to_csdevs(struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_registered_csdev *csdev_item;
+	int err;
+
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		err = cscfg_add_csdev_cfg(csdev_item->csdev, config_desc);
+		if (err)
+			return err;
+	}
+	return 0;
+}
+
+/*
+ * Allocate a feature object for load into a csdev.
+ * memory allocated using the csdev->dev object using devm managed allocator.
+ */
+static struct cscfg_feature_csdev *
+cscfg_alloc_csdev_feat(struct coresight_device *csdev, struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_feature_csdev *feat_csdev = NULL;
+	struct device *dev = csdev->dev.parent;
+	int i;
+
+	feat_csdev = devm_kzalloc(dev, sizeof(struct cscfg_feature_csdev), GFP_KERNEL);
+	if (!feat_csdev)
+		return NULL;
+
+	/* parameters are optional - could be 0 */
+	feat_csdev->nr_params = feat_desc->nr_params;
+
+	/*
+	 * if we need parameters, zero alloc the space here, the load routine in
+	 * the csdev device driver will fill out some information according to
+	 * feature descriptor.
+	 */
+	if (feat_csdev->nr_params) {
+		feat_csdev->params_csdev = devm_kcalloc(dev, feat_csdev->nr_params,
+							sizeof(struct cscfg_parameter_csdev),
+							GFP_KERNEL);
+		if (!feat_csdev->params_csdev)
+			return NULL;
+
+		/*
+		 * fill in the feature reference in the param - other fields
+		 * handled by loader in csdev.
+		 */
+		for (i = 0; i < feat_csdev->nr_params; i++)
+			feat_csdev->params_csdev[i].feat_csdev = feat_csdev;
+	}
+
+	/*
+	 * Always have registers to program - again the load routine in csdev device
+	 * will fill out according to feature descriptor and device requirements.
+	 */
+	feat_csdev->nr_regs = feat_desc->nr_regs;
+	feat_csdev->regs_csdev = devm_kcalloc(dev, feat_csdev->nr_regs,
+					      sizeof(struct cscfg_regval_csdev),
+					      GFP_KERNEL);
+	if (!feat_csdev->regs_csdev)
+		return NULL;
+
+	/* load the feature default values */
+	feat_csdev->feat_desc = feat_desc;
+	feat_csdev->csdev = csdev;
+
+	return feat_csdev;
+}
+
+/* load one feature into one coresight device */
+static int cscfg_load_feat_csdev(struct coresight_device *csdev,
+				 struct cscfg_feature_desc *feat_desc,
+				 struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+	int err;
+
+	if (!ops->load_feat)
+		return -EINVAL;
+
+	feat_csdev = cscfg_alloc_csdev_feat(csdev, feat_desc);
+	if (!feat_csdev)
+		return -ENOMEM;
+
+	/* load the feature into the device */
+	err = ops->load_feat(csdev, feat_csdev);
+	if (err)
+		return err;
+
+	/* add to internal csdev feature list */
+	mutex_lock(&cscfg_csdev_mutex);
+	list_add(&feat_csdev->node, &csdev->feature_csdev_list);
+	mutex_unlock(&cscfg_csdev_mutex);
+
+	return 0;
+}
+
+/*
+ * Add feature to any matching devices - call with mutex locked.
+ * Iterates through devices - any device that matches the feature will be
+ * called to load it.
+ */
+static int cscfg_add_feat_to_csdevs(struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_registered_csdev *csdev_item;
+	int err;
+
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		if (csdev_item->match_flags & feat_desc->match_flags) {
+			err = cscfg_load_feat_csdev(csdev_item->csdev, feat_desc, &csdev_item->ops);
+			if (err)
+				return err;
+		}
+	}
+	return 0;
+}
+
 /* check feature list for a named feature - call with mutex locked. */
 static bool cscfg_match_list_feat(const char *name)
 {
@@ -53,8 +246,14 @@ static int cscfg_check_feat_for_cfg(struct cscfg_config_desc *config_desc)
  */
 static int cscfg_load_feat(struct cscfg_feature_desc *feat_desc)
 {
-	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
+	int err;
 
+	/* add feature to any matching registered devices */
+	err = cscfg_add_feat_to_csdevs(feat_desc);
+	if (err)
+		return err;
+
+	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
 	return 0;
 }
 
@@ -71,6 +270,11 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	if (err)
 		return err;
 
+	/* add config to any matching registered device */
+	err = cscfg_add_cfg_to_csdevs(config_desc);
+	if (err)
+		return err;
+
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
 	return 0;
 }
@@ -125,6 +329,138 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 }
 EXPORT_SYMBOL_GPL(cscfg_load_config_sets);
 
+/* Handle coresight device registration and add configs and features to devices */
+
+/* iterate through config lists and load matching configs to device */
+static int cscfg_add_cfgs_csdev(struct coresight_device *csdev)
+{
+	struct cscfg_config_desc *config_desc;
+	int err = 0;
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		err = cscfg_add_csdev_cfg(csdev, config_desc);
+		if (err)
+			break;
+	}
+	return err;
+}
+
+/* iterate through feature lists and load matching features to device */
+static int cscfg_add_feats_csdev(struct coresight_device *csdev,
+				 u32 match_flags,
+				 struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_feature_desc *feat_desc;
+	int err = 0;
+
+	if (!ops->load_feat)
+		return -EINVAL;
+
+	list_for_each_entry(feat_desc, &cscfg_mgr->feat_desc_list, item) {
+		if (feat_desc->match_flags & match_flags) {
+			err = cscfg_load_feat_csdev(csdev, feat_desc, ops);
+			if (err)
+				break;
+		}
+	}
+	return err;
+}
+
+/* Add coresight device to list and copy its matching info */
+static int cscfg_list_add_csdev(struct coresight_device *csdev,
+				u32 match_flags,
+				struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_registered_csdev *csdev_item;
+
+	/* allocate the list entry structure */
+	csdev_item = kzalloc(sizeof(struct cscfg_registered_csdev), GFP_KERNEL);
+	if (!csdev_item)
+		return -ENOMEM;
+
+	csdev_item->csdev = csdev;
+	csdev_item->match_flags = match_flags;
+	csdev_item->ops.load_feat = ops->load_feat;
+	list_add(&csdev_item->item, &cscfg_mgr->csdev_desc_list);
+
+	INIT_LIST_HEAD(&csdev->feature_csdev_list);
+	INIT_LIST_HEAD(&csdev->config_csdev_list);
+
+	return 0;
+}
+
+/* remove a coresight device from the list and free data */
+static void cscfg_list_remove_csdev(struct coresight_device *csdev)
+{
+	struct cscfg_registered_csdev *csdev_item, *tmp;
+
+	list_for_each_entry_safe(csdev_item, tmp, &cscfg_mgr->csdev_desc_list, item) {
+		if (csdev_item->csdev == csdev) {
+			list_del(&csdev_item->item);
+			kfree(csdev_item);
+			break;
+		}
+	}
+}
+
+/**
+ * cscfg_register_csdev - register a coresight device with the syscfg manager.
+ *
+ * Registers the coresight device with the system. @match_flags used to check
+ * if the device is a match for registered features. Any currently registered
+ * configurations and features that match the device will be loaded onto it.
+ *
+ * @csdev:		The coresight device to register.
+ * @match_flags:	Matching information to load features.
+ * @ops:		Standard operations supported by the device.
+ */
+int cscfg_register_csdev(struct coresight_device *csdev,
+			 u32 match_flags,
+			 struct cscfg_csdev_feat_ops *ops)
+{
+	int ret = 0;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* add device to list of registered devices  */
+	ret = cscfg_list_add_csdev(csdev, match_flags, ops);
+	if (ret)
+		goto reg_csdev_unlock;
+
+	/* now load any registered features and configs matching the device. */
+	ret = cscfg_add_feats_csdev(csdev, match_flags, ops);
+	if (ret) {
+		cscfg_list_remove_csdev(csdev);
+		goto reg_csdev_unlock;
+	}
+
+	ret = cscfg_add_cfgs_csdev(csdev);
+	if (ret) {
+		cscfg_list_remove_csdev(csdev);
+		goto reg_csdev_unlock;
+	}
+
+	pr_info("CSCFG registered %s", dev_name(&csdev->dev));
+
+reg_csdev_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cscfg_register_csdev);
+
+/**
+ * cscfg_unregister_csdev - remove coresight device from syscfg manager.
+ *
+ * @csdev: Device to remove.
+ */
+void cscfg_unregister_csdev(struct coresight_device *csdev)
+{
+	mutex_lock(&cscfg_mutex);
+	cscfg_list_remove_csdev(csdev);
+	mutex_unlock(&cscfg_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_unregister_csdev);
+
 /* Initialise system configuration management device. */
 
 struct device *cscfg_device(void)
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 18be9b58cd0b..5bcae3b374c6 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -35,6 +35,22 @@ struct cscfg_manager {
 /* get reference to dev in cscfg_manager */
 struct device *cscfg_device(void);
 
+/**
+ * List entry for Coresight devices that are registered as supporting complex
+ * config operations.
+ *
+ * @csdev:	 The registered device.
+ * @match_flags: The matching type information for adding features.
+ * @ops:	 Operations supported by the registered device.
+ * @item:	 list entry.
+ */
+struct cscfg_registered_csdev {
+	struct coresight_device *csdev;
+	u32 match_flags;
+	struct cscfg_csdev_feat_ops ops;
+	struct list_head item;
+};
+
 /* internal core operations for cscfg */
 int __init cscfg_init(void);
 void cscfg_exit(void);
@@ -42,5 +58,8 @@ void cscfg_exit(void);
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
 			   struct cscfg_feature_desc **feat_descs);
+int cscfg_register_csdev(struct coresight_device *csdev, u32 match_flags,
+			 struct cscfg_csdev_feat_ops *ops);
+void cscfg_unregister_csdev(struct coresight_device *csdev);
 
 #endif /* CORESIGHT_SYSCFG_H */
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 85008a65e21f..6fb516e1b22e 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -220,6 +220,8 @@ struct coresight_sysfs_link {
  * @nr_links:   number of sysfs links created to other components from this
  *		device. These will appear in the "connections" group.
  * @has_conns_grp: Have added a "connections" group for sysfs links.
+ * @feature_csdev_list: List of complex feature programming added to the device.
+ * @config_csdev_list:  List of system configurations added to the device.
  */
 struct coresight_device {
 	struct coresight_platform_data *pdata;
@@ -241,6 +243,9 @@ struct coresight_device {
 	int nr_links;
 	bool has_conns_grp;
 	bool ect_enabled; /* true only if associated ect device is enabled */
+	/* system configuration and feature lists */
+	struct list_head feature_csdev_list;
+	struct list_head config_csdev_list;
 };
 
 /*
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:20 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:20 +0100
Subject: [PATCH v6 08/10] coresight: config: Add preloaded configurations
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-9-mike.leach@linaro.org>

Preload set of configurations.

This patch creates a small set of preloaded configurations and features
that are available immediately after coresight has been initialised.

The current set provides a strobing feature for ETMv4, that creates a
periodic sampling of trace by switching trace generation on and off
using counters in the ETM.

A configuration called "autofdo" is also provided that uses the 'strobing'
feature and provides a couple of preset values, selectable on the perf
command line.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../hwtracing/coresight/coresight-cfg-afdo.c  | 147 ++++++++++++++++++
 .../coresight/coresight-cfg-preload.c         |  27 ++++
 .../coresight/coresight-cfg-preload.h         |  11 ++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
 .../hwtracing/coresight/coresight-syscfg.c    |   9 ++
 .../hwtracing/coresight/coresight-syscfg.h    |   1 +
 7 files changed, 212 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 9420d33b23ac..ad44f0fe3069 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,8 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o coresight-syscfg.o coresight-config.o
+		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
+		coresight-cfg-preload.o coresight-cfg-afdo.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-cfg-afdo.c b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
new file mode 100644
index 000000000000..d6faf27b8326
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-config.h"
+#include "coresight-etm4x-cfg.h"
+
+/* preload configurations and features */
+
+/* preload in features for ETMv4 */
+
+/* strobe feature */
+static struct cscfg_parameter_desc strobe_params[] = {
+	{
+		.name = "window",
+		.value = 5000,
+	},
+	{
+		.name = "period",
+		.value = 10000,
+	},
+};
+
+static struct cscfg_regval_desc strobe_regs[] = {
+	/* resource selectors */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCRSCTLRn(2),
+		.hw_info = ETM4_CFG_RES_SEL,
+		.val32 = 0x20001,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCRSCTLRn(3),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x20002,
+	},
+	/* strobe window counter 0 - reload from param 0 */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
+		.offset = TRCCNTVRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
+		.offset = TRCCNTRLDVRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCCNTCTLRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0x10001,
+	},
+	/* strobe period counter 1 - reload from param 1 */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
+		.offset = TRCCNTVRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
+		.offset = TRCCNTRLDVRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 1,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCCNTCTLRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0x8102,
+	},
+	/* sequencer */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCSEQEVRn(0),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x0081,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCSEQEVRn(1),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x0000,
+	},
+	/* view-inst */
+	{
+		.type = CS_CFG_REG_TYPE_STD | CS_CFG_REG_TYPE_VAL_MASK,
+		.offset = TRCVICTLR,
+		.val32 = 0x0003,
+		.mask32 = 0x0003,
+	},
+	/* end of regs */
+};
+
+struct cscfg_feature_desc strobe = {
+	.name = "strobing",
+	.description = "Generate periodic trace capture windows.\n"
+		       "parameter \'window\': a number of CPU cycles (W)\n"
+		       "parameter \'period\': trace enabled for W cycles every period x W cycles\n",
+	.match_flags = CS_CFG_MATCH_CLASS_SRC_ETM4,
+	.nr_params = ARRAY_SIZE(strobe_params),
+	.params_desc = strobe_params,
+	.nr_regs = ARRAY_SIZE(strobe_regs),
+	.regs_desc = strobe_regs,
+};
+
+/* create an autofdo configuration */
+
+/* we will provide 9 sets of preset parameter values */
+#define AFDO_NR_PRESETS	9
+/* the total number of parameters in used features */
+#define AFDO_NR_PARAMS	ARRAY_SIZE(strobe_params)
+
+static const char *afdo_ref_names[] = {
+	"strobing",
+};
+
+/*
+ * set of presets leaves strobing window constant while varying period to allow
+ * experimentation with mark / space ratios for various workloads
+ */
+static u64 afdo_presets[AFDO_NR_PRESETS][AFDO_NR_PARAMS] = {
+	{ 5000, 2 },
+	{ 5000, 4 },
+	{ 5000, 8 },
+	{ 5000, 16 },
+	{ 5000, 64 },
+	{ 5000, 128 },
+	{ 5000, 512 },
+	{ 5000, 1024 },
+	{ 5000, 4096 },
+};
+
+struct cscfg_config_desc afdo = {
+	.name = "autofdo",
+	.description = "Setup ETMs with strobing for autofdo\n"
+	"Supplied presets allow experimentation with mark-space ratio for various loads\n",
+	.nr_feat_refs = ARRAY_SIZE(afdo_ref_names),
+	.feat_ref_names = afdo_ref_names,
+	.nr_presets = AFDO_NR_PRESETS,
+	.nr_total_params = AFDO_NR_PARAMS,
+	.presets = &afdo_presets[0][0],
+};
diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.c b/drivers/hwtracing/coresight/coresight-cfg-preload.c
new file mode 100644
index 000000000000..9ed0f029a335
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-preload.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-cfg-preload.h"
+#include "coresight-config.h"
+#include "coresight-syscfg.h"
+
+/* Basic features and configurations pre-loaded on initialisation */
+
+static struct cscfg_feature_desc *preload_feats[] = {
+	&strobe,
+	0
+};
+
+static struct cscfg_config_desc *preload_cfgs[] = {
+	&afdo,
+	0
+};
+
+/* preload called on initialisation */
+int cscfg_preload(void)
+{
+	return cscfg_load_config_sets(preload_cfgs, preload_feats);
+}
diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.h b/drivers/hwtracing/coresight/coresight-cfg-preload.h
new file mode 100644
index 000000000000..fc4ac7faa93d
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-preload.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+/* declare preloaded configurations and features */
+
+/* from coresight-cfg-afdo.c */
+extern struct cscfg_feature_desc strobe;
+extern struct cscfg_config_desc afdo;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
index a204ad9a4792..32dab34c1dac 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
@@ -9,6 +9,21 @@
 #include "coresight-config.h"
 #include "coresight-etm4x.h"
 
+/* ETMv4 specific config defines */
+
+/* resource IDs */
+
+#define ETM4_CFG_RES_CTR	0x001
+#define ETM4_CFG_RES_CMP	0x002
+#define ETM4_CFG_RES_CMP_PAIR0	0x003
+#define ETM4_CFG_RES_CMP_PAIR1	0x004
+#define ETM4_CFG_RES_SEL	0x005
+#define ETM4_CFG_RES_SEL_PAIR0	0x006
+#define ETM4_CFG_RES_SEL_PAIR1	0x007
+#define ETM4_CFG_RES_SEQ	0x008
+#define ETM4_CFG_RES_TS		0x009
+#define ETM4_CFG_RES_MASK	0x00F
+
 /* ETMv4 specific config functions */
 int etm4_cscfg_register(struct coresight_device *csdev);
 
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index b234e45c153f..41f742190639 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -709,8 +709,17 @@ int __init cscfg_init(void)
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
 	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
 
+	/* preload built-in configurations */
+	err = cscfg_preload();
+	if (err)
+		goto exit_err;
+
 	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
 	return 0;
+
+exit_err:
+	cscfg_clear_device();
+	return err;
 }
 
 void cscfg_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index a52775890670..7bb8c8e497ba 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -56,6 +56,7 @@ struct cscfg_registered_csdev {
 /* internal core operations for cscfg */
 int __init cscfg_init(void);
 void cscfg_exit(void);
+int cscfg_preload(void);
 
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:19 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:19 +0100
Subject: [PATCH v6 07/10] coresight: etm4x: Add complex configuration handlers
 to etmv4
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-8-mike.leach@linaro.org>

Adds in handlers to allow the ETMv4 to use the complex configuration
support. Features and configurations can be loaded and selected in the
device.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
 .../coresight/coresight-etm4x-core.c          |  38 +++-
 .../coresight/coresight-etm4x-sysfs.c         |   3 +
 5 files changed, 238 insertions(+), 3 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 63ecfc3cf66d..9420d33b23ac 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
 coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
 		     coresight-etm3x-sysfs.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
-coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
+coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
+			coresight-etm4x-cfg.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
 obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
 obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
new file mode 100644
index 000000000000..d2ea903231b2
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-etm4x.h"
+#include "coresight-etm4x-cfg.h"
+#include "coresight-priv.h"
+#include "coresight-syscfg.h"
+
+/* defines to associate register IDs with driver data locations */
+#define CHECKREG(cval, elem) \
+	{ \
+		if (offset == cval) { \
+			reg_csdev->driver_regval = &drvcfg->elem; \
+			err = 0; \
+			break; \
+		} \
+	}
+
+#define CHECKREGIDX(cval, elem, off_idx, mask)	\
+	{ \
+		if (mask == cval) { \
+			reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
+			err = 0; \
+			break; \
+		} \
+	}
+
+/**
+ * etm4_cfg_map_reg_offset - validate and map the register offset into a
+ *			     location in the driver config struct.
+ *
+ * Limits the number of registers that can be accessed and programmed in
+ * features, to those which are used to control the trace capture parameters.
+ *
+ * Omits or limits access to those which the driver must use exclusively.
+ *
+ * Invalid offsets will result in fail code return and feature load failure.
+ *
+ * @drvdata:	driver data to map into.
+ * @reg:	register to map.
+ * @offset:	device offset for the register
+ */
+static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
+				   struct cscfg_regval_csdev *reg_csdev, u32 offset)
+{
+	int err = -EINVAL, idx;
+	struct etmv4_config *drvcfg = &drvdata->config;
+	u32 off_mask;
+
+	if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
+	    ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
+	    ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
+		do {
+			CHECKREG(TRCEVENTCTL0R, eventctrl0);
+			CHECKREG(TRCEVENTCTL1R, eventctrl1);
+			CHECKREG(TRCSTALLCTLR, stall_ctrl);
+			CHECKREG(TRCTSCTLR, ts_ctrl);
+			CHECKREG(TRCSYNCPR, syncfreq);
+			CHECKREG(TRCCCCTLR, ccctlr);
+			CHECKREG(TRCBBCTLR, bb_ctrl);
+			CHECKREG(TRCVICTLR, vinst_ctrl);
+			CHECKREG(TRCVIIECTLR, viiectlr);
+			CHECKREG(TRCVISSCTLR, vissctlr);
+			CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
+			CHECKREG(TRCSEQRSTEVR, seq_rst);
+			CHECKREG(TRCSEQSTR, seq_state);
+			CHECKREG(TRCEXTINSELR, ext_inp);
+			CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
+			CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
+			CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
+			CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
+		} while (0);
+	} else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
+		/* sequencer state control registers */
+		idx = (offset & GENMASK(3, 0)) / 4;
+		if (idx < ETM_MAX_SEQ_STATES) {
+			reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
+			err = 0;
+		}
+	} else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
+		/* 32 bit, 8 off indexed register sets */
+		idx = (offset & GENMASK(4, 0)) / 4;
+		off_mask =  (offset & GENMASK(11, 5));
+		do {
+			CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
+			CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
+			CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
+		/* 64 bit, 8 off indexed register sets */
+		idx = (offset & GENMASK(5, 0)) / 8;
+		off_mask = (offset & GENMASK(11, 6));
+		do {
+			CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
+			CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCRSCTLRn(2)) &&
+		   (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
+		/* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
+		idx = (offset & GENMASK(6, 0)) / 4;
+		if (idx < ETM_MAX_RES_SEL) {
+			reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
+			err = 0;
+		}
+	} else if ((offset >= TRCACVRn(0)) &&
+		   (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
+		/* 64 bit addr cmp regs, 16 off */
+		idx = (offset & GENMASK(6, 0)) / 8;
+		off_mask = offset & GENMASK(11, 7);
+		do {
+			CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
+			CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCCNTRLDVRn(0)) &&
+		   (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
+		/* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
+		idx = (offset &  GENMASK(3, 0)) / 4;
+		off_mask = offset &  GENMASK(11, 4);
+		do {
+			CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
+			CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
+			CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
+		} while (0);
+	}
+	return err;
+}
+
+/**
+ * etm4_cfg_load_feature - load a feature into a device instance.
+ *
+ * @csdev:	An ETMv4 CoreSight device.
+ * @feat:	The feature to be loaded.
+ *
+ * The function will load a feature instance into the device, checking that
+ * the register definitions are valid for the device.
+ *
+ * Parameter and register definitions will be converted into internal
+ * structures that are used to set the values in the driver when the
+ * feature is enabled for the device.
+ *
+ * The feature spinlock pointer is initialised to the same spinlock
+ * that the driver uses to protect the internal register values.
+ */
+static int etm4_cfg_load_feature(struct coresight_device *csdev,
+				 struct cscfg_feature_csdev *feat_csdev)
+{
+	struct device *dev = csdev->dev.parent;
+	struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
+	const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
+	u32 offset;
+	int i = 0, err = 0;
+
+	/*
+	 * essential we set the device spinlock - this is used in the generic
+	 * programming routines when copying values into the drvdata structures
+	 * via the pointers setup in etm4_cfg_map_reg_offset().
+	 */
+	feat_csdev->drv_spinlock = &drvdata->spinlock;
+
+	/* process the register descriptions */
+	for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
+		offset = feat_desc->regs_desc[i].offset;
+		err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
+	}
+	return err;
+}
+
+/* match information when loading configurations */
+#define CS_CFG_ETM4_MATCH_FLAGS	(CS_CFG_MATCH_CLASS_SRC_ALL | \
+				 CS_CFG_MATCH_CLASS_SRC_ETM4)
+
+int etm4_cscfg_register(struct coresight_device *csdev)
+{
+	struct cscfg_csdev_feat_ops ops;
+
+	ops.load_feat = &etm4_cfg_load_feature;
+
+	return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
+}
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
new file mode 100644
index 000000000000..a204ad9a4792
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _CORESIGHT_ETM4X_CFG_H
+#define _CORESIGHT_ETM4X_CFG_H
+
+#include "coresight-config.h"
+#include "coresight-etm4x.h"
+
+/* ETMv4 specific config functions */
+int etm4_cscfg_register(struct coresight_device *csdev);
+
+#endif /* CORESIGHT_ETM4X_CFG_H */
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index efb84ced83dd..94f10910d20d 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -39,6 +39,8 @@
 
 #include "coresight-etm4x.h"
 #include "coresight-etm-perf.h"
+#include "coresight-etm4x-cfg.h"
+#include "coresight-syscfg.h"
 
 static int boot_enable;
 module_param(boot_enable, int, 0444);
@@ -561,12 +563,15 @@ static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata)
 	return ret;
 }
 
-static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
+static int etm4_parse_event_config(struct coresight_device *csdev,
 				   struct perf_event *event)
 {
 	int ret = 0;
+	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	struct etmv4_config *config = &drvdata->config;
 	struct perf_event_attr *attr = &event->attr;
+	unsigned long cfg_hash;
+	int preset;
 
 	if (!attr) {
 		ret = -EINVAL;
@@ -637,6 +642,20 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
 		/* bit[12], Return stack enable bit */
 		config->cfg |= BIT(12);
 
+	/*
+	 * Set any selected configuration and preset.
+	 *
+	 * This extracts the values of PMU_FORMAT_ATTR(configid) and PMU_FORMAT_ATTR(preset)
+	 * in the perf attributes defined in coresight-etm-perf.c.
+	 * configid uses bits 63:32 of attr->config2, preset uses bits 3:0 of attr->config.
+	 * A zero configid means no configuration active, preset = 0 means no preset selected.
+	 */
+	if (attr->config2 & GENMASK_ULL(63, 32)) {
+		cfg_hash = (u32)(attr->config2 >> 32);
+		preset = attr->config & 0xF;
+		ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
+	}
+
 out:
 	return ret;
 }
@@ -653,7 +672,7 @@ static int etm4_enable_perf(struct coresight_device *csdev,
 	}
 
 	/* Configure the tracer based on the session's specifics */
-	ret = etm4_parse_event_config(drvdata, event);
+	ret = etm4_parse_event_config(csdev, event);
 	if (ret)
 		goto out;
 	/* And enable it */
@@ -799,11 +818,18 @@ static int etm4_disable_perf(struct coresight_device *csdev,
 	u32 control;
 	struct etm_filters *filters = event->hw.addr_filters;
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	struct perf_event_attr *attr = &event->attr;
 
 	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
 		return -EINVAL;
 
 	etm4_disable_hw(drvdata);
+	/*
+	 * The config_id occupies bits 63:32 of the config2 perf event attr
+	 * field. If this is non-zero then we will have enabled a config.
+	 */
+	if (attr->config2 & GENMASK_ULL(63, 32))
+		cscfg_csdev_disable_active_config(csdev);
 
 	/*
 	 * Check if the start/stop logic was active when the unit was stopped.
@@ -1944,6 +1970,13 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 		return ret;
 	}
 
+	/* register with config infrastructure & load any current features */
+	ret = etm4_cscfg_register(drvdata->csdev);
+	if (ret) {
+		coresight_unregister(drvdata->csdev);
+		return ret;
+	}
+
 	etmdrvdata[drvdata->cpu] = drvdata;
 
 	dev_info(&drvdata->csdev->dev, "CPU%d: %s v%d.%d initialized\n",
@@ -2030,6 +2063,7 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
 
 	cpus_read_unlock();
 
+	cscfg_unregister_csdev(drvdata->csdev);
 	coresight_unregister(drvdata->csdev);
 
 	return 0;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index 007bad9e7ad8..a0640fa5c55b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -9,6 +9,7 @@
 #include <linux/sysfs.h>
 #include "coresight-etm4x.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static int etm4_set_mode_exclude(struct etmv4_drvdata *drvdata, bool exclude)
 {
@@ -269,6 +270,8 @@ static ssize_t reset_store(struct device *dev,
 
 	spin_unlock(&drvdata->spinlock);
 
+	cscfg_csdev_reset_feats(to_coresight_device(dev));
+
 	return size;
 }
 static DEVICE_ATTR_WO(reset);
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:21 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:21 +0100
Subject: [PATCH v6 09/10] coresight: syscfg: Add initial configfs support
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-10-mike.leach@linaro.org>

Adds configfs subsystem and attributes to the configuration manager
to enable the listing of loaded configurations and features.

The default values of feature parameters can be accessed and altered
from these attributes to affect all installed devices using the feature.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../coresight/coresight-syscfg-configfs.c     | 396 ++++++++++++++++++
 .../coresight/coresight-syscfg-configfs.h     |  45 ++
 .../hwtracing/coresight/coresight-syscfg.c    |  76 ++++
 .../hwtracing/coresight/coresight-syscfg.h    |   7 +
 5 files changed, 526 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index ad44f0fe3069..b6c4a48140ec 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -5,7 +5,8 @@
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
 		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
-		coresight-cfg-preload.o coresight-cfg-afdo.o
+		coresight-cfg-preload.o coresight-cfg-afdo.o \
+		coresight-syscfg-configfs.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
new file mode 100644
index 000000000000..c547816b9000
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/configfs.h>
+
+#include "coresight-syscfg-configfs.h"
+
+/* create a default ci_type. */
+static inline struct config_item_type *cscfg_create_ci_type(void)
+{
+	struct config_item_type *ci_type;
+
+	ci_type = devm_kzalloc(cscfg_device(), sizeof(*ci_type), GFP_KERNEL);
+	if (ci_type)
+		ci_type->ct_owner = THIS_MODULE;
+
+	return ci_type;
+}
+
+/* configurations sub-group */
+
+/* attributes for the config view group */
+static ssize_t cscfg_cfg_description_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
+							 struct cscfg_fs_config, group);
+
+	return scnprintf(page, PAGE_SIZE, "%s", fs_config->config_desc->description);
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, description);
+
+static ssize_t cscfg_cfg_feature_refs_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
+							 struct cscfg_fs_config, group);
+	const struct cscfg_config_desc *config_desc = fs_config->config_desc;
+	ssize_t ch_used = 0;
+	int i;
+
+	for (i = 0; i < config_desc->nr_feat_refs; i++)
+		ch_used += scnprintf(page + ch_used, PAGE_SIZE - ch_used,
+				     "%s\n", config_desc->feat_ref_names[i]);
+	return ch_used;
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, feature_refs);
+
+/* list preset values in order of features and params */
+static ssize_t cscfg_cfg_values_show(struct config_item *item, char *page)
+{
+	const struct cscfg_feature_desc *feat_desc;
+	const struct cscfg_config_desc *config_desc;
+	struct cscfg_fs_preset *fs_preset;
+	int i, j, val_idx, preset_idx;
+	ssize_t used = 0;
+
+	fs_preset = container_of(to_config_group(item), struct cscfg_fs_preset, group);
+	config_desc = fs_preset->config_desc;
+
+	if (!config_desc->nr_presets)
+		return 0;
+
+	preset_idx = fs_preset->preset_num - 1;
+
+	/* start index on the correct array line */
+	val_idx = config_desc->nr_total_params * preset_idx;
+
+	/*
+	 * A set of presets is the sum of all params in used features,
+	 * in order of declaration of features and params in the features
+	 */
+	for (i = 0; i < config_desc->nr_feat_refs; i++) {
+		feat_desc = cscfg_get_named_feat_desc(config_desc->feat_ref_names[i]);
+		for (j = 0; j < feat_desc->nr_params; j++) {
+			used += scnprintf(page + used, PAGE_SIZE - used,
+					  "%s.%s = 0x%llx ",
+					  feat_desc->name,
+					  feat_desc->params_desc[j].name,
+					  config_desc->presets[val_idx++]);
+		}
+	}
+	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
+
+	return used;
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, values);
+
+static struct configfs_attribute *cscfg_config_view_attrs[] = {
+	&cscfg_cfg_attr_description,
+	&cscfg_cfg_attr_feature_refs,
+	NULL,
+};
+
+static struct config_item_type cscfg_config_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_config_view_attrs,
+};
+
+static struct configfs_attribute *cscfg_config_preset_attrs[] = {
+	&cscfg_cfg_attr_values,
+	NULL,
+};
+
+static struct config_item_type cscfg_config_preset_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_config_preset_attrs,
+};
+
+static int cscfg_add_preset_groups(struct cscfg_fs_config *cfg_view)
+{
+	int preset_num;
+	struct cscfg_fs_preset *cfg_fs_preset;
+	struct cscfg_config_desc *config_desc = cfg_view->config_desc;
+	char name[CONFIGFS_ITEM_NAME_LEN];
+
+	if (!config_desc->nr_presets)
+		return 0;
+
+	for (preset_num = 1; preset_num <= config_desc->nr_presets; preset_num++) {
+		cfg_fs_preset = devm_kzalloc(cscfg_device(),
+					     sizeof(struct cscfg_fs_preset), GFP_KERNEL);
+
+		if (!cfg_fs_preset)
+			return -ENOMEM;
+
+		snprintf(name, CONFIGFS_ITEM_NAME_LEN, "preset%d", preset_num);
+		cfg_fs_preset->preset_num = preset_num;
+		cfg_fs_preset->config_desc = cfg_view->config_desc;
+		config_group_init_type_name(&cfg_fs_preset->group, name,
+					    &cscfg_config_preset_type);
+		configfs_add_default_group(&cfg_fs_preset->group, &cfg_view->group);
+	}
+	return 0;
+}
+
+static struct config_group *cscfg_create_config_group(struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_fs_config *cfg_view;
+	struct device *dev = cscfg_device();
+	int err;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	cfg_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_config), GFP_KERNEL);
+	if (!cfg_view)
+		return ERR_PTR(-ENOMEM);
+
+	cfg_view->config_desc = config_desc;
+	config_group_init_type_name(&cfg_view->group, config_desc->name, &cscfg_config_view_type);
+
+	/* add in a preset<n> dir for each preset */
+	err = cscfg_add_preset_groups(cfg_view);
+	if (err)
+		return ERR_PTR(err);
+
+	return &cfg_view->group;
+}
+
+/* attributes for features view */
+
+static ssize_t cscfg_feat_description_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+
+	return scnprintf(page, PAGE_SIZE, "%s", fs_feat->feat_desc->description);
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, description);
+
+static ssize_t cscfg_feat_matches_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+	u32 match_flags = fs_feat->feat_desc->match_flags;
+	int used = 0;
+
+	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL)
+		used = scnprintf(page, PAGE_SIZE, "SRC_ALL ");
+
+	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4)
+		used += scnprintf(page + used, PAGE_SIZE - used, "SRC_ETMV4 ");
+
+	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
+	return used;
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, matches);
+
+static ssize_t cscfg_feat_nr_params_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+
+	return scnprintf(page, PAGE_SIZE, "%d\n", fs_feat->feat_desc->nr_params);
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, nr_params);
+
+/* base feature desc attrib structures */
+static struct configfs_attribute *cscfg_feature_view_attrs[] = {
+	&cscfg_feat_attr_description,
+	&cscfg_feat_attr_matches,
+	&cscfg_feat_attr_nr_params,
+	NULL,
+};
+
+static struct config_item_type cscfg_feature_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_feature_view_attrs,
+};
+
+static ssize_t cscfg_param_value_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
+							 struct cscfg_fs_param, group);
+	u64 value = param_item->feat_desc->params_desc[param_item->param_idx].value;
+
+	return scnprintf(page, PAGE_SIZE, "0x%llx\n", value);
+}
+
+static ssize_t cscfg_param_value_store(struct config_item *item,
+				       const char *page, size_t size)
+{
+	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
+							 struct cscfg_fs_param, group);
+	struct cscfg_feature_desc *feat_desc = param_item->feat_desc;
+	int param_idx = param_item->param_idx;
+	u64 value;
+	int err;
+
+	err = kstrtoull(page, 0, &value);
+	if (!err)
+		err = cscfg_update_feat_param_val(feat_desc, param_idx, value);
+
+	return err ? err : size;
+}
+CONFIGFS_ATTR(cscfg_param_, value);
+
+static struct configfs_attribute *cscfg_param_view_attrs[] = {
+	&cscfg_param_attr_value,
+	NULL,
+};
+
+static struct config_item_type cscfg_param_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_param_view_attrs,
+};
+
+/*
+ * configfs has far less functionality provided to add attributes dynamically than sysfs,
+ * and the show and store fns pass the enclosing config_item so the actual attribute cannot
+ * be determined. Therefore we add each item as a group directory, with a value attribute.
+ */
+static int cscfg_create_params_group_items(struct cscfg_feature_desc *feat_desc,
+					   struct config_group *params_group)
+{
+	struct device *dev = cscfg_device();
+	struct cscfg_fs_param *param_item;
+	int i;
+
+	/* parameter items - as groups with default_value attribute */
+	for (i = 0; i < feat_desc->nr_params; i++) {
+		param_item = devm_kzalloc(dev, sizeof(struct cscfg_fs_param), GFP_KERNEL);
+		if (!param_item)
+			return -ENOMEM;
+		param_item->feat_desc = feat_desc;
+		param_item->param_idx = i;
+		config_group_init_type_name(&param_item->group,
+					    feat_desc->params_desc[i].name,
+					    &cscfg_param_view_type);
+		configfs_add_default_group(&param_item->group, params_group);
+	}
+	return 0;
+}
+
+static struct config_group *cscfg_create_feature_group(struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_fs_feature *feat_view;
+	struct config_item_type *params_group_type;
+	struct config_group *params_group = NULL;
+	struct device *dev = cscfg_device();
+	int item_err;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	feat_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_feature), GFP_KERNEL);
+	if (!feat_view)
+		return ERR_PTR(-ENOMEM);
+
+	if (feat_desc->nr_params) {
+		params_group = devm_kzalloc(dev, sizeof(struct config_group), GFP_KERNEL);
+		if (!params_group)
+			return ERR_PTR(-ENOMEM);
+
+		params_group_type = cscfg_create_ci_type();
+		if (!params_group_type)
+			return ERR_PTR(-ENOMEM);
+	}
+
+	feat_view->feat_desc = feat_desc;
+	config_group_init_type_name(&feat_view->group,
+				    feat_desc->name,
+				    &cscfg_feature_view_type);
+	if (params_group) {
+		config_group_init_type_name(params_group, "params", params_group_type);
+		configfs_add_default_group(params_group, &feat_view->group);
+		item_err = cscfg_create_params_group_items(feat_desc, params_group);
+		if (item_err)
+			return ERR_PTR(item_err);
+	}
+	return &feat_view->group;
+}
+
+static struct config_item_type cscfg_configs_type = {
+	.ct_owner = THIS_MODULE,
+};
+
+static struct config_group cscfg_configs_grp = {
+	.cg_item = {
+		.ci_namebuf = "configurations",
+		.ci_type = &cscfg_configs_type,
+	},
+};
+
+/* add configuration to configurations group */
+int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc)
+{
+	struct config_group *new_group;
+	int err;
+
+	new_group = cscfg_create_config_group(config_desc);
+	if (IS_ERR(new_group))
+		return PTR_ERR(new_group);
+	err =  configfs_register_group(&cscfg_configs_grp, new_group);
+	return err;
+}
+
+static struct config_item_type cscfg_features_type = {
+	.ct_owner = THIS_MODULE,
+};
+
+static struct config_group cscfg_features_grp = {
+	.cg_item = {
+		.ci_namebuf = "features",
+		.ci_type = &cscfg_features_type,
+	},
+};
+
+/* add feature to features group */
+int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc)
+{
+	struct config_group *new_group;
+	int err;
+
+	new_group = cscfg_create_feature_group(feat_desc);
+	if (IS_ERR(new_group))
+		return PTR_ERR(new_group);
+	err =  configfs_register_group(&cscfg_features_grp, new_group);
+	return err;
+}
+
+int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr)
+{
+	struct configfs_subsystem *subsys;
+	struct config_item_type *ci_type;
+
+	if (!cscfg_mgr)
+		return -EINVAL;
+
+	ci_type = cscfg_create_ci_type();
+	if (!ci_type)
+		return -ENOMEM;
+
+	subsys = &cscfg_mgr->cfgfs_subsys;
+	config_item_set_name(&subsys->su_group.cg_item, CSCFG_FS_SUBSYS_NAME);
+	subsys->su_group.cg_item.ci_type = ci_type;
+
+	config_group_init(&subsys->su_group);
+	mutex_init(&subsys->su_mutex);
+
+	/* Add default groups to subsystem */
+	config_group_init(&cscfg_configs_grp);
+	configfs_add_default_group(&cscfg_configs_grp, &subsys->su_group);
+
+	config_group_init(&cscfg_features_grp);
+	configfs_add_default_group(&cscfg_features_grp, &subsys->su_group);
+
+	return configfs_register_subsystem(subsys);
+}
+
+void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr)
+{
+	configfs_unregister_subsystem(&cscfg_mgr->cfgfs_subsys);
+}
diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.h b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
new file mode 100644
index 000000000000..7d6ffe35ca4c
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Coresight system configuration driver - support for configfs.
+ */
+
+#ifndef CORESIGHT_SYSCFG_CONFIGFS_H
+#define CORESIGHT_SYSCFG_CONFIGFS_H
+
+#include <linux/configfs.h>
+#include "coresight-syscfg.h"
+
+#define CSCFG_FS_SUBSYS_NAME "cs-syscfg"
+
+/* container for configuration view */
+struct cscfg_fs_config {
+	struct cscfg_config_desc *config_desc;
+	struct config_group group;
+};
+
+/* container for feature view */
+struct cscfg_fs_feature {
+	struct cscfg_feature_desc *feat_desc;
+	struct config_group group;
+};
+
+/* container for parameter view */
+struct cscfg_fs_param {
+	int param_idx;
+	struct cscfg_feature_desc *feat_desc;
+	struct config_group group;
+};
+
+/* container for preset view */
+struct cscfg_fs_preset {
+	int preset_num;
+	struct cscfg_config_desc *config_desc;
+	struct config_group group;
+};
+
+int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr);
+void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr);
+int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc);
+int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc);
+
+#endif /* CORESIGHT_SYSCFG_CONFIGFS_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 41f742190639..180202402eb5 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -9,6 +9,7 @@
 #include "coresight-config.h"
 #include "coresight-etm-perf.h"
 #include "coresight-syscfg.h"
+#include "coresight-syscfg-configfs.h"
 
 /*
  * cscfg_ API manages configurations and features for the entire coresight
@@ -287,6 +288,72 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	return 0;
 }
 
+/* get a feature descriptor by name */
+const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name)
+{
+	const struct cscfg_feature_desc *feat_desc = NULL, *feat_desc_item;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(feat_desc_item, &cscfg_mgr->feat_desc_list, item) {
+		if (strcmp(feat_desc_item->name, name) == 0) {
+			feat_desc = feat_desc_item;
+			break;
+		}
+	}
+
+	mutex_unlock(&cscfg_mutex);
+	return feat_desc;
+}
+
+/* called with cscfg_mutex held */
+static struct cscfg_feature_csdev *
+cscfg_csdev_get_feat_from_desc(struct coresight_device *csdev,
+			       struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
+		if (feat_csdev->feat_desc == feat_desc)
+			return feat_csdev;
+	}
+	return NULL;
+}
+
+int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
+				int param_idx, u64 value)
+{
+	int err = 0;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_registered_csdev *csdev_item;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* check if any config active & return busy */
+	if (atomic_read(&cscfg_mgr->sys_active_cnt)) {
+		err = -EBUSY;
+		goto unlock_exit;
+	}
+
+	/* set the value */
+	if ((param_idx < 0) || (param_idx >= feat_desc->nr_params)) {
+		err = -EINVAL;
+		goto unlock_exit;
+	}
+	feat_desc->params_desc[param_idx].value = value;
+
+	/* update loaded instances.*/
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		feat_csdev = cscfg_csdev_get_feat_from_desc(csdev_item->csdev, feat_desc);
+		if (feat_csdev)
+			feat_csdev->params_csdev[param_idx].current_value = value;
+	}
+
+unlock_exit:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+
 /**
  * cscfg_load_config_sets - API function to load feature and config sets.
  *
@@ -308,6 +375,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 	if (feat_descs) {
 		while (feat_descs[i]) {
 			err = cscfg_load_feat(feat_descs[i]);
+			if (!err)
+				err = cscfg_configfs_add_feature(feat_descs[i]);
 			if (err) {
 				pr_err("coresight-syscfg: Failed to load feature %s\n",
 				       feat_descs[i]->name);
@@ -322,6 +391,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 	if (config_descs) {
 		while (config_descs[i]) {
 			err = cscfg_load_config(config_descs[i]);
+			if (!err)
+				err = cscfg_configfs_add_config(config_descs[i]);
 			if (err) {
 				pr_err("coresight-syscfg: Failed to load configuration %s\n",
 				       config_descs[i]->name);
@@ -691,6 +762,7 @@ static void cscfg_clear_device(void)
 	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
 		etm_perf_del_symlink_cscfg(cfg_desc);
 	}
+	cscfg_configfs_release(cscfg_mgr);
 	device_unregister(cscfg_device());
 	mutex_unlock(&cscfg_mutex);
 }
@@ -704,6 +776,10 @@ int __init cscfg_init(void)
 	if (err)
 		return err;
 
+	err = cscfg_configfs_init(cscfg_mgr);
+	if (err)
+		goto exit_err;
+
 	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 7bb8c8e497ba..8d018efd6ead 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -6,6 +6,7 @@
 #ifndef CORESIGHT_SYSCFG_H
 #define CORESIGHT_SYSCFG_H
 
+#include <linux/configfs.h>
 #include <linux/coresight.h>
 #include <linux/device.h>
 
@@ -25,6 +26,7 @@
  * @feat_desc_list:	List of feature descriptors to load into registered devices.
  * @config_desc_list:	List of system configuration descriptors to load into registered devices.
  * @sys_active_cnt:	Total number of active config descriptor references.
+ * @cfgfs_subsys:	configfs subsystem used to manage configurations.
  */
 struct cscfg_manager {
 	struct device dev;
@@ -32,6 +34,7 @@ struct cscfg_manager {
 	struct list_head feat_desc_list;
 	struct list_head config_desc_list;
 	atomic_t sys_active_cnt;
+	struct configfs_subsystem cfgfs_subsys;
 };
 
 /* get reference to dev in cscfg_manager */
@@ -57,6 +60,10 @@ struct cscfg_registered_csdev {
 int __init cscfg_init(void);
 void cscfg_exit(void);
 int cscfg_preload(void);
+const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name);
+int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
+				int param_idx, u64 value);
+
 
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
-- 
2.17.1



From mike.leach at linaro.org  Fri Apr  9 11:37:22 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri,  9 Apr 2021 11:37:22 +0100
Subject: [PATCH v6 10/10] Documentation: coresight: Add documentation for
 CoreSight config
In-Reply-To: <20210409103722.26290-1-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
Message-ID: <20210409103722.26290-11-mike.leach@linaro.org>

Adds documentation for the CoreSight System configuration manager.

Cc: Jonathan Corbet <corbet at lwn.net>
Cc: linux-doc at vger.kernel.org
Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../trace/coresight/coresight-config.rst      | 244 ++++++++++++++++++
 Documentation/trace/coresight/coresight.rst   |  16 ++
 2 files changed, 260 insertions(+)
 create mode 100644 Documentation/trace/coresight/coresight-config.rst

diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst
new file mode 100644
index 000000000000..a4e3ef295240
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-config.rst
@@ -0,0 +1,244 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+CoreSight System Configuration Manager
+======================================
+
+    :Author:   Mike Leach <mike.leach at linaro.org>
+    :Date:     October 2020
+
+Introduction
+============
+
+The CoreSight System Configuration manager is an API that allows the
+programming of the CoreSight system with pre-defined configurations that
+can then be easily enabled from sysfs or perf.
+
+Many CoreSight components can be programmed in complex ways - especially ETMs.
+In addition, components can interact across the CoreSight system, often via
+the cross trigger components such as CTI and CTM. These system settings can
+be defined and enabled as named configurations.
+
+
+Basic Concepts
+==============
+
+This section introduces the basic concepts of a CoreSight system configuration.
+
+
+Features
+--------
+
+A feature is a named set of programming for a CoreSight device. The programming
+is device dependent, and can be defined in terms of absolute register values,
+resource usage and parameter values.
+
+The feature is defined using a descriptor. This descriptor is used to load onto
+a matching device, either when the feature is loaded into the system, or when the
+CoreSight device is registered with the configuration manager.
+
+The load process involves interpreting the descriptor into a set of register
+accesses in the driver - the resource usage and parameter descriptions
+translated into appropriate register accesses. This interpretation makes it easy
+and efficient for the feature to be programmed onto the device when required.
+
+The feature will not be active on the device until the feature is enabled, and
+the device itself is enabled. When the device is enabled then enabled features
+will be programmed into the device hardware.
+
+A feature is enabled as part of a configuration being enabled on the system.
+
+
+Parameter Value
+~~~~~~~~~~~~~~~
+
+A parameter value is a named value that may be set by the user prior to the
+feature being enabled that can adjust the behaviour of the operation programmed
+by the feature.
+
+For example, this could be a count value in a programmed operation that repeats
+at a given rate. When the feature is enabled then the current value of the
+parameter is used in programming the device.
+
+The feature descriptor defines a default value for a parameter, which is used
+if the user does not supply a new value.
+
+Users can update parameter values using the configfs API for the CoreSight
+system - which is described below.
+
+The current value of the parameter is loaded into the device when the feature
+is enabled on that device.
+
+
+Configurations
+--------------
+
+A configuration defines a set of features that are to be used in a trace
+session where the configuration is selected. For any trace session only one
+configuration may be selected.
+
+The features defined may be on any type of device that is registered
+to support system configuration. A configuration may select features to be
+enabled on a class of devices - i.e. any ETMv4, or specific devices, e.g. a
+specific CTI on the system.
+
+As with the feature, a descriptor is used to define the configuration.
+This will define the features that must be enabled as part of the configuration
+as well as any preset values that can be used to override default parameter
+values.
+
+
+Preset Values
+~~~~~~~~~~~~~
+
+Preset values are easily selectable sets of parameter values for the features
+that the configuration uses. The number of values in a single preset set, equals
+the sum of parameter values in the features used by the configuration.
+
+e.g. a configuration consists of 3 features, one has 2 parameters, one has
+a single parameter, and another has no parameters. A single preset set will
+therefore have 3 values.
+
+Presets are optionally defined by the configuration, up to 15 can be defined.
+If no preset is selected, then the parameter values defined in the feature
+are used as normal.
+
+
+Operation
+~~~~~~~~~
+
+The following steps take place in the operation of a configuration.
+
+1) In this example, the configuration is 'autofdo', which has an
+   associated feature 'strobing' that works on ETMv4 CoreSight Devices.
+
+2) The configuration is enabled. For example 'perf' may select the
+   configuration as part of its command line::
+
+    perf record -e cs_etm/autofdo/ myapp
+
+   which will enable the 'autofdo' configuration.
+
+3) perf starts tracing on the system. As each ETMv4 that perf uses for
+   trace is enabled,  the configuration manager will check if the ETMv4
+   has a feature that relates to the currently active configuration.
+   In this case 'strobing' is enabled & programmed into the ETMv4.
+
+4) When the ETMv4 is disabled, any registers marked as needing to be
+   saved will be read back.
+
+5) At the end of the perf session, the configuration will be disabled.
+
+
+Viewing Configurations and Features
+===================================
+
+The set of configurations and features that are currently loaded into the
+system can be viewed using the configfs API.
+
+Mount configfs as normal and the 'cs-syscfg' subsystem will appear::
+
+    $ ls /config
+    cs-syscfg  stp-policy
+
+This has two sub-directories::
+
+    $ cd cs-syscfg/
+    $ ls
+    configurations  features
+
+The system has the configuration 'autofdo' built in. It may be examined as
+follows::
+
+    $ cd configurations/
+    $ ls
+    autofdo
+    $ cd autofdo/
+    $ ls
+    description   preset1  preset3  preset5  preset7  preset9
+    feature_refs  preset2  preset4  preset6  preset8
+    $ cat description
+    Setup ETMs with strobing for autofdo
+    $ cat feature_refs
+    strobing
+
+Each preset declared has a preset<n> subdirectory declared. The values for
+the preset can be examined::
+
+    $ cat preset1/values
+    strobing.window = 0x1388 strobing.period = 0x2
+    $ cat preset2/values
+    strobing.window = 0x1388 strobing.period = 0x4
+
+The features referenced by the configuration can be examined in the features
+directory::
+
+    $ cd ../../features/strobing/
+    $ ls
+    description  matches  nr_params  params
+    $ cat description
+    Generate periodic trace capture windows.
+    parameter 'window': a number of CPU cycles (W)
+    parameter 'period': trace enabled for W cycles every period x W cycles
+    $ cat matches
+    SRC_ETMV4
+    $ cat nr_params
+    2
+
+Move to the params directory to examine and adjust parameters::
+
+    cd params
+    $ ls
+    period  window
+    $ cd period
+    $ ls
+    value
+    $ cat value
+    0x2710
+    # echo 15000 > value
+    # cat value
+    0x3a98
+
+Parameters adjusted in this way are reflected in all device instances that have
+loaded the feature.
+
+
+Using Configurations in perf
+============================
+
+The configurations loaded into the CoreSight configuration management are
+also declared in the perf 'cs_etm' event infrastructure so that they can
+be selected when running trace under perf::
+
+    $ ls /sys/devices/cs_etm
+    configurations  format  perf_event_mux_interval_ms  sinks  type
+    events  nr_addr_filters  power
+
+Key directories here are 'configurations' - which lists the loaded
+configurations, and 'events' - a generic perf directory which allows
+selection on the perf command line.::
+
+    $ ls configurations/
+    autofdo
+    $ cat configurations/autofdo
+    0xa7c3dddd
+
+As with the sinks entries, this provides a hash of the configuration name.
+The entry in the 'events' directory uses perfs built in syntax generator
+to substitute the syntax for the name when evaluating the command::
+
+    $ ls events/
+    autofdo
+    $ cat events/autofdo
+    configid=0xa7c3dddd
+
+The 'autofdo' configuration may be selected on the perf command line::
+
+    $ perf record -e cs_etm/autofdo/u --per-thread <application>
+
+A preset to override the current parameter values can also be selected::
+
+    $ perf record -e cs_etm/autofdo,preset=1/u --per-thread <application>
+
+When configurations are selected in this way, then the trace sink used is
+automatically selected.
diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
index 169749efd8d1..7ec656c9f0dc 100644
--- a/Documentation/trace/coresight/coresight.rst
+++ b/Documentation/trace/coresight/coresight.rst
@@ -619,6 +619,20 @@ A separate documentation file is provided to explain the use of these devices.
 (:doc:`coresight-ect`) [#fourth]_.
 
 
+CoreSight System Configuration
+------------------------------
+
+CoreSight components can be complex devices with many programming options.
+Furthermore, components can be programmed to interact with each other across the
+complete system.
+
+A CoreSight System Configuration manager is provided to allow these complex programming
+configurations to be selected and used easily from perf and sysfs.
+
+See the separate document for further information.
+(:doc:`coresight-config`) [#fifth]_.
+
+
 .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 
 .. [#second] Documentation/trace/stm.rst
@@ -626,3 +640,5 @@ A separate documentation file is provided to explain the use of these devices.
 .. [#third] https://github.com/Linaro/perf-opencsd
 
 .. [#fourth] Documentation/trace/coresight/coresight-ect.rst
+
+.. [#fifth] Documentation/trace/coresight/coresight-config.rst
-- 
2.17.1



From nsaenz at kernel.org  Fri Apr  9 11:44:47 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Fri,  9 Apr 2021 12:44:47 +0200
Subject: [PATCH] MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
Message-ID: <20210409104448.12259-1-nsaenz@kernel.org>

The @kernel.org e-mail address is likely to last longer than the current
one, so use it.

Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index d269763af39d..c8f32b7c1e06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3414,7 +3414,7 @@ F:	include/linux/dsa/brcm.h
 F:	include/linux/platform_data/b53.h
 
 BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
-M:	Nicolas Saenz Julienne <nsaenzjulienne at suse.de>
+M:	Nicolas Saenz Julienne <nsaenz at kernel.org>
 L:	bcm-kernel-feedback-list at broadcom.com
 L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-- 
2.31.1



From nsaenzjulienne at suse.de  Fri Apr  9 11:54:26 2021
From: nsaenzjulienne at suse.de (Nicolas Saenz Julienne)
Date: Fri, 09 Apr 2021 12:54:26 +0200
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
 <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
 <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>
 <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>
Message-ID: <2dbb9e8c1f1e107712b05e36aa1b244329381425.camel@suse.de>

Hi again,

On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
> Nicolas,
> 
> I got a better description of the failure and it looks like the bus
> clock needs to be limited to 300KHz for a 500MHz core clock.
> What's happening is that an internal reset sequence is needed after a
> command timeout and the reset signal needs to be asserted for at least
> 2 ticks of the bus clock. This is done using a 12 bit counter clocked
> by the core clock. That means a 500MHz core clock produces a 122KHz
> reset signal which is too fast for 2 ticks of the 200KHz bus clock
> (100KHz) but is okay for the 300KHz (150Khz) bus clock.

Is there any value in implementing this in a generic way? That is, will a SoC
other than BCM2711 ever need this? Otherwise I can simply limit BCM2711's
sdhci-iproc min clk frequency to 300KHz and call it a day.

The alternative is something the likes of:

	min_clk = clk_get_rate(core_bus) >> 11;

But it involves updating the bindings and DT.

Regards,
Nicolas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/901d95f8/attachment.sig>

From marcan at marcan.st  Fri Apr  9 11:56:17 2021
From: marcan at marcan.st (Hector Martin)
Date: Fri, 9 Apr 2021 19:56:17 +0900
Subject: linux-next: build failure after merge of the arm-soc tree
In-Reply-To: <20210409201316.6c9295a4@canb.auug.org.au>
References: <20210409201316.6c9295a4@canb.auug.org.au>
Message-ID: <1d2feb6a-43a0-45b5-1c5f-50e23bb399be@marcan.st>

Hi Stephen,

On 09/04/2021 19.13, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the arm-soc tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
[...]
> Caused by commits
> 
>    7c566bb5e4d5 ("asm-generic/io.h:  Add a non-posted variant of ioremap()")
>    89897f739d7b ("of/address: Add infrastructure to declare MMIO as non-posted")
> (and maybe some others)
> 
> I have reverted 86332e9e3477..7d2d16ccf15d for today.

This is fixed in ea9629283839 in the soc tree, which went in a few hours 
ago. Sorry for the noise.

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From Ludovic.Desroches at microchip.com  Fri Apr  9 11:58:17 2021
From: Ludovic.Desroches at microchip.com (Ludovic.Desroches at microchip.com)
Date: Fri, 9 Apr 2021 10:58:17 +0000
Subject: [PATCH] drm/atmel-hlcdc: Allow async page flips
In-Reply-To: <20210330151721.6616-1-dan.sneddon@microchip.com>
References: <20210330151721.6616-1-dan.sneddon@microchip.com>
Message-ID: <20210409105816.cfffdr3edzi4yntm@sekiro>

On Tue, Mar 30, 2021 at 08:17:20AM -0700, Dan Sneddon wrote:
> The driver is capable of doing async page flips so we need to tell the
> core to allow them.
> 
> Signed-off-by: Dan Sneddon <dan.sneddon at microchip.com>
Tested-by: Ludovic Desroches <ludovic.desroches at microchip.com> 

Thanks,
Ludovic

> ---
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 871293d1aeeb..f6c3d8809fd8 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -686,6 +686,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
>  	dev->mode_config.max_width = dc->desc->max_width;
>  	dev->mode_config.max_height = dc->desc->max_height;
>  	dev->mode_config.funcs = &mode_config_funcs;
> +	dev->mode_config.async_page_flip = true;
>  
>  	return 0;
>  }
> -- 
> 2.17.1
> 

From linqiheng at huawei.com  Fri Apr  9 12:02:46 2021
From: linqiheng at huawei.com (Qiheng Lin)
Date: Fri, 9 Apr 2021 19:02:46 +0800
Subject: [PATCH -next] ASoC: sun4i-codec: remove redundant dev_err call in
 sun4i_codec_probe()
Message-ID: <20210409110246.96-1-linqiheng@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
---
 sound/soc/sunxi/sun4i-codec.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 6c13cc84b3fb..00b73b7444b7 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1706,10 +1706,8 @@ static int sun4i_codec_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(base)) {
-		dev_err(&pdev->dev, "Failed to map the registers\n");
+	if (IS_ERR(base))
 		return PTR_ERR(base);
-	}
 
 	quirks = of_device_get_match_data(&pdev->dev);
 	if (quirks == NULL) {



From linqiheng at huawei.com  Fri Apr  9 12:02:43 2021
From: linqiheng at huawei.com (Qiheng Lin)
Date: Fri, 9 Apr 2021 19:02:43 +0800
Subject: [PATCH -next] soc: amlogic: meson-clk-measure: remove redundant
 dev_err call in meson_msr_probe()
Message-ID: <20210409110243.41-1-linqiheng@huawei.com>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
---
 drivers/soc/amlogic/meson-clk-measure.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index e1957476a006..6dd190270123 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -626,10 +626,8 @@ static int meson_msr_probe(struct platform_device *pdev)
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(base)) {
-		dev_err(&pdev->dev, "io resource mapping failed\n");
+	if (IS_ERR(base))
 		return PTR_ERR(base);
-	}
 
 	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
 					     &meson_clk_msr_regmap_config);



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:21 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:21 +0300
Subject: [PATCH v2 00/24] ARM: at91: pm: add support for sama7g5
Message-ID: <20210409111345.294472-1-claudiu.beznea@microchip.com>

Hi,

This series adds PM support for SAMA7G5. The standby, ulp0, ulp1, and
backup modes are supported.

Thank you,
Claudiu Beznea

Changes in v2:
- keep only the generic sama7_dt in patch 22/24 and adapt patch 23/24
- collected tags

Claudiu Beznea (23):
  ARM: at91: pm: move pm_bu to soc_pm data structure
  ARM: at91: pm: move the setup of soc_pm.bu->suspended
  ARM: at91: pm: document at91_soc_pm structure
  ARM: at91: pm: check for different controllers in at91_pm_modes_init()
  ARM: at91: pm: do not initialize pdev
  ARM: at91: pm: use r7 instead of tmp1
  ARM: at91: pm: avoid push and pop on stack while memory is in
    self-refersh
  ARM: at91: pm: s/CONFIG_SOC_SAM9X60/CONFIG_HAVE_AT91_SAM9X60_PLL/g
  ARM: at91: pm: add support for waiting MCK1..4
  ARM: at91: sfrbu: add sfrbu registers definitions for sama7g5
  ARM: at91: ddr: add registers definitions for sama7g5's ddr
  ARM: at91: pm: add self-refresh support for sama7g5
  ARM: at91: pm: add support for MCK1..4 save/restore for ulp modes
  ARM: at91: pm: add support for 2.5V LDO regulator control
  ARM: at91: pm: wait for ddr power mode off
  dt-bindings: atmel-sysreg: add bindings for sama7g5
  ARM: at91: pm: add sama7g5 ddr controller
  ARM: at91: pm: add sama7g5 ddr phy controller
  ARM: at91: pm: save ddr phy calibration data to securam
  ARM: at91: pm: add backup mode support for SAMA7G5
  ARM: at91: pm: add sama7g5's pmc
  ARM: at91: pm: add pm support for SAMA7G5
  ARM: at91: pm: add sama7g5 shdwc

Eugen Hristev (1):
  ARM: at91: sama7: introduce sama7 SoC family

 .../devicetree/bindings/arm/atmel-sysregs.txt |  15 +-
 arch/arm/mach-at91/Makefile                   |   1 +
 arch/arm/mach-at91/generic.h                  |   2 +
 arch/arm/mach-at91/pm.c                       | 343 ++++++--
 arch/arm/mach-at91/pm.h                       |   3 +
 arch/arm/mach-at91/pm_data-offsets.c          |   2 +
 arch/arm/mach-at91/pm_suspend.S               | 827 +++++++++++++-----
 arch/arm/mach-at91/sama7.c                    |  33 +
 include/soc/at91/sama7-ddr.h                  |  80 ++
 include/soc/at91/sama7-sfrbu.h                |  34 +
 10 files changed, 1050 insertions(+), 290 deletions(-)
 create mode 100644 arch/arm/mach-at91/sama7.c
 create mode 100644 include/soc/at91/sama7-ddr.h
 create mode 100644 include/soc/at91/sama7-sfrbu.h

-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:22 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:22 +0300
Subject: [PATCH v2 01/24] ARM: at91: pm: move pm_bu to soc_pm data structure
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-2-claudiu.beznea@microchip.com>

Move pm_bu to soc_pm data structure.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 90dcdfe3b3d0..e13ceef7ac9a 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -27,10 +27,25 @@
 #include "generic.h"
 #include "pm.h"
 
+/**
+ * struct at91_pm_bu - AT91 power management backup unit data structure
+ * @suspended: true if suspended to backup mode
+ * @reserved: reserved
+ * @canary: canary data for memory checking after exit from backup mode
+ * @resume: resume API
+ */
+struct at91_pm_bu {
+	int suspended;
+	unsigned long reserved;
+	phys_addr_t canary;
+	phys_addr_t resume;
+};
+
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
 	int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
 	const struct of_device_id *ws_ids;
+	struct at91_pm_bu *bu;
 	struct at91_pm_data data;
 };
 
@@ -71,13 +86,6 @@ static int at91_pm_valid_state(suspend_state_t state)
 
 static int canary = 0xA5A5A5A5;
 
-static struct at91_pm_bu {
-	int suspended;
-	unsigned long reserved;
-	phys_addr_t canary;
-	phys_addr_t resume;
-} *pm_bu;
-
 struct wakeup_source_info {
 	unsigned int pmc_fsmr_bit;
 	unsigned int shdwc_mr_bit;
@@ -288,7 +296,7 @@ static int at91_suspend_finish(unsigned long val)
 static void at91_pm_suspend(suspend_state_t state)
 {
 	if (soc_pm.data.mode == AT91_PM_BACKUP) {
-		pm_bu->suspended = 1;
+		soc_pm.bu->suspended = 1;
 
 		cpu_suspend(0, at91_suspend_finish);
 
@@ -657,16 +665,16 @@ static int __init at91_pm_backup_init(void)
 		goto securam_fail;
 	}
 
-	pm_bu = (void *)gen_pool_alloc(sram_pool, sizeof(struct at91_pm_bu));
-	if (!pm_bu) {
+	soc_pm.bu = (void *)gen_pool_alloc(sram_pool, sizeof(struct at91_pm_bu));
+	if (!soc_pm.bu) {
 		pr_warn("%s: unable to alloc securam!\n", __func__);
 		ret = -ENOMEM;
 		goto securam_fail;
 	}
 
-	pm_bu->suspended = 0;
-	pm_bu->canary = __pa_symbol(&canary);
-	pm_bu->resume = __pa_symbol(cpu_resume);
+	soc_pm.bu->suspended = 0;
+	soc_pm.bu->canary = __pa_symbol(&canary);
+	soc_pm.bu->resume = __pa_symbol(cpu_resume);
 
 	return 0;
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:23 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:23 +0300
Subject: [PATCH v2 02/24] ARM: at91: pm: move the setup of soc_pm.bu->suspended
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-3-claudiu.beznea@microchip.com>

Move the setup of soc_pm.bu->suspended in platform_suspend::begin
function so that the PMC code in charge with clocks suspend/resume
to differentiate b/w standard PM mode and backup mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 arch/arm/mach-at91/pm.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index e13ceef7ac9a..3742a1fb76db 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -214,6 +214,8 @@ static int at91_sam9x60_config_pmc_ws(void __iomem *pmc, u32 mode, u32 polarity)
  */
 static int at91_pm_begin(suspend_state_t state)
 {
+	int ret;
+
 	switch (state) {
 	case PM_SUSPEND_MEM:
 		soc_pm.data.mode = soc_pm.data.suspend_mode;
@@ -227,7 +229,16 @@ static int at91_pm_begin(suspend_state_t state)
 		soc_pm.data.mode = -1;
 	}
 
-	return at91_pm_config_ws(soc_pm.data.mode, true);
+	ret = at91_pm_config_ws(soc_pm.data.mode, true);
+	if (ret)
+		return ret;
+
+	if (soc_pm.data.mode == AT91_PM_BACKUP)
+		soc_pm.bu->suspended = 1;
+	else if (soc_pm.bu)
+		soc_pm.bu->suspended = 0;
+
+	return 0;
 }
 
 /*
@@ -296,8 +307,6 @@ static int at91_suspend_finish(unsigned long val)
 static void at91_pm_suspend(suspend_state_t state)
 {
 	if (soc_pm.data.mode == AT91_PM_BACKUP) {
-		soc_pm.bu->suspended = 1;
-
 		cpu_suspend(0, at91_suspend_finish);
 
 		/* The SRAM is lost between suspend cycles */
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:24 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:24 +0300
Subject: [PATCH v2 03/24] ARM: at91: pm: document at91_soc_pm structure
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-4-claudiu.beznea@microchip.com>

Document at91_soc_pm structure.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 3742a1fb76db..3029351ec78e 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -41,6 +41,14 @@ struct at91_pm_bu {
 	phys_addr_t resume;
 };
 
+/**
+ * struct at91_soc_pm - AT91 SoC power management data structure
+ * @config_shdwc_ws: wakeup sources configuration function for SHDWC
+ * @config_pmc_ws: wakeup srouces configuration function for PMC
+ * @ws_ids: wakup sources of_device_id array
+ * @data: PM data to be used on last phase of suspend
+ * @bu: backup unit mapped data (for backup mode)
+ */
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
 	int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
-- 
2.25.1



From rafael at kernel.org  Fri Apr  9 12:14:40 2021
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Fri, 9 Apr 2021 13:14:40 +0200
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <1617957362.12105.27.camel@mhfsdcap03>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
 <1617933211.12105.22.camel@mhfsdcap03> <YG/ohhh3Tyet6InQ@atomide.com>
 <1617957362.12105.27.camel@mhfsdcap03>
Message-ID: <CAJZ5v0ioobLt5aEm8TAcPKgJiL13OJ7KqTeJmcQCuVp8ALxBmw@mail.gmail.com>

On Fri, Apr 9, 2021 at 10:36 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
>
> On Fri, 2021-04-09 at 08:39 +0300, Tony Lindgren wrote:
> > * Chunfeng Yun <chunfeng.yun at mediatek.com> [210409 01:54]:
> > > On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote:
> > > > On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > > > >
> > > > > When the dedicated wake irq is level trigger, enable it before
> > > > > calling runtime_suspend, will trigger an interrupt.
> > > > >
> > > > > e.g.
> > > > > for a low level trigger type, it's low level at running time (0),
> > > > > and becomes high level when enters suspend (runtime_suspend (1) is
> > > > > called), a wakeup signal at (2) make it become low level, wake irq
> > > > > will be triggered.
> > > > >
> > > > >                 ------------------
> > > > >                |           ^     ^|
> > > > > ----------------           |     | --------------
> > > > >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> > > > >
> > > > > if we enable the wake irq before calling runtime_suspend during (0),
> > > > > an interrupt will arise, it causes resume immediately;
> > > >
> > > > But that's necessary to avoid missing a wakeup interrupt, isn't it?
> > > That's also what I worry about.
> >
> > Yeah sounds like this patch will lead into missed wakeirqs.
> If miss level trigger wakeirqs, that means HW doesn't latch it? is it HW
> limitation?

If it's level-triggered, it won't be missed, but then it is just
pointless to suspend the device when wakeup is being signaled in the
first place.

I'm not sure if I understand the underlying problem correctly.  Is it
about addressing spurious wakeups?


From nsaenz at kernel.org  Fri Apr  9 12:14:53 2021
From: nsaenz at kernel.org (Nicolas Saenz Julienne)
Date: Fri,  9 Apr 2021 13:14:53 +0200
Subject: [PATCH] mailmap: Update email address for Nicolas Saenz
Message-ID: <20210409111453.28121-1-nsaenz@kernel.org>

Add my kernel.org address for old email address.

Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
---
 .mailmap | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 78835e80214a..b407e1192fb3 100644
--- a/.mailmap
+++ b/.mailmap
@@ -260,6 +260,8 @@ Nguyen Anh Quynh <aquynh at gmail.com>
 Nicolas Ferre <nicolas.ferre at microchip.com> <nicolas.ferre at atmel.com>
 Nicolas Pitre <nico at fluxnic.net> <nicolas.pitre at linaro.org>
 Nicolas Pitre <nico at fluxnic.net> <nico at linaro.org>
+Nicolas Saenz Julienne <nsaenz at kernel.org> <nsaenzjulienne at suse.de>
+Nicolas Saenz Julienne <nsaenz at kernel.org> <nsaenzjulienne at suse.com>
 Oleksij Rempel <linux at rempel-privat.de> <bug-track at fisher-privat.net>
 Oleksij Rempel <linux at rempel-privat.de> <external.Oleksij.Rempel at de.bosch.com>
 Oleksij Rempel <linux at rempel-privat.de> <fixed-term.Oleksij.Rempel at de.bosch.com>
-- 
2.31.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:25 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:25 +0300
Subject: [PATCH v2 04/24] ARM: at91: pm: check for different controllers in
 at91_pm_modes_init()
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-5-claudiu.beznea@microchip.com>

at91_pm_modes_init() checks for proper nodes in device tree and maps
them accordingly. Up to SAMA7G5 all AT91 SoCs had the same mapping
b/w power saving modes and different controllers needed in the
final/first steps of suspend/resume. SAMA7G5 is not aligned with the
old SoCs thus the code is adapted for this. This patch prepares
the field for next commits.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 143 +++++++++++++++++++++++++---------------
 1 file changed, 91 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 3029351ec78e..5a6ce1d88971 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -57,6 +57,18 @@ struct at91_soc_pm {
 	struct at91_pm_data data;
 };
 
+/**
+ * enum at91_pm_iomaps:	IOs that needs to be mapped for different PM modes
+ * @AT91_PM_IOMAP_SHDWC:	SHDWC controller
+ * @AT91_PM_IOMAP_SFRBU:	SFRBU controller
+ */
+enum at91_pm_iomaps {
+	AT91_PM_IOMAP_SHDWC,
+	AT91_PM_IOMAP_SFRBU,
+};
+
+#define AT91_PM_IOMAP(name)	BIT(AT91_PM_IOMAP_##name)
+
 static struct at91_soc_pm soc_pm = {
 	.data = {
 		.standby_mode = AT91_PM_STANDBY,
@@ -656,24 +668,15 @@ static int __init at91_pm_backup_init(void)
 	if (!at91_is_pm_mode_active(AT91_PM_BACKUP))
 		return 0;
 
-	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-sfrbu");
-	if (!np) {
-		pr_warn("%s: failed to find sfrbu!\n", __func__);
-		return ret;
-	}
-
-	soc_pm.data.sfrbu = of_iomap(np, 0);
-	of_node_put(np);
-
 	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-securam");
 	if (!np)
-		goto securam_fail_no_ref_dev;
+		return ret;
 
 	pdev = of_find_device_by_node(np);
 	of_node_put(np);
 	if (!pdev) {
 		pr_warn("%s: failed to find securam device!\n", __func__);
-		goto securam_fail_no_ref_dev;
+		return ret;
 	}
 
 	sram_pool = gen_pool_get(&pdev->dev, NULL);
@@ -697,64 +700,92 @@ static int __init at91_pm_backup_init(void)
 
 securam_fail:
 	put_device(&pdev->dev);
-securam_fail_no_ref_dev:
-	iounmap(soc_pm.data.sfrbu);
-	soc_pm.data.sfrbu = NULL;
 	return ret;
 }
 
-static void __init at91_pm_use_default_mode(int pm_mode)
-{
-	if (pm_mode != AT91_PM_ULP1 && pm_mode != AT91_PM_BACKUP)
-		return;
-
-	if (soc_pm.data.standby_mode == pm_mode)
-		soc_pm.data.standby_mode = AT91_PM_ULP0;
-	if (soc_pm.data.suspend_mode == pm_mode)
-		soc_pm.data.suspend_mode = AT91_PM_ULP0;
-}
-
 static const struct of_device_id atmel_shdwc_ids[] = {
 	{ .compatible = "atmel,sama5d2-shdwc" },
 	{ .compatible = "microchip,sam9x60-shdwc" },
 	{ /* sentinel. */ }
 };
 
-static void __init at91_pm_modes_init(void)
+static void __init at91_pm_modes_init(const u32 *maps, int len)
 {
 	struct device_node *np;
-	int ret;
+	int ret, mode;
 
-	if (!at91_is_pm_mode_active(AT91_PM_BACKUP) &&
-	    !at91_is_pm_mode_active(AT91_PM_ULP1))
-		return;
+	ret = at91_pm_backup_init();
+	if (ret) {
+		if (soc_pm.data.standby_mode == AT91_PM_BACKUP)
+			soc_pm.data.standby_mode = AT91_PM_ULP0;
+		if (soc_pm.data.suspend_mode == AT91_PM_BACKUP)
+			soc_pm.data.suspend_mode = AT91_PM_ULP0;
+	}
 
-	np = of_find_matching_node(NULL, atmel_shdwc_ids);
-	if (!np) {
-		pr_warn("%s: failed to find shdwc!\n", __func__);
-		goto ulp1_default;
+	if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC) ||
+	    maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC)) {
+		np = of_find_matching_node(NULL, atmel_shdwc_ids);
+		if (!np) {
+			pr_warn("%s: failed to find shdwc!\n", __func__);
+
+			/* Use ULP0 if it doesn't needs SHDWC.*/
+			if (!(maps[AT91_PM_ULP0] & AT91_PM_IOMAP(SHDWC)))
+				mode = AT91_PM_ULP0;
+			else
+				mode = AT91_PM_STANDBY;
+
+			if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC))
+				soc_pm.data.standby_mode = mode;
+			if (maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC))
+				soc_pm.data.suspend_mode = mode;
+		} else {
+			soc_pm.data.shdwc = of_iomap(np, 0);
+			of_node_put(np);
+		}
 	}
 
-	soc_pm.data.shdwc = of_iomap(np, 0);
-	of_node_put(np);
+	if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU) ||
+	    maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU)) {
+		np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-sfrbu");
+		if (!np) {
+			pr_warn("%s: failed to find sfrbu!\n", __func__);
+
+			/*
+			 * Use ULP0 if it doesn't need SHDWC or if SHDWC
+			 * was already located.
+			 */
+			if (!(maps[AT91_PM_ULP0] & AT91_PM_IOMAP(SHDWC)) ||
+			    soc_pm.data.shdwc)
+				mode = AT91_PM_ULP0;
+			else
+				mode = AT91_PM_STANDBY;
+
+			if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU))
+				soc_pm.data.standby_mode = mode;
+			if (maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU))
+				soc_pm.data.suspend_mode = mode;
+		} else {
+			soc_pm.data.sfrbu = of_iomap(np, 0);
+			of_node_put(np);
+		}
+	}
 
-	ret = at91_pm_backup_init();
-	if (ret) {
-		if (!at91_is_pm_mode_active(AT91_PM_ULP1))
-			goto unmap;
-		else
-			goto backup_default;
+	/* Unmap all unnecessary. */
+	if (soc_pm.data.shdwc &&
+	    !(maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC) ||
+	      maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC))) {
+		iounmap(soc_pm.data.shdwc);
+		soc_pm.data.shdwc = NULL;
 	}
 
-	return;
+	if (soc_pm.data.sfrbu &&
+	    !(maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU) ||
+	      maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU))) {
+		iounmap(soc_pm.data.sfrbu);
+		soc_pm.data.sfrbu = NULL;
+	}
 
-unmap:
-	iounmap(soc_pm.data.shdwc);
-	soc_pm.data.shdwc = NULL;
-ulp1_default:
-	at91_pm_use_default_mode(AT91_PM_ULP1);
-backup_default:
-	at91_pm_use_default_mode(AT91_PM_BACKUP);
+	return;
 }
 
 struct pmc_info {
@@ -917,12 +948,15 @@ void __init sam9x60_pm_init(void)
 	static const int modes[] __initconst = {
 		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP0_FAST, AT91_PM_ULP1,
 	};
+	static const int iomaps[] __initconst = {
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SHDWC),
+	};
 
 	if (!IS_ENABLED(CONFIG_SOC_SAM9X60))
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_pm_modes_init();
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
 	at91_dt_ramc();
 	at91_pm_init(NULL);
 
@@ -967,12 +1001,17 @@ void __init sama5d2_pm_init(void)
 		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP0_FAST, AT91_PM_ULP1,
 		AT91_PM_BACKUP,
 	};
+	static const u32 iomaps[] __initconst = {
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SHDWC),
+		[AT91_PM_BACKUP]	= AT91_PM_IOMAP(SHDWC) |
+					  AT91_PM_IOMAP(SFRBU),
+	};
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_pm_modes_init();
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
 	at91_dt_ramc();
 	at91_pm_init(NULL);
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:26 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:26 +0300
Subject: [PATCH v2 05/24] ARM: at91: pm: do not initialize pdev
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-6-claudiu.beznea@microchip.com>

There is no need to initialize pdev.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5a6ce1d88971..65e13769cf50 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -659,7 +659,7 @@ static int __init at91_pm_backup_init(void)
 {
 	struct gen_pool *sram_pool;
 	struct device_node *np;
-	struct platform_device *pdev = NULL;
+	struct platform_device *pdev;
 	int ret = -ENODEV;
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:27 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:27 +0300
Subject: [PATCH v2 06/24] ARM: at91: pm: use r7 instead of tmp1
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-7-claudiu.beznea@microchip.com>

Use r7 instead of tmp1 in macros. This prepares the filed for
next commits.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index b683c2caa40b..3d20c9880fee 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -31,30 +31,36 @@ tmp3	.req	r6
 
 /*
  * Wait until master oscillator has stabilized.
+ *
+ * Side effects: overwrites r7
  */
 	.macro wait_moscrdy
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MOSCS
+1:	ldr	r7, [pmc, #AT91_PMC_SR]
+	tst	r7, #AT91_PMC_MOSCS
 	beq	1b
 	.endm
 
 /*
  * Wait for main oscillator selection is done
+ *
+ * Side effects: overwrites r7
  */
 	.macro wait_moscsels
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MOSCSELS
+1:	ldr	r7, [pmc, #AT91_PMC_SR]
+	tst	r7, #AT91_PMC_MOSCSELS
 	beq	1b
 	.endm
 
 /*
  * Put the processor to enter the idle state
+ *
+ * Side effects: overwrites r7
  */
 	.macro at91_cpu_idle
 
 #if defined(CONFIG_CPU_V7)
-	mov	tmp1, #AT91_PMC_PCK
-	str	tmp1, [pmc, #AT91_PMC_SCDR]
+	mov	r7, #AT91_PMC_PCK
+	str	r7, [pmc, #AT91_PMC_SCDR]
 
 	dsb
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:28 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:28 +0300
Subject: [PATCH v2 07/24] ARM: at91: pm: avoid push and pop on stack while
 memory is in self-refersh
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-8-claudiu.beznea@microchip.com>

For the previous AT91 RAM controller and self-refresh procedure this
had no side effects. However, for SAMA7G5 the self-refresh procedure
doesn't allow this anymore as the RAM controller ports are closed
before switching it to self-refresh. This commits prepares the code
for the following ones adding self-refresh and PM support for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 397 +++++++++++++++++---------------
 1 file changed, 205 insertions(+), 192 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 3d20c9880fee..960ad29cce51 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -75,98 +75,147 @@ tmp3	.req	r6
 
 	.arm
 
-/*
- * void at91_suspend_sram_fn(struct at91_pm_data*)
- * @input param:
- * 	@r0: base address of struct at91_pm_data
+/**
+ * Enable self-refresh
+ *
+ * register usage:
+ * 	@r1: memory type
+ *	@r2: base address of the sram controller
+ *	@r3: temporary
  */
-/* at91_pm_suspend_in_sram must be 8-byte aligned per the requirements of fncpy() */
-	.align 3
-ENTRY(at91_pm_suspend_in_sram)
-	/* Save registers on stack */
-	stmfd	sp!, {r4 - r12, lr}
+.macro at91_sramc_self_refresh_ena
+	ldr	r1, .memtype
+	ldr	r2, .sramc_base
 
-	/* Drain write buffer */
-	mov	tmp1, #0
-	mcr	p15, 0, tmp1, c7, c10, 4
+	cmp	r1, #AT91_MEMCTRL_MC
+	bne	sr_ena_ddrc_sf
 
-	ldr	tmp1, [r0, #PM_DATA_PMC]
-	str	tmp1, .pmc_base
-	ldr	tmp1, [r0, #PM_DATA_RAMC0]
-	str	tmp1, .sramc_base
-	ldr	tmp1, [r0, #PM_DATA_RAMC1]
-	str	tmp1, .sramc1_base
-	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
-	str	tmp1, .memtype
-	ldr	tmp1, [r0, #PM_DATA_MODE]
-	str	tmp1, .pm_mode
-	ldr	tmp1, [r0, #PM_DATA_PMC_MCKR_OFFSET]
-	str	tmp1, .mckr_offset
-	ldr	tmp1, [r0, #PM_DATA_PMC_VERSION]
-	str	tmp1, .pmc_version
-	/* Both ldrne below are here to preload their address in the TLB */
-	ldr	tmp1, [r0, #PM_DATA_SHDWC]
-	str	tmp1, .shdwc
-	cmp	tmp1, #0
-	ldrne	tmp2, [tmp1, #0]
-	ldr	tmp1, [r0, #PM_DATA_SFRBU]
-	str	tmp1, .sfrbu
-	cmp	tmp1, #0
-	ldrne	tmp2, [tmp1, #0x10]
+	/* Active SDRAM self-refresh mode */
+	mov	r3, #1
+	str	r3, [r2, #AT91_MC_SDRAMC_SRR]
+	b	sr_ena_exit
 
-	/* Active the self-refresh mode */
-	mov	r0, #SRAMC_SELF_FRESH_ACTIVE
-	bl	at91_sramc_self_refresh
+sr_ena_ddrc_sf:
+	cmp	r1, #AT91_MEMCTRL_DDRSDR
+	bne	sr_ena_sdramc_sf
 
-	ldr	r0, .pm_mode
-	cmp	r0, #AT91_PM_STANDBY
-	beq	standby
-	cmp	r0, #AT91_PM_BACKUP
-	beq	backup_mode
+	/*
+	 * DDR Memory controller
+	 */
 
-	bl	at91_ulp_mode
-	b	exit_suspend
+	/* LPDDR1 --> force DDR2 mode during self-refresh */
+	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
+	str	r3, .saved_sam9_mdr
+	bic	r3, r3, #~AT91_DDRSDRC_MD
+	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
+	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
+	biceq	r3, r3, #AT91_DDRSDRC_MD
+	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
+	streq	r3, [r2, #AT91_DDRSDRC_MDR]
 
-standby:
-	/* Wait for interrupt */
-	ldr	pmc, .pmc_base
-	at91_cpu_idle
-	b	exit_suspend
+	/* Active DDRC self-refresh mode */
+	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
+	str	r3, .saved_sam9_lpr
+	bic	r3, r3, #AT91_DDRSDRC_LPCB
+	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
 
-backup_mode:
-	bl	at91_backup_mode
-	b	exit_suspend
+	/* If using the 2nd ddr controller */
+	ldr	r2, .sramc1_base
+	cmp	r2, #0
+	beq	sr_ena_no_2nd_ddrc
 
-exit_suspend:
-	/* Exit the self-refresh mode */
-	mov	r0, #SRAMC_SELF_FRESH_EXIT
-	bl	at91_sramc_self_refresh
+	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
+	str	r3, .saved_sam9_mdr1
+	bic	r3, r3, #~AT91_DDRSDRC_MD
+	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
+	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
+	biceq	r3, r3, #AT91_DDRSDRC_MD
+	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
+	streq	r3, [r2, #AT91_DDRSDRC_MDR]
 
-	/* Restore registers, and return */
-	ldmfd	sp!, {r4 - r12, pc}
-ENDPROC(at91_pm_suspend_in_sram)
+	/* Active DDRC self-refresh mode */
+	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
+	str	r3, .saved_sam9_lpr1
+	bic	r3, r3, #AT91_DDRSDRC_LPCB
+	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
 
-ENTRY(at91_backup_mode)
-	/* Switch the master clock source to slow clock. */
-	ldr	pmc, .pmc_base
-	ldr	tmp2, .mckr_offset
-	ldr	tmp1, [pmc, tmp2]
-	bic	tmp1, tmp1, #AT91_PMC_CSS
-	str	tmp1, [pmc, tmp2]
+sr_ena_no_2nd_ddrc:
+	b	sr_ena_exit
 
-	wait_mckrdy
+	/*
+	 * SDRAMC Memory controller
+	 */
+sr_ena_sdramc_sf:
+	/* Active SDRAMC self-refresh mode */
+	ldr	r3, [r2, #AT91_SDRAMC_LPR]
+	str	r3, .saved_sam9_lpr
+	bic	r3, r3, #AT91_SDRAMC_LPCB
+	orr	r3, r3, #AT91_SDRAMC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_SDRAMC_LPR]
 
-	/*BUMEN*/
-	ldr	r0, .sfrbu
-	mov	tmp1, #0x1
-	str	tmp1, [r0, #0x10]
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_SDRAMC_LPR]
 
-	/* Shutdown */
-	ldr	r0, .shdwc
-	mov	tmp1, #0xA5000000
-	add	tmp1, tmp1, #0x1
-	str	tmp1, [r0, #0]
-ENDPROC(at91_backup_mode)
+sr_ena_exit:
+.endm
+
+/**
+ * Disable self-refresh
+ *
+ * register usage:
+ * 	@r1: memory type
+ *	@r2: base address of the sram controller
+ *	@r3: temporary
+ */
+.macro at91_sramc_self_refresh_dis
+	ldr	r1, .memtype
+	ldr	r2, .sramc_base
+
+	cmp	r1, #AT91_MEMCTRL_MC
+	bne	sr_dis_ddrc_exit_sf
+
+	/*
+	 * at91rm9200 Memory controller
+	 */
+
+	 /*
+	  * For exiting the self-refresh mode, do nothing,
+	  * automatically exit the self-refresh mode.
+	  */
+	b	sr_dis_exit
+
+sr_dis_ddrc_exit_sf:
+	cmp	r1, #AT91_MEMCTRL_DDRSDR
+	bne	sdramc_exit_sf
+
+	/* DDR Memory controller */
+
+	/* Restore MDR in case of LPDDR1 */
+	ldr	r3, .saved_sam9_mdr
+	str	r3, [r2, #AT91_DDRSDRC_MDR]
+	/* Restore LPR on AT91 with DDRAM */
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
+
+	/* If using the 2nd ddr controller */
+	ldr	r2, .sramc1_base
+	cmp	r2, #0
+	ldrne	r3, .saved_sam9_mdr1
+	strne	r3, [r2, #AT91_DDRSDRC_MDR]
+	ldrne	r3, .saved_sam9_lpr1
+	strne	r3, [r2, #AT91_DDRSDRC_LPR]
+
+	b	sr_dis_exit
+
+sdramc_exit_sf:
+	/* SDRAMC Memory controller */
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_SDRAMC_LPR]
+
+sr_dis_exit:
+.endm
 
 .macro at91_pm_ulp0_mode
 	ldr	pmc, .pmc_base
@@ -503,7 +552,7 @@ ENDPROC(at91_backup_mode)
 2:
 .endm
 
-ENTRY(at91_ulp_mode)
+.macro at91_ulp_mode
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
 	ldr	tmp3, .pm_mode
@@ -552,133 +601,97 @@ ulp_exit:
 
 	wait_mckrdy
 
-	mov	pc, lr
-ENDPROC(at91_ulp_mode)
-
-/*
- * void at91_sramc_self_refresh(unsigned int is_active)
- *
- * @input param:
- *	@r0: 1 - active self-refresh mode
- *	     0 - exit self-refresh mode
- * register usage:
- * 	@r1: memory type
- *	@r2: base address of the sram controller
- */
-
-ENTRY(at91_sramc_self_refresh)
-	ldr	r1, .memtype
-	ldr	r2, .sramc_base
-
-	cmp	r1, #AT91_MEMCTRL_MC
-	bne	ddrc_sf
-
-	/*
-	 * at91rm9200 Memory controller
-	 */
-
-	 /*
-	  * For exiting the self-refresh mode, do nothing,
-	  * automatically exit the self-refresh mode.
-	  */
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	exit_sramc_sf
-
-	/* Active SDRAM self-refresh mode */
-	mov	r3, #1
-	str	r3, [r2, #AT91_MC_SDRAMC_SRR]
-	b	exit_sramc_sf
-
-ddrc_sf:
-	cmp	r1, #AT91_MEMCTRL_DDRSDR
-	bne	sdramc_sf
+.endm
 
-	/*
-	 * DDR Memory controller
-	 */
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	ddrc_exit_sf
+.macro at91_backup_mode
+	/* Switch the master clock source to slow clock. */
+	ldr	pmc, .pmc_base
+	ldr	tmp2, .mckr_offset
+	ldr	tmp1, [pmc, tmp2]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	str	tmp1, [pmc, tmp2]
 
-	/* LPDDR1 --> force DDR2 mode during self-refresh */
-	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
-	str	r3, .saved_sam9_mdr
-	bic	r3, r3, #~AT91_DDRSDRC_MD
-	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
-	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
-	biceq	r3, r3, #AT91_DDRSDRC_MD
-	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
-	streq	r3, [r2, #AT91_DDRSDRC_MDR]
+	wait_mckrdy
 
-	/* Active DDRC self-refresh mode */
-	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
-	str	r3, .saved_sam9_lpr
-	bic	r3, r3, #AT91_DDRSDRC_LPCB
-	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/*BUMEN*/
+	ldr	r0, .sfrbu
+	mov	tmp1, #0x1
+	str	tmp1, [r0, #0x10]
 
-	/* If using the 2nd ddr controller */
-	ldr	r2, .sramc1_base
-	cmp	r2, #0
-	beq	no_2nd_ddrc
+	/* Shutdown */
+	ldr	r0, .shdwc
+	mov	tmp1, #0xA5000000
+	add	tmp1, tmp1, #0x1
+	str	tmp1, [r0, #0]
+.endm
 
-	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
-	str	r3, .saved_sam9_mdr1
-	bic	r3, r3, #~AT91_DDRSDRC_MD
-	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
-	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
-	biceq	r3, r3, #AT91_DDRSDRC_MD
-	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
-	streq	r3, [r2, #AT91_DDRSDRC_MDR]
+/*
+ * void at91_suspend_sram_fn(struct at91_pm_data*)
+ * @input param:
+ * 	@r0: base address of struct at91_pm_data
+ */
+/* at91_pm_suspend_in_sram must be 8-byte aligned per the requirements of fncpy() */
+	.align 3
+ENTRY(at91_pm_suspend_in_sram)
+	/* Save registers on stack */
+	stmfd	sp!, {r4 - r12, lr}
 
-	/* Active DDRC self-refresh mode */
-	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
-	str	r3, .saved_sam9_lpr1
-	bic	r3, r3, #AT91_DDRSDRC_LPCB
-	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/* Drain write buffer */
+	mov	tmp1, #0
+	mcr	p15, 0, tmp1, c7, c10, 4
 
-no_2nd_ddrc:
-	b	exit_sramc_sf
+	ldr	tmp1, [r0, #PM_DATA_PMC]
+	str	tmp1, .pmc_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC0]
+	str	tmp1, .sramc_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC1]
+	str	tmp1, .sramc1_base
+	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
+	str	tmp1, .memtype
+	ldr	tmp1, [r0, #PM_DATA_MODE]
+	str	tmp1, .pm_mode
+	ldr	tmp1, [r0, #PM_DATA_PMC_MCKR_OFFSET]
+	str	tmp1, .mckr_offset
+	ldr	tmp1, [r0, #PM_DATA_PMC_VERSION]
+	str	tmp1, .pmc_version
+	/* Both ldrne below are here to preload their address in the TLB */
+	ldr	tmp1, [r0, #PM_DATA_SHDWC]
+	str	tmp1, .shdwc
+	cmp	tmp1, #0
+	ldrne	tmp2, [tmp1, #0]
+	ldr	tmp1, [r0, #PM_DATA_SFRBU]
+	str	tmp1, .sfrbu
+	cmp	tmp1, #0
+	ldrne	tmp2, [tmp1, #0x10]
 
-ddrc_exit_sf:
-	/* Restore MDR in case of LPDDR1 */
-	ldr	r3, .saved_sam9_mdr
-	str	r3, [r2, #AT91_DDRSDRC_MDR]
-	/* Restore LPR on AT91 with DDRAM */
-	ldr	r3, .saved_sam9_lpr
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/* Active the self-refresh mode */
+	at91_sramc_self_refresh_ena
 
-	/* If using the 2nd ddr controller */
-	ldr	r2, .sramc1_base
-	cmp	r2, #0
-	ldrne	r3, .saved_sam9_mdr1
-	strne	r3, [r2, #AT91_DDRSDRC_MDR]
-	ldrne	r3, .saved_sam9_lpr1
-	strne	r3, [r2, #AT91_DDRSDRC_LPR]
+	ldr	r0, .pm_mode
+	cmp	r0, #AT91_PM_STANDBY
+	beq	standby
+	cmp	r0, #AT91_PM_BACKUP
+	beq	backup_mode
 
-	b	exit_sramc_sf
+	at91_ulp_mode
+	b	exit_suspend
 
-	/*
-	 * SDRAMC Memory controller
-	 */
-sdramc_sf:
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	sdramc_exit_sf
+standby:
+	/* Wait for interrupt */
+	ldr	pmc, .pmc_base
+	at91_cpu_idle
+	b	exit_suspend
 
-	/* Active SDRAMC self-refresh mode */
-	ldr	r3, [r2, #AT91_SDRAMC_LPR]
-	str	r3, .saved_sam9_lpr
-	bic	r3, r3, #AT91_SDRAMC_LPCB
-	orr	r3, r3, #AT91_SDRAMC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_SDRAMC_LPR]
+backup_mode:
+	at91_backup_mode
 
-sdramc_exit_sf:
-	ldr	r3, .saved_sam9_lpr
-	str	r3, [r2, #AT91_SDRAMC_LPR]
+exit_suspend:
+	/* Exit the self-refresh mode */
+	at91_sramc_self_refresh_dis
 
-exit_sramc_sf:
-	mov	pc, lr
-ENDPROC(at91_sramc_self_refresh)
+	/* Restore registers, and return */
+	ldmfd	sp!, {r4 - r12, pc}
+ENDPROC(at91_pm_suspend_in_sram)
 
 .pmc_base:
 	.word 0
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:31 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:31 +0300
Subject: [PATCH v2 10/24] ARM: at91: sfrbu: add sfrbu registers definitions
 for sama7g5
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-11-claudiu.beznea@microchip.com>

Add SFRBU registers definitions for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 include/soc/at91/sama7-sfrbu.h | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 include/soc/at91/sama7-sfrbu.h

diff --git a/include/soc/at91/sama7-sfrbu.h b/include/soc/at91/sama7-sfrbu.h
new file mode 100644
index 000000000000..76b740810d34
--- /dev/null
+++ b/include/soc/at91/sama7-sfrbu.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SAMA7 SFRBU registers offsets and bit definitions.
+ *
+ * Copyright (C) [2020] Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudu Beznea <claudiu.beznea at microchip.com>
+ */
+
+#ifndef __SAMA7_SFRBU_H__
+#define __SAMA7_SFRBU_H__
+
+#ifdef CONFIG_SOC_SAMA7
+
+#define AT91_SFRBU_PSWBU			(0x00)		/* SFRBU Power Switch BU Control Register */
+#define		AT91_SFRBU_PSWBU_PSWKEY		(0x4BD20C << 8)	/* Specific value mandatory to allow writing of other register bits */
+#define		AT91_SFRBU_PSWBU_STATE		(1 << 2)	/* Power switch BU state */
+#define		AT91_SFRBU_PSWBU_SOFTSWITCH	(1 << 1)	/* Power switch BU source selection */
+#define		AT91_SFRBU_PSWBU_CTRL		(1 << 0)	/* Power switch BU control */
+
+#define AT91_SFRBU_25LDOCR			(0x0C)		/* SFRBU 2.5V LDO Control Register */
+#define		AT91_SFRBU_25LDOCR_LDOANAKEY	(0x3B6E18 << 8)	/* Specific value mandatory to allow writing of other register bits. */
+#define		AT91_SFRBU_25LDOCR_STATE	(1 << 3)	/* LDOANA Switch On/Off Control */
+#define		AT91_SFRBU_25LDOCR_LP		(1 << 2)	/* LDOANA Low-Power Mode Control */
+#define		AT91_SFRBU_PD_VALUE_MSK		(0x3)
+#define		AT91_SFRBU_25LDOCR_PD_VALUE(v)	((v) & AT91_SFRBU_PD_VALUE_MSK)	/* LDOANA Pull-down value */
+
+#define AT91_FRBU_DDRPWR			(0x10)		/* SFRBU DDR Power Control Register */
+#define		AT91_FRBU_DDRPWR_STATE		(1 << 0)	/* DDR Power Mode State */
+
+#endif /* CONFIG_SOC_SAMA7 */
+
+#endif /* __SAMA7_SFRBU_H__ */
+
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:30 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:30 +0300
Subject: [PATCH v2 09/24] ARM: at91: pm: add support for waiting MCK1..4
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-10-claudiu.beznea@microchip.com>

SAMA7G5 has 5 master clocks 0..4. MCK0 is controlled differently than
MCK 1..4. MCK 1..4 should also be saved/restored in the last phase of
suspend/resume. Thus, adapt wait_mckrdy to support also MCK1..4.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 48 ++++++++++++++++++++++++---------
 1 file changed, 35 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 1f63bbfad728..7669b32d5257 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -22,11 +22,23 @@ tmp3	.req	r6
 
 /*
  * Wait until master clock is ready (after switching master clock source)
+ *
+ * @r_mckid:	register holding master clock identifier
+ *
+ * Side effects: overwrites r7, r8
  */
-	.macro wait_mckrdy
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MCKRDY
-	beq	1b
+	.macro wait_mckrdy r_mckid
+#ifdef CONFIG_SOC_SAMA7
+	cmp	\r_mckid, #0
+	beq	1f
+	mov	r7, #AT91_PMC_MCKXRDY
+	b	2f
+#endif
+1:	mov	r7, #AT91_PMC_MCKRDY
+2:	ldr	r8, [pmc, #AT91_PMC_SR]
+	and	r8, r7
+	cmp	r8, r7
+	bne	2b
 	.endm
 
 /*
@@ -231,7 +243,9 @@ sr_dis_exit:
 	bic	tmp1, tmp1, #AT91_PMC_PRES
 	orr	tmp1, tmp1, #AT91_PMC_PRES_64
 	str	tmp1, [pmc, tmp3]
-	wait_mckrdy
+
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 	b	1f
 
 0:
@@ -267,10 +281,13 @@ sr_dis_exit:
 	bne	5f
 
 	/* Set lowest prescaler for fast resume. */
+	ldr	tmp3, .mckr_offset
 	ldr	tmp1, [pmc, tmp3]
 	bic	tmp1, tmp1, #AT91_PMC_PRES
 	str	tmp1, [pmc, tmp3]
-	wait_mckrdy
+
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 	b	6f
 
 5:	/* Restore RC oscillator state */
@@ -307,6 +324,7 @@ sr_dis_exit:
 .macro at91_pm_ulp1_mode
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
+	mov	tmp3, #0
 
 	/* Save RC oscillator state and check if it is enabled. */
 	ldr	tmp1, [pmc, #AT91_PMC_SR]
@@ -348,7 +366,7 @@ sr_dis_exit:
 	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Enter the ULP1 mode by set WAITMODE bit in CKGR_MOR */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -361,7 +379,7 @@ sr_dis_exit:
 	nop
 	nop
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Enable the crystal oscillator */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -377,7 +395,7 @@ sr_dis_exit:
 	bic	tmp1, tmp1, #AT91_PMC_CSS
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Switch main clock source to crystal oscillator */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -394,7 +412,7 @@ sr_dis_exit:
 	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Restore RC oscillator state */
 	ldr	tmp1, .saved_osc_status
@@ -573,10 +591,12 @@ sr_dis_exit:
 save_mck:
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 	at91_plla_disable
 
+	ldr	tmp3, .pm_mode
 	cmp	tmp3, #AT91_PM_ULP1
 	beq	ulp1_mode
 
@@ -599,7 +619,8 @@ ulp_exit:
 	ldr	tmp2, .saved_mckr
 	str	tmp2, [pmc, tmp1]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 .endm
 
@@ -611,7 +632,8 @@ ulp_exit:
 	bic	tmp1, tmp1, #AT91_PMC_CSS
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 	/*BUMEN*/
 	ldr	r0, .sfrbu
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:32 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:32 +0300
Subject: [PATCH v2 11/24] ARM: at91: ddr: add registers definitions for
 sama7g5's ddr
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-12-claudiu.beznea@microchip.com>

Add registers and bits definitions for SAMA7G5's UDDRC and DDR3PHY.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 include/soc/at91/sama7-ddr.h | 80 ++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 include/soc/at91/sama7-ddr.h

diff --git a/include/soc/at91/sama7-ddr.h b/include/soc/at91/sama7-ddr.h
new file mode 100644
index 000000000000..f6542584ca13
--- /dev/null
+++ b/include/soc/at91/sama7-ddr.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SAMA7 UDDR Controller and DDR3 PHY Controller registers offsets
+ * and bit definitions.
+ *
+ * Copyright (C) [2020] Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudu Beznea <claudiu.beznea at microchip.com>
+ */
+
+#ifndef __SAMA7_DDR_H__
+#define __SAMA7_DDR_H__
+
+#ifdef CONFIG_SOC_SAMA7
+
+/* DDR3PHY */
+#define DDR3PHY_PIR				(0x04)		/* DDR3PHY PHY Initialization Register	*/
+#define	DDR3PHY_PIR_DLLBYP		(1 << 17)	/* DLL Bypass */
+#define		DDR3PHY_PIR_ITMSRST		(1 << 4)	/* Interface Timing Module Soft Reset */
+#define	DDR3PHY_PIR_DLLLOCK		(1 << 2)	/* DLL Lock */
+#define		DDR3PHY_PIR_DLLSRST		(1 << 1)	/* DLL Soft Rest */
+#define	DDR3PHY_PIR_INIT		(1 << 0)	/* Initialization Trigger */
+
+#define DDR3PHY_PGCR				(0x08)		/* DDR3PHY PHY General Configuration Register */
+#define		DDR3PHY_PGCR_CKDV1		(1 << 13)	/* CK# Disable Value */
+#define		DDR3PHY_PGCR_CKDV0		(1 << 12)	/* CK Disable Value */
+
+#define	DDR3PHY_PGSR				(0x0C)		/* DDR3PHY PHY General Status Register */
+#define		DDR3PHY_PGSR_IDONE		(1 << 0)	/* Initialization Done */
+
+#define DDR3PHY_ACIOCR				(0x24)		/*  DDR3PHY AC I/O Configuration Register */
+#define		DDR3PHY_ACIOCR_CSPDD_CS0	(1 << 18)	/* CS#[0] Power Down Driver */
+#define		DDR3PHY_ACIOCR_CKPDD_CK0	(1 << 8)	/* CK[0] Power Down Driver */
+#define		DDR3PHY_ACIORC_ACPDD		(1 << 3)	/* AC Power Down Driver */
+
+#define DDR3PHY_DXCCR				(0x28)		/* DDR3PHY DATX8 Common Configuration Register */
+#define		DDR3PHY_DXCCR_DXPDR		(1 << 3)	/* Data Power Down Receiver */
+
+#define DDR3PHY_DSGCR				(0x2C)		/* DDR3PHY DDR System General Configuration Register */
+#define		DDR3PHY_DSGCR_ODTPDD_ODT0	(1 << 20)	/* ODT[0] Power Down Driver */
+
+#define DDR3PHY_ZQ0SR0				(0x188)		/* ZQ status register 0 */
+
+/* UDDRC */
+#define UDDRC_STAT				(0x04)		/* UDDRC Operating Mode Status Register */
+#define		UDDRC_STAT_SELFREF_TYPE_DIS	(0x0 << 4)	/* SDRAM is not in Self-refresh */
+#define		UDDRC_STAT_SELFREF_TYPE_PHY	(0x1 << 4)	/* SDRAM is in Self-refresh, which was caused by PHY Master Request */
+#define		UDDRC_STAT_SELFREF_TYPE_SW	(0x2 << 4)	/* SDRAM is in Self-refresh, which was not caused solely under Automatic Self-refresh control */
+#define		UDDRC_STAT_SELFREF_TYPE_AUTO	(0x3 << 4)	/* SDRAM is in Self-refresh, which was caused by Automatic Self-refresh only */
+#define		UDDRC_STAT_SELFREF_TYPE_MSK	(0x3 << 4)	/* Self-refresh type mask */
+#define		UDDRC_STAT_OPMODE_INIT		(0x0 << 0)	/* Init */
+#define		UDDRC_STAT_OPMODE_NORMAL	(0x1 << 0)	/* Normal */
+#define		UDDRC_STAT_OPMODE_PWRDOWN	(0x2 << 0)	/* Power-down */
+#define		UDDRC_STAT_OPMODE_SELF_REFRESH	(0x3 << 0)	/* Self-refresh */
+#define		UDDRC_STAT_OPMODE_MSK		(0x7 << 0)	/* Operating mode mask */
+
+#define UDDRC_PWRCTL				(0x30)		/* UDDRC Low Power Control Register */
+#define		UDDRC_PWRCTRL_SELFREF_SW	(1 << 5)	/* Software self-refresh */
+
+#define UDDRC_DFIMISC				(0x1B0)		/* UDDRC DFI Miscellaneous Control Register */
+#define		UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN (1 << 0)	/* PHY initialization complete enable signal */
+
+#define UDDRC_SWCTRL				(0x320)		/* UDDRC Software Register Programming Control Enable */
+#define		UDDRC_SWCTRL_SW_DONE		(1 << 0)	/* Enable quasi-dynamic register programming outside reset */
+
+#define UDDRC_SWSTAT				(0x324)		/* UDDRC Software Register Programming Control Status */
+#define		UDDRC_SWSTAT_SW_DONE_ACK	(1 << 0)	/* Register programming done */
+
+#define UDDRC_PSTAT				(0x3FC)		/* UDDRC Port Status Register */
+#define	UDDRC_PSTAT_ALL_PORTS		(0x1F001F)	/* Read + writes outstanding transactions on all ports */
+
+#define UDDRC_PCTRL_0				(0x490)		/* UDDRC Port 0 Control Register */
+#define UDDRC_PCTRL_1				(0x540)		/* UDDRC Port 1 Control Register */
+#define UDDRC_PCTRL_2				(0x5F0)		/* UDDRC Port 2 Control Register */
+#define UDDRC_PCTRL_3				(0x6A0)		/* UDDRC Port 3 Control Register */
+#define UDDRC_PCTRL_4				(0x750)		/* UDDRC Port 4 Control Register */
+
+#endif /* CONFIG_SOC_SAMA7 */
+
+#endif /* __SAMA7_DDR_H__ */
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:29 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:29 +0300
Subject: [PATCH v2 08/24] ARM: at91: pm:
 s/CONFIG_SOC_SAM9X60/CONFIG_HAVE_AT91_SAM9X60_PLL/g
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-9-claudiu.beznea@microchip.com>

Replace CONFIG_SOC_SAM9X60 with CONFIG_HAVE_AT91_SAM9X60_PLL as the
SAM9X60's PLL is also present on SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 960ad29cce51..1f63bbfad728 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -422,7 +422,7 @@ sr_dis_exit:
 	cmp	tmp1, #AT91_PMC_V1
 	beq	1f
 
-#ifdef CONFIG_SOC_SAM9X60
+#ifdef CONFIG_HAVE_AT91_SAM9X60_PLL
 	/* Save PLLA settings. */
 	ldr	tmp2, [pmc, #AT91_PMC_PLL_UPDT]
 	bic	tmp2, tmp2, #AT91_PMC_PLL_UPDT_ID
@@ -489,7 +489,7 @@ sr_dis_exit:
 	cmp	tmp3, #AT91_PMC_V1
 	beq	4f
 
-#ifdef CONFIG_SOC_SAM9X60
+#ifdef CONFIG_HAVE_AT91_SAM9X60_PLL
 	/* step 1. */
 	ldr	tmp1, [pmc, #AT91_PMC_PLL_UPDT]
 	bic	tmp1, tmp1, #AT91_PMC_PLL_UPDT_ID
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:33 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:33 +0300
Subject: [PATCH v2 12/24] ARM: at91: pm: add self-refresh support for sama7g5
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-13-claudiu.beznea@microchip.com>

Add self-refresh support for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.h              |   2 +
 arch/arm/mach-at91/pm_data-offsets.c |   2 +
 arch/arm/mach-at91/pm_suspend.S      | 199 +++++++++++++++++++++++++++
 3 files changed, 203 insertions(+)

diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index bfb260be371e..666474088d55 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -12,6 +12,7 @@
 #include <linux/mfd/syscon/atmel-mc.h>
 #include <soc/at91/at91sam9_ddrsdr.h>
 #include <soc/at91/at91sam9_sdramc.h>
+#include <soc/at91/sama7-ddr.h>
 
 #define AT91_MEMCTRL_MC		0
 #define AT91_MEMCTRL_SDRAMC	1
@@ -27,6 +28,7 @@
 struct at91_pm_data {
 	void __iomem *pmc;
 	void __iomem *ramc[2];
+	void __iomem *ramc_phy;
 	unsigned long uhp_udp_mask;
 	unsigned int memctrl;
 	unsigned int mode;
diff --git a/arch/arm/mach-at91/pm_data-offsets.c b/arch/arm/mach-at91/pm_data-offsets.c
index 82089ff258c0..40bd4e8fe40a 100644
--- a/arch/arm/mach-at91/pm_data-offsets.c
+++ b/arch/arm/mach-at91/pm_data-offsets.c
@@ -8,6 +8,8 @@ int main(void)
 	DEFINE(PM_DATA_PMC,		offsetof(struct at91_pm_data, pmc));
 	DEFINE(PM_DATA_RAMC0,		offsetof(struct at91_pm_data, ramc[0]));
 	DEFINE(PM_DATA_RAMC1,		offsetof(struct at91_pm_data, ramc[1]));
+	DEFINE(PM_DATA_RAMC_PHY,	offsetof(struct at91_pm_data,
+						 ramc_phy));
 	DEFINE(PM_DATA_MEMCTRL,	offsetof(struct at91_pm_data, memctrl));
 	DEFINE(PM_DATA_MODE,		offsetof(struct at91_pm_data, mode));
 	DEFINE(PM_DATA_SHDWC,		offsetof(struct at91_pm_data, shdwc));
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 7669b32d5257..84418120ba67 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -87,6 +87,200 @@ tmp3	.req	r6
 
 	.arm
 
+#ifdef CONFIG_SOC_SAMA7
+/**
+ * Enable self-refresh
+ *
+ * Side effects: overwrites r2, r3, tmp1, tmp2, tmp3, r7
+ */
+.macro at91_sramc_self_refresh_ena
+	ldr	r2, .sramc_base
+	ldr	r3, .sramc_phy_base
+	ldr	r7, .pm_mode
+
+	dsb
+
+	/* Disable all AXI ports. */
+	ldr	tmp1, [r2, #UDDRC_PCTRL_0]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_0]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_1]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_1]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_2]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_2]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_3]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_3]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_4]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_4]
+
+sr_ena_1:
+	/* Wait for all ports to disable. */
+	ldr	tmp1, [r2, #UDDRC_PSTAT]
+	ldr	tmp2, =UDDRC_PSTAT_ALL_PORTS
+	tst	tmp1, tmp2
+	bne	sr_ena_1
+
+	/* Switch to self-refresh. */
+	ldr	tmp1, [r2, #UDDRC_PWRCTL]
+	orr	tmp1, tmp1, #UDDRC_PWRCTRL_SELFREF_SW
+	str	tmp1, [r2, #UDDRC_PWRCTL]
+
+sr_ena_2:
+	/* Wait for self-refresh enter. */
+	ldr	tmp1, [r2, #UDDRC_STAT]
+	bic	tmp1, tmp1, #~UDDRC_STAT_SELFREF_TYPE_MSK
+	cmp	tmp1, #UDDRC_STAT_SELFREF_TYPE_SW
+	bne	sr_ena_2
+
+	/* Put DDR PHY's DLL in bypass mode for non-backup modes. */
+	cmp	r7, #AT91_PM_BACKUP
+	beq	sr_ena_3
+	ldr	tmp1, [r3, #DDR3PHY_PIR]
+	orr	tmp1, tmp1, #DDR3PHY_PIR_DLLBYP
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+sr_ena_3:
+	/* Power down DDR PHY data receivers. */
+	ldr	tmp1, [r3, #DDR3PHY_DXCCR]
+	orr	tmp1, tmp1, #DDR3PHY_DXCCR_DXPDR
+	str	tmp1, [r3, #DDR3PHY_DXCCR]
+
+	/* Power down ADDR/CMD IO. */
+	ldr	tmp1, [r3, #DDR3PHY_ACIOCR]
+	orr	tmp1, tmp1, #DDR3PHY_ACIORC_ACPDD
+	orr	tmp1, tmp1, #DDR3PHY_ACIOCR_CKPDD_CK0
+	orr	tmp1, tmp1, #DDR3PHY_ACIOCR_CSPDD_CS0
+	str	tmp1, [r3, #DDR3PHY_ACIOCR]
+
+	/* Power down ODT. */
+	ldr	tmp1, [r3, #DDR3PHY_DSGCR]
+	orr	tmp1, tmp1, #DDR3PHY_DSGCR_ODTPDD_ODT0
+	str	tmp1, [r3, #DDR3PHY_DSGCR]
+.endm
+
+/**
+ * Disable self-refresh
+ *
+ * Side effects: overwrites r2, r3, tmp1, tmp2, tmp3
+ */
+.macro at91_sramc_self_refresh_dis
+	ldr	r2, .sramc_base
+	ldr	r3, .sramc_phy_base
+
+	/* Power up DDR PHY data receivers. */
+	ldr	tmp1, [r3, #DDR3PHY_DXCCR]
+	bic	tmp1, tmp1, #DDR3PHY_DXCCR_DXPDR
+	str	tmp1, [r3, #DDR3PHY_DXCCR]
+
+	/* Power up the output of CK and CS pins. */
+	ldr	tmp1, [r3, #DDR3PHY_ACIOCR]
+	bic	tmp1, tmp1, #DDR3PHY_ACIORC_ACPDD
+	bic	tmp1, tmp1, #DDR3PHY_ACIOCR_CKPDD_CK0
+	bic	tmp1, tmp1, #DDR3PHY_ACIOCR_CSPDD_CS0
+	str	tmp1, [r3, #DDR3PHY_ACIOCR]
+
+	/* Power up ODT. */
+	ldr	tmp1, [r3, #DDR3PHY_DSGCR]
+	bic	tmp1, tmp1, #DDR3PHY_DSGCR_ODTPDD_ODT0
+	str	tmp1, [r3, #DDR3PHY_DSGCR]
+
+	/* Take DDR PHY's DLL out of bypass mode. */
+	ldr	tmp1, [r3, #DDR3PHY_PIR]
+	bic	tmp1, tmp1, #DDR3PHY_PIR_DLLBYP
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+	/* Enable quasi-dynamic programming. */
+	mov	tmp1, #0
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+	/* De-assert SDRAM initialization. */
+	ldr	tmp1, [r2, #UDDRC_DFIMISC]
+	bic	tmp1, tmp1, #UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN
+	str	tmp1, [r2, #UDDRC_DFIMISC]
+
+	/* Quasi-dynamic programming done. */
+	mov	tmp1, #UDDRC_SWCTRL_SW_DONE
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+sr_dis_1:
+	ldr	tmp1, [r2, #UDDRC_SWSTAT]
+	tst	tmp1, #UDDRC_SWSTAT_SW_DONE_ACK
+	beq	sr_dis_1
+
+	/* DLL soft-reset + DLL lock wait + ITM reset */
+	mov	tmp1, #(DDR3PHY_PIR_INIT | DDR3PHY_PIR_DLLSRST | \
+			DDR3PHY_PIR_DLLLOCK | DDR3PHY_PIR_ITMSRST)
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+sr_dis_4:
+	/* Wait for it. */
+	ldr	tmp1, [r3, #DDR3PHY_PGSR]
+	tst	tmp1, #DDR3PHY_PGSR_IDONE
+	beq	sr_dis_4
+
+	/* Enable quasi-dynamic programming. */
+	mov	tmp1, #0
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+	/* Assert PHY init complete enable signal. */
+	ldr	tmp1, [r2, #UDDRC_DFIMISC]
+	orr	tmp1, tmp1, #UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN
+	str	tmp1, [r2, #UDDRC_DFIMISC]
+
+	/* Programming is done. Set sw_done. */
+	mov	tmp1, #UDDRC_SWCTRL_SW_DONE
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+sr_dis_5:
+	/* Wait for it. */
+	ldr	tmp1, [r2, #UDDRC_SWSTAT]
+	tst	tmp1, #UDDRC_SWSTAT_SW_DONE_ACK
+	beq	sr_dis_5
+
+	/* Trigger self-refresh exit. */
+	ldr	tmp1, [r2, #UDDRC_PWRCTL]
+	bic	tmp1, tmp1, #UDDRC_PWRCTRL_SELFREF_SW
+	str	tmp1, [r2, #UDDRC_PWRCTL]
+
+sr_dis_6:
+	/* Wait for self-refresh exit done. */
+	ldr	tmp1, [r2, #UDDRC_STAT]
+	bic	tmp1, tmp1, #~UDDRC_STAT_OPMODE_MSK
+	cmp	tmp1, #UDDRC_STAT_OPMODE_NORMAL
+	bne	sr_dis_6
+
+	/* Enable all AXI ports. */
+	ldr	tmp1, [r2, #UDDRC_PCTRL_0]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_0]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_1]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_1]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_2]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_2]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_3]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_3]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_4]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_4]
+
+	dsb
+.endm
+#else
 /**
  * Enable self-refresh
  *
@@ -228,6 +422,7 @@ sdramc_exit_sf:
 
 sr_dis_exit:
 .endm
+#endif
 
 .macro at91_pm_ulp0_mode
 	ldr	pmc, .pmc_base
@@ -668,6 +863,8 @@ ENTRY(at91_pm_suspend_in_sram)
 	str	tmp1, .sramc_base
 	ldr	tmp1, [r0, #PM_DATA_RAMC1]
 	str	tmp1, .sramc1_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC_PHY]
+	str	tmp1, .sramc_phy_base
 	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
 	str	tmp1, .memtype
 	ldr	tmp1, [r0, #PM_DATA_MODE]
@@ -721,6 +918,8 @@ ENDPROC(at91_pm_suspend_in_sram)
 	.word 0
 .sramc1_base:
 	.word 0
+.sramc_phy_base:
+	.word 0
 .shdwc:
 	.word 0
 .sfrbu:
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:34 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:34 +0300
Subject: [PATCH v2 13/24] ARM: at91: pm: add support for MCK1..4 save/restore
 for ulp modes
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-14-claudiu.beznea@microchip.com>

Add support for MCK1..4 save restore for ULP modes.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 126 ++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 84418120ba67..8b0b8619ee8a 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -765,7 +765,122 @@ sr_dis_exit:
 2:
 .endm
 
+/**
+ * at91_mckx_ps_enable:	save MCK1..4 settings and switch it to main clock
+ *
+ * Side effects: overwrites tmp1, tmp2
+ */
+.macro at91_mckx_ps_enable
+#ifdef CONFIG_SOC_SAMA7
+	ldr	pmc, .pmc_base
+
+	/* There are 4 MCKs we need to handle: MCK1..4 */
+	mov	tmp1, #1
+e_loop:	cmp	tmp1, #5
+	beq	e_done
+
+	/* Write MCK ID to retrieve the settings. */
+	str	tmp1, [pmc, #AT91_PMC_MCR_V2]
+	ldr	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+e_save_mck1:
+	cmp	tmp1, #1
+	bne	e_save_mck2
+	str	tmp2, .saved_mck1
+	b	e_ps
+
+e_save_mck2:
+	cmp	tmp1, #2
+	bne	e_save_mck3
+	str	tmp2, .saved_mck2
+	b	e_ps
+
+e_save_mck3:
+	cmp	tmp1, #3
+	bne	e_save_mck4
+	str	tmp2, .saved_mck3
+	b	e_ps
+
+e_save_mck4:
+	str	tmp2, .saved_mck4
+
+e_ps:
+	/* Use CSS=MAINCK and DIV=1. */
+	bic	tmp2, tmp2, #AT91_PMC_MCR_V2_CSS
+	bic	tmp2, tmp2, #AT91_PMC_MCR_V2_DIV
+	orr	tmp2, tmp2, #AT91_PMC_MCR_V2_CSS_MAINCK
+	orr	tmp2, tmp2, #AT91_PMC_MCR_V2_DIV1
+	str	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+	wait_mckrdy tmp1
+
+	add	tmp1, tmp1, #1
+	b	e_loop
+
+e_done:
+#endif
+.endm
+
+/**
+ * at91_mckx_ps_restore: restore MCK1..4 settings
+ *
+ * Side effects: overwrites tmp1, tmp2
+ */
+.macro at91_mckx_ps_restore
+#ifdef CONFIG_SOC_SAMA7
+	ldr	pmc, .pmc_base
+
+	/* There are 4 MCKs we need to handle: MCK1..4 */
+	mov	tmp1, #1
+r_loop:	cmp	tmp1, #5
+	beq	r_done
+
+r_save_mck1:
+	cmp	tmp1, #1
+	bne	r_save_mck2
+	ldr	tmp2, .saved_mck1
+	b	r_ps
+
+r_save_mck2:
+	cmp	tmp1, #2
+	bne	r_save_mck3
+	ldr	tmp2, .saved_mck2
+	b	r_ps
+
+r_save_mck3:
+	cmp	tmp1, #3
+	bne	r_save_mck4
+	ldr	tmp2, .saved_mck3
+	b	r_ps
+
+r_save_mck4:
+	ldr	tmp2, .saved_mck4
+
+r_ps:
+	/* Write MCK ID to retrieve the settings. */
+	str	tmp1, [pmc, #AT91_PMC_MCR_V2]
+	ldr	tmp3, [pmc, #AT91_PMC_MCR_V2]
+
+	/* We need to restore CSS and DIV. */
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_CSS
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_DIV
+	orr	tmp3, tmp3, tmp2
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_ID_MSK
+	orr	tmp3, tmp3, tmp1
+	orr	tmp3, tmp3, #AT91_PMC_MCR_V2_CMD
+	str	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+	wait_mckrdy tmp1
+
+	add	tmp1, tmp1, #1
+	b	r_loop
+r_done:
+#endif
+.endm
+
 .macro at91_ulp_mode
+	at91_mckx_ps_enable
+
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
 	ldr	tmp3, .pm_mode
@@ -817,6 +932,7 @@ ulp_exit:
 	mov	tmp3, #0
 	wait_mckrdy tmp3
 
+	at91_mckx_ps_restore
 .endm
 
 .macro at91_backup_mode
@@ -946,6 +1062,16 @@ ENDPROC(at91_pm_suspend_in_sram)
 	.word 0
 .saved_osc_status:
 	.word 0
+#ifdef CONFIG_SOC_SAMA7
+.saved_mck1:
+	.word 0
+.saved_mck2:
+	.word 0
+.saved_mck3:
+	.word 0
+.saved_mck4:
+	.word 0
+#endif
 
 ENTRY(at91_pm_suspend_in_sram_sz)
 	.word .-at91_pm_suspend_in_sram
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:35 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:35 +0300
Subject: [PATCH v2 14/24] ARM: at91: pm: add support for 2.5V LDO regulator
 control
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-15-claudiu.beznea@microchip.com>

Add support to disable/enable 2.5V LDO regulator when entering/exiting
any ULP mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.h         |  1 +
 arch/arm/mach-at91/pm_suspend.S | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 666474088d55..53bdc9000e44 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -13,6 +13,7 @@
 #include <soc/at91/at91sam9_ddrsdr.h>
 #include <soc/at91/at91sam9_sdramc.h>
 #include <soc/at91/sama7-ddr.h>
+#include <soc/at91/sama7-sfrbu.h>
 
 #define AT91_MEMCTRL_MC		0
 #define AT91_MEMCTRL_SDRAMC	1
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 8b0b8619ee8a..9c9e08fd8300 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -83,6 +83,29 @@ tmp3	.req	r6
 
 	.endm
 
+/**
+ * Set state for 2.5V low power regulator
+ * @ena: 0 - disable regulator
+ *	 1 - enable regulator
+ *
+ * Side effects: overwrites r7, r8, r9, r10
+ */
+	.macro at91_2_5V_reg_set_low_power ena
+#ifdef CONFIG_SOC_SAMA7
+	ldr	r7, .sfrbu
+	mov	r8, #\ena
+	ldr	r9, [r7, #AT91_SFRBU_25LDOCR]
+	orr	r9, r9, #AT91_SFRBU_25LDOCR_LP
+	cmp	r8, #1
+	beq	lp_done_\ena
+	bic	r9, r9, #AT91_SFRBU_25LDOCR_LP
+lp_done_\ena:
+	ldr	r10, =AT91_SFRBU_25LDOCR_LDOANAKEY
+	orr	r9, r9, r10
+	str	r9, [r7, #AT91_SFRBU_25LDOCR]
+#endif
+	.endm
+
 	.text
 
 	.arm
@@ -906,6 +929,9 @@ save_mck:
 
 	at91_plla_disable
 
+	/* Enable low power mode for 2.5V regulator. */
+	at91_2_5V_reg_set_low_power 1
+
 	ldr	tmp3, .pm_mode
 	cmp	tmp3, #AT91_PM_ULP1
 	beq	ulp1_mode
@@ -918,6 +944,9 @@ ulp1_mode:
 	b	ulp_exit
 
 ulp_exit:
+	/* Disable low power mode for 2.5V regulator. */
+	at91_2_5V_reg_set_low_power 0
+
 	ldr	pmc, .pmc_base
 
 	at91_plla_enable
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:36 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:36 +0300
Subject: [PATCH v2 15/24] ARM: at91: pm: wait for ddr power mode off
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-16-claudiu.beznea@microchip.com>

Wait for DDR power mode off before shutting down the core.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 9c9e08fd8300..7396e18dd7e5 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -980,6 +980,11 @@ ulp_exit:
 	mov	tmp1, #0x1
 	str	tmp1, [r0, #0x10]
 
+	/* Wait for it. */
+1:	ldr	tmp1, [r0, #0x10]
+	tst	tmp1, #0x1
+	beq	1b
+
 	/* Shutdown */
 	ldr	r0, .shdwc
 	mov	tmp1, #0xA5000000
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:37 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:37 +0300
Subject: [PATCH v2 16/24] dt-bindings: atmel-sysreg: add bindings for sama7g5
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-17-claudiu.beznea@microchip.com>

Add RAM controller and RAM PHY controller DT bindings.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 .../devicetree/bindings/arm/atmel-sysregs.txt     | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index 807264a78edc..7cd55a760d41 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties:
 			"atmel,at91sam9260-sdramc",
 			"atmel,at91sam9g45-ddramc",
 			"atmel,sama5d3-ddramc",
-			"microchip,sam9x60-ddramc"
+			"microchip,sam9x60-ddramc",
+			"microchip,sama7g5-uddrc"
 - reg: Should contain registers location and length
 
 Examples:
@@ -55,6 +56,18 @@ Examples:
 		reg = <0xffffe800 0x200>;
 	};
 
+RAMC PHY Controller required properties:
+- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
+- reg: Should contain registers location and length
+
+Example:
+
+	ddr3phy: ddr3phy at e3804000 {
+		compatible = "microchip,sama7g5-ddr3phy", "syscon";
+		reg = <0xe3804000 0x1000>;
+		status = "okay";
+};
+
 SHDWC Shutdown Controller
 
 required properties:
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:38 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:38 +0300
Subject: [PATCH v2 17/24] ARM: at91: pm: add sama7g5 ddr controller
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-18-claudiu.beznea@microchip.com>

Add SAMA7G5 DDR controller to the list of DDR controller compatibles.
At the moment there is no standby support. Adapt the code for this.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 65e13769cf50..5dc942a2012d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -548,6 +548,7 @@ static const struct of_device_id ramc_ids[] __initconst = {
 	{ .compatible = "atmel,at91sam9260-sdramc", .data = &ramc_infos[1] },
 	{ .compatible = "atmel,at91sam9g45-ddramc", .data = &ramc_infos[2] },
 	{ .compatible = "atmel,sama5d3-ddramc", .data = &ramc_infos[3] },
+	{ .compatible = "microchip,sama7g5-uddrc", },
 	{ /*sentinel*/ }
 };
 
@@ -565,9 +566,11 @@ static __init void at91_dt_ramc(void)
 			panic(pr_fmt("unable to map ramc[%d] cpu registers\n"), idx);
 
 		ramc = of_id->data;
-		if (!standby)
-			standby = ramc->idle;
-		soc_pm.data.memctrl = ramc->memctrl;
+		if (ramc) {
+			if (!standby)
+				standby = ramc->idle;
+			soc_pm.data.memctrl = ramc->memctrl;
+		}
 
 		idx++;
 	}
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:39 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:39 +0300
Subject: [PATCH v2 18/24] ARM: at91: pm: add sama7g5 ddr phy controller
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-19-claudiu.beznea@microchip.com>

SAMA7G5 self-refresh procedure accesses also the DDR PHY registers.
Adapt the code so that the at91_dt_ramc() to look also for DDR PHYs,
in case it is mandatory.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5dc942a2012d..4dec7216a80e 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -552,7 +552,12 @@ static const struct of_device_id ramc_ids[] __initconst = {
 	{ /*sentinel*/ }
 };
 
-static __init void at91_dt_ramc(void)
+static const struct of_device_id ramc_phy_ids[] __initconst = {
+	{ .compatible = "microchip,sama7g5-ddr3phy", },
+	{ /* Sentinel. */ },
+};
+
+static __init void at91_dt_ramc(bool phy_mandatory)
 {
 	struct device_node *np;
 	const struct of_device_id *of_id;
@@ -578,6 +583,16 @@ static __init void at91_dt_ramc(void)
 	if (!idx)
 		panic(pr_fmt("unable to find compatible ram controller node in dtb\n"));
 
+	/* Lookup for DDR PHY node, if any. */
+	for_each_matching_node_and_match(np, ramc_phy_ids, &of_id) {
+		soc_pm.data.ramc_phy = of_iomap(np, 0);
+		if (!soc_pm.data.ramc_phy)
+			panic(pr_fmt("unable to map ramc phy cpu registers\n"));
+	}
+
+	if (phy_mandatory && !soc_pm.data.ramc_phy)
+		panic(pr_fmt("DDR PHY is mandatory!\n"));
+
 	if (!standby) {
 		pr_warn("ramc no standby function available\n");
 		return;
@@ -936,7 +951,7 @@ void __init at91rm9200_pm_init(void)
 	soc_pm.data.standby_mode = AT91_PM_STANDBY;
 	soc_pm.data.suspend_mode = AT91_PM_ULP0;
 
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 
 	/*
 	 * AT91RM9200 SDRAM low-power mode cannot be used with self-refresh.
@@ -960,7 +975,7 @@ void __init sam9x60_pm_init(void)
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
 	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 
 	soc_pm.ws_ids = sam9x60_ws_ids;
@@ -980,7 +995,7 @@ void __init at91sam9_pm_init(void)
 	soc_pm.data.standby_mode = AT91_PM_STANDBY;
 	soc_pm.data.suspend_mode = AT91_PM_ULP0;
 
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(at91sam9_idle);
 }
 
@@ -994,7 +1009,7 @@ void __init sama5_pm_init(void)
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 }
 
@@ -1015,7 +1030,7 @@ void __init sama5d2_pm_init(void)
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
 	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 
 	soc_pm.ws_ids = sama5d2_ws_ids;
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:40 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:40 +0300
Subject: [PATCH v2 19/24] ARM: at91: pm: save ddr phy calibration data to
 securam
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-20-claudiu.beznea@microchip.com>

The resuming from backup mode is done with the help of bootloader.
The bootloader reconfigure the DDR controller and DDR PHY controller.
To speed-up the resuming process save the PHY calibration data into
SECURAM before suspending (securam is powered on backup mode).
This data will be later used by bootloader in DDR PHY reconfiguration
process. Also, in the process or recalibration the first 8 words of
the memory may get corrupted. To solve this, these 8 words are saved
in the securam and restored by bootloader in the process of PHY
configuration.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 60 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 4dec7216a80e..91b4014d2e10 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -10,6 +10,7 @@
 #include <linux/io.h>
 #include <linux/of_address.h>
 #include <linux/of.h>
+#include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/parser.h>
 #include <linux/suspend.h>
@@ -27,18 +28,23 @@
 #include "generic.h"
 #include "pm.h"
 
+#define BACKUP_DDR_PHY_CALIBRATION	(9)
+
 /**
  * struct at91_pm_bu - AT91 power management backup unit data structure
  * @suspended: true if suspended to backup mode
  * @reserved: reserved
  * @canary: canary data for memory checking after exit from backup mode
  * @resume: resume API
+ * @ddr_phy_calibration: DDR PHY calibration data: ZQ0CR0, first 8 words
+ * of the memory
  */
 struct at91_pm_bu {
 	int suspended;
 	unsigned long reserved;
 	phys_addr_t canary;
 	phys_addr_t resume;
+	unsigned long ddr_phy_calibration[BACKUP_DDR_PHY_CALIBRATION];
 };
 
 /**
@@ -48,6 +54,7 @@ struct at91_pm_bu {
  * @ws_ids: wakup sources of_device_id array
  * @data: PM data to be used on last phase of suspend
  * @bu: backup unit mapped data (for backup mode)
+ * @memcs: memory chip select
  */
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
@@ -55,6 +62,7 @@ struct at91_soc_pm {
 	const struct of_device_id *ws_ids;
 	struct at91_pm_bu *bu;
 	struct at91_pm_data data;
+	void *memcs;
 };
 
 /**
@@ -316,6 +324,19 @@ extern u32 at91_pm_suspend_in_sram_sz;
 
 static int at91_suspend_finish(unsigned long val)
 {
+	int i;
+
+	if (soc_pm.data.mode == AT91_PM_BACKUP && soc_pm.data.ramc_phy) {
+		/*
+		 * The 1st 8 words of memory might get corrupted in the process
+		 * of DDR PHY recalibration; it is saved here in securam and it
+		 * will be restored later, after recalibration, by bootloader
+		 */
+		for (i = 1; i < BACKUP_DDR_PHY_CALIBRATION; i++)
+			soc_pm.bu->ddr_phy_calibration[i] =
+				*((unsigned int *)soc_pm.memcs + (i - 1));
+	}
+
 	flush_cache_all();
 	outer_disable();
 
@@ -673,12 +694,40 @@ static bool __init at91_is_pm_mode_active(int pm_mode)
 		soc_pm.data.suspend_mode == pm_mode);
 }
 
+static int __init at91_pm_backup_scan_memcs(unsigned long node,
+					    const char *uname, int depth,
+					    void *data)
+{
+	const char *type;
+	const __be32 *reg;
+	int *located = data;
+	int size;
+
+	/* Memory node already located. */
+	if (*located)
+		return 0;
+
+	type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	/* We are scanning "memory" nodes only. */
+	if (!type || strcmp(type, "memory"))
+		return 0;
+
+	reg = of_get_flat_dt_prop(node, "reg", &size);
+	if (reg) {
+		soc_pm.memcs = __va((phys_addr_t)be32_to_cpu(*reg));
+		*located = 1;
+	}
+
+	return 0;
+}
+
 static int __init at91_pm_backup_init(void)
 {
 	struct gen_pool *sram_pool;
 	struct device_node *np;
 	struct platform_device *pdev;
-	int ret = -ENODEV;
+	int ret = -ENODEV, located = 0;
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
 		return -EPERM;
@@ -713,6 +762,15 @@ static int __init at91_pm_backup_init(void)
 	soc_pm.bu->suspended = 0;
 	soc_pm.bu->canary = __pa_symbol(&canary);
 	soc_pm.bu->resume = __pa_symbol(cpu_resume);
+	if (soc_pm.data.ramc_phy) {
+		of_scan_flat_dt(at91_pm_backup_scan_memcs, &located);
+		if (!located)
+			goto securam_fail;
+
+		/* DDR3PHY_ZQ0SR0 */
+		soc_pm.bu->ddr_phy_calibration[0] = readl(soc_pm.data.ramc_phy +
+							  0x188);
+	}
 
 	return 0;
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:41 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:41 +0300
Subject: [PATCH v2 20/24] ARM: at91: pm: add backup mode support for SAMA7G5
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-21-claudiu.beznea@microchip.com>

Adapt at91_pm_backup_init() to work for SAMA7G5. Also, set the LPM pin
to shutdown controller. This will signal to PMIC that it needs to switch
to the state corresponding to backup mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c         | 3 ++-
 arch/arm/mach-at91/pm_suspend.S | 7 +++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 91b4014d2e10..fcb20272d65d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -729,7 +729,8 @@ static int __init at91_pm_backup_init(void)
 	struct platform_device *pdev;
 	int ret = -ENODEV, located = 0;
 
-	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
+	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2) &&
+	    !IS_ENABLED(CONFIG_SOC_SAMA7G5))
 		return -EPERM;
 
 	if (!at91_is_pm_mode_active(AT91_PM_BACKUP))
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 7396e18dd7e5..cbd61a3bcab1 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -106,6 +106,12 @@ lp_done_\ena:
 #endif
 	.endm
 
+	.macro at91_backup_set_lpm reg
+#ifdef CONFIG_SOC_SAMA7
+	orr	\reg, \reg, #0x200000
+#endif
+	.endm
+
 	.text
 
 	.arm
@@ -989,6 +995,7 @@ ulp_exit:
 	ldr	r0, .shdwc
 	mov	tmp1, #0xA5000000
 	add	tmp1, tmp1, #0x1
+	at91_backup_set_lpm tmp1
 	str	tmp1, [r0, #0]
 .endm
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:42 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:42 +0300
Subject: [PATCH v2 21/24] ARM: at91: pm: add sama7g5's pmc
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-22-claudiu.beznea@microchip.com>

Add SAMA7G5's PMC to compatible list.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index fcb20272d65d..f4e66a7c7d18 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -897,6 +897,11 @@ static const struct pmc_info pmc_infos[] __initconst = {
 		.mckr = 0x28,
 		.version = AT91_PMC_V2,
 	},
+	{
+		.mckr = 0x28,
+		.version = AT91_PMC_V2,
+	},
+
 };
 
 static const struct of_device_id atmel_pmc_ids[] __initconst = {
@@ -912,6 +917,7 @@ static const struct of_device_id atmel_pmc_ids[] __initconst = {
 	{ .compatible = "atmel,sama5d4-pmc", .data = &pmc_infos[1] },
 	{ .compatible = "atmel,sama5d2-pmc", .data = &pmc_infos[1] },
 	{ .compatible = "microchip,sam9x60-pmc", .data = &pmc_infos[4] },
+	{ .compatible = "microchip,sama7g5-pmc", .data = &pmc_infos[5] },
 	{ /* sentinel */ },
 };
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:43 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:43 +0300
Subject: [PATCH v2 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-23-claudiu.beznea@microchip.com>

From: Eugen Hristev <eugen.hristev at microchip.com>

Introduce new family of SoCs, sama7, and first SoC, sama7g5.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
[claudiu.beznea at microchip.com: keep only the sama7_dt]
Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/Makefile |  1 +
 arch/arm/mach-at91/sama7.c  | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100644 arch/arm/mach-at91/sama7.c

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index f565490f1b70..522b680b6446 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_AT91RM9200)	+= at91rm9200.o
 obj-$(CONFIG_SOC_AT91SAM9)	+= at91sam9.o
 obj-$(CONFIG_SOC_SAM9X60)	+= sam9x60.o
 obj-$(CONFIG_SOC_SAMA5)		+= sama5.o
+obj-$(CONFIG_SOC_SAMA7)		+= sama7.o
 obj-$(CONFIG_SOC_SAMV7)		+= samv7.o
 
 # Power Management
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
new file mode 100644
index 000000000000..19d7bcbc97f1
--- /dev/null
+++ b/arch/arm/mach-at91/sama7.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Setup code for SAMA7
+ *
+ * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+#include <asm/system_misc.h>
+
+#include "generic.h"
+
+static void __init sama7_dt_device_init(void)
+{
+	of_platform_default_populate(NULL, NULL, NULL);
+}
+
+static const char *const sama7_dt_board_compat[] __initconst = {
+	"microchip,sama7",
+	NULL
+};
+
+DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
+	/* Maintainer: Microchip */
+	.init_machine	= sama7_dt_device_init,
+	.dt_compat	= sama7_dt_board_compat,
+MACHINE_END
+
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:44 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:44 +0300
Subject: [PATCH v2 23/24] ARM: at91: pm: add pm support for SAMA7G5
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-24-claudiu.beznea@microchip.com>

Add support for SAMA7G5 power management modes: standby, ulp0, ulp1, backup.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/generic.h |  2 ++
 arch/arm/mach-at91/pm.c      | 37 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-at91/sama7.c   |  1 +
 3 files changed, 40 insertions(+)

diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 0a4cdcb4985b..0c3960a8b3eb 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -14,12 +14,14 @@ extern void __init at91sam9_pm_init(void);
 extern void __init sam9x60_pm_init(void);
 extern void __init sama5_pm_init(void);
 extern void __init sama5d2_pm_init(void);
+extern void __init sama7_pm_init(void);
 #else
 static inline void __init at91rm9200_pm_init(void) { }
 static inline void __init at91sam9_pm_init(void) { }
 static inline void __init sam9x60_pm_init(void) { }
 static inline void __init sama5_pm_init(void) { }
 static inline void __init sama5d2_pm_init(void) { }
+static inline void __init sama7_pm_init(void) { }
 #endif
 
 #endif /* _AT91_GENERIC_H */
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index f4e66a7c7d18..24d5fd06d487 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -152,6 +152,17 @@ static const struct of_device_id sam9x60_ws_ids[] = {
 	{ /* sentinel */ }
 };
 
+static const struct of_device_id sama7g5_ws_ids[] = {
+	{ .compatible = "atmel,at91sam9x5-rtc",		.data = &ws_info[1] },
+	{ .compatible = "microchip,sama7g5-ohci",	.data = &ws_info[2] },
+	{ .compatible = "usb-ohci",			.data = &ws_info[2] },
+	{ .compatible = "atmel,at91sam9g45-ehci",	.data = &ws_info[2] },
+	{ .compatible = "usb-ehci",			.data = &ws_info[2] },
+	{ .compatible = "microchip,sama7g5-sdhci",	.data = &ws_info[3] },
+	{ .compatible = "atmel,at91sam9260-rtt",	.data = &ws_info[4] },
+	{ /* sentinel */ }
+};
+
 static int at91_pm_config_ws(unsigned int pm_mode, bool set)
 {
 	const struct wakeup_source_info *wsi;
@@ -1103,6 +1114,32 @@ void __init sama5d2_pm_init(void)
 	soc_pm.config_pmc_ws = at91_sama5d2_config_pmc_ws;
 }
 
+void __init sama7_pm_init(void)
+{
+	static const int modes[] __initconst = {
+		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP1, AT91_PM_BACKUP,
+	};
+	static const u32 iomaps[] __initconst = {
+		[AT91_PM_ULP0]		= AT91_PM_IOMAP(SFRBU),
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SFRBU) |
+					  AT91_PM_IOMAP(SHDWC),
+		[AT91_PM_BACKUP]	= AT91_PM_IOMAP(SFRBU) |
+					  AT91_PM_IOMAP(SHDWC),
+	};
+
+	if (!IS_ENABLED(CONFIG_SOC_SAMA7))
+		return;
+
+	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
+
+	at91_dt_ramc(true);
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
+	at91_pm_init(NULL);
+
+	soc_pm.ws_ids = sama7g5_ws_ids;
+	soc_pm.config_pmc_ws = at91_sam9x60_config_pmc_ws;
+}
+
 static int __init at91_pm_modes_select(char *str)
 {
 	char *s;
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
index 19d7bcbc97f1..bd43733ede18 100644
--- a/arch/arm/mach-at91/sama7.c
+++ b/arch/arm/mach-at91/sama7.c
@@ -17,6 +17,7 @@
 static void __init sama7_dt_device_init(void)
 {
 	of_platform_default_populate(NULL, NULL, NULL);
+	sama7_pm_init();
 }
 
 static const char *const sama7_dt_board_compat[] __initconst = {
-- 
2.25.1



From claudiu.beznea at microchip.com  Fri Apr  9 12:13:45 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Fri, 9 Apr 2021 14:13:45 +0300
Subject: [PATCH v2 24/24] ARM: at91: pm: add sama7g5 shdwc
In-Reply-To: <20210409111345.294472-1-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
Message-ID: <20210409111345.294472-25-claudiu.beznea@microchip.com>

Add SAMA7G5 SHDWC.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 24d5fd06d487..d6cfe7c4bb00 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -794,6 +794,7 @@ static int __init at91_pm_backup_init(void)
 static const struct of_device_id atmel_shdwc_ids[] = {
 	{ .compatible = "atmel,sama5d2-shdwc" },
 	{ .compatible = "microchip,sam9x60-shdwc" },
+	{ .compatible = "microchip,sama7g5-shdwc" },
 	{ /* sentinel. */ }
 };
 
-- 
2.25.1



From david at redhat.com  Fri Apr  9 12:20:35 2021
From: david at redhat.com (David Hildenbrand)
Date: Fri,  9 Apr 2021 13:20:35 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
Message-ID: <20210409112035.27221-1-david@redhat.com>

Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
which depends on CMA, if possible; however, these drivers also have to
tolerate if DMA_CMA is not available/functioning, for example, if no CMA
area for DMA_CMA use has been setup via "cma=X". In the worst case, the
driver cannot do it's job properly in some configurations.

For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and DMA_CMA if
available") documents
	While this is no build dependency, etnaviv will only work correctly
	on most systems if CMA and DMA_CMA are enabled. Select both options
	if available to avoid users ending up with a non-working GPU due to
	a lacking kernel config.
So etnaviv really wants to have DMA_CMA, however, can deal with some cases
where it is not available.

Let's introduce WANT_DMA_CMA and use it in most cases where drivers
select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
of recursive dependency issues).

We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.

With this change, distributions can disable CONFIG_CMA or
CONFIG_DMA_CMA, without it silently getting enabled again by random
drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
and CONFIG_DMA_CMA if they are unspecified and any driver is around that
selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
DRM_KMS_CMA_HELPER.

For example, if any driver selects WANT_DMA_CMA and we do a
"make olddefconfig":

1. With "# CONFIG_CMA is not set" and no specification of
   "CONFIG_DMA_CMA"

-> CONFIG_DMA_CMA won't be part of .config

2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA

Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)

3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"

-> CONFIG_DMA_CMA will be removed from .config

Note: drivers/remoteproc seems to be special; commit c51e882cd711
("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
there is a real dependency to DMA_CMA for it to work; leave that dependency
in place and don't convert it to a soft dependency.

Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
Cc: Maxime Ripard <mripard at kernel.org>
Cc: Thomas Zimmermann <tzimmermann at suse.de>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Joel Stanley <joel at jms.id.au>
Cc: Andrew Jeffery <andrew at aj.id.au>
Cc: Lucas Stach <l.stach at pengutronix.de>
Cc: Russell King <linux+etnaviv at armlinux.org.uk>
Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
Cc: Paul Cercueil <paul at crapouillou.net>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Christoph Hellwig <hch at lst.de>
Cc: Marek Szyprowski <m.szyprowski at samsung.com>
Cc: Robin Murphy <robin.murphy at arm.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
Cc: Eric Anholt <eric at anholt.net>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: Masahiro Yamada <masahiroy at kernel.org>
Cc: "Alexander A. Klimov" <grandmaster at al2klimov.de>
Cc: Peter Collingbourne <pcc at google.com>
Cc: Suman Anna <s-anna at ti.com>
Cc: Jason Gunthorpe <jgg at ziepe.ca>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-aspeed at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: etnaviv at lists.freedesktop.org
Cc: linux-mips at vger.kernel.org
Cc: linux-fbdev at vger.kernel.org
Cc: iommu at lists.linux-foundation.org
Signed-off-by: David Hildenbrand <david at redhat.com>
---

Let's see if this approach is better for soft dependencies (and if we
actually have some hard dependencies in there). This is the follow-up
of
  https://lkml.kernel.org/r/20210408092011.52763-1-david at redhat.com
  https://lkml.kernel.org/r/20210408100523.63356-1-david at redhat.com

I was wondering if it would make sense in some drivers to warn if either
CONFIG_DMA_CMA is not available or if DRM_CMA has not been configured
properly - just to give people a heads up that something might more likely
go wrong; that would, however, be future work.

v2 -> v3:
- Don't use "imply" but instead use a new WANT_DMA_CMA and make the default
  of CMA and DMA_CMA depend on it.
- Also adjust ingenic, mcde, tve200; these sound like soft dependencies as
  well (although DMA_CMA is really desired)

v1 -> v2:
- Fix DRM_CMA -> DMA_CMA

---
 drivers/gpu/drm/Kconfig         | 2 ++
 drivers/gpu/drm/aspeed/Kconfig  | 2 --
 drivers/gpu/drm/etnaviv/Kconfig | 3 +--
 drivers/gpu/drm/ingenic/Kconfig | 1 -
 drivers/gpu/drm/mcde/Kconfig    | 1 -
 drivers/gpu/drm/tve200/Kconfig  | 1 -
 drivers/video/fbdev/Kconfig     | 2 +-
 kernel/dma/Kconfig              | 7 +++++++
 mm/Kconfig                      | 1 +
 9 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 85b79a7fee63..6f9989adfa93 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -201,12 +201,14 @@ config DRM_TTM_HELPER
 config DRM_GEM_CMA_HELPER
 	bool
 	depends on DRM
+	select WANT_DMA_CMA
 	help
 	  Choose this if you need the GEM CMA helper functions
 
 config DRM_KMS_CMA_HELPER
 	bool
 	depends on DRM
+	select WANT_DMA_CMA
 	select DRM_GEM_CMA_HELPER
 	help
 	  Choose this if you need the KMS CMA helper functions
diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
index 5e95bcea43e9..e5ff33f85f21 100644
--- a/drivers/gpu/drm/aspeed/Kconfig
+++ b/drivers/gpu/drm/aspeed/Kconfig
@@ -6,8 +6,6 @@ config DRM_ASPEED_GFX
 	depends on MMU
 	select DRM_KMS_HELPER
 	select DRM_KMS_CMA_HELPER
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
-	select CMA if HAVE_DMA_CONTIGUOUS
 	select MFD_SYSCON
 	help
 	  Chose this option if you have an ASPEED AST2500 SOC Display
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index faa7fc68b009..a3e7649b44a7 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -9,8 +9,7 @@ config DRM_ETNAVIV
 	select THERMAL if DRM_ETNAVIV_THERMAL
 	select TMPFS
 	select WANT_DEV_COREDUMP
-	select CMA if HAVE_DMA_CONTIGUOUS
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS
+	select WANT_DMA_CMA
 	select DRM_SCHED
 	help
 	  DRM driver for Vivante GPUs.
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 3b57f8be007c..156b11b7bbb8 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -2,7 +2,6 @@ config DRM_INGENIC
 	tristate "DRM Support for Ingenic SoCs"
 	depends on MIPS || COMPILE_TEST
 	depends on DRM
-	depends on CMA
 	depends on OF
 	depends on COMMON_CLK
 	select DRM_BRIDGE
diff --git a/drivers/gpu/drm/mcde/Kconfig b/drivers/gpu/drm/mcde/Kconfig
index 71c689b573c9..217d54c4babc 100644
--- a/drivers/gpu/drm/mcde/Kconfig
+++ b/drivers/gpu/drm/mcde/Kconfig
@@ -1,7 +1,6 @@
 config DRM_MCDE
 	tristate "DRM Support for ST-Ericsson MCDE (Multichannel Display Engine)"
 	depends on DRM
-	depends on CMA
 	depends on ARM || COMPILE_TEST
 	depends on OF
 	depends on COMMON_CLK
diff --git a/drivers/gpu/drm/tve200/Kconfig b/drivers/gpu/drm/tve200/Kconfig
index e2d163c74ed6..d04b7322c770 100644
--- a/drivers/gpu/drm/tve200/Kconfig
+++ b/drivers/gpu/drm/tve200/Kconfig
@@ -2,7 +2,6 @@
 config DRM_TVE200
 	tristate "DRM Support for Faraday TV Encoder TVE200"
 	depends on DRM
-	depends on CMA
 	depends on ARM || COMPILE_TEST
 	depends on OF
 	select DRM_BRIDGE
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 4f02db65dede..e8acd4f77d41 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2186,7 +2186,7 @@ config FB_HYPERV
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_DEFERRED_IO
-	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
+	select WANT_DMA_CMA
 	help
 	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
 
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..928f16d2461d 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -103,8 +103,15 @@ config DMA_DIRECT_REMAP
 	select DMA_REMAP
 	select DMA_COHERENT_POOL
 
+config WANT_DMA_CMA
+	bool
+	help
+	  Drivers should "select" this option if they desire to use the
+	  DMA_CMA mechanism.
+
 config DMA_CMA
 	bool "DMA Contiguous Memory Allocator"
+	default y if WANT_DMA_CMA
 	depends on HAVE_DMA_CONTIGUOUS && CMA
 	help
 	  This enables the Contiguous Memory Allocator which allows drivers
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b95..169598ee56b1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -485,6 +485,7 @@ config FRONTSWAP
 
 config CMA
 	bool "Contiguous Memory Allocator"
+	default y if WANT_DMA_CMA
 	depends on MMU
 	select MIGRATION
 	select MEMORY_ISOLATION
-- 
2.30.2



From Sergey.Semin at baikalelectronics.ru  Fri Apr  9 12:30:25 2021
From: Sergey.Semin at baikalelectronics.ru (Serge Semin)
Date: Fri, 9 Apr 2021 14:30:25 +0300
Subject: [PATCH RESEND v8 4/7] arm: dts: stih407-family: Harmonize DWC USB3 DT
 nodes name
In-Reply-To: <20210409113029.7144-1-Sergey.Semin@baikalelectronics.ru>
References: <20210409113029.7144-1-Sergey.Semin@baikalelectronics.ru>
Message-ID: <20210409113029.7144-5-Sergey.Semin@baikalelectronics.ru>

In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.

Signed-off-by: Serge Semin <Sergey.Semin at baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk at kernel.org>
Reviewed-by: Patrice Chotard <patrice.chotard at st.com>
---
 arch/arm/boot/dts/stih407-family.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 23a1746f3baa..2352f76b5a69 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -681,7 +681,7 @@ st_dwc3: dwc3 at 8f94000 {
 
 			status = "disabled";
 
-			dwc3: dwc3 at 9900000 {
+			dwc3: usb at 9900000 {
 				compatible	= "snps,dwc3";
 				reg		= <0x09900000 0x100000>;
 				interrupts	= <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.30.1



From Sergey.Semin at baikalelectronics.ru  Fri Apr  9 12:30:21 2021
From: Sergey.Semin at baikalelectronics.ru (Serge Semin)
Date: Fri, 9 Apr 2021 14:30:21 +0300
Subject: [PATCH RESEND v8 0/7] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3
 nodes name
Message-ID: <20210409113029.7144-1-Sergey.Semin@baikalelectronics.ru>

As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].

Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.

Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.

Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.

Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.

[1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin at baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
  node names had been also updated in all the depended dts files. As a
  result I found two more files which should have been also modified:
  arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
  arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.

Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin at baikalelectronics.ru
Changelog v2:
- Drop the patch:
  [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
  and get back the one which marks the "synopsys,dwc3" compatible string
  as deprecated into the DT schema related series.
- Drop the patches:
  [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
  [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
  [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
  [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
  [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
  [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
  [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
  [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
  [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
  [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
  since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
  sub-node and falling back to the "dwc3@"-prefixed one on failure.

Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin at baikalelectronics.ru
Changelog v3:
- Drop the patches:
  [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
  [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
  [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
  since they have been applied to the corresponding maintainers repos.

Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin at baikalelectronics.ru
Changelog v4:
- Just resend.

Link: https://lore.kernel.org/linux-usb/20201210091756.18057-1-Sergey.Semin at baikalelectronics.ru/
Changelog v5:
- Drop the patch:
  [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
  since it has been applied to the corresponding maintainers repos.
- Get back the patch:
  [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  as it has been missing in the kernel 5.11-rc7
- Rebase onto the kernel 5.11-rc7.

Link: https://lore.kernel.org/lkml/20210208135154.6645-1-Sergey.Semin at baikalelectronics.ru/
Changelog v6:
- Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.

Link: https://lore.kernel.org/linux-usb/20210210172850.20849-1-Sergey.Semin at baikalelectronics.ru
Link: https://lore.kernel.org/linux-usb/20210212205521.14280-1-Sergey.Semin at baikalelectronics.ru
Changelog v7:
- Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");"
  pattern with using of_get_compatible_child() method in the Qcom DWC3 driver.
- Drop the patches:
  [PATCH v6 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  [PATCH v6 02/10] arm: dts: keystone: Correct DWC USB3 compatible string
  [PATCH v6 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name
  since they have been applied to the corresponding maintainers repos.
- Cleanup the list of recipients.
- Rebase onto kernel 5.12-rc4.

Link: https://lore.kernel.org/lkml/20210324204836.29668-1-Sergey.Semin at baikalelectronics.ru/
Changelog v8:
- Just resend.

Cc: Khuong Dinh <khuong at os.amperecomputing.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Cc: Paul Mackerras <paulus at samba.org>
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-snps-arc at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-kernel at vger.kernel.org

Serge Semin (7):
  arc: dts: Harmonize EHCI/OHCI DT nodes name
  arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
  powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
  arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
  arm64: dts: apm: Harmonize DWC USB3 DT nodes name
  usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
  arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

 arch/arc/boot/dts/axc003.dtsi                | 4 ++--
 arch/arc/boot/dts/axc003_idu.dtsi            | 4 ++--
 arch/arc/boot/dts/axs10x_mb.dtsi             | 4 ++--
 arch/arc/boot/dts/hsdk.dts                   | 4 ++--
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi         | 2 +-
 arch/arm/boot/dts/lpc18xx.dtsi               | 4 ++--
 arch/arm/boot/dts/stih407-family.dtsi        | 2 +-
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi   | 4 ++--
 arch/arm64/boot/dts/apm/apm-storm.dtsi       | 6 +++---
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
 arch/arm64/boot/dts/qcom/ipq8074.dtsi        | 4 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi        | 4 ++--
 arch/arm64/boot/dts/qcom/msm8998.dtsi        | 2 +-
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi     | 2 +-
 arch/arm64/boot/dts/qcom/qcs404.dtsi         | 4 ++--
 arch/arm64/boot/dts/qcom/sc7180.dtsi         | 2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi         | 4 ++--
 arch/arm64/boot/dts/qcom/sm8150.dtsi         | 2 +-
 arch/powerpc/boot/dts/akebono.dts            | 6 +++---
 drivers/usb/dwc3/dwc3-qcom.c                 | 2 +-
 20 files changed, 35 insertions(+), 35 deletions(-)

-- 
2.30.1



From Sergey.Semin at baikalelectronics.ru  Fri Apr  9 12:30:23 2021
From: Sergey.Semin at baikalelectronics.ru (Serge Semin)
Date: Fri, 9 Apr 2021 14:30:23 +0300
Subject: [PATCH RESEND v8 2/7] arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes
 name
In-Reply-To: <20210409113029.7144-1-Sergey.Semin@baikalelectronics.ru>
References: <20210409113029.7144-1-Sergey.Semin@baikalelectronics.ru>
Message-ID: <20210409113029.7144-3-Sergey.Semin@baikalelectronics.ru>

In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin <Sergey.Semin at baikalelectronics.ru>
Acked-by: Vladimir Zapolskiy <vz at mleia.com>
Acked-by: Krzysztof Kozlowski <krzk at kernel.org>
---
 arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 10b8249b8ab6..82ffd7b0ad8a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -121,7 +121,7 @@ mmcsd: mmcsd at 40004000 {
 			status = "disabled";
 		};
 
-		usb0: ehci at 40006100 {
+		usb0: usb at 40006100 {
 			compatible = "nxp,lpc1850-ehci", "generic-ehci";
 			reg = <0x40006100 0x100>;
 			interrupts = <8>;
@@ -133,7 +133,7 @@ usb0: ehci at 40006100 {
 			status = "disabled";
 		};
 
-		usb1: ehci at 40007100 {
+		usb1: usb at 40007100 {
 			compatible = "nxp,lpc1850-ehci", "generic-ehci";
 			reg = <0x40007100 0x100>;
 			interrupts = <9>;
-- 
2.30.1



From broonie at kernel.org  Fri Apr  9 12:31:01 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 9 Apr 2021 12:31:01 +0100
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <eacc6098-a15f-c07a-2730-cb16cb8e1982@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
 <20210408165825.GP4516@sirena.org.uk>
 <eacc6098-a15f-c07a-2730-cb16cb8e1982@linux.microsoft.com>
Message-ID: <20210409113101.GA4499@sirena.org.uk>

On Thu, Apr 08, 2021 at 02:23:39PM -0500, Madhavan T. Venkataraman wrote:
> On 4/8/21 11:58 AM, Mark Brown wrote:

> > This looks good to me however I'd really like someone who has a firmer
> > understanding of what ftrace is doing to double check as it is entirely
> > likely that I am missing cases here, it seems likely that if I am
> > missing stuff it's extra stuff that needs to be added and we're not
> > actually making use of the reliability information yet.

> OK. So, do you have some specific reviewer(s) in mind? Apart from yourself, Mark Rutland and
> Josh Poimboeuf, these are some reviewers I can think of (in alphabetical order):

Mainly Mark Rutland, but generally someone else who has looked at ftrace
on arm64 in detail.  It was mainly a comment to say I wasn't going to do
any kind of Reviewed-by but also hadn't spotted any issues.
-------------- 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/20210409/902c0126/attachment.sig>

From eugen.hristev at microchip.com  Fri Apr  9 12:31:15 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Fri, 9 Apr 2021 14:31:15 +0300
Subject: [PATCH v2 1/2] ARM: at91: add new SoC sama7g5
Message-ID: <20210409113116.482199-1-eugen.hristev@microchip.com>

Add new SoC from at91 family : sama7g5

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
[claudiu.beznea at microchip.com: Select PLL, generic clock and UTMI support]
Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
Changes in v2:
- squash previous patch
 [PATCH 3/3] ARM: at91: Kconfig: select PLL, generic clock and utmi support
into this one

 arch/arm/mach-at91/Kconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ccd7e80ce943..f52b46bccd85 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -57,6 +57,16 @@ config SOC_SAMA5D4
 	help
 	  Select this if you are using one of Microchip's SAMA5D4 family SoC.
 
+config SOC_SAMA7G5
+	bool "SAMA7G5 family"
+	depends on ARCH_MULTI_V7
+	select HAVE_AT91_GENERATED_CLK
+	select HAVE_AT91_SAM9X60_PLL
+	select HAVE_AT91_UTMI
+	select SOC_SAMA7
+	help
+	  Select this if you are using one of Microchip's SAMA7G5 family SoC.
+
 config SOC_AT91RM9200
 	bool "AT91RM9200"
 	depends on ARCH_MULTI_V4T
@@ -191,4 +201,9 @@ config SOC_SAMA5
 config ATMEL_PM
 	bool
 
+config SOC_SAMA7
+	bool
+	select ARM_GIC
+	select MEMORY
+	select SOC_SAM_V7
 endif
-- 
2.25.1



From eugen.hristev at microchip.com  Fri Apr  9 12:31:16 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Fri, 9 Apr 2021 14:31:16 +0300
Subject: [PATCH v2 2/2] ARM: at91: debug: add sama7g5 low level debug uart
In-Reply-To: <20210409113116.482199-1-eugen.hristev@microchip.com>
References: <20210409113116.482199-1-eugen.hristev@microchip.com>
Message-ID: <20210409113116.482199-2-eugen.hristev@microchip.com>

Add sama7g5 SoC debug uart on Flexcom3. This is the UART that the
ROM bootloader uses.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 arch/arm/Kconfig.debug | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9e0b5e7f12af..7598624ce6dd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -191,6 +191,14 @@ choice
 		  their output to the USART1 port on SAMV7 based
 		  machines.
 
+	config DEBUG_AT91_SAMA7G5_FLEXCOM3
+		bool "Kernel low-level debugging on SAMA7G5 FLEXCOM3"
+		select DEBUG_AT91_UART
+		depends on SOC_SAMA7G5
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on the FLEXCOM3 port of SAMA7G5.
+
 	config DEBUG_BCM2835
 		bool "Kernel low-level debugging on BCM2835 PL011 UART"
 		depends on ARCH_BCM2835 && ARCH_MULTI_V6
@@ -1657,6 +1665,7 @@ config DEBUG_UART_PHYS
 	default 0xd4017000 if DEBUG_MMP_UART2
 	default 0xd4018000 if DEBUG_MMP_UART3
 	default 0xe0000000 if DEBUG_SPEAR13XX
+	default 0xe1824200 if DEBUG_AT91_SAMA7G5_FLEXCOM3
 	default 0xe4007000 if DEBUG_HIP04_UART
 	default 0xe6c40000 if DEBUG_RMOBILE_SCIFA0
 	default 0xe6c50000 if DEBUG_RMOBILE_SCIFA1
@@ -1718,6 +1727,7 @@ config DEBUG_UART_VIRT
 	default 0xc8821000 if DEBUG_RV1108_UART1
 	default 0xc8912000 if DEBUG_RV1108_UART0
 	default 0xe0010fe0 if ARCH_RPC
+	default 0xe0824200 if DEBUG_AT91_SAMA7G5_FLEXCOM3
 	default 0xf0010000 if DEBUG_ASM9260_UART
 	default 0xf0100000 if DEBUG_DIGICOLOR_UA0
 	default 0xf01fb000 if DEBUG_NOMADIK_UART
-- 
2.25.1



From agx at sigxcpu.org  Fri Apr  9 12:40:19 2021
From: agx at sigxcpu.org (=?UTF-8?q?Guido=20G=C3=BCnther?=)
Date: Fri,  9 Apr 2021 13:40:19 +0200
Subject: [PATCH v5 0/2] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
Message-ID: <cover.1617968250.git.agx@sigxcpu.org>

This allows us to shut down the mipi power domain on the imx8. The alternative
would be to drop the dphy from the mipi power domain in the SOCs device tree
and only have the DSI host controller visible there but since the PD is mostly
about the PHY that would defeat it's purpose.

This allows to shut off the power domain when blanking the LCD panel:

pm_genpd_summary before:

domain                          status          slaves
    /device                                             runtime status
----------------------------------------------------------------------
mipi                            on
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  unsupported
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended

after:

mipi                            off-0
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  suspended
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended

Changes from v1:
 - Tweak commit message slightly

Changes from v2:
  - As per review comment by Lucas Stach
    https://lore.kernel.org/linux-arm-kernel/ee22b072e0abe07559a3e6a63ccf6ece064a46cb.camel at pengutronix.de/
    Check for pm_runtime_get_sync failure

Changes from v3:
  - As per review comment by Liu Ying
    https://lore.kernel.org/linux-arm-kernel/424af315b677934fe6a91cee5a0a7aee058245a9.camel at nxp.com/
    https://lore.kernel.org/linux-arm-kernel/a98f7531b9d0293d3c89174446f742d4199cb27c.camel at nxp.com/
    - Use phy layers runtime pm
    - simplify mixel_dphy_remove

Chanes from v4:
  - As per review comment by Liu Ying
    https://lore.kernel.org/linux-arm-kernel/daef1299e43f0372a95c149b979441f8083f4b15.camel at nxp.com/
    - Disable after probe errors
    - core: increment device usage count on .configure as well

Guido G?nther (2):
  phy: core: Use runtime pm during configure too
  phy: fsl-imx8-mipi-dphy: Hook into runtime pm

 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 13 +++++++++++++
 drivers/phy/phy-core.c                         |  6 ++++++
 2 files changed, 19 insertions(+)

-- 
2.30.1



From agx at sigxcpu.org  Fri Apr  9 12:40:20 2021
From: agx at sigxcpu.org (=?UTF-8?q?Guido=20G=C3=BCnther?=)
Date: Fri,  9 Apr 2021 13:40:20 +0200
Subject: [PATCH v5 1/2] phy: core: Use runtime pm during configure too
In-Reply-To: <cover.1617968250.git.agx@sigxcpu.org>
References: <cover.1617968250.git.agx@sigxcpu.org>
Message-ID: <2de2ee26bbf443491dfff1c802f2fa9efaf58d52.1617968250.git.agx@sigxcpu.org>

The phy's configure phase usually needs register access so taking the
device out of pm_runtime suspend looks useful.

There's currently two in tree drivers using runtime pm and .configure
(qualcomm/phy-qcom-qmp.c, rockchip/phy-rockchip-inno-dsidphy.c) but both
don't use the phy layers 'transparent' runtime phy_pm_runtime handling
but manage it manually so this will for now only affect the
phy-fsl-imx8-mipi-dphy driver.

Signed-off-by: Guido G?nther <agx at sigxcpu.org>
---
 drivers/phy/phy-core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ccb575b13777..256a964d52d3 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -470,10 +470,16 @@ int phy_configure(struct phy *phy, union phy_configure_opts *opts)
 	if (!phy->ops->configure)
 		return -EOPNOTSUPP;
 
+	ret = phy_pm_runtime_get_sync(phy);
+	if (ret < 0 && ret != -ENOTSUPP)
+		return ret;
+	ret = 0; /* Override possible ret == -ENOTSUPP */
+
 	mutex_lock(&phy->mutex);
 	ret = phy->ops->configure(phy, opts);
 	mutex_unlock(&phy->mutex);
 
+	phy_pm_runtime_put(phy);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(phy_configure);
-- 
2.30.1



From agx at sigxcpu.org  Fri Apr  9 12:40:21 2021
From: agx at sigxcpu.org (=?UTF-8?q?Guido=20G=C3=BCnther?=)
Date: Fri,  9 Apr 2021 13:40:21 +0200
Subject: [PATCH v5 2/2] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
In-Reply-To: <cover.1617968250.git.agx@sigxcpu.org>
References: <cover.1617968250.git.agx@sigxcpu.org>
Message-ID: <c68efbfc19de3bf1a6586edc71a9b9bdd05c84eb.1617968250.git.agx@sigxcpu.org>

This allows us to shut down the mipi power domain on the imx8. The
alternative would be to drop the dphy from the mipi power domain in the
SOCs device tree and only have the DSI host controller visible there but
since the PD is mostly about the PHY that would defeat it's purpose.

This allows to shut off the power domain when blanking the LCD panel:

pm_genpd_summary before:

domain                          status          slaves
    /device                                             runtime status
----------------------------------------------------------------------
mipi                            on
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  unsupported
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended

after:

mipi                            off-0
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  suspended
    /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended

Signed-off-by: Guido G?nther <agx at sigxcpu.org>
---
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
index a95572b397ca..f89a0c458499 100644
--- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -14,6 +14,7 @@
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 
 /* DPHY registers */
@@ -469,20 +470,32 @@ static int mixel_dphy_probe(struct platform_device *pdev)
 
 	dev_set_drvdata(dev, priv);
 
+	pm_runtime_enable(dev);
+
 	phy = devm_phy_create(dev, np, &mixel_dphy_phy_ops);
 	if (IS_ERR(phy)) {
+		pm_runtime_disable(&pdev->dev);
 		dev_err(dev, "Failed to create phy %ld\n", PTR_ERR(phy));
 		return PTR_ERR(phy);
 	}
 	phy_set_drvdata(phy, priv);
 
 	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+	if (IS_ERR(phy_provider))
+		pm_runtime_disable(&pdev->dev);
 
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
+static int mixel_dphy_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	return 0;
+}
+
 static struct platform_driver mixel_dphy_driver = {
 	.probe	= mixel_dphy_probe,
+	.remove = mixel_dphy_remove,
 	.driver = {
 		.name = "mixel-mipi-dphy",
 		.of_match_table	= mixel_dphy_of_match,
-- 
2.30.1



From s.nawrocki at samsung.com  Fri Apr  9 12:53:32 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Fri, 9 Apr 2021 13:53:32 +0200
Subject: [PATCH] pinctrl: samsung: use 'int' for register masks in Exynos
In-Reply-To: <20210408195029.69974-1-krzysztof.kozlowski@canonical.com>
References: <CGME20210408195041eucas1p1b63616039af4e1156aa4cfd8101b1362@eucas1p1.samsung.com>
 <20210408195029.69974-1-krzysztof.kozlowski@canonical.com>
Message-ID: <3b8d0145-bf01-9ec0-acb3-54081fb57d7f@samsung.com>

On 08.04.2021 21:50, Krzysztof Kozlowski wrote:
> The Special Function Registers on all Exynos SoC, including ARM64, are
> 32-bit wide, so entire driver uses matching functions like readl() or
> writel().  On 64-bit ARM using unsigned long for register masks:
> 1. makes little sense as immediately after bitwise operation it will be
>    cast to 32-bit value when calling writel(),
> 2. is actually error-prone because it might promote other operands to
>    64-bit.
> 
> Addresses-Coverity: Unintentional integer overflow
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

> ---
> 
> Not tested on ARM64.

I have tested it on exynos5433/tm2e and didn't notice any issues
as we could expect. 
The patch looks good to me, however I would personally use u32
rather than "unsigned int", like in other places for the register
value variables.

--
Regards, 
Sylwester


From broonie at kernel.org  Fri Apr  9 12:57:08 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 9 Apr 2021 12:57:08 +0100
Subject: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack
 trace reliability checks
In-Reply-To: <eb905f70-a963-6257-c597-89e008675539@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-2-madvenka@linux.microsoft.com>
 <20210408171715.GQ4516@sirena.org.uk>
 <69b6924b-88f6-6c40-7b18-8cdf15d92bd1@linux.microsoft.com>
 <eb905f70-a963-6257-c597-89e008675539@linux.microsoft.com>
Message-ID: <20210409115708.GB4499@sirena.org.uk>

On Thu, Apr 08, 2021 at 06:30:22PM -0500, Madhavan T. Venkataraman wrote:
> On 4/8/21 2:30 PM, Madhavan T. Venkataraman wrote:

> > 1. Create a common section (I will have to come up with an appropriate name) and put
> >    all such functions in that one section.

> > 2. Create one section for each logical type (exception section, ftrace section and
> >    kprobe section) or some such.

> For now, I will start with idea 2. I will create a special section for each class of
> functions (EL1 exception handlers, FTRACE trampolines, KPROBE trampolines). Instead of a
> special functions array, I will implement a special_sections array. The rest of the code
> should just fall into place.

> Let me know if you prefer something different.

It might be safer to start off by just putting all SYM_CODE into a
section then pulling bits we know to be safe out of the section as
needed - we know that anything that's SYM_CODE is doing something
non-standard and needs checking to verify that the unwinder will be
happy with it and I that should cover most if not all of the cases above
as well as anything else we didn't explicitly think of.
-------------- 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/20210409/811e0f45/attachment.sig>

From thierry.reding at gmail.com  Fri Apr  9 13:09:16 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 9 Apr 2021 14:09:16 +0200
Subject: [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic
In-Reply-To: <20210406134356.dda74heeshkwdarw@pengutronix.de>
References: <20210406073036.26857-1-u.kleine-koenig@pengutronix.de>
 <YGxDD4jVZx/H/Zdr@orome.fritz.box>
 <20210406134356.dda74heeshkwdarw@pengutronix.de>
Message-ID: <YHBD7AhOJGyELpVZ@orome.fritz.box>

On Tue, Apr 06, 2021 at 03:43:56PM +0200, Uwe Kleine-K?nig wrote:
> Hello Thierry,
> 
> On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote:
> > On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-K?nig wrote:
> > > Given that lowlevel drivers usually cannot implement exactly what a
> > > consumer requests with pwm_apply_state() there is some rounding involved.
> > > 
> > > pwm_get_state() traditionally returned the setting that was requested most
> > > recently by the consumer (opposed to what was actually implemented in
> > > hardware in reply to the last request). To make this semantic obvious
> > > rename the function.
> > > 
> > > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > > ---
> > >  Documentation/driver-api/pwm.rst           |  6 +++-
> > >  drivers/clk/clk-pwm.c                      |  2 +-
> > >  drivers/gpu/drm/i915/display/intel_panel.c |  4 +--
> > >  drivers/input/misc/da7280.c                |  2 +-
> > >  drivers/input/misc/pwm-beeper.c            |  2 +-
> > >  drivers/input/misc/pwm-vibra.c             |  4 +--
> > >  drivers/pwm/core.c                         |  4 +--
> > >  drivers/pwm/pwm-atmel-hlcdc.c              |  2 +-
> > >  drivers/pwm/pwm-atmel.c                    |  2 +-
> > >  drivers/pwm/pwm-imx27.c                    |  2 +-
> > >  drivers/pwm/pwm-rockchip.c                 |  2 +-
> > >  drivers/pwm/pwm-stm32-lp.c                 |  4 +--
> > >  drivers/pwm/pwm-sun4i.c                    |  2 +-
> > >  drivers/pwm/sysfs.c                        | 18 ++++++------
> > >  drivers/regulator/pwm-regulator.c          |  4 +--
> > >  drivers/video/backlight/pwm_bl.c           | 10 +++----
> > >  include/linux/pwm.h                        | 34 ++++++++++++++--------
> > >  17 files changed, 59 insertions(+), 45 deletions(-)
> > 
> > Honestly, I don't think this is worth the churn. If you think people
> > will easily get confused by this then a better solution might be to more
> > explicitly document the pwm_get_state() function to say exactly what it
> > returns.
> 
> I'm not so optimistic that people become aware of the semantic just
> because there is documentation describing it and I strongly believe that
> a good name for functions is more important than accurate documentation.
> 
> If you don't agree, what do you think about the updated wording in
> Documentation/driver-api/pwm.rst?

Yeah, that clarifies this a bit. I can apply that hunk of the patch
separately.

> > But there's no need to make life difficult for everyone by
> > renaming this to something as cumbersome as this.
> 
> I don't expect any merge conflicts (and if still a problem occurs
> resolving should be trivial enough). So I obviously don't agree to your
> weighing.

I wasn't talking about merge conflicts but instead about the extra churn
of changing all consumers and having to type all these extra characters
for no benefit.

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/20210409/5932c8b2/attachment.sig>

From mark.rutland at arm.com  Fri Apr  9 13:09:09 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 9 Apr 2021 13:09:09 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210405204313.21346-1-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
Message-ID: <20210409120859.GA51636@C02TD0UTHF1T.local>

Hi Madhavan,

I've noted some concerns below. At a high-level, I'm not keen on the
blacklisting approach, and I think there's some other preparatory work
that would be more valuable in the short term.

On Mon, Apr 05, 2021 at 03:43:09PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> There are a number of places in kernel code where the stack trace is not
> reliable. Enhance the unwinder to check for those cases and mark the
> stack trace as unreliable. Once all of the checks are in place, the unwinder
> can provide a reliable stack trace. But before this can be used for livepatch,
> some other entity needs to guarantee that the frame pointers are all set up
> correctly in kernel functions. objtool is currently being worked on to
> fill that gap.
> 
> Except for the return address check, all the other checks involve checking
> the return PC of every frame against certain kernel functions. To do this,
> implement some infrastructure code:
> 
> 	- Define a special_functions[] array and populate the array with
> 	  the special functions

I'm not too keen on having to manually collate this within the unwinder,
as it's very painful from a maintenance perspective. I'd much rather we
could associate this information with the implementations of these
functions, so that they're more likely to stay in sync.

Further, I believe all the special cases are assembly functions, and
most of those are already in special sections to begin with. I reckon
it'd be simpler and more robust to reject unwinding based on the
section. If we need to unwind across specific functions in those
sections, we could opt-in with some metadata. So e.g. we could reject
all functions in ".entry.text", special casing the EL0 entry functions
if necessary.

As I mentioned before, I'm currently reworking the entry assembly to
make this simpler to do. I'd prefer to not make invasive changes in that
area until that's sorted.

I think there's a lot more code that we cannot unwind, e.g. KVM
exception code, or almost anything marked with SYM_CODE_END().

> 	- Using kallsyms_lookup(), lookup the symbol table entries for the
> 	  functions and record their address ranges
> 
> 	- Define an is_reliable_function(pc) to match a return PC against
> 	  the special functions.
> 
> The unwinder calls is_reliable_function(pc) for every return PC and marks
> the stack trace as reliable or unreliable accordingly.
> 
> Return address check
> ====================
> 
> Check the return PC of every stack frame to make sure that it is a valid
> kernel text address (and not some generated code, for example).
> 
> Detect EL1 exception frame
> ==========================
> 
> EL1 exceptions can happen on any instruction including instructions in
> the frame pointer prolog or epilog. Depending on where exactly they happen,
> they could render the stack trace unreliable.
> 
> Add all of the EL1 exception handlers to special_functions[].
> 
> 	- el1_sync()
> 	- el1_irq()
> 	- el1_error()
> 	- el1_sync_invalid()
> 	- el1_irq_invalid()
> 	- el1_fiq_invalid()
> 	- el1_error_invalid()
> 
> Detect ftrace frame
> ===================
> 
> When FTRACE executes at the beginning of a traced function, it creates two
> frames and calls the tracer function:
> 
> 	- One frame for the traced function
> 
> 	- One frame for the caller of the traced function
> 
> That gives a sensible stack trace while executing in the tracer function.
> When FTRACE returns to the traced function, the frames are popped and
> everything is back to normal.
> 
> However, in cases like live patch, the tracer function redirects execution
> to a different function. When FTRACE returns, control will go to that target
> function. A stack trace taken in the tracer function will not show the target
> function. The target function is the real function that we want to track.
> So, the stack trace is unreliable.

This doesn't match my understanding of the reliable stacktrace
requirements, but I might have misunderstood what you're saying here.

IIUC what you're describing here is:

1) A calls B
2) B is traced
3) tracer replaces B with TARGET
4) tracer returns to TARGET

... and if a stacktrace is taken at step 3 (before the return address is
patched), the trace will show B rather than TARGET.

My understanding is that this is legitimate behaviour.

> To detect stack traces from a tracer function, add the following to
> special_functions[]:
> 
> 	- ftrace_call + 4
> 
> ftrace_call is the label at which the tracer function is patched in. So,
> ftrace_call + 4 is its return address. This is what will show up in a
> stack trace taken from the tracer function.
> 
> When Function Graph Tracing is on, ftrace_graph_caller is patched in
> at the label ftrace_graph_call. If a tracer function called before it has
> redirected execution as mentioned above, the stack traces taken from within
> ftrace_graph_caller will also be unreliable for the same reason as mentioned
> above. So, add ftrace_graph_caller to special_functions[] as well.
> 
> Also, the Function Graph Tracer modifies the return address of a traced
> function to a return trampoline (return_to_handler()) to gather tracing
> data on function return. Stack traces taken from the traced function and
> functions it calls will not show the original caller of the traced function.
> The unwinder handles this case by getting the original caller from FTRACE.
> 
> However, stack traces taken from the trampoline itself and functions it calls
> are unreliable as the original return address may not be available in
> that context. This is because the trampoline calls FTRACE to gather trace
> data as well as to obtain the actual return address and FTRACE discards the
> record of the original return address along the way.

The reason we cannot unwind the trampolines in the usual way is because
they are not AAPCS compliant functions. We don't discard the original
return address, but it's not in the usual location.  With care, we could
write a special case unwinder for them. Note that we also cannot unwind
from any PLT on the way to the trampolines, so we'd also need to
identify those.  Luckily we're in charge of creating those, and (for
now) we only need to care about the module PLTs.

The bigger problem is return_to_handler, since there's a transient
period when C code removes the return address from the graph return
stack before passing this to assembly in a register, and so we can't
reliably find the correct return address during this period. With care
we could special case unwinding immediately before/after this.

If we could find a way to restructure return_to_handler such that we can
reliably find the correct return address, that would be a useful
improvement today, and would mean that we don't have to blacklist it for
reliable stacktrace.

Thanks,
Mark.

> Add return_to_handler() to special_functions[].
> 
> Check for kretprobe
> ===================
> 
> For functions with a kretprobe set up, probe code executes on entry
> to the function and replaces the return address in the stack frame with a
> kretprobe trampoline. Whenever the function returns, control is
> transferred to the trampoline. The trampoline eventually returns to the
> original return address.
> 
> A stack trace taken while executing in the function (or in functions that
> get called from the function) will not show the original return address.
> Similarly, a stack trace taken while executing in the trampoline itself
> (and functions that get called from the trampoline) will not show the
> original return address. This means that the caller of the probed function
> will not show. This makes the stack trace unreliable.
> 
> Add the kretprobe trampoline to special_functions[].
> 
> Optprobes
> =========
> 
> Optprobes may be implemented in the future for arm64. For optprobes,
> the relevant trampoline(s) can be added to special_functions[].
> ---
> Changelog:
> 
> v1
> 	- Define a bool field in struct stackframe. This will indicate if
> 	  a stack trace is reliable.
> 
> 	- Implement a special_functions[] array that will be populated
> 	  with special functions in which the stack trace is considered
> 	  unreliable.
> 	
> 	- Using kallsyms_lookup(), get the address ranges for the special
> 	  functions and record them.
> 
> 	- Implement an is_reliable_function(pc). This function will check
> 	  if a given return PC falls in any of the special functions. If
> 	  it does, the stack trace is unreliable.
> 
> 	- Implement check_reliability() function that will check if a
> 	  stack frame is reliable. Call is_reliable_function() from
> 	  check_reliability().
> 
> 	- Before a return PC is checked against special_funtions[], it
> 	  must be validates as a proper kernel text address. Call
> 	  __kernel_text_address() from check_reliability().
> 
> 	- Finally, call check_reliability() from unwind_frame() for
> 	  each stack frame.
> 
> 	- Add EL1 exception handlers to special_functions[].
> 
> 		el1_sync();
> 		el1_irq();
> 		el1_error();
> 		el1_sync_invalid();
> 		el1_irq_invalid();
> 		el1_fiq_invalid();
> 		el1_error_invalid();
> 
> 	- The above functions are currently defined as LOCAL symbols.
> 	  Make them global so that they can be referenced from the
> 	  unwinder code.
> 
> 	- Add FTRACE trampolines to special_functions[]:
> 
> 		ftrace_graph_call()
> 		ftrace_graph_caller()
> 		return_to_handler()
> 
> 	- Add the kretprobe trampoline to special functions[]:
> 
> 		kretprobe_trampoline()
> 
> v2
> 	- Removed the terminating entry { 0, 0 } in special_functions[]
> 	  and replaced it with the idiom { /* sentinel */ }.
> 
> 	- Change the ftrace trampoline entry ftrace_graph_call in
> 	  special_functions[] to ftrace_call + 4 and added explanatory
> 	  comments.
> 
> 	- Unnested #ifdefs in special_functions[] for FTRACE.
> 
> Madhavan T. Venkataraman (4):
>   arm64: Implement infrastructure for stack trace reliability checks
>   arm64: Mark a stack trace unreliable if an EL1 exception frame is
>     detected
>   arm64: Detect FTRACE cases that make the stack trace unreliable
>   arm64: Mark stack trace as unreliable if kretprobed functions are
>     present
> 
>  arch/arm64/include/asm/exception.h  |   8 ++
>  arch/arm64/include/asm/stacktrace.h |   2 +
>  arch/arm64/kernel/entry-ftrace.S    |  12 ++
>  arch/arm64/kernel/entry.S           |  14 +-
>  arch/arm64/kernel/stacktrace.c      | 215 ++++++++++++++++++++++++++++
>  5 files changed, 244 insertions(+), 7 deletions(-)
> 
> 
> base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
> -- 
> 2.25.1
> 


From Ludovic.Desroches at microchip.com  Fri Apr  9 13:11:08 2021
From: Ludovic.Desroches at microchip.com (Ludovic.Desroches at microchip.com)
Date: Fri, 9 Apr 2021 12:11:08 +0000
Subject: [PATCH] pinctrl: at91-pio4: Fix slew rate disablement
In-Reply-To: <20210409082522.625168-1-tudor.ambarus@microchip.com>
References: <20210409082522.625168-1-tudor.ambarus@microchip.com>
Message-ID: <20210409121107.mcjo6cbsequjd3v4@sekiro>

On Fri, Apr 09, 2021 at 11:25:22AM +0300, Tudor Ambarus wrote:
> The slew rate was enabled by default for each configuration of the
> pin. In case the pin had more than one configuration, even if
> we set the slew rate as disabled in the device tree, the next pin
> configuration would set again the slew rate enabled by default,
> overwriting the slew rate disablement.
> Instead of enabling the slew rate by default for each pin configuration,
> enable the slew rate by default just once per pin, regardless of the
> number of configurations. This way the slew rate disablement will also
> work for cases where pins have multiple configurations.
> 
> Fixes: 440b144978ba ("pinctrl: at91-pio4: add support for slew-rate")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>

Acked-by: Ludovic Desroches <ludovic.desroches at microchip.com>

Thanks.

> ---
>  drivers/pinctrl/pinctrl-at91-pio4.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
> index a5d328808e4c..4c01d8471ffa 100644
> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> @@ -801,6 +801,10 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
>  
>  	conf = atmel_pin_config_read(pctldev, pin_id);
>  
> +	/* Keep slew rate enabled by default. */
> +	if (atmel_pioctrl->slew_rate_support)
> +		conf |= ATMEL_PIO_SR_MASK;
> +
>  	for (i = 0; i < num_configs; i++) {
>  		unsigned int param = pinconf_to_config_param(configs[i]);
>  		unsigned int arg = pinconf_to_config_argument(configs[i]);
> @@ -808,10 +812,6 @@ static int atmel_conf_pin_config_group_set(struct pinctrl_dev *pctldev,
>  		dev_dbg(pctldev->dev, "%s: pin=%u, config=0x%lx\n",
>  			__func__, pin_id, configs[i]);
>  
> -		/* Keep slew rate enabled by default. */
> -		if (atmel_pioctrl->slew_rate_support)
> -			conf |= ATMEL_PIO_SR_MASK;
> -
>  		switch (param) {
>  		case PIN_CONFIG_BIAS_DISABLE:
>  			conf &= (~ATMEL_PIO_PUEN_MASK);
> -- 
> 2.25.1
> 

From m.szyprowski at samsung.com  Fri Apr  9 13:17:43 2021
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 9 Apr 2021 14:17:43 +0200
Subject: [PATCH] iommu: exynos: remove unneeded local variable
 initialization
In-Reply-To: <20210408201622.78009-1-krzysztof.kozlowski@canonical.com>
References: <CGME20210408201630eucas1p25551bcecf0073ac0361cfc03a4ef124a@eucas1p2.samsung.com>
 <20210408201622.78009-1-krzysztof.kozlowski@canonical.com>
Message-ID: <2a00f957-1f19-f398-ae18-908d8a17375d@samsung.com>

On 08.04.2021 22:16, Krzysztof Kozlowski wrote:
> The initialization of 'fault_addr' local variable is not needed as it is
> shortly after overwritten.
>
> Addresses-Coverity: Unused value
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Acked-by: Marek Szyprowski <m.szyprowski at samsung.com>

> ---
>   drivers/iommu/exynos-iommu.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index de324b4eedfe..8fa9a591fb96 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -407,7 +407,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
>   	struct sysmmu_drvdata *data = dev_id;
>   	const struct sysmmu_fault_info *finfo;
>   	unsigned int i, n, itype;
> -	sysmmu_iova_t fault_addr = -1;
> +	sysmmu_iova_t fault_addr;
>   	unsigned short reg_status, reg_clear;
>   	int ret = -ENOSYS;
>   

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From lukma at denx.de  Fri Apr  9 13:20:36 2021
From: lukma at denx.de (Lukasz Majewski)
Date: Fri,  9 Apr 2021 14:20:36 +0200
Subject: [PATCH 2/2] ARM: dts: imx28: Add DTS description of imx28 based XEA
 board
Message-ID: <20210409122036.31628-1-lukma@denx.de>

This patch adds DTS definition of the imx278 based XEA board.

Signed-off-by: Lukasz Majewski <lukma at denx.de>

---
Changes for v2:
- Fix 'memory' node and remove regulators subnode
- Rename 'flash0: s25fl256s0 at 0' to flash at 0
- Add proper compatible for XEA board
---
 arch/arm/boot/dts/Makefile       |   3 +-
 arch/arm/boot/dts/imx28-lwe.dtsi | 174 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx28-xea.dts  |  99 ++++++++++++++++++
 3 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx28-lwe.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-xea.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..d2398a090e4d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -721,7 +721,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
 	imx28-ts4600.dtb \
-	imx28-tx28.dtb
+	imx28-tx28.dtb \
+	imx28-xea.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
 	ste-nomadik-s8815.dtb \
 	ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/imx28-lwe.dtsi b/arch/arm/boot/dts/imx28-lwe.dtsi
new file mode 100644
index 000000000000..2d14a8ae91f8
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-lwe.dtsi
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2021
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+
+/ {
+	aliases {
+		spi2 = &ssp3;
+	};
+
+	chosen {
+		bootargs = "root=/dev/mmcblk0p2 rootfstype=ext4 ro rootwait console=ttyAMA0,115200 panic=1";
+	};
+
+	memory at 0x40000000 {
+		reg = <0x40000000 0x08000000>;
+	};
+
+	reg_3v3: regulator-reg-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_usb_5v: regulator-reg-usb-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+	};
+
+	reg_fec_3v3: regulator-reg-fec-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		regulator-boot-on;
+	};
+};
+
+&duart {
+	pinctrl-names = "default";
+	pinctrl-0 = <&duart_pins_a>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+};
+
+&saif0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif0_pins_a>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&clks 53>;
+	assigned-clock-rates = <12000000>;
+	status = "okay";
+};
+
+&saif1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif1_pins_a>;
+	fsl,saif-master = <&saif0>;
+	#sound-dai-cells = <0>;
+	status = "okay";
+};
+
+&spi3_pins_a {
+	fsl,pinmux-ids = <
+		MX28_PAD_AUART2_RX__SSP3_D4
+		MX28_PAD_AUART2_TX__SSP3_D5
+		MX28_PAD_SSP3_SCK__SSP3_SCK
+		MX28_PAD_SSP3_MOSI__SSP3_CMD
+		MX28_PAD_SSP3_MISO__SSP3_D0
+		MX28_PAD_SSP3_SS0__SSP3_D3
+		MX28_PAD_AUART2_TX__GPIO_3_9
+	>;
+};
+
+&ssp3 {
+	compatible = "fsl,imx28-spi";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi3_pins_a>;
+	status = "okay";
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <40000000>;
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				label = "u-boot";
+				reg = <0 0x80000>;
+				read-only;
+			};
+
+			partition at 80000 {
+				label = "env0";
+				reg = <0x80000 0x10000>;
+			};
+
+			partition at 90000 {
+				label = "env1";
+				reg = <0x90000 0x10000>;
+			};
+
+			partition at 100000 {
+				label = "kernel";
+				reg = <0x100000 0x400000>;
+			};
+
+			partition at 500000 {
+				label = "swupdate";
+				reg = <0x500000 0x800000>;
+			};
+		};
+	};
+};
+
+&ssp2 {
+	compatible = "fsl,imx28-spi";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_pins_a>;
+	status = "okay";
+};
+
+&ssp0 {
+	compatible = "fsl,imx28-mmc";
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_8bit_pins_a>;
+	bus-width = <8>;
+	vmmc-supply = <&reg_3v3>;
+	non-removable;
+	status = "okay";
+};
+
+&usb0 {
+	vbus-supply = <&reg_usb_5v>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_pins_b>, <&usb0_id_pins_a>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy0 {
+	status = "okay";
+};
+
+&usb1 {
+	vbus-supply = <&reg_usb_5v>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb1_pins_b>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx28-xea.dts b/arch/arm/boot/dts/imx28-xea.dts
new file mode 100644
index 000000000000..a400c108f66a
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-xea.dts
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2021
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx28-lwe.dtsi"
+
+/ {
+	compatible = "lwn,imx28-xea", "fsl,imx28";
+};
+
+&can0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&can1_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins_b>;
+	status = "okay";
+};
+
+&pinctrl {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hog_pins_a &hog_pins_tiva>;
+
+	hog_pins_a: hog at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_D00__GPIO_0_0
+			MX28_PAD_GPMI_D02__GPIO_0_2
+			MX28_PAD_GPMI_D05__GPIO_0_5
+			MX28_PAD_GPMI_CE1N__GPIO_0_17
+			MX28_PAD_GPMI_RDY0__GPIO_0_20
+			MX28_PAD_GPMI_RDY1__GPIO_0_21
+			MX28_PAD_GPMI_RDY2__GPIO_0_22
+			MX28_PAD_GPMI_RDN__GPIO_0_24
+			MX28_PAD_GPMI_CLE__GPIO_0_27
+			MX28_PAD_LCD_VSYNC__GPIO_1_28
+			MX28_PAD_SSP1_SCK__GPIO_2_12
+			MX28_PAD_SSP1_CMD__GPIO_2_13
+			MX28_PAD_SSP2_SS1__GPIO_2_20
+			MX28_PAD_SSP2_SS2__GPIO_2_21
+			MX28_PAD_LCD_D00__GPIO_1_0
+			MX28_PAD_LCD_D01__GPIO_1_1
+			MX28_PAD_LCD_D02__GPIO_1_2
+			MX28_PAD_LCD_D03__GPIO_1_3
+			MX28_PAD_LCD_D04__GPIO_1_4
+			MX28_PAD_LCD_D05__GPIO_1_5
+			MX28_PAD_LCD_D06__GPIO_1_6
+		>;
+		fsl,drive-strength = <MXS_DRIVE_4mA>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+
+	hog_pins_tiva: hog at 1 {
+		reg = <1>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_RDY3__GPIO_0_23
+			MX28_PAD_GPMI_WRN__GPIO_0_25
+		>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+
+	hog_pins_coding: hog at 2 {
+		reg = <2>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_D01__GPIO_0_1
+			MX28_PAD_GPMI_D03__GPIO_0_3
+			MX28_PAD_GPMI_D04__GPIO_0_4
+			MX28_PAD_GPMI_D06__GPIO_0_6
+			MX28_PAD_GPMI_D07__GPIO_0_7
+		>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+};
+
+&reg_fec_3v3 {
+	gpio = <&gpio0 0 0>;
+};
+
+&reg_usb_5v {
+	gpio = <&gpio0 2 0>;
+};
+
+&spi2_pins_a {
+	fsl,pinmux-ids = <
+		MX28_PAD_SSP2_SCK__SSP2_SCK
+		MX28_PAD_SSP2_MOSI__SSP2_CMD
+		MX28_PAD_SSP2_MISO__SSP2_D0
+		MX28_PAD_SSP2_SS0__GPIO_2_19
+	>;
+};
-- 
2.20.1



From thierry.reding at gmail.com  Fri Apr  9 13:24:43 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 9 Apr 2021 14:24:43 +0200
Subject: [v3,PATCH 3/3] pwm: mtk_disp: implement .get_state()
In-Reply-To: <20210406102756.4kncasxe4um3q6wi@pengutronix.de>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
 <1617703062-4251-4-git-send-email-rex-bc.chen@mediatek.com>
 <20210406102756.4kncasxe4um3q6wi@pengutronix.de>
Message-ID: <YHBHizYI7oyULZx9@orome.fritz.box>

On Tue, Apr 06, 2021 at 12:27:56PM +0200, Uwe Kleine-K?nig wrote:
> On Tue, Apr 06, 2021 at 05:57:42PM +0800, Rex-BC Chen wrote:
> > implement get_state function for pwm-mtk-disp
> > 
> > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> 
> Ideally you S-o-b line is the last one to show the order in which this
> patch went from one person to another.
> 
> > ---
> >  drivers/pwm/pwm-mtk-disp.c | 46 ++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> > 
> > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
> > index 502228adf718..166e0a8ca703 100644
> > --- a/drivers/pwm/pwm-mtk-disp.c
> > +++ b/drivers/pwm/pwm-mtk-disp.c
> > @@ -179,8 +179,54 @@ static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >  	return mtk_disp_pwm_enable(chip, state);
> >  }
> >  
> > +static void mtk_disp_pwm_get_state(struct pwm_chip *chip,
> > +				   struct pwm_device *pwm,
> > +				   struct pwm_state *state)
> > +{
> > +	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
> > +	u32 clk_div, period, high_width, con0, con1;
> > +	u64 rate;
> > +	int err;
> > +
> > +	err = clk_prepare_enable(mdp->clk_main);
> > +	if (err < 0) {
> > +		dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n", err);
> > +		return;
> > +	}
> > +	err = clk_prepare_enable(mdp->clk_mm);
> > +	if (err < 0) {
> > +		dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n", err);
> > +		clk_disable_unprepare(mdp->clk_main);
> 
> As before: %pe please

According to the documentation %pe only works on pointers for which
IS_ERR() is true, so I'm not sure it can be used with plain integer
error codes.

Looks like there's a bunch of drivers that will do %pe and then use
ERR_PTR(err) to make this work, but to be honest, that seems like
jumping through hoops.

But I don't feel strongly either way, so choose whichever you want.

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/20210409/d4ab82f8/attachment.sig>

From mark.rutland at arm.com  Fri Apr  9 13:27:01 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 9 Apr 2021 13:27:01 +0100
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the
 stack trace unreliable
In-Reply-To: <20210405204313.21346-4-madvenka@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
Message-ID: <20210409122701.GB51636@C02TD0UTHF1T.local>

On Mon, Apr 05, 2021 at 03:43:12PM -0500, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
> for a function, the ftrace infrastructure is called for the function at
> the very beginning. Ftrace creates two frames:
> 
> 	- One for the traced function
> 
> 	- One for the caller of the traced function
> 
> That gives a reliable stack trace while executing in the ftrace code. When
> ftrace returns to the traced function, the frames are popped and everything
> is back to normal.
> 
> However, in cases like live patch, a tracer function may redirect execution
> to a different function when it returns. A stack trace taken while still in
> the tracer function will not show the target function. The target function
> is the real function that we want to track.
> 
> So, if an FTRACE frame is detected on the stack, just mark the stack trace
> as unreliable. The detection is done by checking the return PC against
> FTRACE trampolines.
> 
> Also, the Function Graph Tracer modifies the return address of a traced
> function to a return trampoline to gather tracing data on function return.
> Stack traces taken from that trampoline and functions it calls are
> unreliable as the original return address may not be available in
> that context. Mark the stack trace unreliable accordingly.
> 
> Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
> ---
>  arch/arm64/kernel/entry-ftrace.S | 12 +++++++
>  arch/arm64/kernel/stacktrace.c   | 61 ++++++++++++++++++++++++++++++++
>  2 files changed, 73 insertions(+)
> 
> diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
> index b3e4f9a088b1..1f0714a50c71 100644
> --- a/arch/arm64/kernel/entry-ftrace.S
> +++ b/arch/arm64/kernel/entry-ftrace.S
> @@ -86,6 +86,18 @@ SYM_CODE_START(ftrace_caller)
>  	b	ftrace_common
>  SYM_CODE_END(ftrace_caller)
>  
> +/*
> + * A stack trace taken from anywhere in the FTRACE trampoline code should be
> + * considered unreliable as a tracer function (patched at ftrace_call) could
> + * potentially set pt_regs->pc and redirect execution to a function different
> + * than the traced function. E.g., livepatch.

IIUC the issue here that we have two copies of the pc: one in the regs,
and one in a frame record, and so after the update to the regs, the
frame record is stale.

This is something that we could fix by having
ftrace_instruction_pointer_set() set both.

However, as noted elsewhere there are other issues which mean we'd still
need special unwinding code for this.

Thanks,
Mark.

> + *
> + * No stack traces are taken in this FTRACE trampoline assembly code. But
> + * they can be taken from C functions that get called from here. The unwinder
> + * checks if a return address falls in this FTRACE trampoline code. See
> + * stacktrace.c. If function calls in this code are changed, please keep the
> + * special_functions[] array in stacktrace.c in sync.
> + */
>  SYM_CODE_START(ftrace_common)
>  	sub	x0, x30, #AARCH64_INSN_SIZE	// ip (callsite's BL insn)
>  	mov	x1, x9				// parent_ip (callsite's LR)
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index fb11e4372891..7a3c638d4aeb 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -51,6 +51,52 @@ struct function_range {
>   * unreliable. Breakpoints are used for executing probe code. Stack traces
>   * taken while in the probe code will show an EL1 frame and will be considered
>   * unreliable. This is correct behavior.
> + *
> + * FTRACE
> + * ======
> + *
> + * When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled, the FTRACE trampoline code
> + * is called from a traced function even before the frame pointer prolog.
> + * FTRACE sets up two stack frames (one for the traced function and one for
> + * its caller) so that the unwinder can provide a sensible stack trace for
> + * any tracer function called from the FTRACE trampoline code.
> + *
> + * There are two cases where the stack trace is not reliable.
> + *
> + * (1) The task gets preempted before the two frames are set up. Preemption
> + *     involves an interrupt which is an EL1 exception. The unwinder already
> + *     handles EL1 exceptions.
> + *
> + * (2) The tracer function that gets called by the FTRACE trampoline code
> + *     changes the return PC (e.g., livepatch).
> + *
> + *     Not all tracer functions do that. But to err on the side of safety,
> + *     consider the stack trace as unreliable in all cases.
> + *
> + * When Function Graph Tracer is used, FTRACE modifies the return address of
> + * the traced function in its stack frame to an FTRACE return trampoline
> + * (return_to_handler). When the traced function returns, control goes to
> + * return_to_handler. return_to_handler calls FTRACE to gather tracing data
> + * and to obtain the original return address. Then, return_to_handler returns
> + * to the original return address.
> + *
> + * There are two cases to consider from a stack trace reliability point of
> + * view:
> + *
> + * (1) Stack traces taken within the traced function (and functions that get
> + *     called from there) will show return_to_handler instead of the original
> + *     return address. The original return address can be obtained from FTRACE.
> + *     The unwinder already obtains it and modifies the return PC in its copy
> + *     of the stack frame to the original return address. So, this is handled.
> + *
> + * (2) return_to_handler calls FTRACE as mentioned before. FTRACE discards
> + *     the record of the original return address along the way as it does not
> + *     need to maintain it anymore. This means that the unwinder cannot get
> + *     the original return address beyond that point while the task is still
> + *     executing in return_to_handler. So, consider the stack trace unreliable
> + *     if return_to_handler is detected on the stack.
> + *
> + * NOTE: The unwinder must do (1) before (2).
>   */
>  static struct function_range	special_functions[] = {
>  	/*
> @@ -64,6 +110,21 @@ static struct function_range	special_functions[] = {
>  	{ (unsigned long) el1_fiq_invalid, 0 },
>  	{ (unsigned long) el1_error_invalid, 0 },
>  
> +	/*
> +	 * FTRACE trampolines.
> +	 *
> +	 * Tracer function gets patched at the label ftrace_call. Its return
> +	 * address is the next instruction address.
> +	 */
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> +	{ (unsigned long) ftrace_call + 4, 0 },
> +#endif
> +
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +	{ (unsigned long) ftrace_graph_caller, 0 },
> +	{ (unsigned long) return_to_handler, 0 },
> +#endif
> +
>  	{ /* sentinel */ }
>  };
>  
> -- 
> 2.25.1
> 


From l.stach at pengutronix.de  Fri Apr  9 13:30:34 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 09 Apr 2021 14:30:34 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <20210409112035.27221-1-david@redhat.com>
References: <20210409112035.27221-1-david@redhat.com>
Message-ID: <18d42d56167f0e2af6d0edaf596b20fcd778b96c.camel@pengutronix.de>

Am Freitag, dem 09.04.2021 um 13:20 +0200 schrieb David Hildenbrand:
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
> which depends on CMA, if possible; however, these drivers also have to
> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
> driver cannot do it's job properly in some configurations.
> 
> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and DMA_CMA if
> available") documents
> 	While this is no build dependency, etnaviv will only work correctly
> 	on most systems if CMA and DMA_CMA are enabled. Select both options
> 	if available to avoid users ending up with a non-working GPU due to
> 	a lacking kernel config.
> So etnaviv really wants to have DMA_CMA, however, can deal with some cases
> where it is not available.
> 
> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
> of recursive dependency issues).
> 
> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
> 
> With this change, distributions can disable CONFIG_CMA or
> CONFIG_DMA_CMA, without it silently getting enabled again by random
> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER.
> 
> For example, if any driver selects WANT_DMA_CMA and we do a
> "make olddefconfig":
> 
> 1. With "# CONFIG_CMA is not set" and no specification of
> ???"CONFIG_DMA_CMA"
> 
> -> CONFIG_DMA_CMA won't be part of .config
> 
> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
> 
> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
> 
> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
> 
> -> CONFIG_DMA_CMA will be removed from .config
> 
> Note: drivers/remoteproc seems to be special; commit c51e882cd711
> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
> there is a real dependency to DMA_CMA for it to work; leave that dependency
> in place and don't convert it to a soft dependency.

Hm, to me this sounds much like the reasoning for the etnaviv
dependency. There is no actual build dependency, as the allocations are
done through the DMA API, but for the allocations to succeed you most
likely want CMA to be enabled. But that's just an observation from the
outside, I have no real clue about the remoteproc drivers.

As far as the etnaviv changes are concerned:
Acked-by: Lucas Stach <l.stach at pengutronix.de>

> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> Cc: Maxime Ripard <mripard at kernel.org>
> Cc: Thomas Zimmermann <tzimmermann at suse.de>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Joel Stanley <joel at jms.id.au>
> Cc: Andrew Jeffery <andrew at aj.id.au>
> Cc: Lucas Stach <l.stach at pengutronix.de>
> Cc: Russell King <linux+etnaviv at armlinux.org.uk>
> Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
> Cc: Paul Cercueil <paul at crapouillou.net>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Christoph Hellwig <hch at lst.de>
> Cc: Marek Szyprowski <m.szyprowski at samsung.com>
> Cc: Robin Murphy <robin.murphy at arm.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: Masahiro Yamada <masahiroy at kernel.org>
> Cc: "Alexander A. Klimov" <grandmaster at al2klimov.de>
> Cc: Peter Collingbourne <pcc at google.com>
> Cc: Suman Anna <s-anna at ti.com>
> Cc: Jason Gunthorpe <jgg at ziepe.ca>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-aspeed at lists.ozlabs.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: etnaviv at lists.freedesktop.org
> Cc: linux-mips at vger.kernel.org
> Cc: linux-fbdev at vger.kernel.org
> Cc: iommu at lists.linux-foundation.org
> Signed-off-by: David Hildenbrand <david at redhat.com>
> ---
> 
> Let's see if this approach is better for soft dependencies (and if we
> actually have some hard dependencies in there). This is the follow-up
> of
> ??https://lkml.kernel.org/r/20210408092011.52763-1-david at redhat.com
> ??https://lkml.kernel.org/r/20210408100523.63356-1-david at redhat.com
> 
> I was wondering if it would make sense in some drivers to warn if either
> CONFIG_DMA_CMA is not available or if DRM_CMA has not been configured
> properly - just to give people a heads up that something might more likely
> go wrong; that would, however, be future work.
> 
> v2 -> v3:
> - Don't use "imply" but instead use a new WANT_DMA_CMA and make the default
> ??of CMA and DMA_CMA depend on it.
> - Also adjust ingenic, mcde, tve200; these sound like soft dependencies as
> ??well (although DMA_CMA is really desired)
> 
> v1 -> v2:
> - Fix DRM_CMA -> DMA_CMA
> 
> ---
> ?drivers/gpu/drm/Kconfig         | 2 ++
> ?drivers/gpu/drm/aspeed/Kconfig  | 2 --
> ?drivers/gpu/drm/etnaviv/Kconfig | 3 +--
> ?drivers/gpu/drm/ingenic/Kconfig | 1 -
> ?drivers/gpu/drm/mcde/Kconfig    | 1 -
> ?drivers/gpu/drm/tve200/Kconfig  | 1 -
> ?drivers/video/fbdev/Kconfig     | 2 +-
> ?kernel/dma/Kconfig              | 7 +++++++
> ?mm/Kconfig                      | 1 +
> ?9 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 85b79a7fee63..6f9989adfa93 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -201,12 +201,14 @@ config DRM_TTM_HELPER
> ?config DRM_GEM_CMA_HELPER
> ?	bool
> ?	depends on DRM
> +	select WANT_DMA_CMA
> ?	help
> ?	  Choose this if you need the GEM CMA helper functions
> ?
> 
> 
> 
> ?config DRM_KMS_CMA_HELPER
> ?	bool
> ?	depends on DRM
> +	select WANT_DMA_CMA
> ?	select DRM_GEM_CMA_HELPER
> ?	help
> ?	  Choose this if you need the KMS CMA helper functions
> diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
> index 5e95bcea43e9..e5ff33f85f21 100644
> --- a/drivers/gpu/drm/aspeed/Kconfig
> +++ b/drivers/gpu/drm/aspeed/Kconfig
> @@ -6,8 +6,6 @@ config DRM_ASPEED_GFX
> ?	depends on MMU
> ?	select DRM_KMS_HELPER
> ?	select DRM_KMS_CMA_HELPER
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS
> -	select CMA if HAVE_DMA_CONTIGUOUS
> ?	select MFD_SYSCON
> ?	help
> ?	  Chose this option if you have an ASPEED AST2500 SOC Display
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index faa7fc68b009..a3e7649b44a7 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -9,8 +9,7 @@ config DRM_ETNAVIV
> ?	select THERMAL if DRM_ETNAVIV_THERMAL
> ?	select TMPFS
> ?	select WANT_DEV_COREDUMP
> -	select CMA if HAVE_DMA_CONTIGUOUS
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS
> +	select WANT_DMA_CMA
> ?	select DRM_SCHED
> ?	help
> ?	  DRM driver for Vivante GPUs.
> diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
> index 3b57f8be007c..156b11b7bbb8 100644
> --- a/drivers/gpu/drm/ingenic/Kconfig
> +++ b/drivers/gpu/drm/ingenic/Kconfig
> @@ -2,7 +2,6 @@ config DRM_INGENIC
> ?	tristate "DRM Support for Ingenic SoCs"
> ?	depends on MIPS || COMPILE_TEST
> ?	depends on DRM
> -	depends on CMA
> ?	depends on OF
> ?	depends on COMMON_CLK
> ?	select DRM_BRIDGE
> diff --git a/drivers/gpu/drm/mcde/Kconfig b/drivers/gpu/drm/mcde/Kconfig
> index 71c689b573c9..217d54c4babc 100644
> --- a/drivers/gpu/drm/mcde/Kconfig
> +++ b/drivers/gpu/drm/mcde/Kconfig
> @@ -1,7 +1,6 @@
> ?config DRM_MCDE
> ?	tristate "DRM Support for ST-Ericsson MCDE (Multichannel Display Engine)"
> ?	depends on DRM
> -	depends on CMA
> ?	depends on ARM || COMPILE_TEST
> ?	depends on OF
> ?	depends on COMMON_CLK
> diff --git a/drivers/gpu/drm/tve200/Kconfig b/drivers/gpu/drm/tve200/Kconfig
> index e2d163c74ed6..d04b7322c770 100644
> --- a/drivers/gpu/drm/tve200/Kconfig
> +++ b/drivers/gpu/drm/tve200/Kconfig
> @@ -2,7 +2,6 @@
> ?config DRM_TVE200
> ?	tristate "DRM Support for Faraday TV Encoder TVE200"
> ?	depends on DRM
> -	depends on CMA
> ?	depends on ARM || COMPILE_TEST
> ?	depends on OF
> ?	select DRM_BRIDGE
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 4f02db65dede..e8acd4f77d41 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2186,7 +2186,7 @@ config FB_HYPERV
> ?	select FB_CFB_COPYAREA
> ?	select FB_CFB_IMAGEBLIT
> ?	select FB_DEFERRED_IO
> -	select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> +	select WANT_DMA_CMA
> ?	help
> ?	  This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
> ?
> 
> 
> 
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 77b405508743..928f16d2461d 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -103,8 +103,15 @@ config DMA_DIRECT_REMAP
> ?	select DMA_REMAP
> ?	select DMA_COHERENT_POOL
> ?
> 
> 
> 
> +config WANT_DMA_CMA
> +	bool
> +	help
> +	  Drivers should "select" this option if they desire to use the
> +	  DMA_CMA mechanism.
> +
> ?config DMA_CMA
> ?	bool "DMA Contiguous Memory Allocator"
> +	default y if WANT_DMA_CMA
> ?	depends on HAVE_DMA_CONTIGUOUS && CMA
> ?	help
> ?	  This enables the Contiguous Memory Allocator which allows drivers
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 24c045b24b95..169598ee56b1 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -485,6 +485,7 @@ config FRONTSWAP
> ?
> 
> 
> 
> ?config CMA
> ?	bool "Contiguous Memory Allocator"
> +	default y if WANT_DMA_CMA
> ?	depends on MMU
> ?	select MIGRATION
> ?	select MEMORY_ISOLATION




From linus.walleij at linaro.org  Fri Apr  9 13:35:52 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 9 Apr 2021 14:35:52 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <20210409112035.27221-1-david@redhat.com>
References: <20210409112035.27221-1-david@redhat.com>
Message-ID: <CACRpkdb_eQrcCFV9Q9uho8E6HO4X0dRJp1qAdJBcT82=sZ1v7A@mail.gmail.com>

On Fri, Apr 9, 2021 at 1:20 PM David Hildenbrand <david at redhat.com> wrote:

> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
> which depends on CMA, if possible; however, these drivers also have to
> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
> driver cannot do it's job properly in some configurations.

Looks good to me. At least a lot better than what we have.
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

> Let's see if this approach is better for soft dependencies (and if we
> actually have some hard dependencies in there). This is the follow-up
> of
>   https://lkml.kernel.org/r/20210408092011.52763-1-david at redhat.com
>   https://lkml.kernel.org/r/20210408100523.63356-1-david at redhat.com

You can just add these to the commit message with Link:
when applying so people can easily find the discussion from the
commit.

> I was wondering if it would make sense in some drivers to warn if either
> CONFIG_DMA_CMA is not available or if DRM_CMA has not been configured
> properly - just to give people a heads up that something might more likely
> go wrong; that would, however, be future work.

I think the frameworks  (DRM_*_CMA_HELPER)
should pr_info something about it so the individual drivers
don't have to sanity check their entire world.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Apr  9 13:49:54 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri,  9 Apr 2021 14:49:54 +0200
Subject: [PATCH] ARM: dts: qcom: Fix up APQ8060 DragonBoard license
Message-ID: <20210409124954.320529-1-linus.walleij@linaro.org>

This file is licensed in some kind of BSD manner, put it under
the combined GPL+BSD license like what the bindings use, it
seems most helpful.

I wrote the whole file so whatever. Those are my principles,
if you don't like them: I have others.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../arm/boot/dts/qcom-apq8060-dragonboard.dts | 23 +------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index dace8ffeb991..1be467124a70 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -1,25 +1,4 @@
-/*
- * Copyright 2016 Linaro Ltd
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this software and associated documentation files (the "Software"), to deal
- * in the Software without restriction, including without limitation the rights
- * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
- * copies of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
- * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
- * THE SOFTWARE.
- */
-
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
-- 
2.30.2



From linux at roeck-us.net  Fri Apr  9 13:56:43 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 9 Apr 2021 05:56:43 -0700
Subject: [PATCH] watchdog: mtk: support pre-timeout when the bark irq is
 available
In-Reply-To: <1617962142-28795-1-git-send-email-wangqing@vivo.com>
References: <1617962142-28795-1-git-send-email-wangqing@vivo.com>
Message-ID: <58b6f50a-4522-dc21-3411-7ed18059b480@roeck-us.net>

On 4/9/21 2:55 AM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> By default, the pretimeout notification shall occur one second earlier
> than the timeout.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 44 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..8b919cc
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>  	int ret;
>  
> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);

That looks suspiciously like the real watchdog won't happen at all.
What will happen if the pretimeout governor is set to none ?

Guenter

>  	if (ret < 0)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
>  	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	if (wdt_dev->pretimeout)
> +		reg |= WDT_MODE_IRQ_EN;
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> +				   unsigned int timeout)
> +{
> +	wdd->pretimeout = timeout;
> +	return mtk_wdt_start(wdd);
> +}
> +
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +	watchdog_notify_pretimeout(wdd);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,12 +271,21 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
>  	.stop		= mtk_wdt_stop,
>  	.ping		= mtk_wdt_ping,
>  	.set_timeout	= mtk_wdt_set_timeout,
> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>  	.restart	= mtk_wdt_restart,
>  };
>  
> @@ -267,7 +294,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err,irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +306,21 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark", &mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = 1;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> 



From colin.king at canonical.com  Fri Apr  9 14:07:26 2021
From: colin.king at canonical.com (Colin King)
Date: Fri,  9 Apr 2021 14:07:26 +0100
Subject: [PATCH] net: thunderx: Fix unintentional sign extension issue
Message-ID: <20210409130726.665490-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The shifting of the u8 integers rq->caching by 26 bits to
the left will be promoted to a 32 bit signed int and then
sign-extended to a u64. In the event that rq->caching is
greater than 0x1f then all then all the upper 32 bits of
the u64 end up as also being set because of the int
sign-extension. Fix this by casting the u8 values to a
u64 before the 26 bit left shift.

Addresses-Coverity: ("Unintended sign extension")
Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index f782e6af45e9..50bbe79fb93d 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -776,7 +776,7 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
 	mbx.rq.msg = NIC_MBOX_MSG_RQ_CFG;
 	mbx.rq.qs_num = qs->vnic_id;
 	mbx.rq.rq_num = qidx;
-	mbx.rq.cfg = (rq->caching << 26) | (rq->cq_qs << 19) |
+	mbx.rq.cfg = ((u64)rq->caching << 26) | (rq->cq_qs << 19) |
 			  (rq->cq_idx << 16) | (rq->cont_rbdr_qs << 9) |
 			  (rq->cont_qs_rbdr_idx << 8) |
 			  (rq->start_rbdr_qs << 1) | (rq->start_qs_rbdr_idx);
-- 
2.30.2



From lkp at intel.com  Fri Apr  9 14:14:06 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 9 Apr 2021 21:14:06 +0800
Subject: [PATCH v2] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210409101902.2800-1-vincenzo.frascino@arm.com>
References: <20210409101902.2800-1-vincenzo.frascino@arm.com>
Message-ID: <202104092126.pvVQG3UB-lkp@intel.com>

Hi Vincenzo,

I love your patch! Yet something to improve:

[auto build test ERROR on arm/for-next]
[also build test ERROR on soc/for-next kvmarm/next linus/master v5.12-rc6 next-20210408]
[cannot apply to arm64/for-next/core xlnx/master]
[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]

url:    https://github.com/0day-ci/linux/commits/Vincenzo-Frascino/arm64-mte-Move-MTE-TCF0-check-in-entry-common/20210409-182215
base:   git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
config: arm64-allnoconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/59174442d4b85039bfec7ede4825ff2b5c0b4331
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Vincenzo-Frascino/arm64-mte-Move-MTE-TCF0-check-in-entry-common/20210409-182215
        git checkout 59174442d4b85039bfec7ede4825ff2b5c0b4331
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

   In file included from arch/arm64/include/asm/pgtable.h:12,
                    from include/linux/pgtable.h:6,
                    from include/linux/mm.h:33,
                    from arch/arm64/kernel/asm-offsets.c:12:
>> arch/arm64/include/asm/mte.h:89:1: warning: ignoring attribute 'gnu_inline' because it conflicts with attribute 'noinline' [-Wattributes]
      89 | {
         | ^
   arch/arm64/include/asm/mte.h:34:14: note: previous declaration here
      34 | void noinstr check_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
>> arch/arm64/include/asm/mte.h:88:20: error: static declaration of 'check_mte_async_tcf0' follows non-static declaration
      88 | static inline void check_mte_async_tcf0(void)
         |                    ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:34:14: note: previous declaration of 'check_mte_async_tcf0' was here
      34 | void noinstr check_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:92:1: warning: ignoring attribute 'gnu_inline' because it conflicts with attribute 'noinline' [-Wattributes]
      92 | {
         | ^
   arch/arm64/include/asm/mte.h:35:14: note: previous declaration here
      35 | void noinstr clear_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
>> arch/arm64/include/asm/mte.h:91:20: error: static declaration of 'clear_mte_async_tcf0' follows non-static declaration
      91 | static inline void clear_mte_async_tcf0(void)
         |                    ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:35:14: note: previous declaration of 'clear_mte_async_tcf0' was here
      35 | void noinstr clear_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
--
   In file included from arch/arm64/include/asm/pgtable.h:12,
                    from include/linux/pgtable.h:6,
                    from include/linux/mm.h:33,
                    from arch/arm64/kernel/asm-offsets.c:12:
>> arch/arm64/include/asm/mte.h:89:1: warning: ignoring attribute 'gnu_inline' because it conflicts with attribute 'noinline' [-Wattributes]
      89 | {
         | ^
   arch/arm64/include/asm/mte.h:34:14: note: previous declaration here
      34 | void noinstr check_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
>> arch/arm64/include/asm/mte.h:88:20: error: static declaration of 'check_mte_async_tcf0' follows non-static declaration
      88 | static inline void check_mte_async_tcf0(void)
         |                    ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:34:14: note: previous declaration of 'check_mte_async_tcf0' was here
      34 | void noinstr check_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:92:1: warning: ignoring attribute 'gnu_inline' because it conflicts with attribute 'noinline' [-Wattributes]
      92 | {
         | ^
   arch/arm64/include/asm/mte.h:35:14: note: previous declaration here
      35 | void noinstr clear_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
>> arch/arm64/include/asm/mte.h:91:20: error: static declaration of 'clear_mte_async_tcf0' follows non-static declaration
      91 | static inline void clear_mte_async_tcf0(void)
         |                    ^~~~~~~~~~~~~~~~~~~~
   arch/arm64/include/asm/mte.h:35:14: note: previous declaration of 'clear_mte_async_tcf0' was here
      35 | void noinstr clear_mte_async_tcf0(void);
         |              ^~~~~~~~~~~~~~~~~~~~
   make[2]: *** [scripts/Makefile.build:116: arch/arm64/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [Makefile:1233: prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [Makefile:215: __sub-make] Error 2
   make: Target 'prepare' not remade because of errors.


vim +/check_mte_async_tcf0 +88 arch/arm64/include/asm/mte.h

    20	
    21	void mte_clear_page_tags(void *addr);
    22	unsigned long mte_copy_tags_from_user(void *to, const void __user *from,
    23					      unsigned long n);
    24	unsigned long mte_copy_tags_to_user(void __user *to, void *from,
    25					    unsigned long n);
    26	int mte_save_tags(struct page *page);
    27	void mte_save_page_tags(const void *page_addr, void *tag_storage);
    28	bool mte_restore_tags(swp_entry_t entry, struct page *page);
    29	void mte_restore_page_tags(void *page_addr, const void *tag_storage);
    30	void mte_invalidate_tags(int type, pgoff_t offset);
    31	void mte_invalidate_tags_area(int type);
    32	void *mte_allocate_tag_storage(void);
    33	void mte_free_tag_storage(char *storage);
  > 34	void noinstr check_mte_async_tcf0(void);
    35	void noinstr clear_mte_async_tcf0(void);
    36	
    37	#ifdef CONFIG_ARM64_MTE
    38	
    39	/* track which pages have valid allocation tags */
    40	#define PG_mte_tagged	PG_arch_2
    41	
    42	void mte_sync_tags(pte_t *ptep, pte_t pte);
    43	void mte_copy_page_tags(void *kto, const void *kfrom);
    44	void flush_mte_state(void);
    45	void mte_thread_switch(struct task_struct *next);
    46	void mte_suspend_exit(void);
    47	long set_mte_ctrl(struct task_struct *task, unsigned long arg);
    48	long get_mte_ctrl(struct task_struct *task);
    49	int mte_ptrace_copy_tags(struct task_struct *child, long request,
    50				 unsigned long addr, unsigned long data);
    51	
    52	void mte_assign_mem_tag_range(void *addr, size_t size);
    53	
    54	#else /* CONFIG_ARM64_MTE */
    55	
    56	/* unused if !CONFIG_ARM64_MTE, silence the compiler */
    57	#define PG_mte_tagged	0
    58	
    59	static inline void mte_sync_tags(pte_t *ptep, pte_t pte)
    60	{
    61	}
    62	static inline void mte_copy_page_tags(void *kto, const void *kfrom)
    63	{
    64	}
    65	static inline void flush_mte_state(void)
    66	{
    67	}
    68	static inline void mte_thread_switch(struct task_struct *next)
    69	{
    70	}
    71	static inline void mte_suspend_exit(void)
    72	{
    73	}
    74	static inline long set_mte_ctrl(struct task_struct *task, unsigned long arg)
    75	{
    76		return 0;
    77	}
    78	static inline long get_mte_ctrl(struct task_struct *task)
    79	{
    80		return 0;
    81	}
    82	static inline int mte_ptrace_copy_tags(struct task_struct *child,
    83					       long request, unsigned long addr,
    84					       unsigned long data)
    85	{
    86		return -EIO;
    87	}
  > 88	static inline void check_mte_async_tcf0(void)
  > 89	{
    90	}
  > 91	static inline void clear_mte_async_tcf0(void)
    92	{
    93	}
    94	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 8216 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/1b644bbc/attachment.gz>

From thierry.reding at gmail.com  Fri Apr  9 14:20:12 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 9 Apr 2021 15:20:12 +0200
Subject: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <YHBUjPjEpLYF/915@orome.fritz.box>

On Fri, Apr 09, 2021 at 06:07:09PM +0900, Nobuhiro Iwamatsu wrote:
> Add driver for the PWM controller on Toshiba Visconti ARM SoC.
> 
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> ---
>  drivers/pwm/Kconfig        |   9 ++
>  drivers/pwm/Makefile       |   1 +
>  drivers/pwm/pwm-visconti.c | 193 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 203 insertions(+)
>  create mode 100644 drivers/pwm/pwm-visconti.c

Looks good, but I have a few minor comments, see below.

> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 9a4f66ae8070..8ae68d6203fb 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -601,6 +601,15 @@ config PWM_TWL_LED
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called pwm-twl-led.
>  
> +config PWM_VISCONTI
> +	tristate "Toshiba Visconti PWM support"
> +	depends on ARCH_VISCONTI || COMPILE_TEST
> +	help
> +	  PWM Subsystem driver support for Toshiba Visconti SoCs.
> +
> +	  To compile this driver as a module, choose M here: the module
> +	  will be called pwm-visconti.
> +
>  config PWM_VT8500
>  	tristate "vt8500 PWM support"
>  	depends on ARCH_VT8500 || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 6374d3b1d6f3..d43b1e17e8e1 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
>  obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
>  obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
>  obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
> +obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
>  obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
> diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> new file mode 100644
> index 000000000000..ff4a5f5b0009
> --- /dev/null
> +++ b/drivers/pwm/pwm-visconti.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Toshiba Visconti pulse-width-modulation controller driver
> + *
> + * Copyright (c) 2020 TOSHIBA CORPORATION
> + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> + *
> + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/pwm.h>
> +#include <linux/platform_device.h>

Should be sorted alphabetically.

> +
> +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> +
> +#define PIPGM_PWMC_PWMACT		BIT(5)
> +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> +#define PIPGM_PWMC_POLARITY_MASK	GENMASK(5, 5)
> +
> +struct visconti_pwm_chip {
> +	struct pwm_chip chip;
> +	void __iomem *base;
> +};
> +
> +#define to_visconti_chip(chip) \
> +	container_of(chip, struct visconti_pwm_chip, chip)

I prefer these to be static inline functions because that tends to give
better error messages than macros. Also, that's what's primarily used in
the PWM drivers, even if there are a couple of outliers.

I'll go fix those up.

> +
> +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			      const struct pwm_state *state)
> +{
> +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> +	u32 period, duty_cycle, pwmc0;
> +
> +	dev_dbg(chip->dev, "%s: ch = %d en = %d p = 0x%llx d = 0x%llx\n", __func__,
> +		pwm->hwpwm, state->enabled, state->period, state->duty_cycle);

Don't the trace points work for you?

> +
> +	/*
> +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> +	 * the period register (PCSR) is written and the currently running period is completed. This
> +	 * way the hardware switches atomically from the old setting to the new.
> +	 * Also, disabling the hardware completes the currently running period and keeps the output
> +	 * at low level at all times.
> +	 */
> +	if (!state->enabled) {
> +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +		return 0;
> +	}
> +
> +	/*
> +	 * The biggest period the hardware can provide is
> +	 *	(0xffff << 3) * 1000 ns
> +	 * This value fits easily in an u32, so simplify the maths by
> +	 * capping the values to 32 bit integers.
> +	 */
> +	if (state->period > (0xffff << 3) * 1000)
> +		period = (0xffff << 3) * 1000;
> +	else
> +		period = state->period;
> +
> +	if (state->duty_cycle > period)
> +		duty_cycle = period;
> +	else
> +		duty_cycle = state->duty_cycle;
> +
> +	/*
> +	 * The input clock runs fixed at 1 MHz, so we have only
> +	 * microsecond resolution and so can divide by
> +	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
> +	 */
> +	period /= 1000;
> +	duty_cycle /= 1000;
> +
> +	if (!period)
> +		/* period too small */
> +		return -ERANGE;

Maybe braces around this so the two-line "block" doesn't look wrong,
even if it actually isn't. Or perhaps put the comment above the check
for the same effect.

Quite frankly, I'd just drop the comment because the code itself is
clear and the comment doesn't add anything.

> +
> +	/*
> +	 * PWMC controls a divider that divides the input clk by a
> +	 * power of two between 1 and 8. As a smaller divider yields
> +	 * higher precision, pick the smallest possible one.
> +	 */
> +	if (period > 0xffff) {
> +		pwmc0 = ilog2(period >> 16);
> +		BUG_ON(pwmc0 > 3);
> +	} else
> +		pwmc0 = 0;
> +
> +	period >>= pwmc0;
> +	duty_cycle >>= pwmc0;
> +
> +	if (state->polarity == PWM_POLARITY_INVERSED)
> +		pwmc0 |= PIPGM_PWMC_PWMACT;
> +	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> +	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> +	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +
> +	return 0;
> +}
> +
> +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +				   struct pwm_state *state)
> +{
> +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> +	u32 period, duty, pwmc0, pwmc0_clk;
> +
> +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> +	if (period)
> +		state->enabled = true;
> +	else
> +		state->enabled = false;
> +
> +	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
> +	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
> +	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
> +
> +	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
> +	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
> +	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
> +		state->polarity = PWM_POLARITY_INVERSED;
> +	else
> +		state->polarity = PWM_POLARITY_NORMAL;
> +}
> +
> +static const struct pwm_ops visconti_pwm_ops = {
> +	.apply = visconti_pwm_apply,
> +	.get_state = visconti_pwm_get_state,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int visconti_pwm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct visconti_pwm_chip *priv;
> +	int ret;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(priv->base))
> +		return PTR_ERR(priv->base);
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	priv->chip.dev = dev;
> +	priv->chip.ops = &visconti_pwm_ops;
> +	priv->chip.base = -1;

There's no need for this anymore. The current PWM tree will always
assume base = -1.

> +	priv->chip.npwm = 4;
> +
> +	ret = pwmchip_add(&priv->chip);
> +	if (ret < 0)
> +		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
> +
> +	dev_dbg(&pdev->dev, "visconti PWM registered\n");

Maybe not the best use of a debug message. There are better ways to
check if a device has successfully bound to a driver than relying on
debug messages.

> +
> +	return 0;
> +}
> +
> +static int visconti_pwm_remove(struct platform_device *pdev)
> +{
> +	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
> +
> +	return pwmchip_remove(&priv->chip);

I think Uwe would prefer this to be done separately because he's working
towards removing the return value from pwmchip_remove() and if we start
ignoring it in new drivers that will make life easier going forward.

So this should just be:

	pwmchip_remove(&priv->chip);

	return 0;

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/20210409/5017b490/attachment-0001.sig>

From vincenzo.frascino at arm.com  Fri Apr  9 14:24:19 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Fri,  9 Apr 2021 14:24:19 +0100
Subject: [PATCH v3] arm64: mte: Move MTE TCF0 check in entry-common
Message-ID: <20210409132419.29965-1-vincenzo.frascino@arm.com>

The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
race with another CPU doing a set_tsk_thread_flag() and all the other flags
can be lost in the process.

Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
exit_to_user_mode() to address the problem.

Note: Moving the check in entry-common allows to use set_thread_flag()
which is safe.

Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous tag check faults")
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: stable at vger.kernel.org
Reported-by: Will Deacon <will at kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
 arch/arm64/include/asm/mte.h     |  9 +++++++++
 arch/arm64/kernel/entry-common.c |  6 ++++++
 arch/arm64/kernel/entry.S        | 34 --------------------------------
 arch/arm64/kernel/mte.c          | 33 +++++++++++++++++++++++++++++--
 4 files changed, 46 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index 9b557a457f24..c7ab681a95c3 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -49,6 +49,9 @@ int mte_ptrace_copy_tags(struct task_struct *child, long request,
 
 void mte_assign_mem_tag_range(void *addr, size_t size);
 
+void noinstr check_mte_async_tcf0(void);
+void noinstr clear_mte_async_tcf0(void);
+
 #else /* CONFIG_ARM64_MTE */
 
 /* unused if !CONFIG_ARM64_MTE, silence the compiler */
@@ -83,6 +86,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
 {
 	return -EIO;
 }
+static inline void check_mte_async_tcf0(void)
+{
+}
+static inline void clear_mte_async_tcf0(void)
+{
+}
 
 static inline void mte_assign_mem_tag_range(void *addr, size_t size)
 {
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9d3588450473..837d3624a1d5 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
 	CT_WARN_ON(ct_state() != CONTEXT_USER);
 	user_exit_irqoff();
 	trace_hardirqs_off_finish();
+
+	/* Check for asynchronous tag check faults in user space */
+	check_mte_async_tcf0();
 }
 
 asmlinkage void noinstr exit_to_user_mode(void)
 {
+	/* Ignore asynchronous tag check faults in the uaccess routines */
+	clear_mte_async_tcf0();
+
 	trace_hardirqs_on_prepare();
 	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
 	user_enter_irqoff();
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a31a0a713c85..fb57df0d453f 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -34,15 +34,11 @@
  * user and kernel mode.
  */
 	.macro user_exit_irqoff
-#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
 	bl	enter_from_user_mode
-#endif
 	.endm
 
 	.macro user_enter_irqoff
-#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
 	bl	exit_to_user_mode
-#endif
 	.endm
 
 	.macro	clear_gp_regs
@@ -147,32 +143,6 @@ alternative_cb_end
 .L__asm_ssbd_skip\@:
 	.endm
 
-	/* Check for MTE asynchronous tag check faults */
-	.macro check_mte_async_tcf, flgs, tmp
-#ifdef CONFIG_ARM64_MTE
-alternative_if_not ARM64_MTE
-	b	1f
-alternative_else_nop_endif
-	mrs_s	\tmp, SYS_TFSRE0_EL1
-	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
-	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
-	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
-	str	\flgs, [tsk, #TSK_TI_FLAGS]
-	msr_s	SYS_TFSRE0_EL1, xzr
-1:
-#endif
-	.endm
-
-	/* Clear the MTE asynchronous tag check faults */
-	.macro clear_mte_async_tcf
-#ifdef CONFIG_ARM64_MTE
-alternative_if ARM64_MTE
-	dsb	ish
-	msr_s	SYS_TFSRE0_EL1, xzr
-alternative_else_nop_endif
-#endif
-	.endm
-
 	.macro mte_set_gcr, tmp, tmp2
 #ifdef CONFIG_ARM64_MTE
 	/*
@@ -243,8 +213,6 @@ alternative_else_nop_endif
 	ldr	x19, [tsk, #TSK_TI_FLAGS]
 	disable_step_tsk x19, x20
 
-	/* Check for asynchronous tag check faults in user space */
-	check_mte_async_tcf x19, x22
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23
@@ -775,8 +743,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
 	cbnz	x2, work_pending
 finish_ret_to_user:
 	user_enter_irqoff
-	/* Ignore asynchronous tag check faults in the uaccess routines */
-	clear_mte_async_tcf
 	enable_step_tsk x19, x2
 #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
 	bl	stackleak_erase
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index b3c70a612c7a..84a942c25870 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64 excl)
 	 */
 }
 
-void flush_mte_state(void)
+void noinstr check_mte_async_tcf0(void)
+{
+	u64 tcf0;
+
+	if (!system_supports_mte())
+		return;
+
+	/*
+	 * dsb(ish) is not required before the register read
+	 * because the TFSRE0_EL1 is automatically synchronized
+	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
+	 * is set.
+	 */
+	tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
+
+	if (tcf0 & SYS_TFSR_EL1_TF0)
+		set_thread_flag(TIF_MTE_ASYNC_FAULT);
+
+	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
+void noinstr clear_mte_async_tcf0(void)
 {
 	if (!system_supports_mte())
 		return;
 
-	/* clear any pending asynchronous tag fault */
 	dsb(ish);
 	write_sysreg_s(0, SYS_TFSRE0_EL1);
+}
+
+void flush_mte_state(void)
+{
+	if (!system_supports_mte())
+		return;
+
+	/* clear any pending asynchronous tag fault */
+	clear_mte_async_tcf0();
 	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
 	/* disable tag checking */
 	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
-- 
2.30.2



From arnd at arndb.de  Fri Apr  9 14:35:03 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 9 Apr 2021 15:35:03 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <20210409112035.27221-1-david@redhat.com>
References: <20210409112035.27221-1-david@redhat.com>
Message-ID: <CAK8P3a31uKNcim0n99=yt3zjZ+LQSw4V4+8PS8daLsBdS0iSYg@mail.gmail.com>

On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand <david at redhat.com> wrote:
>
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
> which depends on CMA, if possible; however, these drivers also have to
> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
> driver cannot do it's job properly in some configurations.
>
> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and DMA_CMA if
> available") documents
>         While this is no build dependency, etnaviv will only work correctly
>         on most systems if CMA and DMA_CMA are enabled. Select both options
>         if available to avoid users ending up with a non-working GPU due to
>         a lacking kernel config.
> So etnaviv really wants to have DMA_CMA, however, can deal with some cases
> where it is not available.
>
> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
> of recursive dependency issues).
>
> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
>
> With this change, distributions can disable CONFIG_CMA or
> CONFIG_DMA_CMA, without it silently getting enabled again by random
> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER.
>
> For example, if any driver selects WANT_DMA_CMA and we do a
> "make olddefconfig":
>
> 1. With "# CONFIG_CMA is not set" and no specification of
>    "CONFIG_DMA_CMA"
>
> -> CONFIG_DMA_CMA won't be part of .config
>
> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
>
> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
>
> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
>
> -> CONFIG_DMA_CMA will be removed from .config
>
> Note: drivers/remoteproc seems to be special; commit c51e882cd711
> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
> there is a real dependency to DMA_CMA for it to work; leave that dependency
> in place and don't convert it to a soft dependency.

I don't think this dependency is fundamentally different from the others,
though davinci machines tend to have less memory than a lot of the
other machines, so it's more likely to fail without CMA.

Regardless of this,

Reviewed-by: Arnd Bergmann <arnd at arndb.de>


From aford173 at gmail.com  Fri Apr  9 14:36:29 2021
From: aford173 at gmail.com (Adam Ford)
Date: Fri, 9 Apr 2021 08:36:29 -0500
Subject: [PATCH v1 0/7] imx-gpcv2 improvements
In-Reply-To: <bc59b75b-d5b7-fe0f-6cba-d184cab204d3@oss.nxp.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
 <542d469459083fa31e37ca7feb14480831a0445f.camel@pengutronix.de>
 <bc59b75b-d5b7-fe0f-6cba-d184cab204d3@oss.nxp.com>
Message-ID: <CAHCN7xK=mjvgrMGXfFwN6520rhtdZu9YRiSn6mi6-+9sVA-LWg@mail.gmail.com>

On Wed, Apr 7, 2021 at 8:27 PM Peng Fan (OSS) <peng.fan at oss.nxp.com> wrote:
>
> Hi Lucas,
>
> On 2021/4/8 6:13, Lucas Stach wrote:
> > Hi Adrien,
> >
> > I feel like I already mentioned to you some time ago that there is
> > already a much more complete patch series to add this functionality on
> > the list [1].
> >
> > If you want this functionality to go upstream, please help test and
> > extend this patch series.
> >
> > Regards,
> > Lucas
> >
> > [1] https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.stach at pengutronix.de/
>
> Would you share what's the issue that block this going forward?

Peng,

I know of a few.  One of them is mentioned in [1] above.  From what I
can tell, the dt-bindings have halted being able to enable the GPU and
USB power domains.  See [2] for some of that dialog.

The second part that I am aware is the blk-ctl being dependent on the
power domain and the power domain being dependent on the blk-ctl [3]
There was some discussion of using syscon to let the power-domain
finish coming up and then referencing the the power-domain from the
blk-ctl, but there was some disagreement [4] on that approach

I think Abel tried to create an IRC, but by the time I was able to
join the IRC, there was no activity.

[2] - https://lore.kernel.org/linux-arm-kernel/CAHCN7xLdkEd0G3fa9gAp-xvKZ-bYmvcyn-8OEbgNjBJyCCOs9g at mail.gmail.com/
[3] - https://lkml.org/lkml/2020/11/9/17
[4] - https://www.spinics.net/lists/arm-kernel/msg849032.html

>
> Thanks,
> Peng.
>
> >
> > Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> >> Hi,
> >>
> >> This patch set aims is to add the support of the i.MX8 MM power domains
> >> on the mainline kernel.
> >>
> >> To achieve this, I do several patches
> >>    - Check errors when reading or writing registers (concerns i.MX8M base
> >>      implementation);
> >>    - Fix power up/down sequence. Handshake was not checked and it was
> >>      not called at the appropriate time (concerns i.MX8M base
> >> implementaions);
> >>    - Allow domains without power sequence control like the HSIOMIX of the
> >>      i.MX8MM.
> >>    - Add some i.MX8MM domains (HSIO and OTGS);
> >>    - Introduce quirks. For example, i.MX8MM OTG domains should not be
> >>      powered off (seen n the source code of th i.MX ATF). Quirks are
> >> easily upgrable for other cases.
> >>    - Finally I defined power domains into the imx8mm.dtb file.
> >>
> >> I know that this kind of patch is rejected by NXP ut the other way
> >> (callin ATF directly) was also rejected.
> >>
> >> I also know that NXP is concerned abou adding hundred lines of codes for
> >> each new SOC but it' the way it works on Linux. And the "added code"
> >> mainly consist of adding structures, defines and generic methods for
> >> regmap.
> >>
> >> If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> >> i.MX8MM, i.MX8MN and i.MX8MP.
> >>
> >> Thanks,
> >>
> >> Adrien Grassein (7):
> >>    soc: imx: gpcv2: check for errors when r/w registers
> >>    soc: imx: gpcv2: Fix power up/down sequence
> >>    soc: imx: gpcv2: allow domains without power sequence control
> >>    dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> >>    soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> >>    soc: imx: gpcv2: add quirks to domains
> >>    arm64: dts: imx8mm: add power-domains
> >>
> >>   .../bindings/power/fsl,imx-gpcv2.yaml         |   7 +-
> >>   arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  35 ++
> >>   drivers/soc/imx/gpcv2.c                       | 336 ++++++++++++++----
> >>   include/dt-bindings/power/imx8mm-power.h      |  21 ++
> >>   4 files changed, 333 insertions(+), 66 deletions(-)
> >>   create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >>
> >
> >


From david at redhat.com  Fri Apr  9 14:39:47 2021
From: david at redhat.com (David Hildenbrand)
Date: Fri, 9 Apr 2021 15:39:47 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <CAK8P3a31uKNcim0n99=yt3zjZ+LQSw4V4+8PS8daLsBdS0iSYg@mail.gmail.com>
References: <20210409112035.27221-1-david@redhat.com>
 <CAK8P3a31uKNcim0n99=yt3zjZ+LQSw4V4+8PS8daLsBdS0iSYg@mail.gmail.com>
Message-ID: <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com>

On 09.04.21 15:35, Arnd Bergmann wrote:
> On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand <david at redhat.com> wrote:
>>
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
>> which depends on CMA, if possible; however, these drivers also have to
>> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
>> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
>> driver cannot do it's job properly in some configurations.
>>
>> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and DMA_CMA if
>> available") documents
>>          While this is no build dependency, etnaviv will only work correctly
>>          on most systems if CMA and DMA_CMA are enabled. Select both options
>>          if available to avoid users ending up with a non-working GPU due to
>>          a lacking kernel config.
>> So etnaviv really wants to have DMA_CMA, however, can deal with some cases
>> where it is not available.
>>
>> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
>> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
>> of recursive dependency issues).
>>
>> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
>> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
>>
>> With this change, distributions can disable CONFIG_CMA or
>> CONFIG_DMA_CMA, without it silently getting enabled again by random
>> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
>> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
>> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
>> DRM_KMS_CMA_HELPER.
>>
>> For example, if any driver selects WANT_DMA_CMA and we do a
>> "make olddefconfig":
>>
>> 1. With "# CONFIG_CMA is not set" and no specification of
>>     "CONFIG_DMA_CMA"
>>
>> -> CONFIG_DMA_CMA won't be part of .config
>>
>> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
>>
>> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
>> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
>>
>> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
>>
>> -> CONFIG_DMA_CMA will be removed from .config
>>
>> Note: drivers/remoteproc seems to be special; commit c51e882cd711
>> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
>> there is a real dependency to DMA_CMA for it to work; leave that dependency
>> in place and don't convert it to a soft dependency.
> 
> I don't think this dependency is fundamentally different from the others,
> though davinci machines tend to have less memory than a lot of the
> other machines, so it's more likely to fail without CMA.
> 

I was also unsure - and Lucas had similar thoughts. If you want, I can 
send a v4 also taking care of this.

Thanks!

> Regardless of this,
> 
> Reviewed-by: Arnd Bergmann <arnd at arndb.de>
> 


-- 
Thanks,

David / dhildenb



From tglx at linutronix.de  Fri Apr  9 14:52:48 2021
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 09 Apr 2021 15:52:48 +0200
Subject: [RFC PATCH 05/10] genirq: Let purely flow-masked ONESHOT irqs
 through unmask_threaded_irq()
In-Reply-To: <20210408154326.3988781-6-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
 <20210408154326.3988781-6-valentin.schneider@arm.com>
Message-ID: <87v98v4lan.ffs@nanos.tec.linutronix.de>

On Thu, Apr 08 2021 at 16:43, Valentin Schneider wrote:
> A subsequent patch will let IRQs end up in irq_finalize_oneshot() without
> IRQD_IRQ_MASKED, but with IRQD_IRQ_FLOW_MASKED set instead. Let such IRQs
> receive their final ->irq_eoi().
>
> Signed-off-by: Valentin Schneider <valentin.schneider at arm.com>
> ---
>  kernel/irq/manage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index e976c4927b25..59c8056d6714 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1076,7 +1076,7 @@ static void irq_finalize_oneshot(struct irq_desc *desc,
>  	desc->threads_oneshot &= ~action->thread_mask;
>  
>  	if (!desc->threads_oneshot && !irqd_irq_disabled(&desc->irq_data) &&
> -	    irqd_irq_masked(&desc->irq_data))
> +	    (irqd_irq_masked(&desc->irq_data) || irqd_irq_flow_masked(&desc->irq_data)))
>  		unmask_threaded_irq(desc);

This creates better code when you have '|' instead of '||' because the
compiler can spare a conditional and combine the bit check into one.

Thanks,

        tglx


From tglx at linutronix.de  Fri Apr  9 14:57:28 2021
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 09 Apr 2021 15:57:28 +0200
Subject: [RFC PATCH 06/10] genirq: Don't mask IRQ within flow handler if
 IRQ is flow-masked
In-Reply-To: <20210408154326.3988781-7-valentin.schneider@arm.com>
References: <20210408154326.3988781-1-valentin.schneider@arm.com>
 <20210408154326.3988781-7-valentin.schneider@arm.com>
Message-ID: <87sg3z4l2v.ffs@nanos.tec.linutronix.de>

On Thu, Apr 08 2021 at 16:43, Valentin Schneider wrote:
> +	/*
> +	 * Masking is required if IRQ is ONESHOT and we can't rely on the
> +	 * flow-masking persisting down to irq_finalize_oneshot()
> +	 * (in the IRQ thread).
> +	 */
> +	if ((desc->istate & IRQS_ONESHOT) &&
> +	    (!(chip->flags & IRQCHIP_AUTOMASKS_FLOW) ||
> +	     !(chip->flags & IRQCHIP_EOI_THREADED)))

#define XXXX (IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED)

        ((chip->flags & XXXX) != XXXX)

Hmm?

Thanks,

        tglx


From madvenka at linux.microsoft.com  Fri Apr  9 15:02:41 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 9 Apr 2021 09:02:41 -0500
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210409113101.GA4499@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
 <20210408165825.GP4516@sirena.org.uk>
 <eacc6098-a15f-c07a-2730-cb16cb8e1982@linux.microsoft.com>
 <20210409113101.GA4499@sirena.org.uk>
Message-ID: <75944f33-9a3e-27d9-75df-b2038c10ea02@linux.microsoft.com>



On 4/9/21 6:31 AM, Mark Brown wrote:
> On Thu, Apr 08, 2021 at 02:23:39PM -0500, Madhavan T. Venkataraman wrote:
>> On 4/8/21 11:58 AM, Mark Brown wrote:
> 
>>> This looks good to me however I'd really like someone who has a firmer
>>> understanding of what ftrace is doing to double check as it is entirely
>>> likely that I am missing cases here, it seems likely that if I am
>>> missing stuff it's extra stuff that needs to be added and we're not
>>> actually making use of the reliability information yet.
> 
>> OK. So, do you have some specific reviewer(s) in mind? Apart from yourself, Mark Rutland and
>> Josh Poimboeuf, these are some reviewers I can think of (in alphabetical order):
> 
> Mainly Mark Rutland, but generally someone else who has looked at ftrace
> on arm64 in detail.  It was mainly a comment to say I wasn't going to do
> any kind of Reviewed-by but also hadn't spotted any issues.
> 

Understood.

Madhavan


From srinivas.neeli at xilinx.com  Fri Apr  9 15:08:03 2021
From: srinivas.neeli at xilinx.com (Srinivas Neeli)
Date: Fri, 9 Apr 2021 19:38:03 +0530
Subject: [PATCH 0/3] gpio: zynq: Update on gpio zynq driver
Message-ID: <20210409140806.31824-1-srinivas.neeli@xilinx.com>

This patch series does the following:
-Simplified the code by using module_platform_driver().
-Fixing coverity warnings. 

Srinivas Neeli (3):
  gpio: zynq: use module_platform_driver to simplify the code
  gpio: zynq: Check return value of pm_runtime_get_sync
  gpio: zynq: Check return value of irq_get_irq_data

 drivers/gpio/gpio-zynq.c | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

-- 
2.9.1



From srinivas.neeli at xilinx.com  Fri Apr  9 15:08:04 2021
From: srinivas.neeli at xilinx.com (Srinivas Neeli)
Date: Fri, 9 Apr 2021 19:38:04 +0530
Subject: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify the
 code
In-Reply-To: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
Message-ID: <20210409140806.31824-2-srinivas.neeli@xilinx.com>

module_platform_driver() makes the code simpler by eliminating
boilerplate code.

Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
---
 drivers/gpio/gpio-zynq.c | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index 3521c1dc3ac0..bb1ac0c5cf26 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -1020,22 +1020,7 @@ static struct platform_driver zynq_gpio_driver = {
 	.remove = zynq_gpio_remove,
 };
 
-/**
- * zynq_gpio_init - Initial driver registration call
- *
- * Return: value from platform_driver_register
- */
-static int __init zynq_gpio_init(void)
-{
-	return platform_driver_register(&zynq_gpio_driver);
-}
-postcore_initcall(zynq_gpio_init);
-
-static void __exit zynq_gpio_exit(void)
-{
-	platform_driver_unregister(&zynq_gpio_driver);
-}
-module_exit(zynq_gpio_exit);
+module_platform_driver(zynq_gpio_driver);
 
 MODULE_AUTHOR("Xilinx Inc.");
 MODULE_DESCRIPTION("Zynq GPIO driver");
-- 
2.9.1



From srinivas.neeli at xilinx.com  Fri Apr  9 15:08:06 2021
From: srinivas.neeli at xilinx.com (Srinivas Neeli)
Date: Fri, 9 Apr 2021 19:38:06 +0530
Subject: [PATCH 3/3] gpio: zynq: Check return value of irq_get_irq_data
In-Reply-To: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
Message-ID: <20210409140806.31824-4-srinivas.neeli@xilinx.com>

In two different instances the return value of "irq_get_irq_data"
API was neither captured nor checked.
Fixed it by capturing the return value and then checking for any error.

Addresses-Coverity: "returned_null"
Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
---
 drivers/gpio/gpio-zynq.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index c91302a16c77..f0cb8ccd03ed 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -736,6 +736,11 @@ static int __maybe_unused zynq_gpio_suspend(struct device *dev)
 	struct zynq_gpio *gpio = dev_get_drvdata(dev);
 	struct irq_data *data = irq_get_irq_data(gpio->irq);
 
+	if (!data) {
+		dev_err(dev, "irq_get_irq_data() failed\n");
+		return -EINVAL;
+	}
+
 	if (!device_may_wakeup(dev))
 		disable_irq(gpio->irq);
 
@@ -753,6 +758,11 @@ static int __maybe_unused zynq_gpio_resume(struct device *dev)
 	struct irq_data *data = irq_get_irq_data(gpio->irq);
 	int ret;
 
+	if (!data) {
+		dev_err(dev, "irq_get_irq_data() failed\n");
+		return -EINVAL;
+	}
+
 	if (!device_may_wakeup(dev))
 		enable_irq(gpio->irq);
 
-- 
2.9.1



From srinivas.neeli at xilinx.com  Fri Apr  9 15:08:05 2021
From: srinivas.neeli at xilinx.com (Srinivas Neeli)
Date: Fri, 9 Apr 2021 19:38:05 +0530
Subject: [PATCH 2/3] gpio: zynq: Check return value of pm_runtime_get_sync
In-Reply-To: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
Message-ID: <20210409140806.31824-3-srinivas.neeli@xilinx.com>

Return value of "pm_runtime_get_sync" API was neither captured nor checked.
Fixed it by capturing the return value and then checking for any warning.

Addresses-Coverity: "check_return"
Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
---
 drivers/gpio/gpio-zynq.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
index bb1ac0c5cf26..c91302a16c77 100644
--- a/drivers/gpio/gpio-zynq.c
+++ b/drivers/gpio/gpio-zynq.c
@@ -1001,8 +1001,11 @@ static int zynq_gpio_probe(struct platform_device *pdev)
 static int zynq_gpio_remove(struct platform_device *pdev)
 {
 	struct zynq_gpio *gpio = platform_get_drvdata(pdev);
+	int ret;
 
-	pm_runtime_get_sync(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0)
+		dev_warn(&pdev->dev, "pm_runtime_get_sync() Failed\n");
 	gpiochip_remove(&gpio->chip);
 	clk_disable_unprepare(gpio->clk);
 	device_set_wakeup_capable(&pdev->dev, 0);
-- 
2.9.1



From lkp at intel.com  Fri Apr  9 15:32:24 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 9 Apr 2021 22:32:24 +0800
Subject: [PATCH v6 08/10] coresight: config: Add preloaded configurations
In-Reply-To: <20210409103722.26290-9-mike.leach@linaro.org>
References: <20210409103722.26290-9-mike.leach@linaro.org>
Message-ID: <202104092257.hD7EMfCI-lkp@intel.com>

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20210408]
[also build test ERROR on v5.12-rc6]
[cannot apply to soc/for-next lwn/docs-next linus/master v5.12-rc6 v5.12-rc5 v5.12-rc4]
[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]

url:    https://github.com/0day-ci/linux/commits/Mike-Leach/CoreSight-configuration-management-ETM-strobing/20210409-183900
base:    6145d80cfc62e3ed8f16ff584d6287e6d88b82b9
config: arm-randconfig-s032-20210409 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-279-g6d5d9b42-dirty
        # https://github.com/0day-ci/linux/commit/e97fc23237355b8b816f4e4864206f91a41652cc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mike-Leach/CoreSight-configuration-management-ETM-strobing/20210409-183900
        git checkout e97fc23237355b8b816f4e4864206f91a41652cc
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from drivers/hwtracing/coresight/coresight-etm4x-cfg.h:10,
                    from drivers/hwtracing/coresight/coresight-cfg-afdo.c:8:
>> drivers/hwtracing/coresight/coresight-etm4x.h:143:10: fatal error: asm/sysreg.h: No such file or directory
     143 | #include <asm/sysreg.h>
         |          ^~~~~~~~~~~~~~
   compilation terminated.


sparse warnings: (new ones prefixed by >>)
>> drivers/hwtracing/coresight/coresight-cfg-preload.c:15:9: sparse: sparse: Using plain integer as NULL pointer
   drivers/hwtracing/coresight/coresight-cfg-preload.c:20:9: sparse: sparse: Using plain integer as NULL pointer

vim +143 drivers/hwtracing/coresight/coresight-etm4x.h

03336d0f4d0d74 Suzuki K Poulose 2021-02-01  142  
03336d0f4d0d74 Suzuki K Poulose 2021-02-01 @143  #include <asm/sysreg.h>
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  144  #define ETM4x_REG_NUM_TO_SYSREG(n)				\
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  145  	sys_reg(2, 1, ETM4x_CRn(n), ETM4x_CRm(n), ETM4x_Op2(n))
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  146  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39117 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210409/1825236d/attachment-0001.gz>

From mark.rutland at arm.com  Fri Apr  9 15:32:47 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 9 Apr 2021 15:32:47 +0100
Subject: [PATCH v3] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210409132419.29965-1-vincenzo.frascino@arm.com>
References: <20210409132419.29965-1-vincenzo.frascino@arm.com>
Message-ID: <20210409143247.GA58461@C02TD0UTHF1T.local>

Hi Vincenzo,

On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> race with another CPU doing a set_tsk_thread_flag() and all the other flags
> can be lost in the process.
> 
> Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> exit_to_user_mode() to address the problem.
> 
> Note: Moving the check in entry-common allows to use set_thread_flag()
> which is safe.
> 
> Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous tag check faults")
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: stable at vger.kernel.org
> Reported-by: Will Deacon <will at kernel.org>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> ---
>  arch/arm64/include/asm/mte.h     |  9 +++++++++
>  arch/arm64/kernel/entry-common.c |  6 ++++++
>  arch/arm64/kernel/entry.S        | 34 --------------------------------
>  arch/arm64/kernel/mte.c          | 33 +++++++++++++++++++++++++++++--
>  4 files changed, 46 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 9b557a457f24..c7ab681a95c3 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -49,6 +49,9 @@ int mte_ptrace_copy_tags(struct task_struct *child, long request,
>  
>  void mte_assign_mem_tag_range(void *addr, size_t size);
>  
> +void noinstr check_mte_async_tcf0(void);
> +void noinstr clear_mte_async_tcf0(void);

Can we please put the implementations in the header so that they can be
inlined? Otherwise when the HW doesn't support MTE we'll always do a pointless
branch to the out-of-line implementation.

With that, we can mark them __always_inline to avoid weirdness with an inline
noinstr function.

Otherwise, this looks good to me.

Thanks,
Mark.

> +
>  #else /* CONFIG_ARM64_MTE */
>  
>  /* unused if !CONFIG_ARM64_MTE, silence the compiler */
> @@ -83,6 +86,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
>  {
>  	return -EIO;
>  }
> +static inline void check_mte_async_tcf0(void)
> +{
> +}
> +static inline void clear_mte_async_tcf0(void)
> +{
> +}
>  
>  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
>  {
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 9d3588450473..837d3624a1d5 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
>  	CT_WARN_ON(ct_state() != CONTEXT_USER);
>  	user_exit_irqoff();
>  	trace_hardirqs_off_finish();
> +
> +	/* Check for asynchronous tag check faults in user space */
> +	check_mte_async_tcf0();



>  }
>  
>  asmlinkage void noinstr exit_to_user_mode(void)
>  {
> +	/* Ignore asynchronous tag check faults in the uaccess routines */
> +	clear_mte_async_tcf0();
> +
>  	trace_hardirqs_on_prepare();
>  	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
>  	user_enter_irqoff();
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index a31a0a713c85..fb57df0d453f 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -34,15 +34,11 @@
>   * user and kernel mode.
>   */
>  	.macro user_exit_irqoff
> -#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
>  	bl	enter_from_user_mode
> -#endif
>  	.endm
>  
>  	.macro user_enter_irqoff
> -#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
>  	bl	exit_to_user_mode
> -#endif
>  	.endm
>  
>  	.macro	clear_gp_regs
> @@ -147,32 +143,6 @@ alternative_cb_end
>  .L__asm_ssbd_skip\@:
>  	.endm
>  
> -	/* Check for MTE asynchronous tag check faults */
> -	.macro check_mte_async_tcf, flgs, tmp
> -#ifdef CONFIG_ARM64_MTE
> -alternative_if_not ARM64_MTE
> -	b	1f
> -alternative_else_nop_endif
> -	mrs_s	\tmp, SYS_TFSRE0_EL1
> -	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
> -	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
> -	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
> -	str	\flgs, [tsk, #TSK_TI_FLAGS]
> -	msr_s	SYS_TFSRE0_EL1, xzr
> -1:
> -#endif
> -	.endm
> -
> -	/* Clear the MTE asynchronous tag check faults */
> -	.macro clear_mte_async_tcf
> -#ifdef CONFIG_ARM64_MTE
> -alternative_if ARM64_MTE
> -	dsb	ish
> -	msr_s	SYS_TFSRE0_EL1, xzr
> -alternative_else_nop_endif
> -#endif
> -	.endm
> -
>  	.macro mte_set_gcr, tmp, tmp2
>  #ifdef CONFIG_ARM64_MTE
>  	/*
> @@ -243,8 +213,6 @@ alternative_else_nop_endif
>  	ldr	x19, [tsk, #TSK_TI_FLAGS]
>  	disable_step_tsk x19, x20
>  
> -	/* Check for asynchronous tag check faults in user space */
> -	check_mte_async_tcf x19, x22
>  	apply_ssbd 1, x22, x23
>  
>  	ptrauth_keys_install_kernel tsk, x20, x22, x23
> @@ -775,8 +743,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
>  	cbnz	x2, work_pending
>  finish_ret_to_user:
>  	user_enter_irqoff
> -	/* Ignore asynchronous tag check faults in the uaccess routines */
> -	clear_mte_async_tcf
>  	enable_step_tsk x19, x2
>  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>  	bl	stackleak_erase
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index b3c70a612c7a..84a942c25870 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64 excl)
>  	 */
>  }
>  
> -void flush_mte_state(void)
> +void noinstr check_mte_async_tcf0(void)
> +{
> +	u64 tcf0;
> +
> +	if (!system_supports_mte())
> +		return;
> +
> +	/*
> +	 * dsb(ish) is not required before the register read
> +	 * because the TFSRE0_EL1 is automatically synchronized
> +	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
> +	 * is set.
> +	 */
> +	tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
> +
> +	if (tcf0 & SYS_TFSR_EL1_TF0)
> +		set_thread_flag(TIF_MTE_ASYNC_FAULT);
> +
> +	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}
> +
> +void noinstr clear_mte_async_tcf0(void)
>  {
>  	if (!system_supports_mte())
>  		return;
>  
> -	/* clear any pending asynchronous tag fault */
>  	dsb(ish);
>  	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}
> +
> +void flush_mte_state(void)
> +{
> +	if (!system_supports_mte())
> +		return;
> +
> +	/* clear any pending asynchronous tag fault */
> +	clear_mte_async_tcf0();
>  	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
>  	/* disable tag checking */
>  	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
> -- 
> 2.30.2
> 


From robh at kernel.org  Fri Apr  9 15:47:27 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 09:47:27 -0500
Subject: [PATCH RFC 1/3] fpga: region: Add fpga-region property
 'fpga-config-from-dmabuf'
In-Reply-To: <20210402090933.32276-2-nava.manne@xilinx.com>
References: <20210402090933.32276-1-nava.manne@xilinx.com>
 <20210402090933.32276-2-nava.manne@xilinx.com>
Message-ID: <20210409144727.GA3625530@robh.at.kernel.org>

On Fri, Apr 02, 2021 at 02:39:31PM +0530, Nava kishore Manne wrote:
> Add "fpga-config-from-dmabuf" property to allow the bitstream
> configuration from pre-allocated dma-buffer.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  Documentation/devicetree/bindings/fpga/fpga-region.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> index 969ca53bb65e..c573cf258d60 100644
> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> @@ -177,6 +177,8 @@ Optional properties:
>  	it indicates that the FPGA has already been programmed with this image.
>  	If this property is in an overlay targeting a FPGA region, it is a
>  	request to program the FPGA with that image.
> +- fpga-config-from-dmabuf : boolean, set if the FPGA configured done from the
> +	pre-allocated dma-buffer.

Sounds like an implementation detail of the OS. Doesn't belong in DT.

Rob

>  - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be
>  	controlled during FPGA programming along with the parent FPGA bridge.
>  	This property is optional if the FPGA Manager handles the bridges.
> -- 
> 2.18.0
> 


From catalin.marinas at arm.com  Fri Apr  9 15:47:39 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 9 Apr 2021 15:47:39 +0100
Subject: [PATCH v3] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210409132419.29965-1-vincenzo.frascino@arm.com>
References: <20210409132419.29965-1-vincenzo.frascino@arm.com>
Message-ID: <20210409144738.GB24031@arm.com>

On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index b3c70a612c7a..84a942c25870 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64 excl)
>  	 */
>  }
>  
> -void flush_mte_state(void)
> +void noinstr check_mte_async_tcf0(void)

Nitpick: it looks like naming isn't be entirely consistent with your
kernel async patches:

https://lore.kernel.org/linux-arm-kernel/20210315132019.33202-8-vincenzo.frascino at arm.com/

You could name them mte_check_tfsre0_el1() etc. Also make sure they are
called in similar places in both series.

> +{
> +	u64 tcf0;
> +
> +	if (!system_supports_mte())
> +		return;
> +
> +	/*
> +	 * dsb(ish) is not required before the register read
> +	 * because the TFSRE0_EL1 is automatically synchronized
> +	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
> +	 * is set.
> +	 */
> +	tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
> +
> +	if (tcf0 & SYS_TFSR_EL1_TF0)
> +		set_thread_flag(TIF_MTE_ASYNC_FAULT);
> +
> +	write_sysreg_s(0, SYS_TFSRE0_EL1);

Please move the write_sysreg() inside the 'if' block. If it was 0,
there's no point in a potentially more expensive write.

That said, we only check TFSRE0_EL1 on entry from EL0. Is there a point
in clearing it before we return to EL0? Uaccess routines may set it
anyway.

> +}
> +
> +void noinstr clear_mte_async_tcf0(void)
>  {
>  	if (!system_supports_mte())
>  		return;
>  
> -	/* clear any pending asynchronous tag fault */
>  	dsb(ish);
>  	write_sysreg_s(0, SYS_TFSRE0_EL1);
> +}

I think Mark suggested on your first version that we should keep these
functions in mte.h so that they can be inlined. They are small and only
called in one or two places.

-- 
Catalin


From robh at kernel.org  Fri Apr  9 15:47:57 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 09:47:57 -0500
Subject: [PATCH 1/3] dt-bindings: zynqmp: Add new PD_PL macro
In-Reply-To: <20210402092049.479-2-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-2-nava.manne@xilinx.com>
Message-ID: <20210409144757.GA3628593@robh.at.kernel.org>

On Fri, 02 Apr 2021 14:50:47 +0530, Nava kishore Manne wrote:
> Add new power domain for PL region.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  include/dt-bindings/power/xlnx-zynqmp-power.h | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr  9 15:50:53 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 09:50:53 -0500
Subject: [PATCH 2/3] fpga: region: Add fpga-region property 'power-domains'
In-Reply-To: <20210402092049.479-3-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-3-nava.manne@xilinx.com>
Message-ID: <20210409145053.GA3632538@robh.at.kernel.org>

On Fri, 02 Apr 2021 14:50:48 +0530, Nava kishore Manne wrote:
> Add fpga-region property 'power-domains' to allow to handle
> the FPGA/PL power domins.
> 
> dt-bindings: fpga: Enable PM generic domain support
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  .../devicetree/bindings/fpga/fpga-region.txt       | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From elder at linaro.org  Fri Apr  9 16:08:27 2021
From: elder at linaro.org (Alex Elder)
Date: Fri,  9 Apr 2021 10:08:27 -0500
Subject: [PATCH] ARM: configs: qcom_defconfig: enable IPA and RMNET
Message-ID: <20210409150827.946289-1-elder@linaro.org>

The SDX55 is a 32-bit ARM device that includes IPA v4.5.  Add
CONFIG_QCOM_IPA=m and CONFIG_RMNET=m to "qcom_defconfig".

Signed-off-by: Alex Elder <elder at linaro.org>
---
 arch/arm/configs/qcom_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 3f36887e83330..b30f57399477d 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -85,7 +85,9 @@ CONFIG_NETDEVICES=y
 CONFIG_DUMMY=y
 CONFIG_ATL1C=y
 CONFIG_KS8851=y
+CONFIG_RMNET=m
 CONFIG_SMSC911X=y
+CONFIG_QCOM_IPA=m
 CONFIG_MDIO_BITBANG=y
 CONFIG_MDIO_GPIO=y
 CONFIG_SLIP=y
-- 
2.27.0



From stern at rowland.harvard.edu  Fri Apr  9 16:09:11 2021
From: stern at rowland.harvard.edu (Alan Stern)
Date: Fri, 9 Apr 2021 11:09:11 -0400
Subject: [RFC PATCH] usb: core: reduce power-on-good delay time of root hub
In-Reply-To: <1617935947-24045-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617935947-24045-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <20210409150911.GC1333284@rowland.harvard.edu>

On Fri, Apr 09, 2021 at 10:39:07AM +0800, Chunfeng Yun wrote:
> Return the exactly delay time given by root hub descriptor,
> this helps to reduce resume time etc.
> 
> Due to the root hub descriptor is usually provided by the host
> controller driver, if there is compatibility for a root hub,
> we can fix it easily without affect other root hub
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>

Acked-by: Alan Stern <stern at rowland.harvard.edu>

> ---
>  drivers/usb/core/hub.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 73f4482d833a..22ea1f4f2d66 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -148,8 +148,10 @@ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
>  {
>  	unsigned delay = hub->descriptor->bPwrOn2PwrGood * 2;
>  
> -	/* Wait at least 100 msec for power to become stable */
> -	return max(delay, 100U);
> +	if (!hub->hdev->parent)	/* root hub */
> +		return delay;
> +	else /* Wait at least 100 msec for power to become stable */
> +		return max(delay, 100U);
>  }
>  
>  static inline int hub_port_debounce_be_connected(struct usb_hub *hub,
> -- 
> 2.18.0
> 


From alexandru.elisei at arm.com  Fri Apr  9 16:21:53 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Fri,  9 Apr 2021 16:21:53 +0100
Subject: [PATCH 1/2] KVM: arm64: Don't print warning when trapping SPE
 registers
In-Reply-To: <20210409152154.198566-1-alexandru.elisei@arm.com>
References: <20210409152154.198566-1-alexandru.elisei@arm.com>
Message-ID: <20210409152154.198566-2-alexandru.elisei@arm.com>

KVM sets up MDCR_EL2 to trap accesses to the SPE buffer and sampling
control registers and it relies on the fact that KVM injects an undefined
exception for unknown registers. This mechanism of injecting undefined
exceptions also prints a warning message for the host kernel; for example,
when a guest tries to access PMSIDR_EL1:

[    2.691830] kvm [142]: Unsupported guest sys_reg access at: 80009e78 [800003c5]
[    2.691830]  { Op0( 3), Op1( 0), CRn( 9), CRm( 9), Op2( 7), func_read },

This is unnecessary, because KVM has explicitly configured trapping of
those registers and is well aware of their existence. Prevent the warning
by adding the SPE registers to the list of registers that KVM emulates.
The access function will inject the undefined exception.

Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
---
 arch/arm64/include/asm/sysreg.h |  2 ++
 arch/arm64/kvm/sys_regs.c       | 13 +++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d4a5fca984c3..43bca834c477 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -283,6 +283,8 @@
 #define SYS_PMSIRR_EL1_INTERVAL_MASK	0xffffffUL
 
 /* Filtering controls */
+#define SYS_PMSNEVFR_EL1		sys_reg(3, 0, 9, 9, 1)
+
 #define SYS_PMSFCR_EL1			sys_reg(3, 0, 9, 9, 4)
 #define SYS_PMSFCR_EL1_FE_SHIFT		0
 #define SYS_PMSFCR_EL1_FT_SHIFT		1
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4f2f1e3145de..402cd11aa4fc 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1501,6 +1501,19 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_FAR_EL1), access_vm_reg, reset_unknown, FAR_EL1 },
 	{ SYS_DESC(SYS_PAR_EL1), NULL, reset_unknown, PAR_EL1 },
 
+	{ SYS_DESC(SYS_PMSCR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSNEVFR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSICR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSIRR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSFCR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSEVFR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSLATFR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMSIDR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMBLIMITR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMBPTR_EL1), undef_access },
+	{ SYS_DESC(SYS_PMBSR_EL1), undef_access },
+	/* PMBIDR_EL1 is not trapped */
+
 	{ PMU_SYS_REG(SYS_PMINTENSET_EL1),
 	  .access = access_pminten, .reg = PMINTENSET_EL1 },
 	{ PMU_SYS_REG(SYS_PMINTENCLR_EL1),
-- 
2.31.1



From alexandru.elisei at arm.com  Fri Apr  9 16:21:54 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Fri,  9 Apr 2021 16:21:54 +0100
Subject: [PATCH 2/2] KVM: arm64: Don't advertise FEAT_SPE to guests
In-Reply-To: <20210409152154.198566-1-alexandru.elisei@arm.com>
References: <20210409152154.198566-1-alexandru.elisei@arm.com>
Message-ID: <20210409152154.198566-3-alexandru.elisei@arm.com>

Even though KVM sets up MDCR_EL2 to trap accesses to the SPE buffer and
sampling control registers and to inject an undefined exception, the
presence of FEAT_SPE is still advertised in the ID_AA64DFR0_EL1 register,
if the hardware supports it. Getting an undefined exception when accessing
a register usually happens for a hardware feature which is not implemented,
and indeed this is how PMU emulation is handled when the virtual machine
has been created without the KVM_ARM_VCPU_PMU_V3 feature. Let's be
consistent and never advertise FEAT_SPE, because KVM doesn't have support
for emulating it yet.

Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
---
 arch/arm64/kvm/sys_regs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 402cd11aa4fc..61ee9bfb8826 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1063,6 +1063,8 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
 		val = cpuid_feature_cap_perfmon_field(val,
 						      ID_AA64DFR0_PMUVER_SHIFT,
 						      kvm_vcpu_has_pmu(vcpu) ? ID_AA64DFR0_PMUVER_8_4 : 0);
+		/* Hide SPE from guests */
+		val &= ~FEATURE(ID_AA64DFR0_PMSVER);
 		break;
 	case SYS_ID_DFR0_EL1:
 		/* Limit guests to PMUv3 for ARMv8.4 */
-- 
2.31.1



From alexandru.elisei at arm.com  Fri Apr  9 16:21:52 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Fri,  9 Apr 2021 16:21:52 +0100
Subject: [PATCH 0/2] KVM: arm64: Hide SPE from guests
Message-ID: <20210409152154.198566-1-alexandru.elisei@arm.com>

This was part of the KVM SPE series that I posted some time ago [1]. The
series didn't get too much attention, so I've decided to send this
fix/cleanup/improvement separately, to make it easier to review.

I've split the original patch into two because it makes more sense to me
this way, but I'm not opposed to squashing the series back into a single
patch if that is preferred.

Based on v5.12-rc6.

[1] https://www.spinics.net/lists/kvm-arm/msg42962.html

Alexandru Elisei (2):
  KVM: arm64: Don't print warning when trapping SPE registers
  KVM: arm64: Don't advertise FEAT_SPE to guests

 arch/arm64/include/asm/sysreg.h |  2 ++
 arch/arm64/kvm/sys_regs.c       | 15 +++++++++++++++
 2 files changed, 17 insertions(+)

-- 
2.31.1



From qais.yousef at arm.com  Fri Apr  9 16:33:09 2021
From: qais.yousef at arm.com (Qais Yousef)
Date: Fri, 9 Apr 2021 16:33:09 +0100
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
Message-ID: <20210409153309.wbebto3eufui35qs@e107158-lin>

Adding Linus Walleij back to CC

On 03/30/21 13:40, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin at nokia.com>
> 
> FTRACE's function tracer currently doesn't always work on ARM with
> MODULE_PLT option enabled. If the module is loaded too far, FTRACE's
> code modifier cannot cope with introduced veneers and turns the
> function tracer off globally.
> 
> ARM64 already has a solution for the problem, refer to the following
> patches:
> 
> arm64: ftrace: emit ftrace-mod.o contents through code
> arm64: module-plts: factor out PLT generation code for ftrace
> arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels
> arm64: ftrace: fix building without CONFIG_MODULES
> arm64: ftrace: add support for far branches to dynamic ftrace
> arm64: ftrace: don't validate branch via PLT in ftrace_make_nop()
> 
> But the presented ARM variant has just a half of the footprint in terms of
> the changed LoCs. It also retains the code validation-before-modification
> instead of switching it off.
> 
> Changelog:
> v8:
> * Add warn suppress parameter to arm_gen_branch_link()

I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't
work out for you? I struggle to see how this is better and why it was hard to
incorporate my suggestion.

For example

	-       old = ftrace_call_replace(ip, adjust_address(rec, addr));
	+#ifdef CONFIG_ARM_MODULE_PLTS
	+       /* mod is only supplied during module loading */
	+       if (!mod)
	+               mod = rec->arch.mod;
	+       else
	+               rec->arch.mod = mod;
	+#endif
	+
	+       old = ftrace_call_replace(ip, aaddr,
	+                                 !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod);
	+#ifdef CONFIG_ARM_MODULE_PLTS
	+       if (!old && mod) {
	+               aaddr = get_module_plt(mod, ip, aaddr);
	+               old = ftrace_call_replace(ip, aaddr, true);
	+       }
	+#endif
	+

There's an ifdef, followed by a code that embeds
!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/

And there was no need to make the new warn arg visible all the way to
ftrace_call_repalce() and all of its users.

FWIW

Tested-by: Qais Yousef <qais.yousef at arm.com>

If this gets accepted as-is, I'll send a patch to improve on this.


Thanks

--
Qais Yousef


From Marc.Bonnici at arm.com  Fri Apr  9 16:45:13 2021
From: Marc.Bonnici at arm.com (Marc Bonnici)
Date: Fri, 9 Apr 2021 15:45:13 +0000
Subject: [PATCH v5 6/7] firmware: arm_ffa: Setup in-kernel users of FFA
 partitions
In-Reply-To: <20210325143255.1532452-7-sudeep.holla@arm.com>
References: <20210325143255.1532452-1-sudeep.holla@arm.com>
 <20210325143255.1532452-7-sudeep.holla@arm.com>
Message-ID: <VI1PR08MB356704472CA87B757B89AB5296739@VI1PR08MB3567.eurprd08.prod.outlook.com>

Hi Sudeep, 

> -----Original Message-----
> From: Sudeep Holla <sudeep.holla at arm.com>
> Sent: 25 March 2021 14:33
> To: linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org
> Cc: Sudeep Holla <Sudeep.Holla at arm.com>; Trilok Soni
> <tsoni at codeaurora.org>; arve at android.com; Andrew Walbran
> <qwandor at google.com>; David Hartley <dhh at qti.qualcomm.com>; Achin
> Gupta <Achin.Gupta at arm.com>; Jens Wiklander
> <jens.wiklander at linaro.org>; Arunachalam Ganapathy
> <Arunachalam.Ganapathy at arm.com>; Marc Bonnici <Marc.Bonnici at arm.com>
> Subject: [PATCH v5 6/7] firmware: arm_ffa: Setup in-kernel users of
> FFA partitions
> 
> Parse the FFA nodes from the device-tree and register all the
> partitions whose services will be used in the kernel.
> 
> In order to also enable in-kernel users of FFA interface, let us add
> simple set of operations for such devices.
> 
> The in-kernel users are registered without the character device
> interface.
> 
> Reviewed-by: Jens Wiklander <jens.wiklander at linaro.org>
> Tested-by: Jens Wiklander <jens.wiklander at linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  drivers/firmware/arm_ffa/common.h |   2 +
>  drivers/firmware/arm_ffa/driver.c | 188
> ++++++++++++++++++++++++++++++
>  include/linux/arm_ffa.h           |  38 +++++-
>  3 files changed, 227 insertions(+), 1 deletion(-)
> 
[snip]
> 
> +static int ffa_msg_send_direct_req(u16 src_id, u16 dst_id, bool
> mode_32bit,
> +				   struct ffa_send_direct_data *data) {
> +	u32 req_id, resp_id, src_dst_ids = PACK_TARGET_INFO(src_id,
> dst_id);
> +	ffa_res_t ret;
> +
> +	if (mode_32bit) {
> +		req_id = FFA_MSG_SEND_DIRECT_REQ;
> +		resp_id = FFA_MSG_SEND_DIRECT_RESP;
> +	} else {
> +		req_id = FFA_FN_NATIVE(MSG_SEND_DIRECT_REQ);
> +		resp_id = FFA_FN_NATIVE(MSG_SEND_DIRECT_RESP);
> +	}
> +
> +	ret = invoke_ffa_fn(req_id, src_dst_ids, 0, data->data0, data-
> >data1,
> +			    data->data2, data->data3, data->data4);
> +
> +	while (ret.a0 == FFA_INTERRUPT)
> +		ret = invoke_ffa_fn(FFA_RUN, ret.a1, 0, 0, 0, 0, 0, 0);
> +	if (ret.a0 == FFA_ERROR)
> +		return ffa_to_linux_errno((int)ret.a2);
> +
> +	if (ret.a0 == resp_id) {
> +		data->data0 = ret.a3;
> +		data->data1 = ret.a4;
> +		data->data2 = ret.a5;
> +		data->data3 = ret.a6;
> +		data->data4 = ret.a7;
> +	}
> +
> +	return 0;
> +}	
> +

If the returned function ID is not FFA_ERROR but still not what we're 
expecting here we should return an error to the calling code rather
than success.

Kind Regards
Marc Bonnici


From robh+dt at kernel.org  Fri Apr  9 16:58:35 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 10:58:35 -0500
Subject: [PATCH V2 1/2] dt-bindings: mediatek: mt6359: add ASoC mt6359
 ASoC accdet jack document
In-Reply-To: <CAL_JsqL-TvUZOZ8Eev5zrq2aA59SLLEMVV3Ypq-07bNccp=NRw@mail.gmail.com>
References: <1615383186-18500-1-git-send-email-argus.lin@mediatek.com>
 <1615383186-18500-2-git-send-email-argus.lin@mediatek.com>
 <CAL_JsqL-TvUZOZ8Eev5zrq2aA59SLLEMVV3Ypq-07bNccp=NRw@mail.gmail.com>
Message-ID: <CAL_Jsq+awH=L=qu4HqoL-arA8fsCuEkqf9oYsYnw6=3nq8XENw@mail.gmail.com>

On Wed, Mar 31, 2021 at 9:16 AM Rob Herring <robh+dt at kernel.org> wrote:
>
> On Wed, Mar 10, 2021 at 7:33 AM Argus Lin <argus.lin at mediatek.com> wrote:
> >
> > This patch adds MediaTek MT6359 ASoC accdet jack document.
>
> Seems this never made it to the DT list so no checks ran. It's got all
> sorts of errors:

Still broken in linux-next. Please revert if can't be bothered to fix it.

>
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,four-key-thr: 'oneOf' conditional failed, one must
> be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,four-key-thr: 'oneOf' conditional failed, one must
> be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,four-key-thr: 'oneOf' conditional failed, one must
> be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,accdet-name: 'oneOf' conditional failed, one must
> be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,accdet-name: 'oneOf' conditional failed, one must
> be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,accdet-name: 'oneOf' conditional failed, one must
> be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ext-res: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ext-res: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ext-res: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,tri-key-cdd-thr: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,tri-key-cdd-thr: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,tri-key-cdd-thr: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,pwm-deb-setting: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,pwm-deb-setting: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,pwm-deb-setting: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-num: 'oneOf' conditional failed, one must be
> fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-num: 'oneOf' conditional failed, one must be
> fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-num: 'oneOf' conditional failed, one must be
> fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-vol: 'oneOf' conditional failed, one must be
> fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-vol: 'oneOf' conditional failed, one must be
> fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-vol: 'oneOf' conditional failed, one must be
> fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-trig-mode: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-trig-mode: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-trig-mode: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,three-key-thr: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,three-key-thr: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,three-key-thr: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,key-mode: 'oneOf' conditional failed, one must be
> fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,key-mode: 'oneOf' conditional failed, one must be
> fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,key-mode: 'oneOf' conditional failed, one must be
> fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-comp-vth: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-comp-vth: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-comp-vth: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ap: 'oneOf' conditional failed, one must
> be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ap: 'oneOf' conditional failed, one must
> be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-use-ap: 'oneOf' conditional failed, one must
> be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-mode: 'oneOf' conditional failed, one must be
> fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-mode: 'oneOf' conditional failed, one must be
> fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,mic-mode: 'oneOf' conditional failed, one must be
> fixed:
>  '$ref' is a required property
>  'allOf' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-detect-mode: 'oneOf' conditional failed, one
> must be fixed:
>  'type' is a required property
>  Additional properties are not allowed ('maxItems' was unexpected)
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-detect-mode: 'oneOf' conditional failed, one
> must be fixed:
>  'enum' is a required property
>  'const' is a required property
> /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml:
> properties:mediatek,eint-detect-mode: 'oneOf' conditional failed, one
> must be fixed:
>  '$ref' is a required property
>  'allOf' is a required property
>
>
> > Signed-off-by: Argus Lin <argus.lin at mediatek.com>
> > ---
> >  .../bindings/sound/mt6359-accdet.yaml         | 164 ++++++++++++++++++
> >  1 file changed, 164 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/sound/mt6359-accdet.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml b/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml
> > new file mode 100644
> > index 000000000000..7fb3e8dfb4c5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml
> > @@ -0,0 +1,164 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/sound/mt6359-accdet.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mediatek Technologies Inc. MT6359 ASoC accdet jack driver bindings
> > +
> > +maintainers:
> > +  - Chipeng Chang <chipeng.chang at mediatek.com>
> > +
> > +description: |
> > +  This binding describes the Mediatek Technologies MT6359 ASoC
> > +  accdet jack driver.
> > +
> > +properties:
> > +  mediatek,accdet-name:
> > +    maxItems: 1
> > +    description: named as "mt6359-accdet" jack.
>
> Sounds like a constraint. Why do you need this in DT if only 1 value?
> And why expose an SoC specific name to userspace (I guess)?
>
> > +
> > +  mediatek,mic-vol:
> > +    maxItems: 1
>
> This is an array because 'maxItems' is for arrays? It needs a type
> reference. Same problem throughout.
>
> > +    description: |
> > +      accdet micbias1 voltage.
> > +
> > +      enum:
>
> The indentation is wrong here, so this is just part of 'description'.
>
> > +        - 0x00 # 1.7v - micbias1 volage is 1.7v.
> > +        - 0x01 # 1.8v - micbias1 volage is 1.8v.
> > +        - 0x02 # 1.9v - micbias1 volage is 1.9v.
> > +        - 0x03 # 2.0v - micbias1 volage is 2.0v.
> > +        - 0x04 # 2.1v - micbias1 volage is 2.1v.
> > +        - 0x05 # 2.5v - micbias1 volage is 2.5v.
> > +        - 0x06 # 2.6v - micbias1 volage is 2.6v.
> > +        - 0x07 # 2.7v - micbias1 volage is 2.7v.
> > +        - 0x08 # 2.8v - micbias1 volage is 2.8v.
> > +        - 0x09 # 2.85v - micbias1 volage is 2.85v.
> > +
> > +  mediatek,mic-mode:
> > +    maxItems: 1
> > +    description: |
> > +      value as 1, 2, 6 to indicate ACC/DCC mode. default is DCC mode 2.
> > +
> > +      enum:
> > +        - 0x01 # ACC - ACC mode.
> > +        - 0x02 # DCC - low cost without in bias.
> > +        - 0x06 # DCC - low cost with in bias.
> > +
> > +  mediatek,pwm-deb-setting:
> > +    maxItems: 15
> > +    description: |
> > +       headset-mode-setting : Indicates customized pwm, debounce setting
> > +       accdet pwm_width, pwm_thresh, fall_delay, rise_delay
> > +       debounce0, debounce1, debounce3, debounce4
> > +       eint pwm_width, eint pwm_thresh
> > +       eint deb(debounce0, debounce1, debounce2, debounce3), inv_debounce.
>
> This is a string?
>
> > +
> > +  mediatek,eint-use-ap:
> > +    maxItems: 1
> > +    description: |
> > +      indicates to use ap gpio.
> > +
> > +      enum:
> > +        - 0x00 # MT6359 eint detection mode.
> > +        - 0x01 # SoC GPIO detection mode.
>
> Would boolean work here?
>
> > +
> > +  mediatek,eint-detect-mode:
> > +    maxItems: 1
> > +    description: |
> > +      indicates to use ap gpio.
> > +
> > +      enum:
> > +        - 0x00 # detection mode with higher detection power.
> > +        - 0x01 # detection mode with lower detection power.
> > +        - 0x02 # detection mode with sw moisture detection mode.
> > +        - 0x03 # detection mode with hw moisture detection mode1.
> > +        - 0x04 # detection mode with hw moisture detection mode2.
> > +
> > +  mediatek,eint-num:
> > +    maxItems: 1
> > +    description: |
> > +      incicates pmic eint usage.
> > +
> > +      enum:
> > +        - 0x0 # PMIC_EINT0 - use pmic eint0 to trigger plug interrupt.
> > +        - 0x1 # PMIC_EINT1 - use pmic eint1 to trigger plug interrupt.
> > +        - 0x2 # PMIC_BI_EINT - use pmic eint0/1 to trigger plug interrupt.
> > +
> > +  mediatek,eint-trig-mode:
> > +    maxItems: 1
> > +    description: |
> > +      incicates pmic eint trigger mode.
> > +
> > +      enum:
> > +        - 0x0 # PMIC_GPIO - use pmic gpio to detect plug status.
> > +        - 0x1 # PMIC_INVERTER - use pmic inverter to detect plug status.
>
> Boolean instead?
>
> > +
> > +  mediatek,eint-use-ext-res:
> > +    maxItems: 1
> > +    description: |
> > +      select HP_EINT pull up resistance, default 0 use internal resistance.
> > +
> > +      enum:
> > +        - 0x0 # use internal resistor.
> > +        - 0x1 # use external resistor.
>
> Boolean?
>
> > +
> > +  mediatek,eint-comp-vth:
> > +    maxItems: 1
> > +    description: |
> > +      indicates comparator detection voltage.
> > +
> > +      enum:
> > +        - 0x00 # 2.8v.
> > +        - 0x01 # 2.4v.
> > +        - 0x02 # 2.0v.
> > +        - 0x03 # 0.7v.
> > +
> > +  mediatek,key-mode:
> > +    maxItems: 1
> > +    description: |
> > +      incicates key mode type.
> > +
> > +      enum:
> > +        - 0x0 # THREE_KEY - support 3-key key mode.
> > +        - 0x1 # FOUR_KEY - support 4-key key mode.
> > +        - 0x2 # TRI_KEY_CDD - support 3-key google CDD key mode.
> > +
> > +  mediatek,three-key-thr:
> > +    maxItems: 4
> > +    description: |
> > +      3 key device detection threshold: 0--MD_MAX--UP_MAX--DW_MAX.
> > +
> > +  mediatek,tri-key-cdd-thr:
> > +    maxItems: 4
> > +    description: |
> > +      3 key CDD device detection threshold: 0--MD_MAX--UP_MAX--DW_MAX.
> > +
> > +  mediatek,four-key-thr:
> > +    maxItems: 4
> > +    description: |
> > +      4 key device detection threshold: 0--MD_MAX--VOICE_MAX--UP_MAX--DW_MAX.
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    accdet: accdet {
>
> Where does this node go? You've got no compatible, so it's a child of
> something else?
>
> > +        mediatek,accdet-name = "mt6359-accdet";
> > +        mediatek,mic-vol = <8>;
> > +        mediatek,mic-mode = <2>;
> > +        mediatek,pwm-deb-setting = <0x500 0x500 1 0x1f0
> > +                                    0x800 0x800 0x20 0x44
> > +                                    0x4 0x1
> > +                                    0x5 0x3 0x3 0x5 0xe>;
> > +        mediatek,eint-use-ap = <0>;
> > +        mediatek,eint-detect-mode = <4>;
> > +        mediatek,eint-num = <0>;
> > +        mediatek,eint-trig-mode = <1>;
> > +        mediatek,eint-use-ext-res = <0>;
> > +        mediatek,eint-comp-vth = <2>;
> > +        mediatek,key-mode = <0>;
> > +        mediatek,three-key-thr = <0 80 220 400>;
> > +        status = "okay";
>
> Don't show status in examples.
>
> > +    };
> > +...
>
> > --
> > 2.18.0
> >


From robh at kernel.org  Fri Apr  9 17:07:22 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 11:07:22 -0500
Subject: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc
 binding
In-Reply-To: <20210405155105.162529-29-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-29-eugen.hristev@microchip.com>
Message-ID: <20210409160722.GA3733611@robh.at.kernel.org>

On Mon, Apr 05, 2021 at 06:51:03PM +0300, Eugen Hristev wrote:
> Add bindings for the microchip xisc, a driver based on atmel-isc.
> It shares common code with atmel-isc, but the xisc is the next generation
> ISC which is present on sama7g5 product.
> It has an enhanced pipeline, additional modules, formats, and it supports
> not only parallel sensors, but also serial sensors, by connecting to a demux
> endpoint present on sama7g5.
> One of the key points for creating a new binding is the clocking scheme, as
> atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
> input clock.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
> 
> Hello Rob, all,
> 
> I did not convert this yet to yaml because I would like first your feedback
> if the binding is good.
> If it's fine I will convert both this new binding and the old atmel-isc
> to yaml.

Looks pretty straight forward.

Rob


From robh at kernel.org  Fri Apr  9 17:17:55 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 11:17:55 -0500
Subject: [PATCH 1/2] dt-bindings: serial: stm32: add fifo threshold
 configuration
In-Reply-To: <20210406072122.27384-2-erwan.leray@foss.st.com>
References: <20210406072122.27384-1-erwan.leray@foss.st.com>
 <20210406072122.27384-2-erwan.leray@foss.st.com>
Message-ID: <20210409161755.GA3745930@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 09:21:21AM +0200, Erwan Le Ray wrote:
> Add two optional DT properties, to configure RX and TX fifo threshold:
> - st,rx-fifo-threshold-bytes
> - st,tx-fifo-threshold-bytes
> 
> This patch depends on patch ("dt-bindings: serial: Add rx-tx-swap to stm32-usart").
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
> Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>
> 
> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> index c69f8464cdf3..e163449bf39e 100644
> --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
> @@ -65,6 +65,22 @@ properties:
>    linux,rs485-enabled-at-boot-time: true
>    rs485-rx-during-tx: true
>  
> +  st,rx-fifo-threshold-bytes:
> +    description:
> +      RX FIFO threshold configuration in bytes.
> +      If value is set to 1, RX FIFO threshold is disabled.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [1, 2, 4, 8, 12, 14, 16]
> +    default: 8
> +
> +  st,tx-fifo-threshold-bytes:
> +    description:
> +      TX FIFO threshold configuration in bytes.
> +      If value is set to 1, TX FIFO threshold is disabled.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [1, 2, 4, 8, 12, 14, 16]
> +    default: 8

We already have 'tx-threshold' for 8250, so reuse that and add 
'rx-threshold'.

Rob


From mark.rutland at arm.com  Fri Apr  9 17:18:45 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 9 Apr 2021 17:18:45 +0100
Subject: [PATCH v3] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210409143247.GA58461@C02TD0UTHF1T.local>
References: <20210409132419.29965-1-vincenzo.frascino@arm.com>
 <20210409143247.GA58461@C02TD0UTHF1T.local>
Message-ID: <20210409161030.GA60611@C02TD0UTHF1T.local>

On Fri, Apr 09, 2021 at 03:32:47PM +0100, Mark Rutland wrote:
> Hi Vincenzo,
> 
> On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> > race with another CPU doing a set_tsk_thread_flag() and all the other flags
> > can be lost in the process.
> > 
> > Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> > exit_to_user_mode() to address the problem.
> > 
> > Note: Moving the check in entry-common allows to use set_thread_flag()
> > which is safe.

I've dug into this a bit more, and as set_thread_flag() calls some
potentially-instrumented helpers I don't think this is safe after all
(as e.g. those might cause an EL1 exception and clobber the ESR/FAR/etc
before the EL0 exception handler reads it).

Making that watertight is pretty hairy, as we either need to open-code
set_thread_flag() or go rework a load of core code. If we can use STSET
in the entry asm that'd be simpler, otherwise we'll need something more
involved.

Thanks,
Mark.

> > 
> > Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous tag check faults")
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Cc: stable at vger.kernel.org
> > Reported-by: Will Deacon <will at kernel.org>
> > Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> > ---
> >  arch/arm64/include/asm/mte.h     |  9 +++++++++
> >  arch/arm64/kernel/entry-common.c |  6 ++++++
> >  arch/arm64/kernel/entry.S        | 34 --------------------------------
> >  arch/arm64/kernel/mte.c          | 33 +++++++++++++++++++++++++++++--
> >  4 files changed, 46 insertions(+), 36 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> > index 9b557a457f24..c7ab681a95c3 100644
> > --- a/arch/arm64/include/asm/mte.h
> > +++ b/arch/arm64/include/asm/mte.h
> > @@ -49,6 +49,9 @@ int mte_ptrace_copy_tags(struct task_struct *child, long request,
> >  
> >  void mte_assign_mem_tag_range(void *addr, size_t size);
> >  
> > +void noinstr check_mte_async_tcf0(void);
> > +void noinstr clear_mte_async_tcf0(void);
> 
> Can we please put the implementations in the header so that they can be
> inlined? Otherwise when the HW doesn't support MTE we'll always do a pointless
> branch to the out-of-line implementation.
> 
> With that, we can mark them __always_inline to avoid weirdness with an inline
> noinstr function.
> 
> Otherwise, this looks good to me.
> 
> Thanks,
> Mark.
> 
> > +
> >  #else /* CONFIG_ARM64_MTE */
> >  
> >  /* unused if !CONFIG_ARM64_MTE, silence the compiler */
> > @@ -83,6 +86,12 @@ static inline int mte_ptrace_copy_tags(struct task_struct *child,
> >  {
> >  	return -EIO;
> >  }
> > +static inline void check_mte_async_tcf0(void)
> > +{
> > +}
> > +static inline void clear_mte_async_tcf0(void)
> > +{
> > +}
> >  
> >  static inline void mte_assign_mem_tag_range(void *addr, size_t size)
> >  {
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 9d3588450473..837d3624a1d5 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
> >  	CT_WARN_ON(ct_state() != CONTEXT_USER);
> >  	user_exit_irqoff();
> >  	trace_hardirqs_off_finish();
> > +
> > +	/* Check for asynchronous tag check faults in user space */
> > +	check_mte_async_tcf0();
> 
> 
> 
> >  }
> >  
> >  asmlinkage void noinstr exit_to_user_mode(void)
> >  {
> > +	/* Ignore asynchronous tag check faults in the uaccess routines */
> > +	clear_mte_async_tcf0();
> > +
> >  	trace_hardirqs_on_prepare();
> >  	lockdep_hardirqs_on_prepare(CALLER_ADDR0);
> >  	user_enter_irqoff();
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index a31a0a713c85..fb57df0d453f 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -34,15 +34,11 @@
> >   * user and kernel mode.
> >   */
> >  	.macro user_exit_irqoff
> > -#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
> >  	bl	enter_from_user_mode
> > -#endif
> >  	.endm
> >  
> >  	.macro user_enter_irqoff
> > -#if defined(CONFIG_CONTEXT_TRACKING) || defined(CONFIG_TRACE_IRQFLAGS)
> >  	bl	exit_to_user_mode
> > -#endif
> >  	.endm
> >  
> >  	.macro	clear_gp_regs
> > @@ -147,32 +143,6 @@ alternative_cb_end
> >  .L__asm_ssbd_skip\@:
> >  	.endm
> >  
> > -	/* Check for MTE asynchronous tag check faults */
> > -	.macro check_mte_async_tcf, flgs, tmp
> > -#ifdef CONFIG_ARM64_MTE
> > -alternative_if_not ARM64_MTE
> > -	b	1f
> > -alternative_else_nop_endif
> > -	mrs_s	\tmp, SYS_TFSRE0_EL1
> > -	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
> > -	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
> > -	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
> > -	str	\flgs, [tsk, #TSK_TI_FLAGS]
> > -	msr_s	SYS_TFSRE0_EL1, xzr
> > -1:
> > -#endif
> > -	.endm
> > -
> > -	/* Clear the MTE asynchronous tag check faults */
> > -	.macro clear_mte_async_tcf
> > -#ifdef CONFIG_ARM64_MTE
> > -alternative_if ARM64_MTE
> > -	dsb	ish
> > -	msr_s	SYS_TFSRE0_EL1, xzr
> > -alternative_else_nop_endif
> > -#endif
> > -	.endm
> > -
> >  	.macro mte_set_gcr, tmp, tmp2
> >  #ifdef CONFIG_ARM64_MTE
> >  	/*
> > @@ -243,8 +213,6 @@ alternative_else_nop_endif
> >  	ldr	x19, [tsk, #TSK_TI_FLAGS]
> >  	disable_step_tsk x19, x20
> >  
> > -	/* Check for asynchronous tag check faults in user space */
> > -	check_mte_async_tcf x19, x22
> >  	apply_ssbd 1, x22, x23
> >  
> >  	ptrauth_keys_install_kernel tsk, x20, x22, x23
> > @@ -775,8 +743,6 @@ SYM_CODE_START_LOCAL(ret_to_user)
> >  	cbnz	x2, work_pending
> >  finish_ret_to_user:
> >  	user_enter_irqoff
> > -	/* Ignore asynchronous tag check faults in the uaccess routines */
> > -	clear_mte_async_tcf
> >  	enable_step_tsk x19, x2
> >  #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> >  	bl	stackleak_erase
> > diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> > index b3c70a612c7a..84a942c25870 100644
> > --- a/arch/arm64/kernel/mte.c
> > +++ b/arch/arm64/kernel/mte.c
> > @@ -166,14 +166,43 @@ static void set_gcr_el1_excl(u64 excl)
> >  	 */
> >  }
> >  
> > -void flush_mte_state(void)
> > +void noinstr check_mte_async_tcf0(void)
> > +{
> > +	u64 tcf0;
> > +
> > +	if (!system_supports_mte())
> > +		return;
> > +
> > +	/*
> > +	 * dsb(ish) is not required before the register read
> > +	 * because the TFSRE0_EL1 is automatically synchronized
> > +	 * by the hardware on exception entry as SCTLR_EL1.ITFSB
> > +	 * is set.
> > +	 */
> > +	tcf0 = read_sysreg_s(SYS_TFSRE0_EL1);
> > +
> > +	if (tcf0 & SYS_TFSR_EL1_TF0)
> > +		set_thread_flag(TIF_MTE_ASYNC_FAULT);
> > +
> > +	write_sysreg_s(0, SYS_TFSRE0_EL1);
> > +}
> > +
> > +void noinstr clear_mte_async_tcf0(void)
> >  {
> >  	if (!system_supports_mte())
> >  		return;
> >  
> > -	/* clear any pending asynchronous tag fault */
> >  	dsb(ish);
> >  	write_sysreg_s(0, SYS_TFSRE0_EL1);
> > +}
> > +
> > +void flush_mte_state(void)
> > +{
> > +	if (!system_supports_mte())
> > +		return;
> > +
> > +	/* clear any pending asynchronous tag fault */
> > +	clear_mte_async_tcf0();
> >  	clear_thread_flag(TIF_MTE_ASYNC_FAULT);
> >  	/* disable tag checking */
> >  	set_sctlr_el1_tcf0(SCTLR_EL1_TCF0_NONE);
> > -- 
> > 2.30.2
> > 


From robh at kernel.org  Fri Apr  9 17:18:55 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 11:18:55 -0500
Subject: [PATCH 1/3] dt-bindings: mmc: iproc-sdhci: Convert to json-schema
In-Reply-To: <20210406104802.20898-2-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
 <20210406104802.20898-2-nsaenz@kernel.org>
Message-ID: <20210409161855.GA3750765@robh.at.kernel.org>

On Tue, 06 Apr 2021 12:48:01 +0200, Nicolas Saenz Julienne wrote:
> Convert the brcm,iproc-sdhci binding to DT schema format using json-schema
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> 
> ---
> 
>  .../bindings/mmc/brcm,iproc-sdhci.yaml        | 63 +++++++++++++++++++
>  .../bindings/mmc/brcm,sdhci-iproc.txt         | 37 -----------
>  2 files changed, 63 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
>  delete mode 100644 Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From bjorn.andersson at linaro.org  Fri Apr  9 17:20:01 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Fri,  9 Apr 2021 11:20:01 -0500
Subject: [GIT PULL] More Qualcomm driver updates for 5.13
Message-ID: <20210409162001.775851-1-bjorn.andersson@linaro.org>

The following changes since commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8:

  bus: qcom: Put child node before return (2021-03-29 22:01:27 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-5.13-2

for you to fetch changes up to 0648c55e3a21ccd816e99b6600d6199fbf39d23a:

  soc: qcom: mdt_loader: Detect truncated read of segments (2021-04-08 10:28:59 -0500)

----------------------------------------------------------------
More Qualcomm driver updates for 5.13

This improves the Qualcomm SCM driver logic related to detecting the
calling convention, in particular on SC7180, and fixes a few small
issues in the same.

It introduces additonal sanity checks of the size of loaded segments in
the MDT loader and adds a missing error in the return path of
pdr_register_listener().

It makes it possible to specify the OEM specific firmware path in the
wcn36xx control (and WiFi) driver.

Lastly it adds a missing path specifier in the MAINTAINERS' entry and
fixes a bunch of kerneldoc issues in various drivers.

----------------------------------------------------------------
Bjorn Andersson (5):
      dt-bindings: soc: qcom: wcnss: Add firmware-name property
      soc: qcom: wcnss_ctrl: Introduce local variable "dev"
      soc: qcom: wcnss_ctrl: Allow reading firmware-name from DT
      soc: qcom: mdt_loader: Validate that p_filesz < p_memsz
      soc: qcom: mdt_loader: Detect truncated read of segments

Lukas Bulwahn (2):
      MAINTAINERS: add another entry for ARM/QUALCOMM SUPPORT
      soc: qcom: address kernel-doc warnings

Qinglang Miao (1):
      soc: qcom: pdr: Fix error return code in pdr_register_listener

Stephen Boyd (5):
      firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool
      firmware: qcom_scm: Reduce locking section for __get_convention()
      firmware: qcom_scm: Workaround lack of "is available" call on SC7180
      firmware: qcom_scm: Suppress sysfs bind attributes
      firmware: qcom_scm: Fix kernel-doc function names to match

 .../devicetree/bindings/soc/qcom/qcom,wcnss.txt    |  7 ++
 MAINTAINERS                                        |  1 +
 drivers/firmware/qcom_scm-legacy.c                 |  4 +-
 drivers/firmware/qcom_scm-smc.c                    | 12 +--
 drivers/firmware/qcom_scm.c                        | 89 ++++++++++++----------
 drivers/firmware/qcom_scm.h                        |  7 +-
 drivers/soc/qcom/mdt_loader.c                      | 17 +++++
 drivers/soc/qcom/pdr_interface.c                   |  2 +-
 drivers/soc/qcom/wcnss_ctrl.c                      | 15 ++--
 include/linux/soc/qcom/apr.h                       |  2 +-
 include/linux/soc/qcom/irq.h                       |  2 +-
 include/linux/soc/qcom/llcc-qcom.h                 |  6 +-
 include/linux/soc/qcom/qmi.h                       |  4 +-
 13 files changed, 107 insertions(+), 61 deletions(-)


From hayashi.kunihiko at socionext.com  Fri Apr  9 17:22:15 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Sat, 10 Apr 2021 01:22:15 +0900
Subject: [PATCH v10 0/3] PCI: uniphier: Add PME/AER support for UniPhier PCIe
 host controller
Message-ID: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>

This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.

Changes since v9:
- Fix the description of pcie_prot_service_get_irq()

Changes since v8:
- Add uniphier_pcie_host_init_complete() that finds PME/AER vIRQ number
  after calling dw_pcie_host_init()
- Add conditions to depend on CONFIG_PCIE_PME and CONFIG_PCIEAER instead
  of CONFIG_PCIEPORTBUS
- Add Acked-by: line to portdrv patch

Changes since v7:
- Add Reviewed-by: line to 1st and 3rd patches

Changes since v6:
- Separate patches for iATU and phy error from this series
- Add Reviewed-by: line to dwc patch

Changes since v5:
- Add pcie_port_service_get_irq() function to pcie/portdrv
- Call pcie_port_service_get_irq() to get vIRQ interrupt number for PME/AER
- Rebase to the latest linux-next branch,
  and remove devm_platform_ioremap_resource_byname() replacement patch

Changes since v4:
- Add Acked-by: line to dwc patch

Changes since v3:
- Move msi_host_isr() call into dw_handle_msi_irq()
- Move uniphier_pcie_misc_isr() call into the guard of chained_irq
- Use a bool argument is_msi instead of pci_msi_enabled()
- Consolidate handler calls for the same interrupt
- Fix typos in commit messages

Changes since v2:
- Avoid printing phy error message in case of EPROBE_DEFER
- Fix iATU register mapping method
- dt-bindings: Add Acked-by: line
- Fix typos in commit messages
- Use devm_platform_ioremap_resource_byname()

Changes since v1:
- Add check if struct resource is NULL
- Fix warning in the type of dev_err() argument

Kunihiko Hayashi (3):
  PCI: portdrv: Add pcie_port_service_get_irq() function
  PCI: dwc: Add msi_host_isr() callback
  PCI: uniphier: Add misc interrupt handler to invoke PME and AER

 drivers/pci/controller/dwc/pcie-designware-host.c |   3 +
 drivers/pci/controller/dwc/pcie-designware.h      |   1 +
 drivers/pci/controller/dwc/pcie-uniphier.c        | 101 +++++++++++++++++++---
 drivers/pci/pcie/portdrv.h                        |   1 +
 drivers/pci/pcie/portdrv_core.c                   |  16 ++++
 5 files changed, 110 insertions(+), 12 deletions(-)

-- 
2.7.4



From hayashi.kunihiko at socionext.com  Fri Apr  9 17:22:16 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Sat, 10 Apr 2021 01:22:16 +0900
Subject: [PATCH v10 1/3] PCI: portdrv: Add pcie_port_service_get_irq() function
In-Reply-To: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1617985338-19648-2-git-send-email-hayashi.kunihiko@socionext.com>

Add pcie_port_service_get_irq() that returns the virtual IRQ number
for specified portdrv service.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/pcie/portdrv.h      |  1 +
 drivers/pci/pcie/portdrv_core.c | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index 2ff5724..628a3de 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -144,4 +144,5 @@ static inline void pcie_pme_interrupt_enable(struct pci_dev *dev, bool en) {}
 #endif /* !CONFIG_PCIE_PME */
 
 struct device *pcie_port_find_device(struct pci_dev *dev, u32 service);
+int pcie_port_service_get_irq(struct pci_dev *dev, u32 service);
 #endif /* _PORTDRV_H_ */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e1fed664..b60f0f3 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -477,7 +477,22 @@ struct device *pcie_port_find_device(struct pci_dev *dev,
 }
 EXPORT_SYMBOL_GPL(pcie_port_find_device);
 
+/*
+ * pcie_port_service_get_irq - get irq of the service
+ * @dev: PCI Express port the service is associated with
+ * @service: For the service to find
+ *
+ * Get IRQ number associated with given service on a pci_dev.
+ */
+int pcie_port_service_get_irq(struct pci_dev *dev, u32 service)
+{
+	struct pcie_device *pciedev;
+
+	pciedev = to_pcie_device(pcie_port_find_device(dev, service));
+
+	return pciedev->irq;
+}
+
 /**
  * pcie_port_device_remove - unregister PCI Express port service devices
  * @dev: PCI Express port the service devices to unregister are associated with
-- 
2.7.4



From hayashi.kunihiko at socionext.com  Fri Apr  9 17:22:17 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Sat, 10 Apr 2021 01:22:17 +0900
Subject: [PATCH v10 2/3] PCI: dwc: Add msi_host_isr() callback
In-Reply-To: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1617985338-19648-3-git-send-email-hayashi.kunihiko@socionext.com>

This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.

For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Jingoo Han <jingoohan1 at gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 3 +++
 drivers/pci/controller/dwc/pcie-designware.h      | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 7e55b2b..3cc6311 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -61,6 +61,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
 	irqreturn_t ret = IRQ_NONE;
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 
+	if (pp->ops->msi_host_isr)
+		pp->ops->msi_host_isr(pp);
+
 	num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
 
 	for (i = 0; i < num_ctrls; i++) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 7247c8b..3c15909 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -175,6 +175,7 @@ enum dw_pcie_device_mode {
 struct dw_pcie_host_ops {
 	int (*host_init)(struct pcie_port *pp);
 	int (*msi_host_init)(struct pcie_port *pp);
+	void (*msi_host_isr)(struct pcie_port *pp);
 };
 
 struct pcie_port {
-- 
2.7.4



From hayashi.kunihiko at socionext.com  Fri Apr  9 17:22:18 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Sat, 10 Apr 2021 01:22:18 +0900
Subject: [PATCH v10 3/3] PCI: uniphier: Add misc interrupt handler to invoke
 PME and AER
In-Reply-To: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1617985338-19648-4-git-send-email-hayashi.kunihiko@socionext.com>

This patch adds misc interrupt handler to detect and invoke PME/AER event.

In UniPhier PCIe controller, PME/AER signals are assigned to the same
signal as MSI by the internal logic. These signals should be detected by
the internal register, however, DWC MSI handler can't handle these signals.

DWC MSI handler calls .msi_host_isr() callback function, that detects
PME/AER signals using the internal register and invokes the interrupt
with PME/AER vIRQ numbers.

These vIRQ numbers is obtained by uniphier_pcie_port_get_irq() function,
that finds the device that matches PME/AER from the devices associated
with Root Port, and returns its vIRQ number.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Jingoo Han <jingoohan1 at gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 drivers/pci/controller/dwc/pcie-uniphier.c | 101 +++++++++++++++++++++++++----
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 7e8bad3..bc4db6f 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -21,6 +21,7 @@
 #include <linux/reset.h>
 
 #include "pcie-designware.h"
+#include "../../pcie/portdrv.h"
 
 #define PCL_PINCTRL0			0x002c
 #define PCL_PERST_PLDN_REGEN		BIT(12)
@@ -44,7 +45,9 @@
 #define PCL_SYS_AUX_PWR_DET		BIT(8)
 
 #define PCL_RCV_INT			0x8108
+#define PCL_RCV_INT_ALL_INT_MASK	GENMASK(28, 25)
 #define PCL_RCV_INT_ALL_ENABLE		GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK	GENMASK(12, 9)
 #define PCL_CFG_BW_MGT_STATUS		BIT(4)
 #define PCL_CFG_LINK_AUTO_BW_STATUS	BIT(3)
 #define PCL_CFG_AER_RC_ERR_MSI_STATUS	BIT(2)
@@ -68,6 +71,8 @@ struct uniphier_pcie_priv {
 	struct reset_control *rst;
 	struct phy *phy;
 	struct irq_domain *legacy_irq_domain;
+	int aer_irq;
+	int pme_irq;
 };
 
 #define to_uniphier_pcie(x)	dev_get_drvdata((x)->dev)
@@ -164,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
 
 static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
 {
-	writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+	u32 val;
+
+	val = PCL_RCV_INT_ALL_ENABLE;
+	if (pci_msi_enabled())
+		val |= PCL_RCV_INT_ALL_INT_MASK;
+	else
+		val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+	writel(val, priv->base + PCL_RCV_INT);
 	writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
 }
 
@@ -228,28 +241,51 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
 	.map = uniphier_pcie_intx_map,
 };
 
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp, bool is_msi)
 {
-	struct pcie_port *pp = irq_desc_get_handler_data(desc);
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
-	struct irq_chip *chip = irq_desc_get_chip(desc);
-	unsigned long reg;
-	u32 val, bit, virq;
+	u32 val;
 
-	/* INT for debug */
 	val = readl(priv->base + PCL_RCV_INT);
 
 	if (val & PCL_CFG_BW_MGT_STATUS)
 		dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
 	if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
 		dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
-	if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
-		dev_dbg(pci->dev, "Root Error\n");
-	if (val & PCL_CFG_PME_MSI_STATUS)
-		dev_dbg(pci->dev, "PME Interrupt\n");
+
+	if (is_msi) {
+		if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
+			dev_dbg(pci->dev, "Root Error Status\n");
+			if (priv->aer_irq)
+				generic_handle_irq(priv->aer_irq);
+		}
+
+		if (val & PCL_CFG_PME_MSI_STATUS) {
+			dev_dbg(pci->dev, "PME Interrupt\n");
+			if (priv->pme_irq)
+				generic_handle_irq(priv->pme_irq);
+		}
+	}
 
 	writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_msi_host_isr(struct pcie_port *pp)
+{
+	uniphier_pcie_misc_isr(pp, true);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+	struct pcie_port *pp = irq_desc_get_handler_data(desc);
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+	struct irq_chip *chip = irq_desc_get_chip(desc);
+	unsigned long reg;
+	u32 val, bit, virq;
+
+	uniphier_pcie_misc_isr(pp, false);
 
 	/* INTx */
 	chained_irq_enter(chip, desc);
@@ -317,8 +353,45 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
 	return 0;
 }
 
+static int uniphier_pcie_port_get_irq(struct pcie_port *pp, u32 service)
+{
+	struct pci_dev *pcidev;
+	int irq = 0;
+
+	if (!IS_ENABLED(CONFIG_PCIEAER) && !IS_ENABLED(CONFIG_PCIE_PME))
+		return 0;
+
+	/*
+	 * Finds the device that matches 'service' from the devices
+	 * associated with Root Port, and returns its vIRQ number.
+	 */
+	list_for_each_entry(pcidev, &pp->bridge->bus->devices, bus_list) {
+		irq = pcie_port_service_get_irq(pcidev, service);
+		if (irq)
+			break;
+	}
+
+	return irq;
+}
+
+static int uniphier_pcie_host_init_complete(struct pcie_port *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+
+	if (IS_ENABLED(CONFIG_PCIE_PME))
+		priv->pme_irq =
+			uniphier_pcie_port_get_irq(pp, PCIE_PORT_SERVICE_PME);
+	if (IS_ENABLED(CONFIG_PCIEAER))
+		priv->aer_irq =
+			uniphier_pcie_port_get_irq(pp, PCIE_PORT_SERVICE_AER);
+
+	return 0;
+}
+
 static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
 	.host_init = uniphier_pcie_host_init,
+	.msi_host_isr = uniphier_pcie_msi_host_isr,
 };
 
 static int uniphier_pcie_host_enable(struct uniphier_pcie_priv *priv)
@@ -398,7 +471,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
 
 	priv->pci.pp.ops = &uniphier_pcie_host_ops;
 
-	return dw_pcie_host_init(&priv->pci.pp);
+	ret = dw_pcie_host_init(&priv->pci.pp);
+	if (ret)
+		return ret;
+
+	return uniphier_pcie_host_init_complete(&priv->pci.pp);
 }
 
 static const struct of_device_id uniphier_pcie_match[] = {
-- 
2.7.4



From broonie at kernel.org  Fri Apr  9 17:22:42 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri,  9 Apr 2021 17:22:42 +0100
Subject: [PATCH] spi: imx: add a check for speed_hz before calculating the
 clock
In-Reply-To: <20210408103347.244313-2-xiaoning.wang@nxp.com>
References: <20210408103347.244313-1-xiaoning.wang@nxp.com>
 <20210408103347.244313-2-xiaoning.wang@nxp.com>
Message-ID: <161798356988.48466.14829479576984252197.b4-ty@kernel.org>

On Thu, 8 Apr 2021 18:33:47 +0800, Clark Wang wrote:
> When some drivers use spi to send data, spi_transfer->speed_hz is
> not assigned. If spidev->max_speed_hz is not assigned as well, it
> will cause an error in configuring the clock.
> Add a check for these two values before configuring the clock. An
> error will be returned when they are not assigned.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: imx: add a check for speed_hz before calculating the clock
      commit: 4df2f5e1372e9eec8f9e1b4a3025b9be23487d36

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 Apr  9 17:22:45 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri,  9 Apr 2021 17:22:45 +0100
Subject: [PATCH 0/4] spi: spi-zynqmp-gpspi: fix some issues
In-Reply-To: <20210408040223.23134-1-quanyang.wang@windriver.com>
References: <20210408040223.23134-1-quanyang.wang@windriver.com>
Message-ID: <161798356989.48466.13500615762726622805.b4-ty@kernel.org>

On Thu, 8 Apr 2021 12:02:19 +0800, quanyang.wang at windriver.com wrote:
> This series fix some issues that occurs when the gqspi driver switches to spi-mem framework.
> 
> Hi Amit,
> I rewrite the "Subject" and "commit message" of these patches, so they
> look different from the ones which you reviewed before. I still keep
> your "Reviewed-by" and hope you will not mind.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/4] spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to make zynqmp_qspi_exec_op not interruptible
      commit: a16bff68b75fd082d36aa0b14b540bd7a3ebebbd
[2/4] spi: spi-zynqmp-gqspi: add mutex locking for exec_op
      commit: a0f65be6e880a14d3445b75e7dc03d7d015fc922
[3/4] spi: spi-zynqmp-gqspi: transmit dummy circles by using the controller's internal functionality
      commit: 8ad07d79bd56a531990a1a3f3f1c0eb19d2de806
[4/4] spi: spi-zynqmp-gqspi: fix incorrect operating mode in zynqmp_qspi_read_op
      commit: 41d310930084502433fcb3c4baf219e7424b7734

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 bjorn.andersson at linaro.org  Fri Apr  9 17:23:59 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Fri,  9 Apr 2021 11:23:59 -0500
Subject: [GIT PULL] Qualcomm dts updates for v5.13
Message-ID: <20210409162359.776076-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-dts-for-5.13

for you to fetch changes up to 885aae6860fae1eed38f5cc1ac09a40e4896a38c:

  ARM: dts: qcom: msm8974-klte: Add bluetooth support (2021-04-06 11:53:16 -0500)

----------------------------------------------------------------
Qualcomm dts updates for v5.13

This adds Bluetooth support on the Samsung Galaxy S5, corrects the mount
matrix for the IMU on Nexus 5 and corrects the fuel gauge irq trigger
for the two devices.

----------------------------------------------------------------
Alexey Minnekhanov (2):
      ARM: dts: qcom: msm8974: add blsp2_uart8
      ARM: dts: qcom: msm8974-klte: Add bluetooth support

Krzysztof Kozlowski (2):
      ARM: dts: qcom: msm8974-lge-nexus5: correct fuel gauge interrupt trigger level
      ARM: dts: qcom: msm8974-samsung-klte: correct fuel gauge interrupt trigger level

Luca Weiss (1):
      ARM: dts: qcom: msm8974-hammerhead: add mount matrix for IMU

 .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts     |  6 ++-
 arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts    | 52 +++++++++++++++++++++-
 arch/arm/boot/dts/qcom-msm8974.dtsi                |  9 ++++
 3 files changed, 65 insertions(+), 2 deletions(-)


From robh at kernel.org  Fri Apr  9 17:33:13 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 11:33:13 -0500
Subject: [PATCH V2 15/18] dt-bindings: i2c: imx-lpi2c: Add dma
 configuration example
In-Reply-To: <20210406113306.2633595-16-xiaoning.wang@nxp.com>
References: <20210406113306.2633595-1-xiaoning.wang@nxp.com>
 <20210406113306.2633595-16-xiaoning.wang@nxp.com>
Message-ID: <20210409163313.GA3750926@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 07:33:03PM +0800, Clark Wang wrote:
> Add i2c bus dma mode configuration example.
> 
> Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
> ---
> V2 changes:
>  - New patch added in V2
> ---
>  .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml       | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
> index 0a4b28827dcc..3868fec0cf27 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
> @@ -51,6 +51,16 @@ properties:
>    sda-gpios:
>      maxItems: 1
>  
> +  dmas:
> +    minItems: 2
> +    maxItems: 2
> +
> +  dma-names:
> +    minItems: 2
> +    maxItems: 2
> +    items:
> +      enum: [ "tx", "rx" ]

Please define the order:

items:
  - const: tx
  - const: rx

> +
>  required:
>    - compatible
>    - reg
> @@ -75,4 +85,6 @@ examples:
>          pinctrl-1 = <&pinctrl_i2c_recovery>;
>          scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
>          sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +        dmas = <&edma1 0 16>, <&edma1 0 15>;
> +        dma-names = "tx","rx";
>      };
> -- 
> 2.25.1
> 


From bjorn.andersson at linaro.org  Fri Apr  9 17:39:49 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Fri,  9 Apr 2021 11:39:49 -0500
Subject: [GIT PULL] More Qualcomm ARM64 DT updates for 5.13
Message-ID: <20210409163949.776530-1-bjorn.andersson@linaro.org>

The following changes since commit e9269650db2f5b4aeeafced1a42b2e51d10bcdf5:

  arm64: dts: qcom: qrb5165-rb5: switch into using GPIO for SPI0 CS (2021-03-18 09:35:42 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13-2

for you to fetch changes up to 7178d4cc0702bfe6a7e0f21e37d6e3dfe8e40f11:

  arm64: dts: qcom: update usb qmp phy clock-cells property (2021-04-08 10:23:25 -0500)

----------------------------------------------------------------
More Qualcomm ARM64 DT updates for 5.13

This adds RPMh regulators, coresight, AOSS qmp, ipcc, llcc for the
SC7280. It adds interconnect, PRNG and thermal pieces to SM8350. It
specifies the now required clocks for the SDM845 gcc, corrects the
firmware-name for adsp and cdsp on the db845c and defines DSI and panel
bits for Xiaomi Pocophone F1.

SM8150 gains iommu settings and the remaining I2C controllers and SM8250
gains Venus and the QMP PHY is updated to include the DP portion.

It adds the MSM8998 based OnePlus 5/5T device and enables sound support
on the Trogdor device family.

Lastly it adds the GIC hypervisor registers & interrupt for when Linux
is booted in EL2 on MSM8916.

----------------------------------------------------------------
Ajit Pandey (1):
      arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver

Bryan O'Donoghue (1):
      arm64: dts: qcom: sm8250: Add venus DT node

Caleb Connolly (2):
      arm64: dts: qcom: sm8150: add other QUP nodes and iommus
      arm64: dts: qcom: sm8150: add i2c nodes

Dmitry Baryshkov (4):
      arm64: dts: qcom: sdm845: add required clocks on the gcc
      arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode
      arm64: dts: qcom: use dp_phy to provide clocks to dispcc
      arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware

Jami Kettunen (2):
      arm64: dts: qcom: msm8998: Disable MSS remoteproc by default
      arm64: dts: qcom: Add support for OnePlus 5/5T

Jonathan Marek (2):
      arm64: dts: qcom: sm8250: fix display nodes
      arm64: dts: qcom: update usb qmp phy clock-cells property

Robert Foss (2):
      arm64: dts: qcom: sm8350: Add thermal zones and throttling support
      arm64: dts: qcom: sm8350: Add support for PRNG EE

Sai Prakash Ranjan (4):
      arm64: dts: qcom: sc7280: Add device tree node for LLCC
      arm64: dts: qcom: sc7280: Add IPCC for SC7280 SoC
      arm64: dts: qcom: sc7280: Add AOSS QMP node
      arm64: dts: qcom: sc7280: Add Coresight support

Srinivasa Rao Mandadapu (1):
      arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz

Stephan Gerhold (1):
      arm64: dts: qcom: msm8916: Add GICv2 hypervisor registers/interrupt

Sujit Kautkar (1):
      arm64: dts: qcom: Move rmtfs memory region

Sumit Semwal (1):
      arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits

Vinod Koul (1):
      arm64: dts: qcom: sm8350: Add interconnects

jonathan at marek.ca (1):
      arm64: dts: qcom: sm8250: Add videocc DT node

satya priya (1):
      arm64: dts: qcom: sc7280: Add RPMh regulators for sc7280-idp

 arch/arm64/boot/dts/qcom/Makefile                  |   2 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |   4 +-
 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi    |   4 +
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi          |   4 +
 .../boot/dts/qcom/msm8998-oneplus-cheeseburger.dts |  42 +
 .../boot/dts/qcom/msm8998-oneplus-common.dtsi      | 514 ++++++++++++
 .../boot/dts/qcom/msm8998-oneplus-dumpling.dts     |  25 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi              |   2 +
 .../arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi |  10 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi       |  60 +-
 arch/arm64/boot/dts/qcom/sc7180.dtsi               |   4 +-
 arch/arm64/boot/dts/qcom/sc7280-idp.dts            | 212 +++++
 arch/arm64/boot/dts/qcom/sc7280.dtsi               | 520 ++++++++++++
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts         |   4 +-
 .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts      |  71 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |  16 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi               | 553 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8250.dtsi               | 128 ++-
 arch/arm64/boot/dts/qcom/sm8350.dtsi               | 911 +++++++++++++++++++++
 19 files changed, 3048 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts


From sven at svenpeter.dev  Fri Apr  9 17:49:50 2021
From: sven at svenpeter.dev (Sven Peter)
Date: Fri, 09 Apr 2021 18:49:50 +0200
Subject: [PATCH] iommu: dart: fix call_kern.cocci warnings
In-Reply-To: <alpine.DEB.2.22.394.2104041724340.2958@hadrien>
References: <alpine.DEB.2.22.394.2104041724340.2958@hadrien>
Message-ID: <cc2a3f1f-da43-4767-b00b-6e88ecd3a05c@www.fastmail.com>

On Sun, Apr 4, 2021, at 17:26, Julia Lawall wrote:
> From: kernel test robot <lkp at intel.com>
> 
> Function apple_dart_attach_stream called on line 519 inside
> lock on line 509 but uses GFP_KERNEL

Thanks! Fixed for v3.


Best,


Sven


From sven at svenpeter.dev  Fri Apr  9 17:50:12 2021
From: sven at svenpeter.dev (Sven Peter)
Date: Fri, 09 Apr 2021 18:50:12 +0200
Subject: [PATCH v2 3/3] iommu: dart: Add DART iommu driver
In-Reply-To: <20210407104209.GA15173@willie-the-truck>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-4-sven@svenpeter.dev>
 <20210407104209.GA15173@willie-the-truck>
Message-ID: <10040e18-6e49-432b-b85c-bcc1345a5e18@www.fastmail.com>



On Wed, Apr 7, 2021, at 12:42, Will Deacon wrote:
> On Sun, Mar 28, 2021 at 09:40:09AM +0200, Sven Peter wrote:
> > Apple's new SoCs use iommus for almost all peripherals. These Device
> > Address Resolution Tables must be setup before these peripherals can
> > act as DMA masters.
> > 
> > Signed-off-by: Sven Peter <sven at svenpeter.dev>
> > ---
> >  MAINTAINERS                      |   1 +
> >  drivers/iommu/Kconfig            |  14 +
> >  drivers/iommu/Makefile           |   1 +
> >  drivers/iommu/apple-dart-iommu.c | 858 +++++++++++++++++++++++++++++++
> >  4 files changed, 874 insertions(+)
> >  create mode 100644 drivers/iommu/apple-dart-iommu.c
> 
> [...]
> 
> > +/* must be called with held domain->lock */
> > +static int apple_dart_attach_stream(struct apple_dart_domain *domain,
> > +				    struct apple_dart *dart, u32 sid)
> > +{
> > +	unsigned long flags;
> > +	struct apple_dart_stream *stream;
> > +	struct io_pgtable_cfg *pgtbl_cfg;
> > +	int ret;
> > +
> > +	list_for_each_entry(stream, &domain->streams, stream_head) {
> > +		if (stream->dart == dart && stream->sid == sid) {
> > +			stream->num_devices++;
> > +			return 0;
> > +		}
> > +	}
> > +
> > +	spin_lock_irqsave(&dart->lock, flags);
> > +
> > +	if (WARN_ON(dart->used_sids & BIT(sid))) {
> > +		ret = -EINVAL;
> > +		goto error;
> > +	}
> > +
> > +	stream = kzalloc(sizeof(*stream), GFP_KERNEL);
> > +	if (!stream) {
> > +		ret = -ENOMEM;
> > +		goto error;
> > +	}
> 
> Just in case you missed it, a cocci bot noticed that you're using GFP_KERNEL
> to allocate while holding a spinlock here:
> 
> https://lore.kernel.org/r/alpine.DEB.2.22.394.2104041724340.2958 at hadrien
> 

Thanks for the reminder!
I haven't replied yet because that one was found later when the bot picked up
a (slightly earlier) version that Marc was using to bring up pcie I believe.
I'll fix it for the next version.


Sven


From sven at svenpeter.dev  Fri Apr  9 17:55:07 2021
From: sven at svenpeter.dev (Sven Peter)
Date: Fri, 09 Apr 2021 18:55:07 +0200
Subject: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format
In-Reply-To: <20210407104425.GB15173@willie-the-truck>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-2-sven@svenpeter.dev>
 <20210407104425.GB15173@willie-the-truck>
Message-ID: <e0d9af36-fc6c-4470-a87c-61b9161bdf8f@www.fastmail.com>



On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
[...]
> >  
> > +static struct io_pgtable *
> > +apple_dart_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> > +{
> > +	struct arm_lpae_io_pgtable *data;
> > +
> > +	if (cfg->ias > 36)
> > +		return NULL;
> > +	if (cfg->oas > 36)
> > +		return NULL;
> > +
> > +	if (!cfg->coherent_walk)
> > +		return NULL;
> 
> This all feels like IOMMU-specific limitations leaking into the page-table
> code here; it doesn't feel so unlikely that future implementations of this
> IP might have greater addressing capabilities, for example, and so I don't
> see why the page-table code needs to police this.

That's true, this really doesn't belong here.
I'll fix it for the next version and make sure to keep iommu-specific
limitations inside the driver itself.


> 
> > +	cfg->pgsize_bitmap &= SZ_16K;
> > +	if (!cfg->pgsize_bitmap)
> > +		return NULL;
> 
> This is worrying (and again, I don't think this belongs here). How is this
> thing supposed to work if the CPU is using 4k pages?

This SoC is just full of fun surprises!
I didn't even think about that case since I've always been using 16k pages so far.

I've checked again and wasn't able to find any way to configure the pagesize
of the IOMMU. There seem to be variants of this IP in older iPhones which
support a 4k pagesize but to the best of my knowledge this is hard wired
and not configurable in software.

When booting with 4k pages I hit the BUG_ON in iova.c that ensures that the
iommu pagesize has to be <= the cpu page size.

I see two options here and I'm not sure I like either of them:

1) Just don't support 4k CPU pages together with IOMMU translations and only
   allow full bypass mode there.
   This would however mean that PCIe (i.e. ethernet, usb ports on the Mac
   mini) and possibly Thunderbolt support would not be possible since these
   devices don't seem to like iommu bypass mode at all.

2) I've had a brief discussion on IRC with Arnd about this [1] and he pointed
   out that the dma_map_sg API doesn't make any guarantees about the returned
   iovas and that it might be possible to make this work at least for devices
   that go through the normal DMA API.

   I've then replaced the page size check with a WARN_ON in iova.c just to see
   what happens. At least normal devices that go through the DMA API seem to
   work with my configuration. iommu_dma_alloc took the iommu_dma_alloc_remap
   path which was called with the cpu page size but then used
   domain->pgsize_bitmap to increase that to 16k. So this kinda works out, but
   there are other functions in dma-iommu.c that I believe rely on the fact that
   the iommu can map single cpu pages. This feels very fragile right now and
   would probably require some rather invasive changes.

   Any driver that tries to use the iommu API directly could be trouble
   as well if they make similar assumptions.

   Is this something you would even want to support in the iommu subsytem
   and is it even possible to do this in a sane way?


Best,


Sven


[1] https://freenode.irclog.whitequark.org/asahi/2021-04-07#29609786;


From catalin.marinas at arm.com  Fri Apr  9 17:56:01 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 9 Apr 2021 17:56:01 +0100
Subject: [PATCH v3] arm64: mte: Move MTE TCF0 check in entry-common
In-Reply-To: <20210409161030.GA60611@C02TD0UTHF1T.local>
References: <20210409132419.29965-1-vincenzo.frascino@arm.com>
 <20210409143247.GA58461@C02TD0UTHF1T.local>
 <20210409161030.GA60611@C02TD0UTHF1T.local>
Message-ID: <20210409165601.GE24031@arm.com>

On Fri, Apr 09, 2021 at 05:18:45PM +0100, Mark Rutland wrote:
> On Fri, Apr 09, 2021 at 03:32:47PM +0100, Mark Rutland wrote:
> > Hi Vincenzo,
> > 
> > On Fri, Apr 09, 2021 at 02:24:19PM +0100, Vincenzo Frascino wrote:
> > > The check_mte_async_tcf macro sets the TIF flag non-atomically. This can
> > > race with another CPU doing a set_tsk_thread_flag() and all the other flags
> > > can be lost in the process.
> > > 
> > > Move the tcf0 check to enter_from_user_mode() and clear tcf0 in
> > > exit_to_user_mode() to address the problem.
> > > 
> > > Note: Moving the check in entry-common allows to use set_thread_flag()
> > > which is safe.
> 
> I've dug into this a bit more, and as set_thread_flag() calls some
> potentially-instrumented helpers I don't think this is safe after all
> (as e.g. those might cause an EL1 exception and clobber the ESR/FAR/etc
> before the EL0 exception handler reads it).
> 
> Making that watertight is pretty hairy, as we either need to open-code
> set_thread_flag() or go rework a load of core code. If we can use STSET
> in the entry asm that'd be simpler, otherwise we'll need something more
> involved.

I hacked this up quickly:

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9b4d629f7628..25efe83d68a4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1646,6 +1646,7 @@ config ARM64_AS_HAS_MTE
 config ARM64_MTE
 	bool "Memory Tagging Extension support"
 	default y
+	depends on ARM64_LSE_ATOMICS
 	depends on ARM64_AS_HAS_MTE && ARM64_TAGGED_ADDR_ABI
 	depends on AS_HAS_ARMV8_5
 	# Required for tag checking in the uaccess routines
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a45b4ebbfe7d..ad29892f2974 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -148,16 +148,18 @@ alternative_cb_end
 	.endm
 
 	/* Check for MTE asynchronous tag check faults */
-	.macro check_mte_async_tcf, flgs, tmp
+	.macro check_mte_async_tcf, tmp, ti_flags
 #ifdef CONFIG_ARM64_MTE
+	.arch_extension lse
 alternative_if_not ARM64_MTE
 	b	1f
 alternative_else_nop_endif
 	mrs_s	\tmp, SYS_TFSRE0_EL1
 	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
 	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
-	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
-	str	\flgs, [tsk, #TSK_TI_FLAGS]
+	mov	\tmp, #_TIF_MTE_ASYNC_FAULT
+	add	\ti_flags, tsk, #TSK_TI_FLAGS
+	stset	\tmp, [\ti_flags]
 	msr_s	SYS_TFSRE0_EL1, xzr
 1:
 #endif
@@ -244,7 +246,7 @@ alternative_else_nop_endif
 	disable_step_tsk x19, x20
 
 	/* Check for asynchronous tag check faults in user space */
-	check_mte_async_tcf x19, x22
+	check_mte_async_tcf x22, x23
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23

-- 
Catalin


From madvenka at linux.microsoft.com  Fri Apr  9 18:16:26 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 9 Apr 2021 12:16:26 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409120859.GA51636@C02TD0UTHF1T.local>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
Message-ID: <cb594cb0-f2e7-887e-e454-03971cfcbc53@linux.microsoft.com>



On 4/9/21 7:09 AM, Mark Rutland wrote:
> Hi Madhavan,
> 
> I've noted some concerns below. At a high-level, I'm not keen on the
> blacklisting approach, and I think there's some other preparatory work
> that would be more valuable in the short term.
> 

Some kind of blacklisting has to be done whichever way you do it.

> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>
>> There are a number of places in kernel code where the stack trace is not
>> reliable. Enhance the unwinder to check for those cases and mark the
>> stack trace as unreliable. Once all of the checks are in place, the unwinder
>> can provide a reliable stack trace. But before this can be used for livepatch,
>> some other entity needs to guarantee that the frame pointers are all set up
>> correctly in kernel functions. objtool is currently being worked on to
>> fill that gap.
>>
>> Except for the return address check, all the other checks involve checking
>> the return PC of every frame against certain kernel functions. To do this,
>> implement some infrastructure code:
>>
>> 	- Define a special_functions[] array and populate the array with
>> 	  the special functions
> 
> I'm not too keen on having to manually collate this within the unwinder,
> as it's very painful from a maintenance perspective. I'd much rather we
> could associate this information with the implementations of these
> functions, so that they're more likely to stay in sync.
> 
> Further, I believe all the special cases are assembly functions, and
> most of those are already in special sections to begin with. I reckon
> it'd be simpler and more robust to reject unwinding based on the
> section. If we need to unwind across specific functions in those
> sections, we could opt-in with some metadata. So e.g. we could reject
> all functions in ".entry.text", special casing the EL0 entry functions
> if necessary.
> 

Yes. I have already agreed that using sections is the way to go. I am working
on that now.

> As I mentioned before, I'm currently reworking the entry assembly to
> make this simpler to do. I'd prefer to not make invasive changes in that
> area until that's sorted.
> 

I don't plan to make any invasive changes. But a couple of cosmetic changes may be
necessary. I don't know yet. But I will keep in mind that you don't want
any invasive changes there.

> I think there's a lot more code that we cannot unwind, e.g. KVM
> exception code, or almost anything marked with SYM_CODE_END().
> 

As Mark Brown suggested, I will take a look at all code that is marked as
SYM_CODE. His idea of placing all SYM_CODE in a separate section and blacklisting
that to begin with and refining things as we go along appears to me to be
a reasonable approach.

>> 	- Using kallsyms_lookup(), lookup the symbol table entries for the
>> 	  functions and record their address ranges
>>
>> 	- Define an is_reliable_function(pc) to match a return PC against
>> 	  the special functions.
>>
>> The unwinder calls is_reliable_function(pc) for every return PC and marks
>> the stack trace as reliable or unreliable accordingly.
>>
>> Return address check
>> ====================
>>
>> Check the return PC of every stack frame to make sure that it is a valid
>> kernel text address (and not some generated code, for example).
>>
>> Detect EL1 exception frame
>> ==========================
>>
>> EL1 exceptions can happen on any instruction including instructions in
>> the frame pointer prolog or epilog. Depending on where exactly they happen,
>> they could render the stack trace unreliable.
>>
>> Add all of the EL1 exception handlers to special_functions[].
>>
>> 	- el1_sync()
>> 	- el1_irq()
>> 	- el1_error()
>> 	- el1_sync_invalid()
>> 	- el1_irq_invalid()
>> 	- el1_fiq_invalid()
>> 	- el1_error_invalid()
>>
>> Detect ftrace frame
>> ===================
>>
>> When FTRACE executes at the beginning of a traced function, it creates two
>> frames and calls the tracer function:
>>
>> 	- One frame for the traced function
>>
>> 	- One frame for the caller of the traced function
>>
>> That gives a sensible stack trace while executing in the tracer function.
>> When FTRACE returns to the traced function, the frames are popped and
>> everything is back to normal.
>>
>> However, in cases like live patch, the tracer function redirects execution
>> to a different function. When FTRACE returns, control will go to that target
>> function. A stack trace taken in the tracer function will not show the target
>> function. The target function is the real function that we want to track.
>> So, the stack trace is unreliable.
> 
> This doesn't match my understanding of the reliable stacktrace
> requirements, but I might have misunderstood what you're saying here.
> 
> IIUC what you're describing here is:
> 
> 1) A calls B
> 2) B is traced
> 3) tracer replaces B with TARGET
> 4) tracer returns to TARGET
> 
> ... and if a stacktrace is taken at step 3 (before the return address is
> patched), the trace will show B rather than TARGET.
> 
> My understanding is that this is legitimate behaviour.
> 

My understanding is as follows (correct me if I am wrong):

- Before B is traced, the situation is "A calls B".

- A trace is placed on B to redirect execution to TARGET. Semantically, it
  becomes "A calls TARGET" beyond that point and B is irrelevant.

- But temporarily, the stack trace will show A -> B.

>> To detect stack traces from a tracer function, add the following to
>> special_functions[]:
>>
>> 	- ftrace_call + 4
>>
>> ftrace_call is the label at which the tracer function is patched in. So,
>> ftrace_call + 4 is its return address. This is what will show up in a
>> stack trace taken from the tracer function.
>>
>> When Function Graph Tracing is on, ftrace_graph_caller is patched in
>> at the label ftrace_graph_call. If a tracer function called before it has
>> redirected execution as mentioned above, the stack traces taken from within
>> ftrace_graph_caller will also be unreliable for the same reason as mentioned
>> above. So, add ftrace_graph_caller to special_functions[] as well.
>>
>> Also, the Function Graph Tracer modifies the return address of a traced
>> function to a return trampoline (return_to_handler()) to gather tracing
>> data on function return. Stack traces taken from the traced function and
>> functions it calls will not show the original caller of the traced function.
>> The unwinder handles this case by getting the original caller from FTRACE.
>>
>> However, stack traces taken from the trampoline itself and functions it calls
>> are unreliable as the original return address may not be available in
>> that context. This is because the trampoline calls FTRACE to gather trace
>> data as well as to obtain the actual return address and FTRACE discards the
>> record of the original return address along the way.
> 
> The reason we cannot unwind the trampolines in the usual way is because
> they are not AAPCS compliant functions. We don't discard the original
> return address, but it's not in the usual location.  With care, we could
> write a special case unwinder for them. Note that we also cannot unwind
> from any PLT on the way to the trampolines, so we'd also need to
> identify those.  Luckily we're in charge of creating those, and (for
> now) we only need to care about the module PLTs.
> 
> The bigger problem is return_to_handler, since there's a transient
> period when C code removes the return address from the graph return
> stack before passing this to assembly in a register, and so we can't
> reliably find the correct return address during this period. With care
> we could special case unwinding immediately before/after this.
> 

This is what I meant when I said "as the original return address may not be available in
that context" because the original address is popped off the return address stack
by the ftrace code called from the trampoline.

> If we could find a way to restructure return_to_handler such that we can
> reliably find the correct return address, that would be a useful
> improvement today, and would mean that we don't have to blacklist it for
> reliable stacktrace.
> 

Agreed. But until then it needs to be blacklisted. Rather than wait for that restructuring
to be done, we could initially blacklist it and remove the blacklist if and when the
restructuring is done.

Thanks.

Madhavan


From maz at kernel.org  Fri Apr  9 18:18:57 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 09 Apr 2021 18:18:57 +0100
Subject: [PATCH] KVM: arm64: Fully zero the vcpu state on reset
In-Reply-To: <c34842b2-215a-e9d0-7d9d-a8cd64ed1171@arm.com>
References: <20210407181308.2265808-1-maz@kernel.org>
 <c34842b2-215a-e9d0-7d9d-a8cd64ed1171@arm.com>
Message-ID: <87im4vnzpa.wl-maz@kernel.org>

On Thu, 08 Apr 2021 16:36:40 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> Hi Marc,
> 
> On 4/7/21 7:13 PM, Marc Zyngier wrote:
> > On vcpu reset, we expect all the registers to be brought back
> > to their initial state, which happens to be a bunch of zeroes.
> >
> > However, some recent commit broke this, and is now leaving a bunch
> > of registers (such as a FP state) with whatever was left by the
> > guest. My bad.
> >
> > Just zero the whole vcpu context on reset. It is more than we
> > strictly need, but at least we won't miss anything. This also
> > zeroes the __hyp_running_vcpu pointer, which is always NULL
> > for a vcpu anyway.
> 
> Had a look at struct kvm_cpu_context and indeed the only field which doesn't
> represent a guest register is __hyp_running_vcpu. Did a grep for all the places
> where __hyp_running_vcpu is used, and indeed the assumption is that for a guest
> the pointer is NULL, as __sysreg_restore_el1_state() relies on it.
> 
> >
> > Cc: stable at vger.kernel.org
> > Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only")
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  arch/arm64/kvm/reset.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> > index bd354cd45d28..ef1c49a1a3ad 100644
> > --- a/arch/arm64/kvm/reset.c
> > +++ b/arch/arm64/kvm/reset.c
> > @@ -240,8 +240,8 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> >  		break;
> >  	}
> >  
> > -	/* Reset core registers */
> > -	memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
> > +	/* Zero all registers */
> > +	memset(&vcpu->arch.ctxt, 0, sizeof(vcpu->arch.ctxt));
> 
> Checked that code earlier in the function does not touch the guest
> registers from vcpu->arch.ctxt, to make sure we're not overwriting
> other reset values by mistake.
> Looks good to me:
> 
> Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Scratch that, this is breaks the setting of CNTVOFF, which gets
populated when we create the vcpu. The gotcha is that creating a vcpu
resets CNTVOFF for *all* vcpus:

* If the VMM creates all vcpus, then reset them all, this works
  "fine": all the vcpus have CNTVOFF==0, which is an acceptable
  departure from the current behaviour (where vtime starts at 0).

* If the VMM alternates vcpu creation and reset, then the last vcpu
  ends up with a CNTVOFF set to 0, while all the others have a
  different offset.

QEMU does the former, and kvmtool the latter. Thanks to Will for the
heads up. I'll drop the patch from -next and post a v2 shortly.

Thanks,

	M.

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


From madvenka at linux.microsoft.com  Fri Apr  9 18:23:47 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 9 Apr 2021 12:23:47 -0500
Subject: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack
 trace unreliable
In-Reply-To: <20210409122701.GB51636@C02TD0UTHF1T.local>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210405204313.21346-4-madvenka@linux.microsoft.com>
 <20210409122701.GB51636@C02TD0UTHF1T.local>
Message-ID: <c57de436-7943-175f-29b2-ed7ebcdc0837@linux.microsoft.com>


>> Also, the Function Graph Tracer modifies the return address of a traced
>> function to a return trampoline to gather tracing data on function return.
>> Stack traces taken from that trampoline and functions it calls are
>> unreliable as the original return address may not be available in
>> that context. Mark the stack trace unreliable accordingly.
>>
>> Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
>> ---
>>  arch/arm64/kernel/entry-ftrace.S | 12 +++++++
>>  arch/arm64/kernel/stacktrace.c   | 61 ++++++++++++++++++++++++++++++++
>>  2 files changed, 73 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
>> index b3e4f9a088b1..1f0714a50c71 100644
>> --- a/arch/arm64/kernel/entry-ftrace.S
>> +++ b/arch/arm64/kernel/entry-ftrace.S
>> @@ -86,6 +86,18 @@ SYM_CODE_START(ftrace_caller)
>>  	b	ftrace_common
>>  SYM_CODE_END(ftrace_caller)
>>  
>> +/*
>> + * A stack trace taken from anywhere in the FTRACE trampoline code should be
>> + * considered unreliable as a tracer function (patched at ftrace_call) could
>> + * potentially set pt_regs->pc and redirect execution to a function different
>> + * than the traced function. E.g., livepatch.
> 
> IIUC the issue here that we have two copies of the pc: one in the regs,
> and one in a frame record, and so after the update to the regs, the
> frame record is stale.
> 
> This is something that we could fix by having
> ftrace_instruction_pointer_set() set both.
> 

Yes. I will look at this.

> However, as noted elsewhere there are other issues which mean we'd still
> need special unwinding code for this.
> 

The only other cases we have discussed are EL1 exceptions in the ftrace code
and the return trampoline for function graph tracing. Is there any other case?

Thanks.

Madhavan


From maz at kernel.org  Fri Apr  9 18:32:57 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri,  9 Apr 2021 18:32:57 +0100
Subject: [PATCH v2] KVM: arm64: Fully zero the vcpu state on reset
Message-ID: <20210409173257.3031729-1-maz@kernel.org>

On vcpu reset, we expect all the registers to be brought back
to their initial state, which happens to be a bunch of zeroes.

However, some recent commit broke this, and is now leaving a bunch
of registers (such as the FP state) with whatever was left by the
guest. My bad.

Zero the reset of the state (32bit SPSRs and FPSIMD state).

Cc: stable at vger.kernel.org
Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only")
Signed-off-by: Marc Zyngier <maz at kernel.org>
---

Notes:
    v2: Only reset the FPSIMD state and the AArch32 SPSRs to avoid
    corrupting CNTVOFF in creative ways.

 arch/arm64/kvm/reset.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index bd354cd45d28..4b5acd84b8c8 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -242,6 +242,11 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 
 	/* Reset core registers */
 	memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
+	memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
+	vcpu->arch.ctxt.spsr_abt = 0;
+	vcpu->arch.ctxt.spsr_und = 0;
+	vcpu->arch.ctxt.spsr_irq = 0;
+	vcpu->arch.ctxt.spsr_fiq = 0;
 	vcpu_gp_regs(vcpu)->pstate = pstate;
 
 	/* Reset system registers */
-- 
2.30.2



From f.fainelli at gmail.com  Fri Apr  9 18:34:34 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri,  9 Apr 2021 10:34:34 -0700
Subject: [PATCH] MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
In-Reply-To: <20210409104448.12259-1-nsaenz@kernel.org>
References: <20210409104448.12259-1-nsaenz@kernel.org>
Message-ID: <20210409173434.3036128-1-f.fainelli@gmail.com>

On Fri,  9 Apr 2021 12:44:47 +0200, Nicolas Saenz Julienne <nsaenz at kernel.org> wrote:
> The @kernel.org e-mail address is likely to last longer than the current
> one, so use it.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> ---

Applied to maintainers/next, thanks!
--
Florian


From catalin.marinas at arm.com  Fri Apr  9 18:37:10 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri,  9 Apr 2021 18:37:10 +0100
Subject: [PATCH] arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically
Message-ID: <20210409173710.18582-1-catalin.marinas@arm.com>

The entry from EL0 code checks the TFSRE0_EL1 register for any
asynchronous tag check faults in user space and sets the
TIF_MTE_ASYNC_FAULT flag. This is not done atomically, potentially
racing with another CPU calling set_tsk_thread_flag().

Replace the non-atomic ORR+STR with an STSET instruction. While STSET
requires ARMv8.1 and an assembler that understands LSE atomics, the MTE
feature is part of ARMv8.5 and already requires an updated assembler.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Fixes: 637ec831ea4f ("arm64: mte: Handle synchronous and asynchronous tag check faults")
Cc: <stable at vger.kernel.org> # 5.10.x
Reported-by: Will Deacon <will at kernel.org>
Cc: Will Deacon <will at kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
---

Slightly updated from the inline diff I posted. The MTE dependency is only on
AS_HAS_LSE_ATOMICS rather than the whole LSE feature being enabled.

 arch/arm64/Kconfig        |  6 +++++-
 arch/arm64/kernel/entry.S | 10 ++++++----
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9b4d629f7628..1573cbdf372e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1401,10 +1401,13 @@ config ARM64_PAN
 config AS_HAS_LDAPR
 	def_bool $(as-instr,.arch_extension rcpc)
 
+config AS_HAS_LSE_ATOMICS
+	def_bool $(as-instr,.arch_extension lse)
+
 config ARM64_LSE_ATOMICS
 	bool
 	default ARM64_USE_LSE_ATOMICS
-	depends on $(as-instr,.arch_extension lse)
+	depends on AS_HAS_LSE_ATOMICS
 
 config ARM64_USE_LSE_ATOMICS
 	bool "Atomic instructions"
@@ -1648,6 +1651,7 @@ config ARM64_MTE
 	default y
 	depends on ARM64_AS_HAS_MTE && ARM64_TAGGED_ADDR_ABI
 	depends on AS_HAS_ARMV8_5
+	depends on AS_HAS_LSE_ATOMICS
 	# Required for tag checking in the uaccess routines
 	depends on ARM64_PAN
 	select ARCH_USES_HIGH_VMA_FLAGS
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index a45b4ebbfe7d..ad29892f2974 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -148,16 +148,18 @@ alternative_cb_end
 	.endm
 
 	/* Check for MTE asynchronous tag check faults */
-	.macro check_mte_async_tcf, flgs, tmp
+	.macro check_mte_async_tcf, tmp, ti_flags
 #ifdef CONFIG_ARM64_MTE
+	.arch_extension lse
 alternative_if_not ARM64_MTE
 	b	1f
 alternative_else_nop_endif
 	mrs_s	\tmp, SYS_TFSRE0_EL1
 	tbz	\tmp, #SYS_TFSR_EL1_TF0_SHIFT, 1f
 	/* Asynchronous TCF occurred for TTBR0 access, set the TI flag */
-	orr	\flgs, \flgs, #_TIF_MTE_ASYNC_FAULT
-	str	\flgs, [tsk, #TSK_TI_FLAGS]
+	mov	\tmp, #_TIF_MTE_ASYNC_FAULT
+	add	\ti_flags, tsk, #TSK_TI_FLAGS
+	stset	\tmp, [\ti_flags]
 	msr_s	SYS_TFSRE0_EL1, xzr
 1:
 #endif
@@ -244,7 +246,7 @@ alternative_else_nop_endif
 	disable_step_tsk x19, x20
 
 	/* Check for asynchronous tag check faults in user space */
-	check_mte_async_tcf x19, x22
+	check_mte_async_tcf x22, x23
 	apply_ssbd 1, x22, x23
 
 	ptrauth_keys_install_kernel tsk, x20, x22, x23


From f.fainelli at gmail.com  Fri Apr  9 18:47:21 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri,  9 Apr 2021 10:47:21 -0700
Subject: [PATCH] mailmap: Update email address for Nicolas Saenz
In-Reply-To: <20210409111453.28121-1-nsaenz@kernel.org>
References: <20210409111453.28121-1-nsaenz@kernel.org>
Message-ID: <20210409174721.3050449-1-f.fainelli@gmail.com>

On Fri,  9 Apr 2021 13:14:53 +0200, Nicolas Saenz Julienne <nsaenz at kernel.org> wrote:
> Add my kernel.org address for old email address.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> ---

Applied to maintainers/next, thanks!
--
Florian


From f.fainelli at gmail.com  Fri Apr  9 18:50:18 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri,  9 Apr 2021 10:50:18 -0700
Subject: [GIT PULL] Broadcom maintainers changes for 5.13
Message-ID: <20210409175018.3051283-1-f.fainelli@gmail.com>

The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:

  Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)

are available in the Git repository at:

  https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.13/maintainers

for you to fetch changes up to 0072f6c37f02071821eb2135b80daa404d783704:

  mailmap: Update email address for Nicolas Saenz (2021-04-09 10:47:17 -0700)

----------------------------------------------------------------
This pull request contains Broadcom SoC MAINTAINERS file entries and
.mailmap updates for 5.13, please pull the following:

- Nicolas updates his maintainer email to a kernel.org address for
  continuity

----------------------------------------------------------------
Nicolas Saenz Julienne (2):
      MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
      mailmap: Update email address for Nicolas Saenz

 .mailmap    | 2 ++
 MAINTAINERS | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)


From robh at kernel.org  Fri Apr  9 18:55:51 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 12:55:51 -0500
Subject: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210406155053.29101-1-jbx6244@gmail.com>
References: <20210406155053.29101-1-jbx6244@gmail.com>
Message-ID: <20210409175551.GA3769113@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 05:50:52PM +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 ---------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 66 ++++++++++++++++++++++
>  2 files changed, 66 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> deleted file mode 100644
> index f70956dea..000000000
> --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> -Rockchip PWM controller
> -
> -Required properties:
> - - compatible: should be "rockchip,<name>-pwm"
> -   "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
> -   "rockchip,rk3288-pwm": found on RK3288 SOC
> -   "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
> -   "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
> - - reg: physical base address and length of the controller's registers
> - - clocks: See ../clock/clock-bindings.txt
> -   - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
> -     - There is one clock that's used both to derive the functional clock
> -       for the device and as the bus clock.
> -   - For newer hardware (rk3328 and future socs): specified by name
> -     - "pwm": This is used to derive the functional clock.
> -     - "pclk": This is the APB bus clock.
> - - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this directory
> -   for a description of the cell format.
> -
> -Example:
> -
> -	pwm0: pwm at 20030000 {
> -		compatible = "rockchip,rk2928-pwm";
> -		reg = <0x20030000 0x10>;
> -		clocks = <&cru PCLK_PWM01>;
> -		#pwm-cells = <2>;
> -	};
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> new file mode 100644
> index 000000000..cfd637d3e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip PWM controller
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - const: rockchip,rk2928-pwm
> +      - const: rockchip,rk3288-pwm
> +      - const: rockchip,vop-pwm
> +      - items:
> +          - enum:
> +              - rockchip,rv1108-pwm
> +          - const: rockchip,rk3288-pwm
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    minItems: 1
> +    maxItems: 2
> +    description:
> +      For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399)
> +        There is one clock that is used both to derive the functional clock
> +        for the device and as the bus clock.
> +      For newer hardware (rk3328 and future SoCs) that is also specified

Can you express this with a schema.

> +      with clock names.
> +        "pwm" is used to derive the functional clock for the device.
> +        "pclk" is used as the APB bus clock.

Let's not document the names twice.

> +
> +  clock-names:
> +    minItems: 1
> +    items:
> +      - const: pwm
> +      - const: pclk
> +
> +  "#pwm-cells":
> +    enum: [2, 3]
> +    description:
> +      Must be 2 (rk2928) or 3 (rk3288).
> +      See pwm.yaml for a description of the cell format.
> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - "#pwm-cells"
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3188-cru-common.h>
> +    pwm0: pwm at 20030000 {
> +      compatible = "rockchip,rk2928-pwm";
> +      reg = <0x20030000 0x10>;
> +      clocks = <&cru PCLK_PWM01>;
> +      #pwm-cells = <2>;
> +    };
> -- 
> 2.11.0
> 


From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:55:58 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:25:58 +0530
Subject: [RFC v2 PATCH 0/7] Xilinx DMA enhancements and optimization
Message-ID: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>


Some background about the patch series: Xilinx Axi Ethernet device driver
(xilinx_axienet_main.c) currently has axi-dma code inside it. The goal
is to refactor axiethernet driver and use existing AXI DMA driver using
DMAEngine API.

This patchset does feature addition and optimization to support
axidma integration with axiethernet network driver. Once axidma 
version is accepted mcdma specific changes will be added in 
followup version.

This series is based on dmaengine tree commit: #a38fd8748464

Changes for v2:
- Use metadata API[1] for passing metadata from dma to netdev client.
- Read irq-delay from DT.
- Remove desc_callback_valid check.
- Addressed RFC v1 comments[2].
- Minor code refactoring.

Comments, suggestions are very welcome!


[1] https://www.spinics.net/lists/dmaengine/msg16583.html
[2] https://www.spinics.net/lists/dmaengine/msg15208.html

Radhey Shyam Pandey (7):
  dt-bindings: dmaengine: xilinx_dma: Add xlnx,axistream-connected
    property
  dt-bindings: dmaengine: xilinx_dma: Add xlnx,irq-delay property
  dmaengine: xilinx_dma: Pass AXI4-Stream control words to dma client
  dmaengine: xilinx_dma: Increase AXI DMA transaction segment count
  dmaengine: xilinx_dma: Freeup active list based on descriptor
    completion bit
  dmaengine: xilinx_dma: Use tasklet_hi_schedule for timing critical
    usecase
  dmaengine: xilinx_dma: Program interrupt delay timeout

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |  4 ++
 drivers/dma/xilinx/xilinx_dma.c                    | 68 ++++++++++++++++++----
 2 files changed, 61 insertions(+), 11 deletions(-)

-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:55:59 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:25:59 +0530
Subject: [RFC v2 PATCH 1/7] dt-bindings: dmaengine: xilinx_dma: Add xlnx,
 axistream-connected property
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-2-git-send-email-radhey.shyam.pandey@xilinx.com>

Add an optional DMA property 'xlnx,axistream-connected'. This can be
specified to indicate that DMA is connected to a streaming IP in the
hardware design and dma driver needs to do some additional handling
i.e pass metadata and perform streaming IP specific configuration.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Changes for v2:
- Rename xlnx,axieth-connected to xlnx,axistream-connected to
  make it generic.
---
 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index 325aca52cd43..f5f23a4a4467 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -49,6 +49,8 @@ Optional properties for AXI DMA and MCDMA:
 	register as configured in h/w. Takes values {8...26}. If the property
 	is missing or invalid then the default value 23 is used. This is the
 	maximum value that is supported by all IP versions.
+- xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
+
 Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
 	It takes following values:
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:02 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:02 +0530
Subject: [RFC v2 PATCH 4/7] dmaengine: xilinx_dma: Increase AXI DMA
 transaction segment count
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-5-git-send-email-radhey.shyam.pandey@xilinx.com>

Increase AXI DMA transaction segments count to ensure that even in
high load we always get a free segment in prepare descriptor for a
DMA_SLAVE transaction.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Changes for v2:
- None
---
 drivers/dma/xilinx/xilinx_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 14dcfc473e52..890bf46b36e5 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -178,7 +178,7 @@
 #define XILINX_DMA_BD_SOP		BIT(27)
 #define XILINX_DMA_BD_EOP		BIT(26)
 #define XILINX_DMA_COALESCE_MAX		255
-#define XILINX_DMA_NUM_DESCS		255
+#define XILINX_DMA_NUM_DESCS		512
 #define XILINX_DMA_NUM_APP_WORDS	5
 
 /* AXI CDMA Specific Registers/Offsets */
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:00 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:00 +0530
Subject: [RFC v2 PATCH 2/7] dt-bindings: dmaengine: xilinx_dma: Add xlnx,
 irq-delay property
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-3-git-send-email-radhey.shyam.pandey@xilinx.com>

Add an optional AXI DMA property 'xlnx,irq-delay'. It specifies interrupt
timeout value and causes the DMA engine to generate an interrupt after the
delay time period has expired. Timer begins counting at the end of a packet
and resets with receipt of a new packet or a timeout event occurs.

This property is useful when AXI DMA is connected to the streaming IP i.e
axiethernet where inter packet latency is critical while still taking the
benefit of interrupt coalescing.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Changes for v2:
- New patch. Introduce xlnx,irq-delay property for low latency usecases
---
 Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index f5f23a4a4467..96009ced7b29 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -50,7 +50,9 @@ Optional properties for AXI DMA and MCDMA:
 	is missing or invalid then the default value 23 is used. This is the
 	maximum value that is supported by all IP versions.
 - xlnx,axistream-connected: Tells whether DMA is connected to AXI stream IP.
-
+- xlnx,irq-delay: Tells the interrupt delay timeout value. Valid range is from
+	0-255. Setting this value to zero disables the delay timer interrupt.
+	1 timeout interval = 125 * clock period of SG clock.
 Optional properties for VDMA:
 - xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
 	It takes following values:
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:01 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:01 +0530
Subject: [RFC v2 PATCH 3/7] dmaengine: xilinx_dma: Pass AXI4-Stream control
 words to dma client
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-4-git-send-email-radhey.shyam.pandey@xilinx.com>

Read DT property to check if AXI DMA is connected to streaming IP
i.e axiethernet. If connected pass AXI4-Stream control words to
dma client using metadata_ops dmaengine API.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Changes for v2:
- Use descriptor metadata API to pass control words to dma client.
- Rephrased commit description to be inline with implementation.
---
 drivers/dma/xilinx/xilinx_dma.c | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3aded7861fef..14dcfc473e52 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -491,6 +491,7 @@ struct xilinx_dma_config {
  * @s2mm_chan_id: DMA s2mm channel identifier
  * @mm2s_chan_id: DMA mm2s channel identifier
  * @max_buffer_len: Max buffer length
+ * @has_axistream_connected: AXI DMA connected to AXI Stream IP
  */
 struct xilinx_dma_device {
 	void __iomem *regs;
@@ -509,6 +510,7 @@ struct xilinx_dma_device {
 	u32 s2mm_chan_id;
 	u32 mm2s_chan_id;
 	u32 max_buffer_len;
+	bool has_axistream_connected;
 };
 
 /* Macros */
@@ -621,6 +623,29 @@ static inline void xilinx_aximcdma_buf(struct xilinx_dma_chan *chan,
 	}
 }
 
+/**
+ * xilinx_dma_get_metadata_ptr- Populate metadata pointer and payload length
+ * @tx: async transaction descriptor
+ * @payload_len: metadata payload length
+ * @max_len: metadata max length
+ * Return: The app field pointer.
+ */
+static void *xilinx_dma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
+					 size_t *payload_len, size_t *max_len)
+{
+	struct xilinx_dma_tx_descriptor *desc = to_dma_tx_descriptor(tx);
+	struct xilinx_axidma_tx_segment *seg;
+
+	*max_len = *payload_len = sizeof(u32) * XILINX_DMA_NUM_APP_WORDS;
+	seg = list_first_entry(&desc->segments,
+			       struct xilinx_axidma_tx_segment, node);
+	return seg->hw.app;
+}
+
+static struct dma_descriptor_metadata_ops xilinx_dma_metadata_ops = {
+	.get_ptr = xilinx_dma_get_metadata_ptr,
+};
+
 /* -----------------------------------------------------------------------------
  * Descriptors and segments alloc and free
  */
@@ -2200,6 +2225,9 @@ static struct dma_async_tx_descriptor *xilinx_dma_prep_slave_sg(
 		segment->hw.control |= XILINX_DMA_BD_EOP;
 	}
 
+	if (chan->xdev->has_axistream_connected)
+		desc->async_tx.metadata_ops = &xilinx_dma_metadata_ops;
+
 	return &desc->async_tx;
 
 error:
@@ -3032,6 +3060,11 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 		}
 	}
 
+	if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
+		xdev->has_axistream_connected =
+			of_property_read_bool(node, "xlnx,axistream-connected");
+	}
+
 	if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
 		err = of_property_read_u32(node, "xlnx,num-fstores",
 					   &num_frames);
@@ -3057,6 +3090,10 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	else
 		xdev->ext_addr = false;
 
+	/* Set metadata mode */
+	if (xdev->has_axistream_connected)
+		xdev->common.desc_metadata_modes = DESC_METADATA_ENGINE;
+
 	/* Set the dma mask bits */
 	dma_set_mask(xdev->dev, DMA_BIT_MASK(addr_width));
 
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:03 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:03 +0530
Subject: [RFC v2 PATCH 5/7] dmaengine: xilinx_dma: Freeup active list based on
 descriptor completion bit
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-6-git-send-email-radhey.shyam.pandey@xilinx.com>

AXIDMA IP in SG mode sets completion bit to 1 when the transfer is
completed. Read this bit to move descriptor from active list to the
done list. This feature is needed when interrupt delay timeout and
IRQThreshold is enabled i.e Dly_IrqEn is triggered w/o completing
interrupt threshold.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
- Check BD completion bit only for SG mode.
- Modify the logic to have early return path.
---
 drivers/dma/xilinx/xilinx_dma.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 890bf46b36e5..f2305a73cb91 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -177,6 +177,7 @@
 #define XILINX_DMA_CR_COALESCE_SHIFT	16
 #define XILINX_DMA_BD_SOP		BIT(27)
 #define XILINX_DMA_BD_EOP		BIT(26)
+#define XILINX_DMA_BD_COMP_MASK		BIT(31)
 #define XILINX_DMA_COALESCE_MAX		255
 #define XILINX_DMA_NUM_DESCS		512
 #define XILINX_DMA_NUM_APP_WORDS	5
@@ -1683,12 +1684,18 @@ static void xilinx_dma_issue_pending(struct dma_chan *dchan)
 static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
 {
 	struct xilinx_dma_tx_descriptor *desc, *next;
+	struct xilinx_axidma_tx_segment *seg;
 
 	/* This function was invoked with lock held */
 	if (list_empty(&chan->active_list))
 		return;
 
 	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
+		/* TODO: remove hardcoding for axidma_tx_segment */
+		seg = list_last_entry(&desc->segments,
+				      struct xilinx_axidma_tx_segment, node);
+		if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
+			break;
 		if (chan->has_sg && chan->xdev->dma_config->dmatype !=
 		    XDMA_TYPE_VDMA)
 			desc->residue = xilinx_dma_get_residue(chan, desc);
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:04 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:04 +0530
Subject: [RFC v2 PATCH 6/7] dmaengine: xilinx_dma: Use tasklet_hi_schedule for
 timing critical usecase
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-7-git-send-email-radhey.shyam.pandey@xilinx.com>

Schedule tasklet with high priority to ensure that callback processing
is prioritized. It improves throughput for netdev dma clients.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
--
Changes for v2:
- None
---
 drivers/dma/xilinx/xilinx_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index f2305a73cb91..a2ea2d649332 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -1829,7 +1829,7 @@ static irqreturn_t xilinx_mcdma_irq_handler(int irq, void *data)
 		spin_unlock(&chan->lock);
 	}
 
-	tasklet_schedule(&chan->tasklet);
+	tasklet_hi_schedule(&chan->tasklet);
 	return IRQ_HANDLED;
 }
 
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 18:56:05 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:26:05 +0530
Subject: [RFC v2 PATCH 7/7] dmaengine: xilinx_dma: Program interrupt delay
 timeout
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617990965-35337-8-git-send-email-radhey.shyam.pandey@xilinx.com>

Program IRQDelay for AXI DMA. The interrupt timeout mechanism causes
the DMA engine to generate an interrupt after the delay time period
has expired. It enables dmaengine to respond in real-time even though
interrupt coalescing is configured. It also remove the placeholder
for delay interrupt and merge it with frame completion interrupt.
Since by default interrupt delay timeout is disabled this feature
addition has no functional impact on VDMA and CDMA IP's.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Changes for v2:
- Read irq delay timeout value from DT.
- Merge interrupt processing for frame done and delay interrupt.
---
 drivers/dma/xilinx/xilinx_dma.c | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index a2ea2d649332..0c0dc9882a01 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -173,8 +173,10 @@
 #define XILINX_DMA_MAX_TRANS_LEN_MAX	23
 #define XILINX_DMA_V2_MAX_TRANS_LEN_MAX	26
 #define XILINX_DMA_CR_COALESCE_MAX	GENMASK(23, 16)
+#define XILINX_DMA_CR_DELAY_MAX		GENMASK(31, 24)
 #define XILINX_DMA_CR_CYCLIC_BD_EN_MASK	BIT(4)
 #define XILINX_DMA_CR_COALESCE_SHIFT	16
+#define XILINX_DMA_CR_DELAY_SHIFT	24
 #define XILINX_DMA_BD_SOP		BIT(27)
 #define XILINX_DMA_BD_EOP		BIT(26)
 #define XILINX_DMA_BD_COMP_MASK		BIT(31)
@@ -410,6 +412,7 @@ struct xilinx_dma_tx_descriptor {
  * @stop_transfer: Differentiate b/w DMA IP's quiesce
  * @tdest: TDEST value for mcdma
  * @has_vflip: S2MM vertical flip
+ * @irq_delay: Interrupt delay timeout
  */
 struct xilinx_dma_chan {
 	struct xilinx_dma_device *xdev;
@@ -447,6 +450,7 @@ struct xilinx_dma_chan {
 	int (*stop_transfer)(struct xilinx_dma_chan *chan);
 	u16 tdest;
 	bool has_vflip;
+	u8 irq_delay;
 };
 
 /**
@@ -1555,6 +1559,9 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
 	if (chan->has_sg)
 		xilinx_write(chan, XILINX_DMA_REG_CURDESC,
 			     head_desc->async_tx.phys);
+	reg  &= ~XILINX_DMA_CR_DELAY_MAX;
+	reg  |= chan->irq_delay << XILINX_DMA_CR_DELAY_SHIFT;
+	dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
 
 	xilinx_dma_start(chan);
 
@@ -1877,15 +1884,8 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
 		}
 	}
 
-	if (status & XILINX_DMA_DMASR_DLY_CNT_IRQ) {
-		/*
-		 * Device takes too long to do the transfer when user requires
-		 * responsiveness.
-		 */
-		dev_dbg(chan->dev, "Inter-packet latency too long\n");
-	}
-
-	if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
+	if (status & (XILINX_DMA_DMASR_FRM_CNT_IRQ |
+		      XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
 		spin_lock(&chan->lock);
 		xilinx_dma_complete_descriptor(chan);
 		chan->idle = true;
@@ -2802,6 +2802,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
 	/* Retrieve the channel properties from the device tree */
 	has_dre = of_property_read_bool(node, "xlnx,include-dre");
 
+	of_property_read_u8(node, "xlnx,irq-delay", &chan->irq_delay);
+
 	chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
 
 	err = of_property_read_u32(node, "xlnx,datawidth", &value);
-- 
2.7.4



From robh at kernel.org  Fri Apr  9 19:07:52 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:07:52 -0500
Subject: [PATCH v1 1/2] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <8f05dc0d-8fb7-c200-5251-d9e147b1d00d@gmail.com>
References: <20210406155053.29101-1-jbx6244@gmail.com>
 <8f05dc0d-8fb7-c200-5251-d9e147b1d00d@gmail.com>
Message-ID: <20210409180752.GB3769113@robh.at.kernel.org>

On Tue, Apr 06, 2021 at 09:04:29PM +0200, Johan Jonker wrote:
> Hi,
> 
> Question for Heiko:
> rv1108.dtsi and rk3328.dtsi have a undocumented "interrupts" property
> AFAICT without driver support.
> Please advise what to do with it.
> 
> 
> See build log:
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210406155053.29101-1-jbx6244 at gmail.com/
> 
> ====
> 
> Question for Rob:
> It looks like that recent "improvements" with regard to checking for
> undocumented compatible strings make it almost impossible to do any
> useful dt_checking, let alone for the average user. Maybe reduce the
> notification blurb output a bit for things that have nothing to do with
> this document. 

It's off by default for dt_binding_check until the 80 or so warnings are 
killed. It's on for the PW checks so new ones don't get added. It's also 
off for dtbs_check if you set DT_SCHEMA_FILES. 

> Unable to fall back to previous versions for older kernels.

Sorry, don't understand this sentence.

> 
> pip3 install git+https://github.com/devicetree-org/dt-schema.git at master
> --upgrade
> 
> make ARCH=arm dtbs_check
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 
> make ARCH=arm64 dtbs_check
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml


From robh at kernel.org  Fri Apr  9 19:09:35 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:09:35 -0500
Subject: [PATCH v1 2/2] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210406155053.29101-2-jbx6244@gmail.com>
References: <20210406155053.29101-1-jbx6244@gmail.com>
 <20210406155053.29101-2-jbx6244@gmail.com>
Message-ID: <20210409180935.GA3894908@robh.at.kernel.org>

On Tue, 06 Apr 2021 17:50:53 +0200, Johan Jonker wrote:
> The compatible strings below are already in use in the Rockchip
> dtsi files, but were somehow never added to a document, so add
> 
> "rockchip,rk3328-pwm"
> 
> "rockchip,rk3036-pwm", "rockchip,rk2928-pwm"
> 
> "rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
> "rockchip,rk3399-pwm", "rockchip,rk3288-pwm"
> 
> "rockchip,px30-pwm", "rockchip,rk3328-pwm"
> "rockchip,rk3308-pwm", "rockchip,rk3328-pwm"
> 
> for pwm nodes to pwm-rockchip.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr  9 19:09:52 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:09:52 -0500
Subject: [PATCH 1/8] dt-bindings: clock: Add MT8192 APU clock bindings
In-Reply-To: <1617766086-5502-2-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-2-git-send-email-flora.fu@mediatek.com>
Message-ID: <20210409180952.GA3895409@robh.at.kernel.org>

On Wed, 07 Apr 2021 11:27:59 +0800, Flora Fu wrote:
> Add clock bindings for APU on MT8192.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---
>  include/dt-bindings/clock/mt8192-clk.h | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From khilman at baylibre.com  Fri Apr  9 19:10:26 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Fri, 09 Apr 2021 11:10:26 -0700
Subject: [GIT PULL] arm64: dts: amlogic updates for v5.13
In-Reply-To: <161789493793.1630479.15784072871445378505.b4-ty@arndb.de>
References: <7h5z10mjpp.fsf@baylibre.com>
 <161789493793.1630479.15784072871445378505.b4-ty@arndb.de>
Message-ID: <7h1rbjib1p.fsf@baylibre.com>

[ + Christian ]

Arnd Bergmann <arnd at kernel.org> writes:

> From: Arnd Bergmann <arnd at arndb.de>
>
> On Mon, 05 Apr 2021 15:48:18 -0700, Kevin Hilman wrote:
>> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
>> 
>>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
>> 
>> are available in the Git repository at:
>> 
>>   https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
>> 
>> [...]
>
> Merged into arm/dt, thanks!
>
> Can you have a look at these added warnings from 'make dtbs_check W=1'?

Yes, we'll have a look and send a follow-up set of fixes.

Kevin

> amlogic/meson-gxl-s905d-mecool-kii-pro.dts:31.19-42.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
> amlogic/meson-gxl-s905d-mecool-kii-pro.dts:37.12-41.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
> amlogic/meson-gxm-mecool-kiii-pro.dts:36.19-47.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
> amlogic/meson-gxm-mecool-kiii-pro.dts:42.12-46.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
> amlogic/meson-gxm-minix-neo-u9h.dts:42.19-53.4: Warning (avoid_unnecessary_addr_size): /gpio-keys-polled: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
> amlogic/meson-gxm-minix-neo-u9h.dts:48.12-52.5: Warning (unit_address_vs_reg): /gpio-keys-polled/button at 0: node has a unit name, but no reg or ranges property
> amlogic/meson-gxl-s805x-p241.dt.yaml: serial at 84c0: 'uart-has-rtscts' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: audio-controller at 5400:
> 'sound-name-prefix' does not match any of the regexes: 'pinctrl-[0-9]+' amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml:
> audio-controller at c8832000: 'AVDD-supply', 'sound-name-prefix' do not match any f the regexes: 'pinctrl-[0-9]+'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names: ['lpo'] is too short
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clock-names:0: 'txco' was expected
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bluetooth: clocks: [[23]] is too short
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000: eth-phy-mux: {'type': 'object'} is not allowed for {'compatible': ['mdio-mux-mmioreg', 'mdio-mux'], '#address-cells': [[1]], '#size-cells': [[0]], 'reg': [[0, 1372, 0, 4]], 'mux-mask': [[4294967295]], 'mdio-parent-bus': [[35]], 'mdio at e40908ff': {'reg': [[3825797375]], '#address-cells': [[1]], '#size-cells': [[0]], 'ethernet-phy at 8': {'compatible': ['ethernet-phy-id0181.4400'], 'interrupts': [[0, 9, 4]], 'reg': [[8]], 'max-speed': [[100]], 'phandle': [[36]]}}, 'mdio at 2009087f': {'reg': [[537462911]], '#address-cells': [[1]], '#size-cells': [[0]]}}
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: bus at c8834000: rng: {'type': 'object'} is not allowed for {'compatible': ['amlogic,meson-rng'], 'reg': [[0, 0, 0, 4]], 'clocks': [[3, 25]], 'clock-names': ['core']}
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: hdmi-tx at c883a000: 'sound-name-prefix' does not match any of the regexes: pinctrl-[0-9]+'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: ir at 580: linux,rc-map-name:0: 'rc-mecool-kii-pro' is not one of ['rc-adstech-dvb-t-ci', 'rc-alink-dtu-m', 'rc-anysee', 'rc-apac-viewcomp',..., 'rc-zx-irdec']
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: serial at 84c0: 'bluetooth', 'uart-has-rtscts' do not match any of the regexes:
> 'pinctrl-0-9]+'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'assigned-clock-parents', 'assigned-clock-rates', 'assigned-clocks' do not atch any of the regexes: '^dai-link-[0-9]+$', 'pinctrl-[0-9]+'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: 'clocks' is a dependency of 'assigned-clocks'
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: audio-routing: ['AU2 INL', 'ACODEC LOLP', 'AU2 INR', 'ACODEC LORP', AU2 INL', 'ACODEC LOLN', 'AU2 INR', 'ACODEC LORN', 'Lineout', 'AU2 OUTL', 'Lineout', 'AU2 OUTR'] is too long
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0: [63, 0, 0] is too long
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:1: missing phandle tag in 0
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-0:sound-dai:0:2: missing phandle tag in 0
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0: [63, 0, 1] is too long
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:1: missing phandle tag in 0
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: sound: dai-link-1:sound-dai:0:2: missing phandle tag in 1
> amlogic/meson-gxl-s905d-mecool-kii-pro.dt.yaml: vpu at d0100000: 'amlogic,canvas' does not match any of the regexes: 'pinctrl-[0-9]+'
>
> merge commit: aa1e345ade42ba90ab868750acab27a360998af1
>
>        Arnd


From radhey.shyam.pandey at xilinx.com  Fri Apr  9 19:13:19 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:43:19 +0530
Subject: [RFC PATCH 0/3] net: axienet: Introduce dmaengine support
Message-ID: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>

The axiethernet driver now uses the dmaengine framework to communicate
with the xilinx DMAengine driver(AXIDMA, MCDMA). The inspiration behind
this dmaengine adoption is to reuse the in-kernel xilinx dma engine 
driver[1] and remove redundant dma programming sequence[2] from the 
ethernet driver. This simplifies the ethernet driver and also makes
it generic to be hooked to any complaint dma IP i.e AXIDMA, MCDMA 
without any modification.

This initial version is a proof of concept and validated with a ping test
on an AXI ethernet subsystem 1G + xilinx AXI DMA design. There is an
anticipated performance impact due to the adoption of the dmaengine 
framework. The plan is to revisit it once all required functional 
features are implemented.

The dmaengine framework was extended for metadata API support during the
axidma RFC[3] discussion. However, it still needs further enhancements to
make it well suited for ethernet usecases. The ethernet features i.e
ethtool set/get of DMA IP properties, ndo_poll_controller, trigger
reset of DMA IP from ethernet are not supported (mentioned in TODO)
and it requires follow-up discussion and dma framework enhancement.

Comments, suggestions, thoughts to implement remaining functional
features are very welcome!

[1]: https://github.com/torvalds/linux/blob/master/drivers/dma/xilinx/xilinx_dma.c
[2]: https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/xilinx/xilinx_axienet_main.c#L238 
[3]: http://lkml.iu.edu/hypermail/linux/kernel/1804.0/00367.html 

This series is based on dmaengine tree commit: #a38fd8748464

Radhey Shyam Pandey (3):
  dt-bindings: net: xilinx_axienet: convert bindings document to yaml
  dt-bindings: net: xilinx_axienet: Introduce dmaengine binding support
  net: axienet: Introduce dmaengine support

 .../devicetree/bindings/net/xilinx_axienet.txt     |   80 --
 .../devicetree/bindings/net/xilinx_axienet.yaml    |  155 +++
 MAINTAINERS                                        |    1 +
 drivers/net/ethernet/xilinx/xilinx_axienet.h       |  141 +--
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c  | 1050 ++++----------------
 5 files changed, 341 insertions(+), 1086 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt
 create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml

-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 19:13:20 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:43:20 +0530
Subject: [RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert bindings
 document to yaml
In-Reply-To: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617992002-38028-2-git-send-email-radhey.shyam.pandey@xilinx.com>

Convert the bindings document for Xilinx AXI Ethernet Subsystem
from txt to yaml. No changes to existing binding description.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
Pending: Fix below remaining dt_binding_check warning:

ethernet at 40c00000: 'device_type' does not match any of
the regexes: 'pinctrl-[0-9]+
---
 .../devicetree/bindings/net/xilinx_axienet.txt     |  80 -----------
 .../devicetree/bindings/net/xilinx_axienet.yaml    | 147 +++++++++++++++++++++
 MAINTAINERS                                        |   1 +
 3 files changed, 148 insertions(+), 80 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt
 create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.yaml

diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.txt b/Documentation/devicetree/bindings/net/xilinx_axienet.txt
deleted file mode 100644
index 2cd452419ed0..000000000000
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-XILINX AXI ETHERNET Device Tree Bindings
---------------------------------------------------------
-
-Also called  AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
-provides connectivity to an external ethernet PHY supporting different
-interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
-segments of memory for buffering TX and RX, as well as the capability of
-offloading TX/RX checksum calculation off the processor.
-
-Management configuration is done through the AXI interface, while payload is
-sent and received through means of an AXI DMA controller. This driver
-includes the DMA driver code, so this driver is incompatible with AXI DMA
-driver.
-
-For more details about mdio please refer phy.txt file in the same directory.
-
-Required properties:
-- compatible	: Must be one of "xlnx,axi-ethernet-1.00.a",
-		  "xlnx,axi-ethernet-1.01.a", "xlnx,axi-ethernet-2.01.a"
-- reg		: Address and length of the IO space, as well as the address
-                  and length of the AXI DMA controller IO space, unless
-                  axistream-connected is specified, in which case the reg
-                  attribute of the node referenced by it is used.
-- interrupts	: Should be a list of 2 or 3 interrupts: TX DMA, RX DMA,
-		  and optionally Ethernet core. If axistream-connected is
-		  specified, the TX/RX DMA interrupts should be on that node
-		  instead, and only the Ethernet core interrupt is optionally
-		  specified here.
-- phy-handle	: Should point to the external phy device.
-		  See ethernet.txt file in the same directory.
-- xlnx,rxmem	: Set to allocated memory buffer for Rx/Tx in the hardware
-
-Optional properties:
-- phy-mode	: See ethernet.txt
-- xlnx,phy-type	: Deprecated, do not use, but still accepted in preference
-		  to phy-mode.
-- xlnx,txcsum	: 0 or empty for disabling TX checksum offload,
-		  1 to enable partial TX checksum offload,
-		  2 to enable full TX checksum offload
-- xlnx,rxcsum	: Same values as xlnx,txcsum but for RX checksum offload
-- xlnx,switch-x-sgmii : Boolean to indicate the Ethernet core is configured to
-		  support both 1000BaseX and SGMII modes. If set, the phy-mode
-		  should be set to match the mode selected on core reset (i.e.
-		  by the basex_or_sgmii core input line).
-- clocks	: AXI bus clock for the device. Refer to common clock bindings.
-		  Used to calculate MDIO clock divisor. If not specified, it is
-		  auto-detected from the CPU clock (but only on platforms where
-		  this is possible). New device trees should specify this - the
-		  auto detection is only for backward compatibility.
-- axistream-connected: Reference to another node which contains the resources
-		       for the AXI DMA controller used by this device.
-		       If this is specified, the DMA-related resources from that
-		       device (DMA registers and DMA TX/RX interrupts) rather
-		       than this one will be used.
- - mdio		: Child node for MDIO bus. Must be defined if PHY access is
-		  required through the core's MDIO interface (i.e. always,
-		  unless the PHY is accessed through a different bus).
-
-Example:
-	axi_ethernet_eth: ethernet at 40c00000 {
-		compatible = "xlnx,axi-ethernet-1.00.a";
-		device_type = "network";
-		interrupt-parent = <&microblaze_0_axi_intc>;
-		interrupts = <2 0 1>;
-		clocks = <&axi_clk>;
-		phy-mode = "mii";
-		reg = <0x40c00000 0x40000 0x50c00000 0x40000>;
-		xlnx,rxcsum = <0x2>;
-		xlnx,rxmem = <0x800>;
-		xlnx,txcsum = <0x2>;
-		phy-handle = <&phy0>;
-		axi_ethernetlite_0_mdio: mdio {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			phy0: phy at 0 {
-				device_type = "ethernet-phy";
-				reg = <1>;
-			};
-		};
-	};
diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
new file mode 100644
index 000000000000..6a00e03e8804
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/xilinx_axienet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AXI 1G/2.5G Ethernet Subsystem
+
+description: |
+  Also called  AXI 1G/2.5G Ethernet Subsystem, the xilinx axi ethernet IP core
+  provides connectivity to an external ethernet PHY supporting different
+  interfaces: MII, GMII, RGMII, SGMII, 1000BaseX. It also includes two
+  segments of memory for buffering TX and RX, as well as the capability of
+  offloading TX/RX checksum calculation off the processor.
+
+  Management configuration is done through the AXI interface, while payload is
+  sent and received through means of an AXI DMA controller. This driver
+  includes the DMA driver code, so this driver is incompatible with AXI DMA
+  driver.
+
+
+allOf:
+  - $ref: "ethernet-controller.yaml#"
+
+maintainers:
+  - Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - xlnx,axi-ethernet-1.00.a
+              - xlnx,axi-ethernet-1.01.a
+              - xlnx,axi-ethernet-2.01.a
+
+  reg:
+    description:
+      Address and length of the IO space, as well as the address
+      and length of the AXI DMA controller IO space, unless
+      axistream-connected is specified, in which case the reg
+      attribute of the node referenced by it is used.
+    maxItems: 2
+
+  interrupts:
+    description:
+      Can point to at most 3 interrupts. TX DMA, RX DMA, and optionally Ethernet
+      core. If axistream-connected is specified, the TX/RX DMA interrupts should
+      be on that node instead, and only the Ethernet core interrupt is optionally
+      specified here.
+    maxItems: 3
+
+  phy-handle: true
+
+  xlnx,rxmem:
+    description:
+      Set to allocated memory buffer for Rx/Tx in the hardware.
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  phy-mode: true
+
+  xlnx,phy-type:
+    description:
+      Do not use, but still accepted in preference to phy-mode.
+    deprecated: true
+    $ref: /schemas/types.yaml#/definitions/uint32
+
+  xlnx,txcsum:
+    description:
+      TX checksum offload. 0 or empty for disabling TX checksum offload,
+      1 to enable partial TX checksum offload and 2 to enable full TX
+      checksum offload.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [0, 1, 2]
+
+  xlnx,rxcsum:
+    description:
+      RX checksum offload. 0 or empty for disabling RX checksum offload,
+      1 to enable partial RX checksum offload and 2 to enable full RX
+      checksum offload.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [0, 1, 2]
+
+  xlnx,switch-x-sgmii:
+    description:
+      Indicate the Ethernet core is configured to support both 1000BaseX and
+      SGMII modes. If set, the phy-mode should be set to match the mode
+      selected on core reset (i.e. by the basex_or_sgmii core input line).
+    type: boolean
+
+  clocks:
+    items:
+      - description: Clock for AXI register slave interface.
+      - description: AXI4-Stream clock for TXD RXD TXC and RXS interfaces.
+      - description: Ethernet reference clock, used by signal delay primitives
+                     and transceivers.
+      - description: MGT reference clock (used by optional internal PCS/PMA PHY)
+
+  clock-names:
+    items:
+      - const: s_axi_lite_clk
+      - const: axis_clk
+      - const: ref_clk
+      - const: mgt_clk
+
+  axistream-connected:
+    type: object
+    description: Reference to another node which contains the resources
+      for the AXI DMA controller used by this device. If this is specified,
+      the DMA-related resources from that device (DMA registers and DMA
+      TX/RX interrupts) rather than this one will be used.
+
+  mdio: true
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - xlnx,rxmem
+  - phy-handle
+
+additionalProperties: false
+
+examples:
+  - |
+    axi_ethernet_eth: ethernet at 40c00000 {
+      compatible = "xlnx,axi-ethernet-1.00.a";
+      device_type = "network";
+      interrupt-parent = <&microblaze_0_axi_intc>;
+      interrupts = <2>, <0>, <1>;
+      clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
+      clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
+      phy-mode = "mii";
+      reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>;
+      xlnx,rxcsum = <0x2>;
+      xlnx,rxmem = <0x800>;
+      xlnx,txcsum = <0x2>;
+      phy-handle = <&phy0>;
+      axi_ethernetlite_0_mdio: mdio {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        phy0: ethernet-phy at 1 {
+          device_type = "ethernet-phy";
+          reg = <1>;
+          };
+        };
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..23d6f69eddee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19679,6 +19679,7 @@ F:	include/uapi/linux/fsmap.h
 XILINX AXI ETHERNET DRIVER
 M:	Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
 S:	Maintained
+F:	Documentation/devicetree/bindings/net/xilinx_axienet.yaml
 F:	drivers/net/ethernet/xilinx/xilinx_axienet*
 
 XILINX CAN DRIVER
-- 
2.7.4



From radhey.shyam.pandey at xilinx.com  Fri Apr  9 19:13:21 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:43:21 +0530
Subject: [RFC PATCH 2/3] dt-bindings: net: xilinx_axienet: Introduce dmaengine
 binding support
In-Reply-To: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617992002-38028-3-git-send-email-radhey.shyam.pandey@xilinx.com>

The axiethernet driver will now use dmaengine framework to communicate
with dma controller IP instead of built-in dma programming sequence.

To request dma transmit and receive channels the axiethernet driver uses
generic dmas, dma-names properties. It deprecates axistream-connected
property, remove axidma reg and interrupt properties from the ethernet
node. Just to highlight that these DT changes are not backward compatible
due to major driver restructuring/cleanup done in adopting the dmaengine
framework.

Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
 .../devicetree/bindings/net/xilinx_axienet.yaml    | 40 +++++++++++++---------
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
index 6a00e03e8804..0ea3972fefef 100644
--- a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
+++ b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
@@ -14,10 +14,8 @@ description: |
   offloading TX/RX checksum calculation off the processor.
 
   Management configuration is done through the AXI interface, while payload is
-  sent and received through means of an AXI DMA controller. This driver
-  includes the DMA driver code, so this driver is incompatible with AXI DMA
-  driver.
-
+  sent and received through means of an AXI DMA controller using dmaengine
+  framework.
 
 allOf:
   - $ref: "ethernet-controller.yaml#"
@@ -36,19 +34,13 @@ properties:
 
   reg:
     description:
-      Address and length of the IO space, as well as the address
-      and length of the AXI DMA controller IO space, unless
-      axistream-connected is specified, in which case the reg
-      attribute of the node referenced by it is used.
-    maxItems: 2
+      Address and length of the IO space.
+    maxItems: 1
 
   interrupts:
     description:
-      Can point to at most 3 interrupts. TX DMA, RX DMA, and optionally Ethernet
-      core. If axistream-connected is specified, the TX/RX DMA interrupts should
-      be on that node instead, and only the Ethernet core interrupt is optionally
-      specified here.
-    maxItems: 3
+      Ethernet core interrupt.
+    maxItems: 1
 
   phy-handle: true
 
@@ -109,15 +101,29 @@ properties:
       for the AXI DMA controller used by this device. If this is specified,
       the DMA-related resources from that device (DMA registers and DMA
       TX/RX interrupts) rather than this one will be used.
+    deprecated: true
 
   mdio: true
 
+  dmas:
+    items:
+      - description: TX DMA Channel phandle and DMA request line number
+      - description: RX DMA Channel phandle and DMA request line number
+
+  dma-names:
+    items:
+      - const: tx_chan0
+      - const: rx_chan0
+
+
 required:
   - compatible
   - reg
   - interrupts
   - xlnx,rxmem
   - phy-handle
+  - dmas
+  - dma-names
 
 additionalProperties: false
 
@@ -127,11 +133,13 @@ examples:
       compatible = "xlnx,axi-ethernet-1.00.a";
       device_type = "network";
       interrupt-parent = <&microblaze_0_axi_intc>;
-      interrupts = <2>, <0>, <1>;
+      interrupts = <1>;
       clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
       clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
       phy-mode = "mii";
-      reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>;
+      reg = <0x40c00000 0x40000>;
+      dmas = <&xilinx_dma 0>, <&xilinx_dma 1>;
+      dma-names = "tx_chan0", "rx_chan0";
       xlnx,rxcsum = <0x2>;
       xlnx,rxmem = <0x800>;
       xlnx,txcsum = <0x2>;
-- 
2.7.4



From khilman at baylibre.com  Fri Apr  9 19:14:12 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Fri, 09 Apr 2021 11:14:12 -0700
Subject: [GIT PULL] arm64: dts: amlogic: updates for v5.13 (round 2)
Message-ID: <7htuofgwaz.fsf@baylibre.com>

Arnd, Olof,

A 2nd round of DT changes for Amlogic SoC families.

I'm now aware of the new DT warnings added in the first round and will
work to get those cleaned up next.

Kevin


The following changes since commit 727d93ed3ba67307a82c3ac5ebc7e335265e8b9e:

  arm64: dts: meson: add initial device-tree for MeCool KIII Pro (2021-04-05 15:35:39 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2

for you to fetch changes up to 412c8fa8c3748cc0500b4c86a47dd28254f015f1:

  arm64: dts: meson: add GPIO line names to ODROID N2/N2+ (2021-04-07 09:18:41 -0700)

----------------------------------------------------------------
arm64: dts: amlogic: updates for v5.13 (round 2)
- updates/cleanups for Hardkernel Odroid N2/N2+

----------------------------------------------------------------
Christian Hewitt (1):
      arm64: dts: meson: remove extra tab from ODROID N2/N2+ ext_mdio node

Hyeonki Hong (2):
      arm64: dts: meson: add saradc node to ODROID N2/N2+
      arm64: dts: meson: add GPIO line names to ODROID N2/N2+

 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)


From radhey.shyam.pandey at xilinx.com  Fri Apr  9 19:13:22 2021
From: radhey.shyam.pandey at xilinx.com (Radhey Shyam Pandey)
Date: Fri, 9 Apr 2021 23:43:22 +0530
Subject: [RFC PATCH 3/3] net: axienet: Introduce dmaengine support
In-Reply-To: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1617992002-38028-4-git-send-email-radhey.shyam.pandey@xilinx.com>

The axiethernet driver have in-built dma programming. The aim is to remove
axiethernet axidma programming and instead use the dmaengine framework to
communicate with existing xilinx DMAengine controller(xilinx_dma) driver.

This initial version is a proof of concept and validated with ping test.
There is an anticipated performance impact due to adoption of dmaengine
framework. The plan is to revisit it once all required functional
features are implemented.

The dmaengine framework was extended for metadata API support during the
axidma RFC[1] discussion. However it still need further enhancements to
make it well suited for ethernet usecases. The ethernet features i.e
ethtool set/get of DMA IP properties, ndo_poll_controller, trigger
reset of DMA IP from ethernet are not supported (mentioned in TODO)
and it requires follow-up discussion and dma framework enhancement.

[1]: https://lore.kernel.org/lkml/1522665546-10035-1-git-send-email-radheys at xilinx.com
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
---
 drivers/net/ethernet/xilinx/xilinx_axienet.h      |  141 +--
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1050 ++++-----------------
 2 files changed, 185 insertions(+), 1006 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 1e966a39967e..1baa75d07f94 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -70,76 +70,10 @@
 				 XAE_OPTION_RXEN)
 
 /* Axi DMA Register definitions */
-
-#define XAXIDMA_TX_CR_OFFSET	0x00000000 /* Channel control */
-#define XAXIDMA_TX_SR_OFFSET	0x00000004 /* Status */
-#define XAXIDMA_TX_CDESC_OFFSET	0x00000008 /* Current descriptor pointer */
-#define XAXIDMA_TX_TDESC_OFFSET	0x00000010 /* Tail descriptor pointer */
-
-#define XAXIDMA_RX_CR_OFFSET	0x00000030 /* Channel control */
-#define XAXIDMA_RX_SR_OFFSET	0x00000034 /* Status */
-#define XAXIDMA_RX_CDESC_OFFSET	0x00000038 /* Current descriptor pointer */
-#define XAXIDMA_RX_TDESC_OFFSET	0x00000040 /* Tail descriptor pointer */
-
-#define XAXIDMA_CR_RUNSTOP_MASK	0x00000001 /* Start/stop DMA channel */
-#define XAXIDMA_CR_RESET_MASK	0x00000004 /* Reset DMA engine */
-
-#define XAXIDMA_SR_HALT_MASK	0x00000001 /* Indicates DMA channel halted */
-
-#define XAXIDMA_BD_NDESC_OFFSET		0x00 /* Next descriptor pointer */
-#define XAXIDMA_BD_BUFA_OFFSET		0x08 /* Buffer address */
-#define XAXIDMA_BD_CTRL_LEN_OFFSET	0x18 /* Control/buffer length */
-#define XAXIDMA_BD_STS_OFFSET		0x1C /* Status */
-#define XAXIDMA_BD_USR0_OFFSET		0x20 /* User IP specific word0 */
-#define XAXIDMA_BD_USR1_OFFSET		0x24 /* User IP specific word1 */
-#define XAXIDMA_BD_USR2_OFFSET		0x28 /* User IP specific word2 */
-#define XAXIDMA_BD_USR3_OFFSET		0x2C /* User IP specific word3 */
-#define XAXIDMA_BD_USR4_OFFSET		0x30 /* User IP specific word4 */
-#define XAXIDMA_BD_ID_OFFSET		0x34 /* Sw ID */
-#define XAXIDMA_BD_HAS_STSCNTRL_OFFSET	0x38 /* Whether has stscntrl strm */
-#define XAXIDMA_BD_HAS_DRE_OFFSET	0x3C /* Whether has DRE */
-
-#define XAXIDMA_BD_HAS_DRE_SHIFT	8 /* Whether has DRE shift */
-#define XAXIDMA_BD_HAS_DRE_MASK		0xF00 /* Whether has DRE mask */
-#define XAXIDMA_BD_WORDLEN_MASK		0xFF /* Whether has DRE mask */
-
-#define XAXIDMA_BD_CTRL_LENGTH_MASK	0x007FFFFF /* Requested len */
-#define XAXIDMA_BD_CTRL_TXSOF_MASK	0x08000000 /* First tx packet */
-#define XAXIDMA_BD_CTRL_TXEOF_MASK	0x04000000 /* Last tx packet */
-#define XAXIDMA_BD_CTRL_ALL_MASK	0x0C000000 /* All control bits */
-
-#define XAXIDMA_DELAY_MASK		0xFF000000 /* Delay timeout counter */
-#define XAXIDMA_COALESCE_MASK		0x00FF0000 /* Coalesce counter */
-
-#define XAXIDMA_DELAY_SHIFT		24
-#define XAXIDMA_COALESCE_SHIFT		16
-
-#define XAXIDMA_IRQ_IOC_MASK		0x00001000 /* Completion intr */
-#define XAXIDMA_IRQ_DELAY_MASK		0x00002000 /* Delay interrupt */
-#define XAXIDMA_IRQ_ERROR_MASK		0x00004000 /* Error interrupt */
-#define XAXIDMA_IRQ_ALL_MASK		0x00007000 /* All interrupts */
-
-/* Default TX/RX Threshold and waitbound values for SGDMA mode */
-#define XAXIDMA_DFT_TX_THRESHOLD	24
-#define XAXIDMA_DFT_TX_WAITBOUND	254
-#define XAXIDMA_DFT_RX_THRESHOLD	24
-#define XAXIDMA_DFT_RX_WAITBOUND	254
-
-#define XAXIDMA_BD_CTRL_TXSOF_MASK	0x08000000 /* First tx packet */
-#define XAXIDMA_BD_CTRL_TXEOF_MASK	0x04000000 /* Last tx packet */
-#define XAXIDMA_BD_CTRL_ALL_MASK	0x0C000000 /* All control bits */
-
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK	0x007FFFFF /* Actual len */
-#define XAXIDMA_BD_STS_COMPLETE_MASK	0x80000000 /* Completed */
-#define XAXIDMA_BD_STS_DEC_ERR_MASK	0x40000000 /* Decode error */
-#define XAXIDMA_BD_STS_SLV_ERR_MASK	0x20000000 /* Slave error */
-#define XAXIDMA_BD_STS_INT_ERR_MASK	0x10000000 /* Internal err */
-#define XAXIDMA_BD_STS_ALL_ERR_MASK	0x70000000 /* All errors */
-#define XAXIDMA_BD_STS_RXSOF_MASK	0x08000000 /* First rx pkt */
-#define XAXIDMA_BD_STS_RXEOF_MASK	0x04000000 /* Last rx pkt */
-#define XAXIDMA_BD_STS_ALL_MASK		0xFC000000 /* All status bits */
-
-#define XAXIDMA_BD_MINIMUM_ALIGNMENT	0x40
+#define XAXIDMA_DFT_TX_THRESHOLD        24
+#define XAXIDMA_DFT_TX_WAITBOUND        254
+#define XAXIDMA_DFT_RX_THRESHOLD        24
+#define XAXIDMA_DFT_RX_WAITBOUND        254
 
 /* Axi Ethernet registers definition */
 #define XAE_RAF_OFFSET		0x00000000 /* Reset and Address filter */
@@ -344,39 +278,6 @@
 #define XLNX_MII_STD_SELECT_SGMII	BIT(0)
 
 /**
- * struct axidma_bd - Axi Dma buffer descriptor layout
- * @next:         MM2S/S2MM Next Descriptor Pointer
- * @next_msb:     MM2S/S2MM Next Descriptor Pointer (high 32 bits)
- * @phys:         MM2S/S2MM Buffer Address
- * @phys_msb:     MM2S/S2MM Buffer Address (high 32 bits)
- * @reserved3:    Reserved and not used
- * @reserved4:    Reserved and not used
- * @cntrl:        MM2S/S2MM Control value
- * @status:       MM2S/S2MM Status value
- * @app0:         MM2S/S2MM User Application Field 0.
- * @app1:         MM2S/S2MM User Application Field 1.
- * @app2:         MM2S/S2MM User Application Field 2.
- * @app3:         MM2S/S2MM User Application Field 3.
- * @app4:         MM2S/S2MM User Application Field 4.
- */
-struct axidma_bd {
-	u32 next;	/* Physical address of next buffer descriptor */
-	u32 next_msb;	/* high 32 bits for IP >= v7.1, reserved on older IP */
-	u32 phys;
-	u32 phys_msb;	/* for IP >= v7.1, reserved for older IP */
-	u32 reserved3;
-	u32 reserved4;
-	u32 cntrl;
-	u32 status;
-	u32 app0;
-	u32 app1;	/* TX start << 16 | insert */
-	u32 app2;	/* TX csum seed */
-	u32 app3;
-	u32 app4;   /* Last field used by HW */
-	struct sk_buff *skb;
-} __aligned(XAXIDMA_BD_MINIMUM_ALIGNMENT);
-
-/**
  * struct axienet_local - axienet private per device data
  * @ndev:	Pointer for net_device to which it will be attached.
  * @dev:	Pointer to device structure
@@ -390,27 +291,12 @@ struct axidma_bd {
  * @mii_clk_div: MII bus clock divider value
  * @regs_start: Resource start for axienet device addresses
  * @regs:	Base address for the axienet_local device address space
- * @dma_regs:	Base address for the axidma device address space
- * @dma_err_task: Work structure to process Axi DMA errors
- * @tx_irq:	Axidma TX IRQ number
- * @rx_irq:	Axidma RX IRQ number
  * @eth_irq:	Ethernet core IRQ number
  * @phy_mode:	Phy type to identify between MII/GMII/RGMII/SGMII/1000 Base-X
  * @options:	AxiEthernet option word
  * @features:	Stores the extended features supported by the axienet hw
- * @tx_bd_v:	Virtual address of the TX buffer descriptor ring
- * @tx_bd_p:	Physical address(start address) of the TX buffer descr. ring
  * @tx_bd_num:	Size of TX buffer descriptor ring
- * @rx_bd_v:	Virtual address of the RX buffer descriptor ring
- * @rx_bd_p:	Physical address(start address) of the RX buffer descr. ring
  * @rx_bd_num:	Size of RX buffer descriptor ring
- * @tx_bd_ci:	Stores the index of the Tx buffer descriptor in the ring being
- *		accessed currently. Used while alloc. BDs before a TX starts
- * @tx_bd_tail:	Stores the index of the Tx buffer descriptor in the ring being
- *		accessed currently. Used while processing BDs after the TX
- *		completed.
- * @rx_bd_ci:	Stores the index of the Rx buffer descriptor in the ring being
- *		accessed currently.
  * @max_frm_size: Stores the maximum size of the frame that can be that
  *		  Txed/Rxed in the existing hardware. If jumbo option is
  *		  supported, the maximum frame size would be 9k. Else it is
@@ -420,6 +306,9 @@ struct axidma_bd {
  * @csum_offload_on_rx_path:	Stores the checksum selection on RX side.
  * @coalesce_count_rx:	Store the irq coalesce on RX side.
  * @coalesce_count_tx:	Store the irq coalesce on TX side.
+ * @tx_chan: TX DMA channel.
+ * @rx_chan: RX DMA channel.
+ * @skb_cache: Custom skb slab allocator.
  */
 struct axienet_local {
 	struct net_device *ndev;
@@ -441,27 +330,15 @@ struct axienet_local {
 
 	resource_size_t regs_start;
 	void __iomem *regs;
-	void __iomem *dma_regs;
-
-	struct work_struct dma_err_task;
 
-	int tx_irq;
-	int rx_irq;
 	int eth_irq;
 	phy_interface_t phy_mode;
 
 	u32 options;
 	u32 features;
 
-	struct axidma_bd *tx_bd_v;
-	dma_addr_t tx_bd_p;
 	u32 tx_bd_num;
-	struct axidma_bd *rx_bd_v;
-	dma_addr_t rx_bd_p;
 	u32 rx_bd_num;
-	u32 tx_bd_ci;
-	u32 tx_bd_tail;
-	u32 rx_bd_ci;
 
 	u32 max_frm_size;
 	u32 rxmem;
@@ -471,6 +348,10 @@ struct axienet_local {
 
 	u32 coalesce_count_rx;
 	u32 coalesce_count_tx;
+
+	struct dma_chan *tx_chan;
+	struct dma_chan *rx_chan;
+	struct kmem_cache *skb_cache;
 };
 
 /**
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 3a8775e0ca55..2f166b87d038 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -15,7 +15,6 @@
  *
  * TODO:
  *  - Add Axi Fifo support.
- *  - Factor out Axi DMA code into separate driver.
  *  - Test and fix basic multicast filtering.
  *  - Add support for extended multicast filtering.
  *  - Test basic VLAN support.
@@ -37,14 +36,17 @@
 #include <linux/phy.h>
 #include <linux/mii.h>
 #include <linux/ethtool.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
 
 #include "xilinx_axienet.h"
 
 /* Descriptors defines for Tx and Rx DMA */
 #define TX_BD_NUM_DEFAULT		64
-#define RX_BD_NUM_DEFAULT		1024
+#define RX_BD_NUM_DEFAULT		128
 #define TX_BD_NUM_MAX			4096
 #define RX_BD_NUM_MAX			4096
+#define DMA_NUM_APP_WORDS		5
 
 /* Must be shorter than length of ethtool_drvinfo.driver field to fit */
 #define DRIVER_NAME		"xaxienet"
@@ -118,232 +120,131 @@ static struct axienet_option axienet_options[] = {
 	{}
 };
 
-/**
- * axienet_dma_in32 - Memory mapped Axi DMA register read
- * @lp:		Pointer to axienet local structure
- * @reg:	Address offset from the base address of the Axi DMA core
- *
- * Return: The contents of the Axi DMA register
- *
- * This function returns the contents of the corresponding Axi DMA register.
- */
-static inline u32 axienet_dma_in32(struct axienet_local *lp, off_t reg)
+struct axi_skbuff {
+	struct sk_buff *skb;
+	struct scatterlist sgl[MAX_SKB_FRAGS + 1];
+	dma_addr_t dma_address;
+	int sg_len;
+	struct dma_async_tx_descriptor *desc;
+} __packed;
+
+static void axienet_dma_rx_cb(void *data, const struct dmaengine_result *result);
+static int axienet_rx_submit_desc(struct net_device *ndev)
 {
-	return ioread32(lp->dma_regs + reg);
-}
+	struct axienet_local *lp = netdev_priv(ndev);
+	struct dma_async_tx_descriptor *dma_rx_desc = NULL;
+	struct axi_skbuff *axi_skb;
+	struct sk_buff *skb;
+	dma_addr_t addr;
+	int ret;
 
-/**
- * axienet_dma_out32 - Memory mapped Axi DMA register write.
- * @lp:		Pointer to axienet local structure
- * @reg:	Address offset from the base address of the Axi DMA core
- * @value:	Value to be written into the Axi DMA register
- *
- * This function writes the desired value into the corresponding Axi DMA
- * register.
- */
-static inline void axienet_dma_out32(struct axienet_local *lp,
-				     off_t reg, u32 value)
-{
-	iowrite32(value, lp->dma_regs + reg);
-}
+	axi_skb = kmem_cache_alloc(lp->skb_cache, GFP_KERNEL);
+	if (!axi_skb)
+		return -ENOMEM;
 
-static void axienet_dma_out_addr(struct axienet_local *lp, off_t reg,
-				 dma_addr_t addr)
-{
-	axienet_dma_out32(lp, reg, lower_32_bits(addr));
+	skb = netdev_alloc_skb(ndev, lp->max_frm_size);
+	if (!skb) {
+		ret = -ENOMEM;
+		goto rx_bd_init_skb;
+	}
 
-	if (lp->features & XAE_FEATURE_DMA_64BIT)
-		axienet_dma_out32(lp, reg + 4, upper_32_bits(addr));
-}
+	sg_init_table(axi_skb->sgl, 1);
+	addr = dma_map_single(lp->dev, skb->data, lp->max_frm_size, DMA_FROM_DEVICE);
+	sg_dma_address(axi_skb->sgl) = addr;
+	sg_dma_len(axi_skb->sgl) = lp->max_frm_size;
 
-static void desc_set_phys_addr(struct axienet_local *lp, dma_addr_t addr,
-			       struct axidma_bd *desc)
-{
-	desc->phys = lower_32_bits(addr);
-	if (lp->features & XAE_FEATURE_DMA_64BIT)
-		desc->phys_msb = upper_32_bits(addr);
-}
+	dma_rx_desc = dmaengine_prep_slave_sg(lp->rx_chan, axi_skb->sgl,
+					      1, DMA_DEV_TO_MEM,
+					      DMA_PREP_INTERRUPT);
+	if (!dma_rx_desc) {
+		ret = -EINVAL;
+		goto rx_bd_init_prep_sg;
+	}
 
-static dma_addr_t desc_get_phys_addr(struct axienet_local *lp,
-				     struct axidma_bd *desc)
-{
-	dma_addr_t ret = desc->phys;
+	axi_skb->skb = skb;
+	axi_skb->dma_address = sg_dma_address(axi_skb->sgl);
+	axi_skb->desc = dma_rx_desc;
+	dma_rx_desc->callback_param =  axi_skb;
+	dma_rx_desc->callback_result = axienet_dma_rx_cb;
+	dmaengine_submit(dma_rx_desc);
 
-	if (lp->features & XAE_FEATURE_DMA_64BIT)
-		ret |= ((dma_addr_t)desc->phys_msb << 16) << 16;
+	return 0;
 
+rx_bd_init_prep_sg:
+	dma_unmap_single(lp->dev, addr, lp->max_frm_size, DMA_FROM_DEVICE);
+	dev_kfree_skb(skb);
+rx_bd_init_skb:
+	kmem_cache_free(lp->skb_cache, axi_skb);
 	return ret;
-}
-
-/**
- * axienet_dma_bd_release - Release buffer descriptor rings
- * @ndev:	Pointer to the net_device structure
- *
- * This function is used to release the descriptors allocated in
- * axienet_dma_bd_init. axienet_dma_bd_release is called when Axi Ethernet
- * driver stop api is called.
- */
-static void axienet_dma_bd_release(struct net_device *ndev)
-{
-	int i;
-	struct axienet_local *lp = netdev_priv(ndev);
-
-	/* If we end up here, tx_bd_v must have been DMA allocated. */
-	dma_free_coherent(ndev->dev.parent,
-			  sizeof(*lp->tx_bd_v) * lp->tx_bd_num,
-			  lp->tx_bd_v,
-			  lp->tx_bd_p);
-
-	if (!lp->rx_bd_v)
-		return;
-
-	for (i = 0; i < lp->rx_bd_num; i++) {
-		dma_addr_t phys;
-
-		/* A NULL skb means this descriptor has not been initialised
-		 * at all.
-		 */
-		if (!lp->rx_bd_v[i].skb)
-			break;
 
-		dev_kfree_skb(lp->rx_bd_v[i].skb);
-
-		/* For each descriptor, we programmed cntrl with the (non-zero)
-		 * descriptor size, after it had been successfully allocated.
-		 * So a non-zero value in there means we need to unmap it.
-		 */
-		if (lp->rx_bd_v[i].cntrl) {
-			phys = desc_get_phys_addr(lp, &lp->rx_bd_v[i]);
-			dma_unmap_single(ndev->dev.parent, phys,
-					 lp->max_frm_size, DMA_FROM_DEVICE);
-		}
-	}
+};
 
-	dma_free_coherent(ndev->dev.parent,
-			  sizeof(*lp->rx_bd_v) * lp->rx_bd_num,
-			  lp->rx_bd_v,
-			  lp->rx_bd_p);
+static void axienet_dma_rx_cb(void *data, const struct dmaengine_result *result)
+{
+	struct axi_skbuff *axi_skb = data;
+	struct sk_buff *skb = axi_skb->skb;
+	struct net_device *netdev = skb->dev;
+	struct axienet_local *lp = netdev_priv(netdev);
+	u32 *app;
+	size_t meta_len, meta_max_len, rx_len;
+
+	app  = dmaengine_desc_get_metadata_ptr(axi_skb->desc, &meta_len, &meta_max_len);
+	dma_unmap_single(lp->dev, axi_skb->dma_address, lp->max_frm_size,
+			 DMA_FROM_DEVICE);
+	/* TODO: Derive app word index programmatically */
+	rx_len = (app[4] & 0xFFFF);
+	skb_put(skb, rx_len);
+	skb->protocol = eth_type_trans(skb, netdev);
+	skb->ip_summed = CHECKSUM_NONE;
+
+	netif_rx(skb);
+	kmem_cache_free(lp->skb_cache, axi_skb);
+	netdev->stats.rx_packets++;
+	netdev->stats.rx_bytes += rx_len;
+	axienet_rx_submit_desc(netdev);
+	dma_async_issue_pending(lp->rx_chan);
 }
 
-/**
- * axienet_dma_bd_init - Setup buffer descriptor rings for Axi DMA
- * @ndev:	Pointer to the net_device structure
- *
- * Return: 0, on success -ENOMEM, on failure
- *
- * This function is called to initialize the Rx and Tx DMA descriptor
- * rings. This initializes the descriptors with required default values
- * and is called when Axi Ethernet driver reset is called.
- */
-static int axienet_dma_bd_init(struct net_device *ndev)
+static int axienet_setup_dma_chan(struct net_device *ndev)
 {
-	u32 cr;
-	int i;
-	struct sk_buff *skb;
 	struct axienet_local *lp = netdev_priv(ndev);
+	int i, ret;
 
-	/* Reset the indexes which are used for accessing the BDs */
-	lp->tx_bd_ci = 0;
-	lp->tx_bd_tail = 0;
-	lp->rx_bd_ci = 0;
-
-	/* Allocate the Tx and Rx buffer descriptors. */
-	lp->tx_bd_v = dma_alloc_coherent(ndev->dev.parent,
-					 sizeof(*lp->tx_bd_v) * lp->tx_bd_num,
-					 &lp->tx_bd_p, GFP_KERNEL);
-	if (!lp->tx_bd_v)
-		return -ENOMEM;
-
-	lp->rx_bd_v = dma_alloc_coherent(ndev->dev.parent,
-					 sizeof(*lp->rx_bd_v) * lp->rx_bd_num,
-					 &lp->rx_bd_p, GFP_KERNEL);
-	if (!lp->rx_bd_v)
-		goto out;
-
-	for (i = 0; i < lp->tx_bd_num; i++) {
-		dma_addr_t addr = lp->tx_bd_p +
-				  sizeof(*lp->tx_bd_v) *
-				  ((i + 1) % lp->tx_bd_num);
-
-		lp->tx_bd_v[i].next = lower_32_bits(addr);
-		if (lp->features & XAE_FEATURE_DMA_64BIT)
-			lp->tx_bd_v[i].next_msb = upper_32_bits(addr);
+	lp->tx_chan = dma_request_chan(lp->dev, "tx_chan0");
+	if (IS_ERR(lp->tx_chan)) {
+		ret = PTR_ERR(lp->tx_chan);
+		if (ret != -EPROBE_DEFER)
+			netdev_err(ndev, "No Ethernet DMA (TX) channel found\n");
+		return ret;
 	}
 
-	for (i = 0; i < lp->rx_bd_num; i++) {
-		dma_addr_t addr;
-
-		addr = lp->rx_bd_p + sizeof(*lp->rx_bd_v) *
-			((i + 1) % lp->rx_bd_num);
-		lp->rx_bd_v[i].next = lower_32_bits(addr);
-		if (lp->features & XAE_FEATURE_DMA_64BIT)
-			lp->rx_bd_v[i].next_msb = upper_32_bits(addr);
-
-		skb = netdev_alloc_skb_ip_align(ndev, lp->max_frm_size);
-		if (!skb)
-			goto out;
-
-		lp->rx_bd_v[i].skb = skb;
-		addr = dma_map_single(ndev->dev.parent, skb->data,
-				      lp->max_frm_size, DMA_FROM_DEVICE);
-		if (dma_mapping_error(ndev->dev.parent, addr)) {
-			netdev_err(ndev, "DMA mapping error\n");
-			goto out;
-		}
-		desc_set_phys_addr(lp, addr, &lp->rx_bd_v[i]);
+	lp->rx_chan = dma_request_chan(lp->dev, "rx_chan0");
+	if (IS_ERR(lp->rx_chan)) {
+		ret = PTR_ERR(lp->rx_chan);
+		if (ret != -EPROBE_DEFER)
+			netdev_err(ndev, "No Ethernet DMA (RX) channel found\n");
+		goto err_dma_request_rx;
+	}
 
-		lp->rx_bd_v[i].cntrl = lp->max_frm_size;
+	lp->skb_cache = kmem_cache_create("ethernet", sizeof(struct axi_skbuff),
+					  0, 0, NULL);
+	if (!lp->skb_cache) {
+		ret =  -ENOMEM;
+		goto err_kmem;
 	}
 
-	/* Start updating the Rx channel control register */
-	cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	/* Update the interrupt coalesce count */
-	cr = ((cr & ~XAXIDMA_COALESCE_MASK) |
-	      ((lp->coalesce_count_rx) << XAXIDMA_COALESCE_SHIFT));
-	/* Update the delay timer count */
-	cr = ((cr & ~XAXIDMA_DELAY_MASK) |
-	      (XAXIDMA_DFT_RX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
-	/* Enable coalesce, delay timer and error interrupts */
-	cr |= XAXIDMA_IRQ_ALL_MASK;
-	/* Write to the Rx channel control register */
-	axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET, cr);
-
-	/* Start updating the Tx channel control register */
-	cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	/* Update the interrupt coalesce count */
-	cr = (((cr & ~XAXIDMA_COALESCE_MASK)) |
-	      ((lp->coalesce_count_tx) << XAXIDMA_COALESCE_SHIFT));
-	/* Update the delay timer count */
-	cr = (((cr & ~XAXIDMA_DELAY_MASK)) |
-	      (XAXIDMA_DFT_TX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
-	/* Enable coalesce, delay timer and error interrupts */
-	cr |= XAXIDMA_IRQ_ALL_MASK;
-	/* Write to the Tx channel control register */
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, cr);
-
-	/* Populate the tail pointer and bring the Rx Axi DMA engine out of
-	 * halted state. This will make the Rx side ready for reception.
-	 */
-	axienet_dma_out_addr(lp, XAXIDMA_RX_CDESC_OFFSET, lp->rx_bd_p);
-	cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET,
-			  cr | XAXIDMA_CR_RUNSTOP_MASK);
-	axienet_dma_out_addr(lp, XAXIDMA_RX_TDESC_OFFSET, lp->rx_bd_p +
-			     (sizeof(*lp->rx_bd_v) * (lp->rx_bd_num - 1)));
-
-	/* Write to the RS (Run-stop) bit in the Tx channel control register.
-	 * Tx channel is now ready to run. But only after we write to the
-	 * tail pointer register that the Tx channel will start transmitting.
-	 */
-	axienet_dma_out_addr(lp, XAXIDMA_TX_CDESC_OFFSET, lp->tx_bd_p);
-	cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET,
-			  cr | XAXIDMA_CR_RUNSTOP_MASK);
+	/* TODO: Instead of BD_NUM_DEFAULT use runtime support*/
+	for (i = 0; i < RX_BD_NUM_DEFAULT; i++)
+		axienet_rx_submit_desc(ndev);
+	dma_async_issue_pending(lp->rx_chan);
 
 	return 0;
-out:
-	axienet_dma_bd_release(ndev);
-	return -ENOMEM;
+
+err_kmem:
+	dma_release_channel(lp->rx_chan);
+err_dma_request_rx:
+	dma_release_channel(lp->tx_chan);
+	return ret;
 }
 
 /**
@@ -494,32 +395,6 @@ static void axienet_setoptions(struct net_device *ndev, u32 options)
 	lp->options |= options;
 }
 
-static int __axienet_device_reset(struct axienet_local *lp)
-{
-	u32 timeout;
-
-	/* Reset Axi DMA. This would reset Axi Ethernet core as well. The reset
-	 * process of Axi DMA takes a while to complete as all pending
-	 * commands/transfers will be flushed or completed during this
-	 * reset process.
-	 * Note that even though both TX and RX have their own reset register,
-	 * they both reset the entire DMA core, so only one needs to be used.
-	 */
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, XAXIDMA_CR_RESET_MASK);
-	timeout = DELAY_OF_ONE_MILLISEC;
-	while (axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET) &
-				XAXIDMA_CR_RESET_MASK) {
-		udelay(1);
-		if (--timeout == 0) {
-			netdev_err(lp->ndev, "%s: DMA reset timeout!\n",
-				   __func__);
-			return -ETIMEDOUT;
-		}
-	}
-
-	return 0;
-}
-
 /**
  * axienet_device_reset - Reset and initialize the Axi Ethernet hardware.
  * @ndev:	Pointer to the net_device structure
@@ -536,11 +411,8 @@ static int axienet_device_reset(struct net_device *ndev)
 {
 	u32 axienet_status;
 	struct axienet_local *lp = netdev_priv(ndev);
-	int ret;
 
-	ret = __axienet_device_reset(lp);
-	if (ret)
-		return ret;
+	/* TODO: Request DMA RESET */
 
 	lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
 	lp->options |= XAE_OPTION_VLAN;
@@ -555,13 +427,7 @@ static int axienet_device_reset(struct net_device *ndev)
 			lp->options |= XAE_OPTION_JUMBO;
 	}
 
-	ret = axienet_dma_bd_init(ndev);
-	if (ret) {
-		netdev_err(ndev, "%s: descriptor allocation failed\n",
-			   __func__);
-		return ret;
-	}
-
+	/* TODO: BD initialization */
 	axienet_status = axienet_ior(lp, XAE_RCW1_OFFSET);
 	axienet_status &= ~XAE_RCW1_RX_MASK;
 	axienet_iow(lp, XAE_RCW1_OFFSET, axienet_status);
@@ -589,116 +455,28 @@ static int axienet_device_reset(struct net_device *ndev)
 }
 
 /**
- * axienet_free_tx_chain - Clean up a series of linked TX descriptors.
- * @ndev:	Pointer to the net_device structure
- * @first_bd:	Index of first descriptor to clean up
- * @nr_bds:	Number of descriptors to clean up, can be -1 if unknown.
- * @sizep:	Pointer to a u32 filled with the total sum of all bytes
- * 		in all cleaned-up descriptors. Ignored if NULL.
- *
- * Would either be called after a successful transmit operation, or after
- * there was an error when setting up the chain.
- * Returns the number of descriptors handled.
+ * axienet_dma_tx_cb - DMA engine callback for TX channel.
+ * @data:       Pointer to the net_device structure
+ * @result:     error reporting through dmaengine_result.
+ * This function is called by dmaengine driver for TX channel to notify
+ * that the transmit is done.
  */
-static int axienet_free_tx_chain(struct net_device *ndev, u32 first_bd,
-				 int nr_bds, u32 *sizep)
-{
-	struct axienet_local *lp = netdev_priv(ndev);
-	struct axidma_bd *cur_p;
-	int max_bds = nr_bds;
-	unsigned int status;
-	dma_addr_t phys;
-	int i;
-
-	if (max_bds == -1)
-		max_bds = lp->tx_bd_num;
-
-	for (i = 0; i < max_bds; i++) {
-		cur_p = &lp->tx_bd_v[(first_bd + i) % lp->tx_bd_num];
-		status = cur_p->status;
-
-		/* If no number is given, clean up *all* descriptors that have
-		 * been completed by the MAC.
-		 */
-		if (nr_bds == -1 && !(status & XAXIDMA_BD_STS_COMPLETE_MASK))
-			break;
-
-		phys = desc_get_phys_addr(lp, cur_p);
-		dma_unmap_single(ndev->dev.parent, phys,
-				 (cur_p->cntrl & XAXIDMA_BD_CTRL_LENGTH_MASK),
-				 DMA_TO_DEVICE);
-
-		if (cur_p->skb && (status & XAXIDMA_BD_STS_COMPLETE_MASK))
-			dev_consume_skb_irq(cur_p->skb);
-
-		cur_p->cntrl = 0;
-		cur_p->app0 = 0;
-		cur_p->app1 = 0;
-		cur_p->app2 = 0;
-		cur_p->app4 = 0;
-		cur_p->status = 0;
-		cur_p->skb = NULL;
-
-		if (sizep)
-			*sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
-	}
-
-	return i;
-}
 
-/**
- * axienet_start_xmit_done - Invoked once a transmit is completed by the
- * Axi DMA Tx channel.
- * @ndev:	Pointer to the net_device structure
- *
- * This function is invoked from the Axi DMA Tx isr to notify the completion
- * of transmit operation. It clears fields in the corresponding Tx BDs and
- * unmaps the corresponding buffer so that CPU can regain ownership of the
- * buffer. It finally invokes "netif_wake_queue" to restart transmission if
- * required.
- */
-static void axienet_start_xmit_done(struct net_device *ndev)
+static void axienet_dma_tx_cb(void *data, const struct dmaengine_result *result)
 {
-	struct axienet_local *lp = netdev_priv(ndev);
-	u32 packets = 0;
-	u32 size = 0;
-
-	packets = axienet_free_tx_chain(ndev, lp->tx_bd_ci, -1, &size);
+	struct axi_skbuff *axi_skb = data;
+	struct sk_buff *skb = axi_skb->skb;
 
-	lp->tx_bd_ci += packets;
-	if (lp->tx_bd_ci >= lp->tx_bd_num)
-		lp->tx_bd_ci -= lp->tx_bd_num;
+	struct net_device *netdev = skb->dev;
+	struct axienet_local *lp = netdev_priv(netdev);
 
-	ndev->stats.tx_packets += packets;
-	ndev->stats.tx_bytes += size;
+	dma_unmap_sg(lp->dev, axi_skb->sgl, axi_skb->sg_len, DMA_MEM_TO_DEV);
+	dev_kfree_skb_any(skb);
+	kmem_cache_free(lp->skb_cache, axi_skb);
+	netdev->stats.tx_packets++;
 
-	/* Matches barrier in axienet_start_xmit */
-	smp_mb();
-
-	netif_wake_queue(ndev);
-}
-
-/**
- * axienet_check_tx_bd_space - Checks if a BD/group of BDs are currently busy
- * @lp:		Pointer to the axienet_local structure
- * @num_frag:	The number of BDs to check for
- *
- * Return: 0, on success
- *	    NETDEV_TX_BUSY, if any of the descriptors are not free
- *
- * This function is invoked before BDs are allocated and transmission starts.
- * This function returns 0 if a BD or group of BDs can be allocated for
- * transmission. If the BD or any of the BDs are not free the function
- * returns a busy status. This is invoked from axienet_start_xmit.
- */
-static inline int axienet_check_tx_bd_space(struct axienet_local *lp,
-					    int num_frag)
-{
-	struct axidma_bd *cur_p;
-	cur_p = &lp->tx_bd_v[(lp->tx_bd_tail + num_frag) % lp->tx_bd_num];
-	if (cur_p->status & XAXIDMA_BD_STS_ALL_MASK)
-		return NETDEV_TX_BUSY;
-	return 0;
+	if (netif_queue_stopped(netdev))
+		netif_wake_queue(netdev);
 }
 
 /**
@@ -717,285 +495,65 @@ static inline int axienet_check_tx_bd_space(struct axienet_local *lp,
 static netdev_tx_t
 axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 {
-	u32 ii;
-	u32 num_frag;
 	u32 csum_start_off;
 	u32 csum_index_off;
-	skb_frag_t *frag;
-	dma_addr_t tail_p, phys;
+	int sg_len;
 	struct axienet_local *lp = netdev_priv(ndev);
-	struct axidma_bd *cur_p;
-	u32 orig_tail_ptr = lp->tx_bd_tail;
-
-	num_frag = skb_shinfo(skb)->nr_frags;
-	cur_p = &lp->tx_bd_v[lp->tx_bd_tail];
-
-	if (axienet_check_tx_bd_space(lp, num_frag)) {
-		if (netif_queue_stopped(ndev))
-			return NETDEV_TX_BUSY;
-
-		netif_stop_queue(ndev);
+	struct dma_async_tx_descriptor *dma_tx_desc = NULL;
+	struct axi_skbuff *axi_skb;
+	u32 app[DMA_NUM_APP_WORDS] = {0};
+	int ret;
 
-		/* Matches barrier in axienet_start_xmit_done */
-		smp_mb();
+	sg_len = skb_shinfo(skb)->nr_frags + 1;
+	axi_skb = kmem_cache_zalloc(lp->skb_cache, GFP_KERNEL);
+	if (!axi_skb)
+		return NETDEV_TX_BUSY;
 
-		/* Space might have just been freed - check again */
-		if (axienet_check_tx_bd_space(lp, num_frag))
-			return NETDEV_TX_BUSY;
+	sg_init_table(axi_skb->sgl, sg_len);
+	ret = skb_to_sgvec(skb, axi_skb->sgl, 0, skb->len);
+	if (unlikely(ret < 0))
+		goto xmit_error_skb_sgvec;
 
-		netif_wake_queue(ndev);
-	}
+	dma_map_sg(lp->dev, axi_skb->sgl, sg_len, DMA_TO_DEVICE);
 
+	/*Fill up app fields for checksum */
 	if (skb->ip_summed == CHECKSUM_PARTIAL) {
 		if (lp->features & XAE_FEATURE_FULL_TX_CSUM) {
 			/* Tx Full Checksum Offload Enabled */
-			cur_p->app0 |= 2;
+			app[0] |= 2;
 		} else if (lp->features & XAE_FEATURE_PARTIAL_RX_CSUM) {
 			csum_start_off = skb_transport_offset(skb);
 			csum_index_off = csum_start_off + skb->csum_offset;
 			/* Tx Partial Checksum Offload Enabled */
-			cur_p->app0 |= 1;
-			cur_p->app1 = (csum_start_off << 16) | csum_index_off;
+			app[0] |= 1;
+			app[1] = (csum_start_off << 16) | csum_index_off;
 		}
 	} else if (skb->ip_summed == CHECKSUM_UNNECESSARY) {
-		cur_p->app0 |= 2; /* Tx Full Checksum Offload Enabled */
+		app[0] |= 2; /* Tx Full Checksum Offload Enabled */
 	}
 
-	phys = dma_map_single(ndev->dev.parent, skb->data,
-			      skb_headlen(skb), DMA_TO_DEVICE);
-	if (unlikely(dma_mapping_error(ndev->dev.parent, phys))) {
-		if (net_ratelimit())
-			netdev_err(ndev, "TX DMA mapping error\n");
-		ndev->stats.tx_dropped++;
-		return NETDEV_TX_OK;
-	}
-	desc_set_phys_addr(lp, phys, cur_p);
-	cur_p->cntrl = skb_headlen(skb) | XAXIDMA_BD_CTRL_TXSOF_MASK;
-
-	for (ii = 0; ii < num_frag; ii++) {
-		if (++lp->tx_bd_tail >= lp->tx_bd_num)
-			lp->tx_bd_tail = 0;
-		cur_p = &lp->tx_bd_v[lp->tx_bd_tail];
-		frag = &skb_shinfo(skb)->frags[ii];
-		phys = dma_map_single(ndev->dev.parent,
-				      skb_frag_address(frag),
-				      skb_frag_size(frag),
-				      DMA_TO_DEVICE);
-		if (unlikely(dma_mapping_error(ndev->dev.parent, phys))) {
-			if (net_ratelimit())
-				netdev_err(ndev, "TX DMA mapping error\n");
-			ndev->stats.tx_dropped++;
-			axienet_free_tx_chain(ndev, orig_tail_ptr, ii + 1,
-					      NULL);
-			lp->tx_bd_tail = orig_tail_ptr;
-
-			return NETDEV_TX_OK;
-		}
-		desc_set_phys_addr(lp, phys, cur_p);
-		cur_p->cntrl = skb_frag_size(frag);
-	}
+	dma_tx_desc = lp->tx_chan->device->device_prep_slave_sg(lp->tx_chan, axi_skb->sgl,
+								sg_len, DMA_MEM_TO_DEV,
+								DMA_PREP_INTERRUPT, (void *)app);
 
-	cur_p->cntrl |= XAXIDMA_BD_CTRL_TXEOF_MASK;
-	cur_p->skb = skb;
+	if (!dma_tx_desc)
+		goto xmit_error_prep;
 
-	tail_p = lp->tx_bd_p + sizeof(*lp->tx_bd_v) * lp->tx_bd_tail;
-	/* Start the transfer */
-	axienet_dma_out_addr(lp, XAXIDMA_TX_TDESC_OFFSET, tail_p);
-	if (++lp->tx_bd_tail >= lp->tx_bd_num)
-		lp->tx_bd_tail = 0;
+	axi_skb->skb = skb;
+	axi_skb->sg_len = sg_len;
+	dma_tx_desc->callback_param =  axi_skb;
+	dma_tx_desc->callback_result = axienet_dma_tx_cb;
+	dmaengine_submit(dma_tx_desc);
+	dma_async_issue_pending(lp->tx_chan);
+	ndev->stats.tx_bytes += skb->len;
 
 	return NETDEV_TX_OK;
-}
 
-/**
- * axienet_recv - Is called from Axi DMA Rx Isr to complete the received
- *		  BD processing.
- * @ndev:	Pointer to net_device structure.
- *
- * This function is invoked from the Axi DMA Rx isr to process the Rx BDs. It
- * does minimal processing and invokes "netif_rx" to complete further
- * processing.
- */
-static void axienet_recv(struct net_device *ndev)
-{
-	u32 length;
-	u32 csumstatus;
-	u32 size = 0;
-	u32 packets = 0;
-	dma_addr_t tail_p = 0;
-	struct axienet_local *lp = netdev_priv(ndev);
-	struct sk_buff *skb, *new_skb;
-	struct axidma_bd *cur_p;
-
-	cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
-
-	while ((cur_p->status & XAXIDMA_BD_STS_COMPLETE_MASK)) {
-		dma_addr_t phys;
-
-		tail_p = lp->rx_bd_p + sizeof(*lp->rx_bd_v) * lp->rx_bd_ci;
-
-		phys = desc_get_phys_addr(lp, cur_p);
-		dma_unmap_single(ndev->dev.parent, phys, lp->max_frm_size,
-				 DMA_FROM_DEVICE);
-
-		skb = cur_p->skb;
-		cur_p->skb = NULL;
-		length = cur_p->app4 & 0x0000FFFF;
-
-		skb_put(skb, length);
-		skb->protocol = eth_type_trans(skb, ndev);
-		/*skb_checksum_none_assert(skb);*/
-		skb->ip_summed = CHECKSUM_NONE;
-
-		/* if we're doing Rx csum offload, set it up */
-		if (lp->features & XAE_FEATURE_FULL_RX_CSUM) {
-			csumstatus = (cur_p->app2 &
-				      XAE_FULL_CSUM_STATUS_MASK) >> 3;
-			if ((csumstatus == XAE_IP_TCP_CSUM_VALIDATED) ||
-			    (csumstatus == XAE_IP_UDP_CSUM_VALIDATED)) {
-				skb->ip_summed = CHECKSUM_UNNECESSARY;
-			}
-		} else if ((lp->features & XAE_FEATURE_PARTIAL_RX_CSUM) != 0 &&
-			   skb->protocol == htons(ETH_P_IP) &&
-			   skb->len > 64) {
-			skb->csum = be32_to_cpu(cur_p->app3 & 0xFFFF);
-			skb->ip_summed = CHECKSUM_COMPLETE;
-		}
-
-		netif_rx(skb);
-
-		size += length;
-		packets++;
-
-		new_skb = netdev_alloc_skb_ip_align(ndev, lp->max_frm_size);
-		if (!new_skb)
-			return;
-
-		phys = dma_map_single(ndev->dev.parent, new_skb->data,
-				      lp->max_frm_size,
-				      DMA_FROM_DEVICE);
-		if (unlikely(dma_mapping_error(ndev->dev.parent, phys))) {
-			if (net_ratelimit())
-				netdev_err(ndev, "RX DMA mapping error\n");
-			dev_kfree_skb(new_skb);
-			return;
-		}
-		desc_set_phys_addr(lp, phys, cur_p);
-
-		cur_p->cntrl = lp->max_frm_size;
-		cur_p->status = 0;
-		cur_p->skb = new_skb;
-
-		if (++lp->rx_bd_ci >= lp->rx_bd_num)
-			lp->rx_bd_ci = 0;
-		cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
-	}
-
-	ndev->stats.rx_packets += packets;
-	ndev->stats.rx_bytes += size;
-
-	if (tail_p)
-		axienet_dma_out_addr(lp, XAXIDMA_RX_TDESC_OFFSET, tail_p);
-}
-
-/**
- * axienet_tx_irq - Tx Done Isr.
- * @irq:	irq number
- * @_ndev:	net_device pointer
- *
- * Return: IRQ_HANDLED if device generated a TX interrupt, IRQ_NONE otherwise.
- *
- * This is the Axi DMA Tx done Isr. It invokes "axienet_start_xmit_done"
- * to complete the BD processing.
- */
-static irqreturn_t axienet_tx_irq(int irq, void *_ndev)
-{
-	u32 cr;
-	unsigned int status;
-	struct net_device *ndev = _ndev;
-	struct axienet_local *lp = netdev_priv(ndev);
-
-	status = axienet_dma_in32(lp, XAXIDMA_TX_SR_OFFSET);
-	if (status & (XAXIDMA_IRQ_IOC_MASK | XAXIDMA_IRQ_DELAY_MASK)) {
-		axienet_dma_out32(lp, XAXIDMA_TX_SR_OFFSET, status);
-		axienet_start_xmit_done(lp->ndev);
-		goto out;
-	}
-	if (!(status & XAXIDMA_IRQ_ALL_MASK))
-		return IRQ_NONE;
-	if (status & XAXIDMA_IRQ_ERROR_MASK) {
-		dev_err(&ndev->dev, "DMA Tx error 0x%x\n", status);
-		dev_err(&ndev->dev, "Current BD is at: 0x%x%08x\n",
-			(lp->tx_bd_v[lp->tx_bd_ci]).phys_msb,
-			(lp->tx_bd_v[lp->tx_bd_ci]).phys);
-
-		cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-		/* Disable coalesce, delay timer and error interrupts */
-		cr &= (~XAXIDMA_IRQ_ALL_MASK);
-		/* Write to the Tx channel control register */
-		axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, cr);
-
-		cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-		/* Disable coalesce, delay timer and error interrupts */
-		cr &= (~XAXIDMA_IRQ_ALL_MASK);
-		/* Write to the Rx channel control register */
-		axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET, cr);
-
-		schedule_work(&lp->dma_err_task);
-		axienet_dma_out32(lp, XAXIDMA_TX_SR_OFFSET, status);
-	}
-out:
-	return IRQ_HANDLED;
-}
-
-/**
- * axienet_rx_irq - Rx Isr.
- * @irq:	irq number
- * @_ndev:	net_device pointer
- *
- * Return: IRQ_HANDLED if device generated a RX interrupt, IRQ_NONE otherwise.
- *
- * This is the Axi DMA Rx Isr. It invokes "axienet_recv" to complete the BD
- * processing.
- */
-static irqreturn_t axienet_rx_irq(int irq, void *_ndev)
-{
-	u32 cr;
-	unsigned int status;
-	struct net_device *ndev = _ndev;
-	struct axienet_local *lp = netdev_priv(ndev);
-
-	status = axienet_dma_in32(lp, XAXIDMA_RX_SR_OFFSET);
-	if (status & (XAXIDMA_IRQ_IOC_MASK | XAXIDMA_IRQ_DELAY_MASK)) {
-		axienet_dma_out32(lp, XAXIDMA_RX_SR_OFFSET, status);
-		axienet_recv(lp->ndev);
-		goto out;
-	}
-	if (!(status & XAXIDMA_IRQ_ALL_MASK))
-		return IRQ_NONE;
-	if (status & XAXIDMA_IRQ_ERROR_MASK) {
-		dev_err(&ndev->dev, "DMA Rx error 0x%x\n", status);
-		dev_err(&ndev->dev, "Current BD is at: 0x%x%08x\n",
-			(lp->rx_bd_v[lp->rx_bd_ci]).phys_msb,
-			(lp->rx_bd_v[lp->rx_bd_ci]).phys);
-
-		cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-		/* Disable coalesce, delay timer and error interrupts */
-		cr &= (~XAXIDMA_IRQ_ALL_MASK);
-		/* Finally write to the Tx channel control register */
-		axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, cr);
-
-		cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-		/* Disable coalesce, delay timer and error interrupts */
-		cr &= (~XAXIDMA_IRQ_ALL_MASK);
-		/* write to the Rx channel control register */
-		axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET, cr);
-
-		schedule_work(&lp->dma_err_task);
-		axienet_dma_out32(lp, XAXIDMA_RX_SR_OFFSET, status);
-	}
-out:
-	return IRQ_HANDLED;
+xmit_error_prep:
+	dma_unmap_sg(lp->dev, axi_skb->sgl, sg_len, DMA_TO_DEVICE);
+xmit_error_skb_sgvec:
+	kmem_cache_free(lp->skb_cache, axi_skb);
+	return NETDEV_TX_BUSY;
 }
 
 /**
@@ -1027,8 +585,6 @@ static irqreturn_t axienet_eth_irq(int irq, void *_ndev)
 	return IRQ_HANDLED;
 }
 
-static void axienet_dma_err_handler(struct work_struct *work);
-
 /**
  * axienet_open - Driver open routine.
  * @ndev:	Pointer to net_device structure
@@ -1065,19 +621,6 @@ static int axienet_open(struct net_device *ndev)
 
 	phylink_start(lp->phylink);
 
-	/* Enable worker thread for Axi DMA error handling */
-	INIT_WORK(&lp->dma_err_task, axienet_dma_err_handler);
-
-	/* Enable interrupts for Axi DMA Tx */
-	ret = request_irq(lp->tx_irq, axienet_tx_irq, IRQF_SHARED,
-			  ndev->name, ndev);
-	if (ret)
-		goto err_tx_irq;
-	/* Enable interrupts for Axi DMA Rx */
-	ret = request_irq(lp->rx_irq, axienet_rx_irq, IRQF_SHARED,
-			  ndev->name, ndev);
-	if (ret)
-		goto err_rx_irq;
 	/* Enable interrupts for Axi Ethernet core (if defined) */
 	if (lp->eth_irq > 0) {
 		ret = request_irq(lp->eth_irq, axienet_eth_irq, IRQF_SHARED,
@@ -1086,16 +629,18 @@ static int axienet_open(struct net_device *ndev)
 			goto err_eth_irq;
 	}
 
+	 /* Setup dma channel */
+	ret = axienet_setup_dma_chan(ndev);
+	if (ret < 0)
+		goto err_dma_setup;
+
 	return 0;
 
+err_dma_setup:
+	free_irq(lp->eth_irq, ndev);
 err_eth_irq:
-	free_irq(lp->rx_irq, ndev);
-err_rx_irq:
-	free_irq(lp->tx_irq, ndev);
-err_tx_irq:
 	phylink_stop(lp->phylink);
 	phylink_disconnect_phy(lp->phylink);
-	cancel_work_sync(&lp->dma_err_task);
 	dev_err(lp->dev, "request_irq() failed\n");
 	return ret;
 }
@@ -1112,8 +657,6 @@ static int axienet_open(struct net_device *ndev)
  */
 static int axienet_stop(struct net_device *ndev)
 {
-	u32 cr, sr;
-	int count;
 	struct axienet_local *lp = netdev_priv(ndev);
 
 	dev_dbg(&ndev->dev, "axienet_close()\n");
@@ -1124,42 +667,14 @@ static int axienet_stop(struct net_device *ndev)
 	axienet_setoptions(ndev, lp->options &
 			   ~(XAE_OPTION_TXEN | XAE_OPTION_RXEN));
 
-	cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	cr &= ~(XAXIDMA_CR_RUNSTOP_MASK | XAXIDMA_IRQ_ALL_MASK);
-	axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET, cr);
-
-	cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	cr &= ~(XAXIDMA_CR_RUNSTOP_MASK | XAXIDMA_IRQ_ALL_MASK);
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, cr);
-
 	axienet_iow(lp, XAE_IE_OFFSET, 0);
 
-	/* Give DMAs a chance to halt gracefully */
-	sr = axienet_dma_in32(lp, XAXIDMA_RX_SR_OFFSET);
-	for (count = 0; !(sr & XAXIDMA_SR_HALT_MASK) && count < 5; ++count) {
-		msleep(20);
-		sr = axienet_dma_in32(lp, XAXIDMA_RX_SR_OFFSET);
-	}
-
-	sr = axienet_dma_in32(lp, XAXIDMA_TX_SR_OFFSET);
-	for (count = 0; !(sr & XAXIDMA_SR_HALT_MASK) && count < 5; ++count) {
-		msleep(20);
-		sr = axienet_dma_in32(lp, XAXIDMA_TX_SR_OFFSET);
-	}
-
-	/* Do a reset to ensure DMA is really stopped */
-	mutex_lock(&lp->mii_bus->mdio_lock);
-	__axienet_device_reset(lp);
-	mutex_unlock(&lp->mii_bus->mdio_lock);
-
-	cancel_work_sync(&lp->dma_err_task);
+	dma_release_channel(lp->rx_chan);
+	dma_release_channel(lp->tx_chan);
 
 	if (lp->eth_irq > 0)
 		free_irq(lp->eth_irq, ndev);
-	free_irq(lp->tx_irq, ndev);
-	free_irq(lp->rx_irq, ndev);
 
-	axienet_dma_bd_release(ndev);
 	return 0;
 }
 
@@ -1201,12 +716,7 @@ static int axienet_change_mtu(struct net_device *ndev, int new_mtu)
 static void axienet_poll_controller(struct net_device *ndev)
 {
 	struct axienet_local *lp = netdev_priv(ndev);
-	disable_irq(lp->tx_irq);
-	disable_irq(lp->rx_irq);
-	axienet_rx_irq(lp->tx_irq, ndev);
-	axienet_tx_irq(lp->rx_irq, ndev);
-	enable_irq(lp->tx_irq);
-	enable_irq(lp->rx_irq);
+	/* TODO: Placeholder to implement poll mechanism */
 }
 #endif
 
@@ -1313,14 +823,8 @@ static void axienet_ethtools_get_regs(struct net_device *ndev,
 	data[29] = axienet_ior(lp, XAE_FMI_OFFSET);
 	data[30] = axienet_ior(lp, XAE_AF0_OFFSET);
 	data[31] = axienet_ior(lp, XAE_AF1_OFFSET);
-	data[32] = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	data[33] = axienet_dma_in32(lp, XAXIDMA_TX_SR_OFFSET);
-	data[34] = axienet_dma_in32(lp, XAXIDMA_TX_CDESC_OFFSET);
-	data[35] = axienet_dma_in32(lp, XAXIDMA_TX_TDESC_OFFSET);
-	data[36] = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	data[37] = axienet_dma_in32(lp, XAXIDMA_RX_SR_OFFSET);
-	data[38] = axienet_dma_in32(lp, XAXIDMA_RX_CDESC_OFFSET);
-	data[39] = axienet_dma_in32(lp, XAXIDMA_RX_TDESC_OFFSET);
+
+	/*TODO : explore how to dump DMA registers here?*/
 }
 
 static void axienet_ethtools_get_ringparam(struct net_device *ndev,
@@ -1410,14 +914,8 @@ axienet_ethtools_set_pauseparam(struct net_device *ndev,
 static int axienet_ethtools_get_coalesce(struct net_device *ndev,
 					 struct ethtool_coalesce *ecoalesce)
 {
-	u32 regval = 0;
-	struct axienet_local *lp = netdev_priv(ndev);
-	regval = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	ecoalesce->rx_max_coalesced_frames = (regval & XAXIDMA_COALESCE_MASK)
-					     >> XAXIDMA_COALESCE_SHIFT;
-	regval = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	ecoalesce->tx_max_coalesced_frames = (regval & XAXIDMA_COALESCE_MASK)
-					     >> XAXIDMA_COALESCE_SHIFT;
+	/* TODO: Request and populate DMA engine TX and RX coalesc params */
+
 	return 0;
 }
 
@@ -1688,136 +1186,6 @@ static const struct phylink_mac_ops axienet_phylink_ops = {
 };
 
 /**
- * axienet_dma_err_handler - Work queue task for Axi DMA Error
- * @work:	pointer to work_struct
- *
- * Resets the Axi DMA and Axi Ethernet devices, and reconfigures the
- * Tx/Rx BDs.
- */
-static void axienet_dma_err_handler(struct work_struct *work)
-{
-	u32 axienet_status;
-	u32 cr, i;
-	struct axienet_local *lp = container_of(work, struct axienet_local,
-						dma_err_task);
-	struct net_device *ndev = lp->ndev;
-	struct axidma_bd *cur_p;
-
-	axienet_setoptions(ndev, lp->options &
-			   ~(XAE_OPTION_TXEN | XAE_OPTION_RXEN));
-	/* When we do an Axi Ethernet reset, it resets the complete core
-	 * including the MDIO. MDIO must be disabled before resetting.
-	 * Hold MDIO bus lock to avoid MDIO accesses during the reset.
-	 */
-	mutex_lock(&lp->mii_bus->mdio_lock);
-	__axienet_device_reset(lp);
-	mutex_unlock(&lp->mii_bus->mdio_lock);
-
-	for (i = 0; i < lp->tx_bd_num; i++) {
-		cur_p = &lp->tx_bd_v[i];
-		if (cur_p->cntrl) {
-			dma_addr_t addr = desc_get_phys_addr(lp, cur_p);
-
-			dma_unmap_single(ndev->dev.parent, addr,
-					 (cur_p->cntrl &
-					  XAXIDMA_BD_CTRL_LENGTH_MASK),
-					 DMA_TO_DEVICE);
-		}
-		if (cur_p->skb)
-			dev_kfree_skb_irq(cur_p->skb);
-		cur_p->phys = 0;
-		cur_p->phys_msb = 0;
-		cur_p->cntrl = 0;
-		cur_p->status = 0;
-		cur_p->app0 = 0;
-		cur_p->app1 = 0;
-		cur_p->app2 = 0;
-		cur_p->app3 = 0;
-		cur_p->app4 = 0;
-		cur_p->skb = NULL;
-	}
-
-	for (i = 0; i < lp->rx_bd_num; i++) {
-		cur_p = &lp->rx_bd_v[i];
-		cur_p->status = 0;
-		cur_p->app0 = 0;
-		cur_p->app1 = 0;
-		cur_p->app2 = 0;
-		cur_p->app3 = 0;
-		cur_p->app4 = 0;
-	}
-
-	lp->tx_bd_ci = 0;
-	lp->tx_bd_tail = 0;
-	lp->rx_bd_ci = 0;
-
-	/* Start updating the Rx channel control register */
-	cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	/* Update the interrupt coalesce count */
-	cr = ((cr & ~XAXIDMA_COALESCE_MASK) |
-	      (XAXIDMA_DFT_RX_THRESHOLD << XAXIDMA_COALESCE_SHIFT));
-	/* Update the delay timer count */
-	cr = ((cr & ~XAXIDMA_DELAY_MASK) |
-	      (XAXIDMA_DFT_RX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
-	/* Enable coalesce, delay timer and error interrupts */
-	cr |= XAXIDMA_IRQ_ALL_MASK;
-	/* Finally write to the Rx channel control register */
-	axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET, cr);
-
-	/* Start updating the Tx channel control register */
-	cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	/* Update the interrupt coalesce count */
-	cr = (((cr & ~XAXIDMA_COALESCE_MASK)) |
-	      (XAXIDMA_DFT_TX_THRESHOLD << XAXIDMA_COALESCE_SHIFT));
-	/* Update the delay timer count */
-	cr = (((cr & ~XAXIDMA_DELAY_MASK)) |
-	      (XAXIDMA_DFT_TX_WAITBOUND << XAXIDMA_DELAY_SHIFT));
-	/* Enable coalesce, delay timer and error interrupts */
-	cr |= XAXIDMA_IRQ_ALL_MASK;
-	/* Finally write to the Tx channel control register */
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, cr);
-
-	/* Populate the tail pointer and bring the Rx Axi DMA engine out of
-	 * halted state. This will make the Rx side ready for reception.
-	 */
-	axienet_dma_out_addr(lp, XAXIDMA_RX_CDESC_OFFSET, lp->rx_bd_p);
-	cr = axienet_dma_in32(lp, XAXIDMA_RX_CR_OFFSET);
-	axienet_dma_out32(lp, XAXIDMA_RX_CR_OFFSET,
-			  cr | XAXIDMA_CR_RUNSTOP_MASK);
-	axienet_dma_out_addr(lp, XAXIDMA_RX_TDESC_OFFSET, lp->rx_bd_p +
-			     (sizeof(*lp->rx_bd_v) * (lp->rx_bd_num - 1)));
-
-	/* Write to the RS (Run-stop) bit in the Tx channel control register.
-	 * Tx channel is now ready to run. But only after we write to the
-	 * tail pointer register that the Tx channel will start transmitting
-	 */
-	axienet_dma_out_addr(lp, XAXIDMA_TX_CDESC_OFFSET, lp->tx_bd_p);
-	cr = axienet_dma_in32(lp, XAXIDMA_TX_CR_OFFSET);
-	axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET,
-			  cr | XAXIDMA_CR_RUNSTOP_MASK);
-
-	axienet_status = axienet_ior(lp, XAE_RCW1_OFFSET);
-	axienet_status &= ~XAE_RCW1_RX_MASK;
-	axienet_iow(lp, XAE_RCW1_OFFSET, axienet_status);
-
-	axienet_status = axienet_ior(lp, XAE_IP_OFFSET);
-	if (axienet_status & XAE_INT_RXRJECT_MASK)
-		axienet_iow(lp, XAE_IS_OFFSET, XAE_INT_RXRJECT_MASK);
-	axienet_iow(lp, XAE_IE_OFFSET, lp->eth_irq > 0 ?
-		    XAE_INT_RECV_ERROR_MASK : 0);
-	axienet_iow(lp, XAE_FCC_OFFSET, XAE_FCC_FCRX_MASK);
-
-	/* Sync default options with HW but leave receiver and
-	 * transmitter disabled.
-	 */
-	axienet_setoptions(ndev, lp->options &
-			   ~(XAE_OPTION_TXEN | XAE_OPTION_RXEN));
-	axienet_set_mac_address(ndev, NULL);
-	axienet_set_multicast_list(ndev);
-	axienet_setoptions(ndev, lp->options);
-}
-
-/**
  * axienet_probe - Axi Ethernet probe function.
  * @pdev:	Pointer to platform device structure.
  *
@@ -1832,12 +1200,10 @@ static void axienet_dma_err_handler(struct work_struct *work)
 static int axienet_probe(struct platform_device *pdev)
 {
 	int ret;
-	struct device_node *np;
 	struct axienet_local *lp;
 	struct net_device *ndev;
 	const void *mac_addr;
 	struct resource *ethres;
-	int addr_width = 32;
 	u32 value;
 
 	ndev = alloc_etherdev(sizeof(*lp));
@@ -1972,74 +1338,6 @@ static int axienet_probe(struct platform_device *pdev)
 		goto free_netdev;
 	}
 
-	/* Find the DMA node, map the DMA registers, and decode the DMA IRQs */
-	np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
-	if (np) {
-		struct resource dmares;
-
-		ret = of_address_to_resource(np, 0, &dmares);
-		if (ret) {
-			dev_err(&pdev->dev,
-				"unable to get DMA resource\n");
-			of_node_put(np);
-			goto free_netdev;
-		}
-		lp->dma_regs = devm_ioremap_resource(&pdev->dev,
-						     &dmares);
-		lp->rx_irq = irq_of_parse_and_map(np, 1);
-		lp->tx_irq = irq_of_parse_and_map(np, 0);
-		of_node_put(np);
-		lp->eth_irq = platform_get_irq_optional(pdev, 0);
-	} else {
-		/* Check for these resources directly on the Ethernet node. */
-		struct resource *res = platform_get_resource(pdev,
-							     IORESOURCE_MEM, 1);
-		lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
-		lp->rx_irq = platform_get_irq(pdev, 1);
-		lp->tx_irq = platform_get_irq(pdev, 0);
-		lp->eth_irq = platform_get_irq_optional(pdev, 2);
-	}
-	if (IS_ERR(lp->dma_regs)) {
-		dev_err(&pdev->dev, "could not map DMA regs\n");
-		ret = PTR_ERR(lp->dma_regs);
-		goto free_netdev;
-	}
-	if ((lp->rx_irq <= 0) || (lp->tx_irq <= 0)) {
-		dev_err(&pdev->dev, "could not determine irqs\n");
-		ret = -ENOMEM;
-		goto free_netdev;
-	}
-
-	/* Autodetect the need for 64-bit DMA pointers.
-	 * When the IP is configured for a bus width bigger than 32 bits,
-	 * writing the MSB registers is mandatory, even if they are all 0.
-	 * We can detect this case by writing all 1's to one such register
-	 * and see if that sticks: when the IP is configured for 32 bits
-	 * only, those registers are RES0.
-	 * Those MSB registers were introduced in IP v7.1, which we check first.
-	 */
-	if ((axienet_ior(lp, XAE_ID_OFFSET) >> 24) >= 0x9) {
-		void __iomem *desc = lp->dma_regs + XAXIDMA_TX_CDESC_OFFSET + 4;
-
-		iowrite32(0x0, desc);
-		if (ioread32(desc) == 0) {	/* sanity check */
-			iowrite32(0xffffffff, desc);
-			if (ioread32(desc) > 0) {
-				lp->features |= XAE_FEATURE_DMA_64BIT;
-				addr_width = 64;
-				dev_info(&pdev->dev,
-					 "autodetected 64-bit DMA range\n");
-			}
-			iowrite32(0x0, desc);
-		}
-	}
-
-	ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(addr_width));
-	if (ret) {
-		dev_err(&pdev->dev, "No suitable DMA available\n");
-		goto free_netdev;
-	}
-
 	/* Check for Ethernet core IRQ (optional) */
 	if (lp->eth_irq <= 0)
 		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
-- 
2.7.4



From robh at kernel.org  Fri Apr  9 19:23:38 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:23:38 -0500
Subject: [PATCH 3/8] dt-bindings: apu: Add MT8192 APU power domain
In-Reply-To: <1617766086-5502-4-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-4-git-send-email-flora.fu@mediatek.com>
Message-ID: <20210409182338.GA3895583@robh.at.kernel.org>

On Wed, Apr 07, 2021 at 11:28:01AM +0800, Flora Fu wrote:
> Create MT8192 APU power domain bindings.
> Add top power domain id.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---
>  include/dt-bindings/power/mt8192-apu-power.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 include/dt-bindings/power/mt8192-apu-power.h
> 
> diff --git a/include/dt-bindings/power/mt8192-apu-power.h b/include/dt-bindings/power/mt8192-apu-power.h
> new file mode 100644
> index 000000000000..b821bd4811a6
> --- /dev/null
> +++ b/include/dt-bindings/power/mt8192-apu-power.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_MT8192_APU_POWER_H
> +#define _DT_BINDINGS_POWER_MT8192_APU_POWER_H
> +
> +#define MT8192_POWER_DOMAIN_APUSYS_TOP	0

Really, you don't know what the other power domains are? Please make 
this as complete as possible. These headers create a merge mess.

Rob


From robh at kernel.org  Fri Apr  9 19:25:38 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:25:38 -0500
Subject: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document
 bindings for APU
In-Reply-To: <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>
Message-ID: <20210409182538.GA3913794@robh.at.kernel.org>

On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> Document the apusys bindings.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---
>  .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> new file mode 100644
> index 000000000000..dc04a46f1bad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek APUSYS Controller
> +
> +maintainers:
> +  - Flora Fu <flora.fu at mediatek.com>
> +
> +description:
> +  The Mediatek apusys controller provides functional configurations and clocks
> +  to the system.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - mediatek,mt8192-apu_mbox
> +          - mediatek,mt8192-apu_conn
> +          - mediatek,mt8192-apu_vcore

s/_/-/

> +      - const: syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    apu_mbox: apu_mbox at 19000000 {

mailbox at ...? Is this a mailbox provider?

> +        compatible = "mediatek,mt8192-apu_mbox", "syscon";
> +        reg = <0x19000000 0x1000>;
> +    };
> +
> +  - |
> +    apu_conn: apu_conn at 19020000 {
> +        compatible = "mediatek,mt8192-apu_conn", "syscon";
> +        reg = <0x19020000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    apu_vcore: apu_vcore at 19029000 {
> +        compatible = "mediatek,mt8192-apu_vcore", "syscon";
> +        reg = <0x19029000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> -- 
> 2.18.0
> 


From stefan.wahren at i2se.com  Fri Apr  9 19:28:59 2021
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 9 Apr 2021 20:28:59 +0200
Subject: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
In-Reply-To: <2dbb9e8c1f1e107712b05e36aa1b244329381425.camel@suse.de>
References: <20210322185816.27582-1-nsaenz@kernel.org>
 <20210322185816.27582-5-nsaenz@kernel.org>
 <401100ea-90ad-57b1-50da-967118a090da@i2se.com>
 <78dec30c052e9bb76e52c38f3da5af371e5d65f5.camel@suse.de>
 <2d2a2638-8213-5d6e-0a3a-927ed5bb2ed7@i2se.com>
 <c7c8e20d3d11c7d6cd203797c5faffa8a4d202a6.camel@suse.de>
 <CAOGqxeUxOA_s6=KUh_XWFtRF_EWZgQH_y2MEdxUeDQTYMeb+3A@mail.gmail.com>
 <4d4e3de99dbee711cf47878bf98a7cc34c3f1e65.camel@suse.de>
 <CAOGqxeWzjn70A_gP4Eh_ZLW0H3KkE_wA7QzeGRqU1u7xtJr-+Q@mail.gmail.com>
 <2dbb9e8c1f1e107712b05e36aa1b244329381425.camel@suse.de>
Message-ID: <6dfd1108-deaa-8606-01a9-4739e7c2da91@i2se.com>

Hi Nicolas,

Am 09.04.21 um 12:54 schrieb Nicolas Saenz Julienne:
> Hi again,
>
> On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote:
>> Nicolas,
>>
>> I got a better description of the failure and it looks like the bus
>> clock needs to be limited to 300KHz for a 500MHz core clock.
>> What's happening is that an internal reset sequence is needed after a
>> command timeout and the reset signal needs to be asserted for at least
>> 2 ticks of the bus clock. This is done using a 12 bit counter clocked
>> by the core clock. That means a 500MHz core clock produces a 122KHz
>> reset signal which is too fast for 2 ticks of the 200KHz bus clock
>> (100KHz) but is okay for the 300KHz (150Khz) bus clock.
> Is there any value in implementing this in a generic way?

i don't have any idea which callback could manipulate the reset
duration. Limiting the min clk frequency looks like the less invasive
solution to me. Touching the DT isn't recommend.

Best regards





From masahiroy at kernel.org  Fri Apr  9 19:28:21 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sat, 10 Apr 2021 03:28:21 +0900
Subject: [PATCH][V2] clk: uniphier: Fix potential infinite loop
In-Reply-To: <20210409090104.629722-2-colin.king@canonical.com>
References: <20210409090104.629722-1-colin.king@canonical.com>
 <20210409090104.629722-2-colin.king@canonical.com>
Message-ID: <CAK7LNAS=cFxQ3Z3GPdQfwB8DBLDbY9Oxm+yK9cjz116HZ8OKAw@mail.gmail.com>

On Fri, Apr 9, 2021 at 6:01 PM Colin King <colin.king at canonical.com> wrote:
>
> From: Colin Ian King <colin.king at canonical.com>
>
> The for-loop iterates with a u8 loop counter i and compares this
> with the loop upper limit of num_parents that is an int type.
> There is a potential infinite loop if num_parents is larger than
> the u8 loop counter. Fix this by making the loop counter the same
> type as num_parents.  Also make num_parents an unsigned int to
> match the return type of the call to clk_hw_get_num_parents.
>
> Addresses-Coverity: ("Infinite loop")
> Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
>
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>
> V2: Make num_parents an unsigned int to match return type of
>     clk_hw_get_num_parents().

Reviewed-by: Masahiro Yamada <masahiroy at kernel.org>




> ---
>  drivers/clk/uniphier/clk-uniphier-mux.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
> index 462c84321b2d..1998e9d4cfc0 100644
> --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> @@ -31,10 +31,10 @@ static int uniphier_clk_mux_set_parent(struct clk_hw *hw, u8 index)
>  static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
>  {
>         struct uniphier_clk_mux *mux = to_uniphier_clk_mux(hw);
> -       int num_parents = clk_hw_get_num_parents(hw);
> +       unsigned int num_parents = clk_hw_get_num_parents(hw);
>         int ret;
>         unsigned int val;
> -       u8 i;
> +       unsigned int i;
>
>         ret = regmap_read(mux->regmap, mux->reg, &val);
>         if (ret)
> --
> 2.30.2
>


-- 
Best Regards
Masahiro Yamada


From robh at kernel.org  Fri Apr  9 19:41:18 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:41:18 -0500
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <20210408015218.20560-2-steven_lee@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
Message-ID: <20210409184118.GA3934798@robh.at.kernel.org>

On Thu, Apr 08, 2021 at 09:52:17AM +0800, Steven Lee wrote:
> AST2600-A2 EVB provides the reference design for enabling SD bus power
> and toggling SD bus signal voltage by GPIO pins.
> Add the definition and example for power-gpio and power-switch-gpio
> properties.
> 
> In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> a 1.8v and a 3.3v power load switch that providing signal voltage to
> SD1 bus.
> If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> disabled.
> If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> voltage is 3.3v. Otherwise, 1.8v power load switch will be enabled, SD1
> signal voltage becomes 1.8v.
> 
> AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and GPIOV3
> as power-switch-gpio.
> 
> Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> ---
>  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> index 987b287f3bff..515a74614f3c 100644
> --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> @@ -37,6 +37,14 @@ properties:
>    clocks:
>      maxItems: 1
>      description: The SD/SDIO controller clock gate
> +  power-gpio:

'-gpios' is the preferred form even if just 1.

> +    description:
> +      The GPIO for enabling/disabling SD bus power.
> +    maxItems: 1

blank line

> +  power-switch-gpio:
> +    description:
> +      The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> +    maxItems: 1
>  
>  patternProperties:
>    "^sdhci@[0-9a-f]+$":
> @@ -61,6 +69,14 @@ patternProperties:
>        sdhci,auto-cmd12:
>          type: boolean
>          description: Specifies that controller should use auto CMD12
> +      power-gpio:
> +        description:
> +          The GPIO for enabling/disabling SD bus power.
> +        maxItems: 1
> +      power-switch-gpio:
> +        description:
> +          The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> +        maxItems: 1
>      required:
>        - compatible
>        - reg
> @@ -80,6 +96,7 @@ required:
>  examples:
>    - |
>      #include <dt-bindings/clock/aspeed-clock.h>
> +    #include <dt-bindings/gpio/aspeed-gpio.h>
>      sdc at 1e740000 {
>              compatible = "aspeed,ast2500-sd-controller";
>              reg = <0x1e740000 0x100>;
> @@ -94,6 +111,10 @@ examples:
>                      interrupts = <26>;
>                      sdhci,auto-cmd12;
>                      clocks = <&syscon ASPEED_CLK_SDIO>;
> +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
> +                                     GPIO_ACTIVE_HIGH>;
> +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 1)
> +                                     GPIO_ACTIVE_HIGH>;
>              };
>  
>              sdhci1: sdhci at 200 {
> @@ -102,5 +123,9 @@ examples:
>                      interrupts = <26>;
>                      sdhci,auto-cmd12;
>                      clocks = <&syscon ASPEED_CLK_SDIO>;
> +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
> +                                     GPIO_ACTIVE_HIGH>;
> +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 3)
> +                                     GPIO_ACTIVE_HIGH>;
>              };
>      };
> -- 
> 2.17.1
> 


From robh at kernel.org  Fri Apr  9 19:41:47 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 9 Apr 2021 13:41:47 -0500
Subject: [PATCH 3/6] dt-bindings: usb: mtk-xhci: add wakeup interrupt
In-Reply-To: <1617874514-12282-3-git-send-email-chunfeng.yun@mediatek.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-3-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <20210409184147.GA3937709@robh.at.kernel.org>

On Thu, 08 Apr 2021 17:35:11 +0800, Chunfeng Yun wrote:
> Add an interrupt which is EINT usually to support runtime PM,
> meanwhile add "interrupt-names" property, for backward
> compatibility, it's optional and used when wakeup interrupt
> exists
> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml  | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Fri Apr  9 20:16:19 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 03:16:19 +0800
Subject: [soc:aspeed/lpc] BUILD SUCCESS
 489774ff5db943642751f4f0fdac9033239208c6
Message-ID: <6070a803.SWmF4hVgUYEEa0mZ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git aspeed/lpc
branch HEAD: 489774ff5db943642751f4f0fdac9033239208c6  soc: aspeed: Adapt to new LPC device tree layout

elapsed time: 822m

configs tested: 239
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          polaris_defconfig
arc                              allyesconfig
powerpc                     asp8347_defconfig
m68k                          multi_defconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
mips                malta_kvm_guest_defconfig
sh                          landisk_defconfig
arm                      tct_hammer_defconfig
mips                     loongson1b_defconfig
mips                         tb0226_defconfig
openrisc                  or1klitex_defconfig
xtensa                    xip_kc705_defconfig
arm                            hisi_defconfig
powerpc                      pmac32_defconfig
arm                          lpd270_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
ia64                             allyesconfig
mips                          ath79_defconfig
m68k                                defconfig
nios2                            alldefconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
mips                        nlm_xlr_defconfig
powerpc                 mpc8315_rdb_defconfig
mips                        workpad_defconfig
sh                          rsk7203_defconfig
arm                        spear6xx_defconfig
sh                          sdk7786_defconfig
arm                         lubbock_defconfig
powerpc                          allmodconfig
arm                       aspeed_g4_defconfig
arm                       omap2plus_defconfig
xtensa                generic_kc705_defconfig
powerpc                      pcm030_defconfig
arc                 nsimosci_hs_smp_defconfig
xtensa                  nommu_kc705_defconfig
nios2                               defconfig
sh                      rts7751r2d1_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
powerpc                       eiger_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
mips                  maltasmvp_eva_defconfig
arm                          ep93xx_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
parisc                           alldefconfig
m68k                         amcore_defconfig
mips                       bmips_be_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
um                             i386_defconfig
sh                          rsk7264_defconfig
ia64                        generic_defconfig
mips                        vocore2_defconfig
powerpc                           allnoconfig
powerpc                    sam440ep_defconfig
powerpc                       ppc64_defconfig
arm                          ixp4xx_defconfig
mips                         cobalt_defconfig
sh                           se7206_defconfig
mips                      fuloong2e_defconfig
arm                           sama5_defconfig
mips                      maltasmvp_defconfig
sh                                  defconfig
powerpc                 mpc8313_rdb_defconfig
arm                            dove_defconfig
arm                  colibri_pxa270_defconfig
sh                           se7619_defconfig
powerpc                      chrp32_defconfig
arm                         socfpga_defconfig
arm                            pleb_defconfig
arm                            xcep_defconfig
mips                            e55_defconfig
um                                allnoconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
arm                       imx_v4_v5_defconfig
mips                           ip27_defconfig
mips                         mpc30x_defconfig
s390                                defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
arm                       versatile_defconfig
sh                          lboxre2_defconfig
arm                         cm_x300_defconfig
m68k                       m5475evb_defconfig
mips                         bigsur_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
powerpc                         ps3_defconfig
arm                         at91_dt_defconfig
powerpc                      obs600_defconfig
arm                        mini2440_defconfig
microblaze                      mmu_defconfig
powerpc                 mpc832x_rdb_defconfig
sh                ecovec24-romimage_defconfig
powerpc                     pseries_defconfig
powerpc                     tqm8548_defconfig
powerpc                  iss476-smp_defconfig
arm                        shmobile_defconfig
arm                         s3c2410_defconfig
m68k                        stmark2_defconfig
m68k                        m5407c3_defconfig
sh                            titan_defconfig
arm                        oxnas_v6_defconfig
mips                     cu1830-neo_defconfig
arc                        nsim_700_defconfig
arm                       netwinder_defconfig
sh                          kfr2r09_defconfig
parisc                              defconfig
arm                            mps2_defconfig
arm                  colibri_pxa300_defconfig
powerpc                 mpc8540_ads_defconfig
microblaze                          defconfig
sh                        sh7785lcr_defconfig
sh                           se7750_defconfig
mips                         tb0219_defconfig
m68k                       m5208evb_defconfig
openrisc                            defconfig
ia64                          tiger_defconfig
sh                   sh7770_generic_defconfig
powerpc                 canyonlands_defconfig
powerpc                    mvme5100_defconfig
csky                                defconfig
arm                        cerfcube_defconfig
mips                      maltaaprp_defconfig
sh                          urquell_defconfig
arc                      axs103_smp_defconfig
powerpc                     taishan_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
arm                         shannon_defconfig
mips                           xway_defconfig
mips                       rbtx49xx_defconfig
powerpc                     ksi8560_defconfig
xtensa                  audio_kc705_defconfig
arm                          badge4_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
s390                          debug_defconfig
powerpc                     sequoia_defconfig
sh                          r7785rp_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
arm                         mv78xx0_defconfig
arm                       multi_v4t_defconfig
xtensa                  cadence_csp_defconfig
powerpc64                           defconfig
sh                          sdk7780_defconfig
sh                   secureedge5410_defconfig
arc                        nsimosci_defconfig
ia64                                defconfig
ia64                             allmodconfig
m68k                             allmodconfig
m68k                             allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
arc                                 defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
i386                 randconfig-a012-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 20:16:21 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 03:16:21 +0800
Subject: [soc:bmc/dt] BUILD SUCCESS
 ee33e2fb3d70267de00f7c0b09e7e3b309a686df
Message-ID: <6070a805.RgzOXnCwEK0ay0wV%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git bmc/dt
branch HEAD: ee33e2fb3d70267de00f7c0b09e7e3b309a686df  ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree

elapsed time: 822m

configs tested: 245
configs skipped: 97

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          polaris_defconfig
arc                              allyesconfig
powerpc                     asp8347_defconfig
m68k                          multi_defconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
mips                malta_kvm_guest_defconfig
sh                          landisk_defconfig
arm                      tct_hammer_defconfig
mips                     loongson1b_defconfig
mips                         tb0226_defconfig
openrisc                  or1klitex_defconfig
xtensa                    xip_kc705_defconfig
arm                            hisi_defconfig
powerpc                      pmac32_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
ia64                             allyesconfig
mips                          ath79_defconfig
m68k                                defconfig
nios2                            alldefconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
mips                        nlm_xlr_defconfig
powerpc                 mpc8315_rdb_defconfig
mips                        workpad_defconfig
sh                          rsk7203_defconfig
arm                        spear6xx_defconfig
sh                          sdk7786_defconfig
arm                         lubbock_defconfig
powerpc                          allmodconfig
arm                         shannon_defconfig
powerpc                  mpc866_ads_defconfig
m68k                             alldefconfig
arc                           tb10x_defconfig
arm                       aspeed_g4_defconfig
arm                       omap2plus_defconfig
xtensa                generic_kc705_defconfig
powerpc                      pcm030_defconfig
arc                 nsimosci_hs_smp_defconfig
xtensa                  nommu_kc705_defconfig
nios2                               defconfig
sh                      rts7751r2d1_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
powerpc                       eiger_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
mips                  maltasmvp_eva_defconfig
arm                          ep93xx_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
um                             i386_defconfig
sh                          rsk7264_defconfig
ia64                        generic_defconfig
mips                        vocore2_defconfig
powerpc                           allnoconfig
powerpc                    sam440ep_defconfig
powerpc                       ppc64_defconfig
arm                          ixp4xx_defconfig
mips                         cobalt_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
sh                           se7206_defconfig
mips                      fuloong2e_defconfig
arm                           sama5_defconfig
mips                      maltasmvp_defconfig
arm                            dove_defconfig
arm                  colibri_pxa270_defconfig
powerpc                      chrp32_defconfig
arm                         socfpga_defconfig
arm                            pleb_defconfig
arm                            xcep_defconfig
mips                            e55_defconfig
um                                allnoconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
arm                       imx_v4_v5_defconfig
mips                           ip27_defconfig
mips                         mpc30x_defconfig
s390                                defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
arm                       versatile_defconfig
sh                          lboxre2_defconfig
arm                         cm_x300_defconfig
m68k                       m5475evb_defconfig
mips                         bigsur_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
powerpc                         ps3_defconfig
arm                         at91_dt_defconfig
powerpc                      obs600_defconfig
arm                        mini2440_defconfig
microblaze                      mmu_defconfig
arm                        shmobile_defconfig
arm                         s3c2410_defconfig
m68k                        stmark2_defconfig
m68k                        m5407c3_defconfig
sh                            titan_defconfig
arm                        oxnas_v6_defconfig
mips                     cu1830-neo_defconfig
arc                        nsim_700_defconfig
arm                       netwinder_defconfig
sh                          kfr2r09_defconfig
parisc                              defconfig
powerpc                     tqm8548_defconfig
arm                            mps2_defconfig
powerpc                   bluestone_defconfig
arc                                 defconfig
mips                      loongson3_defconfig
arm                  colibri_pxa300_defconfig
powerpc                 mpc8540_ads_defconfig
m68k                         amcore_defconfig
microblaze                          defconfig
sh                        sh7785lcr_defconfig
mips                         tb0219_defconfig
powerpc                 mpc834x_mds_defconfig
m68k                       m5208evb_defconfig
openrisc                            defconfig
ia64                          tiger_defconfig
sh                   sh7770_generic_defconfig
powerpc                 canyonlands_defconfig
powerpc                    mvme5100_defconfig
csky                                defconfig
arm                        cerfcube_defconfig
mips                      maltaaprp_defconfig
sh                          urquell_defconfig
arc                      axs103_smp_defconfig
powerpc                     taishan_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
sh                           se7619_defconfig
mips                       rbtx49xx_defconfig
powerpc                     ksi8560_defconfig
xtensa                  audio_kc705_defconfig
arm                          badge4_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
s390                          debug_defconfig
powerpc                     sequoia_defconfig
sh                          r7785rp_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
arm                         mv78xx0_defconfig
arm                       multi_v4t_defconfig
xtensa                  cadence_csp_defconfig
powerpc64                           defconfig
sh                          sdk7780_defconfig
sh                   secureedge5410_defconfig
arc                        nsimosci_defconfig
ia64                                defconfig
ia64                             allmodconfig
m68k                             allmodconfig
m68k                             allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
i386                 randconfig-a012-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From zweiss at equinix.com  Fri Apr  9 20:21:34 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 19:21:34 +0000
Subject: [PATCH v2 09/21] ipmi: kcs_bmc: Split out kcs_bmc_cdev_ipmi
In-Reply-To: <6aa7c000-da09-4058-96b4-f330193c7fc6@www.fastmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-9-andrew@aj.id.au> <YG/QUCIdEzW1ghVA@packtop>
 <6aa7c000-da09-4058-96b4-f330193c7fc6@www.fastmail.com>
Message-ID: <YHCpPa3EtVy9XcLn@packtop>

On Fri, Apr 09, 2021 at 12:48:21AM CDT, Andrew Jeffery wrote:
>
>
>On Fri, 9 Apr 2021, at 13:26, Zev Weiss wrote:
>> On Fri, Mar 19, 2021 at 01:27:40AM CDT, Andrew Jeffery wrote:
>> >Take steps towards defining a coherent API to separate the KCS device
>> >drivers from the userspace interface. Decreasing the coupling will
>> >improve the separation of concerns and enable the introduction of
>> >alternative userspace interfaces.
>> >
>> >For now, simply split the chardev logic out to a separate file. The code
>> >continues to build into the same module.
>> >
>> >Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>> >---
>> > drivers/char/ipmi/Makefile            |   2 +-
>> > drivers/char/ipmi/kcs_bmc.c           | 423 +------------------------
>> > drivers/char/ipmi/kcs_bmc.h           |  10 +-
>> > drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 428 ++++++++++++++++++++++++++
>> > 4 files changed, 451 insertions(+), 412 deletions(-)
>> > create mode 100644 drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>> >
>> >diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>> >index 0822adc2ec41..a302bc865370 100644
>> >--- a/drivers/char/ipmi/Makefile
>> >+++ b/drivers/char/ipmi/Makefile
>> >@@ -22,7 +22,7 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
>> > obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
>> > obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
>> > obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
>> >-obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
>> >+obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o kcs_bmc_cdev_ipmi.o
>> > obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>> > obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
>> > obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>> >diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>> >index c4336c1f2d6d..ef5c48ffe74a 100644
>> >--- a/drivers/char/ipmi/kcs_bmc.c
>> >+++ b/drivers/char/ipmi/kcs_bmc.c
>> >@@ -3,446 +3,51 @@
>> >  * Copyright (c) 2015-2018, Intel Corporation.
>> >  */
>> >
>> >-#define pr_fmt(fmt) "kcs-bmc: " fmt
>> >-
>> >-#include <linux/errno.h>
>> >-#include <linux/io.h>
>> >-#include <linux/ipmi_bmc.h>
>> > #include <linux/module.h>
>> >-#include <linux/platform_device.h>
>> >-#include <linux/poll.h>
>> >-#include <linux/sched.h>
>> >-#include <linux/slab.h>
>> >
>> > #include "kcs_bmc.h"
>> >
>> >-#define DEVICE_NAME "ipmi-kcs"
>> >-
>> >-#define KCS_MSG_BUFSIZ    1000
>> >-
>> >-#define KCS_ZERO_DATA     0
>> >-
>> >-
>> >-/* IPMI 2.0 - Table 9-1, KCS Interface Status Register Bits */
>> >-#define KCS_STATUS_STATE(state) (state << 6)
>> >-#define KCS_STATUS_STATE_MASK   GENMASK(7, 6)
>> >-#define KCS_STATUS_CMD_DAT      BIT(3)
>> >-#define KCS_STATUS_SMS_ATN      BIT(2)
>> >-#define KCS_STATUS_IBF          BIT(1)
>> >-#define KCS_STATUS_OBF          BIT(0)
>> >-
>> >-/* IPMI 2.0 - Table 9-2, KCS Interface State Bits */
>> >-enum kcs_states {
>> >-	IDLE_STATE  = 0,
>> >-	READ_STATE  = 1,
>> >-	WRITE_STATE = 2,
>> >-	ERROR_STATE = 3,
>> >-};
>> >-
>> >-/* IPMI 2.0 - Table 9-3, KCS Interface Control Codes */
>> >-#define KCS_CMD_GET_STATUS_ABORT  0x60
>> >-#define KCS_CMD_WRITE_START       0x61
>> >-#define KCS_CMD_WRITE_END         0x62
>> >-#define KCS_CMD_READ_BYTE         0x68
>> >-
>> >-static inline u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
>> >+u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc)
>> > {
>> > 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.idr);
>> > }
>> >+EXPORT_SYMBOL(kcs_bmc_read_data);
>> >
>> >-static inline void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
>> >+void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data)
>> > {
>> > 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.odr, data);
>> > }
>> >+EXPORT_SYMBOL(kcs_bmc_write_data);
>> >
>> >-static inline u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
>> >+u8 kcs_bmc_read_status(struct kcs_bmc *kcs_bmc)
>> > {
>> > 	return kcs_bmc->io_inputb(kcs_bmc, kcs_bmc->ioreg.str);
>> > }
>> >+EXPORT_SYMBOL(kcs_bmc_read_status);
>> >
>> >-static inline void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
>> >+void kcs_bmc_write_status(struct kcs_bmc *kcs_bmc, u8 data)
>> > {
>> > 	kcs_bmc->io_outputb(kcs_bmc, kcs_bmc->ioreg.str, data);
>> > }
>> >+EXPORT_SYMBOL(kcs_bmc_write_status);
>> >
>> >-static void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
>> >+void kcs_bmc_update_status(struct kcs_bmc *kcs_bmc, u8 mask, u8 val)
>> > {
>> > 	kcs_bmc->io_updateb(kcs_bmc, kcs_bmc->ioreg.str, mask, val);
>> > }
>> >+EXPORT_SYMBOL(kcs_bmc_update_status);
>> >
>> >-static inline void set_state(struct kcs_bmc *kcs_bmc, u8 state)
>> >-{
>> >-	kcs_bmc_update_status(kcs_bmc, KCS_STATUS_STATE_MASK,
>> >-					KCS_STATUS_STATE(state));
>> >-}
>> >-
>> >-static void kcs_force_abort(struct kcs_bmc *kcs_bmc)
>> >-{
>> >-	set_state(kcs_bmc, ERROR_STATE);
>> >-	kcs_bmc_read_data(kcs_bmc);
>> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-
>> >-	kcs_bmc->phase = KCS_PHASE_ERROR;
>> >-	kcs_bmc->data_in_avail = false;
>> >-	kcs_bmc->data_in_idx = 0;
>> >-}
>> >-
>> >-static void kcs_bmc_handle_data(struct kcs_bmc *kcs_bmc)
>> >-{
>> >-	u8 data;
>> >-
>> >-	switch (kcs_bmc->phase) {
>> >-	case KCS_PHASE_WRITE_START:
>> >-		kcs_bmc->phase = KCS_PHASE_WRITE_DATA;
>> >-		fallthrough;
>> >-
>> >-	case KCS_PHASE_WRITE_DATA:
>> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>> >-			set_state(kcs_bmc, WRITE_STATE);
>> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>> >-						kcs_bmc_read_data(kcs_bmc);
>> >-		} else {
>> >-			kcs_force_abort(kcs_bmc);
>> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
>> >-		}
>> >-		break;
>> >-
>> >-	case KCS_PHASE_WRITE_END_CMD:
>> >-		if (kcs_bmc->data_in_idx < KCS_MSG_BUFSIZ) {
>> >-			set_state(kcs_bmc, READ_STATE);
>> >-			kcs_bmc->data_in[kcs_bmc->data_in_idx++] =
>> >-						kcs_bmc_read_data(kcs_bmc);
>> >-			kcs_bmc->phase = KCS_PHASE_WRITE_DONE;
>> >-			kcs_bmc->data_in_avail = true;
>> >-			wake_up_interruptible(&kcs_bmc->queue);
>> >-		} else {
>> >-			kcs_force_abort(kcs_bmc);
>> >-			kcs_bmc->error = KCS_LENGTH_ERROR;
>> >-		}
>> >-		break;
>> >-
>> >-	case KCS_PHASE_READ:
>> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len)
>> >-			set_state(kcs_bmc, IDLE_STATE);
>> >-
>> >-		data = kcs_bmc_read_data(kcs_bmc);
>> >-		if (data != KCS_CMD_READ_BYTE) {
>> >-			set_state(kcs_bmc, ERROR_STATE);
>> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-			break;
>> >-		}
>> >-
>> >-		if (kcs_bmc->data_out_idx == kcs_bmc->data_out_len) {
>> >-			kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-			kcs_bmc->phase = KCS_PHASE_IDLE;
>> >-			break;
>> >-		}
>> >-
>> >-		kcs_bmc_write_data(kcs_bmc,
>> >-			kcs_bmc->data_out[kcs_bmc->data_out_idx++]);
>> >-		break;
>> >-
>> >-	case KCS_PHASE_ABORT_ERROR1:
>> >-		set_state(kcs_bmc, READ_STATE);
>> >-		kcs_bmc_read_data(kcs_bmc);
>> >-		kcs_bmc_write_data(kcs_bmc, kcs_bmc->error);
>> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR2;
>> >-		break;
>> >-
>> >-	case KCS_PHASE_ABORT_ERROR2:
>> >-		set_state(kcs_bmc, IDLE_STATE);
>> >-		kcs_bmc_read_data(kcs_bmc);
>> >-		kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-		kcs_bmc->phase = KCS_PHASE_IDLE;
>> >-		break;
>> >-
>> >-	default:
>> >-		kcs_force_abort(kcs_bmc);
>> >-		break;
>> >-	}
>> >-}
>> >-
>> >-static void kcs_bmc_handle_cmd(struct kcs_bmc *kcs_bmc)
>> >-{
>> >-	u8 cmd;
>> >-
>> >-	set_state(kcs_bmc, WRITE_STATE);
>> >-	kcs_bmc_write_data(kcs_bmc, KCS_ZERO_DATA);
>> >-
>> >-	cmd = kcs_bmc_read_data(kcs_bmc);
>> >-	switch (cmd) {
>> >-	case KCS_CMD_WRITE_START:
>> >-		kcs_bmc->phase = KCS_PHASE_WRITE_START;
>> >-		kcs_bmc->error = KCS_NO_ERROR;
>> >-		kcs_bmc->data_in_avail = false;
>> >-		kcs_bmc->data_in_idx = 0;
>> >-		break;
>> >-
>> >-	case KCS_CMD_WRITE_END:
>> >-		if (kcs_bmc->phase != KCS_PHASE_WRITE_DATA) {
>> >-			kcs_force_abort(kcs_bmc);
>> >-			break;
>> >-		}
>> >-
>> >-		kcs_bmc->phase = KCS_PHASE_WRITE_END_CMD;
>> >-		break;
>> >-
>> >-	case KCS_CMD_GET_STATUS_ABORT:
>> >-		if (kcs_bmc->error == KCS_NO_ERROR)
>> >-			kcs_bmc->error = KCS_ABORTED_BY_COMMAND;
>> >-
>> >-		kcs_bmc->phase = KCS_PHASE_ABORT_ERROR1;
>> >-		kcs_bmc->data_in_avail = false;
>> >-		kcs_bmc->data_in_idx = 0;
>> >-		break;
>> >-
>> >-	default:
>> >-		kcs_force_abort(kcs_bmc);
>> >-		kcs_bmc->error = KCS_ILLEGAL_CONTROL_CODE;
>> >-		break;
>> >-	}
>> >-}
>> >-
>> >+int kcs_bmc_ipmi_event(struct kcs_bmc *kcs_bmc);
>>
>> This declaration looks a bit out of place here; should it be in
>> kcs_bmc.h instead?
>
>These are only temporary and get removed later on in the series after
>some shuffling of the code.
>

Okay -- there were a couple others further down in the patch that I'm
pretty sure were strictly redundant and could perhaps be cleaned up
(kcs_bmc_ipmi_event and kcs_bmc_ipmi_alloc in kcs_bmc_cdev_ipmi.c), but
aside from that:

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From zweiss at equinix.com  Fri Apr  9 20:26:00 2021
From: zweiss at equinix.com (Zev Weiss)
Date: Fri, 9 Apr 2021 19:26:00 +0000
Subject: [PATCH v2 10/21] ipmi: kcs_bmc: Turn the driver data-structures
 inside-out
In-Reply-To: <YG/zVv4XOo1HoLd1@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-10-andrew@aj.id.au> <YG/Ql9z9X/mtOSvl@packtop>
 <ea34ee69-a266-4737-8450-4695d2d0fbd4@www.fastmail.com>
 <YG/zVv4XOo1HoLd1@packtop>
Message-ID: <YHCqR8/nZFB1HRgX@packtop>

On Fri, Apr 09, 2021 at 01:25:26AM CDT, Zev Weiss wrote:
>On Fri, Apr 09, 2021 at 12:59:09AM CDT, Andrew Jeffery wrote:
>>
>>
>>On Fri, 9 Apr 2021, at 13:27, Zev Weiss wrote:
>>>On Fri, Mar 19, 2021 at 01:27:41AM CDT, Andrew Jeffery wrote:
>>>>Make the KCS device drivers responsible for allocating their own memory.
>>>>
>>>>Until now the private data for the device driver was allocated internal
>>>>to the private data for the chardev interface. This coupling required
>>>>the slightly awkward API of passing through the struct size for the
>>>>driver private data to the chardev constructor, and then retrieving a
>>>>pointer to the driver private data from the allocated chardev memory.
>>>>
>>>>In addition to being awkward, the arrangement prevents the
>>>>implementation of alternative userspace interfaces as the device driver
>>>>private data is not independent.
>>>>
>>>>Peel a layer off the onion and turn the data-structures inside out by
>>>>exploiting container_of() and embedding `struct kcs_device` in the
>>>>driver private data.
>>>>
>>>>Signed-off-by: Andrew Jeffery <andrew at aj.id.au>
>>>>---
>>>> drivers/char/ipmi/kcs_bmc.c           | 15 +++++--
>>>> drivers/char/ipmi/kcs_bmc.h           | 12 ++----
>>>> drivers/char/ipmi/kcs_bmc_aspeed.c    | 60 ++++++++++++++++-----------
>>>> drivers/char/ipmi/kcs_bmc_cdev_ipmi.c | 60 ++++++++++++++++++---------
>>>> drivers/char/ipmi/kcs_bmc_npcm7xx.c   | 37 ++++++++++-------
>>>> 5 files changed, 113 insertions(+), 71 deletions(-)
>>>>
>>>>diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
>>>>index ef5c48ffe74a..709b6bdec165 100644
>>>>--- a/drivers/char/ipmi/kcs_bmc.c
>>>>+++ b/drivers/char/ipmi/kcs_bmc.c
>>>>@@ -44,12 +44,19 @@ int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc)
>>>> }
>>>> EXPORT_SYMBOL(kcs_bmc_handle_event);
>>>>
>>>>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>>>>-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel)
>>>>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>>>
>>>Another declaration perhaps intended for kcs_bmc.h?
>>
>>These are temporary while the code gets shuffled around. The symbol
>>name is an implementation detail, not a "public" part of the API; after
>>some further shuffling these are eventually assigned as callbacks in an
>>ops struct.
>>
>
>Okay, that makes sense.
>
>>>
>>>>+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc)
>>>> {
>>>>-	return kcs_bmc_ipmi_alloc(dev, sizeof_priv, channel);
>>>>+	return kcs_bmc_ipmi_attach_cdev(kcs_bmc);
>>>> }
>>>>-EXPORT_SYMBOL(kcs_bmc_alloc);
>>>>+EXPORT_SYMBOL(kcs_bmc_add_device);
>>>>+
>>>>+int kcs_bmc_ipmi_detach_cdev(struct kcs_bmc *kcs_bmc);
>>>
>>>Here too.
>>>
>>>>+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc)
>>>>+{
>>>>+	return kcs_bmc_ipmi_detach_cdev(kcs_bmc);
>>>>+}
>>>>+EXPORT_SYMBOL(kcs_bmc_remove_device);
>>>>
>>>> MODULE_LICENSE("GPL v2");
>>>> MODULE_AUTHOR("Haiyue Wang <haiyue.wang at linux.intel.com>");
>>>>diff --git a/drivers/char/ipmi/kcs_bmc.h b/drivers/char/ipmi/kcs_bmc.h
>>>>index febea0c8deb4..bf0ae327997f 100644
>>>>--- a/drivers/char/ipmi/kcs_bmc.h
>>>>+++ b/drivers/char/ipmi/kcs_bmc.h
>>>>@@ -67,6 +67,8 @@ struct kcs_ioreg {
>>>> };
>>>>
>>>> struct kcs_bmc {
>>>>+	struct device *dev;
>>>>+
>>>> 	spinlock_t lock;
>>>>
>>>> 	u32 channel;
>>>>@@ -94,17 +96,11 @@ struct kcs_bmc {
>>>> 	u8 *kbuffer;
>>>>
>>>> 	struct miscdevice miscdev;
>>>>-
>>>>-	unsigned long priv[];
>>>> };
>>>>
>>>>-static inline void *kcs_bmc_priv(struct kcs_bmc *kcs_bmc)
>>>>-{
>>>>-	return kcs_bmc->priv;
>>>>-}
>>>>-
>>>> int kcs_bmc_handle_event(struct kcs_bmc *kcs_bmc);
>>>>-struct kcs_bmc *kcs_bmc_alloc(struct device *dev, int sizeof_priv, u32 channel);
>>>>+int kcs_bmc_add_device(struct kcs_bmc *kcs_bmc);
>>>>+int kcs_bmc_remove_device(struct kcs_bmc *kcs_bmc);
>>>>
>>>> u8 kcs_bmc_read_data(struct kcs_bmc *kcs_bmc);
>>>> void kcs_bmc_write_data(struct kcs_bmc *kcs_bmc, u8 data);
>>>>diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
>>>>index 630cf095560e..0416ac78ce68 100644
>>>>--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
>>>>+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
>>>>@@ -61,6 +61,8 @@
>>>> #define LPC_STR4             0x11C
>>>>
>>>> struct aspeed_kcs_bmc {
>>>>+	struct kcs_bmc kcs_bmc;
>>>>+
>>>> 	struct regmap *map;
>>>> };
>>>>
>>>>@@ -69,9 +71,14 @@ struct aspeed_kcs_of_ops {
>>>> 	int (*get_io_address)(struct platform_device *pdev);
>>>> };
>>>>
>>>>+static inline struct aspeed_kcs_bmc *to_aspeed_kcs_bmc(struct kcs_bmc *kcs_bmc)
>>>>+{
>>>>+	return container_of(kcs_bmc, struct aspeed_kcs_bmc, kcs_bmc);
>>>>+}
>>>>+
>>>> static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>>>> {
>>>>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>>>>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>>>> 	u32 val = 0;
>>>> 	int rc;
>>>>
>>>>@@ -83,7 +90,7 @@ static u8 aspeed_kcs_inb(struct kcs_bmc *kcs_bmc, u32 reg)
>>>>
>>>> static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>>>> {
>>>>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>>>>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>>>> 	int rc;
>>>>
>>>> 	rc = regmap_write(priv->map, reg, data);
>>>>@@ -92,7 +99,7 @@ static void aspeed_kcs_outb(struct kcs_bmc *kcs_bmc, u32 reg, u8 data)
>>>>
>>>> static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val)
>>>> {
>>>>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>>>>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>>>> 	int rc;
>>>>
>>>> 	rc = regmap_update_bits(priv->map, reg, mask, val);
>>>>@@ -114,7 +121,7 @@ static void aspeed_kcs_updateb(struct kcs_bmc *kcs_bmc, u32 reg, u8 mask, u8 val
>>>>  */
>>>> static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>>>> {
>>>>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>>>>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>>>>
>>>> 	switch (kcs_bmc->channel) {
>>>> 	case 1:
>>>>@@ -148,7 +155,7 @@ static void aspeed_kcs_set_address(struct kcs_bmc *kcs_bmc, u16 addr)
>>>>
>>>> static void aspeed_kcs_enable_channel(struct kcs_bmc *kcs_bmc, bool enable)
>>>> {
>>>>-	struct aspeed_kcs_bmc *priv = kcs_bmc_priv(kcs_bmc);
>>>>+	struct aspeed_kcs_bmc *priv = to_aspeed_kcs_bmc(kcs_bmc);
>>>>
>>>> 	switch (kcs_bmc->channel) {
>>>> 	case 1:
>>>>@@ -323,16 +330,16 @@ static int aspeed_kcs_of_v2_get_io_address(struct platform_device *pdev)
>>>> static int aspeed_kcs_probe(struct platform_device *pdev)
>>>> {
>>>> 	const struct aspeed_kcs_of_ops *ops;
>>>>-	struct device *dev = &pdev->dev;
>>>>+	struct aspeed_kcs_bmc *priv;
>>>> 	struct kcs_bmc *kcs_bmc;
>>>> 	struct device_node *np;
>>>> 	int rc, channel, addr;
>>>>
>>>>-	np = dev->of_node->parent;
>>>>+	np = pdev->dev.of_node->parent;
>>>> 	if (!of_device_is_compatible(np, "aspeed,ast2400-lpc-v2") &&
>>>> 	    !of_device_is_compatible(np, "aspeed,ast2500-lpc-v2") &&
>>>> 	    !of_device_is_compatible(np, "aspeed,ast2600-lpc-v2")) {
>>>>-		dev_err(dev, "unsupported LPC device binding\n");
>>>>+		dev_err(&pdev->dev, "unsupported LPC device binding\n");
>>>> 		return -ENODEV;
>>>> 	}
>>>> 	ops = of_device_get_match_data(&pdev->dev);
>>>>@@ -343,18 +350,27 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>>>> 	if (channel < 0)
>>>> 		return channel;
>>>>
>>>>-	kcs_bmc = kcs_bmc_alloc(&pdev->dev, sizeof(struct aspeed_kcs_bmc), channel);
>>>>-	if (!kcs_bmc)
>>>>+	addr = ops->get_io_address(pdev);
>>>>+	if (addr < 0)
>>>>+		return addr;
>>>>+
>>>>+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>>>+	if (!priv)
>>>> 		return -ENOMEM;
>>>>
>>>>+	kcs_bmc = &priv->kcs_bmc;
>>>>+	kcs_bmc->dev = &pdev->dev;
>>>>+	kcs_bmc->channel = channel;
>>>> 	kcs_bmc->ioreg = ast_kcs_bmc_ioregs[channel - 1];
>>>> 	kcs_bmc->io_inputb = aspeed_kcs_inb;
>>>> 	kcs_bmc->io_outputb = aspeed_kcs_outb;
>>>> 	kcs_bmc->io_updateb = aspeed_kcs_updateb;
>>>>
>>>>-	addr = ops->get_io_address(pdev);
>>>>-	if (addr < 0)
>>>>-		return addr;
>>>>+	priv->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>>>>+	if (IS_ERR(priv->map)) {
>>>>+		dev_err(&pdev->dev, "Couldn't get regmap\n");
>>>>+		return -ENODEV;
>>>>+	}
>>>
>>>The reanimated priv->map initialization I suspect wasn't meant to
>>>have been removed in the first place...
>>
>>Yeah, I'll have to go back and figure out what went wrong there!
>>
>>Thanks for catching that.
>>
>>>
>>>>
>>>> 	aspeed_kcs_set_address(kcs_bmc, addr);
>>>>
>>>>@@ -362,29 +378,25 @@ static int aspeed_kcs_probe(struct platform_device *pdev)
>>>> 	if (rc)
>>>> 		return rc;
>>>>
>>>>-	dev_set_drvdata(dev, kcs_bmc);
>>>>+	platform_set_drvdata(pdev, priv);
>>>>
>>>> 	aspeed_kcs_enable_channel(kcs_bmc, true);
>>>>
>>>>-	rc = misc_register(&kcs_bmc->miscdev);
>>>>-	if (rc) {
>>>>-		dev_err(dev, "Unable to register device\n");
>>>>+	rc = kcs_bmc_add_device(&priv->kcs_bmc);
>>>>+	if (rc < 0)
>>>> 		return rc;
>>>>-	}
>>>>
>>>>-	dev_dbg(&pdev->dev,
>>>>-		"Probed KCS device %d (IDR=0x%x, ODR=0x%x, STR=0x%x)\n",
>>>>-		kcs_bmc->channel, kcs_bmc->ioreg.idr, kcs_bmc->ioreg.odr,
>>>>-		kcs_bmc->ioreg.str);
>>>>+	dev_info(&pdev->dev, "Initialised channel %d at 0x%x\n", kcs_bmc->channel, addr);
>>>
>>>Is the dbg->info change here intentional?  (I have no particular
>>>objection if so, but it's often a change I make myself during
>>>testing/debugging and then forget to revert...)
>>
>>Yeah, it was possibly something I forgot to revert. If others have
>>issues with it staying at dev_info() I'll switch it back.
>>
>>>
>>>>
>>>> 	return 0;
>>>> }
>>>>
>>>> static int aspeed_kcs_remove(struct platform_device *pdev)
>>>> {
>>>>-	struct kcs_bmc *kcs_bmc = dev_get_drvdata(&pdev->dev);
>>>>+	struct aspeed_kcs_bmc *priv = platform_get_drvdata(pdev);
>>>>+	struct kcs_bmc *kcs_bmc = &priv->kcs_bmc;
>>>>
>>>>-	misc_deregister(&kcs_bmc->miscdev);
>>>>+	kcs_bmc_remove_device(kcs_bmc);
>>>
>>>Should we propagate the return value outward here?
>>
>>Probably!
>>
>>>
>>>>
>>>> 	return 0;
>>>> }
>>>>diff --git a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>>>>index 82c77994e481..0ca71c135a1a 100644
>>>>--- a/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>>>>+++ b/drivers/char/ipmi/kcs_bmc_cdev_ipmi.c
>>>>@@ -382,7 +382,7 @@ static int kcs_bmc_ipmi_release(struct inode *inode, struct file *filp)
>>>> 	return 0;
>>>> }
>>>>
>>>>-static const struct file_operations kcs_bmc_fops = {
>>>>+static const struct file_operations kcs_bmc_ipmi_fops = {
>>>> 	.owner          = THIS_MODULE,
>>>> 	.open           = kcs_bmc_ipmi_open,
>>>> 	.read           = kcs_bmc_ipmi_read,
>>>>@@ -392,36 +392,58 @@ static const struct file_operations kcs_bmc_fops = {
>>>> 	.unlocked_ioctl = kcs_bmc_ipmi_ioctl,
>>>> };
>>>>
>>>>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
>>>>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
>>>>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
>>>
>>>Errant declaration again?
>>
>>As previously explained.
>>
>
>This one seems like a slightly different category, because...
>
>>>
>>>>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
>
>...it's immediately followed by the definition of the very same function
>that it just declared, so I can't see how its presence or absence could
>make any functional difference to anything.  (So perhaps I should have
>said "redundant" instead of "errant...again".)
>
>It's fairly trivial of course given that it's gone by the end of the
>series, but as long as there's going to be another iteration anyway it
>seems like we might as well tidy it up?
>

Oh, and otherwise:

Reviewed-by: Zev Weiss <zweiss at equinix.com>


From arnd at kernel.org  Fri Apr  9 20:38:15 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 9 Apr 2021 21:38:15 +0200
Subject: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format
In-Reply-To: <e0d9af36-fc6c-4470-a87c-61b9161bdf8f@www.fastmail.com>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-2-sven@svenpeter.dev>
 <20210407104425.GB15173@willie-the-truck>
 <e0d9af36-fc6c-4470-a87c-61b9161bdf8f@www.fastmail.com>
Message-ID: <CAK8P3a11O7JVDv+4rfky13C1pZFD7eE_B_54zRN8UQVpBrQJcA@mail.gmail.com>

On Fri, Apr 9, 2021 at 6:56 PM Sven Peter <sven at svenpeter.dev> wrote:
> On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> > On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> >
> > > +   cfg->pgsize_bitmap &= SZ_16K;
> > > +   if (!cfg->pgsize_bitmap)
> > > +           return NULL;
> >
> > This is worrying (and again, I don't think this belongs here). How is this
> > thing supposed to work if the CPU is using 4k pages?
>
> This SoC is just full of fun surprises!
> I didn't even think about that case since I've always been using 16k pages so far.
>
> I've checked again and wasn't able to find any way to configure the pagesize
> of the IOMMU. There seem to be variants of this IP in older iPhones which
> support a 4k pagesize but to the best of my knowledge this is hard wired
> and not configurable in software.
>
> When booting with 4k pages I hit the BUG_ON in iova.c that ensures that the
> iommu pagesize has to be <= the cpu page size.
>
> I see two options here and I'm not sure I like either of them:
>
> 1) Just don't support 4k CPU pages together with IOMMU translations and only
>    allow full bypass mode there.
>    This would however mean that PCIe (i.e. ethernet, usb ports on the Mac
>    mini) and possibly Thunderbolt support would not be possible since these
>    devices don't seem to like iommu bypass mode at all.

It should be possible to do a fake bypass mode by just programming a
static page table for as much address space as you can, and then
use swiotlb to address any memory beyond that. This won't perform
well because it requires bounce buffers for any high memory, but it
can be a last resort if a dart instance cannot do normal bypass mode.

> 2) I've had a brief discussion on IRC with Arnd about this [1] and he pointed
>    out that the dma_map_sg API doesn't make any guarantees about the returned
>    iovas and that it might be possible to make this work at least for devices
>    that go through the normal DMA API.
>
>    I've then replaced the page size check with a WARN_ON in iova.c just to see
>    what happens. At least normal devices that go through the DMA API seem to
>    work with my configuration. iommu_dma_alloc took the iommu_dma_alloc_remap
>    path which was called with the cpu page size but then used
>    domain->pgsize_bitmap to increase that to 16k. So this kinda works out, but
>    there are other functions in dma-iommu.c that I believe rely on the fact that
>    the iommu can map single cpu pages. This feels very fragile right now and
>    would probably require some rather invasive changes.

The other second-to-last resort here would be to duplicate the code from
the dma-iommu code and implement the dma-mapping API directly on
top of the dart hardware instead of the iommu layer. This would probably
be much faster than the swiotlb on top of a bypass or a linear map,
but it's a really awful abstraction that would require adding special cases
into a lot of generic code.

>    Any driver that tries to use the iommu API directly could be trouble
>    as well if they make similar assumptions.

I think pretty much all drivers using the iommu API directly already
depends on having a matching page size.  I don't see any way to use
e.g. PCI device assignment using vfio, or a GPU driver with per-process
contexts when the iotlb page size is larger than the CPU's.

>    Is this something you would even want to support in the iommu subsytem
>    and is it even possible to do this in a sane way?

I don't know how hard it is to do adjust the dma-iommu implementation
to allow this, but as long as we can work out the DT binding to support
both normal dma-iommu mode with 16KB pages and some kind of
passthrough mode (emulated or not) with 4KB pages, it can be left
as a possible optimization for later.

        Arnd


From arnd at kernel.org  Fri Apr  9 20:49:18 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 21:49:18 +0200
Subject: [GIT PULL] Broadcom maintainers changes for 5.13
In-Reply-To: <20210409175018.3051283-1-f.fainelli@gmail.com>
References: <20210409175018.3051283-1-f.fainelli@gmail.com>
Message-ID: <161799773277.1861470.10984939931826324456.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 10:50:18 -0700, Florian Fainelli wrote:
> The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:
> 
>   Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.13/maintainers
> 
> [...]

Merged into arm/soc, thanks!

merge commit: d92e5e32fb4fce7ae939ad322aad77955dd5dcda

       Arnd


From arnd at kernel.org  Fri Apr  9 20:54:08 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 21:54:08 +0200
Subject: [GIT PULL] More Qualcomm driver updates for 5.13
In-Reply-To: <20210409162001.775851-1-bjorn.andersson@linaro.org>
References: <20210409162001.775851-1-bjorn.andersson@linaro.org>
Message-ID: <161799803678.1862045.4284365394007319918.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 11:20:01 -0500, Bjorn Andersson wrote:
> The following changes since commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8:
> 
>   bus: qcom: Put child node before return (2021-03-29 22:01:27 -0500)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-drivers-for-5.13-2
> 
> [...]

Merged into arm/drivers, thanks!

merge commit: 30be8446db39be8dc52fc8cd2cb601d3d6319e9d

       Arnd


From arnd at kernel.org  Fri Apr  9 20:54:53 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 21:54:53 +0200
Subject: [GIT PULL] Qualcomm dts updates for v5.13
In-Reply-To: <20210409162359.776076-1-bjorn.andersson@linaro.org>
References: <20210409162359.776076-1-bjorn.andersson@linaro.org>
Message-ID: <161799808686.1862218.8412636987649764617.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 11:23:59 -0500, Bjorn Andersson wrote:
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-dts-for-5.13
> 
> [...]

Merged into arm/dt, thanks!

merge commit: e8adf27e9766525ebedb8e6607c023997f93c353

       Arnd


From arnd at kernel.org  Fri Apr  9 20:54:52 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 21:54:52 +0200
Subject: [GIT PULL] More Qualcomm ARM64 DT updates for 5.13
In-Reply-To: <20210409163949.776530-1-bjorn.andersson@linaro.org>
References: <20210409163949.776530-1-bjorn.andersson@linaro.org>
Message-ID: <161799808694.1862218.16413759565351084850.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 9 Apr 2021 11:39:49 -0500, Bjorn Andersson wrote:
> The following changes since commit e9269650db2f5b4aeeafced1a42b2e51d10bcdf5:
> 
>   arm64: dts: qcom: qrb5165-rb5: switch into using GPIO for SPI0 CS (2021-03-18 09:35:42 -0500)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13-2
> 
> [...]

Merged into arm/dt, thanks!

merge commit: a8f6ba28257ab6fcf08138496afdcb2d6de3955c

       Arnd


From arnd at kernel.org  Fri Apr  9 20:54:54 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri,  9 Apr 2021 21:54:54 +0200
Subject: [GIT PULL] arm64: dts: amlogic: updates for v5.13 (round 2)
In-Reply-To: <7htuofgwaz.fsf@baylibre.com>
References: <7htuofgwaz.fsf@baylibre.com>
Message-ID: <161799808702.1862218.12904940080958587014.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Fri, 09 Apr 2021 11:14:12 -0700, Kevin Hilman wrote:
> Arnd, Olof,
> 
> A 2nd round of DT changes for Amlogic SoC families.
> 
> I'm now aware of the new DT warnings added in the first round and will
> work to get those cleaned up next.
> 
> Kevin
> 
> [...]

Merged into arm/dt, thanks!

merge commit: db7a033f2b1f54c46244efe54687fe8f4b9b7c21

       Arnd


From lkp at intel.com  Fri Apr  9 21:50:05 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 04:50:05 +0800
Subject: [soc:bmc/wpcm450] BUILD SUCCESS
 09e6d2b71ae673dccf9f59f0fc1e17109113b6f4
Message-ID: <6070bdfd.e0W+OYLX11MTPUMv%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git bmc/wpcm450
branch HEAD: 09e6d2b71ae673dccf9f59f0fc1e17109113b6f4  ARM: config: Add WPCM to multi v5

elapsed time: 818m

configs tested: 231
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          polaris_defconfig
arc                              allyesconfig
powerpc                     asp8347_defconfig
m68k                          multi_defconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
openrisc                  or1klitex_defconfig
xtensa                    xip_kc705_defconfig
arm                            hisi_defconfig
powerpc                      pmac32_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
ia64                             allyesconfig
mips                          ath79_defconfig
m68k                                defconfig
nios2                            alldefconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
mips                        nlm_xlr_defconfig
powerpc                 mpc8315_rdb_defconfig
sh                           se7722_defconfig
m68k                        m5307c3_defconfig
powerpc                       ppc64_defconfig
nios2                               defconfig
sh                      rts7751r2d1_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
mips                         tb0226_defconfig
powerpc                       eiger_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
parisc                           alldefconfig
m68k                         amcore_defconfig
mips                       bmips_be_defconfig
powerpc                 mpc834x_mds_defconfig
xtensa                  cadence_csp_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
um                             i386_defconfig
sh                          rsk7264_defconfig
ia64                        generic_defconfig
mips                        vocore2_defconfig
powerpc                           allnoconfig
powerpc                    sam440ep_defconfig
arm                          ixp4xx_defconfig
mips                         cobalt_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
sh                           se7206_defconfig
mips                      fuloong2e_defconfig
arm                           sama5_defconfig
mips                      maltasmvp_defconfig
sh                                  defconfig
powerpc                 mpc8313_rdb_defconfig
arm                            dove_defconfig
arm                  colibri_pxa270_defconfig
sh                           se7619_defconfig
powerpc                      chrp32_defconfig
arm                         socfpga_defconfig
arm                            pleb_defconfig
arm                            xcep_defconfig
arm                          ep93xx_defconfig
mips                            e55_defconfig
mips                        workpad_defconfig
um                                allnoconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
arm                       imx_v4_v5_defconfig
mips                           ip27_defconfig
mips                         mpc30x_defconfig
s390                                defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                  maltasmvp_eva_defconfig
arm                       versatile_defconfig
sh                          lboxre2_defconfig
arm                         cm_x300_defconfig
m68k                       m5475evb_defconfig
mips                         bigsur_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
powerpc                         ps3_defconfig
arm                         at91_dt_defconfig
powerpc                      obs600_defconfig
arm                        mini2440_defconfig
microblaze                      mmu_defconfig
arm                        shmobile_defconfig
arm                         s3c2410_defconfig
m68k                        stmark2_defconfig
m68k                        m5407c3_defconfig
sh                            titan_defconfig
arm                        oxnas_v6_defconfig
mips                     cu1830-neo_defconfig
arc                 nsimosci_hs_smp_defconfig
arc                        nsim_700_defconfig
arm                       netwinder_defconfig
mips                             allyesconfig
sh                           se7712_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                   bluestone_defconfig
arc                                 defconfig
mips                      loongson3_defconfig
arm                  colibri_pxa300_defconfig
powerpc                 mpc8540_ads_defconfig
microblaze                          defconfig
sh                        sh7785lcr_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arc                      axs103_smp_defconfig
powerpc                     taishan_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
ia64                             allmodconfig
arm                         shannon_defconfig
h8300                     edosk2674_defconfig
powerpc                      pasemi_defconfig
powerpc                     ksi8560_defconfig
mips                       rbtx49xx_defconfig
xtensa                  audio_kc705_defconfig
arm                          badge4_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
s390                          debug_defconfig
nds32                             allnoconfig
powerpc                     sequoia_defconfig
sh                          r7785rp_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
mips                     loongson1b_defconfig
arm                         mv78xx0_defconfig
arm                       multi_v4t_defconfig
powerpc64                           defconfig
sh                          sdk7780_defconfig
sh                   secureedge5410_defconfig
arc                        nsimosci_defconfig
sh                               alldefconfig
arm                          collie_defconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
i386                 randconfig-a012-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr  9 21:50:07 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 04:50:07 +0800
Subject: [soc:arm/newsoc] BUILD SUCCESS
 39b95079f68cf17888a4cee93ad3c4acc3854b38
Message-ID: <6070bdff.vGrjmQZwfHius6+v%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/newsoc
branch HEAD: 39b95079f68cf17888a4cee93ad3c4acc3854b38  Merge tag 'bmc-5.13-wpcm450' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/newsoc

elapsed time: 723m

configs tested: 208
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
sh                          polaris_defconfig
arc                              allyesconfig
powerpc                     asp8347_defconfig
m68k                          multi_defconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
openrisc                  or1klitex_defconfig
xtensa                    xip_kc705_defconfig
arm                            hisi_defconfig
powerpc                      pmac32_defconfig
arm                          lpd270_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
nios2                            alldefconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
mips                        nlm_xlr_defconfig
powerpc                 mpc8315_rdb_defconfig
sh                           se7722_defconfig
m68k                        m5307c3_defconfig
powerpc                       ppc64_defconfig
nios2                               defconfig
sh                      rts7751r2d1_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
powerpc                       eiger_defconfig
mips                         tb0226_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
parisc                           alldefconfig
m68k                         amcore_defconfig
mips                       bmips_be_defconfig
powerpc                 mpc834x_mds_defconfig
xtensa                  cadence_csp_defconfig
powerpc                    sam440ep_defconfig
arm                          ixp4xx_defconfig
mips                         cobalt_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
sh                           se7206_defconfig
mips                      fuloong2e_defconfig
arm                           sama5_defconfig
mips                      maltasmvp_defconfig
sh                                  defconfig
powerpc                 mpc8313_rdb_defconfig
arm                            dove_defconfig
arm                  colibri_pxa270_defconfig
sh                           se7619_defconfig
powerpc                      chrp32_defconfig
arm                         socfpga_defconfig
arm                            pleb_defconfig
arm                            xcep_defconfig
arm                          ep93xx_defconfig
mips                            e55_defconfig
mips                        workpad_defconfig
um                                allnoconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
arm                       imx_v4_v5_defconfig
mips                           ip27_defconfig
mips                         mpc30x_defconfig
s390                                defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
arm                         cm_x300_defconfig
m68k                       m5475evb_defconfig
mips                         bigsur_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                        shmobile_defconfig
arm                         s3c2410_defconfig
m68k                        stmark2_defconfig
mips                     cu1830-neo_defconfig
arc                 nsimosci_hs_smp_defconfig
arc                        nsim_700_defconfig
arm                       netwinder_defconfig
mips                             allyesconfig
sh                           se7712_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                   bluestone_defconfig
arc                                 defconfig
mips                      loongson3_defconfig
arm                  colibri_pxa300_defconfig
powerpc                 mpc8540_ads_defconfig
ia64                             allyesconfig
microblaze                          defconfig
sh                        sh7785lcr_defconfig
mips                         tb0219_defconfig
arm                         at91_dt_defconfig
sh                          urquell_defconfig
arc                      axs103_smp_defconfig
powerpc                     taishan_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
ia64                             allmodconfig
arm                         shannon_defconfig
h8300                     edosk2674_defconfig
powerpc                      pasemi_defconfig
powerpc                     ksi8560_defconfig
xtensa                  audio_kc705_defconfig
arm                          badge4_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
sh                          lboxre2_defconfig
s390                          debug_defconfig
nds32                             allnoconfig
powerpc                     sequoia_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
mips                     loongson1b_defconfig
arm                         mv78xx0_defconfig
arm                       multi_v4t_defconfig
powerpc64                           defconfig
sh                          sdk7780_defconfig
sh                   secureedge5410_defconfig
arm                       versatile_defconfig
arc                        nsimosci_defconfig
sh                               alldefconfig
arm                          collie_defconfig
powerpc                 mpc837x_rdb_defconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
i386                 randconfig-a012-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From leoyang.li at nxp.com  Fri Apr  9 21:57:19 2021
From: leoyang.li at nxp.com (Li Yang)
Date: Fri,  9 Apr 2021 15:57:19 -0500
Subject: [GIT PULL] soc/fsl drivers changes for next(v5.13)
Message-ID: <20210409205719.27927-1-leoyang.li@nxp.com>

Hi soc maintainers,

Please merge the following new changes for soc/fsl drivers.

Regards,
Leo

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-next-v5.13

for you to fetch changes up to 242b0b398ccd34f73772120bd27a87a1bf00e30b:

  soc: fsl: enable acpi support in RCPM driver (2021-04-08 16:34:15 -0500)

----------------------------------------------------------------
NXP/FSL SoC driver updates for v5.13

- Add ACPI support for RCPM driver
- Use generic io{read,write} for QE drivers after performance optimized
  for PowerPC
- Fix QBMAN probe to cleanup HW states correctly for kexec
- Various cleanup and style fix for QBMAN/QE/GUTS drivers

----------------------------------------------------------------
Aditya Srivastava (1):
      soc: fsl: guts: fix comment syntax in file

Christophe Leroy (3):
      soc: fsl: qe: replace qe_io{read,write}* wrappers by generic io{read,write}*
      tty: serial: ucc_uart: replace qe_io{read,write}* wrappers by generic io{read,write}*
      Revert "soc: fsl: qe: introduce qe_io{read,write}* wrappers"

Peng Ma (1):
      soc: fsl: enable acpi support in RCPM driver

Roy Pledge (1):
      soc: fsl: qbman: Ensure device cleanup is run for kexec

Yang Li (1):
      soc: fsl: guts: remove unneeded semicolon

Zheng Yongjun (2):
      soc: fsl: qbman: Delete useless kfree code
      soc: fsl: qe: Use DEFINE_SPINLOCK() for spinlock

 drivers/soc/fsl/guts.c              |   2 +-
 drivers/soc/fsl/qbman/bman.c        |   1 -
 drivers/soc/fsl/qbman/bman_portal.c |   3 +-
 drivers/soc/fsl/qbman/qman_portal.c |   3 +-
 drivers/soc/fsl/qe/gpio.c           |  20 +++---
 drivers/soc/fsl/qe/qe.c             |  24 +++----
 drivers/soc/fsl/qe/qe_common.c      |   3 +-
 drivers/soc/fsl/qe/qe_ic.c          |   4 +-
 drivers/soc/fsl/qe/qe_io.c          |  36 +++++------
 drivers/soc/fsl/qe/ucc_fast.c       |  68 ++++++++++----------
 drivers/soc/fsl/qe/ucc_slow.c       |  42 ++++++------
 drivers/soc/fsl/rcpm.c              |  24 ++++++-
 drivers/tty/serial/ucc_uart.c       | 124 ++++++++++++++++++------------------
 include/linux/fsl/guts.h            |   4 +-
 include/soc/fsl/qe/qe.h             |  34 +++-------
 15 files changed, 198 insertions(+), 194 deletions(-)


From mdf at kernel.org  Fri Apr  9 22:30:45 2021
From: mdf at kernel.org (Moritz Fischer)
Date: Fri, 9 Apr 2021 14:30:45 -0700
Subject: [PATCH 3/3] fpga: region: Adds runtime PM support
In-Reply-To: <20210402092049.479-4-nava.manne@xilinx.com>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-4-nava.manne@xilinx.com>
Message-ID: <YHDHhf1tQo6vI49W@epycbox.lan>

On Fri, Apr 02, 2021 at 02:50:49PM +0530, Nava kishore Manne wrote:
> Adds support to handle FPGA/PL power domain. With this patch,
> the PL power domain will be turned on before loading the bitstream
> and turned off while removing/unloading the bitstream using overlays.
> This can be achieved by adding the runtime PM support.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  drivers/fpga/of-fpga-region.c | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
> index e405309baadc..35fc2f3d4bd8 100644
> --- a/drivers/fpga/of-fpga-region.c
> +++ b/drivers/fpga/of-fpga-region.c
> @@ -15,6 +15,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/pm_runtime.h>
>  
>  static const struct of_device_id fpga_region_of_match[] = {
>  	{ .compatible = "fpga-region", },
> @@ -302,6 +303,7 @@ static int of_fpga_region_notify_pre_apply(struct fpga_region *region,
>  	}
>  
>  	region->info = info;
> +	pm_runtime_get_sync(dev->parent);
>  	ret = fpga_region_program_fpga(region);
>  	if (ret) {
>  		/* error; reject overlay */
> @@ -324,10 +326,13 @@ static int of_fpga_region_notify_pre_apply(struct fpga_region *region,
>  static void of_fpga_region_notify_post_remove(struct fpga_region *region,
>  					      struct of_overlay_notify_data *nd)
>  {
> +	struct device *dev = &region->dev;
> +
>  	fpga_bridges_disable(&region->bridge_list);
>  	fpga_bridges_put(&region->bridge_list);
>  	fpga_image_info_free(region->info);
>  	region->info = NULL;
> +	pm_runtime_put(dev->parent);
>  }
>  
>  /**
> @@ -411,9 +416,16 @@ static int of_fpga_region_probe(struct platform_device *pdev)
>  		goto eprobe_mgr_put;
>  	}
>  
> +	pm_runtime_enable(&pdev->dev);
> +	ret = pm_runtime_get_sync(&pdev->dev);
> +	if (ret < 0)
> +		goto err_pm;
> +
> +	pm_runtime_put(&pdev->dev);
> +
>  	ret = fpga_region_register(region);
>  	if (ret)
> -		goto eprobe_mgr_put;
> +		goto err_pm;
>  
>  	of_platform_populate(np, fpga_region_of_match, NULL, &region->dev);
>  	platform_set_drvdata(pdev, region);
> @@ -422,6 +434,9 @@ static int of_fpga_region_probe(struct platform_device *pdev)
>  
>  	return 0;
>  
> +err_pm:
> +	pm_runtime_put(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
>  eprobe_mgr_put:
>  	fpga_mgr_put(mgr);
>  	return ret;
> @@ -434,6 +449,7 @@ static int of_fpga_region_remove(struct platform_device *pdev)
>  
>  	fpga_region_unregister(region);
>  	fpga_mgr_put(mgr);
> +	pm_runtime_disable(region->dev.parent);
>  
>  	return 0;
>  }
> -- 
> 2.18.0
> 

Does this add a dependency on CONFIG_PM?

Thanks,
Moritz


From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr  9 22:34:55 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sat, 10 Apr 2021 06:34:55 +0900
Subject: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <YHBUjPjEpLYF/915@orome.fritz.box>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <YHBUjPjEpLYF/915@orome.fritz.box>
Message-ID: <20210409213455.6f25m4jyttqn75hf@toshiba.co.jp>

Hi Thierry,

Thanks for your review.

On Fri, Apr 09, 2021 at 03:20:12PM +0200, Thierry Reding wrote:
> On Fri, Apr 09, 2021 at 06:07:09PM +0900, Nobuhiro Iwamatsu wrote:
> > Add driver for the PWM controller on Toshiba Visconti ARM SoC.
> > 
> > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > ---
> >  drivers/pwm/Kconfig        |   9 ++
> >  drivers/pwm/Makefile       |   1 +
> >  drivers/pwm/pwm-visconti.c | 193 +++++++++++++++++++++++++++++++++++++
> >  3 files changed, 203 insertions(+)
> >  create mode 100644 drivers/pwm/pwm-visconti.c
> 
> Looks good, but I have a few minor comments, see below.
> 
> > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > index 9a4f66ae8070..8ae68d6203fb 100644
> > --- a/drivers/pwm/Kconfig
> > +++ b/drivers/pwm/Kconfig
> > @@ -601,6 +601,15 @@ config PWM_TWL_LED
> >  	  To compile this driver as a module, choose M here: the module
> >  	  will be called pwm-twl-led.
> >  
> > +config PWM_VISCONTI
> > +	tristate "Toshiba Visconti PWM support"
> > +	depends on ARCH_VISCONTI || COMPILE_TEST
> > +	help
> > +	  PWM Subsystem driver support for Toshiba Visconti SoCs.
> > +
> > +	  To compile this driver as a module, choose M here: the module
> > +	  will be called pwm-visconti.
> > +
> >  config PWM_VT8500
> >  	tristate "vt8500 PWM support"
> >  	depends on ARCH_VT8500 || COMPILE_TEST
> > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> > index 6374d3b1d6f3..d43b1e17e8e1 100644
> > --- a/drivers/pwm/Makefile
> > +++ b/drivers/pwm/Makefile
> > @@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
> >  obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
> >  obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
> >  obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
> > +obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
> >  obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
> > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > new file mode 100644
> > index 000000000000..ff4a5f5b0009
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-visconti.c
> > @@ -0,0 +1,193 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Toshiba Visconti pulse-width-modulation controller driver
> > + *
> > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > + *
> > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > + *
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/pwm.h>
> > +#include <linux/platform_device.h>
> 
> Should be sorted alphabetically.
> 

I forgot it, I will fix.

> > +
> > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > +
> > +#define PIPGM_PWMC_PWMACT		BIT(5)
> > +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> > +#define PIPGM_PWMC_POLARITY_MASK	GENMASK(5, 5)
> > +
> > +struct visconti_pwm_chip {
> > +	struct pwm_chip chip;
> > +	void __iomem *base;
> > +};
> > +
> > +#define to_visconti_chip(chip) \
> > +	container_of(chip, struct visconti_pwm_chip, chip)
> 
> I prefer these to be static inline functions because that tends to give
> better error messages than macros. Also, that's what's primarily used in
> the PWM drivers, even if there are a couple of outliers.
> 
> I'll go fix those up.

I see. I will change to use static inline functions..

> 
> > +
> > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > +			      const struct pwm_state *state)
> > +{
> > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > +	u32 period, duty_cycle, pwmc0;
> > +
> > +	dev_dbg(chip->dev, "%s: ch = %d en = %d p = 0x%llx d = 0x%llx\n", __func__,
> > +		pwm->hwpwm, state->enabled, state->period, state->duty_cycle);
> 
> Don't the trace points work for you?

Yes, we can get this information by using the trace function. I will
drop this.

> 
> > +
> > +	/*
> > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > +	 * way the hardware switches atomically from the old setting to the new.
> > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > +	 * at low level at all times.
> > +	 */
> > +	if (!state->enabled) {
> > +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +		return 0;
> > +	}
> > +
> > +	/*
> > +	 * The biggest period the hardware can provide is
> > +	 *	(0xffff << 3) * 1000 ns
> > +	 * This value fits easily in an u32, so simplify the maths by
> > +	 * capping the values to 32 bit integers.
> > +	 */
> > +	if (state->period > (0xffff << 3) * 1000)
> > +		period = (0xffff << 3) * 1000;
> > +	else
> > +		period = state->period;
> > +
> > +	if (state->duty_cycle > period)
> > +		duty_cycle = period;
> > +	else
> > +		duty_cycle = state->duty_cycle;
> > +
> > +	/*
> > +	 * The input clock runs fixed at 1 MHz, so we have only
> > +	 * microsecond resolution and so can divide by
> > +	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
> > +	 */
> > +	period /= 1000;
> > +	duty_cycle /= 1000;
> > +
> > +	if (!period)
> > +		/* period too small */
> > +		return -ERANGE;
> 
> Maybe braces around this so the two-line "block" doesn't look wrong,
> even if it actually isn't. Or perhaps put the comment above the check
> for the same effect.

I see, it's readability.

> 
> Quite frankly, I'd just drop the comment because the code itself is
> clear and the comment doesn't add anything.

OK, I will drop this comment.

> 
> > +
> > +	/*
> > +	 * PWMC controls a divider that divides the input clk by a
> > +	 * power of two between 1 and 8. As a smaller divider yields
> > +	 * higher precision, pick the smallest possible one.
> > +	 */
> > +	if (period > 0xffff) {
> > +		pwmc0 = ilog2(period >> 16);
> > +		BUG_ON(pwmc0 > 3);
> > +	} else
> > +		pwmc0 = 0;
> > +
> > +	period >>= pwmc0;
> > +	duty_cycle >>= pwmc0;
> > +
> > +	if (state->polarity == PWM_POLARITY_INVERSED)
> > +		pwmc0 |= PIPGM_PWMC_PWMACT;
> > +	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> > +	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> > +	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +
> > +	return 0;
> > +}
> > +
> > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > +				   struct pwm_state *state)
> > +{
> > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > +	u32 period, duty, pwmc0, pwmc0_clk;
> > +
> > +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +	if (period)
> > +		state->enabled = true;
> > +	else
> > +		state->enabled = false;
> > +
> > +	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
> > +	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
> > +	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
> > +
> > +	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
> > +	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
> > +	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
> > +		state->polarity = PWM_POLARITY_INVERSED;
> > +	else
> > +		state->polarity = PWM_POLARITY_NORMAL;
> > +}
> > +
> > +static const struct pwm_ops visconti_pwm_ops = {
> > +	.apply = visconti_pwm_apply,
> > +	.get_state = visconti_pwm_get_state,
> > +	.owner = THIS_MODULE,
> > +};
> > +
> > +static int visconti_pwm_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct visconti_pwm_chip *priv;
> > +	int ret;
> > +
> > +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return -ENOMEM;
> > +
> > +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> > +	if (IS_ERR(priv->base))
> > +		return PTR_ERR(priv->base);
> > +
> > +	platform_set_drvdata(pdev, priv);
> > +
> > +	priv->chip.dev = dev;
> > +	priv->chip.ops = &visconti_pwm_ops;
> > +	priv->chip.base = -1;
> 
> There's no need for this anymore. The current PWM tree will always
> assume base = -1.

I see. I will drop this.

> 
> > +	priv->chip.npwm = 4;
> > +
> > +	ret = pwmchip_add(&priv->chip);
> > +	if (ret < 0)
> > +		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
> > +
> > +	dev_dbg(&pdev->dev, "visconti PWM registered\n");
> 
> Maybe not the best use of a debug message. There are better ways to
> check if a device has successfully bound to a driver than relying on
> debug messages.

I will drop this line. it says there are better way to check, but what is it?

> 
> > +
> > +	return 0;
> > +}
> > +
> > +static int visconti_pwm_remove(struct platform_device *pdev)
> > +{
> > +	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
> > +
> > +	return pwmchip_remove(&priv->chip);
> 
> I think Uwe would prefer this to be done separately because he's working
> towards removing the return value from pwmchip_remove() and if we start
> ignoring it in new drivers that will make life easier going forward.
> 
> So this should just be:
> 
> 	pwmchip_remove(&priv->chip);
> 
> 	return 0;

I understand your suggestion.
However, it looks like the pwmchip_remove() hasn't been updated yet.
I will wait for the update of pwmchip_remove.

> 
> Thierry

Best regards,
  Nobuhiro


From jpoimboe at redhat.com  Fri Apr  9 22:37:41 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Fri, 9 Apr 2021 16:37:41 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409120859.GA51636@C02TD0UTHF1T.local>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
Message-ID: <20210409213741.kqmwyajoppuqrkge@treble>

On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:
> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madvenka at linux.microsoft.com wrote:
> > From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> > 
> > There are a number of places in kernel code where the stack trace is not
> > reliable. Enhance the unwinder to check for those cases and mark the
> > stack trace as unreliable. Once all of the checks are in place, the unwinder
> > can provide a reliable stack trace. But before this can be used for livepatch,
> > some other entity needs to guarantee that the frame pointers are all set up
> > correctly in kernel functions. objtool is currently being worked on to
> > fill that gap.
> > 
> > Except for the return address check, all the other checks involve checking
> > the return PC of every frame against certain kernel functions. To do this,
> > implement some infrastructure code:
> > 
> > 	- Define a special_functions[] array and populate the array with
> > 	  the special functions
> 
> I'm not too keen on having to manually collate this within the unwinder,
> as it's very painful from a maintenance perspective.

Agreed.

> I'd much rather we could associate this information with the
> implementations of these functions, so that they're more likely to
> stay in sync.
> 
> Further, I believe all the special cases are assembly functions, and
> most of those are already in special sections to begin with. I reckon
> it'd be simpler and more robust to reject unwinding based on the
> section. If we need to unwind across specific functions in those
> sections, we could opt-in with some metadata. So e.g. we could reject
> all functions in ".entry.text", special casing the EL0 entry functions
> if necessary.

Couldn't this also end up being somewhat fragile?  Saying "certain
sections are deemed unreliable" isn't necessarily obvious to somebody
who doesn't already know about it, and it could be overlooked or
forgotten over time.  And there's no way to enforce it stays that way.

FWIW, over the years we've had zero issues with encoding the frame
pointer on x86.  After you save pt_regs, you encode the frame pointer to
point to it.  Ideally in the same macro so it's hard to overlook.

If you're concerned about debuggers getting confused by the encoding -
which debuggers specifically?  In my experience, if vmlinux has
debuginfo, gdb and most other debuggers will use DWARF (which is already
broken in asm code) and completely ignore frame pointers.

> I think there's a lot more code that we cannot unwind, e.g. KVM
> exception code, or almost anything marked with SYM_CODE_END().

Just a reminder that livepatch only unwinds blocked tasks (plus the
'current' task which calls into livepatch).  So practically speaking, it
doesn't matter whether the 'unreliable' detection has full coverage.
The only exceptions which really matter are those which end up calling
schedule(), e.g. preemption or page faults.

Being able to consistently detect *all* possible unreliable paths would
be nice in theory, but it's unnecessary and may not be worth the extra
complexity.

-- 
Josh



From u.kleine-koenig at pengutronix.de  Fri Apr  9 22:52:07 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 9 Apr 2021 23:52:07 +0200
Subject: [v3,PATCH 3/3] pwm: mtk_disp: implement .get_state()
In-Reply-To: <YHBHizYI7oyULZx9@orome.fritz.box>
References: <1617703062-4251-1-git-send-email-rex-bc.chen@mediatek.com>
 <1617703062-4251-4-git-send-email-rex-bc.chen@mediatek.com>
 <20210406102756.4kncasxe4um3q6wi@pengutronix.de>
 <YHBHizYI7oyULZx9@orome.fritz.box>
Message-ID: <20210409215207.uuyc42mddq4jify5@pengutronix.de>

On Fri, Apr 09, 2021 at 02:24:43PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 12:27:56PM +0200, Uwe Kleine-K?nig wrote:
> > On Tue, Apr 06, 2021 at 05:57:42PM +0800, Rex-BC Chen wrote:
> > > implement get_state function for pwm-mtk-disp
> > > 
> > > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > 
> > Ideally you S-o-b line is the last one to show the order in which this
> > patch went from one person to another.
> > 
> > > ---
> > >  drivers/pwm/pwm-mtk-disp.c | 46 ++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 46 insertions(+)
> > > 
> > > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
> > > index 502228adf718..166e0a8ca703 100644
> > > --- a/drivers/pwm/pwm-mtk-disp.c
> > > +++ b/drivers/pwm/pwm-mtk-disp.c
> > > @@ -179,8 +179,54 @@ static int mtk_disp_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > >  	return mtk_disp_pwm_enable(chip, state);
> > >  }
> > >  
> > > +static void mtk_disp_pwm_get_state(struct pwm_chip *chip,
> > > +				   struct pwm_device *pwm,
> > > +				   struct pwm_state *state)
> > > +{
> > > +	struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
> > > +	u32 clk_div, period, high_width, con0, con1;
> > > +	u64 rate;
> > > +	int err;
> > > +
> > > +	err = clk_prepare_enable(mdp->clk_main);
> > > +	if (err < 0) {
> > > +		dev_err(chip->dev, "Can't enable mdp->clk_main: %d\n", err);
> > > +		return;
> > > +	}
> > > +	err = clk_prepare_enable(mdp->clk_mm);
> > > +	if (err < 0) {
> > > +		dev_err(chip->dev, "Can't enable mdp->clk_mm: %d\n", err);
> > > +		clk_disable_unprepare(mdp->clk_main);
> > 
> > As before: %pe please
> 
> According to the documentation %pe only works on pointers for which
> IS_ERR() is true, so I'm not sure it can be used with plain integer
> error codes.

It cannot.

> Looks like there's a bunch of drivers that will do %pe and then use
> ERR_PTR(err) to make this work, but to be honest, that seems like
> jumping through hoops.

When I suggested to implement %dE to print error codes this was shot
down by the printk guys who's position is that %pe has to be good enough
for everybody. And yes, you'd need to pass ERR_PTR(err) then.

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/20210409/1ceaa1e9/attachment.sig>

From leoyang.li at nxp.com  Fri Apr  9 22:56:16 2021
From: leoyang.li at nxp.com (Leo Li)
Date: Fri, 9 Apr 2021 21:56:16 +0000
Subject: [PATCH -next] soc: fsl: qe: use DEFINE_SPINLOCK() for spinlock
In-Reply-To: <20210409095152.2294487-1-yebin10@huawei.com>
References: <20210409095152.2294487-1-yebin10@huawei.com>
Message-ID: <AM6PR04MB4471507F0A759451E68FA8638F739@AM6PR04MB4471.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Ye Bin <yebin10 at huawei.com>
> Sent: Friday, April 9, 2021 4:52 AM
> To: yebin10 at huawei.com; Qiang Zhao <qiang.zhao at nxp.com>; Leo Li
> <leoyang.li at nxp.com>
> Cc: linuxppc-dev at lists.ozlabs.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; kernel-janitors at vger.kernel.org; Hulk Robot
> <hulkci at huawei.com>
> Subject: [PATCH -next] soc: fsl: qe: use DEFINE_SPINLOCK() for spinlock
> 
> spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than
> explicitly calling spin_lock_init().

The previous version has been applied.  Thanks.

> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Ye Bin <yebin10 at huawei.com>
> ---
>  drivers/soc/fsl/qe/qe_common.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/fsl/qe/qe_common.c
> b/drivers/soc/fsl/qe/qe_common.c index 654e9246ce6b..a0cb8e746879
> 100644
> --- a/drivers/soc/fsl/qe/qe_common.c
> +++ b/drivers/soc/fsl/qe/qe_common.c
> @@ -26,7 +26,7 @@
>  #include <soc/fsl/qe/qe.h>
> 
>  static struct gen_pool *muram_pool;
> -static spinlock_t cpm_muram_lock;
> +static DEFINE_SPINLOCK(cpm_muram_lock);
>  static void __iomem *muram_vbase;
>  static phys_addr_t muram_pbase;
> 
> @@ -54,7 +54,6 @@ int cpm_muram_init(void)
>  	if (muram_pbase)
>  		return 0;
> 
> -	spin_lock_init(&cpm_muram_lock);
>  	np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
>  	if (!np) {
>  		/* try legacy bindings */



From madvenka at linux.microsoft.com  Fri Apr  9 23:05:58 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 9 Apr 2021 17:05:58 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409213741.kqmwyajoppuqrkge@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
Message-ID: <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>



On 4/9/21 4:37 PM, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:
>> On Mon, Apr 05, 2021 at 03:43:09PM -0500, madvenka at linux.microsoft.com wrote:
>>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>>
>>> There are a number of places in kernel code where the stack trace is not
>>> reliable. Enhance the unwinder to check for those cases and mark the
>>> stack trace as unreliable. Once all of the checks are in place, the unwinder
>>> can provide a reliable stack trace. But before this can be used for livepatch,
>>> some other entity needs to guarantee that the frame pointers are all set up
>>> correctly in kernel functions. objtool is currently being worked on to
>>> fill that gap.
>>>
>>> Except for the return address check, all the other checks involve checking
>>> the return PC of every frame against certain kernel functions. To do this,
>>> implement some infrastructure code:
>>>
>>> 	- Define a special_functions[] array and populate the array with
>>> 	  the special functions
>>
>> I'm not too keen on having to manually collate this within the unwinder,
>> as it's very painful from a maintenance perspective.
> 
> Agreed.
> 
>> I'd much rather we could associate this information with the
>> implementations of these functions, so that they're more likely to
>> stay in sync.
>>
>> Further, I believe all the special cases are assembly functions, and
>> most of those are already in special sections to begin with. I reckon
>> it'd be simpler and more robust to reject unwinding based on the
>> section. If we need to unwind across specific functions in those
>> sections, we could opt-in with some metadata. So e.g. we could reject
>> all functions in ".entry.text", special casing the EL0 entry functions
>> if necessary.
> 
> Couldn't this also end up being somewhat fragile?  Saying "certain
> sections are deemed unreliable" isn't necessarily obvious to somebody
> who doesn't already know about it, and it could be overlooked or
> forgotten over time.  And there's no way to enforce it stays that way.
> 

Good point!

> FWIW, over the years we've had zero issues with encoding the frame
> pointer on x86.  After you save pt_regs, you encode the frame pointer to
> point to it.  Ideally in the same macro so it's hard to overlook.
> 

I had the same opinion. In fact, in my encoding scheme, I have additional
checks to make absolutely sure that it is a true encoding and not stack
corruption. The chances of all of those values accidentally matching are,
well, null.

> If you're concerned about debuggers getting confused by the encoding -
> which debuggers specifically?  In my experience, if vmlinux has
> debuginfo, gdb and most other debuggers will use DWARF (which is already
> broken in asm code) and completely ignore frame pointers.
> 

Yes. I checked gdb actually. It did not show a problem.

>> I think there's a lot more code that we cannot unwind, e.g. KVM
>> exception code, or almost anything marked with SYM_CODE_END().
> 
> Just a reminder that livepatch only unwinds blocked tasks (plus the
> 'current' task which calls into livepatch).  So practically speaking, it
> doesn't matter whether the 'unreliable' detection has full coverage.
> The only exceptions which really matter are those which end up calling
> schedule(), e.g. preemption or page faults.
> 
> Being able to consistently detect *all* possible unreliable paths would
> be nice in theory, but it's unnecessary and may not be worth the extra
> complexity.
> 

You do have a point. I tried to think of arch_stack_walk_reliable() as
something that should be implemented independent of livepatching. But
I could not really come up with a single example of where else it would
really be useful.

So, if we assume that the reliable stack trace is solely for the purpose
of livepatching, I agree with your earlier comments as well.

Thanks!

Madhavan


From nathan at kernel.org  Fri Apr  9 23:11:55 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri,  9 Apr 2021 15:11:55 -0700
Subject: [PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
Message-ID: <20210409221155.1113205-1-nathan@kernel.org>

Debian's clang carries a patch that makes the default FPU mode
'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
instructions on hardware that does not support them:

https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
https://bugs.debian.org/841474
https://bugs.debian.org/842142
https://bugs.debian.org/914268

This results in the following build error when clang's integrated
assembler is used because the '.arch' directive overrides the '.fpu'
directive:

arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
 vmov.i32 q0, #1
 ^
arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
 vshr.u64 q1, q0, #7
 ^
arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
 vshr.u64 q0, q0, #8
 ^
arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
 vmov.i32 d4, #19
 ^

Shuffle the order of the '.arch' and '.fpu' directives so that the code
builds regardless of the default FPU mode. This has been tested against
both clang with and without Debian's patch and GCC.

Cc: stable at vger.kernel.org
Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118
Reported-by: Arnd Bergmann <arnd at arndb.de>
Suggested-by: Arnd Bergmann <arnd at arndb.de>
Suggested-by: Jessica Clarke <jrtc27 at jrtc27.com>
Signed-off-by: Nathan Chancellor <nathan at kernel.org>
---
 arch/arm/crypto/curve25519-core.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/crypto/curve25519-core.S b/arch/arm/crypto/curve25519-core.S
index be18af52e7dc..b697fa5d059a 100644
--- a/arch/arm/crypto/curve25519-core.S
+++ b/arch/arm/crypto/curve25519-core.S
@@ -10,8 +10,8 @@
 #include <linux/linkage.h>
 
 .text
-.fpu neon
 .arch armv7-a
+.fpu neon
 .align 4
 
 ENTRY(curve25519_neon)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.31.1.189.g2e36527f23



From Jason at zx2c4.com  Fri Apr  9 23:14:44 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 9 Apr 2021 16:14:44 -0600
Subject: [PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
In-Reply-To: <20210409221155.1113205-1-nathan@kernel.org>
References: <20210409221155.1113205-1-nathan@kernel.org>
Message-ID: <CAHmME9raNqAftSHuJZ1VE0Xp=yGfuVN+i1j2tCAEDSynsgqy7w@mail.gmail.com>

Seems reasonable to me.

Acked-by: Jason A. Donenfeld <Jason at zx2c4.com>


From jpoimboe at redhat.com  Fri Apr  9 23:32:27 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Fri, 9 Apr 2021 17:32:27 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
Message-ID: <20210409223227.rvf6tfhvgnpzmabn@treble>

On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote:
> > FWIW, over the years we've had zero issues with encoding the frame
> > pointer on x86.  After you save pt_regs, you encode the frame pointer to
> > point to it.  Ideally in the same macro so it's hard to overlook.
> > 
> 
> I had the same opinion. In fact, in my encoding scheme, I have additional
> checks to make absolutely sure that it is a true encoding and not stack
> corruption. The chances of all of those values accidentally matching are,
> well, null.

Right, stack corruption -- which is already exceedingly rare -- would
have to be combined with a miracle or two in order to come out of the
whole thing marked as 'reliable' :-)

And really, we already take a similar risk today by "trusting" the frame
pointer value on the stack to a certain extent.

> >> I think there's a lot more code that we cannot unwind, e.g. KVM
> >> exception code, or almost anything marked with SYM_CODE_END().
> > 
> > Just a reminder that livepatch only unwinds blocked tasks (plus the
> > 'current' task which calls into livepatch).  So practically speaking, it
> > doesn't matter whether the 'unreliable' detection has full coverage.
> > The only exceptions which really matter are those which end up calling
> > schedule(), e.g. preemption or page faults.
> > 
> > Being able to consistently detect *all* possible unreliable paths would
> > be nice in theory, but it's unnecessary and may not be worth the extra
> > complexity.
> > 
> 
> You do have a point. I tried to think of arch_stack_walk_reliable() as
> something that should be implemented independent of livepatching. But
> I could not really come up with a single example of where else it would
> really be useful.
> 
> So, if we assume that the reliable stack trace is solely for the purpose
> of livepatching, I agree with your earlier comments as well.

One thought: if folks really view this as a problem, it might help to
just rename things to reduce confusion.

For example, instead of calling it 'reliable', we could call it
something more precise, like 'klp_reliable', to indicate that its
reliable enough for live patching.

Then have a comment above 'klp_reliable' and/or
stack_trace_save_tsk_klp_reliable() which describes what that means.

Hm, for that matter, even without renaming things, a comment above
stack_trace_save_tsk_reliable() describing the meaning of "reliable"
would be a good idea.

-- 
Josh



From chunkuang.hu at kernel.org  Fri Apr  9 23:41:36 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 10 Apr 2021 06:41:36 +0800
Subject: [PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167
In-Reply-To: <20210409084308.481185-1-narmstrong@baylibre.com>
References: <20210409084308.481185-1-narmstrong@baylibre.com>
Message-ID: <CAAOTY_-gqN2HCLg6AABsXYzJoBxpN8FkMfjqWFu2q=6noiY1qg@mail.gmail.com>

Hi, Neil:

Neil Armstrong <narmstrong at baylibre.com> ? 2021?4?9? ?? ??4:43???
>
> On MT8167, only CEA modes and anything using a clock below 148500 is
> supported for HDMI. This change adds some checks to make sure the
> video format is OK for MT8167.

I think this patch should be separated to 3 patches. check CEA mode,
check clock, add mt8167 hdmi support.

>
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 8ee55f9e2954..991e2e935b93 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -148,6 +148,8 @@ struct hdmi_audio_param {
>
>  struct mtk_hdmi_conf {
>         bool tz_disabled;
> +       unsigned long max_mode_clock;
> +       bool cea_modes_only;
>  };
>
>  struct mtk_hdmi {
> @@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
>                         return MODE_BAD;
>         }
>
> +       if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
> +               return MODE_BAD;
> +
> +       if (hdmi->conf->max_mode_clock &&
> +           mode->clock > hdmi->conf->max_mode_clock)
> +               return MODE_CLOCK_HIGH;
> +
>         if (mode->clock < 27000)
>                 return MODE_CLOCK_LOW;
>         if (mode->clock > 297000)
> @@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
>         .tz_disabled = true,
>  };
>
> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
> +       .max_mode_clock = 148500,
> +       .cea_modes_only = true,
> +};
> +
>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
>         { .compatible = "mediatek,mt2701-hdmi",
>           .data = &mtk_hdmi_conf_mt2701,
>         },
> +       { .compatible = "mediatek,mt8167-hdmi",

"mediatek,mt8167-hdmi" does not exist in binding document, so add this
to binding document first.
In addition, could you also transfer mediatek,hdmi.txt to yaml format?

Regards,
Chun-Kuang.

> +         .data = &mtk_hdmi_conf_mt8167,
> +       },
>         { .compatible = "mediatek,mt8173-hdmi",
>         },
>         {}
> --
> 2.25.1
>


From jpoimboe at redhat.com  Fri Apr  9 23:53:21 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Fri, 9 Apr 2021 17:53:21 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409223227.rvf6tfhvgnpzmabn@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
 <20210409223227.rvf6tfhvgnpzmabn@treble>
Message-ID: <20210409225321.2czbawz6p2aquf5m@treble>

On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote:
> > > FWIW, over the years we've had zero issues with encoding the frame
> > > pointer on x86.  After you save pt_regs, you encode the frame pointer to
> > > point to it.  Ideally in the same macro so it's hard to overlook.
> > > 
> > 
> > I had the same opinion. In fact, in my encoding scheme, I have additional
> > checks to make absolutely sure that it is a true encoding and not stack
> > corruption. The chances of all of those values accidentally matching are,
> > well, null.
> 
> Right, stack corruption -- which is already exceedingly rare -- would
> have to be combined with a miracle or two in order to come out of the
> whole thing marked as 'reliable' :-)
> 
> And really, we already take a similar risk today by "trusting" the frame
> pointer value on the stack to a certain extent.

Oh yeah, I forgot to mention some more benefits of encoding the frame
pointer (or marking pt_regs in some other way):

a) Stack addresses can be printed properly: '%pS' for printing regs->pc
   and '%pB' for printing call returns.

   Using '%pS' for call returns (as arm64 seems to do today) will result
   in printing the wrong function when you have tail calls to noreturn
   functions on the stack (which is actually quite common for calls to
   panic(), die(), etc).

   More details:

   https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp at treble

b) Stack dumps to the console can dump the exception registers they find
   along the way.  This is actually quite nice for debugging.


-- 
Josh



From nobuhiro1.iwamatsu at toshiba.co.jp  Sat Apr 10 00:08:35 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sat, 10 Apr 2021 08:08:35 +0900
Subject: [PATCH v4 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Message-ID: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation and device driver.

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

Updates:

  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
    v3 -> v4:
      - No update.
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm
      - Change filename to toshiba,visconti-pwm.yaml.
      - Add Reviewed-by tag from Rob.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
      - Set compatible toshiba,pwm-visconti only.
      - Drop unnecessary comments.

  pwm: visconti: Add Toshiba Visconti SoC PWM support
    v3 -> v4:
      - Sorted alphabetically include files.
      - Changed container_of to using static inline functions.
      - Dropped unnecessary dev_dbg().
      - Drop Initialization of chip.base.
      - Drop commnet "period too small".
      - Rebased for-next. 
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm.
      - Fix MODULE_ALIAS to platform:pwm-visconti, again.
      - Align continuation line to the opening parenthesis.
      - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only.
      - Add prefix for the register defines.
      - Drop struct device from struct visconti_pwm_chip.
      - Use '>>' instead of '/'.
      - Drop error message by devm_platform_ioremap_resource().
      - Use dev_err_probe instead of dev_err.
      - Change dev_info to dev_dbg.
      - Remove some empty lines.
      - Fix MODULE_ALIAS to platform:pwm-visconti.
      - Add .get_state() function.
      - Use the author name and email address to MODULE_AUTHOR.
      - Add more comment to function of the hardware.
      - Support .get_status() function.
      - Use NSEC_PER_USEC instead of 1000.
      - Alphabetically sorted for Makefile and Kconfig.
      - Added check for set value in visconti_pwm_apply().

Nobuhiro Iwamatsu (2):
  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
  pwm: visconti: Add Toshiba Visconti SoC PWM support

 .../bindings/pwm/toshiba,pwm-visconti.yaml    |  43 ++++
 drivers/pwm/Kconfig                           |   9 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-visconti.c                    | 188 ++++++++++++++++++
 4 files changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
 create mode 100644 drivers/pwm/pwm-visconti.c

-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Sat Apr 10 00:08:36 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sat, 10 Apr 2021 08:08:36 +0900
Subject: [PATCH v4 1/2] dt-bindings: pwm: Add bindings for Toshiba Visconti
 PWM Controller
In-Reply-To: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210409230837.1919744-2-nobuhiro1.iwamatsu@toshiba.co.jp>

Add bindings for the Toshiba Visconti PWM Controller.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pwm/toshiba,pwm-visconti.yaml    | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml

diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
new file mode 100644
index 000000000000..d350f5edfb67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/toshiba,pwm-visconti.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti PWM Controller
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,visconti-pwm
+
+  reg:
+    maxItems: 1
+
+  '#pwm-cells':
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pwm: pwm at 241c0000 {
+            compatible = "toshiba,visconti-pwm";
+            reg = <0 0x241c0000 0 0x1000>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&pwm_mux>;
+            #pwm-cells = <2>;
+        };
+    };
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Sat Apr 10 00:08:37 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sat, 10 Apr 2021 08:08:37 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add driver for the PWM controller on Toshiba Visconti ARM SoC.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pwm/Kconfig        |   9 ++
 drivers/pwm/Makefile       |   1 +
 drivers/pwm/pwm-visconti.c | 188 +++++++++++++++++++++++++++++++++++++
 3 files changed, 198 insertions(+)
 create mode 100644 drivers/pwm/pwm-visconti.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..8ae68d6203fb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -601,6 +601,15 @@ config PWM_TWL_LED
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-twl-led.
 
+config PWM_VISCONTI
+	tristate "Toshiba Visconti PWM support"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	help
+	  PWM Subsystem driver support for Toshiba Visconti SoCs.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-visconti.
+
 config PWM_VT8500
 	tristate "vt8500 PWM support"
 	depends on ARCH_VT8500 || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..d43b1e17e8e1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
+obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
 obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
new file mode 100644
index 000000000000..99d83f94ed86
--- /dev/null
+++ b/drivers/pwm/pwm-visconti.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Toshiba Visconti pulse-width-modulation controller driver
+ *
+ * Copyright (c) 2020 TOSHIBA CORPORATION
+ * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
+ *
+ * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
+#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
+#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
+
+#define PIPGM_PWMC_PWMACT		BIT(5)
+#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
+#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 *to_visconti_chip(struct pwm_chip *chip)
+{
+	return container_of(chip, struct visconti_pwm_chip, chip);
+}
+
+static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
+	u32 period, duty_cycle, pwmc0;
+
+	/*
+	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
+	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
+	 * the period register (PCSR) is written and the currently running period is completed. This
+	 * way the hardware switches atomically from the old setting to the new.
+	 * Also, disabling the hardware completes the currently running period and keeps the output
+	 * at low level at all times.
+	 */
+	if (!state->enabled) {
+		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
+		return 0;
+	}
+
+	/*
+	 * The biggest period the hardware can provide is
+	 *	(0xffff << 3) * 1000 ns
+	 * This value fits easily in an u32, so simplify the maths by
+	 * capping the values to 32 bit integers.
+	 */
+	if (state->period > (0xffff << 3) * 1000)
+		period = (0xffff << 3) * 1000;
+	else
+		period = state->period;
+
+	if (state->duty_cycle > period)
+		duty_cycle = period;
+	else
+		duty_cycle = state->duty_cycle;
+
+	/*
+	 * The input clock runs fixed at 1 MHz, so we have only
+	 * microsecond resolution and so can divide by
+	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
+	 */
+	period /= 1000;
+	duty_cycle /= 1000;
+
+	if (!period)
+		return -ERANGE;
+
+	/*
+	 * PWMC controls a divider that divides the input clk by a
+	 * power of two between 1 and 8. As a smaller divider yields
+	 * higher precision, pick the smallest possible one.
+	 */
+	if (period > 0xffff) {
+		pwmc0 = ilog2(period >> 16);
+		BUG_ON(pwmc0 > 3);
+	} else
+		pwmc0 = 0;
+
+	period >>= pwmc0;
+	duty_cycle >>= pwmc0;
+
+	if (state->polarity == PWM_POLARITY_INVERSED)
+		pwmc0 |= PIPGM_PWMC_PWMACT;
+	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
+	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
+	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
+
+	return 0;
+}
+
+static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = chip_to_priv(chip);
+	u32 period, duty, pwmc0, pwmc0_clk;
+
+	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
+	if (period)
+		state->enabled = true;
+	else
+		state->enabled = false;
+
+	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
+	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
+	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
+
+	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
+	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
+	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
+		state->polarity = PWM_POLARITY_INVERSED;
+	else
+		state->polarity = PWM_POLARITY_NORMAL;
+}
+
+static const struct pwm_ops visconti_pwm_ops = {
+	.apply = visconti_pwm_apply,
+	.get_state = visconti_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int visconti_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pwm_chip *priv;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &visconti_pwm_ops;
+	priv->chip.npwm = 4;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
+
+	return 0;
+}
+
+static int visconti_pwm_remove(struct platform_device *pdev)
+{
+	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
+
+	return pwmchip_remove(&priv->chip);
+}
+
+static const struct of_device_id visconti_pwm_of_match[] = {
+	{ .compatible = "toshiba,visconti-pwm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, visconti_pwm_of_match);
+
+static struct platform_driver visconti_pwm_driver = {
+	.driver = {
+		.name = "pwm-visconti",
+		.of_match_table = visconti_pwm_of_match,
+	},
+	.probe = visconti_pwm_probe,
+	.remove = visconti_pwm_remove,
+};
+module_platform_driver(visconti_pwm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>");
+MODULE_ALIAS("platform:pwm-visconti");
-- 
2.30.0.rc2



From ndesaulniers at google.com  Sat Apr 10 00:36:09 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Fri, 9 Apr 2021 16:36:09 -0700
Subject: [PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
In-Reply-To: <20210409221155.1113205-1-nathan@kernel.org>
References: <20210409221155.1113205-1-nathan@kernel.org>
Message-ID: <CAKwvOdnTFXPy29L5JhcMBJAP4STfZUMn6739Mc4J_2Qwu3efBw@mail.gmail.com>

On Fri, Apr 9, 2021 at 3:12 PM Nathan Chancellor <nathan at kernel.org> wrote:
>
> Debian's clang carries a patch that makes the default FPU mode
> 'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
> instructions on hardware that does not support them:
>
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
> https://bugs.debian.org/841474
> https://bugs.debian.org/842142
> https://bugs.debian.org/914268

Another good link would be the one from Jessica describing more
precisely what the ARM targets for Debian are:
https://wiki.debian.org/ArchitectureSpecificsMemo#armel

>
> This results in the following build error when clang's integrated
> assembler is used because the '.arch' directive overrides the '.fpu'
> directive:
>
> arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
>  vmov.i32 q0, #1
>  ^
> arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
>  vshr.u64 q1, q0, #7
>  ^
> arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
>  vshr.u64 q0, q0, #8
>  ^
> arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
>  vmov.i32 d4, #19
>  ^
>
> Shuffle the order of the '.arch' and '.fpu' directives so that the code
> builds regardless of the default FPU mode. This has been tested against
> both clang with and without Debian's patch and GCC.
>
> Cc: stable at vger.kernel.org
> Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
> Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Suggested-by: Arnd Bergmann <arnd at arndb.de>
> Suggested-by: Jessica Clarke <jrtc27 at jrtc27.com>
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>

Great work tracking down that Debian was carrying patches! Thank you!
I've run this through the same 3 assemblers.

Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>
Tested-by: Nick Desaulniers <ndesaulniers at google.com>

> ---
>  arch/arm/crypto/curve25519-core.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/crypto/curve25519-core.S b/arch/arm/crypto/curve25519-core.S
> index be18af52e7dc..b697fa5d059a 100644
> --- a/arch/arm/crypto/curve25519-core.S
> +++ b/arch/arm/crypto/curve25519-core.S
> @@ -10,8 +10,8 @@
>  #include <linux/linkage.h>
>
>  .text
> -.fpu neon
>  .arch armv7-a
> +.fpu neon
>  .align 4
>
>  ENTRY(curve25519_neon)
>
> base-commit: e49d033bddf5b565044e2abe4241353959bc9120
> --
> 2.31.1.189.g2e36527f23
>


-- 
Thanks,
~Nick Desaulniers


From cki-project at redhat.com  Sat Apr 10 00:40:34 2021
From: cki-project at redhat.com (CKI Project)
Date: Fri, 09 Apr 2021 23:40:34 -0000
Subject: =?utf-8?b?4p2M?= FAIL: Test report for kernel 5.12.0-rc4 (arm-next,
 a61be843)
Message-ID: <cki.D5B650052E.587HEJ1V3R@redhat.com>


Hello,

We ran automated tests on a recent commit from this kernel tree:

       Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
            Commit: a61be843e1b1 - Merge branch 'for-next/fixes' into for-kernelci

The results of these automated tests are provided below.

    Overall result: FAILED (see details below)
             Merge: OK
           Compile: OK
             Tests: FAILED

All kernel binaries, config files, and logs are available for download here:

  https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/04/09/284003294

One or more kernel tests failed:

    aarch64:
     ? Networking tunnel: geneve basic test

We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.

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
           `-'
______________________________________________________________________________

Compile testing
---------------

We compiled the kernel for 1 architecture:

    aarch64:
      make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg



Hardware testing
----------------
We booted each kernel and ran the following tests:

  aarch64:
    Host 1:
       ? Boot test
       ? ACPI table test
       ? ACPI enabled test
       ? LTP
       ? CIFS Connectathon
       ? POSIX pjd-fstest suites
       ? Loopdev Sanity
       ? jvm - jcstress tests
       ? Memory: fork_mem
       ? Memory function: memfd_create
       ? AMTU (Abstract Machine Test Utility)
       ? Networking bridge: sanity
       ? Ethernet drivers sanity
       ? Networking socket: fuzz
       ? Networking: igmp conformance test
       ? Networking route: pmtu
       ? Networking route_func - local
       ? Networking route_func - forward
       ? Networking TCP: keepalive test
       ? Networking UDP: socket
       ? Networking cki netfilter test
       ? Networking tunnel: geneve basic test
       ? Networking tunnel: gre basic
       ? L2TP basic test
       ? Networking tunnel: vxlan basic
       ? Networking ipsec: basic netns - transport
       ? Networking ipsec: basic netns - tunnel
       ? Libkcapi AF_ALG test
       ? pciutils: update pci ids test
       ? ALSA PCM loopback test
       ? ALSA Control (mixer) Userspace Element test
       ? storage: SCSI VPD
       ? trace: ftrace/tracer
       ? ? i2c: i2cdetect sanity
       ? ? Firmware test suite
       ? ? Memory function: kaslr
       ? ? audit: audit testsuite test

    Host 2:
       ? Boot test
       ? xfstests - ext4
       ? xfstests - xfs
       ? selinux-policy: serge-testsuite
       ? storage: software RAID testing
       ? Storage: swraid mdadm raid_module test
       ? ? xfstests - btrfs
       ? ? IPMI driver test
       ? ? IPMItool loop stress test
       ? ? Storage blktests
       ? ? Storage block - filesystem fio test
       ? ? Storage block - queue scheduler test
       ? ? Storage nvme - tcp
       ? ? Storage: lvm device-mapper test
       ? ? stress: stress-ng

  Test sources: https://gitlab.com/cki-project/kernel-tests
    ? Pull requests are welcome for new tests or improvements to existing tests!

Aborted tests
-------------
Tests that didn't complete running successfully are marked with ???.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.

Waived tests
------------
If the test run included waived tests, they are marked with ?. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.

Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ?.



From linus.walleij at linaro.org  Sat Apr 10 01:07:26 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 10 Apr 2021 02:07:26 +0200
Subject: [PATCH] pinctrl: samsung: use 'int' for register masks in Exynos
In-Reply-To: <20210408195029.69974-1-krzysztof.kozlowski@canonical.com>
References: <20210408195029.69974-1-krzysztof.kozlowski@canonical.com>
Message-ID: <CACRpkdYm0yG7mC0H7YwgQdPP1eT=GSkvHbohA7jc6LDsVPsZBQ@mail.gmail.com>

On Thu, Apr 8, 2021 at 9:50 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:

> The Special Function Registers on all Exynos SoC, including ARM64, are
> 32-bit wide, so entire driver uses matching functions like readl() or
> writel().  On 64-bit ARM using unsigned long for register masks:
> 1. makes little sense as immediately after bitwise operation it will be
>    cast to 32-bit value when calling writel(),
> 2. is actually error-prone because it might promote other operands to
>    64-bit.
>
> Addresses-Coverity: Unintentional integer overflow
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
(...)
> Please apply it directly, I don't have any patches for Samsung pinctrl
> in my tree.

OK! Patch applied!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Apr 10 01:08:39 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 10 Apr 2021 02:08:39 +0200
Subject: [PATCH] pinctrl: at91-pio4: Fix slew rate disablement
In-Reply-To: <20210409082522.625168-1-tudor.ambarus@microchip.com>
References: <20210409082522.625168-1-tudor.ambarus@microchip.com>
Message-ID: <CACRpkdbRfnZT9OU3FccZ7vny+Ami=k+dkDr4Lo7w_JOgzotX9A@mail.gmail.com>

On Fri, Apr 9, 2021 at 10:25 AM Tudor Ambarus
<tudor.ambarus at microchip.com> wrote:

> The slew rate was enabled by default for each configuration of the
> pin. In case the pin had more than one configuration, even if
> we set the slew rate as disabled in the device tree, the next pin
> configuration would set again the slew rate enabled by default,
> overwriting the slew rate disablement.
> Instead of enabling the slew rate by default for each pin configuration,
> enable the slew rate by default just once per pin, regardless of the
> number of configurations. This way the slew rate disablement will also
> work for cases where pins have multiple configurations.
>
> Fixes: 440b144978ba ("pinctrl: at91-pio4: add support for slew-rate")
> Signed-off-by: Tudor Ambarus <tudor.ambarus at microchip.com>

Patch applied!

Yours,
Linus Walleij


From lkp at intel.com  Sat Apr 10 01:36:26 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 08:36:26 +0800
Subject: [soc:arm/apple-m1] BUILD SUCCESS
 ea96292838397682530ac77a429974f8ff5f2df3
Message-ID: <6070f30a.pqg7oidsgZP9ab4s%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/apple-m1
branch HEAD: ea96292838397682530ac77a429974f8ff5f2df3  asm-generic/io.h: Unbork ioremap_np() declaration

elapsed time: 722m

configs tested: 181
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm64                               defconfig
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
sh                           se7722_defconfig
m68k                        m5307c3_defconfig
powerpc                       ppc64_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
sh                        dreamcast_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
sh                           se7712_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
arm                          badge4_defconfig
s390                             allyesconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
arc                      axs103_smp_defconfig
powerpc                     taishan_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
arm                         shannon_defconfig
mips                malta_kvm_guest_defconfig
sh                           se7619_defconfig
sh                      rts7751r2d1_defconfig
h8300                     edosk2674_defconfig
xtensa                    xip_kc705_defconfig
m68k                         amcore_defconfig
powerpc                     ksi8560_defconfig
powerpc                       eiger_defconfig
mips                       rbtx49xx_defconfig
xtensa                  audio_kc705_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
sh                          lboxre2_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
mips                     loongson1b_defconfig
arm                         mv78xx0_defconfig
arm                       multi_v4t_defconfig
xtensa                  cadence_csp_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
csky                                defconfig
i386                                defconfig
arm                        vexpress_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
arc                                 defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                                defconfig
parisc                           allyesconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 01:44:12 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 08:44:12 +0800
Subject: [PATCH v6 08/10] coresight: config: Add preloaded configurations
In-Reply-To: <20210409103722.26290-9-mike.leach@linaro.org>
References: <20210409103722.26290-9-mike.leach@linaro.org>
Message-ID: <202104100800.0YHQhGqJ-lkp@intel.com>

Hi Mike,

I love your patch! Yet something to improve:

[auto build test ERROR on next-20210408]
[also build test ERROR on v5.12-rc6]
[cannot apply to soc/for-next lwn/docs-next linus/master v5.12-rc6 v5.12-rc5 v5.12-rc4]
[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]

url:    https://github.com/0day-ci/linux/commits/Mike-Leach/CoreSight-configuration-management-ETM-strobing/20210409-183900
base:    6145d80cfc62e3ed8f16ff584d6287e6d88b82b9
config: arm-randconfig-r011-20210409 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project dd453a1389b6a7e6d9214b449d3c54981b1a89b6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/e97fc23237355b8b816f4e4864206f91a41652cc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mike-Leach/CoreSight-configuration-management-ETM-strobing/20210409-183900
        git checkout e97fc23237355b8b816f4e4864206f91a41652cc
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from drivers/hwtracing/coresight/coresight-cfg-afdo.c:8:
   In file included from drivers/hwtracing/coresight/coresight-etm4x-cfg.h:10:
>> drivers/hwtracing/coresight/coresight-etm4x.h:143:10: fatal error: 'asm/sysreg.h' file not found
   #include <asm/sysreg.h>
            ^~~~~~~~~~~~~~
   1 error generated.


vim +143 drivers/hwtracing/coresight/coresight-etm4x.h

03336d0f4d0d74 Suzuki K Poulose 2021-02-01  142  
03336d0f4d0d74 Suzuki K Poulose 2021-02-01 @143  #include <asm/sysreg.h>
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  144  #define ETM4x_REG_NUM_TO_SYSREG(n)				\
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  145  	sys_reg(2, 1, ETM4x_CRn(n), ETM4x_CRm(n), ETM4x_Op2(n))
03336d0f4d0d74 Suzuki K Poulose 2021-02-01  146  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31290 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210410/b0c69062/attachment-0001.gz>

From kuba at kernel.org  Sat Apr 10 01:50:04 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 9 Apr 2021 17:50:04 -0700
Subject: [PATCH net-next v2 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210407170442.1641-1-vee.khee.wong@linux.intel.com>
References: <20210407170442.1641-1-vee.khee.wong@linux.intel.com>
Message-ID: <20210409175004.2fceacdd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

Other than the minor nit below LGTM. Let's give Richard one more day.

On Thu,  8 Apr 2021 01:04:42 +0800 Wong Vee Khee wrote:
> +static void timestamp_interrupt(struct stmmac_priv *priv)
> +{
> +	struct ptp_clock_event event;
> +	unsigned long flags;
> +	u32 num_snapshot;
> +	u32 ts_status;
> +	u32 tsync_int;
> +	u64 ptp_time;
> +	int i;
> +
> +	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
> +
> +	if (!tsync_int)
> +		return;
> +
> +	/* Read timestamp status to clear interrupt from either external
> +	 * timestamp or start/end of PPS.
> +	 */
> +	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
> +
> +	if (priv->plat->ext_snapshot_en) {

Are you intending to add more code after this if? Otherwise you could
flip the condition and return early instead of having the extra level
of indentation.

> +		num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
> +			       GMAC_TIMESTAMP_ATSNS_SHIFT;
> +
> +		for (i = 0; i < num_snapshot; i++) {
> +			spin_lock_irqsave(&priv->ptp_lock, flags);
> +			get_ptptime(priv->ptpaddr, &ptp_time);
> +			spin_unlock_irqrestore(&priv->ptp_lock, flags);
> +			event.type = PTP_CLOCK_EXTTS;
> +			event.index = 0;
> +			event.timestamp = ptp_time;
> +			ptp_clock_event(priv->ptp_clock, &event);
> +		}
> +	}
> +}

Not really related to this patch but how does stmmac set IRQF_SHARED
and yet not track if it indeed generated the interrupt? Isn't that
against the rules?



From chunfeng.yun at mediatek.com  Sat Apr 10 02:20:45 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 09:20:45 +0800
Subject: [PATCH v2] usb: core: reduce power-on-good delay time of root hub
Message-ID: <1618017645-12259-1-git-send-email-chunfeng.yun@mediatek.com>

Return the exactly delay time given by root hub descriptor,
this helps to reduce resume time etc.

Due to the root hub descriptor is usually provided by the host
controller driver, if there is compatibility for a root hub,
we can fix it easily without affect other root hub

Acked-by: Alan Stern <stern at rowland.harvard.edu>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: remove RFC tag, and add acked-by Alan
---
 drivers/usb/core/hub.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 73f4482d833a..22ea1f4f2d66 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -148,8 +148,10 @@ static inline unsigned hub_power_on_good_delay(struct usb_hub *hub)
 {
 	unsigned delay = hub->descriptor->bPwrOn2PwrGood * 2;
 
-	/* Wait at least 100 msec for power to become stable */
-	return max(delay, 100U);
+	if (!hub->hdev->parent)	/* root hub */
+		return delay;
+	else /* Wait at least 100 msec for power to become stable */
+		return max(delay, 100U);
 }
 
 static inline int hub_port_debounce_be_connected(struct usb_hub *hub,
-- 
2.18.0

From swboyd at chromium.org  Sat Apr 10 02:52:47 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Fri,  9 Apr 2021 18:52:47 -0700
Subject: [PATCH v4 00/13] Add build ID to stacktraces
Message-ID: <20210410015300.3764485-1-swboyd@chromium.org>

This series adds the kernel's build ID[1] to the stacktrace header printed
in oops messages, warnings, etc. and the build ID for any module that
appears in the stacktrace after the module name. The goal is to make the
stacktrace more self-contained and descriptive by including the relevant
build IDs in the kernel logs when something goes wrong. This can be used
by post processing tools like script/decode_stacktrace.sh and kernel
developers to easily locate the debug info associated with a kernel
crash and line up what line and file things started falling apart at.

To show how this can be used I've included a patch to
decode_stacktrace.sh that downloads the debuginfo from a debuginfod
server.

This also includes some patches to make the buildid.c file use more
const arguments and consolidate logic into buildid.c from kdump. These
are left to the end as they were mostly cleanup patches. I don't know
who exactly maintains this so I guess Andrew is the best option to merge
all this code.

Here's an example lkdtm stacktrace on arm64.

 WARNING: CPU: 4 PID: 3255 at drivers/misc/lkdtm/bugs.c:83 lkdtm_WARNING+0x28/0x30 [lkdtm]
 Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE
 CPU: 4 PID: 3255 Comm: bash Not tainted 5.11 #3 aa23f7a1231c229de205662d5a9e0d4c580f19a1
 Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
 pstate: 00400009 (nzcv daif +PAN -UAO -TCO BTYPE=--)
 pc : lkdtm_WARNING+0x28/0x30 [lkdtm]
 lr : lkdtm_do_action+0x24/0x40 [lkdtm]
 sp : ffffffc0134fbca0
 x29: ffffffc0134fbca0 x28: ffffff92d53ba240
 x27: 0000000000000000 x26: 0000000000000000
 x25: 0000000000000000 x24: ffffffe3622352c0
 x23: 0000000000000020 x22: ffffffe362233366
 x21: ffffffe3622352e0 x20: ffffffc0134fbde0
 x19: 0000000000000008 x18: 0000000000000000
 x17: ffffff929b6536fc x16: 0000000000000000
 x15: 0000000000000000 x14: 0000000000000012
 x13: ffffffe380ed892c x12: ffffffe381d05068
 x11: 0000000000000000 x10: 0000000000000000
 x9 : 0000000000000001 x8 : ffffffe362237000
 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000
 x5 : 0000000000000000 x4 : 0000000000000001
 x3 : 0000000000000008 x2 : ffffff93fef25a70
 x1 : ffffff93fef15788 x0 : ffffffe3622352e0
 Call trace:
  lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e]
  direct_entry+0x16c/0x1b4 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e]
  full_proxy_write+0x74/0xa4
  vfs_write+0xec/0x2e8
  ksys_write+0x84/0xf0
  __arm64_sys_write+0x24/0x30
  el0_svc_common+0xf4/0x1c0
  do_el0_svc_compat+0x28/0x3c
  el0_svc_compat+0x10/0x1c
  el0_sync_compat_handler+0xa8/0xcc
  el0_sync_compat+0x178/0x180
 ---[ end trace 3d95032303e59e68 ]---

Changes from v3 (https://lore.kernel.org/r/20210331030520.3816265-1-swboyd at chromium.org):
 * Fixed compilation warnings due to config changes
 * Fixed kernel-doc on init_vmlinx_build_id()
 * Totally removed add_build_id_vmcoreinfo()
 * Added another printk format %pBb to help x86 print backtraces
 * Some BUILD_BUG_ON() checks to make sure the buildid doesn't get bigger or smaller

Changes from v2 (https://lore.kernel.org/r/20210324020443.1815557-1-swboyd at chromium.org):
 * Renamed symbol printing function to indicate build IDness
 * Put build ID information behind Kconfig knob
 * Build ID for vmlinux is calculated in early init instead of on demand
 * printk format is %pS[R]b

Changes from v1 (https://lore.kernel.org/r/20210301174749.1269154-1-swboyd at chromium.org):
 * New printk format %pSb and %pSr
 * Return binary format instead of hex format string from build ID APIs
 * Some new patches to cleanup buildid/decode_stacktrace.sh
 * A new patch to decode_stacktrace.sh to parse output

[1] https://fedoraproject.org/wiki/Releases/FeatureBuildId

Cc: Alexei Starovoitov <ast at kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Baoquan He <bhe at redhat.com>
Cc: Borislav Petkov <bp at alien8.de>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Dave Young <dyoung at redhat.com>
Cc: Evan Green <evgreen at chromium.org>
Cc: Hsin-Yi Wang <hsinyi at chromium.org>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: Jessica Yu <jeyu at kernel.org>
Cc: Jiri Olsa <jolsa at kernel.org>
Cc: <kexec at lists.infradead.org>
Cc: Konstantin Khlebnikov <khlebnikov at yandex-team.ru>
Cc: <linux-arm-kernel at lists.infradead.org>
Cc: <linux-doc at vger.kernel.org>
Cc: <linux-kernel at vger.kernel.org>
Cc: Matthew Wilcox <willy at infradead.org>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Rasmus Villemoes <linux at rasmusvillemoes.dk>
Cc: Sasha Levin <sashal at kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky at gmail.com>
Cc: Steven Rostedt <rostedt at goodmis.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Will Deacon <will at kernel.org>
Cc: <x86 at kernel.org>
Cc: Christoph Hellwig <hch at infradead.org>
Cc: peter enderborg <peter.enderborg at sony.com>


Stephen Boyd (13):
  buildid: Only consider GNU notes for build ID parsing
  buildid: Add API to parse build ID out of buffer
  buildid: Stash away kernels build ID on init
  dump_stack: Add vmlinux build ID to stack traces
  module: Add printk formats to add module build ID to stacktraces
  arm64: stacktrace: Use %pSb for backtrace printing
  x86/dumpstack: Use %pSb/%pBb for backtrace printing
  scripts/decode_stacktrace.sh: Support debuginfod
  scripts/decode_stacktrace.sh: Silence stderr messages from
    addr2line/nm
  scripts/decode_stacktrace.sh: Indicate 'auto' can be used for base
    path
  buildid: Mark some arguments const
  buildid: Fix kernel-doc notation
  kdump: Use vmlinux_build_id to simplify

 Documentation/core-api/printk-formats.rst | 11 +++
 arch/arm64/kernel/stacktrace.c            |  2 +-
 arch/x86/kernel/dumpstack.c               |  6 +-
 include/linux/buildid.h                   |  4 +
 include/linux/crash_core.h                |  7 +-
 include/linux/kallsyms.h                  | 20 ++++-
 include/linux/module.h                    |  6 +-
 init/main.c                               |  1 +
 kernel/crash_core.c                       | 50 +-----------
 kernel/kallsyms.c                         | 95 ++++++++++++++++++-----
 kernel/module.c                           | 24 +++++-
 lib/Kconfig.debug                         | 11 +++
 lib/buildid.c                             | 72 +++++++++++++----
 lib/dump_stack.c                          | 13 +++-
 lib/vsprintf.c                            |  8 +-
 scripts/decode_stacktrace.sh              | 89 +++++++++++++++++----
 16 files changed, 304 insertions(+), 115 deletions(-)


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
-- 
https://chromeos.dev



From swboyd at chromium.org  Sat Apr 10 02:52:53 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Fri,  9 Apr 2021 18:52:53 -0700
Subject: [PATCH v4 06/13] arm64: stacktrace: Use %pSb for backtrace printing
In-Reply-To: <20210410015300.3764485-1-swboyd@chromium.org>
References: <20210410015300.3764485-1-swboyd@chromium.org>
Message-ID: <20210410015300.3764485-7-swboyd@chromium.org>

Let's use the new printk format to print the stacktrace entry when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: <linux-arm-kernel at lists.infradead.org>
Cc: Jiri Olsa <jolsa at kernel.org>
Cc: Alexei Starovoitov <ast at kernel.org>
Cc: Jessica Yu <jeyu at kernel.org>
Cc: Evan Green <evgreen at chromium.org>
Cc: Hsin-Yi Wang <hsinyi at chromium.org>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Steven Rostedt <rostedt at goodmis.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Matthew Wilcox <willy at infradead.org>
Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
Link: https://sourceware.org/elfutils/Debuginfod.html [2]
Signed-off-by: Stephen Boyd <swboyd at chromium.org>
---
 arch/arm64/kernel/stacktrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..9d38da01ff98 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -129,7 +129,7 @@ NOKPROBE_SYMBOL(walk_stackframe);
 
 static void dump_backtrace_entry(unsigned long where, const char *loglvl)
 {
-	printk("%s %pS\n", loglvl, (void *)where);
+	printk("%s %pSb\n", loglvl, (void *)where);
 }
 
 void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
-- 
https://chromeos.dev



From chunfeng.yun at mediatek.com  Sat Apr 10 02:44:21 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 09:44:21 +0800
Subject: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend
 hook called
In-Reply-To: <CAJZ5v0ioobLt5aEm8TAcPKgJiL13OJ7KqTeJmcQCuVp8ALxBmw@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <CAJZ5v0gGntbfnvAP5A491_hUh-JUuqZjZRdPPLwWJjnZRtemcQ@mail.gmail.com>
 <1617933211.12105.22.camel@mhfsdcap03> <YG/ohhh3Tyet6InQ@atomide.com>
 <1617957362.12105.27.camel@mhfsdcap03>
 <CAJZ5v0ioobLt5aEm8TAcPKgJiL13OJ7KqTeJmcQCuVp8ALxBmw@mail.gmail.com>
Message-ID: <1618019061.12105.48.camel@mhfsdcap03>

On Fri, 2021-04-09 at 13:14 +0200, Rafael J. Wysocki wrote:
> On Fri, Apr 9, 2021 at 10:36 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > On Fri, 2021-04-09 at 08:39 +0300, Tony Lindgren wrote:
> > > * Chunfeng Yun <chunfeng.yun at mediatek.com> [210409 01:54]:
> > > > On Thu, 2021-04-08 at 19:41 +0200, Rafael J. Wysocki wrote:
> > > > > On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > > > > >
> > > > > > When the dedicated wake irq is level trigger, enable it before
> > > > > > calling runtime_suspend, will trigger an interrupt.
> > > > > >
> > > > > > e.g.
> > > > > > for a low level trigger type, it's low level at running time (0),
> > > > > > and becomes high level when enters suspend (runtime_suspend (1) is
> > > > > > called), a wakeup signal at (2) make it become low level, wake irq
> > > > > > will be triggered.
> > > > > >
> > > > > >                 ------------------
> > > > > >                |           ^     ^|
> > > > > > ----------------           |     | --------------
> > > > > >  |<---(0)--->|<--(1)--|   (3)   (2)    (4)
> > > > > >
> > > > > > if we enable the wake irq before calling runtime_suspend during (0),
> > > > > > an interrupt will arise, it causes resume immediately;
> > > > >
> > > > > But that's necessary to avoid missing a wakeup interrupt, isn't it?
> > > > That's also what I worry about.
> > >
> > > Yeah sounds like this patch will lead into missed wakeirqs.
> > If miss level trigger wakeirqs, that means HW doesn't latch it? is it HW
> > limitation?
> 
> If it's level-triggered, it won't be missed, but then it is just
> pointless to suspend the device when wakeup is being signaled in the
> first place.
Got it
> 
> I'm not sure if I understand the underlying problem correctly.  Is it
> about addressing spurious wakeups?
In fact, it's default value is the same as the wakeup signal, maybe the
above case, using level trigger, should be avoided, it is not clear and
causes confusion, as Ikjoon and Tony suggested, using falling edge type
is better.

Thanks a lot




From wangqing at vivo.com  Sat Apr 10 03:42:33 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Sat, 10 Apr 2021 10:42:33 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSF0gd2F0Y2hkb2c6IG10azogc3VwcG9ydCBwcmUtdGltZW91dCB3aGVuIHRoZSBiYXJrIGlycSBpcyBhdmFpbGFibGU=?=
In-Reply-To: <58b6f50a-4522-dc21-3411-7ed18059b480@roeck-us.net>
Message-ID: <ANUA4QBkDhibiES5bK7X8Ko8.3.1618022553315.Hmail.wangqing@vivo.com>


>On 4/9/21 2:55 AM, Wang Qing wrote:
>> Use the bark interrupt as the pretimeout notifier if available.
>> 
>> By default, the pretimeout notification shall occur one second earlier
>> than the timeout.
>> 
>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>> ---
>>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 44 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>> index 97ca993..8b919cc
>> --- a/drivers/watchdog/mtk_wdt.c
>> +++ b/drivers/watchdog/mtk_wdt.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/reset-controller.h>
>>  #include <linux/types.h>
>>  #include <linux/watchdog.h>
>> +#include <linux/interrupt.h>
>>  
>>  #define WDT_MAX_TIMEOUT		31
>>  #define WDT_MIN_TIMEOUT		1
>> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>  	int ret;
>>  
>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>
>That looks suspiciously like the real watchdog won't happen at all.
>What will happen if the pretimeout governor is set to none ?
>
>Guenter
>
The pretimeout governor is panic by default. If pretimeout is enabled and the governor is
set to none, it means the timeout behavior does not need to be processed, only printing.

Thanks.

Qing Wang.



From willy at infradead.org  Sat Apr 10 03:43:13 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 10 Apr 2021 03:43:13 +0100
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <202104100656.N7EVvkNZ-lkp@intel.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
Message-ID: <20210410024313.GX2531743@casper.infradead.org>

On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel test robot wrote:
> >> include/linux/mm_types.h:274:1: error: static_assert failed due to requirement '__builtin_offsetof(struct page, lru) == __builtin_offsetof(struct folio, lru)' "offsetof(struct page, lru) == offsetof(struct folio, lru)"
>    FOLIO_MATCH(lru, lru);
>    include/linux/mm_types.h:272:2: note: expanded from macro 'FOLIO_MATCH'
>            static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))

Well, this is interesting.  pahole reports:

struct page {
        long unsigned int          flags;                /*     0     4 */
        /* XXX 4 bytes hole, try to pack */
        union {
                struct {
                        struct list_head lru;            /*     8     8 */
...
struct folio {
        union {
                struct {
                        long unsigned int flags;         /*     0     4 */
                        struct list_head lru;            /*     4     8 */

so this assert has absolutely done its job.

But why has this assert triggered?  Why is struct page layout not what
we thought it was?  Turns out it's the dma_addr added in 2019 by commit
c25fff7171be ("mm: add dma_addr_t to struct page").  On this particular
config, it's 64-bit, and ppc32 requires alignment to 64-bit.  So
the whole union gets moved out by 4 bytes.

Unfortunately, we can't just fix this by putting an 'unsigned long pad'
in front of it.  It still aligns the entire union to 8 bytes, and then
it skips another 4 bytes after the pad.

We can fix it like this ...

+++ b/include/linux/mm_types.h
@@ -96,11 +96,12 @@ struct page {
                        unsigned long private;
                };
                struct {        /* page_pool used by netstack */
+                       unsigned long _page_pool_pad;
                        /**
                         * @dma_addr: might require a 64-bit value even on
                         * 32-bit architectures.
                         */
-                       dma_addr_t dma_addr;
+                       dma_addr_t dma_addr __packed;
                };
                struct {        /* slab, slob and slub */
                        union {

but I don't know if GCC is smart enough to realise that dma_addr is now
on an 8 byte boundary and it can use a normal instruction to access it,
or whether it'll do something daft like use byte loads to access it.

We could also do:

+                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));

and I see pahole, at least sees this correctly:

                struct {
                        long unsigned int _page_pool_pad; /*     4     4 */
                        dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
                } __attribute__((__packed__)) __attribute__((__aligned__(4)));  

This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
/ dma_addr_t.  Advice, please?


From linux at roeck-us.net  Sat Apr 10 03:56:45 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 9 Apr 2021 19:56:45 -0700
Subject: [PATCH] watchdog: mtk: support pre-timeout when the bark irq is
 available
In-Reply-To: <ANUA4QBkDhibiES5bK7X8Ko8.3.1618022553315.Hmail.wangqing@vivo.com>
References: <ANUA4QBkDhibiES5bK7X8Ko8.3.1618022553315.Hmail.wangqing@vivo.com>
Message-ID: <95861c15-0294-ddda-6080-ca15f19eb048@roeck-us.net>

On 4/9/21 7:42 PM, ?? wrote:
> 
>> On 4/9/21 2:55 AM, Wang Qing wrote:
>>> Use the bark interrupt as the pretimeout notifier if available.
>>>
>>> By default, the pretimeout notification shall occur one second earlier
>>> than the timeout.
>>>
>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>> ---
>>>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>>>  1 file changed, 44 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>> index 97ca993..8b919cc
>>> --- a/drivers/watchdog/mtk_wdt.c
>>> +++ b/drivers/watchdog/mtk_wdt.c
>>> @@ -25,6 +25,7 @@
>>>  #include <linux/reset-controller.h>
>>>  #include <linux/types.h>
>>>  #include <linux/watchdog.h>
>>> +#include <linux/interrupt.h>
>>>  
>>>  #define WDT_MAX_TIMEOUT		31
>>>  #define WDT_MIN_TIMEOUT		1
>>> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>  	int ret;
>>>  
>>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>>
>> That looks suspiciously like the real watchdog won't happen at all.
>> What will happen if the pretimeout governor is set to none ?
>>
>> Guenter
>>
> The pretimeout governor is panic by default. If pretimeout is enabled and the governor is
> set to none, it means the timeout behavior does not need to be processed, only printing.
> 

That was not my question. My question was if the real timeout happens in that case.

Guenter



From wangqing at vivo.com  Sat Apr 10 04:11:45 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Sat, 10 Apr 2021 11:11:45 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSF0gd2F0Y2hkb2c6IG10azogc3VwcG9ydCBwcmUtdGltZW91dCB3aGVuIHRoZSBiYXJrIGlycSBpcyBhdmFpbGFibGU=?=
In-Reply-To: <95861c15-0294-ddda-6080-ca15f19eb048@roeck-us.net>
Message-ID: <AKoADwCwDn4bllbdA00CnKoA.3.1618024305455.Hmail.wangqing@vivo.com>


>On 4/9/21 7:42 PM, ?? wrote:
>> 
>>> On 4/9/21 2:55 AM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> By default, the pretimeout notification shall occur one second earlier
>>>> than the timeout.
>>>>
>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>>>>  1 file changed, 44 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..8b919cc
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>>  	int ret;
>>>>  
>>>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>>>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>>>
>>> That looks suspiciously like the real watchdog won't happen at all.
>>> What will happen if the pretimeout governor is set to none ?
>>>
>>> Guenter
>>>
>> The pretimeout governor is panic by default. If pretimeout is enabled and the governor is
>> set to none, it means the timeout behavior does not need to be processed, only printing.
>> 
>
>That was not my question. My question was if the real timeout happens in that case.
>
>Guenter
>
Yes, the real timeout will happen. After WDT timeout, IRQ is sent out instead of 
reset signal first. In order to ensure that CPU does not get stuck after IRQ is sent out, 
WDT will time again and send reset signal to reset.

Thanks.
Qing Wang.


From wangli74 at huawei.com  Sat Apr 10 04:48:41 2021
From: wangli74 at huawei.com (Wang Li)
Date: Sat, 10 Apr 2021 03:48:41 +0000
Subject: [PATCH -next] drm/mediatek: Fix PM reference leak in
 mtk_crtc_ddp_hw_init()
Message-ID: <20210410034841.16567-1-wangli74@huawei.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.

Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wang Li <wangli74 at huawei.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 54ab3a324752..f1954242d8f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -259,7 +259,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 		drm_connector_list_iter_end(&conn_iter);
 	}
 
-	ret = pm_runtime_get_sync(crtc->dev->dev);
+	ret = pm_runtime_resume_and_get(crtc->dev->dev);
 	if (ret < 0) {
 		DRM_ERROR("Failed to enable power domain: %d\n", ret);
 		return ret;
-- 
2.17.1



From linux at roeck-us.net  Sat Apr 10 05:35:38 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 9 Apr 2021 21:35:38 -0700
Subject: [PATCH] watchdog: mtk: support pre-timeout when the bark irq is
 available
In-Reply-To: <AKoADwCwDn4bllbdA00CnKoA.3.1618024305455.Hmail.wangqing@vivo.com>
References: <AKoADwCwDn4bllbdA00CnKoA.3.1618024305455.Hmail.wangqing@vivo.com>
Message-ID: <45e40a84-9d98-87e7-659e-6c34834e6280@roeck-us.net>

On 4/9/21 8:11 PM, ?? wrote:
> 
>> On 4/9/21 7:42 PM, ?? wrote:
>>>
>>>> On 4/9/21 2:55 AM, Wang Qing wrote:
>>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>>
>>>>> By default, the pretimeout notification shall occur one second earlier
>>>>> than the timeout.
>>>>>
>>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>>> ---
>>>>>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>>>>>  1 file changed, 44 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>>> index 97ca993..8b919cc
>>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>>> @@ -25,6 +25,7 @@
>>>>>  #include <linux/reset-controller.h>
>>>>>  #include <linux/types.h>
>>>>>  #include <linux/watchdog.h>
>>>>> +#include <linux/interrupt.h>
>>>>>  
>>>>>  #define WDT_MAX_TIMEOUT		31
>>>>>  #define WDT_MIN_TIMEOUT		1
>>>>> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>>>  	int ret;
>>>>>  
>>>>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>>>>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>>>>
>>>> That looks suspiciously like the real watchdog won't happen at all.
>>>> What will happen if the pretimeout governor is set to none ?
>>>>
>>>> Guenter
>>>>
>>> The pretimeout governor is panic by default. If pretimeout is enabled and the governor is
>>> set to none, it means the timeout behavior does not need to be processed, only printing.
>>>
>>
>> That was not my question. My question was if the real timeout happens in that case.
>>
>> Guenter
>>
> Yes, the real timeout will happen. After WDT timeout, IRQ is sent out instead of 
> reset signal first. In order to ensure that CPU does not get stuck after IRQ is sent out, 
> WDT will time again and send reset signal to reset.
> 

When will that be, or in other words how does the chip know when to time out ?
After all, only a single timeout value is written into the chip. I don't see how
it would know to reset the chip after wdt_dev->timeout.

Guenter




From leo.yan at linaro.org  Sat Apr 10 06:00:40 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:40 +0800
Subject: [PATCH v3 0/6] perf arm-spe: Enable timestamp
Message-ID: <20210410050046.5394-1-leo.yan@linaro.org>

This patch set is to enable timestamp for Arm SPE trace.  It reads out
TSC parameters from the TIME_CONV event, the parameters are used for
conversion between timer counter and kernel time and which is applied
for Arm SPE samples.

This version dropped the change for adding hardware clock parameters
into auxtrace info, alternatively, it utilizes the TIME_CONV event to
extract the clock parameters which is used for timestamp calculation.

This patch set can be clearly applied on perf/core branch with:

  commit 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat --bpf-counters' new option")

Ths patch series has been tested on Hisilicon D06 platform.

Changes from v2:
* Changed to use TIME_CONV event for extracing clock parameters (Al).

Changes from v1:
* Rebased patch series on the latest perf/core branch;
* Fixed the patch for dumping TSC parameters to support both the
  older and new auxtrace info format.


Leo Yan (6):
  perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
  perf arm-spe: Save clock parameters from TIME_CONV event
  perf arm-spe: Convert event kernel time to counter value
  perf arm-spe: Assign kernel time to synthesized event
  perf arm-spe: Bail out if the trace is later than perf event
  perf arm-spe: Don't wait for PERF_RECORD_EXIT event

 tools/perf/util/arm-spe.c | 66 +++++++++++++++++++++++++++++++++------
 tools/perf/util/arm-spe.h |  1 -
 2 files changed, 56 insertions(+), 11 deletions(-)

-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:41 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:41 +0800
Subject: [PATCH v3 1/6] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-2-leo.yan@linaro.org>

The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
index 98d3235781c3..105ce0ea0a01 100644
--- a/tools/perf/util/arm-spe.h
+++ b/tools/perf/util/arm-spe.h
@@ -11,7 +11,6 @@
 
 enum {
 	ARM_SPE_PMU_TYPE,
-	ARM_SPE_PER_CPU_MMAPS,
 	ARM_SPE_AUXTRACE_PRIV_MAX,
 };
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:42 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:42 +0800
Subject: [PATCH v3 2/6] perf arm-spe: Save clock parameters from TIME_CONV
 event
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-3-leo.yan@linaro.org>

During the recording phase, "perf record" tool synthesizes event
PERF_RECORD_TIME_CONV for the hardware clock parameters and saves the
event into the data file.

Afterwards, when processing the data file, the event TIME_CONV will be
processed at the very early time and is stored into session context.

This patch extracts these parameters from the session context and saves
into the structure "spe->tc" with the type perf_tsc_conversion, so that
the parameters are ready for conversion between clock counter and time
stamp.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 2539d4baec44..b48816d5c0b4 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -26,6 +26,7 @@
 #include "symbol.h"
 #include "thread.h"
 #include "thread-stack.h"
+#include "tsc.h"
 #include "tool.h"
 #include "util/synthetic-events.h"
 
@@ -45,6 +46,8 @@ struct arm_spe {
 	struct machine			*machine;
 	u32				pmu_type;
 
+	struct perf_tsc_conversion	tc;
+
 	u8				timeless_decoding;
 	u8				data_queued;
 
@@ -1027,6 +1030,22 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
 	spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
 
 	spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
+
+	/*
+	 * The synthesized event PERF_RECORD_TIME_CONV has been handled
+	 * ahead and the parameters for hardware clock are stored in
+	 * the session context.  Passes these parameters to the structure
+	 * perf_tsc_conversion in "spe->tc", which is used for later
+	 * conversion between clock counter and timestamp.
+	 */
+	spe->tc.time_shift = session->time_conv.time_shift;
+	spe->tc.time_mult = session->time_conv.time_mult;
+	spe->tc.time_zero = session->time_conv.time_zero;
+	spe->tc.time_cycles = session->time_conv.time_cycles;
+	spe->tc.time_mask = session->time_conv.time_mask;
+	spe->tc.cap_user_time_zero = session->time_conv.cap_user_time_zero;
+	spe->tc.cap_user_time_short = session->time_conv.cap_user_time_short;
+
 	spe->auxtrace.process_event = arm_spe_process_event;
 	spe->auxtrace.process_auxtrace_event = arm_spe_process_auxtrace_event;
 	spe->auxtrace.flush_events = arm_spe_flush;
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:43 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:43 +0800
Subject: [PATCH v3 3/6] perf arm-spe: Convert event kernel time to counter
 value
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-4-leo.yan@linaro.org>

When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.

This patch converts the event kernel time to arch timer's counter value,
thus it can be used to compare with counter value contained in Arm SPE
Timestamp packet.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index b48816d5c0b4..f66e10c62473 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -669,7 +669,7 @@ static int arm_spe_process_event(struct perf_session *session,
 	}
 
 	if (sample->time && (sample->time != (u64) -1))
-		timestamp = sample->time;
+		timestamp = perf_time_to_tsc(sample->time, &spe->tc);
 	else
 		timestamp = 0;
 
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:44 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:44 +0800
Subject: [PATCH v3 4/6] perf arm-spe: Assign kernel time to synthesized event
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-5-leo.yan@linaro.org>

In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.

To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index f66e10c62473..ec7df83b50fd 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
 	struct arm_spe_record *record = &speq->decoder->record;
 
 	if (!spe->timeless_decoding)
-		sample->time = speq->timestamp;
+		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
 
 	sample->ip = record->from_ip;
 	sample->cpumode = arm_spe_cpumode(spe, sample->ip);
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:45 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:45 +0800
Subject: [PATCH v3 5/6] perf arm-spe: Bail out if the trace is later than perf
 event
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-6-leo.yan@linaro.org>

It's possible that record in Arm SPE trace is later than perf event and
vice versa.  This asks to correlate the perf events and Arm SPE
synthesized events to be processed in the manner of correct timing.

To achieve the time ordering, this patch reverses the flow, it firstly
calls arm_spe_sample() and then calls arm_spe_decode().  By comparing
the timestamp value and detect the perf event is coming earlier than Arm
SPE trace data, it bails out from the decoding loop, the last record is
pushed into auxtrace stack and is deferred to generate sample.  To track
the timestamp, everytime it updates timestamp for the latest record.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index ec7df83b50fd..8facda81a06c 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -434,12 +434,36 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
 static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 {
 	struct arm_spe *spe = speq->spe;
+	struct arm_spe_record *record;
 	int ret;
 
 	if (!spe->kernel_start)
 		spe->kernel_start = machine__kernel_start(spe->machine);
 
 	while (1) {
+		/*
+		 * The usual logic is firstly to decode the packets, and then
+		 * based the record to synthesize sample; but here the flow is
+		 * reversed: it calls arm_spe_sample() for synthesizing samples
+		 * prior to arm_spe_decode().
+		 *
+		 * Two reasons for this code logic:
+		 * 1. Firstly, when setup queue in arm_spe__setup_queue(), it
+		 * has decoded trace data and generated a record, but the record
+		 * is left to generate sample until run to here, so it's correct
+		 * to synthesize sample for the left record.
+		 * 2. After decoding trace data, it needs to compare the record
+		 * timestamp with the coming perf event, if the record timestamp
+		 * is later than the perf event, it needs bail out and pushs the
+		 * record into auxtrace heap, thus the record can be deferred to
+		 * synthesize sample until run to here at the next time; so this
+		 * can correlate samples between Arm SPE trace data and other
+		 * perf events with correct time ordering.
+		 */
+		ret = arm_spe_sample(speq);
+		if (ret)
+			return ret;
+
 		ret = arm_spe_decode(speq->decoder);
 		if (!ret) {
 			pr_debug("No data or all data has been processed.\n");
@@ -453,10 +477,17 @@ static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 		if (ret < 0)
 			continue;
 
-		ret = arm_spe_sample(speq);
-		if (ret)
-			return ret;
+		record = &speq->decoder->record;
 
+		/* Update timestamp for the last record */
+		if (record->timestamp > speq->timestamp)
+			speq->timestamp = record->timestamp;
+
+		/*
+		 * If the timestamp of the queue is later than timestamp of the
+		 * coming perf event, bail out so can allow the perf event to
+		 * be processed ahead.
+		 */
 		if (!spe->timeless_decoding && speq->timestamp >= *timestamp) {
 			*timestamp = speq->timestamp;
 			return 0;
-- 
2.25.1



From leo.yan at linaro.org  Sat Apr 10 06:00:46 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 10 Apr 2021 13:00:46 +0800
Subject: [PATCH v3 6/6] perf arm-spe: Don't wait for PERF_RECORD_EXIT event
In-Reply-To: <20210410050046.5394-1-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
Message-ID: <20210410050046.5394-7-leo.yan@linaro.org>

When decode Arm SPE trace, it waits for PERF_RECORD_EXIT event (the last
perf event) for processing trace data, which is needless and even might
cause logic error, e.g. it might fail to correlate perf events with Arm
SPE events correctly.

So this patch removes the condition checking for PERF_RECORD_EXIT event.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 8facda81a06c..5e98a29fcbdb 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -717,11 +717,7 @@ static int arm_spe_process_event(struct perf_session *session,
 					sample->time);
 		}
 	} else if (timestamp) {
-		if (event->header.type == PERF_RECORD_EXIT) {
-			err = arm_spe_process_queues(spe, timestamp);
-			if (err)
-				return err;
-		}
+		err = arm_spe_process_queues(spe, timestamp);
 	}
 
 	return err;
-- 
2.25.1



From chunfeng.yun at mediatek.com  Sat Apr 10 06:10:05 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 13:10:05 +0800
Subject: [PATCH v2 4/5] usb: xhci-mtk: use clock bulk to get clocks
In-Reply-To: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1618031406-15347-4-git-send-email-chunfeng.yun@mediatek.com>

Use clock bulk helpers to get/enable/disable clocks, meanwhile
make sys_ck optional, then will be easier to handle clocks.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: no changes
---
 drivers/usb/host/xhci-mtk.c | 109 +++++++-----------------------------
 drivers/usb/host/xhci-mtk.h |  10 ++--
 2 files changed, 24 insertions(+), 95 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 30927f4064d4..d4c455eecb8d 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -7,7 +7,6 @@
  *  Chunfeng Yun <chunfeng.yun at mediatek.com>
  */
 
-#include <linux/clk.h>
 #include <linux/dma-mapping.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
@@ -220,89 +219,6 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
 	return xhci_mtk_host_enable(mtk);
 }
 
-static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
-{
-	struct device *dev = mtk->dev;
-
-	mtk->sys_clk = devm_clk_get(dev, "sys_ck");
-	if (IS_ERR(mtk->sys_clk)) {
-		dev_err(dev, "fail to get sys_ck\n");
-		return PTR_ERR(mtk->sys_clk);
-	}
-
-	mtk->xhci_clk = devm_clk_get_optional(dev, "xhci_ck");
-	if (IS_ERR(mtk->xhci_clk))
-		return PTR_ERR(mtk->xhci_clk);
-
-	mtk->ref_clk = devm_clk_get_optional(dev, "ref_ck");
-	if (IS_ERR(mtk->ref_clk))
-		return PTR_ERR(mtk->ref_clk);
-
-	mtk->mcu_clk = devm_clk_get_optional(dev, "mcu_ck");
-	if (IS_ERR(mtk->mcu_clk))
-		return PTR_ERR(mtk->mcu_clk);
-
-	mtk->dma_clk = devm_clk_get_optional(dev, "dma_ck");
-	return PTR_ERR_OR_ZERO(mtk->dma_clk);
-}
-
-static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
-{
-	int ret;
-
-	ret = clk_prepare_enable(mtk->ref_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable ref_clk\n");
-		goto ref_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->sys_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable sys_clk\n");
-		goto sys_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->xhci_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable xhci_clk\n");
-		goto xhci_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->mcu_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable mcu_clk\n");
-		goto mcu_clk_err;
-	}
-
-	ret = clk_prepare_enable(mtk->dma_clk);
-	if (ret) {
-		dev_err(mtk->dev, "failed to enable dma_clk\n");
-		goto dma_clk_err;
-	}
-
-	return 0;
-
-dma_clk_err:
-	clk_disable_unprepare(mtk->mcu_clk);
-mcu_clk_err:
-	clk_disable_unprepare(mtk->xhci_clk);
-xhci_clk_err:
-	clk_disable_unprepare(mtk->sys_clk);
-sys_clk_err:
-	clk_disable_unprepare(mtk->ref_clk);
-ref_clk_err:
-	return ret;
-}
-
-static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
-{
-	clk_disable_unprepare(mtk->dma_clk);
-	clk_disable_unprepare(mtk->mcu_clk);
-	clk_disable_unprepare(mtk->xhci_clk);
-	clk_disable_unprepare(mtk->sys_clk);
-	clk_disable_unprepare(mtk->ref_clk);
-}
-
 /* only clocks can be turn off for ip-sleep wakeup mode */
 static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk *mtk, bool enable)
 {
@@ -367,6 +283,19 @@ static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
 		usb_wakeup_ip_sleep_set(mtk, enable);
 }
 
+static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
+{
+	struct clk_bulk_data *clks = mtk->clks;
+
+	clks[0].id = "sys_ck";
+	clks[1].id = "xhci_ck";
+	clks[2].id = "ref_ck";
+	clks[3].id = "mcu_ck";
+	clks[4].id = "dma_ck";
+
+	return devm_clk_bulk_get_optional(mtk->dev, BULK_CLKS_NUM, clks);
+}
+
 static int xhci_mtk_ldos_enable(struct xhci_hcd_mtk *mtk)
 {
 	int ret;
@@ -522,7 +451,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_pm;
 
-	ret = xhci_mtk_clks_enable(mtk);
+	ret = clk_bulk_prepare_enable(BULK_CLKS_NUM, mtk->clks);
 	if (ret)
 		goto disable_ldos;
 
@@ -625,7 +554,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	usb_put_hcd(hcd);
 
 disable_clk:
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 
 disable_ldos:
 	xhci_mtk_ldos_disable(mtk);
@@ -655,7 +584,7 @@ static int xhci_mtk_remove(struct platform_device *pdev)
 	usb_put_hcd(shared_hcd);
 	usb_put_hcd(hcd);
 	xhci_mtk_sch_exit(mtk);
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 	xhci_mtk_ldos_disable(mtk);
 
 	pm_runtime_disable(dev);
@@ -682,7 +611,7 @@ static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 	if (ret)
 		goto restart_poll_rh;
 
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 	usb_wakeup_set(mtk, true);
 	return 0;
 
@@ -703,7 +632,7 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	int ret;
 
 	usb_wakeup_set(mtk, false);
-	ret = xhci_mtk_clks_enable(mtk);
+	ret = clk_bulk_prepare_enable(BULK_CLKS_NUM, mtk->clks);
 	if (ret)
 		goto enable_wakeup;
 
@@ -719,7 +648,7 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	return 0;
 
 disable_clks:
-	xhci_mtk_clks_disable(mtk);
+	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
 enable_wakeup:
 	usb_wakeup_set(mtk, true);
 	return ret;
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 621ec1a85009..11996edc1967 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -9,8 +9,12 @@
 #ifndef _XHCI_MTK_H_
 #define _XHCI_MTK_H_
 
+#include <linux/clk.h>
+
 #include "xhci.h"
 
+#define BULK_CLKS_NUM	5
+
 /**
  * To simplify scheduler algorithm, set a upper limit for ESIT,
  * if a synchromous ep's ESIT is larger than @XHCI_MTK_MAX_ESIT,
@@ -140,11 +144,7 @@ struct xhci_hcd_mtk {
 	int u3p_dis_msk;
 	struct regulator *vusb33;
 	struct regulator *vbus;
-	struct clk *sys_clk;	/* sys and mac clock */
-	struct clk *xhci_clk;
-	struct clk *ref_clk;
-	struct clk *mcu_clk;
-	struct clk *dma_clk;
+	struct clk_bulk_data clks[BULK_CLKS_NUM];
 	struct regmap *pericfg;
 	struct phy **phys;
 	int num_phys;
-- 
2.18.0

From chunfeng.yun at mediatek.com  Sat Apr 10 06:10:03 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 13:10:03 +0800
Subject: [PATCH v2 2/5] dt-bindings: usb: mtk-xhci: add wakeup interrupt
In-Reply-To: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1618031406-15347-2-git-send-email-chunfeng.yun@mediatek.com>

Add an interrupt which is EINT usually to support runtime PM,
meanwhile add "interrupt-names" property, for backward
compatibility, it's optional and used when wakeup interrupt
exists

Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: add Reviewed-by Rob
---
 .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml  | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
index 45bf4ea00c9e..4fe8a301d03f 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
@@ -46,7 +46,18 @@ properties:
       - const: ippc  # optional, only needed for case 1.
 
   interrupts:
-    maxItems: 1
+    description:
+      use "interrupts-extended" when the interrupts are connected to the
+      separate interrupt controllers
+    minItems: 1
+    items:
+      - description: xHCI host controller interrupt
+      - description: optional, wakeup interrupt used to support runtime PM
+
+  interrupt-names:
+    items:
+      - const: host
+      - const: wakeup
 
   power-domains:
     description: A phandle to USB power domain node to control USB's MTCMOS
-- 
2.18.0

From chunfeng.yun at mediatek.com  Sat Apr 10 06:10:04 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 13:10:04 +0800
Subject: [PATCH v2 3/5] usb: xhci-mtk: add support runtime PM
In-Reply-To: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1618031406-15347-3-git-send-email-chunfeng.yun@mediatek.com>

A dedicated wakeup irq will be used to handle runtime suspend/resume,
we use dev_pm_set_dedicated_wake_irq API to take care of requesting
and attaching wakeup irq, then the suspend/resume framework will help
to enable/disable wakeup irq.

The runtime PM is default off since some platforms may not support it.
users can enable it via power/control (set "auto") in sysfs.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: no changes, but abandon dependent patch [1], use falling edge type
    interrupt

[1]
[1/6] PM: runtime: enable wake irq after runtime_suspend hook called

https://patchwork.kernel.org/project/linux-mediatek/patch/1617874514-12282-1-git-send-email-chunfeng.yun at mediatek.com/
---
 drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
 1 file changed, 124 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index a74764ab914a..30927f4064d4 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -16,6 +16,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
+#include <linux/pm_wakeirq.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 
@@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
 			mtk->uwk_reg_base, mtk->uwk_vers);
 
 	return PTR_ERR_OR_ZERO(mtk->uwk);
-
 }
 
 static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
@@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct usb_hcd *hcd;
 	int ret = -ENODEV;
+	int wakeup_irq;
 	int irq;
 
 	if (usb_disabled())
@@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	irq = platform_get_irq_byname_optional(pdev, "host");
+	if (irq < 0) {
+		if (irq == -EPROBE_DEFER)
+			return irq;
+
+		/* for backward compatibility */
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0)
+			return irq;
+	}
+
+	wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
+	if (wakeup_irq == -EPROBE_DEFER)
+		return wakeup_irq;
+
 	mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
 	/* optional property, ignore the error if it does not exist */
 	of_property_read_u32(node, "mediatek,u3p-dis-msk",
@@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	pm_runtime_set_active(dev);
+	pm_runtime_use_autosuspend(dev);
+	pm_runtime_set_autosuspend_delay(dev, 4000);
 	pm_runtime_enable(dev);
 	pm_runtime_get_sync(dev);
-	device_enable_async_suspend(dev);
 
 	ret = xhci_mtk_ldos_enable(mtk);
 	if (ret)
@@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto disable_ldos;
 
-	irq = platform_get_irq(pdev, 0);
-	if (irq < 0) {
-		ret = irq;
-		goto disable_clk;
-	}
-
 	hcd = usb_create_hcd(driver, dev, dev_name(dev));
 	if (!hcd) {
 		ret = -ENOMEM;
@@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	if (ret)
 		goto dealloc_usb2_hcd;
 
+	if (wakeup_irq > 0) {
+		ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
+		if (ret) {
+			dev_err(dev, "set wakeup irq %d failed\n", wakeup_irq);
+			goto dealloc_usb3_hcd;
+		}
+		dev_info(dev, "wakeup irq %d\n", wakeup_irq);
+	}
+
+	device_enable_async_suspend(dev);
+	pm_runtime_mark_last_busy(dev);
+	pm_runtime_put_autosuspend(dev);
+	pm_runtime_forbid(dev);
+
 	return 0;
 
+dealloc_usb3_hcd:
+	usb_remove_hcd(xhci->shared_hcd);
+	xhci->shared_hcd = NULL;
+
 dealloc_usb2_hcd:
 	usb_remove_hcd(hcd);
 
@@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 	xhci_mtk_ldos_disable(mtk);
 
 disable_pm:
-	pm_runtime_put_sync(dev);
+	pm_runtime_put_sync_autosuspend(dev);
 	pm_runtime_disable(dev);
 	return ret;
 }
 
-static int xhci_mtk_remove(struct platform_device *dev)
+static int xhci_mtk_remove(struct platform_device *pdev)
 {
-	struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
+	struct xhci_hcd_mtk *mtk = platform_get_drvdata(pdev);
 	struct usb_hcd	*hcd = mtk->hcd;
 	struct xhci_hcd	*xhci = hcd_to_xhci(hcd);
 	struct usb_hcd  *shared_hcd = xhci->shared_hcd;
+	struct device *dev = &pdev->dev;
 
-	pm_runtime_put_noidle(&dev->dev);
-	pm_runtime_disable(&dev->dev);
+	pm_runtime_get_sync(dev);
+	xhci->xhc_state |= XHCI_STATE_REMOVING;
+	dev_pm_clear_wake_irq(dev);
+	device_init_wakeup(dev, false);
 
 	usb_remove_hcd(shared_hcd);
 	xhci->shared_hcd = NULL;
-	device_init_wakeup(&dev->dev, false);
-
 	usb_remove_hcd(hcd);
 	usb_put_hcd(shared_hcd);
 	usb_put_hcd(hcd);
@@ -627,6 +658,10 @@ static int xhci_mtk_remove(struct platform_device *dev)
 	xhci_mtk_clks_disable(mtk);
 	xhci_mtk_ldos_disable(mtk);
 
+	pm_runtime_disable(dev);
+	pm_runtime_put_noidle(dev);
+	pm_runtime_set_suspended(dev);
+
 	return 0;
 }
 
@@ -690,10 +725,83 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	return ret;
 }
 
+static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
+{
+	u32 suspended_ports;
+	u32 status;
+	int num_ports;
+	int i;
+
+	num_ports = rhub->num_ports;
+	suspended_ports = rhub->bus_state.suspended_ports;
+	for (i = 0; i < num_ports; i++) {
+		if (!(suspended_ports & BIT(i))) {
+			status = readl(rhub->ports[i]->addr);
+			if (status & PORT_CONNECT)
+				return -EBUSY;
+		}
+	}
+
+	return 0;
+}
+
+/*
+ * check the bus whether it could suspend or not
+ * the bus will suspend if the downstream ports are already suspended,
+ * or no devices connected.
+ */
+static int check_bus_status(struct xhci_hcd *xhci)
+{
+	int ret;
+
+	ret = check_rhub_status(xhci, &xhci->usb3_rhub);
+	if (ret)
+		return ret;
+
+	return check_rhub_status(xhci, &xhci->usb2_rhub);
+}
+
+static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
+{
+	struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
+	struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+	int ret = 0;
+
+	if (xhci->xhc_state)
+		return -ESHUTDOWN;
+
+	if (device_may_wakeup(dev)) {
+		ret = check_bus_status(xhci);
+		if (!ret)
+			ret = xhci_mtk_suspend(dev);
+	}
+
+	/* -EBUSY: let PM automatically reschedule another autosuspend */
+	return ret ? -EBUSY : 0;
+}
+
+static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
+{
+	struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
+	struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+	int ret = 0;
+
+	if (xhci->xhc_state)
+		return -ESHUTDOWN;
+
+	if (device_may_wakeup(dev))
+		ret = xhci_mtk_resume(dev);
+
+	return ret;
+}
+
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
+	SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
+			   xhci_mtk_runtime_resume, NULL)
 };
-#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
+
+#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
 
 static const struct of_device_id mtk_xhci_of_match[] = {
 	{ .compatible = "mediatek,mt8173-xhci"},
-- 
2.18.0

From chunfeng.yun at mediatek.com  Sat Apr 10 06:10:02 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 13:10:02 +0800
Subject: [PATCH v2 1/5] usb: xhci-mtk: check return value in suspend/resume
 hooks
Message-ID: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>

Return error number if encounter errors during suspend and resume.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: no changes
---
 drivers/usb/host/xhci-mtk.c | 37 +++++++++++++++++++++++++++----------
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c1bc40289833..a74764ab914a 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -630,18 +630,12 @@ static int xhci_mtk_remove(struct platform_device *dev)
 	return 0;
 }
 
-/*
- * if ip sleep fails, and all clocks are disabled, access register will hang
- * AHB bus, so stop polling roothubs to avoid regs access on bus suspend.
- * and no need to check whether ip sleep failed or not; this will cause SPM
- * to wake up system immediately after system suspend complete if ip sleep
- * fails, it is what we wanted.
- */
 static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 {
 	struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
 	struct usb_hcd *hcd = mtk->hcd;
 	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+	int ret;
 
 	xhci_dbg(xhci, "%s: stop port polling\n", __func__);
 	clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
@@ -649,10 +643,21 @@ static int __maybe_unused xhci_mtk_suspend(struct device *dev)
 	clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
 	del_timer_sync(&xhci->shared_hcd->rh_timer);
 
-	xhci_mtk_host_disable(mtk);
+	ret = xhci_mtk_host_disable(mtk);
+	if (ret)
+		goto restart_poll_rh;
+
 	xhci_mtk_clks_disable(mtk);
 	usb_wakeup_set(mtk, true);
 	return 0;
+
+restart_poll_rh:
+	xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+	set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
+	usb_hcd_poll_rh_status(xhci->shared_hcd);
+	set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
+	usb_hcd_poll_rh_status(hcd);
+	return ret;
 }
 
 static int __maybe_unused xhci_mtk_resume(struct device *dev)
@@ -660,10 +665,16 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
 	struct usb_hcd *hcd = mtk->hcd;
 	struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+	int ret;
 
 	usb_wakeup_set(mtk, false);
-	xhci_mtk_clks_enable(mtk);
-	xhci_mtk_host_enable(mtk);
+	ret = xhci_mtk_clks_enable(mtk);
+	if (ret)
+		goto enable_wakeup;
+
+	ret = xhci_mtk_host_enable(mtk);
+	if (ret)
+		goto disable_clks;
 
 	xhci_dbg(xhci, "%s: restart port polling\n", __func__);
 	set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags);
@@ -671,6 +682,12 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
 	usb_hcd_poll_rh_status(hcd);
 	return 0;
+
+disable_clks:
+	xhci_mtk_clks_disable(mtk);
+enable_wakeup:
+	usb_wakeup_set(mtk, true);
+	return ret;
 }
 
 static const struct dev_pm_ops xhci_mtk_pm_ops = {
-- 
2.18.0

From chunfeng.yun at mediatek.com  Sat Apr 10 06:10:06 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Sat, 10 Apr 2021 13:10:06 +0800
Subject: [PATCH v2 5/5] usb: xhci-mtk: remove unused members
In-Reply-To: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1618031406-15347-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <1618031406-15347-5-git-send-email-chunfeng.yun@mediatek.com>

Now some members about phys and wakeup are not used anymore,
remove them.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
v2: no changes
---
 drivers/usb/host/xhci-mtk.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 11996edc1967..7940593a3445 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -145,9 +145,6 @@ struct xhci_hcd_mtk {
 	struct regulator *vusb33;
 	struct regulator *vbus;
 	struct clk_bulk_data clks[BULK_CLKS_NUM];
-	struct regmap *pericfg;
-	struct phy **phys;
-	int num_phys;
 	bool lpm_support;
 	/* usb remote wakeup */
 	bool uwk_en;
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 06:28:34 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 13:28:34 +0800
Subject: [PATCH] iommu/mediatek: always enable the clk on resume
In-Reply-To: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
References: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
Message-ID: <1618032514.26944.20.camel@mhfsdcap03>

On Thu, 2021-04-08 at 14:28 +0200, Dafna Hirschfeld wrote:
> In mtk_iommu_runtime_resume always enable the clk, even
> if m4u_dom is null. Otherwise the 'suspend' cb might
> disable the clk which is already disabled causing the warning:

Hi Dafna,

Thanks very much for testing and report. I have reproduced this issue
locally. It happened when iommu probe before than smi-common(iommu is
the supplier in the dev-link).

I put clk_prepare_enable in the _hw_init since I have plan to remove the
pm_runtime_get/put in the _attach_device(This will turn off the display
power domain if we show fastlogo at that time.) May be we should keep
the smi-common probe always before than iommu.

Anyway, This patch makes code symmetrical and it is good for now.

Reviewed-by: Yong Wu <yong.wu at mediatek.com>

> 
> [    1.586104] infra_m4u already disabled
> [    1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
> [    1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
> [    1.598108] Modules linked in:
> [    1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
> [    1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
> [    1.617487] Hardware name: Google Elm (DT)
> [    1.617491] Workqueue: pm pm_runtime_work
> [    1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)
> 
> [    1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
> [    1.659297] pc : clk_core_disable+0xb0/0xb8
> [    1.663475] lr : clk_core_disable+0xb0/0xb8
> [    1.667652] sp : ffff800011b9bbe0
> [    1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
> [    1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
> [    1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
> [    1.686882] x23: 0000000000000000 x22: ffff8000106fad90
> [    1.692189] x21: 000000000000000a x20: ffff0000c0048500
> [    1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
> [    1.702804] x17: 0000000000000000 x16: 0000000000000000
> [    1.708112] x15: ffff800011460300 x14: fffffffffffe0000
> [    1.713420] x13: ffff8000114602d8 x12: 0720072007200720
> [    1.718727] x11: 0720072007200720 x10: 0720072007200720
> [    1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
> [    1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
> [    1.734649] x5 : 0000000000000000 x4 : 0000000000000000
> [    1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
> [    1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
> [    1.750572] Call trace:
> [    1.753010]  clk_core_disable+0xb0/0xb8
> [    1.756840]  clk_core_disable_lock+0x24/0x40
> [    1.761105]  clk_disable+0x20/0x30
> [    1.764501]  mtk_iommu_runtime_suspend+0x88/0xa8
> [    1.769114]  pm_generic_runtime_suspend+0x2c/0x48
> [    1.773815]  __rpm_callback+0xe0/0x178
> [    1.777559]  rpm_callback+0x24/0x88
> [    1.781041]  rpm_suspend+0xdc/0x470
> [    1.784523]  rpm_idle+0x12c/0x170
> [    1.787831]  pm_runtime_work+0xa8/0xc0
> [    1.791573]  process_one_work+0x1e8/0x360
> [    1.795580]  worker_thread+0x44/0x478
> [    1.799237]  kthread+0x150/0x158
> [    1.802460]  ret_from_fork+0x10/0x30
> [    1.806034] ---[ end trace 82402920ef64573b ]---
> [    1.810728] ------------[ cut here ]------------
> 
> In addition, we now don't need to enable the clock from the
> function mtk_iommu_hw_init since it is already enabled by the resume.
> 
> Fixes: commit c0b57581b73b ("iommu/mediatek: Add power-domain operation")
> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld at collabora.com>
> ---
>  drivers/iommu/mtk_iommu.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 6ecc007f07cd..e168a682806a 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -688,13 +688,6 @@ static const struct iommu_ops mtk_iommu_ops = {
>  static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>  {
>  	u32 regval;
> -	int ret;
> -
> -	ret = clk_prepare_enable(data->bclk);
> -	if (ret) {
> -		dev_err(data->dev, "Failed to enable iommu bclk(%d)\n", ret);
> -		return ret;
> -	}
>  
>  	if (data->plat_data->m4u_plat == M4U_MT8173) {
>  		regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> @@ -760,7 +753,6 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>  	if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
>  			     dev_name(data->dev), (void *)data)) {
>  		writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
> -		clk_disable_unprepare(data->bclk);
>  		dev_err(data->dev, "Failed @ IRQ-%d Request\n", data->irq);
>  		return -ENODEV;
>  	}
> @@ -977,14 +969,19 @@ static int __maybe_unused mtk_iommu_runtime_resume(struct device *dev)
>  	void __iomem *base = data->base;
>  	int ret;
>  
> -	/* Avoid first resume to affect the default value of registers below. */
> -	if (!m4u_dom)
> -		return 0;
>  	ret = clk_prepare_enable(data->bclk);
>  	if (ret) {
>  		dev_err(data->dev, "Failed to enable clk(%d) in resume\n", ret);
>  		return ret;
>  	}
> +
> +	/*
> +	 * Uppon first resume, only enable the clk and return, since the values of the
> +	 * registers are not yet set.
> +	 */
> +	if (!m4u_dom)
> +		return 0;
> +
>  	writel_relaxed(reg->wr_len_ctrl, base + REG_MMU_WR_LEN_CTRL);
>  	writel_relaxed(reg->misc_ctrl, base + REG_MMU_MISC_CTRL);
>  	writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);


From brouer at redhat.com  Sat Apr 10 07:21:58 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Sat, 10 Apr 2021 08:21:58 +0200
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <20210410024313.GX2531743@casper.infradead.org>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
Message-ID: <20210410082158.79ad09a6@carbon>

On Sat, 10 Apr 2021 03:43:13 +0100
Matthew Wilcox <willy at infradead.org> wrote:

> On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel test robot wrote:
> > >> include/linux/mm_types.h:274:1: error: static_assert failed due to requirement '__builtin_offsetof(struct page, lru) == __builtin_offsetof(struct folio, lru)' "offsetof(struct page, lru) == offsetof(struct folio, lru)"  
> >    FOLIO_MATCH(lru, lru);
> >    include/linux/mm_types.h:272:2: note: expanded from macro 'FOLIO_MATCH'
> >            static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))  
> 
> Well, this is interesting.  pahole reports:
> 
> struct page {
>         long unsigned int          flags;                /*     0     4 */
>         /* XXX 4 bytes hole, try to pack */
>         union {
>                 struct {
>                         struct list_head lru;            /*     8     8 */
> ...
> struct folio {
>         union {
>                 struct {
>                         long unsigned int flags;         /*     0     4 */
>                         struct list_head lru;            /*     4     8 */
> 
> so this assert has absolutely done its job.
> 
> But why has this assert triggered?  Why is struct page layout not what
> we thought it was?  Turns out it's the dma_addr added in 2019 by commit
> c25fff7171be ("mm: add dma_addr_t to struct page").  On this particular
> config, it's 64-bit, and ppc32 requires alignment to 64-bit.  So
> the whole union gets moved out by 4 bytes.

Argh, good that you are catching this!

> Unfortunately, we can't just fix this by putting an 'unsigned long pad'
> in front of it.  It still aligns the entire union to 8 bytes, and then
> it skips another 4 bytes after the pad.
> 
> We can fix it like this ...
> 
> +++ b/include/linux/mm_types.h
> @@ -96,11 +96,12 @@ struct page {
>                         unsigned long private;
>                 };
>                 struct {        /* page_pool used by netstack */
> +                       unsigned long _page_pool_pad;

I'm fine with this pad.  Matteo is currently proposing[1] to add a 32-bit
value after @dma_addr, and he could use this area instead.

[1] https://lore.kernel.org/netdev/20210409223801.104657-3-mcroce at linux.microsoft.com/

When adding/changing this, we need to make sure that it doesn't overlap
member @index, because network stack use/check page_is_pfmemalloc().
As far as my calculations this is safe to add.  I always try to keep an
eye out for this, but I wonder if we could have a build check like yours.


>                         /**
>                          * @dma_addr: might require a 64-bit value even on
>                          * 32-bit architectures.
>                          */
> -                       dma_addr_t dma_addr;
> +                       dma_addr_t dma_addr __packed;
>                 };
>                 struct {        /* slab, slob and slub */
>                         union {
> 
> but I don't know if GCC is smart enough to realise that dma_addr is now
> on an 8 byte boundary and it can use a normal instruction to access it,
> or whether it'll do something daft like use byte loads to access it.
> 
> We could also do:
> 
> +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));
> 
> and I see pahole, at least sees this correctly:
> 
>                 struct {
>                         long unsigned int _page_pool_pad; /*     4     4 */
>                         dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
>                 } __attribute__((__packed__)) __attribute__((__aligned__(4)));  
> 
> This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> / dma_addr_t.  Advice, please?

I'm not sure that the 32-bit behavior is with 64-bit (dma) addrs.

I don't have any 32-bit boards with 64-bit DMA.  Cc. Ivan, wasn't your
board (572x ?) 32-bit with driver 'cpsw' this case (where Ivan added
XDP+page_pool) ?

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer



From wanjiabing at vivo.com  Sat Apr 10 08:40:00 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Sat, 10 Apr 2021 15:40:00 +0800
Subject: [PATCH] drm/nouveau/nvkm: Remove unnecessary assignment
Message-ID: <20210410074012.1258923-1-wanjiabing@vivo.com>

The declaration with assignment here is confusing.
Remove the unnecessary assignment.

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
index 96aca0edfa3c..c51bac76174c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c
@@ -313,7 +313,7 @@ nv50_instobj_dtor(struct nvkm_memory *memory)
 	struct nv50_instobj *iobj = nv50_instobj(memory);
 	struct nvkm_instmem *imem = &iobj->imem->base;
 	struct nvkm_vma *bar;
-	void *map = map;
+	void *map;
 
 	mutex_lock(&imem->mutex);
 	if (likely(iobj->lru.next))
-- 
2.25.1



From zhangshaokun at hisilicon.com  Sat Apr 10 09:16:37 2021
From: zhangshaokun at hisilicon.com (Shaokun Zhang)
Date: Sat, 10 Apr 2021 16:16:37 +0800
Subject: [RFC] KVM: arm64: Support FEAT_CCIDX
Message-ID: <1618042597-59294-1-git-send-email-zhangshaokun@hisilicon.com>

CCSIDR_EL1 can be implemented as 64-bit format inferred by CCIDX field
in ID_AA64MMFR2_EL1. The bits of Numsets and Associativity are different
from the 32-bit format. Let's support this feature.

Cc: Marc Zyngier <maz at kernel.org>
Cc: James Morse <james.morse at arm.com>
Cc: Alexandru Elisei <alexandru.elisei at arm.com>
Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun at hisilicon.com>
---
 arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 52fdb9a015a4..0dc822cef20b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -18,6 +18,7 @@
 
 #include <asm/cacheflush.h>
 #include <asm/cputype.h>
+#include <asm/cpufeature.h>
 #include <asm/debug-monitors.h>
 #include <asm/esr.h>
 #include <asm/kvm_arm.h>
@@ -95,9 +96,9 @@ static u32 cache_levels;
 #define CSSELR_MAX 14
 
 /* Which cache CCSIDR represents depends on CSSELR value. */
-static u32 get_ccsidr(u32 csselr)
+static u64 get_ccsidr(u32 csselr)
 {
-	u32 ccsidr;
+	u64 ccsidr;
 
 	/* Make sure noone else changes CSSELR during this! */
 	local_irq_disable();
@@ -1275,12 +1276,16 @@ static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 			  const struct sys_reg_desc *r)
 {
-	u32 csselr;
+	u32 csselr, ccidx;
+	u64 mmfr2;
 
 	if (p->is_write)
 		return write_to_read_only(vcpu, p, r);
 
 	csselr = vcpu_read_sys_reg(vcpu, CSSELR_EL1);
+	mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
+	ccidx = cpuid_feature_extract_unsigned_field(mmfr2,
+						     ID_AA64MMFR2_CCIDX_SHIFT);
 	p->regval = get_ccsidr(csselr);
 
 	/*
@@ -1295,8 +1300,13 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	 * geometry (which is not permitted by the architecture), they would
 	 * only do so for virtually indexed caches.]
 	 */
-	if (!(csselr & 1)) // data or unified cache
-		p->regval &= ~GENMASK(27, 3);
+	if (!(csselr & 1)) { // data or unified cache
+		if (ccidx)
+			p->regval &= ~(GENMASK(23, 3) | GENMASK(55, 32));
+		else
+			p->regval &= ~GENMASK(27, 3);
+	}
+
 	return true;
 }
 
@@ -2521,7 +2531,7 @@ static bool is_valid_cache(u32 val)
 static int demux_c15_get(u64 id, void __user *uaddr)
 {
 	u32 val;
-	u32 __user *uval = uaddr;
+	u64 __user *uval = uaddr;
 
 	/* Fail if we have unknown bits set. */
 	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
@@ -2545,8 +2555,9 @@ static int demux_c15_get(u64 id, void __user *uaddr)
 
 static int demux_c15_set(u64 id, void __user *uaddr)
 {
-	u32 val, newval;
-	u32 __user *uval = uaddr;
+	u32 val;
+	u64 newval;
+	u64 __user *uval = uaddr;
 
 	/* Fail if we have unknown bits set. */
 	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
-- 
2.7.4



From lkp at intel.com  Sat Apr 10 09:19:33 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:19:33 +0800
Subject: [xlnx:master 271/274]
 drivers/misc/xilinx-ai-engine/ai-engine-part.c:302:32: warning: passing
 argument 2 of 'copy_from_user' makes pointer from integer without a cast
Message-ID: <202104101628.BJAzxVdL-lkp@intel.com>

Hi Tejus,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx master
head:   11fb963a44f50af56ff7017fe808ff83b3ae4716
commit: d3774573d5a9700273bd0c3ff82af157107f7fa6 [271/274] misc: xilinx-ai-engine: transaction mode ioctl
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/d3774573d5a9700273bd0c3ff82af157107f7fa6
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout d3774573d5a9700273bd0c3ff82af157107f7fa6
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/misc/xilinx-ai-engine/ai-engine-part.c: In function 'aie_part_access_regs':
>> drivers/misc/xilinx-ai-engine/ai-engine-part.c:302:32: warning: passing argument 2 of 'copy_from_user' makes pointer from integer without a cast [-Wint-conversion]
     302 |    if (copy_from_user(tmp, args->dataptr, sizeof(u32) *
         |                            ~~~~^~~~~~~~~
         |                                |
         |                                __u64 {aka long long unsigned int}
   In file included from include/linux/sched/task.h:11,
                    from include/linux/sched/signal.h:9,
                    from include/linux/ptrace.h:7,
                    from arch/arm64/include/asm/kgdb.h:14,
                    from include/linux/kgdb.h:20,
                    from arch/arm64/include/asm/cacheflush.h:11,
                    from arch/arm64/include/asm/mmu_context.h:18,
                    from include/linux/mmu_context.h:5,
                    from drivers/misc/xilinx-ai-engine/ai-engine-part.c:17:
   include/linux/uaccess.h:141:45: note: expected 'const void *' but argument is of type '__u64' {aka 'long long unsigned int'}
     141 | copy_from_user(void *to, const void __user *from, unsigned long n)
         |                          ~~~~~~~~~~~~~~~~~~~^~~~
   drivers/misc/xilinx-ai-engine/ai-engine-part.c: In function 'aie_part_execute_transaction_from_user':
   drivers/misc/xilinx-ai-engine/ai-engine-part.c:365:35: warning: passing argument 2 of 'copy_from_user' makes pointer from integer without a cast [-Wint-conversion]
     365 |  if (copy_from_user(cmds, txn_inst.cmdsptr,
         |                           ~~~~~~~~^~~~~~~~
         |                                   |
         |                                   __u64 {aka long long unsigned int}
   In file included from include/linux/sched/task.h:11,
                    from include/linux/sched/signal.h:9,
                    from include/linux/ptrace.h:7,
                    from arch/arm64/include/asm/kgdb.h:14,
                    from include/linux/kgdb.h:20,
                    from arch/arm64/include/asm/cacheflush.h:11,
                    from arch/arm64/include/asm/mmu_context.h:18,
                    from include/linux/mmu_context.h:5,
                    from drivers/misc/xilinx-ai-engine/ai-engine-part.c:17:
   include/linux/uaccess.h:141:45: note: expected 'const void *' but argument is of type '__u64' {aka 'long long unsigned int'}
     141 | copy_from_user(void *to, const void __user *from, unsigned long n)
         |                          ~~~~~~~~~~~~~~~~~~~^~~~


vim +/copy_from_user +302 drivers/misc/xilinx-ai-engine/ai-engine-part.c

   262	
   263	/**
   264	 * aie_part_access_regs() - AI engine partition registers access
   265	 * @apart: AI engine partition
   266	 * @num_reqs: number of access requests
   267	 * @reqs: array of registers access
   268	 * @return: 0 for success, and negative value for failure.
   269	 *
   270	 * This function executes AI engine partition register access requests.
   271	 */
   272	static int aie_part_access_regs(struct aie_partition *apart, u32 num_reqs,
   273					struct aie_reg_args *reqs)
   274	{
   275		u32 i;
   276	
   277		for (i = 0; i < num_reqs; i++) {
   278			struct aie_reg_args *args = &reqs[i];
   279			int ret;
   280	
   281			switch (args->op) {
   282			case AIE_REG_WRITE:
   283			{
   284				ret = aie_part_write_register(apart,
   285							      (size_t)args->offset,
   286							      sizeof(args->val),
   287							      &args->val, args->mask);
   288				break;
   289			}
   290			case AIE_REG_BLOCKWRITE:
   291			{
   292				u32 *tmp;
   293	
   294				/*
   295				 * TODO: replace copy_from_user by pinning the user
   296				 * page for performance improvement.
   297				 */
   298				tmp = kcalloc(args->len, sizeof(u32), GFP_KERNEL);
   299				if (!tmp)
   300					return -ENOMEM;
   301	
 > 302				if (copy_from_user(tmp, args->dataptr, sizeof(u32) *
   303							args->len)) {
   304					kfree(tmp);
   305					return -EFAULT;
   306				}
   307	
   308				ret = aie_part_write_register(apart,
   309							      (size_t)args->offset,
   310							      sizeof(u32) * args->len,
   311							      tmp, args->mask);
   312				kfree(tmp);
   313				break;
   314			}
   315			case AIE_REG_BLOCKSET:
   316			{
   317				ret = aie_part_block_set(apart, args);
   318				break;
   319			}
   320			default:
   321				dev_err(&apart->dev,
   322					"Invalid register command type: %u.\n",
   323					args->op);
   324				return -EINVAL;
   325			}
   326	
   327			if (ret < 0) {
   328				dev_err(&apart->dev, "reg op %u failed: 0x%llx.\n",
   329					args->op, args->offset);
   330				return ret;
   331			}
   332		}
   333	
   334		return 0;
   335	}
   336	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 68674 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210410/4fcabb01/attachment-0001.gz>

From robert.jarzmik at free.fr  Sat Apr 10 09:15:15 2021
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 10 Apr 2021 10:15:15 +0200
Subject: [PATCH] ARM: pxa: mainstone: avoid -Woverride-init warning
In-Reply-To: <161727243811.583633.1536328285829233051.b4-ty@arndb.de> (Arnd
 Bergmann's message of "Thu, 1 Apr 2021 12:23:29 +0200")
References: <20210323130849.2362001-1-arnd@kernel.org>
 <161727243811.583633.1536328285829233051.b4-ty@arndb.de>
Message-ID: <87im4utv1o.fsf@belgarion.home>

Arnd Bergmann <arnd at kernel.org> writes:

> From: Arnd Bergmann <arnd at arndb.de>
>
> On Tue, 23 Mar 2021 14:08:27 +0100, Arnd Bergmann wrote:
>> The default initializer at the start of the array causes a warning
>> when building with W=1:
>> 
>> In file included from arch/arm/mach-pxa/mainstone.c:47:
>> arch/arm/mach-pxa/mainstone.h:124:33: error: initialized field overwritten [-Werror=override-init]
>>   124 | #define MAINSTONE_IRQ(x)        (MAINSTONE_NR_IRQS + (x))
>>       |                                 ^
>> arch/arm/mach-pxa/mainstone.h:133:33: note: in expansion of macro 'MAINSTONE_IRQ'
>>   133 | #define MAINSTONE_S0_CD_IRQ     MAINSTONE_IRQ(9)
>>       |                                 ^~~~~~~~~~~~~
>> arch/arm/mach-pxa/mainstone.c:506:15: note: in expansion of macro 'MAINSTONE_S0_CD_IRQ'
>>   506 |         [5] = MAINSTONE_S0_CD_IRQ,
>>       |               ^~~~~~~~~~~~~~~~~~~
>> 
>> [...]
>
> Applied to arm/fixes.
Too late, but ...
Acked-by: Robert Jarzmik <robert.jarzmik at free.fr>

Cheers.

-- 
Robert


From lkp at intel.com  Sat Apr 10 09:46:33 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:33 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 db7a033f2b1f54c46244efe54687fe8f4b9b7c21
Message-ID: <607165e9.BmvvbMxQ0N73+Tm9%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: db7a033f2b1f54c46244efe54687fe8f4b9b7c21  Merge tag 'amlogic-dt64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/dt

elapsed time: 724m

configs tested: 152
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
openrisc                 simple_smp_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
csky                                defconfig
i386                                defconfig
arm                        vexpress_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:36 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:36 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 30be8446db39be8dc52fc8cd2cb601d3d6319e9d
Message-ID: <607165ec.mPu73YkCEFmey+bm%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: 30be8446db39be8dc52fc8cd2cb601d3d6319e9d  Merge tag 'qcom-drivers-for-5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers

elapsed time: 725m

configs tested: 132
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allyesconfig
i386                             allyesconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
sh                        dreamcast_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
arm                          badge4_defconfig
openrisc                 simple_smp_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
mips                malta_kvm_guest_defconfig
arm                        multi_v5_defconfig
sh                           se7619_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
arm                        vexpress_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:31 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:31 +0800
Subject: [soc:qcom/drivers-2] BUILD SUCCESS
 0648c55e3a21ccd816e99b6600d6199fbf39d23a
Message-ID: <607165e7.wcPfNBuo38jd3Vpz%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/drivers-2
branch HEAD: 0648c55e3a21ccd816e99b6600d6199fbf39d23a  soc: qcom: mdt_loader: Detect truncated read of segments

elapsed time: 723m

configs tested: 161
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
powerpc                   bluestone_defconfig
mips                      loongson3_defconfig
m68k                          multi_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
csky                                defconfig
i386                                defconfig
arm                        vexpress_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:29 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:29 +0800
Subject: [soc:amlogic/dt64-2] BUILD SUCCESS
 412c8fa8c3748cc0500b4c86a47dd28254f015f1
Message-ID: <607165e5.7Vu8PvhsO/4FbFmH%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git amlogic/dt64-2
branch HEAD: 412c8fa8c3748cc0500b4c86a47dd28254f015f1  arm64: dts: meson: add GPIO line names to ODROID N2/N2+

elapsed time: 3751m

configs tested: 354
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                         hackkit_defconfig
arm                           u8500_defconfig
mips                       bmips_be_defconfig
arm                           h5000_defconfig
mips                      loongson3_defconfig
ia64                             allyesconfig
arm                         lpc18xx_defconfig
arc                         haps_hs_defconfig
riscv                            alldefconfig
powerpc                     mpc83xx_defconfig
openrisc                 simple_smp_defconfig
mips                         rt305x_defconfig
um                                allnoconfig
sh                          urquell_defconfig
sh                            titan_defconfig
arm                             ezx_defconfig
arm                        oxnas_v6_defconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
powerpc                    amigaone_defconfig
arc                      axs103_smp_defconfig
mips                        bcm47xx_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
arc                          axs101_defconfig
powerpc                      chrp32_defconfig
arm                        keystone_defconfig
alpha                            allyesconfig
sh                            shmin_defconfig
mips                           ci20_defconfig
mips                        maltaup_defconfig
mips                         mpc30x_defconfig
arm                        cerfcube_defconfig
xtensa                  cadence_csp_defconfig
m68k                             allyesconfig
powerpc                     akebono_defconfig
arm                     eseries_pxa_defconfig
arm                            pleb_defconfig
m68k                         amcore_defconfig
sparc                       sparc32_defconfig
powerpc                     ppa8548_defconfig
xtensa                         virt_defconfig
arm                         lubbock_defconfig
powerpc                     tqm8555_defconfig
s390                             alldefconfig
sh                           se7619_defconfig
powerpc                 mpc836x_mds_defconfig
m68k                        m5307c3_defconfig
m68k                       m5208evb_defconfig
mips                malta_qemu_32r6_defconfig
sh                           se7712_defconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
powerpc                      ppc44x_defconfig
arm                  colibri_pxa300_defconfig
m68k                         apollo_defconfig
sh                          r7785rp_defconfig
powerpc                      pmac32_defconfig
mips                       lemote2f_defconfig
mips                           ip28_defconfig
sh                               alldefconfig
powerpc               mpc834x_itxgp_defconfig
sh                             espt_defconfig
arm                         bcm2835_defconfig
arm                            hisi_defconfig
arm                         assabet_defconfig
mips                            e55_defconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                   currituck_defconfig
sh                            hp6xx_defconfig
arc                     nsimosci_hs_defconfig
arm                        clps711x_defconfig
openrisc                  or1klitex_defconfig
sh                ecovec24-romimage_defconfig
mips                         cobalt_defconfig
m68k                        m5407c3_defconfig
arm                            lart_defconfig
arm                           spitz_defconfig
arm                         palmz72_defconfig
arm                         lpc32xx_defconfig
ia64                             alldefconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                 mpc836x_rdk_defconfig
arm                         socfpga_defconfig
mips                      malta_kvm_defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                 mpc832x_mds_defconfig
powerpc                      ppc6xx_defconfig
sh                   sh7770_generic_defconfig
sh                           sh2007_defconfig
nios2                         3c120_defconfig
powerpc                    klondike_defconfig
powerpc64                           defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arm                         at91_dt_defconfig
powerpc                 mpc8272_ads_defconfig
arm                          collie_defconfig
sh                          r7780mp_defconfig
m68k                        mvme16x_defconfig
arm                        multi_v5_defconfig
powerpc                     kmeter1_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                           sama5_defconfig
xtensa                           alldefconfig
xtensa                    xip_kc705_defconfig
h8300                            alldefconfig
arm                             rpc_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
powerpc                     mpc5200_defconfig
arm                       omap2plus_defconfig
csky                                defconfig
arm                        mvebu_v7_defconfig
arm                        neponset_defconfig
mips                  cavium_octeon_defconfig
ia64                        generic_defconfig
arm                           tegra_defconfig
powerpc                     stx_gp3_defconfig
powerpc                  storcenter_defconfig
arm                         s5pv210_defconfig
ia64                         bigsur_defconfig
arm                         orion5x_defconfig
m68k                        stmark2_defconfig
mips                        workpad_defconfig
arm                        multi_v7_defconfig
arm                        spear3xx_defconfig
m68k                             alldefconfig
mips                           mtx1_defconfig
arc                           tb10x_defconfig
powerpc                      ppc64e_defconfig
powerpc                 mpc834x_mds_defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
arm                        spear6xx_defconfig
powerpc                 mpc8315_rdb_defconfig
arm                            zeus_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                       maple_defconfig
mips                     cu1000-neo_defconfig
sh                   secureedge5410_defconfig
arm                         nhk8815_defconfig
sh                          landisk_defconfig
parisc                           allyesconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
sh                          kfr2r09_defconfig
arm                      footbridge_defconfig
arm                          iop32x_defconfig
powerpc                 mpc832x_rdb_defconfig
sh                           se7343_defconfig
sh                        sh7785lcr_defconfig
sh                          rsk7201_defconfig
m68k                          hp300_defconfig
s390                          debug_defconfig
sh                 kfr2r09-romimage_defconfig
mips                          malta_defconfig
arm                         axm55xx_defconfig
mips                      fuloong2e_defconfig
sh                        sh7757lcr_defconfig
arm                        shmobile_defconfig
riscv             nommu_k210_sdcard_defconfig
arc                                 defconfig
mips                            ar7_defconfig
sh                          sdk7786_defconfig
arm                     am200epdkit_defconfig
arm                           sunxi_defconfig
m68k                            q40_defconfig
mips                        nlm_xlr_defconfig
powerpc                     sbc8548_defconfig
arm                       netwinder_defconfig
powerpc                        warp_defconfig
sh                          lboxre2_defconfig
powerpc                   bluestone_defconfig
m68k                          multi_defconfig
arm                         cm_x300_defconfig
alpha                            alldefconfig
arm                      tct_hammer_defconfig
sh                   sh7724_generic_defconfig
sh                          rsk7269_defconfig
powerpc                mpc7448_hpc2_defconfig
mips                           ip22_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                           gcw0_defconfig
sh                        sh7763rdp_defconfig
h8300                               defconfig
arm                         shannon_defconfig
powerpc                         ps3_defconfig
x86_64                           alldefconfig
arm                            xcep_defconfig
nios2                            alldefconfig
powerpc                      ep88xc_defconfig
m68k                          amiga_defconfig
arm                  colibri_pxa270_defconfig
powerpc                    mvme5100_defconfig
mips                    maltaup_xpa_defconfig
arm                        trizeps4_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                      tqm8xx_defconfig
powerpc                     tqm8541_defconfig
powerpc                        fsp2_defconfig
um                               allyesconfig
arm                          ep93xx_defconfig
arm                            dove_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                     asp8347_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
arm                        vexpress_defconfig
powerpc                      ppc40x_defconfig
arm                        realview_defconfig
sh                         ap325rxa_defconfig
openrisc                            defconfig
mips                          ath25_defconfig
mips                          ath79_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210408
x86_64               randconfig-a005-20210408
x86_64               randconfig-a003-20210408
x86_64               randconfig-a001-20210408
x86_64               randconfig-a002-20210408
x86_64               randconfig-a006-20210408
i386                 randconfig-a006-20210408
i386                 randconfig-a003-20210408
i386                 randconfig-a001-20210408
i386                 randconfig-a004-20210408
i386                 randconfig-a005-20210408
i386                 randconfig-a002-20210408
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
i386                 randconfig-a006-20210407
i386                 randconfig-a003-20210407
i386                 randconfig-a001-20210407
i386                 randconfig-a004-20210407
i386                 randconfig-a002-20210407
i386                 randconfig-a005-20210407
x86_64               randconfig-a014-20210407
x86_64               randconfig-a015-20210407
x86_64               randconfig-a013-20210407
x86_64               randconfig-a011-20210407
x86_64               randconfig-a012-20210407
x86_64               randconfig-a016-20210407
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
i386                 randconfig-a014-20210407
i386                 randconfig-a011-20210407
i386                 randconfig-a016-20210407
i386                 randconfig-a012-20210407
i386                 randconfig-a015-20210407
i386                 randconfig-a013-20210407
i386                 randconfig-a014-20210408
i386                 randconfig-a016-20210408
i386                 randconfig-a011-20210408
i386                 randconfig-a012-20210408
i386                 randconfig-a013-20210408
i386                 randconfig-a015-20210408
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409
x86_64               randconfig-a004-20210407
x86_64               randconfig-a003-20210407
x86_64               randconfig-a005-20210407
x86_64               randconfig-a001-20210407
x86_64               randconfig-a002-20210407
x86_64               randconfig-a006-20210407
x86_64               randconfig-a014-20210408
x86_64               randconfig-a015-20210408
x86_64               randconfig-a012-20210408
x86_64               randconfig-a011-20210408
x86_64               randconfig-a013-20210408
x86_64               randconfig-a016-20210408

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:40 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:40 +0800
Subject: [soc:qcom/dt64-2] BUILD SUCCESS
 7178d4cc0702bfe6a7e0f21e37d6e3dfe8e40f11
Message-ID: <607165f0.N7B7YRqlIizSL6PH%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt64-2
branch HEAD: 7178d4cc0702bfe6a7e0f21e37d6e3dfe8e40f11  arm64: dts: qcom: update usb qmp phy clock-cells property

elapsed time: 723m

configs tested: 169
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
ia64                             allyesconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
powerpc                   bluestone_defconfig
mips                      loongson3_defconfig
m68k                          multi_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
xtensa                  audio_kc705_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
sh                          lboxre2_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
arm                        vexpress_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
arm                            pleb_defconfig
arm                          collie_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:41 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:41 +0800
Subject: [soc:broadcom/maintainer] BUILD SUCCESS
 0072f6c37f02071821eb2135b80daa404d783704
Message-ID: <607165f1.T9KVpORTDhlD0/nX%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git broadcom/maintainer
branch HEAD: 0072f6c37f02071821eb2135b80daa404d783704  mailmap: Update email address for Nicolas Saenz

elapsed time: 724m

configs tested: 150
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
ia64                             allyesconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
openrisc                 simple_smp_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
arm                        vexpress_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
arm                            pleb_defconfig
arm                          collie_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:45 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:45 +0800
Subject: [soc:for-next] BUILD SUCCESS 76c46d152106e594926a21e40c95ec58d80ec264
Message-ID: <607165f5.hOXieUg6TSEQ+Ags%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 76c46d152106e594926a21e40c95ec58d80ec264  soc: document merges

elapsed time: 724m

configs tested: 114
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
sh                        dreamcast_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
sh                          sdk7780_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:43 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:43 +0800
Subject: [soc:arm/soc] BUILD SUCCESS d92e5e32fb4fce7ae939ad322aad77955dd5dcda
Message-ID: <607165f3.cXLmCh1hmapnhWUS%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/soc
branch HEAD: d92e5e32fb4fce7ae939ad322aad77955dd5dcda  Merge tag 'arm-soc/for-5.13/maintainers' of https://github.com/Broadcom/stblinux into arm/soc

elapsed time: 724m

configs tested: 165
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
sh                           se7750_defconfig
powerpc                       ebony_defconfig
mips                           xway_defconfig
powerpc                     mpc83xx_defconfig
ia64                      gensparse_defconfig
arm                          simpad_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
mips                        workpad_defconfig
mips                       bmips_be_defconfig
sh                            shmin_defconfig
arm                        multi_v7_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
powerpc                   bluestone_defconfig
mips                      loongson3_defconfig
m68k                          multi_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
xtensa                  audio_kc705_defconfig
arm                      jornada720_defconfig
sh                           se7780_defconfig
sh                          lboxre2_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
arm                        vexpress_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sat Apr 10 09:46:38 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 10 Apr 2021 16:46:38 +0800
Subject: [soc:qcom/dt-2] BUILD SUCCESS 885aae6860fae1eed38f5cc1ac09a40e4896a38c
Message-ID: <607165ee.xyMbi4kiMtrJ2Kci%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt-2
branch HEAD: 885aae6860fae1eed38f5cc1ac09a40e4896a38c  ARM: dts: qcom: msm8974-klte: Add bluetooth support

elapsed time: 723m

configs tested: 153
configs skipped: 75

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm64                            alldefconfig
powerpc                      bamboo_defconfig
m68k                       bvme6000_defconfig
mips                      pistachio_defconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc834x_itx_defconfig
powerpc                     pq2fads_defconfig
mips                    maltaup_xpa_defconfig
mips                          ath79_defconfig
m68k                                defconfig
ia64                             allyesconfig
s390                       zfcpdump_defconfig
powerpc                      pasemi_defconfig
powerpc                 linkstation_defconfig
um                             i386_defconfig
s390                             allmodconfig
arm                          gemini_defconfig
powerpc                     ep8248e_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                    socrates_defconfig
sh                           se7751_defconfig
arm                         s3c6400_defconfig
sh                         apsh4a3a_defconfig
mips                        bcm63xx_defconfig
powerpc                      tqm8xx_defconfig
openrisc                         alldefconfig
arm                            mmp2_defconfig
powerpc64                           defconfig
sh                             espt_defconfig
arm                         vf610m4_defconfig
mips                          rb532_defconfig
mips                            gpr_defconfig
arc                     haps_hs_smp_defconfig
arm                             mxs_defconfig
powerpc                      arches_defconfig
sh                        dreamcast_defconfig
arm                             rpc_defconfig
powerpc                   currituck_defconfig
powerpc                 mpc837x_mds_defconfig
microblaze                      mmu_defconfig
riscv                    nommu_k210_defconfig
arc                            hsdk_defconfig
riscv             nommu_k210_sdcard_defconfig
arm                        multi_v5_defconfig
h8300                               defconfig
mips                         tb0287_defconfig
mips                         tb0219_defconfig
sh                          urquell_defconfig
arm                        spear6xx_defconfig
sh                            titan_defconfig
powerpc                 mpc8315_rdb_defconfig
powerpc                 mpc836x_rdk_defconfig
m68k                       m5249evb_defconfig
ia64                            zx1_defconfig
arm                          ixp4xx_defconfig
arc                          axs101_defconfig
sh                          sdk7780_defconfig
s390                             allyesconfig
arm                          badge4_defconfig
arm                             pxa_defconfig
powerpc                      walnut_defconfig
mips                      loongson3_defconfig
mips                       lemote2f_defconfig
arm                     am200epdkit_defconfig
sh                        sh7757lcr_defconfig
arm                         nhk8815_defconfig
arm                         shannon_defconfig
sh                           se7619_defconfig
sh                          r7785rp_defconfig
powerpc                     asp8347_defconfig
powerpc                     sbc8548_defconfig
powerpc                     tqm8540_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                      mgcoge_defconfig
m68k                        m5407c3_defconfig
arm                        vexpress_defconfig
sh                               alldefconfig
mips                     loongson1b_defconfig
arm                            pleb_defconfig
arm                          collie_defconfig
ia64                             allmodconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a006-20210409
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From ilias.apalodimas at linaro.org  Sat Apr 10 09:52:26 2021
From: ilias.apalodimas at linaro.org (Ilias Apalodimas)
Date: Sat, 10 Apr 2021 11:52:26 +0300
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <20210410082158.79ad09a6@carbon>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
Message-ID: <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>

+CC Grygorii for the cpsw part as Ivan's email is not valid anymore

Thanks for catching this. Interesting indeed...

On Sat, 10 Apr 2021 at 09:22, Jesper Dangaard Brouer <brouer at redhat.com> wrote:
>
> On Sat, 10 Apr 2021 03:43:13 +0100
> Matthew Wilcox <willy at infradead.org> wrote:
>
> > On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel test robot wrote:
> > > >> include/linux/mm_types.h:274:1: error: static_assert failed due to requirement '__builtin_offsetof(struct page, lru) == __builtin_offsetof(struct folio, lru)' "offsetof(struct page, lru) == offsetof(struct folio, lru)"
> > >    FOLIO_MATCH(lru, lru);
> > >    include/linux/mm_types.h:272:2: note: expanded from macro 'FOLIO_MATCH'
> > >            static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))
> >
> > Well, this is interesting.  pahole reports:
> >
> > struct page {
> >         long unsigned int          flags;                /*     0     4 */
> >         /* XXX 4 bytes hole, try to pack */
> >         union {
> >                 struct {
> >                         struct list_head lru;            /*     8     8 */
> > ...
> > struct folio {
> >         union {
> >                 struct {
> >                         long unsigned int flags;         /*     0     4 */
> >                         struct list_head lru;            /*     4     8 */
> >
> > so this assert has absolutely done its job.
> >
> > But why has this assert triggered?  Why is struct page layout not what
> > we thought it was?  Turns out it's the dma_addr added in 2019 by commit
> > c25fff7171be ("mm: add dma_addr_t to struct page").  On this particular
> > config, it's 64-bit, and ppc32 requires alignment to 64-bit.  So
> > the whole union gets moved out by 4 bytes.
>
> Argh, good that you are catching this!
>
> > Unfortunately, we can't just fix this by putting an 'unsigned long pad'
> > in front of it.  It still aligns the entire union to 8 bytes, and then
> > it skips another 4 bytes after the pad.
> >
> > We can fix it like this ...
> >
> > +++ b/include/linux/mm_types.h
> > @@ -96,11 +96,12 @@ struct page {
> >                         unsigned long private;
> >                 };
> >                 struct {        /* page_pool used by netstack */
> > +                       unsigned long _page_pool_pad;
>
> I'm fine with this pad.  Matteo is currently proposing[1] to add a 32-bit
> value after @dma_addr, and he could use this area instead.
>
> [1] https://lore.kernel.org/netdev/20210409223801.104657-3-mcroce at linux.microsoft.com/
>
> When adding/changing this, we need to make sure that it doesn't overlap
> member @index, because network stack use/check page_is_pfmemalloc().
> As far as my calculations this is safe to add.  I always try to keep an
> eye out for this, but I wonder if we could have a build check like yours.
>
>
> >                         /**
> >                          * @dma_addr: might require a 64-bit value even on
> >                          * 32-bit architectures.
> >                          */
> > -                       dma_addr_t dma_addr;
> > +                       dma_addr_t dma_addr __packed;
> >                 };
> >                 struct {        /* slab, slob and slub */
> >                         union {
> >
> > but I don't know if GCC is smart enough to realise that dma_addr is now
> > on an 8 byte boundary and it can use a normal instruction to access it,
> > or whether it'll do something daft like use byte loads to access it.
> >
> > We could also do:
> >
> > +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));
> >
> > and I see pahole, at least sees this correctly:
> >
> >                 struct {
> >                         long unsigned int _page_pool_pad; /*     4     4 */
> >                         dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
> >                 } __attribute__((__packed__)) __attribute__((__aligned__(4)));
> >
> > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> > / dma_addr_t.  Advice, please?
>
> I'm not sure that the 32-bit behavior is with 64-bit (dma) addrs.
>
> I don't have any 32-bit boards with 64-bit DMA.  Cc. Ivan, wasn't your
> board (572x ?) 32-bit with driver 'cpsw' this case (where Ivan added
> XDP+page_pool) ?
>
> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer
>


From gregkh at linuxfoundation.org  Sat Apr 10 09:58:09 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Sat, 10 Apr 2021 10:58:09 +0200
Subject: [PATCH -next] char: xilinx_hwicap: use DEFINE_MUTEX() for mutex
 lock
In-Reply-To: <20210409095136.2293754-1-yebin10@huawei.com>
References: <20210409095136.2293754-1-yebin10@huawei.com>
Message-ID: <YHFooZWlC+PV1kV0@kroah.com>

On Fri, Apr 09, 2021 at 05:51:36PM +0800, Ye Bin wrote:
> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Ye Bin <yebin10 at huawei.com>
> ---
>  drivers/char/xilinx_hwicap/xilinx_hwicap.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> index 067396bedf22..4d586233dfa4 100644
> --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> @@ -111,7 +111,7 @@
>  /* An array, which is set to true when the device is registered. */
>  static DEFINE_MUTEX(hwicap_mutex);
>  static bool probed_devices[HWICAP_DEVICES];
> -static struct mutex icap_sem;
> +static DEFINE_MUTEX(icap_sem);
>  
>  static struct class *icap_class;
>  
> @@ -857,7 +857,6 @@ static int __init hwicap_module_init(void)
>  	int retval;
>  
>  	icap_class = class_create(THIS_MODULE, "xilinx_config");
> -	mutex_init(&icap_sem);
>  
>  	devt = MKDEV(XHWICAP_MAJOR, XHWICAP_MINOR);
>  	retval = register_chrdev_region(devt,
> 

What actually does this help out with?  Why is it wrong to explicitly
call mutex_init() instead of a magic macro?

What good are these changes causing?

thanks,

greg k-h


From yong.wu at mediatek.com  Sat Apr 10 10:11:12 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:12 +0800
Subject: [PATCH v5 00/16] Clean up "mediatek,larb"
Message-ID: <20210410091128.31823-1-yong.wu@mediatek.com>

MediaTek IOMMU block diagram always like below:

        M4U
         |
    smi-common
         |
  -------------
  |         |  ...
  |         |
larb1     larb2
  |         |
vdec       venc

All the consumer connect with smi-larb, then connect with smi-common.

When the consumer works, it should enable the smi-larb's power which also
need enable the smi-common's power firstly.

Thus, Firstly, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.

After adding the device_link, then "mediatek,larb" property can be removed.
the iommu consumer don't need call the mtk_smi_larb_get/put to enable
the power and clock of smi-larb and smi-common.

About the MM dt-bindings/dtsi patches, I guess they will go through Matthias's
tree, so I don't split them for each a MM module and each a SoC.

This patchset base on v5.12-rc2 and a vcodec patchset(separating its node)[1]
which has already been in linux-next.

[1] https://lore.kernel.org/linux-mediatek/20210325122625.15100-1-irui.wang at mediatek.com/

Change notes:
v5: 1) Base on v5.12-rc2.
    2) Remove changing the mtk-iommu to module_platform_driver patch, It have
    already been a independent patch.
    3) Add several patches for the MM drivers with pm_runtime_resume_and_get
    instead of pm_runtime_get_sync since smi already use it.

v4: https://lore.kernel.org/linux-mediatek/1590826218-23653-1-git-send-email-yong.wu at mediatek.com/ 
    base on v5.7-rc1.
  1) Move drm PM patch before smi patchs.
  2) Change builtin_platform_driver to module_platform_driver since we may need
     build as module.
  3) Rebase many patchset as above.

v3: https://lore.kernel.org/linux-iommu/1567503456-24725-1-git-send-email-yong.wu at mediatek.com/
    1) rebase on v5.3-rc1 and the latest mt8183 patchset.
    2) Use device_is_bound to check whether the driver is ready from Matthias.    
    3) Add DL_FLAG_STATELESS flag when calling device_link_add and explain the
   reason in the commit message[3/14].
    4) Add a display patch[12/14] into this series. otherwise it may affect
   display HW fastlogo even though it don't happen in mt8183.
   
v2: https://lore.kernel.org/linux-iommu/1560171313-28299-1-git-send-email-yong.wu at mediatek.com/
   1) rebase on v5.2-rc1.
   2) Move adding device_link between the consumer and smi-larb into
iommu_add_device from Robin.
   3) add DL_FLAG_AUTOREMOVE_CONSUMER even though the smi is built-in from Evan.
   4) Remove the shutdown callback in iommu.   

v1: https://lore.kernel.org/linux-iommu/1546318276-18993-1-git-send-email-yong.wu at mediatek.com/

Yong Wu (15):
  dt-binding: mediatek: Get rid of mediatek,larb for multimedia HW
  iommu/mediatek: Add probe_defer for smi-larb
  iommu/mediatek: Add device_link between the consumer and the larb
    devices
  memory: mtk-smi: Add device-link between smi-larb and smi-common
  media: mtk-jpeg: Use pm_runtime_resume_and_get for PM get_sync
  media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
  media: mtk-mdp: Use pm_runtime_resume_and_get for PM get_sync
  media: mtk-mdp: Get rid of mtk_smi_larb_get/put
  drm/mediatek: Use pm_runtime_resume_and_get for PM get_sync
  drm/mediatek: Get rid of mtk_smi_larb_get/put
  media: mtk-vcodec: Use pm_runtime_resume_and_get for PM get_sync
  media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
  memory: mtk-smi: Get rid of mtk_smi_larb_get/put
  arm: dts: mediatek: Get rid of mediatek,larb for MM nodes
  arm64: dts: mediatek: Get rid of mediatek,larb for MM nodes

Yongqiang Niu (1):
  drm/mediatek: Add pm runtime support for ovl and rdma

 .../display/mediatek/mediatek,disp.txt        |  9 ----
 .../bindings/media/mediatek-jpeg-decoder.txt  |  4 --
 .../bindings/media/mediatek-jpeg-encoder.txt  |  4 --
 .../bindings/media/mediatek-mdp.txt           |  8 ----
 .../bindings/media/mediatek-vcodec.txt        |  4 --
 arch/arm/boot/dts/mt2701.dtsi                 |  2 -
 arch/arm/boot/dts/mt7623n.dtsi                |  5 --
 arch/arm64/boot/dts/mediatek/mt8173.dtsi      | 16 -------
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      |  5 --
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c       |  9 +++-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c      |  9 +++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 21 +++++----
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   | 35 --------------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  1 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  5 +-
 drivers/iommu/mtk_iommu.c                     | 24 +++++++++-
 drivers/iommu/mtk_iommu_v1.c                  | 22 ++++++++-
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 34 ++------------
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  2 -
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 40 ----------------
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  2 -
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  1 -
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  |  4 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c   | 42 ++++-------------
 .../platform/mtk-vcodec/mtk_vcodec_drv.h      |  3 --
 .../platform/mtk-vcodec/mtk_vcodec_enc.c      |  1 -
 .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c   | 46 ++-----------------
 drivers/memory/mtk-smi.c                      | 33 ++++---------
 include/soc/mediatek/smi.h                    | 20 --------
 29 files changed, 99 insertions(+), 312 deletions(-)

-- 
2.18.0


From yong.wu at mediatek.com  Sat Apr 10 10:11:13 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:13 +0800
Subject: [PATCH v5 01/16] dt-binding: mediatek: Get rid of mediatek,
 larb for multimedia HW
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-2-yong.wu@mediatek.com>

After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.

And IOMMU also know which larb this consumer connects with from
iommu id in the "iommus=" property.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Evan Green <evgreen at chromium.org>
---
 .../bindings/display/mediatek/mediatek,disp.txt          | 9 ---------
 .../devicetree/bindings/media/mediatek-jpeg-decoder.txt  | 4 ----
 .../devicetree/bindings/media/mediatek-jpeg-encoder.txt  | 4 ----
 Documentation/devicetree/bindings/media/mediatek-mdp.txt | 8 --------
 .../devicetree/bindings/media/mediatek-vcodec.txt        | 4 ----
 5 files changed, 29 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 93b160df3eec..6336bae8a6d7 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -61,8 +61,6 @@ Required properties (DMA function blocks):
 	"mediatek,<chip>-disp-rdma"
 	"mediatek,<chip>-disp-wdma"
   the supported chips are mt2701, mt8167 and mt8173.
-- larb: Should contain a phandle pointing to the local arbiter device as defined
-  in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
 - iommus: Should point to the respective IOMMU block with master port as
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
   for details.
@@ -91,7 +89,6 @@ ovl0: ovl at 1400c000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_OVL0>;
 	iommus = <&iommu M4U_PORT_DISP_OVL0>;
-	mediatek,larb = <&larb0>;
 };
 
 ovl1: ovl at 1400d000 {
@@ -101,7 +98,6 @@ ovl1: ovl at 1400d000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_OVL1>;
 	iommus = <&iommu M4U_PORT_DISP_OVL1>;
-	mediatek,larb = <&larb4>;
 };
 
 rdma0: rdma at 1400e000 {
@@ -111,7 +107,6 @@ rdma0: rdma at 1400e000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_RDMA0>;
 	iommus = <&iommu M4U_PORT_DISP_RDMA0>;
-	mediatek,larb = <&larb0>;
 	mediatek,rdma-fifosize = <8192>;
 };
 
@@ -122,7 +117,6 @@ rdma1: rdma at 1400f000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_RDMA1>;
 	iommus = <&iommu M4U_PORT_DISP_RDMA1>;
-	mediatek,larb = <&larb4>;
 };
 
 rdma2: rdma at 14010000 {
@@ -132,7 +126,6 @@ rdma2: rdma at 14010000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_RDMA2>;
 	iommus = <&iommu M4U_PORT_DISP_RDMA2>;
-	mediatek,larb = <&larb4>;
 };
 
 wdma0: wdma at 14011000 {
@@ -142,7 +135,6 @@ wdma0: wdma at 14011000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_WDMA0>;
 	iommus = <&iommu M4U_PORT_DISP_WDMA0>;
-	mediatek,larb = <&larb0>;
 };
 
 wdma1: wdma at 14012000 {
@@ -152,7 +144,6 @@ wdma1: wdma at 14012000 {
 	power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 	clocks = <&mmsys CLK_MM_DISP_WDMA1>;
 	iommus = <&iommu M4U_PORT_DISP_WDMA1>;
-	mediatek,larb = <&larb4>;
 };
 
 color0: color at 14013000 {
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
index cf60c5acc0e4..7978f210e3d4 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
@@ -15,9 +15,6 @@ Required properties:
 - clock-names: must contain "jpgdec-smi" and "jpgdec".
 - power-domains: a phandle to the power domain, see
   Documentation/devicetree/bindings/power/power_domain.txt for details.
-- mediatek,larb: must contain the local arbiters in the current Socs, see
-  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
-  for details.
 - iommus: should point to the respective IOMMU block with master port as
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
   for details.
@@ -32,7 +29,6 @@ Example:
 		clock-names = "jpgdec-smi",
 			      "jpgdec";
 		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
-		mediatek,larb = <&larb2>;
 		iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
 			 <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
 	};
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
index acfb50375b8a..4b3664987362 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -13,9 +13,6 @@ Required properties:
 - clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
 - power-domains: a phandle to the power domain, see
   Documentation/devicetree/bindings/power/power_domain.txt for details.
-- mediatek,larb: must contain the local arbiters in the current SoCs, see
-  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
-  for details.
 - iommus: should point to the respective IOMMU block with master port as
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
   for details.
@@ -29,7 +26,6 @@ Example:
 		clocks =  <&imgsys CLK_IMG_VENC>;
 		clock-names = "jpgenc";
 		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
-		mediatek,larb = <&larb2>;
 		iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
 			 <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
 	};
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index f4798d04e925..df69c5a06250 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -27,9 +27,6 @@ Required properties (DMA function blocks, child node):
 - iommus: should point to the respective IOMMU block with master port as
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
   for details.
-- mediatek,larb: must contain the local arbiters in the current Socs, see
-  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
-  for details.
 
 Example:
 	mdp_rdma0: rdma at 14001000 {
@@ -40,7 +37,6 @@ Example:
 			 <&mmsys CLK_MM_MUTEX_32K>;
 		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 		iommus = <&iommu M4U_PORT_MDP_RDMA0>;
-		mediatek,larb = <&larb0>;
 		mediatek,vpu = <&vpu>;
 	};
 
@@ -51,7 +47,6 @@ Example:
 			 <&mmsys CLK_MM_MUTEX_32K>;
 		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 		iommus = <&iommu M4U_PORT_MDP_RDMA1>;
-		mediatek,larb = <&larb4>;
 	};
 
 	mdp_rsz0: rsz at 14003000 {
@@ -81,7 +76,6 @@ Example:
 		clocks = <&mmsys CLK_MM_MDP_WDMA>;
 		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 		iommus = <&iommu M4U_PORT_MDP_WDMA>;
-		mediatek,larb = <&larb0>;
 	};
 
 	mdp_wrot0: wrot at 14007000 {
@@ -90,7 +84,6 @@ Example:
 		clocks = <&mmsys CLK_MM_MDP_WROT0>;
 		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 		iommus = <&iommu M4U_PORT_MDP_WROT0>;
-		mediatek,larb = <&larb0>;
 	};
 
 	mdp_wrot1: wrot at 14008000 {
@@ -99,5 +92,4 @@ Example:
 		clocks = <&mmsys CLK_MM_MDP_WROT1>;
 		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
 		iommus = <&iommu M4U_PORT_MDP_WROT1>;
-		mediatek,larb = <&larb4>;
 	};
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8318f0ed492d..ad7ba4bf23fe 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -12,7 +12,6 @@ Required properties:
 - reg : Physical base address of the video codec registers and length of
   memory mapped region.
 - interrupts : interrupt number to the cpu.
-- mediatek,larb : must contain the local arbiters in the current Socs.
 - clocks : list of clock specifiers, corresponding to entries in
   the clock-names property.
 - clock-names: avc encoder must contain "venc_sel", vp8 encoder must
@@ -44,7 +43,6 @@ vcodec_dec: vcodec at 16000000 {
           <0 0x16027800 0 0x800>,   /*VP8_VL*/
           <0 0x16028400 0 0x400>;   /*VP9_VD*/
     interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>;
-    mediatek,larb = <&larb1>;
     iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
              <&iommu M4U_PORT_HW_VDEC_PP_EXT>,
              <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
@@ -97,7 +95,6 @@ vcodec_enc_avc: vcodec at 18002000 {
              <&iommu M4U_PORT_VENC_REF_CHROMA>,
              <&iommu M4U_PORT_VENC_NBM_RDMA>,
              <&iommu M4U_PORT_VENC_NBM_WDMA>;
-    mediatek,larb = <&larb3>;
     mediatek,vpu = <&vpu>;
     clocks = <&topckgen CLK_TOP_VENC_SEL>;
     clock-names = "venc_sel";
@@ -118,7 +115,6 @@ vcodec_enc_vp8: vcodec at 19002000 {
              <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
              <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
              <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
-    mediatek,larb = <&larb5>;
     mediatek,vpu = <&vpu>;
     clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
     clock-names = "venc_lt_sel";
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:14 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:14 +0800
Subject: [PATCH v5 02/16] iommu/mediatek: Add probe_defer for smi-larb
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-3-yong.wu@mediatek.com>

The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.

When there is no this patch, if some consumer drivers run before
smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
device_link_add, then device_links_driver_bound will use WARN_ON
to complain that the link_status of supplier is not right.

This is a preparing patch for adding device_link.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
To Matthias,

In v2, You suggested use device_is_bound here. But from [1], this
interface is not allowed to be EXPORT. It will affect this driver
built as module. thus I still use dev.driver to check here.

[1] https://lore.kernel.org/patchwork/patch/1334670/
---
 drivers/iommu/mtk_iommu.c    | 2 +-
 drivers/iommu/mtk_iommu_v1.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd..7a7b8260d308 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -862,7 +862,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 			id = i;
 
 		plarbdev = of_find_device_by_node(larbnode);
-		if (!plarbdev) {
+		if (!plarbdev || !plarbdev->dev.driver) {
 			of_node_put(larbnode);
 			return -EPROBE_DEFER;
 		}
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 82ddfe9170d4..a82466e4046e 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -597,7 +597,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 			plarbdev = of_platform_device_create(
 						larb_spec.np, NULL,
 						platform_bus_type.dev_root);
-			if (!plarbdev) {
+			if (!plarbdev || !plarbdev->dev.driver) {
 				of_node_put(larb_spec.np);
 				return -EPROBE_DEFER;
 			}
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:15 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:15 +0800
Subject: [PATCH v5 03/16] iommu/mediatek: Add device_link between the consumer
 and the larb devices
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-4-yong.wu@mediatek.com>

MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.

        M4U
         |
    smi-common
         |
  -------------
  |         |    ...
  |         |
larb1     larb2
  |         |
vdec       venc

When the consumer works, it should enable the smi-larb's power which
also need enable the smi-common's power firstly.

Thus, First of all, use the device link connect the consumer and the
smi-larbs. then add device link between the smi-larb and smi-common.

This patch adds device_link between the consumer and the larbs.

When device_link_add, I add the flag DL_FLAG_STATELESS to avoid calling
pm_runtime_xx to keep the original status of clocks. It can avoid two
issues:
1) Display HW show fastlogo abnormally reported in [1]. At the beggining,
all the clocks are enabled before entering kernel, but the clocks for
display HW(always in larb0) will be gated after clk_enable and clk_disable
called from device_link_add(->pm_runtime_resume) and rpm_idle. The clock
operation happened before display driver probe. At that time, the display
HW will be abnormal.

2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to skip
pm_runtime_xx to avoid the deadlock.

Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then
device_link_removed should be added explicitly.

[1] https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel at mhfsdcap03/
[2] https://lore.kernel.org/patchwork/patch/1086569/

Suggested-by: Tomasz Figa <tfiga at chromium.org>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/iommu/mtk_iommu.c    | 22 ++++++++++++++++++++++
 drivers/iommu/mtk_iommu_v1.c | 20 +++++++++++++++++++-
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 7a7b8260d308..cd054bd3f0df 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -571,22 +571,44 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
 {
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct mtk_iommu_data *data;
+	struct device_link *link;
+	struct device *larbdev;
+	unsigned int larbid;
 
 	if (!fwspec || fwspec->ops != &mtk_iommu_ops)
 		return ERR_PTR(-ENODEV); /* Not a iommu client device */
 
 	data = dev_iommu_priv_get(dev);
 
+	/*
+	 * Link the consumer device with the smi-larb device(supplier)
+	 * The device in each a larb is a independent HW. thus only link
+	 * one larb here.
+	 */
+	larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+	larbdev = data->larb_imu[larbid].dev;
+	link = device_link_add(dev, larbdev,
+			       DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+	if (!link)
+		dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
 	return &data->iommu;
 }
 
 static void mtk_iommu_release_device(struct device *dev)
 {
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct mtk_iommu_data *data;
+	struct device *larbdev;
+	unsigned int larbid;
 
 	if (!fwspec || fwspec->ops != &mtk_iommu_ops)
 		return;
 
+	data = dev_iommu_priv_get(dev);
+	larbid = MTK_M4U_TO_LARB(fwspec->ids[0]);
+	larbdev = data->larb_imu[larbid].dev;
+	device_link_remove(dev, larbdev);
+
 	iommu_fwspec_free(dev);
 }
 
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index a82466e4046e..43dbdf692894 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -425,7 +425,9 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
 	struct of_phandle_args iommu_spec;
 	struct of_phandle_iterator it;
 	struct mtk_iommu_data *data;
-	int err;
+	struct device_link *link;
+	struct device *larbdev;
+	int err, larbid;
 
 	of_for_each_phandle(&it, err, dev->of_node, "iommus",
 			"#iommu-cells", -1) {
@@ -447,6 +449,14 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
 
 	data = dev_iommu_priv_get(dev);
 
+	/* Link the consumer device with the smi-larb device(supplier) */
+	larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+	larbdev = data->larb_imu[larbid].dev;
+	link = device_link_add(dev, larbdev,
+			       DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+	if (!link)
+		dev_err(dev, "Unable to link %s\n", dev_name(larbdev));
+
 	return &data->iommu;
 }
 
@@ -467,10 +477,18 @@ static void mtk_iommu_probe_finalize(struct device *dev)
 static void mtk_iommu_release_device(struct device *dev)
 {
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct mtk_iommu_data *data;
+	struct device *larbdev;
+	unsigned int larbid;
 
 	if (!fwspec || fwspec->ops != &mtk_iommu_ops)
 		return;
 
+	data = dev_iommu_priv_get(dev);
+	larbid = mt2701_m4u_to_larb(fwspec->ids[0]);
+	larbdev = data->larb_imu[larbid].dev;
+	device_link_remove(dev, larbdev);
+
 	iommu_fwspec_free(dev);
 }
 
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:16 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:16 +0800
Subject: [PATCH v5 04/16] memory: mtk-smi: Add device-link between smi-larb
 and smi-common
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-5-yong.wu@mediatek.com>

Normally, If the smi-larb HW need work, we should enable the smi-common
HW power and clock firstly.
This patch adds device-link between the smi-larb dev and the smi-common
dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
(smi-common-dev) will be called automatically.

Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
probe.

CC: Matthias Brugger <matthias.bgg at gmail.com>
Suggested-by: Tomasz Figa <tfiga at chromium.org>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/memory/mtk-smi.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index b396253fcf4b..c5fb51f73b34 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -319,6 +319,7 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *smi_node;
 	struct platform_device *smi_pdev;
+	struct device_link *link;
 
 	larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
 	if (!larb)
@@ -358,6 +359,12 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
 		if (!platform_get_drvdata(smi_pdev))
 			return -EPROBE_DEFER;
 		larb->smi_common_dev = &smi_pdev->dev;
+		link = device_link_add(dev, larb->smi_common_dev,
+				       DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS);
+		if (!link) {
+			dev_err(dev, "Unable to link smi-common dev\n");
+			return -ENODEV;
+		}
 	} else {
 		dev_err(dev, "Failed to get the smi_common device\n");
 		return -EINVAL;
@@ -370,6 +377,9 @@ static int mtk_smi_larb_probe(struct platform_device *pdev)
 
 static int 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;
@@ -381,17 +391,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device *dev)
 	const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
 	int ret;
 
-	/* Power on smi-common. */
-	ret = pm_runtime_resume_and_get(larb->smi_common_dev);
-	if (ret < 0) {
-		dev_err(dev, "Failed to pm get for smi-common(%d).\n", ret);
-		return ret;
-	}
-
 	ret = mtk_smi_clk_enable(&larb->smi);
 	if (ret < 0) {
 		dev_err(dev, "Failed to enable clock(%d).\n", ret);
-		pm_runtime_put_sync(larb->smi_common_dev);
 		return ret;
 	}
 
@@ -406,7 +408,6 @@ static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
 	struct mtk_smi_larb *larb = dev_get_drvdata(dev);
 
 	mtk_smi_clk_disable(&larb->smi);
-	pm_runtime_put_sync(larb->smi_common_dev);
 	return 0;
 }
 
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:17 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:17 +0800
Subject: [PATCH v5 05/16] media: mtk-jpeg: Use pm_runtime_resume_and_get for
 PM get_sync
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-6-yong.wu@mediatek.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
This patch use pm_runtime_resume_and_get instead of pm_runtime_get
to keep usage counter balanced.

CC: Xia Jiang <xia.jiang at mediatek.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 88a23bce569d..a89c7b206eef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv)
 	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto enc_end;
 
@@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv)
 		return;
 	}
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto dec_end;
 
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:21 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:21 +0800
Subject: [PATCH v5 09/16] drm/mediatek: Use pm_runtime_resume_and_get for PM
 get_sync
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-10-yong.wu@mediatek.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
This patch use pm_runtime_resume_and_get instead of pm_runtime_get
to keep usage counter balanced.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8b0de90156c6..69d23ce56d2c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -259,7 +259,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
 		drm_connector_list_iter_end(&conn_iter);
 	}
 
-	ret = pm_runtime_get_sync(crtc->dev->dev);
+	ret = pm_runtime_resume_and_get(crtc->dev->dev);
 	if (ret < 0) {
 		DRM_ERROR("Failed to enable power domain: %d\n", ret);
 		return ret;
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:24 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:24 +0800
Subject: [PATCH v5 12/16] media: mtk-vcodec: Use pm_runtime_resume_and_get for
 PM get_sync
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-13-yong.wu@mediatek.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
This patch use pm_runtime_resume_and_get instead of
pm_runtime_get_sync to keep usage counter balanced.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index ddee7046ce42..32e1858e9f1d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -92,9 +92,10 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
-	ret = pm_runtime_get_sync(pm->dev);
+	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
-		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
+		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
+
 }
 
 void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:18 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:18 +0800
Subject: [PATCH v5 06/16] media: mtk-jpeg: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-7-yong.wu@mediatek.com>

MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.

CC: Rick Chang <rick.chang at mediatek.com>
CC: Xia Jiang <xia.jiang at mediatek.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
Acked-by: Rick Chang <rick.chang at mediatek.com>
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 30 +------------------
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  2 --
 2 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index a89c7b206eef..a47832a1b316 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -22,7 +22,6 @@
 #include <media/v4l2-ioctl.h>
 #include <media/videobuf2-core.h>
 #include <media/videobuf2-dma-contig.h>
-#include <soc/mediatek/smi.h>
 
 #include "mtk_jpeg_enc_hw.h"
 #include "mtk_jpeg_dec_hw.h"
@@ -1055,10 +1054,6 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
 {
 	int ret;
 
-	ret = mtk_smi_larb_get(jpeg->larb);
-	if (ret)
-		dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
-
 	ret = clk_bulk_prepare_enable(jpeg->variant->num_clks,
 				      jpeg->variant->clks);
 	if (ret)
@@ -1069,7 +1064,6 @@ static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
 {
 	clk_bulk_disable_unprepare(jpeg->variant->num_clks,
 				   jpeg->variant->clks);
-	mtk_smi_larb_put(jpeg->larb);
 }
 
 static irqreturn_t mtk_jpeg_enc_done(struct mtk_jpeg_dev *jpeg)
@@ -1286,27 +1280,12 @@ static struct clk_bulk_data mtk_jpeg_clocks[] = {
 
 static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
 {
-	struct device_node *node;
-	struct platform_device *pdev;
 	int ret;
 
-	node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
-	if (!node)
-		return -EINVAL;
-	pdev = of_find_device_by_node(node);
-	if (WARN_ON(!pdev)) {
-		of_node_put(node);
-		return -EINVAL;
-	}
-	of_node_put(node);
-
-	jpeg->larb = &pdev->dev;
-
 	ret = devm_clk_bulk_get(jpeg->dev, jpeg->variant->num_clks,
 				jpeg->variant->clks);
 	if (ret) {
-		dev_err(&pdev->dev, "failed to get jpeg clock:%d\n", ret);
-		put_device(&pdev->dev);
+		dev_err(jpeg->dev, "failed to get jpeg clock:%d\n", ret);
 		return ret;
 	}
 
@@ -1333,11 +1312,6 @@ static void mtk_jpeg_job_timeout_work(struct work_struct *work)
 	v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
 }
 
-static inline void mtk_jpeg_clk_release(struct mtk_jpeg_dev *jpeg)
-{
-	put_device(jpeg->larb);
-}
-
 static int mtk_jpeg_probe(struct platform_device *pdev)
 {
 	struct mtk_jpeg_dev *jpeg;
@@ -1442,7 +1416,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
 	v4l2_device_unregister(&jpeg->v4l2_dev);
 
 err_dev_register:
-	mtk_jpeg_clk_release(jpeg);
 
 err_clk_init:
 
@@ -1460,7 +1433,6 @@ static int mtk_jpeg_remove(struct platform_device *pdev)
 	video_device_release(jpeg->vdev);
 	v4l2_m2m_release(jpeg->m2m_dev);
 	v4l2_device_unregister(&jpeg->v4l2_dev);
-	mtk_jpeg_clk_release(jpeg);
 
 	return 0;
 }
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 68e634f02e00..6e558e97a2d8 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -85,7 +85,6 @@ struct mtk_jpeg_variant {
  * @alloc_ctx:		videobuf2 memory allocator's context
  * @vdev:		video device node for jpeg mem2mem mode
  * @reg_base:		JPEG registers mapping
- * @larb:		SMI device
  * @job_timeout_work:	IRQ timeout structure
  * @variant:		driver variant to be used
  */
@@ -99,7 +98,6 @@ struct mtk_jpeg_dev {
 	void			*alloc_ctx;
 	struct video_device	*vdev;
 	void __iomem		*reg_base;
-	struct device		*larb;
 	struct delayed_work job_timeout_work;
 	const struct mtk_jpeg_variant *variant;
 };
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:28 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:28 +0800
Subject: [PATCH v5 16/16] arm64: dts: mediatek: Get rid of mediatek,
 larb for MM nodes
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-17-yong.wu@mediatek.com>

After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.

CC: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 ----------------
 arch/arm64/boot/dts/mediatek/mt8183.dtsi |  5 -----
 2 files changed, 21 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index f5950e9fc51d..683bce5eef37 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1008,7 +1008,6 @@
 				 <&mmsys CLK_MM_MUTEX_32K>;
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			iommus = <&iommu M4U_PORT_MDP_RDMA0>;
-			mediatek,larb = <&larb0>;
 			mediatek,vpu = <&vpu>;
 		};
 
@@ -1019,7 +1018,6 @@
 				 <&mmsys CLK_MM_MUTEX_32K>;
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			iommus = <&iommu M4U_PORT_MDP_RDMA1>;
-			mediatek,larb = <&larb4>;
 		};
 
 		mdp_rsz0: rsz at 14003000 {
@@ -1049,7 +1047,6 @@
 			clocks = <&mmsys CLK_MM_MDP_WDMA>;
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			iommus = <&iommu M4U_PORT_MDP_WDMA>;
-			mediatek,larb = <&larb0>;
 		};
 
 		mdp_wrot0: wrot at 14007000 {
@@ -1058,7 +1055,6 @@
 			clocks = <&mmsys CLK_MM_MDP_WROT0>;
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			iommus = <&iommu M4U_PORT_MDP_WROT0>;
-			mediatek,larb = <&larb0>;
 		};
 
 		mdp_wrot1: wrot at 14008000 {
@@ -1067,7 +1063,6 @@
 			clocks = <&mmsys CLK_MM_MDP_WROT1>;
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			iommus = <&iommu M4U_PORT_MDP_WROT1>;
-			mediatek,larb = <&larb4>;
 		};
 
 		ovl0: ovl at 1400c000 {
@@ -1077,7 +1072,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_OVL0>;
 			iommus = <&iommu M4U_PORT_DISP_OVL0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>;
 		};
 
@@ -1088,7 +1082,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_OVL1>;
 			iommus = <&iommu M4U_PORT_DISP_OVL1>;
-			mediatek,larb = <&larb4>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>;
 		};
 
@@ -1099,7 +1092,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_RDMA0>;
 			iommus = <&iommu M4U_PORT_DISP_RDMA0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>;
 		};
 
@@ -1110,7 +1102,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_RDMA1>;
 			iommus = <&iommu M4U_PORT_DISP_RDMA1>;
-			mediatek,larb = <&larb4>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>;
 		};
 
@@ -1121,7 +1112,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_RDMA2>;
 			iommus = <&iommu M4U_PORT_DISP_RDMA2>;
-			mediatek,larb = <&larb4>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0 0x1000>;
 		};
 
@@ -1132,7 +1122,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_WDMA0>;
 			iommus = <&iommu M4U_PORT_DISP_WDMA0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>;
 		};
 
@@ -1143,7 +1132,6 @@
 			power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
 			clocks = <&mmsys CLK_MM_DISP_WDMA1>;
 			iommus = <&iommu M4U_PORT_DISP_WDMA1>;
-			mediatek,larb = <&larb4>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>;
 		};
 
@@ -1394,7 +1382,6 @@
 			      <0 0x16027800 0 0x800>,	/* VDEC_HWB */
 			      <0 0x16028400 0 0x400>;	/* VDEC_HWG */
 			interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>;
-			mediatek,larb = <&larb1>;
 			iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
 				 <&iommu M4U_PORT_HW_VDEC_PP_EXT>,
 				 <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
@@ -1462,7 +1449,6 @@
 			compatible = "mediatek,mt8173-vcodec-enc";
 			reg = <0 0x18002000 0 0x1000>;	/* VENC_SYS */
 			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
-			mediatek,larb = <&larb3>;
 			iommus = <&iommu M4U_PORT_VENC_RCPU>,
 				 <&iommu M4U_PORT_VENC_REC>,
 				 <&iommu M4U_PORT_VENC_BSDMA>,
@@ -1490,7 +1476,6 @@
 			clock-names = "jpgdec-smi",
 				      "jpgdec";
 			power-domains = <&spm MT8173_POWER_DOMAIN_VENC>;
-			mediatek,larb = <&larb3>;
 			iommus = <&iommu M4U_PORT_JPGDEC_WDMA>,
 				 <&iommu M4U_PORT_JPGDEC_BSDMA>;
 		};
@@ -1524,7 +1509,6 @@
 				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
 				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
 				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
-			mediatek,larb = <&larb5>;
 			mediatek,vpu = <&vpu>;
 			clocks = <&topckgen CLK_TOP_VENC_LT_SEL>;
 			clock-names = "venc_lt_sel";
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145f13..ee684bb65daf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -992,7 +992,6 @@
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
 			clocks = <&mmsys CLK_MM_DISP_OVL0>;
 			iommus = <&iommu M4U_PORT_DISP_OVL0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x8000 0x1000>;
 		};
 
@@ -1003,7 +1002,6 @@
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
 			clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
 			iommus = <&iommu M4U_PORT_DISP_2L_OVL0_LARB0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>;
 		};
 
@@ -1014,7 +1012,6 @@
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
 			clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
 			iommus = <&iommu M4U_PORT_DISP_2L_OVL1_LARB0>;
-			mediatek,larb = <&larb0>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xa000 0x1000>;
 		};
 
@@ -1025,7 +1022,6 @@
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
 			clocks = <&mmsys CLK_MM_DISP_RDMA0>;
 			iommus = <&iommu M4U_PORT_DISP_RDMA0>;
-			mediatek,larb = <&larb0>;
 			mediatek,rdma-fifo-size = <5120>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xb000 0x1000>;
 		};
@@ -1037,7 +1033,6 @@
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
 			clocks = <&mmsys CLK_MM_DISP_RDMA1>;
 			iommus = <&iommu M4U_PORT_DISP_RDMA1>;
-			mediatek,larb = <&larb0>;
 			mediatek,rdma-fifo-size = <2048>;
 			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>;
 		};
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:23 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:23 +0800
Subject: [PATCH v5 11/16] drm/mediatek: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-12-yong.wu@mediatek.com>

MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.

CC: CK Hu <ck.hu at mediatek.com>
CC: Philipp Zabel <p.zabel at pengutronix.de>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
Acked-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c     |  9 ------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 35 ---------------------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  1 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.c      |  5 +--
 4 files changed, 1 insertion(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 971ef58ac1dc..d59353af4019 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -10,7 +10,6 @@
 #include <linux/soc/mediatek/mtk-mutex.h>
 
 #include <asm/barrier.h>
-#include <soc/mediatek/smi.h>
 
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
@@ -544,12 +543,6 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
 
 	DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
 
-	ret = mtk_smi_larb_get(comp->larb_dev);
-	if (ret) {
-		DRM_ERROR("Failed to get larb: %d\n", ret);
-		return;
-	}
-
 	ret = pm_runtime_resume_and_get(comp->dev);
 	if (ret < 0)
 		DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
@@ -557,7 +550,6 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
 
 	ret = mtk_crtc_ddp_hw_init(mtk_crtc);
 	if (ret) {
-		mtk_smi_larb_put(comp->larb_dev);
 		pm_runtime_put(comp->dev);
 		return;
 	}
@@ -594,7 +586,6 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
 
 	drm_crtc_vblank_off(crtc);
 	mtk_crtc_ddp_hw_fini(mtk_crtc);
-	mtk_smi_larb_put(comp->larb_dev);
 	ret = pm_runtime_put(comp->dev);
 	if (ret < 0)
 		DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n",
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 75bc00e17fc4..6c01492ba4df 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -449,37 +449,12 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm,
 	return ret;
 }
 
-static int mtk_ddp_get_larb_dev(struct device_node *node, struct mtk_ddp_comp *comp,
-				struct device *dev)
-{
-	struct device_node *larb_node;
-	struct platform_device *larb_pdev;
-
-	larb_node = of_parse_phandle(node, "mediatek,larb", 0);
-	if (!larb_node) {
-		dev_err(dev, "Missing mediadek,larb phandle in %pOF node\n", node);
-		return -EINVAL;
-	}
-
-	larb_pdev = of_find_device_by_node(larb_node);
-	if (!larb_pdev) {
-		dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
-		of_node_put(larb_node);
-		return -EPROBE_DEFER;
-	}
-	of_node_put(larb_node);
-	comp->larb_dev = &larb_pdev->dev;
-
-	return 0;
-}
-
 int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
 		      enum mtk_ddp_comp_id comp_id)
 {
 	struct platform_device *comp_pdev;
 	enum mtk_ddp_comp_type type;
 	struct mtk_ddp_comp_dev *priv;
-	int ret;
 
 	if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
 		return -EINVAL;
@@ -495,16 +470,6 @@ int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
 	}
 	comp->dev = &comp_pdev->dev;
 
-	/* Only DMA capable components need the LARB property */
-	if (type == MTK_DISP_OVL ||
-	    type == MTK_DISP_OVL_2L ||
-	    type == MTK_DISP_RDMA ||
-	    type == MTK_DISP_WDMA) {
-		ret = mtk_ddp_get_larb_dev(node, comp, comp->dev);
-		if (ret)
-			return ret;
-	}
-
 	if (type == MTK_DISP_BLS ||
 	    type == MTK_DISP_CCORR ||
 	    type == MTK_DISP_COLOR ||
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d976cf5..1b582262b682 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -70,7 +70,6 @@ struct mtk_ddp_comp_funcs {
 struct mtk_ddp_comp {
 	struct device *dev;
 	int irq;
-	struct device *larb_dev;
 	enum mtk_ddp_comp_id id;
 	const struct mtk_ddp_comp_funcs *funcs;
 };
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b013d56d2777..622de47239eb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -576,11 +576,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
 	pm_runtime_disable(dev);
 err_node:
 	of_node_put(private->mutex_node);
-	for (i = 0; i < DDP_COMPONENT_ID_MAX; i++) {
+	for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
 		of_node_put(private->comp_node[i]);
-		if (private->ddp_comp[i].larb_dev)
-			put_device(private->ddp_comp[i].larb_dev);
-	}
 	return ret;
 }
 
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:19 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:19 +0800
Subject: [PATCH v5 07/16] media: mtk-mdp: Use pm_runtime_resume_and_get for PM
 get_sync
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-8-yong.wu@mediatek.com>

pm_runtime_get_sync will increment pm usage counter even it failed.
This patch use pm_runtime_resume_and_get instead of pm_runtime_get
to keep usage counter balanced.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index ace4528cdc5e..93c9df15084a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -391,9 +391,9 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct mtk_mdp_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
 	if (ret < 0)
-		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
+		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
 			    ctx->id, ret);
 
 	return 0;
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:27 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:27 +0800
Subject: [PATCH v5 15/16] arm: dts: mediatek: Get rid of mediatek,
 larb for MM nodes
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-16-yong.wu@mediatek.com>

After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.

CC: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
---
 arch/arm/boot/dts/mt2701.dtsi  | 2 --
 arch/arm/boot/dts/mt7623n.dtsi | 5 -----
 2 files changed, 7 deletions(-)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index fade14284017..0a7892bcf536 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -564,7 +564,6 @@
 		clock-names = "jpgdec-smi",
 			      "jpgdec";
 		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
-		mediatek,larb = <&larb2>;
 		iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
 			 <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
 	};
@@ -577,7 +576,6 @@
 		clocks =  <&imgsys CLK_IMG_VENC>;
 		clock-names = "jpgenc";
 		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
-		mediatek,larb = <&larb2>;
 		iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>,
 			 <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>;
 	};
diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi
index 1880ac9e32cf..2e6c16164744 100644
--- a/arch/arm/boot/dts/mt7623n.dtsi
+++ b/arch/arm/boot/dts/mt7623n.dtsi
@@ -121,7 +121,6 @@
 		clock-names = "jpgdec-smi",
 			      "jpgdec";
 		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
-		mediatek,larb = <&larb2>;
 		iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
 			 <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
 	};
@@ -144,7 +143,6 @@
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
 		clocks = <&mmsys CLK_MM_DISP_OVL>;
 		iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>;
-		mediatek,larb = <&larb0>;
 	};
 
 	rdma0: rdma at 14008000 {
@@ -154,7 +152,6 @@
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_LOW>;
 		clocks = <&mmsys CLK_MM_DISP_RDMA>;
 		iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA>;
-		mediatek,larb = <&larb0>;
 	};
 
 	wdma at 14009000 {
@@ -164,7 +161,6 @@
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_LOW>;
 		clocks = <&mmsys CLK_MM_DISP_WDMA>;
 		iommus = <&iommu MT2701_M4U_PORT_DISP_WDMA>;
-		mediatek,larb = <&larb0>;
 	};
 
 	bls: pwm at 1400a000 {
@@ -215,7 +211,6 @@
 		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
 		clocks = <&mmsys CLK_MM_DISP_RDMA1>;
 		iommus = <&iommu MT2701_M4U_PORT_DISP_RDMA1>;
-		mediatek,larb = <&larb0>;
 	};
 
 	dpi0: dpi at 14014000 {
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:25 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:25 +0800
Subject: [PATCH v5 13/16] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-14-yong.wu@mediatek.com>

MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.

CC: Tiffany Lin <tiffany.lin at mediatek.com>
CC: Irui Wang <irui.wang at mediatek.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
Acked-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c   | 37 ++-------------
 .../platform/mtk-vcodec/mtk_vcodec_drv.h      |  3 --
 .../platform/mtk-vcodec/mtk_vcodec_enc.c      |  1 -
 .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c   | 46 ++-----------------
 4 files changed, 10 insertions(+), 77 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 32e1858e9f1d..2b3562e47f4f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/pm_runtime.h>
-#include <soc/mediatek/smi.h>
 
 #include "mtk_vcodec_dec_pm.h"
 #include "mtk_vcodec_util.h"
 
 int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 {
-	struct device_node *node;
 	struct platform_device *pdev;
 	struct mtk_vcodec_pm *pm;
 	struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 	pm = &mtkdev->pm;
 	pm->mtkdev = mtkdev;
 	dec_clk = &pm->vdec_clk;
-	node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
-	if (!node) {
-		mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
-		return -1;
-	}
 
-	pdev = of_find_device_by_node(node);
-	of_node_put(node);
-	if (WARN_ON(!pdev)) {
-		return -1;
-	}
-	pm->larbvdec = &pdev->dev;
 	pdev = mtkdev->plat_dev;
 	pm->dev = &pdev->dev;
 
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 		dec_clk->clk_info = devm_kcalloc(&pdev->dev,
 			dec_clk->clk_num, sizeof(*clk_info),
 			GFP_KERNEL);
-		if (!dec_clk->clk_info) {
-			ret = -ENOMEM;
-			goto put_device;
-		}
+		if (!dec_clk->clk_info)
+			return -ENOMEM;
 	} else {
 		mtk_v4l2_err("Failed to get vdec clock count");
-		ret = -EINVAL;
-		goto put_device;
+		return -EINVAL;
 	}
 
 	for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
 			"clock-names", i, &clk_info->clk_name);
 		if (ret) {
 			mtk_v4l2_err("Failed to get clock name id = %d", i);
-			goto put_device;
+			return ret;
 		}
 		clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
 			clk_info->clk_name);
 		if (IS_ERR(clk_info->vcodec_clk)) {
 			mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
 				clk_info->clk_name);
-			ret = PTR_ERR(clk_info->vcodec_clk);
-			goto put_device;
+			return PTR_ERR(clk_info->vcodec_clk);
 		}
 	}
 
 	pm_runtime_enable(&pdev->dev);
 	return 0;
-put_device:
-	put_device(pm->larbvdec);
-	return ret;
 }
 
 void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
 {
 	pm_runtime_disable(dev->pm.dev);
-	put_device(dev->pm.larbvdec);
 }
 
 void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
@@ -121,11 +100,6 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
 		}
 	}
 
-	ret = mtk_smi_larb_get(pm->larbvdec);
-	if (ret) {
-		mtk_v4l2_err("mtk_smi_larb_get larbvdec fail %d", ret);
-		goto error;
-	}
 	return;
 
 error:
@@ -138,7 +112,6 @@ void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
 	struct mtk_vcodec_clk *dec_clk = &pm->vdec_clk;
 	int i = 0;
 
-	mtk_smi_larb_put(pm->larbvdec);
 	for (i = dec_clk->clk_num - 1; i >= 0; i--)
 		clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
 }
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 869d958d2b99..659790398809 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -189,10 +189,7 @@ struct mtk_vcodec_clk {
  */
 struct mtk_vcodec_pm {
 	struct mtk_vcodec_clk	vdec_clk;
-	struct device	*larbvdec;
-
 	struct mtk_vcodec_clk	venc_clk;
-	struct device	*larbvenc;
 	struct device	*dev;
 	struct mtk_vcodec_dev	*mtkdev;
 };
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 4831052f475d..59816981735b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -8,7 +8,6 @@
 #include <media/v4l2-event.h>
 #include <media/v4l2-mem2mem.h>
 #include <media/videobuf2-dma-contig.h>
-#include <soc/mediatek/smi.h>
 #include <linux/pm_runtime.h>
 
 #include "mtk_vcodec_drv.h"
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
index 1b2e4930ed27..78b99ff882ae 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
@@ -8,58 +8,36 @@
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
 #include <linux/pm_runtime.h>
-#include <soc/mediatek/smi.h>
 
 #include "mtk_vcodec_enc_pm.h"
 #include "mtk_vcodec_util.h"
 
 int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
 {
-	struct device_node *node;
 	struct platform_device *pdev;
 	struct mtk_vcodec_pm *pm;
 	struct mtk_vcodec_clk *enc_clk;
 	struct mtk_vcodec_clk_info *clk_info;
 	int ret = 0, i = 0;
-	struct device *dev;
 
 	pdev = mtkdev->plat_dev;
 	pm = &mtkdev->pm;
 	memset(pm, 0, sizeof(struct mtk_vcodec_pm));
 	pm->mtkdev = mtkdev;
 	pm->dev = &pdev->dev;
-	dev = &pdev->dev;
 	enc_clk = &pm->venc_clk;
 
-	node = of_parse_phandle(dev->of_node, "mediatek,larb", 0);
-	if (!node) {
-		mtk_v4l2_err("no mediatek,larb found");
-		return -ENODEV;
-	}
-	pdev = of_find_device_by_node(node);
-	of_node_put(node);
-	if (!pdev) {
-		mtk_v4l2_err("no mediatek,larb device found");
-		return -ENODEV;
-	}
-	pm->larbvenc = &pdev->dev;
-	pdev = mtkdev->plat_dev;
-	pm->dev = &pdev->dev;
-
 	enc_clk->clk_num = of_property_count_strings(pdev->dev.of_node,
 		"clock-names");
 	if (enc_clk->clk_num > 0) {
 		enc_clk->clk_info = devm_kcalloc(&pdev->dev,
 			enc_clk->clk_num, sizeof(*clk_info),
 			GFP_KERNEL);
-		if (!enc_clk->clk_info) {
-			ret = -ENOMEM;
-			goto put_larbvenc;
-		}
+		if (!enc_clk->clk_info)
+			return -ENOMEM;
 	} else {
 		mtk_v4l2_err("Failed to get venc clock count");
-		ret = -EINVAL;
-		goto put_larbvenc;
+		return -EINVAL;
 	}
 
 	for (i = 0; i < enc_clk->clk_num; i++) {
@@ -68,29 +46,23 @@ int mtk_vcodec_init_enc_pm(struct mtk_vcodec_dev *mtkdev)
 			"clock-names", i, &clk_info->clk_name);
 		if (ret) {
 			mtk_v4l2_err("venc failed to get clk name %d", i);
-			goto put_larbvenc;
+			return ret;
 		}
 		clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
 			clk_info->clk_name);
 		if (IS_ERR(clk_info->vcodec_clk)) {
 			mtk_v4l2_err("venc devm_clk_get (%d)%s fail", i,
 				clk_info->clk_name);
-			ret = PTR_ERR(clk_info->vcodec_clk);
-			goto put_larbvenc;
+			return PTR_ERR(clk_info->vcodec_clk);
 		}
 	}
 
 	return 0;
-
-put_larbvenc:
-	put_device(pm->larbvenc);
-	return ret;
 }
 
 void mtk_vcodec_release_enc_pm(struct mtk_vcodec_dev *mtkdev)
 {
 	pm_runtime_disable(mtkdev->pm.dev);
-	put_device(mtkdev->pm.larbvenc);
 }
 
 
@@ -108,13 +80,6 @@ void mtk_vcodec_enc_clock_on(struct mtk_vcodec_pm *pm)
 		}
 	}
 
-	ret = mtk_smi_larb_get(pm->larbvenc);
-	if (ret) {
-		mtk_v4l2_err("mtk_smi_larb_get larb3 fail %d", ret);
-		goto clkerr;
-	}
-	return;
-
 clkerr:
 	for (i -= 1; i >= 0; i--)
 		clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
@@ -125,7 +90,6 @@ void mtk_vcodec_enc_clock_off(struct mtk_vcodec_pm *pm)
 	struct mtk_vcodec_clk *enc_clk = &pm->venc_clk;
 	int i = 0;
 
-	mtk_smi_larb_put(pm->larbvenc);
 	for (i = enc_clk->clk_num - 1; i >= 0; i--)
 		clk_disable_unprepare(enc_clk->clk_info[i].vcodec_clk);
 }
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:20 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:20 +0800
Subject: [PATCH v5 08/16] media: mtk-mdp: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-9-yong.wu@mediatek.com>

MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.

CC: Minghsiu Tsai <minghsiu.tsai at mediatek.com>
CC: Houlong Wei <houlong.wei at mediatek.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 40 -------------------
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  2 -
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  1 -
 3 files changed, 43 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index b3426a551bea..1e3833f1c9ae 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -9,7 +9,6 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_platform.h>
-#include <soc/mediatek/smi.h>
 
 #include "mtk_mdp_comp.h"
 
@@ -18,14 +17,6 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
 {
 	int i, err;
 
-	if (comp->larb_dev) {
-		err = mtk_smi_larb_get(comp->larb_dev);
-		if (err)
-			dev_err(dev,
-				"failed to get larb, err %d. type:%d\n",
-				err, comp->type);
-	}
-
 	for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
 		if (IS_ERR(comp->clk[i]))
 			continue;
@@ -46,17 +37,12 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
 			continue;
 		clk_disable_unprepare(comp->clk[i]);
 	}
-
-	if (comp->larb_dev)
-		mtk_smi_larb_put(comp->larb_dev);
 }
 
 int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
 		      struct mtk_mdp_comp *comp,
 		      enum mtk_mdp_comp_type comp_type)
 {
-	struct device_node *larb_node;
-	struct platform_device *larb_pdev;
 	int ret;
 	int i;
 
@@ -77,32 +63,6 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
 			break;
 	}
 
-	/* Only DMA capable components need the LARB property */
-	comp->larb_dev = NULL;
-	if (comp->type != MTK_MDP_RDMA &&
-	    comp->type != MTK_MDP_WDMA &&
-	    comp->type != MTK_MDP_WROT)
-		return 0;
-
-	larb_node = of_parse_phandle(node, "mediatek,larb", 0);
-	if (!larb_node) {
-		dev_err(dev,
-			"Missing mediadek,larb phandle in %pOF node\n", node);
-		ret = -EINVAL;
-		goto put_dev;
-	}
-
-	larb_pdev = of_find_device_by_node(larb_node);
-	if (!larb_pdev) {
-		dev_warn(dev, "Waiting for larb device %pOF\n", larb_node);
-		of_node_put(larb_node);
-		ret = -EPROBE_DEFER;
-		goto put_dev;
-	}
-	of_node_put(larb_node);
-
-	comp->larb_dev = &larb_pdev->dev;
-
 	return 0;
 
 put_dev:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 1bf0242cce46..36bc1b8f6222 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -27,14 +27,12 @@ enum mtk_mdp_comp_type {
  * @node:	list node to track sibing MDP components
  * @dev_node:	component device node
  * @clk:	clocks required for component
- * @larb_dev:	SMI device required for component
  * @type:	component type
  */
 struct mtk_mdp_comp {
 	struct list_head	node;
 	struct device_node	*dev_node;
 	struct clk		*clk[2];
-	struct device		*larb_dev;
 	enum mtk_mdp_comp_type	type;
 };
 
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 976aa1f4829b..70a8eab16863 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -17,7 +17,6 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/workqueue.h>
-#include <soc/mediatek/smi.h>
 
 #include "mtk_mdp_core.h"
 #include "mtk_mdp_m2m.h"
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:26 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:26 +0800
Subject: [PATCH v5 14/16] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-15-yong.wu@mediatek.com>

After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.

CC: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Evan Green <evgreen at chromium.org>
---
 drivers/memory/mtk-smi.c   | 14 --------------
 include/soc/mediatek/smi.h | 20 --------------------
 2 files changed, 34 deletions(-)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index c5fb51f73b34..7c61c924e220 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -134,20 +134,6 @@ static void mtk_smi_clk_disable(const struct mtk_smi *smi)
 	clk_disable_unprepare(smi->clk_apb);
 }
 
-int mtk_smi_larb_get(struct device *larbdev)
-{
-	int ret = pm_runtime_resume_and_get(larbdev);
-
-	return (ret < 0) ? ret : 0;
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_get);
-
-void mtk_smi_larb_put(struct device *larbdev)
-{
-	pm_runtime_put_sync(larbdev);
-}
-EXPORT_SYMBOL_GPL(mtk_smi_larb_put);
-
 static int
 mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
 {
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
index 15e3397cec58..11f7d6b59642 100644
--- a/include/soc/mediatek/smi.h
+++ b/include/soc/mediatek/smi.h
@@ -19,26 +19,6 @@ struct mtk_smi_larb_iommu {
 	unsigned char  bank[32];
 };
 
-/*
- * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
- *                   It also initialize some basic setting(like iommu).
- * mtk_smi_larb_put: Disable the power domain and clocks for this local arbiter.
- * Both should be called in non-atomic context.
- *
- * Returns 0 if successful, negative on failure.
- */
-int mtk_smi_larb_get(struct device *larbdev);
-void mtk_smi_larb_put(struct device *larbdev);
-
-#else
-
-static inline int mtk_smi_larb_get(struct device *larbdev)
-{
-	return 0;
-}
-
-static inline void mtk_smi_larb_put(struct device *larbdev) { }
-
 #endif
 
 #endif
-- 
2.18.0

From yong.wu at mediatek.com  Sat Apr 10 10:11:22 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Sat, 10 Apr 2021 17:11:22 +0800
Subject: [PATCH v5 10/16] drm/mediatek: Add pm runtime support for ovl and rdma
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <20210410091128.31823-11-yong.wu@mediatek.com>

From: Yongqiang Niu <yongqiang.niu at mediatek.com>

Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.

This is a preparing patch that smi cleaning up "mediatek,larb".

CC: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
(Yong: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync)
Acked-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c  |  9 ++++++++-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c |  9 ++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 12 +++++++++++-
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 961f87f8d4d1..ee464ccd8a9c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -11,6 +11,7 @@
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/soc/mediatek/mtk-cmdq.h>
 
 #include "mtk_disp_drv.h"
@@ -415,15 +416,21 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	pm_runtime_enable(dev);
+
 	ret = component_add(dev, &mtk_disp_ovl_component_ops);
-	if (ret)
+	if (ret) {
+		pm_runtime_disable(dev);
 		dev_err(dev, "Failed to add component: %d\n", ret);
+	}
 
 	return ret;
 }
 
 static int mtk_disp_ovl_remove(struct platform_device *pdev)
 {
+	pm_runtime_disable(&pdev->dev);
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 728aaadfea8c..9565f3de773e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -9,6 +9,7 @@
 #include <linux/of_device.h>
 #include <linux/of_irq.h>
 #include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
 #include <linux/soc/mediatek/mtk-cmdq.h>
 
 #include "mtk_disp_drv.h"
@@ -329,9 +330,13 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 
+	pm_runtime_enable(dev);
+
 	ret = component_add(dev, &mtk_disp_rdma_component_ops);
-	if (ret)
+	if (ret) {
+		pm_runtime_disable(dev);
 		dev_err(dev, "Failed to add component: %d\n", ret);
+	}
 
 	return ret;
 }
@@ -340,6 +345,8 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
 {
 	component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
 
+	pm_runtime_disable(&pdev->dev);
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 69d23ce56d2c..971ef58ac1dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -550,9 +550,15 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
 		return;
 	}
 
+	ret = pm_runtime_resume_and_get(comp->dev);
+	if (ret < 0)
+		DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
+			      ret);
+
 	ret = mtk_crtc_ddp_hw_init(mtk_crtc);
 	if (ret) {
 		mtk_smi_larb_put(comp->larb_dev);
+		pm_runtime_put(comp->dev);
 		return;
 	}
 
@@ -565,7 +571,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;
+	int i, ret;
 
 	DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
 	if (!mtk_crtc->enabled)
@@ -589,6 +595,10 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
 	drm_crtc_vblank_off(crtc);
 	mtk_crtc_ddp_hw_fini(mtk_crtc);
 	mtk_smi_larb_put(comp->larb_dev);
+	ret = pm_runtime_put(comp->dev);
+	if (ret < 0)
+		DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n",
+			      ret);
 
 	mtk_crtc->enabled = false;
 }
-- 
2.18.0

From maz at kernel.org  Sat Apr 10 10:54:41 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 10 Apr 2021 10:54:41 +0100
Subject: [RFC] KVM: arm64: Support FEAT_CCIDX
In-Reply-To: <1618042597-59294-1-git-send-email-zhangshaokun@hisilicon.com>
References: <1618042597-59294-1-git-send-email-zhangshaokun@hisilicon.com>
Message-ID: <875z0ufori.wl-maz@kernel.org>

On Sat, 10 Apr 2021 09:16:37 +0100,
Shaokun Zhang <zhangshaokun at hisilicon.com> wrote:
> 
> CCSIDR_EL1 can be implemented as 64-bit format inferred by CCIDX field
> in ID_AA64MMFR2_EL1. The bits of Numsets and Associativity are different
> from the 32-bit format. Let's support this feature.
> 
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: James Morse <james.morse at arm.com>
> Cc: Alexandru Elisei <alexandru.elisei at arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun at hisilicon.com>
> ---
>  arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++--------
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 52fdb9a015a4..0dc822cef20b 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -18,6 +18,7 @@
>  
>  #include <asm/cacheflush.h>
>  #include <asm/cputype.h>
> +#include <asm/cpufeature.h>

If you are going to add this (why?), at least add it in alphabetic order.

>  #include <asm/debug-monitors.h>
>  #include <asm/esr.h>
>  #include <asm/kvm_arm.h>
> @@ -95,9 +96,9 @@ static u32 cache_levels;
>  #define CSSELR_MAX 14
>  
>  /* Which cache CCSIDR represents depends on CSSELR value. */
> -static u32 get_ccsidr(u32 csselr)
> +static u64 get_ccsidr(u32 csselr)
>  {
> -	u32 ccsidr;
> +	u64 ccsidr;
>  
>  	/* Make sure noone else changes CSSELR during this! */
>  	local_irq_disable();
> @@ -1275,12 +1276,16 @@ static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  			  const struct sys_reg_desc *r)
>  {
> -	u32 csselr;
> +	u32 csselr, ccidx;
> +	u64 mmfr2;
>  
>  	if (p->is_write)
>  		return write_to_read_only(vcpu, p, r);
>  
>  	csselr = vcpu_read_sys_reg(vcpu, CSSELR_EL1);
> +	mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
> +	ccidx = cpuid_feature_extract_unsigned_field(mmfr2,
> +						     ID_AA64MMFR2_CCIDX_SHIFT);

What happens on an asymmetric system where only some of the CPUs have
FEAT_CCIDX?

>  	p->regval = get_ccsidr(csselr);
>  
>  	/*
> @@ -1295,8 +1300,13 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  	 * geometry (which is not permitted by the architecture), they would
>  	 * only do so for virtually indexed caches.]
>  	 */
> -	if (!(csselr & 1)) // data or unified cache
> -		p->regval &= ~GENMASK(27, 3);
> +	if (!(csselr & 1)) { // data or unified cache
> +		if (ccidx)
> +			p->regval &= ~(GENMASK(23, 3) | GENMASK(55, 32));
> +		else
> +			p->regval &= ~GENMASK(27, 3);
> +	}
> +
>  	return true;
>  }
>  
> @@ -2521,7 +2531,7 @@ static bool is_valid_cache(u32 val)
>  static int demux_c15_get(u64 id, void __user *uaddr)
>  {
>  	u32 val;
> -	u32 __user *uval = uaddr;
> +	u64 __user *uval = uaddr;

What? Has the user API changed while I wasn't looking? Getting CCSIDR
can only return a 32bit quantity on AArch32. In fact, CCSIDR is
*always* 32bit, CCIDX or not. I have no idea what you are trying to do
here, but at best you are now corrupting 32bit of userspace.

>  
>  	/* Fail if we have unknown bits set. */
>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> @@ -2545,8 +2555,9 @@ static int demux_c15_get(u64 id, void __user *uaddr)
>  
>  static int demux_c15_set(u64 id, void __user *uaddr)
>  {
> -	u32 val, newval;
> -	u32 __user *uval = uaddr;
> +	u32 val;
> +	u64 newval;
> +	u64 __user *uval = uaddr;

Same brokenness.

>  
>  	/* Fail if we have unknown bits set. */
>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK

What about CCSIDR2_EL1, which is mandatory when FEAT_CCSIDX is
present? How about the AArch32 handling of that register? I don't
think you have though this one through.

Another question is: why should we care at all? Why don't we drop all
that and only implement a virtual cache topology? A VM shouldn't care
at all about this, and we are already lying about the topology anyway.
We could even get the VMM to set whatever stupid topology it wants for
the sake of it (and to restore previously created VMs).

	M.

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


From kernelfans at gmail.com  Sat Apr 10 10:56:46 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:46 +0800
Subject: [RFC 0/8] use __create_pgd_mapping() to implement idmap and unify
 codes
Message-ID: <20210410095654.24102-1-kernelfans@gmail.com>

Hi everyone,

Sorry to bring up this RFC in a hurry, since I paid attention to "arm64:
MMU enabled kexec relocation" too late and now it has advanced to "[PATCH
v13 00/18] arm64: MMU enabled kexec relocation".

And I think maybe that work can be based on my series.

I have raised my concern when reviewing "[PATCH v12 00/17] arm64: MMU
enabled kexec relocation"
  https://linuxlists.cc/l/1/linux-kernel/t/3923858/(patch_v12_00_17)_arm64:_mmu_enabled_kexec_relocation#post3948651
  (It seems that lore.kernel.org has not archived my reply)
  Where I wrote:
    Then the processes may be neat (I hope so):
    -1. set up identity map in machine_kexec_post_load(), instead of
    copying linear map.
    -2. Also past this temporary identity map to arm64_relocate_new_kernel()
    -3. in arm64_relocate_new_kernel(), just load identity map and
    re-enable MMU. After copying, just turn off MMU.

In a short discuss off-line, Pavel pointed to me
  https://lore.kernel.org/linux-arm-kernel/CA+CK2bC2KwWufE1DWa4szn_hQ1dbjDVHgYUu7=J4O_kvKXTrHg at mail.gmail.com/#t,
which prevent him from using idmap to implement his series.


After digging into the code, I find that if extending one more pgtable level,
the __create_pgd_mapping() routines can be re-used for idmap_pg_dir and
init_pg_dir. Besides, it can be re-used for trans_pgd_idmap_page().
That is what this series do.

As for "[PATCHv13 00/18] arm64: MMU enabled kexec relocation", here is
my two cents:
  -1. a call to create_idmap() API in machine_kexec_post_load(), to map
src + dst + arm64_relocate_new_kernel().
  -2. turn on MMU in arm64_relocate_new_kernel(), after done, turn off.

Sorry again for a hurry. It can be compiled, but far from good.

Thanks,

Pingfan

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org

Pingfan Liu (8):
  arm64/mm: split out __create_pgd_mapping() routines
  arm64/mm: change __create_pgd_mapping() prototype to accept nr_entries
    and introduce create_idmap()
  arm64/mm: change __create_pgd_mapping() prototype to accept extra info
    for allocator
  arm64/mm: enable __create_pgd_mapping() to run across different
    pgtable
  arm64/mm: make trans_pgd_idmap_page() use create_idmap()
  arm64/mm: introduce pgtable allocator for head
  arm64/pgtable-prot.h: reorganize to cope with asm
  arm64/head: convert idmap_pg_dir and init_pg_dir to
    __create_pgd_mapping()

 arch/arm64/Kconfig                    |   4 +
 arch/arm64/include/asm/pgalloc.h      |  28 ++
 arch/arm64/include/asm/pgtable-prot.h |  34 ++-
 arch/arm64/kernel/head.S              | 190 ++++----------
 arch/arm64/mm/Makefile                |   2 +
 arch/arm64/mm/idmap_mmu.c             |  46 ++++
 arch/arm64/mm/mmu.c                   | 358 ++++++--------------------
 arch/arm64/mm/mmu_include.c           | 284 ++++++++++++++++++++
 arch/arm64/mm/trans_pgd.c             |  59 ++---
 9 files changed, 535 insertions(+), 470 deletions(-)
 create mode 100644 arch/arm64/mm/idmap_mmu.c
 create mode 100644 arch/arm64/mm/mmu_include.c

-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:47 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:47 +0800
Subject: [RFC 1/8] arm64/mm: split out __create_pgd_mapping() routines
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-2-kernelfans@gmail.com>

Split out the routines for __create_pgd_mapping(), in order to use it
to generate two sets of operations for CONFIG_PGTABLE_LEVELS and
CONFIG_PGTABLE_LEVELS + 1

Later the one generated with 'CONFIG_PGTABLE_LEVELS + 1' can be used for
idmap if VA_BITS is too small to cover system RAM, which is located
sufficiently high in the physical address space.

Later, idmap can be created by __create_pgd_mapping() directly.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/Kconfig          |   4 +
 arch/arm64/mm/Makefile      |   2 +
 arch/arm64/mm/idmap_mmu.c   |  45 ++++++
 arch/arm64/mm/mmu.c         | 263 +-----------------------------------
 arch/arm64/mm/mmu_include.c | 262 +++++++++++++++++++++++++++++++++++
 5 files changed, 315 insertions(+), 261 deletions(-)
 create mode 100644 arch/arm64/mm/idmap_mmu.c
 create mode 100644 arch/arm64/mm/mmu_include.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..989fc501a1b4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -327,6 +327,10 @@ config PGTABLE_LEVELS
 	default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
 	default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
 
+config IDMAP_PGTABLE_EXPAND
+	def_bool y
+	depends on (ARM64_4K_PAGES && ARM64_VA_BITS_39) || (ARM64_64K_PAGES && ARM64_VA_BITS_42)
+
 config ARCH_SUPPORTS_UPROBES
 	def_bool y
 
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index f188c9092696..f9283cb9a201 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -3,6 +3,8 @@ 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
+
+obj-$(CONFIG_IDMAP_PGTABLE_EXPAND)	+= idmap_mmu.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/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
new file mode 100644
index 000000000000..7e9a4f4017d3
--- /dev/null
+++ b/arch/arm64/mm/idmap_mmu.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/mm.h>
+
+#include <asm/barrier.h>
+#include <asm/cputype.h>
+#include <asm/fixmap.h>
+#include <asm/kasan.h>
+#include <asm/kernel-pgtable.h>
+#include <asm/sections.h>
+#include <asm/setup.h>
+#include <linux/sizes.h>
+#include <asm/tlb.h>
+#include <asm/mmu_context.h>
+#include <asm/ptdump.h>
+#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
+
+#if CONFIG_IDMAP_PGTABLE_EXPAND
+
+#if CONFIG_PGTABLE_LEVELS == 2
+#define EXTEND_LEVEL 3
+#elif CONFIG_PGTABLE_LEVELS == 3
+#define EXTEND_LEVEL 4
+#endif
+
+#undef CONFIG_PGTABLE_LEVELS
+#define CONFIG_PGTABLE_LEVELS EXTEND_LEVEL
+
+
+#include "./mmu_include.c"
+
+void __create_pgd_mapping_extend(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
+				 unsigned long virt, phys_addr_t size,
+				 pgprot_t prot,
+				 phys_addr_t (*pgtable_alloc)(int),
+				 int flags)
+{
+	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size, prot, pgtable_alloc, flags);
+}
+#endif
+
+
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..56e4f25e8d6d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -37,9 +37,6 @@
 #include <asm/tlbflush.h>
 #include <asm/pgalloc.h>
 
-#define NO_BLOCK_MAPPINGS	BIT(0)
-#define NO_CONT_MAPPINGS	BIT(1)
-
 u64 idmap_t0sz = TCR_T0SZ(VA_BITS_MIN);
 u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
 
@@ -116,264 +113,6 @@ static phys_addr_t __init early_pgtable_alloc(int shift)
 	return phys;
 }
 
-static bool pgattr_change_is_safe(u64 old, u64 new)
-{
-	/*
-	 * The following mapping attributes may be updated in live
-	 * kernel mappings without the need for break-before-make.
-	 */
-	pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE | PTE_NG;
-
-	/* creating or taking down mappings is always safe */
-	if (old == 0 || new == 0)
-		return true;
-
-	/* live contiguous mappings may not be manipulated at all */
-	if ((old | new) & PTE_CONT)
-		return false;
-
-	/* Transitioning from Non-Global to Global is unsafe */
-	if (old & ~new & PTE_NG)
-		return false;
-
-	/*
-	 * Changing the memory type between Normal and Normal-Tagged is safe
-	 * since Tagged is considered a permission attribute from the
-	 * mismatched attribute aliases perspective.
-	 */
-	if (((old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
-	     (old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)) &&
-	    ((new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
-	     (new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)))
-		mask |= PTE_ATTRINDX_MASK;
-
-	return ((old ^ new) & ~mask) == 0;
-}
-
-static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot)
-{
-	pte_t *ptep;
-
-	ptep = pte_set_fixmap_offset(pmdp, addr);
-	do {
-		pte_t old_pte = READ_ONCE(*ptep);
-
-		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
-
-		/*
-		 * After the PTE entry has been populated once, we
-		 * only allow updates to the permission attributes.
-		 */
-		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
-					      READ_ONCE(pte_val(*ptep))));
-
-		phys += PAGE_SIZE;
-	} while (ptep++, addr += PAGE_SIZE, addr != end);
-
-	pte_clear_fixmap();
-}
-
-static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
-				unsigned long end, phys_addr_t phys,
-				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int),
-				int flags)
-{
-	unsigned long next;
-	pmd_t pmd = READ_ONCE(*pmdp);
-
-	BUG_ON(pmd_sect(pmd));
-	if (pmd_none(pmd)) {
-		phys_addr_t pte_phys;
-		BUG_ON(!pgtable_alloc);
-		pte_phys = pgtable_alloc(PAGE_SHIFT);
-		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
-		pmd = READ_ONCE(*pmdp);
-	}
-	BUG_ON(pmd_bad(pmd));
-
-	do {
-		pgprot_t __prot = prot;
-
-		next = pte_cont_addr_end(addr, end);
-
-		/* use a contiguous mapping if the range is suitably aligned */
-		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
-			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
-
-		init_pte(pmdp, addr, next, phys, __prot);
-
-		phys += next - addr;
-	} while (addr = next, addr != end);
-}
-
-static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot,
-		     phys_addr_t (*pgtable_alloc)(int), int flags)
-{
-	unsigned long next;
-	pmd_t *pmdp;
-
-	pmdp = pmd_set_fixmap_offset(pudp, addr);
-	do {
-		pmd_t old_pmd = READ_ONCE(*pmdp);
-
-		next = pmd_addr_end(addr, end);
-
-		/* try section mapping first */
-		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
-		    (flags & NO_BLOCK_MAPPINGS) == 0) {
-			pmd_set_huge(pmdp, phys, prot);
-
-			/*
-			 * After the PMD entry has been populated once, we
-			 * only allow updates to the permission attributes.
-			 */
-			BUG_ON(!pgattr_change_is_safe(pmd_val(old_pmd),
-						      READ_ONCE(pmd_val(*pmdp))));
-		} else {
-			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
-
-			BUG_ON(pmd_val(old_pmd) != 0 &&
-			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
-		}
-		phys += next - addr;
-	} while (pmdp++, addr = next, addr != end);
-
-	pmd_clear_fixmap();
-}
-
-static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
-				unsigned long end, phys_addr_t phys,
-				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int), int flags)
-{
-	unsigned long next;
-	pud_t pud = READ_ONCE(*pudp);
-
-	/*
-	 * Check for initial section mappings in the pgd/pud.
-	 */
-	BUG_ON(pud_sect(pud));
-	if (pud_none(pud)) {
-		phys_addr_t pmd_phys;
-		BUG_ON(!pgtable_alloc);
-		pmd_phys = pgtable_alloc(PMD_SHIFT);
-		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
-		pud = READ_ONCE(*pudp);
-	}
-	BUG_ON(pud_bad(pud));
-
-	do {
-		pgprot_t __prot = prot;
-
-		next = pmd_cont_addr_end(addr, end);
-
-		/* use a contiguous mapping if the range is suitably aligned */
-		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
-			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
-
-		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
-
-		phys += next - addr;
-	} while (addr = next, addr != end);
-}
-
-static inline bool use_1G_block(unsigned long addr, unsigned long next,
-			unsigned long phys)
-{
-	if (PAGE_SHIFT != 12)
-		return false;
-
-	if (((addr | next | phys) & ~PUD_MASK) != 0)
-		return false;
-
-	return true;
-}
-
-static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
-			   phys_addr_t phys, pgprot_t prot,
-			   phys_addr_t (*pgtable_alloc)(int),
-			   int flags)
-{
-	unsigned long next;
-	pud_t *pudp;
-	p4d_t *p4dp = p4d_offset(pgdp, addr);
-	p4d_t p4d = READ_ONCE(*p4dp);
-
-	if (p4d_none(p4d)) {
-		phys_addr_t pud_phys;
-		BUG_ON(!pgtable_alloc);
-		pud_phys = pgtable_alloc(PUD_SHIFT);
-		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
-		p4d = READ_ONCE(*p4dp);
-	}
-	BUG_ON(p4d_bad(p4d));
-
-	pudp = pud_set_fixmap_offset(p4dp, addr);
-	do {
-		pud_t old_pud = READ_ONCE(*pudp);
-
-		next = pud_addr_end(addr, end);
-
-		/*
-		 * For 4K granule only, attempt to put down a 1GB block
-		 */
-		if (use_1G_block(addr, next, phys) &&
-		    (flags & NO_BLOCK_MAPPINGS) == 0) {
-			pud_set_huge(pudp, phys, prot);
-
-			/*
-			 * After the PUD entry has been populated once, we
-			 * only allow updates to the permission attributes.
-			 */
-			BUG_ON(!pgattr_change_is_safe(pud_val(old_pud),
-						      READ_ONCE(pud_val(*pudp))));
-		} else {
-			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
-
-			BUG_ON(pud_val(old_pud) != 0 &&
-			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
-		}
-		phys += next - addr;
-	} while (pudp++, addr = next, addr != end);
-
-	pud_clear_fixmap();
-}
-
-static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
-				 unsigned long virt, phys_addr_t size,
-				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
-				 int flags)
-{
-	unsigned long addr, end, next;
-	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
-
-	/*
-	 * If the virtual and physical address don't have the same offset
-	 * within a page, we cannot map the region as the caller expects.
-	 */
-	if (WARN_ON((phys ^ virt) & ~PAGE_MASK))
-		return;
-
-	phys &= PAGE_MASK;
-	addr = virt & PAGE_MASK;
-	end = PAGE_ALIGN(virt + size);
-
-	do {
-		next = pgd_addr_end(addr, end);
-		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
-			       flags);
-		phys += next - addr;
-	} while (pgdp++, addr = next, addr != end);
-}
-
 static phys_addr_t __pgd_pgtable_alloc(int shift)
 {
 	void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
@@ -404,6 +143,8 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
 	return pa;
 }
 
+#include "./mmu_include.c"
+
 /*
  * This function can only be used to modify existing table entries,
  * without allocating new levels of table. Note that this permits the
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
new file mode 100644
index 000000000000..e9ebdffe860b
--- /dev/null
+++ b/arch/arm64/mm/mmu_include.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#define NO_BLOCK_MAPPINGS	BIT(0)
+#define NO_CONT_MAPPINGS	BIT(1)
+
+static bool pgattr_change_is_safe(u64 old, u64 new)
+{
+	/*
+	 * The following mapping attributes may be updated in live
+	 * kernel mappings without the need for break-before-make.
+	 */
+	pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE | PTE_NG;
+
+	/* creating or taking down mappings is always safe */
+	if (old == 0 || new == 0)
+		return true;
+
+	/* live contiguous mappings may not be manipulated at all */
+	if ((old | new) & PTE_CONT)
+		return false;
+
+	/* Transitioning from Non-Global to Global is unsafe */
+	if (old & ~new & PTE_NG)
+		return false;
+
+	/*
+	 * Changing the memory type between Normal and Normal-Tagged is safe
+	 * since Tagged is considered a permission attribute from the
+	 * mismatched attribute aliases perspective.
+	 */
+	if (((old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
+	     (old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)) &&
+	    ((new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
+	     (new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)))
+		mask |= PTE_ATTRINDX_MASK;
+
+	return ((old ^ new) & ~mask) == 0;
+}
+
+static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
+		     phys_addr_t phys, pgprot_t prot)
+{
+	pte_t *ptep;
+
+	ptep = pte_set_fixmap_offset(pmdp, addr);
+	do {
+		pte_t old_pte = READ_ONCE(*ptep);
+
+		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+
+		/*
+		 * After the PTE entry has been populated once, we
+		 * only allow updates to the permission attributes.
+		 */
+		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
+					      READ_ONCE(pte_val(*ptep))));
+
+		phys += PAGE_SIZE;
+	} while (ptep++, addr += PAGE_SIZE, addr != end);
+
+	pte_clear_fixmap();
+}
+
+static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
+				unsigned long end, phys_addr_t phys,
+				pgprot_t prot,
+				phys_addr_t (*pgtable_alloc)(int),
+				int flags)
+{
+	unsigned long next;
+	pmd_t pmd = READ_ONCE(*pmdp);
+
+	BUG_ON(pmd_sect(pmd));
+	if (pmd_none(pmd)) {
+		phys_addr_t pte_phys;
+		BUG_ON(!pgtable_alloc);
+		pte_phys = pgtable_alloc(PAGE_SHIFT);
+		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
+		pmd = READ_ONCE(*pmdp);
+	}
+	BUG_ON(pmd_bad(pmd));
+
+	do {
+		pgprot_t __prot = prot;
+
+		next = pte_cont_addr_end(addr, end);
+
+		/* use a contiguous mapping if the range is suitably aligned */
+		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
+		    (flags & NO_CONT_MAPPINGS) == 0)
+			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+
+		init_pte(pmdp, addr, next, phys, __prot);
+
+		phys += next - addr;
+	} while (addr = next, addr != end);
+}
+
+static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
+		     phys_addr_t phys, pgprot_t prot,
+		     phys_addr_t (*pgtable_alloc)(int), int flags)
+{
+	unsigned long next;
+	pmd_t *pmdp;
+
+	pmdp = pmd_set_fixmap_offset(pudp, addr);
+	do {
+		pmd_t old_pmd = READ_ONCE(*pmdp);
+
+		next = pmd_addr_end(addr, end);
+
+		/* try section mapping first */
+		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
+		    (flags & NO_BLOCK_MAPPINGS) == 0) {
+			pmd_set_huge(pmdp, phys, prot);
+
+			/*
+			 * After the PMD entry has been populated once, we
+			 * only allow updates to the permission attributes.
+			 */
+			BUG_ON(!pgattr_change_is_safe(pmd_val(old_pmd),
+						      READ_ONCE(pmd_val(*pmdp))));
+		} else {
+			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
+					    pgtable_alloc, flags);
+
+			BUG_ON(pmd_val(old_pmd) != 0 &&
+			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
+		}
+		phys += next - addr;
+	} while (pmdp++, addr = next, addr != end);
+
+	pmd_clear_fixmap();
+}
+
+static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
+				unsigned long end, phys_addr_t phys,
+				pgprot_t prot,
+				phys_addr_t (*pgtable_alloc)(int), int flags)
+{
+	unsigned long next;
+	pud_t pud = READ_ONCE(*pudp);
+
+	/*
+	 * Check for initial section mappings in the pgd/pud.
+	 */
+	BUG_ON(pud_sect(pud));
+	if (pud_none(pud)) {
+		phys_addr_t pmd_phys;
+		BUG_ON(!pgtable_alloc);
+		pmd_phys = pgtable_alloc(PMD_SHIFT);
+		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
+		pud = READ_ONCE(*pudp);
+	}
+	BUG_ON(pud_bad(pud));
+
+	do {
+		pgprot_t __prot = prot;
+
+		next = pmd_cont_addr_end(addr, end);
+
+		/* use a contiguous mapping if the range is suitably aligned */
+		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
+		    (flags & NO_CONT_MAPPINGS) == 0)
+			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+
+		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
+
+		phys += next - addr;
+	} while (addr = next, addr != end);
+}
+
+static inline bool use_1G_block(unsigned long addr, unsigned long next,
+			unsigned long phys)
+{
+	if (PAGE_SHIFT != 12)
+		return false;
+
+	if (((addr | next | phys) & ~PUD_MASK) != 0)
+		return false;
+
+	return true;
+}
+
+static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
+			   phys_addr_t phys, pgprot_t prot,
+			   phys_addr_t (*pgtable_alloc)(int),
+			   int flags)
+{
+	unsigned long next;
+	pud_t *pudp;
+	p4d_t *p4dp = p4d_offset(pgdp, addr);
+	p4d_t p4d = READ_ONCE(*p4dp);
+
+	if (p4d_none(p4d)) {
+		phys_addr_t pud_phys;
+		BUG_ON(!pgtable_alloc);
+		pud_phys = pgtable_alloc(PUD_SHIFT);
+		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
+		p4d = READ_ONCE(*p4dp);
+	}
+	BUG_ON(p4d_bad(p4d));
+
+	pudp = pud_set_fixmap_offset(p4dp, addr);
+	do {
+		pud_t old_pud = READ_ONCE(*pudp);
+
+		next = pud_addr_end(addr, end);
+
+		/*
+		 * For 4K granule only, attempt to put down a 1GB block
+		 */
+		if (use_1G_block(addr, next, phys) &&
+		    (flags & NO_BLOCK_MAPPINGS) == 0) {
+			pud_set_huge(pudp, phys, prot);
+
+			/*
+			 * After the PUD entry has been populated once, we
+			 * only allow updates to the permission attributes.
+			 */
+			BUG_ON(!pgattr_change_is_safe(pud_val(old_pud),
+						      READ_ONCE(pud_val(*pudp))));
+		} else {
+			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
+					    pgtable_alloc, flags);
+
+			BUG_ON(pud_val(old_pud) != 0 &&
+			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
+		}
+		phys += next - addr;
+	} while (pudp++, addr = next, addr != end);
+
+	pud_clear_fixmap();
+}
+
+static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
+				 unsigned long virt, phys_addr_t size,
+				 pgprot_t prot,
+				 phys_addr_t (*pgtable_alloc)(int),
+				 int flags)
+{
+	unsigned long addr, end, next;
+	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
+
+	/*
+	 * If the virtual and physical address don't have the same offset
+	 * within a page, we cannot map the region as the caller expects.
+	 */
+	if (WARN_ON((phys ^ virt) & ~PAGE_MASK))
+		return;
+
+	phys &= PAGE_MASK;
+	addr = virt & PAGE_MASK;
+	end = PAGE_ALIGN(virt + size);
+
+	do {
+		next = pgd_addr_end(addr, end);
+		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
+			       flags);
+		phys += next - addr;
+	} while (pgdp++, addr = next, addr != end);
+}
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:48 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:48 +0800
Subject: [RFC 2/8] arm64/mm: change __create_pgd_mapping() prototype to accept
 nr_entries and introduce create_idmap()
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-3-kernelfans@gmail.com>

As idmap may have pgd entries more than PTRS_PER_PGD, change the
prototype of __create_pgd_mapping() to fix that.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  7 ++++++
 arch/arm64/kernel/head.S         |  3 +++
 arch/arm64/mm/mmu.c              | 41 ++++++++++++++++++++++++++------
 arch/arm64/mm/mmu_include.c      | 10 ++++++--
 4 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 3c6a7f5988b1..555792921af0 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -83,4 +83,11 @@ pmd_populate(struct mm_struct *mm, pmd_t *pmdp, pgtable_t ptep)
 }
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
+extern void __create_pgd_mapping_extend(pgd_t *pgdir,
+		unsigned int entries_cnt, phys_addr_t phys,
+		unsigned long virt, phys_addr_t size,
+		pgprot_t prot,
+		phys_addr_t (*pgtable_alloc)(int),
+		int flags);
+
 #endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 840bda1869e9..e19649dbbafb 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -341,6 +341,9 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 #if VA_BITS != EXTRA_SHIFT
 #error "Mismatch between VA_BITS and page size/number of translation levels"
 #endif
+	adr_l	x4, idmap_extend_pgtable
+	mov	x5, #1
+	str	x5, [x4]                //require expanded pagetable
 
 	mov	x4, EXTRA_PTRS
 	create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 56e4f25e8d6d..30afd6ed275f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -145,6 +145,33 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
 
 #include "./mmu_include.c"
 
+int idmap_extend_pgtable;
+
+/* 
+ * todo: tear down part of idmap
+ * todo: lock protection for concurrent population
+ */
+void create_idmap(pgd_t *pgdir, phys_addr_t phys,
+		phys_addr_t size,
+		pgprot_t prot,
+		phys_addr_t (*pgtable_alloc)(int),
+		int flags)
+{
+	u64 ptrs_per_pgd = idmap_ptrs_per_pgd;
+
+#if CONFIG_IDMAP_PGTABLE_EXPAND
+	if (idmap_extend_pgtable)
+		__create_pgd_mapping_extend(pgdir, ptrs_per_pgd,
+				phys, phys, size, prot, pgtable_alloc, flags);
+	else
+		__create_pgd_mapping(pgdir, ptrs_per_pgd,
+				phys, phys, size, prot, pgtable_alloc, flags);
+#else
+	__create_pgd_mapping(pgdir, ptrs_per_pgd,
+			phys, phys, size, prot, pgtable_alloc, flags);
+#endif
+}
+
 /*
  * This function can only be used to modify existing table entries,
  * without allocating new levels of table. Note that this permits the
@@ -158,7 +185,7 @@ static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 			&phys, virt);
 		return;
 	}
-	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
+	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
 			     NO_CONT_MAPPINGS);
 }
 
@@ -173,7 +200,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
 	if (page_mappings_only)
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
-	__create_pgd_mapping(mm->pgd, phys, virt, size, prot,
+	__create_pgd_mapping(mm->pgd, PTRS_PER_PGD, phys, virt, size, prot,
 			     pgd_pgtable_alloc, flags);
 }
 
@@ -186,7 +213,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 
-	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
+	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
 			     NO_CONT_MAPPINGS);
 
 	/* flush the TLBs after updating live kernel mappings */
@@ -196,7 +223,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
 				  phys_addr_t end, pgprot_t prot, int flags)
 {
-	__create_pgd_mapping(pgdp, start, __phys_to_virt(start), end - start,
+	__create_pgd_mapping(pgdp, start, PTRS_PER_PGD, __phys_to_virt(start), end - start,
 			     prot, early_pgtable_alloc, flags);
 }
 
@@ -297,7 +324,7 @@ static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
 	BUG_ON(!PAGE_ALIGNED(pa_start));
 	BUG_ON(!PAGE_ALIGNED(size));
 
-	__create_pgd_mapping(pgdp, pa_start, (unsigned long)va_start, size, prot,
+	__create_pgd_mapping(pgdp, PTRS_PER_PGD, pa_start, (unsigned long)va_start, size, prot,
 			     early_pgtable_alloc, flags);
 
 	if (!(vm_flags & VM_NO_GUARD))
@@ -341,7 +368,7 @@ static int __init map_entry_trampoline(void)
 
 	/* Map only the text into the trampoline page table */
 	memset(tramp_pg_dir, 0, PGD_SIZE);
-	__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
+	__create_pgd_mapping(tramp_pg_dir, PTRS_PER_PGD, pa_start, TRAMP_VALIAS, PAGE_SIZE,
 			     prot, __pgd_pgtable_alloc, 0);
 
 	/* Map both the text and data into the kernel page table */
@@ -1233,7 +1260,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
 	    IS_ENABLED(CONFIG_KFENCE))
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
-	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
+	__create_pgd_mapping(swapper_pg_dir, PTRS_PER_PGD, start, __phys_to_virt(start),
 			     size, params->pgprot, __pgd_pgtable_alloc,
 			     flags);
 
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index e9ebdffe860b..1cf5af7e2aeb 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -233,14 +233,20 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	pud_clear_fixmap();
 }
 
-static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
+static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
 				 unsigned long virt, phys_addr_t size,
 				 pgprot_t prot,
 				 phys_addr_t (*pgtable_alloc)(int),
 				 int flags)
 {
 	unsigned long addr, end, next;
-	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
+	pgd_t *pgdp;
+
+	if (likely(entries_cnt == PTRS_PER_PGD))
+		pgdp = pgd_offset_pgd(pgdir, virt);
+	else {
+		pgdp = pgdir + ((virt >> PGDIR_SHIFT) & (entries_cnt - 1));
+	}
 
 	/*
 	 * If the virtual and physical address don't have the same offset
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:49 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:49 +0800
Subject: [RFC 3/8] arm64/mm: change __create_pgd_mapping() prototype to accept
 extra info for allocator
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-4-kernelfans@gmail.com>

Incoming allocator needs extra info to get the memory pool info.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  5 +++-
 arch/arm64/mm/idmap_mmu.c        |  5 ++--
 arch/arm64/mm/mmu.c              | 31 +++++++++++++------------
 arch/arm64/mm/mmu_include.c      | 39 +++++++++++++++++++-------------
 4 files changed, 46 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 555792921af0..42f602528b90 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -83,11 +83,14 @@ pmd_populate(struct mm_struct *mm, pmd_t *pmdp, pgtable_t ptep)
 }
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
+typedef phys_addr_t (*pgtable_alloc)(unsigned long shift, void *data);
+
 extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		unsigned int entries_cnt, phys_addr_t phys,
 		unsigned long virt, phys_addr_t size,
 		pgprot_t prot,
-		phys_addr_t (*pgtable_alloc)(int),
+		pgtable_alloc allocator,
+		void *info,
 		int flags);
 
 #endif
diff --git a/arch/arm64/mm/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
index 7e9a4f4017d3..9d9fb77ce0e9 100644
--- a/arch/arm64/mm/idmap_mmu.c
+++ b/arch/arm64/mm/idmap_mmu.c
@@ -35,10 +35,11 @@
 void __create_pgd_mapping_extend(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
 				 unsigned long virt, phys_addr_t size,
 				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
+				 pgtable_alloc allocator,
+				 void *info,
 				 int flags)
 {
-	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size, prot, pgtable_alloc, flags);
+	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size, prot, allocator, info, flags);
 }
 #endif
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 30afd6ed275f..0f183aaf98c9 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -86,7 +86,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 }
 EXPORT_SYMBOL(phys_mem_access_prot);
 
-static phys_addr_t __init early_pgtable_alloc(int shift)
+static phys_addr_t __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	phys_addr_t phys;
 	void *ptr;
@@ -113,7 +113,7 @@ static phys_addr_t __init early_pgtable_alloc(int shift)
 	return phys;
 }
 
-static phys_addr_t __pgd_pgtable_alloc(int shift)
+static phys_addr_t __pgd_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
 	BUG_ON(!ptr);
@@ -123,9 +123,9 @@ static phys_addr_t __pgd_pgtable_alloc(int shift)
 	return __pa(ptr);
 }
 
-static phys_addr_t pgd_pgtable_alloc(int shift)
+static phys_addr_t pgd_pgtable_alloc(unsigned long shift, void *unused)
 {
-	phys_addr_t pa = __pgd_pgtable_alloc(shift);
+	phys_addr_t pa = __pgd_pgtable_alloc(shift, unused);
 
 	/*
 	 * Call proper page table ctor in case later we need to
@@ -154,7 +154,8 @@ int idmap_extend_pgtable;
 void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 		phys_addr_t size,
 		pgprot_t prot,
-		phys_addr_t (*pgtable_alloc)(int),
+		pgtable_alloc allocator,
+		void *info,
 		int flags)
 {
 	u64 ptrs_per_pgd = idmap_ptrs_per_pgd;
@@ -162,13 +163,13 @@ void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 #if CONFIG_IDMAP_PGTABLE_EXPAND
 	if (idmap_extend_pgtable)
 		__create_pgd_mapping_extend(pgdir, ptrs_per_pgd,
-				phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 	else
 		__create_pgd_mapping(pgdir, ptrs_per_pgd,
-				phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 #else
 	__create_pgd_mapping(pgdir, ptrs_per_pgd,
-			phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 #endif
 }
 
@@ -186,7 +187,7 @@ static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
-			     NO_CONT_MAPPINGS);
+			     NULL, NO_CONT_MAPPINGS);
 }
 
 void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -201,7 +202,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
 	__create_pgd_mapping(mm->pgd, PTRS_PER_PGD, phys, virt, size, prot,
-			     pgd_pgtable_alloc, flags);
+			     pgd_pgtable_alloc, NULL, flags);
 }
 
 static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
@@ -214,7 +215,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 	}
 
 	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
-			     NO_CONT_MAPPINGS);
+			     NULL, NO_CONT_MAPPINGS);
 
 	/* flush the TLBs after updating live kernel mappings */
 	flush_tlb_kernel_range(virt, virt + size);
@@ -224,7 +225,7 @@ static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
 				  phys_addr_t end, pgprot_t prot, int flags)
 {
 	__create_pgd_mapping(pgdp, start, PTRS_PER_PGD, __phys_to_virt(start), end - start,
-			     prot, early_pgtable_alloc, flags);
+			     prot, early_pgtable_alloc, NULL, flags);
 }
 
 void __init mark_linear_text_alias_ro(void)
@@ -325,7 +326,7 @@ static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
 	BUG_ON(!PAGE_ALIGNED(size));
 
 	__create_pgd_mapping(pgdp, PTRS_PER_PGD, pa_start, (unsigned long)va_start, size, prot,
-			     early_pgtable_alloc, flags);
+			     early_pgtable_alloc, NULL, flags);
 
 	if (!(vm_flags & VM_NO_GUARD))
 		size += PAGE_SIZE;
@@ -369,7 +370,7 @@ static int __init map_entry_trampoline(void)
 	/* Map only the text into the trampoline page table */
 	memset(tramp_pg_dir, 0, PGD_SIZE);
 	__create_pgd_mapping(tramp_pg_dir, PTRS_PER_PGD, pa_start, TRAMP_VALIAS, PAGE_SIZE,
-			     prot, __pgd_pgtable_alloc, 0);
+			     prot, __pgd_pgtable_alloc, NULL, 0);
 
 	/* Map both the text and data into the kernel page table */
 	__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
@@ -1261,7 +1262,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
 	__create_pgd_mapping(swapper_pg_dir, PTRS_PER_PGD, start, __phys_to_virt(start),
-			     size, params->pgprot, __pgd_pgtable_alloc,
+			     size, params->pgprot, __pgd_pgtable_alloc, NULL,
 			     flags);
 
 	memblock_clear_nomap(start, size);
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 1cf5af7e2aeb..371afc7d4502 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -64,7 +64,8 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 				unsigned long end, phys_addr_t phys,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int),
+				pgtable_alloc allocator,
+				void *info,
 				int flags)
 {
 	unsigned long next;
@@ -73,8 +74,8 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 	BUG_ON(pmd_sect(pmd));
 	if (pmd_none(pmd)) {
 		phys_addr_t pte_phys;
-		BUG_ON(!pgtable_alloc);
-		pte_phys = pgtable_alloc(PAGE_SHIFT);
+		BUG_ON(!allocator);
+		pte_phys = allocator(PAGE_SHIFT, info);
 		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
 		pmd = READ_ONCE(*pmdp);
 	}
@@ -98,7 +99,9 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 
 static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 		     phys_addr_t phys, pgprot_t prot,
-		     phys_addr_t (*pgtable_alloc)(int), int flags)
+		     pgtable_alloc allocator,
+		     void *info,
+		     int flags)
 {
 	unsigned long next;
 	pmd_t *pmdp;
@@ -122,7 +125,7 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 						      READ_ONCE(pmd_val(*pmdp))));
 		} else {
 			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
+					    allocator, info, flags);
 
 			BUG_ON(pmd_val(old_pmd) != 0 &&
 			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
@@ -136,7 +139,9 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 				unsigned long end, phys_addr_t phys,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int), int flags)
+				pgtable_alloc allocator,
+				void *info,
+				int flags)
 {
 	unsigned long next;
 	pud_t pud = READ_ONCE(*pudp);
@@ -147,8 +152,8 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 	BUG_ON(pud_sect(pud));
 	if (pud_none(pud)) {
 		phys_addr_t pmd_phys;
-		BUG_ON(!pgtable_alloc);
-		pmd_phys = pgtable_alloc(PMD_SHIFT);
+		BUG_ON(!allocator);
+		pmd_phys = allocator(PMD_SHIFT, info);
 		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
 		pud = READ_ONCE(*pudp);
 	}
@@ -164,7 +169,7 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 		    (flags & NO_CONT_MAPPINGS) == 0)
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
-		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
+		init_pmd(pudp, addr, next, phys, __prot, allocator, info, flags);
 
 		phys += next - addr;
 	} while (addr = next, addr != end);
@@ -184,7 +189,8 @@ static inline bool use_1G_block(unsigned long addr, unsigned long next,
 
 static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 			   phys_addr_t phys, pgprot_t prot,
-			   phys_addr_t (*pgtable_alloc)(int),
+			   pgtable_alloc allocator,
+			   void *info,
 			   int flags)
 {
 	unsigned long next;
@@ -194,8 +200,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 
 	if (p4d_none(p4d)) {
 		phys_addr_t pud_phys;
-		BUG_ON(!pgtable_alloc);
-		pud_phys = pgtable_alloc(PUD_SHIFT);
+		BUG_ON(!allocator);
+		pud_phys = allocator(PUD_SHIFT, info);
 		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
 		p4d = READ_ONCE(*p4dp);
 	}
@@ -222,7 +228,7 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 						      READ_ONCE(pud_val(*pudp))));
 		} else {
 			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
+					    allocator, info, flags);
 
 			BUG_ON(pud_val(old_pud) != 0 &&
 			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
@@ -236,7 +242,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
 				 unsigned long virt, phys_addr_t size,
 				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
+				 pgtable_alloc allocator,
+				 void *info,
 				 int flags)
 {
 	unsigned long addr, end, next;
@@ -261,8 +268,8 @@ static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_ad
 
 	do {
 		next = pgd_addr_end(addr, end);
-		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
-			       flags);
+		alloc_init_pud(pgdp, addr, next, phys, prot, allocator,
+			       info, flags);
 		phys += next - addr;
 	} while (pgdp++, addr = next, addr != end);
 }
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:50 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:50 +0800
Subject: [RFC 4/8] arm64/mm: enable __create_pgd_mapping() to run across
 different pgtable
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-5-kernelfans@gmail.com>

PUP/PMD/PTE fixmap can not be shared across different pgtable
concurrently.

Also change the return type from phys_addr_t to unsigned long, since
allocator may return virtual address directly.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  6 +++++-
 arch/arm64/mm/mmu.c              |  6 +++---
 arch/arm64/mm/mmu_include.c      | 31 ++++++++++++++++++++-----------
 3 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 42f602528b90..6e9f1e218300 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -83,7 +83,7 @@ pmd_populate(struct mm_struct *mm, pmd_t *pmdp, pgtable_t ptep)
 }
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
-typedef phys_addr_t (*pgtable_alloc)(unsigned long shift, void *data);
+typedef unsigned long (*pgtable_alloc)(unsigned long shift, void *data);
 
 extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		unsigned int entries_cnt, phys_addr_t phys,
@@ -93,4 +93,8 @@ extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		void *info,
 		int flags);
 
+#define NO_BLOCK_MAPPINGS	BIT(0)
+#define NO_CONT_MAPPINGS	BIT(1)
+#define NO_FIXMAP	BIT(2)
+
 #endif
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 0f183aaf98c9..628752c3cfd0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -86,7 +86,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 }
 EXPORT_SYMBOL(phys_mem_access_prot);
 
-static phys_addr_t __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
+static unsigned long __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	phys_addr_t phys;
 	void *ptr;
@@ -113,7 +113,7 @@ static phys_addr_t __init early_pgtable_alloc(unsigned long unused_a, void *unus
 	return phys;
 }
 
-static phys_addr_t __pgd_pgtable_alloc(unsigned long unused_a, void *unused_b)
+static unsigned long __pgd_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
 	BUG_ON(!ptr);
@@ -123,7 +123,7 @@ static phys_addr_t __pgd_pgtable_alloc(unsigned long unused_a, void *unused_b)
 	return __pa(ptr);
 }
 
-static phys_addr_t pgd_pgtable_alloc(unsigned long shift, void *unused)
+static unsigned long pgd_pgtable_alloc(unsigned long shift, void *unused)
 {
 	phys_addr_t pa = __pgd_pgtable_alloc(shift, unused);
 
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 371afc7d4502..adad0f93cd53 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -1,8 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
-#define NO_BLOCK_MAPPINGS	BIT(0)
-#define NO_CONT_MAPPINGS	BIT(1)
-
 static bool pgattr_change_is_safe(u64 old, u64 new)
 {
 	/*
@@ -38,11 +35,14 @@ static bool pgattr_change_is_safe(u64 old, u64 new)
 }
 
 static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot)
+		     phys_addr_t phys, pgprot_t prot, int flags)
 {
 	pte_t *ptep;
 
-	ptep = pte_set_fixmap_offset(pmdp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		ptep = pte_set_fixmap_offset(pmdp, addr);
+	else
+		ptep = pte_offset_kernel(pmdp, addr);
 	do {
 		pte_t old_pte = READ_ONCE(*ptep);
 
@@ -58,7 +58,8 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		phys += PAGE_SIZE;
 	} while (ptep++, addr += PAGE_SIZE, addr != end);
 
-	pte_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pte_clear_fixmap();
 }
 
 static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
@@ -91,7 +92,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 		    (flags & NO_CONT_MAPPINGS) == 0)
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
-		init_pte(pmdp, addr, next, phys, __prot);
+		init_pte(pmdp, addr, next, phys, __prot, flags);
 
 		phys += next - addr;
 	} while (addr = next, addr != end);
@@ -106,7 +107,10 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 	unsigned long next;
 	pmd_t *pmdp;
 
-	pmdp = pmd_set_fixmap_offset(pudp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		pmdp = pmd_set_fixmap_offset(pudp, addr);
+	else
+		pmdp = pmd_offset(pudp, addr);
 	do {
 		pmd_t old_pmd = READ_ONCE(*pmdp);
 
@@ -133,7 +137,8 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 		phys += next - addr;
 	} while (pmdp++, addr = next, addr != end);
 
-	pmd_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pmd_clear_fixmap();
 }
 
 static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
@@ -207,7 +212,10 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	}
 	BUG_ON(p4d_bad(p4d));
 
-	pudp = pud_set_fixmap_offset(p4dp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		pudp = pud_set_fixmap_offset(p4dp, addr);
+	else
+		pudp = pud_offset(p4dp, addr);
 	do {
 		pud_t old_pud = READ_ONCE(*pudp);
 
@@ -236,7 +244,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 		phys += next - addr;
 	} while (pudp++, addr = next, addr != end);
 
-	pud_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pud_clear_fixmap();
 }
 
 static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:51 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:51 +0800
Subject: [RFC 5/8] arm64/mm: make trans_pgd_idmap_page() use create_idmap()
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-6-kernelfans@gmail.com>

At present, trans_pgd_idmap_page() has its own logic to set up idmap. To
make code simple, it can reuse create_idmap().

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  9 +++++
 arch/arm64/mm/trans_pgd.c        | 59 +++++++++++++++-----------------
 2 files changed, 36 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 6e9f1e218300..f848a0300228 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -93,6 +93,15 @@ extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		void *info,
 		int flags);
 
+extern int idmap_extend_pgtable;
+
+extern void create_idmap(pgd_t *pgdir, phys_addr_t phys,
+		phys_addr_t size,
+		pgprot_t prot,
+		pgtable_alloc allocator,
+		void *info,
+		int flags);
+
 #define NO_BLOCK_MAPPINGS	BIT(0)
 #define NO_CONT_MAPPINGS	BIT(1)
 #define NO_FIXMAP	BIT(2)
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 527f0a39c3da..004ccbadd647 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -274,6 +274,14 @@ int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
 	return 0;
 }
 
+static unsigned long allocator_trans_alloc(unsigned long unused, void *info)
+{
+	unsigned long *p;
+
+	p = trans_alloc(info);
+	return (unsigned long)p;
+}
+
 /*
  * The page we want to idmap may be outside the range covered by VA_BITS that
  * can be built using the kernel's p?d_populate() helpers. As a one off, for a
@@ -287,38 +295,25 @@ int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
 int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 			 unsigned long *t0sz, void *page)
 {
-	phys_addr_t dst_addr = virt_to_phys(page);
-	unsigned long pfn = __phys_to_pfn(dst_addr);
-	int max_msb = (dst_addr & GENMASK(52, 48)) ? 51 : 47;
-	int bits_mapped = PAGE_SHIFT - 4;
-	unsigned long level_mask, prev_level_entry, *levels[4];
-	int this_level, index, level_lsb, level_msb;
-
-	dst_addr &= PAGE_MASK;
-	prev_level_entry = pte_val(pfn_pte(pfn, PAGE_KERNEL_EXEC));
-
-	for (this_level = 3; this_level >= 0; this_level--) {
-		levels[this_level] = trans_alloc(info);
-		if (!levels[this_level])
-			return -ENOMEM;
-
-		level_lsb = ARM64_HW_PGTABLE_LEVEL_SHIFT(this_level);
-		level_msb = min(level_lsb + bits_mapped, max_msb);
-		level_mask = GENMASK_ULL(level_msb, level_lsb);
-
-		index = (dst_addr & level_mask) >> level_lsb;
-		*(levels[this_level] + index) = prev_level_entry;
-
-		pfn = virt_to_pfn(levels[this_level]);
-		prev_level_entry = pte_val(pfn_pte(pfn,
-						   __pgprot(PMD_TYPE_TABLE)));
-
-		if (level_msb == max_msb)
-			break;
-	}
-
-	*trans_ttbr0 = phys_to_ttbr(__pfn_to_phys(pfn));
-	*t0sz = TCR_T0SZ(max_msb + 1);
+	pgd_t * pgdir = trans_alloc(info);
+	int flags = NO_FIXMAP;
+	unsigned long base, step, level, va_bits;
+
+#ifdef CONFIG_ARM64_64K_PAGES
+	base = 16;
+	step = 13;
+#elif CONFIG_ARM64_4K_PAGES
+	base = 12;
+	step = 9;
+#endif
+	create_idmap(pgdir, virt_to_phys(page), PAGE_SIZE, PAGE_KERNEL_EXEC,
+			allocator_trans_alloc, info, flags);
+
+	*trans_ttbr0 = phys_to_ttbr(__virt_to_phys(pgdir));
+	level = CONFIG_PGTABLE_LEVELS + idmap_extend_pgtable ? 1 : 0;
+	va_bits = base + step * level;
+	va_bits = min(va_bits, vabits_actual);
+	*t0sz = 64 - va_bits;
 
 	return 0;
 }
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:52 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:52 +0800
Subject: [RFC 6/8] arm64/mm: introduce pgtable allocator for head
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-7-kernelfans@gmail.com>

>From the view of __create_pgd_mapping(), both idmap_pg_dir and
init_pg_dir can be treated as a memory pool.  Introduce an allocator
working on them, so __create_pgd_mapping() can create mapping.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/mm/mmu.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 628752c3cfd0..b546e47543e2 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -86,6 +86,28 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 }
 EXPORT_SYMBOL(phys_mem_access_prot);
 
+struct mempool {
+	unsigned long start;
+	unsigned long size;
+	unsigned long next_idx;
+};
+
+struct mempool cur_pool;
+
+void set_cur_mempool(unsigned long start, unsigned long size)
+{
+	cur_pool.start = start;
+	cur_pool.size = size;
+	cur_pool.next_idx = 0;
+}
+
+unsigned long __init head_pgtable_alloc(unsigned long unused_a, void *unused_b)
+{
+	unsigned long idx = cur_pool.next_idx++;
+
+	return cur_pool.start + (idx << PAGE_SHIFT);
+}
+
 static unsigned long __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	phys_addr_t phys;
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:53 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:53 +0800
Subject: [RFC 7/8] arm64/pgtable-prot.h: reorganize to cope with asm
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-8-kernelfans@gmail.com>

In order to refer PAGE_KERNEL_EXEC in head.S, reorganize this file.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgtable-prot.h | 34 +++++++++++++++++----------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 9a65fb528110..424fc5e6fd69 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -33,9 +33,6 @@
 
 extern bool arm64_use_ng_mappings;
 
-#define _PROT_DEFAULT		(PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
-#define _PROT_SECT_DEFAULT	(PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
-
 #define PTE_MAYBE_NG		(arm64_use_ng_mappings ? PTE_NG : 0)
 #define PMD_MAYBE_NG		(arm64_use_ng_mappings ? PMD_SECT_NG : 0)
 
@@ -49,6 +46,26 @@ extern bool arm64_use_ng_mappings;
 #define PTE_MAYBE_GP		0
 #endif
 
+#define PAGE_S2_MEMATTR(attr)						\
+	({								\
+		u64 __val;						\
+		if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))		\
+			__val = PTE_S2_MEMATTR(MT_S2_FWB_ ## attr);	\
+		else							\
+			__val = PTE_S2_MEMATTR(MT_S2_ ## attr);		\
+		__val;							\
+	 })
+
+#endif /* __ASSEMBLY__ */
+
+#ifdef __ASSEMBLY__
+#define PTE_MAYBE_NG	0
+#define __pgprot(x)	(x)
+#endif
+
+#define _PROT_DEFAULT		(PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
+#define _PROT_SECT_DEFAULT	(PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
+
 #define PROT_DEFAULT		(_PROT_DEFAULT | PTE_MAYBE_NG)
 #define PROT_SECT_DEFAULT	(_PROT_SECT_DEFAULT | PMD_MAYBE_NG)
 
@@ -71,15 +88,7 @@ extern bool arm64_use_ng_mappings;
 #define PAGE_KERNEL_EXEC	__pgprot(PROT_NORMAL & ~PTE_PXN)
 #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)
 
-#define PAGE_S2_MEMATTR(attr)						\
-	({								\
-		u64 __val;						\
-		if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))		\
-			__val = PTE_S2_MEMATTR(MT_S2_FWB_ ## attr);	\
-		else							\
-			__val = PTE_S2_MEMATTR(MT_S2_ ## attr);		\
-		__val;							\
-	 })
+
 
 #define PAGE_NONE		__pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
 /* shared+writable pages are clean by default, hence PTE_RDONLY|PTE_WRITE */
@@ -106,6 +115,5 @@ extern bool arm64_use_ng_mappings;
 #define __S110  PAGE_SHARED_EXEC
 #define __S111  PAGE_SHARED_EXEC
 
-#endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_PROT_H */
-- 
2.29.2



From kernelfans at gmail.com  Sat Apr 10 10:56:54 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sat, 10 Apr 2021 17:56:54 +0800
Subject: [RFC 8/8] arm64/head: convert idmap_pg_dir and init_pg_dir to
 __create_pgd_mapping()
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <20210410095654.24102-9-kernelfans@gmail.com>

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |   5 +
 arch/arm64/kernel/head.S         | 187 +++++++------------------------
 arch/arm64/mm/mmu.c              |   9 ++
 3 files changed, 55 insertions(+), 146 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index f848a0300228..128d784d78d4 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -8,6 +8,9 @@
 #ifndef __ASM_PGALLOC_H
 #define __ASM_PGALLOC_H
 
+#include <vdso/bits.h>
+
+#ifndef __ASSEMBLY__
 #include <asm/pgtable-hwdef.h>
 #include <asm/processor.h>
 #include <asm/cacheflush.h>
@@ -102,6 +105,8 @@ extern void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 		void *info,
 		int flags);
 
+#endif
+
 #define NO_BLOCK_MAPPINGS	BIT(0)
 #define NO_CONT_MAPPINGS	BIT(1)
 #define NO_FIXMAP	BIT(2)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index e19649dbbafb..3b0c9359ab70 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -28,6 +28,8 @@
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/page.h>
+#include <asm/pgtable-prot.h>
+#include <asm/pgalloc.h>
 #include <asm/scs.h>
 #include <asm/smp.h>
 #include <asm/sysreg.h>
@@ -93,6 +95,8 @@ SYM_CODE_START(primary_entry)
 	adrp	x23, __PHYS_OFFSET
 	and	x23, x23, MIN_KIMG_ALIGN - 1	// KASLR offset, defaults to 0
 	bl	set_cpu_boot_mode_flag
+	adrp	x4, init_thread_union
+	add	sp, x4, #THREAD_SIZE
 	bl	__create_page_tables
 	/*
 	 * The following calls CPU setup code, see arch/arm64/mm/proc.S for
@@ -121,135 +125,6 @@ SYM_CODE_START_LOCAL(preserve_boot_args)
 	b	__inval_dcache_area		// tail call
 SYM_CODE_END(preserve_boot_args)
 
-/*
- * Macro to create a table entry to the next page.
- *
- *	tbl:	page table address
- *	virt:	virtual address
- *	shift:	#imm page table shift
- *	ptrs:	#imm pointers per table page
- *
- * Preserves:	virt
- * Corrupts:	ptrs, tmp1, tmp2
- * Returns:	tbl -> next level table page address
- */
-	.macro	create_table_entry, tbl, virt, shift, ptrs, tmp1, tmp2
-	add	\tmp1, \tbl, #PAGE_SIZE
-	phys_to_pte \tmp2, \tmp1
-	orr	\tmp2, \tmp2, #PMD_TYPE_TABLE	// address of next table and entry type
-	lsr	\tmp1, \virt, #\shift
-	sub	\ptrs, \ptrs, #1
-	and	\tmp1, \tmp1, \ptrs		// table index
-	str	\tmp2, [\tbl, \tmp1, lsl #3]
-	add	\tbl, \tbl, #PAGE_SIZE		// next level table page
-	.endm
-
-/*
- * Macro to populate page table entries, these entries can be pointers to the next level
- * or last level entries pointing to physical memory.
- *
- *	tbl:	page table address
- *	rtbl:	pointer to page table or physical memory
- *	index:	start index to write
- *	eindex:	end index to write - [index, eindex] written to
- *	flags:	flags for pagetable entry to or in
- *	inc:	increment to rtbl between each entry
- *	tmp1:	temporary variable
- *
- * Preserves:	tbl, eindex, flags, inc
- * Corrupts:	index, tmp1
- * Returns:	rtbl
- */
-	.macro populate_entries, tbl, rtbl, index, eindex, flags, inc, tmp1
-.Lpe\@:	phys_to_pte \tmp1, \rtbl
-	orr	\tmp1, \tmp1, \flags	// tmp1 = table entry
-	str	\tmp1, [\tbl, \index, lsl #3]
-	add	\rtbl, \rtbl, \inc	// rtbl = pa next level
-	add	\index, \index, #1
-	cmp	\index, \eindex
-	b.ls	.Lpe\@
-	.endm
-
-/*
- * Compute indices of table entries from virtual address range. If multiple entries
- * were needed in the previous page table level then the next page table level is assumed
- * to be composed of multiple pages. (This effectively scales the end index).
- *
- *	vstart:	virtual address of start of range
- *	vend:	virtual address of end of range
- *	shift:	shift used to transform virtual address into index
- *	ptrs:	number of entries in page table
- *	istart:	index in table corresponding to vstart
- *	iend:	index in table corresponding to vend
- *	count:	On entry: how many extra entries were required in previous level, scales
- *			  our end index.
- *		On exit: returns how many extra entries required for next page table level
- *
- * Preserves:	vstart, vend, shift, ptrs
- * Returns:	istart, iend, count
- */
-	.macro compute_indices, vstart, vend, shift, ptrs, istart, iend, count
-	lsr	\iend, \vend, \shift
-	mov	\istart, \ptrs
-	sub	\istart, \istart, #1
-	and	\iend, \iend, \istart	// iend = (vend >> shift) & (ptrs - 1)
-	mov	\istart, \ptrs
-	mul	\istart, \istart, \count
-	add	\iend, \iend, \istart	// iend += (count - 1) * ptrs
-					// our entries span multiple tables
-
-	lsr	\istart, \vstart, \shift
-	mov	\count, \ptrs
-	sub	\count, \count, #1
-	and	\istart, \istart, \count
-
-	sub	\count, \iend, \istart
-	.endm
-
-/*
- * Map memory for specified virtual address range. Each level of page table needed supports
- * multiple entries. If a level requires n entries the next page table level is assumed to be
- * formed from n pages.
- *
- *	tbl:	location of page table
- *	rtbl:	address to be used for first level page table entry (typically tbl + PAGE_SIZE)
- *	vstart:	start address to map
- *	vend:	end address to map - we map [vstart, vend]
- *	flags:	flags to use to map last level entries
- *	phys:	physical address corresponding to vstart - physical memory is contiguous
- *	pgds:	the number of pgd entries
- *
- * Temporaries:	istart, iend, tmp, count, sv - these need to be different registers
- * Preserves:	vstart, vend, flags
- * Corrupts:	tbl, rtbl, istart, iend, tmp, count, sv
- */
-	.macro map_memory, tbl, rtbl, vstart, vend, flags, phys, pgds, istart, iend, tmp, count, sv
-	add \rtbl, \tbl, #PAGE_SIZE
-	mov \sv, \rtbl
-	mov \count, #0
-	compute_indices \vstart, \vend, #PGDIR_SHIFT, \pgds, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-	mov \sv, \rtbl
-
-#if SWAPPER_PGTABLE_LEVELS > 3
-	compute_indices \vstart, \vend, #PUD_SHIFT, #PTRS_PER_PUD, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-	mov \sv, \rtbl
-#endif
-
-#if SWAPPER_PGTABLE_LEVELS > 2
-	compute_indices \vstart, \vend, #SWAPPER_TABLE_SHIFT, #PTRS_PER_PMD, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-#endif
-
-	compute_indices \vstart, \vend, #SWAPPER_BLOCK_SHIFT, #PTRS_PER_PTE, \istart, \iend, \count
-	bic \count, \phys, #SWAPPER_BLOCK_SIZE - 1
-	populate_entries \tbl, \count, \istart, \iend, \flags, #SWAPPER_BLOCK_SIZE, \tmp
-	.endm
-
 /*
  * Setup the initial page tables. We only setup the barest amount which is
  * required to get the kernel running. The following sections are required:
@@ -344,9 +219,6 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	adr_l	x4, idmap_extend_pgtable
 	mov	x5, #1
 	str	x5, [x4]                //require expanded pagetable
-
-	mov	x4, EXTRA_PTRS
-	create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
 #else
 	/*
 	 * If VA_BITS == 48, we don't have to configure an additional
@@ -356,25 +228,50 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	str_l	x4, idmap_ptrs_per_pgd, x5
 #endif
 1:
-	ldr_l	x4, idmap_ptrs_per_pgd
-	mov	x5, x3				// __pa(__idmap_text_start)
-	adr_l	x6, __idmap_text_end		// __pa(__idmap_text_end)
+	stp	x0, x1, [sp, #-64]!
+	stp	x2, x3, [sp, #48]
+	stp	x4, x5, [sp, #32]
+	stp	x6, x7, [sp, #16]
 
-	map_memory x0, x1, x3, x6, x7, x3, x4, x10, x11, x12, x13, x14
+	adrp	x0, idmap_pg_dir
+	adrp	x1, idmap_pg_end
+	sub	x1, x1, x0
+	bl	set_cur_mempool
+		
+	adrp	x1, __idmap_text_start
+	adr_l	x2, __idmap_text_end
+	sub	x2, x2, x1
+	ldr	x3, =PAGE_KERNEL_EXEC
+	adr_l	x4, head_pgtable_alloc
+	mov	x5, #0
+	mov	x6, #NO_FIXMAP
+	bl	create_idmap
 
 	/*
 	 * Map the kernel image (starting with PHYS_OFFSET).
 	 */
 	adrp	x0, init_pg_dir
-	mov_q	x5, KIMAGE_VADDR		// compile time __va(_text)
-	add	x5, x5, x23			// add KASLR displacement
-	mov	x4, PTRS_PER_PGD
-	adrp	x6, _end			// runtime __pa(_end)
-	adrp	x3, _text			// runtime __pa(_text)
-	sub	x6, x6, x3			// _end - _text
-	add	x6, x6, x5			// runtime __va(_end)
+	adrp	x1, init_pg_end
+	sub	x1, x1, x0
+	bl	set_cur_mempool
 
-	map_memory x0, x1, x5, x6, x7, x3, x4, x10, x11, x12, x13, x14
+	mov	x1, PTRS_PER_PGD
+	adrp	x3, _text			// runtime __pa(_text)
+	mov_q	x4, KIMAGE_VADDR		// compile time __va(_text)
+	add	x4, x4, x23			// add KASLR displacement
+	adrp	x5, _end			// runtime __pa(_end)
+	sub	x5, x5, x3			// _end - _text
+
+	ldr	x3, =PAGE_KERNEL_EXEC
+	adr_l	x4, head_pgtable_alloc
+	mov	x5, #0
+	mov	x6, #NO_FIXMAP
+
+	bl	create_init_pgd_mapping
+	ldp	x6, x7, [sp, #16]
+	ldp	x4, x5, [sp, #32]
+	ldp	x2, x3, [sp, #48]
+	ldp	x0, x1, [sp], #-64
 
 	/*
 	 * Since the page tables have been populated with non-cacheable
@@ -402,8 +299,6 @@ SYM_FUNC_END(__create_page_tables)
  *   x0 = __PHYS_OFFSET
  */
 SYM_FUNC_START_LOCAL(__primary_switched)
-	adrp	x4, init_thread_union
-	add	sp, x4, #THREAD_SIZE
 	adr_l	x5, init_task
 	msr	sp_el0, x5			// Save thread_info
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index b546e47543e2..b886332a7c3f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -167,6 +167,15 @@ static unsigned long pgd_pgtable_alloc(unsigned long shift, void *unused)
 
 #include "./mmu_include.c"
 
+void create_init_pgd_mapping(pgd_t * pgdir, unsigned int entries_cnt,
+		phys_addr_t phys, unsigned long virt, phys_addr_t size,
+	       	pgprot_t prot, pgtable_alloc allocator,
+		void * info, int flags)
+{
+	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size,
+		prot, allocator, info, flags);
+}
+
 int idmap_extend_pgtable;
 
 /* 
-- 
2.29.2



From wangqing at vivo.com  Sat Apr 10 13:19:22 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Sat, 10 Apr 2021 20:19:22 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSF0gd2F0Y2hkb2c6IG10azogc3VwcG9ydCBwcmUtdGltZW91dCB3aGVuIHRoZSBiYXJrIGlycSBpcyBhdmFpbGFibGU=?=
In-Reply-To: <45e40a84-9d98-87e7-659e-6c34834e6280@roeck-us.net>
Message-ID: <AD6AsgAeDkibbqIS7o2O1arH.3.1618057162190.Hmail.wangqing@vivo.com>


>On 4/9/21 8:11 PM, ?? wrote:
>> 
>>> On 4/9/21 7:42 PM, ?? wrote:
>>>>
>>>>> On 4/9/21 2:55 AM, Wang Qing wrote:
>>>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>>>
>>>>>> By default, the pretimeout notification shall occur one second earlier
>>>>>> than the timeout.
>>>>>>
>>>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>>>> ---
>>>>>>  drivers/watchdog/mtk_wdt.c | 47 +++++++++++++++++++++++++++++++++++++++++++---
>>>>>>  1 file changed, 44 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>>>> index 97ca993..8b919cc
>>>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>>>> @@ -25,6 +25,7 @@
>>>>>>  #include <linux/reset-controller.h>
>>>>>>  #include <linux/types.h>
>>>>>>  #include <linux/watchdog.h>
>>>>>> +#include <linux/interrupt.h>
>>>>>>  
>>>>>>  #define WDT_MAX_TIMEOUT		31
>>>>>>  #define WDT_MIN_TIMEOUT		1
>>>>>> @@ -234,18 +235,35 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>>>>  	int ret;
>>>>>>  
>>>>>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>>>>>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>>>>>
>>>>> That looks suspiciously like the real watchdog won't happen at all.
>>>>> What will happen if the pretimeout governor is set to none ?
>>>>>
>>>>> Guenter
>>>>>
>>>> The pretimeout governor is panic by default. If pretimeout is enabled and the governor is
>>>> set to none, it means the timeout behavior does not need to be processed, only printing.
>>>>
>>>
>>> That was not my question. My question was if the real timeout happens in that case.
>>>
>>> Guenter
>>>
>> Yes, the real timeout will happen. After WDT timeout, IRQ is sent out instead of 
>> reset signal first. In order to ensure that CPU does not get stuck after IRQ is sent out, 
>> WDT will time again and send reset signal to reset.
>> 
>
>When will that be, or in other words how does the chip know when to time out ?
>After all, only a single timeout value is written into the chip. I don't see how
>it would know to reset the chip after wdt_dev->timeout.
>
>Guenter
>
>
Sorry I made a mistake, the IRQ is sent out first, then time again and reset only when 
WDT_MODE_IRQ_EN|WDT_MODE_DUAL_EN is enabled. WDT_MODE_DUAL_EN mode
is a special mode, depending on the specific chip design.

If WDT_MODE_IRQ_EN|~WDT_MODE_DUAL_EN as described in my patch, it just sent
out IRQ instead of reset signal, the real timeout will not happen if the pretimeout 
governor is set to none.

Also, ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN) means send reset signal directly.
It does not support pretimeout processing.

Thanks
Qing Wang


From krzysztof.kozlowski at canonical.com  Sat Apr 10 13:40:11 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Sat, 10 Apr 2021 14:40:11 +0200
Subject: [PATCH v5 04/16] memory: mtk-smi: Add device-link between
 smi-larb and smi-common
In-Reply-To: <20210410091128.31823-5-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
 <20210410091128.31823-5-yong.wu@mediatek.com>
Message-ID: <ea7ed30f-050d-2d38-7c61-1e0c192f6ded@canonical.com>

On 10/04/2021 11:11, Yong Wu wrote:
> Normally, If the smi-larb HW need work, we should enable the smi-common
> HW power and clock firstly.
> This patch adds device-link between the smi-larb dev and the smi-common
> dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
> (smi-common-dev) will be called automatically.
> 
> Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
> probe.
> 
> CC: Matthias Brugger <matthias.bgg at gmail.com>
> Suggested-by: Tomasz Figa <tfiga at chromium.org>
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> ---
>  drivers/memory/mtk-smi.c | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)

I understood this is a dependency for other patches, so:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

If I am wrong and I can take it via memory tree, let me know.

Best regards,
Krzysztof


From vee.khee.wong at linux.intel.com  Sat Apr 10 14:16:09 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Sat, 10 Apr 2021 21:16:09 +0800
Subject: [PATCH net-next v2 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210409175004.2fceacdd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210407170442.1641-1-vee.khee.wong@linux.intel.com>
 <20210409175004.2fceacdd@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <20210410131609.GA12931@linux.intel.com>

On Fri, Apr 09, 2021 at 05:50:04PM -0700, Jakub Kicinski wrote:
> Other than the minor nit below LGTM. Let's give Richard one more day.
> 
> On Thu,  8 Apr 2021 01:04:42 +0800 Wong Vee Khee wrote:
> > +static void timestamp_interrupt(struct stmmac_priv *priv)
> > +{
> > +	struct ptp_clock_event event;
> > +	unsigned long flags;
> > +	u32 num_snapshot;
> > +	u32 ts_status;
> > +	u32 tsync_int;
> > +	u64 ptp_time;
> > +	int i;
> > +
> > +	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
> > +
> > +	if (!tsync_int)
> > +		return;
> > +
> > +	/* Read timestamp status to clear interrupt from either external
> > +	 * timestamp or start/end of PPS.
> > +	 */
> > +	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
> > +
> > +	if (priv->plat->ext_snapshot_en) {
> 
> Are you intending to add more code after this if? Otherwise you could
> flip the condition and return early instead of having the extra level
> of indentation.
>

Thanks fo the suggestion.
There's no plan to add more code after this as per STMMAC features that
required this interrupt. I will flip the condition.

> > +		num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
> > +			       GMAC_TIMESTAMP_ATSNS_SHIFT;
> > +
> > +		for (i = 0; i < num_snapshot; i++) {
> > +			spin_lock_irqsave(&priv->ptp_lock, flags);
> > +			get_ptptime(priv->ptpaddr, &ptp_time);
> > +			spin_unlock_irqrestore(&priv->ptp_lock, flags);
> > +			event.type = PTP_CLOCK_EXTTS;
> > +			event.index = 0;
> > +			event.timestamp = ptp_time;
> > +			ptp_clock_event(priv->ptp_clock, &event);
> > +		}
> > +	}
> > +}
> 
> Not really related to this patch but how does stmmac set IRQF_SHARED
> and yet not track if it indeed generated the interrupt? Isn't that
> against the rules?
>

Good point! Thanks for pointing that out. I looked at how STMMAC
interrupt handlers are coded, and indeed there are no tracking. Will
work on that and send as a seperate patch in near future.




From gregkh at linuxfoundation.org  Sat Apr 10 14:49:54 2021
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sat, 10 Apr 2021 15:49:54 +0200
Subject: Patch "ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt
 pin" has been added to the 4.14-stable tree
Message-ID: <1618062594142188@kroah.com>


This is a note to let you know that I've just added the patch titled

    ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

to the 4.14-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:
     arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch
and it can be found in the queue-4.14 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 a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel at kernel.org>
Date: Sun, 21 Feb 2021 00:11:44 +0100
Subject: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -269,6 +269,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};


Patches currently in stable-queue which might be from kabel at kernel.org are

queue-4.14/arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch


From gregkh at linuxfoundation.org  Sat Apr 10 14:50:11 2021
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sat, 10 Apr 2021 15:50:11 +0200
Subject: Patch "ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt
 pin" has been added to the 4.19-stable tree
Message-ID: <161806261110245@kroah.com>


This is a note to let you know that I've just added the patch titled

    ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

to the 4.19-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:
     arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch
and it can be found in the queue-4.19 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 a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel at kernel.org>
Date: Sun, 21 Feb 2021 00:11:44 +0100
Subject: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};


Patches currently in stable-queue which might be from kabel at kernel.org are

queue-4.19/arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch


From gregkh at linuxfoundation.org  Sat Apr 10 14:51:15 2021
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sat, 10 Apr 2021 15:51:15 +0200
Subject: Patch "ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt
 pin" has been added to the 5.4-stable tree
Message-ID: <16180626757390@kroah.com>


This is a note to let you know that I've just added the patch titled

    ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

to the 5.4-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:
     arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch
and it can be found in the queue-5.4 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 a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel at kernel.org>
Date: Sun, 21 Feb 2021 00:11:44 +0100
Subject: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};


Patches currently in stable-queue which might be from kabel at kernel.org are

queue-5.4/arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch


From gregkh at linuxfoundation.org  Sat Apr 10 14:51:35 2021
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sat, 10 Apr 2021 15:51:35 +0200
Subject: Patch "ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt
 pin" has been added to the 5.10-stable tree
Message-ID: <1618062695137242@kroah.com>


This is a note to let you know that I've just added the patch titled

    ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

to the 5.10-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:
     arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch
and it can be found in the queue-5.10 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 a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel at kernel.org>
Date: Sun, 21 Feb 2021 00:11:44 +0100
Subject: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};


Patches currently in stable-queue which might be from kabel at kernel.org are

queue-5.10/arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch


From gregkh at linuxfoundation.org  Sat Apr 10 14:51:55 2021
From: gregkh at linuxfoundation.org (gregkh at linuxfoundation.org)
Date: Sat, 10 Apr 2021 15:51:55 +0200
Subject: Patch "ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt
 pin" has been added to the 5.11-stable tree
Message-ID: <16180627153127@kroah.com>


This is a note to let you know that I've just added the patch titled

    ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin

to the 5.11-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:
     arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch
and it can be found in the queue-5.11 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 a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <kabel at kernel.org>
Date: Sun, 21 Feb 2021 00:11:44 +0100
Subject: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -389,6 +389,7 @@
 	phy1: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};


Patches currently in stable-queue which might be from kabel at kernel.org are

queue-5.11/arm-dts-turris-omnia-configure-led-intn-pin-as-interrupt-pin.patch


From u.kleine-koenig at pengutronix.de  Sat Apr 10 14:53:21 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 10 Apr 2021 15:53:21 +0200
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210410135321.oissremqropvrpd3@pengutronix.de>

Hello,

just a few small details left to criticize ...

On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> new file mode 100644
> index 000000000000..99d83f94ed86
> --- /dev/null
> +++ b/drivers/pwm/pwm-visconti.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Toshiba Visconti pulse-width-modulation controller driver
> + *
> + * Copyright (c) 2020 TOSHIBA CORPORATION
> + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> + *
> + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +
> +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> +
> +#define PIPGM_PWMC_PWMACT		BIT(5)
> +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> +#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 *to_visconti_chip(struct pwm_chip *chip)
> +{
> +	return container_of(chip, struct visconti_pwm_chip, chip);
> +}
> +
> +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			      const struct pwm_state *state)
> +{
> +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> +	u32 period, duty_cycle, pwmc0;
> +
> +	/*
> +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> +	 * the period register (PCSR) is written and the currently running period is completed. This
> +	 * way the hardware switches atomically from the old setting to the new.
> +	 * Also, disabling the hardware completes the currently running period and keeps the output
> +	 * at low level at all times.

Can you please put a paragraph analogous to the one in pwm-sifive in the
same format. This simplified keeping an overview about the oddities of
the various supported chips.

> +	 */
> +	if (!state->enabled) {
> +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +		return 0;
> +	}
> +
> [...]
> +
> +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +				   struct pwm_state *state)
> +{
> +	struct visconti_pwm_chip *priv = chip_to_priv(chip);
> +	u32 period, duty, pwmc0, pwmc0_clk;
> +
> +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> +	if (period)
> +		state->enabled = true;
> +	else
> +		state->enabled = false;

If PIPGM_PCSR is 0 the hardware is still active and setting a new
configuration completes the currently running period, right? Then I
think having always state->enabled = true is a better match.

> +	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
> +	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
> +	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
> +
> +	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
> +	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
> +	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
> +		state->polarity = PWM_POLARITY_INVERSED;
> +	else
> +		state->polarity = PWM_POLARITY_NORMAL;
> +}
> +
> [...]
> +
> +static int visconti_pwm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct visconti_pwm_chip *priv;
> +	int ret;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(priv->base))
> +		return PTR_ERR(priv->base);
> +
> +	platform_set_drvdata(pdev, priv);
> +
> +	priv->chip.dev = dev;
> +	priv->chip.ops = &visconti_pwm_ops;
> +	priv->chip.npwm = 4;
> +
> +	ret = pwmchip_add(&priv->chip);
> +	if (ret < 0)
> +		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");

Thierry told to have picked up my patch to add the function
devm_pwmchip_add. I just double checked and it didn't made it into his
for-next branch yet. When you respin this series please check if the
patch landed in the mean time and then make use of it.

> +	return 0;
> +}

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/20210410/ade34435/attachment-0001.sig>

From u.kleine-koenig at pengutronix.de  Sat Apr 10 14:56:58 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 10 Apr 2021 15:56:58 +0200
Subject: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409213455.6f25m4jyttqn75hf@toshiba.co.jp>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <YHBUjPjEpLYF/915@orome.fritz.box>
 <20210409213455.6f25m4jyttqn75hf@toshiba.co.jp>
Message-ID: <20210410135658.pf7eg5x5bdhndxkg@pengutronix.de>

Hello,

On Sat, Apr 10, 2021 at 06:34:55AM +0900, Nobuhiro Iwamatsu wrote:
> > > +static int visconti_pwm_remove(struct platform_device *pdev)
> > > +{
> > > +	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
> > > +
> > > +	return pwmchip_remove(&priv->chip);
> > 
> > I think Uwe would prefer this to be done separately because he's working
> > towards removing the return value from pwmchip_remove() and if we start
> > ignoring it in new drivers that will make life easier going forward.
> > 
> > So this should just be:
> > 
> > 	pwmchip_remove(&priv->chip);
> > 
> > 	return 0;
> 
> I understand your suggestion.
> However, it looks like the pwmchip_remove() hasn't been updated yet.
> I will wait for the update of pwmchip_remove.

pwmchip_remove will always return 0 since b2c200e3f2fd which is in v5.3.
So Thierry's suggestion is safe and indeed welcome.
 
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/20210410/dc3fde6d/attachment.sig>

From willy at infradead.org  Sat Apr 10 15:06:52 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 10 Apr 2021 15:06:52 +0100
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
 <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
Message-ID: <20210410140652.GY2531743@casper.infradead.org>

How about moving the flags into the union?  A bit messy, but we don't
have to play games with __packed__.

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 1210a8e41fad..f374d2f06255 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -68,16 +68,22 @@ struct mem_cgroup;
 #endif
 
 struct page {
-	unsigned long flags;		/* Atomic flags, some possibly
-					 * updated asynchronously */
 	/*
-	 * Five words (20/40 bytes) are available in this union.
-	 * WARNING: bit 0 of the first word is used for PageTail(). That
-	 * means the other users of this union MUST NOT use the bit to
+	 * This union is six words (24 / 48 bytes) in size.
+	 * The first word is reserved for atomic flags, often updated
+	 * asynchronously.  Use the PageFoo() macros to access it.  Some
+	 * of the flags can be reused for your own purposes, but the
+	 * word as a whole often contains other information and overwriting
+	 * it will cause functions like page_zone() and page_node() to stop
+	 * working correctly.
+	 *
+	 * Bit 0 of the second word is used for PageTail(). That
+	 * means the other users of this union MUST leave the bit zero to
 	 * avoid collision and false-positive PageTail().
 	 */
 	union {
 		struct {	/* Page cache and anonymous pages */
+			unsigned long flags;
 			/**
 			 * @lru: Pageout list, eg. active_list protected by
 			 * lruvec->lru_lock.  Sometimes used as a generic list
@@ -96,6 +102,8 @@ struct page {
 			unsigned long private;
 		};
 		struct {	/* page_pool used by netstack */
+			unsigned long _pp_flags;
+			unsigned long _pp_pad;
 			/**
 			 * @dma_addr: might require a 64-bit value even on
 			 * 32-bit architectures.
@@ -103,6 +111,7 @@ struct page {
 			dma_addr_t dma_addr;
 		};
 		struct {	/* slab, slob and slub */
+			unsigned long _slab_flags;
 			union {
 				struct list_head slab_list;
 				struct {	/* Partial pages */
@@ -130,6 +139,7 @@ struct page {
 			};
 		};
 		struct {	/* Tail pages of compound page */
+			unsigned long _tail1_flags;
 			unsigned long compound_head;	/* Bit zero is set */
 
 			/* First tail page only */
@@ -139,12 +149,14 @@ struct page {
 			unsigned int compound_nr; /* 1 << compound_order */
 		};
 		struct {	/* Second tail page of compound page */
+			unsigned long _tail2_flags;
 			unsigned long _compound_pad_1;	/* compound_head */
 			atomic_t hpage_pinned_refcount;
 			/* For both global and memcg */
 			struct list_head deferred_list;
 		};
 		struct {	/* Page table pages */
+			unsigned long _pt_flags;
 			unsigned long _pt_pad_1;	/* compound_head */
 			pgtable_t pmd_huge_pte; /* protected by page->ptl */
 			unsigned long _pt_pad_2;	/* mapping */
@@ -159,6 +171,7 @@ struct page {
 #endif
 		};
 		struct {	/* ZONE_DEVICE pages */
+			unsigned long _zd_flags;
 			/** @pgmap: Points to the hosting device page map. */
 			struct dev_pagemap *pgmap;
 			void *zone_device_data;
@@ -174,8 +187,11 @@ struct page {
 			 */
 		};
 
-		/** @rcu_head: You can use this to free a page by RCU. */
-		struct rcu_head rcu_head;
+		struct {
+			unsigned long _rcu_flags;
+			/** @rcu_head: You can use this to free a page by RCU. */
+			struct rcu_head rcu_head;
+		};
 	};
 
 	union {		/* This union is 4 bytes in size. */


From julia.lawall at inria.fr  Sat Apr 10 15:08:37 2021
From: julia.lawall at inria.fr (Julia Lawall)
Date: Sat, 10 Apr 2021 16:08:37 +0200 (CEST)
Subject: [xlnx:master 59/60] drivers/mtd/spi-nor/spi-nor.c:2642:3-19:
 duplicated argument to & or | (fwd)
Message-ID: <alpine.DEB.2.22.394.2104101607480.2975@hadrien>

Please check line 2642.

julia

---------- Forwarded message ----------
Date: Sat, 10 Apr 2021 05:35:58 +0800
From: kernel test robot <lkp at intel.com>
To: kbuild at lists.01.org
Cc: lkp at intel.com, Julia Lawall <julia.lawall at lip6.fr>
Subject: [xlnx:master 59/60] drivers/mtd/spi-nor/spi-nor.c:2642:3-19: duplicated
     argument to & or |

CC: kbuild-all at lists.01.org
CC: linux-arm-kernel at lists.infradead.org
TO: Vishal Sagar <vishal.sagar at xilinx.com>
CC: Michal Simek <monstr at monstr.eu>
CC: Hyun Kwon <hyun.kwon at xilinx.com>

Hi Vishal,

First bad commit (maybe != root cause):

tree:   https://github.com/Xilinx/linux-xlnx master
head:   043f8a226a752a1dd11f7ff64cee6dbe7334d394
commit: c0b33b8ccd38096c815f2dd39746044d0aa079d3 [59/60] staging: xlnxsync: Fix the uapi header license
:::::: branch date: 11 months ago
:::::: commit date: 11 months ago
config: i386-randconfig-c001-20210409 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Julia Lawall <julia.lawall at lip6.fr>


cocci warnings: (new ones prefixed by >>)
>> drivers/mtd/spi-nor/spi-nor.c:2642:3-19: duplicated argument to & or |

vim +2642 drivers/mtd/spi-nor/spi-nor.c

48e4d973aefeea Boris Brezillon           2019-08-24  2447
b199489d37b21c Huang Shijie              2014-02-24  2448  /* NOTE: double check command sets and memory organization when you add
b199489d37b21c Huang Shijie              2014-02-24  2449   * more nor chips.  This current list focusses on newer chips, which
b199489d37b21c Huang Shijie              2014-02-24  2450   * have been converging on command sets which including JEDEC ID.
c19900edff983c Rafa? Mi?ecki             2015-04-25  2451   *
c19900edff983c Rafa? Mi?ecki             2015-04-25  2452   * All newly added entries should describe *hardware* and should use SECT_4K
c19900edff983c Rafa? Mi?ecki             2015-04-25  2453   * (or SECT_4K_PMC) if hardware supports erasing 4 KiB sectors. For usage
c19900edff983c Rafa? Mi?ecki             2015-04-25  2454   * scenarios excluding small sectors there is config option that can be
c19900edff983c Rafa? Mi?ecki             2015-04-25  2455   * disabled: CONFIG_MTD_SPI_NOR_USE_4K_SECTORS.
c19900edff983c Rafa? Mi?ecki             2015-04-25  2456   * For historical (and compatibility) reasons (before we got above config) some
c19900edff983c Rafa? Mi?ecki             2015-04-25  2457   * old entries may be missing 4K flag.
b199489d37b21c Huang Shijie              2014-02-24  2458   */
06bb6f5a69dfc5 Rafa? Mi?ecki             2015-08-10  2459  static const struct flash_info spi_nor_ids[] = {
b199489d37b21c Huang Shijie              2014-02-24  2460  	/* Atmel -- some are (confusingly) marketed as "DataFlash" */
b199489d37b21c Huang Shijie              2014-02-24  2461  	{ "at25fs010",  INFO(0x1f6601, 0, 32 * 1024,   4, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2462  	{ "at25fs040",  INFO(0x1f6604, 0, 64 * 1024,   8, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2463
b199489d37b21c Huang Shijie              2014-02-24  2464  	{ "at25df041a", INFO(0x1f4401, 0, 64 * 1024,   8, SECT_4K) },
b08618c929b289 Jagan Teki                2016-07-26  2465  	{ "at25df321",  INFO(0x1f4700, 0, 64 * 1024,  64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2466  	{ "at25df321a", INFO(0x1f4701, 0, 64 * 1024,  64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2467  	{ "at25df641",  INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2468
b199489d37b21c Huang Shijie              2014-02-24  2469  	{ "at26f004",   INFO(0x1f0400, 0, 64 * 1024,  8, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2470  	{ "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2471  	{ "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2472  	{ "at26df321",  INFO(0x1f4700, 0, 64 * 1024, 64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2473
b199489d37b21c Huang Shijie              2014-02-24  2474  	{ "at45db081d", INFO(0x1f2500, 0, 64 * 1024, 16, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2475
b199489d37b21c Huang Shijie              2014-02-24  2476  	/* EON -- en25xxx */
b199489d37b21c Huang Shijie              2014-02-24  2477  	{ "en25f32",    INFO(0x1c3116, 0, 64 * 1024,   64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2478  	{ "en25p32",    INFO(0x1c2016, 0, 64 * 1024,   64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2479  	{ "en25q32b",   INFO(0x1c3016, 0, 64 * 1024,   64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2480  	{ "en25p64",    INFO(0x1c2017, 0, 64 * 1024,  128, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2481  	{ "en25q64",    INFO(0x1c3017, 0, 64 * 1024,  128, SECT_4K) },
08326d8a9472c0 Frieder Schrempf          2019-02-18  2482  	{ "en25q80a",   INFO(0x1c3014, 0, 64 * 1024,   16,
08326d8a9472c0 Frieder Schrempf          2019-02-18  2483  			SECT_4K | SPI_NOR_DUAL_READ) },
771ff17e82fac5 YuheiOKAWA                2018-05-17  2484  	{ "en25qh32",   INFO(0x1c7016, 0, 64 * 1024,   64, 0) },
30a2c8aa3c520d Roger Pueyo Centelles     2019-02-07  2485  	{ "en25qh64",   INFO(0x1c7017, 0, 64 * 1024,  128,
30a2c8aa3c520d Roger Pueyo Centelles     2019-02-07  2486  			SECT_4K | SPI_NOR_DUAL_READ) },
a41595b34ba40f Sergey Ryazanov           2014-06-12  2487  	{ "en25qh128",  INFO(0x1c7018, 0, 64 * 1024,  256, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2488  	{ "en25qh256",  INFO(0x1c7019, 0, 64 * 1024,  512, 0) },
c19900edff983c Rafa? Mi?ecki             2015-04-25  2489  	{ "en25s64",	INFO(0x1c3817, 0, 64 * 1024,  128, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2490
b199489d37b21c Huang Shijie              2014-02-24  2491  	/* ESMT */
fcf690a22b2bd7 Victor Shyba              2017-01-02  2492  	{ "f25l32pa", INFO(0x8c2016, 0, 64 * 1024, 64, SECT_4K | SPI_NOR_HAS_LOCK) },
ca1fa1a8a6dae3 L. D. Pinney              2017-02-14  2493  	{ "f25l32qa", INFO(0x8c4116, 0, 64 * 1024, 64, SECT_4K | SPI_NOR_HAS_LOCK) },
ca1fa1a8a6dae3 L. D. Pinney              2017-02-14  2494  	{ "f25l64qa", INFO(0x8c4117, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_HAS_LOCK) },
b199489d37b21c Huang Shijie              2014-02-24  2495
b199489d37b21c Huang Shijie              2014-02-24  2496  	/* Everspin */
282e45dc64d183 Philipp Puschmann         2017-10-19  2497  	{ "mr25h128", CAT25_INFO( 16 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2498  	{ "mr25h256", CAT25_INFO( 32 * 1024, 1, 256, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2499  	{ "mr25h10",  CAT25_INFO(128 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
edd0c8f4932dbf IWAMOTO Masahiko          2016-10-05  2500  	{ "mr25h40",  CAT25_INFO(512 * 1024, 1, 256, 3, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2501
ce56ce7da31591 Rostislav Lisovy          2014-10-29  2502  	/* Fujitsu */
ce56ce7da31591 Rostislav Lisovy          2014-10-29  2503  	{ "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1, SPI_NOR_NO_ERASE) },
ce56ce7da31591 Rostislav Lisovy          2014-10-29  2504
b199489d37b21c Huang Shijie              2014-02-24  2505  	/* GigaDevice */
e9cf64dec1067e Kamal Dasu                2017-01-20  2506  	{
e9cf64dec1067e Kamal Dasu                2017-01-20  2507  		"gd25q16", INFO(0xc84015, 0, 64 * 1024,  32,
e9cf64dec1067e Kamal Dasu                2017-01-20  2508  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
e9cf64dec1067e Kamal Dasu                2017-01-20  2509  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
e9cf64dec1067e Kamal Dasu                2017-01-20  2510  	},
595f0e101d4c25 Brian Norris              2016-07-01  2511  	{
595f0e101d4c25 Brian Norris              2016-07-01  2512  		"gd25q32", INFO(0xc84016, 0, 64 * 1024,  64,
595f0e101d4c25 Brian Norris              2016-07-01  2513  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
595f0e101d4c25 Brian Norris              2016-07-01  2514  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
595f0e101d4c25 Brian Norris              2016-07-01  2515  	},
5a0682835ca270 Klaus Goger               2017-09-13  2516  	{
5a0682835ca270 Klaus Goger               2017-09-13  2517  		"gd25lq32", INFO(0xc86016, 0, 64 * 1024, 64,
5a0682835ca270 Klaus Goger               2017-09-13  2518  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
5a0682835ca270 Klaus Goger               2017-09-13  2519  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
5a0682835ca270 Klaus Goger               2017-09-13  2520  	},
595f0e101d4c25 Brian Norris              2016-07-01  2521  	{
595f0e101d4c25 Brian Norris              2016-07-01  2522  		"gd25q64", INFO(0xc84017, 0, 64 * 1024, 128,
595f0e101d4c25 Brian Norris              2016-07-01  2523  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
595f0e101d4c25 Brian Norris              2016-07-01  2524  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
595f0e101d4c25 Brian Norris              2016-07-01  2525  	},
595f0e101d4c25 Brian Norris              2016-07-01  2526  	{
595f0e101d4c25 Brian Norris              2016-07-01  2527  		"gd25lq64c", INFO(0xc86017, 0, 64 * 1024, 128,
595f0e101d4c25 Brian Norris              2016-07-01  2528  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
595f0e101d4c25 Brian Norris              2016-07-01  2529  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
595f0e101d4c25 Brian Norris              2016-07-01  2530  	},
595f0e101d4c25 Brian Norris              2016-07-01  2531  	{
595f0e101d4c25 Brian Norris              2016-07-01  2532  		"gd25q128", INFO(0xc84018, 0, 64 * 1024, 256,
595f0e101d4c25 Brian Norris              2016-07-01  2533  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
595f0e101d4c25 Brian Norris              2016-07-01  2534  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
595f0e101d4c25 Brian Norris              2016-07-01  2535  	},
65153846b18c48 Andy Yan                  2017-08-28  2536  	{
65153846b18c48 Andy Yan                  2017-08-28  2537  		"gd25q256", INFO(0xc84019, 0, 64 * 1024, 512,
65153846b18c48 Andy Yan                  2017-08-28  2538  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
65153846b18c48 Andy Yan                  2017-08-28  2539  			SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
48e4d973aefeea Boris Brezillon           2019-08-24  2540  			.fixups = &gd25q256_fixups,
65153846b18c48 Andy Yan                  2017-08-28  2541  	},
b199489d37b21c Huang Shijie              2014-02-24  2542
b199489d37b21c Huang Shijie              2014-02-24  2543  	/* Intel/Numonyx -- xxxs33b */
b199489d37b21c Huang Shijie              2014-02-24  2544  	{ "160s33b",  INFO(0x898911, 0, 64 * 1024,  32, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2545  	{ "320s33b",  INFO(0x898912, 0, 64 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2546  	{ "640s33b",  INFO(0x898913, 0, 64 * 1024, 128, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2547
b79c332fb283c1 Gabor Juhos               2015-04-07  2548  	/* ISSI */
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2549  	{ "is25wp080d", INFO(0x9d7014, 0, 64 * 1024, 32, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2550  		SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2551  	{ "is25wp016d", INFO(0x9d7015, 0, 64 * 1024, 32, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2552  		SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
b79c332fb283c1 Gabor Juhos               2015-04-07  2553  	{ "is25cd512",  INFO(0x7f9d20, 0, 32 * 1024,   2, SECT_4K) },
ded8a0447f49d7 Sean Nyekjaer             2017-12-15  2554  	{ "is25lq040b", INFO(0x9d4013, 0, 64 * 1024,   8,
ded8a0447f49d7 Sean Nyekjaer             2017-12-15  2555  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b422847877e35d Fabrizio Castro           2018-11-08  2556  	{ "is25lp016d", INFO(0x9d6015, 0, 64 * 1024,  32,
b422847877e35d Fabrizio Castro           2018-11-08  2557  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
17407ec3354d29 Romain Porte              2017-12-28  2558  	{ "is25lp080d", INFO(0x9d6014, 0, 64 * 1024,  16,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2559  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2560  			SPI_NOR_HAS_LOCK) },
4cc106f8f245ba Uwe Kleine-K?nig          2018-11-21  2561  	{ "is25lp032",  INFO(0x9d6016, 0, 64 * 1024,  64,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2562  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_HAS_LOCK) },
4cc106f8f245ba Uwe Kleine-K?nig          2018-11-21  2563  	{ "is25lp064",  INFO(0x9d6017, 0, 64 * 1024, 128,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2564  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_HAS_LOCK) },
34354d4bf845c8 Angelo Dureghello         2017-11-19  2565  	{ "is25lp128",  INFO(0x9d6018, 0, 64 * 1024, 256,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2566  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_HAS_LOCK) },
c7aa1b77f96f35 Marek Vasut               2018-04-07  2567  	{ "is25lp256",  INFO(0x9d6019, 0, 64 * 1024, 512,
d05e21e3cfc7f2 Liu Xiang                 2018-11-14  2568  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2569  			SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK)
cf580a92400584 Liu Xiang                 2019-06-25  2570  			.fixups = &is25lp256_fixups },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2571  	{ "is25wp256d", INFO(0x9d7019, 0, 64 * 1024, 512,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2572  			SECT_4K | SPI_NOR_DUAL_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2573  			SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2574  			SPI_NOR_4B_OPCODES) },
d616f81cdd2a21 Kimmo Rautkoski           2018-05-14  2575  	{ "is25wp032",  INFO(0x9d7016, 0, 64 * 1024,  64,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2576  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2577  			SPI_NOR_HAS_LOCK) },
d616f81cdd2a21 Kimmo Rautkoski           2018-05-14  2578  	{ "is25wp064",  INFO(0x9d7017, 0, 64 * 1024, 128,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2579  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2580  			 | SPI_NOR_HAS_LOCK) },
d616f81cdd2a21 Kimmo Rautkoski           2018-05-14  2581  	{ "is25wp128",  INFO(0x9d7018, 0, 64 * 1024, 256,
d616f81cdd2a21 Kimmo Rautkoski           2018-05-14  2582  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2583  	{ "is25lp512m", INFO(0x9d601a, 0, 64 * 1024, 1024,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2584  			SECT_4K | SPI_NOR_DUAL_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2585  			SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2586  	{ "is25wp512m", INFO(0x9d701a, 0, 64 * 1024, 1024,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2587  			SECT_4K | SPI_NOR_DUAL_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2588  			SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2589  			SPI_NOR_4B_OPCODES) },
b79c332fb283c1 Gabor Juhos               2015-04-07  2590
b199489d37b21c Huang Shijie              2014-02-24  2591  	/* Macronix */
660b5b07cfbc39 Gabor Juhos               2015-04-07  2592  	{ "mx25l512e",   INFO(0xc22010, 0, 64 * 1024,   1, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2593  	{ "mx25l2005a",  INFO(0xc22012, 0, 64 * 1024,   4, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2594  	{ "mx25l4005a",  INFO(0xc22013, 0, 64 * 1024,   8, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2595  	{ "mx25l8005",   INFO(0xc22014, 0, 64 * 1024,  16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2596  	{ "mx25l1606e",  INFO(0xc22015, 0, 64 * 1024,  32, SECT_4K) },
0501f2e5ff28a0 Andreas Fenkart           2015-11-05  2597  	{ "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2598  	{ "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
0501f2e5ff28a0 Andreas Fenkart           2015-11-05  2599  	{ "mx25l6405d",  INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
9f3cd4537da071 Alexander Kurz            2017-03-11  2600  	{ "mx25u2033e",  INFO(0xc22532, 0, 64 * 1024,   4, SECT_4K) },
748df6d831871c Andr? Valentin            2019-01-30  2601  	{ "mx25u3235f",	 INFO(0xc22536, 0, 64 * 1024,  64,
748df6d831871c Andr? Valentin            2019-01-30  2602  			 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
9f3cd4537da071 Alexander Kurz            2017-03-11  2603  	{ "mx25u4035",   INFO(0xc22533, 0, 64 * 1024,   8, SECT_4K) },
9f3cd4537da071 Alexander Kurz            2017-03-11  2604  	{ "mx25u8035",   INFO(0xc22534, 0, 64 * 1024,  16, SECT_4K) },
81a1209c90914c Mika Westerberg           2015-02-05  2605  	{ "mx25u6435f",  INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2606  	{ "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2607  	{ "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
81554171373018 Alexander Sverdlin        2018-07-13  2608  	{ "mx25u12835f", INFO(0xc22538, 0, 64 * 1024, 256,
81554171373018 Alexander Sverdlin        2018-07-13  2609  			 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
2bffa65da43e39 Boris Brezillon           2018-12-06  2610  	{ "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512,
2bffa65da43e39 Boris Brezillon           2018-12-06  2611  			 SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
2bffa65da43e39 Boris Brezillon           2018-12-06  2612  			 .fixups = &mx25l25635_fixups },
b0fcb4b4130283 Mathias Kresin            2017-04-13  2613  	{ "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_4B_OPCODES) },
e36bb65e5d0cf3 Frieder Schrempf          2019-02-18  2614  	{ "mx25v8035f",  INFO(0xc22314, 0, 64 * 1024,  16,
e36bb65e5d0cf3 Frieder Schrempf          2019-02-18  2615  			 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2616  	{ "mx25l25655e", INFO(0xc22619, 0, 64 * 1024, 512, 0) },
d342b6a973af45 Roman Yeryomin            2017-09-18  2617  	{ "mx66l51235l", INFO(0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
af18ba48420e39 Alexander Sverdlin        2017-06-22  2618  	{ "mx66u51235f", INFO(0xc2253a, 0, 64 * 1024, 1024, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
ce398a8141b485 C?dric Le Goater          2017-04-19  2619  	{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2620  	{ "mx66u1g45g",  INFO(0xc2253b, 0, 64 * 1024, 2048, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2621  			SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2622  	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2623
0005aad094538e Yogesh Narayan Gaur       2018-10-12  2624  	/* Micron <--> ST Micro */
61e4611864b396 Moritz Fischer            2016-07-15  2625  	{ "n25q016a",	 INFO(0x20bb15, 0, 64 * 1024,   32, SECT_4K | SPI_NOR_QUAD_READ) },
548cd3ab54da10 Bean Huo ??? (beanhuo  2014-12-17  2626) 	{ "n25q032",	 INFO(0x20ba16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
f9bcb6dc8013d4 Aurelien Chanot           2015-10-07  2627  	{ "n25q032a",	 INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) },
0db7fae2736d0d Alexey Firago             2015-06-30  2628  	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
2a06c7b1fd2389 Mika Westerberg           2015-08-27  2629  	{ "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2630  	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2631  			SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2632  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2633  			SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2634  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2635  			SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_FSR |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2636  			SPI_NOR_HAS_LOCK) },
835ed7bf12609c Nobuhiro Iwamatsu         2017-03-23  2637  	{ "n25q256ax1",  INFO(0x20bb19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2638  	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2639  			USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2640  	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2641  			USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19 @2642  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2643  	{ "n25q00a",     INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2644  			USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2645  			SPI_NOR_HAS_LOCK) },
21ed90acd17868 Andrey Smirnov            2019-05-12  2646  	{ "mt25ql02g",   INFO(0x20ba22, 0, 64 * 1024, 4096,
21ed90acd17868 Andrey Smirnov            2019-05-12  2647  			      SECT_4K | USE_FSR | SPI_NOR_QUAD_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2648  			      NO_CHIP_ERASE | SPI_NOR_HAS_LOCK) },
9607af6f857ff0 Ashish Kumar              2019-08-29  2649  	{ "mt25qu512a (n25q512a)", INFO(0x20bb20, 0, 64 * 1024, 1024,
9607af6f857ff0 Ashish Kumar              2019-08-29  2650  					SECT_4K | USE_FSR | SPI_NOR_DUAL_READ |
9607af6f857ff0 Ashish Kumar              2019-08-29  2651  					SPI_NOR_QUAD_READ |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2652  					SPI_NOR_HAS_LOCK) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2653  	{ "mt25qu02g",   INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2654  			USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2655  			SPI_NOR_HAS_LOCK) },
b199489d37b21c Huang Shijie              2014-02-24  2656
a98086e00420ad Yogesh Narayan Gaur       2018-10-12  2657  	/* Micron */
a98086e00420ad Yogesh Narayan Gaur       2018-10-12  2658  	{
a98086e00420ad Yogesh Narayan Gaur       2018-10-12  2659  		"mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512,
2bda2f811b36cb Yogesh Narayan Gaur       2019-01-15  2660  			SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
606a7db700558f Sai Krishna Potthuri      2019-12-26  2661  			SPI_NOR_OCTAL_WRITE | SPI_NOR_4B_OPCODES)
a98086e00420ad Yogesh Narayan Gaur       2018-10-12  2662  	},
aba8d95e112099 Sai Krishna Potthuri      2019-12-26  2663  	{ "mt35xu01g",  INFO(0x2c5b1b, 0, 128 * 1024, 1024,
aba8d95e112099 Sai Krishna Potthuri      2019-12-26  2664  			    SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
aba8d95e112099 Sai Krishna Potthuri      2019-12-26  2665  			    SPI_NOR_OCTAL_WRITE | SPI_NOR_4B_OPCODES) },
173c3d47736e31 Ashish Kumar              2019-08-29  2666  	{ "mt35xu02g",  INFO(0x2c5b1c, 0, 128 * 1024, 2048,
173c3d47736e31 Ashish Kumar              2019-08-29  2667  			     SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
606a7db700558f Sai Krishna Potthuri      2019-12-26  2668  			     SPI_NOR_OCTAL_WRITE | SPI_NOR_4B_OPCODES) },
a98086e00420ad Yogesh Narayan Gaur       2018-10-12  2669
b199489d37b21c Huang Shijie              2014-02-24  2670  	/* PMC */
b199489d37b21c Huang Shijie              2014-02-24  2671  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
b199489d37b21c Huang Shijie              2014-02-24  2672  	{ "pm25lv010",   INFO(0,        0, 32 * 1024,    4, SECT_4K_PMC) },
b199489d37b21c Huang Shijie              2014-02-24  2673  	{ "pm25lq032",   INFO(0x7f9d46, 0, 64 * 1024,   64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2674
0074a8f3b30302 Rafael Gago               2017-12-21  2675  	/* Spansion/Cypress -- single (large) sector size only, at least
b199489d37b21c Huang Shijie              2014-02-24  2676  	 * for the chips listed here (without boot sectors).
b199489d37b21c Huang Shijie              2014-02-24  2677  	 */
9ab86995ed07f5 Geert Uytterhoeven        2014-04-22  2678  	{ "s25sl032p",  INFO(0x010215, 0x4d00,  64 * 1024,  64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
0f12a27b47284e Joachim Eastwood          2015-08-14  2679  	{ "s25sl064p",  INFO(0x010216, 0x4d00,  64 * 1024, 128, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
50685024f27358 Ahmet Celenk              2019-02-12  2680  	{ "s25fl128s0", INFO6(0x012018, 0x4d0080, 256 * 1024, 64,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2681  			SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2682  			SPI_NOR_HAS_LOCK) },
50685024f27358 Ahmet Celenk              2019-02-12  2683  	{ "s25fl128s1", INFO6(0x012018, 0x4d0180, 64 * 1024, 256,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2684  			SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR |
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2685  			SPI_NOR_HAS_LOCK) },
c4b3eacc1dfef5 Alexander Sverdlin        2017-07-17  2686  	{ "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, USE_CLSR) },
c4b3eacc1dfef5 Alexander Sverdlin        2017-07-17  2687  	{ "s25fl256s1", INFO(0x010219, 0x4d01,  64 * 1024, 512, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
dcb4b22eeaf44f Jonas Bonn                2019-03-20  2688  	{ "s25fl512s",  INFO6(0x010220, 0x4d0080, 256 * 1024, 256,
dcb4b22eeaf44f Jonas Bonn                2019-03-20  2689  			SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
e7023898034ea3 Jungseung Lee             2019-07-13  2690  			SPI_NOR_HAS_LOCK | USE_CLSR) },
dfd2b74530e908 Sergei Shtylyov           2019-01-16  2691  	{ "s25fs512s",  INFO6(0x010220, 0x4d0081, 256 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
b199489d37b21c Huang Shijie              2014-02-24  2692  	{ "s70fl01gs",  INFO(0x010221, 0x4d00, 256 * 1024, 256, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2693  	{ "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2694  	{ "s25sl12801", INFO(0x012018, 0x0301,  64 * 1024, 256, 0) },
c4b3eacc1dfef5 Alexander Sverdlin        2017-07-17  2695  	{ "s25fl129p0", INFO(0x012018, 0x4d00, 256 * 1024,  64, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
c4b3eacc1dfef5 Alexander Sverdlin        2017-07-17  2696  	{ "s25fl129p1", INFO(0x012018, 0x4d01,  64 * 1024, 256, SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
b199489d37b21c Huang Shijie              2014-02-24  2697  	{ "s25sl004a",  INFO(0x010212,      0,  64 * 1024,   8, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2698  	{ "s25sl008a",  INFO(0x010213,      0,  64 * 1024,  16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2699  	{ "s25sl016a",  INFO(0x010214,      0,  64 * 1024,  32, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2700  	{ "s25sl032a",  INFO(0x010215,      0,  64 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2701  	{ "s25sl064a",  INFO(0x010216,      0,  64 * 1024, 128, 0) },
7c748f5774cb74 Sean Nyekjaer             2015-10-13  2702  	{ "s25fl004k",  INFO(0xef4013,      0,  64 * 1024,   8, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
adf508c347c3a5 Joachim Eastwood          2015-07-09  2703  	{ "s25fl008k",  INFO(0xef4014,      0,  64 * 1024,  16, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
adf508c347c3a5 Joachim Eastwood          2015-07-09  2704  	{ "s25fl016k",  INFO(0xef4015,      0,  64 * 1024,  32, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2705  	{ "s25fl064k",  INFO(0xef4017,      0,  64 * 1024, 128, SECT_4K) },
c08266794926a9 Sascha Hauer              2016-02-11  2706  	{ "s25fl116k",  INFO(0x014015,      0,  64 * 1024,  32, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
c19900edff983c Rafa? Mi?ecki             2015-04-25  2707  	{ "s25fl132k",  INFO(0x014016,      0,  64 * 1024,  64, SECT_4K) },
413780d7d7040c Rafa? Mi?ecki             2015-04-25  2708  	{ "s25fl164k",  INFO(0x014017,      0,  64 * 1024, 128, SECT_4K) },
aada20cd2b1af7 Sean Nyekjaer             2015-10-13  2709  	{ "s25fl204k",  INFO(0x014013,      0,  64 * 1024,   8, SECT_4K | SPI_NOR_DUAL_READ) },
022a400f90ceeb Sean Nyekjaer             2016-10-05  2710  	{ "s25fl208k",  INFO(0x014014,      0,  64 * 1024,  16, SECT_4K | SPI_NOR_DUAL_READ) },
d8b494a32889ea Harry Chou                2017-06-23  2711  	{ "s25fl064l",  INFO(0x016017,      0,  64 * 1024, 128, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
0074a8f3b30302 Rafael Gago               2017-12-21  2712  	{ "s25fl128l",  INFO(0x016018,      0,  64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
0074a8f3b30302 Rafael Gago               2017-12-21  2713  	{ "s25fl256l",  INFO(0x016019,      0,  64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2714  	{ "sst26wf016B", INFO(0xbf2651, 0, 64 * 1024, 32,
d2c139cd25f72b Amit Kumar Mahapatra      2020-01-19  2715  			SECT_4K | SST_GLOBAL_PROT_UNLK) },
b199489d37b21c Huang Shijie              2014-02-24  2716
b199489d37b21c Huang Shijie              2014-02-24  2717  	/* SST -- large erase sizes are "overlays", "sectors" are 4K */
b199489d37b21c Huang Shijie              2014-02-24  2718  	{ "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2719  	{ "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2720  	{ "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2721  	{ "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2722  	{ "sst25vf064c", INFO(0xbf254b, 0, 64 * 1024, 128, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2723  	{ "sst25wf512",  INFO(0xbf2501, 0, 64 * 1024,  1, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2724  	{ "sst25wf010",  INFO(0xbf2502, 0, 64 * 1024,  2, SECT_4K | SST_WRITE) },
b199489d37b21c Huang Shijie              2014-02-24  2725  	{ "sst25wf020",  INFO(0xbf2503, 0, 64 * 1024,  4, SECT_4K | SST_WRITE) },
a1d97ef96e3899 Alexis Ballier            2015-08-14  2726  	{ "sst25wf020a", INFO(0x621612, 0, 64 * 1024,  4, SECT_4K) },
c887be71cc3984 Yao Yuan                  2015-09-16  2727  	{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024,  8, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2728  	{ "sst25wf040",  INFO(0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
f02985b78550f5 Harini Katakam            2014-10-21  2729  	{ "sst25wf080",  INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
6dc944db29ba9c Eugeniy Paltsev           2019-07-18  2730  	{ "sst26wf016b", INFO(0xbf2651, 0, 64 * 1024, 32, SECT_4K |
6dc944db29ba9c Eugeniy Paltsev           2019-07-18  2731  			      SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
4b265184095df6 Amit Kumar Mahapatra      2020-02-20  2732  	{ "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32,
4b265184095df6 Amit Kumar Mahapatra      2020-02-20  2733  			      SECT_4K | SST_GLOBAL_PROT_UNLK) },
18f7ce2f449504 Claudiu Beznea            2017-08-22  2734  	{ "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2735
b199489d37b21c Huang Shijie              2014-02-24  2736  	/* ST Microelectronics -- newer production may have feature updates */
b199489d37b21c Huang Shijie              2014-02-24  2737  	{ "m25p05",  INFO(0x202010,  0,  32 * 1024,   2, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2738  	{ "m25p10",  INFO(0x202011,  0,  32 * 1024,   4, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2739  	{ "m25p20",  INFO(0x202012,  0,  64 * 1024,   4, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2740  	{ "m25p40",  INFO(0x202013,  0,  64 * 1024,   8, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2741  	{ "m25p80",  INFO(0x202014,  0,  64 * 1024,  16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2742  	{ "m25p16",  INFO(0x202015,  0,  64 * 1024,  32, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2743  	{ "m25p32",  INFO(0x202016,  0,  64 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2744  	{ "m25p64",  INFO(0x202017,  0,  64 * 1024, 128, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2745  	{ "m25p128", INFO(0x202018,  0, 256 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2746
b199489d37b21c Huang Shijie              2014-02-24  2747  	{ "m25p05-nonjedec",  INFO(0, 0,  32 * 1024,   2, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2748  	{ "m25p10-nonjedec",  INFO(0, 0,  32 * 1024,   4, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2749  	{ "m25p20-nonjedec",  INFO(0, 0,  64 * 1024,   4, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2750  	{ "m25p40-nonjedec",  INFO(0, 0,  64 * 1024,   8, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2751  	{ "m25p80-nonjedec",  INFO(0, 0,  64 * 1024,  16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2752  	{ "m25p16-nonjedec",  INFO(0, 0,  64 * 1024,  32, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2753  	{ "m25p32-nonjedec",  INFO(0, 0,  64 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2754  	{ "m25p64-nonjedec",  INFO(0, 0,  64 * 1024, 128, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2755  	{ "m25p128-nonjedec", INFO(0, 0, 256 * 1024,  64, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2756
b199489d37b21c Huang Shijie              2014-02-24  2757  	{ "m45pe10", INFO(0x204011,  0, 64 * 1024,    2, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2758  	{ "m45pe80", INFO(0x204014,  0, 64 * 1024,   16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2759  	{ "m45pe16", INFO(0x204015,  0, 64 * 1024,   32, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2760
b199489d37b21c Huang Shijie              2014-02-24  2761  	{ "m25pe20", INFO(0x208012,  0, 64 * 1024,  4,       0) },
b199489d37b21c Huang Shijie              2014-02-24  2762  	{ "m25pe80", INFO(0x208014,  0, 64 * 1024, 16,       0) },
b199489d37b21c Huang Shijie              2014-02-24  2763  	{ "m25pe16", INFO(0x208015,  0, 64 * 1024, 32, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2764
b199489d37b21c Huang Shijie              2014-02-24  2765  	{ "m25px16",    INFO(0x207115,  0, 64 * 1024, 32, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2766  	{ "m25px32",    INFO(0x207116,  0, 64 * 1024, 64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2767  	{ "m25px32-s0", INFO(0x207316,  0, 64 * 1024, 64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2768  	{ "m25px32-s1", INFO(0x206316,  0, 64 * 1024, 64, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2769  	{ "m25px64",    INFO(0x207117,  0, 64 * 1024, 128, 0) },
f2fabe16b819cd Thomas Petazzoni          2014-07-27  2770  	{ "m25px80",    INFO(0x207114,  0, 64 * 1024, 16, 0) },
b199489d37b21c Huang Shijie              2014-02-24  2771
b199489d37b21c Huang Shijie              2014-02-24  2772  	/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
40d19ab69c79da Gabor Juhos               2015-03-26  2773  	{ "w25x05", INFO(0xef3010, 0, 64 * 1024,  1,  SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2774  	{ "w25x10", INFO(0xef3011, 0, 64 * 1024,  2,  SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2775  	{ "w25x20", INFO(0xef3012, 0, 64 * 1024,  4,  SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2776  	{ "w25x40", INFO(0xef3013, 0, 64 * 1024,  8,  SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2777  	{ "w25x80", INFO(0xef3014, 0, 64 * 1024,  16, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2778  	{ "w25x16", INFO(0xef3015, 0, 64 * 1024,  32, SECT_4K) },
ace3cbdd23dc49 Neil Armstrong            2017-08-28  2779  	{
ace3cbdd23dc49 Neil Armstrong            2017-08-28  2780  		"w25q16dw", INFO(0xef6015, 0, 64 * 1024,  32,
ace3cbdd23dc49 Neil Armstrong            2017-08-28  2781  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
ace3cbdd23dc49 Neil Armstrong            2017-08-28  2782  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
ace3cbdd23dc49 Neil Armstrong            2017-08-28  2783  	},
b199489d37b21c Huang Shijie              2014-02-24  2784  	{ "w25x32", INFO(0xef3016, 0, 64 * 1024,  64, SECT_4K) },
88489c29de6078 Robert Marko              2019-05-18  2785  	{
88489c29de6078 Robert Marko              2019-05-18  2786  		"w25q16jv-im/jm", INFO(0xef7015, 0, 64 * 1024,  32,
88489c29de6078 Robert Marko              2019-05-18  2787  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
88489c29de6078 Robert Marko              2019-05-18  2788  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
88489c29de6078 Robert Marko              2019-05-18  2789  	},
34fc99dbf32d8c Alexander Kurz            2017-03-11  2790  	{ "w25q20cl", INFO(0xef4012, 0, 64 * 1024,  4, SECT_4K) },
34fc99dbf32d8c Alexander Kurz            2017-03-11  2791  	{ "w25q20bw", INFO(0xef5012, 0, 64 * 1024,  4, SECT_4K) },
34fc99dbf32d8c Alexander Kurz            2017-03-11  2792  	{ "w25q20ew", INFO(0xef6012, 0, 64 * 1024,  4, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2793  	{ "w25q32", INFO(0xef4016, 0, 64 * 1024,  64, SECT_4K) },
9648388fc77373 Brian Norris              2016-01-29  2794  	{
9648388fc77373 Brian Norris              2016-01-29  2795  		"w25q32dw", INFO(0xef6016, 0, 64 * 1024,  64,
9648388fc77373 Brian Norris              2016-01-29  2796  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
9648388fc77373 Brian Norris              2016-01-29  2797  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
9648388fc77373 Brian Norris              2016-01-29  2798  	},
7fccf56ea4faef Stephen Douthit           2018-03-07  2799  	{
7fccf56ea4faef Stephen Douthit           2018-03-07  2800  		"w25q32jv", INFO(0xef7016, 0, 64 * 1024,  64,
7fccf56ea4faef Stephen Douthit           2018-03-07  2801  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
7fccf56ea4faef Stephen Douthit           2018-03-07  2802  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
7fccf56ea4faef Stephen Douthit           2018-03-07  2803  	},
b199489d37b21c Huang Shijie              2014-02-24  2804  	{ "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2805  	{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) },
9648388fc77373 Brian Norris              2016-01-29  2806  	{
9648388fc77373 Brian Norris              2016-01-29  2807  		"w25q64dw", INFO(0xef6017, 0, 64 * 1024, 128,
9648388fc77373 Brian Norris              2016-01-29  2808  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
9648388fc77373 Brian Norris              2016-01-29  2809  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
9648388fc77373 Brian Norris              2016-01-29  2810  	},
9648388fc77373 Brian Norris              2016-01-29  2811  	{
9648388fc77373 Brian Norris              2016-01-29  2812  		"w25q128fw", INFO(0xef6018, 0, 64 * 1024, 256,
9648388fc77373 Brian Norris              2016-01-29  2813  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
9648388fc77373 Brian Norris              2016-01-29  2814  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
9648388fc77373 Brian Norris              2016-01-29  2815  	},
d720a43333b0c2 Robert Marko              2018-06-25  2816  	{
d720a43333b0c2 Robert Marko              2018-06-25  2817  		"w25q128jv", INFO(0xef7018, 0, 64 * 1024, 256,
d720a43333b0c2 Robert Marko              2018-06-25  2818  			SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
d720a43333b0c2 Robert Marko              2018-06-25  2819  			SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
d720a43333b0c2 Robert Marko              2018-06-25  2820  	},
b199489d37b21c Huang Shijie              2014-02-24  2821  	{ "w25q80", INFO(0xef5014, 0, 64 * 1024,  16, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2822  	{ "w25q80bl", INFO(0xef4014, 0, 64 * 1024,  16, SECT_4K) },
b199489d37b21c Huang Shijie              2014-02-24  2823  	{ "w25q128", INFO(0xef4018, 0, 64 * 1024, 256, SECT_4K) },
d7c9ade2e31dba C?dric Le Goater          2017-04-19  2824  	{ "w25q256", INFO(0xef4019, 0, 64 * 1024, 512, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
3123db1d265185 Avi Fishman               2019-07-30  2825  	{ "w25q256jvm", INFO(0xef7019, 0, 64 * 1024, 512,
3123db1d265185 Avi Fishman               2019-07-30  2826  			     SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
0cbef932bd8285 Benjamin Herrenschmidt    2017-06-21  2827  	{ "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
0cbef932bd8285 Benjamin Herrenschmidt    2017-06-21  2828  			SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2829
b199489d37b21c Huang Shijie              2014-02-24  2830  	/* Catalyst / On Semiconductor -- non-JEDEC */
b199489d37b21c Huang Shijie              2014-02-24  2831  	{ "cat25c11", CAT25_INFO(  16, 8, 16, 1, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2832  	{ "cat25c03", CAT25_INFO(  32, 8, 16, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2833  	{ "cat25c09", CAT25_INFO( 128, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2834  	{ "cat25c17", CAT25_INFO( 256, 8, 32, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
b199489d37b21c Huang Shijie              2014-02-24  2835  	{ "cat25128", CAT25_INFO(2048, 8, 64, 2, SPI_NOR_NO_ERASE | SPI_NOR_NO_FR) },
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2836
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2837  	/* Xilinx S3AN Internal Flash */
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2838  	{ "3S50AN", S3AN_INFO(0x1f2200, 64, 264) },
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2839  	{ "3S200AN", S3AN_INFO(0x1f2400, 256, 264) },
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2840  	{ "3S400AN", S3AN_INFO(0x1f2400, 256, 264) },
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2841  	{ "3S700AN", S3AN_INFO(0x1f2500, 512, 264) },
e99ca98f1d7190 Ricardo Ribalda Delgado   2016-12-02  2842  	{ "3S1400AN", S3AN_INFO(0x1f2600, 512, 528) },
ce5013ff3bec05 Hauke Mehrtens            2018-04-18  2843
ce5013ff3bec05 Hauke Mehrtens            2018-04-18  2844  	/* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */
ce5013ff3bec05 Hauke Mehrtens            2018-04-18  2845  	{ "XM25QH64A", INFO(0x207017, 0, 64 * 1024, 128, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
ce5013ff3bec05 Hauke Mehrtens            2018-04-18  2846  	{ "XM25QH128A", INFO(0x207018, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
b199489d37b21c Huang Shijie              2014-02-24  2847  	{ },
b199489d37b21c Huang Shijie              2014-02-24  2848  };
b199489d37b21c Huang Shijie              2014-02-24  2849

:::::: The code at line 2642 was first introduced by commit
:::::: d2c139cd25f72b5ba2f6927fcce17c69f0a8fab7 mtd: spi-nor: Update flags for serial NOR flash devices

:::::: TO: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29113 bytes
Desc: 
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210410/a4e27ea6/attachment-0001.gz>

From David.Laight at ACULAB.COM  Sat Apr 10 15:17:04 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 10 Apr 2021 14:17:04 +0000
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <20210410024313.GX2531743@casper.infradead.org>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
Message-ID: <b9d5b09eaec44334b29241e16b8605d5@AcuMS.aculab.com>

From: Matthew Wilcox
> Sent: 10 April 2021 03:43
> On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel test robot wrote:
> > >> include/linux/mm_types.h:274:1: error: static_assert failed due to requirement
> '__builtin_offsetof(struct page, lru) == __builtin_offsetof(struct folio, lru)' "offsetof(struct page,
> lru) == offsetof(struct folio, lru)"
> >    FOLIO_MATCH(lru, lru);
> >    include/linux/mm_types.h:272:2: note: expanded from macro 'FOLIO_MATCH'
> >            static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))
> 
> Well, this is interesting.  pahole reports:
> 
> struct page {
>         long unsigned int          flags;                /*     0     4 */
>         /* XXX 4 bytes hole, try to pack */
>         union {
>                 struct {
>                         struct list_head lru;            /*     8     8 */
> ...
> struct folio {
>         union {
>                 struct {
>                         long unsigned int flags;         /*     0     4 */
>                         struct list_head lru;            /*     4     8 */
> 
> so this assert has absolutely done its job.
> 
> But why has this assert triggered?  Why is struct page layout not what
> we thought it was?  Turns out it's the dma_addr added in 2019 by commit
> c25fff7171be ("mm: add dma_addr_t to struct page").  On this particular
> config, it's 64-bit, and ppc32 requires alignment to 64-bit.  So
> the whole union gets moved out by 4 bytes.
> 
> Unfortunately, we can't just fix this by putting an 'unsigned long pad'
> in front of it.  It still aligns the entire union to 8 bytes, and then
> it skips another 4 bytes after the pad.
> 
> We can fix it like this ...
> 
> +++ b/include/linux/mm_types.h
> @@ -96,11 +96,12 @@ struct page {
>                         unsigned long private;
>                 };
>                 struct {        /* page_pool used by netstack */
> +                       unsigned long _page_pool_pad;
>                         /**
>                          * @dma_addr: might require a 64-bit value even on
>                          * 32-bit architectures.
>                          */
> -                       dma_addr_t dma_addr;
> +                       dma_addr_t dma_addr __packed;
>                 };
>                 struct {        /* slab, slob and slub */
>                         union {
> 
> but I don't know if GCC is smart enough to realise that dma_addr is now
> on an 8 byte boundary and it can use a normal instruction to access it,
> or whether it'll do something daft like use byte loads to access it.

I'm betting it will use byte accesses.
Checked - it does seem to use 4-byte accesses.
(godbolt is rather short of 32 bit compilers...)

> 
> We could also do:
> 
> +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));

I wonder if __aligned(n) should be defined as
	__attribute__((packed,aligned(n))
I don't think you ever want the 'unpacked' variant.

But explicitly reducing the alignment of single member is much
better than the habit of marking the structure 'packed'.

(Never mind the habit of adding __packed 'because we don't want
the compiler to add random padding.)

> 
> and I see pahole, at least sees this correctly:
> 
>                 struct {
>                         long unsigned int _page_pool_pad; /*     4     4 */
>                         dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
>                 } __attribute__((__packed__)) __attribute__((__aligned__(4)));

Is the attribute on the struct an artifact of pahole?
It should just have an alignment of 4 without anything special.

> 
> This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> / dma_addr_t.  Advice, please?

Only those where a 64-bit value is 64-bit aligned.
So that excludes x86 (which can have 64-bit dma) but includes sparc32
(which probably doesn't).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From linux at armlinux.org.uk  Sat Apr 10 16:54:49 2021
From: linux at armlinux.org.uk (Russell King - ARM Linux admin)
Date: Sat, 10 Apr 2021 16:54:49 +0100
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <20210410140652.GY2531743@casper.infradead.org>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
 <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
 <20210410140652.GY2531743@casper.infradead.org>
Message-ID: <20210410155449.GI1463@shell.armlinux.org.uk>

On Sat, Apr 10, 2021 at 03:06:52PM +0100, Matthew Wilcox wrote:
> How about moving the flags into the union?  A bit messy, but we don't
> have to play games with __packed__.

Yes, that is probably the better solution, avoiding the games to try
and get the union appropriately placed on 32-bit systems.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


From krzysztof.kozlowski at canonical.com  Sat Apr 10 17:47:28 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Sat, 10 Apr 2021 18:47:28 +0200
Subject: [PATCH]  iio: adc: exynos: drop unneeded variable assignment
Message-ID: <20210410164728.8096-1-krzysztof.kozlowski@canonical.com>

The initialization of 'ret' variable in probe function is shortly after
overwritten.  This initialization is simply not used.

Addresses-Coverity: Unused value
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/iio/adc/exynos_adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 784c10deeb1a..2d8e36408f0e 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -794,7 +794,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
 	struct s3c2410_ts_mach_info *pdata = dev_get_platdata(&pdev->dev);
 	struct iio_dev *indio_dev = NULL;
 	bool has_ts = false;
-	int ret = -ENODEV;
+	int ret;
 	int irq;
 
 	indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct exynos_adc));
-- 
2.25.1



From ilya.lipnitskiy at gmail.com  Sat Apr 10 18:33:31 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Sat, 10 Apr 2021 10:33:31 -0700
Subject: [PATCH] staging: mt7621-pci: stop using of_pci_range_to_resource
Message-ID: <20210410173331.57949-1-ilya.lipnitskiy@gmail.com>

The logic here was already overriding the erroneous IO addresses
returned from of_pci_range_to_resource, which is the bulk of the logic.

So stop using it altogether and initialize the fields explicitly, as
done in aeba3731b150 ("powerpc/pci: Fix IO space breakage after
of_pci_range_to_resource() change").

Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
Cc: Sergio Paracuellos <sergio.paracuellos at gmail.com>
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c b/drivers/staging/mt7621-pci/pci-mt7621.c
index 1781c1dcf5b4..115250115f10 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -301,18 +301,19 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct pci_host_bridge *host)
 
 	/*
 	 * IO_SPACE_LIMIT for MIPS is 0xffff but this platform uses IO at
-	 * upper address 0x001e160000 so we have to get the resource from
-	 * the DT because when it has been requested it failed and has been
-	 * removed from bridge->dma_ranges and bridge->windows. So parse it
-	 * and remap it manually to make things work.
+	 * upper address 0x001e160000. of_pci_range_to_resource does not work
+	 * well for MIPS platforms that don't define PCI_IOBASE, so set the IO
+	 * resource manually instead.
 	 */
+	pcie->io.name = node->full_name;
+	pcie->io.parent = pcie->io.child = pcie->io.sibling = NULL;
 	for_each_of_pci_range(&parser, &range) {
 		switch (range.flags & IORESOURCE_TYPE_BITS) {
 		case IORESOURCE_IO:
 			pcie->io_map_base =
 				(unsigned long)ioremap(range.cpu_addr,
 						       range.size);
-			of_pci_range_to_resource(&range, node, &pcie->io);
+			pcie->io.flags = range.flags;
 			pcie->io.start = range.cpu_addr;
 			pcie->io.end = range.cpu_addr + range.size - 1;
 			set_io_port_base(pcie->io_map_base);
-- 
2.31.1



From eantoranz at gmail.com  Sat Apr 10 19:11:17 2021
From: eantoranz at gmail.com (Edmundo Carmona Antoranz)
Date: Sat, 10 Apr 2021 12:11:17 -0600
Subject: [PATCH -next] arm64: vdso: correct definition of macro
 vdso_clocksource_ok
Message-ID: <20210410181117.23967-1-eantoranz@gmail.com>

The macro vdso_clocksource_ok is shadowing a function with the same
name and so it actually makes no difference to have the macro defined
or not. Take a hint from x86, rename the function to have the
arch_ prefix and correct the definition of the macro.

Signed-off-by: Edmundo Carmona Antoranz <eantoranz at gmail.com>
---
 arch/arm64/include/asm/vdso/compat_gettimeofday.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index 7508b0ac1d21..055d9e42a05d 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -166,11 +166,11 @@ static __always_inline const struct vdso_data *__arch_get_timens_vdso_data(void)
 }
 #endif
 
-static inline bool vdso_clocksource_ok(const struct vdso_data *vd)
+static inline bool arch_vdso_clocksource_ok(const struct vdso_data *vd)
 {
 	return vd->clock_mode == VDSO_CLOCKMODE_ARCHTIMER;
 }
-#define vdso_clocksource_ok	vdso_clocksource_ok
+#define vdso_clocksource_ok arch_vdso_clocksource_ok
 
 #endif /* !__ASSEMBLY__ */
 
-- 
2.20.1



From eantoranz at gmail.com  Sat Apr 10 19:12:59 2021
From: eantoranz at gmail.com (Edmundo Carmona Antoranz)
Date: Sat, 10 Apr 2021 12:12:59 -0600
Subject: [PATCH -next] arm: vfp: correct typo in kerneldoc
Message-ID: <20210410181259.25113-1-eantoranz@gmail.com>

kerneldoc for vfp_notifier in vfpmodule.c says THREAD_NOFTIFY_SWTICH
instead of THREAD_NOTIFY_SWITCH. Correct it.

Signed-off-by: Edmundo Carmona Antoranz <eantoranz at gmail.com>
---
 arch/arm/vfp/vfpmodule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2cb355c1b5b7..4f8c6f583b79 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -140,7 +140,7 @@ static void vfp_thread_copy(struct thread_info *thread)
 /*
  * When this function is called with the following 'cmd's, the following
  * is true while this function is being run:
- *  THREAD_NOFTIFY_SWTICH:
+ *  THREAD_NOTIFY_SWITCH:
  *   - the previously running thread will not be scheduled onto another CPU.
  *   - the next thread to be run (v) will not be running on another CPU.
  *   - thread->cpu is the local CPU number
-- 
2.20.1



From u.kleine-koenig at pengutronix.de  Sat Apr 10 19:52:22 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 10 Apr 2021 20:52:22 +0200
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210410185222.4tfpgm2hcka26e6g@pengutronix.de>

Hello,

one more comment:

On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_chip *chip)

all functions but this one start have the common prefix "visconti_pwm_".
I like the concept of a common prefix and so you could rename this
function to visconti_pwm_from_chip or similar.

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/20210410/5718dbec/attachment.sig>

From maz at kernel.org  Sat Apr 10 20:03:53 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 10 Apr 2021 20:03:53 +0100
Subject: [PATCH -next] arm64: vdso: correct definition of macro
 vdso_clocksource_ok
In-Reply-To: <20210410181117.23967-1-eantoranz@gmail.com>
References: <20210410181117.23967-1-eantoranz@gmail.com>
Message-ID: <874kgeezc6.wl-maz@kernel.org>

Hi Edmundo,

On Sat, 10 Apr 2021 19:11:17 +0100,
Edmundo Carmona Antoranz <eantoranz at gmail.com> wrote:
> 
> The macro vdso_clocksource_ok is shadowing a function with the same
> name and so it actually makes no difference to have the macro defined
> or not.

No difference? Have you simply tried removing the macro and witness
the effect? If it made no difference, why have the macro at all then?

Also, run this, for example:

git grep '^\#define' arch/arm64/include/asm/| awk '$2 == $3 { print }'

Are you going to "fix" these too?

Thanks,

	M.

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


From arnd at kernel.org  Sat Apr 10 20:10:47 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sat, 10 Apr 2021 21:10:47 +0200
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <20210410024313.GX2531743@casper.infradead.org>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
Message-ID: <CAK8P3a3uEGaEN-p06vFP+jwbFt3P=Bx4=aRN+kUyB4PcFPxLRg@mail.gmail.com>

On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox <willy at infradead.org> wrote:
> +                       dma_addr_t dma_addr __packed;
>                 };
>                 struct {        /* slab, slob and slub */
>                         union {
>
> but I don't know if GCC is smart enough to realise that dma_addr is now
> on an 8 byte boundary and it can use a normal instruction to access it,
> or whether it'll do something daft like use byte loads to access it.
>
> We could also do:
>
> +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));
>
> and I see pahole, at least sees this correctly:
>
>                 struct {
>                         long unsigned int _page_pool_pad; /*     4     4 */
>                         dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
>                 } __attribute__((__packed__)) __attribute__((__aligned__(4)));
>
> This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> / dma_addr_t.  Advice, please?

I've tried out what gcc would make of this:  https://godbolt.org/z/aTEbxxbG3

struct page {
    short a;
    struct {
        short b;
        long long c __attribute__((packed, aligned(2)));
    } __attribute__((packed));
} __attribute__((aligned(8)));

In this structure, 'c' is clearly aligned to eight bytes, and gcc does
realize that
it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on
struct members with less than 4 byte alignment. However, it also complains
that passing a pointer to 'c' into a function that expects a 'long long' is not
allowed because alignof(c) is only '2' here.

(I used 'short' here because I having a 64-bit member misaligned by four
bytes wouldn't make a difference to the instructions on Arm, or any other
32-bit architecture I can think of, regardless of the ABI requirements).

      Arnd


From sergio.paracuellos at gmail.com  Sat Apr 10 20:23:03 2021
From: sergio.paracuellos at gmail.com (Sergio Paracuellos)
Date: Sat, 10 Apr 2021 21:23:03 +0200
Subject: [PATCH] staging: mt7621-pci: stop using of_pci_range_to_resource
In-Reply-To: <20210410173331.57949-1-ilya.lipnitskiy@gmail.com>
References: <20210410173331.57949-1-ilya.lipnitskiy@gmail.com>
Message-ID: <CAMhs-H_GVj1DnhutUBo=Sdr38A8h9WnaJ7KX_-ge550qbujP7w@mail.gmail.com>

Hi Ilya,

On Sat, Apr 10, 2021 at 7:33 PM Ilya Lipnitskiy
<ilya.lipnitskiy at gmail.com> wrote:
>
> The logic here was already overriding the erroneous IO addresses
> returned from of_pci_range_to_resource, which is the bulk of the logic.
>
> So stop using it altogether and initialize the fields explicitly, as
> done in aeba3731b150 ("powerpc/pci: Fix IO space breakage after
> of_pci_range_to_resource() change").
>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> Cc: Sergio Paracuellos <sergio.paracuellos at gmail.com>
> ---
>  drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)

Looks good to me, thanks! I have also tested this in gnubee pc1
platform with no regressions at all when io bars are assigned:

[   16.378956] mt7621-pci 1e140000.pcie: host bridge /pcie at 1e140000 ranges:
[   16.392405] mt7621-pci 1e140000.pcie:      MEM
0x0060000000..0x006fffffff -> 0x0000000000
[   16.408796] mt7621-pci 1e140000.pcie:       IO
0x001e160000..0x001e16ffff -> 0x0000000000
[   16.425264] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000
(dual port = 1)
[   16.440452] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000
(dual port = 0)
[   16.678713] mt7621-pci 1e140000.pcie: PCIE0 enabled
[   16.688435] mt7621-pci 1e140000.pcie: PCIE1 enabled
[   16.698160] mt7621-pci 1e140000.pcie: PCIE2 enabled
[   16.707886] mt7621-pci 1e140000.pcie: PCI coherence region base:
0x60000000, mask/settings: 0xf0000002
[   16.726623] mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
[   16.739309] pci_bus 0000:00: root bus resource [io  0x1e160000-0x1e16ffff]
[   16.753008] pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
[   16.766709] pci_bus 0000:00: root bus resource [bus 00-ff]
[   16.777649] pci_bus 0000:00: root bus resource [mem
0x60000000-0x6fffffff] (bus address [0x00000000-0x0fffffff])
[   16.797986] pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
[   16.809973] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   16.822467] pci 0000:00:00.0: reg 0x14: initial BAR value 0x00000000 invalid
[   16.836511] pci 0000:00:00.0: reg 0x14: [mem size 0x00010000]
[   16.848048] pci 0000:00:00.0: supports D1
[   16.856051] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
[   16.867943] pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
[   16.879960] pci 0000:00:01.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   16.892454] pci 0000:00:01.0: reg 0x14: initial BAR value 0x00000000 invalid
[   16.906497] pci 0000:00:01.0: reg 0x14: [mem size 0x00010000]
[   16.918040] pci 0000:00:01.0: supports D1
[   16.926031] pci 0000:00:01.0: PME# supported from D0 D1 D3hot
[   16.937903] pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
[   16.949915] pci 0000:00:02.0: reg 0x10: [mem 0x00000000-0x7fffffff]
[   16.962412] pci 0000:00:02.0: reg 0x14: initial BAR value 0x00000000 invalid
[   16.976466] pci 0000:00:02.0: reg 0x14: [mem size 0x00010000]
[   16.987991] pci 0000:00:02.0: supports D1
[   16.995986] pci 0000:00:02.0: PME# supported from D0 D1 D3hot
[   17.008716] pci 0000:00:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   17.024695] pci 0000:00:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   17.040654] pci 0000:00:02.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[   17.056868] pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
[   17.068882] pci 0000:01:00.0: reg 0x10: [io  0x0000-0x0007]
[   17.080003] pci 0000:01:00.0: reg 0x14: [io  0x0000-0x0003]
[   17.091115] pci 0000:01:00.0: reg 0x18: [io  0x0000-0x0007]
[   17.102238] pci 0000:01:00.0: reg 0x1c: [io  0x0000-0x0003]
[   17.113350] pci 0000:01:00.0: reg 0x20: [io  0x0000-0x000f]
[   17.124463] pci 0000:01:00.0: reg 0x24: initial BAR value 0x00000000 invalid
[   17.138508] pci 0000:01:00.0: reg 0x24: [mem size 0x00000200]
[   17.150115] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   17.204594] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[   17.215109] pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
[   17.227257] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
[   17.240785] pci 0000:00:00.0:   bridge window [mem
0x60000000-0x600fffff pref]
[   17.255183] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[   17.268648] pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
[   17.280671] pci 0000:02:00.0: reg 0x10: [io  0x0000-0x0007]
[   17.291785] pci 0000:02:00.0: reg 0x14: [io  0x0000-0x0003]
[   17.302898] pci 0000:02:00.0: reg 0x18: [io  0x0000-0x0007]
[   17.314012] pci 0000:02:00.0: reg 0x1c: [io  0x0000-0x0003]
[   17.325127] pci 0000:02:00.0: reg 0x20: [io  0x0000-0x000f]
[   17.336241] pci 0000:02:00.0: reg 0x24: initial BAR value 0x00000000 invalid
[   17.350279] pci 0000:02:00.0: reg 0x24: [mem size 0x00000200]
[   17.361893] pci 0000:02:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:01.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   17.414591] pci 0000:00:01.0: PCI bridge to [bus 02-ff]
[   17.425063] pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
[   17.437206] pci 0000:00:01.0:   bridge window [mem 0x60000000-0x600fffff]
[   17.450733] pci 0000:00:01.0:   bridge window [mem
0x60000000-0x600fffff pref]
[   17.465130] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[   17.478583] pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
[   17.490604] pci 0000:03:00.0: reg 0x10: [io  0x0000-0x0007]
[   17.501717] pci 0000:03:00.0: reg 0x14: [io  0x0000-0x0003]
[   17.512831] pci 0000:03:00.0: reg 0x18: [io  0x0000-0x0007]
[   17.523945] pci 0000:03:00.0: reg 0x1c: [io  0x0000-0x0003]
[   17.535060] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x000f]
[   17.546174] pci 0000:03:00.0: reg 0x24: initial BAR value 0x00000000 invalid
[   17.560211] pci 0000:03:00.0: reg 0x24: [mem size 0x00000200]
[   17.571825] pci 0000:03:00.0: 2.000 Gb/s available PCIe bandwidth,
limited by 2.5 GT/s PCIe x1 link at 0000:00:02.0 (capable of 4.000
Gb/s with 5.0 GT/s PCIe x1 link)
[   17.624582] pci 0000:00:02.0: PCI bridge to [bus 03-ff]
[   17.635043] pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
[   17.647188] pci 0000:00:02.0:   bridge window [mem 0x60000000-0x600fffff]
[   17.660710] pci 0000:00:02.0:   bridge window [mem
0x60000000-0x600fffff pref]
[   17.675104] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[   17.688358] pci 0000:00:00.0: BAR 0: no space for [mem size 0x80000000]
[   17.701534] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x80000000]
[   17.715406] pci 0000:00:01.0: BAR 0: no space for [mem size 0x80000000]
[   17.728585] pci 0000:00:01.0: BAR 0: failed to assign [mem size 0x80000000]
[   17.742456] pci 0000:00:02.0: BAR 0: no space for [mem size 0x80000000]
[   17.755638] pci 0000:00:02.0: BAR 0: failed to assign [mem size 0x80000000]
[   17.769514] pci 0000:00:00.0: BAR 8: assigned [mem 0x60000000-0x600fffff]
[   17.783039] pci 0000:00:00.0: BAR 9: assigned [mem
0x60100000-0x601fffff pref]
[   17.797429] pci 0000:00:01.0: BAR 8: assigned [mem 0x60200000-0x602fffff]
[   17.810958] pci 0000:00:01.0: BAR 9: assigned [mem
0x60300000-0x603fffff pref]
[   17.825360] pci 0000:00:02.0: BAR 8: assigned [mem 0x60400000-0x604fffff]
[   17.838886] pci 0000:00:02.0: BAR 9: assigned [mem
0x60500000-0x605fffff pref]
[   17.853279] pci 0000:00:00.0: BAR 1: assigned [mem 0x60600000-0x6060ffff]
[   17.866814] pci 0000:00:01.0: BAR 1: assigned [mem 0x60610000-0x6061ffff]
[   17.880346] pci 0000:00:02.0: BAR 1: assigned [mem 0x60620000-0x6062ffff]
[   17.893880] pci 0000:00:00.0: BAR 7: assigned [io  0x1e160000-0x1e160fff]
[   17.907410] pci 0000:00:01.0: BAR 7: assigned [io  0x1e161000-0x1e161fff]
[   17.920935] pci 0000:00:02.0: BAR 7: assigned [io  0x1e162000-0x1e162fff]
[   17.934474] pci 0000:01:00.0: BAR 5: assigned [mem 0x60000000-0x600001ff]
[   17.948008] pci 0000:01:00.0: BAR 4: assigned [io  0x1e160000-0x1e16000f]
[   17.961542] pci 0000:01:00.0: BAR 0: assigned [io  0x1e160010-0x1e160017]
[   17.975072] pci 0000:01:00.0: BAR 2: assigned [io  0x1e160018-0x1e16001f]
[   17.988605] pci 0000:01:00.0: BAR 1: assigned [io  0x1e160020-0x1e160023]
[   18.002138] pci 0000:01:00.0: BAR 3: assigned [io  0x1e160024-0x1e160027]
[   18.015673] pci 0000:00:00.0: PCI bridge to [bus 01]
[   18.025572] pci 0000:00:00.0:   bridge window [io  0x1e160000-0x1e160fff]
[   18.039096] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
[   18.052623] pci 0000:00:00.0:   bridge window [mem
0x60100000-0x601fffff pref]
[   18.067026] pci 0000:02:00.0: BAR 5: assigned [mem 0x60200000-0x602001ff]
[   18.080562] pci 0000:02:00.0: BAR 4: assigned [io  0x1e161000-0x1e16100f]
[   18.094092] pci 0000:02:00.0: BAR 0: assigned [io  0x1e161010-0x1e161017]
[   18.107625] pci 0000:02:00.0: BAR 2: assigned [io  0x1e161018-0x1e16101f]
[   18.121158] pci 0000:02:00.0: BAR 1: assigned [io  0x1e161020-0x1e161023]
[   18.134694] pci 0000:02:00.0: BAR 3: assigned [io  0x1e161024-0x1e161027]
[   18.148225] pci 0000:00:01.0: PCI bridge to [bus 02]
[   18.158117] pci 0000:00:01.0:   bridge window [io  0x1e161000-0x1e161fff]
[   18.171643] pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
[   18.185170] pci 0000:00:01.0:   bridge window [mem
0x60300000-0x603fffff pref]
[   18.199591] pci 0000:03:00.0: BAR 5: assigned [mem 0x60400000-0x604001ff]
[   18.213127] pci 0000:03:00.0: BAR 4: assigned [io  0x1e162000-0x1e16200f]
[   18.226664] pci 0000:03:00.0: BAR 0: assigned [io  0x1e162010-0x1e162017]
[   18.240199] pci 0000:03:00.0: BAR 2: assigned [io  0x1e162018-0x1e16201f]
[   18.253751] pci 0000:03:00.0: BAR 1: assigned [io  0x1e162020-0x1e162023]
[   18.267286] pci 0000:03:00.0: BAR 3: assigned [io  0x1e162024-0x1e162027]
[   18.280814] pci 0000:00:02.0: PCI bridge to [bus 03]
[   18.290713] pci 0000:00:02.0:   bridge window [io  0x1e162000-0x1e162fff]
[   18.304243] pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
[   18.317773] pci 0000:00:02.0:   bridge window [mem
0x60500000-0x605fffff pref]

Reviewed-by: Sergio Paracuellos <sergio.paracuellos at gmail.com>

Best regards,
    Sergio Paracuellos


From gszymaszek at short.pl  Sat Apr 10 20:35:21 2021
From: gszymaszek at short.pl (Grzegorz Szymaszek)
Date: Sat, 10 Apr 2021 21:35:21 +0200
Subject: [PATCH] ARM: dts: stm32: fix stm32mp157c-odyssey card detect pin
Message-ID: <YHH9+Xrn5Quge4Jt@nx64de-df6d00>

The microSD card detect pin is physically connected to the MPU pin PI3.
The Device Tree configuration of the card detect pin was wrong?it was
set to pin PB7 instead. If such configuration was used, the kernel would
hang on ?Waiting for root device? when booting from a microSD card.

Signed-off-by: Grzegorz Szymaszek <gszymaszek at short.pl>
---
 arch/arm/boot/dts/stm32mp157c-odyssey.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stm32mp157c-odyssey.dts b/arch/arm/boot/dts/stm32mp157c-odyssey.dts
index a7ffec8f1516..be1dd5e9e744 100644
--- a/arch/arm/boot/dts/stm32mp157c-odyssey.dts
+++ b/arch/arm/boot/dts/stm32mp157c-odyssey.dts
@@ -64,7 +64,7 @@ &sdmmc1 {
 	pinctrl-0 = <&sdmmc1_b4_pins_a>;
 	pinctrl-1 = <&sdmmc1_b4_od_pins_a>;
 	pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>;
-	cd-gpios = <&gpiob 7 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+	cd-gpios = <&gpioi 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
 	disable-wp;
 	st,neg-edge;
 	bus-width = <4>;
-- 
2.30.2



From eantoranz at gmail.com  Sat Apr 10 20:58:22 2021
From: eantoranz at gmail.com (Edmundo Carmona Antoranz)
Date: Sat, 10 Apr 2021 13:58:22 -0600
Subject: [PATCH -next] arm64: vdso: correct definition of macro
 vdso_clocksource_ok
In-Reply-To: <874kgeezc6.wl-maz@kernel.org>
References: <20210410181117.23967-1-eantoranz@gmail.com>
 <874kgeezc6.wl-maz@kernel.org>
Message-ID: <CAOc6etaqPprFHidXwRy+wNWqDr9FXe2=dDN9H81ODHwXpbX5yA@mail.gmail.com>

On Sat, Apr 10, 2021 at 1:03 PM Marc Zyngier <maz at kernel.org> wrote:
>
> Hi Edmundo,

Sup!

>
>
> No difference? Have you simply tried removing the macro and witness
> the effect? If it made no difference, why have the macro at all then?

Oh, come on! so having the macro defined so that you can do things like

lib/vdso/gettimeofday.c:34:#ifndef vdso_clocksource_ok

counts as "a difference" to you? XD ok ok ... so, I have deleted
"extended linux kernel C preprocessor knowledge" from my linkedin
profile.

I can safely assume that this is a big resounding NACK, right? :-D

>
> Also, run this, for example:
>
> git grep '^\#define' arch/arm64/include/asm/| awk '$2 == $3 { print }'
>
> Are you going to "fix" these too?
>
> Thanks,

Thank you for the lesson, man. Still have a lot of stuff to learn in
front of me.

Pura vida!


From s.shtylyov at omprussia.ru  Sat Apr 10 21:11:59 2021
From: s.shtylyov at omprussia.ru (Sergey Shtylyov)
Date: Sat, 10 Apr 2021 23:11:59 +0300
Subject: [PATCH v2 0/6] Stop calling devm_request_irq() with invalid IRQs in
 the I2C bus drivers
Message-ID: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>

Here are 6 patches against the 'master' branch of Martin Petersen's 'scsi.git' repo.
The affected drivers call platform_get_irq() but largely ignore its result -- they
blithely pass the negative error codes to devm_request_irq() which expects *unsinged*
IRQ #s. Stop doing that by checking what exactly platform_get_irq() returns.

[1/6] i2c: cadence: add IRQ check
[2/6] i2c: emev2: add IRQ check
[3/6] i2c: jz4780: add IRQ check
[4/6] i2c: mlxbf: add IRQ check
[5/6] i2c: rcar: add IRQ check
[6/6] i2c: sh7760: add IRQ check


From s.shtylyov at omprussia.ru  Sat Apr 10 21:14:35 2021
From: s.shtylyov at omprussia.ru (Sergey Shtylyov)
Date: Sat, 10 Apr 2021 23:14:35 +0300
Subject: [PATCH v2 1/6] i2c: cadence: add IRQ check
In-Reply-To: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
References: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
Message-ID: <7166579b-c058-5c45-2f62-d9610d41a00f@omprussia.ru>

The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_irq() (which
takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code.  Stop calling devm_request_irq() with invalid
IRQ #s.

Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
Signed-off-by: Sergey Shtylyov <s.shtylyov at omprussia.ru>

---
Changes in version 2:
- new patch.

 drivers/i2c/busses/i2c-cadence.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux/drivers/i2c/busses/i2c-cadence.c
===================================================================
--- linux.orig/drivers/i2c/busses/i2c-cadence.c
+++ linux/drivers/i2c/busses/i2c-cadence.c
@@ -1200,7 +1200,10 @@ static int cdns_i2c_probe(struct platfor
 	if (IS_ERR(id->membase))
 		return PTR_ERR(id->membase);
 
-	id->irq = platform_get_irq(pdev, 0);
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		return ret;
+	id->irq = ret;
 
 	id->adap.owner = THIS_MODULE;
 	id->adap.dev.of_node = pdev->dev.of_node;


From s.shtylyov at omprussia.ru  Sat Apr 10 21:31:01 2021
From: s.shtylyov at omprussia.ru (Sergey Shtylyov)
Date: Sat, 10 Apr 2021 23:31:01 +0300
Subject: [PATCH v2 0/6] Stop calling devm_request_irq() with invalid IRQs
 in the I2C bus drivers
In-Reply-To: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
References: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
Message-ID: <b27b3e14-d928-f44d-8b67-2d7645009f3c@omprussia.ru>

On 4/10/21 11:11 PM, Sergey Shtylyov wrote:

> Here are 6 patches against the 'master' branch of Martin Petersen's 'scsi.git' repo.
> The affected drivers call platform_get_irq() but largely ignore its result -- they
> blithely pass the negative error codes to devm_request_irq() which expects *unsinged*
> IRQ #s. Stop doing that by checking what exactly platform_get_irq() returns.
> 
> [1/6] i2c: cadence: add IRQ check
> [2/6] i2c: emev2: add IRQ check
> [3/6] i2c: jz4780: add IRQ check
> [4/6] i2c: mlxbf: add IRQ check
> [5/6] i2c: rcar: add IRQ check

   Forgot to mention that the whole v2 patch set grew from this R-Car patch.

> [6/6] i2c: sh7760: add IRQ check

MBR, Sergey


From willy at infradead.org  Sat Apr 10 21:52:44 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Sat, 10 Apr 2021 21:52:44 +0100
Subject: [PATCH 0/1] Fix struct page layout on 32-bit systems
Message-ID: <20210410205246.507048-1-willy@infradead.org>

I'd really appreciate people testing this, particularly on
arm32/mips32/ppc32 systems with a 64-bit dma_addr_t.

Matthew Wilcox (Oracle) (1):
  mm: Fix struct page layout on 32-bit systems

 include/linux/mm_types.h | 38 ++++++++++++++++++++++++++------------
 1 file changed, 26 insertions(+), 12 deletions(-)

-- 
2.30.2



From willy at infradead.org  Sat Apr 10 21:52:45 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Sat, 10 Apr 2021 21:52:45 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210410205246.507048-1-willy@infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
Message-ID: <20210410205246.507048-2-willy@infradead.org>

32-bit architectures which expect 8-byte alignment for 8-byte integers
and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
page inadvertently expanded in 2019.  When the dma_addr_t was added,
it forced the alignment of the union to 8 bytes, which inserted a 4 byte
gap between 'flags' and the union.

We could fix this by telling the compiler to use a smaller alignment
for the dma_addr, but that seems a little fragile.  Instead, move the
'flags' into the union.  That causes dma_addr to shift into the same
bits as 'mapping', so it would have to be cleared on free.  To avoid
this, insert three words of padding and use the same bits as ->index
and ->private, neither of which have to be cleared on free.

Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 include/linux/mm_types.h | 38 ++++++++++++++++++++++++++------------
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..45c563e9b50e 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -68,16 +68,22 @@ struct mem_cgroup;
 #endif
 
 struct page {
-	unsigned long flags;		/* Atomic flags, some possibly
-					 * updated asynchronously */
 	/*
-	 * Five words (20/40 bytes) are available in this union.
-	 * WARNING: bit 0 of the first word is used for PageTail(). That
-	 * means the other users of this union MUST NOT use the bit to
+	 * This union is six words (24 / 48 bytes) in size.
+	 * The first word is reserved for atomic flags, often updated
+	 * asynchronously.  Use the PageFoo() macros to access it.  Some
+	 * of the flags can be reused for your own purposes, but the
+	 * word as a whole often contains other information and overwriting
+	 * it will cause functions like page_zone() and page_node() to stop
+	 * working correctly.
+	 *
+	 * Bit 0 of the second word is used for PageTail(). That
+	 * means the other users of this union MUST leave the bit zero to
 	 * avoid collision and false-positive PageTail().
 	 */
 	union {
 		struct {	/* Page cache and anonymous pages */
+			unsigned long flags;
 			/**
 			 * @lru: Pageout list, eg. active_list protected by
 			 * lruvec->lru_lock.  Sometimes used as a generic list
@@ -96,13 +102,14 @@ struct page {
 			unsigned long private;
 		};
 		struct {	/* page_pool used by netstack */
-			/**
-			 * @dma_addr: might require a 64-bit value even on
-			 * 32-bit architectures.
-			 */
-			dma_addr_t dma_addr;
+			unsigned long _pp_flags;
+			unsigned long pp_magic;
+			unsigned long xmi;
+			unsigned long _pp_mapping_pad;
+			dma_addr_t dma_addr;	/* might be one or two words */
 		};
 		struct {	/* slab, slob and slub */
+			unsigned long _slab_flags;
 			union {
 				struct list_head slab_list;
 				struct {	/* Partial pages */
@@ -130,6 +137,7 @@ struct page {
 			};
 		};
 		struct {	/* Tail pages of compound page */
+			unsigned long _t1_flags;
 			unsigned long compound_head;	/* Bit zero is set */
 
 			/* First tail page only */
@@ -139,12 +147,14 @@ struct page {
 			unsigned int compound_nr; /* 1 << compound_order */
 		};
 		struct {	/* Second tail page of compound page */
+			unsigned long _t2_flags;
 			unsigned long _compound_pad_1;	/* compound_head */
 			atomic_t hpage_pinned_refcount;
 			/* For both global and memcg */
 			struct list_head deferred_list;
 		};
 		struct {	/* Page table pages */
+			unsigned long _pt_flags;
 			unsigned long _pt_pad_1;	/* compound_head */
 			pgtable_t pmd_huge_pte; /* protected by page->ptl */
 			unsigned long _pt_pad_2;	/* mapping */
@@ -159,6 +169,7 @@ struct page {
 #endif
 		};
 		struct {	/* ZONE_DEVICE pages */
+			unsigned long _zd_flags;
 			/** @pgmap: Points to the hosting device page map. */
 			struct dev_pagemap *pgmap;
 			void *zone_device_data;
@@ -174,8 +185,11 @@ struct page {
 			 */
 		};
 
-		/** @rcu_head: You can use this to free a page by RCU. */
-		struct rcu_head rcu_head;
+		struct {
+			unsigned long _rcu_flags;
+			/** @rcu_head: You can use this to free a page by RCU. */
+			struct rcu_head rcu_head;
+		};
 	};
 
 	union {		/* This union is 4 bytes in size. */
-- 
2.30.2



From s.shtylyov at omprussia.ru  Sat Apr 10 21:57:56 2021
From: s.shtylyov at omprussia.ru (Sergey Shtylyov)
Date: Sat, 10 Apr 2021 23:57:56 +0300
Subject: [PATCH v2 0/6] Stop calling devm_request_irq() with invalid IRQs
 in the I2C bus drivers
In-Reply-To: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
References: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
Message-ID: <ca43d9f0-28c7-d23e-402e-bb2b0113517c@omprussia.ru>

On 4/10/21 11:11 PM, Sergey Shtylyov wrote:

> Here are 6 patches against the 'master' branch of Martin Petersen's 'scsi.git' repo.

   Oops, left that line unfinished. Wolfram's 'linux.git' repo, of course... :-)

> The affected drivers call platform_get_irq() but largely ignore its result -- they
> blithely pass the negative error codes to devm_request_irq() which expects *unsinged*
> IRQ #s. Stop doing that by checking what exactly platform_get_irq() returns.

[...]

MNR, Sergey


From maz at kernel.org  Sat Apr 10 23:18:40 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 10 Apr 2021 23:18:40 +0100
Subject: [PATCH -next] arm64: vdso: correct definition of macro
 vdso_clocksource_ok
In-Reply-To: <CAOc6etaqPprFHidXwRy+wNWqDr9FXe2=dDN9H81ODHwXpbX5yA@mail.gmail.com>
References: <20210410181117.23967-1-eantoranz@gmail.com>
 <874kgeezc6.wl-maz@kernel.org>
 <CAOc6etaqPprFHidXwRy+wNWqDr9FXe2=dDN9H81ODHwXpbX5yA@mail.gmail.com>
Message-ID: <8735vxg4vz.wl-maz@kernel.org>

On Sat, 10 Apr 2021 20:58:22 +0100,
Edmundo Carmona Antoranz <eantoranz at gmail.com> wrote:
> 
> On Sat, Apr 10, 2021 at 1:03 PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > Hi Edmundo,
> 
> Sup!
> 
> >
> >
> > No difference? Have you simply tried removing the macro and witness
> > the effect? If it made no difference, why have the macro at all then?
> 
> Oh, come on! so having the macro defined so that you can do things like
> 
> lib/vdso/gettimeofday.c:34:#ifndef vdso_clocksource_ok
> 
> counts as "a difference" to you? XD ok ok ... so, I have deleted
> "extended linux kernel C preprocessor knowledge" from my linkedin
> profile.

If you want to look cool on Linkedin, the C preprocessor really is the
wrong thing to boast about. Consider adding things like iron oxide,
which will definitely boost your visibility.

> I can safely assume that this is a big resounding NACK, right? :-D

Not necessarily a NAK, because I don't like doing that. But I find
this an unnecessarily change and a fairly pointless divergence from an
established practice. Others may agree with you.

But it was worth pointing out that "it actually makes no difference to
have the macro defined or not" wasn't quite the right thing to put in
the commit message.

>
> >
> > Also, run this, for example:
> >
> > git grep '^\#define' arch/arm64/include/asm/| awk '$2 == $3 { print }'
> >
> > Are you going to "fix" these too?
> >
> > Thanks,
> 
> Thank you for the lesson, man. Still have a lot of stuff to learn in
> front of me.

We all do.

	M.

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


From vee.khee.wong at linux.intel.com  Sun Apr 11 03:40:28 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Sun, 11 Apr 2021 10:40:28 +0800
Subject: [PATCH net-next v3 1/1] net: stmmac: Add support for external trigger
 timestamping
Message-ID: <20210411024028.14586-1-vee.khee.wong@linux.intel.com>

From: Tan Tee Min <tee.min.tan at intel.com>

The Synopsis MAC controller supports auxiliary snapshot feature that
allows user to store a snapshot of the system time based on an external
event.

This patch add supports to the above mentioned feature. Users will be
able to triggered capturing the time snapshot from user-space using
application such as testptp or any other applications that uses the
PTP_EXTTS_REQUEST ioctl request.

Cc: Richard Cochran <richardcochran at gmail.com>
Signed-off-by: Tan Tee Min <tee.min.tan at intel.com>
Co-developed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
v2 -> v3:
  - Flip ext_snapshot_en condition check for early return.
v1 -> v2:
  - Changed from pr_info() to netdev_dbg().

 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 11 +++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  5 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  3 ++
 .../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 41 +++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 +
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  | 39 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  1 +
 include/linux/stmmac.h                        |  2 +
 8 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 60566598d644..60e17fd24aba 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -296,6 +296,13 @@ static int intel_crosststamp(ktime_t *device,
 
 	intel_priv = priv->plat->bsp_priv;
 
+	/* Both internal crosstimestamping and external triggered event
+	 * timestamping cannot be run concurrently.
+	 */
+	if (priv->plat->ext_snapshot_en)
+		return -EBUSY;
+
+	mutex_lock(&priv->aux_ts_lock);
 	/* Enable Internal snapshot trigger */
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value &= ~PTP_ACR_MASK;
@@ -321,6 +328,7 @@ static int intel_crosststamp(ktime_t *device,
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value |= PTP_ACR_ATSFC;
 	writel(acr_value, ptpaddr + PTP_ACR);
+	mutex_unlock(&priv->aux_ts_lock);
 
 	/* Trigger Internal snapshot signal
 	 * Create a rising edge by just toggle the GPO1 to low
@@ -355,6 +363,8 @@ static int intel_crosststamp(ktime_t *device,
 		*system = convert_art_to_tsc(art_time);
 	}
 
+	/* Release the mutex */
+	mutex_unlock(&priv->aux_ts_lock);
 	system->cycles *= intel_priv->crossts_adj;
 
 	return 0;
@@ -520,6 +530,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
 
 	plat->int_snapshot_num = AUX_SNAPSHOT1;
+	plat->ext_snapshot_num = AUX_SNAPSHOT0;
 
 	plat->has_crossts = true;
 	plat->crosststamp = intel_crosststamp;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2b5022ef1e52..2cc91759b91f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -504,6 +504,8 @@ struct stmmac_ops {
 #define stmmac_fpe_irq_status(__priv, __args...) \
 	stmmac_do_callback(__priv, mac, fpe_irq_status, __args)
 
+struct stmmac_priv;
+
 /* PTP and HW Timer helpers */
 struct stmmac_hwtimestamp {
 	void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
@@ -515,6 +517,7 @@ struct stmmac_hwtimestamp {
 			       int add_sub, int gmac4);
 	void (*get_systime) (void __iomem *ioaddr, u64 *systime);
 	void (*get_ptptime)(void __iomem *ioaddr, u64 *ptp_time);
+	void (*timestamp_interrupt)(struct stmmac_priv *priv);
 };
 
 #define stmmac_config_hw_tstamping(__priv, __args...) \
@@ -531,6 +534,8 @@ struct stmmac_hwtimestamp {
 	stmmac_do_void_callback(__priv, ptp, get_systime, __args)
 #define stmmac_get_ptptime(__priv, __args...) \
 	stmmac_do_void_callback(__priv, ptp, get_ptptime, __args)
+#define stmmac_timestamp_interrupt(__priv, __args...) \
+	stmmac_do_void_callback(__priv, ptp, timestamp_interrupt, __args)
 
 /* Helpers to manage the descriptors for chain and ring modes */
 struct stmmac_mode_ops {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..abadcd8cdc41 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -239,6 +239,9 @@ struct stmmac_priv {
 	int use_riwt;
 	int irq_wake;
 	spinlock_t ptp_lock;
+	/* Mutex lock for Auxiliary Snapshots */
+	struct mutex aux_ts_lock;
+
 	void __iomem *mmcaddr;
 	void __iomem *ptpaddr;
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 113c51bcc0b5..f6bdd3cde824 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -12,8 +12,11 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/delay.h>
+#include <linux/ptp_clock_kernel.h>
 #include "common.h"
 #include "stmmac_ptp.h"
+#include "dwmac4.h"
+#include "stmmac.h"
 
 static void config_hw_tstamping(void __iomem *ioaddr, u32 data)
 {
@@ -163,6 +166,43 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
 	*ptp_time = ns;
 }
 
+static void timestamp_interrupt(struct stmmac_priv *priv)
+{
+	struct ptp_clock_event event;
+	unsigned long flags;
+	u32 num_snapshot;
+	u32 ts_status;
+	u32 tsync_int;
+	u64 ptp_time;
+	int i;
+
+	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
+
+	if (!tsync_int)
+		return;
+
+	/* Read timestamp status to clear interrupt from either external
+	 * timestamp or start/end of PPS.
+	 */
+	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
+
+	if (!priv->plat->ext_snapshot_en)
+		return;
+
+	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
+		       GMAC_TIMESTAMP_ATSNS_SHIFT;
+
+	for (i = 0; i < num_snapshot; i++) {
+		spin_lock_irqsave(&priv->ptp_lock, flags);
+		get_ptptime(priv->ptpaddr, &ptp_time);
+		spin_unlock_irqrestore(&priv->ptp_lock, flags);
+		event.type = PTP_CLOCK_EXTTS;
+		event.index = 0;
+		event.timestamp = ptp_time;
+		ptp_clock_event(priv->ptp_clock, &event);
+	}
+}
+
 const struct stmmac_hwtimestamp stmmac_ptp = {
 	.config_hw_tstamping = config_hw_tstamping,
 	.init_systime = init_systime,
@@ -171,4 +211,5 @@ const struct stmmac_hwtimestamp stmmac_ptp = {
 	.adjust_systime = adjust_systime,
 	.get_systime = get_systime,
 	.get_ptptime = get_ptptime,
+	.timestamp_interrupt = timestamp_interrupt,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 77285646c5fc..9e57bc3d00a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4989,6 +4989,8 @@ static void stmmac_common_interrupt(struct stmmac_priv *priv)
 			else
 				netif_carrier_off(priv->dev);
 		}
+
+		stmmac_timestamp_interrupt(priv, priv);
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index b164ae22e35f..d668c33a0746 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -135,9 +135,13 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 {
 	struct stmmac_priv *priv =
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
+	void __iomem *ptpaddr = priv->ptpaddr;
+	void __iomem *ioaddr = priv->hw->pcsr;
 	struct stmmac_pps_cfg *cfg;
 	int ret = -EOPNOTSUPP;
 	unsigned long flags;
+	u32 intr_value;
+	u32 acr_value;
 
 	switch (rq->type) {
 	case PTP_CLK_REQ_PEROUT:
@@ -159,6 +163,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 					     priv->systime_flags);
 		spin_unlock_irqrestore(&priv->ptp_lock, flags);
 		break;
+	case PTP_CLK_REQ_EXTTS:
+		priv->plat->ext_snapshot_en = on;
+		mutex_lock(&priv->aux_ts_lock);
+		acr_value = readl(ptpaddr + PTP_ACR);
+		acr_value &= ~PTP_ACR_MASK;
+		if (on) {
+			/* Enable External snapshot trigger */
+			acr_value |= priv->plat->ext_snapshot_num;
+			acr_value |= PTP_ACR_ATSFC;
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d enabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Enable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value |= GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+
+		} else {
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d disabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Disable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value &= ~GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+		}
+		writel(acr_value, ptpaddr + PTP_ACR);
+		mutex_unlock(&priv->aux_ts_lock);
+		ret = 0;
+		break;
+
 	default:
 		break;
 	}
@@ -202,7 +237,7 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
 	.name = "stmmac ptp",
 	.max_adj = 62500000,
 	.n_alarm = 0,
-	.n_ext_ts = 0,
+	.n_ext_ts = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_per_out = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_pins = 0,
 	.pps = 0,
@@ -237,8 +272,10 @@ void stmmac_ptp_register(struct stmmac_priv *priv)
 		stmmac_ptp_clock_ops.max_adj = priv->plat->ptp_max_adj;
 
 	stmmac_ptp_clock_ops.n_per_out = priv->dma_cap.pps_out_num;
+	stmmac_ptp_clock_ops.n_ext_ts = priv->dma_cap.aux_snapshot_n;
 
 	spin_lock_init(&priv->ptp_lock);
+	mutex_init(&priv->aux_ts_lock);
 	priv->ptp_clock_ops = stmmac_ptp_clock_ops;
 
 	priv->ptp_clock = ptp_clock_register(&priv->ptp_clock_ops,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index f88727ce4d30..53172a439810 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -73,6 +73,7 @@
 #define	PTP_ACR_ATSEN1		BIT(5)	/* Auxiliary Snapshot 1 Enable */
 #define	PTP_ACR_ATSEN2		BIT(6)	/* Auxiliary Snapshot 2 Enable */
 #define	PTP_ACR_ATSEN3		BIT(7)	/* Auxiliary Snapshot 3 Enable */
+#define	PTP_ACR_ATSEN_SHIFT	5	/* Auxiliary Snapshot shift */
 #define	PTP_ACR_MASK		GENMASK(7, 4)	/* Aux Snapshot Mask */
 #define	PMC_ART_VALUE0		0x01	/* PMC_ART[15:0] timer value */
 #define	PMC_ART_VALUE1		0x02	/* PMC_ART[31:16] timer value */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..97edb31d6310 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -238,6 +238,8 @@ struct plat_stmmacenet_data {
 	struct pci_dev *pdev;
 	bool has_crossts;
 	int int_snapshot_num;
+	int ext_snapshot_num;
+	bool ext_snapshot_en;
 	bool multi_msi_en;
 	int msi_mac_vec;
 	int msi_wol_vec;
-- 
2.25.1



From maz at kernel.org  Sun Apr 11 09:47:15 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 11 Apr 2021 09:47:15 +0100
Subject: [PATCH 0/2] KVM: arm64: Hide SPE from guests
In-Reply-To: <20210409152154.198566-1-alexandru.elisei@arm.com>
References: <20210409152154.198566-1-alexandru.elisei@arm.com>
Message-ID: <161813082031.3091906.14413697257092481825.b4-ty@kernel.org>

On Fri, 9 Apr 2021 16:21:52 +0100, Alexandru Elisei wrote:
> This was part of the KVM SPE series that I posted some time ago [1]. The
> series didn't get too much attention, so I've decided to send this
> fix/cleanup/improvement separately, to make it easier to review.
> 
> I've split the original patch into two because it makes more sense to me
> this way, but I'm not opposed to squashing the series back into a single
> patch if that is preferred.
> 
> [...]

Applied to kvm-arm64/debug-5.13, thanks!

[1/2] KVM: arm64: Don't print warning when trapping SPE registers
      commit: 13611bc80d3da162aaf32b01ceffc804e027d406
[2/2] KVM: arm64: Don't advertise FEAT_SPE to guests
      commit: 96f4f6809beec1bb2338e1aeac408e6a733f8135

Cheers,

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




From zhiyong.tao at mediatek.com  Sun Apr 11 10:26:55 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Sun, 11 Apr 2021 17:26:55 +0800
Subject: [PATCH v3 1/5] dt-bindings: pinctrl: mt8195: add pinctrl file and
 binding document
In-Reply-To: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
References: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
Message-ID: <20210411092659.22838-2-zhiyong.tao@mediatek.com>

1. This patch adds pinctrl file for mt8195.
2. This patch adds mt8195 compatible node in binding document.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 .../bindings/pinctrl/pinctrl-mt8195.yaml      | 152 +++
 include/dt-bindings/pinctrl/mt8195-pinfunc.h  | 962 ++++++++++++++++++
 2 files changed, 1114 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
 create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
new file mode 100644
index 000000000000..b4b4bfa701ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8195.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8195 Pin Controller
+
+maintainers:
+  - Sean Wang <sean.wang at mediatek.com>
+
+description: |
+  The Mediatek's Pin controller is used to control SoC pins.
+
+properties:
+  compatible:
+    const: mediatek,mt8195-pinctrl
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    description: |
+      Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+      the amount of cells must be specified as 2. See the below
+      mentioned gpio binding representation for description of particular cells.
+    const: 2
+
+  gpio-ranges:
+    description: gpio valid number range.
+    maxItems: 1
+
+  reg:
+    description: |
+      Physical address base for gpio base registers. There are 8 GPIO
+      physical address base in mt8195.
+    maxItems: 8
+
+  reg-names:
+    description: |
+      Gpio base register names.
+    maxItems: 8
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+    const: 2
+
+  interrupts:
+    description: The interrupt outputs to sysirq.
+    maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+  '-pins$':
+    type: object
+    description: |
+      A pinctrl node should contain at least one subnodes representing the
+      pinctrl groups available on the machine. Each subnode will list the
+      pins it needs, and how they should be configured, with regard to muxer
+      configuration, pullups, drive strength, input enable/disable and
+      input schmitt.
+      An example of using macro:
+      pincontroller {
+        /* GPIO0 set as multifunction GPIO0 */
+        gpio_pin {
+          pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+        };
+        /* GPIO8 set as multifunction SDA0 */
+        i2c0_pin {
+          pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+        };
+      };
+    $ref: "pinmux-node.yaml"
+
+    properties:
+      pinmux:
+        description: |
+          Integer array, represents gpio pin number and mux setting.
+          Supported pin number and mux varies for different SoCs, and are defined
+          as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+      drive-strength:
+        description: |
+          It can support some arguments which is from 0 to 7. It can only support
+          2/4/6/8/10/12/14/16mA in mt8195.
+        enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+      bias-pull-down: true
+
+      bias-pull-up: true
+
+      bias-disable: true
+
+      output-high: true
+
+      output-low: true
+
+      input-enable: true
+
+      input-disable: true
+
+      input-schmitt-enable: true
+
+      input-schmitt-disable: true
+
+    required:
+      - pinmux
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - interrupt-controller
+  - '#interrupt-cells'
+  - gpio-controller
+  - '#gpio-cells'
+  - gpio-ranges
+
+additionalProperties: false
+
+examples:
+  - |
+            #include <dt-bindings/pinctrl/mt8195-pinfunc.h>
+            #include <dt-bindings/interrupt-controller/arm-gic.h>
+            pio: pinctrl at 10005000 {
+                    compatible = "mediatek,mt8195-pinctrl";
+                    reg = <0x10005000 0x1000>,
+                          <0x11d10000 0x1000>,
+                          <0x11d30000 0x1000>,
+                          <0x11d40000 0x1000>,
+                          <0x11e20000 0x1000>,
+                          <0x11e20000 0x1000>,
+                          <0x11eb0000 0x1000>,
+                          <0x11f40000 0x1000>,
+                          <0x1000b000 0x1000>;
+                    reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
+                          "iocfg_br", "iocfg_lm", "iocfg_rb",
+                          "iocfg_tl", "eint";
+                    gpio-controller;
+                    #gpio-cells = <2>;
+                    gpio-ranges = <&pio 0 0 144>;
+                    interrupt-controller;
+                    interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+                    #interrupt-cells = <2>;
+
+                    pio-pins {
+                      pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+                      output-low;
+                    };
+            };
diff --git a/include/dt-bindings/pinctrl/mt8195-pinfunc.h b/include/dt-bindings/pinctrl/mt8195-pinfunc.h
new file mode 100644
index 000000000000..666331bb9b40
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt8195-pinfunc.h
@@ -0,0 +1,962 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Zhiyong Tao <zhiyong.tao at mediatek.com>
+ */
+
+#ifndef __MT8195_PINFUNC_H
+#define __MT8195_PINFUNC_H
+
+#include "mt65xx.h"
+
+#define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define PINMUX_GPIO0__FUNC_TP_GPIO0_AO (MTK_PIN_NO(0) | 1)
+#define PINMUX_GPIO0__FUNC_MSDC2_CMD (MTK_PIN_NO(0) | 2)
+#define PINMUX_GPIO0__FUNC_TDMIN_MCK (MTK_PIN_NO(0) | 3)
+#define PINMUX_GPIO0__FUNC_CLKM0 (MTK_PIN_NO(0) | 4)
+#define PINMUX_GPIO0__FUNC_PERSTN_1 (MTK_PIN_NO(0) | 5)
+#define PINMUX_GPIO0__FUNC_IDDIG_1P (MTK_PIN_NO(0) | 6)
+#define PINMUX_GPIO0__FUNC_DMIC4_CLK (MTK_PIN_NO(0) | 7)
+
+#define PINMUX_GPIO1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define PINMUX_GPIO1__FUNC_TP_GPIO1_AO (MTK_PIN_NO(1) | 1)
+#define PINMUX_GPIO1__FUNC_MSDC2_CLK (MTK_PIN_NO(1) | 2)
+#define PINMUX_GPIO1__FUNC_TDMIN_DI (MTK_PIN_NO(1) | 3)
+#define PINMUX_GPIO1__FUNC_CLKM1 (MTK_PIN_NO(1) | 4)
+#define PINMUX_GPIO1__FUNC_CLKREQN_1 (MTK_PIN_NO(1) | 5)
+#define PINMUX_GPIO1__FUNC_USB_DRVVBUS_1P (MTK_PIN_NO(1) | 6)
+#define PINMUX_GPIO1__FUNC_DMIC4_DAT (MTK_PIN_NO(1) | 7)
+
+#define PINMUX_GPIO2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define PINMUX_GPIO2__FUNC_TP_GPIO2_AO (MTK_PIN_NO(2) | 1)
+#define PINMUX_GPIO2__FUNC_MSDC2_DAT3 (MTK_PIN_NO(2) | 2)
+#define PINMUX_GPIO2__FUNC_TDMIN_LRCK (MTK_PIN_NO(2) | 3)
+#define PINMUX_GPIO2__FUNC_CLKM2 (MTK_PIN_NO(2) | 4)
+#define PINMUX_GPIO2__FUNC_WAKEN_1 (MTK_PIN_NO(2) | 5)
+#define PINMUX_GPIO2__FUNC_DMIC2_CLK (MTK_PIN_NO(2) | 7)
+
+#define PINMUX_GPIO3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define PINMUX_GPIO3__FUNC_TP_GPIO3_AO (MTK_PIN_NO(3) | 1)
+#define PINMUX_GPIO3__FUNC_MSDC2_DAT0 (MTK_PIN_NO(3) | 2)
+#define PINMUX_GPIO3__FUNC_TDMIN_BCK (MTK_PIN_NO(3) | 3)
+#define PINMUX_GPIO3__FUNC_CLKM3 (MTK_PIN_NO(3) | 4)
+#define PINMUX_GPIO3__FUNC_DMIC2_DAT (MTK_PIN_NO(3) | 7)
+
+#define PINMUX_GPIO4__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define PINMUX_GPIO4__FUNC_TP_GPIO4_AO (MTK_PIN_NO(4) | 1)
+#define PINMUX_GPIO4__FUNC_MSDC2_DAT2 (MTK_PIN_NO(4) | 2)
+#define PINMUX_GPIO4__FUNC_SPDIF_IN1 (MTK_PIN_NO(4) | 3)
+#define PINMUX_GPIO4__FUNC_UTXD3 (MTK_PIN_NO(4) | 4)
+#define PINMUX_GPIO4__FUNC_SDA2 (MTK_PIN_NO(4) | 5)
+#define PINMUX_GPIO4__FUNC_IDDIG_2P (MTK_PIN_NO(4) | 7)
+
+#define PINMUX_GPIO5__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define PINMUX_GPIO5__FUNC_TP_GPIO5_AO (MTK_PIN_NO(5) | 1)
+#define PINMUX_GPIO5__FUNC_MSDC2_DAT1 (MTK_PIN_NO(5) | 2)
+#define PINMUX_GPIO5__FUNC_SPDIF_IN0 (MTK_PIN_NO(5) | 3)
+#define PINMUX_GPIO5__FUNC_URXD3 (MTK_PIN_NO(5) | 4)
+#define PINMUX_GPIO5__FUNC_SCL2 (MTK_PIN_NO(5) | 5)
+#define PINMUX_GPIO5__FUNC_USB_DRVVBUS_2P (MTK_PIN_NO(5) | 7)
+
+#define PINMUX_GPIO6__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define PINMUX_GPIO6__FUNC_TP_GPIO6_AO (MTK_PIN_NO(6) | 1)
+#define PINMUX_GPIO6__FUNC_DP_TX_HPD (MTK_PIN_NO(6) | 2)
+#define PINMUX_GPIO6__FUNC_I2SO1_D4 (MTK_PIN_NO(6) | 3)
+#define PINMUX_GPIO6__FUNC_UTXD4 (MTK_PIN_NO(6) | 4)
+#define PINMUX_GPIO6__FUNC_CMVREF3 (MTK_PIN_NO(6) | 5)
+#define PINMUX_GPIO6__FUNC_DMIC3_CLK (MTK_PIN_NO(6) | 7)
+
+#define PINMUX_GPIO7__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define PINMUX_GPIO7__FUNC_TP_GPIO7_AO (MTK_PIN_NO(7) | 1)
+#define PINMUX_GPIO7__FUNC_EDP_TX_HPD (MTK_PIN_NO(7) | 2)
+#define PINMUX_GPIO7__FUNC_I2SO1_D5 (MTK_PIN_NO(7) | 3)
+#define PINMUX_GPIO7__FUNC_URXD4 (MTK_PIN_NO(7) | 4)
+#define PINMUX_GPIO7__FUNC_CMVREF4 (MTK_PIN_NO(7) | 5)
+#define PINMUX_GPIO7__FUNC_DMIC3_DAT (MTK_PIN_NO(7) | 7)
+
+#define PINMUX_GPIO8__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define PINMUX_GPIO8__FUNC_SDA0 (MTK_PIN_NO(8) | 1)
+#define PINMUX_GPIO8__FUNC_PWM_0 (MTK_PIN_NO(8) | 2)
+#define PINMUX_GPIO8__FUNC_SPDIF_OUT (MTK_PIN_NO(8) | 4)
+#define PINMUX_GPIO8__FUNC_LVTS_FOUT (MTK_PIN_NO(8) | 6)
+#define PINMUX_GPIO8__FUNC_DBG_MON_A0 (MTK_PIN_NO(8) | 7)
+
+#define PINMUX_GPIO9__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define PINMUX_GPIO9__FUNC_SCL0 (MTK_PIN_NO(9) | 1)
+#define PINMUX_GPIO9__FUNC_PWM_1 (MTK_PIN_NO(9) | 2)
+#define PINMUX_GPIO9__FUNC_IR_IN (MTK_PIN_NO(9) | 4)
+#define PINMUX_GPIO9__FUNC_LVTS_SDO (MTK_PIN_NO(9) | 6)
+#define PINMUX_GPIO9__FUNC_DBG_MON_A1 (MTK_PIN_NO(9) | 7)
+
+#define PINMUX_GPIO10__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define PINMUX_GPIO10__FUNC_SDA1 (MTK_PIN_NO(10) | 1)
+#define PINMUX_GPIO10__FUNC_PWM_2 (MTK_PIN_NO(10) | 2)
+#define PINMUX_GPIO10__FUNC_ADSP_URXD0 (MTK_PIN_NO(10) | 3)
+#define PINMUX_GPIO10__FUNC_SPDIF_IN1 (MTK_PIN_NO(10) | 4)
+#define PINMUX_GPIO10__FUNC_LVTS_SCF (MTK_PIN_NO(10) | 6)
+#define PINMUX_GPIO10__FUNC_DBG_MON_A2 (MTK_PIN_NO(10) | 7)
+
+#define PINMUX_GPIO11__FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define PINMUX_GPIO11__FUNC_SCL1 (MTK_PIN_NO(11) | 1)
+#define PINMUX_GPIO11__FUNC_PWM_3 (MTK_PIN_NO(11) | 2)
+#define PINMUX_GPIO11__FUNC_ADSP_UTXD0 (MTK_PIN_NO(11) | 3)
+#define PINMUX_GPIO11__FUNC_SPDIF_IN0 (MTK_PIN_NO(11) | 4)
+#define PINMUX_GPIO11__FUNC_LVTS_SCK (MTK_PIN_NO(11) | 6)
+#define PINMUX_GPIO11__FUNC_DBG_MON_A3 (MTK_PIN_NO(11) | 7)
+
+#define PINMUX_GPIO12__FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define PINMUX_GPIO12__FUNC_SDA2 (MTK_PIN_NO(12) | 1)
+#define PINMUX_GPIO12__FUNC_DMIC3_DAT_R (MTK_PIN_NO(12) | 2)
+#define PINMUX_GPIO12__FUNC_I2SO1_D6 (MTK_PIN_NO(12) | 3)
+#define PINMUX_GPIO12__FUNC_LVTS_SDI (MTK_PIN_NO(12) | 6)
+#define PINMUX_GPIO12__FUNC_DBG_MON_A4 (MTK_PIN_NO(12) | 7)
+
+#define PINMUX_GPIO13__FUNC_GPIO13 (MTK_PIN_NO(13) | 0)
+#define PINMUX_GPIO13__FUNC_SCL2 (MTK_PIN_NO(13) | 1)
+#define PINMUX_GPIO13__FUNC_DMIC4_DAT_R (MTK_PIN_NO(13) | 2)
+#define PINMUX_GPIO13__FUNC_I2SO1_D7 (MTK_PIN_NO(13) | 3)
+#define PINMUX_GPIO13__FUNC_DBG_MON_A5 (MTK_PIN_NO(13) | 7)
+
+#define PINMUX_GPIO14__FUNC_GPIO14 (MTK_PIN_NO(14) | 0)
+#define PINMUX_GPIO14__FUNC_SDA3 (MTK_PIN_NO(14) | 1)
+#define PINMUX_GPIO14__FUNC_DMIC3_DAT (MTK_PIN_NO(14) | 2)
+#define PINMUX_GPIO14__FUNC_TDMIN_MCK (MTK_PIN_NO(14) | 3)
+#define PINMUX_GPIO14__FUNC_DBG_MON_A6 (MTK_PIN_NO(14) | 7)
+
+#define PINMUX_GPIO15__FUNC_GPIO15 (MTK_PIN_NO(15) | 0)
+#define PINMUX_GPIO15__FUNC_SCL3 (MTK_PIN_NO(15) | 1)
+#define PINMUX_GPIO15__FUNC_DMIC3_CLK (MTK_PIN_NO(15) | 2)
+#define PINMUX_GPIO15__FUNC_TDMIN_DI (MTK_PIN_NO(15) | 3)
+#define PINMUX_GPIO15__FUNC_DBG_MON_A7 (MTK_PIN_NO(15) | 7)
+
+#define PINMUX_GPIO16__FUNC_GPIO16 (MTK_PIN_NO(16) | 0)
+#define PINMUX_GPIO16__FUNC_SDA4 (MTK_PIN_NO(16) | 1)
+#define PINMUX_GPIO16__FUNC_DMIC4_DAT (MTK_PIN_NO(16) | 2)
+#define PINMUX_GPIO16__FUNC_TDMIN_LRCK (MTK_PIN_NO(16) | 3)
+#define PINMUX_GPIO16__FUNC_DBG_MON_A8 (MTK_PIN_NO(16) | 7)
+
+#define PINMUX_GPIO17__FUNC_GPIO17 (MTK_PIN_NO(17) | 0)
+#define PINMUX_GPIO17__FUNC_SCL4 (MTK_PIN_NO(17) | 1)
+#define PINMUX_GPIO17__FUNC_DMIC4_CLK (MTK_PIN_NO(17) | 2)
+#define PINMUX_GPIO17__FUNC_TDMIN_BCK (MTK_PIN_NO(17) | 3)
+#define PINMUX_GPIO17__FUNC_DBG_MON_A9 (MTK_PIN_NO(17) | 7)
+
+#define PINMUX_GPIO18__FUNC_GPIO18 (MTK_PIN_NO(18) | 0)
+#define PINMUX_GPIO18__FUNC_DP_TX_HPD (MTK_PIN_NO(18) | 1)
+
+#define PINMUX_GPIO19__FUNC_GPIO19 (MTK_PIN_NO(19) | 0)
+#define PINMUX_GPIO19__FUNC_WAKEN (MTK_PIN_NO(19) | 1)
+#define PINMUX_GPIO19__FUNC_SCP_SDA1 (MTK_PIN_NO(19) | 2)
+#define PINMUX_GPIO19__FUNC_MD32_0_JTAG_TCK (MTK_PIN_NO(19) | 3)
+#define PINMUX_GPIO19__FUNC_ADSP_JTAG0_TCK (MTK_PIN_NO(19) | 4)
+#define PINMUX_GPIO19__FUNC_SDA6 (MTK_PIN_NO(19) | 5)
+
+#define PINMUX_GPIO20__FUNC_GPIO20 (MTK_PIN_NO(20) | 0)
+#define PINMUX_GPIO20__FUNC_PERSTN (MTK_PIN_NO(20) | 1)
+#define PINMUX_GPIO20__FUNC_SCP_SCL1 (MTK_PIN_NO(20) | 2)
+#define PINMUX_GPIO20__FUNC_MD32_0_JTAG_TMS (MTK_PIN_NO(20) | 3)
+#define PINMUX_GPIO20__FUNC_ADSP_JTAG0_TMS (MTK_PIN_NO(20) | 4)
+#define PINMUX_GPIO20__FUNC_SCL6 (MTK_PIN_NO(20) | 5)
+
+#define PINMUX_GPIO21__FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
+#define PINMUX_GPIO21__FUNC_CLKREQN (MTK_PIN_NO(21) | 1)
+#define PINMUX_GPIO21__FUNC_MD32_0_JTAG_TDI (MTK_PIN_NO(21) | 3)
+#define PINMUX_GPIO21__FUNC_ADSP_JTAG0_TDI (MTK_PIN_NO(21) | 4)
+#define PINMUX_GPIO21__FUNC_SCP_SDA1 (MTK_PIN_NO(21) | 5)
+
+#define PINMUX_GPIO22__FUNC_GPIO22 (MTK_PIN_NO(22) | 0)
+#define PINMUX_GPIO22__FUNC_CMMCLK0 (MTK_PIN_NO(22) | 1)
+#define PINMUX_GPIO22__FUNC_PERSTN_1 (MTK_PIN_NO(22) | 2)
+#define PINMUX_GPIO22__FUNC_SCP_SCL1 (MTK_PIN_NO(22) | 5)
+#define PINMUX_GPIO22__FUNC_MD32_0_GPIO0 (MTK_PIN_NO(22) | 7)
+
+#define PINMUX_GPIO23__FUNC_GPIO23 (MTK_PIN_NO(23) | 0)
+#define PINMUX_GPIO23__FUNC_CMMCLK1 (MTK_PIN_NO(23) | 1)
+#define PINMUX_GPIO23__FUNC_CLKREQN_1 (MTK_PIN_NO(23) | 2)
+#define PINMUX_GPIO23__FUNC_SDA4 (MTK_PIN_NO(23) | 3)
+#define PINMUX_GPIO23__FUNC_DMIC1_CLK (MTK_PIN_NO(23) | 4)
+#define PINMUX_GPIO23__FUNC_SCP_SDA0 (MTK_PIN_NO(23) | 5)
+#define PINMUX_GPIO23__FUNC_MD32_0_GPIO1 (MTK_PIN_NO(23) | 7)
+
+#define PINMUX_GPIO24__FUNC_GPIO24 (MTK_PIN_NO(24) | 0)
+#define PINMUX_GPIO24__FUNC_CMMCLK2 (MTK_PIN_NO(24) | 1)
+#define PINMUX_GPIO24__FUNC_WAKEN_1 (MTK_PIN_NO(24) | 2)
+#define PINMUX_GPIO24__FUNC_SCL4 (MTK_PIN_NO(24) | 3)
+#define PINMUX_GPIO24__FUNC_DMIC1_DAT (MTK_PIN_NO(24) | 4)
+#define PINMUX_GPIO24__FUNC_SCP_SCL0 (MTK_PIN_NO(24) | 5)
+#define PINMUX_GPIO24__FUNC_LVTS_26M (MTK_PIN_NO(24) | 6)
+#define PINMUX_GPIO24__FUNC_MD32_0_GPIO2 (MTK_PIN_NO(24) | 7)
+
+#define PINMUX_GPIO25__FUNC_GPIO25 (MTK_PIN_NO(25) | 0)
+#define PINMUX_GPIO25__FUNC_CMMRST (MTK_PIN_NO(25) | 1)
+#define PINMUX_GPIO25__FUNC_CMMCLK3 (MTK_PIN_NO(25) | 2)
+#define PINMUX_GPIO25__FUNC_SPDIF_OUT (MTK_PIN_NO(25) | 3)
+#define PINMUX_GPIO25__FUNC_SDA6 (MTK_PIN_NO(25) | 4)
+#define PINMUX_GPIO25__FUNC_ADSP_JTAG0_TRSTN (MTK_PIN_NO(25) | 5)
+#define PINMUX_GPIO25__FUNC_MD32_0_JTAG_TRST (MTK_PIN_NO(25) | 6)
+
+#define PINMUX_GPIO26__FUNC_GPIO26 (MTK_PIN_NO(26) | 0)
+#define PINMUX_GPIO26__FUNC_CMMPDN (MTK_PIN_NO(26) | 1)
+#define PINMUX_GPIO26__FUNC_CMMCLK4 (MTK_PIN_NO(26) | 2)
+#define PINMUX_GPIO26__FUNC_IR_IN (MTK_PIN_NO(26) | 3)
+#define PINMUX_GPIO26__FUNC_SCL6 (MTK_PIN_NO(26) | 4)
+#define PINMUX_GPIO26__FUNC_ADSP_JTAG0_TDO (MTK_PIN_NO(26) | 5)
+#define PINMUX_GPIO26__FUNC_MD32_0_JTAG_TDO (MTK_PIN_NO(26) | 6)
+
+#define PINMUX_GPIO27__FUNC_GPIO27 (MTK_PIN_NO(27) | 0)
+#define PINMUX_GPIO27__FUNC_HDMIRX20_HTPLG (MTK_PIN_NO(27) | 1)
+#define PINMUX_GPIO27__FUNC_CMFLASH0 (MTK_PIN_NO(27) | 2)
+#define PINMUX_GPIO27__FUNC_MD32_0_TXD (MTK_PIN_NO(27) | 3)
+#define PINMUX_GPIO27__FUNC_TP_UTXD2_AO (MTK_PIN_NO(27) | 4)
+#define PINMUX_GPIO27__FUNC_SCL7 (MTK_PIN_NO(27) | 5)
+#define PINMUX_GPIO27__FUNC_UCTS2 (MTK_PIN_NO(27) | 6)
+#define PINMUX_GPIO27__FUNC_DBG_MON_A18 (MTK_PIN_NO(27) | 7)
+
+#define PINMUX_GPIO28__FUNC_GPIO28 (MTK_PIN_NO(28) | 0)
+#define PINMUX_GPIO28__FUNC_HDMIRX20_PWR5V (MTK_PIN_NO(28) | 1)
+#define PINMUX_GPIO28__FUNC_CMFLASH1 (MTK_PIN_NO(28) | 2)
+#define PINMUX_GPIO28__FUNC_MD32_0_RXD (MTK_PIN_NO(28) | 3)
+#define PINMUX_GPIO28__FUNC_TP_URXD2_AO (MTK_PIN_NO(28) | 4)
+#define PINMUX_GPIO28__FUNC_SDA7 (MTK_PIN_NO(28) | 5)
+#define PINMUX_GPIO28__FUNC_URTS2 (MTK_PIN_NO(28) | 6)
+#define PINMUX_GPIO28__FUNC_DBG_MON_A19 (MTK_PIN_NO(28) | 7)
+
+#define PINMUX_GPIO29__FUNC_GPIO29 (MTK_PIN_NO(29) | 0)
+#define PINMUX_GPIO29__FUNC_HDMIRX20_SCL (MTK_PIN_NO(29) | 1)
+#define PINMUX_GPIO29__FUNC_CMFLASH2 (MTK_PIN_NO(29) | 2)
+#define PINMUX_GPIO29__FUNC_SCL5 (MTK_PIN_NO(29) | 3)
+#define PINMUX_GPIO29__FUNC_TP_URTS2_AO (MTK_PIN_NO(29) | 4)
+#define PINMUX_GPIO29__FUNC_UTXD2 (MTK_PIN_NO(29) | 6)
+#define PINMUX_GPIO29__FUNC_DBG_MON_A20 (MTK_PIN_NO(29) | 7)
+
+#define PINMUX_GPIO30__FUNC_GPIO30 (MTK_PIN_NO(30) | 0)
+#define PINMUX_GPIO30__FUNC_HDMIRX20_SDA (MTK_PIN_NO(30) | 1)
+#define PINMUX_GPIO30__FUNC_CMFLASH3 (MTK_PIN_NO(30) | 2)
+#define PINMUX_GPIO30__FUNC_SDA5 (MTK_PIN_NO(30) | 3)
+#define PINMUX_GPIO30__FUNC_TP_UCTS2_AO (MTK_PIN_NO(30) | 4)
+#define PINMUX_GPIO30__FUNC_URXD2 (MTK_PIN_NO(30) | 6)
+#define PINMUX_GPIO30__FUNC_DBG_MON_A21 (MTK_PIN_NO(30) | 7)
+
+#define PINMUX_GPIO31__FUNC_GPIO31 (MTK_PIN_NO(31) | 0)
+#define PINMUX_GPIO31__FUNC_HDMITX20_PWR5V (MTK_PIN_NO(31) | 1)
+#define PINMUX_GPIO31__FUNC_DMIC1_DAT_R (MTK_PIN_NO(31) | 2)
+#define PINMUX_GPIO31__FUNC_PERSTN (MTK_PIN_NO(31) | 3)
+#define PINMUX_GPIO31__FUNC_DBG_MON_A22 (MTK_PIN_NO(31) | 7)
+
+#define PINMUX_GPIO32__FUNC_GPIO32 (MTK_PIN_NO(32) | 0)
+#define PINMUX_GPIO32__FUNC_HDMITX20_HTPLG (MTK_PIN_NO(32) | 1)
+#define PINMUX_GPIO32__FUNC_CLKREQN (MTK_PIN_NO(32) | 3)
+#define PINMUX_GPIO32__FUNC_DBG_MON_A23 (MTK_PIN_NO(32) | 7)
+
+#define PINMUX_GPIO33__FUNC_GPIO33 (MTK_PIN_NO(33) | 0)
+#define PINMUX_GPIO33__FUNC_HDMITX20_CEC (MTK_PIN_NO(33) | 1)
+#define PINMUX_GPIO33__FUNC_CMVREF0 (MTK_PIN_NO(33) | 2)
+#define PINMUX_GPIO33__FUNC_WAKEN (MTK_PIN_NO(33) | 3)
+
+#define PINMUX_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0)
+#define PINMUX_GPIO34__FUNC_HDMITX20_SCL (MTK_PIN_NO(34) | 1)
+#define PINMUX_GPIO34__FUNC_CMVREF1 (MTK_PIN_NO(34) | 2)
+#define PINMUX_GPIO34__FUNC_SCL7 (MTK_PIN_NO(34) | 3)
+#define PINMUX_GPIO34__FUNC_SCL6 (MTK_PIN_NO(34) | 4)
+#define PINMUX_GPIO34__FUNC_DBG_MON_A24 (MTK_PIN_NO(34) | 7)
+
+#define PINMUX_GPIO35__FUNC_GPIO35 (MTK_PIN_NO(35) | 0)
+#define PINMUX_GPIO35__FUNC_HDMITX20_SDA (MTK_PIN_NO(35) | 1)
+#define PINMUX_GPIO35__FUNC_CMVREF2 (MTK_PIN_NO(35) | 2)
+#define PINMUX_GPIO35__FUNC_SDA7 (MTK_PIN_NO(35) | 3)
+#define PINMUX_GPIO35__FUNC_SDA6 (MTK_PIN_NO(35) | 4)
+#define PINMUX_GPIO35__FUNC_DBG_MON_A25 (MTK_PIN_NO(35) | 7)
+
+#define PINMUX_GPIO36__FUNC_GPIO36 (MTK_PIN_NO(36) | 0)
+#define PINMUX_GPIO36__FUNC_RTC32K_CK (MTK_PIN_NO(36) | 1)
+#define PINMUX_GPIO36__FUNC_DBG_MON_A27 (MTK_PIN_NO(36) | 7)
+
+#define PINMUX_GPIO37__FUNC_GPIO37 (MTK_PIN_NO(37) | 0)
+#define PINMUX_GPIO37__FUNC_WATCHDOG (MTK_PIN_NO(37) | 1)
+#define PINMUX_GPIO37__FUNC_DBG_MON_A28 (MTK_PIN_NO(37) | 7)
+
+#define PINMUX_GPIO38__FUNC_GPIO38 (MTK_PIN_NO(38) | 0)
+#define PINMUX_GPIO38__FUNC_SRCLKENA0 (MTK_PIN_NO(38) | 1)
+#define PINMUX_GPIO38__FUNC_DBG_MON_A29 (MTK_PIN_NO(38) | 7)
+
+#define PINMUX_GPIO39__FUNC_GPIO39 (MTK_PIN_NO(39) | 0)
+#define PINMUX_GPIO39__FUNC_SRCLKENA1 (MTK_PIN_NO(39) | 1)
+#define PINMUX_GPIO39__FUNC_DMIC2_DAT_R (MTK_PIN_NO(39) | 2)
+#define PINMUX_GPIO39__FUNC_DBG_MON_A30 (MTK_PIN_NO(39) | 7)
+
+#define PINMUX_GPIO40__FUNC_GPIO40 (MTK_PIN_NO(40) | 0)
+#define PINMUX_GPIO40__FUNC_PWRAP_SPI0_CSN (MTK_PIN_NO(40) | 1)
+#define PINMUX_GPIO40__FUNC_SPIM3_CSB (MTK_PIN_NO(40) | 3)
+#define PINMUX_GPIO40__FUNC_DBG_MON_A31 (MTK_PIN_NO(40) | 7)
+
+#define PINMUX_GPIO41__FUNC_GPIO41 (MTK_PIN_NO(41) | 0)
+#define PINMUX_GPIO41__FUNC_PWRAP_SPI0_CK (MTK_PIN_NO(41) | 1)
+#define PINMUX_GPIO41__FUNC_SPIM3_CLK (MTK_PIN_NO(41) | 3)
+#define PINMUX_GPIO41__FUNC_DBG_MON_A32 (MTK_PIN_NO(41) | 7)
+
+#define PINMUX_GPIO42__FUNC_GPIO42 (MTK_PIN_NO(42) | 0)
+#define PINMUX_GPIO42__FUNC_PWRAP_SPI0_MO (MTK_PIN_NO(42) | 1)
+#define PINMUX_GPIO42__FUNC_PWRAP_SPI0_MI (MTK_PIN_NO(42) | 2)
+#define PINMUX_GPIO42__FUNC_SPIM3_MO (MTK_PIN_NO(42) | 3)
+#define PINMUX_GPIO42__FUNC_DBG_MON_B0 (MTK_PIN_NO(42) | 7)
+
+#define PINMUX_GPIO43__FUNC_GPIO43 (MTK_PIN_NO(43) | 0)
+#define PINMUX_GPIO43__FUNC_PWRAP_SPI0_MI (MTK_PIN_NO(43) | 1)
+#define PINMUX_GPIO43__FUNC_PWRAP_SPI0_MO (MTK_PIN_NO(43) | 2)
+#define PINMUX_GPIO43__FUNC_SPIM3_MI (MTK_PIN_NO(43) | 3)
+#define PINMUX_GPIO43__FUNC_DBG_MON_B1 (MTK_PIN_NO(43) | 7)
+
+#define PINMUX_GPIO44__FUNC_GPIO44 (MTK_PIN_NO(44) | 0)
+#define PINMUX_GPIO44__FUNC_SPMI_M_SCL (MTK_PIN_NO(44) | 1)
+#define PINMUX_GPIO44__FUNC_I2SI00_DATA1 (MTK_PIN_NO(44) | 2)
+#define PINMUX_GPIO44__FUNC_SCL5 (MTK_PIN_NO(44) | 3)
+#define PINMUX_GPIO44__FUNC_UTXD5 (MTK_PIN_NO(44) | 4)
+#define PINMUX_GPIO44__FUNC_DBG_MON_B2 (MTK_PIN_NO(44) | 7)
+
+#define PINMUX_GPIO45__FUNC_GPIO45 (MTK_PIN_NO(45) | 0)
+#define PINMUX_GPIO45__FUNC_SPMI_M_SDA (MTK_PIN_NO(45) | 1)
+#define PINMUX_GPIO45__FUNC_I2SI00_DATA2 (MTK_PIN_NO(45) | 2)
+#define PINMUX_GPIO45__FUNC_SDA5 (MTK_PIN_NO(45) | 3)
+#define PINMUX_GPIO45__FUNC_URXD5 (MTK_PIN_NO(45) | 4)
+#define PINMUX_GPIO45__FUNC_DBG_MON_B3 (MTK_PIN_NO(45) | 7)
+
+#define PINMUX_GPIO46__FUNC_GPIO46 (MTK_PIN_NO(46) | 0)
+#define PINMUX_GPIO46__FUNC_I2SIN_MCK (MTK_PIN_NO(46) | 1)
+#define PINMUX_GPIO46__FUNC_I2SI00_DATA3 (MTK_PIN_NO(46) | 2)
+#define PINMUX_GPIO46__FUNC_SPLIN_MCK (MTK_PIN_NO(46) | 3)
+#define PINMUX_GPIO46__FUNC_DBG_MON_B4 (MTK_PIN_NO(46) | 7)
+
+#define PINMUX_GPIO47__FUNC_GPIO47 (MTK_PIN_NO(47) | 0)
+#define PINMUX_GPIO47__FUNC_I2SIN_BCK (MTK_PIN_NO(47) | 1)
+#define PINMUX_GPIO47__FUNC_I2SIN0_BCK (MTK_PIN_NO(47) | 2)
+#define PINMUX_GPIO47__FUNC_SPLIN_LRCK (MTK_PIN_NO(47) | 3)
+#define PINMUX_GPIO47__FUNC_DBG_MON_B5 (MTK_PIN_NO(47) | 7)
+
+#define PINMUX_GPIO48__FUNC_GPIO48 (MTK_PIN_NO(48) | 0)
+#define PINMUX_GPIO48__FUNC_I2SIN_WS (MTK_PIN_NO(48) | 1)
+#define PINMUX_GPIO48__FUNC_I2SIN0_LRCK (MTK_PIN_NO(48) | 2)
+#define PINMUX_GPIO48__FUNC_SPLIN_BCK (MTK_PIN_NO(48) | 3)
+#define PINMUX_GPIO48__FUNC_DBG_MON_B6 (MTK_PIN_NO(48) | 7)
+
+#define PINMUX_GPIO49__FUNC_GPIO49 (MTK_PIN_NO(49) | 0)
+#define PINMUX_GPIO49__FUNC_I2SIN_D0 (MTK_PIN_NO(49) | 1)
+#define PINMUX_GPIO49__FUNC_I2SI00_DATA0 (MTK_PIN_NO(49) | 2)
+#define PINMUX_GPIO49__FUNC_SPLIN_D0 (MTK_PIN_NO(49) | 3)
+#define PINMUX_GPIO49__FUNC_DBG_MON_B7 (MTK_PIN_NO(49) | 7)
+
+#define PINMUX_GPIO50__FUNC_GPIO50 (MTK_PIN_NO(50) | 0)
+#define PINMUX_GPIO50__FUNC_I2SO1_MCK (MTK_PIN_NO(50) | 1)
+#define PINMUX_GPIO50__FUNC_I2SI5_D0 (MTK_PIN_NO(50) | 2)
+#define PINMUX_GPIO50__FUNC_I2SO4_MCK (MTK_PIN_NO(50) | 4)
+#define PINMUX_GPIO50__FUNC_DBG_MON_B8 (MTK_PIN_NO(50) | 7)
+
+#define PINMUX_GPIO51__FUNC_GPIO51 (MTK_PIN_NO(51) | 0)
+#define PINMUX_GPIO51__FUNC_I2SO1_BCK (MTK_PIN_NO(51) | 1)
+#define PINMUX_GPIO51__FUNC_I2SI5_BCK (MTK_PIN_NO(51) | 2)
+#define PINMUX_GPIO51__FUNC_DBG_MON_B9 (MTK_PIN_NO(51) | 7)
+
+#define PINMUX_GPIO52__FUNC_GPIO52 (MTK_PIN_NO(52) | 0)
+#define PINMUX_GPIO52__FUNC_I2SO1_WS (MTK_PIN_NO(52) | 1)
+#define PINMUX_GPIO52__FUNC_I2SI5_WS (MTK_PIN_NO(52) | 2)
+#define PINMUX_GPIO52__FUNC_DBG_MON_B10 (MTK_PIN_NO(52) | 7)
+
+#define PINMUX_GPIO53__FUNC_GPIO53 (MTK_PIN_NO(53) | 0)
+#define PINMUX_GPIO53__FUNC_I2SO1_D0 (MTK_PIN_NO(53) | 1)
+#define PINMUX_GPIO53__FUNC_I2SI5_MCK (MTK_PIN_NO(53) | 2)
+#define PINMUX_GPIO53__FUNC_DBG_MON_B11 (MTK_PIN_NO(53) | 7)
+
+#define PINMUX_GPIO54__FUNC_GPIO54 (MTK_PIN_NO(54) | 0)
+#define PINMUX_GPIO54__FUNC_I2SO1_D1 (MTK_PIN_NO(54) | 1)
+#define PINMUX_GPIO54__FUNC_I2SI01_DATA1 (MTK_PIN_NO(54) | 2)
+#define PINMUX_GPIO54__FUNC_SPLIN_D1 (MTK_PIN_NO(54) | 3)
+#define PINMUX_GPIO54__FUNC_I2SO4_BCK (MTK_PIN_NO(54) | 4)
+#define PINMUX_GPIO54__FUNC_DBG_MON_B12 (MTK_PIN_NO(54) | 7)
+
+#define PINMUX_GPIO55__FUNC_GPIO55 (MTK_PIN_NO(55) | 0)
+#define PINMUX_GPIO55__FUNC_I2SO1_D2 (MTK_PIN_NO(55) | 1)
+#define PINMUX_GPIO55__FUNC_I2SI01_DATA2 (MTK_PIN_NO(55) | 2)
+#define PINMUX_GPIO55__FUNC_SPLIN_D2 (MTK_PIN_NO(55) | 3)
+#define PINMUX_GPIO55__FUNC_I2SO4_WS (MTK_PIN_NO(55) | 4)
+#define PINMUX_GPIO55__FUNC_DBG_MON_B13 (MTK_PIN_NO(55) | 7)
+
+#define PINMUX_GPIO56__FUNC_GPIO56 (MTK_PIN_NO(56) | 0)
+#define PINMUX_GPIO56__FUNC_I2SO1_D3 (MTK_PIN_NO(56) | 1)
+#define PINMUX_GPIO56__FUNC_I2SI01_DATA3 (MTK_PIN_NO(56) | 2)
+#define PINMUX_GPIO56__FUNC_SPLIN_D3 (MTK_PIN_NO(56) | 3)
+#define PINMUX_GPIO56__FUNC_I2SO4_D0 (MTK_PIN_NO(56) | 4)
+#define PINMUX_GPIO56__FUNC_DBG_MON_B14 (MTK_PIN_NO(56) | 7)
+
+#define PINMUX_GPIO57__FUNC_GPIO57 (MTK_PIN_NO(57) | 0)
+#define PINMUX_GPIO57__FUNC_I2SO2_MCK (MTK_PIN_NO(57) | 1)
+#define PINMUX_GPIO57__FUNC_I2SO1_D12 (MTK_PIN_NO(57) | 2)
+#define PINMUX_GPIO57__FUNC_LCM1_RST (MTK_PIN_NO(57) | 3)
+#define PINMUX_GPIO57__FUNC_DBG_MON_B15 (MTK_PIN_NO(57) | 7)
+
+#define PINMUX_GPIO58__FUNC_GPIO58 (MTK_PIN_NO(58) | 0)
+#define PINMUX_GPIO58__FUNC_I2SO2_BCK (MTK_PIN_NO(58) | 1)
+#define PINMUX_GPIO58__FUNC_I2SO1_D13 (MTK_PIN_NO(58) | 2)
+#define PINMUX_GPIO58__FUNC_I2SIN1_BCK (MTK_PIN_NO(58) | 3)
+#define PINMUX_GPIO58__FUNC_DBG_MON_B16 (MTK_PIN_NO(58) | 7)
+
+#define PINMUX_GPIO59__FUNC_GPIO59 (MTK_PIN_NO(59) | 0)
+#define PINMUX_GPIO59__FUNC_I2SO2_WS (MTK_PIN_NO(59) | 1)
+#define PINMUX_GPIO59__FUNC_I2SO1_D14 (MTK_PIN_NO(59) | 2)
+#define PINMUX_GPIO59__FUNC_I2SIN1_LRCK (MTK_PIN_NO(59) | 3)
+#define PINMUX_GPIO59__FUNC_DBG_MON_B17 (MTK_PIN_NO(59) | 7)
+
+#define PINMUX_GPIO60__FUNC_GPIO60 (MTK_PIN_NO(60) | 0)
+#define PINMUX_GPIO60__FUNC_I2SO2_D0 (MTK_PIN_NO(60) | 1)
+#define PINMUX_GPIO60__FUNC_I2SO1_D15 (MTK_PIN_NO(60) | 2)
+#define PINMUX_GPIO60__FUNC_I2SI01_DATA0 (MTK_PIN_NO(60) | 3)
+#define PINMUX_GPIO60__FUNC_DBG_MON_B18 (MTK_PIN_NO(60) | 7)
+
+#define PINMUX_GPIO61__FUNC_GPIO61 (MTK_PIN_NO(61) | 0)
+#define PINMUX_GPIO61__FUNC_DMIC1_CLK (MTK_PIN_NO(61) | 1)
+#define PINMUX_GPIO61__FUNC_I2SO2_BCK (MTK_PIN_NO(61) | 2)
+#define PINMUX_GPIO61__FUNC_SCP_SPI2_CK (MTK_PIN_NO(61) | 3)
+#define PINMUX_GPIO61__FUNC_DBG_MON_B19 (MTK_PIN_NO(61) | 7)
+
+#define PINMUX_GPIO62__FUNC_GPIO62 (MTK_PIN_NO(62) | 0)
+#define PINMUX_GPIO62__FUNC_DMIC1_DAT (MTK_PIN_NO(62) | 1)
+#define PINMUX_GPIO62__FUNC_I2SO2_WS (MTK_PIN_NO(62) | 2)
+#define PINMUX_GPIO62__FUNC_SCP_SPI2_MI (MTK_PIN_NO(62) | 3)
+#define PINMUX_GPIO62__FUNC_DBG_MON_B20 (MTK_PIN_NO(62) | 7)
+
+#define PINMUX_GPIO63__FUNC_GPIO63 (MTK_PIN_NO(63) | 0)
+#define PINMUX_GPIO63__FUNC_DMIC2_CLK (MTK_PIN_NO(63) | 1)
+#define PINMUX_GPIO63__FUNC_VBUSVALID (MTK_PIN_NO(63) | 2)
+#define PINMUX_GPIO63__FUNC_SCP_SPI2_MO (MTK_PIN_NO(63) | 3)
+#define PINMUX_GPIO63__FUNC_SCP_SCL2 (MTK_PIN_NO(63) | 4)
+#define PINMUX_GPIO63__FUNC_SCP_JTAG1_TDO (MTK_PIN_NO(63) | 5)
+#define PINMUX_GPIO63__FUNC_JTDO_SEL1 (MTK_PIN_NO(63) | 6)
+#define PINMUX_GPIO63__FUNC_DBG_MON_B21 (MTK_PIN_NO(63) | 7)
+
+#define PINMUX_GPIO64__FUNC_GPIO64 (MTK_PIN_NO(64) | 0)
+#define PINMUX_GPIO64__FUNC_DMIC2_DAT (MTK_PIN_NO(64) | 1)
+#define PINMUX_GPIO64__FUNC_VBUSVALID_1P (MTK_PIN_NO(64) | 2)
+#define PINMUX_GPIO64__FUNC_SCP_SPI2_CS (MTK_PIN_NO(64) | 3)
+#define PINMUX_GPIO64__FUNC_SCP_SDA2 (MTK_PIN_NO(64) | 4)
+#define PINMUX_GPIO64__FUNC_DBG_MON_B22 (MTK_PIN_NO(64) | 7)
+
+#define PINMUX_GPIO65__FUNC_GPIO65 (MTK_PIN_NO(65) | 0)
+#define PINMUX_GPIO65__FUNC_PCM_DO (MTK_PIN_NO(65) | 1)
+#define PINMUX_GPIO65__FUNC_AUXIF_ST0 (MTK_PIN_NO(65) | 2)
+#define PINMUX_GPIO65__FUNC_UCTS2 (MTK_PIN_NO(65) | 3)
+#define PINMUX_GPIO65__FUNC_SCP_JTAG1_TMS (MTK_PIN_NO(65) | 5)
+#define PINMUX_GPIO65__FUNC_JTMS_SEL1 (MTK_PIN_NO(65) | 6)
+#define PINMUX_GPIO65__FUNC_DBG_MON_B23 (MTK_PIN_NO(65) | 7)
+
+#define PINMUX_GPIO66__FUNC_GPIO66 (MTK_PIN_NO(66) | 0)
+#define PINMUX_GPIO66__FUNC_PCM_CLK (MTK_PIN_NO(66) | 1)
+#define PINMUX_GPIO66__FUNC_AUXIF_CLK0 (MTK_PIN_NO(66) | 2)
+#define PINMUX_GPIO66__FUNC_URTS2 (MTK_PIN_NO(66) | 3)
+#define PINMUX_GPIO66__FUNC_SCP_JTAG1_TCK (MTK_PIN_NO(66) | 5)
+#define PINMUX_GPIO66__FUNC_JTCK_SEL1 (MTK_PIN_NO(66) | 6)
+#define PINMUX_GPIO66__FUNC_DBG_MON_B24 (MTK_PIN_NO(66) | 7)
+
+#define PINMUX_GPIO67__FUNC_GPIO67 (MTK_PIN_NO(67) | 0)
+#define PINMUX_GPIO67__FUNC_PCM_DI (MTK_PIN_NO(67) | 1)
+#define PINMUX_GPIO67__FUNC_AUXIF_ST1 (MTK_PIN_NO(67) | 2)
+#define PINMUX_GPIO67__FUNC_UTXD2 (MTK_PIN_NO(67) | 3)
+#define PINMUX_GPIO67__FUNC_SCP_JTAG1_TRSTN (MTK_PIN_NO(67) | 5)
+#define PINMUX_GPIO67__FUNC_JTRSTn_SEL1 (MTK_PIN_NO(67) | 6)
+#define PINMUX_GPIO67__FUNC_DBG_MON_B25 (MTK_PIN_NO(67) | 7)
+
+#define PINMUX_GPIO68__FUNC_GPIO68 (MTK_PIN_NO(68) | 0)
+#define PINMUX_GPIO68__FUNC_PCM_SYNC (MTK_PIN_NO(68) | 1)
+#define PINMUX_GPIO68__FUNC_AUXIF_CLK1 (MTK_PIN_NO(68) | 2)
+#define PINMUX_GPIO68__FUNC_URXD2 (MTK_PIN_NO(68) | 3)
+#define PINMUX_GPIO68__FUNC_SCP_JTAG1_TDI (MTK_PIN_NO(68) | 5)
+#define PINMUX_GPIO68__FUNC_JTDI_SEL1 (MTK_PIN_NO(68) | 6)
+#define PINMUX_GPIO68__FUNC_DBG_MON_B26 (MTK_PIN_NO(68) | 7)
+
+#define PINMUX_GPIO69__FUNC_GPIO69 (MTK_PIN_NO(69) | 0)
+#define PINMUX_GPIO69__FUNC_AUD_CLK_MOSI (MTK_PIN_NO(69) | 1)
+#define PINMUX_GPIO69__FUNC_I2SIN2_BCK (MTK_PIN_NO(69) | 2)
+#define PINMUX_GPIO69__FUNC_PWM_0 (MTK_PIN_NO(69) | 3)
+#define PINMUX_GPIO69__FUNC_WAKEN (MTK_PIN_NO(69) | 4)
+#define PINMUX_GPIO69__FUNC_DBG_MON_B27 (MTK_PIN_NO(69) | 7)
+
+#define PINMUX_GPIO70__FUNC_GPIO70 (MTK_PIN_NO(70) | 0)
+#define PINMUX_GPIO70__FUNC_AUD_SYNC_MOSI (MTK_PIN_NO(70) | 1)
+#define PINMUX_GPIO70__FUNC_I2SIN2_LRCK (MTK_PIN_NO(70) | 2)
+#define PINMUX_GPIO70__FUNC_PWM_1 (MTK_PIN_NO(70) | 3)
+#define PINMUX_GPIO70__FUNC_PERSTN (MTK_PIN_NO(70) | 4)
+#define PINMUX_GPIO70__FUNC_DBG_MON_B28 (MTK_PIN_NO(70) | 7)
+
+#define PINMUX_GPIO71__FUNC_GPIO71 (MTK_PIN_NO(71) | 0)
+#define PINMUX_GPIO71__FUNC_AUD_DAT_MOSI0 (MTK_PIN_NO(71) | 1)
+#define PINMUX_GPIO71__FUNC_IDDIG_2P (MTK_PIN_NO(71) | 2)
+#define PINMUX_GPIO71__FUNC_PWM_2 (MTK_PIN_NO(71) | 3)
+#define PINMUX_GPIO71__FUNC_CLKREQN (MTK_PIN_NO(71) | 4)
+#define PINMUX_GPIO71__FUNC_DBG_MON_B29 (MTK_PIN_NO(71) | 7)
+
+#define PINMUX_GPIO72__FUNC_GPIO72 (MTK_PIN_NO(72) | 0)
+#define PINMUX_GPIO72__FUNC_AUD_DAT_MOSI1 (MTK_PIN_NO(72) | 1)
+#define PINMUX_GPIO72__FUNC_USB_DRVVBUS_2P (MTK_PIN_NO(72) | 2)
+#define PINMUX_GPIO72__FUNC_PWM_3 (MTK_PIN_NO(72) | 3)
+#define PINMUX_GPIO72__FUNC_PERSTN_1 (MTK_PIN_NO(72) | 4)
+#define PINMUX_GPIO72__FUNC_DBG_MON_B30 (MTK_PIN_NO(72) | 7)
+
+#define PINMUX_GPIO73__FUNC_GPIO73 (MTK_PIN_NO(73) | 0)
+#define PINMUX_GPIO73__FUNC_AUD_DAT_MISO0 (MTK_PIN_NO(73) | 1)
+#define PINMUX_GPIO73__FUNC_I2SI02_DATA0 (MTK_PIN_NO(73) | 2)
+#define PINMUX_GPIO73__FUNC_CLKREQN_1 (MTK_PIN_NO(73) | 4)
+#define PINMUX_GPIO73__FUNC_VOW_DAT_MISO (MTK_PIN_NO(73) | 5)
+#define PINMUX_GPIO73__FUNC_DBG_MON_B31 (MTK_PIN_NO(73) | 7)
+
+#define PINMUX_GPIO74__FUNC_GPIO74 (MTK_PIN_NO(74) | 0)
+#define PINMUX_GPIO74__FUNC_AUD_DAT_MISO1 (MTK_PIN_NO(74) | 1)
+#define PINMUX_GPIO74__FUNC_I2SI02_DATA1 (MTK_PIN_NO(74) | 2)
+#define PINMUX_GPIO74__FUNC_WAKEN_1 (MTK_PIN_NO(74) | 4)
+#define PINMUX_GPIO74__FUNC_VOW_CLK_MISO (MTK_PIN_NO(74) | 5)
+#define PINMUX_GPIO74__FUNC_DBG_MON_B32 (MTK_PIN_NO(74) | 7)
+
+#define PINMUX_GPIO75__FUNC_GPIO75 (MTK_PIN_NO(75) | 0)
+#define PINMUX_GPIO75__FUNC_AUD_DAT_MISO2 (MTK_PIN_NO(75) | 1)
+#define PINMUX_GPIO75__FUNC_I2SI02_DATA2 (MTK_PIN_NO(75) | 2)
+
+#define PINMUX_GPIO76__FUNC_GPIO76 (MTK_PIN_NO(76) | 0)
+#define PINMUX_GPIO76__FUNC_SCP_VREQ_VAO (MTK_PIN_NO(76) | 1)
+#define PINMUX_GPIO76__FUNC_I2SI02_DATA3 (MTK_PIN_NO(76) | 2)
+#define PINMUX_GPIO76__FUNC_DBG_MON_A26 (MTK_PIN_NO(76) | 7)
+
+#define PINMUX_GPIO77__FUNC_GPIO77 (MTK_PIN_NO(77) | 0)
+#define PINMUX_GPIO77__FUNC_DGI_D0 (MTK_PIN_NO(77) | 1)
+#define PINMUX_GPIO77__FUNC_DPI_D0 (MTK_PIN_NO(77) | 2)
+#define PINMUX_GPIO77__FUNC_I2SI4_MCK (MTK_PIN_NO(77) | 3)
+#define PINMUX_GPIO77__FUNC_SPIM4_CLK (MTK_PIN_NO(77) | 4)
+#define PINMUX_GPIO77__FUNC_GBE_TXD3 (MTK_PIN_NO(77) | 5)
+#define PINMUX_GPIO77__FUNC_SPM_JTAG_TCK (MTK_PIN_NO(77) | 6)
+
+#define PINMUX_GPIO78__FUNC_GPIO78 (MTK_PIN_NO(78) | 0)
+#define PINMUX_GPIO78__FUNC_DGI_D1 (MTK_PIN_NO(78) | 1)
+#define PINMUX_GPIO78__FUNC_DPI_D1 (MTK_PIN_NO(78) | 2)
+#define PINMUX_GPIO78__FUNC_I2SI4_BCK (MTK_PIN_NO(78) | 3)
+#define PINMUX_GPIO78__FUNC_SPIM4_MO (MTK_PIN_NO(78) | 4)
+#define PINMUX_GPIO78__FUNC_GBE_TXD2 (MTK_PIN_NO(78) | 5)
+#define PINMUX_GPIO78__FUNC_SPM_JTAG_TMS (MTK_PIN_NO(78) | 6)
+
+#define PINMUX_GPIO79__FUNC_GPIO79 (MTK_PIN_NO(79) | 0)
+#define PINMUX_GPIO79__FUNC_DGI_D2 (MTK_PIN_NO(79) | 1)
+#define PINMUX_GPIO79__FUNC_DPI_D2 (MTK_PIN_NO(79) | 2)
+#define PINMUX_GPIO79__FUNC_I2SI4_WS (MTK_PIN_NO(79) | 3)
+#define PINMUX_GPIO79__FUNC_SPIM4_CSB (MTK_PIN_NO(79) | 4)
+#define PINMUX_GPIO79__FUNC_GBE_TXD1 (MTK_PIN_NO(79) | 5)
+#define PINMUX_GPIO79__FUNC_SPM_JTAG_TDI (MTK_PIN_NO(79) | 6)
+
+#define PINMUX_GPIO80__FUNC_GPIO80 (MTK_PIN_NO(80) | 0)
+#define PINMUX_GPIO80__FUNC_DGI_D3 (MTK_PIN_NO(80) | 1)
+#define PINMUX_GPIO80__FUNC_DPI_D3 (MTK_PIN_NO(80) | 2)
+#define PINMUX_GPIO80__FUNC_I2SI4_D0 (MTK_PIN_NO(80) | 3)
+#define PINMUX_GPIO80__FUNC_SPIM4_MI (MTK_PIN_NO(80) | 4)
+#define PINMUX_GPIO80__FUNC_GBE_TXD0 (MTK_PIN_NO(80) | 5)
+#define PINMUX_GPIO80__FUNC_SPM_JTAG_TDO (MTK_PIN_NO(80) | 6)
+
+#define PINMUX_GPIO81__FUNC_GPIO81 (MTK_PIN_NO(81) | 0)
+#define PINMUX_GPIO81__FUNC_DGI_D4 (MTK_PIN_NO(81) | 1)
+#define PINMUX_GPIO81__FUNC_DPI_D4 (MTK_PIN_NO(81) | 2)
+#define PINMUX_GPIO81__FUNC_I2SI5_MCK (MTK_PIN_NO(81) | 3)
+#define PINMUX_GPIO81__FUNC_SPIM5_CLK (MTK_PIN_NO(81) | 4)
+#define PINMUX_GPIO81__FUNC_GBE_RXD3 (MTK_PIN_NO(81) | 5)
+#define PINMUX_GPIO81__FUNC_SPM_JTAG_TRSTN (MTK_PIN_NO(81) | 6)
+
+#define PINMUX_GPIO82__FUNC_GPIO82 (MTK_PIN_NO(82) | 0)
+#define PINMUX_GPIO82__FUNC_DGI_D5 (MTK_PIN_NO(82) | 1)
+#define PINMUX_GPIO82__FUNC_DPI_D5 (MTK_PIN_NO(82) | 2)
+#define PINMUX_GPIO82__FUNC_I2SI5_BCK (MTK_PIN_NO(82) | 3)
+#define PINMUX_GPIO82__FUNC_SPIM5_MO (MTK_PIN_NO(82) | 4)
+#define PINMUX_GPIO82__FUNC_GBE_RXD2 (MTK_PIN_NO(82) | 5)
+#define PINMUX_GPIO82__FUNC_MCUPM_JTAG_TDO (MTK_PIN_NO(82) | 6)
+
+#define PINMUX_GPIO83__FUNC_GPIO83 (MTK_PIN_NO(83) | 0)
+#define PINMUX_GPIO83__FUNC_DGI_D6 (MTK_PIN_NO(83) | 1)
+#define PINMUX_GPIO83__FUNC_DPI_D6 (MTK_PIN_NO(83) | 2)
+#define PINMUX_GPIO83__FUNC_I2SI5_WS (MTK_PIN_NO(83) | 3)
+#define PINMUX_GPIO83__FUNC_SPIM5_CSB (MTK_PIN_NO(83) | 4)
+#define PINMUX_GPIO83__FUNC_GBE_RXD1 (MTK_PIN_NO(83) | 5)
+#define PINMUX_GPIO83__FUNC_MCUPM_JTAG_TMS (MTK_PIN_NO(83) | 6)
+
+#define PINMUX_GPIO84__FUNC_GPIO84 (MTK_PIN_NO(84) | 0)
+#define PINMUX_GPIO84__FUNC_DGI_D7 (MTK_PIN_NO(84) | 1)
+#define PINMUX_GPIO84__FUNC_DPI_D7 (MTK_PIN_NO(84) | 2)
+#define PINMUX_GPIO84__FUNC_I2SI5_D0 (MTK_PIN_NO(84) | 3)
+#define PINMUX_GPIO84__FUNC_SPIM5_MI (MTK_PIN_NO(84) | 4)
+#define PINMUX_GPIO84__FUNC_GBE_RXD0 (MTK_PIN_NO(84) | 5)
+#define PINMUX_GPIO84__FUNC_MCUPM_JTAG_TCK (MTK_PIN_NO(84) | 6)
+
+#define PINMUX_GPIO85__FUNC_GPIO85 (MTK_PIN_NO(85) | 0)
+#define PINMUX_GPIO85__FUNC_DGI_D8 (MTK_PIN_NO(85) | 1)
+#define PINMUX_GPIO85__FUNC_DPI_D8 (MTK_PIN_NO(85) | 2)
+#define PINMUX_GPIO85__FUNC_I2SO4_MCK (MTK_PIN_NO(85) | 3)
+#define PINMUX_GPIO85__FUNC_SCP_SPI1_B_CK (MTK_PIN_NO(85) | 4)
+#define PINMUX_GPIO85__FUNC_GBE_TXC (MTK_PIN_NO(85) | 5)
+#define PINMUX_GPIO85__FUNC_MCUPM_JTAG_TDI (MTK_PIN_NO(85) | 6)
+
+#define PINMUX_GPIO86__FUNC_GPIO86 (MTK_PIN_NO(86) | 0)
+#define PINMUX_GPIO86__FUNC_DGI_D9 (MTK_PIN_NO(86) | 1)
+#define PINMUX_GPIO86__FUNC_DPI_D9 (MTK_PIN_NO(86) | 2)
+#define PINMUX_GPIO86__FUNC_I2SO4_BCK (MTK_PIN_NO(86) | 3)
+#define PINMUX_GPIO86__FUNC_SCP_SPI1_B_MI (MTK_PIN_NO(86) | 4)
+#define PINMUX_GPIO86__FUNC_GBE_RXC (MTK_PIN_NO(86) | 5)
+#define PINMUX_GPIO86__FUNC_MCUPM_JTAG_TRSTN (MTK_PIN_NO(86) | 6)
+
+#define PINMUX_GPIO87__FUNC_GPIO87 (MTK_PIN_NO(87) | 0)
+#define PINMUX_GPIO87__FUNC_DGI_D10 (MTK_PIN_NO(87) | 1)
+#define PINMUX_GPIO87__FUNC_DPI_D10 (MTK_PIN_NO(87) | 2)
+#define PINMUX_GPIO87__FUNC_I2SO4_WS (MTK_PIN_NO(87) | 3)
+#define PINMUX_GPIO87__FUNC_SCP_SPI1_B_CS (MTK_PIN_NO(87) | 4)
+#define PINMUX_GPIO87__FUNC_GBE_RXDV (MTK_PIN_NO(87) | 5)
+#define PINMUX_GPIO87__FUNC_SSPM_JTAG_TDO (MTK_PIN_NO(87) | 6)
+
+#define PINMUX_GPIO88__FUNC_GPIO88 (MTK_PIN_NO(88) | 0)
+#define PINMUX_GPIO88__FUNC_DGI_D11 (MTK_PIN_NO(88) | 1)
+#define PINMUX_GPIO88__FUNC_DPI_D11 (MTK_PIN_NO(88) | 2)
+#define PINMUX_GPIO88__FUNC_I2SO4_D0 (MTK_PIN_NO(88) | 3)
+#define PINMUX_GPIO88__FUNC_SCP_SPI1_B_MO (MTK_PIN_NO(88) | 4)
+#define PINMUX_GPIO88__FUNC_GBE_TXEN (MTK_PIN_NO(88) | 5)
+#define PINMUX_GPIO88__FUNC_SSPM_JTAG_TMS (MTK_PIN_NO(88) | 6)
+
+#define PINMUX_GPIO89__FUNC_GPIO89 (MTK_PIN_NO(89) | 0)
+#define PINMUX_GPIO89__FUNC_DGI_D12 (MTK_PIN_NO(89) | 1)
+#define PINMUX_GPIO89__FUNC_DPI_D12 (MTK_PIN_NO(89) | 2)
+#define PINMUX_GPIO89__FUNC_MSDC2_CMD_A (MTK_PIN_NO(89) | 3)
+#define PINMUX_GPIO89__FUNC_I2SO5_BCK (MTK_PIN_NO(89) | 4)
+#define PINMUX_GPIO89__FUNC_GBE_MDC (MTK_PIN_NO(89) | 5)
+#define PINMUX_GPIO89__FUNC_SSPM_JTAG_TCK (MTK_PIN_NO(89) | 6)
+
+#define PINMUX_GPIO90__FUNC_GPIO90 (MTK_PIN_NO(90) | 0)
+#define PINMUX_GPIO90__FUNC_DGI_D13 (MTK_PIN_NO(90) | 1)
+#define PINMUX_GPIO90__FUNC_DPI_D13 (MTK_PIN_NO(90) | 2)
+#define PINMUX_GPIO90__FUNC_MSDC2_CLK_A (MTK_PIN_NO(90) | 3)
+#define PINMUX_GPIO90__FUNC_I2SO5_WS (MTK_PIN_NO(90) | 4)
+#define PINMUX_GPIO90__FUNC_GBE_MDIO (MTK_PIN_NO(90) | 5)
+#define PINMUX_GPIO90__FUNC_SSPM_JTAG_TDI (MTK_PIN_NO(90) | 6)
+
+#define PINMUX_GPIO91__FUNC_GPIO91 (MTK_PIN_NO(91) | 0)
+#define PINMUX_GPIO91__FUNC_DGI_D14 (MTK_PIN_NO(91) | 1)
+#define PINMUX_GPIO91__FUNC_DPI_D14 (MTK_PIN_NO(91) | 2)
+#define PINMUX_GPIO91__FUNC_MSDC2_DAT3_A (MTK_PIN_NO(91) | 3)
+#define PINMUX_GPIO91__FUNC_I2SO5_D0 (MTK_PIN_NO(91) | 4)
+#define PINMUX_GPIO91__FUNC_GBE_TXER (MTK_PIN_NO(91) | 5)
+#define PINMUX_GPIO91__FUNC_SSPM_JTAG_TRSTN (MTK_PIN_NO(91) | 6)
+
+#define PINMUX_GPIO92__FUNC_GPIO92 (MTK_PIN_NO(92) | 0)
+#define PINMUX_GPIO92__FUNC_DGI_D15 (MTK_PIN_NO(92) | 1)
+#define PINMUX_GPIO92__FUNC_DPI_D15 (MTK_PIN_NO(92) | 2)
+#define PINMUX_GPIO92__FUNC_MSDC2_DAT0_A (MTK_PIN_NO(92) | 3)
+#define PINMUX_GPIO92__FUNC_I2SO2_D1 (MTK_PIN_NO(92) | 4)
+#define PINMUX_GPIO92__FUNC_GBE_RXER (MTK_PIN_NO(92) | 5)
+#define PINMUX_GPIO92__FUNC_CCU0_JTAG_TDO (MTK_PIN_NO(92) | 6)
+
+#define PINMUX_GPIO93__FUNC_GPIO93 (MTK_PIN_NO(93) | 0)
+#define PINMUX_GPIO93__FUNC_DGI_HSYNC (MTK_PIN_NO(93) | 1)
+#define PINMUX_GPIO93__FUNC_DPI_HSYNC (MTK_PIN_NO(93) | 2)
+#define PINMUX_GPIO93__FUNC_MSDC2_DAT2_A (MTK_PIN_NO(93) | 3)
+#define PINMUX_GPIO93__FUNC_I2SO2_D2 (MTK_PIN_NO(93) | 4)
+#define PINMUX_GPIO93__FUNC_GBE_COL (MTK_PIN_NO(93) | 5)
+#define PINMUX_GPIO93__FUNC_CCU0_JTAG_TMS (MTK_PIN_NO(93) | 6)
+
+#define PINMUX_GPIO94__FUNC_GPIO94 (MTK_PIN_NO(94) | 0)
+#define PINMUX_GPIO94__FUNC_DGI_VSYNC (MTK_PIN_NO(94) | 1)
+#define PINMUX_GPIO94__FUNC_DPI_VSYNC (MTK_PIN_NO(94) | 2)
+#define PINMUX_GPIO94__FUNC_MSDC2_DAT1_A (MTK_PIN_NO(94) | 3)
+#define PINMUX_GPIO94__FUNC_I2SO2_D3 (MTK_PIN_NO(94) | 4)
+#define PINMUX_GPIO94__FUNC_GBE_INTR (MTK_PIN_NO(94) | 5)
+#define PINMUX_GPIO94__FUNC_CCU0_JTAG_TDI (MTK_PIN_NO(94) | 6)
+
+#define PINMUX_GPIO95__FUNC_GPIO95 (MTK_PIN_NO(95) | 0)
+#define PINMUX_GPIO95__FUNC_DGI_DE (MTK_PIN_NO(95) | 1)
+#define PINMUX_GPIO95__FUNC_DPI_DE (MTK_PIN_NO(95) | 2)
+#define PINMUX_GPIO95__FUNC_UTXD2 (MTK_PIN_NO(95) | 3)
+#define PINMUX_GPIO95__FUNC_I2SIN_D1 (MTK_PIN_NO(95) | 5)
+#define PINMUX_GPIO95__FUNC_CCU0_JTAG_TCK (MTK_PIN_NO(95) | 6)
+
+#define PINMUX_GPIO96__FUNC_GPIO96 (MTK_PIN_NO(96) | 0)
+#define PINMUX_GPIO96__FUNC_DGI_CK (MTK_PIN_NO(96) | 1)
+#define PINMUX_GPIO96__FUNC_DPI_CK (MTK_PIN_NO(96) | 2)
+#define PINMUX_GPIO96__FUNC_URXD2 (MTK_PIN_NO(96) | 3)
+#define PINMUX_GPIO96__FUNC_I2SO5_MCK (MTK_PIN_NO(96) | 4)
+#define PINMUX_GPIO96__FUNC_I2SIN_D2 (MTK_PIN_NO(96) | 5)
+#define PINMUX_GPIO96__FUNC_CCU0_JTAG_TRST (MTK_PIN_NO(96) | 6)
+
+#define PINMUX_GPIO97__FUNC_GPIO97 (MTK_PIN_NO(97) | 0)
+#define PINMUX_GPIO97__FUNC_DISP_PWM0 (MTK_PIN_NO(97) | 1)
+#define PINMUX_GPIO97__FUNC_DVFSRC_EXT_REQ (MTK_PIN_NO(97) | 2)
+
+#define PINMUX_GPIO98__FUNC_GPIO98 (MTK_PIN_NO(98) | 0)
+#define PINMUX_GPIO98__FUNC_UTXD0 (MTK_PIN_NO(98) | 1)
+
+#define PINMUX_GPIO99__FUNC_GPIO99 (MTK_PIN_NO(99) | 0)
+#define PINMUX_GPIO99__FUNC_URXD0 (MTK_PIN_NO(99) | 1)
+
+#define PINMUX_GPIO100__FUNC_GPIO100 (MTK_PIN_NO(100) | 0)
+#define PINMUX_GPIO100__FUNC_URTS1 (MTK_PIN_NO(100) | 1)
+#define PINMUX_GPIO100__FUNC_DSI_TE (MTK_PIN_NO(100) | 2)
+#define PINMUX_GPIO100__FUNC_I2SO1_D8 (MTK_PIN_NO(100) | 3)
+#define PINMUX_GPIO100__FUNC_KPROW2 (MTK_PIN_NO(100) | 4)
+#define PINMUX_GPIO100__FUNC_PWM_0 (MTK_PIN_NO(100) | 5)
+#define PINMUX_GPIO100__FUNC_TP_URTS1_AO (MTK_PIN_NO(100) | 6)
+#define PINMUX_GPIO100__FUNC_I2SIN_D0 (MTK_PIN_NO(100) | 7)
+
+#define PINMUX_GPIO101__FUNC_GPIO101 (MTK_PIN_NO(101) | 0)
+#define PINMUX_GPIO101__FUNC_UCTS1 (MTK_PIN_NO(101) | 1)
+#define PINMUX_GPIO101__FUNC_DSI1_TE (MTK_PIN_NO(101) | 2)
+#define PINMUX_GPIO101__FUNC_I2SO1_D9 (MTK_PIN_NO(101) | 3)
+#define PINMUX_GPIO101__FUNC_KPCOL2 (MTK_PIN_NO(101) | 4)
+#define PINMUX_GPIO101__FUNC_PWM_1 (MTK_PIN_NO(101) | 5)
+#define PINMUX_GPIO101__FUNC_TP_UCTS1_AO (MTK_PIN_NO(101) | 6)
+#define PINMUX_GPIO101__FUNC_I2SIN_D1 (MTK_PIN_NO(101) | 7)
+
+#define PINMUX_GPIO102__FUNC_GPIO102 (MTK_PIN_NO(102) | 0)
+#define PINMUX_GPIO102__FUNC_UTXD1 (MTK_PIN_NO(102) | 1)
+#define PINMUX_GPIO102__FUNC_VBUSVALID_2P (MTK_PIN_NO(102) | 2)
+#define PINMUX_GPIO102__FUNC_I2SO1_D10 (MTK_PIN_NO(102) | 3)
+#define PINMUX_GPIO102__FUNC_SSPM_UTXD_AO (MTK_PIN_NO(102) | 4)
+#define PINMUX_GPIO102__FUNC_TP_UTXD1_AO (MTK_PIN_NO(102) | 5)
+#define PINMUX_GPIO102__FUNC_MD32_1_TXD (MTK_PIN_NO(102) | 6)
+#define PINMUX_GPIO102__FUNC_I2SIN_D2 (MTK_PIN_NO(102) | 7)
+
+#define PINMUX_GPIO103__FUNC_GPIO103 (MTK_PIN_NO(103) | 0)
+#define PINMUX_GPIO103__FUNC_URXD1 (MTK_PIN_NO(103) | 1)
+#define PINMUX_GPIO103__FUNC_VBUSVALID_3P (MTK_PIN_NO(103) | 2)
+#define PINMUX_GPIO103__FUNC_I2SO1_D11 (MTK_PIN_NO(103) | 3)
+#define PINMUX_GPIO103__FUNC_SSPM_URXD_AO (MTK_PIN_NO(103) | 4)
+#define PINMUX_GPIO103__FUNC_TP_URXD1_AO (MTK_PIN_NO(103) | 5)
+#define PINMUX_GPIO103__FUNC_MD32_1_RXD (MTK_PIN_NO(103) | 6)
+#define PINMUX_GPIO103__FUNC_I2SIN_D3 (MTK_PIN_NO(103) | 7)
+
+#define PINMUX_GPIO104__FUNC_GPIO104 (MTK_PIN_NO(104) | 0)
+#define PINMUX_GPIO104__FUNC_KPROW0 (MTK_PIN_NO(104) | 1)
+#define PINMUX_GPIO104__FUNC_DISP_PWM1 (MTK_PIN_NO(104) | 2)
+
+#define PINMUX_GPIO105__FUNC_GPIO105 (MTK_PIN_NO(105) | 0)
+#define PINMUX_GPIO105__FUNC_KPROW1 (MTK_PIN_NO(105) | 1)
+#define PINMUX_GPIO105__FUNC_EDP_TX_HPD (MTK_PIN_NO(105) | 2)
+#define PINMUX_GPIO105__FUNC_PWM_2 (MTK_PIN_NO(105) | 3)
+
+#define PINMUX_GPIO106__FUNC_GPIO106 (MTK_PIN_NO(106) | 0)
+#define PINMUX_GPIO106__FUNC_KPCOL0 (MTK_PIN_NO(106) | 1)
+
+#define PINMUX_GPIO107__FUNC_GPIO107 (MTK_PIN_NO(107) | 0)
+#define PINMUX_GPIO107__FUNC_KPCOL1 (MTK_PIN_NO(107) | 1)
+#define PINMUX_GPIO107__FUNC_DSI1_TE (MTK_PIN_NO(107) | 2)
+#define PINMUX_GPIO107__FUNC_PWM_3 (MTK_PIN_NO(107) | 3)
+#define PINMUX_GPIO107__FUNC_SCP_SCL3 (MTK_PIN_NO(107) | 4)
+#define PINMUX_GPIO107__FUNC_I2SIN_MCK (MTK_PIN_NO(107) | 5)
+
+#define PINMUX_GPIO108__FUNC_GPIO108 (MTK_PIN_NO(108) | 0)
+#define PINMUX_GPIO108__FUNC_LCM_RST (MTK_PIN_NO(108) | 1)
+#define PINMUX_GPIO108__FUNC_KPCOL1 (MTK_PIN_NO(108) | 2)
+#define PINMUX_GPIO108__FUNC_SCP_SDA3 (MTK_PIN_NO(108) | 4)
+#define PINMUX_GPIO108__FUNC_I2SIN_BCK (MTK_PIN_NO(108) | 5)
+
+#define PINMUX_GPIO109__FUNC_GPIO109 (MTK_PIN_NO(109) | 0)
+#define PINMUX_GPIO109__FUNC_DSI_TE (MTK_PIN_NO(109) | 1)
+#define PINMUX_GPIO109__FUNC_I2SIN_D3 (MTK_PIN_NO(109) | 2)
+#define PINMUX_GPIO109__FUNC_I2SIN_WS (MTK_PIN_NO(109) | 5)
+
+#define PINMUX_GPIO110__FUNC_GPIO110 (MTK_PIN_NO(110) | 0)
+#define PINMUX_GPIO110__FUNC_MSDC1_CMD (MTK_PIN_NO(110) | 1)
+#define PINMUX_GPIO110__FUNC_JTMS_SEL3 (MTK_PIN_NO(110) | 2)
+#define PINMUX_GPIO110__FUNC_UDI_TMS (MTK_PIN_NO(110) | 3)
+#define PINMUX_GPIO110__FUNC_CCU1_JTAG_TMS (MTK_PIN_NO(110) | 5)
+#define PINMUX_GPIO110__FUNC_IPU_JTAG_TMS (MTK_PIN_NO(110) | 6)
+
+#define PINMUX_GPIO111__FUNC_GPIO111 (MTK_PIN_NO(111) | 0)
+#define PINMUX_GPIO111__FUNC_MSDC1_CLK (MTK_PIN_NO(111) | 1)
+#define PINMUX_GPIO111__FUNC_JTCK_SEL3 (MTK_PIN_NO(111) | 2)
+#define PINMUX_GPIO111__FUNC_UDI_TCK (MTK_PIN_NO(111) | 3)
+#define PINMUX_GPIO111__FUNC_CCU1_JTAG_TCK (MTK_PIN_NO(111) | 5)
+#define PINMUX_GPIO111__FUNC_IPU_JTAG_TCK (MTK_PIN_NO(111) | 6)
+
+#define PINMUX_GPIO112__FUNC_GPIO112 (MTK_PIN_NO(112) | 0)
+#define PINMUX_GPIO112__FUNC_MSDC1_DAT0 (MTK_PIN_NO(112) | 1)
+#define PINMUX_GPIO112__FUNC_JTDI_SEL3 (MTK_PIN_NO(112) | 2)
+#define PINMUX_GPIO112__FUNC_UDI_TDI (MTK_PIN_NO(112) | 3)
+#define PINMUX_GPIO112__FUNC_I2SO2_D0 (MTK_PIN_NO(112) | 4)
+#define PINMUX_GPIO112__FUNC_CCU1_JTAG_TDI (MTK_PIN_NO(112) | 5)
+#define PINMUX_GPIO112__FUNC_IPU_JTAG_TDI (MTK_PIN_NO(112) | 6)
+
+#define PINMUX_GPIO113__FUNC_GPIO113 (MTK_PIN_NO(113) | 0)
+#define PINMUX_GPIO113__FUNC_MSDC1_DAT1 (MTK_PIN_NO(113) | 1)
+#define PINMUX_GPIO113__FUNC_JTDO_SEL3 (MTK_PIN_NO(113) | 2)
+#define PINMUX_GPIO113__FUNC_UDI_TDO (MTK_PIN_NO(113) | 3)
+#define PINMUX_GPIO113__FUNC_I2SO2_D1 (MTK_PIN_NO(113) | 4)
+#define PINMUX_GPIO113__FUNC_CCU1_JTAG_TDO (MTK_PIN_NO(113) | 5)
+#define PINMUX_GPIO113__FUNC_IPU_JTAG_TDO (MTK_PIN_NO(113) | 6)
+
+#define PINMUX_GPIO114__FUNC_GPIO114 (MTK_PIN_NO(114) | 0)
+#define PINMUX_GPIO114__FUNC_MSDC1_DAT2 (MTK_PIN_NO(114) | 1)
+#define PINMUX_GPIO114__FUNC_JTRSTn_SEL3 (MTK_PIN_NO(114) | 2)
+#define PINMUX_GPIO114__FUNC_UDI_NTRST (MTK_PIN_NO(114) | 3)
+#define PINMUX_GPIO114__FUNC_I2SO2_D2 (MTK_PIN_NO(114) | 4)
+#define PINMUX_GPIO114__FUNC_CCU1_JTAG_TRST (MTK_PIN_NO(114) | 5)
+#define PINMUX_GPIO114__FUNC_IPU_JTAG_TRST (MTK_PIN_NO(114) | 6)
+
+#define PINMUX_GPIO115__FUNC_GPIO115 (MTK_PIN_NO(115) | 0)
+#define PINMUX_GPIO115__FUNC_MSDC1_DAT3 (MTK_PIN_NO(115) | 1)
+#define PINMUX_GPIO115__FUNC_I2SO2_D3 (MTK_PIN_NO(115) | 4)
+#define PINMUX_GPIO115__FUNC_MD32_1_GPIO2 (MTK_PIN_NO(115) | 6)
+
+#define PINMUX_GPIO116__FUNC_GPIO116 (MTK_PIN_NO(116) | 0)
+#define PINMUX_GPIO116__FUNC_MSDC0_DAT7 (MTK_PIN_NO(116) | 1)
+
+#define PINMUX_GPIO117__FUNC_GPIO117 (MTK_PIN_NO(117) | 0)
+#define PINMUX_GPIO117__FUNC_MSDC0_DAT6 (MTK_PIN_NO(117) | 1)
+
+#define PINMUX_GPIO118__FUNC_GPIO118 (MTK_PIN_NO(118) | 0)
+#define PINMUX_GPIO118__FUNC_MSDC0_DAT5 (MTK_PIN_NO(118) | 1)
+
+#define PINMUX_GPIO119__FUNC_GPIO119 (MTK_PIN_NO(119) | 0)
+#define PINMUX_GPIO119__FUNC_MSDC0_DAT4 (MTK_PIN_NO(119) | 1)
+
+#define PINMUX_GPIO120__FUNC_GPIO120 (MTK_PIN_NO(120) | 0)
+#define PINMUX_GPIO120__FUNC_MSDC0_RSTB (MTK_PIN_NO(120) | 1)
+
+#define PINMUX_GPIO121__FUNC_GPIO121 (MTK_PIN_NO(121) | 0)
+#define PINMUX_GPIO121__FUNC_MSDC0_CMD (MTK_PIN_NO(121) | 1)
+
+#define PINMUX_GPIO122__FUNC_GPIO122 (MTK_PIN_NO(122) | 0)
+#define PINMUX_GPIO122__FUNC_MSDC0_CLK (MTK_PIN_NO(122) | 1)
+
+#define PINMUX_GPIO123__FUNC_GPIO123 (MTK_PIN_NO(123) | 0)
+#define PINMUX_GPIO123__FUNC_MSDC0_DAT3 (MTK_PIN_NO(123) | 1)
+
+#define PINMUX_GPIO124__FUNC_GPIO124 (MTK_PIN_NO(124) | 0)
+#define PINMUX_GPIO124__FUNC_MSDC0_DAT2 (MTK_PIN_NO(124) | 1)
+
+#define PINMUX_GPIO125__FUNC_GPIO125 (MTK_PIN_NO(125) | 0)
+#define PINMUX_GPIO125__FUNC_MSDC0_DAT1 (MTK_PIN_NO(125) | 1)
+
+#define PINMUX_GPIO126__FUNC_GPIO126 (MTK_PIN_NO(126) | 0)
+#define PINMUX_GPIO126__FUNC_MSDC0_DAT0 (MTK_PIN_NO(126) | 1)
+
+#define PINMUX_GPIO127__FUNC_GPIO127 (MTK_PIN_NO(127) | 0)
+#define PINMUX_GPIO127__FUNC_MSDC0_DSL (MTK_PIN_NO(127) | 1)
+
+#define PINMUX_GPIO128__FUNC_GPIO128 (MTK_PIN_NO(128) | 0)
+#define PINMUX_GPIO128__FUNC_IDDIG (MTK_PIN_NO(128) | 1)
+#define PINMUX_GPIO128__FUNC_UCTS2 (MTK_PIN_NO(128) | 2)
+#define PINMUX_GPIO128__FUNC_UTXD5 (MTK_PIN_NO(128) | 3)
+#define PINMUX_GPIO128__FUNC_UFS_MPHY_SCL (MTK_PIN_NO(128) | 4)
+#define PINMUX_GPIO128__FUNC_mbistreaden_trigger (MTK_PIN_NO(128) | 5)
+#define PINMUX_GPIO128__FUNC_MD32_1_GPIO0 (MTK_PIN_NO(128) | 6)
+#define PINMUX_GPIO128__FUNC_SCP_SCL2 (MTK_PIN_NO(128) | 7)
+
+#define PINMUX_GPIO129__FUNC_GPIO129 (MTK_PIN_NO(129) | 0)
+#define PINMUX_GPIO129__FUNC_USB_DRVVBUS (MTK_PIN_NO(129) | 1)
+#define PINMUX_GPIO129__FUNC_URTS2 (MTK_PIN_NO(129) | 2)
+#define PINMUX_GPIO129__FUNC_URXD5 (MTK_PIN_NO(129) | 3)
+#define PINMUX_GPIO129__FUNC_UFS_MPHY_SDA (MTK_PIN_NO(129) | 4)
+#define PINMUX_GPIO129__FUNC_mbistwriteen_trigger (MTK_PIN_NO(129) | 5)
+#define PINMUX_GPIO129__FUNC_MD32_1_GPIO1 (MTK_PIN_NO(129) | 6)
+#define PINMUX_GPIO129__FUNC_SCP_SDA2 (MTK_PIN_NO(129) | 7)
+
+#define PINMUX_GPIO130__FUNC_GPIO130 (MTK_PIN_NO(130) | 0)
+#define PINMUX_GPIO130__FUNC_IDDIG_1P (MTK_PIN_NO(130) | 1)
+#define PINMUX_GPIO130__FUNC_SPINOR_IO2 (MTK_PIN_NO(130) | 2)
+#define PINMUX_GPIO130__FUNC_SNFI_WP (MTK_PIN_NO(130) | 3)
+#define PINMUX_GPIO130__FUNC_VPU_UDI_NTRST (MTK_PIN_NO(130) | 4)
+
+#define PINMUX_GPIO131__FUNC_GPIO131 (MTK_PIN_NO(131) | 0)
+#define PINMUX_GPIO131__FUNC_USB_DRVVBUS_1P (MTK_PIN_NO(131) | 1)
+#define PINMUX_GPIO131__FUNC_SPINOR_IO3 (MTK_PIN_NO(131) | 2)
+#define PINMUX_GPIO131__FUNC_SNFI_HOLD (MTK_PIN_NO(131) | 3)
+#define PINMUX_GPIO131__FUNC_MD32_1_JTAG_TRST (MTK_PIN_NO(131) | 4)
+#define PINMUX_GPIO131__FUNC_SCP_JTAG0_TRSTN (MTK_PIN_NO(131) | 5)
+#define PINMUX_GPIO131__FUNC_APU_JTAG_TRST (MTK_PIN_NO(131) | 6)
+
+#define PINMUX_GPIO132__FUNC_GPIO132 (MTK_PIN_NO(132) | 0)
+#define PINMUX_GPIO132__FUNC_SPIM0_CSB (MTK_PIN_NO(132) | 1)
+#define PINMUX_GPIO132__FUNC_SCP_SPI0_CS (MTK_PIN_NO(132) | 2)
+#define PINMUX_GPIO132__FUNC_SPIS0_CSB (MTK_PIN_NO(132) | 3)
+#define PINMUX_GPIO132__FUNC_VPU_UDI_TMS (MTK_PIN_NO(132) | 4)
+#define PINMUX_GPIO132__FUNC_I2SO5_D0 (MTK_PIN_NO(132) | 6)
+
+#define PINMUX_GPIO133__FUNC_GPIO133 (MTK_PIN_NO(133) | 0)
+#define PINMUX_GPIO133__FUNC_SPIM0_CLK (MTK_PIN_NO(133) | 1)
+#define PINMUX_GPIO133__FUNC_SCP_SPI0_CK (MTK_PIN_NO(133) | 2)
+#define PINMUX_GPIO133__FUNC_SPIS0_CLK (MTK_PIN_NO(133) | 3)
+#define PINMUX_GPIO133__FUNC_VPU_UDI_TCK (MTK_PIN_NO(133) | 4)
+#define PINMUX_GPIO133__FUNC_I2SO5_BCK (MTK_PIN_NO(133) | 6)
+
+#define PINMUX_GPIO134__FUNC_GPIO134 (MTK_PIN_NO(134) | 0)
+#define PINMUX_GPIO134__FUNC_SPIM0_MO (MTK_PIN_NO(134) | 1)
+#define PINMUX_GPIO134__FUNC_SCP_SPI0_MO (MTK_PIN_NO(134) | 2)
+#define PINMUX_GPIO134__FUNC_SPIS0_SI (MTK_PIN_NO(134) | 3)
+#define PINMUX_GPIO134__FUNC_VPU_UDI_TDO (MTK_PIN_NO(134) | 4)
+#define PINMUX_GPIO134__FUNC_I2SO5_WS (MTK_PIN_NO(134) | 6)
+
+#define PINMUX_GPIO135__FUNC_GPIO135 (MTK_PIN_NO(135) | 0)
+#define PINMUX_GPIO135__FUNC_SPIM0_MI (MTK_PIN_NO(135) | 1)
+#define PINMUX_GPIO135__FUNC_SCP_SPI0_MI (MTK_PIN_NO(135) | 2)
+#define PINMUX_GPIO135__FUNC_SPIS0_SO (MTK_PIN_NO(135) | 3)
+#define PINMUX_GPIO135__FUNC_VPU_UDI_TDI (MTK_PIN_NO(135) | 4)
+#define PINMUX_GPIO135__FUNC_I2SO5_MCK (MTK_PIN_NO(135) | 6)
+
+#define PINMUX_GPIO136__FUNC_GPIO136 (MTK_PIN_NO(136) | 0)
+#define PINMUX_GPIO136__FUNC_SPIM1_CSB (MTK_PIN_NO(136) | 1)
+#define PINMUX_GPIO136__FUNC_SCP_SPI1_A_CS (MTK_PIN_NO(136) | 2)
+#define PINMUX_GPIO136__FUNC_SPIS1_CSB (MTK_PIN_NO(136) | 3)
+#define PINMUX_GPIO136__FUNC_MD32_1_JTAG_TMS (MTK_PIN_NO(136) | 4)
+#define PINMUX_GPIO136__FUNC_SCP_JTAG0_TMS (MTK_PIN_NO(136) | 5)
+#define PINMUX_GPIO136__FUNC_APU_JTAG_TMS (MTK_PIN_NO(136) | 6)
+#define PINMUX_GPIO136__FUNC_DBG_MON_A15 (MTK_PIN_NO(136) | 7)
+
+#define PINMUX_GPIO137__FUNC_GPIO137 (MTK_PIN_NO(137) | 0)
+#define PINMUX_GPIO137__FUNC_SPIM1_CLK (MTK_PIN_NO(137) | 1)
+#define PINMUX_GPIO137__FUNC_SCP_SPI1_A_CK (MTK_PIN_NO(137) | 2)
+#define PINMUX_GPIO137__FUNC_SPIS1_CLK (MTK_PIN_NO(137) | 3)
+#define PINMUX_GPIO137__FUNC_MD32_1_JTAG_TCK (MTK_PIN_NO(137) | 4)
+#define PINMUX_GPIO137__FUNC_SCP_JTAG0_TCK (MTK_PIN_NO(137) | 5)
+#define PINMUX_GPIO137__FUNC_APU_JTAG_TCK (MTK_PIN_NO(137) | 6)
+#define PINMUX_GPIO137__FUNC_DBG_MON_A14 (MTK_PIN_NO(137) | 7)
+
+#define PINMUX_GPIO138__FUNC_GPIO138 (MTK_PIN_NO(138) | 0)
+#define PINMUX_GPIO138__FUNC_SPIM1_MO (MTK_PIN_NO(138) | 1)
+#define PINMUX_GPIO138__FUNC_SCP_SPI1_A_MO (MTK_PIN_NO(138) | 2)
+#define PINMUX_GPIO138__FUNC_SPIS1_SI (MTK_PIN_NO(138) | 3)
+#define PINMUX_GPIO138__FUNC_MD32_1_JTAG_TDO (MTK_PIN_NO(138) | 4)
+#define PINMUX_GPIO138__FUNC_SCP_JTAG0_TDO (MTK_PIN_NO(138) | 5)
+#define PINMUX_GPIO138__FUNC_APU_JTAG_TDO (MTK_PIN_NO(138) | 6)
+#define PINMUX_GPIO138__FUNC_DBG_MON_A16 (MTK_PIN_NO(138) | 7)
+
+#define PINMUX_GPIO139__FUNC_GPIO139 (MTK_PIN_NO(139) | 0)
+#define PINMUX_GPIO139__FUNC_SPIM1_MI (MTK_PIN_NO(139) | 1)
+#define PINMUX_GPIO139__FUNC_SCP_SPI1_A_MI (MTK_PIN_NO(139) | 2)
+#define PINMUX_GPIO139__FUNC_SPIS1_SO (MTK_PIN_NO(139) | 3)
+#define PINMUX_GPIO139__FUNC_MD32_1_JTAG_TDI (MTK_PIN_NO(139) | 4)
+#define PINMUX_GPIO139__FUNC_SCP_JTAG0_TDI (MTK_PIN_NO(139) | 5)
+#define PINMUX_GPIO139__FUNC_APU_JTAG_TDI (MTK_PIN_NO(139) | 6)
+#define PINMUX_GPIO139__FUNC_DBG_MON_A17 (MTK_PIN_NO(139) | 7)
+
+#define PINMUX_GPIO140__FUNC_GPIO140 (MTK_PIN_NO(140) | 0)
+#define PINMUX_GPIO140__FUNC_SPIM2_CSB (MTK_PIN_NO(140) | 1)
+#define PINMUX_GPIO140__FUNC_SPINOR_CS (MTK_PIN_NO(140) | 2)
+#define PINMUX_GPIO140__FUNC_SNFI_CS (MTK_PIN_NO(140) | 3)
+#define PINMUX_GPIO140__FUNC_DMIC3_DAT (MTK_PIN_NO(140) | 4)
+#define PINMUX_GPIO140__FUNC_DBG_MON_A11 (MTK_PIN_NO(140) | 7)
+
+#define PINMUX_GPIO141__FUNC_GPIO141 (MTK_PIN_NO(141) | 0)
+#define PINMUX_GPIO141__FUNC_SPIM2_CLK (MTK_PIN_NO(141) | 1)
+#define PINMUX_GPIO141__FUNC_SPINOR_CK (MTK_PIN_NO(141) | 2)
+#define PINMUX_GPIO141__FUNC_SNFI_CLK (MTK_PIN_NO(141) | 3)
+#define PINMUX_GPIO141__FUNC_DMIC3_CLK (MTK_PIN_NO(141) | 4)
+#define PINMUX_GPIO141__FUNC_DBG_MON_A10 (MTK_PIN_NO(141) | 7)
+
+#define PINMUX_GPIO142__FUNC_GPIO142 (MTK_PIN_NO(142) | 0)
+#define PINMUX_GPIO142__FUNC_SPIM2_MO (MTK_PIN_NO(142) | 1)
+#define PINMUX_GPIO142__FUNC_SPINOR_IO0 (MTK_PIN_NO(142) | 2)
+#define PINMUX_GPIO142__FUNC_SNFI_MOSI (MTK_PIN_NO(142) | 3)
+#define PINMUX_GPIO142__FUNC_DMIC4_DAT (MTK_PIN_NO(142) | 4)
+#define PINMUX_GPIO142__FUNC_DBG_MON_A12 (MTK_PIN_NO(142) | 7)
+
+#define PINMUX_GPIO143__FUNC_GPIO143 (MTK_PIN_NO(143) | 0)
+#define PINMUX_GPIO143__FUNC_SPIM2_MI (MTK_PIN_NO(143) | 1)
+#define PINMUX_GPIO143__FUNC_SPINOR_IO1 (MTK_PIN_NO(143) | 2)
+#define PINMUX_GPIO143__FUNC_SNFI_MISO (MTK_PIN_NO(143) | 3)
+#define PINMUX_GPIO143__FUNC_DMIC4_CLK (MTK_PIN_NO(143) | 4)
+#define PINMUX_GPIO143__FUNC_DBG_MON_A13 (MTK_PIN_NO(143) | 7)
+
+#endif /* __MT8195-PINFUNC_H */
-- 
2.18.0

From zhiyong.tao at mediatek.com  Sun Apr 11 10:26:59 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Sun, 11 Apr 2021 17:26:59 +0800
Subject: [PATCH v3 5/5] pinctrl: add rsel setting on MT8195
In-Reply-To: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
References: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
Message-ID: <20210411092659.22838-6-zhiyong.tao@mediatek.com>

This patch provides rsel setting on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index a7500e18bb1d..66608b8d346a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
 	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_rsel_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x0c0, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x0c0, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x0c0, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x0c0, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x0c0, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x0c0, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x0c0, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x0c0, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x0c0, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x0c0, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x080, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x080, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x0e0, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x0e0, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x0e0, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x0e0, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -793,6 +812,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
 	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
+	[PINCTRL_PIN_REG_RSEL] = MTK_RANGE(mt8195_pin_rsel_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -823,6 +843,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.drive_get = mtk_pinconf_drive_get_rev1,
 	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
 	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
+	.rsel_set = mtk_pinconf_rsel_set,
+	.rsel_get = mtk_pinconf_rsel_get,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 2b51f4a9b860..d1526d0c6248 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1041,6 +1041,20 @@ int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_RSEL, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_set);
+
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_RSEL, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_get);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fd5ce9c5dcbd..570e8da7bf38 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -67,6 +67,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
 	PINCTRL_PIN_REG_DRV_ADV,
+	PINCTRL_PIN_REG_RSEL,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -237,6 +238,10 @@ struct mtk_pin_soc {
 			     const struct mtk_pin_desc *desc, u32 arg);
 	int (*adv_drive_get)(struct mtk_pinctrl *hw,
 			     const struct mtk_pin_desc *desc, u32 *val);
+	int (*rsel_set)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 arg);
+	int (*rsel_get)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 *val);
 
 	/* Specific driver data */
 	void				*driver_data;
@@ -320,5 +325,10 @@ int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
 int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 				  const struct mtk_pin_desc *desc, u32 *val);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val);
+
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..967288c28232 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -22,6 +22,8 @@
 #define MTK_PIN_CONFIG_PU_ADV	(PIN_CONFIG_END + 3)
 #define MTK_PIN_CONFIG_PD_ADV	(PIN_CONFIG_END + 4)
 #define MTK_PIN_CONFIG_DRV_ADV	(PIN_CONFIG_END + 5)
+#define MTK_PIN_CONFIG_RSEL	(PIN_CONFIG_END + 6)
+
 
 static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,tdsel",	MTK_PIN_CONFIG_TDSEL,		0},
@@ -29,6 +31,7 @@ static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,pull-up-adv", MTK_PIN_CONFIG_PU_ADV,		1},
 	{"mediatek,pull-down-adv", MTK_PIN_CONFIG_PD_ADV,	1},
 	{"mediatek,drive-strength-adv", MTK_PIN_CONFIG_DRV_ADV,	2},
+	{"mediatek,rsel",		MTK_PIN_CONFIG_RSEL,	2},
 };
 
 #ifdef CONFIG_DEBUG_FS
@@ -38,6 +41,7 @@ static const struct pin_config_item mtk_conf_items[] = {
 	PCONFDUMP(MTK_PIN_CONFIG_PU_ADV, "pu-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_PD_ADV, "pd-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_DRV_ADV, "drive-strength-adv", NULL, true),
+	PCONFDUMP(MTK_PIN_CONFIG_RSEL, "rsel", NULL, true),
 };
 #endif
 
@@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_get)
+			err = hw->soc->rsel_get(hw, desc, &ret);
+		else
+			err = -EOPNOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
@@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_set)
+			err = hw->soc->rsel_set(hw, desc, arg);
+		else
+			err = -EOPNOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
-- 
2.18.0

From zhiyong.tao at mediatek.com  Sun Apr 11 10:26:58 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Sun, 11 Apr 2021 17:26:58 +0800
Subject: [PATCH v3 4/5] pinctrl: add drive for I2C related pins on MT8195
In-Reply-To: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
References: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
Message-ID: <20210411092659.22838-5-zhiyong.tao@mediatek.com>

This patch provides the advanced drive raw data setting version
for I2C used pins on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |  5 +++++
 3 files changed, 41 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index 063f164d7c9b..a7500e18bb1d 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -760,6 +760,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_range[] = {
 	PIN_FIELD_BASE(143, 143, 1, 0x020, 0x10, 24, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x020, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x020, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x020, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x020, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x020, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x020, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x020, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x020, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x020, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x020, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x020, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x020, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x040, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x040, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x040, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -773,6 +792,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8195_pin_pupd_range),
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
+	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -801,6 +821,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.bias_get_combo = mtk_pinconf_bias_get_combo,
 	.drive_set = mtk_pinconf_drive_set_rev1,
 	.drive_get = mtk_pinconf_drive_get_rev1,
+	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
+	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 72f17f26acd8..2b51f4a9b860 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1027,6 +1027,20 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get);
 
+int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_set_raw);
+
+int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index e2aae285b5fc..fd5ce9c5dcbd 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -66,6 +66,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_EN,
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
+	PINCTRL_PIN_REG_DRV_ADV,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -314,6 +315,10 @@ int mtk_pinconf_adv_drive_set(struct mtk_pinctrl *hw,
 			      const struct mtk_pin_desc *desc, u32 arg);
 int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
 			      const struct mtk_pin_desc *desc, u32 *val);
+int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 *val);
 
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
-- 
2.18.0

From zhiyong.tao at mediatek.com  Sun Apr 11 10:26:56 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Sun, 11 Apr 2021 17:26:56 +0800
Subject: [PATCH v3 2/5] arm64: dts: mt8195: add pinctrl device node
In-Reply-To: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
References: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
Message-ID: <20210411092659.22838-3-zhiyong.tao@mediatek.com>

This commit adds pinctrl device node for mt8195

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index 068fe24efd2d..48b28a9d35cc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -273,6 +273,27 @@
 			};
 		};
 
+		pio: pinctrl at 10005000 {
+			compatible = "mediatek,mt8195-pinctrl";
+			reg = <0 0x10005000 0 0x1000>,
+			      <0 0x11d10000 0 0x1000>,
+			      <0 0x11d30000 0 0x1000>,
+			      <0 0x11d40000 0 0x1000>,
+			      <0 0x11e20000 0 0x1000>,
+			      <0 0x11eb0000 0 0x1000>,
+			      <0 0x11f40000 0 0x1000>,
+			      <0 0x1000b000 0 0x1000>;
+			reg-names = "iocfg0", "iocfg_bm",
+				    "iocfg_bl", "iocfg_br", "iocfg_lm",
+				    "iocfg_rb", "iocfg_tl", "eint";
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pio 0 0 144>;
+			interrupt-controller;
+			interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH 0>;
+			#interrupt-cells = <2>;
+		};
+
 		watchdog: watchdog at 10007000 {
 			compatible = "mediatek,mt8195-wdt", "mediatek,mt6589-wdt";
 			reg = <0 0x10007000 0 0x100>;
-- 
2.18.0

From zhiyong.tao at mediatek.com  Sun Apr 11 10:26:54 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Sun, 11 Apr 2021 17:26:54 +0800
Subject: [PATCH v3 0/5] Mediatek pinctrl patch on mt8195 
Message-ID: <20210411092659.22838-1-zhiyong.tao@mediatek.com>

This series includes 5 patches:
1.add pinctrl file and inding document on mt8195.
2.add pinctrl device node on mt8195.
3.add pinctrl driver on MT8195.
4.add pinctrl drive for I2C related pins on MT8195.
5.add pinctrl rsel setting on MT8195.

Changes in patch v3:
1)change '^pins' to '-pins$'.
2)change 'state_0_node_a' to 'gpio_pin' which is defined in dts.
3)change 'state_0_node_b' to 'i2c0_pin' which is defined in dts.
4)reorder this series patches. change pinctrl file and binding document
together in one patch.

There are no changes in v1 & v2.

Zhiyong Tao (5):
  dt-bindings: pinctrl: mt8195: add pinctrl file and binding document
  arm64: dts: mt8195: add pinctrl device node
  pinctrl: add pinctrl driver on mt8195
  pinctrl: add drive for I2C related pins on MT8195
  pinctrl: add rsel setting on MT8195

 .../bindings/pinctrl/pinctrl-mt8195.yaml      |  152 ++
 arch/arm64/boot/dts/mediatek/mt8195.dtsi      |   21 +
 drivers/pinctrl/mediatek/Kconfig              |    6 +
 drivers/pinctrl/mediatek/Makefile             |    1 +
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     |  872 +++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  |   28 +
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |   15 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h | 1669 +++++++++++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      |   16 +
 include/dt-bindings/pinctrl/mt8195-pinfunc.h  |  962 ++++++++++
 10 files changed, 3742 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8195.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
 create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.h

--
2.18.0 


From brouer at redhat.com  Sun Apr 11 10:43:07 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Sun, 11 Apr 2021 11:43:07 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210410205246.507048-2-willy@infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
Message-ID: <20210411114307.5087f958@carbon>

On Sat, 10 Apr 2021 21:52:45 +0100
"Matthew Wilcox (Oracle)" <willy at infradead.org> wrote:

> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
> 
> We could fix this by telling the compiler to use a smaller alignment
> for the dma_addr, but that seems a little fragile.  Instead, move the
> 'flags' into the union.  That causes dma_addr to shift into the same
> bits as 'mapping', so it would have to be cleared on free.  To avoid
> this, insert three words of padding and use the same bits as ->index
> and ->private, neither of which have to be cleared on free.
> 
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>  include/linux/mm_types.h | 38 ++++++++++++++++++++++++++------------
>  1 file changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..45c563e9b50e 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -68,16 +68,22 @@ struct mem_cgroup;
>  #endif
>  
>  struct page {
> -	unsigned long flags;		/* Atomic flags, some possibly
> -					 * updated asynchronously */
>  	/*
> -	 * Five words (20/40 bytes) are available in this union.
> -	 * WARNING: bit 0 of the first word is used for PageTail(). That
> -	 * means the other users of this union MUST NOT use the bit to
> +	 * This union is six words (24 / 48 bytes) in size.
> +	 * The first word is reserved for atomic flags, often updated
> +	 * asynchronously.  Use the PageFoo() macros to access it.  Some
> +	 * of the flags can be reused for your own purposes, but the
> +	 * word as a whole often contains other information and overwriting
> +	 * it will cause functions like page_zone() and page_node() to stop
> +	 * working correctly.
> +	 *
> +	 * Bit 0 of the second word is used for PageTail(). That
> +	 * means the other users of this union MUST leave the bit zero to
>  	 * avoid collision and false-positive PageTail().
>  	 */
>  	union {
>  		struct {	/* Page cache and anonymous pages */
> +			unsigned long flags;
>  			/**
>  			 * @lru: Pageout list, eg. active_list protected by
>  			 * lruvec->lru_lock.  Sometimes used as a generic list
> @@ -96,13 +102,14 @@ struct page {
>  			unsigned long private;
>  		};
>  		struct {	/* page_pool used by netstack */
> -			/**
> -			 * @dma_addr: might require a 64-bit value even on
> -			 * 32-bit architectures.
> -			 */
> -			dma_addr_t dma_addr;

The original intend of placing member @dma_addr here is that it overlap
with @LRU (type struct list_head) which contains two pointers.  Thus, in
case of CONFIG_ARCH_DMA_ADDR_T_64BIT=y on 32-bit architectures it would
use both pointers.

Thinking more about this, this design is flawed as bit 0 of the first
word is used for compound pages (see PageTail and @compound_head), is
reserved.  We knew DMA addresses were aligned, thus we though this
satisfied that need.  BUT for DMA_ADDR_T_64BIT=y on 32-bit arch the
first word will contain the "upper" part of the DMA addr, which I don't
think gives this guarantee.

I guess, nobody are using this combination?!?  I though we added this
to satisfy TI (Texas Instrument) driver cpsw (code in
drivers/net/ethernet/ti/cpsw*).  Thus, I assumed it was in use?


> +			unsigned long _pp_flags;
> +			unsigned long pp_magic;
> +			unsigned long xmi;

Matteo notice, I think intent is we can store xdp_mem_info in @xmi.

> +			unsigned long _pp_mapping_pad;
> +			dma_addr_t dma_addr;	/* might be one or two words */
>  		};

Could you explain your intent here?
I worry about @index.

As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
(code copy-pasted below signature) which imply that the member @index
have to be kept intact. In above, I'm unsure @index is untouched.

[1] https://lore.kernel.org/lkml/20210410082158.79ad09a6 at carbon/
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

/*
 * Return true only if the page has been allocated with
 * ALLOC_NO_WATERMARKS and the low watermark was not
 * met implying that the system is under some pressure.
 */
static inline bool page_is_pfmemalloc(const struct page *page)
{
	/*
	 * Page index cannot be this large so this must be
	 * a pfmemalloc page.
	 */
	return page->index == -1UL;
}

/*
 * Only to be called by the page allocator on a freshly allocated
 * page.
 */
static inline void set_page_pfmemalloc(struct page *page)
{
	page->index = -1UL;
}

static inline void clear_page_pfmemalloc(struct page *page)
{
	page->index = 0;
}



From heiko at sntech.de  Sun Apr 11 10:43:57 2021
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 11 Apr 2021 11:43:57 +0200
Subject: [GIT PULL] Rockchip dts32 changes for 5.13
Message-ID: <4638723.31r3eYUQgx@phil>

Hi Arnd, Kevin, Olof,

please find below (and in the next mail) dts changes for
Rockchip platforms for 5.13.

Please pull

Thanks
Heiko

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v5.13-rockchip-dts32

for you to fetch changes up to e89db2b4c706b9ca1293e7025ef5e8730b5d1b5b:

  ARM: dts: rockchip: move rv1108 mmcx aliases to board dts files (2021-04-11 11:11:42 +0200)

----------------------------------------------------------------
MMC aliases fixups and some property/compatible cleanups.

----------------------------------------------------------------
Heiko Stuebner (2):
      ARM: dts: rockchip: move rk322x mmcx aliases to board dts files
      ARM: dts: rockchip: move rv1108 mmcx aliases to board dts files

Johan Jonker (3):
      ARM: dts: rockchip: add new watchdog compatible to rv1108.dtsi
      ARM: dts: rockchip: add new watchdog compatible to rk322x.dtsi
      ARM: dts: rockchip: remove clock-names property from watchdog node in rv1108.dtsi

 arch/arm/boot/dts/rk3228-evb.dts      | 4 ++++
 arch/arm/boot/dts/rk3229-evb.dts      | 4 ++++
 arch/arm/boot/dts/rk3229-xms6.dts     | 6 ++++++
 arch/arm/boot/dts/rk322x.dtsi         | 5 +----
 arch/arm/boot/dts/rv1108-elgin-r1.dts | 4 ++++
 arch/arm/boot/dts/rv1108-evb.dts      | 4 ++++
 arch/arm/boot/dts/rv1108.dtsi         | 6 +-----
 7 files changed, 24 insertions(+), 9 deletions(-)





From heiko at sntech.de  Sun Apr 11 10:44:27 2021
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 11 Apr 2021 11:44:27 +0200
Subject: [GIT PULL] Rockchip dts64 changes for 5.13
Message-ID: <2191862.ElGaqSPkdT@phil>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v5.13-rockchip-dts64

for you to fetch changes up to 5dcbe7e3862dfc89d219f37a9ed5e53944fa13c2:

  arm64: dts: rockchip: move mmc aliases to board dts on rk3399 (2021-04-11 11:13:07 +0200)

----------------------------------------------------------------
New board the NanoPi R4S, OPP adjustments on rk3399 (sync with vendor
and using ranged values to allow better compatibility with regulator
steps), gpu opps on px30, infrared receiver on rockpro64,
USB3 support on rk3328, MMC alias fixups, dt-compatible fixes.

----------------------------------------------------------------
Cameron Nemo (1):
      arm64: dts: rockchip: add rk3328 dwc3 usb controller node

Heiko Stuebner (9):
      arm64: dts: rockchip: synchronize rk3399 opps with vendor kernel
      arm64: dts: rockchip: used range'd gpu opps on rk3399
      arm64: dts: rockchip: drop separate opp table on rk3399-puma
      arm64: dts: rockchip: add phandle to timer0 on rk3368
      arm64: dts: rockchip: move mmc aliases to board dts on px30
      arm64: dts: rockchip: move mmc aliases to board dts on rk3308
      arm64: dts: rockchip: move mmc aliases to board dts on rk3328
      arm64: dts: rockchip: move mmc aliases to board dts on rk3368
      arm64: dts: rockchip: move mmc aliases to board dts on rk3399

Johan Jonker (5):
      arm64: dts: rockchip: enable dwc3 usb for A95X Z2
      arm64: dts: rockchip: add new watchdog compatible to px30.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3308.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3328.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3399.dtsi

Maciej Matuszczyk (1):
      arm64: dts: rockchip: Add gpu opp nodes to px30 dtsi

Thomas Schneider (1):
      arm64: dts: rockchip: add infrared receiver node to rockpro64

Tianling Shen (2):
      dt-bindings: Add doc for FriendlyARM NanoPi R4S
      rockchip: rk3399: Add support for FriendlyARM NanoPi R4S

 .../devicetree/bindings/arm/rockchip.yaml          |   1 +
 arch/arm64/boot/dts/rockchip/Makefile              |   1 +
 .../boot/dts/rockchip/px30-engicam-common.dtsi     |   5 +
 .../boot/dts/rockchip/px30-engicam-px30-core.dtsi  |   4 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts          |   6 +
 arch/arm64/boot/dts/rockchip/px30.dtsi             |  27 ++++-
 arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts     |   6 +
 arch/arm64/boot/dts/rockchip/rk3308.dtsi           |   5 +-
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts    |  11 ++
 arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3328-a1.dts         |   5 +
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts        |   6 +
 arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts     |   5 +
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts  |   5 +
 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts     |   5 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |  24 +++-
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi       |   4 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts    |   4 +
 .../arm64/boot/dts/rockchip/rk3368-lion-haikou.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi      |   4 +
 .../boot/dts/rockchip/rk3368-orion-r68-meta.dts    |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts    |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts        |   5 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi           |   5 +-
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts        |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    |   6 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |   5 +
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts |   6 +
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      |   6 +
 .../boot/dts/rockchip/rk3399-kobol-helios64.dts    |   5 +
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  |   6 +
 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts | 133 +++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |   6 +
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi       |  40 +++----
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   |   6 +
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |   6 +
 .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |  55 +--------
 .../boot/dts/rockchip/rk3399-roc-pc-mezzanine.dts  |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    |   5 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |   5 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |   6 +
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi |  19 +++
 .../dts/rockchip/rk3399-sapphire-excavator.dts     |   4 +
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  |   5 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |   5 +-
 .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |   5 +
 50 files changed, 423 insertions(+), 91 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts





From willy at infradead.org  Sun Apr 11 11:33:18 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sun, 11 Apr 2021 11:33:18 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210411114307.5087f958@carbon>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
Message-ID: <20210411103318.GC2531743@casper.infradead.org>

On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 10 Apr 2021 21:52:45 +0100
> "Matthew Wilcox (Oracle)" <willy at infradead.org> wrote:
> 
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.  When the dma_addr_t was added,
> > it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> > gap between 'flags' and the union.
> > 
> > We could fix this by telling the compiler to use a smaller alignment
> > for the dma_addr, but that seems a little fragile.  Instead, move the
> > 'flags' into the union.  That causes dma_addr to shift into the same
> > bits as 'mapping', so it would have to be cleared on free.  To avoid
> > this, insert three words of padding and use the same bits as ->index
> > and ->private, neither of which have to be cleared on free.
> > 
> > Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> > Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> > ---
> >  include/linux/mm_types.h | 38 ++++++++++++++++++++++++++------------
> >  1 file changed, 26 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 6613b26a8894..45c563e9b50e 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -68,16 +68,22 @@ struct mem_cgroup;
> >  #endif
> >  
> >  struct page {
> > -	unsigned long flags;		/* Atomic flags, some possibly
> > -					 * updated asynchronously */
> >  	/*
> > -	 * Five words (20/40 bytes) are available in this union.
> > -	 * WARNING: bit 0 of the first word is used for PageTail(). That
> > -	 * means the other users of this union MUST NOT use the bit to
> > +	 * This union is six words (24 / 48 bytes) in size.
> > +	 * The first word is reserved for atomic flags, often updated
> > +	 * asynchronously.  Use the PageFoo() macros to access it.  Some
> > +	 * of the flags can be reused for your own purposes, but the
> > +	 * word as a whole often contains other information and overwriting
> > +	 * it will cause functions like page_zone() and page_node() to stop
> > +	 * working correctly.
> > +	 *
> > +	 * Bit 0 of the second word is used for PageTail(). That
> > +	 * means the other users of this union MUST leave the bit zero to
> >  	 * avoid collision and false-positive PageTail().
> >  	 */
> >  	union {
> >  		struct {	/* Page cache and anonymous pages */
> > +			unsigned long flags;
> >  			/**
> >  			 * @lru: Pageout list, eg. active_list protected by
> >  			 * lruvec->lru_lock.  Sometimes used as a generic list
> > @@ -96,13 +102,14 @@ struct page {
> >  			unsigned long private;
> >  		};
> >  		struct {	/* page_pool used by netstack */
> > -			/**
> > -			 * @dma_addr: might require a 64-bit value even on
> > -			 * 32-bit architectures.
> > -			 */
> > -			dma_addr_t dma_addr;
> 
> The original intend of placing member @dma_addr here is that it overlap
> with @LRU (type struct list_head) which contains two pointers.  Thus, in
> case of CONFIG_ARCH_DMA_ADDR_T_64BIT=y on 32-bit architectures it would
> use both pointers.
> 
> Thinking more about this, this design is flawed as bit 0 of the first
> word is used for compound pages (see PageTail and @compound_head), is
> reserved.  We knew DMA addresses were aligned, thus we though this
> satisfied that need.  BUT for DMA_ADDR_T_64BIT=y on 32-bit arch the
> first word will contain the "upper" part of the DMA addr, which I don't
> think gives this guarantee.
> 
> I guess, nobody are using this combination?!?  I though we added this
> to satisfy TI (Texas Instrument) driver cpsw (code in
> drivers/net/ethernet/ti/cpsw*).  Thus, I assumed it was in use?

It may be in use, but we've got away with it?  It's relatively rare
that this is going to bite us.  I think what has to happen is:

page is mapped to userspace
task calls get_user_page_fast(), loads the PTE
<preempted>
page is unmapped & freed
page is reallocated to the page_pool
page is DMA mapped to an address that happens to have that bit set
<first task resumes>
task looks for the compound_head() of that PTE, and attempts to bump
the refcount.  *oops*

If it has happened, would it have turned into a bug report?
If we had seen such a bug report, would we have noticed it?

> > +			unsigned long _pp_flags;
> > +			unsigned long pp_magic;
> > +			unsigned long xmi;
> 
> Matteo notice, I think intent is we can store xdp_mem_info in @xmi.

Yep.

> > +			unsigned long _pp_mapping_pad;
> > +			dma_addr_t dma_addr;	/* might be one or two words */
> >  		};
> 
> Could you explain your intent here?
> I worry about @index.
> 
> As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> (code copy-pasted below signature) which imply that the member @index
> have to be kept intact. In above, I'm unsure @index is untouched.

Argh, I read that piece of your message, and then promptly forgot about
it.  I really don't like page_is_pfmemalloc() using the entirety of
page->index for this.  How about we just do what slab does anyway
and use PageActive for page_is_pfmemalloc()?

Basically, we have three aligned dwords here.  We can either alias with
@flags and the first word of @lru, or the second word of @lru and @mapping,
or @index and @private.  @flags is a non-starter.  If we use @mapping,
then you have to set it to NULL before you free it, and I'm not sure
how easy that will be for you.  If that's trivial, then we could use
the layout:

	unsigned long _pp_flags;
	unsigned long pp_magic;
	union {
		dma_addr_t dma_addr;    /* might be one or two words */
		unsigned long _pp_align[2];
	};
	unsigned long pp_pfmemalloc;
	unsigned long xmi;



From catalin.marinas at arm.com  Sun Apr 11 11:53:33 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Sun, 11 Apr 2021 11:53:33 +0100
Subject: [PATCH v4] kasan: remove redundant config option
In-Reply-To: <20210330223637.f3c73a78c64587e615d26766@linux-foundation.org>
References: <20210226012531.29231-1-walter-zh.wu@mediatek.com>
 <CAAeHK+zyv1=kXtKAynnJN-77dwmPG4TXpJOLv_3W0nxXe5NjXA@mail.gmail.com>
 <20210330223637.f3c73a78c64587e615d26766@linux-foundation.org>
Message-ID: <20210411105332.GA23778@arm.com>

Hi Andrew,

On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov <andreyknvl at google.com> wrote:
> > Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> > that was merged into 5.12-rc causes a build time warning:
> > 
> > include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> > defined, evaluates to 0 [-Wundef]
> > #if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > 
> > The fix for it would either be reverting the patch (which would leave
> > the initial issue unfixed) or applying this "kasan: remove redundant
> > config option" patch.
> > 
> > Would it be possible to send this patch (with the fix-up you have in
> > mm) for the next 5.12-rc?
> > 
> > Here are the required tags:
> > 
> > Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
> > Cc: stable at vger.kernel.org
> 
> Got it, thanks.  I updated the changelog to mention the warning fix and
> moved these ahead for a -rc merge.

Is there a chance this patch makes it into 5.12? I still get the warning
with the latest Linus' tree (v5.12-rc6-408-g52e44129fba5) when enabling
KASAN_HW_TAGS.

Thanks.

-- 
Catalin


From alim.akhtar at gmail.com  Sun Apr 11 13:55:58 2021
From: alim.akhtar at gmail.com (Alim Akhtar)
Date: Sun, 11 Apr 2021 18:25:58 +0530
Subject: [PATCH] iio: adc: exynos: drop unneeded variable assignment
In-Reply-To: <20210410164728.8096-1-krzysztof.kozlowski@canonical.com>
References: <20210410164728.8096-1-krzysztof.kozlowski@canonical.com>
Message-ID: <CAGOxZ51PKMZoPyk-kidGRr7zNvADfjAJG8LtMMBOi0vn-KBsLA@mail.gmail.com>

On Sat, Apr 10, 2021 at 10:18 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> The initialization of 'ret' variable in probe function is shortly after
> overwritten.  This initialization is simply not used.
>
> Addresses-Coverity: Unused value
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
Thanks Krzysztof,
Reviewed-by: Alim Akhtar <alim.akhtar at samsung.com>

>  drivers/iio/adc/exynos_adc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 784c10deeb1a..2d8e36408f0e 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -794,7 +794,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
>         struct s3c2410_ts_mach_info *pdata = dev_get_platdata(&pdev->dev);
>         struct iio_dev *indio_dev = NULL;
>         bool has_ts = false;
> -       int ret = -ENODEV;
> +       int ret;
>         int irq;
>
>         indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct exynos_adc));
> --
> 2.25.1
>


-- 
Regards,
Alim


From catalin.marinas at arm.com  Sun Apr 11 14:02:36 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Sun, 11 Apr 2021 14:02:36 +0100
Subject: [PATCH v16 0/9] arm64: ARMv8.5-A: MTE: Add async mode support
In-Reply-To: <20210318185607.GD10758@arm.com>
References: <20210315132019.33202-1-vincenzo.frascino@arm.com>
 <20210318185607.GD10758@arm.com>
Message-ID: <20210411130236.GB23778@arm.com>

On Thu, Mar 18, 2021 at 06:56:07PM +0000, Catalin Marinas wrote:
> On Mon, Mar 15, 2021 at 01:20:10PM +0000, Vincenzo Frascino wrote:
> > This patchset implements the asynchronous mode support for ARMv8.5-A
> > Memory Tagging Extension (MTE), which is a debugging feature that allows
> > to detect with the help of the architecture the C and C++ programmatic
> > memory errors like buffer overflow, use-after-free, use-after-return, etc.
> > 
> > MTE is built on top of the AArch64 v8.0 virtual address tagging TBI
> > (Top Byte Ignore) feature and allows a task to set a 4 bit tag on any
> > subset of its address space that is multiple of a 16 bytes granule. MTE
> > is based on a lock-key mechanism where the lock is the tag associated to
> > the physical memory and the key is the tag associated to the virtual
> > address.
> > When MTE is enabled and tags are set for ranges of address space of a task,
> > the PE will compare the tag related to the physical memory with the tag
> > related to the virtual address (tag check operation). Access to the memory
> > is granted only if the two tags match. In case of mismatch the PE will raise
> > an exception.
> > 
> > The exception can be handled synchronously or asynchronously. When the
> > asynchronous mode is enabled:
> >   - Upon fault the PE updates the TFSR_EL1 register.
> >   - The kernel detects the change during one of the following:
> >     - Context switching
> >     - Return to user/EL0
> >     - Kernel entry from EL1
> >     - Kernel exit to EL1
> >   - If the register has been updated by the PE the kernel clears it and
> >     reports the error.
> > 
> > The series is based on linux-next/akpm.
> 
> Andrew, could you please pick these patches up via the mm tree? They
> depend on kasan patches already queued.

Andrew, are you ok for me to queue these patches via the arm64 tree for
5.13 or you'd rather take them in the mm tree? There is a conflict with
the mm tree in lib/test_kasan.c, I think commit ce816b430b5a ("kasan:
detect false-positives in tests").

Thanks.

-- 
Catalin


From jbx6244 at gmail.com  Sun Apr 11 14:10:03 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:03 +0200
Subject: [PATCH v2 2/6] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210411131007.21757-2-jbx6244@gmail.com>

The compatible strings below are already in use in the Rockchip
dtsi files, but were somehow never added to a document, so add

"rockchip,rk3328-pwm"

"rockchip,rk3036-pwm", "rockchip,rk2928-pwm"

"rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
"rockchip,rk3399-pwm", "rockchip,rk3288-pwm"

"rockchip,px30-pwm", "rockchip,rk3328-pwm"
"rockchip,rk3308-pwm", "rockchip,rk3328-pwm"

for pwm nodes to pwm-rockchip.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V2:
  changed schema for clocks and clock-names
---
 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index 142ce85ce..5596bee70 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -14,14 +14,22 @@ properties:
     oneOf:
       - const: rockchip,rk2928-pwm
       - const: rockchip,rk3288-pwm
+      - const: rockchip,rk3328-pwm
       - const: rockchip,vop-pwm
       - items:
           - const: rockchip,rk3036-pwm
           - const: rockchip,rk2928-pwm
       - items:
           - enum:
+              - rockchip,rk3368-pwm
+              - rockchip,rk3399-pwm
               - rockchip,rv1108-pwm
           - const: rockchip,rk3288-pwm
+      - items:
+          - enum:
+              - rockchip,px30-pwm
+              - rockchip,rk3308-pwm
+          - const: rockchip,rk3328-pwm
 
   reg:
     maxItems: 1
@@ -49,6 +57,7 @@ if:
     compatible:
       contains:
         enum:
+          - rockchip,rk3328-pwm
           - rockchip,rv1108-pwm
 
 then:
-- 
2.11.0



From jbx6244 at gmail.com  Sun Apr 11 14:10:02 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:02 +0200
Subject: [PATCH v2 1/6] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
Message-ID: <20210411131007.21757-1-jbx6244@gmail.com>

Current dts files with 'pwm' nodes are manually verified.
In order to automate this process pwm-rockchip.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V2:
  changed schema for clocks and clock-names
---
 .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
 .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 91 ++++++++++++++++++++++
 2 files changed, 91 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
deleted file mode 100644
index f70956dea..000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Rockchip PWM controller
-
-Required properties:
- - compatible: should be "rockchip,<name>-pwm"
-   "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
-   "rockchip,rk3288-pwm": found on RK3288 SOC
-   "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
-   "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- - reg: physical base address and length of the controller's registers
- - clocks: See ../clock/clock-bindings.txt
-   - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
-     - There is one clock that's used both to derive the functional clock
-       for the device and as the bus clock.
-   - For newer hardware (rk3328 and future socs): specified by name
-     - "pwm": This is used to derive the functional clock.
-     - "pclk": This is the APB bus clock.
- - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this directory
-   for a description of the cell format.
-
-Example:
-
-	pwm0: pwm at 20030000 {
-		compatible = "rockchip,rk2928-pwm";
-		reg = <0x20030000 0x10>;
-		clocks = <&cru PCLK_PWM01>;
-		#pwm-cells = <2>;
-	};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
new file mode 100644
index 000000000..142ce85ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PWM controller
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    oneOf:
+      - const: rockchip,rk2928-pwm
+      - const: rockchip,rk3288-pwm
+      - const: rockchip,vop-pwm
+      - items:
+          - const: rockchip,rk3036-pwm
+          - const: rockchip,rk2928-pwm
+      - items:
+          - enum:
+              - rockchip,rv1108-pwm
+          - const: rockchip,rk3288-pwm
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    maxItems: 2
+
+  "#pwm-cells":
+    enum: [2, 3]
+    description:
+      Must be 2 (rk2928) or 3 (rk3288 and later).
+      See pwm.yaml for a description of the cell format.
+
+required:
+  - compatible
+  - reg
+  - "#pwm-cells"
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - rockchip,rv1108-pwm
+
+then:
+  properties:
+    clocks:
+      items:
+        - description: Used to derive the functional clock for the device.
+        - description: Used as the APB bus clock.
+
+    clock-names:
+      items:
+        - const: pwm
+        - const: pclk
+
+  required:
+    - clocks
+    - clock-names
+
+else:
+  properties:
+    clocks:
+      maxItems: 1
+      description:
+        Used both to derive the functional clock
+        for the device and as the bus clock.
+
+  required:
+    - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3188-cru-common.h>
+    pwm0: pwm at 20030000 {
+      compatible = "rockchip,rk2928-pwm";
+      reg = <0x20030000 0x10>;
+      clocks = <&cru PCLK_PWM01>;
+      #pwm-cells = <2>;
+    };
-- 
2.11.0



From jbx6244 at gmail.com  Sun Apr 11 14:10:04 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:04 +0200
Subject: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from
 pwm nodes rv1108.dtsi
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210411131007.21757-3-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm/boot/dts/rv1108-evb.dt.yaml:
pwm at 10280000: 'interrupts' does not match any of the regexes:
'pinctrl-[0-9]+'

"interrupts" is an undocumented property, so remove them
from pwm nodes in rv1108.dtsi.

make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rv1108.dtsi | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
index 68e2282f7..af033d4c9 100644
--- a/arch/arm/boot/dts/rv1108.dtsi
+++ b/arch/arm/boot/dts/rv1108.dtsi
@@ -217,7 +217,6 @@
 	pwm4: pwm at 10280000 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x10280000 0x10>;
-		interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -229,7 +228,6 @@
 	pwm5: pwm at 10280010 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x10280010 0x10>;
-		interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -241,7 +239,6 @@
 	pwm6: pwm at 10280020 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x10280020 0x10>;
-		interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -253,7 +250,6 @@
 	pwm7: pwm at 10280030 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x10280030 0x10>;
-		interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -391,7 +387,6 @@
 	pwm0: pwm at 20040000 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x20040000 0x10>;
-		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -403,7 +398,6 @@
 	pwm1: pwm at 20040010 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x20040010 0x10>;
-		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -415,7 +409,6 @@
 	pwm2: pwm at 20040020 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x20040020 0x10>;
-		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
@@ -427,7 +420,6 @@
 	pwm3: pwm at 20040030 {
 		compatible = "rockchip,rv1108-pwm", "rockchip,rk3288-pwm";
 		reg = <0x20040030 0x10>;
-		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM0_PMU>, <&cru PCLK_PWM0_PMU>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
-- 
2.11.0



From jbx6244 at gmail.com  Sun Apr 11 14:10:05 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:05 +0200
Subject: [PATCH v2 4/6] ARM: dts: rockchip: remove clock-names from pwm nodes
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210411131007.21757-4-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm/boot/dts/rk3036-evb.dt.yaml:
pwm at 20050030: clock-names: ['pwm'] is too short

Devices with only one pwm clock use it to both
to derive the functional clock for the device
and as the bus clock. The driver does not need
"clock-names" to get a handle, so remove them all.

make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3036.dtsi | 4 ----
 arch/arm/boot/dts/rk3288.dtsi | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 47a787a12..e24230d50 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -355,7 +355,6 @@
 		reg = <0x20050000 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		status = "disabled";
@@ -366,7 +365,6 @@
 		reg = <0x20050010 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		status = "disabled";
@@ -377,7 +375,6 @@
 		reg = <0x20050020 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		status = "disabled";
@@ -388,7 +385,6 @@
 		reg = <0x20050030 0x10>;
 		#pwm-cells = <2>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		status = "disabled";
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ea7416c31..05557ad02 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -679,7 +679,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -690,7 +689,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -701,7 +699,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -712,7 +709,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
-- 
2.11.0



From jbx6244 at gmail.com  Sun Apr 11 14:10:06 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:06 +0200
Subject: [PATCH v2 5/6] arm64: dts: rockchip: remove interrupts properties
 from pwm nodes rk3328.dtsi
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210411131007.21757-5-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm64/boot/dts/rockchip/rk3328-a1.dt.yaml: pwm at ff1b0030:
'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'

"interrupts" is an undocumented property, so remove them
from pwm nodes in rk3328.dtsi.

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index c2ca358c7..5c968b3cd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -480,7 +480,6 @@
 	pwm3: pwm at ff1b0030 {
 		compatible = "rockchip,rk3328-pwm";
 		reg = <0x0 0xff1b0030 0x0 0x10>;
-		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_PWM>, <&cru PCLK_PWM>;
 		clock-names = "pwm", "pclk";
 		pinctrl-names = "default";
-- 
2.11.0



From jbx6244 at gmail.com  Sun Apr 11 14:10:07 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 15:10:07 +0200
Subject: [PATCH v2 6/6] arm64: dts: rockchip: remove clock-names from pwm nodes
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210411131007.21757-6-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dt.yaml:
pwm at ff680030: clock-names: ['pwm'] is too short

Devices with only one pwm clock use it to both
to derive the functional clock for the device
and as the bus clock. The driver does not need
"clock-names" to get a handle, so remove them all.

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ----
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 61b0a2a90..7832e26a3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -561,7 +561,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -572,7 +571,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -581,7 +579,6 @@
 		reg = <0x0 0xff680020 0x0 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -592,7 +589,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e93a5f320..6221b027e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1185,7 +1185,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1196,7 +1195,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1207,7 +1205,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1218,7 +1215,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3a_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
-- 
2.11.0



From jic23 at kernel.org  Sun Apr 11 15:00:39 2021
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sun, 11 Apr 2021 15:00:39 +0100
Subject: [PATCH]  iio: adc: exynos: drop unneeded variable assignment
In-Reply-To: <20210410164728.8096-1-krzysztof.kozlowski@canonical.com>
References: <20210410164728.8096-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210411150039.1dcc76b8@jic23-huawei>

On Sat, 10 Apr 2021 18:47:28 +0200
Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com> wrote:

> The initialization of 'ret' variable in probe function is shortly after
> overwritten.  This initialization is simply not used.
> 
> Addresses-Coverity: Unused value
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Too late for this cycle, but I've queued it up for the next one.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to see if we missed anything.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/exynos_adc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 784c10deeb1a..2d8e36408f0e 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -794,7 +794,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
>  	struct s3c2410_ts_mach_info *pdata = dev_get_platdata(&pdev->dev);
>  	struct iio_dev *indio_dev = NULL;
>  	bool has_ts = false;
> -	int ret = -ENODEV;
> +	int ret;
>  	int irq;
>  
>  	indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct exynos_adc));



From linux at roeck-us.net  Sun Apr 11 15:02:12 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 11 Apr 2021 07:02:12 -0700
Subject: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
In-Reply-To: <ee280235-736d-1689-d324-b090c21106c9@xilinx.com>
References: <1615963949-75320-1-git-send-email-manish.narani@xilinx.com>
 <1615963949-75320-3-git-send-email-manish.narani@xilinx.com>
 <20210407214811.GA260719@roeck-us.net>
 <ee280235-736d-1689-d324-b090c21106c9@xilinx.com>
Message-ID: <82dc676c-10c7-2a45-7ab3-ecad46eab0a3@roeck-us.net>

Michal,

On 4/7/21 11:08 PM, Michal Simek wrote:
...
> It looks like that you directly created the patch. Isn't it better to
> send it yourself? Or do you want Manish to create it based on guidance
> above?
> 
-next is substantially broken all over the place. I already spend way too much
time bisecting and analyzing the failures, and making sure that the problems
are not caused by qemu (which is why I tracked down this problem in such detail).
I don't really have time to write patches and guide them through the process,
sorry.

Guenter


From richardcochran at gmail.com  Sun Apr 11 16:10:55 2021
From: richardcochran at gmail.com (Richard Cochran)
Date: Sun, 11 Apr 2021 08:10:55 -0700
Subject: [PATCH net-next v3 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210411024028.14586-1-vee.khee.wong@linux.intel.com>
References: <20210411024028.14586-1-vee.khee.wong@linux.intel.com>
Message-ID: <20210411151055.GA5719@hoboy.vegasvil.org>

On Sun, Apr 11, 2021 at 10:40:28AM +0800, Wong Vee Khee wrote:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index 60566598d644..60e17fd24aba 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -296,6 +296,13 @@ static int intel_crosststamp(ktime_t *device,
>  
>  	intel_priv = priv->plat->bsp_priv;
>  
> +	/* Both internal crosstimestamping and external triggered event
> +	 * timestamping cannot be run concurrently.
> +	 */
> +	if (priv->plat->ext_snapshot_en)
> +		return -EBUSY;
> +
> +	mutex_lock(&priv->aux_ts_lock);

Lock, then ...

>  	/* Enable Internal snapshot trigger */
>  	acr_value = readl(ptpaddr + PTP_ACR);
>  	acr_value &= ~PTP_ACR_MASK;
> @@ -321,6 +328,7 @@ static int intel_crosststamp(ktime_t *device,
>  	acr_value = readl(ptpaddr + PTP_ACR);
>  	acr_value |= PTP_ACR_ATSFC;
>  	writel(acr_value, ptpaddr + PTP_ACR);
> +	mutex_unlock(&priv->aux_ts_lock);

unlock, then ...
  
>  	/* Trigger Internal snapshot signal
>  	 * Create a rising edge by just toggle the GPO1 to low
> @@ -355,6 +363,8 @@ static int intel_crosststamp(ktime_t *device,
>  		*system = convert_art_to_tsc(art_time);
>  	}
>  
> +	/* Release the mutex */
> +	mutex_unlock(&priv->aux_ts_lock);

unlock again?  Huh?

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index c49debb62b05..abadcd8cdc41 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -239,6 +239,9 @@ struct stmmac_priv {
>  	int use_riwt;
>  	int irq_wake;
>  	spinlock_t ptp_lock;
> +	/* Mutex lock for Auxiliary Snapshots */
> +	struct mutex aux_ts_lock;

In the comment, please be specific about which data are protected.
For example:

	/* Protects auxiliary snapshot registers from concurrent access. */

> @@ -163,6 +166,43 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
>  	*ptp_time = ns;
>  }
>  
> +static void timestamp_interrupt(struct stmmac_priv *priv)
> +{
> +	struct ptp_clock_event event;
> +	unsigned long flags;
> +	u32 num_snapshot;
> +	u32 ts_status;
> +	u32 tsync_int;

Please group same types together (u32) in a one-line list.

> +	u64 ptp_time;
> +	int i;
> +
> +	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
> +
> +	if (!tsync_int)
> +		return;
> +
> +	/* Read timestamp status to clear interrupt from either external
> +	 * timestamp or start/end of PPS.
> +	 */
> +	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);

Reading this register has a side effect of clearing status?  If so,
doesn't it need protection against concurrent access?

The function, intel_crosststamp() also reads this bit.

> +	if (!priv->plat->ext_snapshot_en)
> +		return;

Doesn't this test come too late?  Setting ts_status just cleared the
bit used by the other code path.

> +	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
> +		       GMAC_TIMESTAMP_ATSNS_SHIFT;
> +
> +	for (i = 0; i < num_snapshot; i++) {
> +		spin_lock_irqsave(&priv->ptp_lock, flags);
> +		get_ptptime(priv->ptpaddr, &ptp_time);
> +		spin_unlock_irqrestore(&priv->ptp_lock, flags);
> +		event.type = PTP_CLOCK_EXTTS;
> +		event.index = 0;
> +		event.timestamp = ptp_time;
> +		ptp_clock_event(priv->ptp_clock, &event);
> +	}
> +}
> +

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> index b164ae22e35f..d668c33a0746 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> @@ -135,9 +135,13 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
>  {
>  	struct stmmac_priv *priv =
>  	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
> +	void __iomem *ptpaddr = priv->ptpaddr;
> +	void __iomem *ioaddr = priv->hw->pcsr;
>  	struct stmmac_pps_cfg *cfg;
>  	int ret = -EOPNOTSUPP;
>  	unsigned long flags;
> +	u32 intr_value;
> +	u32 acr_value;

Please group same types together.

Thanks,
Richard


From adrian.hunter at intel.com  Sun Apr 11 18:52:04 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Sun, 11 Apr 2021 20:52:04 +0300
Subject: [PATCH v17 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <1b3d53dad245a7166f3f67a4c65f3a731e6600b3.1617893198.git.asutoshd@codeaurora.org>
References: <cover.1617893198.git.asutoshd@codeaurora.org>
 <1b3d53dad245a7166f3f67a4c65f3a731e6600b3.1617893198.git.asutoshd@codeaurora.org>
Message-ID: <0e967ede-e233-8202-d638-5b1d24144192@intel.com>

On 8/04/21 5:49 pm, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes.
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

<SNIP>

> @@ -5815,14 +5857,14 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
>  
>  	hba->is_sys_suspended = false;
>  	/*
> -	 * Set RPM status of hba device to RPM_ACTIVE,
> +	 * Set RPM status of wlun device to RPM_ACTIVE,
>  	 * this also clears its runtime error.
>  	 */
> -	ret = pm_runtime_set_active(hba->dev);
> +	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);

It may be that it was hba->dev with a runtime error. So,
also need here:

	if (ret)
		ret = pm_runtime_set_active(hba->dev);


> @@ -8671,7 +8701,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  	enum ufs_dev_pwr_mode req_dev_pwr_mode;
>  	enum uic_link_state req_link_state;
>  
> -	hba->pm_op_in_progress = 1;
> +	hba->pm_op_in_progress = true;
>  	if (!ufshcd_is_shutdown_pm(pm_op)) {
>  		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
>  			 hba->rpm_lvl : hba->spm_lvl;
> @@ -8694,17 +8724,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  
>  	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
>  			req_link_state == UIC_LINK_ACTIVE_STATE) {
> -		goto disable_clks;
> +		goto enable_scaling;

Previously "goto disable_clks" would go to the vendor callback
ufshcd_vops_suspend(), but now it is skipped.


>  	}
>  
>  	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
>  	    (req_link_state == hba->uic_link_state))
> -		goto enable_gating;
> +		goto enable_scaling;
>  
>  	/* UFS device & link must be active before we enter in this function */
>  	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
>  		ret = -EINVAL;
> -		goto enable_gating;
> +		goto enable_scaling;
>  	}

<SNIP>

> +/**
> + * ufshcd_suspend - helper function for suspend operations
> + * @hba: per adapter instance
> + *
> + * This function will put disable irqs, turn off clocks
> + * and set vreg and hba-vreg in lpm mode.
> + * Also check the description of __ufshcd_wl_suspend().
> + */
> +static void ufshcd_suspend(struct ufs_hba *hba)
> +{
> +	hba->pm_op_in_progress = 1;

Seems like pm_op_in_progress wouldn't be needed in this function,
nor ufshcd_resume().

You could probably simplify the callers slighly by
putting the "if (!hbs->is_powered) return" check here and in
ufshcd_resume().

> +
> +	/*
> +	 * Disable the host irq as host controller as there won't be any
> +	 * host controller transaction expected till resume.
> +	 */
>  	ufshcd_disable_irq(hba);
>  	ufshcd_setup_clocks(hba, false);
>  	if (ufshcd_is_clkgating_allowed(hba)) {
> @@ -8948,6 +9054,43 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  		trace_ufshcd_clk_gating(dev_name(hba->dev),
>  					hba->clk_gating.state);
>  	}
> +
> +	ufshcd_vreg_set_lpm(hba);
> +	/* Put the host controller in low power mode if possible */
> +	ufshcd_hba_vreg_set_lpm(hba);
> +	hba->pm_op_in_progress = 0;
> +}
> +
> +/**
> + * ufshcd_resume - helper function for resume operations
> + * @hba: per adapter instance
> + *
> + * This function basically turns on the regulators, clocks and
> + * irqs of the hba.
> + * Also check the description of __ufshcd_wl_resume().
> + *
> + * Returns 0 for success and non-zero for failure
> + */
> +static int ufshcd_resume(struct ufs_hba *hba)
> +{
> +	int ret;
> +
> +	hba->pm_op_in_progress = 1;
> +
> +	ufshcd_hba_vreg_set_hpm(hba);
> +	ret = ufshcd_vreg_set_hpm(hba);
> +	if (ret)
> +		goto out;
> +
> +	/* Make sure clocks are enabled before accessing controller */
> +	ret = ufshcd_setup_clocks(hba, true);
> +	if (ret)
> +		goto disable_vreg;
> +
> +	/* enable the host irq as host controller would be active soon */
> +	ufshcd_enable_irq(hba);
> +	goto out;
> +
>  disable_vreg:
>  	ufshcd_vreg_set_lpm(hba);
>  out:
> @@ -8962,6 +9105,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>   * @hba: per adapter instance
>   *
>   * Check the description of ufshcd_suspend() function for more details.
> + * Also check the description of __ufshcd_wl_suspend().
>   *
>   * Returns 0 for success and non-zero for failure
>   */
> @@ -8982,21 +9126,7 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
>	if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
>	     hba->curr_dev_pwr_mode) &&
>	    (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
>	     hba->uic_link_state) &&
>  	     !hba->dev_info.b_rpm_dev_flush_capable)
>  		goto out;

The logic above can be removed.

>  
> -	if (pm_runtime_suspended(hba->dev)) {
> -		/*
> -		 * UFS device and/or UFS link low power states during runtime
> -		 * suspend seems to be different than what is expected during
> -		 * system suspend. Hence runtime resume the devic & link and
> -		 * let the system suspend low power states to take effect.
> -		 * TODO: If resume takes longer time, we might have optimize
> -		 * it in future by not resuming everything if possible.
> -		 */
> -		ret = ufshcd_runtime_resume(hba);
> -		if (ret)
> -			goto out;
> -	}

System suspend/resume and runtime suspend/resume are identical
for hba->dev, so the logic becomes:

	if (pm_runtime_suspended(hba->dev))
		goto out;

> -
> -	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
> +	ufshcd_suspend(hba);
>  out:
>  	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
>  		ktime_to_us(ktime_sub(ktime_get(), start)),
> @@ -9018,25 +9148,20 @@ EXPORT_SYMBOL(ufshcd_system_suspend);
>  
>  int ufshcd_system_resume(struct ufs_hba *hba)
>  {
> -	int ret = 0;
>  	ktime_t start = ktime_get();
>  
> -	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
> -		/*
> -		 * Let the runtime resume take care of resuming
> -		 * if runtime suspended.
> -		 */
> +	if (!hba->is_powered)

System suspend/resume and runtime suspend/resume are identical
for hba->dev, so the original logic is fine here.

>  		goto out;
>  	else
> -		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
> +		ufshcd_resume(hba);
>  out:
> -	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
> +	trace_ufshcd_system_resume(dev_name(hba->dev), 0,
>  		ktime_to_us(ktime_sub(ktime_get(), start)),
>  		hba->curr_dev_pwr_mode, hba->uic_link_state);
> -	if (!ret)
> -		hba->is_sys_suspended = false;
> +
> +	hba->is_sys_suspended = false;
>  	up(&hba->host_sem);

It seems likely that hba->host_sem down / up should be in 
ufshcd_wl_suspend() / ufshcd_wl_resume() respectively, instead
of here.

Ditto hba->is_sys_suspended

> -	return ret;
> +	return 0;
>  }
>  EXPORT_SYMBOL(ufshcd_system_resume);
>  
> @@ -9045,23 +9170,23 @@ EXPORT_SYMBOL(ufshcd_system_resume);
>   * @hba: per adapter instance
>   *
>   * Check the description of ufshcd_suspend() function for more details.
> + * Also check the description of __ufshcd_wl_suspend().
>   *
>   * Returns 0 for success and non-zero for failure
>   */
>  int ufshcd_runtime_suspend(struct ufs_hba *hba)
>  {
> -	int ret = 0;
>  	ktime_t start = ktime_get();
>  
>  	if (!hba->is_powered)
>  		goto out;
>  	else
> -		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
> +		ufshcd_suspend(hba);
>  out:
> -	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
> +	trace_ufshcd_runtime_suspend(dev_name(hba->dev), 0,
>  		ktime_to_us(ktime_sub(ktime_get(), start)),
>  		hba->curr_dev_pwr_mode, hba->uic_link_state);
> -	return ret;
> +	return 0;
>  }
>  EXPORT_SYMBOL(ufshcd_runtime_suspend);
>  
> @@ -9069,37 +9194,25 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
>   * ufshcd_runtime_resume - runtime resume routine
>   * @hba: per adapter instance
>   *
> - * This function basically brings the UFS device, UniPro link and controller
> + * This function basically brings controller
>   * to active state. Following operations are done in this function:
>   *
>   * 1. Turn on all the controller related clocks
> - * 2. Bring the UniPro link out of Hibernate state
> - * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
> - *    to active state.
> - * 4. If auto-bkops is enabled on the device, disable it.
> - *
> - * So following would be the possible power state after this function return
> - * successfully:
> - *	S1: UFS device in Active state with VCC rail ON
> - *	    UniPro link in Active state
> - *	    All the UFS/UniPro controller clocks are ON
> - *
> - * Returns 0 for success and non-zero for failure
> + * 2. Turn ON VCC rail
>   */
>  int ufshcd_runtime_resume(struct ufs_hba *hba)
>  {
> -	int ret = 0;
>  	ktime_t start = ktime_get();
>  
>  	if (!hba->is_powered)
>  		goto out;
>  	else
> -		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
> +		ufshcd_resume(hba);
>  out:
> -	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
> +	trace_ufshcd_runtime_resume(dev_name(hba->dev), 0,
>  		ktime_to_us(ktime_sub(ktime_get(), start)),
>  		hba->curr_dev_pwr_mode, hba->uic_link_state);
> -	return ret;
> +	return 0;
>  }
>  EXPORT_SYMBOL(ufshcd_runtime_resume);
>  
> @@ -9113,18 +9226,13 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
>   * ufshcd_shutdown - shutdown routine
>   * @hba: per adapter instance
>   *
> - * This function would power off both UFS device and UFS link.
> + * This function would turn off both UFS device and UFS hba
> + * regulators. It would also disable clocks.
>   *
>   * Returns 0 always to allow force shutdown even in case of errors.
>   */
>  int ufshcd_shutdown(struct ufs_hba *hba)
>  {
> -	int ret = 0;
> -
> -	down(&hba->host_sem);
> -	hba->shutting_down = true;
> -	up(&hba->host_sem);
> -
>  	if (!hba->is_powered)
>  		goto out;
>  
> @@ -9133,10 +9241,8 @@ int ufshcd_shutdown(struct ufs_hba *hba)
>  
>  	pm_runtime_get_sync(hba->dev);
>  
> -	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
> +	ufshcd_suspend(hba);
>  out:
> -	if (ret)
> -		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
>  	hba->is_powered = false;
>  	/* allow force shutdown even in case of errors */
>  	return 0;
> @@ -9150,6 +9256,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
>   */
>  void ufshcd_remove(struct ufs_hba *hba)
>  {
> +	if (hba->sdev_ufs_device)
> +		scsi_autopm_get_device(hba->sdev_ufs_device);
>  	ufs_bsg_remove(hba);
>  	ufs_sysfs_remove_nodes(hba->dev);
>  	blk_cleanup_queue(hba->tmf_queue);
> @@ -9453,15 +9561,175 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
>  }
>  EXPORT_SYMBOL_GPL(ufshcd_init);
>  
> +void ufshcd_resume_complete(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	pm_runtime_put_noidle(&hba->sdev_ufs_device->sdev_gendev);

pm_runtime_put() instead of pm_runtime_put_noidle() would be
more correct here.

> +}
> +EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
> +
> +int ufshcd_suspend_prepare(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	/*
> +	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
> +	 * are same. And it doesn't wake up the device for system-suspend
> +	 * if it's runtime suspended. But ufs doesn't follow that.
> +	 * The rpm-lvl and spm-lvl can be different in ufs.
> +	 * Force it to honor system-suspend.
> +	 */
> +	scsi_autopm_get_device(hba->sdev_ufs_device);
> +	/* Refer ufshcd_resume_complete() */
> +	pm_runtime_get_noresume(&hba->sdev_ufs_device->sdev_gendev);
> +	scsi_autopm_put_device(hba->sdev_ufs_device);

This could simply be:

	pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);

or new wrapper.

> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int ufshcd_wl_poweroff(struct device *dev)
> +{
> +	struct scsi_device *sdev = to_scsi_device(dev);
> +	struct ufs_hba *hba = shost_priv(sdev->host);
> +
> +	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
> +	return 0;
> +}
> +#endif
> +
> +static int ufshcd_wl_probe(struct device *dev)
> +{
> +	struct scsi_device *sdev = to_scsi_device(dev);
> +
> +	if (!is_device_wlun(sdev))
> +		return -ENODEV;
> +
> +	blk_pm_runtime_init(sdev->request_queue, dev);
> +	pm_runtime_set_autosuspend_delay(dev, 0);
> +	pm_runtime_allow(dev);
> +
> +	return  0;
> +}
> +
> +static int ufshcd_wl_remove(struct device *dev)
> +{
> +	pm_runtime_forbid(dev);
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops ufshcd_wl_pm_ops = {
> +#ifdef CONFIG_PM_SLEEP
> +	.suspend = ufshcd_wl_suspend,
> +	.resume = ufshcd_wl_resume,
> +	.freeze = ufshcd_wl_suspend,
> +	.thaw = ufshcd_wl_resume,
> +	.poweroff = ufshcd_wl_poweroff,
> +	.restore = ufshcd_wl_resume,
> +#endif
> +	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
> +};
> +
> +/**
> + * ufs_dev_wlun_template - describes ufs device wlun
> + * ufs-device wlun - used to send pm commands
> + * All luns are consumers of ufs-device wlun.
> + *
> + * Currently, no sd driver is present for wluns.
> + * Hence the no specific pm operations are performed.
> + * With ufs design, SSU should be sent to ufs-device wlun.
> + * Hence register a scsi driver for ufs wluns only.
> + */
> +static struct scsi_driver ufs_dev_wlun_template = {
> +	.gendrv = {
> +		.name = "ufs_device_wlun",
> +		.owner = THIS_MODULE,
> +		.probe = ufshcd_wl_probe,
> +		.remove = ufshcd_wl_remove,
> +		.pm = &ufshcd_wl_pm_ops,
> +		.shutdown = ufshcd_wl_shutdown,
> +	},
> +};
> +
> +static int ufshcd_rpmb_probe(struct device *dev)
> +{
> +	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
> +}
> +
> +static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
> +{
> +	int ret = 0;
> +
> +	if (!hba->wlun_rpmb_clr_ua)
> +		return 0;
> +	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
> +	if (!ret)
> +		hba->wlun_rpmb_clr_ua = 0;
> +	return ret;
> +}
> +
> +static int ufshcd_rpmb_runtime_resume(struct device *dev)
> +{
> +	struct ufs_hba *hba = wlun_dev_to_hba(dev);
> +
> +	if (hba->sdev_rpmb)
> +		return ufshcd_clear_rpmb_uac(hba);
> +	return 0;
> +}
> +
> +static int ufshcd_rpmb_resume(struct device *dev)
> +{
> +	struct ufs_hba *hba = wlun_dev_to_hba(dev);
> +
> +	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
> +		return ufshcd_clear_rpmb_uac(hba);
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops ufs_rpmb_pm_ops = {
> +	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
> +	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
> +};
> +
> +/**
> + * Describes the ufs rpmb wlun.
> + * Used only to send uac.
> + */
> +static struct scsi_driver ufs_rpmb_wlun_template = {
> +	.gendrv = {
> +		.name = "ufs_rpmb_wlun",
> +		.owner = THIS_MODULE,
> +		.probe = ufshcd_rpmb_probe,
> +		.pm = &ufs_rpmb_pm_ops,
> +	},
> +};
> +
>  static int __init ufshcd_core_init(void)
>  {
> +	int ret;
> +
>  	ufs_debugfs_init();
> +
> +	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
> +	if (ret) {
> +		ufs_debugfs_exit();
> +		return ret;
> +	}
> +	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
> +	if (ret) {
> +		ufs_debugfs_exit();
> +		scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
> +		return ret;
> +	}
>  	return 0;

A separated error path is preferred i.e.

	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
	if (ret)
		goto debugfs_exit;

	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
	if (ret)
		goto unregister;

  	return 0;

unregister:
	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
debugfs_exit:
	ufs_debugfs_exit();
	return ret;

>  }
>  
>  static void __exit ufshcd_core_exit(void)
>  {
>  	ufs_debugfs_exit();
> +	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
> +	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
>  }
>  
>  module_init(ufshcd_core_init);
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 5eb66a8..40436e3 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -72,6 +72,8 @@ enum ufs_event_type {
>  	UFS_EVT_LINK_STARTUP_FAIL,
>  	UFS_EVT_RESUME_ERR,
>  	UFS_EVT_SUSPEND_ERR,
> +	UFS_EVT_WL_SUSP_ERR,
> +	UFS_EVT_WL_RES_ERR,
>  
>  	/* abnormal events */
>  	UFS_EVT_DEV_RESET,
> @@ -807,6 +809,7 @@ struct ufs_hba {
>  	struct list_head clk_list_head;
>  
>  	bool wlun_dev_clr_ua;
> +	bool wlun_rpmb_clr_ua;
>  
>  	/* Number of requests aborts */
>  	int req_abort_count;
> @@ -846,6 +849,7 @@ struct ufs_hba {
>  	struct delayed_work debugfs_ee_work;
>  	u32 debugfs_ee_rate_limit_ms;
>  #endif
> +	u32 luns_avail;
>  };
>  
>  /* Returns true if clocks can be gated. Otherwise false */
> @@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
>  			     enum query_opcode desc_op);
>  
>  int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
> +int ufshcd_suspend_prepare(struct device *dev);
> +void ufshcd_resume_complete(struct device *dev);
>  
>  /* Wrapper functions for safely calling variant operations */
>  static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
> diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
> index 1cb6f1a..599739e 100644
> --- a/include/trace/events/ufs.h
> +++ b/include/trace/events/ufs.h
> @@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
>  		      int dev_state, int link_state),
>  	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
>  
> +DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
> +	     TP_PROTO(const char *dev_name, int err, s64 usecs,
> +		      int dev_state, int link_state),
> +	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
> +
> +DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
> +	     TP_PROTO(const char *dev_name, int err, s64 usecs,
> +		      int dev_state, int link_state),
> +	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
> +
> +DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
> +	     TP_PROTO(const char *dev_name, int err, s64 usecs,
> +		      int dev_state, int link_state),
> +	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
> +
> +DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
> +	     TP_PROTO(const char *dev_name, int err, s64 usecs,
> +		      int dev_state, int link_state),
> +	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
> +
>  TRACE_EVENT(ufshcd_command,
>  	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
>  		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
> 



From madvenka at linux.microsoft.com  Sun Apr 11 18:54:15 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Sun, 11 Apr 2021 12:54:15 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409225321.2czbawz6p2aquf5m@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
 <20210409223227.rvf6tfhvgnpzmabn@treble>
 <20210409225321.2czbawz6p2aquf5m@treble>
Message-ID: <1be20ada-6b52-c6e8-508c-7572c438d2b7@linux.microsoft.com>



On 4/9/21 5:53 PM, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:
>> On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote:
>>>> FWIW, over the years we've had zero issues with encoding the frame
>>>> pointer on x86.  After you save pt_regs, you encode the frame pointer to
>>>> point to it.  Ideally in the same macro so it's hard to overlook.
>>>>
>>>
>>> I had the same opinion. In fact, in my encoding scheme, I have additional
>>> checks to make absolutely sure that it is a true encoding and not stack
>>> corruption. The chances of all of those values accidentally matching are,
>>> well, null.
>>
>> Right, stack corruption -- which is already exceedingly rare -- would
>> have to be combined with a miracle or two in order to come out of the
>> whole thing marked as 'reliable' :-)
>>
>> And really, we already take a similar risk today by "trusting" the frame
>> pointer value on the stack to a certain extent.
> 
> Oh yeah, I forgot to mention some more benefits of encoding the frame
> pointer (or marking pt_regs in some other way):
> 
> a) Stack addresses can be printed properly: '%pS' for printing regs->pc
>    and '%pB' for printing call returns.
> 
>    Using '%pS' for call returns (as arm64 seems to do today) will result
>    in printing the wrong function when you have tail calls to noreturn
>    functions on the stack (which is actually quite common for calls to
>    panic(), die(), etc).
> 
>    More details:
> 
>    https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp at treble
> 
> b) Stack dumps to the console can dump the exception registers they find
>    along the way.  This is actually quite nice for debugging.
> 
> 

Great.

I am preparing version 3 taking into account comments from yourself,
Mark Rutland and Mark Brown.

Stay tuned.

Madhavan


From jbx6244 at gmail.com  Sun Apr 11 18:54:35 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sun, 11 Apr 2021 19:54:35 +0200
Subject: [PATCH v1] dt-bindings: gpio: add YAML description for rockchip,
 gpio-bank
Message-ID: <20210411175435.807-1-jbx6244@gmail.com>

Current dts files with "rockchip,gpio-bank" subnodes
are manually verified. In order to automate this process
the text that describes the compatible in rockchip,pinctrl.txt
is removed and converted to YAML in rockchip,gpio-bank.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 .../bindings/gpio/rockchip,gpio-bank.yaml          | 82 ++++++++++++++++++++++
 .../bindings/pinctrl/rockchip,pinctrl.txt          | 58 +--------------
 2 files changed, 83 insertions(+), 57 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
new file mode 100644
index 000000000..ac2479732
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip GPIO bank
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,gpio-bank
+      - rockchip,rk3188-gpio-bank0
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  gpio-controller: true
+
+  "#gpio-cells":
+    const: 2
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - gpio-controller
+  - "#gpio-cells"
+  - interrupt-controller
+  - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    pinctrl: pinctrl {
+      #address-cells = <1>;
+      #size-cells = <1>;
+      ranges;
+
+      gpio0: gpio0 at 2000a000 {
+        compatible = "rockchip,rk3188-gpio-bank0";
+        reg = <0x2000a000 0x100>;
+        interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clk_gates8 9>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        interrupt-controller;
+        #interrupt-cells = <2>;
+      };
+
+      gpio1: gpio1 at 2003c000 {
+        compatible = "rockchip,gpio-bank";
+        reg = <0x2003c000 0x100>;
+        interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clk_gates8 10>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        interrupt-controller;
+        #interrupt-cells = <2>;
+      };
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index d3eae61a3..4719a6a07 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -50,23 +50,7 @@ Deprecated properties for iomux controller:
 	 Use rockchip,grf and rockchip,pmu described above instead.
 
 Required properties for gpio sub nodes:
-  - compatible: "rockchip,gpio-bank"
-  - reg: register of the gpio bank (different than the iomux registerset)
-  - interrupts: base interrupt of the gpio bank in the interrupt controller
-  - clocks: clock that drives this bank
-  - gpio-controller: identifies the node as a gpio controller and pin bank.
-  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
-    binding is used, the amount of cells must be specified as 2. See generic
-    GPIO binding documentation for description of particular cells.
-  - interrupt-controller: identifies the controller node as interrupt-parent.
-  - #interrupt-cells: the value of this property should be 2 and the interrupt
-    cells should use the standard two-cell scheme described in
-    bindings/interrupt-controller/interrupts.txt
-
-Deprecated properties for gpio sub nodes:
-  - compatible: "rockchip,rk3188-gpio-bank0"
-  - reg: second element: separate pull register for rk3188 bank0, use
-	 rockchip,pmu described above instead
+See rockchip,gpio-bank.yaml
 
 Required properties for pin configuration node:
   - rockchip,pins: 3 integers array, represents a group of pins mux and config
@@ -127,43 +111,3 @@ uart2: serial at 20064000 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart2_xfer>;
 };
-
-Example for rk3188:
-
-	pinctrl at 20008000 {
-		compatible = "rockchip,rk3188-pinctrl";
-		rockchip,grf = <&grf>;
-		rockchip,pmu = <&pmu>;
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		gpio0: gpio0 at 2000a000 {
-			compatible = "rockchip,rk3188-gpio-bank0";
-			reg = <0x2000a000 0x100>;
-			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clk_gates8 9>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		gpio1: gpio1 at 2003c000 {
-			compatible = "rockchip,gpio-bank";
-			reg = <0x2003c000 0x100>;
-			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clk_gates8 10>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		...
-
-	};
-- 
2.11.0



From jernej.skrabec at siol.net  Sun Apr 11 19:16:24 2021
From: jernej.skrabec at siol.net (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Sun, 11 Apr 2021 20:16:24 +0200
Subject: [PATCH -next] media: sunxi: sun8i-rotate: fix PM reference leak
 in rotate_start_streaming()
In-Reply-To: <20210409064658.90493-1-xiangyang3@huawei.com>
References: <20210409064658.90493-1-xiangyang3@huawei.com>
Message-ID: <2001311.PWddzm8SjH@kista>

Dne petek, 09. april 2021 ob 08:46:58 CEST je Xiang Yang napisal(a):
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Xiang Yang <xiangyang3 at huawei.com>

Acked-by: Jernej Skrabec <jernej.skrabec at siol.net>

Best regards,
Jernej




From jernej.skrabec at siol.net  Sun Apr 11 19:18:41 2021
From: jernej.skrabec at siol.net (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Sun, 11 Apr 2021 20:18:41 +0200
Subject: [PATCH -next] media: sun8i: Fix PM reference leak in
 deinterlace_start_streaming()
In-Reply-To: <20210408133630.56299-1-lujialin4@huawei.com>
References: <20210408133630.56299-1-lujialin4@huawei.com>
Message-ID: <2184866.DZomrXFPLt@kista>

Dne ?etrtek, 08. april 2021 ob 15:36:30 CEST je Lu Jialin napisal(a):
> 
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Lu Jialin <lujialin4 at huawei.com>

Acked-by: Jernej Skrabec <jernej.skrabec at siol.net>

Best regards,
Jernej




From heiko at sntech.de  Sun Apr 11 19:55:08 2021
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 11 Apr 2021 20:55:08 +0200
Subject: [PATCH 1/7] ARM: dts: rockchip: move rk322x mmcx aliases to board
 dts files
In-Reply-To: <20210324122235.1059292-1-heiko@sntech.de>
References: <20210324122235.1059292-1-heiko@sntech.de>
Message-ID: <161816730063.114996.16784124163737635566.b4-ty@sntech.de>

On Wed, 24 Mar 2021 13:22:29 +0100, Heiko Stuebner wrote:
> As suggested by Arnd Bergmann, mmc-aliases are supposed to be
> board-specific, so move the newly added general aliases to
> the board-level on rk322x-based boards.

Applied, thanks!

[1/7] ARM: dts: rockchip: move rk322x mmcx aliases to board dts files
      commit: 23a52b0dfebf8b9ae44829c561c3d82d8b9c48e3
[2/7] ARM: dts: rockchip: move rv1108 mmcx aliases to board dts files
      commit: e89db2b4c706b9ca1293e7025ef5e8730b5d1b5b
[3/7] arm64: dts: rockchip: move mmc aliases to board dts on px30
      commit: 78b8513b763c121d0ac5ed8fef3188ea065913bb
[4/7] arm64: dts: rockchip: move mmc aliases to board dts on rk3308
      commit: 3f6c22987c0bdfb42b497e346d77b6cdaed55de3
[5/7] arm64: dts: rockchip: move mmc aliases to board dts on rk3328
      commit: 28869aa53506a12d98f6e5ff54b051400be1c2bf
[6/7] arm64: dts: rockchip: move mmc aliases to board dts on rk3368
      commit: 751a78a8bd25ac2634baa19f6f918912360fba93
[7/7] arm64: dts: rockchip: move mmc aliases to board dts on rk3399
      commit: 5dcbe7e3862dfc89d219f37a9ed5e53944fa13c2

Best regards,
-- 
Heiko Stuebner <heiko at sntech.de>


From valdis.kletnieks at vt.edu  Sun Apr 11 21:07:43 2021
From: valdis.kletnieks at vt.edu (Valdis =?utf-8?Q?Kl=c4=93tnieks?=)
Date: Sun, 11 Apr 2021 16:07:43 -0400
Subject: next-20210409 build breakage in drivers/iommu/mtk_iommu_v1.c
Message-ID: <14335.1618171663@turing-police>

This commit:

commit 8de000cf0265eaa4f63aff9f2c7a3876d2dda9b6
Author: Yong Wu <yong.wu at mediatek.com>
Date:   Fri Mar 26 11:23:36 2021 +0800

    iommu/mediatek-v1: Allow building as module

changes drivers/iommu/Kcconfig

 config MTK_IOMMU_V1
-       bool "MTK IOMMU Version 1 (M4U gen1) Support"
+       tristate "MediaTek IOMMU Version 1 (M4U gen1) Support"

Unfortunately, this doesn't actually build properly as a module, because:

  MODPOST modules-only.symvers
ERROR: modpost: "of_phandle_iterator_args" [drivers/iommu/mtk_iommu_v1.ko] undefined!
make[2]: *** [/usr/src/linux-next/scripts/Makefile.modpost:150: modules-only.symvers] Error 1

There's no EXPORT_SYMBOL and drivers/of/base.o is a built-in, so
the symbol isn't available to modules.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210411/56e17301/attachment.sig>

From akpm at linux-foundation.org  Sun Apr 11 23:03:16 2021
From: akpm at linux-foundation.org (Andrew Morton)
Date: Sun, 11 Apr 2021 15:03:16 -0700
Subject: [PATCH v4] kasan: remove redundant config option
In-Reply-To: <20210411105332.GA23778@arm.com>
References: <20210226012531.29231-1-walter-zh.wu@mediatek.com>
 <CAAeHK+zyv1=kXtKAynnJN-77dwmPG4TXpJOLv_3W0nxXe5NjXA@mail.gmail.com>
 <20210330223637.f3c73a78c64587e615d26766@linux-foundation.org>
 <20210411105332.GA23778@arm.com>
Message-ID: <20210411150316.d60aa0b5174adf2370538809@linux-foundation.org>

On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas <catalin.marinas at arm.com> wrote:

> Hi Andrew,
> 
> On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov <andreyknvl at google.com> wrote:
> > > Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> > > that was merged into 5.12-rc causes a build time warning:
> > > 
> > > include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> > > defined, evaluates to 0 [-Wundef]
> > > #if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > > 
> > > The fix for it would either be reverting the patch (which would leave
> > > the initial issue unfixed) or applying this "kasan: remove redundant
> > > config option" patch.
> > > 
> > > Would it be possible to send this patch (with the fix-up you have in
> > > mm) for the next 5.12-rc?
> > > 
> > > Here are the required tags:
> > > 
> > > Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
> > > Cc: stable at vger.kernel.org
> > 
> > Got it, thanks.  I updated the changelog to mention the warning fix and
> > moved these ahead for a -rc merge.
> 
> Is there a chance this patch makes it into 5.12? I still get the warning
> with the latest Linus' tree (v5.12-rc6-408-g52e44129fba5) when enabling
> KASAN_HW_TAGS.

Trying.   We're still awaiting a tested fix for
https://lkml.kernel.org/r/CA+fCnZf1ABrQg0dsxtoZa9zM1BSbLYq_Xbu+xi9cv8WAZxdC2g at mail.gmail.com


From willy at infradead.org  Sun Apr 11 23:35:37 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sun, 11 Apr 2021 23:35:37 +0100
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <CAK8P3a3uEGaEN-p06vFP+jwbFt3P=Bx4=aRN+kUyB4PcFPxLRg@mail.gmail.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <CAK8P3a3uEGaEN-p06vFP+jwbFt3P=Bx4=aRN+kUyB4PcFPxLRg@mail.gmail.com>
Message-ID: <20210411223537.GF2531743@casper.infradead.org>

On Sat, Apr 10, 2021 at 09:10:47PM +0200, Arnd Bergmann wrote:
> On Sat, Apr 10, 2021 at 4:44 AM Matthew Wilcox <willy at infradead.org> wrote:
> > +                       dma_addr_t dma_addr __packed;
> >                 };
> >                 struct {        /* slab, slob and slub */
> >                         union {
> >
> > but I don't know if GCC is smart enough to realise that dma_addr is now
> > on an 8 byte boundary and it can use a normal instruction to access it,
> > or whether it'll do something daft like use byte loads to access it.
> >
> > We could also do:
> >
> > +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));
> >
> > and I see pahole, at least sees this correctly:
> >
> >                 struct {
> >                         long unsigned int _page_pool_pad; /*     4     4 */
> >                         dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
> >                 } __attribute__((__packed__)) __attribute__((__aligned__(4)));
> >
> > This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
> > / dma_addr_t.  Advice, please?
> 
> I've tried out what gcc would make of this:  https://godbolt.org/z/aTEbxxbG3
> 
> struct page {
>     short a;
>     struct {
>         short b;
>         long long c __attribute__((packed, aligned(2)));
>     } __attribute__((packed));
> } __attribute__((aligned(8)));
> 
> In this structure, 'c' is clearly aligned to eight bytes, and gcc does
> realize that
> it is safe to use the 'ldrd' instruction for 32-bit arm, which is forbidden on
> struct members with less than 4 byte alignment. However, it also complains
> that passing a pointer to 'c' into a function that expects a 'long long' is not
> allowed because alignof(c) is only '2' here.
> 
> (I used 'short' here because I having a 64-bit member misaligned by four
> bytes wouldn't make a difference to the instructions on Arm, or any other
> 32-bit architecture I can think of, regardless of the ABI requirements).

So ... we could do this:

+++ b/include/linux/types.h
@@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
  * so they don't care about the size of the actual bus addresses.
  */
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
-typedef u64 dma_addr_t;
+typedef u64 __attribute__((aligned(sizeof(void *)))) dma_addr_t;
 #else
 typedef u32 dma_addr_t;
 #endif

but I'm a little scared that this might have unintended consequences.
And Jesper points out that a big-endian 64-bit dma_addr_t can impersonate
a PageTail page, and we should solve that problem while we're at it.
So I don't think we should do this, but thought I should mention it as
a possibility.


From andrew at aj.id.au  Mon Apr 12 00:00:26 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Mon, 12 Apr 2021 08:30:26 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_10/21]_ipmi:_kcs=5Fbmc:_Turn_the_driver_data-str?=
 =?UTF-8?Q?uctures_inside-out?=
In-Reply-To: <YHCqR8/nZFB1HRgX@packtop>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-10-andrew@aj.id.au> <YG/Ql9z9X/mtOSvl@packtop>
 <ea34ee69-a266-4737-8450-4695d2d0fbd4@www.fastmail.com>
 <YG/zVv4XOo1HoLd1@packtop> <YHCqR8/nZFB1HRgX@packtop>
Message-ID: <e99e2e45-7810-4a24-a519-5204acee04ea@www.fastmail.com>



On Sat, 10 Apr 2021, at 04:56, Zev Weiss wrote:
> On Fri, Apr 09, 2021 at 01:25:26AM CDT, Zev Weiss wrote:
> >On Fri, Apr 09, 2021 at 12:59:09AM CDT, Andrew Jeffery wrote:
> >>On Fri, 9 Apr 2021, at 13:27, Zev Weiss wrote:
> >>>On Fri, Mar 19, 2021 at 01:27:41AM CDT, Andrew Jeffery wrote:
> >>>>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel);
> >>>>-struct kcs_bmc *kcs_bmc_ipmi_alloc(struct device *dev, int sizeof_priv, u32 channel)
> >>>>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc);
> >>>
> >>>Errant declaration again?
> >>
> >>As previously explained.
> >>
> >
> >This one seems like a slightly different category, because...
> >
> >>>
> >>>>+int kcs_bmc_ipmi_attach_cdev(struct kcs_bmc *kcs_bmc)
> >
> >...it's immediately followed by the definition of the very same function
> >that it just declared, so I can't see how its presence or absence could
> >make any functional difference to anything.  (So perhaps I should have
> >said "redundant" instead of "errant...again".)

This is is a small hack to fend off warnings from -Wmissing-declarations.

> >
> >It's fairly trivial of course given that it's gone by the end of the
> >series, but as long as there's going to be another iteration anyway it
> >seems like we might as well tidy it up?
> >
> 
> Oh, and otherwise:
> 
> Reviewed-by: Zev Weiss <zweiss at equinix.com>

Thanks.

Andrew


From andre.przywara at arm.com  Mon Apr 12 01:08:13 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 12 Apr 2021 01:08:13 +0100
Subject: [PATCH] arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS
Message-ID: <20210412000813.13071-1-andre.przywara@arm.com>

Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

This was based on the observation that the Pine64-LTS has as "push-push"
SD card socket, and that the schematic mentions the card detect GPIO.

After having received two reports about failing SD card access with that
patch, some more research and polls on that subject revealed that there
are at least two different versions of the Pine64-LTS out there:
- On some boards (including mine) the card detect pin is "stuck" at
  high, regardless of an microSD card being inserted or not.
- On other boards the card-detect is working, but is active-high, by
  virtue of an explicit inverter circuit, as shown in the schematic.

To cover all versions of the board out there, and don't take any chances,
let's revert the introduction of the CD GPIO, and go back to the
non-removable property for the Pine64-LTS. That should avoid regressions
and should work for everyone.
The SOPine card detect has proven to be working, so let's keep that
GPIO in place.

Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
Reported-by: Michael Weiser <michael.weiser at gmx.de>
Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index e79ce49e7e6a..843338e19694 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -21,5 +21,5 @@
 };
 
 &mmc0 {
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
+	non-removable;		/* card detect is broken on some boards */
 };
-- 
2.17.5



From leo.yan at linaro.org  Mon Apr 12 01:17:27 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 08:17:27 +0800
Subject: [PATCH v3 2/6] perf arm-spe: Save clock parameters from
 TIME_CONV event
In-Reply-To: <20210410050046.5394-3-leo.yan@linaro.org>
References: <20210410050046.5394-1-leo.yan@linaro.org>
 <20210410050046.5394-3-leo.yan@linaro.org>
Message-ID: <20210412001727.GB6012@leoy-ThinkPad-X240s>

On Sat, Apr 10, 2021 at 01:00:42PM +0800, Leo Yan wrote:
> During the recording phase, "perf record" tool synthesizes event
> PERF_RECORD_TIME_CONV for the hardware clock parameters and saves the
> event into the data file.
> 
> Afterwards, when processing the data file, the event TIME_CONV will be
> processed at the very early time and is stored into session context.
> 
> This patch extracts these parameters from the session context and saves
> into the structure "spe->tc" with the type perf_tsc_conversion, so that
> the parameters are ready for conversion between clock counter and time
> stamp.
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>

[...]

> ---
>  tools/perf/util/arm-spe.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> index 2539d4baec44..b48816d5c0b4 100644
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
> @@ -26,6 +26,7 @@
>  #include "symbol.h"
>  #include "thread.h"
>  #include "thread-stack.h"
> +#include "tsc.h"
>  #include "tool.h"
>  #include "util/synthetic-events.h"
>  
> @@ -45,6 +46,8 @@ struct arm_spe {
>  	struct machine			*machine;
>  	u32				pmu_type;
>  
> +	struct perf_tsc_conversion	tc;
> +
>  	u8				timeless_decoding;
>  	u8				data_queued;
>  
> @@ -1027,6 +1030,22 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
>  	spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
>  
>  	spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
> +
> +	/*
> +	 * The synthesized event PERF_RECORD_TIME_CONV has been handled
> +	 * ahead and the parameters for hardware clock are stored in
> +	 * the session context.  Passes these parameters to the structure
> +	 * perf_tsc_conversion in "spe->tc", which is used for later
> +	 * conversion between clock counter and timestamp.
> +	 */
> +	spe->tc.time_shift = session->time_conv.time_shift;
> +	spe->tc.time_mult = session->time_conv.time_mult;
> +	spe->tc.time_zero = session->time_conv.time_zero;
> +	spe->tc.time_cycles = session->time_conv.time_cycles;
> +	spe->tc.time_mask = session->time_conv.time_mask;
> +	spe->tc.cap_user_time_zero = session->time_conv.cap_user_time_zero;
> +	spe->tc.cap_user_time_short = session->time_conv.cap_user_time_short;

As Adrain suggested, this patch also should check the size of event
PERF_RECORD_TIME_CONV for backwards-compability.   I will send a new
patch set for this.

Thanks,
Leo

>  	spe->auxtrace.process_event = arm_spe_process_event;
>  	spe->auxtrace.process_auxtrace_event = arm_spe_process_auxtrace_event;
>  	spe->auxtrace.flush_events = arm_spe_flush;
> -- 
> 2.25.1
> 


From willy at infradead.org  Mon Apr 12 02:15:32 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 12 Apr 2021 02:15:32 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210411103318.GC2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
Message-ID: <20210412011532.GG2531743@casper.infradead.org>

On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> Basically, we have three aligned dwords here.  We can either alias with
> @flags and the first word of @lru, or the second word of @lru and @mapping,
> or @index and @private.  @flags is a non-starter.  If we use @mapping,
> then you have to set it to NULL before you free it, and I'm not sure
> how easy that will be for you.  If that's trivial, then we could use
> the layout:
> 
> 	unsigned long _pp_flags;
> 	unsigned long pp_magic;
> 	union {
> 		dma_addr_t dma_addr;    /* might be one or two words */
> 		unsigned long _pp_align[2];
> 	};
> 	unsigned long pp_pfmemalloc;
> 	unsigned long xmi;

I forgot about the munmap path.  That calls zap_page_range() which calls
set_page_dirty() which calls page_mapping().  If we use page->mapping,
that's going to get interpreted as an address_space pointer.

*sigh*.  Foiled at every turn.

I'm kind of inclined towards using two (or more) bits for PageSlab as
we discussed here:

https://lore.kernel.org/linux-mm/01000163efe179fe-d6270c58-eaba-482f-a6bd-334667250ef7-000000 at email.amazonses.com/

so we have PageKAlloc that's true for PageSlab, PagePool, PageDMAPool,
PageVMalloc, PageFrag and maybe a few other kernel-internal allocations.

(see also here:)
https://lore.kernel.org/linux-mm/20180518194519.3820-18-willy at infradead.org/


From andrew at aj.id.au  Mon Apr 12 02:33:52 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Mon, 12 Apr 2021 11:03:52 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?=
 =?UTF-8?Q?vice_interface?=
In-Reply-To: <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
Message-ID: <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>

On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> >
> > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > provide a means to generate IRQs and exchange arbitrary data between a
> > BMC and its host system.
> 
> I only noticed the series after Joel asked about the DT changes on the arm
> side. One question though:
> 
> How does this related to the drivers/input/serio/ framework that also talks
> to the keyboard controller for things that are not keyboards?

I've taken a brief look and I feel they're somewhat closely related.

It's plausible that we could wrangle the code so the Aspeed and Nuvoton 
KCS drivers move under drivers/input/serio. If you squint, the i8042 
serio device driver has similarities with what the Aspeed and Nuvoton 
device drivers are providing to the KCS IPMI stack.

Both the KCS IPMI and raw chardev I've implemented in this patch need 
both read and write access to the status register (STR). serio could 
potentially expose its value through serio_interrupt() using the 
SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this 
sentence. We'd need some extra support for writing STR via the serio 
API. I'm not sure that fits into the abstraction (unless we make 
serio_write() take a flags argument?).

In that vein, the serio_raw interface is close to the functionality 
that the raw chardev provides in this patch, though again serio_raw 
lacks userspace access to STR. Flags are ignored in the ->interrupt() 
callback so all values received via ->interrupt() are exposed as data. 
The result is there's no way to take care of SERIO_OOB_DATA in the 
read() path. Given that, I think we'd have to expose an ioctl() to 
access the STR value after taking care of SERIO_OOB_DATA in 
->interrupt().

I'm not sure where that lands us.

Dmitry, any thoughts here?

> Are these
> separate communication channels on adjacent I/O ports, or does there
> need to be some arbitration?

As it stands there's no arbitration.

Cheers,

Andrew


From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 12 02:49:10 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 12 Apr 2021 10:49:10 +0900
Subject: [PATCH v3 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210410135658.pf7eg5x5bdhndxkg@pengutronix.de>
References: <20210409090709.1918021-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409090709.1918021-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <YHBUjPjEpLYF/915@orome.fritz.box>
 <20210409213455.6f25m4jyttqn75hf@toshiba.co.jp>
 <20210410135658.pf7eg5x5bdhndxkg@pengutronix.de>
Message-ID: <20210412014910.b5zo3dgpyiwmprot@toshiba.co.jp>

Hi,

On Sat, Apr 10, 2021 at 03:56:58PM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Sat, Apr 10, 2021 at 06:34:55AM +0900, Nobuhiro Iwamatsu wrote:
> > > > +static int visconti_pwm_remove(struct platform_device *pdev)
> > > > +{
> > > > +	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
> > > > +
> > > > +	return pwmchip_remove(&priv->chip);
> > > 
> > > I think Uwe would prefer this to be done separately because he's working
> > > towards removing the return value from pwmchip_remove() and if we start
> > > ignoring it in new drivers that will make life easier going forward.
> > > 
> > > So this should just be:
> > > 
> > > 	pwmchip_remove(&priv->chip);
> > > 
> > > 	return 0;
> > 
> > I understand your suggestion.
> > However, it looks like the pwmchip_remove() hasn't been updated yet.
> > I will wait for the update of pwmchip_remove.
> 
> pwmchip_remove will always return 0 since b2c200e3f2fd which is in v5.3.
> So Thierry's suggestion is safe and indeed welcome.

Sorry, I was looking at a different function.
I will fix this.

Best regards,
  Nobuhiro


From andrew at aj.id.au  Mon Apr 12 03:16:24 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Mon, 12 Apr 2021 11:46:24 +0930
Subject: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <20210401044232.9637-1-zev@bewilderbeest.net>
References: <20210401044232.9637-1-zev@bewilderbeest.net>
Message-ID: <84202973-1a94-4630-beeb-f33d044a0364@www.fastmail.com>



On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:
> This is a relatively low-cost AST2500-based Xeon E-2100/E-2200 series
> mini-ITX 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 host power control, serial console and
> KVM support, and POST code snooping.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> Reviewed-by: Joel Stanley <joel at jms.id.au>
> ---
> 
> Changes since v2:
>  - un-bungled filename in dtb-$(CONFIG_ARCH_ASPEED)
> Changes since v1:
>  - added entry to dtb-$(CONFIG_ARCH_ASPEED)
>  - added board to compatible
>  - added pinctrl properties to adc
>  - split out of mostly-unrelated patch series
> 
>  arch/arm/boot/dts/Makefile                    |   1 +
>  .../boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  | 202 ++++++++++++++++++
>  2 files changed, 203 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 8e5d4ab4e75e..c22151b50ddc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1406,6 +1406,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>  	aspeed-bmc-ampere-mtjade.dtb \
>  	aspeed-bmc-arm-centriq2400-rep.dtb \
>  	aspeed-bmc-arm-stardragon4800-rep2.dtb \
> +	aspeed-bmc-asrock-e3c246d4i.dtb \
>  	aspeed-bmc-bytedance-g220a.dtb \
>  	aspeed-bmc-facebook-cmm.dtb \
>  	aspeed-bmc-facebook-galaxy100.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts 
> b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> new file mode 100644
> index 000000000000..dcab6e78dfa4
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
> +#include <dt-bindings/i2c/i2c.h>
> +
> +/{
> +	model = "ASRock E3C246D4I BMC";
> +	compatible = "asrock,e3c246d4i-bmc", "aspeed,ast2500";
> +
> +	aliases {
> +		serial4 = &uart5;
> +	};
> +
> +	chosen {
> +		stdout-path = &uart5;
> +		bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
> +	};
> +
> +	memory at 80000000 {
> +		reg = <0x80000000 0x20000000>;
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		heartbeat {
> +			/* BMC_HB_LED_N */
> +			gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_LOW>;
> +			linux,default-trigger = "timer";
> +		};
> +
> +		system-fault {
> +			/* SYSTEM_FAULT_LED_N */
> +			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> +			panic-indicator;
> +		};
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		uid-button {
> +			label = "uid-button";
> +			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> +			linux,code = <ASPEED_GPIO(F, 1)>;
> +		};
> +	};
> +
> +	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>;
> +	};
> +};
> +
> +&fmc {
> +	status = "okay";
> +	flash at 0 {
> +		status = "okay";
> +		m25p,fast-read;
> +		label = "bmc";
> +		spi-max-frequency = <100000000>; /* 100 MHz */
> +#include "openbmc-flash-layout.dtsi"
> +	};
> +};
> +
> +&uart5 {
> +	status = "okay";
> +};
> +
> +&vuart {
> +	status = "okay";
> +	aspeed,sirq-active-high;

This should probably go away, but otherwise,

Reviewed-by: Andrew Jeffery <andrew at aj.id.au>


From jiapeng.chong at linux.alibaba.com  Mon Apr 12 03:16:21 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Mon, 12 Apr 2021 10:16:21 +0800
Subject: [PATCH] gpio: mxs: remove useless function
Message-ID: <1618193781-35329-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following gcc warning:

drivers/gpio/gpio-mxs.c:63:19: warning: kernel/sys_ni.cunused function
'is_imx28_gpio'.

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/gpio/gpio-mxs.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index dfc0c1e..524b668 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -60,11 +60,6 @@ static inline int is_imx23_gpio(struct mxs_gpio_port *port)
 	return port->devid == IMX23_GPIO;
 }
 
-static inline int is_imx28_gpio(struct mxs_gpio_port *port)
-{
-	return port->devid == IMX28_GPIO;
-}
-
 /* Note: This driver assumes 32 GPIOs are handled in one register */
 
 static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
-- 
1.8.3.1



From joel at jms.id.au  Mon Apr 12 03:20:59 2021
From: joel at jms.id.au (Joel Stanley)
Date: Mon, 12 Apr 2021 02:20:59 +0000
Subject: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <84202973-1a94-4630-beeb-f33d044a0364@www.fastmail.com>
References: <20210401044232.9637-1-zev@bewilderbeest.net>
 <84202973-1a94-4630-beeb-f33d044a0364@www.fastmail.com>
Message-ID: <CACPK8XcfuEyqGmO72taXFPARxwzLyct5__0C0CF-nyEf6Yubnw@mail.gmail.com>

On Mon, 12 Apr 2021 at 02:16, Andrew Jeffery <andrew at aj.id.au> wrote:
> On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:

> > +&vuart {
> > +     status = "okay";
> > +     aspeed,sirq-active-high;
>
> This should probably go away, but otherwise,

Zev, this has already been merged (both to mainline for v5.13 and in
openbmc), so any fixups need to come as patches on top of the existing
code.

Cheers,

Joel


From zhangshaokun at hisilicon.com  Mon Apr 12 03:22:03 2021
From: zhangshaokun at hisilicon.com (Shaokun Zhang)
Date: Mon, 12 Apr 2021 10:22:03 +0800
Subject: [RFC] KVM: arm64: Support FEAT_CCIDX
In-Reply-To: <875z0ufori.wl-maz@kernel.org>
References: <1618042597-59294-1-git-send-email-zhangshaokun@hisilicon.com>
 <875z0ufori.wl-maz@kernel.org>
Message-ID: <f605f8cd-71a4-7f4e-ffb7-7b5af738e85e@hisilicon.com>

Hi Marc,

On 2021/4/10 17:54, Marc Zyngier wrote:
> On Sat, 10 Apr 2021 09:16:37 +0100,
> Shaokun Zhang <zhangshaokun at hisilicon.com> wrote:
>>
>> CCSIDR_EL1 can be implemented as 64-bit format inferred by CCIDX field
>> in ID_AA64MMFR2_EL1. The bits of Numsets and Associativity are different
>> from the 32-bit format. Let's support this feature.
>>
>> Cc: Marc Zyngier <maz at kernel.org>
>> Cc: James Morse <james.morse at arm.com>
>> Cc: Alexandru Elisei <alexandru.elisei at arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
>> Signed-off-by: Shaokun Zhang <zhangshaokun at hisilicon.com>
>> ---
>>  arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++--------
>>  1 file changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index 52fdb9a015a4..0dc822cef20b 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -18,6 +18,7 @@
>>  
>>  #include <asm/cacheflush.h>
>>  #include <asm/cputype.h>
>> +#include <asm/cpufeature.h>
> 
> If you are going to add this (why?), at least add it in alphabetic order.

cpuid_feature_extract_unsigned_field will be used later.
It shall do in alphabetic order.

> 
>>  #include <asm/debug-monitors.h>
>>  #include <asm/esr.h>
>>  #include <asm/kvm_arm.h>
>> @@ -95,9 +96,9 @@ static u32 cache_levels;
>>  #define CSSELR_MAX 14
>>  
>>  /* Which cache CCSIDR represents depends on CSSELR value. */
>> -static u32 get_ccsidr(u32 csselr)
>> +static u64 get_ccsidr(u32 csselr)
>>  {
>> -	u32 ccsidr;
>> +	u64 ccsidr;
>>  
>>  	/* Make sure noone else changes CSSELR during this! */
>>  	local_irq_disable();
>> @@ -1275,12 +1276,16 @@ static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>  static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>  			  const struct sys_reg_desc *r)
>>  {
>> -	u32 csselr;
>> +	u32 csselr, ccidx;
>> +	u64 mmfr2;
>>  
>>  	if (p->is_write)
>>  		return write_to_read_only(vcpu, p, r);
>>  
>>  	csselr = vcpu_read_sys_reg(vcpu, CSSELR_EL1);
>> +	mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
>> +	ccidx = cpuid_feature_extract_unsigned_field(mmfr2,
>> +						     ID_AA64MMFR2_CCIDX_SHIFT);
> 
> What happens on an asymmetric system where only some of the CPUs have
> FEAT_CCIDX?

If other CPUs don't have FEAT_CCIDX, its value is 0b0000 while CCSIDR_EL1 is 32-bit format.

> 
>>  	p->regval = get_ccsidr(csselr);
>>  
>>  	/*
>> @@ -1295,8 +1300,13 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>>  	 * geometry (which is not permitted by the architecture), they would
>>  	 * only do so for virtually indexed caches.]
>>  	 */
>> -	if (!(csselr & 1)) // data or unified cache
>> -		p->regval &= ~GENMASK(27, 3);
>> +	if (!(csselr & 1)) { // data or unified cache
>> +		if (ccidx)
>> +			p->regval &= ~(GENMASK(23, 3) | GENMASK(55, 32));
>> +		else
>> +			p->regval &= ~GENMASK(27, 3);
>> +	}
>> +
>>  	return true;
>>  }
>>  
>> @@ -2521,7 +2531,7 @@ static bool is_valid_cache(u32 val)
>>  static int demux_c15_get(u64 id, void __user *uaddr)
>>  {
>>  	u32 val;
>> -	u32 __user *uval = uaddr;
>> +	u64 __user *uval = uaddr;
> 
> What? Has the user API changed while I wasn't looking? Getting CCSIDR
> can only return a 32bit quantity on AArch32. In fact, CCSIDR is
> *always* 32bit, CCIDX or not. I have no idea what you are trying to do
> here, but at best you are now corrupting 32bit of userspace.
> 

Oops, I really missed this.

>>  
>>  	/* Fail if we have unknown bits set. */
>>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
>> @@ -2545,8 +2555,9 @@ static int demux_c15_get(u64 id, void __user *uaddr)
>>  
>>  static int demux_c15_set(u64 id, void __user *uaddr)
>>  {
>> -	u32 val, newval;
>> -	u32 __user *uval = uaddr;
>> +	u32 val;
>> +	u64 newval;
>> +	u64 __user *uval = uaddr;
> 
> Same brokenness.
> 
>>  
>>  	/* Fail if we have unknown bits set. */
>>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> 
> What about CCSIDR2_EL1, which is mandatory when FEAT_CCSIDX is
> present? How about the AArch32 handling of that register? I don't
> think you have though this one through.

To be honest, AArch32 is not considered directly and I sent this only
as RFC. When I wrote some flush cache code using by set/way mode and
noticed that CCSIDR_EL1 is used here.

> 
> Another question is: why should we care at all? Why don't we drop all
> that and only implement a virtual cache topology? A VM shouldn't care
> at all about this, and we are already lying about the topology anyway.
> We could even get the VMM to set whatever stupid topology it wants for
> the sake of it (and to restore previously created VMs).

Got it,

Thanks for your detailed comments.
Shaokun

> 
> 	M.
> 


From zev at bewilderbeest.net  Mon Apr 12 03:42:39 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 21:42:39 -0500
Subject: [PATCH v3] ARM: dts: aspeed: add ASRock E3C246D4I BMC
In-Reply-To: <CACPK8XcfuEyqGmO72taXFPARxwzLyct5__0C0CF-nyEf6Yubnw@mail.gmail.com>
References: <20210401044232.9637-1-zev@bewilderbeest.net>
 <84202973-1a94-4630-beeb-f33d044a0364@www.fastmail.com>
 <CACPK8XcfuEyqGmO72taXFPARxwzLyct5__0C0CF-nyEf6Yubnw@mail.gmail.com>
Message-ID: <YHOznzolgu+j9Ruh@hatter.bewilderbeest.net>

On Sun, Apr 11, 2021 at 09:20:59PM CDT, Joel Stanley wrote:
>On Mon, 12 Apr 2021 at 02:16, Andrew Jeffery <andrew at aj.id.au> wrote:
>> On Thu, 1 Apr 2021, at 15:12, Zev Weiss wrote:
>
>> > +&vuart {
>> > +     status = "okay";
>> > +     aspeed,sirq-active-high;
>>
>> This should probably go away, but otherwise,
>
>Zev, this has already been merged (both to mainline for v5.13 and in
>openbmc), so any fixups need to come as patches on top of the existing
>code.
>

Got it, thanks -- I figured I'd wait until the DT-properties patches got 
approved & merged (I'll be sending v6 of that shortly) and then send an 
incremental update for the e3c246d4i dts to match the final form of 
those.


Zev



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 12 03:55:36 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 12 Apr 2021 11:55:36 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210410135321.oissremqropvrpd3@pengutronix.de>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
Message-ID: <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>

Hi Uwe,

Thanks for your review.

On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> just a few small details left to criticize ...
> 
> On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > new file mode 100644
> > index 000000000000..99d83f94ed86
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-visconti.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Toshiba Visconti pulse-width-modulation controller driver
> > + *
> > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > + *
> > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > + *
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pwm.h>
> > +
> > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > +
> > +#define PIPGM_PWMC_PWMACT		BIT(5)
> > +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> > +#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 *to_visconti_chip(struct pwm_chip *chip)
> > +{
> > +	return container_of(chip, struct visconti_pwm_chip, chip);
> > +}
> > +
> > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > +			      const struct pwm_state *state)
> > +{
> > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > +	u32 period, duty_cycle, pwmc0;
> > +
> > +	/*
> > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > +	 * way the hardware switches atomically from the old setting to the new.
> > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > +	 * at low level at all times.
> 
> Can you please put a paragraph analogous to the one in pwm-sifive in the
> same format. This simplified keeping an overview about the oddities of
> the various supported chips.

OK, I will check pwm-sifive's, and add.

> 
> > +	 */
> > +	if (!state->enabled) {
> > +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +		return 0;
> > +	}
> > +
> > [...]
> > +
> > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > +				   struct pwm_state *state)
> > +{
> > +	struct visconti_pwm_chip *priv = chip_to_priv(chip);
> > +	u32 period, duty, pwmc0, pwmc0_clk;
> > +
> > +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +	if (period)
> > +		state->enabled = true;
> > +	else
> > +		state->enabled = false;
> 
> If PIPGM_PCSR is 0 the hardware is still active and setting a new
> configuration completes the currently running period, right? Then I
> think having always state->enabled = true is a better match.
>
If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of
other registers are written, the values of other registers will not work
unless PIPGM_PCSR is written.

However, as a logic, if PIPGM_PCSR becomes 0, it is only
visconti_pwm_apply () in this driver,
so I think that this process should always be state-> enabled = true
as you pointed out.
I wil drop this, thanks.


> > +	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
> > +	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
> > +	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
> > +
> > +	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
> > +	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
> > +	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
> > +		state->polarity = PWM_POLARITY_INVERSED;
> > +	else
> > +		state->polarity = PWM_POLARITY_NORMAL;
> > +}
> > +
> > [...]
> > +
> > +static int visconti_pwm_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct visconti_pwm_chip *priv;
> > +	int ret;
> > +
> > +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return -ENOMEM;
> > +
> > +	priv->base = devm_platform_ioremap_resource(pdev, 0);
> > +	if (IS_ERR(priv->base))
> > +		return PTR_ERR(priv->base);
> > +
> > +	platform_set_drvdata(pdev, priv);
> > +
> > +	priv->chip.dev = dev;
> > +	priv->chip.ops = &visconti_pwm_ops;
> > +	priv->chip.npwm = 4;
> > +
> > +	ret = pwmchip_add(&priv->chip);
> > +	if (ret < 0)
> > +		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
> 
> Thierry told to have picked up my patch to add the function
> devm_pwmchip_add. I just double checked and it didn't made it into his
> for-next branch yet. When you respin this series please check if the
> patch landed in the mean time and then make use of it.
> 

OKay.

> > +	return 0;
> > +}
> 
> Best regards
> Uwe

Best regards,
  Nobuhiro



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 12 04:04:58 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 12 Apr 2021 12:04:58 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210410185222.4tfpgm2hcka26e6g@pengutronix.de>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410185222.4tfpgm2hcka26e6g@pengutronix.de>
Message-ID: <20210412030458.t2vhg4nxwyi5yp4o@toshiba.co.jp>

Hi,

On Sat, Apr 10, 2021 at 08:52:22PM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> one more comment:
> 
> On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> > +static inline struct visconti_pwm_chip *to_visconti_chip(struct pwm_chip *chip)
> 
> all functions but this one start have the common prefix "visconti_pwm_".
> I like the concept of a common prefix and so you could rename this
> function to visconti_pwm_from_chip or similar.

OK, I will change. 

> 
> Best regards
> Uwe
> 

Best regards,
  Nobuhiro


From wens at kernel.org  Mon Apr 12 04:15:35 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 12 Apr 2021 11:15:35 +0800
Subject: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties
 from pwm nodes rv1108.dtsi
In-Reply-To: <20210411131007.21757-3-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-3-jbx6244@gmail.com>
Message-ID: <CAGb2v67s7a4GARfAnROKS40kaYQpdW_qWX=HX6GU09jV9wrbXw@mail.gmail.com>

On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>
> A test with the command below gives this error:
>
> /arch/arm/boot/dts/rv1108-evb.dt.yaml:
> pwm at 10280000: 'interrupts' does not match any of the regexes:
> 'pinctrl-[0-9]+'
>
> "interrupts" is an undocumented property, so remove them
> from pwm nodes in rv1108.dtsi.
>
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

Given that the interrupts were specified, meaning they are wired up in hardware,
shouldn't the solution be to add the interrupts property to the binding instead?

After all, the device tree describes the actual hardware, not just what the
implementations need.

ChenYu


From evanbenn at chromium.org  Mon Apr 12 04:22:19 2021
From: evanbenn at chromium.org (Evan Benn)
Date: Mon, 12 Apr 2021 13:22:19 +1000
Subject: [PATCH v3] drivers/clocksource/mediatek: Ack and disable interrupts
 on suspend
Message-ID: <20210412132200.v3.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid>

Interrupts are disabled during suspend before this driver disables its
timers. ARM trusted firmware will abort suspend if the timer irq is
pending, so ack and disable the timer interrupt during suspend.

Signed-off-by: Evan Benn <evanbenn at chromium.org>
---

Changes in v3:
Move the ACK from the shutdown to the suspend function.

Changes in v2:
Remove the patch that splits the drivers into 2 files.

 drivers/clocksource/timer-mediatek.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 9318edcd8963..1ae8fee639bf 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -241,6 +241,27 @@ static void mtk_gpt_enable_irq(struct timer_of *to, u8 timer)
 	       timer_of_base(to) + GPT_IRQ_EN_REG);
 }
 
+static void mtk_gpt_resume(struct clock_event_device *clk)
+{
+	struct timer_of *to = to_timer_of(clk);
+
+	mtk_gpt_enable_irq(to, TIMER_CLK_EVT);
+}
+
+static void mtk_gpt_suspend(struct clock_event_device *clk)
+{
+	struct timer_of *to = to_timer_of(clk);
+
+	/* Disable all interrupts */
+	writel(0x0, timer_of_base(to) + GPT_IRQ_EN_REG);
+
+	/* This is called with interrupts disabled,
+	 * so we need to ack any interrupt that is pending
+	 * Or for example ATF will prevent a suspend from completing.
+	 */
+	writel(0x3f, timer_of_base(to) + GPT_IRQ_ACK_REG);
+}
+
 static struct timer_of to = {
 	.flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
 
@@ -286,6 +307,8 @@ static int __init mtk_gpt_init(struct device_node *node)
 	to.clkevt.set_state_oneshot = mtk_gpt_clkevt_shutdown;
 	to.clkevt.tick_resume = mtk_gpt_clkevt_shutdown;
 	to.clkevt.set_next_event = mtk_gpt_clkevt_next_event;
+	to.clkevt.suspend = mtk_gpt_suspend;
+	to.clkevt.resume = mtk_gpt_resume;
 	to.of_irq.handler = mtk_gpt_interrupt;
 
 	ret = timer_of_init(node, &to);
-- 
2.31.1.295.g9ea45b61b8-goog



From zev at bewilderbeest.net  Mon Apr 12 04:47:08 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 22:47:08 -0500
Subject: [PATCH v6 0/4] serial: 8250_aspeed_vuart: generalized DT properties
Message-ID: <20210412034712.16778-1-zev@bewilderbeest.net>

This series generalizes the aspeed-vuart driver's device tree
properties to cover all the attributes it currently exposes via sysfs.

The aspeed,sirq-polarity-sense property was a bit of a design mistake
in that it ties Aspeed VUART SIRQ polarity to SCU register bits that
aren't really inherently related to it; the first patch in this series
deprecates it (though we hope to eventually remove it).

The rest of the series adds two new properties, aspeed,lpc-io-reg and
aspeed,lpc-interrupts.  The latter allows describing the SIRQ polarity
(along with the interrupt number) directly, providing a simpler
replacement for aspeed,sirq-polarity-sense.

Changes since v5 [4]:
 - corrected stale DT property name in commit message
 - factored aspeed_vuart_map_irq_polarity() out of
   aspeed_vuart_probe()
 - fixed commit message subject line prefixes

Changes since v4 [3]:
 - fixed commit reference formatting in commit message

Changes since v3 [2]:
 - renamed properties to match aspeed,ast2400-kcs-bmc

Changes since v2 [0]:
 - expanded to also handle sirq number and lpc address in addition to
   sirq polarity
 - added default settings if DT properties not specified
 - refactored existing sysfs code slightly, adding range checks
 - cleaned up 'make dt_binding_check' warnings

Changes since v1 [1]:
 - deprecate and retain aspeed,sirq-polarity-sense instead of removing it
 - drop e3c246d4i dts addition from this series


[0] https://lore.kernel.org/openbmc/20210401005702.28271-1-zev at bewilderbeest.net/
[1] https://lore.kernel.org/openbmc/20210330002338.335-1-zev at bewilderbeest.net/
[2] https://lore.kernel.org/openbmc/20210402004716.15961-1-zev at bewilderbeest.net/
[3] https://lore.kernel.org/openbmc/20210402182724.20848-1-zev at bewilderbeest.net/
[4] https://lore.kernel.org/openbmc/20210408011637.5361-1-zev at bewilderbeest.net/


Zev Weiss (4):
  dt-bindings: serial: 8250: deprecate aspeed,sirq-polarity-sense
  serial: 8250_aspeed_vuart: refactor sirq and lpc address setting code
  serial: 8250_aspeed_vuart: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts DT properties
  dt-bindings: serial: 8250: add aspeed,lpc-io-reg and
    aspeed,lpc-interrupts

 .../devicetree/bindings/serial/8250.yaml      |  28 ++++-
 drivers/tty/serial/8250/8250_aspeed_vuart.c   | 102 ++++++++++++++----
 2 files changed, 109 insertions(+), 21 deletions(-)

-- 
2.31.1



From zev at bewilderbeest.net  Mon Apr 12 04:47:09 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 22:47:09 -0500
Subject: [PATCH v6 1/4] dt-bindings: serial: 8250: deprecate aspeed,
 sirq-polarity-sense
In-Reply-To: <20210412034712.16778-1-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
Message-ID: <20210412034712.16778-2-zev@bewilderbeest.net>

This property ties SIRQ polarity to SCU register bits that don't
necessarily have any direct relationship to it; the only use of it was
removed in commit c82bf6e133d3 ("ARM: aspeed: g5: Do not set sirq
polarity").

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Joel Stanley <joel at jms.id.au>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..491b9297432d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -188,6 +188,7 @@ properties:
       offset and bit number to identify how the SIRQ polarity should be
       configured. One possible data source is the LPC/eSPI mode bit. Only
       applicable to aspeed,ast2500-vuart.
+    deprecated: true
 
 required:
   - reg
-- 
2.31.1



From zev at bewilderbeest.net  Mon Apr 12 04:47:10 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 22:47:10 -0500
Subject: [PATCH v6 2/4] serial: 8250_aspeed_vuart: refactor sirq and lpc
 address setting code
In-Reply-To: <20210412034712.16778-1-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
Message-ID: <20210412034712.16778-3-zev@bewilderbeest.net>

This splits dedicated aspeed_vuart_set_{sirq,lpc_address}() functions
out of the sysfs store functions in preparation for adding DT
properties that will be poking the same registers.  While we're at it,
these functions now provide some basic bounds-checking on their
arguments.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Andrew Jeffery <andrew at aj.id.au>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++-------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index c33e02cbde93..8433f8dbb186 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -72,22 +72,31 @@ static ssize_t lpc_address_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
 }
 
+static int aspeed_vuart_set_lpc_address(struct aspeed_vuart *vuart, u32 addr)
+{
+	if (addr > U16_MAX)
+		return -EINVAL;
+
+	writeb(addr >> 8, vuart->regs + ASPEED_VUART_ADDRH);
+	writeb(addr >> 0, vuart->regs + ASPEED_VUART_ADDRL);
+
+	return 0;
+}
+
 static ssize_t lpc_address_store(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
-	unsigned long val;
+	u32 val;
 	int err;
 
-	err = kstrtoul(buf, 0, &val);
+	err = kstrtou32(buf, 0, &val);
 	if (err)
 		return err;
 
-	writeb(val >> 8, vuart->regs + ASPEED_VUART_ADDRH);
-	writeb(val >> 0, vuart->regs + ASPEED_VUART_ADDRL);
-
-	return count;
+	err = aspeed_vuart_set_lpc_address(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(lpc_address);
@@ -105,27 +114,37 @@ static ssize_t sirq_show(struct device *dev,
 	return snprintf(buf, PAGE_SIZE - 1, "%u\n", reg);
 }
 
+static int aspeed_vuart_set_sirq(struct aspeed_vuart *vuart, u32 sirq)
+{
+	u8 reg;
+
+	if (sirq > (ASPEED_VUART_GCRB_HOST_SIRQ_MASK >> ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT))
+		return -EINVAL;
+
+	sirq <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
+	sirq &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+
+	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
+	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
+	reg |= sirq;
+	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
+
+	return 0;
+}
+
 static ssize_t sirq_store(struct device *dev, struct device_attribute *attr,
 			  const char *buf, size_t count)
 {
 	struct aspeed_vuart *vuart = dev_get_drvdata(dev);
 	unsigned long val;
 	int err;
-	u8 reg;
 
 	err = kstrtoul(buf, 0, &val);
 	if (err)
 		return err;
 
-	val <<= ASPEED_VUART_GCRB_HOST_SIRQ_SHIFT;
-	val &= ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-
-	reg = readb(vuart->regs + ASPEED_VUART_GCRB);
-	reg &= ~ASPEED_VUART_GCRB_HOST_SIRQ_MASK;
-	reg |= val;
-	writeb(reg, vuart->regs + ASPEED_VUART_GCRB);
-
-	return count;
+	err = aspeed_vuart_set_sirq(vuart, val);
+	return err ? : count;
 }
 
 static DEVICE_ATTR_RW(sirq);
-- 
2.31.1



From zev at bewilderbeest.net  Mon Apr 12 04:47:11 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 22:47:11 -0500
Subject: [PATCH v6 3/4] serial: 8250_aspeed_vuart: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts DT properties
In-Reply-To: <20210412034712.16778-1-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
Message-ID: <20210412034712.16778-4-zev@bewilderbeest.net>

These allow describing all the Aspeed VUART attributes currently
available via sysfs.  aspeed,lpc-interrupts provides a replacement for
the deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---
 drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++++++++-
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 8433f8dbb186..3c239d98747f 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -28,6 +28,10 @@
 #define ASPEED_VUART_ADDRL		0x28
 #define ASPEED_VUART_ADDRH		0x2c
 
+#define ASPEED_VUART_DEFAULT_LPC_ADDR	0x3f8
+#define ASPEED_VUART_DEFAULT_SIRQ	4
+#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY	IRQ_TYPE_LEVEL_LOW
+
 struct aspeed_vuart {
 	struct device		*dev;
 	void __iomem		*regs;
@@ -386,6 +390,18 @@ static void aspeed_vuart_auto_configure_sirq_polarity(
 	aspeed_vuart_set_sirq_polarity(vuart, (value & reg_mask) == 0);
 }
 
+static int aspeed_vuart_map_irq_polarity(u32 dt)
+{
+	switch (dt) {
+	case IRQ_TYPE_LEVEL_LOW:
+		return 0;
+	case IRQ_TYPE_LEVEL_HIGH:
+		return 1;
+	default:
+		return -EINVAL;
+	}
+}
+
 static int aspeed_vuart_probe(struct platform_device *pdev)
 {
 	struct of_phandle_args sirq_polarity_sense_args;
@@ -393,8 +409,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 	struct aspeed_vuart *vuart;
 	struct device_node *np;
 	struct resource *res;
-	u32 clk, prop;
-	int rc;
+	u32 clk, prop, sirq[2];
+	int rc, sirq_polarity;
 
 	np = pdev->dev.of_node;
 
@@ -501,6 +517,37 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
 		of_node_put(sirq_polarity_sense_args.np);
 	}
 
+	rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
+	if (rc < 0)
+		prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
+
+	rc = aspeed_vuart_set_lpc_address(vuart, prop);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
+		goto err_clk_disable;
+	}
+
+	rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
+	if (rc < 0) {
+		sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
+		sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
+	}
+
+	rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
+	if (rc < 0) {
+		dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts property\n");
+		goto err_clk_disable;
+	}
+
+	sirq_polarity = aspeed_vuart_map_irq_polarity(sirq[1]);
+	if (sirq_polarity < 0) {
+		dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts property\n");
+		rc = sirq_polarity;
+		goto err_clk_disable;
+	}
+
+	aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
+
 	aspeed_vuart_set_enabled(vuart, true);
 	aspeed_vuart_set_host_tx_discard(vuart, true);
 	platform_set_drvdata(pdev, vuart);
-- 
2.31.1



From zev at bewilderbeest.net  Mon Apr 12 04:47:12 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 11 Apr 2021 22:47:12 -0500
Subject: [PATCH v6 4/4] dt-bindings: serial: 8250: add aspeed,
 lpc-io-reg and aspeed, lpc-interrupts
In-Reply-To: <20210412034712.16778-1-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
Message-ID: <20210412034712.16778-5-zev@bewilderbeest.net>

These correspond to the existing lpc_address, sirq, and sirq_polarity
sysfs attributes; the second element of aspeed,lpc-interrupts provides
a replacement for the deprecated aspeed,sirq-polarity-sense property.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/serial/8250.yaml      | 27 ++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 491b9297432d..0e82b076e199 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -12,8 +12,13 @@ maintainers:
 allOf:
   - $ref: /schemas/serial.yaml#
   - if:
-      required:
-        - aspeed,sirq-polarity-sense
+      anyOf:
+        - required:
+            - aspeed,lpc-io-reg
+        - required:
+            - aspeed,lpc-interrupts
+        - required:
+            - aspeed,sirq-polarity-sense
     then:
       properties:
         compatible:
@@ -190,6 +195,20 @@ properties:
       applicable to aspeed,ast2500-vuart.
     deprecated: true
 
+  aspeed,lpc-io-reg:
+    $ref: '/schemas/types.yaml#/definitions/uint32'
+    description: |
+      The VUART LPC address.  Only applicable to aspeed,ast2500-vuart.
+
+  aspeed,lpc-interrupts:
+    $ref: "/schemas/types.yaml#/definitions/uint32-array"
+    minItems: 2
+    maxItems: 2
+    description: |
+      A 2-cell property describing the VUART SIRQ number and SIRQ
+      polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH).  Only
+      applicable to aspeed,ast2500-vuart.
+
 required:
   - reg
   - interrupts
@@ -221,6 +240,7 @@ examples:
     };
   - |
     #include <dt-bindings/clock/aspeed-clock.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
     serial at 1e787000 {
         compatible = "aspeed,ast2500-vuart";
         reg = <0x1e787000 0x40>;
@@ -228,7 +248,8 @@ examples:
         interrupts = <8>;
         clocks = <&syscon ASPEED_CLK_APB>;
         no-loopback-test;
-        aspeed,sirq-polarity-sense = <&syscon 0x70 25>;
+        aspeed,lpc-io-reg = <0x3f8>;
+        aspeed,lpc-interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
     };
 
 ...
-- 
2.31.1



From dillon.minfei at gmail.com  Mon Apr 12 05:34:21 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Mon, 12 Apr 2021 12:34:21 +0800
Subject: [PATCH] serial: stm32: optimize spin lock usage
Message-ID: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

To avoid potential deadlock in spin_lock usage, change to use
spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
spin_lock(), spin_unlock() under handler context.

remove unused local_irq_save/restore call.

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
Was verified on stm32f469-disco board. need more test on stm32mp platform.

 drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index b3675cf25a69..c4c859b34367 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
 	struct tty_port *tport = &port->state->port;
 	struct stm32_port *stm32_port = to_stm32_port(port);
 	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
-	unsigned long c;
+	unsigned long c, flags;
 	u32 sr;
 	char flag;
 
@@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
 		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
 	}
 
-	spin_unlock(&port->lock);
+	if (threaded)
+		spin_unlock_irqrestore(&port->lock, flags);
+	else
+		spin_unlock(&port->lock);
+
 	tty_flip_buffer_push(tport);
-	spin_lock(&port->lock);
+
+	if (threaded)
+		spin_lock_irqsave(&port->lock, flags);
+	else
+		spin_lock(&port->lock);
 }
 
 static void stm32_usart_tx_dma_complete(void *arg)
@@ -489,13 +497,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
 {
 	struct uart_port *port = ptr;
 	struct stm32_port *stm32_port = to_stm32_port(port);
+	unsigned long flags;
 
-	spin_lock(&port->lock);
+	spin_lock_irqsave(&port->lock, flags);
 
 	if (stm32_port->rx_ch)
 		stm32_usart_receive_chars(port, true);
 
-	spin_unlock(&port->lock);
+	spin_unlock_irqrestore(&port->lock, flags);
 
 	return IRQ_HANDLED;
 }
@@ -1354,13 +1363,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	u32 old_cr1, new_cr1;
 	int locked = 1;
 
-	local_irq_save(flags);
 	if (port->sysrq)
 		locked = 0;
 	else if (oops_in_progress)
-		locked = spin_trylock(&port->lock);
+		locked = spin_trylock_irqsave(&port->lock, flags);
 	else
-		spin_lock(&port->lock);
+		spin_lock_irqsave(&port->lock, flags);
 
 	/* Save and disable interrupts, enable the transmitter */
 	old_cr1 = readl_relaxed(port->membase + ofs->cr1);
@@ -1374,8 +1382,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	writel_relaxed(old_cr1, port->membase + ofs->cr1);
 
 	if (locked)
-		spin_unlock(&port->lock);
-	local_irq_restore(flags);
+		spin_unlock_irqrestore(&port->lock, flags);
 }
 
 static int stm32_usart_console_setup(struct console *co, char *options)
-- 
2.7.4



From ikjn at chromium.org  Mon Apr 12 06:14:09 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Mon, 12 Apr 2021 13:14:09 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <1617958441.12105.39.camel@mhfsdcap03>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
 <CAATdQgArnkdmbZefF4h7xp6=j-wHLgdQs1K0cDv06sP4eVdHmw@mail.gmail.com>
 <1617958441.12105.39.camel@mhfsdcap03>
Message-ID: <CAATdQgCjNbUKsJYZjr5wHbXV5y-7ZZrN=URKccCv1d+S4zFiDA@mail.gmail.com>

On Fri, Apr 9, 2021 at 4:54 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
>
> On Fri, 2021-04-09 at 13:45 +0800, Ikjoon Jang wrote:
> > On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > >
> > > A dedicated wakeup irq will be used to handle runtime suspend/resume,
> > > we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> > > and attaching wakeup irq, then the suspend/resume framework will help
> > > to enable/disable wakeup irq.
> > >
> > > The runtime PM is default off since some platforms may not support it.
> > > users can enable it via power/control (set "auto") in sysfs.
> > >
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > > ---
> > >  drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
> > >  1 file changed, 124 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > > index a74764ab914a..30927f4064d4 100644
> > > --- a/drivers/usb/host/xhci-mtk.c
> > > +++ b/drivers/usb/host/xhci-mtk.c
> > > @@ -16,6 +16,7 @@
> > >  #include <linux/of.h>
> > >  #include <linux/platform_device.h>
> > >  #include <linux/pm_runtime.h>
> > > +#include <linux/pm_wakeirq.h>
> > >  #include <linux/regmap.h>
> > >  #include <linux/regulator/consumer.h>
> > >
> > > @@ -358,7 +359,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
> > >                         mtk->uwk_reg_base, mtk->uwk_vers);
> > >
> > >         return PTR_ERR_OR_ZERO(mtk->uwk);
> > > -
> > >  }
> > >
> > >  static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
> > > @@ -458,6 +458,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >         struct resource *res;
> > >         struct usb_hcd *hcd;
> > >         int ret = -ENODEV;
> > > +       int wakeup_irq;
> > >         int irq;
> > >
> > >         if (usb_disabled())
> > > @@ -485,6 +486,21 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >         if (ret)
> > >                 return ret;
> > >
> > > +       irq = platform_get_irq_byname_optional(pdev, "host");
> > > +       if (irq < 0) {
> > > +               if (irq == -EPROBE_DEFER)
> > > +                       return irq;
> > > +
> > > +               /* for backward compatibility */
> > > +               irq = platform_get_irq(pdev, 0);
> > > +               if (irq < 0)
> > > +                       return irq;
> > > +       }
> > > +
> > > +       wakeup_irq = platform_get_irq_byname_optional(pdev, "wakeup");
> > > +       if (wakeup_irq == -EPROBE_DEFER)
> > > +               return wakeup_irq;
> > > +
> > >         mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
> > >         /* optional property, ignore the error if it does not exist */
> > >         of_property_read_u32(node, "mediatek,u3p-dis-msk",
> > > @@ -496,9 +512,11 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >                 return ret;
> > >         }
> > >
> > > +       pm_runtime_set_active(dev);
> > > +       pm_runtime_use_autosuspend(dev);
> > > +       pm_runtime_set_autosuspend_delay(dev, 4000);
> > >         pm_runtime_enable(dev);
> > >         pm_runtime_get_sync(dev);
> > > -       device_enable_async_suspend(dev);
> > >
> > >         ret = xhci_mtk_ldos_enable(mtk);
> > >         if (ret)
> > > @@ -508,12 +526,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >         if (ret)
> > >                 goto disable_ldos;
> > >
> > > -       irq = platform_get_irq(pdev, 0);
> > > -       if (irq < 0) {
> > > -               ret = irq;
> > > -               goto disable_clk;
> > > -       }
> > > -
> > >         hcd = usb_create_hcd(driver, dev, dev_name(dev));
> > >         if (!hcd) {
> > >                 ret = -ENOMEM;
> > > @@ -579,8 +591,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >         if (ret)
> > >                 goto dealloc_usb2_hcd;
> > >
> > > +       if (wakeup_irq > 0) {
> > > +               ret = dev_pm_set_dedicated_wake_irq(dev, wakeup_irq);
> > > +               if (ret) {
> > > +                       dev_err(dev, "set wakeup irq %d failed\n", wakeup_irq);
> > > +                       goto dealloc_usb3_hcd;
> > > +               }
> > > +               dev_info(dev, "wakeup irq %d\n", wakeup_irq);
> > > +       }
> > > +
> > > +       device_enable_async_suspend(dev);
> > > +       pm_runtime_mark_last_busy(dev);
> > > +       pm_runtime_put_autosuspend(dev);
> > > +       pm_runtime_forbid(dev);
> > > +
> > >         return 0;
> > >
> > > +dealloc_usb3_hcd:
> > > +       usb_remove_hcd(xhci->shared_hcd);
> > > +       xhci->shared_hcd = NULL;
> > > +
> > >  dealloc_usb2_hcd:
> > >         usb_remove_hcd(hcd);
> > >
> > > @@ -601,25 +631,26 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> > >         xhci_mtk_ldos_disable(mtk);
> > >
> > >  disable_pm:
> > > -       pm_runtime_put_sync(dev);
> > > +       pm_runtime_put_sync_autosuspend(dev);
> > >         pm_runtime_disable(dev);
> > >         return ret;
> > >  }
> > >
> > > -static int xhci_mtk_remove(struct platform_device *dev)
> > > +static int xhci_mtk_remove(struct platform_device *pdev)
> > >  {
> > > -       struct xhci_hcd_mtk *mtk = platform_get_drvdata(dev);
> > > +       struct xhci_hcd_mtk *mtk = platform_get_drvdata(pdev);
> > >         struct usb_hcd  *hcd = mtk->hcd;
> > >         struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > >         struct usb_hcd  *shared_hcd = xhci->shared_hcd;
> > > +       struct device *dev = &pdev->dev;
> > >
> > > -       pm_runtime_put_noidle(&dev->dev);
> > > -       pm_runtime_disable(&dev->dev);
> > > +       pm_runtime_get_sync(dev);
> > > +       xhci->xhc_state |= XHCI_STATE_REMOVING;
> > > +       dev_pm_clear_wake_irq(dev);
> > > +       device_init_wakeup(dev, false);
> > >
> > >         usb_remove_hcd(shared_hcd);
> > >         xhci->shared_hcd = NULL;
> > > -       device_init_wakeup(&dev->dev, false);
> > > -
> > >         usb_remove_hcd(hcd);
> > >         usb_put_hcd(shared_hcd);
> > >         usb_put_hcd(hcd);
> > > @@ -627,6 +658,10 @@ static int xhci_mtk_remove(struct platform_device *dev)
> > >         xhci_mtk_clks_disable(mtk);
> > >         xhci_mtk_ldos_disable(mtk);
> > >
> > > +       pm_runtime_disable(dev);
> > > +       pm_runtime_put_noidle(dev);
> > > +       pm_runtime_set_suspended(dev);
> > > +
> > >         return 0;
> > >  }
> > >
> > > @@ -690,10 +725,83 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
> > >         return ret;
> > >  }
> > >
> > > +static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
> > > +{
> > > +       u32 suspended_ports;
> > > +       u32 status;
> > > +       int num_ports;
> > > +       int i;
> > > +
> > > +       num_ports = rhub->num_ports;
> > > +       suspended_ports = rhub->bus_state.suspended_ports;
> > > +       for (i = 0; i < num_ports; i++) {
> > > +               if (!(suspended_ports & BIT(i))) {
> > > +                       status = readl(rhub->ports[i]->addr);
> > > +                       if (status & PORT_CONNECT)
> >
> > So this pm_runtime support is activated only when there's no devices
> > connected at all?
> No, if the connected devices also support runtime suspend, it will enter
> suspend mode when no data transfer, then the controller can enter
> suspend too
> > I think this will always return -EBUSY with my board having an on-board hub
> > connected to both rhubs.
> the on-board hub supports runtime suspend by default, so if no devices
> connected, it will enter suspend

Sorry, you're correct. I was confused that the condition was
(suspended && connect)
My on-board hub connected to rhub is always in a suspended state
whenever it's called.

However, I don't think this could return -EBUSY
rpm_suspend() only be called when all the descendants are in sleep already.
Did you see any cases of this function returning -EBUSY or any concerns on here?


>
> >
> > > +                               return -EBUSY;
> > > +               }
> > > +       }
> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +/*
> > > + * check the bus whether it could suspend or not
> > > + * the bus will suspend if the downstream ports are already suspended,
> > > + * or no devices connected.
> > > + */
> > > +static int check_bus_status(struct xhci_hcd *xhci)
> > > +{
> > > +       int ret;
> > > +
> > > +       ret = check_rhub_status(xhci, &xhci->usb3_rhub);
> > > +       if (ret)
> > > +               return ret;
> > > +
> > > +       return check_rhub_status(xhci, &xhci->usb2_rhub);
> > > +}
> > > +
> > > +static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
> > > +{
> > > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > > +       int ret = 0;
> > > +
> > > +       if (xhci->xhc_state)
> > > +               return -ESHUTDOWN;
> > > +
> > > +       if (device_may_wakeup(dev)) {
> > > +               ret = check_bus_status(xhci);
> > > +               if (!ret)
> > > +                       ret = xhci_mtk_suspend(dev);
> > > +       }
> > > +
> > > +       /* -EBUSY: let PM automatically reschedule another autosuspend */
> > > +       return ret ? -EBUSY : 0;
> > > +}
> > > +
> > > +static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
> > > +{
> > > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > > +       int ret = 0;
> > > +
> > > +       if (xhci->xhc_state)
> > > +               return -ESHUTDOWN;
> > > +
> > > +       if (device_may_wakeup(dev))
> > > +               ret = xhci_mtk_resume(dev);
> > > +
> > > +       return ret;
> > > +}
> > > +
> > >  static const struct dev_pm_ops xhci_mtk_pm_ops = {
> > >         SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
> > > +       SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
> > > +                          xhci_mtk_runtime_resume, NULL)
> > >  };
> > > -#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
> > > +
> > > +#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
> > >
> > >  static const struct of_device_id mtk_xhci_of_match[] = {
> > >         { .compatible = "mediatek,mt8173-xhci"},
> > > --
> > > 2.18.0
> > >
>


From gregkh at linuxfoundation.org  Mon Apr 12 06:52:24 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 12 Apr 2021 07:52:24 +0200
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <YHPgGI6EmTzmVH7g@kroah.com>

On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> To avoid potential deadlock in spin_lock usage, change to use
> spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
> spin_lock(), spin_unlock() under handler context.
> 
> remove unused local_irq_save/restore call.
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> Was verified on stm32f469-disco board. need more test on stm32mp platform.
> 
>  drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> index b3675cf25a69..c4c859b34367 100644
> --- a/drivers/tty/serial/stm32-usart.c
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>  	struct tty_port *tport = &port->state->port;
>  	struct stm32_port *stm32_port = to_stm32_port(port);
>  	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> -	unsigned long c;
> +	unsigned long c, flags;
>  	u32 sr;
>  	char flag;
>  
> @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>  		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>  	}
>  
> -	spin_unlock(&port->lock);
> +	if (threaded)
> +		spin_unlock_irqrestore(&port->lock, flags);
> +	else
> +		spin_unlock(&port->lock);

You shouldn't have to check for this, see the other patches on the list
recently that fixed this up to not be an issue for irq handlers.

thanks,

greg k-h


From wens at csie.org  Mon Apr 12 07:20:41 2021
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 12 Apr 2021 14:20:41 +0800
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <20210412000813.13071-1-andre.przywara@arm.com>
References: <20210412000813.13071-1-andre.przywara@arm.com>
Message-ID: <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>

Hi,

On Mon, Apr 12, 2021 at 8:08 AM Andre Przywara <andre.przywara at arm.com> wrote:
>
> Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
> SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
> along the way with the Pine64-LTS, which share the same base .dtsi.
>
> This was based on the observation that the Pine64-LTS has as "push-push"
> SD card socket, and that the schematic mentions the card detect GPIO.
>
> After having received two reports about failing SD card access with that
> patch, some more research and polls on that subject revealed that there
> are at least two different versions of the Pine64-LTS out there:
> - On some boards (including mine) the card detect pin is "stuck" at
>   high, regardless of an microSD card being inserted or not.
> - On other boards the card-detect is working, but is active-high, by
>   virtue of an explicit inverter circuit, as shown in the schematic.
>
> To cover all versions of the board out there, and don't take any chances,
> let's revert the introduction of the CD GPIO, and go back to the
> non-removable property for the Pine64-LTS. That should avoid regressions
> and should work for everyone.
> The SOPine card detect has proven to be working, so let's keep that
> GPIO in place.
>
> Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
> Reported-by: Michael Weiser <michael.weiser at gmx.de>
> Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> index e79ce49e7e6a..843338e19694 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> @@ -21,5 +21,5 @@
>  };
>
>  &mmc0 {
> -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> +       non-removable;          /* card detect is broken on some boards */

So a revert is good, but has anyone tried using the "broken-cd" instead?
That way, at least on Linux, the mmc core resorts to polling for a card.
At least this way the card is still removable.


ChenYu


From primoz.fiser at norik.com  Mon Apr 12 07:24:49 2021
From: primoz.fiser at norik.com (Primoz Fiser)
Date: Mon, 12 Apr 2021 08:24:49 +0200
Subject: [PATCH] ARM: dts: imx6: phyFLEX: Fix UART hardware flow control
Message-ID: <20210412062450.1430199-1-primoz.fiser@norik.com>

Serial interface uart3 on phyFLEX board is capable of 5-wire connection
including signals RTS and CTS for hardware flow control.

Fix signals UART3_CTS_B and UART3_RTS_B padmux assignments and add
missing property "uart-has-rtscts" to allow serial interface to be
configured and used with the hardware flow control.

Signed-off-by: Primoz Fiser <primoz.fiser at norik.com>
---
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index f28a96fcf23e..3f262e8ebf7f 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -316,8 +316,8 @@ pinctrl_uart3: uart3grp {
 			fsl,pins = <
 				MX6QDL_PAD_EIM_D24__UART3_TX_DATA	0x1b0b1
 				MX6QDL_PAD_EIM_D25__UART3_RX_DATA	0x1b0b1
-				MX6QDL_PAD_EIM_D30__UART3_RTS_B		0x1b0b1
-				MX6QDL_PAD_EIM_D31__UART3_CTS_B		0x1b0b1
+				MX6QDL_PAD_EIM_D31__UART3_RTS_B		0x1b0b1
+				MX6QDL_PAD_EIM_D30__UART3_CTS_B		0x1b0b1
 			>;
 		};
 
@@ -404,6 +404,7 @@ &reg_soc {
 &uart3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart3>;
+	uart-has-rtscts;
 	status = "disabled";
 };
 
-- 
2.25.1



From primoz.fiser at norik.com  Mon Apr 12 07:24:50 2021
From: primoz.fiser at norik.com (Primoz Fiser)
Date: Mon, 12 Apr 2021 08:24:50 +0200
Subject: [PATCH] ARM: dts: imx6: phyFLEX: Fix UART hardware flow control
In-Reply-To: <20210412062450.1430199-1-primoz.fiser@norik.com>
References: <20210412062450.1430199-1-primoz.fiser@norik.com>
Message-ID: <20210412062450.1430199-2-primoz.fiser@norik.com>

Serial interface uart3 on phyFLEX board is capable of 5-wire connection
including signals RTS and CTS for hardware flow control.

Fix signals UART3_CTS_B and UART3_RTS_B padmux assignments and add
missing property "uart-has-rtscts" to allow serial interface to be
configured and used with the hardware flow control.

Signed-off-by: Primoz Fiser <primoz.fiser at norik.com>
---
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index f28a96fcf23e..3f262e8ebf7f 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -316,8 +316,8 @@ pinctrl_uart3: uart3grp {
 			fsl,pins = <
 				MX6QDL_PAD_EIM_D24__UART3_TX_DATA	0x1b0b1
 				MX6QDL_PAD_EIM_D25__UART3_RX_DATA	0x1b0b1
-				MX6QDL_PAD_EIM_D30__UART3_RTS_B		0x1b0b1
-				MX6QDL_PAD_EIM_D31__UART3_CTS_B		0x1b0b1
+				MX6QDL_PAD_EIM_D31__UART3_RTS_B		0x1b0b1
+				MX6QDL_PAD_EIM_D30__UART3_CTS_B		0x1b0b1
 			>;
 		};
 
@@ -404,6 +404,7 @@ &reg_soc {
 &uart3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart3>;
+	uart-has-rtscts;
 	status = "disabled";
 };
 
-- 
2.25.1



From alexander.sverdlin at nokia.com  Mon Apr 12 07:28:19 2021
From: alexander.sverdlin at nokia.com (Alexander Sverdlin)
Date: Mon, 12 Apr 2021 08:28:19 +0200
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <20210409153309.wbebto3eufui35qs@e107158-lin>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
 <20210409153309.wbebto3eufui35qs@e107158-lin>
Message-ID: <be48adb2-c838-1a9b-37bc-da783f3d5dd3@nokia.com>

Hi!

On 09/04/2021 17:33, Qais Yousef wrote:
> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't
> work out for you? I struggle to see how this is better and why it was hard to
> incorporate my suggestion.
> 
> For example
> 
> 	-       old = ftrace_call_replace(ip, adjust_address(rec, addr));
> 	+#ifdef CONFIG_ARM_MODULE_PLTS
> 	+       /* mod is only supplied during module loading */
> 	+       if (!mod)
> 	+               mod = rec->arch.mod;
> 	+       else
> 	+               rec->arch.mod = mod;
> 	+#endif
> 	+
> 	+       old = ftrace_call_replace(ip, aaddr,
> 	+                                 !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod);
> 	+#ifdef CONFIG_ARM_MODULE_PLTS
> 	+       if (!old && mod) {
> 	+               aaddr = get_module_plt(mod, ip, aaddr);
> 	+               old = ftrace_call_replace(ip, aaddr, true);
> 	+       }
> 	+#endif
> 	+
> 
> There's an ifdef, followed by a code that embeds
> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/

No, it's actually two small ifdefed blocks added before and after an original call,
which parameters have been modified as well. The issue with arch.mod was explained
by Steven Rostedt, maybe you've missed his email.
 
> And there was no need to make the new warn arg visible all the way to
> ftrace_call_repalce() and all of its users.
> 
> FWIW
> 
> Tested-by: Qais Yousef <qais.yousef at arm.com>
-- 
Best regards,
Alexander Sverdlin.


From yongqiang.niu at mediatek.com  Mon Apr 12 07:35:44 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 14:35:44 +0800
Subject: [PATCH v1, 0/3] gamma set with cmdq
Message-ID: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>

This series are based on 5.12-rc2 and provide 3 patch
to set gamma lut with cmdq

Yongqiang Niu (3):
  drm/mediatek: Separate aal module
  arm64: dts: mt8183: refine aal compatible name
  drm/mediatek: gamma set with cmdq

 arch/arm64/boot/dts/mediatek/mt8183.dtsi    |   3 +-
 drivers/gpu/drm/mediatek/Makefile           |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_aal.c     | 167 ++++++++++++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  14 ++-
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c   |  11 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c     |  18 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  39 +------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   8 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c      |   8 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h      |   1 +
 10 files changed, 213 insertions(+), 59 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 07:35:46 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 14:35:46 +0800
Subject: [PATCH v1, 2/3] arm64: dts: mt8183: refine aal compatible name
In-Reply-To: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618209347-10816-3-git-send-email-yongqiang.niu@mediatek.com>

mt8183 aal is different with mt8173
remove mt8173 compatible name for mt8183 aal

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a1..ee8f87f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1061,8 +1061,7 @@
 		};
 
 		aal0: aal at 14010000 {
-			compatible = "mediatek,mt8183-disp-aal",
-				     "mediatek,mt8173-disp-aal";
+			compatible = "mediatek,mt8183-disp-aal";
 			reg = <0 0x14010000 0 0x1000>;
 			interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_LOW>;
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 07:35:47 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 14:35:47 +0800
Subject: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
In-Reply-To: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>

gamma lut set in vsync active will caused display flash issue
set gamma lut with cmdq 

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_aal.c     |  4 ++--
 drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  7 ++++---
 drivers/gpu/drm/mediatek/mtk_disp_gamma.c   | 11 ++++++-----
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 18 +++++++++++-------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  8 +++++---
 5 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
index 64b4528..c8e178e 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -59,12 +59,12 @@ void mtk_aal_config(struct device *dev, unsigned int w,
 	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
 }
 
-void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
+void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
 {
 	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
 
 	if (aal->data && aal->data->has_gamma)
-		mtk_gamma_set_common(aal->regs, state);
+		mtk_gamma_set_common(aal->regs, &aal->cmdq_reg, state, cmdq_pkt);
 }
 
 void mtk_aal_start(struct device *dev)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 86c3068..c2e7dcb 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -14,7 +14,7 @@
 void mtk_aal_config(struct device *dev, unsigned int w,
 		    unsigned int h, unsigned int vrefresh,
 		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
-void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
+void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
 void mtk_aal_start(struct device *dev);
 void mtk_aal_stop(struct device *dev);
 
@@ -50,8 +50,9 @@ void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
 void mtk_gamma_config(struct device *dev, unsigned int w,
 		      unsigned int h, unsigned int vrefresh,
 		      unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
-void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state);
+void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
+void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
+			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
 void mtk_gamma_start(struct device *dev);
 void mtk_gamma_stop(struct device *dev);
 
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
index 3ebf91e..99a4ff3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
@@ -55,7 +55,8 @@ void mtk_gamma_clk_disable(struct device *dev)
 	clk_disable_unprepare(gamma->clk);
 }
 
-void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
+void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
+			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
 {
 	unsigned int i, reg;
 	struct drm_color_lut *lut;
@@ -65,23 +66,23 @@ void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
 	if (state->gamma_lut) {
 		reg = readl(regs + DISP_GAMMA_CFG);
 		reg = reg | GAMMA_LUT_EN;
-		writel(reg, regs + DISP_GAMMA_CFG);
+		mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs, DISP_GAMMA_CFG);
 		lut_base = regs + DISP_GAMMA_LUT;
 		lut = (struct drm_color_lut *)state->gamma_lut->data;
 		for (i = 0; i < MTK_LUT_SIZE; i++) {
 			word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
 				(((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
 				((lut[i].blue >> 6) & LUT_10BIT_MASK);
-			writel(word, (lut_base + i * 4));
+			mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
 		}
 	}
 }
 
-void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
+void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
 {
 	struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
 
-	mtk_gamma_set_common(gamma->regs, state);
+	mtk_gamma_set_common(gamma->regs, &gamma->cmdq_reg, state, cmdq_pkt);
 }
 
 void mtk_gamma_config(struct device *dev, unsigned int w,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8b0de90..73428f0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -423,6 +423,15 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
 		}
 		mtk_crtc->pending_async_planes = false;
 	}
+
+	if (crtc->state->color_mgmt_changed) {
+		int i;
+
+		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
+			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state, cmdq_handle);
+			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
+		}
+	}
 }
 
 static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
@@ -464,7 +473,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	if (mtk_crtc->cmdq_client) {
 		mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
-		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
+		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 2 * PAGE_SIZE);
 		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);
@@ -616,15 +625,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
 				      struct drm_atomic_state *state)
 {
 	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
-	int i;
 
 	if (mtk_crtc->event)
 		mtk_crtc->pending_needs_vblank = true;
-	if (crtc->state->color_mgmt_changed)
-		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
-			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
-			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
-		}
+
 	mtk_drm_crtc_hw_config(mtk_crtc);
 }
 
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d9..bffa58d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -60,7 +60,8 @@ struct mtk_ddp_comp_funcs {
 			     struct mtk_plane_state *state,
 			     struct cmdq_pkt *cmdq_pkt);
 	void (*gamma_set)(struct device *dev,
-			  struct drm_crtc_state *state);
+			  struct drm_crtc_state *state,
+			  struct cmdq_pkt *cmdq_pkt);
 	void (*bgclr_in_on)(struct device *dev);
 	void (*bgclr_in_off)(struct device *dev);
 	void (*ctm_set)(struct device *dev,
@@ -160,10 +161,11 @@ static inline void mtk_ddp_comp_layer_config(struct mtk_ddp_comp *comp,
 }
 
 static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
-				     struct drm_crtc_state *state)
+				     struct drm_crtc_state *state,
+				     struct cmdq_pkt *cmdq_pkt)
 {
 	if (comp->funcs && comp->funcs->gamma_set)
-		comp->funcs->gamma_set(comp->dev, state);
+		comp->funcs->gamma_set(comp->dev, state, cmdq_pkt);
 }
 
 static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 07:35:45 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 14:35:45 +0800
Subject: [PATCH v1, 1/3] drm/mediatek: Separate aal module
In-Reply-To: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618209347-10816-2-git-send-email-yongqiang.niu@mediatek.com>

mt8183 aal has no gamma function

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/gpu/drm/mediatek/Makefile           |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_aal.c     | 167 ++++++++++++++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_disp_drv.h     |   9 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  39 +------
 drivers/gpu/drm/mediatek/mtk_drm_drv.c      |   8 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h      |   1 +
 6 files changed, 187 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c

diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
index dc54a7a..29098d7 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
-mediatek-drm-y := mtk_disp_ccorr.o \
+mediatek-drm-y := mtk_disp_aal.o \
+		  mtk_disp_ccorr.o \
 		  mtk_disp_color.o \
 		  mtk_disp_gamma.o \
 		  mtk_disp_ovl.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
new file mode 100644
index 0000000..64b4528
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.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 DISP_AAL_EN				0x0000
+#define AAL_EN						BIT(0)
+#define DISP_AAL_SIZE				0x0030
+
+
+struct mtk_disp_aal_data {
+	bool has_gamma;
+};
+
+/**
+ * struct mtk_disp_aal - DISP_AAL driver structure
+ * @ddp_comp - structure containing type enum and hardware resources
+ * @crtc - associated crtc to report irq events to
+ */
+struct mtk_disp_aal {
+	struct clk *clk;
+	void __iomem *regs;
+	struct cmdq_client_reg cmdq_reg;
+	const struct mtk_disp_aal_data *data;
+};
+
+int mtk_aal_clk_enable(struct device *dev)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	return clk_prepare_enable(aal->clk);
+}
+
+void mtk_aal_clk_disable(struct device *dev)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(aal->clk);
+}
+
+void mtk_aal_config(struct device *dev, unsigned int w,
+			   unsigned int h, unsigned int vrefresh,
+			   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
+}
+
+void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	if (aal->data && aal->data->has_gamma)
+		mtk_gamma_set_common(aal->regs, state);
+}
+
+void mtk_aal_start(struct device *dev)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	writel(AAL_EN, aal->regs + DISP_AAL_EN);
+}
+
+void mtk_aal_stop(struct device *dev)
+{
+	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
+
+	writel_relaxed(0x0, aal->regs + DISP_AAL_EN);
+}
+
+static int mtk_disp_aal_bind(struct device *dev, struct device *master,
+			       void *data)
+{
+	return 0;
+}
+
+static void mtk_disp_aal_unbind(struct device *dev, struct device *master,
+				  void *data)
+{
+}
+
+static const struct component_ops mtk_disp_aal_component_ops = {
+	.bind	= mtk_disp_aal_bind,
+	.unbind = mtk_disp_aal_unbind,
+};
+
+static int mtk_disp_aal_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_disp_aal *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 aal clk\n");
+		return PTR_ERR(priv->clk);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->regs)) {
+		dev_err(dev, "failed to ioremap aal\n");
+		return PTR_ERR(priv->regs);
+	}
+
+#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);
+
+	ret = component_add(dev, &mtk_disp_aal_component_ops);
+	if (ret)
+		dev_err(dev, "Failed to add component: %d\n", ret);
+
+	return ret;
+}
+
+static int mtk_disp_aal_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &mtk_disp_aal_component_ops);
+
+	return 0;
+}
+
+static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
+	.has_gamma = true,
+};
+
+static const struct of_device_id mtk_disp_aal_driver_dt_match[] = {
+	{ .compatible = "mediatek,mt8173-disp-aal",
+	  .data = &mt8173_aal_driver_data},
+	{ .compatible = "mediatek,mt8183-disp-aal"},
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
+
+struct platform_driver mtk_disp_aal_driver = {
+	.probe		= mtk_disp_aal_probe,
+	.remove		= mtk_disp_aal_remove,
+	.driver		= {
+		.name	= "mediatek-disp-aal",
+		.owner	= THIS_MODULE,
+		.of_match_table = mtk_disp_aal_driver_dt_match,
+	},
+};
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index cafd9df..86c3068 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -9,6 +9,15 @@
 #include <linux/soc/mediatek/mtk-cmdq.h>
 #include "mtk_drm_plane.h"
 
+int mtk_aal_clk_enable(struct device *dev);
+void mtk_aal_clk_disable(struct device *dev);
+void mtk_aal_config(struct device *dev, unsigned int w,
+		    unsigned int h, unsigned int vrefresh,
+		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
+void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
+void mtk_aal_start(struct device *dev);
+void mtk_aal_stop(struct device *dev);
+
 void mtk_ccorr_ctm_set(struct device *dev, struct drm_crtc_state *state);
 int mtk_ccorr_clk_enable(struct device *dev);
 void mtk_ccorr_clk_disable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 75bc00e..f367142 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -32,9 +32,6 @@
 
 #define DISP_REG_UFO_START			0x0000
 
-#define DISP_AAL_EN				0x0000
-#define DISP_AAL_SIZE				0x0030
-
 #define DISP_DITHER_EN				0x0000
 #define DITHER_EN				BIT(0)
 #define DISP_DITHER_CFG				0x0020
@@ -48,8 +45,6 @@
 
 #define UFO_BYPASS				BIT(2)
 
-#define AAL_EN					BIT(0)
-
 #define DISP_DITHERING				BIT(2)
 #define DITHER_LSB_ERR_SHIFT_R(x)		(((x) & 0x7) << 28)
 #define DITHER_OVFLW_BIT_R(x)			(((x) & 0x7) << 24)
@@ -190,36 +185,6 @@ static void mtk_ufoe_start(struct device *dev)
 	writel(UFO_BYPASS, priv->regs + DISP_REG_UFO_START);
 }
 
-static void mtk_aal_config(struct device *dev, unsigned int w,
-			   unsigned int h, unsigned int vrefresh,
-			   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
-{
-	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
-
-	mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs, DISP_AAL_SIZE);
-}
-
-static void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
-{
-	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
-
-	mtk_gamma_set_common(priv->regs, state);
-}
-
-static void mtk_aal_start(struct device *dev)
-{
-	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
-
-	writel(AAL_EN, priv->regs + DISP_AAL_EN);
-}
-
-static void mtk_aal_stop(struct device *dev)
-{
-	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
-
-	writel_relaxed(0x0, priv->regs + DISP_AAL_EN);
-}
-
 static void mtk_dither_config(struct device *dev, unsigned int w,
 			      unsigned int h, unsigned int vrefresh,
 			      unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -247,8 +212,8 @@ static void mtk_dither_stop(struct device *dev)
 }
 
 static const struct mtk_ddp_comp_funcs ddp_aal = {
-	.clk_enable = mtk_ddp_clk_enable,
-	.clk_disable = mtk_ddp_clk_disable,
+	.clk_enable = mtk_aal_clk_enable,
+	.clk_disable = mtk_aal_clk_disable,
 	.gamma_set = mtk_aal_gamma_set,
 	.config = mtk_aal_config,
 	.start = mtk_aal_start,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b013d56..ae8b69d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -420,6 +420,8 @@ static void mtk_drm_unbind(struct device *dev)
 	  .data = (void *)MTK_DISP_COLOR },
 	{ .compatible = "mediatek,mt8173-disp-aal",
 	  .data = (void *)MTK_DISP_AAL},
+	{ .compatible = "mediatek,mt8183-disp-aal",
+	  .data = (void *)MTK_DISP_AAL},
 	{ .compatible = "mediatek,mt8173-disp-gamma",
 	  .data = (void *)MTK_DISP_GAMMA, },
 	{ .compatible = "mediatek,mt8183-disp-gamma",
@@ -531,11 +533,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
 		private->comp_node[comp_id] = of_node_get(node);
 
 		/*
-		 * Currently only the CCORR, COLOR, GAMMA, OVL, RDMA, DSI, and DPI
+		 * Currently only the AAL, CCORR, COLOR, GAMMA, OVL, RDMA, DSI, and DPI
 		 * blocks have separate component platform drivers and initialize their own
 		 * DDP component structure. The others are initialized here.
 		 */
-		if (comp_type == MTK_DISP_CCORR ||
+		if (comp_type == MTK_DISP_AAL ||
+		    comp_type == MTK_DISP_CCORR ||
 		    comp_type == MTK_DISP_COLOR ||
 		    comp_type == MTK_DISP_GAMMA ||
 		    comp_type == MTK_DISP_OVL ||
@@ -635,6 +638,7 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
 };
 
 static struct platform_driver * const mtk_drm_drivers[] = {
+	&mtk_disp_aal_driver,
 	&mtk_disp_ccorr_driver,
 	&mtk_disp_color_driver,
 	&mtk_disp_gamma_driver,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 637f566..3e7d1e6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -46,6 +46,7 @@ struct mtk_drm_private {
 	struct drm_atomic_state *suspend_state;
 };
 
+extern struct platform_driver mtk_disp_aal_driver;
 extern struct platform_driver mtk_disp_ccorr_driver;
 extern struct platform_driver mtk_disp_color_driver;
 extern struct platform_driver mtk_disp_gamma_driver;
-- 
1.8.1.1.dirty

From flora.fu at mediatek.com  Mon Apr 12 07:44:55 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Mon, 12 Apr 2021 14:44:55 +0800
Subject: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document
 bindings for APU
In-Reply-To: <20210409182538.GA3913794@robh.at.kernel.org>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>
 <20210409182538.GA3913794@robh.at.kernel.org>
Message-ID: <1618209895.25062.11.camel@mtksdccf07>

On Fri, 2021-04-09 at 13:25 -0500, Rob Herring wrote:
> On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> > Document the apusys bindings.
> > 
> > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > ---
> >  .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
> >  1 file changed, 56 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > new file mode 100644
> > index 000000000000..dc04a46f1bad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > @@ -0,0 +1,56 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrAYYvZWcw$ 
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrARlhCQ0w$ 
> > +
> > +title: MediaTek APUSYS Controller
> > +
> > +maintainers:
> > +  - Flora Fu <flora.fu at mediatek.com>
> > +
> > +description:
> > +  The Mediatek apusys controller provides functional configurations and clocks
> > +  to the system.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - mediatek,mt8192-apu_mbox
> > +          - mediatek,mt8192-apu_conn
> > +          - mediatek,mt8192-apu_vcore
> 
> s/_/-/
> 

OK. I will update expression strings in the next version.

> > +      - const: syscon
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  '#clock-cells':
> > +    const: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    apu_mbox: apu_mbox at 19000000 {
> 
> mailbox at ...? Is this a mailbox provider?
> 

Yes, the apu_mbox is the for setup mailbox in the APU hardware.

> > +        compatible = "mediatek,mt8192-apu_mbox", "syscon";
> > +        reg = <0x19000000 0x1000>;
> > +    };
> > +
> > +  - |
> > +    apu_conn: apu_conn at 19020000 {
> > +        compatible = "mediatek,mt8192-apu_conn", "syscon";
> > +        reg = <0x19020000 0x1000>;
> > +        #clock-cells = <1>;
> > +    };
> > +
> > +  - |
> > +    apu_vcore: apu_vcore at 19029000 {
> > +        compatible = "mediatek,mt8192-apu_vcore", "syscon";
> > +        reg = <0x19029000 0x1000>;
> > +        #clock-cells = <1>;
> > +    };
> > -- 
> > 2.18.0
> > 


From yong.wu at mediatek.com  Mon Apr 12 07:48:43 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Mon, 12 Apr 2021 14:48:43 +0800
Subject: [PATCH 2/2] iommu/mediatek-v1: Add error handle for mtk_iommu_probe
In-Reply-To: <20210412064843.11614-1-yong.wu@mediatek.com>
References: <20210412064843.11614-1-yong.wu@mediatek.com>
Message-ID: <20210412064843.11614-2-yong.wu@mediatek.com>

In the original code, we lack the error handle. This patch adds them.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
 drivers/iommu/mtk_iommu_v1.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index bed0bb9d63fd..8ba9a2ec5509 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -620,12 +620,26 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 
 	ret = iommu_device_register(&data->iommu);
 	if (ret)
-		return ret;
+		goto out_sysfs_remove;
 
-	if (!iommu_present(&platform_bus_type))
-		bus_set_iommu(&platform_bus_type,  &mtk_iommu_ops);
+	if (!iommu_present(&platform_bus_type)) {
+		ret = bus_set_iommu(&platform_bus_type,  &mtk_iommu_ops);
+		if (ret)
+			goto out_dev_unreg;
+	}
 
-	return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+	ret = component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+	if (ret)
+		goto out_bus_set_null;
+	return ret;
+
+out_bus_set_null:
+	bus_set_iommu(&platform_bus_type, NULL);
+out_dev_unreg:
+	iommu_device_unregister(&data->iommu);
+out_sysfs_remove:
+	iommu_device_sysfs_remove(&data->iommu);
+	return ret;
 }
 
 static int mtk_iommu_remove(struct platform_device *pdev)
-- 
2.18.0

From dillon.minfei at gmail.com  Mon Apr 12 07:50:20 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Mon, 12 Apr 2021 14:50:20 +0800
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <YHPgGI6EmTzmVH7g@kroah.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <YHPgGI6EmTzmVH7g@kroah.com>
Message-ID: <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>

Hi Greg?

Thanks for the quick response, please ignore the last private mail.

On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>
> On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > To avoid potential deadlock in spin_lock usage, change to use
> > spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
> > spin_lock(), spin_unlock() under handler context.
> >
> > remove unused local_irq_save/restore call.
> >
> > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > ---
> > Was verified on stm32f469-disco board. need more test on stm32mp platform.
> >
> >  drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
> >  1 file changed, 17 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > index b3675cf25a69..c4c859b34367 100644
> > --- a/drivers/tty/serial/stm32-usart.c
> > +++ b/drivers/tty/serial/stm32-usart.c
> > @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> >       struct tty_port *tport = &port->state->port;
> >       struct stm32_port *stm32_port = to_stm32_port(port);
> >       const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > -     unsigned long c;
> > +     unsigned long c, flags;
> >       u32 sr;
> >       char flag;
> >
> > @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> >               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> >       }
> >
> > -     spin_unlock(&port->lock);
> > +     if (threaded)
> > +             spin_unlock_irqrestore(&port->lock, flags);
> > +     else
> > +             spin_unlock(&port->lock);
>
> You shouldn't have to check for this, see the other patches on the list
> recently that fixed this up to not be an issue for irq handlers.
Can you help to give more hints, or the commit id of the patch which
fixed this. thanks.

I'm still confused with this.

The stm32_usart_threaded_interrupt() is a kthread context, once
port->lock holds by this function, another serial interrupts raised,
such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
there will be a deadlock. isn't it?

 So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?

There is a bug in this patch, the variable flags should be a global variable.

Thanks.

Dillon,
>
> thanks,
>
> greg k-h


From steven_lee at aspeedtech.com  Mon Apr 12 07:50:33 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Mon, 12 Apr 2021 14:50:33 +0800
Subject: [PATCH v1 2/2] mmc: sdhci-of-aspeed: Support toggling SD bus
 signal voltage by GPIO
In-Reply-To: <acaa2cc2-9b12-442e-a767-3c4b41affa21@www.fastmail.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-3-steven_lee@aspeedtech.com>
 <acaa2cc2-9b12-442e-a767-3c4b41affa21@www.fastmail.com>
Message-ID: <20210412065032.GC23408@aspeedtech.com>

The 04/09/2021 12:14, Andrew Jeffery wrote:
> Hi Steven,
> 
> On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> > AST2600-A2 EVB provides reference design to support toggling signal
> > voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
> > the device tree.
> 
> Is this something you think we need support for beyond the EVB? It 
> sounds a lot like a knob to enable testing of different SD/MMC power 
> configurations and not something that you'd otherwise see in a system 
> design.
>

It can be used for testing different SD power configuration.
The main purpose of the patch is letting the driver has the ability to 
change the bus voltage for switching SD bus speed between UHS-I mode and
normal/high speed mode in AST2600-A2 EVB according to the value of
power-switch-gpio that defined in the device tree. 
But I am not sure whether it needs to be support in mainline kernel.
Since it requires a particular hardware circuit design outside of ASPEED
AST2600 SoC, and AST2600-A2 EVB does have that design.

> > It also supporting enabling/disabling SD bus power by
> > power-gpio.
> 
> This sounds like it could be useful but I'll defer to Ulf with regards 
> to the binding.
> 
> > 
> > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> > a 1.8v and a 3.3v power load switch that providing signal voltage to
> > SD1 bus.
> > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> > disabled.
> > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> > voltage is 3.3v, otherwise, 1.8v power load switch will be enabled, SD1
> > signal voltage becomes 1.8v.
> > 
> > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and
> > GPIOV3 as power-switch-gpio.
> > 
> > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> > ---
> >  drivers/mmc/host/sdhci-of-aspeed.c | 155 +++++++++++++++++++++++++----
> >  1 file changed, 137 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c 
> > b/drivers/mmc/host/sdhci-of-aspeed.c
> > index 7d8692e90996..a74a03d37915 100644
> > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> > @@ -5,6 +5,7 @@
> >  #include <linux/clk.h>
> >  #include <linux/delay.h>
> >  #include <linux/device.h>
> > +#include <linux/gpio/consumer.h>
> >  #include <linux/io.h>
> >  #include <linux/math64.h>
> >  #include <linux/mmc/host.h>
> > @@ -30,6 +31,7 @@
> >  #define   ASPEED_SDC_S0_PHASE_IN_EN	BIT(2)
> >  #define   ASPEED_SDC_S0_PHASE_OUT_EN	GENMASK(1, 0)
> >  #define   ASPEED_SDC_PHASE_MAX		31
> > +#define ASPEED_CLOCK_PHASE 0xf4
> 
> This isn't related to the power GPIOs, and we already have phase 
> support as suggested by the macros immediately above the one you've 
> added here.
> 
> Please remove it and make use of the existing mmc phase devicetree 
> binding and driver support.
> 

Will remove it.

> >  
> >  struct aspeed_sdc {
> >  	struct clk *clk;
> > @@ -58,18 +60,21 @@ struct aspeed_sdhci_phase_desc {
> >  	struct aspeed_sdhci_tap_desc out;
> >  };
> >  
> > -struct aspeed_sdhci_pdata {
> > +struct aspeed_sdhci_data {
> 
> Why are we renaming this? It looks like it creates a lot of noise in 
> the patch. The data it captured was platform data, hence 'pdata' in the 
> name. In my opinon it's fine if we also have a member called pdata.
> 

Since I add a new member in aspeed_sdhci_pdata(In the patch, it is named
aspeed_sdhci_data) for separating the platform data of aspeed-g5 and
aspped-g6, the type of the member is sdhci_pltfm_data.
Therefore, I use the pdata for my new created member and renamed the
original pdata as data as follows.

static const struct of_device_id aspeed_sdhci_of_match[] = {
  { .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_data, },
};

static const struct aspeed_sdhci_data ast2400_sdhci_data = {
  .clk_div_start = 2,
  .pdata = &ast2400_sdhci_pdata,
};


Regardless, I will revert it to the original name and rename
my new created variable.

> >  	unsigned int clk_div_start;
> >  	const struct aspeed_sdhci_phase_desc *phase_desc;
> >  	size_t nr_phase_descs;
> > +	const struct sdhci_pltfm_data *pdata;
> >  };
> >  
> >  struct aspeed_sdhci {
> > -	const struct aspeed_sdhci_pdata *pdata;
> > +	const struct aspeed_sdhci_data *data;
> >  	struct aspeed_sdc *parent;
> >  	u32 width_mask;
> >  	struct mmc_clk_phase_map phase_map;
> >  	const struct aspeed_sdhci_phase_desc *phase_desc;
> > +	struct gpio_desc *pwr_pin;
> > +	struct gpio_desc *pwr_sw_pin;
> >  };
> >  
> >  static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
> > @@ -209,7 +214,6 @@ static void aspeed_sdhci_set_clock(struct 
> > sdhci_host *host, unsigned int clock)
> >  	sdhci = sdhci_pltfm_priv(pltfm_host);
> >  
> >  	parent = clk_get_rate(pltfm_host->clk);
> > -
> 
> Unrelated whitespace cleanup.
> 
> >  	sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> >  
> >  	if (clock == 0)
> > @@ -234,14 +238,13 @@ static void aspeed_sdhci_set_clock(struct 
> > sdhci_host *host, unsigned int clock)
> >  	 * supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and 
> > capture
> >  	 * the 0-value capability in clk_div_start.
> >  	 */
> > -	for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
> > +	for (div = sdhci->data->clk_div_start; div < 256; div *= 2) {
> >  		bus = parent / div;
> >  		if (bus <= clock)
> >  			break;
> >  	}
> >  
> >  	div >>= 1;
> > -
> 
> Unrelated whitespace cleanup.
> 
> >  	clk = div << SDHCI_DIVIDER_SHIFT;
> >  
> >  	aspeed_sdhci_configure_phase(host, bus);
> > @@ -292,8 +295,78 @@ static u32 aspeed_sdhci_readl(struct sdhci_host 
> > *host, int reg)
> >  	return val;
> >  }
> >  
> > +static void sdhci_aspeed_set_power(struct sdhci_host *host, unsigned char mode,
> > +				   unsigned short vdd)
> > +{
> > +	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
> > +	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
> > +	u8 pwr = 0;
> > +
> > +	if (!dev->pwr_pin)
> > +		return sdhci_set_power(host, mode, vdd);
> > +
> > +	if (mode != MMC_POWER_OFF) {
> > +		switch (1 << vdd) {
> > +		case MMC_VDD_165_195:
> > +		/*
> > +		 * Without a regulator, SDHCI does not support 2.0v
> > +		 * so we only get here if the driver deliberately
> > +		 * added the 2.0v range to ocr_avail. Map it to 1.8v
> > +		 * for the purpose of turning on the power.
> > +		 */
> > +		case MMC_VDD_20_21:
> > +				pwr = SDHCI_POWER_180;
> > +				break;
> > +		case MMC_VDD_29_30:
> > +		case MMC_VDD_30_31:
> > +				pwr = SDHCI_POWER_300;
> > +				break;
> > +		case MMC_VDD_32_33:
> > +		case MMC_VDD_33_34:
> > +				pwr = SDHCI_POWER_330;
> > +				break;
> > +		default:
> > +				WARN(1, "%s: Invalid vdd %#x\n",
> > +				     mmc_hostname(host->mmc), vdd);
> > +				break;
> > +		}
> > +	}
> > +
> > +	if (host->pwr == pwr)
> > +		return;
> > +
> > +	host->pwr = pwr;
> > +
> > +	if (pwr == 0) {
> 
> Shouldn't we be testing against an SDHCI_POWER_* macro?
> 

It is copied from sdhci_set_power_noreg() of sdhci.c
The difference is we need to change the bus voltage before writing
SDHCI_POWER_CONTROL.
Since There are only SDHCI_POWER_ON, SDHCI_POWER_180, SDHCI_POWER_300,
and SDHCI_POWER_330 defined in sdhci.h.
Do you mean pwr should be checked with SDHCI_POWER_ON, SDHCI_POWER_180,
SDHCI_POWER_300, and SDHCI_POWER_330?

> > +		gpiod_set_value(dev->pwr_pin, 0);
> > +		sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
> > +	} else {
> > +		gpiod_set_value(dev->pwr_pin, 1);
> > +
> > +		if (dev->pwr_sw_pin) {
> > +			if (pwr & SDHCI_POWER_330)
> > +				gpiod_set_value(dev->pwr_sw_pin, 1);
> > +			else if (pwr & SDHCI_POWER_180)
> > +				gpiod_set_value(dev->pwr_sw_pin, 0);
> > +		}
> > +		pwr |= SDHCI_POWER_ON;
> > +		sdhci_writeb(host, pwr, SDHCI_POWER_CONTROL);
> > +	}
> > +}
> > +
> > +static void aspeed_sdhci_voltage_switch(struct sdhci_host *host)
> > +{
> > +	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
> > +	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
> > +
> > +	if (dev->pwr_sw_pin)
> > +		gpiod_set_value(dev->pwr_sw_pin, 0);
> > +}
> > +
> >  static const struct sdhci_ops aspeed_sdhci_ops = {
> >  	.read_l = aspeed_sdhci_readl,
> > +	.set_power = sdhci_aspeed_set_power,
> > +	.voltage_switch = aspeed_sdhci_voltage_switch,
> >  	.set_clock = aspeed_sdhci_set_clock,
> >  	.get_max_clock = aspeed_sdhci_get_max_clock,
> >  	.set_bus_width = aspeed_sdhci_set_bus_width,
> > @@ -302,9 +375,14 @@ static const struct sdhci_ops aspeed_sdhci_ops = {
> >  	.set_uhs_signaling = sdhci_set_uhs_signaling,
> >  };
> >  
> > -static const struct sdhci_pltfm_data aspeed_sdhci_pdata = {
> > +static const struct sdhci_pltfm_data ast2400_sdhci_pdata = {
> >  	.ops = &aspeed_sdhci_ops,
> >  	.quirks = SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> > +	.quirks2 = SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN | 
> > SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> > +};
> > +
> > +static const struct sdhci_pltfm_data ast2600_sdhci_pdata = {
> > +	.ops = &aspeed_sdhci_ops,
> >  };
> >  
> >  static inline int aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> > @@ -327,27 +405,28 @@ static inline int 
> > aspeed_sdhci_calculate_slot(struct aspeed_sdhci *dev,
> >  
> >  static int aspeed_sdhci_probe(struct platform_device *pdev)
> >  {
> > -	const struct aspeed_sdhci_pdata *aspeed_pdata;
> > +	const struct aspeed_sdhci_data *aspeed_data;
> >  	struct sdhci_pltfm_host *pltfm_host;
> >  	struct aspeed_sdhci *dev;
> >  	struct sdhci_host *host;
> >  	struct resource *res;
> > +	u32 reg_val;
> >  	int slot;
> >  	int ret;
> >  
> > -	aspeed_pdata = of_device_get_match_data(&pdev->dev);
> > -	if (!aspeed_pdata) {
> > +	aspeed_data = of_device_get_match_data(&pdev->dev);
> > +	if (!aspeed_data) {
> >  		dev_err(&pdev->dev, "Missing platform configuration data\n");
> >  		return -EINVAL;
> >  	}
> >  
> > -	host = sdhci_pltfm_init(pdev, &aspeed_sdhci_pdata, sizeof(*dev));
> > +	host = sdhci_pltfm_init(pdev, aspeed_data->pdata, sizeof(*dev));
> >  	if (IS_ERR(host))
> >  		return PTR_ERR(host);
> >  
> >  	pltfm_host = sdhci_priv(host);
> >  	dev = sdhci_pltfm_priv(pltfm_host);
> > -	dev->pdata = aspeed_pdata;
> > +	dev->data = aspeed_data;
> >  	dev->parent = dev_get_drvdata(pdev->dev.parent);
> >  
> >  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > @@ -358,8 +437,8 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
> >  	else if (slot >= 2)
> >  		return -EINVAL;
> >  
> > -	if (slot < dev->pdata->nr_phase_descs) {
> > -		dev->phase_desc = &dev->pdata->phase_desc[slot];
> > +	if (slot < dev->data->nr_phase_descs) {
> > +		dev->phase_desc = &dev->data->phase_desc[slot];
> >  	} else {
> >  		dev_info(&pdev->dev,
> >  			 "Phase control not supported for slot %d\n", slot);
> > @@ -372,6 +451,23 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
> >  
> >  	sdhci_get_of_property(pdev);
> >  
> > +	if (of_property_read_bool(pdev->dev.parent->of_node, "mmc-hs200-1_8v") ||
> > +	    of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
> > +		reg_val = readl(host->ioaddr + 0x40);
> 
> Shouldn't this use  sdhci_readl()?
> 

will use sdhci_readl()

> > +		/* support 1.8V */
> > +		reg_val |= BIT(26);
> > +		/* write to sdhci140 or sdhci240 mirror register */
> > +		writel(reg_val, dev->parent->regs + (0x10 * (slot + 1)));
> 
> I think I prefer a helper for this, like 
> aspeed_sdc_set_slot_capability(dev->parent, reg_val, slot, cap_idx), 
> rather than poking the global SD controller config space from the SDHCI 
> driver.
> 

will add a helper

> > +	}
> > +
> > +	if (of_property_read_bool(pdev->dev.parent->of_node, "sd-uhs-sdr104")) {
> > +		reg_val = readl(host->ioaddr + 0x44);
> > +		/* SDR104 */
> > +		reg_val |= BIT(1);
> > +		/* write to sdhci144 or sdhci244 mirror register */
> > +		writel(reg_val, dev->parent->regs + (0x04 + (slot + 1) * 0x10));
> 
> As above.
> 
> > +	}
> > +
> >  	pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
> >  	if (IS_ERR(pltfm_host->clk))
> >  		return PTR_ERR(pltfm_host->clk);
> > @@ -389,6 +485,22 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
> >  	if (dev->phase_desc)
> >  		mmc_of_parse_clk_phase(host->mmc, &dev->phase_map);
> >  
> > +	dev->pwr_pin = devm_gpiod_get(&pdev->dev, "power", GPIOD_OUT_HIGH);
> 
> Shouldn't this use devm_gpiod_get_optional()?
> 

will use devm_gpiod_get_optional()

> > +	if (!IS_ERR(dev->pwr_pin)) {
> > +		gpiod_set_consumer_name(dev->pwr_pin, "mmc_pwr");
> > +		gpiod_direction_output(dev->pwr_pin, 1);
> > +	} else {
> > +		dev->pwr_pin = NULL;
> > +	}
> > +
> > +	dev->pwr_sw_pin = devm_gpiod_get(&pdev->dev, "power-switch", GPIOD_OUT_HIGH);
> 
> Shouldn't this use devm_gpiod_get_optional()?
> 

will use devm_gpiod_get_optional()

> > +	if (!IS_ERR(dev->pwr_sw_pin)) {
> > +		gpiod_set_consumer_name(dev->pwr_sw_pin, "mmc_pwr_sw");
> > +		gpiod_direction_output(dev->pwr_sw_pin, 0);
> > +	} else {
> > +		dev->pwr_sw_pin = NULL;
> > +	}
> > +
> >  	ret = sdhci_add_host(host);
> >  	if (ret)
> >  		goto err_sdhci_add;
> > @@ -420,8 +532,9 @@ static int aspeed_sdhci_remove(struct platform_device *pdev)
> >  	return 0;
> >  }
> >  
> > -static const struct aspeed_sdhci_pdata ast2400_sdhci_pdata = {
> > +static const struct aspeed_sdhci_data ast2400_sdhci_data = {
> >  	.clk_div_start = 2,
> > +	.pdata = &ast2400_sdhci_pdata,
> >  };
> >  
> >  static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
> > @@ -453,16 +566,17 @@ static const struct aspeed_sdhci_phase_desc 
> > ast2600_sdhci_phase[] = {
> >  	},
> >  };
> >  
> > -static const struct aspeed_sdhci_pdata ast2600_sdhci_pdata = {
> > +static const struct aspeed_sdhci_data ast2600_sdhci_data = {
> >  	.clk_div_start = 1,
> >  	.phase_desc = ast2600_sdhci_phase,
> >  	.nr_phase_descs = ARRAY_SIZE(ast2600_sdhci_phase),
> > +	.pdata = &ast2600_sdhci_pdata,
> >  };
> >  
> >  static const struct of_device_id aspeed_sdhci_of_match[] = {
> > -	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_pdata, },
> > -	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_pdata, },
> > -	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_pdata, },
> > +	{ .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_data, },
> > +	{ .compatible = "aspeed,ast2500-sdhci", .data = &ast2400_sdhci_data, },
> > +	{ .compatible = "aspeed,ast2600-sdhci", .data = &ast2600_sdhci_data, },
> >  	{ }
> >  };
> >  
> > @@ -482,6 +596,7 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
> >  	struct device_node *parent, *child;
> >  	struct aspeed_sdc *sdc;
> >  	int ret;
> > +	u32 timing_phase;
> >  
> >  	sdc = devm_kzalloc(&pdev->dev, sizeof(*sdc), GFP_KERNEL);
> >  	if (!sdc)
> > @@ -506,6 +621,10 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
> >  		goto err_clk;
> >  	}
> >  
> > +	if (!of_property_read_u32(pdev->dev.of_node,
> > +				  "timing-phase", &timing_phase))
> > +		writel(timing_phase, sdc->regs + ASPEED_CLOCK_PHASE);
> 
> As mentioned at the top, please use the existing phase bindings.
> 
> Cheers,
> 
> Andrew


From yong.wu at mediatek.com  Mon Apr 12 07:48:42 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Mon, 12 Apr 2021 14:48:42 +0800
Subject: [PATCH 1/2] iommu/mediatek-v1: Avoid build fail when build as module
Message-ID: <20210412064843.11614-1-yong.wu@mediatek.com>

When this driver build as module, It build fail like:

ERROR: modpost: "of_phandle_iterator_args"
[drivers/iommu/mtk_iommu_v1.ko] undefined!

This patch remove this interface to avoid this build fail.

Reported-by: Valdis Kletnieks <valdis.kletnieks at vt.edu>
Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
Currently below patch is only in linux-next-20210409. This fixes tag may be
not needed. we can add this if it is need.
Fixes: 8de000cf0265 ("iommu/mediatek-v1: Allow building as module")
---
 drivers/iommu/mtk_iommu_v1.c | 62 ++++++++++++++++--------------------
 1 file changed, 28 insertions(+), 34 deletions(-)

diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index be1b20e3f20e..bed0bb9d63fd 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -424,23 +424,21 @@ static struct iommu_device *mtk_iommu_probe_device(struct device *dev)
 {
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct of_phandle_args iommu_spec;
-	struct of_phandle_iterator it;
 	struct mtk_iommu_data *data;
-	int err;
+	int err, idx = 0;
 
-	of_for_each_phandle(&it, err, dev->of_node, "iommus",
-			"#iommu-cells", -1) {
-		int count = of_phandle_iterator_args(&it, iommu_spec.args,
-					MAX_PHANDLE_ARGS);
-		iommu_spec.np = of_node_get(it.node);
-		iommu_spec.args_count = count;
+	while (!of_parse_phandle_with_args(dev->of_node, "iommus",
+					   "#iommu-cells",
+					   idx, &iommu_spec)) {
 
-		mtk_iommu_create_mapping(dev, &iommu_spec);
+		err = mtk_iommu_create_mapping(dev, &iommu_spec);
+		of_node_put(iommu_spec.np);
+		if (err)
+			return ERR_PTR(err);
 
 		/* dev->iommu_fwspec might have changed */
 		fwspec = dev_iommu_fwspec_get(dev);
-
-		of_node_put(iommu_spec.np);
+		idx++;
 	}
 
 	if (!fwspec || fwspec->ops != &mtk_iommu_ops)
@@ -549,10 +547,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 	struct device			*dev = &pdev->dev;
 	struct resource			*res;
 	struct component_match		*match = NULL;
-	struct of_phandle_args		larb_spec;
-	struct of_phandle_iterator	it;
 	void				*protect;
-	int				larb_nr, ret, err;
+	int				larb_nr, ret, i;
 
 	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
 	if (!data)
@@ -580,35 +576,33 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 	if (IS_ERR(data->bclk))
 		return PTR_ERR(data->bclk);
 
-	larb_nr = 0;
-	of_for_each_phandle(&it, err, dev->of_node,
-			"mediatek,larbs", NULL, 0) {
+	larb_nr = of_count_phandle_with_args(dev->of_node,
+					     "mediatek,larbs", NULL);
+	if (larb_nr < 0)
+		return larb_nr;
+
+	for (i = 0; i < larb_nr; i++) {
+		struct device_node *larbnode;
 		struct platform_device *plarbdev;
-		int count = of_phandle_iterator_args(&it, larb_spec.args,
-					MAX_PHANDLE_ARGS);
 
-		if (count)
-			continue;
+		larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
+		if (!larbnode)
+			return -EINVAL;
 
-		larb_spec.np = of_node_get(it.node);
-		if (!of_device_is_available(larb_spec.np))
+		if (!of_device_is_available(larbnode)) {
+			of_node_put(larbnode);
 			continue;
+		}
 
-		plarbdev = of_find_device_by_node(larb_spec.np);
+		plarbdev = of_find_device_by_node(larbnode);
 		if (!plarbdev) {
-			plarbdev = of_platform_device_create(
-						larb_spec.np, NULL,
-						platform_bus_type.dev_root);
-			if (!plarbdev) {
-				of_node_put(larb_spec.np);
-				return -EPROBE_DEFER;
-			}
+			of_node_put(larbnode);
+			return -EPROBE_DEFER;
 		}
+		data->larb_imu[i].dev = &plarbdev->dev;
 
-		data->larb_imu[larb_nr].dev = &plarbdev->dev;
 		component_match_add_release(dev, &match, release_of,
-					    compare_of, larb_spec.np);
-		larb_nr++;
+					    compare_of, larbnode);
 	}
 
 	platform_set_drvdata(pdev, data);
-- 
2.18.0

From u.kleine-koenig at pengutronix.de  Mon Apr 12 08:02:32 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 12 Apr 2021 09:02:32 +0200
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
Message-ID: <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>

On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> Hi Uwe,
> 
> Thanks for your review.
> 
> On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > just a few small details left to criticize ...
> > 
> > On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> > > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > > new file mode 100644
> > > index 000000000000..99d83f94ed86
> > > --- /dev/null
> > > +++ b/drivers/pwm/pwm-visconti.c
> > > @@ -0,0 +1,188 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Toshiba Visconti pulse-width-modulation controller driver
> > > + *
> > > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > > + *
> > > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > > + *
> > > + */
> > > +
> > > +#include <linux/err.h>
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/pwm.h>
> > > +
> > > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > > +
> > > +#define PIPGM_PWMC_PWMACT		BIT(5)
> > > +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> > > +#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 *to_visconti_chip(struct pwm_chip *chip)
> > > +{
> > > +	return container_of(chip, struct visconti_pwm_chip, chip);
> > > +}
> > > +
> > > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > +			      const struct pwm_state *state)
> > > +{
> > > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > > +	u32 period, duty_cycle, pwmc0;
> > > +
> > > +	/*
> > > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > > +	 * way the hardware switches atomically from the old setting to the new.
> > > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > > +	 * at low level at all times.
> > 
> > Can you please put a paragraph analogous to the one in pwm-sifive in the
> > same format. This simplified keeping an overview about the oddities of
> > the various supported chips.
> 
> OK, I will check pwm-sifive's, and add.
> 
> > 
> > > +	 */
> > > +	if (!state->enabled) {
> > > +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > > +		return 0;
> > > +	}
> > > +
> > > [...]
> > > +
> > > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > > +				   struct pwm_state *state)
> > > +{
> > > +	struct visconti_pwm_chip *priv = chip_to_priv(chip);
> > > +	u32 period, duty, pwmc0, pwmc0_clk;
> > > +
> > > +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> > > +	if (period)
> > > +		state->enabled = true;
> > > +	else
> > > +		state->enabled = false;
> > 
> > If PIPGM_PCSR is 0 the hardware is still active and setting a new
> > configuration completes the currently running period, right? Then I
> > think having always state->enabled = true is a better match.
>
> If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of
> other registers are written, the values of other registers will not work
> unless PIPGM_PCSR is written.

Correct me if I'm wrong, but how I understand it, PCSR is special as the
other registers are shadow until PCSR is written. (And that is
irrespective of which value is active in PCSR or what is written to
PCSR.)
 
> However, as a logic, if PIPGM_PCSR becomes 0, it is only
> visconti_pwm_apply () in this driver,
> so I think that this process should always be state-> enabled = true
> as you pointed out.
> I wil drop this, thanks.

For me the critical (and only) difference between "off" and
"duty cycle = 0" is that when a new configuration is to be applied. In
the "off" state a new period can (and should) start immediately, while
with "duty_cycle = 0" the rising edge should be delayed until the
currently running period is over.[1]

So the thing to do here (IMHO) is:

Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
with writing a non-zero value to PIPGM_PCSR) completes the currently
running period, then always assume the PWM as enabled.

And so if the hardware is stopped and the counter is reset when 0 is
written to PIPGM_PCSR, model that as enabled = false.

Best regards
Uwe

[1] In practise this is more difficult because several PWMs don't
complete periods in general. But the hardware under discussion luckily
isn't one of these. And (worse) there are other hardware implementations
where off doesn't emit an inactive level.

-- 
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/20210412/3c893eba/attachment.sig>

From ruifeng.zhang0110 at gmail.com  Mon Apr 12 08:08:19 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Mon, 12 Apr 2021 15:08:19 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
Message-ID: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>

From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>

The arm topology still parse from the MPIDR, but it is incomplete.  When
the armv8.3 cpu runs in aarch32 mode, it will parse out the wrong topology.

armv7 (A7) mpidr is:
[11:8]      [7:2]       [1:0]
cluster     reserved    cpu

armv8.3 (A55) mpidr is:
[23:16]     [15:8]      [7:0]
cluster     cpu         thread

For compatibility to keep the function of get capacity from default
cputype, renamed arm parse_dt_topology to get_cputype_capacity and delete
related logic of parse from dt.
Arm using the same parse_dt_topology function as arm64.

The arm device boot step is to look for the default cputype and get cpu
capacity firstly. Then parse the topology and capacity from dt to replace
default values.

Signed-off-by: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
---
 arch/arm/kernel/topology.c    | 18 ++++--------------
 drivers/base/arch_topology.c  |  4 ++--
 include/linux/arch_topology.h |  1 +
 3 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index ef0058de432b..7a4217367c7e 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -72,7 +72,6 @@ static unsigned long *__cpu_capacity;
 #define cpu_capacity(cpu)	__cpu_capacity[cpu]
 
 static unsigned long middle_capacity = 1;
-static bool cap_from_dt = true;
 
 /*
  * Iterate all CPUs' descriptor in DT and compute the efficiency
@@ -82,7 +81,7 @@ static bool cap_from_dt = true;
  * 'average' CPU is of middle capacity. Also see the comments near
  * table_efficiency[] and update_cpu_capacity().
  */
-static void __init parse_dt_topology(void)
+static void __init get_coretype_capacity(void)
 {
 	const struct cpu_efficiency *cpu_eff;
 	struct device_node *cn = NULL;
@@ -105,13 +104,6 @@ static void __init parse_dt_topology(void)
 			continue;
 		}
 
-		if (topology_parse_cpu_capacity(cn, cpu)) {
-			of_node_put(cn);
-			continue;
-		}
-
-		cap_from_dt = false;
-
 		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
 			if (of_device_is_compatible(cn, cpu_eff->compatible))
 				break;
@@ -151,9 +143,6 @@ static void __init parse_dt_topology(void)
 	else
 		middle_capacity = ((max_capacity / 3)
 				>> (SCHED_CAPACITY_SHIFT-1)) + 1;
-
-	if (cap_from_dt)
-		topology_normalize_cpu_scale();
 }
 
 /*
@@ -163,7 +152,7 @@ static void __init parse_dt_topology(void)
  */
 static void update_cpu_capacity(unsigned int cpu)
 {
-	if (!cpu_capacity(cpu) || cap_from_dt)
+	if (!cpu_capacity(cpu))
 		return;
 
 	topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);
@@ -173,7 +162,7 @@ static void update_cpu_capacity(unsigned int cpu)
 }
 
 #else
-static inline void parse_dt_topology(void) {}
+static inline void parse_dt_capacity(void) {}
 static inline void update_cpu_capacity(unsigned int cpuid) {}
 #endif
 
@@ -241,5 +230,6 @@ void __init init_cpu_topology(void)
 	reset_cpu_topology();
 	smp_wmb();
 
+	get_coretype_capacity();
 	parse_dt_topology();
 }
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index de8587cc119e..a45aec356ec4 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -295,7 +295,7 @@ static void parsing_done_workfn(struct work_struct *work)
 core_initcall(free_raw_capacity);
 #endif
 
-#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
 /*
  * This function returns the logic cpu number of the node.
  * There are basically three kinds of return values:
@@ -441,7 +441,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
 	return 0;
 }
 
-static int __init parse_dt_topology(void)
+int __init parse_dt_topology(void)
 {
 	struct device_node *cn, *map;
 	int ret = 0;
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 0f6cd6b73a61..cfa5a5072aa0 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -66,6 +66,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 #define topology_llc_cpumask(cpu)	(&cpu_topology[cpu].llc_sibling)
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
+int __init parse_dt_topology(void);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 void update_siblings_masks(unsigned int cpu);
 void remove_cpu_topology(unsigned int cpuid);
-- 
2.17.1



From flora.fu at mediatek.com  Mon Apr 12 08:19:25 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Mon, 12 Apr 2021 15:19:25 +0800
Subject: [PATCH 3/8] dt-bindings: apu: Add MT8192 APU power domain
In-Reply-To: <20210409182338.GA3895583@robh.at.kernel.org>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-4-git-send-email-flora.fu@mediatek.com>
 <20210409182338.GA3895583@robh.at.kernel.org>
Message-ID: <1618211965.25062.34.camel@mtksdccf07>

Hi, Rob,

In mt8192 hardware, we only control top power domain in kernel.
It is unnecessary to create a specific header just for such purpose. 
I will update the patch in the next version.
Thanks for your review.

Thanks,
Flora


On Fri, 2021-04-09 at 13:23 -0500, Rob Herring wrote:
> On Wed, Apr 07, 2021 at 11:28:01AM +0800, Flora Fu wrote:
> > Create MT8192 APU power domain bindings.
> > Add top power domain id.
> > 
> > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > ---
> >  include/dt-bindings/power/mt8192-apu-power.h | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >  create mode 100644 include/dt-bindings/power/mt8192-apu-power.h
> > 
> > diff --git a/include/dt-bindings/power/mt8192-apu-power.h b/include/dt-bindings/power/mt8192-apu-power.h
> > new file mode 100644
> > index 000000000000..b821bd4811a6
> > --- /dev/null
> > +++ b/include/dt-bindings/power/mt8192-apu-power.h
> > @@ -0,0 +1,11 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright (c) 2021 MediaTek Inc.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_POWER_MT8192_APU_POWER_H
> > +#define _DT_BINDINGS_POWER_MT8192_APU_POWER_H
> > +
> > +#define MT8192_POWER_DOMAIN_APUSYS_TOP	0
> 
> Really, you don't know what the other power domains are? Please make 
> this as complete as possible. These headers create a merge mess.
> 
> Rob


From lkp at intel.com  Mon Apr 12 08:23:56 2021
From: lkp at intel.com (kernel test robot)
Date: Mon, 12 Apr 2021 15:23:56 +0800
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <202104121526.gm7LWDAv-lkp@intel.com>

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on stm32/stm32-next]
[also build test WARNING on usb/usb-testing v5.12-rc7]
[cannot apply to tty/tty-testing next-20210409]
[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]

url:    https://github.com/0day-ci/linux/commits/dillon-minfei-gmail-com/serial-stm32-optimize-spin-lock-usage/20210412-123607
base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
config: riscv-randconfig-r034-20210412 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 9829f5e6b1bca9b61efc629770d28bb9014dec45)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install riscv cross compiling tool for clang build
        # apt-get install binutils-riscv64-linux-gnu
        # https://github.com/0day-ci/linux/commit/a0e81ae10c46f768437d61cd3a3dfd4d1250b375
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review dillon-minfei-gmail-com/serial-stm32-optimize-spin-lock-usage/20210412-123607
        git checkout a0e81ae10c46f768437d61cd3a3dfd4d1250b375
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/tty/serial/stm32-usart.c:280:39: warning: variable 'flags' is uninitialized when used here [-Wuninitialized]
                   spin_unlock_irqrestore(&port->lock, flags);
                                                       ^~~~~
   drivers/tty/serial/stm32-usart.c:217:24: note: initialize the variable 'flags' to silence this warning
           unsigned long c, flags;
                                 ^
                                  = 0
   1 warning generated.


vim +/flags +280 drivers/tty/serial/stm32-usart.c

   211	
   212	static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
   213	{
   214		struct tty_port *tport = &port->state->port;
   215		struct stm32_port *stm32_port = to_stm32_port(port);
   216		const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
   217		unsigned long c, flags;
   218		u32 sr;
   219		char flag;
   220	
   221		if (irqd_is_wakeup_set(irq_get_irq_data(port->irq)))
   222			pm_wakeup_event(tport->tty->dev, 0);
   223	
   224		while (stm32_usart_pending_rx(port, &sr, &stm32_port->last_res,
   225					      threaded)) {
   226			sr |= USART_SR_DUMMY_RX;
   227			flag = TTY_NORMAL;
   228	
   229			/*
   230			 * Status bits has to be cleared before reading the RDR:
   231			 * In FIFO mode, reading the RDR will pop the next data
   232			 * (if any) along with its status bits into the SR.
   233			 * Not doing so leads to misalignement between RDR and SR,
   234			 * and clear status bits of the next rx data.
   235			 *
   236			 * Clear errors flags for stm32f7 and stm32h7 compatible
   237			 * devices. On stm32f4 compatible devices, the error bit is
   238			 * cleared by the sequence [read SR - read DR].
   239			 */
   240			if ((sr & USART_SR_ERR_MASK) && ofs->icr != UNDEF_REG)
   241				writel_relaxed(sr & USART_SR_ERR_MASK,
   242					       port->membase + ofs->icr);
   243	
   244			c = stm32_usart_get_char(port, &sr, &stm32_port->last_res);
   245			port->icount.rx++;
   246			if (sr & USART_SR_ERR_MASK) {
   247				if (sr & USART_SR_ORE) {
   248					port->icount.overrun++;
   249				} else if (sr & USART_SR_PE) {
   250					port->icount.parity++;
   251				} else if (sr & USART_SR_FE) {
   252					/* Break detection if character is null */
   253					if (!c) {
   254						port->icount.brk++;
   255						if (uart_handle_break(port))
   256							continue;
   257					} else {
   258						port->icount.frame++;
   259					}
   260				}
   261	
   262				sr &= port->read_status_mask;
   263	
   264				if (sr & USART_SR_PE) {
   265					flag = TTY_PARITY;
   266				} else if (sr & USART_SR_FE) {
   267					if (!c)
   268						flag = TTY_BREAK;
   269					else
   270						flag = TTY_FRAME;
   271				}
   272			}
   273	
   274			if (uart_handle_sysrq_char(port, c))
   275				continue;
   276			uart_insert_char(port, sr, USART_SR_ORE, c, flag);
   277		}
   278	
   279		if (threaded)
 > 280			spin_unlock_irqrestore(&port->lock, flags);
   281		else
   282			spin_unlock(&port->lock);
   283	
   284		tty_flip_buffer_push(tport);
   285	
   286		if (threaded)
   287			spin_lock_irqsave(&port->lock, flags);
   288		else
   289			spin_lock(&port->lock);
   290	}
   291	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36623 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210412/579f4817/attachment-0001.gz>

From dillon.minfei at gmail.com  Mon Apr 12 08:29:50 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Mon, 12 Apr 2021 15:29:50 +0800
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <202104121526.gm7LWDAv-lkp@intel.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <202104121526.gm7LWDAv-lkp@intel.com>
Message-ID: <CAL9mu0LDi2-aAU=cGDhBb6fkxWRKUNeRXcR-q1snJERm5ju=QQ@mail.gmail.com>

Hi lkp,

Thanks for the reminder.
I just noticed this from greg's mail. still waiting for his response
about the proper solution for this patch.
After that i will update version 2 for it.

Your test is really efficient, thanks.

Best regards,

Dillon.

On Mon, Apr 12, 2021 at 3:25 PM kernel test robot <lkp at intel.com> wrote:
>
> Hi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on stm32/stm32-next]
> [also build test WARNING on usb/usb-testing v5.12-rc7]
> [cannot apply to tty/tty-testing next-20210409]
> [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]
>
> url:    https://github.com/0day-ci/linux/commits/dillon-minfei-gmail-com/serial-stm32-optimize-spin-lock-usage/20210412-123607
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git stm32-next
> config: riscv-randconfig-r034-20210412 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 9829f5e6b1bca9b61efc629770d28bb9014dec45)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # install riscv cross compiling tool for clang build
>         # apt-get install binutils-riscv64-linux-gnu
>         # https://github.com/0day-ci/linux/commit/a0e81ae10c46f768437d61cd3a3dfd4d1250b375
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review dillon-minfei-gmail-com/serial-stm32-optimize-spin-lock-usage/20210412-123607
>         git checkout a0e81ae10c46f768437d61cd3a3dfd4d1250b375
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/tty/serial/stm32-usart.c:280:39: warning: variable 'flags' is uninitialized when used here [-Wuninitialized]
>                    spin_unlock_irqrestore(&port->lock, flags);
>                                                        ^~~~~
>    drivers/tty/serial/stm32-usart.c:217:24: note: initialize the variable 'flags' to silence this warning
>            unsigned long c, flags;
>                                  ^
>                                   = 0
>    1 warning generated.
>
>
> vim +/flags +280 drivers/tty/serial/stm32-usart.c
>
>    211
>    212  static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>    213  {
>    214          struct tty_port *tport = &port->state->port;
>    215          struct stm32_port *stm32_port = to_stm32_port(port);
>    216          const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
>    217          unsigned long c, flags;
>    218          u32 sr;
>    219          char flag;
>    220
>    221          if (irqd_is_wakeup_set(irq_get_irq_data(port->irq)))
>    222                  pm_wakeup_event(tport->tty->dev, 0);
>    223
>    224          while (stm32_usart_pending_rx(port, &sr, &stm32_port->last_res,
>    225                                        threaded)) {
>    226                  sr |= USART_SR_DUMMY_RX;
>    227                  flag = TTY_NORMAL;
>    228
>    229                  /*
>    230                   * Status bits has to be cleared before reading the RDR:
>    231                   * In FIFO mode, reading the RDR will pop the next data
>    232                   * (if any) along with its status bits into the SR.
>    233                   * Not doing so leads to misalignement between RDR and SR,
>    234                   * and clear status bits of the next rx data.
>    235                   *
>    236                   * Clear errors flags for stm32f7 and stm32h7 compatible
>    237                   * devices. On stm32f4 compatible devices, the error bit is
>    238                   * cleared by the sequence [read SR - read DR].
>    239                   */
>    240                  if ((sr & USART_SR_ERR_MASK) && ofs->icr != UNDEF_REG)
>    241                          writel_relaxed(sr & USART_SR_ERR_MASK,
>    242                                         port->membase + ofs->icr);
>    243
>    244                  c = stm32_usart_get_char(port, &sr, &stm32_port->last_res);
>    245                  port->icount.rx++;
>    246                  if (sr & USART_SR_ERR_MASK) {
>    247                          if (sr & USART_SR_ORE) {
>    248                                  port->icount.overrun++;
>    249                          } else if (sr & USART_SR_PE) {
>    250                                  port->icount.parity++;
>    251                          } else if (sr & USART_SR_FE) {
>    252                                  /* Break detection if character is null */
>    253                                  if (!c) {
>    254                                          port->icount.brk++;
>    255                                          if (uart_handle_break(port))
>    256                                                  continue;
>    257                                  } else {
>    258                                          port->icount.frame++;
>    259                                  }
>    260                          }
>    261
>    262                          sr &= port->read_status_mask;
>    263
>    264                          if (sr & USART_SR_PE) {
>    265                                  flag = TTY_PARITY;
>    266                          } else if (sr & USART_SR_FE) {
>    267                                  if (!c)
>    268                                          flag = TTY_BREAK;
>    269                                  else
>    270                                          flag = TTY_FRAME;
>    271                          }
>    272                  }
>    273
>    274                  if (uart_handle_sysrq_char(port, c))
>    275                          continue;
>    276                  uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>    277          }
>    278
>    279          if (threaded)
>  > 280                  spin_unlock_irqrestore(&port->lock, flags);
>    281          else
>    282                  spin_unlock(&port->lock);
>    283
>    284          tty_flip_buffer_push(tport);
>    285
>    286          if (threaded)
>    287                  spin_lock_irqsave(&port->lock, flags);
>    288          else
>    289                  spin_lock(&port->lock);
>    290  }
>    291
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From yongqiang.niu at mediatek.com  Mon Apr 12 08:25:31 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 15:25:31 +0800
Subject: adjust rdma fifo threshold calculate formula
Message-ID: <1618212332-3547-1-git-send-email-yongqiang.niu@mediatek.com>

This patch base Linux 5.12-rc2 provide one patch

Yongqiang Niu (1):
  drm/mediatek: adjust rdma fifo threshold calculate formula

 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 08:25:32 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 15:25:32 +0800
Subject: [PATCH v1] drm/mediatek: adjust rdma fifo threshold calculate formula
In-Reply-To: <1618212332-3547-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618212332-3547-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618212332-3547-2-git-send-email-yongqiang.niu@mediatek.com>

the orginal formula will caused rdma fifo threshold config overflow

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 728aaad..8c9371b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -167,7 +167,7 @@ void mtk_rdma_config(struct device *dev, unsigned int width,
 	 * output threshold to 6 microseconds with 7/6 overhead to
 	 * account for blanking, and with a pixel depth of 4 bytes:
 	 */
-	threshold = width * height * vrefresh * 4 * 7 / 1000000;
+	threshold = rdma_fifo_size * 7 / 10;
 	reg = RDMA_FIFO_UNDERFLOW_EN |
 	      RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
 	      RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
-- 
1.8.1.1.dirty

From dinghao.liu at zju.edu.cn  Mon Apr 12 08:31:54 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Mon, 12 Apr 2021 15:31:54 +0800
Subject: [PATCH] [v2] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
Message-ID: <20210412073154.25011-1-dinghao.liu@zju.edu.cn>

There is a PM usage counter decrement after zynqmp_qspi_init_hw()
without any refcount increment, which leads to refcount leak.Add
a refcount increment to balance the refcount. Also set
auto_runtime_pm to resume suspended spi controller.

Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---
changelog:

v2: - Add a refcount increment to fix refcout leak instead of the
      refcount decrement on error.
      Set ctlr->auto_runtime_pm = true.
---
 drivers/spi/spi-zynqmp-gqspi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..8b21c7b0e7eb 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1160,6 +1160,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
 	/* QSPI controller initializations */
 	zynqmp_qspi_init_hw(xqspi);
 
@@ -1187,6 +1188,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
 			    SPI_TX_DUAL | SPI_TX_QUAD;
 	ctlr->dev.of_node = np;
+	ctlr->auto_runtime_pm = true;
 
 	ret = devm_spi_register_controller(&pdev->dev, ctlr);
 	if (ret) {
-- 
2.17.1



From ulf.hansson at linaro.org  Mon Apr 12 08:38:40 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 12 Apr 2021 09:38:40 +0200
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <20210408015218.20560-2-steven_lee@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
Message-ID: <CAPDyKFr=Gtwu4v22FBaax5EjRbXTNez1N2ZQxP=v0LKGFTCovw@mail.gmail.com>

On Thu, 8 Apr 2021 at 03:52, Steven Lee <steven_lee at aspeedtech.com> wrote:
>
> AST2600-A2 EVB provides the reference design for enabling SD bus power
> and toggling SD bus signal voltage by GPIO pins.
> Add the definition and example for power-gpio and power-switch-gpio
> properties.
>
> In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> a 1.8v and a 3.3v power load switch that providing signal voltage to
> SD1 bus.
> If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> disabled.
> If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> voltage is 3.3v. Otherwise, 1.8v power load switch will be enabled, SD1
> signal voltage becomes 1.8v.
>
> AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and GPIOV3
> as power-switch-gpio.

Thanks for sharing the details, it certainly helps while reviewing.

>
> Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> ---
>  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> index 987b287f3bff..515a74614f3c 100644
> --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> @@ -37,6 +37,14 @@ properties:
>    clocks:
>      maxItems: 1
>      description: The SD/SDIO controller clock gate
> +  power-gpio:
> +    description:
> +      The GPIO for enabling/disabling SD bus power.
> +    maxItems: 1
> +  power-switch-gpio:
> +    description:
> +      The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> +    maxItems: 1


>
>  patternProperties:
>    "^sdhci@[0-9a-f]+$":
> @@ -61,6 +69,14 @@ patternProperties:
>        sdhci,auto-cmd12:
>          type: boolean
>          description: Specifies that controller should use auto CMD12
> +      power-gpio:
> +        description:
> +          The GPIO for enabling/disabling SD bus power.
> +        maxItems: 1
> +      power-switch-gpio:
> +        description:
> +          The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> +        maxItems: 1
>      required:

Please do not model these as GPIO pins like this. Instead, it's better
to model them as gpio regulators, since the mmc core manages them as
regulators.

We have a vmmc regulator (corresponding to vdd) and a vqmmc regulator
(corresponding the signal-voltage level). These are also described in
the common mmc DT bindings, see
Documentation/devicetree/bindings/mmc/mmc-controller.yaml.

>        - compatible
>        - reg
> @@ -80,6 +96,7 @@ required:
>  examples:
>    - |
>      #include <dt-bindings/clock/aspeed-clock.h>
> +    #include <dt-bindings/gpio/aspeed-gpio.h>
>      sdc at 1e740000 {
>              compatible = "aspeed,ast2500-sd-controller";
>              reg = <0x1e740000 0x100>;
> @@ -94,6 +111,10 @@ examples:
>                      interrupts = <26>;
>                      sdhci,auto-cmd12;
>                      clocks = <&syscon ASPEED_CLK_SDIO>;
> +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
> +                                     GPIO_ACTIVE_HIGH>;
> +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 1)
> +                                     GPIO_ACTIVE_HIGH>;
>              };
>
>              sdhci1: sdhci at 200 {
> @@ -102,5 +123,9 @@ examples:
>                      interrupts = <26>;
>                      sdhci,auto-cmd12;
>                      clocks = <&syscon ASPEED_CLK_SDIO>;
> +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
> +                                     GPIO_ACTIVE_HIGH>;
> +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 3)
> +                                     GPIO_ACTIVE_HIGH>;
>              };
>      };

Kind regards
Uffe


From maz at kernel.org  Mon Apr 12 08:49:19 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 08:49:19 +0100
Subject: [RFC] KVM: arm64: Support FEAT_CCIDX
In-Reply-To: <f605f8cd-71a4-7f4e-ffb7-7b5af738e85e@hisilicon.com>
References: <1618042597-59294-1-git-send-email-zhangshaokun@hisilicon.com>
 <875z0ufori.wl-maz@kernel.org>
 <f605f8cd-71a4-7f4e-ffb7-7b5af738e85e@hisilicon.com>
Message-ID: <87h7kcnds0.wl-maz@kernel.org>

Hi Shaokun,

On Mon, 12 Apr 2021 03:22:03 +0100,
Shaokun Zhang <zhangshaokun at hisilicon.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/10 17:54, Marc Zyngier wrote:
> > On Sat, 10 Apr 2021 09:16:37 +0100,
> > Shaokun Zhang <zhangshaokun at hisilicon.com> wrote:
> >>
> >> CCSIDR_EL1 can be implemented as 64-bit format inferred by CCIDX field
> >> in ID_AA64MMFR2_EL1. The bits of Numsets and Associativity are different
> >> from the 32-bit format. Let's support this feature.
> >>
> >> Cc: Marc Zyngier <maz at kernel.org>
> >> Cc: James Morse <james.morse at arm.com>
> >> Cc: Alexandru Elisei <alexandru.elisei at arm.com>
> >> Cc: Suzuki K Poulose <suzuki.poulose at arm.com>
> >> Signed-off-by: Shaokun Zhang <zhangshaokun at hisilicon.com>
> >> ---
> >>  arch/arm64/kvm/sys_regs.c | 27 +++++++++++++++++++--------
> >>  1 file changed, 19 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> >> index 52fdb9a015a4..0dc822cef20b 100644
> >> --- a/arch/arm64/kvm/sys_regs.c
> >> +++ b/arch/arm64/kvm/sys_regs.c
> >> @@ -18,6 +18,7 @@
> >>  
> >>  #include <asm/cacheflush.h>
> >>  #include <asm/cputype.h>
> >> +#include <asm/cpufeature.h>
> > 
> > If you are going to add this (why?), at least add it in alphabetic order.
> 
> cpuid_feature_extract_unsigned_field will be used later.
> It shall do in alphabetic order.

We already use this function all over the place, and it is already
dragged in via many other paths. Anyway, that's not the biggest
problem.

> 
> > 
> >>  #include <asm/debug-monitors.h>
> >>  #include <asm/esr.h>
> >>  #include <asm/kvm_arm.h>
> >> @@ -95,9 +96,9 @@ static u32 cache_levels;
> >>  #define CSSELR_MAX 14
> >>  
> >>  /* Which cache CCSIDR represents depends on CSSELR value. */
> >> -static u32 get_ccsidr(u32 csselr)
> >> +static u64 get_ccsidr(u32 csselr)
> >>  {
> >> -	u32 ccsidr;
> >> +	u64 ccsidr;
> >>  
> >>  	/* Make sure noone else changes CSSELR during this! */
> >>  	local_irq_disable();
> >> @@ -1275,12 +1276,16 @@ static bool access_csselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>  static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>  			  const struct sys_reg_desc *r)
> >>  {
> >> -	u32 csselr;
> >> +	u32 csselr, ccidx;
> >> +	u64 mmfr2;
> >>  
> >>  	if (p->is_write)
> >>  		return write_to_read_only(vcpu, p, r);
> >>  
> >>  	csselr = vcpu_read_sys_reg(vcpu, CSSELR_EL1);
> >> +	mmfr2 = read_sysreg_s(SYS_ID_AA64MMFR2_EL1);
> >> +	ccidx = cpuid_feature_extract_unsigned_field(mmfr2,
> >> +						     ID_AA64MMFR2_CCIDX_SHIFT);
> > 
> > What happens on an asymmetric system where only some of the CPUs have
> > FEAT_CCIDX?
> 
> If other CPUs don't have FEAT_CCIDX, its value is 0b0000 while
> CCSIDR_EL1 is 32-bit format.
>

You are missing the point: CPU-A has CCIDX, CPU-B doesn't. My vcpu
runs on CPU-A, gets preempted right after the read of
ID_AA64MMFR2_EL1, and then scheduled on CPU-B. You will now compute
the guest view of CCSIDR_EL1 with CPU-B's value, but interpreting it
with CPU-A's configuration. That's totally broken.

> > 
> >>  	p->regval = get_ccsidr(csselr);
> >>  
> >>  	/*
> >> @@ -1295,8 +1300,13 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> >>  	 * geometry (which is not permitted by the architecture), they would
> >>  	 * only do so for virtually indexed caches.]
> >>  	 */
> >> -	if (!(csselr & 1)) // data or unified cache
> >> -		p->regval &= ~GENMASK(27, 3);
> >> +	if (!(csselr & 1)) { // data or unified cache
> >> +		if (ccidx)
> >> +			p->regval &= ~(GENMASK(23, 3) | GENMASK(55, 32));
> >> +		else
> >> +			p->regval &= ~GENMASK(27, 3);
> >> +	}
> >> +
> >>  	return true;
> >>  }
> >>  
> >> @@ -2521,7 +2531,7 @@ static bool is_valid_cache(u32 val)
> >>  static int demux_c15_get(u64 id, void __user *uaddr)
> >>  {
> >>  	u32 val;
> >> -	u32 __user *uval = uaddr;
> >> +	u64 __user *uval = uaddr;
> > 
> > What? Has the user API changed while I wasn't looking? Getting CCSIDR
> > can only return a 32bit quantity on AArch32. In fact, CCSIDR is
> > *always* 32bit, CCIDX or not. I have no idea what you are trying to do
> > here, but at best you are now corrupting 32bit of userspace.
> > 
> 
> Oops, I really missed this.
> 
> >>  
> >>  	/* Fail if we have unknown bits set. */
> >>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> >> @@ -2545,8 +2555,9 @@ static int demux_c15_get(u64 id, void __user *uaddr)
> >>  
> >>  static int demux_c15_set(u64 id, void __user *uaddr)
> >>  {
> >> -	u32 val, newval;
> >> -	u32 __user *uval = uaddr;
> >> +	u32 val;
> >> +	u64 newval;
> >> +	u64 __user *uval = uaddr;
> > 
> > Same brokenness.
> > 
> >>  
> >>  	/* Fail if we have unknown bits set. */
> >>  	if (id & ~(KVM_REG_ARCH_MASK|KVM_REG_SIZE_MASK|KVM_REG_ARM_COPROC_MASK
> > 
> > What about CCSIDR2_EL1, which is mandatory when FEAT_CCSIDX is
> > present? How about the AArch32 handling of that register? I don't
> > think you have though this one through.
> 
> To be honest, AArch32 is not considered directly and I sent this only
> as RFC.

If you don't consider AArch32 when writing a patch, please don't send
it. AArch32 guests are fully supported, and a patch that breaks them
isn't acceptable.

Also, a RFC patch doesn't mean things are allowed to break. We use RFC
as way to ask for people feedback on a design, but the proposed
implementation has to be a valid one. That's not a license to send
broken stuff.

> When I wrote some flush cache code using by set/way mode and
> noticed that CCSIDR_EL1 is used here.
>
> > 
> > Another question is: why should we care at all? Why don't we drop all
> > that and only implement a virtual cache topology? A VM shouldn't care
> > at all about this, and we are already lying about the topology anyway.
> > We could even get the VMM to set whatever stupid topology it wants for
> > the sake of it (and to restore previously created VMs).
> 
> Got it,
> 
> Thanks for your detailed comments.

Thanks,

	M.

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


From ulf.hansson at linaro.org  Mon Apr 12 08:50:36 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 12 Apr 2021 09:50:36 +0200
Subject: [PATCH] mmc: s3cmci: move to use request_irq by IRQF_NO_AUTOEN
 flag
In-Reply-To: <1617765339-28946-1-git-send-email-tiantao6@hisilicon.com>
References: <1617765339-28946-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <CAPDyKFo4L4d0URRyBBj8wFnbJpaMkGrMzNQaGKFSv_PaHcz2aQ@mail.gmail.com>

On Wed, 7 Apr 2021 at 05:15, Tian Tao <tiantao6 at hisilicon.com> wrote:
>
> disable_irq() after request_irq() still has a time gap in which
> interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
> disable IRQ auto-enable because of requesting.
>
> this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
> is being merged: https://lore.kernel.org/patchwork/patch/1388765/
>
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>

FYI, I will have to wait to apply the $subject patch until the above
change (which is commit cbe16f35bee6 in linux-next) is available in an
rc.

Kind regards
Uffe


> ---
>  drivers/mmc/host/s3cmci.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index 0ca6f6d..8d5929a 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -1578,17 +1578,12 @@ static int s3cmci_probe(struct platform_device *pdev)
>                 goto probe_iounmap;
>         }
>
> -       if (request_irq(host->irq, s3cmci_irq, 0, DRIVER_NAME, host)) {
> +       if (request_irq(host->irq, s3cmci_irq, IRQF_NO_AUTOEN, DRIVER_NAME, host)) {
>                 dev_err(&pdev->dev, "failed to request mci interrupt.\n");
>                 ret = -ENOENT;
>                 goto probe_iounmap;
>         }
>
> -       /* We get spurious interrupts even when we have set the IMSK
> -        * register to ignore everything, so use disable_irq() to make
> -        * ensure we don't lock the system with un-serviceable requests. */
> -
> -       disable_irq(host->irq);
>         host->irq_state = false;
>
>         /* Depending on the dma state, get a DMA channel to use. */
> --
> 2.7.4
>


From ulf.hansson at linaro.org  Mon Apr 12 08:52:04 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 12 Apr 2021 09:52:04 +0200
Subject: [PATCH 1/3] dt-bindings: mmc: iproc-sdhci: Convert to json-schema
In-Reply-To: <20210406104802.20898-2-nsaenz@kernel.org>
References: <20210406104802.20898-1-nsaenz@kernel.org>
 <20210406104802.20898-2-nsaenz@kernel.org>
Message-ID: <CAPDyKFrBSVooaNNiVgr12o9OLZ_3_0OExKBoW+QyLXftzR+8cw@mail.gmail.com>

On Tue, 6 Apr 2021 at 12:48, Nicolas Saenz Julienne <nsaenz at kernel.org> wrote:
>
> Convert the brcm,iproc-sdhci binding to DT schema format using json-schema
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>

Applied for next, thanks! (I guess patch2 and patch3 needs a re-spin?)

Kind regards
Uffe


>
> ---
>
>  .../bindings/mmc/brcm,iproc-sdhci.yaml        | 63 +++++++++++++++++++
>  .../bindings/mmc/brcm,sdhci-iproc.txt         | 37 -----------
>  2 files changed, 63 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
>  delete mode 100644 Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
> new file mode 100644
> index 000000000000..6f569fbfa134
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/brcm,iproc-sdhci.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mmc/brcm,iproc-sdhci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom IPROC SDHCI controller
> +
> +maintainers:
> +  - Ray Jui <ray.jui at broadcom.com>
> +  - Scott Branden <scott.branden at broadcom.com>
> +  - Nicolas Saenz Julienne <nsaenz at kernel.org>
> +
> +allOf:
> +  - $ref: mmc-controller.yaml#
> +
> +properties:
> +  compatible:
> +    enum:
> +      - brcm,bcm2835-sdhci
> +      - brcm,bcm2711-emmc2
> +      - brcm,sdhci-iproc-cygnus
> +      - brcm,sdhci-iproc
> +
> +  reg:
> +    minItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +    description:
> +      Handle to core clock for the sdhci controller.
> +
> +  sdhci,auto-cmd12:
> +    type: boolean
> +    description: Specifies that controller should use auto CMD12
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/clock/bcm-cygnus.h>
> +
> +    mmc at 18041000 {
> +      compatible = "brcm,sdhci-iproc-cygnus";
> +      reg = <0x18041000 0x100>;
> +      interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> +      clocks = <&lcpll0_clks BCM_CYGNUS_LCPLL0_SDIO_CLK>;
> +      bus-width = <4>;
> +      sdhci,auto-cmd12;
> +      no-1-8-v;
> +    };
> +...
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> deleted file mode 100644
> index 09d87cc1182a..000000000000
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -Broadcom IPROC SDHCI controller
> -
> -This file documents differences between the core properties described
> -by mmc.txt and the properties that represent the IPROC SDHCI controller.
> -
> -Required properties:
> -- compatible : Should be one of the following
> -              "brcm,bcm2835-sdhci"
> -              "brcm,bcm2711-emmc2"
> -              "brcm,sdhci-iproc-cygnus"
> -              "brcm,sdhci-iproc"
> -
> -Use brcm2835-sdhci for the eMMC controller on the BCM2835 (Raspberry Pi) and
> -bcm2711-emmc2 for the additional eMMC2 controller on BCM2711.
> -
> -Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
> -restricted to 32bit host accesses to SDHCI registers.
> -
> -Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
> -8, 16, 32-bit host access to SDHCI register.
> -
> -- clocks : The clock feeding the SDHCI controller.
> -
> -Optional properties:
> -  - sdhci,auto-cmd12: specifies that controller should use auto CMD12.
> -
> -Example:
> -
> -sdhci0: sdhci at 18041000 {
> -       compatible = "brcm,sdhci-iproc-cygnus";
> -       reg = <0x18041000 0x100>;
> -       interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> -       clocks = <&lcpll0_clks BCM_CYGNUS_LCPLL0_SDIO_CLK>;
> -       bus-width = <4>;
> -       sdhci,auto-cmd12;
> -       no-1-8-v;
> -};
> --
> 2.30.2
>


From ulf.hansson at linaro.org  Mon Apr 12 08:52:22 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 12 Apr 2021 09:52:22 +0200
Subject: [PATCH -next] mmc: owl-mmc: Remove unnecessary error log
In-Reply-To: <20210409023349.3325907-1-qiulaibin@huawei.com>
References: <20210409023349.3325907-1-qiulaibin@huawei.com>
Message-ID: <CAPDyKFrwp6tbaHt6nctnTgppG5PsS2Hcb-BPhBT6N0-fmcpAWA@mail.gmail.com>

On Fri, 9 Apr 2021 at 04:24, Laibin Qiu <qiulaibin at huawei.com> wrote:
>
> devm_ioremap_resource() has recorded error log, so it's
> unnecessary to record log again.
>
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/owl-mmc.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/mmc/host/owl-mmc.c b/drivers/mmc/host/owl-mmc.c
> index 5490962dc8e5..3dc143b03939 100644
> --- a/drivers/mmc/host/owl-mmc.c
> +++ b/drivers/mmc/host/owl-mmc.c
> @@ -581,7 +581,6 @@ static int owl_mmc_probe(struct platform_device *pdev)
>         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         owl_host->base = devm_ioremap_resource(&pdev->dev, res);
>         if (IS_ERR(owl_host->base)) {
> -               dev_err(&pdev->dev, "Failed to remap registers\n");
>                 ret = PTR_ERR(owl_host->base);
>                 goto err_free_host;
>         }
> --
> 2.25.1
>


From ulf.hansson at linaro.org  Mon Apr 12 08:52:25 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 12 Apr 2021 09:52:25 +0200
Subject: [PATCH -next] mmc: sdhci-st: Remove unnecessary error log
In-Reply-To: <20210409023801.3326572-1-qiulaibin@huawei.com>
References: <20210409023801.3326572-1-qiulaibin@huawei.com>
Message-ID: <CAPDyKFqbvZot3mFiManMaZtZw8Cuau-4ewOJSVBdR-MeZU-JwA@mail.gmail.com>

On Fri, 9 Apr 2021 at 04:28, Laibin Qiu <qiulaibin at huawei.com> wrote:
>
> devm_ioremap_resource() has recorded error log, so it's
> unnecessary to record log again.
>
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Laibin Qiu <qiulaibin at huawei.com>

Applied for next, thanks!

Kind regards
Uffe


> ---
>  drivers/mmc/host/sdhci-st.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
> index 78941ac3a1d6..d41582c21aa3 100644
> --- a/drivers/mmc/host/sdhci-st.c
> +++ b/drivers/mmc/host/sdhci-st.c
> @@ -400,10 +400,8 @@ static int sdhci_st_probe(struct platform_device *pdev)
>         res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>                                            "top-mmc-delay");
>         pdata->top_ioaddr = devm_ioremap_resource(&pdev->dev, res);
> -       if (IS_ERR(pdata->top_ioaddr)) {
> -               dev_warn(&pdev->dev, "FlashSS Top Dly registers not available");
> +       if (IS_ERR(pdata->top_ioaddr))
>                 pdata->top_ioaddr = NULL;
> -       }
>
>         pltfm_host->clk = clk;
>         pdata->icnclk = icnclk;
> --
> 2.25.1
>


From tomi.valkeinen at ideasonboard.com  Mon Apr 12 08:53:05 2021
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 12 Apr 2021 10:53:05 +0300
Subject: [PATCH 1/2] ARM: dts: dra76-evm: remove ov5640
Message-ID: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>

DRA76 EVM boards are not shipped with OV5640 sensor module, it is a
separate purchase. OV5640 module is also just one of the possible
sensors or capture boards you can connect.

However, for some reason, OV5640 has been added to the board dts file,
making it cumbersome to use other sensors.

Remove the OV5640 from the dts file so that it is easy to use other
sensors via DT overlays.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 arch/arm/boot/dts/dra76-evm.dts | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 9bd01ae40b1d..f3c900e1b953 100644
--- a/arch/arm/boot/dts/dra76-evm.dts
+++ b/arch/arm/boot/dts/dra76-evm.dts
@@ -158,12 +158,6 @@ aic_dvdd: fixedregulator-aic_dvdd {
 		regulator-max-microvolt = <1800000>;
 	};
 
-	clk_ov5640_fixed: clock {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <24000000>;
-	};
-
 	hdmi0: connector {
 		compatible = "hdmi-connector";
 		label = "hdmi";
@@ -409,22 +403,6 @@ tlv320aic3106: tlv320aic3106 at 19 {
 &i2c5 {
 	status = "okay";
 	clock-frequency = <400000>;
-
-	ov5640 at 3c {
-		compatible = "ovti,ov5640";
-		reg = <0x3c>;
-
-		clocks = <&clk_ov5640_fixed>;
-		clock-names = "xclk";
-
-		port {
-			csi2_cam0: endpoint {
-				remote-endpoint = <&csi2_phy0>;
-				clock-lanes = <0>;
-				data-lanes = <1 2>;
-			};
-		};
-	};
 };
 
 &cpu0 {
@@ -574,11 +552,6 @@ can-transceiver {
 };
 
 &csi2_0 {
-	csi2_phy0: endpoint {
-		remote-endpoint = <&csi2_cam0>;
-		clock-lanes = <0>;
-		data-lanes = <1 2>;
-	};
 };
 
 &ipu2 {
-- 
2.25.1



From tomi.valkeinen at ideasonboard.com  Mon Apr 12 08:53:06 2021
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 12 Apr 2021 10:53:06 +0300
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
Message-ID: <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>

AM654 EVM boards are not shipped with OV5640 sensor module, it is a
separate purchase. OV5640 module is also just one of the possible
sensors or capture boards you can connect.

However, for some reason, OV5640 has been added to the board dts file,
making it cumbersome to use other sensors.

Remove the OV5640 from the dts file so that it is easy to use other
sensors via DT overlays.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---
 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
 1 file changed, 27 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index fe3043943906..76358b4944e1 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -85,12 +85,6 @@ sw6 {
 			gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
 		};
 	};
-
-	clk_ov5640_fixed: clock {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <24000000>;
-	};
 };
 
 &wkup_pmx0 {
@@ -288,22 +282,6 @@ &main_i2c1 {
 	pinctrl-0 = <&main_i2c1_pins_default>;
 	clock-frequency = <400000>;
 
-	ov5640: camera at 3c {
-		compatible = "ovti,ov5640";
-		reg = <0x3c>;
-
-		clocks = <&clk_ov5640_fixed>;
-		clock-names = "xclk";
-
-		port {
-			csi2_cam0: endpoint {
-				remote-endpoint = <&csi2_phy0>;
-				clock-lanes = <0>;
-				data-lanes = <1 2>;
-			};
-		};
-	};
-
 };
 
 &main_i2c2 {
@@ -497,11 +475,6 @@ flash at 0{
 };
 
 &csi2_0 {
-	csi2_phy0: endpoint {
-		remote-endpoint = <&csi2_cam0>;
-		clock-lanes = <0>;
-		data-lanes = <1 2>;
-	};
 };
 
 &mcu_cpsw {
-- 
2.25.1



From laurent.pinchart at ideasonboard.com  Mon Apr 12 09:00:24 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 12 Apr 2021 11:00:24 +0300
Subject: [PATCH 1/2] ARM: dts: dra76-evm: remove ov5640
In-Reply-To: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
Message-ID: <YHP+GDq2omVJwCfq@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Mon, Apr 12, 2021 at 10:53:05AM +0300, Tomi Valkeinen wrote:
> DRA76 EVM boards are not shipped with OV5640 sensor module, it is a
> separate purchase. OV5640 module is also just one of the possible
> sensors or capture boards you can connect.
> 
> However, for some reason, OV5640 has been added to the board dts file,
> making it cumbersome to use other sensors.
> 
> Remove the OV5640 from the dts file so that it is easy to use other
> sensors via DT overlays.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  arch/arm/boot/dts/dra76-evm.dts | 27 ---------------------------
>  1 file changed, 27 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
> index 9bd01ae40b1d..f3c900e1b953 100644
> --- a/arch/arm/boot/dts/dra76-evm.dts
> +++ b/arch/arm/boot/dts/dra76-evm.dts
> @@ -158,12 +158,6 @@ aic_dvdd: fixedregulator-aic_dvdd {
>  		regulator-max-microvolt = <1800000>;
>  	};
>  
> -	clk_ov5640_fixed: clock {
> -		compatible = "fixed-clock";
> -		#clock-cells = <0>;
> -		clock-frequency = <24000000>;
> -	};
> -
>  	hdmi0: connector {
>  		compatible = "hdmi-connector";
>  		label = "hdmi";
> @@ -409,22 +403,6 @@ tlv320aic3106: tlv320aic3106 at 19 {
>  &i2c5 {
>  	status = "okay";
>  	clock-frequency = <400000>;
> -
> -	ov5640 at 3c {
> -		compatible = "ovti,ov5640";
> -		reg = <0x3c>;
> -
> -		clocks = <&clk_ov5640_fixed>;
> -		clock-names = "xclk";
> -
> -		port {
> -			csi2_cam0: endpoint {
> -				remote-endpoint = <&csi2_phy0>;
> -				clock-lanes = <0>;
> -				data-lanes = <1 2>;
> -			};
> -		};
> -	};
>  };

You could drop the node completely.

>  
>  &cpu0 {
> @@ -574,11 +552,6 @@ can-transceiver {
>  };
>  
>  &csi2_0 {
> -	csi2_phy0: endpoint {
> -		remote-endpoint = <&csi2_cam0>;
> -		clock-lanes = <0>;
> -		data-lanes = <1 2>;
> -	};
>  };

And here too.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Is there an overlay available somewhere for this ?

>  
>  &ipu2 {

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Mon Apr 12 09:00:59 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Mon, 12 Apr 2021 11:00:59 +0300
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
Message-ID: <YHP+O3HPCCWOQRb0@pendragon.ideasonboard.com>

Hi Tomi,

Thank you for the patch.

On Mon, Apr 12, 2021 at 10:53:06AM +0300, Tomi Valkeinen wrote:
> AM654 EVM boards are not shipped with OV5640 sensor module, it is a
> separate purchase. OV5640 module is also just one of the possible
> sensors or capture boards you can connect.
> 
> However, for some reason, OV5640 has been added to the board dts file,
> making it cumbersome to use other sensors.
> 
> Remove the OV5640 from the dts file so that it is easy to use other
> sensors via DT overlays.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
>  1 file changed, 27 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index fe3043943906..76358b4944e1 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> @@ -85,12 +85,6 @@ sw6 {
>  			gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
>  		};
>  	};
> -
> -	clk_ov5640_fixed: clock {
> -		compatible = "fixed-clock";
> -		#clock-cells = <0>;
> -		clock-frequency = <24000000>;
> -	};
>  };
>  
>  &wkup_pmx0 {
> @@ -288,22 +282,6 @@ &main_i2c1 {
>  	pinctrl-0 = <&main_i2c1_pins_default>;
>  	clock-frequency = <400000>;
>  
> -	ov5640: camera at 3c {
> -		compatible = "ovti,ov5640";
> -		reg = <0x3c>;
> -
> -		clocks = <&clk_ov5640_fixed>;
> -		clock-names = "xclk";
> -
> -		port {
> -			csi2_cam0: endpoint {
> -				remote-endpoint = <&csi2_phy0>;
> -				clock-lanes = <0>;
> -				data-lanes = <1 2>;
> -			};
> -		};
> -	};
> -
>  };

As for patch 1/2, you could drop the two nodes completely. Same question
about overlay availability.

>  
>  &main_i2c2 {
> @@ -497,11 +475,6 @@ flash at 0{
>  };
>  
>  &csi2_0 {
> -	csi2_phy0: endpoint {
> -		remote-endpoint = <&csi2_cam0>;
> -		clock-lanes = <0>;
> -		data-lanes = <1 2>;
> -	};
>  };
>  
>  &mcu_cpsw {

-- 
Regards,

Laurent Pinchart


From michal.simek at xilinx.com  Mon Apr 12 09:01:51 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 12 Apr 2021 10:01:51 +0200
Subject: [PATCH v4 2/2] usb: dwc3: Add driver for Xilinx platforms
In-Reply-To: <82dc676c-10c7-2a45-7ab3-ecad46eab0a3@roeck-us.net>
References: <1615963949-75320-1-git-send-email-manish.narani@xilinx.com>
 <1615963949-75320-3-git-send-email-manish.narani@xilinx.com>
 <20210407214811.GA260719@roeck-us.net>
 <ee280235-736d-1689-d324-b090c21106c9@xilinx.com>
 <82dc676c-10c7-2a45-7ab3-ecad46eab0a3@roeck-us.net>
Message-ID: <966e3077-ace0-0c38-90ad-e5b833cbbde6@xilinx.com>

Hi Guenter,

On 4/11/21 4:02 PM, Guenter Roeck wrote:
> Michal,
> 
> On 4/7/21 11:08 PM, Michal Simek wrote:
> ...
>> It looks like that you directly created the patch. Isn't it better to
>> send it yourself? Or do you want Manish to create it based on guidance
>> above?
>>
> -next is substantially broken all over the place. I already spend way too much
> time bisecting and analyzing the failures, and making sure that the problems
> are not caused by qemu (which is why I tracked down this problem in such detail).
> I don't really have time to write patches and guide them through the process,
> sorry.

I definitely appreciate your help on this.

Manish has sent a patch for it already.
http://lore.kernel.org/r/1617904448-74611-3-git-send-email-manish.narani at xilinx.com

Not sure why he hasn't added you to CC but at least Reported-by: tag
with your name should be added.

Thanks,
Michal


From alexandre.torgue at foss.st.com  Mon Apr 12 09:09:06 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Mon, 12 Apr 2021 10:09:06 +0200
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
In-Reply-To: <20210408185731.135511-1-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
Message-ID: <b81d6a69-713f-eda7-0837-d6e80d691c6a@foss.st.com>

Hi Marek

On 4/8/21 8:57 PM, Marek Vasut wrote:
> The implementation of ETH_RX_CLK/ETH_REF_CLK handling on STM32MP1 currently
> does not permit selecting the RX clock input from SoC pad, the RX clock are
> hard-wired to eth_clk_fb. This cover letter describes multiple unsuccessful
> attempts at solving this problem and a proposed partial solution.
> 
> The problem is that in stm32mp151.dtsi, the "st,stm32mp1-dwmac" compatible
> ethernet requests mac-clk-rx = <&rcc ETHRX> as MAC RX clock, which per [1]
> page 576 maps to clk_rx_i signal. Upon closer inspection of clk-stm32mp1.c,
> the ETHRX clock 1) only models G_ETHRX gate, which represents ETHRXEN bit,
> and 2) sets ETHRX clock parent to ck_axi. Both are wrong for the following
> reasons:
> 1) ETHRX clock are composite clock of gate and two muxes, which ultimately
>     permit selecting ETHRX clock parent to be either eth_clk_fb or external
>     ETH_RX_CLK/ETH_REF_CLOCK clock from SoC pad. Because only the gate part
>     is modeled, the clock topology is wrong and it is not possible to select
>     the ETHRX clock parent using the clock framework at all.
> 2) ETHRX clock are supplied from a mux controlled by ETH_SEL[2] (from
>     SYSCFG), which is supplied from a mux controlled by ETH_REF_CLK_SEL
>     (from SYSCFG), which is supplied either by ETH_RX_CLK/ETH_REF_CLK
>     from pad OR internally from eth_clk_fb clock, which maps to ETHCK_K
>     clock. Hence, ETHRX can never be supplied by ck_axi.
> 
> Another unique feature of ETHRX clock muxes is that they are controlled
> via SYSCFG block instead of being part of the RCC block. This is a rather
> unfortunate design, as it creates dependency between RCC, SYSCFG and DWMAC.
> Currently, those clock muxes are configured in the dwmac4 driver through
> syscon interface to SYSCFG block, based on custom device tree properties --
> st,eth-clk-sel and st,eth-ref-clk-sel -- this is clearly not the correct
> approach.
> 
> First approach was to implement ETHRX clock including muxes in clk-stm32mp1.c.
> This means RCC clock driver, clk-stm32mp1.c, must obtain access to SYSCFG IP
> registers via some syscon_regmap_lookup_by_phandle() when registering ETHRX
> clock in RCC driver probe, so that it can read out SYSCFG register state to
> determine the current mux state, and later toggle the mux bits. The problem
> here is that the SYSCFG requires clock which are provided by RCC, so
> syscon_regmap_lookup_by_phandle() fails with EPROBE_DEFER because the clock
> are not available yet in RCC clock driver probe, so there is cyclic dependency
> between RCC and SYSCFG.
> 
> Similar approach would be to turn SYSCFG into simple-bus and implement
> separate SYSCFG clock sub-driver, which would register single clock mux with
> two parents -- ETHCK_K and ETH_RX_CLK -- and would only control the SYSCFG
> clock mux bits. The problem here is similar, for RCC driver to register the
> ETHRX clock, the ETHRX clock must have a parent clock, however the parent
> clock are not ready yet, because this new SYSCFG clock sub-driver requires
> SYSCFG register clock, which only become available once RCC finishes probing,
> so there again is a cyclic dependency between RCC and SYSCFG.
> 
> One possible solution could be to defer obtaining the SYSCFG regmap handle
> until later point, i.e. only once a register access to SYSCFG is required
> the first time. This could permit us to register the mux in the RCC driver
> including a mux which requires SYSCFG access via syscon, although this would
> likely still run into problems during probe, since the clock framework would
> call .get_parent() during mux registration and trigger the SYSCFG access.
> 
> All the above still only discusses the clock part of the problem. Even if
> the clock cyclic dependencies could be solved, it would be necessary to
> resolve legacy dwmac st,eth-clk-sel and st,eth-ref-clk-sel DT properties
> and avoid DT ABI break.

Thanks for those clear explanations and for this series. As discussed, 
this approach looks good to me as it doesn't break our current strategy 
for dwmac clock integration. I don't know if those cyclic redundancies 
will be fixed one day but we can have a look on dwmac DT properties (the 
gain to change them, the effort to keep the backward compatibility, code 
readability, ...).

Your DT patches looks good. I'll merge them soon.

regards
alex


> So in the end, this series takes a different approach and only partly solves
> the problem. This series splits ETHCK_K, so the ETHCK_K gate could be turned
> off and adds support for selecting ETHRX clock parent clock via DT. This then
> permits e.g. DHCOM to select MCO2 as ETHRX clock source and the clock tree is
> then correctly set up.
> 
> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>      Figure 83. Peripheral clock distribution for Ethernet
>      https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf
> 
> Marek Vasut (7):
>    clk: stm32mp1: Split ETHCK_K into separate MUX and GATE clock
>    clk: stm32mp1: The dev is always NULL, replace it with np
>    clk: stm32mp1: Register clock with device_node pointer
>    clk: stm32mp1: Add parent_data to ETHRX clock
>    ARM: dts: stm32: Add alternate pinmux for ethernet0 pins
>    ARM: dts: stm32: Add alternate pinmux for mco2 pins
>    ARM: dts: stm32: Switch DWMAC RMII clock to MCO2 on DHCOM
> 
>   arch/arm/boot/dts/stm32mp15-pinctrl.dtsi     |  49 +++++++
>   arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi |  20 ++-
>   drivers/clk/clk-stm32mp1.c                   | 134 +++++++++++--------
>   3 files changed, 146 insertions(+), 57 deletions(-)
> 
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: Christophe Roullier <christophe.roullier at foss.st.com>
> Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> Cc: Patrice Chotard <patrice.chotard at foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
> Cc: Stephen Boyd <swboyd at chromium.org>
> Cc: linux-clk at vger.kernel.org
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org
> 




From nsaenz at kernel.org  Mon Apr 12 09:13:48 2021
From: nsaenz at kernel.org (nicolas saenz julienne)
Date: Mon, 12 Apr 2021 10:13:48 +0200
Subject: [PATCH 1/3] dt-bindings: mmc: iproc-sdhci: Convert to json-schema
In-Reply-To: <CAPDyKFrBSVooaNNiVgr12o9OLZ_3_0OExKBoW+QyLXftzR+8cw@mail.gmail.com>
References: <20210406104802.20898-1-nsaenz@kernel.org>
 <20210406104802.20898-2-nsaenz@kernel.org>
 <CAPDyKFrBSVooaNNiVgr12o9OLZ_3_0OExKBoW+QyLXftzR+8cw@mail.gmail.com>
Message-ID: <dbcfcc97abbedc154485b6975d6456c5cf31668a.camel@kernel.org>

On Mon, 2021-04-12 at 09:52 +0200, Ulf Hansson wrote:
> On Tue, 6 Apr 2021 at 12:48, Nicolas Saenz Julienne <nsaenz at kernel.org> wrote:
> > 
> > Convert the brcm,iproc-sdhci binding to DT schema format using json-schema
> > 
> > Signed-off-by: Nicolas Saenz Julienne <nsaenz at kernel.org>
> 
> Applied for next, thanks! (I guess patch2 and patch3 needs a re-spin?)

Yes, that's right. Thanks!

Regards,
Nicolas



From catalin.marinas at arm.com  Mon Apr 12 09:15:15 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 12 Apr 2021 09:15:15 +0100
Subject: [PATCH v4] kasan: remove redundant config option
In-Reply-To: <20210411150316.d60aa0b5174adf2370538809@linux-foundation.org>
References: <20210226012531.29231-1-walter-zh.wu@mediatek.com>
 <CAAeHK+zyv1=kXtKAynnJN-77dwmPG4TXpJOLv_3W0nxXe5NjXA@mail.gmail.com>
 <20210330223637.f3c73a78c64587e615d26766@linux-foundation.org>
 <20210411105332.GA23778@arm.com>
 <20210411150316.d60aa0b5174adf2370538809@linux-foundation.org>
Message-ID: <20210412081515.GB2060@arm.com>

On Sun, Apr 11, 2021 at 03:03:16PM -0700, Andrew Morton wrote:
> On Sun, 11 Apr 2021 11:53:33 +0100 Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Mar 30, 2021 at 10:36:37PM -0700, Andrew Morton wrote:
> > > On Mon, 29 Mar 2021 16:54:26 +0200 Andrey Konovalov <andreyknvl at google.com> wrote:
> > > > Looks like my patch "kasan: fix KASAN_STACK dependency for HW_TAGS"
> > > > that was merged into 5.12-rc causes a build time warning:
> > > > 
> > > > include/linux/kasan.h:333:30: warning: 'CONFIG_KASAN_STACK' is not
> > > > defined, evaluates to 0 [-Wundef]
> > > > #if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > > > 
> > > > The fix for it would either be reverting the patch (which would leave
> > > > the initial issue unfixed) or applying this "kasan: remove redundant
> > > > config option" patch.
> > > > 
> > > > Would it be possible to send this patch (with the fix-up you have in
> > > > mm) for the next 5.12-rc?
> > > > 
> > > > Here are the required tags:
> > > > 
> > > > Fixes: d9b571c885a8 ("kasan: fix KASAN_STACK dependency for HW_TAGS")
> > > > Cc: stable at vger.kernel.org
> > > 
> > > Got it, thanks.  I updated the changelog to mention the warning fix and
> > > moved these ahead for a -rc merge.
> > 
> > Is there a chance this patch makes it into 5.12? I still get the warning
> > with the latest Linus' tree (v5.12-rc6-408-g52e44129fba5) when enabling
> > KASAN_HW_TAGS.
> 
> Trying.   We're still awaiting a tested fix for
> https://lkml.kernel.org/r/CA+fCnZf1ABrQg0dsxtoZa9zM1BSbLYq_Xbu+xi9cv8WAZxdC2g at mail.gmail.com

Thanks Andrew. I didn't realise it was sent and then dropped.

However, we should decouple (or rather reorder) the two patches. There's
no functional dependency between removing the redundant config option (a
fix for an existing commit) and adding support for KASAN_SW_TAGS with
gcc-11, only a conflict in scripts/Makefile.kasan. Walter's original
patch applies on top of vanilla 5.12-rc3:

https://lkml.kernel.org/r/20210226012531.29231-1-walter-zh.wu at mediatek.com

-- 
Catalin


From michal.simek at xilinx.com  Mon Apr 12 09:24:41 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 12 Apr 2021 10:24:41 +0200
Subject: [GIT PULL] arm64: dts: Zynqmp DT changes for v5.13
Message-ID: <e422fa9c-3e58-28b4-f6f0-65aa44254131@xilinx.com>

Hi guys,

please pull these two patches to your tree.

Thanks,
Michal

The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:

  Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)

are available in the Git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-dt-for-v5.13

for you to fetch changes up to 73d677e9f379934807741dd068ca31872ed4d387:

  arm64: dts: zynqmp: Remove si5328 device nodes (2021-03-08 17:27:08 +0100)

----------------------------------------------------------------
arm64: dts: ZynqMP DT changes for v5.13

- Add power-domains for DP
- Remove si5328 node without compatible string

----------------------------------------------------------------
Laurent Pinchart (1):
      arm64: dts: zynqmp: Add power domain for the DisplayPort DMA
controller

Quanyang Wang (1):
      arm64: dts: zynqmp: Remove si5328 device nodes

 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts | 20 +-------------------
 arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts | 20 +-------------------
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi            |  1 +
 3 files changed, 3 insertions(+), 38 deletions(-)


From gregkh at linuxfoundation.org  Mon Apr 12 09:25:39 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 12 Apr 2021 10:25:39 +0200
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <YHPgGI6EmTzmVH7g@kroah.com>
 <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>
Message-ID: <YHQEA9jn5uXQCtrN@kroah.com>

On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
> Hi Greg?
> 
> Thanks for the quick response, please ignore the last private mail.
> 
> On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh at linuxfoundation.org> wrote:
> >
> > On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com wrote:
> > > From: dillon min <dillon.minfei at gmail.com>
> > >
> > > To avoid potential deadlock in spin_lock usage, change to use
> > > spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
> > > spin_lock(), spin_unlock() under handler context.
> > >
> > > remove unused local_irq_save/restore call.
> > >
> > > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > > ---
> > > Was verified on stm32f469-disco board. need more test on stm32mp platform.
> > >
> > >  drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
> > >  1 file changed, 17 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > > index b3675cf25a69..c4c859b34367 100644
> > > --- a/drivers/tty/serial/stm32-usart.c
> > > +++ b/drivers/tty/serial/stm32-usart.c
> > > @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > >       struct tty_port *tport = &port->state->port;
> > >       struct stm32_port *stm32_port = to_stm32_port(port);
> > >       const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > > -     unsigned long c;
> > > +     unsigned long c, flags;
> > >       u32 sr;
> > >       char flag;
> > >
> > > @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > >               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> > >       }
> > >
> > > -     spin_unlock(&port->lock);
> > > +     if (threaded)
> > > +             spin_unlock_irqrestore(&port->lock, flags);
> > > +     else
> > > +             spin_unlock(&port->lock);
> >
> > You shouldn't have to check for this, see the other patches on the list
> > recently that fixed this up to not be an issue for irq handlers.
> Can you help to give more hints, or the commit id of the patch which
> fixed this. thanks.
> 
> I'm still confused with this.
> 
> The stm32_usart_threaded_interrupt() is a kthread context, once
> port->lock holds by this function, another serial interrupts raised,
> such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
> there will be a deadlock. isn't it?
> 
>  So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?

Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
handlers") for when threaded irq handlers have irqs disabled, isn't that
the case you are trying to "protect" from here?

Why is the "threaded" flag used at all?  The driver should not care.

Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
threading") in linux-next for an example of how this was fixed up in a
serial driver.

does that help?

thanks,

greg k-h


From tomi.valkeinen at ideasonboard.com  Mon Apr 12 09:26:16 2021
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 12 Apr 2021 11:26:16 +0300
Subject: [PATCH 1/2] ARM: dts: dra76-evm: remove ov5640
In-Reply-To: <YHP+GDq2omVJwCfq@pendragon.ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <YHP+GDq2omVJwCfq@pendragon.ideasonboard.com>
Message-ID: <cca8ba39-d1b2-0022-15ad-e0126ee1a8cb@ideasonboard.com>

On 12/04/2021 11:00, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Apr 12, 2021 at 10:53:05AM +0300, Tomi Valkeinen wrote:
>> DRA76 EVM boards are not shipped with OV5640 sensor module, it is a
>> separate purchase. OV5640 module is also just one of the possible
>> sensors or capture boards you can connect.
>>
>> However, for some reason, OV5640 has been added to the board dts file,
>> making it cumbersome to use other sensors.
>>
>> Remove the OV5640 from the dts file so that it is easy to use other
>> sensors via DT overlays.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>> ---
>>   arch/arm/boot/dts/dra76-evm.dts | 27 ---------------------------
>>   1 file changed, 27 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
>> index 9bd01ae40b1d..f3c900e1b953 100644
>> --- a/arch/arm/boot/dts/dra76-evm.dts
>> +++ b/arch/arm/boot/dts/dra76-evm.dts
>> @@ -158,12 +158,6 @@ aic_dvdd: fixedregulator-aic_dvdd {
>>   		regulator-max-microvolt = <1800000>;
>>   	};
>>   
>> -	clk_ov5640_fixed: clock {
>> -		compatible = "fixed-clock";
>> -		#clock-cells = <0>;
>> -		clock-frequency = <24000000>;
>> -	};
>> -
>>   	hdmi0: connector {
>>   		compatible = "hdmi-connector";
>>   		label = "hdmi";
>> @@ -409,22 +403,6 @@ tlv320aic3106: tlv320aic3106 at 19 {
>>   &i2c5 {
>>   	status = "okay";
>>   	clock-frequency = <400000>;
>> -
>> -	ov5640 at 3c {
>> -		compatible = "ovti,ov5640";
>> -		reg = <0x3c>;
>> -
>> -		clocks = <&clk_ov5640_fixed>;
>> -		clock-names = "xclk";
>> -
>> -		port {
>> -			csi2_cam0: endpoint {
>> -				remote-endpoint = <&csi2_phy0>;
>> -				clock-lanes = <0>;
>> -				data-lanes = <1 2>;
>> -			};
>> -		};
>> -	};
>>   };
> 
> You could drop the node completely.
> 
>>   
>>   &cpu0 {
>> @@ -574,11 +552,6 @@ can-transceiver {
>>   };
>>   
>>   &csi2_0 {
>> -	csi2_phy0: endpoint {
>> -		remote-endpoint = <&csi2_cam0>;
>> -		clock-lanes = <0>;
>> -		data-lanes = <1 2>;
>> -	};
>>   };
> 
> And here too.
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> 
> Is there an overlay available somewhere for this ?

I have a work branch for dra76 and am654 overlays for TI's DT overlay tree:

https://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux-dt.git/commit/?h=multistream/work&id=c997e4854164cbfcf11174e9c7d012967b6f399d
https://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux-dt.git/commit/?h=multistream/work&id=311bdaaa28ba16b0142f5879fc7c79aa3aa5906d

I have not sent these to TI yet.

  Tomi


From ck.hu at mediatek.com  Mon Apr 12 09:26:10 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Mon, 12 Apr 2021 16:26:10 +0800
Subject: [PATCH v1, 1/3] drm/mediatek: Separate aal module
In-Reply-To: <1618209347-10816-2-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618209347-10816-2-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618215970.12699.1.camel@mtksdaap41>

Hi, Yongqiang:

On Mon, 2021-04-12 at 14:35 +0800, Yongqiang Niu wrote:
> mt8183 aal has no gamma function

Separate this patch to two patch: one is add has_gamma config in aal.
another one is add mt8183 aal support.

Regards,
CK

> 
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/Makefile           |   3 +-
>  drivers/gpu/drm/mediatek/mtk_disp_aal.c     | 167 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |   9 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  39 +------
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c      |   8 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h      |   1 +
>  6 files changed, 187 insertions(+), 40 deletions(-)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c
> 
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index dc54a7a..29098d7 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
> -mediatek-drm-y := mtk_disp_ccorr.o \
> +mediatek-drm-y := mtk_disp_aal.o \
> +		  mtk_disp_ccorr.o \
>  		  mtk_disp_color.o \
>  		  mtk_disp_gamma.o \
>  		  mtk_disp_ovl.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> new file mode 100644
> index 0000000..64b4528
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/component.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.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 DISP_AAL_EN				0x0000
> +#define AAL_EN						BIT(0)
> +#define DISP_AAL_SIZE				0x0030
> +
> +
> +struct mtk_disp_aal_data {
> +	bool has_gamma;
> +};
> +
> +/**
> + * struct mtk_disp_aal - DISP_AAL driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_aal {
> +	struct clk *clk;
> +	void __iomem *regs;
> +	struct cmdq_client_reg cmdq_reg;
> +	const struct mtk_disp_aal_data *data;
> +};
> +
> +int mtk_aal_clk_enable(struct device *dev)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	return clk_prepare_enable(aal->clk);
> +}
> +
> +void mtk_aal_clk_disable(struct device *dev)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	clk_disable_unprepare(aal->clk);
> +}
> +
> +void mtk_aal_config(struct device *dev, unsigned int w,
> +			   unsigned int h, unsigned int vrefresh,
> +			   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
> +}
> +
> +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	if (aal->data && aal->data->has_gamma)
> +		mtk_gamma_set_common(aal->regs, state);
> +}
> +
> +void mtk_aal_start(struct device *dev)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	writel(AAL_EN, aal->regs + DISP_AAL_EN);
> +}
> +
> +void mtk_aal_stop(struct device *dev)
> +{
> +	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> +	writel_relaxed(0x0, aal->regs + DISP_AAL_EN);
> +}
> +
> +static int mtk_disp_aal_bind(struct device *dev, struct device *master,
> +			       void *data)
> +{
> +	return 0;
> +}
> +
> +static void mtk_disp_aal_unbind(struct device *dev, struct device *master,
> +				  void *data)
> +{
> +}
> +
> +static const struct component_ops mtk_disp_aal_component_ops = {
> +	.bind	= mtk_disp_aal_bind,
> +	.unbind = mtk_disp_aal_unbind,
> +};
> +
> +static int mtk_disp_aal_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct mtk_disp_aal *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 aal clk\n");
> +		return PTR_ERR(priv->clk);
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	priv->regs = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(priv->regs)) {
> +		dev_err(dev, "failed to ioremap aal\n");
> +		return PTR_ERR(priv->regs);
> +	}
> +
> +#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);
> +
> +	ret = component_add(dev, &mtk_disp_aal_component_ops);
> +	if (ret)
> +		dev_err(dev, "Failed to add component: %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int mtk_disp_aal_remove(struct platform_device *pdev)
> +{
> +	component_del(&pdev->dev, &mtk_disp_aal_component_ops);
> +
> +	return 0;
> +}
> +
> +static const struct mtk_disp_aal_data mt8173_aal_driver_data = {
> +	.has_gamma = true,
> +};
> +
> +static const struct of_device_id mtk_disp_aal_driver_dt_match[] = {
> +	{ .compatible = "mediatek,mt8173-disp-aal",
> +	  .data = &mt8173_aal_driver_data},
> +	{ .compatible = "mediatek,mt8183-disp-aal"},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
> +
> +struct platform_driver mtk_disp_aal_driver = {
> +	.probe		= mtk_disp_aal_probe,
> +	.remove		= mtk_disp_aal_remove,
> +	.driver		= {
> +		.name	= "mediatek-disp-aal",
> +		.owner	= THIS_MODULE,
> +		.of_match_table = mtk_disp_aal_driver_dt_match,
> +	},
> +};
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index cafd9df..86c3068 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -9,6 +9,15 @@
>  #include <linux/soc/mediatek/mtk-cmdq.h>
>  #include "mtk_drm_plane.h"
>  
> +int mtk_aal_clk_enable(struct device *dev);
> +void mtk_aal_clk_disable(struct device *dev);
> +void mtk_aal_config(struct device *dev, unsigned int w,
> +		    unsigned int h, unsigned int vrefresh,
> +		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
> +void mtk_aal_start(struct device *dev);
> +void mtk_aal_stop(struct device *dev);
> +
>  void mtk_ccorr_ctm_set(struct device *dev, struct drm_crtc_state *state);
>  int mtk_ccorr_clk_enable(struct device *dev);
>  void mtk_ccorr_clk_disable(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 75bc00e..f367142 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -32,9 +32,6 @@
>  
>  #define DISP_REG_UFO_START			0x0000
>  
> -#define DISP_AAL_EN				0x0000
> -#define DISP_AAL_SIZE				0x0030
> -
>  #define DISP_DITHER_EN				0x0000
>  #define DITHER_EN				BIT(0)
>  #define DISP_DITHER_CFG				0x0020
> @@ -48,8 +45,6 @@
>  
>  #define UFO_BYPASS				BIT(2)
>  
> -#define AAL_EN					BIT(0)
> -
>  #define DISP_DITHERING				BIT(2)
>  #define DITHER_LSB_ERR_SHIFT_R(x)		(((x) & 0x7) << 28)
>  #define DITHER_OVFLW_BIT_R(x)			(((x) & 0x7) << 24)
> @@ -190,36 +185,6 @@ static void mtk_ufoe_start(struct device *dev)
>  	writel(UFO_BYPASS, priv->regs + DISP_REG_UFO_START);
>  }
>  
> -static void mtk_aal_config(struct device *dev, unsigned int w,
> -			   unsigned int h, unsigned int vrefresh,
> -			   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> -{
> -	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> -	mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs, DISP_AAL_SIZE);
> -}
> -
> -static void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> -{
> -	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> -	mtk_gamma_set_common(priv->regs, state);
> -}
> -
> -static void mtk_aal_start(struct device *dev)
> -{
> -	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> -	writel(AAL_EN, priv->regs + DISP_AAL_EN);
> -}
> -
> -static void mtk_aal_stop(struct device *dev)
> -{
> -	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> -
> -	writel_relaxed(0x0, priv->regs + DISP_AAL_EN);
> -}
> -
>  static void mtk_dither_config(struct device *dev, unsigned int w,
>  			      unsigned int h, unsigned int vrefresh,
>  			      unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> @@ -247,8 +212,8 @@ static void mtk_dither_stop(struct device *dev)
>  }
>  
>  static const struct mtk_ddp_comp_funcs ddp_aal = {
> -	.clk_enable = mtk_ddp_clk_enable,
> -	.clk_disable = mtk_ddp_clk_disable,
> +	.clk_enable = mtk_aal_clk_enable,
> +	.clk_disable = mtk_aal_clk_disable,
>  	.gamma_set = mtk_aal_gamma_set,
>  	.config = mtk_aal_config,
>  	.start = mtk_aal_start,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index b013d56..ae8b69d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -420,6 +420,8 @@ static void mtk_drm_unbind(struct device *dev)
>  	  .data = (void *)MTK_DISP_COLOR },
>  	{ .compatible = "mediatek,mt8173-disp-aal",
>  	  .data = (void *)MTK_DISP_AAL},
> +	{ .compatible = "mediatek,mt8183-disp-aal",
> +	  .data = (void *)MTK_DISP_AAL},
>  	{ .compatible = "mediatek,mt8173-disp-gamma",
>  	  .data = (void *)MTK_DISP_GAMMA, },
>  	{ .compatible = "mediatek,mt8183-disp-gamma",
> @@ -531,11 +533,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
>  		private->comp_node[comp_id] = of_node_get(node);
>  
>  		/*
> -		 * Currently only the CCORR, COLOR, GAMMA, OVL, RDMA, DSI, and DPI
> +		 * Currently only the AAL, CCORR, COLOR, GAMMA, OVL, RDMA, DSI, and DPI
>  		 * blocks have separate component platform drivers and initialize their own
>  		 * DDP component structure. The others are initialized here.
>  		 */
> -		if (comp_type == MTK_DISP_CCORR ||
> +		if (comp_type == MTK_DISP_AAL ||
> +		    comp_type == MTK_DISP_CCORR ||
>  		    comp_type == MTK_DISP_COLOR ||
>  		    comp_type == MTK_DISP_GAMMA ||
>  		    comp_type == MTK_DISP_OVL ||
> @@ -635,6 +638,7 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
>  };
>  
>  static struct platform_driver * const mtk_drm_drivers[] = {
> +	&mtk_disp_aal_driver,
>  	&mtk_disp_ccorr_driver,
>  	&mtk_disp_color_driver,
>  	&mtk_disp_gamma_driver,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index 637f566..3e7d1e6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -46,6 +46,7 @@ struct mtk_drm_private {
>  	struct drm_atomic_state *suspend_state;
>  };
>  
> +extern struct platform_driver mtk_disp_aal_driver;
>  extern struct platform_driver mtk_disp_ccorr_driver;
>  extern struct platform_driver mtk_disp_color_driver;
>  extern struct platform_driver mtk_disp_gamma_driver;


From narmstrong at baylibre.com  Mon Apr 12 09:26:34 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 10:26:34 +0200
Subject: [PATCH] gpu/drm: mediatek: hdmi: check for valid modes on MT8167
In-Reply-To: <CAAOTY_-gqN2HCLg6AABsXYzJoBxpN8FkMfjqWFu2q=6noiY1qg@mail.gmail.com>
References: <20210409084308.481185-1-narmstrong@baylibre.com>
 <CAAOTY_-gqN2HCLg6AABsXYzJoBxpN8FkMfjqWFu2q=6noiY1qg@mail.gmail.com>
Message-ID: <e3bd95df-f5c9-2791-8112-348592b7a513@baylibre.com>

On 10/04/2021 00:41, Chun-Kuang Hu wrote:
> Hi, Neil:
> 
> Neil Armstrong <narmstrong at baylibre.com> ? 2021?4?9? ?? ??4:43???
>>
>> On MT8167, only CEA modes and anything using a clock below 148500 is
>> supported for HDMI. This change adds some checks to make sure the
>> video format is OK for MT8167.
> 
> I think this patch should be separated to 3 patches. check CEA mode,
> check clock, add mt8167 hdmi support.

Ok

> 
>>
>> Signed-off-by: Fabien Parent <fparent at baylibre.com>
>> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
>> ---
>>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> index 8ee55f9e2954..991e2e935b93 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> @@ -148,6 +148,8 @@ struct hdmi_audio_param {
>>
>>  struct mtk_hdmi_conf {
>>         bool tz_disabled;
>> +       unsigned long max_mode_clock;
>> +       bool cea_modes_only;
>>  };
>>
>>  struct mtk_hdmi {
>> @@ -1259,6 +1261,13 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
>>                         return MODE_BAD;
>>         }
>>
>> +       if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
>> +               return MODE_BAD;
>> +
>> +       if (hdmi->conf->max_mode_clock &&
>> +           mode->clock > hdmi->conf->max_mode_clock)
>> +               return MODE_CLOCK_HIGH;
>> +
>>         if (mode->clock < 27000)
>>                 return MODE_CLOCK_LOW;
>>         if (mode->clock > 297000)
>> @@ -1810,10 +1819,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
>>         .tz_disabled = true,
>>  };
>>
>> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
>> +       .max_mode_clock = 148500,
>> +       .cea_modes_only = true,
>> +};
>> +
>>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
>>         { .compatible = "mediatek,mt2701-hdmi",
>>           .data = &mtk_hdmi_conf_mt2701,
>>         },
>> +       { .compatible = "mediatek,mt8167-hdmi",
> 
> "mediatek,mt8167-hdmi" does not exist in binding document, so add this
> to binding document first.
> In addition, could you also transfer mediatek,hdmi.txt to yaml format?

Sure

Thanks,
Neil

> 
> Regards,
> Chun-Kuang.
> 
>> +         .data = &mtk_hdmi_conf_mt8167,
>> +       },
>>         { .compatible = "mediatek,mt8173-hdmi",
>>         },
>>         {}
>> --
>> 2.25.1
>>



From ck.hu at mediatek.com  Mon Apr 12 09:28:47 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Mon, 12 Apr 2021 16:28:47 +0800
Subject: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
In-Reply-To: <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618216127.12699.4.camel@mtksdaap41>

Hi, Yongqiang:

On Mon, 2021-04-12 at 14:35 +0800, Yongqiang Niu wrote:
> gamma lut set in vsync active will caused display flash issue
> set gamma lut with cmdq 

In MT8173, it's ok to set gammma out of vblank period. Why do you
setting gamma in vblank in this patch?

Regards,
CK

> 
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_aal.c     |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  7 ++++---
>  drivers/gpu/drm/mediatek/mtk_disp_gamma.c   | 11 ++++++-----
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 18 +++++++++++-------
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  8 +++++---
>  5 files changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> index 64b4528..c8e178e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -59,12 +59,12 @@ void mtk_aal_config(struct device *dev, unsigned int w,
>  	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
>  }
>  
> -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
>  {
>  	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
>  
>  	if (aal->data && aal->data->has_gamma)
> -		mtk_gamma_set_common(aal->regs, state);
> +		mtk_gamma_set_common(aal->regs, &aal->cmdq_reg, state, cmdq_pkt);
>  }
>  
>  void mtk_aal_start(struct device *dev)
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 86c3068..c2e7dcb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -14,7 +14,7 @@
>  void mtk_aal_config(struct device *dev, unsigned int w,
>  		    unsigned int h, unsigned int vrefresh,
>  		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
> +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
>  void mtk_aal_start(struct device *dev);
>  void mtk_aal_stop(struct device *dev);
>  
> @@ -50,8 +50,9 @@ void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
>  void mtk_gamma_config(struct device *dev, unsigned int w,
>  		      unsigned int h, unsigned int vrefresh,
>  		      unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
> -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state);
> +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
>  void mtk_gamma_start(struct device *dev);
>  void mtk_gamma_stop(struct device *dev);
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index 3ebf91e..99a4ff3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -55,7 +55,8 @@ void mtk_gamma_clk_disable(struct device *dev)
>  	clk_disable_unprepare(gamma->clk);
>  }
>  
> -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
>  {
>  	unsigned int i, reg;
>  	struct drm_color_lut *lut;
> @@ -65,23 +66,23 @@ void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
>  	if (state->gamma_lut) {
>  		reg = readl(regs + DISP_GAMMA_CFG);
>  		reg = reg | GAMMA_LUT_EN;
> -		writel(reg, regs + DISP_GAMMA_CFG);
> +		mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs, DISP_GAMMA_CFG);
>  		lut_base = regs + DISP_GAMMA_LUT;
>  		lut = (struct drm_color_lut *)state->gamma_lut->data;
>  		for (i = 0; i < MTK_LUT_SIZE; i++) {
>  			word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
>  				(((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
>  				((lut[i].blue >> 6) & LUT_10BIT_MASK);
> -			writel(word, (lut_base + i * 4));
> +			mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
>  		}
>  	}
>  }
>  
> -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
> +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
>  {
>  	struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
>  
> -	mtk_gamma_set_common(gamma->regs, state);
> +	mtk_gamma_set_common(gamma->regs, &gamma->cmdq_reg, state, cmdq_pkt);
>  }
>  
>  void mtk_gamma_config(struct device *dev, unsigned int w,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 8b0de90..73428f0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -423,6 +423,15 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
>  		}
>  		mtk_crtc->pending_async_planes = false;
>  	}
> +
> +	if (crtc->state->color_mgmt_changed) {
> +		int i;
> +
> +		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> +			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state, cmdq_handle);
> +			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> +		}
> +	}
>  }
>  
>  static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> @@ -464,7 +473,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
>  	if (mtk_crtc->cmdq_client) {
>  		mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> -		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> +		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 2 * PAGE_SIZE);
>  		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);
> @@ -616,15 +625,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
>  				      struct drm_atomic_state *state)
>  {
>  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> -	int i;
>  
>  	if (mtk_crtc->event)
>  		mtk_crtc->pending_needs_vblank = true;
> -	if (crtc->state->color_mgmt_changed)
> -		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> -			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> -			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> -		}
> +
>  	mtk_drm_crtc_hw_config(mtk_crtc);
>  }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index bb914d9..bffa58d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -60,7 +60,8 @@ struct mtk_ddp_comp_funcs {
>  			     struct mtk_plane_state *state,
>  			     struct cmdq_pkt *cmdq_pkt);
>  	void (*gamma_set)(struct device *dev,
> -			  struct drm_crtc_state *state);
> +			  struct drm_crtc_state *state,
> +			  struct cmdq_pkt *cmdq_pkt);
>  	void (*bgclr_in_on)(struct device *dev);
>  	void (*bgclr_in_off)(struct device *dev);
>  	void (*ctm_set)(struct device *dev,
> @@ -160,10 +161,11 @@ static inline void mtk_ddp_comp_layer_config(struct mtk_ddp_comp *comp,
>  }
>  
>  static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
> -				     struct drm_crtc_state *state)
> +				     struct drm_crtc_state *state,
> +				     struct cmdq_pkt *cmdq_pkt)
>  {
>  	if (comp->funcs && comp->funcs->gamma_set)
> -		comp->funcs->gamma_set(comp->dev, state);
> +		comp->funcs->gamma_set(comp->dev, state, cmdq_pkt);
>  }
>  
>  static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)


From monstr at monstr.eu  Mon Apr 12 09:29:51 2021
From: monstr at monstr.eu (Michal Simek)
Date: Mon, 12 Apr 2021 10:29:51 +0200
Subject: [GIT PULL] arm64: soc: ZynqMP changes for v5.13
Message-ID: <a44f8e9f-cea7-57ef-c3bc-10f5f5e064fc@monstr.eu>

Hi,

please pull these two patches to your tree.

Thanks,
Michal

The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8:

  Linux 5.12-rc1 (2021-02-28 16:05:19 -0800)

are available in the Git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-soc-for-v5.13

for you to fetch changes up to 79bfe480a0a0b259ab9fddcd2fe52c03542b1196:

  firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in
IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE) (2021-03-01 12:52:07 +0100)

----------------------------------------------------------------
arm64: soc: ZynqMP SoC changes for v5.13

- Fix firmware removal path
- Cleanup eemi doc and *ops()

----------------------------------------------------------------
Nobuhiro Iwamatsu (1):
      firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in
IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)

Tejas Patel (1):
      firmware: xilinx: Fix dereferencing freed memory

 Documentation/driver-api/xilinx/eemi.rst | 31
++-----------------------------
 drivers/firmware/xilinx/zynqmp.c         |  5 +++--
 include/linux/firmware/xlnx-zynqmp.h     |  5 -----
 3 files changed, 5 insertions(+), 36 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 p.yadav at ti.com  Mon Apr 12 09:36:07 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Mon, 12 Apr 2021 14:06:07 +0530
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <YHP+O3HPCCWOQRb0@pendragon.ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
 <YHP+O3HPCCWOQRb0@pendragon.ideasonboard.com>
Message-ID: <20210412083605.qnpf2mxy3rcaj7dv@ti.com>

+ Vignesh

On 12/04/21 11:00AM, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, Apr 12, 2021 at 10:53:06AM +0300, Tomi Valkeinen wrote:
> > AM654 EVM boards are not shipped with OV5640 sensor module, it is a
> > separate purchase. OV5640 module is also just one of the possible
> > sensors or capture boards you can connect.
> > 
> > However, for some reason, OV5640 has been added to the board dts file,
> > making it cumbersome to use other sensors.
> > 
> > Remove the OV5640 from the dts file so that it is easy to use other
> > sensors via DT overlays.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> > ---
> >  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
> >  1 file changed, 27 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> > index fe3043943906..76358b4944e1 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> > +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> > @@ -85,12 +85,6 @@ sw6 {
> >  			gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
> >  		};
> >  	};
> > -
> > -	clk_ov5640_fixed: clock {
> > -		compatible = "fixed-clock";
> > -		#clock-cells = <0>;
> > -		clock-frequency = <24000000>;
> > -	};
> >  };
> >  
> >  &wkup_pmx0 {
> > @@ -288,22 +282,6 @@ &main_i2c1 {
> >  	pinctrl-0 = <&main_i2c1_pins_default>;
> >  	clock-frequency = <400000>;
> >  
> > -	ov5640: camera at 3c {
> > -		compatible = "ovti,ov5640";
> > -		reg = <0x3c>;
> > -
> > -		clocks = <&clk_ov5640_fixed>;
> > -		clock-names = "xclk";
> > -
> > -		port {
> > -			csi2_cam0: endpoint {
> > -				remote-endpoint = <&csi2_phy0>;
> > -				clock-lanes = <0>;
> > -				data-lanes = <1 2>;
> > -			};
> > -		};
> > -	};
> > -
> >  };
> 
> As for patch 1/2, you could drop the two nodes completely. Same question
> about overlay availability.

The &main_i2c1 node was added much before the OV5640 node in 
19a1768fc34a (arm64: dts: ti: k3-am654-base-board: Add I2C nodes, 
2018-11-13). I wonder if there is any reason for having it present even 
if there are no subnodes. One reason that I can think of is that this 
node defines the pinmux configuration and clock frequency which makes 
more sense here than in an overlay.

> 
> >  
> >  &main_i2c2 {
> > @@ -497,11 +475,6 @@ flash at 0{
> >  };
> >  
> >  &csi2_0 {
> > -	csi2_phy0: endpoint {
> > -		remote-endpoint = <&csi2_cam0>;
> > -		clock-lanes = <0>;
> > -		data-lanes = <1 2>;
> > -	};
> >  };

I agree with Laurent that the entire &csi2_0 node can be dropped.

Have you tested the CAL driver with this node removed and no overlay to 
add it back? Can it handle the error gracefully or does it crash and 
burn?

> >  
> >  &mcu_cpsw {
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From ardb at kernel.org  Mon Apr 12 09:39:00 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Mon, 12 Apr 2021 10:39:00 +0200
Subject: [PATCH v2 1/9] arm64: assembler: remove conditional NEON yield
 macros
In-Reply-To: <20210330095250.GA5352@willie-the-truck>
References: <20210302090118.30666-1-ardb@kernel.org>
 <20210302090118.30666-2-ardb@kernel.org>
 <20210330095250.GA5352@willie-the-truck>
Message-ID: <CAMj1kXFS4e-0pTPx8B7HS=nkf55LfzFPCkohYbBBAiv+BEONeQ@mail.gmail.com>

On Tue, 30 Mar 2021 at 11:52, Will Deacon <will at kernel.org> wrote:
>
> On Tue, Mar 02, 2021 at 10:01:10AM +0100, Ard Biesheuvel wrote:
> > The users of the conditional NEON yield macros have all been switched to
> > the simplified cond_yield macro, and so the NEON specific ones can be
> > removed.
> >
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > ---
> >  arch/arm64/include/asm/assembler.h | 70 --------------------
> >  1 file changed, 70 deletions(-)
>
> Acked-by: Will Deacon <will at kernel.org>
>

Thanks.

Catalin,

Please consider taking the first 3 patches of this series through the
arm64 tree. I will then resubmit the rest to be taken via the crypto
tree for the next cycle.

Thanks,
Ard.


From victor.liu at nxp.com  Mon Apr 12 09:40:56 2021
From: victor.liu at nxp.com (Liu Ying)
Date: Mon, 12 Apr 2021 16:40:56 +0800
Subject: [PATCH v5 1/2] phy: core: Use runtime pm during configure too
In-Reply-To: <2de2ee26bbf443491dfff1c802f2fa9efaf58d52.1617968250.git.agx@sigxcpu.org>
References: <cover.1617968250.git.agx@sigxcpu.org>
 <2de2ee26bbf443491dfff1c802f2fa9efaf58d52.1617968250.git.agx@sigxcpu.org>
Message-ID: <3ae6e6413901cbc9e432c7057db8fb9e81e56f39.camel@nxp.com>

Hi Guido,

On Fri, 2021-04-09 at 13:40 +0200, Guido G?nther wrote:
> The phy's configure phase usually needs register access so taking the
> device out of pm_runtime suspend looks useful.
> 
> There's currently two in tree drivers using runtime pm and .configure
> (qualcomm/phy-qcom-qmp.c, rockchip/phy-rockchip-inno-dsidphy.c) but both
> don't use the phy layers 'transparent' runtime phy_pm_runtime handling
> but manage it manually so this will for now only affect the
> phy-fsl-imx8-mipi-dphy driver.

IIUC, the qualcomm one's runtime PM is managed by the phy core when
users enable it using power/control in sysfs(see comment just before
pm_runtime_forbid() in that driver).
I'm assuming it's affected and it would be good to test it.

I'm not pretty sure if the rockchip one is affected or not, because I'm
assuming the power/control nodes of phy->dev and phy->parent.dev in
sysfs are both 'auto' after the driver probes.

> 
> Signed-off-by: Guido G?nther <agx at sigxcpu.org>
> ---
>  drivers/phy/phy-core.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index ccb575b13777..256a964d52d3 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -470,10 +470,16 @@ int phy_configure(struct phy *phy, union phy_configure_opts *opts)
>  	if (!phy->ops->configure)
>  		return -EOPNOTSUPP;
>  
> +	ret = phy_pm_runtime_get_sync(phy);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		return ret;
> +	ret = 0; /* Override possible ret == -ENOTSUPP */

This override is not needed, because 'ret' will be the return value of
phy->ops->configure() right below.

Regards,
Liu Ying

> +
>  	mutex_lock(&phy->mutex);
>  	ret = phy->ops->configure(phy, opts);
>  	mutex_unlock(&phy->mutex);
>  
> +	phy_pm_runtime_put(phy);
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(phy_configure);



From gregkh at linuxfoundation.org  Mon Apr 12 09:40:21 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:40:21 +0200
Subject: [PATCH 4.19 15/66] ARM: dts: turris-omnia: configure LED[2]/INTn pin
 as interrupt pin
In-Reply-To: <20210412083958.129944265@linuxfoundation.org>
References: <20210412083958.129944265@linuxfoundation.org>
Message-ID: <20210412083958.622107640@linuxfoundation.org>

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};




From gregkh at linuxfoundation.org  Mon Apr 12 09:40:48 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:40:48 +0200
Subject: [PATCH 4.19 42/66] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210412083958.129944265@linuxfoundation.org>
References: <20210412083958.129944265@linuxfoundation.org>
Message-ID: <20210412083959.481524124@linuxfoundation.org>

From: Bastian Germann <bage at linutronix.de>

[ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ]

card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Add it.
This fixes following warning observed on Lamobo R1:

WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
Hardware name: Allwinner sun7i (A20) Family
Call trace:
 (snd_card_new [snd])
 (snd_soc_bind_card [snd_soc_core])
 (snd_soc_register_card [snd_soc_core])
 (sun4i_codec_probe [sun4i_codec])

Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs")
Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings")
Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner")
Cc: linux-arm-kernel at lists.infradead.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Bastian Germann <bage at linutronix.de>
Link: https://lore.kernel.org/r/20210331151843.30583-1-bage at linutronix.de
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sunxi/sun4i-codec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 9a3cb7704810..16e8f74288a5 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1235,6 +1235,7 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "sun4i-codec";
 	card->dapm_widgets	= sun4i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
@@ -1267,6 +1268,7 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A31 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1320,6 +1322,7 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A23 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1358,6 +1361,7 @@ static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "H3 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1396,6 +1400,7 @@ static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "V3s Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
-- 
2.30.2





From Jonathan.Cameron at Huawei.com  Mon Apr 12 09:42:19 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Mon, 12 Apr 2021 09:42:19 +0100
Subject: [PATCH v10 1/3] PCI: portdrv: Add pcie_port_service_get_irq()
 function
In-Reply-To: <1617985338-19648-2-git-send-email-hayashi.kunihiko@socionext.com>
References: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
 <1617985338-19648-2-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <20210412094219.000031ca@Huawei.com>

On Sat, 10 Apr 2021 01:22:16 +0900
Kunihiko Hayashi <hayashi.kunihiko at socionext.com> wrote:

> Add pcie_port_service_get_irq() that returns the virtual IRQ number
> for specified portdrv service.

Trivial comment inline.

> 
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
> Reviewed-by: Rob Herring <robh at kernel.org>
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> ---
>  drivers/pci/pcie/portdrv.h      |  1 +
>  drivers/pci/pcie/portdrv_core.c | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
> index 2ff5724..628a3de 100644
> --- a/drivers/pci/pcie/portdrv.h
> +++ b/drivers/pci/pcie/portdrv.h
> @@ -144,4 +144,5 @@ static inline void pcie_pme_interrupt_enable(struct pci_dev *dev, bool en) {}
>  #endif /* !CONFIG_PCIE_PME */
>  
>  struct device *pcie_port_find_device(struct pci_dev *dev, u32 service);
> +int pcie_port_service_get_irq(struct pci_dev *dev, u32 service);
>  #endif /* _PORTDRV_H_ */
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e1fed664..b60f0f3 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -477,7 +477,22 @@ struct device *pcie_port_find_device(struct pci_dev *dev,
>  }
>  EXPORT_SYMBOL_GPL(pcie_port_find_device);
>  
> +/*

/**

this is kernel-doc style, so why not mark it as such?


> + * pcie_port_service_get_irq - get irq of the service
> + * @dev: PCI Express port the service is associated with
> + * @service: For the service to find
> + *
> + * Get IRQ number associated with given service on a pci_dev.
> + */
> +int pcie_port_service_get_irq(struct pci_dev *dev, u32 service)
> +{
> +	struct pcie_device *pciedev;
> +
> +	pciedev = to_pcie_device(pcie_port_find_device(dev, service));
> +
> +	return pciedev->irq;
> +}
> +
>  /**
>   * pcie_port_device_remove - unregister PCI Express port service devices
>   * @dev: PCI Express port the service devices to unregister are associated with



From gregkh at linuxfoundation.org  Mon Apr 12 09:39:58 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:39:58 +0200
Subject: [PATCH 5.4 020/111] ARM: dts: turris-omnia: configure LED[2]/INTn pin
 as interrupt pin
In-Reply-To: <20210412084004.200986670@linuxfoundation.org>
References: <20210412084004.200986670@linuxfoundation.org>
Message-ID: <20210412084004.896046541@linuxfoundation.org>

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};




From gregkh at linuxfoundation.org  Mon Apr 12 09:40:46 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:40:46 +0200
Subject: [PATCH 5.4 068/111] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210412084004.200986670@linuxfoundation.org>
References: <20210412084004.200986670@linuxfoundation.org>
Message-ID: <20210412084006.523607018@linuxfoundation.org>

From: Bastian Germann <bage at linutronix.de>

[ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ]

card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Add it.
This fixes following warning observed on Lamobo R1:

WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
Hardware name: Allwinner sun7i (A20) Family
Call trace:
 (snd_card_new [snd])
 (snd_soc_bind_card [snd_soc_core])
 (snd_soc_register_card [snd_soc_core])
 (sun4i_codec_probe [sun4i_codec])

Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs")
Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings")
Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner")
Cc: linux-arm-kernel at lists.infradead.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Bastian Germann <bage at linutronix.de>
Link: https://lore.kernel.org/r/20210331151843.30583-1-bage at linutronix.de
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sunxi/sun4i-codec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index ee448d5e07a6..c4021d6ac9df 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1364,6 +1364,7 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "sun4i-codec";
 	card->dapm_widgets	= sun4i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
@@ -1396,6 +1397,7 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A31 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1449,6 +1451,7 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A23 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1487,6 +1490,7 @@ static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "H3 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1525,6 +1529,7 @@ static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "V3s Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
-- 
2.30.2





From arnd at kernel.org  Mon Apr 12 09:48:14 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 12 Apr 2021 10:48:14 +0200
Subject: [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device
 interface
In-Reply-To: <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
 <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>
Message-ID: <CAK8P3a3RXr5CR7DJgD9rEkN8owpPxXRgzRnPB_5LuQcHkzc4LA@mail.gmail.com>

On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > >
> > > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > > provide a means to generate IRQs and exchange arbitrary data between a
> > > BMC and its host system.
> >
> > I only noticed the series after Joel asked about the DT changes on the arm
> > side. One question though:
> >
> > How does this related to the drivers/input/serio/ framework that also talks
> > to the keyboard controller for things that are not keyboards?
>
> I've taken a brief look and I feel they're somewhat closely related.
>
> It's plausible that we could wrangle the code so the Aspeed and Nuvoton
> KCS drivers move under drivers/input/serio. If you squint, the i8042
> serio device driver has similarities with what the Aspeed and Nuvoton
> device drivers are providing to the KCS IPMI stack.

After looking some more into it, I finally understood that the two are
rather complementary. While the  drivers/char/ipmi/kcs_bmc.c
is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems
that the proposed kcs_bmc_cdev_raw.c interface would be
what corresponds to the other side of
drivers/input/serio/i8042.c+userio.c. Then again, these are also on
separate ports (0x60 for the keyboard controller, 0xca2 for the BMC
KCS), so they would never actually talk to one another.

> Both the KCS IPMI and raw chardev I've implemented in this patch need
> both read and write access to the status register (STR). serio could
> potentially expose its value through serio_interrupt() using the
> SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this
> sentence. We'd need some extra support for writing STR via the serio
> API. I'm not sure that fits into the abstraction (unless we make
> serio_write() take a flags argument?).
>
> In that vein, the serio_raw interface is close to the functionality
> that the raw chardev provides in this patch, though again serio_raw
> lacks userspace access to STR. Flags are ignored in the ->interrupt()
> callback so all values received via ->interrupt() are exposed as data.
> The result is there's no way to take care of SERIO_OOB_DATA in the
> read() path. Given that, I think we'd have to expose an ioctl() to
> access the STR value after taking care of SERIO_OOB_DATA in
> ->interrupt().
>
> I'm not sure where that lands us.

Based on what I looked up, I think you can just forget about my original
question. We have two separate interfaces that use an Intel 8042-style
protocol, but they don't really interact.

      Arnd


From ck.hu at mediatek.com  Mon Apr 12 09:46:23 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Mon, 12 Apr 2021 16:46:23 +0800
Subject: [PATCH v1] drm/mediatek: adjust rdma fifo threshold calculate
 formula
In-Reply-To: <1618212332-3547-2-git-send-email-yongqiang.niu@mediatek.com>
References: <1618212332-3547-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618212332-3547-2-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618217183.16010.4.camel@mtksdaap41>

Hi, Yongqiang:

On Mon, 2021-04-12 at 15:25 +0800, Yongqiang Niu wrote:
> the orginal formula will caused rdma fifo threshold config overflow
> 
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 728aaad..8c9371b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -167,7 +167,7 @@ void mtk_rdma_config(struct device *dev, unsigned int width,
>  	 * output threshold to 6 microseconds with 7/6 overhead to
>  	 * account for blanking, and with a pixel depth of 4 bytes:
>  	 */
> -	threshold = width * height * vrefresh * 4 * 7 / 1000000;
> +	threshold = rdma_fifo_size * 7 / 10;

It's better to set threshold by width and height, but it seems that no
one could come out a solution for all SoC. I could just accept this
solution, but I need some addition comment for this solution. How do you
decide 7/10? In the future, another may need to modify this value and he
need to know why you use 7/10. If you just choose it at random, just
tell us that you just randomly choose it.

Regards,
CK

>  	reg = RDMA_FIFO_UNDERFLOW_EN |
>  	      RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
>  	      RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);


From gregkh at linuxfoundation.org  Mon Apr 12 09:39:05 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:39:05 +0200
Subject: [PATCH 5.10 031/188] ARM: dts: turris-omnia: configure LED[2]/INTn
 pin as interrupt pin
In-Reply-To: <20210412084013.643370347@linuxfoundation.org>
References: <20210412084013.643370347@linuxfoundation.org>
Message-ID: <20210412084014.686141907@linuxfoundation.org>

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -236,6 +236,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};




From dillon.minfei at gmail.com  Mon Apr 12 09:54:54 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Mon, 12 Apr 2021 16:54:54 +0800
Subject: [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <YHQEA9jn5uXQCtrN@kroah.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <YHPgGI6EmTzmVH7g@kroah.com>
 <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>
 <YHQEA9jn5uXQCtrN@kroah.com>
Message-ID: <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>

Hi Greg,

On Mon, Apr 12, 2021 at 4:25 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>
> On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
> > Hi Greg?
> >
> > Thanks for the quick response, please ignore the last private mail.
> >
> > On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh at linuxfoundation.org> wrote:
> > >
> > > On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com wrote:
> > > > From: dillon min <dillon.minfei at gmail.com>
> > > >
> > > > To avoid potential deadlock in spin_lock usage, change to use
> > > > spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
> > > > spin_lock(), spin_unlock() under handler context.
> > > >
> > > > remove unused local_irq_save/restore call.
> > > >
> > > > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > > > ---
> > > > Was verified on stm32f469-disco board. need more test on stm32mp platform.
> > > >
> > > >  drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
> > > >  1 file changed, 17 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > > > index b3675cf25a69..c4c859b34367 100644
> > > > --- a/drivers/tty/serial/stm32-usart.c
> > > > +++ b/drivers/tty/serial/stm32-usart.c
> > > > @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > > >       struct tty_port *tport = &port->state->port;
> > > >       struct stm32_port *stm32_port = to_stm32_port(port);
> > > >       const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > > > -     unsigned long c;
> > > > +     unsigned long c, flags;
> > > >       u32 sr;
> > > >       char flag;
> > > >
> > > > @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> > > >               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> > > >       }
> > > >
> > > > -     spin_unlock(&port->lock);
> > > > +     if (threaded)
> > > > +             spin_unlock_irqrestore(&port->lock, flags);
> > > > +     else
> > > > +             spin_unlock(&port->lock);
> > >
> > > You shouldn't have to check for this, see the other patches on the list
> > > recently that fixed this up to not be an issue for irq handlers.
> > Can you help to give more hints, or the commit id of the patch which
> > fixed this. thanks.
> >
> > I'm still confused with this.
> >
> > The stm32_usart_threaded_interrupt() is a kthread context, once
> > port->lock holds by this function, another serial interrupts raised,
> > such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
> > there will be a deadlock. isn't it?
> >
> >  So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?
>
> Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
> handlers") for when threaded irq handlers have irqs disabled, isn't that
> the case you are trying to "protect" from here?
>
> Why is the "threaded" flag used at all?  The driver should not care.
>
> Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
> threading") in linux-next for an example of how this was fixed up in a
> serial driver.
>
> does that help?
>
Yes, it's really helpful. and 81e2073c175b should be highlighted in a doc.
In my past knowledge, we should care about hard irq & thread_fn lock conflict.
This patch has totally avoided patching code in the separate driver side.
thanks.

I will just keep the changes in stm32_usart_console_write(), remove
these code in
thread_fn. update version 2 for you.

thanks.

Dillon,
> thanks,
>
> greg k-h


From yongqiang.niu at mediatek.com  Mon Apr 12 09:45:29 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 16:45:29 +0800
Subject: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
In-Reply-To: <1618216127.12699.4.camel@mtksdaap41>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
 <1618216127.12699.4.camel@mtksdaap41>
Message-ID: <1618217129.9080.5.camel@mhfsdcap03>

On Mon, 2021-04-12 at 16:28 +0800, CK Hu wrote:
> Hi, Yongqiang:
> 
> On Mon, 2021-04-12 at 14:35 +0800, Yongqiang Niu wrote:
> > gamma lut set in vsync active will caused display flash issue
> > set gamma lut with cmdq 
> 
> In MT8173, it's ok to set gammma out of vblank period. Why do you
> setting gamma in vblank in this patch?
> 
> Regards,
> CK
> 

mtk drm driver code has changed many since mt8173, there is no one test
this in the newest version for mt8173.

and this issue is random.
https://partnerissuetracker.corp.google.com/u/1/issues/153842418

and not all platform will set gamma lut.
some project platform will not set gamma lut from chrome os
(crhome os set gamma lut may be with some special panel, like AUO
B116XTN02.3 in
https://partnerissuetracker.corp.google.com/u/1/issues/153842418
)

> > 
> > Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_disp_aal.c     |  4 ++--
> >  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  7 ++++---
> >  drivers/gpu/drm/mediatek/mtk_disp_gamma.c   | 11 ++++++-----
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 18 +++++++++++-------
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  8 +++++---
> >  5 files changed, 28 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > index 64b4528..c8e178e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > @@ -59,12 +59,12 @@ void mtk_aal_config(struct device *dev, unsigned int w,
> >  	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
> >  }
> >  
> > -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> > +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> >  {
> >  	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> >  
> >  	if (aal->data && aal->data->has_gamma)
> > -		mtk_gamma_set_common(aal->regs, state);
> > +		mtk_gamma_set_common(aal->regs, &aal->cmdq_reg, state, cmdq_pkt);
> >  }
> >  
> >  void mtk_aal_start(struct device *dev)
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 86c3068..c2e7dcb 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -14,7 +14,7 @@
> >  void mtk_aal_config(struct device *dev, unsigned int w,
> >  		    unsigned int h, unsigned int vrefresh,
> >  		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
> > +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> >  void mtk_aal_start(struct device *dev);
> >  void mtk_aal_stop(struct device *dev);
> >  
> > @@ -50,8 +50,9 @@ void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> >  void mtk_gamma_config(struct device *dev, unsigned int w,
> >  		      unsigned int h, unsigned int vrefresh,
> >  		      unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
> > -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state);
> > +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> > +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> > +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> >  void mtk_gamma_start(struct device *dev);
> >  void mtk_gamma_stop(struct device *dev);
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > index 3ebf91e..99a4ff3 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > @@ -55,7 +55,8 @@ void mtk_gamma_clk_disable(struct device *dev)
> >  	clk_disable_unprepare(gamma->clk);
> >  }
> >  
> > -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> > +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> > +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> >  {
> >  	unsigned int i, reg;
> >  	struct drm_color_lut *lut;
> > @@ -65,23 +66,23 @@ void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> >  	if (state->gamma_lut) {
> >  		reg = readl(regs + DISP_GAMMA_CFG);
> >  		reg = reg | GAMMA_LUT_EN;
> > -		writel(reg, regs + DISP_GAMMA_CFG);
> > +		mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs, DISP_GAMMA_CFG);
> >  		lut_base = regs + DISP_GAMMA_LUT;
> >  		lut = (struct drm_color_lut *)state->gamma_lut->data;
> >  		for (i = 0; i < MTK_LUT_SIZE; i++) {
> >  			word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
> >  				(((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
> >  				((lut[i].blue >> 6) & LUT_10BIT_MASK);
> > -			writel(word, (lut_base + i * 4));
> > +			mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
> >  		}
> >  	}
> >  }
> >  
> > -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
> > +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> >  {
> >  	struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
> >  
> > -	mtk_gamma_set_common(gamma->regs, state);
> > +	mtk_gamma_set_common(gamma->regs, &gamma->cmdq_reg, state, cmdq_pkt);
> >  }
> >  
> >  void mtk_gamma_config(struct device *dev, unsigned int w,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 8b0de90..73428f0 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -423,6 +423,15 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
> >  		}
> >  		mtk_crtc->pending_async_planes = false;
> >  	}
> > +
> > +	if (crtc->state->color_mgmt_changed) {
> > +		int i;
> > +
> > +		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > +			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state, cmdq_handle);
> > +			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> > +		}
> > +	}
> >  }
> >  
> >  static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> > @@ -464,7 +473,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> >  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> >  	if (mtk_crtc->cmdq_client) {
> >  		mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> > -		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> > +		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 2 * PAGE_SIZE);
> >  		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);
> > @@ -616,15 +625,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> >  				      struct drm_atomic_state *state)
> >  {
> >  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > -	int i;
> >  
> >  	if (mtk_crtc->event)
> >  		mtk_crtc->pending_needs_vblank = true;
> > -	if (crtc->state->color_mgmt_changed)
> > -		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > -			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > -			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> > -		}
> > +
> >  	mtk_drm_crtc_hw_config(mtk_crtc);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > index bb914d9..bffa58d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > @@ -60,7 +60,8 @@ struct mtk_ddp_comp_funcs {
> >  			     struct mtk_plane_state *state,
> >  			     struct cmdq_pkt *cmdq_pkt);
> >  	void (*gamma_set)(struct device *dev,
> > -			  struct drm_crtc_state *state);
> > +			  struct drm_crtc_state *state,
> > +			  struct cmdq_pkt *cmdq_pkt);
> >  	void (*bgclr_in_on)(struct device *dev);
> >  	void (*bgclr_in_off)(struct device *dev);
> >  	void (*ctm_set)(struct device *dev,
> > @@ -160,10 +161,11 @@ static inline void mtk_ddp_comp_layer_config(struct mtk_ddp_comp *comp,
> >  }
> >  
> >  static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
> > -				     struct drm_crtc_state *state)
> > +				     struct drm_crtc_state *state,
> > +				     struct cmdq_pkt *cmdq_pkt)
> >  {
> >  	if (comp->funcs && comp->funcs->gamma_set)
> > -		comp->funcs->gamma_set(comp->dev, state);
> > +		comp->funcs->gamma_set(comp->dev, state, cmdq_pkt);
> >  }
> >  
> >  static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)
> 
> 


From hch at lst.de  Mon Apr 12 09:55:40 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:40 +0200
Subject: consolidate the flock uapi definitions
Message-ID: <20210412085545.2595431-1-hch@lst.de>

Hi all,

currently we deal with the slight differents in the various architecture
variants of the flock and flock64 stuctures in a very cruft way.  This
series switches to just use small arch hooks and define the rest in
asm-generic and linux/compat.h instead.

Diffstat:
 arch/arm64/include/asm/compat.h        |   20 --------------------
 arch/mips/include/asm/compat.h         |   23 ++---------------------
 arch/mips/include/uapi/asm/fcntl.h     |   28 +++-------------------------
 arch/parisc/include/asm/compat.h       |   16 ----------------
 arch/powerpc/include/asm/compat.h      |   20 --------------------
 arch/s390/include/asm/compat.h         |   20 --------------------
 arch/sparc/include/asm/compat.h        |   22 +---------------------
 arch/x86/include/asm/compat.h          |   24 +++---------------------
 include/linux/compat.h                 |   31 +++++++++++++++++++++++++++++++
 include/uapi/asm-generic/fcntl.h       |   21 +++++++--------------
 tools/include/uapi/asm-generic/fcntl.h |   21 +++++++--------------
 11 files changed, 54 insertions(+), 192 deletions(-)


From hch at lst.de  Mon Apr 12 09:55:41 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:41 +0200
Subject: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <20210412085545.2595431-2-hch@lst.de>

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 include/uapi/asm-generic/fcntl.h       | 2 --
 tools/include/uapi/asm-generic/fcntl.h | 2 --
 2 files changed, 4 deletions(-)

diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 9dc0bf0c5a6ee8..fb454bb629d114 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -203,7 +203,6 @@ struct flock {
 };
 #endif
 
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
 #ifndef __ARCH_FLOCK64_PAD
 #define __ARCH_FLOCK64_PAD
 #endif
@@ -216,6 +215,5 @@ struct flock64 {
 	__kernel_pid_t  l_pid;
 	__ARCH_FLOCK64_PAD
 };
-#endif
 
 #endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index ac190958c98144..4a49d33ca4d55d 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -202,7 +202,6 @@ struct flock {
 };
 #endif
 
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
 #ifndef __ARCH_FLOCK64_PAD
 #define __ARCH_FLOCK64_PAD
 #endif
@@ -215,6 +214,5 @@ struct flock64 {
 	__kernel_pid_t  l_pid;
 	__ARCH_FLOCK64_PAD
 };
-#endif
 
 #endif /* _ASM_GENERIC_FCNTL_H */
-- 
2.30.1



From gregkh at linuxfoundation.org  Mon Apr 12 09:40:44 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:40:44 +0200
Subject: [PATCH 5.10 130/188] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210412084013.643370347@linuxfoundation.org>
References: <20210412084013.643370347@linuxfoundation.org>
Message-ID: <20210412084017.966657384@linuxfoundation.org>

From: Bastian Germann <bage at linutronix.de>

[ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ]

card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Add it.
This fixes following warning observed on Lamobo R1:

WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
Hardware name: Allwinner sun7i (A20) Family
Call trace:
 (snd_card_new [snd])
 (snd_soc_bind_card [snd_soc_core])
 (snd_soc_register_card [snd_soc_core])
 (sun4i_codec_probe [sun4i_codec])

Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs")
Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings")
Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner")
Cc: linux-arm-kernel at lists.infradead.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Bastian Germann <bage at linutronix.de>
Link: https://lore.kernel.org/r/20210331151843.30583-1-bage at linutronix.de
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sunxi/sun4i-codec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 6c13cc84b3fb..2173991c13db 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1364,6 +1364,7 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "sun4i-codec";
 	card->dapm_widgets	= sun4i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
@@ -1396,6 +1397,7 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A31 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1449,6 +1451,7 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A23 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1487,6 +1490,7 @@ static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "H3 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1525,6 +1529,7 @@ static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "V3s Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
-- 
2.30.2





From hch at lst.de  Mon Apr 12 09:55:42 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:42 +0200
Subject: [PATCH 2/5] uapi: simplify __ARCH_FLOCK{,64}_PAD a little
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <20210412085545.2595431-3-hch@lst.de>

Don't bother to define emtpty versions of the macros if the architecture
doesn't define them.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 include/uapi/asm-generic/fcntl.h       | 12 ++++--------
 tools/include/uapi/asm-generic/fcntl.h | 12 ++++--------
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index fb454bb629d114..df7ad6962dff71 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -189,22 +189,16 @@ struct f_owner_ex {
 #define F_LINUX_SPECIFIC_BASE	1024
 
 #ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
 struct flock {
 	short	l_type;
 	short	l_whence;
 	__kernel_off_t	l_start;
 	__kernel_off_t	l_len;
 	__kernel_pid_t	l_pid;
+#ifdef __ARCH_FLOCK_PAD
 	__ARCH_FLOCK_PAD
-};
 #endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
 #endif
 
 struct flock64 {
@@ -213,7 +207,9 @@ struct flock64 {
 	__kernel_loff_t l_start;
 	__kernel_loff_t l_len;
 	__kernel_pid_t  l_pid;
+#ifdef __ARCH_FLOCK64_PAD
 	__ARCH_FLOCK64_PAD
+#endif
 };
 
 #endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index 4a49d33ca4d55d..82054502b9748d 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -188,22 +188,16 @@ struct f_owner_ex {
 #define F_LINUX_SPECIFIC_BASE	1024
 
 #ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
 struct flock {
 	short	l_type;
 	short	l_whence;
 	__kernel_off_t	l_start;
 	__kernel_off_t	l_len;
 	__kernel_pid_t	l_pid;
+#ifdef __ARCH_FLOCK_PAD
 	__ARCH_FLOCK_PAD
-};
 #endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
 #endif
 
 struct flock64 {
@@ -212,7 +206,9 @@ struct flock64 {
 	__kernel_loff_t l_start;
 	__kernel_loff_t l_len;
 	__kernel_pid_t  l_pid;
+#ifdef __ARCH_FLOCK64_PAD
 	__ARCH_FLOCK64_PAD
+#endif
 };
 
 #endif /* _ASM_GENERIC_FCNTL_H */
-- 
2.30.1



From hch at lst.de  Mon Apr 12 09:55:43 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:43 +0200
Subject: [PATCH 3/5] uapi: merge the 32-bit mips struct flock into the generic
 one
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <20210412085545.2595431-4-hch@lst.de>

Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 arch/mips/include/uapi/asm/fcntl.h     | 26 +++-----------------------
 include/uapi/asm-generic/fcntl.h       |  5 +++--
 tools/include/uapi/asm-generic/fcntl.h |  5 +++--
 3 files changed, 9 insertions(+), 27 deletions(-)

diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
index 42e13dead54319..9e44ac810db94d 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -50,30 +50,10 @@
 #define F_SETLKW64	35
 #endif
 
-/*
- * The flavours of struct flock.  "struct flock" is the ABI compliant
- * variant.  Finally struct flock64 is the LFS variant of struct flock.	 As
- * a historic accident and inconsistence with the ABI definition it doesn't
- * contain all the same fields as struct flock.
- */
-
 #if _MIPS_SIM != _MIPS_SIM_ABI64
-
-#include <linux/types.h>
-
-struct flock {
-	short	l_type;
-	short	l_whence;
-	__kernel_off_t	l_start;
-	__kernel_off_t	l_len;
-	long	l_sysid;
-	__kernel_pid_t l_pid;
-	long	pad[4];
-};
-
-#define HAVE_ARCH_STRUCT_FLOCK
-
-#endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
+#define __ARCH_FLOCK_EXTRA_SYSID	long l_sysid;
+#define __ARCH_FLOCK_PAD		long pad[4];
+#endif
 
 #include <asm-generic/fcntl.h>
 
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index df7ad6962dff71..7e714443a8d2e3 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -188,18 +188,19 @@ struct f_owner_ex {
 
 #define F_LINUX_SPECIFIC_BASE	1024
 
-#ifndef HAVE_ARCH_STRUCT_FLOCK
 struct flock {
 	short	l_type;
 	short	l_whence;
 	__kernel_off_t	l_start;
 	__kernel_off_t	l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+	__ARCH_FLOCK_EXTRA_SYSID
+#endif
 	__kernel_pid_t	l_pid;
 #ifdef __ARCH_FLOCK_PAD
 	__ARCH_FLOCK_PAD
 #endif
 };
-#endif
 
 struct flock64 {
 	short  l_type;
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index 82054502b9748d..bf961a71802e0e 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -187,18 +187,19 @@ struct f_owner_ex {
 
 #define F_LINUX_SPECIFIC_BASE	1024
 
-#ifndef HAVE_ARCH_STRUCT_FLOCK
 struct flock {
 	short	l_type;
 	short	l_whence;
 	__kernel_off_t	l_start;
 	__kernel_off_t	l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+	__ARCH_FLOCK_EXTRA_SYSID
+#endif
 	__kernel_pid_t	l_pid;
 #ifdef __ARCH_FLOCK_PAD
 	__ARCH_FLOCK_PAD
 #endif
 };
-#endif
 
 struct flock64 {
 	short  l_type;
-- 
2.30.1



From hch at lst.de  Mon Apr 12 09:55:44 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:44 +0200
Subject: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in
 fcntl.h
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <20210412085545.2595431-5-hch@lst.de>

The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
32-bit syscall APIs, but we also need them for compat handling on 64-bit
kernels.

Given that redefining them is rather error prone, as shown by parisc
getting the opcodes wrong currently, just use the existing definitions
for the compat handling.

In theory we could try to hide them from userspace; but given that only
MIPS manages to properly do that while the asm-generic version used by
most architectures relies on a Kconfig symbol that is never set by
userspace there doesn't seem to be much of a point to even bother.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 arch/arm64/include/asm/compat.h        | 4 ----
 arch/mips/include/asm/compat.h         | 4 ----
 arch/mips/include/uapi/asm/fcntl.h     | 2 --
 arch/powerpc/include/asm/compat.h      | 4 ----
 arch/s390/include/asm/compat.h         | 4 ----
 arch/sparc/include/asm/compat.h        | 4 ----
 arch/x86/include/asm/compat.h          | 4 ----
 include/uapi/asm-generic/fcntl.h       | 2 --
 tools/include/uapi/asm-generic/fcntl.h | 2 --
 9 files changed, 30 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 23a9fb73c04ff8..a5fe4558a6ecc0 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -74,10 +74,6 @@ struct compat_flock {
 	compat_pid_t	l_pid;
 };
 
-#define F_GETLK64	12	/*  using 'struct flock64' */
-#define F_SETLK64	13
-#define F_SETLKW64	14
-
 struct compat_flock64 {
 	short		l_type;
 	short		l_whence;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index 65975712a22dcf..a13436e91c3938 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -60,10 +60,6 @@ struct compat_flock {
 	s32		pad[4];
 };
 
-#define F_GETLK64	33
-#define F_SETLK64	34
-#define F_SETLKW64	35
-
 struct compat_flock64 {
 	short		l_type;
 	short		l_whence;
diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
index 9e44ac810db94d..1769fc50d35f0e 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -44,11 +44,9 @@
 #define F_SETOWN	24	/*  for sockets. */
 #define F_GETOWN	23	/*  for sockets. */
 
-#ifndef __mips64
 #define F_GETLK64	33	/*  using 'struct flock64' */
 #define F_SETLK64	34
 #define F_SETLKW64	35
-#endif
 
 #if _MIPS_SIM != _MIPS_SIM_ABI64
 #define __ARCH_FLOCK_EXTRA_SYSID	long l_sysid;
diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
index 9191fc29e6ed11..b0f2c3f7fe45a5 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -56,10 +56,6 @@ struct compat_flock {
 	compat_pid_t	l_pid;
 };
 
-#define F_GETLK64	12	/*  using 'struct flock64' */
-#define F_SETLK64	13
-#define F_SETLKW64	14
-
 struct compat_flock64 {
 	short		l_type;
 	short		l_whence;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index ea5b9c34b7be5b..e0896758779da4 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -111,10 +111,6 @@ struct compat_flock {
 	compat_pid_t	l_pid;
 };
 
-#define F_GETLK64       12
-#define F_SETLK64       13
-#define F_SETLKW64      14    
-
 struct compat_flock64 {
 	short		l_type;
 	short		l_whence;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index b85842cda99fe0..4524997424043f 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -85,10 +85,6 @@ struct compat_flock {
 	short		__unused;
 };
 
-#define F_GETLK64	12
-#define F_SETLK64	13
-#define F_SETLKW64	14
-
 struct compat_flock64 {
 	short		l_type;
 	short		l_whence;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index be09c7eac89f09..b1691cf148be10 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -59,10 +59,6 @@ struct compat_flock {
 	compat_pid_t	l_pid;
 };
 
-#define F_GETLK64	12	/*  using 'struct flock64' */
-#define F_SETLK64	13
-#define F_SETLKW64	14
-
 /*
  * IA32 uses 4 byte alignment for 64 bit quantities,
  * so we need to pack this structure.
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 7e714443a8d2e3..6430a2f8023fc3 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -116,13 +116,11 @@
 #define F_GETSIG	11	/* for sockets. */
 #endif
 
-#ifndef CONFIG_64BIT
 #ifndef F_GETLK64
 #define F_GETLK64	12	/*  using 'struct flock64' */
 #define F_SETLK64	13
 #define F_SETLKW64	14
 #endif
-#endif
 
 #ifndef F_SETOWN_EX
 #define F_SETOWN_EX	15
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index bf961a71802e0e..6e16722026f39a 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -115,13 +115,11 @@
 #define F_GETSIG	11	/* for sockets. */
 #endif
 
-#ifndef CONFIG_64BIT
 #ifndef F_GETLK64
 #define F_GETLK64	12	/*  using 'struct flock64' */
 #define F_SETLK64	13
 #define F_SETLKW64	14
 #endif
-#endif
 
 #ifndef F_SETOWN_EX
 #define F_SETOWN_EX	15
-- 
2.30.1



From hch at lst.de  Mon Apr 12 09:55:45 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 12 Apr 2021 10:55:45 +0200
Subject: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <20210412085545.2595431-6-hch@lst.de>

Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants.  An extra define is added for the packing required on x86.

Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 arch/arm64/include/asm/compat.h   | 16 ----------------
 arch/mips/include/asm/compat.h    | 19 ++-----------------
 arch/parisc/include/asm/compat.h  | 16 ----------------
 arch/powerpc/include/asm/compat.h | 16 ----------------
 arch/s390/include/asm/compat.h    | 16 ----------------
 arch/sparc/include/asm/compat.h   | 18 +-----------------
 arch/x86/include/asm/compat.h     | 20 +++-----------------
 include/linux/compat.h            | 31 +++++++++++++++++++++++++++++++
 8 files changed, 37 insertions(+), 115 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index a5fe4558a6ecc0..6f0908606b2b51 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -66,22 +66,6 @@ struct compat_stat {
 	compat_ulong_t	__unused4[2];
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	compat_pid_t	l_pid;
-};
-
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-};
-
 struct compat_statfs {
 	int		f_type;
 	int		f_bsize;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index a13436e91c3938..7df384e445de06 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -50,23 +50,8 @@ struct compat_stat {
 	s32		st_pad4[14];
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	s32		l_sysid;
-	compat_pid_t	l_pid;
-	s32		pad[4];
-};
-
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-};
+#define __ARCH_COMPAT_FLOCK_EXTRA_SYSID		s32 l_sysid;
+#define __ARCH_COMPAT_FLOCK_PAD			s32 pad[4];
 
 struct compat_statfs {
 	int		f_type;
diff --git a/arch/parisc/include/asm/compat.h b/arch/parisc/include/asm/compat.h
index 1a609d38f6678e..972bf8911d1126 100644
--- a/arch/parisc/include/asm/compat.h
+++ b/arch/parisc/include/asm/compat.h
@@ -54,22 +54,6 @@ struct compat_stat {
 	u32			st_spare4[3];
 };
 
-struct compat_flock {
-	short			l_type;
-	short			l_whence;
-	compat_off_t		l_start;
-	compat_off_t		l_len;
-	compat_pid_t		l_pid;
-};
-
-struct compat_flock64 {
-	short			l_type;
-	short			l_whence;
-	compat_loff_t		l_start;
-	compat_loff_t		l_len;
-	compat_pid_t		l_pid;
-};
-
 struct compat_statfs {
 	s32		f_type;
 	s32		f_bsize;
diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
index b0f2c3f7fe45a5..e9d433bd561725 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -48,22 +48,6 @@ struct compat_stat {
 	u32		__unused4[2];
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	compat_pid_t	l_pid;
-};
-
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-};
-
 struct compat_statfs {
 	int		f_type;
 	int		f_bsize;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index e0896758779da4..5578607913b847 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -103,22 +103,6 @@ struct compat_stat {
 	u32		__unused5;
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	compat_pid_t	l_pid;
-};
-
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-};
-
 struct compat_statfs {
 	u32		f_type;
 	u32		f_bsize;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index 4524997424043f..16fa333f28c274 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -76,23 +76,7 @@ struct compat_stat64 {
 	unsigned int	__unused5;
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	compat_pid_t	l_pid;
-	short		__unused;
-};
-
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-	short		__unused;
-};
+#define __ARCH_COMPAT_FLOCK_PAD		short __unused;
 
 struct compat_statfs {
 	int		f_type;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index b1691cf148be10..d8e01bf51e7a26 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -51,25 +51,11 @@ struct compat_stat {
 	u32		__unused5;
 };
 
-struct compat_flock {
-	short		l_type;
-	short		l_whence;
-	compat_off_t	l_start;
-	compat_off_t	l_len;
-	compat_pid_t	l_pid;
-};
-
 /*
- * IA32 uses 4 byte alignment for 64 bit quantities,
- * so we need to pack this structure.
+ * IA32 uses 4 byte alignment for 64 bit quantities, so we need to pack the
+ * compat flock64 structure.
  */
-struct compat_flock64 {
-	short		l_type;
-	short		l_whence;
-	compat_loff_t	l_start;
-	compat_loff_t	l_len;
-	compat_pid_t	l_pid;
-} __attribute__((packed));
+#define __ARCH_NEED_COMPAT_FLOCK64_PACKED
 
 struct compat_statfs {
 	int		f_type;
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 6e65be75360321..9d196f8a94d5ea 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -258,6 +258,37 @@ struct compat_rlimit {
 	compat_ulong_t	rlim_max;
 };
 
+#ifdef __ARCH_NEED_COMPAT_FLOCK64_PACKED
+#define __ARCH_COMPAT_FLOCK64_PACK	__attribute__((packed))
+#else
+#define __ARCH_COMPAT_FLOCK64_PACK
+#endif
+
+struct compat_flock {
+	short			l_type;
+	short			l_whence;
+	compat_off_t		l_start;
+	compat_off_t		l_len;
+#ifdef __ARCH_COMPAT_FLOCK_EXTRA_SYSID
+	__ARCH_COMPAT_FLOCK_EXTRA_SYSID
+#endif
+	compat_pid_t		l_pid;
+#ifdef __ARCH_COMPAT_FLOCK_PAD
+	__ARCH_COMPAT_FLOCK_PAD
+#endif
+};
+
+struct compat_flock64 {
+	short		l_type;
+	short		l_whence;
+	compat_loff_t	l_start;
+	compat_loff_t	l_len;
+	compat_pid_t	l_pid;
+#ifdef __ARCH_COMPAT_FLOCK64_PAD
+	__ARCH_COMPAT_FLOCK64_PAD
+#endif
+} __ARCH_COMPAT_FLOCK64_PACK;
+
 struct compat_rusage {
 	struct old_timeval32 ru_utime;
 	struct old_timeval32 ru_stime;
-- 
2.30.1



From gregkh at linuxfoundation.org  Mon Apr 12 09:39:03 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:39:03 +0200
Subject: [PATCH 5.11 038/210] ARM: dts: turris-omnia: configure LED[2]/INTn
 pin as interrupt pin
In-Reply-To: <20210412084016.009884719@linuxfoundation.org>
References: <20210412084016.009884719@linuxfoundation.org>
Message-ID: <20210412084017.279580657@linuxfoundation.org>

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -389,6 +389,7 @@
 	phy1: ethernet-phy at 1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};




From gregkh at linuxfoundation.org  Mon Apr 12 09:40:47 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 12 Apr 2021 10:40:47 +0200
Subject: [PATCH 5.11 142/210] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210412084016.009884719@linuxfoundation.org>
References: <20210412084016.009884719@linuxfoundation.org>
Message-ID: <20210412084020.733810912@linuxfoundation.org>

From: Bastian Germann <bage at linutronix.de>

[ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ]

card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Add it.
This fixes following warning observed on Lamobo R1:

WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
Hardware name: Allwinner sun7i (A20) Family
Call trace:
 (snd_card_new [snd])
 (snd_soc_bind_card [snd_soc_core])
 (snd_soc_register_card [snd_soc_core])
 (sun4i_codec_probe [sun4i_codec])

Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs")
Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings")
Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner")
Cc: linux-arm-kernel at lists.infradead.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Bastian Germann <bage at linutronix.de>
Link: https://lore.kernel.org/r/20210331151843.30583-1-bage at linutronix.de
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sunxi/sun4i-codec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 6c13cc84b3fb..2173991c13db 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1364,6 +1364,7 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "sun4i-codec";
 	card->dapm_widgets	= sun4i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
@@ -1396,6 +1397,7 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A31 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1449,6 +1451,7 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A23 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1487,6 +1490,7 @@ static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "H3 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1525,6 +1529,7 @@ static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "V3s Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
-- 
2.30.2





From ck.hu at mediatek.com  Mon Apr 12 10:05:30 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Mon, 12 Apr 2021 17:05:30 +0800
Subject: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
In-Reply-To: <1618217129.9080.5.camel@mhfsdcap03>
References: <1618209347-10816-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
 <1618216127.12699.4.camel@mtksdaap41> <1618217129.9080.5.camel@mhfsdcap03>
Message-ID: <1618218330.16010.13.camel@mtksdaap41>

Hi, Yongqiang:

On Mon, 2021-04-12 at 16:45 +0800, Yongqiang Niu wrote:
> On Mon, 2021-04-12 at 16:28 +0800, CK Hu wrote:
> > Hi, Yongqiang:
> > 
> > On Mon, 2021-04-12 at 14:35 +0800, Yongqiang Niu wrote:
> > > gamma lut set in vsync active will caused display flash issue
> > > set gamma lut with cmdq 
> > 
> > In MT8173, it's ok to set gammma out of vblank period. Why do you
> > setting gamma in vblank in this patch?
> > 
> > Regards,
> > CK
> > 
> 
> mtk drm driver code has changed many since mt8173, there is no one test
> this in the newest version for mt8173.
> 
> and this issue is random.
> https://partnerissuetracker.corp.google.com/u/1/issues/153842418
> 
> and not all platform will set gamma lut.
> some project platform will not set gamma lut from chrome os
> (crhome os set gamma lut may be with some special panel, like AUO
> B116XTN02.3 in
> https://partnerissuetracker.corp.google.com/u/1/issues/153842418
> )
> 


I could not see the page in partnelissuetracker, If this patch fix some
bug, describe the bug in commit message. It's better that information
include how to reproduce this bug and what kind of error happen. More
information would help us to understand why setting in vblank would fix
this bug.

Regards,
CK

> > > 
> > > Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_disp_aal.c     |  4 ++--
> > >  drivers/gpu/drm/mediatek/mtk_disp_drv.h     |  7 ++++---
> > >  drivers/gpu/drm/mediatek/mtk_disp_gamma.c   | 11 ++++++-----
> > >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c     | 18 +++++++++++-------
> > >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  8 +++++---
> > >  5 files changed, 28 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > > index 64b4528..c8e178e 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> > > @@ -59,12 +59,12 @@ void mtk_aal_config(struct device *dev, unsigned int w,
> > >  	mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs, DISP_AAL_SIZE);
> > >  }
> > >  
> > > -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> > > +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> > >  {
> > >  	struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> > >  
> > >  	if (aal->data && aal->data->has_gamma)
> > > -		mtk_gamma_set_common(aal->regs, state);
> > > +		mtk_gamma_set_common(aal->regs, &aal->cmdq_reg, state, cmdq_pkt);
> > >  }
> > >  
> > >  void mtk_aal_start(struct device *dev)
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > index 86c3068..c2e7dcb 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > @@ -14,7 +14,7 @@
> > >  void mtk_aal_config(struct device *dev, unsigned int w,
> > >  		    unsigned int h, unsigned int vrefresh,
> > >  		    unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > > -void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state);
> > > +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> > >  void mtk_aal_start(struct device *dev);
> > >  void mtk_aal_stop(struct device *dev);
> > >  
> > > @@ -50,8 +50,9 @@ void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> > >  void mtk_gamma_config(struct device *dev, unsigned int w,
> > >  		      unsigned int h, unsigned int vrefresh,
> > >  		      unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > > -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
> > > -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state);
> > > +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> > > +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> > > +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt);
> > >  void mtk_gamma_start(struct device *dev);
> > >  void mtk_gamma_stop(struct device *dev);
> > >  
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > > index 3ebf91e..99a4ff3 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> > > @@ -55,7 +55,8 @@ void mtk_gamma_clk_disable(struct device *dev)
> > >  	clk_disable_unprepare(gamma->clk);
> > >  }
> > >  
> > > -void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> > > +void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
> > > +			  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> > >  {
> > >  	unsigned int i, reg;
> > >  	struct drm_color_lut *lut;
> > > @@ -65,23 +66,23 @@ void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> > >  	if (state->gamma_lut) {
> > >  		reg = readl(regs + DISP_GAMMA_CFG);
> > >  		reg = reg | GAMMA_LUT_EN;
> > > -		writel(reg, regs + DISP_GAMMA_CFG);
> > > +		mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs, DISP_GAMMA_CFG);
> > >  		lut_base = regs + DISP_GAMMA_LUT;
> > >  		lut = (struct drm_color_lut *)state->gamma_lut->data;
> > >  		for (i = 0; i < MTK_LUT_SIZE; i++) {
> > >  			word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
> > >  				(((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
> > >  				((lut[i].blue >> 6) & LUT_10BIT_MASK);
> > > -			writel(word, (lut_base + i * 4));
> > > +			mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
> > >  		}
> > >  	}
> > >  }
> > >  
> > > -void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state)
> > > +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
> > >  {
> > >  	struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
> > >  
> > > -	mtk_gamma_set_common(gamma->regs, state);
> > > +	mtk_gamma_set_common(gamma->regs, &gamma->cmdq_reg, state, cmdq_pkt);
> > >  }
> > >  
> > >  void mtk_gamma_config(struct device *dev, unsigned int w,
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > index 8b0de90..73428f0 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > @@ -423,6 +423,15 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
> > >  		}
> > >  		mtk_crtc->pending_async_planes = false;
> > >  	}
> > > +
> > > +	if (crtc->state->color_mgmt_changed) {
> > > +		int i;
> > > +
> > > +		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > > +			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state, cmdq_handle);
> > > +			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> > > +		}
> > > +	}
> > >  }
> > >  
> > >  static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> > > @@ -464,7 +473,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> > >  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > >  	if (mtk_crtc->cmdq_client) {
> > >  		mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> > > -		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> > > +		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, 2 * PAGE_SIZE);
> > >  		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);
> > > @@ -616,15 +625,10 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> > >  				      struct drm_atomic_state *state)
> > >  {
> > >  	struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > > -	int i;
> > >  
> > >  	if (mtk_crtc->event)
> > >  		mtk_crtc->pending_needs_vblank = true;
> > > -	if (crtc->state->color_mgmt_changed)
> > > -		for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > > -			mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > > -			mtk_ddp_ctm_set(mtk_crtc->ddp_comp[i], crtc->state);
> > > -		}
> > > +
> > >  	mtk_drm_crtc_hw_config(mtk_crtc);
> > >  }
> > >  
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > index bb914d9..bffa58d 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > @@ -60,7 +60,8 @@ struct mtk_ddp_comp_funcs {
> > >  			     struct mtk_plane_state *state,
> > >  			     struct cmdq_pkt *cmdq_pkt);
> > >  	void (*gamma_set)(struct device *dev,
> > > -			  struct drm_crtc_state *state);
> > > +			  struct drm_crtc_state *state,
> > > +			  struct cmdq_pkt *cmdq_pkt);
> > >  	void (*bgclr_in_on)(struct device *dev);
> > >  	void (*bgclr_in_off)(struct device *dev);
> > >  	void (*ctm_set)(struct device *dev,
> > > @@ -160,10 +161,11 @@ static inline void mtk_ddp_comp_layer_config(struct mtk_ddp_comp *comp,
> > >  }
> > >  
> > >  static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
> > > -				     struct drm_crtc_state *state)
> > > +				     struct drm_crtc_state *state,
> > > +				     struct cmdq_pkt *cmdq_pkt)
> > >  {
> > >  	if (comp->funcs && comp->funcs->gamma_set)
> > > -		comp->funcs->gamma_set(comp->dev, state);
> > > +		comp->funcs->gamma_set(comp->dev, state, cmdq_pkt);
> > >  }
> > >  
> > >  static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)
> > 
> > 
> 
> 


From leo.yan at linaro.org  Mon Apr 12 10:10:00 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:00 +0800
Subject: [PATCH v4 0/6] perf arm-spe: Enable timestamp
Message-ID: <20210412091006.468557-1-leo.yan@linaro.org>

This patch set is to enable timestamp for Arm SPE trace.  It reads out
TSC parameters from the TIME_CONV event, the parameters are used for
conversion between timer counter and kernel time and which is applied
for Arm SPE samples.

This version dropped the change for adding hardware clock parameters
into auxtrace info, alternatively, it utilizes the TIME_CONV event to
extract the clock parameters which is used for timestamp calculation.

This patch set can be clearly applied on perf/core branch with:

  commit 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat --bpf-counters' new option")

Ths patch series has been tested on Hisilicon D06 platform.

Changes from v3:
* Let to be backwards-compatible for TIME_CONV event (Adrian).

Changes from v2:
* Changed to use TIME_CONV event for extracting clock parameters (Al).

Changes from v1:
* Rebased patch series on the latest perf/core branch;
* Fixed the patch for dumping TSC parameters to support both the
  older and new auxtrace info format.


Leo Yan (6):
  perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
  perf arm-spe: Save clock parameters from TIME_CONV event
  perf arm-spe: Convert event kernel time to counter value
  perf arm-spe: Assign kernel time to synthesized event
  perf arm-spe: Bail out if the trace is later than perf event
  perf arm-spe: Don't wait for PERF_RECORD_EXIT event

 tools/perf/util/arm-spe.c | 74 +++++++++++++++++++++++++++++++++------
 tools/perf/util/arm-spe.h |  1 -
 2 files changed, 64 insertions(+), 11 deletions(-)

-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:01 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:01 +0800
Subject: [PATCH v4 1/6] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-2-leo.yan@linaro.org>

The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
index 98d3235781c3..105ce0ea0a01 100644
--- a/tools/perf/util/arm-spe.h
+++ b/tools/perf/util/arm-spe.h
@@ -11,7 +11,6 @@
 
 enum {
 	ARM_SPE_PMU_TYPE,
-	ARM_SPE_PER_CPU_MMAPS,
 	ARM_SPE_AUXTRACE_PRIV_MAX,
 };
 
-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:02 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:02 +0800
Subject: [PATCH v4 2/6] perf arm-spe: Save clock parameters from TIME_CONV
 event
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-3-leo.yan@linaro.org>

During the recording phase, "perf record" tool synthesizes event
PERF_RECORD_TIME_CONV for the hardware clock parameters and saves the
event into the data file.

Afterwards, when processing the data file, the event TIME_CONV will be
processed at the very early time and is stored into session context.

This patch extracts these parameters from the session context and saves
into the structure "spe->tc" with the type perf_tsc_conversion, so that
the parameters are ready for conversion between clock counter and time
stamp.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 2539d4baec44..7620dcc45940 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -26,6 +26,7 @@
 #include "symbol.h"
 #include "thread.h"
 #include "thread-stack.h"
+#include "tsc.h"
 #include "tool.h"
 #include "util/synthetic-events.h"
 
@@ -45,6 +46,8 @@ struct arm_spe {
 	struct machine			*machine;
 	u32				pmu_type;
 
+	struct perf_tsc_conversion	tc;
+
 	u8				timeless_decoding;
 	u8				data_queued;
 
@@ -1006,6 +1009,7 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
 {
 	struct perf_record_auxtrace_info *auxtrace_info = &event->auxtrace_info;
 	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
+	struct perf_record_time_conv *tc = &session->time_conv;
 	struct arm_spe *spe;
 	int err;
 
@@ -1027,6 +1031,29 @@ int arm_spe_process_auxtrace_info(union perf_event *event,
 	spe->pmu_type = auxtrace_info->priv[ARM_SPE_PMU_TYPE];
 
 	spe->timeless_decoding = arm_spe__is_timeless_decoding(spe);
+
+	/*
+	 * The synthesized event PERF_RECORD_TIME_CONV has been handled ahead
+	 * and the parameters for hardware clock are stored in the session
+	 * context.  Passes these parameters to the struct perf_tsc_conversion
+	 * in "spe->tc", which is used for later conversion between clock
+	 * counter and timestamp.
+	 *
+	 * For backward compatibility, checks the event size and save extended
+	 * fields staring from "time_cycles" if these fields are contained in
+	 * the event.
+	 */
+	spe->tc.time_shift = tc->time_shift;
+	spe->tc.time_mult = tc->time_mult;
+	spe->tc.time_zero = tc->time_zero;
+
+	if (tc->header.size > ((void *)&tc->time_cycles - (void *)tc)) {
+		spe->tc.time_cycles = tc->time_cycles;
+		spe->tc.time_mask = tc->time_mask;
+		spe->tc.cap_user_time_zero = tc->cap_user_time_zero;
+		spe->tc.cap_user_time_short = tc->cap_user_time_short;
+	}
+
 	spe->auxtrace.process_event = arm_spe_process_event;
 	spe->auxtrace.process_auxtrace_event = arm_spe_process_auxtrace_event;
 	spe->auxtrace.flush_events = arm_spe_flush;
-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:03 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:03 +0800
Subject: [PATCH v4 3/6] perf arm-spe: Convert event kernel time to counter
 value
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-4-leo.yan@linaro.org>

When handle a perf event, Arm SPE decoder needs to decide if this perf
event is earlier or later than the samples from Arm SPE trace data; to
do comparision, it needs to use the same unit for the time.

This patch converts the event kernel time to arch timer's counter value,
thus it can be used to compare with counter value contained in Arm SPE
Timestamp packet.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 7620dcc45940..23714cf0380e 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -669,7 +669,7 @@ static int arm_spe_process_event(struct perf_session *session,
 	}
 
 	if (sample->time && (sample->time != (u64) -1))
-		timestamp = sample->time;
+		timestamp = perf_time_to_tsc(sample->time, &spe->tc);
 	else
 		timestamp = 0;
 
-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:04 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:04 +0800
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized event
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-5-leo.yan@linaro.org>

In current code, it assigns the arch timer counter to the synthesized
samples Arm SPE trace, thus the samples don't contain the kernel time
but only contain the raw counter value.

To fix the issue, this patch converts the timer counter to kernel time
and assigns it to sample timestamp.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index 23714cf0380e..c13a89f06ab8 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
 	struct arm_spe_record *record = &speq->decoder->record;
 
 	if (!spe->timeless_decoding)
-		sample->time = speq->timestamp;
+		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
 
 	sample->ip = record->from_ip;
 	sample->cpumode = arm_spe_cpumode(spe, sample->ip);
-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:05 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:05 +0800
Subject: [PATCH v4 5/6] perf arm-spe: Bail out if the trace is later than perf
 event
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-6-leo.yan@linaro.org>

It's possible that record in Arm SPE trace is later than perf event and
vice versa.  This asks to correlate the perf events and Arm SPE
synthesized events to be processed in the manner of correct timing.

To achieve the time ordering, this patch reverses the flow, it firstly
calls arm_spe_sample() and then calls arm_spe_decode().  By comparing
the timestamp value and detect the perf event is coming earlier than Arm
SPE trace data, it bails out from the decoding loop, the last record is
pushed into auxtrace stack and is deferred to generate sample.  To track
the timestamp, everytime it updates timestamp for the latest record.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index c13a89f06ab8..b37d1cacebe9 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -434,12 +434,36 @@ static int arm_spe_sample(struct arm_spe_queue *speq)
 static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 {
 	struct arm_spe *spe = speq->spe;
+	struct arm_spe_record *record;
 	int ret;
 
 	if (!spe->kernel_start)
 		spe->kernel_start = machine__kernel_start(spe->machine);
 
 	while (1) {
+		/*
+		 * The usual logic is firstly to decode the packets, and then
+		 * based the record to synthesize sample; but here the flow is
+		 * reversed: it calls arm_spe_sample() for synthesizing samples
+		 * prior to arm_spe_decode().
+		 *
+		 * Two reasons for this code logic:
+		 * 1. Firstly, when setup queue in arm_spe__setup_queue(), it
+		 * has decoded trace data and generated a record, but the record
+		 * is left to generate sample until run to here, so it's correct
+		 * to synthesize sample for the left record.
+		 * 2. After decoding trace data, it needs to compare the record
+		 * timestamp with the coming perf event, if the record timestamp
+		 * is later than the perf event, it needs bail out and pushs the
+		 * record into auxtrace heap, thus the record can be deferred to
+		 * synthesize sample until run to here at the next time; so this
+		 * can correlate samples between Arm SPE trace data and other
+		 * perf events with correct time ordering.
+		 */
+		ret = arm_spe_sample(speq);
+		if (ret)
+			return ret;
+
 		ret = arm_spe_decode(speq->decoder);
 		if (!ret) {
 			pr_debug("No data or all data has been processed.\n");
@@ -453,10 +477,17 @@ static int arm_spe_run_decoder(struct arm_spe_queue *speq, u64 *timestamp)
 		if (ret < 0)
 			continue;
 
-		ret = arm_spe_sample(speq);
-		if (ret)
-			return ret;
+		record = &speq->decoder->record;
 
+		/* Update timestamp for the last record */
+		if (record->timestamp > speq->timestamp)
+			speq->timestamp = record->timestamp;
+
+		/*
+		 * If the timestamp of the queue is later than timestamp of the
+		 * coming perf event, bail out so can allow the perf event to
+		 * be processed ahead.
+		 */
 		if (!spe->timeless_decoding && speq->timestamp >= *timestamp) {
 			*timestamp = speq->timestamp;
 			return 0;
-- 
2.25.1



From leo.yan at linaro.org  Mon Apr 12 10:10:06 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 12 Apr 2021 17:10:06 +0800
Subject: [PATCH v4 6/6] perf arm-spe: Don't wait for PERF_RECORD_EXIT event
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <20210412091006.468557-7-leo.yan@linaro.org>

When decode Arm SPE trace, it waits for PERF_RECORD_EXIT event (the last
perf event) for processing trace data, which is needless and even might
cause logic error, e.g. it might fail to correlate perf events with Arm
SPE events correctly.

So this patch removes the condition checking for PERF_RECORD_EXIT event.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/util/arm-spe.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
index b37d1cacebe9..654fa2413823 100644
--- a/tools/perf/util/arm-spe.c
+++ b/tools/perf/util/arm-spe.c
@@ -717,11 +717,7 @@ static int arm_spe_process_event(struct perf_session *session,
 					sample->time);
 		}
 	} else if (timestamp) {
-		if (event->header.type == PERF_RECORD_EXIT) {
-			err = arm_spe_process_queues(spe, timestamp);
-			if (err)
-				return err;
-		}
+		err = arm_spe_process_queues(spe, timestamp);
 	}
 
 	return err;
-- 
2.25.1



From victor.liu at nxp.com  Mon Apr 12 10:11:28 2021
From: victor.liu at nxp.com (Liu Ying)
Date: Mon, 12 Apr 2021 17:11:28 +0800
Subject: [PATCH v5 2/2] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
In-Reply-To: <c68efbfc19de3bf1a6586edc71a9b9bdd05c84eb.1617968250.git.agx@sigxcpu.org>
References: <cover.1617968250.git.agx@sigxcpu.org>
 <c68efbfc19de3bf1a6586edc71a9b9bdd05c84eb.1617968250.git.agx@sigxcpu.org>
Message-ID: <d44e5261e8a09d4a221e9c04dd6fc831dfa3fe13.camel@nxp.com>

Hi Guido,

On Fri, 2021-04-09 at 13:40 +0200, Guido G?nther wrote:
> This allows us to shut down the mipi power domain on the imx8. The
> alternative would be to drop the dphy from the mipi power domain in the
> SOCs device tree and only have the DSI host controller visible there but
> since the PD is mostly about the PHY that would defeat it's purpose.
> 
> This allows to shut off the power domain when blanking the LCD panel:
> 
> pm_genpd_summary before:
> 
> domain                          status          slaves
>     /device                                             runtime status
> ----------------------------------------------------------------------
> mipi                            on
>     /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  unsupported
>     /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended
> 
> after:
> 
> mipi                            off-0
>     /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00300.dphy  suspended
>     /devices/platform/soc at 0/soc at 0:bus at 30800000/30a00000.mipi_dsi  suspended
> 
> Signed-off-by: Guido G?nther <agx at sigxcpu.org>
> ---
>  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b397ca..f89a0c458499 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -14,6 +14,7 @@
>  #include <linux/of_platform.h>
>  #include <linux/phy/phy.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/regmap.h>
>  
>  /* DPHY registers */
> @@ -469,20 +470,32 @@ static int mixel_dphy_probe(struct platform_device *pdev)
>  
>  	dev_set_drvdata(dev, priv);
>  
> +	pm_runtime_enable(dev);
> +
>  	phy = devm_phy_create(dev, np, &mixel_dphy_phy_ops);
>  	if (IS_ERR(phy)) {
> +		pm_runtime_disable(&pdev->dev);

It's fine to just use 'dev'.

>  		dev_err(dev, "Failed to create phy %ld\n", PTR_ERR(phy));
>  		return PTR_ERR(phy);
>  	}
>  	phy_set_drvdata(phy, priv);
>  
>  	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> +	if (IS_ERR(phy_provider))
> +		pm_runtime_disable(&pdev->dev);

Ditto.

With the above two addressed:

Reviewed-by: Liu Ying <victor.liu at nxp.com>

>  
>  	return PTR_ERR_OR_ZERO(phy_provider);
>  }
>  
> +static int mixel_dphy_remove(struct platform_device *pdev)
> +{
> +	pm_runtime_disable(&pdev->dev);
> +	return 0;
> +}
> +
>  static struct platform_driver mixel_dphy_driver = {
>  	.probe	= mixel_dphy_probe,
> +	.remove = mixel_dphy_remove,
>  	.driver = {
>  		.name = "mixel-mipi-dphy",
>  		.of_match_table	= mixel_dphy_of_match,



From tomi.valkeinen at ideasonboard.com  Mon Apr 12 10:15:02 2021
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Mon, 12 Apr 2021 12:15:02 +0300
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <20210412083605.qnpf2mxy3rcaj7dv@ti.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
 <YHP+O3HPCCWOQRb0@pendragon.ideasonboard.com>
 <20210412083605.qnpf2mxy3rcaj7dv@ti.com>
Message-ID: <04b96345-f1a9-71bc-ce76-07215648e810@ideasonboard.com>

On 12/04/2021 11:36, Pratyush Yadav wrote:
> + Vignesh
> 
> On 12/04/21 11:00AM, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> Thank you for the patch.
>>
>> On Mon, Apr 12, 2021 at 10:53:06AM +0300, Tomi Valkeinen wrote:
>>> AM654 EVM boards are not shipped with OV5640 sensor module, it is a
>>> separate purchase. OV5640 module is also just one of the possible
>>> sensors or capture boards you can connect.
>>>
>>> However, for some reason, OV5640 has been added to the board dts file,
>>> making it cumbersome to use other sensors.
>>>
>>> Remove the OV5640 from the dts file so that it is easy to use other
>>> sensors via DT overlays.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>>> ---
>>>   .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
>>>   1 file changed, 27 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> index fe3043943906..76358b4944e1 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> @@ -85,12 +85,6 @@ sw6 {
>>>   			gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
>>>   		};
>>>   	};
>>> -
>>> -	clk_ov5640_fixed: clock {
>>> -		compatible = "fixed-clock";
>>> -		#clock-cells = <0>;
>>> -		clock-frequency = <24000000>;
>>> -	};
>>>   };
>>>   
>>>   &wkup_pmx0 {
>>> @@ -288,22 +282,6 @@ &main_i2c1 {
>>>   	pinctrl-0 = <&main_i2c1_pins_default>;
>>>   	clock-frequency = <400000>;
>>>   
>>> -	ov5640: camera at 3c {
>>> -		compatible = "ovti,ov5640";
>>> -		reg = <0x3c>;
>>> -
>>> -		clocks = <&clk_ov5640_fixed>;
>>> -		clock-names = "xclk";
>>> -
>>> -		port {
>>> -			csi2_cam0: endpoint {
>>> -				remote-endpoint = <&csi2_phy0>;
>>> -				clock-lanes = <0>;
>>> -				data-lanes = <1 2>;
>>> -			};
>>> -		};
>>> -	};
>>> -
>>>   };
>>
>> As for patch 1/2, you could drop the two nodes completely. Same question
>> about overlay availability.
> 
> The &main_i2c1 node was added much before the OV5640 node in
> 19a1768fc34a (arm64: dts: ti: k3-am654-base-board: Add I2C nodes,
> 2018-11-13). I wonder if there is any reason for having it present even
> if there are no subnodes. One reason that I can think of is that this
> node defines the pinmux configuration and clock frequency which makes
> more sense here than in an overlay.

Right, and we also have an empty main_i2c2 there. I'd rather keep empty 
main_i2c1 to be in line with main_i2c2, and to have the pinmux in the 
main dts file. Unless someone can say we can remove both main_i2c1 and 
main_i2c2.

> 
>>
>>>   
>>>   &main_i2c2 {
>>> @@ -497,11 +475,6 @@ flash at 0{
>>>   };
>>>   
>>>   &csi2_0 {
>>> -	csi2_phy0: endpoint {
>>> -		remote-endpoint = <&csi2_cam0>;
>>> -		clock-lanes = <0>;
>>> -		data-lanes = <1 2>;
>>> -	};
>>>   };
> 
> I agree with Laurent that the entire &csi2_0 node can be dropped.
> 
> Have you tested the CAL driver with this node removed and no overlay to
> add it back? Can it handle the error gracefully or does it crash and
> burn?

No, I haven't tested that for a while.

  Tomi


From vigneshr at ti.com  Mon Apr 12 10:26:21 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Mon, 12 Apr 2021 14:56:21 +0530
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <20210412083605.qnpf2mxy3rcaj7dv@ti.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
 <YHP+O3HPCCWOQRb0@pendragon.ideasonboard.com>
 <20210412083605.qnpf2mxy3rcaj7dv@ti.com>
Message-ID: <61ca0a2b-900e-daca-3d51-e8fd2c2b8073@ti.com>



On 12/04/21 2:06 pm, Pratyush Yadav wrote:
> + Vignesh
> 
> On 12/04/21 11:00AM, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> Thank you for the patch.
>>
>> On Mon, Apr 12, 2021 at 10:53:06AM +0300, Tomi Valkeinen wrote:
>>> AM654 EVM boards are not shipped with OV5640 sensor module, it is a
>>> separate purchase. OV5640 module is also just one of the possible
>>> sensors or capture boards you can connect.
>>>
>>> However, for some reason, OV5640 has been added to the board dts file,
>>> making it cumbersome to use other sensors.
>>>
>>> Remove the OV5640 from the dts file so that it is easy to use other
>>> sensors via DT overlays.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
>>> ---
>>>? .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
>>>? 1 file changed, 27 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> index fe3043943906..76358b4944e1 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
>>> @@ -85,12 +85,6 @@ sw6 {
>>>????????????????????? gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
>>>????????????? };
>>>????? };
>>> -
>>> -?? clk_ov5640_fixed: clock {
>>> -?????????? compatible = "fixed-clock";
>>> -?????????? #clock-cells = <0>;
>>> -?????????? clock-frequency = <24000000>;
>>> -?? };
>>>? };
>>>? 
>>>? &wkup_pmx0 {
>>> @@ -288,22 +282,6 @@ &main_i2c1 {
>>>????? pinctrl-0 = <&main_i2c1_pins_default>;
>>>????? clock-frequency = <400000>;
>>>? 
>>> -?? ov5640: camera at 3c {
>>> -?????????? compatible = "ovti,ov5640";
>>> -?????????? reg = <0x3c>;
>>> -
>>> -?????????? clocks = <&clk_ov5640_fixed>;
>>> -?????????? clock-names = "xclk";
>>> -
>>> -?????????? port {
>>> -?????????????????? csi2_cam0: endpoint {
>>> -?????????????????????????? remote-endpoint = <&csi2_phy0>;
>>> -?????????????????????????? clock-lanes = <0>;
>>> -?????????????????????????? data-lanes = <1 2>;
>>> -?????????????????? };
>>> -?????????? };
>>> -?? };
>>> -
>>>? };
>>
>> As for patch 1/2, you could drop the two nodes completely. Same question
>> about overlay availability.
> 
> The &main_i2c1 node was added much before the OV5640 node in 
> 19a1768fc34a (arm64: dts: ti: k3-am654-base-board: Add I2C nodes, 
> 2018-11-13). I wonder if there is any reason for having it present even 
> if there are no subnodes. One reason that I can think of is that this 
> node defines the pinmux configuration and clock frequency which makes 
> more sense here than in an overlay.
> 

No, please don't drop main_i2c1 node. As long as pinmux is setup, its
possible to communicate with I2C devices from user space too even when
there are no subnodes.

-- 
Regards
Vignesh


From dillon.minfei at gmail.com  Mon Apr 12 10:31:38 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Mon, 12 Apr 2021 17:31:38 +0800
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
Message-ID: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.

remove unused local_irq_save/restore call.

Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Gerald Baeza <gerald.baeza at foss.st.com>
Cc: Erwan Le Ray <erwan.leray at foss.st.com>
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v2: remove unused code from stm32_usart_threaded_interrupt() according from
    Greg's review.

 drivers/tty/serial/stm32-usart.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index b3675cf25a69..b1ba5e36e36e 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	u32 old_cr1, new_cr1;
 	int locked = 1;
 
-	local_irq_save(flags);
 	if (port->sysrq)
 		locked = 0;
 	else if (oops_in_progress)
-		locked = spin_trylock(&port->lock);
+		locked = spin_trylock_irqsave(&port->lock, flags);
 	else
-		spin_lock(&port->lock);
+		spin_lock_irqsave(&port->lock, flags);
 
 	/* Save and disable interrupts, enable the transmitter */
 	old_cr1 = readl_relaxed(port->membase + ofs->cr1);
@@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	writel_relaxed(old_cr1, port->membase + ofs->cr1);
 
 	if (locked)
-		spin_unlock(&port->lock);
-	local_irq_restore(flags);
+		spin_unlock_irqrestore(&port->lock, flags);
 }
 
 static int stm32_usart_console_setup(struct console *co, char *options)
-- 
2.7.4



From David.Laight at ACULAB.COM  Mon Apr 12 10:37:21 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 12 Apr 2021 09:37:21 +0000
Subject: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
In-Reply-To: <20210412085545.2595431-6-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-6-hch@lst.de>
Message-ID: <15be19af19174c7692dd795297884096@AcuMS.aculab.com>

From: Christoph Hellwig
> Sent: 12 April 2021 09:56
> 
> Provide a single common definition for the compat_flock and
> compat_flock64 structures using the same tricks as for the native
> variants.  An extra define is added for the packing required on x86.
> 
...
>  /*
> - * IA32 uses 4 byte alignment for 64 bit quantities,
> - * so we need to pack this structure.
> + * IA32 uses 4 byte alignment for 64 bit quantities, so we need to pack the
> + * compat flock64 structure.
>   */
> -struct compat_flock64 {
> -	short		l_type;
> -	short		l_whence;
> -	compat_loff_t	l_start;
> -	compat_loff_t	l_len;
> -	compat_pid_t	l_pid;
> -} __attribute__((packed));
> +#define __ARCH_NEED_COMPAT_FLOCK64_PACKED

That shouldn't need to be packed at all.
(Since the 32bit variant isn't packed.)

compat_loff_t should itself have __attribute__((aligned(4)))
probably inherited from compat_s64.
So l_start will be at offset 4 without the __packed.

I'm guessing that compat_pid_t is 16 bits?
So the native 32bit version has an unnamed 2 byte structure pad.
The 'packed' removes this pad from the compat structure.

AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
adding an explicit pad for the implicit pad the compiler
would generate because compat_pid_t is 16 bits.

If the padding need not be named for the 64bit system calls.
(Where there is probably rather more padding all over the place.)
then it doesn't need to be named for the compat variants.

Even the mips extra padding could be removed.
F_GETLK might be expected to do a read-write of them, so
return EFAULT if not mapped.
But nothing should be testing the EFAULT is returned!

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From vkoul at kernel.org  Mon Apr 12 10:39:10 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 12 Apr 2021 15:09:10 +0530
Subject: [PATCH v14 12/12] dmaengine: imx-sdma: add terminated list for
 freed descriptor in worker
In-Reply-To: <1617809456-17693-13-git-send-email-yibin.gong@nxp.com>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
 <1617809456-17693-13-git-send-email-yibin.gong@nxp.com>
Message-ID: <YHQVPoQAYVuHL3/S@vkoul-mobl.Dlink>

On 07-04-21, 23:30, Robin Gong wrote:
> Add terminated list for keeping descriptor so that it could be freed in
> worker without any potential involving next descriptor raised up before
> this descriptor freed, because vchan_get_all_descriptors get all
> descriptors including the last terminated descriptor and the next
> descriptor, hence, the next descriptor maybe freed unexpectly when it's
> done in worker without this patch.
> https://www.spinics.net/lists/dmaengine/msg23367.html

Sound like you should implement .device_synchronize() and do the actual
work there..?

> 
> Signed-off-by: Robin Gong <yibin.gong at nxp.com>
> Reported-by: Richard Leitner <richard.leitner at skidata.com>
> ---
>  drivers/dma/imx-sdma.c | 17 ++++++++++-------
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index 9519b41..4174580 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -381,6 +381,7 @@ struct sdma_channel {
>  	enum dma_status			status;
>  	struct imx_dma_data		data;
>  	struct work_struct		terminate_worker;
> +	struct list_head                terminated;
>  	bool				is_ram_script;
>  };
>  
> @@ -1041,9 +1042,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
>  {
>  	struct sdma_channel *sdmac = container_of(work, struct sdma_channel,
>  						  terminate_worker);
> -	unsigned long flags;
> -	LIST_HEAD(head);
> -
>  	/*
>  	 * According to NXP R&D team a delay of one BD SDMA cost time
>  	 * (maximum is 1ms) should be added after disable of the channel
> @@ -1052,10 +1050,7 @@ static void sdma_channel_terminate_work(struct work_struct *work)
>  	 */
>  	usleep_range(1000, 2000);
>  
> -	spin_lock_irqsave(&sdmac->vc.lock, flags);
> -	vchan_get_all_descriptors(&sdmac->vc, &head);
> -	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
> -	vchan_dma_desc_free_list(&sdmac->vc, &head);
> +	vchan_dma_desc_free_list(&sdmac->vc, &sdmac->terminated);
>  }
>  
>  static int sdma_terminate_all(struct dma_chan *chan)
> @@ -1069,6 +1064,13 @@ static int sdma_terminate_all(struct dma_chan *chan)
>  
>  	if (sdmac->desc) {
>  		vchan_terminate_vdesc(&sdmac->desc->vd);
> +		/*
> +		 * move out current descriptor into terminated list so that
> +		 * it could be free in sdma_channel_terminate_work alone
> +		 * later without potential involving next descriptor raised
> +		 * up before the last descriptor terminated.
> +		 */
> +		vchan_get_all_descriptors(&sdmac->vc, &sdmac->terminated);
>  		sdmac->desc = NULL;
>  		schedule_work(&sdmac->terminate_worker);
>  	}
> @@ -2075,6 +2077,7 @@ static int sdma_probe(struct platform_device *pdev)
>  
>  		sdmac->channel = i;
>  		sdmac->vc.desc_free = sdma_desc_free;
> +		INIT_LIST_HEAD(&sdmac->terminated);
>  		INIT_WORK(&sdmac->terminate_worker,
>  				sdma_channel_terminate_work);
>  		/*
> -- 
> 2.7.4

-- 
~Vinod


From narmstrong at baylibre.com  Mon Apr 12 10:39:23 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:23 +0200
Subject: [PATCH v2 0/5] mediatek: hdmi: add MT8167 configuration
Message-ID: <20210412093928.3321194-1-narmstrong@baylibre.com>

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes.

To achieve this:
- switch the mediatek HDMI bindings to YAML
- add the MT8167 compatible
- add a boolean to discard the non-CEA modes
- add a value to specify mac TMDS supported clock
- add a conf entry for the MT8167 compatible

Neil Armstrong (5):
  dt-bindings: display: mediatek,hdmi: Convert to use graph schema
  dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings
  gpu/drm: mediatek: hdmi: add check for CEA modes only
  gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock
  gpu/drm: mediatek: hdmi: add MT8167 configuration

 .../display/mediatek/mediatek,cec.yaml        |  52 +++++++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  58 ++++++++
 .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
 .../display/mediatek/mediatek,hdmi.yaml       | 132 +++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_hdmi.c           |  17 +++
 5 files changed, 259 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 12 10:39:24 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:24 +0200
Subject: [PATCH v2 1/5] dt-bindings: display: mediatek,
 hdmi: Convert to use graph schema
In-Reply-To: <20210412093928.3321194-1-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
Message-ID: <20210412093928.3321194-2-narmstrong@baylibre.com>

Update the mediatek,dpi binding to use the graph schema.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 .../display/mediatek/mediatek,cec.yaml        |  51 +++++++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 ++++++++
 .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
 .../display/mediatek/mediatek,hdmi.yaml       | 131 +++++++++++++++++
 4 files changed, 239 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
new file mode 100644
index 000000000000..408e7dfce409
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI CEC Controller Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The HDMI CEC controller handles hotplug detection and CEC communication.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt7623-hdmi
+      - mediatek,mt8173-hdmi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    cec: cec at 10013000 {
+        compatible = "mediatek,mt8173-cec";
+        reg = <0x10013000 0xbc>;
+        interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&infracfg CLK_INFRA_CEC>;
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
new file mode 100644
index 000000000000..c15b3470d652
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI DDC Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt7623-hdmi
+      - mediatek,mt8173-hdmi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: ddc-i2c
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    hdmi_ddc0: i2c at 11012000 {
+        compatible = "mediatek,mt8173-hdmi-ddc";
+        reg = <0x11012000 0x1c>;
+        interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&pericfg CLK_PERI_I2C5>;
+        clock-names = "ddc-i2c";
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
deleted file mode 100644
index b284ca51b913..000000000000
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-Mediatek HDMI Encoder
-=====================
-
-The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
-its parallel input.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-hdmi".
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
-  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
-- phys: phandle link to the HDMI PHY node.
-  See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
-- phy-names: must contain "hdmi"
-- mediatek,syscon-hdmi: phandle link and register offset to the system
-  configuration registers. For mt8173 this must be offset 0x900 into the
-  MMSYS_CONFIG region: <&mmsys 0x900>.
-- ports: A node containing input and output port nodes with endpoint
-  definitions as documented in Documentation/devicetree/bindings/graph.txt.
-- port at 0: The input port in the ports node should be connected to a DPI output
-  port.
-- port at 1: The output port in the ports node should be connected to the input
-  port of a connector node that contains a ddc-i2c-bus property, or to the
-  input port of an attached bridge chip, such as a SlimPort transmitter.
-
-HDMI CEC
-========
-
-The HDMI CEC controller handles hotplug detection and CEC communication.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-cec"
-- the supported chips are mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clock
-
-HDMI DDC
-========
-
-The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
-The Mediatek's I2C controller is used to interface with I2C devices.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-hdmi-ddc"
-- the supported chips are mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- clocks: device clock
-- clock-names: Should be "ddc-i2c".
-
-HDMI PHY
-========
-See phy/mediatek,hdmi-phy.yaml
-
-Example:
-
-cec: cec at 10013000 {
-	compatible = "mediatek,mt8173-cec";
-	reg = <0 0x10013000 0 0xbc>;
-	interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&infracfg CLK_INFRA_CEC>;
-};
-
-hdmi_phy: hdmi-phy at 10209100 {
-	compatible = "mediatek,mt8173-hdmi-phy";
-	reg = <0 0x10209100 0 0x24>;
-	clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
-	clock-names = "pll_ref";
-	clock-output-names = "hdmitx_dig_cts";
-	mediatek,ibias = <0xa>;
-	mediatek,ibias_up = <0x1c>;
-	#clock-cells = <0>;
-	#phy-cells = <0>;
-};
-
-hdmi_ddc0: i2c at 11012000 {
-	compatible = "mediatek,mt8173-hdmi-ddc";
-	reg = <0 0x11012000 0 0x1c>;
-	interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&pericfg CLK_PERI_I2C5>;
-	clock-names = "ddc-i2c";
-};
-
-hdmi0: hdmi at 14025000 {
-	compatible = "mediatek,mt8173-hdmi";
-	reg = <0 0x14025000 0 0x400>;
-	interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
-		 <&mmsys CLK_MM_HDMI_PLLCK>,
-		 <&mmsys CLK_MM_HDMI_AUDIO>,
-		 <&mmsys CLK_MM_HDMI_SPDIF>;
-	clock-names = "pixel", "pll", "bclk", "spdif";
-	pinctrl-names = "default";
-	pinctrl-0 = <&hdmi_pin>;
-	phys = <&hdmi_phy>;
-	phy-names = "hdmi";
-	mediatek,syscon-hdmi = <&mmsys 0x900>;
-	assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
-	assigned-clock-parents = <&hdmi_phy>;
-
-	ports {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		port at 0 {
-			reg = <0>;
-
-			hdmi0_in: endpoint {
-				remote-endpoint = <&dpi0_out>;
-			};
-		};
-
-		port at 1 {
-			reg = <1>;
-
-			hdmi0_out: endpoint {
-				remote-endpoint = <&hdmi_con_in>;
-			};
-		};
-	};
-};
-
-connector {
-	compatible = "hdmi-connector";
-	type = "a";
-	ddc-i2c-bus = <&hdmiddc0>;
-
-	port {
-		hdmi_con_in: endpoint {
-			remote-endpoint = <&hdmi0_out>;
-		};
-	};
-};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
new file mode 100644
index 000000000000..9c125d7c8934
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI Encoder Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
+  its parallel input.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt2701-hdmi
+      - mediatek,mt7623-hdmi
+      - mediatek,mt8173-hdmi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: Pixel Clock
+      - description: HDMI PLL
+      - description: Bit Clock
+      - description: S/PDIF Clock
+
+  clock-names:
+    items:
+      - const: pixel
+      - const: pll
+      - const: bclk
+      - const: spdif
+
+  phys:
+    maxItems: 1
+
+  phy-names:
+    items:
+      - const: hdmi
+
+  mediatek,syscon-hdmi:
+    $ref: '/schemas/types.yaml#/definitions/phandle'
+    minItems: 2
+    description: |
+      phandle link and register offset to the system configuration registers.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port at 0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          Input port node. This port should be connected to a DPI output port.
+
+      port at 1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          Output port node. This port should be connected to the input port of a connector
+          node that contains a ddc-i2c-bus property, or to the  input port of an attached
+          bridge chip, such as a SlimPort transmitter.
+
+    required:
+      - port at 0
+      - port at 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - phys
+  - phy-names
+  - mediatek,syscon-hdmi
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    hdmi0: hdmi at 14025000 {
+        reg = <0x14025000 0x400>;
+        interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+             <&mmsys CLK_MM_HDMI_PLLCK>,
+             <&mmsys CLK_MM_HDMI_AUDIO>,
+             <&mmsys CLK_MM_HDMI_SPDIF>;
+        clock-names = "pixel", "pll", "bclk", "spdif";
+        pinctrl-names = "default";
+        pinctrl-0 = <&hdmi_pin>;
+        phys = <&hdmi_phy>;
+        phy-names = "hdmi";
+        mediatek,syscon-hdmi = <&mmsys 0x900>;
+
+        ports {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          port at 0 {
+            reg = <0>;
+
+            hdmi0_in: endpoint {
+              remote-endpoint = <&dpi0_out>;
+            };
+          };
+
+          port at 1 {
+            reg = <1>;
+
+            hdmi0_out: endpoint {
+              remote-endpoint = <&hdmi_con_in>;
+            };
+          };
+        };
+    };
+
+...
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 12 10:39:25 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:25 +0200
Subject: [PATCH v2 2/5] dt-bindings: mediatek: add mt8167 to hdmi,
 hdmi-ddc and cec bindings
In-Reply-To: <20210412093928.3321194-1-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
Message-ID: <20210412093928.3321194-3-narmstrong@baylibre.com>

Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 .../devicetree/bindings/display/mediatek/mediatek,cec.yaml       | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml      | 1 +
 3 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 408e7dfce409..23e21656ca55 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt7623-hdmi
+      - mediatek,mt8167-hdmi
       - mediatek,mt8173-hdmi
 
   reg:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index c15b3470d652..9d7148b1a7c3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt7623-hdmi
+      - mediatek,mt8167-hdmi
       - mediatek,mt8173-hdmi
 
   reg:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index 9c125d7c8934..01ab0e8e02bc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -19,6 +19,7 @@ properties:
     enum:
       - mediatek,mt2701-hdmi
       - mediatek,mt7623-hdmi
+      - mediatek,mt8167-hdmi
       - mediatek,mt8173-hdmi
 
   reg:
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 12 10:39:26 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:26 +0200
Subject: [PATCH v2 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes only
In-Reply-To: <20210412093928.3321194-1-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
Message-ID: <20210412093928.3321194-4-narmstrong@baylibre.com>

Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index dea46d66e712..0539262e69d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,7 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
 	bool tz_disabled;
+	bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
 			return MODE_BAD;
 	}
 
+	if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+		return MODE_BAD;
+
 	if (mode->clock < 27000)
 		return MODE_CLOCK_LOW;
 	if (mode->clock > 297000)
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 12 10:39:27 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:27 +0200
Subject: [PATCH v2 4/5] gpu/drm: mediatek: hdmi: add optional limit on maximal
 HDMI mode clock
In-Reply-To: <20210412093928.3321194-1-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
Message-ID: <20210412093928.3321194-5-narmstrong@baylibre.com>

Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0539262e69d3..bc50d97f2553 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -149,6 +149,7 @@ struct hdmi_audio_param {
 struct mtk_hdmi_conf {
 	bool tz_disabled;
 	bool cea_modes_only;
+	unsigned long max_mode_clock;
 };
 
 struct mtk_hdmi {
@@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
 	if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
 		return MODE_BAD;
 
+	if (hdmi->conf->max_mode_clock &&
+	    mode->clock > hdmi->conf->max_mode_clock)
+		return MODE_CLOCK_HIGH;
+
 	if (mode->clock < 27000)
 		return MODE_CLOCK_LOW;
 	if (mode->clock > 297000)
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 12 10:39:28 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 11:39:28 +0200
Subject: [PATCH v2 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration
In-Reply-To: <20210412093928.3321194-1-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
Message-ID: <20210412093928.3321194-6-narmstrong@baylibre.com>

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index bc50d97f2553..c1651a83700d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
 	.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+	.max_mode_clock = 148500,
+	.cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
 	{ .compatible = "mediatek,mt2701-hdmi",
 	  .data = &mtk_hdmi_conf_mt2701,
 	},
+	{ .compatible = "mediatek,mt8167-hdmi",
+	  .data = &mtk_hdmi_conf_mt8167,
+	},
 	{ .compatible = "mediatek,mt8173-hdmi",
 	},
 	{}
-- 
2.25.1



From Jisheng.Zhang at synaptics.com  Mon Apr 12 10:41:01 2021
From: Jisheng.Zhang at synaptics.com (Jisheng Zhang)
Date: Mon, 12 Apr 2021 17:41:01 +0800
Subject: [PATCH] arm64: kprobes: Restore local irqflag if kprobes is cancelled
Message-ID: <20210412174101.6bfb0594@xhacker.debian>

If instruction being single stepped caused a page fault, the kprobes
is cancelled to let the page fault handler continue as a normal page
fault. But the local irqflags are disabled so cpu will restore pstate
with DAIF masked. After pagefault is serviced, the kprobes is
triggerred again, we overwrite the saved_irqflag by calling
kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
irqflag. After kprobes is serviced, the cpu pstate is retored with
DAIF masked.

This patch is inspired by one patch for riscv from Liao Chang.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
---
 arch/arm64/kernel/probes/kprobes.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 66aac2881ba8..85645b2b0c7a 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -267,10 +267,12 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
 		if (!instruction_pointer(regs))
 			BUG();
 
-		if (kcb->kprobe_status == KPROBE_REENTER)
+		if (kcb->kprobe_status == KPROBE_REENTER) {
 			restore_previous_kprobe(kcb);
-		else
+		} else {
+			kprobes_restore_local_irqflag(kcb, regs);
 			reset_current_kprobe();
+		}
 
 		break;
 	case KPROBE_HIT_ACTIVE:
-- 
2.31.0



From agx at sigxcpu.org  Mon Apr 12 10:41:03 2021
From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=)
Date: Mon, 12 Apr 2021 11:41:03 +0200
Subject: [PATCH v5 1/2] phy: core: Use runtime pm during configure too
In-Reply-To: <3ae6e6413901cbc9e432c7057db8fb9e81e56f39.camel@nxp.com>
References: <cover.1617968250.git.agx@sigxcpu.org>
 <2de2ee26bbf443491dfff1c802f2fa9efaf58d52.1617968250.git.agx@sigxcpu.org>
 <3ae6e6413901cbc9e432c7057db8fb9e81e56f39.camel@nxp.com>
Message-ID: <YHQVr6HYpfW5r5AO@bogon.m.sigxcpu.org>

Hi,
On Mon, Apr 12, 2021 at 04:40:56PM +0800, Liu Ying wrote:
> Hi Guido,
> 
> On Fri, 2021-04-09 at 13:40 +0200, Guido G?nther wrote:
> > The phy's configure phase usually needs register access so taking the
> > device out of pm_runtime suspend looks useful.
> > 
> > There's currently two in tree drivers using runtime pm and .configure
> > (qualcomm/phy-qcom-qmp.c, rockchip/phy-rockchip-inno-dsidphy.c) but both
> > don't use the phy layers 'transparent' runtime phy_pm_runtime handling
> > but manage it manually so this will for now only affect the
> > phy-fsl-imx8-mipi-dphy driver.
> 
> IIUC, the qualcomm one's runtime PM is managed by the phy core when
> users enable it using power/control in sysfs(see comment just before
> pm_runtime_forbid() in that driver).
> I'm assuming it's affected and it would be good to test it.

Ah, right. I'll reword the commit message but i don't have any means to
test it.

> I'm not pretty sure if the rockchip one is affected or not, because I'm
> assuming the power/control nodes of phy->dev and phy->parent.dev in
> sysfs are both 'auto' after the driver probes.

Testing if adding runtime pm for .configure to phy_core breaks anything
here would be great too.

I've added Dmitry and Heiko to cc: since they were active in those
drivers lately and i sure don't want to break these.

> > 
> > Signed-off-by: Guido G?nther <agx at sigxcpu.org>
> > ---
> >  drivers/phy/phy-core.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> > index ccb575b13777..256a964d52d3 100644
> > --- a/drivers/phy/phy-core.c
> > +++ b/drivers/phy/phy-core.c
> > @@ -470,10 +470,16 @@ int phy_configure(struct phy *phy, union phy_configure_opts *opts)
> >  	if (!phy->ops->configure)
> >  		return -EOPNOTSUPP;
> >  
> > +	ret = phy_pm_runtime_get_sync(phy);
> > +	if (ret < 0 && ret != -ENOTSUPP)
> > +		return ret;
> > +	ret = 0; /* Override possible ret == -ENOTSUPP */
> 
> This override is not needed, because 'ret' will be the return value of
> phy->ops->configure() right below.

I thought being explicit is better here but i'll drop that for the next
rev.

Thanks!
 -- Guido

> 
> Regards,
> Liu Ying
> 
> > +
> >  	mutex_lock(&phy->mutex);
> >  	ret = phy->ops->configure(phy, opts);
> >  	mutex_unlock(&phy->mutex);
> >  
> > +	phy_pm_runtime_put(phy);
> >  	return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(phy_configure);
> 


From jacopo at jmondi.org  Mon Apr 12 10:43:12 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 11:43:12 +0200
Subject: [PATCH v2 04/30] media: atmel: atmel-isc: specialize max width
 and max height
In-Reply-To: <20210405155105.162529-5-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-5-eugen.hristev@microchip.com>
Message-ID: <20210412094312.tsghnyhglxf3roiy@uno.localdomain>

Hi Eugene,

On Mon, Apr 05, 2021 at 06:50:39PM +0300, Eugen Hristev wrote:
> Move the max width and max height constants to the product specific driver
> and have them in the device struct.
>
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
>  drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
>  .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
>  3 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
> index 45fc8dbb7943..350076dd029a 100644
> --- a/drivers/media/platform/atmel/atmel-isc-base.c
> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
> @@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
>  	 * just use the maximum ISC can receive.
>  	 */
>  	if (ret) {
> -		pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
> -		pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
> +		pad_cfg->try_crop.width = isc->max_width;
> +		pad_cfg->try_crop.height = isc->max_height;
>  	} else {
>  		pad_cfg->try_crop.width = fse.max_width;
>  		pad_cfg->try_crop.height = fse.max_height;
> @@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
>  	isc->try_config.sd_format = sd_fmt;
>
>  	/* Limit to Atmel ISC hardware capabilities */
> -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> +	if (pixfmt->width > isc->max_width)
> +		pixfmt->width = isc->max_width;
> +	if (pixfmt->height > isc->max_height)
> +		pixfmt->height = isc->max_height;
>
>  	/*
>  	 * The mbus format is the one the subdev outputs.
> @@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
>  	v4l2_fill_pix_format(pixfmt, &format.format);
>
>  	/* Limit to Atmel ISC hardware capabilities */
> -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> +	if (pixfmt->width > isc->max_width)
> +		pixfmt->width = isc->max_width;
> +	if (pixfmt->height > isc->max_height)
> +		pixfmt->height = isc->max_height;

What happens if the sensor sends a frame larger that the ISC max
supported sizes ?

>
>  	pixfmt->field = V4L2_FIELD_NONE;
>  	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
> @@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
>  		return ret;
>
>  	/* Limit to Atmel ISC hardware capabilities */
> -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> +	if (f->fmt.pix.width > isc->max_width)
> +		f->fmt.pix.width = isc->max_width;
> +	if (f->fmt.pix.height > isc->max_height)
> +		f->fmt.pix.height = isc->max_height;
>
>  	isc->fmt = *f;
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
> index 8d81d9967ad2..6becc6c3aaf0 100644
> --- a/drivers/media/platform/atmel/atmel-isc.h
> +++ b/drivers/media/platform/atmel/atmel-isc.h
> @@ -10,9 +10,6 @@
>   */
>  #ifndef _ATMEL_ISC_H_
>
> -#define ISC_MAX_SUPPORT_WIDTH   2592
> -#define ISC_MAX_SUPPORT_HEIGHT  1944
> -
>  #define ISC_CLK_MAX_DIV		255
>
>  enum isc_clk_id {
> @@ -191,6 +188,9 @@ struct isc_ctrls {
>   * @gamma_table:	pointer to the table with gamma values, has
>   *			gamma_max sets of GAMMA_ENTRIES entries each
>   * @gamma_max:		maximum number of sets of inside the gamma_table
> + *
> + * @max_width:		maximum frame width, dependent on the internal RAM
> + * @max_height:		maximum frame height, dependent on the internal RAM
>   */
>  struct isc_device {
>  	struct regmap		*regmap;
> @@ -254,6 +254,9 @@ struct isc_device {
>  	/* pointer to the defined gamma table */
>  	const u32	(*gamma_table)[GAMMA_ENTRIES];
>  	u32		gamma_max;
> +
> +	u32		max_width;
> +	u32		max_height;
>  };
>
>  extern struct isc_format formats_list[];
> diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> index f45d8b96bfb8..f8d1c8ba99b3 100644
> --- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> +++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> @@ -49,8 +49,8 @@
>  #include "atmel-isc-regs.h"
>  #include "atmel-isc.h"
>
> -#define ISC_MAX_SUPPORT_WIDTH   2592
> -#define ISC_MAX_SUPPORT_HEIGHT  1944
> +#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
> +#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
>
>  #define ISC_CLK_MAX_DIV		255
>
> @@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
>  	isc->gamma_table = isc_sama5d2_gamma_table;
>  	isc->gamma_max = 2;
>
> +	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
> +	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
> +
>  	ret = isc_pipeline_init(isc);
>  	if (ret)
>  		return ret;
> --
> 2.25.1
>


From vkabatov at redhat.com  Mon Apr 12 10:44:00 2021
From: vkabatov at redhat.com (Veronika Kabatova)
Date: Mon, 12 Apr 2021 05:44:00 -0400 (EDT)
Subject: =?utf-8?Q?Re:_=E2=9D=8C_FAIL:_Test_report_for_kerne?=
 =?utf-8?Q?l_5.12.0-rc4_(arm-next,=09a61be843)?=
In-Reply-To: <cki.D5B650052E.587HEJ1V3R@redhat.com>
References: <cki.D5B650052E.587HEJ1V3R@redhat.com>
Message-ID: <1958395684.4263632.1618220640519.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "CKI Project" <cki-project at redhat.com>
> To: skt-results-master at redhat.com, will at kernel.org, "catalin marinas" <catalin.marinas at arm.com>,
> linux-arm-kernel at lists.infradead.org
> Cc: "Jianlin Shi" <jishi at redhat.com>, "Jianwen Ji" <jiji at redhat.com>, "Jeff Bastian" <jbastian at redhat.com>, "Hangbin
> Liu" <haliu at redhat.com>
> Sent: Saturday, April 10, 2021 1:40:34 AM
> Subject: ? FAIL: Test report for kernel 5.12.0-rc4 (arm-next,	a61be843)
> 
> 
> Hello,
> 
> We ran automated tests on a recent commit from this kernel tree:
> 
>        Kernel repo:
>        https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>             Commit: a61be843e1b1 - Merge branch 'for-next/fixes' into
>             for-kernelci
> 
> The results of these automated tests are provided below.
> 
>     Overall result: FAILED (see details below)
>              Merge: OK
>            Compile: OK
>              Tests: FAILED
> 
> All kernel binaries, config files, and logs are available for download here:
> 
>   https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/04/09/284003294
> 
> One or more kernel tests failed:
> 
>     aarch64:
>      ? Networking tunnel: geneve basic test
> 

Hi, this is still the same issue as previously reported, on a same commit.
We moved the pipelines to run on gitlab.com and it didn't occur to us to
turn off reporting for the initial runs there /facepalm

Sorry about the repeated notification!

Veronika

> We hope that these logs can help you find the problem quickly. For the full
> detail on our testing procedures, please scroll to the bottom of this
> message.
> 
> 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
>            `-'
> ______________________________________________________________________________
> 
> Compile testing
> ---------------
> 
> We compiled the kernel for 1 architecture:
> 
>     aarch64:
>       make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg
> 
> 
> 
> Hardware testing
> ----------------
> We booted each kernel and ran the following tests:
> 
>   aarch64:
>     Host 1:
>        ? Boot test
>        ? ACPI table test
>        ? ACPI enabled test
>        ? LTP
>        ? CIFS Connectathon
>        ? POSIX pjd-fstest suites
>        ? Loopdev Sanity
>        ? jvm - jcstress tests
>        ? Memory: fork_mem
>        ? Memory function: memfd_create
>        ? AMTU (Abstract Machine Test Utility)
>        ? Networking bridge: sanity
>        ? Ethernet drivers sanity
>        ? Networking socket: fuzz
>        ? Networking: igmp conformance test
>        ? Networking route: pmtu
>        ? Networking route_func - local
>        ? Networking route_func - forward
>        ? Networking TCP: keepalive test
>        ? Networking UDP: socket
>        ? Networking cki netfilter test
>        ? Networking tunnel: geneve basic test
>        ? Networking tunnel: gre basic
>        ? L2TP basic test
>        ? Networking tunnel: vxlan basic
>        ? Networking ipsec: basic netns - transport
>        ? Networking ipsec: basic netns - tunnel
>        ? Libkcapi AF_ALG test
>        ? pciutils: update pci ids test
>        ? ALSA PCM loopback test
>        ? ALSA Control (mixer) Userspace Element test
>        ? storage: SCSI VPD
>        ? trace: ftrace/tracer
>        ? ? i2c: i2cdetect sanity
>        ? ? Firmware test suite
>        ? ? Memory function: kaslr
>        ? ? audit: audit testsuite test
> 
>     Host 2:
>        ? Boot test
>        ? xfstests - ext4
>        ? xfstests - xfs
>        ? selinux-policy: serge-testsuite
>        ? storage: software RAID testing
>        ? Storage: swraid mdadm raid_module test
>        ? ? xfstests - btrfs
>        ? ? IPMI driver test
>        ? ? IPMItool loop stress test
>        ? ? Storage blktests
>        ? ? Storage block - filesystem fio test
>        ? ? Storage block - queue scheduler test
>        ? ? Storage nvme - tcp
>        ? ? Storage: lvm device-mapper test
>        ? ? stress: stress-ng
> 
>   Test sources: https://gitlab.com/cki-project/kernel-tests
>     ? Pull requests are welcome for new tests or improvements to existing
>     tests!
> 
> Aborted tests
> -------------
> Tests that didn't complete running successfully are marked with ???.
> If this was caused by an infrastructure issue, we try to mark that
> explicitly in the report.
> 
> Waived tests
> ------------
> If the test run included waived tests, they are marked with ?. Such tests
> are
> executed but their results are not taken into account. Tests are waived when
> their results are not reliable enough, e.g. when they're just introduced or
> are
> being fixed.
> 
> Testing timeout
> ---------------
> We aim to provide a report within reasonable timeframe. Tests that haven't
> finished running yet are marked with ?.
> 
> 
> 



From jacopo at jmondi.org  Mon Apr 12 10:46:20 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 11:46:20 +0200
Subject: [PATCH v2 05/30] media: atmel: atmel-isc: specialize dma cfg
In-Reply-To: <20210405155105.162529-6-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-6-eugen.hristev@microchip.com>
Message-ID: <20210412094620.uxzt5ri74awbmhpx@uno.localdomain>

Hi Eugene

On Mon, Apr 05, 2021 at 06:50:40PM +0300, Eugen Hristev wrote:
> The dma configuration (DCFG) is specific to the product.
> Move this configuration in the product specific driver, and add the
> field inside the driver struct.

Do you plan to match on different compatible values ?
As in that case you could retrieve platform-specific data with
of_device_get_match_data() maybe ? Just pointing it out if it's anyway
useful to you.

Thanks
  j

>
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  drivers/media/platform/atmel/atmel-isc-base.c    | 3 +--
>  drivers/media/platform/atmel/atmel-isc.h         | 2 ++
>  drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
>  3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
> index 350076dd029a..ff40ee2e2759 100644
> --- a/drivers/media/platform/atmel/atmel-isc-base.c
> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
> @@ -716,8 +716,7 @@ static int isc_configure(struct isc_device *isc)
>  	rlp_mode = isc->config.rlp_cfg_mode;
>  	pipeline = isc->config.bits_pipeline;
>
> -	dcfg = isc->config.dcfg_imode |
> -		       ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
> +	dcfg = isc->config.dcfg_imode | isc->dcfg;
>
>  	pfe_cfg0  |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
>  	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
> diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
> index 6becc6c3aaf0..d14ae096fbf6 100644
> --- a/drivers/media/platform/atmel/atmel-isc.h
> +++ b/drivers/media/platform/atmel/atmel-isc.h
> @@ -150,6 +150,7 @@ struct isc_ctrls {
>   * @hclock:		Hclock clock input (refer datasheet)
>   * @ispck:		iscpck clock (refer datasheet)
>   * @isc_clks:		ISC clocks
> + * @dcfg:		DMA master configuration, architecture dependent
>   *
>   * @dev:		Registered device driver
>   * @v4l2_dev:		v4l2 registered device
> @@ -197,6 +198,7 @@ struct isc_device {
>  	struct clk		*hclock;
>  	struct clk		*ispck;
>  	struct isc_clk		isc_clks[2];
> +	u32			dcfg;
>
>  	struct device		*dev;
>  	struct v4l2_device	v4l2_dev;
> diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> index f8d1c8ba99b3..6d9942dcd7c1 100644
> --- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> +++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> @@ -198,6 +198,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
>  	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
>  	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
>
> +	/* sama5d2-isc - 8 bits per beat */
> +	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
> +
>  	ret = isc_pipeline_init(isc);
>  	if (ret)
>  		return ret;
> --
> 2.25.1
>


From jacopo at jmondi.org  Mon Apr 12 10:53:36 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 11:53:36 +0200
Subject: [PATCH v2 04/30] media: atmel: atmel-isc: specialize max width
 and max height
In-Reply-To: <20210412094312.tsghnyhglxf3roiy@uno.localdomain>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-5-eugen.hristev@microchip.com>
 <20210412094312.tsghnyhglxf3roiy@uno.localdomain>
Message-ID: <20210412095336.vljygvokqq56kb6n@uno.localdomain>

Ups,

On Mon, Apr 12, 2021 at 11:43:12AM +0200, Jacopo Mondi wrote:
> Hi Eugene,
>
> On Mon, Apr 05, 2021 at 06:50:39PM +0300, Eugen Hristev wrote:
> > Move the max width and max height constants to the product specific driver
> > and have them in the device struct.
> >
> > Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> > ---
> >  drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
> >  drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
> >  .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
> >  3 files changed, 25 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
> > index 45fc8dbb7943..350076dd029a 100644
> > --- a/drivers/media/platform/atmel/atmel-isc-base.c
> > +++ b/drivers/media/platform/atmel/atmel-isc-base.c
> > @@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
> >  	 * just use the maximum ISC can receive.
> >  	 */
> >  	if (ret) {
> > -		pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
> > -		pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
> > +		pad_cfg->try_crop.width = isc->max_width;
> > +		pad_cfg->try_crop.height = isc->max_height;
> >  	} else {
> >  		pad_cfg->try_crop.width = fse.max_width;
> >  		pad_cfg->try_crop.height = fse.max_height;
> > @@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
> >  	isc->try_config.sd_format = sd_fmt;
> >
> >  	/* Limit to Atmel ISC hardware capabilities */
> > -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> > -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> > -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> > -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> > +	if (pixfmt->width > isc->max_width)
> > +		pixfmt->width = isc->max_width;
> > +	if (pixfmt->height > isc->max_height)
> > +		pixfmt->height = isc->max_height;
> >
> >  	/*
> >  	 * The mbus format is the one the subdev outputs.
> > @@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
> >  	v4l2_fill_pix_format(pixfmt, &format.format);
> >
> >  	/* Limit to Atmel ISC hardware capabilities */
> > -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> > -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> > -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> > -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> > +	if (pixfmt->width > isc->max_width)
> > +		pixfmt->width = isc->max_width;
> > +	if (pixfmt->height > isc->max_height)
> > +		pixfmt->height = isc->max_height;
>
> What happens if the sensor sends a frame larger that the ISC max
> supported sizes ?
>

I meant to ask this question on the previous patch :/

> >
> >  	pixfmt->field = V4L2_FIELD_NONE;
> >  	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
> > @@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
> >  		return ret;
> >
> >  	/* Limit to Atmel ISC hardware capabilities */
> > -	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> > -		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> > -	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> > -		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
> > +	if (f->fmt.pix.width > isc->max_width)
> > +		f->fmt.pix.width = isc->max_width;
> > +	if (f->fmt.pix.height > isc->max_height)
> > +		f->fmt.pix.height = isc->max_height;
> >
> >  	isc->fmt = *f;
> >
> > diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
> > index 8d81d9967ad2..6becc6c3aaf0 100644
> > --- a/drivers/media/platform/atmel/atmel-isc.h
> > +++ b/drivers/media/platform/atmel/atmel-isc.h
> > @@ -10,9 +10,6 @@
> >   */
> >  #ifndef _ATMEL_ISC_H_
> >
> > -#define ISC_MAX_SUPPORT_WIDTH   2592
> > -#define ISC_MAX_SUPPORT_HEIGHT  1944
> > -
> >  #define ISC_CLK_MAX_DIV		255
> >
> >  enum isc_clk_id {
> > @@ -191,6 +188,9 @@ struct isc_ctrls {
> >   * @gamma_table:	pointer to the table with gamma values, has
> >   *			gamma_max sets of GAMMA_ENTRIES entries each
> >   * @gamma_max:		maximum number of sets of inside the gamma_table
> > + *
> > + * @max_width:		maximum frame width, dependent on the internal RAM
> > + * @max_height:		maximum frame height, dependent on the internal RAM
> >   */
> >  struct isc_device {
> >  	struct regmap		*regmap;
> > @@ -254,6 +254,9 @@ struct isc_device {
> >  	/* pointer to the defined gamma table */
> >  	const u32	(*gamma_table)[GAMMA_ENTRIES];
> >  	u32		gamma_max;
> > +
> > +	u32		max_width;
> > +	u32		max_height;
> >  };
> >
> >  extern struct isc_format formats_list[];
> > diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> > index f45d8b96bfb8..f8d1c8ba99b3 100644
> > --- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> > +++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
> > @@ -49,8 +49,8 @@
> >  #include "atmel-isc-regs.h"
> >  #include "atmel-isc.h"
> >
> > -#define ISC_MAX_SUPPORT_WIDTH   2592
> > -#define ISC_MAX_SUPPORT_HEIGHT  1944
> > +#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
> > +#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
> >
> >  #define ISC_CLK_MAX_DIV		255
> >
> > @@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
> >  	isc->gamma_table = isc_sama5d2_gamma_table;
> >  	isc->gamma_max = 2;
> >
> > +	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
> > +	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
> > +
> >  	ret = isc_pipeline_init(isc);
> >  	if (ret)
> >  		return ret;
> > --
> > 2.25.1
> >


From billy_tsai at aspeedtech.com  Mon Apr 12 10:54:53 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Mon, 12 Apr 2021 17:54:53 +0800
Subject: [PATCH 0/4] Support pwm driver for aspeed ast26xx
Message-ID: <20210412095457.15095-1-billy_tsai@aspeedtech.com>

The legacy driver of aspeed pwm is binding with tach controller and it
doesn't follow the pwm framworks usage. In addition, the pwm register
usage of the 6th generation of ast26xx has drastic change. So these
patch serials add the new aspeed pwm driver to fix up the problem above.

Billy Tsai (4):
  dt-bindings: Add bindings for aspeed pwm-tach.
  dt-bindings: Add bindings for aspeed pwm
  pwm: Add Aspeed ast2600 PWM support
  pwm: Add support for aspeed pwm controller

 .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml |  52 ++++
 .../bindings/pwm/aspeed,ast2600-pwm.yaml      |  47 +++
 drivers/pwm/Kconfig                           |   6 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-aspeed-g6.c                   | 291 ++++++++++++++++++
 5 files changed, 397 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
 create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
 create mode 100644 drivers/pwm/pwm-aspeed-g6.c

-- 
2.25.1



From billy_tsai at aspeedtech.com  Mon Apr 12 10:54:54 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Mon, 12 Apr 2021 17:54:54 +0800
Subject: [PATCH 1/4] dt-bindings: Add bindings for aspeed pwm-tach.
In-Reply-To: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
Message-ID: <20210412095457.15095-2-billy_tsai@aspeedtech.com>

This patch adds device bindings for aspeed pwm-tach device which is a
multi-function device include pwn and tach function.

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
---
 .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml

diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
new file mode 100644
index 000000000000..73512ff71d23
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 ASPEED, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwn-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Tach controller Device Tree Bindings
+
+description: |
+  The PWM Tach controller is represented as a multi-function device which includes:
+    PWM
+    Tach
+
+maintainers:
+  - Billy Tsai <billy_tasi at aspeedtech.com>
+
+properties:
+  compatible:
+    - items:
+        - enum:
+            - aspeed,ast2600-pwn-tach
+        - const: syscon
+        - const: simple-mfd
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    pwm_tach: pwm_tach at 1e610000 {
+      compatible = "aspeed,ast2600-pwm-tach", "simple-mfd", "syscon";
+      #address-cells = <1>;
+      #size-cells = <1>;
+      reg = <0x1e610000 0x100>;
+
+      pwm: pwm at 0 {
+        compatible = "aspeed,ast2600-pwm";
+        #pwm-cells = <3>;
+        reg = <0x0 0x100>;
+      };
+
+      tach: tach at 0 {
+        compatible = "aspeed,ast2600-tach";
+        reg = <0x0 0x100>;
+      };
+    };
-- 
2.25.1



From billy_tsai at aspeedtech.com  Mon Apr 12 10:54:55 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Mon, 12 Apr 2021 17:54:55 +0800
Subject: [PATCH 2/4] dt-bindings: Add bindings for aspeed pwm
In-Reply-To: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
Message-ID: <20210412095457.15095-3-billy_tsai@aspeedtech.com>

This patch adds device bindings for aspeed pwm device which should be
the sub-node of aspeed,ast2600-pwm-tach.

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
---
 .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml

diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
new file mode 100644
index 000000000000..7a7ff0260d27
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 ASPEED, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 PWM controller
+
+maintainers:
+  - Billy Tsai <billy_tsai at aspeedtech.com>
+
+description: |
+  The ASPEED PWM controller can support upto 16 PWM outputs.
+
+properties:
+  compatible:
+    enum:
+      - aspeed,ast2600-pwm
+
+  "#pwm-cells":
+    const: 3
+
+pwm-cells:
+  - channel
+# period in terms of nanoseconds
+  - period
+# PWM_POLARITY_INVERTED
+  - flag
+
+additionalProperties: false
+
+examples:
+  - |
+    // The PWM should be a subnode of a "aspeed,ast2600-pwn-tach" compatible node.
+    pwm_tach at 1e610000 {
+      compatible = "aspeed,ast2600-pwm-tach", "simple-mfd", "syscon";
+      #address-cells = <1>;
+      #size-cells = <1>;
+      reg = <0x1e610000 0x100>;
+      ranges = <0 0x1e610000 0x100>;
+      pwm: pwm at 0 {
+        compatible = "aspeed,ast2600-pwm";
+        #pwm-cells = <3>;
+        reg = <0x0 0x100>;
+      };
+    };
-- 
2.25.1



From billy_tsai at aspeedtech.com  Mon Apr 12 10:54:57 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Mon, 12 Apr 2021 17:54:57 +0800
Subject: [PATCH 4/4] pwm: Add support for aspeed pwm controller
In-Reply-To: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
Message-ID: <20210412095457.15095-5-billy_tsai@aspeedtech.com>

Add support for the pwm controller which can be found at aspeed ast2600
soc. This driver is part function of multi-funciton of device "pwm-tach
controller".

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
---
 drivers/pwm/Kconfig  | 6 ++++++
 drivers/pwm/Makefile | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..947ed642debe 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -42,6 +42,12 @@ config PWM_DEBUG
 	  It is expected to introduce some runtime overhead and diagnostic
 	  output to the kernel log, so only enable while working on a driver.
 
+config PWM_ASPEED_G6
+	tristate "ASPEEDG6 PWM support"
+	help
+	  This driver provides support for ASPEED G6 PWM controllers.
+
+
 config PWM_AB8500
 	tristate "AB8500 PWM support"
 	depends on AB8500_CORE && ARCH_U8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index cbdcd55d69ee..4a74c68547bf 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_PWM)		+= core.o
 obj-$(CONFIG_PWM_SYSFS)		+= sysfs.o
+obj-$(CONFIG_PWM_ASPEED_G6)	+= pwm-aspeed-g6.o
 obj-$(CONFIG_PWM_AB8500)	+= pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)		+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)	+= pwm-atmel-hlcdc.o
-- 
2.25.1



From billy_tsai at aspeedtech.com  Mon Apr 12 10:54:56 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Mon, 12 Apr 2021 17:54:56 +0800
Subject: [PATCH 3/4] pwm: Add Aspeed ast2600 PWM support
In-Reply-To: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
Message-ID: <20210412095457.15095-4-billy_tsai@aspeedtech.com>

This patch add the support of PWM controller which can find at aspeed
ast2600 soc chip. This controller supoorts up to 16 channels.

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
---
 drivers/pwm/pwm-aspeed-g6.c | 291 ++++++++++++++++++++++++++++++++++++
 1 file changed, 291 insertions(+)
 create mode 100644 drivers/pwm/pwm-aspeed-g6.c

diff --git a/drivers/pwm/pwm-aspeed-g6.c b/drivers/pwm/pwm-aspeed-g6.c
new file mode 100644
index 000000000000..4bb4f97453c6
--- /dev/null
+++ b/drivers/pwm/pwm-aspeed-g6.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) ASPEED Technology 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 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+#include <linux/reset.h>
+#include <linux/regmap.h>
+#include <linux/pwm.h>
+/* The channel number of Aspeed pwm controller */
+#define ASPEED_NR_PWMS 16
+/* PWM Control Register */
+#define ASPEED_PWM_CTRL_CH(ch) ((ch * 0x10) + 0x00)
+#define PWM_LOAD_SEL_AS_WDT BIT(19)
+#define LOAD_SEL_FALLING 0
+#define LOAD_SEL_RIGING 1
+#define PWM_DUTY_LOAD_AS_WDT_EN BIT(18)
+#define PWM_DUTY_SYNC_DIS BIT(17)
+#define PWM_CLK_ENABLE BIT(16)
+#define PWM_LEVEL_OUTPUT BIT(15)
+#define PWM_INVERSE BIT(14)
+#define PWM_OPEN_DRAIN_EN BIT(13)
+#define PWM_PIN_EN BIT(12)
+#define PWM_CLK_DIV_H_SHIFT 8
+#define PWM_CLK_DIV_H_MASK (0xf << PWM_CLK_DIV_H_SHIFT)
+#define PWM_CLK_DIV_L_SHIFT 0
+#define PWM_CLK_DIV_L_MASK (0xff << PWM_CLK_DIV_L_SHIFT)
+/* PWM Duty Cycle Register */
+#define ASPEED_PWM_DUTY_CYCLE_CH(ch) ((ch * 0x10) + 0x04)
+#define PWM_PERIOD_SHIFT (24)
+#define PWM_PERIOD_MASK (0xff << PWM_PERIOD_SHIFT)
+#define PWM_POINT_AS_WDT_SHIFT (16)
+#define PWM_POINT_AS_WDT_MASK (0xff << PWM_POINT_AS_WDT_SHIFT)
+#define PWM_FALLING_POINT_SHIFT (8)
+#define PWM_FALLING_POINT_MASK (0xffff << PWM_FALLING_POINT_SHIFT)
+#define PWM_RISING_POINT_SHIFT (0)
+#define PWM_RISING_POINT_MASK (0xffff << PWM_RISING_POINT_SHIFT)
+/* PWM default value */
+#define DEFAULT_PWM_PERIOD 0xff
+#define DEFAULT_TARGET_PWM_FREQ 25000
+#define DEFAULT_DUTY_PT 10
+#define DEFAULT_WDT_RELOAD_DUTY_PT 16
+
+struct aspeed_pwm_data {
+	struct pwm_chip chip;
+	struct regmap *regmap;
+	unsigned long clk_freq;
+	struct reset_control *reset;
+};
+/**
+ * struct aspeed_pwm - per-PWM driver data
+ * @freq: cached pwm freq
+ */
+struct aspeed_pwm {
+	u32 freq;
+};
+
+static void aspeed_set_pwm_channel_enable(struct regmap *regmap, u8 pwm_channel,
+					  bool enable)
+{
+	regmap_update_bits(regmap, ASPEED_PWM_CTRL_CH(pwm_channel),
+			   (PWM_CLK_ENABLE | PWM_PIN_EN),
+			   enable ? (PWM_CLK_ENABLE | PWM_PIN_EN) : 0);
+}
+/*
+ * The PWM frequency = HCLK(200Mhz) / (clock division L bit *
+ * clock division H bit * (period bit + 1))
+ */
+static void aspeed_set_pwm_freq(struct aspeed_pwm_data *priv,
+				struct pwm_device *pwm, u32 freq)
+{
+	u32 target_div, cal_freq;
+	u32 tmp_div_h, tmp_div_l, diff, min_diff = INT_MAX;
+	u32 div_h = BIT(5) - 1, div_l = BIT(8) - 1;
+	u8 div_found;
+	u32 index = pwm->hwpwm;
+	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
+
+	cal_freq = priv->clk_freq / (DEFAULT_PWM_PERIOD + 1);
+	target_div = DIV_ROUND_UP(cal_freq, freq);
+	div_found = 0;
+	/* calculate for target frequence */
+	for (tmp_div_h = 0; tmp_div_h < 0x10; tmp_div_h++) {
+		tmp_div_l = target_div / BIT(tmp_div_h) - 1;
+
+		if (tmp_div_l < 0 || tmp_div_l > 255)
+			continue;
+
+		diff = freq - cal_freq / (BIT(tmp_div_h) * (tmp_div_l + 1));
+		if (abs(diff) < abs(min_diff)) {
+			min_diff = diff;
+			div_l = tmp_div_l;
+			div_h = tmp_div_h;
+			div_found = 1;
+			if (diff == 0)
+				break;
+		}
+	}
+	if (div_found == 0) {
+		pr_debug("target freq: %d too slow set minimal frequency\n",
+			 freq);
+	}
+	channel->freq = cal_freq / (BIT(div_h) * (div_l + 1));
+	pr_debug("div h %x, l : %x pwm out clk %d\n", div_h, div_l,
+		 channel->freq);
+	pr_debug("hclk %ld, target pwm freq %d, real pwm freq %d\n",
+		 priv->clk_freq, freq, channel->freq);
+
+	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index),
+			   (PWM_CLK_DIV_H_MASK | PWM_CLK_DIV_L_MASK),
+			   (div_h << PWM_CLK_DIV_H_SHIFT) |
+				   (div_l << PWM_CLK_DIV_L_SHIFT));
+}
+
+static void aspeed_set_pwm_duty(struct aspeed_pwm_data *priv,
+				struct pwm_device *pwm, u32 duty_pt)
+{
+	u32 index = pwm->hwpwm;
+
+	if (duty_pt == 0) {
+		aspeed_set_pwm_channel_enable(priv->regmap, index, false);
+	} else {
+		regmap_update_bits(priv->regmap,
+				   ASPEED_PWM_DUTY_CYCLE_CH(index),
+				   PWM_FALLING_POINT_MASK,
+				   duty_pt << PWM_FALLING_POINT_SHIFT);
+		aspeed_set_pwm_channel_enable(priv->regmap, index, true);
+	}
+}
+
+static void aspeed_set_pwm_polarity(struct aspeed_pwm_data *priv,
+				    struct pwm_device *pwm, u8 polarity)
+{
+	u32 index = pwm->hwpwm;
+
+	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index), PWM_INVERSE,
+			   (polarity) ? PWM_INVERSE : 0);
+}
+
+static int aspeed_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct device *dev = chip->dev;
+	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
+	struct aspeed_pwm *channel;
+	u32 index = pwm->hwpwm;
+	/*
+	 * Fixed the period to the max value and rising point to 0
+	 * for high resolution and simplified frequency calculation.
+	 */
+	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
+			   PWM_PERIOD_MASK,
+			   DEFAULT_PWM_PERIOD << PWM_PERIOD_SHIFT);
+
+	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
+			   PWM_RISING_POINT_MASK, 0);
+
+	channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
+	if (!channel)
+		return -ENOMEM;
+
+	pwm_set_chip_data(pwm, channel);
+
+	return 0;
+}
+
+static void aspeed_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct device *dev = chip->dev;
+	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
+
+	devm_kfree(dev, channel);
+}
+
+static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			    const struct pwm_state *state)
+{
+	struct device *dev = chip->dev;
+	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
+	struct pwm_state *cur_state = &pwm->state;
+	u32 freq = DIV_ROUND_UP_ULL(1000000000, state->period);
+	u32 duty_pt = DIV_ROUND_UP_ULL(
+		state->duty_cycle * (DEFAULT_PWM_PERIOD + 1), state->period);
+	dev_dbg(dev, "freq: %d, duty_pt: %d", freq, duty_pt);
+	if (state->enabled) {
+		aspeed_set_pwm_freq(priv, pwm, freq);
+		aspeed_set_pwm_duty(priv, pwm, duty_pt);
+		aspeed_set_pwm_polarity(priv, pwm, state->polarity);
+	} else {
+		aspeed_set_pwm_duty(priv, pwm, 0);
+	}
+	cur_state->period = state->period;
+	cur_state->duty_cycle = state->duty_cycle;
+	cur_state->polarity = state->polarity;
+	cur_state->enabled = state->enabled;
+
+	return 0;
+}
+static const struct pwm_ops aspeed_pwm_ops = {
+	.request = aspeed_pwm_request,
+	.free = aspeed_pwm_free,
+	.apply = aspeed_pwm_apply,
+	.owner = THIS_MODULE,
+};
+
+static int aspeed_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct clk *clk;
+	int ret;
+	struct aspeed_pwm_data *priv;
+	struct device_node *np;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	np = pdev->dev.parent->of_node;
+	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach")) {
+		dev_err(dev, "unsupported pwm device binding\n");
+		return -ENODEV;
+	}
+
+	priv->regmap = syscon_node_to_regmap(np);
+	if (IS_ERR(priv->regmap)) {
+		dev_err(dev, "Couldn't get regmap\n");
+		return -ENODEV;
+	}
+
+	clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(clk))
+		return -ENODEV;
+	priv->clk_freq = clk_get_rate(clk);
+
+	priv->reset = reset_control_get_shared(&pdev->dev, NULL);
+	if (IS_ERR(priv->reset)) {
+		dev_err(&pdev->dev, "can't get aspeed_pwm_tacho reset\n");
+		return PTR_ERR(priv->reset);
+	}
+	reset_control_deassert(priv->reset);
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &aspeed_pwm_ops;
+	priv->chip.base = -1;
+	priv->chip.npwm = ASPEED_NR_PWMS;
+	priv->chip.of_xlate = of_pwm_xlate_with_flags;
+	priv->chip.of_pwm_n_cells = 3;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
+		return ret;
+	}
+	dev_set_drvdata(dev, priv);
+	return ret;
+}
+
+static const struct of_device_id of_pwm_match_table[] = {
+	{
+		.compatible = "aspeed,ast2600-pwm",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_match_table);
+
+static struct platform_driver aspeed_pwm_driver = {
+	.probe		= aspeed_pwm_probe,
+	.driver		= {
+		.name	= "aspeed_pwm",
+		.of_match_table = of_pwm_match_table,
+	},
+};
+
+module_platform_driver(aspeed_pwm_driver);
+
+MODULE_AUTHOR("Billy Tsai <billy_tsai at aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED PWM device driver");
+MODULE_LICENSE("GPL v2");
-- 
2.25.1



From arnd at arndb.de  Mon Apr 12 10:55:41 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 12 Apr 2021 11:55:41 +0200
Subject: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64
 define
In-Reply-To: <20210412085545.2595431-2-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-2-hch@lst.de>
Message-ID: <CAK8P3a2MSJarPMfJ8RrSKDMXte3KQec=+GQ-LzV6HB7-Nm1FcQ@mail.gmail.com>

On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch at lst.de> wrote:
>
> Signed-off-by: Christoph Hellwig <hch at lst.de>

The patch looks good, but I'd like to see a description for each one.
How about:

| The check was added when Stephen Rothwell created the file, but
| no architecture ever defined it.

        Arnd


From jacopo at jmondi.org  Mon Apr 12 10:57:14 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 11:57:14 +0200
Subject: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc
 binding
In-Reply-To: <20210405155105.162529-29-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-29-eugen.hristev@microchip.com>
Message-ID: <20210412095714.uivebcatgazzq5ae@uno.localdomain>

Hi Eugene,

On Mon, Apr 05, 2021 at 06:51:03PM +0300, Eugen Hristev wrote:
> Add bindings for the microchip xisc, a driver based on atmel-isc.
> It shares common code with atmel-isc, but the xisc is the next generation
> ISC which is present on sama7g5 product.
> It has an enhanced pipeline, additional modules, formats, and it supports
> not only parallel sensors, but also serial sensors, by connecting to a demux
> endpoint present on sama7g5.
> One of the key points for creating a new binding is the clocking scheme, as
> atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
> input clock.
>
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>
> Hello Rob, all,
>
> I did not convert this yet to yaml because I would like first your feedback
> if the binding is good.
> If it's fine I will convert both this new binding and the old atmel-isc
> to yaml.
>
> Thanks for your feedback,
> Eugen
>
>  .../bindings/media/microchip-xisc.txt         | 64 +++++++++++++++++++
>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
>
> diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt b/Documentation/devicetree/bindings/media/microchip-xisc.txt
> new file mode 100644
> index 000000000000..080a357ed84d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
> @@ -0,0 +1,64 @@
> +Microchip eXtended Image Sensor Controller (XISC)
> +----------------------------------------------
> +
> +Required properties for XISC:
> +- compatible
> +	Must be "microchip,sama7g5-xisc".
> +- reg
> +	Physical base address and length of the registers set for the device.
> +- interrupts
> +	Should contain IRQ line for the XISC.
> +- clocks
> +	List of clock specifiers, corresponding to entries in
> +	the clock-names property;
> +	Please refer to clock-bindings.txt.
> +- clock-names
> +	Required elements: "hclock".
> +	This is the clock that clocks the sensor controller, and is usually
> +	fed from the clock tree. It is used for the internal controller logic.
> +- #clock-cells
> +	Should be 0.
> +- clock-output-names
> +	Should be "isc-mck".
> +- pinctrl-names, pinctrl-0
> +	Please refer to pinctrl-bindings.txt.
> +
> +Optional properties for XISC:
> +- microchip,mipi-mode;
> +	As the XISC is usually connected to a demux/bridge, the XISC receives
> +	the same type of input, however, it should be aware of the type of
> +	signals received. The mipi-mode enables different internal handling
> +	of the data and clock lines.

What does 'mipi-mode' do to a component that has an parallel receiver ?

> +
> +XISC supports a single port node with internal parallel bus.
> +It should contain one 'port' child node with child 'endpoint' node.
> +Please refer to the bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +This endpoint has to be connected to a bridge that acts as a demux from either
> +a serial interface or acts as a simple direct bridge to a parallel sensor.
> +
> +Example:
> +xisc: xisc at e1408000 {
> +	compatible = "microchip,sama7g5-isc";
> +	reg = <0xe1408000 0x2000>;
> +	interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
> +	clock-names = "hclock";
> +	#clock-cells = <0>;
> +	clock-output-names = "isc-mck";
> +	microchip,mipi-mode;
> +
> +	port at 1 {
> +		reg = <1>;
> +		xisc_in: endpoint {
> +		bus-width = <12>;
> +		hsync-active = <1>;
> +		vsync-active = <1>;
> +		remote-endpoint = <&csi2dc_out>;
nit: indentation

Have you consided using bus-type property ? As that's a new binding I
would consider making it mandatory, and to modify the DT parsinga
routine accordingly to remove auto-guessing, which according to my
understanding is almost 'deprecated' ?

> +		};
> +	};
> +};
> +
> --
> 2.25.1
>


From jbx6244 at gmail.com  Mon Apr 12 11:03:26 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 12:03:26 +0200
Subject: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties
 from pwm nodes rv1108.dtsi
In-Reply-To: <CAGb2v67s7a4GARfAnROKS40kaYQpdW_qWX=HX6GU09jV9wrbXw@mail.gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-3-jbx6244@gmail.com>
 <CAGb2v67s7a4GARfAnROKS40kaYQpdW_qWX=HX6GU09jV9wrbXw@mail.gmail.com>
Message-ID: <31b5ff50-afe5-b446-7d3c-943d148814d8@gmail.com>

On 4/12/21 5:15 AM, Chen-Yu Tsai wrote:
> On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>>
>> A test with the command below gives this error:
>>
>> /arch/arm/boot/dts/rv1108-evb.dt.yaml:
>> pwm at 10280000: 'interrupts' does not match any of the regexes:
>> 'pinctrl-[0-9]+'
>>
>> "interrupts" is an undocumented property, so remove them
>> from pwm nodes in rv1108.dtsi.
>>
>> make ARCH=arm dtbs_check
>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> 
> Given that the interrupts were specified, meaning they are wired up in hardware,
> shouldn't the solution be to add the interrupts property to the binding instead?
> 
> After all, the device tree describes the actual hardware, not just what the
> implementations need.
> 
> ChenYu
> 

Hi,

The question of what to do with it was asked in version 1, but no answer
was given, so I made a proposal.
The device tree description should be complete, but also as lean as
possible. If someone manages to sneak in undocumented properties without
reason then the ultimate consequence should be removal I think.

Not sure about the (missing?) rv1108 TRM, but for rk3328 the interrupt
is used for:

PWM_INTSTS 0x0040 W 0x00000000 Interrupt Status Register
  Channel Interrupt Polarity Flag
    This bit is used in capture mode in order to identify the
    transition of the input waveform when interrupt is generated.
  Channel Interrupt Status
    Interrupt generated

PWM_INT_EN 0x0044 W 0x00000000 Interrupt Enable Register
  Channel Interrupt Enable

Is there any current realistic use/setup for it to convince rob+dt this
should be added to pwm-rockchip.yaml?

The rk3328 interrupt rkpwm_int seems shared between channels, but only
included to pwm3. What is the proper way for that?

Johan


From arnd at arndb.de  Mon Apr 12 11:03:40 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 12 Apr 2021 12:03:40 +0200
Subject: consolidate the flock uapi definitions
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <CAK8P3a38qgkjkh4+fDKp4TufL+2_W-quZBFK9pJFf7wXP=84xQ@mail.gmail.com>

On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch at lst.de> wrote:
>
> Hi all,
>
> currently we deal with the slight differents in the various architecture
> variants of the flock and flock64 stuctures in a very cruft way.  This
> series switches to just use small arch hooks and define the rest in
> asm-generic and linux/compat.h instead.

Nice cleanup. I can merge it through the asm-generic tree if you like,
though it's a little late just ahead of the merge window.

I would not want to change the compat_loff_t definition to compat_s64
to avoid the padding at this time, though that might be a useful cleanup
for a future cycle.

        Arnd


From Eugen.Hristev at microchip.com  Mon Apr 12 11:04:14 2021
From: Eugen.Hristev at microchip.com (Eugen.Hristev at microchip.com)
Date: Mon, 12 Apr 2021 10:04:14 +0000
Subject: [PATCH v2 04/30] media: atmel: atmel-isc: specialize max width
 and max height
In-Reply-To: <20210412095336.vljygvokqq56kb6n@uno.localdomain>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-5-eugen.hristev@microchip.com>
 <20210412094312.tsghnyhglxf3roiy@uno.localdomain>
 <20210412095336.vljygvokqq56kb6n@uno.localdomain>
Message-ID: <f6e42811-7b72-ce12-98b5-2f48fe5fb8d0@microchip.com>

On 4/12/21 12:53 PM, Jacopo Mondi wrote:
> Ups,
> 
> On Mon, Apr 12, 2021 at 11:43:12AM +0200, Jacopo Mondi wrote:
>> Hi Eugene,
>>
>> On Mon, Apr 05, 2021 at 06:50:39PM +0300, Eugen Hristev wrote:
>>> Move the max width and max height constants to the product specific driver
>>> and have them in the device struct.
>>>
>>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>>> ---
>>>   drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
>>>   drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
>>>   .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
>>>   3 files changed, 25 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
>>> index 45fc8dbb7943..350076dd029a 100644
>>> --- a/drivers/media/platform/atmel/atmel-isc-base.c
>>> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
>>> @@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
>>>       * just use the maximum ISC can receive.
>>>       */
>>>      if (ret) {
>>> -           pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
>>> -           pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
>>> +           pad_cfg->try_crop.width = isc->max_width;
>>> +           pad_cfg->try_crop.height = isc->max_height;
>>>      } else {
>>>              pad_cfg->try_crop.width = fse.max_width;
>>>              pad_cfg->try_crop.height = fse.max_height;
>>> @@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
>>>      isc->try_config.sd_format = sd_fmt;
>>>
>>>      /* Limit to Atmel ISC hardware capabilities */
>>> -   if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> -           pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> -   if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> -           pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> +   if (pixfmt->width > isc->max_width)
>>> +           pixfmt->width = isc->max_width;
>>> +   if (pixfmt->height > isc->max_height)
>>> +           pixfmt->height = isc->max_height;
>>>
>>>      /*
>>>       * The mbus format is the one the subdev outputs.
>>> @@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
>>>      v4l2_fill_pix_format(pixfmt, &format.format);
>>>
>>>      /* Limit to Atmel ISC hardware capabilities */
>>> -   if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> -           pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> -   if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> -           pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> +   if (pixfmt->width > isc->max_width)
>>> +           pixfmt->width = isc->max_width;
>>> +   if (pixfmt->height > isc->max_height)
>>> +           pixfmt->height = isc->max_height;
>>
>> What happens if the sensor sends a frame larger that the ISC max
>> supported sizes ?
>>
> 
> I meant to ask this question on the previous patch :/

Hi Jacopo,

The ISC has a feature in the PFE module (parallel front end), the first 
pixel capturing module, which will automatically crop the frame at the 
maximum size (or configured frame size).

here is the commit that implements this safety mechanism :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=253ccf34232ae3b47497e5e55aef3ac48821425c

Eugen

> 
>>>
>>>      pixfmt->field = V4L2_FIELD_NONE;
>>>      pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
>>> @@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
>>>              return ret;
>>>
>>>      /* Limit to Atmel ISC hardware capabilities */
>>> -   if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
>>> -           pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
>>> -   if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
>>> -           pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
>>> +   if (f->fmt.pix.width > isc->max_width)
>>> +           f->fmt.pix.width = isc->max_width;
>>> +   if (f->fmt.pix.height > isc->max_height)
>>> +           f->fmt.pix.height = isc->max_height;
>>>
>>>      isc->fmt = *f;
>>>
>>> diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
>>> index 8d81d9967ad2..6becc6c3aaf0 100644
>>> --- a/drivers/media/platform/atmel/atmel-isc.h
>>> +++ b/drivers/media/platform/atmel/atmel-isc.h
>>> @@ -10,9 +10,6 @@
>>>    */
>>>   #ifndef _ATMEL_ISC_H_
>>>
>>> -#define ISC_MAX_SUPPORT_WIDTH   2592
>>> -#define ISC_MAX_SUPPORT_HEIGHT  1944
>>> -
>>>   #define ISC_CLK_MAX_DIV            255
>>>
>>>   enum isc_clk_id {
>>> @@ -191,6 +188,9 @@ struct isc_ctrls {
>>>    * @gamma_table:   pointer to the table with gamma values, has
>>>    *                 gamma_max sets of GAMMA_ENTRIES entries each
>>>    * @gamma_max:             maximum number of sets of inside the gamma_table
>>> + *
>>> + * @max_width:             maximum frame width, dependent on the internal RAM
>>> + * @max_height:            maximum frame height, dependent on the internal RAM
>>>    */
>>>   struct isc_device {
>>>      struct regmap           *regmap;
>>> @@ -254,6 +254,9 @@ struct isc_device {
>>>      /* pointer to the defined gamma table */
>>>      const u32       (*gamma_table)[GAMMA_ENTRIES];
>>>      u32             gamma_max;
>>> +
>>> +   u32             max_width;
>>> +   u32             max_height;
>>>   };
>>>
>>>   extern struct isc_format formats_list[];
>>> diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
>>> index f45d8b96bfb8..f8d1c8ba99b3 100644
>>> --- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
>>> +++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
>>> @@ -49,8 +49,8 @@
>>>   #include "atmel-isc-regs.h"
>>>   #include "atmel-isc.h"
>>>
>>> -#define ISC_MAX_SUPPORT_WIDTH   2592
>>> -#define ISC_MAX_SUPPORT_HEIGHT  1944
>>> +#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
>>> +#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
>>>
>>>   #define ISC_CLK_MAX_DIV            255
>>>
>>> @@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
>>>      isc->gamma_table = isc_sama5d2_gamma_table;
>>>      isc->gamma_max = 2;
>>>
>>> +   isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
>>> +   isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
>>> +
>>>      ret = isc_pipeline_init(isc);
>>>      if (ret)
>>>              return ret;
>>> --
>>> 2.25.1
>>>


From Eugen.Hristev at microchip.com  Mon Apr 12 11:12:22 2021
From: Eugen.Hristev at microchip.com (Eugen.Hristev at microchip.com)
Date: Mon, 12 Apr 2021 10:12:22 +0000
Subject: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc
 binding
In-Reply-To: <20210412095714.uivebcatgazzq5ae@uno.localdomain>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-29-eugen.hristev@microchip.com>
 <20210412095714.uivebcatgazzq5ae@uno.localdomain>
Message-ID: <7269db4c-bc76-58e4-4423-7be9f0369d5c@microchip.com>

On 4/12/21 12:57 PM, Jacopo Mondi wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Eugene,
> 
> On Mon, Apr 05, 2021 at 06:51:03PM +0300, Eugen Hristev wrote:
>> Add bindings for the microchip xisc, a driver based on atmel-isc.
>> It shares common code with atmel-isc, but the xisc is the next generation
>> ISC which is present on sama7g5 product.
>> It has an enhanced pipeline, additional modules, formats, and it supports
>> not only parallel sensors, but also serial sensors, by connecting to a demux
>> endpoint present on sama7g5.
>> One of the key points for creating a new binding is the clocking scheme, as
>> atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
>> input clock.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
>> ---
>>
>> Hello Rob, all,
>>
>> I did not convert this yet to yaml because I would like first your feedback
>> if the binding is good.
>> If it's fine I will convert both this new binding and the old atmel-isc
>> to yaml.
>>
>> Thanks for your feedback,
>> Eugen
>>
>>   .../bindings/media/microchip-xisc.txt         | 64 +++++++++++++++++++
>>   1 file changed, 64 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt b/Documentation/devicetree/bindings/media/microchip-xisc.txt
>> new file mode 100644
>> index 000000000000..080a357ed84d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
>> @@ -0,0 +1,64 @@
>> +Microchip eXtended Image Sensor Controller (XISC)
>> +----------------------------------------------
>> +
>> +Required properties for XISC:
>> +- compatible
>> +     Must be "microchip,sama7g5-xisc".
>> +- reg
>> +     Physical base address and length of the registers set for the device.
>> +- interrupts
>> +     Should contain IRQ line for the XISC.
>> +- clocks
>> +     List of clock specifiers, corresponding to entries in
>> +     the clock-names property;
>> +     Please refer to clock-bindings.txt.
>> +- clock-names
>> +     Required elements: "hclock".
>> +     This is the clock that clocks the sensor controller, and is usually
>> +     fed from the clock tree. It is used for the internal controller logic.
>> +- #clock-cells
>> +     Should be 0.
>> +- clock-output-names
>> +     Should be "isc-mck".
>> +- pinctrl-names, pinctrl-0
>> +     Please refer to pinctrl-bindings.txt.
>> +
>> +Optional properties for XISC:
>> +- microchip,mipi-mode;
>> +     As the XISC is usually connected to a demux/bridge, the XISC receives
>> +     the same type of input, however, it should be aware of the type of
>> +     signals received. The mipi-mode enables different internal handling
>> +     of the data and clock lines.
> 
> What does 'mipi-mode' do to a component that has an parallel receiver ?

Actually, this indeed has a parallel receiver, but it's only inside the 
SoC. The other end of the parallel connection is a demuxer/bridge. This 
demuxer will take the input from either a real parallel sensor or a CSI2 
stream.
Even if the pixels are then converted into a parallel stream, it looks 
like the pixel data has a bit of different constrains in term of hold 
and setup time, and other electrical characteristics inside the SoC.
The XISC hardware designer decided to leave a bit in the user interface 
called 'mipi-mode' , and by setting this, the capture interface of the 
XISC is better adapted to a demuxed stream from a CSI2, rather than 
adapted to a stream coming from a parallel sensor directly.

I am not sure I explained it right, but this is what I understand, when 
I asked the hardware design about it.

So we have to manually set this bit if we have the demuxer deserializing 
the CSI2 pixels or they are connected to a parallel sensor.
The XISC has no way of telling which is the correct setup, and from the 
demuxer perspective, things are the same.

The endpoint connection between the xisc and the demuxer looks to be the 
same, looking as if there is a parallel connection.
To know more, the XISC would be needing to look further down the 
pipeline, and this is something which I could not force it to do.


> 
>> +
>> +XISC supports a single port node with internal parallel bus.
>> +It should contain one 'port' child node with child 'endpoint' node.
>> +Please refer to the bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +This endpoint has to be connected to a bridge that acts as a demux from either
>> +a serial interface or acts as a simple direct bridge to a parallel sensor.
>> +
>> +Example:
>> +xisc: xisc at e1408000 {
>> +     compatible = "microchip,sama7g5-isc";
>> +     reg = <0xe1408000 0x2000>;
>> +     interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
>> +     #address-cells = <1>;
>> +     #size-cells = <0>;
>> +     clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
>> +     clock-names = "hclock";
>> +     #clock-cells = <0>;
>> +     clock-output-names = "isc-mck";
>> +     microchip,mipi-mode;
>> +
>> +     port at 1 {
>> +             reg = <1>;
>> +             xisc_in: endpoint {
>> +             bus-width = <12>;
>> +             hsync-active = <1>;
>> +             vsync-active = <1>;
>> +             remote-endpoint = <&csi2dc_out>;
> nit: indentation
> 
> Have you consided using bus-type property ? As that's a new binding I
> would consider making it mandatory, and to modify the DT parsinga
> routine accordingly to remove auto-guessing, which according to my
> understanding is almost 'deprecated' ?

Having bus-type would just be an useful addition for finding out the bus 
interface ? or it has some other consequences as well ?
Current XISC code actually expects a parallel interface, so it's kind of 
set already, having a bus-type would not bring any new information from 
a driver perspective

> 
>> +             };
>> +     };
>> +};
>> +
>> --
>> 2.25.1
>>


From maz at kernel.org  Mon Apr 12 11:12:51 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 11:12:51 +0100
Subject: [PATCH v2 03/10] KVM: arm64: Convert to the gfn-based MMU
 notifier callbacks
In-Reply-To: <20210402005658.3024832-4-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-4-seanjc@google.com>
Message-ID: <87eeffolp8.wl-maz@kernel.org>

On Fri, 02 Apr 2021 01:56:51 +0100,
Sean Christopherson <seanjc at google.com> wrote:
> 
> Move arm64 to the gfn-base MMU notifier APIs, which do the hva->gfn
> lookup in common code.
> 
> No meaningful functional change intended, though the exact order of
> operations is slightly different since the memslot lookups occur before
> calling into arch code.
> 
> Signed-off-by: Sean Christopherson <seanjc at google.com>

Reviewed-by: Marc Zyngier <maz at kernel.org>

	M.

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


From David.Laight at ACULAB.COM  Mon Apr 12 11:22:38 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 12 Apr 2021 10:22:38 +0000
Subject: consolidate the flock uapi definitions
In-Reply-To: <CAK8P3a38qgkjkh4+fDKp4TufL+2_W-quZBFK9pJFf7wXP=84xQ@mail.gmail.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <CAK8P3a38qgkjkh4+fDKp4TufL+2_W-quZBFK9pJFf7wXP=84xQ@mail.gmail.com>
Message-ID: <16c471554aa5424fbe2f6a4fd60bd662@AcuMS.aculab.com>

From: Arnd Bergmann
> Sent: 12 April 2021 11:04
> 
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch at lst.de> wrote:
> >
> > Hi all,
> >
> > currently we deal with the slight differents in the various architecture
> > variants of the flock and flock64 stuctures in a very cruft way.  This
> > series switches to just use small arch hooks and define the rest in
> > asm-generic and linux/compat.h instead.
> 
> Nice cleanup. I can merge it through the asm-generic tree if you like,
> though it's a little late just ahead of the merge window.
> 
> I would not want to change the compat_loff_t definition to compat_s64
> to avoid the padding at this time, though that might be a useful cleanup
> for a future cycle.

Is x86 the only architecture that has 32bit and 64bit variants where
the 32bit variant aligns 64bit items on 32bit boundaries?

I've just checked MIPS and ARM, and I'm fairly sure sparc 64bit
aligns them.

Are there any others?

Might also be interesting to check whether compat_loff_t gets
used anywhere else - where the x64-64 compat code will get it
wrong.

ISTM that fixing compat_loff_t shouldn't have any fallout.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From maz at kernel.org  Mon Apr 12 11:27:04 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 11:27:04 +0100
Subject: [PATCH v2 00/10] KVM: Consolidate and optimize MMU notifiers
In-Reply-To: <9376b453-be3a-f8b7-d53a-7e54c25161ce@redhat.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <9376b453-be3a-f8b7-d53a-7e54c25161ce@redhat.com>
Message-ID: <87czuzol1j.wl-maz@kernel.org>

On Fri, 02 Apr 2021 13:17:45 +0100,
Paolo Bonzini <pbonzini at redhat.com> wrote:
> 
> On 02/04/21 02:56, Sean Christopherson wrote:
> > The end goal of this series is to optimize the MMU notifiers to take
> > mmu_lock if and only if the notification is relevant to KVM, i.e. the hva
> > range overlaps a memslot.   Large VMs (hundreds of vCPUs) are very
> > sensitive to mmu_lock being taken for write at inopportune times, and
> > such VMs also tend to be "static", e.g. backed by HugeTLB with minimal
> > page shenanigans.  The vast majority of notifications for these VMs will
> > be spurious (for KVM), and eliding mmu_lock for spurious notifications
> > avoids an otherwise unacceptable disruption to the guest.
> > 
> > To get there without potentially degrading performance, e.g. due to
> > multiple memslot lookups, especially on non-x86 where the use cases are
> > largely unknown (from my perspective), first consolidate the MMU notifier
> > logic by moving the hva->gfn lookups into common KVM.
> > 
> > Based on kvm/queue, commit 5f986f748438 ("KVM: x86: dump_vmcs should
> > include the autoload/autostore MSR lists").
> > 
> > Well tested on Intel and AMD.  Compile tested for arm64, MIPS, PPC,
> > PPC e500, and s390.  Absolutely needs to be tested for real on non-x86,
> > I give it even odds that I introduced an off-by-one bug somewhere.
> > 
> > v2:
> >   - Drop the patches that have already been pushed to kvm/queue.
> >   - Drop two selftest changes that had snuck in via "git commit -a".
> >   - Add a patch to assert that mmu_notifier_count is elevated when
> >     .change_pte() runs. [Paolo]
> >   - Split out moving KVM_MMU_(UN)LOCK() to __kvm_handle_hva_range() to a
> >     separate patch.  Opted not to squash it with the introduction of the
> >     common hva walkers (patch 02), as that prevented sharing code between
> >     the old and new APIs. [Paolo]
> >   - Tweak the comment in kvm_vm_destroy() above the smashing of the new
> >     slots lock. [Paolo]
> >   - Make mmu_notifier_slots_lock unconditional to avoid #ifdefs. [Paolo]
> > 
> > v1:
> >   - https://lkml.kernel.org/r/20210326021957.1424875-1-seanjc at google.com
> > 
> > Sean Christopherson (10):
> >    KVM: Assert that notifier count is elevated in .change_pte()
> >    KVM: Move x86's MMU notifier memslot walkers to generic code
> >    KVM: arm64: Convert to the gfn-based MMU notifier callbacks
> >    KVM: MIPS/MMU: Convert to the gfn-based MMU notifier callbacks
> >    KVM: PPC: Convert to the gfn-based MMU notifier callbacks
> >    KVM: Kill off the old hva-based MMU notifier callbacks
> >    KVM: Move MMU notifier's mmu_lock acquisition into common helper
> >    KVM: Take mmu_lock when handling MMU notifier iff the hva hits a
> >      memslot
> >    KVM: Don't take mmu_lock for range invalidation unless necessary
> >    KVM: x86/mmu: Allow yielding during MMU notifier unmap/zap, if
> >      possible
> > 
> >   arch/arm64/kvm/mmu.c                   | 117 +++------
> >   arch/mips/kvm/mmu.c                    |  97 ++------
> >   arch/powerpc/include/asm/kvm_book3s.h  |  12 +-
> >   arch/powerpc/include/asm/kvm_ppc.h     |   9 +-
> >   arch/powerpc/kvm/book3s.c              |  18 +-
> >   arch/powerpc/kvm/book3s.h              |  10 +-
> >   arch/powerpc/kvm/book3s_64_mmu_hv.c    |  98 ++------
> >   arch/powerpc/kvm/book3s_64_mmu_radix.c |  25 +-
> >   arch/powerpc/kvm/book3s_hv.c           |  12 +-
> >   arch/powerpc/kvm/book3s_pr.c           |  56 ++---
> >   arch/powerpc/kvm/e500_mmu_host.c       |  27 +-
> >   arch/x86/kvm/mmu/mmu.c                 | 127 ++++------
> >   arch/x86/kvm/mmu/tdp_mmu.c             | 245 +++++++------------
> >   arch/x86/kvm/mmu/tdp_mmu.h             |  14 +-
> >   include/linux/kvm_host.h               |  22 +-
> >   virt/kvm/kvm_main.c                    | 325 +++++++++++++++++++------
> >   16 files changed, 552 insertions(+), 662 deletions(-)
> > 
> 
> For MIPS, I am going to post a series that simplifies TLB flushing
> further.  I applied it, and rebased this one on top, to
> kvm/mmu-notifier-queue.
> 
> Architecture maintainers, please look at the branch and
> review/test/ack your parts.

I've given this a reasonably good beating on arm64 for both VHE and
nVHE HW, and nothing caught fire, although I was left with a conflict
in the x86 code after merging with linux/master.

Feel free to add a

Tested-by: Marc Zyngier <maz at kernel.org>

for the arm64 side.

	M.

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


From suzuki.poulose at arm.com  Mon Apr 12 11:28:18 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 12 Apr 2021 11:28:18 +0100
Subject: [PATCH v6 07/10] coresight: etm4x: Add complex configuration
 handlers to etmv4
In-Reply-To: <20210409103722.26290-8-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
 <20210409103722.26290-8-mike.leach@linaro.org>
Message-ID: <97d53224-0749-086b-b2b4-12c91ec8ad5a@arm.com>

On 09/04/2021 11:37, Mike Leach wrote:
> Adds in handlers to allow the ETMv4 to use the complex configuration
> support. Features and configurations can be loaded and selected in the
> device.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> ---
>   drivers/hwtracing/coresight/Makefile          |   3 +-
>   .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
>   .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
>   .../coresight/coresight-etm4x-core.c          |  38 +++-
>   .../coresight/coresight-etm4x-sysfs.c         |   3 +
>   5 files changed, 238 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
>   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> 
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 63ecfc3cf66d..9420d33b23ac 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
>   coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
>   		     coresight-etm3x-sysfs.o
>   obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
> -coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
> +coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
> +			coresight-etm4x-cfg.o
>   obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>   obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>   obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> new file mode 100644
> index 000000000000..d2ea903231b2
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +

> +#include "coresight-etm4x.h"
> +#include "coresight-etm4x-cfg.h"
> +#include "coresight-priv.h"
> +#include "coresight-syscfg.h"
> +
> +/* defines to associate register IDs with driver data locations */
> +#define CHECKREG(cval, elem) \
> +	{ \
> +		if (offset == cval) { \
> +			reg_csdev->driver_regval = &drvcfg->elem; \
> +			err = 0; \
> +			break; \
> +		} \
> +	}
> +
> +#define CHECKREGIDX(cval, elem, off_idx, mask)	\
> +	{ \
> +		if (mask == cval) { \
> +			reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
> +			err = 0; \
> +			break; \
> +		} \
> +	}
> +
> +/**
> + * etm4_cfg_map_reg_offset - validate and map the register offset into a
> + *			     location in the driver config struct.
> + *
> + * Limits the number of registers that can be accessed and programmed in
> + * features, to those which are used to control the trace capture parameters.
> + *
> + * Omits or limits access to those which the driver must use exclusively.
> + *
> + * Invalid offsets will result in fail code return and feature load failure.
> + *
> + * @drvdata:	driver data to map into.
> + * @reg:	register to map.
> + * @offset:	device offset for the register
> + */
> +static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> +				   struct cscfg_regval_csdev *reg_csdev, u32 offset)
> +{
> +	int err = -EINVAL, idx;
> +	struct etmv4_config *drvcfg = &drvdata->config;
> +	u32 off_mask;
> +
> +	if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> +	    ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
> +	    ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
> +		do {
> +			CHECKREG(TRCEVENTCTL0R, eventctrl0);
> +			CHECKREG(TRCEVENTCTL1R, eventctrl1);
> +			CHECKREG(TRCSTALLCTLR, stall_ctrl);
> +			CHECKREG(TRCTSCTLR, ts_ctrl);
> +			CHECKREG(TRCSYNCPR, syncfreq);
> +			CHECKREG(TRCCCCTLR, ccctlr);
> +			CHECKREG(TRCBBCTLR, bb_ctrl);
> +			CHECKREG(TRCVICTLR, vinst_ctrl);
> +			CHECKREG(TRCVIIECTLR, viiectlr);
> +			CHECKREG(TRCVISSCTLR, vissctlr);
> +			CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
> +			CHECKREG(TRCSEQRSTEVR, seq_rst);
> +			CHECKREG(TRCSEQSTR, seq_state);
> +			CHECKREG(TRCEXTINSELR, ext_inp);
> +			CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
> +			CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
> +			CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
> +			CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
> +		} while (0);
> +	} else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
> +		/* sequencer state control registers */
> +		idx = (offset & GENMASK(3, 0)) / 4;
> +		if (idx < ETM_MAX_SEQ_STATES) {
> +			reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
> +			err = 0;
> +		}
> +	} else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
> +		/* 32 bit, 8 off indexed register sets */
> +		idx = (offset & GENMASK(4, 0)) / 4;
> +		off_mask =  (offset & GENMASK(11, 5));
> +		do {
> +			CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> +			CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> +			CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> +		/* 64 bit, 8 off indexed register sets */
> +		idx = (offset & GENMASK(5, 0)) / 8;
> +		off_mask = (offset & GENMASK(11, 6));
> +		do {
> +			CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
> +			CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCRSCTLRn(2)) &&
> +		   (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
> +		/* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
> +		idx = (offset & GENMASK(6, 0)) / 4;
> +		if (idx < ETM_MAX_RES_SEL) {
> +			reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
> +			err = 0;
> +		}
> +	} else if ((offset >= TRCACVRn(0)) &&
> +		   (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
> +		/* 64 bit addr cmp regs, 16 off */
> +		idx = (offset & GENMASK(6, 0)) / 8;
> +		off_mask = offset & GENMASK(11, 7);
> +		do {
> +			CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
> +			CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
> +		} while (0);
> +	} else if ((offset >= TRCCNTRLDVRn(0)) &&
> +		   (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
> +		/* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
> +		idx = (offset &  GENMASK(3, 0)) / 4;
> +		off_mask = offset &  GENMASK(11, 4);
> +		do {
> +			CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
> +			CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
> +			CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
> +		} while (0);
> +	}
> +	return err;
> +}
> +
> +/**
> + * etm4_cfg_load_feature - load a feature into a device instance.
> + *
> + * @csdev:	An ETMv4 CoreSight device.
> + * @feat:	The feature to be loaded.
> + *
> + * The function will load a feature instance into the device, checking that
> + * the register definitions are valid for the device.
> + *
> + * Parameter and register definitions will be converted into internal
> + * structures that are used to set the values in the driver when the
> + * feature is enabled for the device.
> + *
> + * The feature spinlock pointer is initialised to the same spinlock
> + * that the driver uses to protect the internal register values.
> + */
> +static int etm4_cfg_load_feature(struct coresight_device *csdev,
> +				 struct cscfg_feature_csdev *feat_csdev)
> +{
> +	struct device *dev = csdev->dev.parent;
> +	struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
> +	const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
> +	u32 offset;
> +	int i = 0, err = 0;
> +
> +	/*
> +	 * essential we set the device spinlock - this is used in the generic
> +	 * programming routines when copying values into the drvdata structures
> +	 * via the pointers setup in etm4_cfg_map_reg_offset().
> +	 */
> +	feat_csdev->drv_spinlock = &drvdata->spinlock;
> +
> +	/* process the register descriptions */
> +	for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
> +		offset = feat_desc->regs_desc[i].offset;
> +		err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
> +	}
> +	return err;
> +}
> +
> +/* match information when loading configurations */
> +#define CS_CFG_ETM4_MATCH_FLAGS	(CS_CFG_MATCH_CLASS_SRC_ALL | \
> +				 CS_CFG_MATCH_CLASS_SRC_ETM4)
> +
> +int etm4_cscfg_register(struct coresight_device *csdev)
> +{
> +	struct cscfg_csdev_feat_ops ops;
> +
> +	ops.load_feat = &etm4_cfg_load_feature;
> +
> +	return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> new file mode 100644
> index 000000000000..a204ad9a4792
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _CORESIGHT_ETM4X_CFG_H
> +#define _CORESIGHT_ETM4X_CFG_H


Looks like this must be guarded by the CONFIG_CORESIGHT_SOURCE_ETM4X to 
prevent the build failures on arm, as reported by the test robot.

#ifdef CONFIG_CORESIGHT_SOURCE_ETM4X

> +
> +#include "coresight-config.h"
> +#include "coresight-etm4x.h"
> +
> +/* ETMv4 specific config functions */
> +int etm4_cscfg_register(struct coresight_device *csdev);
> +

endif /* ETM4X */

Cheers
Suzuki



From wens at kernel.org  Mon Apr 12 11:33:03 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 12 Apr 2021 18:33:03 +0800
Subject: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties
 from pwm nodes rv1108.dtsi
In-Reply-To: <31b5ff50-afe5-b446-7d3c-943d148814d8@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-3-jbx6244@gmail.com>
 <CAGb2v67s7a4GARfAnROKS40kaYQpdW_qWX=HX6GU09jV9wrbXw@mail.gmail.com>
 <31b5ff50-afe5-b446-7d3c-943d148814d8@gmail.com>
Message-ID: <CAGb2v65+A402jCPVRJdDBdxqAEYOJmFTkKB4LJCvnW89hXb8QA@mail.gmail.com>

On Mon, Apr 12, 2021 at 6:03 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>
> On 4/12/21 5:15 AM, Chen-Yu Tsai wrote:
> > On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker <jbx6244 at gmail.com> wrote:
> >>
> >> A test with the command below gives this error:
> >>
> >> /arch/arm/boot/dts/rv1108-evb.dt.yaml:
> >> pwm at 10280000: 'interrupts' does not match any of the regexes:
> >> 'pinctrl-[0-9]+'
> >>
> >> "interrupts" is an undocumented property, so remove them
> >> from pwm nodes in rv1108.dtsi.
> >>
> >> make ARCH=arm dtbs_check
> >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> >>
> >> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> >
> > Given that the interrupts were specified, meaning they are wired up in hardware,
> > shouldn't the solution be to add the interrupts property to the binding instead?
> >
> > After all, the device tree describes the actual hardware, not just what the
> > implementations need.
> >
> > ChenYu
> >
>
> Hi,
>
> The question of what to do with it was asked in version 1, but no answer
> was given, so I made a proposal.
> The device tree description should be complete, but also as lean as
> possible. If someone manages to sneak in undocumented properties without
> reason then the ultimate consequence should be removal I think.
>
> Not sure about the (missing?) rv1108 TRM, but for rk3328 the interrupt
> is used for:
>
> PWM_INTSTS 0x0040 W 0x00000000 Interrupt Status Register
>   Channel Interrupt Polarity Flag
>     This bit is used in capture mode in order to identify the
>     transition of the input waveform when interrupt is generated.
>   Channel Interrupt Status
>     Interrupt generated
>
> PWM_INT_EN 0x0044 W 0x00000000 Interrupt Enable Register
>   Channel Interrupt Enable
>
> Is there any current realistic use/setup for it to convince rob+dt this
> should be added to pwm-rockchip.yaml?

Well, the PWM core has capture support, and pwm-sti implements it with
interrupt support, so I guess there's at least a legitimate case for
adding that to the binding. Whether someone has an actual use case for
it and adds code to implement it is another story.

> The rk3328 interrupt rkpwm_int seems shared between channels, but only
> included to pwm3. What is the proper way for that?

I guess the bigger question is why was the PWM controller split into
four device nodes, instead of just one encompassing the whole block.
Now we'd have to introduce a new binding to support capture mode and
interrupts.

In that case I agree with dropping the interrupts for now, as it just
won't fit. But I would add this additional information to the commit
message.


Regards
ChenYu


From jacopo at jmondi.org  Mon Apr 12 11:34:57 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 12:34:57 +0200
Subject: [PATCH v2 28/30] dt-bindings: media: atmel: add microchip-xisc
 binding
In-Reply-To: <7269db4c-bc76-58e4-4423-7be9f0369d5c@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-29-eugen.hristev@microchip.com>
 <20210412095714.uivebcatgazzq5ae@uno.localdomain>
 <7269db4c-bc76-58e4-4423-7be9f0369d5c@microchip.com>
Message-ID: <20210412103457.3ahntx5ngskgb57e@uno.localdomain>

Hi Eugene,

On Mon, Apr 12, 2021 at 10:12:22AM +0000, Eugen.Hristev at microchip.com wrote:
> On 4/12/21 12:57 PM, Jacopo Mondi wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Hi Eugene,
> >
> > On Mon, Apr 05, 2021 at 06:51:03PM +0300, Eugen Hristev wrote:
> >> Add bindings for the microchip xisc, a driver based on atmel-isc.
> >> It shares common code with atmel-isc, but the xisc is the next generation
> >> ISC which is present on sama7g5 product.
> >> It has an enhanced pipeline, additional modules, formats, and it supports
> >> not only parallel sensors, but also serial sensors, by connecting to a demux
> >> endpoint present on sama7g5.
> >> One of the key points for creating a new binding is the clocking scheme, as
> >> atmel-isc requires 3 mandatory clocks, the microchip-xisc requires a single
> >> input clock.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> >> ---
> >>
> >> Hello Rob, all,
> >>
> >> I did not convert this yet to yaml because I would like first your feedback
> >> if the binding is good.
> >> If it's fine I will convert both this new binding and the old atmel-isc
> >> to yaml.
> >>
> >> Thanks for your feedback,
> >> Eugen
> >>
> >>   .../bindings/media/microchip-xisc.txt         | 64 +++++++++++++++++++
> >>   1 file changed, 64 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/microchip-xisc.txt b/Documentation/devicetree/bindings/media/microchip-xisc.txt
> >> new file mode 100644
> >> index 000000000000..080a357ed84d
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/microchip-xisc.txt
> >> @@ -0,0 +1,64 @@
> >> +Microchip eXtended Image Sensor Controller (XISC)
> >> +----------------------------------------------
> >> +
> >> +Required properties for XISC:
> >> +- compatible
> >> +     Must be "microchip,sama7g5-xisc".
> >> +- reg
> >> +     Physical base address and length of the registers set for the device.
> >> +- interrupts
> >> +     Should contain IRQ line for the XISC.
> >> +- clocks
> >> +     List of clock specifiers, corresponding to entries in
> >> +     the clock-names property;
> >> +     Please refer to clock-bindings.txt.
> >> +- clock-names
> >> +     Required elements: "hclock".
> >> +     This is the clock that clocks the sensor controller, and is usually
> >> +     fed from the clock tree. It is used for the internal controller logic.
> >> +- #clock-cells
> >> +     Should be 0.
> >> +- clock-output-names
> >> +     Should be "isc-mck".
> >> +- pinctrl-names, pinctrl-0
> >> +     Please refer to pinctrl-bindings.txt.
> >> +
> >> +Optional properties for XISC:
> >> +- microchip,mipi-mode;
> >> +     As the XISC is usually connected to a demux/bridge, the XISC receives
> >> +     the same type of input, however, it should be aware of the type of
> >> +     signals received. The mipi-mode enables different internal handling
> >> +     of the data and clock lines.
> >
> > What does 'mipi-mode' do to a component that has an parallel receiver ?
>
> Actually, this indeed has a parallel receiver, but it's only inside the
> SoC. The other end of the parallel connection is a demuxer/bridge. This
> demuxer will take the input from either a real parallel sensor or a CSI2
> stream.
> Even if the pixels are then converted into a parallel stream, it looks
> like the pixel data has a bit of different constrains in term of hold
> and setup time, and other electrical characteristics inside the SoC.
> The XISC hardware designer decided to leave a bit in the user interface
> called 'mipi-mode' , and by setting this, the capture interface of the
> XISC is better adapted to a demuxed stream from a CSI2, rather than
> adapted to a stream coming from a parallel sensor directly.
>
> I am not sure I explained it right, but this is what I understand, when
> I asked the hardware design about it.
>
> So we have to manually set this bit if we have the demuxer deserializing
> the CSI2 pixels or they are connected to a parallel sensor.
> The XISC has no way of telling which is the correct setup, and from the
> demuxer perspective, things are the same.
>
> The endpoint connection between the xisc and the demuxer looks to be the
> same, looking as if there is a parallel connection.
> To know more, the XISC would be needing to look further down the
> pipeline, and this is something which I could not force it to do.

Thanks for the details. It would be interesting to know what changes
when the stream is received from the muxer, the parallel interface
timings should not affected, but I get there are not many ways around
this

>
>
> >
> >> +
> >> +XISC supports a single port node with internal parallel bus.
> >> +It should contain one 'port' child node with child 'endpoint' node.
> >> +Please refer to the bindings defined in
> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >> +
> >> +This endpoint has to be connected to a bridge that acts as a demux from either
> >> +a serial interface or acts as a simple direct bridge to a parallel sensor.
> >> +
> >> +Example:
> >> +xisc: xisc at e1408000 {
> >> +     compatible = "microchip,sama7g5-isc";
> >> +     reg = <0xe1408000 0x2000>;
> >> +     interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> >> +     #address-cells = <1>;
> >> +     #size-cells = <0>;
> >> +     clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
> >> +     clock-names = "hclock";
> >> +     #clock-cells = <0>;
> >> +     clock-output-names = "isc-mck";
> >> +     microchip,mipi-mode;
> >> +
> >> +     port at 1 {
> >> +             reg = <1>;
> >> +             xisc_in: endpoint {
> >> +             bus-width = <12>;
> >> +             hsync-active = <1>;
> >> +             vsync-active = <1>;
> >> +             remote-endpoint = <&csi2dc_out>;
> > nit: indentation
> >
> > Have you consided using bus-type property ? As that's a new binding I
> > would consider making it mandatory, and to modify the DT parsinga
> > routine accordingly to remove auto-guessing, which according to my
> > understanding is almost 'deprecated' ?
>
> Having bus-type would just be an useful addition for finding out the bus
> interface ? or it has some other consequences as well ?
> Current XISC code actually expects a parallel interface, so it's kind of
> set already, having a bus-type would not bring any new information from
> a driver perspective
>

Have I read the parsing routine wrong, as it seems BT.656 is also
supported. IF only parallel is, the dt parsing routine should set
bus_type to V4L2_MBUS_PARALLEL. Although there's still plenty of drivers
relying on auto-guessing, so I won't inist on this :)

Thanks
  j

> >
> >> +             };
> >> +     };
> >> +};
> >> +
> >> --
> >> 2.25.1
> >>
>


From David.Laight at ACULAB.COM  Mon Apr 12 11:53:24 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 12 Apr 2021 10:53:24 +0000
Subject: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
In-Reply-To: <15be19af19174c7692dd795297884096@AcuMS.aculab.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-6-hch@lst.de>
 <15be19af19174c7692dd795297884096@AcuMS.aculab.com>
Message-ID: <5c3635a2b44a496b88d665e8686d9436@AcuMS.aculab.com>

From: David Laight
> Sent: 12 April 2021 10:37
...
> I'm guessing that compat_pid_t is 16 bits?
> So the native 32bit version has an unnamed 2 byte structure pad.
> The 'packed' removes this pad from the compat structure.
> 
> AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
> adding an explicit pad for the implicit pad the compiler
> would generate because compat_pid_t is 16 bits.

I've just looked at the header.
compat_pid_t is 32 bits.
So Linux must have gained 32bit pids at some earlier time.
(Historically Unix pids were 16 bit - even on 32bit systems.)

Which makes the explicit pad in 'sparc' rather 'interesting'.

Actually the tail pad can just be removed from the compat
structures.
Just a comment that mips and sparc have extra fields
in the uapi header is enough.

The kernel never needs to read/write the pad.
userspace must provide the pad in case the kernel writes it.

oh - compat_loff_t is only used in a couple of other places.
neither care in any way about the alignment.
(Provided get_user() doesn't fault on a 8n+4 aligned address.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From jbx6244 at gmail.com  Mon Apr 12 12:04:59 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 13:04:59 +0200
Subject: [PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties
 from pwm nodes rv1108.dtsi
In-Reply-To: <CAGb2v65+A402jCPVRJdDBdxqAEYOJmFTkKB4LJCvnW89hXb8QA@mail.gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-3-jbx6244@gmail.com>
 <CAGb2v67s7a4GARfAnROKS40kaYQpdW_qWX=HX6GU09jV9wrbXw@mail.gmail.com>
 <31b5ff50-afe5-b446-7d3c-943d148814d8@gmail.com>
 <CAGb2v65+A402jCPVRJdDBdxqAEYOJmFTkKB4LJCvnW89hXb8QA@mail.gmail.com>
Message-ID: <20b7c702-9412-93b4-3174-e8633bc413d7@gmail.com>

On 4/12/21 12:33 PM, Chen-Yu Tsai wrote:
> On Mon, Apr 12, 2021 at 6:03 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>>
>> On 4/12/21 5:15 AM, Chen-Yu Tsai wrote:
>>> On Sun, Apr 11, 2021 at 9:11 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>>>>
>>>> A test with the command below gives this error:
>>>>
>>>> /arch/arm/boot/dts/rv1108-evb.dt.yaml:
>>>> pwm at 10280000: 'interrupts' does not match any of the regexes:
>>>> 'pinctrl-[0-9]+'
>>>>
>>>> "interrupts" is an undocumented property, so remove them
>>>> from pwm nodes in rv1108.dtsi.
>>>>
>>>> make ARCH=arm dtbs_check
>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
>>>>
>>>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>>>
>>> Given that the interrupts were specified, meaning they are wired up in hardware,
>>> shouldn't the solution be to add the interrupts property to the binding instead?
>>>
>>> After all, the device tree describes the actual hardware, not just what the
>>> implementations need.
>>>
>>> ChenYu
>>>
>>
>> Hi,
>>
>> The question of what to do with it was asked in version 1, but no answer
>> was given, so I made a proposal.
>> The device tree description should be complete, but also as lean as
>> possible. If someone manages to sneak in undocumented properties without
>> reason then the ultimate consequence should be removal I think.
>>
>> Not sure about the (missing?) rv1108 TRM, but for rk3328 the interrupt
>> is used for:
>>
>> PWM_INTSTS 0x0040 W 0x00000000 Interrupt Status Register
>>   Channel Interrupt Polarity Flag
>>     This bit is used in capture mode in order to identify the
>>     transition of the input waveform when interrupt is generated.
>>   Channel Interrupt Status
>>     Interrupt generated
>>
>> PWM_INT_EN 0x0044 W 0x00000000 Interrupt Enable Register
>>   Channel Interrupt Enable
>>
>> Is there any current realistic use/setup for it to convince rob+dt this
>> should be added to pwm-rockchip.yaml?

Found:
pwm3 combined with ir uses a irq. Keep that as it is for now.

https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/input/remotectl/rockchip_pwm_remotectl.c

> 
> Well, the PWM core has capture support, and pwm-sti implements it with
> interrupt support, so I guess there's at least a legitimate case for
> adding that to the binding. Whether someone has an actual use case for
> it and adds code to implement it is another story.
> 
>> The rk3328 interrupt rkpwm_int seems shared between channels, but only
>> included to pwm3. What is the proper way for that?
> 
> I guess the bigger question is why was the PWM controller split into
> four device nodes, instead of just one encompassing the whole block.
> Now we'd have to introduce a new binding to support capture mode and
> interrupts.
> 
> In that case I agree with dropping the interrupts for now, as it just
> won't fit. But I would add this additional information to the commit
> message.

Will wait with adding "interrupts" to pwm-rockchip.yaml till someone
makes a solution for the whole block. Convert only current
document/binding to reduce notifications.

For Heiko: patch 3 + 5 can go in the garbage bin:
[PATCH v2 3/6] ARM: dts: rockchip: remove interrupts properties from pwm
nodes rv1108.dtsi
[PATCH v2 5/6] arm64: dts: rockchip: remove interrupts properties from
pwm nodes rk3328.dtsi

Johan

> 
> 
> Regards
> ChenYu
> 



From arnd at arndb.de  Mon Apr 12 12:07:50 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 12 Apr 2021 13:07:50 +0200
Subject: consolidate the flock uapi definitions
In-Reply-To: <16c471554aa5424fbe2f6a4fd60bd662@AcuMS.aculab.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <CAK8P3a38qgkjkh4+fDKp4TufL+2_W-quZBFK9pJFf7wXP=84xQ@mail.gmail.com>
 <16c471554aa5424fbe2f6a4fd60bd662@AcuMS.aculab.com>
Message-ID: <CAK8P3a0MpbF=Zp8MtqaPYrLeLorh1TfVVtTPZ-ubxBy93CSOVA@mail.gmail.com>

On Mon, Apr 12, 2021 at 12:22 PM David Laight <David.Laight at aculab.com> wrote:
>
> From: Arnd Bergmann
> > Sent: 12 April 2021 11:04
> >
> > On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch at lst.de> wrote:
> > >
> > > Hi all,
> > >
> > > currently we deal with the slight differents in the various architecture
> > > variants of the flock and flock64 stuctures in a very cruft way.  This
> > > series switches to just use small arch hooks and define the rest in
> > > asm-generic and linux/compat.h instead.
> >
> > Nice cleanup. I can merge it through the asm-generic tree if you like,
> > though it's a little late just ahead of the merge window.
> >
> > I would not want to change the compat_loff_t definition to compat_s64
> > to avoid the padding at this time, though that might be a useful cleanup
> > for a future cycle.
>
> Is x86 the only architecture that has 32bit and 64bit variants where
> the 32bit variant aligns 64bit items on 32bit boundaries?

Yes.

> ISTM that fixing compat_loff_t shouldn't have any fallout.

That is my assumption as well, but I still wouldn't take the
risk one week before the merge window.

       Arnd


From qais.yousef at arm.com  Mon Apr 12 12:08:10 2021
From: qais.yousef at arm.com (Qais Yousef)
Date: Mon, 12 Apr 2021 12:08:10 +0100
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <be48adb2-c838-1a9b-37bc-da783f3d5dd3@nokia.com>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
 <20210409153309.wbebto3eufui35qs@e107158-lin>
 <be48adb2-c838-1a9b-37bc-da783f3d5dd3@nokia.com>
Message-ID: <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com>

Hi Alexander

Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in
your future postings.

On 04/12/21 08:28, Alexander Sverdlin wrote:
> Hi!
> 
> On 09/04/2021 17:33, Qais Yousef wrote:
> > I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't
> > work out for you? I struggle to see how this is better and why it was hard to
> > incorporate my suggestion.
> > 
> > For example
> > 
> > 	-       old = ftrace_call_replace(ip, adjust_address(rec, addr));
> > 	+#ifdef CONFIG_ARM_MODULE_PLTS
> > 	+       /* mod is only supplied during module loading */
> > 	+       if (!mod)
> > 	+               mod = rec->arch.mod;
> > 	+       else
> > 	+               rec->arch.mod = mod;
> > 	+#endif
> > 	+
> > 	+       old = ftrace_call_replace(ip, aaddr,
> > 	+                                 !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod);
> > 	+#ifdef CONFIG_ARM_MODULE_PLTS
> > 	+       if (!old && mod) {
> > 	+               aaddr = get_module_plt(mod, ip, aaddr);
> > 	+               old = ftrace_call_replace(ip, aaddr, true);
> > 	+       }
> > 	+#endif
> > 	+
> > 
> > There's an ifdef, followed by a code that embeds
> > !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/
> 
> No, it's actually two small ifdefed blocks added before and after an original call,
> which parameters have been modified as well. The issue with arch.mod was explained
> by Steven Rostedt, maybe you've missed his email.

If you're referring to arch.mod having to be protected by the ifdef I did
address that. Please look at my patch.

My comment here refers to the ugliness of this ifdefery. Introducing 2 simple
wrapper functions would address that as I've demonstrated in my
suggestion/patch.

Thanks

--
Qais Yousef


From u.kleine-koenig at pengutronix.de  Mon Apr 12 12:14:00 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 12 Apr 2021 13:14:00 +0200
Subject: [PATCH 4/4] pwm: Add support for aspeed pwm controller
In-Reply-To: <20210412095457.15095-5-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-5-billy_tsai@aspeedtech.com>
Message-ID: <20210412111400.w4yafy2r2lcy3qqv@pengutronix.de>

Hello,

On Mon, Apr 12, 2021 at 05:54:57PM +0800, Billy Tsai wrote:
> Add support for the pwm controller which can be found at aspeed ast2600
> soc. This driver is part function of multi-funciton of device "pwm-tach
> controller".

please squash this into patch 3.

> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> ---
>  drivers/pwm/Kconfig  | 6 ++++++
>  drivers/pwm/Makefile | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 63be5362fd3a..947ed642debe 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -42,6 +42,12 @@ config PWM_DEBUG
>  	  It is expected to introduce some runtime overhead and diagnostic
>  	  output to the kernel log, so only enable while working on a driver.
>  
> +config PWM_ASPEED_G6
> +	tristate "ASPEEDG6 PWM support"

No depends?

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/20210412/d115461b/attachment.sig>

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:40 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:40 +0800
Subject: [PATCH v2,
 0/5] Revert "mailbox: mediatek: remove implementation related to
 atomic_exec"
Message-ID: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>

This series base linux 5.12-rc2
these patches will cause home ui flick when cursor moved,
there is no fix solution yet, revert these patches first.

change since v1:
add mtk-gce.txt and dts modification

Yongqiang Niu (5):
  Revert "drm/mediatek: Make sure previous message done or be aborted
    before send"
  Revert "mailbox: mediatek: remove implementation related to
    atomic_exec"
  Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
  Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells
    value"
  arm64: dts: mediatek: mt8183: add gce information for mmsys

 .../devicetree/bindings/mailbox/mtk-gce.txt        |  2 +-
 arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  5 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c            |  1 -
 drivers/mailbox/mtk-cmdq-mailbox.c                 | 80 +++++++++++++++++++---
 4 files changed, 76 insertions(+), 12 deletions(-)

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:42 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:42 +0800
Subject: [PATCH v2,
 2/5] Revert "mailbox: mediatek: remove implementation related to
 atomic_exec"
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618226325-31927-3-git-send-email-yongqiang.niu@mediatek.com>

This reverts commit c9ea564f3d9dd20d88bd34f40a6ff6d31a0d7e8c.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 80 +++++++++++++++++++++++++++++++++-----
 1 file changed, 71 insertions(+), 9 deletions(-)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 5665b6e..e0d9a86 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -56,6 +56,7 @@ struct cmdq_thread {
 	void __iomem		*base;
 	struct list_head	task_busy_list;
 	u32			priority;
+	bool			atomic_exec;
 };
 
 struct cmdq_task {
@@ -168,18 +169,56 @@ static void cmdq_task_insert_into_thread(struct cmdq_task *task)
 	dma_sync_single_for_cpu(dev, prev_task->pa_base,
 				prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
 	prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
-		(u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
+		(u64)CMDQ_JUMP_BY_PA << 32 |
+		(task->pa_base >> task->cmdq->shift_pa);
 	dma_sync_single_for_device(dev, prev_task->pa_base,
 				   prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
 
 	cmdq_thread_invalidate_fetched_data(thread);
 }
 
+static bool cmdq_command_is_wfe(u64 cmd)
+{
+	u64 wfe_option = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+	u64 wfe_op = (u64)(CMDQ_CODE_WFE << CMDQ_OP_CODE_SHIFT) << 32;
+	u64 wfe_mask = (u64)CMDQ_OP_CODE_MASK << 32 | 0xffffffff;
+
+	return ((cmd & wfe_mask) == (wfe_op | wfe_option));
+}
+
+/* we assume tasks in the same display GCE thread are waiting the same event. */
+static void cmdq_task_remove_wfe(struct cmdq_task *task)
+{
+	struct device *dev = task->cmdq->mbox.dev;
+	u64 *base = task->pkt->va_base;
+	int i;
+
+	dma_sync_single_for_cpu(dev, task->pa_base, task->pkt->cmd_buf_size,
+				DMA_TO_DEVICE);
+	for (i = 0; i < CMDQ_NUM_CMD(task->pkt); i++)
+		if (cmdq_command_is_wfe(base[i]))
+			base[i] = (u64)CMDQ_JUMP_BY_OFFSET << 32 |
+				  (CMDQ_JUMP_PASS >> task->cmdq->shift_pa);
+	dma_sync_single_for_device(dev, task->pa_base, task->pkt->cmd_buf_size,
+				   DMA_TO_DEVICE);
+}
+
 static bool cmdq_thread_is_in_wfe(struct cmdq_thread *thread)
 {
 	return readl(thread->base + CMDQ_THR_WAIT_TOKEN) & CMDQ_THR_IS_WAITING;
 }
 
+static void cmdq_thread_wait_end(struct cmdq_thread *thread,
+				 unsigned long end_pa)
+{
+	struct device *dev = thread->chan->mbox->dev;
+	unsigned long curr_pa;
+
+	if (readl_poll_timeout_atomic(thread->base + CMDQ_THR_CURR_ADDR,
+			curr_pa, curr_pa == end_pa, 1, 20))
+		dev_err(dev, "GCE thread cannot run to end.\n");
+}
+
 static void cmdq_task_exec_done(struct cmdq_task *task, enum cmdq_cb_status sta)
 {
 	struct cmdq_task_cb *cb = &task->pkt->async_cb;
@@ -371,15 +410,37 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan, void *data)
 			cmdq->shift_pa;
 		end_pa = readl(thread->base + CMDQ_THR_END_ADDR) <<
 			cmdq->shift_pa;
-		/* check boundary */
-		if (curr_pa == end_pa - CMDQ_INST_SIZE ||
-		    curr_pa == end_pa) {
-			/* set to this task directly */
-			writel(task->pa_base >> cmdq->shift_pa,
-			       thread->base + CMDQ_THR_CURR_ADDR);
+
+		/*
+		 * Atomic execution should remove the following wfe, i.e. only
+		 * wait event at first task, and prevent to pause when running.
+		 */
+		if (thread->atomic_exec) {
+			/* GCE is executing if command is not WFE */
+			if (!cmdq_thread_is_in_wfe(thread)) {
+				cmdq_thread_resume(thread);
+				cmdq_thread_wait_end(thread,
+						     end_pa >> cmdq->shift_pa);
+				WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
+				/* set to this task directly */
+				writel(task->pa_base >> cmdq->shift_pa,
+				       thread->base + CMDQ_THR_CURR_ADDR);
+			} else {
+				cmdq_task_insert_into_thread(task);
+				cmdq_task_remove_wfe(task);
+				smp_mb(); /* modify jump before enable thread */
+			}
 		} else {
-			cmdq_task_insert_into_thread(task);
-			smp_mb(); /* modify jump before enable thread */
+			/* check boundary */
+			if (curr_pa == end_pa - CMDQ_INST_SIZE ||
+			    curr_pa == end_pa) {
+				/* set to this task directly */
+				writel(task->pa_base >> cmdq->shift_pa,
+				       thread->base + CMDQ_THR_CURR_ADDR);
+			} else {
+				cmdq_task_insert_into_thread(task);
+				smp_mb(); /* modify jump before enable thread */
+			}
 		}
 		writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
 		       thread->base + CMDQ_THR_END_ADDR);
@@ -500,6 +561,7 @@ static struct mbox_chan *cmdq_xlate(struct mbox_controller *mbox,
 
 	thread = (struct cmdq_thread *)mbox->chans[ind].con_priv;
 	thread->priority = sp->args[1];
+	thread->atomic_exec = (sp->args[2] != 0);
 	thread->chan = &mbox->chans[ind];
 
 	return &mbox->chans[ind];
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:41 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:41 +0800
Subject: [PATCH v2,
 1/5] Revert "drm/mediatek: Make sure previous message done or be
 aborted before send"
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618226325-31927-2-git-send-email-yongqiang.niu@mediatek.com>

This reverts commit 839cbf0531428f3f9535077a461b8631359c1165.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8b0de90..c76f446 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -463,7 +463,6 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
 	}
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 	if (mtk_crtc->cmdq_client) {
-		mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
 		cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
 		cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
 		cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:43 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:43 +0800
Subject: [PATCH v2,
 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells
 value"
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618226325-31927-4-git-send-email-yongqiang.niu@mediatek.com>

This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 7771eca..cf48cd8 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -47,7 +47,7 @@ Example:
 		interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
 		clocks = <&infracfg CLK_INFRA_GCE>;
 		clock-names = "gce";
-		#mbox-cells = <2>;
+		#mbox-cells = <3>;
 	};
 
 Example for a client device:
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:44 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:44 +0800
Subject: [PATCH v2,
 4/5] Revert "arm64: dts: mediatek: mt8183: fix gce incorrect
 mbox-cells value"
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618226325-31927-5-git-send-email-yongqiang.niu@mediatek.com>

This reverts commit e55c56df43dd11de4a6c08e3ea52ca45b51c8800.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a1..bc89283 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -541,7 +541,7 @@
 			compatible = "mediatek,mt8183-gce";
 			reg = <0 0x10238000 0 0x4000>;
 			interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
-			#mbox-cells = <2>;
+			#mbox-cells = <3>;
 			clocks = <&infracfg CLK_INFRA_GCE>;
 			clock-names = "gce";
 		};
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:18:45 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:18:45 +0800
Subject: [PATCH v2,
 5/5] arm64: dts: mediatek: mt8183: add gce information for mmsys
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618226325-31927-6-git-send-email-yongqiang.niu@mediatek.com>

add gce information for mmsys

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index bc89283..e3a8b10 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -983,6 +983,9 @@
 			compatible = "mediatek,mt8183-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
 			#clock-cells = <1>;
+			mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST 1>,
+				 <&gce 1 CMDQ_THR_PRIO_HIGHEST 1>;
+			mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
 		};
 
 		ovl0: ovl at 14008000 {
-- 
1.8.1.1.dirty

From geert at linux-m68k.org  Mon Apr 12 12:22:12 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 12 Apr 2021 13:22:12 +0200
Subject: [GIT PULL] Renesas ARM DT updates for v5.13 (take two)
In-Reply-To: <161789462010.1629934.8245364544434971043.b4-ty@arndb.de>
References: <cover.1617359678.git.geert+renesas@glider.be>
 <161789462010.1629934.8245364544434971043.b4-ty@arndb.de>
Message-ID: <CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw@mail.gmail.com>

Hi Arnd,

On Thu, Apr 8, 2021 at 5:24 PM Arnd Bergmann <arnd at kernel.org> wrote:
> On Fri, 2 Apr 2021 12:37:15 +0200, Geert Uytterhoeven wrote:
> > The following changes since commit c8aebc1346522d3569690867ce3996642ad52e01:
> >
> >   arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding (2021-03-16 09:58:00 +0100)
> >
> > are available in the Git repository at:
> >
> > [...]
>
> Merged into arm/dt, thanks!

Thank you!

> There were a couple of added warnings from 'make dtbs_check W=1':
>
> renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports: 'port at 0' is a required property

The same issue is present in several other pre-existing DTS files, too.
Commit 066a94e28a23e04c ("media: dt-bindings: media: Use graph and
video-interfaces schemas") in v5.12-rc1 made port at 0 mandatory, but that
port is not present on boards were the interface isn't used (yet).
Probably we should add placeholder port at 0 nodes to all SoC .dtsi files,
like we already have in display, audio, hdmi, and lvds nodes.

> renesas/r8a779a0-falcon.dt.yaml: thermal-zones: 'sensor-thermal1', 'sensor-thermal2', 'sensor-thermal3', 'sensor-thermal4', 'sensor-thermal5' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$', 'pinctrl-[0-9]+'

I don't see that one with the latest bindings in linux-next (i.e. commit
9468e7b031876935 ("dt-bindings: thermal: rcar-gen3-thermal: Support five
TSC nodes on r8a779a0")).

> renesas/r8a779a0-falcon.dt.yaml: timer at e61e0000: compatible:0: 'renesas,tmu-r8a779a0' is not one of ['renesas,tmu-r8a7740', 'renesas,tmu-r8a774a1', 'renesas,tmu-r8a774b1', 'renesas,tmu-r8a774c0', 'renesas,tmu-r8a774e1', 'renesas,tmu-r8a7778', 'renesas,tmu-r8a7779', 'renesas,tmu-r8a7795', 'renesas,tmu-r8a7796', 'renesas,tmu-r8a77961', 'renesas,tmu-r8a77965', 'renesas,tmu-r8a77970', 'renesas,tmu-r8a77980', 'renesas,tmu-r8a77990', 'renesas,tmu-r8a77995']

Trivial DT binding update posted (but not CCed to devicetree) in
https://lore.kernel.org/r/20210331124555.2150-1-wsa at kernel.org/

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 arnd at arndb.de  Mon Apr 12 12:26:00 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 12 Apr 2021 13:26:00 +0200
Subject: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
In-Reply-To: <5c3635a2b44a496b88d665e8686d9436@AcuMS.aculab.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-6-hch@lst.de>
 <15be19af19174c7692dd795297884096@AcuMS.aculab.com>
 <5c3635a2b44a496b88d665e8686d9436@AcuMS.aculab.com>
Message-ID: <CAK8P3a1JZ=JerasdkntzX_ApaCF7C29ZS1E31aPQATOts0ZiLw@mail.gmail.com>

On Mon, Apr 12, 2021 at 12:54 PM David Laight <David.Laight at aculab.com> wrote:
> From: David Laight > Sent: 12 April 2021 10:37
> ...
> > I'm guessing that compat_pid_t is 16 bits?
> > So the native 32bit version has an unnamed 2 byte structure pad.
> > The 'packed' removes this pad from the compat structure.
> >
> > AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
> > adding an explicit pad for the implicit pad the compiler
> > would generate because compat_pid_t is 16 bits.
>
> I've just looked at the header.
> compat_pid_t is 32 bits.
> So Linux must have gained 32bit pids at some earlier time.
> (Historically Unix pids were 16 bit - even on 32bit systems.)
>
> Which makes the explicit pad in 'sparc' rather 'interesting'.

I saw it was there since the sparc kernel support got merged in
linux-1.3, possibly copied from an older sunos version.

> oh - compat_loff_t is only used in a couple of other places.
> neither care in any way about the alignment.
> (Provided get_user() doesn't fault on a 8n+4 aligned address.)

Ah right, I also see that after this series it's only used in to other
places:  compat_resume_swap_area, which could also lose the
__packed annotation, and in the declaration of
compat_sys_sendfile64, where it makes no difference.

      Arnd


From mike.leach at linaro.org  Mon Apr 12 12:29:13 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Mon, 12 Apr 2021 12:29:13 +0100
Subject: [PATCH v6 07/10] coresight: etm4x: Add complex configuration
 handlers to etmv4
In-Reply-To: <97d53224-0749-086b-b2b4-12c91ec8ad5a@arm.com>
References: <20210409103722.26290-1-mike.leach@linaro.org>
 <20210409103722.26290-8-mike.leach@linaro.org>
 <97d53224-0749-086b-b2b4-12c91ec8ad5a@arm.com>
Message-ID: <CAJ9a7Vh23-nFNRdQQZY4s4fGD8xhnE+PQUAE0US8fpsr-ZnsRQ@mail.gmail.com>

HI Suzuki,

On Mon, 12 Apr 2021 at 11:28, Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
>
> On 09/04/2021 11:37, Mike Leach wrote:
> > Adds in handlers to allow the ETMv4 to use the complex configuration
> > support. Features and configurations can be loaded and selected in the
> > device.
> >
> > Signed-off-by: Mike Leach <mike.leach at linaro.org>
> > Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> > ---
> >   drivers/hwtracing/coresight/Makefile          |   3 +-
> >   .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
> >   .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
> >   .../coresight/coresight-etm4x-core.c          |  38 +++-
> >   .../coresight/coresight-etm4x-sysfs.c         |   3 +
> >   5 files changed, 238 insertions(+), 3 deletions(-)
> >   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> >   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> >
> > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> > index 63ecfc3cf66d..9420d33b23ac 100644
> > --- a/drivers/hwtracing/coresight/Makefile
> > +++ b/drivers/hwtracing/coresight/Makefile
> > @@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
> >   coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
> >                    coresight-etm3x-sysfs.o
> >   obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
> > -coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
> > +coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
> > +                     coresight-etm4x-cfg.o
> >   obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> >   obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> >   obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > new file mode 100644
> > index 000000000000..d2ea903231b2
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > @@ -0,0 +1,182 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> > + * Author: Mike Leach <mike.leach at linaro.org>
> > + */
> > +
>
> > +#include "coresight-etm4x.h"
> > +#include "coresight-etm4x-cfg.h"
> > +#include "coresight-priv.h"
> > +#include "coresight-syscfg.h"
> > +
> > +/* defines to associate register IDs with driver data locations */
> > +#define CHECKREG(cval, elem) \
> > +     { \
> > +             if (offset == cval) { \
> > +                     reg_csdev->driver_regval = &drvcfg->elem; \
> > +                     err = 0; \
> > +                     break; \
> > +             } \
> > +     }
> > +
> > +#define CHECKREGIDX(cval, elem, off_idx, mask)       \
> > +     { \
> > +             if (mask == cval) { \
> > +                     reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
> > +                     err = 0; \
> > +                     break; \
> > +             } \
> > +     }
> > +
> > +/**
> > + * etm4_cfg_map_reg_offset - validate and map the register offset into a
> > + *                        location in the driver config struct.
> > + *
> > + * Limits the number of registers that can be accessed and programmed in
> > + * features, to those which are used to control the trace capture parameters.
> > + *
> > + * Omits or limits access to those which the driver must use exclusively.
> > + *
> > + * Invalid offsets will result in fail code return and feature load failure.
> > + *
> > + * @drvdata: driver data to map into.
> > + * @reg:     register to map.
> > + * @offset:  device offset for the register
> > + */
> > +static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> > +                                struct cscfg_regval_csdev *reg_csdev, u32 offset)
> > +{
> > +     int err = -EINVAL, idx;
> > +     struct etmv4_config *drvcfg = &drvdata->config;
> > +     u32 off_mask;
> > +
> > +     if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> > +         ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
> > +         ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
> > +             do {
> > +                     CHECKREG(TRCEVENTCTL0R, eventctrl0);
> > +                     CHECKREG(TRCEVENTCTL1R, eventctrl1);
> > +                     CHECKREG(TRCSTALLCTLR, stall_ctrl);
> > +                     CHECKREG(TRCTSCTLR, ts_ctrl);
> > +                     CHECKREG(TRCSYNCPR, syncfreq);
> > +                     CHECKREG(TRCCCCTLR, ccctlr);
> > +                     CHECKREG(TRCBBCTLR, bb_ctrl);
> > +                     CHECKREG(TRCVICTLR, vinst_ctrl);
> > +                     CHECKREG(TRCVIIECTLR, viiectlr);
> > +                     CHECKREG(TRCVISSCTLR, vissctlr);
> > +                     CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
> > +                     CHECKREG(TRCSEQRSTEVR, seq_rst);
> > +                     CHECKREG(TRCSEQSTR, seq_state);
> > +                     CHECKREG(TRCEXTINSELR, ext_inp);
> > +                     CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
> > +                     CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
> > +                     CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
> > +                     CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
> > +             } while (0);
> > +     } else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
> > +             /* sequencer state control registers */
> > +             idx = (offset & GENMASK(3, 0)) / 4;
> > +             if (idx < ETM_MAX_SEQ_STATES) {
> > +                     reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
> > +                     err = 0;
> > +             }
> > +     } else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
> > +             /* 32 bit, 8 off indexed register sets */
> > +             idx = (offset & GENMASK(4, 0)) / 4;
> > +             off_mask =  (offset & GENMASK(11, 5));
> > +             do {
> > +                     CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> > +                     CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> > +                     CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> > +             } while (0);
> > +     } else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> > +             /* 64 bit, 8 off indexed register sets */
> > +             idx = (offset & GENMASK(5, 0)) / 8;
> > +             off_mask = (offset & GENMASK(11, 6));
> > +             do {
> > +                     CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
> > +                     CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
> > +             } while (0);
> > +     } else if ((offset >= TRCRSCTLRn(2)) &&
> > +                (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
> > +             /* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
> > +             idx = (offset & GENMASK(6, 0)) / 4;
> > +             if (idx < ETM_MAX_RES_SEL) {
> > +                     reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
> > +                     err = 0;
> > +             }
> > +     } else if ((offset >= TRCACVRn(0)) &&
> > +                (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
> > +             /* 64 bit addr cmp regs, 16 off */
> > +             idx = (offset & GENMASK(6, 0)) / 8;
> > +             off_mask = offset & GENMASK(11, 7);
> > +             do {
> > +                     CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
> > +                     CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
> > +             } while (0);
> > +     } else if ((offset >= TRCCNTRLDVRn(0)) &&
> > +                (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
> > +             /* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
> > +             idx = (offset &  GENMASK(3, 0)) / 4;
> > +             off_mask = offset &  GENMASK(11, 4);
> > +             do {
> > +                     CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
> > +                     CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
> > +                     CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
> > +             } while (0);
> > +     }
> > +     return err;
> > +}
> > +
> > +/**
> > + * etm4_cfg_load_feature - load a feature into a device instance.
> > + *
> > + * @csdev:   An ETMv4 CoreSight device.
> > + * @feat:    The feature to be loaded.
> > + *
> > + * The function will load a feature instance into the device, checking that
> > + * the register definitions are valid for the device.
> > + *
> > + * Parameter and register definitions will be converted into internal
> > + * structures that are used to set the values in the driver when the
> > + * feature is enabled for the device.
> > + *
> > + * The feature spinlock pointer is initialised to the same spinlock
> > + * that the driver uses to protect the internal register values.
> > + */
> > +static int etm4_cfg_load_feature(struct coresight_device *csdev,
> > +                              struct cscfg_feature_csdev *feat_csdev)
> > +{
> > +     struct device *dev = csdev->dev.parent;
> > +     struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
> > +     const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
> > +     u32 offset;
> > +     int i = 0, err = 0;
> > +
> > +     /*
> > +      * essential we set the device spinlock - this is used in the generic
> > +      * programming routines when copying values into the drvdata structures
> > +      * via the pointers setup in etm4_cfg_map_reg_offset().
> > +      */
> > +     feat_csdev->drv_spinlock = &drvdata->spinlock;
> > +
> > +     /* process the register descriptions */
> > +     for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
> > +             offset = feat_desc->regs_desc[i].offset;
> > +             err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
> > +     }
> > +     return err;
> > +}
> > +
> > +/* match information when loading configurations */
> > +#define CS_CFG_ETM4_MATCH_FLAGS      (CS_CFG_MATCH_CLASS_SRC_ALL | \
> > +                              CS_CFG_MATCH_CLASS_SRC_ETM4)
> > +
> > +int etm4_cscfg_register(struct coresight_device *csdev)
> > +{
> > +     struct cscfg_csdev_feat_ops ops;
> > +
> > +     ops.load_feat = &etm4_cfg_load_feature;
> > +
> > +     return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
> > +}
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> > new file mode 100644
> > index 000000000000..a204ad9a4792
> > --- /dev/null
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> > @@ -0,0 +1,15 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#ifndef _CORESIGHT_ETM4X_CFG_H
> > +#define _CORESIGHT_ETM4X_CFG_H
>
>
> Looks like this must be guarded by the CONFIG_CORESIGHT_SOURCE_ETM4X to
> prevent the build failures on arm, as reported by the test robot.
>

The test robot was complaining about
#include <asm/sysregs.h>
in the next patch and not this one. I haven't seen any issues reported
with this patch.

Moreover - if this is required - then removing the ETM4 module from
the config - i.e. not defining CONFIG_CORESIGHT_SOURCE_ETM4X - should
trigger the error. I have done a clean build, without ETM4 and the
error does not occur. (I also tried out gcc 9 in case this was a
factor - it was not)

I have to confess I am completely puzzled by this - how can this
include only trigger an issue with my patch when it has been in the
source for some time, and the same header (coresight-etm4x.h) is
included without apparent problems elsewhere in the coresight build.

Without a reliable reproducer, or a credible explanation, I can only
assume that this is an issue with the test robot itself.

I am open to further suggestions!

Thanks

Mike


> #ifdef CONFIG_CORESIGHT_SOURCE_ETM4X
>
> > +
> > +#include "coresight-config.h"
> > +#include "coresight-etm4x.h"
> > +
> > +/* ETMv4 specific config functions */
> > +int etm4_cscfg_register(struct coresight_device *csdev);
> > +
>
> endif /* ETM4X */
>
> Cheers
> Suzuki
>


--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From valentin.schneider at arm.com  Mon Apr 12 12:31:59 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Mon, 12 Apr 2021 12:31:59 +0100
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
Message-ID: <87y2dnn3gw.mognet@arm.com>


Hi,

On 12/04/21 15:08, Ruifeng Zhang wrote:
> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>
> The arm topology still parse from the MPIDR, but it is incomplete.  When
> the armv8.3 cpu runs in aarch32 mode, it will parse out the wrong topology.
>
> armv7 (A7) mpidr is:
> [11:8]      [7:2]       [1:0]
> cluster     reserved    cpu
>
> armv8.3 (A55) mpidr is:
> [23:16]     [15:8]      [7:0]
> cluster     cpu         thread
>
> For compatibility to keep the function of get capacity from default
> cputype, renamed arm parse_dt_topology to get_cputype_capacity and delete
> related logic of parse from dt.
> Arm using the same parse_dt_topology function as arm64.
>
> The arm device boot step is to look for the default cputype and get cpu
> capacity firstly. Then parse the topology and capacity from dt to replace
> default values.
>

I'm afraid I don't get it.

CONFIG_COMPAT lets you run 32-bit stuff at EL0, but the kernel is still
arm64. So if you take your armv8.3 system, the topology parsed by the
kernel will be the same regardless of CONFIG_COMPAT.

Could you elaborate on what problem you are trying to fix here?


From geert at linux-m68k.org  Mon Apr 12 12:32:58 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 12 Apr 2021 13:32:58 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
Message-ID: <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>

Hi Arnd,

On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:
> I've just gone through the DT merges I've received so far and, with a
> little help from Rob,
> managed to run 'make dtbs_check W=1' before and after, to see what
> warnings we get.
> The good news is that the number of warnings is going down, but
> unfortunately there
> is still an unmanageable amount of remaining warnings, and some new
> ones crept in.
>
> I'm still working on my tooling for this, to catch these better, but
> ideally I think we should
> try to not introduce new warnings. I think some platforms are already
> clean, and I did
> not see any new warnings for mvebu, samsung and broadcom. There were a lot of
> warnings from .dtsi files, and I probably did an incomplete job at
> deduplicating those.

Thanks for running these checks!

> See below for the other platforms, and the new warnings that I found.
> If these are
> valid, please send a fixup before the merge window, and let me know if
> you have ideas
> for how we should handle these in the future.
>
> For this merge window, I don't think any of them are show-stoppers (Rob, let me
> know if you disagree), but in the long run we may want to gradually enforce
> a rule about not merging changes that introduce any new warnings, in order to
> have a chance of cleaning up the existing ones.

This may not be as simple as it sounds, as DT binding updates typically
follow a different path than DTS(i) updates.  DT bindings updates may be
picked up by a subsystem maintainer, by Rob, or by the platform
maintainer.
For trivial updates (e.g. adding a compatible value, and sometimes
extending a limit), a DTS(i) update may be accepted by the platform
maintainer before the corresponding DT binding update.  The latter may
even be merged one or more kernel revisions later, especially when
involving subsystems that are not traditionally rooted into platforms
using DT.

Of course we could mention any expected warning regressions in our pull
requests for soc.

> renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports:
> 'port at 0' is a required property

[...]

I've replied to these as a response to your PR reply, see
https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw 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 nicolas.ferre at microchip.com  Mon Apr 12 12:42:48 2021
From: nicolas.ferre at microchip.com (Nicolas Ferre)
Date: Mon, 12 Apr 2021 13:42:48 +0200
Subject: [GIT PULL] ARM: at91: dt for 5.13
In-Reply-To: <CAK8P3a1dyccHquEoSv4kECw-=RKNQAFVQap-DYTX-sDfwEPTGQ@mail.gmail.com>
References: <20210407114415.13180-1-nicolas.ferre@microchip.com>
 <161789493817.1630479.5024717274217057698.b4-ty@arndb.de>
 <71b2bd27-0d3b-3331-4f79-85b22594e20b@microchip.com>
 <CAK8P3a1dyccHquEoSv4kECw-=RKNQAFVQap-DYTX-sDfwEPTGQ@mail.gmail.com>
Message-ID: <6968a992-c3d5-eb56-ec71-1908e7be6ca3@microchip.com>

Arnd,

On 08/04/2021 at 22:15, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:35 PM Nicolas Ferre
> <nicolas.ferre at microchip.com> wrote:
>> On 08/04/2021 at 17:24, Arnd Bergmann wrote:
>> Oh, got it: it's the upper case letter withing the etm hex address. I
>> used this one to mach what was done in the reg property. I'm fixing both
>> of them and sending the patch to the ml right now.
> 
> Ok
> 
>> Tell me if I add it to a subsequent pull-request or if you prefer to
>> take it the soonest in order to not generate additional warnings upstream.
> 
> I'd like to have it before the merge window, but don't bother making it
> an additional pull request if you already plan for another pull request with
> 5.13 material.

I don't plan to make another PR on DT for 5.13 so I would like you to 
take it as a patch.
https://lore.kernel.org/linux-arm-kernel/20210408164443.38941-1-nicolas.ferre at microchip.com/

Thanks for your help. Best regards,
   Nicolas


-- 
Nicolas Ferre


From vkoul at kernel.org  Mon Apr 12 12:44:17 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Mon, 12 Apr 2021 17:14:17 +0530
Subject: [PATCH] dmaengine: qcom_hidma: remove unused code
In-Reply-To: <1617270816-36400-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1617270816-36400-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <YHQykQa1fyxcpGJl@vkoul-mobl.Dlink>

On 01-04-21, 17:53, Jiapeng Chong wrote:
> Fix the following clang warning:
> 
> drivers/dma/qcom/hidma.c:94:20: warning: unused function 'to_hidma_desc'
> [-Wunused-function].

Applied, thanks

-- 
~Vinod


From yongqiang.niu at mediatek.com  Mon Apr 12 12:51:29 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:51:29 +0800
Subject: [PATCH v4, 2/3] arm64: dts: mt8192: add gce node
In-Reply-To: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618228290-18413-3-git-send-email-yongqiang.niu@mediatek.com>

add gce node for mt8192

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 9757138..1afa6ad 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -5,6 +5,7 @@
  */
 
 /dts-v1/;
+#include <dt-bindings/gce/mt8192-gce.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/pinctrl/mt8192-pinfunc.h>
@@ -291,6 +292,15 @@
 			clock-names = "clk13m";
 		};
 
+		gce: mailbox at 10228000 {
+			compatible = "mediatek,mt8192-gce";
+			reg = <0 0x10228000 0 0x4000>;
+			interrupts = <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH 0>;
+			#mbox-cells = <3>;
+			clocks = <&infracfg CLK_INFRA_GCE>;
+			clock-names = "gce";
+		};
+
 		uart0: serial at 11002000 {
 			compatible = "mediatek,mt8192-uart",
 				     "mediatek,mt6577-uart";
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:51:27 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:51:27 +0800
Subject: [PATCH v4, 0/3] support gce on mt8192 platform
Message-ID: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>

Change since v3:
-fix review comment in v2

Change since v2:
- add controy_by_sw for mt8192

Change since v1:
- move out shift jump patch
- remove useless patch

Yongqiang Niu (3):
  dt-binding: gce: add gce header file for mt8192
  arm64: dts: mt8192: add gce node
  mailbox: cmdq: add mt8192 support

 .../devicetree/bindings/mailbox/mtk-gce.txt        |   7 +-
 arch/arm64/boot/dts/mediatek/mt8192.dtsi           |  10 +
 drivers/mailbox/mtk-cmdq-mailbox.c                 |  10 +
 include/dt-bindings/gce/mt8192-gce.h               | 335 +++++++++++++++++++++
 4 files changed, 359 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/gce/mt8192-gce.h

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:51:30 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:51:30 +0800
Subject: [PATCH v4, 3/3] mailbox: cmdq: add mt8192 support
In-Reply-To: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618228290-18413-4-git-send-email-yongqiang.niu@mediatek.com>

add mt8192 support

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/mailbox/mtk-cmdq-mailbox.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index e0d9a86..8da700a 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -36,6 +36,8 @@
 #define CMDQ_THR_WAIT_TOKEN		0x30
 #define CMDQ_THR_PRIORITY		0x40
 
+#define GCE_GCTL_VALUE			0x48
+
 #define CMDQ_THR_ACTIVE_SLOT_CYCLES	0x3200
 #define CMDQ_THR_ENABLED		0x1
 #define CMDQ_THR_DISABLED		0x0
@@ -77,11 +79,13 @@ struct cmdq {
 	struct clk		*clock;
 	bool			suspended;
 	u8			shift_pa;
+	bool			control_by_sw;
 };
 
 struct gce_plat {
 	u32 thread_nr;
 	u8 shift;
+	bool control_by_sw;
 };
 
 u8 cmdq_get_shift_pa(struct mbox_chan *chan)
@@ -122,6 +126,8 @@ static void cmdq_init(struct cmdq *cmdq)
 	int i;
 
 	WARN_ON(clk_enable(cmdq->clock) < 0);
+	if (cmdq->control_by_sw)
+		writel(0x7, cmdq->base + GCE_GCTL_VALUE);
 	writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
 	for (i = 0; i <= CMDQ_MAX_EVENT; i++)
 		writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
@@ -598,6 +604,7 @@ static int cmdq_probe(struct platform_device *pdev)
 
 	cmdq->thread_nr = plat_data->thread_nr;
 	cmdq->shift_pa = plat_data->shift;
+	cmdq->control_by_sw = plat_data->control_by_sw;
 	cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
 	err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
 			       "mtk_cmdq", cmdq);
@@ -663,11 +670,14 @@ static int cmdq_probe(struct platform_device *pdev)
 static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
 static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
 static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
+static const struct gce_plat gce_plat_v5 = {.thread_nr = 24, .shift = 3,
+					    .control_by_sw = true};
 
 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,mt6779-gce", .data = (void *)&gce_plat_v4},
+	{.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v5},
 	{}
 };
 
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 12:51:28 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 19:51:28 +0800
Subject: [PATCH v4, 1/3] dt-binding: gce: add gce header file for mt8192
In-Reply-To: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618228290-18413-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618228290-18413-2-git-send-email-yongqiang.niu@mediatek.com>

Add documentation for the mt8192 gce.

Add gce header file defined the gce hardware event,
subsys number and constant for mt8192.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 .../devicetree/bindings/mailbox/mtk-gce.txt        |   7 +-
 include/dt-bindings/gce/mt8192-gce.h               | 335 +++++++++++++++++++++
 2 files changed, 339 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/gce/mt8192-gce.h

diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index cf48cd8..f48ae45 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -9,8 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to
 mailbox.txt for generic information about mailbox device-tree bindings.
 
 Required properties:
-- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or
-  "mediatek,mt6779-gce".
+- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce",
+  "mediatek,mt8192-gce" or "mediatek,mt6779-gce".
 - reg: Address range of the GCE unit
 - interrupts: The interrupt signal from the GCE block
 - clock: Clocks according to the common clock binding
@@ -36,7 +36,8 @@ Optional properties for a client device:
   size: the total size of register address that GCE can access.
 
 Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
-'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as
+'dt-binding/gce/mt8183-gce.h', 'dt-binding/gce/mt8192-gce.h' or
+'dt-bindings/gce/mt6779-gce.h'. Such as
 sub-system ids, thread priority, event ids.
 
 Example:
diff --git a/include/dt-bindings/gce/mt8192-gce.h b/include/dt-bindings/gce/mt8192-gce.h
new file mode 100644
index 0000000..9e5a0eb
--- /dev/null
+++ b/include/dt-bindings/gce/mt8192-gce.h
@@ -0,0 +1,335 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Yongqiang Niu <yongqiang.niu at mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_GCE_MT8192_H
+#define _DT_BINDINGS_GCE_MT8192_H
+
+/* assign timeout 0 also means default */
+#define CMDQ_NO_TIMEOUT		0xffffffff
+#define CMDQ_TIMEOUT_DEFAULT	1000
+
+/* GCE thread priority */
+#define CMDQ_THR_PRIO_LOWEST	0
+#define CMDQ_THR_PRIO_1		1
+#define CMDQ_THR_PRIO_2		2
+#define CMDQ_THR_PRIO_3		3
+#define CMDQ_THR_PRIO_4		4
+#define CMDQ_THR_PRIO_5		5
+#define CMDQ_THR_PRIO_6		6
+#define CMDQ_THR_PRIO_HIGHEST	7
+
+/* CPR count in 32bit register */
+#define GCE_CPR_COUNT		1312
+
+/* GCE subsys table */
+#define SUBSYS_1300XXXX		0
+#define SUBSYS_1400XXXX		1
+#define SUBSYS_1401XXXX		2
+#define SUBSYS_1402XXXX		3
+#define SUBSYS_1502XXXX		4
+#define SUBSYS_1880XXXX		5
+#define SUBSYS_1881XXXX		6
+#define SUBSYS_1882XXXX		7
+#define SUBSYS_1883XXXX		8
+#define SUBSYS_1884XXXX		9
+#define SUBSYS_1000XXXX		10
+#define SUBSYS_1001XXXX		11
+#define SUBSYS_1002XXXX		12
+#define SUBSYS_1003XXXX		13
+#define SUBSYS_1004XXXX		14
+#define SUBSYS_1005XXXX		15
+#define SUBSYS_1020XXXX		16
+#define SUBSYS_1028XXXX		17
+#define SUBSYS_1700XXXX		18
+#define SUBSYS_1701XXXX		19
+#define SUBSYS_1702XXXX		20
+#define SUBSYS_1703XXXX		21
+#define SUBSYS_1800XXXX		22
+#define SUBSYS_1801XXXX		23
+#define SUBSYS_1802XXXX		24
+#define SUBSYS_1804XXXX		25
+#define SUBSYS_1805XXXX		26
+#define SUBSYS_1808XXXX		27
+#define SUBSYS_180aXXXX		28
+#define SUBSYS_180bXXXX		29
+
+#define CMDQ_EVENT_VDEC_LAT_SOF_0			0
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_0		1
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_1		2
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_2		3
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_3		4
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_4		5
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_5		6
+#define CMDQ_EVENT_VDEC_LAT_FRAME_DONE_6		7
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_0			8
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_1			9
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_2			10
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_3			11
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_4			12
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_5			13
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_6			14
+#define CMDQ_EVENT_VDEC_LAT_ENG_EVENT_7			15
+
+#define CMDQ_EVENT_ISP_FRAME_DONE_A			65
+#define CMDQ_EVENT_ISP_FRAME_DONE_B			66
+#define CMDQ_EVENT_ISP_FRAME_DONE_C			67
+#define CMDQ_EVENT_CAMSV0_PASS1_DONE			68
+#define CMDQ_EVENT_CAMSV02_PASS1_DONE			69
+#define CMDQ_EVENT_CAMSV1_PASS1_DONE			70
+#define CMDQ_EVENT_CAMSV2_PASS1_DONE			71
+#define CMDQ_EVENT_CAMSV3_PASS1_DONE			72
+#define CMDQ_EVENT_MRAW_0_PASS1_DONE			73
+#define CMDQ_EVENT_MRAW_1_PASS1_DONE			74
+#define CMDQ_EVENT_SENINF_CAM0_FIFO_FULL		75
+#define CMDQ_EVENT_SENINF_CAM1_FIFO_FULL		76
+#define CMDQ_EVENT_SENINF_CAM2_FIFO_FULL		77
+#define CMDQ_EVENT_SENINF_CAM3_FIFO_FULL		78
+#define CMDQ_EVENT_SENINF_CAM4_FIFO_FULL		79
+#define CMDQ_EVENT_SENINF_CAM5_FIFO_FULL		80
+#define CMDQ_EVENT_SENINF_CAM6_FIFO_FULL		81
+#define CMDQ_EVENT_SENINF_CAM7_FIFO_FULL		82
+#define CMDQ_EVENT_SENINF_CAM8_FIFO_FULL		83
+#define CMDQ_EVENT_SENINF_CAM9_FIFO_FULL		84
+#define CMDQ_EVENT_SENINF_CAM10_FIFO_FULL		85
+#define CMDQ_EVENT_SENINF_CAM11_FIFO_FULL		86
+#define CMDQ_EVENT_SENINF_CAM12_FIFO_FULL		87
+#define CMDQ_EVENT_TG_OVRUN_A_INT			88
+#define CMDQ_EVENT_DMA_R1_ERROR_A_INT			89
+#define CMDQ_EVENT_TG_OVRUN_B_INT			90
+#define CMDQ_EVENT_DMA_R1_ERROR_B_INT			91
+#define CMDQ_EVENT_TG_OVRUN_C_INT			92
+#define CMDQ_EVENT_DMA_R1_ERROR_C_INT			93
+#define CMDQ_EVENT_TG_OVRUN_M0_INT			94
+#define CMDQ_EVENT_DMA_R1_ERROR_M0_INT			95
+#define CMDQ_EVENT_TG_GRABERR_M0_INT			96
+#define CMDQ_EVENT_TG_GRABERR_M1_INT			97
+#define CMDQ_EVENT_TG_GRABERR_A_INT			98
+#define CMDQ_EVENT_CQ_VR_SNAP_A_INT			99
+#define CMDQ_EVENT_TG_GRABERR_B_INT			100
+#define CMDQ_EVENT_CQ_VR_SNAP_B_INT			101
+#define CMDQ_EVENT_TG_GRABERR_C_INT			102
+#define CMDQ_EVENT_CQ_VR_SNAP_C_INT			103
+
+#define CMDQ_EVENT_VENC_CMDQ_FRAME_DONE			129
+#define CMDQ_EVENT_VENC_CMDQ_PAUSE_DONE			130
+#define CMDQ_EVENT_JPGENC_CMDQ_DONE			131
+#define CMDQ_EVENT_VENC_CMDQ_MB_DONE			132
+#define CMDQ_EVENT_VENC_CMDQ_128BYTE_CNT_DONE		133
+#define CMDQ_EVENT_VENC_C0_CMDQ_WP_2ND_STAGE_DONE	134
+#define CMDQ_EVENT_VENC_C0_CMDQ_WP_3RD_STAGE_DONE	135
+#define CMDQ_EVENT_VENC_CMDQ_PPS_DONE			136
+#define CMDQ_EVENT_VENC_CMDQ_SPS_DONE			137
+#define CMDQ_EVENT_VENC_CMDQ_VPS_DONE			138
+
+#define CMDQ_EVENT_VDEC_CORE0_SOF_0			160
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_0		161
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_1		162
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_2		163
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_3		164
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_4		165
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_5		166
+#define CMDQ_EVENT_VDEC_CORE0_FRAME_DONE_6		167
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_0		168
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_1		169
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_2		170
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_3		171
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_4		172
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_5		173
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_6		174
+#define CMDQ_EVENT_VDEC_CORE0_ENG_EVENT_7		175
+#define CMDQ_EVENT_FDVT_DONE				177
+#define CMDQ_EVENT_FE_DONE				178
+#define CMDQ_EVENT_RSC_DONE				179
+#define CMDQ_EVENT_DVS_DONE_ASYNC_SHOT			180
+#define CMDQ_EVENT_DVP_DONE_ASYNC_SHOT			181
+
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_0		193
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_1		194
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_2		195
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_3		196
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_4		197
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_5		198
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_6		199
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_7		200
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_8		201
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_9		202
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_10		203
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_11		204
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_12		205
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_13		206
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_14		207
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_15		208
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_16		209
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_17		210
+#define CMDQ_EVENT_IMG2_DIP_FRAME_DONE_P2_18		211
+#define CMDQ_EVENT_IMG2_DIP_DMA_ERR_EVENT		212
+#define CMDQ_EVENT_IMG2_AMD_FRAME_DONE			213
+#define CMDQ_EVENT_IMG2_MFB_DONE_LINK_MISC		214
+#define CMDQ_EVENT_IMG2_WPE_A_DONE_LINK_MISC		215
+#define CMDQ_EVENT_IMG2_MSS_DONE_LINK_MISC		216
+
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_0		225
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_1		226
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_2		227
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_3		228
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_4		229
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_5		230
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_6		231
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_7		232
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_8		233
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_9		234
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_10		235
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_11		236
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_12		237
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_13		238
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_14		239
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_15		240
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_16		241
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_17		242
+#define CMDQ_EVENT_IMG1_DIP_FRAME_DONE_P2_18		243
+#define CMDQ_EVENT_IMG1_DIP_DMA_ERR_EVENT		244
+#define CMDQ_EVENT_IMG1_AMD_FRAME_DONE			245
+#define CMDQ_EVENT_IMG1_MFB_DONE_LINK_MISC		246
+#define CMDQ_EVENT_IMG1_WPE_A_DONE_LINK_MISC		247
+#define CMDQ_EVENT_IMG1_MSS_DONE_LINK_MISC		248
+
+#define CMDQ_EVENT_MDP_RDMA0_SOF			256
+#define CMDQ_EVENT_MDP_RDMA1_SOF			257
+#define CMDQ_EVENT_MDP_AAL0_SOF				258
+#define CMDQ_EVENT_MDP_AAL1_SOF				259
+#define CMDQ_EVENT_MDP_HDR0_SOF				260
+#define CMDQ_EVENT_MDP_HDR1_SOF				261
+#define CMDQ_EVENT_MDP_RSZ0_SOF				262
+#define CMDQ_EVENT_MDP_RSZ1_SOF				263
+#define CMDQ_EVENT_MDP_WROT0_SOF			264
+#define CMDQ_EVENT_MDP_WROT1_SOF			265
+#define CMDQ_EVENT_MDP_TDSHP0_SOF			266
+#define CMDQ_EVENT_MDP_TDSHP1_SOF			267
+#define CMDQ_EVENT_IMG_DL_RELAY0_SOF			268
+#define CMDQ_EVENT_IMG_DL_RELAY1_SOF			269
+#define CMDQ_EVENT_MDP_COLOR0_SOF			270
+#define CMDQ_EVENT_MDP_COLOR1_SOF			271
+#define CMDQ_EVENT_MDP_WROT1_FRAME_DONE			290
+#define CMDQ_EVENT_MDP_WROT0_FRAME_DONE			291
+#define CMDQ_EVENT_MDP_TDSHP1_FRAME_DONE		294
+#define CMDQ_EVENT_MDP_TDSHP0_FRAME_DONE		295
+#define CMDQ_EVENT_MDP_RSZ1_FRAME_DONE			302
+#define CMDQ_EVENT_MDP_RSZ0_FRAME_DONE			303
+#define CMDQ_EVENT_MDP_RDMA1_FRAME_DONE			306
+#define CMDQ_EVENT_MDP_RDMA0_FRAME_DONE			307
+#define CMDQ_EVENT_MDP_HDR1_FRAME_DONE			308
+#define CMDQ_EVENT_MDP_HDR0_FRAME_DONE			309
+#define CMDQ_EVENT_MDP_COLOR1_FRAME_DONE		312
+#define CMDQ_EVENT_MDP_COLOR0_FRAME_DONE		313
+#define CMDQ_EVENT_MDP_AAL1_FRAME_DONE			316
+#define CMDQ_EVENT_MDP_AAL0_FRAME_DONE			317
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_0		320
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_1		321
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_2		322
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_3		323
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_4		324
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_5		325
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_6		326
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_7		327
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_8		328
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_9		329
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_10		330
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_11		331
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_12		332
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_13		333
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_14		334
+#define CMDQ_EVENT_MDP_STREAM_DONE_ENG_EVENT_15		335
+#define CMDQ_EVENT_MDP_WROT1_SW_RST_DONE_ENG_EVENT	338
+#define CMDQ_EVENT_MDP_WROT0_SW_RST_DONE_ENG_EVENT	339
+#define CMDQ_EVENT_MDP_RDMA1_SW_RST_DONE_ENG_EVENT	342
+#define CMDQ_EVENT_MDP_RDMA0_SW_RST_DONE_ENG_EVENT	343
+
+#define CMDQ_EVENT_DISP_OVL0_SOF			384
+#define CMDQ_EVENT_DISP_OVL0_2L_SOF			385
+#define CMDQ_EVENT_DISP_RDMA0_SOF			386
+#define CMDQ_EVENT_DISP_RSZ0_SOF			387
+#define CMDQ_EVENT_DISP_COLOR0_SOF			388
+#define CMDQ_EVENT_DISP_CCORR0_SOF			389
+#define CMDQ_EVENT_DISP_AAL0_SOF			390
+#define CMDQ_EVENT_DISP_GAMMA0_SOF			391
+#define CMDQ_EVENT_DISP_POSTMASK0_SOF			392
+#define CMDQ_EVENT_DISP_DITHER0_SOF			393
+#define CMDQ_EVENT_DISP_DSC_WRAP0_CORE0_SOF		394
+#define CMDQ_EVENT_DISP_DSC_WRAP0_CORE1_SOF		395
+#define CMDQ_EVENT_DSI0_SOF				396
+#define CMDQ_EVENT_DISP_WDMA0_SOF			397
+#define CMDQ_EVENT_DISP_UFBC_WDMA0_SOF			398
+#define CMDQ_EVENT_DISP_PWM0_SOF			399
+#define CMDQ_EVENT_DISP_OVL2_2L_SOF			400
+#define CMDQ_EVENT_DISP_RDMA4_SOF			401
+#define CMDQ_EVENT_DISP_DPI0_SOF			402
+#define CMDQ_EVENT_MDP_RDMA4_SOF			403
+#define CMDQ_EVENT_MDP_HDR4_SOF				404
+#define CMDQ_EVENT_MDP_RSZ4_SOF				405
+#define CMDQ_EVENT_MDP_AAL4_SOF				406
+#define CMDQ_EVENT_MDP_TDSHP4_SOF			407
+#define CMDQ_EVENT_MDP_COLOR4_SOF			408
+#define CMDQ_EVENT_DISP_Y2R0_SOF			409
+#define CMDQ_EVENT_MDP_TDSHP4_FRAME_DONE		410
+#define CMDQ_EVENT_MDP_RSZ4_FRAME_DONE			411
+#define CMDQ_EVENT_MDP_RDMA4_FRAME_DONE			412
+#define CMDQ_EVENT_MDP_HDR4_FRAME_DONE			413
+#define CMDQ_EVENT_MDP_COLOR4_FRAME_DONE		414
+#define CMDQ_EVENT_MDP_AAL4_FRAME_DONE			415
+#define CMDQ_EVENT_DSI0_FRAME_DONE			416
+#define CMDQ_EVENT_DISP_WDMA0_FRAME_DONE		417
+#define CMDQ_EVENT_DISP_UFBC_WDMA0_FRAME_DONE		418
+#define CMDQ_EVENT_DISP_RSZ0_FRAME_DONE			419
+#define CMDQ_EVENT_DISP_RDMA4_FRAME_DONE		420
+#define CMDQ_EVENT_DISP_RDMA0_FRAME_DONE		421
+#define CMDQ_EVENT_DISP_POSTMASK0_FRAME_DONE		422
+#define CMDQ_EVENT_DISP_OVL2_2L_FRAME_DONE		423
+#define CMDQ_EVENT_DISP_OVL0_FRAME_DONE			424
+#define CMDQ_EVENT_DISP_OVL0_2L_FRAME_DONE		425
+#define CMDQ_EVENT_DISP_GAMMA0_FRAME_DONE		426
+#define CMDQ_EVENT_DISP_DSC_WRAP0_CORE1_FRAME_DONE	427
+#define CMDQ_EVENT_DISP_DSC_WRAP0_CORE0_FRAME_DONE	428
+#define CMDQ_EVENT_DISP_DPI0_FRAME_DONE			429
+#define CMDQ_EVENT_DISP_DITHER0_FRAME_DONE		430
+#define CMDQ_EVENT_DISP_COLOR0_FRAME_DONE		431
+#define CMDQ_EVENT_DISP_CCORR0_FRAME_DONE		432
+#define CMDQ_EVENT_DISP_AAL0_FRAME_DONE			433
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_0		434
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_1		435
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_2		436
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_3		437
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_4		438
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_5		439
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_6		440
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_7		441
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_8		442
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_9		443
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_10	444
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_11	445
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_12	446
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_13	447
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_14	448
+#define CMDQ_EVENT_DISP_STREAM_DONE_ENG_EVENT_15	449
+#define CMDQ_EVENT_DSI0_TE_ENG_EVENT			450
+#define CMDQ_EVENT_DSI0_IRQ_ENG_EVENT			451
+#define CMDQ_EVENT_DSI0_DONE_ENG_EVENT			452
+#define CMDQ_EVENT_DISP_WDMA0_SW_RST_DONE_ENG_EVENT	453
+#define CMDQ_EVENT_DISP_SMIASSERT_ENG_EVENT		454
+#define CMDQ_EVENT_DISP_POSTMASK0_RST_DONE_ENG_EVENT	455
+#define CMDQ_EVENT_DISP_OVL2_2L_RST_DONE_ENG_EVENT	456
+#define CMDQ_EVENT_DISP_OVL0_RST_DONE_ENG_EVENT		457
+#define CMDQ_EVENT_DISP_OVL0_2L_RST_DONE_ENG_EVENT	458
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_0		459
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_1		460
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_2		461
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_3		462
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_4		463
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_5		464
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_6		465
+#define CMDQ_EVENT_BUF_UNDERRUN_ENG_EVENT_7		466
+#define CMDQ_MAX_HW_EVENT				512
+
+#endif
-- 
1.8.1.1.dirty

From osalvador at suse.de  Mon Apr 12 12:59:52 2021
From: osalvador at suse.de (Oscar Salvador)
Date: Mon, 12 Apr 2021 13:59:52 +0200
Subject: [PATCH V2 4/6] mm: Drop redundant
 ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
In-Reply-To: <1617259448-22529-5-git-send-email-anshuman.khandual@arm.com>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
 <1617259448-22529-5-git-send-email-anshuman.khandual@arm.com>
Message-ID: <20210412115952.GC27818@linux>

On Thu, Apr 01, 2021 at 12:14:06PM +0530, Anshuman Khandual wrote:
> ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION configs have duplicate definitions on
> platforms that subscribe them. Drop these reduntant definitions and instead
> just select them appropriately.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Michael Ellerman <mpe at ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> Cc: Paul Mackerras <paulus at samba.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: "H. Peter Anvin" <hpa at zytor.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: x86 at kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-mm at kvack.org
> Cc: linux-kernel at vger.kernel.org
> Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>

Hi Anshuman, 

X86 needs fixing, see below:

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 503d8b2e8676..10702ef1eb57 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -60,8 +60,10 @@ config X86
>  	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
>  	select ARCH_32BIT_OFF_T			if X86_32
>  	select ARCH_CLOCKSOURCE_INIT
> +	select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE && MIGRATION
>  	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
>  	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
> +	select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE

you need s/x86_64/X86_64/, otherwise we are left with no migration :-)

-- 
Oscar Salvador
SUSE L3


From sumit.garg at linaro.org  Mon Apr 12 13:01:13 2021
From: sumit.garg at linaro.org (Sumit Garg)
Date: Mon, 12 Apr 2021 17:31:13 +0530
Subject: [PATCH v5] arm64: Enable perf events based hard lockup detector
In-Reply-To: <CAFA6WYMqLMEG2s7OdNweQKkP0K2LZ575B1BVw-zfsg7_KBSM5Q@mail.gmail.com>
References: <20210330080615.21938-1-lecopzer.chen@mediatek.com>
 <20210330083218.22285-1-lecopzer.chen@mediatek.com>
 <CAFA6WYMqLMEG2s7OdNweQKkP0K2LZ575B1BVw-zfsg7_KBSM5Q@mail.gmail.com>
Message-ID: <CAFA6WYPXu8biPPim5EoQ1pi+w3APKm65tzfOvH4OSORZdJ6+8Q@mail.gmail.com>

Hi Will,

On Tue, 30 Mar 2021 at 18:00, Sumit Garg <sumit.garg at linaro.org> wrote:
>
> On Tue, 30 Mar 2021 at 14:07, Lecopzer Chen <lecopzer.chen at mediatek.com> wrote:
> >
> > > > Hi Will, Mark,
> > > >
> > > > On Fri, 15 Jan 2021 at 17:32, Sumit Garg <sumit.garg at linaro.org> wrote:
> > > > >
> > > > > With the recent feature added to enable perf events to use pseudo NMIs
> > > > > as interrupts on platforms which support GICv3 or later, its now been
> > > > > possible to enable hard lockup detector (or NMI watchdog) on arm64
> > > > > platforms. So enable corresponding support.
> > > > >
> > > > > One thing to note here is that normally lockup detector is initialized
> > > > > just after the early initcalls but PMU on arm64 comes up much later as
> > > > > device_initcall(). So we need to re-initialize lockup detection once
> > > > > PMU has been initialized.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg at linaro.org>
> > > > > ---
> > > > >
> > > > > Changes in v5:
> > > > > - Fix lockup_detector_init() invocation to be rather invoked from CPU
> > > > >   binded context as it makes heavy use of per-cpu variables and shouldn't
> > > > >   be invoked from preemptible context.
> > > > >
> > > >
> > > > Do you have any further comments on this?
> > > >

Since there aren't any further comments, can you re-pick this feature for 5.13?

-Sumit

> > > > Lecopzer,
> > > >
> > > > Does this feature work fine for you now?
> > >
> > > This really fixes the warning, I have a real hardware for testing this now.
>
> Thanks for the testing. I assume it as an implicit Tested-by.
>
> > > but do we need to call lockup_detector_init() for each cpu?
> > >
> > > In init/main.c, it's only called by cpu 0 for once.
> >
> > Oh sorry, I just misread the code, please ignore previous mail.
> >
>
> No worries.
>
> -Sumit
>
> >
> > BRs,
> > Lecopzer


From qii.wang at mediatek.com  Mon Apr 12 13:03:14 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Mon, 12 Apr 2021 20:03:14 +0800
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <20210407181936.GA1614@kunai>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
 <20210406194856.GF3122@kunai> <1617797706.32076.1.camel@mhfsdcap03>
 <20210407181936.GA1614@kunai>
Message-ID: <1618228994.32225.3.camel@mhfsdcap03>

On Wed, 2021-04-07 at 20:19 +0200, Wolfram Sang wrote:
> > Due to clock stretch, our HW IP cannot meet the ac-timing
> > spec(tSU;STA,tSU;STO). 
> > There isn't a same delay for clock stretching, so we need pass a
> > parameter which can be found through measurement to meet most
> > conditions.
> 
> What about using this existing binding?
> 
> - i2c-scl-internal-delay-ns
>         Number of nanoseconds the IP core additionally needs to setup SCL.
> 

I can't see the relationship between "i2c-scl-falling-time-ns" and clock
stretching, is there a parameter related to clock stretching?
If you think both of them will affect the ac-timing of SCL, at this
point, "i2c-scl-falling-time-ns" maybe a good choice.


From ruifeng.zhang0110 at gmail.com  Mon Apr 12 13:20:26 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Mon, 12 Apr 2021 20:20:26 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <87y2dnn3gw.mognet@arm.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
Message-ID: <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>

Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??7:32???
>
>
> Hi,
>
> On 12/04/21 15:08, Ruifeng Zhang wrote:
> > From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
> >
> > The arm topology still parse from the MPIDR, but it is incomplete.  When
> > the armv8.3 cpu runs in aarch32 mode, it will parse out the wrong topology.
> >
> > armv7 (A7) mpidr is:
> > [11:8]      [7:2]       [1:0]
> > cluster     reserved    cpu
> >
> > armv8.3 (A55) mpidr is:
> > [23:16]     [15:8]      [7:0]
> > cluster     cpu         thread
> >
> > For compatibility to keep the function of get capacity from default
> > cputype, renamed arm parse_dt_topology to get_cputype_capacity and delete
> > related logic of parse from dt.
> > Arm using the same parse_dt_topology function as arm64.
> >
> > The arm device boot step is to look for the default cputype and get cpu
> > capacity firstly. Then parse the topology and capacity from dt to replace
> > default values.
> >
>
> I'm afraid I don't get it.
>
> CONFIG_COMPAT lets you run 32-bit stuff at EL0, but the kernel is still
> arm64. So if you take your armv8.3 system, the topology parsed by the
> kernel will be the same regardless of CONFIG_COMPAT.
>
> Could you elaborate on what problem you are trying to fix here?

There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
The MPIDR has been written to the chip register in armv8.3 format.
For example,
core0: 0000000080000000
core1: 0000000080000100
core2: 0000000080000200
...

Its cpu topology can be parsed normally on aarch64 mode (both
userspace and kernel work on arm64).

The problem is when it working on aarch32 mode (both userspace and
kernel work on arm 32-bit), the cpu topology
will parse error because of the format is different between armv7 and armv8.3.
The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
and store to the topology with armv7,
and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.

In addition, I think arm should also allow customers to configure cpu
topologies via DT.


From mike.leach at linaro.org  Mon Apr 12 13:25:01 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Mon, 12 Apr 2021 13:25:01 +0100
Subject: [PATCH v6 07/10] coresight: etm4x: Add complex configuration
 handlers to etmv4
In-Reply-To: <CAJ9a7Vh23-nFNRdQQZY4s4fGD8xhnE+PQUAE0US8fpsr-ZnsRQ@mail.gmail.com>
References: <20210409103722.26290-1-mike.leach@linaro.org>
 <20210409103722.26290-8-mike.leach@linaro.org>
 <97d53224-0749-086b-b2b4-12c91ec8ad5a@arm.com>
 <CAJ9a7Vh23-nFNRdQQZY4s4fGD8xhnE+PQUAE0US8fpsr-ZnsRQ@mail.gmail.com>
Message-ID: <CAJ9a7VjE3qy9ir=NdHp4_yMn79GnjXZ8w-QW0yQ5T_3WOeXGLw@mail.gmail.com>

HI Suzuki

OK - realized that this is an aarch32 kernel thing on closer
inspection of the kernel test robot info.  Now have a reproducer so
can fix

Thanks

Mike

On Mon, 12 Apr 2021 at 12:29, Mike Leach <mike.leach at linaro.org> wrote:
>
> HI Suzuki,
>
> On Mon, 12 Apr 2021 at 11:28, Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
> >
> > On 09/04/2021 11:37, Mike Leach wrote:
> > > Adds in handlers to allow the ETMv4 to use the complex configuration
> > > support. Features and configurations can be loaded and selected in the
> > > device.
> > >
> > > Signed-off-by: Mike Leach <mike.leach at linaro.org>
> > > Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> > > ---
> > >   drivers/hwtracing/coresight/Makefile          |   3 +-
> > >   .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
> > >   .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
> > >   .../coresight/coresight-etm4x-core.c          |  38 +++-
> > >   .../coresight/coresight-etm4x-sysfs.c         |   3 +
> > >   5 files changed, 238 insertions(+), 3 deletions(-)
> > >   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > >   create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> > >
> > > diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> > > index 63ecfc3cf66d..9420d33b23ac 100644
> > > --- a/drivers/hwtracing/coresight/Makefile
> > > +++ b/drivers/hwtracing/coresight/Makefile
> > > @@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
> > >   coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
> > >                    coresight-etm3x-sysfs.o
> > >   obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
> > > -coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
> > > +coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
> > > +                     coresight-etm4x-cfg.o
> > >   obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> > >   obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
> > >   obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > > new file mode 100644
> > > index 000000000000..d2ea903231b2
> > > --- /dev/null
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
> > > @@ -0,0 +1,182 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> > > + * Author: Mike Leach <mike.leach at linaro.org>
> > > + */
> > > +
> >
> > > +#include "coresight-etm4x.h"
> > > +#include "coresight-etm4x-cfg.h"
> > > +#include "coresight-priv.h"
> > > +#include "coresight-syscfg.h"
> > > +
> > > +/* defines to associate register IDs with driver data locations */
> > > +#define CHECKREG(cval, elem) \
> > > +     { \
> > > +             if (offset == cval) { \
> > > +                     reg_csdev->driver_regval = &drvcfg->elem; \
> > > +                     err = 0; \
> > > +                     break; \
> > > +             } \
> > > +     }
> > > +
> > > +#define CHECKREGIDX(cval, elem, off_idx, mask)       \
> > > +     { \
> > > +             if (mask == cval) { \
> > > +                     reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
> > > +                     err = 0; \
> > > +                     break; \
> > > +             } \
> > > +     }
> > > +
> > > +/**
> > > + * etm4_cfg_map_reg_offset - validate and map the register offset into a
> > > + *                        location in the driver config struct.
> > > + *
> > > + * Limits the number of registers that can be accessed and programmed in
> > > + * features, to those which are used to control the trace capture parameters.
> > > + *
> > > + * Omits or limits access to those which the driver must use exclusively.
> > > + *
> > > + * Invalid offsets will result in fail code return and feature load failure.
> > > + *
> > > + * @drvdata: driver data to map into.
> > > + * @reg:     register to map.
> > > + * @offset:  device offset for the register
> > > + */
> > > +static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
> > > +                                struct cscfg_regval_csdev *reg_csdev, u32 offset)
> > > +{
> > > +     int err = -EINVAL, idx;
> > > +     struct etmv4_config *drvcfg = &drvdata->config;
> > > +     u32 off_mask;
> > > +
> > > +     if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
> > > +         ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
> > > +         ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
> > > +             do {
> > > +                     CHECKREG(TRCEVENTCTL0R, eventctrl0);
> > > +                     CHECKREG(TRCEVENTCTL1R, eventctrl1);
> > > +                     CHECKREG(TRCSTALLCTLR, stall_ctrl);
> > > +                     CHECKREG(TRCTSCTLR, ts_ctrl);
> > > +                     CHECKREG(TRCSYNCPR, syncfreq);
> > > +                     CHECKREG(TRCCCCTLR, ccctlr);
> > > +                     CHECKREG(TRCBBCTLR, bb_ctrl);
> > > +                     CHECKREG(TRCVICTLR, vinst_ctrl);
> > > +                     CHECKREG(TRCVIIECTLR, viiectlr);
> > > +                     CHECKREG(TRCVISSCTLR, vissctlr);
> > > +                     CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
> > > +                     CHECKREG(TRCSEQRSTEVR, seq_rst);
> > > +                     CHECKREG(TRCSEQSTR, seq_state);
> > > +                     CHECKREG(TRCEXTINSELR, ext_inp);
> > > +                     CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
> > > +                     CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
> > > +                     CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
> > > +                     CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
> > > +             } while (0);
> > > +     } else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
> > > +             /* sequencer state control registers */
> > > +             idx = (offset & GENMASK(3, 0)) / 4;
> > > +             if (idx < ETM_MAX_SEQ_STATES) {
> > > +                     reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
> > > +                     err = 0;
> > > +             }
> > > +     } else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
> > > +             /* 32 bit, 8 off indexed register sets */
> > > +             idx = (offset & GENMASK(4, 0)) / 4;
> > > +             off_mask =  (offset & GENMASK(11, 5));
> > > +             do {
> > > +                     CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
> > > +                     CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
> > > +                     CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
> > > +             } while (0);
> > > +     } else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
> > > +             /* 64 bit, 8 off indexed register sets */
> > > +             idx = (offset & GENMASK(5, 0)) / 8;
> > > +             off_mask = (offset & GENMASK(11, 6));
> > > +             do {
> > > +                     CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
> > > +                     CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
> > > +             } while (0);
> > > +     } else if ((offset >= TRCRSCTLRn(2)) &&
> > > +                (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
> > > +             /* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
> > > +             idx = (offset & GENMASK(6, 0)) / 4;
> > > +             if (idx < ETM_MAX_RES_SEL) {
> > > +                     reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
> > > +                     err = 0;
> > > +             }
> > > +     } else if ((offset >= TRCACVRn(0)) &&
> > > +                (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
> > > +             /* 64 bit addr cmp regs, 16 off */
> > > +             idx = (offset & GENMASK(6, 0)) / 8;
> > > +             off_mask = offset & GENMASK(11, 7);
> > > +             do {
> > > +                     CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
> > > +                     CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
> > > +             } while (0);
> > > +     } else if ((offset >= TRCCNTRLDVRn(0)) &&
> > > +                (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
> > > +             /* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
> > > +             idx = (offset &  GENMASK(3, 0)) / 4;
> > > +             off_mask = offset &  GENMASK(11, 4);
> > > +             do {
> > > +                     CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
> > > +                     CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
> > > +                     CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
> > > +             } while (0);
> > > +     }
> > > +     return err;
> > > +}
> > > +
> > > +/**
> > > + * etm4_cfg_load_feature - load a feature into a device instance.
> > > + *
> > > + * @csdev:   An ETMv4 CoreSight device.
> > > + * @feat:    The feature to be loaded.
> > > + *
> > > + * The function will load a feature instance into the device, checking that
> > > + * the register definitions are valid for the device.
> > > + *
> > > + * Parameter and register definitions will be converted into internal
> > > + * structures that are used to set the values in the driver when the
> > > + * feature is enabled for the device.
> > > + *
> > > + * The feature spinlock pointer is initialised to the same spinlock
> > > + * that the driver uses to protect the internal register values.
> > > + */
> > > +static int etm4_cfg_load_feature(struct coresight_device *csdev,
> > > +                              struct cscfg_feature_csdev *feat_csdev)
> > > +{
> > > +     struct device *dev = csdev->dev.parent;
> > > +     struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
> > > +     const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
> > > +     u32 offset;
> > > +     int i = 0, err = 0;
> > > +
> > > +     /*
> > > +      * essential we set the device spinlock - this is used in the generic
> > > +      * programming routines when copying values into the drvdata structures
> > > +      * via the pointers setup in etm4_cfg_map_reg_offset().
> > > +      */
> > > +     feat_csdev->drv_spinlock = &drvdata->spinlock;
> > > +
> > > +     /* process the register descriptions */
> > > +     for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
> > > +             offset = feat_desc->regs_desc[i].offset;
> > > +             err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
> > > +     }
> > > +     return err;
> > > +}
> > > +
> > > +/* match information when loading configurations */
> > > +#define CS_CFG_ETM4_MATCH_FLAGS      (CS_CFG_MATCH_CLASS_SRC_ALL | \
> > > +                              CS_CFG_MATCH_CLASS_SRC_ETM4)
> > > +
> > > +int etm4_cscfg_register(struct coresight_device *csdev)
> > > +{
> > > +     struct cscfg_csdev_feat_ops ops;
> > > +
> > > +     ops.load_feat = &etm4_cfg_load_feature;
> > > +
> > > +     return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
> > > +}
> > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> > > new file mode 100644
> > > index 000000000000..a204ad9a4792
> > > --- /dev/null
> > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
> > > @@ -0,0 +1,15 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
> > > + */
> > > +
> > > +#ifndef _CORESIGHT_ETM4X_CFG_H
> > > +#define _CORESIGHT_ETM4X_CFG_H
> >
> >
> > Looks like this must be guarded by the CONFIG_CORESIGHT_SOURCE_ETM4X to
> > prevent the build failures on arm, as reported by the test robot.
> >
>
> The test robot was complaining about
> #include <asm/sysregs.h>
> in the next patch and not this one. I haven't seen any issues reported
> with this patch.
>
> Moreover - if this is required - then removing the ETM4 module from
> the config - i.e. not defining CONFIG_CORESIGHT_SOURCE_ETM4X - should
> trigger the error. I have done a clean build, without ETM4 and the
> error does not occur. (I also tried out gcc 9 in case this was a
> factor - it was not)
>
> I have to confess I am completely puzzled by this - how can this
> include only trigger an issue with my patch when it has been in the
> source for some time, and the same header (coresight-etm4x.h) is
> included without apparent problems elsewhere in the coresight build.
>
> Without a reliable reproducer, or a credible explanation, I can only
> assume that this is an issue with the test robot itself.
>
> I am open to further suggestions!
>
> Thanks
>
> Mike
>
>
> > #ifdef CONFIG_CORESIGHT_SOURCE_ETM4X
> >
> > > +
> > > +#include "coresight-config.h"
> > > +#include "coresight-etm4x.h"
> > > +
> > > +/* ETMv4 specific config functions */
> > > +int etm4_cscfg_register(struct coresight_device *csdev);
> > > +
> >
> > endif /* ETM4X */
> >
> > Cheers
> > Suzuki
> >
>
>
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From linus.walleij at linaro.org  Mon Apr 12 13:25:34 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 12 Apr 2021 14:25:34 +0200
Subject: [PATCH] ARM: dts: ux500: Drop drdy pin assignment from magnetometer
Message-ID: <20210412122534.1632306-1-linus.walleij@linaro.org>

This magnetometer can not select which line provided the outgoing
IRQ so drop it, the DT bindings will complain too.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi b/arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi
index 70f058352efc..2293b529f1f4 100644
--- a/arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi
+++ b/arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi
@@ -92,7 +92,6 @@ accelerometer at 19 {
 			};
 			magnetometer at 1e {
 				compatible = "st,lsm303dlm-magn";
-				st,drdy-int-pin = <1>;
 				reg = <0x1e>;
 				vdd-supply = <&ab8500_ldo_aux1_reg>;
 				vddio-supply = <&db8500_vsmps2_reg>;
-- 
2.29.2



From u.kleine-koenig at pengutronix.de  Mon Apr 12 13:35:02 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 12 Apr 2021 14:35:02 +0200
Subject: [PATCH 3/4] pwm: Add Aspeed ast2600 PWM support
In-Reply-To: <20210412095457.15095-4-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-4-billy_tsai@aspeedtech.com>
Message-ID: <20210412123502.v77fvmi3awvbmduu@pengutronix.de>

Hello Billy,

On Mon, Apr 12, 2021 at 05:54:56PM +0800, Billy Tsai wrote:
> This patch add the support of PWM controller which can find at aspeed
> ast2600 soc chip. This controller supoorts up to 16 channels.
> 
> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> ---
>  drivers/pwm/pwm-aspeed-g6.c | 291 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 291 insertions(+)
>  create mode 100644 drivers/pwm/pwm-aspeed-g6.c
> 
> diff --git a/drivers/pwm/pwm-aspeed-g6.c b/drivers/pwm/pwm-aspeed-g6.c
> new file mode 100644
> index 000000000000..4bb4f97453c6
> --- /dev/null
> +++ b/drivers/pwm/pwm-aspeed-g6.c
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) ASPEED Technology Inc.

Don't you need to add a year here?

> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 or later as
> + * published by the Free Software Foundation.

Hmm, the comment and the SPDX-License-Identifier contradict each other.
The idea of the latter is that the former isn't needed.

> + */

Is there documentation available in the internet for this hardware? If
yes, please mention a link here.

Also describe the hardware here similar to how e.g.
drivers/pwm/pwm-sifive.c does it. Please stick to the same format for
easy grepping.

> +
> +#include <linux/clk.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/sysfs.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/pwm.h>
> +/* The channel number of Aspeed pwm controller */
> +#define ASPEED_NR_PWMS 16
> +/* PWM Control Register */
> +#define ASPEED_PWM_CTRL_CH(ch) ((ch * 0x10) + 0x00)

#define ASPEED_PWM_CTRL_CH(ch) (((ch) * 0x10) + 0x00)

> +#define PWM_LOAD_SEL_AS_WDT BIT(19)
> +#define LOAD_SEL_FALLING 0
> +#define LOAD_SEL_RIGING 1
> +#define PWM_DUTY_LOAD_AS_WDT_EN BIT(18)
> +#define PWM_DUTY_SYNC_DIS BIT(17)
> +#define PWM_CLK_ENABLE BIT(16)
> +#define PWM_LEVEL_OUTPUT BIT(15)
> +#define PWM_INVERSE BIT(14)
> +#define PWM_OPEN_DRAIN_EN BIT(13)
> +#define PWM_PIN_EN BIT(12)
> +#define PWM_CLK_DIV_H_SHIFT 8
> +#define PWM_CLK_DIV_H_MASK (0xf << PWM_CLK_DIV_H_SHIFT)
> +#define PWM_CLK_DIV_L_SHIFT 0
> +#define PWM_CLK_DIV_L_MASK (0xff << PWM_CLK_DIV_L_SHIFT)
> +/* PWM Duty Cycle Register */
> +#define ASPEED_PWM_DUTY_CYCLE_CH(ch) ((ch * 0x10) + 0x04)
> +#define PWM_PERIOD_SHIFT (24)
> +#define PWM_PERIOD_MASK (0xff << PWM_PERIOD_SHIFT)
> +#define PWM_POINT_AS_WDT_SHIFT (16)
> +#define PWM_POINT_AS_WDT_MASK (0xff << PWM_POINT_AS_WDT_SHIFT)
> +#define PWM_FALLING_POINT_SHIFT (8)
> +#define PWM_FALLING_POINT_MASK (0xffff << PWM_FALLING_POINT_SHIFT)
> +#define PWM_RISING_POINT_SHIFT (0)
> +#define PWM_RISING_POINT_MASK (0xffff << PWM_RISING_POINT_SHIFT)
> +/* PWM default value */
> +#define DEFAULT_PWM_PERIOD 0xff
> +#define DEFAULT_TARGET_PWM_FREQ 25000
> +#define DEFAULT_DUTY_PT 10
> +#define DEFAULT_WDT_RELOAD_DUTY_PT 16

You could spend a few empty lines to make this better readable. Also
please use a consistent driver-specific prefix for your defines and
consider using the macros from <linux/bitfield.h>. Also defines
for bitfields should contain the register name.

> +struct aspeed_pwm_data {
> +	struct pwm_chip chip;
> +	struct regmap *regmap;
> +	unsigned long clk_freq;
> +	struct reset_control *reset;
> +};
> +/**
> + * struct aspeed_pwm - per-PWM driver data
> + * @freq: cached pwm freq
> + */
> +struct aspeed_pwm {
> +	u32 freq;
> +};

This is actually unused, please drop it. (You save a value in it, but
make never use of it.)

> +static void aspeed_set_pwm_channel_enable(struct regmap *regmap, u8 pwm_channel,
> +					  bool enable)
> +{
> +	regmap_update_bits(regmap, ASPEED_PWM_CTRL_CH(pwm_channel),
> +			   (PWM_CLK_ENABLE | PWM_PIN_EN),
> +			   enable ? (PWM_CLK_ENABLE | PWM_PIN_EN) : 0);

What is the semantic of PIN_EN?

> +}
> +/*
> + * The PWM frequency = HCLK(200Mhz) / (clock division L bit *
> + * clock division H bit * (period bit + 1))
> + */
> +static void aspeed_set_pwm_freq(struct aspeed_pwm_data *priv,
> +				struct pwm_device *pwm, u32 freq)
> +{
> +	u32 target_div, cal_freq;
> +	u32 tmp_div_h, tmp_div_l, diff, min_diff = INT_MAX;
> +	u32 div_h = BIT(5) - 1, div_l = BIT(8) - 1;
> +	u8 div_found;
> +	u32 index = pwm->hwpwm;
> +	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
> +
> +	cal_freq = priv->clk_freq / (DEFAULT_PWM_PERIOD + 1);
> +	target_div = DIV_ROUND_UP(cal_freq, freq);
> +	div_found = 0;
> +	/* calculate for target frequence */

s/frequence/frequency/

> +	for (tmp_div_h = 0; tmp_div_h < 0x10; tmp_div_h++) {
> +		tmp_div_l = target_div / BIT(tmp_div_h) - 1;
> +
> +		if (tmp_div_l < 0 || tmp_div_l > 255)
> +			continue;
> +
> +		diff = freq - cal_freq / (BIT(tmp_div_h) * (tmp_div_l + 1));
> +		if (abs(diff) < abs(min_diff)) {
> +			min_diff = diff;
> +			div_l = tmp_div_l;
> +			div_h = tmp_div_h;
> +			div_found = 1;
> +			if (diff == 0)
> +				break;
> +		}
> +	}

If my understanding is right (i.e. H divides by a power of two and L by
an integer) this can be simplified.

> +	if (div_found == 0) {
> +		pr_debug("target freq: %d too slow set minimal frequency\n",
> +			 freq);
> +	}
> +	channel->freq = cal_freq / (BIT(div_h) * (div_l + 1));
> +	pr_debug("div h %x, l : %x pwm out clk %d\n", div_h, div_l,
> +		 channel->freq);
> +	pr_debug("hclk %ld, target pwm freq %d, real pwm freq %d\n",
> +		 priv->clk_freq, freq, channel->freq);
> +
> +	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index),
> +			   (PWM_CLK_DIV_H_MASK | PWM_CLK_DIV_L_MASK),
> +			   (div_h << PWM_CLK_DIV_H_SHIFT) |
> +				   (div_l << PWM_CLK_DIV_L_SHIFT));
> +}
> +
> +static void aspeed_set_pwm_duty(struct aspeed_pwm_data *priv,
> +				struct pwm_device *pwm, u32 duty_pt)
> +{
> +	u32 index = pwm->hwpwm;
> +
> +	if (duty_pt == 0) {
> +		aspeed_set_pwm_channel_enable(priv->regmap, index, false);
> +	} else {
> +		regmap_update_bits(priv->regmap,
> +				   ASPEED_PWM_DUTY_CYCLE_CH(index),
> +				   PWM_FALLING_POINT_MASK,
> +				   duty_pt << PWM_FALLING_POINT_SHIFT);
> +		aspeed_set_pwm_channel_enable(priv->regmap, index, true);
> +	}
> +}
> +
> +static void aspeed_set_pwm_polarity(struct aspeed_pwm_data *priv,
> +				    struct pwm_device *pwm, u8 polarity)
> +{
> +	u32 index = pwm->hwpwm;
> +
> +	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index), PWM_INVERSE,
> +			   (polarity) ? PWM_INVERSE : 0);
> +}
> +
> +static int aspeed_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct device *dev = chip->dev;
> +	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
> +	struct aspeed_pwm *channel;
> +	u32 index = pwm->hwpwm;
> +	/*
> +	 * Fixed the period to the max value and rising point to 0
> +	 * for high resolution and simplified frequency calculation.

s/^H//

> +	 */
> +	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
> +			   PWM_PERIOD_MASK,
> +			   DEFAULT_PWM_PERIOD << PWM_PERIOD_SHIFT);
> +
> +	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
> +			   PWM_RISING_POINT_MASK, 0);

Only .apply is supposed to modify the PWM's configuration.

> +	channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
> +	if (!channel)
> +		return -ENOMEM;

Don't use devm_kzalloc if freeing isn't done at device cleanup time.

> +	pwm_set_chip_data(pwm, channel);
> +
> +	return 0;

> +}
> +
> +static void aspeed_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct device *dev = chip->dev;
> +	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
> +
> +	devm_kfree(dev, channel);
> +}
> +
> +static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			    const struct pwm_state *state)
> +{
> +	struct device *dev = chip->dev;
> +	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);

Please consider using

	priv = container_of(chip, struct aspeed_pwm_data, chip);

(preferably wrapped in a macro) which is more type safe and more
effective to calculate.

> +	struct pwm_state *cur_state = &pwm->state;
> +	u32 freq = DIV_ROUND_UP_ULL(1000000000, state->period);
> +	u32 duty_pt = DIV_ROUND_UP_ULL(
> +		state->duty_cycle * (DEFAULT_PWM_PERIOD + 1), state->period);

You're loosing precision here.

> +	dev_dbg(dev, "freq: %d, duty_pt: %d", freq, duty_pt);
> +	if (state->enabled) {
> +		aspeed_set_pwm_freq(priv, pwm, freq);
> +		aspeed_set_pwm_duty(priv, pwm, duty_pt);
> +		aspeed_set_pwm_polarity(priv, pwm, state->polarity);

How does the hardware behave between these calls? E.g. can it happen
that it already emits a normal period when inversed polarity is
requested just before aspeed_set_pwm_polarity is called? Or there is a
period with the previous duty cycle and the new period?

> +	} else {
> +		aspeed_set_pwm_duty(priv, pwm, 0);
> +	}
> +	cur_state->period = state->period;
> +	cur_state->duty_cycle = state->duty_cycle;
> +	cur_state->polarity = state->polarity;
> +	cur_state->enabled = state->enabled;

The driver is not supposed to modify pwm->state.

> +	return 0;
> +}

From your code I understood: The period of the signal is

	(PWM_PERIOD + 1) * (2 ** DIV_H) * (DIV_L + 1) / 200 MHz

. The duty cycle is

	PWM_FALLING_POINT * (2 ** DIV_H) * (DIV_L + 1) / 200 MHz

. So the PWM cannot provide a 100% relative duty cycle.

Is this right?

> +static const struct pwm_ops aspeed_pwm_ops = {
> +	.request = aspeed_pwm_request,
> +	.free = aspeed_pwm_free,
> +	.apply = aspeed_pwm_apply,

Please test your driver with PWM_DEBUG enabled.

> +	.owner = THIS_MODULE,
> +};
> +
> +static int aspeed_pwm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct clk *clk;
> +	int ret;
> +	struct aspeed_pwm_data *priv;
> +	struct device_node *np;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	np = pdev->dev.parent->of_node;
> +	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach")) {
> +		dev_err(dev, "unsupported pwm device binding\n");
> +		return -ENODEV;
> +	}

Is this pwm-tach an mfd?

> +	priv->regmap = syscon_node_to_regmap(np);
> +	if (IS_ERR(priv->regmap)) {
> +		dev_err(dev, "Couldn't get regmap\n");
> +		return -ENODEV;
> +	}
> +
> +	clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(clk))
> +		return -ENODEV;
> +	priv->clk_freq = clk_get_rate(clk);

If you intend to use this clock, you have to enable it.

> +	priv->reset = reset_control_get_shared(&pdev->dev, NULL);
> +	if (IS_ERR(priv->reset)) {
> +		dev_err(&pdev->dev, "can't get aspeed_pwm_tacho reset\n");
> +		return PTR_ERR(priv->reset);
> +	}
> +	reset_control_deassert(priv->reset);

missing error checking

> +	priv->chip.dev = dev;
> +	priv->chip.ops = &aspeed_pwm_ops;
> +	priv->chip.base = -1;

This isn't necessary since f9a8ee8c8bcd118e800d88772c6457381db45224,
please drop the assignment to base.

> +	priv->chip.npwm = ASPEED_NR_PWMS;
> +	priv->chip.of_xlate = of_pwm_xlate_with_flags;
> +	priv->chip.of_pwm_n_cells = 3;
> +
> +	ret = pwmchip_add(&priv->chip);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);

Please use %pe to make the error messages better readable.

> +		return ret;
> +	}
> +	dev_set_drvdata(dev, priv);
> +	return ret;
> +}
> +
> +static const struct of_device_id of_pwm_match_table[] = {
> +	{
> +		.compatible = "aspeed,ast2600-pwm",
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, of_pwm_match_table);
> +
> +static struct platform_driver aspeed_pwm_driver = {
> +	.probe		= aspeed_pwm_probe,

Please implement a .remove callback.

> +	.driver		= {
> +		.name	= "aspeed_pwm",
> +		.of_match_table = of_pwm_match_table,
> +	},
> +};

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/20210412/ca4bed52/attachment.sig>

From Eugen.Hristev at microchip.com  Mon Apr 12 13:37:41 2021
From: Eugen.Hristev at microchip.com (Eugen.Hristev at microchip.com)
Date: Mon, 12 Apr 2021 12:37:41 +0000
Subject: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc
 driver
In-Reply-To: <20210405155105.162529-31-eugen.hristev@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-31-eugen.hristev@microchip.com>
Message-ID: <a22c2065-1a79-8a96-2b54-a2e28fa08b8a@microchip.com>

On 4/5/21 6:51 PM, Eugen Hristev wrote:
> Add driver for the extended variant of the isc, the microchip XISC
> present on sama7g5 product.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
> Changes in v2:
> - adapted to new fwnode subdev style API, as in kernel 5.12.
> my old code was based on 5.10 style API.
> 
>   drivers/media/platform/Makefile               |   1 +
>   drivers/media/platform/atmel/Kconfig          |  11 +
>   drivers/media/platform/atmel/Makefile         |   2 +
>   drivers/media/platform/atmel/atmel-isc-base.c |   2 +-
>   drivers/media/platform/atmel/atmel-isc-regs.h |  26 +
>   .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
>   6 files changed, 684 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c
> 
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index eedc14aafb32..73ce083c2fc6 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)		+= rcar-vin/
>   
>   obj-$(CONFIG_VIDEO_ATMEL_ISC)		+= atmel/
>   obj-$(CONFIG_VIDEO_ATMEL_ISI)		+= atmel/
> +obj-$(CONFIG_VIDEO_ATMEL_XISC)		+= atmel/
>   
>   obj-$(CONFIG_VIDEO_STM32_DCMI)		+= stm32/
>   
> diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
> index 1850fe7f9360..99b51213f871 100644
> --- a/drivers/media/platform/atmel/Kconfig
> +++ b/drivers/media/platform/atmel/Kconfig
> @@ -12,6 +12,17 @@ config VIDEO_ATMEL_ISC
>   	   This module makes the ATMEL Image Sensor Controller available
>   	   as a v4l2 device.
>   
> +config VIDEO_ATMEL_XISC
> +	tristate "ATMEL eXtended Image Sensor Controller (XISC) support"
> +	depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
> +	depends on ARCH_AT91 || COMPILE_TEST
> +	select VIDEOBUF2_DMA_CONTIG
> +	select REGMAP_MMIO
> +	select V4L2_FWNODE
> +	help
> +	   This module makes the ATMEL eXtended Image Sensor Controller
> +	   available as a v4l2 device.
> +
>   config VIDEO_ATMEL_ISI
>   	tristate "ATMEL Image Sensor Interface (ISI) support"
>   	depends on VIDEO_V4L2 && OF
> diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile
> index 2dba38994a70..c5c01556c653 100644
> --- a/drivers/media/platform/atmel/Makefile
> +++ b/drivers/media/platform/atmel/Makefile
> @@ -1,5 +1,7 @@
>   # SPDX-License-Identifier: GPL-2.0-only
>   atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o
> +atmel-xisc-objs = atmel-sama7g5-isc.o atmel-isc-base.o
>   
>   obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
>   obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
> +obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel-xisc.o
> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
> index f30493a1dccd..d6409406ce2f 100644
> --- a/drivers/media/platform/atmel/atmel-isc-base.c
> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
> @@ -592,7 +592,7 @@ static int isc_configure(struct isc_device *isc)
>   	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
>   	       ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW |
>   	       ISC_PFE_CFG0_MODE_MASK | ISC_PFE_CFG0_CCIR_CRC |
> -		   ISC_PFE_CFG0_CCIR656;
> +	       ISC_PFE_CFG0_CCIR656 | ISC_PFE_CFG0_MIPI;
>   
>   	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
>   
> diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
> index 5f99bf7717c1..d06b72228d4f 100644
> --- a/drivers/media/platform/atmel/atmel-isc-regs.h
> +++ b/drivers/media/platform/atmel/atmel-isc-regs.h
> @@ -26,6 +26,7 @@
>   #define ISC_PFE_CFG0_PPOL_LOW   BIT(2)
>   #define ISC_PFE_CFG0_CCIR656    BIT(9)
>   #define ISC_PFE_CFG0_CCIR_CRC   BIT(10)
> +#define ISC_PFE_CFG0_MIPI	BIT(14)
>   
>   #define ISC_PFE_CFG0_MODE_PROGRESSIVE   (0x0 << 4)
>   #define ISC_PFE_CFG0_MODE_MASK          GENMASK(6, 4)
> @@ -184,6 +185,8 @@
>   /* ISC Gamma Correction Control Register */
>   #define ISC_GAM_CTRL    0x00000094
>   
> +#define ISC_GAM_CTRL_BIPART	BIT(4)
> +
>   /* ISC_Gamma Correction Blue Entry Register */
>   #define ISC_GAM_BENTRY	0x00000098
>   
> @@ -222,6 +225,8 @@
>   
>   /* Offset for CSC register specific to sama5d2 product */
>   #define ISC_SAMA5D2_CSC_OFFSET	0
> +/* Offset for CSC register specific to sama7g5 product */
> +#define ISC_SAMA7G5_CSC_OFFSET	0x11c
>   
>   /* Color Space Conversion Control Register */
>   #define ISC_CSC_CTRL    0x00000398
> @@ -246,6 +251,8 @@
>   
>   /* Offset for CBC register specific to sama5d2 product */
>   #define ISC_SAMA5D2_CBC_OFFSET	0
> +/* Offset for CBC register specific to sama7g5 product */
> +#define ISC_SAMA7G5_CBC_OFFSET	0x11c
>   
>   /* Contrast And Brightness Control Register */
>   #define ISC_CBC_CTRL    0x000003b4
> @@ -261,18 +268,30 @@
>   #define ISC_CBC_CONTRAST	0x000003c0
>   #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
>   
> +/* Hue Register */
> +#define ISC_CBCHS_HUE	0x4e0
> +/* Saturation Register */
> +#define ISC_CBCHS_SAT	0x4e4
> +
>   /* Offset for SUB422 register specific to sama5d2 product */
>   #define ISC_SAMA5D2_SUB422_OFFSET	0
> +/* Offset for SUB422 register specific to sama7g5 product */
> +#define ISC_SAMA7G5_SUB422_OFFSET	0x124
> +
>   /* Subsampling 4:4:4 to 4:2:2 Control Register */
>   #define ISC_SUB422_CTRL 0x000003c4
>   
>   /* Offset for SUB420 register specific to sama5d2 product */
>   #define ISC_SAMA5D2_SUB420_OFFSET	0
> +/* Offset for SUB420 register specific to sama7g5 product */
> +#define ISC_SAMA7G5_SUB420_OFFSET	0x124
>   /* Subsampling 4:2:2 to 4:2:0 Control Register */
>   #define ISC_SUB420_CTRL 0x000003cc
>   
>   /* Offset for RLP register specific to sama5d2 product */
>   #define ISC_SAMA5D2_RLP_OFFSET	0
> +/* Offset for RLP register specific to sama7g5 product */
> +#define ISC_SAMA7G5_RLP_OFFSET	0x124
>   /* Rounding, Limiting and Packing Configuration Register */
>   #define ISC_RLP_CFG     0x000003d0
>   
> @@ -303,6 +322,8 @@
>   
>   /* Offset for HIS register specific to sama5d2 product */
>   #define ISC_SAMA5D2_HIS_OFFSET	0
> +/* Offset for HIS register specific to sama7g5 product */
> +#define ISC_SAMA7G5_HIS_OFFSET	0x124
>   /* Histogram Control Register */
>   #define ISC_HIS_CTRL	0x000003d4
>   
> @@ -326,6 +347,8 @@
>   
>   /* Offset for DMA register specific to sama5d2 product */
>   #define ISC_SAMA5D2_DMA_OFFSET	0
> +/* Offset for DMA register specific to sama7g5 product */
> +#define ISC_SAMA7G5_DMA_OFFSET	0x13c
>   
>   /* DMA Configuration Register */
>   #define ISC_DCFG        0x000003e0
> @@ -376,11 +399,14 @@
>   
>   /* Offset for version register specific to sama5d2 product */
>   #define ISC_SAMA5D2_VERSION_OFFSET	0
> +#define ISC_SAMA7G5_VERSION_OFFSET	0x13c
>   /* Version Register */
>   #define ISC_VERSION	0x0000040c
>   
>   /* Offset for version register specific to sama5d2 product */
>   #define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
> +/* Offset for version register specific to sama7g5 product */
> +#define ISC_SAMA7G5_HIS_ENTRY_OFFSET	0x14c
>   /* Histogram Entry */
>   #define ISC_HIS_ENTRY	0x00000410
>   
> diff --git a/drivers/media/platform/atmel/atmel-sama7g5-isc.c b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
> new file mode 100644
> index 000000000000..9d2f0bbd8815
> --- /dev/null
> +++ b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
> @@ -0,0 +1,643 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Microchip eXtended Image Sensor Controller (XISC) driver
> + *
> + * Copyright (C) 2019-2021 Microchip Technology, Inc. and its subsidiaries
> + *
> + * Author: Eugen Hristev <eugen.hristev at microchip.com>
> + *
> + * Sensor-->PFE-->DPC-->WB-->CFA-->CC-->GAM-->VHXS-->CSC-->CBHS-->SUB-->RLP-->DMA-->HIS
> + *
> + * ISC video pipeline integrates the following submodules:
> + * PFE: Parallel Front End to sample the camera sensor input stream
> + * DPC: Defective Pixel Correction with black offset correction, green disparity
> + *      correction and defective pixel correction (3 modules total)
> + *  WB: Programmable white balance in the Bayer domain
> + * CFA: Color filter array interpolation module
> + *  CC: Programmable color correction
> + * GAM: Gamma correction
> + *VHXS: Vertical and Horizontal Scaler
> + * CSC: Programmable color space conversion
> + *CBHS: Contrast Brightness Hue and Saturation control
> + * SUB: This module performs YCbCr444 to YCbCr420 chrominance subsampling
> + * RLP: This module performs rounding, range limiting
> + *      and packing of the incoming data
> + * DMA: This module performs DMA master accesses to write frames to external RAM
> + * HIS: Histogram module performs statistic counters on the frames
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clkdev.h>
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/math64.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/videodev2.h>
> +
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-event.h>
> +#include <media/v4l2-image-sizes.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/v4l2-fwnode.h>
> +#include <media/v4l2-subdev.h>
> +#include <media/videobuf2-dma-contig.h>
> +
> +#include "atmel-isc-regs.h"
> +#include "atmel-isc.h"
> +
> +#define ISC_SAMA7G5_MAX_SUPPORT_WIDTH   3264
> +#define ISC_SAMA7G5_MAX_SUPPORT_HEIGHT  2464
> +
> +#define ISC_SAMA7G5_PIPELINE \
> +	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
> +	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
> +
> +void isc_sama7g5_config_csc(struct isc_device *isc);
> +void isc_sama7g5_config_cbc(struct isc_device *isc);
> +void isc_sama7g5_config_cc(struct isc_device *isc);
> +void isc_sama7g5_config_dpc(struct isc_device *isc);
> +void isc_sama7g5_config_gam(struct isc_device *isc);
> +void isc_sama7g5_config_rlp(struct isc_device *isc);
> +
> +void isc_sama7g5_adapt_pipeline(struct isc_device *isc);
> +
> +void isc_sama7g5_config_ctrls(struct isc_device *isc,
> +			      const struct v4l2_ctrl_ops *ops);
> +
> +/* This is a list of the formats that the ISC can *output* */
> +const struct isc_format sama7g5_controller_formats[] = {
> +	{
> +		.fourcc		= V4L2_PIX_FMT_ARGB444,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_ARGB555,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_RGB565,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_ABGR32,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_XBGR32,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_YUV420,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_UYVY,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_VYUY,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_YUYV,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_YUV422P,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_GREY,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_Y10,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_Y16,
> +	},
> +};
> +
> +/* This is a list of formats that the ISC can receive as *input* */
> +struct isc_format sama7g5_formats_list[] = {
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SBGGR8,
> +		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGBRG8,
> +		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGRBG8,
> +		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SRGGB8,
> +		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SBGGR10,
> +		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
> +		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGBRG10,
> +		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
> +		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGRBG10,
> +		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
> +		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SRGGB10,
> +		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
> +		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SBGGR12,
> +		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
> +		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGBRG12,
> +		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
> +		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SGRBG12,
> +		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
> +		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_SRGGB12,
> +		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
> +		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_GREY,
> +		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_YUYV,
> +		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_UYVY,
> +		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_RGB565,
> +		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
> +		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
> +	},
> +	{
> +		.fourcc		= V4L2_PIX_FMT_Y10,
> +		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
> +		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
> +	},
> +
> +};
> +
> +void isc_sama7g5_config_csc(struct isc_device *isc)
> +{
> +	struct regmap *regmap = isc->regmap;
> +
> +	/* Convert RGB to YUV */
> +	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
> +		     0x42 | (0x81 << 16));
> +	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
> +		     0x19 | (0x10 << 16));
> +	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
> +		     0xFDA | (0xFB6 << 16));
> +	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
> +		     0x70 | (0x80 << 16));
> +	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
> +		     0x70 | (0xFA2 << 16));
> +	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
> +		     0xFEE | (0x80 << 16));
> +}
> +
> +void isc_sama7g5_config_cbc(struct isc_device *isc)
> +{
> +	struct regmap *regmap = isc->regmap;
> +
> +	/* Configure what is set via v4l2 ctrls */
> +	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc, isc->ctrls.brightness);
> +	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc, isc->ctrls.contrast);
> +	/* Configure Hue and Saturation as neutral midpoint */
> +	regmap_write(regmap, ISC_CBCHS_HUE, 0);
> +	regmap_write(regmap, ISC_CBCHS_SAT, (1 << 4));
> +}
> +
> +void isc_sama7g5_config_cc(struct isc_device *isc)
> +{
> +	struct regmap *regmap = isc->regmap;
> +
> +	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
> +	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
> +	regmap_write(regmap, ISC_CC_RB_OR, 0);
> +	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
> +	regmap_write(regmap, ISC_CC_GB_OG, 0);
> +	regmap_write(regmap, ISC_CC_BR_BG, 0);
> +	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
> +}
> +
> +void isc_sama7g5_config_ctrls(struct isc_device *isc,
> +			      const struct v4l2_ctrl_ops *ops)
> +{
> +	struct isc_ctrls *ctrls = &isc->ctrls;
> +	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
> +
> +	ctrls->contrast = 16;
> +
> +	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 16);
> +}
> +
> +void isc_sama7g5_config_dpc(struct isc_device *isc)
> +{
> +	u32 bay_cfg = isc->config.sd_format->cfa_baycfg;
> +	struct regmap *regmap = isc->regmap;
> +
> +	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BLOFF_MASK,
> +			   (64 << ISC_DPC_CFG_BLOFF_SHIFT));
> +	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BAYCFG_MASK,
> +			   (bay_cfg << ISC_DPC_CFG_BAYCFG_SHIFT));
> +}
> +
> +void isc_sama7g5_config_gam(struct isc_device *isc)
> +{
> +	struct regmap *regmap = isc->regmap;
> +
> +	regmap_update_bits(regmap, ISC_GAM_CTRL, ISC_GAM_CTRL_BIPART,
> +			   ISC_GAM_CTRL_BIPART);
> +}
> +
> +void isc_sama7g5_config_rlp(struct isc_device *isc)
> +{
> +	struct regmap *regmap = isc->regmap;
> +	u32 rlp_mode = isc->config.rlp_cfg_mode;
> +
> +	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
> +			   ISC_RLP_CFG_MODE_MASK | ISC_RLP_CFG_LSH |
> +			   ISC_RLP_CFG_YMODE_MASK, rlp_mode);
> +}
> +
> +void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
> +{
> +	isc->try_config.bits_pipeline &= ISC_SAMA7G5_PIPELINE;
> +}
> +
> +/* Gamma table with gamma 1/2.2 */
> +const u32 isc_sama7g5_gamma_table[][GAMMA_ENTRIES] = {
> +	/* index 0 --> gamma bipartite */
> +	{
> +	      0x980,  0x4c0320,  0x650260,  0x7801e0,  0x8701a0,  0x940180,
> +	   0xa00160,  0xab0120,  0xb40120,  0xbd0120,  0xc60100,  0xce0100,
> +	   0xd600e0,  0xdd00e0,  0xe400e0,  0xeb00c0,  0xf100c0,  0xf700c0,
> +	   0xfd00c0, 0x10300a0, 0x10800c0, 0x10e00a0, 0x11300a0, 0x11800a0,
> +	  0x11d00a0, 0x12200a0, 0x12700a0, 0x12c0080, 0x13000a0, 0x1350080,
> +	  0x13900a0, 0x13e0080, 0x1420076, 0x17d0062, 0x1ae0054, 0x1d8004a,
> +	  0x1fd0044, 0x21f003e, 0x23e003a, 0x25b0036, 0x2760032, 0x28f0030,
> +	  0x2a7002e, 0x2be002c, 0x2d4002c, 0x2ea0028, 0x2fe0028, 0x3120026,
> +	  0x3250024, 0x3370024, 0x3490022, 0x35a0022, 0x36b0020, 0x37b0020,
> +	  0x38b0020, 0x39b001e, 0x3aa001e, 0x3b9001c, 0x3c7001c, 0x3d5001c,
> +	  0x3e3001c, 0x3f1001c, 0x3ff001a, 0x40c001a },
> +};
> +
> +static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
> +{
> +	struct device_node *np = dev->of_node;
> +	struct device_node *epn = NULL;
> +	struct isc_subdev_entity *subdev_entity;
> +	unsigned int flags;
> +	int ret;
> +	bool mipi_mode;
> +
> +	INIT_LIST_HEAD(&isc->subdev_entities);
> +
> +	mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
> +
> +	while (1) {
> +		struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
> +
> +		epn = of_graph_get_next_endpoint(np, epn);
> +		if (!epn)
> +			return 0;
> +
> +		ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
> +						 &v4l2_epn);
> +		if (ret) {
> +			ret = -EINVAL;
> +			dev_err(dev, "Could not parse the endpoint\n");
> +			break;
> +		}
> +
> +		subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
> +					     GFP_KERNEL);
> +		if (!subdev_entity) {
> +			ret = -ENOMEM;
> +			break;
> +		}
> +		subdev_entity->epn = epn;
> +
> +		flags = v4l2_epn.bus.parallel.flags;
> +
> +		if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> +			subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
> +
> +		if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
> +
> +		if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
> +
> +		if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
> +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
> +					ISC_PFE_CFG0_CCIR656;

Hi Jacopo,

If I use the bus-type property for the 'port' , do I actually have to 
change something here ?
the v4l2_epn.bus_type won't be set automatically ? by the endpoint 
parser I mean.

Thanks,
Eugen

> +
> +		if (mipi_mode)
> +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
> +
> +		list_add_tail(&subdev_entity->list, &isc->subdev_entities);
> +	}
> +	of_node_put(epn);
> +
> +	return ret;
> +}
> +
> +static int microchip_xisc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct isc_device *isc;
> +	struct resource *res;
> +	void __iomem *io_base;
> +	struct isc_subdev_entity *subdev_entity;
> +	int irq;
> +	int ret;
> +	u32 ver;
> +
> +	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
> +	if (!isc)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, isc);
> +	isc->dev = dev;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	io_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(io_base))
> +		return PTR_ERR(io_base);
> +
> +	isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
> +	if (IS_ERR(isc->regmap)) {
> +		ret = PTR_ERR(isc->regmap);
> +		dev_err(dev, "failed to init register map: %d\n", ret);
> +		return ret;
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0)
> +		return irq;
> +
> +	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
> +			       "microchip-sama7g5-xisc", isc);
> +	if (ret < 0) {
> +		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
> +			irq, ret);
> +		return ret;
> +	}
> +
> +	isc->gamma_table = isc_sama7g5_gamma_table;
> +	isc->gamma_max = 0;
> +
> +	isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
> +	isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
> +
> +	isc->config_dpc = isc_sama7g5_config_dpc;
> +	isc->config_csc = isc_sama7g5_config_csc;
> +	isc->config_cbc = isc_sama7g5_config_cbc;
> +	isc->config_cc = isc_sama7g5_config_cc;
> +	isc->config_gam = isc_sama7g5_config_gam;
> +	isc->config_rlp = isc_sama7g5_config_rlp;
> +	isc->config_ctrls = isc_sama7g5_config_ctrls;
> +
> +	isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
> +
> +	isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
> +	isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
> +	isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
> +	isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
> +	isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
> +	isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
> +	isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
> +	isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
> +	isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
> +
> +	isc->controller_formats = sama7g5_controller_formats;
> +	isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
> +	isc->formats_list = sama7g5_formats_list;
> +	isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
> +
> +	/* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
> +	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
> +
> +	ret = isc_pipeline_init(isc);
> +	if (ret)
> +		return ret;
> +
> +	isc->hclock = devm_clk_get(dev, "hclock");
> +	if (IS_ERR(isc->hclock)) {
> +		ret = PTR_ERR(isc->hclock);
> +		dev_err(dev, "failed to get hclock: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = clk_prepare_enable(isc->hclock);
> +	if (ret) {
> +		dev_err(dev, "failed to enable hclock: %d\n", ret);
> +		return ret;
> +	}
> +
> +	ret = isc_clk_init(isc);
> +	if (ret) {
> +		dev_err(dev, "failed to init isc clock: %d\n", ret);
> +		goto unprepare_hclk;
> +	}
> +
> +	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
> +
> +	ret = clk_prepare_enable(isc->ispck);
> +	if (ret) {
> +		dev_err(dev, "failed to enable ispck: %d\n", ret);
> +		goto unprepare_hclk;
> +	}
> +
> +	/* ispck should be greater or equal to hclock */
> +	ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
> +	if (ret) {
> +		dev_err(dev, "failed to set ispck rate: %d\n", ret);
> +		goto unprepare_clk;
> +	}
> +
> +	ret = v4l2_device_register(dev, &isc->v4l2_dev);
> +	if (ret) {
> +		dev_err(dev, "unable to register v4l2 device.\n");
> +		goto unprepare_clk;
> +	}
> +
> +	ret = xisc_parse_dt(dev, isc);
> +	if (ret) {
> +		dev_err(dev, "fail to parse device tree\n");
> +		goto unregister_v4l2_device;
> +	}
> +
> +	if (list_empty(&isc->subdev_entities)) {
> +		dev_err(dev, "no subdev found\n");
> +		ret = -ENODEV;
> +		goto unregister_v4l2_device;
> +	}
> +
> +	list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
> +		struct v4l2_async_subdev *asd;
> +
> +		v4l2_async_notifier_init(&subdev_entity->notifier);
> +
> +		asd = v4l2_async_notifier_add_fwnode_remote_subdev(
> +					&subdev_entity->notifier,
> +					of_fwnode_handle(subdev_entity->epn),
> +					struct v4l2_async_subdev);
> +
> +		of_node_put(subdev_entity->epn);
> +		subdev_entity->epn = NULL;
> +
> +		if (IS_ERR(asd)) {
> +			ret = PTR_ERR(asd);
> +			goto cleanup_subdev;
> +		}
> +
> +		subdev_entity->notifier.ops = &isc_async_ops;
> +
> +		ret = v4l2_async_notifier_register(&isc->v4l2_dev,
> +						   &subdev_entity->notifier);
> +		if (ret) {
> +			dev_err(dev, "fail to register async notifier\n");
> +			goto cleanup_subdev;
> +		}
> +
> +		if (video_is_registered(&isc->video_dev))
> +			break;
> +	}
> +
> +	pm_runtime_set_active(dev);
> +	pm_runtime_enable(dev);
> +	pm_request_idle(dev);
> +
> +	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
> +	dev_info(dev, "Microchip XISC version %x\n", ver);
> +
> +	return 0;
> +
> +cleanup_subdev:
> +	isc_subdev_cleanup(isc);
> +
> +unregister_v4l2_device:
> +	v4l2_device_unregister(&isc->v4l2_dev);
> +
> +unprepare_clk:
> +	clk_disable_unprepare(isc->ispck);
> +unprepare_hclk:
> +	clk_disable_unprepare(isc->hclock);
> +
> +	isc_clk_cleanup(isc);
> +
> +	return ret;
> +}
> +
> +static int microchip_xisc_remove(struct platform_device *pdev)
> +{
> +	struct isc_device *isc = platform_get_drvdata(pdev);
> +
> +	pm_runtime_disable(&pdev->dev);
> +
> +	isc_subdev_cleanup(isc);
> +
> +	v4l2_device_unregister(&isc->v4l2_dev);
> +
> +	clk_disable_unprepare(isc->ispck);
> +	clk_disable_unprepare(isc->hclock);
> +
> +	isc_clk_cleanup(isc);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused xisc_runtime_suspend(struct device *dev)
> +{
> +	struct isc_device *isc = dev_get_drvdata(dev);
> +
> +	clk_disable_unprepare(isc->ispck);
> +	clk_disable_unprepare(isc->hclock);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused xisc_runtime_resume(struct device *dev)
> +{
> +	struct isc_device *isc = dev_get_drvdata(dev);
> +	int ret;
> +
> +	ret = clk_prepare_enable(isc->hclock);
> +	if (ret)
> +		return ret;
> +
> +	ret = clk_prepare_enable(isc->ispck);
> +	if (ret)
> +		clk_disable_unprepare(isc->hclock);
> +
> +	return ret;
> +}
> +
> +static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
> +	SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
> +};
> +
> +static const struct of_device_id microchip_xisc_of_match[] = {
> +	{ .compatible = "microchip,sama7g5-isc" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
> +
> +static struct platform_driver microchip_xisc_driver = {
> +	.probe	= microchip_xisc_probe,
> +	.remove	= microchip_xisc_remove,
> +	.driver	= {
> +		.name		= "microchip-sama7g5-xisc",
> +		.pm		= &microchip_xisc_dev_pm_ops,
> +		.of_match_table = of_match_ptr(microchip_xisc_of_match),
> +	},
> +};
> +
> +module_platform_driver(microchip_xisc_driver);
> +
> +MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
> +MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
> +MODULE_LICENSE("GPL v2");
> +MODULE_SUPPORTED_DEVICE("video");
> 


From dietmar.eggemann at arm.com  Mon Apr 12 13:40:15 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Mon, 12 Apr 2021 14:40:15 +0200
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
Message-ID: <121d5639-b827-937f-1cf0-e6c256e306db@arm.com>

On 12/04/2021 14:20, Ruifeng Zhang wrote:
> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??7:32???
>>
>>
>> Hi,
>>
>> On 12/04/21 15:08, Ruifeng Zhang wrote:
>>> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>>>
>>> The arm topology still parse from the MPIDR, but it is incomplete.  When
>>> the armv8.3 cpu runs in aarch32 mode, it will parse out the wrong topology.
>>>
>>> armv7 (A7) mpidr is:
>>> [11:8]      [7:2]       [1:0]
>>> cluster     reserved    cpu
>>>
>>> armv8.3 (A55) mpidr is:
>>> [23:16]     [15:8]      [7:0]
>>> cluster     cpu         thread
>>>
>>> For compatibility to keep the function of get capacity from default
>>> cputype, renamed arm parse_dt_topology to get_cputype_capacity and delete
>>> related logic of parse from dt.
>>> Arm using the same parse_dt_topology function as arm64.
>>>
>>> The arm device boot step is to look for the default cputype and get cpu
>>> capacity firstly. Then parse the topology and capacity from dt to replace
>>> default values.
>>>
>>
>> I'm afraid I don't get it.
>>
>> CONFIG_COMPAT lets you run 32-bit stuff at EL0, but the kernel is still
>> arm64. So if you take your armv8.3 system, the topology parsed by the
>> kernel will be the same regardless of CONFIG_COMPAT.
>>
>> Could you elaborate on what problem you are trying to fix here?
> 
> There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> The MPIDR has been written to the chip register in armv8.3 format.
> For example,
> core0: 0000000080000000
> core1: 0000000080000100
> core2: 0000000080000200
> ...
> 
> Its cpu topology can be parsed normally on aarch64 mode (both
> userspace and kernel work on arm64).
> 
> The problem is when it working on aarch32 mode (both userspace and
> kernel work on arm 32-bit), the cpu topology
> will parse error because of the format is different between armv7 and armv8.3.
> The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> and store to the topology with armv7,
> and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
> 
> In addition, I think arm should also allow customers to configure cpu
> topologies via DT.

This patch ruins the CPU capacity detection based on capacity-dmips-mhz
(Documentation/devicetree/bindings/arm/cpu-capacity.txt) on my TC2 [L B
B L L] (armv7).

tip/sched/core with *mainline* multi_v7_defconfig:

root at linaro-nano:~# cat /sys/devices/system/cpu/cpu*/cpu_capacity
516
1024
1024
516
516

your patch with mainline multi_v7_defconfig:

root at linaro-nano:~#  cat /sys/devices/system/cpu/cpu*/cpu_capacity
1024
1024
1024
1024
1024


There are 2 capacity detection mechanism in arch/arm/kernel/topology.c:

(1) cpu_efficiency (only for armv7 a15 and a7) based, relies on
clock-frequency dt property

(2) capacity-dmips-mhz dt property based

I currently don't see how this different MPIDR layout leads to you code
changes.




From pali at kernel.org  Mon Apr 12 13:39:36 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Mon, 12 Apr 2021 14:39:36 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,
 pci-domain to zero
Message-ID: <20210412123936.25555-1-pali@kernel.org>

Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
function and allow to build it as module") PCIe controller driver for
Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
allows dynamic binding and unbinding of PCIe controller device.

Kernel PCI subsystem assigns by default dynamically allocated PCI domain
number (starting from zero) for this PCIe controller every time when device
is bound. So PCI domain changes after every unbind / bind operation.

Alternative way for assigning PCI domain number is to use static allocated
numbers defined in Device Tree. This option has requirement that every PCI
controller in system must have defined PCI bus number in Device Tree.

Armada 37xx has only one PCIe controller, so assign for it PCI domain 0 in
Device Tree.

After this change PCI domain on Armada 37xx is always zero, even after
repeated unbind and bind operations.

Signed-off-by: Pali Roh?r <pali at kernel.org>
Fixes: 526a76991b7b ("PCI: aardvark: Implement driver 'remove' function and allow to build it as module")
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 7a2df148c6a3..f02058ef5364 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -495,6 +495,7 @@
 					<0 0 0 2 &pcie_intc 1>,
 					<0 0 0 3 &pcie_intc 2>,
 					<0 0 0 4 &pcie_intc 3>;
+			linux,pci-domain = <0>;
 			max-link-speed = <2>;
 			phys = <&comphy1 0>;
 			pcie_intc: interrupt-controller {
-- 
2.20.1



From will at kernel.org  Mon Apr 12 13:42:12 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 12 Apr 2021 13:42:12 +0100
Subject: [PATCH] arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically
In-Reply-To: <20210409173710.18582-1-catalin.marinas@arm.com>
References: <20210409173710.18582-1-catalin.marinas@arm.com>
Message-ID: <161823112587.3590804.10679745971599326262.b4-ty@kernel.org>

On Fri, 9 Apr 2021 18:37:10 +0100, Catalin Marinas wrote:
> The entry from EL0 code checks the TFSRE0_EL1 register for any
> asynchronous tag check faults in user space and sets the
> TIF_MTE_ASYNC_FAULT flag. This is not done atomically, potentially
> racing with another CPU calling set_tsk_thread_flag().
> 
> Replace the non-atomic ORR+STR with an STSET instruction. While STSET
> requires ARMv8.1 and an assembler that understands LSE atomics, the MTE
> feature is part of ARMv8.5 and already requires an updated assembler.

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically
      https://git.kernel.org/arm64/c/2decad92f473

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From irui.wang at mediatek.com  Mon Apr 12 13:45:50 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:50 +0800
Subject: [PATCH v3,1/6] media: mtk-vcodec: venc: remove redundant code
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-2-irui.wang@mediatek.com>

From: Alexandre Courbot <acourbot at chromium.org>

vidioc_try_fmt() does clamp height and width when called on the OUTPUT
queue, so clamping them prior to calling this function is redundant. Set
the queue's parameters after calling vidioc_try_fmt() so we can use the
values it computed.

Signed-off-by: Alexandre Courbot <acourbot at chromium.org>
---
 .../media/platform/mtk-vcodec/mtk_vcodec_enc.c   | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 4831052f475d..42ff13867940 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -443,7 +443,6 @@ static int vidioc_venc_s_fmt_out(struct file *file, void *priv,
 	struct mtk_q_data *q_data;
 	int ret, i;
 	const struct mtk_video_fmt *fmt;
-	struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
 
 	vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
 	if (!vq) {
@@ -468,20 +467,13 @@ static int vidioc_venc_s_fmt_out(struct file *file, void *priv,
 		f->fmt.pix.pixelformat = fmt->fourcc;
 	}
 
-	pix_fmt_mp->height = clamp(pix_fmt_mp->height,
-				MTK_VENC_MIN_H,
-				MTK_VENC_MAX_H);
-	pix_fmt_mp->width = clamp(pix_fmt_mp->width,
-				MTK_VENC_MIN_W,
-				MTK_VENC_MAX_W);
-
-	q_data->visible_width = f->fmt.pix_mp.width;
-	q_data->visible_height = f->fmt.pix_mp.height;
-	q_data->fmt = fmt;
-	ret = vidioc_try_fmt(f, q_data->fmt);
+	ret = vidioc_try_fmt(f, fmt);
 	if (ret)
 		return ret;
 
+	q_data->fmt = fmt;
+	q_data->visible_width = f->fmt.pix_mp.width;
+	q_data->visible_height = f->fmt.pix_mp.height;
 	q_data->coded_width = f->fmt.pix_mp.width;
 	q_data->coded_height = f->fmt.pix_mp.height;
 
-- 
2.25.1

From irui.wang at mediatek.com  Mon Apr 12 13:45:49 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:49 +0800
Subject: [PATCH v3,0/6] Support H264 4K on MT8192
Message-ID: <20210412124555.26897-1-irui.wang@mediatek.com>

Add MT8192 H264 venc driver and support H264 4K encoding on MT8192.

Change notes:
v3: 1) This patch dependents on "Separating encoder device node"[1]
       which has already been in linux-next.
    2) redefine venc max supported resolution.
[1] https://lore.kernel.org/linux-mediatek/20210325122625.15100-1-irui.wang at mediatek.com

Alexandre Courbot (1):
  media: mtk-vcodec: venc: remove redundant code

Irui Wang (5):
  dt-bindings: media: mtk-vcodec: Add dma-ranges property
  media: mtk-vcodec: Support 4GB~8GB range iova space for venc
  dt-bindings: media: mtk-vcodec: Add binding for MT8192 VENC
  media: mtk-vcodec: Add MT8192 H264 venc driver
  media: mtk-vcodec: Support MT8192 H264 4K encoding

 .../bindings/media/mediatek-vcodec.txt        |  3 +
 .../platform/mtk-vcodec/mtk_vcodec_drv.h      |  1 +
 .../platform/mtk-vcodec/mtk_vcodec_enc.c      | 89 +++++++++++--------
 .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c  | 17 ++++
 .../platform/mtk-vcodec/venc/venc_h264_if.c   |  4 +
 5 files changed, 78 insertions(+), 36 deletions(-)

-- 
2.25.1

From irui.wang at mediatek.com  Mon Apr 12 13:45:51 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:51 +0800
Subject: [PATCH v3,
 2/6] dt-bindings: media: mtk-vcodec: Add dma-ranges property
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-3-irui.wang@mediatek.com>

The mt8192 iommu support 0~16GB iova. We separate it to four banks:
0~4G; 4G~8G; 8G~12G; 12G~16G.

The "dma-ranges" could be used to adjust the bank we locate.
If we don't set this property. The default range always is 0~4G.

Here we don't have actual bus/parent concept here.  And the iova
requirement is for our HW. Thus put the property in our node.

Signed-off-by: Irui Wang <irui.wang at mediatek.com>
---
 Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 06db6837cefd..b7801e3c354a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -22,6 +22,8 @@ Required properties:
 - iommus : should point to the respective IOMMU block with master port as
   argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
   for details.
+- dma-ranges : describes how the physical address space of the IOMMU maps
+  to memory.
 One of the two following nodes:
 - mediatek,vpu : the node of the video processor unit, if using VPU.
 - mediatek,scp : the node of the SCP unit, if using SCP.
-- 
2.25.1

From irui.wang at mediatek.com  Mon Apr 12 13:45:54 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:54 +0800
Subject: [PATCH v3,5/6] media: mtk-vcodec: Add MT8192 H264 venc driver
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-6-irui.wang@mediatek.com>

Add MT8192 venc driver's compatible and device private data.

Signed-off-by: Irui Wang <irui.wang at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  1 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index d03cca95e99b..14893d277bb8 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -302,6 +302,7 @@ struct mtk_vcodec_ctx {
 enum mtk_chip {
 	MTK_MT8173,
 	MTK_MT8183,
+	MTK_MT8192,
 };
 
 /**
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 26b089e81213..78f3dd166917 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -425,12 +425,26 @@ static const struct mtk_vcodec_enc_pdata mt8183_pdata = {
 	.core_id = VENC_SYS,
 };
 
+static const struct mtk_vcodec_enc_pdata mt8192_pdata = {
+	.chip = MTK_MT8192,
+	.uses_ext = true,
+	/* MT8192 supports the same capture formats as MT8183*/
+	.capture_formats = mtk_video_formats_capture_mt8183,
+	.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_mt8183),
+	/* MT8192 supports the same output formats as MT8173 */
+	.output_formats = mtk_video_formats_output_mt8173,
+	.num_output_formats = ARRAY_SIZE(mtk_video_formats_output_mt8173),
+	.min_bitrate = 64,
+	.max_bitrate = 100000000,
+	.core_id = VENC_SYS,
+};
 static const struct of_device_id mtk_vcodec_enc_match[] = {
 	{.compatible = "mediatek,mt8173-vcodec-enc",
 			.data = &mt8173_avc_pdata},
 	{.compatible = "mediatek,mt8173-vcodec-enc-vp8",
 			.data = &mt8173_vp8_pdata},
 	{.compatible = "mediatek,mt8183-vcodec-enc", .data = &mt8183_pdata},
+	{.compatible = "mediatek,mt8192-vcodec-enc", .data = &mt8192_pdata},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_vcodec_enc_match);
-- 
2.25.1

From irui.wang at mediatek.com  Mon Apr 12 13:45:55 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:55 +0800
Subject: [PATCH v3,6/6] media: mtk-vcodec: Support MT8192 H264 4K encoding
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-7-irui.wang@mediatek.com>

MT8192 H264 support 4k(3840x2176) and Level 5.1 encoding,
add related path according to enc_capability.

Signed-off-by: Irui Wang <irui.wang at mediatek.com>
---
 .../platform/mtk-vcodec/mtk_vcodec_enc.c      | 75 ++++++++++++-------
 .../platform/mtk-vcodec/venc/venc_h264_if.c   |  4 +
 2 files changed, 54 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 42ff13867940..7396a5050b45 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -19,23 +19,32 @@
 
 #define MTK_VENC_MIN_W	160U
 #define MTK_VENC_MIN_H	128U
-#define MTK_VENC_MAX_W	1920U
-#define MTK_VENC_MAX_H	1088U
+#define MTK_VENC_HD_MAX_W	1920U
+#define MTK_VENC_HD_MAX_H	1088U
+#define MTK_VENC_4K_MAX_W	3840U
+#define MTK_VENC_4K_MAX_H	2176U
+
 #define DFT_CFG_WIDTH	MTK_VENC_MIN_W
 #define DFT_CFG_HEIGHT	MTK_VENC_MIN_H
 #define MTK_MAX_CTRLS_HINT	20
 
 #define MTK_DEFAULT_FRAMERATE_NUM 1001
 #define MTK_DEFAULT_FRAMERATE_DENOM 30000
+#define MTK_VENC_4K_CAPABILITY_ENABLE BIT(0)
 
 static void mtk_venc_worker(struct work_struct *work);
 
-static const struct v4l2_frmsize_stepwise mtk_venc_framesizes = {
-	MTK_VENC_MIN_W, MTK_VENC_MAX_W, 16,
-	MTK_VENC_MIN_H, MTK_VENC_MAX_H, 16,
+static const struct v4l2_frmsize_stepwise mtk_venc_hd_framesizes = {
+	MTK_VENC_MIN_W, MTK_VENC_HD_MAX_W, 16,
+	MTK_VENC_MIN_H, MTK_VENC_HD_MAX_H, 16,
+};
+
+static const struct v4l2_frmsize_stepwise mtk_venc_4k_framesizes = {
+	MTK_VENC_MIN_W, MTK_VENC_4K_MAX_W, 16,
+	MTK_VENC_MIN_H, MTK_VENC_4K_MAX_H, 16,
 };
 
-#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_venc_framesizes)
+#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_venc_hd_framesizes)
 
 static int vidioc_venc_s_ctrl(struct v4l2_ctrl *ctrl)
 {
@@ -151,17 +160,20 @@ static int vidioc_enum_framesizes(struct file *file, void *fh,
 				  struct v4l2_frmsizeenum *fsize)
 {
 	const struct mtk_video_fmt *fmt;
+	struct mtk_vcodec_ctx *ctx = fh_to_ctx(fh);
 
 	if (fsize->index != 0)
 		return -EINVAL;
 
 	fmt = mtk_venc_find_format(fsize->pixel_format,
-				   fh_to_ctx(fh)->dev->venc_pdata);
+				   ctx->dev->venc_pdata);
 	if (!fmt)
 		return -EINVAL;
 
 	fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
-	fsize->stepwise = mtk_venc_framesizes;
+	fsize->stepwise =
+		(ctx->dev->enc_capability & MTK_VENC_4K_CAPABILITY_ENABLE) ?
+		mtk_venc_4k_framesizes : mtk_venc_hd_framesizes;
 
 	return 0;
 }
@@ -248,7 +260,7 @@ static struct mtk_q_data *mtk_venc_get_q_data(struct mtk_vcodec_ctx *ctx,
 /* V4L2 specification suggests the driver corrects the format struct if any of
  * the dimensions is unsupported
  */
-static int vidioc_try_fmt(struct v4l2_format *f,
+static int vidioc_try_fmt(struct mtk_vcodec_ctx *ctx, struct v4l2_format *f,
 			  const struct mtk_video_fmt *fmt)
 {
 	struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
@@ -260,13 +272,22 @@ static int vidioc_try_fmt(struct v4l2_format *f,
 		pix_fmt_mp->plane_fmt[0].bytesperline = 0;
 	} else if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		int tmp_w, tmp_h;
+		unsigned int max_width, max_height;
+
+		if (ctx->dev->enc_capability & MTK_VENC_4K_CAPABILITY_ENABLE) {
+			max_width = MTK_VENC_4K_MAX_W;
+			max_height = MTK_VENC_4K_MAX_H;
+		} else {
+			max_width = MTK_VENC_HD_MAX_W;
+			max_height = MTK_VENC_HD_MAX_H;
+		}
 
 		pix_fmt_mp->height = clamp(pix_fmt_mp->height,
 					MTK_VENC_MIN_H,
-					MTK_VENC_MAX_H);
+					max_height);
 		pix_fmt_mp->width = clamp(pix_fmt_mp->width,
 					MTK_VENC_MIN_W,
-					MTK_VENC_MAX_W);
+					max_width);
 
 		/* find next closer width align 16, heign align 32, size align
 		 * 64 rectangle
@@ -275,16 +296,16 @@ static int vidioc_try_fmt(struct v4l2_format *f,
 		tmp_h = pix_fmt_mp->height;
 		v4l_bound_align_image(&pix_fmt_mp->width,
 					MTK_VENC_MIN_W,
-					MTK_VENC_MAX_W, 4,
+					max_width, 4,
 					&pix_fmt_mp->height,
 					MTK_VENC_MIN_H,
-					MTK_VENC_MAX_H, 5, 6);
+					max_height, 5, 6);
 
 		if (pix_fmt_mp->width < tmp_w &&
-			(pix_fmt_mp->width + 16) <= MTK_VENC_MAX_W)
+			(pix_fmt_mp->width + 16) <= max_width)
 			pix_fmt_mp->width += 16;
 		if (pix_fmt_mp->height < tmp_h &&
-			(pix_fmt_mp->height + 32) <= MTK_VENC_MAX_H)
+			(pix_fmt_mp->height + 32) <= max_height)
 			pix_fmt_mp->height += 32;
 
 		mtk_v4l2_debug(0,
@@ -405,7 +426,7 @@ static int vidioc_venc_s_fmt_cap(struct file *file, void *priv,
 	}
 
 	q_data->fmt = fmt;
-	ret = vidioc_try_fmt(f, q_data->fmt);
+	ret = vidioc_try_fmt(ctx, f, q_data->fmt);
 	if (ret)
 		return ret;
 
@@ -467,7 +488,7 @@ static int vidioc_venc_s_fmt_out(struct file *file, void *priv,
 		f->fmt.pix.pixelformat = fmt->fourcc;
 	}
 
-	ret = vidioc_try_fmt(f, fmt);
+	ret = vidioc_try_fmt(ctx, f, fmt);
 	if (ret)
 		return ret;
 
@@ -545,7 +566,7 @@ static int vidioc_try_fmt_vid_cap_mplane(struct file *file, void *priv,
 	f->fmt.pix_mp.quantization = ctx->quantization;
 	f->fmt.pix_mp.xfer_func = ctx->xfer_func;
 
-	return vidioc_try_fmt(f, fmt);
+	return vidioc_try_fmt(ctx, f, fmt);
 }
 
 static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *priv,
@@ -567,7 +588,7 @@ static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *priv,
 		f->fmt.pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT;
 	}
 
-	return vidioc_try_fmt(f, fmt);
+	return vidioc_try_fmt(ctx, f, fmt);
 }
 
 static int vidioc_venc_g_selection(struct file *file, void *priv,
@@ -1171,16 +1192,16 @@ void mtk_vcodec_enc_set_default_params(struct mtk_vcodec_ctx *ctx)
 
 	v4l_bound_align_image(&q_data->coded_width,
 				MTK_VENC_MIN_W,
-				MTK_VENC_MAX_W, 4,
+				MTK_VENC_HD_MAX_W, 4,
 				&q_data->coded_height,
 				MTK_VENC_MIN_H,
-				MTK_VENC_MAX_H, 5, 6);
+				MTK_VENC_HD_MAX_H, 5, 6);
 
 	if (q_data->coded_width < DFT_CFG_WIDTH &&
-		(q_data->coded_width + 16) <= MTK_VENC_MAX_W)
+		(q_data->coded_width + 16) <= MTK_VENC_HD_MAX_W)
 		q_data->coded_width += 16;
 	if (q_data->coded_height < DFT_CFG_HEIGHT &&
-		(q_data->coded_height + 32) <= MTK_VENC_MAX_H)
+		(q_data->coded_height + 32) <= MTK_VENC_HD_MAX_H)
 		q_data->coded_height += 32;
 
 	q_data->sizeimage[0] =
@@ -1210,6 +1231,9 @@ int mtk_vcodec_enc_ctrls_setup(struct mtk_vcodec_ctx *ctx)
 {
 	const struct v4l2_ctrl_ops *ops = &mtk_vcodec_enc_ctrl_ops;
 	struct v4l2_ctrl_handler *handler = &ctx->ctrl_hdl;
+	const u8 h264_max_level =
+		(ctx->dev->enc_capability & MTK_VENC_4K_CAPABILITY_ENABLE) ?
+		V4L2_MPEG_VIDEO_H264_LEVEL_5_1 : V4L2_MPEG_VIDEO_H264_LEVEL_4_2;
 
 	v4l2_ctrl_handler_init(handler, MTK_MAX_CTRLS_HINT);
 
@@ -1240,8 +1264,9 @@ int mtk_vcodec_enc_ctrls_setup(struct mtk_vcodec_ctx *ctx)
 			V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
 			0, V4L2_MPEG_VIDEO_H264_PROFILE_HIGH);
 	v4l2_ctrl_new_std_menu(handler, ops, V4L2_CID_MPEG_VIDEO_H264_LEVEL,
-			V4L2_MPEG_VIDEO_H264_LEVEL_4_2,
-			0, V4L2_MPEG_VIDEO_H264_LEVEL_4_0);
+			       h264_max_level,
+			       0, V4L2_MPEG_VIDEO_H264_LEVEL_4_0);
+
 	if (handler->error) {
 		mtk_v4l2_err("Init control handler fail %d",
 				handler->error);
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index d0123dfc5f93..b6a4f2074fa5 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -215,6 +215,10 @@ static unsigned int h264_get_level(struct venc_h264_inst *inst,
 		return 41;
 	case V4L2_MPEG_VIDEO_H264_LEVEL_4_2:
 		return 42;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_5_0:
+		return 50;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_5_1:
+		return 51;
 	default:
 		mtk_vcodec_debug(inst, "unsupported level %d", level);
 		return 31;
-- 
2.25.1

From catalin.marinas at arm.com  Mon Apr 12 13:46:37 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 12 Apr 2021 13:46:37 +0100
Subject: ARM WFET application scenario consultation
In-Reply-To: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
References: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
Message-ID: <20210412124637.GE2060@arm.com>

On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> Recently, a new feature of WFE with timeouts has been added to ARMv8.
> I have some doubts about the application scenarios of this feature.
> 
> 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> thread using spinlock can't be sleep, if we use the wfet instruction, we
> can do nothing but wait when timeout,  so what's the difference between
> the two instructions in this scenario?

Not much point in using it it in a classic spinlock, unless you have
some specific implementation that's supposed to time out.

Note that we already enabled the event stream in Linux so that an event
is generated at 100KHz waking up any WFE. One reason we had for this was
some hardware errata where events between clusters were not generated.
Another was some small delays required in in certain user programs
without going through a kernel syscall, though not sure anyone's
actually using it.

> 2) Are there any other special scenarios where using wfet instructions
> can be beneficial ?

In the kernel we could replace our udelay loop with WFIT for example
(not WFET because of the event stream). As for user, we can expose a
HWCAP but it's up to user libraries to make use of it.

-- 
Catalin


From irui.wang at mediatek.com  Mon Apr 12 13:45:52 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:52 +0800
Subject: [PATCH v3,
 3/6] media: mtk-vcodec: Support 4GB~8GB range iova space for venc
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-4-irui.wang@mediatek.com>

Use the dma_set_mask_and_coherent helper to set venc
DMA bit mask to support 4GB~8GB range iova space.

Signed-off-by: Irui Wang <irui.wang at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 7d7b8cfc2cc5..26b089e81213 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -361,6 +361,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
 		goto err_event_workq;
 	}
 
+	if (of_get_property(pdev->dev.of_node, "dma-ranges", NULL))
+		dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(34));
+
 	ret = video_register_device(vfd_enc, VFL_TYPE_VIDEO, 1);
 	if (ret) {
 		mtk_v4l2_err("Failed to register video device");
-- 
2.25.1

From irui.wang at mediatek.com  Mon Apr 12 13:45:53 2021
From: irui.wang at mediatek.com (Irui Wang)
Date: Mon, 12 Apr 2021 20:45:53 +0800
Subject: [PATCH v3,
 4/6] dt-bindings: media: mtk-vcodec: Add binding for MT8192 VENC
In-Reply-To: <20210412124555.26897-1-irui.wang@mediatek.com>
References: <20210412124555.26897-1-irui.wang@mediatek.com>
Message-ID: <20210412124555.26897-5-irui.wang@mediatek.com>

Updates binding document for mt8192 encoder driver.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Irui Wang <irui.wang at mediatek.com>
---
 Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index b7801e3c354a..4171f8761322 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -9,6 +9,7 @@ Required properties:
   "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder.
   "mediatek,mt8183-vcodec-enc" for MT8183 encoder.
   "mediatek,mt8173-vcodec-dec" for MT8173 decoder.
+  "mediatek,mt8192-vcodec-enc" for MT8192 encoder.
 - reg : Physical base address of the video codec registers and length of
   memory mapped region.
 - interrupts : interrupt number to the cpu.
-- 
2.25.1

From u.kleine-koenig at pengutronix.de  Mon Apr 12 13:55:43 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 12 Apr 2021 14:55:43 +0200
Subject: [PATCH 1/4] dt-bindings: Add bindings for aspeed pwm-tach.
In-Reply-To: <20210412095457.15095-2-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-2-billy_tsai@aspeedtech.com>
Message-ID: <20210412125543.xhnitijeumddqdmn@pengutronix.de>

Hello,

On Mon, Apr 12, 2021 at 05:54:54PM +0800, Billy Tsai wrote:
> +  - Billy Tsai <billy_tasi at aspeedtech.com>

I object because the MTA at aspeedtech.com doesn't know this email
address.

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/20210412/a1762074/attachment.sig>

From johan at kernel.org  Mon Apr 12 14:08:14 2021
From: johan at kernel.org (Johan Hovold)
Date: Mon, 12 Apr 2021 15:08:14 +0200
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <YHRGPpQ03XgBMkiy@hovoldconsulting.com>

On Mon, Apr 12, 2021 at 05:31:38PM +0800, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
> spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.

This doesn't make much sense as console_write can be called in any
context. And where's the deadlock you claim to be fixing here?
 
> remove unused local_irq_save/restore call.
> 
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v2: remove unused code from stm32_usart_threaded_interrupt() according from
>     Greg's review.
> 
>  drivers/tty/serial/stm32-usart.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> index b3675cf25a69..b1ba5e36e36e 100644
> --- a/drivers/tty/serial/stm32-usart.c
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
>  	u32 old_cr1, new_cr1;
>  	int locked = 1;
>  
> -	local_irq_save(flags);
>  	if (port->sysrq)
>  		locked = 0;
>  	else if (oops_in_progress)
> -		locked = spin_trylock(&port->lock);
> +		locked = spin_trylock_irqsave(&port->lock, flags);
>  	else
> -		spin_lock(&port->lock);
> +		spin_lock_irqsave(&port->lock, flags);
>  
>  	/* Save and disable interrupts, enable the transmitter */
>  	old_cr1 = readl_relaxed(port->membase + ofs->cr1);
> @@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
>  	writel_relaxed(old_cr1, port->membase + ofs->cr1);
>  
>  	if (locked)
> -		spin_unlock(&port->lock);
> -	local_irq_restore(flags);
> +		spin_unlock_irqrestore(&port->lock, flags);
>  }
>  
>  static int stm32_usart_console_setup(struct console *co, char *options)

Johan


From maz at kernel.org  Mon Apr 12 14:09:10 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 14:09:10 +0100
Subject: ARM WFET application scenario consultation
In-Reply-To: <20210412124637.GE2060@arm.com>
References: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
 <20210412124637.GE2060@arm.com>
Message-ID: <878s5nodjd.wl-maz@kernel.org>

On Mon, 12 Apr 2021 13:46:37 +0100,
Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> > Recently, a new feature of WFE with timeouts has been added to ARMv8.
> > I have some doubts about the application scenarios of this feature.
> > 
> > 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> > thread using spinlock can't be sleep, if we use the wfet instruction, we
> > can do nothing but wait when timeout,  so what's the difference between
> > the two instructions in this scenario?
> 
> Not much point in using it it in a classic spinlock, unless you have
> some specific implementation that's supposed to time out.
> 
> Note that we already enabled the event stream in Linux so that an event
> is generated at 100KHz waking up any WFE. One reason we had for this was
> some hardware errata where events between clusters were not generated.
> Another was some small delays required in in certain user programs
> without going through a kernel syscall, though not sure anyone's
> actually using it.
> 
> > 2) Are there any other special scenarios where using wfet instructions
> > can be beneficial ?
> 
> In the kernel we could replace our udelay loop with WFIT for example
> (not WFET because of the event stream). As for user, we can expose a
> HWCAP but it's up to user libraries to make use of it.

Note that since c219bc4e9205K ("arm64: Trap WFI executed in
userspace"), we actively prevent WFI from being used in userspace, and
I would expect WFIT to be given the same treatment. It otherwise is a
precise tool for userspace to synchronise against kernel events.

Thanks,

	N,

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


From mhiramat at kernel.org  Mon Apr 12 14:11:44 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Mon, 12 Apr 2021 22:11:44 +0900
Subject: [PATCH] arm64: kprobes: Restore local irqflag if kprobes is
 cancelled
In-Reply-To: <20210412174101.6bfb0594@xhacker.debian>
References: <20210412174101.6bfb0594@xhacker.debian>
Message-ID: <20210412221144.2da50e902df14cda0d86eeaa@kernel.org>

Hi Jisheng,

On Mon, 12 Apr 2021 17:41:01 +0800
Jisheng Zhang <Jisheng.Zhang at synaptics.com> wrote:

> If instruction being single stepped caused a page fault, the kprobes
> is cancelled to let the page fault handler continue as a normal page
> fault. But the local irqflags are disabled so cpu will restore pstate
> with DAIF masked. After pagefault is serviced, the kprobes is
> triggerred again, we overwrite the saved_irqflag by calling
> kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
> irqflag. After kprobes is serviced, the cpu pstate is retored with
> DAIF masked.
> 
> This patch is inspired by one patch for riscv from Liao Chang.

Thanks for pointing it out. But I think kprobes_restore_local_irqflag()
is also needed for kcb->kprobe_status == KPROBE_REENTER case...no.
This is more complicated. In the reenter case, I think we have to retry
the kpreprobe_fault_handler() with recovered previous kprobes so that
it can handle page fault in its handler.

Hmm, RISC-V and other code also needs same fix.

Thank you,

> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
> ---
>  arch/arm64/kernel/probes/kprobes.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> index 66aac2881ba8..85645b2b0c7a 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/probes/kprobes.c
> @@ -267,10 +267,12 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
>  		if (!instruction_pointer(regs))
>  			BUG();
>  
> -		if (kcb->kprobe_status == KPROBE_REENTER)
> +		if (kcb->kprobe_status == KPROBE_REENTER) {
>  			restore_previous_kprobe(kcb);
> -		else
> +		} else {
> +			kprobes_restore_local_irqflag(kcb, regs);
>  			reset_current_kprobe();
> +		}
>  
>  		break;
>  	case KPROBE_HIT_ACTIVE:
> -- 
> 2.31.0
> 


-- 
Masami Hiramatsu <mhiramat at kernel.org>


From David.Laight at ACULAB.COM  Mon Apr 12 14:11:45 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 12 Apr 2021 13:11:45 +0000
Subject: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
In-Reply-To: <CAK8P3a1JZ=JerasdkntzX_ApaCF7C29ZS1E31aPQATOts0ZiLw@mail.gmail.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-6-hch@lst.de>
 <15be19af19174c7692dd795297884096@AcuMS.aculab.com>
 <5c3635a2b44a496b88d665e8686d9436@AcuMS.aculab.com>
 <CAK8P3a1JZ=JerasdkntzX_ApaCF7C29ZS1E31aPQATOts0ZiLw@mail.gmail.com>
Message-ID: <0bef075082b244d2b7a5a140336a40d5@AcuMS.aculab.com>

From: Arnd Bergmann
> Sent: 12 April 2021 12:26
> 
> On Mon, Apr 12, 2021 at 12:54 PM David Laight <David.Laight at aculab.com> wrote:
> > From: David Laight > Sent: 12 April 2021 10:37
> > ...
> > > I'm guessing that compat_pid_t is 16 bits?
> > > So the native 32bit version has an unnamed 2 byte structure pad.
> > > The 'packed' removes this pad from the compat structure.
> > >
> > > AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
> > > adding an explicit pad for the implicit pad the compiler
> > > would generate because compat_pid_t is 16 bits.
> >
> > I've just looked at the header.
> > compat_pid_t is 32 bits.
> > So Linux must have gained 32bit pids at some earlier time.
> > (Historically Unix pids were 16 bit - even on 32bit systems.)
> >
> > Which makes the explicit pad in 'sparc' rather 'interesting'.
> 
> I saw it was there since the sparc kernel support got merged in
> linux-1.3, possibly copied from an older sunos version.

Which had a 16bit pid when I used it.
So this is a bug in the sparc merge!

The explicit 'short' pad could be removed from the 64bit variant
because there are always 4 bytes of pad after l_pid.
But it does extend the application structure on 32bit sparc so must
remain in the uapi header.
It doesn't need to be in the 'compat' definition.

> > oh - compat_loff_t is only used in a couple of other places.
> > neither care in any way about the alignment.
> > (Provided get_user() doesn't fault on a 8n+4 aligned address.)
> 
> Ah right, I also see that after this series it's only used in to other
> places:  compat_resume_swap_area, which could also lose the
> __packed annotation,

That structure just defines 0 and 8, the structure size doesn't
matter and the offsets are 'passed to' get_user() so byte
accesses aren't performed.

> and in the declaration of
> compat_sys_sendfile64, where it makes no difference.

Which should probably use get_user() rather than copy_from_user().

Although some architectures may need fallback code for
misaligned get_user() ?
Or is there a general 'cop out' that structures passed to the
kernel are required to be correctly aligned.
They should be aligned unless the kernel is 'playing games'
like reading 'struct pollfd' as a 64bit item.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From catalin.marinas at arm.com  Mon Apr 12 14:11:13 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 12 Apr 2021 14:11:13 +0100
Subject: (subset) [PATCH v2 0/9] running kernel mode SIMD with softirqs
 disabled
In-Reply-To: <20210302090118.30666-1-ardb@kernel.org>
References: <20210302090118.30666-1-ardb@kernel.org>
Message-ID: <161822613829.4133.7312323262518323547.b4-ty@arm.com>

On Tue, 2 Mar 2021 10:01:09 +0100, Ard Biesheuvel wrote:
> [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
>   SIMD in kernel mode could reduce complexity and improve performance, but we
>   need to decide whether we can do this, and how much softirq processing
>   latency we can tolerate. If we can find a satisfactory solution for this,
>   we might do the same for x86 and 32-bit ARM as well.
> 
>   However, based on preliminary off-list discussions with peterz and luto, it
>   seems that for x86, there is a preference for using per-CPU buffers to
>   preserve/restore the task context's kernel mode SIMD state when the task is
>   interrupted to perform kernel mode SIMD in softirq context. On arm64, we
>   actually had this arrangement before, and removed it because it made
>   reasoning about preserving/restoring userland SVE state (32 SIMD registers
>   of up to 2 kbit in size) rather complex. ]
> 
> [...]

Applied to arm64 (for-next/neon-softirqs-disabled), thanks!

[1/9] arm64: assembler: remove conditional NEON yield macros
      https://git.kernel.org/arm64/c/27248fe1abb2
[2/9] arm64: assembler: introduce wxN aliases for wN registers
      https://git.kernel.org/arm64/c/4c4dcd3541f8
[3/9] arm64: fpsimd: run kernel mode NEON with softirqs disabled
      https://git.kernel.org/arm64/c/13150149aa6d

-- 
Catalin



From robin.murphy at arm.com  Mon Apr 12 14:12:20 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 12 Apr 2021 14:12:20 +0100
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com>
References: <20210409112035.27221-1-david@redhat.com>
 <CAK8P3a31uKNcim0n99=yt3zjZ+LQSw4V4+8PS8daLsBdS0iSYg@mail.gmail.com>
 <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com>
Message-ID: <34350446-0e0e-6947-40bd-fabdccdc835f@arm.com>

On 2021-04-09 14:39, David Hildenbrand wrote:
> On 09.04.21 15:35, Arnd Bergmann wrote:
>> On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand <david at redhat.com> 
>> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
>>> which depends on CMA, if possible; however, these drivers also have to
>>> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
>>> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
>>> driver cannot do it's job properly in some configurations.
>>>
>>> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and 
>>> DMA_CMA if
>>> available") documents
>>> ???????? While this is no build dependency, etnaviv will only work 
>>> correctly
>>> ???????? on most systems if CMA and DMA_CMA are enabled. Select both 
>>> options
>>> ???????? if available to avoid users ending up with a non-working GPU 
>>> due to
>>> ???????? a lacking kernel config.
>>> So etnaviv really wants to have DMA_CMA, however, can deal with some 
>>> cases
>>> where it is not available.
>>>
>>> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
>>> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
>>> of recursive dependency issues).
>>>
>>> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
>>> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
>>>
>>> With this change, distributions can disable CONFIG_CMA or
>>> CONFIG_DMA_CMA, without it silently getting enabled again by random
>>> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
>>> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
>>> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
>>> DRM_KMS_CMA_HELPER.
>>>
>>> For example, if any driver selects WANT_DMA_CMA and we do a
>>> "make olddefconfig":
>>>
>>> 1. With "# CONFIG_CMA is not set" and no specification of
>>> ??? "CONFIG_DMA_CMA"
>>>
>>> -> CONFIG_DMA_CMA won't be part of .config
>>>
>>> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
>>>
>>> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
>>> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
>>>
>>> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
>>>
>>> -> CONFIG_DMA_CMA will be removed from .config
>>>
>>> Note: drivers/remoteproc seems to be special; commit c51e882cd711
>>> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains 
>>> that
>>> there is a real dependency to DMA_CMA for it to work; leave that 
>>> dependency
>>> in place and don't convert it to a soft dependency.
>>
>> I don't think this dependency is fundamentally different from the others,
>> though davinci machines tend to have less memory than a lot of the
>> other machines, so it's more likely to fail without CMA.
>>
> 
> I was also unsure - and Lucas had similar thoughts. If you want, I can 
> send a v4 also taking care of this.

TBH I think it should all just be removed. DMA_CMA is effectively an 
internal feature of the DMA API, and drivers which simply use the DMA 
API shouldn't really be trying to assume *how* things might be allocated 
at runtime - CMA is hardly the only way. Platform-level assumptions 
about the presence or not of IOMMUs, memory carveouts, etc., and whether 
it even matters - e.g. a device with a tiny LCD may only need display 
buffers which still fit in a regular MAX_ORDER allocation - could go in 
platform-specific configs, but I really don't think they belong at the 
generic subsystem level.

We already have various examples like I2S drivers that won't even probe 
without a dmaengine provider being present, or host controller drivers 
which are useless without their corresponding phy driver (and I'm 
guessing you can probably also do higher-level things like include the 
block layer but omit all filesystem drivers). I don't believe it's 
Kconfig's job to try to guess whether a given configuration is *useful*, 
only to enforce that's it's valid to build.

Robin.


From arnd at kernel.org  Mon Apr 12 14:14:14 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 12 Apr 2021 15:14:14 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
Message-ID: <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>

On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:

> >
> > For this merge window, I don't think any of them are show-stoppers (Rob, let me
> > know if you disagree), but in the long run we may want to gradually enforce
> > a rule about not merging changes that introduce any new warnings, in order to
> > have a chance of cleaning up the existing ones.
>
> This may not be as simple as it sounds, as DT binding updates typically
> follow a different path than DTS(i) updates.  DT bindings updates may be
> picked up by a subsystem maintainer, by Rob, or by the platform
> maintainer.

I checked out the bindings from linux-next, which seems to have covered
most of these. Sometimes it pays off to be lazy and merge them after
everyone else.

> For trivial updates (e.g. adding a compatible value, and sometimes
> extending a limit), a DTS(i) update may be accepted by the platform
> maintainer before the corresponding DT binding update.  The latter may
> even be merged one or more kernel revisions later, especially when
> involving subsystems that are not traditionally rooted into platforms
> using DT.
>
> Of course we could mention any expected warning regressions in our pull
> requests for soc.

Right, that would certainly help. Some maintainers send all binding
updates both to the driver maintainers and to the soc tree, along
with the other changes that only go into one tree. That is of course
also more work on your side, but it solves the problem entirely.

> > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports:
> > 'port at 0' is a required property
>
> [...]
>
> I've replied to these as a response to your PR reply, see
> https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw at mail.gmail.com/

Ok, thanks.

      Arnd


From catalin.marinas at arm.com  Mon Apr 12 14:15:21 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 12 Apr 2021 14:15:21 +0100
Subject: ARM WFET application scenario consultation
In-Reply-To: <878s5nodjd.wl-maz@kernel.org>
References: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
 <20210412124637.GE2060@arm.com> <878s5nodjd.wl-maz@kernel.org>
Message-ID: <20210412131520.GF2060@arm.com>

On Mon, Apr 12, 2021 at 02:09:10PM +0100, Marc Zyngier wrote:
> On Mon, 12 Apr 2021 13:46:37 +0100,
> Catalin Marinas <catalin.marinas at arm.com> wrote:
> > 
> > On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> > > Recently, a new feature of WFE with timeouts has been added to ARMv8.
> > > I have some doubts about the application scenarios of this feature.
> > > 
> > > 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> > > thread using spinlock can't be sleep, if we use the wfet instruction, we
> > > can do nothing but wait when timeout,  so what's the difference between
> > > the two instructions in this scenario?
> > 
> > Not much point in using it it in a classic spinlock, unless you have
> > some specific implementation that's supposed to time out.
> > 
> > Note that we already enabled the event stream in Linux so that an event
> > is generated at 100KHz waking up any WFE. One reason we had for this was
> > some hardware errata where events between clusters were not generated.
> > Another was some small delays required in in certain user programs
> > without going through a kernel syscall, though not sure anyone's
> > actually using it.
> > 
> > > 2) Are there any other special scenarios where using wfet instructions
> > > can be beneficial ?
> > 
> > In the kernel we could replace our udelay loop with WFIT for example
> > (not WFET because of the event stream). As for user, we can expose a
> > HWCAP but it's up to user libraries to make use of it.
> 
> Note that since c219bc4e9205K ("arm64: Trap WFI executed in
> userspace"), we actively prevent WFI from being used in userspace, and
> I would expect WFIT to be given the same treatment. It otherwise is a
> precise tool for userspace to synchronise against kernel events.

I agree. I only thought about using it in the kernel as a simpler
udelay(). The user should not attempt WFI/WFIT.

Now, if KVM traps WFI/WFIT as well, maybe we should not bother with
udelay() in the kernel either.

-- 
Catalin


From david at redhat.com  Mon Apr 12 14:19:00 2021
From: david at redhat.com (David Hildenbrand)
Date: Mon, 12 Apr 2021 15:19:00 +0200
Subject: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft
 dependencies on DMA_CMA
In-Reply-To: <34350446-0e0e-6947-40bd-fabdccdc835f@arm.com>
References: <20210409112035.27221-1-david@redhat.com>
 <CAK8P3a31uKNcim0n99=yt3zjZ+LQSw4V4+8PS8daLsBdS0iSYg@mail.gmail.com>
 <53ec94ac-ffe3-d0bc-d081-3489fa03daa1@redhat.com>
 <34350446-0e0e-6947-40bd-fabdccdc835f@arm.com>
Message-ID: <e996ca72-7857-ba50-0e7e-f0c3dab3a931@redhat.com>

On 12.04.21 15:12, Robin Murphy wrote:
> On 2021-04-09 14:39, David Hildenbrand wrote:
>> On 09.04.21 15:35, Arnd Bergmann wrote:
>>> On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand <david at redhat.com>
>>> wrote:
>>>>
>>>> Random drivers should not override a user configuration of core knobs
>>>> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
>>>> which depends on CMA, if possible; however, these drivers also have to
>>>> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
>>>> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
>>>> driver cannot do it's job properly in some configurations.
>>>>
>>>> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and
>>>> DMA_CMA if
>>>> available") documents
>>>>  ???????? While this is no build dependency, etnaviv will only work
>>>> correctly
>>>>  ???????? on most systems if CMA and DMA_CMA are enabled. Select both
>>>> options
>>>>  ???????? if available to avoid users ending up with a non-working GPU
>>>> due to
>>>>  ???????? a lacking kernel config.
>>>> So etnaviv really wants to have DMA_CMA, however, can deal with some
>>>> cases
>>>> where it is not available.
>>>>
>>>> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
>>>> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
>>>> of recursive dependency issues).
>>>>
>>>> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
>>>> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
>>>>
>>>> With this change, distributions can disable CONFIG_CMA or
>>>> CONFIG_DMA_CMA, without it silently getting enabled again by random
>>>> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
>>>> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
>>>> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
>>>> DRM_KMS_CMA_HELPER.
>>>>
>>>> For example, if any driver selects WANT_DMA_CMA and we do a
>>>> "make olddefconfig":
>>>>
>>>> 1. With "# CONFIG_CMA is not set" and no specification of
>>>>  ??? "CONFIG_DMA_CMA"
>>>>
>>>> -> CONFIG_DMA_CMA won't be part of .config
>>>>
>>>> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
>>>>
>>>> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
>>>> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
>>>>
>>>> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
>>>>
>>>> -> CONFIG_DMA_CMA will be removed from .config
>>>>
>>>> Note: drivers/remoteproc seems to be special; commit c51e882cd711
>>>> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains
>>>> that
>>>> there is a real dependency to DMA_CMA for it to work; leave that
>>>> dependency
>>>> in place and don't convert it to a soft dependency.
>>>
>>> I don't think this dependency is fundamentally different from the others,
>>> though davinci machines tend to have less memory than a lot of the
>>> other machines, so it's more likely to fail without CMA.
>>>
>>
>> I was also unsure - and Lucas had similar thoughts. If you want, I can
>> send a v4 also taking care of this.
> 
> TBH I think it should all just be removed. DMA_CMA is effectively an
> internal feature of the DMA API, and drivers which simply use the DMA
> API shouldn't really be trying to assume *how* things might be allocated
> at runtime - CMA is hardly the only way. Platform-level assumptions
> about the presence or not of IOMMUs, memory carveouts, etc., and whether
> it even matters - e.g. a device with a tiny LCD may only need display
> buffers which still fit in a regular MAX_ORDER allocation - could go in
> platform-specific configs, but I really don't think they belong at the
> generic subsystem level.
> 
> We already have various examples like I2S drivers that won't even probe
> without a dmaengine provider being present, or host controller drivers
> which are useless without their corresponding phy driver (and I'm
> guessing you can probably also do higher-level things like include the
> block layer but omit all filesystem drivers). I don't believe it's
> Kconfig's job to try to guess whether a given configuration is *useful*,
> only to enforce that's it's valid to build.

That would mean: if it's not a built-time dependency, don't mention it 
in Kconfig.

If that were true, why do we have have defaults modeled in Kconfig then?

IMHO, some part of Kconfig is to give you sane defaults.

-- 
Thanks,

David / dhildenb



From erwan.leray at foss.st.com  Mon Apr 12 14:19:27 2021
From: erwan.leray at foss.st.com (Erwan LE RAY)
Date: Mon, 12 Apr 2021 15:19:27 +0200
Subject: [Linux-stm32] [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <YHPgGI6EmTzmVH7g@kroah.com>
 <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>
 <YHQEA9jn5uXQCtrN@kroah.com>
 <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>
Message-ID: <f3985d70-4f00-7442-de4e-e382b19e3e50@foss.st.com>

Hi Dillon,

Thanks for your patch.

Could you please elaborate the use case in your commit message ?

Best Regards, Erwan.

On 4/12/21 10:54 AM, dillon min wrote:
> Hi Greg,
> 
> On Mon, Apr 12, 2021 at 4:25 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>>
>> On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
>>> Hi Greg?
>>>
>>> Thanks for the quick response, please ignore the last private mail.
>>>
>>> On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>>>>
>>>> On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com wrote:
>>>>> From: dillon min <dillon.minfei at gmail.com>
>>>>>
>>>>> To avoid potential deadlock in spin_lock usage, change to use
>>>>> spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn) context.
>>>>> spin_lock(), spin_unlock() under handler context.
>>>>>
>>>>> remove unused local_irq_save/restore call.
>>>>>
>>>>> Signed-off-by: dillon min <dillon.minfei at gmail.com>
>>>>> ---
>>>>> Was verified on stm32f469-disco board. need more test on stm32mp platform.
>>>>>
>>>>>   drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
>>>>>   1 file changed, 17 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
>>>>> index b3675cf25a69..c4c859b34367 100644
>>>>> --- a/drivers/tty/serial/stm32-usart.c
>>>>> +++ b/drivers/tty/serial/stm32-usart.c
>>>>> @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>>>>>        struct tty_port *tport = &port->state->port;
>>>>>        struct stm32_port *stm32_port = to_stm32_port(port);
>>>>>        const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
>>>>> -     unsigned long c;
>>>>> +     unsigned long c, flags;
>>>>>        u32 sr;
>>>>>        char flag;
>>>>>
>>>>> @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>>>>>                uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>>>>>        }
>>>>>
>>>>> -     spin_unlock(&port->lock);
>>>>> +     if (threaded)
>>>>> +             spin_unlock_irqrestore(&port->lock, flags);
>>>>> +     else
>>>>> +             spin_unlock(&port->lock);
>>>>
>>>> You shouldn't have to check for this, see the other patches on the list
>>>> recently that fixed this up to not be an issue for irq handlers.
>>> Can you help to give more hints, or the commit id of the patch which
>>> fixed this. thanks.
>>>
>>> I'm still confused with this.
>>>
>>> The stm32_usart_threaded_interrupt() is a kthread context, once
>>> port->lock holds by this function, another serial interrupts raised,
>>> such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
>>> there will be a deadlock. isn't it?
>>>
>>>   So, shouldn't I use spin_lock{_irqsave} according to the caller's context ?
>>
>> Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
>> handlers") for when threaded irq handlers have irqs disabled, isn't that
>> the case you are trying to "protect" from here?
>>
>> Why is the "threaded" flag used at all?  The driver should not care.
>>
>> Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
>> threading") in linux-next for an example of how this was fixed up in a
>> serial driver.
>>
>> does that help?
>>
> Yes, it's really helpful. and 81e2073c175b should be highlighted in a doc.
> In my past knowledge, we should care about hard irq & thread_fn lock conflict.
> This patch has totally avoided patching code in the separate driver side.
> thanks.
> 
> I will just keep the changes in stm32_usart_console_write(), remove
> these code in
> thread_fn. update version 2 for you.
> 
> thanks.
> 
> Dillon,
>> thanks,
>>
>> greg k-h
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32 at st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
> 


From robh at kernel.org  Mon Apr 12 14:20:00 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 08:20:00 -0500
Subject: [RFC PATCH 1/3] dt-bindings: net: xilinx_axienet: convert
 bindings document to yaml
In-Reply-To: <1617992002-38028-2-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617992002-38028-2-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <1618233600.182122.3757970.nullmailer@robh.at.kernel.org>

On Fri, 09 Apr 2021 23:43:20 +0530, Radhey Shyam Pandey wrote:
> Convert the bindings document for Xilinx AXI Ethernet Subsystem
> from txt to yaml. No changes to existing binding description.
> 
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> Pending: Fix below remaining dt_binding_check warning:
> 
> ethernet at 40c00000: 'device_type' does not match any of
> the regexes: 'pinctrl-[0-9]+
> ---
>  .../devicetree/bindings/net/xilinx_axienet.txt     |  80 -----------
>  .../devicetree/bindings/net/xilinx_axienet.yaml    | 147 +++++++++++++++++++++
>  MAINTAINERS                                        |   1 +
>  3 files changed, 148 insertions(+), 80 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.txt
>  create mode 100644 Documentation/devicetree/bindings/net/xilinx_axienet.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/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.example.dt.yaml: ethernet at 40c00000: 'device_type' does not match any of the regexes: 'pinctrl-[0-9]+'
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/net/xilinx_axienet.yaml

See https://patchwork.ozlabs.org/patch/1464502

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Mon Apr 12 14:20:00 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 08:20:00 -0500
Subject: [PATCH v2 1/5] dt-bindings: display: mediatek,
 hdmi: Convert to use graph schema
In-Reply-To: <20210412093928.3321194-2-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
 <20210412093928.3321194-2-narmstrong@baylibre.com>
Message-ID: <1618233600.211900.3757977.nullmailer@robh.at.kernel.org>

On Mon, 12 Apr 2021 11:39:24 +0200, Neil Armstrong wrote:
> Update the mediatek,dpi binding to use the graph schema.
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  .../display/mediatek/mediatek,cec.yaml        |  51 +++++++
>  .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 ++++++++
>  .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
>  .../display/mediatek/mediatek,hdmi.yaml       | 131 +++++++++++++++++
>  4 files changed, 239 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.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/mediatek/mediatek,hdmi-ddc.example.dt.yaml:0:0: /example-0/i2c at 11012000: failed to match any schema with compatible: ['mediatek,mt8173-hdmi-ddc']
Documentation/devicetree/bindings/display/mediatek/mediatek,cec.example.dt.yaml:0:0: /example-0/cec at 10013000: failed to match any schema with compatible: ['mediatek,mt8173-cec']

See https://patchwork.ozlabs.org/patch/1465094

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Mon Apr 12 14:20:00 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 08:20:00 -0500
Subject: [PATCH v3 1/5] dt-bindings: pinctrl: mt8195: add pinctrl file and
 binding document
In-Reply-To: <20210411092659.22838-2-zhiyong.tao@mediatek.com>
References: <20210411092659.22838-1-zhiyong.tao@mediatek.com>
 <20210411092659.22838-2-zhiyong.tao@mediatek.com>
Message-ID: <1618233600.191242.3757973.nullmailer@robh.at.kernel.org>

On Sun, 11 Apr 2021 17:26:55 +0800, Zhiyong Tao wrote:
> 1. This patch adds pinctrl file for mt8195.
> 2. This patch adds mt8195 compatible node in binding document.
> 
> Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
> ---
>  .../bindings/pinctrl/pinctrl-mt8195.yaml      | 152 +++
>  include/dt-bindings/pinctrl/mt8195-pinfunc.h  | 962 ++++++++++++++++++
>  2 files changed, 1114 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
>  create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.example.dt.yaml: pinctrl at 10005000: reg: [[268455936, 4096], [298909696, 4096], [299040768, 4096], [299106304, 4096], [300023808, 4096], [300023808, 4096], [300613632, 4096], [301203456, 4096], [268480512, 4096]] is too long
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml

See https://patchwork.ozlabs.org/patch/1464777

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Mon Apr 12 14:20:00 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 08:20:00 -0500
Subject: [PATCH 2/4] dt-bindings: Add bindings for aspeed pwm
In-Reply-To: <20210412095457.15095-3-billy_tsai@aspeedtech.com>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-3-billy_tsai@aspeedtech.com>
Message-ID: <1618233600.223110.3757979.nullmailer@robh.at.kernel.org>

On Mon, 12 Apr 2021 17:54:55 +0800, Billy Tsai wrote:
> This patch adds device bindings for aspeed pwm device which should be
> the sub-node of aspeed,ast2600-pwm-tach.
> 
> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> ---
>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 47 +++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.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/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: Additional properties are not allowed ('pwm-cells' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: Additional properties are not allowed ('pwm-cells' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: ignoring, error in schema: 
warning: no schema found in file: ./Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.example.dt.yaml:0:0: /example-0/pwm_tach at 1e610000: failed to match any schema with compatible: ['aspeed,ast2600-pwm-tach', 'simple-mfd', 'syscon']
Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.example.dt.yaml:0:0: /example-0/pwm_tach at 1e610000/pwm at 0: failed to match any schema with compatible: ['aspeed,ast2600-pwm']

See https://patchwork.ozlabs.org/patch/1465116

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From liuqi115 at huawei.com  Mon Apr 12 14:34:30 2021
From: liuqi115 at huawei.com (liuqi (BA))
Date: Mon, 12 Apr 2021 21:34:30 +0800
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
 <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
 <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>
Message-ID: <9c577f11-46e7-55a0-95e8-6c3376077049@huawei.com>


Hi John,

Thanks for reviewing this.
On 2021/4/9 18:22, John Garry wrote:
> On 09/04/2021 10:05, Qi Liu wrote:
>> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
>> to sample bandwidth, latency, buffer occupation etc.
>>
>> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
>> registered as a PMU in /sys/bus/event_source/devices, so users can
>> select target PMU, and use filter to do further sets.
>>
>> Filtering options contains:
>> event??????? - select the event.
>> subevent???? - select the subevent.
>> port???????? - select target Root Ports. Information of Root Ports
>> ??????????????? are shown under sysfs.
>> bdf????????? - select requester_id of target EP device.
>> trig_len???? - set trigger condition for starting event statistics.
>> trigger_mode - set trigger mode. 0 means starting to statistic when
>> ??????????????? bigger than trigger condition, and 1 means smaller.
>> thr_len????? - set threshold for statistics.
>> thr_mode???? - set threshold mode. 0 means count when bigger than
>> ??????????????? threshold, and 1 means smaller.
>>
>> Signed-off-by: Qi Liu <liuqi115 at huawei.com>
>> ---
>> ? MAINTAINERS??????????????????????????????? |??? 6 +
>> ? drivers/perf/Kconfig?????????????????????? |??? 2 +
>> ? drivers/perf/Makefile????????????????????? |??? 1 +
>> ? drivers/perf/pci/Kconfig?????????????????? |?? 16 +
>> ? drivers/perf/pci/Makefile????????????????? |??? 2 +
>> ? drivers/perf/pci/hisilicon/Makefile??????? |??? 5 +
>> ? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1011 
>> ++++++++++++++++++++++++++++
>> ? include/linux/cpuhotplug.h???????????????? |??? 1 +
>> ? 8 files changed, 1044 insertions(+)
>> ? create mode 100644 drivers/perf/pci/Kconfig
>> ? create mode 100644 drivers/perf/pci/Makefile
>> ? create mode 100644 drivers/perf/pci/hisilicon/Makefile
>> ? create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 3353de0..46c7861 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8023,6 +8023,12 @@ W:??? http://www.hisilicon.com
>> ? F:??? Documentation/admin-guide/perf/hisi-pmu.rst
>> ? F:??? drivers/perf/hisilicon
>> +HISILICON PCIE PMU DRIVER
>> +M:??? Qi Liu <liuqi115 at huawei.com>
>> +S:??? Maintained
>> +F:??? Documentation/admin-guide/perf/hisi-pcie-pmu.rst
> 
> nit: this does not exist yet...
> 
thanks, I'll move this add-maintainer-part to the second patch.
>> +F:??? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> +
>> ? HISILICON QM AND ZIP Controller DRIVER
>> ? M:??? Zhou Wang <wangzhou1 at hisilicon.com>
>> ? L:??? linux-crypto at vger.kernel.org
>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
>> index 3075cf1..99d4760 100644
>> --- a/drivers/perf/Kconfig
>> +++ b/drivers/perf/Kconfig
>> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>> ? source "drivers/perf/hisilicon/Kconfig"
>> +source "drivers/perf/pci/Kconfig"
>> +
>> ? endmenu
>> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
>> index 5260b11..1208c08 100644
>> --- a/drivers/perf/Makefile
>> +++ b/drivers/perf/Makefile
>> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>> ? obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>> ? obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>> ? obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
>> +obj-y += pci/
>> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
>> new file mode 100644
>> index 0000000..a119486
>> --- /dev/null
>> +++ b/drivers/perf/pci/Kconfig
>> @@ -0,0 +1,16 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +#
>> +# PCIe Performance Monitor Drivers
>> +#
>> +menu "PCIe Performance Monitor"
>> +
>> +config HISI_PCIE_PMU
>> +??? tristate "HiSilicon PCIE PERF PMU"
>> +??? depends on ARM64 && PCI && HISI_PMU
> 
> What from HISI_PMU is needed? I couldn't find anything here
The event_sysfs_show() and format_sysfs_show() function of 
hisi_uncore_pmu.h can be reused in hisi_pcie_pmu.c, So I add path in 
Makefile and include "hisi_uncore_pmu.h".

> 
>> +??? help
>> +????? Provide support for HiSilicon PCIe performance monitoring unit 
>> (PMU)
>> +????? RCiEP devices.
>> +????? Adds the PCIe PMU into perf events system for monitoring latency,
>> +????? bandwidth etc.
>> +
>> +endmenu
>> diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
>> new file mode 100644
>> index 0000000..a56b1a9
>> --- /dev/null
>> +++ b/drivers/perf/pci/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +obj-y += hisilicon/
>> diff --git a/drivers/perf/pci/hisilicon/Makefile 
>> b/drivers/perf/pci/hisilicon/Makefile
>> new file mode 100644
>> index 0000000..6f99f52
>> --- /dev/null
>> +++ b/drivers/perf/pci/hisilicon/Makefile
>> @@ -0,0 +1,5 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +ccflags-y :=? -I $(srctree)/drivers/perf/hisilicon
>> +
>> +obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
>> diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c 
>> b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> new file mode 100644
>> index 0000000..ac0e444
>> --- /dev/null
>> +++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> @@ -0,0 +1,1011 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * This driver adds support for PCIe PMU RCiEP device. Related
>> + * perf events are bandwidth, bandwidth utilization, latency
>> + * etc.
>> + *
>> + * Copyright (C) 2021 HiSilicon Limited
>> + * Author: Qi Liu<liuqi115 at huawei.com>
>> + */
>> +#include <linux/bitfield.h>
>> +#include <linux/bitmap.h>
>> +#include <linux/bug.h>
>> +#include <linux/cpuhotplug.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/irq.h>
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/pci.h>
>> +#include <linux/perf_event.h>
>> +
>> +#include "hisi_uncore_pmu.h"
>> +
>> +/* Define registers */
>> +#define HISI_PCIE_GLOBAL_CTRL??????? 0x00
>> +#define HISI_PCIE_EVENT_CTRL??????? 0x010
>> +#define HISI_PCIE_CNT??????????? 0x090
>> +#define HISI_PCIE_EXT_CNT??????? 0x110
>> +#define HISI_PCIE_INT_STAT??????? 0x150
>> +#define HISI_PCIE_INT_MASK??????? 0x154
>> +#define HISI_PCIE_REG_BDF??????? 0xfe0
>> +#define HISI_PCIE_REG_VERSION??????? 0xfe4
>> +#define HISI_PCIE_REG_INFO??????? 0xfe8
>> +#define HISI_PCIE_REG_FREQ??????? 0xfec
>> +
>> +/* Define PCIE CTRL CMD */
>> +#define HISI_PCIE_GLOBAL_EN??????? 0x01
>> +#define HISI_PCIE_GLOBAL_NONE??????? 0
>> +#define HISI_PCIE_EVENT_EN??????? BIT(20)
>> +#define HISI_PCIE_RESET_CNT??????? BIT(22)
>> +#define HISI_PCIE_DEFAULT_SET??????? BIT(34)
>> +#define HISI_PCIE_THR_EN??????? BIT(26)
>> +#define HISI_PCIE_TARGET_EN??????? BIT(32)
>> +#define HISI_PCIE_TRIG_EN??????? BIT(52)
>> +
>> +/* Define offsets in event ctrl regesiter */
>> +#define HISI_PCIE_EVENT_M??????? GENMASK_ULL(7, 0)
>> +#define HISI_PCIE_SUBEVENT_M??????? GENMASK_ULL(15, 8)
>> +#define HISI_PCIE_THR_MODE_M??????? GENMASK_ULL(27, 27)
>> +#define HISI_PCIE_THR_M??????????? GENMASK_ULL(31, 28)
>> +#define HISI_PCIE_TARGET_M??????? GENMASK_ULL(52, 36)
>> +#define HISI_PCIE_TRIG_MODE_M??????? GENMASK_ULL(53, 53)
>> +#define HISI_PCIE_TRIG_M??????? GENMASK_ULL(59, 56)
>> +
>> +#define HISI_PCIE_MAX_COUNTERS??????? 8
>> +#define HISI_PCIE_REG_STEP??????? 8
>> +#define HISI_PCIE_EVENT_MAX??????? 0xa2
>> +#define HISI_PCIE_SUBEVENT_MAX??????? 0x20
>> +#define HISI_PCIE_THR_MAX_VAL??????? 10
>> +#define HISI_PCIE_TRIG_MAX_VAL??????? 10
>> +#define HISI_PCIE_COUNTER_BITS??????? 64
>> +#define HISI_PCIE_MAX_PERIOD??????? BIT_ULL(63)
>> +
>> +struct hisi_pcie_pmu {
>> +??? struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
>> +??? struct hlist_node node;
>> +??? struct pci_dev *pdev;
>> +??? struct pmu pmu;
>> +??? void __iomem *base;
>> +??? cpumask_t cpumask;
>> +??? int irq;
>> +??? u32 identifier;
>> +??? /* Minimum and maximum bdf of root ports monitored by PMU */
>> +??? u16 bdf_min;
>> +??? u16 bdf_max;
>> +};
>> +
>> +#define to_pcie_pmu(p)? (container_of((p), struct hisi_pcie_pmu, pmu))
>> +#define GET_PCI_DEVFN(bdf)? ((bdf) & 0xff)
>> +
>> +#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)?????? \
>> +??? static inline u64 hisi_pcie_get_##_name(struct perf_event *event)? \
>> +??? {???????????????????????????????????????????????????????????? \
>> +??????? return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
>> +??? }??????????????????????????? \
>> +
>> +HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
>> +HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
>> +HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
>> +HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
>> +HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
>> +
>> +#define HISI_PCIE_CHECK_EVENTS(name, list)???????????? \
> 
> "check" in a function name is too vague, as it does not imply any 
> side-effect from calling this function.
> 
> And I think "build" or similar would be good to be included in the macro 
> name.
> 
>> +??? static inline bool is_##name##_event(u32 idx)????????????????? \
> 
> why inline?
> 
>> +    
>> {?????????????????????????????????????????????????????????????????? \
>> +??????? if ((idx >= list[0] && idx <= list[1]) || idx == list[2])? \
>> +??????????? return true;??????????????????????????????????????? \
>> +??????? return false;?????????????????????????????????????????????? \
> 
> isn't this just:
> {
>  ????return (idx >= list[0] && idx <= list[1]) || idx == list[2])
> }

thanks, will address in next version.
> 
>> +??? }
>> +
>> +/*
>> + * The first element of event list is minimum index of TL-layer events
>> + * and the second element is maximum index. The third element is index
>> + * of a DL-layer event.
>> + */
>> +static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
>> +static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
>> +static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
>> +static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
>> +
>> +HISI_PCIE_CHECK_EVENTS(bw, bw_events_list);
>> +HISI_PCIE_CHECK_EVENTS(latency, latency_events_list);
>> +HISI_PCIE_CHECK_EVENTS(bus_util, bus_util_events_list);
>> +HISI_PCIE_CHECK_EVENTS(buf_util, buf_util_events_list);
> 
> Surely the macro can be fixed such that you need to have:
> HISI_PCIE_CHECK_EVENTS(buf_util);
> 
will address in next version.
> 
>> +
>> +static ssize_t hisi_pcie_cpumask_show(struct device *dev,
>> +????????????????????? struct device_attribute *attr, char *buf)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>> +
>> +??? return cpumap_print_to_pagebuf(true, buf, &pcie_pmu->cpumask);
>> +}
>> +
>> +static ssize_t hisi_pcie_identifier_show(struct device *dev,
>> +???????????????????? struct device_attribute *attr,
>> +???????????????????? char *buf)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>> +
>> +??? return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
>> +}
>> +
>> +static ssize_t hisi_pcie_bus_show(struct device *dev,
>> +????????????????? struct device_attribute *attr, char *buf)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>> +
>> +??? return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
>> +}
>> +
>> +static void hisi_pcie_parse_data(struct hisi_pcie_pmu *pcie_pmu, u32 
>> reg_off,
> 
> hisi_pcie_parse_data() name is way too vague. I mean, parse what data?
> 
> is there is some standard format register we use for various data types, 
> then make that clear please
Seems that we only have lower_32_bits() but do not have lower_16_bits().
perhaps we could change the function name to hisi_pcie_parse_reg_value()?

> 
>> +?????????????????? u16 *arg0, u16 *arg1)
>> +{
>> +??? u32 val = readl(pcie_pmu->base + reg_off);
>> +
>> +??? *arg0 = val & 0xffff;
>> +??? *arg1 = (val & 0xffff0000) >> 16;
>> +}
>> +
>> +static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
>> +{
>> +??? return offset + HISI_PCIE_REG_STEP * idx;
>> +}
>> +
>> +static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32 
>> reg_offset,
>> +?????????????????? u32 idx)
>> +{
>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>> +
>> +??? return readl(pcie_pmu->base + offset);
>> +}
>> +
>> +static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32 
>> reg_offset,
>> +???????????????? u32 idx, u32 val)
>> +{
>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>> +
>> +??? writel(val, pcie_pmu->base + offset);
>> +}
>> +
>> +static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32 
>> reg_offset,
>> +?????????????????? u32 idx)
>> +{
>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>> +
>> +??? return readq(pcie_pmu->base + offset);
>> +}
>> +
>> +static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32 
>> reg_offset,
>> +???????????????? u32 idx, u64 val)
>> +{
>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>> +
>> +??? writeq(val, pcie_pmu->base + offset);
>> +}
>> +
>> +static u64 hisi_pcie_pmu_get_event(struct perf_event *event)
> 
> that function name is too vague
> 
>> +{
>> +??? return FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
>> +?????????? FIELD_PREP(HISI_PCIE_SUBEVENT_M, 
>> hisi_pcie_get_subevent(event));
>> +}
>> +
>> +static u64 hisi_pcie_pmu_get_target(struct perf_event *event)
> 
> same here
> 
>> +{
>> +??? u64 port, val;
>> +
>> +??? port = hisi_pcie_get_port(event);
>> +??? if (port) {
>> +??????? val = FIELD_PREP(HISI_PCIE_TARGET_M, port);
>> +??? } else {
>> +??????? val = FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
>> +??????? val |= HISI_PCIE_TARGET_EN;
>> +??? }
>> +
>> +??? return val;
>> +}
>> +
>> +static u64 hisi_pcie_pmu_get_trigger(struct perf_event *event)
> 
> and here
> 
> what you really seem to be doing is getting the formatted fields for the 
> register
> 
> 
> Having all these call-once functions seem to make life a bit more 
> difficult...
> 
Do you mean config all the filters in one function?, will fix it, thanks.

>> +{
>> +??? u64 trig_len, val;
>> +
>> +??? trig_len = hisi_pcie_get_trig_len(event);
>> +??? if (!trig_len)
>> +??????? return 0;
>> +
>> +??? val = FIELD_PREP(HISI_PCIE_TRIG_M, trig_len);
>> +??? val |= FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
>> +????????????? hisi_pcie_get_trig_mode(event));
>> +??? val |= HISI_PCIE_TRIG_EN;
>> +
>> +??? return val;
>> +}
>> +
>> +static u64 hisi_pcie_pmu_get_thr(struct perf_event *event)
>> +{
>> +??? u64 thr_len, val;
>> +
>> +??? thr_len = hisi_pcie_get_thr_len(event);
>> +??? if (!thr_len)
>> +??????? return 0;
>> +
>> +??? val = FIELD_PREP(HISI_PCIE_THR_M, thr_len);
>> +??? val |= FIELD_PREP(HISI_PCIE_THR_MODE_M, 
>> hisi_pcie_get_thr_mode(event));
>> +??? val |= HISI_PCIE_THR_EN;
>> +
>> +??? return val;
>> +}
>> +
>> +static void hisi_pcie_pmu_config_filter(struct perf_event *event)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? u32 idx = hwc->idx;
>> +??? u64 val;
>> +
>> +??? val = HISI_PCIE_DEFAULT_SET;
>> +??? val |= hisi_pcie_pmu_get_event(event);
>> +??? val |= hisi_pcie_pmu_get_target(event);
>> +??? val |= hisi_pcie_pmu_get_trigger(event);
>> +??? val |= hisi_pcie_pmu_get_thr(event);
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
>> +}
>> +
>> +static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
>> +???????????????? HISI_PCIE_DEFAULT_SET);
>> +}
>> +
>> +static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu, 
>> u16 bdf)
>> +{
>> +??? return bdf <= pcie_pmu->bdf_max && bdf >= pcie_pmu->bdf_min;
> 
> nit: it is standard to have:
> 
>  ????if (x >= min && x <= max)
> 
> i.e. have min on the left
> 
> 2nd nit: it is passed bdf, yet "port" is in the name
> 
will fix the function, bdf means the BDF of Root Port, I'll use rp_bdf 
in bext version to describe it.
> 
>> +}
>> +
>> +static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu 
>> *pcie_pmu,
>> +??????????????????????? u32 bdf)
>> +{
>> +??? struct pci_dev *root_port, *pdev;
>> +
>> +??? pdev = 
>> pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
>> +?????????????????????? PCI_BUS_NUM(bdf),
>> +?????????????????????? GET_PCI_DEVFN(bdf));
>> +??? if (!pdev)
>> +??????? return false;
>> +
>> +??? root_port = pcie_find_root_port(pdev);
>> +??? if (!root_port)
>> +??????? return false;
>> +
>> +??? pci_dev_put(pdev);
>> +??? return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
>> +}
>> +
>> +static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
>> +?????????????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? u32 subev_idx = hisi_pcie_get_subevent(event);
>> +??? u32 event_idx = hisi_pcie_get_event(event);
>> +??? u32 requester_id = hisi_pcie_get_bdf(event);
>> +
>> +??? if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
>> +??????? event_idx > HISI_PCIE_EVENT_MAX) {
>> +??????? pci_err(pcie_pmu->pdev,
>> +??????????? "Max event index and max subevent index is: %d, %d.\n",
>> +??????????? HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
> 
> if this is just going to be fed back to userspace, I don't see why we 
> need a kernel log
> 
> and the only caller also triggers an error message, which I doubt is needed
> 
Print out the HISI_PCIE_EVENT_MAX and HISI_PCIE_SUBEVENT_MAX here may be 
more convenient for users to get the right value.
If you this is redundant I'll remove it. :)
>> +??????? return false;
>> +??? }
>> +
>> +??? if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
>> +??????? return false;
>> +
>> +??? if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
>> +??????? return false;
>> +
>> +??? if (requester_id) {
>> +??????? if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id)) {
>> +??????????? pci_err(pcie_pmu->pdev, "Invalid requester id.\n");
> 
> see previous comments
> 
>> +??????????? return false;
>> +??????? }
>> +??? }
>> +
>> +??? return true;
>> +}
>> +
>> +static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
>> +{
>> +??? struct perf_event *sibling, *leader = event->group_leader;
>> +??? int counters = 1;
>> +
>> +??? if (!is_software_event(leader)) {
>> +??????? if (leader->pmu != event->pmu)
>> +??????????? return false;
>> +
>> +??????? if (leader != event)
>> +??????????? counters++;
>> +??? }
>> +
>> +??? for_each_sibling_event(sibling, event->group_leader) {
>> +??????? if (is_software_event(sibling))
>> +??????????? continue;
>> +
>> +??????? if (sibling->pmu != event->pmu)
>> +??????????? return false;
>> +
>> +??????? counters++;
>> +??? }
>> +
>> +??? return counters <= HISI_PCIE_MAX_COUNTERS;
>> +}
>> +
>> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +
>> +??? event->cpu = cpumask_first(&pcie_pmu->cpumask);
>> +
>> +??? if (event->attr.type != event->pmu->type)
>> +??????? return -ENOENT;
>> +
>> +??? /* Sampling is not supported. */
>> +??? if (is_sampling_event(event) || event->attach_state & 
>> PERF_ATTACH_TASK)
>> +??????? return -EOPNOTSUPP;
>> +
>> +??? /* Per-task mode is not supported. */
>> +??? if (event->cpu < 0)
> 
> cpumask_first() gives an unsigned int - this can never happen
> 
>> +??????? return -EINVAL;
>> +
>> +??? if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
>> +??????? pci_err(pcie_pmu->pdev, "Invalid filter!\n");
>> +??????? return -EINVAL;
>> +??? }
>> +
>> +??? if (!hisi_pcie_pmu_validate_event_group(event))
>> +??????? return -EINVAL;
>> +
>> +??? return 0;
>> +}
>> +
>> +static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 val,
> 
> function name too vague, as are the argument names
will fix it, thanks.
> 
>> +????????????????????? u64 val_ext)
>> +{
>> +#define CONVERT_DW_TO_BYTE(x)??? (sizeof(u32) * (x))
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
>> +??? u32 idx = hisi_pcie_get_event(event);
>> +
>> +??? if (!val_ext)
>> +??????? return 0;
>> +
>> +??? /*
>> +???? * The bandwidth, latency, bus utilization and buffer occupancy
>> +???? * are obtained by the (COMMON_COUNTER and EXT_COUNTER). And other
>> +???? * features are obtained by COMMON_COUNTER.
>> +???? */
>> +??? if (is_bw_event(idx)) {
>> +??????? if (!val_ext / 1000)
>> +??????????? return 0;
>> +
>> +??????? /* Process data to set unit of bandwidth as "Byte/ms". */
>> +??????? return (CONVERT_DW_TO_BYTE(val)) / (val_ext / 1000);
>> +??? }
>> +
>> +??? if (is_latency_event(idx))
>> +??????? /* Process data to set unit of latency as "us". */
> 
> it's not a good programming practice to put comments after an if 
> statement like this
will fix it, thanks.
> 
>> +??????? return (val * us_per_cycle) / val_ext;
>> +
>> +??? if (is_bus_util_event(idx))
>> +??????? return (val * us_per_cycle) / val_ext;
>> +
>> +??? if (is_buf_util_event(idx))
>> +??????? return val / (val_ext * us_per_cycle);
>> +
>> +??? return val;
>> +}
>> +
>> +static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 
>> *cnt,
>> +?????????????????????? u64 *cnt_ext)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u32 idx = event->hw.idx;
>> +
>> +??? *cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
>> +??? *cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
>> +}
>> +
>> +static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 
>> val,
>> +??????????????????? u64 val_ext)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u32 idx = event->hw.idx;
>> +
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
>> +}
>> +
>> +static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? int idx;
>> +
>> +??? for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
>> +??????? if (!pcie_pmu->hw_events[idx])
>> +??????????? return idx;
>> +??? }
>> +
>> +??? return -EINVAL;
>> +}
>> +
>> +static void hisi_pcie_pmu_read(struct perf_event *event)
>> +{
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
>> +??? u64 new_cnt_ext, prev_cnt_ext;
>> +??? u64 new_cnt, prev_cnt, delta;
>> +
>> +??? hwc_ext = &hwc->extra_reg;
>> +??? do {
>> +??????? prev_cnt = local64_read(&hwc->prev_count);
>> +??????? prev_cnt_ext = hwc_ext->config;
>> +??????? hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
>> +??? } while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
>> +???????????????? new_cnt) != prev_cnt);
>> +
>> +??? hwc_ext->config = new_cnt_ext;
>> +
>> +??? delta = hisi_pcie_pmu_process_data(event, new_cnt - prev_cnt,
>> +?????????????????????? new_cnt_ext - prev_cnt_ext);
>> +??? local64_add(delta, &event->count);
>> +}
>> +
>> +static void hisi_pcie_pmu_set_period(struct perf_event *event)
>> +{
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? struct hw_perf_event_extra *hwc_ext;
>> +??? u64 val = BIT_ULL(HISI_PCIE_COUNTER_BITS - 1);
>> +
>> +??? hwc_ext = &hwc->extra_reg;
>> +??? local64_set(&hwc->prev_count, val);
>> +??? hwc_ext->config = 0;
>> +??? hisi_pcie_pmu_write_counter(event, val, 0);
>> +}
>> +
>> +static void hisi_pcie_pmu_enable_counter(struct hisi_pcie_pmu *pcie_pmu,
>> +???????????????????? struct hw_perf_event *hwc)
>> +{
>> +??? u32 idx = hwc->idx;
>> +??? u64 val;
>> +
>> +??? val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
>> +??? val |= HISI_PCIE_EVENT_EN;
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
>> +}
>> +
>> +static void hisi_pcie_pmu_disable_counter(struct hisi_pcie_pmu 
>> *pcie_pmu,
>> +????????????????????? struct hw_perf_event *hwc)
>> +{
>> +??? u32 idx = hwc->idx;
>> +??? u64 val;
>> +
>> +??? val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
>> +??? val &= ~HISI_PCIE_EVENT_EN;
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
>> +}
>> +
>> +static void hisi_pcie_pmu_enable_int(struct hisi_pcie_pmu *pcie_pmu,
>> +???????????????????? struct hw_perf_event *hwc)
>> +{
>> +??? u32 idx = hwc->idx;
>> +
>> +??? hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 0);
>> +}
>> +
>> +static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
>> +????????????????????? struct hw_perf_event *hwc)
>> +{
>> +??? u32 idx = hwc->idx;
>> +
>> +??? hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
>> +}
>> +
>> +static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
>> +??????????????????? struct hw_perf_event *hwc)
>> +{
>> +??? u32 idx = hwc->idx;
>> +
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
>> +???????????????? HISI_PCIE_RESET_CNT);
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
>> +???????????????? HISI_PCIE_DEFAULT_SET);
>> +}
>> +
>> +static void hisi_pcie_pmu_start(struct perf_event *event, int flags)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? struct hw_perf_event_extra *hwc_ext;
>> +??? u64 prev_cnt, prev_cnt_ext;
>> +
>> +??? hwc_ext = &hwc->extra_reg;
>> +??? if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
>> +??????? return;
>> +
>> +??? WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
>> +??? hwc->state = 0;
>> +
>> +??? hisi_pcie_pmu_config_filter(event);
>> +??? hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
>> +??? hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
>> +??? hisi_pcie_pmu_set_period(event);
>> +
>> +??? if (flags & PERF_EF_RELOAD) {
>> +??????? prev_cnt = local64_read(&hwc->prev_count);
>> +??????? prev_cnt_ext = hwc_ext->config;
>> +??????? hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
>> +??? }
>> +
>> +??? perf_event_update_userpage(event);
>> +}
>> +
>> +static void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +
>> +??? hisi_pcie_pmu_read(event);
> 
> why do this - it just reads a register? and so why not check the return 
> value?
> 
hisi_pcie_pmu_read() is a void function, perhaps I should use 
hisi_pcie_pmu_update_counter().
>> +??? hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
>> +??? hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
>> +??? hisi_pcie_pmu_clear_filter(event);
>> +??? WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
>> +??? hwc->state |= PERF_HES_STOPPED;
>> +
>> +??? if (hwc->state & PERF_HES_UPTODATE)
>> +??????? return;
>> +
>> +??? hwc->state |= PERF_HES_UPTODATE;
>> +}
>> +
>> +static int hisi_pcie_pmu_add(struct perf_event *event, int flags)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? int idx;
>> +
>> +??? hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
>> +??? idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
>> +??? if (idx < 0)
>> +??????? return idx;
>> +
>> +??? hwc->idx = idx;
>> +??? pcie_pmu->hw_events[idx] = event;
>> +
>> +??? /* Reset PMC to avoid interference caused by previous statistic. */
> 
> what is PMC?
PMU counter, will fix it, thanks.
> 
>> +??? hisi_pcie_pmu_reset_counter(pcie_pmu, hwc);
>> +
>> +??? if (flags & PERF_EF_START)
>> +??????? hisi_pcie_pmu_start(event, PERF_EF_RELOAD);
>> +
>> +??? return 0;
>> +}
>> +
>> +static void hisi_pcie_pmu_del(struct perf_event *event, int flags)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +
>> +??? hisi_pcie_pmu_stop(event, PERF_EF_UPDATE);
>> +??? pcie_pmu->hw_events[hwc->idx] = NULL;
>> +??? perf_event_update_userpage(event);
>> +}
>> +
>> +static void hisi_pcie_pmu_enable(struct pmu *pmu)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
>> +??? int num;
>> +
>> +??? for (num = 0; num < HISI_PCIE_MAX_COUNTERS; num++) {
>> +??????? if (pcie_pmu->hw_events[num])
>> +??????????? break;
>> +??? }
>> +
>> +??? if (num == HISI_PCIE_MAX_COUNTERS)
>> +??????? return;
>> +
>> +??? writel(HISI_PCIE_GLOBAL_EN, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
>> +}
>> +
>> +static void hisi_pcie_pmu_disable(struct pmu *pmu)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
>> +
>> +??? writel(HISI_PCIE_GLOBAL_NONE, pcie_pmu->base + 
>> HISI_PCIE_GLOBAL_CTRL);
>> +}
>> +
>> +static irqreturn_t hisi_pcie_pmu_irq(int irq, void *data)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = data;
>> +??? irqreturn_t ret = IRQ_NONE;
>> +??? struct perf_event *event;
>> +??? u32 overflown;
>> +??? int idx;
>> +
>> +??? for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
>> +??????? overflown = hisi_pcie_pmu_readl(pcie_pmu, HISI_PCIE_INT_STAT,
>> +??????????????????????? idx);
>> +??????? if (!overflown)
>> +??????????? continue;
>> +
>> +??????? /* Clear status of interrupt. */
>> +??????? hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_STAT, idx, 1);
>> +??????? event = pcie_pmu->hw_events[idx];
>> +??????? if (!event)
>> +??????????? continue;
>> +
>> +??????? hisi_pcie_pmu_read(event);
>> +??????? hisi_pcie_pmu_set_period(event);
>> +??????? ret = IRQ_HANDLED;
>> +??? }
>> +
>> +??? return ret;
>> +}
>> +
>> +static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
>> +????????????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? int irq, ret;
>> +
>> +??? ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
>> +??? if (ret < 0) {
>> +??????? pci_err(pdev, "Failed to enable MSI vectors, ret = %d!\n", ret);
>> +??????? return ret;
>> +??? }
>> +
>> +??? irq = pci_irq_vector(pdev, 0);
>> +??? ret = request_irq(irq, hisi_pcie_pmu_irq, IRQF_SHARED, 
>> "hisi_pcie_pmu",
> 
> 
> is this interrupt line really shared?
> 
No, I'll fix it, thanks.
>> +????????????? pcie_pmu);
>> +??? if (ret) {
>> +??????? pci_err(pdev, "Failed to register irq, ret = %d!\n", ret);
>> +??????? pci_free_irq_vectors(pdev);
>> +??????? return ret;
>> +??? }
>> +
>> +??? pcie_pmu->irq = irq;
>> +
>> +??? return 0;
>> +}
>> +
>> +static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
>> +???????????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? free_irq(pcie_pmu->irq, pcie_pmu);
>> +??? pci_free_irq_vectors(pdev);
>> +}
>> +
>> +static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct 
>> hlist_node *node)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>> +???????????????????? struct hisi_pcie_pmu, node);
>> +
>> +??? if (cpumask_empty(&pcie_pmu->cpumask)) {
>> +??????? cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
>> +??????? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
>> +??? }
>> +
>> +??? return 0;
>> +}
>> +
>> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct 
>> hlist_node *node)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>> +???????????????????? struct hisi_pcie_pmu, node);
>> +??? unsigned int target;
>> +
>> +??? if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))
> 
> I do wonder why we even need maintain pcie_pmu->cpumask
> 
> Can't we just use cpu_online_mask as appropiate instead?
> 
>> +??????? return 0;
>> +
>> +??? /* Choose a new CPU from all online cpus. */
>> +??? target = cpumask_any_but(cpu_online_mask, cpu);
>> +??? if (target >= nr_cpu_ids)
>> +??????? return 0;
>> +
>> +??? perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
>> +??? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
>> +
>> +??? return 0;
>> +}
>> +
>> +/*
>> + * Events with the "dl" suffix in their names count performance in DL 
>> layer,
>> + * otherswise, events count performance in TL layer.
>> + */
>> +static struct attribute *hisi_pcie_pmu_events_attr[] = {
>> +??? HISI_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
>> +??? HISI_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
>> +??? HISI_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
>> +??? HISI_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
>> +??? HISI_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
>> +??? HISI_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
>> +??? HISI_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
>> +??? HISI_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
>> +??? HISI_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
>> +??? HISI_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
> 
> it would be nice to see JSONs for these as well with full event 
> descriptions
will add one latter, thanks.
> 
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_events_group = {
>> +??? .name = "events",
>> +??? .attrs = hisi_pcie_pmu_events_attr,
>> +};
>> +
>> +static struct attribute *hisi_pcie_pmu_format_attr[] = {
>> +??? HISI_PMU_FORMAT_ATTR(event, "config:0-7"),
>> +??? HISI_PMU_FORMAT_ATTR(subevent, "config:8-15"),
>> +??? HISI_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
>> +??? HISI_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
>> +??? HISI_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
>> +??? HISI_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
>> +??? HISI_PMU_FORMAT_ATTR(port, "config2:0-15"),
>> +??? HISI_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_format_group = {
>> +??? .name = "format",
>> +??? .attrs = hisi_pcie_pmu_format_attr,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_bus_attr =
>> +??? __ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
>> +??? &hisi_pcie_pmu_bus_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_bus_attrs,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_cpumask_attr =
>> +??? __ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
>> +??? &hisi_pcie_pmu_cpumask_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_cpumask_attrs,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_identifier_attr =
>> +??? __ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
>> +??? &hisi_pcie_pmu_identifier_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_identifier_attrs,
>> +};
>> +
>> +static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
>> +??? &hisi_pcie_pmu_events_group,
>> +??? &hisi_pcie_pmu_format_group,
>> +??? &hisi_pcie_pmu_bus_attr_group,
>> +??? &hisi_pcie_pmu_cpumask_attr_group,
>> +??? &hisi_pcie_pmu_identifier_attr_group,
>> +??? NULL
>> +};
>> +
>> +static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
>> +???????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? u16 sicl_id, device_id;
>> +??? char *name;
>> +
>> +??? pcie_pmu->base = pci_ioremap_bar(pdev, 2);
>> +??? if (!pcie_pmu->base) {
>> +??????? pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
>> +??????? return -ENOMEM;
>> +??? }
>> +
>> +??? hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_BDF, 
>> &pcie_pmu->bdf_min,
>> +?????????????? &pcie_pmu->bdf_max);
>> +??? hisi_pcie_parse_data(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
>> +???????????????? &sicl_id);
>> +??? name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +????????????????? "hisi_pcie%u_%u", sicl_id, device_id);
>> +??? if (!name) {
>> +??????? pci_err(pdev, "Failed to allocate name for PMU.\n");
> 
> no need for that log
will fix it.
> 
>> +??????? return -ENOMEM;
>> +??? }
>> +
>> +??? pcie_pmu->pdev = pdev;
>> +??? pcie_pmu->identifier = readl(pcie_pmu->base + 
>> HISI_PCIE_REG_VERSION);
>> +??? pcie_pmu->pmu = (struct pmu) {
>> +??????? .name??????? = name,
>> +??????? .module??????? = THIS_MODULE,
>> +??????? .event_init??? = hisi_pcie_pmu_event_init,
>> +??????? .pmu_enable??? = hisi_pcie_pmu_enable,
>> +??????? .pmu_disable??? = hisi_pcie_pmu_disable,
>> +??????? .add??????? = hisi_pcie_pmu_add,
>> +??????? .del??????? = hisi_pcie_pmu_del,
>> +??????? .start??????? = hisi_pcie_pmu_start,
>> +??????? .stop??????? = hisi_pcie_pmu_stop,
>> +??????? .read??????? = hisi_pcie_pmu_read,
>> +??????? .task_ctx_nr??? = perf_invalid_context,
>> +??????? .attr_groups??? = hisi_pcie_pmu_attr_groups,
>> +??????? .capabilities??? = PERF_PMU_CAP_NO_EXCLUDE,
>> +??? };
>> +
>> +??? return 0;
>> +}
>> +
>> +static int hisi_pcie_init_pmu(struct pci_dev *pdev,
>> +????????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? int ret;
>> +
>> +??? ret = hisi_pcie_alloc_pmu(pdev, pcie_pmu);
>> +??? if (ret)
>> +??????? return ret;
>> +
>> +??? ret = hisi_pcie_pmu_irq_register(pdev, pcie_pmu);
>> +??? if (ret)
>> +??????? goto err_set_pmu_fail;
>> +
>> +??? ret = 
>> cpuhp_state_add_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>> +?????????????????????? &pcie_pmu->node);
>> +??? if (ret) {
>> +??????? pci_err(pdev, "Failed to register hotplug, ret = %d.\n", ret);
>> +??????? goto err_irq_unregister;
>> +??? }
>> +
>> +??? ret = perf_pmu_register(&pcie_pmu->pmu, pcie_pmu->pmu.name, -1);
>> +??? if (ret) {
>> +??????? pci_err(pdev, "Failed to register PCIe PMU, ret = %d.\n", ret);
>> +??????? goto err_hotplug_unregister;
>> +??? }
>> +
>> +??? return ret;
>> +
>> +err_hotplug_unregister:
>> +??? cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>> +??????????????????? &pcie_pmu->node);
>> +??? irq_set_affinity_hint(pcie_pmu->irq, NULL);
>> +
>> +err_irq_unregister:
>> +??? hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
>> +
>> +err_set_pmu_fail:
>> +??? iounmap(pcie_pmu->base);
>> +
>> +??? return ret;
>> +}
>> +
>> +static void hisi_pcie_uninit_pmu(struct pci_dev *pdev,
>> +???????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? perf_pmu_unregister(&pcie_pmu->pmu);
>> +??? cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>> +??????????????????? &pcie_pmu->node);
>> +??? irq_set_affinity_hint(pcie_pmu->irq, NULL);
>> +??? hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
>> +??? iounmap(pcie_pmu->base);
>> +}
>> +
>> +static int hisi_pcie_init_dev(struct pci_dev *pdev)
>> +{
>> +??? int ret;
>> +
>> +??? ret = pci_enable_device(pdev);
>> +??? if (ret) {
>> +??????? pci_err(pdev, "Failed to enable pci device, ret = %d.\n", ret);
>> +??????? return ret;
>> +??? }
>> +
>> +??? ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
>> +??? if (ret < 0) {
>> +??????? pci_err(pdev, "Failed to request pci mem regions, ret = %d.\n",
>> +??????????? ret);
>> +??????? pci_disable_device(pdev);
>> +??????? return ret;
>> +??? }
>> +
>> +??? pci_set_master(pdev);
>> +
>> +??? return 0;
>> +}
>> +
>> +static void hisi_pcie_uninit_dev(struct pci_dev *pdev)
>> +{
>> +??? pci_clear_master(pdev);
>> +??? pci_release_mem_regions(pdev);
>> +??? pci_disable_device(pdev);
>> +}
>> +
>> +static int hisi_pcie_pmu_probe(struct pci_dev *pdev,
>> +?????????????????? const struct pci_device_id *id)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu;
>> +??? int ret;
>> +
>> +??? pcie_pmu = devm_kzalloc(&pdev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
>> +??? if (!pcie_pmu)
>> +??????? return -ENOMEM;
>> +
>> +??? ret = hisi_pcie_init_dev(pdev);
>> +??? if (ret)
>> +??????? return ret;
>> +
>> +??? ret = hisi_pcie_init_pmu(pdev, pcie_pmu);
>> +??? if (ret)
>> +??????? hisi_pcie_uninit_dev(pdev);
>> +
>> +??? pci_set_drvdata(pdev, pcie_pmu);
>> +
>> +??? return ret;
>> +}
>> +
>> +static void hisi_pcie_pmu_remove(struct pci_dev *pdev)
>> +{
>> +??? hisi_pcie_uninit_pmu(pdev, pci_get_drvdata(pdev));
> 
> passing both pdev and pci_get_drvdata(pdev) should not be needed
> 
>> +??? hisi_pcie_uninit_dev(pdev);
>> +??? pci_set_drvdata(pdev, NULL); > +}
>> +
>> +static const struct pci_device_id hisi_pcie_pmu_ids[] = {
>> +??? { PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12d) },
>> +??? { 0, }
>> +};
>> +MODULE_DEVICE_TABLE(pci, hisi_pcie_pmu_ids);
>> +
>> +static struct pci_driver hisi_pcie_pmu_driver = {
>> +??? .name = "hisi_pcie_pmu",
>> +??? .id_table = hisi_pcie_pmu_ids,
>> +??? .probe = hisi_pcie_pmu_probe,
>> +??? .remove = hisi_pcie_pmu_remove,
>> +};
>> +
>> +static int __init hisi_pcie_module_init(void)
>> +{
>> +??? int ret;
>> +
>> +??? ret = 
>> cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>> +????????????????????? "AP_PERF_ARM_HISI_PCIE_PMU_ONLINE",
>> +????????????????????? hisi_pcie_pmu_online_cpu,
>> +????????????????????? hisi_pcie_pmu_offline_cpu);
>> +??? if (ret) {
>> +??????? pr_err("Failed to setup PCIE PMU hotplug, ret = %d.\n", ret);
>> +??????? return ret;
>> +??? }
>> +
>> +??? ret = pci_register_driver(&hisi_pcie_pmu_driver);
>> +??? if (ret)
>> +??????? cpuhp_remove_multi_state(
>> +??????????????? CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
>> +
>> +??? return ret;
>> +}
>> +module_init(hisi_pcie_module_init);
>> +
>> +static void __exit hisi_pcie_module_exit(void)
>> +{
>> +??? pci_unregister_driver(&hisi_pcie_pmu_driver);
>> +??? cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
>> +}
>> +module_exit(hisi_pcie_module_exit);
>> +
>> +MODULE_DESCRIPTION("HiSilicon PCIe PMU driver");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR("Qi Liu <liuqi115 at huawei.com>");
>> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
>> index 113f51f..c17861a 100644
>> --- a/include/linux/cpuhotplug.h
>> +++ b/include/linux/cpuhotplug.h
>> @@ -174,6 +174,7 @@ enum cpuhp_state {
>> ????? CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
>> ????? CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
>> ????? CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
>> +??? CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
>> ????? CPUHP_AP_PERF_ARM_L2X0_ONLINE,
>> ????? CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
>> ????? CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
>>
> 
> .



From jacopo at jmondi.org  Mon Apr 12 14:41:57 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 15:41:57 +0200
Subject: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc
 driver
In-Reply-To: <a22c2065-1a79-8a96-2b54-a2e28fa08b8a@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-31-eugen.hristev@microchip.com>
 <a22c2065-1a79-8a96-2b54-a2e28fa08b8a@microchip.com>
Message-ID: <20210412134157.4cqva5thylmiqds7@uno.localdomain>

Hi Eugene,

On Mon, Apr 12, 2021 at 12:37:41PM +0000, Eugen.Hristev at microchip.com wrote:
> > +static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
> > +{
> > +	struct device_node *np = dev->of_node;
> > +	struct device_node *epn = NULL;
> > +	struct isc_subdev_entity *subdev_entity;
> > +	unsigned int flags;
> > +	int ret;
> > +	bool mipi_mode;
> > +
> > +	INIT_LIST_HEAD(&isc->subdev_entities);
> > +
> > +	mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
> > +
> > +	while (1) {
> > +		struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
> > +
> > +		epn = of_graph_get_next_endpoint(np, epn);
> > +		if (!epn)
> > +			return 0;
> > +
> > +		ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
> > +						 &v4l2_epn);
> > +		if (ret) {
> > +			ret = -EINVAL;
> > +			dev_err(dev, "Could not parse the endpoint\n");
> > +			break;
> > +		}
> > +
> > +		subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
> > +					     GFP_KERNEL);
> > +		if (!subdev_entity) {
> > +			ret = -ENOMEM;
> > +			break;
> > +		}
> > +		subdev_entity->epn = epn;
> > +
> > +		flags = v4l2_epn.bus.parallel.flags;
> > +
> > +		if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> > +			subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
> > +
> > +		if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> > +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
> > +
> > +		if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> > +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
> > +
> > +		if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
> > +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
> > +					ISC_PFE_CFG0_CCIR656;
>
> Hi Jacopo,
>
> If I use the bus-type property for the 'port' , do I actually have to
> change something here ?

You can set bus_type to the desired type, if it doesn't match the
'bus-type' property you will have an immediate error and a more strict
check on the properties.

You would likely:

        v4l2_epn.bus_type = V4L2_MBUS_PARALLEL;
        ret = v4l2_fwnode_endpoint_parse()
        if (!ret) {
                /* It's parallel */
        } else {
                v4l2_epn.bus_type = V4L2_MBUS_BT656;
                ret = v4l2_fwnode_endpoint_parse()
                if (ret) {
                        /* Unsupported bus type: error out. */
                }

                /* It's BT656 */
        }

Not the greatest API, but it's more robust.

> the v4l2_epn.bus_type won't be set automatically ? by the endpoint
> parser I mean.

Yes, that's what auto-discovery is, the endpoint parser tries to
deduce the bus type from the properties that are there specified. It
works, but leaves quite some ambiguity between ie PARALLEL and BT656
as some polarities might not be necessarily specified even for
PARALLEL bus types.

As I've said, there's still plenty of code that relies on
auto-discovery so I don't think this is blocking, also because making
bus-type mandatory on existing DTS is quite painful. Since this is a
new DTS you can consider this solution if you want to.

Thanks
   j

>
> Thanks,
> Eugen
>
> > +
> > +		if (mipi_mode)
> > +			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
> > +
> > +		list_add_tail(&subdev_entity->list, &isc->subdev_entities);
> > +	}
> > +	of_node_put(epn);
> > +
> > +	return ret;
> > +}
> > +
> > +static int microchip_xisc_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct isc_device *isc;
> > +	struct resource *res;
> > +	void __iomem *io_base;
> > +	struct isc_subdev_entity *subdev_entity;
> > +	int irq;
> > +	int ret;
> > +	u32 ver;
> > +
> > +	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
> > +	if (!isc)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, isc);
> > +	isc->dev = dev;
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	io_base = devm_ioremap_resource(dev, res);
> > +	if (IS_ERR(io_base))
> > +		return PTR_ERR(io_base);
> > +
> > +	isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
> > +	if (IS_ERR(isc->regmap)) {
> > +		ret = PTR_ERR(isc->regmap);
> > +		dev_err(dev, "failed to init register map: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	irq = platform_get_irq(pdev, 0);
> > +	if (irq < 0)
> > +		return irq;
> > +
> > +	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
> > +			       "microchip-sama7g5-xisc", isc);
> > +	if (ret < 0) {
> > +		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
> > +			irq, ret);
> > +		return ret;
> > +	}
> > +
> > +	isc->gamma_table = isc_sama7g5_gamma_table;
> > +	isc->gamma_max = 0;
> > +
> > +	isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
> > +	isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
> > +
> > +	isc->config_dpc = isc_sama7g5_config_dpc;
> > +	isc->config_csc = isc_sama7g5_config_csc;
> > +	isc->config_cbc = isc_sama7g5_config_cbc;
> > +	isc->config_cc = isc_sama7g5_config_cc;
> > +	isc->config_gam = isc_sama7g5_config_gam;
> > +	isc->config_rlp = isc_sama7g5_config_rlp;
> > +	isc->config_ctrls = isc_sama7g5_config_ctrls;
> > +
> > +	isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
> > +
> > +	isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
> > +	isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
> > +	isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
> > +	isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
> > +	isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
> > +	isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
> > +	isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
> > +	isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
> > +	isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
> > +
> > +	isc->controller_formats = sama7g5_controller_formats;
> > +	isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
> > +	isc->formats_list = sama7g5_formats_list;
> > +	isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
> > +
> > +	/* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
> > +	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
> > +
> > +	ret = isc_pipeline_init(isc);
> > +	if (ret)
> > +		return ret;
> > +
> > +	isc->hclock = devm_clk_get(dev, "hclock");
> > +	if (IS_ERR(isc->hclock)) {
> > +		ret = PTR_ERR(isc->hclock);
> > +		dev_err(dev, "failed to get hclock: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	ret = clk_prepare_enable(isc->hclock);
> > +	if (ret) {
> > +		dev_err(dev, "failed to enable hclock: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	ret = isc_clk_init(isc);
> > +	if (ret) {
> > +		dev_err(dev, "failed to init isc clock: %d\n", ret);
> > +		goto unprepare_hclk;
> > +	}
> > +
> > +	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
> > +
> > +	ret = clk_prepare_enable(isc->ispck);
> > +	if (ret) {
> > +		dev_err(dev, "failed to enable ispck: %d\n", ret);
> > +		goto unprepare_hclk;
> > +	}
> > +
> > +	/* ispck should be greater or equal to hclock */
> > +	ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
> > +	if (ret) {
> > +		dev_err(dev, "failed to set ispck rate: %d\n", ret);
> > +		goto unprepare_clk;
> > +	}
> > +
> > +	ret = v4l2_device_register(dev, &isc->v4l2_dev);
> > +	if (ret) {
> > +		dev_err(dev, "unable to register v4l2 device.\n");
> > +		goto unprepare_clk;
> > +	}
> > +
> > +	ret = xisc_parse_dt(dev, isc);
> > +	if (ret) {
> > +		dev_err(dev, "fail to parse device tree\n");
> > +		goto unregister_v4l2_device;
> > +	}
> > +
> > +	if (list_empty(&isc->subdev_entities)) {
> > +		dev_err(dev, "no subdev found\n");
> > +		ret = -ENODEV;
> > +		goto unregister_v4l2_device;
> > +	}
> > +
> > +	list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
> > +		struct v4l2_async_subdev *asd;
> > +
> > +		v4l2_async_notifier_init(&subdev_entity->notifier);
> > +
> > +		asd = v4l2_async_notifier_add_fwnode_remote_subdev(
> > +					&subdev_entity->notifier,
> > +					of_fwnode_handle(subdev_entity->epn),
> > +					struct v4l2_async_subdev);
> > +
> > +		of_node_put(subdev_entity->epn);
> > +		subdev_entity->epn = NULL;
> > +
> > +		if (IS_ERR(asd)) {
> > +			ret = PTR_ERR(asd);
> > +			goto cleanup_subdev;
> > +		}
> > +
> > +		subdev_entity->notifier.ops = &isc_async_ops;
> > +
> > +		ret = v4l2_async_notifier_register(&isc->v4l2_dev,
> > +						   &subdev_entity->notifier);
> > +		if (ret) {
> > +			dev_err(dev, "fail to register async notifier\n");
> > +			goto cleanup_subdev;
> > +		}
> > +
> > +		if (video_is_registered(&isc->video_dev))
> > +			break;
> > +	}
> > +
> > +	pm_runtime_set_active(dev);
> > +	pm_runtime_enable(dev);
> > +	pm_request_idle(dev);
> > +
> > +	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
> > +	dev_info(dev, "Microchip XISC version %x\n", ver);
> > +
> > +	return 0;
> > +
> > +cleanup_subdev:
> > +	isc_subdev_cleanup(isc);
> > +
> > +unregister_v4l2_device:
> > +	v4l2_device_unregister(&isc->v4l2_dev);
> > +
> > +unprepare_clk:
> > +	clk_disable_unprepare(isc->ispck);
> > +unprepare_hclk:
> > +	clk_disable_unprepare(isc->hclock);
> > +
> > +	isc_clk_cleanup(isc);
> > +
> > +	return ret;
> > +}
> > +
> > +static int microchip_xisc_remove(struct platform_device *pdev)
> > +{
> > +	struct isc_device *isc = platform_get_drvdata(pdev);
> > +
> > +	pm_runtime_disable(&pdev->dev);
> > +
> > +	isc_subdev_cleanup(isc);
> > +
> > +	v4l2_device_unregister(&isc->v4l2_dev);
> > +
> > +	clk_disable_unprepare(isc->ispck);
> > +	clk_disable_unprepare(isc->hclock);
> > +
> > +	isc_clk_cleanup(isc);
> > +
> > +	return 0;
> > +}
> > +
> > +static int __maybe_unused xisc_runtime_suspend(struct device *dev)
> > +{
> > +	struct isc_device *isc = dev_get_drvdata(dev);
> > +
> > +	clk_disable_unprepare(isc->ispck);
> > +	clk_disable_unprepare(isc->hclock);
> > +
> > +	return 0;
> > +}
> > +
> > +static int __maybe_unused xisc_runtime_resume(struct device *dev)
> > +{
> > +	struct isc_device *isc = dev_get_drvdata(dev);
> > +	int ret;
> > +
> > +	ret = clk_prepare_enable(isc->hclock);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = clk_prepare_enable(isc->ispck);
> > +	if (ret)
> > +		clk_disable_unprepare(isc->hclock);
> > +
> > +	return ret;
> > +}
> > +
> > +static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
> > +	SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
> > +};
> > +
> > +static const struct of_device_id microchip_xisc_of_match[] = {
> > +	{ .compatible = "microchip,sama7g5-isc" },
> > +	{ }
> > +};
> > +MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
> > +
> > +static struct platform_driver microchip_xisc_driver = {
> > +	.probe	= microchip_xisc_probe,
> > +	.remove	= microchip_xisc_remove,
> > +	.driver	= {
> > +		.name		= "microchip-sama7g5-xisc",
> > +		.pm		= &microchip_xisc_dev_pm_ops,
> > +		.of_match_table = of_match_ptr(microchip_xisc_of_match),
> > +	},
> > +};
> > +
> > +module_platform_driver(microchip_xisc_driver);
> > +
> > +MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
> > +MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_SUPPORTED_DEVICE("video");
> >
>


From dillon.minfei at gmail.com  Mon Apr 12 14:41:53 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Mon, 12 Apr 2021 21:41:53 +0800
Subject: [Linux-stm32] [PATCH] serial: stm32: optimize spin lock usage
In-Reply-To: <f3985d70-4f00-7442-de4e-e382b19e3e50@foss.st.com>
References: <1618202061-8243-1-git-send-email-dillon.minfei@gmail.com>
 <YHPgGI6EmTzmVH7g@kroah.com>
 <CAL9mu0Lt-3_O7V5HLxd5Hbt9afx9ryBUzWqmsc+2n3SP7JS6ig@mail.gmail.com>
 <YHQEA9jn5uXQCtrN@kroah.com>
 <CAL9mu0+hi5eYEder1Mj2yjUN+eicJ9qG8Kr4GTC2mqfY405Jkg@mail.gmail.com>
 <f3985d70-4f00-7442-de4e-e382b19e3e50@foss.st.com>
Message-ID: <CAL9mu0LnxD69Y2F_TK_b+N5QhMS6bjz6YU-zJdscY75S3jj8qQ@mail.gmail.com>

On 4/12/21, Erwan LE RAY <erwan.leray at foss.st.com> wrote:
> Hi Dillon,
>
> Thanks for your patch.
>
> Could you please elaborate the use case in your commit message ?

Sorry, local_irq_save() plus spin_lock() same to spin_lock_irqsave()
There is no deadlock . Please ignore this patch.

Thanks

Dillon
>
> Best Regards, Erwan.
>
> On 4/12/21 10:54 AM, dillon min wrote:
>> Hi Greg,
>>
>> On Mon, Apr 12, 2021 at 4:25 PM Greg KH <gregkh at linuxfoundation.org>
>> wrote:
>>>
>>> On Mon, Apr 12, 2021 at 02:50:20PM +0800, dillon min wrote:
>>>> Hi Greg?
>>>>
>>>> Thanks for the quick response, please ignore the last private mail.
>>>>
>>>> On Mon, Apr 12, 2021 at 1:52 PM Greg KH <gregkh at linuxfoundation.org>
>>>> wrote:
>>>>>
>>>>> On Mon, Apr 12, 2021 at 12:34:21PM +0800, dillon.minfei at gmail.com
>>>>> wrote:
>>>>>> From: dillon min <dillon.minfei at gmail.com>
>>>>>>
>>>>>> To avoid potential deadlock in spin_lock usage, change to use
>>>>>> spin_lock_irqsave(), spin_unlock_irqrestore() in process(thread_fn)
>>>>>> context.
>>>>>> spin_lock(), spin_unlock() under handler context.
>>>>>>
>>>>>> remove unused local_irq_save/restore call.
>>>>>>
>>>>>> Signed-off-by: dillon min <dillon.minfei at gmail.com>
>>>>>> ---
>>>>>> Was verified on stm32f469-disco board. need more test on stm32mp
>>>>>> platform.
>>>>>>
>>>>>>   drivers/tty/serial/stm32-usart.c | 27 +++++++++++++++++----------
>>>>>>   1 file changed, 17 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/tty/serial/stm32-usart.c
>>>>>> b/drivers/tty/serial/stm32-usart.c
>>>>>> index b3675cf25a69..c4c859b34367 100644
>>>>>> --- a/drivers/tty/serial/stm32-usart.c
>>>>>> +++ b/drivers/tty/serial/stm32-usart.c
>>>>>> @@ -214,7 +214,7 @@ static void stm32_usart_receive_chars(struct
>>>>>> uart_port *port, bool threaded)
>>>>>>        struct tty_port *tport = &port->state->port;
>>>>>>        struct stm32_port *stm32_port = to_stm32_port(port);
>>>>>>        const struct stm32_usart_offsets *ofs =
>>>>>> &stm32_port->info->ofs;
>>>>>> -     unsigned long c;
>>>>>> +     unsigned long c, flags;
>>>>>>        u32 sr;
>>>>>>        char flag;
>>>>>>
>>>>>> @@ -276,9 +276,17 @@ static void stm32_usart_receive_chars(struct
>>>>>> uart_port *port, bool threaded)
>>>>>>                uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>>>>>>        }
>>>>>>
>>>>>> -     spin_unlock(&port->lock);
>>>>>> +     if (threaded)
>>>>>> +             spin_unlock_irqrestore(&port->lock, flags);
>>>>>> +     else
>>>>>> +             spin_unlock(&port->lock);
>>>>>
>>>>> You shouldn't have to check for this, see the other patches on the
>>>>> list
>>>>> recently that fixed this up to not be an issue for irq handlers.
>>>> Can you help to give more hints, or the commit id of the patch which
>>>> fixed this. thanks.
>>>>
>>>> I'm still confused with this.
>>>>
>>>> The stm32_usart_threaded_interrupt() is a kthread context, once
>>>> port->lock holds by this function, another serial interrupts raised,
>>>> such as USART_SR_TXE,stm32_usart_interrupt() can't get the lock,
>>>> there will be a deadlock. isn't it?
>>>>
>>>>   So, shouldn't I use spin_lock{_irqsave} according to the caller's
>>>> context ?
>>>
>>> Please see 81e2073c175b ("genirq: Disable interrupts for force threaded
>>> handlers") for when threaded irq handlers have irqs disabled, isn't that
>>> the case you are trying to "protect" from here?
>>>
>>> Why is the "threaded" flag used at all?  The driver should not care.
>>>
>>> Also see 9baedb7baeda ("serial: imx: drop workaround for forced irq
>>> threading") in linux-next for an example of how this was fixed up in a
>>> serial driver.
>>>
>>> does that help?
>>>
>> Yes, it's really helpful. and 81e2073c175b should be highlighted in a
>> doc.
>> In my past knowledge, we should care about hard irq & thread_fn lock
>> conflict.
>> This patch has totally avoided patching code in the separate driver side.
>> thanks.
>>
>> I will just keep the changes in stm32_usart_console_write(), remove
>> these code in
>> thread_fn. update version 2 for you.
>>
>> thanks.
>>
>> Dillon,
>>> thanks,
>>>
>>> greg k-h
>> _______________________________________________
>> Linux-stm32 mailing list
>> Linux-stm32 at st-md-mailman.stormreply.com
>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
>>
>


From linus.walleij at linaro.org  Mon Apr 12 14:47:00 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 12 Apr 2021 15:47:00 +0200
Subject: [PATCH] ARM: defconfig: gemini: Update defconfig
Message-ID: <20210412134700.1977619-1-linus.walleij@linaro.org>

Update the Gemini defconfig: some moved options, added som
WLAN drivers existing on the supported platforms and enabled
the drivetemp sensor which is used on the NAS devices.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ARM SoC folks: apply this wherever defconfigs go.
---
 arch/arm/configs/gemini_defconfig | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/gemini_defconfig b/arch/arm/configs/gemini_defconfig
index d2d5f1cf815f..4d5409689e68 100644
--- a/arch/arm/configs/gemini_defconfig
+++ b/arch/arm/configs/gemini_defconfig
@@ -16,6 +16,7 @@ CONFIG_CMDLINE="console=ttyS0,115200n8"
 CONFIG_KEXEC=y
 CONFIG_PM=y
 CONFIG_PARTITION_ADVANCED=y
+CONFIG_IOSCHED_BFQ=y
 CONFIG_BINFMT_MISC=y
 CONFIG_CMA=y
 CONFIG_NET=y
@@ -51,9 +52,27 @@ CONFIG_NETDEVICES=y
 CONFIG_TUN=y
 CONFIG_NET_DSA_REALTEK_SMI=y
 CONFIG_GEMINI_ETHERNET=y
+CONFIG_MARVELL_PHY=y
 CONFIG_MDIO_BITBANG=y
 CONFIG_MDIO_GPIO=y
-CONFIG_MARVELL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN_VENDOR_ADMTEK is not set
+# CONFIG_WLAN_VENDOR_ATH is not set
+# CONFIG_WLAN_VENDOR_ATMEL is not set
+# CONFIG_WLAN_VENDOR_BROADCOM is not set
+# CONFIG_WLAN_VENDOR_CISCO is not set
+# CONFIG_WLAN_VENDOR_INTEL is not set
+# CONFIG_WLAN_VENDOR_INTERSIL is not set
+# CONFIG_WLAN_VENDOR_MARVELL is not set
+# CONFIG_WLAN_VENDOR_MEDIATEK is not set
+CONFIG_RT2X00=y
+CONFIG_RT61PCI=y
+CONFIG_RT2800PCI=y
+# CONFIG_WLAN_VENDOR_REALTEK is not set
+# CONFIG_WLAN_VENDOR_RSI is not set
+# CONFIG_WLAN_VENDOR_ST is not set
+# CONFIG_WLAN_VENDOR_TI is not set
+# CONFIG_WLAN_VENDOR_ZYDAS is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 # CONFIG_INPUT_MOUSE is not set
@@ -67,6 +86,7 @@ CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_I2C_GPIO=y
 CONFIG_SPI=y
 CONFIG_SPI_GPIO=y
+CONFIG_SENSORS_DRIVETEMP=y
 CONFIG_SENSORS_GPIO_FAN=y
 CONFIG_SENSORS_LM75=y
 CONFIG_THERMAL=y
@@ -98,5 +118,4 @@ CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_ROMFS_FS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
-# CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_DEBUG_FS=y
-- 
2.29.2



From narmstrong at baylibre.com  Mon Apr 12 14:48:33 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 15:48:33 +0200
Subject: [PATCH] media: meson-ge2d: fix rotation parameters
Message-ID: <20210412134833.3467694-1-narmstrong@baylibre.com>

With these settings, 90deg and 270deg rotation leads to inverted
vertical, fix them to have correct rotation.

Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit")
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/media/platform/meson/ge2d/ge2d.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/meson/ge2d/ge2d.c b/drivers/media/platform/meson/ge2d/ge2d.c
index 153612ca96fc..a1393fefa8ae 100644
--- a/drivers/media/platform/meson/ge2d/ge2d.c
+++ b/drivers/media/platform/meson/ge2d/ge2d.c
@@ -757,7 +757,7 @@ static int ge2d_s_ctrl(struct v4l2_ctrl *ctrl)
 
 		if (ctrl->val == 90) {
 			ctx->hflip = 0;
-			ctx->vflip = 0;
+			ctx->vflip = 1;
 			ctx->xy_swap = 1;
 		} else if (ctrl->val == 180) {
 			ctx->hflip = 1;
@@ -765,7 +765,7 @@ static int ge2d_s_ctrl(struct v4l2_ctrl *ctrl)
 			ctx->xy_swap = 0;
 		} else if (ctrl->val == 270) {
 			ctx->hflip = 1;
-			ctx->vflip = 1;
+			ctx->vflip = 0;
 			ctx->xy_swap = 1;
 		} else {
 			ctx->hflip = 0;
-- 
2.25.1



From maz at kernel.org  Mon Apr 12 14:48:47 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 14:48:47 +0100
Subject: ARM WFET application scenario consultation
In-Reply-To: <20210412131520.GF2060@arm.com>
References: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
 <20210412124637.GE2060@arm.com> <878s5nodjd.wl-maz@kernel.org>
 <20210412131520.GF2060@arm.com>
Message-ID: <877dl7obpc.wl-maz@kernel.org>

On Mon, 12 Apr 2021 14:15:21 +0100,
Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> On Mon, Apr 12, 2021 at 02:09:10PM +0100, Marc Zyngier wrote:
> > On Mon, 12 Apr 2021 13:46:37 +0100,
> > Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > 
> > > On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> > > > Recently, a new feature of WFE with timeouts has been added to ARMv8.
> > > > I have some doubts about the application scenarios of this feature.
> > > > 
> > > > 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> > > > thread using spinlock can't be sleep, if we use the wfet instruction, we
> > > > can do nothing but wait when timeout,  so what's the difference between
> > > > the two instructions in this scenario?
> > > 
> > > Not much point in using it it in a classic spinlock, unless you have
> > > some specific implementation that's supposed to time out.
> > > 
> > > Note that we already enabled the event stream in Linux so that an event
> > > is generated at 100KHz waking up any WFE. One reason we had for this was
> > > some hardware errata where events between clusters were not generated.
> > > Another was some small delays required in in certain user programs
> > > without going through a kernel syscall, though not sure anyone's
> > > actually using it.
> > > 
> > > > 2) Are there any other special scenarios where using wfet instructions
> > > > can be beneficial ?
> > > 
> > > In the kernel we could replace our udelay loop with WFIT for example
> > > (not WFET because of the event stream). As for user, we can expose a
> > > HWCAP but it's up to user libraries to make use of it.
> > 
> > Note that since c219bc4e9205K ("arm64: Trap WFI executed in
> > userspace"), we actively prevent WFI from being used in userspace, and
> > I would expect WFIT to be given the same treatment. It otherwise is a
> > precise tool for userspace to synchronise against kernel events.
> 
> I agree. I only thought about using it in the kernel as a simpler
> udelay(). The user should not attempt WFI/WFIT.

That's my position as well. I'll post a patch dealing with that
shortly.

> Now, if KVM traps WFI/WFIT as well, maybe we should not bother with
> udelay() in the kernel either.

"It depends". As long as there is no direct injection of interrupts
(GICv4+), WFI is always trapped. This saves us IPI-ing the physical
CPU to force an IRQ state reload.

However, when the vcpu can be targeted by directly injected interrupts
*and* that it is the only thread in the CPU's run queue, we stop
trapping WFI so that direct injection has a chance of doing its thing.

Of course, the number of systems implementing direct injection is so
far extremely close to zero, so I don't think it is worth basing
udelay() on that just yet.

KVM needs a bit of work to honour the timeout on trap as well, as
currently, a trapped WFIT without any interrupt being injected would
result in a guest that never make forward progress.

I'll put that on my list of things to look at.

Thanks,

	M.

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


From maz at kernel.org  Mon Apr 12 15:02:00 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 12 Apr 2021 15:02:00 +0100
Subject: ARM WFET application scenario consultation
In-Reply-To: <877dl7obpc.wl-maz@kernel.org>
References: <26f50e86-dc68-0aca-f29f-19ef2f884c5d@huawei.com>
 <20210412124637.GE2060@arm.com> <878s5nodjd.wl-maz@kernel.org>
 <20210412131520.GF2060@arm.com> <877dl7obpc.wl-maz@kernel.org>
Message-ID: <875z0rob3b.wl-maz@kernel.org>

On Mon, 12 Apr 2021 14:48:47 +0100,
Marc Zyngier <maz at kernel.org> wrote:
> 
> On Mon, 12 Apr 2021 14:15:21 +0100,
> Catalin Marinas <catalin.marinas at arm.com> wrote:
> > 
> > On Mon, Apr 12, 2021 at 02:09:10PM +0100, Marc Zyngier wrote:
> > > On Mon, 12 Apr 2021 13:46:37 +0100,
> > > Catalin Marinas <catalin.marinas at arm.com> wrote:
> > > > 
> > > > On Mon, Apr 12, 2021 at 08:08:23PM +0800, yangwendong wrote:
> > > > > Recently, a new feature of WFE with timeouts has been added to ARMv8.
> > > > > I have some doubts about the application scenarios of this feature.
> > > > > 
> > > > > 1) Arm spec said that WFE or WFET can be used in spinlock. Since the
> > > > > thread using spinlock can't be sleep, if we use the wfet instruction, we
> > > > > can do nothing but wait when timeout,  so what's the difference between
> > > > > the two instructions in this scenario?
> > > > 
> > > > Not much point in using it it in a classic spinlock, unless you have
> > > > some specific implementation that's supposed to time out.
> > > > 
> > > > Note that we already enabled the event stream in Linux so that an event
> > > > is generated at 100KHz waking up any WFE. One reason we had for this was
> > > > some hardware errata where events between clusters were not generated.
> > > > Another was some small delays required in in certain user programs
> > > > without going through a kernel syscall, though not sure anyone's
> > > > actually using it.
> > > > 
> > > > > 2) Are there any other special scenarios where using wfet instructions
> > > > > can be beneficial ?
> > > > 
> > > > In the kernel we could replace our udelay loop with WFIT for example
> > > > (not WFET because of the event stream). As for user, we can expose a
> > > > HWCAP but it's up to user libraries to make use of it.
> > > 
> > > Note that since c219bc4e9205K ("arm64: Trap WFI executed in
> > > userspace"), we actively prevent WFI from being used in userspace, and
> > > I would expect WFIT to be given the same treatment. It otherwise is a
> > > precise tool for userspace to synchronise against kernel events.
> > 
> > I agree. I only thought about using it in the kernel as a simpler
> > udelay(). The user should not attempt WFI/WFIT.
> 
> That's my position as well. I'll post a patch dealing with that
> shortly.

Actually, no need for that. WFIT gets correctly trapped and skipped
because ESR_ELx_WFx_ISS_TI only covers bit 0, meaning that WFIT is
handled just like WFI.

	M.

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


From nm at ti.com  Mon Apr 12 15:03:54 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 12 Apr 2021 09:03:54 -0500
Subject: [PATCH 2/2] arm64: dts: ti: k3-am654-base-board: remove ov5640
In-Reply-To: <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
References: <20210412075306.102884-1-tomi.valkeinen@ideasonboard.com>
 <20210412075306.102884-2-tomi.valkeinen@ideasonboard.com>
Message-ID: <20210412140354.bpwclelhcmepuepg@remodeler>

On 10:53-20210412, Tomi Valkeinen wrote:
> AM654 EVM boards are not shipped with OV5640 sensor module, it is a
> separate purchase. OV5640 module is also just one of the possible
> sensors or capture boards you can connect.
> 
> However, for some reason, OV5640 has been added to the board dts file,
> making it cumbersome to use other sensors.
> 
> Remove the OV5640 from the dts file so that it is easy to use other
> sensors via DT overlays.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
>  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 27 -------------------
>  1 file changed, 27 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index fe3043943906..76358b4944e1 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts

will be good if you can submit this patch separately. dra7 and am654 are
maintained in different trees.


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


From dillon.minfei at gmail.com  Mon Apr 12 15:04:06 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Mon, 12 Apr 2021 22:04:06 +0800
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
Message-ID: <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>

Hi Johan,

Yes, there is no deadlock. my fault.
I forget the local_irq_save() plus spin_lock() is spin_lock_irqsave().

Thanks for your review. please ignore this patch.

Best regards

Dillon

On Mon, Apr 12, 2021 at 9:08 PM Johan Hovold <johan at kernel.org> wrote:
>
> On Mon, Apr 12, 2021 at 05:31:38PM +0800, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
> > spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.
>
> This doesn't make much sense as console_write can be called in any
> context. And where's the deadlock you claim to be fixing here?
>
> > remove unused local_irq_save/restore call.
> >
> > Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> > Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> > Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> > Reported-by: kernel test robot <lkp at intel.com>
> > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > ---
> > v2: remove unused code from stm32_usart_threaded_interrupt() according from
> >     Greg's review.
> >
> >  drivers/tty/serial/stm32-usart.c | 8 +++-----
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > index b3675cf25a69..b1ba5e36e36e 100644
> > --- a/drivers/tty/serial/stm32-usart.c
> > +++ b/drivers/tty/serial/stm32-usart.c
> > @@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> >       u32 old_cr1, new_cr1;
> >       int locked = 1;
> >
> > -     local_irq_save(flags);
> >       if (port->sysrq)
> >               locked = 0;
> >       else if (oops_in_progress)
> > -             locked = spin_trylock(&port->lock);
> > +             locked = spin_trylock_irqsave(&port->lock, flags);
> >       else
> > -             spin_lock(&port->lock);
> > +             spin_lock_irqsave(&port->lock, flags);
> >
> >       /* Save and disable interrupts, enable the transmitter */
> >       old_cr1 = readl_relaxed(port->membase + ofs->cr1);
> > @@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> >       writel_relaxed(old_cr1, port->membase + ofs->cr1);
> >
> >       if (locked)
> > -             spin_unlock(&port->lock);
> > -     local_irq_restore(flags);
> > +             spin_unlock_irqrestore(&port->lock, flags);
> >  }
> >
> >  static int stm32_usart_console_setup(struct console *co, char *options)
>
> Johan


From yongqiang.niu at mediatek.com  Mon Apr 12 15:04:44 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:04:44 +0800
Subject: [PATCH v5, 0/4] soc: mediatek: mmsys: add mt8192 mmsys support
Message-ID: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>

base 5.12-rc2 and
https://patchwork.kernel.org/project/linux-mediatek/patch/20210330110423.3542163-1-hsinyi at chromium.org/

Change since v4:
- use routing table

Yongqiang Niu (4):
  soc: mediatek: mmsys: add component OVL_2L2
  soc: mediatek: mmsys: add component POSTMASK
  soc: mediatek: mmsys: add component RDMA4
  soc: mediatek: mmsys: Add mt8192 mmsys routing table

 drivers/soc/mediatek/mt8192-mmsys.h    | 68 ++++++++++++++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c       |  7 ++++
 include/linux/soc/mediatek/mtk-mmsys.h |  3 ++
 3 files changed, 78 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:04:46 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:04:46 +0800
Subject: [PATCH v5, 2/4] soc: mediatek: mmsys: add component POSTMASK
In-Reply-To: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618236288-1617-3-git-send-email-yongqiang.niu@mediatek.com>

This patch add component POSTMASK

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 include/linux/soc/mediatek/mtk-mmsys.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
index f6b58f9..7718cd6 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
 	DDP_COMPONENT_OVL_2L1,
 	DDP_COMPONENT_OVL_2L2,
 	DDP_COMPONENT_OVL1,
+	DDP_COMPONENT_POSTMASK0,
 	DDP_COMPONENT_PWM0,
 	DDP_COMPONENT_PWM1,
 	DDP_COMPONENT_PWM2,
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:04:45 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:04:45 +0800
Subject: [PATCH v5, 1/4] soc: mediatek: mmsys: add component OVL_2L2
In-Reply-To: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618236288-1617-2-git-send-email-yongqiang.niu@mediatek.com>

This patch add component OVL_2L2

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
---
 include/linux/soc/mediatek/mtk-mmsys.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
index 2228bf6..f6b58f9 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
 	DDP_COMPONENT_OVL0,
 	DDP_COMPONENT_OVL_2L0,
 	DDP_COMPONENT_OVL_2L1,
+	DDP_COMPONENT_OVL_2L2,
 	DDP_COMPONENT_OVL1,
 	DDP_COMPONENT_PWM0,
 	DDP_COMPONENT_PWM1,
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:04:47 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:04:47 +0800
Subject: [PATCH v5, 3/4] soc: mediatek: mmsys: add component RDMA4
In-Reply-To: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618236288-1617-4-git-send-email-yongqiang.niu@mediatek.com>

This patch add component RDMA4

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
---
 include/linux/soc/mediatek/mtk-mmsys.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
index 7718cd6..4bba275 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -38,6 +38,7 @@ enum mtk_ddp_comp_id {
 	DDP_COMPONENT_RDMA0,
 	DDP_COMPONENT_RDMA1,
 	DDP_COMPONENT_RDMA2,
+	DDP_COMPONENT_RDMA4,
 	DDP_COMPONENT_UFOE,
 	DDP_COMPONENT_WDMA0,
 	DDP_COMPONENT_WDMA1,
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:04:48 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:04:48 +0800
Subject: [PATCH v5, 4/4] soc: mediatek: mmsys: Add mt8192 mmsys routing table
In-Reply-To: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618236288-1617-5-git-send-email-yongqiang.niu@mediatek.com>

mt8192 has different routing registers than mt8183

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/soc/mediatek/mt8192-mmsys.h | 68 +++++++++++++++++++++++++++++++++++++
 drivers/soc/mediatek/mtk-mmsys.c    |  7 ++++
 2 files changed, 75 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h

diff --git a/drivers/soc/mediatek/mt8192-mmsys.h b/drivers/soc/mediatek/mt8192-mmsys.h
new file mode 100644
index 0000000..3179029
--- /dev/null
+++ b/drivers/soc/mediatek/mt8192-mmsys.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8192_MMSYS_H
+#define __SOC_MEDIATEK_MT8192_MMSYS_H
+
+#define MT8192_MMSYS_OVL_MOUT_EN		0xf04
+#define MT8192_DISP_OVL1_2L_MOUT_EN		0xf08
+#define MT8192_DISP_OVL0_2L_MOUT_EN		0xf18
+#define MT8192_DISP_OVL0_MOUT_EN		0xf1c
+#define MT8192_DISP_RDMA0_SEL_IN		0xf2c
+#define MT8192_DISP_RDMA0_SOUT_SEL		0xf30
+#define MT8192_DISP_CCORR0_SOUT_SEL		0xf34
+#define MT8192_DISP_AAL0_SEL_IN			0xf38
+#define MT8192_DISP_DITHER0_MOUT_EN		0xf3c
+#define MT8192_DISP_DSI0_SEL_IN			0xf40
+#define MT8192_DISP_OVL2_2L_MOUT_EN		0xf4c
+
+#define MT8192_DISP_OVL0_GO_BLEND			BIT(0)
+#define MT8192_DITHER0_MOUT_IN_DSI0			BIT(0)
+#define MT8192_OVL0_MOUT_EN_DISP_RDMA0			BIT(0)
+#define MT8192_OVL2_2L_MOUT_EN_RDMA4			BIT(0)
+#define MT8192_DISP_OVL0_GO_BG				BIT(1)
+#define MT8192_DISP_OVL0_2L_GO_BLEND			BIT(2)
+#define MT8192_DISP_OVL0_2L_GO_BG			BIT(3)
+#define MT8192_OVL1_2L_MOUT_EN_RDMA1			BIT(4)
+#define MT8192_OVL0_MOUT_EN_OVL0_2L			BIT(4)
+#define MT8192_RDMA0_SEL_IN_OVL0_2L			0x3
+#define MT8192_RDMA0_SOUT_COLOR0			0x1
+#define MT8192_CCORR0_SOUT_AAL0				0x1
+#define MT8192_AAL0_SEL_IN_CCORR0			0x1
+#define MT8192_DSI0_SEL_IN_DITHER0			0x1
+
+static const struct mtk_mmsys_routes mmsys_mt8192_routing_table[] = {
+	{
+		DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+		MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0,
+	}, {
+		DDP_COMPONENT_OVL_2L2, DDP_COMPONENT_RDMA4,
+		MT8192_DISP_OVL2_2L_MOUT_EN, MT8192_OVL2_2L_MOUT_EN_RDMA4
+	}, {
+		DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
+		MT8192_DISP_DITHER0_MOUT_EN, MT8192_DITHER0_MOUT_IN_DSI0
+	}, {
+		DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+		MT8192_DISP_RDMA0_SEL_IN, MT8192_RDMA0_SEL_IN_OVL0_2L
+	}, {
+		DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
+		MT8192_DISP_AAL0_SEL_IN, MT8192_AAL0_SEL_IN_CCORR0
+	}, {
+		DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
+		MT8192_DISP_DSI0_SEL_IN, MT8192_DSI0_SEL_IN_DITHER0
+	}, {
+		DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
+		MT8192_DISP_RDMA0_SOUT_SEL, MT8192_RDMA0_SOUT_COLOR0
+	}, {
+		DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
+		MT8192_DISP_CCORR0_SOUT_SEL, MT8192_CCORR0_SOUT_AAL0
+	}, {
+		DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
+		MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_GO_BG,
+	}, {
+		DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+		MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_2L_GO_BLEND,
+	}
+};
+
+#endif /* __SOC_MEDIATEK_MT8192_MMSYS_H */
+
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 79e5515..c755617 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -12,6 +12,7 @@
 
 #include "mtk-mmsys.h"
 #include "mt8183-mmsys.h"
+#include "mt8192-mmsys.h"
 
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
 	.clk_driver = "clk-mt2701-mm",
@@ -45,6 +46,12 @@
 	.num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
 };
 
+static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
+	.clk_driver = "clk-mt8192-mm",
+	.routes = mmsys_mt8192_routing_table,
+	.num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table),
+};
+
 struct mtk_mmsys {
 	void __iomem *regs;
 	const struct mtk_mmsys_driver_data *data;
-- 
1.8.1.1.dirty

From andriy.shevchenko at linux.intel.com  Mon Apr 12 15:07:39 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 12 Apr 2021 17:07:39 +0300
Subject: [PATCH v1 1/3] pinctrl: Keep enum pin_config_param ordered by name
Message-ID: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>

It seems the ordering is by name. Keep it that way.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 include/linux/pinctrl/pinconf-generic.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index 6aeb711f7cd1..188db8d84162 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -90,6 +90,7 @@ struct pinctrl_map;
  * 	value on the line. Use argument 1 to indicate high level, argument 0 to
  *	indicate low level. (Please see Documentation/driver-api/pinctl.rst,
  *	section "GPIO mode pitfalls" for a discussion around this parameter.)
+ * @PIN_CONFIG_PERSIST_STATE: retain pin state across sleep or controller reset
  * @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
  *	supplies, the argument to this parameter (on a custom format) tells
  *	the driver which alternative power source to use.
@@ -101,7 +102,6 @@ struct pinctrl_map;
  *	or latch delay (on outputs) this parameter (in a custom format)
  *	specifies the clock skew or latch delay. It typically controls how
  *	many double inverters are put in front of the line.
- * @PIN_CONFIG_PERSIST_STATE: retain pin state across sleep or controller reset
  * @PIN_CONFIG_END: this is the last enumerator for pin configurations, if
  *	you need to pass in custom configurations to the pin controller, use
  *	PIN_CONFIG_END+1 as the base offset.
@@ -127,11 +127,11 @@ enum pin_config_param {
 	PIN_CONFIG_LOW_POWER_MODE,
 	PIN_CONFIG_OUTPUT_ENABLE,
 	PIN_CONFIG_OUTPUT,
+	PIN_CONFIG_PERSIST_STATE,
 	PIN_CONFIG_POWER_SOURCE,
 	PIN_CONFIG_SLEEP_HARDWARE_STATE,
 	PIN_CONFIG_SLEW_RATE,
 	PIN_CONFIG_SKEW_DELAY,
-	PIN_CONFIG_PERSIST_STATE,
 	PIN_CONFIG_END = 0x7F,
 	PIN_CONFIG_MAX = 0xFF,
 };
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 12 15:07:41 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 12 Apr 2021 17:07:41 +0300
Subject: [PATCH v1 3/3] pinctrl: Add PIN_CONFIG_MODE_PWM to enum
 pin_config_param
In-Reply-To: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
References: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210412140741.39946-3-andriy.shevchenko@linux.intel.com>

It seems that we will have more and more pin controllers that support
PWM function on the (selected) pins. Due to it being a part of pin
controller IP the idea is to have some code that will switch the mode
and attach the corresponding driver, for example, via using it as
a library. Meanwhile, put a corresponding item to the pin_config_param
enumerator.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 include/linux/pinctrl/pinconf-generic.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index 189e701832ea..e18ab3d5908f 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -80,6 +80,7 @@ struct pinctrl_map;
  *	operation, if several modes of operation are supported these can be
  *	passed in the argument on a custom form, else just use argument 1
  *	to indicate low power mode, argument 0 turns low power mode off.
+ * @PIN_CONFIG_MODE_PWM: this will configure the pin for PWM
  * @PIN_CONFIG_OUTPUT_ENABLE: this will enable the pin's output mode
  * 	without driving a value there. For most platforms this reduces to
  * 	enable the output buffers and then let the pin controller current
@@ -125,6 +126,7 @@ enum pin_config_param {
 	PIN_CONFIG_INPUT_SCHMITT,
 	PIN_CONFIG_INPUT_SCHMITT_ENABLE,
 	PIN_CONFIG_MODE_LOW_POWER,
+	PIN_CONFIG_MODE_PWM,
 	PIN_CONFIG_OUTPUT_ENABLE,
 	PIN_CONFIG_OUTPUT,
 	PIN_CONFIG_PERSIST_STATE,
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 12 15:07:40 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 12 Apr 2021 17:07:40 +0300
Subject: [PATCH v1 2/3] pinctrl: Introduce MODE group in enum pin_config_param
In-Reply-To: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
References: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210412140741.39946-2-andriy.shevchenko@linux.intel.com>

Better to have a MODE group of settings to keep them together
when ordered alphabetically. Hence, rename PIN_CONFIG_LOW_POWER_MODE
to PIN_CONFIG_MODE_LOW_POWER.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/pinctrl/pinconf-generic.c       | 6 +++---
 drivers/pinctrl/pinctrl-lpc18xx.c       | 4 ++--
 drivers/pinctrl/pinctrl-single.c        | 6 +++---
 drivers/pinctrl/pinctrl-zynq.c          | 4 ++--
 drivers/pinctrl/pxa/pinctrl-pxa2xx.c    | 4 ++--
 drivers/soc/tegra/pmc.c                 | 4 ++--
 include/linux/pinctrl/pinconf-generic.h | 4 ++--
 7 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/pinconf-generic.c b/drivers/pinctrl/pinconf-generic.c
index 1e225d513988..22e8d4c4040e 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -43,7 +43,7 @@ static const struct pin_config_item conf_items[] = {
 	PCONFDUMP(PIN_CONFIG_INPUT_ENABLE, "input enabled", NULL, false),
 	PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT, "input schmitt trigger", NULL, false),
 	PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT_ENABLE, "input schmitt enabled", NULL, false),
-	PCONFDUMP(PIN_CONFIG_LOW_POWER_MODE, "pin low power", "mode", true),
+	PCONFDUMP(PIN_CONFIG_MODE_LOW_POWER, "pin low power", "mode", true),
 	PCONFDUMP(PIN_CONFIG_OUTPUT_ENABLE, "output enabled", NULL, false),
 	PCONFDUMP(PIN_CONFIG_OUTPUT, "pin output", "level", true),
 	PCONFDUMP(PIN_CONFIG_POWER_SOURCE, "pin power source", "selector", true),
@@ -174,8 +174,8 @@ static const struct pinconf_generic_params dt_params[] = {
 	{ "input-schmitt", PIN_CONFIG_INPUT_SCHMITT, 0 },
 	{ "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
 	{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
-	{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
-	{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
+	{ "low-power-disable", PIN_CONFIG_MODE_LOW_POWER, 0 },
+	{ "low-power-enable", PIN_CONFIG_MODE_LOW_POWER, 1 },
 	{ "output-disable", PIN_CONFIG_OUTPUT_ENABLE, 0 },
 	{ "output-enable", PIN_CONFIG_OUTPUT_ENABLE, 1 },
 	{ "output-high", PIN_CONFIG_OUTPUT, 1, },
diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c b/drivers/pinctrl/pinctrl-lpc18xx.c
index 7b2f885e68bd..ed9bf2c89998 100644
--- a/drivers/pinctrl/pinctrl-lpc18xx.c
+++ b/drivers/pinctrl/pinctrl-lpc18xx.c
@@ -646,7 +646,7 @@ static const struct pin_config_item lpc18xx_conf_items[ARRAY_SIZE(lpc18xx_params
 static int lpc18xx_pconf_get_usb1(enum pin_config_param param, int *arg, u32 reg)
 {
 	switch (param) {
-	case PIN_CONFIG_LOW_POWER_MODE:
+	case PIN_CONFIG_MODE_LOW_POWER:
 		if (reg & LPC18XX_SCU_USB1_EPWR)
 			*arg = 0;
 		else
@@ -904,7 +904,7 @@ static int lpc18xx_pconf_set_usb1(struct pinctrl_dev *pctldev,
 				  u32 param_val, u32 *reg)
 {
 	switch (param) {
-	case PIN_CONFIG_LOW_POWER_MODE:
+	case PIN_CONFIG_MODE_LOW_POWER:
 		if (param_val)
 			*reg &= ~LPC18XX_SCU_USB1_EPWR;
 		else
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 39aac32ed09c..2c9c9835f375 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -533,7 +533,7 @@ static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
 			break;
 		case PIN_CONFIG_DRIVE_STRENGTH:
 		case PIN_CONFIG_SLEW_RATE:
-		case PIN_CONFIG_LOW_POWER_MODE:
+		case PIN_CONFIG_MODE_LOW_POWER:
 		default:
 			*config = data;
 			break;
@@ -571,7 +571,7 @@ static int pcs_pinconf_set(struct pinctrl_dev *pctldev,
 			case PIN_CONFIG_INPUT_SCHMITT:
 			case PIN_CONFIG_DRIVE_STRENGTH:
 			case PIN_CONFIG_SLEW_RATE:
-			case PIN_CONFIG_LOW_POWER_MODE:
+			case PIN_CONFIG_MODE_LOW_POWER:
 				shift = ffs(func->conf[i].mask) - 1;
 				data &= ~func->conf[i].mask;
 				data |= (arg << shift) & func->conf[i].mask;
@@ -919,7 +919,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, struct device_node *np,
 		{ "pinctrl-single,drive-strength", PIN_CONFIG_DRIVE_STRENGTH, },
 		{ "pinctrl-single,slew-rate", PIN_CONFIG_SLEW_RATE, },
 		{ "pinctrl-single,input-schmitt", PIN_CONFIG_INPUT_SCHMITT, },
-		{ "pinctrl-single,low-power-mode", PIN_CONFIG_LOW_POWER_MODE, },
+		{ "pinctrl-single,low-power-mode", PIN_CONFIG_MODE_LOW_POWER, },
 	};
 	static const struct pcs_conf_type prop4[] = {
 		{ "pinctrl-single,bias-pullup", PIN_CONFIG_BIAS_PULL_UP, },
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index c6052a0e827a..5fb924a2eedd 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -1016,7 +1016,7 @@ static int zynq_pinconf_cfg_get(struct pinctrl_dev *pctldev,
 	case PIN_CONFIG_SLEW_RATE:
 		arg = !!(reg & ZYNQ_PINCONF_SPEED);
 		break;
-	case PIN_CONFIG_LOW_POWER_MODE:
+	case PIN_CONFIG_MODE_LOW_POWER:
 	{
 		enum zynq_io_standards iostd = zynq_pinconf_iostd_get(reg);
 
@@ -1087,7 +1087,7 @@ static int zynq_pinconf_cfg_set(struct pinctrl_dev *pctldev,
 			reg &= ~ZYNQ_PINCONF_IOTYPE_MASK;
 			reg |= arg << ZYNQ_PINCONF_IOTYPE_SHIFT;
 			break;
-		case PIN_CONFIG_LOW_POWER_MODE:
+		case PIN_CONFIG_MODE_LOW_POWER:
 			if (arg)
 				reg |= ZYNQ_PINCONF_DISABLE_RECVR;
 			else
diff --git a/drivers/pinctrl/pxa/pinctrl-pxa2xx.c b/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
index eab029a21643..d2568dab8c78 100644
--- a/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
+++ b/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
@@ -194,7 +194,7 @@ static int pxa2xx_pconf_group_get(struct pinctrl_dev *pctldev,
 
 	spin_lock_irqsave(&pctl->lock, flags);
 	val = readl_relaxed(pgsr) & BIT(pin % 32);
-	*config = val ? PIN_CONFIG_LOW_POWER_MODE : 0;
+	*config = val ? PIN_CONFIG_MODE_LOW_POWER : 0;
 	spin_unlock_irqrestore(&pctl->lock, flags);
 
 	dev_dbg(pctl->dev, "get sleep gpio state(pin=%d) %d\n",
@@ -217,7 +217,7 @@ static int pxa2xx_pconf_group_set(struct pinctrl_dev *pctldev,
 
 	for (i = 0; i < num_configs; i++) {
 		switch (pinconf_to_config_param(configs[i])) {
-		case PIN_CONFIG_LOW_POWER_MODE:
+		case PIN_CONFIG_MODE_LOW_POWER:
 			is_set = pinconf_to_config_argument(configs[i]);
 			break;
 		default:
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 6bd22359d411..8e3b78bb2ac2 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -1904,7 +1904,7 @@ static int tegra_io_pad_pinconf_get(struct pinctrl_dev *pctl_dev,
 		arg = ret;
 		break;
 
-	case PIN_CONFIG_LOW_POWER_MODE:
+	case PIN_CONFIG_MODE_LOW_POWER:
 		ret = tegra_io_pad_is_powered(pmc, pad->id);
 		if (ret < 0)
 			return ret;
@@ -1941,7 +1941,7 @@ static int tegra_io_pad_pinconf_set(struct pinctrl_dev *pctl_dev,
 		arg = pinconf_to_config_argument(configs[i]);
 
 		switch (param) {
-		case PIN_CONFIG_LOW_POWER_MODE:
+		case PIN_CONFIG_MODE_LOW_POWER:
 			if (arg)
 				err = tegra_io_pad_power_disable(pad->id);
 			else
diff --git a/include/linux/pinctrl/pinconf-generic.h b/include/linux/pinctrl/pinconf-generic.h
index 188db8d84162..189e701832ea 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -76,7 +76,7 @@ struct pinctrl_map;
  * @PIN_CONFIG_INPUT_SCHMITT_ENABLE: control schmitt-trigger mode on the pin.
  *      If the argument != 0, schmitt-trigger mode is enabled. If it's 0,
  *      schmitt-trigger mode is disabled.
- * @PIN_CONFIG_LOW_POWER_MODE: this will configure the pin for low power
+ * @PIN_CONFIG_MODE_LOW_POWER: this will configure the pin for low power
  *	operation, if several modes of operation are supported these can be
  *	passed in the argument on a custom form, else just use argument 1
  *	to indicate low power mode, argument 0 turns low power mode off.
@@ -124,7 +124,7 @@ enum pin_config_param {
 	PIN_CONFIG_INPUT_ENABLE,
 	PIN_CONFIG_INPUT_SCHMITT,
 	PIN_CONFIG_INPUT_SCHMITT_ENABLE,
-	PIN_CONFIG_LOW_POWER_MODE,
+	PIN_CONFIG_MODE_LOW_POWER,
 	PIN_CONFIG_OUTPUT_ENABLE,
 	PIN_CONFIG_OUTPUT,
 	PIN_CONFIG_PERSIST_STATE,
-- 
2.30.2



From Eugen.Hristev at microchip.com  Mon Apr 12 15:15:32 2021
From: Eugen.Hristev at microchip.com (Eugen.Hristev at microchip.com)
Date: Mon, 12 Apr 2021 14:15:32 +0000
Subject: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc
 driver
In-Reply-To: <20210412134157.4cqva5thylmiqds7@uno.localdomain>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-31-eugen.hristev@microchip.com>
 <a22c2065-1a79-8a96-2b54-a2e28fa08b8a@microchip.com>
 <20210412134157.4cqva5thylmiqds7@uno.localdomain>
Message-ID: <52f03c2b-01bd-0de3-83c5-204e6b577b9d@microchip.com>

On 4/12/21 4:41 PM, Jacopo Mondi wrote:
> Hi Eugene,
> 
> On Mon, Apr 12, 2021 at 12:37:41PM +0000, Eugen.Hristev at microchip.com wrote:
>>> +static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
>>> +{
>>> +   struct device_node *np = dev->of_node;
>>> +   struct device_node *epn = NULL;
>>> +   struct isc_subdev_entity *subdev_entity;
>>> +   unsigned int flags;
>>> +   int ret;
>>> +   bool mipi_mode;
>>> +
>>> +   INIT_LIST_HEAD(&isc->subdev_entities);
>>> +
>>> +   mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
>>> +
>>> +   while (1) {
>>> +           struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
>>> +
>>> +           epn = of_graph_get_next_endpoint(np, epn);
>>> +           if (!epn)
>>> +                   return 0;
>>> +
>>> +           ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
>>> +                                            &v4l2_epn);
>>> +           if (ret) {
>>> +                   ret = -EINVAL;
>>> +                   dev_err(dev, "Could not parse the endpoint\n");
>>> +                   break;
>>> +           }
>>> +
>>> +           subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
>>> +                                        GFP_KERNEL);
>>> +           if (!subdev_entity) {
>>> +                   ret = -ENOMEM;
>>> +                   break;
>>> +           }
>>> +           subdev_entity->epn = epn;
>>> +
>>> +           flags = v4l2_epn.bus.parallel.flags;
>>> +
>>> +           if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
>>> +                   subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
>>> +
>>> +           if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
>>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
>>> +
>>> +           if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
>>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>>> +
>>> +           if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
>>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
>>> +                                   ISC_PFE_CFG0_CCIR656;
>>
>> Hi Jacopo,
>>
>> If I use the bus-type property for the 'port' , do I actually have to
>> change something here ?
> 
> You can set bus_type to the desired type, if it doesn't match the
> 'bus-type' property you will have an immediate error and a more strict
> check on the properties.
> 
> You would likely:
> 
>          v4l2_epn.bus_type = V4L2_MBUS_PARALLEL;
>          ret = v4l2_fwnode_endpoint_parse()
>          if (!ret) {
>                  /* It's parallel */
>          } else {
>                  v4l2_epn.bus_type = V4L2_MBUS_BT656;
>                  ret = v4l2_fwnode_endpoint_parse()
>                  if (ret) {
>                          /* Unsupported bus type: error out. */
>                  }
> 
>                  /* It's BT656 */
>          }

if the v4l2_fwnode_endpoint_parse will already fill in the 
v4l2_epn.bus_type based on what is found in the 'bus-type' , why do I 
need to do this assumption-fail-assumption-fail scenario ?
Can't I simply check the value of v4l2_epn.bus_type , as I am doing it 
already ?

> 
> Not the greatest API, but it's more robust.
> 
>> the v4l2_epn.bus_type won't be set automatically ? by the endpoint
>> parser I mean.
> 
> Yes, that's what auto-discovery is, the endpoint parser tries to
> deduce the bus type from the properties that are there specified. It
> works, but leaves quite some ambiguity between ie PARALLEL and BT656
> as some polarities might not be necessarily specified even for
> PARALLEL bus types.
> 
> As I've said, there's still plenty of code that relies on
> auto-discovery so I don't think this is blocking, also because making
> bus-type mandatory on existing DTS is quite painful. Since this is a
> new DTS you can consider this solution if you want to.
> 
> Thanks
>     j
> 
>>
>> Thanks,
>> Eugen
>>
>>> +
>>> +           if (mipi_mode)
>>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
>>> +
>>> +           list_add_tail(&subdev_entity->list, &isc->subdev_entities);
>>> +   }
>>> +   of_node_put(epn);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static int microchip_xisc_probe(struct platform_device *pdev)
>>> +{
>>> +   struct device *dev = &pdev->dev;
>>> +   struct isc_device *isc;
>>> +   struct resource *res;
>>> +   void __iomem *io_base;
>>> +   struct isc_subdev_entity *subdev_entity;
>>> +   int irq;
>>> +   int ret;
>>> +   u32 ver;
>>> +
>>> +   isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
>>> +   if (!isc)
>>> +           return -ENOMEM;
>>> +
>>> +   platform_set_drvdata(pdev, isc);
>>> +   isc->dev = dev;
>>> +
>>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +   io_base = devm_ioremap_resource(dev, res);
>>> +   if (IS_ERR(io_base))
>>> +           return PTR_ERR(io_base);
>>> +
>>> +   isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
>>> +   if (IS_ERR(isc->regmap)) {
>>> +           ret = PTR_ERR(isc->regmap);
>>> +           dev_err(dev, "failed to init register map: %d\n", ret);
>>> +           return ret;
>>> +   }
>>> +
>>> +   irq = platform_get_irq(pdev, 0);
>>> +   if (irq < 0)
>>> +           return irq;
>>> +
>>> +   ret = devm_request_irq(dev, irq, isc_interrupt, 0,
>>> +                          "microchip-sama7g5-xisc", isc);
>>> +   if (ret < 0) {
>>> +           dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
>>> +                   irq, ret);
>>> +           return ret;
>>> +   }
>>> +
>>> +   isc->gamma_table = isc_sama7g5_gamma_table;
>>> +   isc->gamma_max = 0;
>>> +
>>> +   isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
>>> +   isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
>>> +
>>> +   isc->config_dpc = isc_sama7g5_config_dpc;
>>> +   isc->config_csc = isc_sama7g5_config_csc;
>>> +   isc->config_cbc = isc_sama7g5_config_cbc;
>>> +   isc->config_cc = isc_sama7g5_config_cc;
>>> +   isc->config_gam = isc_sama7g5_config_gam;
>>> +   isc->config_rlp = isc_sama7g5_config_rlp;
>>> +   isc->config_ctrls = isc_sama7g5_config_ctrls;
>>> +
>>> +   isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
>>> +
>>> +   isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
>>> +   isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
>>> +   isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
>>> +   isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
>>> +   isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
>>> +   isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
>>> +   isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
>>> +   isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
>>> +   isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
>>> +
>>> +   isc->controller_formats = sama7g5_controller_formats;
>>> +   isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
>>> +   isc->formats_list = sama7g5_formats_list;
>>> +   isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
>>> +
>>> +   /* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
>>> +   isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
>>> +
>>> +   ret = isc_pipeline_init(isc);
>>> +   if (ret)
>>> +           return ret;
>>> +
>>> +   isc->hclock = devm_clk_get(dev, "hclock");
>>> +   if (IS_ERR(isc->hclock)) {
>>> +           ret = PTR_ERR(isc->hclock);
>>> +           dev_err(dev, "failed to get hclock: %d\n", ret);
>>> +           return ret;
>>> +   }
>>> +
>>> +   ret = clk_prepare_enable(isc->hclock);
>>> +   if (ret) {
>>> +           dev_err(dev, "failed to enable hclock: %d\n", ret);
>>> +           return ret;
>>> +   }
>>> +
>>> +   ret = isc_clk_init(isc);
>>> +   if (ret) {
>>> +           dev_err(dev, "failed to init isc clock: %d\n", ret);
>>> +           goto unprepare_hclk;
>>> +   }
>>> +
>>> +   isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
>>> +
>>> +   ret = clk_prepare_enable(isc->ispck);
>>> +   if (ret) {
>>> +           dev_err(dev, "failed to enable ispck: %d\n", ret);
>>> +           goto unprepare_hclk;
>>> +   }
>>> +
>>> +   /* ispck should be greater or equal to hclock */
>>> +   ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
>>> +   if (ret) {
>>> +           dev_err(dev, "failed to set ispck rate: %d\n", ret);
>>> +           goto unprepare_clk;
>>> +   }
>>> +
>>> +   ret = v4l2_device_register(dev, &isc->v4l2_dev);
>>> +   if (ret) {
>>> +           dev_err(dev, "unable to register v4l2 device.\n");
>>> +           goto unprepare_clk;
>>> +   }
>>> +
>>> +   ret = xisc_parse_dt(dev, isc);
>>> +   if (ret) {
>>> +           dev_err(dev, "fail to parse device tree\n");
>>> +           goto unregister_v4l2_device;
>>> +   }
>>> +
>>> +   if (list_empty(&isc->subdev_entities)) {
>>> +           dev_err(dev, "no subdev found\n");
>>> +           ret = -ENODEV;
>>> +           goto unregister_v4l2_device;
>>> +   }
>>> +
>>> +   list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
>>> +           struct v4l2_async_subdev *asd;
>>> +
>>> +           v4l2_async_notifier_init(&subdev_entity->notifier);
>>> +
>>> +           asd = v4l2_async_notifier_add_fwnode_remote_subdev(
>>> +                                   &subdev_entity->notifier,
>>> +                                   of_fwnode_handle(subdev_entity->epn),
>>> +                                   struct v4l2_async_subdev);
>>> +
>>> +           of_node_put(subdev_entity->epn);
>>> +           subdev_entity->epn = NULL;
>>> +
>>> +           if (IS_ERR(asd)) {
>>> +                   ret = PTR_ERR(asd);
>>> +                   goto cleanup_subdev;
>>> +           }
>>> +
>>> +           subdev_entity->notifier.ops = &isc_async_ops;
>>> +
>>> +           ret = v4l2_async_notifier_register(&isc->v4l2_dev,
>>> +                                              &subdev_entity->notifier);
>>> +           if (ret) {
>>> +                   dev_err(dev, "fail to register async notifier\n");
>>> +                   goto cleanup_subdev;
>>> +           }
>>> +
>>> +           if (video_is_registered(&isc->video_dev))
>>> +                   break;
>>> +   }
>>> +
>>> +   pm_runtime_set_active(dev);
>>> +   pm_runtime_enable(dev);
>>> +   pm_request_idle(dev);
>>> +
>>> +   regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
>>> +   dev_info(dev, "Microchip XISC version %x\n", ver);
>>> +
>>> +   return 0;
>>> +
>>> +cleanup_subdev:
>>> +   isc_subdev_cleanup(isc);
>>> +
>>> +unregister_v4l2_device:
>>> +   v4l2_device_unregister(&isc->v4l2_dev);
>>> +
>>> +unprepare_clk:
>>> +   clk_disable_unprepare(isc->ispck);
>>> +unprepare_hclk:
>>> +   clk_disable_unprepare(isc->hclock);
>>> +
>>> +   isc_clk_cleanup(isc);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static int microchip_xisc_remove(struct platform_device *pdev)
>>> +{
>>> +   struct isc_device *isc = platform_get_drvdata(pdev);
>>> +
>>> +   pm_runtime_disable(&pdev->dev);
>>> +
>>> +   isc_subdev_cleanup(isc);
>>> +
>>> +   v4l2_device_unregister(&isc->v4l2_dev);
>>> +
>>> +   clk_disable_unprepare(isc->ispck);
>>> +   clk_disable_unprepare(isc->hclock);
>>> +
>>> +   isc_clk_cleanup(isc);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int __maybe_unused xisc_runtime_suspend(struct device *dev)
>>> +{
>>> +   struct isc_device *isc = dev_get_drvdata(dev);
>>> +
>>> +   clk_disable_unprepare(isc->ispck);
>>> +   clk_disable_unprepare(isc->hclock);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static int __maybe_unused xisc_runtime_resume(struct device *dev)
>>> +{
>>> +   struct isc_device *isc = dev_get_drvdata(dev);
>>> +   int ret;
>>> +
>>> +   ret = clk_prepare_enable(isc->hclock);
>>> +   if (ret)
>>> +           return ret;
>>> +
>>> +   ret = clk_prepare_enable(isc->ispck);
>>> +   if (ret)
>>> +           clk_disable_unprepare(isc->hclock);
>>> +
>>> +   return ret;
>>> +}
>>> +
>>> +static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
>>> +   SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
>>> +};
>>> +
>>> +static const struct of_device_id microchip_xisc_of_match[] = {
>>> +   { .compatible = "microchip,sama7g5-isc" },
>>> +   { }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
>>> +
>>> +static struct platform_driver microchip_xisc_driver = {
>>> +   .probe  = microchip_xisc_probe,
>>> +   .remove = microchip_xisc_remove,
>>> +   .driver = {
>>> +           .name           = "microchip-sama7g5-xisc",
>>> +           .pm             = &microchip_xisc_dev_pm_ops,
>>> +           .of_match_table = of_match_ptr(microchip_xisc_of_match),
>>> +   },
>>> +};
>>> +
>>> +module_platform_driver(microchip_xisc_driver);
>>> +
>>> +MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
>>> +MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_SUPPORTED_DEVICE("video");
>>>
>>


From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:42 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:42 +0800
Subject: [PATCH v7, 1/5] drm/mediatek: add component OVL_2L2
In-Reply-To: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618237306-17670-2-git-send-email-yongqiang.niu@mediatek.com>

This patch add component OVL_2L2

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 75bc00e..b564513 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -385,6 +385,7 @@ struct mtk_ddp_comp_match {
 	[DDP_COMPONENT_OVL1]	= { MTK_DISP_OVL,	1, &ddp_ovl },
 	[DDP_COMPONENT_OVL_2L0]	= { MTK_DISP_OVL_2L,	0, &ddp_ovl },
 	[DDP_COMPONENT_OVL_2L1]	= { MTK_DISP_OVL_2L,	1, &ddp_ovl },
+	[DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,    2, &ddp_ovl },
 	[DDP_COMPONENT_PWM0]	= { MTK_DISP_PWM,	0, NULL },
 	[DDP_COMPONENT_PWM1]	= { MTK_DISP_PWM,	1, NULL },
 	[DDP_COMPONENT_PWM2]	= { MTK_DISP_PWM,	2, NULL },
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:41 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:41 +0800
Subject: [PATCH v7, 0/5] drm/mediatek: add support for mediatek SOC MT8192
Message-ID: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>

This series are based on Linux v5.12-rc2
and following patch:
https://patchwork.kernel.org/project/linux-mediatek/cover/1618236288-1617-1-git-send-email-yongqiang.niu at mediatek.com/

Change since v6:
- rebase


Yongqiang Niu (5):
  drm/mediatek: add component OVL_2L2
  drm/mediatek: add component POSTMASK
  drm/mediatek: add component RDMA4
  soc: mediatek: add mtk mutex support for MT8192
  drm/mediatek: add support for mediatek SOC MT8192

 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c   |   6 ++
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c     |  20 ++++++
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c    |   6 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++++++++++++++++++++--------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c      |  42 ++++++++++++
 drivers/soc/mediatek/mtk-mutex.c            |  35 ++++++++++
 7 files changed, 183 insertions(+), 29 deletions(-)

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:44 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:44 +0800
Subject: [PATCH v7, 3/5] drm/mediatek: add component RDMA4
In-Reply-To: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618237306-17670-4-git-send-email-yongqiang.niu@mediatek.com>

This patch add component RDMA4

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 17309ce..ebe8eec 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -434,6 +434,7 @@ struct mtk_ddp_comp_match {
 	[DDP_COMPONENT_RDMA0]		= { MTK_DISP_RDMA,	0, &ddp_rdma },
 	[DDP_COMPONENT_RDMA1]		= { MTK_DISP_RDMA,	1, &ddp_rdma },
 	[DDP_COMPONENT_RDMA2]		= { MTK_DISP_RDMA,	2, &ddp_rdma },
+	[DDP_COMPONENT_RDMA4]		= { MTK_DISP_RDMA,      4, &ddp_rdma },
 	[DDP_COMPONENT_UFOE]		= { MTK_DISP_UFOE,	0, &ddp_ufoe },
 	[DDP_COMPONENT_WDMA0]		= { MTK_DISP_WDMA,	0, NULL },
 	[DDP_COMPONENT_WDMA1]		= { MTK_DISP_WDMA,	1, NULL },
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:45 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:45 +0800
Subject: [PATCH v7, 4/5] soc: mediatek: add mtk mutex support for MT8192
In-Reply-To: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618237306-17670-5-git-send-email-yongqiang.niu@mediatek.com>

Add mtk mutex support for MT8192 SoC.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
---
 drivers/soc/mediatek/mtk-mutex.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 718a41b..dfd9806 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -39,6 +39,18 @@
 #define MT8167_MUTEX_MOD_DISP_DITHER		15
 #define MT8167_MUTEX_MOD_DISP_UFOE		16
 
+#define MT8192_MUTEX_MOD_DISP_OVL0		0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L		1
+#define MT8192_MUTEX_MOD_DISP_RDMA0		2
+#define MT8192_MUTEX_MOD_DISP_COLOR0		4
+#define MT8192_MUTEX_MOD_DISP_CCORR0		5
+#define MT8192_MUTEX_MOD_DISP_AAL0		6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0		7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK0		8
+#define MT8192_MUTEX_MOD_DISP_DITHER0		9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L		16
+#define MT8192_MUTEX_MOD_DISP_RDMA4		17
+
 #define MT8183_MUTEX_MOD_DISP_RDMA0		0
 #define MT8183_MUTEX_MOD_DISP_RDMA1		1
 #define MT8183_MUTEX_MOD_DISP_OVL0		9
@@ -214,6 +226,20 @@ struct mtk_mutex_ctx {
 	[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
 };
 
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+	[DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+	[DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
+	[DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
+	[DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
+	[DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
+	[DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
+	[DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
+	[DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
+	[DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
+	[DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
+	[DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
+};
+
 static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
 	[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
 	[MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -275,6 +301,13 @@ struct mtk_mutex_ctx {
 	.no_clk = true,
 };
 
+static const struct mtk_mutex_data mt8192_mutex_driver_data = {
+	.mutex_mod = mt8192_mutex_mod,
+	.mutex_sof = mt8183_mutex_sof,
+	.mutex_mod_reg = MT8183_MUTEX0_MOD0,
+	.mutex_sof_reg = MT8183_MUTEX0_SOF0,
+};
+
 struct mtk_mutex *mtk_mutex_get(struct device *dev)
 {
 	struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
@@ -507,6 +540,8 @@ static int mtk_mutex_remove(struct platform_device *pdev)
 	  .data = &mt8173_mutex_driver_data},
 	{ .compatible = "mediatek,mt8183-disp-mutex",
 	  .data = &mt8183_mutex_driver_data},
+	{ .compatible = "mediatek,mt8192-disp-mutex",
+	  .data = &mt8192_mutex_driver_data},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:43 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:43 +0800
Subject: [PATCH v7, 2/5] drm/mediatek: add component POSTMASK
In-Reply-To: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618237306-17670-3-git-send-email-yongqiang.niu@mediatek.com>

This patch add component POSTMASK.

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++++++++++++++++++++--------
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   1 +
 2 files changed, 73 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index b564513..17309ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -50,6 +50,12 @@
 
 #define AAL_EN					BIT(0)
 
+#define DISP_POSTMASK_EN			0x0000
+#define POSTMASK_EN				BIT(0)
+#define DISP_POSTMASK_CFG			0x0020
+#define POSTMASK_RELAY_MODE			BIT(0)
+#define DISP_POSTMASK_SIZE			0x0030
+
 #define DISP_DITHERING				BIT(2)
 #define DITHER_LSB_ERR_SHIFT_R(x)		(((x) & 0x7) << 28)
 #define DITHER_OVFLW_BIT_R(x)			(((x) & 0x7) << 24)
@@ -190,6 +196,32 @@ static void mtk_ufoe_start(struct device *dev)
 	writel(UFO_BYPASS, priv->regs + DISP_REG_UFO_START);
 }
 
+static void mtk_postmask_config(struct device *dev, unsigned int w,
+			unsigned int h, unsigned int vrefresh,
+			unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+	mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs,
+		      DISP_POSTMASK_SIZE);
+	mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, &priv->cmdq_reg,
+		      priv->regs, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct device *dev)
+{
+	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+	writel(POSTMASK_EN, priv->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct device *dev)
+{
+	struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+	writel_relaxed(0x0, priv->regs + DISP_POSTMASK_EN);
+}
+
 static void mtk_aal_config(struct device *dev, unsigned int w,
 			   unsigned int h, unsigned int vrefresh,
 			   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -321,6 +353,14 @@ static void mtk_dither_stop(struct device *dev)
 	.bgclr_in_off = mtk_ovl_bgclr_in_off,
 };
 
+static const struct mtk_ddp_comp_funcs ddp_postmask = {
+	.clk_enable = mtk_ddp_clk_enable,
+	.clk_disable = mtk_ddp_clk_disable,
+	.config = mtk_postmask_config,
+	.start = mtk_postmask_start,
+	.stop = mtk_postmask_stop,
+};
+
 static const struct mtk_ddp_comp_funcs ddp_rdma = {
 	.clk_enable = mtk_rdma_clk_enable,
 	.clk_disable = mtk_rdma_clk_disable,
@@ -356,6 +396,7 @@ static void mtk_dither_stop(struct device *dev)
 	[MTK_DISP_MUTEX] = "mutex",
 	[MTK_DISP_OD] = "od",
 	[MTK_DISP_BLS] = "bls",
+	[MTK_DISP_POSTMASK] = "postmask",
 };
 
 struct mtk_ddp_comp_match {
@@ -365,36 +406,37 @@ struct mtk_ddp_comp_match {
 };
 
 static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
-	[DDP_COMPONENT_AAL0]	= { MTK_DISP_AAL,	0, &ddp_aal },
-	[DDP_COMPONENT_AAL1]	= { MTK_DISP_AAL,	1, &ddp_aal },
-	[DDP_COMPONENT_BLS]	= { MTK_DISP_BLS,	0, NULL },
-	[DDP_COMPONENT_CCORR]	= { MTK_DISP_CCORR,	0, &ddp_ccorr },
-	[DDP_COMPONENT_COLOR0]	= { MTK_DISP_COLOR,	0, &ddp_color },
-	[DDP_COMPONENT_COLOR1]	= { MTK_DISP_COLOR,	1, &ddp_color },
-	[DDP_COMPONENT_DITHER]	= { MTK_DISP_DITHER,	0, &ddp_dither },
-	[DDP_COMPONENT_DPI0]	= { MTK_DPI,		0, &ddp_dpi },
-	[DDP_COMPONENT_DPI1]	= { MTK_DPI,		1, &ddp_dpi },
-	[DDP_COMPONENT_DSI0]	= { MTK_DSI,		0, &ddp_dsi },
-	[DDP_COMPONENT_DSI1]	= { MTK_DSI,		1, &ddp_dsi },
-	[DDP_COMPONENT_DSI2]	= { MTK_DSI,		2, &ddp_dsi },
-	[DDP_COMPONENT_DSI3]	= { MTK_DSI,		3, &ddp_dsi },
-	[DDP_COMPONENT_GAMMA]	= { MTK_DISP_GAMMA,	0, &ddp_gamma },
-	[DDP_COMPONENT_OD0]	= { MTK_DISP_OD,	0, &ddp_od },
-	[DDP_COMPONENT_OD1]	= { MTK_DISP_OD,	1, &ddp_od },
-	[DDP_COMPONENT_OVL0]	= { MTK_DISP_OVL,	0, &ddp_ovl },
-	[DDP_COMPONENT_OVL1]	= { MTK_DISP_OVL,	1, &ddp_ovl },
-	[DDP_COMPONENT_OVL_2L0]	= { MTK_DISP_OVL_2L,	0, &ddp_ovl },
-	[DDP_COMPONENT_OVL_2L1]	= { MTK_DISP_OVL_2L,	1, &ddp_ovl },
-	[DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,    2, &ddp_ovl },
-	[DDP_COMPONENT_PWM0]	= { MTK_DISP_PWM,	0, NULL },
-	[DDP_COMPONENT_PWM1]	= { MTK_DISP_PWM,	1, NULL },
-	[DDP_COMPONENT_PWM2]	= { MTK_DISP_PWM,	2, NULL },
-	[DDP_COMPONENT_RDMA0]	= { MTK_DISP_RDMA,	0, &ddp_rdma },
-	[DDP_COMPONENT_RDMA1]	= { MTK_DISP_RDMA,	1, &ddp_rdma },
-	[DDP_COMPONENT_RDMA2]	= { MTK_DISP_RDMA,	2, &ddp_rdma },
-	[DDP_COMPONENT_UFOE]	= { MTK_DISP_UFOE,	0, &ddp_ufoe },
-	[DDP_COMPONENT_WDMA0]	= { MTK_DISP_WDMA,	0, NULL },
-	[DDP_COMPONENT_WDMA1]	= { MTK_DISP_WDMA,	1, NULL },
+	[DDP_COMPONENT_AAL0]		= { MTK_DISP_AAL,	0, &ddp_aal },
+	[DDP_COMPONENT_AAL1]		= { MTK_DISP_AAL,	1, &ddp_aal },
+	[DDP_COMPONENT_BLS]		= { MTK_DISP_BLS,	0, NULL },
+	[DDP_COMPONENT_CCORR]		= { MTK_DISP_CCORR,	0, &ddp_ccorr },
+	[DDP_COMPONENT_COLOR0]		= { MTK_DISP_COLOR,	0, &ddp_color },
+	[DDP_COMPONENT_COLOR1]		= { MTK_DISP_COLOR,	1, &ddp_color },
+	[DDP_COMPONENT_DITHER]		= { MTK_DISP_DITHER,	0, &ddp_dither },
+	[DDP_COMPONENT_DPI0]		= { MTK_DPI,		0, &ddp_dpi },
+	[DDP_COMPONENT_DPI1]		= { MTK_DPI,		1, &ddp_dpi },
+	[DDP_COMPONENT_DSI0]		= { MTK_DSI,		0, &ddp_dsi },
+	[DDP_COMPONENT_DSI1]		= { MTK_DSI,		1, &ddp_dsi },
+	[DDP_COMPONENT_DSI2]		= { MTK_DSI,		2, &ddp_dsi },
+	[DDP_COMPONENT_DSI3]		= { MTK_DSI,		3, &ddp_dsi },
+	[DDP_COMPONENT_GAMMA]		= { MTK_DISP_GAMMA,	0, &ddp_gamma },
+	[DDP_COMPONENT_OD0]		= { MTK_DISP_OD,	0, &ddp_od },
+	[DDP_COMPONENT_OD1]		= { MTK_DISP_OD,	1, &ddp_od },
+	[DDP_COMPONENT_OVL0]		= { MTK_DISP_OVL,	0, &ddp_ovl },
+	[DDP_COMPONENT_OVL1]		= { MTK_DISP_OVL,	1, &ddp_ovl },
+	[DDP_COMPONENT_OVL_2L0]		= { MTK_DISP_OVL_2L,	0, &ddp_ovl },
+	[DDP_COMPONENT_OVL_2L1]		= { MTK_DISP_OVL_2L,	1, &ddp_ovl },
+	[DDP_COMPONENT_OVL_2L2]		= { MTK_DISP_OVL_2L,    2, &ddp_ovl },
+	[DDP_COMPONENT_POSTMASK0]	= { MTK_DISP_POSTMASK,	0, &ddp_postmask },
+	[DDP_COMPONENT_PWM0]		= { MTK_DISP_PWM,	0, NULL },
+	[DDP_COMPONENT_PWM1]		= { MTK_DISP_PWM,	1, NULL },
+	[DDP_COMPONENT_PWM2]		= { MTK_DISP_PWM,	2, NULL },
+	[DDP_COMPONENT_RDMA0]		= { MTK_DISP_RDMA,	0, &ddp_rdma },
+	[DDP_COMPONENT_RDMA1]		= { MTK_DISP_RDMA,	1, &ddp_rdma },
+	[DDP_COMPONENT_RDMA2]		= { MTK_DISP_RDMA,	2, &ddp_rdma },
+	[DDP_COMPONENT_UFOE]		= { MTK_DISP_UFOE,	0, &ddp_ufoe },
+	[DDP_COMPONENT_WDMA0]		= { MTK_DISP_WDMA,	0, NULL },
+	[DDP_COMPONENT_WDMA1]		= { MTK_DISP_WDMA,	1, NULL },
 };
 
 static bool mtk_drm_find_comp_in_ddp(struct device *dev,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index bb914d9..cd1dec6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -30,6 +30,7 @@ enum mtk_ddp_comp_type {
 	MTK_DISP_UFOE,
 	MTK_DSI,
 	MTK_DPI,
+	MTK_DISP_POSTMASK,
 	MTK_DISP_PWM,
 	MTK_DISP_MUTEX,
 	MTK_DISP_OD,
-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Mon Apr 12 15:21:46 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Mon, 12 Apr 2021 22:21:46 +0800
Subject: [PATCH v7, 5/5] drm/mediatek: add support for mediatek SOC MT8192
In-Reply-To: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618237306-17670-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1618237306-17670-6-git-send-email-yongqiang.niu@mediatek.com>

add support for mediatek SOC MT8192

Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: CK Hu <ck.hu at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c |  6 +++++
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c   | 20 +++++++++++++++
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c  |  6 +++++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c    | 42 +++++++++++++++++++++++++++++++
 4 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 141cb36..3a53ebc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -205,9 +205,15 @@ static int mtk_disp_ccorr_remove(struct platform_device *pdev)
 	.matrix_bits = 10,
 };
 
+static const struct mtk_disp_ccorr_data mt8192_ccorr_driver_data = {
+	.matrix_bits = 11,
+};
+
 static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
 	{ .compatible = "mediatek,mt8183-disp-ccorr",
 	  .data = &mt8183_ccorr_driver_data},
+	{ .compatible = "mediatek,mt8192-disp-ccorr",
+	  .data = &mt8192_ccorr_driver_data},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 961f87f..e266baa 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -455,6 +455,22 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
 	.fmt_rgb565_is_0 = true,
 };
 
+static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
+	.addr = DISP_REG_OVL_ADDR_MT8173,
+	.gmc_bits = 10,
+	.layer_nr = 4,
+	.fmt_rgb565_is_0 = true,
+	.smi_id_en = true,
+};
+
+static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
+	.addr = DISP_REG_OVL_ADDR_MT8173,
+	.gmc_bits = 10,
+	.layer_nr = 2,
+	.fmt_rgb565_is_0 = true,
+	.smi_id_en = true,
+};
+
 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
 	{ .compatible = "mediatek,mt2701-disp-ovl",
 	  .data = &mt2701_ovl_driver_data},
@@ -464,6 +480,10 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
 	  .data = &mt8183_ovl_driver_data},
 	{ .compatible = "mediatek,mt8183-disp-ovl-2l",
 	  .data = &mt8183_ovl_2l_driver_data},
+	{ .compatible = "mediatek,mt8192-disp-ovl",
+	  .data = &mt8192_ovl_driver_data},
+	{ .compatible = "mediatek,mt8192-disp-ovl-2l",
+	  .data = &mt8192_ovl_2l_driver_data},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 8c9371b..274f3ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -355,6 +355,10 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
 	.fifo_size = 5 * SZ_1K,
 };
 
+static const struct mtk_disp_rdma_data mt8192_rdma_driver_data = {
+	.fifo_size = 5 * SZ_1K,
+};
+
 static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
 	{ .compatible = "mediatek,mt2701-disp-rdma",
 	  .data = &mt2701_rdma_driver_data},
@@ -362,6 +366,8 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
 	  .data = &mt8173_rdma_driver_data},
 	{ .compatible = "mediatek,mt8183-disp-rdma",
 	  .data = &mt8183_rdma_driver_data},
+	{ .compatible = "mediatek,mt8192-disp-rdma",
+	  .data = &mt8192_rdma_driver_data},
 	{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b013d56..6df5510 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -147,6 +147,25 @@
 	DDP_COMPONENT_DPI0,
 };
 
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
+	DDP_COMPONENT_OVL0,
+	DDP_COMPONENT_OVL_2L0,
+	DDP_COMPONENT_RDMA0,
+	DDP_COMPONENT_COLOR0,
+	DDP_COMPONENT_CCORR,
+	DDP_COMPONENT_AAL0,
+	DDP_COMPONENT_GAMMA,
+	DDP_COMPONENT_POSTMASK0,
+	DDP_COMPONENT_DITHER,
+	DDP_COMPONENT_DSI0,
+};
+
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_ext[] = {
+	DDP_COMPONENT_OVL_2L2,
+	DDP_COMPONENT_RDMA4,
+	DDP_COMPONENT_DPI0,
+};
+
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
 	.main_path = mt2701_mtk_ddp_main,
 	.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -186,6 +205,13 @@
 	.ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
 };
 
+static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
+	.main_path = mt8192_mtk_ddp_main,
+	.main_len = ARRAY_SIZE(mt8192_mtk_ddp_main),
+	.ext_path = mt8192_mtk_ddp_ext,
+	.ext_len = ARRAY_SIZE(mt8192_mtk_ddp_ext),
+};
+
 static int mtk_drm_kms_init(struct drm_device *drm)
 {
 	struct mtk_drm_private *private = drm->dev_private;
@@ -404,22 +430,32 @@ static void mtk_drm_unbind(struct device *dev)
 	  .data = (void *)MTK_DISP_OVL },
 	{ .compatible = "mediatek,mt8183-disp-ovl-2l",
 	  .data = (void *)MTK_DISP_OVL_2L },
+	{ .compatible = "mediatek,mt8192-disp-ovl",
+	  .data = (void *)MTK_DISP_OVL },
+	{ .compatible = "mediatek,mt8192-disp-ovl-2l",
+	  .data = (void *)MTK_DISP_OVL_2L },
 	{ .compatible = "mediatek,mt2701-disp-rdma",
 	  .data = (void *)MTK_DISP_RDMA },
 	{ .compatible = "mediatek,mt8173-disp-rdma",
 	  .data = (void *)MTK_DISP_RDMA },
 	{ .compatible = "mediatek,mt8183-disp-rdma",
 	  .data = (void *)MTK_DISP_RDMA },
+	{ .compatible = "mediatek,mt8192-disp-rdma",
+	  .data = (void *)MTK_DISP_RDMA },
 	{ .compatible = "mediatek,mt8173-disp-wdma",
 	  .data = (void *)MTK_DISP_WDMA },
 	{ .compatible = "mediatek,mt8183-disp-ccorr",
 	  .data = (void *)MTK_DISP_CCORR },
+	{ .compatible = "mediatek,mt8192-disp-ccorr",
+	  .data = (void *)MTK_DISP_CCORR },
 	{ .compatible = "mediatek,mt2701-disp-color",
 	  .data = (void *)MTK_DISP_COLOR },
 	{ .compatible = "mediatek,mt8173-disp-color",
 	  .data = (void *)MTK_DISP_COLOR },
 	{ .compatible = "mediatek,mt8173-disp-aal",
 	  .data = (void *)MTK_DISP_AAL},
+	{ .compatible = "mediatek,mt8192-disp-aal",
+	  .data = (void *)MTK_DISP_AAL},
 	{ .compatible = "mediatek,mt8173-disp-gamma",
 	  .data = (void *)MTK_DISP_GAMMA, },
 	{ .compatible = "mediatek,mt8183-disp-gamma",
@@ -448,12 +484,16 @@ static void mtk_drm_unbind(struct device *dev)
 	  .data = (void *)MTK_DISP_MUTEX },
 	{ .compatible = "mediatek,mt8183-disp-mutex",
 	  .data = (void *)MTK_DISP_MUTEX },
+	{ .compatible = "mediatek,mt8192-disp-mutex",
+	  .data = (void *)MTK_DISP_MUTEX },
 	{ .compatible = "mediatek,mt2701-disp-pwm",
 	  .data = (void *)MTK_DISP_BLS },
 	{ .compatible = "mediatek,mt8173-disp-pwm",
 	  .data = (void *)MTK_DISP_PWM },
 	{ .compatible = "mediatek,mt8173-disp-od",
 	  .data = (void *)MTK_DISP_OD },
+	{ .compatible = "mediatek,mt8192-disp-postmask",
+	  .data = (void *)MTK_DISP_POSTMASK },
 	{ }
 };
 
@@ -468,6 +508,8 @@ static void mtk_drm_unbind(struct device *dev)
 	  .data = &mt8173_mmsys_driver_data},
 	{ .compatible = "mediatek,mt8183-mmsys",
 	  .data = &mt8183_mmsys_driver_data},
+	{ .compatible = "mediatek,mt8192-mmsys",
+	 .data = &mt8192_mmsys_driver_data},
 	{ }
 };
 
-- 
1.8.1.1.dirty

From jacopo at jmondi.org  Mon Apr 12 15:38:09 2021
From: jacopo at jmondi.org (Jacopo Mondi)
Date: Mon, 12 Apr 2021 16:38:09 +0200
Subject: [PATCH v2 30/30] media: atmel: atmel-isc: add microchip-xisc
 driver
In-Reply-To: <52f03c2b-01bd-0de3-83c5-204e6b577b9d@microchip.com>
References: <20210405155105.162529-1-eugen.hristev@microchip.com>
 <20210405155105.162529-31-eugen.hristev@microchip.com>
 <a22c2065-1a79-8a96-2b54-a2e28fa08b8a@microchip.com>
 <20210412134157.4cqva5thylmiqds7@uno.localdomain>
 <52f03c2b-01bd-0de3-83c5-204e6b577b9d@microchip.com>
Message-ID: <20210412143809.tfw37xwt64oyaue3@uno.localdomain>

Hi Eugene

On Mon, Apr 12, 2021 at 02:15:32PM +0000, Eugen.Hristev at microchip.com wrote:
> On 4/12/21 4:41 PM, Jacopo Mondi wrote:
> > Hi Eugene,
> >
> > On Mon, Apr 12, 2021 at 12:37:41PM +0000, Eugen.Hristev at microchip.com wrote:
> >>> +static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
> >>> +{
> >>> +   struct device_node *np = dev->of_node;
> >>> +   struct device_node *epn = NULL;
> >>> +   struct isc_subdev_entity *subdev_entity;
> >>> +   unsigned int flags;
> >>> +   int ret;
> >>> +   bool mipi_mode;
> >>> +
> >>> +   INIT_LIST_HEAD(&isc->subdev_entities);
> >>> +
> >>> +   mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
> >>> +
> >>> +   while (1) {
> >>> +           struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
> >>> +
> >>> +           epn = of_graph_get_next_endpoint(np, epn);
> >>> +           if (!epn)
> >>> +                   return 0;
> >>> +
> >>> +           ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
> >>> +                                            &v4l2_epn);
> >>> +           if (ret) {
> >>> +                   ret = -EINVAL;
> >>> +                   dev_err(dev, "Could not parse the endpoint\n");
> >>> +                   break;
> >>> +           }
> >>> +
> >>> +           subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
> >>> +                                        GFP_KERNEL);
> >>> +           if (!subdev_entity) {
> >>> +                   ret = -ENOMEM;
> >>> +                   break;
> >>> +           }
> >>> +           subdev_entity->epn = epn;
> >>> +
> >>> +           flags = v4l2_epn.bus.parallel.flags;
> >>> +
> >>> +           if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
> >>> +                   subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
> >>> +
> >>> +           if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
> >>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
> >>> +
> >>> +           if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
> >>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
> >>> +
> >>> +           if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
> >>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
> >>> +                                   ISC_PFE_CFG0_CCIR656;
> >>
> >> Hi Jacopo,
> >>
> >> If I use the bus-type property for the 'port' , do I actually have to
> >> change something here ?
> >
> > You can set bus_type to the desired type, if it doesn't match the
> > 'bus-type' property you will have an immediate error and a more strict
> > check on the properties.
> >
> > You would likely:
> >
> >          v4l2_epn.bus_type = V4L2_MBUS_PARALLEL;
> >          ret = v4l2_fwnode_endpoint_parse()
> >          if (!ret) {
> >                  /* It's parallel */
> >          } else {
> >                  v4l2_epn.bus_type = V4L2_MBUS_BT656;
> >                  ret = v4l2_fwnode_endpoint_parse()
> >                  if (ret) {
> >                          /* Unsupported bus type: error out. */
> >                  }
> >
> >                  /* It's BT656 */
> >          }
>
> if the v4l2_fwnode_endpoint_parse will already fill in the
> v4l2_epn.bus_type based on what is found in the 'bus-type' , why do I
> need to do this assumption-fail-assumption-fail scenario ?

Because you would know exactly what bus type you're parsing, as
v4l2_fwnode_endpoint_parse() would make sure the type you intend to
parse matches what the endpoint reports

	if (vep->bus_type != V4L2_MBUS_UNKNOWN) {
		if (mbus_type != V4L2_MBUS_UNKNOWN &&
		    vep->bus_type != mbus_type) {
			pr_debug("expecting bus type %s\n",
				 v4l2_fwnode_mbus_type_to_string(vep->bus_type));
			return -ENXIO;
		}

I guess this is mostly useful if you want to specify default
values the v4l2_fwnode_endpoint. If you go with autoguessing, a
parallel endpoint without polarities flag specified can be identified
as BT656 if I'm not mistaken.

> Can't I simply check the value of v4l2_epn.bus_type , as I am doing it
> already ?

Only if you make bus-type required in DTS, then you can specify here
bus_type = 0 like you're doing and rely on
v4l2_fwnode_endpoint_parse() to set it to what it has found in DTS.

Otherwise you rely on auto-guessing, if I got this right.

Thanks
   j

>
> >
> > Not the greatest API, but it's more robust.
> >
> >> the v4l2_epn.bus_type won't be set automatically ? by the endpoint
> >> parser I mean.
> >
> > Yes, that's what auto-discovery is, the endpoint parser tries to
> > deduce the bus type from the properties that are there specified. It
> > works, but leaves quite some ambiguity between ie PARALLEL and BT656
> > as some polarities might not be necessarily specified even for
> > PARALLEL bus types.
> >
> > As I've said, there's still plenty of code that relies on
> > auto-discovery so I don't think this is blocking, also because making
> > bus-type mandatory on existing DTS is quite painful. Since this is a
> > new DTS you can consider this solution if you want to.
> >
> > Thanks
> >     j
> >
> >>
> >> Thanks,
> >> Eugen
> >>
> >>> +
> >>> +           if (mipi_mode)
> >>> +                   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
> >>> +
> >>> +           list_add_tail(&subdev_entity->list, &isc->subdev_entities);
> >>> +   }
> >>> +   of_node_put(epn);
> >>> +
> >>> +   return ret;
> >>> +}
> >>> +
> >>> +static int microchip_xisc_probe(struct platform_device *pdev)
> >>> +{
> >>> +   struct device *dev = &pdev->dev;
> >>> +   struct isc_device *isc;
> >>> +   struct resource *res;
> >>> +   void __iomem *io_base;
> >>> +   struct isc_subdev_entity *subdev_entity;
> >>> +   int irq;
> >>> +   int ret;
> >>> +   u32 ver;
> >>> +
> >>> +   isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
> >>> +   if (!isc)
> >>> +           return -ENOMEM;
> >>> +
> >>> +   platform_set_drvdata(pdev, isc);
> >>> +   isc->dev = dev;
> >>> +
> >>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>> +   io_base = devm_ioremap_resource(dev, res);
> >>> +   if (IS_ERR(io_base))
> >>> +           return PTR_ERR(io_base);
> >>> +
> >>> +   isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
> >>> +   if (IS_ERR(isc->regmap)) {
> >>> +           ret = PTR_ERR(isc->regmap);
> >>> +           dev_err(dev, "failed to init register map: %d\n", ret);
> >>> +           return ret;
> >>> +   }
> >>> +
> >>> +   irq = platform_get_irq(pdev, 0);
> >>> +   if (irq < 0)
> >>> +           return irq;
> >>> +
> >>> +   ret = devm_request_irq(dev, irq, isc_interrupt, 0,
> >>> +                          "microchip-sama7g5-xisc", isc);
> >>> +   if (ret < 0) {
> >>> +           dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
> >>> +                   irq, ret);
> >>> +           return ret;
> >>> +   }
> >>> +
> >>> +   isc->gamma_table = isc_sama7g5_gamma_table;
> >>> +   isc->gamma_max = 0;
> >>> +
> >>> +   isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
> >>> +   isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
> >>> +
> >>> +   isc->config_dpc = isc_sama7g5_config_dpc;
> >>> +   isc->config_csc = isc_sama7g5_config_csc;
> >>> +   isc->config_cbc = isc_sama7g5_config_cbc;
> >>> +   isc->config_cc = isc_sama7g5_config_cc;
> >>> +   isc->config_gam = isc_sama7g5_config_gam;
> >>> +   isc->config_rlp = isc_sama7g5_config_rlp;
> >>> +   isc->config_ctrls = isc_sama7g5_config_ctrls;
> >>> +
> >>> +   isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
> >>> +
> >>> +   isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
> >>> +   isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
> >>> +   isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
> >>> +   isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
> >>> +   isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
> >>> +   isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
> >>> +   isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
> >>> +   isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
> >>> +   isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
> >>> +
> >>> +   isc->controller_formats = sama7g5_controller_formats;
> >>> +   isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
> >>> +   isc->formats_list = sama7g5_formats_list;
> >>> +   isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
> >>> +
> >>> +   /* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
> >>> +   isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
> >>> +
> >>> +   ret = isc_pipeline_init(isc);
> >>> +   if (ret)
> >>> +           return ret;
> >>> +
> >>> +   isc->hclock = devm_clk_get(dev, "hclock");
> >>> +   if (IS_ERR(isc->hclock)) {
> >>> +           ret = PTR_ERR(isc->hclock);
> >>> +           dev_err(dev, "failed to get hclock: %d\n", ret);
> >>> +           return ret;
> >>> +   }
> >>> +
> >>> +   ret = clk_prepare_enable(isc->hclock);
> >>> +   if (ret) {
> >>> +           dev_err(dev, "failed to enable hclock: %d\n", ret);
> >>> +           return ret;
> >>> +   }
> >>> +
> >>> +   ret = isc_clk_init(isc);
> >>> +   if (ret) {
> >>> +           dev_err(dev, "failed to init isc clock: %d\n", ret);
> >>> +           goto unprepare_hclk;
> >>> +   }
> >>> +
> >>> +   isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
> >>> +
> >>> +   ret = clk_prepare_enable(isc->ispck);
> >>> +   if (ret) {
> >>> +           dev_err(dev, "failed to enable ispck: %d\n", ret);
> >>> +           goto unprepare_hclk;
> >>> +   }
> >>> +
> >>> +   /* ispck should be greater or equal to hclock */
> >>> +   ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
> >>> +   if (ret) {
> >>> +           dev_err(dev, "failed to set ispck rate: %d\n", ret);
> >>> +           goto unprepare_clk;
> >>> +   }
> >>> +
> >>> +   ret = v4l2_device_register(dev, &isc->v4l2_dev);
> >>> +   if (ret) {
> >>> +           dev_err(dev, "unable to register v4l2 device.\n");
> >>> +           goto unprepare_clk;
> >>> +   }
> >>> +
> >>> +   ret = xisc_parse_dt(dev, isc);
> >>> +   if (ret) {
> >>> +           dev_err(dev, "fail to parse device tree\n");
> >>> +           goto unregister_v4l2_device;
> >>> +   }
> >>> +
> >>> +   if (list_empty(&isc->subdev_entities)) {
> >>> +           dev_err(dev, "no subdev found\n");
> >>> +           ret = -ENODEV;
> >>> +           goto unregister_v4l2_device;
> >>> +   }
> >>> +
> >>> +   list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
> >>> +           struct v4l2_async_subdev *asd;
> >>> +
> >>> +           v4l2_async_notifier_init(&subdev_entity->notifier);
> >>> +
> >>> +           asd = v4l2_async_notifier_add_fwnode_remote_subdev(
> >>> +                                   &subdev_entity->notifier,
> >>> +                                   of_fwnode_handle(subdev_entity->epn),
> >>> +                                   struct v4l2_async_subdev);
> >>> +
> >>> +           of_node_put(subdev_entity->epn);
> >>> +           subdev_entity->epn = NULL;
> >>> +
> >>> +           if (IS_ERR(asd)) {
> >>> +                   ret = PTR_ERR(asd);
> >>> +                   goto cleanup_subdev;
> >>> +           }
> >>> +
> >>> +           subdev_entity->notifier.ops = &isc_async_ops;
> >>> +
> >>> +           ret = v4l2_async_notifier_register(&isc->v4l2_dev,
> >>> +                                              &subdev_entity->notifier);
> >>> +           if (ret) {
> >>> +                   dev_err(dev, "fail to register async notifier\n");
> >>> +                   goto cleanup_subdev;
> >>> +           }
> >>> +
> >>> +           if (video_is_registered(&isc->video_dev))
> >>> +                   break;
> >>> +   }
> >>> +
> >>> +   pm_runtime_set_active(dev);
> >>> +   pm_runtime_enable(dev);
> >>> +   pm_request_idle(dev);
> >>> +
> >>> +   regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
> >>> +   dev_info(dev, "Microchip XISC version %x\n", ver);
> >>> +
> >>> +   return 0;
> >>> +
> >>> +cleanup_subdev:
> >>> +   isc_subdev_cleanup(isc);
> >>> +
> >>> +unregister_v4l2_device:
> >>> +   v4l2_device_unregister(&isc->v4l2_dev);
> >>> +
> >>> +unprepare_clk:
> >>> +   clk_disable_unprepare(isc->ispck);
> >>> +unprepare_hclk:
> >>> +   clk_disable_unprepare(isc->hclock);
> >>> +
> >>> +   isc_clk_cleanup(isc);
> >>> +
> >>> +   return ret;
> >>> +}
> >>> +
> >>> +static int microchip_xisc_remove(struct platform_device *pdev)
> >>> +{
> >>> +   struct isc_device *isc = platform_get_drvdata(pdev);
> >>> +
> >>> +   pm_runtime_disable(&pdev->dev);
> >>> +
> >>> +   isc_subdev_cleanup(isc);
> >>> +
> >>> +   v4l2_device_unregister(&isc->v4l2_dev);
> >>> +
> >>> +   clk_disable_unprepare(isc->ispck);
> >>> +   clk_disable_unprepare(isc->hclock);
> >>> +
> >>> +   isc_clk_cleanup(isc);
> >>> +
> >>> +   return 0;
> >>> +}
> >>> +
> >>> +static int __maybe_unused xisc_runtime_suspend(struct device *dev)
> >>> +{
> >>> +   struct isc_device *isc = dev_get_drvdata(dev);
> >>> +
> >>> +   clk_disable_unprepare(isc->ispck);
> >>> +   clk_disable_unprepare(isc->hclock);
> >>> +
> >>> +   return 0;
> >>> +}
> >>> +
> >>> +static int __maybe_unused xisc_runtime_resume(struct device *dev)
> >>> +{
> >>> +   struct isc_device *isc = dev_get_drvdata(dev);
> >>> +   int ret;
> >>> +
> >>> +   ret = clk_prepare_enable(isc->hclock);
> >>> +   if (ret)
> >>> +           return ret;
> >>> +
> >>> +   ret = clk_prepare_enable(isc->ispck);
> >>> +   if (ret)
> >>> +           clk_disable_unprepare(isc->hclock);
> >>> +
> >>> +   return ret;
> >>> +}
> >>> +
> >>> +static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
> >>> +   SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
> >>> +};
> >>> +
> >>> +static const struct of_device_id microchip_xisc_of_match[] = {
> >>> +   { .compatible = "microchip,sama7g5-isc" },
> >>> +   { }
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
> >>> +
> >>> +static struct platform_driver microchip_xisc_driver = {
> >>> +   .probe  = microchip_xisc_probe,
> >>> +   .remove = microchip_xisc_remove,
> >>> +   .driver = {
> >>> +           .name           = "microchip-sama7g5-xisc",
> >>> +           .pm             = &microchip_xisc_dev_pm_ops,
> >>> +           .of_match_table = of_match_ptr(microchip_xisc_of_match),
> >>> +   },
> >>> +};
> >>> +
> >>> +module_platform_driver(microchip_xisc_driver);
> >>> +
> >>> +MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
> >>> +MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
> >>> +MODULE_LICENSE("GPL v2");
> >>> +MODULE_SUPPORTED_DEVICE("video");
> >>>
> >>
>


From mhiramat at kernel.org  Mon Apr 12 15:46:43 2021
From: mhiramat at kernel.org (Masami Hiramatsu)
Date: Mon, 12 Apr 2021 23:46:43 +0900
Subject: [PATCH] arm64: kprobes: Restore local irqflag if kprobes is
 cancelled
In-Reply-To: <20210412221144.2da50e902df14cda0d86eeaa@kernel.org>
References: <20210412174101.6bfb0594@xhacker.debian>
 <20210412221144.2da50e902df14cda0d86eeaa@kernel.org>
Message-ID: <20210412234643.08a0a8578fb456190c50bc70@kernel.org>

On Mon, 12 Apr 2021 22:11:44 +0900
Masami Hiramatsu <mhiramat at kernel.org> wrote:

> Hi Jisheng,
> 
> On Mon, 12 Apr 2021 17:41:01 +0800
> Jisheng Zhang <Jisheng.Zhang at synaptics.com> wrote:
> 
> > If instruction being single stepped caused a page fault, the kprobes
> > is cancelled to let the page fault handler continue as a normal page
> > fault. But the local irqflags are disabled so cpu will restore pstate
> > with DAIF masked. After pagefault is serviced, the kprobes is
> > triggerred again, we overwrite the saved_irqflag by calling
> > kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
> > irqflag. After kprobes is serviced, the cpu pstate is retored with
> > DAIF masked.
> > 
> > This patch is inspired by one patch for riscv from Liao Chang.
> 
> Thanks for pointing it out. But I think kprobes_restore_local_irqflag()
> is also needed for kcb->kprobe_status == KPROBE_REENTER case...no.
> This is more complicated. In the reenter case, I think we have to retry
> the kpreprobe_fault_handler() with recovered previous kprobes so that
> it can handle page fault in its handler.

Ah, this is another issue, and needs another fix.

So this patch itself is good to me.

Acked-by: Masami Hiramatsu <mhiramat at kernel.org>

Thanks!

> 
> Hmm, RISC-V and other code also needs same fix.
> 
> Thank you,
> 
> > 
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
> > ---
> >  arch/arm64/kernel/probes/kprobes.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
> > index 66aac2881ba8..85645b2b0c7a 100644
> > --- a/arch/arm64/kernel/probes/kprobes.c
> > +++ b/arch/arm64/kernel/probes/kprobes.c
> > @@ -267,10 +267,12 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
> >  		if (!instruction_pointer(regs))
> >  			BUG();
> >  
> > -		if (kcb->kprobe_status == KPROBE_REENTER)
> > +		if (kcb->kprobe_status == KPROBE_REENTER) {
> >  			restore_previous_kprobe(kcb);
> > -		else
> > +		} else {
> > +			kprobes_restore_local_irqflag(kcb, regs);
> >  			reset_current_kprobe();
> > +		}
> >  
> >  		break;
> >  	case KPROBE_HIT_ACTIVE:
> > -- 
> > 2.31.0
> > 
> 
> 
> -- 
> Masami Hiramatsu <mhiramat at kernel.org>


-- 
Masami Hiramatsu <mhiramat at kernel.org>


From robh at kernel.org  Mon Apr 12 16:05:33 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 10:05:33 -0500
Subject: [PATCH v2 2/6] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210411131007.21757-2-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-2-jbx6244@gmail.com>
Message-ID: <20210412150533.GA3898302@robh.at.kernel.org>

On Sun, 11 Apr 2021 15:10:03 +0200, Johan Jonker wrote:
> The compatible strings below are already in use in the Rockchip
> dtsi files, but were somehow never added to a document, so add
> 
> "rockchip,rk3328-pwm"
> 
> "rockchip,rk3036-pwm", "rockchip,rk2928-pwm"
> 
> "rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
> "rockchip,rk3399-pwm", "rockchip,rk3288-pwm"
> 
> "rockchip,px30-pwm", "rockchip,rk3328-pwm"
> "rockchip,rk3308-pwm", "rockchip,rk3328-pwm"
> 
> for pwm nodes to pwm-rockchip.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.



From tsbogend at alpha.franken.de  Mon Apr 12 16:07:04 2021
From: tsbogend at alpha.franken.de (Thomas Bogendoerfer)
Date: Mon, 12 Apr 2021 17:07:04 +0200
Subject: [PATCH -next] MIPS: Alchemy: Use DEFINE_SPINLOCK() for spinlock
In-Reply-To: <20210327095225.104997-1-chenlifu@huawei.com>
References: <20210327095225.104997-1-chenlifu@huawei.com>
Message-ID: <20210412150704.GD23632@alpha.franken.de>

On Sat, Mar 27, 2021 at 05:52:25PM +0800, Chen Lifu wrote:
> From: Lifu Chen <chenlifu at huawei.com>
> 
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Lifu Chen <chenlifu at huawei.com>
> ---
>  arch/mips/alchemy/common/clock.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]


From broonie at kernel.org  Mon Apr 12 16:19:52 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 16:19:52 +0100
Subject: [PATCH v1 0/3] arm64: Boot requirements clarifications
Message-ID: <20210412151955.16078-1-broonie@kernel.org>

This series makes explicit our booting requirements in a number of
areas, mainly the initialisation of optional floating point features.
While no issues have been encountered it seems better to be explict,
particularly given that new extensions frequently require setup from
higher exception levels to be functional so our list of explicit
requirement is tending to become more and more exhaustive creating some
expecation that requirements will be stated clearly.

Due to a collision with my recent FGT series this series is based on top
of arm64/for-next/fgt-boot-init.

Mark Brown (3):
  arm64: Relax booting requirements for configuration of traps
  arm64: Explicitly require that FPSIMD instructions do not trap
  arm64: Explicitly document boot requirements for SVE

 Documentation/arm64/booting.rst | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)


base-commit: 230800cd315cd5e2093e603cf7ee150b7591ce1a
-- 
2.20.1



From broonie at kernel.org  Mon Apr 12 16:19:53 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 16:19:53 +0100
Subject: [PATCH v1 1/3] arm64: Relax booting requirements for configuration of
 traps
In-Reply-To: <20210412151955.16078-1-broonie@kernel.org>
References: <20210412151955.16078-1-broonie@kernel.org>
Message-ID: <20210412151955.16078-2-broonie@kernel.org>

Currently we require that a number of system registers be configured to
disable traps when starting the kernel. Add an explicit note that the
requirement is that the system behave as if the traps are disabled so
transparent handling of the traps is fine, this should be implicit for
people familiar with working with standards documents but it doesn't hurt
to be explicit.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 4fcc00add117..b21049ab6c69 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -279,7 +279,10 @@ Before jumping into the kernel, the following conditions must be met:
 
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
-enter the kernel in the same exception level.
+enter the kernel in the same exception level.  Where the values documented
+disable traps it is permissible for these traps to be enabled so long as
+those traps are handled transparently by higher exception levels as though
+the values documented were set.
 
 The boot loader is expected to enter the kernel on each CPU in the
 following manner:
-- 
2.20.1



From broonie at kernel.org  Mon Apr 12 16:19:54 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 16:19:54 +0100
Subject: [PATCH v1 2/3] arm64: Explicitly require that FPSIMD instructions do
 not trap
In-Reply-To: <20210412151955.16078-1-broonie@kernel.org>
References: <20210412151955.16078-1-broonie@kernel.org>
Message-ID: <20210412151955.16078-3-broonie@kernel.org>

We do not explicitly require that systems with FPSIMD support and EL3 have
disabled EL3 traps when the kernel is started, while it is unlikely that
systems will get this wrong for the sake of completeness let's spell it
out.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index b21049ab6c69..4d0e323c0a35 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -277,6 +277,16 @@ Before jumping into the kernel, the following conditions must be met:
 
     - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1.
 
+  For CPUs with Advanced SIMD and floating point support:
+
+  - If EL3 is present:
+
+    - CPTR_EL3.TFP (bit 10) must be initialised to 0b0.
+
+  - If EL2 is present and the kernel is entered at EL1:
+
+    - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
+
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.  Where the values documented
-- 
2.20.1



From broonie at kernel.org  Mon Apr 12 16:19:55 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 16:19:55 +0100
Subject: [PATCH v1 3/3] arm64: Explicitly document boot requirements for SVE
In-Reply-To: <20210412151955.16078-1-broonie@kernel.org>
References: <20210412151955.16078-1-broonie@kernel.org>
Message-ID: <20210412151955.16078-4-broonie@kernel.org>

We do not currently document the requirements for configuration of the
SVE system registers when booting the kernel, let's do so for completeness.

We don't have a hard requirement that the vector lengths configured on
different CPUs on initial boot be consistent since we have logic to
constrain to the minimum supported value but we will reject any late CPUs
which can't support the current maximum and introducing the concept of
late CPUs seemed more complex than was useful so we require that all CPUs
use the same value.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 Documentation/arm64/booting.rst | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index 4d0e323c0a35..18b8cc1bf32c 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -287,6 +287,24 @@ Before jumping into the kernel, the following conditions must be met:
 
     - CPTR_EL2.TFP (bit 10) must be initialised to 0b0.
 
+  For CPUs with the Scalable Vector Extension (FEAT_SVE) present:
+
+  - if EL3 is present:
+
+    - CPTR_EL3.EZ (bit 8) must be initialised to 0b1.
+
+    - ZCR_EL3.LEN must be initialised to the same value for all CPUs the
+      kernel is executed on.
+
+  - If the kernel is entered at EL1 and EL2 is present:
+
+    - CPTR_EL2.TZ (bit 8) must be initialised to 0b0.
+
+    - CPTR_EL2.ZEN (bits 17:16) must be initialised to 0b11.
+
+    - ZCR_EL2.LEN must be initialised to the same value for all CPUs the
+      kernel will execute on.
+
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.  Where the values documented
-- 
2.20.1



From jassisinghbrar at gmail.com  Mon Apr 12 16:29:25 2021
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Mon, 12 Apr 2021 10:29:25 -0500
Subject: [PATCH v2, 0/5] Revert "mailbox: mediatek: remove implementation
 related to atomic_exec"
In-Reply-To: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <CABb+yY1b9wD0hoBx=aYzpLcF-=EEG4QTrV68sZj8+rtf5J1aJQ@mail.gmail.com>

On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu
<yongqiang.niu at mediatek.com> wrote:
>
> This series base linux 5.12-rc2
> these patches will cause home ui flick when cursor moved,
> there is no fix solution yet, revert these patches first.
>
> change since v1:
> add mtk-gce.txt and dts modification
>
> Yongqiang Niu (5):
>   Revert "drm/mediatek: Make sure previous message done or be aborted
>     before send"
>   Revert "mailbox: mediatek: remove implementation related to
>     atomic_exec"
>   Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
>   Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells
>     value"
>   arm64: dts: mediatek: mt8183: add gce information for mmsys
>
>  .../devicetree/bindings/mailbox/mtk-gce.txt        |  2 +-
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  5 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c            |  1 -
>  drivers/mailbox/mtk-cmdq-mailbox.c                 | 80 +++++++++++++++++++---
>  4 files changed, 76 insertions(+), 12 deletions(-)
>
Please break the patchsets (this and the other 3) into mailbox only
and platform specific ones.
Also, it would help if there are some acked/reviewed by some mtk folks
especially when reverting patches.

thanks


From bpeled at marvell.com  Mon Apr 12 16:30:51 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:51 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=200/5=5D=20Asynchronous=20linkdown=20recovery?=
Message-ID: <1618241456-27200-1-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

The following patches implement the required procedure to handle and recover from asynchronous PCIE link down events on Armada SoCs.

The procedure is defined as the following:
1) Prevent new access to the PCI-E I/F by disabling the LTSSM
2) Flush all pending transaction/access to the PCI-E I/F
3) HW reset the PCIE end point device (based on board support)
4) Reset the PCIE MAC
5) Reinitialize the PCIE root complex and enable the LTSSM

The execution of this procedure is triggered by the PCIE RST_LINK_DOWN interrupt

Ben Peled (5):
  PCI: armada8k: Disable LTSSM on link down interrupts
  PCI: armada8k: Add link-down handle
  PCI: armada8k: add device reset to link-down handle
  dt-bindings: pci: add system controller and MAC reset bit to    
    Armada 7K/8K controller bindings
  arm64: dts: marvell: add pcie mac reset to pcie

 Documentation/devicetree/bindings/pci/pci-armada8k.txt |   6 +
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi          |   7 ++
 drivers/pci/controller/dwc/pcie-armada8k.c             | 126 ++++++++++++++++++++
 3 files changed, 139 insertions(+)

-- 
2.7.4



From bpeled at marvell.com  Mon Apr 12 16:30:52 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:52 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=201/5=5D=20PCI=3A=20armada8k=3A=20Disable=20LTSSM=20on=20link=20down=20interrupts?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618241456-27200-2-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

When a PCI link down condition is detected, the link training state
machine must be disabled immediately.

Signed-off-by: Marc St-Amand <mstamand at ciena.com>
Signed-off-by: Konstantin Porotchkin <kostap at marvell.com>
Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 38 ++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index 13901f3..b2278b1 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -54,6 +54,10 @@ struct armada8k_pcie {
 #define PCIE_INT_C_ASSERT_MASK		BIT(11)
 #define PCIE_INT_D_ASSERT_MASK		BIT(12)
 
+#define PCIE_GLOBAL_INT_CAUSE2_REG	(PCIE_VENDOR_REGS_OFFSET + 0x24)
+#define PCIE_GLOBAL_INT_MASK2_REG	(PCIE_VENDOR_REGS_OFFSET + 0x28)
+#define PCIE_INT2_PHY_RST_LINK_DOWN	BIT(1)
+
 #define PCIE_ARCACHE_TRC_REG		(PCIE_VENDOR_REGS_OFFSET + 0x50)
 #define PCIE_AWCACHE_TRC_REG		(PCIE_VENDOR_REGS_OFFSET + 0x54)
 #define PCIE_ARUSER_REG			(PCIE_VENDOR_REGS_OFFSET + 0x5C)
@@ -193,6 +197,11 @@ static void armada8k_pcie_establish_link(struct armada8k_pcie *pcie)
 	       PCIE_INT_C_ASSERT_MASK | PCIE_INT_D_ASSERT_MASK;
 	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK1_REG, reg);
 
+	/* Also enable link down interrupts */
+	reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG);
+	reg |= PCIE_INT2_PHY_RST_LINK_DOWN;
+	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG, reg);
+
 	if (!dw_pcie_link_up(pci)) {
 		/* Configuration done. Start LTSSM */
 		reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_CONTROL_REG);
@@ -230,6 +239,35 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 	val = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_CAUSE1_REG);
 	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_CAUSE1_REG, val);
 
+	val = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_CAUSE2_REG);
+
+	if (PCIE_INT2_PHY_RST_LINK_DOWN & val) {
+		u32 ctrl_reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_CONTROL_REG);
+		/*
+		 * The link went down. Disable LTSSM immediately. This
+		 * unlocks the root complex config registers. Downstream
+		 * device accesses will return all-Fs
+		 */
+		ctrl_reg &= ~(PCIE_APP_LTSSM_EN);
+		dw_pcie_writel_dbi(pci, PCIE_GLOBAL_CONTROL_REG, ctrl_reg);
+		/*
+		 * Mask link down interrupts. They can be re-enabled once
+		 * the link is retrained.
+		 */
+		ctrl_reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG);
+		ctrl_reg &= ~PCIE_INT2_PHY_RST_LINK_DOWN;
+		dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG, ctrl_reg);
+		/*
+		 * At this point a worker thread can be triggered to
+		 * initiate a link retrain. If link retrains were
+		 * possible, that is.
+		 */
+		dev_dbg(pci->dev, "%s: link went down\n", __func__);
+	}
+
+	/* Now clear the second interrupt cause. */
+	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_CAUSE2_REG, val);
+
 	return IRQ_HANDLED;
 }
 
-- 
2.7.4



From bpeled at marvell.com  Mon Apr 12 16:30:53 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:53 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=202/5=5D=20PCI=3A=20armada8k=3A=20Add=20link-down=20handle?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618241456-27200-3-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

In PCIE ISR routine caused by RST_LINK_DOWN
we schedule work to handle the link-down procedure.
Link-down procedure will:
1. Remove PCIe bus
2. Reset the MAC
3. Reconfigure link back up
4. Rescan PCIe bus

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 68 ++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index b2278b1..4eb8607 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -22,6 +22,8 @@
 #include <linux/resource.h>
 #include <linux/of_pci.h>
 #include <linux/of_irq.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #include "pcie-designware.h"
 
@@ -33,6 +35,9 @@ struct armada8k_pcie {
 	struct clk *clk_reg;
 	struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
 	unsigned int phy_count;
+	struct regmap *sysctrl_base;
+	u32 mac_rest_bitmask;
+	struct work_struct recover_link_work;
 };
 
 #define PCIE_VENDOR_REGS_OFFSET		0x8000
@@ -73,6 +78,8 @@ struct armada8k_pcie {
 #define AX_USER_DOMAIN_MASK		0x3
 #define AX_USER_DOMAIN_SHIFT		4
 
+#define UNIT_SOFT_RESET_CONFIG_REG	0x268
+
 #define to_armada8k_pcie(x)	dev_get_drvdata((x)->dev)
 
 static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie)
@@ -224,6 +231,49 @@ static int armada8k_pcie_host_init(struct pcie_port *pp)
 
 	return 0;
 }
+static void armada8k_pcie_recover_link(struct work_struct *ws)
+{
+	struct armada8k_pcie *pcie = container_of(ws, struct armada8k_pcie, recover_link_work);
+	struct pcie_port *pp = &pcie->pci->pp;
+	struct pci_bus *bus = pp->bridge->bus;
+	struct pci_dev *root_port;
+	int ret;
+
+	root_port = pci_get_slot(bus, 0);
+	if (!root_port) {
+		dev_err(pcie->pci->dev, "failed to get root port\n");
+		return;
+	}
+	pci_lock_rescan_remove();
+	pci_stop_and_remove_bus_device(root_port);
+	/*
+	 * Sleep needed to make sure all pcie transactions and access
+	 * are flushed before resetting the mac
+	 */
+	msleep(100);
+
+	/* Reset mac */
+	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
+				pcie->mac_rest_bitmask, 0, NULL, false, true);
+	udelay(1);
+	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
+				pcie->mac_rest_bitmask, pcie->mac_rest_bitmask,
+				NULL, false, true);
+	udelay(1);
+	ret = armada8k_pcie_host_init(pp);
+	if (ret) {
+		dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
+		pci_unlock_rescan_remove();
+		pci_dev_put(root_port);
+		return;
+	}
+
+	bus = NULL;
+	while ((bus = pci_find_next_bus(bus)) != NULL)
+		pci_rescan_bus(bus);
+	pci_unlock_rescan_remove();
+	pci_dev_put(root_port);
+}
 
 static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 {
@@ -262,6 +312,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 		 * initiate a link retrain. If link retrains were
 		 * possible, that is.
 		 */
+		if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
+			schedule_work(&pcie->recover_link_work);
+
 		dev_dbg(pci->dev, "%s: link went down\n", __func__);
 	}
 
@@ -330,6 +383,8 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 
 	pcie->pci = pci;
 
+	INIT_WORK(&pcie->recover_link_work, armada8k_pcie_recover_link);
+
 	pcie->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(pcie->clk))
 		return PTR_ERR(pcie->clk);
@@ -357,6 +412,19 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 		goto fail_clkreg;
 	}
 
+	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+						       "marvell,system-controller");
+	if (IS_ERR(pcie->sysctrl_base)) {
+		dev_warn(dev, "failed to find marvell,system-controller\n");
+		pcie->sysctrl_base = 0x0;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "marvell,mac-reset-bit-mask",
+				   &pcie->mac_rest_bitmask);
+	if (ret < 0) {
+		dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
+		pcie->mac_rest_bitmask = 0x0;
+	}
 	ret = armada8k_pcie_setup_phys(pcie);
 	if (ret)
 		goto fail_clkreg;
-- 
2.7.4



From bpeled at marvell.com  Mon Apr 12 16:30:54 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:54 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=203/5=5D=20dt-bindings=3A=20pci=3A=20add=20system=20controller=20and=20MAC=20reset=20bit=20to=20Armada=207K/8K=20controller=20bindings?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618241456-27200-4-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Adding optional system-controller and mac-reset-bit-mask
needed for linkdown procedure.

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 Documentation/devicetree/bindings/pci/pci-armada8k.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
index 7a813d0..2696e79 100644
--- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
+++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
@@ -24,6 +24,10 @@ Optional properties:
 - phy-names: names of the PHYs corresponding to the number of lanes.
 	Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
 	2 PHYs.
+- marvell,system-controller: address of system controller needed
+	in order to reset MAC used by link-down handle
+- marvell,mac-reset-bit-mask: MAC reset bit of system controller
+	needed in order to reset MAC used by link-down handle
 
 Example:
 
@@ -45,4 +49,6 @@ Example:
 		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
 		num-lanes = <1>;
 		clocks = <&cpm_syscon0 1 13>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(1)>;
 	};
-- 
2.7.4



From bpeled at marvell.com  Mon Apr 12 16:30:55 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:55 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=204/5=5D=20arm64=3A=20dts=3A=20marvell=3A=20add=20pcie=20mac=20reset=20to=20pcie?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618241456-27200-5-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Add system controller and reset bit to each pcie to enable pcie mac reset

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
index 9dcf16b..eb60e73 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
@@ -11,6 +11,7 @@
 #include "armada-common.dtsi"
 
 #define CP11X_PCIEx_CONF_BASE(iface)	(CP11X_PCIEx_MEM_BASE(iface) + CP11X_PCIEx_MEM_SIZE(iface))
+#define CP11X_PCIEx_MAC_RESET_BIT_MASK(n)	(0x1 << 11 + ((n + 2) % 3))
 
 / {
 	/*
@@ -513,6 +514,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 13>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(0)>;
 		status = "disabled";
 	};
 
@@ -538,6 +541,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 11>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(1)>;
 		status = "disabled";
 	};
 
@@ -563,6 +568,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 12>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(2)>;
 		status = "disabled";
 	};
 };
-- 
2.7.4



From bpeled at marvell.com  Mon Apr 12 16:30:56 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Mon, 12 Apr 2021 18:30:56 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=205/5=5D=20PCI=3A=20armada8k=3A=20add=20device=20reset=20to=20link-down=20handle?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618241456-27200-6-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Added pcie reset via gpio support as described in the
designware-pcie.txt DT binding document.
In cases link down cause still exist in device.
The device need to be reset to reestablish the link.
If reset-gpio pin provided in the device tree, then the linkdown
handle resets the device before reestablishing link.

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index 4eb8607..83ac91e 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -24,6 +24,7 @@
 #include <linux/of_irq.h>
 #include <linux/mfd/syscon.h>
 #include <linux/regmap.h>
+#include <linux/of_gpio.h>
 
 #include "pcie-designware.h"
 
@@ -38,6 +39,7 @@ struct armada8k_pcie {
 	struct regmap *sysctrl_base;
 	u32 mac_rest_bitmask;
 	struct work_struct recover_link_work;
+	enum of_gpio_flags flags;
 };
 
 #define PCIE_VENDOR_REGS_OFFSET		0x8000
-- 
2.7.4



From chunkuang.hu at kernel.org  Mon Apr 12 16:32:06 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Mon, 12 Apr 2021 23:32:06 +0800
Subject: [PATCH -next] drm/mediatek: Fix PM reference leak in
 mtk_crtc_ddp_hw_init()
In-Reply-To: <20210410034841.16567-1-wangli74@huawei.com>
References: <20210410034841.16567-1-wangli74@huawei.com>
Message-ID: <CAAOTY_-qNeoZT1CorqhBrQe888tG21TF=LnPkUgymv=rQ8-YAA@mail.gmail.com>

Hi, Wang:

Wang Li <wangli74 at huawei.com> ? 2021?4?10? ?? ??11:31???
>
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.

Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>

>
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Wang Li <wangli74 at huawei.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 54ab3a324752..f1954242d8f6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -259,7 +259,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
>                 drm_connector_list_iter_end(&conn_iter);
>         }
>
> -       ret = pm_runtime_get_sync(crtc->dev->dev);
> +       ret = pm_runtime_resume_and_get(crtc->dev->dev);
>         if (ret < 0) {
>                 DRM_ERROR("Failed to enable power domain: %d\n", ret);
>                 return ret;
> --
> 2.17.1
>


From valentin.schneider at arm.com  Mon Apr 12 16:32:57 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Mon, 12 Apr 2021 16:32:57 +0100
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
Message-ID: <87tuobmsba.mognet@arm.com>

On 12/04/21 20:20, Ruifeng Zhang wrote:
> There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> The MPIDR has been written to the chip register in armv8.3 format.
> For example,
> core0: 0000000080000000
> core1: 0000000080000100
> core2: 0000000080000200
> ...
>
> Its cpu topology can be parsed normally on aarch64 mode (both
> userspace and kernel work on arm64).
>
> The problem is when it working on aarch32 mode (both userspace and
> kernel work on arm 32-bit),

I didn't know using aarch32 elsewhere than EL0 was something actually being
used. Do you deploy this somewhere, or do you use it for testing purposes?

> the cpu topology
> will parse error because of the format is different between armv7 and armv8.3.
> The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> and store to the topology with armv7,
> and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
>

I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
I couldn't find anything about MPIDR format differences:

  DDI 0487G.a G8.2.113
  """
  AArch32 System register MPIDR bits [31:0] are architecturally mapped to
  AArch64 System register MPIDR_EL1[31:0].
  """

Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
just the same, i.e. for both of them, with your example of:

  core0: 0000000080000000
  core1: 0000000080000100
  core2: 0000000080000200
  ...

we'll get:

  |       | aff2 | aff1 | aff0 |
  |-------+------+------+------|
  | Core0 |    0 |    0 |    0 |
  | Core1 |    0 |    1 |    0 |
  | Core2 |    0 |    2 |    0 |
      ...

Now, arm64 doesn't fallback to MPIDR for topology information anymore since

  3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")

so without DT we would get:
  |       | package_id | core_id |
  |-------+------------+---------|
  | Core0 |          0 |       0 |
  | Core1 |          0 |       1 |
  | Core2 |          0 |       2 |

Whereas with an arm kernel we'll end up parsing MPIDR as:
  |       | package_id | core_id |
  |-------+------------+---------|
  | Core0 |          0 |       0 |
  | Core1 |          1 |       0 |
  | Core2 |          2 |       0 |

Did I get this right? Is this what you're observing?

> In addition, I think arm should also allow customers to configure cpu
> topologies via DT.


From boon.leong.ong at intel.com  Mon Apr 12 16:41:24 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:24 +0800
Subject: [PATCH net-next 1/7] net: stmmac: rearrange RX buffer allocation and
 free functions
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-2-boon.leong.ong@intel.com>

This patch restructures the per RX queue buffer allocation from page_pool
to stmmac_alloc_rx_buffers().

We also rearrange dma_free_rx_skbufs() so that it can be used in
init_dma_rx_desc_rings() during freeing of RX buffer in the event of
page_pool allocation failure to replace the more efficient method earlier.
The replacement is needed to make the RX buffer alloc and free method
scalable to XDP ZC xsk_pool alloc and free later.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 84 +++++++++++--------
 1 file changed, 47 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 77285646c5fc..f6d3d26ce45a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1475,6 +1475,43 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 	tx_q->tx_skbuff_dma[i].map_as_page = false;
 }
 
+/**
+ * dma_free_rx_skbufs - free RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+{
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++)
+		stmmac_free_rx_buffer(priv, queue, i);
+}
+
+static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
+				   gfp_t flags)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct dma_desc *p;
+		int ret;
+
+		if (priv->extend_desc)
+			p = &((rx_q->dma_erx + i)->basic);
+		else
+			p = rx_q->dma_rx + i;
+
+		ret = stmmac_init_rx_buffers(priv, p, i, flags,
+					     queue);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1547,15 +1584,14 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	return;
 
 err_reinit_rx_buffers:
-	do {
-		while (--i >= 0)
-			stmmac_free_rx_buffer(priv, queue, i);
+	while (queue >= 0) {
+		dma_free_rx_skbufs(priv, queue);
 
 		if (queue == 0)
 			break;
 
-		i = priv->dma_rx_size;
-	} while (queue-- > 0);
+		queue--;
+	}
 }
 
 /**
@@ -1572,7 +1608,6 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	int ret = -ENOMEM;
 	int queue;
-	int i;
 
 	/* RX INITIALIZATION */
 	netif_dbg(priv, probe, priv->dev,
@@ -1580,7 +1615,7 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-		int ret;
+
 
 		netif_dbg(priv, probe, priv->dev,
 			  "(%s) dma_rx_phy=0x%08x\n", __func__,
@@ -1596,22 +1631,12 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
 			    rx_q->queue_index);
 
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct dma_desc *p;
-
-			if (priv->extend_desc)
-				p = &((rx_q->dma_erx + i)->basic);
-			else
-				p = rx_q->dma_rx + i;
-
-			ret = stmmac_init_rx_buffers(priv, p, i, flags,
-						     queue);
-			if (ret)
-				goto err_init_rx_buffers;
-		}
+		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+		if (ret < 0)
+			goto err_init_rx_buffers;
 
 		rx_q->cur_rx = 0;
-		rx_q->dirty_rx = (unsigned int)(i - priv->dma_rx_size);
+		rx_q->dirty_rx = 0;
 
 		/* Setup the chained descriptor addresses */
 		if (priv->mode == STMMAC_CHAIN_MODE) {
@@ -1630,13 +1655,11 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 err_init_rx_buffers:
 	while (queue >= 0) {
-		while (--i >= 0)
-			stmmac_free_rx_buffer(priv, queue, i);
+		dma_free_rx_skbufs(priv, queue);
 
 		if (queue == 0)
 			break;
 
-		i = priv->dma_rx_size;
 		queue--;
 	}
 
@@ -1731,19 +1754,6 @@ static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
 	return ret;
 }
 
-/**
- * dma_free_rx_skbufs - free RX dma buffers
- * @priv: private structure
- * @queue: RX queue index
- */
-static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
-{
-	int i;
-
-	for (i = 0; i < priv->dma_rx_size; i++)
-		stmmac_free_rx_buffer(priv, queue, i);
-}
-
 /**
  * dma_free_tx_skbufs - free TX dma buffers
  * @priv: private structure
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:23 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:23 +0800
Subject: [PATCH net-next 0/7] stmmac: add XDP ZC support
Message-ID: <20210412154130.20742-1-boon.leong.ong@intel.com>

Hi,

This is the v1 patch series to add XDP ZC support to stmmac driver and
the changes are as listed in below summary:-

1-4/7: Refactor RX & TX buffer allocation and initialization to prepare
       stmmac driver for XSK RX & TX pool enabling and disabling.

5/7: Refactor stmmac_xdp_run_prog() for XDP ZC use which does not need
     to check for XDP program loaded.

6-7/7: XDP ZC RX and TX enabling.

The above patch series have been tested using xdpsock app in samples/bpf
directory on Intel mGbE controller. The DUT receives burst traffic
packets generated by using pktgen_sample03_burst_single_flow.sh in
samples/pktgen.

########################################################################

==========
A) RX-Only
==========

root at intel-corei7-64:~ $ ./xdpsock  -i eth0 -r -S

 sock0 at eth0:0 rxdrop xdp-skb
                   pps            pkts           1.00
rx                 112161         12229475
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-skb
                   pps            pkts           1.00
rx                 112280         12341779
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-skb
                   pps            pkts           1.00
rx                 112358         12454155
tx                 0              0

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock  -i eth0 -r -N -c

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 681082         2616133
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 681205         3297415
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 681386         3978873
tx                 0              0

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock  -i eth0 -r -z

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 703915         19579779
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 703766         20283768
tx                 0              0

 sock0 at eth0:0 rxdrop xdp-drv
                   pps            pkts           1.00
rx                 703383         20987229
tx                 0              0

==========
B) TX-Only
==========

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -t -S

 sock0 at eth0:0 txonly xdp-skb
                   pps            pkts           1.00
rx                 0              0
tx                 140269         4326720

 sock0 at eth0:0 txonly xdp-skb
                   pps            pkts           1.00
rx                 0              0
tx                 140514         4467264

 sock0 at eth0:0 txonly xdp-skb
                   pps            pkts           1.00
rx                 0              0
tx                 140009         4607296

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -t -N -c

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 138222         3108160

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 139629         3247872

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 139821         3387712

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -t -z

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 447382         13390848

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 447384         13838272

 sock0 at eth0:0 txonly xdp-drv
                   pps            pkts           1.00
rx                 0              0
tx                 447384         14285696

================
C) L2 Forwarding
================

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -l -S

 sock0 at eth0:0 l2fwd xdp-skb
                   pps            pkts           1.00
rx                 85021          7363434
tx                 85021          7363434

 sock0 at eth0:0 l2fwd xdp-skb
                   pps            pkts           1.00
rx                 85003          7448446
tx                 85003          7448446

 sock0 at eth0:0 l2fwd xdp-skb
                   pps            pkts           1.00
rx                 84946          7533403
tx                 84946          7533403

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -l -N -c

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 132136         1092673
tx                 132072         1092609

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 132428         1225118
tx                 132428         1225054

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 132623         1357757
tx                 132623         1357693

 ====================================================

root at intel-corei7-64:~ $ ./xdpsock -i eth0 -l -z

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 468476         43619530
tx                 468476         43619466

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 468633         44088218
tx                 468633         44088154

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 468439         44556775
tx                 468439         44556711

 ########################################################################

Based on the results obtained from above using xdpsock test cases, the
result looks promising. It will be great if community can help to review
and test the above patch series on your respective platform and provide
me feedback for any improvement.

Thank you very much,
Boon Leong

Ong Boon Leong (7):
  net: stmmac: rearrange RX buffer allocation and free functions
  net: stmmac: introduce dma_recycle_rx_skbufs for
    stmmac_reinit_rx_buffers
  net: stmmac: refactor stmmac_init_rx_buffers for
    stmmac_reinit_rx_buffers
  net: stmmac: rearrange RX and TX desc init into per-queue basis
  net: stmmac: Refactor __stmmac_xdp_run_prog for XDP ZC
  net: stmmac: Enable RX via AF_XDP zero-copy
  net: stmmac: Add TX via XDP zero-copy socket

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   24 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 1698 +++++++++++++----
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |   94 +
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |    3 +
 4 files changed, 1396 insertions(+), 423 deletions(-)

-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:25 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:25 +0800
Subject: [PATCH net-next 2/7] net: stmmac: introduce dma_recycle_rx_skbufs for
 stmmac_reinit_rx_buffers
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-3-boon.leong.ong@intel.com>

Rearrange RX buffer page_pool recycling logics into dma_recycle_rx_skbufs,
so that we prepare stmmac_reinit_rx_buffers() for XSK pool expansion.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 44 ++++++++++++-------
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f6d3d26ce45a..a6c3414fd231 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1512,6 +1512,31 @@ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
 	return 0;
 }
 
+/**
+ * dma_recycle_rx_skbufs - recycle RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+		if (buf->page) {
+			page_pool_recycle_direct(rx_q->page_pool, buf->page);
+			buf->page = NULL;
+		}
+
+		if (priv->sph && buf->sec_page) {
+			page_pool_recycle_direct(rx_q->page_pool, buf->sec_page);
+			buf->sec_page = NULL;
+		}
+	}
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1524,23 +1549,8 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	u32 queue;
 	int i;
 
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
-
-			if (buf->page) {
-				page_pool_recycle_direct(rx_q->page_pool, buf->page);
-				buf->page = NULL;
-			}
-
-			if (priv->sph && buf->sec_page) {
-				page_pool_recycle_direct(rx_q->page_pool, buf->sec_page);
-				buf->sec_page = NULL;
-			}
-		}
-	}
+	for (queue = 0; queue < rx_count; queue++)
+		dma_recycle_rx_skbufs(priv, queue);
 
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:26 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:26 +0800
Subject: [PATCH net-next 3/7] net: stmmac: refactor stmmac_init_rx_buffers for
 stmmac_reinit_rx_buffers
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-4-boon.leong.ong@intel.com>

The per-queue RX buffer allocation in stmmac_reinit_rx_buffers() can be
made to use stmmac_alloc_rx_buffers() by merging the page_pool alloc
checks for "buf->page" and "buf->sec_page" in stmmac_init_rx_buffers().

This is in preparation for XSK pool allocation later.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 378 +++++++++---------
 1 file changed, 189 insertions(+), 189 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a6c3414fd231..7e889ef0c7b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1388,12 +1388,14 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv, struct dma_desc *p,
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 	struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
 
-	buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
-	if (!buf->page)
-		return -ENOMEM;
-	buf->page_offset = stmmac_rx_offset(priv);
+	if (!buf->page) {
+		buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
+		if (!buf->page)
+			return -ENOMEM;
+		buf->page_offset = stmmac_rx_offset(priv);
+	}
 
-	if (priv->sph) {
+	if (priv->sph && !buf->sec_page) {
 		buf->sec_page = page_pool_dev_alloc_pages(rx_q->page_pool);
 		if (!buf->sec_page)
 			return -ENOMEM;
@@ -1547,48 +1549,16 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 {
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	u32 queue;
-	int i;
 
 	for (queue = 0; queue < rx_count; queue++)
 		dma_recycle_rx_skbufs(priv, queue);
 
 	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
-			struct dma_desc *p;
-
-			if (priv->extend_desc)
-				p = &((rx_q->dma_erx + i)->basic);
-			else
-				p = rx_q->dma_rx + i;
-
-			if (!buf->page) {
-				buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
-				if (!buf->page)
-					goto err_reinit_rx_buffers;
-
-				buf->addr = page_pool_get_dma_addr(buf->page) +
-					    buf->page_offset;
-			}
-
-			if (priv->sph && !buf->sec_page) {
-				buf->sec_page = page_pool_dev_alloc_pages(rx_q->page_pool);
-				if (!buf->sec_page)
-					goto err_reinit_rx_buffers;
-
-				buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
-			}
+		int ret;
 
-			stmmac_set_desc_addr(priv, p, buf->addr);
-			if (priv->sph)
-				stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, true);
-			else
-				stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, false);
-			if (priv->dma_buf_sz == BUF_SIZE_16KiB)
-				stmmac_init_desc3(priv, p);
-		}
+		ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
+		if (ret < 0)
+			goto err_reinit_rx_buffers;
 	}
 
 	return;
@@ -1791,153 +1761,173 @@ static void stmmac_free_tx_skbufs(struct stmmac_priv *priv)
 }
 
 /**
- * free_dma_rx_desc_resources - free RX dma desc resources
+ * __free_dma_rx_desc_resources - free RX dma desc resources (per queue)
  * @priv: private structure
+ * @queue: RX queue index
  */
-static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
+static void __free_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	u32 queue;
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
-	/* Free RX queue resources */
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	/* Release the DMA RX socket buffers */
+	dma_free_rx_skbufs(priv, queue);
 
-		/* Release the DMA RX socket buffers */
-		dma_free_rx_skbufs(priv, queue);
+	/* Free DMA regions of consistent memory previously allocated */
+	if (!priv->extend_desc)
+		dma_free_coherent(priv->device, priv->dma_rx_size *
+				  sizeof(struct dma_desc),
+				  rx_q->dma_rx, rx_q->dma_rx_phy);
+	else
+		dma_free_coherent(priv->device, priv->dma_rx_size *
+				  sizeof(struct dma_extended_desc),
+				  rx_q->dma_erx, rx_q->dma_rx_phy);
 
-		/* Free DMA regions of consistent memory previously allocated */
-		if (!priv->extend_desc)
-			dma_free_coherent(priv->device, priv->dma_rx_size *
-					  sizeof(struct dma_desc),
-					  rx_q->dma_rx, rx_q->dma_rx_phy);
-		else
-			dma_free_coherent(priv->device, priv->dma_rx_size *
-					  sizeof(struct dma_extended_desc),
-					  rx_q->dma_erx, rx_q->dma_rx_phy);
+	if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
+		xdp_rxq_info_unreg(&rx_q->xdp_rxq);
 
-		if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
-			xdp_rxq_info_unreg(&rx_q->xdp_rxq);
+	kfree(rx_q->buf_pool);
+	if (rx_q->page_pool)
+		page_pool_destroy(rx_q->page_pool);
+}
 
-		kfree(rx_q->buf_pool);
-		if (rx_q->page_pool)
-			page_pool_destroy(rx_q->page_pool);
-	}
+static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+
+	/* Free RX queue resources */
+	for (queue = 0; queue < rx_count; queue++)
+		__free_dma_rx_desc_resources(priv, queue);
 }
 
 /**
- * free_dma_tx_desc_resources - free TX dma desc resources
+ * __free_dma_tx_desc_resources - free TX dma desc resources (per queue)
  * @priv: private structure
+ * @queue: TX queue index
  */
-static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
+static void __free_dma_tx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 tx_count = priv->plat->tx_queues_to_use;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	size_t size;
+	void *addr;
 
-	/* Free TX queue resources */
-	for (queue = 0; queue < tx_count; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-		size_t size;
-		void *addr;
+	/* Release the DMA TX socket buffers */
+	dma_free_tx_skbufs(priv, queue);
+
+	if (priv->extend_desc) {
+		size = sizeof(struct dma_extended_desc);
+		addr = tx_q->dma_etx;
+	} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
+		size = sizeof(struct dma_edesc);
+		addr = tx_q->dma_entx;
+	} else {
+		size = sizeof(struct dma_desc);
+		addr = tx_q->dma_tx;
+	}
 
-		/* Release the DMA TX socket buffers */
-		dma_free_tx_skbufs(priv, queue);
+	size *= priv->dma_tx_size;
 
-		if (priv->extend_desc) {
-			size = sizeof(struct dma_extended_desc);
-			addr = tx_q->dma_etx;
-		} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
-			size = sizeof(struct dma_edesc);
-			addr = tx_q->dma_entx;
-		} else {
-			size = sizeof(struct dma_desc);
-			addr = tx_q->dma_tx;
-		}
+	dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
 
-		size *= priv->dma_tx_size;
+	kfree(tx_q->tx_skbuff_dma);
+	kfree(tx_q->tx_skbuff);
+}
 
-		dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
+static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 tx_count = priv->plat->tx_queues_to_use;
+	u32 queue;
 
-		kfree(tx_q->tx_skbuff_dma);
-		kfree(tx_q->tx_skbuff);
-	}
+	/* Free TX queue resources */
+	for (queue = 0; queue < tx_count; queue++)
+		__free_dma_tx_desc_resources(priv, queue);
 }
 
 /**
- * alloc_dma_rx_desc_resources - alloc RX resources.
+ * __alloc_dma_rx_desc_resources - alloc RX resources (per queue).
  * @priv: private structure
+ * @queue: RX queue index
  * Description: according to which descriptor can be used (extend or basic)
  * this function allocates the resources for TX and RX paths. In case of
  * reception, for example, it pre-allocated the RX socket buffer in order to
  * allow zero-copy mechanism.
  */
-static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
+static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
 	bool xdp_prog = stmmac_xdp_is_enabled(priv);
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	int ret = -ENOMEM;
-	u32 queue;
+	struct page_pool_params pp_params = { 0 };
+	unsigned int num_pages;
+	int ret;
 
-	/* RX queues buffers and DMA */
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-		struct stmmac_channel *ch = &priv->channel[queue];
-		struct page_pool_params pp_params = { 0 };
-		unsigned int num_pages;
-		int ret;
+	rx_q->queue_index = queue;
+	rx_q->priv_data = priv;
+
+	pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV;
+	pp_params.pool_size = priv->dma_rx_size;
+	num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+	pp_params.order = ilog2(num_pages);
+	pp_params.nid = dev_to_node(priv->device);
+	pp_params.dev = priv->device;
+	pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
+	pp_params.offset = stmmac_rx_offset(priv);
+	pp_params.max_len = STMMAC_MAX_RX_BUF_SIZE(num_pages);
+
+	rx_q->page_pool = page_pool_create(&pp_params);
+	if (IS_ERR(rx_q->page_pool)) {
+		ret = PTR_ERR(rx_q->page_pool);
+		rx_q->page_pool = NULL;
+		return ret;
+	}
 
-		rx_q->queue_index = queue;
-		rx_q->priv_data = priv;
-
-		pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV;
-		pp_params.pool_size = priv->dma_rx_size;
-		num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
-		pp_params.order = ilog2(num_pages);
-		pp_params.nid = dev_to_node(priv->device);
-		pp_params.dev = priv->device;
-		pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
-		pp_params.offset = stmmac_rx_offset(priv);
-		pp_params.max_len = STMMAC_MAX_RX_BUF_SIZE(num_pages);
-
-		rx_q->page_pool = page_pool_create(&pp_params);
-		if (IS_ERR(rx_q->page_pool)) {
-			ret = PTR_ERR(rx_q->page_pool);
-			rx_q->page_pool = NULL;
-			goto err_dma;
-		}
+	rx_q->buf_pool = kcalloc(priv->dma_rx_size,
+				 sizeof(*rx_q->buf_pool),
+				 GFP_KERNEL);
+	if (!rx_q->buf_pool)
+		return -ENOMEM;
 
-		rx_q->buf_pool = kcalloc(priv->dma_rx_size,
-					 sizeof(*rx_q->buf_pool),
-					 GFP_KERNEL);
-		if (!rx_q->buf_pool)
-			goto err_dma;
+	if (priv->extend_desc) {
+		rx_q->dma_erx = dma_alloc_coherent(priv->device,
+						   priv->dma_rx_size *
+						   sizeof(struct dma_extended_desc),
+						   &rx_q->dma_rx_phy,
+						   GFP_KERNEL);
+		if (!rx_q->dma_erx)
+			return -ENOMEM;
 
-		if (priv->extend_desc) {
-			rx_q->dma_erx = dma_alloc_coherent(priv->device,
-							   priv->dma_rx_size *
-							   sizeof(struct dma_extended_desc),
-							   &rx_q->dma_rx_phy,
-							   GFP_KERNEL);
-			if (!rx_q->dma_erx)
-				goto err_dma;
+	} else {
+		rx_q->dma_rx = dma_alloc_coherent(priv->device,
+						  priv->dma_rx_size *
+						  sizeof(struct dma_desc),
+						  &rx_q->dma_rx_phy,
+						  GFP_KERNEL);
+		if (!rx_q->dma_rx)
+			return -ENOMEM;
+	}
 
-		} else {
-			rx_q->dma_rx = dma_alloc_coherent(priv->device,
-							  priv->dma_rx_size *
-							  sizeof(struct dma_desc),
-							  &rx_q->dma_rx_phy,
-							  GFP_KERNEL);
-			if (!rx_q->dma_rx)
-				goto err_dma;
-		}
+	ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
+			       rx_q->queue_index,
+			       ch->rx_napi.napi_id);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to register xdp rxq info\n");
+		return -EINVAL;
+	}
 
-		ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
-				       rx_q->queue_index,
-				       ch->rx_napi.napi_id);
-		if (ret) {
-			netdev_err(priv->dev, "Failed to register xdp rxq info\n");
+	return 0;
+}
+
+static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+	int ret;
+
+	/* RX queues buffers and DMA */
+	for (queue = 0; queue < rx_count; queue++) {
+		ret = __alloc_dma_rx_desc_resources(priv, queue);
+		if (ret)
 			goto err_dma;
-		}
 	}
 
 	return 0;
@@ -1949,60 +1939,70 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 }
 
 /**
- * alloc_dma_tx_desc_resources - alloc TX resources.
+ * __alloc_dma_tx_desc_resources - alloc TX resources (per queue).
  * @priv: private structure
+ * @queue: TX queue index
  * Description: according to which descriptor can be used (extend or basic)
  * this function allocates the resources for TX and RX paths. In case of
  * reception, for example, it pre-allocated the RX socket buffer in order to
  * allow zero-copy mechanism.
  */
-static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
+static int __alloc_dma_tx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 tx_count = priv->plat->tx_queues_to_use;
-	int ret = -ENOMEM;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	size_t size;
+	void *addr;
 
-	/* TX queues buffers and DMA */
-	for (queue = 0; queue < tx_count; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-		size_t size;
-		void *addr;
+	tx_q->queue_index = queue;
+	tx_q->priv_data = priv;
 
-		tx_q->queue_index = queue;
-		tx_q->priv_data = priv;
+	tx_q->tx_skbuff_dma = kcalloc(priv->dma_tx_size,
+				      sizeof(*tx_q->tx_skbuff_dma),
+				      GFP_KERNEL);
+	if (!tx_q->tx_skbuff_dma)
+		return -ENOMEM;
 
-		tx_q->tx_skbuff_dma = kcalloc(priv->dma_tx_size,
-					      sizeof(*tx_q->tx_skbuff_dma),
-					      GFP_KERNEL);
-		if (!tx_q->tx_skbuff_dma)
-			goto err_dma;
+	tx_q->tx_skbuff = kcalloc(priv->dma_tx_size,
+				  sizeof(struct sk_buff *),
+				  GFP_KERNEL);
+	if (!tx_q->tx_skbuff)
+		return -ENOMEM;
 
-		tx_q->tx_skbuff = kcalloc(priv->dma_tx_size,
-					  sizeof(struct sk_buff *),
-					  GFP_KERNEL);
-		if (!tx_q->tx_skbuff)
-			goto err_dma;
+	if (priv->extend_desc)
+		size = sizeof(struct dma_extended_desc);
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		size = sizeof(struct dma_edesc);
+	else
+		size = sizeof(struct dma_desc);
 
-		if (priv->extend_desc)
-			size = sizeof(struct dma_extended_desc);
-		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-			size = sizeof(struct dma_edesc);
-		else
-			size = sizeof(struct dma_desc);
+	size *= priv->dma_tx_size;
 
-		size *= priv->dma_tx_size;
+	addr = dma_alloc_coherent(priv->device, size,
+				  &tx_q->dma_tx_phy, GFP_KERNEL);
+	if (!addr)
+		return -ENOMEM;
 
-		addr = dma_alloc_coherent(priv->device, size,
-					  &tx_q->dma_tx_phy, GFP_KERNEL);
-		if (!addr)
-			goto err_dma;
+	if (priv->extend_desc)
+		tx_q->dma_etx = addr;
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		tx_q->dma_entx = addr;
+	else
+		tx_q->dma_tx = addr;
 
-		if (priv->extend_desc)
-			tx_q->dma_etx = addr;
-		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-			tx_q->dma_entx = addr;
-		else
-			tx_q->dma_tx = addr;
+	return 0;
+}
+
+static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 tx_count = priv->plat->tx_queues_to_use;
+	u32 queue;
+	int ret;
+
+	/* TX queues buffers and DMA */
+	for (queue = 0; queue < tx_count; queue++) {
+		ret = __alloc_dma_tx_desc_resources(priv, queue);
+		if (ret)
+			goto err_dma;
 	}
 
 	return 0;
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:27 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:27 +0800
Subject: [PATCH net-next 4/7] net: stmmac: rearrange RX and TX desc init into
 per-queue basis
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-5-boon.leong.ong@intel.com>

Below functions are made to be per-queue in preparation of XDP ZC:

 __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t flags)
 __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)

The original functions below are stay maintained for all queue usage:

 init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 init_dma_tx_desc_rings(struct net_device *dev)

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 180 ++++++++++--------
 1 file changed, 100 insertions(+), 80 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7e889ef0c7b5..0804674e628e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1575,60 +1575,70 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 }
 
 /**
- * init_dma_rx_desc_rings - init the RX descriptor rings
- * @dev: net device structure
+ * __init_dma_rx_desc_rings - init the RX descriptor ring (per queue)
+ * @priv: driver private structure
+ * @queue: RX queue index
  * @flags: gfp flag.
  * Description: this function initializes the DMA RX descriptors
  * and allocates the socket buffers. It supports the chained and ring
  * modes.
  */
-static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
+static int __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t flags)
 {
-	struct stmmac_priv *priv = netdev_priv(dev);
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	int ret = -ENOMEM;
-	int queue;
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int ret;
 
-	/* RX INITIALIZATION */
 	netif_dbg(priv, probe, priv->dev,
-		  "SKB addresses:\nskb\t\tskb data\tdma data\n");
+		  "(%s) dma_rx_phy=0x%08x\n", __func__,
+		  (u32)rx_q->dma_rx_phy);
 
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	stmmac_clear_rx_descriptors(priv, queue);
 
+	WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+					   MEM_TYPE_PAGE_POOL,
+					   rx_q->page_pool));
 
-		netif_dbg(priv, probe, priv->dev,
-			  "(%s) dma_rx_phy=0x%08x\n", __func__,
-			  (u32)rx_q->dma_rx_phy);
+	netdev_info(priv->dev,
+		    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
+		    rx_q->queue_index);
 
-		stmmac_clear_rx_descriptors(priv, queue);
+	ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+	if (ret < 0)
+		return -ENOMEM;
 
-		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
-						   MEM_TYPE_PAGE_POOL,
-						   rx_q->page_pool));
+	rx_q->cur_rx = 0;
+	rx_q->dirty_rx = 0;
 
-		netdev_info(priv->dev,
-			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
-			    rx_q->queue_index);
+	/* Setup the chained descriptor addresses */
+	if (priv->mode == STMMAC_CHAIN_MODE) {
+		if (priv->extend_desc)
+			stmmac_mode_init(priv, rx_q->dma_erx,
+					 rx_q->dma_rx_phy,
+					 priv->dma_rx_size, 1);
+		else
+			stmmac_mode_init(priv, rx_q->dma_rx,
+					 rx_q->dma_rx_phy,
+					 priv->dma_rx_size, 0);
+	}
 
-		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
-		if (ret < 0)
-			goto err_init_rx_buffers;
+	return 0;
+}
 
-		rx_q->cur_rx = 0;
-		rx_q->dirty_rx = 0;
+static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+	int ret;
 
-		/* Setup the chained descriptor addresses */
-		if (priv->mode == STMMAC_CHAIN_MODE) {
-			if (priv->extend_desc)
-				stmmac_mode_init(priv, rx_q->dma_erx,
-						 rx_q->dma_rx_phy,
-						 priv->dma_rx_size, 1);
-			else
-				stmmac_mode_init(priv, rx_q->dma_rx,
-						 rx_q->dma_rx_phy,
-						 priv->dma_rx_size, 0);
-		}
+	/* RX INITIALIZATION */
+	netif_dbg(priv, probe, priv->dev,
+		  "SKB addresses:\nskb\t\tskb data\tdma data\n");
+
+	for (queue = 0; queue < rx_count; queue++) {
+		ret = __init_dma_rx_desc_rings(priv, queue, flags);
+		if (ret)
+			goto err_init_rx_buffers;
 	}
 
 	return 0;
@@ -1647,63 +1657,73 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 }
 
 /**
- * init_dma_tx_desc_rings - init the TX descriptor rings
- * @dev: net device structure.
+ * __init_dma_tx_desc_rings - init the TX descriptor ring (per queue)
+ * @priv: driver private structure
+ * @queue : TX queue index
  * Description: this function initializes the DMA TX descriptors
  * and allocates the socket buffers. It supports the chained and ring
  * modes.
  */
-static int init_dma_tx_desc_rings(struct net_device *dev)
+static int __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)
 {
-	struct stmmac_priv *priv = netdev_priv(dev);
-	u32 tx_queue_cnt = priv->plat->tx_queues_to_use;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	int i;
 
-	for (queue = 0; queue < tx_queue_cnt; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-
-		netif_dbg(priv, probe, priv->dev,
-			  "(%s) dma_tx_phy=0x%08x\n", __func__,
-			 (u32)tx_q->dma_tx_phy);
-
-		/* Setup the chained descriptor addresses */
-		if (priv->mode == STMMAC_CHAIN_MODE) {
-			if (priv->extend_desc)
-				stmmac_mode_init(priv, tx_q->dma_etx,
-						 tx_q->dma_tx_phy,
-						 priv->dma_tx_size, 1);
-			else if (!(tx_q->tbs & STMMAC_TBS_AVAIL))
-				stmmac_mode_init(priv, tx_q->dma_tx,
-						 tx_q->dma_tx_phy,
-						 priv->dma_tx_size, 0);
-		}
+	netif_dbg(priv, probe, priv->dev,
+		  "(%s) dma_tx_phy=0x%08x\n", __func__,
+		  (u32)tx_q->dma_tx_phy);
 
-		for (i = 0; i < priv->dma_tx_size; i++) {
-			struct dma_desc *p;
-			if (priv->extend_desc)
-				p = &((tx_q->dma_etx + i)->basic);
-			else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-				p = &((tx_q->dma_entx + i)->basic);
-			else
-				p = tx_q->dma_tx + i;
+	/* Setup the chained descriptor addresses */
+	if (priv->mode == STMMAC_CHAIN_MODE) {
+		if (priv->extend_desc)
+			stmmac_mode_init(priv, tx_q->dma_etx,
+					 tx_q->dma_tx_phy,
+					 priv->dma_tx_size, 1);
+		else if (!(tx_q->tbs & STMMAC_TBS_AVAIL))
+			stmmac_mode_init(priv, tx_q->dma_tx,
+					 tx_q->dma_tx_phy,
+					 priv->dma_tx_size, 0);
+	}
 
-			stmmac_clear_desc(priv, p);
+	for (i = 0; i < priv->dma_tx_size; i++) {
+		struct dma_desc *p;
 
-			tx_q->tx_skbuff_dma[i].buf = 0;
-			tx_q->tx_skbuff_dma[i].map_as_page = false;
-			tx_q->tx_skbuff_dma[i].len = 0;
-			tx_q->tx_skbuff_dma[i].last_segment = false;
-			tx_q->tx_skbuff[i] = NULL;
-		}
+		if (priv->extend_desc)
+			p = &((tx_q->dma_etx + i)->basic);
+		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+			p = &((tx_q->dma_entx + i)->basic);
+		else
+			p = tx_q->dma_tx + i;
 
-		tx_q->dirty_tx = 0;
-		tx_q->cur_tx = 0;
-		tx_q->mss = 0;
+		stmmac_clear_desc(priv, p);
 
-		netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+		tx_q->tx_skbuff_dma[i].buf = 0;
+		tx_q->tx_skbuff_dma[i].map_as_page = false;
+		tx_q->tx_skbuff_dma[i].len = 0;
+		tx_q->tx_skbuff_dma[i].last_segment = false;
+		tx_q->tx_skbuff[i] = NULL;
 	}
 
+	tx_q->dirty_tx = 0;
+	tx_q->cur_tx = 0;
+	tx_q->mss = 0;
+
+	netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+
+	return 0;
+}
+
+static int init_dma_tx_desc_rings(struct net_device *dev)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	u32 tx_queue_cnt;
+	u32 queue;
+
+	tx_queue_cnt = priv->plat->tx_queues_to_use;
+
+	for (queue = 0; queue < tx_queue_cnt; queue++)
+		__init_dma_tx_desc_rings(priv, queue);
+
 	return 0;
 }
 
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:28 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:28 +0800
Subject: [PATCH net-next 5/7] net: stmmac: Refactor __stmmac_xdp_run_prog for
 XDP ZC
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-6-boon.leong.ong@intel.com>

Prepare stmmac_xdp_run_prog() for AF_XDP zero-copy support which will be
added by upcoming patches by splitting out the XDP verdict processing
into __stmmac_xdp_run_prog() and it callable for XDP ZC path which does
not need to verify bpf_prog is not NULL.

The stmmac_xdp_run_prog() is used for regular XDP Rx path which requires
bpf_prog to be verified.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++-------
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0804674e628e..329a3abbac76 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4408,20 +4408,13 @@ static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
 	return res;
 }
 
-static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
-					   struct xdp_buff *xdp)
+/* This function assumes rcu_read_lock() is held by the caller. */
+static int __stmmac_xdp_run_prog(struct stmmac_priv *priv,
+				 struct bpf_prog *prog,
+				 struct xdp_buff *xdp)
 {
-	struct bpf_prog *prog;
-	int res;
 	u32 act;
-
-	rcu_read_lock();
-
-	prog = READ_ONCE(priv->xdp_prog);
-	if (!prog) {
-		res = STMMAC_XDP_PASS;
-		goto unlock;
-	}
+	int res;
 
 	act = bpf_prog_run_xdp(prog, xdp);
 	switch (act) {
@@ -4448,6 +4441,24 @@ static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 		break;
 	}
 
+	return res;
+}
+
+static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
+					   struct xdp_buff *xdp)
+{
+	struct bpf_prog *prog;
+	int res;
+
+	rcu_read_lock();
+
+	prog = READ_ONCE(priv->xdp_prog);
+	if (!prog) {
+		res = STMMAC_XDP_PASS;
+		goto unlock;
+	}
+
+	res = __stmmac_xdp_run_prog(priv, prog, xdp);
 unlock:
 	rcu_read_unlock();
 	return ERR_PTR(-res);
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:29 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:29 +0800
Subject: [PATCH net-next 6/7] net: stmmac: Enable RX via AF_XDP zero-copy
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-7-boon.leong.ong@intel.com>

This patch adds the support for receiving packet via AF_XDP zero-copy
mechanism.

XDP ZC uses 1:1 mapping of XDP buffer to receive packet, therefore the
use of split header is not used currently. The 'xdp_buff' is declared as
union together with a struct that contains 'page', 'addr' and
'page_offset' that are associated with primary buffer.

RX buffers are now allocated either via page_pool or xsk pool. For RX
buffers from xsk_pool they are allocated and deallocated using below
functions:

 * stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
 * dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)

With above functions now available, we then extend the following driver
functions to support XDP ZC:
 * stmmac_reinit_rx_buffers()
 * __init_dma_rx_desc_rings()
 * init_dma_rx_desc_rings()
 * __free_dma_rx_desc_resources()

Note: stmmac_alloc_rx_buffers_zc() may return -ENOMEM due to RX XDP
buffer pool is not allocated (e.g. samples/bpf/xdpsock TX-only). But,
it is still ok to let TX XDP ZC to continue, therefore, the -ENOMEM
is silently ignored to let the driver succcessfully transition to XDP
ZC mode for the said RX and TX queue.

As XDP ZC buffer size is different, the DMA buffer size is required
to be reprogrammed accordingly for RX DMA/Queue that is populated with
XDP buffer from XSK pool.

Next, to add or remove per-queue XSK pool, stmmac_xdp_setup_pool()
will call stmmac_xdp_enable_pool() or stmmac_xdp_disable_pool()
that in-turn coordinates the tearing down and setting up RX ring via
RX buffers and descriptors removal and reallocation through
stmmac_disable_rx_queue() and stmmac_enable_rx_queue(). In addition,
stmmac_xsk_wakeup() is added to initiate XDP RX buffer replenishing
by signalling user application to add available XDP frames back to
FILL queue.

For RX processing using XDP zero-copy buffer, stmmac_rx_zc() is
introduced which is implemented with the assumption that RX split
header is disabled. For XDP verdict is XDP_PASS, the XDP buffer is
copied into a sk_buff allocated through stmmac_construct_skb_zc()
and sent to Linux network GRO inside stmmac_dispatch_skb_zc(). Free RX
buffers are then replenished using stmmac_rx_refill_zc()

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  18 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 580 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  86 +++
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |   3 +
 4 files changed, 664 insertions(+), 23 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..aa0db622ee69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -77,9 +77,14 @@ struct stmmac_tx_queue {
 };
 
 struct stmmac_rx_buffer {
-	struct page *page;
-	dma_addr_t addr;
-	__u32 page_offset;
+	union {
+		struct {
+			struct page *page;
+			dma_addr_t addr;
+			__u32 page_offset;
+		};
+		struct xdp_buff *xdp;
+	};
 	struct page *sec_page;
 	dma_addr_t sec_addr;
 };
@@ -88,6 +93,7 @@ struct stmmac_rx_queue {
 	u32 rx_count_frames;
 	u32 queue_index;
 	struct xdp_rxq_info xdp_rxq;
+	struct xsk_buff_pool *xsk_pool;
 	struct page_pool *page_pool;
 	struct stmmac_rx_buffer *buf_pool;
 	struct stmmac_priv *priv_data;
@@ -95,6 +101,7 @@ struct stmmac_rx_queue {
 	struct dma_desc *dma_rx ____cacheline_aligned_in_smp;
 	unsigned int cur_rx;
 	unsigned int dirty_rx;
+	unsigned int buf_alloc_num;
 	u32 rx_zeroc_thresh;
 	dma_addr_t dma_rx_phy;
 	u32 rx_tail_addr;
@@ -283,6 +290,7 @@ struct stmmac_priv {
 	struct stmmac_rss rss;
 
 	/* XDP BPF Program */
+	unsigned long *af_xdp_zc_qps;
 	struct bpf_prog *xdp_prog;
 };
 
@@ -328,6 +336,10 @@ static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
 	return 0;
 }
 
+void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue);
+int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags);
+
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
 void stmmac_selftest_run(struct net_device *dev,
 			 struct ethtool_test *etest, u64 *buf);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 329a3abbac76..dace043de13c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -40,6 +40,7 @@
 #include <linux/udp.h>
 #include <linux/bpf_trace.h>
 #include <net/pkt_cls.h>
+#include <net/xdp_sock_drv.h>
 #include "stmmac_ptp.h"
 #include "stmmac.h"
 #include "stmmac_xdp.h"
@@ -69,6 +70,8 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_TX_THRESH(x)	((x)->dma_tx_size / 4)
 #define STMMAC_RX_THRESH(x)	((x)->dma_rx_size / 4)
 
+#define STMMAC_RX_FILL_BATCH		16
+
 #define STMMAC_XDP_PASS		0
 #define STMMAC_XDP_CONSUMED	BIT(0)
 #define STMMAC_XDP_TX		BIT(1)
@@ -188,8 +191,18 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
 	u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
 	u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
 	u32 maxq = max(rx_queues_cnt, tx_queues_cnt);
+	struct stmmac_rx_queue *rx_q;
 	u32 queue;
 
+	/* synchronize_rcu() needed for pending XDP buffers to drain */
+	for (queue = 0; queue < rx_queues_cnt; queue++) {
+		rx_q = &priv->rx_queue[queue];
+		if (rx_q->xsk_pool) {
+			synchronize_rcu();
+			break;
+		}
+	}
+
 	for (queue = 0; queue < maxq; queue++) {
 		struct stmmac_channel *ch = &priv->channel[queue];
 
@@ -1509,6 +1522,8 @@ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
 					     queue);
 		if (ret)
 			return ret;
+
+		rx_q->buf_alloc_num++;
 	}
 
 	return 0;
@@ -1539,6 +1554,56 @@ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
 	}
 }
 
+/**
+ * dma_free_rx_xskbufs - free RX dma buffers from XSK pool
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+		if (!buf->xdp)
+			continue;
+
+		xsk_buff_free(buf->xdp);
+		buf->xdp = NULL;
+	}
+}
+
+static int stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf;
+		dma_addr_t dma_addr;
+		struct dma_desc *p;
+
+		if (priv->extend_desc)
+			p = (struct dma_desc *)(rx_q->dma_erx + i);
+		else
+			p = rx_q->dma_rx + i;
+
+		buf = &rx_q->buf_pool[i];
+
+		buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+		if (!buf->xdp)
+			return -ENOMEM;
+
+		dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+		stmmac_set_desc_addr(priv, p, dma_addr);
+		rx_q->buf_alloc_num++;
+	}
+
+	return 0;
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1550,15 +1615,31 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	u32 queue;
 
-	for (queue = 0; queue < rx_count; queue++)
-		dma_recycle_rx_skbufs(priv, queue);
+	for (queue = 0; queue < rx_count; queue++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+		if (rx_q->xsk_pool)
+			dma_free_rx_xskbufs(priv, queue);
+		else
+			dma_recycle_rx_skbufs(priv, queue);
+
+		rx_q->buf_alloc_num = 0;
+	}
 
 	for (queue = 0; queue < rx_count; queue++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 		int ret;
 
-		ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
-		if (ret < 0)
-			goto err_reinit_rx_buffers;
+		if (rx_q->xsk_pool) {
+			/* RX XDP ZC buffer pool may not be populated, e.g.
+			 * xdpsock TX-only.
+			 */
+			stmmac_alloc_rx_buffers_zc(priv, queue);
+		} else {
+			ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
+			if (ret < 0)
+				goto err_reinit_rx_buffers;
+		}
 	}
 
 	return;
@@ -1574,6 +1655,14 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	}
 }
 
+static struct xsk_buff_pool *stmmac_get_xsk_pool(struct stmmac_priv *priv, u32 queue)
+{
+	if (!stmmac_xdp_is_enabled(priv) || !test_bit(queue, priv->af_xdp_zc_qps))
+		return NULL;
+
+	return xsk_get_pool_from_qid(priv->dev, queue);
+}
+
 /**
  * __init_dma_rx_desc_rings - init the RX descriptor ring (per queue)
  * @priv: driver private structure
@@ -1594,17 +1683,37 @@ static int __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t f
 
 	stmmac_clear_rx_descriptors(priv, queue);
 
-	WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
-					   MEM_TYPE_PAGE_POOL,
-					   rx_q->page_pool));
+	xdp_rxq_info_unreg_mem_model(&rx_q->xdp_rxq);
 
-	netdev_info(priv->dev,
-		    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
-		    rx_q->queue_index);
+	rx_q->xsk_pool = stmmac_get_xsk_pool(priv, queue);
 
-	ret = stmmac_alloc_rx_buffers(priv, queue, flags);
-	if (ret < 0)
-		return -ENOMEM;
+	if (rx_q->xsk_pool) {
+		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+						   MEM_TYPE_XSK_BUFF_POOL,
+						   NULL));
+		netdev_info(priv->dev,
+			    "Register MEM_TYPE_XSK_BUFF_POOL RxQ-%d\n",
+			    rx_q->queue_index);
+		xsk_pool_set_rxq_info(rx_q->xsk_pool, &rx_q->xdp_rxq);
+	} else {
+		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+						   MEM_TYPE_PAGE_POOL,
+						   rx_q->page_pool));
+		netdev_info(priv->dev,
+			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
+			    rx_q->queue_index);
+	}
+
+	if (rx_q->xsk_pool) {
+		/* RX XDP ZC buffer pool may not be populated, e.g.
+		 * xdpsock TX-only.
+		 */
+		stmmac_alloc_rx_buffers_zc(priv, queue);
+	} else {
+		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+		if (ret < 0)
+			return -ENOMEM;
+	}
 
 	rx_q->cur_rx = 0;
 	rx_q->dirty_rx = 0;
@@ -1645,7 +1754,15 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 err_init_rx_buffers:
 	while (queue >= 0) {
-		dma_free_rx_skbufs(priv, queue);
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+		if (rx_q->xsk_pool)
+			dma_free_rx_xskbufs(priv, queue);
+		else
+			dma_free_rx_skbufs(priv, queue);
+
+		rx_q->buf_alloc_num = 0;
+		rx_q->xsk_pool = NULL;
 
 		if (queue == 0)
 			break;
@@ -1790,7 +1907,13 @@ static void __free_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
 	/* Release the DMA RX socket buffers */
-	dma_free_rx_skbufs(priv, queue);
+	if (rx_q->xsk_pool)
+		dma_free_rx_xskbufs(priv, queue);
+	else
+		dma_free_rx_skbufs(priv, queue);
+
+	rx_q->buf_alloc_num = 0;
+	rx_q->xsk_pool = NULL;
 
 	/* Free DMA regions of consistent memory previously allocated */
 	if (!priv->extend_desc)
@@ -2222,12 +2345,24 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 
 	/* configure all channels */
 	for (chan = 0; chan < rx_channels_count; chan++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
+		u32 buf_size;
+
 		qmode = priv->plat->rx_queues_cfg[chan].mode_to_use;
 
 		stmmac_dma_rx_mode(priv, priv->ioaddr, rxmode, chan,
 				rxfifosz, qmode);
-		stmmac_set_dma_bfsize(priv, priv->ioaddr, priv->dma_buf_sz,
-				chan);
+
+		if (rx_q->xsk_pool) {
+			buf_size = xsk_pool_get_rx_frame_size(rx_q->xsk_pool);
+			stmmac_set_dma_bfsize(priv, priv->ioaddr,
+					      buf_size,
+					      chan);
+		} else {
+			stmmac_set_dma_bfsize(priv, priv->ioaddr,
+					      priv->dma_buf_sz,
+					      chan);
+		}
 	}
 
 	for (chan = 0; chan < tx_channels_count; chan++) {
@@ -2638,7 +2773,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 				    rx_q->dma_rx_phy, chan);
 
 		rx_q->rx_tail_addr = rx_q->dma_rx_phy +
-				     (priv->dma_rx_size *
+				     (rx_q->buf_alloc_num *
 				      sizeof(struct dma_desc));
 		stmmac_set_rx_tail_ptr(priv, priv->ioaddr,
 				       rx_q->rx_tail_addr, chan);
@@ -4479,6 +4614,302 @@ static void stmmac_finalize_xdp_rx(struct stmmac_priv *priv,
 		xdp_do_flush();
 }
 
+static struct sk_buff *stmmac_construct_skb_zc(struct stmmac_channel *ch,
+					       struct xdp_buff *xdp)
+{
+	unsigned int metasize = xdp->data - xdp->data_meta;
+	unsigned int datasize = xdp->data_end - xdp->data;
+	struct sk_buff *skb;
+
+	skb = __napi_alloc_skb(&ch->rx_napi,
+			       xdp->data_end - xdp->data_hard_start,
+			       GFP_ATOMIC | __GFP_NOWARN);
+	if (unlikely(!skb))
+		return NULL;
+
+	skb_reserve(skb, xdp->data - xdp->data_hard_start);
+	memcpy(__skb_put(skb, datasize), xdp->data, datasize);
+	if (metasize)
+		skb_metadata_set(skb, metasize);
+
+	return skb;
+}
+
+static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue,
+				   struct dma_desc *p, struct dma_desc *np,
+				   struct xdp_buff *xdp)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned int len = xdp->data_end - xdp->data;
+	enum pkt_hash_types hash_type;
+	int coe = priv->hw->rx_csum;
+	struct sk_buff *skb;
+	u32 hash;
+
+	skb = stmmac_construct_skb_zc(ch, xdp);
+	if (!skb) {
+		priv->dev->stats.rx_dropped++;
+		return;
+	}
+
+	stmmac_get_rx_hwtstamp(priv, p, np, skb);
+	stmmac_rx_vlan(priv->dev, skb);
+	skb->protocol = eth_type_trans(skb, priv->dev);
+
+	if (unlikely(!coe))
+		skb_checksum_none_assert(skb);
+	else
+		skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	if (!stmmac_get_rx_hash(priv, p, &hash, &hash_type))
+		skb_set_hash(skb, hash, hash_type);
+
+	skb_record_rx_queue(skb, queue);
+	napi_gro_receive(&ch->rx_napi, skb);
+
+	priv->dev->stats.rx_packets++;
+	priv->dev->stats.rx_bytes += len;
+}
+
+static bool stmmac_rx_refill_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	unsigned int entry = rx_q->dirty_rx;
+	struct dma_desc *rx_desc = NULL;
+	bool ret = true;
+
+	budget = min(budget, stmmac_rx_dirty(priv, queue));
+
+	while (budget-- > 0 && entry != rx_q->cur_rx) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[entry];
+		dma_addr_t dma_addr;
+		bool use_rx_wd;
+
+		if (!buf->xdp) {
+			buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+			if (!buf->xdp) {
+				ret = false;
+				break;
+			}
+		}
+
+		if (priv->extend_desc)
+			rx_desc = (struct dma_desc *)(rx_q->dma_erx + entry);
+		else
+			rx_desc = rx_q->dma_rx + entry;
+
+		dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+		stmmac_set_desc_addr(priv, rx_desc, dma_addr);
+		stmmac_set_desc_sec_addr(priv, rx_desc, 0, false);
+		stmmac_refill_desc3(priv, rx_q, rx_desc);
+
+		rx_q->rx_count_frames++;
+		rx_q->rx_count_frames += priv->rx_coal_frames[queue];
+		if (rx_q->rx_count_frames > priv->rx_coal_frames[queue])
+			rx_q->rx_count_frames = 0;
+
+		use_rx_wd = !priv->rx_coal_frames[queue];
+		use_rx_wd |= rx_q->rx_count_frames > 0;
+		if (!priv->use_riwt)
+			use_rx_wd = false;
+
+		dma_wmb();
+		stmmac_set_rx_owner(priv, rx_desc, use_rx_wd);
+
+		entry = STMMAC_GET_ENTRY(entry, priv->dma_rx_size);
+	}
+
+	if (rx_desc) {
+		rx_q->dirty_rx = entry;
+		rx_q->rx_tail_addr = rx_q->dma_rx_phy +
+				     (rx_q->dirty_rx * sizeof(struct dma_desc));
+		stmmac_set_rx_tail_ptr(priv, priv->ioaddr, rx_q->rx_tail_addr, queue);
+	}
+
+	return ret;
+}
+
+static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	unsigned int count = 0, error = 0, len = 0;
+	int dirty = stmmac_rx_dirty(priv, queue);
+	unsigned int next_entry = rx_q->cur_rx;
+	unsigned int desc_size;
+	struct bpf_prog *prog;
+	bool failure = false;
+	int xdp_status = 0;
+	int status = 0;
+
+	if (netif_msg_rx_status(priv)) {
+		void *rx_head;
+
+		netdev_dbg(priv->dev, "%s: descriptor ring:\n", __func__);
+		if (priv->extend_desc) {
+			rx_head = (void *)rx_q->dma_erx;
+			desc_size = sizeof(struct dma_extended_desc);
+		} else {
+			rx_head = (void *)rx_q->dma_rx;
+			desc_size = sizeof(struct dma_desc);
+		}
+
+		stmmac_display_ring(priv, rx_head, priv->dma_rx_size, true,
+				    rx_q->dma_rx_phy, desc_size);
+	}
+	while (count < limit) {
+		struct stmmac_rx_buffer *buf;
+		unsigned int buf1_len = 0;
+		struct dma_desc *np, *p;
+		int entry;
+		int res;
+
+		if (!count && rx_q->state_saved) {
+			error = rx_q->state.error;
+			len = rx_q->state.len;
+		} else {
+			rx_q->state_saved = false;
+			error = 0;
+			len = 0;
+		}
+
+		if (count >= limit)
+			break;
+
+read_again:
+		buf1_len = 0;
+		entry = next_entry;
+		buf = &rx_q->buf_pool[entry];
+
+		if (dirty >= STMMAC_RX_FILL_BATCH) {
+			failure = failure ||
+				  !stmmac_rx_refill_zc(priv, queue, dirty);
+			dirty = 0;
+		}
+
+		if (priv->extend_desc)
+			p = (struct dma_desc *)(rx_q->dma_erx + entry);
+		else
+			p = rx_q->dma_rx + entry;
+
+		/* read the status of the incoming frame */
+		status = stmmac_rx_status(priv, &priv->dev->stats,
+					  &priv->xstats, p);
+		/* check if managed by the DMA otherwise go ahead */
+		if (unlikely(status & dma_own))
+			break;
+
+		/* Prefetch the next RX descriptor */
+		rx_q->cur_rx = STMMAC_GET_ENTRY(rx_q->cur_rx,
+						priv->dma_rx_size);
+		next_entry = rx_q->cur_rx;
+
+		if (priv->extend_desc)
+			np = (struct dma_desc *)(rx_q->dma_erx + next_entry);
+		else
+			np = rx_q->dma_rx + next_entry;
+
+		prefetch(np);
+
+		if (priv->extend_desc)
+			stmmac_rx_extended_status(priv, &priv->dev->stats,
+						  &priv->xstats,
+						  rx_q->dma_erx + entry);
+		if (unlikely(status == discard_frame)) {
+			xsk_buff_free(buf->xdp);
+			buf->xdp = NULL;
+			dirty++;
+			error = 1;
+			if (!priv->hwts_rx_en)
+				priv->dev->stats.rx_errors++;
+		}
+
+		if (unlikely(error && (status & rx_not_ls)))
+			goto read_again;
+		if (unlikely(error)) {
+			count++;
+			continue;
+		}
+
+		/* Ensure a valid XSK buffer before proceed */
+		if (!buf->xdp)
+			break;
+
+		/* XSK pool expects RX frame 1:1 mapped to XSK buffer */
+		if (likely(status & rx_not_ls)) {
+			xsk_buff_free(buf->xdp);
+			buf->xdp = NULL;
+			dirty++;
+			count++;
+			goto read_again;
+		}
+
+		/* XDP ZC Frame only support primary buffers for now */
+		buf1_len = stmmac_rx_buf1_len(priv, p, status, len);
+		len += buf1_len;
+
+		/* ACS is set; GMAC core strips PAD/FCS for IEEE 802.3
+		 * Type frames (LLC/LLC-SNAP)
+		 *
+		 * llc_snap is never checked in GMAC >= 4, so this ACS
+		 * feature is always disabled and packets need to be
+		 * stripped manually.
+		 */
+		if (likely(!(status & rx_not_ls)) &&
+		    (likely(priv->synopsys_id >= DWMAC_CORE_4_00) ||
+		     unlikely(status != llc_snap))) {
+			buf1_len -= ETH_FCS_LEN;
+			len -= ETH_FCS_LEN;
+		}
+
+		/* RX buffer is good and fit into a XSK pool buffer */
+		buf->xdp->data_end = buf->xdp->data + buf1_len;
+		xsk_buff_dma_sync_for_cpu(buf->xdp, rx_q->xsk_pool);
+
+		rcu_read_lock();
+		prog = READ_ONCE(priv->xdp_prog);
+		res = __stmmac_xdp_run_prog(priv, prog, buf->xdp);
+		rcu_read_unlock();
+
+		switch (res) {
+		case STMMAC_XDP_PASS:
+			stmmac_dispatch_skb_zc(priv, queue, p, np, buf->xdp);
+			xsk_buff_free(buf->xdp);
+			break;
+		case STMMAC_XDP_CONSUMED:
+			xsk_buff_free(buf->xdp);
+			priv->dev->stats.rx_dropped++;
+			break;
+		case STMMAC_XDP_TX:
+		case STMMAC_XDP_REDIRECT:
+			xdp_status |= res;
+			break;
+		}
+
+		buf->xdp = NULL;
+		dirty++;
+		count++;
+	}
+
+	if (status & rx_not_ls) {
+		rx_q->state_saved = true;
+		rx_q->state.error = error;
+		rx_q->state.len = len;
+	}
+
+	stmmac_finalize_xdp_rx(priv, xdp_status);
+
+	if (xsk_uses_need_wakeup(rx_q->xsk_pool)) {
+		if (failure || stmmac_rx_dirty(priv, queue) > 0)
+			xsk_set_rx_need_wakeup(rx_q->xsk_pool);
+		else
+			xsk_clear_rx_need_wakeup(rx_q->xsk_pool);
+
+		return (int)count;
+	}
+
+	return failure ? limit : (int)count;
+}
+
 /**
  * stmmac_rx - manage the receive process
  * @priv: driver private structure
@@ -4766,12 +5197,17 @@ static int stmmac_napi_poll_rx(struct napi_struct *napi, int budget)
 	struct stmmac_channel *ch =
 		container_of(napi, struct stmmac_channel, rx_napi);
 	struct stmmac_priv *priv = ch->priv_data;
+	struct stmmac_rx_queue *rx_q;
 	u32 chan = ch->index;
 	int work_done;
 
 	priv->xstats.napi_poll++;
 
-	work_done = stmmac_rx(priv, budget, chan);
+	rx_q = &priv->rx_queue[chan];
+
+	work_done = rx_q->xsk_pool ?
+		    stmmac_rx_zc(priv, budget, chan) :
+		    stmmac_rx(priv, budget, chan);
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
 		unsigned long flags;
 
@@ -5675,6 +6111,9 @@ static int stmmac_bpf(struct net_device *dev, struct netdev_bpf *bpf)
 	switch (bpf->command) {
 	case XDP_SETUP_PROG:
 		return stmmac_xdp_set_prog(priv, bpf->prog, bpf->extack);
+	case XDP_SETUP_XSK_POOL:
+		return stmmac_xdp_setup_pool(priv, bpf->xsk.pool,
+					     bpf->xsk.queue_id);
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -5722,6 +6161,102 @@ static int stmmac_xdp_xmit(struct net_device *dev, int num_frames,
 	return nxmit;
 }
 
+void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_disable_dma_irq(priv, priv->ioaddr, queue, 1, 0);
+	spin_unlock_irqrestore(&ch->lock, flags);
+
+	stmmac_stop_rx_dma(priv, queue);
+	__free_dma_rx_desc_resources(priv, queue);
+}
+
+void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+	u32 buf_size;
+	int ret;
+
+	ret = __alloc_dma_rx_desc_resources(priv, queue);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to alloc RX desc.\n");
+		return;
+	}
+
+	ret = __init_dma_rx_desc_rings(priv, queue, GFP_KERNEL);
+	if (ret) {
+		__free_dma_rx_desc_resources(priv, queue);
+		netdev_err(priv->dev, "Failed to init RX desc.\n");
+		return;
+	}
+
+	stmmac_clear_rx_descriptors(priv, queue);
+
+	stmmac_init_rx_chan(priv, priv->ioaddr, priv->plat->dma_cfg,
+			    rx_q->dma_rx_phy, rx_q->queue_index);
+
+	rx_q->rx_tail_addr = rx_q->dma_rx_phy + (rx_q->buf_alloc_num *
+			     sizeof(struct dma_desc));
+	stmmac_set_rx_tail_ptr(priv, priv->ioaddr,
+			       rx_q->rx_tail_addr, rx_q->queue_index);
+
+	if (rx_q->xsk_pool && rx_q->buf_alloc_num) {
+		buf_size = xsk_pool_get_rx_frame_size(rx_q->xsk_pool);
+		stmmac_set_dma_bfsize(priv, priv->ioaddr,
+				      buf_size,
+				      rx_q->queue_index);
+	} else {
+		stmmac_set_dma_bfsize(priv, priv->ioaddr,
+				      priv->dma_buf_sz,
+				      rx_q->queue_index);
+	}
+
+	stmmac_start_rx_dma(priv, queue);
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_enable_dma_irq(priv, priv->ioaddr, queue, 1, 0);
+	spin_unlock_irqrestore(&ch->lock, flags);
+}
+
+int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	struct stmmac_rx_queue *rx_q;
+	struct stmmac_channel *ch;
+
+	if (test_bit(STMMAC_DOWN, &priv->state) ||
+	    !netif_carrier_ok(priv->dev))
+		return -ENETDOWN;
+
+	if (!stmmac_xdp_is_enabled(priv))
+		return -ENXIO;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	rx_q = &priv->rx_queue[queue];
+	ch = &priv->channel[queue];
+
+	if (!rx_q->xsk_pool)
+		return -ENXIO;
+
+	if (flags & XDP_WAKEUP_RX &&
+	    !napi_if_scheduled_mark_missed(&ch->rx_napi)) {
+		/* EQoS does not have per-DMA channel SW interrupt,
+		 * so we schedule RX Napi straight-away.
+		 */
+		if (likely(napi_schedule_prep(&ch->rx_napi)))
+			__napi_schedule(&ch->rx_napi);
+	}
+
+	return 0;
+}
+
 static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_open = stmmac_open,
 	.ndo_start_xmit = stmmac_xmit,
@@ -5742,6 +6277,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_vlan_rx_kill_vid = stmmac_vlan_rx_kill_vid,
 	.ndo_bpf = stmmac_bpf,
 	.ndo_xdp_xmit = stmmac_xdp_xmit,
+	.ndo_xsk_wakeup = stmmac_xsk_wakeup,
 };
 
 static void stmmac_reset_subtask(struct stmmac_priv *priv)
@@ -6075,6 +6611,10 @@ int stmmac_dvr_probe(struct device *device,
 	/* Verify driver arguments */
 	stmmac_verify_args();
 
+	priv->af_xdp_zc_qps = bitmap_zalloc(MTL_MAX_TX_QUEUES, GFP_KERNEL);
+	if (!priv->af_xdp_zc_qps)
+		return -ENOMEM;
+
 	/* Allocate workqueue */
 	priv->wq = create_singlethread_workqueue("stmmac_wq");
 	if (!priv->wq) {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
index bf38d231860b..b1f6362484f0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
@@ -1,9 +1,95 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (c) 2021, Intel Corporation. */
 
+#include <net/xdp_sock_drv.h>
+
 #include "stmmac.h"
 #include "stmmac_xdp.h"
 
+static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
+				  struct xsk_buff_pool *pool, u16 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	bool need_update;
+	u32 frame_size;
+	int err;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	frame_size = xsk_pool_get_rx_frame_size(pool);
+	/* XDP ZC does not span multiple frame, make sure XSK pool buffer
+	 * size can at least store Q-in-Q frame.
+	 */
+	if (frame_size < ETH_FRAME_LEN + VLAN_HLEN * 2)
+		return -EOPNOTSUPP;
+
+	err = xsk_pool_dma_map(pool, priv->device, STMMAC_RX_DMA_ATTR);
+	if (err) {
+		netdev_err(priv->dev, "Failed to map xsk pool\n");
+		return err;
+	}
+
+	need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv);
+
+	if (need_update) {
+		stmmac_disable_rx_queue(priv, queue);
+		napi_disable(&ch->rx_napi);
+	}
+
+	set_bit(queue, priv->af_xdp_zc_qps);
+
+	if (need_update) {
+		napi_enable(&ch->rx_napi);
+		stmmac_enable_rx_queue(priv, queue);
+
+		err = stmmac_xsk_wakeup(priv->dev, queue, XDP_WAKEUP_RX);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	struct xsk_buff_pool *pool;
+	bool need_update;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	pool = xsk_get_pool_from_qid(priv->dev, queue);
+	if (!pool)
+		return -EINVAL;
+
+	need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv);
+
+	if (need_update) {
+		stmmac_disable_rx_queue(priv, queue);
+		napi_disable(&ch->rx_napi);
+	}
+
+	xsk_pool_dma_unmap(pool, STMMAC_RX_DMA_ATTR);
+
+	clear_bit(queue, priv->af_xdp_zc_qps);
+
+	if (need_update) {
+		napi_enable(&ch->rx_napi);
+		stmmac_enable_rx_queue(priv, queue);
+	}
+
+	return 0;
+}
+
+int stmmac_xdp_setup_pool(struct stmmac_priv *priv, struct xsk_buff_pool *pool,
+			  u16 queue)
+{
+	return pool ? stmmac_xdp_enable_pool(priv, pool, queue) :
+		      stmmac_xdp_disable_pool(priv, queue);
+}
+
 int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
 			struct netlink_ext_ack *extack)
 {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
index 93948569d92a..896dc987d4ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
@@ -5,7 +5,10 @@
 #define _STMMAC_XDP_H_
 
 #define STMMAC_MAX_RX_BUF_SIZE(num)	(((num) * PAGE_SIZE) - XDP_PACKET_HEADROOM)
+#define STMMAC_RX_DMA_ATTR	(DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING)
 
+int stmmac_xdp_setup_pool(struct stmmac_priv *priv, struct xsk_buff_pool *pool,
+			  u16 queue);
 int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
 			struct netlink_ext_ack *extack);
 
-- 
2.25.1



From boon.leong.ong at intel.com  Mon Apr 12 16:41:30 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Mon, 12 Apr 2021 23:41:30 +0800
Subject: [PATCH net-next 7/7] net: stmmac: Add TX via XDP zero-copy socket
In-Reply-To: <20210412154130.20742-1-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
Message-ID: <20210412154130.20742-8-boon.leong.ong@intel.com>

We add the support of XDP ZC TX submission and cleaning into
stmmac_tx_clean(). The function is made to clean as many TX complete
frames as possible, i.e. limit by priv->dma_tx_size instead of NAPI
budget. For TX ring that is associated with XSK pool, the function
stmmac_xdp_xmit_zc() is introduced to TX frame buffers from XSK pool by
using xsk_tx_peek_desc(). To make stmmac_tx_clean() support the cleaning
of XSK TX frames, STMMAC_TXBUF_T_XSK_TX TX buffer type is introduced.

As stmmac_tx_clean() uses the return value to cue whether NAPI function
should continue to poll, we augment the caller of stmmac_tx_clean() to
pass NAPI budget instead of priv->dma_tx_size through 'budget' input and
made stmmac_tx_clean() to always clean up-to the TX ring size instead.
This allows us to use the return boolean status of stmmac_xdp_xmit_zc()
to decide if XSK TX work is done or not: If true, set 'xmits' to return
'budget - 1' so that NAPI poll may exit. Else, set 'xmits' to return
'budget' to make NAPI poll continue to poll since XSK TX work is not
done. Finally, at the end of stmmac_tx_clean(), the function now take
a maximum value between 'count' and 'xmits' so that status from both
TX cleaning and XSK TX (only for XDP ZC) is considered.

This patch adds a new NAPI poll called stmmac_napi_poll_rxtx() that is
meant to be enabled/disabled for RX and TX ring that are bound to XSK
pool. This NAPI poll function starts with cleaning TX ring, then submits
XSK TX frames to TX ring before proceed to perform RX operations, i.e.
, receiving RX frames and replenishing RX ring with RX free buffers
obtained from XSK pool. Therefore, during XSK RX and TX setup, the driver
enables stmmac_napi_poll_rxtx() for RX and TX operations, then during
XSK RX and TX pool tear-down, the driver reenables the exisiting
independent NAPI poll functions accordingly: stmmac_napi_poll_rx() and
stmmac_napi_poll_tx().

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   6 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 317 ++++++++++++++++--
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  16 +-
 3 files changed, 310 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index aa0db622ee69..3d9ceb6234eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -40,6 +40,7 @@ enum stmmac_txbuf_type {
 	STMMAC_TXBUF_T_SKB,
 	STMMAC_TXBUF_T_XDP_TX,
 	STMMAC_TXBUF_T_XDP_NDO,
+	STMMAC_TXBUF_T_XSK_TX,
 };
 
 struct stmmac_tx_info {
@@ -69,6 +70,8 @@ struct stmmac_tx_queue {
 		struct xdp_frame **xdpf;
 	};
 	struct stmmac_tx_info *tx_skbuff_dma;
+	struct xsk_buff_pool *xsk_pool;
+	u32 xsk_frames_done;
 	unsigned int cur_tx;
 	unsigned int dirty_tx;
 	dma_addr_t dma_tx_phy;
@@ -116,6 +119,7 @@ struct stmmac_rx_queue {
 struct stmmac_channel {
 	struct napi_struct rx_napi ____cacheline_aligned_in_smp;
 	struct napi_struct tx_napi ____cacheline_aligned_in_smp;
+	struct napi_struct rxtx_napi ____cacheline_aligned_in_smp;
 	struct stmmac_priv *priv_data;
 	spinlock_t lock;
 	u32 index;
@@ -338,6 +342,8 @@ static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
 
 void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue);
 void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_disable_tx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_enable_tx_queue(struct stmmac_priv *priv, u32 queue);
 int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags);
 
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index dace043de13c..8e085647a02e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -70,6 +70,9 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_TX_THRESH(x)	((x)->dma_tx_size / 4)
 #define STMMAC_RX_THRESH(x)	((x)->dma_rx_size / 4)
 
+/* Limit to make sure XDP TX and slow path can coexist */
+#define STMMAC_XSK_TX_BUDGET_MAX	256
+#define STMMAC_TX_XSK_AVAIL		16
 #define STMMAC_RX_FILL_BATCH		16
 
 #define STMMAC_XDP_PASS		0
@@ -120,6 +123,8 @@ 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 void stmmac_tx_timer_arm(struct stmmac_priv *priv, u32 queue);
+static void stmmac_flush_tx_descriptors(struct stmmac_priv *priv, int queue);
 
 #ifdef CONFIG_DEBUG_FS
 static const struct net_device_ops stmmac_netdev_ops;
@@ -206,6 +211,12 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
 	for (queue = 0; queue < maxq; queue++) {
 		struct stmmac_channel *ch = &priv->channel[queue];
 
+		if (stmmac_xdp_is_enabled(priv) &&
+		    test_bit(queue, priv->af_xdp_zc_qps)) {
+			napi_disable(&ch->rxtx_napi);
+			continue;
+		}
+
 		if (queue < rx_queues_cnt)
 			napi_disable(&ch->rx_napi);
 		if (queue < tx_queues_cnt)
@@ -227,6 +238,12 @@ static void stmmac_enable_all_queues(struct stmmac_priv *priv)
 	for (queue = 0; queue < maxq; queue++) {
 		struct stmmac_channel *ch = &priv->channel[queue];
 
+		if (stmmac_xdp_is_enabled(priv) &&
+		    test_bit(queue, priv->af_xdp_zc_qps)) {
+			napi_enable(&ch->rxtx_napi);
+			continue;
+		}
+
 		if (queue < rx_queues_cnt)
 			napi_enable(&ch->rx_napi);
 		if (queue < tx_queues_cnt)
@@ -1480,6 +1497,9 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 		tx_q->xdpf[i] = NULL;
 	}
 
+	if (tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XSK_TX)
+		tx_q->xsk_frames_done++;
+
 	if (tx_q->tx_skbuff[i] &&
 	    tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_SKB) {
 		dev_kfree_skb_any(tx_q->tx_skbuff[i]);
@@ -1802,6 +1822,8 @@ static int __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)
 					 priv->dma_tx_size, 0);
 	}
 
+	tx_q->xsk_pool = stmmac_get_xsk_pool(priv, queue);
+
 	for (i = 0; i < priv->dma_tx_size; i++) {
 		struct dma_desc *p;
 
@@ -1878,10 +1900,19 @@ static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
  */
 static void dma_free_tx_skbufs(struct stmmac_priv *priv, u32 queue)
 {
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	int i;
 
+	tx_q->xsk_frames_done = 0;
+
 	for (i = 0; i < priv->dma_tx_size; i++)
 		stmmac_free_tx_buffer(priv, queue, i);
+
+	if (tx_q->xsk_pool && tx_q->xsk_frames_done) {
+		xsk_tx_completed(tx_q->xsk_pool, tx_q->xsk_frames_done);
+		tx_q->xsk_frames_done = 0;
+		tx_q->xsk_pool = NULL;
+	}
 }
 
 /**
@@ -2002,6 +2033,7 @@ static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 	bool xdp_prog = stmmac_xdp_is_enabled(priv);
 	struct page_pool_params pp_params = { 0 };
 	unsigned int num_pages;
+	unsigned int napi_id;
 	int ret;
 
 	rx_q->queue_index = queue;
@@ -2049,9 +2081,15 @@ static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 			return -ENOMEM;
 	}
 
+	if (stmmac_xdp_is_enabled(priv) &&
+	    test_bit(queue, priv->af_xdp_zc_qps))
+		napi_id = ch->rxtx_napi.napi_id;
+	else
+		napi_id = ch->rx_napi.napi_id;
+
 	ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
 			       rx_q->queue_index,
-			       ch->rx_napi.napi_id);
+			       napi_id);
 	if (ret) {
 		netdev_err(priv->dev, "Failed to register xdp rxq info\n");
 		return -EINVAL;
@@ -2373,6 +2411,101 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 	}
 }
 
+static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
+{
+	struct netdev_queue *nq = netdev_get_tx_queue(priv->dev, queue);
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	struct xsk_buff_pool *pool = tx_q->xsk_pool;
+	unsigned int entry = tx_q->cur_tx;
+	struct dma_desc *tx_desc = NULL;
+	struct xdp_desc xdp_desc;
+	bool work_done = true;
+
+	/* Avoids TX time-out as we are sharing with slow path */
+	nq->trans_start = jiffies;
+
+	budget = min(budget, stmmac_tx_avail(priv, queue));
+
+	while (budget-- > 0) {
+		dma_addr_t dma_addr;
+		bool set_ic;
+
+		/* We are sharing with slow path and stop XSK TX desc submission when
+		 * available TX ring is less than threshold.
+		 */
+		if (unlikely(stmmac_tx_avail(priv, queue) < STMMAC_TX_XSK_AVAIL) ||
+		    !netif_carrier_ok(priv->dev)) {
+			work_done = false;
+			break;
+		}
+
+		if (!xsk_tx_peek_desc(pool, &xdp_desc))
+			break;
+
+		if (likely(priv->extend_desc))
+			tx_desc = (struct dma_desc *)(tx_q->dma_etx + entry);
+		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+			tx_desc = &tx_q->dma_entx[entry].basic;
+		else
+			tx_desc = tx_q->dma_tx + entry;
+
+		dma_addr = xsk_buff_raw_get_dma(pool, xdp_desc.addr);
+		xsk_buff_raw_dma_sync_for_device(pool, dma_addr, xdp_desc.len);
+
+		tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XSK_TX;
+
+		/* To return XDP buffer to XSK pool, we simple call
+		 * xsk_tx_completed(), so we don't need to fill up
+		 * 'buf' and 'xdpf'.
+		 */
+		tx_q->tx_skbuff_dma[entry].buf = 0;
+		tx_q->xdpf[entry] = NULL;
+
+		tx_q->tx_skbuff_dma[entry].map_as_page = false;
+		tx_q->tx_skbuff_dma[entry].len = xdp_desc.len;
+		tx_q->tx_skbuff_dma[entry].last_segment = true;
+		tx_q->tx_skbuff_dma[entry].is_jumbo = false;
+
+		stmmac_set_desc_addr(priv, tx_desc, dma_addr);
+
+		tx_q->tx_count_frames++;
+
+		if (!priv->tx_coal_frames[queue])
+			set_ic = false;
+		else if (tx_q->tx_count_frames % priv->tx_coal_frames[queue] == 0)
+			set_ic = true;
+		else
+			set_ic = false;
+
+		if (set_ic) {
+			tx_q->tx_count_frames = 0;
+			stmmac_set_tx_ic(priv, tx_desc);
+			priv->xstats.tx_set_ic_bit++;
+		}
+
+		stmmac_prepare_tx_desc(priv, tx_desc, 1, xdp_desc.len,
+				       true, priv->mode, true, true,
+				       xdp_desc.len);
+
+		stmmac_enable_dma_transmission(priv, priv->ioaddr);
+
+		tx_q->cur_tx = STMMAC_GET_ENTRY(tx_q->cur_tx, priv->dma_tx_size);
+		entry = tx_q->cur_tx;
+	}
+
+	if (tx_desc) {
+		stmmac_flush_tx_descriptors(priv, queue);
+		xsk_tx_release(pool);
+	}
+
+	/* Return true if all of the 3 conditions are met
+	 *  a) TX Budget is still available
+	 *  b) work_done = true when XSK TX desc peek is empty (no more
+	 *     pending XSK TX for transmission)
+	 */
+	return !!budget && work_done;
+}
+
 /**
  * stmmac_tx_clean - to manage the transmission completion
  * @priv: driver private structure
@@ -2384,14 +2517,18 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 {
 	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	unsigned int bytes_compl = 0, pkts_compl = 0;
-	unsigned int entry, count = 0;
+	unsigned int entry, xmits = 0, count = 0;
 
 	__netif_tx_lock_bh(netdev_get_tx_queue(priv->dev, queue));
 
 	priv->xstats.tx_clean++;
 
+	tx_q->xsk_frames_done = 0;
+
 	entry = tx_q->dirty_tx;
-	while ((entry != tx_q->cur_tx) && (count < budget)) {
+
+	/* Try to clean all TX complete frame in 1 shot */
+	while ((entry != tx_q->cur_tx) && count < priv->dma_tx_size) {
 		struct xdp_frame *xdpf;
 		struct sk_buff *skb;
 		struct dma_desc *p;
@@ -2476,6 +2613,9 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 			tx_q->xdpf[entry] = NULL;
 		}
 
+		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XSK_TX)
+			tx_q->xsk_frames_done++;
+
 		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
 			if (likely(skb)) {
 				pkts_compl++;
@@ -2503,6 +2643,28 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 		netif_tx_wake_queue(netdev_get_tx_queue(priv->dev, queue));
 	}
 
+	if (tx_q->xsk_pool) {
+		bool work_done;
+
+		if (tx_q->xsk_frames_done)
+			xsk_tx_completed(tx_q->xsk_pool, tx_q->xsk_frames_done);
+
+		if (xsk_uses_need_wakeup(tx_q->xsk_pool))
+			xsk_set_tx_need_wakeup(tx_q->xsk_pool);
+
+		/* For XSK TX, we try to send as many as possible.
+		 * If XSK work done (XSK TX desc empty and budget still
+		 * available), return "budget - 1" to reenable TX IRQ.
+		 * Else, return "budget" to make NAPI continue polling.
+		 */
+		work_done = stmmac_xdp_xmit_zc(priv, queue,
+					       STMMAC_XSK_TX_BUDGET_MAX);
+		if (work_done)
+			xmits = budget - 1;
+		else
+			xmits = budget;
+	}
+
 	if (priv->eee_enabled && !priv->tx_path_in_lpi_mode &&
 	    priv->eee_sw_timer_en) {
 		stmmac_enable_eee_mode(priv);
@@ -2517,7 +2679,8 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 
 	__netif_tx_unlock_bh(netdev_get_tx_queue(priv->dev, queue));
 
-	return count;
+	/* Combine decisions from TX clean and XSK TX */
+	return max(count, xmits);
 }
 
 /**
@@ -2599,24 +2762,31 @@ static int stmmac_napi_check(struct stmmac_priv *priv, u32 chan, u32 dir)
 {
 	int status = stmmac_dma_interrupt_status(priv, priv->ioaddr,
 						 &priv->xstats, chan, dir);
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[chan];
 	struct stmmac_channel *ch = &priv->channel[chan];
+	struct napi_struct *rx_napi;
+	struct napi_struct *tx_napi;
 	unsigned long flags;
 
+	rx_napi = rx_q->xsk_pool ? &ch->rxtx_napi : &ch->rx_napi;
+	tx_napi = tx_q->xsk_pool ? &ch->rxtx_napi : &ch->tx_napi;
+
 	if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) {
-		if (napi_schedule_prep(&ch->rx_napi)) {
+		if (napi_schedule_prep(rx_napi)) {
 			spin_lock_irqsave(&ch->lock, flags);
 			stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 1, 0);
 			spin_unlock_irqrestore(&ch->lock, flags);
-			__napi_schedule(&ch->rx_napi);
+			__napi_schedule(rx_napi);
 		}
 	}
 
 	if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) {
-		if (napi_schedule_prep(&ch->tx_napi)) {
+		if (napi_schedule_prep(tx_napi)) {
 			spin_lock_irqsave(&ch->lock, flags);
 			stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 0, 1);
 			spin_unlock_irqrestore(&ch->lock, flags);
-			__napi_schedule(&ch->tx_napi);
+			__napi_schedule(tx_napi);
 		}
 	}
 
@@ -2814,16 +2984,18 @@ static enum hrtimer_restart stmmac_tx_timer(struct hrtimer *t)
 	struct stmmac_tx_queue *tx_q = container_of(t, struct stmmac_tx_queue, txtimer);
 	struct stmmac_priv *priv = tx_q->priv_data;
 	struct stmmac_channel *ch;
+	struct napi_struct *napi;
 
 	ch = &priv->channel[tx_q->queue_index];
+	napi = tx_q->xsk_pool ? &ch->rxtx_napi : &ch->tx_napi;
 
-	if (likely(napi_schedule_prep(&ch->tx_napi))) {
+	if (likely(napi_schedule_prep(napi))) {
 		unsigned long flags;
 
 		spin_lock_irqsave(&ch->lock, flags);
 		stmmac_disable_dma_irq(priv, priv->ioaddr, ch->index, 0, 1);
 		spin_unlock_irqrestore(&ch->lock, flags);
-		__napi_schedule(&ch->tx_napi);
+		__napi_schedule(napi);
 	}
 
 	return HRTIMER_NORESTART;
@@ -4621,7 +4793,7 @@ static struct sk_buff *stmmac_construct_skb_zc(struct stmmac_channel *ch,
 	unsigned int datasize = xdp->data_end - xdp->data;
 	struct sk_buff *skb;
 
-	skb = __napi_alloc_skb(&ch->rx_napi,
+	skb = __napi_alloc_skb(&ch->rxtx_napi,
 			       xdp->data_end - xdp->data_hard_start,
 			       GFP_ATOMIC | __GFP_NOWARN);
 	if (unlikely(!skb))
@@ -4665,7 +4837,7 @@ static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue,
 		skb_set_hash(skb, hash, hash_type);
 
 	skb_record_rx_queue(skb, queue);
-	napi_gro_receive(&ch->rx_napi, skb);
+	napi_gro_receive(&ch->rxtx_napi, skb);
 
 	priv->dev->stats.rx_packets++;
 	priv->dev->stats.rx_bytes += len;
@@ -5197,17 +5369,12 @@ static int stmmac_napi_poll_rx(struct napi_struct *napi, int budget)
 	struct stmmac_channel *ch =
 		container_of(napi, struct stmmac_channel, rx_napi);
 	struct stmmac_priv *priv = ch->priv_data;
-	struct stmmac_rx_queue *rx_q;
 	u32 chan = ch->index;
 	int work_done;
 
 	priv->xstats.napi_poll++;
 
-	rx_q = &priv->rx_queue[chan];
-
-	work_done = rx_q->xsk_pool ?
-		    stmmac_rx_zc(priv, budget, chan) :
-		    stmmac_rx(priv, budget, chan);
+	work_done = stmmac_rx(priv, budget, chan);
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
 		unsigned long flags;
 
@@ -5229,7 +5396,7 @@ static int stmmac_napi_poll_tx(struct napi_struct *napi, int budget)
 
 	priv->xstats.napi_poll++;
 
-	work_done = stmmac_tx_clean(priv, priv->dma_tx_size, chan);
+	work_done = stmmac_tx_clean(priv, budget, chan);
 	work_done = min(work_done, budget);
 
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
@@ -5243,6 +5410,42 @@ static int stmmac_napi_poll_tx(struct napi_struct *napi, int budget)
 	return work_done;
 }
 
+static int stmmac_napi_poll_rxtx(struct napi_struct *napi, int budget)
+{
+	struct stmmac_channel *ch =
+		container_of(napi, struct stmmac_channel, rxtx_napi);
+	struct stmmac_priv *priv = ch->priv_data;
+	int rx_done, tx_done;
+	u32 chan = ch->index;
+
+	priv->xstats.napi_poll++;
+
+	tx_done = stmmac_tx_clean(priv, budget, chan);
+	tx_done = min(tx_done, budget);
+
+	rx_done = stmmac_rx_zc(priv, budget, chan);
+
+	/* If either TX or RX work is not complete, return budget
+	 * and keep pooling
+	 */
+	if (tx_done >= budget || rx_done >= budget)
+		return budget;
+
+	/* all work done, exit the polling mode */
+	if (napi_complete_done(napi, rx_done)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&ch->lock, flags);
+		/* Both RX and TX work done are compelte,
+		 * so enable both RX & TX IRQs.
+		 */
+		stmmac_enable_dma_irq(priv, priv->ioaddr, chan, 1, 1);
+		spin_unlock_irqrestore(&ch->lock, flags);
+	}
+
+	return min(rx_done, budget - 1);
+}
+
 /**
  *  stmmac_tx_timeout
  *  @dev : Pointer to net device structure
@@ -6223,10 +6426,63 @@ void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue)
 	spin_unlock_irqrestore(&ch->lock, flags);
 }
 
+void stmmac_disable_tx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_disable_dma_irq(priv, priv->ioaddr, queue, 0, 1);
+	spin_unlock_irqrestore(&ch->lock, flags);
+
+	stmmac_stop_tx_dma(priv, queue);
+	__free_dma_tx_desc_resources(priv, queue);
+}
+
+void stmmac_enable_tx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+	int ret;
+
+	ret = __alloc_dma_tx_desc_resources(priv, queue);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to alloc TX desc.\n");
+		return;
+	}
+
+	ret = __init_dma_tx_desc_rings(priv, queue);
+	if (ret) {
+		__free_dma_tx_desc_resources(priv, queue);
+		netdev_err(priv->dev, "Failed to init TX desc.\n");
+		return;
+	}
+
+	stmmac_clear_tx_descriptors(priv, queue);
+
+	stmmac_init_tx_chan(priv, priv->ioaddr, priv->plat->dma_cfg,
+			    tx_q->dma_tx_phy, tx_q->queue_index);
+
+	if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		stmmac_enable_tbs(priv, priv->ioaddr, 1, tx_q->queue_index);
+
+	tx_q->tx_tail_addr = tx_q->dma_tx_phy;
+	stmmac_set_tx_tail_ptr(priv, priv->ioaddr,
+			       tx_q->tx_tail_addr, tx_q->queue_index);
+
+	stmmac_start_tx_dma(priv, queue);
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_enable_dma_irq(priv, priv->ioaddr, queue, 0, 1);
+	spin_unlock_irqrestore(&ch->lock, flags);
+}
+
 int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	struct stmmac_rx_queue *rx_q;
+	struct stmmac_tx_queue *tx_q;
 	struct stmmac_channel *ch;
 
 	if (test_bit(STMMAC_DOWN, &priv->state) ||
@@ -6236,22 +6492,23 @@ int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
 	if (!stmmac_xdp_is_enabled(priv))
 		return -ENXIO;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	rx_q = &priv->rx_queue[queue];
+	tx_q = &priv->tx_queue[queue];
 	ch = &priv->channel[queue];
 
-	if (!rx_q->xsk_pool)
+	if (!rx_q->xsk_pool && !tx_q->xsk_pool)
 		return -ENXIO;
 
-	if (flags & XDP_WAKEUP_RX &&
-	    !napi_if_scheduled_mark_missed(&ch->rx_napi)) {
+	if (!napi_if_scheduled_mark_missed(&ch->rxtx_napi)) {
 		/* EQoS does not have per-DMA channel SW interrupt,
 		 * so we schedule RX Napi straight-away.
 		 */
-		if (likely(napi_schedule_prep(&ch->rx_napi)))
-			__napi_schedule(&ch->rx_napi);
+		if (likely(napi_schedule_prep(&ch->rxtx_napi)))
+			__napi_schedule(&ch->rxtx_napi);
 	}
 
 	return 0;
@@ -6436,6 +6693,12 @@ static void stmmac_napi_add(struct net_device *dev)
 					  stmmac_napi_poll_tx,
 					  NAPI_POLL_WEIGHT);
 		}
+		if (queue < priv->plat->rx_queues_to_use &&
+		    queue < priv->plat->tx_queues_to_use) {
+			netif_napi_add(dev, &ch->rxtx_napi,
+				       stmmac_napi_poll_rxtx,
+				       NAPI_POLL_WEIGHT);
+		}
 	}
 }
 
@@ -6453,6 +6716,10 @@ static void stmmac_napi_del(struct net_device *dev)
 			netif_napi_del(&ch->rx_napi);
 		if (queue < priv->plat->tx_queues_to_use)
 			netif_napi_del(&ch->tx_napi);
+		if (queue < priv->plat->rx_queues_to_use &&
+		    queue < priv->plat->tx_queues_to_use) {
+			netif_napi_del(&ch->rxtx_napi);
+		}
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
index b1f6362484f0..34613324795d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
@@ -14,7 +14,8 @@ static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
 	u32 frame_size;
 	int err;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	frame_size = xsk_pool_get_rx_frame_size(pool);
@@ -34,14 +35,17 @@ static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
 
 	if (need_update) {
 		stmmac_disable_rx_queue(priv, queue);
+		stmmac_disable_tx_queue(priv, queue);
 		napi_disable(&ch->rx_napi);
+		napi_disable(&ch->tx_napi);
 	}
 
 	set_bit(queue, priv->af_xdp_zc_qps);
 
 	if (need_update) {
-		napi_enable(&ch->rx_napi);
+		napi_enable(&ch->rxtx_napi);
 		stmmac_enable_rx_queue(priv, queue);
+		stmmac_enable_tx_queue(priv, queue);
 
 		err = stmmac_xsk_wakeup(priv->dev, queue, XDP_WAKEUP_RX);
 		if (err)
@@ -57,7 +61,8 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 	struct xsk_buff_pool *pool;
 	bool need_update;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	pool = xsk_get_pool_from_qid(priv->dev, queue);
@@ -68,7 +73,8 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 
 	if (need_update) {
 		stmmac_disable_rx_queue(priv, queue);
-		napi_disable(&ch->rx_napi);
+		stmmac_disable_tx_queue(priv, queue);
+		napi_disable(&ch->rxtx_napi);
 	}
 
 	xsk_pool_dma_unmap(pool, STMMAC_RX_DMA_ATTR);
@@ -77,7 +83,9 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 
 	if (need_update) {
 		napi_enable(&ch->rx_napi);
+		napi_enable(&ch->tx_napi);
 		stmmac_enable_rx_queue(priv, queue);
+		stmmac_enable_tx_queue(priv, queue);
 	}
 
 	return 0;
-- 
2.25.1



From jernej.skrabec at siol.net  Mon Apr 12 16:43:49 2021
From: jernej.skrabec at siol.net (Jernej Skrabec)
Date: Mon, 12 Apr 2021 17:43:49 +0200
Subject: [PATCH] media: cedrus: Fix H265 status definitions
Message-ID: <20210412154349.1989045-1-jernej.skrabec@siol.net>

Some of the H265 status flags are wrong. Redefine them to corespond to
Allwinner CedarC open source userspace library. Only one of these flags
is actually used and new value also matches value used in libvdpau-sunxi
library, which is proven to be working.

Note that wrong (old) value in right circumstances (in combination with
another H265 decoding bug) causes driver lock up. With this fix decoding
is still broken (green output) but at least driver doesn't lock up.

Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support")
Signed-off-by: Jernej Skrabec <jernej.skrabec at siol.net>
---
This is the sample which locks up driver:
http://jernej.libreelec.tv/videos/h265/hevc-breakage.mkv

Second bug is actually in HEVC API - dependent slice flag for slice is
missing. Similar flag in PPS exists, but that only tells if this
feature is enabled and should not be used for slice.

This will be fixed later.

 .../staging/media/sunxi/cedrus/cedrus_regs.h    | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h
index 6cb1c279790f..7ab3a2b0aa10 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h
@@ -443,16 +443,17 @@
 #define VE_DEC_H265_STATUS_STCD_BUSY		BIT(21)
 #define VE_DEC_H265_STATUS_WB_BUSY		BIT(20)
 #define VE_DEC_H265_STATUS_BS_DMA_BUSY		BIT(19)
-#define VE_DEC_H265_STATUS_IQIT_BUSY		BIT(18)
+#define VE_DEC_H265_STATUS_IT_BUSY		BIT(18)
 #define VE_DEC_H265_STATUS_INTER_BUSY		BIT(17)
 #define VE_DEC_H265_STATUS_MORE_DATA		BIT(16)
-#define VE_DEC_H265_STATUS_VLD_BUSY		BIT(14)
-#define VE_DEC_H265_STATUS_DEBLOCKING_BUSY	BIT(13)
-#define VE_DEC_H265_STATUS_DEBLOCKING_DRAM_BUSY	BIT(12)
-#define VE_DEC_H265_STATUS_INTRA_BUSY		BIT(11)
-#define VE_DEC_H265_STATUS_SAO_BUSY		BIT(10)
-#define VE_DEC_H265_STATUS_MVP_BUSY		BIT(9)
-#define VE_DEC_H265_STATUS_SWDEC_BUSY		BIT(8)
+#define VE_DEC_H265_STATUS_DBLK_BUSY		BIT(15)
+#define VE_DEC_H265_STATUS_IREC_BUSY		BIT(14)
+#define VE_DEC_H265_STATUS_INTRA_BUSY		BIT(13)
+#define VE_DEC_H265_STATUS_MCRI_BUSY		BIT(12)
+#define VE_DEC_H265_STATUS_IQIT_BUSY		BIT(11)
+#define VE_DEC_H265_STATUS_MVP_BUSY		BIT(10)
+#define VE_DEC_H265_STATUS_IS_BUSY		BIT(9)
+#define VE_DEC_H265_STATUS_VLD_BUSY		BIT(8)
 #define VE_DEC_H265_STATUS_OVER_TIME		BIT(3)
 #define VE_DEC_H265_STATUS_VLD_DATA_REQ		BIT(2)
 #define VE_DEC_H265_STATUS_ERROR		BIT(1)
-- 
2.31.1



From weiyongjun1 at huawei.com  Mon Apr 12 17:00:25 2021
From: weiyongjun1 at huawei.com (Wei Yongjun)
Date: Mon, 12 Apr 2021 16:00:25 +0000
Subject: [PATCH -next] spi: spi-zynqmp-gqspi: Fix missing unlock on error in
 zynqmp_qspi_exec_op()
Message-ID: <20210412160025.194171-1-weiyongjun1@huawei.com>

Add the missing unlock before return from function zynqmp_qspi_exec_op()
in the error handling case.

Fixes: a0f65be6e880 ("spi: spi-zynqmp-gqspi: add mutex locking for exec_op")
Reported-by: Hulk Robot <hulkci at huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 9494da9aea40..1670b0aeaa23 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -965,8 +965,10 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 
 	if (op->cmd.opcode) {
 		tmpbuf = kzalloc(op->cmd.nbytes, GFP_KERNEL | GFP_DMA);
-		if (!tmpbuf)
+		if (!tmpbuf) {
+			mutex_unlock(&xqspi->op_lock);
 			return -ENOMEM;
+		}
 		tmpbuf[0] = op->cmd.opcode;
 		reinit_completion(&xqspi->data_completion);
 		xqspi->txbuf = tmpbuf;



From narmstrong at baylibre.com  Mon Apr 12 16:52:53 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 12 Apr 2021 17:52:53 +0200
Subject: [PATCH v2 1/5] dt-bindings: display: mediatek,hdmi: Convert to
 use graph schema
In-Reply-To: <20210412093928.3321194-2-narmstrong@baylibre.com>
References: <20210412093928.3321194-1-narmstrong@baylibre.com>
 <20210412093928.3321194-2-narmstrong@baylibre.com>
Message-ID: <415e0331-fc7c-6362-e81d-108f7ff8a654@baylibre.com>

On 12/04/2021 11:39, Neil Armstrong wrote:
> Update the mediatek,dpi binding to use the graph schema.
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  .../display/mediatek/mediatek,cec.yaml        |  51 +++++++
>  .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 ++++++++
>  .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
>  .../display/mediatek/mediatek,hdmi.yaml       | 131 +++++++++++++++++
>  4 files changed, 239 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> new file mode 100644
> index 000000000000..408e7dfce409
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek HDMI CEC Controller Device Tree Bindings
> +
> +maintainers:
> +  - CK Hu <ck.hu at mediatek.com>
> +  - Jitao shi <jitao.shi at mediatek.com>
> +
> +description: |
> +  The HDMI CEC controller handles hotplug detection and CEC communication.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - mediatek,mt7623-hdmi

=> mediatek,mt7623-cec

> +      - mediatek,mt8173-hdmi

=> mediatek,mt8173-cec

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1

[..]

> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
> new file mode 100644
> index 000000000000..c15b3470d652
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek HDMI DDC Device Tree Bindings
> +
> +maintainers:
> +  - CK Hu <ck.hu at mediatek.com>
> +  - Jitao shi <jitao.shi at mediatek.com>
> +
> +description: |
> +  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - mediatek,mt7623-hdmi

=> mediatek,mt7623-hdmi-ddc

> +      - mediatek,mt8173-hdmi

=> mediatek,mt8173-hdmi-ddc

> +
> +  reg:
> +    maxItems: 1


[..]
will repost with these fixes in  a few days,

Neil


From robh at kernel.org  Mon Apr 12 16:59:10 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 10:59:10 -0500
Subject: [PATCH v3 1/7] dt-bindings: devapc: Add 'vio-idx-num' field to
 support mt8192
In-Reply-To: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
References: <1617956377-4075-1-git-send-email-nina-cm.wu@mediatek.com>
Message-ID: <20210412155910.GA3966290@robh.at.kernel.org>

On Fri, Apr 09, 2021 at 04:19:31PM +0800, Nina Wu wrote:
> From: Nina Wu <Nina-CM.Wu at mediatek.com>
> 
> For new ICs, there are multiple devapc HWs for different subsys.
> We add a field 'vio-idx-num' in DT to indicate the number of
> devices controlled by each devapc.
> To be backward compatible with old ICs which have only one devapc
> HW, this field is not required. The 'vio-idx-num' info will be set
> in compatible data instead.
> 
> Signed-off-by: Nina Wu <Nina-CM.Wu at mediatek.com>
> ---
>  Documentation/devicetree/bindings/soc/mediatek/devapc.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> index 31e4d3c..909e524 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> @@ -20,11 +20,17 @@ properties:
>    compatible:
>      enum:
>        - mediatek,mt6779-devapc
> +      - mediatek,mt8192-devapc
>  
>    reg:
>      description: The base address of devapc register bank
>      maxItems: 1
>  
> +  mediatek,vio-idx-num:
> +    description: The number of the devices controlled by devapc
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    maxItems: 1

A uint32 is always 1 item, so drop. With that,

Reviewed-by: Rob Herring <robh at kernel.org>

> +
>    interrupts:
>      description: A single interrupt specifier
>      maxItems: 1
> -- 
> 2.6.4
> 


From bjorn.andersson at linaro.org  Mon Apr 12 17:01:16 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 12 Apr 2021 11:01:16 -0500
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
 <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>
Message-ID: <20210412160116.GA904837@yoga>

On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote:

> On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:
> 
> > >
> > > For this merge window, I don't think any of them are show-stoppers (Rob, let me
> > > know if you disagree), but in the long run we may want to gradually enforce
> > > a rule about not merging changes that introduce any new warnings, in order to
> > > have a chance of cleaning up the existing ones.
> >
> > This may not be as simple as it sounds, as DT binding updates typically
> > follow a different path than DTS(i) updates.  DT bindings updates may be
> > picked up by a subsystem maintainer, by Rob, or by the platform
> > maintainer.
> 
> I checked out the bindings from linux-next, which seems to have covered
> most of these. Sometimes it pays off to be lazy and merge them after
> everyone else.
> 
> > For trivial updates (e.g. adding a compatible value, and sometimes
> > extending a limit), a DTS(i) update may be accepted by the platform
> > maintainer before the corresponding DT binding update.  The latter may
> > even be merged one or more kernel revisions later, especially when
> > involving subsystems that are not traditionally rooted into platforms
> > using DT.
> >
> > Of course we could mention any expected warning regressions in our pull
> > requests for soc.
> 
> Right, that would certainly help. Some maintainers send all binding
> updates both to the driver maintainers and to the soc tree, along
> with the other changes that only go into one tree. That is of course
> also more work on your side, but it solves the problem entirely.
> 

So the same binding patch is picked up both in the driver and soc tree?
I was expecting that to cause (harmless) conflicts when things arrive in
Linus' merge queue?

Or are you saying people go the length to create immutable branches for
each binding?


I'm curious because it's fairly often that we introduce clocks,
interconnects etc where the macros from the dt bindings includes aren't
available for another release (so we use numerical constants and then go
back and fix them up later).

Regards,
Bjorn

> > > renesas/r8a774a1-beacon-rzg2m-kit.dt.yaml: csi2 at feaa0000: ports:
> > > 'port at 0' is a required property
> >
> > [...]
> >
> > I've replied to these as a response to your PR reply, see
> > https://lore.kernel.org/linux-renesas-soc/CAMuHMdWHLnXgBSjP7VKUdx-YNr9rSKFkE5Ge5q_tarU6HP9Lhw at mail.gmail.com/
> 
> Ok, thanks.
> 
>       Arnd


From robh at kernel.org  Mon Apr 12 17:02:16 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 11:02:16 -0500
Subject: [PATCH v2 16/24] dt-bindings: atmel-sysreg: add bindings for
 sama7g5
In-Reply-To: <20210409111345.294472-17-claudiu.beznea@microchip.com>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
 <20210409111345.294472-17-claudiu.beznea@microchip.com>
Message-ID: <20210412160216.GA3970458@robh.at.kernel.org>

On Fri, Apr 09, 2021 at 02:13:37PM +0300, Claudiu Beznea wrote:
> Add RAM controller and RAM PHY controller DT bindings.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> ---
>  .../devicetree/bindings/arm/atmel-sysregs.txt     | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
> index 807264a78edc..7cd55a760d41 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
> @@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties:
>  			"atmel,at91sam9260-sdramc",
>  			"atmel,at91sam9g45-ddramc",
>  			"atmel,sama5d3-ddramc",
> -			"microchip,sam9x60-ddramc"
> +			"microchip,sam9x60-ddramc",
> +			"microchip,sama7g5-uddrc"
>  - reg: Should contain registers location and length
>  
>  Examples:
> @@ -55,6 +56,18 @@ Examples:
>  		reg = <0xffffe800 0x200>;
>  	};
>  
> +RAMC PHY Controller required properties:
> +- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
> +- reg: Should contain registers location and length
> +
> +Example:
> +
> +	ddr3phy: ddr3phy at e3804000 {
> +		compatible = "microchip,sama7g5-ddr3phy", "syscon";
> +		reg = <0xe3804000 0x1000>;
> +		status = "okay";

Really need an example for this? If so, drop 'status'.

> +};
> +
>  SHDWC Shutdown Controller
>  
>  required properties:
> -- 
> 2.25.1
> 


From sashal at kernel.org  Mon Apr 12 17:22:20 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:22:20 -0400
Subject: [PATCH AUTOSEL 5.11 15/51] net: axienet: allow setups without MDIO
In-Reply-To: <20210412162256.313524-1-sashal@kernel.org>
References: <20210412162256.313524-1-sashal@kernel.org>
Message-ID: <20210412162256.313524-15-sashal@kernel.org>

From: Daniel Mack <daniel at zonque.org>

[ Upstream commit de9c7854e6e1589f639c6352112956d08243b659 ]

In setups with fixed-link settings there is no mdio node in DTS.
axienet_probe() already handles that gracefully but lp->mii_bus is
then NULL.

Fix code that tries to blindly grab the MDIO lock by introducing two helper
functions that make the locking conditional.

Signed-off-by: Daniel Mack <daniel at zonque.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/net/ethernet/xilinx/xilinx_axienet.h      | 12 ++++++++++++
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 12 ++++++------
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index a03c3ca1b28d..9e2cddba3b5b 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -497,6 +497,18 @@ static inline u32 axinet_ior_read_mcr(struct axienet_local *lp)
 	return axienet_ior(lp, XAE_MDIO_MCR_OFFSET);
 }
 
+static inline void axienet_lock_mii(struct axienet_local *lp)
+{
+	if (lp->mii_bus)
+		mutex_lock(&lp->mii_bus->mdio_lock);
+}
+
+static inline void axienet_unlock_mii(struct axienet_local *lp)
+{
+	if (lp->mii_bus)
+		mutex_unlock(&lp->mii_bus->mdio_lock);
+}
+
 /**
  * axienet_iow - Memory mapped Axi Ethernet register write
  * @lp:         Pointer to axienet local structure
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 4cd701a9277d..82176dd2cdf3 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1053,9 +1053,9 @@ static int axienet_open(struct net_device *ndev)
 	 * including the MDIO. MDIO must be disabled before resetting.
 	 * Hold MDIO bus lock to avoid MDIO accesses during the reset.
 	 */
-	mutex_lock(&lp->mii_bus->mdio_lock);
+	axienet_lock_mii(lp);
 	ret = axienet_device_reset(ndev);
-	mutex_unlock(&lp->mii_bus->mdio_lock);
+	axienet_unlock_mii(lp);
 
 	ret = phylink_of_phy_connect(lp->phylink, lp->dev->of_node, 0);
 	if (ret) {
@@ -1148,9 +1148,9 @@ static int axienet_stop(struct net_device *ndev)
 	}
 
 	/* Do a reset to ensure DMA is really stopped */
-	mutex_lock(&lp->mii_bus->mdio_lock);
+	axienet_lock_mii(lp);
 	__axienet_device_reset(lp);
-	mutex_unlock(&lp->mii_bus->mdio_lock);
+	axienet_unlock_mii(lp);
 
 	cancel_work_sync(&lp->dma_err_task);
 
@@ -1664,9 +1664,9 @@ static void axienet_dma_err_handler(struct work_struct *work)
 	 * including the MDIO. MDIO must be disabled before resetting.
 	 * Hold MDIO bus lock to avoid MDIO accesses during the reset.
 	 */
-	mutex_lock(&lp->mii_bus->mdio_lock);
+	axienet_lock_mii(lp);
 	__axienet_device_reset(lp);
-	mutex_unlock(&lp->mii_bus->mdio_lock);
+	axienet_unlock_mii(lp);
 
 	for (i = 0; i < lp->tx_bd_num; i++) {
 		cur_p = &lp->tx_bd_v[i];
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:22:25 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:22:25 -0400
Subject: [PATCH AUTOSEL 5.11 20/51] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162256.313524-1-sashal@kernel.org>
References: <20210412162256.313524-1-sashal@kernel.org>
Message-ID: <20210412162256.313524-20-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index cd711bfc591f..2c647bdf8d25 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -65,7 +65,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -78,7 +78,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:22:26 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:22:26 -0400
Subject: [PATCH AUTOSEL 5.11 21/51] ARM: omap1: fix building with clang IAS
In-Reply-To: <20210412162256.313524-1-sashal@kernel.org>
References: <20210412162256.313524-1-sashal@kernel.org>
Message-ID: <20210412162256.313524-21-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 28399a5a6d569c9bdb612345e4933046ca37cde5 ]

The clang integrated assembler fails to build one file with
a complex asm instruction:

arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this:
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^

The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently
gas does not care because we first add and then subtract this number,
leading to the immediate value to be the same regardless of the
specific definition of NR_IRQS_LEGACY.

Neither the way that 'gas' just silently builds this file, nor the
way that clang IAS makes nonsensical suggestions for how to fix it
is great. Fortunately there is an easy fix, which is to #include
the header that contains the definition.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Tony Lindgren <tony at atomide.com>
Link: https://lore.kernel.org/r/20210308153430.2530616-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-omap1/ams-delta-fiq-handler.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap1/ams-delta-fiq-handler.S b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
index 14a6c3eb3298..f745a65d3bd7 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq-handler.S
+++ b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
@@ -15,6 +15,7 @@
 #include <linux/platform_data/gpio-omap.h>
 
 #include <asm/assembler.h>
+#include <asm/irq.h>
 
 #include "ams-delta-fiq.h"
 #include "board-ams-delta.h"
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:23:31 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:23:31 -0400
Subject: [PATCH AUTOSEL 5.10 16/46] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162401.314035-1-sashal@kernel.org>
References: <20210412162401.314035-1-sashal@kernel.org>
Message-ID: <20210412162401.314035-16-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 09a65c2dfd73..b8fa01f9516e 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -65,7 +65,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -78,7 +78,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:23:32 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:23:32 -0400
Subject: [PATCH AUTOSEL 5.10 17/46] ARM: omap1: fix building with clang IAS
In-Reply-To: <20210412162401.314035-1-sashal@kernel.org>
References: <20210412162401.314035-1-sashal@kernel.org>
Message-ID: <20210412162401.314035-17-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 28399a5a6d569c9bdb612345e4933046ca37cde5 ]

The clang integrated assembler fails to build one file with
a complex asm instruction:

arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this:
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^

The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently
gas does not care because we first add and then subtract this number,
leading to the immediate value to be the same regardless of the
specific definition of NR_IRQS_LEGACY.

Neither the way that 'gas' just silently builds this file, nor the
way that clang IAS makes nonsensical suggestions for how to fix it
is great. Fortunately there is an easy fix, which is to #include
the header that contains the definition.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Tony Lindgren <tony at atomide.com>
Link: https://lore.kernel.org/r/20210308153430.2530616-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-omap1/ams-delta-fiq-handler.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap1/ams-delta-fiq-handler.S b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
index 14a6c3eb3298..f745a65d3bd7 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq-handler.S
+++ b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
@@ -15,6 +15,7 @@
 #include <linux/platform_data/gpio-omap.h>
 
 #include <asm/assembler.h>
+#include <asm/irq.h>
 
 #include "ams-delta-fiq.h"
 #include "board-ams-delta.h"
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:24:34 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:24:34 -0400
Subject: [PATCH AUTOSEL 5.4 12/39] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162502.314854-1-sashal@kernel.org>
References: <20210412162502.314854-1-sashal@kernel.org>
Message-ID: <20210412162502.314854-12-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..697adedaced4 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -62,7 +62,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -75,7 +75,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:24:35 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:24:35 -0400
Subject: [PATCH AUTOSEL 5.4 13/39] ARM: omap1: fix building with clang IAS
In-Reply-To: <20210412162502.314854-1-sashal@kernel.org>
References: <20210412162502.314854-1-sashal@kernel.org>
Message-ID: <20210412162502.314854-13-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 28399a5a6d569c9bdb612345e4933046ca37cde5 ]

The clang integrated assembler fails to build one file with
a complex asm instruction:

arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this:
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^
arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2
 mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
 ^

The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently
gas does not care because we first add and then subtract this number,
leading to the immediate value to be the same regardless of the
specific definition of NR_IRQS_LEGACY.

Neither the way that 'gas' just silently builds this file, nor the
way that clang IAS makes nonsensical suggestions for how to fix it
is great. Fortunately there is an easy fix, which is to #include
the header that contains the definition.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Tony Lindgren <tony at atomide.com>
Link: https://lore.kernel.org/r/20210308153430.2530616-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-omap1/ams-delta-fiq-handler.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap1/ams-delta-fiq-handler.S b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
index 14a6c3eb3298..f745a65d3bd7 100644
--- a/arch/arm/mach-omap1/ams-delta-fiq-handler.S
+++ b/arch/arm/mach-omap1/ams-delta-fiq-handler.S
@@ -15,6 +15,7 @@
 #include <linux/platform_data/gpio-omap.h>
 
 #include <asm/assembler.h>
+#include <asm/irq.h>
 
 #include "ams-delta-fiq.h"
 #include "board-ams-delta.h"
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:25:32 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:25:32 -0400
Subject: [PATCH AUTOSEL 4.19 07/28] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162553.315227-1-sashal@kernel.org>
References: <20210412162553.315227-1-sashal@kernel.org>
Message-ID: <20210412162553.315227-7-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 84613abf35a3..79ff5b953431 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -65,7 +65,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -78,7 +78,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:26:10 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:26:10 -0400
Subject: [PATCH AUTOSEL 4.14 05/25] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162630.315526-1-sashal@kernel.org>
References: <20210412162630.315526-1-sashal@kernel.org>
Message-ID: <20210412162630.315526-5-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 84613abf35a3..79ff5b953431 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -65,7 +65,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -78,7 +78,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:26:46 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:26:46 -0400
Subject: [PATCH AUTOSEL 4.9 05/23] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162704.315783-1-sashal@kernel.org>
References: <20210412162704.315783-1-sashal@kernel.org>
Message-ID: <20210412162704.315783-5-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 84613abf35a3..79ff5b953431 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -65,7 +65,7 @@ static void __init keystone_init(void)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -78,7 +78,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 12 17:27:18 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 12 Apr 2021 12:27:18 -0400
Subject: [PATCH AUTOSEL 4.4 05/23] ARM: keystone: fix integer overflow warning
In-Reply-To: <20210412162736.316026-1-sashal@kernel.org>
References: <20210412162736.316026-1-sashal@kernel.org>
Message-ID: <20210412162736.316026-5-sashal@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

[ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]

clang warns about an impossible condition when building with 32-bit
phys_addr_t:

arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            mem_end   > KEYSTONE_HIGH_PHYS_END) {
            ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
        if (mem_start < KEYSTONE_HIGH_PHYS_START ||
            ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~

Change the temporary variable to a fixed-size u64 to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Acked-by: Santosh Shilimkar <ssantosh at kernel.org>
Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd at kernel.org'
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm/mach-keystone/keystone.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index c279293f084c..0f1f5c4141d5 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -71,7 +71,7 @@ static phys_addr_t keystone_virt_to_idmap(unsigned long x)
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
-	phys_addr_t mem_start, mem_end;
+	u64 mem_start, mem_end;
 
 	mem_start = memblock_start_of_DRAM();
 	mem_end = memblock_end_of_DRAM();
@@ -84,7 +84,7 @@ static long long __init keystone_pv_fixup(void)
 	if (mem_start < KEYSTONE_HIGH_PHYS_START ||
 	    mem_end   > KEYSTONE_HIGH_PHYS_END) {
 		pr_crit("Invalid address space for memory (%08llx-%08llx)\n",
-		        (u64)mem_start, (u64)mem_end);
+		        mem_start, mem_end);
 		return 0;
 	}
 
-- 
2.30.2



From andre.przywara at arm.com  Mon Apr 12 17:45:58 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 12 Apr 2021 17:45:58 +0100
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
Message-ID: <20210412174558.4ba90cf8@slackpad.fritz.box>

On Mon, 12 Apr 2021 14:20:41 +0800
Chen-Yu Tsai <wens at csie.org> wrote:

> Hi,
> 
> On Mon, Apr 12, 2021 at 8:08 AM Andre Przywara <andre.przywara at arm.com> wrote:
> >
> > Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
> > SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
> > along the way with the Pine64-LTS, which share the same base .dtsi.
> >
> > This was based on the observation that the Pine64-LTS has as "push-push"
> > SD card socket, and that the schematic mentions the card detect GPIO.
> >
> > After having received two reports about failing SD card access with that
> > patch, some more research and polls on that subject revealed that there
> > are at least two different versions of the Pine64-LTS out there:
> > - On some boards (including mine) the card detect pin is "stuck" at
> >   high, regardless of an microSD card being inserted or not.
> > - On other boards the card-detect is working, but is active-high, by
> >   virtue of an explicit inverter circuit, as shown in the schematic.
> >
> > To cover all versions of the board out there, and don't take any chances,
> > let's revert the introduction of the CD GPIO, and go back to the
> > non-removable property for the Pine64-LTS. That should avoid regressions
> > and should work for everyone.
> > The SOPine card detect has proven to be working, so let's keep that
> > GPIO in place.
> >
> > Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
> > Reported-by: Michael Weiser <michael.weiser at gmx.de>
> > Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > index e79ce49e7e6a..843338e19694 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > @@ -21,5 +21,5 @@
> >  };
> >
> >  &mmc0 {
> > -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> > +       non-removable;          /* card detect is broken on some boards */  
> 
> So a revert is good, but has anyone tried using the "broken-cd" instead?

Ha, that's a good idea, I totally forgot about this property!

> That way, at least on Linux, the mmc core resorts to polling for a card.
> At least this way the card is still removable.

Yes indeed, I tested it on my "stuck at 1" Pine64-LTS, and it works like
a charm!

Daniel, Michael, can you test this on your boards? So removing the
cd-gpios property, and adding "broken-cd;" instead?

Cheers,
Andre


From alexandru.elisei at arm.com  Mon Apr 12 17:51:53 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Mon, 12 Apr 2021 17:51:53 +0100
Subject: [PATCH v2] KVM: arm64: Fully zero the vcpu state on reset
In-Reply-To: <20210409173257.3031729-1-maz@kernel.org>
References: <20210409173257.3031729-1-maz@kernel.org>
Message-ID: <977338ef-9b06-1fec-9075-5e9cbdb89bc2@arm.com>

Hi Marc,

On 4/9/21 6:32 PM, Marc Zyngier wrote:
> On vcpu reset, we expect all the registers to be brought back
> to their initial state, which happens to be a bunch of zeroes.
>
> However, some recent commit broke this, and is now leaving a bunch
> of registers (such as the FP state) with whatever was left by the
> guest. My bad.
>
> Zero the reset of the state (32bit SPSRs and FPSIMD state).
>
> Cc: stable at vger.kernel.org
> Fixes: e47c2055c68e ("KVM: arm64: Make struct kvm_regs userspace-only")
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>
> Notes:
>     v2: Only reset the FPSIMD state and the AArch32 SPSRs to avoid
>     corrupting CNTVOFF in creative ways.

I missed that last time, sorry.

>
>  arch/arm64/kvm/reset.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index bd354cd45d28..4b5acd84b8c8 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -242,6 +242,11 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  
>  	/* Reset core registers */
>  	memset(vcpu_gp_regs(vcpu), 0, sizeof(*vcpu_gp_regs(vcpu)));
> +	memset(&vcpu->arch.ctxt.fp_regs, 0, sizeof(vcpu->arch.ctxt.fp_regs));
> +	vcpu->arch.ctxt.spsr_abt = 0;
> +	vcpu->arch.ctxt.spsr_und = 0;
> +	vcpu->arch.ctxt.spsr_irq = 0;
> +	vcpu->arch.ctxt.spsr_fiq = 0;

Checked, and the only fields not touched by the change from struct kvm_cpu_context
are sys_regs and __hyp_running_cpu. __hyp_running_cpu is assumed to be NULL for a
guest and it doesn't change during the lifetime of a VCPU; it is set to NULL when
struct kvm_vcpu is allocated.

CNTVOFF_EL2 is not accessible to userspace (it's not in the sys_reg_descs and in
the invariant_sys_regs arrays), so it's not necessary to reset it in case
userspace changed it. Same for the other registers that are part of the VCPU
context, but are not in sys_reg_descs.

I think it's a good choice to skip zeroing the system registers. I compared
vcpu->arch.ctxt.sys_regs with sys_regs_descs, there were quite a few registers
that were part of the vcpu context (pointer authentication registers, virtual
timer registers, and others) and not part of sys_regs_descs. If someone adds a
register to the VCPU context, but not to sys_regs_descs, I think it would have
been easy to miss the fact that KVM_ARM_VCPU_INIT zeroes it.

Hopefully I haven't missed anything:

Reviewed-by: Alexandru Elisei <alexandru.elisei at arm.com>

Thanks,

Alex

>  	vcpu_gp_regs(vcpu)->pstate = pstate;
>  
>  	/* Reset system registers */


From broonie at kernel.org  Mon Apr 12 17:59:33 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 17:59:33 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409223227.rvf6tfhvgnpzmabn@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
 <20210409223227.rvf6tfhvgnpzmabn@treble>
Message-ID: <20210412165933.GD5379@sirena.org.uk>

On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:

> Hm, for that matter, even without renaming things, a comment above
> stack_trace_save_tsk_reliable() describing the meaning of "reliable"
> would be a good idea.

Might be better to place something at the prototype for
arch_stack_walk_reliable() or cross link the two since that's where any
new architectures should be starting, or perhaps even better to extend
the document that Mark wrote further and point to that from both places.  

Some more explict pointer to live patching as the only user would
definitely be good but I think the more important thing would be writing
down any assumptions in the API that aren't already written down and
we're supposed to be relying on.  Mark's document captured a lot of it
but it sounds like there's more here, and even with knowing that this
interface is only used by live patch and digging into what it does it's
not always clear what happens to work with the code right now and what's
something that's suitable to be relied on.
-------------- 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/20210412/ffcf323a/attachment-0001.sig>

From andrew.smirnov at gmail.com  Mon Apr 12 18:16:27 2021
From: andrew.smirnov at gmail.com (Andrey Smirnov)
Date: Mon, 12 Apr 2021 10:16:27 -0700
Subject: [PATCH v1 1/7] soc: imx: gpcv2: check for errors when r/w
 registers
In-Reply-To: <20210407212122.626137-2-adrien.grassein@gmail.com>
References: <20210407212122.626137-1-adrien.grassein@gmail.com>
 <20210407212122.626137-2-adrien.grassein@gmail.com>
Message-ID: <CAHQ1cqEq3LBvJxNBRC-vVsB7=Uj9qTgBXzuAB5vN92qtxo=7bw@mail.gmail.com>

On Wed, Apr 7, 2021 at 2:21 PM Adrien Grassein
<adrien.grassein at gmail.com> wrote:
>
> Errors were not checked after each access to registers

FWIW, I didn't write any error checking code on purpose since all of
those are memory mapped registers and I don't think there's a case for
those to error out. Don't have a strong opinion on this though.

> and clocks initialisation.
>
> Signed-off-by: Adrien Grassein <adrien.grassein at gmail.com>
> ---
>  drivers/soc/imx/gpcv2.c | 62 ++++++++++++++++++++++++++++++-----------
>  1 file changed, 45 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index db7e7fc321b1..8ec5b1b817c7 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -140,8 +140,12 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
>         int i, ret = 0;
>         u32 pxx_req;
>
> -       regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
> -                          domain->bits.map, domain->bits.map);
> +       ret = regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
> +                                domain->bits.map, domain->bits.map);
> +       if (ret) {
> +               dev_err(domain->dev, "failed to map GPC PGC domain\n");
> +               return ret;
> +       }
>
>         if (has_regulator && on) {
>                 ret = regulator_enable(domain->regulator);
> @@ -152,19 +156,39 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
>         }
>
>         /* Enable reset clocks for all devices in the domain */
> -       for (i = 0; i < domain->num_clks; i++)
> -               clk_prepare_enable(domain->clk[i]);
> +       for (i = 0; i < domain->num_clks; i++) {
> +               ret = clk_prepare_enable(domain->clk[i]);
> +               if (ret) {
> +                       dev_err(domain->dev, "failed to enable clocks\n");
> +                       goto disable_clocks;
> +               }
> +       }
>
> -       if (enable_power_control)
> -               regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
> -                                  GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
> +       if (enable_power_control) {
> +               ret = regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
> +                                        GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
> +               if (ret) {
> +                       dev_err(domain->dev, "failed to enable power control\n");
> +                       goto disable_clocks;
> +               }
> +       }
>
> -       if (domain->bits.hsk)
> -               regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
> -                                  domain->bits.hsk, on ? domain->bits.hsk : 0);
> +       if (domain->bits.hsk) {
> +               ret = regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
> +                                        domain->bits.hsk,
> +                                        on ? domain->bits.hsk : 0);
> +               if (ret) {
> +                       dev_err(domain->dev, "Failed to initiate handshake\n");
> +                       goto disable_power_control;
> +               }
> +       }
>
> -       regmap_update_bits(domain->regmap, offset,
> -                          domain->bits.pxx, domain->bits.pxx);
> +       ret = regmap_update_bits(domain->regmap, offset,
> +                                domain->bits.pxx, domain->bits.pxx);
> +       if (ret) {
> +               dev_err(domain->dev, "failed to command PGC\n");
> +               goto disable_power_control;
> +       }
>
>         /*
>          * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
> @@ -173,8 +197,15 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
>         ret = regmap_read_poll_timeout(domain->regmap, offset, pxx_req,
>                                        !(pxx_req & domain->bits.pxx),
>                                        0, USEC_PER_MSEC);
> -       if (ret) {
> +       if (ret)
>                 dev_err(domain->dev, "failed to command PGC\n");
> +
> +disable_power_control:
> +       if (enable_power_control)
> +               regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
> +                                  GPC_PGC_CTRL_PCR, 0);
> +
> +       if (ret) {
>                 /*
>                  * If we were in a process of enabling a
>                  * domain and failed we might as well disable
> @@ -185,10 +216,7 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
>                 on = !on;
>         }
>
> -       if (enable_power_control)
> -               regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
> -                                  GPC_PGC_CTRL_PCR, 0);
> -
> +disable_clocks:
>         /* Disable reset clocks for all devices in the domain */
>         for (i = 0; i < domain->num_clks; i++)
>                 clk_disable_unprepare(domain->clk[i]);
> --
> 2.25.1
>


From john.garry at huawei.com  Mon Apr 12 18:21:24 2021
From: john.garry at huawei.com (John Garry)
Date: Mon, 12 Apr 2021 18:21:24 +0100
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <9c577f11-46e7-55a0-95e8-6c3376077049@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
 <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
 <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>
 <9c577f11-46e7-55a0-95e8-6c3376077049@huawei.com>
Message-ID: <fb795e51-ce01-e976-ac09-d3f384307623@huawei.com>

On 12/04/2021 14:34, liuqi (BA) wrote:
> 
> Hi John,
> 
> Thanks for reviewing this.
> On 2021/4/9 18:22, John Garry wrote:
>> On 09/04/2021 10:05, Qi Liu wrote:
>>> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
>>> to sample bandwidth, latency, buffer occupation etc.
>>>
>>> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
>>> registered as a PMU in /sys/bus/event_source/devices, so users can
>>> select target PMU, and use filter to do further sets.

side note: it would be good to mention what baseline the series is based 
on in the cover letter

>>>
>>> Filtering options contains:
>>> event??????? - select the event.
>>> subevent???? - select the subevent.
>>> port???????? - select target Root Ports. Information of Root Ports
>>>  ??????????????? are shown under sysfs.
>>> bdf????????? - select requester_id of target EP device.
>>> trig_len???? - set trigger condition for starting event statistics.
>>> trigger_mode - set trigger mode. 0 means starting to statistic when
>>>  ??????????????? bigger than trigger condition, and 1 means smaller.
>>> thr_len????? - set threshold for statistics.
>>> thr_mode???? - set threshold mode. 0 means count when bigger than
>>>  ??????????????? threshold, and 1 means smaller.
>>>
>>> Signed-off-by: Qi Liu <liuqi115 at huawei.com>
>>> ---
>>>  ? MAINTAINERS??????????????????????????????? |??? 6 +
>>>  ? drivers/perf/Kconfig?????????????????????? |??? 2 +
>>>  ? drivers/perf/Makefile????????????????????? |??? 1 +
>>>  ? drivers/perf/pci/Kconfig?????????????????? |?? 16 +
>>>  ? drivers/perf/pci/Makefile????????????????? |??? 2 +
>>>  ? drivers/perf/pci/hisilicon/Makefile??????? |??? 5 +
>>>  ? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1011
>>> ++++++++++++++++++++++++++++
>>>  ? include/linux/cpuhotplug.h???????????????? |??? 1 +
>>>  ? 8 files changed, 1044 insertions(+)
>>>  ? create mode 100644 drivers/perf/pci/Kconfig
>>>  ? create mode 100644 drivers/perf/pci/Makefile
>>>  ? create mode 100644 drivers/perf/pci/hisilicon/Makefile
>>>  ? create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 3353de0..46c7861 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -8023,6 +8023,12 @@ W:??? http://www.hisilicon.com
>>>  ? F:??? Documentation/admin-guide/perf/hisi-pmu.rst
>>>  ? F:??? drivers/perf/hisilicon
>>> +HISILICON PCIE PMU DRIVER
>>> +M:??? Qi Liu <liuqi115 at huawei.com>
>>> +S:??? Maintained
>>> +F:??? Documentation/admin-guide/perf/hisi-pcie-pmu.rst
>>
>> nit: this does not exist yet...
>>
> thanks, I'll move this add-maintainer-part to the second patch.

that's why I advocate the documentation first :)

>>> +F:??? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>> +
>>>  ? HISILICON QM AND ZIP Controller DRIVER
>>>  ? M:??? Zhou Wang <wangzhou1 at hisilicon.com>
>>>  ? L:??? linux-crypto at vger.kernel.org
>>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
>>> index 3075cf1..99d4760 100644
>>> --- a/drivers/perf/Kconfig
>>> +++ b/drivers/perf/Kconfig
>>> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>>>  ? source "drivers/perf/hisilicon/Kconfig"
>>> +source "drivers/perf/pci/Kconfig"
>>> +
>>>  ? endmenu
>>> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
>>> index 5260b11..1208c08 100644
>>> --- a/drivers/perf/Makefile
>>> +++ b/drivers/perf/Makefile
>>> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>>>  ? obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>>>  ? obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>>>  ? obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
>>> +obj-y += pci/
>>> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
>>> new file mode 100644
>>> index 0000000..a119486
>>> --- /dev/null
>>> +++ b/drivers/perf/pci/Kconfig
>>> @@ -0,0 +1,16 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only
>>> +#
>>> +# PCIe Performance Monitor Drivers
>>> +#
>>> +menu "PCIe Performance Monitor"
>>> +
>>> +config HISI_PCIE_PMU
>>> +??? tristate "HiSilicon PCIE PERF PMU"
>>> +??? depends on ARM64 && PCI && HISI_PMU
>>
>> What from HISI_PMU is needed? I couldn't find anything here
> The event_sysfs_show() and format_sysfs_show() function of
> hisi_uncore_pmu.h can be reused in hisi_pcie_pmu.c, So I add path in
> Makefile and include "hisi_uncore_pmu.h".

Right, but it would be nice to be able to build this under COMPILE_TEST. 
CONFIG_HISI_PMU cannot be built under COMPILE_TEST, so nice to not 
depend on it.

So you could put hisi_event_sysfs_show() as a static inline in 
hisi_uncore_pmu.h, so the dependency can be removed

Having said that, there is nothing really hisi specific in those 
functions like hisi_event_sysfs_show().

Can't we just create generic functions here?

hisi_event_sysfs_show() == cci400_pmu_cycle_event_show() == 
xgene_pmu_event_show()

> 
>>
>>> +??? help
>>> +????? Provide support for HiSilicon PCIe performance monitoring unit
>>> (PMU)
>>> +????? RCiEP devices.
>>> +????? Adds the PCIe PMU into perf events system for monitoring latency,
>>> +????? bandwidth etc.
>>> +





>>> +#define HISI_PCIE_CHECK_EVENTS(name, list)???????????? \
>>
>> "check" in a function name is too vague, as it does not imply any
>> side-effect from calling this function.
>>
>> And I think "build" or similar would be good to be included in the macro
>> name.
>>
>>> +??? static inline bool is_##name##_event(u32 idx)????????????????? \
>>
>> why inline?
>>
>>> +
>>> {?????????????????????????????????????????????????????????????????? \
>>> +??????? if ((idx >= list[0] && idx <= list[1]) || idx == list[2])? \
>>> +??????????? return true;??????????????????????????????????????? \
>>> +??????? return false;?????????????????????????????????????????????? \
>>
>> isn't this just:
>> {
>>   ????return (idx >= list[0] && idx <= list[1]) || idx == list[2])
>> }
> 
> thanks, will address in next version.
>>
>>> +??? }
>>> +
>>> +/*
>>> + * The first element of event list is minimum index of TL-layer events
>>> + * and the second element is maximum index. The third element is index
>>> + * of a DL-layer event.
>>> + */
>>> +static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
>>> +static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
>>> +static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
>>> +static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
>>> +
>>> +HISI_PCIE_CHECK_EVENTS(bw, bw_events_list);
>>> +HISI_PCIE_CHECK_EVENTS(latency, latency_events_list);
>>> +HISI_PCIE_CHECK_EVENTS(bus_util, bus_util_events_list);
>>> +HISI_PCIE_CHECK_EVENTS(buf_util, buf_util_events_list);
>>
>> Surely the macro can be fixed such that you need to have:
>> HISI_PCIE_CHECK_EVENTS(buf_util);
>>
> will address in next version.
>>
>>> +
>>> +static ssize_t hisi_pcie_cpumask_show(struct device *dev,
>>> +????????????????????? struct device_attribute *attr, char *buf)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>>> +
>>> +??? return cpumap_print_to_pagebuf(true, buf, &pcie_pmu->cpumask);
>>> +}
>>> +
>>> +static ssize_t hisi_pcie_identifier_show(struct device *dev,
>>> +???????????????????? struct device_attribute *attr,
>>> +???????????????????? char *buf)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>>> +
>>> +??? return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
>>> +}
>>> +
>>> +static ssize_t hisi_pcie_bus_show(struct device *dev,
>>> +????????????????? struct device_attribute *attr, char *buf)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
>>> +
>>> +??? return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
>>> +}
>>> +
>>> +static void hisi_pcie_parse_data(struct hisi_pcie_pmu *pcie_pmu, u32
>>> reg_off,
>>
>> hisi_pcie_parse_data() name is way too vague. I mean, parse what data?
>>
>> is there is some standard format register we use for various data types,
>> then make that clear please
> Seems that we only have lower_32_bits() but do not have lower_16_bits().
> perhaps we could change the function name to hisi_pcie_parse_reg_value()?

ok, so even that name is better.

> 
>>
>>> +?????????????????? u16 *arg0, u16 *arg1)
>>> +{
>>> +??? u32 val = readl(pcie_pmu->base + reg_off);
>>> +
>>> +??? *arg0 = val & 0xffff;
>>> +??? *arg1 = (val & 0xffff0000) >> 16;
>>> +}
>>> +
>>> +static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
>>> +{
>>> +??? return offset + HISI_PCIE_REG_STEP * idx;
>>> +}
>>> +
>>> +static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32
>>> reg_offset,
>>> +?????????????????? u32 idx)
>>> +{
>>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>>> +
>>> +??? return readl(pcie_pmu->base + offset);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32
>>> reg_offset,
>>> +???????????????? u32 idx, u32 val)
>>> +{
>>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>>> +
>>> +??? writel(val, pcie_pmu->base + offset);
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32
>>> reg_offset,
>>> +?????????????????? u32 idx)
>>> +{
>>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>>> +
>>> +??? return readq(pcie_pmu->base + offset);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32
>>> reg_offset,
>>> +???????????????? u32 idx, u64 val)
>>> +{
>>> +??? u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
>>> +
>>> +??? writeq(val, pcie_pmu->base + offset);
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_get_event(struct perf_event *event)
>>
>> that function name is too vague
>>
>>> +{
>>> +??? return FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
>>> +?????????? FIELD_PREP(HISI_PCIE_SUBEVENT_M,
>>> hisi_pcie_get_subevent(event));
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_get_target(struct perf_event *event)
>>
>> same here
>>
>>> +{
>>> +??? u64 port, val;
>>> +
>>> +??? port = hisi_pcie_get_port(event);
>>> +??? if (port) {
>>> +??????? val = FIELD_PREP(HISI_PCIE_TARGET_M, port);
>>> +??? } else {
>>> +??????? val = FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
>>> +??????? val |= HISI_PCIE_TARGET_EN;
>>> +??? }
>>> +
>>> +??? return val;
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_get_trigger(struct perf_event *event)
>>
>> and here
>>
>> what you really seem to be doing is getting the formatted fields for the
>> register
>>
>>
>> Having all these call-once functions seem to make life a bit more
>> difficult...
>>
> Do you mean config all the filters in one function?, will fix it, thanks.

Yes, I would suggest one function

> 
>>> +{
>>> +??? u64 trig_len, val;
>>> +
>>> +??? trig_len = hisi_pcie_get_trig_len(event);
>>> +??? if (!trig_len)
>>> +??????? return 0;
>>> +
>>> +??? val = FIELD_PREP(HISI_PCIE_TRIG_M, trig_len);
>>> +??? val |= FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
>>> +????????????? hisi_pcie_get_trig_mode(event));
>>> +??? val |= HISI_PCIE_TRIG_EN;
>>> +
>>> +??? return val;
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_get_thr(struct perf_event *event)
>>> +{
>>> +??? u64 thr_len, val;
>>> +
>>> +??? thr_len = hisi_pcie_get_thr_len(event);
>>> +??? if (!thr_len)
>>> +??????? return 0;
>>> +
>>> +??? val = FIELD_PREP(HISI_PCIE_THR_M, thr_len);
>>> +??? val |= FIELD_PREP(HISI_PCIE_THR_MODE_M,
>>> hisi_pcie_get_thr_mode(event));
>>> +??? val |= HISI_PCIE_THR_EN;
>>> +
>>> +??? return val;
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_config_filter(struct perf_event *event)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +??? struct hw_perf_event *hwc = &event->hw;
>>> +??? u32 idx = hwc->idx;
>>> +??? u64 val;
>>> +
>>> +??? val = HISI_PCIE_DEFAULT_SET;
>>> +??? val |= hisi_pcie_pmu_get_event(event);
>>> +??? val |= hisi_pcie_pmu_get_target(event);
>>> +??? val |= hisi_pcie_pmu_get_trigger(event);
>>> +??? val |= hisi_pcie_pmu_get_thr(event);
>>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +??? struct hw_perf_event *hwc = &event->hw;
>>> +
>>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
>>> +???????????????? HISI_PCIE_DEFAULT_SET);
>>> +}
>>> +
>>> +static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu,
>>> u16 bdf)
>>> +{
>>> +??? return bdf <= pcie_pmu->bdf_max && bdf >= pcie_pmu->bdf_min;
>>
>> nit: it is standard to have:
>>
>>   ????if (x >= min && x <= max)
>>
>> i.e. have min on the left
>>
>> 2nd nit: it is passed bdf, yet "port" is in the name
>>
> will fix the function, bdf means the BDF of Root Port, I'll use rp_bdf
> in bext version to describe it.

ok

>>
>>> +}
>>> +
>>> +static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu
>>> *pcie_pmu,
>>> +??????????????????????? u32 bdf)
>>> +{
>>> +??? struct pci_dev *root_port, *pdev;
>>> +
>>> +??? pdev =
>>> pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
>>> +?????????????????????? PCI_BUS_NUM(bdf),
>>> +?????????????????????? GET_PCI_DEVFN(bdf));
>>> +??? if (!pdev)
>>> +??????? return false;
>>> +
>>> +??? root_port = pcie_find_root_port(pdev);
>>> +??? if (!root_port)
>>> +??????? return false;
>>> +
>>> +??? pci_dev_put(pdev);
>>> +??? return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
>>> +}
>>> +
>>> +static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
>>> +?????????????????????? struct hisi_pcie_pmu *pcie_pmu)
>>> +{
>>> +??? u32 subev_idx = hisi_pcie_get_subevent(event);
>>> +??? u32 event_idx = hisi_pcie_get_event(event);
>>> +??? u32 requester_id = hisi_pcie_get_bdf(event);
>>> +
>>> +??? if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
>>> +??????? event_idx > HISI_PCIE_EVENT_MAX) {
>>> +??????? pci_err(pcie_pmu->pdev,
>>> +??????????? "Max event index and max subevent index is: %d, %d.\n",
>>> +??????????? HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
>>
>> if this is just going to be fed back to userspace, I don't see why we
>> need a kernel log
>>
>> and the only caller also triggers an error message, which I doubt is needed
>>
> Print out the HISI_PCIE_EVENT_MAX and HISI_PCIE_SUBEVENT_MAX here may be
> more convenient for users to get the right value.
> If you this is redundant I'll remove it. :)

Don't we already tell this to userspace?

>>> +??????? return false;
>>> +??? }
>>> +
>>> +??? if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
>>> +??????? return false;
>>> +
>>> +??? if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
>>> +??????? return false;
>>> +
>>> +??? if (requester_id) {
>>> +??????? if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id)) {
>>> +??????????? pci_err(pcie_pmu->pdev, "Invalid requester id.\n");
>>
>> see previous comments
>>
>>> +??????????? return false;
>>> +??????? }
>>> +??? }
>>> +
>>> +??? return true;
>>> +}
>>> +
>>> +static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
>>> +{
>>> +??? struct perf_event *sibling, *leader = event->group_leader;
>>> +??? int counters = 1;
>>> +
>>> +??? if (!is_software_event(leader)) {
>>> +??????? if (leader->pmu != event->pmu)
>>> +??????????? return false;
>>> +
>>> +??????? if (leader != event)
>>> +??????????? counters++;
>>> +??? }
>>> +
>>> +??? for_each_sibling_event(sibling, event->group_leader) {
>>> +??????? if (is_software_event(sibling))
>>> +??????????? continue;
>>> +
>>> +??????? if (sibling->pmu != event->pmu)
>>> +??????????? return false;
>>> +
>>> +??????? counters++;
>>> +??? }
>>> +
>>> +??? return counters <= HISI_PCIE_MAX_COUNTERS;
>>> +}
>>> +
>>> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +
>>> +??? event->cpu = cpumask_first(&pcie_pmu->cpumask);
>>> +
>>> +??? if (event->attr.type != event->pmu->type)
>>> +??????? return -ENOENT;
>>> +
>>> +??? /* Sampling is not supported. */
>>> +??? if (is_sampling_event(event) || event->attach_state &
>>> PERF_ATTACH_TASK)
>>> +??????? return -EOPNOTSUPP;
>>> +
>>> +??? /* Per-task mode is not supported. */
>>> +??? if (event->cpu < 0)
>>
>> cpumask_first() gives an unsigned int - this can never happen

please fix this!

>>
>>> +??????? return -EINVAL;
>>> +
>>> +??? if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
>>> +??????? pci_err(pcie_pmu->pdev, "Invalid filter!\n");
>>> +??????? return -EINVAL;
>>> +??? }
>>> +
>>> +??? if (!hisi_pcie_pmu_validate_event_group(event))
>>> +??????? return -EINVAL;
>>> +
>>> +??? return 0;
>>> +}
>>> +
>>> +static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 val,



>>> +
>>> +static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
>>> +????????????????????? struct hw_perf_event *hwc)
>>> +{
>>> +??? u32 idx = hwc->idx;
>>> +
>>> +??? hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
>>> +??????????????????? struct hw_perf_event *hwc)
>>> +{
>>> +??? u32 idx = hwc->idx;
>>> +
>>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
>>> +???????????????? HISI_PCIE_RESET_CNT);
>>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
>>> +???????????????? HISI_PCIE_DEFAULT_SET);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_start(struct perf_event *event, int flags)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +??? struct hw_perf_event *hwc = &event->hw;
>>> +??? struct hw_perf_event_extra *hwc_ext;
>>> +??? u64 prev_cnt, prev_cnt_ext;
>>> +
>>> +??? hwc_ext = &hwc->extra_reg;
>>> +??? if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
>>> +??????? return;
>>> +
>>> +??? WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
>>> +??? hwc->state = 0;
>>> +
>>> +??? hisi_pcie_pmu_config_filter(event);
>>> +??? hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
>>> +??? hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
>>> +??? hisi_pcie_pmu_set_period(event);
>>> +
>>> +??? if (flags & PERF_EF_RELOAD) {
>>> +??????? prev_cnt = local64_read(&hwc->prev_count);
>>> +??????? prev_cnt_ext = hwc_ext->config;
>>> +??????? hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
>>> +??? }
>>> +
>>> +??? perf_event_update_userpage(event);
>>> +}
>>> +
>>> +static void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +??? struct hw_perf_event *hwc = &event->hw;
>>> +
>>> +??? hisi_pcie_pmu_read(event);
>>
>> why do this - it just reads a register? and so why not check the return
>> value?
>>
> hisi_pcie_pmu_read() is a void function, perhaps I should use
> hisi_pcie_pmu_update_counter().

I am not sure what your intention is with calling hisi_pcie_pmu_read(), 
so cannot advise

>>> +??? hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
>>> +??? hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
>>> +??? hisi_pcie_pmu_clear_filter(event);
>>> +??? WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
>>> +??? hwc->state |= PERF_HES_STOPPED;
>>> +
>>> +??? if (hwc->state & PERF_HES_UPTODATE)
>>> +??????? return;
>>> +
>>> +??? hwc->state |= PERF_HES_UPTODATE;
>>> +}
>>> +
>>> +static int hisi_pcie_pmu_add(struct perf_event *event, int flags)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>> +??? struct hw_perf_event *hwc = &event->hw;
>>> +??? int idx;
>>> +
>>> +??? hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
>>> +??? idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
>>> +??? if (idx < 0)
>>> +??????? return idx;
>>> +
>>> +??? hwc->idx = idx;
>>> +??? pcie_pmu->hw_events[idx] = event;
>>> +
>>> +??? /* Reset PMC to avoid interference caused by previous statistic. */



>>> +
>>> +static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
>>> +???????????????????? struct hisi_pcie_pmu *pcie_pmu)
>>> +{
>>> +??? free_irq(pcie_pmu->irq, pcie_pmu);
>>> +??? pci_free_irq_vectors(pdev);
>>> +}
>>> +
>>> +static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct
>>> hlist_node *node)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>>> +???????????????????? struct hisi_pcie_pmu, node);
>>> +
>>> +??? if (cpumask_empty(&pcie_pmu->cpumask)) {
>>> +??????? cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
>>> +??????? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
>>> +??? }
>>> +
>>> +??? return 0;
>>> +}
>>> +
>>> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct
>>> hlist_node *node)
>>> +{
>>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>>> +???????????????????? struct hisi_pcie_pmu, node);
>>> +??? unsigned int target;
>>> +
>>> +??? if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))
>>
>> I do wonder why we even need maintain pcie_pmu->cpumask
>>
>> Can't we just use cpu_online_mask as appropiate instead?

?

>>
>>> +??????? return 0;
>>> +
>>> +??? /* Choose a new CPU from all online cpus. */
>>> +??? target = cpumask_any_but(cpu_online_mask, cpu);
>>> +??? if (target >= nr_cpu_ids)
>>> +??????? return 0;
>>> +
>>> +??? perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
>>> +??? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
>>> +
>>> +??? return 0;
>>> +}
>>> +


From mathieu.poirier at linaro.org  Mon Apr 12 18:30:03 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 12 Apr 2021 11:30:03 -0600
Subject: [PATCH v6 09/10] coresight: syscfg: Add initial configfs support
In-Reply-To: <20210409103722.26290-10-mike.leach@linaro.org>
References: <20210409103722.26290-1-mike.leach@linaro.org>
 <20210409103722.26290-10-mike.leach@linaro.org>
Message-ID: <20210412173003.GA582195@xps15>

On Fri, Apr 09, 2021 at 11:37:21AM +0100, Mike Leach wrote:
> Adds configfs subsystem and attributes to the configuration manager
> to enable the listing of loaded configurations and features.
> 
> The default values of feature parameters can be accessed and altered
> from these attributes to affect all installed devices using the feature.
> 
> Signed-off-by: Mike Leach <mike.leach at linaro.org>
> ---
>  drivers/hwtracing/coresight/Makefile          |   3 +-
>  .../coresight/coresight-syscfg-configfs.c     | 396 ++++++++++++++++++
>  .../coresight/coresight-syscfg-configfs.h     |  45 ++
>  .../hwtracing/coresight/coresight-syscfg.c    |  76 ++++
>  .../hwtracing/coresight/coresight-syscfg.h    |   7 +
>  5 files changed, 526 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
>

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
 
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index ad44f0fe3069..b6c4a48140ec 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -5,7 +5,8 @@
>  obj-$(CONFIG_CORESIGHT) += coresight.o
>  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
>  		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
> -		coresight-cfg-preload.o coresight-cfg-afdo.o
> +		coresight-cfg-preload.o coresight-cfg-afdo.o \
> +		coresight-syscfg-configfs.o
>  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
>  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
>  		      coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> new file mode 100644
> index 000000000000..c547816b9000
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
> @@ -0,0 +1,396 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Linaro Limited, All rights reserved.
> + * Author: Mike Leach <mike.leach at linaro.org>
> + */
> +
> +#include <linux/configfs.h>
> +
> +#include "coresight-syscfg-configfs.h"
> +
> +/* create a default ci_type. */
> +static inline struct config_item_type *cscfg_create_ci_type(void)
> +{
> +	struct config_item_type *ci_type;
> +
> +	ci_type = devm_kzalloc(cscfg_device(), sizeof(*ci_type), GFP_KERNEL);
> +	if (ci_type)
> +		ci_type->ct_owner = THIS_MODULE;
> +
> +	return ci_type;
> +}
> +
> +/* configurations sub-group */
> +
> +/* attributes for the config view group */
> +static ssize_t cscfg_cfg_description_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> +							 struct cscfg_fs_config, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%s", fs_config->config_desc->description);
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, description);
> +
> +static ssize_t cscfg_cfg_feature_refs_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
> +							 struct cscfg_fs_config, group);
> +	const struct cscfg_config_desc *config_desc = fs_config->config_desc;
> +	ssize_t ch_used = 0;
> +	int i;
> +
> +	for (i = 0; i < config_desc->nr_feat_refs; i++)
> +		ch_used += scnprintf(page + ch_used, PAGE_SIZE - ch_used,
> +				     "%s\n", config_desc->feat_ref_names[i]);
> +	return ch_used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, feature_refs);
> +
> +/* list preset values in order of features and params */
> +static ssize_t cscfg_cfg_values_show(struct config_item *item, char *page)
> +{
> +	const struct cscfg_feature_desc *feat_desc;
> +	const struct cscfg_config_desc *config_desc;
> +	struct cscfg_fs_preset *fs_preset;
> +	int i, j, val_idx, preset_idx;
> +	ssize_t used = 0;
> +
> +	fs_preset = container_of(to_config_group(item), struct cscfg_fs_preset, group);
> +	config_desc = fs_preset->config_desc;
> +
> +	if (!config_desc->nr_presets)
> +		return 0;
> +
> +	preset_idx = fs_preset->preset_num - 1;
> +
> +	/* start index on the correct array line */
> +	val_idx = config_desc->nr_total_params * preset_idx;
> +
> +	/*
> +	 * A set of presets is the sum of all params in used features,
> +	 * in order of declaration of features and params in the features
> +	 */
> +	for (i = 0; i < config_desc->nr_feat_refs; i++) {
> +		feat_desc = cscfg_get_named_feat_desc(config_desc->feat_ref_names[i]);
> +		for (j = 0; j < feat_desc->nr_params; j++) {
> +			used += scnprintf(page + used, PAGE_SIZE - used,
> +					  "%s.%s = 0x%llx ",
> +					  feat_desc->name,
> +					  feat_desc->params_desc[j].name,
> +					  config_desc->presets[val_idx++]);
> +		}
> +	}
> +	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> +
> +	return used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_cfg_, values);
> +
> +static struct configfs_attribute *cscfg_config_view_attrs[] = {
> +	&cscfg_cfg_attr_description,
> +	&cscfg_cfg_attr_feature_refs,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_config_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_config_view_attrs,
> +};
> +
> +static struct configfs_attribute *cscfg_config_preset_attrs[] = {
> +	&cscfg_cfg_attr_values,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_config_preset_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_config_preset_attrs,
> +};
> +
> +static int cscfg_add_preset_groups(struct cscfg_fs_config *cfg_view)
> +{
> +	int preset_num;
> +	struct cscfg_fs_preset *cfg_fs_preset;
> +	struct cscfg_config_desc *config_desc = cfg_view->config_desc;
> +	char name[CONFIGFS_ITEM_NAME_LEN];
> +
> +	if (!config_desc->nr_presets)
> +		return 0;
> +
> +	for (preset_num = 1; preset_num <= config_desc->nr_presets; preset_num++) {
> +		cfg_fs_preset = devm_kzalloc(cscfg_device(),
> +					     sizeof(struct cscfg_fs_preset), GFP_KERNEL);
> +
> +		if (!cfg_fs_preset)
> +			return -ENOMEM;
> +
> +		snprintf(name, CONFIGFS_ITEM_NAME_LEN, "preset%d", preset_num);
> +		cfg_fs_preset->preset_num = preset_num;
> +		cfg_fs_preset->config_desc = cfg_view->config_desc;
> +		config_group_init_type_name(&cfg_fs_preset->group, name,
> +					    &cscfg_config_preset_type);
> +		configfs_add_default_group(&cfg_fs_preset->group, &cfg_view->group);
> +	}
> +	return 0;
> +}
> +
> +static struct config_group *cscfg_create_config_group(struct cscfg_config_desc *config_desc)
> +{
> +	struct cscfg_fs_config *cfg_view;
> +	struct device *dev = cscfg_device();
> +	int err;
> +
> +	if (!dev)
> +		return ERR_PTR(-EINVAL);
> +
> +	cfg_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_config), GFP_KERNEL);
> +	if (!cfg_view)
> +		return ERR_PTR(-ENOMEM);
> +
> +	cfg_view->config_desc = config_desc;
> +	config_group_init_type_name(&cfg_view->group, config_desc->name, &cscfg_config_view_type);
> +
> +	/* add in a preset<n> dir for each preset */
> +	err = cscfg_add_preset_groups(cfg_view);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	return &cfg_view->group;
> +}
> +
> +/* attributes for features view */
> +
> +static ssize_t cscfg_feat_description_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%s", fs_feat->feat_desc->description);
> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, description);
> +
> +static ssize_t cscfg_feat_matches_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +	u32 match_flags = fs_feat->feat_desc->match_flags;
> +	int used = 0;
> +
> +	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL)
> +		used = scnprintf(page, PAGE_SIZE, "SRC_ALL ");
> +
> +	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4)
> +		used += scnprintf(page + used, PAGE_SIZE - used, "SRC_ETMV4 ");
> +
> +	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
> +	return used;
> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, matches);
> +
> +static ssize_t cscfg_feat_nr_params_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
> +							struct cscfg_fs_feature, group);
> +
> +	return scnprintf(page, PAGE_SIZE, "%d\n", fs_feat->feat_desc->nr_params);
> +}
> +CONFIGFS_ATTR_RO(cscfg_feat_, nr_params);
> +
> +/* base feature desc attrib structures */
> +static struct configfs_attribute *cscfg_feature_view_attrs[] = {
> +	&cscfg_feat_attr_description,
> +	&cscfg_feat_attr_matches,
> +	&cscfg_feat_attr_nr_params,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_feature_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_feature_view_attrs,
> +};
> +
> +static ssize_t cscfg_param_value_show(struct config_item *item, char *page)
> +{
> +	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> +							 struct cscfg_fs_param, group);
> +	u64 value = param_item->feat_desc->params_desc[param_item->param_idx].value;
> +
> +	return scnprintf(page, PAGE_SIZE, "0x%llx\n", value);
> +}
> +
> +static ssize_t cscfg_param_value_store(struct config_item *item,
> +				       const char *page, size_t size)
> +{
> +	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
> +							 struct cscfg_fs_param, group);
> +	struct cscfg_feature_desc *feat_desc = param_item->feat_desc;
> +	int param_idx = param_item->param_idx;
> +	u64 value;
> +	int err;
> +
> +	err = kstrtoull(page, 0, &value);
> +	if (!err)
> +		err = cscfg_update_feat_param_val(feat_desc, param_idx, value);
> +
> +	return err ? err : size;
> +}
> +CONFIGFS_ATTR(cscfg_param_, value);
> +
> +static struct configfs_attribute *cscfg_param_view_attrs[] = {
> +	&cscfg_param_attr_value,
> +	NULL,
> +};
> +
> +static struct config_item_type cscfg_param_view_type = {
> +	.ct_owner = THIS_MODULE,
> +	.ct_attrs = cscfg_param_view_attrs,
> +};
> +
> +/*
> + * configfs has far less functionality provided to add attributes dynamically than sysfs,
> + * and the show and store fns pass the enclosing config_item so the actual attribute cannot
> + * be determined. Therefore we add each item as a group directory, with a value attribute.
> + */
> +static int cscfg_create_params_group_items(struct cscfg_feature_desc *feat_desc,
> +					   struct config_group *params_group)
> +{
> +	struct device *dev = cscfg_device();
> +	struct cscfg_fs_param *param_item;
> +	int i;
> +
> +	/* parameter items - as groups with default_value attribute */
> +	for (i = 0; i < feat_desc->nr_params; i++) {
> +		param_item = devm_kzalloc(dev, sizeof(struct cscfg_fs_param), GFP_KERNEL);
> +		if (!param_item)
> +			return -ENOMEM;
> +		param_item->feat_desc = feat_desc;
> +		param_item->param_idx = i;
> +		config_group_init_type_name(&param_item->group,
> +					    feat_desc->params_desc[i].name,
> +					    &cscfg_param_view_type);
> +		configfs_add_default_group(&param_item->group, params_group);
> +	}
> +	return 0;
> +}
> +
> +static struct config_group *cscfg_create_feature_group(struct cscfg_feature_desc *feat_desc)
> +{
> +	struct cscfg_fs_feature *feat_view;
> +	struct config_item_type *params_group_type;
> +	struct config_group *params_group = NULL;
> +	struct device *dev = cscfg_device();
> +	int item_err;
> +
> +	if (!dev)
> +		return ERR_PTR(-EINVAL);
> +
> +	feat_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_feature), GFP_KERNEL);
> +	if (!feat_view)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (feat_desc->nr_params) {
> +		params_group = devm_kzalloc(dev, sizeof(struct config_group), GFP_KERNEL);
> +		if (!params_group)
> +			return ERR_PTR(-ENOMEM);
> +
> +		params_group_type = cscfg_create_ci_type();
> +		if (!params_group_type)
> +			return ERR_PTR(-ENOMEM);
> +	}
> +
> +	feat_view->feat_desc = feat_desc;
> +	config_group_init_type_name(&feat_view->group,
> +				    feat_desc->name,
> +				    &cscfg_feature_view_type);
> +	if (params_group) {
> +		config_group_init_type_name(params_group, "params", params_group_type);
> +		configfs_add_default_group(params_group, &feat_view->group);
> +		item_err = cscfg_create_params_group_items(feat_desc, params_group);
> +		if (item_err)
> +			return ERR_PTR(item_err);
> +	}
> +	return &feat_view->group;
> +}
> +
> +static struct config_item_type cscfg_configs_type = {
> +	.ct_owner = THIS_MODULE,
> +};
> +
> +static struct config_group cscfg_configs_grp = {
> +	.cg_item = {
> +		.ci_namebuf = "configurations",
> +		.ci_type = &cscfg_configs_type,
> +	},
> +};
> +
> +/* add configuration to configurations group */
> +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc)
> +{
> +	struct config_group *new_group;
> +	int err;
> +
> +	new_group = cscfg_create_config_group(config_desc);
> +	if (IS_ERR(new_group))
> +		return PTR_ERR(new_group);
> +	err =  configfs_register_group(&cscfg_configs_grp, new_group);
> +	return err;
> +}
> +
> +static struct config_item_type cscfg_features_type = {
> +	.ct_owner = THIS_MODULE,
> +};
> +
> +static struct config_group cscfg_features_grp = {
> +	.cg_item = {
> +		.ci_namebuf = "features",
> +		.ci_type = &cscfg_features_type,
> +	},
> +};
> +
> +/* add feature to features group */
> +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc)
> +{
> +	struct config_group *new_group;
> +	int err;
> +
> +	new_group = cscfg_create_feature_group(feat_desc);
> +	if (IS_ERR(new_group))
> +		return PTR_ERR(new_group);
> +	err =  configfs_register_group(&cscfg_features_grp, new_group);
> +	return err;
> +}
> +
> +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr)
> +{
> +	struct configfs_subsystem *subsys;
> +	struct config_item_type *ci_type;
> +
> +	if (!cscfg_mgr)
> +		return -EINVAL;
> +
> +	ci_type = cscfg_create_ci_type();
> +	if (!ci_type)
> +		return -ENOMEM;
> +
> +	subsys = &cscfg_mgr->cfgfs_subsys;
> +	config_item_set_name(&subsys->su_group.cg_item, CSCFG_FS_SUBSYS_NAME);
> +	subsys->su_group.cg_item.ci_type = ci_type;
> +
> +	config_group_init(&subsys->su_group);
> +	mutex_init(&subsys->su_mutex);
> +
> +	/* Add default groups to subsystem */
> +	config_group_init(&cscfg_configs_grp);
> +	configfs_add_default_group(&cscfg_configs_grp, &subsys->su_group);
> +
> +	config_group_init(&cscfg_features_grp);
> +	configfs_add_default_group(&cscfg_features_grp, &subsys->su_group);
> +
> +	return configfs_register_subsystem(subsys);
> +}
> +
> +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr)
> +{
> +	configfs_unregister_subsystem(&cscfg_mgr->cfgfs_subsys);
> +}
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.h b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> new file mode 100644
> index 000000000000..7d6ffe35ca4c
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Coresight system configuration driver - support for configfs.
> + */
> +
> +#ifndef CORESIGHT_SYSCFG_CONFIGFS_H
> +#define CORESIGHT_SYSCFG_CONFIGFS_H
> +
> +#include <linux/configfs.h>
> +#include "coresight-syscfg.h"
> +
> +#define CSCFG_FS_SUBSYS_NAME "cs-syscfg"
> +
> +/* container for configuration view */
> +struct cscfg_fs_config {
> +	struct cscfg_config_desc *config_desc;
> +	struct config_group group;
> +};
> +
> +/* container for feature view */
> +struct cscfg_fs_feature {
> +	struct cscfg_feature_desc *feat_desc;
> +	struct config_group group;
> +};
> +
> +/* container for parameter view */
> +struct cscfg_fs_param {
> +	int param_idx;
> +	struct cscfg_feature_desc *feat_desc;
> +	struct config_group group;
> +};
> +
> +/* container for preset view */
> +struct cscfg_fs_preset {
> +	int preset_num;
> +	struct cscfg_config_desc *config_desc;
> +	struct config_group group;
> +};
> +
> +int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr);
> +void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr);
> +int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc);
> +int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc);
> +
> +#endif /* CORESIGHT_SYSCFG_CONFIGFS_H */
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
> index 41f742190639..180202402eb5 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> @@ -9,6 +9,7 @@
>  #include "coresight-config.h"
>  #include "coresight-etm-perf.h"
>  #include "coresight-syscfg.h"
> +#include "coresight-syscfg-configfs.h"
>  
>  /*
>   * cscfg_ API manages configurations and features for the entire coresight
> @@ -287,6 +288,72 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
>  	return 0;
>  }
>  
> +/* get a feature descriptor by name */
> +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name)
> +{
> +	const struct cscfg_feature_desc *feat_desc = NULL, *feat_desc_item;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	list_for_each_entry(feat_desc_item, &cscfg_mgr->feat_desc_list, item) {
> +		if (strcmp(feat_desc_item->name, name) == 0) {
> +			feat_desc = feat_desc_item;
> +			break;
> +		}
> +	}
> +
> +	mutex_unlock(&cscfg_mutex);
> +	return feat_desc;
> +}
> +
> +/* called with cscfg_mutex held */
> +static struct cscfg_feature_csdev *
> +cscfg_csdev_get_feat_from_desc(struct coresight_device *csdev,
> +			       struct cscfg_feature_desc *feat_desc)
> +{
> +	struct cscfg_feature_csdev *feat_csdev;
> +
> +	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
> +		if (feat_csdev->feat_desc == feat_desc)
> +			return feat_csdev;
> +	}
> +	return NULL;
> +}
> +
> +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> +				int param_idx, u64 value)
> +{
> +	int err = 0;
> +	struct cscfg_feature_csdev *feat_csdev;
> +	struct cscfg_registered_csdev *csdev_item;
> +
> +	mutex_lock(&cscfg_mutex);
> +
> +	/* check if any config active & return busy */
> +	if (atomic_read(&cscfg_mgr->sys_active_cnt)) {
> +		err = -EBUSY;
> +		goto unlock_exit;
> +	}
> +
> +	/* set the value */
> +	if ((param_idx < 0) || (param_idx >= feat_desc->nr_params)) {
> +		err = -EINVAL;
> +		goto unlock_exit;
> +	}
> +	feat_desc->params_desc[param_idx].value = value;
> +
> +	/* update loaded instances.*/
> +	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
> +		feat_csdev = cscfg_csdev_get_feat_from_desc(csdev_item->csdev, feat_desc);
> +		if (feat_csdev)
> +			feat_csdev->params_csdev[param_idx].current_value = value;
> +	}
> +
> +unlock_exit:
> +	mutex_unlock(&cscfg_mutex);
> +	return err;
> +}
> +
>  /**
>   * cscfg_load_config_sets - API function to load feature and config sets.
>   *
> @@ -308,6 +375,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
>  	if (feat_descs) {
>  		while (feat_descs[i]) {
>  			err = cscfg_load_feat(feat_descs[i]);
> +			if (!err)
> +				err = cscfg_configfs_add_feature(feat_descs[i]);
>  			if (err) {
>  				pr_err("coresight-syscfg: Failed to load feature %s\n",
>  				       feat_descs[i]->name);
> @@ -322,6 +391,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
>  	if (config_descs) {
>  		while (config_descs[i]) {
>  			err = cscfg_load_config(config_descs[i]);
> +			if (!err)
> +				err = cscfg_configfs_add_config(config_descs[i]);
>  			if (err) {
>  				pr_err("coresight-syscfg: Failed to load configuration %s\n",
>  				       config_descs[i]->name);
> @@ -691,6 +762,7 @@ static void cscfg_clear_device(void)
>  	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
>  		etm_perf_del_symlink_cscfg(cfg_desc);
>  	}
> +	cscfg_configfs_release(cscfg_mgr);
>  	device_unregister(cscfg_device());
>  	mutex_unlock(&cscfg_mutex);
>  }
> @@ -704,6 +776,10 @@ int __init cscfg_init(void)
>  	if (err)
>  		return err;
>  
> +	err = cscfg_configfs_init(cscfg_mgr);
> +	if (err)
> +		goto exit_err;
> +
>  	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
>  	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
> index 7bb8c8e497ba..8d018efd6ead 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.h
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.h
> @@ -6,6 +6,7 @@
>  #ifndef CORESIGHT_SYSCFG_H
>  #define CORESIGHT_SYSCFG_H
>  
> +#include <linux/configfs.h>
>  #include <linux/coresight.h>
>  #include <linux/device.h>
>  
> @@ -25,6 +26,7 @@
>   * @feat_desc_list:	List of feature descriptors to load into registered devices.
>   * @config_desc_list:	List of system configuration descriptors to load into registered devices.
>   * @sys_active_cnt:	Total number of active config descriptor references.
> + * @cfgfs_subsys:	configfs subsystem used to manage configurations.
>   */
>  struct cscfg_manager {
>  	struct device dev;
> @@ -32,6 +34,7 @@ struct cscfg_manager {
>  	struct list_head feat_desc_list;
>  	struct list_head config_desc_list;
>  	atomic_t sys_active_cnt;
> +	struct configfs_subsystem cfgfs_subsys;
>  };
>  
>  /* get reference to dev in cscfg_manager */
> @@ -57,6 +60,10 @@ struct cscfg_registered_csdev {
>  int __init cscfg_init(void);
>  void cscfg_exit(void);
>  int cscfg_preload(void);
> +const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name);
> +int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
> +				int param_idx, u64 value);
> +
>  
>  /* syscfg manager external API */
>  int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
> -- 
> 2.17.1
> 


From broonie at kernel.org  Mon Apr 12 18:23:20 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 18:23:20 +0100
Subject: [PATCH] arm64/sve: Remove redundant system_supports_sve() tests
Message-ID: <20210412172320.3315-1-broonie@kernel.org>

Currently there are a number of places in the SVE code where we check both
system_supports_sve() and TIF_SVE. This is a bit redundant given that we
should never get into a situation where we have set TIF_SVE without having
SVE support and it is not clear that silently ignoring a mistakenly set
TIF_SVE flag is the most sensible error handling approach. For now let's
just drop the system_supports_sve() checks since this will at least reduce
overhead a little.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kernel/fpsimd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 062b21f30f94..734d9ea37ecf 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -285,7 +285,7 @@ static void task_fpsimd_load(void)
 	WARN_ON(!system_supports_fpsimd());
 	WARN_ON(!have_cpu_fpsimd_context());
 
-	if (system_supports_sve() && test_thread_flag(TIF_SVE))
+	if (test_thread_flag(TIF_SVE))
 		sve_load_state(sve_pffr(&current->thread),
 			       &current->thread.uw.fpsimd_state.fpsr,
 			       sve_vq_from_vl(current->thread.sve_vl) - 1);
@@ -307,7 +307,7 @@ static void fpsimd_save(void)
 	WARN_ON(!have_cpu_fpsimd_context());
 
 	if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
-		if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
+		if (test_thread_flag(TIF_SVE)) {
 			if (WARN_ON(sve_get_vl() != last->sve_vl)) {
 				/*
 				 * Can't save the user regs, so current would
@@ -1092,7 +1092,7 @@ void fpsimd_preserve_current_state(void)
 void fpsimd_signal_preserve_current_state(void)
 {
 	fpsimd_preserve_current_state();
-	if (system_supports_sve() && test_thread_flag(TIF_SVE))
+	if (test_thread_flag(TIF_SVE))
 		sve_to_fpsimd(current);
 }
 
@@ -1181,7 +1181,7 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
 	get_cpu_fpsimd_context();
 
 	current->thread.uw.fpsimd_state = *state;
-	if (system_supports_sve() && test_thread_flag(TIF_SVE))
+	if (test_thread_flag(TIF_SVE))
 		fpsimd_to_sve(current);
 
 	task_fpsimd_load();
-- 
2.20.1



From broonie at kernel.org  Mon Apr 12 18:36:17 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 18:36:17 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210409213741.kqmwyajoppuqrkge@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
Message-ID: <20210412173617.GE5379@sirena.org.uk>

On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:

> > Further, I believe all the special cases are assembly functions, and
> > most of those are already in special sections to begin with. I reckon
> > it'd be simpler and more robust to reject unwinding based on the
> > section. If we need to unwind across specific functions in those
> > sections, we could opt-in with some metadata. So e.g. we could reject
> > all functions in ".entry.text", special casing the EL0 entry functions
> > if necessary.

> Couldn't this also end up being somewhat fragile?  Saying "certain
> sections are deemed unreliable" isn't necessarily obvious to somebody
> who doesn't already know about it, and it could be overlooked or
> forgotten over time.  And there's no way to enforce it stays that way.

Anything in this area is going to have some opportunity for fragility
and missed assumptions somewhere.  I do find the idea of using the
SYM_CODE annotations that we already have and use for other purposes to
flag code that we don't expect to be suitable for reliable unwinding
appealing from that point of view.  It's pretty clear at the points
where they're used that they're needed, even with a pretty surface level
review, and the bit actually pushing things into a section is going to
be in a single place where the macro is defined.  That seems relatively
robust as these things go, it seems no worse than our reliance on
SYM_FUNC to create BTI annotations.  Missing those causes oopses when we
try to branch to the function.
-------------- 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/20210412/9defad7e/attachment.sig>

From catalin.marinas at arm.com  Mon Apr 12 18:43:44 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 12 Apr 2021 18:43:44 +0100
Subject: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in
 traps for setting si_code
In-Reply-To: <20210407150940.542103-1-Liam.Howlett@Oracle.com>
References: <20210407150940.542103-1-Liam.Howlett@Oracle.com>
Message-ID: <20210412174343.GG2060@arm.com>

On Wed, Apr 07, 2021 at 03:11:06PM +0000, Liam Howlett wrote:
> find_vma() will continue to search upwards until the end of the virtual
> memory space.  This means the si_code would almost never be set to
> SEGV_MAPERR even when the address falls outside of any VMA.  The result
> is that the si_code is not reliable as it may or may not be set to the
> correct result, depending on where the address falls in the address
> space.
> 
> Using find_vma_intersection() allows for what is intended by only
> returning a VMA if it falls within the range provided, in this case a
> window of 1.
> 
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
>  arch/arm64/kernel/traps.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index a05d34f0e82a..a44007904a64 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
>  void arm64_notify_segfault(unsigned long addr)
>  {
>  	int code;
> +	unsigned long ut_addr = untagged_addr(addr);
>  
>  	mmap_read_lock(current->mm);
> -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
>  		code = SEGV_MAPERR;
>  	else
>  		code = SEGV_ACCERR;

I don't think your change is entirely correct either. We can have a
fault below the vma of a stack (with VM_GROWSDOWN) and
find_vma_intersection() would return NULL but it should be a SEGV_ACCERR
instead.

Maybe this should employ similar checks as __do_page_fault() (with
expand_stack() and VM_GROWSDOWN).

-- 
Catalin


From jernej.skrabec at siol.net  Mon Apr 12 18:51:35 2021
From: jernej.skrabec at siol.net (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Mon, 12 Apr 2021 19:51:35 +0200
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card
 CD GPIO for Pine64-LTS
In-Reply-To: <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
 <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
Message-ID: <2453001.GT6EyWp2Io@kista>

Dne ponedeljek, 12. april 2021 ob 19:41:25 CEST je Michael Weiser napisal(a):
> Hi Andre, ChenYu,
> 
> On Mon, Apr 12, 2021 at 05:45:58PM +0100, Andre Przywara wrote:
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > index e79ce49e7e6a..843338e19694 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > @@ -21,5 +21,5 @@
> > > >  };
> > > >
> > > >  &mmc0 {
> > > > -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch 
*/
> > > > +       non-removable;          /* card detect is broken on some 
boards */  
> > > 
> > > So a revert is good, but has anyone tried using the "broken-cd" instead?
> > Ha, that's a good idea, I totally forgot about this property!
> 
> > > That way, at least on Linux, the mmc core resorts to polling for a card.
> > > At least this way the card is still removable.
> > Yes indeed, I tested it on my "stuck at 1" Pine64-LTS, and it works like
> > a charm!
> 
> > Daniel, Michael, can you test this on your boards? So removing the
> > cd-gpios property, and adding "broken-cd;" instead?
> 
> Yes, it works fine. What flummoxed me at first was that obviously I also
> have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
> after having added and disabled an ACTIVE_HIGH definition in
> sun50i-a64-pine64-lts.dts.
> 
> BTW: My boards have a marking "PINE64-R18-V1_1" and below it
> "2017-08-03" on their upper side. On the back it says on one sticker
> "Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
> "PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
> perhaps?  Is there a way to detect this difference in software and add
> some sort of quirk handler for it?

This is job for bootloader (U-Boot) which can patch DT. Most Allwinner boards 
have no reliable way to be distinguished, except from Olimex. So I would say 
it's not possible.

Best regards,
Jernej





From jbx6244 at gmail.com  Mon Apr 12 18:54:19 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 19:54:19 +0200
Subject: [PATCH v2 2/6] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210412150533.GA3898302@robh.at.kernel.org>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210411131007.21757-2-jbx6244@gmail.com>
 <20210412150533.GA3898302@robh.at.kernel.org>
Message-ID: <ba14a833-10dd-fc70-d6bd-70e8f6811ab3@gmail.com>

Hi,

Sorry, made a little mistake in version 2 with "rockchip,rk3036-pwm",
"rockchip,rk2928-pwm".
Please trash. Will send version 3.
By the change of schema for clocks and clock-names I add
"rockchip,rk3328-pwm" to the "if:", so strictly speaking v1 and (v2) v3
will not be the same.

Johan


On 4/12/21 5:05 PM, Rob Herring wrote:
> On Sun, 11 Apr 2021 15:10:03 +0200, Johan Jonker wrote:
>> The compatible strings below are already in use in the Rockchip
>> dtsi files, but were somehow never added to a document, so add
>>
>> "rockchip,rk3328-pwm"
>>
>> "rockchip,rk3036-pwm", "rockchip,rk2928-pwm"
>>
>> "rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
>> "rockchip,rk3399-pwm", "rockchip,rk3288-pwm"
>>
>> "rockchip,px30-pwm", "rockchip,rk3328-pwm"
>> "rockchip,rk3308-pwm", "rockchip,rk3328-pwm"
>>
>> for pwm nodes to pwm-rockchip.yaml.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---
>> Changed V2:
>>   changed schema for clocks and clock-names
>> ---
>>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
> 
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.
> 



From michael.weiser at gmx.de  Mon Apr 12 18:41:25 2021
From: michael.weiser at gmx.de (Michael Weiser)
Date: Mon, 12 Apr 2021 19:41:25 +0200
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <20210412174558.4ba90cf8@slackpad.fritz.box>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
Message-ID: <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>

Hi Andre, ChenYu,

On Mon, Apr 12, 2021 at 05:45:58PM +0100, Andre Przywara wrote:
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > index e79ce49e7e6a..843338e19694 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > @@ -21,5 +21,5 @@
> > >  };
> > >
> > >  &mmc0 {
> > > -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> > > +       non-removable;          /* card detect is broken on some boards */  
> > 
> > So a revert is good, but has anyone tried using the "broken-cd" instead?
> Ha, that's a good idea, I totally forgot about this property!

> > That way, at least on Linux, the mmc core resorts to polling for a card.
> > At least this way the card is still removable.
> Yes indeed, I tested it on my "stuck at 1" Pine64-LTS, and it works like
> a charm!

> Daniel, Michael, can you test this on your boards? So removing the
> cd-gpios property, and adding "broken-cd;" instead?

Yes, it works fine. What flummoxed me at first was that obviously I also
have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
after having added and disabled an ACTIVE_HIGH definition in
sun50i-a64-pine64-lts.dts.

BTW: My boards have a marking "PINE64-R18-V1_1" and below it
"2017-08-03" on their upper side. On the back it says on one sticker
"Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
"PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
perhaps?  Is there a way to detect this difference in software and add
some sort of quirk handler for it?
-- 
Thanks,
Michael


From willy at infradead.org  Mon Apr 12 19:23:54 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 12 Apr 2021 19:23:54 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210411114307.5087f958@carbon>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
Message-ID: <20210412182354.GN2531743@casper.infradead.org>

On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> Could you explain your intent here?
> I worry about @index.
> 
> As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> (code copy-pasted below signature) which imply that the member @index
> have to be kept intact. In above, I'm unsure @index is untouched.

Well, I tried three different approaches.  Here's the one I hated the least.

From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
Date: Sat, 10 Apr 2021 16:12:06 -0400
Subject: [PATCH] mm: Fix struct page layout on 32-bit systems

32-bit architectures which expect 8-byte alignment for 8-byte integers
and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
page inadvertently expanded in 2019.  When the dma_addr_t was added,
it forced the alignment of the union to 8 bytes, which inserted a 4 byte
gap between 'flags' and the union.

We could fix this by telling the compiler to use a smaller alignment
for the dma_addr, but that seems a little fragile.  Instead, move the
'flags' into the union.  That causes dma_addr to shift into the same
bits as 'mapping', which causes problems with page_mapping() called from
set_page_dirty() in the munmap path.  To avoid this, insert three words
of padding and use the same bits as ->index and ->private, neither of
which have to be cleared on free.

However, page->index is currently used to indicate page_is_pfmemalloc.
Move that information to bit 1 of page->lru (aka compound_head).  This
has the same properties; it will be overwritten by callers who do
not care about pfmemalloc (as opposed to using a bit in page->flags).

Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 include/linux/mm.h       | 12 +++++++-----
 include/linux/mm_types.h | 38 ++++++++++++++++++++++++++------------
 2 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index b58c73e50da0..23cca0eaa9da 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1668,10 +1668,12 @@ struct address_space *page_mapping(struct page *page);
 static inline bool page_is_pfmemalloc(const struct page *page)
 {
 	/*
-	 * Page index cannot be this large so this must be
-	 * a pfmemalloc page.
+	 * This is not a tail page; compound_head of a head page is unused
+	 * at return from the page allocator, and will be overwritten
+	 * by callers who do not care whether the page came from the
+	 * reserves.
 	 */
-	return page->index == -1UL;
+	return page->compound_head & 2;
 }
 
 /*
@@ -1680,12 +1682,12 @@ static inline bool page_is_pfmemalloc(const struct page *page)
  */
 static inline void set_page_pfmemalloc(struct page *page)
 {
-	page->index = -1UL;
+	page->compound_head = 2;
 }
 
 static inline void clear_page_pfmemalloc(struct page *page)
 {
-	page->index = 0;
+	page->compound_head = 0;
 }
 
 /*
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..45c563e9b50e 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -68,16 +68,22 @@ struct mem_cgroup;
 #endif
 
 struct page {
-	unsigned long flags;		/* Atomic flags, some possibly
-					 * updated asynchronously */
 	/*
-	 * Five words (20/40 bytes) are available in this union.
-	 * WARNING: bit 0 of the first word is used for PageTail(). That
-	 * means the other users of this union MUST NOT use the bit to
+	 * This union is six words (24 / 48 bytes) in size.
+	 * The first word is reserved for atomic flags, often updated
+	 * asynchronously.  Use the PageFoo() macros to access it.  Some
+	 * of the flags can be reused for your own purposes, but the
+	 * word as a whole often contains other information and overwriting
+	 * it will cause functions like page_zone() and page_node() to stop
+	 * working correctly.
+	 *
+	 * Bit 0 of the second word is used for PageTail(). That
+	 * means the other users of this union MUST leave the bit zero to
 	 * avoid collision and false-positive PageTail().
 	 */
 	union {
 		struct {	/* Page cache and anonymous pages */
+			unsigned long flags;
 			/**
 			 * @lru: Pageout list, eg. active_list protected by
 			 * lruvec->lru_lock.  Sometimes used as a generic list
@@ -96,13 +102,14 @@ struct page {
 			unsigned long private;
 		};
 		struct {	/* page_pool used by netstack */
-			/**
-			 * @dma_addr: might require a 64-bit value even on
-			 * 32-bit architectures.
-			 */
-			dma_addr_t dma_addr;
+			unsigned long _pp_flags;
+			unsigned long pp_magic;
+			unsigned long xmi;
+			unsigned long _pp_mapping_pad;
+			dma_addr_t dma_addr;	/* might be one or two words */
 		};
 		struct {	/* slab, slob and slub */
+			unsigned long _slab_flags;
 			union {
 				struct list_head slab_list;
 				struct {	/* Partial pages */
@@ -130,6 +137,7 @@ struct page {
 			};
 		};
 		struct {	/* Tail pages of compound page */
+			unsigned long _t1_flags;
 			unsigned long compound_head;	/* Bit zero is set */
 
 			/* First tail page only */
@@ -139,12 +147,14 @@ struct page {
 			unsigned int compound_nr; /* 1 << compound_order */
 		};
 		struct {	/* Second tail page of compound page */
+			unsigned long _t2_flags;
 			unsigned long _compound_pad_1;	/* compound_head */
 			atomic_t hpage_pinned_refcount;
 			/* For both global and memcg */
 			struct list_head deferred_list;
 		};
 		struct {	/* Page table pages */
+			unsigned long _pt_flags;
 			unsigned long _pt_pad_1;	/* compound_head */
 			pgtable_t pmd_huge_pte; /* protected by page->ptl */
 			unsigned long _pt_pad_2;	/* mapping */
@@ -159,6 +169,7 @@ struct page {
 #endif
 		};
 		struct {	/* ZONE_DEVICE pages */
+			unsigned long _zd_flags;
 			/** @pgmap: Points to the hosting device page map. */
 			struct dev_pagemap *pgmap;
 			void *zone_device_data;
@@ -174,8 +185,11 @@ struct page {
 			 */
 		};
 
-		/** @rcu_head: You can use this to free a page by RCU. */
-		struct rcu_head rcu_head;
+		struct {
+			unsigned long _rcu_flags;
+			/** @rcu_head: You can use this to free a page by RCU. */
+			struct rcu_head rcu_head;
+		};
 	};
 
 	union {		/* This union is 4 bytes in size. */
-- 
2.30.2



From robh at kernel.org  Mon Apr 12 19:25:18 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 13:25:18 -0500
Subject: [RFC v2 PATCH 1/7] dt-bindings: dmaengine: xilinx_dma: Add
 xlnx,axistream-connected property
In-Reply-To: <1617990965-35337-2-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-2-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <20210412182518.GA4155576@robh.at.kernel.org>

On Fri, 09 Apr 2021 23:25:59 +0530, Radhey Shyam Pandey wrote:
> Add an optional DMA property 'xlnx,axistream-connected'. This can be
> specified to indicate that DMA is connected to a streaming IP in the
> hardware design and dma driver needs to do some additional handling
> i.e pass metadata and perform streaming IP specific configuration.
> 
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> Changes for v2:
> - Rename xlnx,axieth-connected to xlnx,axistream-connected to
>   make it generic.
> ---
>  Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Apr 12 19:25:29 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 13:25:29 -0500
Subject: [RFC v2 PATCH 2/7] dt-bindings: dmaengine: xilinx_dma: Add
 xlnx,irq-delay property
In-Reply-To: <1617990965-35337-3-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-3-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <20210412182529.GA4155955@robh.at.kernel.org>

On Fri, 09 Apr 2021 23:26:00 +0530, Radhey Shyam Pandey wrote:
> Add an optional AXI DMA property 'xlnx,irq-delay'. It specifies interrupt
> timeout value and causes the DMA engine to generate an interrupt after the
> delay time period has expired. Timer begins counting at the end of a packet
> and resets with receipt of a new packet or a timeout event occurs.
> 
> This property is useful when AXI DMA is connected to the streaming IP i.e
> axiethernet where inter packet latency is critical while still taking the
> benefit of interrupt coalescing.
> 
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> Changes for v2:
> - New patch. Introduce xlnx,irq-delay property for low latency usecases
> ---
>  Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Apr 12 19:30:28 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 13:30:28 -0500
Subject: [RFC PATCH 2/3] dt-bindings: net: xilinx_axienet: Introduce
 dmaengine binding support
In-Reply-To: <1617992002-38028-3-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617992002-38028-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617992002-38028-3-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <20210412183028.GA4156095@robh.at.kernel.org>

On Fri, Apr 09, 2021 at 11:43:21PM +0530, Radhey Shyam Pandey wrote:
> The axiethernet driver will now use dmaengine framework to communicate
> with dma controller IP instead of built-in dma programming sequence.
> 
> To request dma transmit and receive channels the axiethernet driver uses
> generic dmas, dma-names properties. It deprecates axistream-connected

Huh, you just added the property and now deprecating?

> property, remove axidma reg and interrupt properties from the ethernet
> node. Just to highlight that these DT changes are not backward compatible
> due to major driver restructuring/cleanup done in adopting the dmaengine
> framework.

Aren't users going to care this isn't a backwards compatible change?

> 
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
>  .../devicetree/bindings/net/xilinx_axienet.yaml    | 40 +++++++++++++---------
>  1 file changed, 24 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
> index 6a00e03e8804..0ea3972fefef 100644
> --- a/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
> +++ b/Documentation/devicetree/bindings/net/xilinx_axienet.yaml
> @@ -14,10 +14,8 @@ description: |
>    offloading TX/RX checksum calculation off the processor.
>  
>    Management configuration is done through the AXI interface, while payload is
> -  sent and received through means of an AXI DMA controller. This driver
> -  includes the DMA driver code, so this driver is incompatible with AXI DMA
> -  driver.
> -
> +  sent and received through means of an AXI DMA controller using dmaengine
> +  framework.
>  
>  allOf:
>    - $ref: "ethernet-controller.yaml#"
> @@ -36,19 +34,13 @@ properties:
>  
>    reg:
>      description:
> -      Address and length of the IO space, as well as the address
> -      and length of the AXI DMA controller IO space, unless
> -      axistream-connected is specified, in which case the reg
> -      attribute of the node referenced by it is used.
> -    maxItems: 2
> +      Address and length of the IO space.
> +    maxItems: 1
>  
>    interrupts:
>      description:
> -      Can point to at most 3 interrupts. TX DMA, RX DMA, and optionally Ethernet
> -      core. If axistream-connected is specified, the TX/RX DMA interrupts should
> -      be on that node instead, and only the Ethernet core interrupt is optionally
> -      specified here.
> -    maxItems: 3
> +      Ethernet core interrupt.
> +    maxItems: 1
>  
>    phy-handle: true
>  
> @@ -109,15 +101,29 @@ properties:
>        for the AXI DMA controller used by this device. If this is specified,
>        the DMA-related resources from that device (DMA registers and DMA
>        TX/RX interrupts) rather than this one will be used.
> +    deprecated: true
>  
>    mdio: true
>  
> +  dmas:
> +    items:
> +      - description: TX DMA Channel phandle and DMA request line number
> +      - description: RX DMA Channel phandle and DMA request line number
> +
> +  dma-names:
> +    items:
> +      - const: tx_chan0
> +      - const: rx_chan0
> +
> +
>  required:
>    - compatible
>    - reg
>    - interrupts
>    - xlnx,rxmem
>    - phy-handle
> +  - dmas
> +  - dma-names
>  
>  additionalProperties: false
>  
> @@ -127,11 +133,13 @@ examples:
>        compatible = "xlnx,axi-ethernet-1.00.a";
>        device_type = "network";
>        interrupt-parent = <&microblaze_0_axi_intc>;
> -      interrupts = <2>, <0>, <1>;
> +      interrupts = <1>;
>        clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
>        clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
>        phy-mode = "mii";
> -      reg = <0x40c00000 0x40000>,<0x50c00000 0x40000>;
> +      reg = <0x40c00000 0x40000>;
> +      dmas = <&xilinx_dma 0>, <&xilinx_dma 1>;
> +      dma-names = "tx_chan0", "rx_chan0";

Is there a chan1? Typical dma-names are just 'tx' and 'rx'.

>        xlnx,rxcsum = <0x2>;
>        xlnx,rxmem = <0x800>;
>        xlnx,txcsum = <0x2>;
> -- 
> 2.7.4
> 


From marex at denx.de  Mon Apr 12 19:44:17 2021
From: marex at denx.de (Marek Vasut)
Date: Mon, 12 Apr 2021 20:44:17 +0200
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
In-Reply-To: <b81d6a69-713f-eda7-0837-d6e80d691c6a@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <b81d6a69-713f-eda7-0837-d6e80d691c6a@foss.st.com>
Message-ID: <2c410c1b-2a1d-b291-a128-c5d5979be1ef@denx.de>

On 4/12/21 10:09 AM, Alexandre TORGUE wrote:
> Hi Marek

Hello Alex,

[...]

>> All the above still only discusses the clock part of the problem. Even if
>> the clock cyclic dependencies could be solved, it would be necessary to
>> resolve legacy dwmac st,eth-clk-sel and st,eth-ref-clk-sel DT properties
>> and avoid DT ABI break.
> 
> Thanks for those clear explanations and for this series. As discussed, 
> this approach looks good to me as it doesn't break our current strategy 
> for dwmac clock integration. I don't know if those cyclic redundancies 
> will be fixed one day but we can have a look on dwmac DT properties (the 
> gain to change them, the effort to keep the backward compatibility, code 
> readability, ...).
> 
> Your DT patches looks good. I'll merge them soon.
+CC Stephen ; the DT patches depend on the clock driver changes. Would 
it make sense to pick the clock patches through the same tree or how 
should that be handled ?

[...]


From arnd at kernel.org  Mon Apr 12 19:52:37 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 12 Apr 2021 20:52:37 +0200
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <20210412160116.GA904837@yoga>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
 <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>
 <20210412160116.GA904837@yoga>
Message-ID: <CAK8P3a1_YB944niA-ebk-nJx-JDBh1q7z6s-9mLGFjF2Nv9r9w@mail.gmail.com>

On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson
<bjorn.andersson at linaro.org> wrote:
> On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote:
> > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:
>
> So the same binding patch is picked up both in the driver and soc tree?
> I was expecting that to cause (harmless) conflicts when things arrive in
> Linus' merge queue?
>
> Or are you saying people go the length to create immutable branches for
> each binding?

I think it's usually one immutable branch for all the bindings of a given
merge window. This avoids the merge conflicts, and you can add further
bindings on the same branch before sending it off to the soc tree.

> I'm curious because it's fairly often that we introduce clocks,
> interconnects etc where the macros from the dt bindings includes aren't
> available for another release (so we use numerical constants and then go
> back and fix them up later).

Ah right, it is particularly bad for platforms that don't have a regular
layout in these blocks and need to define a new constant every time
another clock/reset/pin/... is discovered in the downstream sources.

I was mainly referring to the simpler problem of defining a binding
document for a device once, and then merging the nodes.

       Arnd


From broonie at kernel.org  Mon Apr 12 20:00:58 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 12 Apr 2021 20:00:58 +0100
Subject: [PATCH -next] spi: spi-zynqmp-gqspi: Fix missing unlock on error
 in zynqmp_qspi_exec_op()
In-Reply-To: <20210412160025.194171-1-weiyongjun1@huawei.com>
References: <20210412160025.194171-1-weiyongjun1@huawei.com>
Message-ID: <161825405874.52313.7242174771524864608.b4-ty@kernel.org>

On Mon, 12 Apr 2021 16:00:25 +0000, Wei Yongjun wrote:
> Add the missing unlock before return from function zynqmp_qspi_exec_op()
> in the error handling case.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: spi-zynqmp-gqspi: Fix missing unlock on error in zynqmp_qspi_exec_op()
      commit: 6043357263fbe2df0bf0736d971ad5dce7d19dc1

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 cki-project at redhat.com  Mon Apr 12 20:19:04 2021
From: cki-project at redhat.com (CKI Project)
Date: Mon, 12 Apr 2021 19:19:04 -0000
Subject: =?utf-8?b?4pyF?= PASS: Test report for kernel 5.12.0-rc7 (arm-next,
 e5ff195b)
Message-ID: <cki.F99F4A01BD.ONPLB93465@redhat.com>


Hello,

We ran automated tests on a recent commit from this kernel tree:

       Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
            Commit: e5ff195bf600 - Merge branch 'for-next/fixes' into for-kernelci

The results of these automated tests are provided below.

    Overall result: PASSED
             Merge: OK
           Compile: OK
             Tests: OK

All kernel binaries, config files, and logs are available for download here:

  https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/04/12/285011008

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
           `-'
______________________________________________________________________________

Compile testing
---------------

We compiled the kernel for 1 architecture:

    aarch64:
      make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg



Hardware testing
----------------
We booted each kernel and ran the following tests:

  aarch64:
    Host 1:
       ? Boot test
       ? ACPI table test
       ? ACPI enabled test
       ? LTP
       ? CIFS Connectathon
       ? POSIX pjd-fstest suites
       ? Loopdev Sanity
       ? jvm - jcstress tests
       ? Memory: fork_mem
       ? Memory function: memfd_create
       ? AMTU (Abstract Machine Test Utility)
       ? Networking bridge: sanity
       ? Ethernet drivers sanity
       ? Networking socket: fuzz
       ? Networking: igmp conformance test
       ? Networking route: pmtu
       ? Networking route_func - local
       ? Networking route_func - forward
       ? Networking TCP: keepalive test
       ? Networking UDP: socket
       ? Networking cki netfilter test
       ? Networking tunnel: geneve basic test
       ? Networking tunnel: gre basic
       ? L2TP basic test
       ? Networking tunnel: vxlan basic
       ? Networking ipsec: basic netns - transport
       ? Networking ipsec: basic netns - tunnel
       ? Libkcapi AF_ALG test
       ? pciutils: update pci ids test
       ? ALSA PCM loopback test
       ? ALSA Control (mixer) Userspace Element test
       ? storage: SCSI VPD
       ? trace: ftrace/tracer
       ? ? i2c: i2cdetect sanity
       ? ? Firmware test suite
       ? ? Memory function: kaslr
       ? ? audit: audit testsuite test

    Host 2:

       ? Internal infrastructure issues prevented one or more tests (marked
       with ???) from running on this architecture.
       This is not the fault of the kernel that was tested.

       ??? Boot test
       ??? xfstests - ext4
       ??? xfstests - xfs
       ??? selinux-policy: serge-testsuite
       ??? storage: software RAID testing
       ??? Storage: swraid mdadm raid_module test
       ? ??? xfstests - btrfs
       ? ??? IPMI driver test
       ? ??? IPMItool loop stress test
       ? ??? Storage blktests
       ? ??? Storage block - filesystem fio test
       ? ??? Storage block - queue scheduler test
       ? ??? Storage nvme - tcp
       ? ??? Storage: lvm device-mapper test
       ? ??? stress: stress-ng

    Host 3:
       ? Boot test
       ? xfstests - ext4
       ? xfstests - xfs
       ? selinux-policy: serge-testsuite
       ? storage: software RAID testing
       ? Storage: swraid mdadm raid_module test
       ? ? xfstests - btrfs
       ? ? IPMI driver test
       ? ? IPMItool loop stress test
       ? ? Storage blktests
       ? ? Storage block - filesystem fio test
       ? ? Storage block - queue scheduler test
       ? ? Storage nvme - tcp
       ? ? Storage: lvm device-mapper test
       ? ? stress: stress-ng

  Test sources: https://gitlab.com/cki-project/kernel-tests
    ? Pull requests are welcome for new tests or improvements to existing tests!

Aborted tests
-------------
Tests that didn't complete running successfully are marked with ???.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.

Waived tests
------------
If the test run included waived tests, they are marked with ?. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.

Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ?.



From madvenka at linux.microsoft.com  Mon Apr 12 20:55:35 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 12 Apr 2021 14:55:35 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210412173617.GE5379@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
Message-ID: <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>



On 4/12/21 12:36 PM, Mark Brown wrote:
> On Fri, Apr 09, 2021 at 04:37:41PM -0500, Josh Poimboeuf wrote:
>> On Fri, Apr 09, 2021 at 01:09:09PM +0100, Mark Rutland wrote:
> 
>>> Further, I believe all the special cases are assembly functions, and
>>> most of those are already in special sections to begin with. I reckon
>>> it'd be simpler and more robust to reject unwinding based on the
>>> section. If we need to unwind across specific functions in those
>>> sections, we could opt-in with some metadata. So e.g. we could reject
>>> all functions in ".entry.text", special casing the EL0 entry functions
>>> if necessary.
> 
>> Couldn't this also end up being somewhat fragile?  Saying "certain
>> sections are deemed unreliable" isn't necessarily obvious to somebody
>> who doesn't already know about it, and it could be overlooked or
>> forgotten over time.  And there's no way to enforce it stays that way.
> 
> Anything in this area is going to have some opportunity for fragility
> and missed assumptions somewhere.  I do find the idea of using the
> SYM_CODE annotations that we already have and use for other purposes to
> flag code that we don't expect to be suitable for reliable unwinding
> appealing from that point of view.  It's pretty clear at the points
> where they're used that they're needed, even with a pretty surface level
> review, and the bit actually pushing things into a section is going to
> be in a single place where the macro is defined.  That seems relatively
> robust as these things go, it seems no worse than our reliance on
> SYM_FUNC to create BTI annotations.  Missing those causes oopses when we
> try to branch to the function.
> 

OK. Just so I am clear on the whole picture, let me state my understanding so far.
Correct me if I am wrong.

1. We are hoping that we can convert a significant number of SYM_CODE functions to
   SYM_FUNC functions by providing them with a proper FP prolog and epilog so that
   we can get objtool coverage for them. These don't need any blacklisting.

2. If we can locate the pt_regs structures created on the stack cleanly for EL1
   exceptions, etc, then we can handle those cases in the unwinder without needing
   any black listing.

   I have a solution for this in version 3 that does it without encoding the FP or
   matching values on the stack. I have addressed all of the objections so far on
   that count. I will send the patch series out soon.

3. We are going to assume that the reliable unwinder is only for livepatch purposes
   and will only be invoked on a task that is not currently running. The task either
   voluntarily gave up the CPU or was pre-empted. We can safely ignore all SYM_CODE
   functions that will never voluntarily give up the CPU. They can only be pre-empted
   and pre-emption is already handled in (2). We don't need to blacklist any of these
   functions.

4. So, the only functions that will need blacklisting are the remaining SYM_CODE functions
   that might give up the CPU voluntarily. At this point, I am not even sure how
   many of these will exist. One hopes that all of these would have ended up as
   SYM_FUNC functions in (1).

So, IMHO, placing code in a black listed section should be the last step and not the first
one. This also satisfies Mark Rutland's requirement that no one muck with the entry text
while he is sorting out that code.

I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the
remaining ones to see which ones must be blacklisted, if any.

Do you agree?

Madhavan


From jbx6244 at gmail.com  Mon Apr 12 21:01:52 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 22:01:52 +0200
Subject: [PATCH v3 1/4] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
Message-ID: <20210412200155.5316-1-jbx6244@gmail.com>

Current dts files with 'pwm' nodes are manually verified.
In order to automate this process pwm-rockchip.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
For some SoC nodes this patch serie generates notifications
for undocumented "interrupts" properties shared between
PWM channels till there is consensus of what to do with it or
someone makes a solution for the whole PWM block.

Changed V3:
  fix mistake with compatibles introduced in V2
Changed V2:
  changed schema for clocks and clock-names
---
 .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
 .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 88 ++++++++++++++++++++++
 2 files changed, 88 insertions(+), 27 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
deleted file mode 100644
index f70956dea..000000000
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Rockchip PWM controller
-
-Required properties:
- - compatible: should be "rockchip,<name>-pwm"
-   "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs
-   "rockchip,rk3288-pwm": found on RK3288 SOC
-   "rockchip,rv1108-pwm", "rockchip,rk3288-pwm": found on RV1108 SoC
-   "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC
- - reg: physical base address and length of the controller's registers
- - clocks: See ../clock/clock-bindings.txt
-   - For older hardware (rk2928, rk3066, rk3188, rk3228, rk3288, rk3399):
-     - There is one clock that's used both to derive the functional clock
-       for the device and as the bus clock.
-   - For newer hardware (rk3328 and future socs): specified by name
-     - "pwm": This is used to derive the functional clock.
-     - "pclk": This is the APB bus clock.
- - #pwm-cells: must be 2 (rk2928) or 3 (rk3288). See pwm.yaml in this directory
-   for a description of the cell format.
-
-Example:
-
-	pwm0: pwm at 20030000 {
-		compatible = "rockchip,rk2928-pwm";
-		reg = <0x20030000 0x10>;
-		clocks = <&cru PCLK_PWM01>;
-		#pwm-cells = <2>;
-	};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
new file mode 100644
index 000000000..19b42d31d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-rockchip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip PWM controller
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    oneOf:
+      - const: rockchip,rk2928-pwm
+      - const: rockchip,rk3288-pwm
+      - const: rockchip,vop-pwm
+      - items:
+          - enum:
+              - rockchip,rv1108-pwm
+          - const: rockchip,rk3288-pwm
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 2
+
+  clock-names:
+    maxItems: 2
+
+  "#pwm-cells":
+    enum: [2, 3]
+    description:
+      Must be 2 (rk2928) or 3 (rk3288 and later).
+      See pwm.yaml for a description of the cell format.
+
+required:
+  - compatible
+  - reg
+  - "#pwm-cells"
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - rockchip,rv1108-pwm
+
+then:
+  properties:
+    clocks:
+      items:
+        - description: Used to derive the functional clock for the device.
+        - description: Used as the APB bus clock.
+
+    clock-names:
+      items:
+        - const: pwm
+        - const: pclk
+
+  required:
+    - clocks
+    - clock-names
+
+else:
+  properties:
+    clocks:
+      maxItems: 1
+      description:
+        Used both to derive the functional clock
+        for the device and as the bus clock.
+
+  required:
+    - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3188-cru-common.h>
+    pwm0: pwm at 20030000 {
+      compatible = "rockchip,rk2928-pwm";
+      reg = <0x20030000 0x10>;
+      clocks = <&cru PCLK_PWM01>;
+      #pwm-cells = <2>;
+    };
-- 
2.11.0



From jbx6244 at gmail.com  Mon Apr 12 21:01:53 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 22:01:53 +0200
Subject: [PATCH v3 2/4] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <20210412200155.5316-2-jbx6244@gmail.com>

The compatible strings below are already in use in the Rockchip
dtsi files, but were somehow never added to a document, so add

"rockchip,rk3328-pwm"

"rockchip,rk3036-pwm", "rockchip,rk2928-pwm"

"rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
"rockchip,rk3399-pwm", "rockchip,rk3288-pwm"

"rockchip,px30-pwm", "rockchip,rk3328-pwm"
"rockchip,rk3308-pwm", "rockchip,rk3328-pwm"

for pwm nodes to pwm-rockchip.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Note for rob+dt:
A tag was not added on purpose, because by the change of schema
for clocks and clock-names I add "rockchip,rk3328-pwm" to
the "if:", so strictly speaking V1 and (V2) V3 will not be the same.
Please have a look at it again.

For some SoC nodes this patch serie generates notifications
for undocumented "interrupts" properties shared between
PWM channels till there is consensus of what to do with it or
someone makes a solution for the whole PWM block.

Changed V3:
  fix mistake with compatibles introduced in V2
Changed V2:
  changed schema for clocks and clock-names
---
 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index 19b42d31d..5596bee70 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -14,11 +14,22 @@ properties:
     oneOf:
       - const: rockchip,rk2928-pwm
       - const: rockchip,rk3288-pwm
+      - const: rockchip,rk3328-pwm
       - const: rockchip,vop-pwm
       - items:
+          - const: rockchip,rk3036-pwm
+          - const: rockchip,rk2928-pwm
+      - items:
           - enum:
+              - rockchip,rk3368-pwm
+              - rockchip,rk3399-pwm
               - rockchip,rv1108-pwm
           - const: rockchip,rk3288-pwm
+      - items:
+          - enum:
+              - rockchip,px30-pwm
+              - rockchip,rk3308-pwm
+          - const: rockchip,rk3328-pwm
 
   reg:
     maxItems: 1
@@ -46,6 +57,7 @@ if:
     compatible:
       contains:
         enum:
+          - rockchip,rk3328-pwm
           - rockchip,rv1108-pwm
 
 then:
-- 
2.11.0



From jbx6244 at gmail.com  Mon Apr 12 21:01:54 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 22:01:54 +0200
Subject: [PATCH v3 3/4] ARM: dts: rockchip: remove clock-names from pwm nodes
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <20210412200155.5316-3-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm/boot/dts/rk3036-evb.dt.yaml:
pwm at 20050030: clock-names: ['pwm'] is too short

Devices with only one pwm clock use it to both
to derive the functional clock for the device
and as the bus clock. The driver does not need
"clock-names" to get a handle, so remove them all.

make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3036.dtsi | 4 ----
 arch/arm/boot/dts/rk3288.dtsi | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 47a787a12..e24230d50 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -355,7 +355,6 @@
 		reg = <0x20050000 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		status = "disabled";
@@ -366,7 +365,6 @@
 		reg = <0x20050010 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		status = "disabled";
@@ -377,7 +375,6 @@
 		reg = <0x20050020 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		status = "disabled";
@@ -388,7 +385,6 @@
 		reg = <0x20050030 0x10>;
 		#pwm-cells = <2>;
 		clocks = <&cru PCLK_PWM>;
-		clock-names = "pwm";
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		status = "disabled";
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ea7416c31..05557ad02 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -679,7 +679,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -690,7 +689,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -701,7 +699,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -712,7 +709,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		clocks = <&cru PCLK_RKPWM>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
-- 
2.11.0



From jbx6244 at gmail.com  Mon Apr 12 21:01:55 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 22:01:55 +0200
Subject: [PATCH v3 4/4] arm64: dts: rockchip: remove clock-names from pwm nodes
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <20210412200155.5316-4-jbx6244@gmail.com>

A test with the command below gives this error:

/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dt.yaml:
pwm at ff680030: clock-names: ['pwm'] is too short

Devices with only one pwm clock use it to both
to derive the functional clock for the device
and as the bus clock. The driver does not need
"clock-names" to get a handle, so remove them all.

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ----
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 61b0a2a90..7832e26a3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -561,7 +561,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -572,7 +571,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -581,7 +579,6 @@
 		reg = <0x0 0xff680020 0x0 0x10>;
 		#pwm-cells = <3>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -592,7 +589,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3_pin>;
 		clocks = <&cru PCLK_PWM1>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e93a5f320..6221b027e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1185,7 +1185,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm0_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1196,7 +1195,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm1_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1207,7 +1205,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm2_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
@@ -1218,7 +1215,6 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pwm3a_pin>;
 		clocks = <&pmucru PCLK_RKPWM_PMU>;
-		clock-names = "pwm";
 		status = "disabled";
 	};
 
-- 
2.11.0



From Daniel.Kiss at arm.com  Mon Apr 12 21:17:05 2021
From: Daniel.Kiss at arm.com (Daniel Kiss)
Date: Mon, 12 Apr 2021 20:17:05 +0000
Subject: [PATCH v3 2/2] arm64: Conditionally configure PTR_AUTH key of the
 kernel.
In-Reply-To: <20210329145137.GE4203@willie-the-truck>
References: <20210208145554.2164638-1-daniel.kiss@arm.com>
 <20210208145554.2164638-3-daniel.kiss@arm.com>
 <20210329145137.GE4203@willie-the-truck>
Message-ID: <04AA56B1-FF63-4DB1-826B-037A7AF03CCD@arm.com>



> On 29 Mar 2021, at 16:51, Will Deacon <will at kernel.org> wrote:
> 
> On Mon, Feb 08, 2021 at 03:55:54PM +0100, Daniel Kiss wrote:
>> If the kernel is not compiled with CONFIG_ARM64_PTR_AUTH_KERNEL=y,
>> then no PACI/AUTI instructions are expected while the kernel is running
>> so the kernel's key will not be used. Write of a system regiters
>> is expensive therefore avoid it not required.
> 
> What happens if somebody tries to load a module built with PAC into a kernel
> where CONFIG_ARM64_PTR_AUTH_KERNEL=n? Do we reject the module?
I think it will be loaded, but actually nothing will happen because then the instruction
will be just NOPs. Other way will work as well.
Enforcement will be trick because module might sneak the compiler flag in that overrides
the kconfig.

> I'm not sure how much we care, but I'm a bit worried that it might not go
> "obviously" wrong.
> 
>> Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
>> ---
>> arch/arm64/include/asm/asm_pointer_auth.h | 63 +++++++++++++----------
>> arch/arm64/include/asm/pointer_auth.h     | 20 +++++--
>> arch/arm64/include/asm/processor.h        |  2 +
>> arch/arm64/kernel/asm-offsets.c           |  2 +
>> 4 files changed, 54 insertions(+), 33 deletions(-)
> 
> [...]
> 
>> diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
>> index c6b4f0603024..b34aebb95757 100644
>> --- a/arch/arm64/include/asm/pointer_auth.h
>> +++ b/arch/arm64/include/asm/pointer_auth.h
>> @@ -30,9 +30,11 @@ struct ptrauth_keys_user {
>> 	struct ptrauth_key apga;
>> };
>> 
>> +#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
>> struct ptrauth_keys_kernel {
>> 	struct ptrauth_key apia;
>> };
>> +#endif
>> 
>> static inline void ptrauth_keys_init_user(struct ptrauth_keys_user *keys)
>> {
>> @@ -54,6 +56,8 @@ do {								\
>> 	write_sysreg_s(__pki_v.hi, SYS_ ## k ## KEYHI_EL1);	\
>> } while (0)
>> 
>> +#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
>> +
>> static __always_inline void ptrauth_keys_init_kernel(struct ptrauth_keys_kernel *keys)
>> {
>> 	if (system_supports_address_auth())
>> @@ -69,6 +73,8 @@ static __always_inline void ptrauth_keys_switch_kernel(struct ptrauth_keys_kerne
>> 	isb();
>> }
>> 
>> +#endif /* CONFIG_ARM64_PTR_AUTH_KERNEL */
> 
> Can you group this with the struct and avoid having two #ifdef blocks?
Sure, I'll send a version.

> 
> Will



From patchwork-bot+netdevbpf at kernel.org  Mon Apr 12 21:20:08 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Mon, 12 Apr 2021 20:20:08 +0000
Subject: [PATCH] net: thunderx: Fix unintentional sign extension issue
In-Reply-To: <20210409130726.665490-1-colin.king@canonical.com>
References: <20210409130726.665490-1-colin.king@canonical.com>
Message-ID: <161825880887.1346.11596655945494608028.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Fri,  9 Apr 2021 14:07:26 +0100 you wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> The shifting of the u8 integers rq->caching by 26 bits to
> the left will be promoted to a 32 bit signed int and then
> sign-extended to a u64. In the event that rq->caching is
> greater than 0x1f then all then all the upper 32 bits of
> the u64 end up as also being set because of the int
> sign-extension. Fix this by casting the u8 values to a
> u64 before the 26 bit left shift.
> 
> [...]

Here is the summary with links:
  - net: thunderx: Fix unintentional sign extension issue
    https://git.kernel.org/netdev/net-next/c/e701a2584036

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From robh at kernel.org  Mon Apr 12 21:57:53 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 15:57:53 -0500
Subject: [PATCH v2 1/6] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210411131007.21757-1-jbx6244@gmail.com>
References: <20210411131007.21757-1-jbx6244@gmail.com>
Message-ID: <20210412205753.GA158321@robh.at.kernel.org>

On Sun, 11 Apr 2021 15:10:02 +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 91 ++++++++++++++++++++++
>  2 files changed, 91 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Apr 12 22:00:05 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 12 Apr 2021 16:00:05 -0500
Subject: [PATCH v1] dt-bindings: gpio: add YAML description for
 rockchip,gpio-bank
In-Reply-To: <20210411175435.807-1-jbx6244@gmail.com>
References: <20210411175435.807-1-jbx6244@gmail.com>
Message-ID: <20210412210005.GA158955@robh.at.kernel.org>

On Sun, Apr 11, 2021 at 07:54:35PM +0200, Johan Jonker wrote:
> Current dts files with "rockchip,gpio-bank" subnodes
> are manually verified. In order to automate this process
> the text that describes the compatible in rockchip,pinctrl.txt
> is removed and converted to YAML in rockchip,gpio-bank.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  .../bindings/gpio/rockchip,gpio-bank.yaml          | 82 ++++++++++++++++++++++
>  .../bindings/pinctrl/rockchip,pinctrl.txt          | 58 +--------------
>  2 files changed, 83 insertions(+), 57 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> 
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> new file mode 100644
> index 000000000..ac2479732
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip GPIO bank
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,gpio-bank
> +      - rockchip,rk3188-gpio-bank0
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  gpio-controller: true
> +
> +  "#gpio-cells":
> +    const: 2
> +
> +  interrupt-controller: true
> +
> +  "#interrupt-cells":
> +    const: 2
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - gpio-controller
> +  - "#gpio-cells"
> +  - interrupt-controller
> +  - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    pinctrl: pinctrl {
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +      ranges;
> +
> +      gpio0: gpio0 at 2000a000 {

gpio at ...

> +        compatible = "rockchip,rk3188-gpio-bank0";
> +        reg = <0x2000a000 0x100>;
> +        interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk_gates8 9>;
> +
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +
> +        interrupt-controller;
> +        #interrupt-cells = <2>;
> +      };
> +
> +      gpio1: gpio1 at 2003c000 {

gpio at ...

> +        compatible = "rockchip,gpio-bank";
> +        reg = <0x2003c000 0x100>;
> +        interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk_gates8 10>;
> +
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +
> +        interrupt-controller;
> +        #interrupt-cells = <2>;
> +      };
> +    };
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> index d3eae61a3..4719a6a07 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -50,23 +50,7 @@ Deprecated properties for iomux controller:
>  	 Use rockchip,grf and rockchip,pmu described above instead.
>  
>  Required properties for gpio sub nodes:
> -  - compatible: "rockchip,gpio-bank"
> -  - reg: register of the gpio bank (different than the iomux registerset)
> -  - interrupts: base interrupt of the gpio bank in the interrupt controller
> -  - clocks: clock that drives this bank
> -  - gpio-controller: identifies the node as a gpio controller and pin bank.
> -  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
> -    binding is used, the amount of cells must be specified as 2. See generic
> -    GPIO binding documentation for description of particular cells.
> -  - interrupt-controller: identifies the controller node as interrupt-parent.
> -  - #interrupt-cells: the value of this property should be 2 and the interrupt
> -    cells should use the standard two-cell scheme described in
> -    bindings/interrupt-controller/interrupts.txt
> -
> -Deprecated properties for gpio sub nodes:
> -  - compatible: "rockchip,rk3188-gpio-bank0"
> -  - reg: second element: separate pull register for rk3188 bank0, use
> -	 rockchip,pmu described above instead
> +See rockchip,gpio-bank.yaml
>  
>  Required properties for pin configuration node:
>    - rockchip,pins: 3 integers array, represents a group of pins mux and config
> @@ -127,43 +111,3 @@ uart2: serial at 20064000 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&uart2_xfer>;
>  };
> -
> -Example for rk3188:
> -
> -	pinctrl at 20008000 {
> -		compatible = "rockchip,rk3188-pinctrl";
> -		rockchip,grf = <&grf>;
> -		rockchip,pmu = <&pmu>;
> -		#address-cells = <1>;
> -		#size-cells = <1>;
> -		ranges;
> -
> -		gpio0: gpio0 at 2000a000 {
> -			compatible = "rockchip,rk3188-gpio-bank0";
> -			reg = <0x2000a000 0x100>;
> -			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&clk_gates8 9>;
> -
> -			gpio-controller;
> -			#gpio-cells = <2>;
> -
> -			interrupt-controller;
> -			#interrupt-cells = <2>;
> -		};
> -
> -		gpio1: gpio1 at 2003c000 {
> -			compatible = "rockchip,gpio-bank";
> -			reg = <0x2003c000 0x100>;
> -			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&clk_gates8 10>;
> -
> -			gpio-controller;
> -			#gpio-cells = <2>;
> -
> -			interrupt-controller;
> -			#interrupt-cells = <2>;
> -		};
> -
> -		...
> -
> -	};
> -- 
> 2.11.0
> 


From davem at davemloft.net  Mon Apr 12 22:19:16 2021
From: davem at davemloft.net (David Miller)
Date: Mon, 12 Apr 2021 14:19:16 -0700 (PDT)
Subject: [PATCH net-next 6/7] net: stmmac: Enable RX via AF_XDP zero-copy
In-Reply-To: <20210412154130.20742-7-boon.leong.ong@intel.com>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
 <20210412154130.20742-7-boon.leong.ong@intel.com>
Message-ID: <20210412.141916.1569200948681549246.davem@davemloft.net>

+	/* synchronize_rcu() needed for pending XDP buffers to drain */
+	for (queue = 0; queue < rx_queues_cnt; queue++) {
+		rx_q = &priv->rx_queue[queue];
+		if (rx_q->xsk_pool) {
+			synchronize_rcu();

Are you sure this is safe here, especially via the ->ndo_setup_tc() code path?

Thank you.


From jbx6244 at gmail.com  Mon Apr 12 22:46:25 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 12 Apr 2021 23:46:25 +0200
Subject: [PATCH v2 1/6] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210412205753.GA158321@robh.at.kernel.org>
References: <20210411131007.21757-1-jbx6244@gmail.com>
 <20210412205753.GA158321@robh.at.kernel.org>
Message-ID: <5705f804-5db0-1d14-f853-02be72fe4d2c@gmail.com>

On 4/12/21 10:57 PM, Rob Herring wrote:
> On Sun, 11 Apr 2021 15:10:02 +0200, Johan Jonker wrote:
>> Current dts files with 'pwm' nodes are manually verified.
>> In order to automate this process pwm-rockchip.txt
>> has to be converted to yaml.
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---
>> Changed V2:
>>   changed schema for clocks and clock-names
>> ---
>>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
>>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 91 ++++++++++++++++++++++
>>  2 files changed, 91 insertions(+), 27 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
>>
> 
> Reviewed-by: Rob Herring <robh at kernel.org>
> 
Hi

This tags version 2 with a little mistake instead of version 3?
Is that correct?

Johan


From jbx6244 at gmail.com  Mon Apr 12 23:36:15 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 13 Apr 2021 00:36:15 +0200
Subject: [PATCH v2 1/3] dt-bindings: gpio: add YAML description for rockchip,
 gpio-bank
Message-ID: <20210412223617.8634-1-jbx6244@gmail.com>

Current dts files with "rockchip,gpio-bank" subnodes
are manually verified. In order to automate this process
the text that describes the compatible in rockchip,pinctrl.txt
is removed and converted to YAML in rockchip,gpio-bank.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V2:
  changed example gpio nodename
---
 .../bindings/gpio/rockchip,gpio-bank.yaml          | 82 ++++++++++++++++++++++
 .../bindings/pinctrl/rockchip,pinctrl.txt          | 58 +--------------
 2 files changed, 83 insertions(+), 57 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
new file mode 100644
index 000000000..d993e002c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip GPIO bank
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,gpio-bank
+      - rockchip,rk3188-gpio-bank0
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  gpio-controller: true
+
+  "#gpio-cells":
+    const: 2
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - gpio-controller
+  - "#gpio-cells"
+  - interrupt-controller
+  - "#interrupt-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    pinctrl: pinctrl {
+      #address-cells = <1>;
+      #size-cells = <1>;
+      ranges;
+
+      gpio0: gpio at 2000a000 {
+        compatible = "rockchip,rk3188-gpio-bank0";
+        reg = <0x2000a000 0x100>;
+        interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clk_gates8 9>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        interrupt-controller;
+        #interrupt-cells = <2>;
+      };
+
+      gpio1: gpio at 2003c000 {
+        compatible = "rockchip,gpio-bank";
+        reg = <0x2003c000 0x100>;
+        interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clk_gates8 10>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        interrupt-controller;
+        #interrupt-cells = <2>;
+      };
+    };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index d3eae61a3..4719a6a07 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -50,23 +50,7 @@ Deprecated properties for iomux controller:
 	 Use rockchip,grf and rockchip,pmu described above instead.
 
 Required properties for gpio sub nodes:
-  - compatible: "rockchip,gpio-bank"
-  - reg: register of the gpio bank (different than the iomux registerset)
-  - interrupts: base interrupt of the gpio bank in the interrupt controller
-  - clocks: clock that drives this bank
-  - gpio-controller: identifies the node as a gpio controller and pin bank.
-  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
-    binding is used, the amount of cells must be specified as 2. See generic
-    GPIO binding documentation for description of particular cells.
-  - interrupt-controller: identifies the controller node as interrupt-parent.
-  - #interrupt-cells: the value of this property should be 2 and the interrupt
-    cells should use the standard two-cell scheme described in
-    bindings/interrupt-controller/interrupts.txt
-
-Deprecated properties for gpio sub nodes:
-  - compatible: "rockchip,rk3188-gpio-bank0"
-  - reg: second element: separate pull register for rk3188 bank0, use
-	 rockchip,pmu described above instead
+See rockchip,gpio-bank.yaml
 
 Required properties for pin configuration node:
   - rockchip,pins: 3 integers array, represents a group of pins mux and config
@@ -127,43 +111,3 @@ uart2: serial at 20064000 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart2_xfer>;
 };
-
-Example for rk3188:
-
-	pinctrl at 20008000 {
-		compatible = "rockchip,rk3188-pinctrl";
-		rockchip,grf = <&grf>;
-		rockchip,pmu = <&pmu>;
-		#address-cells = <1>;
-		#size-cells = <1>;
-		ranges;
-
-		gpio0: gpio0 at 2000a000 {
-			compatible = "rockchip,rk3188-gpio-bank0";
-			reg = <0x2000a000 0x100>;
-			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clk_gates8 9>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		gpio1: gpio1 at 2003c000 {
-			compatible = "rockchip,gpio-bank";
-			reg = <0x2003c000 0x100>;
-			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clk_gates8 10>;
-
-			gpio-controller;
-			#gpio-cells = <2>;
-
-			interrupt-controller;
-			#interrupt-cells = <2>;
-		};
-
-		...
-
-	};
-- 
2.11.0



From jbx6244 at gmail.com  Mon Apr 12 23:36:16 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 13 Apr 2021 00:36:16 +0200
Subject: [PATCH v2 2/3] ARM: dts: rockchip: change gpio nodenames
In-Reply-To: <20210412223617.8634-1-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
Message-ID: <20210412223617.8634-2-jbx6244@gmail.com>

Currently all gpio nodenames are sort of identical to there label.
Nodenames should be of a generic type, so change them all.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3036.dtsi  |  6 +++---
 arch/arm/boot/dts/rk3066a.dtsi | 12 ++++++------
 arch/arm/boot/dts/rk3188.dtsi  |  8 ++++----
 arch/arm/boot/dts/rk322x.dtsi  |  8 ++++----
 arch/arm/boot/dts/rk3288.dtsi  | 18 +++++++++---------
 arch/arm/boot/dts/rv1108.dtsi  |  8 ++++----
 6 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index e24230d50..33ddede4b 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -505,7 +505,7 @@
 		#size-cells = <1>;
 		ranges;
 
-		gpio0: gpio0 at 2007c000 {
+		gpio0: gpio at 2007c000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2007c000 0x100>;
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
@@ -518,7 +518,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at 20080000 {
+		gpio1: gpio at 20080000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20080000 0x100>;
 			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
@@ -531,7 +531,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at 20084000 {
+		gpio2: gpio at 20084000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20084000 0x100>;
 			interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..cf3ea32e5 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -297,7 +297,7 @@
 		#size-cells = <1>;
 		ranges;
 
-		gpio0: gpio0 at 20034000 {
+		gpio0: gpio at 20034000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20034000 0x100>;
 			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
@@ -310,7 +310,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at 2003c000 {
+		gpio1: gpio at 2003c000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2003c000 0x100>;
 			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
@@ -323,7 +323,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at 2003e000 {
+		gpio2: gpio at 2003e000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2003e000 0x100>;
 			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
@@ -336,7 +336,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at 20080000 {
+		gpio3: gpio at 20080000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20080000 0x100>;
 			interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
@@ -349,7 +349,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio4: gpio4 at 20084000 {
+		gpio4: gpio at 20084000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20084000 0x100>;
 			interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
@@ -362,7 +362,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio6: gpio6 at 2000a000 {
+		gpio6: gpio at 2000a000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2000a000 0x100>;
 			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 2298a8d84..08aac5452 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -247,7 +247,7 @@
 		#size-cells = <1>;
 		ranges;
 
-		gpio0: gpio0 at 2000a000 {
+		gpio0: gpio at 2000a000 {
 			compatible = "rockchip,rk3188-gpio-bank0";
 			reg = <0x2000a000 0x100>;
 			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
@@ -260,7 +260,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at 2003c000 {
+		gpio1: gpio at 2003c000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2003c000 0x100>;
 			interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
@@ -273,7 +273,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at 2003e000 {
+		gpio2: gpio at 2003e000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x2003e000 0x100>;
 			interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
@@ -286,7 +286,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at 20080000 {
+		gpio3: gpio at 20080000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20080000 0x100>;
 			interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 118d96424..d9ac1d08c 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -823,7 +823,7 @@
 		#size-cells = <1>;
 		ranges;
 
-		gpio0: gpio0 at 11110000 {
+		gpio0: gpio at 11110000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x11110000 0x100>;
 			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
@@ -836,7 +836,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at 11120000 {
+		gpio1: gpio at 11120000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x11120000 0x100>;
 			interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
@@ -849,7 +849,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at 11130000 {
+		gpio2: gpio at 11130000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x11130000 0x100>;
 			interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
@@ -862,7 +862,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at 11140000 {
+		gpio3: gpio at 11140000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x11140000 0x100>;
 			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 05557ad02..e96a70ebe 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1424,7 +1424,7 @@
 		#size-cells = <2>;
 		ranges;
 
-		gpio0: gpio0 at ff750000 {
+		gpio0: gpio at ff750000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff750000 0x0 0x100>;
 			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
@@ -1437,7 +1437,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at ff780000 {
+		gpio1: gpio at ff780000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff780000 0x0 0x100>;
 			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
@@ -1450,7 +1450,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at ff790000 {
+		gpio2: gpio at ff790000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff790000 0x0 0x100>;
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
@@ -1463,7 +1463,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at ff7a0000 {
+		gpio3: gpio at ff7a0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7a0000 0x0 0x100>;
 			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
@@ -1476,7 +1476,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio4: gpio4 at ff7b0000 {
+		gpio4: gpio at ff7b0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7b0000 0x0 0x100>;
 			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
@@ -1489,7 +1489,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio5: gpio5 at ff7c0000 {
+		gpio5: gpio at ff7c0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7c0000 0x0 0x100>;
 			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
@@ -1502,7 +1502,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio6: gpio6 at ff7d0000 {
+		gpio6: gpio at ff7d0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7d0000 0x0 0x100>;
 			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
@@ -1515,7 +1515,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio7: gpio7 at ff7e0000 {
+		gpio7: gpio at ff7e0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7e0000 0x0 0x100>;
 			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
@@ -1528,7 +1528,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio8: gpio8 at ff7f0000 {
+		gpio8: gpio at ff7f0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7f0000 0x0 0x100>;
 			interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
index 68e2282f7..3ace88e8c 100644
--- a/arch/arm/boot/dts/rv1108.dtsi
+++ b/arch/arm/boot/dts/rv1108.dtsi
@@ -582,7 +582,7 @@
 		#size-cells = <1>;
 		ranges;
 
-		gpio0: gpio0 at 20030000 {
+		gpio0: gpio at 20030000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x20030000 0x100>;
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
@@ -595,7 +595,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at 10310000 {
+		gpio1: gpio at 10310000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x10310000 0x100>;
 			interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
@@ -608,7 +608,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at 10320000 {
+		gpio2: gpio at 10320000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x10320000 0x100>;
 			interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
@@ -621,7 +621,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at 10330000 {
+		gpio3: gpio at 10330000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x10330000 0x100>;
 			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.11.0



From jbx6244 at gmail.com  Mon Apr 12 23:36:17 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 13 Apr 2021 00:36:17 +0200
Subject: [PATCH v2 3/3] arm64: dts: rockchip: change gpio nodenames
In-Reply-To: <20210412223617.8634-1-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
Message-ID: <20210412223617.8634-3-jbx6244@gmail.com>

Currently all gpio nodenames are sort of identical to there label.
Nodenames should be of a generic type, so change them all.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi   |  8 ++++----
 arch/arm64/boot/dts/rockchip/rk3308.dtsi | 10 +++++-----
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  8 ++++----
 arch/arm64/boot/dts/rockchip/rk3368.dtsi |  8 ++++----
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 +++++-----
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 939440015..96924e05a 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1247,7 +1247,7 @@
 		#size-cells = <2>;
 		ranges;
 
-		gpio0: gpio0 at ff040000 {
+		gpio0: gpio at ff040000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff040000 0x0 0x100>;
 			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
@@ -1259,7 +1259,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at ff250000 {
+		gpio1: gpio at ff250000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff250000 0x0 0x100>;
 			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
@@ -1271,7 +1271,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at ff260000 {
+		gpio2: gpio at ff260000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff260000 0x0 0x100>;
 			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
@@ -1283,7 +1283,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at ff270000 {
+		gpio3: gpio at ff270000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff270000 0x0 0x100>;
 			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
index 00844a0e0..ba7dee2e8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
@@ -688,7 +688,7 @@
 		#size-cells = <2>;
 		ranges;
 
-		gpio0: gpio0 at ff220000 {
+		gpio0: gpio at ff220000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff220000 0x0 0x100>;
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
@@ -699,7 +699,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at ff230000 {
+		gpio1: gpio at ff230000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff230000 0x0 0x100>;
 			interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
@@ -710,7 +710,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at ff240000 {
+		gpio2: gpio at ff240000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff240000 0x0 0x100>;
 			interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
@@ -721,7 +721,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at ff250000 {
+		gpio3: gpio at ff250000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff250000 0x0 0x100>;
 			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
@@ -732,7 +732,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio4: gpio4 at ff260000 {
+		gpio4: gpio at ff260000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff260000 0x0 0x100>;
 			interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index c2ca358c7..858d52e2d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1019,7 +1019,7 @@
 		#size-cells = <2>;
 		ranges;
 
-		gpio0: gpio0 at ff210000 {
+		gpio0: gpio at ff210000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff210000 0x0 0x100>;
 			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
@@ -1032,7 +1032,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio1: gpio1 at ff220000 {
+		gpio1: gpio at ff220000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff220000 0x0 0x100>;
 			interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
@@ -1045,7 +1045,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio2: gpio2 at ff230000 {
+		gpio2: gpio at ff230000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff230000 0x0 0x100>;
 			interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
@@ -1058,7 +1058,7 @@
 			#interrupt-cells = <2>;
 		};
 
-		gpio3: gpio3 at ff240000 {
+		gpio3: gpio at ff240000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff240000 0x0 0x100>;
 			interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 7832e26a3..8ae10c434 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -803,7 +803,7 @@
 		#size-cells = <0x2>;
 		ranges;
 
-		gpio0: gpio0 at ff750000 {
+		gpio0: gpio at ff750000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff750000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO0>;
@@ -816,7 +816,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio1: gpio1 at ff780000 {
+		gpio1: gpio at ff780000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff780000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO1>;
@@ -829,7 +829,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio2: gpio2 at ff790000 {
+		gpio2: gpio at ff790000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff790000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO2>;
@@ -842,7 +842,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio3: gpio3 at ff7a0000 {
+		gpio3: gpio at ff7a0000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff7a0000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO3>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 6221b027e..c97a25c70 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1941,7 +1941,7 @@
 		#size-cells = <2>;
 		ranges;
 
-		gpio0: gpio0 at ff720000 {
+		gpio0: gpio at ff720000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff720000 0x0 0x100>;
 			clocks = <&pmucru PCLK_GPIO0_PMU>;
@@ -1954,7 +1954,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio1: gpio1 at ff730000 {
+		gpio1: gpio at ff730000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff730000 0x0 0x100>;
 			clocks = <&pmucru PCLK_GPIO1_PMU>;
@@ -1967,7 +1967,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio2: gpio2 at ff780000 {
+		gpio2: gpio at ff780000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff780000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO2>;
@@ -1980,7 +1980,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio3: gpio3 at ff788000 {
+		gpio3: gpio at ff788000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff788000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO3>;
@@ -1993,7 +1993,7 @@
 			#interrupt-cells = <0x2>;
 		};
 
-		gpio4: gpio4 at ff790000 {
+		gpio4: gpio at ff790000 {
 			compatible = "rockchip,gpio-bank";
 			reg = <0x0 0xff790000 0x0 0x100>;
 			clocks = <&cru PCLK_GPIO4>;
-- 
2.11.0



From andrew at aj.id.au  Tue Apr 13 00:18:16 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 13 Apr 2021 08:48:16 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v1_2/2]_mmc:_sdhci-of-aspeed:_Support_toggling_SD_b?=
 =?UTF-8?Q?us_signal_voltage_by_GPIO?=
In-Reply-To: <20210412065032.GC23408@aspeedtech.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-3-steven_lee@aspeedtech.com>
 <acaa2cc2-9b12-442e-a767-3c4b41affa21@www.fastmail.com>
 <20210412065032.GC23408@aspeedtech.com>
Message-ID: <11b63819-d37c-406d-9ebf-424d226a6839@www.fastmail.com>



On Mon, 12 Apr 2021, at 16:20, Steven Lee wrote:
> The 04/09/2021 12:14, Andrew Jeffery wrote:
> > Hi Steven,
> > 
> > On Thu, 8 Apr 2021, at 11:22, Steven Lee wrote:
> > > AST2600-A2 EVB provides reference design to support toggling signal
> > > voltage between 3.3v and 1.8v by power-switch-gpio pin that defined in
> > > the device tree.
> > 
> > Is this something you think we need support for beyond the EVB? It 
> > sounds a lot like a knob to enable testing of different SD/MMC power 
> > configurations and not something that you'd otherwise see in a system 
> > design.
> >
> 
> It can be used for testing different SD power configuration.
> The main purpose of the patch is letting the driver has the ability to 
> change the bus voltage for switching SD bus speed between UHS-I mode and
> normal/high speed mode in AST2600-A2 EVB according to the value of
> power-switch-gpio that defined in the device tree. 

Ah okay. I'm not strong on all the power requirements for each of the 
bus modes :)

> But I am not sure whether it needs to be support in mainline kernel.
> Since it requires a particular hardware circuit design outside of ASPEED
> AST2600 SoC, and AST2600-A2 EVB does have that design.

This shouldn't be a problem with Uffe's suggestion on the binding patch.

Better to have support in mainline than maintain out-of-tree patches!

> 
> > > It also supporting enabling/disabling SD bus power by
> > > power-gpio.
> > 
> > This sounds like it could be useful but I'll defer to Ulf with regards 
> > to the binding.
> > 
> > > 
> > > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> > > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> > > a 1.8v and a 3.3v power load switch that providing signal voltage to
> > > SD1 bus.
> > > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> > > disabled.
> > > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> > > voltage is 3.3v, otherwise, 1.8v power load switch will be enabled, SD1
> > > signal voltage becomes 1.8v.
> > > 
> > > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> > > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and
> > > GPIOV3 as power-switch-gpio.
> > > 
> > > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> > > ---
> > >  drivers/mmc/host/sdhci-of-aspeed.c | 155 +++++++++++++++++++++++++----
> > >  1 file changed, 137 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c 
> > > b/drivers/mmc/host/sdhci-of-aspeed.c
> > > index 7d8692e90996..a74a03d37915 100644
> > > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> > > @@ -5,6 +5,7 @@
> > >  #include <linux/clk.h>
> > >  #include <linux/delay.h>
> > >  #include <linux/device.h>
> > > +#include <linux/gpio/consumer.h>
> > >  #include <linux/io.h>
> > >  #include <linux/math64.h>
> > >  #include <linux/mmc/host.h>
> > > @@ -30,6 +31,7 @@
> > >  #define   ASPEED_SDC_S0_PHASE_IN_EN	BIT(2)
> > >  #define   ASPEED_SDC_S0_PHASE_OUT_EN	GENMASK(1, 0)
> > >  #define   ASPEED_SDC_PHASE_MAX		31
> > > +#define ASPEED_CLOCK_PHASE 0xf4
> > 
> > This isn't related to the power GPIOs, and we already have phase 
> > support as suggested by the macros immediately above the one you've 
> > added here.
> > 
> > Please remove it and make use of the existing mmc phase devicetree 
> > binding and driver support.
> > 
> 
> Will remove it.
> 
> > >  
> > >  struct aspeed_sdc {
> > >  	struct clk *clk;
> > > @@ -58,18 +60,21 @@ struct aspeed_sdhci_phase_desc {
> > >  	struct aspeed_sdhci_tap_desc out;
> > >  };
> > >  
> > > -struct aspeed_sdhci_pdata {
> > > +struct aspeed_sdhci_data {
> > 
> > Why are we renaming this? It looks like it creates a lot of noise in 
> > the patch. The data it captured was platform data, hence 'pdata' in the 
> > name. In my opinon it's fine if we also have a member called pdata.
> > 
> 
> Since I add a new member in aspeed_sdhci_pdata(In the patch, it is named
> aspeed_sdhci_data) for separating the platform data of aspeed-g5 and
> aspped-g6, the type of the member is sdhci_pltfm_data.
> Therefore, I use the pdata for my new created member and renamed the
> original pdata as data as follows.
> 
> static const struct of_device_id aspeed_sdhci_of_match[] = {
>   { .compatible = "aspeed,ast2400-sdhci", .data = &ast2400_sdhci_data, },
> };
> 
> static const struct aspeed_sdhci_data ast2400_sdhci_data = {
>   .clk_div_start = 2,
>   .pdata = &ast2400_sdhci_pdata,
> };
> 
> 
> Regardless, I will revert it to the original name and rename
> my new created variable.
> 
> > >  	unsigned int clk_div_start;
> > >  	const struct aspeed_sdhci_phase_desc *phase_desc;
> > >  	size_t nr_phase_descs;
> > > +	const struct sdhci_pltfm_data *pdata;
> > >  };
> > >  
> > >  struct aspeed_sdhci {
> > > -	const struct aspeed_sdhci_pdata *pdata;
> > > +	const struct aspeed_sdhci_data *data;
> > >  	struct aspeed_sdc *parent;
> > >  	u32 width_mask;
> > >  	struct mmc_clk_phase_map phase_map;
> > >  	const struct aspeed_sdhci_phase_desc *phase_desc;
> > > +	struct gpio_desc *pwr_pin;
> > > +	struct gpio_desc *pwr_sw_pin;
> > >  };
> > >  
> > >  static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
> > > @@ -209,7 +214,6 @@ static void aspeed_sdhci_set_clock(struct 
> > > sdhci_host *host, unsigned int clock)
> > >  	sdhci = sdhci_pltfm_priv(pltfm_host);
> > >  
> > >  	parent = clk_get_rate(pltfm_host->clk);
> > > -
> > 
> > Unrelated whitespace cleanup.
> > 
> > >  	sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> > >  
> > >  	if (clock == 0)
> > > @@ -234,14 +238,13 @@ static void aspeed_sdhci_set_clock(struct 
> > > sdhci_host *host, unsigned int clock)
> > >  	 * supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and 
> > > capture
> > >  	 * the 0-value capability in clk_div_start.
> > >  	 */
> > > -	for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
> > > +	for (div = sdhci->data->clk_div_start; div < 256; div *= 2) {
> > >  		bus = parent / div;
> > >  		if (bus <= clock)
> > >  			break;
> > >  	}
> > >  
> > >  	div >>= 1;
> > > -
> > 
> > Unrelated whitespace cleanup.
> > 
> > >  	clk = div << SDHCI_DIVIDER_SHIFT;
> > >  
> > >  	aspeed_sdhci_configure_phase(host, bus);
> > > @@ -292,8 +295,78 @@ static u32 aspeed_sdhci_readl(struct sdhci_host 
> > > *host, int reg)
> > >  	return val;
> > >  }
> > >  
> > > +static void sdhci_aspeed_set_power(struct sdhci_host *host, unsigned char mode,
> > > +				   unsigned short vdd)
> > > +{
> > > +	struct sdhci_pltfm_host *pltfm_priv = sdhci_priv(host);
> > > +	struct aspeed_sdhci *dev = sdhci_pltfm_priv(pltfm_priv);
> > > +	u8 pwr = 0;
> > > +
> > > +	if (!dev->pwr_pin)
> > > +		return sdhci_set_power(host, mode, vdd);
> > > +
> > > +	if (mode != MMC_POWER_OFF) {
> > > +		switch (1 << vdd) {
> > > +		case MMC_VDD_165_195:
> > > +		/*
> > > +		 * Without a regulator, SDHCI does not support 2.0v
> > > +		 * so we only get here if the driver deliberately
> > > +		 * added the 2.0v range to ocr_avail. Map it to 1.8v
> > > +		 * for the purpose of turning on the power.
> > > +		 */
> > > +		case MMC_VDD_20_21:
> > > +				pwr = SDHCI_POWER_180;
> > > +				break;
> > > +		case MMC_VDD_29_30:
> > > +		case MMC_VDD_30_31:
> > > +				pwr = SDHCI_POWER_300;
> > > +				break;
> > > +		case MMC_VDD_32_33:
> > > +		case MMC_VDD_33_34:
> > > +				pwr = SDHCI_POWER_330;
> > > +				break;
> > > +		default:
> > > +				WARN(1, "%s: Invalid vdd %#x\n",
> > > +				     mmc_hostname(host->mmc), vdd);
> > > +				break;
> > > +		}
> > > +	}
> > > +
> > > +	if (host->pwr == pwr)
> > > +		return;
> > > +
> > > +	host->pwr = pwr;
> > > +
> > > +	if (pwr == 0) {
> > 
> > Shouldn't we be testing against an SDHCI_POWER_* macro?
> > 
> 
> It is copied from sdhci_set_power_noreg() of sdhci.c
> The difference is we need to change the bus voltage before writing
> SDHCI_POWER_CONTROL.
> Since There are only SDHCI_POWER_ON, SDHCI_POWER_180, SDHCI_POWER_300,
> and SDHCI_POWER_330 defined in sdhci.h.
> Do you mean pwr should be checked with SDHCI_POWER_ON, SDHCI_POWER_180,
> SDHCI_POWER_300, and SDHCI_POWER_330?

No, I was a bit lazy and didn't look at what macros were defined.

Cheers,

Andrew


From pgwipeout at gmail.com  Tue Apr 13 00:22:17 2021
From: pgwipeout at gmail.com (Peter Geis)
Date: Mon, 12 Apr 2021 19:22:17 -0400
Subject: [PATCH v2 3/3] arm64: dts: rockchip: change gpio nodenames
In-Reply-To: <20210412223617.8634-3-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
 <20210412223617.8634-3-jbx6244@gmail.com>
Message-ID: <CAMdYzYqTS-qEOaVsnWMSABpj5Z55An_GLCUoOZZg-fjMp9qi8w@mail.gmail.com>

On Mon, Apr 12, 2021 at 6:38 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>
> Currently all gpio nodenames are sort of identical to there label.
> Nodenames should be of a generic type, so change them all.

Currently the rockchip pinctrl driver checks np->name against the
bank->name and if they do not match it does not set the gpio-bank as
valid.
The new GPIO driver appears to follow a similar method.
This will break the driver without a correction.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pinctrl/pinctrl-rockchip.c?h=next-20210412#n3836

>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  arch/arm64/boot/dts/rockchip/px30.dtsi   |  8 ++++----
>  arch/arm64/boot/dts/rockchip/rk3308.dtsi | 10 +++++-----
>  arch/arm64/boot/dts/rockchip/rk3328.dtsi |  8 ++++----
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi |  8 ++++----
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 +++++-----
>  5 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index 939440015..96924e05a 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -1247,7 +1247,7 @@
>                 #size-cells = <2>;
>                 ranges;
>
> -               gpio0: gpio0 at ff040000 {
> +               gpio0: gpio at ff040000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff040000 0x0 0x100>;
>                         interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1259,7 +1259,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio1: gpio1 at ff250000 {
> +               gpio1: gpio at ff250000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff250000 0x0 0x100>;
>                         interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1271,7 +1271,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio2: gpio2 at ff260000 {
> +               gpio2: gpio at ff260000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff260000 0x0 0x100>;
>                         interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1283,7 +1283,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio3: gpio3 at ff270000 {
> +               gpio3: gpio at ff270000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff270000 0x0 0x100>;
>                         interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> index 00844a0e0..ba7dee2e8 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> @@ -688,7 +688,7 @@
>                 #size-cells = <2>;
>                 ranges;
>
> -               gpio0: gpio0 at ff220000 {
> +               gpio0: gpio at ff220000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff220000 0x0 0x100>;
>                         interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> @@ -699,7 +699,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio1: gpio1 at ff230000 {
> +               gpio1: gpio at ff230000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff230000 0x0 0x100>;
>                         interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> @@ -710,7 +710,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio2: gpio2 at ff240000 {
> +               gpio2: gpio at ff240000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff240000 0x0 0x100>;
>                         interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> @@ -721,7 +721,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio3: gpio3 at ff250000 {
> +               gpio3: gpio at ff250000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff250000 0x0 0x100>;
>                         interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> @@ -732,7 +732,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio4: gpio4 at ff260000 {
> +               gpio4: gpio at ff260000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff260000 0x0 0x100>;
>                         interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index c2ca358c7..858d52e2d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -1019,7 +1019,7 @@
>                 #size-cells = <2>;
>                 ranges;
>
> -               gpio0: gpio0 at ff210000 {
> +               gpio0: gpio at ff210000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff210000 0x0 0x100>;
>                         interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1032,7 +1032,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio1: gpio1 at ff220000 {
> +               gpio1: gpio at ff220000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff220000 0x0 0x100>;
>                         interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1045,7 +1045,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio2: gpio2 at ff230000 {
> +               gpio2: gpio at ff230000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff230000 0x0 0x100>;
>                         interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
> @@ -1058,7 +1058,7 @@
>                         #interrupt-cells = <2>;
>                 };
>
> -               gpio3: gpio3 at ff240000 {
> +               gpio3: gpio at ff240000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff240000 0x0 0x100>;
>                         interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index 7832e26a3..8ae10c434 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -803,7 +803,7 @@
>                 #size-cells = <0x2>;
>                 ranges;
>
> -               gpio0: gpio0 at ff750000 {
> +               gpio0: gpio at ff750000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff750000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO0>;
> @@ -816,7 +816,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio1: gpio1 at ff780000 {
> +               gpio1: gpio at ff780000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff780000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO1>;
> @@ -829,7 +829,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio2: gpio2 at ff790000 {
> +               gpio2: gpio at ff790000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff790000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO2>;
> @@ -842,7 +842,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio3: gpio3 at ff7a0000 {
> +               gpio3: gpio at ff7a0000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff7a0000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO3>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 6221b027e..c97a25c70 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1941,7 +1941,7 @@
>                 #size-cells = <2>;
>                 ranges;
>
> -               gpio0: gpio0 at ff720000 {
> +               gpio0: gpio at ff720000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff720000 0x0 0x100>;
>                         clocks = <&pmucru PCLK_GPIO0_PMU>;
> @@ -1954,7 +1954,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio1: gpio1 at ff730000 {
> +               gpio1: gpio at ff730000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff730000 0x0 0x100>;
>                         clocks = <&pmucru PCLK_GPIO1_PMU>;
> @@ -1967,7 +1967,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio2: gpio2 at ff780000 {
> +               gpio2: gpio at ff780000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff780000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO2>;
> @@ -1980,7 +1980,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio3: gpio3 at ff788000 {
> +               gpio3: gpio at ff788000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff788000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO3>;
> @@ -1993,7 +1993,7 @@
>                         #interrupt-cells = <0x2>;
>                 };
>
> -               gpio4: gpio4 at ff790000 {
> +               gpio4: gpio at ff790000 {
>                         compatible = "rockchip,gpio-bank";
>                         reg = <0x0 0xff790000 0x0 0x100>;
>                         clocks = <&cru PCLK_GPIO4>;
> --
> 2.11.0
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


From andrew at aj.id.au  Tue Apr 13 00:37:48 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 13 Apr 2021 09:07:48 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v6_3/4]_serial:_8250=5Faspeed=5Fvuart:_add_aspeed, l?=
 =?UTF-8?Q?pc-io-reg_and_aspeed,lpc-interrupts_DT_properties?=
In-Reply-To: <20210412034712.16778-4-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
 <20210412034712.16778-4-zev@bewilderbeest.net>
Message-ID: <85b5abef-7c7a-4157-a13e-6ba85f463703@www.fastmail.com>



On Mon, 12 Apr 2021, at 13:17, Zev Weiss wrote:
> These allow describing all the Aspeed VUART attributes currently
> available via sysfs.  aspeed,lpc-interrupts provides a replacement for
> the deprecated aspeed,sirq-polarity-sense property.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>

Reviewed-by: Andrew Jeffery <andrew at aj.id.au>


From dillon.minfei at gmail.com  Tue Apr 13 00:44:39 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Tue, 13 Apr 2021 07:44:39 +0800
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
Message-ID: <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>

Hi Johan, Erwan

It seems still a bit of a problem in the current version, not deadlock
but access register at the same time.

For driver , we should consider it running under smp, let's think
about it for this case:

static void stm32_usart_console_write(struct console *co, const char *s,
                                      unsigned int cnt)
{
         .....
         local_irq_save(flags);
         if (port->sysrq)
                    locked = 0;
         .....
         access register cr1, tdr, isr
         .....

         local_irq_restore(flags);
}

if port->sysrq is 1, stm32_usart_console_write() just disable local
irq response by local_irq_save(), at the time of access register cr1,
tdr, isr. an TXE interrupt raised, for other cores(I know stm32
mpu/mcu do not have multi cores, just assume it has), it still has a
chance to handle interrupt.  Then there is no lock to protect the uart
register.

changes to below, should be more safe:

.....
if (port->sysrq || oops_in_progress)
      locked = spin_trylock_irqsave(&port->lock, flags);
else
      spin_lock_irqsave(&port->lock, flags);

....

if (locked)
     spin_unlock_irqrestore(&port->lock, flags);

For current stm32 soc, it shouldn't happen. just a reminder for future.

Thanks.

Dillon

On Mon, Apr 12, 2021 at 10:04 PM dillon min <dillon.minfei at gmail.com> wrote:
>
> Hi Johan,
>
> Yes, there is no deadlock. my fault.
> I forget the local_irq_save() plus spin_lock() is spin_lock_irqsave().
>
> Thanks for your review. please ignore this patch.
>
> Best regards
>
> Dillon
>
> On Mon, Apr 12, 2021 at 9:08 PM Johan Hovold <johan at kernel.org> wrote:
> >
> > On Mon, Apr 12, 2021 at 05:31:38PM +0800, dillon.minfei at gmail.com wrote:
> > > From: dillon min <dillon.minfei at gmail.com>
> > >
> > > To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
> > > spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.
> >
> > This doesn't make much sense as console_write can be called in any
> > context. And where's the deadlock you claim to be fixing here?
> >
> > > remove unused local_irq_save/restore call.
> > >
> > > Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> > > Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> > > Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> > > Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> > > Reported-by: kernel test robot <lkp at intel.com>
> > > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > > ---
> > > v2: remove unused code from stm32_usart_threaded_interrupt() according from
> > >     Greg's review.
> > >
> > >  drivers/tty/serial/stm32-usart.c | 8 +++-----
> > >  1 file changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > > index b3675cf25a69..b1ba5e36e36e 100644
> > > --- a/drivers/tty/serial/stm32-usart.c
> > > +++ b/drivers/tty/serial/stm32-usart.c
> > > @@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> > >       u32 old_cr1, new_cr1;
> > >       int locked = 1;
> > >
> > > -     local_irq_save(flags);
> > >       if (port->sysrq)
> > >               locked = 0;
> > >       else if (oops_in_progress)
> > > -             locked = spin_trylock(&port->lock);
> > > +             locked = spin_trylock_irqsave(&port->lock, flags);
> > >       else
> > > -             spin_lock(&port->lock);
> > > +             spin_lock_irqsave(&port->lock, flags);
> > >
> > >       /* Save and disable interrupts, enable the transmitter */
> > >       old_cr1 = readl_relaxed(port->membase + ofs->cr1);
> > > @@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> > >       writel_relaxed(old_cr1, port->membase + ofs->cr1);
> > >
> > >       if (locked)
> > > -             spin_unlock(&port->lock);
> > > -     local_irq_restore(flags);
> > > +             spin_unlock_irqrestore(&port->lock, flags);
> > >  }
> > >
> > >  static int stm32_usart_console_setup(struct console *co, char *options)
> >
> > Johan


From andrew at aj.id.au  Tue Apr 13 00:45:55 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 13 Apr 2021 09:15:55 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?=
 =?UTF-8?Q?vice_interface?=
In-Reply-To: <CAK8P3a3RXr5CR7DJgD9rEkN8owpPxXRgzRnPB_5LuQcHkzc4LA@mail.gmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
 <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>
 <CAK8P3a3RXr5CR7DJgD9rEkN8owpPxXRgzRnPB_5LuQcHkzc4LA@mail.gmail.com>
Message-ID: <e2d7268b-bdaf-45bf-bb21-a5b9f7e985a4@www.fastmail.com>



On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote:
> On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > > >
> > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > > > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > > > provide a means to generate IRQs and exchange arbitrary data between a
> > > > BMC and its host system.
> > >
> > > I only noticed the series after Joel asked about the DT changes on the arm
> > > side. One question though:
> > >
> > > How does this related to the drivers/input/serio/ framework that also talks
> > > to the keyboard controller for things that are not keyboards?
> >
> > I've taken a brief look and I feel they're somewhat closely related.
> >
> > It's plausible that we could wrangle the code so the Aspeed and Nuvoton
> > KCS drivers move under drivers/input/serio. If you squint, the i8042
> > serio device driver has similarities with what the Aspeed and Nuvoton
> > device drivers are providing to the KCS IPMI stack.
> 
> After looking some more into it, I finally understood that the two are
> rather complementary. While the  drivers/char/ipmi/kcs_bmc.c
> is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems
> that the proposed kcs_bmc_cdev_raw.c interface would be
> what corresponds to the other side of
> drivers/input/serio/i8042.c+userio.c.

Right. I guess the question is should we be splitting kernel subsystems 
along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe 
we can consolidate in the future if it makes sense?

> Then again, these are also on
> separate ports (0x60 for the keyboard controller, 0xca2 for the BMC
> KCS), so they would never actually talk to one another.

Well, sort of I guess. On Power systems we don't use the keyboard 
controller for IPMI or keyboards, so we're just kinda exploiting the 
hardware for our own purposes.

> 
> > Both the KCS IPMI and raw chardev I've implemented in this patch need
> > both read and write access to the status register (STR). serio could
> > potentially expose its value through serio_interrupt() using the
> > SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this
> > sentence. We'd need some extra support for writing STR via the serio
> > API. I'm not sure that fits into the abstraction (unless we make
> > serio_write() take a flags argument?).
> >
> > In that vein, the serio_raw interface is close to the functionality
> > that the raw chardev provides in this patch, though again serio_raw
> > lacks userspace access to STR. Flags are ignored in the ->interrupt()
> > callback so all values received via ->interrupt() are exposed as data.
> > The result is there's no way to take care of SERIO_OOB_DATA in the
> > read() path. Given that, I think we'd have to expose an ioctl() to
> > access the STR value after taking care of SERIO_OOB_DATA in
> > ->interrupt().
> >
> > I'm not sure where that lands us.
> 
> Based on what I looked up, I think you can just forget about my original
> question. We have two separate interfaces that use an Intel 8042-style
> protocol, but they don't really interact.

Right, this is still true given Power doesn't care for keyboards or 
IPMI via the keyboard controllers; the two still don't interact.

Andrew


From bjorn.andersson at linaro.org  Tue Apr 13 00:53:39 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 12 Apr 2021 18:53:39 -0500
Subject: [PATCH] phy: qcom-qmp: remove redundant error of clock bulk
In-Reply-To: <1617937630-24832-1-git-send-email-chunfeng.yun@mediatek.com>
References: <1617937630-24832-1-git-send-email-chunfeng.yun@mediatek.com>
Message-ID: <20210412235339.GF1538589@yoga>

On Thu 08 Apr 22:07 CDT 2021, Chunfeng Yun wrote:

> There is error log in clk_bulk_prepare/enable()
> 

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 9cdebe7..f14b8be 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -3598,10 +3598,8 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
>  	}
>  
>  	ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> -	if (ret) {
> -		dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> +	if (ret)
>  		goto err_rst;
> -	}
>  
>  	if (cfg->has_phy_dp_com_ctrl) {
>  		qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
> @@ -4035,10 +4033,8 @@ static int __maybe_unused qcom_qmp_phy_runtime_resume(struct device *dev)
>  	}
>  
>  	ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks);
> -	if (ret) {
> -		dev_err(qmp->dev, "failed to enable clks, err=%d\n", ret);
> +	if (ret)
>  		return ret;
> -	}
>  
>  	ret = clk_prepare_enable(qphy->pipe_clk);
>  	if (ret) {
> -- 
> 1.8.1.1.dirty
> 


From anshuman.khandual at arm.com  Tue Apr 13 02:08:55 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Tue, 13 Apr 2021 06:38:55 +0530
Subject: [PATCH V2 4/6] mm: Drop redundant
 ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION
In-Reply-To: <20210412115952.GC27818@linux>
References: <1617259448-22529-1-git-send-email-anshuman.khandual@arm.com>
 <1617259448-22529-5-git-send-email-anshuman.khandual@arm.com>
 <20210412115952.GC27818@linux>
Message-ID: <3ae8627b-68dc-8a86-fbf0-5e65e25ebffb@arm.com>

On 4/12/21 5:29 PM, Oscar Salvador wrote:
> On Thu, Apr 01, 2021 at 12:14:06PM +0530, Anshuman Khandual wrote:
>> ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION configs have duplicate definitions on
>> platforms that subscribe them. Drop these reduntant definitions and instead
>> just select them appropriately.
>>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: Michael Ellerman <mpe at ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
>> Cc: Paul Mackerras <paulus at samba.org>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Ingo Molnar <mingo at redhat.com>
>> Cc: "H. Peter Anvin" <hpa at zytor.com>
>> Cc: Andrew Morton <akpm at linux-foundation.org>
>> Cc: x86 at kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linuxppc-dev at lists.ozlabs.org
>> Cc: linux-mm at kvack.org
>> Cc: linux-kernel at vger.kernel.org
>> Acked-by: Catalin Marinas <catalin.marinas at arm.com> (arm64)
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> 
> Hi Anshuman, 
> 
> X86 needs fixing, see below:
> 
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 503d8b2e8676..10702ef1eb57 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -60,8 +60,10 @@ config X86
>>  	select ACPI_SYSTEM_POWER_STATES_SUPPORT	if ACPI
>>  	select ARCH_32BIT_OFF_T			if X86_32
>>  	select ARCH_CLOCKSOURCE_INIT
>> +	select ARCH_ENABLE_HUGEPAGE_MIGRATION if x86_64 && HUGETLB_PAGE && MIGRATION
>>  	select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 || (X86_32 && HIGHMEM)
>>  	select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
>> +	select ARCH_ENABLE_THP_MIGRATION if x86_64 && TRANSPARENT_HUGEPAGE
> 
> you need s/x86_64/X86_64/, otherwise we are left with no migration :-)

Ahh, right. I guess this could not have got detected during a build test.
As the series is in mmotm tree, wondering if Andrew could help fix these
typos in this patch.


From steven_lee at aspeedtech.com  Tue Apr 13 02:30:10 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Tue, 13 Apr 2021 09:30:10 +0800
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <20210409184118.GA3934798@robh.at.kernel.org>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
 <20210409184118.GA3934798@robh.at.kernel.org>
Message-ID: <20210413013010.GA353@aspeedtech.com>

The 04/10/2021 02:41, Rob Herring wrote:
> On Thu, Apr 08, 2021 at 09:52:17AM +0800, Steven Lee wrote:
> > AST2600-A2 EVB provides the reference design for enabling SD bus power
> > and toggling SD bus signal voltage by GPIO pins.
> > Add the definition and example for power-gpio and power-switch-gpio
> > properties.
> > 
> > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> > a 1.8v and a 3.3v power load switch that providing signal voltage to
> > SD1 bus.
> > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> > disabled.
> > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> > voltage is 3.3v. Otherwise, 1.8v power load switch will be enabled, SD1
> > signal voltage becomes 1.8v.
> > 
> > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and GPIOV3
> > as power-switch-gpio.
> > 
> > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> > ---
> >  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25 +++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > index 987b287f3bff..515a74614f3c 100644
> > --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > @@ -37,6 +37,14 @@ properties:
> >    clocks:
> >      maxItems: 1
> >      description: The SD/SDIO controller clock gate
> > +  power-gpio:
> 
> '-gpios' is the preferred form even if just 1.
> 

Thanks for reviewing, I will change the name.

> > +    description:
> > +      The GPIO for enabling/disabling SD bus power.
> > +    maxItems: 1
> 
> blank line
> 

I will remove the blank line.

> > +  power-switch-gpio:
> > +    description:
> > +      The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> > +    maxItems: 1
> >  
> >  patternProperties:
> >    "^sdhci@[0-9a-f]+$":
> > @@ -61,6 +69,14 @@ patternProperties:
> >        sdhci,auto-cmd12:
> >          type: boolean
> >          description: Specifies that controller should use auto CMD12
> > +      power-gpio:
> > +        description:
> > +          The GPIO for enabling/disabling SD bus power.
> > +        maxItems: 1
> > +      power-switch-gpio:
> > +        description:
> > +          The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> > +        maxItems: 1
> >      required:
> >        - compatible
> >        - reg
> > @@ -80,6 +96,7 @@ required:
> >  examples:
> >    - |
> >      #include <dt-bindings/clock/aspeed-clock.h>
> > +    #include <dt-bindings/gpio/aspeed-gpio.h>
> >      sdc at 1e740000 {
> >              compatible = "aspeed,ast2500-sd-controller";
> >              reg = <0x1e740000 0x100>;
> > @@ -94,6 +111,10 @@ examples:
> >                      interrupts = <26>;
> >                      sdhci,auto-cmd12;
> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
> > +                                     GPIO_ACTIVE_HIGH>;
> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 1)
> > +                                     GPIO_ACTIVE_HIGH>;
> >              };
> >  
> >              sdhci1: sdhci at 200 {
> > @@ -102,5 +123,9 @@ examples:
> >                      interrupts = <26>;
> >                      sdhci,auto-cmd12;
> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
> > +                                     GPIO_ACTIVE_HIGH>;
> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 3)
> > +                                     GPIO_ACTIVE_HIGH>;
> >              };
> >      };
> > -- 
> > 2.17.1
> > 


From sboyd at kernel.org  Tue Apr 13 03:10:29 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Mon, 12 Apr 2021 19:10:29 -0700
Subject: [PATCH][V2] clk: uniphier: Fix potential infinite loop
In-Reply-To: <20210409090104.629722-2-colin.king@canonical.com>
References: <20210409090104.629722-1-colin.king@canonical.com>
 <20210409090104.629722-2-colin.king@canonical.com>
Message-ID: <161827982902.3764895.8459589544672421029@swboyd.mtv.corp.google.com>

Quoting Colin King (2021-04-09 02:01:04)
> From: Colin Ian King <colin.king at canonical.com>
> 
> The for-loop iterates with a u8 loop counter i and compares this
> with the loop upper limit of num_parents that is an int type.
> There is a potential infinite loop if num_parents is larger than
> the u8 loop counter. Fix this by making the loop counter the same
> type as num_parents.  Also make num_parents an unsigned int to
> match the return type of the call to clk_hw_get_num_parents.
> 
> Addresses-Coverity: ("Infinite loop")
> Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
> 
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---

Applied to clk-next


From billy_tsai at aspeedtech.com  Tue Apr 13 03:11:30 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Tue, 13 Apr 2021 02:11:30 +0000
Subject: [PATCH 4/4] pwm: Add support for aspeed pwm controller
In-Reply-To: <20210412111400.w4yafy2r2lcy3qqv@pengutronix.de>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-5-billy_tsai@aspeedtech.com>
 <20210412111400.w4yafy2r2lcy3qqv@pengutronix.de>
Message-ID: <BAD0AD58-BE95-4EF2-BC3F-EFAA19A91965@aspeedtech.com>

Thanks for your review

Best Regards,
Billy Tsai

On 2021/4/12, 7:14 PM,Uwe Kleine-K?nigwrote:

    >Hello,

    >On Mon, Apr 12, 2021 at 05:54:57PM +0800, Billy Tsai wrote:
    >> Add support for the pwm controller which can be found at aspeed ast2600
    >> soc. This driver is part function of multi-funciton of device "pwm-tach
    >> controller".

    >please squash this into patch 3.

OK, I will squash it when sending v2.

    >> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
    >> ---
    >>  drivers/pwm/Kconfig  | 6 ++++++
    >>  drivers/pwm/Makefile | 1 +
    >>  2 files changed, 7 insertions(+)
    >> 
    >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
    >> index 63be5362fd3a..947ed642debe 100644
    >> --- a/drivers/pwm/Kconfig
    >> +++ b/drivers/pwm/Kconfig
    >> @@ -42,6 +42,12 @@ config PWM_DEBUG
    >>  	  It is expected to introduce some runtime overhead and diagnostic
    >>  	  output to the kernel log, so only enable while working on a driver.
    >>  
    >> +config PWM_ASPEED_G6
    >> +	tristate "ASPEEDG6 PWM support"

    >No depends?

I will add "depends on (ARCH_ASPEED || COMPILE_TEST)" for this configure.

    >Best regards
    >Uwe

    >-- 
    >Pengutronix e.K.                           | Uwe Kleine-K?nig            |
    >Industrial Linux Solutions                 | https://www.pengutronix.de/ |


From bjorn.andersson at linaro.org  Tue Apr 13 03:36:12 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 12 Apr 2021 21:36:12 -0500
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1_YB944niA-ebk-nJx-JDBh1q7z6s-9mLGFjF2Nv9r9w@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
 <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>
 <20210412160116.GA904837@yoga>
 <CAK8P3a1_YB944niA-ebk-nJx-JDBh1q7z6s-9mLGFjF2Nv9r9w@mail.gmail.com>
Message-ID: <20210413023612.GH1538589@yoga>

On Mon 12 Apr 13:52 CDT 2021, Arnd Bergmann wrote:

> On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson
> <bjorn.andersson at linaro.org> wrote:
> > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote:
> > > On Mon, Apr 12, 2021 at 1:32 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > On Thu, Apr 8, 2021 at 5:08 PM Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > So the same binding patch is picked up both in the driver and soc tree?
> > I was expecting that to cause (harmless) conflicts when things arrive in
> > Linus' merge queue?
> >
> > Or are you saying people go the length to create immutable branches for
> > each binding?
> 
> I think it's usually one immutable branch for all the bindings of a given
> merge window. This avoids the merge conflicts, and you can add further
> bindings on the same branch before sending it off to the soc tree.
> 

That would be convenient to have, but the binding changes we depend on
in a given window (in particular if dtbs_check is expected to pass) is
scattered over a wide range of maintainer trees.

> > I'm curious because it's fairly often that we introduce clocks,
> > interconnects etc where the macros from the dt bindings includes aren't
> > available for another release (so we use numerical constants and then go
> > back and fix them up later).
> 
> Ah right, it is particularly bad for platforms that don't have a regular
> layout in these blocks and need to define a new constant every time
> another clock/reset/pin/... is discovered in the downstream sources.
> 

Even blocks following some standardized layout has this problem, because
each platform will have it's own (often similar) set of
clocks/resets/pins.

And going back to dtbs_check, you will continue to see the warnings
about missing compatibles, because most of the case they won't end up in
the soc tree.

> I was mainly referring to the simpler problem of defining a binding
> document for a device once, and then merging the nodes.
> 

I'm sure we all love the hardware that's simple to translate to a DT
binding, unfortunately though we're dealing with complex SoCs.

Regards,
Bjorn


From miltonm at us.ibm.com  Tue Apr 13 03:43:14 2021
From: miltonm at us.ibm.com (Milton Miller II)
Date: Tue, 13 Apr 2021 02:43:14 +0000
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <20210413013010.GA353@aspeedtech.com>
References: <20210413013010.GA353@aspeedtech.com>,
 <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
 <20210409184118.GA3934798@robh.at.kernel.org>
Message-ID: <OF2606E97A.D9A04B5B-ON002586B6.000DC6EE-002586B6.000EF1DC@notes.na.collabserv.com>



-----"openbmc" <openbmc-bounces+miltonm=us.ibm.com at lists.ozlabs.org> wrote: -----

>To: Rob Herring <robh at kernel.org>
>From: Steven Lee 
>Sent by: "openbmc" 
>Date: 04/12/2021 08:31PM
>Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
><devicetree at vger.kernel.org>, Ulf Hansson <ulf.hansson at linaro.org>,
>Ryan Chen <ryan_chen at aspeedtech.com>, "moderated list:ASPEED SD/MMC
>DRIVER" <linux-aspeed at lists.ozlabs.org>, Andrew Jeffery
><andrew at aj.id.au>, "open list:ASPEED SD/MMC DRIVER"
><linux-mmc at vger.kernel.org>, "moderated list:ASPEED SD/MMC DRIVER"
><openbmc at lists.ozlabs.org>, Ryan Chen <ryanchen.aspeed at gmail.com>,
>Adrian Hunter <adrian.hunter at intel.com>, open list
><linux-kernel at vger.kernel.org>, Chin-Ting Kuo
><chin-ting_kuo at aspeedtech.com>, "moderated list:ARM/ASPEED MACHINE
>SUPPORT" <linux-arm-kernel at lists.infradead.org>
>Subject: [EXTERNAL] Re: [PATCH v1 1/2] dt-bindings: mmc:
>sdhci-of-aspeed: Add power-gpio and power-switch-gpio
>
>The 04/10/2021 02:41, Rob Herring wrote:
>> On Thu, Apr 08, 2021 at 09:52:17AM +0800, Steven Lee wrote:
>> > AST2600-A2 EVB provides the reference design for enabling SD bus
>power
>> > and toggling SD bus signal voltage by GPIO pins.
>> > Add the definition and example for power-gpio and
>power-switch-gpio
>> > properties.
>> > 
>> > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to
>power
>> > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is
>connected to
>> > a 1.8v and a 3.3v power load switch that providing signal voltage
>to
>> > SD1 bus.
>> > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus
>is
>> > disabled.
>> > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1
>signal
>> > voltage is 3.3v. Otherwise, 1.8v power load switch will be
>enabled, SD1
>> > signal voltage becomes 1.8v.
>> > 
>> > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
>> > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio
>and GPIOV3
>> > as power-switch-gpio.
>> > 
>> > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
>> > ---
>> >  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25
>+++++++++++++++++++
>> >  1 file changed, 25 insertions(+)
>> > 
>> > diff --git
>a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
>b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
>> > index 987b287f3bff..515a74614f3c 100644
>> > --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
>> > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
>> > @@ -37,6 +37,14 @@ properties:
>> >    clocks:
>> >      maxItems: 1
>> >      description: The SD/SDIO controller clock gate
>> > +  power-gpio:
>> 
>> '-gpios' is the preferred form even if just 1.
>> 
>
>Thanks for reviewing, I will change the name.

is this a clock gate or a power on gpio?


>
>> > +    description:
>> > +      The GPIO for enabling/disabling SD bus power.
>> > +    maxItems: 1
>> 
>> blank line
>> 
>
>I will remove the blank line.
>
>> > +  power-switch-gpio:
>> > +    description:
>> > +      The GPIO for toggling the signal voltage between 3.3v and
>1.8v.

Which way does it toggle for which voltage?

Oh, you said in the change log but not in the binding.

But please, use gpio controled regulators as Ulf suggested and is
already used by other mmc controllers upstream.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
Documentation/devicetree/bindings/regulator/gpio-regulator.yaml

Ulf> Please do not model these as GPIO pins like this. Instead, it's better
Ulf> to model them as gpio regulators, since the mmc core manages them as
Ulf> regulators.
Ulf> 
Ulf> We have a vmmc regulator (corresponding to vdd) and a vqmmc regulator
Ulf> (corresponding the signal-voltage level). These are also described in
Ulf> the common mmc DT bindings, see
Ulf> Documentation/devicetree/bindings/mmc/mmc-controller.yaml
Ulf> .

milton

>> > +    maxItems: 1
>> >  
>> >  patternProperties:
>> >    "^sdhci@[0-9a-f]+$":
>> > @@ -61,6 +69,14 @@ patternProperties:
>> >        sdhci,auto-cmd12:
>> >          type: boolean
>> >          description: Specifies that controller should use auto
>CMD12
>> > +      power-gpio:
>> > +        description:
>> > +          The GPIO for enabling/disabling SD bus power.
>> > +        maxItems: 1
>> > +      power-switch-gpio:
>> > +        description:
>> > +          The GPIO for toggling the signal voltage between 3.3v
>and 1.8v.
>> > +        maxItems: 1
>> >      required:
>> >        - compatible
>> >        - reg
>> > @@ -80,6 +96,7 @@ required:
>> >  examples:
>> >    - |
>> >      #include <dt-bindings/clock/aspeed-clock.h>
>> > +    #include <dt-bindings/gpio/aspeed-gpio.h>
>> >      sdc at 1e740000 {
>> >              compatible = "aspeed,ast2500-sd-controller";
>> >              reg = <0x1e740000 0x100>;
>> > @@ -94,6 +111,10 @@ examples:
>> >                      interrupts = <26>;
>> >                      sdhci,auto-cmd12;
>> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
>> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
>> > +                                     GPIO_ACTIVE_HIGH>;
>> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V,
>1)
>> > +                                     GPIO_ACTIVE_HIGH>;
>> >              };
>> >  
>> >              sdhci1: sdhci at 200 {
>> > @@ -102,5 +123,9 @@ examples:
>> >                      interrupts = <26>;
>> >                      sdhci,auto-cmd12;
>> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
>> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
>> > +                                     GPIO_ACTIVE_HIGH>;
>> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V,
>3)
>> > +                                     GPIO_ACTIVE_HIGH>;
>> >              };
>> >      };
>> > -- 
>> > 2.17.1
>> > 
>
>



From steven_lee at aspeedtech.com  Tue Apr 13 04:31:56 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Tue, 13 Apr 2021 11:31:56 +0800
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <CAPDyKFr=Gtwu4v22FBaax5EjRbXTNez1N2ZQxP=v0LKGFTCovw@mail.gmail.com>
References: <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
 <CAPDyKFr=Gtwu4v22FBaax5EjRbXTNez1N2ZQxP=v0LKGFTCovw@mail.gmail.com>
Message-ID: <20210413033155.GA3522@aspeedtech.com>

The 04/12/2021 15:38, Ulf Hansson wrote:
> On Thu, 8 Apr 2021 at 03:52, Steven Lee <steven_lee at aspeedtech.com> wrote:
> >
> > AST2600-A2 EVB provides the reference design for enabling SD bus power
> > and toggling SD bus signal voltage by GPIO pins.
> > Add the definition and example for power-gpio and power-switch-gpio
> > properties.
> >
> > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to power
> > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is connected to
> > a 1.8v and a 3.3v power load switch that providing signal voltage to
> > SD1 bus.
> > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus is
> > disabled.
> > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1 signal
> > voltage is 3.3v. Otherwise, 1.8v power load switch will be enabled, SD1
> > signal voltage becomes 1.8v.
> >
> > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio and GPIOV3
> > as power-switch-gpio.
> 
> Thanks for sharing the details, it certainly helps while reviewing.
> 
> >
> > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> > ---
> >  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25 +++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > index 987b287f3bff..515a74614f3c 100644
> > --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > @@ -37,6 +37,14 @@ properties:
> >    clocks:
> >      maxItems: 1
> >      description: The SD/SDIO controller clock gate
> > +  power-gpio:
> > +    description:
> > +      The GPIO for enabling/disabling SD bus power.
> > +    maxItems: 1
> > +  power-switch-gpio:
> > +    description:
> > +      The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> > +    maxItems: 1
> 
> 
> >
> >  patternProperties:
> >    "^sdhci@[0-9a-f]+$":
> > @@ -61,6 +69,14 @@ patternProperties:
> >        sdhci,auto-cmd12:
> >          type: boolean
> >          description: Specifies that controller should use auto CMD12
> > +      power-gpio:
> > +        description:
> > +          The GPIO for enabling/disabling SD bus power.
> > +        maxItems: 1
> > +      power-switch-gpio:
> > +        description:
> > +          The GPIO for toggling the signal voltage between 3.3v and 1.8v.
> > +        maxItems: 1
> >      required:
> 
> Please do not model these as GPIO pins like this. Instead, it's better
> to model them as gpio regulators, since the mmc core manages them as
> regulators.
> 
> We have a vmmc regulator (corresponding to vdd) and a vqmmc regulator
> (corresponding the signal-voltage level). These are also described in
> the common mmc DT bindings, see
> Documentation/devicetree/bindings/mmc/mmc-controller.yaml.
> 

Thanks for the information. I will modify it.

> >        - compatible
> >        - reg
> > @@ -80,6 +96,7 @@ required:
> >  examples:
> >    - |
> >      #include <dt-bindings/clock/aspeed-clock.h>
> > +    #include <dt-bindings/gpio/aspeed-gpio.h>
> >      sdc at 1e740000 {
> >              compatible = "aspeed,ast2500-sd-controller";
> >              reg = <0x1e740000 0x100>;
> > @@ -94,6 +111,10 @@ examples:
> >                      interrupts = <26>;
> >                      sdhci,auto-cmd12;
> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
> > +                                     GPIO_ACTIVE_HIGH>;
> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 1)
> > +                                     GPIO_ACTIVE_HIGH>;
> >              };
> >
> >              sdhci1: sdhci at 200 {
> > @@ -102,5 +123,9 @@ examples:
> >                      interrupts = <26>;
> >                      sdhci,auto-cmd12;
> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
> > +                                     GPIO_ACTIVE_HIGH>;
> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V, 3)
> > +                                     GPIO_ACTIVE_HIGH>;
> >              };
> >      };
> 
> Kind regards
> Uffe


From chunfeng.yun at mediatek.com  Tue Apr 13 04:35:55 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Tue, 13 Apr 2021 11:35:55 +0800
Subject: [PATCH 4/6] usb: xhci-mtk: add support runtime PM
In-Reply-To: <CAATdQgCjNbUKsJYZjr5wHbXV5y-7ZZrN=URKccCv1d+S4zFiDA@mail.gmail.com>
References: <1617874514-12282-1-git-send-email-chunfeng.yun@mediatek.com>
 <1617874514-12282-4-git-send-email-chunfeng.yun@mediatek.com>
 <CAATdQgArnkdmbZefF4h7xp6=j-wHLgdQs1K0cDv06sP4eVdHmw@mail.gmail.com>
 <1617958441.12105.39.camel@mhfsdcap03>
 <CAATdQgCjNbUKsJYZjr5wHbXV5y-7ZZrN=URKccCv1d+S4zFiDA@mail.gmail.com>
Message-ID: <1618284955.25729.6.camel@mhfsdcap03>

On Mon, 2021-04-12 at 13:14 +0800, Ikjoon Jang wrote:
> On Fri, Apr 9, 2021 at 4:54 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> >
> > On Fri, 2021-04-09 at 13:45 +0800, Ikjoon Jang wrote:
> > > On Thu, Apr 8, 2021 at 5:35 PM Chunfeng Yun <chunfeng.yun at mediatek.com> wrote:
> > > >
> > > > A dedicated wakeup irq will be used to handle runtime suspend/resume,
> > > > we use dev_pm_set_dedicated_wake_irq API to take care of requesting
> > > > and attaching wakeup irq, then the suspend/resume framework will help
> > > > to enable/disable wakeup irq.
> > > >
> > > > The runtime PM is default off since some platforms may not support it.
> > > > users can enable it via power/control (set "auto") in sysfs.
> > > >
> > > > Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> > > > ---
> > > >  drivers/usb/host/xhci-mtk.c | 140 +++++++++++++++++++++++++++++++-----
> > > >  1 file changed, 124 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > > > index a74764ab914a..30927f4064d4 100644
> > > > --- a/drivers/usb/host/xhci-mtk.c
> > > > +++ b/drivers/usb/host/xhci-mtk.c
[...]
> > > >
> > > > +static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
> > > > +{
> > > > +       u32 suspended_ports;
> > > > +       u32 status;
> > > > +       int num_ports;
> > > > +       int i;
> > > > +
> > > > +       num_ports = rhub->num_ports;
> > > > +       suspended_ports = rhub->bus_state.suspended_ports;
> > > > +       for (i = 0; i < num_ports; i++) {
> > > > +               if (!(suspended_ports & BIT(i))) {
> > > > +                       status = readl(rhub->ports[i]->addr);
> > > > +                       if (status & PORT_CONNECT)
> > >
> > > So this pm_runtime support is activated only when there's no devices
> > > connected at all?
> > No, if the connected devices also support runtime suspend, it will enter
> > suspend mode when no data transfer, then the controller can enter
> > suspend too
> > > I think this will always return -EBUSY with my board having an on-board hub
> > > connected to both rhubs.
> > the on-board hub supports runtime suspend by default, so if no devices
> > connected, it will enter suspend
> 
> Sorry, you're correct. I was confused that the condition was
> (suspended && connect)
> My on-board hub connected to rhub is always in a suspended state
> whenever it's called.
> 
> However, I don't think this could return -EBUSY
> rpm_suspend() only be called when all the descendants are in sleep already.
You mean we can drop the bus check? 
If PM already takes care of children count, I think no need check it
anymore.
> Did you see any cases of this function returning -EBUSY or any concerns on here?
No, I didn't see it before.

Thanks

> 
> 
> >
> > >
> > > > +                               return -EBUSY;
> > > > +               }
> > > > +       }
> > > > +
> > > > +       return 0;
> > > > +}
> > > > +
> > > > +/*
> > > > + * check the bus whether it could suspend or not
> > > > + * the bus will suspend if the downstream ports are already suspended,
> > > > + * or no devices connected.
> > > > + */
> > > > +static int check_bus_status(struct xhci_hcd *xhci)
> > > > +{
> > > > +       int ret;
> > > > +
> > > > +       ret = check_rhub_status(xhci, &xhci->usb3_rhub);
> > > > +       if (ret)
> > > > +               return ret;
> > > > +
> > > > +       return check_rhub_status(xhci, &xhci->usb2_rhub);
> > > > +}
> > > > +
> > > > +static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
> > > > +{
> > > > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > > > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > > > +       int ret = 0;
> > > > +
> > > > +       if (xhci->xhc_state)
> > > > +               return -ESHUTDOWN;
> > > > +
> > > > +       if (device_may_wakeup(dev)) {
> > > > +               ret = check_bus_status(xhci);
> > > > +               if (!ret)
> > > > +                       ret = xhci_mtk_suspend(dev);
> > > > +       }
> > > > +
> > > > +       /* -EBUSY: let PM automatically reschedule another autosuspend */
> > > > +       return ret ? -EBUSY : 0;
> > > > +}
> > > > +
> > > > +static int __maybe_unused xhci_mtk_runtime_resume(struct device *dev)
> > > > +{
> > > > +       struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
> > > > +       struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
> > > > +       int ret = 0;
> > > > +
> > > > +       if (xhci->xhc_state)
> > > > +               return -ESHUTDOWN;
> > > > +
> > > > +       if (device_may_wakeup(dev))
> > > > +               ret = xhci_mtk_resume(dev);
> > > > +
> > > > +       return ret;
> > > > +}
> > > > +
> > > >  static const struct dev_pm_ops xhci_mtk_pm_ops = {
> > > >         SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
> > > > +       SET_RUNTIME_PM_OPS(xhci_mtk_runtime_suspend,
> > > > +                          xhci_mtk_runtime_resume, NULL)
> > > >  };
> > > > -#define DEV_PM_OPS IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL
> > > > +
> > > > +#define DEV_PM_OPS (IS_ENABLED(CONFIG_PM) ? &xhci_mtk_pm_ops : NULL)
> > > >
> > > >  static const struct of_device_id mtk_xhci_of_match[] = {
> > > >         { .compatible = "mediatek,mt8173-xhci"},
> > > > --
> > > > 2.18.0
> > > >
> >


From steven_lee at aspeedtech.com  Tue Apr 13 04:38:30 2021
From: steven_lee at aspeedtech.com (Steven Lee)
Date: Tue, 13 Apr 2021 11:38:30 +0800
Subject: [PATCH v1 1/2] dt-bindings: mmc: sdhci-of-aspeed: Add power-gpio
 and power-switch-gpio
In-Reply-To: <OF2606E97A.D9A04B5B-ON002586B6.000DC6EE-002586B6.000EF1DC@notes.na.collabserv.com>
References: <20210413013010.GA353@aspeedtech.com>
 <20210408015218.20560-1-steven_lee@aspeedtech.com>
 <20210408015218.20560-2-steven_lee@aspeedtech.com>
 <20210409184118.GA3934798@robh.at.kernel.org>
 <OF2606E97A.D9A04B5B-ON002586B6.000DC6EE-002586B6.000EF1DC@notes.na.collabserv.com>
Message-ID: <20210413033829.GB3522@aspeedtech.com>

The 04/13/2021 10:43, Milton Miller II wrote:
> 
> 
> -----"openbmc" <openbmc-bounces+miltonm=us.ibm.com at lists.ozlabs.org> wrote: -----
> 
> >To: Rob Herring <robh at kernel.org>
> >From: Steven Lee 
> >Sent by: "openbmc" 
> >Date: 04/12/2021 08:31PM
> >Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
> ><devicetree at vger.kernel.org>, Ulf Hansson <ulf.hansson at linaro.org>,
> >Ryan Chen <ryan_chen at aspeedtech.com>, "moderated list:ASPEED SD/MMC
> >DRIVER" <linux-aspeed at lists.ozlabs.org>, Andrew Jeffery
> ><andrew at aj.id.au>, "open list:ASPEED SD/MMC DRIVER"
> ><linux-mmc at vger.kernel.org>, "moderated list:ASPEED SD/MMC DRIVER"
> ><openbmc at lists.ozlabs.org>, Ryan Chen <ryanchen.aspeed at gmail.com>,
> >Adrian Hunter <adrian.hunter at intel.com>, open list
> ><linux-kernel at vger.kernel.org>, Chin-Ting Kuo
> ><chin-ting_kuo at aspeedtech.com>, "moderated list:ARM/ASPEED MACHINE
> >SUPPORT" <linux-arm-kernel at lists.infradead.org>
> >Subject: [EXTERNAL] Re: [PATCH v1 1/2] dt-bindings: mmc:
> >sdhci-of-aspeed: Add power-gpio and power-switch-gpio
> >
> >The 04/10/2021 02:41, Rob Herring wrote:
> >> On Thu, Apr 08, 2021 at 09:52:17AM +0800, Steven Lee wrote:
> >> > AST2600-A2 EVB provides the reference design for enabling SD bus
> >power
> >> > and toggling SD bus signal voltage by GPIO pins.
> >> > Add the definition and example for power-gpio and
> >power-switch-gpio
> >> > properties.
> >> > 
> >> > In the reference design, GPIOV0 of AST2600-A2 EVB is connected to
> >power
> >> > load switch that providing 3.3v to SD1 bus vdd. GPIOV1 is
> >connected to
> >> > a 1.8v and a 3.3v power load switch that providing signal voltage
> >to
> >> > SD1 bus.
> >> > If GPIOV0 is active high, SD1 bus is enabled. Otherwise, SD1 bus
> >is
> >> > disabled.
> >> > If GPIOV1 is active high, 3.3v power load switch is enabled, SD1
> >signal
> >> > voltage is 3.3v. Otherwise, 1.8v power load switch will be
> >enabled, SD1
> >> > signal voltage becomes 1.8v.
> >> > 
> >> > AST2600-A2 EVB also support toggling signal voltage for SD2 bus.
> >> > The design is the same as SD1 bus. It uses GPIOV2 as power-gpio
> >and GPIOV3
> >> > as power-switch-gpio.
> >> > 
> >> > Signed-off-by: Steven Lee <steven_lee at aspeedtech.com>
> >> > ---
> >> >  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 25
> >+++++++++++++++++++
> >> >  1 file changed, 25 insertions(+)
> >> > 
> >> > diff --git
> >a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> >b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> >> > index 987b287f3bff..515a74614f3c 100644
> >> > --- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> >> > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> >> > @@ -37,6 +37,14 @@ properties:
> >> >    clocks:
> >> >      maxItems: 1
> >> >      description: The SD/SDIO controller clock gate
> >> > +  power-gpio:
> >> 
> >> '-gpios' is the preferred form even if just 1.
> >> 
> >
> >Thanks for reviewing, I will change the name.
> 
> is this a clock gate or a power on gpio?
> 
> 

A power on gpio.

> >
> >> > +    description:
> >> > +      The GPIO for enabling/disabling SD bus power.
> >> > +    maxItems: 1
> >> 
> >> blank line
> >> 
> >
> >I will remove the blank line.
> >
> >> > +  power-switch-gpio:
> >> > +    description:
> >> > +      The GPIO for toggling the signal voltage between 3.3v and
> >1.8v.
> 
> Which way does it toggle for which voltage?
> 
> Oh, you said in the change log but not in the binding.
>

I will add description in the binding.

> But please, use gpio controled regulators as Ulf suggested and is
> already used by other mmc controllers upstream.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
> Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
> 

Thanks for reviewing and the information, I will use gpio-regulator
instead of power-gpio and power-switch-gpio.

> Ulf> Please do not model these as GPIO pins like this. Instead, it's better
> Ulf> to model them as gpio regulators, since the mmc core manages them as
> Ulf> regulators.
> Ulf> 
> Ulf> We have a vmmc regulator (corresponding to vdd) and a vqmmc regulator
> Ulf> (corresponding the signal-voltage level). These are also described in
> Ulf> the common mmc DT bindings, see
> Ulf> Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> Ulf> .
> 
> milton
> 
> >> > +    maxItems: 1
> >> >  
> >> >  patternProperties:
> >> >    "^sdhci@[0-9a-f]+$":
> >> > @@ -61,6 +69,14 @@ patternProperties:
> >> >        sdhci,auto-cmd12:
> >> >          type: boolean
> >> >          description: Specifies that controller should use auto
> >CMD12
> >> > +      power-gpio:
> >> > +        description:
> >> > +          The GPIO for enabling/disabling SD bus power.
> >> > +        maxItems: 1
> >> > +      power-switch-gpio:
> >> > +        description:
> >> > +          The GPIO for toggling the signal voltage between 3.3v
> >and 1.8v.
> >> > +        maxItems: 1
> >> >      required:
> >> >        - compatible
> >> >        - reg
> >> > @@ -80,6 +96,7 @@ required:
> >> >  examples:
> >> >    - |
> >> >      #include <dt-bindings/clock/aspeed-clock.h>
> >> > +    #include <dt-bindings/gpio/aspeed-gpio.h>
> >> >      sdc at 1e740000 {
> >> >              compatible = "aspeed,ast2500-sd-controller";
> >> >              reg = <0x1e740000 0x100>;
> >> > @@ -94,6 +111,10 @@ examples:
> >> >                      interrupts = <26>;
> >> >                      sdhci,auto-cmd12;
> >> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> >> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 0)
> >> > +                                     GPIO_ACTIVE_HIGH>;
> >> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V,
> >1)
> >> > +                                     GPIO_ACTIVE_HIGH>;
> >> >              };
> >> >  
> >> >              sdhci1: sdhci at 200 {
> >> > @@ -102,5 +123,9 @@ examples:
> >> >                      interrupts = <26>;
> >> >                      sdhci,auto-cmd12;
> >> >                      clocks = <&syscon ASPEED_CLK_SDIO>;
> >> > +                    power-gpio = <&gpio0 ASPEED_GPIO(V, 2)
> >> > +                                     GPIO_ACTIVE_HIGH>;
> >> > +                    power-switch-gpio = <&gpio0 ASPEED_GPIO(V,
> >3)
> >> > +                                     GPIO_ACTIVE_HIGH>;
> >> >              };
> >> >      };
> >> > -- 
> >> > 2.17.1
> >> > 
> >
> >
> 


From jiapeng.chong at linux.alibaba.com  Tue Apr 13 04:51:34 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Tue, 13 Apr 2021 11:51:34 +0800
Subject: [PATCH] fpga: xilinx-pr-decoupler: remove useless function
Message-ID: <1618285894-111432-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following gcc warning:

drivers/fpga/xilinx-pr-decoupler.c:32:19: warning: unused function
'xlnx_pr_decouple_read' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/fpga/xilinx-pr-decoupler.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/fpga/xilinx-pr-decoupler.c b/drivers/fpga/xilinx-pr-decoupler.c
index 7d69af2..f407cb2 100644
--- a/drivers/fpga/xilinx-pr-decoupler.c
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -29,12 +29,6 @@ static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data *d,
 	writel(val, d->io_base + offset);
 }
 
-static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,
-					u32 offset)
-{
-	return readl(d->io_base + offset);
-}
-
 static int xlnx_pr_decoupler_enable_set(struct fpga_bridge *bridge, bool enable)
 {
 	int err;
-- 
1.8.3.1



From yibin.gong at nxp.com  Tue Apr 13 06:05:20 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Tue, 13 Apr 2021 05:05:20 +0000
Subject: [PATCH v14 12/12] dmaengine: imx-sdma: add terminated list for
 freed descriptor in worker
In-Reply-To: <YHQVPoQAYVuHL3/S@vkoul-mobl.Dlink>
References: <1617809456-17693-1-git-send-email-yibin.gong@nxp.com>
 <1617809456-17693-13-git-send-email-yibin.gong@nxp.com>
 <YHQVPoQAYVuHL3/S@vkoul-mobl.Dlink>
Message-ID: <VE1PR04MB663877142BA90AADDF9B3AB3894F9@VE1PR04MB6638.eurprd04.prod.outlook.com>

On 2021/04/12 17:39,  Vinod Koul <vkoul at kernel.org>  wrote: 
> On 07-04-21, 23:30, Robin Gong wrote:
> > Add terminated list for keeping descriptor so that it could be freed
> > in worker without any potential involving next descriptor raised up
> > before this descriptor freed, because vchan_get_all_descriptors get
> > all descriptors including the last terminated descriptor and the next
> > descriptor, hence, the next descriptor maybe freed unexpectly when
> > it's done in worker without this patch.
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> spinics.net%2Flists%2Fdmaengine%2Fmsg23367.html&amp;data=04%7C01%
> 7Cyib
> >
> in.gong%40nxp.com%7Cf255f329c8de459ffbaf08d8fd96d6c5%7C686ea1d3bc
> 2b4c6
> >
> fa92cd99c5c301635%7C0%7C0%7C637538171591949442%7CUnknown%7CT
> WFpbGZsb3d
> >
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C
> >
> 1000&amp;sdata=3YFgzHFDNwRnogvxZpNcwVKOKpk4GHrgScdrbuMKjwE%3D
> &amp;rese
> > rved=0
> 
> Sound like you should implement .device_synchronize() and do the actual
> work there..?
Yes,  I believe no issue here if call dmaengine_terminate_sync() always since
flush_work(&sdmac->terminate_worker) has already been in  .device_synchronize() of
sdma driver. But unfortunately, have to use dmaengine_terminate_all() instead in some
non-atomic case like ALSA.




From vee.khee.wong at linux.intel.com  Tue Apr 13 06:07:43 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Tue, 13 Apr 2021 13:07:43 +0800
Subject: [PATCH net-next v3 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210411151055.GA5719@hoboy.vegasvil.org>
References: <20210411024028.14586-1-vee.khee.wong@linux.intel.com>
 <20210411151055.GA5719@hoboy.vegasvil.org>
Message-ID: <20210413050743.GA10274@linux.intel.com>

On Sun, Apr 11, 2021 at 08:10:55AM -0700, Richard Cochran wrote:
> On Sun, Apr 11, 2021 at 10:40:28AM +0800, Wong Vee Khee wrote:
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> > index 60566598d644..60e17fd24aba 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> > @@ -296,6 +296,13 @@ static int intel_crosststamp(ktime_t *device,
> >  
> >  	intel_priv = priv->plat->bsp_priv;
> >  
> > +	/* Both internal crosstimestamping and external triggered event
> > +	 * timestamping cannot be run concurrently.
> > +	 */
> > +	if (priv->plat->ext_snapshot_en)
> > +		return -EBUSY;
> > +
> > +	mutex_lock(&priv->aux_ts_lock);
> 
> Lock, then ...
> 
> >  	/* Enable Internal snapshot trigger */
> >  	acr_value = readl(ptpaddr + PTP_ACR);
> >  	acr_value &= ~PTP_ACR_MASK;
> > @@ -321,6 +328,7 @@ static int intel_crosststamp(ktime_t *device,
> >  	acr_value = readl(ptpaddr + PTP_ACR);
> >  	acr_value |= PTP_ACR_ATSFC;
> >  	writel(acr_value, ptpaddr + PTP_ACR);
> > +	mutex_unlock(&priv->aux_ts_lock);
> 
> unlock, then ...
>   
> >  	/* Trigger Internal snapshot signal
> >  	 * Create a rising edge by just toggle the GPO1 to low
> > @@ -355,6 +363,8 @@ static int intel_crosststamp(ktime_t *device,
> >  		*system = convert_art_to_tsc(art_time);
> >  	}
> >  
> > +	/* Release the mutex */
> > +	mutex_unlock(&priv->aux_ts_lock);
> 
> unlock again?  Huh?
>

Nice catch. Fix in v4.
 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> > index c49debb62b05..abadcd8cdc41 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> > @@ -239,6 +239,9 @@ struct stmmac_priv {
> >  	int use_riwt;
> >  	int irq_wake;
> >  	spinlock_t ptp_lock;
> > +	/* Mutex lock for Auxiliary Snapshots */
> > +	struct mutex aux_ts_lock;
> 
> In the comment, please be specific about which data are protected.
> For example:
> 
> 	/* Protects auxiliary snapshot registers from concurrent access. */
> 
> > @@ -163,6 +166,43 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
> >  	*ptp_time = ns;
> >  }
> >  
> > +static void timestamp_interrupt(struct stmmac_priv *priv)
> > +{
> > +	struct ptp_clock_event event;
> > +	unsigned long flags;
> > +	u32 num_snapshot;
> > +	u32 ts_status;
> > +	u32 tsync_int;
> 
> Please group same types together (u32) in a one-line list.
> 
> > +	u64 ptp_time;
> > +	int i;
> > +
> > +	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
> > +
> > +	if (!tsync_int)
> > +		return;
> > +
> > +	/* Read timestamp status to clear interrupt from either external
> > +	 * timestamp or start/end of PPS.
> > +	 */
> > +	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
> 
> Reading this register has a side effect of clearing status?  If so,
> doesn't it need protection against concurrent access?
> 
> The function, intel_crosststamp() also reads this bit.
>

The following check is introduced in intel_crosststamp() to avoid this:

/* Both internal crosstimestamping and external triggered event
 * timestamping cannot be run concurrently.
 */
 if (priv->plat->ext_snapshot_en)
	return -EBUSY;

 
> > +	if (!priv->plat->ext_snapshot_en)
> > +		return;
> 
> Doesn't this test come too late?  Setting ts_status just cleared the
> bit used by the other code path.
>

As per Synopsys's design, all bits except Bits[27:25] gets cleared when
this register is read.

> > +	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
> > +		       GMAC_TIMESTAMP_ATSNS_SHIFT;
> > +
> > +	for (i = 0; i < num_snapshot; i++) {
> > +		spin_lock_irqsave(&priv->ptp_lock, flags);
> > +		get_ptptime(priv->ptpaddr, &ptp_time);
> > +		spin_unlock_irqrestore(&priv->ptp_lock, flags);
> > +		event.type = PTP_CLOCK_EXTTS;
> > +		event.index = 0;
> > +		event.timestamp = ptp_time;
> > +		ptp_clock_event(priv->ptp_clock, &event);
> > +	}
> > +}
> > +
> 
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> > index b164ae22e35f..d668c33a0746 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
> > @@ -135,9 +135,13 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
> >  {
> >  	struct stmmac_priv *priv =
> >  	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
> > +	void __iomem *ptpaddr = priv->ptpaddr;
> > +	void __iomem *ioaddr = priv->hw->pcsr;
> >  	struct stmmac_pps_cfg *cfg;
> >  	int ret = -EOPNOTSUPP;
> >  	unsigned long flags;
> > +	u32 intr_value;
> > +	u32 acr_value;
> 
> Please group same types together.
>

Fix in v4.
 
> Thanks,
> Richard


From dvyukov at google.com  Tue Apr 13 06:14:07 2021
From: dvyukov at google.com (Dmitry Vyukov)
Date: Tue, 13 Apr 2021 07:14:07 +0200
Subject: [syzbot] upstream boot error: WARNING in __context_tracking_enter
In-Reply-To: <20210322172241.GB80352@C02TD0UTHF1T.local>
References: <0000000000004f14c105bde08f75@google.com>
 <CACT4Y+bLkFSc8manYrCukj-_nzwVsV9y6xYWXmGyYFS-PoBRPQ@mail.gmail.com>
 <20210319101043.GU1463@shell.armlinux.org.uk>
 <20210322172241.GB80352@C02TD0UTHF1T.local>
Message-ID: <CACT4Y+ZaFKB6xd9BiPjYsE+13GJb3d_4aRTkB8xrNMaexpLaFA@mail.gmail.com>

On Mon, Mar 22, 2021 at 6:22 PM Mark Rutland <mark.rutland at arm.com> wrote:
>
> Hi Russell,
>
> On Fri, Mar 19, 2021 at 10:10:43AM +0000, Russell King - ARM Linux admin wrote:
> > On Fri, Mar 19, 2021 at 10:54:48AM +0100, Dmitry Vyukov wrote:
> > > .On Fri, Mar 19, 2021 at 10:44 AM syzbot
> > > <syzbot+f09a12b2c77bfbbf51bd at syzkaller.appspotmail.com> wrote:
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    8b12a62a Merge tag 'drm-fixes-2021-03-19' of git://anongit..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=17e815aed00000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=cfeed364fc353c32
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=f09a12b2c77bfbbf51bd
> > > > userspace arch: arm
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+f09a12b2c77bfbbf51bd at syzkaller.appspotmail.com
> > >
> > >
> > > +Mark, arm
> > > It did not get far with CONFIG_CONTEXT_TRACKING_FORCE (kernel doesn't boot).
> >
> > It seems that the path:
> >
> > context_tracking_user_enter()
> > user_enter()
> > context_tracking_enter()
> > __context_tracking_enter()
> > vtime_user_enter()
> >
> > expects preemption to be disabled. It effectively is, because local
> > interrupts are disabled by context_tracking_enter().
> >
> > However, the requirement for preemption to be disabled is not
> > documented... so shrug. Maybe someone can say what the real requirements
> > are here.
>
> From dealing with this recently on arm64, theis is a bit messy. To
> handle this robustly we need to do a few things in sequence, including
> using the *_irqoff() variants of the context_tracking_user_*()
> functions.
>
> I wrote down the constraints in commit:
>
>   23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
>
> For user->kernel transitions, the arch code needs the following sequence
> before invoking arbitrary kernel C code:
>
>         lockdep_hardirqs_off(CALLER_ADDR0);
>         user_exit_irqoff();
>         trace_hardirqs_off_finish();
>
> For kernel->user transitions, the arch code needs the following sequence
> once it will no longer invoke arbitrary kernel C code, just before
> returning to userspace:
>
>         trace_hardirqs_on_prepare();
>         lockdep_hardirqs_on_prepare(CALLER_ADDR0);
>         user_enter_irqoff();
>         lockdep_hardirqs_on(CALLER_ADDR0);

Hi Russell,

Does Mark's comment make sense to you?
lockdep_assert_preemption_disabled() also checks "&&
this_cpu_read(hardirqs_enabled)", so is it that we also need hardirq's
disabled around user_enter/exit?
This issue currently prevents ARM boot on syzbot.


From zhiyong.tao at mediatek.com  Tue Apr 13 06:57:01 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Tue, 13 Apr 2021 13:57:01 +0800
Subject: [PATCH v4 3/4] pinctrl: add drive for I2C related pins on MT8195
In-Reply-To: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
Message-ID: <20210413055702.27535-4-zhiyong.tao@mediatek.com>

This patch provides the advanced drive raw data setting version
for I2C used pins on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |  5 +++++
 3 files changed, 41 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index 063f164d7c9b..a7500e18bb1d 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -760,6 +760,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_range[] = {
 	PIN_FIELD_BASE(143, 143, 1, 0x020, 0x10, 24, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x020, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x020, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x020, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x020, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x020, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x020, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x020, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x020, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x020, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x020, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x020, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x020, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x040, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x040, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x040, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -773,6 +792,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8195_pin_pupd_range),
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
+	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -801,6 +821,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.bias_get_combo = mtk_pinconf_bias_get_combo,
 	.drive_set = mtk_pinconf_drive_set_rev1,
 	.drive_get = mtk_pinconf_drive_get_rev1,
+	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
+	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 72f17f26acd8..2b51f4a9b860 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1027,6 +1027,20 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get);
 
+int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_set_raw);
+
+int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index e2aae285b5fc..fd5ce9c5dcbd 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -66,6 +66,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_EN,
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
+	PINCTRL_PIN_REG_DRV_ADV,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -314,6 +315,10 @@ int mtk_pinconf_adv_drive_set(struct mtk_pinctrl *hw,
 			      const struct mtk_pin_desc *desc, u32 arg);
 int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
 			      const struct mtk_pin_desc *desc, u32 *val);
+int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
+				  const struct mtk_pin_desc *desc, u32 *val);
 
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
-- 
2.18.0

From zhiyong.tao at mediatek.com  Tue Apr 13 06:56:58 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Tue, 13 Apr 2021 13:56:58 +0800
Subject: [PATCH v4 0/4] Mediatek pinctrl patch on mt8195 
Message-ID: <20210413055702.27535-1-zhiyong.tao@mediatek.com>

This series includes 4 patches:
1.add pinctrl file and inding document on mt8195.
2.add pinctrl driver on MT8195.
3.add pinctrl drive for I2C related pins on MT8195.
4.add pinctrl rsel setting on MT8195.

Changes in patch v4:
1)fix pinctrl-mt8195.yaml warning error.
2)remove pinctrl device node patch which is based on "mt8195.dtsi".

Changes in patch v3:
1)change '^pins' to '-pins$'.
2)change 'state_0_node_a' to 'gpio_pin' which is defined in dts.
3)change 'state_0_node_b' to 'i2c0_pin' which is defined in dts.
4)reorder this series patches. change pinctrl file and binding document
together in one patch.

There are no changes in v1 & v2.

Zhiyong Tao (4):
  dt-bindings: pinctrl: mt8195: add pinctrl file and binding document
  pinctrl: add pinctrl driver on mt8195
  pinctrl: add drive for I2C related pins on MT8195
  pinctrl: add rsel setting on MT8195

 .../bindings/pinctrl/pinctrl-mt8195.yaml      |  151 ++
 drivers/pinctrl/mediatek/Kconfig              |    6 +
 drivers/pinctrl/mediatek/Makefile             |    1 +
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     |  872 +++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  |   28 +
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |   15 +
 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h | 1669 +++++++++++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      |   16 +
 include/dt-bindings/pinctrl/mt8195-pinfunc.h  |  962 ++++++++++
 9 files changed, 3720 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8195.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
 create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.h

--
2.18.0


From zhiyong.tao at mediatek.com  Tue Apr 13 06:56:59 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Tue, 13 Apr 2021 13:56:59 +0800
Subject: [PATCH v4 1/4] dt-bindings: pinctrl: mt8195: add pinctrl file and
 binding document
In-Reply-To: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
Message-ID: <20210413055702.27535-2-zhiyong.tao@mediatek.com>

1. This patch adds pinctrl file for mt8195.
2. This patch adds mt8195 compatible node in binding document.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 .../bindings/pinctrl/pinctrl-mt8195.yaml      | 151 +++
 include/dt-bindings/pinctrl/mt8195-pinfunc.h  | 962 ++++++++++++++++++
 2 files changed, 1113 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
 create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
new file mode 100644
index 000000000000..2f12ec59eee5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
@@ -0,0 +1,151 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8195.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek MT8195 Pin Controller
+
+maintainers:
+  - Sean Wang <sean.wang at mediatek.com>
+
+description: |
+  The Mediatek's Pin controller is used to control SoC pins.
+
+properties:
+  compatible:
+    const: mediatek,mt8195-pinctrl
+
+  gpio-controller: true
+
+  '#gpio-cells':
+    description: |
+      Number of cells in GPIO specifier. Since the generic GPIO binding is used,
+      the amount of cells must be specified as 2. See the below
+      mentioned gpio binding representation for description of particular cells.
+    const: 2
+
+  gpio-ranges:
+    description: gpio valid number range.
+    maxItems: 1
+
+  reg:
+    description: |
+      Physical address base for gpio base registers. There are 8 GPIO
+      physical address base in mt8195.
+    maxItems: 8
+
+  reg-names:
+    description: |
+      Gpio base register names.
+    maxItems: 8
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+    const: 2
+
+  interrupts:
+    description: The interrupt outputs to sysirq.
+    maxItems: 1
+
+#PIN CONFIGURATION NODES
+patternProperties:
+  '-pins$':
+    type: object
+    description: |
+      A pinctrl node should contain at least one subnodes representing the
+      pinctrl groups available on the machine. Each subnode will list the
+      pins it needs, and how they should be configured, with regard to muxer
+      configuration, pullups, drive strength, input enable/disable and
+      input schmitt.
+      An example of using macro:
+      pincontroller {
+        /* GPIO0 set as multifunction GPIO0 */
+        gpio_pin {
+          pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+        };
+        /* GPIO8 set as multifunction SDA0 */
+        i2c0_pin {
+          pinmux = <PINMUX_GPIO8__FUNC_SDA0>;
+        };
+      };
+    $ref: "pinmux-node.yaml"
+
+    properties:
+      pinmux:
+        description: |
+          Integer array, represents gpio pin number and mux setting.
+          Supported pin number and mux varies for different SoCs, and are defined
+          as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+
+      drive-strength:
+        description: |
+          It can support some arguments which is from 0 to 7. It can only support
+          2/4/6/8/10/12/14/16mA in mt8195.
+        enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+      bias-pull-down: true
+
+      bias-pull-up: true
+
+      bias-disable: true
+
+      output-high: true
+
+      output-low: true
+
+      input-enable: true
+
+      input-disable: true
+
+      input-schmitt-enable: true
+
+      input-schmitt-disable: true
+
+    required:
+      - pinmux
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - interrupt-controller
+  - '#interrupt-cells'
+  - gpio-controller
+  - '#gpio-cells'
+  - gpio-ranges
+
+additionalProperties: false
+
+examples:
+  - |
+            #include <dt-bindings/pinctrl/mt8195-pinfunc.h>
+            #include <dt-bindings/interrupt-controller/arm-gic.h>
+            pio: pinctrl at 10005000 {
+                    compatible = "mediatek,mt8195-pinctrl";
+                    reg = <0x10005000 0x1000>,
+                          <0x11d10000 0x1000>,
+                          <0x11d30000 0x1000>,
+                          <0x11d40000 0x1000>,
+                          <0x11e20000 0x1000>,
+                          <0x11eb0000 0x1000>,
+                          <0x11f40000 0x1000>,
+                          <0x1000b000 0x1000>;
+                    reg-names = "iocfg0", "iocfg_bm", "iocfg_bl",
+                          "iocfg_br", "iocfg_lm", "iocfg_rb",
+                          "iocfg_tl", "eint";
+                    gpio-controller;
+                    #gpio-cells = <2>;
+                    gpio-ranges = <&pio 0 0 144>;
+                    interrupt-controller;
+                    interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>;
+                    #interrupt-cells = <2>;
+
+                    pio-pins {
+                      pinmux = <PINMUX_GPIO0__FUNC_GPIO0>;
+                      output-low;
+                    };
+            };
diff --git a/include/dt-bindings/pinctrl/mt8195-pinfunc.h b/include/dt-bindings/pinctrl/mt8195-pinfunc.h
new file mode 100644
index 000000000000..666331bb9b40
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt8195-pinfunc.h
@@ -0,0 +1,962 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ * Author: Zhiyong Tao <zhiyong.tao at mediatek.com>
+ */
+
+#ifndef __MT8195_PINFUNC_H
+#define __MT8195_PINFUNC_H
+
+#include "mt65xx.h"
+
+#define PINMUX_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define PINMUX_GPIO0__FUNC_TP_GPIO0_AO (MTK_PIN_NO(0) | 1)
+#define PINMUX_GPIO0__FUNC_MSDC2_CMD (MTK_PIN_NO(0) | 2)
+#define PINMUX_GPIO0__FUNC_TDMIN_MCK (MTK_PIN_NO(0) | 3)
+#define PINMUX_GPIO0__FUNC_CLKM0 (MTK_PIN_NO(0) | 4)
+#define PINMUX_GPIO0__FUNC_PERSTN_1 (MTK_PIN_NO(0) | 5)
+#define PINMUX_GPIO0__FUNC_IDDIG_1P (MTK_PIN_NO(0) | 6)
+#define PINMUX_GPIO0__FUNC_DMIC4_CLK (MTK_PIN_NO(0) | 7)
+
+#define PINMUX_GPIO1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define PINMUX_GPIO1__FUNC_TP_GPIO1_AO (MTK_PIN_NO(1) | 1)
+#define PINMUX_GPIO1__FUNC_MSDC2_CLK (MTK_PIN_NO(1) | 2)
+#define PINMUX_GPIO1__FUNC_TDMIN_DI (MTK_PIN_NO(1) | 3)
+#define PINMUX_GPIO1__FUNC_CLKM1 (MTK_PIN_NO(1) | 4)
+#define PINMUX_GPIO1__FUNC_CLKREQN_1 (MTK_PIN_NO(1) | 5)
+#define PINMUX_GPIO1__FUNC_USB_DRVVBUS_1P (MTK_PIN_NO(1) | 6)
+#define PINMUX_GPIO1__FUNC_DMIC4_DAT (MTK_PIN_NO(1) | 7)
+
+#define PINMUX_GPIO2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define PINMUX_GPIO2__FUNC_TP_GPIO2_AO (MTK_PIN_NO(2) | 1)
+#define PINMUX_GPIO2__FUNC_MSDC2_DAT3 (MTK_PIN_NO(2) | 2)
+#define PINMUX_GPIO2__FUNC_TDMIN_LRCK (MTK_PIN_NO(2) | 3)
+#define PINMUX_GPIO2__FUNC_CLKM2 (MTK_PIN_NO(2) | 4)
+#define PINMUX_GPIO2__FUNC_WAKEN_1 (MTK_PIN_NO(2) | 5)
+#define PINMUX_GPIO2__FUNC_DMIC2_CLK (MTK_PIN_NO(2) | 7)
+
+#define PINMUX_GPIO3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define PINMUX_GPIO3__FUNC_TP_GPIO3_AO (MTK_PIN_NO(3) | 1)
+#define PINMUX_GPIO3__FUNC_MSDC2_DAT0 (MTK_PIN_NO(3) | 2)
+#define PINMUX_GPIO3__FUNC_TDMIN_BCK (MTK_PIN_NO(3) | 3)
+#define PINMUX_GPIO3__FUNC_CLKM3 (MTK_PIN_NO(3) | 4)
+#define PINMUX_GPIO3__FUNC_DMIC2_DAT (MTK_PIN_NO(3) | 7)
+
+#define PINMUX_GPIO4__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define PINMUX_GPIO4__FUNC_TP_GPIO4_AO (MTK_PIN_NO(4) | 1)
+#define PINMUX_GPIO4__FUNC_MSDC2_DAT2 (MTK_PIN_NO(4) | 2)
+#define PINMUX_GPIO4__FUNC_SPDIF_IN1 (MTK_PIN_NO(4) | 3)
+#define PINMUX_GPIO4__FUNC_UTXD3 (MTK_PIN_NO(4) | 4)
+#define PINMUX_GPIO4__FUNC_SDA2 (MTK_PIN_NO(4) | 5)
+#define PINMUX_GPIO4__FUNC_IDDIG_2P (MTK_PIN_NO(4) | 7)
+
+#define PINMUX_GPIO5__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define PINMUX_GPIO5__FUNC_TP_GPIO5_AO (MTK_PIN_NO(5) | 1)
+#define PINMUX_GPIO5__FUNC_MSDC2_DAT1 (MTK_PIN_NO(5) | 2)
+#define PINMUX_GPIO5__FUNC_SPDIF_IN0 (MTK_PIN_NO(5) | 3)
+#define PINMUX_GPIO5__FUNC_URXD3 (MTK_PIN_NO(5) | 4)
+#define PINMUX_GPIO5__FUNC_SCL2 (MTK_PIN_NO(5) | 5)
+#define PINMUX_GPIO5__FUNC_USB_DRVVBUS_2P (MTK_PIN_NO(5) | 7)
+
+#define PINMUX_GPIO6__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define PINMUX_GPIO6__FUNC_TP_GPIO6_AO (MTK_PIN_NO(6) | 1)
+#define PINMUX_GPIO6__FUNC_DP_TX_HPD (MTK_PIN_NO(6) | 2)
+#define PINMUX_GPIO6__FUNC_I2SO1_D4 (MTK_PIN_NO(6) | 3)
+#define PINMUX_GPIO6__FUNC_UTXD4 (MTK_PIN_NO(6) | 4)
+#define PINMUX_GPIO6__FUNC_CMVREF3 (MTK_PIN_NO(6) | 5)
+#define PINMUX_GPIO6__FUNC_DMIC3_CLK (MTK_PIN_NO(6) | 7)
+
+#define PINMUX_GPIO7__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define PINMUX_GPIO7__FUNC_TP_GPIO7_AO (MTK_PIN_NO(7) | 1)
+#define PINMUX_GPIO7__FUNC_EDP_TX_HPD (MTK_PIN_NO(7) | 2)
+#define PINMUX_GPIO7__FUNC_I2SO1_D5 (MTK_PIN_NO(7) | 3)
+#define PINMUX_GPIO7__FUNC_URXD4 (MTK_PIN_NO(7) | 4)
+#define PINMUX_GPIO7__FUNC_CMVREF4 (MTK_PIN_NO(7) | 5)
+#define PINMUX_GPIO7__FUNC_DMIC3_DAT (MTK_PIN_NO(7) | 7)
+
+#define PINMUX_GPIO8__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define PINMUX_GPIO8__FUNC_SDA0 (MTK_PIN_NO(8) | 1)
+#define PINMUX_GPIO8__FUNC_PWM_0 (MTK_PIN_NO(8) | 2)
+#define PINMUX_GPIO8__FUNC_SPDIF_OUT (MTK_PIN_NO(8) | 4)
+#define PINMUX_GPIO8__FUNC_LVTS_FOUT (MTK_PIN_NO(8) | 6)
+#define PINMUX_GPIO8__FUNC_DBG_MON_A0 (MTK_PIN_NO(8) | 7)
+
+#define PINMUX_GPIO9__FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define PINMUX_GPIO9__FUNC_SCL0 (MTK_PIN_NO(9) | 1)
+#define PINMUX_GPIO9__FUNC_PWM_1 (MTK_PIN_NO(9) | 2)
+#define PINMUX_GPIO9__FUNC_IR_IN (MTK_PIN_NO(9) | 4)
+#define PINMUX_GPIO9__FUNC_LVTS_SDO (MTK_PIN_NO(9) | 6)
+#define PINMUX_GPIO9__FUNC_DBG_MON_A1 (MTK_PIN_NO(9) | 7)
+
+#define PINMUX_GPIO10__FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define PINMUX_GPIO10__FUNC_SDA1 (MTK_PIN_NO(10) | 1)
+#define PINMUX_GPIO10__FUNC_PWM_2 (MTK_PIN_NO(10) | 2)
+#define PINMUX_GPIO10__FUNC_ADSP_URXD0 (MTK_PIN_NO(10) | 3)
+#define PINMUX_GPIO10__FUNC_SPDIF_IN1 (MTK_PIN_NO(10) | 4)
+#define PINMUX_GPIO10__FUNC_LVTS_SCF (MTK_PIN_NO(10) | 6)
+#define PINMUX_GPIO10__FUNC_DBG_MON_A2 (MTK_PIN_NO(10) | 7)
+
+#define PINMUX_GPIO11__FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define PINMUX_GPIO11__FUNC_SCL1 (MTK_PIN_NO(11) | 1)
+#define PINMUX_GPIO11__FUNC_PWM_3 (MTK_PIN_NO(11) | 2)
+#define PINMUX_GPIO11__FUNC_ADSP_UTXD0 (MTK_PIN_NO(11) | 3)
+#define PINMUX_GPIO11__FUNC_SPDIF_IN0 (MTK_PIN_NO(11) | 4)
+#define PINMUX_GPIO11__FUNC_LVTS_SCK (MTK_PIN_NO(11) | 6)
+#define PINMUX_GPIO11__FUNC_DBG_MON_A3 (MTK_PIN_NO(11) | 7)
+
+#define PINMUX_GPIO12__FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define PINMUX_GPIO12__FUNC_SDA2 (MTK_PIN_NO(12) | 1)
+#define PINMUX_GPIO12__FUNC_DMIC3_DAT_R (MTK_PIN_NO(12) | 2)
+#define PINMUX_GPIO12__FUNC_I2SO1_D6 (MTK_PIN_NO(12) | 3)
+#define PINMUX_GPIO12__FUNC_LVTS_SDI (MTK_PIN_NO(12) | 6)
+#define PINMUX_GPIO12__FUNC_DBG_MON_A4 (MTK_PIN_NO(12) | 7)
+
+#define PINMUX_GPIO13__FUNC_GPIO13 (MTK_PIN_NO(13) | 0)
+#define PINMUX_GPIO13__FUNC_SCL2 (MTK_PIN_NO(13) | 1)
+#define PINMUX_GPIO13__FUNC_DMIC4_DAT_R (MTK_PIN_NO(13) | 2)
+#define PINMUX_GPIO13__FUNC_I2SO1_D7 (MTK_PIN_NO(13) | 3)
+#define PINMUX_GPIO13__FUNC_DBG_MON_A5 (MTK_PIN_NO(13) | 7)
+
+#define PINMUX_GPIO14__FUNC_GPIO14 (MTK_PIN_NO(14) | 0)
+#define PINMUX_GPIO14__FUNC_SDA3 (MTK_PIN_NO(14) | 1)
+#define PINMUX_GPIO14__FUNC_DMIC3_DAT (MTK_PIN_NO(14) | 2)
+#define PINMUX_GPIO14__FUNC_TDMIN_MCK (MTK_PIN_NO(14) | 3)
+#define PINMUX_GPIO14__FUNC_DBG_MON_A6 (MTK_PIN_NO(14) | 7)
+
+#define PINMUX_GPIO15__FUNC_GPIO15 (MTK_PIN_NO(15) | 0)
+#define PINMUX_GPIO15__FUNC_SCL3 (MTK_PIN_NO(15) | 1)
+#define PINMUX_GPIO15__FUNC_DMIC3_CLK (MTK_PIN_NO(15) | 2)
+#define PINMUX_GPIO15__FUNC_TDMIN_DI (MTK_PIN_NO(15) | 3)
+#define PINMUX_GPIO15__FUNC_DBG_MON_A7 (MTK_PIN_NO(15) | 7)
+
+#define PINMUX_GPIO16__FUNC_GPIO16 (MTK_PIN_NO(16) | 0)
+#define PINMUX_GPIO16__FUNC_SDA4 (MTK_PIN_NO(16) | 1)
+#define PINMUX_GPIO16__FUNC_DMIC4_DAT (MTK_PIN_NO(16) | 2)
+#define PINMUX_GPIO16__FUNC_TDMIN_LRCK (MTK_PIN_NO(16) | 3)
+#define PINMUX_GPIO16__FUNC_DBG_MON_A8 (MTK_PIN_NO(16) | 7)
+
+#define PINMUX_GPIO17__FUNC_GPIO17 (MTK_PIN_NO(17) | 0)
+#define PINMUX_GPIO17__FUNC_SCL4 (MTK_PIN_NO(17) | 1)
+#define PINMUX_GPIO17__FUNC_DMIC4_CLK (MTK_PIN_NO(17) | 2)
+#define PINMUX_GPIO17__FUNC_TDMIN_BCK (MTK_PIN_NO(17) | 3)
+#define PINMUX_GPIO17__FUNC_DBG_MON_A9 (MTK_PIN_NO(17) | 7)
+
+#define PINMUX_GPIO18__FUNC_GPIO18 (MTK_PIN_NO(18) | 0)
+#define PINMUX_GPIO18__FUNC_DP_TX_HPD (MTK_PIN_NO(18) | 1)
+
+#define PINMUX_GPIO19__FUNC_GPIO19 (MTK_PIN_NO(19) | 0)
+#define PINMUX_GPIO19__FUNC_WAKEN (MTK_PIN_NO(19) | 1)
+#define PINMUX_GPIO19__FUNC_SCP_SDA1 (MTK_PIN_NO(19) | 2)
+#define PINMUX_GPIO19__FUNC_MD32_0_JTAG_TCK (MTK_PIN_NO(19) | 3)
+#define PINMUX_GPIO19__FUNC_ADSP_JTAG0_TCK (MTK_PIN_NO(19) | 4)
+#define PINMUX_GPIO19__FUNC_SDA6 (MTK_PIN_NO(19) | 5)
+
+#define PINMUX_GPIO20__FUNC_GPIO20 (MTK_PIN_NO(20) | 0)
+#define PINMUX_GPIO20__FUNC_PERSTN (MTK_PIN_NO(20) | 1)
+#define PINMUX_GPIO20__FUNC_SCP_SCL1 (MTK_PIN_NO(20) | 2)
+#define PINMUX_GPIO20__FUNC_MD32_0_JTAG_TMS (MTK_PIN_NO(20) | 3)
+#define PINMUX_GPIO20__FUNC_ADSP_JTAG0_TMS (MTK_PIN_NO(20) | 4)
+#define PINMUX_GPIO20__FUNC_SCL6 (MTK_PIN_NO(20) | 5)
+
+#define PINMUX_GPIO21__FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
+#define PINMUX_GPIO21__FUNC_CLKREQN (MTK_PIN_NO(21) | 1)
+#define PINMUX_GPIO21__FUNC_MD32_0_JTAG_TDI (MTK_PIN_NO(21) | 3)
+#define PINMUX_GPIO21__FUNC_ADSP_JTAG0_TDI (MTK_PIN_NO(21) | 4)
+#define PINMUX_GPIO21__FUNC_SCP_SDA1 (MTK_PIN_NO(21) | 5)
+
+#define PINMUX_GPIO22__FUNC_GPIO22 (MTK_PIN_NO(22) | 0)
+#define PINMUX_GPIO22__FUNC_CMMCLK0 (MTK_PIN_NO(22) | 1)
+#define PINMUX_GPIO22__FUNC_PERSTN_1 (MTK_PIN_NO(22) | 2)
+#define PINMUX_GPIO22__FUNC_SCP_SCL1 (MTK_PIN_NO(22) | 5)
+#define PINMUX_GPIO22__FUNC_MD32_0_GPIO0 (MTK_PIN_NO(22) | 7)
+
+#define PINMUX_GPIO23__FUNC_GPIO23 (MTK_PIN_NO(23) | 0)
+#define PINMUX_GPIO23__FUNC_CMMCLK1 (MTK_PIN_NO(23) | 1)
+#define PINMUX_GPIO23__FUNC_CLKREQN_1 (MTK_PIN_NO(23) | 2)
+#define PINMUX_GPIO23__FUNC_SDA4 (MTK_PIN_NO(23) | 3)
+#define PINMUX_GPIO23__FUNC_DMIC1_CLK (MTK_PIN_NO(23) | 4)
+#define PINMUX_GPIO23__FUNC_SCP_SDA0 (MTK_PIN_NO(23) | 5)
+#define PINMUX_GPIO23__FUNC_MD32_0_GPIO1 (MTK_PIN_NO(23) | 7)
+
+#define PINMUX_GPIO24__FUNC_GPIO24 (MTK_PIN_NO(24) | 0)
+#define PINMUX_GPIO24__FUNC_CMMCLK2 (MTK_PIN_NO(24) | 1)
+#define PINMUX_GPIO24__FUNC_WAKEN_1 (MTK_PIN_NO(24) | 2)
+#define PINMUX_GPIO24__FUNC_SCL4 (MTK_PIN_NO(24) | 3)
+#define PINMUX_GPIO24__FUNC_DMIC1_DAT (MTK_PIN_NO(24) | 4)
+#define PINMUX_GPIO24__FUNC_SCP_SCL0 (MTK_PIN_NO(24) | 5)
+#define PINMUX_GPIO24__FUNC_LVTS_26M (MTK_PIN_NO(24) | 6)
+#define PINMUX_GPIO24__FUNC_MD32_0_GPIO2 (MTK_PIN_NO(24) | 7)
+
+#define PINMUX_GPIO25__FUNC_GPIO25 (MTK_PIN_NO(25) | 0)
+#define PINMUX_GPIO25__FUNC_CMMRST (MTK_PIN_NO(25) | 1)
+#define PINMUX_GPIO25__FUNC_CMMCLK3 (MTK_PIN_NO(25) | 2)
+#define PINMUX_GPIO25__FUNC_SPDIF_OUT (MTK_PIN_NO(25) | 3)
+#define PINMUX_GPIO25__FUNC_SDA6 (MTK_PIN_NO(25) | 4)
+#define PINMUX_GPIO25__FUNC_ADSP_JTAG0_TRSTN (MTK_PIN_NO(25) | 5)
+#define PINMUX_GPIO25__FUNC_MD32_0_JTAG_TRST (MTK_PIN_NO(25) | 6)
+
+#define PINMUX_GPIO26__FUNC_GPIO26 (MTK_PIN_NO(26) | 0)
+#define PINMUX_GPIO26__FUNC_CMMPDN (MTK_PIN_NO(26) | 1)
+#define PINMUX_GPIO26__FUNC_CMMCLK4 (MTK_PIN_NO(26) | 2)
+#define PINMUX_GPIO26__FUNC_IR_IN (MTK_PIN_NO(26) | 3)
+#define PINMUX_GPIO26__FUNC_SCL6 (MTK_PIN_NO(26) | 4)
+#define PINMUX_GPIO26__FUNC_ADSP_JTAG0_TDO (MTK_PIN_NO(26) | 5)
+#define PINMUX_GPIO26__FUNC_MD32_0_JTAG_TDO (MTK_PIN_NO(26) | 6)
+
+#define PINMUX_GPIO27__FUNC_GPIO27 (MTK_PIN_NO(27) | 0)
+#define PINMUX_GPIO27__FUNC_HDMIRX20_HTPLG (MTK_PIN_NO(27) | 1)
+#define PINMUX_GPIO27__FUNC_CMFLASH0 (MTK_PIN_NO(27) | 2)
+#define PINMUX_GPIO27__FUNC_MD32_0_TXD (MTK_PIN_NO(27) | 3)
+#define PINMUX_GPIO27__FUNC_TP_UTXD2_AO (MTK_PIN_NO(27) | 4)
+#define PINMUX_GPIO27__FUNC_SCL7 (MTK_PIN_NO(27) | 5)
+#define PINMUX_GPIO27__FUNC_UCTS2 (MTK_PIN_NO(27) | 6)
+#define PINMUX_GPIO27__FUNC_DBG_MON_A18 (MTK_PIN_NO(27) | 7)
+
+#define PINMUX_GPIO28__FUNC_GPIO28 (MTK_PIN_NO(28) | 0)
+#define PINMUX_GPIO28__FUNC_HDMIRX20_PWR5V (MTK_PIN_NO(28) | 1)
+#define PINMUX_GPIO28__FUNC_CMFLASH1 (MTK_PIN_NO(28) | 2)
+#define PINMUX_GPIO28__FUNC_MD32_0_RXD (MTK_PIN_NO(28) | 3)
+#define PINMUX_GPIO28__FUNC_TP_URXD2_AO (MTK_PIN_NO(28) | 4)
+#define PINMUX_GPIO28__FUNC_SDA7 (MTK_PIN_NO(28) | 5)
+#define PINMUX_GPIO28__FUNC_URTS2 (MTK_PIN_NO(28) | 6)
+#define PINMUX_GPIO28__FUNC_DBG_MON_A19 (MTK_PIN_NO(28) | 7)
+
+#define PINMUX_GPIO29__FUNC_GPIO29 (MTK_PIN_NO(29) | 0)
+#define PINMUX_GPIO29__FUNC_HDMIRX20_SCL (MTK_PIN_NO(29) | 1)
+#define PINMUX_GPIO29__FUNC_CMFLASH2 (MTK_PIN_NO(29) | 2)
+#define PINMUX_GPIO29__FUNC_SCL5 (MTK_PIN_NO(29) | 3)
+#define PINMUX_GPIO29__FUNC_TP_URTS2_AO (MTK_PIN_NO(29) | 4)
+#define PINMUX_GPIO29__FUNC_UTXD2 (MTK_PIN_NO(29) | 6)
+#define PINMUX_GPIO29__FUNC_DBG_MON_A20 (MTK_PIN_NO(29) | 7)
+
+#define PINMUX_GPIO30__FUNC_GPIO30 (MTK_PIN_NO(30) | 0)
+#define PINMUX_GPIO30__FUNC_HDMIRX20_SDA (MTK_PIN_NO(30) | 1)
+#define PINMUX_GPIO30__FUNC_CMFLASH3 (MTK_PIN_NO(30) | 2)
+#define PINMUX_GPIO30__FUNC_SDA5 (MTK_PIN_NO(30) | 3)
+#define PINMUX_GPIO30__FUNC_TP_UCTS2_AO (MTK_PIN_NO(30) | 4)
+#define PINMUX_GPIO30__FUNC_URXD2 (MTK_PIN_NO(30) | 6)
+#define PINMUX_GPIO30__FUNC_DBG_MON_A21 (MTK_PIN_NO(30) | 7)
+
+#define PINMUX_GPIO31__FUNC_GPIO31 (MTK_PIN_NO(31) | 0)
+#define PINMUX_GPIO31__FUNC_HDMITX20_PWR5V (MTK_PIN_NO(31) | 1)
+#define PINMUX_GPIO31__FUNC_DMIC1_DAT_R (MTK_PIN_NO(31) | 2)
+#define PINMUX_GPIO31__FUNC_PERSTN (MTK_PIN_NO(31) | 3)
+#define PINMUX_GPIO31__FUNC_DBG_MON_A22 (MTK_PIN_NO(31) | 7)
+
+#define PINMUX_GPIO32__FUNC_GPIO32 (MTK_PIN_NO(32) | 0)
+#define PINMUX_GPIO32__FUNC_HDMITX20_HTPLG (MTK_PIN_NO(32) | 1)
+#define PINMUX_GPIO32__FUNC_CLKREQN (MTK_PIN_NO(32) | 3)
+#define PINMUX_GPIO32__FUNC_DBG_MON_A23 (MTK_PIN_NO(32) | 7)
+
+#define PINMUX_GPIO33__FUNC_GPIO33 (MTK_PIN_NO(33) | 0)
+#define PINMUX_GPIO33__FUNC_HDMITX20_CEC (MTK_PIN_NO(33) | 1)
+#define PINMUX_GPIO33__FUNC_CMVREF0 (MTK_PIN_NO(33) | 2)
+#define PINMUX_GPIO33__FUNC_WAKEN (MTK_PIN_NO(33) | 3)
+
+#define PINMUX_GPIO34__FUNC_GPIO34 (MTK_PIN_NO(34) | 0)
+#define PINMUX_GPIO34__FUNC_HDMITX20_SCL (MTK_PIN_NO(34) | 1)
+#define PINMUX_GPIO34__FUNC_CMVREF1 (MTK_PIN_NO(34) | 2)
+#define PINMUX_GPIO34__FUNC_SCL7 (MTK_PIN_NO(34) | 3)
+#define PINMUX_GPIO34__FUNC_SCL6 (MTK_PIN_NO(34) | 4)
+#define PINMUX_GPIO34__FUNC_DBG_MON_A24 (MTK_PIN_NO(34) | 7)
+
+#define PINMUX_GPIO35__FUNC_GPIO35 (MTK_PIN_NO(35) | 0)
+#define PINMUX_GPIO35__FUNC_HDMITX20_SDA (MTK_PIN_NO(35) | 1)
+#define PINMUX_GPIO35__FUNC_CMVREF2 (MTK_PIN_NO(35) | 2)
+#define PINMUX_GPIO35__FUNC_SDA7 (MTK_PIN_NO(35) | 3)
+#define PINMUX_GPIO35__FUNC_SDA6 (MTK_PIN_NO(35) | 4)
+#define PINMUX_GPIO35__FUNC_DBG_MON_A25 (MTK_PIN_NO(35) | 7)
+
+#define PINMUX_GPIO36__FUNC_GPIO36 (MTK_PIN_NO(36) | 0)
+#define PINMUX_GPIO36__FUNC_RTC32K_CK (MTK_PIN_NO(36) | 1)
+#define PINMUX_GPIO36__FUNC_DBG_MON_A27 (MTK_PIN_NO(36) | 7)
+
+#define PINMUX_GPIO37__FUNC_GPIO37 (MTK_PIN_NO(37) | 0)
+#define PINMUX_GPIO37__FUNC_WATCHDOG (MTK_PIN_NO(37) | 1)
+#define PINMUX_GPIO37__FUNC_DBG_MON_A28 (MTK_PIN_NO(37) | 7)
+
+#define PINMUX_GPIO38__FUNC_GPIO38 (MTK_PIN_NO(38) | 0)
+#define PINMUX_GPIO38__FUNC_SRCLKENA0 (MTK_PIN_NO(38) | 1)
+#define PINMUX_GPIO38__FUNC_DBG_MON_A29 (MTK_PIN_NO(38) | 7)
+
+#define PINMUX_GPIO39__FUNC_GPIO39 (MTK_PIN_NO(39) | 0)
+#define PINMUX_GPIO39__FUNC_SRCLKENA1 (MTK_PIN_NO(39) | 1)
+#define PINMUX_GPIO39__FUNC_DMIC2_DAT_R (MTK_PIN_NO(39) | 2)
+#define PINMUX_GPIO39__FUNC_DBG_MON_A30 (MTK_PIN_NO(39) | 7)
+
+#define PINMUX_GPIO40__FUNC_GPIO40 (MTK_PIN_NO(40) | 0)
+#define PINMUX_GPIO40__FUNC_PWRAP_SPI0_CSN (MTK_PIN_NO(40) | 1)
+#define PINMUX_GPIO40__FUNC_SPIM3_CSB (MTK_PIN_NO(40) | 3)
+#define PINMUX_GPIO40__FUNC_DBG_MON_A31 (MTK_PIN_NO(40) | 7)
+
+#define PINMUX_GPIO41__FUNC_GPIO41 (MTK_PIN_NO(41) | 0)
+#define PINMUX_GPIO41__FUNC_PWRAP_SPI0_CK (MTK_PIN_NO(41) | 1)
+#define PINMUX_GPIO41__FUNC_SPIM3_CLK (MTK_PIN_NO(41) | 3)
+#define PINMUX_GPIO41__FUNC_DBG_MON_A32 (MTK_PIN_NO(41) | 7)
+
+#define PINMUX_GPIO42__FUNC_GPIO42 (MTK_PIN_NO(42) | 0)
+#define PINMUX_GPIO42__FUNC_PWRAP_SPI0_MO (MTK_PIN_NO(42) | 1)
+#define PINMUX_GPIO42__FUNC_PWRAP_SPI0_MI (MTK_PIN_NO(42) | 2)
+#define PINMUX_GPIO42__FUNC_SPIM3_MO (MTK_PIN_NO(42) | 3)
+#define PINMUX_GPIO42__FUNC_DBG_MON_B0 (MTK_PIN_NO(42) | 7)
+
+#define PINMUX_GPIO43__FUNC_GPIO43 (MTK_PIN_NO(43) | 0)
+#define PINMUX_GPIO43__FUNC_PWRAP_SPI0_MI (MTK_PIN_NO(43) | 1)
+#define PINMUX_GPIO43__FUNC_PWRAP_SPI0_MO (MTK_PIN_NO(43) | 2)
+#define PINMUX_GPIO43__FUNC_SPIM3_MI (MTK_PIN_NO(43) | 3)
+#define PINMUX_GPIO43__FUNC_DBG_MON_B1 (MTK_PIN_NO(43) | 7)
+
+#define PINMUX_GPIO44__FUNC_GPIO44 (MTK_PIN_NO(44) | 0)
+#define PINMUX_GPIO44__FUNC_SPMI_M_SCL (MTK_PIN_NO(44) | 1)
+#define PINMUX_GPIO44__FUNC_I2SI00_DATA1 (MTK_PIN_NO(44) | 2)
+#define PINMUX_GPIO44__FUNC_SCL5 (MTK_PIN_NO(44) | 3)
+#define PINMUX_GPIO44__FUNC_UTXD5 (MTK_PIN_NO(44) | 4)
+#define PINMUX_GPIO44__FUNC_DBG_MON_B2 (MTK_PIN_NO(44) | 7)
+
+#define PINMUX_GPIO45__FUNC_GPIO45 (MTK_PIN_NO(45) | 0)
+#define PINMUX_GPIO45__FUNC_SPMI_M_SDA (MTK_PIN_NO(45) | 1)
+#define PINMUX_GPIO45__FUNC_I2SI00_DATA2 (MTK_PIN_NO(45) | 2)
+#define PINMUX_GPIO45__FUNC_SDA5 (MTK_PIN_NO(45) | 3)
+#define PINMUX_GPIO45__FUNC_URXD5 (MTK_PIN_NO(45) | 4)
+#define PINMUX_GPIO45__FUNC_DBG_MON_B3 (MTK_PIN_NO(45) | 7)
+
+#define PINMUX_GPIO46__FUNC_GPIO46 (MTK_PIN_NO(46) | 0)
+#define PINMUX_GPIO46__FUNC_I2SIN_MCK (MTK_PIN_NO(46) | 1)
+#define PINMUX_GPIO46__FUNC_I2SI00_DATA3 (MTK_PIN_NO(46) | 2)
+#define PINMUX_GPIO46__FUNC_SPLIN_MCK (MTK_PIN_NO(46) | 3)
+#define PINMUX_GPIO46__FUNC_DBG_MON_B4 (MTK_PIN_NO(46) | 7)
+
+#define PINMUX_GPIO47__FUNC_GPIO47 (MTK_PIN_NO(47) | 0)
+#define PINMUX_GPIO47__FUNC_I2SIN_BCK (MTK_PIN_NO(47) | 1)
+#define PINMUX_GPIO47__FUNC_I2SIN0_BCK (MTK_PIN_NO(47) | 2)
+#define PINMUX_GPIO47__FUNC_SPLIN_LRCK (MTK_PIN_NO(47) | 3)
+#define PINMUX_GPIO47__FUNC_DBG_MON_B5 (MTK_PIN_NO(47) | 7)
+
+#define PINMUX_GPIO48__FUNC_GPIO48 (MTK_PIN_NO(48) | 0)
+#define PINMUX_GPIO48__FUNC_I2SIN_WS (MTK_PIN_NO(48) | 1)
+#define PINMUX_GPIO48__FUNC_I2SIN0_LRCK (MTK_PIN_NO(48) | 2)
+#define PINMUX_GPIO48__FUNC_SPLIN_BCK (MTK_PIN_NO(48) | 3)
+#define PINMUX_GPIO48__FUNC_DBG_MON_B6 (MTK_PIN_NO(48) | 7)
+
+#define PINMUX_GPIO49__FUNC_GPIO49 (MTK_PIN_NO(49) | 0)
+#define PINMUX_GPIO49__FUNC_I2SIN_D0 (MTK_PIN_NO(49) | 1)
+#define PINMUX_GPIO49__FUNC_I2SI00_DATA0 (MTK_PIN_NO(49) | 2)
+#define PINMUX_GPIO49__FUNC_SPLIN_D0 (MTK_PIN_NO(49) | 3)
+#define PINMUX_GPIO49__FUNC_DBG_MON_B7 (MTK_PIN_NO(49) | 7)
+
+#define PINMUX_GPIO50__FUNC_GPIO50 (MTK_PIN_NO(50) | 0)
+#define PINMUX_GPIO50__FUNC_I2SO1_MCK (MTK_PIN_NO(50) | 1)
+#define PINMUX_GPIO50__FUNC_I2SI5_D0 (MTK_PIN_NO(50) | 2)
+#define PINMUX_GPIO50__FUNC_I2SO4_MCK (MTK_PIN_NO(50) | 4)
+#define PINMUX_GPIO50__FUNC_DBG_MON_B8 (MTK_PIN_NO(50) | 7)
+
+#define PINMUX_GPIO51__FUNC_GPIO51 (MTK_PIN_NO(51) | 0)
+#define PINMUX_GPIO51__FUNC_I2SO1_BCK (MTK_PIN_NO(51) | 1)
+#define PINMUX_GPIO51__FUNC_I2SI5_BCK (MTK_PIN_NO(51) | 2)
+#define PINMUX_GPIO51__FUNC_DBG_MON_B9 (MTK_PIN_NO(51) | 7)
+
+#define PINMUX_GPIO52__FUNC_GPIO52 (MTK_PIN_NO(52) | 0)
+#define PINMUX_GPIO52__FUNC_I2SO1_WS (MTK_PIN_NO(52) | 1)
+#define PINMUX_GPIO52__FUNC_I2SI5_WS (MTK_PIN_NO(52) | 2)
+#define PINMUX_GPIO52__FUNC_DBG_MON_B10 (MTK_PIN_NO(52) | 7)
+
+#define PINMUX_GPIO53__FUNC_GPIO53 (MTK_PIN_NO(53) | 0)
+#define PINMUX_GPIO53__FUNC_I2SO1_D0 (MTK_PIN_NO(53) | 1)
+#define PINMUX_GPIO53__FUNC_I2SI5_MCK (MTK_PIN_NO(53) | 2)
+#define PINMUX_GPIO53__FUNC_DBG_MON_B11 (MTK_PIN_NO(53) | 7)
+
+#define PINMUX_GPIO54__FUNC_GPIO54 (MTK_PIN_NO(54) | 0)
+#define PINMUX_GPIO54__FUNC_I2SO1_D1 (MTK_PIN_NO(54) | 1)
+#define PINMUX_GPIO54__FUNC_I2SI01_DATA1 (MTK_PIN_NO(54) | 2)
+#define PINMUX_GPIO54__FUNC_SPLIN_D1 (MTK_PIN_NO(54) | 3)
+#define PINMUX_GPIO54__FUNC_I2SO4_BCK (MTK_PIN_NO(54) | 4)
+#define PINMUX_GPIO54__FUNC_DBG_MON_B12 (MTK_PIN_NO(54) | 7)
+
+#define PINMUX_GPIO55__FUNC_GPIO55 (MTK_PIN_NO(55) | 0)
+#define PINMUX_GPIO55__FUNC_I2SO1_D2 (MTK_PIN_NO(55) | 1)
+#define PINMUX_GPIO55__FUNC_I2SI01_DATA2 (MTK_PIN_NO(55) | 2)
+#define PINMUX_GPIO55__FUNC_SPLIN_D2 (MTK_PIN_NO(55) | 3)
+#define PINMUX_GPIO55__FUNC_I2SO4_WS (MTK_PIN_NO(55) | 4)
+#define PINMUX_GPIO55__FUNC_DBG_MON_B13 (MTK_PIN_NO(55) | 7)
+
+#define PINMUX_GPIO56__FUNC_GPIO56 (MTK_PIN_NO(56) | 0)
+#define PINMUX_GPIO56__FUNC_I2SO1_D3 (MTK_PIN_NO(56) | 1)
+#define PINMUX_GPIO56__FUNC_I2SI01_DATA3 (MTK_PIN_NO(56) | 2)
+#define PINMUX_GPIO56__FUNC_SPLIN_D3 (MTK_PIN_NO(56) | 3)
+#define PINMUX_GPIO56__FUNC_I2SO4_D0 (MTK_PIN_NO(56) | 4)
+#define PINMUX_GPIO56__FUNC_DBG_MON_B14 (MTK_PIN_NO(56) | 7)
+
+#define PINMUX_GPIO57__FUNC_GPIO57 (MTK_PIN_NO(57) | 0)
+#define PINMUX_GPIO57__FUNC_I2SO2_MCK (MTK_PIN_NO(57) | 1)
+#define PINMUX_GPIO57__FUNC_I2SO1_D12 (MTK_PIN_NO(57) | 2)
+#define PINMUX_GPIO57__FUNC_LCM1_RST (MTK_PIN_NO(57) | 3)
+#define PINMUX_GPIO57__FUNC_DBG_MON_B15 (MTK_PIN_NO(57) | 7)
+
+#define PINMUX_GPIO58__FUNC_GPIO58 (MTK_PIN_NO(58) | 0)
+#define PINMUX_GPIO58__FUNC_I2SO2_BCK (MTK_PIN_NO(58) | 1)
+#define PINMUX_GPIO58__FUNC_I2SO1_D13 (MTK_PIN_NO(58) | 2)
+#define PINMUX_GPIO58__FUNC_I2SIN1_BCK (MTK_PIN_NO(58) | 3)
+#define PINMUX_GPIO58__FUNC_DBG_MON_B16 (MTK_PIN_NO(58) | 7)
+
+#define PINMUX_GPIO59__FUNC_GPIO59 (MTK_PIN_NO(59) | 0)
+#define PINMUX_GPIO59__FUNC_I2SO2_WS (MTK_PIN_NO(59) | 1)
+#define PINMUX_GPIO59__FUNC_I2SO1_D14 (MTK_PIN_NO(59) | 2)
+#define PINMUX_GPIO59__FUNC_I2SIN1_LRCK (MTK_PIN_NO(59) | 3)
+#define PINMUX_GPIO59__FUNC_DBG_MON_B17 (MTK_PIN_NO(59) | 7)
+
+#define PINMUX_GPIO60__FUNC_GPIO60 (MTK_PIN_NO(60) | 0)
+#define PINMUX_GPIO60__FUNC_I2SO2_D0 (MTK_PIN_NO(60) | 1)
+#define PINMUX_GPIO60__FUNC_I2SO1_D15 (MTK_PIN_NO(60) | 2)
+#define PINMUX_GPIO60__FUNC_I2SI01_DATA0 (MTK_PIN_NO(60) | 3)
+#define PINMUX_GPIO60__FUNC_DBG_MON_B18 (MTK_PIN_NO(60) | 7)
+
+#define PINMUX_GPIO61__FUNC_GPIO61 (MTK_PIN_NO(61) | 0)
+#define PINMUX_GPIO61__FUNC_DMIC1_CLK (MTK_PIN_NO(61) | 1)
+#define PINMUX_GPIO61__FUNC_I2SO2_BCK (MTK_PIN_NO(61) | 2)
+#define PINMUX_GPIO61__FUNC_SCP_SPI2_CK (MTK_PIN_NO(61) | 3)
+#define PINMUX_GPIO61__FUNC_DBG_MON_B19 (MTK_PIN_NO(61) | 7)
+
+#define PINMUX_GPIO62__FUNC_GPIO62 (MTK_PIN_NO(62) | 0)
+#define PINMUX_GPIO62__FUNC_DMIC1_DAT (MTK_PIN_NO(62) | 1)
+#define PINMUX_GPIO62__FUNC_I2SO2_WS (MTK_PIN_NO(62) | 2)
+#define PINMUX_GPIO62__FUNC_SCP_SPI2_MI (MTK_PIN_NO(62) | 3)
+#define PINMUX_GPIO62__FUNC_DBG_MON_B20 (MTK_PIN_NO(62) | 7)
+
+#define PINMUX_GPIO63__FUNC_GPIO63 (MTK_PIN_NO(63) | 0)
+#define PINMUX_GPIO63__FUNC_DMIC2_CLK (MTK_PIN_NO(63) | 1)
+#define PINMUX_GPIO63__FUNC_VBUSVALID (MTK_PIN_NO(63) | 2)
+#define PINMUX_GPIO63__FUNC_SCP_SPI2_MO (MTK_PIN_NO(63) | 3)
+#define PINMUX_GPIO63__FUNC_SCP_SCL2 (MTK_PIN_NO(63) | 4)
+#define PINMUX_GPIO63__FUNC_SCP_JTAG1_TDO (MTK_PIN_NO(63) | 5)
+#define PINMUX_GPIO63__FUNC_JTDO_SEL1 (MTK_PIN_NO(63) | 6)
+#define PINMUX_GPIO63__FUNC_DBG_MON_B21 (MTK_PIN_NO(63) | 7)
+
+#define PINMUX_GPIO64__FUNC_GPIO64 (MTK_PIN_NO(64) | 0)
+#define PINMUX_GPIO64__FUNC_DMIC2_DAT (MTK_PIN_NO(64) | 1)
+#define PINMUX_GPIO64__FUNC_VBUSVALID_1P (MTK_PIN_NO(64) | 2)
+#define PINMUX_GPIO64__FUNC_SCP_SPI2_CS (MTK_PIN_NO(64) | 3)
+#define PINMUX_GPIO64__FUNC_SCP_SDA2 (MTK_PIN_NO(64) | 4)
+#define PINMUX_GPIO64__FUNC_DBG_MON_B22 (MTK_PIN_NO(64) | 7)
+
+#define PINMUX_GPIO65__FUNC_GPIO65 (MTK_PIN_NO(65) | 0)
+#define PINMUX_GPIO65__FUNC_PCM_DO (MTK_PIN_NO(65) | 1)
+#define PINMUX_GPIO65__FUNC_AUXIF_ST0 (MTK_PIN_NO(65) | 2)
+#define PINMUX_GPIO65__FUNC_UCTS2 (MTK_PIN_NO(65) | 3)
+#define PINMUX_GPIO65__FUNC_SCP_JTAG1_TMS (MTK_PIN_NO(65) | 5)
+#define PINMUX_GPIO65__FUNC_JTMS_SEL1 (MTK_PIN_NO(65) | 6)
+#define PINMUX_GPIO65__FUNC_DBG_MON_B23 (MTK_PIN_NO(65) | 7)
+
+#define PINMUX_GPIO66__FUNC_GPIO66 (MTK_PIN_NO(66) | 0)
+#define PINMUX_GPIO66__FUNC_PCM_CLK (MTK_PIN_NO(66) | 1)
+#define PINMUX_GPIO66__FUNC_AUXIF_CLK0 (MTK_PIN_NO(66) | 2)
+#define PINMUX_GPIO66__FUNC_URTS2 (MTK_PIN_NO(66) | 3)
+#define PINMUX_GPIO66__FUNC_SCP_JTAG1_TCK (MTK_PIN_NO(66) | 5)
+#define PINMUX_GPIO66__FUNC_JTCK_SEL1 (MTK_PIN_NO(66) | 6)
+#define PINMUX_GPIO66__FUNC_DBG_MON_B24 (MTK_PIN_NO(66) | 7)
+
+#define PINMUX_GPIO67__FUNC_GPIO67 (MTK_PIN_NO(67) | 0)
+#define PINMUX_GPIO67__FUNC_PCM_DI (MTK_PIN_NO(67) | 1)
+#define PINMUX_GPIO67__FUNC_AUXIF_ST1 (MTK_PIN_NO(67) | 2)
+#define PINMUX_GPIO67__FUNC_UTXD2 (MTK_PIN_NO(67) | 3)
+#define PINMUX_GPIO67__FUNC_SCP_JTAG1_TRSTN (MTK_PIN_NO(67) | 5)
+#define PINMUX_GPIO67__FUNC_JTRSTn_SEL1 (MTK_PIN_NO(67) | 6)
+#define PINMUX_GPIO67__FUNC_DBG_MON_B25 (MTK_PIN_NO(67) | 7)
+
+#define PINMUX_GPIO68__FUNC_GPIO68 (MTK_PIN_NO(68) | 0)
+#define PINMUX_GPIO68__FUNC_PCM_SYNC (MTK_PIN_NO(68) | 1)
+#define PINMUX_GPIO68__FUNC_AUXIF_CLK1 (MTK_PIN_NO(68) | 2)
+#define PINMUX_GPIO68__FUNC_URXD2 (MTK_PIN_NO(68) | 3)
+#define PINMUX_GPIO68__FUNC_SCP_JTAG1_TDI (MTK_PIN_NO(68) | 5)
+#define PINMUX_GPIO68__FUNC_JTDI_SEL1 (MTK_PIN_NO(68) | 6)
+#define PINMUX_GPIO68__FUNC_DBG_MON_B26 (MTK_PIN_NO(68) | 7)
+
+#define PINMUX_GPIO69__FUNC_GPIO69 (MTK_PIN_NO(69) | 0)
+#define PINMUX_GPIO69__FUNC_AUD_CLK_MOSI (MTK_PIN_NO(69) | 1)
+#define PINMUX_GPIO69__FUNC_I2SIN2_BCK (MTK_PIN_NO(69) | 2)
+#define PINMUX_GPIO69__FUNC_PWM_0 (MTK_PIN_NO(69) | 3)
+#define PINMUX_GPIO69__FUNC_WAKEN (MTK_PIN_NO(69) | 4)
+#define PINMUX_GPIO69__FUNC_DBG_MON_B27 (MTK_PIN_NO(69) | 7)
+
+#define PINMUX_GPIO70__FUNC_GPIO70 (MTK_PIN_NO(70) | 0)
+#define PINMUX_GPIO70__FUNC_AUD_SYNC_MOSI (MTK_PIN_NO(70) | 1)
+#define PINMUX_GPIO70__FUNC_I2SIN2_LRCK (MTK_PIN_NO(70) | 2)
+#define PINMUX_GPIO70__FUNC_PWM_1 (MTK_PIN_NO(70) | 3)
+#define PINMUX_GPIO70__FUNC_PERSTN (MTK_PIN_NO(70) | 4)
+#define PINMUX_GPIO70__FUNC_DBG_MON_B28 (MTK_PIN_NO(70) | 7)
+
+#define PINMUX_GPIO71__FUNC_GPIO71 (MTK_PIN_NO(71) | 0)
+#define PINMUX_GPIO71__FUNC_AUD_DAT_MOSI0 (MTK_PIN_NO(71) | 1)
+#define PINMUX_GPIO71__FUNC_IDDIG_2P (MTK_PIN_NO(71) | 2)
+#define PINMUX_GPIO71__FUNC_PWM_2 (MTK_PIN_NO(71) | 3)
+#define PINMUX_GPIO71__FUNC_CLKREQN (MTK_PIN_NO(71) | 4)
+#define PINMUX_GPIO71__FUNC_DBG_MON_B29 (MTK_PIN_NO(71) | 7)
+
+#define PINMUX_GPIO72__FUNC_GPIO72 (MTK_PIN_NO(72) | 0)
+#define PINMUX_GPIO72__FUNC_AUD_DAT_MOSI1 (MTK_PIN_NO(72) | 1)
+#define PINMUX_GPIO72__FUNC_USB_DRVVBUS_2P (MTK_PIN_NO(72) | 2)
+#define PINMUX_GPIO72__FUNC_PWM_3 (MTK_PIN_NO(72) | 3)
+#define PINMUX_GPIO72__FUNC_PERSTN_1 (MTK_PIN_NO(72) | 4)
+#define PINMUX_GPIO72__FUNC_DBG_MON_B30 (MTK_PIN_NO(72) | 7)
+
+#define PINMUX_GPIO73__FUNC_GPIO73 (MTK_PIN_NO(73) | 0)
+#define PINMUX_GPIO73__FUNC_AUD_DAT_MISO0 (MTK_PIN_NO(73) | 1)
+#define PINMUX_GPIO73__FUNC_I2SI02_DATA0 (MTK_PIN_NO(73) | 2)
+#define PINMUX_GPIO73__FUNC_CLKREQN_1 (MTK_PIN_NO(73) | 4)
+#define PINMUX_GPIO73__FUNC_VOW_DAT_MISO (MTK_PIN_NO(73) | 5)
+#define PINMUX_GPIO73__FUNC_DBG_MON_B31 (MTK_PIN_NO(73) | 7)
+
+#define PINMUX_GPIO74__FUNC_GPIO74 (MTK_PIN_NO(74) | 0)
+#define PINMUX_GPIO74__FUNC_AUD_DAT_MISO1 (MTK_PIN_NO(74) | 1)
+#define PINMUX_GPIO74__FUNC_I2SI02_DATA1 (MTK_PIN_NO(74) | 2)
+#define PINMUX_GPIO74__FUNC_WAKEN_1 (MTK_PIN_NO(74) | 4)
+#define PINMUX_GPIO74__FUNC_VOW_CLK_MISO (MTK_PIN_NO(74) | 5)
+#define PINMUX_GPIO74__FUNC_DBG_MON_B32 (MTK_PIN_NO(74) | 7)
+
+#define PINMUX_GPIO75__FUNC_GPIO75 (MTK_PIN_NO(75) | 0)
+#define PINMUX_GPIO75__FUNC_AUD_DAT_MISO2 (MTK_PIN_NO(75) | 1)
+#define PINMUX_GPIO75__FUNC_I2SI02_DATA2 (MTK_PIN_NO(75) | 2)
+
+#define PINMUX_GPIO76__FUNC_GPIO76 (MTK_PIN_NO(76) | 0)
+#define PINMUX_GPIO76__FUNC_SCP_VREQ_VAO (MTK_PIN_NO(76) | 1)
+#define PINMUX_GPIO76__FUNC_I2SI02_DATA3 (MTK_PIN_NO(76) | 2)
+#define PINMUX_GPIO76__FUNC_DBG_MON_A26 (MTK_PIN_NO(76) | 7)
+
+#define PINMUX_GPIO77__FUNC_GPIO77 (MTK_PIN_NO(77) | 0)
+#define PINMUX_GPIO77__FUNC_DGI_D0 (MTK_PIN_NO(77) | 1)
+#define PINMUX_GPIO77__FUNC_DPI_D0 (MTK_PIN_NO(77) | 2)
+#define PINMUX_GPIO77__FUNC_I2SI4_MCK (MTK_PIN_NO(77) | 3)
+#define PINMUX_GPIO77__FUNC_SPIM4_CLK (MTK_PIN_NO(77) | 4)
+#define PINMUX_GPIO77__FUNC_GBE_TXD3 (MTK_PIN_NO(77) | 5)
+#define PINMUX_GPIO77__FUNC_SPM_JTAG_TCK (MTK_PIN_NO(77) | 6)
+
+#define PINMUX_GPIO78__FUNC_GPIO78 (MTK_PIN_NO(78) | 0)
+#define PINMUX_GPIO78__FUNC_DGI_D1 (MTK_PIN_NO(78) | 1)
+#define PINMUX_GPIO78__FUNC_DPI_D1 (MTK_PIN_NO(78) | 2)
+#define PINMUX_GPIO78__FUNC_I2SI4_BCK (MTK_PIN_NO(78) | 3)
+#define PINMUX_GPIO78__FUNC_SPIM4_MO (MTK_PIN_NO(78) | 4)
+#define PINMUX_GPIO78__FUNC_GBE_TXD2 (MTK_PIN_NO(78) | 5)
+#define PINMUX_GPIO78__FUNC_SPM_JTAG_TMS (MTK_PIN_NO(78) | 6)
+
+#define PINMUX_GPIO79__FUNC_GPIO79 (MTK_PIN_NO(79) | 0)
+#define PINMUX_GPIO79__FUNC_DGI_D2 (MTK_PIN_NO(79) | 1)
+#define PINMUX_GPIO79__FUNC_DPI_D2 (MTK_PIN_NO(79) | 2)
+#define PINMUX_GPIO79__FUNC_I2SI4_WS (MTK_PIN_NO(79) | 3)
+#define PINMUX_GPIO79__FUNC_SPIM4_CSB (MTK_PIN_NO(79) | 4)
+#define PINMUX_GPIO79__FUNC_GBE_TXD1 (MTK_PIN_NO(79) | 5)
+#define PINMUX_GPIO79__FUNC_SPM_JTAG_TDI (MTK_PIN_NO(79) | 6)
+
+#define PINMUX_GPIO80__FUNC_GPIO80 (MTK_PIN_NO(80) | 0)
+#define PINMUX_GPIO80__FUNC_DGI_D3 (MTK_PIN_NO(80) | 1)
+#define PINMUX_GPIO80__FUNC_DPI_D3 (MTK_PIN_NO(80) | 2)
+#define PINMUX_GPIO80__FUNC_I2SI4_D0 (MTK_PIN_NO(80) | 3)
+#define PINMUX_GPIO80__FUNC_SPIM4_MI (MTK_PIN_NO(80) | 4)
+#define PINMUX_GPIO80__FUNC_GBE_TXD0 (MTK_PIN_NO(80) | 5)
+#define PINMUX_GPIO80__FUNC_SPM_JTAG_TDO (MTK_PIN_NO(80) | 6)
+
+#define PINMUX_GPIO81__FUNC_GPIO81 (MTK_PIN_NO(81) | 0)
+#define PINMUX_GPIO81__FUNC_DGI_D4 (MTK_PIN_NO(81) | 1)
+#define PINMUX_GPIO81__FUNC_DPI_D4 (MTK_PIN_NO(81) | 2)
+#define PINMUX_GPIO81__FUNC_I2SI5_MCK (MTK_PIN_NO(81) | 3)
+#define PINMUX_GPIO81__FUNC_SPIM5_CLK (MTK_PIN_NO(81) | 4)
+#define PINMUX_GPIO81__FUNC_GBE_RXD3 (MTK_PIN_NO(81) | 5)
+#define PINMUX_GPIO81__FUNC_SPM_JTAG_TRSTN (MTK_PIN_NO(81) | 6)
+
+#define PINMUX_GPIO82__FUNC_GPIO82 (MTK_PIN_NO(82) | 0)
+#define PINMUX_GPIO82__FUNC_DGI_D5 (MTK_PIN_NO(82) | 1)
+#define PINMUX_GPIO82__FUNC_DPI_D5 (MTK_PIN_NO(82) | 2)
+#define PINMUX_GPIO82__FUNC_I2SI5_BCK (MTK_PIN_NO(82) | 3)
+#define PINMUX_GPIO82__FUNC_SPIM5_MO (MTK_PIN_NO(82) | 4)
+#define PINMUX_GPIO82__FUNC_GBE_RXD2 (MTK_PIN_NO(82) | 5)
+#define PINMUX_GPIO82__FUNC_MCUPM_JTAG_TDO (MTK_PIN_NO(82) | 6)
+
+#define PINMUX_GPIO83__FUNC_GPIO83 (MTK_PIN_NO(83) | 0)
+#define PINMUX_GPIO83__FUNC_DGI_D6 (MTK_PIN_NO(83) | 1)
+#define PINMUX_GPIO83__FUNC_DPI_D6 (MTK_PIN_NO(83) | 2)
+#define PINMUX_GPIO83__FUNC_I2SI5_WS (MTK_PIN_NO(83) | 3)
+#define PINMUX_GPIO83__FUNC_SPIM5_CSB (MTK_PIN_NO(83) | 4)
+#define PINMUX_GPIO83__FUNC_GBE_RXD1 (MTK_PIN_NO(83) | 5)
+#define PINMUX_GPIO83__FUNC_MCUPM_JTAG_TMS (MTK_PIN_NO(83) | 6)
+
+#define PINMUX_GPIO84__FUNC_GPIO84 (MTK_PIN_NO(84) | 0)
+#define PINMUX_GPIO84__FUNC_DGI_D7 (MTK_PIN_NO(84) | 1)
+#define PINMUX_GPIO84__FUNC_DPI_D7 (MTK_PIN_NO(84) | 2)
+#define PINMUX_GPIO84__FUNC_I2SI5_D0 (MTK_PIN_NO(84) | 3)
+#define PINMUX_GPIO84__FUNC_SPIM5_MI (MTK_PIN_NO(84) | 4)
+#define PINMUX_GPIO84__FUNC_GBE_RXD0 (MTK_PIN_NO(84) | 5)
+#define PINMUX_GPIO84__FUNC_MCUPM_JTAG_TCK (MTK_PIN_NO(84) | 6)
+
+#define PINMUX_GPIO85__FUNC_GPIO85 (MTK_PIN_NO(85) | 0)
+#define PINMUX_GPIO85__FUNC_DGI_D8 (MTK_PIN_NO(85) | 1)
+#define PINMUX_GPIO85__FUNC_DPI_D8 (MTK_PIN_NO(85) | 2)
+#define PINMUX_GPIO85__FUNC_I2SO4_MCK (MTK_PIN_NO(85) | 3)
+#define PINMUX_GPIO85__FUNC_SCP_SPI1_B_CK (MTK_PIN_NO(85) | 4)
+#define PINMUX_GPIO85__FUNC_GBE_TXC (MTK_PIN_NO(85) | 5)
+#define PINMUX_GPIO85__FUNC_MCUPM_JTAG_TDI (MTK_PIN_NO(85) | 6)
+
+#define PINMUX_GPIO86__FUNC_GPIO86 (MTK_PIN_NO(86) | 0)
+#define PINMUX_GPIO86__FUNC_DGI_D9 (MTK_PIN_NO(86) | 1)
+#define PINMUX_GPIO86__FUNC_DPI_D9 (MTK_PIN_NO(86) | 2)
+#define PINMUX_GPIO86__FUNC_I2SO4_BCK (MTK_PIN_NO(86) | 3)
+#define PINMUX_GPIO86__FUNC_SCP_SPI1_B_MI (MTK_PIN_NO(86) | 4)
+#define PINMUX_GPIO86__FUNC_GBE_RXC (MTK_PIN_NO(86) | 5)
+#define PINMUX_GPIO86__FUNC_MCUPM_JTAG_TRSTN (MTK_PIN_NO(86) | 6)
+
+#define PINMUX_GPIO87__FUNC_GPIO87 (MTK_PIN_NO(87) | 0)
+#define PINMUX_GPIO87__FUNC_DGI_D10 (MTK_PIN_NO(87) | 1)
+#define PINMUX_GPIO87__FUNC_DPI_D10 (MTK_PIN_NO(87) | 2)
+#define PINMUX_GPIO87__FUNC_I2SO4_WS (MTK_PIN_NO(87) | 3)
+#define PINMUX_GPIO87__FUNC_SCP_SPI1_B_CS (MTK_PIN_NO(87) | 4)
+#define PINMUX_GPIO87__FUNC_GBE_RXDV (MTK_PIN_NO(87) | 5)
+#define PINMUX_GPIO87__FUNC_SSPM_JTAG_TDO (MTK_PIN_NO(87) | 6)
+
+#define PINMUX_GPIO88__FUNC_GPIO88 (MTK_PIN_NO(88) | 0)
+#define PINMUX_GPIO88__FUNC_DGI_D11 (MTK_PIN_NO(88) | 1)
+#define PINMUX_GPIO88__FUNC_DPI_D11 (MTK_PIN_NO(88) | 2)
+#define PINMUX_GPIO88__FUNC_I2SO4_D0 (MTK_PIN_NO(88) | 3)
+#define PINMUX_GPIO88__FUNC_SCP_SPI1_B_MO (MTK_PIN_NO(88) | 4)
+#define PINMUX_GPIO88__FUNC_GBE_TXEN (MTK_PIN_NO(88) | 5)
+#define PINMUX_GPIO88__FUNC_SSPM_JTAG_TMS (MTK_PIN_NO(88) | 6)
+
+#define PINMUX_GPIO89__FUNC_GPIO89 (MTK_PIN_NO(89) | 0)
+#define PINMUX_GPIO89__FUNC_DGI_D12 (MTK_PIN_NO(89) | 1)
+#define PINMUX_GPIO89__FUNC_DPI_D12 (MTK_PIN_NO(89) | 2)
+#define PINMUX_GPIO89__FUNC_MSDC2_CMD_A (MTK_PIN_NO(89) | 3)
+#define PINMUX_GPIO89__FUNC_I2SO5_BCK (MTK_PIN_NO(89) | 4)
+#define PINMUX_GPIO89__FUNC_GBE_MDC (MTK_PIN_NO(89) | 5)
+#define PINMUX_GPIO89__FUNC_SSPM_JTAG_TCK (MTK_PIN_NO(89) | 6)
+
+#define PINMUX_GPIO90__FUNC_GPIO90 (MTK_PIN_NO(90) | 0)
+#define PINMUX_GPIO90__FUNC_DGI_D13 (MTK_PIN_NO(90) | 1)
+#define PINMUX_GPIO90__FUNC_DPI_D13 (MTK_PIN_NO(90) | 2)
+#define PINMUX_GPIO90__FUNC_MSDC2_CLK_A (MTK_PIN_NO(90) | 3)
+#define PINMUX_GPIO90__FUNC_I2SO5_WS (MTK_PIN_NO(90) | 4)
+#define PINMUX_GPIO90__FUNC_GBE_MDIO (MTK_PIN_NO(90) | 5)
+#define PINMUX_GPIO90__FUNC_SSPM_JTAG_TDI (MTK_PIN_NO(90) | 6)
+
+#define PINMUX_GPIO91__FUNC_GPIO91 (MTK_PIN_NO(91) | 0)
+#define PINMUX_GPIO91__FUNC_DGI_D14 (MTK_PIN_NO(91) | 1)
+#define PINMUX_GPIO91__FUNC_DPI_D14 (MTK_PIN_NO(91) | 2)
+#define PINMUX_GPIO91__FUNC_MSDC2_DAT3_A (MTK_PIN_NO(91) | 3)
+#define PINMUX_GPIO91__FUNC_I2SO5_D0 (MTK_PIN_NO(91) | 4)
+#define PINMUX_GPIO91__FUNC_GBE_TXER (MTK_PIN_NO(91) | 5)
+#define PINMUX_GPIO91__FUNC_SSPM_JTAG_TRSTN (MTK_PIN_NO(91) | 6)
+
+#define PINMUX_GPIO92__FUNC_GPIO92 (MTK_PIN_NO(92) | 0)
+#define PINMUX_GPIO92__FUNC_DGI_D15 (MTK_PIN_NO(92) | 1)
+#define PINMUX_GPIO92__FUNC_DPI_D15 (MTK_PIN_NO(92) | 2)
+#define PINMUX_GPIO92__FUNC_MSDC2_DAT0_A (MTK_PIN_NO(92) | 3)
+#define PINMUX_GPIO92__FUNC_I2SO2_D1 (MTK_PIN_NO(92) | 4)
+#define PINMUX_GPIO92__FUNC_GBE_RXER (MTK_PIN_NO(92) | 5)
+#define PINMUX_GPIO92__FUNC_CCU0_JTAG_TDO (MTK_PIN_NO(92) | 6)
+
+#define PINMUX_GPIO93__FUNC_GPIO93 (MTK_PIN_NO(93) | 0)
+#define PINMUX_GPIO93__FUNC_DGI_HSYNC (MTK_PIN_NO(93) | 1)
+#define PINMUX_GPIO93__FUNC_DPI_HSYNC (MTK_PIN_NO(93) | 2)
+#define PINMUX_GPIO93__FUNC_MSDC2_DAT2_A (MTK_PIN_NO(93) | 3)
+#define PINMUX_GPIO93__FUNC_I2SO2_D2 (MTK_PIN_NO(93) | 4)
+#define PINMUX_GPIO93__FUNC_GBE_COL (MTK_PIN_NO(93) | 5)
+#define PINMUX_GPIO93__FUNC_CCU0_JTAG_TMS (MTK_PIN_NO(93) | 6)
+
+#define PINMUX_GPIO94__FUNC_GPIO94 (MTK_PIN_NO(94) | 0)
+#define PINMUX_GPIO94__FUNC_DGI_VSYNC (MTK_PIN_NO(94) | 1)
+#define PINMUX_GPIO94__FUNC_DPI_VSYNC (MTK_PIN_NO(94) | 2)
+#define PINMUX_GPIO94__FUNC_MSDC2_DAT1_A (MTK_PIN_NO(94) | 3)
+#define PINMUX_GPIO94__FUNC_I2SO2_D3 (MTK_PIN_NO(94) | 4)
+#define PINMUX_GPIO94__FUNC_GBE_INTR (MTK_PIN_NO(94) | 5)
+#define PINMUX_GPIO94__FUNC_CCU0_JTAG_TDI (MTK_PIN_NO(94) | 6)
+
+#define PINMUX_GPIO95__FUNC_GPIO95 (MTK_PIN_NO(95) | 0)
+#define PINMUX_GPIO95__FUNC_DGI_DE (MTK_PIN_NO(95) | 1)
+#define PINMUX_GPIO95__FUNC_DPI_DE (MTK_PIN_NO(95) | 2)
+#define PINMUX_GPIO95__FUNC_UTXD2 (MTK_PIN_NO(95) | 3)
+#define PINMUX_GPIO95__FUNC_I2SIN_D1 (MTK_PIN_NO(95) | 5)
+#define PINMUX_GPIO95__FUNC_CCU0_JTAG_TCK (MTK_PIN_NO(95) | 6)
+
+#define PINMUX_GPIO96__FUNC_GPIO96 (MTK_PIN_NO(96) | 0)
+#define PINMUX_GPIO96__FUNC_DGI_CK (MTK_PIN_NO(96) | 1)
+#define PINMUX_GPIO96__FUNC_DPI_CK (MTK_PIN_NO(96) | 2)
+#define PINMUX_GPIO96__FUNC_URXD2 (MTK_PIN_NO(96) | 3)
+#define PINMUX_GPIO96__FUNC_I2SO5_MCK (MTK_PIN_NO(96) | 4)
+#define PINMUX_GPIO96__FUNC_I2SIN_D2 (MTK_PIN_NO(96) | 5)
+#define PINMUX_GPIO96__FUNC_CCU0_JTAG_TRST (MTK_PIN_NO(96) | 6)
+
+#define PINMUX_GPIO97__FUNC_GPIO97 (MTK_PIN_NO(97) | 0)
+#define PINMUX_GPIO97__FUNC_DISP_PWM0 (MTK_PIN_NO(97) | 1)
+#define PINMUX_GPIO97__FUNC_DVFSRC_EXT_REQ (MTK_PIN_NO(97) | 2)
+
+#define PINMUX_GPIO98__FUNC_GPIO98 (MTK_PIN_NO(98) | 0)
+#define PINMUX_GPIO98__FUNC_UTXD0 (MTK_PIN_NO(98) | 1)
+
+#define PINMUX_GPIO99__FUNC_GPIO99 (MTK_PIN_NO(99) | 0)
+#define PINMUX_GPIO99__FUNC_URXD0 (MTK_PIN_NO(99) | 1)
+
+#define PINMUX_GPIO100__FUNC_GPIO100 (MTK_PIN_NO(100) | 0)
+#define PINMUX_GPIO100__FUNC_URTS1 (MTK_PIN_NO(100) | 1)
+#define PINMUX_GPIO100__FUNC_DSI_TE (MTK_PIN_NO(100) | 2)
+#define PINMUX_GPIO100__FUNC_I2SO1_D8 (MTK_PIN_NO(100) | 3)
+#define PINMUX_GPIO100__FUNC_KPROW2 (MTK_PIN_NO(100) | 4)
+#define PINMUX_GPIO100__FUNC_PWM_0 (MTK_PIN_NO(100) | 5)
+#define PINMUX_GPIO100__FUNC_TP_URTS1_AO (MTK_PIN_NO(100) | 6)
+#define PINMUX_GPIO100__FUNC_I2SIN_D0 (MTK_PIN_NO(100) | 7)
+
+#define PINMUX_GPIO101__FUNC_GPIO101 (MTK_PIN_NO(101) | 0)
+#define PINMUX_GPIO101__FUNC_UCTS1 (MTK_PIN_NO(101) | 1)
+#define PINMUX_GPIO101__FUNC_DSI1_TE (MTK_PIN_NO(101) | 2)
+#define PINMUX_GPIO101__FUNC_I2SO1_D9 (MTK_PIN_NO(101) | 3)
+#define PINMUX_GPIO101__FUNC_KPCOL2 (MTK_PIN_NO(101) | 4)
+#define PINMUX_GPIO101__FUNC_PWM_1 (MTK_PIN_NO(101) | 5)
+#define PINMUX_GPIO101__FUNC_TP_UCTS1_AO (MTK_PIN_NO(101) | 6)
+#define PINMUX_GPIO101__FUNC_I2SIN_D1 (MTK_PIN_NO(101) | 7)
+
+#define PINMUX_GPIO102__FUNC_GPIO102 (MTK_PIN_NO(102) | 0)
+#define PINMUX_GPIO102__FUNC_UTXD1 (MTK_PIN_NO(102) | 1)
+#define PINMUX_GPIO102__FUNC_VBUSVALID_2P (MTK_PIN_NO(102) | 2)
+#define PINMUX_GPIO102__FUNC_I2SO1_D10 (MTK_PIN_NO(102) | 3)
+#define PINMUX_GPIO102__FUNC_SSPM_UTXD_AO (MTK_PIN_NO(102) | 4)
+#define PINMUX_GPIO102__FUNC_TP_UTXD1_AO (MTK_PIN_NO(102) | 5)
+#define PINMUX_GPIO102__FUNC_MD32_1_TXD (MTK_PIN_NO(102) | 6)
+#define PINMUX_GPIO102__FUNC_I2SIN_D2 (MTK_PIN_NO(102) | 7)
+
+#define PINMUX_GPIO103__FUNC_GPIO103 (MTK_PIN_NO(103) | 0)
+#define PINMUX_GPIO103__FUNC_URXD1 (MTK_PIN_NO(103) | 1)
+#define PINMUX_GPIO103__FUNC_VBUSVALID_3P (MTK_PIN_NO(103) | 2)
+#define PINMUX_GPIO103__FUNC_I2SO1_D11 (MTK_PIN_NO(103) | 3)
+#define PINMUX_GPIO103__FUNC_SSPM_URXD_AO (MTK_PIN_NO(103) | 4)
+#define PINMUX_GPIO103__FUNC_TP_URXD1_AO (MTK_PIN_NO(103) | 5)
+#define PINMUX_GPIO103__FUNC_MD32_1_RXD (MTK_PIN_NO(103) | 6)
+#define PINMUX_GPIO103__FUNC_I2SIN_D3 (MTK_PIN_NO(103) | 7)
+
+#define PINMUX_GPIO104__FUNC_GPIO104 (MTK_PIN_NO(104) | 0)
+#define PINMUX_GPIO104__FUNC_KPROW0 (MTK_PIN_NO(104) | 1)
+#define PINMUX_GPIO104__FUNC_DISP_PWM1 (MTK_PIN_NO(104) | 2)
+
+#define PINMUX_GPIO105__FUNC_GPIO105 (MTK_PIN_NO(105) | 0)
+#define PINMUX_GPIO105__FUNC_KPROW1 (MTK_PIN_NO(105) | 1)
+#define PINMUX_GPIO105__FUNC_EDP_TX_HPD (MTK_PIN_NO(105) | 2)
+#define PINMUX_GPIO105__FUNC_PWM_2 (MTK_PIN_NO(105) | 3)
+
+#define PINMUX_GPIO106__FUNC_GPIO106 (MTK_PIN_NO(106) | 0)
+#define PINMUX_GPIO106__FUNC_KPCOL0 (MTK_PIN_NO(106) | 1)
+
+#define PINMUX_GPIO107__FUNC_GPIO107 (MTK_PIN_NO(107) | 0)
+#define PINMUX_GPIO107__FUNC_KPCOL1 (MTK_PIN_NO(107) | 1)
+#define PINMUX_GPIO107__FUNC_DSI1_TE (MTK_PIN_NO(107) | 2)
+#define PINMUX_GPIO107__FUNC_PWM_3 (MTK_PIN_NO(107) | 3)
+#define PINMUX_GPIO107__FUNC_SCP_SCL3 (MTK_PIN_NO(107) | 4)
+#define PINMUX_GPIO107__FUNC_I2SIN_MCK (MTK_PIN_NO(107) | 5)
+
+#define PINMUX_GPIO108__FUNC_GPIO108 (MTK_PIN_NO(108) | 0)
+#define PINMUX_GPIO108__FUNC_LCM_RST (MTK_PIN_NO(108) | 1)
+#define PINMUX_GPIO108__FUNC_KPCOL1 (MTK_PIN_NO(108) | 2)
+#define PINMUX_GPIO108__FUNC_SCP_SDA3 (MTK_PIN_NO(108) | 4)
+#define PINMUX_GPIO108__FUNC_I2SIN_BCK (MTK_PIN_NO(108) | 5)
+
+#define PINMUX_GPIO109__FUNC_GPIO109 (MTK_PIN_NO(109) | 0)
+#define PINMUX_GPIO109__FUNC_DSI_TE (MTK_PIN_NO(109) | 1)
+#define PINMUX_GPIO109__FUNC_I2SIN_D3 (MTK_PIN_NO(109) | 2)
+#define PINMUX_GPIO109__FUNC_I2SIN_WS (MTK_PIN_NO(109) | 5)
+
+#define PINMUX_GPIO110__FUNC_GPIO110 (MTK_PIN_NO(110) | 0)
+#define PINMUX_GPIO110__FUNC_MSDC1_CMD (MTK_PIN_NO(110) | 1)
+#define PINMUX_GPIO110__FUNC_JTMS_SEL3 (MTK_PIN_NO(110) | 2)
+#define PINMUX_GPIO110__FUNC_UDI_TMS (MTK_PIN_NO(110) | 3)
+#define PINMUX_GPIO110__FUNC_CCU1_JTAG_TMS (MTK_PIN_NO(110) | 5)
+#define PINMUX_GPIO110__FUNC_IPU_JTAG_TMS (MTK_PIN_NO(110) | 6)
+
+#define PINMUX_GPIO111__FUNC_GPIO111 (MTK_PIN_NO(111) | 0)
+#define PINMUX_GPIO111__FUNC_MSDC1_CLK (MTK_PIN_NO(111) | 1)
+#define PINMUX_GPIO111__FUNC_JTCK_SEL3 (MTK_PIN_NO(111) | 2)
+#define PINMUX_GPIO111__FUNC_UDI_TCK (MTK_PIN_NO(111) | 3)
+#define PINMUX_GPIO111__FUNC_CCU1_JTAG_TCK (MTK_PIN_NO(111) | 5)
+#define PINMUX_GPIO111__FUNC_IPU_JTAG_TCK (MTK_PIN_NO(111) | 6)
+
+#define PINMUX_GPIO112__FUNC_GPIO112 (MTK_PIN_NO(112) | 0)
+#define PINMUX_GPIO112__FUNC_MSDC1_DAT0 (MTK_PIN_NO(112) | 1)
+#define PINMUX_GPIO112__FUNC_JTDI_SEL3 (MTK_PIN_NO(112) | 2)
+#define PINMUX_GPIO112__FUNC_UDI_TDI (MTK_PIN_NO(112) | 3)
+#define PINMUX_GPIO112__FUNC_I2SO2_D0 (MTK_PIN_NO(112) | 4)
+#define PINMUX_GPIO112__FUNC_CCU1_JTAG_TDI (MTK_PIN_NO(112) | 5)
+#define PINMUX_GPIO112__FUNC_IPU_JTAG_TDI (MTK_PIN_NO(112) | 6)
+
+#define PINMUX_GPIO113__FUNC_GPIO113 (MTK_PIN_NO(113) | 0)
+#define PINMUX_GPIO113__FUNC_MSDC1_DAT1 (MTK_PIN_NO(113) | 1)
+#define PINMUX_GPIO113__FUNC_JTDO_SEL3 (MTK_PIN_NO(113) | 2)
+#define PINMUX_GPIO113__FUNC_UDI_TDO (MTK_PIN_NO(113) | 3)
+#define PINMUX_GPIO113__FUNC_I2SO2_D1 (MTK_PIN_NO(113) | 4)
+#define PINMUX_GPIO113__FUNC_CCU1_JTAG_TDO (MTK_PIN_NO(113) | 5)
+#define PINMUX_GPIO113__FUNC_IPU_JTAG_TDO (MTK_PIN_NO(113) | 6)
+
+#define PINMUX_GPIO114__FUNC_GPIO114 (MTK_PIN_NO(114) | 0)
+#define PINMUX_GPIO114__FUNC_MSDC1_DAT2 (MTK_PIN_NO(114) | 1)
+#define PINMUX_GPIO114__FUNC_JTRSTn_SEL3 (MTK_PIN_NO(114) | 2)
+#define PINMUX_GPIO114__FUNC_UDI_NTRST (MTK_PIN_NO(114) | 3)
+#define PINMUX_GPIO114__FUNC_I2SO2_D2 (MTK_PIN_NO(114) | 4)
+#define PINMUX_GPIO114__FUNC_CCU1_JTAG_TRST (MTK_PIN_NO(114) | 5)
+#define PINMUX_GPIO114__FUNC_IPU_JTAG_TRST (MTK_PIN_NO(114) | 6)
+
+#define PINMUX_GPIO115__FUNC_GPIO115 (MTK_PIN_NO(115) | 0)
+#define PINMUX_GPIO115__FUNC_MSDC1_DAT3 (MTK_PIN_NO(115) | 1)
+#define PINMUX_GPIO115__FUNC_I2SO2_D3 (MTK_PIN_NO(115) | 4)
+#define PINMUX_GPIO115__FUNC_MD32_1_GPIO2 (MTK_PIN_NO(115) | 6)
+
+#define PINMUX_GPIO116__FUNC_GPIO116 (MTK_PIN_NO(116) | 0)
+#define PINMUX_GPIO116__FUNC_MSDC0_DAT7 (MTK_PIN_NO(116) | 1)
+
+#define PINMUX_GPIO117__FUNC_GPIO117 (MTK_PIN_NO(117) | 0)
+#define PINMUX_GPIO117__FUNC_MSDC0_DAT6 (MTK_PIN_NO(117) | 1)
+
+#define PINMUX_GPIO118__FUNC_GPIO118 (MTK_PIN_NO(118) | 0)
+#define PINMUX_GPIO118__FUNC_MSDC0_DAT5 (MTK_PIN_NO(118) | 1)
+
+#define PINMUX_GPIO119__FUNC_GPIO119 (MTK_PIN_NO(119) | 0)
+#define PINMUX_GPIO119__FUNC_MSDC0_DAT4 (MTK_PIN_NO(119) | 1)
+
+#define PINMUX_GPIO120__FUNC_GPIO120 (MTK_PIN_NO(120) | 0)
+#define PINMUX_GPIO120__FUNC_MSDC0_RSTB (MTK_PIN_NO(120) | 1)
+
+#define PINMUX_GPIO121__FUNC_GPIO121 (MTK_PIN_NO(121) | 0)
+#define PINMUX_GPIO121__FUNC_MSDC0_CMD (MTK_PIN_NO(121) | 1)
+
+#define PINMUX_GPIO122__FUNC_GPIO122 (MTK_PIN_NO(122) | 0)
+#define PINMUX_GPIO122__FUNC_MSDC0_CLK (MTK_PIN_NO(122) | 1)
+
+#define PINMUX_GPIO123__FUNC_GPIO123 (MTK_PIN_NO(123) | 0)
+#define PINMUX_GPIO123__FUNC_MSDC0_DAT3 (MTK_PIN_NO(123) | 1)
+
+#define PINMUX_GPIO124__FUNC_GPIO124 (MTK_PIN_NO(124) | 0)
+#define PINMUX_GPIO124__FUNC_MSDC0_DAT2 (MTK_PIN_NO(124) | 1)
+
+#define PINMUX_GPIO125__FUNC_GPIO125 (MTK_PIN_NO(125) | 0)
+#define PINMUX_GPIO125__FUNC_MSDC0_DAT1 (MTK_PIN_NO(125) | 1)
+
+#define PINMUX_GPIO126__FUNC_GPIO126 (MTK_PIN_NO(126) | 0)
+#define PINMUX_GPIO126__FUNC_MSDC0_DAT0 (MTK_PIN_NO(126) | 1)
+
+#define PINMUX_GPIO127__FUNC_GPIO127 (MTK_PIN_NO(127) | 0)
+#define PINMUX_GPIO127__FUNC_MSDC0_DSL (MTK_PIN_NO(127) | 1)
+
+#define PINMUX_GPIO128__FUNC_GPIO128 (MTK_PIN_NO(128) | 0)
+#define PINMUX_GPIO128__FUNC_IDDIG (MTK_PIN_NO(128) | 1)
+#define PINMUX_GPIO128__FUNC_UCTS2 (MTK_PIN_NO(128) | 2)
+#define PINMUX_GPIO128__FUNC_UTXD5 (MTK_PIN_NO(128) | 3)
+#define PINMUX_GPIO128__FUNC_UFS_MPHY_SCL (MTK_PIN_NO(128) | 4)
+#define PINMUX_GPIO128__FUNC_mbistreaden_trigger (MTK_PIN_NO(128) | 5)
+#define PINMUX_GPIO128__FUNC_MD32_1_GPIO0 (MTK_PIN_NO(128) | 6)
+#define PINMUX_GPIO128__FUNC_SCP_SCL2 (MTK_PIN_NO(128) | 7)
+
+#define PINMUX_GPIO129__FUNC_GPIO129 (MTK_PIN_NO(129) | 0)
+#define PINMUX_GPIO129__FUNC_USB_DRVVBUS (MTK_PIN_NO(129) | 1)
+#define PINMUX_GPIO129__FUNC_URTS2 (MTK_PIN_NO(129) | 2)
+#define PINMUX_GPIO129__FUNC_URXD5 (MTK_PIN_NO(129) | 3)
+#define PINMUX_GPIO129__FUNC_UFS_MPHY_SDA (MTK_PIN_NO(129) | 4)
+#define PINMUX_GPIO129__FUNC_mbistwriteen_trigger (MTK_PIN_NO(129) | 5)
+#define PINMUX_GPIO129__FUNC_MD32_1_GPIO1 (MTK_PIN_NO(129) | 6)
+#define PINMUX_GPIO129__FUNC_SCP_SDA2 (MTK_PIN_NO(129) | 7)
+
+#define PINMUX_GPIO130__FUNC_GPIO130 (MTK_PIN_NO(130) | 0)
+#define PINMUX_GPIO130__FUNC_IDDIG_1P (MTK_PIN_NO(130) | 1)
+#define PINMUX_GPIO130__FUNC_SPINOR_IO2 (MTK_PIN_NO(130) | 2)
+#define PINMUX_GPIO130__FUNC_SNFI_WP (MTK_PIN_NO(130) | 3)
+#define PINMUX_GPIO130__FUNC_VPU_UDI_NTRST (MTK_PIN_NO(130) | 4)
+
+#define PINMUX_GPIO131__FUNC_GPIO131 (MTK_PIN_NO(131) | 0)
+#define PINMUX_GPIO131__FUNC_USB_DRVVBUS_1P (MTK_PIN_NO(131) | 1)
+#define PINMUX_GPIO131__FUNC_SPINOR_IO3 (MTK_PIN_NO(131) | 2)
+#define PINMUX_GPIO131__FUNC_SNFI_HOLD (MTK_PIN_NO(131) | 3)
+#define PINMUX_GPIO131__FUNC_MD32_1_JTAG_TRST (MTK_PIN_NO(131) | 4)
+#define PINMUX_GPIO131__FUNC_SCP_JTAG0_TRSTN (MTK_PIN_NO(131) | 5)
+#define PINMUX_GPIO131__FUNC_APU_JTAG_TRST (MTK_PIN_NO(131) | 6)
+
+#define PINMUX_GPIO132__FUNC_GPIO132 (MTK_PIN_NO(132) | 0)
+#define PINMUX_GPIO132__FUNC_SPIM0_CSB (MTK_PIN_NO(132) | 1)
+#define PINMUX_GPIO132__FUNC_SCP_SPI0_CS (MTK_PIN_NO(132) | 2)
+#define PINMUX_GPIO132__FUNC_SPIS0_CSB (MTK_PIN_NO(132) | 3)
+#define PINMUX_GPIO132__FUNC_VPU_UDI_TMS (MTK_PIN_NO(132) | 4)
+#define PINMUX_GPIO132__FUNC_I2SO5_D0 (MTK_PIN_NO(132) | 6)
+
+#define PINMUX_GPIO133__FUNC_GPIO133 (MTK_PIN_NO(133) | 0)
+#define PINMUX_GPIO133__FUNC_SPIM0_CLK (MTK_PIN_NO(133) | 1)
+#define PINMUX_GPIO133__FUNC_SCP_SPI0_CK (MTK_PIN_NO(133) | 2)
+#define PINMUX_GPIO133__FUNC_SPIS0_CLK (MTK_PIN_NO(133) | 3)
+#define PINMUX_GPIO133__FUNC_VPU_UDI_TCK (MTK_PIN_NO(133) | 4)
+#define PINMUX_GPIO133__FUNC_I2SO5_BCK (MTK_PIN_NO(133) | 6)
+
+#define PINMUX_GPIO134__FUNC_GPIO134 (MTK_PIN_NO(134) | 0)
+#define PINMUX_GPIO134__FUNC_SPIM0_MO (MTK_PIN_NO(134) | 1)
+#define PINMUX_GPIO134__FUNC_SCP_SPI0_MO (MTK_PIN_NO(134) | 2)
+#define PINMUX_GPIO134__FUNC_SPIS0_SI (MTK_PIN_NO(134) | 3)
+#define PINMUX_GPIO134__FUNC_VPU_UDI_TDO (MTK_PIN_NO(134) | 4)
+#define PINMUX_GPIO134__FUNC_I2SO5_WS (MTK_PIN_NO(134) | 6)
+
+#define PINMUX_GPIO135__FUNC_GPIO135 (MTK_PIN_NO(135) | 0)
+#define PINMUX_GPIO135__FUNC_SPIM0_MI (MTK_PIN_NO(135) | 1)
+#define PINMUX_GPIO135__FUNC_SCP_SPI0_MI (MTK_PIN_NO(135) | 2)
+#define PINMUX_GPIO135__FUNC_SPIS0_SO (MTK_PIN_NO(135) | 3)
+#define PINMUX_GPIO135__FUNC_VPU_UDI_TDI (MTK_PIN_NO(135) | 4)
+#define PINMUX_GPIO135__FUNC_I2SO5_MCK (MTK_PIN_NO(135) | 6)
+
+#define PINMUX_GPIO136__FUNC_GPIO136 (MTK_PIN_NO(136) | 0)
+#define PINMUX_GPIO136__FUNC_SPIM1_CSB (MTK_PIN_NO(136) | 1)
+#define PINMUX_GPIO136__FUNC_SCP_SPI1_A_CS (MTK_PIN_NO(136) | 2)
+#define PINMUX_GPIO136__FUNC_SPIS1_CSB (MTK_PIN_NO(136) | 3)
+#define PINMUX_GPIO136__FUNC_MD32_1_JTAG_TMS (MTK_PIN_NO(136) | 4)
+#define PINMUX_GPIO136__FUNC_SCP_JTAG0_TMS (MTK_PIN_NO(136) | 5)
+#define PINMUX_GPIO136__FUNC_APU_JTAG_TMS (MTK_PIN_NO(136) | 6)
+#define PINMUX_GPIO136__FUNC_DBG_MON_A15 (MTK_PIN_NO(136) | 7)
+
+#define PINMUX_GPIO137__FUNC_GPIO137 (MTK_PIN_NO(137) | 0)
+#define PINMUX_GPIO137__FUNC_SPIM1_CLK (MTK_PIN_NO(137) | 1)
+#define PINMUX_GPIO137__FUNC_SCP_SPI1_A_CK (MTK_PIN_NO(137) | 2)
+#define PINMUX_GPIO137__FUNC_SPIS1_CLK (MTK_PIN_NO(137) | 3)
+#define PINMUX_GPIO137__FUNC_MD32_1_JTAG_TCK (MTK_PIN_NO(137) | 4)
+#define PINMUX_GPIO137__FUNC_SCP_JTAG0_TCK (MTK_PIN_NO(137) | 5)
+#define PINMUX_GPIO137__FUNC_APU_JTAG_TCK (MTK_PIN_NO(137) | 6)
+#define PINMUX_GPIO137__FUNC_DBG_MON_A14 (MTK_PIN_NO(137) | 7)
+
+#define PINMUX_GPIO138__FUNC_GPIO138 (MTK_PIN_NO(138) | 0)
+#define PINMUX_GPIO138__FUNC_SPIM1_MO (MTK_PIN_NO(138) | 1)
+#define PINMUX_GPIO138__FUNC_SCP_SPI1_A_MO (MTK_PIN_NO(138) | 2)
+#define PINMUX_GPIO138__FUNC_SPIS1_SI (MTK_PIN_NO(138) | 3)
+#define PINMUX_GPIO138__FUNC_MD32_1_JTAG_TDO (MTK_PIN_NO(138) | 4)
+#define PINMUX_GPIO138__FUNC_SCP_JTAG0_TDO (MTK_PIN_NO(138) | 5)
+#define PINMUX_GPIO138__FUNC_APU_JTAG_TDO (MTK_PIN_NO(138) | 6)
+#define PINMUX_GPIO138__FUNC_DBG_MON_A16 (MTK_PIN_NO(138) | 7)
+
+#define PINMUX_GPIO139__FUNC_GPIO139 (MTK_PIN_NO(139) | 0)
+#define PINMUX_GPIO139__FUNC_SPIM1_MI (MTK_PIN_NO(139) | 1)
+#define PINMUX_GPIO139__FUNC_SCP_SPI1_A_MI (MTK_PIN_NO(139) | 2)
+#define PINMUX_GPIO139__FUNC_SPIS1_SO (MTK_PIN_NO(139) | 3)
+#define PINMUX_GPIO139__FUNC_MD32_1_JTAG_TDI (MTK_PIN_NO(139) | 4)
+#define PINMUX_GPIO139__FUNC_SCP_JTAG0_TDI (MTK_PIN_NO(139) | 5)
+#define PINMUX_GPIO139__FUNC_APU_JTAG_TDI (MTK_PIN_NO(139) | 6)
+#define PINMUX_GPIO139__FUNC_DBG_MON_A17 (MTK_PIN_NO(139) | 7)
+
+#define PINMUX_GPIO140__FUNC_GPIO140 (MTK_PIN_NO(140) | 0)
+#define PINMUX_GPIO140__FUNC_SPIM2_CSB (MTK_PIN_NO(140) | 1)
+#define PINMUX_GPIO140__FUNC_SPINOR_CS (MTK_PIN_NO(140) | 2)
+#define PINMUX_GPIO140__FUNC_SNFI_CS (MTK_PIN_NO(140) | 3)
+#define PINMUX_GPIO140__FUNC_DMIC3_DAT (MTK_PIN_NO(140) | 4)
+#define PINMUX_GPIO140__FUNC_DBG_MON_A11 (MTK_PIN_NO(140) | 7)
+
+#define PINMUX_GPIO141__FUNC_GPIO141 (MTK_PIN_NO(141) | 0)
+#define PINMUX_GPIO141__FUNC_SPIM2_CLK (MTK_PIN_NO(141) | 1)
+#define PINMUX_GPIO141__FUNC_SPINOR_CK (MTK_PIN_NO(141) | 2)
+#define PINMUX_GPIO141__FUNC_SNFI_CLK (MTK_PIN_NO(141) | 3)
+#define PINMUX_GPIO141__FUNC_DMIC3_CLK (MTK_PIN_NO(141) | 4)
+#define PINMUX_GPIO141__FUNC_DBG_MON_A10 (MTK_PIN_NO(141) | 7)
+
+#define PINMUX_GPIO142__FUNC_GPIO142 (MTK_PIN_NO(142) | 0)
+#define PINMUX_GPIO142__FUNC_SPIM2_MO (MTK_PIN_NO(142) | 1)
+#define PINMUX_GPIO142__FUNC_SPINOR_IO0 (MTK_PIN_NO(142) | 2)
+#define PINMUX_GPIO142__FUNC_SNFI_MOSI (MTK_PIN_NO(142) | 3)
+#define PINMUX_GPIO142__FUNC_DMIC4_DAT (MTK_PIN_NO(142) | 4)
+#define PINMUX_GPIO142__FUNC_DBG_MON_A12 (MTK_PIN_NO(142) | 7)
+
+#define PINMUX_GPIO143__FUNC_GPIO143 (MTK_PIN_NO(143) | 0)
+#define PINMUX_GPIO143__FUNC_SPIM2_MI (MTK_PIN_NO(143) | 1)
+#define PINMUX_GPIO143__FUNC_SPINOR_IO1 (MTK_PIN_NO(143) | 2)
+#define PINMUX_GPIO143__FUNC_SNFI_MISO (MTK_PIN_NO(143) | 3)
+#define PINMUX_GPIO143__FUNC_DMIC4_CLK (MTK_PIN_NO(143) | 4)
+#define PINMUX_GPIO143__FUNC_DBG_MON_A13 (MTK_PIN_NO(143) | 7)
+
+#endif /* __MT8195-PINFUNC_H */
-- 
2.18.0

From zhiyong.tao at mediatek.com  Tue Apr 13 06:57:02 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Tue, 13 Apr 2021 13:57:02 +0800
Subject: [PATCH v4 4/4] pinctrl: add rsel setting on MT8195
In-Reply-To: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
Message-ID: <20210413055702.27535-5-zhiyong.tao@mediatek.com>

This patch provides rsel setting on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index a7500e18bb1d..66608b8d346a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
 	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_rsel_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x0c0, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x0c0, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x0c0, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x0c0, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x0c0, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x0c0, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x0c0, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x0c0, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x0c0, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x0c0, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x080, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x080, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x0e0, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x0e0, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x0e0, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x0e0, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -793,6 +812,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
 	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
+	[PINCTRL_PIN_REG_RSEL] = MTK_RANGE(mt8195_pin_rsel_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -823,6 +843,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.drive_get = mtk_pinconf_drive_get_rev1,
 	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
 	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
+	.rsel_set = mtk_pinconf_rsel_set,
+	.rsel_get = mtk_pinconf_rsel_get,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 2b51f4a9b860..d1526d0c6248 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1041,6 +1041,20 @@ int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_RSEL, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_set);
+
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_RSEL, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_get);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fd5ce9c5dcbd..570e8da7bf38 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -67,6 +67,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
 	PINCTRL_PIN_REG_DRV_ADV,
+	PINCTRL_PIN_REG_RSEL,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -237,6 +238,10 @@ struct mtk_pin_soc {
 			     const struct mtk_pin_desc *desc, u32 arg);
 	int (*adv_drive_get)(struct mtk_pinctrl *hw,
 			     const struct mtk_pin_desc *desc, u32 *val);
+	int (*rsel_set)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 arg);
+	int (*rsel_get)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 *val);
 
 	/* Specific driver data */
 	void				*driver_data;
@@ -320,5 +325,10 @@ int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
 int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 				  const struct mtk_pin_desc *desc, u32 *val);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val);
+
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..967288c28232 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -22,6 +22,8 @@
 #define MTK_PIN_CONFIG_PU_ADV	(PIN_CONFIG_END + 3)
 #define MTK_PIN_CONFIG_PD_ADV	(PIN_CONFIG_END + 4)
 #define MTK_PIN_CONFIG_DRV_ADV	(PIN_CONFIG_END + 5)
+#define MTK_PIN_CONFIG_RSEL	(PIN_CONFIG_END + 6)
+
 
 static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,tdsel",	MTK_PIN_CONFIG_TDSEL,		0},
@@ -29,6 +31,7 @@ static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,pull-up-adv", MTK_PIN_CONFIG_PU_ADV,		1},
 	{"mediatek,pull-down-adv", MTK_PIN_CONFIG_PD_ADV,	1},
 	{"mediatek,drive-strength-adv", MTK_PIN_CONFIG_DRV_ADV,	2},
+	{"mediatek,rsel",		MTK_PIN_CONFIG_RSEL,	2},
 };
 
 #ifdef CONFIG_DEBUG_FS
@@ -38,6 +41,7 @@ static const struct pin_config_item mtk_conf_items[] = {
 	PCONFDUMP(MTK_PIN_CONFIG_PU_ADV, "pu-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_PD_ADV, "pd-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_DRV_ADV, "drive-strength-adv", NULL, true),
+	PCONFDUMP(MTK_PIN_CONFIG_RSEL, "rsel", NULL, true),
 };
 #endif
 
@@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_get)
+			err = hw->soc->rsel_get(hw, desc, &ret);
+		else
+			err = -EOPNOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
@@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_set)
+			err = hw->soc->rsel_set(hw, desc, arg);
+		else
+			err = -EOPNOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
-- 
2.18.0

From hsin-hsiung.wang at mediatek.com  Tue Apr 13 06:49:49 2021
From: hsin-hsiung.wang at mediatek.com (Hsin-hsiung Wang)
Date: Tue, 13 Apr 2021 13:49:49 +0800
Subject: [PATCH v7 3/4] spmi: mediatek: Add support for MT6873/8192
In-Reply-To: <1615658453-3989-4-git-send-email-hsin-hsiung.wang@mediatek.com>
References: <1615658453-3989-1-git-send-email-hsin-hsiung.wang@mediatek.com>
 <1615658453-3989-4-git-send-email-hsin-hsiung.wang@mediatek.com>
Message-ID: <1618292989.4940.0.camel@mtksdaap41>

Hi Maintainers,
Gentle pin for this patch.

Thanks.

On Sun, 2021-03-14 at 02:00 +0800, Hsin-Hsiung Wang wrote:
> Add spmi support for MT6873/8192.
> 
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang at mediatek.com>
> ---
> changes since v6:
> - remove unused spinlock.
> - remove redundant check for slave id.
> ---
>  drivers/spmi/Kconfig         |  10 +
>  drivers/spmi/Makefile        |   2 +
>  drivers/spmi/spmi-mtk-pmif.c | 465 +++++++++++++++++++++++++++++++++++
>  3 files changed, 477 insertions(+)
>  create mode 100644 drivers/spmi/spmi-mtk-pmif.c
> 
> diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
> index a53bad541f1a..692bac98a120 100644
> --- a/drivers/spmi/Kconfig
> +++ b/drivers/spmi/Kconfig
> @@ -25,4 +25,14 @@ config SPMI_MSM_PMIC_ARB
>  	  This is required for communicating with Qualcomm PMICs and
>  	  other devices that have the SPMI interface.
>  
> +config SPMI_MTK_PMIF
> +	tristate "Mediatek SPMI Controller (PMIC Arbiter)"
> +	help
> +	  If you say yes to this option, support will be included for the
> +	  built-in SPMI PMIC Arbiter interface on Mediatek family
> +	  processors.
> +
> +	  This is required for communicating with Mediatek PMICs and
> +	  other devices that have the SPMI interface.
> +
>  endif
> diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
> index 55a94cadeffe..76fb3b3ab510 100644
> --- a/drivers/spmi/Makefile
> +++ b/drivers/spmi/Makefile
> @@ -5,3 +5,5 @@
>  obj-$(CONFIG_SPMI)	+= spmi.o
>  
>  obj-$(CONFIG_SPMI_MSM_PMIC_ARB)	+= spmi-pmic-arb.o
> +obj-$(CONFIG_SPMI_MTK_PMIF)	+= spmi-mtk-pmif.o
> +
> diff --git a/drivers/spmi/spmi-mtk-pmif.c b/drivers/spmi/spmi-mtk-pmif.c
> new file mode 100644
> index 000000000000..94c45d46ab0c
> --- /dev/null
> +++ b/drivers/spmi/spmi-mtk-pmif.c
> @@ -0,0 +1,465 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2021 MediaTek Inc.
> +
> +#include <linux/clk.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/spmi.h>
> +
> +#define SWINF_IDLE	0x00
> +#define SWINF_WFVLDCLR	0x06
> +
> +#define GET_SWINF(x)	(((x) >> 1) & 0x7)
> +
> +#define PMIF_CMD_REG_0		0
> +#define PMIF_CMD_REG		1
> +#define PMIF_CMD_EXT_REG	2
> +#define PMIF_CMD_EXT_REG_LONG	3
> +
> +#define PMIF_DELAY_US   10
> +#define PMIF_TIMEOUT_US (10 * 1000)
> +
> +#define PMIF_CHAN_OFFSET 0x5
> +
> +#define PMIF_MAX_CLKS	3
> +
> +#define SPMI_OP_ST_BUSY 1
> +
> +struct ch_reg {
> +	u32 ch_sta;
> +	u32 wdata;
> +	u32 rdata;
> +	u32 ch_send;
> +	u32 ch_rdy;
> +};
> +
> +struct pmif_data {
> +	const u32	*regs;
> +	const u32	*spmimst_regs;
> +	u32	soc_chan;
> +};
> +
> +struct pmif {
> +	void __iomem	*base;
> +	void __iomem	*spmimst_base;
> +	struct ch_reg	chan;
> +	struct clk_bulk_data clks[PMIF_MAX_CLKS];
> +	u32 nclks;
> +	const struct pmif_data *data;
> +};
> +
> +static const char * const pmif_clock_names[] = {
> +	"pmif_sys_ck", "pmif_tmr_ck", "spmimst_clk_mux",
> +};
> +
> +enum pmif_regs {
> +	PMIF_INIT_DONE,
> +	PMIF_INF_EN,
> +	PMIF_ARB_EN,
> +	PMIF_CMDISSUE_EN,
> +	PMIF_TIMER_CTRL,
> +	PMIF_SPI_MODE_CTRL,
> +	PMIF_IRQ_EVENT_EN_0,
> +	PMIF_IRQ_FLAG_0,
> +	PMIF_IRQ_CLR_0,
> +	PMIF_IRQ_EVENT_EN_1,
> +	PMIF_IRQ_FLAG_1,
> +	PMIF_IRQ_CLR_1,
> +	PMIF_IRQ_EVENT_EN_2,
> +	PMIF_IRQ_FLAG_2,
> +	PMIF_IRQ_CLR_2,
> +	PMIF_IRQ_EVENT_EN_3,
> +	PMIF_IRQ_FLAG_3,
> +	PMIF_IRQ_CLR_3,
> +	PMIF_IRQ_EVENT_EN_4,
> +	PMIF_IRQ_FLAG_4,
> +	PMIF_IRQ_CLR_4,
> +	PMIF_WDT_EVENT_EN_0,
> +	PMIF_WDT_FLAG_0,
> +	PMIF_WDT_EVENT_EN_1,
> +	PMIF_WDT_FLAG_1,
> +	PMIF_SWINF_0_STA,
> +	PMIF_SWINF_0_WDATA_31_0,
> +	PMIF_SWINF_0_RDATA_31_0,
> +	PMIF_SWINF_0_ACC,
> +	PMIF_SWINF_0_VLD_CLR,
> +	PMIF_SWINF_1_STA,
> +	PMIF_SWINF_1_WDATA_31_0,
> +	PMIF_SWINF_1_RDATA_31_0,
> +	PMIF_SWINF_1_ACC,
> +	PMIF_SWINF_1_VLD_CLR,
> +	PMIF_SWINF_2_STA,
> +	PMIF_SWINF_2_WDATA_31_0,
> +	PMIF_SWINF_2_RDATA_31_0,
> +	PMIF_SWINF_2_ACC,
> +	PMIF_SWINF_2_VLD_CLR,
> +	PMIF_SWINF_3_STA,
> +	PMIF_SWINF_3_WDATA_31_0,
> +	PMIF_SWINF_3_RDATA_31_0,
> +	PMIF_SWINF_3_ACC,
> +	PMIF_SWINF_3_VLD_CLR,
> +};
> +
> +static const u32 mt6873_regs[] = {
> +	[PMIF_INIT_DONE] =	0x0000,
> +	[PMIF_INF_EN] =		0x0024,
> +	[PMIF_ARB_EN] =		0x0150,
> +	[PMIF_CMDISSUE_EN] =	0x03B4,
> +	[PMIF_TIMER_CTRL] =	0x03E0,
> +	[PMIF_SPI_MODE_CTRL] =	0x0400,
> +	[PMIF_IRQ_EVENT_EN_0] =	0x0418,
> +	[PMIF_IRQ_FLAG_0] =	0x0420,
> +	[PMIF_IRQ_CLR_0] =	0x0424,
> +	[PMIF_IRQ_EVENT_EN_1] =	0x0428,
> +	[PMIF_IRQ_FLAG_1] =	0x0430,
> +	[PMIF_IRQ_CLR_1] =	0x0434,
> +	[PMIF_IRQ_EVENT_EN_2] =	0x0438,
> +	[PMIF_IRQ_FLAG_2] =	0x0440,
> +	[PMIF_IRQ_CLR_2] =	0x0444,
> +	[PMIF_IRQ_EVENT_EN_3] =	0x0448,
> +	[PMIF_IRQ_FLAG_3] =	0x0450,
> +	[PMIF_IRQ_CLR_3] =	0x0454,
> +	[PMIF_IRQ_EVENT_EN_4] =	0x0458,
> +	[PMIF_IRQ_FLAG_4] =	0x0460,
> +	[PMIF_IRQ_CLR_4] =	0x0464,
> +	[PMIF_WDT_EVENT_EN_0] =	0x046C,
> +	[PMIF_WDT_FLAG_0] =	0x0470,
> +	[PMIF_WDT_EVENT_EN_1] =	0x0474,
> +	[PMIF_WDT_FLAG_1] =	0x0478,
> +	[PMIF_SWINF_0_ACC] =	0x0C00,
> +	[PMIF_SWINF_0_WDATA_31_0] =	0x0C04,
> +	[PMIF_SWINF_0_RDATA_31_0] =	0x0C14,
> +	[PMIF_SWINF_0_VLD_CLR] =	0x0C24,
> +	[PMIF_SWINF_0_STA] =	0x0C28,
> +	[PMIF_SWINF_1_ACC] =	0x0C40,
> +	[PMIF_SWINF_1_WDATA_31_0] =	0x0C44,
> +	[PMIF_SWINF_1_RDATA_31_0] =	0x0C54,
> +	[PMIF_SWINF_1_VLD_CLR] =	0x0C64,
> +	[PMIF_SWINF_1_STA] =	0x0C68,
> +	[PMIF_SWINF_2_ACC] =	0x0C80,
> +	[PMIF_SWINF_2_WDATA_31_0] =	0x0C84,
> +	[PMIF_SWINF_2_RDATA_31_0] =	0x0C94,
> +	[PMIF_SWINF_2_VLD_CLR] =	0x0CA4,
> +	[PMIF_SWINF_2_STA] =	0x0CA8,
> +	[PMIF_SWINF_3_ACC] =	0x0CC0,
> +	[PMIF_SWINF_3_WDATA_31_0] =	0x0CC4,
> +	[PMIF_SWINF_3_RDATA_31_0] =	0x0CD4,
> +	[PMIF_SWINF_3_VLD_CLR] =	0x0CE4,
> +	[PMIF_SWINF_3_STA] =	0x0CE8,
> +};
> +
> +enum spmi_regs {
> +	SPMI_OP_ST_CTRL,
> +	SPMI_GRP_ID_EN,
> +	SPMI_OP_ST_STA,
> +	SPMI_MST_SAMPL,
> +	SPMI_MST_REQ_EN,
> +	SPMI_REC_CTRL,
> +	SPMI_REC0,
> +	SPMI_REC1,
> +	SPMI_REC2,
> +	SPMI_REC3,
> +	SPMI_REC4,
> +	SPMI_MST_DBG,
> +};
> +
> +static const u32 mt6873_spmi_regs[] = {
> +	[SPMI_OP_ST_CTRL] =	0x0000,
> +	[SPMI_GRP_ID_EN] =	0x0004,
> +	[SPMI_OP_ST_STA] =	0x0008,
> +	[SPMI_MST_SAMPL] =	0x000c,
> +	[SPMI_MST_REQ_EN] =	0x0010,
> +	[SPMI_REC_CTRL] =	0x0040,
> +	[SPMI_REC0] =		0x0044,
> +	[SPMI_REC1] =		0x0048,
> +	[SPMI_REC2] =		0x004c,
> +	[SPMI_REC3] =		0x0050,
> +	[SPMI_REC4] =		0x0054,
> +	[SPMI_MST_DBG] =	0x00fc,
> +};
> +
> +static u32 pmif_readl(struct pmif *arb, enum pmif_regs reg)
> +{
> +	return readl(arb->base + arb->data->regs[reg]);
> +}
> +
> +static void pmif_writel(struct pmif *arb, u32 val, enum pmif_regs reg)
> +{
> +	writel(val, arb->base + arb->data->regs[reg]);
> +}
> +
> +static void mtk_spmi_writel(struct pmif *arb, u32 val, enum spmi_regs reg)
> +{
> +	writel(val, arb->spmimst_base + arb->data->spmimst_regs[reg]);
> +}
> +
> +static bool pmif_is_fsm_vldclr(struct pmif *arb)
> +{
> +	u32 reg_rdata;
> +
> +	reg_rdata = pmif_readl(arb, arb->chan.ch_sta);
> +	return GET_SWINF(reg_rdata) == SWINF_WFVLDCLR;
> +}
> +
> +static int pmif_arb_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid)
> +{
> +	struct pmif *arb = spmi_controller_get_drvdata(ctrl);
> +	u32 rdata, cmd;
> +	int ret;
> +
> +	/* Check the opcode */
> +	if (opc < SPMI_CMD_RESET || opc > SPMI_CMD_WAKEUP)
> +		return -EINVAL;
> +
> +	cmd = opc - SPMI_CMD_RESET;
> +
> +	mtk_spmi_writel(arb, (cmd << 0x4) | sid, SPMI_OP_ST_CTRL);
> +	ret = readl_poll_timeout_atomic(arb->spmimst_base + arb->data->spmimst_regs[SPMI_OP_ST_STA],
> +					rdata, (rdata & SPMI_OP_ST_BUSY) == SPMI_OP_ST_BUSY,
> +					PMIF_DELAY_US, PMIF_TIMEOUT_US);
> +	if (ret < 0)
> +		dev_err(&ctrl->dev, "timeout, err = %d\n", ret);
> +
> +	return ret;
> +}
> +
> +static int pmif_spmi_read_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid,
> +			      u16 addr, u8 *buf, size_t len)
> +{
> +	struct pmif *arb = spmi_controller_get_drvdata(ctrl);
> +	struct ch_reg *inf_reg;
> +	int ret;
> +	u32 data, cmd;
> +
> +	/* Check for argument validation. */
> +	if (sid & ~0xf) {
> +		dev_err(&ctrl->dev, "exceed the max slv id\n");
> +		return -EINVAL;
> +	}
> +
> +	if (len > 4) {
> +		dev_err(&ctrl->dev, "pmif supports 1..4 bytes per trans, but:%zu requested", len);
> +		return -EINVAL;
> +	}
> +
> +	if (opc >= 0x60 && opc <= 0x7f)
> +		opc = PMIF_CMD_REG;
> +	else if ((opc >= 0x20 && opc <= 0x2f) || (opc >= 0x38 && opc <= 0x3f))
> +		opc = PMIF_CMD_EXT_REG_LONG;
> +	else
> +		return -EINVAL;
> +
> +	/* Wait for Software Interface FSM state to be IDLE. */
> +	inf_reg = &arb->chan;
> +	ret = readl_poll_timeout_atomic(arb->base + arb->data->regs[inf_reg->ch_sta],
> +					data, GET_SWINF(data) == SWINF_IDLE,
> +					PMIF_DELAY_US, PMIF_TIMEOUT_US);
> +	if (ret < 0) {
> +		/* set channel ready if the data has transferred */
> +		if (pmif_is_fsm_vldclr(arb))
> +			pmif_writel(arb, 1, inf_reg->ch_rdy);
> +		dev_err(&ctrl->dev, "failed to wait for SWINF_IDLE\n");
> +		goto out;
> +	}
> +
> +	/* Send the command. */
> +	cmd = (opc << 30) | (sid << 24) | ((len - 1) << 16) | addr;
> +	pmif_writel(arb, cmd, inf_reg->ch_send);
> +
> +	/*
> +	 * Wait for Software Interface FSM state to be WFVLDCLR,
> +	 * read the data and clear the valid flag.
> +	 */
> +	ret = readl_poll_timeout_atomic(arb->base + arb->data->regs[inf_reg->ch_sta],
> +					data, GET_SWINF(data) == SWINF_WFVLDCLR,
> +					PMIF_DELAY_US, PMIF_TIMEOUT_US);
> +	if (ret < 0) {
> +		dev_err(&ctrl->dev, "failed to wait for SWINF_WFVLDCLR\n");
> +		goto out;
> +	}
> +
> +	data = pmif_readl(arb, inf_reg->rdata);
> +	memcpy(buf, &data, len);
> +	pmif_writel(arb, 1, inf_reg->ch_rdy);
> +
> +out:
> +	if (ret < 0)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static int pmif_spmi_write_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid,
> +			       u16 addr, const u8 *buf, size_t len)
> +{
> +	struct pmif *arb = spmi_controller_get_drvdata(ctrl);
> +	struct ch_reg *inf_reg;
> +	int ret;
> +	u32 data, cmd;
> +
> +	if (len > 4) {
> +		dev_err(&ctrl->dev, "pmif supports 1..4 bytes per trans, but:%zu requested", len);
> +		return -EINVAL;
> +	}
> +
> +	/* Check the opcode */
> +	if (opc >= 0x40 && opc <= 0x5F)
> +		opc = PMIF_CMD_REG;
> +	else if ((opc <= 0xF) || (opc >= 0x30 && opc <= 0x37))
> +		opc = PMIF_CMD_EXT_REG_LONG;
> +	else if (opc >= 0x80)
> +		opc = PMIF_CMD_REG_0;
> +	else
> +		return -EINVAL;
> +
> +	/* Wait for Software Interface FSM state to be IDLE. */
> +	inf_reg = &arb->chan;
> +	ret = readl_poll_timeout_atomic(arb->base + arb->data->regs[inf_reg->ch_sta],
> +					data, GET_SWINF(data) == SWINF_IDLE,
> +					PMIF_DELAY_US, PMIF_TIMEOUT_US);
> +	if (ret < 0) {
> +		/* set channel ready if the data has transferred */
> +		if (pmif_is_fsm_vldclr(arb))
> +			pmif_writel(arb, 1, inf_reg->ch_rdy);
> +		dev_err(&ctrl->dev, "failed to wait for SWINF_IDLE\n");
> +		goto out;
> +	}
> +
> +	/* Set the write data. */
> +	memcpy(&data, buf, len);
> +	pmif_writel(arb, data, inf_reg->wdata);
> +
> +	/* Send the command. */
> +	cmd = (opc << 30) | BIT(29) | (sid << 24) | ((len - 1) << 16) | addr;
> +	pmif_writel(arb, cmd, inf_reg->ch_send);
> +
> +out:
> +	if (ret < 0)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static const struct pmif_data mt6873_pmif_arb = {
> +	.regs = mt6873_regs,
> +	.spmimst_regs = mt6873_spmi_regs,
> +	.soc_chan = 2,
> +};
> +
> +static int mtk_spmi_probe(struct platform_device *pdev)
> +{
> +	struct pmif *arb;
> +	struct spmi_controller *ctrl;
> +	int err, i;
> +	u32 chan_offset;
> +
> +	ctrl = spmi_controller_alloc(&pdev->dev, sizeof(*arb));
> +	if (!ctrl)
> +		return -ENOMEM;
> +
> +	arb = spmi_controller_get_drvdata(ctrl);
> +	arb->data = of_device_get_match_data(&pdev->dev);
> +	if (!arb->data) {
> +		err = -EINVAL;
> +		dev_err(&pdev->dev, "Cannot get drv_data\n");
> +		goto err_put_ctrl;
> +	}
> +
> +	arb->base = devm_platform_ioremap_resource_byname(pdev, "pmif");
> +	if (IS_ERR(arb->base)) {
> +		err = PTR_ERR(arb->base);
> +		dev_err(&pdev->dev, "pmif failed to get the remappped memory\n");
> +		goto err_put_ctrl;
> +	}
> +
> +	arb->spmimst_base = devm_platform_ioremap_resource_byname(pdev, "spmimst");
> +	if (IS_ERR(arb->spmimst_base)) {
> +		err = PTR_ERR(arb->spmimst_base);
> +		dev_err(&pdev->dev, "spmimst failed to get the remappped memory\n");
> +		goto err_put_ctrl;
> +	}
> +
> +	arb->nclks = ARRAY_SIZE(pmif_clock_names);
> +	if (arb->nclks > PMIF_MAX_CLKS) {
> +		err = -EINVAL;
> +		dev_err(&pdev->dev, "exceed the max clock numbers\n");
> +		goto err_put_ctrl;
> +	}
> +
> +	for (i = 0; i < arb->nclks; i++)
> +		arb->clks[i].id = pmif_clock_names[i];
> +
> +	err = devm_clk_bulk_get(&pdev->dev, arb->nclks, arb->clks);
> +	if (err) {
> +		dev_err(&pdev->dev, "Failed to get clocks: %d\n", err);
> +		goto err_put_ctrl;
> +	}
> +
> +	err = clk_bulk_prepare_enable(arb->nclks, arb->clks);
> +	if (err) {
> +		dev_err(&pdev->dev, "Failed to enable clocks: %d\n", err);
> +		goto err_put_ctrl;
> +	}
> +
> +	ctrl->cmd = pmif_arb_cmd;
> +	ctrl->read_cmd = pmif_spmi_read_cmd;
> +	ctrl->write_cmd = pmif_spmi_write_cmd;
> +
> +	chan_offset = PMIF_CHAN_OFFSET * arb->data->soc_chan;
> +	arb->chan.ch_sta = PMIF_SWINF_0_STA + chan_offset;
> +	arb->chan.wdata = PMIF_SWINF_0_WDATA_31_0 + chan_offset;
> +	arb->chan.rdata = PMIF_SWINF_0_RDATA_31_0 + chan_offset;
> +	arb->chan.ch_send = PMIF_SWINF_0_ACC + chan_offset;
> +	arb->chan.ch_rdy = PMIF_SWINF_0_VLD_CLR + chan_offset;
> +
> +	platform_set_drvdata(pdev, ctrl);
> +
> +	err = spmi_controller_add(ctrl);
> +	if (err)
> +		goto err_domain_remove;
> +
> +	return 0;
> +
> +err_domain_remove:
> +	clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> +err_put_ctrl:
> +	spmi_controller_put(ctrl);
> +	return err;
> +}
> +
> +static int mtk_spmi_remove(struct platform_device *pdev)
> +{
> +	struct spmi_controller *ctrl = platform_get_drvdata(pdev);
> +	struct pmif *arb = spmi_controller_get_drvdata(ctrl);
> +
> +	clk_bulk_disable_unprepare(arb->nclks, arb->clks);
> +	spmi_controller_remove(ctrl);
> +	spmi_controller_put(ctrl);
> +	return 0;
> +}
> +
> +static const struct of_device_id mtk_spmi_match_table[] = {
> +	{
> +		.compatible = "mediatek,mt6873-spmi",
> +		.data = &mt6873_pmif_arb,
> +	}, {
> +		/* sentinel */
> +	},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_spmi_match_table);
> +
> +static struct platform_driver mtk_spmi_driver = {
> +	.driver		= {
> +		.name	= "spmi-mtk",
> +		.of_match_table = of_match_ptr(mtk_spmi_match_table),
> +	},
> +	.probe		= mtk_spmi_probe,
> +	.remove		= mtk_spmi_remove,
> +};
> +module_platform_driver(mtk_spmi_driver);
> +
> +MODULE_AUTHOR("Hsin-Hsiung Wang <hsin-hsiung.wang at mediatek.com>");
> +MODULE_DESCRIPTION("MediaTek SPMI Driver");
> +MODULE_LICENSE("GPL");


From ak at linux.intel.com  Tue Apr 13 07:03:12 2021
From: ak at linux.intel.com (Andi Kleen)
Date: Mon, 12 Apr 2021 23:03:12 -0700
Subject: [PATCH v14 4/6] locking/qspinlock: Introduce starvation avoidance
 into CNA
In-Reply-To: <20210401153156.1165900-5-alex.kogan@oracle.com> (Alex Kogan's
 message of "Thu, 1 Apr 2021 11:31:54 -0400")
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
Message-ID: <87mtu2vhzz.fsf@linux.intel.com>

Alex Kogan <alex.kogan at oracle.com> writes:
>  
> +	numa_spinlock_threshold=	[NUMA, PV_OPS]
> +			Set the time threshold in milliseconds for the
> +			number of intra-node lock hand-offs before the
> +			NUMA-aware spinlock is forced to be passed to
> +			a thread on another NUMA node.	Valid values
> +			are in the [1..100] range. Smaller values result
> +			in a more fair, but less performant spinlock,
> +			and vice versa. The default value is 10.

ms granularity seems very coarse grained for this. Surely
at some point of spinning you can afford a ktime_get? But ok.

Could you turn that into a moduleparm which can be changed at runtime?
Would be strange to have to reboot just to play with this parameter

This would also make the code a lot shorter I guess.

-Andi


From ak at linux.intel.com  Tue Apr 13 07:12:13 2021
From: ak at linux.intel.com (Andi Kleen)
Date: Mon, 12 Apr 2021 23:12:13 -0700
Subject: [PATCH v14 4/6] locking/qspinlock: Introduce starvation avoidance
 into CNA
In-Reply-To: <87mtu2vhzz.fsf@linux.intel.com> (Andi Kleen's message of "Mon,
 12 Apr 2021 23:03:12 -0700")
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
Message-ID: <87im4qvhky.fsf@linux.intel.com>

Andi Kleen <ak at linux.intel.com> writes:

> Alex Kogan <alex.kogan at oracle.com> writes:
>>  
>> +	numa_spinlock_threshold=	[NUMA, PV_OPS]
>> +			Set the time threshold in milliseconds for the
>> +			number of intra-node lock hand-offs before the
>> +			NUMA-aware spinlock is forced to be passed to
>> +			a thread on another NUMA node.	Valid values
>> +			are in the [1..100] range. Smaller values result
>> +			in a more fair, but less performant spinlock,
>> +			and vice versa. The default value is 10.
>
> ms granularity seems very coarse grained for this. Surely
> at some point of spinning you can afford a ktime_get? But ok.

Actually thinking about it more using jiffies is likely broken
anyways because if the interrupts are disabled and the CPU
is running the main timer interrupts they won't increase.

cpu_clock (better than ktime_get) or sched_clock would work.

-Andi


From ruifeng.zhang0110 at gmail.com  Tue Apr 13 07:13:28 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Tue, 13 Apr 2021 14:13:28 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <87tuobmsba.mognet@arm.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
Message-ID: <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>

Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???
>
> On 12/04/21 20:20, Ruifeng Zhang wrote:
> > There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> > The MPIDR has been written to the chip register in armv8.3 format.
> > For example,
> > core0: 0000000080000000
> > core1: 0000000080000100
> > core2: 0000000080000200
> > ...
> >
> > Its cpu topology can be parsed normally on aarch64 mode (both
> > userspace and kernel work on arm64).
> >
> > The problem is when it working on aarch32 mode (both userspace and
> > kernel work on arm 32-bit),
>
> I didn't know using aarch32 elsewhere than EL0 was something actually being
> used. Do you deploy this somewhere, or do you use it for testing purposes?

In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
version, one
of them is the kernel running on EL1 using aarch32.
                          user(EL0)            kernel(EL1)
sc9863a_go      aarch32               aarch32
sc9863a            aarch64               aarch64
>
> > the cpu topology
> > will parse error because of the format is different between armv7 and armv8.3.
> > The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> > and store to the topology with armv7,
> > and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
> >
>
> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
> I couldn't find anything about MPIDR format differences:
>
>   DDI 0487G.a G8.2.113
>   """
>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
>   AArch64 System register MPIDR_EL1[31:0].
>   """
>
> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
> just the same, i.e. for both of them, with your example of:

The cortex-a7 spec DDI0464F 4.3.5
https://developer.arm.com/documentation/ddi0464/f/?lang=en

The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
the parse code is:
void store_cpu_topology(unsigned int cpuid)
{
    ...
    cpuid_topo->thread_id = -1;
    cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
    cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
    ...
}
>
>   core0: 0000000080000000
>   core1: 0000000080000100
>   core2: 0000000080000200
>   ...
>
> we'll get:
>
>   |       | aff2 | aff1 | aff0 |
>   |-------+------+------+------|
>   | Core0 |    0 |    0 |    0 |
>   | Core1 |    0 |    1 |    0 |
>   | Core2 |    0 |    2 |    0 |
>       ...
>
> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
>
>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>
> so without DT we would get:
>   |       | package_id | core_id |
>   |-------+------------+---------|
>   | Core0 |          0 |       0 |
>   | Core1 |          0 |       1 |
>   | Core2 |          0 |       2 |
>
> Whereas with an arm kernel we'll end up parsing MPIDR as:
>   |       | package_id | core_id |
>   |-------+------------+---------|
>   | Core0 |          0 |       0 |
>   | Core1 |          1 |       0 |
>   | Core2 |          2 |       0 |
>
> Did I get this right? Is this what you're observing?

Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
kernel on EL1.
>
> > In addition, I think arm should also allow customers to configure cpu
> > topologies via DT.


From yong.wu at mediatek.com  Tue Apr 13 07:04:36 2021
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 13 Apr 2021 14:04:36 +0800
Subject: [PATCH v5 04/16] memory: mtk-smi: Add device-link between
 smi-larb and smi-common
In-Reply-To: <ea7ed30f-050d-2d38-7c61-1e0c192f6ded@canonical.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
 <20210410091128.31823-5-yong.wu@mediatek.com>
 <ea7ed30f-050d-2d38-7c61-1e0c192f6ded@canonical.com>
Message-ID: <1618293876.20053.19.camel@mhfsdcap03>

On Sat, 2021-04-10 at 14:40 +0200, Krzysztof Kozlowski wrote:
> On 10/04/2021 11:11, Yong Wu wrote:
> > Normally, If the smi-larb HW need work, we should enable the smi-common
> > HW power and clock firstly.
> > This patch adds device-link between the smi-larb dev and the smi-common
> > dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
> > (smi-common-dev) will be called automatically.
> > 
> > Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
> > probe.
> > 
> > CC: Matthias Brugger <matthias.bgg at gmail.com>
> > Suggested-by: Tomasz Figa <tfiga at chromium.org>
> > Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> > ---
> >  drivers/memory/mtk-smi.c | 19 ++++++++++---------
> >  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> I understood this is a dependency for other patches, so:
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> 
> If I am wrong and I can take it via memory tree, let me know.

Hi Krzysztof,

Thanks very much for your quickly review.

I think it is ok if it go through memory tree. In the original patch, we
pm_runtime_get(smi-common-dev) in the smi-larb's pm resume callback.
This patch only use device-link do this. thus, this patch have no
function change. it only adjusts the SMI internal code flow.

In addition, [14/16] expects your Acked-by. and that one should be
merged with the others.

About the others patches, I'm not sure which tree they should go
through. they cross several trees, dt-binding/iommu/media/drm/dts.

Not sure if Matthias could have time to review and give some suggestion.

> 
> Best regards,
> Krzysztof
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From ruifeng.zhang0110 at gmail.com  Tue Apr 13 07:18:51 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Tue, 13 Apr 2021 14:18:51 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <121d5639-b827-937f-1cf0-e6c256e306db@arm.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <121d5639-b827-937f-1cf0-e6c256e306db@arm.com>
Message-ID: <CAG7+-3PDp7mQveNy8y2W2U9fYhZweEtwQT=VBLM6R0+_8Hb3bQ@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?12??? ??8:40???
>
> On 12/04/2021 14:20, Ruifeng Zhang wrote:
> > Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??7:32???
> >>
> >>
> >> Hi,
> >>
> >> On 12/04/21 15:08, Ruifeng Zhang wrote:
> >>> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
> >>>
> >>> The arm topology still parse from the MPIDR, but it is incomplete.  When
> >>> the armv8.3 cpu runs in aarch32 mode, it will parse out the wrong topology.
> >>>
> >>> armv7 (A7) mpidr is:
> >>> [11:8]      [7:2]       [1:0]
> >>> cluster     reserved    cpu
> >>>
> >>> armv8.3 (A55) mpidr is:
> >>> [23:16]     [15:8]      [7:0]
> >>> cluster     cpu         thread
> >>>
> >>> For compatibility to keep the function of get capacity from default
> >>> cputype, renamed arm parse_dt_topology to get_cputype_capacity and delete
> >>> related logic of parse from dt.
> >>> Arm using the same parse_dt_topology function as arm64.
> >>>
> >>> The arm device boot step is to look for the default cputype and get cpu
> >>> capacity firstly. Then parse the topology and capacity from dt to replace
> >>> default values.
> >>>
> >>
> >> I'm afraid I don't get it.
> >>
> >> CONFIG_COMPAT lets you run 32-bit stuff at EL0, but the kernel is still
> >> arm64. So if you take your armv8.3 system, the topology parsed by the
> >> kernel will be the same regardless of CONFIG_COMPAT.
> >>
> >> Could you elaborate on what problem you are trying to fix here?
> >
> > There is a armv8.3 cpu which should work normally both on aarch64 and aarch32.
> > The MPIDR has been written to the chip register in armv8.3 format.
> > For example,
> > core0: 0000000080000000
> > core1: 0000000080000100
> > core2: 0000000080000200
> > ...
> >
> > Its cpu topology can be parsed normally on aarch64 mode (both
> > userspace and kernel work on arm64).
> >
> > The problem is when it working on aarch32 mode (both userspace and
> > kernel work on arm 32-bit), the cpu topology
> > will parse error because of the format is different between armv7 and armv8.3.
> > The arm 32-bit driver, arch/arm/kernel/topology will parse the MPIDR
> > and store to the topology with armv7,
> > and the result is all cpu core_id is 0, the bit[1:0] of armv7 MPIDR format.
> >
> > In addition, I think arm should also allow customers to configure cpu
> > topologies via DT.
>
> This patch ruins the CPU capacity detection based on capacity-dmips-mhz
> (Documentation/devicetree/bindings/arm/cpu-capacity.txt) on my TC2 [L B
> B L L] (armv7).
>
> tip/sched/core with *mainline* multi_v7_defconfig:
>
> root at linaro-nano:~# cat /sys/devices/system/cpu/cpu*/cpu_capacity
> 516
> 1024
> 1024
> 516
> 516
>
> your patch with mainline multi_v7_defconfig:
>
> root at linaro-nano:~#  cat /sys/devices/system/cpu/cpu*/cpu_capacity
> 1024
> 1024
> 1024
> 1024
> 1024
>
>
> There are 2 capacity detection mechanism in arch/arm/kernel/topology.c:
>
> (1) cpu_efficiency (only for armv7 a15 and a7) based, relies on
> clock-frequency dt property
>
> (2) capacity-dmips-mhz dt property based
>
> I currently don't see how this different MPIDR layout leads to you code
> changes.

Thanks for your test, I will update patch-V2 to solve this problem.
>
>


From billy_tsai at aspeedtech.com  Tue Apr 13 07:27:55 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Tue, 13 Apr 2021 06:27:55 +0000
Subject: [PATCH 1/4] dt-bindings: Add bindings for aspeed pwm-tach.
In-Reply-To: <20210412125543.xhnitijeumddqdmn@pengutronix.de>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-2-billy_tsai@aspeedtech.com>
 <20210412125543.xhnitijeumddqdmn@pengutronix.de>
Message-ID: <676ABCCC-C2E8-4AC3-8A3E-F4F5084B6211@aspeedtech.com>

Hi,

Best Regards,
Billy Tsai

On 2021/4/12, 8:55 PM,Uwe Kleine-K?nigwrote:

    > Hello,

    On Mon, Apr 12, 2021 at 05:54:54PM +0800, Billy Tsai wrote:
    > +  - Billy Tsai <billy_tasi at aspeedtech.com>

    > I object because the MTA at aspeedtech.com doesn't know this email
    > address.

This is typo error, my email address is billy_tsai at aspeedtech.com
I will fix it at v2.

    > Best regards
    > Uwe

    > -- 
    > Pengutronix e.K.                           | Uwe Kleine-K?nig            |
    > Industrial Linux Solutions                 | https://www.pengutronix.de/ |


From jiapeng.chong at linux.alibaba.com  Tue Apr 13 07:36:43 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Tue, 13 Apr 2021 14:36:43 +0800
Subject: [PATCH] stm class: remove useless function
Message-ID: <1618295803-19756-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following clang warning:

drivers/hwtracing/stm/policy.c:60:21: warning: unused function
'stp_policy_node_name' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/hwtracing/stm/policy.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 603b4a99..42103c3 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -57,11 +57,6 @@ void stp_policy_node_get_ranges(struct stp_policy_node *policy_node,
 	*cend	= policy_node->last_channel;
 }
 
-static inline char *stp_policy_node_name(struct stp_policy_node *policy_node)
-{
-	return policy_node->group.cg_item.ci_name ? : "<none>";
-}
-
 static inline struct stp_policy *to_stp_policy(struct config_item *item)
 {
 	return item ?
-- 
1.8.3.1



From bot at kernelci.org  Tue Apr 13 08:16:49 2021
From: bot at kernelci.org (kernelci.org bot)
Date: Tue, 13 Apr 2021 00:16:49 -0700 (PDT)
Subject: arm64/for-kernelci build: 3 builds: 0 failed,
 3 passed (v5.12-rc7-3-ge5ff195bf600)
Message-ID: <60754561.1c69fb81.e2497.cd35@mx.google.com>

arm64/for-kernelci build: 3 builds: 0 failed, 3 passed (v5.12-rc7-3-ge5ff195bf600)

Full Build Summary: https://kernelci.org/build/arm64/branch/for-kernelci/kernel/v5.12-rc7-3-ge5ff195bf600/

Tree: arm64
Branch: for-kernelci
Git Describe: v5.12-rc7-3-ge5ff195bf600
Git Commit: e5ff195bf600fd53a254196d1e479ba57736f3ea
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
Built: 1 unique architecture

================================================================================

Detailed per-defconfig build reports:

--------------------------------------------------------------------------------
allmodconfig (arm64, gcc-8) ? PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
allnoconfig (arm64, gcc-8) ? PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) ? PASS, 0 errors, 0 warnings, 0 section mismatches

---
For more info write to <info at kernelci.org>


From billy_tsai at aspeedtech.com  Tue Apr 13 08:27:51 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Tue, 13 Apr 2021 07:27:51 +0000
Subject: [PATCH 2/4] dt-bindings: Add bindings for aspeed pwm
In-Reply-To: <1618233600.223110.3757979.nullmailer@robh.at.kernel.org>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-3-billy_tsai@aspeedtech.com>
 <1618233600.223110.3757979.nullmailer@robh.at.kernel.org>
Message-ID: <106D8276-51DF-4319-BDB4-68D1C0B2971A@aspeedtech.com>

Hi Rob,

Best Regards,
Billy Tsai

On 2021/4/12, 9:20 PM,Rob Herringwrote:

    On Mon, 12 Apr 2021 17:54:55 +0800, Billy Tsai wrote:
    >> This patch adds device bindings for aspeed pwm device which should be
    >> the sub-node of aspeed,ast2600-pwm-tach.
    >> 
    >> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
    >> ---
    >>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 47 +++++++++++++++++++
    >>  1 file changed, 47 insertions(+)
    >>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.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/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: Additional properties are not allowed ('pwm-cells' was unexpected)
    > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: Additional properties are not allowed ('pwm-cells' was unexpected)
    > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml: ignoring, error in schema: 
    > warning: no schema found in file: ./Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
    > Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.example.dt.yaml:0:0: /example-0/pwm_tach at 1e610000: failed to match any schema with compatible: ['aspeed,ast2600-pwm-tach', 'simple-mfd', 'syscon']
    > Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.example.dt.yaml:0:0: /example-0/pwm_tach at 1e610000/pwm at 0: failed to match any schema with compatible: ['aspeed,ast2600-pwm']

The yaml file have dependencies with the first patch in these series. I will squash them.

    > See https://patchwork.ozlabs.org/patch/1465116

    > This check can fail if there are any dependencies. The base for a patch
    > series is generally the most recent rc1.

    > 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.



From alexandre.torgue at foss.st.com  Tue Apr 13 08:48:10 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Tue, 13 Apr 2021 09:48:10 +0200
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
In-Reply-To: <2c410c1b-2a1d-b291-a128-c5d5979be1ef@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <b81d6a69-713f-eda7-0837-d6e80d691c6a@foss.st.com>
 <2c410c1b-2a1d-b291-a128-c5d5979be1ef@denx.de>
Message-ID: <340d32f1-3afb-2159-fa94-70a45aecd88c@foss.st.com>

Hi Marek

On 4/12/21 8:44 PM, Marek Vasut wrote:
> On 4/12/21 10:09 AM, Alexandre TORGUE wrote:
>> Hi Marek
> 
> Hello Alex,
> 
> [...]
> 
>>> All the above still only discusses the clock part of the problem. 
>>> Even if
>>> the clock cyclic dependencies could be solved, it would be necessary to
>>> resolve legacy dwmac st,eth-clk-sel and st,eth-ref-clk-sel DT properties
>>> and avoid DT ABI break.
>>
>> Thanks for those clear explanations and for this series. As discussed, 
>> this approach looks good to me as it doesn't break our current 
>> strategy for dwmac clock integration. I don't know if those cyclic 
>> redundancies will be fixed one day but we can have a look on dwmac DT 
>> properties (the gain to change them, the effort to keep the backward 
>> compatibility, code readability, ...).
>>
>> Your DT patches looks good. I'll merge them soon.
> +CC Stephen ; the DT patches depend on the clock driver changes. Would 
> it make sense to pick the clock patches through the same tree or how 
> should that be handled ?

In this situation, I prefer to wait that Stephen takes clock patches in 
his tree. Then I'll take DT ones in mine. (I assume that taking only 
clock patches will not break mp1 boot or Ethernet usage).

Regards
Alex


> 
> [...]
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From boon.leong.ong at intel.com  Tue Apr 13 08:58:14 2021
From: boon.leong.ong at intel.com (Ong, Boon Leong)
Date: Tue, 13 Apr 2021 07:58:14 +0000
Subject: [PATCH net-next 6/7] net: stmmac: Enable RX via AF_XDP zero-copy
In-Reply-To: <20210412.141916.1569200948681549246.davem@davemloft.net>
References: <20210412154130.20742-1-boon.leong.ong@intel.com>
 <20210412154130.20742-7-boon.leong.ong@intel.com>
 <20210412.141916.1569200948681549246.davem@davemloft.net>
Message-ID: <DM6PR11MB2780C26D19861F18D789B879CA4F9@DM6PR11MB2780.namprd11.prod.outlook.com>

>+	/* synchronize_rcu() needed for pending XDP buffers to drain */
>+	for (queue = 0; queue < rx_queues_cnt; queue++) {
>+		rx_q = &priv->rx_queue[queue];
>+		if (rx_q->xsk_pool) {
>+			synchronize_rcu();
>
>Are you sure this is safe here, especially via the ->ndo_setup_tc() code path?
>
Thanks for the feedback.
Will fix this in v2 by introducing below:

Introduce __stmmac_disable_all_queues() to contain the original code that
does napi_disable() and then make stmmac_setup_tc_block_cb(0 to call this.

Add stmmac_disable_all_queues() to perform synchronize_rcu() if
there is preregistered XSK pool before subsequently call 
__stmmac_disable_all_queues() to perform napi_disable(). 

After this, both stmmac_release() and stmmac_suspend() will use
stmmac_disable_all_queues().

Thx


From David.Laight at ACULAB.COM  Tue Apr 13 09:21:07 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Tue, 13 Apr 2021 08:21:07 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210412182354.GN2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210412182354.GN2531743@casper.infradead.org>
Message-ID: <e88c6b601ad644a88e3f758f53f1060c@AcuMS.aculab.com>

From: Matthew Wilcox <willy at infradead.org>
> Sent: 12 April 2021 19:24
> 
> On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> > Could you explain your intent here?
> > I worry about @index.
> >
> > As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> > (code copy-pasted below signature) which imply that the member @index
> > have to be kept intact. In above, I'm unsure @index is untouched.
> 
> Well, I tried three different approaches.  Here's the one I hated the least.
> 
> From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
> Date: Sat, 10 Apr 2021 16:12:06 -0400
> Subject: [PATCH] mm: Fix struct page layout on 32-bit systems
> 
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
> 
> We could fix this by telling the compiler to use a smaller alignment
> for the dma_addr, but that seems a little fragile.  Instead, move the
> 'flags' into the union.  That causes dma_addr to shift into the same
> bits as 'mapping', which causes problems with page_mapping() called from
> set_page_dirty() in the munmap path.  To avoid this, insert three words
> of padding and use the same bits as ->index and ->private, neither of
> which have to be cleared on free.

This all looks horribly fragile and is bound to get broken again.
Are there two problems?
1) The 'folio' structure needs to match 'rcu' part of the page
   so that it can use the same rcu list to free items.
2) Various uses of 'struct page' need to overlay fields to save space.

For (1) the rcu bit should probably be a named structure in an
anonymous union - probably in both structures.

For (2) is it worth explicitly defining the word number for each field?
So you end up with something like:
#define F(offset, member) struct { long _pad_##offset[offset]; member; }
struct page [
	union {
		struct page_rcu;
		unsigned long flags;
		F(1, unsigned long xxx);
		F(2, unsigned long yyy);
	etc.


		
...
>  		struct {	/* page_pool used by netstack */
> -			/**
> -			 * @dma_addr: might require a 64-bit value even on
> -			 * 32-bit architectures.
> -			 */
> -			dma_addr_t dma_addr;
> +			unsigned long _pp_flags;
> +			unsigned long pp_magic;
> +			unsigned long xmi;
> +			unsigned long _pp_mapping_pad;
> +			dma_addr_t dma_addr;	/* might be one or two words */
>  		};

Isn't that 6 words?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From arnd at kernel.org  Tue Apr 13 09:22:11 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 13 Apr 2021 10:22:11 +0200
Subject: [PATCH v2 16/21] ipmi: kcs_bmc: Add a "raw" character device
 interface
In-Reply-To: <e2d7268b-bdaf-45bf-bb21-a5b9f7e985a4@www.fastmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
 <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>
 <CAK8P3a3RXr5CR7DJgD9rEkN8owpPxXRgzRnPB_5LuQcHkzc4LA@mail.gmail.com>
 <e2d7268b-bdaf-45bf-bb21-a5b9f7e985a4@www.fastmail.com>
Message-ID: <CAK8P3a1VFKuewt65RUK6hFAhZYSFFVUX7_nuJLoZW2WoPXGVTw@mail.gmail.com>

On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote:
> > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > > > >
> > > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > > > > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > > > > provide a means to generate IRQs and exchange arbitrary data between a
> > > > > BMC and its host system.
> > > >
> > > > I only noticed the series after Joel asked about the DT changes on the arm
> > > > side. One question though:
> > > >
> > > > How does this related to the drivers/input/serio/ framework that also talks
> > > > to the keyboard controller for things that are not keyboards?
> > >
> > > I've taken a brief look and I feel they're somewhat closely related.
> > >
> > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton
> > > KCS drivers move under drivers/input/serio. If you squint, the i8042
> > > serio device driver has similarities with what the Aspeed and Nuvoton
> > > device drivers are providing to the KCS IPMI stack.
> >
> > After looking some more into it, I finally understood that the two are
> > rather complementary. While the  drivers/char/ipmi/kcs_bmc.c
> > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems
> > that the proposed kcs_bmc_cdev_raw.c interface would be
> > what corresponds to the other side of
> > drivers/input/serio/i8042.c+userio.c.
>
> Right. I guess the question is should we be splitting kernel subsystems
> along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe
> we can consolidate in the future if it makes sense?

We actually have a number of subsystems with somewhat overlapping
functionality. I brought up serio, because it has an abstraction for multiple
things that communicate over the keyboard controller and I thought
the problem you were trying to solve was also related to the keyboard
controller.
It is also one of multiple abstractions that allow you to connect a device
to a uart (along with serdev and tty_ldisc, probably at least one more that
you can nest above or below these).

Consolidating the kcs_bmc.c interface into something that already
exists would obviously be best, but it's not clear which of these that
should be, that depends on the fundamental properties of the hardware
interface.

> > Then again, these are also on
> > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC
> > KCS), so they would never actually talk to one another.
>
> Well, sort of I guess. On Power systems we don't use the keyboard
> controller for IPMI or keyboards, so we're just kinda exploiting the
> hardware for our own purposes.

Can you describe in an abstract form what the hardware interface
can do here and what you want from it? I wonder if it could be
part of a higher-level interface such as drivers/mailbox/ instead.

         Arnd


From zhukeqian1 at huawei.com  Tue Apr 13 09:54:51 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:51 +0800
Subject: [PATCH v3 06/12] iommu/arm-smmu-v3: Add feature detection for BBML
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-7-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

When altering a translation table descriptor of some specific reasons,
we require break-before-make procedure. But it might cause problems when
the TTD is alive. The I/O streams might not tolerate translation faults.

If the SMMU supports BBM level 1 or BBM level 2, we can change the block
size without using break-before-make sequence.

This adds feature detection for BBML, none functional change expected.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 +++++++++++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  6 ++++++
 include/linux/io-pgtable.h                  |  8 ++++++++
 3 files changed, 33 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 369c0ea7a104..443ac19c6da9 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2030,6 +2030,11 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain,
 	if (smmu->features & ARM_SMMU_FEAT_HD)
 		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_ARM_HD;
 
+	if (smmu->features & ARM_SMMU_FEAT_BBML1)
+		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_ARM_BBML1;
+	else if (smmu->features & ARM_SMMU_FEAT_BBML2)
+		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_ARM_BBML2;
+
 	pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
 	if (!pgtbl_ops)
 		return -ENOMEM;
@@ -3373,6 +3378,20 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
 
 	/* IDR3 */
 	reg = readl_relaxed(smmu->base + ARM_SMMU_IDR3);
+	switch (FIELD_GET(IDR3_BBML, reg)) {
+	case IDR3_BBML0:
+		break;
+	case IDR3_BBML1:
+		smmu->features |= ARM_SMMU_FEAT_BBML1;
+		break;
+	case IDR3_BBML2:
+		smmu->features |= ARM_SMMU_FEAT_BBML2;
+		break;
+	default:
+		dev_err(smmu->dev, "unknown/unsupported BBM behavior level\n");
+		return -ENXIO;
+	}
+
 	if (FIELD_GET(IDR3_RIL, reg))
 		smmu->features |= ARM_SMMU_FEAT_RANGE_INV;
 
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 26d6b935b383..a74125675544 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -54,6 +54,10 @@
 #define IDR1_SIDSIZE			GENMASK(5, 0)
 
 #define ARM_SMMU_IDR3			0xc
+#define IDR3_BBML			GENMASK(12, 11)
+#define IDR3_BBML0			0
+#define IDR3_BBML1			1
+#define IDR3_BBML2			2
 #define IDR3_RIL			(1 << 10)
 
 #define ARM_SMMU_IDR5			0x14
@@ -615,6 +619,8 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_E2H		(1 << 18)
 #define ARM_SMMU_FEAT_HA		(1 << 19)
 #define ARM_SMMU_FEAT_HD		(1 << 20)
+#define ARM_SMMU_FEAT_BBML1		(1 << 21)
+#define ARM_SMMU_FEAT_BBML2		(1 << 22)
 	u32				features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 64cee6831c97..9e7163ec9447 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -84,6 +84,12 @@ struct io_pgtable_cfg {
 	 *	attributes set in the TCR for a non-coherent page-table walker.
 	 *
 	 * IO_PGTABLE_QUIRK_ARM_HD: Support hardware management of dirty status.
+	 *
+	 * IO_PGTABLE_QUIRK_ARM_BBML1: ARM SMMU supports BBM Level 1 behavior
+	 *	when changing block size.
+	 *
+	 * IO_PGTABLE_QUIRK_ARM_BBML2: ARM SMMU supports BBM Level 2 behavior
+	 *	when changing block size.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
@@ -92,6 +98,8 @@ struct io_pgtable_cfg {
 	#define IO_PGTABLE_QUIRK_ARM_TTBR1	BIT(5)
 	#define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA	BIT(6)
 	#define IO_PGTABLE_QUIRK_ARM_HD		BIT(7)
+	#define IO_PGTABLE_QUIRK_ARM_BBML1	BIT(8)
+	#define IO_PGTABLE_QUIRK_ARM_BBML2	BIT(9)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:45 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:45 +0800
Subject: [PATCH v3 00/12] iommu/smmuv3: Implement hardware dirty log tracking
Message-ID: <20210413085457.25400-1-zhukeqian1@huawei.com>


This patch series is split from the series[1] that containes both IOMMU part and
VFIO part. The new VFIO part will be sent out in another series.

[1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-zhukeqian1 at huawei.com/

changelog:

v3:
 - Merge start_dirty_log and stop_dirty_log into switch_dirty_log. (Yi Sun)
 - Maintain the dirty log status in iommu_domain.
 - Update commit message to make patch easier to review.

v2:
 - Address all comments of RFC version, thanks for all of you ;-)
 - Add a bugfix that start dirty log for newly added dma ranges and domain.



Hi everyone,

This patch series introduces a framework of iommu dirty log tracking, and smmuv3
realizes this framework. This new feature can be used by VFIO dma dirty tracking.

Intention?

Some types of IOMMU are capable of tracking DMA dirty log, such as
ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
dirty log tracking framework in the IOMMU base layer.

Three new essential interfaces are added, and we maintaince the status
of dirty log tracking in iommu_domain.
1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap

About SMMU HTTU:

HTTU (Hardware Translation Table Update) is a feature of ARM SMMUv3, it can update
access flag or/and dirty state of the TTD (Translation Table Descriptor) by hardware.
With HTTU, stage1 TTD is classified into 3 types:
                        DBM bit             AP[2](readonly bit)
1. writable_clean         1                       1
2. writable_dirty         1                       0
3. readonly               0                       1

If HTTU_HD (manage dirty state) is enabled, smmu can change TTD from writable_clean to
writable_dirty. Then software can scan TTD to sync dirty state into dirty bitmap. With
this feature, we can track the dirty log of DMA continuously and precisely.

About this series:

Patch 1-3?Introduce dirty log tracking framework in the IOMMU base layer, and two common
           interfaces that can be used by many types of iommu.

Patch 4-6: Add feature detection for smmu HTTU and enable HTTU for smmu stage1 mapping.
           And add feature detection for smmu BBML. We need to split block mapping when
           start dirty log tracking and merge page mapping when stop dirty log tracking,
		   which requires break-before-make procedure. But it might cause problems when the
		   TTD is alive. The I/O streams might not tolerate translation faults. So BBML
		   should be used.

Patch 7-12: We implement these interfaces for arm smmuv3.

Thanks,
Keqian

Jean-Philippe Brucker (1):
  iommu/arm-smmu-v3: Add support for Hardware Translation Table Update

Keqian Zhu (3):
  iommu: Introduce dirty log tracking framework
  iommu: Add iommu_split_block interface
  iommu: Add iommu_merge_page interface

Kunkun Jiang (8):
  iommu/arm-smmu-v3: Enable HTTU for stage1 with io-pgtable mapping
  iommu/arm-smmu-v3: Add feature detection for BBML
  iommu/arm-smmu-v3: Realize split_block iommu ops
  iommu/arm-smmu-v3: Realize merge_page iommu ops
  iommu/arm-smmu-v3: Realize switch_dirty_log iommu ops
  iommu/arm-smmu-v3: Realize sync_dirty_log iommu ops
  iommu/arm-smmu-v3: Realize clear_dirty_log iommu ops
  iommu/arm-smmu-v3: Add HWDBM device feature reporting

 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |   2 +
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 217 +++++++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  14 +
 drivers/iommu/io-pgtable-arm.c                | 392 +++++++++++++++++-
 drivers/iommu/iommu.c                         | 266 ++++++++++++
 include/linux/io-pgtable.h                    |  23 +
 include/linux/iommu.h                         |  76 ++++
 7 files changed, 988 insertions(+), 2 deletions(-)

-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:55 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:55 +0800
Subject: [PATCH v3 10/12] iommu/arm-smmu-v3: Realize sync_dirty_log iommu ops
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-11-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

During dirty log tracking, user will try to retrieve dirty log from
iommu if it supports hardware dirty log. Scan leaf TTD and treat it
is dirty if it's writable. As we just enable HTTU for stage1, so
check whether AP[2] is not set.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 30 +++++++
 drivers/iommu/io-pgtable-arm.c              | 90 +++++++++++++++++++++
 include/linux/io-pgtable.h                  |  4 +
 3 files changed, 124 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 52c6f3e74d6f..9eb209a07acc 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2627,6 +2627,35 @@ static int arm_smmu_switch_dirty_log(struct iommu_domain *domain, bool enable,
 	return 0;
 }
 
+static int arm_smmu_sync_dirty_log(struct iommu_domain *domain,
+				   unsigned long iova, size_t size,
+				   unsigned long *bitmap,
+				   unsigned long base_iova,
+				   unsigned long bitmap_pgshift)
+{
+	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;
+
+	if (!(smmu->features & ARM_SMMU_FEAT_HD))
+		return -ENODEV;
+	if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -EINVAL;
+
+	if (!ops || !ops->sync_dirty_log) {
+		pr_err("io-pgtable don't realize sync dirty log\n");
+		return -ENODEV;
+	}
+
+	/*
+	 * Flush iotlb to ensure all inflight transactions are completed.
+	 * See doc IHI0070Da 3.13.4 "HTTU behavior summary".
+	 */
+	arm_smmu_flush_iotlb_all(domain);
+	return ops->sync_dirty_log(ops, iova, size, bitmap, base_iova,
+				   bitmap_pgshift);
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2729,6 +2758,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.split_block		= arm_smmu_split_block,
 	.merge_page		= arm_smmu_merge_page,
 	.switch_dirty_log	= arm_smmu_switch_dirty_log,
+	.sync_dirty_log		= arm_smmu_sync_dirty_log,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 9028328b99b0..67a208a05ab2 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -877,6 +877,95 @@ static size_t arm_lpae_merge_page(struct io_pgtable_ops *ops, unsigned long iova
 	return __arm_lpae_merge_page(data, iova, paddr, size, lvl, ptep, prot);
 }
 
+static int __arm_lpae_sync_dirty_log(struct arm_lpae_io_pgtable *data,
+				     unsigned long iova, size_t size,
+				     int lvl, arm_lpae_iopte *ptep,
+				     unsigned long *bitmap,
+				     unsigned long base_iova,
+				     unsigned long bitmap_pgshift)
+{
+	arm_lpae_iopte pte;
+	struct io_pgtable *iop = &data->iop;
+	size_t base, next_size;
+	unsigned long offset;
+	int nbits, ret;
+
+	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
+		return -EINVAL;
+
+	ptep += ARM_LPAE_LVL_IDX(iova, lvl, data);
+	pte = READ_ONCE(*ptep);
+	if (WARN_ON(!pte))
+		return -EINVAL;
+
+	if (size == ARM_LPAE_BLOCK_SIZE(lvl, data)) {
+		if (iopte_leaf(pte, lvl, iop->fmt)) {
+			if (pte & ARM_LPAE_PTE_AP_RDONLY)
+				return 0;
+
+			/* It is writable, set the bitmap */
+			nbits = size >> bitmap_pgshift;
+			offset = (iova - base_iova) >> bitmap_pgshift;
+			bitmap_set(bitmap, offset, nbits);
+			return 0;
+		} else {
+			/* To traverse next level */
+			next_size = ARM_LPAE_BLOCK_SIZE(lvl + 1, data);
+			ptep = iopte_deref(pte, data);
+			for (base = 0; base < size; base += next_size) {
+				ret = __arm_lpae_sync_dirty_log(data,
+						iova + base, next_size, lvl + 1,
+						ptep, bitmap, base_iova, bitmap_pgshift);
+				if (ret)
+					return ret;
+			}
+			return 0;
+		}
+	} else if (iopte_leaf(pte, lvl, iop->fmt)) {
+		if (pte & ARM_LPAE_PTE_AP_RDONLY)
+			return 0;
+
+		/* Though the size is too small, also set bitmap */
+		nbits = size >> bitmap_pgshift;
+		offset = (iova - base_iova) >> bitmap_pgshift;
+		bitmap_set(bitmap, offset, nbits);
+		return 0;
+	}
+
+	/* Keep on walkin */
+	ptep = iopte_deref(pte, data);
+	return __arm_lpae_sync_dirty_log(data, iova, size, lvl + 1, ptep,
+			bitmap, base_iova, bitmap_pgshift);
+}
+
+static int arm_lpae_sync_dirty_log(struct io_pgtable_ops *ops,
+				   unsigned long iova, size_t size,
+				   unsigned long *bitmap,
+				   unsigned long base_iova,
+				   unsigned long bitmap_pgshift)
+{
+	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+	arm_lpae_iopte *ptep = data->pgd;
+	int lvl = data->start_level;
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+	long iaext = (s64)iova >> cfg->ias;
+
+	if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
+		return -EINVAL;
+
+	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
+		iaext = ~iaext;
+	if (WARN_ON(iaext))
+		return -EINVAL;
+
+	if (data->iop.fmt != ARM_64_LPAE_S1 &&
+	    data->iop.fmt != ARM_32_LPAE_S1)
+		return -EINVAL;
+
+	return __arm_lpae_sync_dirty_log(data, iova, size, lvl, ptep,
+					 bitmap, base_iova, bitmap_pgshift);
+}
+
 static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
 {
 	unsigned long granule, page_sizes;
@@ -957,6 +1046,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
 		.iova_to_phys	= arm_lpae_iova_to_phys,
 		.split_block	= arm_lpae_split_block,
 		.merge_page	= arm_lpae_merge_page,
+		.sync_dirty_log	= arm_lpae_sync_dirty_log,
 	};
 
 	return data;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index dbee6170de7f..9e2757d12066 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -171,6 +171,10 @@ struct io_pgtable_ops {
 			      size_t size);
 	size_t (*merge_page)(struct io_pgtable_ops *ops, unsigned long iova,
 			     phys_addr_t phys, size_t size, int prot);
+	int (*sync_dirty_log)(struct io_pgtable_ops *ops,
+			      unsigned long iova, size_t size,
+			      unsigned long *bitmap, unsigned long base_iova,
+			      unsigned long bitmap_pgshift);
 };
 
 /**
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:57 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:57 +0800
Subject: [PATCH v3 12/12] iommu/arm-smmu-v3: Add HWDBM device feature reporting
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-13-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

We have implemented these interfaces required to support iommu
dirty log tracking. The last step is reporting this feature to
upper user, then the user can perform higher policy base on it.

There is a new dev feature named IOMMU_DEV_FEAT_HWDBM in iommu
layer. For arm smmuv3, it is equal to ARM_SMMU_FEAT_HD and it is
enabled by default if supported. Other types of IOMMU can enable
it by default or when user invokes enable_feature.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 ++++++
 1 file changed, 6 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 59bb1d198631..2d716ee5621f 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,9 @@ static bool arm_smmu_dev_has_feature(struct device *dev,
 	switch (feat) {
 	case IOMMU_DEV_FEAT_SVA:
 		return arm_smmu_master_sva_supported(master);
+	case IOMMU_DEV_FEAT_HWDBM:
+		/* No requirement for device, require HTTU HD of smmu */
+		return !!(master->smmu->features & ARM_SMMU_FEAT_HD);
 	default:
 		return false;
 	}
@@ -2728,6 +2731,9 @@ static bool arm_smmu_dev_feature_enabled(struct device *dev,
 	switch (feat) {
 	case IOMMU_DEV_FEAT_SVA:
 		return arm_smmu_master_sva_enabled(master);
+	case IOMMU_DEV_FEAT_HWDBM:
+		/* HTTU HD is enabled if supported */
+		return arm_smmu_dev_has_feature(dev, feat);
 	default:
 		return false;
 	}
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:48 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:48 +0800
Subject: [PATCH v3 03/12] iommu: Add iommu_merge_page interface
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-4-zhukeqian1@huawei.com>

If block(largepage) mappings are split during start dirty log, then
when stop dirty log, we need to recover them for better DMA performance.

This adds a new interface named iommu_merge_page in IOMMU base layer.
A specific IOMMU driver can invoke it during stop dirty log. If so, the
driver also need to realize the merge_page iommu ops.

We flush all iotlbs after the whole procedure is completed to ease the
pressure of iommu, as we will hanle a huge range of mapping in general.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/iommu.c | 75 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/iommu.h | 12 +++++++
 2 files changed, 87 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index bb413a927870..8f0d71bafb3a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2762,6 +2762,81 @@ int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
 }
 EXPORT_SYMBOL_GPL(iommu_split_block);
 
+static int __iommu_merge_page(struct iommu_domain *domain,
+			      unsigned long iova, phys_addr_t paddr,
+			      size_t size, int prot)
+{
+	const struct iommu_ops *ops = domain->ops;
+	unsigned int min_pagesz;
+	size_t pgsize;
+	int ret = 0;
+
+	if (unlikely(!ops || !ops->merge_page))
+		return -ENODEV;
+
+	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
+	if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
+		pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 0x%x\n",
+			iova, &paddr, size, min_pagesz);
+		return -EINVAL;
+	}
+
+	while (size) {
+		pgsize = iommu_pgsize(domain, iova | paddr, size);
+
+		ret = ops->merge_page(domain, iova, paddr, pgsize, prot);
+		if (ret)
+			break;
+
+		pr_debug("merge handled: iova 0x%lx pa %pa size 0x%zx\n",
+			 iova, &paddr, pgsize);
+
+		iova += pgsize;
+		paddr += pgsize;
+		size -= pgsize;
+	}
+
+	return ret;
+}
+
+int iommu_merge_page(struct iommu_domain *domain, unsigned long iova,
+		     size_t size, int prot)
+{
+	phys_addr_t phys;
+	dma_addr_t p, i;
+	size_t cont_size;
+	bool flush = false;
+	int ret = 0;
+
+	while (size) {
+		flush = true;
+
+		phys = iommu_iova_to_phys(domain, iova);
+		cont_size = PAGE_SIZE;
+		p = phys + cont_size;
+		i = iova + cont_size;
+
+		while (cont_size < size && p == iommu_iova_to_phys(domain, i)) {
+			p += PAGE_SIZE;
+			i += PAGE_SIZE;
+			cont_size += PAGE_SIZE;
+		}
+
+		ret = __iommu_merge_page(domain, iova, phys, cont_size, prot);
+		if (ret)
+			break;
+
+		iova += cont_size;
+		size -= cont_size;
+	}
+
+	if (flush)
+		iommu_flush_iotlb_all(domain);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_merge_page);
+
 int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
 			   unsigned long iova, size_t size, int prot)
 {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c6c90ac069e3..fea3ecabff3d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -209,6 +209,7 @@ struct iommu_iotlb_gather {
  * @domain_get_attr: Query domain attributes
  * @domain_set_attr: Change domain attributes
  * @split_block: Split block mapping into page mapping
+ * @merge_page: Merge page mapping into block mapping
  * @switch_dirty_log: Perform actions to start|stop dirty log tracking
  * @sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
  * @clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
@@ -270,6 +271,8 @@ struct iommu_ops {
 	/* Track dirty log */
 	int (*split_block)(struct iommu_domain *domain, unsigned long iova,
 			   size_t size);
+	int (*merge_page)(struct iommu_domain *domain, unsigned long iova,
+			  phys_addr_t phys, size_t size, int prot);
 	int (*switch_dirty_log)(struct iommu_domain *domain, bool enable,
 				unsigned long iova, size_t size, int prot);
 	int (*sync_dirty_log)(struct iommu_domain *domain,
@@ -534,6 +537,8 @@ extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
 			     size_t size);
+extern int iommu_merge_page(struct iommu_domain *domain, unsigned long iova,
+			    size_t size, int prot);
 extern int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
 				  unsigned long iova, size_t size, int prot);
 extern int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
@@ -940,6 +945,13 @@ static inline int iommu_split_block(struct iommu_domain *domain,
 	return -EINVAL;
 }
 
+static inline int iommu_merge_page(struct iommu_domain *domain,
+				   unsigned long iova, size_t size,
+				   int prot)
+{
+	return -EINVAL;
+}
+
 static inline int iommu_switch_dirty_log(struct iommu_domain *domain,
 					 bool enable, unsigned long iova,
 					 size_t size, int prot)
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:56 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:56 +0800
Subject: [PATCH v3 11/12] iommu/arm-smmu-v3: Realize clear_dirty_log iommu ops
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-12-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

After dirty log is retrieved, user should clear dirty log to re-enable
dirty log tracking for these dirtied pages. This clears the dirty state
(As we just enable HTTU for stage1, so set the AP[2] bit) of these leaf
TTDs that are specified by the user provided bitmap.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 25 ++++++
 drivers/iommu/io-pgtable-arm.c              | 95 +++++++++++++++++++++
 include/linux/io-pgtable.h                  |  4 +
 3 files changed, 124 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 9eb209a07acc..59bb1d198631 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2656,6 +2656,30 @@ static int arm_smmu_sync_dirty_log(struct iommu_domain *domain,
 				   bitmap_pgshift);
 }
 
+static int arm_smmu_clear_dirty_log(struct iommu_domain *domain,
+				    unsigned long iova, size_t size,
+				    unsigned long *bitmap,
+				    unsigned long base_iova,
+				    unsigned long bitmap_pgshift)
+{
+	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;
+
+	if (!(smmu->features & ARM_SMMU_FEAT_HD))
+		return -ENODEV;
+	if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -EINVAL;
+
+	if (!ops || !ops->clear_dirty_log) {
+		pr_err("io-pgtable don't realize clear dirty log\n");
+		return -ENODEV;
+	}
+
+	return ops->clear_dirty_log(ops, iova, size, bitmap, base_iova,
+				    bitmap_pgshift);
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2759,6 +2783,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.merge_page		= arm_smmu_merge_page,
 	.switch_dirty_log	= arm_smmu_switch_dirty_log,
 	.sync_dirty_log		= arm_smmu_sync_dirty_log,
+	.clear_dirty_log	= arm_smmu_clear_dirty_log,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 67a208a05ab2..e3ef0f50611c 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -966,6 +966,100 @@ static int arm_lpae_sync_dirty_log(struct io_pgtable_ops *ops,
 					 bitmap, base_iova, bitmap_pgshift);
 }
 
+static int __arm_lpae_clear_dirty_log(struct arm_lpae_io_pgtable *data,
+				      unsigned long iova, size_t size,
+				      int lvl, arm_lpae_iopte *ptep,
+				      unsigned long *bitmap,
+				      unsigned long base_iova,
+				      unsigned long bitmap_pgshift)
+{
+	arm_lpae_iopte pte;
+	struct io_pgtable *iop = &data->iop;
+	unsigned long offset;
+	size_t base, next_size;
+	int nbits, ret, i;
+
+	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
+		return -EINVAL;
+
+	ptep += ARM_LPAE_LVL_IDX(iova, lvl, data);
+	pte = READ_ONCE(*ptep);
+	if (WARN_ON(!pte))
+		return -EINVAL;
+
+	if (size == ARM_LPAE_BLOCK_SIZE(lvl, data)) {
+		if (iopte_leaf(pte, lvl, iop->fmt)) {
+			if (pte & ARM_LPAE_PTE_AP_RDONLY)
+				return 0;
+
+			/* Ensure all corresponding bits are set */
+			nbits = size >> bitmap_pgshift;
+			offset = (iova - base_iova) >> bitmap_pgshift;
+			for (i = offset; i < offset + nbits; i++) {
+				if (!test_bit(i, bitmap))
+					return 0;
+			}
+
+			/* Race does not exist */
+			pte |= ARM_LPAE_PTE_AP_RDONLY;
+			__arm_lpae_set_pte(ptep, pte, &iop->cfg);
+			return 0;
+		} else {
+			/* To traverse next level */
+			next_size = ARM_LPAE_BLOCK_SIZE(lvl + 1, data);
+			ptep = iopte_deref(pte, data);
+			for (base = 0; base < size; base += next_size) {
+				ret = __arm_lpae_clear_dirty_log(data,
+						iova + base, next_size, lvl + 1,
+						ptep, bitmap, base_iova,
+						bitmap_pgshift);
+				if (ret)
+					return ret;
+			}
+			return 0;
+		}
+	} else if (iopte_leaf(pte, lvl, iop->fmt)) {
+		/* Though the size is too small, it is already clean */
+		if (pte & ARM_LPAE_PTE_AP_RDONLY)
+			return 0;
+
+		return -EINVAL;
+	}
+
+	/* Keep on walkin */
+	ptep = iopte_deref(pte, data);
+	return __arm_lpae_clear_dirty_log(data, iova, size, lvl + 1, ptep,
+			bitmap, base_iova, bitmap_pgshift);
+}
+
+static int arm_lpae_clear_dirty_log(struct io_pgtable_ops *ops,
+				    unsigned long iova, size_t size,
+				    unsigned long *bitmap,
+				    unsigned long base_iova,
+				    unsigned long bitmap_pgshift)
+{
+	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+	arm_lpae_iopte *ptep = data->pgd;
+	int lvl = data->start_level;
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+	long iaext = (s64)iova >> cfg->ias;
+
+	if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
+		return -EINVAL;
+
+	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
+		iaext = ~iaext;
+	if (WARN_ON(iaext))
+		return -EINVAL;
+
+	if (data->iop.fmt != ARM_64_LPAE_S1 &&
+	    data->iop.fmt != ARM_32_LPAE_S1)
+		return -EINVAL;
+
+	return __arm_lpae_clear_dirty_log(data, iova, size, lvl, ptep,
+			bitmap, base_iova, bitmap_pgshift);
+}
+
 static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
 {
 	unsigned long granule, page_sizes;
@@ -1047,6 +1141,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
 		.split_block	= arm_lpae_split_block,
 		.merge_page	= arm_lpae_merge_page,
 		.sync_dirty_log	= arm_lpae_sync_dirty_log,
+		.clear_dirty_log = arm_lpae_clear_dirty_log,
 	};
 
 	return data;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 9e2757d12066..ad65b9099be6 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -175,6 +175,10 @@ struct io_pgtable_ops {
 			      unsigned long iova, size_t size,
 			      unsigned long *bitmap, unsigned long base_iova,
 			      unsigned long bitmap_pgshift);
+	int (*clear_dirty_log)(struct io_pgtable_ops *ops,
+			       unsigned long iova, size_t size,
+			       unsigned long *bitmap, unsigned long base_iova,
+			       unsigned long bitmap_pgshift);
 };
 
 /**
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:52 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:52 +0800
Subject: [PATCH v3 07/12] iommu/arm-smmu-v3: Realize split_block iommu ops
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-8-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

This splits block descriptor to an span of page descriptors. BBML1
or BBML2 feature is required.

Spliting block does not simultaneously work with other pgtable ops,
as the only designed user is vfio, which always hold a lock, so race
condition is not considered in the pgtable ops.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  27 +++++
 drivers/iommu/io-pgtable-arm.c              | 122 ++++++++++++++++++++
 include/linux/io-pgtable.h                  |   2 +
 3 files changed, 151 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 443ac19c6da9..cfa83fa03c89 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2537,6 +2537,32 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
 	return ret;
 }
 
+static int arm_smmu_split_block(struct iommu_domain *domain,
+				unsigned long iova, size_t size)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+	size_t handled_size;
+
+	if (!(smmu->features & (ARM_SMMU_FEAT_BBML1 | ARM_SMMU_FEAT_BBML2))) {
+		dev_err(smmu->dev, "don't support BBML1/2, can't split block\n");
+		return -ENODEV;
+	}
+	if (!ops || !ops->split_block) {
+		pr_err("io-pgtable don't realize split block\n");
+		return -ENODEV;
+	}
+
+	handled_size = ops->split_block(ops, iova, size);
+	if (handled_size != size) {
+		pr_err("split block failed\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2636,6 +2662,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.device_group		= arm_smmu_device_group,
 	.domain_get_attr	= arm_smmu_domain_get_attr,
 	.domain_set_attr	= arm_smmu_domain_set_attr,
+	.split_block		= arm_smmu_split_block,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 94d790b8ed27..4c4eec3c0698 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -79,6 +79,8 @@
 #define ARM_LPAE_PTE_SH_IS		(((arm_lpae_iopte)3) << 8)
 #define ARM_LPAE_PTE_NS			(((arm_lpae_iopte)1) << 5)
 #define ARM_LPAE_PTE_VALID		(((arm_lpae_iopte)1) << 0)
+/* Block descriptor bits */
+#define ARM_LPAE_PTE_NT			(((arm_lpae_iopte)1) << 16)
 
 #define ARM_LPAE_PTE_ATTR_LO_MASK	(((arm_lpae_iopte)0x3ff) << 2)
 /* Ignore the contiguous bit for block splitting */
@@ -679,6 +681,125 @@ static phys_addr_t arm_lpae_iova_to_phys(struct io_pgtable_ops *ops,
 	return iopte_to_paddr(pte, data) | iova;
 }
 
+static size_t __arm_lpae_split_block(struct arm_lpae_io_pgtable *data,
+				     unsigned long iova, size_t size, int lvl,
+				     arm_lpae_iopte *ptep);
+
+static size_t arm_lpae_do_split_blk(struct arm_lpae_io_pgtable *data,
+				    unsigned long iova, size_t size,
+				    arm_lpae_iopte blk_pte, int lvl,
+				    arm_lpae_iopte *ptep)
+{
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+	arm_lpae_iopte pte, *tablep;
+	phys_addr_t blk_paddr;
+	size_t tablesz = ARM_LPAE_GRANULE(data);
+	size_t split_sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
+	int i;
+
+	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
+		return 0;
+
+	tablep = __arm_lpae_alloc_pages(tablesz, GFP_ATOMIC, cfg);
+	if (!tablep)
+		return 0;
+
+	blk_paddr = iopte_to_paddr(blk_pte, data);
+	pte = iopte_prot(blk_pte);
+	for (i = 0; i < tablesz / sizeof(pte); i++, blk_paddr += split_sz)
+		__arm_lpae_init_pte(data, blk_paddr, pte, lvl, &tablep[i]);
+
+	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_BBML1) {
+		/* Race does not exist */
+		blk_pte |= ARM_LPAE_PTE_NT;
+		__arm_lpae_set_pte(ptep, blk_pte, cfg);
+		io_pgtable_tlb_flush_walk(&data->iop, iova, size, size);
+	}
+	/* Race does not exist */
+	pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
+
+	/* Have splited it into page? */
+	if (lvl == (ARM_LPAE_MAX_LEVELS - 1))
+		return size;
+
+	/* Go back to lvl - 1 */
+	ptep -= ARM_LPAE_LVL_IDX(iova, lvl - 1, data);
+	return __arm_lpae_split_block(data, iova, size, lvl - 1, ptep);
+}
+
+static size_t __arm_lpae_split_block(struct arm_lpae_io_pgtable *data,
+				     unsigned long iova, size_t size, int lvl,
+				     arm_lpae_iopte *ptep)
+{
+	arm_lpae_iopte pte;
+	struct io_pgtable *iop = &data->iop;
+	size_t base, next_size, total_size;
+
+	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
+		return 0;
+
+	ptep += ARM_LPAE_LVL_IDX(iova, lvl, data);
+	pte = READ_ONCE(*ptep);
+	if (WARN_ON(!pte))
+		return 0;
+
+	if (size == ARM_LPAE_BLOCK_SIZE(lvl, data)) {
+		if (iopte_leaf(pte, lvl, iop->fmt)) {
+			if (lvl == (ARM_LPAE_MAX_LEVELS - 1) ||
+			    (pte & ARM_LPAE_PTE_AP_RDONLY))
+				return size;
+
+			/* We find a writable block, split it. */
+			return arm_lpae_do_split_blk(data, iova, size, pte,
+					lvl + 1, ptep);
+		} else {
+			/* If it is the last table level, then nothing to do */
+			if (lvl == (ARM_LPAE_MAX_LEVELS - 2))
+				return size;
+
+			total_size = 0;
+			next_size = ARM_LPAE_BLOCK_SIZE(lvl + 1, data);
+			ptep = iopte_deref(pte, data);
+			for (base = 0; base < size; base += next_size)
+				total_size += __arm_lpae_split_block(data,
+						iova + base, next_size, lvl + 1,
+						ptep);
+			return total_size;
+		}
+	} else if (iopte_leaf(pte, lvl, iop->fmt)) {
+		WARN(1, "Can't split behind a block.\n");
+		return 0;
+	}
+
+	/* Keep on walkin */
+	ptep = iopte_deref(pte, data);
+	return __arm_lpae_split_block(data, iova, size, lvl + 1, ptep);
+}
+
+static size_t arm_lpae_split_block(struct io_pgtable_ops *ops,
+				   unsigned long iova, size_t size)
+{
+	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+	arm_lpae_iopte *ptep = data->pgd;
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+	int lvl = data->start_level;
+	long iaext = (s64)iova >> cfg->ias;
+
+	if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
+		return 0;
+
+	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
+		iaext = ~iaext;
+	if (WARN_ON(iaext))
+		return 0;
+
+	/* If it is smallest granule, then nothing to do */
+	if (size == ARM_LPAE_BLOCK_SIZE(ARM_LPAE_MAX_LEVELS - 1, data))
+		return size;
+
+	return __arm_lpae_split_block(data, iova, size, lvl, ptep);
+}
+
 static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
 {
 	unsigned long granule, page_sizes;
@@ -757,6 +878,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
 		.map		= arm_lpae_map,
 		.unmap		= arm_lpae_unmap,
 		.iova_to_phys	= arm_lpae_iova_to_phys,
+		.split_block	= arm_lpae_split_block,
 	};
 
 	return data;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 9e7163ec9447..47aa8f20849b 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -167,6 +167,8 @@ struct io_pgtable_ops {
 			size_t size, struct iommu_iotlb_gather *gather);
 	phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
 				    unsigned long iova);
+	size_t (*split_block)(struct io_pgtable_ops *ops, unsigned long iova,
+			      size_t size);
 };
 
 /**
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:53 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:53 +0800
Subject: [PATCH v3 08/12] iommu/arm-smmu-v3: Realize merge_page iommu ops
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-9-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

This reinstalls block mappings and unmap the span of page mappings.
BBML1 or BBML2 feature is required.

Merging page does not simultaneously work with other pgtable ops,
as the only designed user is vfio, which always hold a lock, so race
condition is not considered in the pgtable ops.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 28 ++++++++
 drivers/iommu/io-pgtable-arm.c              | 78 +++++++++++++++++++++
 include/linux/io-pgtable.h                  |  2 +
 3 files changed, 108 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 cfa83fa03c89..4d8495d88be2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2563,6 +2563,33 @@ static int arm_smmu_split_block(struct iommu_domain *domain,
 	return 0;
 }
 
+static int arm_smmu_merge_page(struct iommu_domain *domain,
+			       unsigned long iova, phys_addr_t paddr,
+			       size_t size, int prot)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+	struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+	size_t handled_size;
+
+	if (!(smmu->features & (ARM_SMMU_FEAT_BBML1 | ARM_SMMU_FEAT_BBML2))) {
+		dev_err(smmu->dev, "don't support BBML1/2, can't merge page\n");
+		return -ENODEV;
+	}
+	if (!ops || !ops->merge_page) {
+		pr_err("io-pgtable don't realize merge page\n");
+		return -ENODEV;
+	}
+
+	handled_size = ops->merge_page(ops, iova, paddr, size, prot);
+	if (handled_size != size) {
+		pr_err("merge page failed\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2663,6 +2690,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.domain_get_attr	= arm_smmu_domain_get_attr,
 	.domain_set_attr	= arm_smmu_domain_set_attr,
 	.split_block		= arm_smmu_split_block,
+	.merge_page		= arm_smmu_merge_page,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 4c4eec3c0698..9028328b99b0 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -800,6 +800,83 @@ static size_t arm_lpae_split_block(struct io_pgtable_ops *ops,
 	return __arm_lpae_split_block(data, iova, size, lvl, ptep);
 }
 
+static size_t __arm_lpae_merge_page(struct arm_lpae_io_pgtable *data,
+				    unsigned long iova, phys_addr_t paddr,
+				    size_t size, int lvl, arm_lpae_iopte *ptep,
+				    arm_lpae_iopte prot)
+{
+	arm_lpae_iopte pte, *tablep;
+	struct io_pgtable *iop = &data->iop;
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+
+	if (WARN_ON(lvl == ARM_LPAE_MAX_LEVELS))
+		return 0;
+
+	ptep += ARM_LPAE_LVL_IDX(iova, lvl, data);
+	pte = READ_ONCE(*ptep);
+	if (WARN_ON(!pte))
+		return 0;
+
+	if (size == ARM_LPAE_BLOCK_SIZE(lvl, data)) {
+		if (iopte_leaf(pte, lvl, iop->fmt))
+			return size;
+
+		/* Race does not exist */
+		if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_BBML1) {
+			prot |= ARM_LPAE_PTE_NT;
+			__arm_lpae_init_pte(data, paddr, prot, lvl, ptep);
+			io_pgtable_tlb_flush_walk(iop, iova, size,
+						  ARM_LPAE_GRANULE(data));
+
+			prot &= ~(ARM_LPAE_PTE_NT);
+			__arm_lpae_init_pte(data, paddr, prot, lvl, ptep);
+		} else {
+			__arm_lpae_init_pte(data, paddr, prot, lvl, ptep);
+		}
+
+		tablep = iopte_deref(pte, data);
+		__arm_lpae_free_pgtable(data, lvl + 1, tablep);
+		return size;
+	} else if (iopte_leaf(pte, lvl, iop->fmt)) {
+		/* The size is too small, already merged */
+		return size;
+	}
+
+	/* Keep on walkin */
+	ptep = iopte_deref(pte, data);
+	return __arm_lpae_merge_page(data, iova, paddr, size, lvl + 1, ptep, prot);
+}
+
+static size_t arm_lpae_merge_page(struct io_pgtable_ops *ops, unsigned long iova,
+				  phys_addr_t paddr, size_t size, int iommu_prot)
+{
+	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
+	arm_lpae_iopte *ptep = data->pgd;
+	int lvl = data->start_level;
+	arm_lpae_iopte prot;
+	long iaext = (s64)iova >> cfg->ias;
+
+	/* If no access, then nothing to do */
+	if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
+		return size;
+
+	if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
+		return 0;
+
+	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
+		iaext = ~iaext;
+	if (WARN_ON(iaext || paddr >> cfg->oas))
+		return 0;
+
+	/* If it is smallest granule, then nothing to do */
+	if (size == ARM_LPAE_BLOCK_SIZE(ARM_LPAE_MAX_LEVELS - 1, data))
+		return size;
+
+	prot = arm_lpae_prot_to_pte(data, iommu_prot);
+	return __arm_lpae_merge_page(data, iova, paddr, size, lvl, ptep, prot);
+}
+
 static void arm_lpae_restrict_pgsizes(struct io_pgtable_cfg *cfg)
 {
 	unsigned long granule, page_sizes;
@@ -879,6 +956,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
 		.unmap		= arm_lpae_unmap,
 		.iova_to_phys	= arm_lpae_iova_to_phys,
 		.split_block	= arm_lpae_split_block,
+		.merge_page	= arm_lpae_merge_page,
 	};
 
 	return data;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 47aa8f20849b..dbee6170de7f 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -169,6 +169,8 @@ struct io_pgtable_ops {
 				    unsigned long iova);
 	size_t (*split_block)(struct io_pgtable_ops *ops, unsigned long iova,
 			      size_t size);
+	size_t (*merge_page)(struct io_pgtable_ops *ops, unsigned long iova,
+			     phys_addr_t phys, size_t size, int prot);
 };
 
 /**
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:50 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:50 +0800
Subject: [PATCH v3 05/12] iommu/arm-smmu-v3: Enable HTTU for stage1 with
 io-pgtable mapping
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-6-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

As nested mode is not upstreamed now, we just aim to support dirty
log tracking for stage1 with io-pgtable mapping (means not support
SVA mapping). If HTTU is supported, we enable HA/HD bits in the SMMU
CD, and set DBM bit for writable TTD.

The dirty state information is encoded using the access permission
bits AP[2] (stage 1) or S2AP[1] (stage 2) in conjunction with the
DBM (Dirty Bit Modifier) bit, where DBM means writable and AP[2]/
S2AP[1] means dirty.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 +++
 drivers/iommu/io-pgtable-arm.c              | 7 ++++++-
 include/linux/io-pgtable.h                  | 3 +++
 3 files changed, 12 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 b6d965504f44..369c0ea7a104 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1921,6 +1921,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
 			  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_HA | CTXDESC_CD_0_TCR_HD |
 			  CTXDESC_CD_0_TCR_EPD1 | CTXDESC_CD_0_AA64;
 	cfg->cd.mair	= pgtbl_cfg->arm_lpae_s1_cfg.mair;
 
@@ -2026,6 +2027,8 @@ static int arm_smmu_domain_finalise(struct iommu_domain *domain,
 
 	if (smmu_domain->non_strict)
 		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+	if (smmu->features & ARM_SMMU_FEAT_HD)
+		pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_ARM_HD;
 
 	pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
 	if (!pgtbl_ops)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 87def58e79b5..94d790b8ed27 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -72,6 +72,7 @@
 
 #define ARM_LPAE_PTE_NSTABLE		(((arm_lpae_iopte)1) << 63)
 #define ARM_LPAE_PTE_XN			(((arm_lpae_iopte)3) << 53)
+#define ARM_LPAE_PTE_DBM		(((arm_lpae_iopte)1) << 51)
 #define ARM_LPAE_PTE_AF			(((arm_lpae_iopte)1) << 10)
 #define ARM_LPAE_PTE_SH_NS		(((arm_lpae_iopte)0) << 8)
 #define ARM_LPAE_PTE_SH_OS		(((arm_lpae_iopte)2) << 8)
@@ -81,7 +82,7 @@
 
 #define ARM_LPAE_PTE_ATTR_LO_MASK	(((arm_lpae_iopte)0x3ff) << 2)
 /* Ignore the contiguous bit for block splitting */
-#define ARM_LPAE_PTE_ATTR_HI_MASK	(((arm_lpae_iopte)6) << 52)
+#define ARM_LPAE_PTE_ATTR_HI_MASK	(((arm_lpae_iopte)13) << 51)
 #define ARM_LPAE_PTE_ATTR_MASK		(ARM_LPAE_PTE_ATTR_LO_MASK |	\
 					 ARM_LPAE_PTE_ATTR_HI_MASK)
 /* Software bit for solving coherency races */
@@ -379,6 +380,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova,
 static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
 					   int prot)
 {
+	struct io_pgtable_cfg *cfg = &data->iop.cfg;
 	arm_lpae_iopte pte;
 
 	if (data->iop.fmt == ARM_64_LPAE_S1 ||
@@ -386,6 +388,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
 		pte = ARM_LPAE_PTE_nG;
 		if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
 			pte |= ARM_LPAE_PTE_AP_RDONLY;
+		else if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_HD)
+			pte |= ARM_LPAE_PTE_DBM;
+
 		if (!(prot & IOMMU_PRIV))
 			pte |= ARM_LPAE_PTE_AP_UNPRIV;
 	} else {
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a4c9ca2c31f1..64cee6831c97 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -82,6 +82,8 @@ struct io_pgtable_cfg {
 	 *
 	 * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability
 	 *	attributes set in the TCR for a non-coherent page-table walker.
+	 *
+	 * IO_PGTABLE_QUIRK_ARM_HD: Support hardware management of dirty status.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
@@ -89,6 +91,7 @@ struct io_pgtable_cfg {
 	#define IO_PGTABLE_QUIRK_NON_STRICT	BIT(4)
 	#define IO_PGTABLE_QUIRK_ARM_TTBR1	BIT(5)
 	#define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA	BIT(6)
+	#define IO_PGTABLE_QUIRK_ARM_HD		BIT(7)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:49 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:49 +0800
Subject: [PATCH v3 04/12] iommu/arm-smmu-v3: Add support for Hardware
 Translation Table Update
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-5-zhukeqian1@huawei.com>

From: Jean-Philippe Brucker <jean-philippe at linaro.org>

If the SMMU supports it and the kernel was built with HTTU support,
enable hardware update of access and dirty flags. This is essential for
shared page tables, to reduce the number of access faults on the fault
queue. Normal DMA with io-pgtables doesn't currently use the access or
dirty flags.

We can enable HTTU even if CPUs don't support it, because the kernel
always checks for HW dirty bit and updates the PTE flags atomically.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  2 +
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 41 ++++++++++++++++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  8 ++++
 3 files changed, 50 insertions(+), 1 deletion(-)

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 bb251cab61f3..ae075e675892 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
@@ -121,10 +121,12 @@ static struct arm_smmu_ctx_desc *arm_smmu_alloc_shared_cd(struct mm_struct *mm)
 	if (err)
 		goto out_free_asid;
 
+	/* HA and HD will be filtered out later if not supported by the SMMU */
 	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_HA | CTXDESC_CD_0_TCR_HD |
 	      CTXDESC_CD_0_TCR_EPD1 | CTXDESC_CD_0_AA64;
 
 	switch (PAGE_SIZE) {
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 8594b4a83043..b6d965504f44 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1012,10 +1012,17 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain, int ssid,
 		 * this substream's traffic
 		 */
 	} else { /* (1) and (2) */
+		u64 tcr = cd->tcr;
+
 		cdptr[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
 		cdptr[2] = 0;
 		cdptr[3] = cpu_to_le64(cd->mair);
 
+		if (!(smmu->features & ARM_SMMU_FEAT_HD))
+			tcr &= ~CTXDESC_CD_0_TCR_HD;
+		if (!(smmu->features & ARM_SMMU_FEAT_HA))
+			tcr &= ~CTXDESC_CD_0_TCR_HA;
+
 		/*
 		 * STE is live, and the SMMU might read dwords of this CD in any
 		 * order. Ensure that it observes valid values before reading
@@ -1023,7 +1030,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain *smmu_domain, int ssid,
 		 */
 		arm_smmu_sync_cd(smmu_domain, ssid, true);
 
-		val = cd->tcr |
+		val = tcr |
 #ifdef __BIG_ENDIAN
 			CTXDESC_CD_0_ENDI |
 #endif
@@ -3196,6 +3203,28 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)
 	return 0;
 }
 
+static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg)
+{
+	u32 fw_features = smmu->features & (ARM_SMMU_FEAT_HA | ARM_SMMU_FEAT_HD);
+	u32 features = 0;
+
+	switch (FIELD_GET(IDR0_HTTU, reg)) {
+	case IDR0_HTTU_ACCESS_DIRTY:
+		features |= ARM_SMMU_FEAT_HD;
+		fallthrough;
+	case IDR0_HTTU_ACCESS:
+		features |= ARM_SMMU_FEAT_HA;
+	}
+
+	if (smmu->dev->of_node)
+		smmu->features |= features;
+	else if (features != fw_features)
+		/* ACPI IORT sets the HTTU bits */
+		dev_warn(smmu->dev,
+			 "IDR0.HTTU overridden by FW configuration (0x%x)\n",
+			 fw_features);
+}
+
 static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
 {
 	u32 reg;
@@ -3256,6 +3285,8 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
 			smmu->features |= ARM_SMMU_FEAT_E2H;
 	}
 
+	arm_smmu_get_httu(smmu, reg);
+
 	/*
 	 * The coherency feature as set by FW is used in preference to the ID
 	 * register, but warn on mismatch.
@@ -3441,6 +3472,14 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
 	if (iort_smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE)
 		smmu->features |= ARM_SMMU_FEAT_COHERENCY;
 
+	switch (FIELD_GET(ACPI_IORT_SMMU_V3_HTTU_OVERRIDE, iort_smmu->flags)) {
+	case IDR0_HTTU_ACCESS_DIRTY:
+		smmu->features |= ARM_SMMU_FEAT_HD;
+		fallthrough;
+	case IDR0_HTTU_ACCESS:
+		smmu->features |= ARM_SMMU_FEAT_HA;
+	}
+
 	return 0;
 }
 #else
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 f985817c967a..26d6b935b383 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -33,6 +33,9 @@
 #define IDR0_ASID16			(1 << 12)
 #define IDR0_ATS			(1 << 10)
 #define IDR0_HYP			(1 << 9)
+#define IDR0_HTTU			GENMASK(7, 6)
+#define IDR0_HTTU_ACCESS		1
+#define IDR0_HTTU_ACCESS_DIRTY		2
 #define IDR0_COHACC			(1 << 4)
 #define IDR0_TTF			GENMASK(3, 2)
 #define IDR0_TTF_AARCH64		2
@@ -285,6 +288,9 @@
 #define CTXDESC_CD_0_TCR_IPS		GENMASK_ULL(34, 32)
 #define CTXDESC_CD_0_TCR_TBI0		(1ULL << 38)
 
+#define CTXDESC_CD_0_TCR_HA		(1UL << 43)
+#define CTXDESC_CD_0_TCR_HD		(1UL << 42)
+
 #define CTXDESC_CD_0_AA64		(1UL << 41)
 #define CTXDESC_CD_0_S			(1UL << 44)
 #define CTXDESC_CD_0_R			(1UL << 45)
@@ -607,6 +613,8 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_BTM		(1 << 16)
 #define ARM_SMMU_FEAT_SVA		(1 << 17)
 #define ARM_SMMU_FEAT_E2H		(1 << 18)
+#define ARM_SMMU_FEAT_HA		(1 << 19)
+#define ARM_SMMU_FEAT_HD		(1 << 20)
 	u32				features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:47 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:47 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-3-zhukeqian1@huawei.com>

Block(largepage) mapping is not a proper granule for dirty log tracking.
Take an extreme example, if DMA writes one byte, under 1G mapping, the
dirty amount reported is 1G, but under 4K mapping, the dirty amount is
just 4K.

This adds a new interface named iommu_split_block in IOMMU base layer.
A specific IOMMU driver can invoke it during start dirty log. If so, the
driver also need to realize the split_block iommu ops.

We flush all iotlbs after the whole procedure is completed to ease the
pressure of IOMMU, as we will hanle a huge range of mapping in general.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/iommu.c | 41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/iommu.h | 11 +++++++++++
 2 files changed, 52 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 667b2d6d2fc0..bb413a927870 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2721,6 +2721,47 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
 
+int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
+		      size_t size)
+{
+	const struct iommu_ops *ops = domain->ops;
+	unsigned int min_pagesz;
+	size_t pgsize;
+	bool flush = false;
+	int ret = 0;
+
+	if (unlikely(!ops || !ops->split_block))
+		return -ENODEV;
+
+	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
+	if (!IS_ALIGNED(iova | size, min_pagesz)) {
+		pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
+		       iova, size, min_pagesz);
+		return -EINVAL;
+	}
+
+	while (size) {
+		flush = true;
+
+		pgsize = iommu_pgsize(domain, iova, size);
+
+		ret = ops->split_block(domain, iova, pgsize);
+		if (ret)
+			break;
+
+		pr_debug("split handled: iova 0x%lx size 0x%zx\n", iova, pgsize);
+
+		iova += pgsize;
+		size -= pgsize;
+	}
+
+	if (flush)
+		iommu_flush_iotlb_all(domain);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_split_block);
+
 int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
 			   unsigned long iova, size_t size, int prot)
 {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7f9ed9f520e2..c6c90ac069e3 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -208,6 +208,7 @@ struct iommu_iotlb_gather {
  * @device_group: find iommu group for a particular device
  * @domain_get_attr: Query domain attributes
  * @domain_set_attr: Change domain attributes
+ * @split_block: Split block mapping into page mapping
  * @switch_dirty_log: Perform actions to start|stop dirty log tracking
  * @sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
  * @clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
@@ -267,6 +268,8 @@ struct iommu_ops {
 			       enum iommu_attr attr, void *data);
 
 	/* Track dirty log */
+	int (*split_block)(struct iommu_domain *domain, unsigned long iova,
+			   size_t size);
 	int (*switch_dirty_log)(struct iommu_domain *domain, bool enable,
 				unsigned long iova, size_t size, int prot);
 	int (*sync_dirty_log)(struct iommu_domain *domain,
@@ -529,6 +532,8 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
+extern int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
+			     size_t size);
 extern int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
 				  unsigned long iova, size_t size, int prot);
 extern int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
@@ -929,6 +934,12 @@ static inline int iommu_domain_set_attr(struct iommu_domain *domain,
 	return -EINVAL;
 }
 
+static inline int iommu_split_block(struct iommu_domain *domain,
+				    unsigned long iova, size_t size)
+{
+	return -EINVAL;
+}
+
 static inline int iommu_switch_dirty_log(struct iommu_domain *domain,
 					 bool enable, unsigned long iova,
 					 size_t size, int prot)
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:46 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:46 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-2-zhukeqian1@huawei.com>

Some types of IOMMU are capable of tracking DMA dirty log, such as
ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
dirty log tracking framework in the IOMMU base layer.

Three new essential interfaces are added, and we maintaince the status
of dirty log tracking in iommu_domain.
1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap

A new dev feature are added to indicate whether a specific type of
iommu hardware supports and its driver realizes them.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/iommu.c | 150 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/iommu.h |  53 +++++++++++++++
 2 files changed, 203 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..667b2d6d2fc0 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1922,6 +1922,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
 	domain->type = type;
 	/* Assume all sizes by default; the driver may override this later */
 	domain->pgsize_bitmap  = bus->iommu_ops->pgsize_bitmap;
+	mutex_init(&domain->switch_log_lock);
 
 	return domain;
 }
@@ -2720,6 +2721,155 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
 
+int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
+			   unsigned long iova, size_t size, int prot)
+{
+	const struct iommu_ops *ops = domain->ops;
+	int ret;
+
+	if (unlikely(!ops || !ops->switch_dirty_log))
+		return -ENODEV;
+
+	mutex_lock(&domain->switch_log_lock);
+	if (enable && domain->dirty_log_tracking) {
+		ret = -EBUSY;
+		goto out;
+	} else if (!enable && !domain->dirty_log_tracking) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = ops->switch_dirty_log(domain, enable, iova, size, prot);
+	if (ret)
+		goto out;
+
+	domain->dirty_log_tracking = enable;
+out:
+	mutex_unlock(&domain->switch_log_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_switch_dirty_log);
+
+int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
+			 size_t size, unsigned long *bitmap,
+			 unsigned long base_iova, unsigned long bitmap_pgshift)
+{
+	const struct iommu_ops *ops = domain->ops;
+	unsigned int min_pagesz;
+	size_t pgsize;
+	int ret = 0;
+
+	if (unlikely(!ops || !ops->sync_dirty_log))
+		return -ENODEV;
+
+	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
+	if (!IS_ALIGNED(iova | size, min_pagesz)) {
+		pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
+		       iova, size, min_pagesz);
+		return -EINVAL;
+	}
+
+	mutex_lock(&domain->switch_log_lock);
+	if (!domain->dirty_log_tracking) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	while (size) {
+		pgsize = iommu_pgsize(domain, iova, size);
+
+		ret = ops->sync_dirty_log(domain, iova, pgsize,
+					  bitmap, base_iova, bitmap_pgshift);
+		if (ret)
+			break;
+
+		pr_debug("dirty_log_sync handle: iova 0x%lx pagesz 0x%zx\n",
+			 iova, pgsize);
+
+		iova += pgsize;
+		size -= pgsize;
+	}
+out:
+	mutex_unlock(&domain->switch_log_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_sync_dirty_log);
+
+static int __iommu_clear_dirty_log(struct iommu_domain *domain,
+				   unsigned long iova, size_t size,
+				   unsigned long *bitmap,
+				   unsigned long base_iova,
+				   unsigned long bitmap_pgshift)
+{
+	const struct iommu_ops *ops = domain->ops;
+	size_t pgsize;
+	int ret = 0;
+
+	if (unlikely(!ops || !ops->clear_dirty_log))
+		return -ENODEV;
+
+	while (size) {
+		pgsize = iommu_pgsize(domain, iova, size);
+
+		ret = ops->clear_dirty_log(domain, iova, pgsize, bitmap,
+					   base_iova, bitmap_pgshift);
+		if (ret)
+			break;
+
+		pr_debug("dirty_log_clear handled: iova 0x%lx pagesz 0x%zx\n",
+			 iova, pgsize);
+
+		iova += pgsize;
+		size -= pgsize;
+	}
+
+	return ret;
+}
+
+int iommu_clear_dirty_log(struct iommu_domain *domain,
+			  unsigned long iova, size_t size,
+			  unsigned long *bitmap, unsigned long base_iova,
+			  unsigned long bitmap_pgshift)
+{
+	unsigned long riova, rsize;
+	unsigned int min_pagesz;
+	bool flush = false;
+	int rs, re, start, end;
+	int ret = 0;
+
+	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
+	if (!IS_ALIGNED(iova | size, min_pagesz)) {
+		pr_err("unaligned: iova 0x%lx min_pagesz 0x%x\n",
+		       iova, min_pagesz);
+		return -EINVAL;
+	}
+
+	mutex_lock(&domain->switch_log_lock);
+	if (!domain->dirty_log_tracking) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	start = (iova - base_iova) >> bitmap_pgshift;
+	end = start + (size >> bitmap_pgshift);
+	bitmap_for_each_set_region(bitmap, rs, re, start, end) {
+		flush = true;
+		riova = iova + (rs << bitmap_pgshift);
+		rsize = (re - rs) << bitmap_pgshift;
+		ret = __iommu_clear_dirty_log(domain, riova, rsize, bitmap,
+					      base_iova, bitmap_pgshift);
+		if (ret)
+			break;
+	}
+
+	if (flush)
+		iommu_flush_iotlb_all(domain);
+out:
+	mutex_unlock(&domain->switch_log_lock);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_clear_dirty_log);
+
 void iommu_get_resv_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev->bus->iommu_ops;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 5e7fe519430a..7f9ed9f520e2 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -87,6 +87,8 @@ struct iommu_domain {
 	void *handler_token;
 	struct iommu_domain_geometry geometry;
 	void *iova_cookie;
+	bool dirty_log_tracking;
+	struct mutex switch_log_lock;
 };
 
 enum iommu_cap {
@@ -160,6 +162,7 @@ struct iommu_resv_region {
 enum iommu_dev_features {
 	IOMMU_DEV_FEAT_AUX,	/* Aux-domain feature */
 	IOMMU_DEV_FEAT_SVA,	/* Shared Virtual Addresses */
+	IOMMU_DEV_FEAT_HWDBM,	/* Hardware Dirty Bit Management */
 };
 
 #define IOMMU_PASID_INVALID	(-1U)
@@ -205,6 +208,9 @@ struct iommu_iotlb_gather {
  * @device_group: find iommu group for a particular device
  * @domain_get_attr: Query domain attributes
  * @domain_set_attr: Change domain attributes
+ * @switch_dirty_log: Perform actions to start|stop dirty log tracking
+ * @sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
+ * @clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
  * @get_resv_regions: Request list of reserved regions for a device
  * @put_resv_regions: Free list of reserved regions for a device
  * @apply_resv_region: Temporary helper call-back for iova reserved ranges
@@ -260,6 +266,18 @@ struct iommu_ops {
 	int (*domain_set_attr)(struct iommu_domain *domain,
 			       enum iommu_attr attr, void *data);
 
+	/* Track dirty log */
+	int (*switch_dirty_log)(struct iommu_domain *domain, bool enable,
+				unsigned long iova, size_t size, int prot);
+	int (*sync_dirty_log)(struct iommu_domain *domain,
+			      unsigned long iova, size_t size,
+			      unsigned long *bitmap, unsigned long base_iova,
+			      unsigned long bitmap_pgshift);
+	int (*clear_dirty_log)(struct iommu_domain *domain,
+			       unsigned long iova, size_t size,
+			       unsigned long *bitmap, unsigned long base_iova,
+			       unsigned long bitmap_pgshift);
+
 	/* Request/Free a list of reserved regions for a device */
 	void (*get_resv_regions)(struct device *dev, struct list_head *list);
 	void (*put_resv_regions)(struct device *dev, struct list_head *list);
@@ -511,6 +529,16 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
+extern int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
+				  unsigned long iova, size_t size, int prot);
+extern int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
+				size_t size, unsigned long *bitmap,
+				unsigned long base_iova,
+				unsigned long bitmap_pgshift);
+extern int iommu_clear_dirty_log(struct iommu_domain *domain, unsigned long iova,
+				 size_t dma_size, unsigned long *bitmap,
+				 unsigned long base_iova,
+				 unsigned long bitmap_pgshift);
 
 /* Window handling function prototypes */
 extern int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
@@ -901,6 +929,31 @@ static inline int iommu_domain_set_attr(struct iommu_domain *domain,
 	return -EINVAL;
 }
 
+static inline int iommu_switch_dirty_log(struct iommu_domain *domain,
+					 bool enable, unsigned long iova,
+					 size_t size, int prot)
+{
+	return -EINVAL;
+}
+
+static inline int iommu_sync_dirty_log(struct iommu_domain *domain,
+				       unsigned long iova, size_t size,
+				       unsigned long *bitmap,
+				       unsigned long base_iova,
+				       unsigned long pgshift)
+{
+	return -EINVAL;
+}
+
+static inline int iommu_clear_dirty_log(struct iommu_domain *domain,
+					unsigned long iova, size_t size,
+					unsigned long *bitmap,
+					unsigned long base_iova,
+					unsigned long pgshift)
+{
+	return -EINVAL;
+}
+
 static inline int  iommu_device_register(struct iommu_device *iommu)
 {
 	return -ENODEV;
-- 
2.19.1



From zhukeqian1 at huawei.com  Tue Apr 13 09:54:54 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 13 Apr 2021 16:54:54 +0800
Subject: [PATCH v3 09/12] iommu/arm-smmu-v3: Realize switch_dirty_log iommu ops
In-Reply-To: <20210413085457.25400-1-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
Message-ID: <20210413085457.25400-10-zhukeqian1@huawei.com>

From: Kunkun Jiang <jiangkunkun at huawei.com>

This realizes switch_dirty_log by invoking iommu_split_block() and
iommu_merge_page(). HTTU HD feature is required.

Co-developed-by: Keqian Zhu <zhukeqian1 at huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 38 +++++++++++++++++++++
 1 file changed, 38 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 4d8495d88be2..52c6f3e74d6f 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2590,6 +2590,43 @@ static int arm_smmu_merge_page(struct iommu_domain *domain,
 	return 0;
 }
 
+static int arm_smmu_switch_dirty_log(struct iommu_domain *domain, bool enable,
+				     unsigned long iova, size_t size, int prot)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+	if (!(smmu->features & ARM_SMMU_FEAT_HD))
+		return -ENODEV;
+	if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+		return -EINVAL;
+
+	if (enable) {
+		/*
+		 * For SMMU, the hardware dirty management is always enabled if
+		 * hardware supports HTTU HD. The action to start dirty log is
+		 * spliting block mapping.
+		 *
+		 * We don't return error even if the split operation fail, as we
+		 * can still track dirty at block granule, which is still a much
+		 * better choice compared to full dirty policy.
+		 */
+		iommu_split_block(domain, iova, size);
+	} else {
+		/*
+		 * For SMMU, the hardware dirty management is always enabled if
+		 * hardware supports HTTU HD. The action to start dirty log is
+		 * merging page mapping.
+		 *
+		 * We don't return error even if the merge operation fail, as it
+		 * just effects performace of DMA transaction.
+		 */
+		iommu_merge_page(domain, iova, size, prot);
+	}
+
+	return 0;
+}
+
 static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 {
 	return iommu_fwspec_add_ids(dev, args->args, 1);
@@ -2691,6 +2728,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.domain_set_attr	= arm_smmu_domain_set_attr,
 	.split_block		= arm_smmu_split_block,
 	.merge_page		= arm_smmu_merge_page,
+	.switch_dirty_log	= arm_smmu_switch_dirty_log,
 	.of_xlate		= arm_smmu_of_xlate,
 	.get_resv_regions	= arm_smmu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
-- 
2.19.1



From jbx6244 at gmail.com  Tue Apr 13 09:55:11 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 13 Apr 2021 10:55:11 +0200
Subject: [PATCH v2 3/3] arm64: dts: rockchip: change gpio nodenames
In-Reply-To: <CAMdYzYqTS-qEOaVsnWMSABpj5Z55An_GLCUoOZZg-fjMp9qi8w@mail.gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
 <20210412223617.8634-3-jbx6244@gmail.com>
 <CAMdYzYqTS-qEOaVsnWMSABpj5Z55An_GLCUoOZZg-fjMp9qi8w@mail.gmail.com>
Message-ID: <9fa62a53-e4f2-5032-cf1b-267e470af1c9@gmail.com>

On 4/13/21 1:22 AM, Peter Geis wrote:
> On Mon, Apr 12, 2021 at 6:38 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>>
>> Currently all gpio nodenames are sort of identical to there label.
>> Nodenames should be of a generic type, so change them all.
> 
> Currently the rockchip pinctrl driver checks np->name against the
> bank->name and if they do not match it does not set the gpio-bank as
> valid.
> The new GPIO driver appears to follow a similar method.
> This will break the driver without a correction.

Given Rob's comment in version 1 maybe combine this serie with yours?
With Heiko's blessing maybe add support both for legacy and for the new
format?

Johan

> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pinctrl/pinctrl-rockchip.c?h=next-20210412#n3836
> 
>>
>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>> ---


From liuqi115 at huawei.com  Tue Apr 13 10:12:16 2021
From: liuqi115 at huawei.com (liuqi (BA))
Date: Tue, 13 Apr 2021 17:12:16 +0800
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <fb795e51-ce01-e976-ac09-d3f384307623@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
 <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
 <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>
 <9c577f11-46e7-55a0-95e8-6c3376077049@huawei.com>
 <fb795e51-ce01-e976-ac09-d3f384307623@huawei.com>
Message-ID: <b45b5443-b0a4-3e7b-7ba6-be18eb413cba@huawei.com>


Hi John,

On 2021/4/13 1:21, John Garry wrote:
> On 12/04/2021 14:34, liuqi (BA) wrote:
>>
>> Hi John,
>>
>> Thanks for reviewing this.
>> On 2021/4/9 18:22, John Garry wrote:
>>> On 09/04/2021 10:05, Qi Liu wrote:
>>>> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
>>>> to sample bandwidth, latency, buffer occupation etc.
>>>>
>>>> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
>>>> registered as a PMU in /sys/bus/event_source/devices, so users can
>>>> select target PMU, and use filter to do further sets.
> 
> side note: it would be good to mention what baseline the series is based 
> on in the cover letter
> 
Got it, will add it, thanks.

>>>>
>>>> Filtering options contains:
>>>> event??????? - select the event.
>>>> subevent???? - select the subevent.
>>>> port???????? - select target Root Ports. Information of Root Ports
>>>> ???????????????? are shown under sysfs.
>>>> bdf????????? - select requester_id of target EP device.
>>>> trig_len???? - set trigger condition for starting event statistics.
>>>> trigger_mode - set trigger mode. 0 means starting to statistic when
>>>> ???????????????? bigger than trigger condition, and 1 means smaller.
>>>> thr_len????? - set threshold for statistics.
>>>> thr_mode???? - set threshold mode. 0 means count when bigger than
>>>> ???????????????? threshold, and 1 means smaller.
>>>>
>>>> Signed-off-by: Qi Liu <liuqi115 at huawei.com>
>>>> ---
>>>> ?? MAINTAINERS??????????????????????????????? |??? 6 +
>>>> ?? drivers/perf/Kconfig?????????????????????? |??? 2 +
>>>> ?? drivers/perf/Makefile????????????????????? |??? 1 +
>>>> ?? drivers/perf/pci/Kconfig?????????????????? |?? 16 +
>>>> ?? drivers/perf/pci/Makefile????????????????? |??? 2 +
>>>> ?? drivers/perf/pci/hisilicon/Makefile??????? |??? 5 +
>>>> ?? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1011
>>>> ++++++++++++++++++++++++++++
>>>> ?? include/linux/cpuhotplug.h???????????????? |??? 1 +
>>>> ?? 8 files changed, 1044 insertions(+)
>>>> ?? create mode 100644 drivers/perf/pci/Kconfig
>>>> ?? create mode 100644 drivers/perf/pci/Makefile
>>>> ?? create mode 100644 drivers/perf/pci/hisilicon/Makefile
>>>> ?? create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 3353de0..46c7861 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -8023,6 +8023,12 @@ W:??? http://www.hisilicon.com
>>>> ?? F:??? Documentation/admin-guide/perf/hisi-pmu.rst
>>>> ?? F:??? drivers/perf/hisilicon
>>>> +HISILICON PCIE PMU DRIVER
>>>> +M:??? Qi Liu <liuqi115 at huawei.com>
>>>> +S:??? Maintained
>>>> +F:??? Documentation/admin-guide/perf/hisi-pcie-pmu.rst
>>>
>>> nit: this does not exist yet...
>>>
>> thanks, I'll move this add-maintainer-part to the second patch.
> 
> that's why I advocate the documentation first :)
ok, I'll move document as the first patch.
> 
>>>> +F:??? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>>> +
>>>> ?? HISILICON QM AND ZIP Controller DRIVER
>>>> ?? M:??? Zhou Wang <wangzhou1 at hisilicon.com>
>>>> ?? L:??? linux-crypto at vger.kernel.org
>>>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
>>>> index 3075cf1..99d4760 100644
>>>> --- a/drivers/perf/Kconfig
>>>> +++ b/drivers/perf/Kconfig
>>>> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>>>> ?? source "drivers/perf/hisilicon/Kconfig"
>>>> +source "drivers/perf/pci/Kconfig"
>>>> +
>>>> ?? endmenu
>>>> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
>>>> index 5260b11..1208c08 100644
>>>> --- a/drivers/perf/Makefile
>>>> +++ b/drivers/perf/Makefile
>>>> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>>>> ?? obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>>>> ?? obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>>>> ?? obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
>>>> +obj-y += pci/
>>>> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
>>>> new file mode 100644
>>>> index 0000000..a119486
>>>> --- /dev/null
>>>> +++ b/drivers/perf/pci/Kconfig
>>>> @@ -0,0 +1,16 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>> +#
>>>> +# PCIe Performance Monitor Drivers
>>>> +#
>>>> +menu "PCIe Performance Monitor"
>>>> +
>>>> +config HISI_PCIE_PMU
>>>> +??? tristate "HiSilicon PCIE PERF PMU"
>>>> +??? depends on ARM64 && PCI && HISI_PMU
>>>
>>> What from HISI_PMU is needed? I couldn't find anything here
>> The event_sysfs_show() and format_sysfs_show() function of
>> hisi_uncore_pmu.h can be reused in hisi_pcie_pmu.c, So I add path in
>> Makefile and include "hisi_uncore_pmu.h".
> 
> Right, but it would be nice to be able to build this under COMPILE_TEST. 
> CONFIG_HISI_PMU cannot be built under COMPILE_TEST, so nice to not 
> depend on it.
> 
> So you could put hisi_event_sysfs_show() as a static inline in 
> hisi_uncore_pmu.h, so the dependency can be removed
> 
> Having said that, there is nothing really hisi specific in those 
> functions like hisi_event_sysfs_show().
> 
> Can't we just create generic functions here?
> 
> hisi_event_sysfs_show() == cci400_pmu_cycle_event_show() == 
> xgene_pmu_event_show()
> 
Got it, will address this.
>>
>>>
>>>> +??? help
>>>> +????? Provide support for HiSilicon PCIe performance monitoring unit
>>>> (PMU)
>>>> +????? RCiEP devices.
>>>> +????? Adds the PCIe PMU into perf events system for monitoring 
>>>> latency,
>>>> +????? bandwidth etc.
>>>> +
> 
> 
> 
> 
>
[...]
>>>> +static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
>>>> +?????????????????????? struct hisi_pcie_pmu *pcie_pmu)
>>>> +{
>>>> +??? u32 subev_idx = hisi_pcie_get_subevent(event);
>>>> +??? u32 event_idx = hisi_pcie_get_event(event);
>>>> +??? u32 requester_id = hisi_pcie_get_bdf(event);
>>>> +
>>>> +??? if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
>>>> +??????? event_idx > HISI_PCIE_EVENT_MAX) {
>>>> +??????? pci_err(pcie_pmu->pdev,
>>>> +??????????? "Max event index and max subevent index is: %d, %d.\n",
>>>> +??????????? HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
>>>
>>> if this is just going to be fed back to userspace, I don't see why we
>>> need a kernel log
>>>
>>> and the only caller also triggers an error message, which I doubt is 
>>> needed
>>>
>> Print out the HISI_PCIE_EVENT_MAX and HISI_PCIE_SUBEVENT_MAX here may be
>> more convenient for users to get the right value.
>> If you this is redundant I'll remove it. :)
> 
> Don't we already tell this to userspace?
> 
"event" is a 8-bit filter, its max value is 0xff, but PCIE PMU only have 
0xa2 events? So if users input "event=0xa3", userspace only printout 
"<not supported>".
Perhaps driver could tell users the max value of event index here.
If you think this is redundant I'll remove it. :)


>>>> +??????? return false;
>>>> +??? }
>>>> +
>>>> +??? if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
>>>> +??????? return false;
>>>> +
>>>> +??? if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
>>>> +??????? return false;
>>>> +
>>>> +??? if (requester_id) {
>>>> +??????? if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, 
>>>> requester_id)) {
>>>> +??????????? pci_err(pcie_pmu->pdev, "Invalid requester id.\n");
>>>
>>> see previous comments
>>>
>>>> +??????????? return false;
>>>> +??????? }
>>>> +??? }
>>>> +
>>>> +??? return true;
>>>> +}
>>>> +
>>>> +static bool hisi_pcie_pmu_validate_event_group(struct perf_event 
>>>> *event)
>>>> +{
>>>> +??? struct perf_event *sibling, *leader = event->group_leader;
>>>> +??? int counters = 1;
>>>> +
>>>> +??? if (!is_software_event(leader)) {
>>>> +??????? if (leader->pmu != event->pmu)
>>>> +??????????? return false;
>>>> +
>>>> +??????? if (leader != event)
>>>> +??????????? counters++;
>>>> +??? }
>>>> +
>>>> +??? for_each_sibling_event(sibling, event->group_leader) {
>>>> +??????? if (is_software_event(sibling))
>>>> +??????????? continue;
>>>> +
>>>> +??????? if (sibling->pmu != event->pmu)
>>>> +??????????? return false;
>>>> +
>>>> +??????? counters++;
>>>> +??? }
>>>> +
>>>> +??? return counters <= HISI_PCIE_MAX_COUNTERS;
>>>> +}
>>>> +
>>>> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
>>>> +{
>>>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>>>> +
>>>> +??? event->cpu = cpumask_first(&pcie_pmu->cpumask);
>>>> +
>>>> +??? if (event->attr.type != event->pmu->type)
>>>> +??????? return -ENOENT;
>>>> +
>>>> +??? /* Sampling is not supported. */
>>>> +??? if (is_sampling_event(event) || event->attach_state &
>>>> PERF_ATTACH_TASK)
>>>> +??????? return -EOPNOTSUPP;
>>>> +
>>>> +??? /* Per-task mode is not supported. */
>>>> +??? if (event->cpu < 0)
>>>
>>> cpumask_first() gives an unsigned int - this can never happen
> 
> please fix this!
> 
Sorry, missed it yesterday. I'll fix this next version.
>>>
>>>> +??????? return -EINVAL;
>>>> +
>>>> +??? if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
>>>> +??????? pci_err(pcie_pmu->pdev, "Invalid filter!\n");
>>>> +??????? return -EINVAL;
>>>> +??? }
>>>> +
>>>> +??? if (!hisi_pcie_pmu_validate_event_group(event))
>>>> +??????? return -EINVAL;
>>>> +
>>>> +??? return 0;
>>>> +}
>>>> +
>>>> +static u64 hisi_pcie_pmu_process_data(struct perf_event *event, u64 
>>>> val,
> 
> 
...
> 
>>>> +
>>>> +static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
>>>> +???????????????????? struct hisi_pcie_pmu *pcie_pmu)
>>>> +{
>>>> +??? free_irq(pcie_pmu->irq, pcie_pmu);
>>>> +??? pci_free_irq_vectors(pdev);
>>>> +}
>>>> +
>>>> +static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct
>>>> hlist_node *node)
>>>> +{
>>>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>>>> +???????????????????? struct hisi_pcie_pmu, node);
>>>> +
>>>> +??? if (cpumask_empty(&pcie_pmu->cpumask)) {
>>>> +??????? cpumask_set_cpu(cpu, &pcie_pmu->cpumask);
>>>> +??????? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, 
>>>> cpumask_of(cpu)));
>>>> +??? }
>>>> +
>>>> +??? return 0;
>>>> +}
>>>> +
>>>> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct
>>>> hlist_node *node)
>>>> +{
>>>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>>>> +???????????????????? struct hisi_pcie_pmu, node);
>>>> +??? unsigned int target;
>>>> +
>>>> +??? if (!cpumask_test_and_clear_cpu(cpu, &pcie_pmu->cpumask))
>>>
>>> I do wonder why we even need maintain pcie_pmu->cpumask
>>>
>>> Can't we just use cpu_online_mask as appropiate instead?
> 
> ?
Sorry, missed it yesterday.
It seems that cpumask is always same as cpu_online_mask, So do we need 
to reserve the cpumask sysfs interface?

Thanks,
Qi
> 
>>>
>>>> +??????? return 0;
>>>> +
>>>> +??? /* Choose a new CPU from all online cpus. */
>>>> +??? target = cpumask_any_but(cpu_online_mask, cpu);
>>>> +??? if (target >= nr_cpu_ids)
>>>> +??????? return 0;
>>>> +
>>>> +??? perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
>>>> +??? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
>>>> +
>>>> +??? return 0;
>>>> +}
>>>> +
> 
> .



From arnd at arndb.de  Tue Apr 13 10:17:31 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 13 Apr 2021 11:17:31 +0200
Subject: [PATCH] ARM: defconfig: gemini: Update defconfig
In-Reply-To: <20210412134700.1977619-1-linus.walleij@linaro.org>
References: <20210412134700.1977619-1-linus.walleij@linaro.org>
Message-ID: <CAK8P3a1yKNF9NkRZNKtySjFKZ2WzLKrk0B+XkcmH3A=awi6C7g@mail.gmail.com>

On Mon, Apr 12, 2021 at 3:47 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> Update the Gemini defconfig: some moved options, added som
> WLAN drivers existing on the supported platforms and enabled
> the drivetemp sensor which is used on the NAS devices.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

I don't like patches that mix functional changes with what comes down
to whitespace. Can you resend this one as a series?

At the minimum, make one patch that adds BFQ, DRIVETEMP
and WLAN changes and another one that moves options
around that change after 'savedefconfig'.

For the CONFIG_ENABLE_MUST_CHECK removal, can you
send a patch that removes this line from all defconfig files at once?

      Arnd


From billy_tsai at aspeedtech.com  Tue Apr 13 10:24:45 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Tue, 13 Apr 2021 09:24:45 +0000
Subject: [PATCH 3/4] pwm: Add Aspeed ast2600 PWM support
In-Reply-To: <20210412123502.v77fvmi3awvbmduu@pengutronix.de>
References: <20210412095457.15095-1-billy_tsai@aspeedtech.com>
 <20210412095457.15095-4-billy_tsai@aspeedtech.com>
 <20210412123502.v77fvmi3awvbmduu@pengutronix.de>
Message-ID: <EF35BD1B-0FD8-487C-9FE7-EFB9E481F434@aspeedtech.com>

Thanks for your review

Best Regards,
Billy Tsai

On 2021/4/12, 8:35 PM,Uwe Kleine-K?nigwrote:

    Hello Billy,

    On Mon, Apr 12, 2021 at 05:54:56PM +0800, Billy Tsai wrote:
    >> This patch add the support of PWM controller which can find at aspeed
    >> ast2600 soc chip. This controller supoorts up to 16 channels.
    >> 
    >> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
    >> ---
    >>  drivers/pwm/pwm-aspeed-g6.c | 291 ++++++++++++++++++++++++++++++++++++
    >>  1 file changed, 291 insertions(+)
    >>  create mode 100644 drivers/pwm/pwm-aspeed-g6.c
    >> 
    >> diff --git a/drivers/pwm/pwm-aspeed-g6.c b/drivers/pwm/pwm-aspeed-g6.c
    >> new file mode 100644
    >> index 000000000000..4bb4f97453c6
    >> --- /dev/null
    >> +++ b/drivers/pwm/pwm-aspeed-g6.c
    >> @@ -0,0 +1,291 @@
    >> +// SPDX-License-Identifier: GPL-2.0-only
    >> +/*
    >> + * Copyright (C) ASPEED Technology Inc.

    > Don't you need to add a year here?

Got it.

    >> + * This program is free software; you can redistribute it and/or modify
    >> + * it under the terms of the GNU General Public License version 2 or later as
    >> + * published by the Free Software Foundation.

    > Hmm, the comment and the SPDX-License-Identifier contradict each other.
    > The idea of the latter is that the former isn't needed.

I will use "// SPDX-License-Identifier: GPL-2.0-or-later" for the license.

    >> + */

    > Is there documentation available in the internet for this hardware? If
    > yes, please mention a link here.

Sorry we don't have the hardware document in the internet.

    > Also describe the hardware here similar to how e.g.
    > drivers/pwm/pwm-sifive.c does it. Please stick to the same format for
    > easy grepping.

Got it.

    >> +
    >> +#include <linux/clk.h>
    >> +#include <linux/errno.h>
    >> +#include <linux/delay.h>
    >> +#include <linux/io.h>
    >> +#include <linux/kernel.h>
    >> +#include <linux/mfd/syscon.h>
    >> +#include <linux/module.h>
    >> +#include <linux/of_platform.h>
    >> +#include <linux/of_device.h>
    >> +#include <linux/platform_device.h>
    >> +#include <linux/sysfs.h>
    >> +#include <linux/reset.h>
    >> +#include <linux/regmap.h>
    >> +#include <linux/pwm.h>
    >> +/* The channel number of Aspeed pwm controller */
    >> +#define ASPEED_NR_PWMS 16
    >> +/* PWM Control Register */
    >> +#define ASPEED_PWM_CTRL_CH(ch) ((ch * 0x10) + 0x00)

    > #define ASPEED_PWM_CTRL_CH(ch) (((ch) * 0x10) + 0x00)

Got it.

    >> +#define PWM_LOAD_SEL_AS_WDT BIT(19)
    >> +#define LOAD_SEL_FALLING 0
    >> +#define LOAD_SEL_RIGING 1
    >> +#define PWM_DUTY_LOAD_AS_WDT_EN BIT(18)
    >> +#define PWM_DUTY_SYNC_DIS BIT(17)
    >> +#define PWM_CLK_ENABLE BIT(16)
    >> +#define PWM_LEVEL_OUTPUT BIT(15)
    >> +#define PWM_INVERSE BIT(14)
    >> +#define PWM_OPEN_DRAIN_EN BIT(13)
    >> +#define PWM_PIN_EN BIT(12)
    >> +#define PWM_CLK_DIV_H_SHIFT 8
    >> +#define PWM_CLK_DIV_H_MASK (0xf << PWM_CLK_DIV_H_SHIFT)
    >> +#define PWM_CLK_DIV_L_SHIFT 0
    >> +#define PWM_CLK_DIV_L_MASK (0xff << PWM_CLK_DIV_L_SHIFT)
    >> +/* PWM Duty Cycle Register */
    >> +#define ASPEED_PWM_DUTY_CYCLE_CH(ch) ((ch * 0x10) + 0x04)
    >> +#define PWM_PERIOD_SHIFT (24)
    >> +#define PWM_PERIOD_MASK (0xff << PWM_PERIOD_SHIFT)
    >> +#define PWM_POINT_AS_WDT_SHIFT (16)
    >> +#define PWM_POINT_AS_WDT_MASK (0xff << PWM_POINT_AS_WDT_SHIFT)
    >> +#define PWM_FALLING_POINT_SHIFT (8)
    >> +#define PWM_FALLING_POINT_MASK (0xffff << PWM_FALLING_POINT_SHIFT)
    >> +#define PWM_RISING_POINT_SHIFT (0)
    >> +#define PWM_RISING_POINT_MASK (0xffff << PWM_RISING_POINT_SHIFT)
    >> +/* PWM default value */
    >> +#define DEFAULT_PWM_PERIOD 0xff
    >> +#define DEFAULT_TARGET_PWM_FREQ 25000
    >> +#define DEFAULT_DUTY_PT 10
    >> +#define DEFAULT_WDT_RELOAD_DUTY_PT 16

    > You could spend a few empty lines to make this better readable. Also
    > please use a consistent driver-specific prefix for your defines and
    > consider using the macros from <linux/bitfield.h>. Also defines
    > for bitfields should contain the register name.

Got it. I will use the bitfield method to write the hardware register.

    >> +struct aspeed_pwm_data {
    >> +	struct pwm_chip chip;
    >> +	struct regmap *regmap;
    >> +	unsigned long clk_freq;
    >> +	struct reset_control *reset;
    >> +};
    >> +/**
    >> + * struct aspeed_pwm - per-PWM driver data
    >> + * @freq: cached pwm freq
    >> + */
    >> +struct aspeed_pwm {
    >> +	u32 freq;
    >> +};

    > This is actually unused, please drop it. (You save a value in it, but
    > make never use of it.)

Got it.

    >> +static void aspeed_set_pwm_channel_enable(struct regmap *regmap, u8 pwm_channel,
    >> +					  bool enable)
    >> +{
    >> +	regmap_update_bits(regmap, ASPEED_PWM_CTRL_CH(pwm_channel),
    >> +			   (PWM_CLK_ENABLE | PWM_PIN_EN),
    >> +			   enable ? (PWM_CLK_ENABLE | PWM_PIN_EN) : 0);

    > What is the semantic of PIN_EN?

It means PIN_ENABLE. I will complete the defined name with PWM_PIN_ENABLE.

    >> +}
    >> +/*
    >> + * The PWM frequency = HCLK(200Mhz) / (clock division L bit *
    >> + * clock division H bit * (period bit + 1))
    >> + */
    >> +static void aspeed_set_pwm_freq(struct aspeed_pwm_data *priv,
    >> +				struct pwm_device *pwm, u32 freq)
    >> +{
    >> +	u32 target_div, cal_freq;
    >> +	u32 tmp_div_h, tmp_div_l, diff, min_diff = INT_MAX;
    >> +	u32 div_h = BIT(5) - 1, div_l = BIT(8) - 1;
    >> +	u8 div_found;
    >> +	u32 index = pwm->hwpwm;
    >> +	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
    >> +
    >> +	cal_freq = priv->clk_freq / (DEFAULT_PWM_PERIOD + 1);
    >> +	target_div = DIV_ROUND_UP(cal_freq, freq);
    >> +	div_found = 0;
    >> +	/* calculate for target frequence */

    > s/frequence/frequency/

Got it.

    >> +	for (tmp_div_h = 0; tmp_div_h < 0x10; tmp_div_h++) {
    >> +		tmp_div_l = target_div / BIT(tmp_div_h) - 1;
    >> +
    >> +		if (tmp_div_l < 0 || tmp_div_l >> 255)
    >> +			continue;
    >> +
    >> +		diff = freq - cal_freq / (BIT(tmp_div_h) * (tmp_div_l + 1));
    >> +		if (abs(diff) < abs(min_diff)) {
    >> +			min_diff = diff;
    >> +			div_l = tmp_div_l;
    >> +			div_h = tmp_div_h;
    >> +			div_found = 1;
    >> +			if (diff == 0)
    >> +				break;
    >> +		}
    >> +	}

    > If my understanding is right (i.e. H divides by a power of two and L by
    > an integer) this can be simplified.

Yes, the formula of the frequency is: 
    HCLK / ((2 ** H divide) * L divide * PERIOD value)
I think the simplified way is using the bit shift, right?

    >> +	if (div_found == 0) {
    >> +		pr_debug("target freq: %d too slow set minimal frequency\n",
    >> +			 freq);
    >> +	}
    >> +	channel->freq = cal_freq / (BIT(div_h) * (div_l + 1));
    >> +	pr_debug("div h %x, l : %x pwm out clk %d\n", div_h, div_l,
    >> +		 channel->freq);
    >> +	pr_debug("hclk %ld, target pwm freq %d, real pwm freq %d\n",
    >> +		 priv->clk_freq, freq, channel->freq);
    >> +
    >> +	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index),
    >> +			   (PWM_CLK_DIV_H_MASK | PWM_CLK_DIV_L_MASK),
    >> +			   (div_h << PWM_CLK_DIV_H_SHIFT) |
    >> +				   (div_l << PWM_CLK_DIV_L_SHIFT));
    >> +}
    >> +
    >> +static void aspeed_set_pwm_duty(struct aspeed_pwm_data *priv,
    >> +				struct pwm_device *pwm, u32 duty_pt)
    >> +{
    >> +	u32 index = pwm->hwpwm;
    >> +
    >> +	if (duty_pt == 0) {
    >> +		aspeed_set_pwm_channel_enable(priv->regmap, index, false);
    >> +	} else {
    >> +		regmap_update_bits(priv->regmap,
    >> +				   ASPEED_PWM_DUTY_CYCLE_CH(index),
    >> +				   PWM_FALLING_POINT_MASK,
    >> +				   duty_pt << PWM_FALLING_POINT_SHIFT);
    >> +		aspeed_set_pwm_channel_enable(priv->regmap, index, true);
    >> +	}
    >> +}
    >> +
    >> +static void aspeed_set_pwm_polarity(struct aspeed_pwm_data *priv,
    >> +				    struct pwm_device *pwm, u8 polarity)
    >> +{
    >> +	u32 index = pwm->hwpwm;
    >> +
    >> +	regmap_update_bits(priv->regmap, ASPEED_PWM_CTRL_CH(index), PWM_INVERSE,
    >> +			   (polarity) ? PWM_INVERSE : 0);
    >> +}
    >> +
    >> +static int aspeed_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
    >> +{
    >> +	struct device *dev = chip->dev;
    >> +	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
    >> +	struct aspeed_pwm *channel;
    >> +	u32 index = pwm->hwpwm;
    >> +	/*
    >> +	 * Fixed the period to the max value and rising point to 0
    >> +	 * for high resolution and  simplified frequency calculation.

    > s/^H//

Sorry, I don't understand this mean.

    >> +	 */
    >> +	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
    >> +			   PWM_PERIOD_MASK,
    >> +			   DEFAULT_PWM_PERIOD << PWM_PERIOD_SHIFT);
    >> +
    >> +	regmap_update_bits(priv->regmap, ASPEED_PWM_DUTY_CYCLE_CH(index),
    >> +			   PWM_RISING_POINT_MASK, 0);

    > Only .apply is supposed to modify the PWM's configuration.

This is the initial value and the fixed(const) value for our pwm driver usage.
The value won't be modified, so I think I can initial it when pwm channel be requested.

    >> +	channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
    >> +	if (!channel)
    >> +		return -ENOMEM;

    > Don't use devm_kzalloc if freeing isn't done at device cleanup time.

This doesn't depend on device, so I can use "kzalloc" to replace it?

    >> +	pwm_set_chip_data(pwm, channel);
    >> +
    >> +	return 0;

    >> +}
    >> +
    >> +static void aspeed_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
    >> +{
    >> +	struct device *dev = chip->dev;
    >> +	struct aspeed_pwm *channel = pwm_get_chip_data(pwm);
    >> +
    >> +	devm_kfree(dev, channel);
    >> +}

When pwm free I need to use kfree to release the resources, right?

    >> +
    >> +static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
    >> +			    const struct pwm_state *state)
    >> +{
    >> +	struct device *dev = chip->dev;
    >> +	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);

    >Please consider using
    >
    >	priv = container_of(chip, struct aspeed_pwm_data, chip);
    >
    >(preferably wrapped in a macro) which is more type safe and more
    >effective to calculate.

Got it.

    >> +	struct pwm_state *cur_state = &pwm->state;
    >> +	u32 freq = DIV_ROUND_UP_ULL(1000000000, state->period);
    >> +	u32 duty_pt = DIV_ROUND_UP_ULL(
    >> +		state->duty_cycle * (DEFAULT_PWM_PERIOD + 1), state->period);

    > You're loosing precision here.


    >> +	dev_dbg(dev, "freq: %d, duty_pt: %d", freq, duty_pt);
    >> +	if (state->enabled) {
    >> +		aspeed_set_pwm_freq(priv, pwm, freq);
    >> +		aspeed_set_pwm_duty(priv, pwm, duty_pt);
    >> +		aspeed_set_pwm_polarity(priv, pwm, state->polarity);

    > How does the hardware behave between these calls? E.g. can it happen
    > that it already emits a normal period when inversed polarity is
    > requested just before aspeed_set_pwm_polarity is called? Or there is a
    > period with the previous duty cycle and the new period?

It will emits a normal period first and inversed the pwm duty instantly or wait one period 
after aspeed_set_pwm_polarity is called depends on the bit PWM_DUTY_SYNC_DIS.
Does the pwm driver have expected behavior when apply polarity changed?

    >> +	} else {
    >> +		aspeed_set_pwm_duty(priv, pwm, 0);
    >> +	}
    >> +	cur_state->period = state->period;
    >> +	cur_state->duty_cycle = state->duty_cycle;
    >> +	cur_state->polarity = state->polarity;
    >> +	cur_state->enabled = state->enabled;

    > The driver is not supposed to modify pwm->state.

Ok, I will remove it and use chip data to store it for .get_status api.

    >> +	return 0;
    >> +}

    > From your code I understood: The period of the signal is
    > 
    >	(PWM_PERIOD + 1) * (2 ** DIV_H) * (DIV_L + 1) / 200 MHz

    > . The duty cycle is
    >
    >	PWM_FALLING_POINT * (2 ** DIV_H) * (DIV_L + 1) / 200 MHz

    > . So the PWM cannot provide a 100% relative duty cycle.

    > Is this right?

No, If you want to set 100% duty cycle you can set the PWM_FALLING_POINT value 
to same as PWM_RISING_POINT (we fixed it to 0).

    >> +static const struct pwm_ops aspeed_pwm_ops = {
    >> +	.request = aspeed_pwm_request,
    >> +	.free = aspeed_pwm_free,
    >> +	.apply = aspeed_pwm_apply,

    > Please test your driver with PWM_DEBUG enabled.

Got it.

    >> +	.owner = THIS_MODULE,
    >> +};
    >> +
    >> +static int aspeed_pwm_probe(struct platform_device *pdev)
    >> +{
    >> +	struct device *dev = &pdev->dev;
    >> +	struct clk *clk;
    >> +	int ret;
    >> +	struct aspeed_pwm_data *priv;
    >> +	struct device_node *np;
    >> +
    >> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
    >> +	if (!priv)
    >> +		return -ENOMEM;
    >> +
    >> +	np = pdev->dev.parent->of_node;
    >> +	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach")) {
    >> +		dev_err(dev, "unsupported pwm device binding\n");
    >> +		return -ENODEV;
    >> +	}

    > Is this pwm-tach an mfd?

Yes, It is an mfd.

    >> +	priv->regmap = syscon_node_to_regmap(np);
    >> +	if (IS_ERR(priv->regmap)) {
    >> +		dev_err(dev, "Couldn't get regmap\n");
    >> +		return -ENODEV;
    >> +	}
    >> +
    >> +	clk = devm_clk_get(dev, NULL);
    >> +	if (IS_ERR(clk))
    >> +		return -ENODEV;
    >> +	priv->clk_freq = clk_get_rate(clk);

    > If you intend to use this clock, you have to enable it.

Got it.

    >> +	priv->reset = reset_control_get_shared(&pdev->dev, NULL);
    >> +	if (IS_ERR(priv->reset)) {
    >> +		dev_err(&pdev->dev, "can't get aspeed_pwm_tacho reset\n");
    >> +		return PTR_ERR(priv->reset);
    >> +	}
    >> +	reset_control_deassert(priv->reset);

    > missing error checking

Got it.

    >> +	priv->chip.dev = dev;
    >> +	priv->chip.ops = &aspeed_pwm_ops;
    >> +	priv->chip.base = -1;

    > This isn't necessary since f9a8ee8c8bcd118e800d88772c6457381db45224,
    > please drop the assignment to base.

Got it.

    >> +	priv->chip.npwm = ASPEED_NR_PWMS;
    >> +	priv->chip.of_xlate = of_pwm_xlate_with_flags;
    >> +	priv->chip.of_pwm_n_cells = 3;
    >> +
    >> +	ret = pwmchip_add(&priv->chip);
    >> +	if (ret < 0) {
    >> +		dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);

    > Please use %pe to make the error messages better readable.

Got it.

    >> +		return ret;
    >> +	}
    >> +	dev_set_drvdata(dev, priv);
    >> +	return ret;
    >> +}
    >> +
    >> +static const struct of_device_id of_pwm_match_table[] = {
    >> +	{
    >> +		.compatible = "aspeed,ast2600-pwm",
    >> +	},
    >> +	{},
    >> +};
    >> +MODULE_DEVICE_TABLE(of, of_pwm_match_table);
    >> +
    >> +static struct platform_driver aspeed_pwm_driver = {
    >> +	.probe		= aspeed_pwm_probe,

    > Please implement a .remove callback.

Got it.

    >> +	.driver		= {
    >> +		.name	= "aspeed_pwm",
    >> +		.of_match_table = of_pwm_match_table,
    >> +	},
    >> +};

    Best regards
    Uwe

    -- 
    Pengutronix e.K.                           | Uwe Kleine-K?nig            |
    Industrial Linux Solutions                 | https://www.pengutronix.de/ |


From boon.leong.ong at intel.com  Tue Apr 13 10:36:19 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:19 +0800
Subject: [PATCH net-next v2 0/7] stmmac: add XDP ZC support
Message-ID: <20210413093626.3447-1-boon.leong.ong@intel.com>

Hi,

This is the v2 patch series to add XDP ZC support to stmmac driver.

Summary of v2 patch change:-

6/7: fix synchronize_rcu() is called stmmac_disable_all_queues() that is
     used by ndo_setup_tc().

 ########################################################################

Continuous burst traffics are generated by pktgen script and in the midst
of each packet processing operation by xdpsock the following tc-loop.sh
script is looped continuously:-

 #!/bin/bash
 tc qdisc del dev eth0 parent root
 tc qdisc add dev eth0 ingress
 tc qdisc add dev eth0 root 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 0
 tc filter add dev eth0 parent ffff: protocol 802.1Q flower vlan_prio 0 hw_tc 0
 tc filter add dev eth0 parent ffff: protocol 802.1Q flower vlan_prio 1 hw_tc 1
 tc filter add dev eth0 parent ffff: protocol 802.1Q flower vlan_prio 2 hw_tc 2
 tc filter add dev eth0 parent ffff: protocol 802.1Q flower vlan_prio 3 hw_tc 3
 tc qdisc list dev eth0
 tc filter show dev eth0 ingress

 On different ssh terminal
 $ while true; do ./tc-loop.sh; sleep 1; done

The v2 patch series have been tested using the xdpsock app:
 $ ./xdpsock -i eth0 -l -z

>From xdpsock poller pps report and dmesg, we don't find any warning
related to rcu and the only difference when the script is executed is
the pps rate drops momentarily.

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 436347         191361334
tx                 436411         191361334

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 254117         191615476
tx                 254053         191615412

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 466395         192081924
tx                 466395         192081860

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 287410         192369365
tx                 287474         192369365

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 395853         192765329
tx                 395789         192765265

 sock0 at eth0:0 l2fwd xdp-drv
                   pps            pkts           1.00
rx                 466132         193231514
tx                 466132         193231450

 ########################################################################

Based on the above result, the fix looks promising. Appreciate that if
community can help to review the patch series and provide me feedback
for improvement.

Thanks,
Boon Leong

 ------------------------------------------------------------------------
 History of patch series as follow:-

 v1: https://patchwork.kernel.org/project/netdevbpf/list/?series=465747&state=*

 ------------------------------------------------------------------------

Ong Boon Leong (7):
  net: stmmac: rearrange RX buffer allocation and free functions
  net: stmmac: introduce dma_recycle_rx_skbufs for
    stmmac_reinit_rx_buffers
  net: stmmac: refactor stmmac_init_rx_buffers for
    stmmac_reinit_rx_buffers
  net: stmmac: rearrange RX and TX desc init into per-queue basis
  net: stmmac: Refactor __stmmac_xdp_run_prog for XDP ZC
  net: stmmac: Enable RX via AF_XDP zero-copy
  net: stmmac: Add TX via XDP zero-copy socket

 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   24 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 1718 +++++++++++++----
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |   95 +
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |    3 +
 4 files changed, 1411 insertions(+), 429 deletions(-)

-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:20 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:20 +0800
Subject: [PATCH net-next v2 1/7] net: stmmac: rearrange RX buffer allocation
 and free functions
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-2-boon.leong.ong@intel.com>

This patch restructures the per RX queue buffer allocation from page_pool
to stmmac_alloc_rx_buffers().

We also rearrange dma_free_rx_skbufs() so that it can be used in
init_dma_rx_desc_rings() during freeing of RX buffer in the event of
page_pool allocation failure to replace the more efficient method earlier.
The replacement is needed to make the RX buffer alloc and free method
scalable to XDP ZC xsk_pool alloc and free later.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 84 +++++++++++--------
 1 file changed, 47 insertions(+), 37 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 77285646c5fc..f6d3d26ce45a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1475,6 +1475,43 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 	tx_q->tx_skbuff_dma[i].map_as_page = false;
 }
 
+/**
+ * dma_free_rx_skbufs - free RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+{
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++)
+		stmmac_free_rx_buffer(priv, queue, i);
+}
+
+static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
+				   gfp_t flags)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct dma_desc *p;
+		int ret;
+
+		if (priv->extend_desc)
+			p = &((rx_q->dma_erx + i)->basic);
+		else
+			p = rx_q->dma_rx + i;
+
+		ret = stmmac_init_rx_buffers(priv, p, i, flags,
+					     queue);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1547,15 +1584,14 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	return;
 
 err_reinit_rx_buffers:
-	do {
-		while (--i >= 0)
-			stmmac_free_rx_buffer(priv, queue, i);
+	while (queue >= 0) {
+		dma_free_rx_skbufs(priv, queue);
 
 		if (queue == 0)
 			break;
 
-		i = priv->dma_rx_size;
-	} while (queue-- > 0);
+		queue--;
+	}
 }
 
 /**
@@ -1572,7 +1608,6 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	int ret = -ENOMEM;
 	int queue;
-	int i;
 
 	/* RX INITIALIZATION */
 	netif_dbg(priv, probe, priv->dev,
@@ -1580,7 +1615,7 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-		int ret;
+
 
 		netif_dbg(priv, probe, priv->dev,
 			  "(%s) dma_rx_phy=0x%08x\n", __func__,
@@ -1596,22 +1631,12 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
 			    rx_q->queue_index);
 
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct dma_desc *p;
-
-			if (priv->extend_desc)
-				p = &((rx_q->dma_erx + i)->basic);
-			else
-				p = rx_q->dma_rx + i;
-
-			ret = stmmac_init_rx_buffers(priv, p, i, flags,
-						     queue);
-			if (ret)
-				goto err_init_rx_buffers;
-		}
+		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+		if (ret < 0)
+			goto err_init_rx_buffers;
 
 		rx_q->cur_rx = 0;
-		rx_q->dirty_rx = (unsigned int)(i - priv->dma_rx_size);
+		rx_q->dirty_rx = 0;
 
 		/* Setup the chained descriptor addresses */
 		if (priv->mode == STMMAC_CHAIN_MODE) {
@@ -1630,13 +1655,11 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 err_init_rx_buffers:
 	while (queue >= 0) {
-		while (--i >= 0)
-			stmmac_free_rx_buffer(priv, queue, i);
+		dma_free_rx_skbufs(priv, queue);
 
 		if (queue == 0)
 			break;
 
-		i = priv->dma_rx_size;
 		queue--;
 	}
 
@@ -1731,19 +1754,6 @@ static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
 	return ret;
 }
 
-/**
- * dma_free_rx_skbufs - free RX dma buffers
- * @priv: private structure
- * @queue: RX queue index
- */
-static void dma_free_rx_skbufs(struct stmmac_priv *priv, u32 queue)
-{
-	int i;
-
-	for (i = 0; i < priv->dma_rx_size; i++)
-		stmmac_free_rx_buffer(priv, queue, i);
-}
-
 /**
  * dma_free_tx_skbufs - free TX dma buffers
  * @priv: private structure
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:21 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:21 +0800
Subject: [PATCH net-next v2 2/7] net: stmmac: introduce dma_recycle_rx_skbufs
 for stmmac_reinit_rx_buffers
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-3-boon.leong.ong@intel.com>

Rearrange RX buffer page_pool recycling logics into dma_recycle_rx_skbufs,
so that we prepare stmmac_reinit_rx_buffers() for XSK pool expansion.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 44 ++++++++++++-------
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f6d3d26ce45a..a6c3414fd231 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1512,6 +1512,31 @@ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
 	return 0;
 }
 
+/**
+ * dma_recycle_rx_skbufs - recycle RX dma buffers
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+		if (buf->page) {
+			page_pool_recycle_direct(rx_q->page_pool, buf->page);
+			buf->page = NULL;
+		}
+
+		if (priv->sph && buf->sec_page) {
+			page_pool_recycle_direct(rx_q->page_pool, buf->sec_page);
+			buf->sec_page = NULL;
+		}
+	}
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1524,23 +1549,8 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	u32 queue;
 	int i;
 
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
-
-			if (buf->page) {
-				page_pool_recycle_direct(rx_q->page_pool, buf->page);
-				buf->page = NULL;
-			}
-
-			if (priv->sph && buf->sec_page) {
-				page_pool_recycle_direct(rx_q->page_pool, buf->sec_page);
-				buf->sec_page = NULL;
-			}
-		}
-	}
+	for (queue = 0; queue < rx_count; queue++)
+		dma_recycle_rx_skbufs(priv, queue);
 
 	for (queue = 0; queue < rx_count; queue++) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:22 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:22 +0800
Subject: [PATCH net-next v2 3/7] net: stmmac: refactor stmmac_init_rx_buffers
 for stmmac_reinit_rx_buffers
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-4-boon.leong.ong@intel.com>

The per-queue RX buffer allocation in stmmac_reinit_rx_buffers() can be
made to use stmmac_alloc_rx_buffers() by merging the page_pool alloc
checks for "buf->page" and "buf->sec_page" in stmmac_init_rx_buffers().

This is in preparation for XSK pool allocation later.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 378 +++++++++---------
 1 file changed, 189 insertions(+), 189 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a6c3414fd231..7e889ef0c7b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1388,12 +1388,14 @@ static int stmmac_init_rx_buffers(struct stmmac_priv *priv, struct dma_desc *p,
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 	struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
 
-	buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
-	if (!buf->page)
-		return -ENOMEM;
-	buf->page_offset = stmmac_rx_offset(priv);
+	if (!buf->page) {
+		buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
+		if (!buf->page)
+			return -ENOMEM;
+		buf->page_offset = stmmac_rx_offset(priv);
+	}
 
-	if (priv->sph) {
+	if (priv->sph && !buf->sec_page) {
 		buf->sec_page = page_pool_dev_alloc_pages(rx_q->page_pool);
 		if (!buf->sec_page)
 			return -ENOMEM;
@@ -1547,48 +1549,16 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 {
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	u32 queue;
-	int i;
 
 	for (queue = 0; queue < rx_count; queue++)
 		dma_recycle_rx_skbufs(priv, queue);
 
 	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-
-		for (i = 0; i < priv->dma_rx_size; i++) {
-			struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
-			struct dma_desc *p;
-
-			if (priv->extend_desc)
-				p = &((rx_q->dma_erx + i)->basic);
-			else
-				p = rx_q->dma_rx + i;
-
-			if (!buf->page) {
-				buf->page = page_pool_dev_alloc_pages(rx_q->page_pool);
-				if (!buf->page)
-					goto err_reinit_rx_buffers;
-
-				buf->addr = page_pool_get_dma_addr(buf->page) +
-					    buf->page_offset;
-			}
-
-			if (priv->sph && !buf->sec_page) {
-				buf->sec_page = page_pool_dev_alloc_pages(rx_q->page_pool);
-				if (!buf->sec_page)
-					goto err_reinit_rx_buffers;
-
-				buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
-			}
+		int ret;
 
-			stmmac_set_desc_addr(priv, p, buf->addr);
-			if (priv->sph)
-				stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, true);
-			else
-				stmmac_set_desc_sec_addr(priv, p, buf->sec_addr, false);
-			if (priv->dma_buf_sz == BUF_SIZE_16KiB)
-				stmmac_init_desc3(priv, p);
-		}
+		ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
+		if (ret < 0)
+			goto err_reinit_rx_buffers;
 	}
 
 	return;
@@ -1791,153 +1761,173 @@ static void stmmac_free_tx_skbufs(struct stmmac_priv *priv)
 }
 
 /**
- * free_dma_rx_desc_resources - free RX dma desc resources
+ * __free_dma_rx_desc_resources - free RX dma desc resources (per queue)
  * @priv: private structure
+ * @queue: RX queue index
  */
-static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
+static void __free_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	u32 queue;
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
-	/* Free RX queue resources */
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	/* Release the DMA RX socket buffers */
+	dma_free_rx_skbufs(priv, queue);
 
-		/* Release the DMA RX socket buffers */
-		dma_free_rx_skbufs(priv, queue);
+	/* Free DMA regions of consistent memory previously allocated */
+	if (!priv->extend_desc)
+		dma_free_coherent(priv->device, priv->dma_rx_size *
+				  sizeof(struct dma_desc),
+				  rx_q->dma_rx, rx_q->dma_rx_phy);
+	else
+		dma_free_coherent(priv->device, priv->dma_rx_size *
+				  sizeof(struct dma_extended_desc),
+				  rx_q->dma_erx, rx_q->dma_rx_phy);
 
-		/* Free DMA regions of consistent memory previously allocated */
-		if (!priv->extend_desc)
-			dma_free_coherent(priv->device, priv->dma_rx_size *
-					  sizeof(struct dma_desc),
-					  rx_q->dma_rx, rx_q->dma_rx_phy);
-		else
-			dma_free_coherent(priv->device, priv->dma_rx_size *
-					  sizeof(struct dma_extended_desc),
-					  rx_q->dma_erx, rx_q->dma_rx_phy);
+	if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
+		xdp_rxq_info_unreg(&rx_q->xdp_rxq);
 
-		if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
-			xdp_rxq_info_unreg(&rx_q->xdp_rxq);
+	kfree(rx_q->buf_pool);
+	if (rx_q->page_pool)
+		page_pool_destroy(rx_q->page_pool);
+}
 
-		kfree(rx_q->buf_pool);
-		if (rx_q->page_pool)
-			page_pool_destroy(rx_q->page_pool);
-	}
+static void free_dma_rx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+
+	/* Free RX queue resources */
+	for (queue = 0; queue < rx_count; queue++)
+		__free_dma_rx_desc_resources(priv, queue);
 }
 
 /**
- * free_dma_tx_desc_resources - free TX dma desc resources
+ * __free_dma_tx_desc_resources - free TX dma desc resources (per queue)
  * @priv: private structure
+ * @queue: TX queue index
  */
-static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
+static void __free_dma_tx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 tx_count = priv->plat->tx_queues_to_use;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	size_t size;
+	void *addr;
 
-	/* Free TX queue resources */
-	for (queue = 0; queue < tx_count; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-		size_t size;
-		void *addr;
+	/* Release the DMA TX socket buffers */
+	dma_free_tx_skbufs(priv, queue);
+
+	if (priv->extend_desc) {
+		size = sizeof(struct dma_extended_desc);
+		addr = tx_q->dma_etx;
+	} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
+		size = sizeof(struct dma_edesc);
+		addr = tx_q->dma_entx;
+	} else {
+		size = sizeof(struct dma_desc);
+		addr = tx_q->dma_tx;
+	}
 
-		/* Release the DMA TX socket buffers */
-		dma_free_tx_skbufs(priv, queue);
+	size *= priv->dma_tx_size;
 
-		if (priv->extend_desc) {
-			size = sizeof(struct dma_extended_desc);
-			addr = tx_q->dma_etx;
-		} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
-			size = sizeof(struct dma_edesc);
-			addr = tx_q->dma_entx;
-		} else {
-			size = sizeof(struct dma_desc);
-			addr = tx_q->dma_tx;
-		}
+	dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
 
-		size *= priv->dma_tx_size;
+	kfree(tx_q->tx_skbuff_dma);
+	kfree(tx_q->tx_skbuff);
+}
 
-		dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
+static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 tx_count = priv->plat->tx_queues_to_use;
+	u32 queue;
 
-		kfree(tx_q->tx_skbuff_dma);
-		kfree(tx_q->tx_skbuff);
-	}
+	/* Free TX queue resources */
+	for (queue = 0; queue < tx_count; queue++)
+		__free_dma_tx_desc_resources(priv, queue);
 }
 
 /**
- * alloc_dma_rx_desc_resources - alloc RX resources.
+ * __alloc_dma_rx_desc_resources - alloc RX resources (per queue).
  * @priv: private structure
+ * @queue: RX queue index
  * Description: according to which descriptor can be used (extend or basic)
  * this function allocates the resources for TX and RX paths. In case of
  * reception, for example, it pre-allocated the RX socket buffer in order to
  * allow zero-copy mechanism.
  */
-static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
+static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
 	bool xdp_prog = stmmac_xdp_is_enabled(priv);
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	int ret = -ENOMEM;
-	u32 queue;
+	struct page_pool_params pp_params = { 0 };
+	unsigned int num_pages;
+	int ret;
 
-	/* RX queues buffers and DMA */
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
-		struct stmmac_channel *ch = &priv->channel[queue];
-		struct page_pool_params pp_params = { 0 };
-		unsigned int num_pages;
-		int ret;
+	rx_q->queue_index = queue;
+	rx_q->priv_data = priv;
+
+	pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV;
+	pp_params.pool_size = priv->dma_rx_size;
+	num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
+	pp_params.order = ilog2(num_pages);
+	pp_params.nid = dev_to_node(priv->device);
+	pp_params.dev = priv->device;
+	pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
+	pp_params.offset = stmmac_rx_offset(priv);
+	pp_params.max_len = STMMAC_MAX_RX_BUF_SIZE(num_pages);
+
+	rx_q->page_pool = page_pool_create(&pp_params);
+	if (IS_ERR(rx_q->page_pool)) {
+		ret = PTR_ERR(rx_q->page_pool);
+		rx_q->page_pool = NULL;
+		return ret;
+	}
 
-		rx_q->queue_index = queue;
-		rx_q->priv_data = priv;
-
-		pp_params.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV;
-		pp_params.pool_size = priv->dma_rx_size;
-		num_pages = DIV_ROUND_UP(priv->dma_buf_sz, PAGE_SIZE);
-		pp_params.order = ilog2(num_pages);
-		pp_params.nid = dev_to_node(priv->device);
-		pp_params.dev = priv->device;
-		pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
-		pp_params.offset = stmmac_rx_offset(priv);
-		pp_params.max_len = STMMAC_MAX_RX_BUF_SIZE(num_pages);
-
-		rx_q->page_pool = page_pool_create(&pp_params);
-		if (IS_ERR(rx_q->page_pool)) {
-			ret = PTR_ERR(rx_q->page_pool);
-			rx_q->page_pool = NULL;
-			goto err_dma;
-		}
+	rx_q->buf_pool = kcalloc(priv->dma_rx_size,
+				 sizeof(*rx_q->buf_pool),
+				 GFP_KERNEL);
+	if (!rx_q->buf_pool)
+		return -ENOMEM;
 
-		rx_q->buf_pool = kcalloc(priv->dma_rx_size,
-					 sizeof(*rx_q->buf_pool),
-					 GFP_KERNEL);
-		if (!rx_q->buf_pool)
-			goto err_dma;
+	if (priv->extend_desc) {
+		rx_q->dma_erx = dma_alloc_coherent(priv->device,
+						   priv->dma_rx_size *
+						   sizeof(struct dma_extended_desc),
+						   &rx_q->dma_rx_phy,
+						   GFP_KERNEL);
+		if (!rx_q->dma_erx)
+			return -ENOMEM;
 
-		if (priv->extend_desc) {
-			rx_q->dma_erx = dma_alloc_coherent(priv->device,
-							   priv->dma_rx_size *
-							   sizeof(struct dma_extended_desc),
-							   &rx_q->dma_rx_phy,
-							   GFP_KERNEL);
-			if (!rx_q->dma_erx)
-				goto err_dma;
+	} else {
+		rx_q->dma_rx = dma_alloc_coherent(priv->device,
+						  priv->dma_rx_size *
+						  sizeof(struct dma_desc),
+						  &rx_q->dma_rx_phy,
+						  GFP_KERNEL);
+		if (!rx_q->dma_rx)
+			return -ENOMEM;
+	}
 
-		} else {
-			rx_q->dma_rx = dma_alloc_coherent(priv->device,
-							  priv->dma_rx_size *
-							  sizeof(struct dma_desc),
-							  &rx_q->dma_rx_phy,
-							  GFP_KERNEL);
-			if (!rx_q->dma_rx)
-				goto err_dma;
-		}
+	ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
+			       rx_q->queue_index,
+			       ch->rx_napi.napi_id);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to register xdp rxq info\n");
+		return -EINVAL;
+	}
 
-		ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
-				       rx_q->queue_index,
-				       ch->rx_napi.napi_id);
-		if (ret) {
-			netdev_err(priv->dev, "Failed to register xdp rxq info\n");
+	return 0;
+}
+
+static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+	int ret;
+
+	/* RX queues buffers and DMA */
+	for (queue = 0; queue < rx_count; queue++) {
+		ret = __alloc_dma_rx_desc_resources(priv, queue);
+		if (ret)
 			goto err_dma;
-		}
 	}
 
 	return 0;
@@ -1949,60 +1939,70 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
 }
 
 /**
- * alloc_dma_tx_desc_resources - alloc TX resources.
+ * __alloc_dma_tx_desc_resources - alloc TX resources (per queue).
  * @priv: private structure
+ * @queue: TX queue index
  * Description: according to which descriptor can be used (extend or basic)
  * this function allocates the resources for TX and RX paths. In case of
  * reception, for example, it pre-allocated the RX socket buffer in order to
  * allow zero-copy mechanism.
  */
-static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
+static int __alloc_dma_tx_desc_resources(struct stmmac_priv *priv, u32 queue)
 {
-	u32 tx_count = priv->plat->tx_queues_to_use;
-	int ret = -ENOMEM;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	size_t size;
+	void *addr;
 
-	/* TX queues buffers and DMA */
-	for (queue = 0; queue < tx_count; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-		size_t size;
-		void *addr;
+	tx_q->queue_index = queue;
+	tx_q->priv_data = priv;
 
-		tx_q->queue_index = queue;
-		tx_q->priv_data = priv;
+	tx_q->tx_skbuff_dma = kcalloc(priv->dma_tx_size,
+				      sizeof(*tx_q->tx_skbuff_dma),
+				      GFP_KERNEL);
+	if (!tx_q->tx_skbuff_dma)
+		return -ENOMEM;
 
-		tx_q->tx_skbuff_dma = kcalloc(priv->dma_tx_size,
-					      sizeof(*tx_q->tx_skbuff_dma),
-					      GFP_KERNEL);
-		if (!tx_q->tx_skbuff_dma)
-			goto err_dma;
+	tx_q->tx_skbuff = kcalloc(priv->dma_tx_size,
+				  sizeof(struct sk_buff *),
+				  GFP_KERNEL);
+	if (!tx_q->tx_skbuff)
+		return -ENOMEM;
 
-		tx_q->tx_skbuff = kcalloc(priv->dma_tx_size,
-					  sizeof(struct sk_buff *),
-					  GFP_KERNEL);
-		if (!tx_q->tx_skbuff)
-			goto err_dma;
+	if (priv->extend_desc)
+		size = sizeof(struct dma_extended_desc);
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		size = sizeof(struct dma_edesc);
+	else
+		size = sizeof(struct dma_desc);
 
-		if (priv->extend_desc)
-			size = sizeof(struct dma_extended_desc);
-		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-			size = sizeof(struct dma_edesc);
-		else
-			size = sizeof(struct dma_desc);
+	size *= priv->dma_tx_size;
 
-		size *= priv->dma_tx_size;
+	addr = dma_alloc_coherent(priv->device, size,
+				  &tx_q->dma_tx_phy, GFP_KERNEL);
+	if (!addr)
+		return -ENOMEM;
 
-		addr = dma_alloc_coherent(priv->device, size,
-					  &tx_q->dma_tx_phy, GFP_KERNEL);
-		if (!addr)
-			goto err_dma;
+	if (priv->extend_desc)
+		tx_q->dma_etx = addr;
+	else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		tx_q->dma_entx = addr;
+	else
+		tx_q->dma_tx = addr;
 
-		if (priv->extend_desc)
-			tx_q->dma_etx = addr;
-		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-			tx_q->dma_entx = addr;
-		else
-			tx_q->dma_tx = addr;
+	return 0;
+}
+
+static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
+{
+	u32 tx_count = priv->plat->tx_queues_to_use;
+	u32 queue;
+	int ret;
+
+	/* TX queues buffers and DMA */
+	for (queue = 0; queue < tx_count; queue++) {
+		ret = __alloc_dma_tx_desc_resources(priv, queue);
+		if (ret)
+			goto err_dma;
 	}
 
 	return 0;
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:23 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:23 +0800
Subject: [PATCH net-next v2 4/7] net: stmmac: rearrange RX and TX desc init
 into per-queue basis
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-5-boon.leong.ong@intel.com>

Below functions are made to be per-queue in preparation of XDP ZC:

 __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t flags)
 __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)

The original functions below are stay maintained for all queue usage:

 init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 init_dma_tx_desc_rings(struct net_device *dev)

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 180 ++++++++++--------
 1 file changed, 100 insertions(+), 80 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 7e889ef0c7b5..0804674e628e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1575,60 +1575,70 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 }
 
 /**
- * init_dma_rx_desc_rings - init the RX descriptor rings
- * @dev: net device structure
+ * __init_dma_rx_desc_rings - init the RX descriptor ring (per queue)
+ * @priv: driver private structure
+ * @queue: RX queue index
  * @flags: gfp flag.
  * Description: this function initializes the DMA RX descriptors
  * and allocates the socket buffers. It supports the chained and ring
  * modes.
  */
-static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
+static int __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t flags)
 {
-	struct stmmac_priv *priv = netdev_priv(dev);
-	u32 rx_count = priv->plat->rx_queues_to_use;
-	int ret = -ENOMEM;
-	int queue;
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int ret;
 
-	/* RX INITIALIZATION */
 	netif_dbg(priv, probe, priv->dev,
-		  "SKB addresses:\nskb\t\tskb data\tdma data\n");
+		  "(%s) dma_rx_phy=0x%08x\n", __func__,
+		  (u32)rx_q->dma_rx_phy);
 
-	for (queue = 0; queue < rx_count; queue++) {
-		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	stmmac_clear_rx_descriptors(priv, queue);
 
+	WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+					   MEM_TYPE_PAGE_POOL,
+					   rx_q->page_pool));
 
-		netif_dbg(priv, probe, priv->dev,
-			  "(%s) dma_rx_phy=0x%08x\n", __func__,
-			  (u32)rx_q->dma_rx_phy);
+	netdev_info(priv->dev,
+		    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
+		    rx_q->queue_index);
 
-		stmmac_clear_rx_descriptors(priv, queue);
+	ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+	if (ret < 0)
+		return -ENOMEM;
 
-		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
-						   MEM_TYPE_PAGE_POOL,
-						   rx_q->page_pool));
+	rx_q->cur_rx = 0;
+	rx_q->dirty_rx = 0;
 
-		netdev_info(priv->dev,
-			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
-			    rx_q->queue_index);
+	/* Setup the chained descriptor addresses */
+	if (priv->mode == STMMAC_CHAIN_MODE) {
+		if (priv->extend_desc)
+			stmmac_mode_init(priv, rx_q->dma_erx,
+					 rx_q->dma_rx_phy,
+					 priv->dma_rx_size, 1);
+		else
+			stmmac_mode_init(priv, rx_q->dma_rx,
+					 rx_q->dma_rx_phy,
+					 priv->dma_rx_size, 0);
+	}
 
-		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
-		if (ret < 0)
-			goto err_init_rx_buffers;
+	return 0;
+}
 
-		rx_q->cur_rx = 0;
-		rx_q->dirty_rx = 0;
+static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	u32 rx_count = priv->plat->rx_queues_to_use;
+	u32 queue;
+	int ret;
 
-		/* Setup the chained descriptor addresses */
-		if (priv->mode == STMMAC_CHAIN_MODE) {
-			if (priv->extend_desc)
-				stmmac_mode_init(priv, rx_q->dma_erx,
-						 rx_q->dma_rx_phy,
-						 priv->dma_rx_size, 1);
-			else
-				stmmac_mode_init(priv, rx_q->dma_rx,
-						 rx_q->dma_rx_phy,
-						 priv->dma_rx_size, 0);
-		}
+	/* RX INITIALIZATION */
+	netif_dbg(priv, probe, priv->dev,
+		  "SKB addresses:\nskb\t\tskb data\tdma data\n");
+
+	for (queue = 0; queue < rx_count; queue++) {
+		ret = __init_dma_rx_desc_rings(priv, queue, flags);
+		if (ret)
+			goto err_init_rx_buffers;
 	}
 
 	return 0;
@@ -1647,63 +1657,73 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 }
 
 /**
- * init_dma_tx_desc_rings - init the TX descriptor rings
- * @dev: net device structure.
+ * __init_dma_tx_desc_rings - init the TX descriptor ring (per queue)
+ * @priv: driver private structure
+ * @queue : TX queue index
  * Description: this function initializes the DMA TX descriptors
  * and allocates the socket buffers. It supports the chained and ring
  * modes.
  */
-static int init_dma_tx_desc_rings(struct net_device *dev)
+static int __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)
 {
-	struct stmmac_priv *priv = netdev_priv(dev);
-	u32 tx_queue_cnt = priv->plat->tx_queues_to_use;
-	u32 queue;
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	int i;
 
-	for (queue = 0; queue < tx_queue_cnt; queue++) {
-		struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
-
-		netif_dbg(priv, probe, priv->dev,
-			  "(%s) dma_tx_phy=0x%08x\n", __func__,
-			 (u32)tx_q->dma_tx_phy);
-
-		/* Setup the chained descriptor addresses */
-		if (priv->mode == STMMAC_CHAIN_MODE) {
-			if (priv->extend_desc)
-				stmmac_mode_init(priv, tx_q->dma_etx,
-						 tx_q->dma_tx_phy,
-						 priv->dma_tx_size, 1);
-			else if (!(tx_q->tbs & STMMAC_TBS_AVAIL))
-				stmmac_mode_init(priv, tx_q->dma_tx,
-						 tx_q->dma_tx_phy,
-						 priv->dma_tx_size, 0);
-		}
+	netif_dbg(priv, probe, priv->dev,
+		  "(%s) dma_tx_phy=0x%08x\n", __func__,
+		  (u32)tx_q->dma_tx_phy);
 
-		for (i = 0; i < priv->dma_tx_size; i++) {
-			struct dma_desc *p;
-			if (priv->extend_desc)
-				p = &((tx_q->dma_etx + i)->basic);
-			else if (tx_q->tbs & STMMAC_TBS_AVAIL)
-				p = &((tx_q->dma_entx + i)->basic);
-			else
-				p = tx_q->dma_tx + i;
+	/* Setup the chained descriptor addresses */
+	if (priv->mode == STMMAC_CHAIN_MODE) {
+		if (priv->extend_desc)
+			stmmac_mode_init(priv, tx_q->dma_etx,
+					 tx_q->dma_tx_phy,
+					 priv->dma_tx_size, 1);
+		else if (!(tx_q->tbs & STMMAC_TBS_AVAIL))
+			stmmac_mode_init(priv, tx_q->dma_tx,
+					 tx_q->dma_tx_phy,
+					 priv->dma_tx_size, 0);
+	}
 
-			stmmac_clear_desc(priv, p);
+	for (i = 0; i < priv->dma_tx_size; i++) {
+		struct dma_desc *p;
 
-			tx_q->tx_skbuff_dma[i].buf = 0;
-			tx_q->tx_skbuff_dma[i].map_as_page = false;
-			tx_q->tx_skbuff_dma[i].len = 0;
-			tx_q->tx_skbuff_dma[i].last_segment = false;
-			tx_q->tx_skbuff[i] = NULL;
-		}
+		if (priv->extend_desc)
+			p = &((tx_q->dma_etx + i)->basic);
+		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+			p = &((tx_q->dma_entx + i)->basic);
+		else
+			p = tx_q->dma_tx + i;
 
-		tx_q->dirty_tx = 0;
-		tx_q->cur_tx = 0;
-		tx_q->mss = 0;
+		stmmac_clear_desc(priv, p);
 
-		netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+		tx_q->tx_skbuff_dma[i].buf = 0;
+		tx_q->tx_skbuff_dma[i].map_as_page = false;
+		tx_q->tx_skbuff_dma[i].len = 0;
+		tx_q->tx_skbuff_dma[i].last_segment = false;
+		tx_q->tx_skbuff[i] = NULL;
 	}
 
+	tx_q->dirty_tx = 0;
+	tx_q->cur_tx = 0;
+	tx_q->mss = 0;
+
+	netdev_tx_reset_queue(netdev_get_tx_queue(priv->dev, queue));
+
+	return 0;
+}
+
+static int init_dma_tx_desc_rings(struct net_device *dev)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	u32 tx_queue_cnt;
+	u32 queue;
+
+	tx_queue_cnt = priv->plat->tx_queues_to_use;
+
+	for (queue = 0; queue < tx_queue_cnt; queue++)
+		__init_dma_tx_desc_rings(priv, queue);
+
 	return 0;
 }
 
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:24 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:24 +0800
Subject: [PATCH net-next v2 5/7] net: stmmac: Refactor __stmmac_xdp_run_prog
 for XDP ZC
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-6-boon.leong.ong@intel.com>

Prepare stmmac_xdp_run_prog() for AF_XDP zero-copy support which will be
added by upcoming patches by splitting out the XDP verdict processing
into __stmmac_xdp_run_prog() and it callable for XDP ZC path which does
not need to verify bpf_prog is not NULL.

The stmmac_xdp_run_prog() is used for regular XDP Rx path which requires
bpf_prog to be verified.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 35 ++++++++++++-------
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0804674e628e..329a3abbac76 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -4408,20 +4408,13 @@ static int stmmac_xdp_xmit_back(struct stmmac_priv *priv,
 	return res;
 }
 
-static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
-					   struct xdp_buff *xdp)
+/* This function assumes rcu_read_lock() is held by the caller. */
+static int __stmmac_xdp_run_prog(struct stmmac_priv *priv,
+				 struct bpf_prog *prog,
+				 struct xdp_buff *xdp)
 {
-	struct bpf_prog *prog;
-	int res;
 	u32 act;
-
-	rcu_read_lock();
-
-	prog = READ_ONCE(priv->xdp_prog);
-	if (!prog) {
-		res = STMMAC_XDP_PASS;
-		goto unlock;
-	}
+	int res;
 
 	act = bpf_prog_run_xdp(prog, xdp);
 	switch (act) {
@@ -4448,6 +4441,24 @@ static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
 		break;
 	}
 
+	return res;
+}
+
+static struct sk_buff *stmmac_xdp_run_prog(struct stmmac_priv *priv,
+					   struct xdp_buff *xdp)
+{
+	struct bpf_prog *prog;
+	int res;
+
+	rcu_read_lock();
+
+	prog = READ_ONCE(priv->xdp_prog);
+	if (!prog) {
+		res = STMMAC_XDP_PASS;
+		goto unlock;
+	}
+
+	res = __stmmac_xdp_run_prog(priv, prog, xdp);
 unlock:
 	rcu_read_unlock();
 	return ERR_PTR(-res);
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:25 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:25 +0800
Subject: [PATCH net-next v2 6/7] net: stmmac: Enable RX via AF_XDP zero-copy
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-7-boon.leong.ong@intel.com>

This patch adds the support for receiving packet via AF_XDP zero-copy
mechanism.

XDP ZC uses 1:1 mapping of XDP buffer to receive packet, therefore the
use of split header is not used currently. The 'xdp_buff' is declared as
union together with a struct that contains 'page', 'addr' and
'page_offset' that are associated with primary buffer.

RX buffers are now allocated either via page_pool or xsk pool. For RX
buffers from xsk_pool they are allocated and deallocated using below
functions:

 * stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
 * dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)

With above functions now available, we then extend the following driver
functions to support XDP ZC:
 * stmmac_reinit_rx_buffers()
 * __init_dma_rx_desc_rings()
 * init_dma_rx_desc_rings()
 * __free_dma_rx_desc_resources()

Note: stmmac_alloc_rx_buffers_zc() may return -ENOMEM due to RX XDP
buffer pool is not allocated (e.g. samples/bpf/xdpsock TX-only). But,
it is still ok to let TX XDP ZC to continue, therefore, the -ENOMEM
is silently ignored to let the driver succcessfully transition to XDP
ZC mode for the said RX and TX queue.

As XDP ZC buffer size is different, the DMA buffer size is required
to be reprogrammed accordingly for RX DMA/Queue that is populated with
XDP buffer from XSK pool.

Next, to add or remove per-queue XSK pool, stmmac_xdp_setup_pool()
will call stmmac_xdp_enable_pool() or stmmac_xdp_disable_pool()
that in-turn coordinates the tearing down and setting up RX ring via
RX buffers and descriptors removal and reallocation through
stmmac_disable_rx_queue() and stmmac_enable_rx_queue(). In addition,
stmmac_xsk_wakeup() is added to initiate XDP RX buffer replenishing
by signalling user application to add available XDP frames back to
FILL queue.

For RX processing using XDP zero-copy buffer, stmmac_rx_zc() is
introduced which is implemented with the assumption that RX split
header is disabled. For XDP verdict is XDP_PASS, the XDP buffer is
copied into a sk_buff allocated through stmmac_construct_skb_zc()
and sent to Linux network GRO inside stmmac_dispatch_skb_zc(). Free RX
buffers are then replenished using stmmac_rx_refill_zc()

v2: introduce __stmmac_disable_all_queues() to contain the original code
    that does napi_disable() and then make stmmac_setup_tc_block_cb()
    to use it. Move synchronize_rcu() into stmmac_disable_all_queues()
    that eventually calls __stmmac_disable_all_queues(). Then,
    make both stmmac_release() and stmmac_suspend() to use
    stmmac_disable_all_queues(). Thanks David Miller for spotting the
    synchronize_rcu() issue in v1 patch.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  18 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 600 +++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  87 +++
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.h  |   3 +
 4 files changed, 679 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c49debb62b05..aa0db622ee69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -77,9 +77,14 @@ struct stmmac_tx_queue {
 };
 
 struct stmmac_rx_buffer {
-	struct page *page;
-	dma_addr_t addr;
-	__u32 page_offset;
+	union {
+		struct {
+			struct page *page;
+			dma_addr_t addr;
+			__u32 page_offset;
+		};
+		struct xdp_buff *xdp;
+	};
 	struct page *sec_page;
 	dma_addr_t sec_addr;
 };
@@ -88,6 +93,7 @@ struct stmmac_rx_queue {
 	u32 rx_count_frames;
 	u32 queue_index;
 	struct xdp_rxq_info xdp_rxq;
+	struct xsk_buff_pool *xsk_pool;
 	struct page_pool *page_pool;
 	struct stmmac_rx_buffer *buf_pool;
 	struct stmmac_priv *priv_data;
@@ -95,6 +101,7 @@ struct stmmac_rx_queue {
 	struct dma_desc *dma_rx ____cacheline_aligned_in_smp;
 	unsigned int cur_rx;
 	unsigned int dirty_rx;
+	unsigned int buf_alloc_num;
 	u32 rx_zeroc_thresh;
 	dma_addr_t dma_rx_phy;
 	u32 rx_tail_addr;
@@ -283,6 +290,7 @@ struct stmmac_priv {
 	struct stmmac_rss rss;
 
 	/* XDP BPF Program */
+	unsigned long *af_xdp_zc_qps;
 	struct bpf_prog *xdp_prog;
 };
 
@@ -328,6 +336,10 @@ static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
 	return 0;
 }
 
+void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue);
+int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags);
+
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
 void stmmac_selftest_run(struct net_device *dev,
 			 struct ethtool_test *etest, u64 *buf);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 329a3abbac76..48e755ebcf2b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -40,6 +40,7 @@
 #include <linux/udp.h>
 #include <linux/bpf_trace.h>
 #include <net/pkt_cls.h>
+#include <net/xdp_sock_drv.h>
 #include "stmmac_ptp.h"
 #include "stmmac.h"
 #include "stmmac_xdp.h"
@@ -69,6 +70,8 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_TX_THRESH(x)	((x)->dma_tx_size / 4)
 #define STMMAC_RX_THRESH(x)	((x)->dma_rx_size / 4)
 
+#define STMMAC_RX_FILL_BATCH		16
+
 #define STMMAC_XDP_PASS		0
 #define STMMAC_XDP_CONSUMED	BIT(0)
 #define STMMAC_XDP_TX		BIT(1)
@@ -179,11 +182,7 @@ static void stmmac_verify_args(void)
 		eee_timer = STMMAC_DEFAULT_LPI_TIMER;
 }
 
-/**
- * stmmac_disable_all_queues - Disable all queues
- * @priv: driver private structure
- */
-static void stmmac_disable_all_queues(struct stmmac_priv *priv)
+static void __stmmac_disable_all_queues(struct stmmac_priv *priv)
 {
 	u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
 	u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
@@ -200,6 +199,28 @@ static void stmmac_disable_all_queues(struct stmmac_priv *priv)
 	}
 }
 
+/**
+ * stmmac_disable_all_queues - Disable all queues
+ * @priv: driver private structure
+ */
+static void stmmac_disable_all_queues(struct stmmac_priv *priv)
+{
+	u32 rx_queues_cnt = priv->plat->rx_queues_to_use;
+	struct stmmac_rx_queue *rx_q;
+	u32 queue;
+
+	/* synchronize_rcu() needed for pending XDP buffers to drain */
+	for (queue = 0; queue < rx_queues_cnt; queue++) {
+		rx_q = &priv->rx_queue[queue];
+		if (rx_q->xsk_pool) {
+			synchronize_rcu();
+			break;
+		}
+	}
+
+	__stmmac_disable_all_queues(priv);
+}
+
 /**
  * stmmac_enable_all_queues - Enable all queues
  * @priv: driver private structure
@@ -1509,6 +1530,8 @@ static int stmmac_alloc_rx_buffers(struct stmmac_priv *priv, u32 queue,
 					     queue);
 		if (ret)
 			return ret;
+
+		rx_q->buf_alloc_num++;
 	}
 
 	return 0;
@@ -1539,6 +1562,56 @@ static void dma_recycle_rx_skbufs(struct stmmac_priv *priv, u32 queue)
 	}
 }
 
+/**
+ * dma_free_rx_xskbufs - free RX dma buffers from XSK pool
+ * @priv: private structure
+ * @queue: RX queue index
+ */
+static void dma_free_rx_xskbufs(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[i];
+
+		if (!buf->xdp)
+			continue;
+
+		xsk_buff_free(buf->xdp);
+		buf->xdp = NULL;
+	}
+}
+
+static int stmmac_alloc_rx_buffers_zc(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	int i;
+
+	for (i = 0; i < priv->dma_rx_size; i++) {
+		struct stmmac_rx_buffer *buf;
+		dma_addr_t dma_addr;
+		struct dma_desc *p;
+
+		if (priv->extend_desc)
+			p = (struct dma_desc *)(rx_q->dma_erx + i);
+		else
+			p = rx_q->dma_rx + i;
+
+		buf = &rx_q->buf_pool[i];
+
+		buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+		if (!buf->xdp)
+			return -ENOMEM;
+
+		dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+		stmmac_set_desc_addr(priv, p, dma_addr);
+		rx_q->buf_alloc_num++;
+	}
+
+	return 0;
+}
+
 /**
  * stmmac_reinit_rx_buffers - reinit the RX descriptor buffer.
  * @priv: driver private structure
@@ -1550,15 +1623,31 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	u32 rx_count = priv->plat->rx_queues_to_use;
 	u32 queue;
 
-	for (queue = 0; queue < rx_count; queue++)
-		dma_recycle_rx_skbufs(priv, queue);
+	for (queue = 0; queue < rx_count; queue++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+		if (rx_q->xsk_pool)
+			dma_free_rx_xskbufs(priv, queue);
+		else
+			dma_recycle_rx_skbufs(priv, queue);
+
+		rx_q->buf_alloc_num = 0;
+	}
 
 	for (queue = 0; queue < rx_count; queue++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 		int ret;
 
-		ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
-		if (ret < 0)
-			goto err_reinit_rx_buffers;
+		if (rx_q->xsk_pool) {
+			/* RX XDP ZC buffer pool may not be populated, e.g.
+			 * xdpsock TX-only.
+			 */
+			stmmac_alloc_rx_buffers_zc(priv, queue);
+		} else {
+			ret = stmmac_alloc_rx_buffers(priv, queue, GFP_KERNEL);
+			if (ret < 0)
+				goto err_reinit_rx_buffers;
+		}
 	}
 
 	return;
@@ -1574,6 +1663,14 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	}
 }
 
+static struct xsk_buff_pool *stmmac_get_xsk_pool(struct stmmac_priv *priv, u32 queue)
+{
+	if (!stmmac_xdp_is_enabled(priv) || !test_bit(queue, priv->af_xdp_zc_qps))
+		return NULL;
+
+	return xsk_get_pool_from_qid(priv->dev, queue);
+}
+
 /**
  * __init_dma_rx_desc_rings - init the RX descriptor ring (per queue)
  * @priv: driver private structure
@@ -1594,17 +1691,37 @@ static int __init_dma_rx_desc_rings(struct stmmac_priv *priv, u32 queue, gfp_t f
 
 	stmmac_clear_rx_descriptors(priv, queue);
 
-	WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
-					   MEM_TYPE_PAGE_POOL,
-					   rx_q->page_pool));
+	xdp_rxq_info_unreg_mem_model(&rx_q->xdp_rxq);
 
-	netdev_info(priv->dev,
-		    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
-		    rx_q->queue_index);
+	rx_q->xsk_pool = stmmac_get_xsk_pool(priv, queue);
 
-	ret = stmmac_alloc_rx_buffers(priv, queue, flags);
-	if (ret < 0)
-		return -ENOMEM;
+	if (rx_q->xsk_pool) {
+		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+						   MEM_TYPE_XSK_BUFF_POOL,
+						   NULL));
+		netdev_info(priv->dev,
+			    "Register MEM_TYPE_XSK_BUFF_POOL RxQ-%d\n",
+			    rx_q->queue_index);
+		xsk_pool_set_rxq_info(rx_q->xsk_pool, &rx_q->xdp_rxq);
+	} else {
+		WARN_ON(xdp_rxq_info_reg_mem_model(&rx_q->xdp_rxq,
+						   MEM_TYPE_PAGE_POOL,
+						   rx_q->page_pool));
+		netdev_info(priv->dev,
+			    "Register MEM_TYPE_PAGE_POOL RxQ-%d\n",
+			    rx_q->queue_index);
+	}
+
+	if (rx_q->xsk_pool) {
+		/* RX XDP ZC buffer pool may not be populated, e.g.
+		 * xdpsock TX-only.
+		 */
+		stmmac_alloc_rx_buffers_zc(priv, queue);
+	} else {
+		ret = stmmac_alloc_rx_buffers(priv, queue, flags);
+		if (ret < 0)
+			return -ENOMEM;
+	}
 
 	rx_q->cur_rx = 0;
 	rx_q->dirty_rx = 0;
@@ -1645,7 +1762,15 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 
 err_init_rx_buffers:
 	while (queue >= 0) {
-		dma_free_rx_skbufs(priv, queue);
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+
+		if (rx_q->xsk_pool)
+			dma_free_rx_xskbufs(priv, queue);
+		else
+			dma_free_rx_skbufs(priv, queue);
+
+		rx_q->buf_alloc_num = 0;
+		rx_q->xsk_pool = NULL;
 
 		if (queue == 0)
 			break;
@@ -1790,7 +1915,13 @@ static void __free_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
 	/* Release the DMA RX socket buffers */
-	dma_free_rx_skbufs(priv, queue);
+	if (rx_q->xsk_pool)
+		dma_free_rx_xskbufs(priv, queue);
+	else
+		dma_free_rx_skbufs(priv, queue);
+
+	rx_q->buf_alloc_num = 0;
+	rx_q->xsk_pool = NULL;
 
 	/* Free DMA regions of consistent memory previously allocated */
 	if (!priv->extend_desc)
@@ -2222,12 +2353,24 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 
 	/* configure all channels */
 	for (chan = 0; chan < rx_channels_count; chan++) {
+		struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
+		u32 buf_size;
+
 		qmode = priv->plat->rx_queues_cfg[chan].mode_to_use;
 
 		stmmac_dma_rx_mode(priv, priv->ioaddr, rxmode, chan,
 				rxfifosz, qmode);
-		stmmac_set_dma_bfsize(priv, priv->ioaddr, priv->dma_buf_sz,
-				chan);
+
+		if (rx_q->xsk_pool) {
+			buf_size = xsk_pool_get_rx_frame_size(rx_q->xsk_pool);
+			stmmac_set_dma_bfsize(priv, priv->ioaddr,
+					      buf_size,
+					      chan);
+		} else {
+			stmmac_set_dma_bfsize(priv, priv->ioaddr,
+					      priv->dma_buf_sz,
+					      chan);
+		}
 	}
 
 	for (chan = 0; chan < tx_channels_count; chan++) {
@@ -2638,7 +2781,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv)
 				    rx_q->dma_rx_phy, chan);
 
 		rx_q->rx_tail_addr = rx_q->dma_rx_phy +
-				     (priv->dma_rx_size *
+				     (rx_q->buf_alloc_num *
 				      sizeof(struct dma_desc));
 		stmmac_set_rx_tail_ptr(priv, priv->ioaddr,
 				       rx_q->rx_tail_addr, chan);
@@ -4479,6 +4622,302 @@ static void stmmac_finalize_xdp_rx(struct stmmac_priv *priv,
 		xdp_do_flush();
 }
 
+static struct sk_buff *stmmac_construct_skb_zc(struct stmmac_channel *ch,
+					       struct xdp_buff *xdp)
+{
+	unsigned int metasize = xdp->data - xdp->data_meta;
+	unsigned int datasize = xdp->data_end - xdp->data;
+	struct sk_buff *skb;
+
+	skb = __napi_alloc_skb(&ch->rx_napi,
+			       xdp->data_end - xdp->data_hard_start,
+			       GFP_ATOMIC | __GFP_NOWARN);
+	if (unlikely(!skb))
+		return NULL;
+
+	skb_reserve(skb, xdp->data - xdp->data_hard_start);
+	memcpy(__skb_put(skb, datasize), xdp->data, datasize);
+	if (metasize)
+		skb_metadata_set(skb, metasize);
+
+	return skb;
+}
+
+static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue,
+				   struct dma_desc *p, struct dma_desc *np,
+				   struct xdp_buff *xdp)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned int len = xdp->data_end - xdp->data;
+	enum pkt_hash_types hash_type;
+	int coe = priv->hw->rx_csum;
+	struct sk_buff *skb;
+	u32 hash;
+
+	skb = stmmac_construct_skb_zc(ch, xdp);
+	if (!skb) {
+		priv->dev->stats.rx_dropped++;
+		return;
+	}
+
+	stmmac_get_rx_hwtstamp(priv, p, np, skb);
+	stmmac_rx_vlan(priv->dev, skb);
+	skb->protocol = eth_type_trans(skb, priv->dev);
+
+	if (unlikely(!coe))
+		skb_checksum_none_assert(skb);
+	else
+		skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	if (!stmmac_get_rx_hash(priv, p, &hash, &hash_type))
+		skb_set_hash(skb, hash, hash_type);
+
+	skb_record_rx_queue(skb, queue);
+	napi_gro_receive(&ch->rx_napi, skb);
+
+	priv->dev->stats.rx_packets++;
+	priv->dev->stats.rx_bytes += len;
+}
+
+static bool stmmac_rx_refill_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	unsigned int entry = rx_q->dirty_rx;
+	struct dma_desc *rx_desc = NULL;
+	bool ret = true;
+
+	budget = min(budget, stmmac_rx_dirty(priv, queue));
+
+	while (budget-- > 0 && entry != rx_q->cur_rx) {
+		struct stmmac_rx_buffer *buf = &rx_q->buf_pool[entry];
+		dma_addr_t dma_addr;
+		bool use_rx_wd;
+
+		if (!buf->xdp) {
+			buf->xdp = xsk_buff_alloc(rx_q->xsk_pool);
+			if (!buf->xdp) {
+				ret = false;
+				break;
+			}
+		}
+
+		if (priv->extend_desc)
+			rx_desc = (struct dma_desc *)(rx_q->dma_erx + entry);
+		else
+			rx_desc = rx_q->dma_rx + entry;
+
+		dma_addr = xsk_buff_xdp_get_dma(buf->xdp);
+		stmmac_set_desc_addr(priv, rx_desc, dma_addr);
+		stmmac_set_desc_sec_addr(priv, rx_desc, 0, false);
+		stmmac_refill_desc3(priv, rx_q, rx_desc);
+
+		rx_q->rx_count_frames++;
+		rx_q->rx_count_frames += priv->rx_coal_frames[queue];
+		if (rx_q->rx_count_frames > priv->rx_coal_frames[queue])
+			rx_q->rx_count_frames = 0;
+
+		use_rx_wd = !priv->rx_coal_frames[queue];
+		use_rx_wd |= rx_q->rx_count_frames > 0;
+		if (!priv->use_riwt)
+			use_rx_wd = false;
+
+		dma_wmb();
+		stmmac_set_rx_owner(priv, rx_desc, use_rx_wd);
+
+		entry = STMMAC_GET_ENTRY(entry, priv->dma_rx_size);
+	}
+
+	if (rx_desc) {
+		rx_q->dirty_rx = entry;
+		rx_q->rx_tail_addr = rx_q->dma_rx_phy +
+				     (rx_q->dirty_rx * sizeof(struct dma_desc));
+		stmmac_set_rx_tail_ptr(priv, priv->ioaddr, rx_q->rx_tail_addr, queue);
+	}
+
+	return ret;
+}
+
+static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	unsigned int count = 0, error = 0, len = 0;
+	int dirty = stmmac_rx_dirty(priv, queue);
+	unsigned int next_entry = rx_q->cur_rx;
+	unsigned int desc_size;
+	struct bpf_prog *prog;
+	bool failure = false;
+	int xdp_status = 0;
+	int status = 0;
+
+	if (netif_msg_rx_status(priv)) {
+		void *rx_head;
+
+		netdev_dbg(priv->dev, "%s: descriptor ring:\n", __func__);
+		if (priv->extend_desc) {
+			rx_head = (void *)rx_q->dma_erx;
+			desc_size = sizeof(struct dma_extended_desc);
+		} else {
+			rx_head = (void *)rx_q->dma_rx;
+			desc_size = sizeof(struct dma_desc);
+		}
+
+		stmmac_display_ring(priv, rx_head, priv->dma_rx_size, true,
+				    rx_q->dma_rx_phy, desc_size);
+	}
+	while (count < limit) {
+		struct stmmac_rx_buffer *buf;
+		unsigned int buf1_len = 0;
+		struct dma_desc *np, *p;
+		int entry;
+		int res;
+
+		if (!count && rx_q->state_saved) {
+			error = rx_q->state.error;
+			len = rx_q->state.len;
+		} else {
+			rx_q->state_saved = false;
+			error = 0;
+			len = 0;
+		}
+
+		if (count >= limit)
+			break;
+
+read_again:
+		buf1_len = 0;
+		entry = next_entry;
+		buf = &rx_q->buf_pool[entry];
+
+		if (dirty >= STMMAC_RX_FILL_BATCH) {
+			failure = failure ||
+				  !stmmac_rx_refill_zc(priv, queue, dirty);
+			dirty = 0;
+		}
+
+		if (priv->extend_desc)
+			p = (struct dma_desc *)(rx_q->dma_erx + entry);
+		else
+			p = rx_q->dma_rx + entry;
+
+		/* read the status of the incoming frame */
+		status = stmmac_rx_status(priv, &priv->dev->stats,
+					  &priv->xstats, p);
+		/* check if managed by the DMA otherwise go ahead */
+		if (unlikely(status & dma_own))
+			break;
+
+		/* Prefetch the next RX descriptor */
+		rx_q->cur_rx = STMMAC_GET_ENTRY(rx_q->cur_rx,
+						priv->dma_rx_size);
+		next_entry = rx_q->cur_rx;
+
+		if (priv->extend_desc)
+			np = (struct dma_desc *)(rx_q->dma_erx + next_entry);
+		else
+			np = rx_q->dma_rx + next_entry;
+
+		prefetch(np);
+
+		if (priv->extend_desc)
+			stmmac_rx_extended_status(priv, &priv->dev->stats,
+						  &priv->xstats,
+						  rx_q->dma_erx + entry);
+		if (unlikely(status == discard_frame)) {
+			xsk_buff_free(buf->xdp);
+			buf->xdp = NULL;
+			dirty++;
+			error = 1;
+			if (!priv->hwts_rx_en)
+				priv->dev->stats.rx_errors++;
+		}
+
+		if (unlikely(error && (status & rx_not_ls)))
+			goto read_again;
+		if (unlikely(error)) {
+			count++;
+			continue;
+		}
+
+		/* Ensure a valid XSK buffer before proceed */
+		if (!buf->xdp)
+			break;
+
+		/* XSK pool expects RX frame 1:1 mapped to XSK buffer */
+		if (likely(status & rx_not_ls)) {
+			xsk_buff_free(buf->xdp);
+			buf->xdp = NULL;
+			dirty++;
+			count++;
+			goto read_again;
+		}
+
+		/* XDP ZC Frame only support primary buffers for now */
+		buf1_len = stmmac_rx_buf1_len(priv, p, status, len);
+		len += buf1_len;
+
+		/* ACS is set; GMAC core strips PAD/FCS for IEEE 802.3
+		 * Type frames (LLC/LLC-SNAP)
+		 *
+		 * llc_snap is never checked in GMAC >= 4, so this ACS
+		 * feature is always disabled and packets need to be
+		 * stripped manually.
+		 */
+		if (likely(!(status & rx_not_ls)) &&
+		    (likely(priv->synopsys_id >= DWMAC_CORE_4_00) ||
+		     unlikely(status != llc_snap))) {
+			buf1_len -= ETH_FCS_LEN;
+			len -= ETH_FCS_LEN;
+		}
+
+		/* RX buffer is good and fit into a XSK pool buffer */
+		buf->xdp->data_end = buf->xdp->data + buf1_len;
+		xsk_buff_dma_sync_for_cpu(buf->xdp, rx_q->xsk_pool);
+
+		rcu_read_lock();
+		prog = READ_ONCE(priv->xdp_prog);
+		res = __stmmac_xdp_run_prog(priv, prog, buf->xdp);
+		rcu_read_unlock();
+
+		switch (res) {
+		case STMMAC_XDP_PASS:
+			stmmac_dispatch_skb_zc(priv, queue, p, np, buf->xdp);
+			xsk_buff_free(buf->xdp);
+			break;
+		case STMMAC_XDP_CONSUMED:
+			xsk_buff_free(buf->xdp);
+			priv->dev->stats.rx_dropped++;
+			break;
+		case STMMAC_XDP_TX:
+		case STMMAC_XDP_REDIRECT:
+			xdp_status |= res;
+			break;
+		}
+
+		buf->xdp = NULL;
+		dirty++;
+		count++;
+	}
+
+	if (status & rx_not_ls) {
+		rx_q->state_saved = true;
+		rx_q->state.error = error;
+		rx_q->state.len = len;
+	}
+
+	stmmac_finalize_xdp_rx(priv, xdp_status);
+
+	if (xsk_uses_need_wakeup(rx_q->xsk_pool)) {
+		if (failure || stmmac_rx_dirty(priv, queue) > 0)
+			xsk_set_rx_need_wakeup(rx_q->xsk_pool);
+		else
+			xsk_clear_rx_need_wakeup(rx_q->xsk_pool);
+
+		return (int)count;
+	}
+
+	return failure ? limit : (int)count;
+}
+
 /**
  * stmmac_rx - manage the receive process
  * @priv: driver private structure
@@ -4766,12 +5205,17 @@ static int stmmac_napi_poll_rx(struct napi_struct *napi, int budget)
 	struct stmmac_channel *ch =
 		container_of(napi, struct stmmac_channel, rx_napi);
 	struct stmmac_priv *priv = ch->priv_data;
+	struct stmmac_rx_queue *rx_q;
 	u32 chan = ch->index;
 	int work_done;
 
 	priv->xstats.napi_poll++;
 
-	work_done = stmmac_rx(priv, budget, chan);
+	rx_q = &priv->rx_queue[chan];
+
+	work_done = rx_q->xsk_pool ?
+		    stmmac_rx_zc(priv, budget, chan) :
+		    stmmac_rx(priv, budget, chan);
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
 		unsigned long flags;
 
@@ -5254,7 +5698,7 @@ static int stmmac_setup_tc_block_cb(enum tc_setup_type type, void *type_data,
 	if (!tc_cls_can_offload_and_chain0(priv->dev, type_data))
 		return ret;
 
-	stmmac_disable_all_queues(priv);
+	__stmmac_disable_all_queues(priv);
 
 	switch (type) {
 	case TC_SETUP_CLSU32:
@@ -5675,6 +6119,9 @@ static int stmmac_bpf(struct net_device *dev, struct netdev_bpf *bpf)
 	switch (bpf->command) {
 	case XDP_SETUP_PROG:
 		return stmmac_xdp_set_prog(priv, bpf->prog, bpf->extack);
+	case XDP_SETUP_XSK_POOL:
+		return stmmac_xdp_setup_pool(priv, bpf->xsk.pool,
+					     bpf->xsk.queue_id);
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -5722,6 +6169,102 @@ static int stmmac_xdp_xmit(struct net_device *dev, int num_frames,
 	return nxmit;
 }
 
+void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_disable_dma_irq(priv, priv->ioaddr, queue, 1, 0);
+	spin_unlock_irqrestore(&ch->lock, flags);
+
+	stmmac_stop_rx_dma(priv, queue);
+	__free_dma_rx_desc_resources(priv, queue);
+}
+
+void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+	u32 buf_size;
+	int ret;
+
+	ret = __alloc_dma_rx_desc_resources(priv, queue);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to alloc RX desc.\n");
+		return;
+	}
+
+	ret = __init_dma_rx_desc_rings(priv, queue, GFP_KERNEL);
+	if (ret) {
+		__free_dma_rx_desc_resources(priv, queue);
+		netdev_err(priv->dev, "Failed to init RX desc.\n");
+		return;
+	}
+
+	stmmac_clear_rx_descriptors(priv, queue);
+
+	stmmac_init_rx_chan(priv, priv->ioaddr, priv->plat->dma_cfg,
+			    rx_q->dma_rx_phy, rx_q->queue_index);
+
+	rx_q->rx_tail_addr = rx_q->dma_rx_phy + (rx_q->buf_alloc_num *
+			     sizeof(struct dma_desc));
+	stmmac_set_rx_tail_ptr(priv, priv->ioaddr,
+			       rx_q->rx_tail_addr, rx_q->queue_index);
+
+	if (rx_q->xsk_pool && rx_q->buf_alloc_num) {
+		buf_size = xsk_pool_get_rx_frame_size(rx_q->xsk_pool);
+		stmmac_set_dma_bfsize(priv, priv->ioaddr,
+				      buf_size,
+				      rx_q->queue_index);
+	} else {
+		stmmac_set_dma_bfsize(priv, priv->ioaddr,
+				      priv->dma_buf_sz,
+				      rx_q->queue_index);
+	}
+
+	stmmac_start_rx_dma(priv, queue);
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_enable_dma_irq(priv, priv->ioaddr, queue, 1, 0);
+	spin_unlock_irqrestore(&ch->lock, flags);
+}
+
+int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+	struct stmmac_rx_queue *rx_q;
+	struct stmmac_channel *ch;
+
+	if (test_bit(STMMAC_DOWN, &priv->state) ||
+	    !netif_carrier_ok(priv->dev))
+		return -ENETDOWN;
+
+	if (!stmmac_xdp_is_enabled(priv))
+		return -ENXIO;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	rx_q = &priv->rx_queue[queue];
+	ch = &priv->channel[queue];
+
+	if (!rx_q->xsk_pool)
+		return -ENXIO;
+
+	if (flags & XDP_WAKEUP_RX &&
+	    !napi_if_scheduled_mark_missed(&ch->rx_napi)) {
+		/* EQoS does not have per-DMA channel SW interrupt,
+		 * so we schedule RX Napi straight-away.
+		 */
+		if (likely(napi_schedule_prep(&ch->rx_napi)))
+			__napi_schedule(&ch->rx_napi);
+	}
+
+	return 0;
+}
+
 static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_open = stmmac_open,
 	.ndo_start_xmit = stmmac_xmit,
@@ -5742,6 +6285,7 @@ static const struct net_device_ops stmmac_netdev_ops = {
 	.ndo_vlan_rx_kill_vid = stmmac_vlan_rx_kill_vid,
 	.ndo_bpf = stmmac_bpf,
 	.ndo_xdp_xmit = stmmac_xdp_xmit,
+	.ndo_xsk_wakeup = stmmac_xsk_wakeup,
 };
 
 static void stmmac_reset_subtask(struct stmmac_priv *priv)
@@ -6075,6 +6619,10 @@ int stmmac_dvr_probe(struct device *device,
 	/* Verify driver arguments */
 	stmmac_verify_args();
 
+	priv->af_xdp_zc_qps = bitmap_zalloc(MTL_MAX_TX_QUEUES, GFP_KERNEL);
+	if (!priv->af_xdp_zc_qps)
+		return -ENOMEM;
+
 	/* Allocate workqueue */
 	priv->wq = create_singlethread_workqueue("stmmac_wq");
 	if (!priv->wq) {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
index bf38d231860b..caff0dfc6f4b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
@@ -1,9 +1,96 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (c) 2021, Intel Corporation. */
 
+#include <net/xdp_sock_drv.h>
+
 #include "stmmac.h"
 #include "stmmac_xdp.h"
 
+static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
+				  struct xsk_buff_pool *pool, u16 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	bool need_update;
+	u32 frame_size;
+	int err;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	frame_size = xsk_pool_get_rx_frame_size(pool);
+	/* XDP ZC does not span multiple frame, make sure XSK pool buffer
+	 * size can at least store Q-in-Q frame.
+	 */
+	if (frame_size < ETH_FRAME_LEN + VLAN_HLEN * 2)
+		return -EOPNOTSUPP;
+
+	err = xsk_pool_dma_map(pool, priv->device, STMMAC_RX_DMA_ATTR);
+	if (err) {
+		netdev_err(priv->dev, "Failed to map xsk pool\n");
+		return err;
+	}
+
+	need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv);
+
+	if (need_update) {
+		stmmac_disable_rx_queue(priv, queue);
+		napi_disable(&ch->rx_napi);
+	}
+
+	set_bit(queue, priv->af_xdp_zc_qps);
+
+	if (need_update) {
+		napi_enable(&ch->rx_napi);
+		stmmac_enable_rx_queue(priv, queue);
+
+		err = stmmac_xsk_wakeup(priv->dev, queue, XDP_WAKEUP_RX);
+		if (err)
+			return err;
+	}
+
+	return 0;
+}
+
+static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	struct xsk_buff_pool *pool;
+	bool need_update;
+
+	if (queue >= priv->plat->rx_queues_to_use)
+		return -EINVAL;
+
+	pool = xsk_get_pool_from_qid(priv->dev, queue);
+	if (!pool)
+		return -EINVAL;
+
+	need_update = netif_running(priv->dev) && stmmac_xdp_is_enabled(priv);
+
+	if (need_update) {
+		stmmac_disable_rx_queue(priv, queue);
+		synchronize_rcu();
+		napi_disable(&ch->rx_napi);
+	}
+
+	xsk_pool_dma_unmap(pool, STMMAC_RX_DMA_ATTR);
+
+	clear_bit(queue, priv->af_xdp_zc_qps);
+
+	if (need_update) {
+		napi_enable(&ch->rx_napi);
+		stmmac_enable_rx_queue(priv, queue);
+	}
+
+	return 0;
+}
+
+int stmmac_xdp_setup_pool(struct stmmac_priv *priv, struct xsk_buff_pool *pool,
+			  u16 queue)
+{
+	return pool ? stmmac_xdp_enable_pool(priv, pool, queue) :
+		      stmmac_xdp_disable_pool(priv, queue);
+}
+
 int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
 			struct netlink_ext_ack *extack)
 {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
index 93948569d92a..896dc987d4ef 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.h
@@ -5,7 +5,10 @@
 #define _STMMAC_XDP_H_
 
 #define STMMAC_MAX_RX_BUF_SIZE(num)	(((num) * PAGE_SIZE) - XDP_PACKET_HEADROOM)
+#define STMMAC_RX_DMA_ATTR	(DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING)
 
+int stmmac_xdp_setup_pool(struct stmmac_priv *priv, struct xsk_buff_pool *pool,
+			  u16 queue);
 int stmmac_xdp_set_prog(struct stmmac_priv *priv, struct bpf_prog *prog,
 			struct netlink_ext_ack *extack);
 
-- 
2.25.1



From boon.leong.ong at intel.com  Tue Apr 13 10:36:26 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Tue, 13 Apr 2021 17:36:26 +0800
Subject: [PATCH net-next v2 7/7] net: stmmac: Add TX via XDP zero-copy socket
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <20210413093626.3447-8-boon.leong.ong@intel.com>

We add the support of XDP ZC TX submission and cleaning into
stmmac_tx_clean(). The function is made to clean as many TX complete
frames as possible, i.e. limit by priv->dma_tx_size instead of NAPI
budget. For TX ring that is associated with XSK pool, the function
stmmac_xdp_xmit_zc() is introduced to TX frame buffers from XSK pool by
using xsk_tx_peek_desc(). To make stmmac_tx_clean() support the cleaning
of XSK TX frames, STMMAC_TXBUF_T_XSK_TX TX buffer type is introduced.

As stmmac_tx_clean() uses the return value to cue whether NAPI function
should continue to poll, we augment the caller of stmmac_tx_clean() to
pass NAPI budget instead of priv->dma_tx_size through 'budget' input and
made stmmac_tx_clean() to always clean up-to the TX ring size instead.
This allows us to use the return boolean status of stmmac_xdp_xmit_zc()
to decide if XSK TX work is done or not: If true, set 'xmits' to return
'budget - 1' so that NAPI poll may exit. Else, set 'xmits' to return
'budget' to make NAPI poll continue to poll since XSK TX work is not
done. Finally, at the end of stmmac_tx_clean(), the function now take
a maximum value between 'count' and 'xmits' so that status from both
TX cleaning and XSK TX (only for XDP ZC) is considered.

This patch adds a new NAPI poll called stmmac_napi_poll_rxtx() that is
meant to be enabled/disabled for RX and TX ring that are bound to XSK
pool. This NAPI poll function starts with cleaning TX ring, then submits
XSK TX frames to TX ring before proceed to perform RX operations, i.e.
, receiving RX frames and replenishing RX ring with RX free buffers
obtained from XSK pool. Therefore, during XSK RX and TX setup, the driver
enables stmmac_napi_poll_rxtx() for RX and TX operations, then during
XSK RX and TX pool tear-down, the driver reenables the exisiting
independent NAPI poll functions accordingly: stmmac_napi_poll_rx() and
stmmac_napi_poll_tx().

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |   6 +
 .../net/ethernet/stmicro/stmmac/stmmac_main.c | 317 ++++++++++++++++--
 .../net/ethernet/stmicro/stmmac/stmmac_xdp.c  |  16 +-
 3 files changed, 310 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index aa0db622ee69..3d9ceb6234eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -40,6 +40,7 @@ enum stmmac_txbuf_type {
 	STMMAC_TXBUF_T_SKB,
 	STMMAC_TXBUF_T_XDP_TX,
 	STMMAC_TXBUF_T_XDP_NDO,
+	STMMAC_TXBUF_T_XSK_TX,
 };
 
 struct stmmac_tx_info {
@@ -69,6 +70,8 @@ struct stmmac_tx_queue {
 		struct xdp_frame **xdpf;
 	};
 	struct stmmac_tx_info *tx_skbuff_dma;
+	struct xsk_buff_pool *xsk_pool;
+	u32 xsk_frames_done;
 	unsigned int cur_tx;
 	unsigned int dirty_tx;
 	dma_addr_t dma_tx_phy;
@@ -116,6 +119,7 @@ struct stmmac_rx_queue {
 struct stmmac_channel {
 	struct napi_struct rx_napi ____cacheline_aligned_in_smp;
 	struct napi_struct tx_napi ____cacheline_aligned_in_smp;
+	struct napi_struct rxtx_napi ____cacheline_aligned_in_smp;
 	struct stmmac_priv *priv_data;
 	spinlock_t lock;
 	u32 index;
@@ -338,6 +342,8 @@ static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
 
 void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue);
 void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_disable_tx_queue(struct stmmac_priv *priv, u32 queue);
+void stmmac_enable_tx_queue(struct stmmac_priv *priv, u32 queue);
 int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags);
 
 #if IS_ENABLED(CONFIG_STMMAC_SELFTESTS)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 48e755ebcf2b..d10a67f0b21c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -70,6 +70,9 @@ MODULE_PARM_DESC(phyaddr, "Physical device address");
 #define STMMAC_TX_THRESH(x)	((x)->dma_tx_size / 4)
 #define STMMAC_RX_THRESH(x)	((x)->dma_rx_size / 4)
 
+/* Limit to make sure XDP TX and slow path can coexist */
+#define STMMAC_XSK_TX_BUDGET_MAX	256
+#define STMMAC_TX_XSK_AVAIL		16
 #define STMMAC_RX_FILL_BATCH		16
 
 #define STMMAC_XDP_PASS		0
@@ -120,6 +123,8 @@ 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 void stmmac_tx_timer_arm(struct stmmac_priv *priv, u32 queue);
+static void stmmac_flush_tx_descriptors(struct stmmac_priv *priv, int queue);
 
 #ifdef CONFIG_DEBUG_FS
 static const struct net_device_ops stmmac_netdev_ops;
@@ -192,6 +197,12 @@ static void __stmmac_disable_all_queues(struct stmmac_priv *priv)
 	for (queue = 0; queue < maxq; queue++) {
 		struct stmmac_channel *ch = &priv->channel[queue];
 
+		if (stmmac_xdp_is_enabled(priv) &&
+		    test_bit(queue, priv->af_xdp_zc_qps)) {
+			napi_disable(&ch->rxtx_napi);
+			continue;
+		}
+
 		if (queue < rx_queues_cnt)
 			napi_disable(&ch->rx_napi);
 		if (queue < tx_queues_cnt)
@@ -235,6 +246,12 @@ static void stmmac_enable_all_queues(struct stmmac_priv *priv)
 	for (queue = 0; queue < maxq; queue++) {
 		struct stmmac_channel *ch = &priv->channel[queue];
 
+		if (stmmac_xdp_is_enabled(priv) &&
+		    test_bit(queue, priv->af_xdp_zc_qps)) {
+			napi_enable(&ch->rxtx_napi);
+			continue;
+		}
+
 		if (queue < rx_queues_cnt)
 			napi_enable(&ch->rx_napi);
 		if (queue < tx_queues_cnt)
@@ -1488,6 +1505,9 @@ static void stmmac_free_tx_buffer(struct stmmac_priv *priv, u32 queue, int i)
 		tx_q->xdpf[i] = NULL;
 	}
 
+	if (tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_XSK_TX)
+		tx_q->xsk_frames_done++;
+
 	if (tx_q->tx_skbuff[i] &&
 	    tx_q->tx_skbuff_dma[i].buf_type == STMMAC_TXBUF_T_SKB) {
 		dev_kfree_skb_any(tx_q->tx_skbuff[i]);
@@ -1810,6 +1830,8 @@ static int __init_dma_tx_desc_rings(struct stmmac_priv *priv, u32 queue)
 					 priv->dma_tx_size, 0);
 	}
 
+	tx_q->xsk_pool = stmmac_get_xsk_pool(priv, queue);
+
 	for (i = 0; i < priv->dma_tx_size; i++) {
 		struct dma_desc *p;
 
@@ -1886,10 +1908,19 @@ static int init_dma_desc_rings(struct net_device *dev, gfp_t flags)
  */
 static void dma_free_tx_skbufs(struct stmmac_priv *priv, u32 queue)
 {
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	int i;
 
+	tx_q->xsk_frames_done = 0;
+
 	for (i = 0; i < priv->dma_tx_size; i++)
 		stmmac_free_tx_buffer(priv, queue, i);
+
+	if (tx_q->xsk_pool && tx_q->xsk_frames_done) {
+		xsk_tx_completed(tx_q->xsk_pool, tx_q->xsk_frames_done);
+		tx_q->xsk_frames_done = 0;
+		tx_q->xsk_pool = NULL;
+	}
 }
 
 /**
@@ -2010,6 +2041,7 @@ static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 	bool xdp_prog = stmmac_xdp_is_enabled(priv);
 	struct page_pool_params pp_params = { 0 };
 	unsigned int num_pages;
+	unsigned int napi_id;
 	int ret;
 
 	rx_q->queue_index = queue;
@@ -2057,9 +2089,15 @@ static int __alloc_dma_rx_desc_resources(struct stmmac_priv *priv, u32 queue)
 			return -ENOMEM;
 	}
 
+	if (stmmac_xdp_is_enabled(priv) &&
+	    test_bit(queue, priv->af_xdp_zc_qps))
+		napi_id = ch->rxtx_napi.napi_id;
+	else
+		napi_id = ch->rx_napi.napi_id;
+
 	ret = xdp_rxq_info_reg(&rx_q->xdp_rxq, priv->dev,
 			       rx_q->queue_index,
-			       ch->rx_napi.napi_id);
+			       napi_id);
 	if (ret) {
 		netdev_err(priv->dev, "Failed to register xdp rxq info\n");
 		return -EINVAL;
@@ -2381,6 +2419,101 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
 	}
 }
 
+static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget)
+{
+	struct netdev_queue *nq = netdev_get_tx_queue(priv->dev, queue);
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	struct xsk_buff_pool *pool = tx_q->xsk_pool;
+	unsigned int entry = tx_q->cur_tx;
+	struct dma_desc *tx_desc = NULL;
+	struct xdp_desc xdp_desc;
+	bool work_done = true;
+
+	/* Avoids TX time-out as we are sharing with slow path */
+	nq->trans_start = jiffies;
+
+	budget = min(budget, stmmac_tx_avail(priv, queue));
+
+	while (budget-- > 0) {
+		dma_addr_t dma_addr;
+		bool set_ic;
+
+		/* We are sharing with slow path and stop XSK TX desc submission when
+		 * available TX ring is less than threshold.
+		 */
+		if (unlikely(stmmac_tx_avail(priv, queue) < STMMAC_TX_XSK_AVAIL) ||
+		    !netif_carrier_ok(priv->dev)) {
+			work_done = false;
+			break;
+		}
+
+		if (!xsk_tx_peek_desc(pool, &xdp_desc))
+			break;
+
+		if (likely(priv->extend_desc))
+			tx_desc = (struct dma_desc *)(tx_q->dma_etx + entry);
+		else if (tx_q->tbs & STMMAC_TBS_AVAIL)
+			tx_desc = &tx_q->dma_entx[entry].basic;
+		else
+			tx_desc = tx_q->dma_tx + entry;
+
+		dma_addr = xsk_buff_raw_get_dma(pool, xdp_desc.addr);
+		xsk_buff_raw_dma_sync_for_device(pool, dma_addr, xdp_desc.len);
+
+		tx_q->tx_skbuff_dma[entry].buf_type = STMMAC_TXBUF_T_XSK_TX;
+
+		/* To return XDP buffer to XSK pool, we simple call
+		 * xsk_tx_completed(), so we don't need to fill up
+		 * 'buf' and 'xdpf'.
+		 */
+		tx_q->tx_skbuff_dma[entry].buf = 0;
+		tx_q->xdpf[entry] = NULL;
+
+		tx_q->tx_skbuff_dma[entry].map_as_page = false;
+		tx_q->tx_skbuff_dma[entry].len = xdp_desc.len;
+		tx_q->tx_skbuff_dma[entry].last_segment = true;
+		tx_q->tx_skbuff_dma[entry].is_jumbo = false;
+
+		stmmac_set_desc_addr(priv, tx_desc, dma_addr);
+
+		tx_q->tx_count_frames++;
+
+		if (!priv->tx_coal_frames[queue])
+			set_ic = false;
+		else if (tx_q->tx_count_frames % priv->tx_coal_frames[queue] == 0)
+			set_ic = true;
+		else
+			set_ic = false;
+
+		if (set_ic) {
+			tx_q->tx_count_frames = 0;
+			stmmac_set_tx_ic(priv, tx_desc);
+			priv->xstats.tx_set_ic_bit++;
+		}
+
+		stmmac_prepare_tx_desc(priv, tx_desc, 1, xdp_desc.len,
+				       true, priv->mode, true, true,
+				       xdp_desc.len);
+
+		stmmac_enable_dma_transmission(priv, priv->ioaddr);
+
+		tx_q->cur_tx = STMMAC_GET_ENTRY(tx_q->cur_tx, priv->dma_tx_size);
+		entry = tx_q->cur_tx;
+	}
+
+	if (tx_desc) {
+		stmmac_flush_tx_descriptors(priv, queue);
+		xsk_tx_release(pool);
+	}
+
+	/* Return true if all of the 3 conditions are met
+	 *  a) TX Budget is still available
+	 *  b) work_done = true when XSK TX desc peek is empty (no more
+	 *     pending XSK TX for transmission)
+	 */
+	return !!budget && work_done;
+}
+
 /**
  * stmmac_tx_clean - to manage the transmission completion
  * @priv: driver private structure
@@ -2392,14 +2525,18 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 {
 	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
 	unsigned int bytes_compl = 0, pkts_compl = 0;
-	unsigned int entry, count = 0;
+	unsigned int entry, xmits = 0, count = 0;
 
 	__netif_tx_lock_bh(netdev_get_tx_queue(priv->dev, queue));
 
 	priv->xstats.tx_clean++;
 
+	tx_q->xsk_frames_done = 0;
+
 	entry = tx_q->dirty_tx;
-	while ((entry != tx_q->cur_tx) && (count < budget)) {
+
+	/* Try to clean all TX complete frame in 1 shot */
+	while ((entry != tx_q->cur_tx) && count < priv->dma_tx_size) {
 		struct xdp_frame *xdpf;
 		struct sk_buff *skb;
 		struct dma_desc *p;
@@ -2484,6 +2621,9 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 			tx_q->xdpf[entry] = NULL;
 		}
 
+		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_XSK_TX)
+			tx_q->xsk_frames_done++;
+
 		if (tx_q->tx_skbuff_dma[entry].buf_type == STMMAC_TXBUF_T_SKB) {
 			if (likely(skb)) {
 				pkts_compl++;
@@ -2511,6 +2651,28 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 		netif_tx_wake_queue(netdev_get_tx_queue(priv->dev, queue));
 	}
 
+	if (tx_q->xsk_pool) {
+		bool work_done;
+
+		if (tx_q->xsk_frames_done)
+			xsk_tx_completed(tx_q->xsk_pool, tx_q->xsk_frames_done);
+
+		if (xsk_uses_need_wakeup(tx_q->xsk_pool))
+			xsk_set_tx_need_wakeup(tx_q->xsk_pool);
+
+		/* For XSK TX, we try to send as many as possible.
+		 * If XSK work done (XSK TX desc empty and budget still
+		 * available), return "budget - 1" to reenable TX IRQ.
+		 * Else, return "budget" to make NAPI continue polling.
+		 */
+		work_done = stmmac_xdp_xmit_zc(priv, queue,
+					       STMMAC_XSK_TX_BUDGET_MAX);
+		if (work_done)
+			xmits = budget - 1;
+		else
+			xmits = budget;
+	}
+
 	if (priv->eee_enabled && !priv->tx_path_in_lpi_mode &&
 	    priv->eee_sw_timer_en) {
 		stmmac_enable_eee_mode(priv);
@@ -2525,7 +2687,8 @@ static int stmmac_tx_clean(struct stmmac_priv *priv, int budget, u32 queue)
 
 	__netif_tx_unlock_bh(netdev_get_tx_queue(priv->dev, queue));
 
-	return count;
+	/* Combine decisions from TX clean and XSK TX */
+	return max(count, xmits);
 }
 
 /**
@@ -2607,24 +2770,31 @@ static int stmmac_napi_check(struct stmmac_priv *priv, u32 chan, u32 dir)
 {
 	int status = stmmac_dma_interrupt_status(priv, priv->ioaddr,
 						 &priv->xstats, chan, dir);
+	struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[chan];
 	struct stmmac_channel *ch = &priv->channel[chan];
+	struct napi_struct *rx_napi;
+	struct napi_struct *tx_napi;
 	unsigned long flags;
 
+	rx_napi = rx_q->xsk_pool ? &ch->rxtx_napi : &ch->rx_napi;
+	tx_napi = tx_q->xsk_pool ? &ch->rxtx_napi : &ch->tx_napi;
+
 	if ((status & handle_rx) && (chan < priv->plat->rx_queues_to_use)) {
-		if (napi_schedule_prep(&ch->rx_napi)) {
+		if (napi_schedule_prep(rx_napi)) {
 			spin_lock_irqsave(&ch->lock, flags);
 			stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 1, 0);
 			spin_unlock_irqrestore(&ch->lock, flags);
-			__napi_schedule(&ch->rx_napi);
+			__napi_schedule(rx_napi);
 		}
 	}
 
 	if ((status & handle_tx) && (chan < priv->plat->tx_queues_to_use)) {
-		if (napi_schedule_prep(&ch->tx_napi)) {
+		if (napi_schedule_prep(tx_napi)) {
 			spin_lock_irqsave(&ch->lock, flags);
 			stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 0, 1);
 			spin_unlock_irqrestore(&ch->lock, flags);
-			__napi_schedule(&ch->tx_napi);
+			__napi_schedule(tx_napi);
 		}
 	}
 
@@ -2822,16 +2992,18 @@ static enum hrtimer_restart stmmac_tx_timer(struct hrtimer *t)
 	struct stmmac_tx_queue *tx_q = container_of(t, struct stmmac_tx_queue, txtimer);
 	struct stmmac_priv *priv = tx_q->priv_data;
 	struct stmmac_channel *ch;
+	struct napi_struct *napi;
 
 	ch = &priv->channel[tx_q->queue_index];
+	napi = tx_q->xsk_pool ? &ch->rxtx_napi : &ch->tx_napi;
 
-	if (likely(napi_schedule_prep(&ch->tx_napi))) {
+	if (likely(napi_schedule_prep(napi))) {
 		unsigned long flags;
 
 		spin_lock_irqsave(&ch->lock, flags);
 		stmmac_disable_dma_irq(priv, priv->ioaddr, ch->index, 0, 1);
 		spin_unlock_irqrestore(&ch->lock, flags);
-		__napi_schedule(&ch->tx_napi);
+		__napi_schedule(napi);
 	}
 
 	return HRTIMER_NORESTART;
@@ -4629,7 +4801,7 @@ static struct sk_buff *stmmac_construct_skb_zc(struct stmmac_channel *ch,
 	unsigned int datasize = xdp->data_end - xdp->data;
 	struct sk_buff *skb;
 
-	skb = __napi_alloc_skb(&ch->rx_napi,
+	skb = __napi_alloc_skb(&ch->rxtx_napi,
 			       xdp->data_end - xdp->data_hard_start,
 			       GFP_ATOMIC | __GFP_NOWARN);
 	if (unlikely(!skb))
@@ -4673,7 +4845,7 @@ static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue,
 		skb_set_hash(skb, hash, hash_type);
 
 	skb_record_rx_queue(skb, queue);
-	napi_gro_receive(&ch->rx_napi, skb);
+	napi_gro_receive(&ch->rxtx_napi, skb);
 
 	priv->dev->stats.rx_packets++;
 	priv->dev->stats.rx_bytes += len;
@@ -5205,17 +5377,12 @@ static int stmmac_napi_poll_rx(struct napi_struct *napi, int budget)
 	struct stmmac_channel *ch =
 		container_of(napi, struct stmmac_channel, rx_napi);
 	struct stmmac_priv *priv = ch->priv_data;
-	struct stmmac_rx_queue *rx_q;
 	u32 chan = ch->index;
 	int work_done;
 
 	priv->xstats.napi_poll++;
 
-	rx_q = &priv->rx_queue[chan];
-
-	work_done = rx_q->xsk_pool ?
-		    stmmac_rx_zc(priv, budget, chan) :
-		    stmmac_rx(priv, budget, chan);
+	work_done = stmmac_rx(priv, budget, chan);
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
 		unsigned long flags;
 
@@ -5237,7 +5404,7 @@ static int stmmac_napi_poll_tx(struct napi_struct *napi, int budget)
 
 	priv->xstats.napi_poll++;
 
-	work_done = stmmac_tx_clean(priv, priv->dma_tx_size, chan);
+	work_done = stmmac_tx_clean(priv, budget, chan);
 	work_done = min(work_done, budget);
 
 	if (work_done < budget && napi_complete_done(napi, work_done)) {
@@ -5251,6 +5418,42 @@ static int stmmac_napi_poll_tx(struct napi_struct *napi, int budget)
 	return work_done;
 }
 
+static int stmmac_napi_poll_rxtx(struct napi_struct *napi, int budget)
+{
+	struct stmmac_channel *ch =
+		container_of(napi, struct stmmac_channel, rxtx_napi);
+	struct stmmac_priv *priv = ch->priv_data;
+	int rx_done, tx_done;
+	u32 chan = ch->index;
+
+	priv->xstats.napi_poll++;
+
+	tx_done = stmmac_tx_clean(priv, budget, chan);
+	tx_done = min(tx_done, budget);
+
+	rx_done = stmmac_rx_zc(priv, budget, chan);
+
+	/* If either TX or RX work is not complete, return budget
+	 * and keep pooling
+	 */
+	if (tx_done >= budget || rx_done >= budget)
+		return budget;
+
+	/* all work done, exit the polling mode */
+	if (napi_complete_done(napi, rx_done)) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&ch->lock, flags);
+		/* Both RX and TX work done are compelte,
+		 * so enable both RX & TX IRQs.
+		 */
+		stmmac_enable_dma_irq(priv, priv->ioaddr, chan, 1, 1);
+		spin_unlock_irqrestore(&ch->lock, flags);
+	}
+
+	return min(rx_done, budget - 1);
+}
+
 /**
  *  stmmac_tx_timeout
  *  @dev : Pointer to net device structure
@@ -6231,10 +6434,63 @@ void stmmac_enable_rx_queue(struct stmmac_priv *priv, u32 queue)
 	spin_unlock_irqrestore(&ch->lock, flags);
 }
 
+void stmmac_disable_tx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_disable_dma_irq(priv, priv->ioaddr, queue, 0, 1);
+	spin_unlock_irqrestore(&ch->lock, flags);
+
+	stmmac_stop_tx_dma(priv, queue);
+	__free_dma_tx_desc_resources(priv, queue);
+}
+
+void stmmac_enable_tx_queue(struct stmmac_priv *priv, u32 queue)
+{
+	struct stmmac_tx_queue *tx_q = &priv->tx_queue[queue];
+	struct stmmac_channel *ch = &priv->channel[queue];
+	unsigned long flags;
+	int ret;
+
+	ret = __alloc_dma_tx_desc_resources(priv, queue);
+	if (ret) {
+		netdev_err(priv->dev, "Failed to alloc TX desc.\n");
+		return;
+	}
+
+	ret = __init_dma_tx_desc_rings(priv, queue);
+	if (ret) {
+		__free_dma_tx_desc_resources(priv, queue);
+		netdev_err(priv->dev, "Failed to init TX desc.\n");
+		return;
+	}
+
+	stmmac_clear_tx_descriptors(priv, queue);
+
+	stmmac_init_tx_chan(priv, priv->ioaddr, priv->plat->dma_cfg,
+			    tx_q->dma_tx_phy, tx_q->queue_index);
+
+	if (tx_q->tbs & STMMAC_TBS_AVAIL)
+		stmmac_enable_tbs(priv, priv->ioaddr, 1, tx_q->queue_index);
+
+	tx_q->tx_tail_addr = tx_q->dma_tx_phy;
+	stmmac_set_tx_tail_ptr(priv, priv->ioaddr,
+			       tx_q->tx_tail_addr, tx_q->queue_index);
+
+	stmmac_start_tx_dma(priv, queue);
+
+	spin_lock_irqsave(&ch->lock, flags);
+	stmmac_enable_dma_irq(priv, priv->ioaddr, queue, 0, 1);
+	spin_unlock_irqrestore(&ch->lock, flags);
+}
+
 int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	struct stmmac_rx_queue *rx_q;
+	struct stmmac_tx_queue *tx_q;
 	struct stmmac_channel *ch;
 
 	if (test_bit(STMMAC_DOWN, &priv->state) ||
@@ -6244,22 +6500,23 @@ int stmmac_xsk_wakeup(struct net_device *dev, u32 queue, u32 flags)
 	if (!stmmac_xdp_is_enabled(priv))
 		return -ENXIO;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	rx_q = &priv->rx_queue[queue];
+	tx_q = &priv->tx_queue[queue];
 	ch = &priv->channel[queue];
 
-	if (!rx_q->xsk_pool)
+	if (!rx_q->xsk_pool && !tx_q->xsk_pool)
 		return -ENXIO;
 
-	if (flags & XDP_WAKEUP_RX &&
-	    !napi_if_scheduled_mark_missed(&ch->rx_napi)) {
+	if (!napi_if_scheduled_mark_missed(&ch->rxtx_napi)) {
 		/* EQoS does not have per-DMA channel SW interrupt,
 		 * so we schedule RX Napi straight-away.
 		 */
-		if (likely(napi_schedule_prep(&ch->rx_napi)))
-			__napi_schedule(&ch->rx_napi);
+		if (likely(napi_schedule_prep(&ch->rxtx_napi)))
+			__napi_schedule(&ch->rxtx_napi);
 	}
 
 	return 0;
@@ -6444,6 +6701,12 @@ static void stmmac_napi_add(struct net_device *dev)
 					  stmmac_napi_poll_tx,
 					  NAPI_POLL_WEIGHT);
 		}
+		if (queue < priv->plat->rx_queues_to_use &&
+		    queue < priv->plat->tx_queues_to_use) {
+			netif_napi_add(dev, &ch->rxtx_napi,
+				       stmmac_napi_poll_rxtx,
+				       NAPI_POLL_WEIGHT);
+		}
 	}
 }
 
@@ -6461,6 +6724,10 @@ static void stmmac_napi_del(struct net_device *dev)
 			netif_napi_del(&ch->rx_napi);
 		if (queue < priv->plat->tx_queues_to_use)
 			netif_napi_del(&ch->tx_napi);
+		if (queue < priv->plat->rx_queues_to_use &&
+		    queue < priv->plat->tx_queues_to_use) {
+			netif_napi_del(&ch->rxtx_napi);
+		}
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
index caff0dfc6f4b..105821b53020 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_xdp.c
@@ -14,7 +14,8 @@ static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
 	u32 frame_size;
 	int err;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	frame_size = xsk_pool_get_rx_frame_size(pool);
@@ -34,14 +35,17 @@ static int stmmac_xdp_enable_pool(struct stmmac_priv *priv,
 
 	if (need_update) {
 		stmmac_disable_rx_queue(priv, queue);
+		stmmac_disable_tx_queue(priv, queue);
 		napi_disable(&ch->rx_napi);
+		napi_disable(&ch->tx_napi);
 	}
 
 	set_bit(queue, priv->af_xdp_zc_qps);
 
 	if (need_update) {
-		napi_enable(&ch->rx_napi);
+		napi_enable(&ch->rxtx_napi);
 		stmmac_enable_rx_queue(priv, queue);
+		stmmac_enable_tx_queue(priv, queue);
 
 		err = stmmac_xsk_wakeup(priv->dev, queue, XDP_WAKEUP_RX);
 		if (err)
@@ -57,7 +61,8 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 	struct xsk_buff_pool *pool;
 	bool need_update;
 
-	if (queue >= priv->plat->rx_queues_to_use)
+	if (queue >= priv->plat->rx_queues_to_use ||
+	    queue >= priv->plat->tx_queues_to_use)
 		return -EINVAL;
 
 	pool = xsk_get_pool_from_qid(priv->dev, queue);
@@ -68,8 +73,9 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 
 	if (need_update) {
 		stmmac_disable_rx_queue(priv, queue);
+		stmmac_disable_tx_queue(priv, queue);
 		synchronize_rcu();
-		napi_disable(&ch->rx_napi);
+		napi_disable(&ch->rxtx_napi);
 	}
 
 	xsk_pool_dma_unmap(pool, STMMAC_RX_DMA_ATTR);
@@ -78,7 +84,9 @@ static int stmmac_xdp_disable_pool(struct stmmac_priv *priv, u16 queue)
 
 	if (need_update) {
 		napi_enable(&ch->rx_napi);
+		napi_enable(&ch->tx_napi);
 		stmmac_enable_rx_queue(priv, queue);
+		stmmac_enable_tx_queue(priv, queue);
 	}
 
 	return 0;
-- 
2.25.1



From o.rempel at pengutronix.de  Tue Apr 13 10:43:05 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Tue, 13 Apr 2021 11:43:05 +0200
Subject: [PATCH v2 0/7] remove different PHY fixups
In-Reply-To: <CAOMZO5CRFHh5vv3vQqaatDnq55ZMmO5DfJH1VtZ1n0DBgf5Whg@mail.gmail.com>
References: <20210309112615.625-1-o.rempel@pengutronix.de>
 <CAOMZO5CYquzd4BBZBUM6ufWkPqfidctruWmaDROwHKVmi3NX2A@mail.gmail.com>
 <YGM2AGfawEFTKOtE@lunn.ch>
 <CAOMZO5CRFHh5vv3vQqaatDnq55ZMmO5DfJH1VtZ1n0DBgf5Whg@mail.gmail.com>
Message-ID: <20210413094305.kvjgaiseppg5hrzh@pengutronix.de>

Hello,

On Tue, Mar 30, 2021 at 12:04:50PM -0300, Fabio Estevam wrote:
> Hi Andrew,
> 
> On Tue, Mar 30, 2021 at 11:30 AM Andrew Lunn <andrew at lunn.ch> wrote:
> 
> > Hi Fabio
> >
> > I think it should be merged, and we fixup anything which does break.
> > We are probably at the point where more is broken by not merging it
> > than merging it.
> 
> Thanks for your feedback. I agree.
> 
> Shawn wants to collect some Acked-by for this series.
> 
> Could you please give your Acked-by for this series?

Andrew, can you please add you ACK?

Shawn will it be enough or you need more ACKs?

Regards,
Oleksij
-- 
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 Apr 13 10:47:37 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 13 Apr 2021 10:47:37 +0100
Subject: [PATCH v16 0/9] arm64: ARMv8.5-A: MTE: Add async mode support
In-Reply-To: <20210315132019.33202-1-vincenzo.frascino@arm.com>
References: <20210315132019.33202-1-vincenzo.frascino@arm.com>
Message-ID: <161830715687.1113.4436583872879811764.b4-ty@arm.com>

On Mon, 15 Mar 2021 13:20:10 +0000, Vincenzo Frascino wrote:
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory errors like buffer overflow, use-after-free, use-after-return, etc.
> 
> MTE is built on top of the AArch64 v8.0 virtual address tagging TBI
> (Top Byte Ignore) feature and allows a task to set a 4 bit tag on any
> subset of its address space that is multiple of a 16 bytes granule. MTE
> is based on a lock-key mechanism where the lock is the tag associated to
> the physical memory and the key is the tag associated to the virtual
> address.
> When MTE is enabled and tags are set for ranges of address space of a task,
> the PE will compare the tag related to the physical memory with the tag
> related to the virtual address (tag check operation). Access to the memory
> is granted only if the two tags match. In case of mismatch the PE will raise
> an exception.
> 
> [...]

Applied to arm64 (for-next/mte-async-kernel-mode) but with a note that
I'll drop them if Andrew prefers to take the patches via the mm tree.
Thanks!

[1/9] arm64: mte: Add asynchronous mode support
      https://git.kernel.org/arm64/c/f3b7deef8dca
[2/9] kasan: Add KASAN mode kernel parameter
      https://git.kernel.org/arm64/c/2603f8a78dfb
[3/9] arm64: mte: Drop arch_enable_tagging()
      https://git.kernel.org/arm64/c/c137c6145b11
[4/9] kasan: Add report for async mode
      https://git.kernel.org/arm64/c/8f7b5054755e
[5/9] arm64: mte: Enable TCO in functions that can read beyond buffer limits
      https://git.kernel.org/arm64/c/e60beb95c08b
[6/9] arm64: mte: Conditionally compile mte_enable_kernel_*()
      https://git.kernel.org/arm64/c/d8969752cc4e
[7/9] arm64: mte: Enable async tag check fault
      https://git.kernel.org/arm64/c/65812c6921cc
[8/9] arm64: mte: Report async tag faults before suspend
      https://git.kernel.org/arm64/c/eab0e6e17d87
[9/9] kasan, arm64: tests supports for HW_TAGS async mode
      https://git.kernel.org/arm64/c/e80a76aa1a91

-- 
Catalin



From yang.lee at linux.alibaba.com  Tue Apr 13 10:48:21 2021
From: yang.lee at linux.alibaba.com (Yang Li)
Date: Tue, 13 Apr 2021 17:48:21 +0800
Subject: [PATCH] i2c: busses: remove unused including <linux/version.h>
Message-ID: <1618307301-72925-1-git-send-email-yang.lee@linux.alibaba.com>

Fix the following versioncheck warnings:
./drivers/i2c/busses/i2c-xgene-slimpro.c: 22 linux/version.h not needed.
./drivers/i2c/busses/i2c-brcmstb.c: 25 linux/version.h not needed.

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
---
 drivers/i2c/busses/i2c-brcmstb.c       | 1 -
 drivers/i2c/busses/i2c-xgene-slimpro.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index ba766d2..490ee39 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -22,7 +22,6 @@
 #include <linux/platform_device.h>
 #include <linux/sched.h>
 #include <linux/slab.h>
-#include <linux/version.h>
 
 #define N_DATA_REGS					8
 
diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c b/drivers/i2c/busses/i2c-xgene-slimpro.c
index 63cbb9c7..bba08cb 100644
--- a/drivers/i2c/busses/i2c-xgene-slimpro.c
+++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
@@ -19,7 +19,6 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
-#include <linux/version.h>
 
 #define MAILBOX_OP_TIMEOUT		1000	/* Operation time out in ms */
 #define MAILBOX_I2C_INDEX		0
-- 
1.8.3.1



From daniel.vetter at ffwll.ch  Tue Apr 13 10:48:54 2021
From: daniel.vetter at ffwll.ch (Daniel Vetter)
Date: Tue, 13 Apr 2021 11:48:54 +0200
Subject: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
Message-ID: <20210413094904.3736372-3-daniel.vetter@ffwll.ch>

Since

commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Inki Dae <inki.dae at samsung.com>
Cc: Joonyoung Shim <jy0922.shim at samsung.com>
Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: Krzysztof Kozlowski <krzk at kernel.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 64370b634cca..79fa3649185c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
 	dev->mode_config.funcs = &exynos_drm_mode_config_funcs;
 	dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
 
-	dev->mode_config.allow_fb_modifiers = true;
-
 	dev->mode_config.normalize_zpos = true;
 }
-- 
2.31.0



From daniel.vetter at ffwll.ch  Tue Apr 13 10:48:56 2021
From: daniel.vetter at ffwll.ch (Daniel Vetter)
Date: Tue, 13 Apr 2021 11:48:56 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
Message-ID: <20210413094904.3736372-5-daniel.vetter@ffwll.ch>

Since

commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

This one actually set it twice on top of what drm_plane_init does, so
double-redundant!

Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
 drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
index b549ce5e7607..37ae68a7fba5 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
@@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
 	config->min_height = 1;
 	config->max_width = 4096;
 	config->max_height = 4096;
-	config->allow_fb_modifiers = true;
 	config->normalize_zpos = true;
 
 	config->funcs = &dcss_drm_mode_config_funcs;
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
index 2ded8e4f32d0..8be4edaec958 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
 	drm->mode_config.max_height = 4096;
 	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
 	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
-	drm->mode_config.allow_fb_modifiers = true;
 	drm->mode_config.normalize_zpos = true;
 
 	ret = drmm_mode_config_init(drm);
-- 
2.31.0



From daniel.vetter at ffwll.ch  Tue Apr 13 10:49:00 2021
From: daniel.vetter at ffwll.ch (Daniel Vetter)
Date: Tue, 13 Apr 2021 11:49:00 +0200
Subject: [PATCH 09/12] drm/stm: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
Message-ID: <20210413094904.3736372-9-daniel.vetter@ffwll.ch>

Since

commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Yannick Fertre <yannick.fertre at foss.st.com>
Cc: Philippe Cornu <philippe.cornu at foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard at linaro.org>
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/gpu/drm/stm/ltdc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
 		goto err;
 	}
 
-	ddev->mode_config.allow_fb_modifiers = true;
-
 	ret = ltdc_crtc_init(ddev, crtc);
 	if (ret) {
 		DRM_ERROR("Failed to init crtc\n");
-- 
2.31.0



From lorenzo.pieralisi at arm.com  Tue Apr 13 10:53:05 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 13 Apr 2021 10:53:05 +0100
Subject: [v9,2/7] PCI: Export pci_pio_to_address() for module use
In-Reply-To: <20210324090942.kmhxnxzm7tz3ynuy@pali>
References: <20210324030510.29177-1-jianjun.wang@mediatek.com>
 <20210324030510.29177-3-jianjun.wang@mediatek.com>
 <20210324090942.kmhxnxzm7tz3ynuy@pali>
Message-ID: <20210413095257.GA21802@lpieralisi>

On Wed, Mar 24, 2021 at 10:09:42AM +0100, Pali Roh?r wrote:
> On Wednesday 24 March 2021 11:05:05 Jianjun Wang wrote:
> > This interface will be used by PCI host drivers for PIO translation,
> > export it to support compiling those drivers as kernel modules.
> > 
> > Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
> > ---
> >  drivers/pci/pci.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 16a17215f633..12bba221c9f2 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -4052,6 +4052,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> >  
> >  	return address;
> >  }
> > +EXPORT_SYMBOL(pci_pio_to_address);
> 
> Hello! I'm not sure if EXPORT_SYMBOL is correct because file has GPL-2.0
> header. Should not be in this case used only EXPORT_SYMBOL_GPL? Maybe
> other people would know what is correct?

I think this should be EXPORT_SYMBOL_GPL(), I can make this change
but this requires Bjorn's ACK to go upstream (Bjorn, it is my fault,
it was assigned to me on patchwork, now updated, please have a look).

Thanks,
Lorenzo

> >  
> >  unsigned long __weak pci_address_to_pio(phys_addr_t address)
> >  {
> > -- 
> > 2.25.1
> > 


From broonie at kernel.org  Tue Apr 13 10:55:22 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 13 Apr 2021 10:55:22 +0100
Subject: New 'make dtbs_check W=1' warnings
In-Reply-To: <CAK8P3a1_YB944niA-ebk-nJx-JDBh1q7z6s-9mLGFjF2Nv9r9w@mail.gmail.com>
References: <CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA@mail.gmail.com>
 <CAMuHMdWY0aGoAw6QfF5PQRFNFwAzNP9cmFCjbKnsSbHsMz45fQ@mail.gmail.com>
 <CAK8P3a3EaaTGvAYvffbf7AF-iaC05yMShdnTc2QMcKQGZv7N8Q@mail.gmail.com>
 <20210412160116.GA904837@yoga>
 <CAK8P3a1_YB944niA-ebk-nJx-JDBh1q7z6s-9mLGFjF2Nv9r9w@mail.gmail.com>
Message-ID: <20210413095522.GA5586@sirena.org.uk>

On Mon, Apr 12, 2021 at 08:52:37PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 12, 2021 at 6:01 PM Bjorn Andersson
> > On Mon 12 Apr 08:14 CDT 2021, Arnd Bergmann wrote:

> > So the same binding patch is picked up both in the driver and soc tree?
> > I was expecting that to cause (harmless) conflicts when things arrive in
> > Linus' merge queue?

> > Or are you saying people go the length to create immutable branches for
> > each binding?

> I think it's usually one immutable branch for all the bindings of a given
> merge window. This avoids the merge conflicts, and you can add further
> bindings on the same branch before sending it off to the soc tree.

Even with a single branch for everything having to split serieses into
multiple branches seems like a pain, it'll break my automation 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/20210413/6783d967/attachment.sig>

From l.stach at pengutronix.de  Tue Apr 13 11:00:45 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 13 Apr 2021 12:00:45 +0200
Subject: [PATCH v2 0/7] remove different PHY fixups
In-Reply-To: <20210309112615.625-1-o.rempel@pengutronix.de>
References: <20210309112615.625-1-o.rempel@pengutronix.de>
Message-ID: <c03053f59a89ef6ea4a4f2ce15aee4b4f4892745.camel@pengutronix.de>

Hi all,

Am Dienstag, dem 09.03.2021 um 12:26 +0100 schrieb Oleksij Rempel:
> changes v2:
> - rebase against latest kernel
> - fix networking on RIoTBoard
> 
> This patch series tries to remove most of the imx6 and imx7 board
> specific PHY configuration via fixup, as this breaks the PHYs when
> connected to switch chips or USB Ethernet MACs.
> 
> Each patch has the possibility to break boards, but contains a
> recommendation to fix the problem in a more portable and future-proof
> way.

I agree with the opinion that those PHY fixups introduce more harm than
good. Essentially they are pushing board specific configuration values
into the PHY, without any checks that the fixup is even running on the
specific board it was targeted at.

While there is a real chance to break some out of tree boards or
incomplete configs I think that's something we can accept here. If
someone makes a case why they can absolutely not fixup their DT or
kernel config we could even bring back some of those fixups with a
proper board compatible check to avoid mashing things up for other
boards with the same PHY. I guess the only realistic way to learn if
someone can make such a case is to apply this series and look for any
fallout.

So for what it is worth:
Acked-by: Lucas Stach <l.stach at pengutronix.de>

> regards,
> Oleksij
> 
> Oleksij Rempel (7):
> ??ARM: imx6q: remove PHY fixup for KSZ9031
> ??ARM: imx6q: remove TX clock delay of ar8031_phy_fixup()
> ??ARM: imx6q: remove hand crafted PHY power up in ar8035_phy_fixup()
> ??ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035
> ????PHYs
> ??ARM: imx6q: remove Atheros AR8035 SmartEEE fixup
> ??ARM: imx6sx: remove Atheros AR8031 PHY fixup
> ??ARM: imx7d: remove Atheros AR8031 PHY fixup
> 
> ?arch/arm/boot/dts/imx6dl-riotboard.dts  |  2 +
> ?arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts |  2 +-
> ?arch/arm/mach-imx/mach-imx6q.c          | 85 -------------------------
> ?arch/arm/mach-imx/mach-imx6sx.c         | 26 --------
> ?arch/arm/mach-imx/mach-imx7d.c          | 22 -------
> ?5 files changed, 3 insertions(+), 134 deletions(-)
> 




From bpeled at marvell.com  Tue Apr 13 11:14:15 2021
From: bpeled at marvell.com (Ben Peled)
Date: Tue, 13 Apr 2021 10:14:15 +0000
Subject: =?utf-8?B?UkU6IFvigJ1QQVRDSOKAnSAwLzVdIEFzeW5jaHJvbm91cyBsaW5rZG93biBy?=
 =?utf-8?Q?ecovery?=
In-Reply-To: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
Message-ID: <MW2PR18MB22175AED0E4FCC2BF640AB8CC24F9@MW2PR18MB2217.namprd18.prod.outlook.com>

Hi all,
Please ignore this patch list there is a small change missing. 

-----Original Message-----
From: bpeled at marvell.com <bpeled at marvell.com> 
Sent: Monday, April 12, 2021 6:31 PM
To: thomas.petazzoni at bootlin.com; lorenzo.pieralisi at arm.com; bhelgaas at google.com
Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-pci at vger.kernel.org; sebastian.hesselbarth at gmail.com; gregory.clement at bootlin.com; andrew at lunn.ch; robh+dt at kernel.org; mw at semihalf.com; jaz at semihalf.com; Kostya Porotchkin <kostap at marvell.com>; Nadav Haklai <nadavh at marvell.com>; Stefan Chulski <stefanc at marvell.com>; Ofer Heifetz <oferh at marvell.com>; Ben Peled <bpeled at marvell.com>
Subject: [?PATCH? 0/5] Asynchronous linkdown recovery

From: Ben Peled <bpeled at marvell.com>

The following patches implement the required procedure to handle and recover from asynchronous PCIE link down events on Armada SoCs.

The procedure is defined as the following:
1) Prevent new access to the PCI-E I/F by disabling the LTSSM
2) Flush all pending transaction/access to the PCI-E I/F
3) HW reset the PCIE end point device (based on board support)
4) Reset the PCIE MAC
5) Reinitialize the PCIE root complex and enable the LTSSM

The execution of this procedure is triggered by the PCIE RST_LINK_DOWN interrupt

Ben Peled (5):
  PCI: armada8k: Disable LTSSM on link down interrupts
  PCI: armada8k: Add link-down handle
  PCI: armada8k: add device reset to link-down handle
  dt-bindings: pci: add system controller and MAC reset bit to    
    Armada 7K/8K controller bindings
  arm64: dts: marvell: add pcie mac reset to pcie

 Documentation/devicetree/bindings/pci/pci-armada8k.txt |   6 +
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi          |   7 ++
 drivers/pci/controller/dwc/pcie-armada8k.c             | 126 ++++++++++++++++++++
 3 files changed, 139 insertions(+)

-- 
2.7.4


From bgolaszewski at baylibre.com  Tue Apr 13 11:39:25 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Tue, 13 Apr 2021 12:39:25 +0200
Subject: [PATCH] gpio: mxs: remove useless function
In-Reply-To: <1618193781-35329-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1618193781-35329-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <CAMpxmJUBPEC9mLCM9DgnMxRcY-H3gEXgcgw9Xp+TyEA7SUDQkw@mail.gmail.com>

On Mon, Apr 12, 2021 at 4:16 AM Jiapeng Chong
<jiapeng.chong at linux.alibaba.com> wrote:
>
> Fix the following gcc warning:
>
> drivers/gpio/gpio-mxs.c:63:19: warning: kernel/sys_ni.cunused function
> 'is_imx28_gpio'.
>
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
> ---
>  drivers/gpio/gpio-mxs.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
> index dfc0c1e..524b668 100644
> --- a/drivers/gpio/gpio-mxs.c
> +++ b/drivers/gpio/gpio-mxs.c
> @@ -60,11 +60,6 @@ static inline int is_imx23_gpio(struct mxs_gpio_port *port)
>         return port->devid == IMX23_GPIO;
>  }
>
> -static inline int is_imx28_gpio(struct mxs_gpio_port *port)
> -{
> -       return port->devid == IMX28_GPIO;
> -}
> -
>  /* Note: This driver assumes 32 GPIOs are handled in one register */
>
>  static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
> --
> 1.8.3.1
>

Patch applied, thanks!

Bartosz


From bgolaszewski at baylibre.com  Tue Apr 13 11:43:48 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Tue, 13 Apr 2021 12:43:48 +0200
Subject: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
 the code
In-Reply-To: <CAHp75Vddd6ygr4mJ9Z+SuGZmfLcgDLWLZaxby2XE2mX8War-qQ@mail.gmail.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
 <20210409140806.31824-2-srinivas.neeli@xilinx.com>
 <CAHp75Vddd6ygr4mJ9Z+SuGZmfLcgDLWLZaxby2XE2mX8War-qQ@mail.gmail.com>
Message-ID: <CAMpxmJW=HWf_NxGpfBkX=utgOTs4+6RtypxnKGtpuYnX=t8rGQ@mail.gmail.com>

On Sat, Apr 10, 2021 at 12:08 AM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
>
>
>
> On Friday, April 9, 2021, Srinivas Neeli <srinivas.neeli at xilinx.com> wrote:
>>
>> module_platform_driver() makes the code simpler by eliminating
>> boilerplate code.
>>
>> Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
>> ---
>>  drivers/gpio/gpio-zynq.c | 17 +----------------
>>  1 file changed, 1 insertion(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
>> index 3521c1dc3ac0..bb1ac0c5cf26 100644
>> --- a/drivers/gpio/gpio-zynq.c
>> +++ b/drivers/gpio/gpio-zynq.c
>> @@ -1020,22 +1020,7 @@ static struct platform_driver zynq_gpio_driver = {
>>         .remove = zynq_gpio_remove,
>>  };
>>
>> -/**
>> - * zynq_gpio_init - Initial driver registration call
>> - *
>> - * Return: value from platform_driver_register
>> - */
>> -static int __init zynq_gpio_init(void)
>> -{
>> -       return platform_driver_register(&zynq_gpio_driver);
>> -}
>> -postcore_initcall(zynq_gpio_init);
>
>
>
> It?s not an equivalent. Have you tested on actual hardware? If no, there is no go for this change.
>

Yep, this has been like this since the initial introduction of this
driver. Unfortunately there's no documented reason so unless we can
test it, it has to stay this way.

Bartosz


From song.bao.hua at hisilicon.com  Tue Apr 13 11:45:44 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Tue, 13 Apr 2021 10:45:44 +0000
Subject: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and
 add cluster scheduler
In-Reply-To: <4fdc781e-7385-2ae6-d9c9-3ec165f473c4@arm.com>
References: <20210106083026.40444-1-song.bao.hua@hisilicon.com>
 <737932c9-846a-0a6b-08b8-e2d2d95b67ce@linux.intel.com>
 <20210108151241.GA47324@e123083-lin>
 <99c07bdf-02d1-153a-bd1e-2f4200cc67c5@linux.intel.com>
 <20210111092811.GB47324@e123083-lin>
 <4fdc781e-7385-2ae6-d9c9-3ec165f473c4@arm.com>
Message-ID: <9201b56a29dd4dacb7d9fcbf307ca5ff@hisilicon.com>



> -----Original Message-----
> From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]
> Sent: Wednesday, January 13, 2021 12:00 AM
> To: Morten Rasmussen <morten.rasmussen at arm.com>; Tim Chen
> <tim.c.chen at linux.intel.com>
> Cc: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> valentin.schneider at arm.com; catalin.marinas at arm.com; will at kernel.org;
> rjw at rjwysocki.net; vincent.guittot at linaro.org; lenb at kernel.org;
> gregkh at linuxfoundation.org; Jonathan Cameron <jonathan.cameron at huawei.com>;
> mingo at redhat.com; peterz at infradead.org; juri.lelli at redhat.com;
> rostedt at goodmis.org; bsegall at google.com; mgorman at suse.de;
> mark.rutland at arm.com; sudeep.holla at arm.com; aubrey.li at linux.intel.com;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> linux-acpi at vger.kernel.org; linuxarm at openeuler.org; xuwei (O)
> <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>; tiantao (H)
> <tiantao6 at hisilicon.com>
> Subject: Re: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and
> add cluster scheduler
> 
> On 11/01/2021 10:28, Morten Rasmussen wrote:
> > On Fri, Jan 08, 2021 at 12:22:41PM -0800, Tim Chen wrote:
> >>
> >>
> >> On 1/8/21 7:12 AM, Morten Rasmussen wrote:
> >>> On Thu, Jan 07, 2021 at 03:16:47PM -0800, Tim Chen wrote:
> >>>> On 1/6/21 12:30 AM, Barry Song wrote:
> 
> [...]
> 
> >> I think it is going to depend on the workload.  If there are dependent
> >> tasks that communicate with one another, putting them together
> >> in the same cluster will be the right thing to do to reduce communication
> >> costs.  On the other hand, if the tasks are independent, putting them together
> on the same cluster
> >> will increase resource contention and spreading them out will be better.
> >
> > Agree. That is exactly where I'm coming from. This is all about the task
> > placement policy. We generally tend to spread tasks to avoid resource
> > contention, SMT and caches, which seems to be what you are proposing to
> > extend. I think that makes sense given it can produce significant
> > benefits.
> >
> >>
> >> Any thoughts on what is the right clustering "tag" to use to clump
> >> related tasks together?
> >> Cgroup? Pid? Tasks with same mm?
> >
> > I think this is the real question. I think the closest thing we have at
> > the moment is the wakee/waker flip heuristic. This seems to be related.
> > Perhaps the wake_affine tricks can serve as starting point?
> 
> wake_wide() switches between packing (select_idle_sibling(), llc_size
> CPUs) and spreading (find_idlest_cpu(), all CPUs).
> 
> AFAICS, since none of the sched domains set SD_BALANCE_WAKE, currently
> all wakeups are (llc-)packed.
> 
>  select_task_rq_fair()
> 
>    for_each_domain(cpu, tmp)
> 
>      if (tmp->flags & sd_flag)
>        sd = tmp;
> 
> 
> In case we would like to further distinguish between llc-packing and
> even narrower (cluster or MC-L2)-packing, we would introduce a 2. level
> packing vs. spreading heuristic further down in sis().
> 
> IMHO, Barry's current implementation doesn't do this right now. Instead
> he's trying to pack on cluster first and if not successful look further
> among the remaining llc CPUs for an idle CPU.

Right now in the main cases of using wake_affine to achieve
better performance, processes are actually bound within one
numa which is also a LLC in kunpeng920. 

Probably LLC=NUMA is also true for X86 Jacobsville, Tim?

So one possible way to pretend a 2-level packing might be:
if the affinity cpuset of waker and waker are both subset
of one same LLC, we totally use cluster as the factor to
determine packing or not and ignore LLC.

I haven't really done this, but the below code can make the
same result by forcing llc_id=cluster_id:

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index d72eb8d..3d78097 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -107,7 +107,7 @@ int __init parse_acpi_topology(void)
                cpu_topology[cpu].cluster_id = topology_id;
                topology_id = find_acpi_cpu_topology_package(cpu);
                cpu_topology[cpu].package_id = topology_id;
-
+#if 0
                i = acpi_find_last_cache_level(cpu);

                if (i > 0) {
@@ -119,8 +119,11 @@ int __init parse_acpi_topology(void)
                        if (cache_id > 0)
                                cpu_topology[cpu].llc_id = cache_id;
                }
-       }
+#else
+               cpu_topology[cpu].llc_id = cpu_topology[cpu].cluster_id;
+#endif

+       }
        return 0;
 }
 #endif

With this, I have seen some major improvement in hackbench especially
for monogamous communication model (fds_num=1, one sender for one
receiver):
numactl -N 0 hackbench -p -T -l 200000 -f 1 -g $1

I have tested -g(group_nums) 6, 12, 18, 24, 28, 32,
For each different g, I ran 20 times and got the
average value. The result is as below:

g=    6      12    18      24    28     32
w/o 1.3243 1.6741 1.7560 1.9036 2.0262 2.1826
w/  1.1314 1.1864 1.4494 1.6159 1.9078 2.1249

Using top -H and hit "f" to show cpu of each thread,
I am seeing the two threads in one group are likely
to run in a cluster. That's why the hackbench latency
is decreasing much.

Thanks
Barry

From lorenzo.pieralisi at arm.com  Tue Apr 13 11:48:33 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 13 Apr 2021 11:48:33 +0100
Subject: [PATCH -next] PCI: mediatek: Add missing MODULE_DEVICE_TABLE
In-Reply-To: <20210331085938.3115-1-linqiheng@huawei.com>
References: <20210331085938.3115-1-linqiheng@huawei.com>
Message-ID: <161831089975.6369.2070015191943714889.b4-ty@arm.com>

On Wed, 31 Mar 2021 16:59:38 +0800, Qiheng Lin wrote:
> This patch adds missing MODULE_DEVICE_TABLE definition which generates
> correct modalias for automatic loading of this driver when it is built
> as an external module.

Applied to pci/mediatek, thanks!

[1/1] PCI: mediatek: Add missing MODULE_DEVICE_TABLE
      https://git.kernel.org/lpieralisi/pci/c/87db343f80

Thanks,
Lorenzo


From linux at armlinux.org.uk  Tue Apr 13 11:51:44 2021
From: linux at armlinux.org.uk (Russell King - ARM Linux admin)
Date: Tue, 13 Apr 2021 11:51:44 +0100
Subject: [PATCH v2 0/7] remove different PHY fixups
In-Reply-To: <c03053f59a89ef6ea4a4f2ce15aee4b4f4892745.camel@pengutronix.de>
References: <20210309112615.625-1-o.rempel@pengutronix.de>
 <c03053f59a89ef6ea4a4f2ce15aee4b4f4892745.camel@pengutronix.de>
Message-ID: <20210413105144.GN1463@shell.armlinux.org.uk>

On Tue, Apr 13, 2021 at 12:00:45PM +0200, Lucas Stach wrote:
> I agree with the opinion that those PHY fixups introduce more harm than
> good. Essentially they are pushing board specific configuration values
> into the PHY, without any checks that the fixup is even running on the
> specific board it was targeted at.

Yes and no. The problem is, that's an easy statement to make when one
doesn't understand what they're all doing.

Some are "board specific" in that the normal setup for e.g. iMX6 would
be to enable clock output from the AR8035 PHY and feed that into the
iMX6 - as far as I'm aware, that's the only working configuration for
that SoC and PHY. However, it's also true that this fixup should not
be applied unconditionally.

Then there's SmartEEE - it has been found that the PHY defaults for
this lead to link drops independent of the board and SoC that it is
connected to. It seems that the PHY is essentially broken - it powers
up with SmartEEE enabled, and when connected to another SmartEEE
supporting device, it seems guaranteed that it will result in link
drops in its default configuration.

Freescale's approach has apparently been to unconditionally disable
SmartEEE for all their platforms because of this. With a bit of
research however (as has been done by Jon and myself) we've found
that increasing the Tw parameter for 1G connections results in a
much more stable link.

So, just saying that these are bad without actually understanding what
they are doing is _also_ bad.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!


From eugen.hristev at microchip.com  Tue Apr 13 11:56:58 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:56:58 +0300
Subject: [PATCH v3 00/33] media: atmel: atmel-isc: add support for xisc
Message-ID: <20210413105731.610028-1-eugen.hristev@microchip.com>

Hello,

This series adds support for a variant of the ISC named XISC.
This block is present in the product named sama7g5.

I started by moving code around, the code which was specialized for sama5d2
type of ISC, to have it inside the dedicated sama5d2 file.

I added several new pipeline elements to the code base, which would be common
to sama5d2 and the new sama7g5, but only used by the new style pipeline.

I separated the input and output formats on a per-product separate array.

I added the new sama7g5 compatible driver for the xisc, which is similar with
the sama5d2, but with differences in terms of DT, clocks and callbacks to
specific operations.

I converted the atmel-isc binding to yaml format, and added the new binding in yaml
format.

Feedback is appreciated.
Thanks,
Eugen

Changes in v3:
- Adapted commit messages for several commits to explain several acronyms, especially
for submodule names
- Converted atmel-isc binding to yaml
- Converted microchip-xisc binding to yaml
- Updated MAINTAINERS

Changes in v2:
- Fixed krobot warnings with W=1 regarding functions with no prototype
- Fixed new sama7g5 driver to use the new subdev fwnode API in kernel 5.12. my driver was
based on old 5.10 style API.

Eugen Hristev (33):
  media: atmel: atmel-isc: specialize gamma table into product specific
  media: atmel: atmel-isc: specialize driver name constant
  media: atmel: atmel-isc: add checks for limiting frame sizes
  media: atmel: atmel-isc: specialize max width and max height
  media: atmel: atmel-isc: specialize dma cfg
  media: atmel: atmel-isc: extract CSC submodule config into separate
    function
  media: atmel: atmel-isc-base: add id to clock debug message
  media: atmel: atmel-isc: create register offsets struct
  media: atmel: atmel-isc: extract CBC submodule config into separate
    function
  media: atmel: atmel-isc: add CBC to the reg offsets struct
  media: atmel: atmel-isc: add SUB422 and SUB420 to register offsets
  media: atmel: atmel-isc: add RLP to register offsets
  media: atmel: atmel-isc: add HIS to register offsets
  media: atmel: atmel-isc: add DMA to register offsets
  media: atmel: atmel-isc: add support for version register
  media: atmel: atmel-isc: add his_entry to register offsets
  media: atmel: atmel-isc: add register description for additional
    modules
  media: atmel: atmel-isc: extend pipeline with extra modules
  media: atmel: atmel-isc: add CC initialization function
  media: atmel: atmel-isc: create product specific v4l2 controls config
  media: atmel: atmel-isc: create callback for DPC submodule product
    specific
  media: atmel: atmel-isc: create callback for GAM submodule product
    specific
  media: atmel: atmel-isc: create callback for RLP submodule product
    specific
  media: atmel: atmel-isc: move the formats list into product specific
    code
  media: atmel: atmel-isc: create an adapt pipeline callback for product
    specific
  media: atmel: atmel-isc-regs: add additional fields for sama7g5 type
    pipeline
  media: atmel: atmel-isc-base: add support for more formats and
    additional pipeline modules
  media: atmel: atmel-isc-sama5d2: remove duplicate define
  dt-bindings: media: atmel-isc: convert to yaml
  dt-bindings: media: add microchip,xisc device bindings
  media: atmel: atmel-isc: add microchip-xisc driver
  MAINTAINERS: update ISC driver bindings file
  MAINTAINERS: add xisc files to isc driver entry

 .../devicetree/bindings/media/atmel,isc.yaml  | 115 ++++
 .../devicetree/bindings/media/atmel-isc.txt   |  65 --
 .../bindings/media/microchip,xisc.yaml        | 129 ++++
 MAINTAINERS                                   |   4 +-
 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c | 381 ++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h | 133 +++-
 drivers/media/platform/atmel/atmel-isc.h      | 122 +++-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 311 ++++++++-
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
 12 files changed, 1574 insertions(+), 343 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml
 delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
 create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:56:59 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:56:59 +0300
Subject: [PATCH v3 01/33] media: atmel: atmel-isc: specialize gamma table into
 product specific
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-2-eugen.hristev@microchip.com>

Separate the gamma table from the isc base file into the specific sama5d2
product file.
Add a pointer to the gamma table and entries count inside the platform
driver specific struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 47 ++-----------------
 drivers/media/platform/atmel/atmel-isc.h      | 11 +++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 45 ++++++++++++++++++
 3 files changed, 56 insertions(+), 47 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..8b6c5e339cb8 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -176,48 +176,6 @@ struct isc_format formats_list[] = {
 
 };
 
-/* Gamma table with gamma 1/2.2 */
-const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES] = {
-	/* 0 --> gamma 1/1.8 */
-	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
-	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
-	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
-	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
-	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
-	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
-	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
-	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
-	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
-	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
-	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
-
-	/* 1 --> gamma 1/2 */
-	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
-	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
-	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
-	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
-	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
-	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
-	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
-	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
-	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
-	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
-	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
-
-	/* 2 --> gamma 1/2.2 */
-	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
-	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
-	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
-	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
-	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
-	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
-	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
-	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
-	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
-	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
-	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -683,7 +641,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	regmap_write(regmap, ISC_CFA_CFG, bay_cfg | ISC_CFA_CFG_EITPOL);
 
-	gamma = &isc_gamma_table[ctrls->gamma_index][0];
+	gamma = &isc->gamma_table[ctrls->gamma_index][0];
 	regmap_bulk_write(regmap, ISC_GAM_BENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
@@ -2070,7 +2028,8 @@ static int isc_ctrl_init(struct isc_device *isc)
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX, 1, 2);
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
+			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
 					  V4L2_CID_AUTO_WHITE_BALANCE,
 					  0, 1, 1, 1);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fab8eca58d93..f1df47a4655b 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -187,6 +187,10 @@ struct isc_ctrls {
  *
  * @current_subdev:	current subdevice: the sensor
  * @subdev_entities:	list of subdevice entitites
+ *
+ * @gamma_table:	pointer to the table with gamma values, has
+ *			gamma_max sets of GAMMA_ENTRIES entries each
+ * @gamma_max:		maximum number of sets of inside the gamma_table
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -245,16 +249,17 @@ struct isc_device {
 		struct v4l2_ctrl	*gr_off_ctrl;
 		struct v4l2_ctrl	*gb_off_ctrl;
 	};
-};
 
-#define GAMMA_MAX	2
 #define GAMMA_ENTRIES	64
+	/* pointer to the defined gamma table */
+	const u32	(*gamma_table)[GAMMA_ENTRIES];
+	u32		gamma_max;
+};
 
 #define ATMEL_ISC_NAME "atmel-isc"
 
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
-extern const u32 isc_gamma_table[GAMMA_MAX + 1][GAMMA_ENTRIES];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0b78fecfd2a8..c74f36245bd5 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,48 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
+	/* 0 --> gamma 1/1.8 */
+	{      0x65,  0x66002F,  0x950025,  0xBB0020,  0xDB001D,  0xF8001A,
+	  0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
+	  0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
+	  0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
+	  0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
+	  0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
+	  0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
+	  0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
+	  0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
+	  0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
+	  0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
+
+	/* 1 --> gamma 1/2 */
+	{      0x7F,  0x800034,  0xB50028,  0xDE0021, 0x100001E, 0x11E001B,
+	  0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
+	  0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
+	  0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
+	  0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
+	  0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
+	  0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
+	  0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
+	  0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
+	  0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
+	  0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
+
+	/* 2 --> gamma 1/2.2 */
+	{      0x99,  0x9B0038,  0xD4002A,  0xFF0023, 0x122001F, 0x141001B,
+	  0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
+	  0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
+	  0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
+	  0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
+	  0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
+	  0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
+	  0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
+	  0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
+	  0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
+	  0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
+};
+
 static int isc_parse_dt(struct device *dev, struct isc_device *isc)
 {
 	struct device_node *np = dev->of_node;
@@ -150,6 +192,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	isc->gamma_table = isc_sama5d2_gamma_table;
+	isc->gamma_max = 2;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From andre.przywara at arm.com  Tue Apr 13 11:58:37 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 13 Apr 2021 11:58:37 +0100
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
 <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
Message-ID: <20210413115837.232c465a@slackpad.fritz.box>

On Mon, 12 Apr 2021 19:41:25 +0200
Michael Weiser <michael.weiser at gmx.de> wrote:

Hi Michael,

> Hi Andre, ChenYu,
> 
> On Mon, Apr 12, 2021 at 05:45:58PM +0100, Andre Przywara wrote:
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > index e79ce49e7e6a..843338e19694 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > > > @@ -21,5 +21,5 @@
> > > >  };
> > > >
> > > >  &mmc0 {
> > > > -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> > > > +       non-removable;          /* card detect is broken on some boards */    
> > > 
> > > So a revert is good, but has anyone tried using the "broken-cd" instead?  
> > Ha, that's a good idea, I totally forgot about this property!  
> 
> > > That way, at least on Linux, the mmc core resorts to polling for a card.
> > > At least this way the card is still removable.  
> > Yes indeed, I tested it on my "stuck at 1" Pine64-LTS, and it works like
> > a charm!  
> 
> > Daniel, Michael, can you test this on your boards? So removing the
> > cd-gpios property, and adding "broken-cd;" instead?  
> 
> Yes, it works fine. What flummoxed me at first was that obviously I also
> have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
> after having added and disabled an ACTIVE_HIGH definition in
> sun50i-a64-pine64-lts.dts.

Why? From my experiments it should not matter, the actual card presence
is typically detected via the SD bus anyway (if I understand the code
correctly). broken-cd just prevents installation of an interrupt
handler, so it's less efficient and prevents wakeup on card detect,
AFAICS.
But also: ACTIVE_HIGH *is* the right polarity, even for the
Pine64-LTS. At least that's what an earlier report from Daniel
suggested:
=> gpio input pf6
card inserted: value is 1
card removed: value is 0
So for your particular board (version) you could actually remove the
whole &mmc0 node override, use the same node as the SOPine (working
active-high CD) and it should work.

> BTW: My boards have a marking "PINE64-R18-V1_1" and below it
> "2017-08-03" on their upper side. On the back it says on one sticker
> "Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
> "PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
> perhaps?  Is there a way to detect this difference in software and add
> some sort of quirk handler for it?

As Jernej mentioned, this would be U-Boot's task, but I don't see a
good reason for it. Firstly, you would need to find a good automatic
way of determining the board revision, which I doubt there is. And
secondly, I don't see the benefit: It works quite nicely with
broken-cd: card removals and insertions are detected automatically,
it's just not as efficient (interrupt-driven) as it could be.
Or do you see any problems with broken-cd?

Cheers,
Andre


From eugen.hristev at microchip.com  Tue Apr 13 11:57:00 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:00 +0300
Subject: [PATCH v3 02/33] media: atmel: atmel-isc: specialize driver name
 constant
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-3-eugen.hristev@microchip.com>

The driver name constant must defined based on product driver, thus moving
the constant directly where it's required. This will allow each ISC based
product to define it's own name.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc.h         | 2 --
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 4 ++--
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8b6c5e339cb8..277a8fd8b83d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -896,7 +896,7 @@ static int isc_querycap(struct file *file, void *priv,
 {
 	struct isc_device *isc = video_drvdata(file);
 
-	strscpy(cap->driver, ATMEL_ISC_NAME, sizeof(cap->driver));
+	strscpy(cap->driver, "microchip-isc", sizeof(cap->driver));
 	strscpy(cap->card, "Atmel Image Sensor Controller", sizeof(cap->card));
 	snprintf(cap->bus_info, sizeof(cap->bus_info),
 		 "platform:%s", isc->v4l2_dev.name);
@@ -2246,7 +2246,7 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
 	}
 
 	/* Register video device */
-	strscpy(vdev->name, ATMEL_ISC_NAME, sizeof(vdev->name));
+	strscpy(vdev->name, "microchip-isc", sizeof(vdev->name));
 	vdev->release		= video_device_release_empty;
 	vdev->fops		= &isc_fops;
 	vdev->ioctl_ops		= &isc_ioctl_ops;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f1df47a4655b..8d81d9967ad2 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -256,8 +256,6 @@ struct isc_device {
 	u32		gamma_max;
 };
 
-#define ATMEL_ISC_NAME "atmel-isc"
-
 extern struct isc_format formats_list[];
 extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c74f36245bd5..f45d8b96bfb8 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -185,7 +185,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 		return irq;
 
 	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
-			       ATMEL_ISC_NAME, isc);
+			       "atmel-sama5d2-isc", isc);
 	if (ret < 0) {
 		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
 			irq, ret);
@@ -364,7 +364,7 @@ static struct platform_driver atmel_isc_driver = {
 	.probe	= atmel_isc_probe,
 	.remove	= atmel_isc_remove,
 	.driver	= {
-		.name		= ATMEL_ISC_NAME,
+		.name		= "atmel-sama5d2-isc",
 		.pm		= &atmel_isc_dev_pm_ops,
 		.of_match_table = of_match_ptr(atmel_isc_of_match),
 	},
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:01 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:01 +0300
Subject: [PATCH v3 03/33] media: atmel: atmel-isc: add checks for limiting
 frame sizes
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-4-eugen.hristev@microchip.com>

When calling the subdev, certain subdev drivers will overwrite the
frame size and adding sizes which are beyond the ISC's capabilities.
Thus we need to ensure the frame size is cropped to the maximum caps.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 277a8fd8b83d..45fc8dbb7943 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1326,6 +1326,12 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
 	pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height;
@@ -1361,6 +1367,12 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 	if (ret < 0)
 		return ret;
 
+	/* Limit to Atmel ISC hardware capabilities */
+	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
+		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
+	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
+		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+
 	isc->fmt = *f;
 
 	if (isc->try_config.sd_format && isc->config.sd_format &&
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:02 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:02 +0300
Subject: [PATCH v3 04/33] media: atmel: atmel-isc: specialize max width and
 max height
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-5-eugen.hristev@microchip.com>

Move the max width and max height constants to the product specific driver
and have them in the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 28 +++++++++----------
 drivers/media/platform/atmel/atmel-isc.h      |  9 ++++--
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  7 +++--
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 45fc8dbb7943..350076dd029a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1204,8 +1204,8 @@ static void isc_try_fse(struct isc_device *isc,
 	 * just use the maximum ISC can receive.
 	 */
 	if (ret) {
-		pad_cfg->try_crop.width = ISC_MAX_SUPPORT_WIDTH;
-		pad_cfg->try_crop.height = ISC_MAX_SUPPORT_HEIGHT;
+		pad_cfg->try_crop.width = isc->max_width;
+		pad_cfg->try_crop.height = isc->max_height;
 	} else {
 		pad_cfg->try_crop.width = fse.max_width;
 		pad_cfg->try_crop.height = fse.max_height;
@@ -1282,10 +1282,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	isc->try_config.sd_format = sd_fmt;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	/*
 	 * The mbus format is the one the subdev outputs.
@@ -1327,10 +1327,10 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
 	v4l2_fill_pix_format(pixfmt, &format.format);
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (pixfmt->width > isc->max_width)
+		pixfmt->width = isc->max_width;
+	if (pixfmt->height > isc->max_height)
+		pixfmt->height = isc->max_height;
 
 	pixfmt->field = V4L2_FIELD_NONE;
 	pixfmt->bytesperline = (pixfmt->width * isc->try_config.bpp) >> 3;
@@ -1368,10 +1368,10 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
 		return ret;
 
 	/* Limit to Atmel ISC hardware capabilities */
-	if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
-		pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
-	if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
-		pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
+	if (f->fmt.pix.width > isc->max_width)
+		f->fmt.pix.width = isc->max_width;
+	if (f->fmt.pix.height > isc->max_height)
+		f->fmt.pix.height = isc->max_height;
 
 	isc->fmt = *f;
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 8d81d9967ad2..6becc6c3aaf0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -10,9 +10,6 @@
  */
 #ifndef _ATMEL_ISC_H_
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
-
 #define ISC_CLK_MAX_DIV		255
 
 enum isc_clk_id {
@@ -191,6 +188,9 @@ struct isc_ctrls {
  * @gamma_table:	pointer to the table with gamma values, has
  *			gamma_max sets of GAMMA_ENTRIES entries each
  * @gamma_max:		maximum number of sets of inside the gamma_table
+ *
+ * @max_width:		maximum frame width, dependent on the internal RAM
+ * @max_height:		maximum frame height, dependent on the internal RAM
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -254,6 +254,9 @@ struct isc_device {
 	/* pointer to the defined gamma table */
 	const u32	(*gamma_table)[GAMMA_ENTRIES];
 	u32		gamma_max;
+
+	u32		max_width;
+	u32		max_height;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f45d8b96bfb8..f8d1c8ba99b3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -49,8 +49,8 @@
 #include "atmel-isc-regs.h"
 #include "atmel-isc.h"
 
-#define ISC_MAX_SUPPORT_WIDTH   2592
-#define ISC_MAX_SUPPORT_HEIGHT  1944
+#define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
+#define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
 #define ISC_CLK_MAX_DIV		255
 
@@ -195,6 +195,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->gamma_table = isc_sama5d2_gamma_table;
 	isc->gamma_max = 2;
 
+	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:03 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:03 +0300
Subject: [PATCH v3 05/33] media: atmel: atmel-isc: specialize dma cfg
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-6-eugen.hristev@microchip.com>

The dma configuration (DCFG) is specific to the product.
Move this configuration in the product specific driver, and add the
field inside the driver struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 +--
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 3 +++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 350076dd029a..ff40ee2e2759 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -716,8 +716,7 @@ static int isc_configure(struct isc_device *isc)
 	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
-	dcfg = isc->config.dcfg_imode |
-		       ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+	dcfg = isc->config.dcfg_imode | isc->dcfg;
 
 	pfe_cfg0  |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 6becc6c3aaf0..d14ae096fbf6 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,6 +150,7 @@ struct isc_ctrls {
  * @hclock:		Hclock clock input (refer datasheet)
  * @ispck:		iscpck clock (refer datasheet)
  * @isc_clks:		ISC clocks
+ * @dcfg:		DMA master configuration, architecture dependent
  *
  * @dev:		Registered device driver
  * @v4l2_dev:		v4l2 registered device
@@ -197,6 +198,7 @@ struct isc_device {
 	struct clk		*hclock;
 	struct clk		*ispck;
 	struct isc_clk		isc_clks[2];
+	u32			dcfg;
 
 	struct device		*dev;
 	struct v4l2_device	v4l2_dev;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f8d1c8ba99b3..6d9942dcd7c1 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -198,6 +198,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	/* sama5d2-isc - 8 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
+
 	ret = isc_pipeline_init(isc);
 	if (ret)
 		return ret;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:04 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:04 +0300
Subject: [PATCH v3 06/33] media: atmel: atmel-isc: extract CSC submodule
 config into separate function
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-7-eugen.hristev@microchip.com>

The CSC submodule is a part of the atmel-isc pipeline, and stands for
Color Space Conversion. It is used to apply a matrix transformation to
RGB pixels to convert them to the YUV components.
The CSC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added explanation regarding CSC acronym
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c   |  8 +-------
 drivers/media/platform/atmel/atmel-isc.h        |  7 +++++++
 .../media/platform/atmel/atmel-sama5d2-isc.c    | 17 +++++++++++++++++
 3 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index ff40ee2e2759..31f63ba90c71 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -646,13 +646,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
-	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	isc->config_csc(isc);
 
 	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
 	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d14ae096fbf6..bb0b4419deff 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -192,6 +192,9 @@ struct isc_ctrls {
  *
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
+ *
+ * @config_csc:		pointer to a function that initializes product
+ *			specific CSC module
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -259,6 +262,10 @@ struct isc_device {
 
 	u32		max_width;
 	u32		max_height;
+
+	struct {
+		void (*config_csc)(struct isc_device *isc);
+	};
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 6d9942dcd7c1..f041bd75090e 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,6 +54,21 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+void isc_sama5d2_config_csc(struct isc_device *isc);
+
+void isc_sama5d2_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -198,6 +213,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_csc = isc_sama5d2_config_csc;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:05 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:05 +0300
Subject: [PATCH v3 07/33] media: atmel: atmel-isc-base: add id to clock debug
 message
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-8-eugen.hristev@microchip.com>

Add the clock id to the debug message regarding clock setup

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 31f63ba90c71..bc036e8ac4fe 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -277,8 +277,8 @@ static int isc_clk_enable(struct clk_hw *hw)
 	unsigned long flags;
 	unsigned int status;
 
-	dev_dbg(isc_clk->dev, "ISC CLK: %s, div = %d, parent id = %d\n",
-		__func__, isc_clk->div, isc_clk->parent_id);
+	dev_dbg(isc_clk->dev, "ISC CLK: %s, id = %d, div = %d, parent id = %d\n",
+		__func__, id, isc_clk->div, isc_clk->parent_id);
 
 	spin_lock_irqsave(&isc_clk->lock, flags);
 	regmap_update_bits(regmap, ISC_CLKCFG,
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:06 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:06 +0300
Subject: [PATCH v3 08/33] media: atmel: atmel-isc: create register offsets
 struct
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-9-eugen.hristev@microchip.com>

Create a struct that holds register offsets that are product specific.
Add initially the CSC register.
This allows each product that contains a variant of the ISC to add their
own register offset.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c |  2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      | 12 +++++++++++
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 20 +++++++++++++------
 4 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bc036e8ac4fe..019d931d1367 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,7 +2311,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
-		REG_FIELD(ISC_CSC_CTRL, 0, 0),
+		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index f1e160ed4351..5a65600c5f88 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -153,6 +153,9 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* Offset for CSC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CSC_OFFSET	0
+
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index bb0b4419deff..ef3a0451192d 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -144,6 +144,14 @@ struct isc_ctrls {
 
 #define ISC_PIPE_LINE_NODE_NUM	11
 
+/*
+ * struct isc_reg_offsets - ISC device register offsets
+ * @csc:		Offset for the CSC register
+ */
+struct isc_reg_offsets {
+	u32 csc;
+};
+
 /*
  * struct isc_device - ISC device driver data/config struct
  * @regmap:		Register map
@@ -195,6 +203,8 @@ struct isc_ctrls {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ *
+ * @offsets:		struct holding the product specific register offsets
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -266,6 +276,8 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 	};
+
+	struct isc_reg_offsets		offsets;
 };
 
 extern struct isc_format formats_list[];
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index f041bd75090e..9e557d17e731 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -61,12 +61,18 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 	struct regmap *regmap = isc->regmap;
 
 	/* Convert RGB to YUV */
-	regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
-	regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
-	regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
-	regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
-	regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
-	regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -215,6 +221,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 
+	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:07 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:07 +0300
Subject: [PATCH v3 09/33] media: atmel: atmel-isc: extract CBC submodule
 config into separate function
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-10-eugen.hristev@microchip.com>

The CBC submodule is a part of the atmel-isc pipeline, and stands for
Contrast Brightness Control. It is used to apply gains and offsets to the
luma (Y) and chroma (U, V) components of the YUV elements.
The CBC submodule should be initialized in the product specific driver
as it's product specific. Other products can implement it differently

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description explanation
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  4 +---
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 10 ++++++++++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 019d931d1367..446fe232956b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -647,9 +647,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
 	isc->config_csc(isc);
-
-	regmap_write(regmap, ISC_CBC_BRIGHT, ctrls->brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, ctrls->contrast);
+	isc->config_cbc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index ef3a0451192d..cb47932197b1 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -203,6 +203,8 @@ struct isc_reg_offsets {
  *
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
+ * @config_cbc:		pointer to a function that initializes product
+ *			specific CBC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -275,6 +277,7 @@ struct isc_device {
 
 	struct {
 		void (*config_csc)(struct isc_device *isc);
+		void (*config_cbc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 9e557d17e731..66b92fa1c752 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -55,6 +55,7 @@
 #define ISC_CLK_MAX_DIV		255
 
 void isc_sama5d2_config_csc(struct isc_device *isc);
+void isc_sama5d2_config_cbc(struct isc_device *isc);
 
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
@@ -75,6 +76,14 @@ void isc_sama5d2_config_csc(struct isc_device *isc)
 		     0xFEE | (0x80 << 16));
 }
 
+void isc_sama5d2_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -220,6 +229,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
 	isc->config_csc = isc_sama5d2_config_csc;
+	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:08 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:08 +0300
Subject: [PATCH v3 10/33] media: atmel: atmel-isc: add CBC to the reg offsets
 struct
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-11-eugen.hristev@microchip.com>

The CBC submodule is a part of the atmel-isc pipeline, and stands for
Contrast Brightness Control. It is used to apply gains and offsets to the
luma (Y) and chroma (U, V) components of the YUV elements.
Add cbc to the reg offsets struct. This will allow different products
to have a different reg offset for this particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- add module explanation in commit message

 drivers/media/platform/atmel/atmel-isc-base.c    | 2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 3 +++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++--
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 446fe232956b..d4bf7fd5929f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2310,7 +2310,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
-		REG_FIELD(ISC_CBC_CTRL, 0, 0),
+		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
 		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
 	};
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5a65600c5f88..a5e2fe01ba9f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -177,6 +177,9 @@
 /* Color Space Conversion CRB OCR Register */
 #define ISC_CSC_CRB_OCR	0x000003b0
 
+/* Offset for CBC register specific to sama5d2 product */
+#define ISC_SAMA5D2_CBC_OFFSET	0
+
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index cb47932197b1..b1fe93c93c61 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -147,9 +147,11 @@ struct isc_ctrls {
 /*
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
+ * @cbc:		Offset for the CBC register
  */
 struct isc_reg_offsets {
 	u32 csc;
+	u32 cbc;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 66b92fa1c752..c3037244e01e 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -80,8 +80,10 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
 
-	regmap_write(regmap, ISC_CBC_BRIGHT, isc->ctrls.brightness);
-	regmap_write(regmap, ISC_CBC_CONTRAST, isc->ctrls.contrast);
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc,
+		     isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc,
+		     isc->ctrls.contrast);
 }
 
 /* Gamma table with gamma 1/2.2 */
@@ -232,6 +234,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:09 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:09 +0300
Subject: [PATCH v3 11/33] media: atmel: atmel-isc: add SUB422 and SUB420 to
 register offsets
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-12-eugen.hristev@microchip.com>

The SUB submodules are a part of the atmel-isc pipeline, and stand for
Subsampling. They are used to subsample the original YUV 4:4:4 pixel ratio
aspect to either 4:2:2 or 4:2:0.
Add sub420 and sub422 to the reg offsets struct.
This will allow different products to have a different reg offset for these
particular modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- add module explanation in commit message

 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 4 ++++
 drivers/media/platform/atmel/atmel-isc.h         | 4 ++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 ++
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index d4bf7fd5929f..b2067d75499b 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2311,8 +2311,8 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
-		REG_FIELD(ISC_SUB422_CTRL, 0, 0),
-		REG_FIELD(ISC_SUB420_CTRL, 0, 0),
+		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
+		REG_FIELD(ISC_SUB420_CTRL + isc->offsets.sub420, 0, 0),
 	};
 
 	for (i = 0; i < ISC_PIPE_LINE_NODE_NUM; i++) {
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a5e2fe01ba9f..04839def6ef6 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -194,9 +194,13 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Offset for SUB422 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB422_OFFSET	0
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
+/* Offset for SUB420 register specific to sama5d2 product */
+#define ISC_SAMA5D2_SUB420_OFFSET	0
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b1fe93c93c61..fb7257872e7c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -148,10 +148,14 @@ struct isc_ctrls {
  * struct isc_reg_offsets - ISC device register offsets
  * @csc:		Offset for the CSC register
  * @cbc:		Offset for the CBC register
+ * @sub422:		Offset for the SUB422 register
+ * @sub420:		Offset for the SUB420 register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
+	u32 sub422;
+	u32 sub420;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index c3037244e01e..943793fbc791 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -235,6 +235,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:10 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:10 +0300
Subject: [PATCH v3 12/33] media: atmel: atmel-isc: add RLP to register offsets
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-13-eugen.hristev@microchip.com>

The RLP submodule is a part of the atmel-isc pipeline, and stands for
Rounding,Limiting and Packaging. It used to extract specific data from the
ISC pipeline. For example if we want to output greyscale 8 bit, we would
use limiting to 8 bits, and packaging to Luma component only.
Add rlp to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- add module description in commit message

 drivers/media/platform/atmel/atmel-isc-base.c    | 4 ++--
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index b2067d75499b..317172959370 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -718,8 +718,8 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG, ISC_RLP_CFG_MODE_MASK,
-			   rlp_mode);
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
 	regmap_write(regmap, ISC_DCFG, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 04839def6ef6..2205484e04fc 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -204,6 +204,8 @@
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
+/* Offset for RLP register specific to sama5d2 product */
+#define ISC_SAMA5D2_RLP_OFFSET	0
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index fb7257872e7c..b7d4e7fab570 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -150,12 +150,14 @@ struct isc_ctrls {
  * @cbc:		Offset for the CBC register
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
+ * @rlp:		Offset for the RLP register
  */
 struct isc_reg_offsets {
 	u32 csc;
 	u32 cbc;
 	u32 sub422;
 	u32 sub420;
+	u32 rlp;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 943793fbc791..dd3f8e50a8d4 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -237,6 +237,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:11 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:11 +0300
Subject: [PATCH v3 13/33] media: atmel: atmel-isc: add HIS to register offsets
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-14-eugen.hristev@microchip.com>

The HIS submodule is a part of the atmel-isc pipeline, and stands for
Histogram. This module performs a color histogram that can be read and used
by the main processor.
Add his to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description in commit message

 drivers/media/platform/atmel/atmel-isc-base.c    | 11 +++++++----
 drivers/media/platform/atmel/atmel-isc-regs.h    |  2 ++
 drivers/media/platform/atmel/atmel-isc.h         |  2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c |  1 +
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 317172959370..aa7a9a7ca0e6 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -678,12 +678,13 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 	struct isc_ctrls *ctrls = &isc->ctrls;
 
 	if (enable) {
-		regmap_write(regmap, ISC_HIS_CFG,
+		regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
 			     ISC_HIS_CFG_MODE_GR |
 			     (isc->config.sd_format->cfa_baycfg
 					<< ISC_HIS_CFG_BAYSEL_SHIFT) |
 					ISC_HIS_CFG_RAR);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_EN);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_EN);
 		regmap_write(regmap, ISC_INTEN, ISC_INT_HISDONE);
 		ctrls->hist_id = ISC_HIS_CFG_MODE_GR;
 		isc_update_profile(isc);
@@ -692,7 +693,8 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 		ctrls->hist_stat = HIST_ENABLED;
 	} else {
 		regmap_write(regmap, ISC_INTDIS, ISC_INT_HISDONE);
-		regmap_write(regmap, ISC_HIS_CTRL, ISC_HIS_CTRL_DIS);
+		regmap_write(regmap, ISC_HIS_CTRL + isc->offsets.his,
+			     ISC_HIS_CTRL_DIS);
 
 		ctrls->hist_stat = HIST_DISABLED;
 	}
@@ -1821,7 +1823,8 @@ static void isc_awb_work(struct work_struct *w)
 			ctrls->awb = ISC_WB_NONE;
 		}
 	}
-	regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
+	regmap_write(regmap, ISC_HIS_CFG + isc->offsets.his,
+		     hist_id | baysel | ISC_HIS_CFG_RAR);
 	isc_update_profile(isc);
 	/* if awb has been disabled, we don't need to start another histogram */
 	if (ctrls->awb)
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 2205484e04fc..0ab280ab59ec 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -224,6 +224,8 @@
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+/* Offset for HIS register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index b7d4e7fab570..652285dc9f52 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -151,6 +151,7 @@ struct isc_ctrls {
  * @sub422:		Offset for the SUB422 register
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
+ * @his:		Offset for the HIS related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -158,6 +159,7 @@ struct isc_reg_offsets {
 	u32 sub422;
 	u32 sub420;
 	u32 rlp;
+	u32 his;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index dd3f8e50a8d4..914de4ed63f3 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -238,6 +238,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:13 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:13 +0300
Subject: [PATCH v3 15/33] media: atmel: atmel-isc: add support for version
 register
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-16-eugen.hristev@microchip.com>

Add support for version register and print it at probe time.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h    | 5 +++++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 5 +++++
 3 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 4940998c82a2..344668dcfcf4 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -295,6 +295,11 @@
 /* DMA Address 2 Register */
 #define ISC_DAD2        0x000003fc
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_VERSION_OFFSET	0
+/* Version Register */
+#define ISC_VERSION	0x0000040c
+
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 52a9199d65ee..676a5be1ee8c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -153,6 +153,7 @@ struct isc_ctrls {
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
+ * @version:		Offset for the version register
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -162,6 +163,7 @@ struct isc_reg_offsets {
 	u32 rlp;
 	u32 his;
 	u32 dma;
+	u32 version;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 12f56a71db40..10b70d4b04c4 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -192,6 +192,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	struct isc_subdev_entity *subdev_entity;
 	int irq;
 	int ret;
+	u32 ver;
 
 	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
 	if (!isc)
@@ -240,6 +241,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
@@ -335,6 +337,9 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	pm_runtime_enable(dev);
 	pm_request_idle(dev);
 
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip ISC version %x\n", ver);
+
 	return 0;
 
 cleanup_subdev:
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:12 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:12 +0300
Subject: [PATCH v3 14/33] media: atmel: atmel-isc: add DMA to register offsets
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-15-eugen.hristev@microchip.com>

The DMA submodule is a part of the atmel-isc pipeline, and stands for
Direct Memory Access. It acts like a master on the AXI bus of the SoC, and
can directly write the RAM area with the pixel data from the ISC internal
sram.
Add dma to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module explanation in commit message

 drivers/media/platform/atmel/atmel-isc-base.c | 19 ++++++++++++-------
 drivers/media/platform/atmel/atmel-isc-regs.h |  3 +++
 drivers/media/platform/atmel/atmel-isc.h      |  2 ++
 .../media/platform/atmel/atmel-sama5d2-isc.c  |  1 +
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index aa7a9a7ca0e6..11121943d2cb 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -593,16 +593,20 @@ static void isc_start_dma(struct isc_device *isc)
 			   ISC_PFE_CFG0_COLEN | ISC_PFE_CFG0_ROWEN);
 
 	addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
-	regmap_write(regmap, ISC_DAD0, addr0);
+	regmap_write(regmap, ISC_DAD0 + isc->offsets.dma, addr0);
 
 	switch (isc->config.fourcc) {
 	case V4L2_PIX_FMT_YUV420:
-		regmap_write(regmap, ISC_DAD1, addr0 + (sizeimage * 2) / 3);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 5) / 6);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + (sizeimage * 2) / 3);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 5) / 6);
 		break;
 	case V4L2_PIX_FMT_YUV422P:
-		regmap_write(regmap, ISC_DAD1, addr0 + sizeimage / 2);
-		regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage * 3) / 4);
+		regmap_write(regmap, ISC_DAD1 + isc->offsets.dma,
+			     addr0 + sizeimage / 2);
+		regmap_write(regmap, ISC_DAD2 + isc->offsets.dma,
+			     addr0 + (sizeimage * 3) / 4);
 		break;
 	default:
 		break;
@@ -610,7 +614,8 @@ static void isc_start_dma(struct isc_device *isc)
 
 	dctrl_dview = isc->config.dctrl_dview;
 
-	regmap_write(regmap, ISC_DCTRL, dctrl_dview | ISC_DCTRL_IE_IS);
+	regmap_write(regmap, ISC_DCTRL + isc->offsets.dma,
+		     dctrl_dview | ISC_DCTRL_IE_IS);
 	spin_lock(&isc->awb_lock);
 	regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_CAPTURE);
 	spin_unlock(&isc->awb_lock);
@@ -723,7 +728,7 @@ static int isc_configure(struct isc_device *isc)
 	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 
-	regmap_write(regmap, ISC_DCFG, dcfg);
+	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
 	/* Set the pipeline */
 	isc_set_pipeline(isc, pipeline);
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 0ab280ab59ec..4940998c82a2 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -247,6 +247,9 @@
 
 #define ISC_HIS_CFG_RAR			BIT(8)
 
+/* Offset for DMA register specific to sama5d2 product */
+#define ISC_SAMA5D2_DMA_OFFSET	0
+
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
 #define ISC_DCFG_IMODE_PACKED8          0x0
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 652285dc9f52..52a9199d65ee 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -152,6 +152,7 @@ struct isc_ctrls {
  * @sub420:		Offset for the SUB420 register
  * @rlp:		Offset for the RLP register
  * @his:		Offset for the HIS related registers
+ * @dma:		Offset for the DMA related registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -160,6 +161,7 @@ struct isc_reg_offsets {
 	u32 sub420;
 	u32 rlp;
 	u32 his;
+	u32 dma;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 914de4ed63f3..12f56a71db40 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -239,6 +239,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.sub420 = ISC_SAMA5D2_SUB420_OFFSET;
 	isc->offsets.rlp = ISC_SAMA5D2_RLP_OFFSET;
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:14 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:14 +0300
Subject: [PATCH v3 16/33] media: atmel: atmel-isc: add his_entry to register
 offsets
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-17-eugen.hristev@microchip.com>

Add his_entry to the reg offsets struct.
This will allow different products to have a different reg offset for this
particular module.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    | 3 ++-
 drivers/media/platform/atmel/atmel-isc-regs.h    | 2 ++
 drivers/media/platform/atmel/atmel-isc.h         | 2 ++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 11121943d2cb..2a619eef6aa3 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1672,7 +1672,8 @@ static void isc_hist_count(struct isc_device *isc, u32 *min, u32 *max)
 	*min = 0;
 	*max = HIST_ENTRIES;
 
-	regmap_bulk_read(regmap, ISC_HIS_ENTRY, hist_entry, HIST_ENTRIES);
+	regmap_bulk_read(regmap, ISC_HIS_ENTRY + isc->offsets.his_entry,
+			 hist_entry, HIST_ENTRIES);
 
 	*hist_count = 0;
 	/*
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 344668dcfcf4..a15c13e1a833 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -300,6 +300,8 @@
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
+/* Offset for version register specific to sama5d2 product */
+#define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 676a5be1ee8c..c5d956fd20a0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -154,6 +154,7 @@ struct isc_ctrls {
  * @his:		Offset for the HIS related registers
  * @dma:		Offset for the DMA related registers
  * @version:		Offset for the version register
+ * @his_entry:		Offset for the HIS entries registers
  */
 struct isc_reg_offsets {
 	u32 csc;
@@ -164,6 +165,7 @@ struct isc_reg_offsets {
 	u32 his;
 	u32 dma;
 	u32 version;
+	u32 his_entry;
 };
 
 /*
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 10b70d4b04c4..0ff13198d732 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -242,6 +242,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.his = ISC_SAMA5D2_HIS_OFFSET;
 	isc->offsets.dma = ISC_SAMA5D2_DMA_OFFSET;
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:15 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:15 +0300
Subject: [PATCH v3 17/33] media: atmel: atmel-isc: add register description
 for additional modules
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-18-eugen.hristev@microchip.com>

Add register description for additional pipeline modules: the
Defective Pixel Correction (DPC) and the Vertical and Horizontal Scaler(VHXS)

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 67 +++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index a15c13e1a833..457eed74cda9 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -90,6 +90,46 @@
 #define ISC_INT_DDONE		BIT(8)
 #define ISC_INT_HISDONE		BIT(12)
 
+/* ISC DPC Control Register */
+#define ISC_DPC_CTRL	0x40
+
+#define ISC_DPC_CTRL_DPCEN	BIT(0)
+#define ISC_DPC_CTRL_GDCEN	BIT(1)
+#define ISC_DPC_CTRL_BLCEN	BIT(2)
+
+/* ISC DPC Config Register */
+#define ISC_DPC_CFG	0x44
+
+#define ISC_DPC_CFG_BAYSEL_SHIFT	0
+
+#define ISC_DPC_CFG_EITPOL		BIT(4)
+
+#define ISC_DPC_CFG_TA_ENABLE		BIT(14)
+#define ISC_DPC_CFG_TC_ENABLE		BIT(13)
+#define ISC_DPC_CFG_TM_ENABLE		BIT(12)
+
+#define ISC_DPC_CFG_RE_MODE		BIT(17)
+
+#define ISC_DPC_CFG_GDCCLP_SHIFT	20
+#define ISC_DPC_CFG_GDCCLP_MASK		GENMASK(22, 20)
+
+#define ISC_DPC_CFG_BLOFF_SHIFT		24
+#define ISC_DPC_CFG_BLOFF_MASK		GENMASK(31, 24)
+
+#define ISC_DPC_CFG_BAYCFG_SHIFT	0
+#define ISC_DPC_CFG_BAYCFG_MASK		GENMASK(1, 0)
+/* ISC DPC Threshold Median Register */
+#define ISC_DPC_THRESHM	0x48
+
+/* ISC DPC Threshold Closest Register */
+#define ISC_DPC_THRESHC	0x4C
+
+/* ISC DPC Threshold Average Register */
+#define ISC_DPC_THRESHA	0x50
+
+/* ISC DPC STatus Register */
+#define ISC_DPC_SR	0x54
+
 /* ISC White Balance Control Register */
 #define ISC_WB_CTRL     0x00000058
 
@@ -153,6 +193,33 @@
 /* ISC_Gamma Correction Green Entry Register */
 #define ISC_GAM_RENTRY	0x00000298
 
+/* ISC VHXS Control Register */
+#define ISC_VHXS_CTRL	0x398
+
+/* ISC VHXS Source Size Register */
+#define ISC_VHXS_SS	0x39C
+
+/* ISC VHXS Destination Size Register */
+#define ISC_VHXS_DS	0x3A0
+
+/* ISC Vertical Factor Register */
+#define ISC_VXS_FACT	0x3a4
+
+/* ISC Horizontal Factor Register */
+#define ISC_HXS_FACT	0x3a8
+
+/* ISC Vertical Config Register */
+#define ISC_VXS_CFG	0x3ac
+
+/* ISC Horizontal Config Register */
+#define ISC_HXS_CFG	0x3b0
+
+/* ISC Vertical Tap Register */
+#define ISC_VXS_TAP	0x3b4
+
+/* ISC Horizontal Tap Register */
+#define ISC_HXS_TAP	0x434
+
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
 
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:16 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:16 +0300
Subject: [PATCH v3 18/33] media: atmel: atmel-isc: extend pipeline with extra
 modules
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-19-eugen.hristev@microchip.com>

Newer ISC pipelines have the additional modules of
Defective Pixel Correction -> DPC itself,
Defective Pixel Correction -> Green Disparity Correction (DPC_GDC)
Defective Pixel Correction -> Black Level Correction (DPC_BLC)
Vertical and Horizontal Scaler -> VHXS

Some products have this full pipeline (sama7g5), other products do not (sama5d2)

Add the modules to the isc base, and also extend the register range to include
the modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 11 ++++++--
 drivers/media/platform/atmel/atmel-isc.h      | 28 +++++++++++--------
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 2a619eef6aa3..66005cb3940f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2309,8 +2309,14 @@ int isc_pipeline_init(struct isc_device *isc)
 	struct regmap_field *regs;
 	unsigned int i;
 
-	/* WB-->CFA-->CC-->GAM-->CSC-->CBC-->SUB422-->SUB420 */
+	/*
+	 * DPCEN-->GDCEN-->BLCEN-->WB-->CFA-->CC-->
+	 * GAM-->VHXS-->CSC-->CBC-->SUB422-->SUB420
+	 */
 	const struct reg_field regfields[ISC_PIPE_LINE_NODE_NUM] = {
+		REG_FIELD(ISC_DPC_CTRL, 0, 0),
+		REG_FIELD(ISC_DPC_CTRL, 1, 1),
+		REG_FIELD(ISC_DPC_CTRL, 2, 2),
 		REG_FIELD(ISC_WB_CTRL, 0, 0),
 		REG_FIELD(ISC_CFA_CTRL, 0, 0),
 		REG_FIELD(ISC_CC_CTRL, 0, 0),
@@ -2318,6 +2324,7 @@ int isc_pipeline_init(struct isc_device *isc)
 		REG_FIELD(ISC_GAM_CTRL, 1, 1),
 		REG_FIELD(ISC_GAM_CTRL, 2, 2),
 		REG_FIELD(ISC_GAM_CTRL, 3, 3),
+		REG_FIELD(ISC_VHXS_CTRL, 0, 0),
 		REG_FIELD(ISC_CSC_CTRL + isc->offsets.csc, 0, 0),
 		REG_FIELD(ISC_CBC_CTRL + isc->offsets.cbc, 0, 0),
 		REG_FIELD(ISC_SUB422_CTRL + isc->offsets.sub422, 0, 0),
@@ -2336,7 +2343,7 @@ int isc_pipeline_init(struct isc_device *isc)
 }
 
 /* regmap configuration */
-#define ATMEL_ISC_REG_MAX    0xbfc
+#define ATMEL_ISC_REG_MAX    0xd5c
 const struct regmap_config isc_regmap_config = {
 	.reg_bits       = 32,
 	.reg_stride     = 4,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index c5d956fd20a0..f574bcc3ba67 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -68,17 +68,21 @@ struct isc_format {
 };
 
 /* Pipeline bitmap */
-#define WB_ENABLE	BIT(0)
-#define CFA_ENABLE	BIT(1)
-#define CC_ENABLE	BIT(2)
-#define GAM_ENABLE	BIT(3)
-#define GAM_BENABLE	BIT(4)
-#define GAM_GENABLE	BIT(5)
-#define GAM_RENABLE	BIT(6)
-#define CSC_ENABLE	BIT(7)
-#define CBC_ENABLE	BIT(8)
-#define SUB422_ENABLE	BIT(9)
-#define SUB420_ENABLE	BIT(10)
+#define DPC_DPCENABLE	BIT(0)
+#define DPC_GDCENABLE	BIT(1)
+#define DPC_BLCENABLE	BIT(2)
+#define WB_ENABLE	BIT(3)
+#define CFA_ENABLE	BIT(4)
+#define CC_ENABLE	BIT(5)
+#define GAM_ENABLE	BIT(6)
+#define GAM_BENABLE	BIT(7)
+#define GAM_GENABLE	BIT(8)
+#define GAM_RENABLE	BIT(9)
+#define VHXS_ENABLE	BIT(10)
+#define CSC_ENABLE	BIT(11)
+#define CBC_ENABLE	BIT(12)
+#define SUB422_ENABLE	BIT(13)
+#define SUB420_ENABLE	BIT(14)
 
 #define GAM_ENABLES	(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
 
@@ -142,7 +146,7 @@ struct isc_ctrls {
 	u32 hist_minmax[HIST_BAYER][2];
 };
 
-#define ISC_PIPE_LINE_NODE_NUM	11
+#define ISC_PIPE_LINE_NODE_NUM	15
 
 /*
  * struct isc_reg_offsets - ISC device register offsets
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:17 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:17 +0300
Subject: [PATCH v3 19/33] media: atmel: atmel-isc: add CC initialization
 function
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-20-eugen.hristev@microchip.com>

The CC submodule is a part of the atmel-isc pipeline, and stands for
Color Correction. It is used to apply gains and offsets to the
chroma (U, V) components of the YUV elements.
Implement the CC submodule initialization, as a product
specific function, which currently configures the neutral point in color
correction.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description in commit message
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  1 +
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 15 +++++++++++++++
 3 files changed, 19 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 66005cb3940f..182903803c05 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -653,6 +653,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
+	isc->config_cc(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index f574bcc3ba67..a5f8d5001381 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -225,6 +225,8 @@ struct isc_reg_offsets {
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
  *			specific CBC module
+ * @config_cc:		pointer to a function that initializes product
+ *			specific CC module
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -298,6 +300,7 @@ struct isc_device {
 	struct {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
+		void (*config_cc)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0ff13198d732..0ce8293622f9 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -56,6 +56,7 @@
 
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
+void isc_sama5d2_config_cc(struct isc_device *isc);
 
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
@@ -86,6 +87,19 @@ void isc_sama5d2_config_cbc(struct isc_device *isc)
 		     isc->ctrls.contrast);
 }
 
+void isc_sama5d2_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -233,6 +247,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
+	isc->config_cc = isc_sama5d2_config_cc;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:19 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:19 +0300
Subject: [PATCH v3 21/33] media: atmel: atmel-isc: create callback for DPC
 submodule product specific
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-22-eugen.hristev@microchip.com>

The DPC submodule is a part of the atmel-isc pipeline, and stands for
Defective Pixel Correction. Its purpose is to detect defective pixels and
correct them if possible with the help of adjacent pixels.
Create a product specific callback for initializing the DPC submodule
of the pipeline.
For sama5d2 product, this module does not exist, thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description in commit message
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++++
 3 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 69952b6ac401..1f7116abc61a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -651,6 +651,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
 	regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
 
+	isc->config_dpc(isc);
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index eb549fadb1a8..d6cd85a4c3e9 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -221,6 +221,8 @@ struct isc_reg_offsets {
  * @max_width:		maximum frame width, dependent on the internal RAM
  * @max_height:		maximum frame height, dependent on the internal RAM
  *
+ * @config_dpc:		pointer to a function that initializes product
+ *			specific DPC module
  * @config_csc:		pointer to a function that initializes product
  *			specific CSC module
  * @config_cbc:		pointer to a function that initializes product
@@ -300,6 +302,7 @@ struct isc_device {
 	u32		max_height;
 
 	struct {
+		void (*config_dpc)(struct isc_device *isc);
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 7ff8b362568d..2b53e9427353 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -57,6 +57,7 @@
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
+void isc_sama5d2_config_dpc(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -114,6 +115,11 @@ void isc_sama5d2_config_ctrls(struct isc_device *isc,
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 }
 
+void isc_sama5d2_config_dpc(struct isc_device *isc)
+{
+	/* This module is not present on sama5d2 pipeline */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -259,6 +265,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->max_width = ISC_SAMA5D2_MAX_SUPPORT_WIDTH;
 	isc->max_height = ISC_SAMA5D2_MAX_SUPPORT_HEIGHT;
 
+	isc->config_dpc = isc_sama5d2_config_dpc;
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:18 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:18 +0300
Subject: [PATCH v3 20/33] media: atmel: atmel-isc: create product specific
 v4l2 controls config
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-21-eugen.hristev@microchip.com>

Create product specific callback for initializing v4l2 controls.
Call this from v4l2 controls init function.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  5 +++--
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 15 +++++++++++++++
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 182903803c05..69952b6ac401 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -2036,11 +2036,12 @@ static int isc_ctrl_init(struct isc_device *isc)
 	if (ret < 0)
 		return ret;
 
+	/* Initialize product specific controls. For example, contrast */
+	isc->config_ctrls(isc, ops);
+
 	ctrls->brightness = 0;
-	ctrls->contrast = 256;
 
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
-	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
 	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, isc->gamma_max, 1,
 			  isc->gamma_max);
 	isc->awb_ctrl = v4l2_ctrl_new_std(hdl, &isc_awb_ops,
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index a5f8d5001381..eb549fadb1a8 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -227,6 +227,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_ctrls:	pointer to a functoin that initializes product
+ *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
  */
@@ -301,6 +303,9 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+
+		void (*config_ctrls)(struct isc_device *isc,
+				     const struct v4l2_ctrl_ops *ops);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 0ce8293622f9..7ff8b362568d 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -58,6 +58,9 @@ void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 
+void isc_sama5d2_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops);
+
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
@@ -100,6 +103,17 @@ void isc_sama5d2_config_cc(struct isc_device *isc)
 	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
 }
 
+void isc_sama5d2_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 256;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 256);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -248,6 +262,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:20 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:20 +0300
Subject: [PATCH v3 22/33] media: atmel: atmel-isc: create callback for GAM
 submodule product specific
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-23-eugen.hristev@microchip.com>

The GAM submodule is a part of the atmel-isc pipeline, and stands for
Gamma Correction. It is used to apply the gamma curve to the incoming pixels.
Create a product specific callback for initializing the GAM submodule
of the pipeline.
For sama5d2 product, there is no special configuration at this moment,
thus this function is a noop.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description in commit message
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    | 1 +
 drivers/media/platform/atmel/atmel-isc.h         | 3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 7 +++++++
 3 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 1f7116abc61a..bd24e0c99613 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -655,6 +655,7 @@ static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
 	isc->config_csc(isc);
 	isc->config_cbc(isc);
 	isc->config_cc(isc);
+	isc->config_gam(isc);
 }
 
 static int isc_update_profile(struct isc_device *isc)
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index d6cd85a4c3e9..1e6988f1876e 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -229,6 +229,8 @@ struct isc_reg_offsets {
  *			specific CBC module
  * @config_cc:		pointer to a function that initializes product
  *			specific CC module
+ * @config_gam:		pointer to a function that initializes product
+ *			specific GAMMA module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -306,6 +308,7 @@ struct isc_device {
 		void (*config_csc)(struct isc_device *isc);
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
+		void (*config_gam)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 2b53e9427353..df26941af64b 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -58,6 +58,7 @@ void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
+void isc_sama5d2_config_gam(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -120,6 +121,11 @@ void isc_sama5d2_config_dpc(struct isc_device *isc)
 	/* This module is not present on sama5d2 pipeline */
 }
 
+void isc_sama5d2_config_gam(struct isc_device *isc)
+{
+	/* No specific gamma configuration */
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -269,6 +275,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_csc = isc_sama5d2_config_csc;
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
+	isc->config_gam = isc_sama5d2_config_gam;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:21 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:21 +0300
Subject: [PATCH v3 23/33] media: atmel: atmel-isc: create callback for RLP
 submodule product specific
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-24-eugen.hristev@microchip.com>

The RLP submodule is a part of the atmel-isc pipeline, and stands for
Rounding,Limiting and Packaging. It used to extract specific data from the
ISC pipeline. For example if we want to output greyscale 8 bit, we would
use limiting to 8 bits, and packaging to Luma component only.

Create a product specific callback for initializing the RLP submodule
of the pipeline

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v3:
- added module description in commit message
Changes in v2:
- addded function prototype to avoid warning with W=1

 drivers/media/platform/atmel/atmel-isc-base.c    |  6 ++----
 drivers/media/platform/atmel/atmel-isc.h         |  3 +++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 11 +++++++++++
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index bd24e0c99613..8422df41f083 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -711,11 +711,10 @@ static void isc_set_histogram(struct isc_device *isc, bool enable)
 static int isc_configure(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
-	u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
+	u32 pfe_cfg0, dcfg, mask, pipeline;
 	struct isc_subdev_entity *subdev = isc->current_subdev;
 
 	pfe_cfg0 = isc->config.sd_format->pfe_cfg0_bps;
-	rlp_mode = isc->config.rlp_cfg_mode;
 	pipeline = isc->config.bits_pipeline;
 
 	dcfg = isc->config.dcfg_imode | isc->dcfg;
@@ -728,8 +727,7 @@ static int isc_configure(struct isc_device *isc)
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
-	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
-			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+	isc->config_rlp(isc);
 
 	regmap_write(regmap, ISC_DCFG + isc->offsets.dma, dcfg);
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 1e6988f1876e..abeef7b2ab27 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -231,6 +231,8 @@ struct isc_reg_offsets {
  *			specific CC module
  * @config_gam:		pointer to a function that initializes product
  *			specific GAMMA module
+ * @config_rlp:		pointer to a function that initializes product
+ *			specific RLP module
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
@@ -309,6 +311,7 @@ struct isc_device {
 		void (*config_cbc)(struct isc_device *isc);
 		void (*config_cc)(struct isc_device *isc);
 		void (*config_gam)(struct isc_device *isc);
+		void (*config_rlp)(struct isc_device *isc);
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index df26941af64b..855027821fba 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -59,6 +59,7 @@ void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
 void isc_sama5d2_config_gam(struct isc_device *isc);
+void isc_sama5d2_config_rlp(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -126,6 +127,15 @@ void isc_sama5d2_config_gam(struct isc_device *isc)
 	/* No specific gamma configuration */
 }
 
+void isc_sama5d2_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -276,6 +286,7 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_cbc = isc_sama5d2_config_cbc;
 	isc->config_cc = isc_sama5d2_config_cc;
 	isc->config_gam = isc_sama5d2_config_gam;
+	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
-- 
2.25.1



From broonie at kernel.org  Tue Apr 13 12:02:55 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 13 Apr 2021 12:02:55 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
 <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
Message-ID: <20210413110255.GB5586@sirena.org.uk>

On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote:

> 
> OK. Just so I am clear on the whole picture, let me state my understanding so far.
> Correct me if I am wrong.

> 1. We are hoping that we can convert a significant number of SYM_CODE functions to
>    SYM_FUNC functions by providing them with a proper FP prolog and epilog so that
>    we can get objtool coverage for them. These don't need any blacklisting.

I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC.  I'd
expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's
required to be non standard due to some external interface - things like
the exception vectors, ftrace, and stuff around suspend/hibernate.  A
quick grep seems to confirm this.

> 3. We are going to assume that the reliable unwinder is only for livepatch purposes
>    and will only be invoked on a task that is not currently running. The task either

The reliable unwinder can also be invoked on itself.

> 4. So, the only functions that will need blacklisting are the remaining SYM_CODE functions
>    that might give up the CPU voluntarily. At this point, I am not even sure how
>    many of these will exist. One hopes that all of these would have ended up as
>    SYM_FUNC functions in (1).

There's stuff like ret_from_fork there.

> I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the
> remaining ones to see which ones must be blacklisted, if any.

I'm not clear what the concrete steps you're planning to do first are
there - your 3 seems like a statement of assumptions.  For flagging
functions I do think it'd be safer to default to assuming that all
SYM_CODE functions can't be unwound reliably rather than only explicitly
listing ones that cause problems.
-------------- 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/20210413/6358baac/attachment-0001.sig>

From eugen.hristev at microchip.com  Tue Apr 13 11:57:23 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:23 +0300
Subject: [PATCH v3 25/33] media: atmel: atmel-isc: create an adapt pipeline
 callback for product specific
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-26-eugen.hristev@microchip.com>

Once the pipeline is set in the base code, create a callback that will adapt
the ISC pipeline to each product.
Create the adapt_pipeline callback that will be used in this fashion.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c    |  4 ++++
 drivers/media/platform/atmel/atmel-isc.h         |  5 +++++
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 12 ++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 6746c9060e3f..a3c299068bd5 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -1047,6 +1047,10 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 	default:
 		isc->try_config.bits_pipeline = 0x0;
 	}
+
+	/* Tune the pipeline to product specific */
+	isc->adapt_pipeline(isc);
+
 	return 0;
 }
 
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index 14e318a7373c..19cc60dfcbe0 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -236,6 +236,9 @@ struct isc_reg_offsets {
  * @config_ctrls:	pointer to a functoin that initializes product
  *			specific v4l2 controls.
  *
+ * @adapt_pipeline:	pointer to a function that adapts the pipeline bits
+ *			to the product specific pipeline
+ *
  * @offsets:		struct holding the product specific register offsets
  * @controller_formats:	pointer to the array of possible formats that the
  *			controller can output
@@ -321,6 +324,8 @@ struct isc_device {
 
 		void (*config_ctrls)(struct isc_device *isc,
 				     const struct v4l2_ctrl_ops *ops);
+
+		void (*adapt_pipeline)(struct isc_device *isc);
 	};
 
 	struct isc_reg_offsets		offsets;
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index a5823a3a6111..b2ace528b260 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -54,12 +54,17 @@
 
 #define ISC_CLK_MAX_DIV		255
 
+#define ISC_SAMA5D2_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
 void isc_sama5d2_config_csc(struct isc_device *isc);
 void isc_sama5d2_config_cbc(struct isc_device *isc);
 void isc_sama5d2_config_cc(struct isc_device *isc);
 void isc_sama5d2_config_dpc(struct isc_device *isc);
 void isc_sama5d2_config_gam(struct isc_device *isc);
 void isc_sama5d2_config_rlp(struct isc_device *isc);
+void isc_sama5d2_adapt_pipeline(struct isc_device *isc);
 
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
@@ -267,6 +272,11 @@ void isc_sama5d2_config_rlp(struct isc_device *isc)
 			   ISC_RLP_CFG_MODE_MASK, rlp_mode);
 }
 
+void isc_sama5d2_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA5D2_PIPELINE;
+}
+
 /* Gamma table with gamma 1/2.2 */
 const u32 isc_sama5d2_gamma_table[][GAMMA_ENTRIES] = {
 	/* 0 --> gamma 1/1.8 */
@@ -420,6 +430,8 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->config_rlp = isc_sama5d2_config_rlp;
 	isc->config_ctrls = isc_sama5d2_config_ctrls;
 
+	isc->adapt_pipeline = isc_sama5d2_adapt_pipeline;
+
 	isc->offsets.csc = ISC_SAMA5D2_CSC_OFFSET;
 	isc->offsets.cbc = ISC_SAMA5D2_CBC_OFFSET;
 	isc->offsets.sub422 = ISC_SAMA5D2_SUB422_OFFSET;
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:22 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:22 +0300
Subject: [PATCH v3 24/33] media: atmel: atmel-isc: move the formats list into
 product specific code
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-25-eugen.hristev@microchip.com>

The list of input and output formats has to be product specific.
Move this list into the product specific code.
Have pointers to these arrays inside the device struct.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 167 ++----------------
 drivers/media/platform/atmel/atmel-isc.h      |  12 +-
 .../media/platform/atmel/atmel-sama5d2-isc.c  | 136 ++++++++++++++
 3 files changed, 165 insertions(+), 150 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index 8422df41f083..6746c9060e3f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -45,137 +45,6 @@ module_param(sensor_preferred, uint, 0644);
 MODULE_PARM_DESC(sensor_preferred,
 		 "Sensor is preferred to output the specified format (1-on 0-off), default 1");
 
-/* This is a list of the formats that the ISC can *output* */
-const struct isc_format controller_formats[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB444,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ARGB555,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_ABGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_XBGR32,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV420,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUV422P,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-	},
-};
-
-/* This is a list of formats that the ISC can receive as *input* */
-struct isc_format formats_list[] = {
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR8,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG8,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB8,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR10,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG10,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB10,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SBGGR12,
-		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGBRG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SGRBG12,
-		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_SRGGB12,
-		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
-		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_GREY,
-		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_YUYV,
-		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_RGB565,
-		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
-		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
-	},
-	{
-		.fourcc		= V4L2_PIX_FMT_Y10,
-		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
-		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
-	},
-
-};
-
 #define ISC_IS_FORMAT_RAW(mbus_code) \
 	(((mbus_code) & 0xf000) == 0x3000)
 
@@ -906,25 +775,26 @@ static int isc_querycap(struct file *file, void *priv,
 static int isc_enum_fmt_vid_cap(struct file *file, void *priv,
 				 struct v4l2_fmtdesc *f)
 {
+	struct isc_device *isc = video_drvdata(file);
 	u32 index = f->index;
 	u32 i, supported_index;
 
-	if (index < ARRAY_SIZE(controller_formats)) {
-		f->pixelformat = controller_formats[index].fourcc;
+	if (index < isc->controller_formats_size) {
+		f->pixelformat = isc->controller_formats[index].fourcc;
 		return 0;
 	}
 
-	index -= ARRAY_SIZE(controller_formats);
+	index -= isc->controller_formats_size;
 
 	i = 0;
 	supported_index = 0;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
-		if (!ISC_IS_FORMAT_RAW(formats_list[i].mbus_code) ||
-		    !formats_list[i].sd_support)
+	for (i = 0; i < isc->formats_list_size; i++) {
+		if (!ISC_IS_FORMAT_RAW(isc->formats_list[i].mbus_code) ||
+		    !isc->formats_list[i].sd_support)
 			continue;
 		if (supported_index == index) {
-			f->pixelformat = formats_list[i].fourcc;
+			f->pixelformat = isc->formats_list[i].fourcc;
 			return 0;
 		}
 		supported_index++;
@@ -1465,8 +1335,8 @@ static int isc_enum_framesizes(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fsize->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fsize->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fsize->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -1502,8 +1372,8 @@ static int isc_enum_frameintervals(struct file *file, void *fh,
 		if (isc->user_formats[i]->fourcc == fival->pixel_format)
 			ret = 0;
 
-	for (i = 0; i < ARRAY_SIZE(controller_formats); i++)
-		if (controller_formats[i].fourcc == fival->pixel_format)
+	for (i = 0; i < isc->controller_formats_size; i++)
+		if (isc->controller_formats[i].fourcc == fival->pixel_format)
 			ret = 0;
 
 	if (ret)
@@ -2111,12 +1981,13 @@ static void isc_async_unbind(struct v4l2_async_notifier *notifier,
 	v4l2_ctrl_handler_free(&isc->ctrls.handler);
 }
 
-static struct isc_format *find_format_by_code(unsigned int code, int *index)
+static struct isc_format *find_format_by_code(struct isc_device *isc,
+					      unsigned int code, int *index)
 {
-	struct isc_format *fmt = &formats_list[0];
+	struct isc_format *fmt = &isc->formats_list[0];
 	unsigned int i;
 
-	for (i = 0; i < ARRAY_SIZE(formats_list); i++) {
+	for (i = 0; i < isc->formats_list_size; i++) {
 		if (fmt->mbus_code == code) {
 			*index = i;
 			return fmt;
@@ -2133,7 +2004,7 @@ static int isc_formats_init(struct isc_device *isc)
 	struct isc_format *fmt;
 	struct v4l2_subdev *subdev = isc->current_subdev->sd;
 	unsigned int num_fmts, i, j;
-	u32 list_size = ARRAY_SIZE(formats_list);
+	u32 list_size = isc->formats_list_size;
 	struct v4l2_subdev_mbus_code_enum mbus_code = {
 		.which = V4L2_SUBDEV_FORMAT_ACTIVE,
 	};
@@ -2143,7 +2014,7 @@ static int isc_formats_init(struct isc_device *isc)
 	       NULL, &mbus_code)) {
 		mbus_code.index++;
 
-		fmt = find_format_by_code(mbus_code.code, &i);
+		fmt = find_format_by_code(isc, mbus_code.code, &i);
 		if (!fmt) {
 			v4l2_warn(&isc->v4l2_dev, "Mbus code %x not supported\n",
 				  mbus_code.code);
@@ -2164,7 +2035,7 @@ static int isc_formats_init(struct isc_device *isc)
 	if (!isc->user_formats)
 		return -ENOMEM;
 
-	fmt = &formats_list[0];
+	fmt = &isc->formats_list[0];
 	for (i = 0, j = 0; i < list_size; i++) {
 		if (fmt->sd_support)
 			isc->user_formats[j++] = fmt;
diff --git a/drivers/media/platform/atmel/atmel-isc.h b/drivers/media/platform/atmel/atmel-isc.h
index abeef7b2ab27..14e318a7373c 100644
--- a/drivers/media/platform/atmel/atmel-isc.h
+++ b/drivers/media/platform/atmel/atmel-isc.h
@@ -237,6 +237,12 @@ struct isc_reg_offsets {
  *			specific v4l2 controls.
  *
  * @offsets:		struct holding the product specific register offsets
+ * @controller_formats:	pointer to the array of possible formats that the
+ *			controller can output
+ * @formats_list:	pointer to the array of possible formats that can
+ *			be used as an input to the controller
+ * @controller_formats_size:	size of controller_formats array
+ * @formats_list_size:	size of formats_list array
  */
 struct isc_device {
 	struct regmap		*regmap;
@@ -318,10 +324,12 @@ struct isc_device {
 	};
 
 	struct isc_reg_offsets		offsets;
+	const struct isc_format		*controller_formats;
+	struct isc_format		*formats_list;
+	u32				controller_formats_size;
+	u32				formats_list_size;
 };
 
-extern struct isc_format formats_list[];
-extern const struct isc_format controller_formats[];
 extern const struct regmap_config isc_regmap_config;
 extern const struct v4l2_async_notifier_operations isc_async_ops;
 
diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index 855027821fba..a5823a3a6111 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -64,6 +64,137 @@ void isc_sama5d2_config_rlp(struct isc_device *isc);
 void isc_sama5d2_config_ctrls(struct isc_device *isc,
 			      const struct v4l2_ctrl_ops *ops);
 
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama5d2_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama5d2_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
 void isc_sama5d2_config_csc(struct isc_device *isc)
 {
 	struct regmap *regmap = isc->regmap;
@@ -299,6 +430,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
 	isc->offsets.version = ISC_SAMA5D2_VERSION_OFFSET;
 	isc->offsets.his_entry = ISC_SAMA5D2_HIS_ENTRY_OFFSET;
 
+	isc->controller_formats = sama5d2_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama5d2_controller_formats);
+	isc->formats_list = sama5d2_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama5d2_formats_list);
+
 	/* sama5d2-isc - 8 bits per beat */
 	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS8 | ISC_DCFG_CMBSIZE_BEATS8;
 
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:24 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:24 +0300
Subject: [PATCH v3 26/33] media: atmel: atmel-isc-regs: add additional fields
 for sama7g5 type pipeline
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-27-eugen.hristev@microchip.com>

Add additional fields for registers present in sama7g5 type pipeline.
Extend register masks for additional bits in sama7g5 type pipeline registers.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-regs.h | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 457eed74cda9..5f99bf7717c1 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -289,8 +289,18 @@
 #define ISC_RLP_CFG_MODE_ARGB32         0xa
 #define ISC_RLP_CFG_MODE_YYCC           0xb
 #define ISC_RLP_CFG_MODE_YYCC_LIMITED   0xc
+#define ISC_RLP_CFG_MODE_YCYC           0xd
 #define ISC_RLP_CFG_MODE_MASK           GENMASK(3, 0)
 
+#define ISC_RLP_CFG_LSH			BIT(5)
+
+#define ISC_RLP_CFG_YMODE_YUYV		(3 << 6)
+#define ISC_RLP_CFG_YMODE_YVYU		(2 << 6)
+#define ISC_RLP_CFG_YMODE_VYUY		(0 << 6)
+#define ISC_RLP_CFG_YMODE_UYVY		(1 << 6)
+
+#define ISC_RLP_CFG_YMODE_MASK		GENMASK(7, 6)
+
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
 /* Histogram Control Register */
@@ -332,13 +342,15 @@
 #define ISC_DCFG_YMBSIZE_BEATS4         (0x1 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS8         (0x2 << 4)
 #define ISC_DCFG_YMBSIZE_BEATS16        (0x3 << 4)
-#define ISC_DCFG_YMBSIZE_MASK           GENMASK(5, 4)
+#define ISC_DCFG_YMBSIZE_BEATS32        (0x4 << 4)
+#define ISC_DCFG_YMBSIZE_MASK           GENMASK(6, 4)
 
 #define ISC_DCFG_CMBSIZE_SINGLE         (0x0 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS4         (0x1 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS8         (0x2 << 8)
 #define ISC_DCFG_CMBSIZE_BEATS16        (0x3 << 8)
-#define ISC_DCFG_CMBSIZE_MASK           GENMASK(9, 8)
+#define ISC_DCFG_CMBSIZE_BEATS32        (0x4 << 8)
+#define ISC_DCFG_CMBSIZE_MASK           GENMASK(10, 8)
 
 /* DMA Control Register */
 #define ISC_DCTRL       0x000003e4
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:27 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:27 +0300
Subject: [PATCH v3 29/33] dt-bindings: media: atmel-isc: convert to yaml
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-30-eugen.hristev@microchip.com>

Convert the Atmel ISC to yaml binding format.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 .../devicetree/bindings/media/atmel,isc.yaml  | 115 ++++++++++++++++++
 .../devicetree/bindings/media/atmel-isc.txt   |  65 ----------
 2 files changed, 115 insertions(+), 65 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml
 delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml
new file mode 100644
index 000000000000..6ef8b4102b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2016-2021 Microchip Technology, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/atmel,isc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Image Sensor Controller (ISC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev at microchip.com>
+
+description:
+  The Image Sensor Controller (ISC) device provides the video input capabilities for the
+  Atmel/Microchip AT91 SAMA family of devices.
+
+  The ISC has a single parallel input that supports RAW Bayer, RGB or YUV video,
+  with both external synchronization and BT.656 synchronization for the latter.
+
+properties:
+  compatible:
+    const: atmel,sama5d2-isc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    minItems: 3
+    maxItems: 3
+
+  clock-names:
+    items:
+      - const: hclock
+      - const: iscck
+      - const: gck
+
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    const: isc-mck
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      endpoint:
+        $ref: video-interfaces.yaml#
+
+        properties:
+          remote-endpoint: true
+
+          bus-width:
+            enum: [8, 9, 10, 11, 12]
+            default: 12
+
+          hsync-active:
+            enum: [0, 1]
+            default: 1
+
+          vsync-active:
+            enum: [0, 1]
+            default: 1
+
+          pclk-sample:
+            enum: [0, 1]
+            default: 1
+
+        required:
+          - remote-endpoint
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - clock-output-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    isc: isc at f0008000 {
+        compatible = "atmel,sama5d2-isc";
+        reg = <0xf0008000 0x4000>;
+        interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+        clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
+        clock-names = "hclock", "iscck", "gck";
+        #clock-cells = <0>;
+        clock-output-names = "isc-mck";
+
+        port {
+                isc_0: endpoint {
+                       remote-endpoint = <&ov7740_0>;
+                       hsync-active = <1>;
+                       vsync-active = <0>;
+                       pclk-sample = <1>;
+                       bus-width = <8>;
+                };
+        };
+    };
+
diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt b/Documentation/devicetree/bindings/media/atmel-isc.txt
deleted file mode 100644
index bbe0e87c6188..000000000000
--- a/Documentation/devicetree/bindings/media/atmel-isc.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Atmel Image Sensor Controller (ISC)
-----------------------------------------------
-
-Required properties for ISC:
-- compatible
-	Must be "atmel,sama5d2-isc".
-- reg
-	Physical base address and length of the registers set for the device.
-- interrupts
-	Should contain IRQ line for the ISC.
-- clocks
-	List of clock specifiers, corresponding to entries in
-	the clock-names property;
-	Please refer to clock-bindings.txt.
-- clock-names
-	Required elements: "hclock", "iscck", "gck".
-- #clock-cells
-	Should be 0.
-- clock-output-names
-	Should be "isc-mck".
-- pinctrl-names, pinctrl-0
-	Please refer to pinctrl-bindings.txt.
-
-ISC supports a single port node with parallel bus. It should contain one
-'port' child node with child 'endpoint' node. Please refer to the bindings
-defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-isc: isc at f0008000 {
-	compatible = "atmel,sama5d2-isc";
-	reg = <0xf0008000 0x4000>;
-	interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
-	clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
-	clock-names = "hclock", "iscck", "gck";
-	#clock-cells = <0>;
-	clock-output-names = "isc-mck";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>;
-
-	port {
-		isc_0: endpoint {
-			remote-endpoint = <&ov7740_0>;
-			hsync-active = <1>;
-			vsync-active = <0>;
-			pclk-sample = <1>;
-		};
-	};
-};
-
-i2c1: i2c at fc028000 {
-	ov7740: camera at 21 {
-		compatible = "ovti,ov7740";
-		reg = <0x21>;
-		clocks = <&isc>;
-		clock-names = "xvclk";
-		assigned-clocks = <&isc>;
-		assigned-clock-rates = <24000000>;
-
-		port {
-			ov7740_0: endpoint {
-				remote-endpoint = <&isc_0>;
-			};
-		};
-	};
-};
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:25 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:25 +0300
Subject: [PATCH v3 27/33] media: atmel: atmel-isc-base: add support for more
 formats and additional pipeline modules
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-28-eugen.hristev@microchip.com>

Add support for additional formats supported by newer pipelines, and for
additional pipeline modules.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 48 +++++++++++++++----
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index a3c299068bd5..f30493a1dccd 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -843,6 +843,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
 	case V4L2_PIX_FMT_YUV420:
 	case V4L2_PIX_FMT_YUV422P:
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		ret = 0;
 		yuv = true;
 		break;
@@ -857,6 +859,7 @@ static int isc_try_validate_formats(struct isc_device *isc)
 		break;
 	case V4L2_PIX_FMT_GREY:
 	case V4L2_PIX_FMT_Y10:
+	case V4L2_PIX_FMT_Y16:
 		ret = 0;
 		grey = true;
 		break;
@@ -887,6 +890,8 @@ static int isc_try_validate_formats(struct isc_device *isc)
  */
 static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 {
+	isc->try_config.rlp_cfg_mode = 0;
+
 	switch (isc->try_config.fourcc) {
 	case V4L2_PIX_FMT_SBGGR8:
 	case V4L2_PIX_FMT_SGBRG8:
@@ -953,7 +958,19 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.bpp = 16;
 		break;
 	case V4L2_PIX_FMT_YUYV:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YYCC;
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_YUYV;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_UYVY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_UYVY;
+		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
+		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+		isc->try_config.bpp = 16;
+		break;
+	case V4L2_PIX_FMT_VYUY:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_YCYC | ISC_RLP_CFG_YMODE_VYUY;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED32;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -964,8 +981,11 @@ static int isc_try_configure_rlp_dma(struct isc_device *isc, bool direct_dump)
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 8;
 		break;
+	case V4L2_PIX_FMT_Y16:
+		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10 | ISC_RLP_CFG_LSH;
+		fallthrough;
 	case V4L2_PIX_FMT_Y10:
-		isc->try_config.rlp_cfg_mode = ISC_RLP_CFG_MODE_DATY10;
+		isc->try_config.rlp_cfg_mode |= ISC_RLP_CFG_MODE_DATY10;
 		isc->try_config.dcfg_imode = ISC_DCFG_IMODE_PACKED16;
 		isc->try_config.dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
 		isc->try_config.bpp = 16;
@@ -999,7 +1019,8 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				WB_ENABLE | GAM_ENABLES;
+				WB_ENABLE | GAM_ENABLES | DPC_BLCENABLE |
+				CC_ENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1008,8 +1029,9 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
-				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE;
+				CSC_ENABLE | GAM_ENABLES | WB_ENABLE |
+				SUB420_ENABLE | SUB422_ENABLE | CBC_ENABLE |
+				DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
@@ -1019,33 +1041,39 @@ static int isc_try_configure_pipeline(struct isc_device *isc)
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_YUYV:
+	case V4L2_PIX_FMT_UYVY:
+	case V4L2_PIX_FMT_VYUY:
 		/* if sensor format is RAW, we convert inside ISC */
 		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				SUB422_ENABLE | CBC_ENABLE;
+				SUB422_ENABLE | CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	case V4L2_PIX_FMT_GREY:
-		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
+	case V4L2_PIX_FMT_Y16:
 		/* if sensor format is RAW, we convert inside ISC */
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code)) {
 			isc->try_config.bits_pipeline = CFA_ENABLE |
 				CSC_ENABLE | WB_ENABLE | GAM_ENABLES |
-				CBC_ENABLE;
+				CBC_ENABLE | DPC_BLCENABLE;
 		} else {
 			isc->try_config.bits_pipeline = 0x0;
 		}
 		break;
 	default:
-		isc->try_config.bits_pipeline = 0x0;
+		if (ISC_IS_FORMAT_RAW(isc->try_config.sd_format->mbus_code))
+			isc->try_config.bits_pipeline = WB_ENABLE | DPC_BLCENABLE;
+		else
+			isc->try_config.bits_pipeline = 0x0;
 	}
 
 	/* Tune the pipeline to product specific */
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:28 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:28 +0300
Subject: [PATCH v3 30/33] dt-bindings: media: add microchip,
 xisc device bindings
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-31-eugen.hristev@microchip.com>

Add bindings for the Microchip eXtended Image Sensor Controller.
Based on the atmel,isc.yaml binding.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml

diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
new file mode 100644
index 000000000000..e3825c4e13f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2021 Microchip Technology, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip eXtended Image Sensor Controller (XISC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev at microchip.com>
+
+description:
+  The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
+  Microchip AT91 SAM family of devices.
+
+  The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
+  The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
+  parallel sensor.
+
+  The XISC provides one clock output that is used to clock the demuxer/bridge.
+
+properties:
+  compatible:
+    const: microchip,sama7g5-isc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: hclock
+
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    const: isc-mck
+
+  microchip,mipi-mode:
+    type: boolean
+    description:
+      As the XISC is usually connected to a demux/bridge, the XISC receives
+      the same type of input, however, it should be aware of the type of
+      signals received. The mipi-mode enables different internal handling
+      of the data and clock lines.
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      endpoint:
+        $ref: video-interfaces.yaml#
+
+        properties:
+          bus-type:
+            enum: [5, 6]
+
+          remote-endpoint: true
+
+          bus-width:
+            enum: [8, 9, 10, 11, 12]
+            default: 12
+
+          hsync-active:
+            enum: [0, 1]
+            default: 1
+
+          vsync-active:
+            enum: [0, 1]
+            default: 1
+
+          pclk-sample:
+            enum: [0, 1]
+            default: 1
+
+        required:
+          - remote-endpoint
+          - bus-type
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - clock-output-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/at91.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    xisc: xisc at e1408000 {
+        compatible = "microchip,sama7g5-isc";
+        reg = <0xe1408000 0x2000>;
+        interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+        clock-names = "hclock";
+        #clock-cells = <0>;
+        clock-output-names = "isc-mck";
+
+        port {
+                xisc_in: endpoint {
+                       bus-type = <5>; /* Parallel */
+                       remote-endpoint = <&csi2dc_out>;
+                       hsync-active = <1>;
+                       vsync-active = <1>;
+                       bus-width = <12>;
+                };
+        };
+    };
+
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:26 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:26 +0300
Subject: [PATCH v3 28/33] media: atmel: atmel-isc-sama5d2: remove duplicate
 define
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-29-eugen.hristev@microchip.com>

Remove a duplicate definition of clock max divider

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/atmel/atmel-sama5d2-isc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-sama5d2-isc.c b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
index b2ace528b260..213a2ecc7c66 100644
--- a/drivers/media/platform/atmel/atmel-sama5d2-isc.c
+++ b/drivers/media/platform/atmel/atmel-sama5d2-isc.c
@@ -52,8 +52,6 @@
 #define ISC_SAMA5D2_MAX_SUPPORT_WIDTH   2592
 #define ISC_SAMA5D2_MAX_SUPPORT_HEIGHT  1944
 
-#define ISC_CLK_MAX_DIV		255
-
 #define ISC_SAMA5D2_PIPELINE \
 	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
 	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:30 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:30 +0300
Subject: [PATCH v3 32/33] MAINTAINERS: update ISC driver bindings file
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-33-eugen.hristev@microchip.com>

ISC driver was converted to yaml. Update maintainers file.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 04e6df934eb0..95e3c7b7f934 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11720,7 +11720,7 @@ MICROCHIP ISC DRIVER
 M:	Eugen Hristev <eugen.hristev at microchip.com>
 L:	linux-media at vger.kernel.org
 S:	Supported
-F:	Documentation/devicetree/bindings/media/atmel-isc.txt
+F:	Documentation/devicetree/bindings/media/atmel,isc.yaml
 F:	drivers/media/platform/atmel/atmel-isc-base.c
 F:	drivers/media/platform/atmel/atmel-isc-regs.h
 F:	drivers/media/platform/atmel/atmel-isc.h
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:29 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:29 +0300
Subject: [PATCH v3 31/33] media: atmel: atmel-isc: add microchip-xisc driver
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-32-eugen.hristev@microchip.com>

Add driver for the extended variant of the isc, the microchip XISC
present on sama7g5 product.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 drivers/media/platform/Makefile               |   1 +
 drivers/media/platform/atmel/Kconfig          |  11 +
 drivers/media/platform/atmel/Makefile         |   2 +
 drivers/media/platform/atmel/atmel-isc-base.c |   2 +-
 drivers/media/platform/atmel/atmel-isc-regs.h |  26 +
 .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++++++++++++++++++
 6 files changed, 684 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c

diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index eedc14aafb32..73ce083c2fc6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)		+= rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)		+= atmel/
 obj-$(CONFIG_VIDEO_ATMEL_ISI)		+= atmel/
+obj-$(CONFIG_VIDEO_ATMEL_XISC)		+= atmel/
 
 obj-$(CONFIG_VIDEO_STM32_DCMI)		+= stm32/
 
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 1850fe7f9360..99b51213f871 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -12,6 +12,17 @@ config VIDEO_ATMEL_ISC
 	   This module makes the ATMEL Image Sensor Controller available
 	   as a v4l2 device.
 
+config VIDEO_ATMEL_XISC
+	tristate "ATMEL eXtended Image Sensor Controller (XISC) support"
+	depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API
+	depends on ARCH_AT91 || COMPILE_TEST
+	select VIDEOBUF2_DMA_CONTIG
+	select REGMAP_MMIO
+	select V4L2_FWNODE
+	help
+	   This module makes the ATMEL eXtended Image Sensor Controller
+	   available as a v4l2 device.
+
 config VIDEO_ATMEL_ISI
 	tristate "ATMEL Image Sensor Interface (ISI) support"
 	depends on VIDEO_V4L2 && OF
diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile
index 2dba38994a70..c5c01556c653 100644
--- a/drivers/media/platform/atmel/Makefile
+++ b/drivers/media/platform/atmel/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 atmel-isc-objs = atmel-sama5d2-isc.o atmel-isc-base.o
+atmel-xisc-objs = atmel-sama7g5-isc.o atmel-isc-base.o
 
 obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
 obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
+obj-$(CONFIG_VIDEO_ATMEL_XISC) += atmel-xisc.o
diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index f30493a1dccd..d6409406ce2f 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -592,7 +592,7 @@ static int isc_configure(struct isc_device *isc)
 	mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
 	       ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW |
 	       ISC_PFE_CFG0_MODE_MASK | ISC_PFE_CFG0_CCIR_CRC |
-		   ISC_PFE_CFG0_CCIR656;
+	       ISC_PFE_CFG0_CCIR656 | ISC_PFE_CFG0_MIPI;
 
 	regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
 
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 5f99bf7717c1..d06b72228d4f 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -26,6 +26,7 @@
 #define ISC_PFE_CFG0_PPOL_LOW   BIT(2)
 #define ISC_PFE_CFG0_CCIR656    BIT(9)
 #define ISC_PFE_CFG0_CCIR_CRC   BIT(10)
+#define ISC_PFE_CFG0_MIPI	BIT(14)
 
 #define ISC_PFE_CFG0_MODE_PROGRESSIVE   (0x0 << 4)
 #define ISC_PFE_CFG0_MODE_MASK          GENMASK(6, 4)
@@ -184,6 +185,8 @@
 /* ISC Gamma Correction Control Register */
 #define ISC_GAM_CTRL    0x00000094
 
+#define ISC_GAM_CTRL_BIPART	BIT(4)
+
 /* ISC_Gamma Correction Blue Entry Register */
 #define ISC_GAM_BENTRY	0x00000098
 
@@ -222,6 +225,8 @@
 
 /* Offset for CSC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CSC_OFFSET	0
+/* Offset for CSC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CSC_OFFSET	0x11c
 
 /* Color Space Conversion Control Register */
 #define ISC_CSC_CTRL    0x00000398
@@ -246,6 +251,8 @@
 
 /* Offset for CBC register specific to sama5d2 product */
 #define ISC_SAMA5D2_CBC_OFFSET	0
+/* Offset for CBC register specific to sama7g5 product */
+#define ISC_SAMA7G5_CBC_OFFSET	0x11c
 
 /* Contrast And Brightness Control Register */
 #define ISC_CBC_CTRL    0x000003b4
@@ -261,18 +268,30 @@
 #define ISC_CBC_CONTRAST	0x000003c0
 #define ISC_CBC_CONTRAST_MASK	GENMASK(11, 0)
 
+/* Hue Register */
+#define ISC_CBCHS_HUE	0x4e0
+/* Saturation Register */
+#define ISC_CBCHS_SAT	0x4e4
+
 /* Offset for SUB422 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB422_OFFSET	0
+/* Offset for SUB422 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB422_OFFSET	0x124
+
 /* Subsampling 4:4:4 to 4:2:2 Control Register */
 #define ISC_SUB422_CTRL 0x000003c4
 
 /* Offset for SUB420 register specific to sama5d2 product */
 #define ISC_SAMA5D2_SUB420_OFFSET	0
+/* Offset for SUB420 register specific to sama7g5 product */
+#define ISC_SAMA7G5_SUB420_OFFSET	0x124
 /* Subsampling 4:2:2 to 4:2:0 Control Register */
 #define ISC_SUB420_CTRL 0x000003cc
 
 /* Offset for RLP register specific to sama5d2 product */
 #define ISC_SAMA5D2_RLP_OFFSET	0
+/* Offset for RLP register specific to sama7g5 product */
+#define ISC_SAMA7G5_RLP_OFFSET	0x124
 /* Rounding, Limiting and Packing Configuration Register */
 #define ISC_RLP_CFG     0x000003d0
 
@@ -303,6 +322,8 @@
 
 /* Offset for HIS register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_OFFSET	0
+/* Offset for HIS register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_OFFSET	0x124
 /* Histogram Control Register */
 #define ISC_HIS_CTRL	0x000003d4
 
@@ -326,6 +347,8 @@
 
 /* Offset for DMA register specific to sama5d2 product */
 #define ISC_SAMA5D2_DMA_OFFSET	0
+/* Offset for DMA register specific to sama7g5 product */
+#define ISC_SAMA7G5_DMA_OFFSET	0x13c
 
 /* DMA Configuration Register */
 #define ISC_DCFG        0x000003e0
@@ -376,11 +399,14 @@
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_VERSION_OFFSET	0
+#define ISC_SAMA7G5_VERSION_OFFSET	0x13c
 /* Version Register */
 #define ISC_VERSION	0x0000040c
 
 /* Offset for version register specific to sama5d2 product */
 #define ISC_SAMA5D2_HIS_ENTRY_OFFSET	0
+/* Offset for version register specific to sama7g5 product */
+#define ISC_SAMA7G5_HIS_ENTRY_OFFSET	0x14c
 /* Histogram Entry */
 #define ISC_HIS_ENTRY	0x00000410
 
diff --git a/drivers/media/platform/atmel/atmel-sama7g5-isc.c b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
new file mode 100644
index 000000000000..9d2f0bbd8815
--- /dev/null
+++ b/drivers/media/platform/atmel/atmel-sama7g5-isc.c
@@ -0,0 +1,643 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Microchip eXtended Image Sensor Controller (XISC) driver
+ *
+ * Copyright (C) 2019-2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ * Author: Eugen Hristev <eugen.hristev at microchip.com>
+ *
+ * Sensor-->PFE-->DPC-->WB-->CFA-->CC-->GAM-->VHXS-->CSC-->CBHS-->SUB-->RLP-->DMA-->HIS
+ *
+ * ISC video pipeline integrates the following submodules:
+ * PFE: Parallel Front End to sample the camera sensor input stream
+ * DPC: Defective Pixel Correction with black offset correction, green disparity
+ *      correction and defective pixel correction (3 modules total)
+ *  WB: Programmable white balance in the Bayer domain
+ * CFA: Color filter array interpolation module
+ *  CC: Programmable color correction
+ * GAM: Gamma correction
+ *VHXS: Vertical and Horizontal Scaler
+ * CSC: Programmable color space conversion
+ *CBHS: Contrast Brightness Hue and Saturation control
+ * SUB: This module performs YCbCr444 to YCbCr420 chrominance subsampling
+ * RLP: This module performs rounding, range limiting
+ *      and packing of the incoming data
+ * DMA: This module performs DMA master accesses to write frames to external RAM
+ * HIS: Histogram module performs statistic counters on the frames
+ */
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/videodev2.h>
+
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-event.h>
+#include <media/v4l2-image-sizes.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+#include <media/videobuf2-dma-contig.h>
+
+#include "atmel-isc-regs.h"
+#include "atmel-isc.h"
+
+#define ISC_SAMA7G5_MAX_SUPPORT_WIDTH   3264
+#define ISC_SAMA7G5_MAX_SUPPORT_HEIGHT  2464
+
+#define ISC_SAMA7G5_PIPELINE \
+	(WB_ENABLE | CFA_ENABLE | CC_ENABLE | GAM_ENABLES | CSC_ENABLE | \
+	CBC_ENABLE | SUB422_ENABLE | SUB420_ENABLE)
+
+void isc_sama7g5_config_csc(struct isc_device *isc);
+void isc_sama7g5_config_cbc(struct isc_device *isc);
+void isc_sama7g5_config_cc(struct isc_device *isc);
+void isc_sama7g5_config_dpc(struct isc_device *isc);
+void isc_sama7g5_config_gam(struct isc_device *isc);
+void isc_sama7g5_config_rlp(struct isc_device *isc);
+
+void isc_sama7g5_adapt_pipeline(struct isc_device *isc);
+
+void isc_sama7g5_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops);
+
+/* This is a list of the formats that the ISC can *output* */
+const struct isc_format sama7g5_controller_formats[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB444,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ARGB555,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_ABGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_XBGR32,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV420,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_VYUY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUV422P,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y16,
+	},
+};
+
+/* This is a list of formats that the ISC can receive as *input* */
+struct isc_format sama7g5_formats_list[] = {
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR8,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG8,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB8,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR10,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG10,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB10,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SBGGR12,
+		.mbus_code	= MEDIA_BUS_FMT_SBGGR12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_BGBG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGBRG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGBRG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GBGB,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SGRBG12,
+		.mbus_code	= MEDIA_BUS_FMT_SGRBG12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_GRGR,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_SRGGB12,
+		.mbus_code	= MEDIA_BUS_FMT_SRGGB12_1X12,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TWELVE,
+		.cfa_baycfg	= ISC_BAY_CFG_RGRG,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_GREY,
+		.mbus_code	= MEDIA_BUS_FMT_Y8_1X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_YUYV,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_UYVY,
+		.mbus_code	= MEDIA_BUS_FMT_YUYV8_2X8,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_RGB565,
+		.mbus_code	= MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.pfe_cfg0_bps	= ISC_PFE_CFG0_BPS_EIGHT,
+	},
+	{
+		.fourcc		= V4L2_PIX_FMT_Y10,
+		.mbus_code	= MEDIA_BUS_FMT_Y10_1X10,
+		.pfe_cfg0_bps	= ISC_PFG_CFG0_BPS_TEN,
+	},
+
+};
+
+void isc_sama7g5_config_csc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Convert RGB to YUV */
+	regmap_write(regmap, ISC_CSC_YR_YG + isc->offsets.csc,
+		     0x42 | (0x81 << 16));
+	regmap_write(regmap, ISC_CSC_YB_OY + isc->offsets.csc,
+		     0x19 | (0x10 << 16));
+	regmap_write(regmap, ISC_CSC_CBR_CBG + isc->offsets.csc,
+		     0xFDA | (0xFB6 << 16));
+	regmap_write(regmap, ISC_CSC_CBB_OCB + isc->offsets.csc,
+		     0x70 | (0x80 << 16));
+	regmap_write(regmap, ISC_CSC_CRR_CRG + isc->offsets.csc,
+		     0x70 | (0xFA2 << 16));
+	regmap_write(regmap, ISC_CSC_CRB_OCR + isc->offsets.csc,
+		     0xFEE | (0x80 << 16));
+}
+
+void isc_sama7g5_config_cbc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure what is set via v4l2 ctrls */
+	regmap_write(regmap, ISC_CBC_BRIGHT + isc->offsets.cbc, isc->ctrls.brightness);
+	regmap_write(regmap, ISC_CBC_CONTRAST + isc->offsets.cbc, isc->ctrls.contrast);
+	/* Configure Hue and Saturation as neutral midpoint */
+	regmap_write(regmap, ISC_CBCHS_HUE, 0);
+	regmap_write(regmap, ISC_CBCHS_SAT, (1 << 4));
+}
+
+void isc_sama7g5_config_cc(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	/* Configure each register at the neutral fixed point 1.0 or 0.0 */
+	regmap_write(regmap, ISC_CC_RR_RG, (1 << 8));
+	regmap_write(regmap, ISC_CC_RB_OR, 0);
+	regmap_write(regmap, ISC_CC_GR_GG, (1 << 8) << 16);
+	regmap_write(regmap, ISC_CC_GB_OG, 0);
+	regmap_write(regmap, ISC_CC_BR_BG, 0);
+	regmap_write(regmap, ISC_CC_BB_OB, (1 << 8));
+}
+
+void isc_sama7g5_config_ctrls(struct isc_device *isc,
+			      const struct v4l2_ctrl_ops *ops)
+{
+	struct isc_ctrls *ctrls = &isc->ctrls;
+	struct v4l2_ctrl_handler *hdl = &ctrls->handler;
+
+	ctrls->contrast = 16;
+
+	v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -2048, 2047, 1, 16);
+}
+
+void isc_sama7g5_config_dpc(struct isc_device *isc)
+{
+	u32 bay_cfg = isc->config.sd_format->cfa_baycfg;
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BLOFF_MASK,
+			   (64 << ISC_DPC_CFG_BLOFF_SHIFT));
+	regmap_update_bits(regmap, ISC_DPC_CFG, ISC_DPC_CFG_BAYCFG_MASK,
+			   (bay_cfg << ISC_DPC_CFG_BAYCFG_SHIFT));
+}
+
+void isc_sama7g5_config_gam(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+
+	regmap_update_bits(regmap, ISC_GAM_CTRL, ISC_GAM_CTRL_BIPART,
+			   ISC_GAM_CTRL_BIPART);
+}
+
+void isc_sama7g5_config_rlp(struct isc_device *isc)
+{
+	struct regmap *regmap = isc->regmap;
+	u32 rlp_mode = isc->config.rlp_cfg_mode;
+
+	regmap_update_bits(regmap, ISC_RLP_CFG + isc->offsets.rlp,
+			   ISC_RLP_CFG_MODE_MASK | ISC_RLP_CFG_LSH |
+			   ISC_RLP_CFG_YMODE_MASK, rlp_mode);
+}
+
+void isc_sama7g5_adapt_pipeline(struct isc_device *isc)
+{
+	isc->try_config.bits_pipeline &= ISC_SAMA7G5_PIPELINE;
+}
+
+/* Gamma table with gamma 1/2.2 */
+const u32 isc_sama7g5_gamma_table[][GAMMA_ENTRIES] = {
+	/* index 0 --> gamma bipartite */
+	{
+	      0x980,  0x4c0320,  0x650260,  0x7801e0,  0x8701a0,  0x940180,
+	   0xa00160,  0xab0120,  0xb40120,  0xbd0120,  0xc60100,  0xce0100,
+	   0xd600e0,  0xdd00e0,  0xe400e0,  0xeb00c0,  0xf100c0,  0xf700c0,
+	   0xfd00c0, 0x10300a0, 0x10800c0, 0x10e00a0, 0x11300a0, 0x11800a0,
+	  0x11d00a0, 0x12200a0, 0x12700a0, 0x12c0080, 0x13000a0, 0x1350080,
+	  0x13900a0, 0x13e0080, 0x1420076, 0x17d0062, 0x1ae0054, 0x1d8004a,
+	  0x1fd0044, 0x21f003e, 0x23e003a, 0x25b0036, 0x2760032, 0x28f0030,
+	  0x2a7002e, 0x2be002c, 0x2d4002c, 0x2ea0028, 0x2fe0028, 0x3120026,
+	  0x3250024, 0x3370024, 0x3490022, 0x35a0022, 0x36b0020, 0x37b0020,
+	  0x38b0020, 0x39b001e, 0x3aa001e, 0x3b9001c, 0x3c7001c, 0x3d5001c,
+	  0x3e3001c, 0x3f1001c, 0x3ff001a, 0x40c001a },
+};
+
+static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
+{
+	struct device_node *np = dev->of_node;
+	struct device_node *epn = NULL;
+	struct isc_subdev_entity *subdev_entity;
+	unsigned int flags;
+	int ret;
+	bool mipi_mode;
+
+	INIT_LIST_HEAD(&isc->subdev_entities);
+
+	mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
+
+	while (1) {
+		struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
+
+		epn = of_graph_get_next_endpoint(np, epn);
+		if (!epn)
+			return 0;
+
+		ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
+						 &v4l2_epn);
+		if (ret) {
+			ret = -EINVAL;
+			dev_err(dev, "Could not parse the endpoint\n");
+			break;
+		}
+
+		subdev_entity = devm_kzalloc(dev, sizeof(*subdev_entity),
+					     GFP_KERNEL);
+		if (!subdev_entity) {
+			ret = -ENOMEM;
+			break;
+		}
+		subdev_entity->epn = epn;
+
+		flags = v4l2_epn.bus.parallel.flags;
+
+		if (flags & V4L2_MBUS_HSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 = ISC_PFE_CFG0_HPOL_LOW;
+
+		if (flags & V4L2_MBUS_VSYNC_ACTIVE_LOW)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_VPOL_LOW;
+
+		if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
+
+		if (v4l2_epn.bus_type == V4L2_MBUS_BT656)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_CCIR_CRC |
+					ISC_PFE_CFG0_CCIR656;
+
+		if (mipi_mode)
+			subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_MIPI;
+
+		list_add_tail(&subdev_entity->list, &isc->subdev_entities);
+	}
+	of_node_put(epn);
+
+	return ret;
+}
+
+static int microchip_xisc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct isc_device *isc;
+	struct resource *res;
+	void __iomem *io_base;
+	struct isc_subdev_entity *subdev_entity;
+	int irq;
+	int ret;
+	u32 ver;
+
+	isc = devm_kzalloc(dev, sizeof(*isc), GFP_KERNEL);
+	if (!isc)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, isc);
+	isc->dev = dev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	io_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(io_base))
+		return PTR_ERR(io_base);
+
+	isc->regmap = devm_regmap_init_mmio(dev, io_base, &isc_regmap_config);
+	if (IS_ERR(isc->regmap)) {
+		ret = PTR_ERR(isc->regmap);
+		dev_err(dev, "failed to init register map: %d\n", ret);
+		return ret;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	ret = devm_request_irq(dev, irq, isc_interrupt, 0,
+			       "microchip-sama7g5-xisc", isc);
+	if (ret < 0) {
+		dev_err(dev, "can't register ISR for IRQ %u (ret=%i)\n",
+			irq, ret);
+		return ret;
+	}
+
+	isc->gamma_table = isc_sama7g5_gamma_table;
+	isc->gamma_max = 0;
+
+	isc->max_width = ISC_SAMA7G5_MAX_SUPPORT_WIDTH;
+	isc->max_height = ISC_SAMA7G5_MAX_SUPPORT_HEIGHT;
+
+	isc->config_dpc = isc_sama7g5_config_dpc;
+	isc->config_csc = isc_sama7g5_config_csc;
+	isc->config_cbc = isc_sama7g5_config_cbc;
+	isc->config_cc = isc_sama7g5_config_cc;
+	isc->config_gam = isc_sama7g5_config_gam;
+	isc->config_rlp = isc_sama7g5_config_rlp;
+	isc->config_ctrls = isc_sama7g5_config_ctrls;
+
+	isc->adapt_pipeline = isc_sama7g5_adapt_pipeline;
+
+	isc->offsets.csc = ISC_SAMA7G5_CSC_OFFSET;
+	isc->offsets.cbc = ISC_SAMA7G5_CBC_OFFSET;
+	isc->offsets.sub422 = ISC_SAMA7G5_SUB422_OFFSET;
+	isc->offsets.sub420 = ISC_SAMA7G5_SUB420_OFFSET;
+	isc->offsets.rlp = ISC_SAMA7G5_RLP_OFFSET;
+	isc->offsets.his = ISC_SAMA7G5_HIS_OFFSET;
+	isc->offsets.dma = ISC_SAMA7G5_DMA_OFFSET;
+	isc->offsets.version = ISC_SAMA7G5_VERSION_OFFSET;
+	isc->offsets.his_entry = ISC_SAMA7G5_HIS_ENTRY_OFFSET;
+
+	isc->controller_formats = sama7g5_controller_formats;
+	isc->controller_formats_size = ARRAY_SIZE(sama7g5_controller_formats);
+	isc->formats_list = sama7g5_formats_list;
+	isc->formats_list_size = ARRAY_SIZE(sama7g5_formats_list);
+
+	/* sama7g5-isc RAM access port is full AXI4 - 32 bits per beat */
+	isc->dcfg = ISC_DCFG_YMBSIZE_BEATS32 | ISC_DCFG_CMBSIZE_BEATS32;
+
+	ret = isc_pipeline_init(isc);
+	if (ret)
+		return ret;
+
+	isc->hclock = devm_clk_get(dev, "hclock");
+	if (IS_ERR(isc->hclock)) {
+		ret = PTR_ERR(isc->hclock);
+		dev_err(dev, "failed to get hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret) {
+		dev_err(dev, "failed to enable hclock: %d\n", ret);
+		return ret;
+	}
+
+	ret = isc_clk_init(isc);
+	if (ret) {
+		dev_err(dev, "failed to init isc clock: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret) {
+		dev_err(dev, "failed to enable ispck: %d\n", ret);
+		goto unprepare_hclk;
+	}
+
+	/* ispck should be greater or equal to hclock */
+	ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
+	if (ret) {
+		dev_err(dev, "failed to set ispck rate: %d\n", ret);
+		goto unprepare_clk;
+	}
+
+	ret = v4l2_device_register(dev, &isc->v4l2_dev);
+	if (ret) {
+		dev_err(dev, "unable to register v4l2 device.\n");
+		goto unprepare_clk;
+	}
+
+	ret = xisc_parse_dt(dev, isc);
+	if (ret) {
+		dev_err(dev, "fail to parse device tree\n");
+		goto unregister_v4l2_device;
+	}
+
+	if (list_empty(&isc->subdev_entities)) {
+		dev_err(dev, "no subdev found\n");
+		ret = -ENODEV;
+		goto unregister_v4l2_device;
+	}
+
+	list_for_each_entry(subdev_entity, &isc->subdev_entities, list) {
+		struct v4l2_async_subdev *asd;
+
+		v4l2_async_notifier_init(&subdev_entity->notifier);
+
+		asd = v4l2_async_notifier_add_fwnode_remote_subdev(
+					&subdev_entity->notifier,
+					of_fwnode_handle(subdev_entity->epn),
+					struct v4l2_async_subdev);
+
+		of_node_put(subdev_entity->epn);
+		subdev_entity->epn = NULL;
+
+		if (IS_ERR(asd)) {
+			ret = PTR_ERR(asd);
+			goto cleanup_subdev;
+		}
+
+		subdev_entity->notifier.ops = &isc_async_ops;
+
+		ret = v4l2_async_notifier_register(&isc->v4l2_dev,
+						   &subdev_entity->notifier);
+		if (ret) {
+			dev_err(dev, "fail to register async notifier\n");
+			goto cleanup_subdev;
+		}
+
+		if (video_is_registered(&isc->video_dev))
+			break;
+	}
+
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+	pm_request_idle(dev);
+
+	regmap_read(isc->regmap, ISC_VERSION + isc->offsets.version, &ver);
+	dev_info(dev, "Microchip XISC version %x\n", ver);
+
+	return 0;
+
+cleanup_subdev:
+	isc_subdev_cleanup(isc);
+
+unregister_v4l2_device:
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+unprepare_clk:
+	clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return ret;
+}
+
+static int microchip_xisc_remove(struct platform_device *pdev)
+{
+	struct isc_device *isc = platform_get_drvdata(pdev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	isc_subdev_cleanup(isc);
+
+	v4l2_device_unregister(&isc->v4l2_dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	isc_clk_cleanup(isc);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_suspend(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(isc->ispck);
+	clk_disable_unprepare(isc->hclock);
+
+	return 0;
+}
+
+static int __maybe_unused xisc_runtime_resume(struct device *dev)
+{
+	struct isc_device *isc = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(isc->hclock);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(isc->ispck);
+	if (ret)
+		clk_disable_unprepare(isc->hclock);
+
+	return ret;
+}
+
+static const struct dev_pm_ops microchip_xisc_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(xisc_runtime_suspend, xisc_runtime_resume, NULL)
+};
+
+static const struct of_device_id microchip_xisc_of_match[] = {
+	{ .compatible = "microchip,sama7g5-isc" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, microchip_xisc_of_match);
+
+static struct platform_driver microchip_xisc_driver = {
+	.probe	= microchip_xisc_probe,
+	.remove	= microchip_xisc_remove,
+	.driver	= {
+		.name		= "microchip-sama7g5-xisc",
+		.pm		= &microchip_xisc_dev_pm_ops,
+		.of_match_table = of_match_ptr(microchip_xisc_of_match),
+	},
+};
+
+module_platform_driver(microchip_xisc_driver);
+
+MODULE_AUTHOR("Eugen Hristev <eugen.hristev at microchip.com>");
+MODULE_DESCRIPTION("The V4L2 driver for Microchip-XISC");
+MODULE_LICENSE("GPL v2");
+MODULE_SUPPORTED_DEVICE("video");
-- 
2.25.1



From eugen.hristev at microchip.com  Tue Apr 13 11:57:31 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Tue, 13 Apr 2021 13:57:31 +0300
Subject: [PATCH v3 33/33] MAINTAINERS: add xisc files to isc driver entry
In-Reply-To: <20210413105731.610028-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
Message-ID: <20210413105731.610028-34-eugen.hristev@microchip.com>

Add XISC driver and binding files to the ISC driver entry.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 95e3c7b7f934..451f2f0bed0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11721,10 +11721,12 @@ M:	Eugen Hristev <eugen.hristev at microchip.com>
 L:	linux-media at vger.kernel.org
 S:	Supported
 F:	Documentation/devicetree/bindings/media/atmel,isc.yaml
+F:	Documentation/devicetree/bindings/media/microchip,xisc.yaml
 F:	drivers/media/platform/atmel/atmel-isc-base.c
 F:	drivers/media/platform/atmel/atmel-isc-regs.h
 F:	drivers/media/platform/atmel/atmel-isc.h
 F:	drivers/media/platform/atmel/atmel-sama5d2-isc.c
+F:	drivers/media/platform/atmel/atmel-sama7g5-isc.c
 F:	include/linux/atmel-isc-media.h
 
 MICROCHIP ISI DRIVER
-- 
2.25.1



From l.stach at pengutronix.de  Tue Apr 13 12:10:47 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 13 Apr 2021 13:10:47 +0200
Subject: [PATCH v2 0/7] remove different PHY fixups
In-Reply-To: <20210413105144.GN1463@shell.armlinux.org.uk>
References: <20210309112615.625-1-o.rempel@pengutronix.de>
 <c03053f59a89ef6ea4a4f2ce15aee4b4f4892745.camel@pengutronix.de>
 <20210413105144.GN1463@shell.armlinux.org.uk>
Message-ID: <5277e89e497be121aa7d371a434a3f510fa00e4b.camel@pengutronix.de>

Hi Russell,

sorry for the noise of this arriving in your inbox twice. Apparently I
messed up and replied in private in my last mail.

Am Dienstag, dem 13.04.2021 um 11:51 +0100 schrieb Russell King - ARM Linux admin:
> On Tue, Apr 13, 2021 at 12:00:45PM +0200, Lucas Stach wrote:
> > I agree with the opinion that those PHY fixups introduce more harm than
> > good. Essentially they are pushing board specific configuration values
> > into the PHY, without any checks that the fixup is even running on the
> > specific board it was targeted at.
> 
> Yes and no. The problem is, that's an easy statement to make when one
> doesn't understand what they're all doing.
> 
> Some are "board specific" in that the normal setup for e.g. iMX6 would
> be to enable clock output from the AR8035 PHY and feed that into the
> iMX6 - as far as I'm aware, that's the only working configuration for
> that SoC and PHY. However, it's also true that this fixup should not
> be applied unconditionally.
> 
> Then there's SmartEEE - it has been found that the PHY defaults for
> this lead to link drops independent of the board and SoC that it is
> connected to. It seems that the PHY is essentially broken - it powers
> up with SmartEEE enabled, and when connected to another SmartEEE
> supporting device, it seems guaranteed that it will result in link
> drops in its default configuration.
> 
> Freescale's approach has apparently been to unconditionally disable
> SmartEEE for all their platforms because of this. With a bit of
> research however (as has been done by Jon and myself) we've found
> that increasing the Tw parameter for 1G connections results in a
> much more stable link.
> 
> So, just saying that these are bad without actually understanding what
> they are doing is _also_ bad.

I'm not saying the fixups are bad per se. What I'm saying is that they
are inherently board specific and the right way to apply them is either
via DT properties, or if absolutely necessary via a fixup that at least
checks that it is running on the specific board it was targeted at.

While SmartEEE disabling will cause no big harm, aside from a bit more
power consumption, a wrong clock configuration can cause major
confusion. Especially if the configuration in DT and values put into
the PHY via fixups differ from each other.

Regards,
Lucas




From peterz at infradead.org  Tue Apr 13 12:30:06 2021
From: peterz at infradead.org (Peter Zijlstra)
Date: Tue, 13 Apr 2021 13:30:06 +0200
Subject: [PATCH v14 3/6] locking/qspinlock: Introduce CNA into the slow
 path of qspinlock
In-Reply-To: <20210401153156.1165900-4-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-4-alex.kogan@oracle.com>
Message-ID: <YHWAvjymlE5svU71@hirez.programming.kicks-ass.net>

On Thu, Apr 01, 2021 at 11:31:53AM -0400, Alex Kogan wrote:

> +/*
> + * cna_splice_tail -- splice the next node from the primary queue onto
> + * the secondary queue.
> + */
> +static void cna_splice_next(struct mcs_spinlock *node,
> +			    struct mcs_spinlock *next,
> +			    struct mcs_spinlock *nnext)

You forgot to update the comment when you changed the name on this
thing.

> +/*
> + * cna_order_queue - check whether the next waiter in the main queue is on
> + * the same NUMA node as the lock holder; if not, and it has a waiter behind
> + * it in the main queue, move the former onto the secondary queue.
> + */
> +static void cna_order_queue(struct mcs_spinlock *node)
> +{
> +	struct mcs_spinlock *next = READ_ONCE(node->next);
> +	struct cna_node *cn = (struct cna_node *)node;
> +	int numa_node, next_numa_node;
> +
> +	if (!next) {
> +		cn->partial_order = LOCAL_WAITER_NOT_FOUND;
> +		return;
> +	}
> +
> +	numa_node = cn->numa_node;
> +	next_numa_node = ((struct cna_node *)next)->numa_node;
> +
> +	if (next_numa_node != numa_node) {
> +		struct mcs_spinlock *nnext = READ_ONCE(next->next);
> +
> +		if (nnext) {
> +			cna_splice_next(node, next, nnext);
> +			next = nnext;
> +		}
> +		/*
> +		 * Inherit NUMA node id of primary queue, to maintain the
> +		 * preference even if the next waiter is on a different node.
> +		 */
> +		((struct cna_node *)next)->numa_node = numa_node;
> +	}
> +}

So the obvious change since last time I looked a this is that it now
only looks 1 entry ahead. Which makes sense I suppose.

I'm not really a fan of the 'partial_order' name combined with that
silly enum { LOCAL_WAITER_FOUND, LOCAL_WAITER_NOT_FOUND }. That's just
really bad naming all around. The enum is about having a waiter while
the variable is about partial order, that doesn't match at all.

If you rename the variable to 'has_waiter' and simply use 0,1 values,
things would be ever so more readable. But I don't think that makes
sense, see below.

I'm also not sure about that whole numa_node thing, why would you
over-write the numa node, why at this point ?

> +
> +/* Abuse the pv_wait_head_or_lock() hook to get some work done */
> +static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
> +						 struct mcs_spinlock *node)
> +{
> +	/*
> +	 * Try and put the time otherwise spent spin waiting on
> +	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
> +	 */
> +	cna_order_queue(node);
> +
> +	return 0; /* we lied; we didn't wait, go do so now */

So here we inspect one entry ahead and then quit. I can't rmember, but
did we try something like:

	/*
	 * Try and put the time otherwise spent spin waiting on
	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
	 * Move one entry at a go until either the list is fully
	 * sorted or we ran out of spin condition.
	 */
	while (READ_ONCE(lock->val) & _Q_LOCKED_PENDING_MASK &&
	       node->partial_order)
		cna_order_queue(node);

	return 0;

This will keep moving @next to the remote list until such a time that
we're forced to continue or @next is local.

> +}
> +
> +static inline void cna_lock_handoff(struct mcs_spinlock *node,
> +				 struct mcs_spinlock *next)
> +{
> +	struct cna_node *cn = (struct cna_node *)node;
> +	u32 val = 1;
> +
> +	u32 partial_order = cn->partial_order;
> +
> +	if (partial_order == LOCAL_WAITER_NOT_FOUND)
> +		cna_order_queue(node);
> +

AFAICT this is where playing silly games with ->numa_node belong; but
right along with that goes a comment that describes why any of that
makes sense.

I mean, if you leave your node, for any reason, why bother coming back
to it, why not accept it is a sign of the gods you're overdue for a
node-change?

Was the efficacy of this scheme tested?

> +	/*
> +	 * We have a local waiter, either real or fake one;
> +	 * reload @next in case it was changed by cna_order_queue().
> +	 */
> +	next = node->next;
> +	if (node->locked > 1)
> +		val = node->locked;	/* preseve secondary queue */

IIRC we used to do:

	val |= node->locked;

Which is simpler for not having branches. Why change a good thing?

> +
> +	arch_mcs_lock_handoff(&next->locked, val);
> +}


From valentin.schneider at arm.com  Tue Apr 13 12:40:39 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Tue, 13 Apr 2021 12:40:39 +0100
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
 <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
Message-ID: <87o8eimmyw.mognet@arm.com>

On 13/04/21 14:13, Ruifeng Zhang wrote:
> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???
>> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
>> I couldn't find anything about MPIDR format differences:
>>
>>   DDI 0487G.a G8.2.113
>>   """
>>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
>>   AArch64 System register MPIDR_EL1[31:0].
>>   """
>>
>> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
>> just the same, i.e. for both of them, with your example of:
>
> The cortex-a7 spec DDI0464F 4.3.5
> https://developer.arm.com/documentation/ddi0464/f/?lang=en
>

Ah, so that's where the core_id=bit[1:0] comes from. That does still
conform to the MPIDR format, and as you point out below that's being parsed
the same (aff2, aff1, aff0) == mpidr([23:16][15:8][7:0])

> The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
> the parse code is:
> void store_cpu_topology(unsigned int cpuid)
> {
>     ...
>     cpuid_topo->thread_id = -1;
>     cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>     cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>     ...
> }
>>
>>   core0: 0000000080000000
>>   core1: 0000000080000100
>>   core2: 0000000080000200
>>   ...
>>
>> we'll get:
>>
>>   |       | aff2 | aff1 | aff0 |
>>   |-------+------+------+------|
>>   | Core0 |    0 |    0 |    0 |
>>   | Core1 |    0 |    1 |    0 |
>>   | Core2 |    0 |    2 |    0 |
>>       ...
>>
>> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
>>
>>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>>
>> so without DT we would get:
>>   |       | package_id | core_id |
>>   |-------+------------+---------|
>>   | Core0 |          0 |       0 |
>>   | Core1 |          0 |       1 |
>>   | Core2 |          0 |       2 |
>>
>> Whereas with an arm kernel we'll end up parsing MPIDR as:
>>   |       | package_id | core_id |
>>   |-------+------------+---------|
>>   | Core0 |          0 |       0 |
>>   | Core1 |          1 |       0 |
>>   | Core2 |          2 |       0 |
>>
>> Did I get this right? Is this what you're observing?
>
> Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
> kernel on EL1.


With the above MPIDR(_EL1) values, you would have the same problem in
aarch64 mode on any kernel predating

  3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")

since all Aff0 values are 0. Arguably those MPIDR(_EL1) values don't
make much sense (cores in the same cluster should have different Aff0
values, unless SMT), but in arm64 that's usually "corrected" by DT.

As you pointed out, arm doesn't currently leverage the cpu-map DT entry. I
don't see any obvious problem with adding support for it, so if you can fix
the capacity issue Dietmar reported, I think we could consider it.


From l.stach at pengutronix.de  Tue Apr 13 12:47:28 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 13 Apr 2021 13:47:28 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
Message-ID: <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>

Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> Since
> 
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> Date:   Fri Jan 4 09:56:10 2019 +0100
> 
> ????drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> 
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
> 
> This one actually set it twice on top of what drm_plane_init does, so
> double-redundant!

That's not true. imx-dcss and imx-drm are two totally separate drivers.
Maybe we should move imx-drm into its own ipuv3 directory one day to
make this more clear. Change is still correct, though.

Reviewed-by: Lucas Stach <l.stach at pengutronix.de>

> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> ?drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> ?drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
> ?2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> index b549ce5e7607..37ae68a7fba5 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> ?	config->min_height = 1;
> ?	config->max_width = 4096;
> ?	config->max_height = 4096;
> -	config->allow_fb_modifiers = true;
> ?	config->normalize_zpos = true;
> ?
> 
> 
> 
> ?	config->funcs = &dcss_drm_mode_config_funcs;
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> index 2ded8e4f32d0..8be4edaec958 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> ?	drm->mode_config.max_height = 4096;
> ?	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> ?	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> -	drm->mode_config.allow_fb_modifiers = true;
> ?	drm->mode_config.normalize_zpos = true;
> ?
> 
> 
> 
> ?	ret = drmm_mode_config_init(drm);




From catalin.marinas at arm.com  Tue Apr 13 12:49:34 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 13 Apr 2021 12:49:34 +0100
Subject: [PATCH] arm64/sve: Remove redundant system_supports_sve() tests
In-Reply-To: <20210412172320.3315-1-broonie@kernel.org>
References: <20210412172320.3315-1-broonie@kernel.org>
Message-ID: <20210413114933.GE15806@arm.com>

On Mon, Apr 12, 2021 at 06:23:20PM +0100, Mark Brown wrote:
> Currently there are a number of places in the SVE code where we check both
> system_supports_sve() and TIF_SVE. This is a bit redundant given that we
> should never get into a situation where we have set TIF_SVE without having
> SVE support and it is not clear that silently ignoring a mistakenly set
> TIF_SVE flag is the most sensible error handling approach. For now let's
> just drop the system_supports_sve() checks since this will at least reduce
> overhead a little.

It makes sense. The only advantage is if CONFIG_ARM64_SVE is disabled,
we avoid an extra check but with defconfig that's always on.

-- 
Catalin


From peterz at infradead.org  Tue Apr 13 13:03:07 2021
From: peterz at infradead.org (Peter Zijlstra)
Date: Tue, 13 Apr 2021 14:03:07 +0200
Subject: [PATCH v14 4/6] locking/qspinlock: Introduce starvation
 avoidance into CNA
In-Reply-To: <20210401153156.1165900-5-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
Message-ID: <YHWIezK9pbmbWxsu@hirez.programming.kicks-ass.net>

On Thu, Apr 01, 2021 at 11:31:54AM -0400, Alex Kogan wrote:

> @@ -49,13 +55,33 @@ struct cna_node {
>  	u16			real_numa_node;
>  	u32			encoded_tail;	/* self */
>  	u32			partial_order;	/* enum val */
> +	s32			start_time;
>  };

> +/*
> + * Controls the threshold time in ms (default = 10) for intra-node lock
> + * hand-offs before the NUMA-aware variant of spinlock is forced to be
> + * passed to a thread on another NUMA node. The default setting can be
> + * changed with the "numa_spinlock_threshold" boot option.
> + */
> +#define MSECS_TO_JIFFIES(m)	\
> +	(((m) + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ))
> +static int intra_node_handoff_threshold __ro_after_init = MSECS_TO_JIFFIES(10);
> +
> +static inline bool intra_node_threshold_reached(struct cna_node *cn)
> +{
> +	s32 current_time = (s32)jiffies;
> +	s32 threshold = cn->start_time + intra_node_handoff_threshold;
> +
> +	return current_time - threshold > 0;
> +}

None of this makes any sense:

 - why do you track time elapsed as a signed entity?
 - why are you using jiffies; that's terrible granularity.

As Andi already said, 10ms is silly large. You've just inflated the
lock-acquire time for every contended lock to stupid land just because
NUMA.

And this also brings me to the whole premise of this series; *why* are
we optimizing this? What locks are so contended that this actually helps
and shouldn't you be spending your time breaking those locks? That would
improve throughput more than this ever can.

>  static void __init cna_init_nodes_per_cpu(unsigned int cpu)
>  {
>  	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);

> @@ -250,11 +284,17 @@ static void cna_order_queue(struct mcs_spinlock *node)
>  static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
>  						 struct mcs_spinlock *node)
>  {
> -	/*
> -	 * Try and put the time otherwise spent spin waiting on
> -	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
> -	 */
> -	cna_order_queue(node);
> +	struct cna_node *cn = (struct cna_node *)node;
> +
> +	if (!cn->start_time || !intra_node_threshold_reached(cn)) {
> +		/*
> +		 * Try and put the time otherwise spent spin waiting on
> +		 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
> +		 */
> +		cna_order_queue(node);
> +	} else {
> +		cn->partial_order = FLUSH_SECONDARY_QUEUE;

This is even worse naming..

> +	}
>  
>  	return 0; /* we lied; we didn't wait, go do so now */
>  }


From marex at denx.de  Tue Apr 13 13:05:13 2021
From: marex at denx.de (Marek Vasut)
Date: Tue, 13 Apr 2021 14:05:13 +0200
Subject: [PATCH 0/7] ARM: dts: stm32: clk: Switch ETHRX clock parent from
 ETHCK_K to MCO2 on DHCOM SoM
In-Reply-To: <340d32f1-3afb-2159-fa94-70a45aecd88c@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <b81d6a69-713f-eda7-0837-d6e80d691c6a@foss.st.com>
 <2c410c1b-2a1d-b291-a128-c5d5979be1ef@denx.de>
 <340d32f1-3afb-2159-fa94-70a45aecd88c@foss.st.com>
Message-ID: <5a7ac087-4506-df7f-e692-c663d7b61703@denx.de>

On 4/13/21 9:48 AM, Alexandre TORGUE wrote:
> Hi Marek

Hello Alexandre,

> On 4/12/21 8:44 PM, Marek Vasut wrote:
>> On 4/12/21 10:09 AM, Alexandre TORGUE wrote:
>>> Hi Marek
>>
>> Hello Alex,
>>
>> [...]
>>
>>>> All the above still only discusses the clock part of the problem. 
>>>> Even if
>>>> the clock cyclic dependencies could be solved, it would be necessary to
>>>> resolve legacy dwmac st,eth-clk-sel and st,eth-ref-clk-sel DT 
>>>> properties
>>>> and avoid DT ABI break.
>>>
>>> Thanks for those clear explanations and for this series. As 
>>> discussed, this approach looks good to me as it doesn't break our 
>>> current strategy for dwmac clock integration. I don't know if those 
>>> cyclic redundancies will be fixed one day but we can have a look on 
>>> dwmac DT properties (the gain to change them, the effort to keep the 
>>> backward compatibility, code readability, ...).
>>>
>>> Your DT patches looks good. I'll merge them soon.
>> +CC Stephen ; the DT patches depend on the clock driver changes. Would 
>> it make sense to pick the clock patches through the same tree or how 
>> should that be handled ?
> 
> In this situation, I prefer to wait that Stephen takes clock patches in 
> his tree. Then I'll take DT ones in mine. (I assume that taking only 
> clock patches will not break mp1 boot or Ethernet usage).

That's fine by me, thanks !


From geert+renesas at glider.be  Tue Apr 13 13:21:58 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 13 Apr 2021 14:21:58 +0200
Subject: [PATCH] irqchip: APPLE_AIC should depend on ARCH_APPLE
Message-ID: <f37e8daea37d50651d2164b0b3dad90780188548.1618316398.git.geert+renesas@glider.be>

The Apple Interrupt Controller is only present on Apple Silicon SoCs.
Hence add a dependency on ARCH_APPLE, to prevent asking the user about
this driver when configuring a kernel without Apple Silicon SoC support.

Drop the default, as ARCH_APPLE already selects APPLE_AIC.

Fixes: 76cde26394114f6a ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 drivers/irqchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d3a14f304ec80caa..b165b3285d9b0555 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -580,7 +580,7 @@ config MST_IRQ
 config APPLE_AIC
 	bool "Apple Interrupt Controller (AIC)"
 	depends on ARM64
-	default ARCH_APPLE
+	depends on ARCH_APPLE || COMPILE_TEST
 	help
 	  Support for the Apple Interrupt Controller found on Apple Silicon SoCs,
 	  such as the M1.
-- 
2.25.1



From geert+renesas at glider.be  Tue Apr 13 13:26:15 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 13 Apr 2021 14:26:15 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
Message-ID: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>

The HiSilicon Kunpeng I2C controller is only present on HiSilicon
Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
about this driver when configuring a kernel without Hisilicon platform
or ACPI firmware support.

Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -647,7 +647,7 @@ config I2C_HIGHLANDER
 
 config I2C_HISI
 	tristate "HiSilicon I2C controller"
-	depends on ARM64 || COMPILE_TEST
+	depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
 	help
 	  Say Y here if you want to have Hisilicon I2C controller support
 	  available on the Kunpeng Server.
-- 
2.25.1



From geert+renesas at glider.be  Tue Apr 13 13:27:23 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 13 Apr 2021 14:27:23 +0200
Subject: [PATCH] spi: SPI_HISI_KUNPENG should depend on ARCH_HISI
Message-ID: <d93934dfdbb4d35e35371517de3b64c144aeb5ef.1618316782.git.geert+renesas@glider.be>

The HiSilicon Kunpeng SPI controller is only present on HiSilicon
Kunpeng SoCs.  Hence add a dependency on ARCH_HISI, to prevent asking
the user about this driver when configuring a kernel without Hisilicon
platform support.

Fixes: c770d8631e1810d8 ("spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1ffcad19c0562a39..7d438ad343598bb8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -334,7 +334,7 @@ config SPI_FSL_QUADSPI
 
 config SPI_HISI_KUNPENG
 	tristate "HiSilicon SPI Controller for Kunpeng SoCs"
-	depends on (ARM64 && ACPI) || COMPILE_TEST
+	depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
 	help
 	  This enables support for HiSilicon SPI controller found on
 	  Kunpeng SoCs.
-- 
2.25.1



From andriy.shevchenko at linux.intel.com  Tue Apr 13 13:36:57 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Tue, 13 Apr 2021 15:36:57 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
Message-ID: <YHWQaQaw53eZtYzn@smile.fi.intel.com>

On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> about this driver when configuring a kernel without Hisilicon platform
> or ACPI firmware support.

I don't by the ACPI dependency, sorry.

The driver is a pure platform driver that can be enumerated on ACPI enabled
devices, but otherwise it can be used as a platform one.

If you remove ACPI dependency, feel free to add my
Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

> Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
>  drivers/i2c/busses/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
>  
>  config I2C_HISI
>  	tristate "HiSilicon I2C controller"
> -	depends on ARM64 || COMPILE_TEST
> +	depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
>  	help
>  	  Say Y here if you want to have Hisilicon I2C controller support
>  	  available on the Kunpeng Server.
> -- 
> 2.25.1
> 

-- 
With Best Regards,
Andy Shevchenko




From broonie at kernel.org  Tue Apr 13 13:47:15 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 13 Apr 2021 13:47:15 +0100
Subject: [PATCH] spi: SPI_HISI_KUNPENG should depend on ARCH_HISI
In-Reply-To: <d93934dfdbb4d35e35371517de3b64c144aeb5ef.1618316782.git.geert+renesas@glider.be>
References: <d93934dfdbb4d35e35371517de3b64c144aeb5ef.1618316782.git.geert+renesas@glider.be>
Message-ID: <20210413124715.GE5586@sirena.org.uk>

On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:
> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
> Kunpeng SoCs.  Hence add a dependency on ARCH_HISI, to prevent asking
> the user about this driver when configuring a kernel without Hisilicon
> platform support.

Are you *sure* about this?  HiSilicon produce a wide range of SoCs with
very diverse target markets, this driver looks like it's for enterprise
stuff while most things guarded by that config option look like they're
for embedded applications.
-------------- 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/20210413/08ccd248/attachment.sig>

From geert at linux-m68k.org  Tue Apr 13 13:48:15 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 13 Apr 2021 14:48:15 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <YHWQaQaw53eZtYzn@smile.fi.intel.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <YHWQaQaw53eZtYzn@smile.fi.intel.com>
Message-ID: <CAMuHMdX29zQHaC9UgGyGad-LxRRK=hBKVHVZ5+9_Cawqk=NMtA@mail.gmail.com>

Hi Andy,

On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > about this driver when configuring a kernel without Hisilicon platform
> > or ACPI firmware support.
>
> I don't by the ACPI dependency, sorry.
>
> The driver is a pure platform driver that can be enumerated on ACPI enabled
> devices, but otherwise it can be used as a platform one.

Sure, you can manually instantiate a platform device with a matching
name, and set up the "clk_rate" device property.
But would it make sense to do that? Would anyone ever do that?

The corresponding SPI_HISI_KUNPENG depends on ACPI, too.

> If you remove ACPI dependency, feel free to add my
> Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

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 f.fangjian at huawei.com  Tue Apr 13 13:59:02 2021
From: f.fangjian at huawei.com (Jay Fang)
Date: Tue, 13 Apr 2021 20:59:02 +0800
Subject: [PATCH] spi: SPI_HISI_KUNPENG should depend on ARCH_HISI
In-Reply-To: <20210413124715.GE5586@sirena.org.uk>
References: <d93934dfdbb4d35e35371517de3b64c144aeb5ef.1618316782.git.geert+renesas@glider.be>
 <20210413124715.GE5586@sirena.org.uk>
Message-ID: <46a47db2-338e-2ca4-0eac-c2b129ee7b7d@huawei.com>

On 2021/4/13 20:47, Mark Brown wrote:
> On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:
>> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
>> Kunpeng SoCs.  Hence add a dependency on ARCH_HISI, to prevent asking
>> the user about this driver when configuring a kernel without Hisilicon
>> platform support.
> 
> Are you *sure* about this?  HiSilicon produce a wide range of SoCs with
> very diverse target markets, this driver looks like it's for enterprise
> stuff while most things guarded by that config option look like they're
> for embedded applications.
SPI_HISI_KUNPENG does not depend on ARCH_HISI.


Thanks,
Jay





From broonie at kernel.org  Tue Apr 13 14:09:39 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 13 Apr 2021 14:09:39 +0100
Subject: [PATCH] spi: SPI_HISI_KUNPENG should depend on ARCH_HISI
In-Reply-To: <46a47db2-338e-2ca4-0eac-c2b129ee7b7d@huawei.com>
References: <d93934dfdbb4d35e35371517de3b64c144aeb5ef.1618316782.git.geert+renesas@glider.be>
 <20210413124715.GE5586@sirena.org.uk>
 <46a47db2-338e-2ca4-0eac-c2b129ee7b7d@huawei.com>
Message-ID: <20210413130939.GF5586@sirena.org.uk>

On Tue, Apr 13, 2021 at 08:59:02PM +0800, Jay Fang wrote:
> On 2021/4/13 20:47, Mark Brown wrote:
> > On Tue, Apr 13, 2021 at 02:27:23PM +0200, Geert Uytterhoeven wrote:

> >> The HiSilicon Kunpeng SPI controller is only present on HiSilicon
> >> Kunpeng SoCs.  Hence add a dependency on ARCH_HISI, to prevent asking
> >> the user about this driver when configuring a kernel without Hisilicon
> >> platform support.

> > Are you *sure* about this?  HiSilicon produce a wide range of SoCs with
> > very diverse target markets, this driver looks like it's for enterprise
> > stuff while most things guarded by that config option look like they're
> > for embedded applications.

> SPI_HISI_KUNPENG does not depend on ARCH_HISI.

Right, but that's what Geert is proposing to change - the question is
does it make sense to do so or not?
-------------- 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/20210413/a1de9855/attachment.sig>

From ruifeng.zhang0110 at gmail.com  Tue Apr 13 14:26:41 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Tue, 13 Apr 2021 21:26:41 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <87o8eimmyw.mognet@arm.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
 <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
 <87o8eimmyw.mognet@arm.com>
Message-ID: <CAG7+-3NaUAvjv9=9HZ4jQU=DVcZW6gRKZg9ZjutL3aKnnC4FLw@mail.gmail.com>

Thanks for your review. Patch-v2 that solve the capacity issue will be
uploaded as soon as possible. : )

Valentin Schneider <valentin.schneider at arm.com> ?2021?4?13??? ??7:40???
>
> On 13/04/21 14:13, Ruifeng Zhang wrote:
> > Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???
> >> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
> >> I couldn't find anything about MPIDR format differences:
> >>
> >>   DDI 0487G.a G8.2.113
> >>   """
> >>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
> >>   AArch64 System register MPIDR_EL1[31:0].
> >>   """
> >>
> >> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
> >> just the same, i.e. for both of them, with your example of:
> >
> > The cortex-a7 spec DDI0464F 4.3.5
> > https://developer.arm.com/documentation/ddi0464/f/?lang=en
> >
>
> Ah, so that's where the core_id=bit[1:0] comes from. That does still
> conform to the MPIDR format, and as you point out below that's being parsed
> the same (aff2, aff1, aff0) == mpidr([23:16][15:8][7:0])
>
> > The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
> > the parse code is:
> > void store_cpu_topology(unsigned int cpuid)
> > {
> >     ...
> >     cpuid_topo->thread_id = -1;
> >     cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >     cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >     ...
> > }
> >>
> >>   core0: 0000000080000000
> >>   core1: 0000000080000100
> >>   core2: 0000000080000200
> >>   ...
> >>
> >> we'll get:
> >>
> >>   |       | aff2 | aff1 | aff0 |
> >>   |-------+------+------+------|
> >>   | Core0 |    0 |    0 |    0 |
> >>   | Core1 |    0 |    1 |    0 |
> >>   | Core2 |    0 |    2 |    0 |
> >>       ...
> >>
> >> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
> >>
> >>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
> >>
> >> so without DT we would get:
> >>   |       | package_id | core_id |
> >>   |-------+------------+---------|
> >>   | Core0 |          0 |       0 |
> >>   | Core1 |          0 |       1 |
> >>   | Core2 |          0 |       2 |
> >>
> >> Whereas with an arm kernel we'll end up parsing MPIDR as:
> >>   |       | package_id | core_id |
> >>   |-------+------------+---------|
> >>   | Core0 |          0 |       0 |
> >>   | Core1 |          1 |       0 |
> >>   | Core2 |          2 |       0 |
> >>
> >> Did I get this right? Is this what you're observing?
> >
> > Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
> > kernel on EL1.
>
>
> With the above MPIDR(_EL1) values, you would have the same problem in
> aarch64 mode on any kernel predating
>
>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>
> since all Aff0 values are 0. Arguably those MPIDR(_EL1) values don't
> make much sense (cores in the same cluster should have different Aff0
> values, unless SMT), but in arm64 that's usually "corrected" by DT.
>
> As you pointed out, arm doesn't currently leverage the cpu-map DT entry. I
> don't see any obvious problem with adding support for it, so if you can fix
> the capacity issue Dietmar reported, I think we could consider it.


From lkp at intel.com  Tue Apr 13 14:32:17 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 13 Apr 2021 21:32:17 +0800
Subject: [PATCH v1, 3/3] drm/mediatek: gamma set with cmdq
In-Reply-To: <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
References: <1618209347-10816-4-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <202104132152.liqPUFTL-lkp@intel.com>

Hi Yongqiang,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on robh/for-next]
[also build test WARNING on pza/reset/next linus/master v5.12-rc7]
[cannot apply to next-20210413]
[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]

url:    https://github.com/0day-ci/linux/commits/Yongqiang-Niu/gamma-set-with-cmdq/20210412-143659
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r023-20210413 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 9829f5e6b1bca9b61efc629770d28bb9014dec45)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/0day-ci/linux/commit/b562bd6c318f4681373221cc292c78d51cb819e6
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Yongqiang-Niu/gamma-set-with-cmdq/20210412-143659
        git checkout b562bd6c318f4681373221cc292c78d51cb819e6
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/mediatek/mtk_disp_gamma.c:76:50: warning: incompatible pointer to integer conversion passing 'void *' to parameter of type 'unsigned int' [-Wint-conversion]
                           mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
                                                                         ^~~~~~~~~~~~~~~~~~
   drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h:199:19: note: passing argument to parameter 'offset' here
                      unsigned int offset);
                                   ^
   1 warning generated.


vim +76 drivers/gpu/drm/mediatek/mtk_disp_gamma.c

    57	
    58	void mtk_gamma_set_common(void __iomem *regs, struct cmdq_client_reg *cmdq_reg,
    59				  struct drm_crtc_state *state, struct cmdq_pkt *cmdq_pkt)
    60	{
    61		unsigned int i, reg;
    62		struct drm_color_lut *lut;
    63		void __iomem *lut_base;
    64		u32 word;
    65	
    66		if (state->gamma_lut) {
    67			reg = readl(regs + DISP_GAMMA_CFG);
    68			reg = reg | GAMMA_LUT_EN;
    69			mtk_ddp_write(cmdq_pkt, reg, cmdq_reg, regs, DISP_GAMMA_CFG);
    70			lut_base = regs + DISP_GAMMA_LUT;
    71			lut = (struct drm_color_lut *)state->gamma_lut->data;
    72			for (i = 0; i < MTK_LUT_SIZE; i++) {
    73				word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
    74					(((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
    75					((lut[i].blue >> 6) & LUT_10BIT_MASK);
  > 76				mtk_ddp_write(cmdq_pkt, word, cmdq_reg, regs, (lut_base + i * 4));
    77			}
    78		}
    79	}
    80	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29152 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210413/2b0d217b/attachment-0001.gz>

From robh at kernel.org  Tue Apr 13 14:37:26 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 08:37:26 -0500
Subject: [PATCH v3 1/4] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <20210413133726.GA1534983@robh.at.kernel.org>

On Mon, 12 Apr 2021 22:01:52 +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> For some SoC nodes this patch serie generates notifications
> for undocumented "interrupts" properties shared between
> PWM channels till there is consensus of what to do with it or
> someone makes a solution for the whole PWM block.
> 
> Changed V3:
>   fix mistake with compatibles introduced in V2
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 88 ++++++++++++++++++++++
>  2 files changed, 88 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 13 14:37:53 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 08:37:53 -0500
Subject: [PATCH v3 2/4] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210412200155.5316-2-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
 <20210412200155.5316-2-jbx6244@gmail.com>
Message-ID: <20210413133753.GA1535744@robh.at.kernel.org>

On Mon, 12 Apr 2021 22:01:53 +0200, Johan Jonker wrote:
> The compatible strings below are already in use in the Rockchip
> dtsi files, but were somehow never added to a document, so add
> 
> "rockchip,rk3328-pwm"
> 
> "rockchip,rk3036-pwm", "rockchip,rk2928-pwm"
> 
> "rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
> "rockchip,rk3399-pwm", "rockchip,rk3288-pwm"
> 
> "rockchip,px30-pwm", "rockchip,rk3328-pwm"
> "rockchip,rk3308-pwm", "rockchip,rk3328-pwm"
> 
> for pwm nodes to pwm-rockchip.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Note for rob+dt:
> A tag was not added on purpose, because by the change of schema
> for clocks and clock-names I add "rockchip,rk3328-pwm" to
> the "if:", so strictly speaking V1 and (V2) V3 will not be the same.
> Please have a look at it again.
> 
> For some SoC nodes this patch serie generates notifications
> for undocumented "interrupts" properties shared between
> PWM channels till there is consensus of what to do with it or
> someone makes a solution for the whole PWM block.
> 
> Changed V3:
>   fix mistake with compatibles introduced in V2
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From daniel at ffwll.ch  Tue Apr 13 15:04:37 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 13 Apr 2021 16:04:37 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
 <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
Message-ID: <YHWk9V/4mu1lGFgD@phenom.ffwll.local>

On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> > 
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > Date:   Fri Jan 4 09:56:10 2019 +0100
> > 
> > ????drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > 
> > this is done automatically as part of plane init, if drivers set the
> > modifier list correctly. Which is the case here.
> > 
> > This one actually set it twice on top of what drm_plane_init does, so
> > double-redundant!
> 
> That's not true. imx-dcss and imx-drm are two totally separate drivers.
> Maybe we should move imx-drm into its own ipuv3 directory one day to
> make this more clear. Change is still correct, though.

Hm I greeped for drm_universal_plane_init and didn't find anythinf for the
imx main driver ... where are planes set up for that? Need to review that
they have the modifiers listed in all cases.
-Daniel

> 
> Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > Cc: Shawn Guo <shawnguo at kernel.org>
> > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > Cc: Fabio Estevam <festevam at gmail.com>
> > Cc: NXP Linux Team <linux-imx at nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > ---
> > ?drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> > ?drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
> > ?2 files changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > index b549ce5e7607..37ae68a7fba5 100644
> > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> > ?	config->min_height = 1;
> > ?	config->max_width = 4096;
> > ?	config->max_height = 4096;
> > -	config->allow_fb_modifiers = true;
> > ?	config->normalize_zpos = true;
> > ?
> > 
> > 
> > 
> > ?	config->funcs = &dcss_drm_mode_config_funcs;
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 2ded8e4f32d0..8be4edaec958 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> > ?	drm->mode_config.max_height = 4096;
> > ?	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > ?	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > -	drm->mode_config.allow_fb_modifiers = true;
> > ?	drm->mode_config.normalize_zpos = true;
> > ?
> > 
> > 
> > 
> > ?	ret = drmm_mode_config_init(drm);
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From krzysztof.kozlowski at canonical.com  Tue Apr 13 15:04:30 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 13 Apr 2021 16:04:30 +0200
Subject: [PATCH v5 14/16] memory: mtk-smi: Get rid of mtk_smi_larb_get/put
In-Reply-To: <20210410091128.31823-15-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
 <20210410091128.31823-15-yong.wu@mediatek.com>
Message-ID: <b015fd4a-f05b-5dc7-f23e-e517d40aeb21@canonical.com>

On 10/04/2021 11:11, Yong Wu wrote:
> After adding device_link between the iommu consumer and smi-larb,
> the pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. we can get rid of mtk_smi_larb_get/put.
> 
> CC: Matthias Brugger <matthias.bgg at gmail.com>
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> Reviewed-by: Evan Green <evgreen at chromium.org>
> ---
>  drivers/memory/mtk-smi.c   | 14 --------------
>  include/soc/mediatek/smi.h | 20 --------------------
>  2 files changed, 34 deletions(-)
> 


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


Best regards,
Krzysztof


From l.stach at pengutronix.de  Tue Apr 13 15:14:11 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 13 Apr 2021 16:14:11 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <YHWk9V/4mu1lGFgD@phenom.ffwll.local>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
 <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
 <YHWk9V/4mu1lGFgD@phenom.ffwll.local>
Message-ID: <83a41b2e9636cb6a790b23843c6d2628d02c6997.camel@pengutronix.de>

Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > Since
> > > 
> > > commit 890880ddfdbe256083170866e49c87618b706ac7
> > > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > > Date:   Fri Jan 4 09:56:10 2019 +0100
> > > 
> > > ????drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > > 
> > > this is done automatically as part of plane init, if drivers set the
> > > modifier list correctly. Which is the case here.
> > > 
> > > This one actually set it twice on top of what drm_plane_init does, so
> > > double-redundant!
> > 
> > That's not true. imx-dcss and imx-drm are two totally separate drivers.
> > Maybe we should move imx-drm into its own ipuv3 directory one day to
> > make this more clear. Change is still correct, though.
> 
> Hm I greeped for drm_universal_plane_init and didn't find anythinf for the
> imx main driver ... where are planes set up for that? Need to review that
> they have the modifiers listed in all cases.

That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always
set on plane init.

Regards,
Lucas

> 
> > 
> > Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> > 
> > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > Cc: Shawn Guo <shawnguo at kernel.org>
> > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > > Cc: Fabio Estevam <festevam at gmail.com>
> > > Cc: NXP Linux Team <linux-imx at nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org
> > > ---
> > > ?drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> > > ?drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
> > > ?2 files changed, 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > index b549ce5e7607..37ae68a7fba5 100644
> > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> > > ?	config->min_height = 1;
> > > ?	config->max_width = 4096;
> > > ?	config->max_height = 4096;
> > > -	config->allow_fb_modifiers = true;
> > > ?	config->normalize_zpos = true;
> > > ?
> > > 
> > > 
> > > 
> > > ?	config->funcs = &dcss_drm_mode_config_funcs;
> > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> > > index 2ded8e4f32d0..8be4edaec958 100644
> > > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> > > ?	drm->mode_config.max_height = 4096;
> > > ?	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > > ?	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > > -	drm->mode_config.allow_fb_modifiers = true;
> > > ?	drm->mode_config.normalize_zpos = true;
> > > ?
> > > 
> > > 
> > > 
> > > ?	ret = drmm_mode_config_init(drm);
> > 
> > 
> 




From pbrobinson at gmail.com  Tue Apr 13 15:17:09 2021
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 13 Apr 2021 15:17:09 +0100
Subject: [PATCH] arm64: dts: rockchip: Use only supported PCIe link speed on
 rk3399
Message-ID: <20210413141709.845592-1-pbrobinson@gmail.com>

The max link speed supported by the rk3399 is already set in the
rk3399.dtsi file so don't set unsupported link speeds in device
specific DTs. This is the same fix as 642fb27.

Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi      | 1 -
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi    | 1 -
 arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi | 1 -
 3 files changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 48ed4aaa37f3..476787027e03 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ &pcie_phy {
 };
 
 &pcie0 {
-	max-link-speed = <2>;
 	num-lanes = <2>;
 	vpcie0v9-supply = <&vcca0v9_s3>;
 	vpcie1v8-supply = <&vcca1v8_s3>;
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 fb7599f07af4..17ba7c3d9a9c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
@@ -469,7 +469,6 @@ &pcie_phy {
 
 &pcie0 {
 	ep-gpios = <&gpio4 RK_PD3 GPIO_ACTIVE_HIGH>;
-	max-link-speed = <2>;
 	num-lanes = <4>;
 	pinctrl-0 = <&pcie_clkreqnb_cpm>;
 	pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
index 7257494d2831..bc385ad45a13 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399pro-vmarc-som.dtsi
@@ -324,7 +324,6 @@ &pcie_phy {
 
 &pcie0 {
 	ep-gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
-	max-link-speed = <2>;
 	num-lanes = <4>;
 	pinctrl-0 = <&pcie_clkreqnb_cpm>;
 	pinctrl-names = "default";
-- 
2.31.1



From amelie.delaunay at foss.st.com  Tue Apr 13 15:31:39 2021
From: amelie.delaunay at foss.st.com (Amelie Delaunay)
Date: Tue, 13 Apr 2021 16:31:39 +0200
Subject: [PATCH v2 0/2] STM32 USBPHYC vbus-supply property support
Message-ID: <20210413143141.12919-1-amelie.delaunay@foss.st.com>

STM32 USBPHYC provides two USB High-Speed ports which are used by controllers
with Host capabilities. That's why vbus-supply has to be supported on each
phy node.

---
Changes in v2:
- use connector node vbus-supply property as suggested by Rob
---
Amelie Delaunay (2):
  dt-bindings: phy: add vbus-supply optional property to
    phy-stm32-usbphyc
  phy: stm32: manage optional vbus regulator on phy_power_on/off

 .../bindings/phy/phy-stm32-usbphyc.yaml       | 11 +++++++
 drivers/phy/st/phy-stm32-usbphyc.c            | 31 +++++++++++++++++++
 2 files changed, 42 insertions(+)

-- 
2.17.1



From amelie.delaunay at foss.st.com  Tue Apr 13 15:31:41 2021
From: amelie.delaunay at foss.st.com (Amelie Delaunay)
Date: Tue, 13 Apr 2021 16:31:41 +0200
Subject: [PATCH v2 2/2] phy: stm32: manage optional vbus regulator on
 phy_power_on/off
In-Reply-To: <20210413143141.12919-1-amelie.delaunay@foss.st.com>
References: <20210413143141.12919-1-amelie.delaunay@foss.st.com>
Message-ID: <20210413143141.12919-3-amelie.delaunay@foss.st.com>

This patch adds support for optional vbus regulator.
It is managed on phy_power_on/off calls and may be needed for host mode.

Signed-off-by: Amelie Delaunay <amelie.delaunay at foss.st.com>
---
No changes in v2.
---
 drivers/phy/st/phy-stm32-usbphyc.c | 31 ++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/phy/st/phy-stm32-usbphyc.c b/drivers/phy/st/phy-stm32-usbphyc.c
index c184f4e34584..3e491dfb2525 100644
--- a/drivers/phy/st/phy-stm32-usbphyc.c
+++ b/drivers/phy/st/phy-stm32-usbphyc.c
@@ -57,6 +57,7 @@ struct pll_params {
 struct stm32_usbphyc_phy {
 	struct phy *phy;
 	struct stm32_usbphyc *usbphyc;
+	struct regulator *vbus;
 	u32 index;
 	bool active;
 };
@@ -291,9 +292,31 @@ static int stm32_usbphyc_phy_exit(struct phy *phy)
 	return stm32_usbphyc_pll_disable(usbphyc);
 }
 
+static int stm32_usbphyc_phy_power_on(struct phy *phy)
+{
+	struct stm32_usbphyc_phy *usbphyc_phy = phy_get_drvdata(phy);
+
+	if (usbphyc_phy->vbus)
+		return regulator_enable(usbphyc_phy->vbus);
+
+	return 0;
+}
+
+static int stm32_usbphyc_phy_power_off(struct phy *phy)
+{
+	struct stm32_usbphyc_phy *usbphyc_phy = phy_get_drvdata(phy);
+
+	if (usbphyc_phy->vbus)
+		return regulator_disable(usbphyc_phy->vbus);
+
+	return 0;
+}
+
 static const struct phy_ops stm32_usbphyc_phy_ops = {
 	.init = stm32_usbphyc_phy_init,
 	.exit = stm32_usbphyc_phy_exit,
+	.power_on = stm32_usbphyc_phy_power_on,
+	.power_off = stm32_usbphyc_phy_power_off,
 	.owner = THIS_MODULE,
 };
 
@@ -519,6 +542,14 @@ static int stm32_usbphyc_probe(struct platform_device *pdev)
 		usbphyc->phys[port]->index = index;
 		usbphyc->phys[port]->active = false;
 
+		usbphyc->phys[port]->vbus = devm_regulator_get_optional(&phy->dev, "vbus");
+		if (IS_ERR(usbphyc->phys[port]->vbus)) {
+			ret = PTR_ERR(usbphyc->phys[port]->vbus);
+			if (ret == -EPROBE_DEFER)
+				goto put_child;
+			usbphyc->phys[port]->vbus = NULL;
+		}
+
 		port++;
 	}
 
-- 
2.17.1



From amelie.delaunay at foss.st.com  Tue Apr 13 15:31:40 2021
From: amelie.delaunay at foss.st.com (Amelie Delaunay)
Date: Tue, 13 Apr 2021 16:31:40 +0200
Subject: [PATCH v2 1/2] dt-bindings: phy: add vbus-supply optional property to
 phy-stm32-usbphyc
In-Reply-To: <20210413143141.12919-1-amelie.delaunay@foss.st.com>
References: <20210413143141.12919-1-amelie.delaunay@foss.st.com>
Message-ID: <20210413143141.12919-2-amelie.delaunay@foss.st.com>

This patch adds vbus-supply optional property to phy sub-nodes using
connector node.
A regulator for USB VBUS may be needed for host mode.

Signed-off-by: Amelie Delaunay <amelie.delaunay at foss.st.com>
---
Changes in v2:
- add connector vbus-supply property as suggested by Rob
---
 .../devicetree/bindings/phy/phy-stm32-usbphyc.yaml    | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
index 018cc1246ee1..3329f1d33a4f 100644
--- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
@@ -74,6 +74,13 @@ patternProperties:
       "#phy-cells":
         enum: [ 0x0, 0x1 ]
 
+      connector:
+        type: object
+        allOf:
+          - $ref: ../connector/usb-connector.yaml
+        properties:
+          vbus-supply: true
+
     allOf:
       - if:
           properties:
@@ -130,6 +137,10 @@ examples:
             reg = <0>;
             phy-supply = <&vdd_usb>;
             #phy-cells = <0>;
+            connector {
+                compatible = "usb-a-connector";
+                vbus-supply = <&vbus_sw>;
+            };
         };
 
         usbphyc_port1: usb-phy at 1 {
-- 
2.17.1



From andriy.shevchenko at linux.intel.com  Tue Apr 13 15:41:28 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Tue, 13 Apr 2021 17:41:28 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdX29zQHaC9UgGyGad-LxRRK=hBKVHVZ5+9_Cawqk=NMtA@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <YHWQaQaw53eZtYzn@smile.fi.intel.com>
 <CAMuHMdX29zQHaC9UgGyGad-LxRRK=hBKVHVZ5+9_Cawqk=NMtA@mail.gmail.com>
Message-ID: <YHWtmBTSKzFMQ/Dy@smile.fi.intel.com>

On Tue, Apr 13, 2021 at 02:48:15PM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > about this driver when configuring a kernel without Hisilicon platform
> > > or ACPI firmware support.
> >
> > I don't by the ACPI dependency, sorry.
> >
> > The driver is a pure platform driver that can be enumerated on ACPI enabled
> > devices, but otherwise it can be used as a platform one.
> 
> Sure, you can manually instantiate a platform device with a matching
> name, and set up the "clk_rate" device property.
> But would it make sense to do that? Would anyone ever do that?

It will narrow down the possibility to have One Kernel for as many as possible
platforms.

> The corresponding SPI_HISI_KUNPENG depends on ACPI, too.

-- 
With Best Regards,
Andy Shevchenko




From trix at redhat.com  Tue Apr 13 15:41:35 2021
From: trix at redhat.com (Tom Rix)
Date: Tue, 13 Apr 2021 07:41:35 -0700
Subject: [PATCH] fpga: xilinx-pr-decoupler: remove useless function
In-Reply-To: <1618285894-111432-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1618285894-111432-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <40a0449f-37c4-6b3a-5a34-d865db971f9f@redhat.com>


On 4/12/21 8:51 PM, Jiapeng Chong wrote:
> Fix the following gcc warning:
>
> drivers/fpga/xilinx-pr-decoupler.c:32:19: warning: unused function
> 'xlnx_pr_decouple_read' [-Wunused-function].
>
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
> ---
>   drivers/fpga/xilinx-pr-decoupler.c | 6 ------
>   1 file changed, 6 deletions(-)
>
> diff --git a/drivers/fpga/xilinx-pr-decoupler.c b/drivers/fpga/xilinx-pr-decoupler.c
> index 7d69af2..f407cb2 100644
> --- a/drivers/fpga/xilinx-pr-decoupler.c
> +++ b/drivers/fpga/xilinx-pr-decoupler.c
> @@ -29,12 +29,6 @@ static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data *d,
>   	writel(val, d->io_base + offset);
>   }
>   
> -static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,
> -					u32 offset)
> -{
> -	return readl(d->io_base + offset);
> -}
> -

I am not in favor of removing this function.

It should have been used in xlnx_pr_decoupler_enable_show() instead of 
the bare readl().

So use it in this function, and for consistency rename to 
xlnx_pr_decoupler_read()

that is 'decouple' -> 'decoupler'

Tom

>   static int xlnx_pr_decoupler_enable_set(struct fpga_bridge *bridge, bool enable)
>   {
>   	int err;



From geert at linux-m68k.org  Tue Apr 13 15:44:33 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 13 Apr 2021 16:44:33 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <YHWtmBTSKzFMQ/Dy@smile.fi.intel.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <YHWQaQaw53eZtYzn@smile.fi.intel.com>
 <CAMuHMdX29zQHaC9UgGyGad-LxRRK=hBKVHVZ5+9_Cawqk=NMtA@mail.gmail.com>
 <YHWtmBTSKzFMQ/Dy@smile.fi.intel.com>
Message-ID: <CAMuHMdV1kTcPhutZZa04zd53C37Ci7Fr51nq1z8OX3kg1C14CA@mail.gmail.com>

Hi Andy,

On Tue, Apr 13, 2021 at 4:41 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Tue, Apr 13, 2021 at 02:48:15PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > > On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > about this driver when configuring a kernel without Hisilicon platform
> > > > or ACPI firmware support.
> > >
> > > I don't by the ACPI dependency, sorry.
> > >
> > > The driver is a pure platform driver that can be enumerated on ACPI enabled
> > > devices, but otherwise it can be used as a platform one.
> >
> > Sure, you can manually instantiate a platform device with a matching
> > name, and set up the "clk_rate" device property.
> > But would it make sense to do that? Would anyone ever do that?
>
> It will narrow down the possibility to have One Kernel for as many as possible
> platforms.

That One Kernel needs to have CONFIG_ACPI enabled to use I2C on the
HiSilicon Kunpeng.  If CONFIG_ACPI is disabled, it cannot be used, as there
is no other code that creates "hisi-i2c" platform devices.

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 canonical.com  Tue Apr 13 15:58:03 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 13 Apr 2021 16:58:03 +0200
Subject: [PATCH v5 04/16] memory: mtk-smi: Add device-link between
 smi-larb and smi-common
In-Reply-To: <1618293876.20053.19.camel@mhfsdcap03>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
 <20210410091128.31823-5-yong.wu@mediatek.com>
 <ea7ed30f-050d-2d38-7c61-1e0c192f6ded@canonical.com>
 <1618293876.20053.19.camel@mhfsdcap03>
Message-ID: <d3b5b48a-82dc-361b-91f7-df0a73629b67@canonical.com>

On 13/04/2021 08:04, Yong Wu wrote:
> On Sat, 2021-04-10 at 14:40 +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2021 11:11, Yong Wu wrote:
>>> Normally, If the smi-larb HW need work, we should enable the smi-common
>>> HW power and clock firstly.
>>> This patch adds device-link between the smi-larb dev and the smi-common
>>> dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
>>> (smi-common-dev) will be called automatically.
>>>
>>> Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
>>> probe.
>>>
>>> CC: Matthias Brugger <matthias.bgg at gmail.com>
>>> Suggested-by: Tomasz Figa <tfiga at chromium.org>
>>> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
>>> ---
>>>  drivers/memory/mtk-smi.c | 19 ++++++++++---------
>>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> I understood this is a dependency for other patches, so:
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
>>
>> If I am wrong and I can take it via memory tree, let me know.
> 
> Hi Krzysztof,
> 
> Thanks very much for your quickly review.
> 
> I think it is ok if it go through memory tree. In the original patch, we
> pm_runtime_get(smi-common-dev) in the smi-larb's pm resume callback.
> This patch only use device-link do this. thus, this patch have no
> function change. it only adjusts the SMI internal code flow.

Hm, okay, I took it then for v5.13.

> 
> In addition, [14/16] expects your Acked-by. and that one should be
> merged with the others.

Thanks for reminder.

Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Tue Apr 13 15:58:23 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 13 Apr 2021 16:58:23 +0200
Subject: [PATCH] memory: samsung: exynos5422-dmc: handle clk_set_parent()
 failure
In-Reply-To: <20210407154535.70756-1-krzysztof.kozlowski@canonical.com>
References: <20210407154535.70756-1-krzysztof.kozlowski@canonical.com>
Message-ID: <161832589345.71964.47710078429514068.b4-ty@canonical.com>

On Wed, 7 Apr 2021 17:45:35 +0200, Krzysztof Kozlowski wrote:
> clk_set_parent() can fail and ignoring such case could lead to invalid
> clock setup for given frequency.

Applied, thanks!

[1/1] memory: samsung: exynos5422-dmc: handle clk_set_parent() failure
      commit: 132c17c3ff878c7beaba51bdd275d5cc654c0e33

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


From krzysztof.kozlowski at canonical.com  Tue Apr 13 15:58:24 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 13 Apr 2021 16:58:24 +0200
Subject: (subset) [PATCH v5 00/16] Clean up "mediatek,larb"
In-Reply-To: <20210410091128.31823-1-yong.wu@mediatek.com>
References: <20210410091128.31823-1-yong.wu@mediatek.com>
Message-ID: <161832589345.71964.1780926932144222450.b4-ty@canonical.com>

On Sat, 10 Apr 2021 17:11:12 +0800, Yong Wu wrote:
> MediaTek IOMMU block diagram always like below:
> 
>         M4U
>          |
>     smi-common
>          |
>   -------------
>   |         |  ...
>   |         |
> larb1     larb2
>   |         |
> vdec       venc
> 
> [...]

Applied, thanks!

[04/16] memory: mtk-smi: Add device-link between smi-larb and smi-common
        commit: 6ce2c05b21189eb17b3aa26720cc5841acf9dce8

Best regards,
-- 
Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


From krzysztof.kozlowski at canonical.com  Tue Apr 13 16:07:21 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 13 Apr 2021 17:07:21 +0200
Subject: [PATCH] arm: mach-s3c: Remove unnecessary break
In-Reply-To: <20210409064920.1096367-1-wanjiabing@vivo.com>
References: <20210409064920.1096367-1-wanjiabing@vivo.com>
Message-ID: <1c1e4839-fbc7-b50c-dc25-983edf018e7b@canonical.com>

On 09/04/2021 08:49, Wan Jiabing wrote:
> There is a return above the break.
> The break here is unnecessary. Remove it.
> 
> Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
> ---
>  arch/arm/mach-s3c/mach-rx1950.c | 1 -
>  1 file changed, 1 deletion(-)

Thanks, looks good but I do not plan another pull request in current
cycle, so I will take it after the merge window.


Best regards,
Krzysztof


From robh at kernel.org  Tue Apr 13 16:10:13 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 10:10:13 -0500
Subject: =?utf-8?B?W+KAnVBBVENI4oCdIDMvNV0gZHQt?=
 =?utf-8?Q?bindings=3A_pci=3A_add_system_controlle?= =?utf-8?Q?r?= and MAC
 reset bit to Armada 7K/8K controller bindings
In-Reply-To: <1618241456-27200-4-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
 <1618241456-27200-4-git-send-email-bpeled@marvell.com>
Message-ID: <20210413151013.GA1683364@robh.at.kernel.org>

On Mon, Apr 12, 2021 at 06:30:54PM +0300, bpeled at marvell.com wrote:
> From: Ben Peled <bpeled at marvell.com>
> 
> Adding optional system-controller and mac-reset-bit-mask
> needed for linkdown procedure.
> 
> Signed-off-by: Ben Peled <bpeled at marvell.com>
> ---
>  Documentation/devicetree/bindings/pci/pci-armada8k.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> index 7a813d0..2696e79 100644
> --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> @@ -24,6 +24,10 @@ Optional properties:
>  - phy-names: names of the PHYs corresponding to the number of lanes.
>  	Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
>  	2 PHYs.
> +- marvell,system-controller: address of system controller needed
> +	in order to reset MAC used by link-down handle
> +- marvell,mac-reset-bit-mask: MAC reset bit of system controller
> +	needed in order to reset MAC used by link-down handle

Seems like this should use the reset controller binding instead.

If not, this can be a single property with a phandle plus arg.

Rob


From andriy.shevchenko at linux.intel.com  Tue Apr 13 16:19:11 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Tue, 13 Apr 2021 18:19:11 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdV1kTcPhutZZa04zd53C37Ci7Fr51nq1z8OX3kg1C14CA@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <YHWQaQaw53eZtYzn@smile.fi.intel.com>
 <CAMuHMdX29zQHaC9UgGyGad-LxRRK=hBKVHVZ5+9_Cawqk=NMtA@mail.gmail.com>
 <YHWtmBTSKzFMQ/Dy@smile.fi.intel.com>
 <CAMuHMdV1kTcPhutZZa04zd53C37Ci7Fr51nq1z8OX3kg1C14CA@mail.gmail.com>
Message-ID: <YHW2b4aBHh3ohs8r@smile.fi.intel.com>

On Tue, Apr 13, 2021 at 04:44:33PM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 13, 2021 at 4:41 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Tue, Apr 13, 2021 at 02:48:15PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Apr 13, 2021 at 2:37 PM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Tue, Apr 13, 2021 at 02:26:15PM +0200, Geert Uytterhoeven wrote:
> > > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > > about this driver when configuring a kernel without Hisilicon platform
> > > > > or ACPI firmware support.
> > > >
> > > > I don't by the ACPI dependency, sorry.
> > > >
> > > > The driver is a pure platform driver that can be enumerated on ACPI enabled
> > > > devices, but otherwise it can be used as a platform one.
> > >
> > > Sure, you can manually instantiate a platform device with a matching
> > > name, and set up the "clk_rate" device property.
> > > But would it make sense to do that? Would anyone ever do that?
> >
> > It will narrow down the possibility to have One Kernel for as many as possible
> > platforms.
> 
> That One Kernel needs to have CONFIG_ACPI enabled to use I2C on the
> HiSilicon Kunpeng.  If CONFIG_ACPI is disabled, it cannot be used, as there
> is no other code that creates "hisi-i2c" platform devices.

It is fine, but since you add a dependency to the ARCH variant, the ACPI should
be added there, not here. Here is simply wrong place for this dependency as driver
is *not* dependent on ACPI per se.

-- 
With Best Regards,
Andy Shevchenko




From thierry.reding at gmail.com  Tue Apr 13 16:21:49 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 13 Apr 2021 17:21:49 +0200
Subject: [PATCH v3 1/4] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <YHW3DYjr2ifBltVk@orome.fritz.box>

On Mon, Apr 12, 2021 at 10:01:52PM +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> For some SoC nodes this patch serie generates notifications
> for undocumented "interrupts" properties shared between
> PWM channels till there is consensus of what to do with it or
> someone makes a solution for the whole PWM block.
> 
> Changed V3:
>   fix mistake with compatibles introduced in V2
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 88 ++++++++++++++++++++++
>  2 files changed, 88 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

Heiko, do you want to pick up patches 1 & 2 into your tree along with 3 & 4? If so:

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20210413/63ec0e51/attachment.sig>

From thierry.reding at gmail.com  Tue Apr 13 16:22:16 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 13 Apr 2021 17:22:16 +0200
Subject: [PATCH v3 2/4] dt-bindings: pwm: add more compatible strings to
 pwm-rockchip.yaml
In-Reply-To: <20210412200155.5316-2-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
 <20210412200155.5316-2-jbx6244@gmail.com>
Message-ID: <YHW3KFN8zCZBAhS3@orome.fritz.box>

On Mon, Apr 12, 2021 at 10:01:53PM +0200, Johan Jonker wrote:
> The compatible strings below are already in use in the Rockchip
> dtsi files, but were somehow never added to a document, so add
> 
> "rockchip,rk3328-pwm"
> 
> "rockchip,rk3036-pwm", "rockchip,rk2928-pwm"
> 
> "rockchip,rk3368-pwm", "rockchip,rk3288-pwm"
> "rockchip,rk3399-pwm", "rockchip,rk3288-pwm"
> 
> "rockchip,px30-pwm", "rockchip,rk3328-pwm"
> "rockchip,rk3308-pwm", "rockchip,rk3328-pwm"
> 
> for pwm nodes to pwm-rockchip.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Note for rob+dt:
> A tag was not added on purpose, because by the change of schema
> for clocks and clock-names I add "rockchip,rk3328-pwm" to
> the "if:", so strictly speaking V1 and (V2) V3 will not be the same.
> Please have a look at it again.
> 
> For some SoC nodes this patch serie generates notifications
> for undocumented "interrupts" properties shared between
> PWM channels till there is consensus of what to do with it or
> someone makes a solution for the whole PWM block.
> 
> Changed V3:
>   fix mistake with compatibles introduced in V2
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

Acked-by: Thierry Reding <thierry.reding at gmail.com>
-------------- 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/20210413/42a28ea5/attachment-0001.sig>

From robh at kernel.org  Tue Apr 13 16:22:29 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 10:22:29 -0500
Subject: [PATCH v2 1/3] dt-bindings: gpio: add YAML description for
 rockchip, gpio-bank
In-Reply-To: <20210412223617.8634-1-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
Message-ID: <20210413152229.GA1702359@robh.at.kernel.org>

On Tue, 13 Apr 2021 00:36:15 +0200, Johan Jonker wrote:
> Current dts files with "rockchip,gpio-bank" subnodes
> are manually verified. In order to automate this process
> the text that describes the compatible in rockchip,pinctrl.txt
> is removed and converted to YAML in rockchip,gpio-bank.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Changed V2:
>   changed example gpio nodename
> ---
>  .../bindings/gpio/rockchip,gpio-bank.yaml          | 82 ++++++++++++++++++++++
>  .../bindings/pinctrl/rockchip,pinctrl.txt          | 58 +--------------
>  2 files changed, 83 insertions(+), 57 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From heiko at sntech.de  Tue Apr 13 16:24:09 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 13 Apr 2021 17:24:09 +0200
Subject: [PATCH v3 1/4] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <YHW3DYjr2ifBltVk@orome.fritz.box>
References: <20210412200155.5316-1-jbx6244@gmail.com>
 <YHW3DYjr2ifBltVk@orome.fritz.box>
Message-ID: <9940894.0AQdONaE2F@diego>

Hi Thierry,

Am Dienstag, 13. April 2021, 17:21:49 CEST schrieb Thierry Reding:
> On Mon, Apr 12, 2021 at 10:01:52PM +0200, Johan Jonker wrote:
> > Current dts files with 'pwm' nodes are manually verified.
> > In order to automate this process pwm-rockchip.txt
> > has to be converted to yaml.
> > 
> > Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> > ---
> > For some SoC nodes this patch serie generates notifications
> > for undocumented "interrupts" properties shared between
> > PWM channels till there is consensus of what to do with it or
> > someone makes a solution for the whole PWM block.
> > 
> > Changed V3:
> >   fix mistake with compatibles introduced in V2
> > Changed V2:
> >   changed schema for clocks and clock-names
> > ---
> >  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
> >  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 88 ++++++++++++++++++++++
> >  2 files changed, 88 insertions(+), 27 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
> 
> Heiko, do you want to pick up patches 1 & 2 into your tree along with 3 & 4? If so:
> 
> Acked-by: Thierry Reding <thierry.reding at gmail.com>

however you like :-)

I can pick up everything for 5.14 for sure.

Depending on your tree-schedule for the merge-window, you could also pick
up all 4 with my:

Acked-by: Heiko Stuebner <heiko at sntech.de>


Heiko





From michael at walle.cc  Tue Apr 13 16:33:49 2021
From: michael at walle.cc (Michael Walle)
Date: Tue, 13 Apr 2021 17:33:49 +0200
Subject: [PATCH 2/2] arm64: dts: freescale: sl28: fix RGMII clock and voltage
In-Reply-To: <20210413153349.29119-1-michael@walle.cc>
References: <20210413153349.29119-1-michael@walle.cc>
Message-ID: <20210413153349.29119-3-michael@walle.cc>

During hardware validation it was noticed that the clock isn't
continuously enabled when there is no link. This is because the 125MHz
clock is derived from the internal PLL which seems to go into some kind
of power-down mode every once in a while. The LS1028A expects a contiuous
clock. Thus enable the PLL all the time.

Also, the RGMII pad voltage is wrong, it was configured to 2.5V (that is
the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO
regulator.

This fix is for the freescale/fsl-ls1028a-kontron-sl28-var1.dts.

Fixes: 642856097c18 ("arm64: dts: freescale: sl28: add variant 1")
Signed-off-by: Michael Walle <michael at walle.cc>
---
 .../arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts
index 6c309b97587d..e8d31279b7a3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts
@@ -46,7 +46,8 @@
 			eee-broken-100tx;
 			qca,clk-out-frequency = <125000000>;
 			qca,clk-out-strength = <AR803X_STRENGTH_FULL>;
-			vddio-supply = <&vddh>;
+			qca,keep-pll-enabled;
+			vddio-supply = <&vddio>;
 
 			vddio: vddio-regulator {
 				regulator-name = "VDDIO";
-- 
2.20.1



From michael at walle.cc  Tue Apr 13 16:33:48 2021
From: michael at walle.cc (Michael Walle)
Date: Tue, 13 Apr 2021 17:33:48 +0200
Subject: [PATCH 1/2] arm64: dts: freescale: sl28: fix RGMII clock and voltage
In-Reply-To: <20210413153349.29119-1-michael@walle.cc>
References: <20210413153349.29119-1-michael@walle.cc>
Message-ID: <20210413153349.29119-2-michael@walle.cc>

During hardware validation it was noticed that the clock isn't
continuously enabled when there is no link. This is because the 125MHz
clock is derived from the internal PLL which seems to go into some kind
of power-down mode every once in a while. The LS1028A expects a contiuous
clock. Thus enable the PLL all the time.

Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is
the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO
regulator.

This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts.

Fixes: 815364d0424e ("arm64: dts: freescale: add Kontron sl28 support")
Signed-off-by: Michael Walle <michael at walle.cc>
---
 .../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts     | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
index df212ed5bb94..e65d1c477e2c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
@@ -31,11 +31,10 @@
 			reg = <0x4>;
 			eee-broken-1000t;
 			eee-broken-100tx;
-
 			qca,clk-out-frequency = <125000000>;
 			qca,clk-out-strength = <AR803X_STRENGTH_FULL>;
-
-			vddio-supply = <&vddh>;
+			qca,keep-pll-enabled;
+			vddio-supply = <&vddio>;
 
 			vddio: vddio-regulator {
 				regulator-name = "VDDIO";
-- 
2.20.1



From michael at walle.cc  Tue Apr 13 16:33:47 2021
From: michael at walle.cc (Michael Walle)
Date: Tue, 13 Apr 2021 17:33:47 +0200
Subject: [PATCH 0/2] arm64: dts: freescale: sl28: fix RGMII
Message-ID: <20210413153349.29119-1-michael@walle.cc>

This fixes the RGMII on the sl28 boards. While the network port was
actually working it is still out-of-spec.

Please note, that this is split into two patches because each one fixes
a different commit.

Michael Walle (2):
  arm64: dts: freescale: sl28: fix RGMII clock and voltage
  arm64: dts: freescale: sl28: fix RGMII clock and voltage

 .../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var1.dts     | 3 ++-
 .../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts     | 5 ++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.20.1



From mathieu.poirier at linaro.org  Tue Apr 13 17:19:52 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 10:19:52 -0600
Subject: [GIT PULL] coresight: Fixes for ETE and TRBE
Message-ID: <20210413161952.750262-1-mathieu.poirier@linaro.org>

The following changes since commit 4fb13790417a7bf726f3867a5d2b9723efde488b:

  dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600)

are available in the Git repository at:

  git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE

for you to fetch changes up to 68d400c079978f649e7f63aba966d219743edd64:

  coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() (2021-04-13 09:46:27 -0600)

----------------------------------------------------------------
Hi Marc,

Please consider these two patches, they are ETE/TRBE fixes found by bots.

Let me know if you want me to rebase on your next branch and send the
pull request from that.

Thanks,
Mathieu

----------------------------------------------------------------

Wei Yongjun (2):
      coresight: core: Make symbol 'csdev_sink' static
      coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

 drivers/hwtracing/coresight/coresight-core.c | 2 +-
 drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


From mathieu.poirier at linaro.org  Tue Apr 13 17:22:49 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 10:22:49 -0600
Subject: [PATCH -next v2] coresight: trbe: Fix return value check in
 arm_trbe_register_coresight_cpu()
In-Reply-To: <20210409094901.1903622-1-weiyongjun1@huawei.com>
References: <20210409094901.1903622-1-weiyongjun1@huawei.com>
Message-ID: <20210413162249.GA690529@xps15>

On Fri, Apr 09, 2021 at 09:49:01AM +0000, Wei Yongjun wrote:
> In case of error, the function devm_kasprintf() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
> ---
> v1 -> v2: remove fixes tag.
> ---
>  drivers/hwtracing/coresight/coresight-trbe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

I have picked up both patches.

Thanks,
Mathieu
 
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 5ce239875c98..176868496879 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -871,7 +871,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp
>  
>  	dev = &cpudata->drvdata->pdev->dev;
>  	desc.name = devm_kasprintf(dev, GFP_KERNEL, "trbe%d", cpu);
> -	if (IS_ERR(desc.name))
> +	if (!desc.name)
>  		goto cpu_clear;
>  
>  	desc.type = CORESIGHT_DEV_TYPE_SINK;
> 


From robh at kernel.org  Tue Apr 13 17:28:12 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 11:28:12 -0500
Subject: [PATCH v4 1/4] dt-bindings: pinctrl: mt8195: add pinctrl file
 and binding document
In-Reply-To: <20210413055702.27535-2-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <20210413055702.27535-2-zhiyong.tao@mediatek.com>
Message-ID: <20210413162812.GA1785746@robh.at.kernel.org>

On Tue, 13 Apr 2021 13:56:59 +0800, Zhiyong Tao wrote:
> 1. This patch adds pinctrl file for mt8195.
> 2. This patch adds mt8195 compatible node in binding document.
> 
> Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
> ---
>  .../bindings/pinctrl/pinctrl-mt8195.yaml      | 151 +++
>  include/dt-bindings/pinctrl/mt8195-pinfunc.h  | 962 ++++++++++++++++++
>  2 files changed, 1113 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml
>  create mode 100644 include/dt-bindings/pinctrl/mt8195-pinfunc.h
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 13 17:32:00 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 11:32:00 -0500
Subject: [PATCH v3 29/33] dt-bindings: media: atmel-isc: convert to yaml
In-Reply-To: <20210413105731.610028-30-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
 <20210413105731.610028-30-eugen.hristev@microchip.com>
Message-ID: <20210413163200.GA1791073@robh.at.kernel.org>

On Tue, 13 Apr 2021 13:57:27 +0300, Eugen Hristev wrote:
> Convert the Atmel ISC to yaml binding format.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  .../devicetree/bindings/media/atmel,isc.yaml  | 115 ++++++++++++++++++
>  .../devicetree/bindings/media/atmel-isc.txt   |  65 ----------
>  2 files changed, 115 insertions(+), 65 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml
>  delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 13 17:34:26 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 11:34:26 -0500
Subject: [PATCH v3 30/33] dt-bindings: media: add microchip,xisc device
 bindings
In-Reply-To: <20210413105731.610028-31-eugen.hristev@microchip.com>
References: <20210413105731.610028-1-eugen.hristev@microchip.com>
 <20210413105731.610028-31-eugen.hristev@microchip.com>
Message-ID: <20210413163426.GA1791337@robh.at.kernel.org>

On Tue, Apr 13, 2021 at 01:57:28PM +0300, Eugen Hristev wrote:
> Add bindings for the Microchip eXtended Image Sensor Controller.
> Based on the atmel,isc.yaml binding.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
>  1 file changed, 129 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
> new file mode 100644
> index 000000000000..e3825c4e13f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: GPL-2.0-only

Dual license new bindings:

GPL-2.0-only OR BSD-2-Clause

> +# Copyright (C) 2021 Microchip Technology, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip eXtended Image Sensor Controller (XISC)
> +
> +maintainers:
> +  - Eugen Hristev <eugen.hristev at microchip.com>
> +
> +description:

You need '|' on the end if you want to preserve line breaks.

> +  The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
> +  Microchip AT91 SAM family of devices.
> +
> +  The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
> +  The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
> +  parallel sensor.
> +
> +  The XISC provides one clock output that is used to clock the demuxer/bridge.
> +
> +properties:
> +  compatible:
> +    const: microchip,sama7g5-isc
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: hclock
> +
> +  '#clock-cells':
> +    const: 0
> +
> +  clock-output-names:
> +    const: isc-mck
> +
> +  microchip,mipi-mode:
> +    type: boolean
> +    description:
> +      As the XISC is usually connected to a demux/bridge, the XISC receives
> +      the same type of input, however, it should be aware of the type of
> +      signals received. The mipi-mode enables different internal handling
> +      of the data and clock lines.
> +
> +  port:
> +    $ref: /schemas/graph.yaml#/properties/port
> +    description:
> +      Input port node, single endpoint describing the input pad.
> +
> +    properties:
> +      endpoint:
> +        $ref: video-interfaces.yaml#
> +
> +        properties:
> +          bus-type:
> +            enum: [5, 6]
> +
> +          remote-endpoint: true
> +
> +          bus-width:
> +            enum: [8, 9, 10, 11, 12]
> +            default: 12
> +
> +          hsync-active:
> +            enum: [0, 1]
> +            default: 1
> +
> +          vsync-active:
> +            enum: [0, 1]
> +            default: 1
> +
> +          pclk-sample:
> +            enum: [0, 1]
> +            default: 1
> +
> +        required:
> +          - remote-endpoint
> +          - bus-type
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - '#clock-cells'
> +  - clock-output-names
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/clock/at91.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +
> +    xisc: xisc at e1408000 {
> +        compatible = "microchip,sama7g5-isc";
> +        reg = <0xe1408000 0x2000>;
> +        interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
> +        clock-names = "hclock";
> +        #clock-cells = <0>;
> +        clock-output-names = "isc-mck";
> +
> +        port {
> +                xisc_in: endpoint {
> +                       bus-type = <5>; /* Parallel */
> +                       remote-endpoint = <&csi2dc_out>;
> +                       hsync-active = <1>;
> +                       vsync-active = <1>;
> +                       bus-width = <12>;
> +                };
> +        };
> +    };
> +
> -- 
> 2.25.1
> 


From john.garry at huawei.com  Tue Apr 13 17:37:19 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 13 Apr 2021 17:37:19 +0100
Subject: [PATCH v2 1/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <b45b5443-b0a4-3e7b-7ba6-be18eb413cba@huawei.com>
References: <1617959157-22956-1-git-send-email-liuqi115@huawei.com>
 <1617959157-22956-2-git-send-email-liuqi115@huawei.com>
 <4cae4206-aa50-f111-2f6f-d035bc36856e@huawei.com>
 <9c577f11-46e7-55a0-95e8-6c3376077049@huawei.com>
 <fb795e51-ce01-e976-ac09-d3f384307623@huawei.com>
 <b45b5443-b0a4-3e7b-7ba6-be18eb413cba@huawei.com>
Message-ID: <60dffcdf-f5a5-b533-2474-ba44580191a9@huawei.com>

On 13/04/2021 10:12, liuqi (BA) wrote:
>>>>
>>>> I do wonder why we even need maintain pcie_pmu->cpumask
>>>>
>>>> Can't we just use cpu_online_mask as appropiate instead?
>>
>> ?
> Sorry, missed it yesterday.
> It seems that cpumask is always same as cpu_online_mask, So do we need 
> to reserve the cpumask sysfs interface?

I'm not saying that we don't require the cpumask sysfs interface. I am 
just asking why you maintain a separate cpumask, when, as I said, they 
seem the same.

Thanks,
John


From maz at kernel.org  Tue Apr 13 17:52:34 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 13 Apr 2021 17:52:34 +0100
Subject: [GIT PULL] coresight: Fixes for ETE and TRBE
In-Reply-To: <20210413161952.750262-1-mathieu.poirier@linaro.org>
References: <20210413161952.750262-1-mathieu.poirier@linaro.org>
Message-ID: <87sg3um8j1.wl-maz@kernel.org>

Hi Mathieu,

On Tue, 13 Apr 2021 17:19:52 +0100,
Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> 
> The following changes since commit 4fb13790417a7bf726f3867a5d2b9723efde488b:
> 
>   dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600)
> 
> are available in the Git repository at:
> 
>   git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE
> 
> for you to fetch changes up to 68d400c079978f649e7f63aba966d219743edd64:
> 
>   coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() (2021-04-13 09:46:27 -0600)
> 
> ----------------------------------------------------------------
> Hi Marc,
> 
> Please consider these two patches, they are ETE/TRBE fixes found by bots.
> 
> Let me know if you want me to rebase on your next branch and send the
> pull request from that.

I've now pulled this into kvmarm/next. If you have additional fixes,
just stick them on top of your next-ETE-TRBE branch like you did with
these two patches.

The kvmarm/next branch gets rebuilt every other day, so it isn't a
stable branch on its own. Only the non-merge commits are stable, which
is why I keep everything on topic branches.

Thanks,

	M.

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


From liam.howlett at oracle.com  Tue Apr 13 17:52:34 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Tue, 13 Apr 2021 16:52:34 +0000
Subject: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in
 traps for setting si_code
In-Reply-To: <20210412174343.GG2060@arm.com>
References: <20210407150940.542103-1-Liam.Howlett@Oracle.com>
 <20210412174343.GG2060@arm.com>
Message-ID: <20210413143035.7zrct6a3up42uaoo@revolver>

* Catalin Marinas <catalin.marinas at arm.com> [210412 13:44]:
> On Wed, Apr 07, 2021 at 03:11:06PM +0000, Liam Howlett wrote:
> > find_vma() will continue to search upwards until the end of the virtual
> > memory space.  This means the si_code would almost never be set to
> > SEGV_MAPERR even when the address falls outside of any VMA.  The result
> > is that the si_code is not reliable as it may or may not be set to the
> > correct result, depending on where the address falls in the address
> > space.
> > 
> > Using find_vma_intersection() allows for what is intended by only
> > returning a VMA if it falls within the range provided, in this case a
> > window of 1.
> > 
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > ---
> >  arch/arm64/kernel/traps.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index a05d34f0e82a..a44007904a64 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
> >  void arm64_notify_segfault(unsigned long addr)
> >  {
> >  	int code;
> > +	unsigned long ut_addr = untagged_addr(addr);
> >  
> >  	mmap_read_lock(current->mm);
> > -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> > +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
> >  		code = SEGV_MAPERR;
> >  	else
> >  		code = SEGV_ACCERR;


Thank you for taking the time to thoroughly review this patch.

> 
> I don't think your change is entirely correct either. We can have a
> fault below the vma of a stack (with VM_GROWSDOWN) and
> find_vma_intersection() would return NULL but it should be a SEGV_ACCERR
> instead.

I'm pretty sure I am missing something.  From what you said above, I
think this means that there can be a user cache fault below the stack
which should notify the user application that they are not allowed to
expand the stack by sending a SIGV_ACCERR in the si_code?  Is this
expected behaviour or am I missing a code path to this function?

> 
> Maybe this should employ similar checks as __do_page_fault() (with
> expand_stack() and VM_GROWSDOWN).

You mean the code needs to detect endianness and to check if this is an
attempt to expand the stack for both cases?

Thanks,
Liam

From mathieu.poirier at linaro.org  Tue Apr 13 17:55:00 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 10:55:00 -0600
Subject: [PATCH V3 2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
 support
In-Reply-To: <1617846898-13662-3-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-3-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413165500.GA750651@xps15>

On Thu, Apr 08, 2021 at 09:54:52AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add i.MX7ULP compatible.
> 
> We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
> control of M4 core, M4 core starts by ROM and powers most serivces used

s/serivces/services

> by A7 core, so A7 core has no power to start and stop M4 core. So
> clocks and syscon are not required.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> Acked-by: Rob Herring <robh at kernel.org>
> ---
>  .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml          | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index b13bf8d70488..58bc2a23f97b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> @@ -18,6 +18,7 @@ properties:
>        - fsl,imx8mq-cm4
>        - fsl,imx8mm-cm4
>        - fsl,imx7d-cm4
> +      - fsl,imx7ulp-cm4
>        - fsl,imx6sx-cm4
>  
>    clocks:
> @@ -57,8 +58,6 @@ properties:
>  
>  required:
>    - compatible
> -  - clocks
> -  - syscon
>  
>  additionalProperties: false
>  
> -- 
> 2.30.0
> 


From nm at ti.com  Tue Apr 13 18:12:30 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 13 Apr 2021 12:12:30 -0500
Subject: [PATCH] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
Message-ID: <20210413171230.5872-1-nm@ti.com>

Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
  tisci node definition
- Switched reg usage for address-cells and size-cells 1 - aligned with
  schema checks as well
- included header in example for buildable example

NOTE: The following warning is generated since we do include the header
in the example, but this is a false positive warning.
  WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/mailbox/ti,secure-proxy.txt      | 50 -------------
 .../bindings/mailbox/ti,secure-proxy.yaml     | 72 +++++++++++++++++++
 2 files changed, 72 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..000000000000
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-========================================
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===========================
-Required properties:
---------------------
-- compatible:		Shall be "ti,am654-secure-proxy"
-- reg-names 		target_data - Map the proxy data region
-			rt - Map the realtime status region
-			scfg - Map the configuration region
-- reg:			Contains the register map per reg-names.
-- #mbox-cells		Shall be 1 and shall refer to the transfer path
-			called thread.
-- interrupt-names:	Contains interrupt names matching the rx transfer path
-			for a given SoC. Receive interrupts shall be of the
-			format: "rx_<PID>".
-- interrupts:		Contains the interrupt information corresponding to
-			interrupt-names property.
-
-Example(AM654):
-------------
-
-	secure_proxy: mailbox at 32c00000 {
-		compatible = "ti,am654-secure-proxy";
-		#mbox-cells = <1>;
-		reg-names = "target_data", "rt", "scfg";
-		reg = <0x0 0x32c00000 0x0 0x100000>,
-		      <0x0 0x32400000 0x0 0x100000>,
-		      <0x0 0x32800000 0x0 0x100000>;
-		interrupt-names = "rx_011";
-		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-	};
-
-	dmsc: dmsc {
-		[...]
-		mbox-names = "rx", "tx";
-		# RX Thread ID is 11
-		# TX Thread ID is 13
-		mboxes= <&secure_proxy 11>,
-			<&secure_proxy 13>;
-		[...]
-	};
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index 000000000000..88eb32cb5678
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  The Texas Instruments' secure proxy is a mailbox controller that has
+  configurable queues selectable at SoC(System on Chip) integration. The
+  Message manager is broken up into different address regions that are
+  called "threads" or "proxies" - each instance is unidirectional and is
+  instantiated at SoC integration level by system controller to indicate
+  receive or transmit path.
+
+properties:
+  $nodename:
+    pattern: "^mailbox@[0-9a-f]+$"
+
+  compatible:
+    const: ti,am654-secure-proxy
+
+  "#mbox-cells":
+    const: 1
+
+  reg-names:
+    items:
+      - const: target_data
+      - const: rt
+      - const: scfg
+
+  reg:
+    minItems: 3
+
+  interrupt-names:
+    minItems: 1
+    description:
+      Contains the interrupt name information for the Rx interrupt path for
+      secure proxy.
+
+  interrupts:
+    minItems: 1
+    description:
+      Contains the interrupt information for the Rx interrupt path for secure
+      proxy.
+
+required:
+  - compatible
+  - reg-names
+  - reg
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    secure_proxy: mailbox at 32c00000 {
+          compatible = "ti,am654-secure-proxy";
+          #mbox-cells = <1>;
+          reg-names = "target_data", "rt", "scfg";
+          reg = <0x32c00000 0x100000>,
+                <0x32400000 0x100000>,
+                <0x32800000 0x100000>;
+          interrupt-names = "rx_011";
+          interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+    };
-- 
2.31.0



From mathieu.poirier at linaro.org  Tue Apr 13 18:28:17 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 11:28:17 -0600
Subject: [PATCH V3 4/8] remoteproc: imx_rproc: make clk optional
In-Reply-To: <1617846898-13662-5-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-5-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413172817.GB750651@xps15>

On Thu, Apr 08, 2021 at 09:54:54AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> To i.MX7ULP, M4 is the master to control everything, so it not need
> clk from A7.
> 
> Reviewed-by: Richard Zhu <hongxing.zhu at nxp.com>
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index d6338872c6db..ca17f520d904 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -635,7 +635,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto err_put_mbox;
>  
> -	priv->clk = devm_clk_get(dev, NULL);
> +	priv->clk = devm_clk_get_optional(dev, NULL);

Overnight the clock becomes optional for all remote processors?  Why not call
devm_clk_get() or devm_clk_get_optional() based on the remote processor type in
a new function called imx_rproc_clk_get()?

>  	if (IS_ERR(priv->clk)) {
>  		dev_err(dev, "Failed to get clock\n");
>  		ret = PTR_ERR(priv->clk);
> -- 
> 2.30.0
> 


From mathieu.poirier at linaro.org  Tue Apr 13 18:31:13 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 11:31:13 -0600
Subject: [PATCH V3 5/8] remoteproc: imx_rproc: parse fsl,auto-boot
In-Reply-To: <1617846898-13662-6-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-6-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413173113.GC750651@xps15>

On Thu, Apr 08, 2021 at 09:54:55AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Parse fsl,auto-boot to indicate whether need remoteproc framework
> auto boot or not.
> 
> When remote processor is booted before Linux Kernel up, do not parse
> fsl,auto-boot. So add an entry to store the working mode of remote
> processor. Currently only IMX_RPROC_NORMAL, IMX_RPROC_EARLY_BOOT.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index ca17f520d904..c576e12d3817 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -83,6 +83,16 @@ struct imx_rproc_dcfg {
>  	size_t				att_size;
>  };
>  
> +enum imx_rproc_mode {
> +	/* Linux load/kick remote core */
> +	IMX_RPROC_NORMAL,
> +	/*
> +	 * remote core booted before kicking Linux, and remote core
> +	 * could be stopped & restarted by Linux
> +	 */
> +	IMX_RPROC_EARLY_BOOT,
> +};
> +

As far as I can see a new mode to track the state of the remote processor is not
needed.  rproc->state can do that for you.

>  struct imx_rproc {
>  	struct device			*dev;
>  	struct regmap			*regmap;
> @@ -96,6 +106,7 @@ struct imx_rproc {
>  	struct work_struct		rproc_work;
>  	struct workqueue_struct		*workqueue;
>  	void __iomem			*rsc_table;
> +	enum imx_rproc_mode		mode;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> @@ -565,14 +576,18 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  	int ret;
>  	u32 val;
>  
> +	priv->mode = IMX_RPROC_NORMAL;
> +
>  	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
>  	if (ret) {
>  		dev_err(dev, "Failed to read src\n");
>  		return ret;
>  	}
>  
> -	if (!(val & dcfg->src_stop))
> +	if (!(val & dcfg->src_stop)) {
> +		priv->mode = IMX_RPROC_EARLY_BOOT;
>  		priv->rproc->state = RPROC_DETACHED;
> +	}
>  
>  	return 0;
>  }
> @@ -654,6 +669,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  
>  	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
>  
> +	if (priv->mode == IMX_RPROC_NORMAL)
> +		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
> +

        if (rproc->state == RPROC_DETACHED)

>  	ret = rproc_add(rproc);
>  	if (ret) {
>  		dev_err(dev, "rproc_add failed\n");
> -- 
> 2.30.0
> 


From erwan.leray at foss.st.com  Tue Apr 13 18:40:15 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 13 Apr 2021 19:40:15 +0200
Subject: [PATCH v2 4/4] serial: stm32: add FIFO threshold configuration
In-Reply-To: <20210413174015.23011-1-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
Message-ID: <20210413174015.23011-5-erwan.leray@foss.st.com>

From: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Add the support for two optional DT properties, to configure RX and TX
FIFO thresholds:
- rx-threshold
- tx-threshold
This replaces hard-coded 8 bytes threshold. Keep 8 as the default value if
not specified, for backward compatibility.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>

Changes in v2:
Change added properties naming as proposed by Rob Herring.

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 4d277804c63e..409cfd15a933 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -312,7 +312,7 @@ static void stm32_usart_tx_interrupt_enable(struct uart_port *port)
 	 * Enables TX FIFO threashold irq when FIFO is enabled,
 	 * or TX empty irq when FIFO is disabled
 	 */
-	if (stm32_port->fifoen)
+	if (stm32_port->fifoen && stm32_port->txftcfg >= 0)
 		stm32_usart_set_bits(port, ofs->cr3, USART_CR3_TXFTIE);
 	else
 		stm32_usart_set_bits(port, ofs->cr1, USART_CR1_TXEIE);
@@ -323,7 +323,7 @@ static void stm32_usart_tx_interrupt_disable(struct uart_port *port)
 	struct stm32_port *stm32_port = to_stm32_port(port);
 	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
 
-	if (stm32_port->fifoen)
+	if (stm32_port->fifoen && stm32_port->txftcfg >= 0)
 		stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_TXFTIE);
 	else
 		stm32_usart_clr_bits(port, ofs->cr1, USART_CR1_TXEIE);
@@ -801,9 +801,10 @@ static void stm32_usart_set_termios(struct uart_port *port,
 	cr3 = readl_relaxed(port->membase + ofs->cr3);
 	cr3 &= USART_CR3_TXFTIE | USART_CR3_RXFTIE;
 	if (stm32_port->fifoen) {
-		cr3 &= ~(USART_CR3_TXFTCFG_MASK | USART_CR3_RXFTCFG_MASK);
-		cr3 |= USART_CR3_TXFTCFG_HALF << USART_CR3_TXFTCFG_SHIFT;
-		cr3 |= USART_CR3_RXFTCFG_HALF << USART_CR3_RXFTCFG_SHIFT;
+		if (stm32_port->txftcfg >= 0)
+			cr3 |= stm32_port->txftcfg << USART_CR3_TXFTCFG_SHIFT;
+		if (stm32_port->rxftcfg >= 0)
+			cr3 |= stm32_port->rxftcfg << USART_CR3_RXFTCFG_SHIFT;
 	}
 
 	if (cflag & CSTOPB)
@@ -833,7 +834,8 @@ static void stm32_usart_set_termios(struct uart_port *port,
 			, bits);
 
 	if (ofs->rtor != UNDEF_REG && (stm32_port->rx_ch ||
-				       stm32_port->fifoen)) {
+				       (stm32_port->fifoen &&
+					stm32_port->rxftcfg >= 0))) {
 		if (cflag & CSTOPB)
 			bits = bits + 3; /* 1 start bit + 2 stop bits */
 		else
@@ -1021,6 +1023,39 @@ static const struct uart_ops stm32_uart_ops = {
 	.verify_port	= stm32_usart_verify_port,
 };
 
+/*
+ * STM32H7 RX & TX FIFO threshold configuration (CR3 RXFTCFG / TXFTCFG)
+ * Note: 1 isn't a valid value in RXFTCFG / TXFTCFG. In this case,
+ * RXNEIE / TXEIE can be used instead of threshold irqs: RXFTIE / TXFTIE.
+ * So, RXFTCFG / TXFTCFG bitfields values are encoded as array index + 1.
+ */
+static const u32 stm32h7_usart_fifo_thresh_cfg[] = { 1, 2, 4, 8, 12, 14, 16 };
+
+static void stm32_usart_get_ftcfg(struct platform_device *pdev, const char *p,
+				  int *ftcfg)
+{
+	u32 bytes, i;
+
+	/* DT option to get RX & TX FIFO threshold (default to 8 bytes) */
+	if (of_property_read_u32(pdev->dev.of_node, p, &bytes))
+		bytes = 8;
+
+	for (i = 0; i < ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg); i++)
+		if (stm32h7_usart_fifo_thresh_cfg[i] >= bytes)
+			break;
+	if (i >= ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg))
+		i = ARRAY_SIZE(stm32h7_usart_fifo_thresh_cfg) - 1;
+
+	dev_dbg(&pdev->dev, "%s set to %d bytes\n", p,
+		stm32h7_usart_fifo_thresh_cfg[i]);
+
+	/* Provide FIFO threshold ftcfg (1 is invalid: threshold irq unused) */
+	if (i)
+		*ftcfg = i - 1;
+	else
+		*ftcfg = -EINVAL;
+}
+
 static void stm32_usart_deinit_port(struct stm32_port *stm32port)
 {
 	clk_disable_unprepare(stm32port->clk);
@@ -1057,6 +1092,12 @@ static int stm32_usart_init_port(struct stm32_port *stm32port,
 		of_property_read_bool(pdev->dev.of_node, "rx-tx-swap");
 
 	stm32port->fifoen = stm32port->info->cfg.has_fifo;
+	if (stm32port->fifoen) {
+		stm32_usart_get_ftcfg(pdev, "rx-threshold",
+				      &stm32port->rxftcfg);
+		stm32_usart_get_ftcfg(pdev, "tx-threshold",
+				      &stm32port->txftcfg);
+	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	port->membase = devm_ioremap_resource(&pdev->dev, res);
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 77d1ac082e89..07ac291328cd 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -216,12 +216,6 @@ struct stm32_usart_info stm32h7_info = {
 #define USART_CR3_TXFTCFG_MASK	GENMASK(31, 29)	/* H7 */
 #define USART_CR3_TXFTCFG_SHIFT	29		/* H7 */
 
-/* TX FIFO threashold set to half of its depth */
-#define USART_CR3_TXFTCFG_HALF	0x2
-
-/* RX FIFO threashold set to half of its depth */
-#define USART_CR3_RXFTCFG_HALF	0x2
-
 /* USART_GTPR */
 #define USART_GTPR_PSC_MASK	GENMASK(7, 0)
 #define USART_GTPR_GT_MASK	GENMASK(15, 8)
@@ -273,6 +267,8 @@ struct stm32_port {
 	bool hw_flow_control;
 	bool swap;		 /* swap RX & TX pins */
 	bool fifoen;
+	int rxftcfg;		/* RX FIFO threshold CFG      */
+	int txftcfg;		/* TX FIFO threshold CFG      */
 	bool wakeup_src;
 	int rdr_mask;		/* receive data register mask */
 	struct mctrl_gpios *gpios; /* modem control gpios */
-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr 13 18:40:13 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 13 Apr 2021 19:40:13 +0200
Subject: [PATCH v2 2/4] dt-bindings: serial: stm32: override FIFO threshold
 properties
In-Reply-To: <20210413174015.23011-1-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
Message-ID: <20210413174015.23011-3-erwan.leray@foss.st.com>

Override rx-threshold and tx-threshold properties:
- extend description
- provide default and expected values

Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>

Changes in v2:
Change added properties naming and factorize it in serial.yaml as proposed
by Rob Herring.

diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index c69f8464cdf3..71a6426bc558 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -65,6 +65,18 @@ properties:
   linux,rs485-enabled-at-boot-time: true
   rs485-rx-during-tx: true
 
+  rx-threshold:
+    description:
+      If value is set to 1, RX FIFO threshold is disabled.
+    enum: [1, 2, 4, 8, 12, 14, 16]
+    default: 8
+
+  tx-threshold:
+    description:
+      If value is set to 1, TX FIFO threshold is disabled.
+    enum: [1, 2, 4, 8, 12, 14, 16]
+    default: 8
+
 allOf:
   - $ref: rs485.yaml#
   - $ref: serial.yaml#
@@ -82,6 +94,17 @@ allOf:
     then:
       properties:
         rx-tx-swap: false
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - st,stm32-uart
+              - st,stm32f7-uart
+    then:
+      properties:
+        rx-threshold: false
+        tx-threshold: false
 
 required:
   - compatible
@@ -96,13 +119,15 @@ examples:
   - |
     #include <dt-bindings/clock/stm32mp1-clks.h>
     usart1: serial at 40011000 {
-      compatible = "st,stm32-uart";
+      compatible = "st,stm32h7-uart";
       reg = <0x40011000 0x400>;
       interrupts = <37>;
       clocks = <&rcc 0 164>;
       dmas = <&dma2 2 4 0x414 0x0>,
              <&dma2 7 4 0x414 0x0>;
       dma-names = "rx", "tx";
+      rx-threshold = <4>;
+      tx-threshold = <4>;
       rs485-rts-active-low;
     };
 
-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr 13 18:40:11 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 13 Apr 2021 19:40:11 +0200
Subject: [PATCH v2 0/4] stm32 usart add fifo threshold configuration
Message-ID: <20210413174015.23011-1-erwan.leray@foss.st.com>

This series adds the support for two optional DT properties to configure
RX and TX FIFO thresholds:
 - rx-threshold
 - tx-threshold
This replaces hard-coded 8 bytes threshold. No functional change expected
if unspecified (keep 8 as default).

Changes in v2:
Change added properties naming and factorize it in serial.yaml as proposed
by Rob Herring. 

Erwan Le Ray (3):
  dt-bindings: serial: add RX and TX FIFO properties
  dt-bindings: serial: stm32: override FIFO threshold properties
  dt-bindings: serial: 8250: update TX FIFO trigger level

Fabrice Gasnier (1):
  serial: stm32: add FIFO threshold configuration

 .../devicetree/bindings/serial/8250.yaml      |  1 -
 .../devicetree/bindings/serial/serial.yaml    | 10 ++++
 .../bindings/serial/st,stm32-uart.yaml        | 27 +++++++++-
 drivers/tty/serial/stm32-usart.c              | 53 ++++++++++++++++---
 drivers/tty/serial/stm32-usart.h              |  8 +--
 5 files changed, 85 insertions(+), 14 deletions(-)

-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr 13 18:40:14 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 13 Apr 2021 19:40:14 +0200
Subject: [PATCH v2 3/4] dt-bindings: serial: 8250: update TX FIFO trigger level
In-Reply-To: <20210413174015.23011-1-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
Message-ID: <20210413174015.23011-4-erwan.leray@foss.st.com>

Remove data type from tx-threshold trigger level as defined now as a
serial generic property.

Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index c0e292cdaa6b..ff0fa9b2a390 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -166,7 +166,6 @@ properties:
       property.
 
   tx-threshold:
-    $ref: /schemas/types.yaml#/definitions/uint32
     description: |
       Specify the TX FIFO low water indication for parts with programmable
       TX FIFO thresholds.
-- 
2.17.1



From erwan.leray at foss.st.com  Tue Apr 13 18:40:12 2021
From: erwan.leray at foss.st.com (Erwan Le Ray)
Date: Tue, 13 Apr 2021 19:40:12 +0200
Subject: [PATCH v2 1/4] dt-bindings: serial: add RX and TX FIFO properties
In-Reply-To: <20210413174015.23011-1-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
Message-ID: <20210413174015.23011-2-erwan.leray@foss.st.com>

Add two optional DT properties to configure RX and TX FIFO thresholds:
- rx-threshold
- tx-threshold

Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>

diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml
index 65e75d040521..f368d58e8086 100644
--- a/Documentation/devicetree/bindings/serial/serial.yaml
+++ b/Documentation/devicetree/bindings/serial/serial.yaml
@@ -75,6 +75,16 @@ properties:
     type: boolean
     description: CTS and RTS pins are swapped.
 
+  rx-threshold:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      RX FIFO threshold configuration (in bytes).
+
+  tx-threshold:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      TX FIFO threshold configuration (in bytes).
+
 if:
   required:
     - uart-has-rtscts
-- 
2.17.1



From mathieu.poirier at linaro.org  Tue Apr 13 18:45:45 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 11:45:45 -0600
Subject: [PATCH V3 6/8] remoteproc: imx_rproc: initial support for
 mutilple start/stop method
In-Reply-To: <1617846898-13662-7-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-7-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413174545.GD750651@xps15>

On Thu, Apr 08, 2021 at 09:54:56AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
> (start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).
> 
> The current SoCs supported are all using IMX_RPROC_MMIO, add a restrict
> in probe that only SoCs using IMX_RPROC_MMIO needs syscon regmap to
> access registers.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 50 +++++++++++++++++++++++-----------
>  1 file changed, 34 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index c576e12d3817..a7fa9d7fc2d1 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -74,6 +74,15 @@ struct imx_rproc_att {
>  	int flags;
>  };
>  
> +/* Remote core start/stop method */
> +enum imx_rproc_method {
> +	IMX_RPROC_NONE,
> +	/* Through syscon regmap */
> +	IMX_RPROC_MMIO,
> +	/* Through ARM SMCCC */
> +	IMX_RPROC_SMC,
> +};
> +
>  struct imx_rproc_dcfg {
>  	u32				src_reg;
>  	u32				src_mask;
> @@ -81,6 +90,7 @@ struct imx_rproc_dcfg {
>  	u32				src_stop;
>  	const struct imx_rproc_att	*att;
>  	size_t				att_size;
> +	enum imx_rproc_method		method;
>  };
>  
>  enum imx_rproc_mode {
> @@ -194,6 +204,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
>  	.src_stop	= IMX7D_M4_STOP,
>  	.att		= imx_rproc_att_imx8mq,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mq),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
> @@ -203,6 +214,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
>  	.src_stop	= IMX7D_M4_STOP,
>  	.att		= imx_rproc_att_imx7d,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7d),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
> @@ -212,6 +224,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
>  	.src_stop	= IMX6SX_M4_STOP,
>  	.att		= imx_rproc_att_imx6sx,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx6sx),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static int imx_rproc_start(struct rproc *rproc)
> @@ -578,15 +591,17 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  
>  	priv->mode = IMX_RPROC_NORMAL;
>  
> -	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
> -	if (ret) {
> -		dev_err(dev, "Failed to read src\n");
> -		return ret;
> -	}
> +	if (priv->regmap) {
> +		ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
> +		if (ret) {
> +			dev_err(dev, "Failed to read src\n");
> +			return ret;
> +		}
>  
> -	if (!(val & dcfg->src_stop)) {
> -		priv->mode = IMX_RPROC_EARLY_BOOT;
> -		priv->rproc->state = RPROC_DETACHED;
> +		if (!(val & dcfg->src_stop)) {
> +			priv->rproc->state = RPROC_DETACHED;
> +			priv->mode = IMX_RPROC_EARLY_BOOT;
> +		}
>  	}
>  
>  	return 0;
> @@ -600,16 +615,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  	struct rproc *rproc;
>  	struct regmap_config config = { .name = "imx-rproc" };
>  	const struct imx_rproc_dcfg *dcfg;
> -	struct regmap *regmap;
> +	struct regmap *regmap = NULL;
>  	int ret;
>  
> -	regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
> -	if (IS_ERR(regmap)) {
> -		dev_err(dev, "failed to find syscon\n");
> -		return PTR_ERR(regmap);
> -	}
> -	regmap_attach_dev(dev, regmap, &config);
> -
>  	/* set some other name then imx */
>  	rproc = rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
>  			    NULL, sizeof(*priv));
> @@ -622,6 +630,16 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  		goto err_put_rproc;
>  	}
>  
> +	if (dcfg->method == IMX_RPROC_MMIO) {
> +		regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
> +		if (IS_ERR(regmap)) {
> +			dev_err(dev, "failed to find syscon\n");
> +			ret = PTR_ERR(regmap);
> +			goto err_put_rproc;
> +		}
> +		regmap_attach_dev(dev, regmap, &config);
> +	}

I would move this to imx_rproc_detect_mode() and get rid of the "if
(priv->regmap)" that is there.

> +
>  	priv = rproc->priv;
>  	priv->rproc = rproc;
>  	priv->regmap = regmap;
> -- 
> 2.30.0
> 


From will at kernel.org  Tue Apr 13 18:49:22 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 13 Apr 2021 18:49:22 +0100
Subject: [PATCH] arm64: kprobes: Restore local irqflag if kprobes is
 cancelled
In-Reply-To: <20210412174101.6bfb0594@xhacker.debian>
References: <20210412174101.6bfb0594@xhacker.debian>
Message-ID: <161830261625.3702418.8292373763983690459.b4-ty@kernel.org>

On Mon, 12 Apr 2021 17:41:01 +0800, Jisheng Zhang wrote:
> If instruction being single stepped caused a page fault, the kprobes
> is cancelled to let the page fault handler continue as a normal page
> fault. But the local irqflags are disabled so cpu will restore pstate
> with DAIF masked. After pagefault is serviced, the kprobes is
> triggerred again, we overwrite the saved_irqflag by calling
> kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
> irqflag. After kprobes is serviced, the cpu pstate is retored with
> DAIF masked.
> 
> [...]

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64: kprobes: Restore local irqflag if kprobes is cancelled
      https://git.kernel.org/arm64/c/738fa58ee132

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev


From mathieu.poirier at linaro.org  Tue Apr 13 18:49:32 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 11:49:32 -0600
Subject: [PATCH V3 7/8] remoteproc: imx_rproc: support i.MX7ULP
In-Reply-To: <1617846898-13662-8-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-8-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413174932.GE750651@xps15>

On Thu, Apr 08, 2021 at 09:54:57AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
> and powers most serivces used by A7 core, so A7 core has no power to
> start and stop M4 core.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index a7fa9d7fc2d1..b911a7539897 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -147,6 +147,14 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
>  	{ 0x40000000, 0x40000000, 0x80000000, 0 },
>  };
>  
> +static const struct imx_rproc_att imx_rproc_att_imx7ulp[] = {
> +	{0x1FFD0000, 0x1FFD0000, 0x30000, ATT_OWN},
> +	{0x20000000, 0x20000000, 0x10000, ATT_OWN},
> +	{0x2F000000, 0x2F000000, 0x20000, ATT_OWN},
> +	{0x2F020000, 0x2F020000, 0x20000, ATT_OWN},
> +	{0x60000000, 0x60000000, 0x40000000, 0}
> +};
> +
>  static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
>  	/* dev addr , sys addr  , size	    , flags */
>  	/* OCRAM_S (M4 Boot code) - alias */
> @@ -207,6 +215,12 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
>  	.method		= IMX_RPROC_MMIO,
>  };
>  
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx7ulp = {
> +	.att		= imx_rproc_att_imx7ulp,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7ulp),
> +	.method		= IMX_RPROC_NONE,
> +};
> +
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
>  	.src_reg	= IMX7D_SRC_SCR,
>  	.src_mask	= IMX7D_M4_RST_MASK,
> @@ -598,12 +612,16 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  			return ret;
>  		}
>  
> -		if (!(val & dcfg->src_stop)) {
> -			priv->rproc->state = RPROC_DETACHED;
> +		if (!(val & dcfg->src_stop))
>  			priv->mode = IMX_RPROC_EARLY_BOOT;
> -		}
>  	}
>  
> +	if (dcfg->method == IMX_RPROC_NONE)
> +		priv->mode = IMX_RPROC_EARLY_BOOT;

As I pointed out there is no need for priv->mode.  Just declare a boolean
variable that is local to this function and use it to determine the state of the
remote processor:

        if (dcfg->method == IMX_RPROC_NONE)
                early_boot = true;

        if (early_boot)
                priv->rproc->state = RPROC_DETACHED;

> +
> +	if (priv->mode == IMX_RPROC_EARLY_BOOT)
> +		priv->rproc->state = RPROC_DETACHED;
> +
>  	return 0;
>  }
>  
> @@ -724,6 +742,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id imx_rproc_of_match[] = {
> +	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
>  	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
>  	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
>  	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
> -- 
> 2.30.0
> 


From mathieu.poirier at linaro.org  Tue Apr 13 18:52:35 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 11:52:35 -0600
Subject: [PATCH V3 8/8] remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1617846898-13662-9-git-send-email-peng.fan@oss.nxp.com>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-9-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210413175235.GF750651@xps15>

On Thu, Apr 08, 2021 at 09:54:58AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
> SMCCC to start/stop M core, not using regmap interface.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 89 +++++++++++++++++++++++++++++++---
>  1 file changed, 82 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index b911a7539897..9351626f09c0 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -3,6 +3,7 @@
>   * Copyright (c) 2017 Pengutronix, Oleksij Rempel <kernel at pengutronix.de>
>   */
>  
> +#include <linux/arm-smccc.h>
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/interrupt.h>
> @@ -50,6 +51,11 @@
>  
>  #define IMX_RPROC_MEM_MAX		32
>  
> +#define IMX_SIP_RPROC			0xC2000005
> +#define IMX_SIP_RPROC_START		0x00
> +#define IMX_SIP_RPROC_STARTED		0x01
> +#define IMX_SIP_RPROC_STOP		0x02
> +
>  /**
>   * struct imx_rproc_mem - slim internal memory structure
>   * @cpu_addr: MPU virtual address of the memory region
> @@ -119,6 +125,36 @@ struct imx_rproc {
>  	enum imx_rproc_mode		mode;
>  };
>  
> +static const struct imx_rproc_att imx_rproc_att_imx8mn[] = {
> +	/* dev addr , sys addr  , size	    , flags */
> +	/* ITCM   */
> +	{ 0x00000000, 0x007E0000, 0x00020000, ATT_OWN },
> +	/* OCRAM_S */
> +	{ 0x00180000, 0x00180000, 0x00009000, 0 },
> +	/* OCRAM */
> +	{ 0x00900000, 0x00900000, 0x00020000, 0 },
> +	/* OCRAM */
> +	{ 0x00920000, 0x00920000, 0x00020000, 0 },
> +	/* OCRAM */
> +	{ 0x00940000, 0x00940000, 0x00050000, 0 },
> +	/* QSPI Code - alias */
> +	{ 0x08000000, 0x08000000, 0x08000000, 0 },
> +	/* DDR (Code) - alias */
> +	{ 0x10000000, 0x40000000, 0x0FFE0000, 0 },
> +	/* DTCM */
> +	{ 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
> +	/* OCRAM_S - alias */
> +	{ 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
> +	/* OCRAM */
> +	{ 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
> +	/* OCRAM */
> +	{ 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
> +	/* OCRAM */
> +	{ 0x20240000, 0x00940000, 0x00040000, ATT_OWN },
> +	/* DDR (Data) */
> +	{ 0x40000000, 0x40000000, 0x80000000, 0 },
> +};
> +
>  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
>  	/* dev addr , sys addr  , size	    , flags */
>  	/* TCML - alias */
> @@ -205,6 +241,12 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
>  	{ 0x80000000, 0x80000000, 0x60000000, 0 },
>  };
>  
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn = {
> +	.att		= imx_rproc_att_imx8mn,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mn),
> +	.method		= IMX_RPROC_SMC,
> +};
> +
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
>  	.src_reg	= IMX7D_SRC_SCR,
>  	.src_mask	= IMX7D_M4_RST_MASK,
> @@ -246,12 +288,24 @@ static int imx_rproc_start(struct rproc *rproc)
>  	struct imx_rproc *priv = rproc->priv;
>  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
>  	struct device *dev = priv->dev;
> +	struct arm_smccc_res res;
>  	int ret;
>  
> -	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> -				 dcfg->src_mask, dcfg->src_start);
> +	switch (dcfg->method) {
> +	case IMX_RPROC_MMIO:
> +		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
> +					 dcfg->src_start);
> +		break;
> +	case IMX_RPROC_SMC:
> +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0, 0, 0, 0, &res);
> +		ret = res.a0;
> +		break;
> +	default:
> +		return -EOPNOTSUPP;
> +	}
> +
>  	if (ret)
> -		dev_err(dev, "Failed to enable M4!\n");
> +		dev_err(dev, "Failed to enable remote cores!\n");
>  
>  	return ret;
>  }
> @@ -261,12 +315,26 @@ static int imx_rproc_stop(struct rproc *rproc)
>  	struct imx_rproc *priv = rproc->priv;
>  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
>  	struct device *dev = priv->dev;
> +	struct arm_smccc_res res;
>  	int ret;
>  
> -	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> -				 dcfg->src_mask, dcfg->src_stop);
> +	switch (dcfg->method) {
> +	case IMX_RPROC_MMIO:
> +		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
> +					 dcfg->src_stop);
> +		break;
> +	case IMX_RPROC_SMC:
> +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STOP, 0, 0, 0, 0, 0, 0, &res);
> +		ret = res.a0;
> +		if (res.a1)
> +			dev_info(dev, "Not in wfi, force stopped\n");
> +		break;
> +	default:
> +		return -EOPNOTSUPP;
> +	}
> +
>  	if (ret)
> -		dev_err(dev, "Failed to stop M4!\n");
> +		dev_err(dev, "Failed to stop remote cores\n");
>  
>  	return ret;
>  }
> @@ -600,6 +668,7 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  {
>  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
>  	struct device *dev = priv->dev;
> +	struct arm_smccc_res res;
>  	int ret;
>  	u32 val;
>  
> @@ -616,8 +685,12 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  			priv->mode = IMX_RPROC_EARLY_BOOT;
>  	}
>  
> -	if (dcfg->method == IMX_RPROC_NONE)
> +	if (dcfg->method == IMX_RPROC_NONE) {
>  		priv->mode = IMX_RPROC_EARLY_BOOT;
> +	} else if (dcfg->method == IMX_RPROC_SMC) {
> +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STARTED, 0, 0, 0, 0, 0, 0, &res);
> +		priv->mode = res.a0 ? IMX_RPROC_EARLY_BOOT : IMX_RPROC_NORMAL;
> +	}

When all patches have been applied this function is really hard to read.  I
suggest using a switch() statement like you did in imx_rproc_start() and
imx_rproc_stop().

Thanks,
Mathieu

>  
>  	if (priv->mode == IMX_RPROC_EARLY_BOOT)
>  		priv->rproc->state = RPROC_DETACHED;
> @@ -747,6 +820,8 @@ static const struct of_device_id imx_rproc_of_match[] = {
>  	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
>  	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
>  	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
> +	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
> +	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
> -- 
> 2.30.0
> 


From catalin.marinas at arm.com  Tue Apr 13 19:00:33 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 13 Apr 2021 19:00:33 +0100
Subject: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in
 traps for setting si_code
In-Reply-To: <20210413143035.7zrct6a3up42uaoo@revolver>
References: <20210407150940.542103-1-Liam.Howlett@Oracle.com>
 <20210412174343.GG2060@arm.com>
 <20210413143035.7zrct6a3up42uaoo@revolver>
Message-ID: <20210413180030.GA31164@arm.com>

On Tue, Apr 13, 2021 at 04:52:34PM +0000, Liam Howlett wrote:
> * Catalin Marinas <catalin.marinas at arm.com> [210412 13:44]:
> > On Wed, Apr 07, 2021 at 03:11:06PM +0000, Liam Howlett wrote:
> > > find_vma() will continue to search upwards until the end of the virtual
> > > memory space.  This means the si_code would almost never be set to
> > > SEGV_MAPERR even when the address falls outside of any VMA.  The result
> > > is that the si_code is not reliable as it may or may not be set to the
> > > correct result, depending on where the address falls in the address
> > > space.
> > > 
> > > Using find_vma_intersection() allows for what is intended by only
> > > returning a VMA if it falls within the range provided, in this case a
> > > window of 1.
> > > 
> > > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > > ---
> > >  arch/arm64/kernel/traps.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > > index a05d34f0e82a..a44007904a64 100644
> > > --- a/arch/arm64/kernel/traps.c
> > > +++ b/arch/arm64/kernel/traps.c
> > > @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
> > >  void arm64_notify_segfault(unsigned long addr)
> > >  {
> > >  	int code;
> > > +	unsigned long ut_addr = untagged_addr(addr);
> > >  
> > >  	mmap_read_lock(current->mm);
> > > -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> > > +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
> > >  		code = SEGV_MAPERR;
> > >  	else
> > >  		code = SEGV_ACCERR;
[...]
> > I don't think your change is entirely correct either. We can have a
> > fault below the vma of a stack (with VM_GROWSDOWN) and
> > find_vma_intersection() would return NULL but it should be a SEGV_ACCERR
> > instead.
> 
> I'm pretty sure I am missing something.  From what you said above, I
> think this means that there can be a user cache fault below the stack
> which should notify the user application that they are not allowed to
> expand the stack by sending a SIGV_ACCERR in the si_code?  Is this
> expected behaviour or am I missing a code path to this function?

My point was that find_vma() may return a valid vma where addr < vm_end
but also addr < vm_addr. It's the responsibility of the caller to check
that that vma can be expanded (VM_GROWSDOWN) and we do something like
this in __do_page_fault(). find_vma_intersection(), OTOH, requires addr
>= vm_start.

If we hit this case (addr < vm_start), normally we'd first need to check
whether it's expandable and, if not, return MAPERR. If it's expandable,
it should be ACCERR since something else caused the fault.

Now, I think at least for user_cache_maint_handler(), we can assume that
__do_page_fault() handled any expansion already, so we don't need to
check it here. In this case, your find_vma_intersection() check should
work.

Are there other cases where we invoke arm64_notify_segfault() without a
prior fault? I think in swp_handler() we can bail out early before we
even attempted the access so we may report MAPERR but ACCERR is a better
indication. Also in sys_rt_sigreturn() we always call it as
arm64_notify_segfault(regs->sp). I'm not sure that's correct in all
cases, see restore_altstack().

I guess this code needs some tidying up.

> > Maybe this should employ similar checks as __do_page_fault() (with
> > expand_stack() and VM_GROWSDOWN).
> 
> You mean the code needs to detect endianness and to check if this is an
> attempt to expand the stack for both cases?

Nothing to do with endianness, just the relation between the address and
the vma->vm_start and whether the vma can be expanded down.

-- 
Catalin


From s-anna at ti.com  Tue Apr 13 19:10:43 2021
From: s-anna at ti.com (Suman Anna)
Date: Tue, 13 Apr 2021 13:10:43 -0500
Subject: [PATCH v2 0/3] PRU firmware event/interrupt mapping fixes
In-Reply-To: <20210407155641.5501-1-s-anna@ti.com>
References: <20210407155641.5501-1-s-anna@ti.com>
Message-ID: <52942a19-c0f8-c376-9103-2e5020c49c3a@ti.com>

Hi Bjorn,

On 4/7/21 10:56 AM, Suman Anna wrote:
> Hi All,
> 
> The following is a minor revised version of the series [1] that includes fixes
> for various different issues associated with the PRU firmware event/interrupt
> mapping configuration logic. Please see the v1 cover-letter [1] for additional
> details. 
> 
> There are currently no in-kernel dts nodes yet in mainline kernel (first
> nodes will appear in v5.13-rc1) so these can be picked up for either v5.13
> merge window or the current -rc cycle.
> 
> Changes in v2:
>  - Picked up Reviewed-by tags on Patches 1 and 2
>  - Revised Patch 3 to address additional error cleanup paths as
>    pointed out by Mathieu.

All patches are reviewed now, so can you please pick these up for the next merge
window if not already in your queue.

regards
Suman

> 
> regards
> Suman
> 
> [1] https://patchwork.kernel.org/project/linux-remoteproc/cover/20210323223839.17464-1-s-anna at ti.com/
> 
> Suman Anna (3):
>   remoteproc: pru: Fixup interrupt-parent logic for fw events
>   remoteproc: pru: Fix wrong success return value for fw events
>   remoteproc: pru: Fix and cleanup firmware interrupt mapping logic
> 
>  drivers/remoteproc/pru_rproc.c | 41 ++++++++++++++++++++++++++--------
>  1 file changed, 32 insertions(+), 9 deletions(-)
> 



From dvyukov at google.com  Tue Apr 13 19:11:38 2021
From: dvyukov at google.com (Dmitry Vyukov)
Date: Tue, 13 Apr 2021 20:11:38 +0200
Subject: [syzbot] WARNING: suspicious RCU usage in __schedule
In-Reply-To: <00000000000066b6f405bf0d0660@google.com>
References: <00000000000066b6f405bf0d0660@google.com>
Message-ID: <CACT4Y+a7m9_hGjb0f8r_ZELSGqs=NvpocST9pXex23y57RLGug@mail.gmail.com>

On Sat, Apr 3, 2021 at 10:12 AM syzbot
<syzbot+be81a058b10931003a4a at syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1432bd1ad00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=78a83786814e7724
> dashboard link: https://syzkaller.appspot.com/bug?extid=be81a058b10931003a4a
> userspace arch: arm
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+be81a058b10931003a4a at syzkaller.appspotmail.com

#syz dup: WARNING: suspicious RCU usage in getname_flags

> =============================
> WARNING: suspicious RCU usage
> 5.12.0-rc5-syzkaller-00003-g1e43c377a79f #0 Not tainted
> -----------------------------
> kernel/sched/core.c:4841 Illegal context switch in RCU-sched read-side critical section!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 0
> no locks held by migration/1/17.
>
> stack backtrace:
> CPU: 1 PID: 17 Comm: migration/1 Not tainted 5.12.0-rc5-syzkaller-00003-g1e43c377a79f #0
> Hardware name: linux,dummy-virt (DT)
> Stopper: 0x0 <- 0x0
> Call trace:
>  dump_backtrace+0x0/0x3e0 arch/arm64/include/asm/pointer_auth.h:76
>  show_stack+0x18/0x24 arch/arm64/kernel/stacktrace.c:191
>  __dump_stack lib/dump_stack.c:79 [inline]
>  dump_stack+0x120/0x1a8 lib/dump_stack.c:120
>  lockdep_rcu_suspicious+0x130/0x148 kernel/locking/lockdep.c:6428
>  schedule_debug kernel/sched/core.c:4841 [inline]
>  __schedule+0x1244/0x1bc4 kernel/sched/core.c:4967
>  schedule+0xac/0x22c kernel/sched/core.c:5152
>  smpboot_thread_fn+0x278/0x7f4 kernel/smpboot.c:161
>  kthread+0x320/0x3bc kernel/kthread.c:292
>  ret_from_fork+0x10/0x3c arch/arm64/kernel/entry.S:958
>
>
> ---
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000066b6f405bf0d0660%40google.com.


From robh+dt at kernel.org  Tue Apr 13 19:17:29 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Tue, 13 Apr 2021 13:17:29 -0500
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,
 pci-domain to zero
In-Reply-To: <20210412123936.25555-1-pali@kernel.org>
References: <20210412123936.25555-1-pali@kernel.org>
Message-ID: <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>

On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
>
> Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> function and allow to build it as module") PCIe controller driver for
> Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> allows dynamic binding and unbinding of PCIe controller device.
>
> Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> number (starting from zero) for this PCIe controller every time when device
> is bound. So PCI domain changes after every unbind / bind operation.

PCI host bridges as a module are relatively new, so seems likely a bug to me.

> Alternative way for assigning PCI domain number is to use static allocated
> numbers defined in Device Tree. This option has requirement that every PCI
> controller in system must have defined PCI bus number in Device Tree.

That seems entirely pointless from a DT point of view with a single PCI bridge.

> Armada 37xx has only one PCIe controller, so assign for it PCI domain 0 in
> Device Tree.
>
> After this change PCI domain on Armada 37xx is always zero, even after
> repeated unbind and bind operations.
>
> Signed-off-by: Pali Roh?r <pali at kernel.org>
> Fixes: 526a76991b7b ("PCI: aardvark: Implement driver 'remove' function and allow to build it as module")
> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index 7a2df148c6a3..f02058ef5364 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -495,6 +495,7 @@
>                                         <0 0 0 2 &pcie_intc 1>,
>                                         <0 0 0 3 &pcie_intc 2>,
>                                         <0 0 0 4 &pcie_intc 3>;
> +                       linux,pci-domain = <0>;
>                         max-link-speed = <2>;
>                         phys = <&comphy1 0>;
>                         pcie_intc: interrupt-controller {
> --
> 2.20.1
>


From michael.weiser at gmx.de  Tue Apr 13 19:48:24 2021
From: michael.weiser at gmx.de (Michael Weiser)
Date: Tue, 13 Apr 2021 20:48:24 +0200
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <20210413115837.232c465a@slackpad.fritz.box>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
 <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
 <20210413115837.232c465a@slackpad.fritz.box>
Message-ID: <YHXneEEiFCwna7X6@weiser.dinsnail.net>

Hi Jernej and Andre,

On Tue, Apr 13, 2021 at 11:58:37AM +0100, Andre Przywara wrote:

> > > Daniel, Michael, can you test this on your boards? So removing the
> > > cd-gpios property, and adding "broken-cd;" instead?  
> > Yes, it works fine. What flummoxed me at first was that obviously I also
> > have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
> > after having added and disabled an ACTIVE_HIGH definition in
> > sun50i-a64-pine64-lts.dts.
> Why? From my experiments it should not matter, the actual card presence
> is typically detected via the SD bus anyway (if I understand the code
> correctly). broken-cd just prevents installation of an interrupt
> handler, so it's less efficient and prevents wakeup on card detect,
> AFAICS.

I just retested to be sure: At least with 5.11.11 and on my boards,
cd-gpio ACTIVE_LOW being specified in the sopine.dtsi takes precedence
over broken-cd being specified in pine64-lts.dts. Could that spoil the
plan of disabling cd-gpio for the LTS while leaving it enabled for
Sopine and baseboard?

Behaviour is as such: With cd-gpios ACTIVE_LOW in sopine.dtsi and
broken-cd in pine64-lts.dts, card insertion, removal and reinsertion is
not detected after booting the kernel without a card in the slot. With
cd-gpios ACTIVE_LOW removed from sopine.dtsi it starts working.

In diffs for added clarity:

PAGER= git log --pretty=oneline HEAD~1..HEAD
aa7258f8f3d48a29bc024ea8c5145bdc4a980e4d (HEAD, tag: v5.11.11) Linux 5.11.11

- not working on its own:

index 302e24be0a31..5b0c21e68352 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -8,3 +8,7 @@ / {
        compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
                     "allwinner,sun50i-a64";
 };
+
+&mmc0 {
+       broken-cd;
+};

- working with this additional change:

index 3402cec87035..ba2b7398993b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
@@ -34,7 +34,6 @@ &mmc0 {
        vmmc-supply = <&reg_dcdc1>;
        disable-wp;
        bus-width = <4>;
-       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
        status = "okay";
 };

> So for your particular board (version) you could actually remove the
> whole &mmc0 node override, use the same node as the SOPine (working
> active-high CD) and it should work.

Correct. Again for reasons of laziness I tested with the dts from
5.11.11 which is currently running on the board and which still has
ACTIVE_LOW in sopine.dtsi. Sorry for not being clearer about that.

But somewhat lucky as well because without ACTIVE_LOW still being set in
sopine.dtsi I wouldn't have had a way to tell that broken-cd was not
taking effect and silently have tested the working ACTIVE_HIGH
definition from sopine.dtsi.

Or am I somehow making a mess of this?

> > BTW: My boards have a marking "PINE64-R18-V1_1" and below it
> > "2017-08-03" on their upper side. On the back it says on one sticker
> > "Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
> > "PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
> > perhaps?  Is there a way to detect this difference in software and add
> > some sort of quirk handler for it?
> As Jernej mentioned, this would be U-Boot's task, but I don't see a
> good reason for it. Firstly, you would need to find a good automatic
> way of determining the board revision, which I doubt there is. And
> secondly, I don't see the benefit: It works quite nicely with
> broken-cd: card removals and insertions are detected automatically,
> it's just not as efficient (interrupt-driven) as it could be.
> Or do you see any problems with broken-cd?

Of course not. My boards have their rootfs on mmc0, so the card is never
removed and replaced during operation anyway. I was just asking out of
curiosity.

And out of curiosity again: Could one have a device tree overlay
configured manually to be loaded by the bootloader that adds cd-gpio
ACTIVE_HIGH for mmc0 and disables/overrules broken-cd? Somewhat like so
(untested):

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>

/ {
        fragment at 0 {
                target = <&mmc0>;
                __overlay__ {
                        cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 push-push switch */
                };
        };
};

Here it would be useful if cd-gpios indeed took precedence over
broken-cd because my grepping of the code can't find a way to un-specify
it once set.
-- 
Michael


From tim.c.chen at linux.intel.com  Tue Apr 13 20:00:27 2021
From: tim.c.chen at linux.intel.com (Tim Chen)
Date: Tue, 13 Apr 2021 12:00:27 -0700
Subject: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and
 add cluster scheduler
In-Reply-To: <9201b56a29dd4dacb7d9fcbf307ca5ff@hisilicon.com>
References: <20210106083026.40444-1-song.bao.hua@hisilicon.com>
 <737932c9-846a-0a6b-08b8-e2d2d95b67ce@linux.intel.com>
 <20210108151241.GA47324@e123083-lin>
 <99c07bdf-02d1-153a-bd1e-2f4200cc67c5@linux.intel.com>
 <20210111092811.GB47324@e123083-lin>
 <4fdc781e-7385-2ae6-d9c9-3ec165f473c4@arm.com>
 <9201b56a29dd4dacb7d9fcbf307ca5ff@hisilicon.com>
Message-ID: <6e067798-5585-5169-38fc-77e173831af5@linux.intel.com>



On 4/13/21 3:45 AM, Song Bao Hua (Barry Song) wrote:
> 
> 
>
> Right now in the main cases of using wake_affine to achieve
> better performance, processes are actually bound within one
> numa which is also a LLC in kunpeng920. 
> 
> Probably LLC=NUMA is also true for X86 Jacobsville, Tim?

In general for x86, LLC is partitioned at the sub-numa cluster level.  
LLC could be divided between sub-numa cluster within a NUMA node.
That said, for Jacobsville, we don't have sub-numa clusters
so LLC=NUMA is true for that platform. 

Tim


From mathieu.poirier at linaro.org  Tue Apr 13 20:45:00 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 13 Apr 2021 13:45:00 -0600
Subject: [GIT PULL] coresight: Fixes for ETE and TRBE
In-Reply-To: <87sg3um8j1.wl-maz@kernel.org>
References: <20210413161952.750262-1-mathieu.poirier@linaro.org>
 <87sg3um8j1.wl-maz@kernel.org>
Message-ID: <CANLsYkyyqSAe=9O2MyeX0z0sS501uD2+7NuDVv5V9LeAbbMDoQ@mail.gmail.com>

On Tue, 13 Apr 2021 at 10:52, Marc Zyngier <maz at kernel.org> wrote:
>
> Hi Mathieu,
>
> On Tue, 13 Apr 2021 17:19:52 +0100,
> Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> >
> > The following changes since commit 4fb13790417a7bf726f3867a5d2b9723efde488b:
> >
> >   dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600)
> >
> > are available in the Git repository at:
> >
> >   git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE
> >
> > for you to fetch changes up to 68d400c079978f649e7f63aba966d219743edd64:
> >
> >   coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() (2021-04-13 09:46:27 -0600)
> >
> > ----------------------------------------------------------------
> > Hi Marc,
> >
> > Please consider these two patches, they are ETE/TRBE fixes found by bots.
> >
> > Let me know if you want me to rebase on your next branch and send the
> > pull request from that.
>
> I've now pulled this into kvmarm/next. If you have additional fixes,
> just stick them on top of your next-ETE-TRBE branch like you did with
> these two patches.
>

Much appreciated - I owe you a beer.

> The kvmarm/next branch gets rebuilt every other day, so it isn't a
> stable branch on its own. Only the non-merge commits are stable, which
> is why I keep everything on topic branches.
>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.


From wsa at kernel.org  Tue Apr 13 20:55:21 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Tue, 13 Apr 2021 21:55:21 +0200
Subject: [PATCH] i2c: busses: remove unused including <linux/version.h>
In-Reply-To: <1618307301-72925-1-git-send-email-yang.lee@linux.alibaba.com>
References: <1618307301-72925-1-git-send-email-yang.lee@linux.alibaba.com>
Message-ID: <20210413195521.GA2751@kunai>

On Tue, Apr 13, 2021 at 05:48:21PM +0800, Yang Li wrote:
> Fix the following versioncheck warnings:
> ./drivers/i2c/busses/i2c-xgene-slimpro.c: 22 linux/version.h not needed.
> ./drivers/i2c/busses/i2c-brcmstb.c: 25 linux/version.h not needed.
> 
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>

Thanks, but a similar patch is already in -next.

https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git/commit/?h=i2c/for-next&id=660f58b6d290417828680f417f43d7b810fa9138

-------------- 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/20210413/b3b6c599/attachment.sig>

From eajames at linux.ibm.com  Tue Apr 13 21:08:52 2021
From: eajames at linux.ibm.com (Eddie James)
Date: Tue, 13 Apr 2021 15:08:52 -0500
Subject: [PATCH] fsi: aspeed: Emit fewer barriers in opb operations
In-Reply-To: <20210223041737.171274-1-joel@jms.id.au>
References: <20210223041737.171274-1-joel@jms.id.au>
Message-ID: <bfb940efdba7d308cf5e91874604582cb5173ada.camel@linux.ibm.com>

On Tue, 2021-02-23 at 14:47 +1030, Joel Stanley wrote:
> When setting up a read or write to the OPB memory space, we must
> perform
> five or six AHB writes. The ordering of these up until the trigger
> write
> does not matter, so use writel_relaxed.

Reviewed-by: Eddie James <eajames at linux.ibm.com>

I have also tested this patch on hardware, so

Tested-by: Eddie James <eajames at linux.ibm.com>

> 
> The generated code goes from (Debian GCC 10.2.1-6):
> 
>         mov     r8, r3
>         mcr     15, 0, sl, cr7, cr10, {4}
>         str     sl, [r6, #20]
>         mcr     15, 0, sl, cr7, cr10, {4}
>         str     r3, [r6, #24]
>         mcr     15, 0, sl, cr7, cr10, {4}
>         str     r1, [r6, #28]
>         mcr     15, 0, sl, cr7, cr10, {4}
>         str     r2, [r6, #32]
>         mcr     15, 0, sl, cr7, cr10, {4}
>         mov     r1, #1
>         str     r1, [r6, #64]   ; 0x40
>         mcr     15, 0, sl, cr7, cr10, {4}
>         str     r1, [r6, #4]
> 
> to this:
> 
>         str     r3, [r7, #20]
>         str     r2, [r7, #24]
>         str     r1, [r7, #28]
>         str     r3, [r7, #64]
>         mov     r8, #0
>         mcr     15, 0, r8, cr7, cr10, {4}
>         str     r3, [r7, #4]
> 
> Signed-off-by: Joel Stanley <joel at jms.id.au>
> ---
>  drivers/fsi/fsi-master-aspeed.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/fsi/fsi-master-aspeed.c b/drivers/fsi/fsi-
> master-aspeed.c
> index 90dbe58ca1ed..09fff86b2bac 100644
> --- a/drivers/fsi/fsi-master-aspeed.c
> +++ b/drivers/fsi/fsi-master-aspeed.c
> @@ -101,11 +101,11 @@ static int __opb_write(struct fsi_master_aspeed
> *aspeed, u32 addr,
>  	u32 reg, status;
>  	int ret;
>  
> -	writel(CMD_WRITE, base + OPB0_RW);
> -	writel(transfer_size, base + OPB0_XFER_SIZE);
> -	writel(addr, base + OPB0_FSI_ADDR);
> -	writel(val, base + OPB0_FSI_DATA_W);
> -	writel(0x1, base + OPB_IRQ_CLEAR);
> +	writel_relaxed(CMD_WRITE, base + OPB0_RW);
> +	writel_relaxed(transfer_size, base + OPB0_XFER_SIZE);
> +	writel_relaxed(addr, base + OPB0_FSI_ADDR);
> +	writel_relaxed(val, base + OPB0_FSI_DATA_W);
> +	writel_relaxed(0x1, base + OPB_IRQ_CLEAR);
>  	writel(0x1, base + OPB_TRIGGER);
>  
>  	ret = readl_poll_timeout(base + OPB_IRQ_STATUS, reg,
> @@ -149,10 +149,10 @@ static int __opb_read(struct fsi_master_aspeed
> *aspeed, uint32_t addr,
>  	u32 result, reg;
>  	int status, ret;
>  
> -	writel(CMD_READ, base + OPB0_RW);
> -	writel(transfer_size, base + OPB0_XFER_SIZE);
> -	writel(addr, base + OPB0_FSI_ADDR);
> -	writel(0x1, base + OPB_IRQ_CLEAR);
> +	writel_relaxed(CMD_READ, base + OPB0_RW);
> +	writel_relaxed(transfer_size, base + OPB0_XFER_SIZE);
> +	writel_relaxed(addr, base + OPB0_FSI_ADDR);
> +	writel_relaxed(0x1, base + OPB_IRQ_CLEAR);
>  	writel(0x1, base + OPB_TRIGGER);
>  
>  	ret = readl_poll_timeout(base + OPB_IRQ_STATUS, reg,



From wsa at the-dreams.de  Tue Apr 13 21:17:40 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 13 Apr 2021 22:17:40 +0200
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <1618228994.32225.3.camel@mhfsdcap03>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
 <20210406194856.GF3122@kunai> <1617797706.32076.1.camel@mhfsdcap03>
 <20210407181936.GA1614@kunai> <1618228994.32225.3.camel@mhfsdcap03>
Message-ID: <20210413201740.GC2751@kunai>

On Mon, Apr 12, 2021 at 08:03:14PM +0800, Qii Wang wrote:
> On Wed, 2021-04-07 at 20:19 +0200, Wolfram Sang wrote:
> > > Due to clock stretch, our HW IP cannot meet the ac-timing
> > > spec(tSU;STA,tSU;STO). 
> > > There isn't a same delay for clock stretching, so we need pass a
> > > parameter which can be found through measurement to meet most
> > > conditions.
> > 
> > What about using this existing binding?
> > 
> > - i2c-scl-internal-delay-ns
> >         Number of nanoseconds the IP core additionally needs to setup SCL.
> > 
> 
> I can't see the relationship between "i2c-scl-falling-time-ns" and clock
> stretching, is there a parameter related to clock stretching?

( you wrote "i2c-scl-falling-time-ns" above, didn't you mean
"i2c-scl-internal-delay-ns" instead? )

Not yet, and I wonder if there can be one. In I2C (not SMBus), devices
are allowed to stretch the clock as long as they want, so what should be
specified here?

I suggesteed "internal-delay" because AFAIU your hardware needs this
delay to be able to cope with clock stretching.

> If you think both of them will affect the ac-timing of SCL, at this
> point, "i2c-scl-falling-time-ns" maybe a good choice.

Do you mean "i2c-scl-falling-time-ns" or "i2c-scl-internal-delay-ns"?

-------------- 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/20210413/6c6c2659/attachment-0001.sig>

From bjorn.andersson at linaro.org  Tue Apr 13 21:51:23 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Tue, 13 Apr 2021 15:51:23 -0500
Subject: [PATCH 2/2] remoteproc: stm32: add capability to detach
In-Reply-To: <20210318145923.31936-3-arnaud.pouliquen@foss.st.com>
References: <20210318145923.31936-1-arnaud.pouliquen@foss.st.com>
 <20210318145923.31936-3-arnaud.pouliquen@foss.st.com>
Message-ID: <YHYESxThXVnVH3q8@builder.lan>

On Thu 18 Mar 09:59 CDT 2021, Arnaud Pouliquen wrote:

> From: Arnaud Pouliquen <arnaud.pouliquen at foss-st.com>
> 
> A mechanism similar to the shutdown mailbox signal is implemented to
> detach a remote processor.
> 
> Upon detachment, a signal is sent to the remote firmware, allowing it
> to perform specific actions such as stopping RPMsg communication.
> 
> The Cortex-M hold boot is also disabled to allow the remote processor
> to restart in case of crash.
> 
> Notice that for this feature to be supported, the remote firmware 
> resource table must be stored at the beginning of a 1kB section 
> (default size provided to the remoteproc core).
> 
> This restriction should be lifted in the future by using a backup register
> to store the actual size of the resource table. 
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen at foss-st.com>
> ---
>  drivers/remoteproc/stm32_rproc.c | 38 ++++++++++++++++++++++++++++++--
>  1 file changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> index 3d45f51de4d0..298ef5b19e27 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -28,7 +28,7 @@
>  #define RELEASE_BOOT		1
>  
>  #define MBOX_NB_VQ		2
> -#define MBOX_NB_MBX		3
> +#define MBOX_NB_MBX		4
>  
>  #define STM32_SMC_RCC		0x82001000
>  #define STM32_SMC_REG_WRITE	0x1
> @@ -38,6 +38,7 @@
>  #define STM32_MBX_VQ1		"vq1"
>  #define STM32_MBX_VQ1_ID	1
>  #define STM32_MBX_SHUTDOWN	"shutdown"
> +#define STM32_MBX_DETACH	"detach"
>  
>  #define RSC_TBL_SIZE		1024
>  
> @@ -336,6 +337,15 @@ static const struct stm32_mbox stm32_rproc_mbox[MBOX_NB_MBX] = {
>  			.tx_done = NULL,
>  			.tx_tout = 500, /* 500 ms time out */
>  		},
> +	},
> +	{
> +		.name = STM32_MBX_DETACH,
> +		.vq_id = -1,
> +		.client = {
> +			.tx_block = true,
> +			.tx_done = NULL,
> +			.tx_tout = 200, /* 200 ms time out to detach should be fair enough */
> +		},
>  	}
>  };
>  
> @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc)
>  	return stm32_rproc_set_hold_boot(rproc, true);
>  }
>  
> +static int stm32_rproc_detach(struct rproc *rproc)
> +{
> +	struct stm32_rproc *ddata = rproc->priv;
> +	int err, dummy_data, idx;
> +
> +	/* Inform the remote processor of the detach */
> +	idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH);
> +	if (idx >= 0 && ddata->mb[idx].chan) {
> +		/* A dummy data is sent to allow to block on transmit */
> +		err = mbox_send_message(ddata->mb[idx].chan,
> +					&dummy_data);

Isn't it the stm32_ipcc driver on the other side of this call? In which
case I believe "data" is ignored, and you would be able to just pass
NULL here.

As long as "data" isn't dereferenced it's probably better to send some
bugus value, than an address to this variable on the stack. If on the
other hand you pair this with one of the mailbox drivers that
dereferences "data", you should initialize it...

Apart from this, I think the patch looks good!

Regards,
Bjorn

> +		if (err < 0)
> +			dev_warn(&rproc->dev, "warning: remote FW detach without ack\n");
> +	}
> +
> +	/* Allow remote processor to auto-reboot */
> +	return stm32_rproc_set_hold_boot(rproc, false);
> +}
> +
>  static int stm32_rproc_stop(struct rproc *rproc)
>  {
>  	struct stm32_rproc *ddata = rproc->priv;
> @@ -597,7 +626,11 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
>  	}
>  
>  done:
> -	/* Assuming the resource table fits in 1kB is fair */
> +	/*
> +	 * Assuming the resource table fits in 1kB is fair.
> +	 * Notice for the detach, that this 1 kB memory area has to be reserved in the coprocessor
> +	 * firmware for the resource table. A clean of this whole area is done on detach.
> +	 */
>  	*table_sz = RSC_TBL_SIZE;
>  	return (struct resource_table *)ddata->rsc_va;
>  }
> @@ -607,6 +640,7 @@ static const struct rproc_ops st_rproc_ops = {
>  	.start		= stm32_rproc_start,
>  	.stop		= stm32_rproc_stop,
>  	.attach		= stm32_rproc_attach,
> +	.detach		= stm32_rproc_detach,
>  	.kick		= stm32_rproc_kick,
>  	.load		= rproc_elf_load_segments,
>  	.parse_fw	= stm32_rproc_parse_fw,
> -- 
> 2.17.1
> 


From bjorn.andersson at linaro.org  Tue Apr 13 21:59:26 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Tue, 13 Apr 2021 15:59:26 -0500
Subject: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for
 Meson AO ARC rproc
In-Reply-To: <CAFBinCA92411o5+AGApr8+nkMdmzJ4ddzVY+Cb5FLBez+-92nA@mail.gmail.com>
References: <20201230012724.1326156-1-martin.blumenstingl@googlemail.com>
 <20201230012724.1326156-4-martin.blumenstingl@googlemail.com>
 <YFLBPGNQpT9mM3AJ@builder.lan>
 <CAFBinCA92411o5+AGApr8+nkMdmzJ4ddzVY+Cb5FLBez+-92nA@mail.gmail.com>
Message-ID: <YHYGLuxIN7WMakco@builder.lan>

On Tue 23 Mar 17:02 CDT 2021, Martin Blumenstingl wrote:

> Hi Bjorn,
> 
> On Thu, Mar 18, 2021 at 3:55 AM Bjorn Andersson
> <bjorn.andersson at linaro.org> wrote:
> [...]
> > > +examples:
> > > +  - |
> > > +    remoteproc at 1c {
> > > +      compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
> > > +      reg = <0x1c 0x8>, <0x38 0x8>;
> >
> > I'm generally not in favor of mapping "individual" registers, do you
> > know what hardware block this is part of? Can you express the whole
> > block as an single entity in your DT?
> the answer is unfortunately not easy :-)
> 
> some background information:
> Amlogic SoCs have two power domains:
> - AO (Always-On)
> - EE (Everything-Else)
> 
> AO includes (at least) one ARC core for which this remoteproc dt-binding is.
> EE includes ARM Cortex-A7/15/... cores
> 
> The AO registers can be accessed from the EE power-domain and vice versa
> 
> Following is an extract (with comments added by me) for the AO
> registers (taken from the GPL vendor kernel):
> #define AO_RTI_STATUS_REG0 ((0x00 << 10) | (0x00 << 2))
> #define AO_RTI_STATUS_REG1 ((0x00 << 10) | (0x01 << 2))
> #define AO_RTI_STATUS_REG2 ((0x00 << 10) | (0x02 << 2))
> these three are used for communication with the firmware on the AO ARC core
> I am not sure into which Linux subsystem these would fit into best
> 
> #define AO_RTI_PWR_CNTL_REG1 ((0x00 << 10) | (0x03 << 2))
> #define AO_RTI_PWR_CNTL_REG0 ((0x00 << 10) | (0x04 << 2))
> this includes various power-domains for the following functionality
> (and probably more):
> - DDR PHY I/O
> - AHB SRAM
> - video encoder/decoders
> - EE domain isolation
> 
> #define AO_RTI_PIN_MUX_REG ((0x00 << 10) | (0x05 << 2))
> first part of the pin controller registers for the "AO" bank pads
> this includes various GPIOs, UART, I2C for communication with a PMIC,
> infrared remote decoder, two PWMs, etc.
> all (known) functionality can be used by Linux as well.
> especially the UART, I2C, IR decoder and GPIOs are functionality that
> we use with Linux today - without involving the AO ARC
> remote-processor.
> 
> #define AO_WD_GPIO_REG ((0x00 << 10) | (0x06 << 2))
> (I think this is related to the watchdog being able to trigger the
> SoC's reset line, but there's no documentation on this register)
> 
> #define AO_REMAP_REG0 ((0x00 << 10) | (0x07 << 2))
> #define AO_REMAP_REG1 ((0x00 << 10) | (0x08 << 2))
> remap registers for the AO ARC remote-processor as used in this binding
> 
> #define AO_GPIO_O_EN_N ((0x00 << 10) | (0x09 << 2))
> #define AO_GPIO_I ((0x00 << 10) | (0x0A << 2))
> GPIO controller registers for the "AO" bank pads
> 
> #define AO_RTI_PULL_UP_REG ((0x00 << 10) | (0x0B << 2))
> second part of the pin controller registers for the "AO" bank pads
> 
> #define AO_RTI_WD_MARK ((0x00 << 10) | (0x0D << 2))
> again, I think this is somehow related to the watchdog but there's no
> documentation on this
> 
> #define AO_CPU_CNTL ((0x00 << 10) | (0x0E << 2))
> #define AO_CPU_STAT ((0x00 << 10) | (0x0F << 2))
> used for booting the AO ARC remote-processor
> 
> #define AO_RTI_GEN_CNTL_REG0 ((0x00 << 10) | (0x10 << 2))
> seems to be a multi purpose register as it (seems to) contains some
> reset bits (for the AO UART and RTC) - not documented
> 
> (more registers are following)
> 
> to summarize this: I think there's indeed three different sets of registers
> having one big device-tree node spanning all of these registers seems
> incorrect to me as the other IPs are independent of the AO ARC
> remote-processor.
> so the way I have done it in the original patch is the best I could
> come up with.
> 
> Please let me know what you think!
> 

I see.

Describing these kinds blocks in DT is indeed tricky, I've had
both cases where a block maps to multiple "functions" or where they
contain misc registers to be used in relation to some other block.

The prior typically lends itself to be modelled as a "simple-mfd" and
the latter as a "syscon".

So perhaps you could do a simple-mfd that spans the entire block and
then describe the remoteproc, watchdog?, pinctrl pieces as children
under that?

Regards,
Bjorn


From alex.kogan at oracle.com  Tue Apr 13 22:01:37 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Tue, 13 Apr 2021 17:01:37 -0400
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <87mtu2vhzz.fsf@linux.intel.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
Message-ID: <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>

Hi, Andi.

Thanks for your comments!

> On Apr 13, 2021, at 2:03 AM, Andi Kleen <ak at linux.intel.com> wrote:
> 
> Alex Kogan <alex.kogan at oracle.com> writes:
>> 
>> +	numa_spinlock_threshold=	[NUMA, PV_OPS]
>> +			Set the time threshold in milliseconds for the
>> +			number of intra-node lock hand-offs before the
>> +			NUMA-aware spinlock is forced to be passed to
>> +			a thread on another NUMA node.	Valid values
>> +			are in the [1..100] range. Smaller values result
>> +			in a more fair, but less performant spinlock,
>> +			and vice versa. The default value is 10.
> 
> ms granularity seems very coarse grained for this. Surely
> at some point of spinning you can afford a ktime_get? But ok.
We are reading time when we are at the head of the (main) queue, but
don?t have the lock yet. Not sure about the latency of ktime_get(), but
anything reasonably fast but not necessarily precise should work.

> Could you turn that into a moduleparm which can be changed at runtime?
> Would be strange to have to reboot just to play with this parameter
Yes, good suggestion, thanks.

> This would also make the code a lot shorter I guess.
So you don?t think we need the command-line parameter, just the module_param?

Regards,
? Alex



From ak at linux.intel.com  Tue Apr 13 22:22:03 2021
From: ak at linux.intel.com (Andi Kleen)
Date: Tue, 13 Apr 2021 14:22:03 -0700
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
 <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
Message-ID: <20210413212203.GT3762101@tassilo.jf.intel.com>

> > ms granularity seems very coarse grained for this. Surely
> > at some point of spinning you can afford a ktime_get? But ok.
> We are reading time when we are at the head of the (main) queue, but
> don?t have the lock yet. Not sure about the latency of ktime_get(), but
> anything reasonably fast but not necessarily precise should work.

Actually cpu_clock / sched_clock (see my other email). These should
be fast without corner cases and also monotonic.

> 
> > Could you turn that into a moduleparm which can be changed at runtime?
> > Would be strange to have to reboot just to play with this parameter
> Yes, good suggestion, thanks.
> 
> > This would also make the code a lot shorter I guess.
> So you don?t think we need the command-line parameter, just the module_param?

module_params can be changed at the command line too, so yes.

-Andi


From bjorn.andersson at linaro.org  Tue Apr 13 22:34:47 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Tue, 13 Apr 2021 16:34:47 -0500
Subject: [PATCH v4 2/2] remoteproc: stm32: add capability to detach
In-Reply-To: <20210331073347.8293-3-arnaud.pouliquen@foss.st.com>
References: <20210331073347.8293-1-arnaud.pouliquen@foss.st.com>
 <20210331073347.8293-3-arnaud.pouliquen@foss.st.com>
Message-ID: <YHYOd/vqeZCiqkpJ@builder.lan>

On Wed 31 Mar 02:33 CDT 2021, Arnaud Pouliquen wrote:

> A mechanism similar to the shutdown mailbox signal is implemented to
> detach a remote processor.
> 
> Upon detachment, a signal is sent to the remote firmware, allowing it
> to perform specific actions such as stopping rpmsg communication.
> 
> The Cortex-M hold boot is also disabled to allow the remote processor
> to restart in case of crash.
> 
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen at foss.st.com>
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Tested-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> ---
>  drivers/remoteproc/stm32_rproc.c | 39 ++++++++++++++++++++++++++++++--
>  1 file changed, 37 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> index 3d45f51de4d0..7353f9e7e7af 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -28,7 +28,7 @@
>  #define RELEASE_BOOT		1
>  
>  #define MBOX_NB_VQ		2
> -#define MBOX_NB_MBX		3
> +#define MBOX_NB_MBX		4
>  
>  #define STM32_SMC_RCC		0x82001000
>  #define STM32_SMC_REG_WRITE	0x1
> @@ -38,6 +38,7 @@
>  #define STM32_MBX_VQ1		"vq1"
>  #define STM32_MBX_VQ1_ID	1
>  #define STM32_MBX_SHUTDOWN	"shutdown"
> +#define STM32_MBX_DETACH	"detach"
>  
>  #define RSC_TBL_SIZE		1024
>  
> @@ -336,6 +337,15 @@ static const struct stm32_mbox stm32_rproc_mbox[MBOX_NB_MBX] = {
>  			.tx_done = NULL,
>  			.tx_tout = 500, /* 500 ms time out */
>  		},
> +	},
> +	{
> +		.name = STM32_MBX_DETACH,
> +		.vq_id = -1,
> +		.client = {
> +			.tx_block = true,
> +			.tx_done = NULL,
> +			.tx_tout = 200, /* 200 ms time out to detach should be fair enough */
> +		},
>  	}
>  };
>  
> @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc)
>  	return stm32_rproc_set_hold_boot(rproc, true);
>  }
>  
> +static int stm32_rproc_detach(struct rproc *rproc)
> +{
> +	struct stm32_rproc *ddata = rproc->priv;
> +	int err, dummy_data, idx;
> +
> +	/* Inform the remote processor of the detach */
> +	idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH);
> +	if (idx >= 0 && ddata->mb[idx].chan) {
> +		/* A dummy data is sent to allow to block on transmit */
> +		err = mbox_send_message(ddata->mb[idx].chan,
> +					&dummy_data);

Seems I posted my comment on v1, rather than this latest version. Please
let me know if we should do anything about this dummy_data.

Regards,
Bjorn

> +		if (err < 0)
> +			dev_warn(&rproc->dev, "warning: remote FW detach without ack\n");
> +	}
> +
> +	/* Allow remote processor to auto-reboot */
> +	return stm32_rproc_set_hold_boot(rproc, false);
> +}
> +
>  static int stm32_rproc_stop(struct rproc *rproc)
>  {
>  	struct stm32_rproc *ddata = rproc->priv;
> @@ -597,7 +626,12 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
>  	}
>  
>  done:
> -	/* Assuming the resource table fits in 1kB is fair */
> +	/*
> +	 * Assuming the resource table fits in 1kB is fair.
> +	 * Notice for the detach, that this 1 kB memory area has to be reserved in the coprocessor
> +	 * firmware for the resource table. On detach, the remoteproc core re-initializes this
> +	 * entire area by overwriting it with the initial values stored in rproc->clean_table.
> +	 */
>  	*table_sz = RSC_TBL_SIZE;
>  	return (struct resource_table *)ddata->rsc_va;
>  }
> @@ -607,6 +641,7 @@ static const struct rproc_ops st_rproc_ops = {
>  	.start		= stm32_rproc_start,
>  	.stop		= stm32_rproc_stop,
>  	.attach		= stm32_rproc_attach,
> +	.detach		= stm32_rproc_detach,
>  	.kick		= stm32_rproc_kick,
>  	.load		= rproc_elf_load_segments,
>  	.parse_fw	= stm32_rproc_parse_fw,
> -- 
> 2.17.1
> 


From daniel.kulesz at posteo.de  Tue Apr 13 23:09:30 2021
From: daniel.kulesz at posteo.de (Daniel Kulesz)
Date: Wed, 14 Apr 2021 00:09:30 +0200
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <YHXneEEiFCwna7X6@weiser.dinsnail.net>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
 <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
 <20210413115837.232c465a@slackpad.fritz.box>
 <YHXneEEiFCwna7X6@weiser.dinsnail.net>
Message-ID: <20210414000930.ea5d7037702f6efb5957e86d@posteo.de>

Hi folks,

I have just made the two changes suggested by Michael to my A64-LTS. My unit is running kernel 5.10.28-1 from Debian unstable (Package "linux-image-5.10.0-6-arm64"). The DTB was built from the one supplied with kernel 5.10.29 (from kernel.org).

Using the modified dtb (with the changes applied), the machine *DOES* boot fine for me.

Cheers, Daniel


On Tue, 13 Apr 2021 20:48:24 +0200
Michael Weiser <michael.weiser at gmx.de> wrote:

> Hi Jernej and Andre,
> 
> On Tue, Apr 13, 2021 at 11:58:37AM +0100, Andre Przywara wrote:
> 
> > > > Daniel, Michael, can you test this on your boards? So removing the
> > > > cd-gpios property, and adding "broken-cd;" instead?  
> > > Yes, it works fine. What flummoxed me at first was that obviously I also
> > > have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
> > > after having added and disabled an ACTIVE_HIGH definition in
> > > sun50i-a64-pine64-lts.dts.
> > Why? From my experiments it should not matter, the actual card presence
> > is typically detected via the SD bus anyway (if I understand the code
> > correctly). broken-cd just prevents installation of an interrupt
> > handler, so it's less efficient and prevents wakeup on card detect,
> > AFAICS.
> 
> I just retested to be sure: At least with 5.11.11 and on my boards,
> cd-gpio ACTIVE_LOW being specified in the sopine.dtsi takes precedence
> over broken-cd being specified in pine64-lts.dts. Could that spoil the
> plan of disabling cd-gpio for the LTS while leaving it enabled for
> Sopine and baseboard?
> 
> Behaviour is as such: With cd-gpios ACTIVE_LOW in sopine.dtsi and
> broken-cd in pine64-lts.dts, card insertion, removal and reinsertion is
> not detected after booting the kernel without a card in the slot. With
> cd-gpios ACTIVE_LOW removed from sopine.dtsi it starts working.
> 
> In diffs for added clarity:
> 
> PAGER= git log --pretty=oneline HEAD~1..HEAD
> aa7258f8f3d48a29bc024ea8c5145bdc4a980e4d (HEAD, tag: v5.11.11) Linux 5.11.11
> 
> - not working on its own:
> 
> index 302e24be0a31..5b0c21e68352 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> @@ -8,3 +8,7 @@ / {
>         compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
>                      "allwinner,sun50i-a64";
>  };
> +
> +&mmc0 {
> +       broken-cd;
> +};
> 
> - working with this additional change:
> 
> index 3402cec87035..ba2b7398993b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> @@ -34,7 +34,6 @@ &mmc0 {
>         vmmc-supply = <&reg_dcdc1>;
>         disable-wp;
>         bus-width = <4>;
> -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>         status = "okay";
>  };
> 
> > So for your particular board (version) you could actually remove the
> > whole &mmc0 node override, use the same node as the SOPine (working
> > active-high CD) and it should work.
> 
> Correct. Again for reasons of laziness I tested with the dts from
> 5.11.11 which is currently running on the board and which still has
> ACTIVE_LOW in sopine.dtsi. Sorry for not being clearer about that.
> 
> But somewhat lucky as well because without ACTIVE_LOW still being set in
> sopine.dtsi I wouldn't have had a way to tell that broken-cd was not
> taking effect and silently have tested the working ACTIVE_HIGH
> definition from sopine.dtsi.
> 
> Or am I somehow making a mess of this?
> 
> > > BTW: My boards have a marking "PINE64-R18-V1_1" and below it
> > > "2017-08-03" on their upper side. On the back it says on one sticker
> > > "Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
> > > "PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
> > > perhaps?  Is there a way to detect this difference in software and add
> > > some sort of quirk handler for it?
> > As Jernej mentioned, this would be U-Boot's task, but I don't see a
> > good reason for it. Firstly, you would need to find a good automatic
> > way of determining the board revision, which I doubt there is. And
> > secondly, I don't see the benefit: It works quite nicely with
> > broken-cd: card removals and insertions are detected automatically,
> > it's just not as efficient (interrupt-driven) as it could be.
> > Or do you see any problems with broken-cd?
> 
> Of course not. My boards have their rootfs on mmc0, so the card is never
> removed and replaced during operation anyway. I was just asking out of
> curiosity.
> 
> And out of curiosity again: Could one have a device tree overlay
> configured manually to be loaded by the bootloader that adds cd-gpio
> ACTIVE_HIGH for mmc0 and disables/overrules broken-cd? Somewhat like so
> (untested):
> 
> /dts-v1/;
> /plugin/;
> 
> #include <dt-bindings/gpio/gpio.h>
> 
> / {
>         fragment at 0 {
>                 target = <&mmc0>;
>                 __overlay__ {
>                         cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 push-push switch */
>                 };
>         };
> };
> 
> Here it would be useful if cd-gpios indeed took precedence over
> broken-cd because my grepping of the code can't find a way to un-specify
> it once set.
> -- 
> Michael


-- 
Daniel Kulesz <daniel.kulesz at posteo.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sun50i-a64-pine64-lts.dtb
Type: application/octet-stream
Size: 27920 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210414/277d156d/attachment-0001.obj>

From patchwork-bot+netdevbpf at kernel.org  Tue Apr 13 23:10:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Tue, 13 Apr 2021 22:10:10 +0000
Subject: [PATCH net-next v2 0/7] stmmac: add XDP ZC support
In-Reply-To: <20210413093626.3447-1-boon.leong.ong@intel.com>
References: <20210413093626.3447-1-boon.leong.ong@intel.com>
Message-ID: <161835181083.31494.7438008757120147305.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Tue, 13 Apr 2021 17:36:19 +0800 you wrote:
> Hi,
> 
> This is the v2 patch series to add XDP ZC support to stmmac driver.
> 
> Summary of v2 patch change:-
> 
> 6/7: fix synchronize_rcu() is called stmmac_disable_all_queues() that is
>      used by ndo_setup_tc().
> 
> [...]

Here is the summary with links:
  - [net-next,v2,1/7] net: stmmac: rearrange RX buffer allocation and free functions
    https://git.kernel.org/netdev/net-next/c/4298255f26fa
  - [net-next,v2,2/7] net: stmmac: introduce dma_recycle_rx_skbufs for stmmac_reinit_rx_buffers
    https://git.kernel.org/netdev/net-next/c/80f573c995fc
  - [net-next,v2,3/7] net: stmmac: refactor stmmac_init_rx_buffers for stmmac_reinit_rx_buffers
    https://git.kernel.org/netdev/net-next/c/da5ec7f22a0f
  - [net-next,v2,4/7] net: stmmac: rearrange RX and TX desc init into per-queue basis
    https://git.kernel.org/netdev/net-next/c/de0b90e52a11
  - [net-next,v2,5/7] net: stmmac: Refactor __stmmac_xdp_run_prog for XDP ZC
    https://git.kernel.org/netdev/net-next/c/bba71cac680f
  - [net-next,v2,6/7] net: stmmac: Enable RX via AF_XDP zero-copy
    https://git.kernel.org/netdev/net-next/c/bba2556efad6
  - [net-next,v2,7/7] net: stmmac: Add TX via XDP zero-copy socket
    https://git.kernel.org/netdev/net-next/c/132c32ee5bc0

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 Apr 13 23:24:52 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:52 +0800
Subject: [soc:fsl/drivers] BUILD SUCCESS
 242b0b398ccd34f73772120bd27a87a1bf00e30b
Message-ID: <60761a34.QaTDTRytzeU9a/QA%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git fsl/drivers
branch HEAD: 242b0b398ccd34f73772120bd27a87a1bf00e30b  soc: fsl: enable acpi support in RCPM driver

elapsed time: 7200m

configs tested: 242
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                       omap2plus_defconfig
m68k                             alldefconfig
sh                          rsk7203_defconfig
powerpc                  storcenter_defconfig
riscv                             allnoconfig
sh                        sh7785lcr_defconfig
nios2                            alldefconfig
m68k                         apollo_defconfig
mips                        omega2p_defconfig
mips                        nlm_xlr_defconfig
powerpc                 mpc8315_rdb_defconfig
h8300                       h8s-sim_defconfig
mips                       bmips_be_defconfig
powerpc                 canyonlands_defconfig
mips                  decstation_64_defconfig
arm                              alldefconfig
sh                           se7206_defconfig
s390                             allmodconfig
riscv             nommu_k210_sdcard_defconfig
sh                           se7343_defconfig
sh                      rts7751r2d1_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
powerpc                       eiger_defconfig
mips                         tb0226_defconfig
s390                       zfcpdump_defconfig
arm                  colibri_pxa300_defconfig
sh                          kfr2r09_defconfig
powerpc                     tqm5200_defconfig
powerpc                      makalu_defconfig
arc                         haps_hs_defconfig
powerpc                     taishan_defconfig
powerpc64                        alldefconfig
powerpc                     ksi8560_defconfig
xtensa                  cadence_csp_defconfig
sh                          rsk7269_defconfig
arm                       cns3420vb_defconfig
ia64                          tiger_defconfig
arc                        nsim_700_defconfig
openrisc                 simple_smp_defconfig
parisc                           alldefconfig
m68k                         amcore_defconfig
powerpc                 mpc834x_mds_defconfig
sh                          rsk7264_defconfig
sh                           se7751_defconfig
ia64                        generic_defconfig
mips                        vocore2_defconfig
powerpc                           allnoconfig
m68k                          hp300_defconfig
sh                            shmin_defconfig
mips                            gpr_defconfig
ia64                             alldefconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
powerpc                      bamboo_defconfig
arm                            xcep_defconfig
mips                        nlm_xlp_defconfig
powerpc                  iss476-smp_defconfig
sh                               j2_defconfig
arm                            mmp2_defconfig
powerpc                         wii_defconfig
mips                      fuloong2e_defconfig
arm                           sama5_defconfig
mips                      maltasmvp_defconfig
sh                          landisk_defconfig
csky                             alldefconfig
powerpc                     tqm8560_defconfig
arm                       spear13xx_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                           h3600_defconfig
arm                       netwinder_defconfig
arm                       imx_v4_v5_defconfig
mips                           ip27_defconfig
mips                         mpc30x_defconfig
s390                                defconfig
arc                                 defconfig
arm                           corgi_defconfig
arc                              allyesconfig
arm                        magician_defconfig
um                                  defconfig
mips                  maltasmvp_eva_defconfig
arm                       versatile_defconfig
sh                          lboxre2_defconfig
arm                            zeus_defconfig
openrisc                         alldefconfig
m68k                          atari_defconfig
powerpc                    gamecube_defconfig
arm                         cm_x300_defconfig
m68k                       m5475evb_defconfig
mips                         bigsur_defconfig
arm                            pleb_defconfig
mips                      pistachio_defconfig
powerpc                     mpc5200_defconfig
h8300                     edosk2674_defconfig
xtensa                  nommu_kc705_defconfig
sh                           se7780_defconfig
powerpc                 mpc8540_ads_defconfig
powerpc                        fsp2_defconfig
arm                   milbeaut_m10v_defconfig
sh                   sh7770_generic_defconfig
mips                     cu1830-neo_defconfig
arc                 nsimosci_hs_smp_defconfig
arm                         hackkit_defconfig
m68k                       m5208evb_defconfig
arm                             ezx_defconfig
arm                          pxa3xx_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                          pxa168_defconfig
mips                           ci20_defconfig
parisc                              defconfig
powerpc                     tqm8548_defconfig
mips                          ath79_defconfig
arm                            mps2_defconfig
m68k                             allyesconfig
ia64                             allyesconfig
microblaze                          defconfig
powerpc                 linkstation_defconfig
powerpc                     pseries_defconfig
arm                           spitz_defconfig
arm                       multi_v4t_defconfig
openrisc                    or1ksim_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc834x_itx_defconfig
sparc64                             defconfig
powerpc                     sequoia_defconfig
um                               allmodconfig
arm                            qcom_defconfig
arm                         bcm2835_defconfig
sh                          rsk7201_defconfig
arc                          axs103_defconfig
ia64                             allmodconfig
sh                          urquell_defconfig
arc                      axs103_smp_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     ppa8548_defconfig
arm                          ep93xx_defconfig
m68k                            mac_defconfig
arm                  colibri_pxa270_defconfig
powerpc                    amigaone_defconfig
powerpc                     powernv_defconfig
powerpc                       ebony_defconfig
sh                        edosk7760_defconfig
arm                           stm32_defconfig
mips                           ip28_defconfig
powerpc                    adder875_defconfig
mips                     loongson1b_defconfig
arm                         mv78xx0_defconfig
arc                          axs101_defconfig
mips                         tb0219_defconfig
parisc                generic-32bit_defconfig
sh                     magicpanelr2_defconfig
ia64                                defconfig
m68k                             allmodconfig
m68k                                defconfig
nios2                               defconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                           allyesconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a003-20210409
i386                 randconfig-a001-20210409
i386                 randconfig-a004-20210409
i386                 randconfig-a002-20210409
i386                 randconfig-a005-20210409
i386                 randconfig-a006-20210409
x86_64               randconfig-a014-20210409
x86_64               randconfig-a015-20210409
x86_64               randconfig-a012-20210409
x86_64               randconfig-a011-20210409
x86_64               randconfig-a013-20210409
x86_64               randconfig-a016-20210409
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
i386                 randconfig-a014-20210409
i386                 randconfig-a011-20210409
i386                 randconfig-a016-20210409
i386                 randconfig-a012-20210409
i386                 randconfig-a013-20210409
i386                 randconfig-a015-20210409
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                                allnoconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210409
x86_64               randconfig-a005-20210409
x86_64               randconfig-a003-20210409
x86_64               randconfig-a001-20210409
x86_64               randconfig-a002-20210409
x86_64               randconfig-a006-20210409
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 13 23:24:56 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:56 +0800
Subject: [soc:for-next] BUILD SUCCESS a3689dbaeca323f7aed8bb718bd74a909f4a13ce
Message-ID: <60761a38.09Tb4znQDVtcIg+2%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: a3689dbaeca323f7aed8bb718bd74a909f4a13ce  soc: document merges

elapsed time: 721m

configs tested: 106
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                       omap2plus_defconfig
m68k                             alldefconfig
sh                          rsk7203_defconfig
powerpc                  storcenter_defconfig
sh                        sh7785lcr_defconfig
h8300                       h8s-sim_defconfig
arc                      axs103_smp_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
mips                         cobalt_defconfig
sh                          rsk7269_defconfig
arm                       cns3420vb_defconfig
ia64                          tiger_defconfig
arc                        nsim_700_defconfig
openrisc                 simple_smp_defconfig
mips                        workpad_defconfig
sh                          polaris_defconfig
powerpc                     tqm5200_defconfig
arm                         assabet_defconfig
arm                            zeus_defconfig
openrisc                         alldefconfig
powerpc                 mpc832x_rdb_defconfig
m68k                          atari_defconfig
powerpc                    gamecube_defconfig
arm                           corgi_defconfig
mips                        omega2p_defconfig
arm                          ixp4xx_defconfig
powerpc                     tqm8540_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 13 23:24:44 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:44 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 40bb91338a60affd2f05a9b8d9d18dbf0e6f9593
Message-ID: <60761a2c.1c1tTetIbxW5CUfT%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: 40bb91338a60affd2f05a9b8d9d18dbf0e6f9593  Merge tag 'zynqmp-dt-for-v5.13' of https://github.com/Xilinx/linux-xlnx into arm/dt

elapsed time: 721m

configs tested: 171
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                       omap2plus_defconfig
m68k                             alldefconfig
sh                          rsk7203_defconfig
powerpc                  storcenter_defconfig
sh                        sh7785lcr_defconfig
riscv                             allnoconfig
h8300                       h8s-sim_defconfig
arc                      axs103_smp_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
mips                         cobalt_defconfig
mips                       bmips_be_defconfig
powerpc                 canyonlands_defconfig
mips                  decstation_64_defconfig
arm                              alldefconfig
arm                             pxa_defconfig
powerpc                     pseries_defconfig
arm                  colibri_pxa270_defconfig
sh                        dreamcast_defconfig
arm                            mps2_defconfig
s390                       zfcpdump_defconfig
arm                  colibri_pxa300_defconfig
nios2                            alldefconfig
sh                          kfr2r09_defconfig
powerpc                     tqm5200_defconfig
powerpc                      makalu_defconfig
arc                         haps_hs_defconfig
powerpc                     taishan_defconfig
powerpc64                        alldefconfig
powerpc                     ksi8560_defconfig
xtensa                  cadence_csp_defconfig
sh                          rsk7269_defconfig
arm                       cns3420vb_defconfig
ia64                          tiger_defconfig
arc                        nsim_700_defconfig
openrisc                 simple_smp_defconfig
m68k                          hp300_defconfig
sh                            shmin_defconfig
mips                            gpr_defconfig
ia64                             alldefconfig
powerpc                      bamboo_defconfig
arm                            xcep_defconfig
mips                        nlm_xlp_defconfig
powerpc                  iss476-smp_defconfig
sh                               j2_defconfig
arm                            mmp2_defconfig
powerpc                         wii_defconfig
mips                         db1xxx_defconfig
sh                            titan_defconfig
m68k                         amcore_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
ia64                            zx1_defconfig
mips                        workpad_defconfig
sh                          polaris_defconfig
arm                         assabet_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                           h3600_defconfig
arm                            zeus_defconfig
openrisc                         alldefconfig
m68k                          atari_defconfig
powerpc                    gamecube_defconfig
powerpc                     mpc5200_defconfig
h8300                     edosk2674_defconfig
xtensa                  nommu_kc705_defconfig
sh                           se7780_defconfig
arm                           corgi_defconfig
mips                        omega2p_defconfig
arm                          ixp4xx_defconfig
powerpc                     tqm8540_defconfig
arm                         hackkit_defconfig
m68k                       m5208evb_defconfig
arm                             ezx_defconfig
arm                          pxa3xx_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                          pxa168_defconfig
mips                           ci20_defconfig
arm                            qcom_defconfig
mips                         mpc30x_defconfig
mips                          ath79_defconfig
powerpc                    amigaone_defconfig
powerpc                     powernv_defconfig
powerpc                       ebony_defconfig
sh                        edosk7760_defconfig
arm                           stm32_defconfig
arc                          axs101_defconfig
powerpc                   motionpro_defconfig
mips                        nlm_xlr_defconfig
m68k                             allyesconfig
mips                         tb0219_defconfig
parisc                generic-32bit_defconfig
microblaze                          defconfig
arm                       multi_v4t_defconfig
sh                     magicpanelr2_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 13 23:24:46 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:46 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 41c39cfc841d3ed0d302edd2a539d752a13fa06e
Message-ID: <60761a2e.Ee70LOt1/DWsHB/M%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: 41c39cfc841d3ed0d302edd2a539d752a13fa06e  Merge tag 'soc-fsl-next-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux into arm/drivers

elapsed time: 721m

configs tested: 119
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
arm                       omap2plus_defconfig
m68k                             alldefconfig
sh                          rsk7203_defconfig
powerpc                  storcenter_defconfig
sh                        sh7785lcr_defconfig
riscv                             allnoconfig
h8300                       h8s-sim_defconfig
arc                      axs103_smp_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
mips                         cobalt_defconfig
mips                       bmips_be_defconfig
powerpc                 canyonlands_defconfig
mips                  decstation_64_defconfig
arm                              alldefconfig
sh                               j2_defconfig
arm                            mmp2_defconfig
powerpc                         wii_defconfig
mips                        workpad_defconfig
sh                          polaris_defconfig
powerpc                     tqm5200_defconfig
arm                         assabet_defconfig
openrisc                 simple_smp_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                           h3600_defconfig
arm                       netwinder_defconfig
arm                           corgi_defconfig
mips                        omega2p_defconfig
arm                          ixp4xx_defconfig
powerpc                     tqm8540_defconfig
arm                          pxa3xx_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                          pxa168_defconfig
mips                           ci20_defconfig
powerpc                    amigaone_defconfig
powerpc                     powernv_defconfig
powerpc                       ebony_defconfig
sh                        edosk7760_defconfig
arm                           stm32_defconfig
arm                       multi_v4t_defconfig
sh                     magicpanelr2_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 13 23:24:54 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:54 +0800
Subject: [soc:rockchip/dt64] BUILD SUCCESS
 5dcbe7e3862dfc89d219f37a9ed5e53944fa13c2
Message-ID: <60761a36.Tj9dVNptfjDezDaO%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rockchip/dt64
branch HEAD: 5dcbe7e3862dfc89d219f37a9ed5e53944fa13c2  arm64: dts: rockchip: move mmc aliases to board dts on rk3399

elapsed time: 3641m

configs tested: 370
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
nios2                               defconfig
sh                   sh7724_generic_defconfig
sparc                            alldefconfig
arm                            xcep_defconfig
um                            kunit_defconfig
mips                         tb0219_defconfig
powerpc                 mpc832x_rdb_defconfig
sh                        sh7763rdp_defconfig
mips                      maltaaprp_defconfig
m68k                             allyesconfig
nios2                            allyesconfig
sh                         microdev_defconfig
sh                             espt_defconfig
riscv             nommu_k210_sdcard_defconfig
mips                           ip32_defconfig
arm                        oxnas_v6_defconfig
arm                       omap2plus_defconfig
m68k                             alldefconfig
sh                          rsk7203_defconfig
powerpc                  storcenter_defconfig
sh                        sh7785lcr_defconfig
riscv                             allnoconfig
powerpc                    klondike_defconfig
mips                           rs90_defconfig
powerpc                     taishan_defconfig
arm                            hisi_defconfig
arm                     am200epdkit_defconfig
mips                     cu1830-neo_defconfig
arm                         s3c2410_defconfig
powerpc                 mpc8315_rdb_defconfig
arc                          axs103_defconfig
powerpc                        fsp2_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                 mpc836x_mds_defconfig
h8300                       h8s-sim_defconfig
arc                      axs103_smp_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
mips                         cobalt_defconfig
nds32                            alldefconfig
powerpc                 mpc834x_itx_defconfig
arc                                 defconfig
sh                         apsh4a3a_defconfig
arm                   milbeaut_m10v_defconfig
arm                         nhk8815_defconfig
mips                           mtx1_defconfig
m68k                       m5249evb_defconfig
mips                          malta_defconfig
arm                          pxa168_defconfig
arm                         cm_x300_defconfig
sh                          landisk_defconfig
mips                       lemote2f_defconfig
mips                       bmips_be_defconfig
powerpc                 canyonlands_defconfig
mips                  decstation_64_defconfig
arm                              alldefconfig
sh                        dreamcast_defconfig
sh                           se7206_defconfig
s390                             allmodconfig
sh                           se7343_defconfig
arc                        vdk_hs38_defconfig
s390                                defconfig
openrisc                         alldefconfig
mips                          rm200_defconfig
powerpc                     skiroot_defconfig
arm                            mps2_defconfig
arm                       aspeed_g4_defconfig
powerpc                      cm5200_defconfig
arm                        mvebu_v7_defconfig
mips                          ath79_defconfig
microblaze                          defconfig
mips                           ip27_defconfig
powerpc                     pq2fads_defconfig
m68k                          atari_defconfig
mips                malta_qemu_32r6_defconfig
arc                           tb10x_defconfig
s390                       zfcpdump_defconfig
arm                  colibri_pxa300_defconfig
nios2                            alldefconfig
sh                          kfr2r09_defconfig
powerpc                     tqm5200_defconfig
powerpc                      makalu_defconfig
arc                         haps_hs_defconfig
powerpc64                        alldefconfig
powerpc                     ksi8560_defconfig
xtensa                  cadence_csp_defconfig
sh                           se7705_defconfig
mips                     loongson1b_defconfig
sh                           se7712_defconfig
mips                     loongson1c_defconfig
mips                            e55_defconfig
arc                          axs101_defconfig
powerpc                     tqm8541_defconfig
arm64                            alldefconfig
m68k                          sun3x_defconfig
arm                          iop32x_defconfig
powerpc                      pcm030_defconfig
arm                         mv78xx0_defconfig
arm                          exynos_defconfig
arm                       multi_v4t_defconfig
mips                           ip22_defconfig
sh                          rsk7269_defconfig
arm                       cns3420vb_defconfig
ia64                          tiger_defconfig
arc                        nsim_700_defconfig
openrisc                 simple_smp_defconfig
sh                          urquell_defconfig
h8300                    h8300h-sim_defconfig
arm                          collie_defconfig
arm                         s3c6400_defconfig
arm                            mmp2_defconfig
m68k                       m5275evb_defconfig
powerpc                     mpc512x_defconfig
arm                           sunxi_defconfig
mips                malta_kvm_guest_defconfig
sh                           se7750_defconfig
powerpc                    gamecube_defconfig
arc                     nsimosci_hs_defconfig
arm                            lart_defconfig
m68k                        mvme16x_defconfig
arm                          ixp4xx_defconfig
s390                             allyesconfig
powerpc                     tqm8555_defconfig
powerpc                     redwood_defconfig
m68k                           sun3_defconfig
sh                         ecovec24_defconfig
powerpc                 mpc85xx_cds_defconfig
m68k                          hp300_defconfig
sh                            shmin_defconfig
mips                            gpr_defconfig
ia64                             alldefconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlp_defconfig
powerpc                  iss476-smp_defconfig
powerpc                      pasemi_defconfig
powerpc                 mpc8540_ads_defconfig
arm                        spear6xx_defconfig
xtensa                  nommu_kc705_defconfig
arm                             pxa_defconfig
xtensa                generic_kc705_defconfig
arm                       imx_v6_v7_defconfig
xtensa                    smp_lx200_defconfig
sparc64                          alldefconfig
arm                        spear3xx_defconfig
powerpc                     sbc8548_defconfig
arm                         assabet_defconfig
xtensa                              defconfig
sh                               j2_defconfig
powerpc                         wii_defconfig
powerpc                    ge_imp3a_defconfig
arm                        trizeps4_defconfig
powerpc                   motionpro_defconfig
sh                ecovec24-romimage_defconfig
h8300                            alldefconfig
powerpc                 linkstation_defconfig
mips                      malta_kvm_defconfig
arm                             rpc_defconfig
powerpc                      ppc64e_defconfig
mips                        workpad_defconfig
sh                          polaris_defconfig
csky                             alldefconfig
powerpc                     tqm8560_defconfig
arm                       spear13xx_defconfig
powerpc                          g5_defconfig
arm                           h3600_defconfig
arm                       netwinder_defconfig
sh                                  defconfig
arm                           sama5_defconfig
sh                        edosk7760_defconfig
sparc64                             defconfig
powerpc                     tqm8548_defconfig
powerpc                        cell_defconfig
sh                          rsk7201_defconfig
arm                           corgi_defconfig
arm                        magician_defconfig
um                                  defconfig
arc                              allyesconfig
mips                        omega2p_defconfig
powerpc                 mpc8272_ads_defconfig
nds32                             allnoconfig
arm                          pxa910_defconfig
powerpc                     ppa8548_defconfig
powerpc                 mpc8313_rdb_defconfig
arm                            zeus_defconfig
arc                     haps_hs_smp_defconfig
mips                        maltaup_defconfig
arm                        realview_defconfig
arm                         hackkit_defconfig
sh                          rsk7264_defconfig
powerpc                        warp_defconfig
arm                             ezx_defconfig
arm                          imote2_defconfig
sh                             sh03_defconfig
arm                         s5pv210_defconfig
powerpc                     tqm8540_defconfig
sh                   rts7751r2dplus_defconfig
mips                         db1xxx_defconfig
mips                      loongson3_defconfig
powerpc                 mpc8560_ads_defconfig
sh                   sh7770_generic_defconfig
sparc                               defconfig
sh                            titan_defconfig
alpha                               defconfig
powerpc                     powernv_defconfig
sh                          r7785rp_defconfig
powerpc                      arches_defconfig
m68k                       m5208evb_defconfig
arm                          pxa3xx_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
mips                           ci20_defconfig
sh                           se7751_defconfig
x86_64                           alldefconfig
powerpc                     kmeter1_defconfig
sparc                       sparc64_defconfig
csky                                defconfig
powerpc                     pseries_defconfig
arm                           spitz_defconfig
openrisc                    or1ksim_defconfig
powerpc                      ppc44x_defconfig
arm                        vexpress_defconfig
mips                      maltasmvp_defconfig
xtensa                         virt_defconfig
arm                      pxa255-idp_defconfig
powerpc                     sequoia_defconfig
arc                              alldefconfig
powerpc                mpc7448_hpc2_defconfig
powerpc                      obs600_defconfig
mips                      bmips_stb_defconfig
sh                           sh2007_defconfig
sh                           se7619_defconfig
um                               allmodconfig
arm                            qcom_defconfig
mips                         mpc30x_defconfig
arm                         bcm2835_defconfig
powerpc                         ps3_defconfig
arm                        mini2440_defconfig
arm                         lpc32xx_defconfig
m68k                        m5272c3_defconfig
mips                           ip28_defconfig
arm                          ep93xx_defconfig
m68k                            mac_defconfig
arm                  colibri_pxa270_defconfig
x86_64                              defconfig
m68k                          multi_defconfig
arm                        clps711x_defconfig
powerpc                    amigaone_defconfig
powerpc                       ebony_defconfig
arm                           stm32_defconfig
m68k                         amcore_defconfig
m68k                        m5307c3_defconfig
powerpc               mpc834x_itxgp_defconfig
arm                            dove_defconfig
m68k                          amiga_defconfig
arm                         vf610m4_defconfig
mips                          ath25_defconfig
mips                 decstation_r4k_defconfig
mips                        nlm_xlr_defconfig
sh                     magicpanelr2_defconfig
mips                     cu1000-neo_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
nds32                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
sparc                            allyesconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
x86_64               randconfig-a003-20210411
x86_64               randconfig-a002-20210411
x86_64               randconfig-a001-20210411
x86_64               randconfig-a005-20210411
x86_64               randconfig-a006-20210411
x86_64               randconfig-a004-20210411
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a003-20210412
i386                 randconfig-a001-20210412
i386                 randconfig-a006-20210412
i386                 randconfig-a005-20210412
i386                 randconfig-a004-20210412
i386                 randconfig-a002-20210412
i386                 randconfig-a003-20210411
i386                 randconfig-a001-20210411
i386                 randconfig-a006-20210411
i386                 randconfig-a005-20210411
i386                 randconfig-a004-20210411
i386                 randconfig-a002-20210411
x86_64               randconfig-a014-20210412
x86_64               randconfig-a015-20210412
x86_64               randconfig-a011-20210412
x86_64               randconfig-a013-20210412
x86_64               randconfig-a012-20210412
x86_64               randconfig-a016-20210412
i386                 randconfig-a015-20210411
i386                 randconfig-a014-20210411
i386                 randconfig-a013-20210411
i386                 randconfig-a012-20210411
i386                 randconfig-a016-20210411
i386                 randconfig-a011-20210411
i386                 randconfig-a015-20210412
i386                 randconfig-a014-20210412
i386                 randconfig-a013-20210412
i386                 randconfig-a012-20210412
i386                 randconfig-a016-20210412
i386                 randconfig-a011-20210412
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                                allnoconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210412
x86_64               randconfig-a002-20210412
x86_64               randconfig-a001-20210412
x86_64               randconfig-a005-20210412
x86_64               randconfig-a006-20210412
x86_64               randconfig-a004-20210412
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413
x86_64               randconfig-a014-20210411
x86_64               randconfig-a015-20210411
x86_64               randconfig-a011-20210411
x86_64               randconfig-a013-20210411
x86_64               randconfig-a012-20210411
x86_64               randconfig-a016-20210411

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 13 23:24:50 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 14 Apr 2021 06:24:50 +0800
Subject: [soc:rockchip/dt] BUILD SUCCESS
 e89db2b4c706b9ca1293e7025ef5e8730b5d1b5b
Message-ID: <60761a32.BksOP5QFDAQGu8MY%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git rockchip/dt
branch HEAD: e89db2b4c706b9ca1293e7025ef5e8730b5d1b5b  ARM: dts: rockchip: move rv1108 mmcx aliases to board dts files

elapsed time: 3641m

configs tested: 375
configs skipped: 96

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
riscv                            allmodconfig
x86_64                           allyesconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                         tb0219_defconfig
powerpc                 mpc832x_rdb_defconfig
sh                        sh7763rdp_defconfig
mips                      maltaaprp_defconfig
m68k                             allyesconfig
arm                           sama5_defconfig
sparc                               defconfig
sh                   sh7770_generic_defconfig
powerpc                mpc7448_hpc2_defconfig
ia64                         bigsur_defconfig
nios2                            allyesconfig
sh                         microdev_defconfig
sh                             espt_defconfig
riscv             nommu_k210_sdcard_defconfig
mips                           ip32_defconfig
arm                        oxnas_v6_defconfig
powerpc                    klondike_defconfig
mips                           rs90_defconfig
powerpc                     taishan_defconfig
arm                            hisi_defconfig
arm                     am200epdkit_defconfig
mips                     cu1830-neo_defconfig
arm                         s3c2410_defconfig
powerpc                 mpc8315_rdb_defconfig
arc                          axs103_defconfig
powerpc                        fsp2_defconfig
sh                  sh7785lcr_32bit_defconfig
powerpc                 mpc836x_mds_defconfig
h8300                       h8s-sim_defconfig
arc                      axs103_smp_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
riscv                             allnoconfig
mips                         cobalt_defconfig
nds32                            alldefconfig
powerpc                 mpc834x_itx_defconfig
arc                                 defconfig
sh                         apsh4a3a_defconfig
arm                   milbeaut_m10v_defconfig
arm                         nhk8815_defconfig
sh                          rsk7269_defconfig
sh                             sh03_defconfig
ia64                                defconfig
openrisc                 simple_smp_defconfig
mips                       bmips_be_defconfig
powerpc                 canyonlands_defconfig
mips                  decstation_64_defconfig
arm                              alldefconfig
sparc                       sparc32_defconfig
arm                          simpad_defconfig
powerpc                        icon_defconfig
arm                            qcom_defconfig
m68k                          amiga_defconfig
powerpc                       ppc64_defconfig
sh                           se7721_defconfig
sh                           se7206_defconfig
s390                             allmodconfig
sh                           se7343_defconfig
arm                       omap2plus_defconfig
arc                        vdk_hs38_defconfig
arm                            xcep_defconfig
s390                                defconfig
openrisc                         alldefconfig
mips                          rm200_defconfig
powerpc                     skiroot_defconfig
arm                            mps2_defconfig
arm                       aspeed_g4_defconfig
powerpc                      cm5200_defconfig
arm                        mvebu_v7_defconfig
mips                          ath79_defconfig
microblaze                          defconfig
mips                           ip27_defconfig
powerpc                     pq2fads_defconfig
m68k                          atari_defconfig
mips                malta_qemu_32r6_defconfig
arc                           tb10x_defconfig
powerpc                      mgcoge_defconfig
arm                        mvebu_v5_defconfig
m68k                             allmodconfig
powerpc                     sbc8548_defconfig
sh                            shmin_defconfig
sh                          polaris_defconfig
um                             i386_defconfig
arm                       multi_v4t_defconfig
xtensa                           alldefconfig
s390                       zfcpdump_defconfig
arm                  colibri_pxa300_defconfig
nios2                            alldefconfig
sh                          kfr2r09_defconfig
powerpc                     tqm5200_defconfig
powerpc                      makalu_defconfig
arc                         haps_hs_defconfig
powerpc64                        alldefconfig
powerpc                     ksi8560_defconfig
xtensa                  cadence_csp_defconfig
sh                           se7705_defconfig
mips                     loongson1b_defconfig
sh                           se7712_defconfig
mips                     loongson1c_defconfig
mips                            e55_defconfig
arc                          axs101_defconfig
powerpc                     tqm8541_defconfig
arm64                            alldefconfig
m68k                          sun3x_defconfig
arm                          iop32x_defconfig
powerpc                      pcm030_defconfig
arm                         mv78xx0_defconfig
arm                          exynos_defconfig
mips                           ip22_defconfig
arm                       cns3420vb_defconfig
ia64                          tiger_defconfig
arc                        nsim_700_defconfig
sh                          urquell_defconfig
h8300                    h8300h-sim_defconfig
arm                          collie_defconfig
mips                malta_kvm_guest_defconfig
sh                           se7750_defconfig
powerpc                    gamecube_defconfig
arc                     nsimosci_hs_defconfig
m68k                       m5208evb_defconfig
parisc                              defconfig
parisc                generic-64bit_defconfig
xtensa                       common_defconfig
arm                            lart_defconfig
m68k                        mvme16x_defconfig
arm                          ixp4xx_defconfig
powerpc                     tqm8555_defconfig
powerpc                     redwood_defconfig
m68k                           sun3_defconfig
sh                         ecovec24_defconfig
powerpc                 mpc85xx_cds_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlp_defconfig
powerpc                  iss476-smp_defconfig
powerpc                      pasemi_defconfig
powerpc                 mpc8540_ads_defconfig
arm                        spear6xx_defconfig
xtensa                  nommu_kc705_defconfig
sh                                  defconfig
nds32                               defconfig
sh                           se7619_defconfig
arm                          pxa910_defconfig
arm                         assabet_defconfig
xtensa                              defconfig
sh                               j2_defconfig
arm                            mmp2_defconfig
powerpc                         wii_defconfig
mips                         db1xxx_defconfig
sh                            titan_defconfig
m68k                         amcore_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
ia64                            zx1_defconfig
arm                         bcm2835_defconfig
sh                     sh7710voipgw_defconfig
mips                        vocore2_defconfig
arm                           sunxi_defconfig
powerpc                    ge_imp3a_defconfig
arm                        trizeps4_defconfig
powerpc                   motionpro_defconfig
sh                ecovec24-romimage_defconfig
h8300                            alldefconfig
powerpc                 linkstation_defconfig
mips                      malta_kvm_defconfig
arm                             rpc_defconfig
powerpc                      ppc64e_defconfig
mips                        workpad_defconfig
sh                          landisk_defconfig
csky                             alldefconfig
powerpc                     tqm8560_defconfig
arm                       spear13xx_defconfig
arm                           h3600_defconfig
sh                        edosk7760_defconfig
sparc64                             defconfig
powerpc                     tqm8548_defconfig
powerpc                        cell_defconfig
sh                          rsk7201_defconfig
arm                           corgi_defconfig
arc                              allyesconfig
mips                        omega2p_defconfig
arm                        magician_defconfig
um                                  defconfig
powerpc                 mpc8272_ads_defconfig
nds32                             allnoconfig
powerpc                     ppa8548_defconfig
m68k                          hp300_defconfig
powerpc                 mpc8313_rdb_defconfig
arm                            zeus_defconfig
arc                     haps_hs_smp_defconfig
mips                        maltaup_defconfig
arm                        realview_defconfig
arm                         hackkit_defconfig
sh                          rsk7264_defconfig
powerpc                        warp_defconfig
arm                             ezx_defconfig
arm                          imote2_defconfig
sh                   sh7724_generic_defconfig
arm                         s5pv210_defconfig
powerpc                     tqm8540_defconfig
sh                   rts7751r2dplus_defconfig
m68k                       m5249evb_defconfig
mips                      loongson3_defconfig
mips                           jazz_defconfig
powerpc                 mpc8560_ads_defconfig
alpha                               defconfig
arm                             pxa_defconfig
mips                     cu1000-neo_defconfig
mips                        jmr3927_defconfig
sparc                       sparc64_defconfig
arm                          pxa3xx_defconfig
powerpc                      ep88xc_defconfig
powerpc                     rainier_defconfig
arm                          pxa168_defconfig
mips                           ci20_defconfig
sh                           se7751_defconfig
x86_64                           alldefconfig
powerpc                     kmeter1_defconfig
arm                         cm_x300_defconfig
powerpc                     pseries_defconfig
arm                           spitz_defconfig
openrisc                    or1ksim_defconfig
powerpc                      ppc44x_defconfig
powerpc                    sam440ep_defconfig
s390                             alldefconfig
powerpc                      ppc40x_defconfig
arm                        vexpress_defconfig
mips                      maltasmvp_defconfig
xtensa                         virt_defconfig
arm                      pxa255-idp_defconfig
powerpc                     sequoia_defconfig
arc                              alldefconfig
powerpc                      obs600_defconfig
mips                      bmips_stb_defconfig
sh                           sh2007_defconfig
um                               allmodconfig
mips                         mpc30x_defconfig
powerpc                         ps3_defconfig
nios2                               defconfig
powerpc                      katmai_defconfig
arm                        mini2440_defconfig
arm                         lpc32xx_defconfig
m68k                        m5272c3_defconfig
um                           x86_64_defconfig
mips                        qi_lb60_defconfig
arm                          ep93xx_defconfig
m68k                            mac_defconfig
arm                  colibri_pxa270_defconfig
x86_64                              defconfig
m68k                          multi_defconfig
arm                        clps711x_defconfig
powerpc                    amigaone_defconfig
powerpc                     powernv_defconfig
powerpc                       ebony_defconfig
arm                           stm32_defconfig
sh                        sh7785lcr_defconfig
m68k                        m5307c3_defconfig
powerpc               mpc834x_itxgp_defconfig
arm                            dove_defconfig
arm                         vf610m4_defconfig
mips                          ath25_defconfig
mips                 decstation_r4k_defconfig
mips                        nlm_xlr_defconfig
mips                            gpr_defconfig
sh                          r7785rp_defconfig
parisc                generic-32bit_defconfig
sh                     magicpanelr2_defconfig
arm                         s3c6400_defconfig
ia64                             allmodconfig
ia64                             allyesconfig
m68k                                defconfig
csky                                defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
sh                               allmodconfig
s390                             allyesconfig
parisc                           allyesconfig
sparc                            allyesconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
x86_64               randconfig-a003-20210411
x86_64               randconfig-a002-20210411
x86_64               randconfig-a001-20210411
x86_64               randconfig-a005-20210411
x86_64               randconfig-a006-20210411
x86_64               randconfig-a004-20210411
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a003-20210412
i386                 randconfig-a001-20210412
i386                 randconfig-a006-20210412
i386                 randconfig-a005-20210412
i386                 randconfig-a004-20210412
i386                 randconfig-a002-20210412
i386                 randconfig-a003-20210411
i386                 randconfig-a001-20210411
i386                 randconfig-a006-20210411
i386                 randconfig-a005-20210411
i386                 randconfig-a004-20210411
i386                 randconfig-a002-20210411
x86_64               randconfig-a014-20210412
x86_64               randconfig-a015-20210412
x86_64               randconfig-a011-20210412
x86_64               randconfig-a013-20210412
x86_64               randconfig-a012-20210412
x86_64               randconfig-a016-20210412
i386                 randconfig-a015-20210411
i386                 randconfig-a014-20210411
i386                 randconfig-a013-20210411
i386                 randconfig-a012-20210411
i386                 randconfig-a016-20210411
i386                 randconfig-a011-20210411
i386                 randconfig-a015-20210412
i386                 randconfig-a014-20210412
i386                 randconfig-a013-20210412
i386                 randconfig-a012-20210412
i386                 randconfig-a016-20210412
i386                 randconfig-a011-20210412
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                                allnoconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210412
x86_64               randconfig-a002-20210412
x86_64               randconfig-a001-20210412
x86_64               randconfig-a005-20210412
x86_64               randconfig-a006-20210412
x86_64               randconfig-a004-20210412
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413
x86_64               randconfig-a014-20210411
x86_64               randconfig-a015-20210411
x86_64               randconfig-a011-20210411
x86_64               randconfig-a013-20210411
x86_64               randconfig-a012-20210411
x86_64               randconfig-a016-20210411

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From nm at ti.com  Tue Apr 13 23:32:03 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 13 Apr 2021 17:32:03 -0500
Subject: [PATCH] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
In-Reply-To: <20210413171230.5872-1-nm@ti.com>
References: <20210413171230.5872-1-nm@ti.com>
Message-ID: <20210413223203.fracjesde642msmv@blaspheme>

On 12:12-20210413, Nishanth Menon wrote:
[...]
> +properties:
> +  $nodename:
> +    pattern: "^mailbox@[0-9a-f]+$"
> +
> +  compatible:
> +    const: ti,am654-secure-proxy
> +
> +  "#mbox-cells":
> +    const: 1
> +
> +  reg-names:
> +    items:
> +      - const: target_data
> +      - const: rt
> +      - const: scfg
> +
> +  reg:
> +    minItems: 3
> +
> +  interrupt-names:
> +    minItems: 1
> +    description:
> +      Contains the interrupt name information for the Rx interrupt path for
> +      secure proxy.
> +
> +  interrupts:
> +    minItems: 1
> +    description:
> +      Contains the interrupt information for the Rx interrupt path for secure


I think I can strengthen it quite a bit here. let me post a v2 further
that has lesser information loss in the conversion and checks are
stronger.


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


From nm at ti.com  Tue Apr 13 23:45:35 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 13 Apr 2021 17:45:35 -0500
Subject: [PATCH V2] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
Message-ID: <20210413224535.30910-1-nm@ti.com>

Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
  tisci node definition
- Switched reg usage for address-cells and size-cells 1 - aligned with
  schema checks as well
- included header in example for buildable example

While at this, lets make sure to support upto 100 rx threads even though
typically upto 1 threads is practically in use.

NOTE: The following checkpatch warning is generated since we do include the header
in the example, but this is a false positive warning.
  WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst

Signed-off-by: Nishanth Menon <nm at ti.com>
---
Changes since V1: (Thanks Suman for some offline comments)
- Strengthened interrupt-names property to be on rails
- More documentation (we dont want an information loss between txt and
  yaml)
- Added a max interrupts of 100, which is a rather conservative limit on
  current devices, but who knows..
- Commit message updates
- compatible is a simpler const.
- interrupt-names are required property - makes no sense in not knowing
  which interrupts belong to which thread irqs.

V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1-nm at ti.com/

 .../bindings/mailbox/ti,secure-proxy.txt      | 50 ------------
 .../bindings/mailbox/ti,secure-proxy.yaml     | 79 +++++++++++++++++++
 2 files changed, 79 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..000000000000
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-========================================
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===========================
-Required properties:
---------------------
-- compatible:		Shall be "ti,am654-secure-proxy"
-- reg-names 		target_data - Map the proxy data region
-			rt - Map the realtime status region
-			scfg - Map the configuration region
-- reg:			Contains the register map per reg-names.
-- #mbox-cells		Shall be 1 and shall refer to the transfer path
-			called thread.
-- interrupt-names:	Contains interrupt names matching the rx transfer path
-			for a given SoC. Receive interrupts shall be of the
-			format: "rx_<PID>".
-- interrupts:		Contains the interrupt information corresponding to
-			interrupt-names property.
-
-Example(AM654):
-------------
-
-	secure_proxy: mailbox at 32c00000 {
-		compatible = "ti,am654-secure-proxy";
-		#mbox-cells = <1>;
-		reg-names = "target_data", "rt", "scfg";
-		reg = <0x0 0x32c00000 0x0 0x100000>,
-		      <0x0 0x32400000 0x0 0x100000>,
-		      <0x0 0x32800000 0x0 0x100000>;
-		interrupt-names = "rx_011";
-		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-	};
-
-	dmsc: dmsc {
-		[...]
-		mbox-names = "rx", "tx";
-		# RX Thread ID is 11
-		# TX Thread ID is 13
-		mboxes= <&secure_proxy 11>,
-			<&secure_proxy 13>;
-		[...]
-	};
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index 000000000000..08a4837fdfcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  The Texas Instruments' secure proxy is a mailbox controller that has
+  configurable queues selectable at SoC(System on Chip) integration. The
+  Message manager is broken up into different address regions that are
+  called "threads" or "proxies" - each instance is unidirectional and is
+  instantiated at SoC integration level by system controller to indicate
+  receive or transmit path.
+
+properties:
+  $nodename:
+    pattern: "^mailbox@[0-9a-f]+$"
+
+  compatible:
+    const: ti,am654-secure-proxy
+
+  "#mbox-cells":
+    const: 1
+    description:
+      Contains the secure proxy thread ID used for the specific transfer path.
+
+  reg-names:
+    items:
+      - const: target_data
+      - const: rt
+      - const: scfg
+
+  reg:
+    minItems: 3
+
+  interrupt-names:
+    minItems: 1
+    maxItems: 100
+    items:
+      - pattern: "^rx_[0-9]{3}$"
+    description:
+      Contains the interrupt name information for the Rx interrupt path for
+      secure proxy thread in the form 'rx_<PID>'.
+
+  interrupts:
+    minItems: 1
+    maxItems: 100
+    description:
+      Contains the interrupt information for the Rx interrupt path for secure
+      proxy.
+
+required:
+  - compatible
+  - reg-names
+  - reg
+  - interrupt-names
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    secure_proxy: mailbox at 32c00000 {
+          compatible = "ti,am654-secure-proxy";
+          #mbox-cells = <1>;
+          reg-names = "target_data", "rt", "scfg";
+          reg = <0x32c00000 0x100000>,
+                <0x32400000 0x100000>,
+                <0x32800000 0x100000>;
+          interrupt-names = "rx_011";
+          interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+    };
-- 
2.31.0



From jpoimboe at redhat.com  Tue Apr 13 23:53:10 2021
From: jpoimboe at redhat.com (Josh Poimboeuf)
Date: Tue, 13 Apr 2021 17:53:10 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210412165933.GD5379@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
 <20210409223227.rvf6tfhvgnpzmabn@treble>
 <20210412165933.GD5379@sirena.org.uk>
Message-ID: <20210413225310.k64wqjnst7cia4ft@treble>

On Mon, Apr 12, 2021 at 05:59:33PM +0100, Mark Brown wrote:
> On Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote:
> 
> > Hm, for that matter, even without renaming things, a comment above
> > stack_trace_save_tsk_reliable() describing the meaning of "reliable"
> > would be a good idea.
> 
> Might be better to place something at the prototype for
> arch_stack_walk_reliable() or cross link the two since that's where any
> new architectures should be starting, or perhaps even better to extend
> the document that Mark wrote further and point to that from both places.  
> 
> Some more explict pointer to live patching as the only user would
> definitely be good but I think the more important thing would be writing
> down any assumptions in the API that aren't already written down and
> we're supposed to be relying on.  Mark's document captured a lot of it
> but it sounds like there's more here, and even with knowing that this
> interface is only used by live patch and digging into what it does it's
> not always clear what happens to work with the code right now and what's
> something that's suitable to be relied on.

Something like so?

From: Josh Poimboeuf <jpoimboe at redhat.com>
Subject: [PATCH] livepatch: Clarify the meaning of 'reliable'

Update the comments and documentation to reflect what 'reliable'
unwinding actually means, in the context of live patching.

Suggested-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com>
---
 .../livepatch/reliable-stacktrace.rst         | 26 +++++++++++++----
 arch/x86/kernel/stacktrace.c                  |  6 ----
 include/linux/stacktrace.h                    | 29 +++++++++++++++++--
 kernel/stacktrace.c                           |  7 ++++-
 4 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
index 67459d2ca2af..e325efc7e952 100644
--- a/Documentation/livepatch/reliable-stacktrace.rst
+++ b/Documentation/livepatch/reliable-stacktrace.rst
@@ -72,7 +72,21 @@ The unwinding process varies across architectures, their respective procedure
 call standards, and kernel configurations. This section describes common
 details that architectures should consider.
 
-4.1 Identifying successful termination
+4.1 Only preemptible code needs reliability detection
+-----------------------------------------------------
+
+The only current user of reliable stacktracing is livepatch, which only
+calls it for a) inactive tasks; or b) the current task in task context.
+
+Therefore, the unwinder only needs to detect the reliability of stacks
+involving *preemptible* code.
+
+Practically speaking, reliability of stacks involving *non-preemptible*
+code is a "don't-care".  It may help to return a wrong reliability
+result for such cases, if it results in reduced complexity, since such
+cases will not happen in practice.
+
+4.2 Identifying successful termination
 --------------------------------------
 
 Unwinding may terminate early for a number of reasons, including:
@@ -95,7 +109,7 @@ architectures verify that a stacktrace ends at an expected location, e.g.
 * On a specific stack expected for a kernel entry point (e.g. if the
   architecture has separate task and IRQ stacks).
 
-4.2 Identifying unwindable code
+4.3 Identifying unwindable code
 -------------------------------
 
 Unwinding typically relies on code following specific conventions (e.g.
@@ -129,7 +143,7 @@ unreliable to unwind from, e.g.
 
 * Identifying specific portions of code using bounds information.
 
-4.3 Unwinding across interrupts and exceptions
+4.4 Unwinding across interrupts and exceptions
 ----------------------------------------------
 
 At function call boundaries the stack and other unwind state is expected to be
@@ -156,7 +170,7 @@ have no such cases) should attempt to unwind across exception boundaries, as
 doing so can prevent unnecessarily stalling livepatch consistency checks and
 permits livepatch transitions to complete more quickly.
 
-4.4 Rewriting of return addresses
+4.5 Rewriting of return addresses
 ---------------------------------
 
 Some trampolines temporarily modify the return address of a function in order
@@ -222,7 +236,7 @@ middle of return_to_handler and can report this as unreliable. Architectures
 are not required to unwind from other trampolines which modify the return
 address.
 
-4.5 Obscuring of return addresses
+4.6 Obscuring of return addresses
 ---------------------------------
 
 Some trampolines do not rewrite the return address in order to intercept
@@ -249,7 +263,7 @@ than the link register as would usually be the case.
 Architectures must either ensure that unwinders either reliably unwind
 such cases, or report the unwinding as unreliable.
 
-4.6 Link register unreliability
+4.7 Link register unreliability
 -------------------------------
 
 On some other architectures, 'call' instructions place the return address into a
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 8627fda8d993..15b058eefc4e 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -29,12 +29,6 @@ void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
 	}
 }
 
-/*
- * This function returns an error if it detects any unreliable features of the
- * stack.  Otherwise it guarantees that the stack trace is reliable.
- *
- * If the task is not 'current', the caller *must* ensure the task is inactive.
- */
 int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry,
 			     void *cookie, struct task_struct *task)
 {
diff --git a/include/linux/stacktrace.h b/include/linux/stacktrace.h
index 50e2df30b0aa..1b6a65a0ad22 100644
--- a/include/linux/stacktrace.h
+++ b/include/linux/stacktrace.h
@@ -26,7 +26,7 @@ unsigned int stack_trace_save_user(unsigned long *store, unsigned int size);
 #ifdef CONFIG_ARCH_STACKWALK
 
 /**
- * stack_trace_consume_fn - Callback for arch_stack_walk()
+ * stack_trace_consume_fn() - Callback for arch_stack_walk()
  * @cookie:	Caller supplied pointer handed back by arch_stack_walk()
  * @addr:	The stack entry address to consume
  *
@@ -35,7 +35,7 @@ unsigned int stack_trace_save_user(unsigned long *store, unsigned int size);
  */
 typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr);
 /**
- * arch_stack_walk - Architecture specific function to walk the stack
+ * arch_stack_walk() - Architecture specific function to walk the stack
  * @consume_entry:	Callback which is invoked by the architecture code for
  *			each entry.
  * @cookie:		Caller supplied pointer which is handed back to
@@ -52,8 +52,33 @@ typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr);
  */
 void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
 		     struct task_struct *task, struct pt_regs *regs);
+
+/**
+ * arch_stack_walk_reliable() - Architecture specific function to walk the
+ *				stack, with stack reliability check
+ * @consume_entry:	Callback which is invoked by the architecture code for
+ *			each entry.
+ * @cookie:		Caller supplied pointer which is handed back to
+ *			@consume_entry
+ * @task:		Pointer to a task struct, can be NULL for current
+ *
+ * Return: 0 if the stack trace is considered reliable for livepatch; else < 0.
+ *
+ * NOTE: This interface is only used by livepatch.  The caller must ensure that
+ *	 it's only called in one of the following two scenarios:
+ *
+ *	 a) the task is inactive (and guaranteed to remain so); or
+ *
+ *	 b) the task is 'current', running in task context.
+ *
+ * Effectively, this means the arch unwinder doesn't need to detect the
+ * reliability of stacks involving non-preemptible code.
+ *
+ * For more details, see Documentation/livepatch/reliable-stacktrace.rst.
+ */
 int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry, void *cookie,
 			     struct task_struct *task);
+
 void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
 			  const struct pt_regs *regs);
 
diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c
index 9f8117c7cfdd..a198fd194fed 100644
--- a/kernel/stacktrace.c
+++ b/kernel/stacktrace.c
@@ -185,7 +185,12 @@ unsigned int stack_trace_save_regs(struct pt_regs *regs, unsigned long *store,
  *		stack. Otherwise it guarantees that the stack trace is
  *		reliable and returns the number of entries stored.
  *
- * If the task is not 'current', the caller *must* ensure the task is inactive.
+ * NOTE: This interface is only used by livepatch.  The caller must ensure that
+ *	 it's only called in one of the following two scenarios:
+ *
+ *	 a) the task is inactive (and guaranteed to remain so); or
+ *
+ *	 b) the task is 'current', running in task context.
  */
 int stack_trace_save_tsk_reliable(struct task_struct *tsk, unsigned long *store,
 				  unsigned int size)
-- 
2.30.2



From ndesaulniers at google.com  Wed Apr 14 00:06:06 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Tue, 13 Apr 2021 16:06:06 -0700
Subject: [PATCH] arm64: vdso32: drop -no-integrated-as flag
Message-ID: <20210413230609.3114365-1-ndesaulniers@google.com>

Clang can assemble these files just fine; this is a relic from the top
level Makefile conditionally adding this.

To test building:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
  CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
  defconfig arch/arm64/kernel/vdso32/

Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
---
 arch/arm64/kernel/vdso32/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 789ad420f16b..7812717f8b79 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -15,7 +15,7 @@ COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
 
 CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
 CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
-CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
+CC_COMPAT_CLANG_FLAGS += -Qunused-arguments
 ifneq ($(COMPAT_GCC_TOOLCHAIN),)
 CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
 endif
-- 
2.31.1.295.g9ea45b61b8-goog



From nathan at kernel.org  Wed Apr 14 00:12:02 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 13 Apr 2021 16:12:02 -0700
Subject: [PATCH] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210413230609.3114365-1-ndesaulniers@google.com>
References: <20210413230609.3114365-1-ndesaulniers@google.com>
Message-ID: <YHYlQnFRMNdn/CDp@archlinux-ax161>

On Tue, Apr 13, 2021 at 04:06:06PM -0700, Nick Desaulniers wrote:
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/
> 
> Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
> ---
>  arch/arm64/kernel/vdso32/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 789ad420f16b..7812717f8b79 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -15,7 +15,7 @@ COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
>  
>  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
>  CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
> -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> +CC_COMPAT_CLANG_FLAGS += -Qunused-arguments

Might as well just eliminate '--prefix=' and '--gcc-toolchain=' along
with the variables COMPAT_GCC_TOOLCHAIN_DIR and COMPAT_GCC_TOOLCHAIN
while you are at it, they serve no purpose without '-no-integrated-as'.

>  ifneq ($(COMPAT_GCC_TOOLCHAIN),)
>  CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
>  endif
> -- 
> 2.31.1.295.g9ea45b61b8-goog
> 
> 


From chunkuang.hu at kernel.org  Wed Apr 14 00:38:13 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Wed, 14 Apr 2021 07:38:13 +0800
Subject: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix
 incorrect mbox-cells value"
In-Reply-To: <1618226325-31927-4-git-send-email-yongqiang.niu@mediatek.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618226325-31927-4-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <CAAOTY__zcdjA-tu4kNtWjy=37_HZV1U2fS6=k4OBAbjfNwC9Ow@mail.gmail.com>

Hi, Yongqiang:

Yongqiang Niu <yongqiang.niu at mediatek.com> ? 2021?4?12? ?? ??7:19???
>
> This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f.
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> ---
>  Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> index 7771eca..cf48cd8 100644
> --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> @@ -47,7 +47,7 @@ Example:
>                 interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
>                 clocks = <&infracfg CLK_INFRA_GCE>;
>                 clock-names = "gce";
> -               #mbox-cells = <2>;
> +               #mbox-cells = <3>;

I think we should not change the binding just to fix software bug.
I think there are many temporary solution to fix drm bug. If drm bug
is caused by cursor plane, you could temporarily let drm not support
cursor plane to fix it (in [1], do not return DRM_PLANE_TYPE_CURSOR).
But I would like you to find out the correct solution rather than a
temporary solution because this bug is not so urgent. (For me, bug of
build fail, boot fail, black screen is urgent).

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mediatek/mtk_drm_crtc.c?h=v5.12-rc7#n699

Regards,
Chun-Kuang.

>         };
>
>  Example for a client device:
> --
> 1.8.1.1.dirty
>


From nathan at kernel.org  Wed Apr 14 01:08:04 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Tue, 13 Apr 2021 17:08:04 -0700
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn, endif}
Message-ID: <20210414000803.662534-1-nathan@kernel.org>

After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
set atomically"), LLVM's integrated assembler fails to build entry.S:

<instantiation>:5:7: error: expected assembly-time absolute expression
 .org . - (664b-663b) + (662b-661b)
      ^
<instantiation>:6:7: error: expected assembly-time absolute expression
 .org . - (662b-661b) + (664b-663b)
      ^

The root cause is LLVM's assembler has a one-pass design, meaning it
cannot figure out these instruction lengths when the .org directive is
outside of the subsection that they are in, which was changed by the
.arch_extension directive added in the above commit.

Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
length validation inside the subsection") to the alternative_endif
macro, shuffling the .org directives so that the length validation
happen will always happen in the same subsections. alternative_insn has
not shown any issue yet but it appears that it could have the same issue
in the future so just preemptively change it.

Cc: stable at vger.kernel.org
Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
Link: https://github.com/ClangBuiltLinux/linux/issues/1347
Signed-off-by: Nathan Chancellor <nathan at kernel.org>
---

Apologies if my explanation or terminology is off, I am only now getting
more familiar with assembly.

 arch/arm64/include/asm/alternative-macros.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/alternative-macros.h b/arch/arm64/include/asm/alternative-macros.h
index 5df500dcc627..8a078fc662ac 100644
--- a/arch/arm64/include/asm/alternative-macros.h
+++ b/arch/arm64/include/asm/alternative-macros.h
@@ -97,9 +97,9 @@
 	.popsection
 	.subsection 1
 663:	\insn2
-664:	.previous
-	.org	. - (664b-663b) + (662b-661b)
+664:	.org	. - (664b-663b) + (662b-661b)
 	.org	. - (662b-661b) + (664b-663b)
+	.previous
 	.endif
 .endm
 
@@ -169,11 +169,11 @@
  */
 .macro alternative_endif
 664:
+	.org	. - (664b-663b) + (662b-661b)
+	.org	. - (662b-661b) + (664b-663b)
 	.if .Lasm_alt_mode==0
 	.previous
 	.endif
-	.org	. - (664b-663b) + (662b-661b)
-	.org	. - (662b-661b) + (664b-663b)
 .endm
 
 /*

base-commit: 738fa58ee1328481d1d7889e7c430b3401c571b9
-- 
2.31.1.272.g89b43f80a5



From vee.khee.wong at linux.intel.com  Wed Apr 14 01:16:17 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Wed, 14 Apr 2021 08:16:17 +0800
Subject: [PATCH net-next v4 1/1] net: stmmac: Add support for external trigger
 timestamping
Message-ID: <20210414001617.3490-1-vee.khee.wong@linux.intel.com>

From: Tan Tee Min <tee.min.tan at intel.com>

The Synopsis MAC controller supports auxiliary snapshot feature that
allows user to store a snapshot of the system time based on an external
event.

This patch add supports to the above mentioned feature. Users will be
able to triggered capturing the time snapshot from user-space using
application such as testptp or any other applications that uses the
PTP_EXTTS_REQUEST ioctl request.

Cc: Richard Cochran <richardcochran at gmail.com>
Signed-off-by: Tan Tee Min <tee.min.tan at intel.com>
Co-developed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
v3 -> v4:
  - Group variable of same datatype together in oneline.
  - Removed unnecessary mutex_unlock()
  - Added mutex_destroy() on ptp_unregister().
v2 -> v3:
  - Flip ext_snapshot_en condition check for early return.
v1 -> v2:
  - Changed from pr_info() to netdev_dbg().
---
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 10 +++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  5 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  3 ++
 .../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 39 ++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 +
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.c  | 40 ++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_ptp.h  |  1 +
 include/linux/stmmac.h                        |  2 +
 8 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 60566598d644..ec140fc4a0f5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -296,6 +296,13 @@ static int intel_crosststamp(ktime_t *device,
 
 	intel_priv = priv->plat->bsp_priv;
 
+	/* Both internal crosstimestamping and external triggered event
+	 * timestamping cannot be run concurrently.
+	 */
+	if (priv->plat->ext_snapshot_en)
+		return -EBUSY;
+
+	mutex_lock(&priv->aux_ts_lock);
 	/* Enable Internal snapshot trigger */
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value &= ~PTP_ACR_MASK;
@@ -321,6 +328,8 @@ static int intel_crosststamp(ktime_t *device,
 	acr_value = readl(ptpaddr + PTP_ACR);
 	acr_value |= PTP_ACR_ATSFC;
 	writel(acr_value, ptpaddr + PTP_ACR);
+	/* Release the mutex */
+	mutex_unlock(&priv->aux_ts_lock);
 
 	/* Trigger Internal snapshot signal
 	 * Create a rising edge by just toggle the GPO1 to low
@@ -520,6 +529,7 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->mdio_bus_data->phy_mask |= 1 << INTEL_MGBE_XPCS_ADDR;
 
 	plat->int_snapshot_num = AUX_SNAPSHOT1;
+	plat->ext_snapshot_num = AUX_SNAPSHOT0;
 
 	plat->has_crossts = true;
 	plat->crosststamp = intel_crosststamp;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2b5022ef1e52..2cc91759b91f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -504,6 +504,8 @@ struct stmmac_ops {
 #define stmmac_fpe_irq_status(__priv, __args...) \
 	stmmac_do_callback(__priv, mac, fpe_irq_status, __args)
 
+struct stmmac_priv;
+
 /* PTP and HW Timer helpers */
 struct stmmac_hwtimestamp {
 	void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
@@ -515,6 +517,7 @@ struct stmmac_hwtimestamp {
 			       int add_sub, int gmac4);
 	void (*get_systime) (void __iomem *ioaddr, u64 *systime);
 	void (*get_ptptime)(void __iomem *ioaddr, u64 *ptp_time);
+	void (*timestamp_interrupt)(struct stmmac_priv *priv);
 };
 
 #define stmmac_config_hw_tstamping(__priv, __args...) \
@@ -531,6 +534,8 @@ struct stmmac_hwtimestamp {
 	stmmac_do_void_callback(__priv, ptp, get_systime, __args)
 #define stmmac_get_ptptime(__priv, __args...) \
 	stmmac_do_void_callback(__priv, ptp, get_ptptime, __args)
+#define stmmac_timestamp_interrupt(__priv, __args...) \
+	stmmac_do_void_callback(__priv, ptp, timestamp_interrupt, __args)
 
 /* Helpers to manage the descriptors for chain and ring modes */
 struct stmmac_mode_ops {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index b8a42260066d..b6cd43eda7ac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -250,6 +250,9 @@ struct stmmac_priv {
 	int use_riwt;
 	int irq_wake;
 	spinlock_t ptp_lock;
+	/* Protects auxiliary snapshot registers from concurrent access. */
+	struct mutex aux_ts_lock;
+
 	void __iomem *mmcaddr;
 	void __iomem *ptpaddr;
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 113c51bcc0b5..074e2cdfb0fa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -12,8 +12,11 @@
 #include <linux/io.h>
 #include <linux/iopoll.h>
 #include <linux/delay.h>
+#include <linux/ptp_clock_kernel.h>
 #include "common.h"
 #include "stmmac_ptp.h"
+#include "dwmac4.h"
+#include "stmmac.h"
 
 static void config_hw_tstamping(void __iomem *ioaddr, u32 data)
 {
@@ -163,6 +166,41 @@ static void get_ptptime(void __iomem *ptpaddr, u64 *ptp_time)
 	*ptp_time = ns;
 }
 
+static void timestamp_interrupt(struct stmmac_priv *priv)
+{
+	u32 num_snapshot, ts_status, tsync_int;
+	struct ptp_clock_event event;
+	unsigned long flags;
+	u64 ptp_time;
+	int i;
+
+	tsync_int = readl(priv->ioaddr + GMAC_INT_STATUS) & GMAC_INT_TSIE;
+
+	if (!tsync_int)
+		return;
+
+	/* Read timestamp status to clear interrupt from either external
+	 * timestamp or start/end of PPS.
+	 */
+	ts_status = readl(priv->ioaddr + GMAC_TIMESTAMP_STATUS);
+
+	if (!priv->plat->ext_snapshot_en)
+		return;
+
+	num_snapshot = (ts_status & GMAC_TIMESTAMP_ATSNS_MASK) >>
+		       GMAC_TIMESTAMP_ATSNS_SHIFT;
+
+	for (i = 0; i < num_snapshot; i++) {
+		spin_lock_irqsave(&priv->ptp_lock, flags);
+		get_ptptime(priv->ptpaddr, &ptp_time);
+		spin_unlock_irqrestore(&priv->ptp_lock, flags);
+		event.type = PTP_CLOCK_EXTTS;
+		event.index = 0;
+		event.timestamp = ptp_time;
+		ptp_clock_event(priv->ptp_clock, &event);
+	}
+}
+
 const struct stmmac_hwtimestamp stmmac_ptp = {
 	.config_hw_tstamping = config_hw_tstamping,
 	.init_systime = init_systime,
@@ -171,4 +209,5 @@ const struct stmmac_hwtimestamp stmmac_ptp = {
 	.adjust_systime = adjust_systime,
 	.get_systime = get_systime,
 	.get_ptptime = get_ptptime,
+	.timestamp_interrupt = timestamp_interrupt,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e3e22200a4fd..3a5ca5833ce1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5687,6 +5687,8 @@ static void stmmac_common_interrupt(struct stmmac_priv *priv)
 			else
 				netif_carrier_off(priv->dev);
 		}
+
+		stmmac_timestamp_interrupt(priv, priv);
 	}
 }
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
index b164ae22e35f..4e86cdf2bc9f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
@@ -135,7 +135,10 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 {
 	struct stmmac_priv *priv =
 	    container_of(ptp, struct stmmac_priv, ptp_clock_ops);
+	void __iomem *ptpaddr = priv->ptpaddr;
+	void __iomem *ioaddr = priv->hw->pcsr;
 	struct stmmac_pps_cfg *cfg;
+	u32 intr_value, acr_value;
 	int ret = -EOPNOTSUPP;
 	unsigned long flags;
 
@@ -159,6 +162,37 @@ static int stmmac_enable(struct ptp_clock_info *ptp,
 					     priv->systime_flags);
 		spin_unlock_irqrestore(&priv->ptp_lock, flags);
 		break;
+	case PTP_CLK_REQ_EXTTS:
+		priv->plat->ext_snapshot_en = on;
+		mutex_lock(&priv->aux_ts_lock);
+		acr_value = readl(ptpaddr + PTP_ACR);
+		acr_value &= ~PTP_ACR_MASK;
+		if (on) {
+			/* Enable External snapshot trigger */
+			acr_value |= priv->plat->ext_snapshot_num;
+			acr_value |= PTP_ACR_ATSFC;
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d enabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Enable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value |= GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+
+		} else {
+			netdev_dbg(priv->dev, "Auxiliary Snapshot %d disabled.\n",
+				   priv->plat->ext_snapshot_num >>
+				   PTP_ACR_ATSEN_SHIFT);
+			/* Disable Timestamp Interrupt */
+			intr_value = readl(ioaddr + GMAC_INT_EN);
+			intr_value &= ~GMAC_INT_TSIE;
+			writel(intr_value, ioaddr + GMAC_INT_EN);
+		}
+		writel(acr_value, ptpaddr + PTP_ACR);
+		mutex_unlock(&priv->aux_ts_lock);
+		ret = 0;
+		break;
+
 	default:
 		break;
 	}
@@ -202,7 +236,7 @@ static struct ptp_clock_info stmmac_ptp_clock_ops = {
 	.name = "stmmac ptp",
 	.max_adj = 62500000,
 	.n_alarm = 0,
-	.n_ext_ts = 0,
+	.n_ext_ts = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_per_out = 0, /* will be overwritten in stmmac_ptp_register */
 	.n_pins = 0,
 	.pps = 0,
@@ -237,8 +271,10 @@ void stmmac_ptp_register(struct stmmac_priv *priv)
 		stmmac_ptp_clock_ops.max_adj = priv->plat->ptp_max_adj;
 
 	stmmac_ptp_clock_ops.n_per_out = priv->dma_cap.pps_out_num;
+	stmmac_ptp_clock_ops.n_ext_ts = priv->dma_cap.aux_snapshot_n;
 
 	spin_lock_init(&priv->ptp_lock);
+	mutex_init(&priv->aux_ts_lock);
 	priv->ptp_clock_ops = stmmac_ptp_clock_ops;
 
 	priv->ptp_clock = ptp_clock_register(&priv->ptp_clock_ops,
@@ -264,4 +300,6 @@ void stmmac_ptp_unregister(struct stmmac_priv *priv)
 		pr_debug("Removed PTP HW clock successfully on %s\n",
 			 priv->dev->name);
 	}
+
+	mutex_destroy(&priv->aux_ts_lock);
 }
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
index f88727ce4d30..53172a439810 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
@@ -73,6 +73,7 @@
 #define	PTP_ACR_ATSEN1		BIT(5)	/* Auxiliary Snapshot 1 Enable */
 #define	PTP_ACR_ATSEN2		BIT(6)	/* Auxiliary Snapshot 2 Enable */
 #define	PTP_ACR_ATSEN3		BIT(7)	/* Auxiliary Snapshot 3 Enable */
+#define	PTP_ACR_ATSEN_SHIFT	5	/* Auxiliary Snapshot shift */
 #define	PTP_ACR_MASK		GENMASK(7, 4)	/* Aux Snapshot Mask */
 #define	PMC_ART_VALUE0		0x01	/* PMC_ART[15:0] timer value */
 #define	PMC_ART_VALUE1		0x02	/* PMC_ART[31:16] timer value */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index e338ef7abc00..97edb31d6310 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -238,6 +238,8 @@ struct plat_stmmacenet_data {
 	struct pci_dev *pdev;
 	bool has_crossts;
 	int int_snapshot_num;
+	int ext_snapshot_num;
+	bool ext_snapshot_en;
 	bool multi_msi_en;
 	int msi_mac_vec;
 	int msi_wol_vec;
-- 
2.25.1



From nm at ti.com  Wed Apr 14 01:19:26 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 13 Apr 2021 19:19:26 -0500
Subject: [PATCH] ARM: dts: keystone-k2g: Rename message-manager node
Message-ID: <20210414001926.20002-1-nm@ti.com>

Rename message-manager instance node name to be better aligned with
current style of device tree nodes for mailboxes.

Signed-off-by: Nishanth Menon <nm at ti.com>
---

Santosh:
- This is'nt critical to queue up for 5.13-rc1 window, but just getting
  it out of the way. I noticed it as I was converting the binding to
  yaml. (patch for yaml conversion for the node follows)

 arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 05a75019275e..e5c813b5556d 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -242,7 +242,7 @@ dsp0: dsp at 10800000 {
 			status = "disabled";
 		};
 
-		msgmgr: msgmgr at 2a00000 {
+		msgmgr: mailbox at 2a00000 {
 			compatible = "ti,k2g-message-manager";
 			#mbox-cells = <2>;
 			reg-names = "queue_proxy_region",
-- 
2.31.0



From nm at ti.com  Wed Apr 14 01:27:21 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 13 Apr 2021 19:27:21 -0500
Subject: [PATCH] dt-bindings: mailbox: ti,message-manager: Convert to yaml
Message-ID: <20210414002721.23638-1-nm@ti.com>

Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
  tisci node definition
- included header in example for buildable example

NOTE: The following checkpatch warning is generated since we do include
the header
in the example, but this is a false positive warning.
  WARNING: DT binding docs and includes should be a separate patch. See:
  Documentation/devicetree/bindings/submitting-patches.rst

Signed-off-by: Nishanth Menon <nm at ti.com>
---

Depending on how [1] turns out in discussion, we might want to queue [2]
appropriately.

[1] https://lore.kernel.org/linux-arm-kernel/CAK8P3a1L8rWpR5b66v6Su8-m7-scA0wZQr_g_4KnV4dnrky6ZA at mail.gmail.com/
[2] https://lore.kernel.org/linux-arm-kernel/20210414001926.20002-1-nm at ti.com/
 .../bindings/mailbox/ti,message-manager.txt   | 50 -------------
 .../bindings/mailbox/ti,message-manager.yaml  | 75 +++++++++++++++++++
 2 files changed, 75 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
deleted file mode 100644
index ebf0e3710cee..000000000000
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Message Manager Driver
-========================================
-
-The Texas Instruments' Message Manager is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The Message
-manager is broken up into queues in different address regions that are called
-"proxies" - each instance is unidirectional and is instantiated at SoC
-integration level to indicate receive or transmit path.
-
-Message Manager Device Node:
-===========================
-Required properties:
---------------------
-- compatible:		Shall be: "ti,k2g-message-manager"
-- reg-names 		queue_proxy_region - Map the queue proxy region.
-			queue_state_debug_region - Map the queue state debug
-			region.
-- reg:			Contains the register map per reg-names.
-- #mbox-cells		Shall be 2. Contains the queue ID and proxy ID in that
-		        order referring to the transfer path.
-- interrupt-names:	Contains interrupt names matching the rx transfer path
-			for a given SoC. Receive interrupts shall be of the
-			format: "rx_<QID>".
-			For ti,k2g-message-manager, this shall contain:
-				"rx_005", "rx_057"
-- interrupts:		Contains the interrupt information corresponding to
-			interrupt-names property.
-
-Example(K2G):
-------------
-
-	msgmgr: msgmgr at 2a00000 {
-		compatible = "ti,k2g-message-manager";
-		#mbox-cells = <2>;
-		reg-names = "queue_proxy_region", "queue_state_debug_region";
-		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
-		interrupt-names = "rx_005", "rx_057";
-		interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
-	};
-
-	pmmc: pmmc {
-		[...]
-		mbox-names = "rx", "tx";
-		# RX queue ID is 5, proxy ID is 2
-		# TX queue ID is 0, proxy ID is 0
-		mboxes= <&msgmgr 5 2>,
-			<&msgmgr 0 0>;
-		[...]
-	};
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
new file mode 100644
index 000000000000..4987e803ac37
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Message Manager Driver
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  The Texas Instruments' Message Manager is a mailbox controller that has
+  configurable queues selectable at SoC(System on Chip) integration. The Message
+  manager is broken up into queues in different address regions that are called
+  "proxies" - each instance is unidirectional and is instantiated at SoC
+  integration level to indicate receive or transmit path.
+
+properties:
+  $nodename:
+    pattern: "^mailbox@[0-9a-f]+$"
+
+  compatible:
+    const: ti,k2g-message-manager
+
+  "#mbox-cells":
+    const: 2
+    description:
+      Contains the queue ID and proxy ID in that order referring to the
+      transfer path.
+
+  reg-names:
+    items:
+      - const: queue_proxy_region
+      - const: queue_state_debug_region
+
+  reg:
+    minItems: 2
+
+  interrupt-names:
+    items:
+      - const: rx_005
+      - const: rx_057
+    description:
+      Contains interrupt names matching the Rx transfer path for a given SoC.
+      Receive interrupts shall be of the format "rx_<QID>".
+
+  interrupts:
+    minItems: 2
+    description:
+      Contains the interrupt information for the Rx interrupt paths for message
+      manager corresponding to the interrupt-names.
+
+required:
+  - compatible
+  - reg-names
+  - reg
+  - interrupt-names
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    msgmgr: mailbox at 2a00000 {
+          compatible = "ti,k2g-message-manager";
+          #mbox-cells = <2>;
+          reg-names = "queue_proxy_region", "queue_state_debug_region";
+          reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
+          interrupt-names = "rx_005", "rx_057";
+          interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+                       <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
+    };
-- 
2.31.0



From andrew at aj.id.au  Wed Apr 14 01:30:20 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Wed, 14 Apr 2021 10:00:20 +0930
Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?=
 =?UTF-8?Q?vice_interface?=
In-Reply-To: <CAK8P3a1VFKuewt65RUK6hFAhZYSFFVUX7_nuJLoZW2WoPXGVTw@mail.gmail.com>
References: <20210319062752.145730-1-andrew@aj.id.au>
 <20210319062752.145730-16-andrew@aj.id.au>
 <CAK8P3a1HDQdbTAT4aRMLu-VFz720ynPqPHG5b22NZ5p5QfUqOw@mail.gmail.com>
 <ba63f830-4758-49aa-a63e-f204a8eec1b4@www.fastmail.com>
 <CAK8P3a3RXr5CR7DJgD9rEkN8owpPxXRgzRnPB_5LuQcHkzc4LA@mail.gmail.com>
 <e2d7268b-bdaf-45bf-bb21-a5b9f7e985a4@www.fastmail.com>
 <CAK8P3a1VFKuewt65RUK6hFAhZYSFFVUX7_nuJLoZW2WoPXGVTw@mail.gmail.com>
Message-ID: <37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com>



On Tue, 13 Apr 2021, at 17:52, Arnd Bergmann wrote:
> On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote:
> > > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote:
> > > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery <andrew at aj.id.au> wrote:
> > > > > >
> > > > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests.
> > > > > > However, KCS devices are useful beyond IPMI (or keyboards), as they
> > > > > > provide a means to generate IRQs and exchange arbitrary data between a
> > > > > > BMC and its host system.
> > > > >
> > > > > I only noticed the series after Joel asked about the DT changes on the arm
> > > > > side. One question though:
> > > > >
> > > > > How does this related to the drivers/input/serio/ framework that also talks
> > > > > to the keyboard controller for things that are not keyboards?
> > > >
> > > > I've taken a brief look and I feel they're somewhat closely related.
> > > >
> > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton
> > > > KCS drivers move under drivers/input/serio. If you squint, the i8042
> > > > serio device driver has similarities with what the Aspeed and Nuvoton
> > > > device drivers are providing to the KCS IPMI stack.
> > >
> > > After looking some more into it, I finally understood that the two are
> > > rather complementary. While the  drivers/char/ipmi/kcs_bmc.c
> > > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems
> > > that the proposed kcs_bmc_cdev_raw.c interface would be
> > > what corresponds to the other side of
> > > drivers/input/serio/i8042.c+userio.c.
> >
> > Right. I guess the question is should we be splitting kernel subsystems
> > along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe
> > we can consolidate in the future if it makes sense?
> 
> We actually have a number of subsystems with somewhat overlapping
> functionality. I brought up serio, because it has an abstraction for multiple
> things that communicate over the keyboard controller and I thought
> the problem you were trying to solve was also related to the keyboard
> controller.
> It is also one of multiple abstractions that allow you to connect a device
> to a uart (along with serdev and tty_ldisc, probably at least one more that
> you can nest above or below these).
> 
> Consolidating the kcs_bmc.c interface into something that already
> exists would obviously be best, but it's not clear which of these that
> should be, that depends on the fundamental properties of the hardware
> interface.
> 
> > > Then again, these are also on
> > > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC
> > > KCS), so they would never actually talk to one another.
> >
> > Well, sort of I guess. On Power systems we don't use the keyboard
> > controller for IPMI or keyboards, so we're just kinda exploiting the
> > hardware for our own purposes.
> 
> Can you describe in an abstract form what the hardware interface
> can do here and what you want from it? I wonder if it could be
> part of a higher-level interface such as drivers/mailbox/ instead.

It gives us interrupts each way between the host and BMC when we send 
some (small amount of) data/metadata. Mailbox is possibly a fit for 
this? We're (ab)using the keyboard controllers to implement a vendor 
MCTP binding over LPC[1] and also a simple protocol for the (Power) 
host to trigger BMC debug data capture in the event of issues with 
other (more complex) in-band communication stacks. The MCTP binding is 
what requires access to STR.

It's feasible that we could implement the debug capture protocol with 
the serio_raw interface now that I think about it (as it only makes use 
of data and not status). What's unclear to me right now is what impact 
that has on the Aspeed/Nuvoton KCS drivers we have in the IPMI 
subsystem. If we can do something sensible to service both serio and 
IPMI with the one driver implementation then I can put together a PoC 
for the debug data stuff using serio_raw.

Regarding the MCTP binding, Jeremy Kerr is working in an in-kernel, 
socket-based implementation of MCTP. Eventually this will allow us to 
bury the KCS details in the MCTP subsystem, which removes some of the 
motivation for the raw interface here.

Andrew

[1] https://github.com/openbmc/libmctp/blob/master/docs/bindings/vendor-ibm-astlpc.md


From qii.wang at mediatek.com  Wed Apr 14 02:37:24 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Wed, 14 Apr 2021 09:37:24 +0800
Subject: [RESEND] i2c: mediatek: Get device clock-stretch time via dts
In-Reply-To: <20210413201740.GC2751@kunai>
References: <1615622664-15032-1-git-send-email-qii.wang@mediatek.com>
 <20210406194856.GF3122@kunai> <1617797706.32076.1.camel@mhfsdcap03>
 <20210407181936.GA1614@kunai> <1618228994.32225.3.camel@mhfsdcap03>
 <20210413201740.GC2751@kunai>
Message-ID: <1618364244.32225.21.camel@mhfsdcap03>

On Tue, 2021-04-13 at 22:17 +0200, Wolfram Sang wrote:
> On Mon, Apr 12, 2021 at 08:03:14PM +0800, Qii Wang wrote:
> > I can't see the relationship between "i2c-scl-falling-time-ns" and clock
> > stretching, is there a parameter related to clock stretching?
> 
> ( you wrote "i2c-scl-falling-time-ns" above, didn't you mean
> "i2c-scl-internal-delay-ns" instead? )
> 

I am sorry, I have confused your comment with lkjoon's comment in the
last mail. what I actually want to say is "i2c-scl-internal-delay-ns".

> Not yet, and I wonder if there can be one. In I2C (not SMBus), devices
> are allowed to stretch the clock as long as they want, so what should be
> specified here?
> 
> I suggesteed "internal-delay" because AFAIU your hardware needs this
> delay to be able to cope with clock stretching.
> 

If there is not a maximum value for clock stretching,
"i2c-scl-internal-delay-ns" should be a good choice for our hardware,
although it maybe not for clock stretching.

> > If you think both of them will affect the ac-timing of SCL, at this
> > point, "i2c-scl-falling-time-ns" maybe a good choice.
> 
> Do you mean "i2c-scl-falling-time-ns" or "i2c-scl-internal-delay-ns"?
> 

"i2c-scl-internal-delay-ns" is better.

Thanks for your review.
Qii



From richard.xnu.clark at gmail.com  Wed Apr 14 02:45:21 2021
From: richard.xnu.clark at gmail.com (richard clark)
Date: Wed, 14 Apr 2021 09:45:21 +0800
Subject: Question: multiple SMMUv3 devices probe
In-Reply-To: <YHWVWiQpS93lRNly@myrica>
References: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
 <YG6v2m1P8cbhRnJU@myrica>
 <CAJNi4rPx=oh7iv=4=-5PV-7OAgkZzr5zLysgTjr3YVKzHsC44w@mail.gmail.com>
 <YHWVWiQpS93lRNly@myrica>
Message-ID: <CAJNi4rPo47c3GL9jDUuy4N=7aunKUgr3-oPxtVj=YZaNs=fvKQ@mail.gmail.com>

Jean-Philippe Brucker <jean-philippe at linaro.org> ?2021?4?13??? ??8:58???
>
> On Tue, Apr 13, 2021 at 08:40:47PM +0800, richard clark wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Apr 07, 2021 at 05:37:52PM +0800, richard clark wrote:
> > > > Hi guys,
> > > > There're 3 SMMUv3 devices in my arm64 box. I am confused by the below
> > > > probe process:
> > > >
> > > > arm_smmu_device_probe(...) --> arm_smmu_set_bus_ops(&arm_smmu_ops):
> > > > if (platform_bus_type.iommu_ops != ops) {
> > > >         err = bus_set_iommu(&platform_bus_type, ops);
> > > >         if (err)
> > > > }
> > > >
> > > > so for the 1st smmu device on the platform_bus, the
> > > > arm_smmu_device_probe(...) will set the platform_bus_type.iommu_bus =
> > > > arm_smmu_ops, so for the arm_smmu_device_probe(...) when probing the
> > > > 2nd smmu device, the bus_set_iommu() will have no chance be called
> > > > since the platform_bus_type.iommu_bus == arm_smmu_ops is true, my
> > > > question is how the followed bus_set_iommu(...) being called?
> > >
> > > arm_smmu_ops is the same for all SMMU devices, so bus_set_iommu() only
> > > needs to be called once.
> > >
> > Actually, my question is a if pci device driver probes its device
> > before the SMMUv3 driver probing,
> > how does that pci device using the DMA with SMMU translation?
>
> It doesn't - by looking at the dependencies described in device-tree
(forget to reply all, so add the CC'ing...)
I understand 'it doesn't' here means the pci driver will not probe its
device before SMMU driver is on
> (iommu-map property) or in ACPI IORT, we defer probe of the PCI device
> until the SMMU is operational.
>
If that is correct, Jean, would you point me to the code snippet that
a pci driver will defer
its probe until the SMMU is functional? Some key points are enough...

> Thanks,
> Jean


From yongqiang.niu at mediatek.com  Wed Apr 14 02:49:17 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Wed, 14 Apr 2021 09:49:17 +0800
Subject: [PATCH v2, 3/5] Revert "dt-bindings: mailbox: mtk-gce: fix
 incorrect mbox-cells value"
In-Reply-To: <CAAOTY__zcdjA-tu4kNtWjy=37_HZV1U2fS6=k4OBAbjfNwC9Ow@mail.gmail.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618226325-31927-4-git-send-email-yongqiang.niu@mediatek.com>
 <CAAOTY__zcdjA-tu4kNtWjy=37_HZV1U2fS6=k4OBAbjfNwC9Ow@mail.gmail.com>
Message-ID: <1618364957.9156.3.camel@mhfsdcap03>

On Wed, 2021-04-14 at 07:38 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
> 
> Yongqiang Niu <yongqiang.niu at mediatek.com> ? 2021?4?12? ?? ??7:19???
> >
> > This reverts commit f83b03fc727ab56a77e68713d6e40299698f3c9f.
> >
> > Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> > ---
> >  Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > index 7771eca..cf48cd8 100644
> > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > @@ -47,7 +47,7 @@ Example:
> >                 interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
> >                 clocks = <&infracfg CLK_INFRA_GCE>;
> >                 clock-names = "gce";
> > -               #mbox-cells = <2>;
> > +               #mbox-cells = <3>;
> 
> I think we should not change the binding just to fix software bug.
> I think there are many temporary solution to fix drm bug. If drm bug
> is caused by cursor plane, you could temporarily let drm not support
> cursor plane to fix it (in [1], do not return DRM_PLANE_TYPE_CURSOR).
> But I would like you to find out the correct solution rather than a
> temporary solution because this bug is not so urgent. (For me, bug of
> build fail, boot fail, black screen is urgent).
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mediatek/mtk_drm_crtc.c?h=v5.12-rc7#n699
> 
> Regards,
> Chun-Kuang.

this not drm bug, but caused by cmdq patch
https://patchwork.kernel.org/project/linux-mediatek/patch/20200214043325.16618-3-bibby.hsieh at mediatek.com/
before this patch, drm cursor and ui works well
after this patch, ui will flash when move cursor

this is critical issue,

> 
> >         };
> >
> >  Example for a client device:
> > --
> > 1.8.1.1.dirty
> >


From victor.liu at nxp.com  Wed Apr 14 03:24:22 2021
From: victor.liu at nxp.com (Liu Ying)
Date: Wed, 14 Apr 2021 10:24:22 +0800
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <83a41b2e9636cb6a790b23843c6d2628d02c6997.camel@pengutronix.de>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
 <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
 <YHWk9V/4mu1lGFgD@phenom.ffwll.local>
 <83a41b2e9636cb6a790b23843c6d2628d02c6997.camel@pengutronix.de>
Message-ID: <9395e1fde2725d4fe01c206d9172b8acd7cdf921.camel@nxp.com>

Hi Daniel,

On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > > Since
> > > > 
> > > > commit 890880ddfdbe256083170866e49c87618b706ac7
> > > > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > > > Date:   Fri Jan 4 09:56:10 2019 +0100
> > > > 
> > > >     drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > > > 
> > > > this is done automatically as part of plane init, if drivers set the
> > > > modifier list correctly. Which is the case here.
> > > > 
> > > > This one actually set it twice on top of what drm_plane_init does, so
> > > > double-redundant!
> > > 
> > > That's not true. imx-dcss and imx-drm are two totally separate drivers.
> > > Maybe we should move imx-drm into its own ipuv3 directory one day to
> > > make this more clear. Change is still correct, though.
> > 
> > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the
> > imx main driver ... where are planes set up for that? Need to review that
> > they have the modifiers listed in all cases.
> 
> That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always
> set on plane init.
> 
> Regards,
> Lucas
> 
> > > Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> > > 
> > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > Cc: Shawn Guo <shawnguo at kernel.org>
> > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > Cc: NXP Linux Team <linux-imx at nxp.com>
> > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > ---
> > > >  drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> > > >  drivers/gpu/drm/imx/imx-drm-core.c  | 1 -

Nit: Since this patch touches two totally separate drivers(imx-dcss and
imx-drm), it would be good to split it into two patches.

Thanks,
Liu Ying

> > > >  2 files changed, 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > index b549ce5e7607..37ae68a7fba5 100644
> > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> > > >  	config->min_height = 1;
> > > >  	config->max_width = 4096;
> > > >  	config->max_height = 4096;
> > > > -	config->allow_fb_modifiers = true;
> > > >  	config->normalize_zpos = true;
> > > >  
> > > > 
> > > > 
> > > > 
> > > >  	config->funcs = &dcss_drm_mode_config_funcs;
> > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > index 2ded8e4f32d0..8be4edaec958 100644
> > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> > > >  	drm->mode_config.max_height = 4096;
> > > >  	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > > >  	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > > > -	drm->mode_config.allow_fb_modifiers = true;
> > > >  	drm->mode_config.normalize_zpos = true;
> > > >  
> > > > 
> > > > 
> > > > 
> > > >  	ret = drmm_mode_config_init(drm);
> 
> 



From alex.kogan at oracle.com  Wed Apr 14 03:29:07 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Tue, 13 Apr 2021 22:29:07 -0400
Subject: [External] : Re: [PATCH v14 3/6] locking/qspinlock: Introduce CNA
 into the slow path of qspinlock
In-Reply-To: <YHWAvjymlE5svU71@hirez.programming.kicks-ass.net>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-4-alex.kogan@oracle.com>
 <YHWAvjymlE5svU71@hirez.programming.kicks-ass.net>
Message-ID: <DB82B452-C879-445D-BBFE-DF4FD7597798@oracle.com>

Peter, thanks for all the comments and suggestions!

> On Apr 13, 2021, at 7:30 AM, Peter Zijlstra <peterz at infradead.org> wrote:
> 
> On Thu, Apr 01, 2021 at 11:31:53AM -0400, Alex Kogan wrote:
> 
>> +/*
>> + * cna_splice_tail -- splice the next node from the primary queue onto
>> + * the secondary queue.
>> + */
>> +static void cna_splice_next(struct mcs_spinlock *node,
>> +			    struct mcs_spinlock *next,
>> +			    struct mcs_spinlock *nnext)
> 
> You forgot to update the comment when you changed the name on this
> thing.
Good catch, thanks.

> 
>> +/*
>> + * cna_order_queue - check whether the next waiter in the main queue is on
>> + * the same NUMA node as the lock holder; if not, and it has a waiter behind
>> + * it in the main queue, move the former onto the secondary queue.
>> + */
>> +static void cna_order_queue(struct mcs_spinlock *node)
>> +{
>> +	struct mcs_spinlock *next = READ_ONCE(node->next);
>> +	struct cna_node *cn = (struct cna_node *)node;
>> +	int numa_node, next_numa_node;
>> +
>> +	if (!next) {
>> +		cn->partial_order = LOCAL_WAITER_NOT_FOUND;
>> +		return;
>> +	}
>> +
>> +	numa_node = cn->numa_node;
>> +	next_numa_node = ((struct cna_node *)next)->numa_node;
>> +
>> +	if (next_numa_node != numa_node) {
>> +		struct mcs_spinlock *nnext = READ_ONCE(next->next);
>> +
>> +		if (nnext) {
>> +			cna_splice_next(node, next, nnext);
>> +			next = nnext;
>> +		}
>> +		/*
>> +		 * Inherit NUMA node id of primary queue, to maintain the
>> +		 * preference even if the next waiter is on a different node.
>> +		 */
>> +		((struct cna_node *)next)->numa_node = numa_node;
>> +	}
>> +}
> 
> So the obvious change since last time I looked a this is that it now
> only looks 1 entry ahead. Which makes sense I suppose.
This is in response to the critique that the worst-case time complexity of
cna_order_queue() was O(n). With this change, the complexity is constant.

> 
> I'm not really a fan of the 'partial_order' name combined with that
> silly enum { LOCAL_WAITER_FOUND, LOCAL_WAITER_NOT_FOUND }. That's just
> really bad naming all around. The enum is about having a waiter while
> the variable is about partial order, that doesn't match at all.
Fair enough.

> If you rename the variable to 'has_waiter' and simply use 0,1 values,
> things would be ever so more readable. But I don't think that makes
> sense, see below.
> 
> I'm also not sure about that whole numa_node thing, why would you
> over-write the numa node, why at this point ?
With this move-one-by-one approach, I want to keep the NUMA-node 
preference of the lock holder even if the next-next waiter is on a different
NUMA-node. Otherwise, we will end up switching preference often and
the entire scheme would not perform well. In particular, we might easily
end up with threads from the preferred node waiting in the secondary queue.

> 
>> +
>> +/* Abuse the pv_wait_head_or_lock() hook to get some work done */
>> +static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
>> +						 struct mcs_spinlock *node)
>> +{
>> +	/*
>> +	 * Try and put the time otherwise spent spin waiting on
>> +	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
>> +	 */
>> +	cna_order_queue(node);
>> +
>> +	return 0; /* we lied; we didn't wait, go do so now */
> 
> So here we inspect one entry ahead and then quit. I can't rmember, but
> did we try something like:
> 
> 	/*
> 	 * Try and put the time otherwise spent spin waiting on
> 	 * _Q_LOCKED_PENDING_MASK to use by sorting our lists.
> 	 * Move one entry at a go until either the list is fully
> 	 * sorted or we ran out of spin condition.
> 	 */
> 	while (READ_ONCE(lock->val) & _Q_LOCKED_PENDING_MASK &&
> 	       node->partial_order)
> 		cna_order_queue(node);
> 
> 	return 0;
> 
> This will keep moving @next to the remote list until such a time that
> we're forced to continue or @next is local.
We have not tried that. This is actually an interesting idea, with its pros and cons.
That is, we are likely to filter out ?non-preferred? waiters into the secondary queue
faster, but also we are more likely to run into a situation where the lock becomes
available at the time we are running the cna_order_queue() logic, thus prolonging
the handover time.

With this change, however, there is no need to call cna_order_queue() again 
in cna_lock_handoff(), which is another advantage I guess.

All in all, I am fine switching to this alternative if you like it more.

BTW, we can return node->partial_order instead of 0, to skip the call to
atomic_cond_read_acquire() in the general code.

> 
>> +}
>> +
>> +static inline void cna_lock_handoff(struct mcs_spinlock *node,
>> +				 struct mcs_spinlock *next)
>> +{
>> +	struct cna_node *cn = (struct cna_node *)node;
>> +	u32 val = 1;
>> +
>> +	u32 partial_order = cn->partial_order;
>> +
>> +	if (partial_order == LOCAL_WAITER_NOT_FOUND)
>> +		cna_order_queue(node);
>> +
> 
> AFAICT this is where playing silly games with ->numa_node belong; but
> right along with that goes a comment that describes why any of that
> makes sense.
> 
> I mean, if you leave your node, for any reason, why bother coming back
> to it, why not accept it is a sign of the gods you're overdue for a
> node-change?
I think there is some misunderstanding here ? let me try to clarify.
In the current logic, we first call cna_order_queue() from cna_wait_head_or_lock().
If we find an appropriate ?local? waiter (either real or fake), we set it as
next and make sure the numa_node of that node is the same as ours.
If not (i.e., when we do not have any next waiter), we set partial_order to
LOCAL_WAITER_NOT_FOUND (pardon the names) and go spin on the lock (calling
atomic_cond_read_acquire() in the generic code).
During this spin time, new waiters can join the queue.
Hence, we recheck the state of the queue by calling cna_order_queue() again
from cna_lock_handoff().

As just mentioned, if we change the logic as you suggest, there is
really no reason to call cna_order_queue() again.

> 
> Was the efficacy of this scheme tested?
> 
>> +	/*
>> +	 * We have a local waiter, either real or fake one;
>> +	 * reload @next in case it was changed by cna_order_queue().
>> +	 */
>> +	next = node->next;
>> +	if (node->locked > 1)
>> +		val = node->locked;	/* preseve secondary queue */
> 
> IIRC we used to do:
> 
> 	val |= node->locked;
> 
> Which is simpler for not having branches. Why change a good thing?
With |= we might set val to encoded tail+1 (rather than encoded tail).
This still would work, as decode_tail(val) does not care about LSB, but seems fragile to me.
We talked about that before: 
https://lore.kernel.org/linux-arm-kernel/E32F90E2-F00B-423B-A851-336004EF6593 at oracle.com

If you think this is a non-issue, I will be happy to adopt your suggestion.

Regards,
? Alex



From alex.kogan at oracle.com  Wed Apr 14 03:30:41 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Tue, 13 Apr 2021 22:30:41 -0400
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <20210413212203.GT3762101@tassilo.jf.intel.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
 <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
 <20210413212203.GT3762101@tassilo.jf.intel.com>
Message-ID: <7902C919-9624-48C9-89C3-D390A9FF78AB@oracle.com>



> On Apr 13, 2021, at 5:22 PM, Andi Kleen <ak at linux.intel.com> wrote:
> 
>>> ms granularity seems very coarse grained for this. Surely
>>> at some point of spinning you can afford a ktime_get? But ok.
>> We are reading time when we are at the head of the (main) queue, but
>> don?t have the lock yet. Not sure about the latency of ktime_get(), but
>> anything reasonably fast but not necessarily precise should work.
> 
> Actually cpu_clock / sched_clock (see my other email). These should
> be fast without corner cases and also monotonic.
I see, thanks.

> 
>> 
>>> Could you turn that into a moduleparm which can be changed at runtime?
>>> Would be strange to have to reboot just to play with this parameter
>> Yes, good suggestion, thanks.
>> 
>>> This would also make the code a lot shorter I guess.
>> So you don?t think we need the command-line parameter, just the module_param?
> 
> module_params can be changed at the command line too, so yes.
Got it, thanks again.

? Alex



From yuzenghui at huawei.com  Wed Apr 14 03:39:54 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Wed, 14 Apr 2021 10:39:54 +0800
Subject: Question: multiple SMMUv3 devices probe
In-Reply-To: <CAJNi4rPo47c3GL9jDUuy4N=7aunKUgr3-oPxtVj=YZaNs=fvKQ@mail.gmail.com>
References: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
 <YG6v2m1P8cbhRnJU@myrica>
 <CAJNi4rPx=oh7iv=4=-5PV-7OAgkZzr5zLysgTjr3YVKzHsC44w@mail.gmail.com>
 <YHWVWiQpS93lRNly@myrica>
 <CAJNi4rPo47c3GL9jDUuy4N=7aunKUgr3-oPxtVj=YZaNs=fvKQ@mail.gmail.com>
Message-ID: <403674d3-1146-f893-f31a-8a8b26c8fa2d@huawei.com>

On 2021/4/14 9:45, richard clark wrote:
> Jean-Philippe Brucker <jean-philippe at linaro.org> ?2021?4?13??? ??8:58???
>>
>> On Tue, Apr 13, 2021 at 08:40:47PM +0800, richard clark wrote:

[...]

>>> Actually, my question is a if pci device driver probes its device
>>> before the SMMUv3 driver probing,
>>> how does that pci device using the DMA with SMMU translation?
>>
>> It doesn't - by looking at the dependencies described in device-tree
> (forget to reply all, so add the CC'ing...)
> I understand 'it doesn't' here means the pci driver will not probe its
> device before SMMU driver is on
>> (iommu-map property) or in ACPI IORT, we defer probe of the PCI device
>> until the SMMU is operational.
>>
> If that is correct, Jean, would you point me to the code snippet that
> a pci driver will defer
> its probe until the SMMU is functional? Some key points are enough...

I think it's correct. Take ACPI-based system as an example, we setup PCI
device's DMA configuration by pci_dma_configure()/acpi_dma_configure().
If as you said, the PCI device is probed before the SMMUv3 probing, we
will get *-EPROBE_DEFER* during the DMA configuration. Please have a
look at iort_pci_iommu_init()/iort_iommu_xlate(), which should have
provided the whole details for us.

The device we *are* probing is then put onto the "deferred list" (grep
it in the driver core code) and will be retried from the list by
deferred_probe_work.

Hope it helps.


Zenghui


From hongxing.zhu at nxp.com  Wed Apr 14 03:26:13 2021
From: hongxing.zhu at nxp.com (Richard Zhu)
Date: Wed, 14 Apr 2021 10:26:13 +0800
Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to power up
Message-ID: <1618367174-30968-1-git-send-email-hongxing.zhu@nxp.com>

The other two patches are accepted into PCIe tree.
It's time to post it for Shawn to pick up into the imx DT tree.
https://patchwork.kernel.org/project/linux-pci/patch/1616661882-26487-3-git-send-email-hongxing.zhu at nxp.com/

arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 1 +
1 file changed, 1 insertion(+)

[PATCH] arm64: dts: imx8mq-evk: add one regulator used to power up


From hongxing.zhu at nxp.com  Wed Apr 14 03:26:14 2021
From: hongxing.zhu at nxp.com (Richard Zhu)
Date: Wed, 14 Apr 2021 10:26:14 +0800
Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to power up
 pcie phy
In-Reply-To: <1618367174-30968-1-git-send-email-hongxing.zhu@nxp.com>
References: <1618367174-30968-1-git-send-email-hongxing.zhu@nxp.com>
Message-ID: <1618367174-30968-2-git-send-email-hongxing.zhu@nxp.com>

Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
the VREG_BYPASS bits of GPR registers should be cleared from default
value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
turned on.

Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
---
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 85b045253a0e..4d2035e3dd7c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -318,6 +318,7 @@
 		 <&clk IMX8MQ_CLK_PCIE1_PHY>,
 		 <&pcie0_refclk>;
 	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
+	vph-supply = <&vgen5_reg>;
 	status = "okay";
 };
 
-- 
2.17.1



From bjorn.andersson at linaro.org  Wed Apr 14 03:47:12 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Tue, 13 Apr 2021 21:47:12 -0500
Subject: [PATCH v3] ARM: kernel: Fix interrupted SMC calls
In-Reply-To: <20210326182237.47048-1-manivannan.sadhasivam@linaro.org>
References: <20210326182237.47048-1-manivannan.sadhasivam@linaro.org>
Message-ID: <20210414024712.GX1538589@yoga>

On Fri 26 Mar 13:22 CDT 2021, Manivannan Sadhasivam wrote:

> On Qualcomm ARM32 platforms, the SMC call can return before it has
> completed. If this occurs, the call can be restarted, but it requires
> using the returned session ID value from the interrupted SMC call.
> 
> The ARM32 SMCC code already has the provision to add platform specific
> quirks for things like this. So let's make use of it and add the
> Qualcomm specific quirk (ARM_SMCCC_QUIRK_QCOM_A6) used by the QCOM_SCM
> driver.
> 
> This change is similar to the below one added for ARM64 a while ago:
> commit 82bcd087029f ("firmware: qcom: scm: Fix interrupted SCM calls")
> 
> Without this change, the Qualcomm ARM32 platforms like SDX55 will return
> -EINVAL for SMC calls used for modem firmware loading and validation.
> 
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

> ---
> 
> Changes in v3:
> 
> * Rebased on top of v5.12-rc2
> * Sent to SoC list since there was no review so far apart from initial one
>   by Russel
> 
> Changes in v2:
> 
> * Preserved callee saved registers and used the registers r4, r5 which
>   are getting pushed onto the stack.
> 
>  arch/arm/kernel/asm-offsets.c |  3 +++
>  arch/arm/kernel/smccc-call.S  | 11 ++++++++++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index be8050b0c3df..70993af22d80 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -24,6 +24,7 @@
>  #include <asm/vdso_datapage.h>
>  #include <asm/hardware/cache-l2x0.h>
>  #include <linux/kbuild.h>
> +#include <linux/arm-smccc.h>
>  #include "signal.h"
>  
>  /*
> @@ -148,6 +149,8 @@ int main(void)
>    DEFINE(SLEEP_SAVE_SP_PHYS,	offsetof(struct sleep_save_sp, save_ptr_stash_phys));
>    DEFINE(SLEEP_SAVE_SP_VIRT,	offsetof(struct sleep_save_sp, save_ptr_stash));
>  #endif
> +  DEFINE(ARM_SMCCC_QUIRK_ID_OFFS,	offsetof(struct arm_smccc_quirk, id));
> +  DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS,	offsetof(struct arm_smccc_quirk, state));
>    BLANK();
>    DEFINE(DMA_BIDIRECTIONAL,	DMA_BIDIRECTIONAL);
>    DEFINE(DMA_TO_DEVICE,		DMA_TO_DEVICE);
> diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
> index 00664c78faca..931df62a7831 100644
> --- a/arch/arm/kernel/smccc-call.S
> +++ b/arch/arm/kernel/smccc-call.S
> @@ -3,7 +3,9 @@
>   * Copyright (c) 2015, Linaro Limited
>   */
>  #include <linux/linkage.h>
> +#include <linux/arm-smccc.h>
>  
> +#include <asm/asm-offsets.h>
>  #include <asm/opcodes-sec.h>
>  #include <asm/opcodes-virt.h>
>  #include <asm/unwind.h>
> @@ -27,7 +29,14 @@ UNWIND(	.fnstart)
>  UNWIND(	.save	{r4-r7})
>  	ldm	r12, {r4-r7}
>  	\instr
> -	pop	{r4-r7}
> +	ldr	r4, [sp, #36]
> +	cmp	r4, #0
> +	beq	1f			// No quirk structure
> +	ldr     r5, [r4, #ARM_SMCCC_QUIRK_ID_OFFS]
> +	cmp     r5, #ARM_SMCCC_QUIRK_QCOM_A6
> +	bne	1f			// No quirk present
> +	str	r6, [r4, #ARM_SMCCC_QUIRK_STATE_OFFS]
> +1:	pop	{r4-r7}
>  	ldr	r12, [sp, #(4 * 4)]
>  	stm	r12, {r0-r3}
>  	bx	lr
> -- 
> 2.25.1
> 


From zhukeqian1 at huawei.com  Wed Apr 14 03:48:50 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 14 Apr 2021 10:48:50 +0800
Subject: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <878s5up71v.wl-maz@kernel.org>
References: <20210316134338.18052-1-zhukeqian1@huawei.com>
 <20210316134338.18052-3-zhukeqian1@huawei.com> <878s5up71v.wl-maz@kernel.org>
Message-ID: <a72d4b34-1088-70b8-2cf9-628119fbbb74@huawei.com>

Hi Marc,

I think I have fully tested this patch. The next step is to do some restriction on
HVA in vfio module, so we can build block mapping for it with a higher probability.

Is there anything to improve? If not, could you apply it? ^_^

Thanks,
Keqian

On 2021/4/7 21:18, Marc Zyngier wrote:
> On Tue, 16 Mar 2021 13:43:38 +0000,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> The MMIO region of a device maybe huge (GB level), try to use
>> block mapping in stage2 to speedup both map and unmap.
>>
>> Compared to normal memory mapping, we should consider two more
>> points when try block mapping for MMIO region:
>>
>> 1. For normal memory mapping, the PA(host physical address) and
>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>> the HVA to request hugepage, so we don't need to consider PA
>> alignment when verifing block mapping. But for device memory
>> mapping, the PA and HVA may have different alignment.
>>
>> 2. For normal memory mapping, we are sure hugepage size properly
>> fit into vma, so we don't check whether the mapping size exceeds
>> the boundary of vma. But for device memory mapping, we should pay
>> attention to this.
>>
>> This adds device_rough_page_shift() to check these two points when
>> selecting block mapping size.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> ---
>>
>> Mainly for RFC, not fully tested. I will fully test it when the
>> code logic is well accepted.
>>
>> ---
>>  arch/arm64/kvm/mmu.c | 42 ++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 38 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index c59af5ca01b0..224aa15eb4d9 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -624,6 +624,36 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>>  }
>>  
>> +/*
>> + * Find a mapping size that properly insides the intersection of vma and
>> + * memslot. And hva and pa have the same alignment to this mapping size.
>> + * It's rough because there are still other restrictions, which will be
>> + * checked by the following fault_supports_stage2_huge_mapping().
> 
> I don't think these restrictions make complete sense to me. If this is
> a PFNMAP VMA, we should use the biggest mapping size that covers the
> VMA, and not more than the VMA.
> 
>> + */
>> +static short device_rough_page_shift(struct kvm_memory_slot *memslot,
>> +				     struct vm_area_struct *vma,
>> +				     unsigned long hva)
>> +{
>> +	size_t size = memslot->npages * PAGE_SIZE;
>> +	hva_t sec_start = max(memslot->userspace_addr, vma->vm_start);
>> +	hva_t sec_end = min(memslot->userspace_addr + size, vma->vm_end);
>> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>> +
>> +#ifndef __PAGETABLE_PMD_FOLDED
>> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PUD_SIZE) >= sec_start &&
>> +	    ALIGN(hva, PUD_SIZE) <= sec_end)
>> +		return PUD_SHIFT;
>> +#endif
>> +
>> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PMD_SIZE) >= sec_start &&
>> +	    ALIGN(hva, PMD_SIZE) <= sec_end)
>> +		return PMD_SHIFT;
>> +
>> +	return PAGE_SHIFT;
>> +}
>> +
>>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>>  					       unsigned long hva,
>>  					       unsigned long map_size)
>> @@ -769,7 +799,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  		return -EFAULT;
>>  	}
>>  
>> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
>> +	/*
>> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
>> +	 * get block mapping for device MMIO region.
>> +	 */
>>  	mmap_read_lock(current->mm);
>>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>>  	if (unlikely(!vma)) {
>> @@ -780,11 +813,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (is_vm_hugetlb_page(vma))
>>  		vma_shift = huge_page_shift(hstate_vma(vma));
>> +	else if (vma->vm_flags & VM_PFNMAP)
>> +		vma_shift = device_rough_page_shift(memslot, vma, hva);
>>  	else
>>  		vma_shift = PAGE_SHIFT;
>>  
>> -	if (logging_active ||
>> -	    (vma->vm_flags & VM_PFNMAP)) {
>> +	if (logging_active) {
>>  		force_pte = true;
>>  		vma_shift = PAGE_SHIFT;
> 
> But why should we downgrade to page-size mappings if logging? This is
> a device, and you aren't moving the device around, are you? Or is your
> device actually memory with a device mapping that you are trying to
> migrate?
> 
>>  	}
>> @@ -855,7 +889,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (kvm_is_device_pfn(pfn)) {
>>  		device = true;
>> -		force_pte = true;
>> +		force_pte = (vma_pagesize == PAGE_SIZE);
>>  	} else if (logging_active && !write_fault) {
>>  		/*
>>  		 * Only actually map the page as writable if this was a write
>> -- 
>> 2.19.1
>>
>>
> 
> Thanks,
> 
> 	M.
> 


From anshuman.khandual at arm.com  Wed Apr 14 03:54:59 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 14 Apr 2021 08:24:59 +0530
Subject: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
Message-ID: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>

Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
for those platforms which would override generic default FIRST_USER_ADDRESS
value 0UL. This makes it much cleaner with reduced code.

Cc: linux-alpha at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-csky at vger.kernel.org
Cc: linux-hexagon at vger.kernel.org
Cc: linux-ia64 at vger.kernel.org
Cc: linux-m68k at lists.linux-m68k.org
Cc: linux-mips at vger.kernel.org
Cc: openrisc at lists.librecores.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-riscv at lists.infradead.org
Cc: linux-s390 at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-um at lists.infradead.org
Cc: linux-xtensa at linux-xtensa.org
Cc: x86 at kernel.org
Cc: linux-mm at kvack.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 arch/alpha/include/asm/pgtable.h             | 1 -
 arch/arc/include/asm/pgtable.h               | 6 ------
 arch/arm/Kconfig                             | 1 +
 arch/arm64/include/asm/pgtable.h             | 2 --
 arch/csky/include/asm/pgtable.h              | 1 -
 arch/hexagon/include/asm/pgtable.h           | 3 ---
 arch/ia64/include/asm/pgtable.h              | 1 -
 arch/m68k/include/asm/pgtable_mm.h           | 1 -
 arch/microblaze/include/asm/pgtable.h        | 2 --
 arch/mips/include/asm/pgtable-32.h           | 1 -
 arch/mips/include/asm/pgtable-64.h           | 1 -
 arch/nds32/Kconfig                           | 1 +
 arch/nios2/include/asm/pgtable.h             | 2 --
 arch/openrisc/include/asm/pgtable.h          | 1 -
 arch/parisc/include/asm/pgtable.h            | 2 --
 arch/powerpc/include/asm/book3s/pgtable.h    | 1 -
 arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
 arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
 arch/riscv/include/asm/pgtable.h             | 2 --
 arch/s390/include/asm/pgtable.h              | 2 --
 arch/sh/include/asm/pgtable.h                | 2 --
 arch/sparc/include/asm/pgtable_32.h          | 1 -
 arch/sparc/include/asm/pgtable_64.h          | 3 ---
 arch/um/include/asm/pgtable-2level.h         | 1 -
 arch/um/include/asm/pgtable-3level.h         | 1 -
 arch/x86/include/asm/pgtable_types.h         | 2 --
 arch/xtensa/include/asm/pgtable.h            | 1 -
 include/linux/mm.h                           | 4 ++++
 mm/Kconfig                                   | 4 ++++
 29 files changed, 10 insertions(+), 43 deletions(-)

diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 8d856c62e22a..1a2fb0dc905b 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -46,7 +46,6 @@ struct vm_area_struct;
 #define PTRS_PER_PMD	(1UL << (PAGE_SHIFT-3))
 #define PTRS_PER_PGD	(1UL << (PAGE_SHIFT-3))
 #define USER_PTRS_PER_PGD	(TASK_SIZE / PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 /* Number of pointers that fit on a page:  this will go away. */
 #define PTRS_PER_PAGE	(1UL << (PAGE_SHIFT-3))
diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
index 163641726a2b..a9fabfb70664 100644
--- a/arch/arc/include/asm/pgtable.h
+++ b/arch/arc/include/asm/pgtable.h
@@ -228,12 +228,6 @@
  */
 #define	USER_PTRS_PER_PGD	(TASK_SIZE / PGDIR_SIZE)
 
-/*
- * No special requirements for lowest virtual address we permit any user space
- * mapping to be mapped at.
- */
-#define FIRST_USER_ADDRESS      0UL
-
 
 /****************************************************************
  * Bucket load of VM Helpers
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5da96f5df48f..ad086e6d7155 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,7 @@ config ARM
 	select ARCH_HAS_DEBUG_VIRTUAL if MMU
 	select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
 	select ARCH_HAS_ELF_RANDOMIZE
+	select ARCH_HAS_FIRST_USER_ADDRESS
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_KCOV
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 47027796c2f9..f6ab8b64967e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -26,8 +26,6 @@
 
 #define vmemmap			((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
 
-#define FIRST_USER_ADDRESS	0UL
-
 #ifndef __ASSEMBLY__
 
 #include <asm/cmpxchg.h>
diff --git a/arch/csky/include/asm/pgtable.h b/arch/csky/include/asm/pgtable.h
index 0d60367b6bfa..151607ed5158 100644
--- a/arch/csky/include/asm/pgtable.h
+++ b/arch/csky/include/asm/pgtable.h
@@ -14,7 +14,6 @@
 #define PGDIR_MASK		(~(PGDIR_SIZE-1))
 
 #define USER_PTRS_PER_PGD	(PAGE_OFFSET/PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 /*
  * C-SKY is two-level paging structure:
diff --git a/arch/hexagon/include/asm/pgtable.h b/arch/hexagon/include/asm/pgtable.h
index dbb22b80b8c4..e4979508cddf 100644
--- a/arch/hexagon/include/asm/pgtable.h
+++ b/arch/hexagon/include/asm/pgtable.h
@@ -155,9 +155,6 @@ extern unsigned long _dflt_cache_att;
 
 extern pgd_t swapper_pg_dir[PTRS_PER_PGD];  /* located in head.S */
 
-/* Seems to be zero even in architectures where the zero page is firewalled? */
-#define FIRST_USER_ADDRESS 0UL
-
 /*  HUGETLB not working currently  */
 #ifdef CONFIG_HUGETLB_PAGE
 #define pte_mkhuge(pte) __pte((pte_val(pte) & ~0x3) | HVM_HUGEPAGE_SIZE)
diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 9b4efe89e62d..b37381532c2f 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -128,7 +128,6 @@
 #define PTRS_PER_PGD_SHIFT	PTRS_PER_PTD_SHIFT
 #define PTRS_PER_PGD		(1UL << PTRS_PER_PGD_SHIFT)
 #define USER_PTRS_PER_PGD	(5*PTRS_PER_PGD/8)	/* regions 0-4 are user regions */
-#define FIRST_USER_ADDRESS	0UL
 
 /*
  * All the normal masks have the "page accessed" bits on, as any time
diff --git a/arch/m68k/include/asm/pgtable_mm.h b/arch/m68k/include/asm/pgtable_mm.h
index aca22c2c1ee2..143ba7de9bda 100644
--- a/arch/m68k/include/asm/pgtable_mm.h
+++ b/arch/m68k/include/asm/pgtable_mm.h
@@ -72,7 +72,6 @@
 #define PTRS_PER_PGD	128
 #endif
 #define USER_PTRS_PER_PGD	(TASK_SIZE/PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 /* Virtual address region for use by kernel_map() */
 #ifdef CONFIG_SUN3
diff --git a/arch/microblaze/include/asm/pgtable.h b/arch/microblaze/include/asm/pgtable.h
index 9ae8d2c17dd5..71cd547655d9 100644
--- a/arch/microblaze/include/asm/pgtable.h
+++ b/arch/microblaze/include/asm/pgtable.h
@@ -25,8 +25,6 @@ extern int mem_init_done;
 #include <asm/mmu.h>
 #include <asm/page.h>
 
-#define FIRST_USER_ADDRESS	0UL
-
 extern unsigned long va_to_phys(unsigned long address);
 extern pte_t *va_to_pte(unsigned long address);
 
diff --git a/arch/mips/include/asm/pgtable-32.h b/arch/mips/include/asm/pgtable-32.h
index 6c0532d7b211..95df9c293d8d 100644
--- a/arch/mips/include/asm/pgtable-32.h
+++ b/arch/mips/include/asm/pgtable-32.h
@@ -93,7 +93,6 @@ extern int add_temporary_entry(unsigned long entrylo0, unsigned long entrylo1,
 #endif
 
 #define USER_PTRS_PER_PGD	(0x80000000UL/PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 #define VMALLOC_START	  MAP_BASE
 
diff --git a/arch/mips/include/asm/pgtable-64.h b/arch/mips/include/asm/pgtable-64.h
index 1e7d6ce9d8d6..046465906c82 100644
--- a/arch/mips/include/asm/pgtable-64.h
+++ b/arch/mips/include/asm/pgtable-64.h
@@ -137,7 +137,6 @@
 #define PTRS_PER_PTE	((PAGE_SIZE << PTE_ORDER) / sizeof(pte_t))
 
 #define USER_PTRS_PER_PGD       ((TASK_SIZE64 / PGDIR_SIZE)?(TASK_SIZE64 / PGDIR_SIZE):1)
-#define FIRST_USER_ADDRESS	0UL
 
 /*
  * TLB refill handlers also map the vmalloc area into xuseg.  Avoid
diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 62313902d75d..23ec4fcc0d0f 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -8,6 +8,7 @@ config NDS32
 	def_bool y
 	select ARCH_32BIT_OFF_T
 	select ARCH_HAS_DMA_PREP_COHERENT
+	select ARCH_HAS_FIRST_USER_ADDRESS
 	select ARCH_HAS_SYNC_DMA_FOR_CPU
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
 	select ARCH_WANT_FRAME_POINTERS if FTRACE
diff --git a/arch/nios2/include/asm/pgtable.h b/arch/nios2/include/asm/pgtable.h
index 2600d76c310c..4a995fa628ee 100644
--- a/arch/nios2/include/asm/pgtable.h
+++ b/arch/nios2/include/asm/pgtable.h
@@ -24,8 +24,6 @@
 #include <asm/pgtable-bits.h>
 #include <asm-generic/pgtable-nopmd.h>
 
-#define FIRST_USER_ADDRESS	0UL
-
 #define VMALLOC_START		CONFIG_NIOS2_KERNEL_MMU_REGION_BASE
 #define VMALLOC_END		(CONFIG_NIOS2_KERNEL_REGION_BASE - 1)
 
diff --git a/arch/openrisc/include/asm/pgtable.h b/arch/openrisc/include/asm/pgtable.h
index 9425bedab4fc..4ac591c9ca33 100644
--- a/arch/openrisc/include/asm/pgtable.h
+++ b/arch/openrisc/include/asm/pgtable.h
@@ -73,7 +73,6 @@ extern void paging_init(void);
  */
 
 #define USER_PTRS_PER_PGD       (TASK_SIZE/PGDIR_SIZE)
-#define FIRST_USER_ADDRESS      0UL
 
 /*
  * Kernels own virtual memory area.
diff --git a/arch/parisc/include/asm/pgtable.h b/arch/parisc/include/asm/pgtable.h
index 39017210dbf0..7f33c29764cc 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -171,8 +171,6 @@ static inline void purge_tlb_entries(struct mm_struct *mm, unsigned long addr)
  * pgd entries used up by user/kernel:
  */
 
-#define FIRST_USER_ADDRESS	0UL
-
 /* NB: The tlb miss handlers make certain assumptions about the order */
 /*     of the following bits, so be careful (One example, bits 25-31  */
 /*     are moved together in one instruction).                        */
diff --git a/arch/powerpc/include/asm/book3s/pgtable.h b/arch/powerpc/include/asm/book3s/pgtable.h
index 0e1263455d73..ad130e15a126 100644
--- a/arch/powerpc/include/asm/book3s/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/pgtable.h
@@ -8,7 +8,6 @@
 #include <asm/book3s/32/pgtable.h>
 #endif
 
-#define FIRST_USER_ADDRESS	0UL
 #ifndef __ASSEMBLY__
 /* Insert a PTE, top-level function is out of line. It uses an inline
  * low level function in the respective pgtable-* files
diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h b/arch/powerpc/include/asm/nohash/32/pgtable.h
index 96522f7f0618..f06ae00f2a65 100644
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@ -54,7 +54,6 @@ extern int icache_44x_need_flush;
 #define PGD_MASKED_BITS		0
 
 #define USER_PTRS_PER_PGD	(TASK_SIZE / PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 #define pte_ERROR(e) \
 	pr_err("%s:%d: bad pte %llx.\n", __FILE__, __LINE__, \
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h
index 6cb8aa357191..e40fb54af7ef 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -10,8 +10,6 @@
 #include <asm/barrier.h>
 #include <asm/asm-const.h>
 
-#define FIRST_USER_ADDRESS	0UL
-
 /*
  * Size of EA range mapped by our pagetables.
  */
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..1893dc9f0974 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -490,8 +490,6 @@ void setup_bootmem(void);
 void paging_init(void);
 void misc_mem_init(void);
 
-#define FIRST_USER_ADDRESS  0
-
 /*
  * ZERO_PAGE is a global shared page that is always zero,
  * used for zero-mapped memory areas, etc.
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 29c7ecd5ad1d..4ee49bb98f34 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -65,8 +65,6 @@ extern unsigned long zero_page_mask;
 
 /* TODO: s390 cannot support io_remap_pfn_range... */
 
-#define FIRST_USER_ADDRESS  0UL
-
 #define pte_ERROR(e) \
 	printk("%s:%d: bad pte %p.\n", __FILE__, __LINE__, (void *) pte_val(e))
 #define pmd_ERROR(e) \
diff --git a/arch/sh/include/asm/pgtable.h b/arch/sh/include/asm/pgtable.h
index 27751e9470df..d7ddb1ec86a0 100644
--- a/arch/sh/include/asm/pgtable.h
+++ b/arch/sh/include/asm/pgtable.h
@@ -59,8 +59,6 @@ static inline unsigned long long neff_sign_extend(unsigned long val)
 /* Entries per level */
 #define PTRS_PER_PTE	(PAGE_SIZE / (1 << PTE_MAGNITUDE))
 
-#define FIRST_USER_ADDRESS	0UL
-
 #define PHYS_ADDR_MASK29		0x1fffffff
 #define PHYS_ADDR_MASK32		0xffffffff
 
diff --git a/arch/sparc/include/asm/pgtable_32.h b/arch/sparc/include/asm/pgtable_32.h
index 632cdb959542..a732961da91d 100644
--- a/arch/sparc/include/asm/pgtable_32.h
+++ b/arch/sparc/include/asm/pgtable_32.h
@@ -48,7 +48,6 @@ unsigned long __init bootmem_init(unsigned long *pages_avail);
 #define PTRS_PER_PMD    	64
 #define PTRS_PER_PGD    	256
 #define USER_PTRS_PER_PGD	PAGE_OFFSET / PGDIR_SIZE
-#define FIRST_USER_ADDRESS	0UL
 #define PTE_SIZE		(PTRS_PER_PTE*4)
 
 #define PAGE_NONE	SRMMU_PAGE_NONE
diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 550d3904de65..57460b7ada7b 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -95,9 +95,6 @@ bool kern_addr_valid(unsigned long addr);
 #define PTRS_PER_PUD	(1UL << PUD_BITS)
 #define PTRS_PER_PGD	(1UL << PGDIR_BITS)
 
-/* Kernel has a separate 44bit address space. */
-#define FIRST_USER_ADDRESS	0UL
-
 #define pmd_ERROR(e)							\
 	pr_err("%s:%d: bad pmd %p(%016lx) seen at (%pS)\n",		\
 	       __FILE__, __LINE__, &(e), pmd_val(e), __builtin_return_address(0))
diff --git a/arch/um/include/asm/pgtable-2level.h b/arch/um/include/asm/pgtable-2level.h
index 32106d31e4ab..8256ecc5b919 100644
--- a/arch/um/include/asm/pgtable-2level.h
+++ b/arch/um/include/asm/pgtable-2level.h
@@ -23,7 +23,6 @@
 #define PTRS_PER_PTE	1024
 #define USER_PTRS_PER_PGD ((TASK_SIZE + (PGDIR_SIZE - 1)) / PGDIR_SIZE)
 #define PTRS_PER_PGD	1024
-#define FIRST_USER_ADDRESS	0UL
 
 #define pte_ERROR(e) \
         printk("%s:%d: bad pte %p(%08lx).\n", __FILE__, __LINE__, &(e), \
diff --git a/arch/um/include/asm/pgtable-3level.h b/arch/um/include/asm/pgtable-3level.h
index 7e6a4180db9d..9289a86643a9 100644
--- a/arch/um/include/asm/pgtable-3level.h
+++ b/arch/um/include/asm/pgtable-3level.h
@@ -41,7 +41,6 @@
 #endif
 
 #define USER_PTRS_PER_PGD ((TASK_SIZE + (PGDIR_SIZE - 1)) / PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 
 #define pte_ERROR(e) \
         printk("%s:%d: bad pte %p(%016lx).\n", __FILE__, __LINE__, &(e), \
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index f24d7ef8fffa..40497a9020c6 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -7,8 +7,6 @@
 
 #include <asm/page_types.h>
 
-#define FIRST_USER_ADDRESS	0UL
-
 #define _PAGE_BIT_PRESENT	0	/* is present */
 #define _PAGE_BIT_RW		1	/* writeable */
 #define _PAGE_BIT_USER		2	/* userspace addressable */
diff --git a/arch/xtensa/include/asm/pgtable.h b/arch/xtensa/include/asm/pgtable.h
index 4dc04e6c01d7..38aa57e34390 100644
--- a/arch/xtensa/include/asm/pgtable.h
+++ b/arch/xtensa/include/asm/pgtable.h
@@ -59,7 +59,6 @@
 #define PTRS_PER_PGD		1024
 #define PGD_ORDER		0
 #define USER_PTRS_PER_PGD	(TASK_SIZE/PGDIR_SIZE)
-#define FIRST_USER_ADDRESS	0UL
 #define FIRST_USER_PGD_NR	(FIRST_USER_ADDRESS >> PGDIR_SHIFT)
 
 #ifdef CONFIG_MMU
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..47098ccd715e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
 
 void init_mm_internals(void);
 
+#ifndef ARCH_HAS_FIRST_USER_ADDRESS
+#define FIRST_USER_ADDRESS	0UL
+#endif
+
 #ifndef CONFIG_NEED_MULTIPLE_NODES	/* Don't use mapnrs, do it properly */
 extern unsigned long max_mapnr;
 
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b95..373fbe377075 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -806,6 +806,10 @@ config VMAP_PFN
 
 config ARCH_USES_HIGH_VMA_FLAGS
 	bool
+
+config ARCH_HAS_FIRST_USER_ADDRESS
+	bool
+
 config ARCH_HAS_PKEYS
 	bool
 
-- 
2.20.1



From hongxing.zhu at nxp.com  Wed Apr 14 04:02:11 2021
From: hongxing.zhu at nxp.com (Richard Zhu)
Date: Wed, 14 Apr 2021 03:02:11 +0000
Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to power
 up pcie phy
In-Reply-To: <1618367174-30968-2-git-send-email-hongxing.zhu@nxp.com>
References: <1618367174-30968-1-git-send-email-hongxing.zhu@nxp.com>
 <1618367174-30968-2-git-send-email-hongxing.zhu@nxp.com>
Message-ID: <VI1PR04MB5853835972CB26B529E6FF3E8C4E9@VI1PR04MB5853.eurprd04.prod.outlook.com>

Hi Shawn:
Regarding Lucas' advice, this patch should be split out and post for you to pick up into DT tree.
Since the other two patches are accepted by PCIe tree now.
Can you help to pick up this patch?
Thanks in advanced.
https://patchwork.kernel.org/project/linux-pci/patch/1616661882-26487-3-git-send-email-hongxing.zhu at nxp.com/
https://patchwork.kernel.org/project/linux-pci/patch/1617091701-6444-2-git-send-email-hongxing.zhu at nxp.com/

Best Regards
Richard Zhu

> -----Original Message-----
> From: Richard Zhu <hongxing.zhu at nxp.com>
> Sent: Wednesday, April 14, 2021 10:26 AM
> To: shawnguo at kernel.org
> Cc: l.stach at pengutronix.de; dl-linux-imx <linux-imx at nxp.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Richard
> Zhu <hongxing.zhu at nxp.com>
> Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to power
> up pcie phy
> 
> Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data sheet.
> When PCIE_VPH is supplied by 3.3v in the HW schematic design, the
> VREG_BYPASS bits of GPR registers should be cleared from default value 1b'1
> to 1b'0. Thus, the internal 3v3 to 1v8 translator would be turned on.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> ---
>  arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> index 85b045253a0e..4d2035e3dd7c 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> @@ -318,6 +318,7 @@
>  		 <&clk IMX8MQ_CLK_PCIE1_PHY>,
>  		 <&pcie0_refclk>;
>  	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +	vph-supply = <&vgen5_reg>;
>  	status = "okay";
>  };
> 
> --
> 2.17.1



From richard.xnu.clark at gmail.com  Wed Apr 14 04:17:31 2021
From: richard.xnu.clark at gmail.com (richard clark)
Date: Wed, 14 Apr 2021 11:17:31 +0800
Subject: Question: multiple SMMUv3 devices probe
In-Reply-To: <403674d3-1146-f893-f31a-8a8b26c8fa2d@huawei.com>
References: <CAJNi4rN2myKrRvuPPQg1QikAkbJVpb=fuETK0yV8wt-HNvZq9A@mail.gmail.com>
 <YG6v2m1P8cbhRnJU@myrica>
 <CAJNi4rPx=oh7iv=4=-5PV-7OAgkZzr5zLysgTjr3YVKzHsC44w@mail.gmail.com>
 <YHWVWiQpS93lRNly@myrica>
 <CAJNi4rPo47c3GL9jDUuy4N=7aunKUgr3-oPxtVj=YZaNs=fvKQ@mail.gmail.com>
 <403674d3-1146-f893-f31a-8a8b26c8fa2d@huawei.com>
Message-ID: <CAJNi4rNiNOwbqph383f1WiC4L09pVYwOghGr7m56MffpsY2hjQ@mail.gmail.com>

Zenghui Yu <yuzenghui at huawei.com> ?2021?4?14??? ??10:40???
>
> On 2021/4/14 9:45, richard clark wrote:
> > Jean-Philippe Brucker <jean-philippe at linaro.org> ?2021?4?13??? ??8:58???
> >>
> >> On Tue, Apr 13, 2021 at 08:40:47PM +0800, richard clark wrote:
>
> [...]
>
> >>> Actually, my question is a if pci device driver probes its device
> >>> before the SMMUv3 driver probing,
> >>> how does that pci device using the DMA with SMMU translation?
> >>
> >> It doesn't - by looking at the dependencies described in device-tree
> > (forget to reply all, so add the CC'ing...)
> > I understand 'it doesn't' here means the pci driver will not probe its
> > device before SMMU driver is on
> >> (iommu-map property) or in ACPI IORT, we defer probe of the PCI device
> >> until the SMMU is operational.
> >>
> > If that is correct, Jean, would you point me to the code snippet that
> > a pci driver will defer
> > its probe until the SMMU is functional? Some key points are enough...
>
> I think it's correct. Take ACPI-based system as an example, we setup PCI
> device's DMA configuration by pci_dma_configure()/acpi_dma_configure().
> If as you said, the PCI device is probed before the SMMUv3 probing, we
> will get *-EPROBE_DEFER* during the DMA configuration. Please have a
> look at iort_pci_iommu_init()/iort_iommu_xlate(), which should have
> provided the whole details for us.
>
> The device we *are* probing is then put onto the "deferred list" (grep
> it in the driver core code) and will be retried from the list by
> deferred_probe_work.
>
> Hope it helps.
>
Ah, very clear workflow to clarify my confusion. It really does help,
thanks guy, good luck!
>
> Zenghui


From ilya.lipnitskiy at gmail.com  Wed Apr 14 05:10:02 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Tue, 13 Apr 2021 21:10:02 -0700
Subject: [PATCH] staging: mt7621-pci: stop using of_pci_range_to_resource
In-Reply-To: <CAMhs-H_GVj1DnhutUBo=Sdr38A8h9WnaJ7KX_-ge550qbujP7w@mail.gmail.com>
References: <20210410173331.57949-1-ilya.lipnitskiy@gmail.com>
 <CAMhs-H_GVj1DnhutUBo=Sdr38A8h9WnaJ7KX_-ge550qbujP7w@mail.gmail.com>
Message-ID: <CALCv0x3qc5MVP0fm3HWD2CF27tX8z=g1A9T+yR15teU3jgOg6Q@mail.gmail.com>

Hi Sergio,

Just as an aside, are you planning to move staging/mt7621-pci into
arch/mips/pci at some point? This driver seems more maintained (by
you!) than many in-tree drivers...

Ilya

On Sat, Apr 10, 2021 at 12:23 PM Sergio Paracuellos
<sergio.paracuellos at gmail.com> wrote:
>
> Hi Ilya,
>
> On Sat, Apr 10, 2021 at 7:33 PM Ilya Lipnitskiy
> <ilya.lipnitskiy at gmail.com> wrote:
> >
> > The logic here was already overriding the erroneous IO addresses
> > returned from of_pci_range_to_resource, which is the bulk of the logic.
> >
> > So stop using it altogether and initialize the fields explicitly, as
> > done in aeba3731b150 ("powerpc/pci: Fix IO space breakage after
> > of_pci_range_to_resource() change").
> >
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > Cc: Sergio Paracuellos <sergio.paracuellos at gmail.com>
> > ---
> >  drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++++++-----
> >  1 file changed, 6 insertions(+), 5 deletions(-)
>
> Looks good to me, thanks! I have also tested this in gnubee pc1
> platform with no regressions at all when io bars are assigned:
>
> [   16.378956] mt7621-pci 1e140000.pcie: host bridge /pcie at 1e140000 ranges:
> [   16.392405] mt7621-pci 1e140000.pcie:      MEM
> 0x0060000000..0x006fffffff -> 0x0000000000
> [   16.408796] mt7621-pci 1e140000.pcie:       IO
> 0x001e160000..0x001e16ffff -> 0x0000000000
> [   16.425264] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000
> (dual port = 1)
> [   16.440452] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000
> (dual port = 0)
> [   16.678713] mt7621-pci 1e140000.pcie: PCIE0 enabled
> [   16.688435] mt7621-pci 1e140000.pcie: PCIE1 enabled
> [   16.698160] mt7621-pci 1e140000.pcie: PCIE2 enabled
> [   16.707886] mt7621-pci 1e140000.pcie: PCI coherence region base:
> 0x60000000, mask/settings: 0xf0000002
> [   16.726623] mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
> [   16.739309] pci_bus 0000:00: root bus resource [io  0x1e160000-0x1e16ffff]
> [   16.753008] pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
> [   16.766709] pci_bus 0000:00: root bus resource [bus 00-ff]
> [   16.777649] pci_bus 0000:00: root bus resource [mem
> 0x60000000-0x6fffffff] (bus address [0x00000000-0x0fffffff])
> [   16.797986] pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
> [   16.809973] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> [   16.822467] pci 0000:00:00.0: reg 0x14: initial BAR value 0x00000000 invalid
> [   16.836511] pci 0000:00:00.0: reg 0x14: [mem size 0x00010000]
> [   16.848048] pci 0000:00:00.0: supports D1
> [   16.856051] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> [   16.867943] pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
> [   16.879960] pci 0000:00:01.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> [   16.892454] pci 0000:00:01.0: reg 0x14: initial BAR value 0x00000000 invalid
> [   16.906497] pci 0000:00:01.0: reg 0x14: [mem size 0x00010000]
> [   16.918040] pci 0000:00:01.0: supports D1
> [   16.926031] pci 0000:00:01.0: PME# supported from D0 D1 D3hot
> [   16.937903] pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
> [   16.949915] pci 0000:00:02.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> [   16.962412] pci 0000:00:02.0: reg 0x14: initial BAR value 0x00000000 invalid
> [   16.976466] pci 0000:00:02.0: reg 0x14: [mem size 0x00010000]
> [   16.987991] pci 0000:00:02.0: supports D1
> [   16.995986] pci 0000:00:02.0: PME# supported from D0 D1 D3hot
> [   17.008716] pci 0000:00:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [   17.024695] pci 0000:00:01.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [   17.040654] pci 0000:00:02.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [   17.056868] pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
> [   17.068882] pci 0000:01:00.0: reg 0x10: [io  0x0000-0x0007]
> [   17.080003] pci 0000:01:00.0: reg 0x14: [io  0x0000-0x0003]
> [   17.091115] pci 0000:01:00.0: reg 0x18: [io  0x0000-0x0007]
> [   17.102238] pci 0000:01:00.0: reg 0x1c: [io  0x0000-0x0003]
> [   17.113350] pci 0000:01:00.0: reg 0x20: [io  0x0000-0x000f]
> [   17.124463] pci 0000:01:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> [   17.138508] pci 0000:01:00.0: reg 0x24: [mem size 0x00000200]
> [   17.150115] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth,
> limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000
> Gb/s with 5.0 GT/s PCIe x1 link)
> [   17.204594] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [   17.215109] pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> [   17.227257] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> [   17.240785] pci 0000:00:00.0:   bridge window [mem
> 0x60000000-0x600fffff pref]
> [   17.255183] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> [   17.268648] pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
> [   17.280671] pci 0000:02:00.0: reg 0x10: [io  0x0000-0x0007]
> [   17.291785] pci 0000:02:00.0: reg 0x14: [io  0x0000-0x0003]
> [   17.302898] pci 0000:02:00.0: reg 0x18: [io  0x0000-0x0007]
> [   17.314012] pci 0000:02:00.0: reg 0x1c: [io  0x0000-0x0003]
> [   17.325127] pci 0000:02:00.0: reg 0x20: [io  0x0000-0x000f]
> [   17.336241] pci 0000:02:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> [   17.350279] pci 0000:02:00.0: reg 0x24: [mem size 0x00000200]
> [   17.361893] pci 0000:02:00.0: 2.000 Gb/s available PCIe bandwidth,
> limited by 2.5 GT/s PCIe x1 link at 0000:00:01.0 (capable of 4.000
> Gb/s with 5.0 GT/s PCIe x1 link)
> [   17.414591] pci 0000:00:01.0: PCI bridge to [bus 02-ff]
> [   17.425063] pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
> [   17.437206] pci 0000:00:01.0:   bridge window [mem 0x60000000-0x600fffff]
> [   17.450733] pci 0000:00:01.0:   bridge window [mem
> 0x60000000-0x600fffff pref]
> [   17.465130] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
> [   17.478583] pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
> [   17.490604] pci 0000:03:00.0: reg 0x10: [io  0x0000-0x0007]
> [   17.501717] pci 0000:03:00.0: reg 0x14: [io  0x0000-0x0003]
> [   17.512831] pci 0000:03:00.0: reg 0x18: [io  0x0000-0x0007]
> [   17.523945] pci 0000:03:00.0: reg 0x1c: [io  0x0000-0x0003]
> [   17.535060] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x000f]
> [   17.546174] pci 0000:03:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> [   17.560211] pci 0000:03:00.0: reg 0x24: [mem size 0x00000200]
> [   17.571825] pci 0000:03:00.0: 2.000 Gb/s available PCIe bandwidth,
> limited by 2.5 GT/s PCIe x1 link at 0000:00:02.0 (capable of 4.000
> Gb/s with 5.0 GT/s PCIe x1 link)
> [   17.624582] pci 0000:00:02.0: PCI bridge to [bus 03-ff]
> [   17.635043] pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
> [   17.647188] pci 0000:00:02.0:   bridge window [mem 0x60000000-0x600fffff]
> [   17.660710] pci 0000:00:02.0:   bridge window [mem
> 0x60000000-0x600fffff pref]
> [   17.675104] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
> [   17.688358] pci 0000:00:00.0: BAR 0: no space for [mem size 0x80000000]
> [   17.701534] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x80000000]
> [   17.715406] pci 0000:00:01.0: BAR 0: no space for [mem size 0x80000000]
> [   17.728585] pci 0000:00:01.0: BAR 0: failed to assign [mem size 0x80000000]
> [   17.742456] pci 0000:00:02.0: BAR 0: no space for [mem size 0x80000000]
> [   17.755638] pci 0000:00:02.0: BAR 0: failed to assign [mem size 0x80000000]
> [   17.769514] pci 0000:00:00.0: BAR 8: assigned [mem 0x60000000-0x600fffff]
> [   17.783039] pci 0000:00:00.0: BAR 9: assigned [mem
> 0x60100000-0x601fffff pref]
> [   17.797429] pci 0000:00:01.0: BAR 8: assigned [mem 0x60200000-0x602fffff]
> [   17.810958] pci 0000:00:01.0: BAR 9: assigned [mem
> 0x60300000-0x603fffff pref]
> [   17.825360] pci 0000:00:02.0: BAR 8: assigned [mem 0x60400000-0x604fffff]
> [   17.838886] pci 0000:00:02.0: BAR 9: assigned [mem
> 0x60500000-0x605fffff pref]
> [   17.853279] pci 0000:00:00.0: BAR 1: assigned [mem 0x60600000-0x6060ffff]
> [   17.866814] pci 0000:00:01.0: BAR 1: assigned [mem 0x60610000-0x6061ffff]
> [   17.880346] pci 0000:00:02.0: BAR 1: assigned [mem 0x60620000-0x6062ffff]
> [   17.893880] pci 0000:00:00.0: BAR 7: assigned [io  0x1e160000-0x1e160fff]
> [   17.907410] pci 0000:00:01.0: BAR 7: assigned [io  0x1e161000-0x1e161fff]
> [   17.920935] pci 0000:00:02.0: BAR 7: assigned [io  0x1e162000-0x1e162fff]
> [   17.934474] pci 0000:01:00.0: BAR 5: assigned [mem 0x60000000-0x600001ff]
> [   17.948008] pci 0000:01:00.0: BAR 4: assigned [io  0x1e160000-0x1e16000f]
> [   17.961542] pci 0000:01:00.0: BAR 0: assigned [io  0x1e160010-0x1e160017]
> [   17.975072] pci 0000:01:00.0: BAR 2: assigned [io  0x1e160018-0x1e16001f]
> [   17.988605] pci 0000:01:00.0: BAR 1: assigned [io  0x1e160020-0x1e160023]
> [   18.002138] pci 0000:01:00.0: BAR 3: assigned [io  0x1e160024-0x1e160027]
> [   18.015673] pci 0000:00:00.0: PCI bridge to [bus 01]
> [   18.025572] pci 0000:00:00.0:   bridge window [io  0x1e160000-0x1e160fff]
> [   18.039096] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> [   18.052623] pci 0000:00:00.0:   bridge window [mem
> 0x60100000-0x601fffff pref]
> [   18.067026] pci 0000:02:00.0: BAR 5: assigned [mem 0x60200000-0x602001ff]
> [   18.080562] pci 0000:02:00.0: BAR 4: assigned [io  0x1e161000-0x1e16100f]
> [   18.094092] pci 0000:02:00.0: BAR 0: assigned [io  0x1e161010-0x1e161017]
> [   18.107625] pci 0000:02:00.0: BAR 2: assigned [io  0x1e161018-0x1e16101f]
> [   18.121158] pci 0000:02:00.0: BAR 1: assigned [io  0x1e161020-0x1e161023]
> [   18.134694] pci 0000:02:00.0: BAR 3: assigned [io  0x1e161024-0x1e161027]
> [   18.148225] pci 0000:00:01.0: PCI bridge to [bus 02]
> [   18.158117] pci 0000:00:01.0:   bridge window [io  0x1e161000-0x1e161fff]
> [   18.171643] pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
> [   18.185170] pci 0000:00:01.0:   bridge window [mem
> 0x60300000-0x603fffff pref]
> [   18.199591] pci 0000:03:00.0: BAR 5: assigned [mem 0x60400000-0x604001ff]
> [   18.213127] pci 0000:03:00.0: BAR 4: assigned [io  0x1e162000-0x1e16200f]
> [   18.226664] pci 0000:03:00.0: BAR 0: assigned [io  0x1e162010-0x1e162017]
> [   18.240199] pci 0000:03:00.0: BAR 2: assigned [io  0x1e162018-0x1e16201f]
> [   18.253751] pci 0000:03:00.0: BAR 1: assigned [io  0x1e162020-0x1e162023]
> [   18.267286] pci 0000:03:00.0: BAR 3: assigned [io  0x1e162024-0x1e162027]
> [   18.280814] pci 0000:00:02.0: PCI bridge to [bus 03]
> [   18.290713] pci 0000:00:02.0:   bridge window [io  0x1e162000-0x1e162fff]
> [   18.304243] pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
> [   18.317773] pci 0000:00:02.0:   bridge window [mem
> 0x60500000-0x605fffff pref]
>
> Reviewed-by: Sergio Paracuellos <sergio.paracuellos at gmail.com>
>
> Best regards,
>     Sergio Paracuellos


From sergio.paracuellos at gmail.com  Wed Apr 14 05:57:50 2021
From: sergio.paracuellos at gmail.com (Sergio Paracuellos)
Date: Wed, 14 Apr 2021 06:57:50 +0200
Subject: [PATCH] staging: mt7621-pci: stop using of_pci_range_to_resource
In-Reply-To: <CALCv0x3qc5MVP0fm3HWD2CF27tX8z=g1A9T+yR15teU3jgOg6Q@mail.gmail.com>
References: <20210410173331.57949-1-ilya.lipnitskiy@gmail.com>
 <CAMhs-H_GVj1DnhutUBo=Sdr38A8h9WnaJ7KX_-ge550qbujP7w@mail.gmail.com>
 <CALCv0x3qc5MVP0fm3HWD2CF27tX8z=g1A9T+yR15teU3jgOg6Q@mail.gmail.com>
Message-ID: <CAMhs-H-3+u0emL7oMex3ErgsD5=FtWQSuPXnLJT8axz+2y2oOw@mail.gmail.com>

Hi Illya,

On Wed, Apr 14, 2021 at 6:10 AM Ilya Lipnitskiy
<ilya.lipnitskiy at gmail.com> wrote:
>
> Hi Sergio,
>
> Just as an aside, are you planning to move staging/mt7621-pci into
> arch/mips/pci at some point? This driver seems more maintained (by
> you!) than many in-tree drivers...

Yes, I am planning to move it and maintain it. There is minor stuff
that must be changed before that but I hope to give that all a try
after the next merge window.

Best regards,
    Sergio Paracuellos
> Ilya
>
> On Sat, Apr 10, 2021 at 12:23 PM Sergio Paracuellos
> <sergio.paracuellos at gmail.com> wrote:
> >
> > Hi Ilya,
> >
> > On Sat, Apr 10, 2021 at 7:33 PM Ilya Lipnitskiy
> > <ilya.lipnitskiy at gmail.com> wrote:
> > >
> > > The logic here was already overriding the erroneous IO addresses
> > > returned from of_pci_range_to_resource, which is the bulk of the logic.
> > >
> > > So stop using it altogether and initialize the fields explicitly, as
> > > done in aeba3731b150 ("powerpc/pci: Fix IO space breakage after
> > > of_pci_range_to_resource() change").
> > >
> > > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > > Cc: Sergio Paracuellos <sergio.paracuellos at gmail.com>
> > > ---
> > >  drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++++++-----
> > >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > Looks good to me, thanks! I have also tested this in gnubee pc1
> > platform with no regressions at all when io bars are assigned:
> >
> > [   16.378956] mt7621-pci 1e140000.pcie: host bridge /pcie at 1e140000 ranges:
> > [   16.392405] mt7621-pci 1e140000.pcie:      MEM
> > 0x0060000000..0x006fffffff -> 0x0000000000
> > [   16.408796] mt7621-pci 1e140000.pcie:       IO
> > 0x001e160000..0x001e16ffff -> 0x0000000000
> > [   16.425264] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000
> > (dual port = 1)
> > [   16.440452] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000
> > (dual port = 0)
> > [   16.678713] mt7621-pci 1e140000.pcie: PCIE0 enabled
> > [   16.688435] mt7621-pci 1e140000.pcie: PCIE1 enabled
> > [   16.698160] mt7621-pci 1e140000.pcie: PCIE2 enabled
> > [   16.707886] mt7621-pci 1e140000.pcie: PCI coherence region base:
> > 0x60000000, mask/settings: 0xf0000002
> > [   16.726623] mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
> > [   16.739309] pci_bus 0000:00: root bus resource [io  0x1e160000-0x1e16ffff]
> > [   16.753008] pci_bus 0000:00: root bus resource [mem 0x60000000-0x6fffffff]
> > [   16.766709] pci_bus 0000:00: root bus resource [bus 00-ff]
> > [   16.777649] pci_bus 0000:00: root bus resource [mem
> > 0x60000000-0x6fffffff] (bus address [0x00000000-0x0fffffff])
> > [   16.797986] pci 0000:00:00.0: [0e8d:0801] type 01 class 0x060400
> > [   16.809973] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> > [   16.822467] pci 0000:00:00.0: reg 0x14: initial BAR value 0x00000000 invalid
> > [   16.836511] pci 0000:00:00.0: reg 0x14: [mem size 0x00010000]
> > [   16.848048] pci 0000:00:00.0: supports D1
> > [   16.856051] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
> > [   16.867943] pci 0000:00:01.0: [0e8d:0801] type 01 class 0x060400
> > [   16.879960] pci 0000:00:01.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> > [   16.892454] pci 0000:00:01.0: reg 0x14: initial BAR value 0x00000000 invalid
> > [   16.906497] pci 0000:00:01.0: reg 0x14: [mem size 0x00010000]
> > [   16.918040] pci 0000:00:01.0: supports D1
> > [   16.926031] pci 0000:00:01.0: PME# supported from D0 D1 D3hot
> > [   16.937903] pci 0000:00:02.0: [0e8d:0801] type 01 class 0x060400
> > [   16.949915] pci 0000:00:02.0: reg 0x10: [mem 0x00000000-0x7fffffff]
> > [   16.962412] pci 0000:00:02.0: reg 0x14: initial BAR value 0x00000000 invalid
> > [   16.976466] pci 0000:00:02.0: reg 0x14: [mem size 0x00010000]
> > [   16.987991] pci 0000:00:02.0: supports D1
> > [   16.995986] pci 0000:00:02.0: PME# supported from D0 D1 D3hot
> > [   17.008716] pci 0000:00:00.0: bridge configuration invalid ([bus
> > 00-00]), reconfiguring
> > [   17.024695] pci 0000:00:01.0: bridge configuration invalid ([bus
> > 00-00]), reconfiguring
> > [   17.040654] pci 0000:00:02.0: bridge configuration invalid ([bus
> > 00-00]), reconfiguring
> > [   17.056868] pci 0000:01:00.0: [1b21:0611] type 00 class 0x010185
> > [   17.068882] pci 0000:01:00.0: reg 0x10: [io  0x0000-0x0007]
> > [   17.080003] pci 0000:01:00.0: reg 0x14: [io  0x0000-0x0003]
> > [   17.091115] pci 0000:01:00.0: reg 0x18: [io  0x0000-0x0007]
> > [   17.102238] pci 0000:01:00.0: reg 0x1c: [io  0x0000-0x0003]
> > [   17.113350] pci 0000:01:00.0: reg 0x20: [io  0x0000-0x000f]
> > [   17.124463] pci 0000:01:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> > [   17.138508] pci 0000:01:00.0: reg 0x24: [mem size 0x00000200]
> > [   17.150115] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth,
> > limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000
> > Gb/s with 5.0 GT/s PCIe x1 link)
> > [   17.204594] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> > [   17.215109] pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > [   17.227257] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> > [   17.240785] pci 0000:00:00.0:   bridge window [mem
> > 0x60000000-0x600fffff pref]
> > [   17.255183] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> > [   17.268648] pci 0000:02:00.0: [1b21:0611] type 00 class 0x010185
> > [   17.280671] pci 0000:02:00.0: reg 0x10: [io  0x0000-0x0007]
> > [   17.291785] pci 0000:02:00.0: reg 0x14: [io  0x0000-0x0003]
> > [   17.302898] pci 0000:02:00.0: reg 0x18: [io  0x0000-0x0007]
> > [   17.314012] pci 0000:02:00.0: reg 0x1c: [io  0x0000-0x0003]
> > [   17.325127] pci 0000:02:00.0: reg 0x20: [io  0x0000-0x000f]
> > [   17.336241] pci 0000:02:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> > [   17.350279] pci 0000:02:00.0: reg 0x24: [mem size 0x00000200]
> > [   17.361893] pci 0000:02:00.0: 2.000 Gb/s available PCIe bandwidth,
> > limited by 2.5 GT/s PCIe x1 link at 0000:00:01.0 (capable of 4.000
> > Gb/s with 5.0 GT/s PCIe x1 link)
> > [   17.414591] pci 0000:00:01.0: PCI bridge to [bus 02-ff]
> > [   17.425063] pci 0000:00:01.0:   bridge window [io  0x0000-0x0fff]
> > [   17.437206] pci 0000:00:01.0:   bridge window [mem 0x60000000-0x600fffff]
> > [   17.450733] pci 0000:00:01.0:   bridge window [mem
> > 0x60000000-0x600fffff pref]
> > [   17.465130] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
> > [   17.478583] pci 0000:03:00.0: [1b21:0611] type 00 class 0x010185
> > [   17.490604] pci 0000:03:00.0: reg 0x10: [io  0x0000-0x0007]
> > [   17.501717] pci 0000:03:00.0: reg 0x14: [io  0x0000-0x0003]
> > [   17.512831] pci 0000:03:00.0: reg 0x18: [io  0x0000-0x0007]
> > [   17.523945] pci 0000:03:00.0: reg 0x1c: [io  0x0000-0x0003]
> > [   17.535060] pci 0000:03:00.0: reg 0x20: [io  0x0000-0x000f]
> > [   17.546174] pci 0000:03:00.0: reg 0x24: initial BAR value 0x00000000 invalid
> > [   17.560211] pci 0000:03:00.0: reg 0x24: [mem size 0x00000200]
> > [   17.571825] pci 0000:03:00.0: 2.000 Gb/s available PCIe bandwidth,
> > limited by 2.5 GT/s PCIe x1 link at 0000:00:02.0 (capable of 4.000
> > Gb/s with 5.0 GT/s PCIe x1 link)
> > [   17.624582] pci 0000:00:02.0: PCI bridge to [bus 03-ff]
> > [   17.635043] pci 0000:00:02.0:   bridge window [io  0x0000-0x0fff]
> > [   17.647188] pci 0000:00:02.0:   bridge window [mem 0x60000000-0x600fffff]
> > [   17.660710] pci 0000:00:02.0:   bridge window [mem
> > 0x60000000-0x600fffff pref]
> > [   17.675104] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
> > [   17.688358] pci 0000:00:00.0: BAR 0: no space for [mem size 0x80000000]
> > [   17.701534] pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x80000000]
> > [   17.715406] pci 0000:00:01.0: BAR 0: no space for [mem size 0x80000000]
> > [   17.728585] pci 0000:00:01.0: BAR 0: failed to assign [mem size 0x80000000]
> > [   17.742456] pci 0000:00:02.0: BAR 0: no space for [mem size 0x80000000]
> > [   17.755638] pci 0000:00:02.0: BAR 0: failed to assign [mem size 0x80000000]
> > [   17.769514] pci 0000:00:00.0: BAR 8: assigned [mem 0x60000000-0x600fffff]
> > [   17.783039] pci 0000:00:00.0: BAR 9: assigned [mem
> > 0x60100000-0x601fffff pref]
> > [   17.797429] pci 0000:00:01.0: BAR 8: assigned [mem 0x60200000-0x602fffff]
> > [   17.810958] pci 0000:00:01.0: BAR 9: assigned [mem
> > 0x60300000-0x603fffff pref]
> > [   17.825360] pci 0000:00:02.0: BAR 8: assigned [mem 0x60400000-0x604fffff]
> > [   17.838886] pci 0000:00:02.0: BAR 9: assigned [mem
> > 0x60500000-0x605fffff pref]
> > [   17.853279] pci 0000:00:00.0: BAR 1: assigned [mem 0x60600000-0x6060ffff]
> > [   17.866814] pci 0000:00:01.0: BAR 1: assigned [mem 0x60610000-0x6061ffff]
> > [   17.880346] pci 0000:00:02.0: BAR 1: assigned [mem 0x60620000-0x6062ffff]
> > [   17.893880] pci 0000:00:00.0: BAR 7: assigned [io  0x1e160000-0x1e160fff]
> > [   17.907410] pci 0000:00:01.0: BAR 7: assigned [io  0x1e161000-0x1e161fff]
> > [   17.920935] pci 0000:00:02.0: BAR 7: assigned [io  0x1e162000-0x1e162fff]
> > [   17.934474] pci 0000:01:00.0: BAR 5: assigned [mem 0x60000000-0x600001ff]
> > [   17.948008] pci 0000:01:00.0: BAR 4: assigned [io  0x1e160000-0x1e16000f]
> > [   17.961542] pci 0000:01:00.0: BAR 0: assigned [io  0x1e160010-0x1e160017]
> > [   17.975072] pci 0000:01:00.0: BAR 2: assigned [io  0x1e160018-0x1e16001f]
> > [   17.988605] pci 0000:01:00.0: BAR 1: assigned [io  0x1e160020-0x1e160023]
> > [   18.002138] pci 0000:01:00.0: BAR 3: assigned [io  0x1e160024-0x1e160027]
> > [   18.015673] pci 0000:00:00.0: PCI bridge to [bus 01]
> > [   18.025572] pci 0000:00:00.0:   bridge window [io  0x1e160000-0x1e160fff]
> > [   18.039096] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> > [   18.052623] pci 0000:00:00.0:   bridge window [mem
> > 0x60100000-0x601fffff pref]
> > [   18.067026] pci 0000:02:00.0: BAR 5: assigned [mem 0x60200000-0x602001ff]
> > [   18.080562] pci 0000:02:00.0: BAR 4: assigned [io  0x1e161000-0x1e16100f]
> > [   18.094092] pci 0000:02:00.0: BAR 0: assigned [io  0x1e161010-0x1e161017]
> > [   18.107625] pci 0000:02:00.0: BAR 2: assigned [io  0x1e161018-0x1e16101f]
> > [   18.121158] pci 0000:02:00.0: BAR 1: assigned [io  0x1e161020-0x1e161023]
> > [   18.134694] pci 0000:02:00.0: BAR 3: assigned [io  0x1e161024-0x1e161027]
> > [   18.148225] pci 0000:00:01.0: PCI bridge to [bus 02]
> > [   18.158117] pci 0000:00:01.0:   bridge window [io  0x1e161000-0x1e161fff]
> > [   18.171643] pci 0000:00:01.0:   bridge window [mem 0x60200000-0x602fffff]
> > [   18.185170] pci 0000:00:01.0:   bridge window [mem
> > 0x60300000-0x603fffff pref]
> > [   18.199591] pci 0000:03:00.0: BAR 5: assigned [mem 0x60400000-0x604001ff]
> > [   18.213127] pci 0000:03:00.0: BAR 4: assigned [io  0x1e162000-0x1e16200f]
> > [   18.226664] pci 0000:03:00.0: BAR 0: assigned [io  0x1e162010-0x1e162017]
> > [   18.240199] pci 0000:03:00.0: BAR 2: assigned [io  0x1e162018-0x1e16201f]
> > [   18.253751] pci 0000:03:00.0: BAR 1: assigned [io  0x1e162020-0x1e162023]
> > [   18.267286] pci 0000:03:00.0: BAR 3: assigned [io  0x1e162024-0x1e162027]
> > [   18.280814] pci 0000:00:02.0: PCI bridge to [bus 03]
> > [   18.290713] pci 0000:00:02.0:   bridge window [io  0x1e162000-0x1e162fff]
> > [   18.304243] pci 0000:00:02.0:   bridge window [mem 0x60400000-0x604fffff]
> > [   18.317773] pci 0000:00:02.0:   bridge window [mem
> > 0x60500000-0x605fffff pref]
> >
> > Reviewed-by: Sergio Paracuellos <sergio.paracuellos at gmail.com>
> >
> > Best regards,
> >     Sergio Paracuellos


From dan.carpenter at oracle.com  Wed Apr 14 06:33:36 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Wed, 14 Apr 2021 08:33:36 +0300
Subject: [PATCH net-next v2 1/2] of: net: pass the dst buffer to
 of_get_mac_address()
In-Reply-To: <20210406153725.10059-2-michael@walle.cc>
Message-ID: <20210414053336.GQ6021@kadam>

Hi Michael,

url:    https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git cc0626c2aaed8e475efdd85fa374b497a7192e35
config: x86_64-randconfig-m001-20210406 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

smatch warnings:
drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2069 axienet_probe() warn: passing a valid pointer to 'PTR_ERR'

vim +/PTR_ERR +2069 drivers/net/ethernet/xilinx/xilinx_axienet_main.c

522856cefaf09d Robert Hancock      2019-06-06  2060  	/* Check for Ethernet core IRQ (optional) */
522856cefaf09d Robert Hancock      2019-06-06  2061  	if (lp->eth_irq <= 0)
522856cefaf09d Robert Hancock      2019-06-06  2062  		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
522856cefaf09d Robert Hancock      2019-06-06  2063  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2064  	/* Retrieve the MAC address */
411b125c6ace1f Michael Walle       2021-04-06  2065  	ret = of_get_mac_address(pdev->dev.of_node, mac_addr);
411b125c6ace1f Michael Walle       2021-04-06  2066  	if (!ret) {
411b125c6ace1f Michael Walle       2021-04-06  2067  		axienet_set_mac_address(ndev, mac_addr);
411b125c6ace1f Michael Walle       2021-04-06  2068  	} else {
d05a9ed5c3a773 Robert Hancock      2019-06-06 @2069  		dev_warn(&pdev->dev, "could not find MAC address property: %ld\n",
d05a9ed5c3a773 Robert Hancock      2019-06-06  2070  			 PTR_ERR(mac_addr));
                                                                         ^^^^^^^^^^^^^^^^^
This should print "ret".

411b125c6ace1f Michael Walle       2021-04-06  2071  		axienet_set_mac_address(ndev, NULL);
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2072  	}
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2073  
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2074  	lp->coalesce_count_rx = XAXIDMA_DFT_RX_THRESHOLD;
8a3b7a252dca9f Daniel Borkmann     2012-01-19  2075  	lp->coalesce_count_tx = XAXIDMA_DFT_TX_THRESHOLD;

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31129 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210414/07453774/attachment-0001.gz>

From christophe.leroy at csgroup.eu  Wed Apr 14 06:22:06 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 14 Apr 2021 07:22:06 +0200
Subject: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
In-Reply-To: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
References: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>



Le 14/04/2021 ? 04:54, Anshuman Khandual a ?crit?:
> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
> for those platforms which would override generic default FIRST_USER_ADDRESS
> value 0UL. This makes it much cleaner with reduced code.
> 
> Cc: linux-alpha at vger.kernel.org
> Cc: linux-snps-arc at lists.infradead.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-csky at vger.kernel.org
> Cc: linux-hexagon at vger.kernel.org
> Cc: linux-ia64 at vger.kernel.org
> Cc: linux-m68k at lists.linux-m68k.org
> Cc: linux-mips at vger.kernel.org
> Cc: openrisc at lists.librecores.org
> Cc: linux-parisc at vger.kernel.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-riscv at lists.infradead.org
> Cc: linux-s390 at vger.kernel.org
> Cc: linux-sh at vger.kernel.org
> Cc: sparclinux at vger.kernel.org
> Cc: linux-um at lists.infradead.org
> Cc: linux-xtensa at linux-xtensa.org
> Cc: x86 at kernel.org
> Cc: linux-mm at kvack.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
>   arch/alpha/include/asm/pgtable.h             | 1 -
>   arch/arc/include/asm/pgtable.h               | 6 ------
>   arch/arm/Kconfig                             | 1 +
>   arch/arm64/include/asm/pgtable.h             | 2 --
>   arch/csky/include/asm/pgtable.h              | 1 -
>   arch/hexagon/include/asm/pgtable.h           | 3 ---
>   arch/ia64/include/asm/pgtable.h              | 1 -
>   arch/m68k/include/asm/pgtable_mm.h           | 1 -
>   arch/microblaze/include/asm/pgtable.h        | 2 --
>   arch/mips/include/asm/pgtable-32.h           | 1 -
>   arch/mips/include/asm/pgtable-64.h           | 1 -
>   arch/nds32/Kconfig                           | 1 +
>   arch/nios2/include/asm/pgtable.h             | 2 --
>   arch/openrisc/include/asm/pgtable.h          | 1 -
>   arch/parisc/include/asm/pgtable.h            | 2 --
>   arch/powerpc/include/asm/book3s/pgtable.h    | 1 -
>   arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>   arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>   arch/riscv/include/asm/pgtable.h             | 2 --
>   arch/s390/include/asm/pgtable.h              | 2 --
>   arch/sh/include/asm/pgtable.h                | 2 --
>   arch/sparc/include/asm/pgtable_32.h          | 1 -
>   arch/sparc/include/asm/pgtable_64.h          | 3 ---
>   arch/um/include/asm/pgtable-2level.h         | 1 -
>   arch/um/include/asm/pgtable-3level.h         | 1 -
>   arch/x86/include/asm/pgtable_types.h         | 2 --
>   arch/xtensa/include/asm/pgtable.h            | 1 -
>   include/linux/mm.h                           | 4 ++++
>   mm/Kconfig                                   | 4 ++++
>   29 files changed, 10 insertions(+), 43 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8ba434287387..47098ccd715e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>   
>   void init_mm_internals(void);
>   
> +#ifndef ARCH_HAS_FIRST_USER_ADDRESS

I guess you didn't test it ..... :)

should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS

> +#define FIRST_USER_ADDRESS	0UL
> +#endif

But why do we need a config option at all for that ?

Why not just:

#ifndef FIRST_USER_ADDRESS
#define FIRST_USER_ADDRESS	0UL
#endif

> +
>   #ifndef CONFIG_NEED_MULTIPLE_NODES	/* Don't use mapnrs, do it properly */
>   extern unsigned long max_mapnr;
>   
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 24c045b24b95..373fbe377075 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -806,6 +806,10 @@ config VMAP_PFN
>   
>   config ARCH_USES_HIGH_VMA_FLAGS
>   	bool
> +
> +config ARCH_HAS_FIRST_USER_ADDRESS
> +	bool
> +
>   config ARCH_HAS_PKEYS
>   	bool
>   
> 


From anshuman.khandual at arm.com  Wed Apr 14 06:59:40 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 14 Apr 2021 11:29:40 +0530
Subject: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
In-Reply-To: <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>
References: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
 <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>
Message-ID: <6d24d3cc-b2df-f0d7-f4bf-f505f679c77e@arm.com>



On 4/14/21 10:52 AM, Christophe Leroy wrote:
> 
> 
> Le 14/04/2021 ? 04:54, Anshuman Khandual a ?crit?:
>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>> for those platforms which would override generic default FIRST_USER_ADDRESS
>> value 0UL. This makes it much cleaner with reduced code.
>>
>> Cc: linux-alpha at vger.kernel.org
>> Cc: linux-snps-arc at lists.infradead.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-csky at vger.kernel.org
>> Cc: linux-hexagon at vger.kernel.org
>> Cc: linux-ia64 at vger.kernel.org
>> Cc: linux-m68k at lists.linux-m68k.org
>> Cc: linux-mips at vger.kernel.org
>> Cc: openrisc at lists.librecores.org
>> Cc: linux-parisc at vger.kernel.org
>> Cc: linuxppc-dev at lists.ozlabs.org
>> Cc: linux-riscv at lists.infradead.org
>> Cc: linux-s390 at vger.kernel.org
>> Cc: linux-sh at vger.kernel.org
>> Cc: sparclinux at vger.kernel.org
>> Cc: linux-um at lists.infradead.org
>> Cc: linux-xtensa at linux-xtensa.org
>> Cc: x86 at kernel.org
>> Cc: linux-mm at kvack.org
>> Cc: linux-kernel at vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> ? arch/alpha/include/asm/pgtable.h???????????? | 1 -
>> ? arch/arc/include/asm/pgtable.h?????????????? | 6 ------
>> ? arch/arm/Kconfig???????????????????????????? | 1 +
>> ? arch/arm64/include/asm/pgtable.h???????????? | 2 --
>> ? arch/csky/include/asm/pgtable.h????????????? | 1 -
>> ? arch/hexagon/include/asm/pgtable.h?????????? | 3 ---
>> ? arch/ia64/include/asm/pgtable.h????????????? | 1 -
>> ? arch/m68k/include/asm/pgtable_mm.h?????????? | 1 -
>> ? arch/microblaze/include/asm/pgtable.h??????? | 2 --
>> ? arch/mips/include/asm/pgtable-32.h?????????? | 1 -
>> ? arch/mips/include/asm/pgtable-64.h?????????? | 1 -
>> ? arch/nds32/Kconfig?????????????????????????? | 1 +
>> ? arch/nios2/include/asm/pgtable.h???????????? | 2 --
>> ? arch/openrisc/include/asm/pgtable.h????????? | 1 -
>> ? arch/parisc/include/asm/pgtable.h??????????? | 2 --
>> ? arch/powerpc/include/asm/book3s/pgtable.h??? | 1 -
>> ? arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>> ? arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>> ? arch/riscv/include/asm/pgtable.h???????????? | 2 --
>> ? arch/s390/include/asm/pgtable.h????????????? | 2 --
>> ? arch/sh/include/asm/pgtable.h??????????????? | 2 --
>> ? arch/sparc/include/asm/pgtable_32.h????????? | 1 -
>> ? arch/sparc/include/asm/pgtable_64.h????????? | 3 ---
>> ? arch/um/include/asm/pgtable-2level.h???????? | 1 -
>> ? arch/um/include/asm/pgtable-3level.h???????? | 1 -
>> ? arch/x86/include/asm/pgtable_types.h???????? | 2 --
>> ? arch/xtensa/include/asm/pgtable.h??????????? | 1 -
>> ? include/linux/mm.h?????????????????????????? | 4 ++++
>> ? mm/Kconfig?????????????????????????????????? | 4 ++++
>> ? 29 files changed, 10 insertions(+), 43 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 8ba434287387..47098ccd715e 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>> ? ? void init_mm_internals(void);
>> ? +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
> 
> I guess you didn't test it ..... :)

In fact I did :) Though just booted it on arm64 and cross compiled on
multiple others platforms.

> 
> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS

Right, meant that instead.

> 
>> +#define FIRST_USER_ADDRESS??? 0UL
>> +#endif
> 
> But why do we need a config option at all for that ?
> 
> Why not just:
> 
> #ifndef FIRST_USER_ADDRESS
> #define FIRST_USER_ADDRESS??? 0UL
> #endif

This sounds simpler. But just wondering, would not there be any possibility
of build problems due to compilation sequence between arch and generic code ?


From christophe.leroy at csgroup.eu  Wed Apr 14 07:10:49 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 14 Apr 2021 08:10:49 +0200
Subject: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
In-Reply-To: <6d24d3cc-b2df-f0d7-f4bf-f505f679c77e@arm.com>
References: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
 <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>
 <6d24d3cc-b2df-f0d7-f4bf-f505f679c77e@arm.com>
Message-ID: <ec7bbb30-dbbd-197b-4d65-eb3600fe6413@csgroup.eu>



Le 14/04/2021 ? 07:59, Anshuman Khandual a ?crit?:
> 
> 
> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>
>>
>> Le 14/04/2021 ? 04:54, Anshuman Khandual a ?crit?:
>>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>>> for those platforms which would override generic default FIRST_USER_ADDRESS
>>> value 0UL. This makes it much cleaner with reduced code.
>>>
>>> Cc: linux-alpha at vger.kernel.org
>>> Cc: linux-snps-arc at lists.infradead.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-csky at vger.kernel.org
>>> Cc: linux-hexagon at vger.kernel.org
>>> Cc: linux-ia64 at vger.kernel.org
>>> Cc: linux-m68k at lists.linux-m68k.org
>>> Cc: linux-mips at vger.kernel.org
>>> Cc: openrisc at lists.librecores.org
>>> Cc: linux-parisc at vger.kernel.org
>>> Cc: linuxppc-dev at lists.ozlabs.org
>>> Cc: linux-riscv at lists.infradead.org
>>> Cc: linux-s390 at vger.kernel.org
>>> Cc: linux-sh at vger.kernel.org
>>> Cc: sparclinux at vger.kernel.org
>>> Cc: linux-um at lists.infradead.org
>>> Cc: linux-xtensa at linux-xtensa.org
>>> Cc: x86 at kernel.org
>>> Cc: linux-mm at kvack.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>> ---
>>>  ? arch/alpha/include/asm/pgtable.h???????????? | 1 -
>>>  ? arch/arc/include/asm/pgtable.h?????????????? | 6 ------
>>>  ? arch/arm/Kconfig???????????????????????????? | 1 +
>>>  ? arch/arm64/include/asm/pgtable.h???????????? | 2 --
>>>  ? arch/csky/include/asm/pgtable.h????????????? | 1 -
>>>  ? arch/hexagon/include/asm/pgtable.h?????????? | 3 ---
>>>  ? arch/ia64/include/asm/pgtable.h????????????? | 1 -
>>>  ? arch/m68k/include/asm/pgtable_mm.h?????????? | 1 -
>>>  ? arch/microblaze/include/asm/pgtable.h??????? | 2 --
>>>  ? arch/mips/include/asm/pgtable-32.h?????????? | 1 -
>>>  ? arch/mips/include/asm/pgtable-64.h?????????? | 1 -
>>>  ? arch/nds32/Kconfig?????????????????????????? | 1 +
>>>  ? arch/nios2/include/asm/pgtable.h???????????? | 2 --
>>>  ? arch/openrisc/include/asm/pgtable.h????????? | 1 -
>>>  ? arch/parisc/include/asm/pgtable.h??????????? | 2 --
>>>  ? arch/powerpc/include/asm/book3s/pgtable.h??? | 1 -
>>>  ? arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>>>  ? arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>>>  ? arch/riscv/include/asm/pgtable.h???????????? | 2 --
>>>  ? arch/s390/include/asm/pgtable.h????????????? | 2 --
>>>  ? arch/sh/include/asm/pgtable.h??????????????? | 2 --
>>>  ? arch/sparc/include/asm/pgtable_32.h????????? | 1 -
>>>  ? arch/sparc/include/asm/pgtable_64.h????????? | 3 ---
>>>  ? arch/um/include/asm/pgtable-2level.h???????? | 1 -
>>>  ? arch/um/include/asm/pgtable-3level.h???????? | 1 -
>>>  ? arch/x86/include/asm/pgtable_types.h???????? | 2 --
>>>  ? arch/xtensa/include/asm/pgtable.h??????????? | 1 -
>>>  ? include/linux/mm.h?????????????????????????? | 4 ++++
>>>  ? mm/Kconfig?????????????????????????????????? | 4 ++++
>>>  ? 29 files changed, 10 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 8ba434287387..47098ccd715e 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>>>  ? ? void init_mm_internals(void);
>>>  ? +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
>>
>> I guess you didn't test it ..... :)
> 
> In fact I did :) Though just booted it on arm64 and cross compiled on
> multiple others platforms.
> 
>>
>> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
> 
> Right, meant that instead.
> 
>>
>>> +#define FIRST_USER_ADDRESS??? 0UL
>>> +#endif
>>
>> But why do we need a config option at all for that ?
>>
>> Why not just:
>>
>> #ifndef FIRST_USER_ADDRESS
>> #define FIRST_USER_ADDRESS??? 0UL
>> #endif
> 
> This sounds simpler. But just wondering, would not there be any possibility
> of build problems due to compilation sequence between arch and generic code ?
> 

For sure it has to be addresses carefully, but there are already a lot of stuff like that around 
pgtables.h

For instance, pte_offset_kernel() has a generic definition in linux/pgtables.h based on whether it 
is already defined or not.

Taking into account that FIRST_USER_ADDRESS is today in the architectures's asm/pgtables.h, I think 
putting the fallback definition in linux/pgtable.h would do the trick.


From dillon.minfei at gmail.com  Wed Apr 14 07:13:44 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:13:44 +0800
Subject: [PATCH v1 0/3] arm: imx: Add i.mx6q DaSheng COM-9XX SBC board support
Message-ID: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

This patchset aims to add kernel support on DaSheng COM-8XX SBC board
optimize ov2659 driver to handle xvclk on/off at proper stage to save power

changes based on master branch, since commit id:
89698becf06d341a700913c3d89ce2a914af69a2

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

dillon min (3):
  dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC board dts
    support
  arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support
  media: i2c: ov2659: Add clk_prepare_enable(), clk_disable_unprepare()
    to handle xvclk

 Documentation/devicetree/bindings/arm/fsl.yaml |   1 +
 arch/arm/boot/dts/Makefile                     |   1 +
 arch/arm/boot/dts/imx6q-ds.dts                 |  18 +
 arch/arm/boot/dts/imx6qdl-ds.dtsi              | 465 +++++++++++++++++++++++++
 drivers/media/i2c/ov2659.c                     |  24 +-
 5 files changed, 503 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:13:45 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:13:45 +0800
Subject: [PATCH v1 1/3] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
 board dts support
In-Reply-To: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
References: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618380827-16056-2-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.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 297c87f45db8..24bdfbd4853f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -206,6 +206,7 @@ properties:
               - fsl,imx6q-sabreauto
               - fsl,imx6q-sabrelite
               - fsl,imx6q-sabresd
+              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
               - karo,imx6q-tx6q           # Ka-Ro electronics TX6Q Modules
               - kiebackpeter,imx6q-tpc    # K+P i.MX6 Quad TPC Board
               - kontron,imx6q-samx6i      # Kontron i.MX6 Dual/Quad SMARC Module
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:13:46 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:13:46 +0800
Subject: [PATCH v1 2/3] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board
 support
In-Reply-To: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
References: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618380827-16056-3-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/imx6q-ds.dts    |  18 ++
 arch/arm/boot/dts/imx6qdl-ds.dtsi | 465 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 484 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a19c5ab9df84..ecbac8e5336c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -562,6 +562,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
 	imx6q-sabresd.dtb \
+	imx6q-ds.dtb \
 	imx6q-savageboard.dtb \
 	imx6q-sbc6x.dtb \
 	imx6q-tbs2910.dtb \
diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
new file mode 100644
index 000000000000..1056e1749536
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ds.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-ds.dtsi"
+
+/ {
+	model = "DaSheng i.MX6 Quad Com-9xx Board";
+	compatible = "ds,imx6q-sbc", "fsl,imx6q";
+};
+
diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
new file mode 100644
index 000000000000..d28e065349cd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	memory at 10000000 {
+		device_type = "memory";
+		reg = <0x10000000 0x80000000>;
+	};
+
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb_h1_vbus: regulator-usb-h1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_h1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_leds>;
+
+		green {
+			gpios = <&gpio4 8 0>;
+			default-state = "on";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+	bus-width = <8>;
+	data-shift = <12>; /* Lines 19:12 used */
+	hsync-active = <1>;
+	vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+	remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ipu1_csi0>;
+	status = "okay";
+};
+
+&clks {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&ecspi1 {
+	cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "okay";
+
+	flash: m25p80 at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,m25p80", "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy>;
+	fsl,magic-packet;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy: ethernet-phy at 1 {
+			reg = <1>;
+			qca,clk-out-frequency = <125000000>;
+			reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+		};
+	};
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hdmi_cec>;
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	pmic: pfuze100 at 8 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3b_reg: sw3b {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw4_reg: sw4 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vgen1 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen2_reg: vgen2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ov2659: camera at 30 {
+		compatible = "ovti,ov2659";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ov2659>;
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		clock-names = "xvclk";
+		reg = <0x30>;
+		powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+		status = "okay";
+
+		port {
+			ov2659_to_ipu1_csi0_mux: endpoint {
+				remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+				link-frequencies = /bits/ 64 <70000000>;
+				bus-width = <8>;
+				hsync-active = <1>;
+				vsync-active = <1>;
+			};
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	imx6qdl-ds {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
+				MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+				MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+			>;
+		};
+
+		pinctrl_ecspi1: ecspi1grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_ROW1__GPIO4_IO09	0x1b0b0
+				MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
+				MX6QDL_PAD_EIM_D16__ECSPI1_SCLK	0x100b1
+				MX6QDL_PAD_EIM_D18__ECSPI1_MOSI	0x100b1
+				MX6QDL_PAD_EIM_D17__ECSPI1_MISO	0x100b1
+			>;
+		};
+
+		pinctrl_enet: enetgrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
+				MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
+				MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x1b030
+				MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x1b030
+				MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x1b030
+				MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x1b030
+				MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x1b030
+				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x1b030
+				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x1b0b0
+				MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b030
+				MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b030
+				MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b030
+				MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b030
+				MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b030
+				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b030
+			>;
+		};
+
+		pinctrl_hdmi_cec: hdmicecgrp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE	0x1f8b0
+			>;
+		};
+
+		pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_EB2__I2C2_SCL		0x4001b8b1
+				MX6QDL_PAD_KEY_ROW3__I2C2_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_i2c3: i2c3grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_5__I2C3_SCL		0x4001b8b1
+				MX6QDL_PAD_GPIO_6__I2C3_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_ipu1_csi0: ipu1csi0grp {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
+				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
+				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
+				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
+			>;
+		};
+
+		pinctrl_ov2659: ov2659grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x1b0b0
+				MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+			>;
+		};
+
+		pinctrl_uart4: uart4grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL0__UART4_TX_DATA	0x1b0b1
+				MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA	0x1b0b1
+			>;
+		};
+
+		pinctrl_usbotg: usbotggrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID	0x17059
+			>;
+		};
+
+		pinctrl_usdhc1: usdhc1grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD1_CMD__SD1_CMD		0x17059
+				MX6QDL_PAD_SD1_CLK__SD1_CLK		0x10059
+				MX6QDL_PAD_SD1_DAT0__SD1_DATA0		0x17059
+				MX6QDL_PAD_SD1_DAT1__SD1_DATA1		0x17059
+				MX6QDL_PAD_SD1_DAT2__SD1_DATA2		0x17059
+				MX6QDL_PAD_SD1_DAT3__SD1_DATA3		0x17059
+				MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28	0x1b0b0
+			>;
+		};
+
+		pinctrl_usdhc2: usdhc2grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+				MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10059
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+			>;
+		};
+
+		pinctrl_usdhc3: usdhc3grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+				MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10059
+				MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+				MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+				MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+				MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+				MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+				MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+				MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+				MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+			>;
+		};
+
+		pinctrl_wdog: wdoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_1__WDOG2_B		0x1b0b0
+			>;
+		};
+	};
+
+	gpio_leds {
+		pinctrl_gpio_leds: gpioledsgrp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
+			>;
+		};
+	};
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usb_h1_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	bus-width = <8>;
+	non-removable;
+	no-1-8-v;
+	status = "okay";
+};
+
+&wdog1 {
+	status = "okay";
+};
+
+&wdog2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "disabled";
+};
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:13:47 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:13:47 +0800
Subject: [PATCH v1 3/3] media: i2c: ov2659: Add clk_prepare_enable(),
 clk_disable_unprepare() to handle xvclk
In-Reply-To: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
References: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618380827-16056-4-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

For power save purpose, xvclk might not be always on.
need add clk_prepare_enable(), clk_disable_unprepare() at driver
side to set xvclk on/off at proper stage.

Add following changes:
- add 'struct clk *clk' in 'struct ov2659'
- enable xvclk in ov2659_power_on()
- disable xvclk in ov2659_power_off()

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
 drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 42f64175a6df..fb78a1cedc03 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -204,6 +204,7 @@ struct ov2659 {
 	struct i2c_client *client;
 	struct v4l2_ctrl_handler ctrls;
 	struct v4l2_ctrl *link_frequency;
+	struct clk *clk;
 	const struct ov2659_framesize *frame_size;
 	struct sensor_register *format_ctrl_regs;
 	struct ov2659_pll_ctrl pll;
@@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
 
 	gpiod_set_value(ov2659->pwdn_gpio, 1);
 
+	clk_disable_unprepare(ov2659->clk);
+
 	return 0;
 }
 
@@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
 	struct i2c_client *client = to_i2c_client(dev);
 	struct v4l2_subdev *sd = i2c_get_clientdata(client);
 	struct ov2659 *ov2659 = to_ov2659(sd);
+	int ret;
 
 	dev_dbg(&client->dev, "%s:\n", __func__);
 
+	ret = clk_prepare_enable(ov2659->clk);
+	if (ret) {
+		dev_err(&client->dev, "%s: failed to enable clock\n",
+			__func__);
+		return ret;
+	}
+
 	gpiod_set_value(ov2659->pwdn_gpio, 0);
 
 	if (ov2659->resetb_gpio) {
@@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
 	const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
 	struct v4l2_subdev *sd;
 	struct ov2659 *ov2659;
-	struct clk *clk;
 	int ret;
 
 	if (!pdata) {
@@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->pdata = pdata;
 	ov2659->client = client;
 
-	clk = devm_clk_get(&client->dev, "xvclk");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
+	ov2659->clk = devm_clk_get(&client->dev, "xvclk");
+	if (IS_ERR(ov2659->clk))
+		return PTR_ERR(ov2659->clk);
 
-	ov2659->xvclk_frequency = clk_get_rate(clk);
+	ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
 	if (ov2659->xvclk_frequency < 6000000 ||
 	    ov2659->xvclk_frequency > 27000000)
 		return -EINVAL;
@@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->frame_size = &ov2659_framesizes[2];
 	ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
 
-	ov2659_power_on(&client->dev);
+	ret = ov2659_power_on(&client->dev);
+	if (ret < 0)
+		goto error;
 
 	ret = ov2659_detect(sd);
 	if (ret < 0)
-- 
2.7.4



From krzysztof.kozlowski at canonical.com  Wed Apr 14 07:22:34 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 08:22:34 +0200
Subject: [PATCH v1 1/3] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC board dts support
In-Reply-To: <1618380827-16056-2-git-send-email-dillon.minfei@gmail.com>
References: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
 <1618380827-16056-2-git-send-email-dillon.minfei@gmail.com>
Message-ID: <2a993aa9-6933-4af8-da26-f53096dc6ab7@canonical.com>

On 14/04/2021 08:13, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.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 297c87f45db8..24bdfbd4853f 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -206,6 +206,7 @@ properties:
>                - fsl,imx6q-sabreauto
>                - fsl,imx6q-sabrelite
>                - fsl,imx6q-sabresd
> +              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
>                - karo,imx6q-tx6q           # Ka-Ro electronics TX6Q Modules
>                - kiebackpeter,imx6q-tpc    # K+P i.MX6 Quad TPC Board
>                - kontron,imx6q-samx6i      # Kontron i.MX6 Dual/Quad SMARC Module
> 

You miss change in vendor prefixes. Didn't checkpatch complain about it?
Did you run checkpatch?
Best regards,
Best regards,
Krzysztof


From dillon.minfei at gmail.com  Wed Apr 14 07:40:26 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Wed, 14 Apr 2021 14:40:26 +0800
Subject: [PATCH v1 1/3] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC board dts support
In-Reply-To: <2a993aa9-6933-4af8-da26-f53096dc6ab7@canonical.com>
References: <1618380827-16056-1-git-send-email-dillon.minfei@gmail.com>
 <1618380827-16056-2-git-send-email-dillon.minfei@gmail.com>
 <2a993aa9-6933-4af8-da26-f53096dc6ab7@canonical.com>
Message-ID: <CAL9mu0+U2PN2HsQdw5mYGap+bH_YN55RyT-tw65EfH3zKxwScQ@mail.gmail.com>

On Wed, Apr 14, 2021 at 2:22 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On 14/04/2021 08:13, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> > featuring:
> > - i.MX6Q
> > - 2GiB LPDDR3 DRAM
> > - 8GiB eMMC 5.0 FLASH
> > - 4MiB SPI Flash
> > - USB 2.0 Host/Device
> > - Multiple multi-protocol RS232/RS485 Serial ports
> > - microSD socket
> > - 5V DC power input
> > - HDMI1.4a,1080p at 60
> > - RGMIIx1 Gigabit Ethernet
> > - CSI0x1, connect with ov2659
> >
> > Signed-off-by: dillon min <dillon.minfei at gmail.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 297c87f45db8..24bdfbd4853f 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -206,6 +206,7 @@ properties:
> >                - fsl,imx6q-sabreauto
> >                - fsl,imx6q-sabrelite
> >                - fsl,imx6q-sabresd
> > +              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
> >                - karo,imx6q-tx6q           # Ka-Ro electronics TX6Q Modules
> >                - kiebackpeter,imx6q-tpc    # K+P i.MX6 Quad TPC Board
> >                - kontron,imx6q-samx6i      # Kontron i.MX6 Dual/Quad SMARC Module
> >
>
> You miss change in vendor prefixes. Didn't checkpatch complain about it?
> Did you run checkpatch?

Yes. was checked with checkpatch, since it's a warning, i forget to
fix it.thanks.
Will add vendor prefixes to vendor-prefixes.yaml in v2

Thanks.
Dillon,

> Best regards,
> Best regards,
> Krzysztof


From sfr at canb.auug.org.au  Wed Apr 14 07:45:15 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 14 Apr 2021 16:45:15 +1000
Subject: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64
 define
In-Reply-To: <CAK8P3a2MSJarPMfJ8RrSKDMXte3KQec=+GQ-LzV6HB7-Nm1FcQ@mail.gmail.com>
References: <20210412085545.2595431-1-hch@lst.de>
 <20210412085545.2595431-2-hch@lst.de>
 <CAK8P3a2MSJarPMfJ8RrSKDMXte3KQec=+GQ-LzV6HB7-Nm1FcQ@mail.gmail.com>
Message-ID: <20210414164515.7358054a@canb.auug.org.au>

Hi Arnd,

On Mon, 12 Apr 2021 11:55:41 +0200 Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch at lst.de> wrote:
> >
> > Signed-off-by: Christoph Hellwig <hch at lst.de>  
> 
> The patch looks good, but I'd like to see a description for each one.
> How about:
> 
> | The check was added when Stephen Rothwell created the file, but
> | no architecture ever defined it.

Actually it was used by the xtensa architecture until Dec, 2006.

-- 
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/20210414/3c701f1c/attachment.sig>

From dillon.minfei at gmail.com  Wed Apr 14 07:51:53 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:51:53 +0800
Subject: [PATCH v2 0/4] arm: imx: Add i.mx6q DaSheng COM-9XX SBC board support
Message-ID: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

This patchset aims to add kernel support on DaSheng COM-8XX SBC board
optimize ov2659 driver to handle xvclk on/off at proper stage to save power

changes based on master branch, since commit id:
89698becf06d341a700913c3d89ce2a914af69a2

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

v2:
- add "[PATCH v2 4/4] dt-bindings: add dasheng vendor prefix" to fix
  checkpatch.pl warning.

dillon min (4):
  dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC board dts
    support
  arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support
  media: i2c: ov2659: Add clk_prepare_enable(),  clk_disable_unprepare()
    to handle xvclk
  dt-bindings: add dasheng vendor prefix

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/imx6q-ds.dts                     |  17 +
 arch/arm/boot/dts/imx6qdl-ds.dtsi                  | 465 +++++++++++++++++++++
 drivers/media/i2c/ov2659.c                         |  24 +-
 6 files changed, 504 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

-- 
2.7.4



From zhukeqian1 at huawei.com  Wed Apr 14 07:51:07 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 14 Apr 2021 14:51:07 +0800
Subject: [PATCH v3 0/2] kvm/arm64: Try stage2 block mapping for host device
 MMIO
Message-ID: <20210414065109.8616-1-zhukeqian1@huawei.com>

Hi,

We have two pathes to build stage2 mapping for MMIO regions.

Create time's path and stage2 fault path.

Patch#1 removes the creation time's mapping of MMIO regions
Patch#2 tries stage2 block mapping for host device MMIO at fault path

Changelog:

v3:
 - Do not need to check memslot boundary in device_rough_page_shift(). (Marc)

Thanks,
Keqian

Keqian Zhu (2):
  kvm/arm64: Remove the creation time's mapping of MMIO regions
  kvm/arm64: Try stage2 block mapping for host device MMIO

 arch/arm64/kvm/mmu.c | 75 +++++++++++++++++++++-----------------------
 1 file changed, 36 insertions(+), 39 deletions(-)

-- 
2.19.1



From zhukeqian1 at huawei.com  Wed Apr 14 07:51:09 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 14 Apr 2021 14:51:09 +0800
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host device
 MMIO
In-Reply-To: <20210414065109.8616-1-zhukeqian1@huawei.com>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
Message-ID: <20210414065109.8616-3-zhukeqian1@huawei.com>

The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.

Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:

1. For normal memory mapping, the PA(host physical address) and
HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
the HVA to request hugepage, so we don't need to consider PA
alignment when verifing block mapping. But for device memory
mapping, the PA and HVA may have different alignment.

2. For normal memory mapping, we are sure hugepage size properly
fit into vma, so we don't check whether the mapping size exceeds
the boundary of vma. But for device memory mapping, we should pay
attention to this.

This adds device_rough_page_shift() to check these two points when
selecting block mapping size.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index c59af5ca01b0..1a6d96169d60 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
 	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
 }
 
+/*
+ * Find a max mapping size that properly insides the vma. And hva and pa must
+ * have the same alignment to this mapping size. It's rough as there are still
+ * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
+ */
+static short device_rough_page_shift(struct vm_area_struct *vma,
+				     unsigned long hva)
+{
+	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
+		return PUD_SHIFT;
+#endif
+
+	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
+		return PMD_SHIFT;
+
+	return PAGE_SHIFT;
+}
+
 static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
 					       unsigned long hva,
 					       unsigned long map_size)
@@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 	}
 
-	/* Let's check if we will get back a huge page backed by hugetlbfs */
+	/*
+	 * Let's check if we will get back a huge page backed by hugetlbfs, or
+	 * get block mapping for device MMIO region.
+	 */
 	mmap_read_lock(current->mm);
 	vma = find_vma_intersection(current->mm, hva, hva + 1);
 	if (unlikely(!vma)) {
@@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 
 	if (is_vm_hugetlb_page(vma))
 		vma_shift = huge_page_shift(hstate_vma(vma));
+	else if (vma->vm_flags & VM_PFNMAP)
+		vma_shift = device_rough_page_shift(vma, hva);
 	else
 		vma_shift = PAGE_SHIFT;
 
-	if (logging_active ||
-	    (vma->vm_flags & VM_PFNMAP)) {
+	if (logging_active) {
 		force_pte = true;
 		vma_shift = PAGE_SHIFT;
 	}
@@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 
 	if (kvm_is_device_pfn(pfn)) {
 		device = true;
-		force_pte = true;
+		force_pte = (vma_pagesize == PAGE_SIZE);
 	} else if (logging_active && !write_fault) {
 		/*
 		 * Only actually map the page as writable if this was a write
-- 
2.19.1



From zhukeqian1 at huawei.com  Wed Apr 14 07:51:08 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 14 Apr 2021 14:51:08 +0800
Subject: [PATCH v3 1/2] kvm/arm64: Remove the creation time's mapping of MMIO
 regions
In-Reply-To: <20210414065109.8616-1-zhukeqian1@huawei.com>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
Message-ID: <20210414065109.8616-2-zhukeqian1@huawei.com>

The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.

Remove the mapping code while keep the useful sanity check.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
 1 file changed, 3 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..c59af5ca01b0 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 {
 	hva_t hva = mem->userspace_addr;
 	hva_t reg_end = hva + mem->memory_size;
-	bool writable = !(mem->flags & KVM_MEM_READONLY);
 	int ret = 0;
 
 	if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
@@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 	mmap_read_lock(current->mm);
 	/*
 	 * A memory region could potentially cover multiple VMAs, and any holes
-	 * between them, so iterate over all of them to find out if we can map
-	 * any of them right now.
+	 * between them, so iterate over all of them.
 	 *
 	 *     +--------------------------------------------+
 	 * +---------------+----------------+   +----------------+
@@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 	 */
 	do {
 		struct vm_area_struct *vma = find_vma(current->mm, hva);
-		hva_t vm_start, vm_end;
 
 		if (!vma || vma->vm_start >= reg_end)
 			break;
 
-		/*
-		 * Take the intersection of this VMA with the memory region
-		 */
-		vm_start = max(hva, vma->vm_start);
-		vm_end = min(reg_end, vma->vm_end);
-
 		if (vma->vm_flags & VM_PFNMAP) {
-			gpa_t gpa = mem->guest_phys_addr +
-				    (vm_start - mem->userspace_addr);
-			phys_addr_t pa;
-
-			pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
-			pa += vm_start - vma->vm_start;
-
 			/* IO region dirty page logging not allowed */
 			if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
 				ret = -EINVAL;
-				goto out;
-			}
-
-			ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
-						    vm_end - vm_start,
-						    writable);
-			if (ret)
 				break;
+			}
 		}
-		hva = vm_end;
+		hva = min(reg_end, vma->vm_end);
 	} while (hva < reg_end);
 
-	if (change == KVM_MR_FLAGS_ONLY)
-		goto out;
-
-	spin_lock(&kvm->mmu_lock);
-	if (ret)
-		unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
-	else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
-		stage2_flush_memslot(kvm, memslot);
-	spin_unlock(&kvm->mmu_lock);
-out:
 	mmap_read_unlock(current->mm);
 	return ret;
 }
-- 
2.19.1



From dillon.minfei at gmail.com  Wed Apr 14 07:51:54 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:51:54 +0800
Subject: [PATCH v2 1/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
 board dts support
In-Reply-To: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618383117-17179-2-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
v2: no changes

 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 297c87f45db8..24bdfbd4853f 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -206,6 +206,7 @@ properties:
               - fsl,imx6q-sabreauto
               - fsl,imx6q-sabrelite
               - fsl,imx6q-sabresd
+              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
               - karo,imx6q-tx6q           # Ka-Ro electronics TX6Q Modules
               - kiebackpeter,imx6q-tpc    # K+P i.MX6 Quad TPC Board
               - kontron,imx6q-samx6i      # Kontron i.MX6 Dual/Quad SMARC Module
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:51:55 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:51:55 +0800
Subject: [PATCH v2 2/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board
 support
In-Reply-To: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618383117-17179-3-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v2: no changes

 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/imx6q-ds.dts    |  17 ++
 arch/arm/boot/dts/imx6qdl-ds.dtsi | 465 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 483 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a19c5ab9df84..ecbac8e5336c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -562,6 +562,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-sabreauto.dtb \
 	imx6q-sabrelite.dtb \
 	imx6q-sabresd.dtb \
+	imx6q-ds.dtb \
 	imx6q-savageboard.dtb \
 	imx6q-sbc6x.dtb \
 	imx6q-tbs2910.dtb \
diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
new file mode 100644
index 000000000000..b0a63a133977
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ds.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-ds.dtsi"
+
+/ {
+	model = "DaSheng i.MX6 Quad Com-9xx Board";
+	compatible = "ds,imx6q-sbc", "fsl,imx6q";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
new file mode 100644
index 000000000000..d28e065349cd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	memory at 10000000 {
+		device_type = "memory";
+		reg = <0x10000000 0x80000000>;
+	};
+
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb_h1_vbus: regulator-usb-h1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_h1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_leds>;
+
+		green {
+			gpios = <&gpio4 8 0>;
+			default-state = "on";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+	bus-width = <8>;
+	data-shift = <12>; /* Lines 19:12 used */
+	hsync-active = <1>;
+	vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+	remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ipu1_csi0>;
+	status = "okay";
+};
+
+&clks {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&ecspi1 {
+	cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "okay";
+
+	flash: m25p80 at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,m25p80", "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy>;
+	fsl,magic-packet;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy: ethernet-phy at 1 {
+			reg = <1>;
+			qca,clk-out-frequency = <125000000>;
+			reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+		};
+	};
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hdmi_cec>;
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	pmic: pfuze100 at 8 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3b_reg: sw3b {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw4_reg: sw4 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vgen1 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen2_reg: vgen2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ov2659: camera at 30 {
+		compatible = "ovti,ov2659";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ov2659>;
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		clock-names = "xvclk";
+		reg = <0x30>;
+		powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+		status = "okay";
+
+		port {
+			ov2659_to_ipu1_csi0_mux: endpoint {
+				remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+				link-frequencies = /bits/ 64 <70000000>;
+				bus-width = <8>;
+				hsync-active = <1>;
+				vsync-active = <1>;
+			};
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	imx6qdl-ds {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
+				MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+				MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+			>;
+		};
+
+		pinctrl_ecspi1: ecspi1grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_ROW1__GPIO4_IO09	0x1b0b0
+				MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
+				MX6QDL_PAD_EIM_D16__ECSPI1_SCLK	0x100b1
+				MX6QDL_PAD_EIM_D18__ECSPI1_MOSI	0x100b1
+				MX6QDL_PAD_EIM_D17__ECSPI1_MISO	0x100b1
+			>;
+		};
+
+		pinctrl_enet: enetgrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
+				MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
+				MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x1b030
+				MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x1b030
+				MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x1b030
+				MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x1b030
+				MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x1b030
+				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x1b030
+				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x1b0b0
+				MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b030
+				MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b030
+				MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b030
+				MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b030
+				MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b030
+				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b030
+			>;
+		};
+
+		pinctrl_hdmi_cec: hdmicecgrp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE	0x1f8b0
+			>;
+		};
+
+		pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_EB2__I2C2_SCL		0x4001b8b1
+				MX6QDL_PAD_KEY_ROW3__I2C2_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_i2c3: i2c3grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_5__I2C3_SCL		0x4001b8b1
+				MX6QDL_PAD_GPIO_6__I2C3_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_ipu1_csi0: ipu1csi0grp {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
+				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
+				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
+				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
+			>;
+		};
+
+		pinctrl_ov2659: ov2659grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x1b0b0
+				MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+			>;
+		};
+
+		pinctrl_uart4: uart4grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL0__UART4_TX_DATA	0x1b0b1
+				MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA	0x1b0b1
+			>;
+		};
+
+		pinctrl_usbotg: usbotggrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID	0x17059
+			>;
+		};
+
+		pinctrl_usdhc1: usdhc1grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD1_CMD__SD1_CMD		0x17059
+				MX6QDL_PAD_SD1_CLK__SD1_CLK		0x10059
+				MX6QDL_PAD_SD1_DAT0__SD1_DATA0		0x17059
+				MX6QDL_PAD_SD1_DAT1__SD1_DATA1		0x17059
+				MX6QDL_PAD_SD1_DAT2__SD1_DATA2		0x17059
+				MX6QDL_PAD_SD1_DAT3__SD1_DATA3		0x17059
+				MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28	0x1b0b0
+			>;
+		};
+
+		pinctrl_usdhc2: usdhc2grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+				MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10059
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+			>;
+		};
+
+		pinctrl_usdhc3: usdhc3grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+				MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10059
+				MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+				MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+				MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+				MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+				MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+				MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+				MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+				MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+			>;
+		};
+
+		pinctrl_wdog: wdoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_1__WDOG2_B		0x1b0b0
+			>;
+		};
+	};
+
+	gpio_leds {
+		pinctrl_gpio_leds: gpioledsgrp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
+			>;
+		};
+	};
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usb_h1_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	bus-width = <8>;
+	non-removable;
+	no-1-8-v;
+	status = "okay";
+};
+
+&wdog1 {
+	status = "okay";
+};
+
+&wdog2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "disabled";
+};
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:51:56 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:51:56 +0800
Subject: [PATCH v2 3/4] media: i2c: ov2659: Add clk_prepare_enable(),
 clk_disable_unprepare() to handle xvclk
In-Reply-To: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618383117-17179-4-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

For power save purpose, xvclk might not be always on.
need add clk_prepare_enable(), clk_disable_unprepare() at driver
side to set xvclk on/off at proper stage.

Add following changes:
- add 'struct clk *clk' in 'struct ov2659'
- enable xvclk in ov2659_power_on()
- disable xvclk in ov2659_power_off()

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v2: no changes

 drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 42f64175a6df..fb78a1cedc03 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -204,6 +204,7 @@ struct ov2659 {
 	struct i2c_client *client;
 	struct v4l2_ctrl_handler ctrls;
 	struct v4l2_ctrl *link_frequency;
+	struct clk *clk;
 	const struct ov2659_framesize *frame_size;
 	struct sensor_register *format_ctrl_regs;
 	struct ov2659_pll_ctrl pll;
@@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
 
 	gpiod_set_value(ov2659->pwdn_gpio, 1);
 
+	clk_disable_unprepare(ov2659->clk);
+
 	return 0;
 }
 
@@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
 	struct i2c_client *client = to_i2c_client(dev);
 	struct v4l2_subdev *sd = i2c_get_clientdata(client);
 	struct ov2659 *ov2659 = to_ov2659(sd);
+	int ret;
 
 	dev_dbg(&client->dev, "%s:\n", __func__);
 
+	ret = clk_prepare_enable(ov2659->clk);
+	if (ret) {
+		dev_err(&client->dev, "%s: failed to enable clock\n",
+			__func__);
+		return ret;
+	}
+
 	gpiod_set_value(ov2659->pwdn_gpio, 0);
 
 	if (ov2659->resetb_gpio) {
@@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
 	const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
 	struct v4l2_subdev *sd;
 	struct ov2659 *ov2659;
-	struct clk *clk;
 	int ret;
 
 	if (!pdata) {
@@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->pdata = pdata;
 	ov2659->client = client;
 
-	clk = devm_clk_get(&client->dev, "xvclk");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
+	ov2659->clk = devm_clk_get(&client->dev, "xvclk");
+	if (IS_ERR(ov2659->clk))
+		return PTR_ERR(ov2659->clk);
 
-	ov2659->xvclk_frequency = clk_get_rate(clk);
+	ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
 	if (ov2659->xvclk_frequency < 6000000 ||
 	    ov2659->xvclk_frequency > 27000000)
 		return -EINVAL;
@@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->frame_size = &ov2659_framesizes[2];
 	ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
 
-	ov2659_power_on(&client->dev);
+	ret = ov2659_power_on(&client->dev);
+	if (ret < 0)
+		goto error;
 
 	ret = ov2659_detect(sd);
 	if (ret < 0)
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 14 07:51:57 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 14 Apr 2021 14:51:57 +0800
Subject: [PATCH v2 4/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618383117-17179-5-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

Add vendor prefix for DaSheng, Inc.

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v2: new add

 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 f6064d84a424..4ec28488c963 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -309,6 +309,8 @@ patternProperties:
     description: DPTechnics
   "^dragino,.*":
     description: Dragino Technology Co., Limited
+  "^ds,.*":
+    description: DaSheng, Inc.
   "^dserve,.*":
     description: dServe Technology B.V.
   "^dynaimage,.*":
-- 
2.7.4



From zhukeqian1 at huawei.com  Wed Apr 14 07:58:40 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 14 Apr 2021 14:58:40 +0800
Subject: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <9f74392b-1086-a85e-72d8-f7bd99d65ea7@huawei.com>
References: <20210316134338.18052-1-zhukeqian1@huawei.com>
 <20210316134338.18052-3-zhukeqian1@huawei.com> <878s5up71v.wl-maz@kernel.org>
 <9f74392b-1086-a85e-72d8-f7bd99d65ea7@huawei.com>
Message-ID: <f1d9f7c2-969f-336a-9744-5706d6c59298@huawei.com>

Hi Marc,

On 2021/4/8 15:28, Keqian Zhu wrote:
> Hi Marc,
> 
> On 2021/4/7 21:18, Marc Zyngier wrote:
>> On Tue, 16 Mar 2021 13:43:38 +0000,
>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>>
[...]

>>>  
>>> +/*
>>> + * Find a mapping size that properly insides the intersection of vma and
>>> + * memslot. And hva and pa have the same alignment to this mapping size.
>>> + * It's rough because there are still other restrictions, which will be
>>> + * checked by the following fault_supports_stage2_huge_mapping().
>>
>> I don't think these restrictions make complete sense to me. If this is
>> a PFNMAP VMA, we should use the biggest mapping size that covers the
>> VMA, and not more than the VMA.
> But as described by kvm_arch_prepare_memory_region(), the memslot may not fully
> cover the VMA. If that's true and we just consider the boundary of the VMA, our
> block mapping may beyond the boundary of memslot. Is this a problem?
emm... Sorry I missed something. The fault_supports_stage2_huge_mapping() will check
the boundary of memslot, so we don't need to check it here. I have send v3, please
check that.

BRs,
Keqian


From baolu.lu at linux.intel.com  Wed Apr 14 08:00:42 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Wed, 14 Apr 2021 15:00:42 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <20210413085457.25400-2-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
Message-ID: <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>

Hi Keqian,

On 4/13/21 4:54 PM, Keqian Zhu wrote:
> Some types of IOMMU are capable of tracking DMA dirty log, such as
> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
> dirty log tracking framework in the IOMMU base layer.
> 
> Three new essential interfaces are added, and we maintaince the status
> of dirty log tracking in iommu_domain.
> 1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
> 2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
> 3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
> 
> A new dev feature are added to indicate whether a specific type of
> iommu hardware supports and its driver realizes them.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
> ---
>   drivers/iommu/iommu.c | 150 ++++++++++++++++++++++++++++++++++++++++++
>   include/linux/iommu.h |  53 +++++++++++++++
>   2 files changed, 203 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d0b0a15dba84..667b2d6d2fc0 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1922,6 +1922,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>   	domain->type = type;
>   	/* Assume all sizes by default; the driver may override this later */
>   	domain->pgsize_bitmap  = bus->iommu_ops->pgsize_bitmap;
> +	mutex_init(&domain->switch_log_lock);
>   
>   	return domain;
>   }
> @@ -2720,6 +2721,155 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>   }
>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>   
> +int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
> +			   unsigned long iova, size_t size, int prot)
> +{
> +	const struct iommu_ops *ops = domain->ops;
> +	int ret;
> +
> +	if (unlikely(!ops || !ops->switch_dirty_log))
> +		return -ENODEV;
> +
> +	mutex_lock(&domain->switch_log_lock);
> +	if (enable && domain->dirty_log_tracking) {
> +		ret = -EBUSY;
> +		goto out;
> +	} else if (!enable && !domain->dirty_log_tracking) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	ret = ops->switch_dirty_log(domain, enable, iova, size, prot);
> +	if (ret)
> +		goto out;
> +
> +	domain->dirty_log_tracking = enable;
> +out:
> +	mutex_unlock(&domain->switch_log_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_switch_dirty_log);

Since you also added IOMMU_DEV_FEAT_HWDBM, I am wondering what's the
difference between

iommu_switch_dirty_log(on) vs. 
iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)

iommu_switch_dirty_log(off) vs. 
iommu_dev_disable_feature(IOMMU_DEV_FEAT_HWDBM)

> +
> +int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
> +			 size_t size, unsigned long *bitmap,
> +			 unsigned long base_iova, unsigned long bitmap_pgshift)
> +{
> +	const struct iommu_ops *ops = domain->ops;
> +	unsigned int min_pagesz;
> +	size_t pgsize;
> +	int ret = 0;
> +
> +	if (unlikely(!ops || !ops->sync_dirty_log))
> +		return -ENODEV;
> +
> +	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
> +	if (!IS_ALIGNED(iova | size, min_pagesz)) {
> +		pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
> +		       iova, size, min_pagesz);
> +		return -EINVAL;
> +	}
> +
> +	mutex_lock(&domain->switch_log_lock);
> +	if (!domain->dirty_log_tracking) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	while (size) {
> +		pgsize = iommu_pgsize(domain, iova, size);
> +
> +		ret = ops->sync_dirty_log(domain, iova, pgsize,
> +					  bitmap, base_iova, bitmap_pgshift);

Any reason why do you want to do this in a per-4K page manner? This can
lead to a lot of indirect calls and bad performance.

How about a sync_dirty_pages()?

The same comment applies to other places in this patch series.

> +		if (ret)
> +			break;
> +
> +		pr_debug("dirty_log_sync handle: iova 0x%lx pagesz 0x%zx\n",
> +			 iova, pgsize);
> +
> +		iova += pgsize;
> +		size -= pgsize;
> +	}
> +out:
> +	mutex_unlock(&domain->switch_log_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sync_dirty_log);
> +
> +static int __iommu_clear_dirty_log(struct iommu_domain *domain,
> +				   unsigned long iova, size_t size,
> +				   unsigned long *bitmap,
> +				   unsigned long base_iova,
> +				   unsigned long bitmap_pgshift)
> +{
> +	const struct iommu_ops *ops = domain->ops;
> +	size_t pgsize;
> +	int ret = 0;
> +
> +	if (unlikely(!ops || !ops->clear_dirty_log))
> +		return -ENODEV;
> +
> +	while (size) {
> +		pgsize = iommu_pgsize(domain, iova, size);
> +
> +		ret = ops->clear_dirty_log(domain, iova, pgsize, bitmap,
> +					   base_iova, bitmap_pgshift);
> +		if (ret)
> +			break;
> +
> +		pr_debug("dirty_log_clear handled: iova 0x%lx pagesz 0x%zx\n",
> +			 iova, pgsize);
> +
> +		iova += pgsize;
> +		size -= pgsize;
> +	}
> +
> +	return ret;
> +}
> +
> +int iommu_clear_dirty_log(struct iommu_domain *domain,
> +			  unsigned long iova, size_t size,
> +			  unsigned long *bitmap, unsigned long base_iova,
> +			  unsigned long bitmap_pgshift)
> +{
> +	unsigned long riova, rsize;
> +	unsigned int min_pagesz;
> +	bool flush = false;
> +	int rs, re, start, end;
> +	int ret = 0;
> +
> +	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
> +	if (!IS_ALIGNED(iova | size, min_pagesz)) {
> +		pr_err("unaligned: iova 0x%lx min_pagesz 0x%x\n",
> +		       iova, min_pagesz);
> +		return -EINVAL;
> +	}
> +
> +	mutex_lock(&domain->switch_log_lock);
> +	if (!domain->dirty_log_tracking) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	start = (iova - base_iova) >> bitmap_pgshift;
> +	end = start + (size >> bitmap_pgshift);
> +	bitmap_for_each_set_region(bitmap, rs, re, start, end) {
> +		flush = true;
> +		riova = iova + (rs << bitmap_pgshift);
> +		rsize = (re - rs) << bitmap_pgshift;
> +		ret = __iommu_clear_dirty_log(domain, riova, rsize, bitmap,
> +					      base_iova, bitmap_pgshift);
> +		if (ret)
> +			break;
> +	}
> +
> +	if (flush)
> +		iommu_flush_iotlb_all(domain);
> +out:
> +	mutex_unlock(&domain->switch_log_lock);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_clear_dirty_log);
> +
>   void iommu_get_resv_regions(struct device *dev, struct list_head *list)
>   {
>   	const struct iommu_ops *ops = dev->bus->iommu_ops;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 5e7fe519430a..7f9ed9f520e2 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -87,6 +87,8 @@ struct iommu_domain {
>   	void *handler_token;
>   	struct iommu_domain_geometry geometry;
>   	void *iova_cookie;
> +	bool dirty_log_tracking;
> +	struct mutex switch_log_lock;
>   };
>   
>   enum iommu_cap {
> @@ -160,6 +162,7 @@ struct iommu_resv_region {
>   enum iommu_dev_features {
>   	IOMMU_DEV_FEAT_AUX,	/* Aux-domain feature */
>   	IOMMU_DEV_FEAT_SVA,	/* Shared Virtual Addresses */
> +	IOMMU_DEV_FEAT_HWDBM,	/* Hardware Dirty Bit Management */
>   };
>   
>   #define IOMMU_PASID_INVALID	(-1U)
> @@ -205,6 +208,9 @@ struct iommu_iotlb_gather {
>    * @device_group: find iommu group for a particular device
>    * @domain_get_attr: Query domain attributes
>    * @domain_set_attr: Change domain attributes
> + * @switch_dirty_log: Perform actions to start|stop dirty log tracking
> + * @sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
> + * @clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
>    * @get_resv_regions: Request list of reserved regions for a device
>    * @put_resv_regions: Free list of reserved regions for a device
>    * @apply_resv_region: Temporary helper call-back for iova reserved ranges
> @@ -260,6 +266,18 @@ struct iommu_ops {
>   	int (*domain_set_attr)(struct iommu_domain *domain,
>   			       enum iommu_attr attr, void *data);
>   
> +	/* Track dirty log */
> +	int (*switch_dirty_log)(struct iommu_domain *domain, bool enable,
> +				unsigned long iova, size_t size, int prot);
> +	int (*sync_dirty_log)(struct iommu_domain *domain,
> +			      unsigned long iova, size_t size,
> +			      unsigned long *bitmap, unsigned long base_iova,
> +			      unsigned long bitmap_pgshift);
> +	int (*clear_dirty_log)(struct iommu_domain *domain,
> +			       unsigned long iova, size_t size,
> +			       unsigned long *bitmap, unsigned long base_iova,
> +			       unsigned long bitmap_pgshift);
> +
>   	/* Request/Free a list of reserved regions for a device */
>   	void (*get_resv_regions)(struct device *dev, struct list_head *list);
>   	void (*put_resv_regions)(struct device *dev, struct list_head *list);
> @@ -511,6 +529,16 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
>   				 void *data);
>   extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
>   				 void *data);
> +extern int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
> +				  unsigned long iova, size_t size, int prot);
> +extern int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
> +				size_t size, unsigned long *bitmap,
> +				unsigned long base_iova,
> +				unsigned long bitmap_pgshift);
> +extern int iommu_clear_dirty_log(struct iommu_domain *domain, unsigned long iova,
> +				 size_t dma_size, unsigned long *bitmap,
> +				 unsigned long base_iova,
> +				 unsigned long bitmap_pgshift);
>   
>   /* Window handling function prototypes */
>   extern int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
> @@ -901,6 +929,31 @@ static inline int iommu_domain_set_attr(struct iommu_domain *domain,
>   	return -EINVAL;
>   }
>   
> +static inline int iommu_switch_dirty_log(struct iommu_domain *domain,
> +					 bool enable, unsigned long iova,
> +					 size_t size, int prot)
> +{
> +	return -EINVAL;
> +}
> +
> +static inline int iommu_sync_dirty_log(struct iommu_domain *domain,
> +				       unsigned long iova, size_t size,
> +				       unsigned long *bitmap,
> +				       unsigned long base_iova,
> +				       unsigned long pgshift)
> +{
> +	return -EINVAL;
> +}
> +
> +static inline int iommu_clear_dirty_log(struct iommu_domain *domain,
> +					unsigned long iova, size_t size,
> +					unsigned long *bitmap,
> +					unsigned long base_iova,
> +					unsigned long pgshift)
> +{
> +	return -EINVAL;
> +}
> +
>   static inline int  iommu_device_register(struct iommu_device *iommu)
>   {
>   	return -ENODEV;
> 

Best regards,
baolu


From linus.walleij at linaro.org  Wed Apr 14 08:12:57 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 14 Apr 2021 09:12:57 +0200
Subject: [PATCH v2 1/3] dt-bindings: gpio: add YAML description for
 rockchip, gpio-bank
In-Reply-To: <20210412223617.8634-1-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
Message-ID: <CACRpkdZ-oq4zKt_qOYTNCL7XqvJygRG0gfb9jRGVi2XRiE_3RQ@mail.gmail.com>

On Tue, Apr 13, 2021 at 12:36 AM Johan Jonker <jbx6244 at gmail.com> wrote:

> Current dts files with "rockchip,gpio-bank" subnodes
> are manually verified. In order to automate this process
> the text that describes the compatible in rockchip,pinctrl.txt
> is removed and converted to YAML in rockchip,gpio-bank.yaml.
>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Changed V2:
>   changed example gpio nodename

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From Yz.Wu at mediatek.com  Wed Apr 14 08:17:47 2021
From: Yz.Wu at mediatek.com (Yz.Wu at mediatek.com)
Date: Wed, 14 Apr 2021 15:17:47 +0800
Subject: [PATCH v5 0/2] Add Mediatek Efuse Device Node for MT8192 SoC
Message-ID: <1618384669-30070-1-git-send-email-Yz.Wu@mediatek.com>

From: Ryan Wu <Yz.Wu at mediatek.com>

This patch adds efuse to read via NVMEM.

Ryan Wu (2):
  dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC
  arm64: dts: mt8192: add eFuse support for MT8192 SoC

 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi              | 5 +++++
 2 files changed, 6 insertions(+)

-- 
2.6.4

From Yz.Wu at mediatek.com  Wed Apr 14 08:17:48 2021
From: Yz.Wu at mediatek.com (Yz.Wu at mediatek.com)
Date: Wed, 14 Apr 2021 15:17:48 +0800
Subject: [PATCH v5 1/2] dt-bindings: nvmem: mediatek: add support for MediaTek
 mt8192 SoC
In-Reply-To: <1618384669-30070-1-git-send-email-Yz.Wu@mediatek.com>
References: <1618384669-30070-1-git-send-email-Yz.Wu@mediatek.com>
Message-ID: <1618384669-30070-2-git-send-email-Yz.Wu@mediatek.com>

From: Ryan Wu <Yz.Wu at mediatek.com>

This updates dt-binding documentation for MediaTek mt8192

Signed-off-by: Ryan Wu <Yz.Wu at mediatek.com>
---
This patch is based on v5.12-rc2.
---
 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
index ef93c3b..dbd4da8 100644
--- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
+++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
@@ -7,6 +7,7 @@ Required properties:
 	      "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
 	      "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
 	      "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
+		  "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
 	      "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
 - reg: Should contain registers location and length
 
-- 
2.6.4

From Yz.Wu at mediatek.com  Wed Apr 14 08:17:49 2021
From: Yz.Wu at mediatek.com (Yz.Wu at mediatek.com)
Date: Wed, 14 Apr 2021 15:17:49 +0800
Subject: [PATCH v5 2/2] arm64: dts: mt8192: add eFuse support for MT8192 SoC
In-Reply-To: <1618384669-30070-1-git-send-email-Yz.Wu@mediatek.com>
References: <1618384669-30070-1-git-send-email-Yz.Wu@mediatek.com>
Message-ID: <1618384669-30070-3-git-send-email-Yz.Wu@mediatek.com>

From: Ryan Wu <Yz.Wu at mediatek.com>

Add eFuse node to read Mediatek eFuse

Signed-off-by: Ryan Wu <Yz.Wu at mediatek.com>
---
This patch dependents on "arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile"[1]

mt8192.dtsi file is needed for this patch.
Please also accept this patch together with [1].

[1]http://lists.infradead.org/pipermail/linux-mediatek/2020-November/019378.html
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 9757138..4d4e4de 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -436,6 +436,11 @@
 			status = "disable";
 		};
 
+		efuse: efuse at 11c10000 {
+				compatible = "mediatek,mt8192-efuse",
+							 "mediatek,efuse";
+		};
+
 		i2c3: i2c3 at 11cb0000 {
 			compatible = "mediatek,mt8192-i2c";
 			reg = <0 0x11cb0000 0 0x1000>,
-- 
2.6.4

From arnaud.pouliquen at foss.st.com  Wed Apr 14 08:23:56 2021
From: arnaud.pouliquen at foss.st.com (Arnaud POULIQUEN)
Date: Wed, 14 Apr 2021 09:23:56 +0200
Subject: [PATCH v4 2/2] remoteproc: stm32: add capability to detach
In-Reply-To: <YHYOd/vqeZCiqkpJ@builder.lan>
References: <20210331073347.8293-1-arnaud.pouliquen@foss.st.com>
 <20210331073347.8293-3-arnaud.pouliquen@foss.st.com>
 <YHYOd/vqeZCiqkpJ@builder.lan>
Message-ID: <3df5317b-d28a-9362-6876-99442fdb8ef5@foss.st.com>

Hello Bjorn

On 4/13/21 11:34 PM, Bjorn Andersson wrote:
> On Wed 31 Mar 02:33 CDT 2021, Arnaud Pouliquen wrote:
> 
>> A mechanism similar to the shutdown mailbox signal is implemented to
>> detach a remote processor.
>>
>> Upon detachment, a signal is sent to the remote firmware, allowing it
>> to perform specific actions such as stopping rpmsg communication.
>>
>> The Cortex-M hold boot is also disabled to allow the remote processor
>> to restart in case of crash.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen at foss.st.com>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>> Tested-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>> ---
>>  drivers/remoteproc/stm32_rproc.c | 39 ++++++++++++++++++++++++++++++--
>>  1 file changed, 37 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
>> index 3d45f51de4d0..7353f9e7e7af 100644
>> --- a/drivers/remoteproc/stm32_rproc.c
>> +++ b/drivers/remoteproc/stm32_rproc.c
>> @@ -28,7 +28,7 @@
>>  #define RELEASE_BOOT		1
>>  
>>  #define MBOX_NB_VQ		2
>> -#define MBOX_NB_MBX		3
>> +#define MBOX_NB_MBX		4
>>  
>>  #define STM32_SMC_RCC		0x82001000
>>  #define STM32_SMC_REG_WRITE	0x1
>> @@ -38,6 +38,7 @@
>>  #define STM32_MBX_VQ1		"vq1"
>>  #define STM32_MBX_VQ1_ID	1
>>  #define STM32_MBX_SHUTDOWN	"shutdown"
>> +#define STM32_MBX_DETACH	"detach"
>>  
>>  #define RSC_TBL_SIZE		1024
>>  
>> @@ -336,6 +337,15 @@ static const struct stm32_mbox stm32_rproc_mbox[MBOX_NB_MBX] = {
>>  			.tx_done = NULL,
>>  			.tx_tout = 500, /* 500 ms time out */
>>  		},
>> +	},
>> +	{
>> +		.name = STM32_MBX_DETACH,
>> +		.vq_id = -1,
>> +		.client = {
>> +			.tx_block = true,
>> +			.tx_done = NULL,
>> +			.tx_tout = 200, /* 200 ms time out to detach should be fair enough */
>> +		},
>>  	}
>>  };
>>  
>> @@ -461,6 +471,25 @@ static int stm32_rproc_attach(struct rproc *rproc)
>>  	return stm32_rproc_set_hold_boot(rproc, true);
>>  }
>>  
>> +static int stm32_rproc_detach(struct rproc *rproc)
>> +{
>> +	struct stm32_rproc *ddata = rproc->priv;
>> +	int err, dummy_data, idx;
>> +
>> +	/* Inform the remote processor of the detach */
>> +	idx = stm32_rproc_mbox_idx(rproc, STM32_MBX_DETACH);
>> +	if (idx >= 0 && ddata->mb[idx].chan) {
>> +		/* A dummy data is sent to allow to block on transmit */
>> +		err = mbox_send_message(ddata->mb[idx].chan,
>> +					&dummy_data);
> 
> Seems I posted my comment on v1, rather than this latest version. Please
> let me know if we should do anything about this dummy_data.

Thanks for pointing this out, you are right, the mailbox driver is stm32_ipcc
and it only sends a signal to the remote processor.

As message can be queued by the mailbox framework using a local variable seems
not a good option. As this code is a copy/past of the kick and stop?
I propose to get this one and I will send a new patch to fix the usage in the
whole driver.

Thanks,
Arnaud

> 
> Regards,
> Bjorn
> 
>> +		if (err < 0)
>> +			dev_warn(&rproc->dev, "warning: remote FW detach without ack\n");
>> +	}
>> +
>> +	/* Allow remote processor to auto-reboot */
>> +	return stm32_rproc_set_hold_boot(rproc, false);
>> +}
>> +
>>  static int stm32_rproc_stop(struct rproc *rproc)
>>  {
>>  	struct stm32_rproc *ddata = rproc->priv;
>> @@ -597,7 +626,12 @@ stm32_rproc_get_loaded_rsc_table(struct rproc *rproc, size_t *table_sz)
>>  	}
>>  
>>  done:
>> -	/* Assuming the resource table fits in 1kB is fair */
>> +	/*
>> +	 * Assuming the resource table fits in 1kB is fair.
>> +	 * Notice for the detach, that this 1 kB memory area has to be reserved in the coprocessor
>> +	 * firmware for the resource table. On detach, the remoteproc core re-initializes this
>> +	 * entire area by overwriting it with the initial values stored in rproc->clean_table.
>> +	 */
>>  	*table_sz = RSC_TBL_SIZE;
>>  	return (struct resource_table *)ddata->rsc_va;
>>  }
>> @@ -607,6 +641,7 @@ static const struct rproc_ops st_rproc_ops = {
>>  	.start		= stm32_rproc_start,
>>  	.stop		= stm32_rproc_stop,
>>  	.attach		= stm32_rproc_attach,
>> +	.detach		= stm32_rproc_detach,
>>  	.kick		= stm32_rproc_kick,
>>  	.load		= rproc_elf_load_segments,
>>  	.parse_fw	= stm32_rproc_parse_fw,
>> -- 
>> 2.17.1
>>


From baolu.lu at linux.intel.com  Wed Apr 14 08:14:32 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Wed, 14 Apr 2021 15:14:32 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <20210413085457.25400-3-zhukeqian1@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
Message-ID: <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>

On 4/13/21 4:54 PM, Keqian Zhu wrote:
> Block(largepage) mapping is not a proper granule for dirty log tracking.
> Take an extreme example, if DMA writes one byte, under 1G mapping, the
> dirty amount reported is 1G, but under 4K mapping, the dirty amount is
> just 4K.
> 
> This adds a new interface named iommu_split_block in IOMMU base layer.
> A specific IOMMU driver can invoke it during start dirty log. If so, the
> driver also need to realize the split_block iommu ops.
> 
> We flush all iotlbs after the whole procedure is completed to ease the
> pressure of IOMMU, as we will hanle a huge range of mapping in general.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
> ---
>   drivers/iommu/iommu.c | 41 +++++++++++++++++++++++++++++++++++++++++
>   include/linux/iommu.h | 11 +++++++++++
>   2 files changed, 52 insertions(+)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 667b2d6d2fc0..bb413a927870 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2721,6 +2721,47 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>   }
>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>   
> +int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
> +		      size_t size)
> +{
> +	const struct iommu_ops *ops = domain->ops;
> +	unsigned int min_pagesz;
> +	size_t pgsize;
> +	bool flush = false;
> +	int ret = 0;
> +
> +	if (unlikely(!ops || !ops->split_block))
> +		return -ENODEV;
> +
> +	min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
> +	if (!IS_ALIGNED(iova | size, min_pagesz)) {
> +		pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
> +		       iova, size, min_pagesz);
> +		return -EINVAL;
> +	}
> +
> +	while (size) {
> +		flush = true;
> +
> +		pgsize = iommu_pgsize(domain, iova, size);
> +
> +		ret = ops->split_block(domain, iova, pgsize);
> +		if (ret)
> +			break;
> +
> +		pr_debug("split handled: iova 0x%lx size 0x%zx\n", iova, pgsize);
> +
> +		iova += pgsize;
> +		size -= pgsize;
> +	}
> +
> +	if (flush)
> +		iommu_flush_iotlb_all(domain);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_split_block);

Do you really have any consumers of this interface other than the dirty
bit tracking? If not, I don't suggest to make this as a generic IOMMU
interface.

There is an implicit requirement for such interfaces. The
iommu_map/unmap(iova, size) shouldn't be called at the same time.
Currently there's no such sanity check in the iommu core. A poorly
written driver could mess up the kernel by misusing this interface.

This also applies to iommu_merge_page().

Best regards,
baolu


From wangqing at vivo.com  Wed Apr 14 08:28:58 2021
From: wangqing at vivo.com (Wang Qing)
Date: Wed, 14 Apr 2021 15:28:58 +0800
Subject: [PATCH V2] watchdog: mtk: support pre-timeout when the bark irq is
 available
Message-ID: <1618385339-3527-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

By default, the pretimeout notification shall occur one second earlier
than the timeout.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 57 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..b0ec933
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -234,18 +235,41 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
 	int ret;
 
-	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
 	if (ret < 0)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	reg &= ~WDT_MODE_IRQ_EN;
+	if (wdt_dev->pretimeout)
+		reg |= WDT_MODE_IRQ_EN;
+	else
+		reg &= ~WDT_MODE_IRQ_EN;
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+				   unsigned int timeout)
+{
+	wdd->pretimeout = timeout;
+	return mtk_wdt_start(wdd);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+if (IS_ENABLED(CONFIG_WATCHDOG_PRETIMEOUT_GOV))
+	watchdog_notify_pretimeout(wdd);
+else
+	//panic by decault instead of WDT_SWRST;
+	panic("MTk Watchdog bark!\n");
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +277,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +300,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +312,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+								&mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = 1;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
@@ -360,7 +408,6 @@ static struct platform_driver mtk_wdt_driver = {
 };
 
 module_platform_driver(mtk_wdt_driver);
-
 module_param(timeout, uint, 0);
 MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
 
-- 
2.7.4



From ikjn at chromium.org  Wed Apr 14 08:31:08 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Wed, 14 Apr 2021 15:31:08 +0800
Subject: [PATCH v2] arm64: dts: mt8183: Add power-domains properity to mfgcfg
Message-ID: <20210414073108.3899082-1-ikjn@chromium.org>

mfgcfg clock is under MFG_ASYNC power domain

Signed-off-by: Weiyi Lu <weiyi.lu at mediatek.com>
Signed-off-by: Ikjoon Jang <ikjn at chromium.org>
---

Changes in v2:
Fix a wrong power domain reference (scpsys to spm).

Link(v1): https://patchwork.kernel.org/project/linux-mediatek/patch/20210224091742.1060508-1-ikjn at chromium.org/#23997681

---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 0ff7b67a6806..64813634c3df 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1116,6 +1116,7 @@ mfgcfg: syscon at 13000000 {
 			compatible = "mediatek,mt8183-mfgcfg", "syscon";
 			reg = <0 0x13000000 0 0x1000>;
 			#clock-cells = <1>;
+			power-domains = <&spm MT8183_POWER_DOMAIN_MFG_ASYNC>;
 		};
 
 		mmsys: syscon at 14000000 {
-- 
2.31.1.295.g9ea45b61b8-goog



From aherrmann at suse.com  Wed Apr 14 08:47:01 2021
From: aherrmann at suse.com (Andreas Herrmann)
Date: Wed, 14 Apr 2021 09:47:01 +0200
Subject: [PATCH v14 6/6] locking/qspinlock: Introduce the shuffle
 reduction optimization into CNA
In-Reply-To: <20210401153156.1165900-7-alex.kogan@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-7-alex.kogan@oracle.com>
Message-ID: <YHad9S5ckj5IR1l6@suselix>

On Thu, Apr 01, 2021 at 11:31:56AM -0400, Alex Kogan wrote:
> This performance optimization chooses probabilistically to avoid moving
> threads from the main queue into the secondary one when the secondary queue
> is empty.
> 
> It is helpful when the lock is only lightly contended. In particular, it
> makes CNA less eager to create a secondary queue, but does not introduce
> any extra delays for threads waiting in that queue once it is created.
> 
> Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
> Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
> Reviewed-by: Waiman Long <longman at redhat.com>
> ---
>  kernel/locking/qspinlock_cna.h | 39 ++++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
> index 29c3abbd3d94..983c6a47a221 100644
> --- a/kernel/locking/qspinlock_cna.h
> +++ b/kernel/locking/qspinlock_cna.h
> @@ -5,6 +5,7 @@
>  
>  #include <linux/topology.h>
>  #include <linux/sched/rt.h>
> +#include <linux/random.h>
>  
>  /*
>   * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
> @@ -86,6 +87,34 @@ static inline bool intra_node_threshold_reached(struct cna_node *cn)
>  	return current_time - threshold > 0;
>  }
>  
> +/*
> + * Controls the probability for enabling the ordering of the main queue
> + * when the secondary queue is empty. The chosen value reduces the amount
> + * of unnecessary shuffling of threads between the two waiting queues
> + * when the contention is low, while responding fast enough and enabling
> + * the shuffling when the contention is high.
> + */
> +#define SHUFFLE_REDUCTION_PROB_ARG  (7)

Out of curiosity:

Have you used other values and done measurements what's an efficient
value for SHUFFLE_REDUCTION_PROB_ARG?
Maybe I miscalculated it, but if I understand it correctly this value
implies that the propability is 0.9921875 that below function returns
true.

My question is probably answered by following statement from
referenced paper:

"In our experiments with the shuffle reduction optimization enabled,
we set THRESHOLD2 to 0xff." (page with figure 5)

> +
> +/* Per-CPU pseudo-random number seed */
> +static DEFINE_PER_CPU(u32, seed);
> +
> +/*
> + * Return false with probability 1 / 2^@num_bits.
> + * Intuitively, the larger @num_bits the less likely false is to be returned.
> + * @num_bits must be a number between 0 and 31.
> + */
> +static bool probably(unsigned int num_bits)
> +{
> +	u32 s;
> +
> +	s = this_cpu_read(seed);
> +	s = next_pseudo_random32(s);
> +	this_cpu_write(seed, s);
> +
> +	return s & ((1 << num_bits) - 1);
> +}
> +
>  static void __init cna_init_nodes_per_cpu(unsigned int cpu)
>  {
>  	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);
> @@ -293,6 +322,16 @@ static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
>  {
>  	struct cna_node *cn = (struct cna_node *)node;
>  
> +	if (node->locked <= 1 && probably(SHUFFLE_REDUCTION_PROB_ARG)) {

Again if I understand it correctly with SHUFFLE_REDUCTION_PROB_ARG==7
it's roughly 1 out of 100 cases where probably() returns false.

Why/when is this beneficial?

I assume it has to do with following statement in the referenced
paper:

"The superior performance over MCS at 4 threads is the result of the
shuffling that does take place once in a while, organizing threads?
arrivals to the lock in a way that reduces the inter-socket lock
migration without the need to continuously modify the main queue. ..."
(page with figure 9; the paper has no page numbers)

But OTHO why this pseudo randomness?

How about deterministically treating every 100th execution differently
(it also matches "once in a while") and thus entirely removing the
pseudo randomness?

Have you tried this? If so why was it worse than pseudo randomness?

(Or maybe I missed something and pseudo randomness is required for
other reasons there.)

> +		/*
> +		 * When the secondary queue is empty, skip the call to
> +		 * cna_order_queue() below with high probability. This optimization
> +		 * reduces the overhead of unnecessary shuffling of threads
> +		 * between waiting queues when the lock is only lightly contended.
> +		 */
> +		return 0;
> +	}
> +
>  	if (!cn->start_time || !intra_node_threshold_reached(cn)) {
>  		/*
>  		 * We are at the head of the wait queue, no need to use
> -- 
> 2.24.3 (Apple Git-128)
> 

-- 
Regards,
Andreas



From wsa at kernel.org  Wed Apr 14 08:51:27 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Wed, 14 Apr 2021 09:51:27 +0200
Subject: [PATCH 0/8] i2c: fix reference leak when pm_runtime_get_sync fails
In-Reply-To: <20201201092924.112461-1-miaoqinglang@huawei.com>
References: <20201201092924.112461-1-miaoqinglang@huawei.com>
Message-ID: <20210414075127.GA2180@ninjato>

On Tue, Dec 01, 2020 at 05:29:24PM +0800, Qinglang Miao wrote:
> pm_runtime_get_sync will increment the PM reference count
> even failed. Forgetting to putting operation will result
> in a reference leak here. 
> 
> Replace it with pm_runtime_resume_and_get to keep usage
> counter balanced. 
> 
> BTW, pm_runtime_resume_and_get is introduced in v5.10-rc5 as
> dd8088d5a896 ("PM: runtime: Add  pm_runtime_resume_and_get
> to dealwith usage counter")
> 
> Qinglang Miao (8):
>   i2c: cadence: fix reference leak when pm_runtime_get_sync fails
>   i2c: img-scb: fix reference leak when pm_runtime_get_sync fails
>   i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails
>   i2c: imx: fix reference leak when pm_runtime_get_sync fails
>   i2c: omap: fix reference leak when pm_runtime_get_sync fails
>   i2c: sprd: fix reference leak when pm_runtime_get_sync fails
>   i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails
>   i2c: xiic: fix reference leak when pm_runtime_get_sync fails

I applied this series now 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/20210414/12e0d71b/attachment.sig>

From wsa at kernel.org  Wed Apr 14 08:56:49 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Wed, 14 Apr 2021 09:56:49 +0200
Subject: [PATCH -next] i2c: imx-lpi2c: fix PM reference leak in
 lpi2c_imx_master_enable()
In-Reply-To: <20210408111930.203574-1-yeweihua4@huawei.com>
References: <20210408111930.203574-1-yeweihua4@huawei.com>
Message-ID: <20210414075649.GC2180@ninjato>

On Thu, Apr 08, 2021 at 07:19:30PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> ipi2c_imx_master_enable().
> 
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will result in
> a leak.
> 
> Replace it with pm_runtime_resume_and_get() to keep the usage counter
> balanced.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>

Thanks, yet I applied this series now:

http://patchwork.ozlabs.org/project/linux-i2c/list/?series=217733&state=*

-------------- 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/20210414/5d9696c0/attachment.sig>

From wsa at kernel.org  Wed Apr 14 08:57:30 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Wed, 14 Apr 2021 09:57:30 +0200
Subject: [PATCH -next] i2c: cadence: Fix PM reference leak in
 cdns_i2c_master_xfer()
In-Reply-To: <20210408112352.211173-1-pulehui@huawei.com>
References: <20210408112352.211173-1-pulehui@huawei.com>
Message-ID: <20210414075730.GD2180@ninjato>

On Thu, Apr 08, 2021 at 07:23:52PM +0800, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
> 
> Signed-off-by: Pu Lehui <pulehui at huawei.com>

Thanks, yet I applied this series now:

http://patchwork.ozlabs.org/project/linux-i2c/list/?series=217733&state=*

-------------- 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/20210414/541c792f/attachment.sig>

From wsa at kernel.org  Wed Apr 14 09:04:12 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Wed, 14 Apr 2021 10:04:12 +0200
Subject: [PATCH -next] i2c: imx: Fix PM reference leak in
 i2c_imx_reg_slave()
In-Reply-To: <20210408110638.200761-1-yeweihua4@huawei.com>
References: <20210408110638.200761-1-yeweihua4@huawei.com>
Message-ID: <20210414080412.GI2180@ninjato>

On Thu, Apr 08, 2021 at 07:06:38PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> these functions.
> 
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will result in
> a leak.
> 
> Replace it with pm_runtime_resume_and_get() to keep the usage counter
> balanced.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Ye Weihua <yeweihua4 at huawei.com>

After rebasing, only one hunk was left:

> @@ -801,7 +801,7 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
>  	i2c_imx->last_slave_event = I2C_SLAVE_STOP;
>  
>  	/* Resume */
> -	ret = pm_runtime_get_sync(i2c_imx->adapter.dev.parent);
> +	ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
>  	if (ret < 0) {
>  		dev_err(&i2c_imx->adapter.dev, "failed to resume i2c controller");
>  		return ret;

I applied this 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/20210414/d30268a0/attachment.sig>

From brouer at redhat.com  Wed Apr 14 09:10:44 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Wed, 14 Apr 2021 10:10:44 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210412011532.GG2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
Message-ID: <20210414101044.19da09df@carbon>

On Mon, 12 Apr 2021 02:15:32 +0100
Matthew Wilcox <willy at infradead.org> wrote:

> On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> > Basically, we have three aligned dwords here.  We can either alias with
> > @flags and the first word of @lru, or the second word of @lru and @mapping,
> > or @index and @private.  @flags is a non-starter.  If we use @mapping,
> > then you have to set it to NULL before you free it, and I'm not sure
> > how easy that will be for you.  If that's trivial, then we could use
> > the layout:
> > 
> > 	unsigned long _pp_flags;
> > 	unsigned long pp_magic;
> > 	union {
> > 		dma_addr_t dma_addr;    /* might be one or two words */
> > 		unsigned long _pp_align[2];
> > 	};
> > 	unsigned long pp_pfmemalloc;
> > 	unsigned long xmi;  
> 
> I forgot about the munmap path.  That calls zap_page_range() which calls
> set_page_dirty() which calls page_mapping().  If we use page->mapping,
> that's going to get interpreted as an address_space pointer.
> 
> *sigh*.  Foiled at every turn.

Yes, indeed! - And very frustrating.  It's keeping me up at night.
I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
me that I don't sleep well with these kind of dreams ;-)

> I'm kind of inclined towards using two (or more) bits for PageSlab as
> we discussed here:
> 
> https://lore.kernel.org/linux-mm/01000163efe179fe-d6270c58-eaba-482f-a6bd-334667250ef7-000000 at email.amazonses.com/
> 
> so we have PageKAlloc that's true for PageSlab, PagePool, PageDMAPool,
> PageVMalloc, PageFrag and maybe a few other kernel-internal allocations.

I actually like this idea a lot.  I also think it will solve or remove
Matteo/Ilias'es[2] need to introduce the pp_magic signature.  Ilias do
say[1] that page_pool pages could be used for TCP RX zerocopy, but I
don't think we should "allow" that (meaning page_pool should drop the
DMA-mapping and give up recycling).  I should argue why in that thread.

That said, I think we need to have a quicker fix for the immediate
issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
it leaves[3] in struct page.  In[3] you mention ppc32, does it only
happens on certain 32-bit archs?

I'm seriously considering removing page_pool's support for doing/keeping
DMA-mappings on 32-bit arch's.  AFAIK only a single driver use this.

> (see also here:)
> https://lore.kernel.org/linux-mm/20180518194519.3820-18-willy at infradead.org/

[1] https://lore.kernel.org/netdev/YHHuE7g73mZNrMV4 at enceladus/
[2] https://patchwork.kernel.org/project/netdevbpf/patch/20210409223801.104657-3-mcroce at linux.microsoft.com/
[3] https://lore.kernel.org/linux-mm/20210410024313.GX2531743 at casper.infradead.org/
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer



From hayashi.kunihiko at socionext.com  Wed Apr 14 09:21:52 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Wed, 14 Apr 2021 17:21:52 +0900
Subject: [PATCH v10 1/3] PCI: portdrv: Add pcie_port_service_get_irq()
 function
In-Reply-To: <20210412094219.000031ca@Huawei.com>
References: <1617985338-19648-1-git-send-email-hayashi.kunihiko@socionext.com>
 <1617985338-19648-2-git-send-email-hayashi.kunihiko@socionext.com>
 <20210412094219.000031ca@Huawei.com>
Message-ID: <1001a75f-76fb-5a99-7af2-602aef31b01b@socionext.com>

Hi Jonathan,

On 2021/04/12 17:42, Jonathan Cameron wrote:
> On Sat, 10 Apr 2021 01:22:16 +0900
> Kunihiko Hayashi <hayashi.kunihiko at socionext.com> wrote:
> 
>> Add pcie_port_service_get_irq() that returns the virtual IRQ number
>> for specified portdrv service.
> 
> Trivial comment inline.
> 
>>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
>> Reviewed-by: Rob Herring <robh at kernel.org>
>> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
>> ---
>>   drivers/pci/pcie/portdrv.h      |  1 +
>>   drivers/pci/pcie/portdrv_core.c | 16 ++++++++++++++++
>>   2 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
>> index 2ff5724..628a3de 100644
>> --- a/drivers/pci/pcie/portdrv.h
>> +++ b/drivers/pci/pcie/portdrv.h
>> @@ -144,4 +144,5 @@ static inline void pcie_pme_interrupt_enable(struct pci_dev *dev, bool en) {}
>>   #endif /* !CONFIG_PCIE_PME */
>>   
>>   struct device *pcie_port_find_device(struct pci_dev *dev, u32 service);
>> +int pcie_port_service_get_irq(struct pci_dev *dev, u32 service);
>>   #endif /* _PORTDRV_H_ */
>> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
>> index e1fed664..b60f0f3 100644
>> --- a/drivers/pci/pcie/portdrv_core.c
>> +++ b/drivers/pci/pcie/portdrv_core.c
>> @@ -477,7 +477,22 @@ struct device *pcie_port_find_device(struct pci_dev *dev,
>>   }
>>   EXPORT_SYMBOL_GPL(pcie_port_find_device);
>>   
>> +/*
> 
> /**
> 
> this is kernel-doc style, so why not mark it as such?

Thank you for pointing out.
I'll apply the style to this comment.

Thank you,

---
Best Regards
Kunihiko Hayashi


From wsa+renesas at sang-engineering.com  Wed Apr 14 09:22:46 2021
From: wsa+renesas at sang-engineering.com (Wolfram Sang)
Date: Wed, 14 Apr 2021 10:22:46 +0200
Subject: [PATCH v2 0/6] Stop calling devm_request_irq() with invalid IRQs
 in the I2C bus drivers
In-Reply-To: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
References: <7995bba1-61dd-baa3-51ea-0fb2fccc19a0@omprussia.ru>
Message-ID: <20210414082246.GK2180@ninjato>

On Sat, Apr 10, 2021 at 11:11:59PM +0300, Sergey Shtylyov wrote:
> Here are 6 patches against the 'master' branch of Martin Petersen's 'scsi.git' repo.
> The affected drivers call platform_get_irq() but largely ignore its result -- they
> blithely pass the negative error codes to devm_request_irq() which expects *unsinged*
> IRQ #s. Stop doing that by checking what exactly platform_get_irq() returns.
> 
> [1/6] i2c: cadence: add IRQ check
> [2/6] i2c: emev2: add IRQ check
> [3/6] i2c: jz4780: add IRQ check
> [4/6] i2c: mlxbf: add IRQ check
> [5/6] i2c: rcar: add IRQ check
> [6/6] i2c: sh7760: add IRQ check

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/20210414/a527889b/attachment.sig>

From maz at kernel.org  Wed Apr 14 09:27:51 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 09:27:51 +0100
Subject: [GIT PULL] coresight: Fixes for ETE and TRBE
In-Reply-To: <CANLsYkyyqSAe=9O2MyeX0z0sS501uD2+7NuDVv5V9LeAbbMDoQ@mail.gmail.com>
References: <20210413161952.750262-1-mathieu.poirier@linaro.org>
 <87sg3um8j1.wl-maz@kernel.org>
 <CANLsYkyyqSAe=9O2MyeX0z0sS501uD2+7NuDVv5V9LeAbbMDoQ@mail.gmail.com>
Message-ID: <87r1jdmfso.wl-maz@kernel.org>

On Tue, 13 Apr 2021 20:45:00 +0100,
Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> 
> On Tue, 13 Apr 2021 at 10:52, Marc Zyngier <maz at kernel.org> wrote:
> >
> > Hi Mathieu,
> >
> > On Tue, 13 Apr 2021 17:19:52 +0100,
> > Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> > >
> > > The following changes since commit 4fb13790417a7bf726f3867a5d2b9723efde488b:
> > >
> > >   dts: bindings: Document device tree bindings for Arm TRBE (2021-04-06 16:05:38 -0600)
> > >
> > > are available in the Git repository at:
> > >
> > >   git at gitolite.kernel.org:pub/scm/linux/kernel/git/coresight/linux.git next-ETE-TRBE
> > >
> > > for you to fetch changes up to 68d400c079978f649e7f63aba966d219743edd64:
> > >
> > >   coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu() (2021-04-13 09:46:27 -0600)
> > >
> > > ----------------------------------------------------------------
> > > Hi Marc,
> > >
> > > Please consider these two patches, they are ETE/TRBE fixes found by bots.
> > >
> > > Let me know if you want me to rebase on your next branch and send the
> > > pull request from that.
> >
> > I've now pulled this into kvmarm/next. If you have additional fixes,
> > just stick them on top of your next-ETE-TRBE branch like you did with
> > these two patches.
> >
> 
> Much appreciated - I owe you a beer.

One day, my friend. One day...

	M.

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


From hsinyi at chromium.org  Wed Apr 14 09:38:04 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:04 +0800
Subject: [PATCH v18 0/5] add power control in i2c
Message-ID: <20210414083809.1932133-1-hsinyi@chromium.org>

Although in the most platforms, the power of eeprom
and i2c are alway on, some platforms disable the
eeprom and i2c power in order to meet low power request.

This patch add the pm_runtime ops to control power to
support all platforms.

Changes since v17:
 - Add a patch to fix unbalanced regulator disabling.
 - Add dts patch.

Changes since v16:
 - request regulator in device instead of in the core.
 - control regulator only if it's provided.

Changes since v15:
 - Squash the fix[1] for v15.
[1] https://patchwork.ozlabs.org/project/linux-i2c/patch/20200522101327.13456-1-m.szyprowski at samsung.com/

Changes since v14:
 - change the return value in normal condition
 - access the variable after NULL pointer checking
 - add ack tag

Changes since v13:
 - fixup some logic error

Changes since v12:
 - rebase onto v5.7-rc1
 - change the property description in binding

Changes since v11:
 - use suspend_late/resume_early instead of suspend/resume
 - rebase onto v5.6-rc1

Changes since v10:
 - fixup some worng codes

Changes since v9:
 - fixup build error
 - remove redundant code

Changes since v8:
 - fixup some wrong code
 - remove redundant message

        [... snip ...]

Bibby Hsieh (1):
  i2c: core: support bus regulator controlling in adapter

Hsin-Yi Wang (4):
  dt-binding: i2c: mt65xx: add vbus-supply property
  i2c: mediatek: mt65xx: add optional vbus-supply
  misc: eeprom: at24: check suspend status before disable regulator
  arm64: dts: mt8183: add supply name for eeprom

 .../devicetree/bindings/i2c/i2c-mt65xx.txt    |  1 +
 .../dts/mediatek/mt8183-kukui-kakadu.dtsi     |  4 +
 .../dts/mediatek/mt8183-kukui-kodama.dtsi     |  4 +
 .../boot/dts/mediatek/mt8183-kukui-krane.dtsi |  4 +
 drivers/i2c/busses/i2c-mt65xx.c               |  7 ++
 drivers/i2c/i2c-core-base.c                   | 88 +++++++++++++++++++
 drivers/misc/eeprom/at24.c                    |  6 +-
 include/linux/i2c.h                           |  2 +
 8 files changed, 114 insertions(+), 2 deletions(-)

-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 09:38:05 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:05 +0800
Subject: [PATCH v18 1/5] i2c: core: support bus regulator controlling in
 adapter
In-Reply-To: <20210414083809.1932133-1-hsinyi@chromium.org>
References: <20210414083809.1932133-1-hsinyi@chromium.org>
Message-ID: <20210414083809.1932133-2-hsinyi@chromium.org>

From: Bibby Hsieh <bibby.hsieh at mediatek.com>

Although in the most platforms, the bus power of i2c
are alway on, some platforms disable the i2c bus power
in order to meet low power request.

We can control bulk regulator if it is provided in i2c
adapter device.

Signed-off-by: Bibby Hsieh <bibby.hsieh at mediatek.com>
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/i2c-core-base.c | 88 +++++++++++++++++++++++++++++++++++++
 include/linux/i2c.h         |  2 +
 2 files changed, 90 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 24c8f11bac73..c34920f30c5a 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -461,12 +461,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
 static int i2c_device_probe(struct device *dev)
 {
 	struct i2c_client	*client = i2c_verify_client(dev);
+	struct i2c_adapter	*adap;
 	struct i2c_driver	*driver;
 	int status;
 
 	if (!client)
 		return 0;
 
+	adap = client->adapter;
 	client->irq = client->init_irq;
 
 	if (!client->irq) {
@@ -532,6 +534,14 @@ static int i2c_device_probe(struct device *dev)
 
 	dev_dbg(dev, "probe\n");
 
+	if (adap->bus_regulator) {
+		status = regulator_enable(adap->bus_regulator);
+		if (status < 0) {
+			dev_err(&adap->dev, "Failed to enable bus regulator\n");
+			goto err_clear_wakeup_irq;
+		}
+	}
+
 	status = of_clk_set_defaults(dev->of_node, false);
 	if (status < 0)
 		goto err_clear_wakeup_irq;
@@ -589,8 +599,10 @@ static int i2c_device_probe(struct device *dev)
 static int i2c_device_remove(struct device *dev)
 {
 	struct i2c_client	*client = to_i2c_client(dev);
+	struct i2c_adapter      *adap;
 	struct i2c_driver	*driver;
 
+	adap = client->adapter;
 	driver = to_i2c_driver(dev->driver);
 	if (driver->remove) {
 		int status;
@@ -605,6 +617,8 @@ static int i2c_device_remove(struct device *dev)
 	devres_release_group(&client->dev, client->devres_group_id);
 
 	dev_pm_domain_detach(&client->dev, true);
+	if (!pm_runtime_status_suspended(&client->dev) && adap->bus_regulator)
+		regulator_disable(adap->bus_regulator);
 
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
@@ -617,6 +631,79 @@ static int i2c_device_remove(struct device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int i2c_resume_early(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	if (!pm_runtime_status_suspended(&client->dev)) {
+		err = regulator_enable(client->adapter->bus_regulator);
+		if (err)
+			return err;
+	}
+
+	return pm_generic_resume_early(&client->dev);
+}
+
+static int i2c_suspend_late(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_suspend_late(&client->dev);
+	if (err)
+		return err;
+
+	if (!pm_runtime_status_suspended(&client->dev))
+		return regulator_disable(client->adapter->bus_regulator);
+
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_PM
+static int i2c_runtime_resume(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = regulator_enable(client->adapter->bus_regulator);
+	if (err)
+		return err;
+	return pm_generic_runtime_resume(&client->dev);
+}
+
+static int i2c_runtime_suspend(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_runtime_suspend(&client->dev);
+	if (err)
+		return err;
+
+	return regulator_disable(client->adapter->bus_regulator);
+}
+#endif
+
+static const struct dev_pm_ops i2c_device_pm = {
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
+	SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
+};
+
 static void i2c_device_shutdown(struct device *dev)
 {
 	struct i2c_client *client = i2c_verify_client(dev);
@@ -674,6 +761,7 @@ struct bus_type i2c_bus_type = {
 	.probe		= i2c_device_probe,
 	.remove		= i2c_device_remove,
 	.shutdown	= i2c_device_shutdown,
+	.pm		= &i2c_device_pm,
 };
 EXPORT_SYMBOL_GPL(i2c_bus_type);
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e8f2ac8c9c3d..953a4eecb88f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -15,6 +15,7 @@
 #include <linux/device.h>	/* for struct device */
 #include <linux/sched.h>	/* for completion */
 #include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
 #include <linux/rtmutex.h>
 #include <linux/irqdomain.h>		/* for Host Notify IRQ */
 #include <linux/of.h>		/* for struct device_node */
@@ -729,6 +730,7 @@ struct i2c_adapter {
 	const struct i2c_adapter_quirks *quirks;
 
 	struct irq_domain *host_notify_domain;
+	struct regulator *bus_regulator;
 };
 #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 09:38:06 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:06 +0800
Subject: [PATCH v18 2/5] dt-binding: i2c: mt65xx: add vbus-supply property
In-Reply-To: <20210414083809.1932133-1-hsinyi@chromium.org>
References: <20210414083809.1932133-1-hsinyi@chromium.org>
Message-ID: <20210414083809.1932133-3-hsinyi@chromium.org>

Add vbus-supply property for mt65xx. The regulator can be passed into
core and turned off during suspend/sleep to reduce power consumption.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
index 7f0194fdd0cc..2c45647e9f0b 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
@@ -32,6 +32,7 @@ Optional properties:
   - mediatek,have-pmic: platform can control i2c form special pmic side.
     Only mt6589 and mt8135 support this feature.
   - mediatek,use-push-pull: IO config use push-pull mode.
+  - vbus-supply: phandle to the regulator that provides power to SCL/SDA.
 
 Example:
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 09:38:07 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:07 +0800
Subject: [PATCH v18 3/5] i2c: mediatek: mt65xx: add optional vbus-supply
In-Reply-To: <20210414083809.1932133-1-hsinyi@chromium.org>
References: <20210414083809.1932133-1-hsinyi@chromium.org>
Message-ID: <20210414083809.1932133-4-hsinyi@chromium.org>

Add vbus-supply which provides power to SCL/SDA. Pass this regulator
into core so it can be turned on/off for low power mode support.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/busses/i2c-mt65xx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ffd2f354d0a..82f2b6716005 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1215,6 +1215,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 	i2c->adap.quirks = i2c->dev_comp->quirks;
 	i2c->adap.timeout = 2 * HZ;
 	i2c->adap.retries = 1;
+	i2c->adap.bus_regulator = devm_regulator_get_optional(&pdev->dev, "vbus");
+	if (IS_ERR(i2c->adap.bus_regulator)) {
+		if (PTR_ERR(i2c->adap.bus_regulator) == -ENODEV)
+			i2c->adap.bus_regulator = NULL;
+		else
+			return PTR_ERR(i2c->adap.bus_regulator);
+	}
 
 	ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
 	if (ret)
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 09:38:08 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:08 +0800
Subject: [PATCH v18 4/5] misc: eeprom: at24: check suspend status before
 disable regulator
In-Reply-To: <20210414083809.1932133-1-hsinyi@chromium.org>
References: <20210414083809.1932133-1-hsinyi@chromium.org>
Message-ID: <20210414083809.1932133-5-hsinyi@chromium.org>

cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
regulator in runtime suspend. If runtime suspend is called before
regulator disable, it will results in regulator unbalanced disabling.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/misc/eeprom/at24.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 926408b41270..7a6f01ace78a 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client *client)
 	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
 	if (IS_ERR(at24->nvmem)) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return PTR_ERR(at24->nvmem);
 	}
 
@@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client *client)
 	err = at24_read(at24, 0, &test_byte, 1);
 	if (err) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return -ENODEV;
 	}
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 09:38:09 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 14 Apr 2021 16:38:09 +0800
Subject: [PATCH v18 5/5] arm64: dts: mt8183: add supply name for eeprom
In-Reply-To: <20210414083809.1932133-1-hsinyi@chromium.org>
References: <20210414083809.1932133-1-hsinyi@chromium.org>
Message-ID: <20210414083809.1932133-6-hsinyi@chromium.org>

Add supplies for eeprom for mt8183 boards.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi  | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
index b442e38a3156..28966a65391b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
@@ -88,11 +88,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -101,11 +103,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
index 2f5234a16ead..3aa79403c0c2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
@@ -62,11 +62,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c64";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcamio_reg>;
 	};
 };
 
@@ -75,11 +77,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c64";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
index fbc471ccf805..30c183c96a54 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
@@ -71,11 +71,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -84,11 +86,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
-- 
2.31.1.295.g9ea45b61b8-goog



From sahil.malhotra at oss.nxp.com  Wed Apr 14 09:51:05 2021
From: sahil.malhotra at oss.nxp.com (Sahil Malhotra (OSS))
Date: Wed, 14 Apr 2021 08:51:05 +0000
Subject: [PATCH] arm64: dts: ls1028a-rdb: enable optee node
In-Reply-To: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
References: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
Message-ID: <DB7PR04MB53224FF04ABFBD166124664E824E9@DB7PR04MB5322.eurprd04.prod.outlook.com>

Hi Shawn, Michael,

Just a friendly reminder to have a look at this patch.

Regards,
Sahil Malhotra

-----Original Message-----
From: Sahil Malhotra <sahil.malhotra at oss.nxp.com> 
Sent: Tuesday, March 30, 2021 8:20 PM
To: shawnguo at kernel.org
Cc: Sahil Malhotra (OSS) <sahil.malhotra at oss.nxp.com>; Sahil Malhotra <sahil.malhotra at nxp.com>; Michael Walle <michael at walle.cc>; Leo Li <leoyang.li at nxp.com>; Rob Herring <robh+dt at kernel.org>; moderated list:ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE <linux-arm-kernel at lists.infradead.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree at vger.kernel.org>; open list <linux-kernel at vger.kernel.org>
Subject: [PATCH] arm64: dts: ls1028a-rdb: enable optee node

From: Sahil Malhotra <sahil.malhotra at nxp.com>

optee node was disabled by default, enabling it for ls1028a-rdb.

Signed-off-by: Michael Walle <michael at walle.cc>
Signed-off-by: Sahil Malhotra <sahil.malhotra at nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 4 ++++
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index 41ae6e7675ba..1bdf0104d492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -274,6 +274,10 @@
 	status = "okay";
 };
 
+&optee {
+	status = "okay";
+};
+
 &sai4 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 262fbad8f0ec..fb155ac192b1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -92,7 +92,7 @@
 	};
 
 	firmware {
-		optee {
+		optee: optee  {
 			compatible = "linaro,optee-tz";
 			method = "smc";
 			status = "disabled";
-- 
2.17.1



From matthias.bgg at gmail.com  Wed Apr 14 09:51:40 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 14 Apr 2021 10:51:40 +0200
Subject: [PATCH v2, 0/5] Revert "mailbox: mediatek: remove implementation
 related to atomic_exec"
In-Reply-To: <CABb+yY1b9wD0hoBx=aYzpLcF-=EEG4QTrV68sZj8+rtf5J1aJQ@mail.gmail.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
 <CABb+yY1b9wD0hoBx=aYzpLcF-=EEG4QTrV68sZj8+rtf5J1aJQ@mail.gmail.com>
Message-ID: <1d946d1c-1626-33ed-26ba-f840729d63e7@gmail.com>



On 12/04/2021 17:29, Jassi Brar wrote:
> On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu
> <yongqiang.niu at mediatek.com> wrote:
>>
>> This series base linux 5.12-rc2
>> these patches will cause home ui flick when cursor moved,
>> there is no fix solution yet, revert these patches first.
>>
>> change since v1:
>> add mtk-gce.txt and dts modification
>>
>> Yongqiang Niu (5):
>>   Revert "drm/mediatek: Make sure previous message done or be aborted
>>     before send"
>>   Revert "mailbox: mediatek: remove implementation related to
>>     atomic_exec"
>>   Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
>>   Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells
>>     value"
>>   arm64: dts: mediatek: mt8183: add gce information for mmsys
>>
>>  .../devicetree/bindings/mailbox/mtk-gce.txt        |  2 +-
>>  arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  5 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c            |  1 -
>>  drivers/mailbox/mtk-cmdq-mailbox.c                 | 80 +++++++++++++++++++---
>>  4 files changed, 76 insertions(+), 12 deletions(-)
>>
> Please break the patchsets (this and the other 3) into mailbox only
> and platform specific ones.
> Also, it would help if there are some acked/reviewed by some mtk folks
> especially when reverting patches.
> 

I'd prefer to have DT and mailbox patches together as otherwise the burden on me
to find out which patches in the driver are needed, and to check if these got
accepted, gets higher.

Regards,
Matthias


From Jisheng.Zhang at synaptics.com  Wed Apr 14 09:58:08 2021
From: Jisheng.Zhang at synaptics.com (Jisheng Zhang)
Date: Wed, 14 Apr 2021 16:58:08 +0800
Subject: [PATCH] init: consolidate trap_init()
Message-ID: <20210414165808.458a3d11@xhacker.debian>

Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
---
 arch/arc/kernel/traps.c      |  5 -----
 arch/arm/kernel/traps.c      |  5 -----
 arch/h8300/kernel/traps.c    | 13 -------------
 arch/hexagon/kernel/traps.c  |  4 ----
 arch/nds32/kernel/traps.c    |  5 -----
 arch/nios2/kernel/traps.c    |  5 -----
 arch/openrisc/kernel/traps.c |  5 -----
 arch/parisc/kernel/traps.c   |  4 ----
 arch/powerpc/kernel/traps.c  |  5 -----
 arch/riscv/kernel/traps.c    |  5 -----
 arch/um/kernel/trap.c        |  4 ----
 init/main.c                  |  2 ++
 12 files changed, 2 insertions(+), 60 deletions(-)

diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 57235e5c0cea..6b83e3f2b41c 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -20,11 +20,6 @@
 #include <asm/unaligned.h>
 #include <asm/kprobes.h>
 
-void __init trap_init(void)
-{
-	return;
-}
-
 void die(const char *str, struct pt_regs *regs, unsigned long address)
 {
 	show_kernel_fault_diag(str, regs, address);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 17d5a785df28..9baccef20392 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -780,11 +780,6 @@ void abort(void)
 	panic("Oops failed to kill thread");
 }
 
-void __init trap_init(void)
-{
-	return;
-}
-
 #ifdef CONFIG_KUSER_HELPERS
 static void __init kuser_init(void *vectors)
 {
diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index 5d8b969cd8f3..c3a3ebf77fbb 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -30,19 +30,6 @@
 
 static DEFINE_SPINLOCK(die_lock);
 
-/*
- * this must be called very early as the kernel might
- * use some instruction that are emulated on the 060
- */
-
-void __init base_trap_init(void)
-{
-}
-
-void __init trap_init(void)
-{
-}
-
 asmlinkage void set_esp0(unsigned long ssp)
 {
 	current->thread.esp0 = ssp;
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 904134b37232..edfc35dafeb1 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -28,10 +28,6 @@
 #define TRAP_SYSCALL	1
 #define TRAP_DEBUG	0xdb
 
-void __init trap_init(void)
-{
-}
-
 #ifdef CONFIG_GENERIC_BUG
 /* Maybe should resemble arch/sh/kernel/traps.c ?? */
 int is_valid_bugaddr(unsigned long addr)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index ee0d9ae192a5..f06421c645af 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -183,11 +183,6 @@ void __pgd_error(const char *file, int line, unsigned long val)
 }
 
 extern char *exception_vector, *exception_vector_end;
-void __init trap_init(void)
-{
-	return;
-}
-
 void __init early_trap_init(void)
 {
 	unsigned long ivb = 0;
diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index b172da4eb1a9..596986a74a26 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -105,11 +105,6 @@ void show_stack(struct task_struct *task, unsigned long *stack,
 	printk("%s\n", loglvl);
 }
 
-void __init trap_init(void)
-{
-	/* Nothing to do here */
-}
-
 /* Breakpoint handler */
 asmlinkage void breakpoint_c(struct pt_regs *fp)
 {
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 4d61333c2623..aa1e709405ac 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -231,11 +231,6 @@ void unhandled_exception(struct pt_regs *regs, int ea, int vector)
 	die("Oops", regs, 9);
 }
 
-void __init trap_init(void)
-{
-	/* Nothing needs to be done */
-}
-
 asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
 {
 	force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->pc);
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 8d8441d4562a..747c328fb886 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -859,7 +859,3 @@ void  __init early_trap_init(void)
 
 	initialize_ivt(&fault_vector_20);
 }
-
-void __init trap_init(void)
-{
-}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a44a30b0688c..e952bee89684 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2207,11 +2207,6 @@ DEFINE_INTERRUPT_HANDLER(kernel_bad_stack)
 	die("Bad kernel stack pointer", regs, SIGABRT);
 }
 
-void __init trap_init(void)
-{
-}
-
-
 #ifdef CONFIG_PPC_EMULATED_STATS
 
 #define WARN_EMULATED_SETUP(type)	.type = { .name = #type }
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 0879b5df11b9..b3f3d84de779 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -194,8 +194,3 @@ int is_valid_bugaddr(unsigned long pc)
 		return ((insn & __COMPRESSED_INSN_MASK) == __BUG_INSN_16);
 }
 #endif /* CONFIG_GENERIC_BUG */
-
-/* stvec & scratch is already set from head.S */
-void trap_init(void)
-{
-}
diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index ad12f78bda7e..3198c4767387 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -311,7 +311,3 @@ void winch(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs)
 {
 	do_IRQ(WINCH_IRQ, regs);
 }
-
-void trap_init(void)
-{
-}
diff --git a/init/main.c b/init/main.c
index 53b278845b88..4bdbe2928530 100644
--- a/init/main.c
+++ b/init/main.c
@@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
 }
 #endif
 
+void __init __weak trap_init(void) { }
+
 /* Report memory auto-initialization states for this boot. */
 static void __init report_meminit(void)
 {
-- 
2.31.0



From maz at kernel.org  Wed Apr 14 10:05:05 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 10:05:05 +0100
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <20210414065109.8616-3-zhukeqian1@huawei.com>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
 <20210414065109.8616-3-zhukeqian1@huawei.com>
Message-ID: <87pmyxme2m.wl-maz@kernel.org>

+ Santosh, who found some interesting bugs in that area before.

On Wed, 14 Apr 2021 07:51:09 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
> 
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
> 
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
> 
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
> 
> This adds device_rough_page_shift() to check these two points when
> selecting block mapping size.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>  arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
>  1 file changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..1a6d96169d60 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>  }
>  
> +/*
> + * Find a max mapping size that properly insides the vma. And hva and pa must
> + * have the same alignment to this mapping size. It's rough as there are still
> + * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
> + */
> +static short device_rough_page_shift(struct vm_area_struct *vma,
> +				     unsigned long hva)

My earlier question still stands. Under which circumstances would this
function return something that is *not* the final mapping size? I
really don't see a reason why this would not return the final mapping
size.

> +{
> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +
>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>  					       unsigned long hva,
>  					       unsigned long map_size)
> @@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  	}
>  
> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> +	/*
> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> +	 * get block mapping for device MMIO region.
> +	 */
>  	mmap_read_lock(current->mm);
>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>  	if (unlikely(!vma)) {
> @@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  
>  	if (is_vm_hugetlb_page(vma))
>  		vma_shift = huge_page_shift(hstate_vma(vma));
> +	else if (vma->vm_flags & VM_PFNMAP)
> +		vma_shift = device_rough_page_shift(vma, hva);

What prevents a VMA from having both VM_HUGETLB and VM_PFNMAP? This is
pretty unlikely, but I'd like to see this case catered for.

>  	else
>  		vma_shift = PAGE_SHIFT;
>  
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	if (logging_active) {
>  		force_pte = true;
>  		vma_shift = PAGE_SHIFT;
>  	}
> @@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  
>  	if (kvm_is_device_pfn(pfn)) {
>  		device = true;
> -		force_pte = true;
> +		force_pte = (vma_pagesize == PAGE_SIZE);

Why do we need to set force_pte if we are already dealing with
PAGE_SIZE? I guess you are doing this for the sake of avoiding the
call to transparent_hugepage_adjust(), right?

I'd rather you simply don't try to upgrade a device mapping by
explicitly checking for this and keep force_pte for *memory*
exclusively.

Santosh, can you please take a look at this series and try to see if
the problem you fixed in [1] (which ended up as commit 91a2c34b7d6f)
is still OK with this series?

>  	} else if (logging_active && !write_fault) {
>  		/*
>  		 * Only actually map the page as writable if this was a write

Thanks,

	M.

[1] https://lore.kernel.org/kvmarm/1603711447-11998-1-git-send-email-sashukla at nvidia.com/

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


From daniel at ffwll.ch  Wed Apr 14 10:10:46 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Wed, 14 Apr 2021 11:10:46 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <9395e1fde2725d4fe01c206d9172b8acd7cdf921.camel@nxp.com>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
 <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
 <YHWk9V/4mu1lGFgD@phenom.ffwll.local>
 <83a41b2e9636cb6a790b23843c6d2628d02c6997.camel@pengutronix.de>
 <9395e1fde2725d4fe01c206d9172b8acd7cdf921.camel@nxp.com>
Message-ID: <YHaxls5WbuU/5pts@phenom.ffwll.local>

On Wed, Apr 14, 2021 at 10:24:22AM +0800, Liu Ying wrote:
> Hi Daniel,
> 
> On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > > > Since
> > > > > 
> > > > > commit 890880ddfdbe256083170866e49c87618b706ac7
> > > > > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > > > > Date:   Fri Jan 4 09:56:10 2019 +0100
> > > > > 
> > > > >     drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > > > > 
> > > > > this is done automatically as part of plane init, if drivers set the
> > > > > modifier list correctly. Which is the case here.
> > > > > 
> > > > > This one actually set it twice on top of what drm_plane_init does, so
> > > > > double-redundant!
> > > > 
> > > > That's not true. imx-dcss and imx-drm are two totally separate drivers.
> > > > Maybe we should move imx-drm into its own ipuv3 directory one day to
> > > > make this more clear. Change is still correct, though.
> > > 
> > > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the
> > > imx main driver ... where are planes set up for that? Need to review that
> > > they have the modifiers listed in all cases.
> > 
> > That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always
> > set on plane init.

Oh I didn't grep for the new drmm_universal_plane_alloc. Thanks for
pointing this out.

> > 
> > Regards,
> > Lucas
> > 
> > > > Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> > > > 
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > > > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > > > > Cc: Shawn Guo <shawnguo at kernel.org>
> > > > > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > > > > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > > > > Cc: Fabio Estevam <festevam at gmail.com>
> > > > > Cc: NXP Linux Team <linux-imx at nxp.com>
> > > > > Cc: linux-arm-kernel at lists.infradead.org
> > > > > ---
> > > > >  drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> > > > >  drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
> 
> Nit: Since this patch touches two totally separate drivers(imx-dcss and
> imx-drm), it would be good to split it into two patches.

I think if you expect that, then you need to move the imx-drm driver into
a subdirectory like dcss. And like e.g. drm/msm works too. As-is this is
just kinda confusing for people not involved in imx.
-Daniel

> 
> Thanks,
> Liu Ying
> 
> > > > >  2 files changed, 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > > index b549ce5e7607..37ae68a7fba5 100644
> > > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> > > > >  	config->min_height = 1;
> > > > >  	config->max_width = 4096;
> > > > >  	config->max_height = 4096;
> > > > > -	config->allow_fb_modifiers = true;
> > > > >  	config->normalize_zpos = true;
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > >  	config->funcs = &dcss_drm_mode_config_funcs;
> > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > index 2ded8e4f32d0..8be4edaec958 100644
> > > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> > > > >  	drm->mode_config.max_height = 4096;
> > > > >  	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > > > >  	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > > > > -	drm->mode_config.allow_fb_modifiers = true;
> > > > >  	drm->mode_config.normalize_zpos = true;
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > >  	ret = drmm_mode_config_init(drm);
> > 
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From christophe.leroy at csgroup.eu  Wed Apr 14 10:10:42 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 14 Apr 2021 11:10:42 +0200
Subject: [PATCH] init: consolidate trap_init()
In-Reply-To: <20210414165808.458a3d11@xhacker.debian>
References: <20210414165808.458a3d11@xhacker.debian>
Message-ID: <44bdf1f1-117d-0f10-fc59-9edd32d1ad61@csgroup.eu>



Le 14/04/2021 ? 10:58, Jisheng Zhang a ?crit?:
> Many architectures implement the trap_init() as NOP, since there is
> no such default for trap_init(), this empty stub is duplicated among
> these architectures. Provide a generic but weak NOP implementation
> to drop the empty stubs of trap_init() in these architectures.

You define the weak function in the __init section.

Most but not all architectures had it in __init section.

And the remaining ones may not be defined in __init section. For instance look at the one in alpha 
architecture.

Have you checked that it is not a problem ? It would be good to say something about it in the commit 
description.


> 
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
> ---
>   arch/arc/kernel/traps.c      |  5 -----
>   arch/arm/kernel/traps.c      |  5 -----
>   arch/h8300/kernel/traps.c    | 13 -------------
>   arch/hexagon/kernel/traps.c  |  4 ----
>   arch/nds32/kernel/traps.c    |  5 -----
>   arch/nios2/kernel/traps.c    |  5 -----
>   arch/openrisc/kernel/traps.c |  5 -----
>   arch/parisc/kernel/traps.c   |  4 ----
>   arch/powerpc/kernel/traps.c  |  5 -----
>   arch/riscv/kernel/traps.c    |  5 -----
>   arch/um/kernel/trap.c        |  4 ----
>   init/main.c                  |  2 ++
>   12 files changed, 2 insertions(+), 60 deletions(-)
> 
> diff --git a/init/main.c b/init/main.c
> index 53b278845b88..4bdbe2928530 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
>   }
>   #endif
>   
> +void __init __weak trap_init(void) { }
> +

I think in a C file we don't try to save space as much as in a header file.

I would prefer something like:


void __init __weak trap_init(void)
{
}


>   /* Report memory auto-initialization states for this boot. */
>   static void __init report_meminit(void)
>   {
> 


From yangyicong at hisilicon.com  Wed Apr 14 10:19:07 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Wed, 14 Apr 2021 17:19:07 +0800
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
Message-ID: <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>

On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> about this driver when configuring a kernel without Hisilicon platform
> or ACPI firmware support.
> 

this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
not sure all the platform this IP on has ARCH_HISI configured. The driver
will not be compiled by default config. This is not correct to have
this dependence.

> Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
>  drivers/i2c/busses/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
>  
>  config I2C_HISI
>  	tristate "HiSilicon I2C controller"
> -	depends on ARM64 || COMPILE_TEST
> +	depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
>  	help
>  	  Say Y here if you want to have Hisilicon I2C controller support
>  	  available on the Kunpeng Server.
> 



From Jisheng.Zhang at synaptics.com  Wed Apr 14 10:27:57 2021
From: Jisheng.Zhang at synaptics.com (Jisheng Zhang)
Date: Wed, 14 Apr 2021 17:27:57 +0800
Subject: [PATCH] init: consolidate trap_init()
In-Reply-To: <44bdf1f1-117d-0f10-fc59-9edd32d1ad61@csgroup.eu>
References: <20210414165808.458a3d11@xhacker.debian>
 <44bdf1f1-117d-0f10-fc59-9edd32d1ad61@csgroup.eu>
Message-ID: <20210414172757.3ebfaa4c@xhacker.debian>

On Wed, 14 Apr 2021 11:10:42 +0200
Christophe Leroy <christophe.leroy at csgroup.eu> wrote:

> 
> Le 14/04/2021 ? 10:58, Jisheng Zhang a ?crit :
> > Many architectures implement the trap_init() as NOP, since there is
> > no such default for trap_init(), this empty stub is duplicated among
> > these architectures. Provide a generic but weak NOP implementation
> > to drop the empty stubs of trap_init() in these architectures.  
> 
> You define the weak function in the __init section.
> 
> Most but not all architectures had it in __init section.
> 
> And the remaining ones may not be defined in __init section. For instance look at the one in alpha
> architecture.
> 
> Have you checked that it is not a problem ? It would be good to say something about it in the commit
> description.

For those non-nop platforms, I can only test x86/arm64/, but both has
__init mark. I'm not sure whether this is a problem for alpha etc. Maybe
I can check which section the trap_init() sits. Or to avoid any possible
regression, I can add __init mark to those remaining ones without it in
preparation patches.

> 
> 
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
> > ---
> >   arch/arc/kernel/traps.c      |  5 -----
> >   arch/arm/kernel/traps.c      |  5 -----
> >   arch/h8300/kernel/traps.c    | 13 -------------
> >   arch/hexagon/kernel/traps.c  |  4 ----
> >   arch/nds32/kernel/traps.c    |  5 -----
> >   arch/nios2/kernel/traps.c    |  5 -----
> >   arch/openrisc/kernel/traps.c |  5 -----
> >   arch/parisc/kernel/traps.c   |  4 ----
> >   arch/powerpc/kernel/traps.c  |  5 -----
> >   arch/riscv/kernel/traps.c    |  5 -----
> >   arch/um/kernel/trap.c        |  4 ----
> >   init/main.c                  |  2 ++
> >   12 files changed, 2 insertions(+), 60 deletions(-)
> >
> > diff --git a/init/main.c b/init/main.c
> > index 53b278845b88..4bdbe2928530 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -790,6 +790,8 @@ static inline void initcall_debug_enable(void)
> >   }
> >   #endif
> >
> > +void __init __weak trap_init(void) { }
> > +  
> 
> I think in a C file we don't try to save space as much as in a header file.
> 

This is to follow most weak NOP implementations in init/main.c to make
the style unified in the same file. I'm not sure which is better.

> I would prefer something like:
> 
> 
> void __init __weak trap_init(void)
> {
> }
> 
> 
> >   /* Report memory auto-initialization states for this boot. */
> >   static void __init report_meminit(void)
> >   {
> >  



From Jisheng.Zhang at synaptics.com  Wed Apr 14 10:38:32 2021
From: Jisheng.Zhang at synaptics.com (Jisheng Zhang)
Date: Wed, 14 Apr 2021 17:38:32 +0800
Subject: [PATCH] init: consolidate trap_init()
In-Reply-To: <20210414172757.3ebfaa4c@xhacker.debian>
References: <20210414165808.458a3d11@xhacker.debian>
 <44bdf1f1-117d-0f10-fc59-9edd32d1ad61@csgroup.eu>
 <20210414172757.3ebfaa4c@xhacker.debian>
Message-ID: <20210414173832.52bc3ddb@xhacker.debian>

On Wed, 14 Apr 2021 17:27:57 +0800
Jisheng Zhang <Jisheng.Zhang at synaptics.com> wrote:

> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On Wed, 14 Apr 2021 11:10:42 +0200
> Christophe Leroy <christophe.leroy at csgroup.eu> wrote:
> 
> >
> > Le 14/04/2021 ? 10:58, Jisheng Zhang a ?crit :  
> > > Many architectures implement the trap_init() as NOP, since there is
> > > no such default for trap_init(), this empty stub is duplicated among
> > > these architectures. Provide a generic but weak NOP implementation
> > > to drop the empty stubs of trap_init() in these architectures.  
> >
> > You define the weak function in the __init section.
> >
> > Most but not all architectures had it in __init section.
> >
> > And the remaining ones may not be defined in __init section. For instance look at the one in alpha
> > architecture.
> >
> > Have you checked that it is not a problem ? It would be good to say something about it in the commit
> > description.  
> 
> For those non-nop platforms, I can only test x86/arm64/, but both has
> __init mark. I'm not sure whether this is a problem for alpha etc. Maybe
> I can check which section the trap_init() sits. Or to avoid any possible
> regression, I can add __init mark to those remaining ones without it in
> preparation patches.
> 

Hi,

I found only three platforms don't have the __init marker for trap_init(), I
will add the __init marker in three preparation patches in new version.

thanks


From dietmar.eggemann at arm.com  Wed Apr 14 10:42:57 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Wed, 14 Apr 2021 11:42:57 +0200
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3NaUAvjv9=9HZ4jQU=DVcZW6gRKZg9ZjutL3aKnnC4FLw@mail.gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
 <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
 <87o8eimmyw.mognet@arm.com>
 <CAG7+-3NaUAvjv9=9HZ4jQU=DVcZW6gRKZg9ZjutL3aKnnC4FLw@mail.gmail.com>
Message-ID: <74b3ff57-473f-4d5a-daf8-ecbb0761abb2@arm.com>

On 13/04/2021 15:26, Ruifeng Zhang wrote:
> Thanks for your review. Patch-v2 that solve the capacity issue will be
> uploaded as soon as possible. : )
> 
> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?13??? ??7:40???
>>
>> On 13/04/21 14:13, Ruifeng Zhang wrote:
>>> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???
>>>> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
>>>> I couldn't find anything about MPIDR format differences:
>>>>
>>>>   DDI 0487G.a G8.2.113
>>>>   """
>>>>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
>>>>   AArch64 System register MPIDR_EL1[31:0].
>>>>   """
>>>>
>>>> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
>>>> just the same, i.e. for both of them, with your example of:
>>>
>>> The cortex-a7 spec DDI0464F 4.3.5
>>> https://developer.arm.com/documentation/ddi0464/f/?lang=en
>>>
>>
>> Ah, so that's where the core_id=bit[1:0] comes from. That does still
>> conform to the MPIDR format, and as you point out below that's being parsed
>> the same (aff2, aff1, aff0) == mpidr([23:16][15:8][7:0])
>>
>>> The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
>>> the parse code is:
>>> void store_cpu_topology(unsigned int cpuid)
>>> {
>>>     ...
>>>     cpuid_topo->thread_id = -1;
>>>     cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>>>     cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>>>     ...
>>> }
>>>>
>>>>   core0: 0000000080000000
>>>>   core1: 0000000080000100
>>>>   core2: 0000000080000200
>>>>   ...
>>>>
>>>> we'll get:
>>>>
>>>>   |       | aff2 | aff1 | aff0 |
>>>>   |-------+------+------+------|
>>>>   | Core0 |    0 |    0 |    0 |
>>>>   | Core1 |    0 |    1 |    0 |
>>>>   | Core2 |    0 |    2 |    0 |
>>>>       ...
>>>>
>>>> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
>>>>
>>>>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>>>>
>>>> so without DT we would get:
>>>>   |       | package_id | core_id |
>>>>   |-------+------------+---------|
>>>>   | Core0 |          0 |       0 |
>>>>   | Core1 |          0 |       1 |
>>>>   | Core2 |          0 |       2 |
>>>>
>>>> Whereas with an arm kernel we'll end up parsing MPIDR as:
>>>>   |       | package_id | core_id |
>>>>   |-------+------------+---------|
>>>>   | Core0 |          0 |       0 |
>>>>   | Core1 |          1 |       0 |
>>>>   | Core2 |          2 |       0 |
>>>>
>>>> Did I get this right? Is this what you're observing?
>>>
>>> Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
>>> kernel on EL1.
>>
>>
>> With the above MPIDR(_EL1) values, you would have the same problem in
>> aarch64 mode on any kernel predating
>>
>>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
>>
>> since all Aff0 values are 0. Arguably those MPIDR(_EL1) values don't
>> make much sense (cores in the same cluster should have different Aff0
>> values, unless SMT), but in arm64 that's usually "corrected" by DT.
>>
>> As you pointed out, arm doesn't currently leverage the cpu-map DT entry. I
>> don't see any obvious problem with adding support for it, so if you can fix
>> the capacity issue Dietmar reported, I think we could consider it.

Coming back to your original patch. You want to use parse_dt_topology()
from drivers/base/arch_topology.c to be able detect a cpu-map in dt and
so bypassing the read of mpidr in store_cpu_topology()?

Looks like sc9863a has two frequency domains (1.6 and 1.2GHz). So
technically it's a big.LITTLE system (based only on max CPU frequency
(not on uarch) differences).
But the dts file doesn't contain any `capacity-dmips-mhz` entries? So
asymmetric CPU capacity (even only based on max CPU frequency) detection
won't kick in. Since you don't have any uarch diffs, you would have to
specify `capacity-dmips-mhz = <1024>` for each CPU.


From narmstrong at baylibre.com  Wed Apr 14 11:00:10 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Wed, 14 Apr 2021 12:00:10 +0200
Subject: [PATCH] mmc: meson-gx: remove useless warning about scatterlist size
 alignment in block mode
Message-ID: <20210414100010.3877669-1-narmstrong@baylibre.com>

Since commit e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode"),
support for SDIO SD_IO_RW_EXTENDED transferts are properly filtered but some driver
like brcmfmac still gives a block sg buffer size not aligned with SDIO block,
triggerring a warning even if the transfer works in degraded mode.

This should be ultimately fixed in brcmfmac, but since it's only a performance issue
the warning should be removed.

Fixes: e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode")
Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index eb6c02bc4a02..6bc151045843 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -246,11 +246,8 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
 		 * size, otherwise chain mode could not be used.
 		 */
 		for_each_sg(data->sg, sg, data->sg_len, i) {
-			if (sg->length % data->blksz) {
-				WARN_ONCE(1, "unaligned sg len %u blksize %u\n",
-					  sg->length, data->blksz);
+			if (sg->length % data->blksz)
 				return;
-			}
 		}
 	}
 
-- 
2.25.1



From Jisheng.Zhang at synaptics.com  Wed Apr 14 11:00:45 2021
From: Jisheng.Zhang at synaptics.com (Jisheng Zhang)
Date: Wed, 14 Apr 2021 18:00:45 +0800
Subject: [PATCH v2] init: consolidate trap_init()
In-Reply-To: <20210414165808.458a3d11@xhacker.debian>
References: <20210414165808.458a3d11@xhacker.debian>
Message-ID: <20210414180037.14602dab@xhacker.debian>

Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.

The alpha, microblaze and sparc32 have real trap_init() implementation
but the __init marker is missing, so add it to these three platforms.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
---
Since v1:
 - add __init marker to trap_init() for alpha, microblaze and sparc32
 - adjust the generic weak NOP trap_init() location to make it sits with
   other NOP implementations together

 arch/alpha/kernel/traps.c      |  2 +-
 arch/arc/kernel/traps.c        |  5 -----
 arch/arm/kernel/traps.c        |  5 -----
 arch/h8300/kernel/traps.c      | 13 -------------
 arch/hexagon/kernel/traps.c    |  4 ----
 arch/microblaze/kernel/traps.c |  2 +-
 arch/nds32/kernel/traps.c      |  5 -----
 arch/nios2/kernel/traps.c      |  5 -----
 arch/openrisc/kernel/traps.c   |  5 -----
 arch/parisc/kernel/traps.c     |  4 ----
 arch/powerpc/kernel/traps.c    |  5 -----
 arch/riscv/kernel/traps.c      |  5 -----
 arch/sparc/kernel/traps_32.c   |  2 +-
 arch/um/kernel/trap.c          |  4 ----
 init/main.c                    |  2 ++
 15 files changed, 5 insertions(+), 63 deletions(-)

diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 921d4b6e4d95..96b203199c6c 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -973,7 +973,7 @@ do_entUnaUser(void __user * va, unsigned long opcode,
 	return;
 }
 
-void
+void __init
 trap_init(void)
 {
 	/* Tell PAL-code what global pointer we want in the kernel.  */
diff --git a/arch/arc/kernel/traps.c b/arch/arc/kernel/traps.c
index 57235e5c0cea..6b83e3f2b41c 100644
--- a/arch/arc/kernel/traps.c
+++ b/arch/arc/kernel/traps.c
@@ -20,11 +20,6 @@
 #include <asm/unaligned.h>
 #include <asm/kprobes.h>
 
-void __init trap_init(void)
-{
-	return;
-}
-
 void die(const char *str, struct pt_regs *regs, unsigned long address)
 {
 	show_kernel_fault_diag(str, regs, address);
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 17d5a785df28..9baccef20392 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -780,11 +780,6 @@ void abort(void)
 	panic("Oops failed to kill thread");
 }
 
-void __init trap_init(void)
-{
-	return;
-}
-
 #ifdef CONFIG_KUSER_HELPERS
 static void __init kuser_init(void *vectors)
 {
diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index 5d8b969cd8f3..c3a3ebf77fbb 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -30,19 +30,6 @@
 
 static DEFINE_SPINLOCK(die_lock);
 
-/*
- * this must be called very early as the kernel might
- * use some instruction that are emulated on the 060
- */
-
-void __init base_trap_init(void)
-{
-}
-
-void __init trap_init(void)
-{
-}
-
 asmlinkage void set_esp0(unsigned long ssp)
 {
 	current->thread.esp0 = ssp;
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 904134b37232..edfc35dafeb1 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -28,10 +28,6 @@
 #define TRAP_SYSCALL	1
 #define TRAP_DEBUG	0xdb
 
-void __init trap_init(void)
-{
-}
-
 #ifdef CONFIG_GENERIC_BUG
 /* Maybe should resemble arch/sh/kernel/traps.c ?? */
 int is_valid_bugaddr(unsigned long addr)
diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index 94b6fe93147d..7c15704fe56e 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -18,7 +18,7 @@
 #include <asm/exceptions.h>
 #include <asm/unwind.h>
 
-void trap_init(void)
+void __init trap_init(void)
 {
 	__enable_hw_exceptions();
 }
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index ee0d9ae192a5..f06421c645af 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -183,11 +183,6 @@ void __pgd_error(const char *file, int line, unsigned long val)
 }
 
 extern char *exception_vector, *exception_vector_end;
-void __init trap_init(void)
-{
-	return;
-}
-
 void __init early_trap_init(void)
 {
 	unsigned long ivb = 0;
diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index b172da4eb1a9..596986a74a26 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -105,11 +105,6 @@ void show_stack(struct task_struct *task, unsigned long *stack,
 	printk("%s\n", loglvl);
 }
 
-void __init trap_init(void)
-{
-	/* Nothing to do here */
-}
-
 /* Breakpoint handler */
 asmlinkage void breakpoint_c(struct pt_regs *fp)
 {
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 4d61333c2623..aa1e709405ac 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -231,11 +231,6 @@ void unhandled_exception(struct pt_regs *regs, int ea, int vector)
 	die("Oops", regs, 9);
 }
 
-void __init trap_init(void)
-{
-	/* Nothing needs to be done */
-}
-
 asmlinkage void do_trap(struct pt_regs *regs, unsigned long address)
 {
 	force_sig_fault(SIGTRAP, TRAP_BRKPT, (void __user *)regs->pc);
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 8d8441d4562a..747c328fb886 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -859,7 +859,3 @@ void  __init early_trap_init(void)
 
 	initialize_ivt(&fault_vector_20);
 }
-
-void __init trap_init(void)
-{
-}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a44a30b0688c..e952bee89684 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2207,11 +2207,6 @@ DEFINE_INTERRUPT_HANDLER(kernel_bad_stack)
 	die("Bad kernel stack pointer", regs, SIGABRT);
 }
 
-void __init trap_init(void)
-{
-}
-
-
 #ifdef CONFIG_PPC_EMULATED_STATS
 
 #define WARN_EMULATED_SETUP(type)	.type = { .name = #type }
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 0879b5df11b9..b3f3d84de779 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -194,8 +194,3 @@ int is_valid_bugaddr(unsigned long pc)
 		return ((insn & __COMPRESSED_INSN_MASK) == __BUG_INSN_16);
 }
 #endif /* CONFIG_GENERIC_BUG */
-
-/* stvec & scratch is already set from head.S */
-void trap_init(void)
-{
-}
diff --git a/arch/sparc/kernel/traps_32.c b/arch/sparc/kernel/traps_32.c
index 247a0d9683b2..c4df20ec01e2 100644
--- a/arch/sparc/kernel/traps_32.c
+++ b/arch/sparc/kernel/traps_32.c
@@ -365,7 +365,7 @@ EXPORT_SYMBOL(do_BUG);
  * up here so that timer interrupts work during initialization.
  */
 
-void trap_init(void)
+void __init trap_init(void)
 {
 	extern void thread_info_offsets_are_bolixed_pete(void);
 
diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index ad12f78bda7e..3198c4767387 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -311,7 +311,3 @@ void winch(int sig, struct siginfo *unused_si, struct uml_pt_regs *regs)
 {
 	do_IRQ(WINCH_IRQ, regs);
 }
-
-void trap_init(void)
-{
-}
diff --git a/init/main.c b/init/main.c
index 53b278845b88..8d14674c4e00 100644
--- a/init/main.c
+++ b/init/main.c
@@ -779,6 +779,8 @@ void __init __weak poking_init(void) { }
 
 void __init __weak pgtable_cache_init(void) { }
 
+void __init __weak trap_init(void) { }
+
 bool initcall_debug;
 core_param(initcall_debug, initcall_debug, bool, 0644);
 
-- 
2.31.0



From catalin.marinas at arm.com  Wed Apr 14 11:06:51 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 14 Apr 2021 11:06:51 +0100
Subject: [PATCH] arm64/sve: Remove redundant system_supports_sve() tests
In-Reply-To: <20210412172320.3315-1-broonie@kernel.org>
References: <20210412172320.3315-1-broonie@kernel.org>
Message-ID: <161839480316.21512.15943685062801779565.b4-ty@arm.com>

On Mon, 12 Apr 2021 18:23:20 +0100, Mark Brown wrote:
> Currently there are a number of places in the SVE code where we check both
> system_supports_sve() and TIF_SVE. This is a bit redundant given that we
> should never get into a situation where we have set TIF_SVE without having
> SVE support and it is not clear that silently ignoring a mistakenly set
> TIF_SVE flag is the most sensible error handling approach. For now let's
> just drop the system_supports_sve() checks since this will at least reduce
> overhead a little.

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64/sve: Remove redundant system_supports_sve() tests
      https://git.kernel.org/arm64/c/ef9c5d09797d

-- 
Catalin



From catalin.marinas at arm.com  Wed Apr 14 11:07:54 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 14 Apr 2021 11:07:54 +0100
Subject: [PATCH] arm64/kernel/probes: Use BUG_ON instead of if condition
 followed by BUG.
In-Reply-To: <1617105472-6081-1-git-send-email-zhouchuangao@vivo.com>
References: <1617105472-6081-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <161839480316.21512.13167172134622153882.b4-ty@arm.com>

On Tue, 30 Mar 2021 04:57:50 -0700, zhouchuangao wrote:
> It can be optimized at compile time.

Applied to arm64 (for-next/misc), it saves one line ;). Thanks!

[1/1] arm64/kernel/probes: Use BUG_ON instead of if condition followed by BUG.
      https://git.kernel.org/arm64/c/839157876f97

-- 
Catalin



From catalin.marinas at arm.com  Wed Apr 14 11:10:19 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 14 Apr 2021 11:10:19 +0100
Subject: [PATCH v8 1/3] arm64: mte: make the per-task SCTLR_EL1 field
 usable elsewhere
In-Reply-To: <13d725cb8e741950fb9d6e64b2cd9bd54ff7c3f9.1616123271.git.pcc@google.com>
References: <13d725cb8e741950fb9d6e64b2cd9bd54ff7c3f9.1616123271.git.pcc@google.com>
Message-ID: <161839488327.21932.16461913261970131291.b4-ty@arm.com>

On Thu, 18 Mar 2021 20:10:52 -0700, Peter Collingbourne wrote:
> In an upcoming change we are going to introduce per-task SCTLR_EL1
> bits for PAC. Move the existing per-task SCTLR_EL1 field out of the
> MTE-specific code so that we will be able to use it from both the
> PAC and MTE code paths and make the task switching code more efficient.

Applied to arm64 (for-next/pac-set-get-enabled-keys).

Peter, can you please have a look and give it a try as part of the arm64
for-next/core branch? I rebased your patches on top of the
for-next/mte-async-kernel-mode branch as this was adding more code to
mte_thread_switch(), so I kept the function for now.

Thanks.

[1/3] arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere
      https://git.kernel.org/arm64/c/2f79d2fc391e
[2/3] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)
      https://git.kernel.org/arm64/c/201698626fbc
[3/3] arm64: pac: Optimize kernel entry/exit key installation code paths
      https://git.kernel.org/arm64/c/b90e483938ce

-- 
Catalin



From madvenka at linux.microsoft.com  Wed Apr 14 11:23:38 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Wed, 14 Apr 2021 05:23:38 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210413110255.GB5586@sirena.org.uk>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
 <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
 <20210413110255.GB5586@sirena.org.uk>
Message-ID: <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>



On 4/13/21 6:02 AM, Mark Brown wrote:
> On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote:
> 
>>
>> OK. Just so I am clear on the whole picture, let me state my understanding so far.
>> Correct me if I am wrong.
> 
>> 1. We are hoping that we can convert a significant number of SYM_CODE functions to
>>    SYM_FUNC functions by providing them with a proper FP prolog and epilog so that
>>    we can get objtool coverage for them. These don't need any blacklisting.
> 
> I wouldn't expect to be converting lots of SYM_CODE to SYM_FUNC.  I'd
> expect the overwhelming majority of SYM_CODE to be SYM_CODE because it's
> required to be non standard due to some external interface - things like
> the exception vectors, ftrace, and stuff around suspend/hibernate.  A
> quick grep seems to confirm this.
> 

OK. Fair enough.

>> 3. We are going to assume that the reliable unwinder is only for livepatch purposes
>>    and will only be invoked on a task that is not currently running. The task either
> 
> The reliable unwinder can also be invoked on itself.
> 

I have not called out the self-directed case because I am assuming that the reliable unwinder
is only used for livepatch. So, AFAICT, this is applicable to the task that performs the
livepatch operation itself. In this case, there should be no unreliable functions on the
self-directed stack trace (otherwise, livepatching would always fail).

>> 4. So, the only functions that will need blacklisting are the remaining SYM_CODE functions
>>    that might give up the CPU voluntarily. At this point, I am not even sure how
>>    many of these will exist. One hopes that all of these would have ended up as
>>    SYM_FUNC functions in (1).
> 
> There's stuff like ret_from_fork there.
> 

OK. There would be a few functions that fit this category. I agree.

>> I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the
>> remaining ones to see which ones must be blacklisted, if any.
> 
> I'm not clear what the concrete steps you're planning to do first are
> there - your 3 seems like a statement of assumptions.  For flagging
> functions I do think it'd be safer to default to assuming that all
> SYM_CODE functions can't be unwound reliably rather than only explicitly
> listing ones that cause problems.
> 

They are not assumptions. They are true statements. But I probably did not do a good
job of explaining. But Josh sent out a patch that updates the documentation that
explains what I said a lot better.

In any case, I have absolutely no problems in implementing your section idea. I will
make an attempt to do that in version 3 of my patch series.

Stay tuned.

And, thanks for all the input. It is very helpful.

Madhavan


From andre.przywara at arm.com  Wed Apr 14 11:35:16 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 14 Apr 2021 11:35:16 +0100
Subject: [linux-sunxi] [PATCH] arm64: dts: allwinner: Revert SD card CD
 GPIO for Pine64-LTS
In-Reply-To: <YHXneEEiFCwna7X6@weiser.dinsnail.net>
References: <20210412000813.13071-1-andre.przywara@arm.com>
 <CAGb2v65uwo5Ns_ODNyX9S4H=cS6TGWCgaEyzhMaRaayxUtif2g@mail.gmail.com>
 <20210412174558.4ba90cf8@slackpad.fritz.box>
 <YHSGRSQr5w0h8vtt@weiser.dinsnail.net>
 <20210413115837.232c465a@slackpad.fritz.box>
 <YHXneEEiFCwna7X6@weiser.dinsnail.net>
Message-ID: <20210414113516.0fdc3a24@slackpad.fritz.box>

On Tue, 13 Apr 2021 20:48:24 +0200
Michael Weiser <michael.weiser at gmx.de> wrote:

Hi Michael,

thanks for the reply and your testing!

> On Tue, Apr 13, 2021 at 11:58:37AM +0100, Andre Przywara wrote:
> 
> > > > Daniel, Michael, can you test this on your boards? So removing the
> > > > cd-gpios property, and adding "broken-cd;" instead?    
> > > Yes, it works fine. What flummoxed me at first was that obviously I also
> > > have to disable the ACTIVE_LOW definition in sun50i-a64-sopine.dtsi
> > > after having added and disabled an ACTIVE_HIGH definition in
> > > sun50i-a64-pine64-lts.dts.  
> > Why? From my experiments it should not matter, the actual card presence
> > is typically detected via the SD bus anyway (if I understand the code
> > correctly). broken-cd just prevents installation of an interrupt
> > handler, so it's less efficient and prevents wakeup on card detect,
> > AFAICS.  
> 
> I just retested to be sure: At least with 5.11.11 and on my boards,
> cd-gpio ACTIVE_LOW being specified in the sopine.dtsi takes precedence
> over broken-cd being specified in pine64-lts.dts. Could that spoil the
> plan of disabling cd-gpio for the LTS while leaving it enabled for
> Sopine and baseboard?

I am not sure what you mean with "takes precedence"? And there should be
no active-low anymore, after that other patch of mine[1].

The CD GPIO and broken-cd are somewhat independent: Whenever a CD GPIO
is specified in the DT, the code will pick it up and use any level
changes, but only to trigger the actual card detection routine (over the
SD bus). If "broken-cd" is NOT specified, it will also try to register
an interrupt handler for any pin change, so it doesn't need to poll and
can use it as a wakeup source.
So I specified a different GPIO and connected a switch to that pin, to
simulate the different cases:
- Having broken-cd didn't hurt in any way, maybe apart from the missing
  wakeup source (which I didn't test).
- Having no CD GPIO property, but broken-cd worked equally fine, every
  card insertion or removal was detected.
- Having the CD GPIO at somewhat random (switch not corresponding to
  actual card insertion state), but still having broken-cd, did not do
  any harm either: it always looked at the actual card state and still
  detected any card change, even without a pin change.
- The only problematic situation is "no broken-cd, but wrong CD GPIO":
  card removals are detected, but the card insertion checks would rely
  on the CD pin reading "card inserted". Not sure if there is a way
  to force card detection from the prompt somehow.

This last case however is only a problem is the CD GPIO never reads
"card inserted". In our case (active high, as inherited from the
SOPine), it works even without broken-cd on those broken boards: the
"stuck at 1" means "card always inserted", which correctly detects
every removal and insertion.

So given the above (broken-cd not doing any harm, but correctly
describing the situation on some boards), I would like to see both an
active-high CD GPIO and the broken-cd property to be in. I will send a
v2 in a minute.

> 
> Behaviour is as such: With cd-gpios ACTIVE_LOW in sopine.dtsi and

Yes, that is wrong, and I sent a patch already [1].

> broken-cd in pine64-lts.dts, card insertion, removal and reinsertion is
> not detected after booting the kernel without a card in the slot. With
> cd-gpios ACTIVE_LOW removed from sopine.dtsi it starts working.

Yes, that confirms my findings above. ACTIVE_LOW is the culprit here,
with ACTIVE_HIGH it should work.

> 
> In diffs for added clarity:
> 
> PAGER= git log --pretty=oneline HEAD~1..HEAD
> aa7258f8f3d48a29bc024ea8c5145bdc4a980e4d (HEAD, tag: v5.11.11) Linux 5.11.11
> 
> - not working on its own:
> 
> index 302e24be0a31..5b0c21e68352 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> @@ -8,3 +8,7 @@ / {
>         compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
>                      "allwinner,sun50i-a64";
>  };
> +
> +&mmc0 {
> +       broken-cd;
> +};
> 
> - working with this additional change:
> 
> index 3402cec87035..ba2b7398993b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> @@ -34,7 +34,6 @@ &mmc0 {
>         vmmc-supply = <&reg_dcdc1>;
>         disable-wp;
>         bus-width = <4>;
> -       cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */

It should work with this line still in, but reading ACTIVE_HIGH, as per
[1].

>         status = "okay";
>  };
> 
> > So for your particular board (version) you could actually remove the
> > whole &mmc0 node override, use the same node as the SOPine (working
> > active-high CD) and it should work.  
> 
> Correct. Again for reasons of laziness I tested with the dts from
> 5.11.11 which is currently running on the board and which still has
> ACTIVE_LOW in sopine.dtsi. Sorry for not being clearer about that.
> 
> But somewhat lucky as well because without ACTIVE_LOW still being set in
> sopine.dtsi I wouldn't have had a way to tell that broken-cd was not
> taking effect and silently have tested the working ACTIVE_HIGH
> definition from sopine.dtsi.
> 
> Or am I somehow making a mess of this?
> 
> > > BTW: My boards have a marking "PINE64-R18-V1_1" and below it
> > > "2017-08-03" on their upper side. On the back it says on one sticker
> > > "Model:PineA64 2GB LTS" and on another "2O1-PINE64R18-00" and
> > > "PINE64-R18-V1.1 2G". Is CD being stuck at 1 a bug of revision 1.0
> > > perhaps?  Is there a way to detect this difference in software and add
> > > some sort of quirk handler for it?  
> > As Jernej mentioned, this would be U-Boot's task, but I don't see a
> > good reason for it. Firstly, you would need to find a good automatic
> > way of determining the board revision, which I doubt there is. And
> > secondly, I don't see the benefit: It works quite nicely with
> > broken-cd: card removals and insertions are detected automatically,
> > it's just not as efficient (interrupt-driven) as it could be.
> > Or do you see any problems with broken-cd?  
> 
> Of course not. My boards have their rootfs on mmc0, so the card is never
> removed and replaced during operation anyway. I was just asking out of
> curiosity.

Ah, OK. I am running with initrds for those tests, so SD card status is
not fatal.
 
> And out of curiosity again: Could one have a device tree overlay
> configured manually to be loaded by the bootloader that adds cd-gpio
> ACTIVE_HIGH for mmc0 and disables/overrules broken-cd? Somewhat like so
> (untested):

ACTIVE_HIGH should be merged anytime soon, so we don't need that.
And yes, you can remove broken-cd, but as shown above, I don't see why
and it's certainly not worth the hassle from my point of view.

> 
> /dts-v1/;
> /plugin/;
> 
> #include <dt-bindings/gpio/gpio.h>
> 
> / {
>         fragment at 0 {
>                 target = <&mmc0>;
>                 __overlay__ {
>                         cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 push-push switch */
>                 };
>         };
> };

If you really want to remove broken-cd from the DT, you can do much
easier in U-Boot:
=> fdt addr $fdt_addr_r
=> fdt rm /soc/mmc broken-cd

> 
> Here it would be useful if cd-gpios indeed took precedence over
> broken-cd because my grepping of the code can't find a way to un-specify
> it once set.

See above, shouldn't be a problem.

Cheers,
Andre
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2021-March/645191.html



From catalin.marinas at arm.com  Wed Apr 14 11:41:44 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 14 Apr 2021 11:41:44 +0100
Subject: [PATCH] arm64:align function __arch_clear_user
In-Reply-To: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
References: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
Message-ID: <20210414104144.GB8320@arm.com>

On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
> Performance decreases happen in __arch_clear_user when this
> function is not correctly aligned on HISI-HIP08 arm64 SOC which
> fetches 32 bytes (8 instructions) from icache with a 32-bytes
> aligned end address. As a result, if the hot loop is not 32-bytes
> aligned, it may take more icache fetches which leads to decrease
> in performance.
> Dump of assembler code for function __arch_clear_user:
>        0xffff0000809e3f10 :    nop
>        0xffff0000809e3f14 :    mov x2, x1
>        0xffff0000809e3f18 :    subs x1, x1, #0x8
>        0xffff0000809e3f1c :    b.mi 0xffff0000809e3f30 <__arch_clear_user+3
> -----  0xffff0000809e3f20 :    str    xzr, [x0],#8
> hot    0xffff0000809e3f24 :    nop
> loop   0xffff0000809e3f28 :    subs x1, x1, #0x8
> -----  0xffff0000809e3f2c :    b.pl  0xffff0000809e3f20 <__arch_clear_user+1
> The hot loop above takes one icache fetch as the code is in one
> 32-bytes aligned area and the loop takes one more icache fetch
> when it is not aligned like below.
>        0xffff0000809e4178 :   str    xzr, [x0],#8
>        0xffff0000809e417c :   nop
>        0xffff0000809e4180 :   subs x1, x1, #0x8
>        0xffff0000809e4184 :   b.pl  0xffff0000809e4178 <__arch_clear_user+
> Data collected by perf:
>                          aligned   not aligned
>           instructions   57733790     57739065
>        L1-dcache-store   14938070     13718242
> L1-dcache-store-misses     349280       349869
>        L1-icache-loads   15380895     28500665
> As we can see, L1-icache-loads almost double when the loop is not
> aligned.
> This problem is found in linux 4.19 on HISI-HIP08 arm64 SOC.
> Not sure what the case is on other arm64 SOC, but it should do
> no harm.
> Signed-off-by: Kai Shen <shenkai8 at huawei.com>

Do you have a real world workload that's affected by this function?

I'm against adding alignments and nops for specific hardware
implementations. What about lots of other loops that the compiler may
generate or that we wrote in asm?

-- 
Catalin


From andre.przywara at arm.com  Wed Apr 14 11:47:40 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 14 Apr 2021 11:47:40 +0100
Subject: [PATCH v2] arm64: dts: allwinner: Revert SD card CD GPIO for
 Pine64-LTS
Message-ID: <20210414104740.31497-1-andre.przywara@arm.com>

Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

This was based on the observation that the Pine64-LTS has as "push-push"
SD card socket, and that the schematic mentions the card detect GPIO.

After having received two reports about failing SD card access with that
patch, some more research and polls on that subject revealed that there
are at least two different versions of the Pine64-LTS out there:
- On some boards (including mine) the card detect pin is "stuck" at
  high, regardless of an microSD card being inserted or not.
- On other boards the card-detect is working, but is active-high, by
  virtue of an explicit inverter circuit, as shown in the schematic.

To cover all versions of the board out there, and don't take any chances,
let's revert the introduction of the active-low CD GPIO, but let's use
the broken-cd property for the Pine64-LTS this time. That should avoid
regressions and should work for everyone, even allowing SD card changes
now.
The SOPine card detect has proven to be working, so let's keep that
GPIO in place.

Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
Reported-by: Michael Weiser <michael.weiser at gmx.de>
Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
Suggested-by: Chen-Yu Tsai <wens at csie.org>
Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
index e79ce49e7e6a..596a25907432 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -21,5 +21,5 @@
 };
 
 &mmc0 {
-	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
+	broken-cd;		/* card detect is broken on *some* boards */
 };
-- 
2.17.5



From billy_tsai at aspeedtech.com  Wed Apr 14 11:49:37 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Wed, 14 Apr 2021 18:49:37 +0800
Subject: [v2 0/2] Support pwm driver for aspeed ast26xx
Message-ID: <20210414104939.1093-1-billy_tsai@aspeedtech.com>

The legacy driver of aspeed pwm is binding with tach controller and it
doesn't follow the pwm framworks usage. In addition, the pwm register
usage of the 6th generation of ast26xx has drastic change. So these
patch serials add the new aspeed pwm driver to fix up the problem above.

Changes since v1:
- Fix the dt_binding_check fail suggested by Rob Herring
- Add depends to PWM_ASPEED_G6 configure suggested by Uwe Kleine-Konig
- pwm-aspeed-g6.c suggested by Uwe Kleine-K?nig
  - Fix license header
  - Use bitfiled.h macro to define register fields
  - Implement .remove device function
  - Implement .get_state pwm api

Billy Tsai (2):
  dt-bindings: Add bindings for aspeed pwm-tach and pwm.
  pwm: Add Aspeed ast2600 PWM support

 .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml |  60 ++++
 .../bindings/pwm/aspeed,ast2600-pwm.yaml      |  44 +++
 drivers/pwm/Kconfig                           |   7 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-aspeed-g6.c                   | 324 ++++++++++++++++++
 5 files changed, 436 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
 create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
 create mode 100644 drivers/pwm/pwm-aspeed-g6.c

-- 
2.25.1



From billy_tsai at aspeedtech.com  Wed Apr 14 11:49:39 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Wed, 14 Apr 2021 18:49:39 +0800
Subject: [v2 2/2] pwm: Add Aspeed ast2600 PWM support
In-Reply-To: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
Message-ID: <20210414104939.1093-3-billy_tsai@aspeedtech.com>

This patch add the support of PWM controller which can be found at aspeed
ast2600 soc. The pwm supoorts up to 16 channels and it's part function
of multi-funciton device "pwm-tach controller".

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
---
 drivers/pwm/Kconfig         |   7 +
 drivers/pwm/Makefile        |   1 +
 drivers/pwm/pwm-aspeed-g6.c | 324 ++++++++++++++++++++++++++++++++++++
 3 files changed, 332 insertions(+)
 create mode 100644 drivers/pwm/pwm-aspeed-g6.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..d6c1e25717d7 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -42,6 +42,13 @@ config PWM_DEBUG
 	  It is expected to introduce some runtime overhead and diagnostic
 	  output to the kernel log, so only enable while working on a driver.
 
+config PWM_ASPEED_G6
+	tristate "ASPEEDG6 PWM support"
+	depends on ARCH_ASPEED || COMPILE_TEST
+	help
+	  This driver provides support for ASPEED G6 PWM controllers.
+
+
 config PWM_AB8500
 	tristate "AB8500 PWM support"
 	depends on AB8500_CORE && ARCH_U8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..2d9b4590662e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_PWM)		+= core.o
 obj-$(CONFIG_PWM_SYSFS)		+= sysfs.o
+obj-$(CONFIG_PWM_ASPEED_G6)	+= pwm-aspeed-g6.o
 obj-$(CONFIG_PWM_AB8500)	+= pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)		+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)	+= pwm-atmel-hlcdc.o
diff --git a/drivers/pwm/pwm-aspeed-g6.c b/drivers/pwm/pwm-aspeed-g6.c
new file mode 100644
index 000000000000..b537a5d7015a
--- /dev/null
+++ b/drivers/pwm/pwm-aspeed-g6.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 ASPEED Technology Inc.
+ *
+ * PWM controller driver for Aspeed ast26xx SoCs.
+ * This drivers doesn't rollback to previous version of aspeed SoCs.
+ *
+ * Hardware Features:
+ * 1. Support up to 16 channels
+ * 2. Support PWM frequency range from 24Hz to 780KHz
+ * 3. Duty cycle from 0 to 100% with 1/256 resolution incremental
+ * 4. Support wdt reset tolerance (Driver not ready)
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/errno.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+#include <linux/reset.h>
+#include <linux/regmap.h>
+#include <linux/bitfield.h>
+#include <linux/slab.h>
+#include <linux/pwm.h>
+/* The channel number of Aspeed pwm controller */
+#define PWM_ASPEED_NR_PWMS 16
+
+/* PWM Control Register */
+#define PWM_ASPEED_CTRL_CH(ch) (((ch * 0x10) + 0x00))
+#define PWM_LOAD_SEL_RISING_AS_WDT BIT(19)
+#define PWM_DUTY_LOAD_AS_WDT_ENABLE BIT(18)
+#define PWM_DUTY_SYNC_DISABLE BIT(17)
+#define PWM_CLK_ENABLE BIT(16)
+#define PWM_LEVEL_OUTPUT BIT(15)
+#define PWM_INVERSE BIT(14)
+#define PWM_OPEN_DRAIN_ENABLE BIT(13)
+#define PWM_PIN_ENABLE BIT(12)
+#define PWM_CLK_DIV_H GENMASK(11, 8)
+#define PWM_CLK_DIV_L GENMASK(7, 0)
+
+/* PWM Duty Cycle Register */
+#define PWM_ASPEED_DUTY_CYCLE_CH(ch) (((ch * 0x10) + 0x04))
+#define PWM_PERIOD GENMASK(31, 24)
+#define PWM_POINT_AS_WDT GENMASK(23, 16)
+#define PWM_FALLING_POINT GENMASK(15, 8)
+#define PWM_RISING_POINT GENMASK(7, 0)
+
+/* PWM fixed value */
+#define PWM_FIXED_PERIOD 0xff
+
+struct aspeed_pwm_data {
+	struct pwm_chip chip;
+	struct clk *clk;
+	struct regmap *regmap;
+	struct reset_control *reset;
+};
+
+static void aspeed_set_pwm_channel_enable(struct regmap *regmap, u8 pwm_channel,
+					  bool enable)
+{
+	regmap_update_bits(regmap, PWM_ASPEED_CTRL_CH(pwm_channel),
+			   (PWM_CLK_ENABLE | PWM_PIN_ENABLE),
+			   enable ? (PWM_CLK_ENABLE | PWM_PIN_ENABLE) : 0);
+}
+/*
+ * The PWM frequency = HCLK(200Mhz) / (clock division L bit *
+ * clock division H bit * (period bit + 1))
+ */
+static void aspeed_set_pwm_freq(struct aspeed_pwm_data *priv,
+				struct pwm_device *pwm, u32 freq)
+{
+	u32 target_div, freq_a_fix_div, out_freq;
+	u32 tmp_div_h, tmp_div_l, diff, min_diff = INT_MAX;
+	u32 div_h = BIT(5) - 1, div_l = BIT(8) - 1;
+	u8 div_found;
+	u32 index = pwm->hwpwm;
+	/* Frequency after fixed divide */
+	freq_a_fix_div = clk_get_rate(priv->clk) / (PWM_FIXED_PERIOD + 1);
+	/*
+	 * Use round up to avoid 0 case.
+	 * After that the only scenario which can't find divide pair is too slow
+	 */
+	target_div = DIV_ROUND_UP(freq_a_fix_div, freq);
+	div_found = 0;
+	/* calculate for target frequency */
+	for (tmp_div_h = 0; tmp_div_h < 0x10; tmp_div_h++) {
+		tmp_div_l = target_div / BIT(tmp_div_h) - 1;
+
+		if (tmp_div_l < 0 || tmp_div_l > 255)
+			continue;
+
+		diff = freq - ((freq_a_fix_div >> tmp_div_h) / (tmp_div_l + 1));
+		if (abs(diff) < abs(min_diff)) {
+			min_diff = diff;
+			div_l = tmp_div_l;
+			div_h = tmp_div_h;
+			div_found = 1;
+			if (diff == 0)
+				break;
+		}
+	}
+	if (div_found == 0) {
+		pr_debug("target freq: %d too slow set minimal frequency\n",
+			 freq);
+	}
+	out_freq = freq_a_fix_div / (BIT(div_h) * (div_l + 1));
+	pr_debug("div h %x, l : %x\n", div_h, div_l);
+	pr_debug("hclk %ld, target pwm freq %d, real pwm freq %d\n",
+		 clk_get_rate(priv->clk), freq, out_freq);
+
+	regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL_CH(index),
+			   (PWM_CLK_DIV_H | PWM_CLK_DIV_L),
+			   FIELD_PREP(PWM_CLK_DIV_H, div_h) |
+				   FIELD_PREP(PWM_CLK_DIV_L, div_l));
+}
+
+static void aspeed_set_pwm_duty(struct aspeed_pwm_data *priv,
+				struct pwm_device *pwm, u32 duty_pt)
+{
+	u32 index = pwm->hwpwm;
+
+	if (duty_pt == 0) {
+		aspeed_set_pwm_channel_enable(priv->regmap, index, false);
+	} else {
+		regmap_update_bits(priv->regmap,
+				   PWM_ASPEED_DUTY_CYCLE_CH(index),
+				   PWM_FALLING_POINT,
+				   FIELD_PREP(PWM_FALLING_POINT, duty_pt));
+		aspeed_set_pwm_channel_enable(priv->regmap, index, true);
+	}
+}
+
+static void aspeed_set_pwm_polarity(struct aspeed_pwm_data *priv,
+				    struct pwm_device *pwm, u8 polarity)
+{
+	u32 index = pwm->hwpwm;
+
+	regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL_CH(index), PWM_INVERSE,
+			   (polarity) ? PWM_INVERSE : 0);
+}
+
+static int aspeed_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct device *dev = chip->dev;
+	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
+	struct pwm_state *channel;
+	u32 index = pwm->hwpwm;
+	/*
+	 * Fixed the period to the max value and rising point to 0
+	 * for high resolution and simplified frequency calculation.
+	 */
+	regmap_update_bits(priv->regmap, PWM_ASPEED_DUTY_CYCLE_CH(index),
+			   PWM_PERIOD,
+			   FIELD_PREP(PWM_PERIOD, PWM_FIXED_PERIOD));
+
+	regmap_update_bits(priv->regmap, PWM_ASPEED_DUTY_CYCLE_CH(index),
+			   PWM_RISING_POINT, 0);
+
+	channel = kzalloc(sizeof(*channel), GFP_KERNEL);
+	if (!channel)
+		return -ENOMEM;
+
+	return pwm_set_chip_data(pwm, channel);
+}
+
+static void aspeed_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+	struct pwm_state *channel = pwm_get_chip_data(pwm);
+
+	kfree(channel);
+}
+
+static inline struct aspeed_pwm_data *
+aspeed_pwm_chip_to_data(struct pwm_chip *c)
+{
+	return container_of(c, struct aspeed_pwm_data, chip);
+}
+
+static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			    const struct pwm_state *state)
+{
+	struct device *dev = chip->dev;
+	struct aspeed_pwm_data *priv = aspeed_pwm_chip_to_data(chip);
+	struct pwm_state *channel = pwm_get_chip_data(pwm);
+	/* compute the ns to Hz */
+	u32 freq = DIV_ROUND_UP_ULL(1000000000, state->period);
+	u32 duty_pt = DIV_ROUND_UP_ULL(
+		state->duty_cycle * (PWM_FIXED_PERIOD + 1), state->period);
+	dev_dbg(dev, "freq: %d, duty_pt: %d", freq, duty_pt);
+	if (state->enabled) {
+		aspeed_set_pwm_freq(priv, pwm, freq);
+		aspeed_set_pwm_duty(priv, pwm, duty_pt);
+		aspeed_set_pwm_polarity(priv, pwm, state->polarity);
+	} else {
+		aspeed_set_pwm_duty(priv, pwm, 0);
+	}
+	channel->period = state->period;
+	channel->duty_cycle = state->duty_cycle;
+	channel->polarity = state->polarity;
+	channel->enabled = state->enabled;
+
+	return 0;
+}
+
+static void aspeed_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+				 struct pwm_state *state)
+{
+	struct pwm_state *channel = pwm_get_chip_data(pwm);
+
+	state->period = channel->period;
+	state->duty_cycle = channel->duty_cycle;
+	state->polarity = channel->polarity;
+	state->enabled = channel->enabled;
+}
+
+static const struct pwm_ops aspeed_pwm_ops = {
+	.request = aspeed_pwm_request,
+	.free = aspeed_pwm_free,
+	.apply = aspeed_pwm_apply,
+	.get_state = aspeed_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int aspeed_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	int ret;
+	struct aspeed_pwm_data *priv;
+	struct device_node *np;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	np = pdev->dev.parent->of_node;
+	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach")) {
+		dev_err(dev, "unsupported pwm device binding\n");
+		return -ENODEV;
+	}
+
+	priv->regmap = syscon_node_to_regmap(np);
+	if (IS_ERR(priv->regmap)) {
+		dev_err(dev, "Couldn't get regmap\n");
+		return -ENODEV;
+	}
+
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk))
+		return -ENODEV;
+
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(dev, "couldn't enable clock\n");
+		return ret;
+	}
+
+	priv->reset = reset_control_get_shared(dev, NULL);
+	if (IS_ERR(priv->reset)) {
+		dev_err(dev, "can't get aspeed_pwm_tacho reset: %pe\n",
+			ERR_PTR((long)priv->reset));
+		return PTR_ERR(priv->reset);
+	}
+
+	ret = reset_control_deassert(priv->reset);
+	if (ret) {
+		dev_err(&pdev->dev, "cannot deassert reset control: %pe\n",
+			ERR_PTR(ret));
+		return ret;
+	}
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &aspeed_pwm_ops;
+	priv->chip.npwm = PWM_ASPEED_NR_PWMS;
+	priv->chip.of_xlate = of_pwm_xlate_with_flags;
+	priv->chip.of_pwm_n_cells = 3;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0) {
+		dev_err(dev, "failed to add PWM chip: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+	dev_set_drvdata(dev, priv);
+	return ret;
+}
+
+static int aspeed_pwm_remove(struct platform_device *dev)
+{
+	struct aspeed_pwm_data *priv = platform_get_drvdata(dev);
+
+	reset_control_assert(priv->reset);
+	clk_disable_unprepare(priv->clk);
+
+	return pwmchip_remove(&priv->chip);
+}
+
+static const struct of_device_id of_pwm_match_table[] = {
+	{
+		.compatible = "aspeed,ast2600-pwm",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_match_table);
+
+static struct platform_driver aspeed_pwm_driver = {
+	.probe		= aspeed_pwm_probe,
+	.remove		= aspeed_pwm_remove,
+	.driver		= {
+		.name	= "aspeed_pwm",
+		.of_match_table = of_pwm_match_table,
+	},
+};
+
+module_platform_driver(aspeed_pwm_driver);
+
+MODULE_AUTHOR("Billy Tsai <billy_tsai at aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED PWM device driver");
+MODULE_LICENSE("GPL v2");
-- 
2.25.1



From billy_tsai at aspeedtech.com  Wed Apr 14 11:49:38 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Wed, 14 Apr 2021 18:49:38 +0800
Subject: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
In-Reply-To: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
Message-ID: <20210414104939.1093-2-billy_tsai@aspeedtech.com>

This patch adds device bindings for aspeed pwm-tach device which is a
multi-function device include pwn and tach function and pwm device which
should be the sub-node of pwm-tach device.

Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545
---
 .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++++++++++++++++++
 .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 44 ++++++++++++++
 2 files changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
 create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml

diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
new file mode 100644
index 000000000000..eaf8bdf8d44e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 ASPEED, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Tach controller Device Tree Bindings
+
+description: |
+  The PWM Tach controller is represented as a multi-function device which
+  includes:
+    PWM
+    Tach
+
+maintainers:
+  - Billy Tsai <billy_tsai at aspeedtech.com>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - aspeed,ast2600-pwm-tach
+      - const: syscon
+      - const: simple-mfd
+  reg:
+    maxItems: 1
+  "#address-cells":
+    const: 1
+  "#size-cells":
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties:
+  type: object
+
+examples:
+  - |
+    pwm_tach: pwm_tach at 1e610000 {
+      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
+      #address-cells = <1>;
+      #size-cells = <1>;
+      reg = <0x1e610000 0x100>;
+
+      pwm: pwm at 0 {
+        compatible = "aspeed,ast2600-pwm";
+        #pwm-cells = <3>;
+        reg = <0x0 0x100>;
+      };
+
+      tach: tach at 1 {
+        compatible = "aspeed,ast2600-tach";
+        reg = <0x0 0x100>;
+      };
+    };
diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
new file mode 100644
index 000000000000..97923e68ccb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 ASPEED, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 PWM controller
+
+maintainers:
+  - Billy Tsai <billy_tsai at aspeedtech.com>
+
+description: |
+  The ASPEED PWM controller can support upto 16 PWM outputs.
+
+properties:
+  compatible:
+    enum:
+      - aspeed,ast2600-pwm
+
+  "#pwm-cells":
+    const: 3
+
+  reg:
+    maxItems: 1
+
+additionalProperties: false
+
+examples:
+  - |
+    // The PWM should be a subnode of a "aspeed,ast2600-pwm-tach" compatible
+    // node.
+    pwm_tach: pwm_tach at 1e610000 {
+      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
+      #address-cells = <1>;
+      #size-cells = <1>;
+      reg = <0x1e610000 0x100>;
+
+      pwm: pwm at 0 {
+        compatible = "aspeed,ast2600-pwm";
+        #pwm-cells = <3>;
+        reg = <0x0 0x100>;
+      };
+    };
-- 
2.25.1



From linux at roeck-us.net  Wed Apr 14 12:23:36 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 14 Apr 2021 04:23:36 -0700
Subject: [PATCH V2] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1618385339-3527-1-git-send-email-wangqing@vivo.com>
References: <1618385339-3527-1-git-send-email-wangqing@vivo.com>
Message-ID: <427a4dc7-3528-83c6-b951-8ca0b2ca09a3@roeck-us.net>

On 4/14/21 12:28 AM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> By default, the pretimeout notification shall occur one second earlier
> than the timeout.
> 
> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 57 ++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 52 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..b0ec933
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -234,18 +235,41 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>  	int ret;
>  
> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>  	if (ret < 0)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	reg &= ~WDT_MODE_IRQ_EN;
> +	if (wdt_dev->pretimeout)
> +		reg |= WDT_MODE_IRQ_EN;
> +	else
> +		reg &= ~WDT_MODE_IRQ_EN;
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
> 


You said previously that the pretimeout would prevent the real timeout / reset
from happening, and the driver has no provision to set the real timeout.
That makes this a no-go.

>  	return 0;
>  }
>  
> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> +				   unsigned int timeout)
> +{
> +	wdd->pretimeout = timeout;
> +	return mtk_wdt_start(wdd);
> +}
> +
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +if (IS_ENABLED(CONFIG_WATCHDOG_PRETIMEOUT_GOV))
> +	watchdog_notify_pretimeout(wdd);
> +else
> +	//panic by decault instead of WDT_SWRST;
> +	panic("MTk Watchdog bark!\n");
> +
The idea behind the pretimeout governor is that it can be disabled
by setting it to "none", and if pretimeout governors are disabled
it is supposed to be a no-op. The above bypasses this mechanism
and is not acceptable.

This suggests that the real timeout indeed doesn't happen when
WDT_MODE_IRQ_EN is set. Again, this is unacceptable.

On a side note, formatting is way off here.

Guenter

> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,12 +277,21 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
>  	.stop		= mtk_wdt_stop,
>  	.ping		= mtk_wdt_ping,
>  	.set_timeout	= mtk_wdt_set_timeout,
> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>  	.restart	= mtk_wdt_restart,
>  };
>  
> @@ -267,7 +300,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +312,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +								&mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = 1;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> @@ -360,7 +408,6 @@ static struct platform_driver mtk_wdt_driver = {
>  };
>  
>  module_platform_driver(mtk_wdt_driver);
> -
>  module_param(timeout, uint, 0);
>  MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
>  
> 



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:22:56 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:22:56 +0100
Subject: [PATCH v4 00/16] kvm/arm: Align the VMID allocation with the arm64
 ASID one
Message-ID: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>

Hi,

This is an attempt to revive this series originally posted by
Julien Grall[1]. The main motive to work on this now is because
of the requirement to have Pinned KVM VMIDs and the RFC discussion
for the same basically suggested[2] to have a common/better vmid
allocator for KVM which this series provides.
 
Major Changes from v3:

-Changes related to Pinned ASID support.
-Changes to take care KPTI related bits reservation.
-Dropped support for 32 bit KVM.
-Rebase to 5.12-rc7

Individual patches have change history for any major changes
from v3.

Tests were performed on a HiSilicon D06 platform and so far not observed
any regressions.

For ASID allocation,

Avg of 10 runs(hackbench -s 512 -l 200 -g 300 -f 25 -P),
5.12-rc7: Time:18.8119
5.12-rc7+v4: Time: 18.459

~1.8% improvement.

For KVM VMID,

The measurement was made with maxcpus set to 8 and with the
number of VMID limited to 4-bit. The test involves running
concurrently 40 guests with 2 vCPUs. Each guest will then
execute hackbench 5 times before exiting.

The performance difference between the current algo and the
new one are(ag. of 10 runs):
    - 1.9% less exit from the guest
    - 0.7% faster

For complete series, please see,
 https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4

Please take a look and let me know your feedback.

Thanks,
Shameer
[1].https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190724162534.7390-1-julien.grall at arm.com/
[2].https://lore.kernel.org/linux-arm-kernel/20210222155338.26132-6-shameerali.kolothum.thodi at huawei.com/T/#mff3129997739e2747172f4a2e81fd66be91ffea4
--------
>From V3:
--------
Hi all,

This patch series is moving out the ASID allocator in a separate file in order
to re-use it for the VMID. The benefits are:
    - CPUs are not forced to exit on a roll-over.
    - Context invalidation is now per-CPU rather than
      broadcasted.

There are no performance regression on the fastpath for ASID allocation.
Actually on the hackbench measurement (300 hackbench) it was .7% faster.

The measurement was made on a Seattle based SoC (8 CPUs), with the
number of VMID limited to 4-bit. The test involves running concurrently 40
guests with 2 vCPUs. Each guest will then execute hackbench 5 times
before exiting.

The performance difference (on 5.1-rc1) between the current algo and the
new one are:
    - 2.5% less exit from the guest
    - 22.4% more flush, although they are now local rather than broadcasted
    - 0.11% faster (just for the record)

The ASID allocator rework to make it generic has been divided in multiple
patches to make the review easier.

A branch with the patch based on 5.3-rc1 can be found:

http://xenbits.xen.org/gitweb/?p=people/julieng/linux-arm.git;a=shortlog;h=refs/heads/vmid-rework/v3

For all the changes see in each patch.

Best regards,

Julien Grall (13):
  arm64/mm: Introduce asid_info structure and move
    asid_generation/asid_map to it
  arm64/mm: Move active_asids and reserved_asids to asid_info
  arm64/mm: Move bits to asid_info
  arm64/mm: Move the variable lock and tlb_flush_pending to asid_info
  arm64/mm: Remove dependency on MM in new_context
  arm64/mm: Introduce NUM_CTXT_ASIDS
  arm64/mm: Split asid_inits in 2 parts
  arm64/mm: Split the function check_and_switch_context in 3 parts
  arm64/mm: Introduce a callback to flush the local context
  arm64: Move the ASID allocator code in a separate file
  arm64/lib: Add an helper to free memory allocated by the ASID
    allocator
  arch/arm64: Introduce a capability to tell whether 16-bit VMID is
    available
  kvm/arm: Align the VMID allocation with the arm64 ASID one

Shameer Kolothum (3):
  arm64/mm: Move Pinned ASID related variables to asid_info
  arm64/mm: Split the arm64_mm_context_get/put
  arm64/mm: Introduce a callback to set reserved bits

 arch/arm64/include/asm/cpucaps.h   |   3 +-
 arch/arm64/include/asm/kvm_asm.h   |   4 +-
 arch/arm64/include/asm/kvm_host.h  |   5 +-
 arch/arm64/include/asm/kvm_mmu.h   |   7 +-
 arch/arm64/include/asm/lib_asid.h  |  87 +++++++++
 arch/arm64/kernel/cpufeature.c     |   9 +
 arch/arm64/kvm/arm.c               | 124 +++++--------
 arch/arm64/kvm/hyp/nvhe/hyp-main.c |   6 +-
 arch/arm64/kvm/hyp/nvhe/tlb.c      |  10 +-
 arch/arm64/kvm/hyp/vhe/tlb.c       |  10 +-
 arch/arm64/kvm/mmu.c               |   1 -
 arch/arm64/lib/Makefile            |   2 +
 arch/arm64/lib/asid.c              | 264 +++++++++++++++++++++++++++
 arch/arm64/mm/context.c            | 283 ++++-------------------------
 14 files changed, 469 insertions(+), 346 deletions(-)
 create mode 100644 arch/arm64/include/asm/lib_asid.h
 create mode 100644 arch/arm64/lib/asid.c

-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:22:57 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:22:57 +0100
Subject: [PATCH v4 01/16] arm64/mm: Introduce asid_info structure and move
 asid_generation/asid_map to it
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-2-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

In an attempt to make the ASID allocator generic, create a new structure
asid_info to store all the information necessary for the allocator.

For now, move the variables asid_generation, asid_map, cur_idx to the
new structure asid_info. Follow-up patches will move more variables.

Note to avoid more renaming aftwards, a local variable 'info' has been
created and is a pointer to the ASID allocator structure.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3-->v4:
  Move cur_idx into asid_info.
---
 arch/arm64/mm/context.c | 71 +++++++++++++++++++++++------------------
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 001737a8f309..783f8bdb91ee 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -20,8 +20,12 @@
 static u32 asid_bits;
 static DEFINE_RAW_SPINLOCK(cpu_asid_lock);
 
-static atomic64_t asid_generation;
-static unsigned long *asid_map;
+static struct asid_info
+{
+	atomic64_t	generation;
+	unsigned long	*map;
+	unsigned int	map_idx;
+} asid_info;
 
 static DEFINE_PER_CPU(atomic64_t, active_asids);
 static DEFINE_PER_CPU(u64, reserved_asids);
@@ -88,26 +92,26 @@ static void set_kpti_asid_bits(unsigned long *map)
 	memset(map, 0xaa, len);
 }
 
-static void set_reserved_asid_bits(void)
+static void set_reserved_asid_bits(struct asid_info *info)
 {
 	if (pinned_asid_map)
-		bitmap_copy(asid_map, pinned_asid_map, NUM_USER_ASIDS);
+		bitmap_copy(info->map, pinned_asid_map, NUM_USER_ASIDS);
 	else if (arm64_kernel_unmapped_at_el0())
-		set_kpti_asid_bits(asid_map);
+		set_kpti_asid_bits(info->map);
 	else
-		bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+		bitmap_clear(info->map, 0, NUM_USER_ASIDS);
 }
 
-#define asid_gen_match(asid) \
-	(!(((asid) ^ atomic64_read(&asid_generation)) >> asid_bits))
+#define asid_gen_match(asid, info) \
+	(!(((asid) ^ atomic64_read(&(info)->generation)) >> asid_bits))
 
-static void flush_context(void)
+static void flush_context(struct asid_info *info)
 {
 	int i;
 	u64 asid;
 
 	/* Update the list of reserved ASIDs and the ASID bitmap. */
-	set_reserved_asid_bits();
+	set_reserved_asid_bits(info);
 
 	for_each_possible_cpu(i) {
 		asid = atomic64_xchg_relaxed(&per_cpu(active_asids, i), 0);
@@ -120,7 +124,7 @@ static void flush_context(void)
 		 */
 		if (asid == 0)
 			asid = per_cpu(reserved_asids, i);
-		__set_bit(asid2idx(asid), asid_map);
+		__set_bit(asid2idx(asid), info->map);
 		per_cpu(reserved_asids, i) = asid;
 	}
 
@@ -155,11 +159,10 @@ static bool check_update_reserved_asid(u64 asid, u64 newasid)
 	return hit;
 }
 
-static u64 new_context(struct mm_struct *mm)
+static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 {
-	static u32 cur_idx = 1;
 	u64 asid = atomic64_read(&mm->context.id);
-	u64 generation = atomic64_read(&asid_generation);
+	u64 generation = atomic64_read(&info->generation);
 
 	if (asid != 0) {
 		u64 newasid = generation | (asid & ~ASID_MASK);
@@ -183,7 +186,7 @@ static u64 new_context(struct mm_struct *mm)
 		 * We had a valid ASID in a previous life, so try to re-use
 		 * it if possible.
 		 */
-		if (!__test_and_set_bit(asid2idx(asid), asid_map))
+		if (!__test_and_set_bit(asid2idx(asid), info->map))
 			return newasid;
 	}
 
@@ -194,21 +197,21 @@ static u64 new_context(struct mm_struct *mm)
 	 * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
 	 * pairs.
 	 */
-	asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, cur_idx);
+	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS, info->map_idx);
 	if (asid != NUM_USER_ASIDS)
 		goto set_asid;
 
 	/* We're out of ASIDs, so increment the global generation count */
 	generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION,
-						 &asid_generation);
-	flush_context();
+						 &info->generation);
+	flush_context(info);
 
 	/* We have more ASIDs than CPUs, so this will always succeed */
-	asid = find_next_zero_bit(asid_map, NUM_USER_ASIDS, 1);
+	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS, 1);
 
 set_asid:
-	__set_bit(asid, asid_map);
-	cur_idx = asid;
+	__set_bit(asid, info->map);
+	info->map_idx = asid;
 	return idx2asid(asid) | generation;
 }
 
@@ -217,6 +220,7 @@ void check_and_switch_context(struct mm_struct *mm)
 	unsigned long flags;
 	unsigned int cpu;
 	u64 asid, old_active_asid;
+	struct asid_info *info = &asid_info;
 
 	if (system_supports_cnp())
 		cpu_set_reserved_ttbr0();
@@ -238,7 +242,7 @@ void check_and_switch_context(struct mm_struct *mm)
 	 *   because atomic RmWs are totally ordered for a given location.
 	 */
 	old_active_asid = atomic64_read(this_cpu_ptr(&active_asids));
-	if (old_active_asid && asid_gen_match(asid) &&
+	if (old_active_asid && asid_gen_match(asid, info) &&
 	    atomic64_cmpxchg_relaxed(this_cpu_ptr(&active_asids),
 				     old_active_asid, asid))
 		goto switch_mm_fastpath;
@@ -246,8 +250,8 @@ void check_and_switch_context(struct mm_struct *mm)
 	raw_spin_lock_irqsave(&cpu_asid_lock, flags);
 	/* Check that our ASID belongs to the current generation. */
 	asid = atomic64_read(&mm->context.id);
-	if (!asid_gen_match(asid)) {
-		asid = new_context(mm);
+	if (!asid_gen_match(asid, info)) {
+		asid = new_context(info, mm);
 		atomic64_set(&mm->context.id, asid);
 	}
 
@@ -274,6 +278,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 {
 	unsigned long flags;
 	u64 asid;
+	struct asid_info *info = &asid_info;
 
 	if (!pinned_asid_map)
 		return 0;
@@ -290,12 +295,12 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 		goto out_unlock;
 	}
 
-	if (!asid_gen_match(asid)) {
+	if (!asid_gen_match(asid, info)) {
 		/*
 		 * We went through one or more rollover since that ASID was
 		 * used. Ensure that it is still valid, or generate a new one.
 		 */
-		asid = new_context(mm);
+		asid = new_context(info, mm);
 		atomic64_set(&mm->context.id, asid);
 	}
 
@@ -400,14 +405,18 @@ arch_initcall(asids_update_limit);
 
 static int asids_init(void)
 {
+	struct asid_info *info = &asid_info;
+
 	asid_bits = get_cpu_asid_bits();
-	atomic64_set(&asid_generation, ASID_FIRST_VERSION);
-	asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS), sizeof(*asid_map),
-			   GFP_KERNEL);
-	if (!asid_map)
+	atomic64_set(&info->generation, ASID_FIRST_VERSION);
+	info->map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS), sizeof(*info->map),
+			    GFP_KERNEL);
+	if (!info->map)
 		panic("Failed to allocate bitmap for %lu ASIDs\n",
 		      NUM_USER_ASIDS);
 
+	info->map_idx = 1;
+
 	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS),
 				  sizeof(*pinned_asid_map), GFP_KERNEL);
 	nr_pinned_asids = 0;
@@ -418,7 +427,7 @@ static int asids_init(void)
 	 * and reserve kernel ASID's from beginning.
 	 */
 	if (IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0))
-		set_kpti_asid_bits(asid_map);
+		set_kpti_asid_bits(info->map);
 	return 0;
 }
 early_initcall(asids_init);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:22:58 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:22:58 +0100
Subject: [PATCH v4 02/16] arm64/mm: Move active_asids and reserved_asids to
 asid_info
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-3-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

The variables active_asids and reserved_asids hold information for a
given ASID allocator. So move them to the structure asid_info.

At the same time, introduce wrappers to access the active and reserved
ASIDs to make the code clearer.


Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3-->v4
  keep the this_cpu_ptr in fastpath. See c4885bbb3afe("arm64/mm: save
memory access in check_and_switch_context() fast switch path")

---
 arch/arm64/mm/context.c | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 783f8bdb91ee..42e011094571 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -25,8 +25,13 @@ static struct asid_info
 	atomic64_t	generation;
 	unsigned long	*map;
 	unsigned int	map_idx;
+	atomic64_t __percpu	*active;
+	u64 __percpu		*reserved;
 } asid_info;
 
+#define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
+#define reserved_asid(info, cpu) (*per_cpu_ptr((info)->reserved, cpu))
+
 static DEFINE_PER_CPU(atomic64_t, active_asids);
 static DEFINE_PER_CPU(u64, reserved_asids);
 static cpumask_t tlb_flush_pending;
@@ -114,7 +119,7 @@ static void flush_context(struct asid_info *info)
 	set_reserved_asid_bits(info);
 
 	for_each_possible_cpu(i) {
-		asid = atomic64_xchg_relaxed(&per_cpu(active_asids, i), 0);
+		asid = atomic64_xchg_relaxed(&active_asid(info, i), 0);
 		/*
 		 * If this CPU has already been through a
 		 * rollover, but hasn't run another task in
@@ -123,9 +128,9 @@ static void flush_context(struct asid_info *info)
 		 * the process it is still running.
 		 */
 		if (asid == 0)
-			asid = per_cpu(reserved_asids, i);
+			asid = reserved_asid(info, i);
 		__set_bit(asid2idx(asid), info->map);
-		per_cpu(reserved_asids, i) = asid;
+		reserved_asid(info, i) = asid;
 	}
 
 	/*
@@ -135,7 +140,8 @@ static void flush_context(struct asid_info *info)
 	cpumask_setall(&tlb_flush_pending);
 }
 
-static bool check_update_reserved_asid(u64 asid, u64 newasid)
+static bool check_update_reserved_asid(struct asid_info *info, u64 asid,
+				       u64 newasid)
 {
 	int cpu;
 	bool hit = false;
@@ -150,9 +156,9 @@ static bool check_update_reserved_asid(u64 asid, u64 newasid)
 	 * generation.
 	 */
 	for_each_possible_cpu(cpu) {
-		if (per_cpu(reserved_asids, cpu) == asid) {
+		if (reserved_asid(info, cpu) == asid) {
 			hit = true;
-			per_cpu(reserved_asids, cpu) = newasid;
+			reserved_asid(info, cpu) = newasid;
 		}
 	}
 
@@ -171,7 +177,7 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 		 * If our current ASID was active during a rollover, we
 		 * can continue to use it and this was just a false alarm.
 		 */
-		if (check_update_reserved_asid(asid, newasid))
+		if (check_update_reserved_asid(info, asid, newasid))
 			return newasid;
 
 		/*
@@ -229,8 +235,8 @@ void check_and_switch_context(struct mm_struct *mm)
 
 	/*
 	 * The memory ordering here is subtle.
-	 * If our active_asids is non-zero and the ASID matches the current
-	 * generation, then we update the active_asids entry with a relaxed
+	 * If our active_asid is non-zero and the ASID matches the current
+	 * generation, then we update the active_asid entry with a relaxed
 	 * cmpxchg. Racing with a concurrent rollover means that either:
 	 *
 	 * - We get a zero back from the cmpxchg and end up waiting on the
@@ -241,9 +247,9 @@ void check_and_switch_context(struct mm_struct *mm)
 	 *   relaxed xchg in flush_context will treat us as reserved
 	 *   because atomic RmWs are totally ordered for a given location.
 	 */
-	old_active_asid = atomic64_read(this_cpu_ptr(&active_asids));
+	old_active_asid = atomic64_read(this_cpu_ptr(info->active));
 	if (old_active_asid && asid_gen_match(asid, info) &&
-	    atomic64_cmpxchg_relaxed(this_cpu_ptr(&active_asids),
+	    atomic64_cmpxchg_relaxed(this_cpu_ptr(info->active),
 				     old_active_asid, asid))
 		goto switch_mm_fastpath;
 
@@ -259,7 +265,7 @@ void check_and_switch_context(struct mm_struct *mm)
 	if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending))
 		local_flush_tlb_all();
 
-	atomic64_set(this_cpu_ptr(&active_asids), asid);
+	atomic64_set(&active_asid(info, cpu), asid);
 	raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
 
 switch_mm_fastpath:
@@ -416,6 +422,8 @@ static int asids_init(void)
 		      NUM_USER_ASIDS);
 
 	info->map_idx = 1;
+	info->active = &active_asids;
+	info->reserved = &reserved_asids;
 
 	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS),
 				  sizeof(*pinned_asid_map), GFP_KERNEL);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:22:59 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:22:59 +0100
Subject: [PATCH v4 03/16] arm64/mm: Move bits to asid_info
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-4-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

The variable bits hold information for a given ASID allocator. So move
it to the asid_info structure.

Because most of the macros were relying on bits, they are now taking an
extra parameter that is a pointer to the asid_info structure.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 70 +++++++++++++++++++++--------------------
 1 file changed, 36 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 42e011094571..1fd40a42955c 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -17,7 +17,6 @@
 #include <asm/smp.h>
 #include <asm/tlbflush.h>
 
-static u32 asid_bits;
 static DEFINE_RAW_SPINLOCK(cpu_asid_lock);
 
 static struct asid_info
@@ -27,6 +26,7 @@ static struct asid_info
 	unsigned int	map_idx;
 	atomic64_t __percpu	*active;
 	u64 __percpu		*reserved;
+	u32			bits;
 } asid_info;
 
 #define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
@@ -40,12 +40,12 @@ static unsigned long max_pinned_asids;
 static unsigned long nr_pinned_asids;
 static unsigned long *pinned_asid_map;
 
-#define ASID_MASK		(~GENMASK(asid_bits - 1, 0))
-#define ASID_FIRST_VERSION	(1UL << asid_bits)
+#define ASID_MASK(info)			(~GENMASK((info)->bits - 1, 0))
+#define ASID_FIRST_VERSION(info)	(1UL << (info)->bits)
 
-#define NUM_USER_ASIDS		ASID_FIRST_VERSION
-#define asid2idx(asid)		((asid) & ~ASID_MASK)
-#define idx2asid(idx)		asid2idx(idx)
+#define NUM_USER_ASIDS(info)		ASID_FIRST_VERSION(info)
+#define asid2idx(info, asid)		((asid) & ~ASID_MASK(info))
+#define idx2asid(info, idx)		asid2idx(info, idx)
 
 /* Get the ASIDBits supported by the current CPU */
 static u32 get_cpu_asid_bits(void)
@@ -74,20 +74,20 @@ void verify_cpu_asid_bits(void)
 {
 	u32 asid = get_cpu_asid_bits();
 
-	if (asid < asid_bits) {
+	if (asid < asid_info.bits) {
 		/*
 		 * We cannot decrease the ASID size at runtime, so panic if we support
 		 * fewer ASID bits than the boot CPU.
 		 */
 		pr_crit("CPU%d: smaller ASID size(%u) than boot CPU (%u)\n",
-				smp_processor_id(), asid, asid_bits);
+				smp_processor_id(), asid, asid_info.bits);
 		cpu_panic_kernel();
 	}
 }
 
-static void set_kpti_asid_bits(unsigned long *map)
+static void set_kpti_asid_bits(struct asid_info *info, unsigned long *map)
 {
-	unsigned int len = BITS_TO_LONGS(NUM_USER_ASIDS) * sizeof(unsigned long);
+	unsigned int len = BITS_TO_LONGS(NUM_USER_ASIDS(info)) * sizeof(unsigned long);
 	/*
 	 * In case of KPTI kernel/user ASIDs are allocated in
 	 * pairs, the bottom bit distinguishes the two: if it
@@ -100,15 +100,15 @@ static void set_kpti_asid_bits(unsigned long *map)
 static void set_reserved_asid_bits(struct asid_info *info)
 {
 	if (pinned_asid_map)
-		bitmap_copy(info->map, pinned_asid_map, NUM_USER_ASIDS);
+		bitmap_copy(info->map, pinned_asid_map, NUM_USER_ASIDS(info));
 	else if (arm64_kernel_unmapped_at_el0())
-		set_kpti_asid_bits(info->map);
+		set_kpti_asid_bits(info, info->map);
 	else
-		bitmap_clear(info->map, 0, NUM_USER_ASIDS);
+		bitmap_clear(info->map, 0, NUM_USER_ASIDS(info));
 }
 
 #define asid_gen_match(asid, info) \
-	(!(((asid) ^ atomic64_read(&(info)->generation)) >> asid_bits))
+	(!(((asid) ^ atomic64_read(&(info)->generation)) >> info->bits))
 
 static void flush_context(struct asid_info *info)
 {
@@ -129,7 +129,7 @@ static void flush_context(struct asid_info *info)
 		 */
 		if (asid == 0)
 			asid = reserved_asid(info, i);
-		__set_bit(asid2idx(asid), info->map);
+		__set_bit(asid2idx(info, asid), info->map);
 		reserved_asid(info, i) = asid;
 	}
 
@@ -171,7 +171,7 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 	u64 generation = atomic64_read(&info->generation);
 
 	if (asid != 0) {
-		u64 newasid = generation | (asid & ~ASID_MASK);
+		u64 newasid = generation | (asid & ~ASID_MASK(info));
 
 		/*
 		 * If our current ASID was active during a rollover, we
@@ -192,7 +192,7 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 		 * We had a valid ASID in a previous life, so try to re-use
 		 * it if possible.
 		 */
-		if (!__test_and_set_bit(asid2idx(asid), info->map))
+		if (!__test_and_set_bit(asid2idx(info, asid), info->map))
 			return newasid;
 	}
 
@@ -203,22 +203,22 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 	 * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
 	 * pairs.
 	 */
-	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS, info->map_idx);
-	if (asid != NUM_USER_ASIDS)
+	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS(info), info->map_idx);
+	if (asid != NUM_USER_ASIDS(info))
 		goto set_asid;
 
 	/* We're out of ASIDs, so increment the global generation count */
-	generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION,
+	generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION(info),
 						 &info->generation);
 	flush_context(info);
 
 	/* We have more ASIDs than CPUs, so this will always succeed */
-	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS, 1);
+	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS(info), 1);
 
 set_asid:
 	__set_bit(asid, info->map);
 	info->map_idx = asid;
-	return idx2asid(asid) | generation;
+	return idx2asid(info, asid) | generation;
 }
 
 void check_and_switch_context(struct mm_struct *mm)
@@ -311,13 +311,13 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 	}
 
 	nr_pinned_asids++;
-	__set_bit(asid2idx(asid), pinned_asid_map);
+	__set_bit(asid2idx(info, asid), pinned_asid_map);
 	refcount_set(&mm->context.pinned, 1);
 
 out_unlock:
 	raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
 
-	asid &= ~ASID_MASK;
+	asid &= ~ASID_MASK(info);
 
 	/* Set the equivalent of USER_ASID_BIT */
 	if (asid && arm64_kernel_unmapped_at_el0())
@@ -330,6 +330,7 @@ EXPORT_SYMBOL_GPL(arm64_mm_context_get);
 void arm64_mm_context_put(struct mm_struct *mm)
 {
 	unsigned long flags;
+	struct asid_info *info = &asid_info;
 	u64 asid = atomic64_read(&mm->context.id);
 
 	if (!pinned_asid_map)
@@ -338,7 +339,7 @@ void arm64_mm_context_put(struct mm_struct *mm)
 	raw_spin_lock_irqsave(&cpu_asid_lock, flags);
 
 	if (refcount_dec_and_test(&mm->context.pinned)) {
-		__clear_bit(asid2idx(asid), pinned_asid_map);
+		__clear_bit(asid2idx(info, asid), pinned_asid_map);
 		nr_pinned_asids--;
 	}
 
@@ -384,12 +385,13 @@ void cpu_do_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm)
 
 static int asids_update_limit(void)
 {
-	unsigned long num_available_asids = NUM_USER_ASIDS;
+	struct asid_info *info = &asid_info;
+	unsigned long num_available_asids = NUM_USER_ASIDS(info);
 
 	if (arm64_kernel_unmapped_at_el0()) {
 		num_available_asids /= 2;
 		if (pinned_asid_map)
-			set_kpti_asid_bits(pinned_asid_map);
+			set_kpti_asid_bits(info, pinned_asid_map);
 	}
 	/*
 	 * Expect allocation after rollover to fail if we don't have at least
@@ -413,19 +415,19 @@ static int asids_init(void)
 {
 	struct asid_info *info = &asid_info;
 
-	asid_bits = get_cpu_asid_bits();
-	atomic64_set(&info->generation, ASID_FIRST_VERSION);
-	info->map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS), sizeof(*info->map),
-			    GFP_KERNEL);
+	info->bits = get_cpu_asid_bits();
+	atomic64_set(&info->generation, ASID_FIRST_VERSION(info));
+	info->map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS(info)),
+			    sizeof(*info->map), GFP_KERNEL);
 	if (!info->map)
 		panic("Failed to allocate bitmap for %lu ASIDs\n",
-		      NUM_USER_ASIDS);
+		      NUM_USER_ASIDS(info));
 
 	info->map_idx = 1;
 	info->active = &active_asids;
 	info->reserved = &reserved_asids;
 
-	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS),
+	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS(info)),
 				  sizeof(*pinned_asid_map), GFP_KERNEL);
 	nr_pinned_asids = 0;
 
@@ -435,7 +437,7 @@ static int asids_init(void)
 	 * and reserve kernel ASID's from beginning.
 	 */
 	if (IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0))
-		set_kpti_asid_bits(info->map);
+		set_kpti_asid_bits(info, info->map);
 	return 0;
 }
 early_initcall(asids_init);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:00 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:00 +0100
Subject: [PATCH v4 04/16] arm64/mm: Move the variable lock and
 tlb_flush_pending to asid_info
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-5-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

The variables lock and tlb_flush_pending holds information for a given
ASID allocator. So move them to the asid_info structure.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 1fd40a42955c..139ebc161acb 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -17,8 +17,6 @@
 #include <asm/smp.h>
 #include <asm/tlbflush.h>
 
-static DEFINE_RAW_SPINLOCK(cpu_asid_lock);
-
 static struct asid_info
 {
 	atomic64_t	generation;
@@ -27,6 +25,9 @@ static struct asid_info
 	atomic64_t __percpu	*active;
 	u64 __percpu		*reserved;
 	u32			bits;
+	raw_spinlock_t		lock;
+	/* Which CPU requires context flush on next call */
+	cpumask_t		flush_pending;
 } asid_info;
 
 #define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
@@ -34,7 +35,6 @@ static struct asid_info
 
 static DEFINE_PER_CPU(atomic64_t, active_asids);
 static DEFINE_PER_CPU(u64, reserved_asids);
-static cpumask_t tlb_flush_pending;
 
 static unsigned long max_pinned_asids;
 static unsigned long nr_pinned_asids;
@@ -137,7 +137,7 @@ static void flush_context(struct asid_info *info)
 	 * Queue a TLB invalidation for each CPU to perform on next
 	 * context-switch
 	 */
-	cpumask_setall(&tlb_flush_pending);
+	cpumask_setall(&info->flush_pending);
 }
 
 static bool check_update_reserved_asid(struct asid_info *info, u64 asid,
@@ -253,7 +253,7 @@ void check_and_switch_context(struct mm_struct *mm)
 				     old_active_asid, asid))
 		goto switch_mm_fastpath;
 
-	raw_spin_lock_irqsave(&cpu_asid_lock, flags);
+	raw_spin_lock_irqsave(&info->lock, flags);
 	/* Check that our ASID belongs to the current generation. */
 	asid = atomic64_read(&mm->context.id);
 	if (!asid_gen_match(asid, info)) {
@@ -262,11 +262,11 @@ void check_and_switch_context(struct mm_struct *mm)
 	}
 
 	cpu = smp_processor_id();
-	if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending))
+	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending))
 		local_flush_tlb_all();
 
 	atomic64_set(&active_asid(info, cpu), asid);
-	raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
+	raw_spin_unlock_irqrestore(&info->lock, flags);
 
 switch_mm_fastpath:
 
@@ -289,7 +289,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 	if (!pinned_asid_map)
 		return 0;
 
-	raw_spin_lock_irqsave(&cpu_asid_lock, flags);
+	raw_spin_lock_irqsave(&info->lock, flags);
 
 	asid = atomic64_read(&mm->context.id);
 
@@ -315,7 +315,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 	refcount_set(&mm->context.pinned, 1);
 
 out_unlock:
-	raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
+	raw_spin_unlock_irqrestore(&info->lock, flags);
 
 	asid &= ~ASID_MASK(info);
 
@@ -336,14 +336,14 @@ void arm64_mm_context_put(struct mm_struct *mm)
 	if (!pinned_asid_map)
 		return;
 
-	raw_spin_lock_irqsave(&cpu_asid_lock, flags);
+	raw_spin_lock_irqsave(&info->lock, flags);
 
 	if (refcount_dec_and_test(&mm->context.pinned)) {
 		__clear_bit(asid2idx(info, asid), pinned_asid_map);
 		nr_pinned_asids--;
 	}
 
-	raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
+	raw_spin_unlock_irqrestore(&info->lock, flags);
 }
 EXPORT_SYMBOL_GPL(arm64_mm_context_put);
 
@@ -426,6 +426,7 @@ static int asids_init(void)
 	info->map_idx = 1;
 	info->active = &active_asids;
 	info->reserved = &reserved_asids;
+	raw_spin_lock_init(&info->lock);
 
 	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS(info)),
 				  sizeof(*pinned_asid_map), GFP_KERNEL);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:01 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:01 +0100
Subject: [PATCH v4 05/16] arm64/mm: Remove dependency on MM in new_context
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-6-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

The function new_context will be part of a generic ASID allocator. At
the moment, the MM structure is currently used to fetch the ASID and
pinned refcount.

To remove the dependency on MM, it is possible to just pass a pointer to
the current ASID and pinned refcount. Also please note that 'pinned' may
be NULL if the user doesn't require the pinned asid support.


Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3-->v4:
  Changes related to Pinned ASID refcount.

---
 arch/arm64/mm/context.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 139ebc161acb..628304e0d3b1 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -165,9 +165,10 @@ static bool check_update_reserved_asid(struct asid_info *info, u64 asid,
 	return hit;
 }
 
-static u64 new_context(struct asid_info *info, struct mm_struct *mm)
+static u64 new_context(struct asid_info *info, atomic64_t *pasid,
+		       refcount_t *pinned)
 {
-	u64 asid = atomic64_read(&mm->context.id);
+	u64 asid = atomic64_read(pasid);
 	u64 generation = atomic64_read(&info->generation);
 
 	if (asid != 0) {
@@ -185,7 +186,7 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm)
 		 * takes priority, because even if it is also pinned, we need to
 		 * update the generation into the reserved_asids.
 		 */
-		if (refcount_read(&mm->context.pinned))
+		if (pinned && refcount_read(pinned))
 			return newasid;
 
 		/*
@@ -257,7 +258,7 @@ void check_and_switch_context(struct mm_struct *mm)
 	/* Check that our ASID belongs to the current generation. */
 	asid = atomic64_read(&mm->context.id);
 	if (!asid_gen_match(asid, info)) {
-		asid = new_context(info, mm);
+		asid = new_context(info, &mm->context.id, &mm->context.pinned);
 		atomic64_set(&mm->context.id, asid);
 	}
 
@@ -306,7 +307,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 		 * We went through one or more rollover since that ASID was
 		 * used. Ensure that it is still valid, or generate a new one.
 		 */
-		asid = new_context(info, mm);
+		asid = new_context(info, &mm->context.id, &mm->context.pinned);
 		atomic64_set(&mm->context.id, asid);
 	}
 
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:03 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:03 +0100
Subject: [PATCH v4 07/16] arm64/mm: Move Pinned ASID related variables to
 asid_info
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-8-shameerali.kolothum.thodi@huawei.com>

The Pinned ASID variables hold information for a given ASID
allocator. So move them to the structure asid_info.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 0f11d7c7f6a3..8af54e06f5bc 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -28,6 +28,10 @@ static struct asid_info
 	raw_spinlock_t		lock;
 	/* Which CPU requires context flush on next call */
 	cpumask_t		flush_pending;
+	/* Pinned ASIDs info */
+	unsigned long		*pinned_map;
+	unsigned long		max_pinned_asids;
+	unsigned long		nr_pinned_asids;
 } asid_info;
 
 #define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
@@ -36,10 +40,6 @@ static struct asid_info
 static DEFINE_PER_CPU(atomic64_t, active_asids);
 static DEFINE_PER_CPU(u64, reserved_asids);
 
-static unsigned long max_pinned_asids;
-static unsigned long nr_pinned_asids;
-static unsigned long *pinned_asid_map;
-
 #define ASID_MASK(info)			(~GENMASK((info)->bits - 1, 0))
 #define NUM_CTXT_ASIDS(info)		(1UL << ((info)->bits))
 #define ASID_FIRST_VERSION(info)        NUM_CTXT_ASIDS(info)
@@ -99,8 +99,8 @@ static void set_kpti_asid_bits(struct asid_info *info, unsigned long *map)
 
 static void set_reserved_asid_bits(struct asid_info *info)
 {
-	if (pinned_asid_map)
-		bitmap_copy(info->map, pinned_asid_map, NUM_CTXT_ASIDS(info));
+	if (info->pinned_map)
+		bitmap_copy(info->map, info->pinned_map, NUM_CTXT_ASIDS(info));
 	else if (arm64_kernel_unmapped_at_el0())
 		set_kpti_asid_bits(info, info->map);
 	else
@@ -287,7 +287,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 	u64 asid;
 	struct asid_info *info = &asid_info;
 
-	if (!pinned_asid_map)
+	if (!info->pinned_map)
 		return 0;
 
 	raw_spin_lock_irqsave(&info->lock, flags);
@@ -297,7 +297,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 	if (refcount_inc_not_zero(&mm->context.pinned))
 		goto out_unlock;
 
-	if (nr_pinned_asids >= max_pinned_asids) {
+	if (info->nr_pinned_asids >= info->max_pinned_asids) {
 		asid = 0;
 		goto out_unlock;
 	}
@@ -311,8 +311,8 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 		atomic64_set(&mm->context.id, asid);
 	}
 
-	nr_pinned_asids++;
-	__set_bit(asid2idx(info, asid), pinned_asid_map);
+	info->nr_pinned_asids++;
+	__set_bit(asid2idx(info, asid), info->pinned_map);
 	refcount_set(&mm->context.pinned, 1);
 
 out_unlock:
@@ -334,14 +334,14 @@ void arm64_mm_context_put(struct mm_struct *mm)
 	struct asid_info *info = &asid_info;
 	u64 asid = atomic64_read(&mm->context.id);
 
-	if (!pinned_asid_map)
+	if (!info->pinned_map)
 		return;
 
 	raw_spin_lock_irqsave(&info->lock, flags);
 
 	if (refcount_dec_and_test(&mm->context.pinned)) {
-		__clear_bit(asid2idx(info, asid), pinned_asid_map);
-		nr_pinned_asids--;
+		__clear_bit(asid2idx(info, asid), info->pinned_map);
+		info->nr_pinned_asids--;
 	}
 
 	raw_spin_unlock_irqrestore(&info->lock, flags);
@@ -391,8 +391,8 @@ static int asids_update_limit(void)
 
 	if (arm64_kernel_unmapped_at_el0()) {
 		num_available_asids /= 2;
-		if (pinned_asid_map)
-			set_kpti_asid_bits(info, pinned_asid_map);
+		if (info->pinned_map)
+			set_kpti_asid_bits(info, info->pinned_map);
 	}
 	/*
 	 * Expect allocation after rollover to fail if we don't have at least
@@ -407,7 +407,7 @@ static int asids_update_limit(void)
 	 * even if all CPUs have a reserved ASID and the maximum number of ASIDs
 	 * are pinned, there still is at least one empty slot in the ASID map.
 	 */
-	max_pinned_asids = num_available_asids - num_possible_cpus() - 2;
+	info->max_pinned_asids = num_available_asids - num_possible_cpus() - 2;
 	return 0;
 }
 arch_initcall(asids_update_limit);
@@ -429,9 +429,9 @@ static int asids_init(void)
 	info->reserved = &reserved_asids;
 	raw_spin_lock_init(&info->lock);
 
-	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
-				  sizeof(*pinned_asid_map), GFP_KERNEL);
-	nr_pinned_asids = 0;
+	info->pinned_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
+				   sizeof(*info->pinned_map), GFP_KERNEL);
+	info->nr_pinned_asids = 0;
 
 	/*
 	 * We cannot call set_reserved_asid_bits() here because CPU
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:02 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:02 +0100
Subject: [PATCH v4 06/16] arm64/mm: Introduce NUM_CTXT_ASIDS
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-7-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

At the moment ASID_FIRST_VERSION is used to know the number of ASIDs
supported. As we are going to move the ASID allocator to a separate file,
it would be better to use a different name for external users.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3-->v4
 -Dropped patch #6, but retained the name NUM_CTXT_ASIDS.

---
 arch/arm64/mm/context.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 628304e0d3b1..0f11d7c7f6a3 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -41,9 +41,9 @@ static unsigned long nr_pinned_asids;
 static unsigned long *pinned_asid_map;
 
 #define ASID_MASK(info)			(~GENMASK((info)->bits - 1, 0))
-#define ASID_FIRST_VERSION(info)	(1UL << (info)->bits)
+#define NUM_CTXT_ASIDS(info)		(1UL << ((info)->bits))
+#define ASID_FIRST_VERSION(info)        NUM_CTXT_ASIDS(info)
 
-#define NUM_USER_ASIDS(info)		ASID_FIRST_VERSION(info)
 #define asid2idx(info, asid)		((asid) & ~ASID_MASK(info))
 #define idx2asid(info, idx)		asid2idx(info, idx)
 
@@ -87,7 +87,7 @@ void verify_cpu_asid_bits(void)
 
 static void set_kpti_asid_bits(struct asid_info *info, unsigned long *map)
 {
-	unsigned int len = BITS_TO_LONGS(NUM_USER_ASIDS(info)) * sizeof(unsigned long);
+	unsigned int len = BITS_TO_LONGS(NUM_CTXT_ASIDS(info)) * sizeof(unsigned long);
 	/*
 	 * In case of KPTI kernel/user ASIDs are allocated in
 	 * pairs, the bottom bit distinguishes the two: if it
@@ -100,11 +100,11 @@ static void set_kpti_asid_bits(struct asid_info *info, unsigned long *map)
 static void set_reserved_asid_bits(struct asid_info *info)
 {
 	if (pinned_asid_map)
-		bitmap_copy(info->map, pinned_asid_map, NUM_USER_ASIDS(info));
+		bitmap_copy(info->map, pinned_asid_map, NUM_CTXT_ASIDS(info));
 	else if (arm64_kernel_unmapped_at_el0())
 		set_kpti_asid_bits(info, info->map);
 	else
-		bitmap_clear(info->map, 0, NUM_USER_ASIDS(info));
+		bitmap_clear(info->map, 0, NUM_CTXT_ASIDS(info));
 }
 
 #define asid_gen_match(asid, info) \
@@ -204,8 +204,8 @@ static u64 new_context(struct asid_info *info, atomic64_t *pasid,
 	 * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
 	 * pairs.
 	 */
-	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS(info), info->map_idx);
-	if (asid != NUM_USER_ASIDS(info))
+	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), info->map_idx);
+	if (asid != NUM_CTXT_ASIDS(info))
 		goto set_asid;
 
 	/* We're out of ASIDs, so increment the global generation count */
@@ -214,7 +214,7 @@ static u64 new_context(struct asid_info *info, atomic64_t *pasid,
 	flush_context(info);
 
 	/* We have more ASIDs than CPUs, so this will always succeed */
-	asid = find_next_zero_bit(info->map, NUM_USER_ASIDS(info), 1);
+	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), 1);
 
 set_asid:
 	__set_bit(asid, info->map);
@@ -387,7 +387,7 @@ void cpu_do_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm)
 static int asids_update_limit(void)
 {
 	struct asid_info *info = &asid_info;
-	unsigned long num_available_asids = NUM_USER_ASIDS(info);
+	unsigned long num_available_asids = NUM_CTXT_ASIDS(info);
 
 	if (arm64_kernel_unmapped_at_el0()) {
 		num_available_asids /= 2;
@@ -418,18 +418,18 @@ static int asids_init(void)
 
 	info->bits = get_cpu_asid_bits();
 	atomic64_set(&info->generation, ASID_FIRST_VERSION(info));
-	info->map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS(info)),
+	info->map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
 			    sizeof(*info->map), GFP_KERNEL);
 	if (!info->map)
 		panic("Failed to allocate bitmap for %lu ASIDs\n",
-		      NUM_USER_ASIDS(info));
+		      NUM_CTXT_ASIDS(info));
 
 	info->map_idx = 1;
 	info->active = &active_asids;
 	info->reserved = &reserved_asids;
 	raw_spin_lock_init(&info->lock);
 
-	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS(info)),
+	pinned_asid_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
 				  sizeof(*pinned_asid_map), GFP_KERNEL);
 	nr_pinned_asids = 0;
 
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:04 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:04 +0100
Subject: [PATCH v4 08/16] arm64/mm: Split asid_inits in 2 parts
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-9-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

Move out the common initialization of the ASID allocator in a separate
function.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3-->v4
  -dropped asid_per_ctxt and added pinned asid map init.
---
 arch/arm64/mm/context.c | 44 +++++++++++++++++++++++++++++++----------
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 8af54e06f5bc..041c3c5e0216 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -412,26 +412,50 @@ static int asids_update_limit(void)
 }
 arch_initcall(asids_update_limit);
 
-static int asids_init(void)
+/*
+ * Initialize the ASID allocator
+ *
+ * @info: Pointer to the asid allocator structure
+ * @bits: Number of ASIDs available
+ * @pinned: Support for Pinned ASIDs
+ */
+static int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned)
 {
-	struct asid_info *info = &asid_info;
+	info->bits = bits;
 
-	info->bits = get_cpu_asid_bits();
+	/*
+	 * Expect allocation after rollover to fail if we don't have at least
+	 * one more ASID than CPUs. ASID #0 is always reserved.
+	 */
+	WARN_ON(NUM_CTXT_ASIDS(info) - 1 <= num_possible_cpus());
 	atomic64_set(&info->generation, ASID_FIRST_VERSION(info));
 	info->map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
 			    sizeof(*info->map), GFP_KERNEL);
 	if (!info->map)
-		panic("Failed to allocate bitmap for %lu ASIDs\n",
-		      NUM_CTXT_ASIDS(info));
+		return -ENOMEM;
 
 	info->map_idx = 1;
-	info->active = &active_asids;
-	info->reserved = &reserved_asids;
 	raw_spin_lock_init(&info->lock);
 
-	info->pinned_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
-				   sizeof(*info->pinned_map), GFP_KERNEL);
-	info->nr_pinned_asids = 0;
+	if (pinned) {
+		info->pinned_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
+					   sizeof(*info->pinned_map), GFP_KERNEL);
+		info->nr_pinned_asids = 0;
+	}
+
+	return 0;
+}
+
+static int asids_init(void)
+{
+	struct asid_info *info = &asid_info;
+
+	if (asid_allocator_init(info, get_cpu_asid_bits(), true))
+		panic("Unable to initialize ASID allocator for %lu ASIDs\n",
+		      NUM_CTXT_ASIDS(info));
+
+	info->active = &active_asids;
+	info->reserved = &reserved_asids;
 
 	/*
 	 * We cannot call set_reserved_asid_bits() here because CPU
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:05 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:05 +0100
Subject: [PATCH v4 09/16] arm64/mm: Split the function
 check_and_switch_context in 3 parts
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-10-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

The function check_and_switch_context is used to:
    1) Check whether the ASID is still valid
    2) Generate a new one if it is not valid
    3) Switch the context

While the latter is specific to the MM subsystem, the rest could be part
of the generic ASID allocator.

After this patch, the function is now split in 3 parts which corresponds
to the use of the functions:
    1) asid_check_context: Check if the ASID is still valid
    2) asid_new_context: Generate a new ASID for the context
    3) check_and_switch_context: Call 1) and 2) and switch the context

1) and 2) have not been merged in a single function because we want to
avoid to add a branch in when the ASID is still valid. This will matter
when the code will be moved in separate file later on as 1) will reside
in the header as a static inline function.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
v3 comment:
    Will wants to avoid to add a branch when the ASID is still valid. So
    1) and 2) are in separates function. The former will move to a new
    header and make static inline.
---
 arch/arm64/mm/context.c | 70 ++++++++++++++++++++++++++++-------------
 1 file changed, 48 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 041c3c5e0216..40ef013c90c3 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -222,17 +222,49 @@ static u64 new_context(struct asid_info *info, atomic64_t *pasid,
 	return idx2asid(info, asid) | generation;
 }
 
-void check_and_switch_context(struct mm_struct *mm)
+/*
+ * Generate a new ASID for the context.
+ *
+ * @pasid: Pointer to the current ASID batch allocated. It will be updated
+ * with the new ASID batch.
+ * @pinned: refcount if asid is pinned.
+ * Caller needs to make sure preempt is disabled before calling this function.
+ */
+static void asid_new_context(struct asid_info *info, atomic64_t *pasid,
+			     refcount_t *pinned)
 {
 	unsigned long flags;
-	unsigned int cpu;
-	u64 asid, old_active_asid;
-	struct asid_info *info = &asid_info;
+	u64 asid;
+	unsigned int cpu = smp_processor_id();
 
-	if (system_supports_cnp())
-		cpu_set_reserved_ttbr0();
+	raw_spin_lock_irqsave(&info->lock, flags);
+	/* Check that our ASID belongs to the current generation. */
+	asid = atomic64_read(pasid);
+	if (!asid_gen_match(asid, info)) {
+		asid = new_context(info, pasid, pinned);
+		atomic64_set(pasid, asid);
+	}
 
-	asid = atomic64_read(&mm->context.id);
+	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending))
+		local_flush_tlb_all();
+
+	atomic64_set(&active_asid(info, cpu), asid);
+	raw_spin_unlock_irqrestore(&info->lock, flags);
+}
+
+/*
+ * Check the ASID is still valid for the context. If not generate a new ASID.
+ *
+ * @pasid: Pointer to the current ASID batch
+ * @pinned: refcount if asid is pinned
+ * Caller needs to make sure preempt is disabled before calling this function.
+ */
+static void asid_check_context(struct asid_info *info, atomic64_t *pasid,
+			       refcount_t *pinned)
+{
+	u64 asid, old_active_asid;
+
+	asid = atomic64_read(pasid);
 
 	/*
 	 * The memory ordering here is subtle.
@@ -252,24 +284,18 @@ void check_and_switch_context(struct mm_struct *mm)
 	if (old_active_asid && asid_gen_match(asid, info) &&
 	    atomic64_cmpxchg_relaxed(this_cpu_ptr(info->active),
 				     old_active_asid, asid))
-		goto switch_mm_fastpath;
-
-	raw_spin_lock_irqsave(&info->lock, flags);
-	/* Check that our ASID belongs to the current generation. */
-	asid = atomic64_read(&mm->context.id);
-	if (!asid_gen_match(asid, info)) {
-		asid = new_context(info, &mm->context.id, &mm->context.pinned);
-		atomic64_set(&mm->context.id, asid);
-	}
+		return;
 
-	cpu = smp_processor_id();
-	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending))
-		local_flush_tlb_all();
+	asid_new_context(info, pasid, pinned);
+}
 
-	atomic64_set(&active_asid(info, cpu), asid);
-	raw_spin_unlock_irqrestore(&info->lock, flags);
+void check_and_switch_context(struct mm_struct *mm)
+{
+	if (system_supports_cnp())
+		cpu_set_reserved_ttbr0();
 
-switch_mm_fastpath:
+	asid_check_context(&asid_info, &mm->context.id,
+			   &mm->context.pinned);
 
 	arm64_apply_bp_hardening();
 
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:06 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:06 +0100
Subject: [PATCH v4 10/16] arm64/mm: Split the arm64_mm_context_get/put
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-11-shameerali.kolothum.thodi@huawei.com>

Keep only the mm specific part in arm64_mm_context_get/put
and move the rest to generic functions.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 53 +++++++++++++++++++++++++++--------------
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 40ef013c90c3..901472a57b5d 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -307,20 +307,21 @@ void check_and_switch_context(struct mm_struct *mm)
 		cpu_switch_mm(mm->pgd, mm);
 }
 
-unsigned long arm64_mm_context_get(struct mm_struct *mm)
+static unsigned long asid_context_pinned_get(struct asid_info *info,
+					     atomic64_t *pasid,
+					     refcount_t *pinned)
 {
 	unsigned long flags;
 	u64 asid;
-	struct asid_info *info = &asid_info;
 
 	if (!info->pinned_map)
 		return 0;
 
 	raw_spin_lock_irqsave(&info->lock, flags);
 
-	asid = atomic64_read(&mm->context.id);
+	asid = atomic64_read(pasid);
 
-	if (refcount_inc_not_zero(&mm->context.pinned))
+	if (refcount_inc_not_zero(pinned))
 		goto out_unlock;
 
 	if (info->nr_pinned_asids >= info->max_pinned_asids) {
@@ -333,45 +334,61 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm)
 		 * We went through one or more rollover since that ASID was
 		 * used. Ensure that it is still valid, or generate a new one.
 		 */
-		asid = new_context(info, &mm->context.id, &mm->context.pinned);
-		atomic64_set(&mm->context.id, asid);
+		asid = new_context(info, pasid, pinned);
+		atomic64_set(pasid, asid);
 	}
 
 	info->nr_pinned_asids++;
 	__set_bit(asid2idx(info, asid), info->pinned_map);
-	refcount_set(&mm->context.pinned, 1);
+	refcount_set(pinned, 1);
 
 out_unlock:
 	raw_spin_unlock_irqrestore(&info->lock, flags);
-
 	asid &= ~ASID_MASK(info);
-
-	/* Set the equivalent of USER_ASID_BIT */
-	if (asid && arm64_kernel_unmapped_at_el0())
-		asid |= 1;
-
 	return asid;
 }
-EXPORT_SYMBOL_GPL(arm64_mm_context_get);
 
-void arm64_mm_context_put(struct mm_struct *mm)
+static void asid_context_pinned_put(struct asid_info *info, atomic64_t *pasid,
+				    refcount_t *pinned)
 {
 	unsigned long flags;
-	struct asid_info *info = &asid_info;
-	u64 asid = atomic64_read(&mm->context.id);
+	u64 asid = atomic64_read(pasid);
 
 	if (!info->pinned_map)
 		return;
 
 	raw_spin_lock_irqsave(&info->lock, flags);
 
-	if (refcount_dec_and_test(&mm->context.pinned)) {
+	if (refcount_dec_and_test(pinned)) {
 		__clear_bit(asid2idx(info, asid), info->pinned_map);
 		info->nr_pinned_asids--;
 	}
 
 	raw_spin_unlock_irqrestore(&info->lock, flags);
 }
+
+unsigned long arm64_mm_context_get(struct mm_struct *mm)
+{
+	u64 asid;
+	struct asid_info *info = &asid_info;
+
+	asid = asid_context_pinned_get(info, &mm->context.id,
+				       &mm->context.pinned);
+
+	/* Set the equivalent of USER_ASID_BIT */
+	if (asid && arm64_kernel_unmapped_at_el0())
+		asid |= 1;
+
+	return asid;
+}
+EXPORT_SYMBOL_GPL(arm64_mm_context_get);
+
+void arm64_mm_context_put(struct mm_struct *mm)
+{
+	struct asid_info *info = &asid_info;
+
+	asid_context_pinned_put(info, &mm->context.id, &mm->context.pinned);
+}
 EXPORT_SYMBOL_GPL(arm64_mm_context_put);
 
 /* Errata workaround post TTBRx_EL1 update. */
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:08 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:08 +0100
Subject: [PATCH v4 12/16] arm64/mm: Introduce a callback to set reserved bits
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-13-shameerali.kolothum.thodi@huawei.com>

Setting the reserved asid bits will vary depending on the actual
user of the ASID allocator. Introduce a new callback.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index ee446f7535a3..e9049d14f54a 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -34,6 +34,8 @@ static struct asid_info
 	unsigned long		nr_pinned_asids;
 	/* Callback to locally flush the context. */
 	void			(*flush_cpu_ctxt_cb)(void);
+	/* Callback to set the list of reserved ASIDs */
+	void			(*set_reserved_bits)(struct asid_info *info);
 } asid_info;
 
 #define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
@@ -118,7 +120,8 @@ static void flush_context(struct asid_info *info)
 	u64 asid;
 
 	/* Update the list of reserved ASIDs and the ASID bitmap. */
-	set_reserved_asid_bits(info);
+	if (info->set_reserved_bits)
+		info->set_reserved_bits(info);
 
 	for_each_possible_cpu(i) {
 		asid = atomic64_xchg_relaxed(&active_asid(info, i), 0);
@@ -508,6 +511,7 @@ static int asids_init(void)
 	info->active = &active_asids;
 	info->reserved = &reserved_asids;
 	info->flush_cpu_ctxt_cb = asid_flush_cpu_ctxt;
+	info->set_reserved_bits = set_reserved_asid_bits;
 
 	/*
 	 * We cannot call set_reserved_asid_bits() here because CPU
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:07 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:07 +0100
Subject: [PATCH v4 11/16] arm64/mm: Introduce a callback to flush the local
 context
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-12-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

Flushing the local context will vary depending on the actual user
of the ASID allocator. Introduce a new callback to flush the local
context and move the call to flush local TLB in it.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/mm/context.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 901472a57b5d..ee446f7535a3 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -32,6 +32,8 @@ static struct asid_info
 	unsigned long		*pinned_map;
 	unsigned long		max_pinned_asids;
 	unsigned long		nr_pinned_asids;
+	/* Callback to locally flush the context. */
+	void			(*flush_cpu_ctxt_cb)(void);
 } asid_info;
 
 #define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
@@ -245,8 +247,9 @@ static void asid_new_context(struct asid_info *info, atomic64_t *pasid,
 		atomic64_set(pasid, asid);
 	}
 
-	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending))
-		local_flush_tlb_all();
+	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending) &&
+	    info->flush_cpu_ctxt_cb)
+		info->flush_cpu_ctxt_cb();
 
 	atomic64_set(&active_asid(info, cpu), asid);
 	raw_spin_unlock_irqrestore(&info->lock, flags);
@@ -427,6 +430,11 @@ void cpu_do_switch_mm(phys_addr_t pgd_phys, struct mm_struct *mm)
 	post_ttbr_update_workaround();
 }
 
+static void asid_flush_cpu_ctxt(void)
+{
+	local_flush_tlb_all();
+}
+
 static int asids_update_limit(void)
 {
 	struct asid_info *info = &asid_info;
@@ -499,6 +507,7 @@ static int asids_init(void)
 
 	info->active = &active_asids;
 	info->reserved = &reserved_asids;
+	info->flush_cpu_ctxt_cb = asid_flush_cpu_ctxt;
 
 	/*
 	 * We cannot call set_reserved_asid_bits() here because CPU
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:09 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:09 +0100
Subject: [PATCH v4 13/16] arm64: Move the ASID allocator code in a separate
 file
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-14-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

We will want to re-use the ASID allocator in a separate context (e.g
allocating VMID). So move the code in a new file.

The function asid_check_context has been moved in the header as a static
inline function because we want to avoid add a branch when checking if the
ASID is still valid.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/include/asm/lib_asid.h |  85 ++++++++
 arch/arm64/lib/Makefile           |   2 +
 arch/arm64/lib/asid.c             | 258 +++++++++++++++++++++++++
 arch/arm64/mm/context.c           | 310 +-----------------------------
 4 files changed, 347 insertions(+), 308 deletions(-)
 create mode 100644 arch/arm64/include/asm/lib_asid.h
 create mode 100644 arch/arm64/lib/asid.c

diff --git a/arch/arm64/include/asm/lib_asid.h b/arch/arm64/include/asm/lib_asid.h
new file mode 100644
index 000000000000..acae8d243d17
--- /dev/null
+++ b/arch/arm64/include/asm/lib_asid.h
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_ASM_LIB_ASID_H
+#define __ASM_ASM_LIB_ASID_H
+
+#include <linux/atomic.h>
+#include <linux/compiler.h>
+#include <linux/cpumask.h>
+#include <linux/percpu.h>
+#include <linux/spinlock.h>
+
+struct asid_info {
+	atomic64_t	generation;
+	unsigned long	*map;
+	unsigned int	map_idx;
+	atomic64_t __percpu	*active;
+	u64 __percpu		*reserved;
+	u32			bits;
+	raw_spinlock_t		lock;
+	/* Which CPU requires context flush on next call */
+	cpumask_t		flush_pending;
+	/* Pinned ASIDs info */
+	unsigned long		*pinned_map;
+	unsigned long		max_pinned_asids;
+	unsigned long		nr_pinned_asids;
+	/* Callback to locally flush the context. */
+	void			(*flush_cpu_ctxt_cb)(void);
+	/* Callback to set the list of reserved ASIDs */
+	void			(*set_reserved_bits)(struct asid_info *info);
+};
+
+#define NUM_CTXT_ASIDS(info)		(1UL << ((info)->bits))
+
+#define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
+#define asid_gen_match(asid, info) \
+	(!(((asid) ^ atomic64_read(&(info)->generation)) >> info->bits))
+
+void asid_new_context(struct asid_info *info, atomic64_t *pasid,
+		      refcount_t *pinned, unsigned int cpu);
+
+/*
+ * Check the ASID is still valid for the context. If not generate a new ASID.
+ *
+ * @pasid: Pointer to the current ASID batch
+ * @pinned: refcount if asid is pinned
+ */
+static inline void asid_check_context(struct asid_info *info, atomic64_t *pasid,
+				      refcount_t *pinned)
+{
+	unsigned int cpu;
+	u64 asid, old_active_asid;
+
+	asid = atomic64_read(pasid);
+
+	/*
+	 * The memory ordering here is subtle.
+	 * If our active_asid is non-zero and the ASID matches the current
+	 * generation, then we update the active_asid entry with a relaxed
+	 * cmpxchg. Racing with a concurrent rollover means that either:
+	 *
+	 * - We get a zero back from the cmpxchg and end up waiting on the
+	 *   lock. Taking the lock synchronises with the rollover and so
+	 *   we are forced to see the updated generation.
+	 *
+	 * - We get a valid ASID back from the cmpxchg, which means the
+	 *   relaxed xchg in flush_context will treat us as reserved
+	 *   because atomic RmWs are totally ordered for a given location.
+	 */
+	old_active_asid = atomic64_read(this_cpu_ptr(info->active));
+	if (old_active_asid && asid_gen_match(asid, info) &&
+	    atomic64_cmpxchg_relaxed(this_cpu_ptr(info->active),
+				     old_active_asid, asid))
+		return;
+
+	cpu = smp_processor_id();
+	asid_new_context(info, pasid, pinned, cpu);
+}
+
+unsigned long asid_context_pinned_get(struct asid_info *info,
+				      atomic64_t *pasid,
+				      refcount_t *pinned);
+void asid_context_pinned_put(struct asid_info *info, atomic64_t *pasid,
+			     refcount_t *pinned);
+int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned);
+
+#endif
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index d31e1169d9b8..d42c66ce0460 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -5,6 +5,8 @@ lib-y		:= clear_user.o delay.o copy_from_user.o		\
 		   memset.o memcmp.o strcmp.o strncmp.o strlen.o	\
 		   strnlen.o strchr.o strrchr.o tishift.o
 
+lib-y		+= asid.o
+
 ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
 obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 CFLAGS_REMOVE_xor-neon.o	+= -mgeneral-regs-only
diff --git a/arch/arm64/lib/asid.c b/arch/arm64/lib/asid.c
new file mode 100644
index 000000000000..286285616f65
--- /dev/null
+++ b/arch/arm64/lib/asid.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Generic ASID allocator.
+ *
+ * Based on arch/arm/mm/context.c
+ *
+ * Copyright (C) 2002-2003 Deep Blue Solutions Ltd, all rights reserved.
+ * Copyright (C) 2012 ARM Ltd.
+ */
+
+#include <linux/slab.h>
+
+#include <asm/lib_asid.h>
+
+#define reserved_asid(info, cpu) (*per_cpu_ptr((info)->reserved, cpu))
+
+#define ASID_MASK(info)			(~GENMASK((info)->bits - 1, 0))
+#define ASID_FIRST_VERSION(info)        NUM_CTXT_ASIDS(info)
+
+#define asid2idx(info, asid)		((asid) & ~ASID_MASK(info))
+#define idx2asid(info, idx)		asid2idx(info, idx)
+
+static void flush_context(struct asid_info *info)
+{
+	int i;
+	u64 asid;
+
+	/* Update the list of reserved ASIDs and the ASID bitmap. */
+	if (info->set_reserved_bits)
+		info->set_reserved_bits(info);
+
+	for_each_possible_cpu(i) {
+		asid = atomic64_xchg_relaxed(&active_asid(info, i), 0);
+		/*
+		 * If this CPU has already been through a
+		 * rollover, but hasn't run another task in
+		 * the meantime, we must preserve its reserved
+		 * ASID, as this is the only trace we have of
+		 * the process it is still running.
+		 */
+		if (asid == 0)
+			asid = reserved_asid(info, i);
+		__set_bit(asid2idx(info, asid), info->map);
+		reserved_asid(info, i) = asid;
+	}
+
+	/*
+	 * Queue a TLB invalidation for each CPU to perform on next
+	 * context-switch
+	 */
+	cpumask_setall(&info->flush_pending);
+}
+
+static bool check_update_reserved_asid(struct asid_info *info, u64 asid,
+				       u64 newasid)
+{
+	int cpu;
+	bool hit = false;
+
+	/*
+	 * Iterate over the set of reserved ASIDs looking for a match.
+	 * If we find one, then we can update our mm to use newasid
+	 * (i.e. the same ASID in the current generation) but we can't
+	 * exit the loop early, since we need to ensure that all copies
+	 * of the old ASID are updated to reflect the mm. Failure to do
+	 * so could result in us missing the reserved ASID in a future
+	 * generation.
+	 */
+	for_each_possible_cpu(cpu) {
+		if (reserved_asid(info, cpu) == asid) {
+			hit = true;
+			reserved_asid(info, cpu) = newasid;
+		}
+	}
+
+	return hit;
+}
+
+static u64 new_context(struct asid_info *info, atomic64_t *pasid,
+		       refcount_t *pinned)
+{
+	u64 asid = atomic64_read(pasid);
+	u64 generation = atomic64_read(&info->generation);
+
+	if (asid != 0) {
+		u64 newasid = generation | (asid & ~ASID_MASK(info));
+
+		/*
+		 * If our current ASID was active during a rollover, we
+		 * can continue to use it and this was just a false alarm.
+		 */
+		if (check_update_reserved_asid(info, asid, newasid))
+			return newasid;
+
+		/*
+		 * If it is pinned, we can keep using it. Note that reserved
+		 * takes priority, because even if it is also pinned, we need to
+		 * update the generation into the reserved_asids.
+		 */
+		if (pinned && refcount_read(pinned))
+			return newasid;
+
+		/*
+		 * We had a valid ASID in a previous life, so try to re-use
+		 * it if possible.
+		 */
+		if (!__test_and_set_bit(asid2idx(info, asid), info->map))
+			return newasid;
+	}
+
+	/*
+	 * Allocate a free ASID. If we can't find one, take a note of the
+	 * currently active ASIDs and mark the TLBs as requiring flushes.  We
+	 * always count from ASID #2 (index 1), as we use ASID #0 when setting
+	 * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
+	 * pairs.
+	 */
+	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), info->map_idx);
+	if (asid != NUM_CTXT_ASIDS(info))
+		goto set_asid;
+
+	/* We're out of ASIDs, so increment the global generation count */
+	generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION(info),
+						 &info->generation);
+	flush_context(info);
+
+	/* We have more ASIDs than CPUs, so this will always succeed */
+	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), 1);
+
+set_asid:
+	__set_bit(asid, info->map);
+	info->map_idx = asid;
+	return idx2asid(info, asid) | generation;
+}
+
+/*
+ * Generate a new ASID for the context.
+ *
+ * @pasid: Pointer to the current ASID batch allocated. It will be updated
+ * with the new ASID batch.
+ * @pinned: refcount if asid is pinned
+ * @cpu: current CPU ID. Must have been acquired through get_cpu()
+ */
+void asid_new_context(struct asid_info *info, atomic64_t *pasid,
+		      refcount_t *pinned, unsigned int cpu)
+{
+	unsigned long flags;
+	u64 asid;
+
+	raw_spin_lock_irqsave(&info->lock, flags);
+	/* Check that our ASID belongs to the current generation. */
+	asid = atomic64_read(pasid);
+	if (!asid_gen_match(asid, info)) {
+		asid = new_context(info, pasid, pinned);
+		atomic64_set(pasid, asid);
+	}
+
+	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending) &&
+	    info->flush_cpu_ctxt_cb)
+		info->flush_cpu_ctxt_cb();
+
+	atomic64_set(&active_asid(info, cpu), asid);
+	raw_spin_unlock_irqrestore(&info->lock, flags);
+}
+
+unsigned long asid_context_pinned_get(struct asid_info *info,
+				      atomic64_t *pasid,
+				      refcount_t *pinned)
+{
+	unsigned long flags;
+	u64 asid;
+
+	if (!info->pinned_map)
+		return 0;
+
+	raw_spin_lock_irqsave(&info->lock, flags);
+
+	asid = atomic64_read(pasid);
+
+	if (refcount_inc_not_zero(pinned))
+		goto out_unlock;
+
+	if (info->nr_pinned_asids >= info->max_pinned_asids) {
+		asid = 0;
+		goto out_unlock;
+	}
+
+	if (!asid_gen_match(asid, info)) {
+		/*
+		 * We went through one or more rollover since that ASID was
+		 * used. Ensure that it is still valid, or generate a new one.
+		 */
+		asid = new_context(info, pasid, pinned);
+		atomic64_set(pasid, asid);
+	}
+
+	info->nr_pinned_asids++;
+	__set_bit(asid2idx(info, asid), info->pinned_map);
+	refcount_set(pinned, 1);
+
+out_unlock:
+	raw_spin_unlock_irqrestore(&info->lock, flags);
+	asid &= ~ASID_MASK(info);
+	return asid;
+}
+
+void asid_context_pinned_put(struct asid_info *info, atomic64_t *pasid,
+			     refcount_t *pinned)
+{
+	unsigned long flags;
+	u64 asid = atomic64_read(pasid);
+
+	if (!info->pinned_map)
+		return;
+
+	raw_spin_lock_irqsave(&info->lock, flags);
+
+	if (refcount_dec_and_test(pinned)) {
+		__clear_bit(asid2idx(info, asid), info->pinned_map);
+		info->nr_pinned_asids--;
+	}
+
+	raw_spin_unlock_irqrestore(&info->lock, flags);
+}
+
+/*
+ * Initialize the ASID allocator
+ *
+ * @info: Pointer to the asid allocator structure
+ * @bits: Number of ASIDs available
+ * @pinned: Support for Pinned ASIDs
+ */
+int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned)
+{
+	info->bits = bits;
+
+	/*
+	 * Expect allocation after rollover to fail if we don't have at least
+	 * one more ASID than CPUs. ASID #0 is always reserved.
+	 */
+	WARN_ON(NUM_CTXT_ASIDS(info) - 1 <= num_possible_cpus());
+	atomic64_set(&info->generation, ASID_FIRST_VERSION(info));
+	info->map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
+			    sizeof(*info->map), GFP_KERNEL);
+	if (!info->map)
+		return -ENOMEM;
+
+	info->map_idx = 1;
+	raw_spin_lock_init(&info->lock);
+
+	if (pinned) {
+		info->pinned_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
+					   sizeof(*info->pinned_map), GFP_KERNEL);
+		info->nr_pinned_asids = 0;
+	}
+
+	return 0;
+}
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index e9049d14f54a..f44e08981841 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -13,43 +13,15 @@
 #include <linux/mm.h>
 
 #include <asm/cpufeature.h>
+#include <asm/lib_asid.h>
 #include <asm/mmu_context.h>
 #include <asm/smp.h>
 #include <asm/tlbflush.h>
 
-static struct asid_info
-{
-	atomic64_t	generation;
-	unsigned long	*map;
-	unsigned int	map_idx;
-	atomic64_t __percpu	*active;
-	u64 __percpu		*reserved;
-	u32			bits;
-	raw_spinlock_t		lock;
-	/* Which CPU requires context flush on next call */
-	cpumask_t		flush_pending;
-	/* Pinned ASIDs info */
-	unsigned long		*pinned_map;
-	unsigned long		max_pinned_asids;
-	unsigned long		nr_pinned_asids;
-	/* Callback to locally flush the context. */
-	void			(*flush_cpu_ctxt_cb)(void);
-	/* Callback to set the list of reserved ASIDs */
-	void			(*set_reserved_bits)(struct asid_info *info);
-} asid_info;
-
-#define active_asid(info, cpu)	 (*per_cpu_ptr((info)->active, cpu))
-#define reserved_asid(info, cpu) (*per_cpu_ptr((info)->reserved, cpu))
-
 static DEFINE_PER_CPU(atomic64_t, active_asids);
 static DEFINE_PER_CPU(u64, reserved_asids);
 
-#define ASID_MASK(info)			(~GENMASK((info)->bits - 1, 0))
-#define NUM_CTXT_ASIDS(info)		(1UL << ((info)->bits))
-#define ASID_FIRST_VERSION(info)        NUM_CTXT_ASIDS(info)
-
-#define asid2idx(info, asid)		((asid) & ~ASID_MASK(info))
-#define idx2asid(info, idx)		asid2idx(info, idx)
+static struct asid_info asid_info;
 
 /* Get the ASIDBits supported by the current CPU */
 static u32 get_cpu_asid_bits(void)
@@ -111,190 +83,6 @@ static void set_reserved_asid_bits(struct asid_info *info)
 		bitmap_clear(info->map, 0, NUM_CTXT_ASIDS(info));
 }
 
-#define asid_gen_match(asid, info) \
-	(!(((asid) ^ atomic64_read(&(info)->generation)) >> info->bits))
-
-static void flush_context(struct asid_info *info)
-{
-	int i;
-	u64 asid;
-
-	/* Update the list of reserved ASIDs and the ASID bitmap. */
-	if (info->set_reserved_bits)
-		info->set_reserved_bits(info);
-
-	for_each_possible_cpu(i) {
-		asid = atomic64_xchg_relaxed(&active_asid(info, i), 0);
-		/*
-		 * If this CPU has already been through a
-		 * rollover, but hasn't run another task in
-		 * the meantime, we must preserve its reserved
-		 * ASID, as this is the only trace we have of
-		 * the process it is still running.
-		 */
-		if (asid == 0)
-			asid = reserved_asid(info, i);
-		__set_bit(asid2idx(info, asid), info->map);
-		reserved_asid(info, i) = asid;
-	}
-
-	/*
-	 * Queue a TLB invalidation for each CPU to perform on next
-	 * context-switch
-	 */
-	cpumask_setall(&info->flush_pending);
-}
-
-static bool check_update_reserved_asid(struct asid_info *info, u64 asid,
-				       u64 newasid)
-{
-	int cpu;
-	bool hit = false;
-
-	/*
-	 * Iterate over the set of reserved ASIDs looking for a match.
-	 * If we find one, then we can update our mm to use newasid
-	 * (i.e. the same ASID in the current generation) but we can't
-	 * exit the loop early, since we need to ensure that all copies
-	 * of the old ASID are updated to reflect the mm. Failure to do
-	 * so could result in us missing the reserved ASID in a future
-	 * generation.
-	 */
-	for_each_possible_cpu(cpu) {
-		if (reserved_asid(info, cpu) == asid) {
-			hit = true;
-			reserved_asid(info, cpu) = newasid;
-		}
-	}
-
-	return hit;
-}
-
-static u64 new_context(struct asid_info *info, atomic64_t *pasid,
-		       refcount_t *pinned)
-{
-	u64 asid = atomic64_read(pasid);
-	u64 generation = atomic64_read(&info->generation);
-
-	if (asid != 0) {
-		u64 newasid = generation | (asid & ~ASID_MASK(info));
-
-		/*
-		 * If our current ASID was active during a rollover, we
-		 * can continue to use it and this was just a false alarm.
-		 */
-		if (check_update_reserved_asid(info, asid, newasid))
-			return newasid;
-
-		/*
-		 * If it is pinned, we can keep using it. Note that reserved
-		 * takes priority, because even if it is also pinned, we need to
-		 * update the generation into the reserved_asids.
-		 */
-		if (pinned && refcount_read(pinned))
-			return newasid;
-
-		/*
-		 * We had a valid ASID in a previous life, so try to re-use
-		 * it if possible.
-		 */
-		if (!__test_and_set_bit(asid2idx(info, asid), info->map))
-			return newasid;
-	}
-
-	/*
-	 * Allocate a free ASID. If we can't find one, take a note of the
-	 * currently active ASIDs and mark the TLBs as requiring flushes.  We
-	 * always count from ASID #2 (index 1), as we use ASID #0 when setting
-	 * a reserved TTBR0 for the init_mm and we allocate ASIDs in even/odd
-	 * pairs.
-	 */
-	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), info->map_idx);
-	if (asid != NUM_CTXT_ASIDS(info))
-		goto set_asid;
-
-	/* We're out of ASIDs, so increment the global generation count */
-	generation = atomic64_add_return_relaxed(ASID_FIRST_VERSION(info),
-						 &info->generation);
-	flush_context(info);
-
-	/* We have more ASIDs than CPUs, so this will always succeed */
-	asid = find_next_zero_bit(info->map, NUM_CTXT_ASIDS(info), 1);
-
-set_asid:
-	__set_bit(asid, info->map);
-	info->map_idx = asid;
-	return idx2asid(info, asid) | generation;
-}
-
-/*
- * Generate a new ASID for the context.
- *
- * @pasid: Pointer to the current ASID batch allocated. It will be updated
- * with the new ASID batch.
- * @pinned: refcount if asid is pinned.
- * Caller needs to make sure preempt is disabled before calling this function.
- */
-static void asid_new_context(struct asid_info *info, atomic64_t *pasid,
-			     refcount_t *pinned)
-{
-	unsigned long flags;
-	u64 asid;
-	unsigned int cpu = smp_processor_id();
-
-	raw_spin_lock_irqsave(&info->lock, flags);
-	/* Check that our ASID belongs to the current generation. */
-	asid = atomic64_read(pasid);
-	if (!asid_gen_match(asid, info)) {
-		asid = new_context(info, pasid, pinned);
-		atomic64_set(pasid, asid);
-	}
-
-	if (cpumask_test_and_clear_cpu(cpu, &info->flush_pending) &&
-	    info->flush_cpu_ctxt_cb)
-		info->flush_cpu_ctxt_cb();
-
-	atomic64_set(&active_asid(info, cpu), asid);
-	raw_spin_unlock_irqrestore(&info->lock, flags);
-}
-
-/*
- * Check the ASID is still valid for the context. If not generate a new ASID.
- *
- * @pasid: Pointer to the current ASID batch
- * @pinned: refcount if asid is pinned
- * Caller needs to make sure preempt is disabled before calling this function.
- */
-static void asid_check_context(struct asid_info *info, atomic64_t *pasid,
-			       refcount_t *pinned)
-{
-	u64 asid, old_active_asid;
-
-	asid = atomic64_read(pasid);
-
-	/*
-	 * The memory ordering here is subtle.
-	 * If our active_asid is non-zero and the ASID matches the current
-	 * generation, then we update the active_asid entry with a relaxed
-	 * cmpxchg. Racing with a concurrent rollover means that either:
-	 *
-	 * - We get a zero back from the cmpxchg and end up waiting on the
-	 *   lock. Taking the lock synchronises with the rollover and so
-	 *   we are forced to see the updated generation.
-	 *
-	 * - We get a valid ASID back from the cmpxchg, which means the
-	 *   relaxed xchg in flush_context will treat us as reserved
-	 *   because atomic RmWs are totally ordered for a given location.
-	 */
-	old_active_asid = atomic64_read(this_cpu_ptr(info->active));
-	if (old_active_asid && asid_gen_match(asid, info) &&
-	    atomic64_cmpxchg_relaxed(this_cpu_ptr(info->active),
-				     old_active_asid, asid))
-		return;
-
-	asid_new_context(info, pasid, pinned);
-}
-
 void check_and_switch_context(struct mm_struct *mm)
 {
 	if (system_supports_cnp())
@@ -313,66 +101,6 @@ void check_and_switch_context(struct mm_struct *mm)
 		cpu_switch_mm(mm->pgd, mm);
 }
 
-static unsigned long asid_context_pinned_get(struct asid_info *info,
-					     atomic64_t *pasid,
-					     refcount_t *pinned)
-{
-	unsigned long flags;
-	u64 asid;
-
-	if (!info->pinned_map)
-		return 0;
-
-	raw_spin_lock_irqsave(&info->lock, flags);
-
-	asid = atomic64_read(pasid);
-
-	if (refcount_inc_not_zero(pinned))
-		goto out_unlock;
-
-	if (info->nr_pinned_asids >= info->max_pinned_asids) {
-		asid = 0;
-		goto out_unlock;
-	}
-
-	if (!asid_gen_match(asid, info)) {
-		/*
-		 * We went through one or more rollover since that ASID was
-		 * used. Ensure that it is still valid, or generate a new one.
-		 */
-		asid = new_context(info, pasid, pinned);
-		atomic64_set(pasid, asid);
-	}
-
-	info->nr_pinned_asids++;
-	__set_bit(asid2idx(info, asid), info->pinned_map);
-	refcount_set(pinned, 1);
-
-out_unlock:
-	raw_spin_unlock_irqrestore(&info->lock, flags);
-	asid &= ~ASID_MASK(info);
-	return asid;
-}
-
-static void asid_context_pinned_put(struct asid_info *info, atomic64_t *pasid,
-				    refcount_t *pinned)
-{
-	unsigned long flags;
-	u64 asid = atomic64_read(pasid);
-
-	if (!info->pinned_map)
-		return;
-
-	raw_spin_lock_irqsave(&info->lock, flags);
-
-	if (refcount_dec_and_test(pinned)) {
-		__clear_bit(asid2idx(info, asid), info->pinned_map);
-		info->nr_pinned_asids--;
-	}
-
-	raw_spin_unlock_irqrestore(&info->lock, flags);
-}
-
 unsigned long arm64_mm_context_get(struct mm_struct *mm)
 {
 	u64 asid;
@@ -466,40 +194,6 @@ static int asids_update_limit(void)
 }
 arch_initcall(asids_update_limit);
 
-/*
- * Initialize the ASID allocator
- *
- * @info: Pointer to the asid allocator structure
- * @bits: Number of ASIDs available
- * @pinned: Support for Pinned ASIDs
- */
-static int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned)
-{
-	info->bits = bits;
-
-	/*
-	 * Expect allocation after rollover to fail if we don't have at least
-	 * one more ASID than CPUs. ASID #0 is always reserved.
-	 */
-	WARN_ON(NUM_CTXT_ASIDS(info) - 1 <= num_possible_cpus());
-	atomic64_set(&info->generation, ASID_FIRST_VERSION(info));
-	info->map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
-			    sizeof(*info->map), GFP_KERNEL);
-	if (!info->map)
-		return -ENOMEM;
-
-	info->map_idx = 1;
-	raw_spin_lock_init(&info->lock);
-
-	if (pinned) {
-		info->pinned_map = kcalloc(BITS_TO_LONGS(NUM_CTXT_ASIDS(info)),
-					   sizeof(*info->pinned_map), GFP_KERNEL);
-		info->nr_pinned_asids = 0;
-	}
-
-	return 0;
-}
-
 static int asids_init(void)
 {
 	struct asid_info *info = &asid_info;
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:10 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:10 +0100
Subject: [PATCH v4 14/16] arm64/lib: Add an helper to free memory allocated by
 the ASID allocator
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-15-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

Some users of the ASID allocator (e.g VMID) may need to free any
resources if the initialization fail. So introduce a function that
allows freeing of any memory allocated by the ASID allocator.

Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 arch/arm64/include/asm/lib_asid.h | 2 ++
 arch/arm64/lib/asid.c             | 6 ++++++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/include/asm/lib_asid.h b/arch/arm64/include/asm/lib_asid.h
index acae8d243d17..4dbc0a3f19a6 100644
--- a/arch/arm64/include/asm/lib_asid.h
+++ b/arch/arm64/include/asm/lib_asid.h
@@ -82,4 +82,6 @@ void asid_context_pinned_put(struct asid_info *info, atomic64_t *pasid,
 			     refcount_t *pinned);
 int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned);
 
+void asid_allocator_free(struct asid_info *info);
+
 #endif
diff --git a/arch/arm64/lib/asid.c b/arch/arm64/lib/asid.c
index 286285616f65..7bd031f9516a 100644
--- a/arch/arm64/lib/asid.c
+++ b/arch/arm64/lib/asid.c
@@ -256,3 +256,9 @@ int asid_allocator_init(struct asid_info *info, u32 bits, bool pinned)
 
 	return 0;
 }
+
+void asid_allocator_free(struct asid_info *info)
+{
+	kfree(info->map);
+	kfree(info->pinned_map);
+}
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:11 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:11 +0100
Subject: [PATCH v4 15/16] arch/arm64: Introduce a capability to tell whether
 16-bit VMID is available
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-16-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

At the moment, the function kvm_get_vmid_bits() is looking up for the
sanitized value of ID_AA64MMFR1_EL1 and extract the information
regarding the number of VMID bits supported.

This is fine as the function is mainly used during VMID roll-over. New
use in a follow-up patch will require the function to be called a every
context switch so we want the function to be more efficient.

A new capability is introduced to tell whether 16-bit VMID is
available.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---
 arch/arm64/include/asm/cpucaps.h | 3 ++-
 arch/arm64/include/asm/kvm_mmu.h | 4 +---
 arch/arm64/kernel/cpufeature.c   | 9 +++++++++
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index c40f2490cd7b..acb92da5c254 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -67,7 +67,8 @@
 #define ARM64_HAS_LDAPR				59
 #define ARM64_KVM_PROTECTED_MODE		60
 #define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP	61
+#define ARM64_HAS_16BIT_VMID			62
 
-#define ARM64_NCAPS				62
+#define ARM64_NCAPS				63
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 90873851f677..c3080966ef83 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -213,9 +213,7 @@ void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
 
 static inline unsigned int kvm_get_vmid_bits(void)
 {
-	int reg = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
-
-	return get_vmid_bits(reg);
+	return cpus_have_const_cap(ARM64_HAS_16BIT_VMID) ? 16 : 8;
 }
 
 /*
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e5281e1c8f1d..ff956fb2f712 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2203,6 +2203,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.matches = has_cpuid_feature,
 		.min_field_value = 1,
 	},
+	{
+		.capability = ARM64_HAS_16BIT_VMID,
+		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.sys_reg = SYS_ID_AA64MMFR1_EL1,
+		.field_pos = ID_AA64MMFR1_VMIDBITS_SHIFT,
+		.sign = FTR_UNSIGNED,
+		.min_field_value = ID_AA64MMFR1_VMIDBITS_16,
+		.matches = has_cpuid_feature,
+	},
 	{},
 };
 
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Wed Apr 14 12:23:12 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Wed, 14 Apr 2021 12:23:12 +0100
Subject: [PATCH v4 16/16] kvm/arm: Align the VMID allocation with the arm64
 ASID one
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210414112312.13704-17-shameerali.kolothum.thodi@huawei.com>

From: Julien Grall <julien.grall at arm.com>

At the moment, the VMID algorithm will send an SGI to all the CPUs to
force an exit and then broadcast a full TLB flush and I-Cache
invalidation.

This patch re-use the new ASID allocator. The
benefits are:
    - CPUs are not forced to exit at roll-over. Instead the VMID will be
    marked reserved and the context will be flushed at next exit. This
    will reduce the IPIs traffic.
    - Context invalidation is now per-CPU rather than broadcasted.
    - Catalin has a formal model of the ASID allocator.

With the new algo, the code is now adapted:
    - The function __kvm_flush_vm_context() has been renamed to
    __kvm_tlb_flush_local_all() and now only flushing the current CPU
    context.
    - The call to update_vmid() will be done with preemption disabled
    as the new algo requires to store information per-CPU.
    - The TLBs associated to EL1 will be flushed when booting a CPU to
    deal with stale information. This was previously done on the
    allocation of the first VMID of a new generation.


Signed-off-by: Julien Grall <julien.grall at arm.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
Test Results:

v4:
The measurement was made on a HiSilicon D06 platform with maxcpus set
to 8 and with the number of VMID limited to 4-bit. The test involves
running concurrently 40 guests with 2 vCPUs. Each guest will then
 execute hackbench 5 times before exiting.

The performance difference between the current algo and the new one are
(avg. of 10 runs):
   - 1.9% less entry/exit from guest
   - 0.7% faster

v3:
The measurement was made on a Seattle based SoC (8 CPUs), with the
number of VMID limited to 4-bit. The test involves running concurrently 40
guests with 2 vCPUs. Each guest will then execute hackbench 5 times
before exiting.

The performance difference between the current algo and the new one are:
    - 2.5% less exit from the guest
    - 22.4% more flush, although they are now local rather than
    broadcasted
    - 0.11% faster (just for the record)

---
 arch/arm64/include/asm/kvm_asm.h   |   4 +-
 arch/arm64/include/asm/kvm_host.h  |   5 +-
 arch/arm64/include/asm/kvm_mmu.h   |   3 +-
 arch/arm64/kvm/arm.c               | 124 +++++++++++------------------
 arch/arm64/kvm/hyp/nvhe/hyp-main.c |   6 +-
 arch/arm64/kvm/hyp/nvhe/tlb.c      |  10 +--
 arch/arm64/kvm/hyp/vhe/tlb.c       |  10 +--
 arch/arm64/kvm/mmu.c               |   1 -
 8 files changed, 65 insertions(+), 98 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index a7ab84f781f7..29697c5ab2c2 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -44,7 +44,7 @@
 
 #define __KVM_HOST_SMCCC_FUNC___kvm_hyp_init			0
 #define __KVM_HOST_SMCCC_FUNC___kvm_vcpu_run			1
-#define __KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context		2
+#define __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_local_all		2
 #define __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa		3
 #define __KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid		4
 #define __KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context		5
@@ -182,7 +182,7 @@ DECLARE_KVM_NVHE_SYM(__per_cpu_end);
 DECLARE_KVM_HYP_SYM(__bp_harden_hyp_vecs);
 #define __bp_harden_hyp_vecs	CHOOSE_HYP_SYM(__bp_harden_hyp_vecs)
 
-extern void __kvm_flush_vm_context(void);
+extern void __kvm_tlb_flush_local_all(void);
 extern void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t ipa,
 				     int level);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527f7d..5309216e4a94 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -70,9 +70,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
 void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
 
 struct kvm_vmid {
-	/* The VMID generation used for the virt. memory system */
-	u64    vmid_gen;
-	u32    vmid;
+	atomic64_t id;
 };
 
 struct kvm_s2_mmu {
@@ -631,7 +629,6 @@ void kvm_arm_resume_guest(struct kvm *kvm);
 		ret;							\
 	})
 
-void force_vm_exit(const cpumask_t *mask);
 void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
 
 int handle_exit(struct kvm_vcpu *vcpu, int exception_index);
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index c3080966ef83..43e83df87e3a 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -252,7 +252,8 @@ static __always_inline u64 kvm_get_vttbr(struct kvm_s2_mmu *mmu)
 	u64 cnp = system_supports_cnp() ? VTTBR_CNP_BIT : 0;
 
 	baddr = mmu->pgd_phys;
-	vmid_field = (u64)vmid->vmid << VTTBR_VMID_SHIFT;
+	vmid_field = atomic64_read(&vmid->id) << VTTBR_VMID_SHIFT;
+	vmid_field &= VTTBR_VMID_MASK(kvm_get_vmid_bits());
 	return kvm_phys_to_vttbr(baddr) | vmid_field | cnp;
 }
 
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 7f06ba76698d..c63242db2d42 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -31,6 +31,7 @@
 #include <asm/tlbflush.h>
 #include <asm/cacheflush.h>
 #include <asm/cpufeature.h>
+#include <asm/lib_asid.h>
 #include <asm/virt.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_asm.h>
@@ -55,10 +56,10 @@ static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
 unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
 DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
 
-/* The VMID used in the VTTBR */
-static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
-static u32 kvm_next_vmid;
-static DEFINE_SPINLOCK(kvm_vmid_lock);
+static DEFINE_PER_CPU(atomic64_t, active_vmids);
+static DEFINE_PER_CPU(u64, reserved_vmids);
+
+static struct asid_info vmid_info;
 
 static bool vgic_present;
 
@@ -486,85 +487,22 @@ bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
 	return vcpu_mode_priv(vcpu);
 }
 
-/* Just ensure a guest exit from a particular CPU */
-static void exit_vm_noop(void *info)
-{
-}
-
-void force_vm_exit(const cpumask_t *mask)
+static void vmid_flush_cpu_ctxt(void)
 {
-	preempt_disable();
-	smp_call_function_many(mask, exit_vm_noop, NULL, true);
-	preempt_enable();
+	kvm_call_hyp(__kvm_tlb_flush_local_all);
 }
 
-/**
- * need_new_vmid_gen - check that the VMID is still valid
- * @vmid: The VMID to check
- *
- * return true if there is a new generation of VMIDs being used
- *
- * The hardware supports a limited set of values with the value zero reserved
- * for the host, so we check if an assigned value belongs to a previous
- * generation, which requires us to assign a new value. If we're the first to
- * use a VMID for the new generation, we must flush necessary caches and TLBs
- * on all CPUs.
- */
-static bool need_new_vmid_gen(struct kvm_vmid *vmid)
+static void vmid_set_reserved_bits(struct asid_info *info)
 {
-	u64 current_vmid_gen = atomic64_read(&kvm_vmid_gen);
-	smp_rmb(); /* Orders read of kvm_vmid_gen and kvm->arch.vmid */
-	return unlikely(READ_ONCE(vmid->vmid_gen) != current_vmid_gen);
+	bitmap_clear(info->map, 0, NUM_CTXT_ASIDS(info));
 }
-
 /**
  * update_vmid - Update the vmid with a valid VMID for the current generation
  * @vmid: The stage-2 VMID information struct
  */
 static void update_vmid(struct kvm_vmid *vmid)
 {
-	if (!need_new_vmid_gen(vmid))
-		return;
-
-	spin_lock(&kvm_vmid_lock);
-
-	/*
-	 * We need to re-check the vmid_gen here to ensure that if another vcpu
-	 * already allocated a valid vmid for this vm, then this vcpu should
-	 * use the same vmid.
-	 */
-	if (!need_new_vmid_gen(vmid)) {
-		spin_unlock(&kvm_vmid_lock);
-		return;
-	}
-
-	/* First user of a new VMID generation? */
-	if (unlikely(kvm_next_vmid == 0)) {
-		atomic64_inc(&kvm_vmid_gen);
-		kvm_next_vmid = 1;
-
-		/*
-		 * On SMP we know no other CPUs can use this CPU's or each
-		 * other's VMID after force_vm_exit returns since the
-		 * kvm_vmid_lock blocks them from reentry to the guest.
-		 */
-		force_vm_exit(cpu_all_mask);
-		/*
-		 * Now broadcast TLB + ICACHE invalidation over the inner
-		 * shareable domain to make sure all data structures are
-		 * clean.
-		 */
-		kvm_call_hyp(__kvm_flush_vm_context);
-	}
-
-	vmid->vmid = kvm_next_vmid;
-	kvm_next_vmid++;
-	kvm_next_vmid &= (1 << kvm_get_vmid_bits()) - 1;
-
-	smp_wmb();
-	WRITE_ONCE(vmid->vmid_gen, atomic64_read(&kvm_vmid_gen));
-
-	spin_unlock(&kvm_vmid_lock);
+	asid_check_context(&vmid_info, &vmid->id, NULL);
 }
 
 static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
@@ -728,8 +666,6 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 		 */
 		cond_resched();
 
-		update_vmid(&vcpu->arch.hw_mmu->vmid);
-
 		check_vcpu_requests(vcpu);
 
 		/*
@@ -739,6 +675,15 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 		 */
 		preempt_disable();
 
+		/*
+		 * The ASID/VMID allocator only tracks active VMIDs per
+		 * physical CPU, and therefore the VMID allocated may not be
+		 * preserved on VMID roll-over if the task was preempted,
+		 * making a thread's VMID inactive. So we need to call
+		 * update_vttbr in non-premptible context.
+		 */
+		update_vmid(&vcpu->arch.hw_mmu->vmid);
+
 		kvm_pmu_flush_hwstate(vcpu);
 
 		local_irq_disable();
@@ -777,8 +722,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
 		 */
 		smp_store_mb(vcpu->mode, IN_GUEST_MODE);
 
-		if (ret <= 0 || need_new_vmid_gen(&vcpu->arch.hw_mmu->vmid) ||
-		    kvm_request_pending(vcpu)) {
+		if (ret <= 0 || kvm_request_pending(vcpu)) {
 			vcpu->mode = OUTSIDE_GUEST_MODE;
 			isb(); /* Ensure work in x_flush_hwstate is committed */
 			kvm_pmu_sync_hwstate(vcpu);
@@ -1460,6 +1404,8 @@ static void cpu_hyp_reset(void)
 {
 	if (!is_kernel_in_hyp_mode())
 		__hyp_reset_vectors();
+
+	kvm_call_hyp(__kvm_tlb_flush_local_all);
 }
 
 /*
@@ -1635,9 +1581,32 @@ static bool init_psci_relay(void)
 
 static int init_common_resources(void)
 {
+	struct asid_info *info = &vmid_info;
+	int err;
+
+	/*
+	 * Initialize the ASID allocator telling it to allocate a single
+	 * VMID per VM.
+	 */
+	err = asid_allocator_init(info, kvm_get_vmid_bits(), false);
+	if (err) {
+		kvm_err("Failed to initialize VMID allocator.\n");
+		return err;
+	}
+
+	info->active = &active_vmids;
+	info->reserved = &reserved_vmids;
+	info->flush_cpu_ctxt_cb = vmid_flush_cpu_ctxt;
+	info->set_reserved_bits = vmid_set_reserved_bits;
+
 	return kvm_set_ipa_limit();
 }
 
+static void free_common_resources(void)
+{
+	asid_allocator_free(&vmid_info);
+}
+
 static int init_subsystems(void)
 {
 	int err = 0;
@@ -1918,7 +1887,7 @@ int kvm_arch_init(void *opaque)
 
 	err = kvm_arm_init_sve();
 	if (err)
-		return err;
+		goto out_err;
 
 	if (!in_hyp_mode) {
 		err = init_hyp_mode();
@@ -1952,6 +1921,7 @@ int kvm_arch_init(void *opaque)
 	if (!in_hyp_mode)
 		teardown_hyp_mode();
 out_err:
+	free_common_resources();
 	return err;
 }
 
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 936328207bde..62027448d534 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -25,9 +25,9 @@ static void handle___kvm_vcpu_run(struct kvm_cpu_context *host_ctxt)
 	cpu_reg(host_ctxt, 1) =  __kvm_vcpu_run(kern_hyp_va(vcpu));
 }
 
-static void handle___kvm_flush_vm_context(struct kvm_cpu_context *host_ctxt)
+static void handle___kvm_tlb_flush_local_all(struct kvm_cpu_context *host_ctxt)
 {
-	__kvm_flush_vm_context();
+	__kvm_tlb_flush_local_all();
 }
 
 static void handle___kvm_tlb_flush_vmid_ipa(struct kvm_cpu_context *host_ctxt)
@@ -112,7 +112,7 @@ typedef void (*hcall_t)(struct kvm_cpu_context *);
 
 static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__kvm_vcpu_run),
-	HANDLE_FUNC(__kvm_flush_vm_context),
+	HANDLE_FUNC(__kvm_tlb_flush_local_all),
 	HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa),
 	HANDLE_FUNC(__kvm_tlb_flush_vmid),
 	HANDLE_FUNC(__kvm_flush_cpu_context),
diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
index 229b06748c20..3f1fc5125e9e 100644
--- a/arch/arm64/kvm/hyp/nvhe/tlb.c
+++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
@@ -138,10 +138,10 @@ void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu)
 	__tlb_switch_to_host(&cxt);
 }
 
-void __kvm_flush_vm_context(void)
+void __kvm_tlb_flush_local_all(void)
 {
-	dsb(ishst);
-	__tlbi(alle1is);
+	dsb(nshst);
+	__tlbi(alle1);
 
 	/*
 	 * VIPT and PIPT caches are not affected by VMID, so no maintenance
@@ -153,7 +153,7 @@ void __kvm_flush_vm_context(void)
 	 *
 	 */
 	if (icache_is_vpipt())
-		asm volatile("ic ialluis");
+		asm volatile("ic iallu" : : );
 
-	dsb(ish);
+	dsb(nsh);
 }
diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
index 66f17349f0c3..89f229e77b7d 100644
--- a/arch/arm64/kvm/hyp/vhe/tlb.c
+++ b/arch/arm64/kvm/hyp/vhe/tlb.c
@@ -142,10 +142,10 @@ void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu)
 	__tlb_switch_to_host(&cxt);
 }
 
-void __kvm_flush_vm_context(void)
+void __kvm_tlb_flush_local_all(void)
 {
-	dsb(ishst);
-	__tlbi(alle1is);
+	dsb(nshst);
+	__tlbi(alle1);
 
 	/*
 	 * VIPT and PIPT caches are not affected by VMID, so no maintenance
@@ -157,7 +157,7 @@ void __kvm_flush_vm_context(void)
 	 *
 	 */
 	if (icache_is_vpipt())
-		asm volatile("ic ialluis");
+		asm volatile("ic iallu" : : );
 
-	dsb(ish);
+	dsb(nsh);
 }
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..4933fc9a13fb 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -390,7 +390,6 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu)
 	mmu->kvm = kvm;
 	mmu->pgt = pgt;
 	mmu->pgd_phys = __pa(pgt->pgd);
-	mmu->vmid.vmid_gen = 0;
 	return 0;
 
 out_destroy_pgtable:
-- 
2.17.1



From ruifeng.zhang0110 at gmail.com  Wed Apr 14 12:26:48 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Wed, 14 Apr 2021 19:26:48 +0800
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <74b3ff57-473f-4d5a-daf8-ecbb0761abb2@arm.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
 <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
 <87o8eimmyw.mognet@arm.com>
 <CAG7+-3NaUAvjv9=9HZ4jQU=DVcZW6gRKZg9ZjutL3aKnnC4FLw@mail.gmail.com>
 <74b3ff57-473f-4d5a-daf8-ecbb0761abb2@arm.com>
Message-ID: <CAG7+-3P6FYhqmt3p6g8b5ZXzaFW2pfx-vOZJYwuLCKXVqfFMVw@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?14??? ??5:43???
>
> On 13/04/2021 15:26, Ruifeng Zhang wrote:
> > Thanks for your review. Patch-v2 that solve the capacity issue will be
> > uploaded as soon as possible. : )
> >
> > Valentin Schneider <valentin.schneider at arm.com> ?2021?4?13??? ??7:40???
> >>
> >> On 13/04/21 14:13, Ruifeng Zhang wrote:
> >>> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???
> >>>> I'm not fluent at all in armv7 (or most aarch32 compat mode stuff), but
> >>>> I couldn't find anything about MPIDR format differences:
> >>>>
> >>>>   DDI 0487G.a G8.2.113
> >>>>   """
> >>>>   AArch32 System register MPIDR bits [31:0] are architecturally mapped to
> >>>>   AArch64 System register MPIDR_EL1[31:0].
> >>>>   """
> >>>>
> >>>> Peeking at some armv7 doc and arm/kernel/topology.c the layout really looks
> >>>> just the same, i.e. for both of them, with your example of:
> >>>
> >>> The cortex-a7 spec DDI0464F 4.3.5
> >>> https://developer.arm.com/documentation/ddi0464/f/?lang=en
> >>>
> >>
> >> Ah, so that's where the core_id=bit[1:0] comes from. That does still
> >> conform to the MPIDR format, and as you point out below that's being parsed
> >> the same (aff2, aff1, aff0) == mpidr([23:16][15:8][7:0])
> >>
> >>> The current arch/arm/kernel/topology code parse the MPIDR with a armv7 format.
> >>> the parse code is:
> >>> void store_cpu_topology(unsigned int cpuid)
> >>> {
> >>>     ...
> >>>     cpuid_topo->thread_id = -1;
> >>>     cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> >>>     cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> >>>     ...
> >>> }
> >>>>
> >>>>   core0: 0000000080000000
> >>>>   core1: 0000000080000100
> >>>>   core2: 0000000080000200
> >>>>   ...
> >>>>
> >>>> we'll get:
> >>>>
> >>>>   |       | aff2 | aff1 | aff0 |
> >>>>   |-------+------+------+------|
> >>>>   | Core0 |    0 |    0 |    0 |
> >>>>   | Core1 |    0 |    1 |    0 |
> >>>>   | Core2 |    0 |    2 |    0 |
> >>>>       ...
> >>>>
> >>>> Now, arm64 doesn't fallback to MPIDR for topology information anymore since
> >>>>
> >>>>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
> >>>>
> >>>> so without DT we would get:
> >>>>   |       | package_id | core_id |
> >>>>   |-------+------------+---------|
> >>>>   | Core0 |          0 |       0 |
> >>>>   | Core1 |          0 |       1 |
> >>>>   | Core2 |          0 |       2 |
> >>>>
> >>>> Whereas with an arm kernel we'll end up parsing MPIDR as:
> >>>>   |       | package_id | core_id |
> >>>>   |-------+------------+---------|
> >>>>   | Core0 |          0 |       0 |
> >>>>   | Core1 |          1 |       0 |
> >>>>   | Core2 |          2 |       0 |
> >>>>
> >>>> Did I get this right? Is this what you're observing?
> >>>
> >>> Yes, this is a problem if an armv8.2 or above cpu is running a 32-bit
> >>> kernel on EL1.
> >>
> >>
> >> With the above MPIDR(_EL1) values, you would have the same problem in
> >> aarch64 mode on any kernel predating
> >>
> >>   3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")
> >>
> >> since all Aff0 values are 0. Arguably those MPIDR(_EL1) values don't
> >> make much sense (cores in the same cluster should have different Aff0
> >> values, unless SMT), but in arm64 that's usually "corrected" by DT.
> >>
> >> As you pointed out, arm doesn't currently leverage the cpu-map DT entry. I
> >> don't see any obvious problem with adding support for it, so if you can fix
> >> the capacity issue Dietmar reported, I think we could consider it.
>
> Coming back to your original patch. You want to use parse_dt_topology()
> from drivers/base/arch_topology.c to be able detect a cpu-map in dt and
> so bypassing the read of mpidr in store_cpu_topology()?

Yes
>
> Looks like sc9863a has two frequency domains (1.6 and 1.2GHz). So
> technically it's a big.LITTLE system (based only on max CPU frequency
> (not on uarch) differences).
> But the dts file doesn't contain any `capacity-dmips-mhz` entries? So
> asymmetric CPU capacity (even only based on max CPU frequency) detection
> won't kick in. Since you don't have any uarch diffs, you would have to
> specify `capacity-dmips-mhz = <1024>` for each CPU.

Yes, for capacity, the DT should have a capacity-dmips-MHz entry or a
clock-frequency entry (for A7 and A15 only).
The sc9863a dts is a vendor file,  in my opinion is not appropriate to
be update with this series.
What do you think if I independently update the sc9863a dts file later?


From wangqing at vivo.com  Wed Apr 14 12:48:49 2021
From: wangqing at vivo.com (Wang Qing)
Date: Wed, 14 Apr 2021 19:48:49 +0800
Subject: [PATCH V3] watchdog: mtk: support pre-timeout when the bark irq is
 available
Message-ID: <1618400929-17013-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

By default, the pretimeout notification shall occur one second earlier
than the timeout.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 62 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..7bef1e3
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -234,18 +235,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
 	int ret;
 
-	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
 	if (ret < 0)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	reg &= ~WDT_MODE_IRQ_EN;
+	if (wdt_dev->pretimeout)
+		reg |= WDT_MODE_IRQ_EN;
+	else
+		reg &= ~WDT_MODE_IRQ_EN;
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+				   unsigned int timeout)
+{
+	wdd->pretimeout = timeout;
+	return mtk_wdt_start(wdd);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
+	void __iomem *wdt_base = mtk_wdt->wdt_base;
+
+	watchdog_notify_pretimeout(wdd);
+	/*
+	 * Guaranteed to be reset when the timeout
+	 * expires under any situations
+	 */
+	mdelay(1000*wdd->pretimeout);
+	writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +282,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +305,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +317,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+							&mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = 1;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
@@ -360,7 +413,6 @@ static struct platform_driver mtk_wdt_driver = {
 };
 
 module_platform_driver(mtk_wdt_driver);
-
 module_param(timeout, uint, 0);
 MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
 
-- 
2.7.4



From willy at infradead.org  Wed Apr 14 12:50:52 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Wed, 14 Apr 2021 12:50:52 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414101044.19da09df@carbon>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
Message-ID: <20210414115052.GS2531743@casper.infradead.org>

On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> Yes, indeed! - And very frustrating.  It's keeping me up at night.
> I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> me that I don't sleep well with these kind of dreams ;-)

Then you're going to love this ... even with the latest patch, there's
still a problem.  Because dma_addr_t is still 64-bit aligned _as a type_,
that forces the union to be 64-bit aligned (as we already knew and worked
around), but what I'd forgotten is that forces the entirety of struct
page to be 64-bit aligned.  Which means ...

        /* size: 40, cachelines: 1, members: 4 */
        /* padding: 4 */
        /* forced alignments: 1 */
        /* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));

.. that we still have a hole!  It's just moved from being at offset 4
to being at offset 36.

> That said, I think we need to have a quicker fix for the immediate
> issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
> it leaves[3] in struct page.  In[3] you mention ppc32, does it only
> happens on certain 32-bit archs?

AFAICT it happens on mips32, ppc32, arm32 and arc.  It doesn't happen
on x86-32 because dma_addr_t is 32-bit aligned.

Doing this fixes it:

+++ b/include/linux/types.h
@@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
  * so they don't care about the size of the actual bus addresses.
  */
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
-typedef u64 dma_addr_t;
+typedef u64 __attribute__((aligned(sizeof(void *)))) dma_addr_t;
 #else
 typedef u32 dma_addr_t;
 #endif

> I'm seriously considering removing page_pool's support for doing/keeping
> DMA-mappings on 32-bit arch's.  AFAIK only a single driver use this.

... if you're going to do that, then we don't need to do this.


From ilias.apalodimas at linaro.org  Wed Apr 14 12:56:02 2021
From: ilias.apalodimas at linaro.org (Ilias Apalodimas)
Date: Wed, 14 Apr 2021 14:56:02 +0300
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414115052.GS2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
Message-ID: <YHbYUvOYedojZAoB@apalos.home>

On Wed, Apr 14, 2021 at 12:50:52PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> > Yes, indeed! - And very frustrating.  It's keeping me up at night.
> > I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> > me that I don't sleep well with these kind of dreams ;-)
> 
> Then you're going to love this ... even with the latest patch, there's
> still a problem.  Because dma_addr_t is still 64-bit aligned _as a type_,
> that forces the union to be 64-bit aligned (as we already knew and worked
> around), but what I'd forgotten is that forces the entirety of struct
> page to be 64-bit aligned.  Which means ...
> 
>         /* size: 40, cachelines: 1, members: 4 */
>         /* padding: 4 */
>         /* forced alignments: 1 */
>         /* last cacheline: 40 bytes */
> } __attribute__((__aligned__(8)));
> 
> .. that we still have a hole!  It's just moved from being at offset 4
> to being at offset 36.
> 
> > That said, I think we need to have a quicker fix for the immediate
> > issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
> > it leaves[3] in struct page.  In[3] you mention ppc32, does it only
> > happens on certain 32-bit archs?
> 
> AFAICT it happens on mips32, ppc32, arm32 and arc.  It doesn't happen
> on x86-32 because dma_addr_t is 32-bit aligned.
> 
> Doing this fixes it:
> 
> +++ b/include/linux/types.h
> @@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
>   * so they don't care about the size of the actual bus addresses.
>   */
>  #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> -typedef u64 dma_addr_t;
> +typedef u64 __attribute__((aligned(sizeof(void *)))) dma_addr_t;
>  #else
>  typedef u32 dma_addr_t;
>  #endif
> 
> > I'm seriously considering removing page_pool's support for doing/keeping
> > DMA-mappings on 32-bit arch's.  AFAIK only a single driver use this.
> 
> ... if you're going to do that, then we don't need to do this.

FWIW I already proposed that to Matthew in private a few days ago...
II am not even sure the AM572x has that support.  I'd much prefer getting rid
of it as well, instead of overcomplicating the struct for a device noone is
going to need.

Cheers
/Ilias


From madvenka at linux.microsoft.com  Wed Apr 14 13:09:09 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Wed, 14 Apr 2021 07:09:09 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210402032404.47239-2-madvenka@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
Message-ID: <dfa80040-8ac2-3694-4f69-a10b0e5dd959@linux.microsoft.com>

Hi Mark Rutland, Mark Brown,

Could you take a look at this version for proper stack termination and let me know
what you think?

Thanks!

Madhavan

On 4/1/21 10:24 PM, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> Reliable stacktracing requires that we identify when a stacktrace is
> terminated early. We can do this by ensuring all tasks have a final
> frame record at a known location on their task stack, and checking
> that this is the final frame record in the chain.
> 
> Kernel Tasks
> ============
> 
> All tasks except the idle task have a pt_regs structure right after the
> task stack. This is called the task pt_regs. The pt_regs structure has a
> special stackframe field. Make this stackframe field the final frame in the
> task stack. This needs to be done in copy_thread() which initializes a new
> task's pt_regs and initial CPU context.
> 
> For the idle task, there is no task pt_regs. For our purpose, we need one.
> So, create a pt_regs just like other kernel tasks and make
> pt_regs->stackframe the final frame in the idle task stack. This needs to be
> done at two places:
> 
> 	- On the primary CPU, the boot task runs. It calls start_kernel()
> 	  and eventually becomes the idle task for the primary CPU. Just
> 	  before start_kernel() is called, set up the final frame.
> 
> 	- On each secondary CPU, a startup task runs that calls
> 	  secondary_startup_kernel() and eventually becomes the idle task
> 	  on the secondary CPU. Just before secondary_start_kernel() is
> 	  called, set up the final frame.
> 
> User Tasks
> ==========
> 
> User tasks are initially set up like kernel tasks when they are created.
> Then, they return to userland after fork via ret_from_fork(). After that,
> they enter the kernel only on an EL0 exception. (In arm64, system calls are
> also EL0 exceptions). The EL0 exception handler stores state in the task
> pt_regs and calls different functions based on the type of exception. The
> stack trace for an EL0 exception must end at the task pt_regs. So, make
> task pt_regs->stackframe as the final frame in the EL0 exception stack.
> 
> In summary, task pt_regs->stackframe is where a successful stack trace ends.
> 
> Stack trace termination
> =======================
> 
> In the unwinder, terminate the stack trace successfully when
> task_pt_regs(task)->stackframe is reached. For stack traces in the kernel,
> this will correctly terminate the stack trace at the right place.
> 
> However, debuggers terminate the stack trace when FP == 0. In the
> pt_regs->stackframe, the PC is 0 as well. So, stack traces taken in the
> debugger may print an extra record 0x0 at the end. While this is not
> pretty, this does not do any harm. This is a small price to pay for
> having reliable stack trace termination in the kernel.
> 
> Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
> ---
>  arch/arm64/kernel/entry.S      |  8 +++++---
>  arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
>  arch/arm64/kernel/process.c    |  5 +++++
>  arch/arm64/kernel/stacktrace.c | 10 +++++-----
>  4 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index a31a0a713c85..e2dc2e998934 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -261,16 +261,18 @@ alternative_else_nop_endif
>  	stp	lr, x21, [sp, #S_LR]
>  
>  	/*
> -	 * For exceptions from EL0, terminate the callchain here.
> +	 * For exceptions from EL0, terminate the callchain here at
> +	 * task_pt_regs(current)->stackframe.
> +	 *
>  	 * For exceptions from EL1, create a synthetic frame record so the
>  	 * interrupted code shows up in the backtrace.
>  	 */
>  	.if \el == 0
> -	mov	x29, xzr
> +	stp	xzr, xzr, [sp, #S_STACKFRAME]
>  	.else
>  	stp	x29, x22, [sp, #S_STACKFRAME]
> -	add	x29, sp, #S_STACKFRAME
>  	.endif
> +	add	x29, sp, #S_STACKFRAME
>  
>  #ifdef CONFIG_ARM64_SW_TTBR0_PAN
>  alternative_if_not ARM64_HAS_PAN
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 840bda1869e9..743c019a42c7 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -393,6 +393,23 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
>  	ret	x28
>  SYM_FUNC_END(__create_page_tables)
>  
> +	/*
> +	 * The boot task becomes the idle task for the primary CPU. The
> +	 * CPU startup task on each secondary CPU becomes the idle task
> +	 * for the secondary CPU.
> +	 *
> +	 * The idle task does not require pt_regs. But create a dummy
> +	 * pt_regs so that task_pt_regs(idle_task)->stackframe can be
> +	 * set up to be the final frame on the idle task stack just like
> +	 * all the other kernel tasks. This helps the unwinder to
> +	 * terminate the stack trace at a well-known stack offset.
> +	 */
> +	.macro setup_final_frame
> +	sub	sp, sp, #PT_REGS_SIZE
> +	stp	xzr, xzr, [sp, #S_STACKFRAME]
> +	add	x29, sp, #S_STACKFRAME
> +	.endm
> +
>  /*
>   * The following fragment of code is executed with the MMU enabled.
>   *
> @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>  #endif
>  	bl	switch_to_vhe			// Prefer VHE if possible
>  	add	sp, sp, #16
> -	mov	x29, #0
> -	mov	x30, #0
> -	b	start_kernel
> +	setup_final_frame
> +	bl	start_kernel
> +	nop
>  SYM_FUNC_END(__primary_switched)
>  
>  	.pushsection ".rodata", "a"
> @@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
>  	cbz	x2, __secondary_too_slow
>  	msr	sp_el0, x2
>  	scs_load x2, x3
> -	mov	x29, #0
> -	mov	x30, #0
> +	setup_final_frame
>  
>  #ifdef CONFIG_ARM64_PTR_AUTH
>  	ptrauth_keys_init_cpu x2, x3, x4, x5
>  #endif
>  
> -	b	secondary_start_kernel
> +	bl	secondary_start_kernel
> +	nop
>  SYM_FUNC_END(__secondary_switched)
>  
>  SYM_FUNC_START_LOCAL(__secondary_too_slow)
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 325c83b1a24d..906baa232a89 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -437,6 +437,11 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>  	}
>  	p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>  	p->thread.cpu_context.sp = (unsigned long)childregs;
> +	/*
> +	 * For the benefit of the unwinder, set up childregs->stackframe
> +	 * as the final frame for the new task.
> +	 */
> +	p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
>  
>  	ptrace_hw_copy_thread(p);
>  
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index ad20981dfda4..72f5af8c69dc 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  	unsigned long fp = frame->fp;
>  	struct stack_info info;
>  
> -	/* Terminal record; nothing to unwind */
> -	if (!fp)
> +	if (!tsk)
> +		tsk = current;
> +
> +	/* Final frame; nothing to unwind */
> +	if (fp == (unsigned long) task_pt_regs(tsk)->stackframe)
>  		return -ENOENT;
>  
>  	if (fp & 0xf)
>  		return -EINVAL;
>  
> -	if (!tsk)
> -		tsk = current;
> -
>  	if (!on_accessible_stack(tsk, fp, &info))
>  		return -EINVAL;
>  
> 


From linux at roeck-us.net  Wed Apr 14 13:13:01 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 14 Apr 2021 05:13:01 -0700
Subject: [PATCH V3] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1618400929-17013-1-git-send-email-wangqing@vivo.com>
References: <1618400929-17013-1-git-send-email-wangqing@vivo.com>
Message-ID: <1e60551b-4961-91d6-1ea8-7e3b6becd385@roeck-us.net>

On 4/14/21 4:48 AM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> By default, the pretimeout notification shall occur one second earlier
> than the timeout.
> 
> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> 
> V3:
> - Modify the pretimeout behavior, manually reset after the pretimeout
> - is processed and wait until timeout.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 62 ++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 57 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..7bef1e3
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -234,18 +235,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>  	int ret;
>  
> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>  	if (ret < 0)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	reg &= ~WDT_MODE_IRQ_EN;
> +	if (wdt_dev->pretimeout)
> +		reg |= WDT_MODE_IRQ_EN;
> +	else
> +		reg &= ~WDT_MODE_IRQ_EN;
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> +				   unsigned int timeout)
> +{
> +	wdd->pretimeout = timeout;
> +	return mtk_wdt_start(wdd);

The watchdog is not necessarily active here.

> +}
> +
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
> +
> +	watchdog_notify_pretimeout(wdd);
> +	/*
> +	 * Guaranteed to be reset when the timeout
> +	 * expires under any situations
> +	 */
> +	mdelay(1000*wdd->pretimeout);

That is not how this is supposed to work. The idea with a pretimeout is that the
real watchdog reset will happen under all circumstances, and that executing
the pretimeout (and changing some hardware registers) is not a prerequisite
for the real timeout to happen. After all, the system could be stuck hard, with
interrupts disabled.

On top of that, just sleeping here while waiting for the real timeout and
then resetting the system isn't the idea either. On a single core system this
will just hang. On a multi-core system, who knows if userspace managed to ping
the watchdog in the meantime.

Unless there is a means to trigger the watchdog twice, without intervention,
the first time generating an interrupt and the second time resetting the system,
there is no way for this to work. I don't see how this chip really supports
pretimeout. It seems that it supports either a hard reset or generating an
interrupt on watchdog timeout, and there is only a single timeout.

If you have a use case for generating an interrupt and resetting the system via
software (ie panic) _instead_ of having it generate a hard reset, please feel
free to submit a patch along that line, together with a description of its use
case.

Thanks,
Guenter

> +	writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,12 +282,21 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
>  	.stop		= mtk_wdt_stop,
>  	.ping		= mtk_wdt_ping,
>  	.set_timeout	= mtk_wdt_set_timeout,
> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>  	.restart	= mtk_wdt_restart,
>  };
>  
> @@ -267,7 +305,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +317,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +							&mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = 1;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> @@ -360,7 +413,6 @@ static struct platform_driver mtk_wdt_driver = {
>  };
>  
>  module_platform_driver(mtk_wdt_driver);
> -
>  module_param(timeout, uint, 0);
>  MODULE_PARM_DESC(timeout, "Watchdog heartbeat in seconds");
>  
> 



From ruifeng.zhang0110 at gmail.com  Wed Apr 14 13:23:25 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Wed, 14 Apr 2021 20:23:25 +0800
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
Message-ID: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>

From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>

In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
version, one of them is the kernel running on EL1 using aarch32.
                user(EL0)             kernel(EL1)
sc9863a_go      aarch32               aarch32
sc9863a         aarch64               aarch64

When kernel runs on EL1 using aarch32, the topology will parse wrong.
For example,
The MPIDR has been written to the chip register in armv8.2 format.
For example,
core0: 0000000080000000
core1: 0000000080000100
core2: 0000000080000200
...

It will parse to:
|       | aff2 | packageid | coreid |
|-------+------+-----------+--------|
| Core0 |    0 |         0 |    0   |
| Core1 |    0 |         1 |    0   |
| Core2 |    0 |         2 |    0   |
|  ...  |      |           |        |

The wrong topology is that all of the coreid are 0 and unexpected
packageid.

The reason is the MPIDR format is different between armv7 and armv8.2.
armv7 (A7) mpidr is:
[11:8]      [7:2]       [1:0]
cluster     reserved    cpu
The cortex-a7 spec DDI0464F 4.3.5
https://developer.arm.com/documentation/ddi0464/f/?lang=en

armv8.2 (A55) mpidr is:
[23:16]     [15:8]      [7:0]
cluster     cpu         thread

The current arch/arm/kernel/topology code parse the MPIDR with a armv7
format. The parse code is:
void store_cpu_topology(unsigned int cpuid)
{
    ...
    cpuid_topo->thread_id = -1;
    cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
    cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
    ...
}

Ruifeng Zhang (1):
  arm: topology: parse the topology from the dt

 arch/arm/kernel/topology.c    | 22 ++++++----------------
 drivers/base/arch_topology.c  |  4 ++--
 include/linux/arch_topology.h |  1 +
 3 files changed, 9 insertions(+), 18 deletions(-)

-- 
2.17.1



From ruifeng.zhang0110 at gmail.com  Wed Apr 14 13:23:26 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Wed, 14 Apr 2021 20:23:26 +0800
Subject: [PATCH v2 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
Message-ID: <20210414122326.5255-2-ruifeng.zhang0110@gmail.com>

From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>

The arm topology still parse from the MPIDR, but it is incomplete.  When
the armv8.2 or above cpu runs kernel in EL1 with aarch32 mode, it will
parse out the wrong topology.

Changed:
1) Arm using the same parse_dt_topology function as arm64.
2) For compatibility to keep the function of get capacity from default
   cputype, renamed arm parse_dt_topology to get_efficiency_capacity and
   delete related logic of parse from dt.
3) The update_cpu_capacity function should not depend on the topology, so
   it is moved to the beginning of store_cpu_topology.

The arm device boot step is to look for the efficiency_capacity firstly.
Then parse the topology and capacity from dt to replace efficiency value.

Signed-off-by: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
Signed-off-by: Nianfu Bai <nianfu.bai at unisoc.com>
---
 arch/arm/kernel/topology.c    | 22 ++++++----------------
 drivers/base/arch_topology.c  |  4 ++--
 include/linux/arch_topology.h |  1 +
 3 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index ef0058de432b..93d875320cc4 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -72,7 +72,6 @@ static unsigned long *__cpu_capacity;
 #define cpu_capacity(cpu)	__cpu_capacity[cpu]
 
 static unsigned long middle_capacity = 1;
-static bool cap_from_dt = true;
 
 /*
  * Iterate all CPUs' descriptor in DT and compute the efficiency
@@ -82,7 +81,7 @@ static bool cap_from_dt = true;
  * 'average' CPU is of middle capacity. Also see the comments near
  * table_efficiency[] and update_cpu_capacity().
  */
-static void __init parse_dt_topology(void)
+static void __init get_coretype_capacity(void)
 {
 	const struct cpu_efficiency *cpu_eff;
 	struct device_node *cn = NULL;
@@ -105,13 +104,6 @@ static void __init parse_dt_topology(void)
 			continue;
 		}
 
-		if (topology_parse_cpu_capacity(cn, cpu)) {
-			of_node_put(cn);
-			continue;
-		}
-
-		cap_from_dt = false;
-
 		for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
 			if (of_device_is_compatible(cn, cpu_eff->compatible))
 				break;
@@ -151,9 +143,6 @@ static void __init parse_dt_topology(void)
 	else
 		middle_capacity = ((max_capacity / 3)
 				>> (SCHED_CAPACITY_SHIFT-1)) + 1;
-
-	if (cap_from_dt)
-		topology_normalize_cpu_scale();
 }
 
 /*
@@ -163,7 +152,7 @@ static void __init parse_dt_topology(void)
  */
 static void update_cpu_capacity(unsigned int cpu)
 {
-	if (!cpu_capacity(cpu) || cap_from_dt)
+	if (!cpu_capacity(cpu))
 		return;
 
 	topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);
@@ -173,7 +162,7 @@ static void update_cpu_capacity(unsigned int cpu)
 }
 
 #else
-static inline void parse_dt_topology(void) {}
+static inline void get_cputype_capacity(void) {}
 static inline void update_cpu_capacity(unsigned int cpuid) {}
 #endif
 
@@ -187,6 +176,8 @@ void store_cpu_topology(unsigned int cpuid)
 	struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
 	unsigned int mpidr;
 
+	update_cpu_capacity(cpuid);
+
 	if (cpuid_topo->package_id != -1)
 		goto topology_populated;
 
@@ -221,8 +212,6 @@ void store_cpu_topology(unsigned int cpuid)
 		cpuid_topo->package_id = -1;
 	}
 
-	update_cpu_capacity(cpuid);
-
 	pr_info("CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
 		cpuid, cpu_topology[cpuid].thread_id,
 		cpu_topology[cpuid].core_id,
@@ -241,5 +230,6 @@ void __init init_cpu_topology(void)
 	reset_cpu_topology();
 	smp_wmb();
 
+	get_coretype_capacity();
 	parse_dt_topology();
 }
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index de8587cc119e..a45aec356ec4 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -295,7 +295,7 @@ static void parsing_done_workfn(struct work_struct *work)
 core_initcall(free_raw_capacity);
 #endif
 
-#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
 /*
  * This function returns the logic cpu number of the node.
  * There are basically three kinds of return values:
@@ -441,7 +441,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
 	return 0;
 }
 
-static int __init parse_dt_topology(void)
+int __init parse_dt_topology(void)
 {
 	struct device_node *cn, *map;
 	int ret = 0;
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 0f6cd6b73a61..cfa5a5072aa0 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -66,6 +66,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 #define topology_llc_cpumask(cpu)	(&cpu_topology[cpu].llc_sibling)
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
+int __init parse_dt_topology(void);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 void update_siblings_masks(unsigned int cpu);
 void remove_cpu_topology(unsigned int cpuid);
-- 
2.17.1



From broonie at kernel.org  Wed Apr 14 13:24:05 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 14 Apr 2021 13:24:05 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <20210413225310.k64wqjnst7cia4ft@treble>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com>
 <20210409223227.rvf6tfhvgnpzmabn@treble>
 <20210412165933.GD5379@sirena.org.uk>
 <20210413225310.k64wqjnst7cia4ft@treble>
Message-ID: <20210414122405.GB4535@sirena.org.uk>

On Tue, Apr 13, 2021 at 05:53:10PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 12, 2021 at 05:59:33PM +0100, Mark Brown wrote:

> > Some more explict pointer to live patching as the only user would
> > definitely be good but I think the more important thing would be writing
> > down any assumptions in the API that aren't already written down and

> Something like so?

Yeah, looks reasonable - it'll need rebasing against current code as I
moved the docs in the source out of the arch code into the header this
cycle (they were copied verbatim in a couple of places).

>  #ifdef CONFIG_ARCH_STACKWALK
>  
>  /**
> - * stack_trace_consume_fn - Callback for arch_stack_walk()
> + * stack_trace_consume_fn() - Callback for arch_stack_walk()
>   * @cookie:	Caller supplied pointer handed back by arch_stack_walk()
>   * @addr:	The stack entry address to consume
>   *

> @@ -35,7 +35,7 @@ unsigned int stack_trace_save_user(unsigned long *store, unsigned int size);
>   */
>  typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr);
>  /**
> - * arch_stack_walk - Architecture specific function to walk the stack
> + * arch_stack_walk() - Architecture specific function to walk the stack
>   * @consume_entry:	Callback which is invoked by the architecture code for
>   *			each entry.
>   * @cookie:		Caller supplied pointer which is handed back to

These two should be separated.
-------------- 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/20210414/c9b0cd92/attachment.sig>

From joe.burmeister at devtank.co.uk  Wed Apr 14 13:25:07 2021
From: joe.burmeister at devtank.co.uk (Joe Burmeister)
Date: Wed, 14 Apr 2021 13:25:07 +0100
Subject: [PATCH] Remove BCM2835 SPI chipselect limit.
Message-ID: <20210414122507.203348-1-joe.burmeister@devtank.co.uk>

The limit of 4 chipselects for the BCM2835 was not required and also was
not inforced. Without inforcement it was possible to make a device tree
over this limit which would trample memory.

The chipselect count is now obtained from the device tree and expanded
if more devices are added.

Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>
---
 drivers/spi/spi-bcm2835.c | 114 +++++++++++++++++++++++++++++++++-----
 1 file changed, 101 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index aab6c7e5c114..4f215ec3bd1b 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -28,6 +28,7 @@
 #include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h> /* FIXME: using chip internals */
 #include <linux/gpio/driver.h> /* FIXME: using chip internals */
+#include <linux/of_gpio.h>
 #include <linux/of_irq.h>
 #include <linux/spi/spi.h>
 
@@ -134,7 +135,8 @@ struct bcm2835_spi {
 	int tx_prologue;
 	int rx_prologue;
 	unsigned int tx_spillover;
-	u32 prepare_cs[BCM2835_SPI_NUM_CS];
+	unsigned int allocated_cs_num;
+	u32 *prepare_cs;
 
 	struct dentry *debugfs_dir;
 	u64 count_transfer_polling;
@@ -147,9 +149,9 @@ struct bcm2835_spi {
 	unsigned int rx_dma_active;
 	struct dma_async_tx_descriptor *fill_tx_desc;
 	dma_addr_t fill_tx_addr;
-	struct dma_async_tx_descriptor *clear_rx_desc[BCM2835_SPI_NUM_CS];
+	struct dma_async_tx_descriptor **clear_rx_desc;
 	dma_addr_t clear_rx_addr;
-	u32 clear_rx_cs[BCM2835_SPI_NUM_CS] ____cacheline_aligned;
+	u32 *clear_rx_cs;
 };
 
 #if defined(CONFIG_DEBUG_FS)
@@ -859,14 +861,18 @@ static void bcm2835_dma_release(struct spi_controller *ctlr,
 	if (ctlr->dma_tx) {
 		dmaengine_terminate_sync(ctlr->dma_tx);
 
-		if (bs->fill_tx_desc)
+		if (bs->fill_tx_desc) {
 			dmaengine_desc_free(bs->fill_tx_desc);
+			bs->fill_tx_desc = NULL;
+		}
 
-		if (bs->fill_tx_addr)
+		if (bs->fill_tx_addr) {
 			dma_unmap_page_attrs(ctlr->dma_tx->device->dev,
 					     bs->fill_tx_addr, sizeof(u32),
 					     DMA_TO_DEVICE,
 					     DMA_ATTR_SKIP_CPU_SYNC);
+			bs->fill_tx_addr = 0;
+		}
 
 		dma_release_channel(ctlr->dma_tx);
 		ctlr->dma_tx = NULL;
@@ -875,15 +881,19 @@ static void bcm2835_dma_release(struct spi_controller *ctlr,
 	if (ctlr->dma_rx) {
 		dmaengine_terminate_sync(ctlr->dma_rx);
 
-		for (i = 0; i < BCM2835_SPI_NUM_CS; i++)
-			if (bs->clear_rx_desc[i])
+		for (i = 0; i < bs->allocated_cs_num; i++)
+			if (bs->clear_rx_desc[i]) {
 				dmaengine_desc_free(bs->clear_rx_desc[i]);
+				bs->clear_rx_desc[i] = NULL;
+			}
 
-		if (bs->clear_rx_addr)
+		if (bs->clear_rx_addr) {
 			dma_unmap_single(ctlr->dma_rx->device->dev,
 					 bs->clear_rx_addr,
-					 sizeof(bs->clear_rx_cs),
+					 sizeof(u32) * bs->allocated_cs_num,
 					 DMA_TO_DEVICE);
+			bs->clear_rx_addr = 0;
+		}
 
 		dma_release_channel(ctlr->dma_rx);
 		ctlr->dma_rx = NULL;
@@ -978,7 +988,7 @@ static int bcm2835_dma_init(struct spi_controller *ctlr, struct device *dev,
 
 	bs->clear_rx_addr = dma_map_single(ctlr->dma_rx->device->dev,
 					   bs->clear_rx_cs,
-					   sizeof(bs->clear_rx_cs),
+					   sizeof(u32) * bs->allocated_cs_num,
 					   DMA_TO_DEVICE);
 	if (dma_mapping_error(ctlr->dma_rx->device->dev, bs->clear_rx_addr)) {
 		dev_err(dev, "cannot map clear_rx_cs - not using DMA mode\n");
@@ -987,7 +997,7 @@ static int bcm2835_dma_init(struct spi_controller *ctlr, struct device *dev,
 		goto err_release;
 	}
 
-	for (i = 0; i < BCM2835_SPI_NUM_CS; i++) {
+	for (i = 0; i < bs->allocated_cs_num; i++) {
 		bs->clear_rx_desc[i] = dmaengine_prep_dma_cyclic(ctlr->dma_rx,
 					   bs->clear_rx_addr + i * sizeof(u32),
 					   sizeof(u32), 0,
@@ -1209,6 +1219,48 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 	struct gpio_chip *chip;
 	u32 cs;
 
+	if (spi->chip_select >= bs->allocated_cs_num) {
+		unsigned int new_allocated_cs_num = spi->chip_select + 1;
+		void *new_prepare_cs, *new_clear_rx_desc, *new_clear_rx_cs;
+		int err;
+
+		dev_info(&spi->dev, "Increasing CS count to %u\n",
+			new_allocated_cs_num);
+
+		bcm2835_dma_release(ctlr, bs);
+
+		new_prepare_cs  = kmalloc_array(new_allocated_cs_num,
+			sizeof(u32), GFP_KERNEL);
+		new_clear_rx_desc = kmalloc_array(new_allocated_cs_num,
+			sizeof(struct dma_async_tx_descriptor *), GFP_KERNEL);
+		new_clear_rx_cs = kmalloc_array(new_allocated_cs_num,
+			sizeof(u32), GFP_DMA);
+
+		if (!new_prepare_cs || !new_clear_rx_desc || !new_clear_rx_cs) {
+			dev_err(&spi->dev, "Failed to allocate new CS arrays.\n");
+			return -ENOMEM;
+		}
+
+		memcpy(new_prepare_cs, bs->prepare_cs,
+			bs->allocated_cs_num * sizeof(u32));
+
+		kfree(bs->prepare_cs);
+		kfree(bs->clear_rx_desc);
+		kfree(bs->clear_rx_cs);
+
+		bs->prepare_cs  = new_prepare_cs;
+		bs->clear_rx_desc = new_clear_rx_desc;
+		bs->clear_rx_cs = new_clear_rx_cs;
+
+		bs->allocated_cs_num = new_allocated_cs_num;
+
+		err = bcm2835_dma_init(ctlr, &spi->dev, bs);
+		if (err) {
+			dev_err(&spi->dev, "Failed to reinit DMA after CS count change.");
+			return err;
+		}
+	}
+
 	/*
 	 * Precalculate SPI slave's CS register value for ->prepare_message():
 	 * The driver always uses software-controlled GPIO chip select, hence
@@ -1233,7 +1285,7 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 						    BCM2835_SPI_CS_CLEAR_RX;
 		dma_sync_single_for_device(ctlr->dma_rx->device->dev,
 					   bs->clear_rx_addr,
-					   sizeof(bs->clear_rx_cs),
+					   sizeof(u32) * bs->allocated_cs_num,
 					   DMA_TO_DEVICE);
 	}
 
@@ -1248,6 +1300,7 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 	 */
 	if (spi->cs_gpiod)
 		return 0;
+
 	if (spi->chip_select > 1) {
 		/* error in the case of native CS requested with CS > 1
 		 * officially there is a CS2, but it is not documented
@@ -1286,10 +1339,25 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 	return 0;
 }
 
+
+#ifdef CONFIG_OF
+static int bcm2835_spi_get_num_chipselect(struct platform_device *pdev)
+{
+	return max_t(int, of_gpio_named_count(pdev->dev.of_node, "cs-gpios"), BCM2835_SPI_NUM_CS);
+}
+#else
+static int bcm2835_spi_get_num_chipselect(struct platform_device *pdev)
+{
+	return BCM2835_SPI_NUM_CS;
+}
+#endif
+
+
 static int bcm2835_spi_probe(struct platform_device *pdev)
 {
 	struct spi_controller *ctlr;
 	struct bcm2835_spi *bs;
+	int num_chipselect;
 	int err;
 
 	ctlr = devm_spi_alloc_master(&pdev->dev, ALIGN(sizeof(*bs),
@@ -1297,12 +1365,14 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
 	if (!ctlr)
 		return -ENOMEM;
 
+	num_chipselect = bcm2835_spi_get_num_chipselect(pdev);
+
 	platform_set_drvdata(pdev, ctlr);
 
 	ctlr->use_gpio_descriptors = true;
 	ctlr->mode_bits = BCM2835_SPI_MODE_BITS;
 	ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
-	ctlr->num_chipselect = BCM2835_SPI_NUM_CS;
+	ctlr->num_chipselect = num_chipselect;
 	ctlr->setup = bcm2835_spi_setup;
 	ctlr->transfer_one = bcm2835_spi_transfer_one;
 	ctlr->handle_err = bcm2835_spi_handle_err;
@@ -1311,6 +1381,20 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
 
 	bs = spi_controller_get_devdata(ctlr);
 	bs->ctlr = ctlr;
+	bs->allocated_cs_num = num_chipselect;
+
+	bs->prepare_cs = kmalloc_array(num_chipselect, sizeof(u32), GFP_KERNEL);
+	if (!bs->prepare_cs)
+		return -ENOMEM;
+
+	bs->clear_rx_desc = kmalloc_array(num_chipselect,
+		sizeof(struct dma_async_tx_descriptor *), GFP_KERNEL);
+	if (!bs->clear_rx_desc)
+		return -ENOMEM;
+
+	bs->clear_rx_cs = kmalloc_array(num_chipselect, sizeof(u32), GFP_DMA);
+	if (!bs->clear_rx_cs)
+		return -ENOMEM;
 
 	bs->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(bs->regs))
@@ -1378,6 +1462,10 @@ static int bcm2835_spi_remove(struct platform_device *pdev)
 
 	clk_disable_unprepare(bs->clk);
 
+	kfree(bs->prepare_cs);
+	kfree(bs->clear_rx_desc);
+	kfree(bs->clear_rx_cs);
+
 	return 0;
 }
 
-- 
2.30.2



From broonie at kernel.org  Wed Apr 14 13:35:48 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 14 Apr 2021 13:35:48 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
 <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
 <20210413110255.GB5586@sirena.org.uk>
 <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>
Message-ID: <20210414123548.GC4535@sirena.org.uk>

On Wed, Apr 14, 2021 at 05:23:38AM -0500, Madhavan T. Venkataraman wrote:
> On 4/13/21 6:02 AM, Mark Brown wrote:
> > On Mon, Apr 12, 2021 at 02:55:35PM -0500, Madhavan T. Venkataraman wrote:

> >> 3. We are going to assume that the reliable unwinder is only for livepatch purposes
> >>    and will only be invoked on a task that is not currently running. The task either
> > 
> > The reliable unwinder can also be invoked on itself.

> I have not called out the self-directed case because I am assuming that the reliable unwinder
> is only used for livepatch. So, AFAICT, this is applicable to the task that performs the
> livepatch operation itself. In this case, there should be no unreliable functions on the
> self-directed stack trace (otherwise, livepatching would always fail).

Someone might've added a probe of some kind which upsets things so
there's a possibility things might fail.  Like you say there's no way a
system in such a state can succesfully apply a live patch but we might
still run into that situation.

> >> I suggest we do (3) first. Then, review the assembly functions to do (1). Then, review the
> >> remaining ones to see which ones must be blacklisted, if any.

> > I'm not clear what the concrete steps you're planning to do first are
> > there - your 3 seems like a statement of assumptions.  For flagging
> > functions I do think it'd be safer to default to assuming that all
> > SYM_CODE functions can't be unwound reliably rather than only explicitly
> > listing ones that cause problems.

> They are not assumptions. They are true statements. But I probably did not do a good
> job of explaining. But Josh sent out a patch that updates the documentation that
> explains what I said a lot better.

You say true statements, I say assumptions :)
-------------- 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/20210414/186c3f30/attachment.sig>

From ruifeng.zhang0110 at gmail.com  Wed Apr 14 13:38:07 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Wed, 14 Apr 2021 20:38:07 +0800
Subject: [PATCH v2 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <20210414122326.5255-2-ruifeng.zhang0110@gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <20210414122326.5255-2-ruifeng.zhang0110@gmail.com>
Message-ID: <CAG7+-3OiFQDrZAasnFyJaYobgXMN8S9MTtHjzOB+_W9DAMeFwA@mail.gmail.com>

Dear Dietmar,

In the last, update_cpu_capacity(cpuid) must be called in
store_cpu_topology because the cpuid_topo->package_id is always be the
initialization value.

Because of added the DT parsing logic, the cpuid_topo->package_id will
be parse in driver/base/arch_topology and the update_cpu_capacity
can't be called if DT has cpu-map.

Update cpu capacity isn't related with cpu topology, so move it to the
beginning of this function.

Please help to review and test the new patch, thanks.

Ruifeng Zhang <ruifeng.zhang0110 at gmail.com> ?2021?4?14??? ??8:24???
>
> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>
> The arm topology still parse from the MPIDR, but it is incomplete.  When
> the armv8.2 or above cpu runs kernel in EL1 with aarch32 mode, it will
> parse out the wrong topology.
>
> Changed:
> 1) Arm using the same parse_dt_topology function as arm64.
> 2) For compatibility to keep the function of get capacity from default
>    cputype, renamed arm parse_dt_topology to get_efficiency_capacity and
>    delete related logic of parse from dt.
> 3) The update_cpu_capacity function should not depend on the topology, so
>    it is moved to the beginning of store_cpu_topology.
>
> The arm device boot step is to look for the efficiency_capacity firstly.
> Then parse the topology and capacity from dt to replace efficiency value.
>
> Signed-off-by: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
> Signed-off-by: Nianfu Bai <nianfu.bai at unisoc.com>
> ---
>  arch/arm/kernel/topology.c    | 22 ++++++----------------
>  drivers/base/arch_topology.c  |  4 ++--
>  include/linux/arch_topology.h |  1 +
>  3 files changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index ef0058de432b..93d875320cc4 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -72,7 +72,6 @@ static unsigned long *__cpu_capacity;
>  #define cpu_capacity(cpu)      __cpu_capacity[cpu]
>
>  static unsigned long middle_capacity = 1;
> -static bool cap_from_dt = true;
>
>  /*
>   * Iterate all CPUs' descriptor in DT and compute the efficiency
> @@ -82,7 +81,7 @@ static bool cap_from_dt = true;
>   * 'average' CPU is of middle capacity. Also see the comments near
>   * table_efficiency[] and update_cpu_capacity().
>   */
> -static void __init parse_dt_topology(void)
> +static void __init get_coretype_capacity(void)
>  {
>         const struct cpu_efficiency *cpu_eff;
>         struct device_node *cn = NULL;
> @@ -105,13 +104,6 @@ static void __init parse_dt_topology(void)
>                         continue;
>                 }
>
> -               if (topology_parse_cpu_capacity(cn, cpu)) {
> -                       of_node_put(cn);
> -                       continue;
> -               }
> -
> -               cap_from_dt = false;
> -
>                 for (cpu_eff = table_efficiency; cpu_eff->compatible; cpu_eff++)
>                         if (of_device_is_compatible(cn, cpu_eff->compatible))
>                                 break;
> @@ -151,9 +143,6 @@ static void __init parse_dt_topology(void)
>         else
>                 middle_capacity = ((max_capacity / 3)
>                                 >> (SCHED_CAPACITY_SHIFT-1)) + 1;
> -
> -       if (cap_from_dt)
> -               topology_normalize_cpu_scale();
>  }
>
>  /*
> @@ -163,7 +152,7 @@ static void __init parse_dt_topology(void)
>   */
>  static void update_cpu_capacity(unsigned int cpu)
>  {
> -       if (!cpu_capacity(cpu) || cap_from_dt)
> +       if (!cpu_capacity(cpu))
>                 return;
>
>         topology_set_cpu_scale(cpu, cpu_capacity(cpu) / middle_capacity);
> @@ -173,7 +162,7 @@ static void update_cpu_capacity(unsigned int cpu)
>  }
>
>  #else
> -static inline void parse_dt_topology(void) {}
> +static inline void get_cputype_capacity(void) {}
>  static inline void update_cpu_capacity(unsigned int cpuid) {}
>  #endif
>
> @@ -187,6 +176,8 @@ void store_cpu_topology(unsigned int cpuid)
>         struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
>         unsigned int mpidr;
>
> +       update_cpu_capacity(cpuid);
> +
>         if (cpuid_topo->package_id != -1)
>                 goto topology_populated;
>
> @@ -221,8 +212,6 @@ void store_cpu_topology(unsigned int cpuid)
>                 cpuid_topo->package_id = -1;
>         }
>
> -       update_cpu_capacity(cpuid);
> -
>         pr_info("CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
>                 cpuid, cpu_topology[cpuid].thread_id,
>                 cpu_topology[cpuid].core_id,
> @@ -241,5 +230,6 @@ void __init init_cpu_topology(void)
>         reset_cpu_topology();
>         smp_wmb();
>
> +       get_coretype_capacity();
>         parse_dt_topology();
>  }
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index de8587cc119e..a45aec356ec4 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -295,7 +295,7 @@ static void parsing_done_workfn(struct work_struct *work)
>  core_initcall(free_raw_capacity);
>  #endif
>
> -#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
>  /*
>   * This function returns the logic cpu number of the node.
>   * There are basically three kinds of return values:
> @@ -441,7 +441,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
>         return 0;
>  }
>
> -static int __init parse_dt_topology(void)
> +int __init parse_dt_topology(void)
>  {
>         struct device_node *cn, *map;
>         int ret = 0;
> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index 0f6cd6b73a61..cfa5a5072aa0 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -66,6 +66,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>  #define topology_llc_cpumask(cpu)      (&cpu_topology[cpu].llc_sibling)
>  void init_cpu_topology(void);
>  void store_cpu_topology(unsigned int cpuid);
> +int __init parse_dt_topology(void);
>  const struct cpumask *cpu_coregroup_mask(int cpu);
>  void update_siblings_masks(unsigned int cpu);
>  void remove_cpu_topology(unsigned int cpuid);
> --
> 2.17.1
>


From Jonathan.Cameron at Huawei.com  Wed Apr 14 13:42:40 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Wed, 14 Apr 2021 13:42:40 +0100
Subject: =?UTF-8?Q?[=E2=80=9DPATCH=E2=80=9D?= 2/5] PCI: armada8k: Add
 link-down handle
In-Reply-To: <1618241456-27200-3-git-send-email-bpeled@marvell.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
 <1618241456-27200-3-git-send-email-bpeled@marvell.com>
Message-ID: <20210414134240.000057b4@Huawei.com>

On Mon, 12 Apr 2021 18:30:53 +0300
<bpeled at marvell.com> wrote:

> From: Ben Peled <bpeled at marvell.com>
> 
> In PCIE ISR routine caused by RST_LINK_DOWN
> we schedule work to handle the link-down procedure.
> Link-down procedure will:
> 1. Remove PCIe bus
> 2. Reset the MAC
> 3. Reconfigure link back up
> 4. Rescan PCIe bus
> 
> Signed-off-by: Ben Peled <bpeled at marvell.com>

Trivial comment inline.

Also, something odd with quotes around PATCH in the title you probably
want to clean up.

> ---
>  drivers/pci/controller/dwc/pcie-armada8k.c | 68 ++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
> index b2278b1..4eb8607 100644
> --- a/drivers/pci/controller/dwc/pcie-armada8k.c
> +++ b/drivers/pci/controller/dwc/pcie-armada8k.c
> @@ -22,6 +22,8 @@
>  #include <linux/resource.h>
>  #include <linux/of_pci.h>
>  #include <linux/of_irq.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -33,6 +35,9 @@ struct armada8k_pcie {
>  	struct clk *clk_reg;
>  	struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
>  	unsigned int phy_count;
> +	struct regmap *sysctrl_base;
> +	u32 mac_rest_bitmask;
> +	struct work_struct recover_link_work;
>  };
>  
>  #define PCIE_VENDOR_REGS_OFFSET		0x8000
> @@ -73,6 +78,8 @@ struct armada8k_pcie {
>  #define AX_USER_DOMAIN_MASK		0x3
>  #define AX_USER_DOMAIN_SHIFT		4
>  
> +#define UNIT_SOFT_RESET_CONFIG_REG	0x268
> +
>  #define to_armada8k_pcie(x)	dev_get_drvdata((x)->dev)
>  
>  static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie)
> @@ -224,6 +231,49 @@ static int armada8k_pcie_host_init(struct pcie_port *pp)
>  
>  	return 0;
>  }
> +static void armada8k_pcie_recover_link(struct work_struct *ws)
> +{
> +	struct armada8k_pcie *pcie = container_of(ws, struct armada8k_pcie, recover_link_work);
> +	struct pcie_port *pp = &pcie->pci->pp;
> +	struct pci_bus *bus = pp->bridge->bus;
> +	struct pci_dev *root_port;
> +	int ret;
> +
> +	root_port = pci_get_slot(bus, 0);
> +	if (!root_port) {
> +		dev_err(pcie->pci->dev, "failed to get root port\n");
> +		return;
> +	}
> +	pci_lock_rescan_remove();
> +	pci_stop_and_remove_bus_device(root_port);
> +	/*
> +	 * Sleep needed to make sure all pcie transactions and access
> +	 * are flushed before resetting the mac
> +	 */
> +	msleep(100);
> +
> +	/* Reset mac */
> +	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> +				pcie->mac_rest_bitmask, 0, NULL, false, true);
> +	udelay(1);
> +	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> +				pcie->mac_rest_bitmask, pcie->mac_rest_bitmask,
> +				NULL, false, true);
> +	udelay(1);
> +	ret = armada8k_pcie_host_init(pp);
> +	if (ret) {
> +		dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
> +		pci_unlock_rescan_remove();
> +		pci_dev_put(root_port);
> +		return;
> +	}
> +
> +	bus = NULL;
> +	while ((bus = pci_find_next_bus(bus)) != NULL)
> +		pci_rescan_bus(bus);
> +	pci_unlock_rescan_remove();
> +	pci_dev_put(root_port);
> +}
>  
>  static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
>  {
> @@ -262,6 +312,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
>  		 * initiate a link retrain. If link retrains were
>  		 * possible, that is.
>  		 */
> +		if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
> +			schedule_work(&pcie->recover_link_work);
> +
>  		dev_dbg(pci->dev, "%s: link went down\n", __func__);
>  	}
>  
> @@ -330,6 +383,8 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->pci = pci;
>  
> +	INIT_WORK(&pcie->recover_link_work, armada8k_pcie_recover_link);
> +
>  	pcie->clk = devm_clk_get(dev, NULL);
>  	if (IS_ERR(pcie->clk))
>  		return PTR_ERR(pcie->clk);
> @@ -357,6 +412,19 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
>  		goto fail_clkreg;
>  	}
>  
> +	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> +						       "marvell,system-controller");
> +	if (IS_ERR(pcie->sysctrl_base)) {
> +		dev_warn(dev, "failed to find marvell,system-controller\n");
> +		pcie->sysctrl_base = 0x0;

= NULL; ?

> +	}
> +
> +	ret = of_property_read_u32(pdev->dev.of_node, "marvell,mac-reset-bit-mask",
> +				   &pcie->mac_rest_bitmask);
> +	if (ret < 0) {
> +		dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
> +		pcie->mac_rest_bitmask = 0x0;
> +	}
>  	ret = armada8k_pcie_setup_phys(pcie);
>  	if (ret)
>  		goto fail_clkreg;



From michael at walle.cc  Wed Apr 14 13:56:30 2021
From: michael at walle.cc (Michael Walle)
Date: Wed, 14 Apr 2021 14:56:30 +0200
Subject: [PATCH net-next v2 1/2] of: net: pass the dst buffer to
 of_get_mac_address()
In-Reply-To: <20210414053336.GQ6021@kadam>
References: <20210414053336.GQ6021@kadam>
Message-ID: <cf5c86dd6492b9c1907ea69e2d660eb2@walle.cc>

Hi Dan,

Am 2021-04-14 07:33, schrieb Dan Carpenter:
> url:
> https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
> base:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> cc0626c2aaed8e475efdd85fa374b497a7192e35
> config: x86_64-randconfig-m001-20210406 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> 
> smatch warnings:
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2069 axienet_probe()
> warn: passing a valid pointer to 'PTR_ERR'
> 
> vim +/PTR_ERR +2069 drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> 
> 522856cefaf09d Robert Hancock      2019-06-06  2060  	/* Check for
> Ethernet core IRQ (optional) */
> 522856cefaf09d Robert Hancock      2019-06-06  2061  	if (lp->eth_irq 
> <= 0)
> 522856cefaf09d Robert Hancock      2019-06-06  2062
> 		dev_info(&pdev->dev, "Ethernet core IRQ not defined\n");
> 522856cefaf09d Robert Hancock      2019-06-06  2063
> 8a3b7a252dca9f Daniel Borkmann     2012-01-19  2064  	/* Retrieve the
> MAC address */
> 411b125c6ace1f Michael Walle       2021-04-06  2065  	ret =
> of_get_mac_address(pdev->dev.of_node, mac_addr);
> 411b125c6ace1f Michael Walle       2021-04-06  2066  	if (!ret) {
> 411b125c6ace1f Michael Walle       2021-04-06  2067
> 		axienet_set_mac_address(ndev, mac_addr);
> 411b125c6ace1f Michael Walle       2021-04-06  2068  	} else {
> d05a9ed5c3a773 Robert Hancock      2019-06-06 @2069
> 		dev_warn(&pdev->dev, "could not find MAC address property: %ld\n",
> d05a9ed5c3a773 Robert Hancock      2019-06-06  2070  			 
> PTR_ERR(mac_addr));
> 
>   ^^^^^^^^^^^^^^^^^
> This should print "ret".

Thanks, this was fixed (in the now merged) v4. I forgot
to add you to that huge CC list. Sorry for that.

-michael


From krzysztof.kozlowski at canonical.com  Wed Apr 14 14:00:00 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 15:00:00 +0200
Subject: [PATCH v2 1/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC board dts support
In-Reply-To: <1618383117-17179-2-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
 <1618383117-17179-2-git-send-email-dillon.minfei@gmail.com>
Message-ID: <6d8a5d4c-b741-dc7a-7cfb-eb66a642cb6f@canonical.com>

On 14/04/2021 08:51, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
> v2: no changes
> 
>  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 297c87f45db8..24bdfbd4853f 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -206,6 +206,7 @@ properties:
>                - fsl,imx6q-sabreauto
>                - fsl,imx6q-sabrelite
>                - fsl,imx6q-sabresd
> +              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules

You break here the alphabetical order. Should be after dmo,imx6q-edmqmx6.


Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Wed Apr 14 14:01:35 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 15:01:35 +0200
Subject: [PATCH v2 4/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <1618383117-17179-5-git-send-email-dillon.minfei@gmail.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
 <1618383117-17179-5-git-send-email-dillon.minfei@gmail.com>
Message-ID: <9f8f3d55-b3f3-54d6-9143-5d676a21c901@canonical.com>

On 14/04/2021 08:51, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> Add vendor prefix for DaSheng, Inc.
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v2: new add
> 
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)

This should be the first patch in the series.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


Best regards,
Krzysztof


From gabriel.fernandez at foss.st.com  Wed Apr 14 14:03:36 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Wed, 14 Apr 2021 15:03:36 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <20210408185731.135511-2-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
Message-ID: <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>

Hi Marek,

Thanks for the patchset

On 4/8/21 8:57 PM, Marek Vasut wrote:
> The ETHCK_K are modeled as composite clock of MUX and GATE, however per
> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. Peripheral
> clock distribution for Ethernet, ETHPTPDIV divider is attached past the
> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN gate.
> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
> in use, ETHCKEN gate can be turned off. Current driver does not permit
> that, fix it.

I don"t understand, it's already the case.

ETHCK_K it's a composite with a MUX and a GATE.

ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV (no gate)

If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.

  

> This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
> ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
> NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent clock
> to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
> ETHPTP_K remain functional as before.
>
> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>      Figure 83. Peripheral clock distribution for Ethernet
>      https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf
>
> Signed-off-by: Marek Vasut<marex at denx.de>
> Cc: Alexandre Torgue<alexandre.torgue at foss.st.com>
> Cc: Christophe Roullier<christophe.roullier at foss.st.com>
> Cc: Gabriel Fernandez<gabriel.fernandez at foss.st.com>
> Cc: Patrice Chotard<patrice.chotard at foss.st.com>
> Cc: Patrick Delaunay<patrick.delaunay at foss.st.com>
> Cc: Stephen Boyd<swboyd at chromium.org>
> Cc:linux-clk at vger.kernel.org
> Cc:linux-stm32 at st-md-mailman.stormreply.com
> To:linux-arm-kernel at lists.infradead.org
> ---
>   drivers/clk/clk-stm32mp1.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
> index a875649df8b8..a7c7f544ee5d 100644
> --- a/drivers/clk/clk-stm32mp1.c
> +++ b/drivers/clk/clk-stm32mp1.c
> @@ -1949,7 +1949,6 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
>   	KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
>   	KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
>   	KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
> -	KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
>   
>   	/* Particulary Kernel Clocks (no mux or no gate) */
>   	MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
> @@ -1958,11 +1957,16 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
>   	MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
>   	MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
>   
> -	COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
> +	COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
>   		  CLK_SET_RATE_NO_REPARENT,
>   		  _NO_GATE,
>   		  _MMUX(M_ETHCK),
> -		  _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
> +		  _NO_DIV),
> +
> +	MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
assigned parent with ETHCK_K will not work
> +
> +	DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |

CLK_OPS_PARENT_ENABLE flags not useful with a divider.

best regards

Gabriel

> +	    CLK_SET_RATE_NO_REPARENT, RCC_ETHCKSELR, 4, 4, 0),
>   
>   	/* RTC clock */
>   	DIV(NO_ID, "ck_hse_rtc", "ck_hse", 0, RCC_RTCDIVR, 0, 6, 0),


From kernelfans at gmail.com  Wed Apr 14 14:19:51 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Wed, 14 Apr 2021 21:19:51 +0800
Subject: [RFC 1/8] arm64/mm: split out __create_pgd_mapping() routines
In-Reply-To: <20210410095654.24102-2-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
 <20210410095654.24102-2-kernelfans@gmail.com>
Message-ID: <CAFgQCTuKiMBrwmePSQwDAz0cZap9=8J0NZb9YQ=S1fS=NKUKCw@mail.gmail.com>

On Sat, Apr 10, 2021 at 5:57 PM Pingfan Liu <kernelfans at gmail.com> wrote:
>
> Split out the routines for __create_pgd_mapping(), in order to use it
> to generate two sets of operations for CONFIG_PGTABLE_LEVELS and
> CONFIG_PGTABLE_LEVELS + 1
>
> Later the one generated with 'CONFIG_PGTABLE_LEVELS + 1' can be used for
> idmap if VA_BITS is too small to cover system RAM, which is located
> sufficiently high in the physical address space.
>
> Later, idmap can be created by __create_pgd_mapping() directly.
>
> Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Kristina Martsenko <kristina.martsenko at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Cc: Steven Price <steven.price at arm.com>
> Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
> Cc: Anshuman Khandual <anshuman.khandual at arm.com>
> Cc: Atish Patra <atish.patra at wdc.com>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: Logan Gunthorpe <logang at deltatee.com>
> Cc: Mark Brown <broonie at kernel.org>
> To: linux-arm-kernel at lists.infradead.org
> ---
>  arch/arm64/Kconfig          |   4 +
>  arch/arm64/mm/Makefile      |   2 +
>  arch/arm64/mm/idmap_mmu.c   |  45 ++++++
>  arch/arm64/mm/mmu.c         | 263 +-----------------------------------
>  arch/arm64/mm/mmu_include.c | 262 +++++++++++++++++++++++++++++++++++
>  5 files changed, 315 insertions(+), 261 deletions(-)
>  create mode 100644 arch/arm64/mm/idmap_mmu.c
>  create mode 100644 arch/arm64/mm/mmu_include.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..989fc501a1b4 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -327,6 +327,10 @@ config PGTABLE_LEVELS
>         default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
>         default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
>
> +config IDMAP_PGTABLE_EXPAND
> +       def_bool y
> +       depends on (ARM64_4K_PAGES && ARM64_VA_BITS_39) || (ARM64_64K_PAGES && ARM64_VA_BITS_42)
> +
>  config ARCH_SUPPORTS_UPROBES
>         def_bool y
>
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index f188c9092696..f9283cb9a201 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -3,6 +3,8 @@ 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
> +
> +obj-$(CONFIG_IDMAP_PGTABLE_EXPAND)     += idmap_mmu.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/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
> new file mode 100644
> index 000000000000..7e9a4f4017d3
> --- /dev/null
> +++ b/arch/arm64/mm/idmap_mmu.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/mm.h>
> +
> +#include <asm/barrier.h>
> +#include <asm/cputype.h>
> +#include <asm/fixmap.h>
> +#include <asm/kasan.h>
> +#include <asm/kernel-pgtable.h>
> +#include <asm/sections.h>
> +#include <asm/setup.h>
> +#include <linux/sizes.h>
> +#include <asm/tlb.h>
> +#include <asm/mmu_context.h>
> +#include <asm/ptdump.h>
> +#include <asm/tlbflush.h>
> +#include <asm/pgalloc.h>
> +
> +#if CONFIG_IDMAP_PGTABLE_EXPAND
> +
> +#if CONFIG_PGTABLE_LEVELS == 2
> +#define EXTEND_LEVEL 3
> +#elif CONFIG_PGTABLE_LEVELS == 3
> +#define EXTEND_LEVEL 4
> +#endif
> +
> +#undef CONFIG_PGTABLE_LEVELS
> +#define CONFIG_PGTABLE_LEVELS EXTEND_LEVEL

In order to take effect, the redefinition of CONFIG_PGTABLE_LEVELS
should be moved to the head of this file.

I will fix it in V2.

Thanks,
Pingfan


From bpeled at marvell.com  Wed Apr 14 14:20:49 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:49 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=200/5=5D=20Asynchronous=20linkdown=20recovery?=
Message-ID: <1618406454-7953-1-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

The following patches implement the required procedure to handle and recover from asynchronous PCIE link down events on Armada SoCs.

The procedure is defined as the following:
1) Prevent new access to the PCI-E I/F by disabling the LTSSM
2) Flush all pending transaction/access to the PCI-E I/F
3) HW reset the PCIE end point device (based on board support)
4) Reset the PCIE MAC
5) Reinitialize the PCIE root complex and enable the LTSSM

The execution of this procedure is triggered by the PCIE RST_LINK_DOWN interrupt

v1 --> v2
- Add missing device reset to link-down handle

Ben Peled (5):
  PCI: armada8k: Disable LTSSM on link down interrupts
  PCI: armada8k: Add link-down handle
  dt-bindings: pci: add system controller and MAC reset bit to    
    Armada 7K/8K controller bindings
  arm64: dts: marvell: add pcie mac reset to pcie
  PCI: armada8k: add device reset to link-down handle

 Documentation/devicetree/bindings/pci/pci-armada8k.txt |   6 +
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi          |   7 ++
 drivers/pci/controller/dwc/pcie-armada8k.c             | 127 ++++++++++++++++++++
 3 files changed, 140 insertions(+)

-- 
2.7.4



From bpeled at marvell.com  Wed Apr 14 14:20:51 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:51 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=202/5=5D=20PCI=3A=20armada8k=3A=20Add=20link-down=20handle?=
In-Reply-To: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618406454-7953-3-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

In PCIE ISR routine caused by RST_LINK_DOWN
we schedule work to handle the link-down procedure.
Link-down procedure will:
1. Remove PCIe bus
2. Reset the MAC
3. Reconfigure link back up
4. Rescan PCIe bus

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 69 ++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index b2278b1..34b253c 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -22,6 +22,8 @@
 #include <linux/resource.h>
 #include <linux/of_pci.h>
 #include <linux/of_irq.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #include "pcie-designware.h"
 
@@ -33,6 +35,9 @@ struct armada8k_pcie {
 	struct clk *clk_reg;
 	struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
 	unsigned int phy_count;
+	struct regmap *sysctrl_base;
+	u32 mac_rest_bitmask;
+	struct work_struct recover_link_work;
 };
 
 #define PCIE_VENDOR_REGS_OFFSET		0x8000
@@ -73,6 +78,8 @@ struct armada8k_pcie {
 #define AX_USER_DOMAIN_MASK		0x3
 #define AX_USER_DOMAIN_SHIFT		4
 
+#define UNIT_SOFT_RESET_CONFIG_REG	0x268
+
 #define to_armada8k_pcie(x)	dev_get_drvdata((x)->dev)
 
 static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie)
@@ -225,6 +232,50 @@ static int armada8k_pcie_host_init(struct pcie_port *pp)
 	return 0;
 }
 
+static void armada8k_pcie_recover_link(struct work_struct *ws)
+{
+	struct armada8k_pcie *pcie = container_of(ws, struct armada8k_pcie, recover_link_work);
+	struct pcie_port *pp = &pcie->pci->pp;
+	struct pci_bus *bus = pp->bridge->bus;
+	struct pci_dev *root_port;
+	int ret;
+
+	root_port = pci_get_slot(bus, 0);
+	if (!root_port) {
+		dev_err(pcie->pci->dev, "failed to get root port\n");
+		return;
+	}
+	pci_lock_rescan_remove();
+	pci_stop_and_remove_bus_device(root_port);
+	/*
+	 * Sleep needed to make sure all pcie transactions and access
+	 * are flushed before resetting the mac
+	 */
+	msleep(100);
+
+	/* Reset mac */
+	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
+				pcie->mac_rest_bitmask, 0, NULL, false, true);
+	udelay(1);
+	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
+				pcie->mac_rest_bitmask, pcie->mac_rest_bitmask,
+				NULL, false, true);
+	udelay(1);
+	ret = armada8k_pcie_host_init(pp);
+	if (ret) {
+		dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
+		pci_unlock_rescan_remove();
+		pci_dev_put(root_port);
+		return;
+	}
+
+	bus = NULL;
+	while ((bus = pci_find_next_bus(bus)) != NULL)
+		pci_rescan_bus(bus);
+	pci_unlock_rescan_remove();
+	pci_dev_put(root_port);
+}
+
 static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 {
 	struct armada8k_pcie *pcie = arg;
@@ -262,6 +313,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 		 * initiate a link retrain. If link retrains were
 		 * possible, that is.
 		 */
+		if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
+			schedule_work(&pcie->recover_link_work);
+
 		dev_dbg(pci->dev, "%s: link went down\n", __func__);
 	}
 
@@ -330,6 +384,8 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 
 	pcie->pci = pci;
 
+	INIT_WORK(&pcie->recover_link_work, armada8k_pcie_recover_link);
+
 	pcie->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(pcie->clk))
 		return PTR_ERR(pcie->clk);
@@ -357,6 +413,19 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 		goto fail_clkreg;
 	}
 
+	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+						       "marvell,system-controller");
+	if (IS_ERR(pcie->sysctrl_base)) {
+		dev_warn(dev, "failed to find marvell,system-controller\n");
+		pcie->sysctrl_base = 0x0;
+	}
+
+	ret = of_property_read_u32(pdev->dev.of_node, "marvell,mac-reset-bit-mask",
+				   &pcie->mac_rest_bitmask);
+	if (ret < 0) {
+		dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
+		pcie->mac_rest_bitmask = 0x0;
+	}
 	ret = armada8k_pcie_setup_phys(pcie);
 	if (ret)
 		goto fail_clkreg;
-- 
2.7.4



From bpeled at marvell.com  Wed Apr 14 14:20:52 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:52 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=203/5=5D=20dt-bindings=3A=20pci=3A=20add=20system=20controller=20and=20MAC=20reset=20bit=20to=20Armada=207K/8K=20controller=20bindings?=
In-Reply-To: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618406454-7953-4-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Adding optional system-controller and mac-reset-bit-mask
needed for linkdown procedure.

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 Documentation/devicetree/bindings/pci/pci-armada8k.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
index 7a813d0..2696e79 100644
--- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
+++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
@@ -24,6 +24,10 @@ Optional properties:
 - phy-names: names of the PHYs corresponding to the number of lanes.
 	Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
 	2 PHYs.
+- marvell,system-controller: address of system controller needed
+	in order to reset MAC used by link-down handle
+- marvell,mac-reset-bit-mask: MAC reset bit of system controller
+	needed in order to reset MAC used by link-down handle
 
 Example:
 
@@ -45,4 +49,6 @@ Example:
 		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
 		num-lanes = <1>;
 		clocks = <&cpm_syscon0 1 13>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(1)>;
 	};
-- 
2.7.4



From bpeled at marvell.com  Wed Apr 14 14:20:53 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:53 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=204/5=5D=20arm64=3A=20dts=3A=20marvell=3A=20add=20pcie=20mac=20reset=20to=20pcie?=
In-Reply-To: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618406454-7953-5-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Add system controller and reset bit to each pcie to enable pcie mac reset

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
index 9dcf16b..eb60e73 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
@@ -11,6 +11,7 @@
 #include "armada-common.dtsi"
 
 #define CP11X_PCIEx_CONF_BASE(iface)	(CP11X_PCIEx_MEM_BASE(iface) + CP11X_PCIEx_MEM_SIZE(iface))
+#define CP11X_PCIEx_MAC_RESET_BIT_MASK(n)	(0x1 << 11 + ((n + 2) % 3))
 
 / {
 	/*
@@ -513,6 +514,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 13>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(0)>;
 		status = "disabled";
 	};
 
@@ -538,6 +541,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 11>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(1)>;
 		status = "disabled";
 	};
 
@@ -563,6 +568,8 @@
 		num-lanes = <1>;
 		clock-names = "core", "reg";
 		clocks = <&CP11X_LABEL(clk) 1 12>, <&CP11X_LABEL(clk) 1 14>;
+		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
+		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(2)>;
 		status = "disabled";
 	};
 };
-- 
2.7.4



From bpeled at marvell.com  Wed Apr 14 14:20:54 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:54 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=205/5=5D=20PCI=3A=20armada8k=3A=20add=20device=20reset=20to=20link-down=20handle?=
In-Reply-To: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618406454-7953-6-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

Added pcie reset via gpio support as described in the
designware-pcie.txt DT binding document.
In cases link down cause still exist in device.
The device need to be reset to reestablish the link.
If reset-gpio pin provided in the device tree, then the linkdown
handle resets the device before reestablishing link.

Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 24 ++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index 34b253c..04bba97 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -24,6 +24,7 @@
 #include <linux/of_irq.h>
 #include <linux/mfd/syscon.h>
 #include <linux/regmap.h>
+#include <linux/of_gpio.h>
 
 #include "pcie-designware.h"
 
@@ -38,6 +39,8 @@ struct armada8k_pcie {
 	struct regmap *sysctrl_base;
 	u32 mac_rest_bitmask;
 	struct work_struct recover_link_work;
+	enum of_gpio_flags flags;
+	struct gpio_desc *reset_gpio;
 };
 
 #define PCIE_VENDOR_REGS_OFFSET		0x8000
@@ -247,9 +250,18 @@ static void armada8k_pcie_recover_link(struct work_struct *ws)
 	}
 	pci_lock_rescan_remove();
 	pci_stop_and_remove_bus_device(root_port);
+	/* Reset device if reset gpio is set */
+	if (pcie->reset_gpio) {
+		/* assert and then deassert the reset signal */
+		gpiod_set_value_cansleep(pcie->reset_gpio, 0);
+		msleep(100);
+		gpiod_set_value_cansleep(pcie->reset_gpio,
+					 (pcie->flags & OF_GPIO_ACTIVE_LOW) ? 0 : 1);
+	}
 	/*
-	 * Sleep needed to make sure all pcie transactions and access
-	 * are flushed before resetting the mac
+	 * Sleep used for two reasons.
+	 * First make sure all pcie transactions and access are flushed before resetting the mac
+	 * and second to make sure pci device is ready in case we reset the device
 	 */
 	msleep(100);
 
@@ -369,6 +381,7 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 	struct armada8k_pcie *pcie;
 	struct device *dev = &pdev->dev;
 	struct resource *base;
+	int reset_gpio;
 	int ret;
 
 	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
@@ -413,6 +426,13 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
 		goto fail_clkreg;
 	}
 
+	/* Config reset gpio for pcie if the reset connected to gpio */
+	reset_gpio = of_get_named_gpio_flags(pdev->dev.of_node,
+					     "reset-gpios", 0,
+					     &pcie->flags);
+	if (gpio_is_valid(reset_gpio))
+		pcie->reset_gpio = gpio_to_desc(reset_gpio);
+
 	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
 						       "marvell,system-controller");
 	if (IS_ERR(pcie->sysctrl_base)) {
-- 
2.7.4



From bpeled at marvell.com  Wed Apr 14 14:20:50 2021
From: bpeled at marvell.com (bpeled at marvell.com)
Date: Wed, 14 Apr 2021 16:20:50 +0300
Subject: =?UTF-8?q?=5B=E2=80=9DPATCH=E2=80=9D=20v2=201/5=5D=20PCI=3A=20armada8k=3A=20Disable=20LTSSM=20on=20link=20down=20interrupts?=
In-Reply-To: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
Message-ID: <1618406454-7953-2-git-send-email-bpeled@marvell.com>

From: Ben Peled <bpeled at marvell.com>

When a PCI link down condition is detected, the link training state
machine must be disabled immediately.

Signed-off-by: Marc St-Amand <mstamand at ciena.com>
Signed-off-by: Konstantin Porotchkin <kostap at marvell.com>
Signed-off-by: Ben Peled <bpeled at marvell.com>
---
 drivers/pci/controller/dwc/pcie-armada8k.c | 38 ++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
index 13901f3..b2278b1 100644
--- a/drivers/pci/controller/dwc/pcie-armada8k.c
+++ b/drivers/pci/controller/dwc/pcie-armada8k.c
@@ -54,6 +54,10 @@ struct armada8k_pcie {
 #define PCIE_INT_C_ASSERT_MASK		BIT(11)
 #define PCIE_INT_D_ASSERT_MASK		BIT(12)
 
+#define PCIE_GLOBAL_INT_CAUSE2_REG	(PCIE_VENDOR_REGS_OFFSET + 0x24)
+#define PCIE_GLOBAL_INT_MASK2_REG	(PCIE_VENDOR_REGS_OFFSET + 0x28)
+#define PCIE_INT2_PHY_RST_LINK_DOWN	BIT(1)
+
 #define PCIE_ARCACHE_TRC_REG		(PCIE_VENDOR_REGS_OFFSET + 0x50)
 #define PCIE_AWCACHE_TRC_REG		(PCIE_VENDOR_REGS_OFFSET + 0x54)
 #define PCIE_ARUSER_REG			(PCIE_VENDOR_REGS_OFFSET + 0x5C)
@@ -193,6 +197,11 @@ static void armada8k_pcie_establish_link(struct armada8k_pcie *pcie)
 	       PCIE_INT_C_ASSERT_MASK | PCIE_INT_D_ASSERT_MASK;
 	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK1_REG, reg);
 
+	/* Also enable link down interrupts */
+	reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG);
+	reg |= PCIE_INT2_PHY_RST_LINK_DOWN;
+	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG, reg);
+
 	if (!dw_pcie_link_up(pci)) {
 		/* Configuration done. Start LTSSM */
 		reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_CONTROL_REG);
@@ -230,6 +239,35 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
 	val = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_CAUSE1_REG);
 	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_CAUSE1_REG, val);
 
+	val = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_CAUSE2_REG);
+
+	if (PCIE_INT2_PHY_RST_LINK_DOWN & val) {
+		u32 ctrl_reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_CONTROL_REG);
+		/*
+		 * The link went down. Disable LTSSM immediately. This
+		 * unlocks the root complex config registers. Downstream
+		 * device accesses will return all-Fs
+		 */
+		ctrl_reg &= ~(PCIE_APP_LTSSM_EN);
+		dw_pcie_writel_dbi(pci, PCIE_GLOBAL_CONTROL_REG, ctrl_reg);
+		/*
+		 * Mask link down interrupts. They can be re-enabled once
+		 * the link is retrained.
+		 */
+		ctrl_reg = dw_pcie_readl_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG);
+		ctrl_reg &= ~PCIE_INT2_PHY_RST_LINK_DOWN;
+		dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_MASK2_REG, ctrl_reg);
+		/*
+		 * At this point a worker thread can be triggered to
+		 * initiate a link retrain. If link retrains were
+		 * possible, that is.
+		 */
+		dev_dbg(pci->dev, "%s: link went down\n", __func__);
+	}
+
+	/* Now clear the second interrupt cause. */
+	dw_pcie_writel_dbi(pci, PCIE_GLOBAL_INT_CAUSE2_REG, val);
+
 	return IRQ_HANDLED;
 }
 
-- 
2.7.4



From rex-bc.chen at mediatek.com  Wed Apr 14 14:35:15 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Wed, 14 Apr 2021 21:35:15 +0800
Subject: [v2,
 PATCH 2/3] drm/mediatek: config mt8183 driver data to support dual
 edge sample
In-Reply-To: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1618407316-10042-3-git-send-email-rex-bc.chen@mediatek.com>

add dual_edge value for mt8183_conf

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 21a3a7b78835..76431fe849b8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -691,6 +691,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
 static const struct mtk_dpi_conf mt8183_conf = {
 	.cal_factor = mt8183_calculate_factor,
 	.reg_h_fre_con = 0xe0,
+	.dual_edge = true,
 };
 
 static int mtk_dpi_probe(struct platform_device *pdev)
-- 
2.18.0

From rex-bc.chen at mediatek.com  Wed Apr 14 14:35:14 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Wed, 14 Apr 2021 21:35:14 +0800
Subject: [v2,PATCH 1/3] drm/mediatek: dpi dual edge sample mode support
In-Reply-To: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1618407316-10042-2-git-send-email-rex-bc.chen@mediatek.com>

DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index b05f900d9322..21a3a7b78835 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -83,6 +83,7 @@ struct mtk_dpi {
 	struct pinctrl *pinctrl;
 	struct pinctrl_state *pins_gpio;
 	struct pinctrl_state *pins_dpi;
+	bool ddr_edge_sel;
 	int refcount;
 };
 
@@ -121,6 +122,7 @@ struct mtk_dpi_conf {
 	unsigned int (*cal_factor)(int clock);
 	u32 reg_h_fre_con;
 	bool edge_sel_en;
+	bool dual_edge;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -380,6 +382,15 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
 	}
 }
 
+static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
+{
+	if (dpi->conf->dual_edge) {
+		mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+			     DDR_EN | DDR_4PHASE);
+		mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, dpi->ddr_edge_sel ? EDGE_SEL : 0, EDGE_SEL);
+	}
+}
+
 static void mtk_dpi_power_off(struct mtk_dpi *dpi)
 {
 	if (WARN_ON(dpi->refcount == 0))
@@ -518,6 +529,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	mtk_dpi_config_yc_map(dpi, dpi->yc_map);
 	mtk_dpi_config_color_format(dpi, dpi->color_format);
 	mtk_dpi_config_2n_h_fre(dpi);
+	mtk_dpi_dual_edge(dpi);
 	mtk_dpi_config_disable_edge(dpi);
 	mtk_dpi_sw_reset(dpi, false);
 
-- 
2.18.0

From rex-bc.chen at mediatek.com  Wed Apr 14 14:35:13 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Wed, 14 Apr 2021 21:35:13 +0800
Subject: [v2,PATCH 0/3] mt8183 dpi supports dual edge
Message-ID: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>

v2:
modify unused code

v1:
DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Rex-BC Chen (3):
  drm/mediatek: dpi dual edge sample mode support
  drm/mediatek: config mt8183 driver data to support dual edge sample
  drm/mediatek: dpi: add bus format negotiation

 drivers/gpu/drm/mediatek/mtk_dpi.c | 102 +++++++++++++++++++++++++++--
 1 file changed, 97 insertions(+), 5 deletions(-)

-- 
2.18.0

From rex-bc.chen at mediatek.com  Wed Apr 14 14:35:16 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Wed, 14 Apr 2021 21:35:16 +0800
Subject: [v2,PATCH 3/3] drm/mediatek: dpi: add bus format negotiation
In-Reply-To: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>

Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 89 ++++++++++++++++++++++++++++--
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 76431fe849b8..b4e9c6c8d706 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	return 0;
 }
 
+#define MAX_OUTPUT_SEL_FORMATS	2
+
+static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
+					struct drm_bridge_state *bridge_state,
+					struct drm_crtc_state *crtc_state,
+					struct drm_connector_state *conn_state,
+					unsigned int *num_output_fmts)
+{
+	struct drm_display_mode *mode = &crtc_state->mode;
+	u32 *output_fmts;
+	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+	*num_output_fmts = 0;
+
+	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
+			      GFP_KERNEL);
+	if (!output_fmts)
+		return NULL;
+
+	/* Default 8bit RGB fallback */
+	if (dpi->conf->dual_edge) {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
+		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
+		*num_output_fmts = 2;
+	} else {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
+		*num_output_fmts = 1;
+	}
+
+	return output_fmts;
+}
+
+#define MAX_INPUT_SEL_FORMATS	1
+
+static u32 *mtk_dpi_bridge_atomic_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)
+{
+	u32 *input_fmts;
+
+	*num_input_fmts = 0;
+
+	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+			     GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	*num_input_fmts = 1;
+	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+
+	return input_fmts;
+}
+
+static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
+				       struct drm_bridge_state *bridge_state,
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
+{
+	struct mtk_dpi *dpi = bridge->driver_private;
+	unsigned int out_bus_format;
+
+	out_bus_format = bridge_state->output_bus_cfg.format;
+
+	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
+		bridge_state->input_bus_cfg.format,
+		bridge_state->output_bus_cfg.format);
+
+	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
+		 		true : false;
+
+	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
+	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
+	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
+	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
+
+	return 0;
+}
+
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 				 enum drm_bridge_attach_flags flags)
 {
@@ -574,6 +655,9 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
 	.mode_set = mtk_dpi_bridge_mode_set,
 	.disable = mtk_dpi_bridge_disable,
 	.enable = mtk_dpi_bridge_enable,
+	.atomic_check = mtk_dpi_bridge_atomic_check,
+	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
+	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
 };
 
 void mtk_dpi_start(struct device *dev)
@@ -620,11 +704,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
 	}
 	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
 
-	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
-	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
-	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
-	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
-
 	return 0;
 
 err_cleanup:
-- 
2.18.0

From maz at kernel.org  Wed Apr 14 14:44:08 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:08 +0100
Subject: [PATCH 4/5] sh: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <20210414134409.1266357-5-maz@kernel.org>

perf_pmu_name() and perf_num_counters() are unused. Drop them.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/sh/kernel/perf_event.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/arch/sh/kernel/perf_event.c b/arch/sh/kernel/perf_event.c
index 445e3ece4c23..1d2507f22437 100644
--- a/arch/sh/kernel/perf_event.c
+++ b/arch/sh/kernel/perf_event.c
@@ -57,24 +57,6 @@ static inline int sh_pmu_initialized(void)
 	return !!sh_pmu;
 }
 
-const char *perf_pmu_name(void)
-{
-	if (!sh_pmu)
-		return NULL;
-
-	return sh_pmu->name;
-}
-EXPORT_SYMBOL_GPL(perf_pmu_name);
-
-int perf_num_counters(void)
-{
-	if (!sh_pmu)
-		return 0;
-
-	return sh_pmu->num_events;
-}
-EXPORT_SYMBOL_GPL(perf_num_counters);
-
 /*
  * Release the PMU if this is the last perf_event.
  */
-- 
2.29.2



From maz at kernel.org  Wed Apr 14 14:44:04 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:04 +0100
Subject: [PATCH 0/5] perf: oprofile spring cleanup
Message-ID: <20210414134409.1266357-1-maz@kernel.org>

This small series builds on top of the work that was started with [1].

It recently became apparent that KVM/arm64 is the last bit of the
kernel that still uses perf_num_counters().

As I went ahead to address this, it became obvious that all traces of
oprofile had been eradicated from all architectures but arm64, s390
and sh (plus a bit of cruft in the core perf code). With KVM fixed,
perf_num_counters() and perf_pmu_name() are finally gone.

Thanks,

	M.

[1] https://lore.kernel.org/lkml/20210215050618.hgftdmfmslbdrg3j at vireshk-i7

Marc Zyngier (5):
  KVM: arm64: Divorce the perf code from oprofile helpers
  arm64: Get rid of oprofile leftovers
  s390: Get rid of oprofile leftovers
  sh: Get rid of oprofile leftovers
  perf: Get rid of oprofile leftovers

 arch/arm64/kvm/perf.c         |  7 +------
 arch/arm64/kvm/pmu-emul.c     |  2 +-
 arch/s390/kernel/perf_event.c | 21 ---------------------
 arch/sh/kernel/perf_event.c   | 18 ------------------
 drivers/perf/arm_pmu.c        | 30 ------------------------------
 include/kvm/arm_pmu.h         |  4 ++++
 include/linux/perf_event.h    |  2 --
 kernel/events/core.c          |  5 -----
 8 files changed, 6 insertions(+), 83 deletions(-)

-- 
2.29.2


From maz at kernel.org  Wed Apr 14 14:44:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:07 +0100
Subject: [PATCH 3/5] s390: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <20210414134409.1266357-4-maz@kernel.org>

perf_pmu_name() and perf_num_counters() are unused. Drop them.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/s390/kernel/perf_event.c | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/arch/s390/kernel/perf_event.c b/arch/s390/kernel/perf_event.c
index 1e75cc983546..ea7729bebaa0 100644
--- a/arch/s390/kernel/perf_event.c
+++ b/arch/s390/kernel/perf_event.c
@@ -23,27 +23,6 @@
 #include <asm/sysinfo.h>
 #include <asm/unwind.h>
 
-const char *perf_pmu_name(void)
-{
-	if (cpum_cf_avail() || cpum_sf_avail())
-		return "CPU-Measurement Facilities (CPU-MF)";
-	return "pmu";
-}
-EXPORT_SYMBOL(perf_pmu_name);
-
-int perf_num_counters(void)
-{
-	int num = 0;
-
-	if (cpum_cf_avail())
-		num += PERF_CPUM_CF_MAX_CTR;
-	if (cpum_sf_avail())
-		num += PERF_CPUM_SF_MAX_CTR;
-
-	return num;
-}
-EXPORT_SYMBOL(perf_num_counters);
-
 static struct kvm_s390_sie_block *sie_block(struct pt_regs *regs)
 {
 	struct stack_frame *stack = (struct stack_frame *) regs->gprs[15];
-- 
2.29.2



From maz at kernel.org  Wed Apr 14 14:44:05 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:05 +0100
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile helpers
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <20210414134409.1266357-2-maz@kernel.org>

KVM/arm64 is the sole user of perf_num_counters(), and really
could do without it. Stop using the obsolete API by relying on
the existing probing code.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kvm/perf.c     | 7 +------
 arch/arm64/kvm/pmu-emul.c | 2 +-
 include/kvm/arm_pmu.h     | 4 ++++
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
index 739164324afe..b8b398670ef2 100644
--- a/arch/arm64/kvm/perf.c
+++ b/arch/arm64/kvm/perf.c
@@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
 
 int kvm_perf_init(void)
 {
-	/*
-	 * Check if HW_PERF_EVENTS are supported by checking the number of
-	 * hardware performance counters. This could ensure the presence of
-	 * a physical PMU and CONFIG_PERF_EVENT is selected.
-	 */
-	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
+	if (kvm_pmu_probe_pmuver() != 0xf)
 		static_branch_enable(&kvm_arm_pmu_available);
 
 	return perf_register_guest_info_callbacks(&kvm_guest_cbs);
diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
index e32c6e139a09..fd167d4f4215 100644
--- a/arch/arm64/kvm/pmu-emul.c
+++ b/arch/arm64/kvm/pmu-emul.c
@@ -739,7 +739,7 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	kvm_pmu_create_perf_event(vcpu, select_idx);
 }
 
-static int kvm_pmu_probe_pmuver(void)
+int kvm_pmu_probe_pmuver(void)
 {
 	struct perf_event_attr attr = { };
 	struct perf_event *event;
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 6fd3cda608e4..864b9997efb2 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -61,6 +61,7 @@ int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
 int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
 			    struct kvm_device_attr *attr);
 int kvm_arm_pmu_v3_enable(struct kvm_vcpu *vcpu);
+int kvm_pmu_probe_pmuver(void);
 #else
 struct kvm_pmu {
 };
@@ -116,6 +117,9 @@ static inline u64 kvm_pmu_get_pmceid(struct kvm_vcpu *vcpu, bool pmceid1)
 {
 	return 0;
 }
+
+static inline int kvm_pmu_probe_pmuver(void) { return 0xf; }
+
 #endif
 
 #endif
-- 
2.29.2



From maz at kernel.org  Wed Apr 14 14:44:06 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:06 +0100
Subject: [PATCH 2/5] arm64: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <20210414134409.1266357-3-maz@kernel.org>

perf_pmu_name() and perf_num_counters() are now unused. Drop them.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/perf/arm_pmu.c | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 2d10d84fb79c..d4f7f1f9cc77 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -581,33 +581,6 @@ static const struct attribute_group armpmu_common_attr_group = {
 	.attrs = armpmu_common_attrs,
 };
 
-/* Set at runtime when we know what CPU type we are. */
-static struct arm_pmu *__oprofile_cpu_pmu;
-
-/*
- * Despite the names, these two functions are CPU-specific and are used
- * by the OProfile/perf code.
- */
-const char *perf_pmu_name(void)
-{
-	if (!__oprofile_cpu_pmu)
-		return NULL;
-
-	return __oprofile_cpu_pmu->name;
-}
-EXPORT_SYMBOL_GPL(perf_pmu_name);
-
-int perf_num_counters(void)
-{
-	int max_events = 0;
-
-	if (__oprofile_cpu_pmu != NULL)
-		max_events = __oprofile_cpu_pmu->num_events;
-
-	return max_events;
-}
-EXPORT_SYMBOL_GPL(perf_num_counters);
-
 static int armpmu_count_irq_users(const int irq)
 {
 	int cpu, count = 0;
@@ -979,9 +952,6 @@ int armpmu_register(struct arm_pmu *pmu)
 	if (ret)
 		goto out_destroy;
 
-	if (!__oprofile_cpu_pmu)
-		__oprofile_cpu_pmu = pmu;
-
 	pr_info("enabled with %s PMU driver, %d counters available%s\n",
 		pmu->name, pmu->num_events,
 		has_nmi ? ", using NMIs" : "");
-- 
2.29.2



From maz at kernel.org  Wed Apr 14 14:44:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 14 Apr 2021 14:44:09 +0100
Subject: [PATCH 5/5] perf: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <20210414134409.1266357-6-maz@kernel.org>

perf_pmu_name() and perf_num_counters() are unused. Drop them.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 include/linux/perf_event.h | 2 --
 kernel/events/core.c       | 5 -----
 2 files changed, 7 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 3f7f89ea5e51..51154ed9a206 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -951,8 +951,6 @@ extern void perf_event_itrace_started(struct perf_event *event);
 extern int perf_pmu_register(struct pmu *pmu, const char *name, int type);
 extern void perf_pmu_unregister(struct pmu *pmu);
 
-extern int perf_num_counters(void);
-extern const char *perf_pmu_name(void);
 extern void __perf_event_task_sched_in(struct task_struct *prev,
 				       struct task_struct *task);
 extern void __perf_event_task_sched_out(struct task_struct *prev,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 03db40f6cba9..88cb0ba5690b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -580,11 +580,6 @@ static u64 perf_event_time(struct perf_event *event);
 
 void __weak perf_event_print_debug(void)	{ }
 
-extern __weak const char *perf_pmu_name(void)
-{
-	return "pmu";
-}
-
 static inline u64 perf_clock(void)
 {
 	return local_clock();
-- 
2.29.2



From dietmar.eggemann at arm.com  Wed Apr 14 14:53:48 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Wed, 14 Apr 2021 15:53:48 +0200
Subject: [PATCH 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3P6FYhqmt3p6g8b5ZXzaFW2pfx-vOZJYwuLCKXVqfFMVw@mail.gmail.com>
References: <20210412070819.23493-1-ruifeng.zhang0110@gmail.com>
 <87y2dnn3gw.mognet@arm.com>
 <CAG7+-3MsjuChoEOj11VAMX9W61UY6MmphkxWDF=-_R1A8sfvpA@mail.gmail.com>
 <87tuobmsba.mognet@arm.com>
 <CAG7+-3OMYVTc+ja9CK+94X8XtKq3hbRb+XOEv7xOeuXgNm0BHQ@mail.gmail.com>
 <87o8eimmyw.mognet@arm.com>
 <CAG7+-3NaUAvjv9=9HZ4jQU=DVcZW6gRKZg9ZjutL3aKnnC4FLw@mail.gmail.com>
 <74b3ff57-473f-4d5a-daf8-ecbb0761abb2@arm.com>
 <CAG7+-3P6FYhqmt3p6g8b5ZXzaFW2pfx-vOZJYwuLCKXVqfFMVw@mail.gmail.com>
Message-ID: <02ed2223-6f33-faee-38a6-fc4ef071d431@arm.com>

On 14/04/2021 13:26, Ruifeng Zhang wrote:
> Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?14??? ??5:43???
>>
>> On 13/04/2021 15:26, Ruifeng Zhang wrote:
>>> Thanks for your review. Patch-v2 that solve the capacity issue will be
>>> uploaded as soon as possible. : )
>>>
>>> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?13??? ??7:40???
>>>>
>>>> On 13/04/21 14:13, Ruifeng Zhang wrote:
>>>>> Valentin Schneider <valentin.schneider at arm.com> ?2021?4?12??? ??11:33???

[...]

>> Looks like sc9863a has two frequency domains (1.6 and 1.2GHz). So
>> technically it's a big.LITTLE system (based only on max CPU frequency
>> (not on uarch) differences).
>> But the dts file doesn't contain any `capacity-dmips-mhz` entries? So
>> asymmetric CPU capacity (even only based on max CPU frequency) detection
>> won't kick in. Since you don't have any uarch diffs, you would have to
>> specify `capacity-dmips-mhz = <1024>` for each CPU.
> 
> Yes, for capacity, the DT should have a capacity-dmips-MHz entry or a
> clock-frequency entry (for A7 and A15 only).
> The sc9863a dts is a vendor file,  in my opinion is not appropriate to
> be update with this series.
> What do you think if I independently update the sc9863a dts file later?
> 

Yes, this is a separate thing. Just wanted to mention it here since this
allows you to test asymmetric CPU capacity on your platform w/ and w/o
your patch on arm64 and arm.

No need to add `clock-frequency` entries, just `capacity-dmips-mhz`
entries should do.


From robh at kernel.org  Wed Apr 14 14:55:25 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 08:55:25 -0500
Subject: [PATCH] phy: Allow a NULL phy name for devm_phy_get()
Message-ID: <20210414135525.3535787-1-robh@kernel.org>

For a single PHY, there's no reason to have a phy-names entry in DT.
The DT specific get functions allow for this already, but devm_phy_get()
WARNs in this case. Other subsystems also don't warn in their get
functions. Let's drop the WARN for DT case in devm_phy_get().

Cc: Kishon Vijay Abraham I <kishon at ti.com>
Cc: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Rob Herring <robh at kernel.org>
---
Note that I think the device_link_add later on is now redundant with 
fw_devlinks. If so, this can be simplified to just calling of_phy_get() 
for DT case.

 drivers/phy/phy-core.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 71cb10826326..3e4971253ec1 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -667,16 +667,18 @@ struct phy *phy_get(struct device *dev, const char *string)
 	struct phy *phy;
 	struct device_link *link;
 
-	if (string == NULL) {
-		dev_WARN(dev, "missing string\n");
-		return ERR_PTR(-EINVAL);
-	}
-
 	if (dev->of_node) {
-		index = of_property_match_string(dev->of_node, "phy-names",
-			string);
+		if (string)
+			index = of_property_match_string(dev->of_node, "phy-names",
+				string);
+		else
+			index = 0;
 		phy = _of_phy_get(dev->of_node, index);
 	} else {
+		if (string == NULL) {
+			dev_WARN(dev, "missing string\n");
+			return ERR_PTR(-EINVAL);
+		}
 		phy = phy_find(dev, string);
 	}
 	if (IS_ERR(phy))
-- 
2.27.0



From marex at denx.de  Wed Apr 14 15:04:30 2021
From: marex at denx.de (Marek Vasut)
Date: Wed, 14 Apr 2021 16:04:30 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
Message-ID: <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>

On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
> Hi Marek,

Hello Gabriel,

> Thanks for the patchset
> 
> On 4/8/21 8:57 PM, Marek Vasut wrote:
>> The ETHCK_K are modeled as composite clock of MUX and GATE, however per
>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. Peripheral
>> clock distribution for Ethernet, ETHPTPDIV divider is attached past the
>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN gate.
>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
>> in use, ETHCKEN gate can be turned off. Current driver does not permit
>> that, fix it.
> 
> I don"t understand, it's already the case.
> 
> ETHCK_K it's a composite with a MUX and a GATE.

But ETHCK_K is _not_ a composite clock, look at the Figure 83 in the 
datasheet again and schematic below.

> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV (no gate)

But ETHPTP_K shouldn't control any mux, it is only a divider.

> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.

Look, this is what you have today:

            .------------ ETHCK_K -----------.
            |_______               _______   |
pll4_p_ck--|M_ETHCK\             |G_ETHCK\  |
            | MUX    |------+-----| GATE   |-------------[x] ETH_CLK
pll3_q_ck--|_______/       |     |_______/                  eth_clk_fb
            |               |
            |               '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
            |                                          |
            '------------ ETHPTP_K --------------------'

And this is what you should have, to avoid having two composite clock 
which control the same mux using the same register bit, i.e. what this 
patch implements:

            .- ck_ker_eth -.  .--- ETHCK_K --.
            |_______       |  |    _______   |
pll4_p_ck--|M_ETHCK\      |  |   |G_ETHCK\  |
            | MUX    |------+-----| GATE   |-------------[x] ETH_CLK
pll3_q_ck--|_______/       |     |_______/                  eth_clk_fb
                            |
                            '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
                             |                         |
                             '---- ETHPTP_K -----------'

>> This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
>> ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
>> NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent clock
>> to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
>> ETHPTP_K remain functional as before.
>>
>> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>> ???? Figure 83. Peripheral clock distribution for Ethernet
>>      
>> https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf 
>>

[...]

>> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
>> index a875649df8b8..a7c7f544ee5d 100644
>> --- a/drivers/clk/clk-stm32mp1.c
>> +++ b/drivers/clk/clk-stm32mp1.c
>> @@ -1949,7 +1949,6 @@ static const struct clock_config 
>> stm32mp1_clock_cfg[] = {
>> ????? KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
>> ????? KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
>> ????? KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
>> -??? KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
>> ????? /* Particulary Kernel Clocks (no mux or no gate) */
>> ????? MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
>> @@ -1958,11 +1957,16 @@ static const struct clock_config 
>> stm32mp1_clock_cfg[] = {
>> ????? MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
>> ????? MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
>> -??? COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
>> +??? COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
>> ??????????? CLK_SET_RATE_NO_REPARENT,
>> ??????????? _NO_GATE,
>> ??????????? _MMUX(M_ETHCK),
>> -????????? _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
>> +????????? _NO_DIV),
>> +
>> +??? MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
> assigned parent with ETHCK_K will not work
>> +
>> +??? DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |
> 
> CLK_OPS_PARENT_ENABLE flags not useful with a divider.

How so ?


From pasha.tatashin at soleen.com  Wed Apr 14 15:05:43 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Wed, 14 Apr 2021 10:05:43 -0400
Subject: [RFC 0/8] use __create_pgd_mapping() to implement idmap and unify
 codes
In-Reply-To: <20210410095654.24102-1-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
Message-ID: <CA+CK2bCLwRWiNf-pUbD_qSRPt=taQxSvrEMOP-8D7FgNhXQKug@mail.gmail.com>

On Sat, Apr 10, 2021 at 5:57 AM Pingfan Liu <kernelfans at gmail.com> wrote:
>
> Hi everyone,
>
> Sorry to bring up this RFC in a hurry, since I paid attention to "arm64:
> MMU enabled kexec relocation" too late and now it has advanced to "[PATCH
> v13 00/18] arm64: MMU enabled kexec relocation".
>
> And I think maybe that work can be based on my series.
>
> I have raised my concern when reviewing "[PATCH v12 00/17] arm64: MMU
> enabled kexec relocation"
>   https://linuxlists.cc/l/1/linux-kernel/t/3923858/(patch_v12_00_17)_arm64:_mmu_enabled_kexec_relocation#post3948651
>   (It seems that lore.kernel.org has not archived my reply)
>   Where I wrote:
>     Then the processes may be neat (I hope so):
>     -1. set up identity map in machine_kexec_post_load(), instead of
>     copying linear map.
>     -2. Also past this temporary identity map to arm64_relocate_new_kernel()
>     -3. in arm64_relocate_new_kernel(), just load identity map and
>     re-enable MMU. After copying, just turn off MMU.


Hi Pingfan,

The MMU enabled kexec code has been in development for a while, and
has gone through several iterations:

1. simply reserve memory (similar to crash kernel) so no relocation is
needed. The approach was only ~50 LOC, but since this was an ARM64
specific problem I was asked to fix it in ARM64, not in generic code.
2. The second approach was to use idmap (as you are proposing now),
but James Morse explained to me that there are arm systems that have
very high starting physical addresses that they cannot cover all
physical memory via idamp. So, I cannot assume that I can idmap any
page in PA.
3. The third approach was to unify some of page table management code
with hibernations (trans_pgd), and use contiguous VA maps, so the
relocation function can be as simply as possible. However, both, Eric
Biederman and James Morse asked me to change it to a linear map
instead: to be inline with other arches, and also for easier
debugging.
4. The fourth approach is the current one, I am using a linear map,
and a lot of patches for this project have already landed into the
mainline. The last set of changes does not add any new LOC: "18 files
changed, 315 insertions(+), 330 deletions(-)", as all the preliminary
work has landed upstream.

What is the benefit of going back to approach 2, when the current
approach has already been agreed with James and Eric, and does not add
new complexity, as the net LOC change is negative?

Thank you,
Pavel


>
> In a short discuss off-line, Pavel pointed to me
>   https://lore.kernel.org/linux-arm-kernel/CA+CK2bC2KwWufE1DWa4szn_hQ1dbjDVHgYUu7=J4O_kvKXTrHg at mail.gmail.com/#t,
> which prevent him from using idmap to implement his series.
>
>
> After digging into the code, I find that if extending one more pgtable level,
> the __create_pgd_mapping() routines can be re-used for idmap_pg_dir and
> init_pg_dir. Besides, it can be re-used for trans_pgd_idmap_page().
> That is what this series do.
>
> As for "[PATCHv13 00/18] arm64: MMU enabled kexec relocation", here is
> my two cents:
>   -1. a call to create_idmap() API in machine_kexec_post_load(), to map
> src + dst + arm64_relocate_new_kernel().
>   -2. turn on MMU in arm64_relocate_new_kernel(), after done, turn off.
>
> Sorry again for a hurry. It can be compiled, but far from good.
>
> Thanks,
>
> Pingfan
>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Kristina Martsenko <kristina.martsenko at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Cc: Steven Price <steven.price at arm.com>
> Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
> Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
> Cc: Anshuman Khandual <anshuman.khandual at arm.com>
> Cc: Atish Patra <atish.patra at wdc.com>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: Logan Gunthorpe <logang at deltatee.com>
> Cc: Mark Brown <broonie at kernel.org>
> To: linux-arm-kernel at lists.infradead.org
>
> Pingfan Liu (8):
>   arm64/mm: split out __create_pgd_mapping() routines
>   arm64/mm: change __create_pgd_mapping() prototype to accept nr_entries
>     and introduce create_idmap()
>   arm64/mm: change __create_pgd_mapping() prototype to accept extra info
>     for allocator
>   arm64/mm: enable __create_pgd_mapping() to run across different
>     pgtable
>   arm64/mm: make trans_pgd_idmap_page() use create_idmap()
>   arm64/mm: introduce pgtable allocator for head
>   arm64/pgtable-prot.h: reorganize to cope with asm
>   arm64/head: convert idmap_pg_dir and init_pg_dir to
>     __create_pgd_mapping()
>
>  arch/arm64/Kconfig                    |   4 +
>  arch/arm64/include/asm/pgalloc.h      |  28 ++
>  arch/arm64/include/asm/pgtable-prot.h |  34 ++-
>  arch/arm64/kernel/head.S              | 190 ++++----------
>  arch/arm64/mm/Makefile                |   2 +
>  arch/arm64/mm/idmap_mmu.c             |  46 ++++
>  arch/arm64/mm/mmu.c                   | 358 ++++++--------------------
>  arch/arm64/mm/mmu_include.c           | 284 ++++++++++++++++++++
>  arch/arm64/mm/trans_pgd.c             |  59 ++---
>  9 files changed, 535 insertions(+), 470 deletions(-)
>  create mode 100644 arch/arm64/mm/idmap_mmu.c
>  create mode 100644 arch/arm64/mm/mmu_include.c
>
> --
> 2.29.2
>


From yibin.gong at nxp.com  Wed Apr 14 15:33:58 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed, 14 Apr 2021 14:33:58 +0000
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
Message-ID: <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>

On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > Hi
> >
> > On Tue, May 19, 2020 at 6:04 PM Lucas Stach <l.stach at pengutronix.de>
> wrote:
> > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > There are two requirements that we need to move the request of dma
> > > > channel from probe to open.
> > >
> > > How do you handle -EPROBE_DEFER return code from the channel request
> > > if you don't do it in probe?
> >
> > I use the dma_request_slave_channel or dma_request_channel instead of
> > dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
> > return code.
> 
> This is a pretty weak argument. The dmaengine device might probe after you
> try to get the channel. Using a function to request the channel that doesn't
> allow you to handle probe deferral is IMHO a bug and should be fixed, instead
> of building even more assumptions on top of it.
> 
> > > > - When dma device binds with power-domains, the power will be
> > > > enabled when we request dma channel. If the request of dma channel
> > > > happen on probe, then the power-domains will be always enabled
> > > > after kernel boot up,  which is not good for power saving,  so we
> > > > need to move the request of dma channel to .open();
> > >
> > > This is certainly something which could be fixed in the dmaengine
> > > driver.
> >
> > Dma driver always call the pm_runtime_get_sync in
> > device_alloc_chan_resources, the device_alloc_chan_resources is called
> > when channel is requested. so power is enabled on channel request.
> 
> So why can't you fix the dmaengine driver to do that RPM call at a later time
> when the channel is actually going to be used? This will allow further power
> savings with other slave devices than the audio PCM.
Hi Lucas,
  Thanks for your suggestion. I have tried to implement runtime autosuspend in
fsl-edma driver on i.mx8qm/qxp with delay time (2 sec) for this feature as below
(or you can refer to drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
pm_runtime_put_autosuspend in all dmaengine driver interface like
device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_cyclic/
device_tx_status...


                pm_runtime_use_autosuspend(fsl_chan->dev);
                pm_runtime_set_autosuspend_delay(fsl_chan->dev, 2000);

That could resolve this audio case since the autosuspend could suspend runtime after
2 seconds if there is no further dma transfer but only channel request(device_alloc_chan_resources).
But unfortunately, it cause another issue. As you know, on our i.mx8qm/qxp, 
power domain done by scfw (drivers/firmware/imx/scu-pd.c) over mailbox:
 imx_sc_pd_power()->imx_scu_call_rpc()-> imx_scu_ipc_write()->mbox_send_message()
which means have to 'waits for completion', meanwhile, some driver like tty will call dmaengine
interfaces in non-atomic case as below, 

static int uart_write(struct tty_struct *tty, const unsigned char *buf, int count)
{
   .......
	    port = uart_port_lock(state, flags);
   ......
        __uart_start(tty);  //call start_tx()->dmaengine_prep_slave_sg...
        uart_port_unlock(port, flags);
        return ret;
}

Thus dma runtime resume may happen in that timing window and cause kernel alarm. 
I'm not sure whether there are similar limitations on other driver subsystem. But for me,
It looks like the only way to resolve the contradiction between tty and scu-pd (hardware
limitation on i.mx8qm/qxp) is to give up autosuspend and keep pm_runtime_get_sync
only in device_alloc_chan_resources because request channel is a safe non-atomic phase. 
Do you have any idea? Thanks in advance. 
  

> 
> > > > - With FE-BE case, if the dma channel is requested in probe, then
> > > > there will be below issue, which is caused by that the dma channel
> > > > will be requested duplicately
> > >
> > > Why is this requested a second time? Is this just some missing
> > > cleanup on a deferred probe path?
> >
> > Not relate with deferred probe.  With DMA1->ASRC->DMA2->ESAI case, the
> > DMA1->ASRC->DMA2 is in FE,  ESAI is in BE.  When ESAI drvier probe,
> > DMA3 channel is created with ESAI's "dma:tx" (DMA3 channel
> > is not used in this FE-BE case).    When FE-BE startup, DMA2
> > channel is created, it needs the ESAI's "dma:tx", so below warning
> > comes out.
> >
> > > Regards,
> > > Lucas
> > >
> > > > [  638.906268] sysfs: cannot create duplicate filename
> '/devices/soc0/soc/2000000.bus/2000000.spba-bus/2024000.esai/dma:tx'
> > > > [  638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted
> > > > 5.7.0-rc1-12956-gfc64b2585593 #287 [  638.927113] Hardware name:
> > > > Freescale i.MX6 Quad/DualLite (Device Tree) [  638.933690]
> > > > [<c0110dd8>] (unwind_backtrace) from [<c010b8ec>]
> > > > (show_stack+0x10/0x14) [  638.941464] [<c010b8ec>] (show_stack)
> > > > from [<c0557fc0>] (dump_stack+0xe4/0x118) [  638.948808]
> > > > [<c0557fc0>] (dump_stack) from [<c032aeb4>]
> > > > (sysfs_warn_dup+0x50/0x64) [  638.956406] [<c032aeb4>]
> > > > (sysfs_warn_dup) from [<c032b1a8>]
> > > > (sysfs_do_create_link_sd+0xc8/0xd4)
> > > > [  638.965134] [<c032b1a8>] (sysfs_do_create_link_sd) from
> > > > [<c05dc668>] (dma_request_chan+0xb0/0x210) [  638.974120]
> > > > [<c05dc668>] (dma_request_chan) from [<c05dc7d0>]
> > > > (dma_request_slave_channel+0x8/0x14)
> > > > [  638.983111] [<c05dc7d0>] (dma_request_slave_channel) from
> > > > [<c09d5548>] (fsl_asrc_dma_hw_params+0x1e0/0x438)
> > > > [  638.992881] [<c09d5548>] (fsl_asrc_dma_hw_params) from
> > > > [<c09c1654>] (soc_pcm_hw_params+0x4a0/0x6a8) [  639.001952]
> > > > [<c09c1654>] (soc_pcm_hw_params) from [<c09c39d4>]
> > > > (dpcm_fe_dai_hw_params+0x70/0xe4) [  639.010765] [<c09c39d4>]
> > > > (dpcm_fe_dai_hw_params) from [<c099b274>]
> > > > (snd_pcm_hw_params+0x158/0x418) [  639.019750] [<c099b274>]
> > > > (snd_pcm_hw_params) from [<c099c5a0>]
> (snd_pcm_ioctl+0x734/0x183c) [  639.028129] [<c099c5a0>] (snd_pcm_ioctl)
> from [<c029ff94>] (ksys_ioctl+0x2ac/0xb98) [  639.035812] [<c029ff94>]
> (ksys_ioctl) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [  639.043490]
> Exception stack(0xec529fa8 to 0xec529ff0)
> > > > [  639.048565] 9fa0:                   bee84650 01321870
> 00000004 c25c4111 bee84650 0002000f
> > > > [  639.056766] 9fc0: bee84650 01321870 01321820 00000036
> 00001f40
> > > > 00000000 0002c2f8 00000003 [  639.064964] 9fe0: b6f483fc bee8451c
> > > > b6ee2655 b6e1dcf8 [  639.070339] fsl-esai-dai 2024000.esai: Cannot
> > > > create DMA dma:tx symlink
> > > >
> > > > Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
> > > > ---
> > > >  sound/soc/fsl/imx-pcm-dma.c | 173
> > > > +++++++++++++++++++++++++++++++++---
> > > >  1 file changed, 159 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/sound/soc/fsl/imx-pcm-dma.c
> > > > b/sound/soc/fsl/imx-pcm-dma.c index 04a9bc749016..dae53b384df4
> > > > 100644
> > > > --- a/sound/soc/fsl/imx-pcm-dma.c
> > > > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > > > @@ -11,6 +11,7 @@
> > > >  #include <linux/dmaengine.h>
> > > >  #include <linux/types.h>
> > > >  #include <linux/module.h>
> > > > +#include <linux/dma-mapping.h>
> > > >
> > > >  #include <sound/core.h>
> > > >  #include <sound/pcm.h>
> > > > @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void
> *param)
> > > >       return true;
> > > >  }
> > > >
> > > > -static const struct snd_dmaengine_pcm_config
> imx_dmaengine_pcm_config = {
> > > > -     .prepare_slave_config =
> snd_dmaengine_pcm_prepare_slave_config,
> > > > -     .compat_filter_fn = filter,
> > > > -};
> > > > +static int imx_pcm_hw_params(struct snd_soc_component
> *component,
> > > > +                          struct snd_pcm_substream *substream,
> > > > +                          struct snd_pcm_hw_params *params) {
> > > > +     struct snd_pcm_runtime *runtime = substream->runtime;
> > > > +     struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > +     struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > +     struct snd_dmaengine_dai_dma_data *dma_data;
> > > > +     struct dma_slave_config config;
> > > > +     struct dma_chan *chan;
> > > > +     int ret = 0;
> > > >
> > > > -int imx_pcm_dma_init(struct platform_device *pdev, size_t size)
> > > > +     snd_pcm_set_runtime_buffer(substream,
> &substream->dma_buffer);
> > > > +     runtime->dma_bytes = params_buffer_bytes(params);
> > > > +
> > > > +     chan = snd_dmaengine_pcm_get_chan(substream);
> > > > +     if (!chan)
> > > > +             return -EINVAL;
> > > > +
> > > > +     ret = snd_hwparams_to_dma_slave_config(substream, params,
> &config);
> > > > +     if (ret)
> > > > +             return ret;
> > > > +
> > > > +     dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > +     if (!dma_data)
> > > > +             return -EINVAL;
> > > > +
> > > > +     snd_dmaengine_pcm_set_config_from_dai_data(substream,
> > > > +                                                dma_data,
> > > > +                                                &config);
> > > > +     return dmaengine_slave_config(chan, &config); }
> > > > +
> > > > +static int imx_pcm_hw_free(struct snd_soc_component *component,
> > > > +                        struct snd_pcm_substream *substream)
> > > >  {
> > > > -     struct snd_dmaengine_pcm_config *config;
> > > > +     snd_pcm_set_runtime_buffer(substream, NULL);
> > > > +     return 0;
> > > > +}
> > > > +
> > > > +static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component
> *component,
> > > > +                                      struct snd_pcm_substream
> > > > +*substream) {
> > > > +     return snd_dmaengine_pcm_pointer(substream);
> > > > +}
> > > > +
> > > > +static int imx_pcm_trigger(struct snd_soc_component *component,
> > > > +                        struct snd_pcm_substream *substream, int
> > > > +cmd) {
> > > > +     return snd_dmaengine_pcm_trigger(substream, cmd); }
> > > > +
> > > > +static int imx_pcm_open(struct snd_soc_component *component,
> > > > +                     struct snd_pcm_substream *substream) {
> > > > +     struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > +     bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > > > +     struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > +     struct snd_dmaengine_dai_dma_data *dma_data;
> > > > +     struct device *dev = component->dev;
> > > > +     struct snd_pcm_hardware hw;
> > > > +     struct dma_chan *chan;
> > > > +     int ret;
> > > > +
> > > > +     ret = snd_pcm_hw_constraint_integer(substream->runtime,
> > > > +
> SNDRV_PCM_HW_PARAM_PERIODS);
> > > > +     if (ret < 0) {
> > > > +             dev_err(dev, "failed to set pcm hw params periods\n");
> > > > +             return ret;
> > > > +     }
> > > > +
> > > > +     dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > +     if (!dma_data)
> > > > +             return -EINVAL;
> > > > +
> > > > +     chan = dma_request_slave_channel(cpu_dai->dev, tx ? "tx" : "rx");
> > > > +     if (!chan) {
> > > > +             /* Try to request channel using compat_filter_fn */
> > > > +             chan = snd_dmaengine_pcm_request_channel(filter,
> > > > +
> dma_data->filter_data);
> > > > +             if (!chan)
> > > > +                     return -ENXIO;
> > > > +     }
> > > >
> > > > -     config = devm_kzalloc(&pdev->dev,
> > > > -                     sizeof(struct snd_dmaengine_pcm_config),
> GFP_KERNEL);
> > > > -     if (!config)
> > > > -             return -ENOMEM;
> > > > -     *config = imx_dmaengine_pcm_config;
> > > > +     ret = snd_dmaengine_pcm_open(substream, chan);
> > > > +     if (ret)
> > > > +             goto pcm_open_fail;
> > > >
> > > > -     return devm_snd_dmaengine_pcm_register(&pdev->dev,
> > > > -             config,
> > > > -             SND_DMAENGINE_PCM_FLAG_COMPAT);
> > > > +     memset(&hw, 0, sizeof(hw));
> > > > +     hw.info = SNDRV_PCM_INFO_MMAP |
> SNDRV_PCM_INFO_MMAP_VALID |
> > > > +                     SNDRV_PCM_INFO_INTERLEAVED;
> > > > +     hw.periods_min = 2;
> > > > +     hw.periods_max = UINT_MAX;
> > > > +     hw.period_bytes_min = 256;
> > > > +     hw.period_bytes_max =
> dma_get_max_seg_size(chan->device->dev);
> > > > +     hw.buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE;
> > > > +     hw.fifo_size = dma_data->fifo_size;
> > > > +
> > > > +     /* Refine the hw according to caps of DMA. */
> > > > +     ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream,
> > > > +
> dma_data,
> > > > +                                                     &hw,
> > > > +                                                     chan);
> > > > +     if (ret < 0)
> > > > +             goto refine_runtime_hwparams_fail;
> > > > +
> > > > +     snd_soc_set_runtime_hwparams(substream, &hw);
> > > > +
> > > > +     /* Support allocate memory from IRAM */
> > > > +     ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_IRAM,
> > > > +                               chan->device->dev,
> > > > +                               hw.buffer_bytes_max,
> > > > +                               &substream->dma_buffer);
> > > > +     if (ret < 0)
> > > > +             goto alloc_pagas_fail;
> > > > +
> > > > +     return 0;
> > > > +
> > > > +alloc_pagas_fail:
> > > > +refine_runtime_hwparams_fail:
> > > > +     snd_dmaengine_pcm_close(substream);
> > > > +pcm_open_fail:
> > > > +     dma_release_channel(chan);
> > > > +
> > > > +     return ret;
> > > > +}
> > > > +
> > > > +static int imx_pcm_close(struct snd_soc_component *component,
> > > > +                      struct snd_pcm_substream *substream) {
> > > > +     if (substream) {
> > > > +             snd_dma_free_pages(&substream->dma_buffer);
> > > > +             substream->dma_buffer.area = NULL;
> > > > +             substream->dma_buffer.addr = 0;
> > > > +     }
> > > > +
> > > > +     return snd_dmaengine_pcm_close_release_chan(substream);
> > > > +}
> > > > +
> > > > +static int imx_pcm_new(struct snd_soc_component *component,
> > > > +                    struct snd_soc_pcm_runtime *rtd) {
> > > > +     struct snd_card *card = rtd->card->snd_card;
> > > > +
> > > > +     return dma_coerce_mask_and_coherent(card->dev,
> > > > +DMA_BIT_MASK(32)); }
> > > > +
> > > > +static const struct snd_soc_component_driver imx_pcm_component = {
> > > > +     .name           = "imx-pcm-dma",
> > > > +     .pcm_construct  = imx_pcm_new,
> > > > +     .open           = imx_pcm_open,
> > > > +     .close          = imx_pcm_close,
> > > > +     .hw_params      = imx_pcm_hw_params,
> > > > +     .hw_free        = imx_pcm_hw_free,
> > > > +     .trigger        = imx_pcm_trigger,
> > > > +     .pointer        = imx_pcm_pointer,
> > > > +};
> > > > +
> > > > +int imx_pcm_dma_init(struct platform_device *pdev, size_t size) {
> > > > +     return devm_snd_soc_register_component(&pdev->dev,
> > > > +
> &imx_pcm_component,
> > > > +NULL, 0);
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(imx_pcm_dma_init);
> > > >


From james.clark at arm.com  Wed Apr 14 15:39:18 2021
From: james.clark at arm.com (James Clark)
Date: Wed, 14 Apr 2021 17:39:18 +0300
Subject: [PATCH 1/2] perf cs-etm: Refactor timestamp variable names
Message-ID: <20210414143919.12605-1-james.clark@arm.com>

Remove ambiguity in variable names relating to timestamps.
A later commit will save the sample kernel timestamp in one
of the etm structs, so name all elements appropriately to
avoid confusion.

This is also removes some ambiguity arising from the fact
that the --timestamp argument to perf record refers to
sample kernel timestamps, and the /timestamp/ event modifier
refers to etm timestamps, so the term is overloaded.

Signed-off-by: James Clark <james.clark at arm.com>
---
 .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 ++++----
 tools/perf/util/cs-etm.c                      | 42 +++++++++----------
 tools/perf/util/cs-etm.h                      |  4 +-
 3 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 059bcec3f651..055cb93eca59 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -276,13 +276,13 @@ cs_etm_decoder__do_soft_timestamp(struct cs_etm_queue *etmq,
 				  const uint8_t trace_chan_id)
 {
 	/* No timestamp packet has been received, nothing to do */
-	if (!packet_queue->timestamp)
+	if (!packet_queue->etm_timestamp)
 		return OCSD_RESP_CONT;
 
-	packet_queue->timestamp = packet_queue->next_timestamp;
+	packet_queue->etm_timestamp = packet_queue->next_etm_timestamp;
 
 	/* Estimate the timestamp for the next range packet */
-	packet_queue->next_timestamp += packet_queue->instr_count;
+	packet_queue->next_etm_timestamp += packet_queue->instr_count;
 	packet_queue->instr_count = 0;
 
 	/* Tell the front end which traceid_queue needs attention */
@@ -308,8 +308,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 	 * Function do_soft_timestamp() will report the value to the front end,
 	 * hence asking the decoder to keep decoding rather than stopping.
 	 */
-	if (packet_queue->timestamp) {
-		packet_queue->next_timestamp = elem->timestamp;
+	if (packet_queue->etm_timestamp) {
+		packet_queue->next_etm_timestamp = elem->timestamp;
 		return OCSD_RESP_CONT;
 	}
 
@@ -320,8 +320,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 	 * which instructions started by subtracting the number of instructions
 	 * executed to the timestamp.
 	 */
-	packet_queue->timestamp = elem->timestamp - packet_queue->instr_count;
-	packet_queue->next_timestamp = elem->timestamp;
+	packet_queue->etm_timestamp = elem->timestamp - packet_queue->instr_count;
+	packet_queue->next_etm_timestamp = elem->timestamp;
 	packet_queue->instr_count = 0;
 
 	/* Tell the front end which traceid_queue needs attention */
@@ -334,8 +334,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 static void
 cs_etm_decoder__reset_timestamp(struct cs_etm_packet_queue *packet_queue)
 {
-	packet_queue->timestamp = 0;
-	packet_queue->next_timestamp = 0;
+	packet_queue->etm_timestamp = 0;
+	packet_queue->next_etm_timestamp = 0;
 	packet_queue->instr_count = 0;
 }
 
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 7e63e7dedc33..c25da2ffa8f3 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -38,8 +38,6 @@
 #include <tools/libc_compat.h>
 #include "util/synthetic-events.h"
 
-#define MAX_TIMESTAMP (~0ULL)
-
 struct cs_etm_auxtrace {
 	struct auxtrace auxtrace;
 	struct auxtrace_queues queues;
@@ -86,7 +84,7 @@ struct cs_etm_queue {
 	struct cs_etm_decoder *decoder;
 	struct auxtrace_buffer *buffer;
 	unsigned int queue_nr;
-	u8 pending_timestamp;
+	u8 pending_timestamp_chan_id;
 	u64 offset;
 	const unsigned char *buf;
 	size_t buf_len, buf_used;
@@ -208,7 +206,7 @@ void cs_etm__etmq_set_traceid_queue_timestamp(struct cs_etm_queue *etmq,
 	 * be more than one channel per cs_etm_queue, we need to specify
 	 * what traceID queue needs servicing.
 	 */
-	etmq->pending_timestamp = trace_chan_id;
+	etmq->pending_timestamp_chan_id = trace_chan_id;
 }
 
 static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
@@ -216,22 +214,22 @@ static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
 {
 	struct cs_etm_packet_queue *packet_queue;
 
-	if (!etmq->pending_timestamp)
+	if (!etmq->pending_timestamp_chan_id)
 		return 0;
 
 	if (trace_chan_id)
-		*trace_chan_id = etmq->pending_timestamp;
+		*trace_chan_id = etmq->pending_timestamp_chan_id;
 
 	packet_queue = cs_etm__etmq_get_packet_queue(etmq,
-						     etmq->pending_timestamp);
+						     etmq->pending_timestamp_chan_id);
 	if (!packet_queue)
 		return 0;
 
 	/* Acknowledge pending status */
-	etmq->pending_timestamp = 0;
+	etmq->pending_timestamp_chan_id = 0;
 
 	/* See function cs_etm_decoder__do_{hard|soft}_timestamp() */
-	return packet_queue->timestamp;
+	return packet_queue->etm_timestamp;
 }
 
 static void cs_etm__clear_packet_queue(struct cs_etm_packet_queue *queue)
@@ -814,7 +812,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 	int ret = 0;
 	unsigned int cs_queue_nr;
 	u8 trace_chan_id;
-	u64 timestamp;
+	u64 etm_timestamp;
 	struct cs_etm_queue *etmq = queue->priv;
 
 	if (list_empty(&queue->head) || etmq)
@@ -854,7 +852,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 
 		/*
 		 * Run decoder on the trace block.  The decoder will stop when
-		 * encountering a timestamp, a full packet queue or the end of
+		 * encountering an ETM timestamp, a full packet queue or the end of
 		 * trace for that block.
 		 */
 		ret = cs_etm__decode_data_block(etmq);
@@ -865,10 +863,10 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 		 * Function cs_etm_decoder__do_{hard|soft}_timestamp() does all
 		 * the timestamp calculation for us.
 		 */
-		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
+		etm_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
 
 		/* We found a timestamp, no need to continue. */
-		if (timestamp)
+		if (etm_timestamp)
 			break;
 
 		/*
@@ -892,7 +890,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 	 * queue and will be processed in cs_etm__process_queues().
 	 */
 	cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
-	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
+	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, etm_timestamp);
 out:
 	return ret;
 }
@@ -2221,7 +2219,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 	int ret = 0;
 	unsigned int cs_queue_nr, queue_nr;
 	u8 trace_chan_id;
-	u64 timestamp;
+	u64 etm_timestamp;
 	struct auxtrace_queue *queue;
 	struct cs_etm_queue *etmq;
 	struct cs_etm_traceid_queue *tidq;
@@ -2283,9 +2281,9 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 		if (ret)
 			goto out;
 
-		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
+		etm_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
 
-		if (!timestamp) {
+		if (!etm_timestamp) {
 			/*
 			 * Function cs_etm__decode_data_block() returns when
 			 * there is no more traces to decode in the current
@@ -2308,7 +2306,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 		 * this queue/traceID.
 		 */
 		cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
-		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
+		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, etm_timestamp);
 	}
 
 out:
@@ -2380,7 +2378,7 @@ static int cs_etm__process_event(struct perf_session *session,
 				 struct perf_tool *tool)
 {
 	int err = 0;
-	u64 timestamp;
+	u64 sample_kernel_timestamp;
 	struct cs_etm_auxtrace *etm = container_of(session->auxtrace,
 						   struct cs_etm_auxtrace,
 						   auxtrace);
@@ -2394,11 +2392,11 @@ static int cs_etm__process_event(struct perf_session *session,
 	}
 
 	if (sample->time && (sample->time != (u64) -1))
-		timestamp = sample->time;
+		sample_kernel_timestamp = sample->time;
 	else
-		timestamp = 0;
+		sample_kernel_timestamp = 0;
 
-	if (timestamp || etm->timeless_decoding) {
+	if (sample_kernel_timestamp || etm->timeless_decoding) {
 		err = cs_etm__update_queues(etm);
 		if (err)
 			return err;
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 36428918411e..b300f6fa19cc 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -171,8 +171,8 @@ struct cs_etm_packet_queue {
 	u32 head;
 	u32 tail;
 	u32 instr_count;
-	u64 timestamp;
-	u64 next_timestamp;
+	u64 etm_timestamp;
+	u64 next_etm_timestamp;
 	struct cs_etm_packet packet_buffer[CS_ETM_PACKET_MAX_BUFFER];
 };
 
-- 
2.28.0



From james.clark at arm.com  Wed Apr 14 15:39:19 2021
From: james.clark at arm.com (James Clark)
Date: Wed, 14 Apr 2021 17:39:19 +0300
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to preserve
 ordering
In-Reply-To: <20210414143919.12605-1-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
Message-ID: <20210414143919.12605-2-james.clark@arm.com>

The following attribute is set when synthesising samples in
timed decoding mode:

    attr.sample_type |= PERF_SAMPLE_TIME;

This results in new samples that appear to have timestamps but
because we don't assign any timestamps to the samples, when the
resulting inject file is opened again, the synthesised samples
will be on the wrong side of the MMAP or COMM events.

For example this results in the samples being associated with
the perf binary, rather than the target of the record:

    perf record -e cs_etm/@tmc_etr0/u top
    perf inject -i perf.data -o perf.inject --itrace=i100il
    perf report -i perf.inject

Where 'Command' == perf should show as 'top':

    # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
    # ........  .......  ....................  ......................  ......................  ..................
    #
        31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -

If the perf.data file is opened directly with perf, without the
inject step, then this already works correctly because the
events are synthesised after the COMM and MMAP events and
no second sorting happens. Re-sorting only happens when opening
the perf.inject file for the second time so timestamps are
needed.

Using the timestamp from the AUX record mirrors the current
behaviour when opening directly with perf, because the events
are generated on the call to cs_etm__process_queues().

Signed-off-by: James Clark <james.clark at arm.com>
Co-developed-by: Al Grant <al.grant at arm.com>
Signed-off-by: Al Grant <al.grant at arm.com>
---
 tools/perf/util/cs-etm.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index c25da2ffa8f3..d0fa9dce47f1 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
 	u8 sample_instructions;
 
 	int num_cpu;
+	u64 latest_kernel_timestamp;
 	u32 auxtrace_type;
 	u64 branches_sample_type;
 	u64 branches_id;
@@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
 	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
 	event->sample.header.size = sizeof(struct perf_event_header);
 
+	if (!etm->timeless_decoding)
+		sample.time = etm->latest_kernel_timestamp;
 	sample.ip = addr;
 	sample.pid = tidq->pid;
 	sample.tid = tidq->tid;
@@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
 	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
 	event->sample.header.size = sizeof(struct perf_event_header);
 
+	if (!etm->timeless_decoding)
+		sample.time = etm->latest_kernel_timestamp;
 	sample.ip = ip;
 	sample.pid = tidq->pid;
 	sample.tid = tidq->tid;
@@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
 	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
 		return cs_etm__process_switch_cpu_wide(etm, event);
 
-	if (!etm->timeless_decoding &&
-	    event->header.type == PERF_RECORD_AUX)
+	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
+		etm->latest_kernel_timestamp = sample_kernel_timestamp;
 		return cs_etm__process_queues(etm);
+	}
 
 	return 0;
 }
-- 
2.28.0



From james.clark at arm.com  Wed Apr 14 15:41:46 2021
From: james.clark at arm.com (James Clark)
Date: Wed, 14 Apr 2021 17:41:46 +0300
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210414143919.12605-2-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
Message-ID: <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>

Hi,

For this change, I also tried removing the setting of PERF_SAMPLE_TIME in cs_etm__synth_events(). In theory, this would remove the sorting when opening the file, but the change doesn't affect when the built-in events are saved to the inject file. Resulting in events like MMAP and COMM with timestamps, but the synthesised events without. This results in the same issue of the synthesised events appearing before the COMM and MMAP events. If it was possible to somehow tell perf to remove timestamps from built-in events, removing PERF_SAMPLE_TIME would probably be the right solution, because we don't set sample.time.

For Arm v8.4 we will have the kernel time in the etm timestamps, so an if can be added to switch between this behaviour and the next (more correct) one depending on the hardware. 

On the subject of timestamps, but not related to this change, some combinations of timestamp options aren't working. For example:

    perf record -e cs_etm/time, at tmc_etr0/u --per-thread
or  perf record -e cs_etm/@tmc_etr0/u --timestamp --per-thread

These don't work because of the assumption that etm->timeless_decoding == --per-thread
and kernel timestamps enabled (/time/ or --timestamp) == etm timestamps enabled (/timestamp/), which isn't necessarily true.

This can be made to work with a few code changes for cs_etm/time,timestamp/u --per-thread, but cs_etm/time/u --per-thread could be a bit more work. Changes involved would be using "per_cpu_mmaps" in some places instead of etm->timeless_decoding, and also setting etm->timeless_decoding based on whether there are any etm timestamps, not kernel ones. Although to search for any etm timestamp would involve a full decode ahead of time which might not be feasible (or maybe just checking the options, although that's not how it's done in cs_etm__is_timeless_decoding() currently).

Or, we could force /time/ and /timestamp/ options to always be enabled together in the record stage. 


Thanks
James

On 14/04/2021 17:39, James Clark wrote:
> The following attribute is set when synthesising samples in
> timed decoding mode:
> 
>     attr.sample_type |= PERF_SAMPLE_TIME;
> 
> This results in new samples that appear to have timestamps but
> because we don't assign any timestamps to the samples, when the
> resulting inject file is opened again, the synthesised samples
> will be on the wrong side of the MMAP or COMM events.
> 
> For example this results in the samples being associated with
> the perf binary, rather than the target of the record:
> 
>     perf record -e cs_etm/@tmc_etr0/u top
>     perf inject -i perf.data -o perf.inject --itrace=i100il
>     perf report -i perf.inject
> 
> Where 'Command' == perf should show as 'top':
> 
>     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>     # ........  .......  ....................  ......................  ......................  ..................
>     #
>         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
> 
> If the perf.data file is opened directly with perf, without the
> inject step, then this already works correctly because the
> events are synthesised after the COMM and MMAP events and
> no second sorting happens. Re-sorting only happens when opening
> the perf.inject file for the second time so timestamps are
> needed.
> 
> Using the timestamp from the AUX record mirrors the current
> behaviour when opening directly with perf, because the events
> are generated on the call to cs_etm__process_queues().
> 
> Signed-off-by: James Clark <james.clark at arm.com>
> Co-developed-by: Al Grant <al.grant at arm.com>
> Signed-off-by: Al Grant <al.grant at arm.com>
> ---
>  tools/perf/util/cs-etm.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index c25da2ffa8f3..d0fa9dce47f1 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>  	u8 sample_instructions;
>  
>  	int num_cpu;
> +	u64 latest_kernel_timestamp;
>  	u32 auxtrace_type;
>  	u64 branches_sample_type;
>  	u64 branches_id;
> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = addr;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = ip;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>  		return cs_etm__process_switch_cpu_wide(etm, event);
>  
> -	if (!etm->timeless_decoding &&
> -	    event->header.type == PERF_RECORD_AUX)
> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
>  		return cs_etm__process_queues(etm);
> +	}
>  
>  	return 0;
>  }
> 


From sneeli at xilinx.com  Wed Apr 14 15:45:55 2021
From: sneeli at xilinx.com (Srinivas Neeli)
Date: Wed, 14 Apr 2021 14:45:55 +0000
Subject: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
 the code
In-Reply-To: <CAMpxmJW=HWf_NxGpfBkX=utgOTs4+6RtypxnKGtpuYnX=t8rGQ@mail.gmail.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
 <20210409140806.31824-2-srinivas.neeli@xilinx.com>
 <CAHp75Vddd6ygr4mJ9Z+SuGZmfLcgDLWLZaxby2XE2mX8War-qQ@mail.gmail.com>
 <CAMpxmJW=HWf_NxGpfBkX=utgOTs4+6RtypxnKGtpuYnX=t8rGQ@mail.gmail.com>
Message-ID: <DM6PR02MB5386CADF5A10EF28A640AD76AF4E9@DM6PR02MB5386.namprd02.prod.outlook.com>

HI baratosz and Andy,

> -----Original Message-----
> From: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> Sent: Tuesday, April 13, 2021 4:14 PM
> To: Andy Shevchenko <andy.shevchenko at gmail.com>
> Cc: Srinivas Neeli <sneeli at xilinx.com>; linus.walleij at linaro.org; Michal Simek
> <michals at xilinx.com>; Shubhrajyoti Datta <shubhraj at xilinx.com>; Srinivas
> Goud <sgoud at xilinx.com>; linux-gpio at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; git
> <git at xilinx.com>
> Subject: Re: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
> the code
> 
> On Sat, Apr 10, 2021 at 12:08 AM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> >
> >
> >
> > On Friday, April 9, 2021, Srinivas Neeli <srinivas.neeli at xilinx.com> wrote:
> >>
> >> module_platform_driver() makes the code simpler by eliminating
> >> boilerplate code.
> >>
> >> Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
> >> ---
> >>  drivers/gpio/gpio-zynq.c | 17 +----------------
> >>  1 file changed, 1 insertion(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> >> index 3521c1dc3ac0..bb1ac0c5cf26 100644
> >> --- a/drivers/gpio/gpio-zynq.c
> >> +++ b/drivers/gpio/gpio-zynq.c
> >> @@ -1020,22 +1020,7 @@ static struct platform_driver zynq_gpio_driver
> = {
> >>         .remove = zynq_gpio_remove,
> >>  };
> >>
> >> -/**
> >> - * zynq_gpio_init - Initial driver registration call
> >> - *
> >> - * Return: value from platform_driver_register
> >> - */
> >> -static int __init zynq_gpio_init(void) -{
> >> -       return platform_driver_register(&zynq_gpio_driver);
> >> -}
> >> -postcore_initcall(zynq_gpio_init);
> >
> >
> >
> > It?s not an equivalent. Have you tested on actual hardware? If no, there is
> no go for this change.
> >
> 
> Yep, this has been like this since the initial introduction of this driver.
> Unfortunately there's no documented reason so unless we can test it, it has
> to stay this way.
> 
I tested driver, functionality wise everything working fine.
Based on below conversation, I moved driver to module driver.
https://lore.kernel.org/patchwork/patch/818202/

Thanks
Srinivas Neeli

> Bartosz

From matthias.bgg at kernel.org  Wed Apr 14 15:46:40 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Wed, 14 Apr 2021 16:46:40 +0200
Subject: [PATCH 1/3] arm64: dts: mt8183-pumpkin: fix dtbs_check warning
Message-ID: <20210414144643.17435-1-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

Fix unit names to make dtbs_check happy.

Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
---

 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index eb6e595c2975..0aff5eb52e88 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -32,7 +32,7 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
-		scp_mem_reserved: scp_mem_region {
+		scp_mem_reserved: scp_mem_region at 50000000 {
 			compatible = "shared-dma-pool";
 			reg = <0 0x50000000 0 0x2900000>;
 			no-map;
@@ -55,7 +55,7 @@ led-green {
 		};
 	};
 
-	ntc at 0 {
+	ntc {
 		compatible = "murata,ncp03wf104";
 		pullup-uv = <1800000>;
 		pullup-ohm = <390000>;
-- 
2.30.2



From richardcochran at gmail.com  Wed Apr 14 15:46:47 2021
From: richardcochran at gmail.com (Richard Cochran)
Date: Wed, 14 Apr 2021 07:46:47 -0700
Subject: [PATCH net-next v4 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210414001617.3490-1-vee.khee.wong@linux.intel.com>
References: <20210414001617.3490-1-vee.khee.wong@linux.intel.com>
Message-ID: <20210414144647.GA9318@hoboy.vegasvil.org>

On Wed, Apr 14, 2021 at 08:16:17AM +0800, Wong Vee Khee wrote:
> From: Tan Tee Min <tee.min.tan at intel.com>
> 
> The Synopsis MAC controller supports auxiliary snapshot feature that
> allows user to store a snapshot of the system time based on an external
> event.
> 
> This patch add supports to the above mentioned feature. Users will be
> able to triggered capturing the time snapshot from user-space using
> application such as testptp or any other applications that uses the
> PTP_EXTTS_REQUEST ioctl request.
> 
> Cc: Richard Cochran <richardcochran at gmail.com>
> Signed-off-by: Tan Tee Min <tee.min.tan at intel.com>
> Co-developed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
> Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>

Acked-by: Richard Cochran <richardcochran at gmail.com>


From matthias.bgg at kernel.org  Wed Apr 14 15:46:41 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Wed, 14 Apr 2021 16:46:41 +0200
Subject: [PATCH 2/3] arm64: dts: mt8183: fix dtbs_check warning
In-Reply-To: <20210414144643.17435-1-matthias.bgg@kernel.org>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
Message-ID: <20210414144643.17435-2-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

Fix unit names to make dtbs_check happy.

Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
---

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 0ff7b67a6806..c5e822b6b77a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -681,13 +681,13 @@ cpu_thermal: cpu_thermal {
 				sustainable-power = <5000>;
 
 				trips {
-					threshold: trip-point at 0 {
+					threshold: trip-point0 {
 						temperature = <68000>;
 						hysteresis = <2000>;
 						type = "passive";
 					};
 
-					target: trip-point at 1 {
+					target: trip-point1 {
 						temperature = <80000>;
 						hysteresis = <2000>;
 						type = "passive";
@@ -1103,7 +1103,7 @@ u2port0: usb-phy at 0 {
 				status = "okay";
 			};
 
-			u3port0: usb-phy at 0700 {
+			u3port0: usb-phy at 700 {
 				reg = <0x0700 0x900>;
 				clocks = <&clk26m>;
 				clock-names = "ref";
-- 
2.30.2



From matthias.bgg at kernel.org  Wed Apr 14 15:46:42 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Wed, 14 Apr 2021 16:46:42 +0200
Subject: [PATCH 3/3] arm64: dts: mt8183-kukui: fix dtbs_check warnings
In-Reply-To: <20210414144643.17435-1-matthias.bgg@kernel.org>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
Message-ID: <20210414144643.17435-3-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

The dsi children don't have any reg property, so we don't need address and
size cells. This makes dtbs_check happy.

CC: Hsin-Yi Wang <hsinyi at chromium.org>
CC: Enric Balletbo i Serra <enric.balletbo at collabora.com>
CC: Nicolas Boichat <drinkcat at chromium.org>
Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>

---

 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index ff56bcfa3370..f4dca6a33168 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -251,8 +251,7 @@ &cpu7 {
 
 &dsi0 {
 	status = "okay";
-	#address-cells = <1>;
-	#size-cells = <0>;
+
 	panel: panel at 0 {
 		/* compatible will be set in board dts */
 		reg = <0>;
-- 
2.30.2



From robh at kernel.org  Wed Apr 14 15:50:33 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 09:50:33 -0500
Subject: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
In-Reply-To: <20210414104939.1093-2-billy_tsai@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
 <20210414104939.1093-2-billy_tsai@aspeedtech.com>
Message-ID: <1618411833.809131.3605228.nullmailer@robh.at.kernel.org>

On Wed, 14 Apr 2021 18:49:38 +0800, Billy Tsai wrote:
> This patch adds device bindings for aspeed pwm-tach device which is a
> multi-function device include pwn and tach function and pwm device which
> should be the sub-node of pwm-tach device.
> 
> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545
> ---
>  .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++++++++++++++++++
>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 44 ++++++++++++++
>  2 files changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.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/mfd/aspeed,ast2600-pwm-tach.example.dt.yaml:0:0: /example-0/pwm_tach at 1e610000/tach at 1: failed to match any schema with compatible: ['aspeed,ast2600-tach']

See https://patchwork.ozlabs.org/patch/1466127

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From jassisinghbrar at gmail.com  Wed Apr 14 15:53:18 2021
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Wed, 14 Apr 2021 09:53:18 -0500
Subject: [PATCH v2, 0/5] Revert "mailbox: mediatek: remove implementation
 related to atomic_exec"
In-Reply-To: <1d946d1c-1626-33ed-26ba-f840729d63e7@gmail.com>
References: <1618226325-31927-1-git-send-email-yongqiang.niu@mediatek.com>
 <CABb+yY1b9wD0hoBx=aYzpLcF-=EEG4QTrV68sZj8+rtf5J1aJQ@mail.gmail.com>
 <1d946d1c-1626-33ed-26ba-f840729d63e7@gmail.com>
Message-ID: <CABb+yY2ar8LcYMUrOTP8gH+DhNdV3aL7nuod4Uc_fuQq2A8K+A@mail.gmail.com>

On Wed, Apr 14, 2021 at 3:51 AM Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
>
> On 12/04/2021 17:29, Jassi Brar wrote:
> > On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu
> > <yongqiang.niu at mediatek.com> wrote:
> >>
> >> This series base linux 5.12-rc2
> >> these patches will cause home ui flick when cursor moved,
> >> there is no fix solution yet, revert these patches first.
> >>
> >> change since v1:
> >> add mtk-gce.txt and dts modification
> >>
> >> Yongqiang Niu (5):
> >>   Revert "drm/mediatek: Make sure previous message done or be aborted
> >>     before send"
> >>   Revert "mailbox: mediatek: remove implementation related to
> >>     atomic_exec"
> >>   Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value"
> >>   Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells
> >>     value"
> >>   arm64: dts: mediatek: mt8183: add gce information for mmsys
> >>
> >>  .../devicetree/bindings/mailbox/mtk-gce.txt        |  2 +-
> >>  arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  5 +-
> >>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c            |  1 -
> >>  drivers/mailbox/mtk-cmdq-mailbox.c                 | 80 +++++++++++++++++++---
> >>  4 files changed, 76 insertions(+), 12 deletions(-)
> >>
> > Please break the patchsets (this and the other 3) into mailbox only
> > and platform specific ones.
> > Also, it would help if there are some acked/reviewed by some mtk folks
> > especially when reverting patches.
> >
>
> I'd prefer to have DT and mailbox patches together as otherwise the burden on me
> to find out which patches in the driver are needed, and to check if these got
> accepted, gets higher.
>
I meant the patches that need to go via mailbox tree (controller) and the rest.

thanks.


From bjorn.andersson at linaro.org  Wed Apr 14 16:01:29 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 14 Apr 2021 10:01:29 -0500
Subject: [PATCH v4 2/2] remoteproc: stm32: add capability to detach
In-Reply-To: <3df5317b-d28a-9362-6876-99442fdb8ef5@foss.st.com>
References: <20210331073347.8293-1-arnaud.pouliquen@foss.st.com>
 <20210331073347.8293-3-arnaud.pouliquen@foss.st.com>
 <YHYOd/vqeZCiqkpJ@builder.lan>
 <3df5317b-d28a-9362-6876-99442fdb8ef5@foss.st.com>
Message-ID: <YHcDyUap4cU8WNh6@builder.lan>

On Wed 14 Apr 02:23 CDT 2021, Arnaud POULIQUEN wrote:
> On 4/13/21 11:34 PM, Bjorn Andersson wrote:
> > On Wed 31 Mar 02:33 CDT 2021, Arnaud Pouliquen wrote:
[..]
> >> +		err = mbox_send_message(ddata->mb[idx].chan,
> >> +					&dummy_data);
> > 
> > Seems I posted my comment on v1, rather than this latest version. Please
> > let me know if we should do anything about this dummy_data.
> 
> Thanks for pointing this out, you are right, the mailbox driver is stm32_ipcc
> and it only sends a signal to the remote processor.
> 
> As message can be queued by the mailbox framework using a local variable seems
> not a good option. As this code is a copy/past of the kick and stop?
> I propose to get this one and I will send a new patch to fix the usage in the
> whole driver.
> 

That works for me, I've merged the two patches.

Thanks,
Bjorn


From david at redhat.com  Wed Apr 14 16:12:11 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 14 Apr 2021 17:12:11 +0200
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <20210407172607.8812-2-rppt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
Message-ID: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>

On 07.04.21 19:26, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().

I assume these pages are never given to the buddy, because we don't have 
a direct mapping. So to the kernel, it's essentially just like a memory 
hole with benefits.

I can spot that we want to export such memory like any special memory 
thingy/hole in /proc/iomem -- "reserved", which makes sense.

I would assume that MEMBLOCK_NOMAP is a special type of *reserved* 
memory. IOW, that for_each_reserved_mem_range() should already succeed 
on these as well -- we should mark anything that is MEMBLOCK_NOMAP 
implicitly as reserved. Or are there valid reasons not to do so? What 
can anyone do with that memory?

I assume they are pretty much useless for the kernel, right? Like other 
reserved memory ranges.


> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   mm/memblock.c | 23 +++++++++++++++++++++--
>   1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..6b7ea9d86310 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>   	return end_pfn - start_pfn;
>   }
>   
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}
> +}
> +
>   static unsigned long __init free_low_memory_core_early(void)
>   {
>   	unsigned long count = 0;
> @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
>   
>   	memblock_clear_hotplug(0, -1);
>   
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>   
>   	/*
>   	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 


-- 
Thanks,

David / dhildenb



From ardb at kernel.org  Wed Apr 14 16:27:53 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Wed, 14 Apr 2021 17:27:53 +0200
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
Message-ID: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>

On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david at redhat.com> wrote:
>
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved region just before the memory is freed from memblock to the buddy
> > page allocator.
> >
> > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > values set by the memory map initialization which makes it necessary to
> > have a special treatment for such pages in pfn_valid() and
> > pfn_valid_within().
>
> I assume these pages are never given to the buddy, because we don't have
> a direct mapping. So to the kernel, it's essentially just like a memory
> hole with benefits.
>
> I can spot that we want to export such memory like any special memory
> thingy/hole in /proc/iomem -- "reserved", which makes sense.
>
> I would assume that MEMBLOCK_NOMAP is a special type of *reserved*
> memory. IOW, that for_each_reserved_mem_range() should already succeed
> on these as well -- we should mark anything that is MEMBLOCK_NOMAP
> implicitly as reserved. Or are there valid reasons not to do so? What
> can anyone do with that memory?
>
> I assume they are pretty much useless for the kernel, right? Like other
> reserved memory ranges.
>

On ARM, we need to know whether any physical regions that do not
contain system memory contain something with device semantics or not.
One of the examples is ACPI tables: these are in reserved memory, and
so they are not covered by the linear region. However, when the ACPI
core ioremap()s an arbitrary memory region, we don't know whether it
is mapping a memory region or a device region unless we keep track of
this in some way. (Device mappings require device attributes, but
firmware tables require memory attributes, as they might be accessed
using misaligned reads)


>
> >
> > Split out initialization of the reserved pages to a function with a
> > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> > reserved regions and mark struct pages for the NOMAP regions as
> > PageReserved.
> >
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   mm/memblock.c | 23 +++++++++++++++++++++--
> >   1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..6b7ea9d86310 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
> >       return end_pfn - start_pfn;
> >   }
> >
> > +static void __init memmap_init_reserved_pages(void)
> > +{
> > +     struct memblock_region *region;
> > +     phys_addr_t start, end;
> > +     u64 i;
> > +
> > +     /* initialize struct pages for the reserved regions */
> > +     for_each_reserved_mem_range(i, &start, &end)
> > +             reserve_bootmem_region(start, end);
> > +
> > +     /* and also treat struct pages for the NOMAP regions as PageReserved */
> > +     for_each_mem_region(region) {
> > +             if (memblock_is_nomap(region)) {
> > +                     start = region->base;
> > +                     end = start + region->size;
> > +                     reserve_bootmem_region(start, end);
> > +             }
> > +     }
> > +}
> > +
> >   static unsigned long __init free_low_memory_core_early(void)
> >   {
> >       unsigned long count = 0;
> > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
> >
> >       memblock_clear_hotplug(0, -1);
> >
> > -     for_each_reserved_mem_range(i, &start, &end)
> > -             reserve_bootmem_region(start, end);
> > +     memmap_init_reserved_pages();
> >
> >       /*
> >        * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> >
>
>
> --
> Thanks,
>
> David / dhildenb
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From l.stach at pengutronix.de  Wed Apr 14 16:33:03 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Wed, 14 Apr 2021 17:33:03 +0200
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
Message-ID: <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>

Hi Robin,

Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > Hi
> > > 
> > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach <l.stach at pengutronix.de>
> > wrote:
> > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > > There are two requirements that we need to move the request of dma
> > > > > channel from probe to open.
> > > > 
> > > > How do you handle -EPROBE_DEFER return code from the channel request
> > > > if you don't do it in probe?
> > > 
> > > I use the dma_request_slave_channel or dma_request_channel instead of
> > > dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
> > > return code.
> > 
> > This is a pretty weak argument. The dmaengine device might probe after you
> > try to get the channel. Using a function to request the channel that doesn't
> > allow you to handle probe deferral is IMHO a bug and should be fixed, instead
> > of building even more assumptions on top of it.
> > 
> > > > > - When dma device binds with power-domains, the power will be
> > > > > enabled when we request dma channel. If the request of dma channel
> > > > > happen on probe, then the power-domains will be always enabled
> > > > > after kernel boot up,  which is not good for power saving,  so we
> > > > > need to move the request of dma channel to .open();
> > > > 
> > > > This is certainly something which could be fixed in the dmaengine
> > > > driver.
> > > 
> > > Dma driver always call the pm_runtime_get_sync in
> > > device_alloc_chan_resources, the device_alloc_chan_resources is called
> > > when channel is requested. so power is enabled on channel request.
> > 
> > So why can't you fix the dmaengine driver to do that RPM call at a later time
> > when the channel is actually going to be used? This will allow further power
> > savings with other slave devices than the audio PCM.
> Hi Lucas,
> ??Thanks for your suggestion. I have tried to implement runtime autosuspend in
> fsl-edma driver on i.mx8qm/qxp with delay time (2 sec) for this feature as below
> (or you can refer to drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> pm_runtime_put_autosuspend in all dmaengine driver interface like
> device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_cyclic/
> device_tx_status...
> 
> 
> ????????????????pm_runtime_use_autosuspend(fsl_chan->dev);
> ????????????????pm_runtime_set_autosuspend_delay(fsl_chan->dev, 2000);
> 
> That could resolve this audio case since the autosuspend could suspend runtime after
> 2 seconds if there is no further dma transfer but only channel request(device_alloc_chan_resources).
> But unfortunately, it cause another issue. As you know, on our i.mx8qm/qxp, 
> power domain done by scfw (drivers/firmware/imx/scu-pd.c) over mailbox:
> ?imx_sc_pd_power()->imx_scu_call_rpc()-> imx_scu_ipc_write()->mbox_send_message()
> which means have to 'waits for completion', meanwhile, some driver like tty will call dmaengine
> interfaces in non-atomic case as below, 
> 
> static int uart_write(struct tty_struct *tty, const unsigned char *buf, int count)
> {
> ???.......
> 	    port = uart_port_lock(state, flags);
> ???......
> ????????__uart_start(tty);  //call start_tx()->dmaengine_prep_slave_sg...
> ????????uart_port_unlock(port, flags);
> ????????return ret;
> }
> 
> Thus dma runtime resume may happen in that timing window and cause kernel alarm. 
> I'm not sure whether there are similar limitations on other driver subsystem. But for me,
> It looks like the only way to resolve the contradiction between tty and scu-pd (hardware
> limitation on i.mx8qm/qxp) is to give up autosuspend and keep pm_runtime_get_sync
> only in device_alloc_chan_resources because request channel is a safe non-atomic phase. 
> Do you have any idea? Thanks in advance. 

If you look closely at the driver you used as an example (hidma.c) it
looks like there is already something in there, which looks very much
like what you need here:

In hidma_issue_pending() the driver tries to get the device to runtime
resume. If this doesn't work, maybe due to the power domain code not
being able to be called in atomic context, the actual work of waking up
the dma hardware and issuing the descriptor is shunted to a tasklet.

If I'm reading this right, this is exactly what you need here to be
able to call the dmaengine code from atomic context: try the rpm get
and issue immediately when possible, otherwise shunt the work to a non-
atomic context where you can deal with the requirements of scu-pd.

Also you don't need the runtime resume in all of the functions you
mentioned. From a quick look into the edma driver it looks like for
example the prep_slave_dma() function only touches data structures in
memory, so you don't actually need the device to be awake at that
point. Only later in the flow when you write registers in the dma
hardware and actually issue the transfer you need to wake the device
from sleep.

Regards,
Lucas

> ??
> 
> 
> 
> 
> > 
> > > > > - With FE-BE case, if the dma channel is requested in probe, then
> > > > > there will be below issue, which is caused by that the dma channel
> > > > > will be requested duplicately
> > > > 
> > > > Why is this requested a second time? Is this just some missing
> > > > cleanup on a deferred probe path?
> > > 
> > > Not relate with deferred probe.  With DMA1->ASRC->DMA2->ESAI case, the
> > > DMA1->ASRC->DMA2 is in FE,  ESAI is in BE.  When ESAI drvier probe,
> > > DMA3 channel is created with ESAI's "dma:tx" (DMA3 channel
> > > is not used in this FE-BE case).    When FE-BE startup, DMA2
> > > channel is created, it needs the ESAI's "dma:tx", so below warning
> > > comes out.
> > > 
> > > > Regards,
> > > > Lucas
> > > > 
> > > > > [  638.906268] sysfs: cannot create duplicate filename
> > '/devices/soc0/soc/2000000.bus/2000000.spba-bus/2024000.esai/dma:tx'
> > > > > [  638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted
> > > > > 5.7.0-rc1-12956-gfc64b2585593 #287 [  638.927113] Hardware name:
> > > > > Freescale i.MX6 Quad/DualLite (Device Tree) [  638.933690]
> > > > > [<c0110dd8>] (unwind_backtrace) from [<c010b8ec>]
> > > > > (show_stack+0x10/0x14) [  638.941464] [<c010b8ec>] (show_stack)
> > > > > from [<c0557fc0>] (dump_stack+0xe4/0x118) [  638.948808]
> > > > > [<c0557fc0>] (dump_stack) from [<c032aeb4>]
> > > > > (sysfs_warn_dup+0x50/0x64) [  638.956406] [<c032aeb4>]
> > > > > (sysfs_warn_dup) from [<c032b1a8>]
> > > > > (sysfs_do_create_link_sd+0xc8/0xd4)
> > > > > [  638.965134] [<c032b1a8>] (sysfs_do_create_link_sd) from
> > > > > [<c05dc668>] (dma_request_chan+0xb0/0x210) [  638.974120]
> > > > > [<c05dc668>] (dma_request_chan) from [<c05dc7d0>]
> > > > > (dma_request_slave_channel+0x8/0x14)
> > > > > [  638.983111] [<c05dc7d0>] (dma_request_slave_channel) from
> > > > > [<c09d5548>] (fsl_asrc_dma_hw_params+0x1e0/0x438)
> > > > > [  638.992881] [<c09d5548>] (fsl_asrc_dma_hw_params) from
> > > > > [<c09c1654>] (soc_pcm_hw_params+0x4a0/0x6a8) [  639.001952]
> > > > > [<c09c1654>] (soc_pcm_hw_params) from [<c09c39d4>]
> > > > > (dpcm_fe_dai_hw_params+0x70/0xe4) [  639.010765] [<c09c39d4>]
> > > > > (dpcm_fe_dai_hw_params) from [<c099b274>]
> > > > > (snd_pcm_hw_params+0x158/0x418) [  639.019750] [<c099b274>]
> > > > > (snd_pcm_hw_params) from [<c099c5a0>]
> > (snd_pcm_ioctl+0x734/0x183c) [  639.028129] [<c099c5a0>] (snd_pcm_ioctl)
> > from [<c029ff94>] (ksys_ioctl+0x2ac/0xb98) [  639.035812] [<c029ff94>]
> > (ksys_ioctl) from [<c0100080>] (ret_fast_syscall+0x0/0x28) [  639.043490]
> > Exception stack(0xec529fa8 to 0xec529ff0)
> > > > > [  639.048565] 9fa0:                   bee84650 01321870
> > 00000004 c25c4111 bee84650 0002000f
> > > > > [  639.056766] 9fc0: bee84650 01321870 01321820 00000036
> > 00001f40
> > > > > 00000000 0002c2f8 00000003 [  639.064964] 9fe0: b6f483fc bee8451c
> > > > > b6ee2655 b6e1dcf8 [  639.070339] fsl-esai-dai 2024000.esai: Cannot
> > > > > create DMA dma:tx symlink
> > > > > 
> > > > > Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
> > > > > ---
> > > > > ?sound/soc/fsl/imx-pcm-dma.c | 173
> > > > > +++++++++++++++++++++++++++++++++---
> > > > > ?1 file changed, 159 insertions(+), 14 deletions(-)
> > > > > 
> > > > > diff --git a/sound/soc/fsl/imx-pcm-dma.c
> > > > > b/sound/soc/fsl/imx-pcm-dma.c index 04a9bc749016..dae53b384df4
> > > > > 100644
> > > > > --- a/sound/soc/fsl/imx-pcm-dma.c
> > > > > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > > > > @@ -11,6 +11,7 @@
> > > > > ?#include <linux/dmaengine.h>
> > > > > ?#include <linux/types.h>
> > > > > ?#include <linux/module.h>
> > > > > +#include <linux/dma-mapping.h>
> > > > > 
> > > > > ?#include <sound/core.h>
> > > > > ?#include <sound/pcm.h>
> > > > > @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void
> > *param)
> > > > > ??????return true;
> > > > > ?}
> > > > > 
> > > > > -static const struct snd_dmaengine_pcm_config
> > imx_dmaengine_pcm_config = {
> > > > > -     .prepare_slave_config =
> > snd_dmaengine_pcm_prepare_slave_config,
> > > > > -     .compat_filter_fn = filter,
> > > > > -};
> > > > > +static int imx_pcm_hw_params(struct snd_soc_component
> > *component,
> > > > > +                          struct snd_pcm_substream *substream,
> > > > > +                          struct snd_pcm_hw_params *params) {
> > > > > +     struct snd_pcm_runtime *runtime = substream->runtime;
> > > > > +     struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > > +     struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > > +     struct snd_dmaengine_dai_dma_data *dma_data;
> > > > > +     struct dma_slave_config config;
> > > > > +     struct dma_chan *chan;
> > > > > +     int ret = 0;
> > > > > 
> > > > > -int imx_pcm_dma_init(struct platform_device *pdev, size_t size)
> > > > > +     snd_pcm_set_runtime_buffer(substream,
> > &substream->dma_buffer);
> > > > > +     runtime->dma_bytes = params_buffer_bytes(params);
> > > > > +
> > > > > +     chan = snd_dmaengine_pcm_get_chan(substream);
> > > > > +     if (!chan)
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     ret = snd_hwparams_to_dma_slave_config(substream, params,
> > &config);
> > > > > +     if (ret)
> > > > > +             return ret;
> > > > > +
> > > > > +     dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > > +     if (!dma_data)
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     snd_dmaengine_pcm_set_config_from_dai_data(substream,
> > > > > +                                                dma_data,
> > > > > +                                                &config);
> > > > > +     return dmaengine_slave_config(chan, &config); }
> > > > > +
> > > > > +static int imx_pcm_hw_free(struct snd_soc_component *component,
> > > > > +                        struct snd_pcm_substream *substream)
> > > > > ?{
> > > > > -     struct snd_dmaengine_pcm_config *config;
> > > > > +     snd_pcm_set_runtime_buffer(substream, NULL);
> > > > > +     return 0;
> > > > > +}
> > > > > +
> > > > > +static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component
> > *component,
> > > > > +                                      struct snd_pcm_substream
> > > > > +*substream) {
> > > > > +     return snd_dmaengine_pcm_pointer(substream);
> > > > > +}
> > > > > +
> > > > > +static int imx_pcm_trigger(struct snd_soc_component *component,
> > > > > +                        struct snd_pcm_substream *substream, int
> > > > > +cmd) {
> > > > > +     return snd_dmaengine_pcm_trigger(substream, cmd); }
> > > > > +
> > > > > +static int imx_pcm_open(struct snd_soc_component *component,
> > > > > +                     struct snd_pcm_substream *substream) {
> > > > > +     struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > > > > +     bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > > > > +     struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> > > > > +     struct snd_dmaengine_dai_dma_data *dma_data;
> > > > > +     struct device *dev = component->dev;
> > > > > +     struct snd_pcm_hardware hw;
> > > > > +     struct dma_chan *chan;
> > > > > +     int ret;
> > > > > +
> > > > > +     ret = snd_pcm_hw_constraint_integer(substream->runtime,
> > > > > +
> > SNDRV_PCM_HW_PARAM_PERIODS);
> > > > > +     if (ret < 0) {
> > > > > +             dev_err(dev, "failed to set pcm hw params periods\n");
> > > > > +             return ret;
> > > > > +     }
> > > > > +
> > > > > +     dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
> > > > > +     if (!dma_data)
> > > > > +             return -EINVAL;
> > > > > +
> > > > > +     chan = dma_request_slave_channel(cpu_dai->dev, tx ? "tx" : "rx");
> > > > > +     if (!chan) {
> > > > > +             /* Try to request channel using compat_filter_fn */
> > > > > +             chan = snd_dmaengine_pcm_request_channel(filter,
> > > > > +
> > dma_data->filter_data);
> > > > > +             if (!chan)
> > > > > +                     return -ENXIO;
> > > > > +     }
> > > > > 
> > > > > -     config = devm_kzalloc(&pdev->dev,
> > > > > -                     sizeof(struct snd_dmaengine_pcm_config),
> > GFP_KERNEL);
> > > > > -     if (!config)
> > > > > -             return -ENOMEM;
> > > > > -     *config = imx_dmaengine_pcm_config;
> > > > > +     ret = snd_dmaengine_pcm_open(substream, chan);
> > > > > +     if (ret)
> > > > > +             goto pcm_open_fail;
> > > > > 
> > > > > -     return devm_snd_dmaengine_pcm_register(&pdev->dev,
> > > > > -             config,
> > > > > -             SND_DMAENGINE_PCM_FLAG_COMPAT);
> > > > > +     memset(&hw, 0, sizeof(hw));
> > > > > +     hw.info = SNDRV_PCM_INFO_MMAP |
> > SNDRV_PCM_INFO_MMAP_VALID |
> > > > > +                     SNDRV_PCM_INFO_INTERLEAVED;
> > > > > +     hw.periods_min = 2;
> > > > > +     hw.periods_max = UINT_MAX;
> > > > > +     hw.period_bytes_min = 256;
> > > > > +     hw.period_bytes_max =
> > dma_get_max_seg_size(chan->device->dev);
> > > > > +     hw.buffer_bytes_max = IMX_DEFAULT_DMABUF_SIZE;
> > > > > +     hw.fifo_size = dma_data->fifo_size;
> > > > > +
> > > > > +     /* Refine the hw according to caps of DMA. */
> > > > > +     ret = snd_dmaengine_pcm_refine_runtime_hwparams(substream,
> > > > > +
> > dma_data,
> > > > > +                                                     &hw,
> > > > > +                                                     chan);
> > > > > +     if (ret < 0)
> > > > > +             goto refine_runtime_hwparams_fail;
> > > > > +
> > > > > +     snd_soc_set_runtime_hwparams(substream, &hw);
> > > > > +
> > > > > +     /* Support allocate memory from IRAM */
> > > > > +     ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_IRAM,
> > > > > +                               chan->device->dev,
> > > > > +                               hw.buffer_bytes_max,
> > > > > +                               &substream->dma_buffer);
> > > > > +     if (ret < 0)
> > > > > +             goto alloc_pagas_fail;
> > > > > +
> > > > > +     return 0;
> > > > > +
> > > > > +alloc_pagas_fail:
> > > > > +refine_runtime_hwparams_fail:
> > > > > +     snd_dmaengine_pcm_close(substream);
> > > > > +pcm_open_fail:
> > > > > +     dma_release_channel(chan);
> > > > > +
> > > > > +     return ret;
> > > > > +}
> > > > > +
> > > > > +static int imx_pcm_close(struct snd_soc_component *component,
> > > > > +                      struct snd_pcm_substream *substream) {
> > > > > +     if (substream) {
> > > > > +             snd_dma_free_pages(&substream->dma_buffer);
> > > > > +             substream->dma_buffer.area = NULL;
> > > > > +             substream->dma_buffer.addr = 0;
> > > > > +     }
> > > > > +
> > > > > +     return snd_dmaengine_pcm_close_release_chan(substream);
> > > > > +}
> > > > > +
> > > > > +static int imx_pcm_new(struct snd_soc_component *component,
> > > > > +                    struct snd_soc_pcm_runtime *rtd) {
> > > > > +     struct snd_card *card = rtd->card->snd_card;
> > > > > +
> > > > > +     return dma_coerce_mask_and_coherent(card->dev,
> > > > > +DMA_BIT_MASK(32)); }
> > > > > +
> > > > > +static const struct snd_soc_component_driver imx_pcm_component = {
> > > > > +     .name           = "imx-pcm-dma",
> > > > > +     .pcm_construct  = imx_pcm_new,
> > > > > +     .open           = imx_pcm_open,
> > > > > +     .close          = imx_pcm_close,
> > > > > +     .hw_params      = imx_pcm_hw_params,
> > > > > +     .hw_free        = imx_pcm_hw_free,
> > > > > +     .trigger        = imx_pcm_trigger,
> > > > > +     .pointer        = imx_pcm_pointer,
> > > > > +};
> > > > > +
> > > > > +int imx_pcm_dma_init(struct platform_device *pdev, size_t size) {
> > > > > +     return devm_snd_soc_register_component(&pdev->dev,
> > > > > +
> > &imx_pcm_component,
> > > > > +NULL, 0);
> > > > > ?}
> > > > > ?EXPORT_SYMBOL_GPL(imx_pcm_dma_init);
> > > > > 
> 




From David.Laight at ACULAB.COM  Wed Apr 14 16:52:16 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 14 Apr 2021 15:52:16 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414115052.GS2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
Message-ID: <7f6cee3dcf1749fbb7b54eaf129141e7@AcuMS.aculab.com>

> Doing this fixes it:
> 
> +++ b/include/linux/types.h
> @@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
>   * so they don't care about the size of the actual bus addresses.
>   */
>  #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> -typedef u64 dma_addr_t;
> +typedef u64 __attribute__((aligned(sizeof(void *)))) dma_addr_t;
>  #else
>  typedef u32 dma_addr_t;
>  #endif

I hate __packed so much I've been checking what it does!

If you add __packed to the dma_addr_t field inside the union
then gcc (at least) removes the pad from before it, but also
'remembers' the alignment that is enforced by other members
of the structure.

So you don't need the extra aligned(sizeof (void *)) since
that is implicit.

So in this case __packed probably has no side effects.
(Unless a 32bit arch has instructions for a 64bit read
that must not be on an 8n+4 boundary and the address is taken).

It also doesn't affect 64bit - since the previous field
forces 64bit alignment.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From david at redhat.com  Wed Apr 14 16:52:57 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 14 Apr 2021 17:52:57 +0200
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
Message-ID: <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>

On 14.04.21 17:27, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david at redhat.com> wrote:
>>
>> On 07.04.21 19:26, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> The struct pages representing a reserved memory region are initialized
>>> using reserve_bootmem_range() function. This function is called for each
>>> reserved region just before the memory is freed from memblock to the buddy
>>> page allocator.
>>>
>>> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
>>> values set by the memory map initialization which makes it necessary to
>>> have a special treatment for such pages in pfn_valid() and
>>> pfn_valid_within().
>>
>> I assume these pages are never given to the buddy, because we don't have
>> a direct mapping. So to the kernel, it's essentially just like a memory
>> hole with benefits.
>>
>> I can spot that we want to export such memory like any special memory
>> thingy/hole in /proc/iomem -- "reserved", which makes sense.
>>
>> I would assume that MEMBLOCK_NOMAP is a special type of *reserved*
>> memory. IOW, that for_each_reserved_mem_range() should already succeed
>> on these as well -- we should mark anything that is MEMBLOCK_NOMAP
>> implicitly as reserved. Or are there valid reasons not to do so? What
>> can anyone do with that memory?
>>
>> I assume they are pretty much useless for the kernel, right? Like other
>> reserved memory ranges.
>>
> 
> On ARM, we need to know whether any physical regions that do not
> contain system memory contain something with device semantics or not.
> One of the examples is ACPI tables: these are in reserved memory, and
> so they are not covered by the linear region. However, when the ACPI
> core ioremap()s an arbitrary memory region, we don't know whether it
> is mapping a memory region or a device region unless we keep track of
> this in some way. (Device mappings require device attributes, but
> firmware tables require memory attributes, as they might be accessed
> using misaligned reads)

Using generically sounding NOMAP ("don't create direct mapping") to 
identify device regions feels like a hack. I know, it was introduced 
just for that purpose.

Looking at memblock_mark_nomap(), we consider "device regions"

1) ACPI tables

2) VIDEO_TYPE_EFI memory

3) some device-tree regions in of/fdt.c


IIUC, right now we end up creating a memmap for this NOMAP memory, but 
hide it away in pfn_valid(). This patch set at least fixes that.

Assuming these pages are never mapped to user space via the struct page 
(which better be the case), we could further use a new pagetype to mark 
these pages in a special way, such that we can identify them directly 
via pfn_to_page().

Then, we could mostly avoid having to query memblock at runtime to 
figure out that this is special memory. This would obviously be an 
extension to this series. Just a thought.

-- 
Thanks,

David / dhildenb



From suzuki.poulose at arm.com  Wed Apr 14 16:54:55 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 14 Apr 2021 16:54:55 +0100
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210414143919.12605-2-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
Message-ID: <d6b39eca-4f19-bace-ca3d-f36549caa51c@arm.com>

On 14/04/2021 15:39, James Clark wrote:
> The following attribute is set when synthesising samples in
> timed decoding mode:
> 
>      attr.sample_type |= PERF_SAMPLE_TIME;
> 
> This results in new samples that appear to have timestamps but
> because we don't assign any timestamps to the samples, when the
> resulting inject file is opened again, the synthesised samples
> will be on the wrong side of the MMAP or COMM events.
> 
> For example this results in the samples being associated with
> the perf binary, rather than the target of the record:
> 
>      perf record -e cs_etm/@tmc_etr0/u top
>      perf inject -i perf.data -o perf.inject --itrace=i100il
>      perf report -i perf.inject
> 
> Where 'Command' == perf should show as 'top':
> 
>      # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>      # ........  .......  ....................  ......................  ......................  ..................
>      #
>          31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
> 
> If the perf.data file is opened directly with perf, without the
> inject step, then this already works correctly because the
> events are synthesised after the COMM and MMAP events and
> no second sorting happens. Re-sorting only happens when opening
> the perf.inject file for the second time so timestamps are
> needed.
> 
> Using the timestamp from the AUX record mirrors the current
> behaviour when opening directly with perf, because the events
> are generated on the call to cs_etm__process_queues().

I would add the following here to clarify the situation :

"The ETM trace could optionally contain time stamps, but there is
no way to correlate this with the kernel time. So, the best available
time value is that of the AUX_RECORD header. This patch uses
the timestamp from the header for all the samples. The ordering of the
samples are implicit in the trace and thus is fine with respect to
relative ordering."


> 
> Signed-off-by: James Clark <james.clark at arm.com>
> Co-developed-by: Al Grant <al.grant at arm.com>
> Signed-off-by: Al Grant <al.grant at arm.com>

nit: The preferred order is your S-o-B at the end (i.e of the sender)

> ---
>   tools/perf/util/cs-etm.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index c25da2ffa8f3..d0fa9dce47f1 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>   	u8 sample_instructions;
>   
>   	int num_cpu;
> +	u64 latest_kernel_timestamp;
>   	u32 auxtrace_type;
>   	u64 branches_sample_type;
>   	u64 branches_id;
> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>   	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>   	event->sample.header.size = sizeof(struct perf_event_header);
>   
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>   	sample.ip = addr;
>   	sample.pid = tidq->pid;
>   	sample.tid = tidq->tid;
> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>   	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>   	event->sample.header.size = sizeof(struct perf_event_header);
>   
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>   	sample.ip = ip;
>   	sample.pid = tidq->pid;
>   	sample.tid = tidq->tid;
> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>   	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>   		return cs_etm__process_switch_cpu_wide(etm, event);
>   
> -	if (!etm->timeless_decoding &&
> -	    event->header.type == PERF_RECORD_AUX)

Might want to add a comment here ,

	/*
	 * Record the latest kernel timestamp available in the header
	 * for samples.
	 */

> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
>   		return cs_etm__process_queues(etm);
> +	}
>   
>   	return 0;
>   }
> 

This is the best effort thing we could do to get things working.

With the comments addressed:

Acked-by: Suzuki K Poulos <suzuki.poulose at arm.com>


From david at redhat.com  Wed Apr 14 16:58:26 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 14 Apr 2021 17:58:26 +0200
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
 <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
Message-ID: <9c0956f0-494e-5c6b-bdc2-d4213afd5e2f@redhat.com>

On 08.04.21 07:14, Anshuman Khandual wrote:
> 
> On 4/7/21 10:56 PM, Mike Rapoport wrote:
>> From: Mike Rapoport <rppt at linux.ibm.com>
>>
>> The intended semantics of pfn_valid() is to verify whether there is a
>> struct page for the pfn in question and nothing else.
> 
> Should there be a comment affirming this semantics interpretation, above the
> generic pfn_valid() in include/linux/mmzone.h ?
> 
>>
>> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
>> linear map vs those that require ioremap() to access them.
>>
>> Introduce a dedicated pfn_is_memory() to perform such check and use it
>> where appropriate.
>>
>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>> ---
>>   arch/arm64/include/asm/memory.h | 2 +-
>>   arch/arm64/include/asm/page.h   | 1 +
>>   arch/arm64/kvm/mmu.c            | 2 +-
>>   arch/arm64/mm/init.c            | 6 ++++++
>>   arch/arm64/mm/ioremap.c         | 4 ++--
>>   arch/arm64/mm/mmu.c             | 2 +-
>>   6 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 0aabc3be9a75..7e77fdf71b9d 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>   
>>   #define virt_addr_valid(addr)	({					\
>>   	__typeof__(addr) __addr = __tag_reset(addr);			\
>> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
>> +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
>>   })
>>   
>>   void dump_mem_limit(void);
>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>> index 012cffc574e8..32b485bcc6ff 100644
>> --- a/arch/arm64/include/asm/page.h
>> +++ b/arch/arm64/include/asm/page.h
>> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>>   typedef struct page *pgtable_t;
>>   
>>   extern int pfn_valid(unsigned long);
>> +extern int pfn_is_memory(unsigned long);
>>   
>>   #include <asm/memory.h>
>>   
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 8711894db8c2..ad2ea65a3937 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>>   
>>   static bool kvm_is_device_pfn(unsigned long pfn)
>>   {
>> -	return !pfn_valid(pfn);
>> +	return !pfn_is_memory(pfn);
>>   }
>>   
>>   /*
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 3685e12aba9b..258b1905ed4a 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
>>   }
>>   EXPORT_SYMBOL(pfn_valid);
>>   
>> +int pfn_is_memory(unsigned long pfn)
>> +{
>> +	return memblock_is_map_memory(PFN_PHYS(pfn));
>> +}
>> +EXPORT_SYMBOL(pfn_is_memory);> +
> 
> Should not this be generic though ? There is nothing platform or arm64
> specific in here. Wondering as pfn_is_memory() just indicates that the
> pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
> instead ? Regardless, it's fine either way.

TBH, I dislike (generic) pfn_is_memory(). It feels like we're mixing 
concepts. NOMAP memory vs !NOMAP memory; even NOMAP is some kind of 
memory after all. pfn_is_map_memory() would be more expressive, although 
still sub-optimal.

We'd actually want some kind of arm64-specific pfn_is_system_memory() or 
the inverse pfn_is_device_memory() -- to be improved.

-- 
Thanks,

David / dhildenb



From liam.howlett at oracle.com  Wed Apr 14 17:30:11 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Wed, 14 Apr 2021 16:30:11 +0000
Subject: [PATCH] arch/arm64/kernel/traps: Use find_vma_intersection() in
 traps for setting si_code
In-Reply-To: <20210413180030.GA31164@arm.com>
References: <20210407150940.542103-1-Liam.Howlett@Oracle.com>
 <20210412174343.GG2060@arm.com> <20210413143035.7zrct6a3up42uaoo@revolver>
 <20210413180030.GA31164@arm.com>
Message-ID: <20210414163006.jh2kccbliktnt3x4@revolver>

* Catalin Marinas <catalin.marinas at arm.com> [210413 14:00]:
> On Tue, Apr 13, 2021 at 04:52:34PM +0000, Liam Howlett wrote:
> > * Catalin Marinas <catalin.marinas at arm.com> [210412 13:44]:
> > > On Wed, Apr 07, 2021 at 03:11:06PM +0000, Liam Howlett wrote:
> > > > find_vma() will continue to search upwards until the end of the virtual
> > > > memory space.  This means the si_code would almost never be set to
> > > > SEGV_MAPERR even when the address falls outside of any VMA.  The result
> > > > is that the si_code is not reliable as it may or may not be set to the
> > > > correct result, depending on where the address falls in the address
> > > > space.
> > > > 
> > > > Using find_vma_intersection() allows for what is intended by only
> > > > returning a VMA if it falls within the range provided, in this case a
> > > > window of 1.
> > > > 
> > > > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > > > ---
> > > >  arch/arm64/kernel/traps.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > > > index a05d34f0e82a..a44007904a64 100644
> > > > --- a/arch/arm64/kernel/traps.c
> > > > +++ b/arch/arm64/kernel/traps.c
> > > > @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
> > > >  void arm64_notify_segfault(unsigned long addr)
> > > >  {
> > > >  	int code;
> > > > +	unsigned long ut_addr = untagged_addr(addr);
> > > >  
> > > >  	mmap_read_lock(current->mm);
> > > > -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> > > > +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
> > > >  		code = SEGV_MAPERR;
> > > >  	else
> > > >  		code = SEGV_ACCERR;
> [...]
> > > I don't think your change is entirely correct either. We can have a
> > > fault below the vma of a stack (with VM_GROWSDOWN) and
> > > find_vma_intersection() would return NULL but it should be a SEGV_ACCERR
> > > instead.
> > 
> > I'm pretty sure I am missing something.  From what you said above, I
> > think this means that there can be a user cache fault below the stack
> > which should notify the user application that they are not allowed to
> > expand the stack by sending a SIGV_ACCERR in the si_code?  Is this
> > expected behaviour or am I missing a code path to this function?
> 
> My point was that find_vma() may return a valid vma where addr < vm_end
> but also addr < vm_addr. It's the responsibility of the caller to check
> that that vma can be expanded (VM_GROWSDOWN) and we do something like
> this in __do_page_fault(). find_vma_intersection(), OTOH, requires addr
> >= vm_start.

Right.  The find_vma() interface is not clear by the function name;
returning a VMA that doesn't include the address of interest is unclear.
I think this is why we ended up with the bug in the first place.

> 
> If we hit this case (addr < vm_start), normally we'd first need to check
> whether it's expandable and, if not, return MAPERR. If it's expandable,
> it should be ACCERR since something else caused the fault.
> 
> Now, I think at least for user_cache_maint_handler(), we can assume that
> __do_page_fault() handled any expansion already, so we don't need to
> check it here. In this case, your find_vma_intersection() check should
> work.
> 
> Are there other cases where we invoke arm64_notify_segfault() without a
> prior fault? I think in swp_handler() we can bail out early before we
> even attempted the access so we may report MAPERR but ACCERR is a better
> indication.

swp_handler() is also buggy.  It is currently getting the ACCERR as long
as the address being checked is > mm->highest_vm_end.  If access_ok()
fails, it should return ACCERR and not search VMAs for the address at
all.

...

>Also in sys_rt_sigreturn() we always call it as
> arm64_notify_segfault(regs->sp). I'm not sure that's correct in all
> cases, see restore_altstack().

Ditto for sys_rt_sigreturn() and sys_sigreturn(), they both suffer the
same bug as swp_handler() outlined above.

In the case of restore_sigframe() or restore_altstack() failing, it
seems that the signal shouldn't be dependent on where the address falls
within the VMA at all.  Should the signal still be SIGSEGV or something
else?  By the comments, I would have thought SIGBUS, si_code of
BUS_ADRALN?

> 
> I guess this code needs some tidying up.

Indeed, there seems to be a few code paths that need to skip this
function all together and just set the code to ACCERR - especially since
the access_ok() just validates the number itself.

I don't think the right answer is to rewrite the function to check
VM_GROWSDOWN, as I cannot see a way to reach this function when trying
to expand the stack which should report back ACCERR.  Do you agree?

I also see that my fix would expose other bugs which need to be
addressed at the same time.

> 
> > > Maybe this should employ similar checks as __do_page_fault() (with
> > > expand_stack() and VM_GROWSDOWN).
> > 
> > You mean the code needs to detect endianness and to check if this is an
> > attempt to expand the stack for both cases?
> 
> Nothing to do with endianness, just the relation between the address and
> the vma->vm_start and whether the vma can be expanded down.

Okay, thanks for clarifying.


Cheers,
Liam

From llong at redhat.com  Wed Apr 14 17:41:58 2021
From: llong at redhat.com (Waiman Long)
Date: Wed, 14 Apr 2021 12:41:58 -0400
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
 <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
Message-ID: <4a9dbfa7-db68-a2dc-9018-a5b74f0f421c@redhat.com>

On 4/13/21 5:01 PM, Alex Kogan wrote:
> Hi, Andi.
>
> Thanks for your comments!
>
>> On Apr 13, 2021, at 2:03 AM, Andi Kleen <ak at linux.intel.com> wrote:
>>
>> Alex Kogan <alex.kogan at oracle.com> writes:
>>> +	numa_spinlock_threshold=	[NUMA, PV_OPS]
>>> +			Set the time threshold in milliseconds for the
>>> +			number of intra-node lock hand-offs before the
>>> +			NUMA-aware spinlock is forced to be passed to
>>> +			a thread on another NUMA node.	Valid values
>>> +			are in the [1..100] range. Smaller values result
>>> +			in a more fair, but less performant spinlock,
>>> +			and vice versa. The default value is 10.
>> ms granularity seems very coarse grained for this. Surely
>> at some point of spinning you can afford a ktime_get? But ok.
> We are reading time when we are at the head of the (main) queue, but
> don?t have the lock yet. Not sure about the latency of ktime_get(), but
> anything reasonably fast but not necessarily precise should work.
>
>> Could you turn that into a moduleparm which can be changed at runtime?
>> Would be strange to have to reboot just to play with this parameter
> Yes, good suggestion, thanks.
>
>> This would also make the code a lot shorter I guess.
> So you don?t think we need the command-line parameter, just the module_param?

The CNA code, if enabled, will be in vmlinux, not in a kernel module. As 
a result, I think a module parameter will be no different from a kernel 
command line parameter in this regard.

Cheers,
Longman




From will at kernel.org  Wed Apr 14 18:13:35 2021
From: will at kernel.org (Will Deacon)
Date: Wed, 14 Apr 2021 18:13:35 +0100
Subject: [GIT PULL] arm64: Fixes for -rc8
Message-ID: <20210414171334.GA25300@willie-the-truck>

Hi Linus,

Please pull these three arm64 fixes for -rc8; summary in the tag. We
don't have anything else on the horizon, although two of these issues
(the asm constraint and kprobes bugs) have been around for a while so
you never know.

Cheers,

Will

--->8

The following changes since commit 20109a859a9b514eb10c22b8a14b5704ffe93897:

  arm64: kernel: disable CNP on Carmel (2021-03-25 10:00:23 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to 738fa58ee1328481d1d7889e7c430b3401c571b9:

  arm64: kprobes: Restore local irqflag if kprobes is cancelled (2021-04-13 09:30:16 +0100)

----------------------------------------------------------------
arm64 fixes for -rc8

- Fix incorrect asm constraint for load_unaligned_zeropad() fixup

- Fix thread flag update when setting TIF_MTE_ASYNC_FAULT

- Fix restored irq state when handling fault on kprobe

----------------------------------------------------------------
Catalin Marinas (1):
      arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is set atomically

Jisheng Zhang (1):
      arm64: kprobes: Restore local irqflag if kprobes is cancelled

Peter Collingbourne (1):
      arm64: fix inline asm in load_unaligned_zeropad()

 arch/arm64/Kconfig                      |  6 +++++-
 arch/arm64/include/asm/word-at-a-time.h | 10 +++++-----
 arch/arm64/kernel/entry.S               | 10 ++++++----
 arch/arm64/kernel/probes/kprobes.c      |  6 ++++--
 4 files changed, 20 insertions(+), 12 deletions(-)


From ak at linux.intel.com  Wed Apr 14 18:26:02 2021
From: ak at linux.intel.com (Andi Kleen)
Date: Wed, 14 Apr 2021 10:26:02 -0700
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <4a9dbfa7-db68-a2dc-9018-a5b74f0f421c@redhat.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
 <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
 <4a9dbfa7-db68-a2dc-9018-a5b74f0f421c@redhat.com>
Message-ID: <20210414172602.GW3762101@tassilo.jf.intel.com>

> The CNA code, if enabled, will be in vmlinux, not in a kernel module. As a
> result, I think a module parameter will be no different from a kernel
> command line parameter in this regard.

You can still change it in /sys at runtime, even if it's in the vmlinux.

-Andi


From hsinyi at chromium.org  Wed Apr 14 18:29:10 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:10 +0800
Subject: [PATCH v19 0/6] add power control in i2c
Message-ID: <20210414172916.2689361-1-hsinyi@chromium.org>

Although in the most platforms, the power of eeprom
and i2c are alway on, some platforms disable the
eeprom and i2c power in order to meet low power request.

This patch add the pm_runtime ops to control power to
support all platforms.

Changes since v18:
 - Fix a function name conflict with drivers/gpu/drm/i915/selftests/i915_gem.c

Changes since v17:
 - Add a patch to fix unbalanced regulator disabling.
 - Add dts patch.

Changes since v16:
 - request regulator in device instead of in the core.
 - control regulator only if it's provided.

Changes since v15:
 - Squash the fix[1] for v15.
[1] https://patchwork.ozlabs.org/project/linux-i2c/patch/20200522101327.13456-1-m.szyprowski at samsung.com/

Changes since v14:
 - change the return value in normal condition
 - access the variable after NULL pointer checking
 - add ack tag

Changes since v13:
 - fixup some logic error

Changes since v12:
 - rebase onto v5.7-rc1
 - change the property description in binding

Changes since v11:
 - use suspend_late/resume_early instead of suspend/resume
 - rebase onto v5.6-rc1

Changes since v10:
 - fixup some worng codes

Changes since v9:
 - fixup build error
 - remove redundant code

Changes since v8:
 - fixup some wrong code
 - remove redundant message

        [... snip ...]

Bibby Hsieh (1):
  i2c: core: support bus regulator controlling in adapter

Hsin-Yi Wang (5):
  dt-binding: i2c: mt65xx: add vbus-supply property
  i2c: mediatek: mt65xx: add optional vbus-supply
  misc: eeprom: at24: check suspend status before disable regulator
  arm64: dts: mt8183: add supply name for eeprom
  drm/i915/selftests: Rename functions names

 .../devicetree/bindings/i2c/i2c-mt65xx.txt    |  1 +
 .../dts/mediatek/mt8183-kukui-kakadu.dtsi     |  4 +
 .../dts/mediatek/mt8183-kukui-kodama.dtsi     |  4 +
 .../boot/dts/mediatek/mt8183-kukui-krane.dtsi |  4 +
 drivers/gpu/drm/i915/selftests/i915_gem.c     | 10 +--
 drivers/i2c/busses/i2c-mt65xx.c               |  7 ++
 drivers/i2c/i2c-core-base.c                   | 88 +++++++++++++++++++
 drivers/misc/eeprom/at24.c                    |  6 +-
 include/linux/i2c.h                           |  2 +
 9 files changed, 119 insertions(+), 7 deletions(-)

-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:11 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:11 +0800
Subject: [PATCH v19 1/6] i2c: core: support bus regulator controlling in
 adapter
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-2-hsinyi@chromium.org>

From: Bibby Hsieh <bibby.hsieh at mediatek.com>

Although in the most platforms, the bus power of i2c
are alway on, some platforms disable the i2c bus power
in order to meet low power request.

We can control bulk regulator if it is provided in i2c
adapter device.

Signed-off-by: Bibby Hsieh <bibby.hsieh at mediatek.com>
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/i2c-core-base.c | 88 +++++++++++++++++++++++++++++++++++++
 include/linux/i2c.h         |  2 +
 2 files changed, 90 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 24c8f11bac73..c34920f30c5a 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -461,12 +461,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
 static int i2c_device_probe(struct device *dev)
 {
 	struct i2c_client	*client = i2c_verify_client(dev);
+	struct i2c_adapter	*adap;
 	struct i2c_driver	*driver;
 	int status;
 
 	if (!client)
 		return 0;
 
+	adap = client->adapter;
 	client->irq = client->init_irq;
 
 	if (!client->irq) {
@@ -532,6 +534,14 @@ static int i2c_device_probe(struct device *dev)
 
 	dev_dbg(dev, "probe\n");
 
+	if (adap->bus_regulator) {
+		status = regulator_enable(adap->bus_regulator);
+		if (status < 0) {
+			dev_err(&adap->dev, "Failed to enable bus regulator\n");
+			goto err_clear_wakeup_irq;
+		}
+	}
+
 	status = of_clk_set_defaults(dev->of_node, false);
 	if (status < 0)
 		goto err_clear_wakeup_irq;
@@ -589,8 +599,10 @@ static int i2c_device_probe(struct device *dev)
 static int i2c_device_remove(struct device *dev)
 {
 	struct i2c_client	*client = to_i2c_client(dev);
+	struct i2c_adapter      *adap;
 	struct i2c_driver	*driver;
 
+	adap = client->adapter;
 	driver = to_i2c_driver(dev->driver);
 	if (driver->remove) {
 		int status;
@@ -605,6 +617,8 @@ static int i2c_device_remove(struct device *dev)
 	devres_release_group(&client->dev, client->devres_group_id);
 
 	dev_pm_domain_detach(&client->dev, true);
+	if (!pm_runtime_status_suspended(&client->dev) && adap->bus_regulator)
+		regulator_disable(adap->bus_regulator);
 
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
@@ -617,6 +631,79 @@ static int i2c_device_remove(struct device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int i2c_resume_early(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	if (!pm_runtime_status_suspended(&client->dev)) {
+		err = regulator_enable(client->adapter->bus_regulator);
+		if (err)
+			return err;
+	}
+
+	return pm_generic_resume_early(&client->dev);
+}
+
+static int i2c_suspend_late(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_suspend_late(&client->dev);
+	if (err)
+		return err;
+
+	if (!pm_runtime_status_suspended(&client->dev))
+		return regulator_disable(client->adapter->bus_regulator);
+
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_PM
+static int i2c_runtime_resume(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = regulator_enable(client->adapter->bus_regulator);
+	if (err)
+		return err;
+	return pm_generic_runtime_resume(&client->dev);
+}
+
+static int i2c_runtime_suspend(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_runtime_suspend(&client->dev);
+	if (err)
+		return err;
+
+	return regulator_disable(client->adapter->bus_regulator);
+}
+#endif
+
+static const struct dev_pm_ops i2c_device_pm = {
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
+	SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
+};
+
 static void i2c_device_shutdown(struct device *dev)
 {
 	struct i2c_client *client = i2c_verify_client(dev);
@@ -674,6 +761,7 @@ struct bus_type i2c_bus_type = {
 	.probe		= i2c_device_probe,
 	.remove		= i2c_device_remove,
 	.shutdown	= i2c_device_shutdown,
+	.pm		= &i2c_device_pm,
 };
 EXPORT_SYMBOL_GPL(i2c_bus_type);
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e8f2ac8c9c3d..953a4eecb88f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -15,6 +15,7 @@
 #include <linux/device.h>	/* for struct device */
 #include <linux/sched.h>	/* for completion */
 #include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
 #include <linux/rtmutex.h>
 #include <linux/irqdomain.h>		/* for Host Notify IRQ */
 #include <linux/of.h>		/* for struct device_node */
@@ -729,6 +730,7 @@ struct i2c_adapter {
 	const struct i2c_adapter_quirks *quirks;
 
 	struct irq_domain *host_notify_domain;
+	struct regulator *bus_regulator;
 };
 #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:12 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:12 +0800
Subject: [PATCH v19 2/6] dt-binding: i2c: mt65xx: add vbus-supply property
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-3-hsinyi@chromium.org>

Add vbus-supply property for mt65xx. The regulator can be passed into
core and turned off during suspend/sleep to reduce power consumption.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
index 7f0194fdd0cc..2c45647e9f0b 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
@@ -32,6 +32,7 @@ Optional properties:
   - mediatek,have-pmic: platform can control i2c form special pmic side.
     Only mt6589 and mt8135 support this feature.
   - mediatek,use-push-pull: IO config use push-pull mode.
+  - vbus-supply: phandle to the regulator that provides power to SCL/SDA.
 
 Example:
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:13 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:13 +0800
Subject: [PATCH v19 3/6] i2c: mediatek: mt65xx: add optional vbus-supply
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-4-hsinyi@chromium.org>

Add vbus-supply which provides power to SCL/SDA. Pass this regulator
into core so it can be turned on/off for low power mode support.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/busses/i2c-mt65xx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ffd2f354d0a..82f2b6716005 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1215,6 +1215,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 	i2c->adap.quirks = i2c->dev_comp->quirks;
 	i2c->adap.timeout = 2 * HZ;
 	i2c->adap.retries = 1;
+	i2c->adap.bus_regulator = devm_regulator_get_optional(&pdev->dev, "vbus");
+	if (IS_ERR(i2c->adap.bus_regulator)) {
+		if (PTR_ERR(i2c->adap.bus_regulator) == -ENODEV)
+			i2c->adap.bus_regulator = NULL;
+		else
+			return PTR_ERR(i2c->adap.bus_regulator);
+	}
 
 	ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
 	if (ret)
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:14 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:14 +0800
Subject: [PATCH v19 4/6] misc: eeprom: at24: check suspend status before
 disable regulator
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-5-hsinyi@chromium.org>

cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
regulator in runtime suspend. If runtime suspend is called before
regulator disable, it will results in regulator unbalanced disabling.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/misc/eeprom/at24.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 926408b41270..7a6f01ace78a 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client *client)
 	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
 	if (IS_ERR(at24->nvmem)) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return PTR_ERR(at24->nvmem);
 	}
 
@@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client *client)
 	err = at24_read(at24, 0, &test_byte, 1);
 	if (err) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return -ENODEV;
 	}
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:15 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:15 +0800
Subject: [PATCH v19 5/6] arm64: dts: mt8183: add supply name for eeprom
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-6-hsinyi@chromium.org>

Add supplies for eeprom for mt8183 boards.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi  | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
index b442e38a3156..28966a65391b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
@@ -88,11 +88,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -101,11 +103,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
index 2f5234a16ead..3aa79403c0c2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
@@ -62,11 +62,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c64";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcamio_reg>;
 	};
 };
 
@@ -75,11 +77,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c64";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
index fbc471ccf805..30c183c96a54 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
@@ -71,11 +71,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -84,11 +86,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Wed Apr 14 18:29:16 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 01:29:16 +0800
Subject: [PATCH v19 6/6] drm/i915/selftests: Rename functions names
In-Reply-To: <20210414172916.2689361-1-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
Message-ID: <20210414172916.2689361-7-hsinyi@chromium.org>

pm_resume and pm_suspend might be conflict with the ones defined in
include/linux/suspend.h. Rename pm_resume{suspend} to
i915_pm_resume{suspend} since they are only used here.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reported-by: kernel test robot <lkp at intel.com>
---
 drivers/gpu/drm/i915/selftests/i915_gem.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
index dc394fb7ccfa..525afda9d31f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -94,7 +94,7 @@ static int pm_prepare(struct drm_i915_private *i915)
 	return 0;
 }
 
-static void pm_suspend(struct drm_i915_private *i915)
+static void i915_pm_suspend(struct drm_i915_private *i915)
 {
 	intel_wakeref_t wakeref;
 
@@ -116,7 +116,7 @@ static void pm_hibernate(struct drm_i915_private *i915)
 	}
 }
 
-static void pm_resume(struct drm_i915_private *i915)
+static void i915_pm_resume(struct drm_i915_private *i915)
 {
 	intel_wakeref_t wakeref;
 
@@ -152,12 +152,12 @@ static int igt_gem_suspend(void *arg)
 	if (err)
 		goto out;
 
-	pm_suspend(i915);
+	i915_pm_suspend(i915);
 
 	/* Here be dragons! Note that with S3RST any S3 may become S4! */
 	simulate_hibernate(i915);
 
-	pm_resume(i915);
+	i915_pm_resume(i915);
 
 	err = switch_to_context(ctx);
 out:
@@ -192,7 +192,7 @@ static int igt_gem_hibernate(void *arg)
 	/* Here be dragons! */
 	simulate_hibernate(i915);
 
-	pm_resume(i915);
+	i915_pm_resume(i915);
 
 	err = switch_to_context(ctx);
 out:
-- 
2.31.1.295.g9ea45b61b8-goog



From llong at redhat.com  Wed Apr 14 18:31:17 2021
From: llong at redhat.com (Waiman Long)
Date: Wed, 14 Apr 2021 13:31:17 -0400
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <20210414172602.GW3762101@tassilo.jf.intel.com>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <87mtu2vhzz.fsf@linux.intel.com>
 <CA1141EF-76A8-47A9-97B9-3CB2FC246B1A@oracle.com>
 <4a9dbfa7-db68-a2dc-9018-a5b74f0f421c@redhat.com>
 <20210414172602.GW3762101@tassilo.jf.intel.com>
Message-ID: <6c968acd-dda2-ed1f-6582-b7811030761e@redhat.com>

On 4/14/21 1:26 PM, Andi Kleen wrote:
>> The CNA code, if enabled, will be in vmlinux, not in a kernel module. As a
>> result, I think a module parameter will be no different from a kernel
>> command line parameter in this regard.
> You can still change it in /sys at runtime, even if it's in the vmlinux.

I see, thank for the clarification.

Cheers,
Longman



From samitolvanen at google.com  Wed Apr 14 18:46:49 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Wed, 14 Apr 2021 10:46:49 -0700
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn, endif}
In-Reply-To: <20210414000803.662534-1-nathan@kernel.org>
References: <20210414000803.662534-1-nathan@kernel.org>
Message-ID: <CABCJKueJjOguo7-PUR1yhZm4sX4F7t-7ZMcjU8pAMBQyv6Pmnw@mail.gmail.com>

Hi Nathan,

On Tue, Apr 13, 2021 at 5:09 PM Nathan Chancellor <nathan at kernel.org> wrote:
>
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
>
> <instantiation>:5:7: error: expected assembly-time absolute expression
>  .org . - (664b-663b) + (662b-661b)
>       ^
> <instantiation>:6:7: error: expected assembly-time absolute expression
>  .org . - (662b-661b) + (664b-663b)
>       ^
>
> The root cause is LLVM's assembler has a one-pass design, meaning it
> cannot figure out these instruction lengths when the .org directive is
> outside of the subsection that they are in, which was changed by the
> .arch_extension directive added in the above commit.
>
> Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
> length validation inside the subsection") to the alternative_endif
> macro, shuffling the .org directives so that the length validation
> happen will always happen in the same subsections. alternative_insn has
> not shown any issue yet but it appears that it could have the same issue
> in the future so just preemptively change it.
>
> Cc: stable at vger.kernel.org
> Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1347
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>
> ---
>
> Apologies if my explanation or terminology is off, I am only now getting
> more familiar with assembly.
>
>  arch/arm64/include/asm/alternative-macros.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/alternative-macros.h b/arch/arm64/include/asm/alternative-macros.h
> index 5df500dcc627..8a078fc662ac 100644
> --- a/arch/arm64/include/asm/alternative-macros.h
> +++ b/arch/arm64/include/asm/alternative-macros.h
> @@ -97,9 +97,9 @@
>         .popsection
>         .subsection 1
>  663:   \insn2
> -664:   .previous
> -       .org    . - (664b-663b) + (662b-661b)
> +664:   .org    . - (664b-663b) + (662b-661b)
>         .org    . - (662b-661b) + (664b-663b)
> +       .previous
>         .endif
>  .endm
>
> @@ -169,11 +169,11 @@
>   */
>  .macro alternative_endif
>  664:
> +       .org    . - (664b-663b) + (662b-661b)
> +       .org    . - (662b-661b) + (664b-663b)
>         .if .Lasm_alt_mode==0
>         .previous
>         .endif
> -       .org    . - (664b-663b) + (662b-661b)
> -       .org    . - (662b-661b) + (664b-663b)
>  .endm
>
>  /*

Thank you for fixing these!

The patch looks correct to me, next-20210413 builds with LLVM_IAS=1
after I applied it, and defconfig built with both Clang and gcc boots
normally. Please feel free to add:

Reviewed-by: Sami Tolvanen <samitolvanen at google.com>
Tested-by: Sami Tolvanen <samitolvanen at google.com>

Sami


From pr-tracker-bot at kernel.org  Wed Apr 14 19:02:53 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Wed, 14 Apr 2021 18:02:53 +0000
Subject: [GIT PULL] arm64: Fixes for -rc8
In-Reply-To: <20210414171334.GA25300@willie-the-truck>
References: <20210414171334.GA25300@willie-the-truck>
Message-ID: <161842337327.19533.11791869407185736160.pr-tracker-bot@kernel.org>

The pull request you sent on Wed, 14 Apr 2021 18:13:35 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec97a7296ad1ca3ccb8bca1e72739cb8262686f1

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From geert at linux-m68k.org  Wed Apr 14 19:06:18 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 14 Apr 2021 20:06:18 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
Message-ID: <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>

Hi Yicong,

On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > about this driver when configuring a kernel without Hisilicon platform
> > or ACPI firmware support.
>
> this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> not sure all the platform this IP on has ARCH_HISI configured. The driver
> will not be compiled by default config. This is not correct to have
> this dependence.

Thanks for your answer!

I guess it's still fine to add a dependency on ACPI?

Thanks again!

> > Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> > ---
> >  drivers/i2c/busses/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
> >
> >  config I2C_HISI
> >       tristate "HiSilicon I2C controller"
> > -     depends on ARM64 || COMPILE_TEST
> > +     depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
> >       help
> >         Say Y here if you want to have Hisilicon I2C controller support
> >         available on the Kunpeng Server.
\
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 andriy.shevchenko at linux.intel.com  Wed Apr 14 19:18:33 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 14 Apr 2021 21:18:33 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
Message-ID: <YHcx+QPbkTA0bv9V@smile.fi.intel.com>

On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > about this driver when configuring a kernel without Hisilicon platform
> > > or ACPI firmware support.
> >
> > this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> > not sure all the platform this IP on has ARCH_HISI configured. The driver
> > will not be compiled by default config. This is not correct to have
> > this dependence.
> 
> Thanks for your answer!
> 
> I guess it's still fine to add a dependency on ACPI?

But why?

-- 
With Best Regards,
Andy Shevchenko




From alex.kogan at oracle.com  Wed Apr 14 19:18:05 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Wed, 14 Apr 2021 14:18:05 -0400
Subject: [External] : Re: [PATCH v14 6/6] locking/qspinlock: Introduce the
 shuffle reduction optimization into CNA
In-Reply-To: <YHad9S5ckj5IR1l6@suselix>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-7-alex.kogan@oracle.com> <YHad9S5ckj5IR1l6@suselix>
Message-ID: <96EB342A-1343-4D71-B687-6EED27159161@oracle.com>

Hi, Andreas.

Thanks for the great questions.

> On Apr 14, 2021, at 3:47 AM, Andreas Herrmann <aherrmann at suse.com> wrote:
> 
> On Thu, Apr 01, 2021 at 11:31:56AM -0400, Alex Kogan wrote:
>> This performance optimization chooses probabilistically to avoid moving
>> threads from the main queue into the secondary one when the secondary queue
>> is empty.
>> 
>> It is helpful when the lock is only lightly contended. In particular, it
>> makes CNA less eager to create a secondary queue, but does not introduce
>> any extra delays for threads waiting in that queue once it is created.
>> 
>> Signed-off-by: Alex Kogan <alex.kogan at oracle.com>
>> Reviewed-by: Steve Sistare <steven.sistare at oracle.com>
>> Reviewed-by: Waiman Long <longman at redhat.com>
>> ---
>> kernel/locking/qspinlock_cna.h | 39 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>> 
>> diff --git a/kernel/locking/qspinlock_cna.h b/kernel/locking/qspinlock_cna.h
>> index 29c3abbd3d94..983c6a47a221 100644
>> --- a/kernel/locking/qspinlock_cna.h
>> +++ b/kernel/locking/qspinlock_cna.h
>> @@ -5,6 +5,7 @@
>> 
>> #include <linux/topology.h>
>> #include <linux/sched/rt.h>
>> +#include <linux/random.h>
>> 
>> /*
>>  * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware lock).
>> @@ -86,6 +87,34 @@ static inline bool intra_node_threshold_reached(struct cna_node *cn)
>> 	return current_time - threshold > 0;
>> }
>> 
>> +/*
>> + * Controls the probability for enabling the ordering of the main queue
>> + * when the secondary queue is empty. The chosen value reduces the amount
>> + * of unnecessary shuffling of threads between the two waiting queues
>> + * when the contention is low, while responding fast enough and enabling
>> + * the shuffling when the contention is high.
>> + */
>> +#define SHUFFLE_REDUCTION_PROB_ARG  (7)
> 
> Out of curiosity:
> 
> Have you used other values and done measurements what's an efficient
> value for SHUFFLE_REDUCTION_PROB_ARG?
Yes, we did try other values. Small variations do not change the results much,
but if you bump the value significantly (e.g., 20), you end up with a lock that
hardly does any shuffling and thus performs on-par with the (MCS-based)
baseline.

> Maybe I miscalculated it, but if I understand it correctly this value
> implies that the propability is 0.9921875 that below function returns
> true.
Your analysis is correct. Intuitively, we tried to keep the probability around 1-2%,
so if we do decide to shuffle when we don?t really want to (i.e., when the
contention is low), the overall overhead of such wrong decisions would be small.

> 
> My question is probably answered by following statement from
> referenced paper:
> 
> "In our experiments with the shuffle reduction optimization enabled,
> we set THRESHOLD2 to 0xff." (page with figure 5)
Yeah, just to avoid any confusion ? we used a different mechanism to draw
pseudo-random numbers in the paper, so that 0xff number is not directly 
comparable to the range of possible values for SHUFFLE_REDUCTION_PROB_ARG,
but the idea was exactly the same.

> 
>> +
>> +/* Per-CPU pseudo-random number seed */
>> +static DEFINE_PER_CPU(u32, seed);
>> +
>> +/*
>> + * Return false with probability 1 / 2^@num_bits.
>> + * Intuitively, the larger @num_bits the less likely false is to be returned.
>> + * @num_bits must be a number between 0 and 31.
>> + */
>> +static bool probably(unsigned int num_bits)
>> +{
>> +	u32 s;
>> +
>> +	s = this_cpu_read(seed);
>> +	s = next_pseudo_random32(s);
>> +	this_cpu_write(seed, s);
>> +
>> +	return s & ((1 << num_bits) - 1);
>> +}
>> +
>> static void __init cna_init_nodes_per_cpu(unsigned int cpu)
>> {
>> 	struct mcs_spinlock *base = per_cpu_ptr(&qnodes[0].mcs, cpu);
>> @@ -293,6 +322,16 @@ static __always_inline u32 cna_wait_head_or_lock(struct qspinlock *lock,
>> {
>> 	struct cna_node *cn = (struct cna_node *)node;
>> 
>> +	if (node->locked <= 1 && probably(SHUFFLE_REDUCTION_PROB_ARG)) {
> 
> Again if I understand it correctly with SHUFFLE_REDUCTION_PROB_ARG==7
> it's roughly 1 out of 100 cases where probably() returns false.
> 
> Why/when is this beneficial?
> 
> I assume it has to do with following statement in the referenced
> paper:
> 
> "The superior performance over MCS at 4 threads is the result of the
> shuffling that does take place once in a while, organizing threads?
> arrivals to the lock in a way that reduces the inter-socket lock
> migration without the need to continuously modify the main queue. ..."
> (page with figure 9; the paper has no page numbers)
This is correct. This performance optimization deals with a small regression
that might occur at the low-medium range of contention. And just to reiterate
what the patch comment says, this optimization has nothing to do with correctness
and does not introduce any extra delays for threads already waiting in the
secondary queue.

> 
> But OTHO why this pseudo randomness?
> 
> How about deterministically treating every 100th execution differently
> (it also matches "once in a while") and thus entirely removing the
> pseudo randomness?
Pseudo-randomness helps to avoid pathological cases where we would do the
same decision, despite having this optimization in place, for every lock acquisition.

Consider an application in which each thread cycles through X locks, e.g., X=10.
If we count deterministically, then for the first 9 locks we will _always avoid doing
any shuffling, missing on any opportunity for the benefit derived by the CNA 
approach. At the same time, for lock #10 we will always attempt to shuffle, and so
the optimization would not have any effect. 

> 
> Have you tried this? If so why was it worse than pseudo randomness?
> 
> (Or maybe I missed something and pseudo randomness is required for
> other reasons there.)

Hope this helps ? let me know if you have any further questions!

Best,
? Alex

From michael.weiser at gmx.de  Wed Apr 14 19:35:03 2021
From: michael.weiser at gmx.de (Michael Weiser)
Date: Wed, 14 Apr 2021 20:35:03 +0200
Subject: [PATCH v2] arm64: dts: allwinner: Revert SD card CD GPIO for
 Pine64-LTS
In-Reply-To: <20210414104740.31497-1-andre.przywara@arm.com>
References: <20210414104740.31497-1-andre.przywara@arm.com>
Message-ID: <YHc11xC1vT1Yr+a1@weiser.dinsnail.net>

Hi Andre,

On Wed, Apr 14, 2021 at 11:47:40AM +0100, Andre Przywara wrote:

> Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
> SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
> along the way with the Pine64-LTS, which share the same base .dtsi.

> This was based on the observation that the Pine64-LTS has as "push-push"
> SD card socket, and that the schematic mentions the card detect GPIO.

> After having received two reports about failing SD card access with that
> patch, some more research and polls on that subject revealed that there
> are at least two different versions of the Pine64-LTS out there:
> - On some boards (including mine) the card detect pin is "stuck" at
>   high, regardless of an microSD card being inserted or not.
> - On other boards the card-detect is working, but is active-high, by
>   virtue of an explicit inverter circuit, as shown in the schematic.

> To cover all versions of the board out there, and don't take any chances,
> let's revert the introduction of the active-low CD GPIO, but let's use
> the broken-cd property for the Pine64-LTS this time. That should avoid
> regressions and should work for everyone, even allowing SD card changes
> now.
> The SOPine card detect has proven to be working, so let's keep that
> GPIO in place.

I can confirm that this change works on my Pine64 LTS boards (with
working high-active card detect) when applied to today's linux-next (which
already includes your previous change to change the card detect GPIO
from low- to high-active in sun50i-a64-sopine.dtsi).

> Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
> Reported-by: Michael Weiser <michael.weiser at gmx.de>
> Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
> Suggested-by: Chen-Yu Tsai <wens at csie.org>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Tested-by: Michael Weiser <michael.weiser at gmx.de>

Thanks!
Michael

> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> index e79ce49e7e6a..596a25907432 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> @@ -21,5 +21,5 @@
>  };

>  &mmc0 {
> -	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> +	broken-cd;		/* card detect is broken on *some* boards */
>  };

-- 
tschoe, Michael
Eisregen


From geert at linux-m68k.org  Wed Apr 14 19:55:21 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 14 Apr 2021 20:55:21 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
Message-ID: <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>

Hi Andy,

On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> > > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > about this driver when configuring a kernel without Hisilicon platform
> > > > or ACPI firmware support.
> > >
> > > this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> > > not sure all the platform this IP on has ARCH_HISI configured. The driver
> > > will not be compiled by default config. This is not correct to have
> > > this dependence.
> >
> > Thanks for your answer!
> >
> > I guess it's still fine to add a dependency on ACPI?
>
> But why?

Please tell me how/when the driver is used when CONFIG_ACPI=n.
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 asutoshd at codeaurora.org  Wed Apr 14 19:58:26 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Wed, 14 Apr 2021 11:58:26 -0700
Subject: [PATCH v18 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1618426513.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v17 -> v18:
- Addressed Adrian's comments

v16 -> v17:
- Addressed Adrian's & Daejun's comments

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing


Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  24 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 692 +++++++++++++++++++++++++------------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 561 insertions(+), 268 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Wed Apr 14 19:58:27 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Wed, 14 Apr 2021 11:58:27 -0700
Subject: [PATCH v18 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1618426513.git.asutoshd@codeaurora.org>
References: <cover.1618426513.git.asutoshd@codeaurora.org>
Message-ID: <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 692 +++++++++++++++++++++++++------------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 549 insertions(+), 256 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..b9105e4 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..4e1ff20 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..49a918c 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..d463b44 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..39bf204 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			ufshcd_rpm_put_sync(hba);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..0a58c9a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4098,12 +4112,13 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	}
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
-	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+	if (update &&
+	    !pm_runtime_suspended(&hba->sdev_ufs_device->sdev_gendev)) {
+		ufshcd_rpm_get_sync(hba);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		ufshcd_rpm_put_sync(hba);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4816,40 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			ufshcd_rpm_put(hba);
+			return;
+		}
+	} else {
+		/* device wlun is probed */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4880,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4913,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5035,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5636,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
+	ufshcd_rpm_put_sync(hba);
 }
 
 /**
@@ -5604,7 +5654,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5670,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5794,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	ufshcd_rpm_get_sync(hba);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5836,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	ufshcd_rpm_put(hba);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5857,18 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
+
+	/* hba device might have a runtime error otherwise */
+	if (ret)
+		ret = pm_runtime_set_active(hba->dev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7292,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7455,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7935,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8521,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8697,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8705,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8728,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto vops_suspend;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8750,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8778,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8791,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
+vops_suspend:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8800,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8824,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
-
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8858,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,42 +8906,214 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
-	if (ufshcd_is_clkscaling_supported(hba))
-		ufshcd_clk_scaling_suspend(hba, false);
-
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
+	if (hba->clk_scaling.is_allowed)
+		ufshcd_resume_clkscaling(hba);
 
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	down(&hba->host_sem);
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret) {
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+		up(&hba->host_sem);
+	} else {
+		hba->is_sys_suspended = true;
+	}
+
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+out:
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+	if (!ret)
+		hba->is_sys_suspended = false;
+	up(&hba->host_sem);
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	ufshcd_rpm_get_sync(hba);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static int ufshcd_suspend(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
-	ufshcd_setup_clocks(hba, false);
+	ret = ufshcd_setup_clocks(hba, false);
+	if (ret) {
+		ufshcd_enable_irq(hba);
+		return ret;
+	}
 	if (ufshcd_is_clkgating_allowed(hba)) {
 		hba->clk_gating.state = CLKS_OFF;
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	return ret;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
-	hba->pm_op_in_progress = 0;
 	if (ret)
 		ufshcd_update_evt_hist(hba, UFS_EVT_RESUME_ERR, (u32)ret);
 	return ret;
@@ -8962,49 +9124,23 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_system_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	down(&hba->host_sem);
-
-	if (!hba->is_powered)
-		return 0;
-
-	if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
-	     hba->curr_dev_pwr_mode) &&
-	    (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-	     hba->uic_link_state) &&
-	     !hba->dev_info.b_rpm_dev_flush_capable)
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ret = ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = true;
-	else
-		up(&hba->host_sem);
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_suspend);
@@ -9018,24 +9154,19 @@ EXPORT_SYMBOL(ufshcd_system_suspend);
 
 int ufshcd_system_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+
+	ret = ufshcd_resume(hba);
+
 out:
 	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
-	up(&hba->host_sem);
+
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
@@ -9045,19 +9176,17 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_suspend(hba);
+
 	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9069,33 +9198,19 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_resume(hba);
+
 	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9113,30 +9228,20 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
-	if (!hba->is_powered)
-		goto out;
-
 	if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
 		goto out;
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9255,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		ufshcd_rpm_get_sync(hba);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9560,176 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	ufshcd_rpm_put(hba);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * Force it to honor system-suspend.
+	 * Refer ufshcd_resume_complete()
+	 */
+	ufshcd_rpm_get_sync(hba);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba = shost_priv(sdev->host);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
-	return 0;
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret)
+		goto debugfs_exit;
+
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret)
+		goto unregister;
+
+	return ret;
+unregister:
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+debugfs_exit:
+	ufs_debugfs_exit();
+	return ret;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..3a8dc0d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
@@ -1309,4 +1315,19 @@ static inline int ufshcd_update_ee_usr_mask(struct ufs_hba *hba,
 					&hba->ee_drv_mask, set, clr);
 }
 
+static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_put_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+}
+
 #endif /* End of Header */
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From geert at linux-m68k.org  Wed Apr 14 20:09:50 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 14 Apr 2021 21:09:50 +0200
Subject: [PATCH 4/5] sh: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-5-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-5-maz@kernel.org>
Message-ID: <CAMuHMdVfwRv_66mMz79rvszdgXnovrS_FZzPRK9fqOMH5Npu5A@mail.gmail.com>

On Wed, Apr 14, 2021 at 3:53 PM Marc Zyngier <maz at kernel.org> wrote:
> perf_pmu_name() and perf_num_counters() are unused. Drop them.
>
> Signed-off-by: Marc Zyngier <maz at kernel.org>

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 brouer at redhat.com  Wed Apr 14 20:13:22 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Wed, 14 Apr 2021 21:13:22 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414115052.GS2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
Message-ID: <20210414211322.3799afd4@carbon>

On Wed, 14 Apr 2021 12:50:52 +0100
Matthew Wilcox <willy at infradead.org> wrote:

> > That said, I think we need to have a quicker fix for the immediate
> > issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
> > it leaves[3] in struct page.  In[3] you mention ppc32, does it only
> > happens on certain 32-bit archs?  
> 
> AFAICT it happens on mips32, ppc32, arm32 and arc.  It doesn't happen
> on x86-32 because dma_addr_t is 32-bit aligned.

(If others want to reproduce).  First I could not reproduce on ARM32.
Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.

Details below signature.
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

From file: arch/arm/Kconfig

config XEN
	bool "Xen guest support on ARM"
	depends on ARM && AEABI && OF
	depends on CPU_V7 && !CPU_V6
	depends on !GENERIC_ATOMIC64
	depends on MMU
	select ARCH_DMA_ADDR_T_64BIT
	select ARM_PSCI
	select SWIOTLB
	select SWIOTLB_XEN
	select PARAVIRT
	help
	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.

My make compile command:

 export VERSION=gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf/
 export CROSS_COMPILE="/home/${USER}/cross-compilers/${VERSION}/bin/arm-none-linux-gnueabihf-"
 make -j8 ARCH=arm CROSS_COMPILE=$CROSS_COMPILE

Pahole output:
 $ pahole -C page mm/page_alloc.o

 struct page {
        long unsigned int          flags;                /*     0     4 */

        /* XXX 4 bytes hole, try to pack */

        union {
                struct {
                        struct list_head lru;            /*     8     8 */
                        struct address_space * mapping;  /*    16     4 */
                        long unsigned int index;         /*    20     4 */
                        long unsigned int private;       /*    24     4 */
                };                                       /*     8    20 */
                struct {
                        dma_addr_t dma_addr;             /*     8     8 */
                };                                       /*     8     8 */
                struct {
                        union {
                                struct list_head slab_list; /*     8     8 */
                                struct {
                                        struct page * next; /*     8     4 */
                                        short int pages; /*    12     2 */
                                        short int pobjects; /*    14     2 */
                                };                       /*     8     8 */
                        };                               /*     8     8 */
                        struct kmem_cache * slab_cache;  /*    16     4 */
                        void *     freelist;             /*    20     4 */
                        union {
                                void * s_mem;            /*    24     4 */
                                long unsigned int counters; /*    24     4 */
                                struct {
                                        unsigned int inuse:16; /*    24: 0  4 */
                                        unsigned int objects:15; /*    24:16  4 */
                                        unsigned int frozen:1; /*    24:31  4 */
                                };                       /*    24     4 */
                        };                               /*    24     4 */
                };                                       /*     8    20 */
                struct {
                        long unsigned int compound_head; /*     8     4 */
                        unsigned char compound_dtor;     /*    12     1 */
                        unsigned char compound_order;    /*    13     1 */

                        /* XXX 2 bytes hole, try to pack */

                        atomic_t   compound_mapcount;    /*    16     4 */
                        unsigned int compound_nr;        /*    20     4 */
                };                                       /*     8    16 */
                struct {
                        long unsigned int _compound_pad_1; /*     8     4 */
                        atomic_t   hpage_pinned_refcount; /*    12     4 */
                        struct list_head deferred_list;  /*    16     8 */
                };                                       /*     8    16 */
                struct {
                        long unsigned int _pt_pad_1;     /*     8     4 */
                        pgtable_t  pmd_huge_pte;         /*    12     4 */
                        long unsigned int _pt_pad_2;     /*    16     4 */
                        union {
                                struct mm_struct * pt_mm; /*    20     4 */
                                atomic_t pt_frag_refcount; /*    20     4 */
                        };                               /*    20     4 */
                        spinlock_t ptl;                  /*    24     4 */
                };                                       /*     8    20 */
                struct {
                        struct dev_pagemap * pgmap;      /*     8     4 */
                        void *     zone_device_data;     /*    12     4 */
                };                                       /*     8     8 */
                struct callback_head callback_head __attribute__((__aligned__(4))); /*     8     8 */
        } __attribute__((__aligned__(8)));               /*     8    24 */
        union {
                atomic_t           _mapcount;            /*    32     4 */
                unsigned int       page_type;            /*    32     4 */
                unsigned int       active;               /*    32     4 */
                int                units;                /*    32     4 */
        };                                               /*    32     4 */
        atomic_t                   _refcount;            /*    36     4 */

        /* size: 40, cachelines: 1, members: 4 */
        /* sum members: 36, holes: 1, sum holes: 4 */
        /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
        /* last cacheline: 40 bytes */
} __attribute__((__aligned__(8)));





From andriy.shevchenko at linux.intel.com  Wed Apr 14 20:14:04 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Wed, 14 Apr 2021 22:14:04 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
Message-ID: <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>

On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> > > > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > > about this driver when configuring a kernel without Hisilicon platform
> > > > > or ACPI firmware support.
> > > >
> > > > this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> > > > not sure all the platform this IP on has ARCH_HISI configured. The driver
> > > > will not be compiled by default config. This is not correct to have
> > > > this dependence.
> > >
> > > Thanks for your answer!
> > >
> > > I guess it's still fine to add a dependency on ACPI?
> >
> > But why?
> 
> Please tell me how/when the driver is used when CONFIG_ACPI=n.

I'm not using it at all. Ask the author :-)

But if we follow your logic, then we need to mark all the _platform_ drivers
for x86 world as ACPI dependent? This sounds ugly.

So, if you are going to send a such patch, NAK here from me.
Same here. NAK.

-- 
With Best Regards,
Andy Shevchenko




From mike.leach at linaro.org  Wed Apr 14 20:18:53 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:53 +0100
Subject: [PATCH v7 00/10] CoreSight configuration management; ETM strobing
Message-ID: <20210414191903.18349-1-mike.leach@linaro.org>

This patchset introduces initial concepts in CoreSight system
configuration management support. to allow more detailed and complex
programming to be applied to CoreSight systems during trace capture.

Configurations consist of 2 elements:-
1) Features - programming combinations for devices, applied to a class of
device on the system (all ETMv4), or individual devices.
2) Configurations - a set of programmed features used when the named
configuration is selected.

Features and configurations are declared as a data table, a set of register,
resource and parameter requirements. Features and configurations are loaded
into the system by the virtual cs_syscfg device. This then matches features
to any registered devices and loads the feature into them.

Individual device classes that support feature and configuration register
with cs_syscfg.

Once loaded a configuration can be enabled for a specific trace run.
Configurations are registered with the perf cs_etm event as entries in
cs_etm/events. These can be selected on the perf command line as follows:-

perf record -e cs_etm/<config_name>/ ...

This patch set has one pre-loaded configuration and feature.
A named "strobing" feature is provided for ETMv4.
A named "autofdo" configuration is provided. This configuration enables
strobing on any ETM in used.

Thus the command:
perf record -e cs_etm/autofdo/ ...

will trace the supplied application while enabling the "autofdo" configuation
on each ETM as it is enabled by perf. This in turn will enable strobing for
the ETM - with default parameters. Parameters can be adjusted using configfs.

The sink used in the trace run will be automatically selected.

A configuration can supply up to 15 of preset parameter values, which will
subsitute in parameter values for any feature used in the configuration.

Selection of preset values as follows
perf record -e cs_etm/autofdo,preset=1/ ...

(valid presets 1-N, where N is the number supplied in the configuration, not
exceeding 15. preset=0 is the same as not selecting a preset.)

Applies to & tested against coresight/next-ETE-TRBE (5.12-rc3 base)

Changes since v6:
Fixed kernel test robot issues-
Reported-by: kernel test robot <lkp at intel.com>

Changes since v5:

1) Fix code style issues from auto-build reports, as
Reported-by: kernel test robot <lkp at intel.com>
2) Update comments to get consistent docs for API functions.
3) remove unused #define from autofdo example.
4) fix perf code style issues from patch 4 (Mathieu)
5) fix configfs code style issues from patch 9. (Mathieu)

Changes since v4: (based on comments from Matthieu and Suzuki).
No large functional changes - primarily code improvements and naming schema.
1) Updated entire set to ensure a consistent naming scheme was used for
variables and struct members that refer to the key objects in the system.
Suffixes _desc used for all references to feature and configuraion descriptors,
suffix _csdev used for all references to load feature and configs in the csdev
instances. (Mathieu & Suzuki).
2) Dropped the 'configurations' sub dir in cs_etm perf directories as superfluous
with the configfs containing the same information. (Mathieu).
3) Simplified perf handling code (suzuki)
4) Multiple simplifications and improvements for code readability (Matthieu
and Suzuki)

Changes since v3: (Primarily based on comments from Matthieu)
1) Locking mechanisms simplified.
2) Removed the possibility to enable features independently from
configurations.Only configurations can be enabled now. Simplifies programming
logic.
3) Configuration now uses an activate->enable mechanism. This means that perf
will activate a selected configuration at the start of a session (during
setup_aux), and disable at the end of a session (around free_aux)
The active configuration and associated features will be programmed into the
CoreSight device instances when they are enabled. This locks the configuration
into the system while in use. Parameters cannot be altered while this is
in place. This mechanism will be extended in future for dynamic load / unload
of configurations to prevent removal while in use.
4) Removed the custom bus / driver as un-necessary. A single device is
registered to own perf fs elements and configfs.
5) Various other minor issues addressed.

Changes since v2:
1) Added documentation file.
2) Altered cs_syscfg driver to no longer be coresight_device based, and moved
to its own custom bus to remove it from the main coresight bus. (Mathieu)
3) Added configfs support to inspect and control loaded configurations and
features. Allows listing of preset values (Yabin Cui)
4) Dropped sysfs support for adjusting feature parameters on the per device
basis, in favour of a single point adjustment in configfs that is pushed to all
device instances.
5) Altered how the config and preset command line options are handled in perf
and the drivers. (Mathieu and Suzuki).
6) Fixes for various issues and technical points (Mathieu, Yabin)

Changes since v1:
1) Moved preloaded configurations and features out of individual drivers.
2) Added cs_syscfg driver to manage configurations and features. Individual
drivers register with cs_syscfg indicating support for config, and provide
matching information that the system uses to load features into the drivers.
This allows individual drivers to be updated on an as needed basis - and
removes the need to consider devices that cannot benefit from configuration -
static replicators, funnels, tpiu.
3) Added perf selection of configuarations.
4) Rebased onto the coresight module loading set. 

To follow in future revisions / sets:-
a) load of additional config and features by loadable module.
b) load of additional config and features by configfs
c) enhanced resource management for ETMv4 and checking features have sufficient
resources to be enabled.
d) ECT and CTI support for configuration and features.

Mike Leach (10):
  coresight: syscfg: Initial coresight system configuration
  coresight: syscfg: Add registration and feature loading for cs devices
  coresight: config: Add configuration and feature generic functions
  coresight: etm-perf: update to handle configuration selection
  coresight: syscfg: Add API to activate and enable configurations
  coresight: etm-perf: Update to activate selected configuration
  coresight: etm4x: Add complex configuration handlers to etmv4
  coresight: config: Add preloaded configurations
  coresight: syscfg: Add initial configfs support
  Documentation: coresight: Add documentation for CoreSight config

 .../trace/coresight/coresight-config.rst      | 244 ++++++
 Documentation/trace/coresight/coresight.rst   |  16 +
 drivers/hwtracing/coresight/Makefile          |   7 +-
 .../hwtracing/coresight/coresight-cfg-afdo.c  | 153 ++++
 .../coresight/coresight-cfg-preload.c         |  31 +
 .../coresight/coresight-cfg-preload.h         |  13 +
 .../hwtracing/coresight/coresight-config.c    | 275 ++++++
 .../hwtracing/coresight/coresight-config.h    | 253 ++++++
 drivers/hwtracing/coresight/coresight-core.c  |  12 +-
 .../hwtracing/coresight/coresight-etm-perf.c  | 150 +++-
 .../hwtracing/coresight/coresight-etm-perf.h  |  12 +-
 .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  30 +
 .../coresight/coresight-etm4x-core.c          |  38 +-
 .../coresight/coresight-etm4x-sysfs.c         |   3 +
 .../coresight/coresight-syscfg-configfs.c     | 396 +++++++++
 .../coresight/coresight-syscfg-configfs.h     |  45 +
 .../hwtracing/coresight/coresight-syscfg.c    | 804 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |  81 ++
 include/linux/coresight.h                     |   7 +
 20 files changed, 2716 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/trace/coresight/coresight-config.rst
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h
 create mode 100644 drivers/hwtracing/coresight/coresight-config.c
 create mode 100644 drivers/hwtracing/coresight/coresight-config.h
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h

-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:54 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:54 +0100
Subject: [PATCH v7 01/10] coresight: syscfg: Initial coresight system
 configuration
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-2-mike.leach@linaro.org>

Creates an system management API to allow complex configurations and
features to be programmed into a CoreSight infrastructure.

A feature is defined as a programming set for a device or class of
devices.

A configuration is a set of features across the system that are enabled
for a trace session.

The API will manage system wide configuration, and allow complex
programmed features to be added to individual device instances, and
provide for system wide configuration selection on trace capture
operations.

This patch creates the initial data object and the initial API for
loading configurations and features.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-config.h    | 142 +++++++++++++
 drivers/hwtracing/coresight/coresight-core.c  |  12 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |   2 +-
 .../hwtracing/coresight/coresight-etm-perf.h  |   2 +-
 .../hwtracing/coresight/coresight-syscfg.c    | 199 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |  46 ++++
 7 files changed, 401 insertions(+), 4 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-config.h
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index d60816509755..3d037f17aade 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o
+		coresight-sysfs.o coresight-syscfg.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
new file mode 100644
index 000000000000..21aa7464dcdc
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -0,0 +1,142 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#ifndef _CORESIGHT_CORESIGHT_CONFIG_H
+#define _CORESIGHT_CORESIGHT_CONFIG_H
+
+#include <linux/coresight.h>
+#include <linux/types.h>
+
+/* CoreSight Configuration Management - component and system wide configuration */
+
+/*
+ * Register type flags for register value descriptor:
+ * describe how the value is interpreted, and handled.
+ */
+#define CS_CFG_REG_TYPE_STD		0x80	/* reg is standard reg */
+#define CS_CFG_REG_TYPE_RESOURCE	0x40	/* reg is a resource */
+#define CS_CFG_REG_TYPE_VAL_PARAM	0x08	/* reg value uses param */
+#define CS_CFG_REG_TYPE_VAL_MASK	0x04	/* reg value bit masked */
+#define CS_CFG_REG_TYPE_VAL_64BIT	0x02	/* reg value 64 bit */
+#define CS_CFG_REG_TYPE_VAL_SAVE	0x01	/* reg value save on disable */
+
+/*
+ * flags defining what device class a feature will match to when processing a
+ * system configuration - used by config data and devices.
+ */
+#define CS_CFG_MATCH_CLASS_SRC_ALL	0x0001	/* match any source */
+#define CS_CFG_MATCH_CLASS_SRC_ETM4	0x0002	/* match any ETMv4 device */
+
+/* flags defining device instance matching - used in config match desc data. */
+#define CS_CFG_MATCH_INST_ANY		0x80000000 /* any instance of a class */
+
+/*
+ * Limit number of presets in a configuration
+ * This is related to the number of bits (4) we use to select the preset on
+ * the perf command line. Preset 0 is always none selected.
+ * See PMU_FORMAT_ATTR(preset, "config:0-3") in coresight-etm-perf.c
+ */
+#define CS_CFG_CONFIG_PRESET_MAX 15
+
+/**
+ * Parameter descriptor for a device feature.
+ *
+ * @name:  Name of parameter.
+ * @value: Initial or default value.
+ */
+struct cscfg_parameter_desc {
+	const char *name;
+	u64 value;
+};
+
+/**
+ * Representation of register value and a descriptor of register usage.
+ *
+ * Used as a descriptor in the feature descriptors.
+ * Used as a value in when in a feature loading into a csdev.
+ *
+ * Supports full 64 bit register value, or 32 bit value with optional mask
+ * value.
+ *
+ * @type:	define register usage and interpretation.
+ * @offset:	the address offset for register in the hardware device (per device specification).
+ * @hw_info:	optional hardware device type specific information. (ETM / CTI specific etc)
+ * @val64:	64 bit value.
+ * @val32:	32 bit value.
+ * @mask32:	32 bit mask when using 32 bit value to access device register - if mask type.
+ * @param_idx:	parameter index value into parameter array if param type.
+ */
+struct cscfg_regval_desc {
+	struct {
+		u32 type:8;
+		u32 offset:12;
+		u32 hw_info:12;
+	};
+	union {
+		u64 val64;
+		struct {
+			u32 val32;
+			u32 mask32;
+		};
+		u32 param_idx;
+	};
+};
+
+/**
+ * Device feature descriptor - combination of registers and parameters to
+ * program a device to implement a specific complex function.
+ *
+ * @name:	 feature name.
+ * @description: brief description of the feature.
+ * @item:	 List entry.
+ * @match_flags: matching information if loading into a device
+ * @nr_params:   number of parameters used.
+ * @params_desc: array of parameters used.
+ * @nr_regs:	 number of registers used.
+ * @regs_desc:	 array of registers used.
+ */
+struct cscfg_feature_desc {
+	const char *name;
+	const char *description;
+	struct list_head item;
+	u32 match_flags;
+	int nr_params;
+	struct cscfg_parameter_desc *params_desc;
+	int nr_regs;
+	struct cscfg_regval_desc *regs_desc;
+};
+
+/**
+ * Configuration descriptor - describes selectable system configuration.
+ *
+ * A configuration describes device features in use, and may provide preset
+ * values for the parameters in those features.
+ *
+ * A single set of presets is the sum of the parameters declared by
+ * all the features in use - this value is @nr_total_params.
+ *
+ * @name:		name of the configuration - used for selection.
+ * @description:	description of the purpose of the configuration.
+ * @item:		list entry.
+ * @nr_feat_refs:	Number of features used in this configuration.
+ * @feat_ref_names:	references to features used in this configuration.
+ * @nr_presets:		Number of sets of presets supplied by this configuration.
+ * @nr_total_params:	Sum of all parameters declared by used features
+ * @presets:		Array of preset values.
+ *
+ */
+struct cscfg_config_desc {
+	const char *name;
+	const char *description;
+	struct list_head item;
+	int nr_feat_refs;
+	const char **feat_ref_names;
+	int nr_presets;
+	int nr_total_params;
+	const u64 *presets; /* nr_presets * nr_total_params */
+};
+
+#endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index ca75b0b54e1f..868785983c79 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -21,6 +21,7 @@
 
 #include "coresight-etm-perf.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static DEFINE_MUTEX(coresight_mutex);
 static DEFINE_PER_CPU(struct coresight_device *, csdev_sink);
@@ -1764,13 +1765,22 @@ static int __init coresight_init(void)
 
 	ret = etm_perf_init();
 	if (ret)
-		bus_unregister(&coresight_bustype);
+		goto exit_bus_unregister;
 
+	/* initialise the coresight syscfg API */
+	ret = cscfg_init();
+	if (!ret)
+		return 0;
+
+	etm_perf_exit();
+exit_bus_unregister:
+	bus_unregister(&coresight_bustype);
 	return ret;
 }
 
 static void __exit coresight_exit(void)
 {
+	cscfg_exit();
 	etm_perf_exit();
 	bus_unregister(&coresight_bustype);
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f123c26b9f54..15310c72f89f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -748,7 +748,7 @@ int __init etm_perf_init(void)
 	return ret;
 }
 
-void __exit etm_perf_exit(void)
+void etm_perf_exit(void)
 {
 	perf_pmu_unregister(&etm_pmu);
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 3e4f2ad5e193..29d90dfeba31 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -83,6 +83,6 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 #endif /* CONFIG_CORESIGHT */
 
 int __init etm_perf_init(void);
-void __exit etm_perf_exit(void);
+void etm_perf_exit(void);
 
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
new file mode 100644
index 000000000000..417db3f92c2f
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/platform_device.h>
+
+#include "coresight-config.h"
+#include "coresight-syscfg.h"
+
+/*
+ * cscfg_ API manages configurations and features for the entire coresight
+ * infrastructure.
+ *
+ * It allows the loading of configurations and features, and loads these into
+ * coresight devices as appropriate.
+ */
+
+/* protect the cscsg_data and device */
+static DEFINE_MUTEX(cscfg_mutex);
+
+/* only one of these */
+static struct cscfg_manager *cscfg_mgr;
+
+/* load features and configuations into the lists */
+
+/* check feature list for a named feature - call with mutex locked. */
+static bool cscfg_match_list_feat(const char *name)
+{
+	struct cscfg_feature_desc *feat_desc;
+
+	list_for_each_entry(feat_desc, &cscfg_mgr->feat_desc_list, item) {
+		if (strcmp(feat_desc->name, name) == 0)
+			return true;
+	}
+	return false;
+}
+
+/* check all feat needed for cfg are in the list - call with mutex locked. */
+static int cscfg_check_feat_for_cfg(struct cscfg_config_desc *config_desc)
+{
+	int i;
+
+	for (i = 0; i < config_desc->nr_feat_refs; i++)
+		if (!cscfg_match_list_feat(config_desc->feat_ref_names[i]))
+			return -EINVAL;
+	return 0;
+}
+
+/*
+ * load feature - add to feature list.
+ */
+static int cscfg_load_feat(struct cscfg_feature_desc *feat_desc)
+{
+	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
+
+	return 0;
+}
+
+/*
+ * load config into the system - validate used features exist then add to
+ * config list.
+ */
+static int cscfg_load_config(struct cscfg_config_desc *config_desc)
+{
+	int err;
+
+	/* validate features are present */
+	err = cscfg_check_feat_for_cfg(config_desc);
+	if (err)
+		return err;
+
+	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
+	return 0;
+}
+
+/**
+ * cscfg_load_config_sets - API function to load feature and config sets.
+ *
+ * Take a 0 terminated array of feature descriptors and/or configuration
+ * descriptors and load into the system.
+ * Features are loaded first to ensure configuration dependencies can be met.
+ *
+ * @config_descs: 0 terminated array of configuration descriptors.
+ * @feat_descs:   0 terminated array of feature descriptors.
+ */
+int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
+			   struct cscfg_feature_desc **feat_descs)
+{
+	int err, i = 0;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* load features first */
+	if (feat_descs) {
+		while (feat_descs[i]) {
+			err = cscfg_load_feat(feat_descs[i]);
+			if (err) {
+				pr_err("coresight-syscfg: Failed to load feature %s\n",
+				       feat_descs[i]->name);
+				goto exit_unlock;
+			}
+			i++;
+		}
+	}
+
+	/* next any configurations to check feature dependencies */
+	i = 0;
+	if (config_descs) {
+		while (config_descs[i]) {
+			err = cscfg_load_config(config_descs[i]);
+			if (err) {
+				pr_err("coresight-syscfg: Failed to load configuration %s\n",
+				       config_descs[i]->name);
+				goto exit_unlock;
+			}
+			i++;
+		}
+	}
+
+exit_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_load_config_sets);
+
+/* Initialise system configuration management device. */
+
+struct device *cscfg_device(void)
+{
+	return cscfg_mgr ? &cscfg_mgr->dev : NULL;
+}
+
+/* Must have a release function or the kernel will complain on module unload */
+static void cscfg_dev_release(struct device *dev)
+{
+	kfree(cscfg_mgr);
+	cscfg_mgr = NULL;
+}
+
+/* a device is needed to "own" some kernel elements such as sysfs entries.  */
+static int cscfg_create_device(void)
+{
+	struct device *dev;
+	int err = -ENOMEM;
+
+	mutex_lock(&cscfg_mutex);
+	if (cscfg_mgr) {
+		err = -EINVAL;
+		goto create_dev_exit_unlock;
+	}
+
+	cscfg_mgr = kzalloc(sizeof(struct cscfg_manager), GFP_KERNEL);
+	if (!cscfg_mgr)
+		goto create_dev_exit_unlock;
+
+	/* setup the device */
+	dev = cscfg_device();
+	dev->release = cscfg_dev_release;
+	dev->init_name = "cs_system_cfg";
+
+	err = device_register(dev);
+	if (err)
+		cscfg_dev_release(dev);
+
+create_dev_exit_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+
+static void cscfg_clear_device(void)
+{
+	mutex_lock(&cscfg_mutex);
+	device_unregister(cscfg_device());
+	mutex_unlock(&cscfg_mutex);
+}
+
+/* Initialise system config management API device  */
+int __init cscfg_init(void)
+{
+	int err = 0;
+
+	err = cscfg_create_device();
+	if (err)
+		return err;
+
+	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
+	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
+	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
+
+	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
+	return 0;
+}
+
+void cscfg_exit(void)
+{
+	cscfg_clear_device();
+}
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
new file mode 100644
index 000000000000..18be9b58cd0b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Coresight system configuration driver.
+ */
+
+#ifndef CORESIGHT_SYSCFG_H
+#define CORESIGHT_SYSCFG_H
+
+#include <linux/coresight.h>
+#include <linux/device.h>
+
+#include "coresight-config.h"
+
+/**
+ * System configuration manager device.
+ *
+ * Contains lists of the loaded configurations and features, plus a list of CoreSight devices
+ * registered with the system as supporting configuration management.
+ *
+ * Need a device to 'own' some coresight system wide sysfs entries in
+ * perf events, configfs etc.
+ *
+ * @dev:		The device.
+ * @csdev_desc_list:	List of coresight devices registered with the configuration manager.
+ * @feat_desc_list:	List of feature descriptors to load into registered devices.
+ * @config_desc_list:	List of system configuration descriptors to load into registered devices.
+ */
+struct cscfg_manager {
+	struct device dev;
+	struct list_head csdev_desc_list;
+	struct list_head feat_desc_list;
+	struct list_head config_desc_list;
+};
+
+/* get reference to dev in cscfg_manager */
+struct device *cscfg_device(void);
+
+/* internal core operations for cscfg */
+int __init cscfg_init(void);
+void cscfg_exit(void);
+
+/* syscfg manager external API */
+int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
+			   struct cscfg_feature_desc **feat_descs);
+
+#endif /* CORESIGHT_SYSCFG_H */
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:56 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:56 +0100
Subject: [PATCH v7 03/10] coresight: config: Add configuration and feature
 generic functions
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-4-mike.leach@linaro.org>

Adds a set of generic support functions that allow devices to set and save
features values on the device, and enable and disable configurations.

Additional functions for other common operations including feature
reset.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-config.c    | 275 ++++++++++++++++++
 .../hwtracing/coresight/coresight-config.h    |   9 +
 .../hwtracing/coresight/coresight-syscfg.c    |   3 +-
 4 files changed, 287 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-config.c

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 3d037f17aade..63ecfc3cf66d 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o coresight-syscfg.o
+		coresight-sysfs.o coresight-syscfg.o coresight-config.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-config.c b/drivers/hwtracing/coresight/coresight-config.c
new file mode 100644
index 000000000000..3c501e027bc0
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-config.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/sysfs.h>
+#include "coresight-config.h"
+#include "coresight-priv.h"
+
+/*
+ * This provides a set of generic functions that operate on configurations
+ * and features to manage the handling of parameters, the programming and
+ * saving of registers used by features on devices.
+ */
+
+/*
+ * Write the value held in the register structure into the driver internal memory
+ * location.
+ */
+static void cscfg_set_reg(struct cscfg_regval_csdev *reg_csdev)
+{
+	u32 *p_val32 = (u32 *)reg_csdev->driver_regval;
+	u32 tmp32 = reg_csdev->reg_desc.val32;
+
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT) {
+		*((u64 *)reg_csdev->driver_regval) = reg_csdev->reg_desc.val64;
+		return;
+	}
+
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_MASK) {
+		tmp32 = *p_val32;
+		tmp32 &= ~reg_csdev->reg_desc.mask32;
+		tmp32 |= reg_csdev->reg_desc.val32 & reg_csdev->reg_desc.mask32;
+	}
+	*p_val32 = tmp32;
+}
+
+/*
+ * Read the driver value into the reg if this is marked as one we want to save.
+ */
+static void cscfg_save_reg(struct cscfg_regval_csdev *reg_csdev)
+{
+	if (!(reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_SAVE))
+		return;
+	if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT)
+		reg_csdev->reg_desc.val64 = *(u64 *)(reg_csdev->driver_regval);
+	else
+		reg_csdev->reg_desc.val32 = *(u32 *)(reg_csdev->driver_regval);
+}
+
+/*
+ * Some register values are set from parameters. Initialise these registers
+ * from the current parameter values.
+ */
+static void cscfg_init_reg_param(struct cscfg_feature_csdev *feat_csdev,
+				 struct cscfg_regval_desc *reg_desc,
+				 struct cscfg_regval_csdev *reg_csdev)
+{
+	struct cscfg_parameter_csdev *param_csdev;
+
+	/* for param, load routines have validated the index */
+	param_csdev = &feat_csdev->params_csdev[reg_desc->param_idx];
+	param_csdev->reg_csdev = reg_csdev;
+	param_csdev->val64 = reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT;
+
+	if (param_csdev->val64)
+		reg_csdev->reg_desc.val64 = param_csdev->current_value;
+	else
+		reg_csdev->reg_desc.val32 = (u32)param_csdev->current_value;
+}
+
+/* set values into the driver locations referenced in cscfg_reg_csdev */
+static int cscfg_set_on_enable(struct cscfg_feature_csdev *feat_csdev)
+{
+	int i;
+
+	spin_lock(feat_csdev->drv_spinlock);
+	for (i = 0; i < feat_csdev->nr_regs; i++)
+		cscfg_set_reg(&feat_csdev->regs_csdev[i]);
+	spin_unlock(feat_csdev->drv_spinlock);
+	dev_dbg(&feat_csdev->csdev->dev, "Feature %s: %s",
+		feat_csdev->feat_desc->name, "set on enable");
+	return 0;
+}
+
+/* copy back values from the driver locations referenced in cscfg_reg_csdev */
+static void cscfg_save_on_disable(struct cscfg_feature_csdev *feat_csdev)
+{
+	int i;
+
+	spin_lock(feat_csdev->drv_spinlock);
+	for (i = 0; i < feat_csdev->nr_regs; i++)
+		cscfg_save_reg(&feat_csdev->regs_csdev[i]);
+	spin_unlock(feat_csdev->drv_spinlock);
+	dev_dbg(&feat_csdev->csdev->dev, "Feature %s: %s",
+		feat_csdev->feat_desc->name, "save on disable");
+}
+
+/* default reset - restore default values */
+void cscfg_reset_feat(struct cscfg_feature_csdev *feat_csdev)
+{
+	struct cscfg_regval_desc *reg_desc;
+	struct cscfg_regval_csdev *reg_csdev;
+	int i;
+
+	/*
+	 * set the default values for all parameters and regs from the
+	 * relevant static descriptors.
+	 */
+	for (i = 0; i < feat_csdev->nr_params; i++)
+		feat_csdev->params_csdev[i].current_value =
+			feat_csdev->feat_desc->params_desc[i].value;
+
+	for (i = 0; i < feat_csdev->nr_regs; i++) {
+		reg_desc = &feat_csdev->feat_desc->regs_desc[i];
+		reg_csdev = &feat_csdev->regs_csdev[i];
+		reg_csdev->reg_desc.type = reg_desc->type;
+
+		/* check if reg set from a parameter otherwise desc default */
+		if (reg_desc->type & CS_CFG_REG_TYPE_VAL_PARAM)
+			cscfg_init_reg_param(feat_csdev, reg_desc, reg_csdev);
+		else
+			/*
+			 * for normal values the union between val64 & val32 + mask32
+			 * allows us to init using the 64 bit value
+			 */
+			reg_csdev->reg_desc.val64 = reg_desc->val64;
+	}
+}
+
+/*
+ * For the selected presets, we set the register associated with the parameter, to
+ * the value of the preset index associated with the parameter.
+ */
+static int cscfg_update_presets(struct cscfg_config_csdev *config_csdev, int preset)
+{
+	int i, j, val_idx = 0, nr_cfg_params;
+	struct cscfg_parameter_csdev *param_csdev;
+	struct cscfg_feature_csdev *feat_csdev;
+	const struct cscfg_config_desc *config_desc = config_csdev->config_desc;
+	const char *name;
+	const u64 *preset_base;
+	u64 val;
+
+	/* preset in range 1 to nr_presets */
+	if (preset < 1 || preset > config_desc->nr_presets)
+		return -EINVAL;
+	/*
+	 * Go through the array of features, assigning preset values to
+	 * feature parameters in the order they appear.
+	 * There should be precisely the same number of preset values as the
+	 * sum of number of parameters over all the features - but we will
+	 * ensure there is no overrun.
+	 */
+	nr_cfg_params = config_desc->nr_total_params;
+	preset_base = &config_desc->presets[(preset - 1) * nr_cfg_params];
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		if (!feat_csdev->nr_params)
+			continue;
+
+		for (j = 0; j < feat_csdev->nr_params; j++) {
+			param_csdev = &feat_csdev->params_csdev[j];
+			name = feat_csdev->feat_desc->params_desc[j].name;
+			val = preset_base[val_idx++];
+			if (param_csdev->val64) {
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%lld)", name, val);
+				param_csdev->reg_csdev->reg_desc.val64 = val;
+			} else {
+				param_csdev->reg_csdev->reg_desc.val32 = (u32)val;
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%d)", name, (u32)val);
+			}
+		}
+
+		/* exit early if all params filled */
+		if (val_idx >= nr_cfg_params)
+			break;
+	}
+	return 0;
+}
+
+/*
+ * if we are not using a preset, then need to update the feature params
+ * with current values. This sets the register associated with the parameter
+ * with the current value of that parameter.
+ */
+static int cscfg_update_curr_params(struct cscfg_config_csdev *config_csdev)
+{
+	int i, j;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_parameter_csdev *param_csdev;
+	const char *name;
+	u64 val;
+
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		if (!feat_csdev->nr_params)
+			continue;
+		for (j = 0; j < feat_csdev->nr_params; j++) {
+			param_csdev = &feat_csdev->params_csdev[j];
+			name = feat_csdev->feat_desc->params_desc[j].name;
+			val = param_csdev->current_value;
+			if (param_csdev->val64) {
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%lld)", name, val);
+				param_csdev->reg_csdev->reg_desc.val64 = val;
+			} else {
+				param_csdev->reg_csdev->reg_desc.val32 = (u32)val;
+				dev_dbg(&config_csdev->csdev->dev,
+					"set param %s (%d)", name, (u32)val);
+			}
+		}
+	}
+	return 0;
+}
+
+/*
+ * Configuration values will be programmed into the driver locations if enabling, or read
+ * from relevant locations on disable.
+ */
+static int cscfg_prog_config(struct cscfg_config_csdev *config_csdev, bool enable)
+{
+	int i, err = 0;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct coresight_device *csdev;
+
+	for (i = 0; i < config_csdev->nr_feat; i++) {
+		feat_csdev = config_csdev->feats_csdev[i];
+		csdev = feat_csdev->csdev;
+		dev_dbg(&csdev->dev, "cfg %s;  %s feature:%s", config_csdev->config_desc->name,
+			enable ? "enable" : "disable", feat_csdev->feat_desc->name);
+
+		if (enable)
+			err = cscfg_set_on_enable(feat_csdev);
+		else
+			cscfg_save_on_disable(feat_csdev);
+
+		if (err)
+			break;
+	}
+	return err;
+}
+
+/*
+ * Enable configuration for the device. Will result in the internal driver data
+ * being updated ready for programming into the device.
+ *
+ * @config_csdev:	config_csdev to set.
+ * @preset:		preset values to use - 0 for default.
+ */
+int cscfg_csdev_enable_config(struct cscfg_config_csdev *config_csdev, int preset)
+{
+	int err = 0;
+
+	if (preset)
+		err = cscfg_update_presets(config_csdev, preset);
+	else
+		err = cscfg_update_curr_params(config_csdev);
+	if (!err)
+		err = cscfg_prog_config(config_csdev, true);
+	if (!err)
+		config_csdev->enabled = true;
+	return err;
+}
+
+void cscfg_csdev_disable_config(struct cscfg_config_csdev *config_csdev)
+{
+	if (config_csdev->enabled) {
+		cscfg_prog_config(config_csdev, false);
+		config_csdev->enabled = false;
+	}
+}
diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 685fb46ce893..5a39cbbc38a4 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -237,4 +237,13 @@ struct cscfg_csdev_feat_ops {
 			 struct cscfg_feature_csdev *feat_csdev);
 };
 
+/* coresight config helper functions*/
+
+/* enable / disable config on a device - called with appropriate locks set.*/
+int cscfg_csdev_enable_config(struct cscfg_config_csdev *config_csdev, int preset);
+void cscfg_csdev_disable_config(struct cscfg_config_csdev *config_csdev);
+
+/* reset a feature to default values */
+void cscfg_reset_feat(struct cscfg_feature_csdev *feat_csdev);
+
 #endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index e93e62c1efbb..c7f48d6b48f5 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -190,9 +190,10 @@ static int cscfg_load_feat_csdev(struct coresight_device *csdev,
 	if (err)
 		return err;
 
-	/* add to internal csdev feature list */
+	/* add to internal csdev feature list & initialise using reset call */
 	mutex_lock(&cscfg_csdev_mutex);
 	list_add(&feat_csdev->node, &csdev->feature_csdev_list);
+	cscfg_reset_feat(feat_csdev);
 	mutex_unlock(&cscfg_csdev_mutex);
 
 	return 0;
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:55 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:55 +0100
Subject: [PATCH v7 02/10] coresight: syscfg: Add registration and feature
 loading for cs devices
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-3-mike.leach@linaro.org>

API for individual devices to register with the syscfg management
system is added.

Devices register with matching information, and any features or
configurations that match will be loaded into the device.

The feature and configuration loading is extended so that on load these
are loaded into any currently registered devices. This allows
configuration loading after devices have been registered.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |  98 +++++
 .../hwtracing/coresight/coresight-syscfg.c    | 338 +++++++++++++++++-
 .../hwtracing/coresight/coresight-syscfg.h    |  19 +
 include/linux/coresight.h                     |   5 +
 4 files changed, 459 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 21aa7464dcdc..685fb46ce893 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -139,4 +139,102 @@ struct cscfg_config_desc {
 	const u64 *presets; /* nr_presets * nr_total_params */
 };
 
+/**
+ * config register instance - part of a loaded feature.
+ *                            maps register values to csdev driver structures
+ *
+ * @reg_desc:		value to use when setting feature on device / store for
+ *			readback of volatile values.
+ * @driver_regval:	pointer to internal driver element used to set the value
+ *			in hardware.
+ */
+struct cscfg_regval_csdev {
+	struct cscfg_regval_desc reg_desc;
+	void *driver_regval;
+};
+
+/**
+ * config parameter instance - part of a loaded feature.
+ *
+ * @feat_csdev:		parent feature
+ * @reg_csdev:		register value updated by this parameter.
+ * @current_value:	current value of parameter - may be set by user via
+ *			sysfs, or modified during device operation.
+ * @val64:		true if 64 bit value
+ */
+struct cscfg_parameter_csdev {
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_regval_csdev *reg_csdev;
+	u64 current_value;
+	bool val64;
+};
+
+/**
+ * Feature instance loaded into a CoreSight device.
+ *
+ * When a feature is loaded into a specific device, then this structure holds
+ * the connections between the register / parameter values used and the
+ * internal data structures that are written when the feature is enabled.
+ *
+ * Since applying a feature modifies internal data structures in the device,
+ * then we have a reference to the device spinlock to protect access to these
+ * structures (@drv_spinlock).
+ *
+ * @feat_desc:		pointer to the static descriptor for this feature.
+ * @csdev:		parent CoreSight device instance.
+ * @node:		list entry into feature list for this device.
+ * @drv_spinlock:	device spinlock for access to driver register data.
+ * @nr_params:		number of parameters.
+ * @params_csdev:	current parameter values on this device
+ * @nr_regs:		number of registers to be programmed.
+ * @regs_csdev:		Programming details for the registers
+ */
+struct cscfg_feature_csdev {
+	const struct cscfg_feature_desc *feat_desc;
+	struct coresight_device *csdev;
+	struct list_head node;
+	spinlock_t *drv_spinlock;
+	int nr_params;
+	struct cscfg_parameter_csdev *params_csdev;
+	int nr_regs;
+	struct cscfg_regval_csdev *regs_csdev;
+};
+
+/**
+ * Configuration instance when loaded into a CoreSight device.
+ *
+ * The instance contains references to loaded features on this device that are
+ * used by the configuration.
+ *
+ * @config_desc:reference to the descriptor for this configuration
+ * @csdev:	parent coresight device for this configuration instance.
+ * @enabled:	true if configuration is enabled on this device.
+ * @node:	list entry within the coresight device
+ * @nr_feat:	Number of features on this device that are used in the
+ *		configuration.
+ * @feats_csdev:references to the device features to enable.
+ */
+struct cscfg_config_csdev {
+	const struct cscfg_config_desc *config_desc;
+	struct coresight_device *csdev;
+	bool enabled;
+	struct list_head node;
+	int nr_feat;
+	struct cscfg_feature_csdev *feats_csdev[0];
+};
+
+/**
+ * Coresight device operations.
+ *
+ * Registered coresight devices provide these operations to manage feature
+ * instances compatible with the device hardware and drivers
+ *
+ * @load_feat:	Pass a feature descriptor into the device and create the
+ *		loaded feature instance (struct cscfg_feature_csdev).
+ */
+struct cscfg_csdev_feat_ops {
+	int (*load_feat)(struct coresight_device *csdev,
+			 struct cscfg_feature_csdev *feat_csdev);
+};
+
 #endif /* _CORESIGHT_CORESIGHT_CONFIG_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 417db3f92c2f..e93e62c1efbb 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -25,6 +25,199 @@ static struct cscfg_manager *cscfg_mgr;
 
 /* load features and configuations into the lists */
 
+/* protect the cfg lists in the csdev instances */
+static DEFINE_MUTEX(cscfg_csdev_mutex);
+
+/* get name feature instance from a coresight device list of features */
+static struct cscfg_feature_csdev *
+cscfg_get_feat_csdev(struct coresight_device *csdev, const char *name)
+{
+	struct cscfg_feature_csdev *feat_csdev = NULL;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
+		if (strcmp(feat_csdev->feat_desc->name, name) == 0)
+			return feat_csdev;
+	}
+	return NULL;
+}
+
+/* allocate the device config instance - with max number of used features */
+static struct cscfg_config_csdev *
+cscfg_alloc_csdev_cfg(struct coresight_device *csdev, int nr_feats)
+{
+	struct cscfg_config_csdev *config_csdev = NULL;
+	struct device *dev = csdev->dev.parent;
+
+	/* this is being allocated using the devm for the coresight device */
+	config_csdev = devm_kzalloc(dev,
+				    offsetof(struct cscfg_config_csdev, feats_csdev[nr_feats]),
+				    GFP_KERNEL);
+	if (!config_csdev)
+		return NULL;
+
+	config_csdev->csdev = csdev;
+	return config_csdev;
+}
+
+/* Load a config into a device if there are any feature matches between config and device */
+static int cscfg_add_csdev_cfg(struct coresight_device *csdev,
+			       struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_config_csdev *config_csdev = NULL;
+	struct cscfg_feature_csdev *feat_csdev;
+	int i;
+
+	/* look at each required feature and see if it matches any feature on the device */
+	for (i = 0; i < config_desc->nr_feat_refs; i++) {
+		/* look for a matching name */
+		feat_csdev = cscfg_get_feat_csdev(csdev, config_desc->feat_ref_names[i]);
+		if (feat_csdev) {
+			/*
+			 * At least one feature on this device matches the config
+			 * add a config instance to the device and a reference to the feature.
+			 */
+			if (!config_csdev) {
+				config_csdev = cscfg_alloc_csdev_cfg(csdev,
+								     config_desc->nr_feat_refs);
+				if (!config_csdev)
+					return -ENOMEM;
+				config_csdev->config_desc = config_desc;
+			}
+			config_csdev->feats_csdev[config_csdev->nr_feat++] = feat_csdev;
+		}
+	}
+	/* if matched features, add config to device.*/
+	if (config_csdev) {
+		mutex_lock(&cscfg_csdev_mutex);
+		list_add(&config_csdev->node, &csdev->config_csdev_list);
+		mutex_unlock(&cscfg_csdev_mutex);
+	}
+
+	return 0;
+}
+
+/*
+ * Add the config to the set of registered devices - call with mutex locked.
+ * Iterates through devices - any device that matches one or more of the
+ * configuration features will load it, the others will ignore it.
+ */
+static int cscfg_add_cfg_to_csdevs(struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_registered_csdev *csdev_item;
+	int err;
+
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		err = cscfg_add_csdev_cfg(csdev_item->csdev, config_desc);
+		if (err)
+			return err;
+	}
+	return 0;
+}
+
+/*
+ * Allocate a feature object for load into a csdev.
+ * memory allocated using the csdev->dev object using devm managed allocator.
+ */
+static struct cscfg_feature_csdev *
+cscfg_alloc_csdev_feat(struct coresight_device *csdev, struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_feature_csdev *feat_csdev = NULL;
+	struct device *dev = csdev->dev.parent;
+	int i;
+
+	feat_csdev = devm_kzalloc(dev, sizeof(struct cscfg_feature_csdev), GFP_KERNEL);
+	if (!feat_csdev)
+		return NULL;
+
+	/* parameters are optional - could be 0 */
+	feat_csdev->nr_params = feat_desc->nr_params;
+
+	/*
+	 * if we need parameters, zero alloc the space here, the load routine in
+	 * the csdev device driver will fill out some information according to
+	 * feature descriptor.
+	 */
+	if (feat_csdev->nr_params) {
+		feat_csdev->params_csdev = devm_kcalloc(dev, feat_csdev->nr_params,
+							sizeof(struct cscfg_parameter_csdev),
+							GFP_KERNEL);
+		if (!feat_csdev->params_csdev)
+			return NULL;
+
+		/*
+		 * fill in the feature reference in the param - other fields
+		 * handled by loader in csdev.
+		 */
+		for (i = 0; i < feat_csdev->nr_params; i++)
+			feat_csdev->params_csdev[i].feat_csdev = feat_csdev;
+	}
+
+	/*
+	 * Always have registers to program - again the load routine in csdev device
+	 * will fill out according to feature descriptor and device requirements.
+	 */
+	feat_csdev->nr_regs = feat_desc->nr_regs;
+	feat_csdev->regs_csdev = devm_kcalloc(dev, feat_csdev->nr_regs,
+					      sizeof(struct cscfg_regval_csdev),
+					      GFP_KERNEL);
+	if (!feat_csdev->regs_csdev)
+		return NULL;
+
+	/* load the feature default values */
+	feat_csdev->feat_desc = feat_desc;
+	feat_csdev->csdev = csdev;
+
+	return feat_csdev;
+}
+
+/* load one feature into one coresight device */
+static int cscfg_load_feat_csdev(struct coresight_device *csdev,
+				 struct cscfg_feature_desc *feat_desc,
+				 struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+	int err;
+
+	if (!ops->load_feat)
+		return -EINVAL;
+
+	feat_csdev = cscfg_alloc_csdev_feat(csdev, feat_desc);
+	if (!feat_csdev)
+		return -ENOMEM;
+
+	/* load the feature into the device */
+	err = ops->load_feat(csdev, feat_csdev);
+	if (err)
+		return err;
+
+	/* add to internal csdev feature list */
+	mutex_lock(&cscfg_csdev_mutex);
+	list_add(&feat_csdev->node, &csdev->feature_csdev_list);
+	mutex_unlock(&cscfg_csdev_mutex);
+
+	return 0;
+}
+
+/*
+ * Add feature to any matching devices - call with mutex locked.
+ * Iterates through devices - any device that matches the feature will be
+ * called to load it.
+ */
+static int cscfg_add_feat_to_csdevs(struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_registered_csdev *csdev_item;
+	int err;
+
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		if (csdev_item->match_flags & feat_desc->match_flags) {
+			err = cscfg_load_feat_csdev(csdev_item->csdev, feat_desc, &csdev_item->ops);
+			if (err)
+				return err;
+		}
+	}
+	return 0;
+}
+
 /* check feature list for a named feature - call with mutex locked. */
 static bool cscfg_match_list_feat(const char *name)
 {
@@ -53,8 +246,14 @@ static int cscfg_check_feat_for_cfg(struct cscfg_config_desc *config_desc)
  */
 static int cscfg_load_feat(struct cscfg_feature_desc *feat_desc)
 {
-	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
+	int err;
 
+	/* add feature to any matching registered devices */
+	err = cscfg_add_feat_to_csdevs(feat_desc);
+	if (err)
+		return err;
+
+	list_add(&feat_desc->item, &cscfg_mgr->feat_desc_list);
 	return 0;
 }
 
@@ -71,6 +270,11 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	if (err)
 		return err;
 
+	/* add config to any matching registered device */
+	err = cscfg_add_cfg_to_csdevs(config_desc);
+	if (err)
+		return err;
+
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
 	return 0;
 }
@@ -125,6 +329,138 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 }
 EXPORT_SYMBOL_GPL(cscfg_load_config_sets);
 
+/* Handle coresight device registration and add configs and features to devices */
+
+/* iterate through config lists and load matching configs to device */
+static int cscfg_add_cfgs_csdev(struct coresight_device *csdev)
+{
+	struct cscfg_config_desc *config_desc;
+	int err = 0;
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		err = cscfg_add_csdev_cfg(csdev, config_desc);
+		if (err)
+			break;
+	}
+	return err;
+}
+
+/* iterate through feature lists and load matching features to device */
+static int cscfg_add_feats_csdev(struct coresight_device *csdev,
+				 u32 match_flags,
+				 struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_feature_desc *feat_desc;
+	int err = 0;
+
+	if (!ops->load_feat)
+		return -EINVAL;
+
+	list_for_each_entry(feat_desc, &cscfg_mgr->feat_desc_list, item) {
+		if (feat_desc->match_flags & match_flags) {
+			err = cscfg_load_feat_csdev(csdev, feat_desc, ops);
+			if (err)
+				break;
+		}
+	}
+	return err;
+}
+
+/* Add coresight device to list and copy its matching info */
+static int cscfg_list_add_csdev(struct coresight_device *csdev,
+				u32 match_flags,
+				struct cscfg_csdev_feat_ops *ops)
+{
+	struct cscfg_registered_csdev *csdev_item;
+
+	/* allocate the list entry structure */
+	csdev_item = kzalloc(sizeof(struct cscfg_registered_csdev), GFP_KERNEL);
+	if (!csdev_item)
+		return -ENOMEM;
+
+	csdev_item->csdev = csdev;
+	csdev_item->match_flags = match_flags;
+	csdev_item->ops.load_feat = ops->load_feat;
+	list_add(&csdev_item->item, &cscfg_mgr->csdev_desc_list);
+
+	INIT_LIST_HEAD(&csdev->feature_csdev_list);
+	INIT_LIST_HEAD(&csdev->config_csdev_list);
+
+	return 0;
+}
+
+/* remove a coresight device from the list and free data */
+static void cscfg_list_remove_csdev(struct coresight_device *csdev)
+{
+	struct cscfg_registered_csdev *csdev_item, *tmp;
+
+	list_for_each_entry_safe(csdev_item, tmp, &cscfg_mgr->csdev_desc_list, item) {
+		if (csdev_item->csdev == csdev) {
+			list_del(&csdev_item->item);
+			kfree(csdev_item);
+			break;
+		}
+	}
+}
+
+/**
+ * cscfg_register_csdev - register a coresight device with the syscfg manager.
+ *
+ * Registers the coresight device with the system. @match_flags used to check
+ * if the device is a match for registered features. Any currently registered
+ * configurations and features that match the device will be loaded onto it.
+ *
+ * @csdev:		The coresight device to register.
+ * @match_flags:	Matching information to load features.
+ * @ops:		Standard operations supported by the device.
+ */
+int cscfg_register_csdev(struct coresight_device *csdev,
+			 u32 match_flags,
+			 struct cscfg_csdev_feat_ops *ops)
+{
+	int ret = 0;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* add device to list of registered devices  */
+	ret = cscfg_list_add_csdev(csdev, match_flags, ops);
+	if (ret)
+		goto reg_csdev_unlock;
+
+	/* now load any registered features and configs matching the device. */
+	ret = cscfg_add_feats_csdev(csdev, match_flags, ops);
+	if (ret) {
+		cscfg_list_remove_csdev(csdev);
+		goto reg_csdev_unlock;
+	}
+
+	ret = cscfg_add_cfgs_csdev(csdev);
+	if (ret) {
+		cscfg_list_remove_csdev(csdev);
+		goto reg_csdev_unlock;
+	}
+
+	pr_info("CSCFG registered %s", dev_name(&csdev->dev));
+
+reg_csdev_unlock:
+	mutex_unlock(&cscfg_mutex);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cscfg_register_csdev);
+
+/**
+ * cscfg_unregister_csdev - remove coresight device from syscfg manager.
+ *
+ * @csdev: Device to remove.
+ */
+void cscfg_unregister_csdev(struct coresight_device *csdev)
+{
+	mutex_lock(&cscfg_mutex);
+	cscfg_list_remove_csdev(csdev);
+	mutex_unlock(&cscfg_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_unregister_csdev);
+
 /* Initialise system configuration management device. */
 
 struct device *cscfg_device(void)
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 18be9b58cd0b..5bcae3b374c6 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -35,6 +35,22 @@ struct cscfg_manager {
 /* get reference to dev in cscfg_manager */
 struct device *cscfg_device(void);
 
+/**
+ * List entry for Coresight devices that are registered as supporting complex
+ * config operations.
+ *
+ * @csdev:	 The registered device.
+ * @match_flags: The matching type information for adding features.
+ * @ops:	 Operations supported by the registered device.
+ * @item:	 list entry.
+ */
+struct cscfg_registered_csdev {
+	struct coresight_device *csdev;
+	u32 match_flags;
+	struct cscfg_csdev_feat_ops ops;
+	struct list_head item;
+};
+
 /* internal core operations for cscfg */
 int __init cscfg_init(void);
 void cscfg_exit(void);
@@ -42,5 +58,8 @@ void cscfg_exit(void);
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
 			   struct cscfg_feature_desc **feat_descs);
+int cscfg_register_csdev(struct coresight_device *csdev, u32 match_flags,
+			 struct cscfg_csdev_feat_ops *ops);
+void cscfg_unregister_csdev(struct coresight_device *csdev);
 
 #endif /* CORESIGHT_SYSCFG_H */
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 85008a65e21f..6fb516e1b22e 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -220,6 +220,8 @@ struct coresight_sysfs_link {
  * @nr_links:   number of sysfs links created to other components from this
  *		device. These will appear in the "connections" group.
  * @has_conns_grp: Have added a "connections" group for sysfs links.
+ * @feature_csdev_list: List of complex feature programming added to the device.
+ * @config_csdev_list:  List of system configurations added to the device.
  */
 struct coresight_device {
 	struct coresight_platform_data *pdata;
@@ -241,6 +243,9 @@ struct coresight_device {
 	int nr_links;
 	bool has_conns_grp;
 	bool ect_enabled; /* true only if associated ect device is enabled */
+	/* system configuration and feature lists */
+	struct list_head feature_csdev_list;
+	struct list_head config_csdev_list;
 };
 
 /*
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:58 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:58 +0100
Subject: [PATCH v7 05/10] coresight: syscfg: Add API to activate and enable
 configurations
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-6-mike.leach@linaro.org>

Configurations are first activated, then when any coresight device is
enabled, the active configurations are checked and any matching
one is enabled.

This patch provides the activation / enable API.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |   2 +
 .../hwtracing/coresight/coresight-syscfg.c    | 172 ++++++++++++++++++
 .../hwtracing/coresight/coresight-syscfg.h    |   8 +
 include/linux/coresight.h                     |   2 +
 4 files changed, 184 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 0667581822c1..25eb6c632692 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -127,6 +127,7 @@ struct cscfg_feature_desc {
  * @nr_total_params:	Sum of all parameters declared by used features
  * @presets:		Array of preset values.
  * @event_ea:		Extended attribute for perf event value
+ * @active_cnt:		ref count for activate on this configuration.
  *
  */
 struct cscfg_config_desc {
@@ -139,6 +140,7 @@ struct cscfg_config_desc {
 	int nr_total_params;
 	const u64 *presets; /* nr_presets * nr_total_params */
 	struct dev_ext_attribute *event_ea;
+	atomic_t active_cnt;
 };
 
 /**
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index e35f8c0ac2f8..b234e45c153f 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -283,6 +283,7 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 		return err;
 
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
+	atomic_set(&config_desc->active_cnt, 0);
 	return 0;
 }
 
@@ -468,6 +469,176 @@ void cscfg_unregister_csdev(struct coresight_device *csdev)
 }
 EXPORT_SYMBOL_GPL(cscfg_unregister_csdev);
 
+/**
+ * cscfg_csdev_reset_feats - reset features for a CoreSight device.
+ *
+ * Resets all parameters and register values for any features loaded
+ * into @csdev to their default values.
+ *
+ * @csdev: The CoreSight device.
+ */
+void cscfg_csdev_reset_feats(struct coresight_device *csdev)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	if (list_empty(&csdev->feature_csdev_list))
+		goto unlock_exit;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node)
+		cscfg_reset_feat(feat_csdev);
+
+unlock_exit:
+	mutex_unlock(&cscfg_csdev_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_reset_feats);
+
+/**
+ * cscfg_activate_config -  Mark a configuration descriptor as active.
+ *
+ * This will be seen when csdev devices are enabled in the system.
+ * Only activated configurations can be enabled on individual devices.
+ * Activation protects the configuration from alteration or removal while
+ * active.
+ *
+ * Selection by hash value - generated from the configuration name when it
+ * was loaded and added to the cs_etm/configurations file system for selection
+ * by perf.
+ *
+ * Increments the configuration descriptor active count and the global active
+ * count.
+ *
+ * @cfg_hash: Hash value of the selected configuration name.
+ */
+int cscfg_activate_config(unsigned long cfg_hash)
+{
+	struct cscfg_config_desc *config_desc;
+	int err = -EINVAL;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
+			/*
+			 * increment the global active count - control changes to
+			 * active configurations
+			 */
+			atomic_inc(&cscfg_mgr->sys_active_cnt);
+
+			/*
+			 * mark the descriptor as active so enable config on a
+			 * device instance will use it
+			 */
+			atomic_inc(&config_desc->active_cnt);
+
+			err = 0;
+			dev_dbg(cscfg_device(), "Activate config %s.\n", config_desc->name);
+			break;
+		}
+	}
+	mutex_unlock(&cscfg_mutex);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_activate_config);
+
+/**
+ * cscfg_deactivate_config -  Mark a config descriptor as inactive.
+ *
+ * Decrement the configuration and global active counts.
+ *
+ * @cfg_hash: Hash value of the selected configuration name.
+ */
+void cscfg_deactivate_config(unsigned long cfg_hash)
+{
+	struct cscfg_config_desc *config_desc;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
+		if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
+			atomic_dec(&config_desc->active_cnt);
+			atomic_dec(&cscfg_mgr->sys_active_cnt);
+			dev_dbg(cscfg_device(), "Deactivate config %s.\n", config_desc->name);
+			break;
+		}
+	}
+	mutex_unlock(&cscfg_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_deactivate_config);
+
+/**
+ * cscfg_csdev_enable_active_config - Enable matching active configuration for device.
+ *
+ * Enables the configuration selected by @cfg_hash if the configuration is supported
+ * on the device and has been activated.
+ *
+ * If active and supported the CoreSight device @csdev will be programmed with the
+ * configuration, using @preset parameters.
+ *
+ * Should be called before driver hardware enable for the requested device, prior to
+ * programming and enabling the physical hardware.
+ *
+ * @csdev:	CoreSight device to program.
+ * @cfg_hash:	Selector for the configuration.
+ * @preset:	Preset parameter values to use, 0 for current / default values.
+ */
+int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
+				     unsigned long cfg_hash, int preset)
+{
+	struct cscfg_config_csdev *config_csdev_active = NULL, *config_csdev_item;
+	const struct cscfg_config_desc *config_desc;
+	int err = 0;
+
+	/* quickly check global count */
+	if (!atomic_read(&cscfg_mgr->sys_active_cnt))
+		return 0;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	list_for_each_entry(config_csdev_item, &csdev->config_csdev_list, node) {
+		config_desc = config_csdev_item->config_desc;
+		if ((atomic_read(&config_desc->active_cnt)) &&
+		    ((unsigned long)config_desc->event_ea->var == cfg_hash)) {
+			config_csdev_active = config_csdev_item;
+			break;
+		}
+	}
+	if (config_csdev_active) {
+		err = cscfg_csdev_enable_config(config_csdev_active, preset);
+		if (!err)
+			csdev->active_cscfg_ctxt = (void *)config_csdev_active;
+	}
+	mutex_unlock(&cscfg_csdev_mutex);
+	return err;
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_enable_active_config);
+
+/**
+ * cscfg_csdev_disable_active_config - disable an active config on the device.
+ *
+ * Disables the active configuration on the CoreSight device @csdev.
+ * Disable will save the values of any registers marked in the configurations
+ * as save on disable.
+ *
+ * Should be called after driver hardware disable for the requested device,
+ * after disabling the physical hardware and reading back registers.
+ *
+ * @csdev: The CoreSight device.
+ */
+void cscfg_csdev_disable_active_config(struct coresight_device *csdev)
+{
+	struct cscfg_config_csdev *config_csdev;
+
+	mutex_lock(&cscfg_csdev_mutex);
+	config_csdev = (struct cscfg_config_csdev *)csdev->active_cscfg_ctxt;
+	if (config_csdev) {
+		cscfg_csdev_disable_config(config_csdev);
+		csdev->active_cscfg_ctxt = NULL;
+	}
+	mutex_unlock(&cscfg_csdev_mutex);
+}
+EXPORT_SYMBOL_GPL(cscfg_csdev_disable_active_config);
+
 /* Initialise system configuration management device. */
 
 struct device *cscfg_device(void)
@@ -536,6 +707,7 @@ int __init cscfg_init(void)
 	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
+	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
 
 	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
 	return 0;
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 5bcae3b374c6..a52775890670 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -24,12 +24,14 @@
  * @csdev_desc_list:	List of coresight devices registered with the configuration manager.
  * @feat_desc_list:	List of feature descriptors to load into registered devices.
  * @config_desc_list:	List of system configuration descriptors to load into registered devices.
+ * @sys_active_cnt:	Total number of active config descriptor references.
  */
 struct cscfg_manager {
 	struct device dev;
 	struct list_head csdev_desc_list;
 	struct list_head feat_desc_list;
 	struct list_head config_desc_list;
+	atomic_t sys_active_cnt;
 };
 
 /* get reference to dev in cscfg_manager */
@@ -61,5 +63,11 @@ int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
 int cscfg_register_csdev(struct coresight_device *csdev, u32 match_flags,
 			 struct cscfg_csdev_feat_ops *ops);
 void cscfg_unregister_csdev(struct coresight_device *csdev);
+int cscfg_activate_config(unsigned long cfg_hash);
+void cscfg_deactivate_config(unsigned long cfg_hash);
+void cscfg_csdev_reset_feats(struct coresight_device *csdev);
+int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
+				     unsigned long cfg_hash, int preset);
+void cscfg_csdev_disable_active_config(struct coresight_device *csdev);
 
 #endif /* CORESIGHT_SYSCFG_H */
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 6fb516e1b22e..a348049ee08b 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -222,6 +222,7 @@ struct coresight_sysfs_link {
  * @has_conns_grp: Have added a "connections" group for sysfs links.
  * @feature_csdev_list: List of complex feature programming added to the device.
  * @config_csdev_list:  List of system configurations added to the device.
+ * @active_cscfg_ctxt:  Context information for current active system configuration.
  */
 struct coresight_device {
 	struct coresight_platform_data *pdata;
@@ -246,6 +247,7 @@ struct coresight_device {
 	/* system configuration and feature lists */
 	struct list_head feature_csdev_list;
 	struct list_head config_csdev_list;
+	void *active_cscfg_ctxt;
 };
 
 /*
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:57 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:57 +0100
Subject: [PATCH v7 04/10] coresight: etm-perf: update to handle configuration
 selection
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-5-mike.leach@linaro.org>

Loaded coresight configurations are registered in the cs_etm\events sub
directory. This extends the etm-perf code to handle these registrations,
and the cs_syscfg driver to perform the registration on load.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../hwtracing/coresight/coresight-config.h    |   2 +
 .../hwtracing/coresight/coresight-etm-perf.c  | 134 ++++++++++++++----
 .../hwtracing/coresight/coresight-etm-perf.h  |   8 ++
 .../hwtracing/coresight/coresight-syscfg.c    |  11 ++
 4 files changed, 127 insertions(+), 28 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-config.h b/drivers/hwtracing/coresight/coresight-config.h
index 5a39cbbc38a4..0667581822c1 100644
--- a/drivers/hwtracing/coresight/coresight-config.h
+++ b/drivers/hwtracing/coresight/coresight-config.h
@@ -126,6 +126,7 @@ struct cscfg_feature_desc {
  * @nr_presets:		Number of sets of presets supplied by this configuration.
  * @nr_total_params:	Sum of all parameters declared by used features
  * @presets:		Array of preset values.
+ * @event_ea:		Extended attribute for perf event value
  *
  */
 struct cscfg_config_desc {
@@ -137,6 +138,7 @@ struct cscfg_config_desc {
 	int nr_presets;
 	int nr_total_params;
 	const u64 *presets; /* nr_presets * nr_total_params */
+	struct dev_ext_attribute *event_ea;
 };
 
 /**
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 15310c72f89f..26b4bca156aa 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -18,8 +18,10 @@
 #include <linux/types.h>
 #include <linux/workqueue.h>
 
+#include "coresight-config.h"
 #include "coresight-etm-perf.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static struct pmu etm_pmu;
 static bool etm_perf_up;
@@ -57,8 +59,13 @@ PMU_FORMAT_ATTR(contextid1,	"config:" __stringify(ETM_OPT_CTXTID));
 PMU_FORMAT_ATTR(contextid2,	"config:" __stringify(ETM_OPT_CTXTID2));
 PMU_FORMAT_ATTR(timestamp,	"config:" __stringify(ETM_OPT_TS));
 PMU_FORMAT_ATTR(retstack,	"config:" __stringify(ETM_OPT_RETSTK));
+/* preset - if sink ID is used as a configuration selector */
+PMU_FORMAT_ATTR(preset,		"config:0-3");
 /* Sink ID - same for all ETMs */
 PMU_FORMAT_ATTR(sinkid,		"config2:0-31");
+/* config ID - set if a system configuration is selected */
+PMU_FORMAT_ATTR(configid,	"config2:32-63");
+
 
 /*
  * contextid always traces the "PID".  The PID is in CONTEXTIDR_EL1
@@ -88,6 +95,8 @@ static struct attribute *etm_config_formats_attr[] = {
 	&format_attr_timestamp.attr,
 	&format_attr_retstack.attr,
 	&format_attr_sinkid.attr,
+	&format_attr_preset.attr,
+	&format_attr_configid.attr,
 	NULL,
 };
 
@@ -105,9 +114,19 @@ static const struct attribute_group etm_pmu_sinks_group = {
 	.attrs  = etm_config_sinks_attr,
 };
 
+static struct attribute *etm_config_events_attr[] = {
+	NULL,
+};
+
+static const struct attribute_group etm_pmu_events_group = {
+	.name   = "events",
+	.attrs  = etm_config_events_attr,
+};
+
 static const struct attribute_group *etm_pmu_attr_groups[] = {
 	&etm_pmu_format_group,
 	&etm_pmu_sinks_group,
+	&etm_pmu_events_group,
 	NULL,
 };
 
@@ -286,7 +305,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	INIT_WORK(&event_data->work, free_event_data);
 
 	/* First get the selected sink from user space. */
-	if (event->attr.config2) {
+	if (event->attr.config2 & GENMASK_ULL(31, 0)) {
 		id = (u32)event->attr.config2;
 		sink = user_sink = coresight_get_sink_by_id(id);
 	}
@@ -658,68 +677,127 @@ static ssize_t etm_perf_sink_name_show(struct device *dev,
 	return scnprintf(buf, PAGE_SIZE, "0x%lx\n", (unsigned long)(ea->var));
 }
 
-int etm_perf_add_symlink_sink(struct coresight_device *csdev)
+static struct dev_ext_attribute *
+etm_perf_add_symlink_group(struct device *dev, const char *name, const char *group_name)
 {
-	int ret;
+	struct dev_ext_attribute *ea;
 	unsigned long hash;
-	const char *name;
+	int ret;
 	struct device *pmu_dev = etm_pmu.dev;
-	struct device *dev = &csdev->dev;
-	struct dev_ext_attribute *ea;
-
-	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
-	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
-		return -EINVAL;
-
-	if (csdev->ea != NULL)
-		return -EINVAL;
 
 	if (!etm_perf_up)
-		return -EPROBE_DEFER;
+		return ERR_PTR(-EPROBE_DEFER);
 
 	ea = devm_kzalloc(dev, sizeof(*ea), GFP_KERNEL);
 	if (!ea)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
-	name = dev_name(dev);
-	/* See function coresight_get_sink_by_id() to know where this is used */
+	/*
+	 * If this function is called adding a sink then the hash is used for
+	 * sink selection - see function coresight_get_sink_by_id().
+	 * If adding a configuration then the hash is used for selection in
+	 * cscfg_activate_config()
+	 */
 	hash = hashlen_hash(hashlen_string(NULL, name));
 
 	sysfs_attr_init(&ea->attr.attr);
 	ea->attr.attr.name = devm_kstrdup(dev, name, GFP_KERNEL);
 	if (!ea->attr.attr.name)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	ea->attr.attr.mode = 0444;
-	ea->attr.show = etm_perf_sink_name_show;
 	ea->var = (unsigned long *)hash;
 
 	ret = sysfs_add_file_to_group(&pmu_dev->kobj,
-				      &ea->attr.attr, "sinks");
+				      &ea->attr.attr, group_name);
 
-	if (!ret)
-		csdev->ea = ea;
+	return ret ? ERR_PTR(ret) : ea;
+}
 
-	return ret;
+int etm_perf_add_symlink_sink(struct coresight_device *csdev)
+{
+	const char *name;
+	struct device *dev = &csdev->dev;
+	int err = 0;
+
+	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+		return -EINVAL;
+
+	if (csdev->ea != NULL)
+		return -EINVAL;
+
+	name = dev_name(dev);
+	csdev->ea = etm_perf_add_symlink_group(dev, name, "sinks");
+	if (IS_ERR(csdev->ea)) {
+		err = PTR_ERR(csdev->ea);
+		csdev->ea = NULL;
+	} else
+		csdev->ea->attr.show = etm_perf_sink_name_show;
+
+	return err;
 }
 
-void etm_perf_del_symlink_sink(struct coresight_device *csdev)
+static void etm_perf_del_symlink_group(struct dev_ext_attribute *ea, const char *group_name)
 {
 	struct device *pmu_dev = etm_pmu.dev;
-	struct dev_ext_attribute *ea = csdev->ea;
 
+	sysfs_remove_file_from_group(&pmu_dev->kobj,
+				     &ea->attr.attr, group_name);
+}
+
+void etm_perf_del_symlink_sink(struct coresight_device *csdev)
+{
 	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
 	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
 		return;
 
-	if (!ea)
+	if (!csdev->ea)
 		return;
 
-	sysfs_remove_file_from_group(&pmu_dev->kobj,
-				     &ea->attr.attr, "sinks");
+	etm_perf_del_symlink_group(csdev->ea, "sinks");
 	csdev->ea = NULL;
 }
 
+static ssize_t etm_perf_cscfg_event_show(struct device *dev,
+					 struct device_attribute *dattr,
+					 char *buf)
+{
+	struct dev_ext_attribute *ea;
+
+	ea = container_of(dattr, struct dev_ext_attribute, attr);
+	return scnprintf(buf, PAGE_SIZE, "configid=0x%lx\n", (unsigned long)(ea->var));
+}
+
+int etm_perf_add_symlink_cscfg(struct device *dev, struct cscfg_config_desc *config_desc)
+{
+	int err = 0;
+
+	if (config_desc->event_ea != NULL)
+		return 0;
+
+	config_desc->event_ea = etm_perf_add_symlink_group(dev, config_desc->name, "events");
+
+	/* set the show function to the custom cscfg event */
+	if (!IS_ERR(config_desc->event_ea))
+		config_desc->event_ea->attr.show = etm_perf_cscfg_event_show;
+	else {
+		err = PTR_ERR(config_desc->event_ea);
+		config_desc->event_ea = NULL;
+	}
+
+	return err;
+}
+
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc)
+{
+	if (!config_desc->event_ea)
+		return;
+
+	etm_perf_del_symlink_group(config_desc->event_ea, "events");
+	config_desc->event_ea = NULL;
+}
+
 int __init etm_perf_init(void)
 {
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 29d90dfeba31..ba617fe2217e 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -11,6 +11,7 @@
 #include "coresight-priv.h"
 
 struct coresight_device;
+struct cscfg_config_desc;
 
 /*
  * In both ETMv3 and v4 the maximum number of address comparator implentable
@@ -69,6 +70,9 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 		return data->snk_config;
 	return NULL;
 }
+int etm_perf_add_symlink_cscfg(struct device *dev,
+			       struct cscfg_config_desc *config_desc);
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc);
 #else
 static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
 { return -EINVAL; }
@@ -79,6 +83,10 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 {
 	return NULL;
 }
+int etm_perf_add_symlink_cscfg(struct device *dev,
+			       struct cscfg_config_desc *config_desc)
+{ return -EINVAL; }
+void etm_perf_del_symlink_cscfg(struct cscfg_config_desc *config_desc) {}
 
 #endif /* CONFIG_CORESIGHT */
 
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index c7f48d6b48f5..e35f8c0ac2f8 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -7,6 +7,7 @@
 #include <linux/platform_device.h>
 
 #include "coresight-config.h"
+#include "coresight-etm-perf.h"
 #include "coresight-syscfg.h"
 
 /*
@@ -276,6 +277,11 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	if (err)
 		return err;
 
+	/* add config to perf fs to allow selection */
+	err = etm_perf_add_symlink_cscfg(cscfg_device(), config_desc);
+	if (err)
+		return err;
+
 	list_add(&config_desc->item, &cscfg_mgr->config_desc_list);
 	return 0;
 }
@@ -508,7 +514,12 @@ static int cscfg_create_device(void)
 
 static void cscfg_clear_device(void)
 {
+	struct cscfg_config_desc *cfg_desc;
+
 	mutex_lock(&cscfg_mutex);
+	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
+		etm_perf_del_symlink_cscfg(cfg_desc);
+	}
 	device_unregister(cscfg_device());
 	mutex_unlock(&cscfg_mutex);
 }
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:18:59 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:18:59 +0100
Subject: [PATCH v7 06/10] coresight: etm-perf: Update to activate selected
 configuration
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-7-mike.leach@linaro.org>

Add calls to activate the selected configuration as perf starts
and stops the tracing session.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 14 +++++++++++++-
 drivers/hwtracing/coresight/coresight-etm-perf.h |  2 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 26b4bca156aa..560baefdfed8 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -215,6 +215,10 @@ static void free_event_data(struct work_struct *work)
 	/* Free the sink buffers, if there are any */
 	free_sink_buffer(event_data);
 
+	/* clear any configuration we were using */
+	if (event_data->cfg_hash)
+		cscfg_deactivate_config(event_data->cfg_hash);
+
 	for_each_cpu(cpu, mask) {
 		struct list_head **ppath;
 
@@ -292,7 +296,7 @@ static bool sinks_compatible(struct coresight_device *a,
 static void *etm_setup_aux(struct perf_event *event, void **pages,
 			   int nr_pages, bool overwrite)
 {
-	u32 id;
+	u32 id, cfg_hash;
 	int cpu = event->cpu;
 	cpumask_t *mask;
 	struct coresight_device *sink = NULL;
@@ -310,6 +314,14 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 		sink = user_sink = coresight_get_sink_by_id(id);
 	}
 
+	/* check if user wants a coresight configuration selected */
+	cfg_hash = (u32)((event->attr.config2 & GENMASK_ULL(63, 32)) >> 32);
+	if (cfg_hash) {
+		if (cscfg_activate_config(cfg_hash))
+			goto err;
+		event_data->cfg_hash = cfg_hash;
+	}
+
 	mask = &event_data->mask;
 
 	/*
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index ba617fe2217e..468f7799ab4f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -49,12 +49,14 @@ struct etm_filters {
  * @work:		Handle to free allocated memory outside IRQ context.
  * @mask:		Hold the CPU(s) this event was set for.
  * @snk_config:		The sink configuration.
+ * @cfg_hash:		The hash id of any coresight config selected.
  * @path:		An array of path, each slot for one CPU.
  */
 struct etm_event_data {
 	struct work_struct work;
 	cpumask_t mask;
 	void *snk_config;
+	u32 cfg_hash;
 	struct list_head * __percpu *path;
 };
 
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:19:00 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:19:00 +0100
Subject: [PATCH v7 07/10] coresight: etm4x: Add complex configuration handlers
 to etmv4
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-8-mike.leach@linaro.org>

Adds in handlers to allow the ETMv4 to use the complex configuration
support. Features and configurations can be loaded and selected in the
device.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++++++++++++++++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
 .../coresight/coresight-etm4x-core.c          |  38 +++-
 .../coresight/coresight-etm4x-sysfs.c         |   3 +
 5 files changed, 238 insertions(+), 3 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 63ecfc3cf66d..9420d33b23ac 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,7 +16,8 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o
 coresight-etm3x-y := coresight-etm3x-core.o coresight-etm-cp14.o \
 		     coresight-etm3x-sysfs.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
-coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o
+coresight-etm4x-y := coresight-etm4x-core.o coresight-etm4x-sysfs.o \
+			coresight-etm4x-cfg.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
 obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
 obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
new file mode 100644
index 000000000000..d2ea903231b2
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-etm4x.h"
+#include "coresight-etm4x-cfg.h"
+#include "coresight-priv.h"
+#include "coresight-syscfg.h"
+
+/* defines to associate register IDs with driver data locations */
+#define CHECKREG(cval, elem) \
+	{ \
+		if (offset == cval) { \
+			reg_csdev->driver_regval = &drvcfg->elem; \
+			err = 0; \
+			break; \
+		} \
+	}
+
+#define CHECKREGIDX(cval, elem, off_idx, mask)	\
+	{ \
+		if (mask == cval) { \
+			reg_csdev->driver_regval = &drvcfg->elem[off_idx]; \
+			err = 0; \
+			break; \
+		} \
+	}
+
+/**
+ * etm4_cfg_map_reg_offset - validate and map the register offset into a
+ *			     location in the driver config struct.
+ *
+ * Limits the number of registers that can be accessed and programmed in
+ * features, to those which are used to control the trace capture parameters.
+ *
+ * Omits or limits access to those which the driver must use exclusively.
+ *
+ * Invalid offsets will result in fail code return and feature load failure.
+ *
+ * @drvdata:	driver data to map into.
+ * @reg:	register to map.
+ * @offset:	device offset for the register
+ */
+static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata,
+				   struct cscfg_regval_csdev *reg_csdev, u32 offset)
+{
+	int err = -EINVAL, idx;
+	struct etmv4_config *drvcfg = &drvdata->config;
+	u32 off_mask;
+
+	if (((offset >= TRCEVENTCTL0R) && (offset <= TRCVIPCSSCTLR)) ||
+	    ((offset >= TRCSEQRSTEVR) && (offset <= TRCEXTINSELR)) ||
+	    ((offset >= TRCCIDCCTLR0) && (offset <= TRCVMIDCCTLR1))) {
+		do {
+			CHECKREG(TRCEVENTCTL0R, eventctrl0);
+			CHECKREG(TRCEVENTCTL1R, eventctrl1);
+			CHECKREG(TRCSTALLCTLR, stall_ctrl);
+			CHECKREG(TRCTSCTLR, ts_ctrl);
+			CHECKREG(TRCSYNCPR, syncfreq);
+			CHECKREG(TRCCCCTLR, ccctlr);
+			CHECKREG(TRCBBCTLR, bb_ctrl);
+			CHECKREG(TRCVICTLR, vinst_ctrl);
+			CHECKREG(TRCVIIECTLR, viiectlr);
+			CHECKREG(TRCVISSCTLR, vissctlr);
+			CHECKREG(TRCVIPCSSCTLR, vipcssctlr);
+			CHECKREG(TRCSEQRSTEVR, seq_rst);
+			CHECKREG(TRCSEQSTR, seq_state);
+			CHECKREG(TRCEXTINSELR, ext_inp);
+			CHECKREG(TRCCIDCCTLR0, ctxid_mask0);
+			CHECKREG(TRCCIDCCTLR1, ctxid_mask1);
+			CHECKREG(TRCVMIDCCTLR0, vmid_mask0);
+			CHECKREG(TRCVMIDCCTLR1, vmid_mask1);
+		} while (0);
+	} else if ((offset & GENMASK(11, 4)) == TRCSEQEVRn(0)) {
+		/* sequencer state control registers */
+		idx = (offset & GENMASK(3, 0)) / 4;
+		if (idx < ETM_MAX_SEQ_STATES) {
+			reg_csdev->driver_regval = &drvcfg->seq_ctrl[idx];
+			err = 0;
+		}
+	} else if ((offset >= TRCSSCCRn(0)) && (offset <= TRCSSPCICRn(7))) {
+		/* 32 bit, 8 off indexed register sets */
+		idx = (offset & GENMASK(4, 0)) / 4;
+		off_mask =  (offset & GENMASK(11, 5));
+		do {
+			CHECKREGIDX(TRCSSCCRn(0), ss_ctrl, idx, off_mask);
+			CHECKREGIDX(TRCSSCSRn(0), ss_status, idx, off_mask);
+			CHECKREGIDX(TRCSSPCICRn(0), ss_pe_cmp, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCCIDCVRn(0)) && (offset <= TRCVMIDCVRn(7))) {
+		/* 64 bit, 8 off indexed register sets */
+		idx = (offset & GENMASK(5, 0)) / 8;
+		off_mask = (offset & GENMASK(11, 6));
+		do {
+			CHECKREGIDX(TRCCIDCVRn(0), ctxid_pid, idx, off_mask);
+			CHECKREGIDX(TRCVMIDCVRn(0), vmid_val, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCRSCTLRn(2)) &&
+		   (offset <= TRCRSCTLRn((ETM_MAX_RES_SEL - 1)))) {
+		/* 32 bit resource selection regs, 32 off, skip fixed 0,1 */
+		idx = (offset & GENMASK(6, 0)) / 4;
+		if (idx < ETM_MAX_RES_SEL) {
+			reg_csdev->driver_regval = &drvcfg->res_ctrl[idx];
+			err = 0;
+		}
+	} else if ((offset >= TRCACVRn(0)) &&
+		   (offset <= TRCACATRn((ETM_MAX_SINGLE_ADDR_CMP - 1)))) {
+		/* 64 bit addr cmp regs, 16 off */
+		idx = (offset & GENMASK(6, 0)) / 8;
+		off_mask = offset & GENMASK(11, 7);
+		do {
+			CHECKREGIDX(TRCACVRn(0), addr_val, idx, off_mask);
+			CHECKREGIDX(TRCACATRn(0), addr_acc, idx, off_mask);
+		} while (0);
+	} else if ((offset >= TRCCNTRLDVRn(0)) &&
+		   (offset <= TRCCNTVRn((ETMv4_MAX_CNTR - 1)))) {
+		/* 32 bit counter regs, 4 off (ETMv4_MAX_CNTR - 1) */
+		idx = (offset &  GENMASK(3, 0)) / 4;
+		off_mask = offset &  GENMASK(11, 4);
+		do {
+			CHECKREGIDX(TRCCNTRLDVRn(0), cntrldvr, idx, off_mask);
+			CHECKREGIDX(TRCCNTCTLRn(0), cntr_ctrl, idx, off_mask);
+			CHECKREGIDX(TRCCNTVRn(0), cntr_val, idx, off_mask);
+		} while (0);
+	}
+	return err;
+}
+
+/**
+ * etm4_cfg_load_feature - load a feature into a device instance.
+ *
+ * @csdev:	An ETMv4 CoreSight device.
+ * @feat:	The feature to be loaded.
+ *
+ * The function will load a feature instance into the device, checking that
+ * the register definitions are valid for the device.
+ *
+ * Parameter and register definitions will be converted into internal
+ * structures that are used to set the values in the driver when the
+ * feature is enabled for the device.
+ *
+ * The feature spinlock pointer is initialised to the same spinlock
+ * that the driver uses to protect the internal register values.
+ */
+static int etm4_cfg_load_feature(struct coresight_device *csdev,
+				 struct cscfg_feature_csdev *feat_csdev)
+{
+	struct device *dev = csdev->dev.parent;
+	struct etmv4_drvdata *drvdata = dev_get_drvdata(dev);
+	const struct cscfg_feature_desc *feat_desc = feat_csdev->feat_desc;
+	u32 offset;
+	int i = 0, err = 0;
+
+	/*
+	 * essential we set the device spinlock - this is used in the generic
+	 * programming routines when copying values into the drvdata structures
+	 * via the pointers setup in etm4_cfg_map_reg_offset().
+	 */
+	feat_csdev->drv_spinlock = &drvdata->spinlock;
+
+	/* process the register descriptions */
+	for (i = 0; i < feat_csdev->nr_regs && !err; i++) {
+		offset = feat_desc->regs_desc[i].offset;
+		err = etm4_cfg_map_reg_offset(drvdata, &feat_csdev->regs_csdev[i], offset);
+	}
+	return err;
+}
+
+/* match information when loading configurations */
+#define CS_CFG_ETM4_MATCH_FLAGS	(CS_CFG_MATCH_CLASS_SRC_ALL | \
+				 CS_CFG_MATCH_CLASS_SRC_ETM4)
+
+int etm4_cscfg_register(struct coresight_device *csdev)
+{
+	struct cscfg_csdev_feat_ops ops;
+
+	ops.load_feat = &etm4_cfg_load_feature;
+
+	return cscfg_register_csdev(csdev, CS_CFG_ETM4_MATCH_FLAGS, &ops);
+}
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
new file mode 100644
index 000000000000..a204ad9a4792
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2014-2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _CORESIGHT_ETM4X_CFG_H
+#define _CORESIGHT_ETM4X_CFG_H
+
+#include "coresight-config.h"
+#include "coresight-etm4x.h"
+
+/* ETMv4 specific config functions */
+int etm4_cscfg_register(struct coresight_device *csdev);
+
+#endif /* CORESIGHT_ETM4X_CFG_H */
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index efb84ced83dd..94f10910d20d 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -39,6 +39,8 @@
 
 #include "coresight-etm4x.h"
 #include "coresight-etm-perf.h"
+#include "coresight-etm4x-cfg.h"
+#include "coresight-syscfg.h"
 
 static int boot_enable;
 module_param(boot_enable, int, 0444);
@@ -561,12 +563,15 @@ static int etm4_config_timestamp_event(struct etmv4_drvdata *drvdata)
 	return ret;
 }
 
-static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
+static int etm4_parse_event_config(struct coresight_device *csdev,
 				   struct perf_event *event)
 {
 	int ret = 0;
+	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	struct etmv4_config *config = &drvdata->config;
 	struct perf_event_attr *attr = &event->attr;
+	unsigned long cfg_hash;
+	int preset;
 
 	if (!attr) {
 		ret = -EINVAL;
@@ -637,6 +642,20 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
 		/* bit[12], Return stack enable bit */
 		config->cfg |= BIT(12);
 
+	/*
+	 * Set any selected configuration and preset.
+	 *
+	 * This extracts the values of PMU_FORMAT_ATTR(configid) and PMU_FORMAT_ATTR(preset)
+	 * in the perf attributes defined in coresight-etm-perf.c.
+	 * configid uses bits 63:32 of attr->config2, preset uses bits 3:0 of attr->config.
+	 * A zero configid means no configuration active, preset = 0 means no preset selected.
+	 */
+	if (attr->config2 & GENMASK_ULL(63, 32)) {
+		cfg_hash = (u32)(attr->config2 >> 32);
+		preset = attr->config & 0xF;
+		ret = cscfg_csdev_enable_active_config(csdev, cfg_hash, preset);
+	}
+
 out:
 	return ret;
 }
@@ -653,7 +672,7 @@ static int etm4_enable_perf(struct coresight_device *csdev,
 	}
 
 	/* Configure the tracer based on the session's specifics */
-	ret = etm4_parse_event_config(drvdata, event);
+	ret = etm4_parse_event_config(csdev, event);
 	if (ret)
 		goto out;
 	/* And enable it */
@@ -799,11 +818,18 @@ static int etm4_disable_perf(struct coresight_device *csdev,
 	u32 control;
 	struct etm_filters *filters = event->hw.addr_filters;
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	struct perf_event_attr *attr = &event->attr;
 
 	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
 		return -EINVAL;
 
 	etm4_disable_hw(drvdata);
+	/*
+	 * The config_id occupies bits 63:32 of the config2 perf event attr
+	 * field. If this is non-zero then we will have enabled a config.
+	 */
+	if (attr->config2 & GENMASK_ULL(63, 32))
+		cscfg_csdev_disable_active_config(csdev);
 
 	/*
 	 * Check if the start/stop logic was active when the unit was stopped.
@@ -1944,6 +1970,13 @@ static int etm4_probe(struct device *dev, void __iomem *base, u32 etm_pid)
 		return ret;
 	}
 
+	/* register with config infrastructure & load any current features */
+	ret = etm4_cscfg_register(drvdata->csdev);
+	if (ret) {
+		coresight_unregister(drvdata->csdev);
+		return ret;
+	}
+
 	etmdrvdata[drvdata->cpu] = drvdata;
 
 	dev_info(&drvdata->csdev->dev, "CPU%d: %s v%d.%d initialized\n",
@@ -2030,6 +2063,7 @@ static int __exit etm4_remove_dev(struct etmv4_drvdata *drvdata)
 
 	cpus_read_unlock();
 
+	cscfg_unregister_csdev(drvdata->csdev);
 	coresight_unregister(drvdata->csdev);
 
 	return 0;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
index 007bad9e7ad8..a0640fa5c55b 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
@@ -9,6 +9,7 @@
 #include <linux/sysfs.h>
 #include "coresight-etm4x.h"
 #include "coresight-priv.h"
+#include "coresight-syscfg.h"
 
 static int etm4_set_mode_exclude(struct etmv4_drvdata *drvdata, bool exclude)
 {
@@ -269,6 +270,8 @@ static ssize_t reset_store(struct device *dev,
 
 	spin_unlock(&drvdata->spinlock);
 
+	cscfg_csdev_reset_feats(to_coresight_device(dev));
+
 	return size;
 }
 static DEVICE_ATTR_WO(reset);
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:19:01 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:19:01 +0100
Subject: [PATCH v7 08/10] coresight: config: Add preloaded configurations
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-9-mike.leach@linaro.org>

Preload set of configurations.

This patch creates a small set of preloaded configurations and features
that are available immediately after coresight has been initialised.

The current set provides a strobing feature for ETMv4, that creates a
periodic sampling of trace by switching trace generation on and off
using counters in the ETM.

A configuration called "autofdo" is also provided that uses the 'strobing'
feature and provides a couple of preset values, selectable on the perf
command line.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../hwtracing/coresight/coresight-cfg-afdo.c  | 153 ++++++++++++++++++
 .../coresight/coresight-cfg-preload.c         |  31 ++++
 .../coresight/coresight-cfg-preload.h         |  13 ++
 .../hwtracing/coresight/coresight-etm4x-cfg.h |  15 ++
 .../hwtracing/coresight/coresight-syscfg.c    |   9 ++
 .../hwtracing/coresight/coresight-syscfg.h    |   1 +
 7 files changed, 224 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
 create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 9420d33b23ac..ad44f0fe3069 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,8 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o coresight-syscfg.o coresight-config.o
+		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
+		coresight-cfg-preload.o coresight-cfg-afdo.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-cfg-afdo.c b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
new file mode 100644
index 000000000000..84b31184252b
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-afdo.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-config.h"
+
+/* ETMv4 includes and features */
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
+#include "coresight-etm4x-cfg.h"
+
+/* preload configurations and features */
+
+/* preload in features for ETMv4 */
+
+/* strobe feature */
+static struct cscfg_parameter_desc strobe_params[] = {
+	{
+		.name = "window",
+		.value = 5000,
+	},
+	{
+		.name = "period",
+		.value = 10000,
+	},
+};
+
+static struct cscfg_regval_desc strobe_regs[] = {
+	/* resource selectors */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCRSCTLRn(2),
+		.hw_info = ETM4_CFG_RES_SEL,
+		.val32 = 0x20001,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCRSCTLRn(3),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x20002,
+	},
+	/* strobe window counter 0 - reload from param 0 */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
+		.offset = TRCCNTVRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
+		.offset = TRCCNTRLDVRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCCNTCTLRn(0),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0x10001,
+	},
+	/* strobe period counter 1 - reload from param 1 */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_SAVE,
+		.offset = TRCCNTVRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE | CS_CFG_REG_TYPE_VAL_PARAM,
+		.offset = TRCCNTRLDVRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 1,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCCNTCTLRn(1),
+		.hw_info = ETM4_CFG_RES_CTR,
+		.val32 = 0x8102,
+	},
+	/* sequencer */
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCSEQEVRn(0),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x0081,
+	},
+	{
+		.type = CS_CFG_REG_TYPE_RESOURCE,
+		.offset = TRCSEQEVRn(1),
+		.hw_info = ETM4_CFG_RES_SEQ,
+		.val32 = 0x0000,
+	},
+	/* view-inst */
+	{
+		.type = CS_CFG_REG_TYPE_STD | CS_CFG_REG_TYPE_VAL_MASK,
+		.offset = TRCVICTLR,
+		.val32 = 0x0003,
+		.mask32 = 0x0003,
+	},
+	/* end of regs */
+};
+
+struct cscfg_feature_desc strobe_etm4x = {
+	.name = "strobing",
+	.description = "Generate periodic trace capture windows.\n"
+		       "parameter \'window\': a number of CPU cycles (W)\n"
+		       "parameter \'period\': trace enabled for W cycles every period x W cycles\n",
+	.match_flags = CS_CFG_MATCH_CLASS_SRC_ETM4,
+	.nr_params = ARRAY_SIZE(strobe_params),
+	.params_desc = strobe_params,
+	.nr_regs = ARRAY_SIZE(strobe_regs),
+	.regs_desc = strobe_regs,
+};
+
+/* create an autofdo configuration */
+
+/* we will provide 9 sets of preset parameter values */
+#define AFDO_NR_PRESETS	9
+/* the total number of parameters in used features */
+#define AFDO_NR_PARAMS	ARRAY_SIZE(strobe_params)
+
+static const char *afdo_ref_names[] = {
+	"strobing",
+};
+
+/*
+ * set of presets leaves strobing window constant while varying period to allow
+ * experimentation with mark / space ratios for various workloads
+ */
+static u64 afdo_presets[AFDO_NR_PRESETS][AFDO_NR_PARAMS] = {
+	{ 5000, 2 },
+	{ 5000, 4 },
+	{ 5000, 8 },
+	{ 5000, 16 },
+	{ 5000, 64 },
+	{ 5000, 128 },
+	{ 5000, 512 },
+	{ 5000, 1024 },
+	{ 5000, 4096 },
+};
+
+struct cscfg_config_desc afdo_etm4x = {
+	.name = "autofdo",
+	.description = "Setup ETMs with strobing for autofdo\n"
+	"Supplied presets allow experimentation with mark-space ratio for various loads\n",
+	.nr_feat_refs = ARRAY_SIZE(afdo_ref_names),
+	.feat_ref_names = afdo_ref_names,
+	.nr_presets = AFDO_NR_PRESETS,
+	.nr_total_params = AFDO_NR_PARAMS,
+	.presets = &afdo_presets[0][0],
+};
+
+/* end of ETM4x configurations */
+#endif	/* IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) */
diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.c b/drivers/hwtracing/coresight/coresight-cfg-preload.c
new file mode 100644
index 000000000000..751af3710d56
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-preload.c
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include "coresight-cfg-preload.h"
+#include "coresight-config.h"
+#include "coresight-syscfg.h"
+
+/* Basic features and configurations pre-loaded on initialisation */
+
+static struct cscfg_feature_desc *preload_feats[] = {
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
+	&strobe_etm4x,
+#endif
+	NULL
+};
+
+static struct cscfg_config_desc *preload_cfgs[] = {
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
+	&afdo_etm4x,
+#endif
+	NULL
+};
+
+/* preload called on initialisation */
+int cscfg_preload(void)
+{
+	return cscfg_load_config_sets(preload_cfgs, preload_feats);
+}
diff --git a/drivers/hwtracing/coresight/coresight-cfg-preload.h b/drivers/hwtracing/coresight/coresight-cfg-preload.h
new file mode 100644
index 000000000000..21299e175477
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-cfg-preload.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(C) 2020 Linaro Limited. All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+/* declare preloaded configurations and features */
+
+/* from coresight-cfg-afdo.c - etm 4x features */
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
+extern struct cscfg_feature_desc strobe_etm4x;
+extern struct cscfg_config_desc afdo_etm4x;
+#endif
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
index a204ad9a4792..32dab34c1dac 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.h
@@ -9,6 +9,21 @@
 #include "coresight-config.h"
 #include "coresight-etm4x.h"
 
+/* ETMv4 specific config defines */
+
+/* resource IDs */
+
+#define ETM4_CFG_RES_CTR	0x001
+#define ETM4_CFG_RES_CMP	0x002
+#define ETM4_CFG_RES_CMP_PAIR0	0x003
+#define ETM4_CFG_RES_CMP_PAIR1	0x004
+#define ETM4_CFG_RES_SEL	0x005
+#define ETM4_CFG_RES_SEL_PAIR0	0x006
+#define ETM4_CFG_RES_SEL_PAIR1	0x007
+#define ETM4_CFG_RES_SEQ	0x008
+#define ETM4_CFG_RES_TS		0x009
+#define ETM4_CFG_RES_MASK	0x00F
+
 /* ETMv4 specific config functions */
 int etm4_cscfg_register(struct coresight_device *csdev);
 
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index b234e45c153f..41f742190639 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -709,8 +709,17 @@ int __init cscfg_init(void)
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
 	atomic_set(&cscfg_mgr->sys_active_cnt, 0);
 
+	/* preload built-in configurations */
+	err = cscfg_preload();
+	if (err)
+		goto exit_err;
+
 	dev_info(cscfg_device(), "CoreSight Configuration manager initialised");
 	return 0;
+
+exit_err:
+	cscfg_clear_device();
+	return err;
 }
 
 void cscfg_exit(void)
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index a52775890670..7bb8c8e497ba 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -56,6 +56,7 @@ struct cscfg_registered_csdev {
 /* internal core operations for cscfg */
 int __init cscfg_init(void);
 void cscfg_exit(void);
+int cscfg_preload(void);
 
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:19:02 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:19:02 +0100
Subject: [PATCH v7 09/10] coresight: syscfg: Add initial configfs support
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-10-mike.leach@linaro.org>

Adds configfs subsystem and attributes to the configuration manager
to enable the listing of loaded configurations and features.

The default values of feature parameters can be accessed and altered
from these attributes to affect all installed devices using the feature.

Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile          |   3 +-
 .../coresight/coresight-syscfg-configfs.c     | 396 ++++++++++++++++++
 .../coresight/coresight-syscfg-configfs.h     |  45 ++
 .../hwtracing/coresight/coresight-syscfg.c    |  76 ++++
 .../hwtracing/coresight/coresight-syscfg.h    |   7 +
 5 files changed, 526 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
 create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index ad44f0fe3069..b6c4a48140ec 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -5,7 +5,8 @@
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
 		coresight-sysfs.o coresight-syscfg.o coresight-config.o \
-		coresight-cfg-preload.o coresight-cfg-afdo.o
+		coresight-cfg-preload.o coresight-cfg-afdo.o \
+		coresight-syscfg-configfs.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.c b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
new file mode 100644
index 000000000000..c547816b9000
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Linaro Limited, All rights reserved.
+ * Author: Mike Leach <mike.leach at linaro.org>
+ */
+
+#include <linux/configfs.h>
+
+#include "coresight-syscfg-configfs.h"
+
+/* create a default ci_type. */
+static inline struct config_item_type *cscfg_create_ci_type(void)
+{
+	struct config_item_type *ci_type;
+
+	ci_type = devm_kzalloc(cscfg_device(), sizeof(*ci_type), GFP_KERNEL);
+	if (ci_type)
+		ci_type->ct_owner = THIS_MODULE;
+
+	return ci_type;
+}
+
+/* configurations sub-group */
+
+/* attributes for the config view group */
+static ssize_t cscfg_cfg_description_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
+							 struct cscfg_fs_config, group);
+
+	return scnprintf(page, PAGE_SIZE, "%s", fs_config->config_desc->description);
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, description);
+
+static ssize_t cscfg_cfg_feature_refs_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_config *fs_config = container_of(to_config_group(item),
+							 struct cscfg_fs_config, group);
+	const struct cscfg_config_desc *config_desc = fs_config->config_desc;
+	ssize_t ch_used = 0;
+	int i;
+
+	for (i = 0; i < config_desc->nr_feat_refs; i++)
+		ch_used += scnprintf(page + ch_used, PAGE_SIZE - ch_used,
+				     "%s\n", config_desc->feat_ref_names[i]);
+	return ch_used;
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, feature_refs);
+
+/* list preset values in order of features and params */
+static ssize_t cscfg_cfg_values_show(struct config_item *item, char *page)
+{
+	const struct cscfg_feature_desc *feat_desc;
+	const struct cscfg_config_desc *config_desc;
+	struct cscfg_fs_preset *fs_preset;
+	int i, j, val_idx, preset_idx;
+	ssize_t used = 0;
+
+	fs_preset = container_of(to_config_group(item), struct cscfg_fs_preset, group);
+	config_desc = fs_preset->config_desc;
+
+	if (!config_desc->nr_presets)
+		return 0;
+
+	preset_idx = fs_preset->preset_num - 1;
+
+	/* start index on the correct array line */
+	val_idx = config_desc->nr_total_params * preset_idx;
+
+	/*
+	 * A set of presets is the sum of all params in used features,
+	 * in order of declaration of features and params in the features
+	 */
+	for (i = 0; i < config_desc->nr_feat_refs; i++) {
+		feat_desc = cscfg_get_named_feat_desc(config_desc->feat_ref_names[i]);
+		for (j = 0; j < feat_desc->nr_params; j++) {
+			used += scnprintf(page + used, PAGE_SIZE - used,
+					  "%s.%s = 0x%llx ",
+					  feat_desc->name,
+					  feat_desc->params_desc[j].name,
+					  config_desc->presets[val_idx++]);
+		}
+	}
+	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
+
+	return used;
+}
+CONFIGFS_ATTR_RO(cscfg_cfg_, values);
+
+static struct configfs_attribute *cscfg_config_view_attrs[] = {
+	&cscfg_cfg_attr_description,
+	&cscfg_cfg_attr_feature_refs,
+	NULL,
+};
+
+static struct config_item_type cscfg_config_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_config_view_attrs,
+};
+
+static struct configfs_attribute *cscfg_config_preset_attrs[] = {
+	&cscfg_cfg_attr_values,
+	NULL,
+};
+
+static struct config_item_type cscfg_config_preset_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_config_preset_attrs,
+};
+
+static int cscfg_add_preset_groups(struct cscfg_fs_config *cfg_view)
+{
+	int preset_num;
+	struct cscfg_fs_preset *cfg_fs_preset;
+	struct cscfg_config_desc *config_desc = cfg_view->config_desc;
+	char name[CONFIGFS_ITEM_NAME_LEN];
+
+	if (!config_desc->nr_presets)
+		return 0;
+
+	for (preset_num = 1; preset_num <= config_desc->nr_presets; preset_num++) {
+		cfg_fs_preset = devm_kzalloc(cscfg_device(),
+					     sizeof(struct cscfg_fs_preset), GFP_KERNEL);
+
+		if (!cfg_fs_preset)
+			return -ENOMEM;
+
+		snprintf(name, CONFIGFS_ITEM_NAME_LEN, "preset%d", preset_num);
+		cfg_fs_preset->preset_num = preset_num;
+		cfg_fs_preset->config_desc = cfg_view->config_desc;
+		config_group_init_type_name(&cfg_fs_preset->group, name,
+					    &cscfg_config_preset_type);
+		configfs_add_default_group(&cfg_fs_preset->group, &cfg_view->group);
+	}
+	return 0;
+}
+
+static struct config_group *cscfg_create_config_group(struct cscfg_config_desc *config_desc)
+{
+	struct cscfg_fs_config *cfg_view;
+	struct device *dev = cscfg_device();
+	int err;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	cfg_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_config), GFP_KERNEL);
+	if (!cfg_view)
+		return ERR_PTR(-ENOMEM);
+
+	cfg_view->config_desc = config_desc;
+	config_group_init_type_name(&cfg_view->group, config_desc->name, &cscfg_config_view_type);
+
+	/* add in a preset<n> dir for each preset */
+	err = cscfg_add_preset_groups(cfg_view);
+	if (err)
+		return ERR_PTR(err);
+
+	return &cfg_view->group;
+}
+
+/* attributes for features view */
+
+static ssize_t cscfg_feat_description_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+
+	return scnprintf(page, PAGE_SIZE, "%s", fs_feat->feat_desc->description);
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, description);
+
+static ssize_t cscfg_feat_matches_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+	u32 match_flags = fs_feat->feat_desc->match_flags;
+	int used = 0;
+
+	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ALL)
+		used = scnprintf(page, PAGE_SIZE, "SRC_ALL ");
+
+	if (match_flags & CS_CFG_MATCH_CLASS_SRC_ETM4)
+		used += scnprintf(page + used, PAGE_SIZE - used, "SRC_ETMV4 ");
+
+	used += scnprintf(page + used, PAGE_SIZE - used, "\n");
+	return used;
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, matches);
+
+static ssize_t cscfg_feat_nr_params_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_feature *fs_feat = container_of(to_config_group(item),
+							struct cscfg_fs_feature, group);
+
+	return scnprintf(page, PAGE_SIZE, "%d\n", fs_feat->feat_desc->nr_params);
+}
+CONFIGFS_ATTR_RO(cscfg_feat_, nr_params);
+
+/* base feature desc attrib structures */
+static struct configfs_attribute *cscfg_feature_view_attrs[] = {
+	&cscfg_feat_attr_description,
+	&cscfg_feat_attr_matches,
+	&cscfg_feat_attr_nr_params,
+	NULL,
+};
+
+static struct config_item_type cscfg_feature_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_feature_view_attrs,
+};
+
+static ssize_t cscfg_param_value_show(struct config_item *item, char *page)
+{
+	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
+							 struct cscfg_fs_param, group);
+	u64 value = param_item->feat_desc->params_desc[param_item->param_idx].value;
+
+	return scnprintf(page, PAGE_SIZE, "0x%llx\n", value);
+}
+
+static ssize_t cscfg_param_value_store(struct config_item *item,
+				       const char *page, size_t size)
+{
+	struct cscfg_fs_param *param_item = container_of(to_config_group(item),
+							 struct cscfg_fs_param, group);
+	struct cscfg_feature_desc *feat_desc = param_item->feat_desc;
+	int param_idx = param_item->param_idx;
+	u64 value;
+	int err;
+
+	err = kstrtoull(page, 0, &value);
+	if (!err)
+		err = cscfg_update_feat_param_val(feat_desc, param_idx, value);
+
+	return err ? err : size;
+}
+CONFIGFS_ATTR(cscfg_param_, value);
+
+static struct configfs_attribute *cscfg_param_view_attrs[] = {
+	&cscfg_param_attr_value,
+	NULL,
+};
+
+static struct config_item_type cscfg_param_view_type = {
+	.ct_owner = THIS_MODULE,
+	.ct_attrs = cscfg_param_view_attrs,
+};
+
+/*
+ * configfs has far less functionality provided to add attributes dynamically than sysfs,
+ * and the show and store fns pass the enclosing config_item so the actual attribute cannot
+ * be determined. Therefore we add each item as a group directory, with a value attribute.
+ */
+static int cscfg_create_params_group_items(struct cscfg_feature_desc *feat_desc,
+					   struct config_group *params_group)
+{
+	struct device *dev = cscfg_device();
+	struct cscfg_fs_param *param_item;
+	int i;
+
+	/* parameter items - as groups with default_value attribute */
+	for (i = 0; i < feat_desc->nr_params; i++) {
+		param_item = devm_kzalloc(dev, sizeof(struct cscfg_fs_param), GFP_KERNEL);
+		if (!param_item)
+			return -ENOMEM;
+		param_item->feat_desc = feat_desc;
+		param_item->param_idx = i;
+		config_group_init_type_name(&param_item->group,
+					    feat_desc->params_desc[i].name,
+					    &cscfg_param_view_type);
+		configfs_add_default_group(&param_item->group, params_group);
+	}
+	return 0;
+}
+
+static struct config_group *cscfg_create_feature_group(struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_fs_feature *feat_view;
+	struct config_item_type *params_group_type;
+	struct config_group *params_group = NULL;
+	struct device *dev = cscfg_device();
+	int item_err;
+
+	if (!dev)
+		return ERR_PTR(-EINVAL);
+
+	feat_view = devm_kzalloc(dev, sizeof(struct cscfg_fs_feature), GFP_KERNEL);
+	if (!feat_view)
+		return ERR_PTR(-ENOMEM);
+
+	if (feat_desc->nr_params) {
+		params_group = devm_kzalloc(dev, sizeof(struct config_group), GFP_KERNEL);
+		if (!params_group)
+			return ERR_PTR(-ENOMEM);
+
+		params_group_type = cscfg_create_ci_type();
+		if (!params_group_type)
+			return ERR_PTR(-ENOMEM);
+	}
+
+	feat_view->feat_desc = feat_desc;
+	config_group_init_type_name(&feat_view->group,
+				    feat_desc->name,
+				    &cscfg_feature_view_type);
+	if (params_group) {
+		config_group_init_type_name(params_group, "params", params_group_type);
+		configfs_add_default_group(params_group, &feat_view->group);
+		item_err = cscfg_create_params_group_items(feat_desc, params_group);
+		if (item_err)
+			return ERR_PTR(item_err);
+	}
+	return &feat_view->group;
+}
+
+static struct config_item_type cscfg_configs_type = {
+	.ct_owner = THIS_MODULE,
+};
+
+static struct config_group cscfg_configs_grp = {
+	.cg_item = {
+		.ci_namebuf = "configurations",
+		.ci_type = &cscfg_configs_type,
+	},
+};
+
+/* add configuration to configurations group */
+int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc)
+{
+	struct config_group *new_group;
+	int err;
+
+	new_group = cscfg_create_config_group(config_desc);
+	if (IS_ERR(new_group))
+		return PTR_ERR(new_group);
+	err =  configfs_register_group(&cscfg_configs_grp, new_group);
+	return err;
+}
+
+static struct config_item_type cscfg_features_type = {
+	.ct_owner = THIS_MODULE,
+};
+
+static struct config_group cscfg_features_grp = {
+	.cg_item = {
+		.ci_namebuf = "features",
+		.ci_type = &cscfg_features_type,
+	},
+};
+
+/* add feature to features group */
+int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc)
+{
+	struct config_group *new_group;
+	int err;
+
+	new_group = cscfg_create_feature_group(feat_desc);
+	if (IS_ERR(new_group))
+		return PTR_ERR(new_group);
+	err =  configfs_register_group(&cscfg_features_grp, new_group);
+	return err;
+}
+
+int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr)
+{
+	struct configfs_subsystem *subsys;
+	struct config_item_type *ci_type;
+
+	if (!cscfg_mgr)
+		return -EINVAL;
+
+	ci_type = cscfg_create_ci_type();
+	if (!ci_type)
+		return -ENOMEM;
+
+	subsys = &cscfg_mgr->cfgfs_subsys;
+	config_item_set_name(&subsys->su_group.cg_item, CSCFG_FS_SUBSYS_NAME);
+	subsys->su_group.cg_item.ci_type = ci_type;
+
+	config_group_init(&subsys->su_group);
+	mutex_init(&subsys->su_mutex);
+
+	/* Add default groups to subsystem */
+	config_group_init(&cscfg_configs_grp);
+	configfs_add_default_group(&cscfg_configs_grp, &subsys->su_group);
+
+	config_group_init(&cscfg_features_grp);
+	configfs_add_default_group(&cscfg_features_grp, &subsys->su_group);
+
+	return configfs_register_subsystem(subsys);
+}
+
+void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr)
+{
+	configfs_unregister_subsystem(&cscfg_mgr->cfgfs_subsys);
+}
diff --git a/drivers/hwtracing/coresight/coresight-syscfg-configfs.h b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
new file mode 100644
index 000000000000..7d6ffe35ca4c
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-syscfg-configfs.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Coresight system configuration driver - support for configfs.
+ */
+
+#ifndef CORESIGHT_SYSCFG_CONFIGFS_H
+#define CORESIGHT_SYSCFG_CONFIGFS_H
+
+#include <linux/configfs.h>
+#include "coresight-syscfg.h"
+
+#define CSCFG_FS_SUBSYS_NAME "cs-syscfg"
+
+/* container for configuration view */
+struct cscfg_fs_config {
+	struct cscfg_config_desc *config_desc;
+	struct config_group group;
+};
+
+/* container for feature view */
+struct cscfg_fs_feature {
+	struct cscfg_feature_desc *feat_desc;
+	struct config_group group;
+};
+
+/* container for parameter view */
+struct cscfg_fs_param {
+	int param_idx;
+	struct cscfg_feature_desc *feat_desc;
+	struct config_group group;
+};
+
+/* container for preset view */
+struct cscfg_fs_preset {
+	int preset_num;
+	struct cscfg_config_desc *config_desc;
+	struct config_group group;
+};
+
+int cscfg_configfs_init(struct cscfg_manager *cscfg_mgr);
+void cscfg_configfs_release(struct cscfg_manager *cscfg_mgr);
+int cscfg_configfs_add_config(struct cscfg_config_desc *config_desc);
+int cscfg_configfs_add_feature(struct cscfg_feature_desc *feat_desc);
+
+#endif /* CORESIGHT_SYSCFG_CONFIGFS_H */
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 41f742190639..180202402eb5 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -9,6 +9,7 @@
 #include "coresight-config.h"
 #include "coresight-etm-perf.h"
 #include "coresight-syscfg.h"
+#include "coresight-syscfg-configfs.h"
 
 /*
  * cscfg_ API manages configurations and features for the entire coresight
@@ -287,6 +288,72 @@ static int cscfg_load_config(struct cscfg_config_desc *config_desc)
 	return 0;
 }
 
+/* get a feature descriptor by name */
+const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name)
+{
+	const struct cscfg_feature_desc *feat_desc = NULL, *feat_desc_item;
+
+	mutex_lock(&cscfg_mutex);
+
+	list_for_each_entry(feat_desc_item, &cscfg_mgr->feat_desc_list, item) {
+		if (strcmp(feat_desc_item->name, name) == 0) {
+			feat_desc = feat_desc_item;
+			break;
+		}
+	}
+
+	mutex_unlock(&cscfg_mutex);
+	return feat_desc;
+}
+
+/* called with cscfg_mutex held */
+static struct cscfg_feature_csdev *
+cscfg_csdev_get_feat_from_desc(struct coresight_device *csdev,
+			       struct cscfg_feature_desc *feat_desc)
+{
+	struct cscfg_feature_csdev *feat_csdev;
+
+	list_for_each_entry(feat_csdev, &csdev->feature_csdev_list, node) {
+		if (feat_csdev->feat_desc == feat_desc)
+			return feat_csdev;
+	}
+	return NULL;
+}
+
+int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
+				int param_idx, u64 value)
+{
+	int err = 0;
+	struct cscfg_feature_csdev *feat_csdev;
+	struct cscfg_registered_csdev *csdev_item;
+
+	mutex_lock(&cscfg_mutex);
+
+	/* check if any config active & return busy */
+	if (atomic_read(&cscfg_mgr->sys_active_cnt)) {
+		err = -EBUSY;
+		goto unlock_exit;
+	}
+
+	/* set the value */
+	if ((param_idx < 0) || (param_idx >= feat_desc->nr_params)) {
+		err = -EINVAL;
+		goto unlock_exit;
+	}
+	feat_desc->params_desc[param_idx].value = value;
+
+	/* update loaded instances.*/
+	list_for_each_entry(csdev_item, &cscfg_mgr->csdev_desc_list, item) {
+		feat_csdev = cscfg_csdev_get_feat_from_desc(csdev_item->csdev, feat_desc);
+		if (feat_csdev)
+			feat_csdev->params_csdev[param_idx].current_value = value;
+	}
+
+unlock_exit:
+	mutex_unlock(&cscfg_mutex);
+	return err;
+}
+
 /**
  * cscfg_load_config_sets - API function to load feature and config sets.
  *
@@ -308,6 +375,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 	if (feat_descs) {
 		while (feat_descs[i]) {
 			err = cscfg_load_feat(feat_descs[i]);
+			if (!err)
+				err = cscfg_configfs_add_feature(feat_descs[i]);
 			if (err) {
 				pr_err("coresight-syscfg: Failed to load feature %s\n",
 				       feat_descs[i]->name);
@@ -322,6 +391,8 @@ int cscfg_load_config_sets(struct cscfg_config_desc **config_descs,
 	if (config_descs) {
 		while (config_descs[i]) {
 			err = cscfg_load_config(config_descs[i]);
+			if (!err)
+				err = cscfg_configfs_add_config(config_descs[i]);
 			if (err) {
 				pr_err("coresight-syscfg: Failed to load configuration %s\n",
 				       config_descs[i]->name);
@@ -691,6 +762,7 @@ static void cscfg_clear_device(void)
 	list_for_each_entry(cfg_desc, &cscfg_mgr->config_desc_list, item) {
 		etm_perf_del_symlink_cscfg(cfg_desc);
 	}
+	cscfg_configfs_release(cscfg_mgr);
 	device_unregister(cscfg_device());
 	mutex_unlock(&cscfg_mutex);
 }
@@ -704,6 +776,10 @@ int __init cscfg_init(void)
 	if (err)
 		return err;
 
+	err = cscfg_configfs_init(cscfg_mgr);
+	if (err)
+		goto exit_err;
+
 	INIT_LIST_HEAD(&cscfg_mgr->csdev_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->feat_desc_list);
 	INIT_LIST_HEAD(&cscfg_mgr->config_desc_list);
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.h b/drivers/hwtracing/coresight/coresight-syscfg.h
index 7bb8c8e497ba..8d018efd6ead 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.h
+++ b/drivers/hwtracing/coresight/coresight-syscfg.h
@@ -6,6 +6,7 @@
 #ifndef CORESIGHT_SYSCFG_H
 #define CORESIGHT_SYSCFG_H
 
+#include <linux/configfs.h>
 #include <linux/coresight.h>
 #include <linux/device.h>
 
@@ -25,6 +26,7 @@
  * @feat_desc_list:	List of feature descriptors to load into registered devices.
  * @config_desc_list:	List of system configuration descriptors to load into registered devices.
  * @sys_active_cnt:	Total number of active config descriptor references.
+ * @cfgfs_subsys:	configfs subsystem used to manage configurations.
  */
 struct cscfg_manager {
 	struct device dev;
@@ -32,6 +34,7 @@ struct cscfg_manager {
 	struct list_head feat_desc_list;
 	struct list_head config_desc_list;
 	atomic_t sys_active_cnt;
+	struct configfs_subsystem cfgfs_subsys;
 };
 
 /* get reference to dev in cscfg_manager */
@@ -57,6 +60,10 @@ struct cscfg_registered_csdev {
 int __init cscfg_init(void);
 void cscfg_exit(void);
 int cscfg_preload(void);
+const struct cscfg_feature_desc *cscfg_get_named_feat_desc(const char *name);
+int cscfg_update_feat_param_val(struct cscfg_feature_desc *feat_desc,
+				int param_idx, u64 value);
+
 
 /* syscfg manager external API */
 int cscfg_load_config_sets(struct cscfg_config_desc **cfg_descs,
-- 
2.17.1



From mike.leach at linaro.org  Wed Apr 14 20:19:03 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:19:03 +0100
Subject: [PATCH v7 10/10] Documentation: coresight: Add documentation for
 CoreSight config
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210414191903.18349-11-mike.leach@linaro.org>

Adds documentation for the CoreSight System configuration manager.

Cc: Jonathan Corbet <corbet at lwn.net>
Cc: linux-doc at vger.kernel.org
Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 .../trace/coresight/coresight-config.rst      | 244 ++++++++++++++++++
 Documentation/trace/coresight/coresight.rst   |  16 ++
 2 files changed, 260 insertions(+)
 create mode 100644 Documentation/trace/coresight/coresight-config.rst

diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst
new file mode 100644
index 000000000000..a4e3ef295240
--- /dev/null
+++ b/Documentation/trace/coresight/coresight-config.rst
@@ -0,0 +1,244 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+CoreSight System Configuration Manager
+======================================
+
+    :Author:   Mike Leach <mike.leach at linaro.org>
+    :Date:     October 2020
+
+Introduction
+============
+
+The CoreSight System Configuration manager is an API that allows the
+programming of the CoreSight system with pre-defined configurations that
+can then be easily enabled from sysfs or perf.
+
+Many CoreSight components can be programmed in complex ways - especially ETMs.
+In addition, components can interact across the CoreSight system, often via
+the cross trigger components such as CTI and CTM. These system settings can
+be defined and enabled as named configurations.
+
+
+Basic Concepts
+==============
+
+This section introduces the basic concepts of a CoreSight system configuration.
+
+
+Features
+--------
+
+A feature is a named set of programming for a CoreSight device. The programming
+is device dependent, and can be defined in terms of absolute register values,
+resource usage and parameter values.
+
+The feature is defined using a descriptor. This descriptor is used to load onto
+a matching device, either when the feature is loaded into the system, or when the
+CoreSight device is registered with the configuration manager.
+
+The load process involves interpreting the descriptor into a set of register
+accesses in the driver - the resource usage and parameter descriptions
+translated into appropriate register accesses. This interpretation makes it easy
+and efficient for the feature to be programmed onto the device when required.
+
+The feature will not be active on the device until the feature is enabled, and
+the device itself is enabled. When the device is enabled then enabled features
+will be programmed into the device hardware.
+
+A feature is enabled as part of a configuration being enabled on the system.
+
+
+Parameter Value
+~~~~~~~~~~~~~~~
+
+A parameter value is a named value that may be set by the user prior to the
+feature being enabled that can adjust the behaviour of the operation programmed
+by the feature.
+
+For example, this could be a count value in a programmed operation that repeats
+at a given rate. When the feature is enabled then the current value of the
+parameter is used in programming the device.
+
+The feature descriptor defines a default value for a parameter, which is used
+if the user does not supply a new value.
+
+Users can update parameter values using the configfs API for the CoreSight
+system - which is described below.
+
+The current value of the parameter is loaded into the device when the feature
+is enabled on that device.
+
+
+Configurations
+--------------
+
+A configuration defines a set of features that are to be used in a trace
+session where the configuration is selected. For any trace session only one
+configuration may be selected.
+
+The features defined may be on any type of device that is registered
+to support system configuration. A configuration may select features to be
+enabled on a class of devices - i.e. any ETMv4, or specific devices, e.g. a
+specific CTI on the system.
+
+As with the feature, a descriptor is used to define the configuration.
+This will define the features that must be enabled as part of the configuration
+as well as any preset values that can be used to override default parameter
+values.
+
+
+Preset Values
+~~~~~~~~~~~~~
+
+Preset values are easily selectable sets of parameter values for the features
+that the configuration uses. The number of values in a single preset set, equals
+the sum of parameter values in the features used by the configuration.
+
+e.g. a configuration consists of 3 features, one has 2 parameters, one has
+a single parameter, and another has no parameters. A single preset set will
+therefore have 3 values.
+
+Presets are optionally defined by the configuration, up to 15 can be defined.
+If no preset is selected, then the parameter values defined in the feature
+are used as normal.
+
+
+Operation
+~~~~~~~~~
+
+The following steps take place in the operation of a configuration.
+
+1) In this example, the configuration is 'autofdo', which has an
+   associated feature 'strobing' that works on ETMv4 CoreSight Devices.
+
+2) The configuration is enabled. For example 'perf' may select the
+   configuration as part of its command line::
+
+    perf record -e cs_etm/autofdo/ myapp
+
+   which will enable the 'autofdo' configuration.
+
+3) perf starts tracing on the system. As each ETMv4 that perf uses for
+   trace is enabled,  the configuration manager will check if the ETMv4
+   has a feature that relates to the currently active configuration.
+   In this case 'strobing' is enabled & programmed into the ETMv4.
+
+4) When the ETMv4 is disabled, any registers marked as needing to be
+   saved will be read back.
+
+5) At the end of the perf session, the configuration will be disabled.
+
+
+Viewing Configurations and Features
+===================================
+
+The set of configurations and features that are currently loaded into the
+system can be viewed using the configfs API.
+
+Mount configfs as normal and the 'cs-syscfg' subsystem will appear::
+
+    $ ls /config
+    cs-syscfg  stp-policy
+
+This has two sub-directories::
+
+    $ cd cs-syscfg/
+    $ ls
+    configurations  features
+
+The system has the configuration 'autofdo' built in. It may be examined as
+follows::
+
+    $ cd configurations/
+    $ ls
+    autofdo
+    $ cd autofdo/
+    $ ls
+    description   preset1  preset3  preset5  preset7  preset9
+    feature_refs  preset2  preset4  preset6  preset8
+    $ cat description
+    Setup ETMs with strobing for autofdo
+    $ cat feature_refs
+    strobing
+
+Each preset declared has a preset<n> subdirectory declared. The values for
+the preset can be examined::
+
+    $ cat preset1/values
+    strobing.window = 0x1388 strobing.period = 0x2
+    $ cat preset2/values
+    strobing.window = 0x1388 strobing.period = 0x4
+
+The features referenced by the configuration can be examined in the features
+directory::
+
+    $ cd ../../features/strobing/
+    $ ls
+    description  matches  nr_params  params
+    $ cat description
+    Generate periodic trace capture windows.
+    parameter 'window': a number of CPU cycles (W)
+    parameter 'period': trace enabled for W cycles every period x W cycles
+    $ cat matches
+    SRC_ETMV4
+    $ cat nr_params
+    2
+
+Move to the params directory to examine and adjust parameters::
+
+    cd params
+    $ ls
+    period  window
+    $ cd period
+    $ ls
+    value
+    $ cat value
+    0x2710
+    # echo 15000 > value
+    # cat value
+    0x3a98
+
+Parameters adjusted in this way are reflected in all device instances that have
+loaded the feature.
+
+
+Using Configurations in perf
+============================
+
+The configurations loaded into the CoreSight configuration management are
+also declared in the perf 'cs_etm' event infrastructure so that they can
+be selected when running trace under perf::
+
+    $ ls /sys/devices/cs_etm
+    configurations  format  perf_event_mux_interval_ms  sinks  type
+    events  nr_addr_filters  power
+
+Key directories here are 'configurations' - which lists the loaded
+configurations, and 'events' - a generic perf directory which allows
+selection on the perf command line.::
+
+    $ ls configurations/
+    autofdo
+    $ cat configurations/autofdo
+    0xa7c3dddd
+
+As with the sinks entries, this provides a hash of the configuration name.
+The entry in the 'events' directory uses perfs built in syntax generator
+to substitute the syntax for the name when evaluating the command::
+
+    $ ls events/
+    autofdo
+    $ cat events/autofdo
+    configid=0xa7c3dddd
+
+The 'autofdo' configuration may be selected on the perf command line::
+
+    $ perf record -e cs_etm/autofdo/u --per-thread <application>
+
+A preset to override the current parameter values can also be selected::
+
+    $ perf record -e cs_etm/autofdo,preset=1/u --per-thread <application>
+
+When configurations are selected in this way, then the trace sink used is
+automatically selected.
diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
index 169749efd8d1..7ec656c9f0dc 100644
--- a/Documentation/trace/coresight/coresight.rst
+++ b/Documentation/trace/coresight/coresight.rst
@@ -619,6 +619,20 @@ A separate documentation file is provided to explain the use of these devices.
 (:doc:`coresight-ect`) [#fourth]_.
 
 
+CoreSight System Configuration
+------------------------------
+
+CoreSight components can be complex devices with many programming options.
+Furthermore, components can be programmed to interact with each other across the
+complete system.
+
+A CoreSight System Configuration manager is provided to allow these complex programming
+configurations to be selected and used easily from perf and sysfs.
+
+See the separate document for further information.
+(:doc:`coresight-config`) [#fifth]_.
+
+
 .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 
 .. [#second] Documentation/trace/stm.rst
@@ -626,3 +640,5 @@ A separate documentation file is provided to explain the use of these devices.
 .. [#third] https://github.com/Linaro/perf-opencsd
 
 .. [#fourth] Documentation/trace/coresight/coresight-ect.rst
+
+.. [#fifth] Documentation/trace/coresight/coresight-config.rst
-- 
2.17.1



From geert at linux-m68k.org  Wed Apr 14 20:21:38 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 14 Apr 2021 21:21:38 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
Message-ID: <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>

Hi Andy,

On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
> On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> > > > > On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> > > > > > The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> > > > > > Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> > > > > > Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> > > > > > about this driver when configuring a kernel without Hisilicon platform
> > > > > > or ACPI firmware support.
> > > > >
> > > > > this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> > > > > not sure all the platform this IP on has ARCH_HISI configured. The driver
> > > > > will not be compiled by default config. This is not correct to have
> > > > > this dependence.
> > > >
> > > > Thanks for your answer!
> > > >
> > > > I guess it's still fine to add a dependency on ACPI?
> > >
> > > But why?
> >
> > Please tell me how/when the driver is used when CONFIG_ACPI=n.
>
> I'm not using it at all. Ask the author :-)
>
> But if we follow your logic, then we need to mark all the _platform_ drivers
> for x86 world as ACPI dependent? This sounds ugly.

Do all other x86 platform drivers have (1) an .acpi_match_table[] and
(2) no other way of instantiating their devices?
The first driver from the top of my memory I looked at is rtc-cmos:
it has no .acpi_match_table[], and the rtc-cmos device is instantiated
from arch/x86/kernel/rtc.c.

For drivers with only an .of_match_table(), and no legacy users
instantiating platform devices, we do have dependencies on OF.

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 ndesaulniers at google.com  Wed Apr 14 20:22:17 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Wed, 14 Apr 2021 12:22:17 -0700
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn, endif}
In-Reply-To: <20210414000803.662534-1-nathan@kernel.org>
References: <20210414000803.662534-1-nathan@kernel.org>
Message-ID: <CAKwvOdmHA-5BLVMTViJuuqnHTLnVHaJeHf7M0nbfscxPFKYSPQ@mail.gmail.com>

On Tue, Apr 13, 2021 at 5:09 PM Nathan Chancellor <nathan at kernel.org> wrote:
>
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
>
> <instantiation>:5:7: error: expected assembly-time absolute expression
>  .org . - (664b-663b) + (662b-661b)
>       ^
> <instantiation>:6:7: error: expected assembly-time absolute expression
>  .org . - (662b-661b) + (664b-663b)
>       ^
>
> The root cause is LLVM's assembler has a one-pass design, meaning it
> cannot figure out these instruction lengths when the .org directive is
> outside of the subsection that they are in, which was changed by the
> .arch_extension directive added in the above commit.
>
> Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
> length validation inside the subsection") to the alternative_endif
> macro, shuffling the .org directives so that the length validation
> happen will always happen in the same subsections. alternative_insn has
> not shown any issue yet but it appears that it could have the same issue
> in the future so just preemptively change it.

Thanks Nathan.
Reviewed-by: Nick Desaulniers <ndesaulniers at google.com>
Tested-by: Nick Desaulniers <ndesaulniers at google.com>

I did some additional disassembly comparison.  In case we ever need it
again, I'll copy it below for posterity.

$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu make LLVM=1 LLVM_IAS=1
-j72 O=/tmp/a defconfig all
$ b4 am https://lore.kernel.org/lkml/20210414000803.662534-1-nathan at kernel.org/
-o - | git am -3
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu make LLVM=1 LLVM_IAS=1
-j72 O=/tmp/b defconfig all
$ for f in $(find /tmp/a/arch/arm64 -name \*.o); do llvm-objdump -dr
$f > $f.txt; done
$ for f in $(find /tmp/b/arch/arm64 -name \*.o); do llvm-objdump -dr
$f > $f.txt; done
$ for f in $(find /tmp/a/arch/arm64 -name \*.o); do diff -u $f.txt
$(echo $f.txt|sed 's/a/b/'); done | less

For no difference.  You can check more sections than .text by changing
`-d` to `-D` for llvm-objdump, though you're going to get a lot of
noise related to changes in .strtab and relocations referring to debug
info (.debug_str).  But if I drop your patch, rebuild, and recompare,
I see the same differences.

>
> Cc: stable at vger.kernel.org
> Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1347
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>
> ---
>
> Apologies if my explanation or terminology is off, I am only now getting
> more familiar with assembly.
>
>  arch/arm64/include/asm/alternative-macros.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/alternative-macros.h b/arch/arm64/include/asm/alternative-macros.h
> index 5df500dcc627..8a078fc662ac 100644
> --- a/arch/arm64/include/asm/alternative-macros.h
> +++ b/arch/arm64/include/asm/alternative-macros.h
> @@ -97,9 +97,9 @@
>         .popsection
>         .subsection 1
>  663:   \insn2
> -664:   .previous
> -       .org    . - (664b-663b) + (662b-661b)
> +664:   .org    . - (664b-663b) + (662b-661b)
>         .org    . - (662b-661b) + (664b-663b)
> +       .previous
>         .endif
>  .endm
>
> @@ -169,11 +169,11 @@
>   */
>  .macro alternative_endif
>  664:
> +       .org    . - (664b-663b) + (662b-661b)
> +       .org    . - (662b-661b) + (664b-663b)
>         .if .Lasm_alt_mode==0
>         .previous
>         .endif
> -       .org    . - (664b-663b) + (662b-661b)
> -       .org    . - (662b-661b) + (664b-663b)
>  .endm
>
>  /*
>
> base-commit: 738fa58ee1328481d1d7889e7c430b3401c571b9
> --
> 2.31.1.272.g89b43f80a5
>


-- 
Thanks,
~Nick Desaulniers


From helgaas at kernel.org  Wed Apr 14 20:46:54 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 14 Apr 2021 14:46:54 -0500
Subject: [PATCH v10 3/3] PCI: uniphier: Add misc interrupt handler to
 invoke PME and AER
In-Reply-To: <1617985338-19648-4-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <20210414194654.GA2526782@bjorn-Precision-5520>

On Sat, Apr 10, 2021 at 01:22:18AM +0900, Kunihiko Hayashi wrote:
> This patch adds misc interrupt handler to detect and invoke PME/AER event.
> 
> In UniPhier PCIe controller, PME/AER signals are assigned to the same
> signal as MSI by the internal logic. These signals should be detected by
> the internal register, however, DWC MSI handler can't handle these signals.
> 
> DWC MSI handler calls .msi_host_isr() callback function, that detects
> PME/AER signals using the internal register and invokes the interrupt
> with PME/AER vIRQ numbers.
> 
> These vIRQ numbers is obtained by uniphier_pcie_port_get_irq() function,
> that finds the device that matches PME/AER from the devices associated
> with Root Port, and returns its vIRQ number.

Why do you use the term "vIRQ"?  What exactly is a vIRQ?  It seems no
different than the simple "irq" as stored in pci_dev.irq or
pcie_device.irq and passed to generic_handle_irq().  "virq" is also
used in the patch, so if you change one, please change the other as
well.

Bjorn


From mike.leach at linaro.org  Wed Apr 14 20:48:08 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Wed, 14 Apr 2021 20:48:08 +0100
Subject: [PATCH] coresight: etm-perf: Fix define build issue when built as
 module
Message-ID: <20210414194808.22872-1-mike.leach@linaro.org>

CONFIG_CORESIGHT_SOURCE_ETM4X is undefined when built as module,
CONFIG_CORESIGHT_SOURCE_ETM4X_MODULE is defined instead.

Therefore code in format_attr_contextid_show() not correctly complied
when coresight built as module.

Use IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) to correct this.

Fixes: 88f11864cf1d ("coresight: etm-perf: Support PID tracing for kernel at EL2")
Signed-off-by: Mike Leach <mike.leach at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 560baefdfed8..b2d6db78a025 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -78,7 +78,7 @@ static ssize_t format_attr_contextid_show(struct device *dev,
 {
 	int pid_fmt = ETM_OPT_CTXTID;
 
-#if defined(CONFIG_CORESIGHT_SOURCE_ETM4X)
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
 	pid_fmt = is_kernel_in_hyp_mode() ? ETM_OPT_CTXTID2 : ETM_OPT_CTXTID;
 #endif
 	return sprintf(page, "config:%d\n", pid_fmt);
-- 
2.17.1



From patchwork-bot+netdevbpf at kernel.org  Wed Apr 14 21:00:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 14 Apr 2021 20:00:10 +0000
Subject: [PATCH net-next v4 1/1] net: stmmac: Add support for external
 trigger timestamping
In-Reply-To: <20210414001617.3490-1-vee.khee.wong@linux.intel.com>
References: <20210414001617.3490-1-vee.khee.wong@linux.intel.com>
Message-ID: <161843041077.5559.2620169684665757690.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Wed, 14 Apr 2021 08:16:17 +0800 you wrote:
> From: Tan Tee Min <tee.min.tan at intel.com>
> 
> The Synopsis MAC controller supports auxiliary snapshot feature that
> allows user to store a snapshot of the system time based on an external
> event.
> 
> This patch add supports to the above mentioned feature. Users will be
> able to triggered capturing the time snapshot from user-space using
> application such as testptp or any other applications that uses the
> PTP_EXTTS_REQUEST ioctl request.
> 
> [...]

Here is the summary with links:
  - [net-next,v4,1/1] net: stmmac: Add support for external trigger timestamping
    https://git.kernel.org/netdev/net-next/c/f4da56529da6

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From rppt at kernel.org  Wed Apr 14 21:06:33 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 14 Apr 2021 23:06:33 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
Message-ID: <YHdLSeYE3f5+v3n5@kernel.org>

On Wed, Apr 14, 2021 at 05:12:11PM +0200, David Hildenbrand wrote:
> On 07.04.21 19:26, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved region just before the memory is freed from memblock to the buddy
> > page allocator.
> > 
> > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > values set by the memory map initialization which makes it necessary to
> > have a special treatment for such pages in pfn_valid() and
> > pfn_valid_within().
> 
> I assume these pages are never given to the buddy, because we don't have a
> direct mapping. So to the kernel, it's essentially just like a memory hole
> with benefits.

The pages should not be accessed as normal memory so they do not have a
direct (or in ARMish linear) mapping and are never given to buddy. 
After looking at ACPI standard I don't see a fundamental reason for this
but they've already made this mess and we need to cope with it.
 
> I can spot that we want to export such memory like any special memory
> thingy/hole in /proc/iomem -- "reserved", which makes sense.

It does, but let's wait with /proc/iomem changes. We don't really have a
100% consistent view of it on different architectures, so adding yet
another type there does not seem, well, urgent.
 
> I would assume that MEMBLOCK_NOMAP is a special type of *reserved* memory.
> IOW, that for_each_reserved_mem_range() should already succeed on these as
> well -- we should mark anything that is MEMBLOCK_NOMAP implicitly as
> reserved. Or are there valid reasons not to do so? What can anyone do with
> that memory?
> 
> I assume they are pretty much useless for the kernel, right? Like other
> reserved memory ranges.

I agree that there is a lot of commonality between NOMAP and reserved. The
problem is that even semantics for reserved is different between
architectures. Moreover, on the same architecture there could be
E820_TYPE_RESERVED and memblock.reserved with different properties.

I'd really prefer moving in baby steps here because any change in the boot
mm can bear several month of early hangs debugging ;-)

> > Split out initialization of the reserved pages to a function with a
> > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> > reserved regions and mark struct pages for the NOMAP regions as
> > PageReserved.
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   mm/memblock.c | 23 +++++++++++++++++++++--
> >   1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..6b7ea9d86310 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
> >   	return end_pfn - start_pfn;
> >   }
> > +static void __init memmap_init_reserved_pages(void)
> > +{
> > +	struct memblock_region *region;
> > +	phys_addr_t start, end;
> > +	u64 i;
> > +
> > +	/* initialize struct pages for the reserved regions */
> > +	for_each_reserved_mem_range(i, &start, &end)
> > +		reserve_bootmem_region(start, end);
> > +
> > +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> > +	for_each_mem_region(region) {
> > +		if (memblock_is_nomap(region)) {
> > +			start = region->base;
> > +			end = start + region->size;
> > +			reserve_bootmem_region(start, end);
> > +		}
> > +	}
> > +}
> > +
> >   static unsigned long __init free_low_memory_core_early(void)
> >   {
> >   	unsigned long count = 0;
> > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
> >   	memblock_clear_hotplug(0, -1);
> > -	for_each_reserved_mem_range(i, &start, &end)
> > -		reserve_bootmem_region(start, end);
> > +	memmap_init_reserved_pages();
> >   	/*
> >   	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id

-- 
Sincerely yours,
Mike.


From rppt at kernel.org  Wed Apr 14 21:11:38 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 14 Apr 2021 23:11:38 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
Message-ID: <YHdMeqroH0enGiE3@kernel.org>

On Wed, Apr 14, 2021 at 05:27:53PM +0200, Ard Biesheuvel wrote:
> On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david at redhat.com> wrote:
> >
> > On 07.04.21 19:26, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt at linux.ibm.com>
> > >
> > > The struct pages representing a reserved memory region are initialized
> > > using reserve_bootmem_range() function. This function is called for each
> > > reserved region just before the memory is freed from memblock to the buddy
> > > page allocator.
> > >
> > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > > values set by the memory map initialization which makes it necessary to
> > > have a special treatment for such pages in pfn_valid() and
> > > pfn_valid_within().
> >
> > I assume these pages are never given to the buddy, because we don't have
> > a direct mapping. So to the kernel, it's essentially just like a memory
> > hole with benefits.
> >
> > I can spot that we want to export such memory like any special memory
> > thingy/hole in /proc/iomem -- "reserved", which makes sense.
> >
> > I would assume that MEMBLOCK_NOMAP is a special type of *reserved*
> > memory. IOW, that for_each_reserved_mem_range() should already succeed
> > on these as well -- we should mark anything that is MEMBLOCK_NOMAP
> > implicitly as reserved. Or are there valid reasons not to do so? What
> > can anyone do with that memory?
> >
> > I assume they are pretty much useless for the kernel, right? Like other
> > reserved memory ranges.
> >
> 
> On ARM, we need to know whether any physical regions that do not
> contain system memory contain something with device semantics or not.
> One of the examples is ACPI tables: these are in reserved memory, and
> so they are not covered by the linear region. However, when the ACPI
> core ioremap()s an arbitrary memory region, we don't know whether it
> is mapping a memory region or a device region unless we keep track of
> this in some way. (Device mappings require device attributes, but
> firmware tables require memory attributes, as they might be accessed
> using misaligned reads)

I mostly agree, but my understanding is that regions of *physical* memory
that are occupied by various pieces of EFI/ACPI information require special
treatment because it was defined this way in the APCI spec.
And since ARM cannot tolerate aliased mappings with different caching mode
the whole bunch of firmware memory should be ioremap()ed to access it.

> > > Split out initialization of the reserved pages to a function with a
> > > meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> > > reserved regions and mark struct pages for the NOMAP regions as
> > > PageReserved.
> > >
> > > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > > ---
> > >   mm/memblock.c | 23 +++++++++++++++++++++--
> > >   1 file changed, 21 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/memblock.c b/mm/memblock.c
> > > index afaefa8fc6ab..6b7ea9d86310 100644
> > > --- a/mm/memblock.c
> > > +++ b/mm/memblock.c
> > > @@ -2002,6 +2002,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
> > >       return end_pfn - start_pfn;
> > >   }
> > >
> > > +static void __init memmap_init_reserved_pages(void)
> > > +{
> > > +     struct memblock_region *region;
> > > +     phys_addr_t start, end;
> > > +     u64 i;
> > > +
> > > +     /* initialize struct pages for the reserved regions */
> > > +     for_each_reserved_mem_range(i, &start, &end)
> > > +             reserve_bootmem_region(start, end);
> > > +
> > > +     /* and also treat struct pages for the NOMAP regions as PageReserved */
> > > +     for_each_mem_region(region) {
> > > +             if (memblock_is_nomap(region)) {
> > > +                     start = region->base;
> > > +                     end = start + region->size;
> > > +                     reserve_bootmem_region(start, end);
> > > +             }
> > > +     }
> > > +}
> > > +
> > >   static unsigned long __init free_low_memory_core_early(void)
> > >   {
> > >       unsigned long count = 0;
> > > @@ -2010,8 +2030,7 @@ static unsigned long __init free_low_memory_core_early(void)
> > >
> > >       memblock_clear_hotplug(0, -1);
> > >
> > > -     for_each_reserved_mem_range(i, &start, &end)
> > > -             reserve_bootmem_region(start, end);
> > > +     memmap_init_reserved_pages();
> > >
> > >       /*
> > >        * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> > >
> >
> >
> > --
> > Thanks,
> >
> > David / dhildenb
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Sincerely yours,
Mike.


From rppt at kernel.org  Wed Apr 14 21:24:58 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 14 Apr 2021 23:24:58 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
 <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>
Message-ID: <YHdPmtpzFxHE9mAt@kernel.org>

On Wed, Apr 14, 2021 at 05:52:57PM +0200, David Hildenbrand wrote:
> On 14.04.21 17:27, Ard Biesheuvel wrote:
> > On Wed, 14 Apr 2021 at 17:14, David Hildenbrand <david at redhat.com> wrote:
> > > 
> > > On 07.04.21 19:26, Mike Rapoport wrote:
> > > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > > 
> > > > The struct pages representing a reserved memory region are initialized
> > > > using reserve_bootmem_range() function. This function is called for each
> > > > reserved region just before the memory is freed from memblock to the buddy
> > > > page allocator.
> > > > 
> > > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > > > values set by the memory map initialization which makes it necessary to
> > > > have a special treatment for such pages in pfn_valid() and
> > > > pfn_valid_within().
> > > 
> > > I assume these pages are never given to the buddy, because we don't have
> > > a direct mapping. So to the kernel, it's essentially just like a memory
> > > hole with benefits.
> > > 
> > > I can spot that we want to export such memory like any special memory
> > > thingy/hole in /proc/iomem -- "reserved", which makes sense.
> > > 
> > > I would assume that MEMBLOCK_NOMAP is a special type of *reserved*
> > > memory. IOW, that for_each_reserved_mem_range() should already succeed
> > > on these as well -- we should mark anything that is MEMBLOCK_NOMAP
> > > implicitly as reserved. Or are there valid reasons not to do so? What
> > > can anyone do with that memory?
> > > 
> > > I assume they are pretty much useless for the kernel, right? Like other
> > > reserved memory ranges.
> > > 
> > 
> > On ARM, we need to know whether any physical regions that do not
> > contain system memory contain something with device semantics or not.
> > One of the examples is ACPI tables: these are in reserved memory, and
> > so they are not covered by the linear region. However, when the ACPI
> > core ioremap()s an arbitrary memory region, we don't know whether it
> > is mapping a memory region or a device region unless we keep track of
> > this in some way. (Device mappings require device attributes, but
> > firmware tables require memory attributes, as they might be accessed
> > using misaligned reads)
> 
> Using generically sounding NOMAP ("don't create direct mapping") to identify
> device regions feels like a hack. I know, it was introduced just for that
> purpose.
> 
> Looking at memblock_mark_nomap(), we consider "device regions"
> 
> 1) ACPI tables
> 
> 2) VIDEO_TYPE_EFI memory
> 
> 3) some device-tree regions in of/fdt.c
> 
> 
> IIUC, right now we end up creating a memmap for this NOMAP memory, but hide
> it away in pfn_valid(). This patch set at least fixes that.

Currently we have memmap entries with struct page set to defaults for the
NOMAP memory. AFAIU hiding them in pfn_valid()/pfn_valid_within() was a
solution to failures in pfn walkers that presumed that for a pfn_valid()
there will be a struct page that really reflects the state of that page.

> Assuming these pages are never mapped to user space via the struct page
> (which better be the case), we could further use a new pagetype to mark
> these pages in a special way, such that we can identify them directly via
> pfn_to_page().

Not sure we really need a new pagetype here, PG_Reserved seems to be quite
enough to say "don't touch this".  I generally agree that we could make
PG_Reserved a PageType and then have several sub-types for reserved memory.
This definitely will add clarity but I'm not sure that this justifies
amount of churn and effort required to audit uses of PageResrved().
 
> Then, we could mostly avoid having to query memblock at runtime to figure
> out that this is special memory. This would obviously be an extension to
> this series. Just a thought. 

Stop pushing memblock out of kernel! ;-)

Now, seriously, we can minimize memblock involvement in run-time and this
series in yet another step in that direction.

-- 
Sincerely yours,
Mike.


From rppt at kernel.org  Wed Apr 14 21:29:42 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 14 Apr 2021 23:29:42 +0300
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <9c0956f0-494e-5c6b-bdc2-d4213afd5e2f@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
 <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
 <9c0956f0-494e-5c6b-bdc2-d4213afd5e2f@redhat.com>
Message-ID: <YHdQtmuxpqi4wCE/@kernel.org>

On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> On 08.04.21 07:14, Anshuman Khandual wrote:
> > 
> > On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > 
> > > The intended semantics of pfn_valid() is to verify whether there is a
> > > struct page for the pfn in question and nothing else.
> > 
> > Should there be a comment affirming this semantics interpretation, above the
> > generic pfn_valid() in include/linux/mmzone.h ?
> > 
> > > 
> > > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > > linear map vs those that require ioremap() to access them.
> > > 
> > > Introduce a dedicated pfn_is_memory() to perform such check and use it
> > > where appropriate.
> > > 
> > > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > > ---
> > >   arch/arm64/include/asm/memory.h | 2 +-
> > >   arch/arm64/include/asm/page.h   | 1 +
> > >   arch/arm64/kvm/mmu.c            | 2 +-
> > >   arch/arm64/mm/init.c            | 6 ++++++
> > >   arch/arm64/mm/ioremap.c         | 4 ++--
> > >   arch/arm64/mm/mmu.c             | 2 +-
> > >   6 files changed, 12 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > index 0aabc3be9a75..7e77fdf71b9d 100644
> > > --- a/arch/arm64/include/asm/memory.h
> > > +++ b/arch/arm64/include/asm/memory.h
> > > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> > >   #define virt_addr_valid(addr)	({					\
> > >   	__typeof__(addr) __addr = __tag_reset(addr);			\
> > > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > > +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
> > >   })
> > >   void dump_mem_limit(void);
> > > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > > index 012cffc574e8..32b485bcc6ff 100644
> > > --- a/arch/arm64/include/asm/page.h
> > > +++ b/arch/arm64/include/asm/page.h
> > > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> > >   typedef struct page *pgtable_t;
> > >   extern int pfn_valid(unsigned long);
> > > +extern int pfn_is_memory(unsigned long);
> > >   #include <asm/memory.h>
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 8711894db8c2..ad2ea65a3937 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> > >   static bool kvm_is_device_pfn(unsigned long pfn)
> > >   {
> > > -	return !pfn_valid(pfn);
> > > +	return !pfn_is_memory(pfn);
> > >   }
> > >   /*
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 3685e12aba9b..258b1905ed4a 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
> > >   }
> > >   EXPORT_SYMBOL(pfn_valid);
> > > +int pfn_is_memory(unsigned long pfn)
> > > +{
> > > +	return memblock_is_map_memory(PFN_PHYS(pfn));
> > > +}
> > > +EXPORT_SYMBOL(pfn_is_memory);> +
> > 
> > Should not this be generic though ? There is nothing platform or arm64
> > specific in here. Wondering as pfn_is_memory() just indicates that the
> > pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
> > instead ? Regardless, it's fine either way.
> 
> TBH, I dislike (generic) pfn_is_memory(). It feels like we're mixing
> concepts.

Yeah, at the moment NOMAP is very much arm specific so I'd keep it this way
for now.

>  NOMAP memory vs !NOMAP memory; even NOMAP is some kind of memory
> after all. pfn_is_map_memory() would be more expressive, although still
> sub-optimal.
>
> We'd actually want some kind of arm64-specific pfn_is_system_memory() or the
> inverse pfn_is_device_memory() -- to be improved.

In my current version (to be posted soon) I've started with
pfn_lineary_mapped() but then ended up with pfn_mapped() to make it
"upward" compatible with architectures that use direct rather than linear
map :)

-- 
Sincerely yours,
Mike.


From krzysztof.kozlowski at canonical.com  Wed Apr 14 21:33:41 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 22:33:41 +0200
Subject: [PATCH 1/3] spi: s3c64xx: simplify getting of_device_id match data
Message-ID: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>

Use of_device_get_match_data() to make the code slightly smaller and to
remove the of_device_id table forward declaration.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/spi/spi-s3c64xx.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index dfa7c91e13aa..c6d7641ea342 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -15,6 +15,7 @@
 #include <linux/spi/spi.h>
 #include <linux/gpio.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/of_gpio.h>
 
 #include <linux/platform_data/spi-s3c64xx.h>
@@ -1048,17 +1049,12 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
 }
 #endif
 
-static const struct of_device_id s3c64xx_spi_dt_match[];
-
 static inline struct s3c64xx_spi_port_config *s3c64xx_spi_get_port_config(
 						struct platform_device *pdev)
 {
 #ifdef CONFIG_OF
-	if (pdev->dev.of_node) {
-		const struct of_device_id *match;
-		match = of_match_node(s3c64xx_spi_dt_match, pdev->dev.of_node);
-		return (struct s3c64xx_spi_port_config *)match->data;
-	}
+	if (pdev->dev.of_node)
+		return (struct s3c64xx_spi_port_config *)of_device_get_match_data(&pdev->dev);
 #endif
 	return (struct s3c64xx_spi_port_config *)
 			 platform_get_device_id(pdev)->driver_data;
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Wed Apr 14 21:33:42 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 22:33:42 +0200
Subject: [PATCH 2/3] spi: s3c64xx: correct kerneldoc of s3c64xx_spi_port_config
In-Reply-To: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210414203343.203119-2-krzysztof.kozlowski@canonical.com>

Correct the name of s3c64xx_spi_port_config structure in kerneldoc:

  drivers/spi/spi-s3c64xx.c:154: warning:
    expecting prototype for struct s3c64xx_spi_info. Prototype was for struct s3c64xx_spi_port_config instead

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/spi/spi-s3c64xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index c6d7641ea342..eac3c300f806 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -128,7 +128,7 @@ struct s3c64xx_spi_dma_data {
 };
 
 /**
- * struct s3c64xx_spi_info - SPI Controller hardware info
+ * struct s3c64xx_spi_port_config - SPI Controller hardware info
  * @fifo_lvl_mask: Bit-mask for {TX|RX}_FIFO_LVL bits in SPI_STATUS register.
  * @rx_lvl_offset: Bit offset of RX_FIFO_LVL bits in SPI_STATUS regiter.
  * @tx_st_done: Bit offset of TX_DONE bit in SPI_STATUS regiter.
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Wed Apr 14 21:33:43 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Wed, 14 Apr 2021 22:33:43 +0200
Subject: [PATCH 3/3] spi: s3c64xx: constify driver/match data
In-Reply-To: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210414203343.203119-3-krzysztof.kozlowski@canonical.com>

The match data (struct s3c64xx_spi_port_config) stored in of_device_id
and platform_device_id tables is not modified by the driver and can be
handled entirely in a const-way to increase the code safety.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/spi/spi-s3c64xx.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index eac3c300f806..8755cd85e83c 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -190,7 +190,7 @@ struct s3c64xx_spi_driver_data {
 	unsigned                        cur_speed;
 	struct s3c64xx_spi_dma_data	rx_dma;
 	struct s3c64xx_spi_dma_data	tx_dma;
-	struct s3c64xx_spi_port_config	*port_conf;
+	const struct s3c64xx_spi_port_config	*port_conf;
 	unsigned int			port_id;
 };
 
@@ -1049,15 +1049,14 @@ static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
 }
 #endif
 
-static inline struct s3c64xx_spi_port_config *s3c64xx_spi_get_port_config(
+static inline const struct s3c64xx_spi_port_config *s3c64xx_spi_get_port_config(
 						struct platform_device *pdev)
 {
 #ifdef CONFIG_OF
 	if (pdev->dev.of_node)
-		return (struct s3c64xx_spi_port_config *)of_device_get_match_data(&pdev->dev);
+		return of_device_get_match_data(&pdev->dev);
 #endif
-	return (struct s3c64xx_spi_port_config *)
-			 platform_get_device_id(pdev)->driver_data;
+	return (const struct s3c64xx_spi_port_config *)platform_get_device_id(pdev)->driver_data;
 }
 
 static int s3c64xx_spi_probe(struct platform_device *pdev)
@@ -1395,27 +1394,27 @@ static const struct dev_pm_ops s3c64xx_spi_pm = {
 			   s3c64xx_spi_runtime_resume, NULL)
 };
 
-static struct s3c64xx_spi_port_config s3c2443_spi_port_config = {
+static const struct s3c64xx_spi_port_config s3c2443_spi_port_config = {
 	.fifo_lvl_mask	= { 0x7f },
 	.rx_lvl_offset	= 13,
 	.tx_st_done	= 21,
 	.high_speed	= true,
 };
 
-static struct s3c64xx_spi_port_config s3c6410_spi_port_config = {
+static const struct s3c64xx_spi_port_config s3c6410_spi_port_config = {
 	.fifo_lvl_mask	= { 0x7f, 0x7F },
 	.rx_lvl_offset	= 13,
 	.tx_st_done	= 21,
 };
 
-static struct s3c64xx_spi_port_config s5pv210_spi_port_config = {
+static const struct s3c64xx_spi_port_config s5pv210_spi_port_config = {
 	.fifo_lvl_mask	= { 0x1ff, 0x7F },
 	.rx_lvl_offset	= 15,
 	.tx_st_done	= 25,
 	.high_speed	= true,
 };
 
-static struct s3c64xx_spi_port_config exynos4_spi_port_config = {
+static const struct s3c64xx_spi_port_config exynos4_spi_port_config = {
 	.fifo_lvl_mask	= { 0x1ff, 0x7F, 0x7F },
 	.rx_lvl_offset	= 15,
 	.tx_st_done	= 25,
@@ -1424,7 +1423,7 @@ static struct s3c64xx_spi_port_config exynos4_spi_port_config = {
 	.quirks		= S3C64XX_SPI_QUIRK_CS_AUTO,
 };
 
-static struct s3c64xx_spi_port_config exynos7_spi_port_config = {
+static const struct s3c64xx_spi_port_config exynos7_spi_port_config = {
 	.fifo_lvl_mask	= { 0x1ff, 0x7F, 0x7F, 0x7F, 0x7F, 0x1ff},
 	.rx_lvl_offset	= 15,
 	.tx_st_done	= 25,
@@ -1433,7 +1432,7 @@ static struct s3c64xx_spi_port_config exynos7_spi_port_config = {
 	.quirks		= S3C64XX_SPI_QUIRK_CS_AUTO,
 };
 
-static struct s3c64xx_spi_port_config exynos5433_spi_port_config = {
+static const struct s3c64xx_spi_port_config exynos5433_spi_port_config = {
 	.fifo_lvl_mask	= { 0x1ff, 0x7f, 0x7f, 0x7f, 0x7f, 0x1ff},
 	.rx_lvl_offset	= 15,
 	.tx_st_done	= 25,
-- 
2.25.1



From jbx6244 at gmail.com  Wed Apr 14 22:18:47 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:47 +0200
Subject: [PATCH v7 02/11] arm: dts: rockchip: Fix power-controller node names
 for rk3188
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-3-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3188.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 2298a8d84..5db32fdbe 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -699,7 +699,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3188_PD_VIO {
+		power-domain at RK3188_PD_VIO {
 			reg = <RK3188_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -721,7 +721,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3188_PD_VIDEO {
+		power-domain at RK3188_PD_VIDEO {
 			reg = <RK3188_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -730,7 +730,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3188_PD_GPU {
+		power-domain at RK3188_PD_GPU {
 			reg = <RK3188_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:45 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:45 +0200
Subject: [PATCH v7 00/11] soc: rockchip: power-domain: add rk3568 powerdomains
Message-ID: <20210414211856.12104-1-jbx6244@gmail.com>

Fix power-controller node names for dtbs_check.
Convert power domain documentation to json-schema.
Add a meaningful power domain name.
Support power domain function for RK3568 Soc.

Changed in V7:
[PATCH v7 07/11]
  Fix TAB warning
  Fix alignment
[PATCH v7 09/11]:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
[PATCH v7 11/11]
  Fix alignment

Changed in V6:
[PATCH v6 7/11]: Use kbasename(node->full_name).
[PATCH v6 9/11]: Update the commit message.

Changed in V5:
[PATCH v5 1/11]: New.
[PATCH v5 2/11]: New.
[PATCH v5 3/11]: New.
[PATCH v5 4/11]: New.
[PATCH v5 5/11]: New.
[PATCH v5 6/11]: New.
[PATCH v5 7/11]: New.
[PATCH v5 8/11]: No change. Same as [PATCH v4 1/4].
[PATCH v5 9/11]: [PATCH v4 2/4] Fix up yaml code styles.
[PATCH v5 10/11]: No change. Same as [PATCH v4 3/4].
[PATCH v5 11/11]: [PATCH v4 4/4] add a meaningful power domain name for
RK3568 Soc.

Changed in V4:
[PATCH v4 2/4]: Fix up yaml code styles. Remove the new compatible to [PATCH v4 3/4]
[PATCH v4 3/4]: Adding new compatible for RK3568 Soc.
[PATCH v4 4/4]: No change. Same as [PATCH v3 3/3].

Changed in V3:
[PATCH v3 2/3]: Fix up the code styles and add rk3568 base on:
https://patchwork.kernel.org/project/linux-rockchip/patch/20210225102643.653095-1-enric.balletbo at collabora.com/

Changed in V2:
[PATCH v2 2/3]: Fix up yaml code styles.

Elaine Zhang (10):
  arm: dts: rockchip: Fix power-controller node names for rk3066a
  arm: dts: rockchip: Fix power-controller node names for rk3188
  arm: dts: rockchip: Fix power-controller node names for rk3288
  arm64: dts: rockchip: Fix power-controller node names for px30
  arm64: dts: rockchip: Fix power-controller node names for rk3328
  arm64: dts: rockchip: Fix power-controller node names for rk3399
  soc: rockchip: pm-domains: Add a meaningful power domain name
  dt-bindings: add power-domain header for RK3568 SoCs
  dt-bindings: power: rockchip: Add bindings for RK3568 Soc
  soc: rockchip: power-domain: add rk3568 powerdomains

Enric Balletbo i Serra (1):
  dt-bindings: power: rockchip: Convert to json-schema

 .../bindings/power/rockchip,power-controller.yaml  | 285 +++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 ----------
 arch/arm/boot/dts/rk3066a.dtsi                     |   6 +-
 arch/arm/boot/dts/rk3188.dtsi                      |   6 +-
 arch/arm/boot/dts/rk3288.dtsi                      |   8 +-
 arch/arm64/boot/dts/rockchip/px30.dtsi             |  16 +-
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |   6 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  40 +--
 drivers/soc/rockchip/pm_domains.c                  | 252 ++++++++++--------
 include/dt-bindings/power/rk3568-power.h           |  32 +++
 10 files changed, 503 insertions(+), 284 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
 create mode 100644 include/dt-bindings/power/rk3568-power.h

-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:46 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:46 +0200
Subject: [PATCH v7 01/11] arm: dts: rockchip: Fix power-controller node names
 for rk3066a
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-2-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed
---
 arch/arm/boot/dts/rk3066a.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..bbc3bff50 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -755,7 +755,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3066_PD_VIO {
+		power-domain at RK3066_PD_VIO {
 			reg = <RK3066_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -782,7 +782,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3066_PD_VIDEO {
+		power-domain at RK3066_PD_VIDEO {
 			reg = <RK3066_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -791,7 +791,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3066_PD_GPU {
+		power-domain at RK3066_PD_GPU {
 			reg = <RK3066_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:48 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:48 +0200
Subject: [PATCH v7 03/11] arm: dts: rockchip: Fix power-controller node names
 for rk3288
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-4-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ea7416c31..6f4d7929e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -769,7 +769,7 @@
 			 *	*_HDMI		HDMI
 			 *	*_MIPI_*	MIPI
 			 */
-			pd_vio at RK3288_PD_VIO {
+			power-domain at RK3288_PD_VIO {
 				reg = <RK3288_PD_VIO>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru ACLK_ISP>,
@@ -811,7 +811,7 @@
 			 * Note: The following 3 are HEVC(H.265) clocks,
 			 * and on the ACLK_HEVC_NIU (NOC).
 			 */
-			pd_hevc at RK3288_PD_HEVC {
+			power-domain at RK3288_PD_HEVC {
 				reg = <RK3288_PD_HEVC>;
 				clocks = <&cru ACLK_HEVC>,
 					 <&cru SCLK_HEVC_CABAC>,
@@ -825,7 +825,7 @@
 			 * (video endecoder & decoder) clocks that on the
 			 * ACLK_VCODEC_NIU and HCLK_VCODEC_NIU (NOC).
 			 */
-			pd_video at RK3288_PD_VIDEO {
+			power-domain at RK3288_PD_VIDEO {
 				reg = <RK3288_PD_VIDEO>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
@@ -836,7 +836,7 @@
 			 * Note: ACLK_GPU is the GPU clock,
 			 * and on the ACLK_GPU_NIU (NOC).
 			 */
-			pd_gpu at RK3288_PD_GPU {
+			power-domain at RK3288_PD_GPU {
 				reg = <RK3288_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu_r>,
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:49 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:49 +0200
Subject: [PATCH v7 04/11] arm64: dts: rockchip: Fix power-controller node
 names for px30
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-5-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a16..2b43c3d72 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -244,20 +244,20 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_usb at PX30_PD_USB {
+			power-domain at PX30_PD_USB {
 				reg = <PX30_PD_USB>;
 				clocks = <&cru HCLK_HOST>,
 					 <&cru HCLK_OTG>,
 					 <&cru SCLK_OTG_ADP>;
 				pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
 			};
-			pd_sdcard at PX30_PD_SDCARD {
+			power-domain at PX30_PD_SDCARD {
 				reg = <PX30_PD_SDCARD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sdmmc>;
 			};
-			pd_gmac at PX30_PD_GMAC {
+			power-domain at PX30_PD_GMAC {
 				reg = <PX30_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>,
@@ -265,7 +265,7 @@
 					 <&cru SCLK_GMAC_RX_TX>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_mmc_nand at PX30_PD_MMC_NAND {
+			power-domain at PX30_PD_MMC_NAND {
 				reg = <PX30_PD_MMC_NAND>;
 				clocks =  <&cru HCLK_NANDC>,
 					  <&cru HCLK_EMMC>,
@@ -278,14 +278,14 @@
 				pm_qos = <&qos_emmc>, <&qos_nand>,
 					 <&qos_sdio>, <&qos_sfc>;
 			};
-			pd_vpu at PX30_PD_VPU {
+			power-domain at PX30_PD_VPU {
 				reg = <PX30_PD_VPU>;
 				clocks = <&cru ACLK_VPU>,
 					 <&cru HCLK_VPU>,
 					 <&cru SCLK_CORE_VPU>;
 				pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
 			};
-			pd_vo at PX30_PD_VO {
+			power-domain at PX30_PD_VO {
 				reg = <PX30_PD_VO>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru ACLK_VOPB>,
@@ -301,7 +301,7 @@
 				pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
 					 <&qos_vop_m0>, <&qos_vop_m1>;
 			};
-			pd_vi at PX30_PD_VI {
+			power-domain at PX30_PD_VI {
 				reg = <PX30_PD_VI>;
 				clocks = <&cru ACLK_CIF>,
 					 <&cru ACLK_ISP>,
@@ -312,7 +312,7 @@
 					 <&qos_isp_wr>, <&qos_isp_m1>,
 					 <&qos_vip>;
 			};
-			pd_gpu at PX30_PD_GPU {
+			power-domain at PX30_PD_GPU {
 				reg = <PX30_PD_GPU>;
 				clocks = <&cru SCLK_GPU>;
 				pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:50 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:50 +0200
Subject: [PATCH v7 05/11] arm64: dts: rockchip: Fix power-controller node
 names for rk3328
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-6-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 5bab61784..35df57535 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -300,13 +300,13 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 
-			pd_hevc at RK3328_PD_HEVC {
+			power-domain at RK3328_PD_HEVC {
 				reg = <RK3328_PD_HEVC>;
 			};
-			pd_video at RK3328_PD_VIDEO {
+			power-domain at RK3328_PD_VIDEO {
 				reg = <RK3328_PD_VIDEO>;
 			};
-			pd_vpu at RK3328_PD_VPU {
+			power-domain at RK3328_PD_VPU {
 				reg = <RK3328_PD_VPU>;
 				clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
 			};
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:51 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:51 +0200
Subject: [PATCH v7 06/11] arm64: dts: rockchip: Fix power-controller node
 names for rk3399
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-7-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 40 ++++++++++++++++----------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 0f2879cc1..19614c2ce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -968,26 +968,26 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_CENTER */
-			pd_iep at RK3399_PD_IEP {
+			power-domain at RK3399_PD_IEP {
 				reg = <RK3399_PD_IEP>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru HCLK_IEP>;
 				pm_qos = <&qos_iep>;
 			};
-			pd_rga at RK3399_PD_RGA {
+			power-domain at RK3399_PD_RGA {
 				reg = <RK3399_PD_RGA>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru HCLK_RGA>;
 				pm_qos = <&qos_rga_r>,
 					 <&qos_rga_w>;
 			};
-			pd_vcodec at RK3399_PD_VCODEC {
+			power-domain at RK3399_PD_VCODEC {
 				reg = <RK3399_PD_VCODEC>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video_m0>;
 			};
-			pd_vdu at RK3399_PD_VDU {
+			power-domain at RK3399_PD_VDU {
 				reg = <RK3399_PD_VDU>;
 				clocks = <&cru ACLK_VDU>,
 					 <&cru HCLK_VDU>;
@@ -996,94 +996,94 @@
 			};
 
 			/* These power domains are grouped by VD_GPU */
-			pd_gpu at RK3399_PD_GPU {
+			power-domain at RK3399_PD_GPU {
 				reg = <RK3399_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu>;
 			};
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_edp at RK3399_PD_EDP {
+			power-domain at RK3399_PD_EDP {
 				reg = <RK3399_PD_EDP>;
 				clocks = <&cru PCLK_EDP_CTRL>;
 			};
-			pd_emmc at RK3399_PD_EMMC {
+			power-domain at RK3399_PD_EMMC {
 				reg = <RK3399_PD_EMMC>;
 				clocks = <&cru ACLK_EMMC>;
 				pm_qos = <&qos_emmc>;
 			};
-			pd_gmac at RK3399_PD_GMAC {
+			power-domain at RK3399_PD_GMAC {
 				reg = <RK3399_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_sd at RK3399_PD_SD {
+			power-domain at RK3399_PD_SD {
 				reg = <RK3399_PD_SD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sd>;
 			};
-			pd_sdioaudio at RK3399_PD_SDIOAUDIO {
+			power-domain at RK3399_PD_SDIOAUDIO {
 				reg = <RK3399_PD_SDIOAUDIO>;
 				clocks = <&cru HCLK_SDIO>;
 				pm_qos = <&qos_sdioaudio>;
 			};
-			pd_tcpc0 at RK3399_PD_TCPD0 {
+			power-domain at RK3399_PD_TCPD0 {
 				reg = <RK3399_PD_TCPD0>;
 				clocks = <&cru SCLK_UPHY0_TCPDCORE>,
 					 <&cru SCLK_UPHY0_TCPDPHY_REF>;
 			};
-			pd_tcpc1 at RK3399_PD_TCPD1 {
+			power-domain at RK3399_PD_TCPD1 {
 				reg = <RK3399_PD_TCPD1>;
 				clocks = <&cru SCLK_UPHY1_TCPDCORE>,
 					 <&cru SCLK_UPHY1_TCPDPHY_REF>;
 			};
-			pd_usb3 at RK3399_PD_USB3 {
+			power-domain at RK3399_PD_USB3 {
 				reg = <RK3399_PD_USB3>;
 				clocks = <&cru ACLK_USB3>;
 				pm_qos = <&qos_usb_otg0>,
 					 <&qos_usb_otg1>;
 			};
-			pd_vio at RK3399_PD_VIO {
+			power-domain at RK3399_PD_VIO {
 				reg = <RK3399_PD_VIO>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				pd_hdcp at RK3399_PD_HDCP {
+				power-domain at RK3399_PD_HDCP {
 					reg = <RK3399_PD_HDCP>;
 					clocks = <&cru ACLK_HDCP>,
 						 <&cru HCLK_HDCP>,
 						 <&cru PCLK_HDCP>;
 					pm_qos = <&qos_hdcp>;
 				};
-				pd_isp0 at RK3399_PD_ISP0 {
+				power-domain at RK3399_PD_ISP0 {
 					reg = <RK3399_PD_ISP0>;
 					clocks = <&cru ACLK_ISP0>,
 						 <&cru HCLK_ISP0>;
 					pm_qos = <&qos_isp0_m0>,
 						 <&qos_isp0_m1>;
 				};
-				pd_isp1 at RK3399_PD_ISP1 {
+				power-domain at RK3399_PD_ISP1 {
 					reg = <RK3399_PD_ISP1>;
 					clocks = <&cru ACLK_ISP1>,
 						 <&cru HCLK_ISP1>;
 					pm_qos = <&qos_isp1_m0>,
 						 <&qos_isp1_m1>;
 				};
-				pd_vo at RK3399_PD_VO {
+				power-domain at RK3399_PD_VO {
 					reg = <RK3399_PD_VO>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 
-					pd_vopb at RK3399_PD_VOPB {
+					power-domain at RK3399_PD_VOPB {
 						reg = <RK3399_PD_VOPB>;
 						clocks = <&cru ACLK_VOP0>,
 							 <&cru HCLK_VOP0>;
 						pm_qos = <&qos_vop_big_r>,
 							 <&qos_vop_big_w>;
 					};
-					pd_vopl at RK3399_PD_VOPL {
+					power-domain at RK3399_PD_VOPL {
 						reg = <RK3399_PD_VOPL>;
 						clocks = <&cru ACLK_VOP1>,
 							 <&cru HCLK_VOP1>;
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:53 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:53 +0200
Subject: [PATCH v7 08/11] dt-bindings: add power-domain header for RK3568 SoCs
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-9-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 include/dt-bindings/power/rk3568-power.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3568-power.h

diff --git a/include/dt-bindings/power/rk3568-power.h b/include/dt-bindings/power/rk3568-power.h
new file mode 100644
index 000000000..6cc1af1a9
--- /dev/null
+++ b/include/dt-bindings/power/rk3568-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3568_POWER_H__
+#define __DT_BINDINGS_POWER_RK3568_POWER_H__
+
+/* VD_CORE */
+#define RK3568_PD_CPU_0		0
+#define RK3568_PD_CPU_1		1
+#define RK3568_PD_CPU_2		2
+#define RK3568_PD_CPU_3		3
+#define RK3568_PD_CORE_ALIVE	4
+
+/* VD_PMU */
+#define RK3568_PD_PMU		5
+
+/* VD_NPU */
+#define RK3568_PD_NPU		6
+
+/* VD_GPU */
+#define RK3568_PD_GPU		7
+
+/* VD_LOGIC */
+#define RK3568_PD_VI		8
+#define RK3568_PD_VO		9
+#define RK3568_PD_RGA		10
+#define RK3568_PD_VPU		11
+#define RK3568_PD_CENTER	12
+#define RK3568_PD_RKVDEC	13
+#define RK3568_PD_RKVENC	14
+#define RK3568_PD_PIPE		15
+#define RK3568_PD_LOGIC_ALIVE	16
+
+#endif
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:56 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:56 +0200
Subject: [PATCH v7 11/11] soc: rockchip: power-domain: add rk3568 powerdomains
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-12-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add power-domains found on rk3568 socs.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 1d1b06672..0868b7d40 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -27,6 +27,7 @@
 #include <dt-bindings/power/rk3366-power.h>
 #include <dt-bindings/power/rk3368-power.h>
 #include <dt-bindings/power/rk3399-power.h>
+#include <dt-bindings/power/rk3568-power.h>
 
 struct rockchip_domain_info {
 	const char *name;
@@ -135,6 +136,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
 	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
+#define DOMAIN_RK3568(name, pwr, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, req, req, wakeup)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -848,6 +852,18 @@ static const struct rockchip_domain_info rk3399_pm_domains[] = {
 	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
+static const struct rockchip_domain_info rk3568_pm_domains[] = {
+	[RK3568_PD_NPU]		= DOMAIN_RK3568("npu",  BIT(1), BIT(2),  false),
+	[RK3568_PD_GPU]		= DOMAIN_RK3568("gpu",  BIT(0), BIT(1),  false),
+	[RK3568_PD_VI]		= DOMAIN_RK3568("vi",   BIT(6), BIT(3),  false),
+	[RK3568_PD_VO]		= DOMAIN_RK3568("vo",   BIT(7), BIT(4),  false),
+	[RK3568_PD_RGA]		= DOMAIN_RK3568("rga",  BIT(5), BIT(5),  false),
+	[RK3568_PD_VPU]		= DOMAIN_RK3568("vpu",  BIT(2), BIT(6),  false),
+	[RK3568_PD_RKVDEC]	= DOMAIN_RK3568("vdec", BIT(4), BIT(8),  false),
+	[RK3568_PD_RKVENC]	= DOMAIN_RK3568("venc", BIT(3), BIT(7),  false),
+	[RK3568_PD_PIPE]	= DOMAIN_RK3568("pipe", BIT(8), BIT(11), false),
+};
+
 static const struct rockchip_pmu_info px30_pmu = {
 	.pwr_offset = 0x18,
 	.status_offset = 0x20,
@@ -983,6 +999,17 @@ static const struct rockchip_pmu_info rk3399_pmu = {
 	.domain_info = rk3399_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3568_pmu = {
+	.pwr_offset = 0xa0,
+	.status_offset = 0x98,
+	.req_offset = 0x50,
+	.idle_offset = 0x68,
+	.ack_offset = 0x60,
+
+	.num_domains = ARRAY_SIZE(rk3568_pm_domains),
+	.domain_info = rk3568_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,px30-power-controller",
@@ -1028,6 +1055,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3399-power-controller",
 		.data = (void *)&rk3399_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3568-power-controller",
+		.data = (void *)&rk3568_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:54 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:54 +0200
Subject: [PATCH v7 09/11] dt-bindings: power: rockchip: Convert to json-schema
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-10-jbx6244@gmail.com>

From: Enric Balletbo i Serra <enric.balletbo at collabora.com>

Convert the soc/rockchip/power_domain.txt binding document to
json-schema and move to the power bindings directory.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Note for rob+dt:
A tag was not added on purpose, because:
  Add "rockchip," prefix to the qos compatible name
  in example.
  Changed maintainers.
  Size reg description is reduced.
  Little style changes '' to ""
Please have a look at it again.

For some SoC nodes this patch serie generates notifications
for undocumented "assigned-clocks" and "assigned-clock-parents"
properties till there is consensus of what to do with it.
---
Changed V7:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
Changed V6:
  Changed author
Changed V5:
  Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
  Remove a maintainer
  Changed patternProperties to power-domain
  Add "clocks", "assigned-clocks" and "assigned-clock-parents"
Changed V4:
  Remove new compatible string
  Style changes '' to ""
Changed V3:
  Use Enric's conversion with rk3399 example
Changed V2:
  Convert power_domain.txt to YAML with rk3568 example
---
 .../bindings/power/rockchip,power-controller.yaml  | 283 +++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 ----------
 2 files changed, 283 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
new file mode 100644
index 000000000..934308006
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -0,0 +1,283 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Domains
+
+maintainers:
+  - Elaine Zhang <zhangqing at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |
+  Rockchip processors include support for multiple power domains which can be
+  powered up/down by software based on different application scenarios to save power.
+
+  Power domains contained within power-controller node are generic power domain
+  providers documented in Documentation/devicetree/bindings/power/power-domain.yaml.
+
+  IP cores belonging to a power domain should contain a "power-domains"
+  property that is a phandle for the power domain node representing the domain.
+
+properties:
+  $nodename:
+    const: power-controller
+
+  compatible:
+    enum:
+      - rockchip,px30-power-controller
+      - rockchip,rk3036-power-controller
+      - rockchip,rk3066-power-controller
+      - rockchip,rk3128-power-controller
+      - rockchip,rk3188-power-controller
+      - rockchip,rk3228-power-controller
+      - rockchip,rk3288-power-controller
+      - rockchip,rk3328-power-controller
+      - rockchip,rk3366-power-controller
+      - rockchip,rk3368-power-controller
+      - rockchip,rk3399-power-controller
+
+  "#power-domain-cells":
+    const: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+    type: object
+    description: |
+      Represents the power domains within the power controller node as documented
+      in Documentation/devicetree/bindings/power/power-domain.yaml.
+
+    properties:
+
+      "#power-domain-cells":
+        description:
+          Must be 0 for nodes representing a single PM domain and 1 for nodes
+          providing multiple PM domains.
+
+      "#address-cells":
+        const: 1
+
+      "#size-cells":
+        const: 0
+
+      reg:
+        maxItems: 1
+        description: |
+          Power domain index. Valid values are defined in
+          "include/dt-bindings/power/px30-power.h"
+          "include/dt-bindings/power/rk3036-power.h"
+          "include/dt-bindings/power/rk3066-power.h"
+          "include/dt-bindings/power/rk3128-power.h"
+          "include/dt-bindings/power/rk3188-power.h"
+          "include/dt-bindings/power/rk3228-power.h"
+          "include/dt-bindings/power/rk3288-power.h"
+          "include/dt-bindings/power/rk3328-power.h"
+          "include/dt-bindings/power/rk3366-power.h"
+          "include/dt-bindings/power/rk3368-power.h"
+          "include/dt-bindings/power/rk3399-power.h"
+
+      clocks:
+        description: |
+          A number of phandles to clocks that need to be enabled while power domain
+          switches state.
+
+      pm_qos:
+        description: |
+          A number of phandles to qos blocks which need to be saved and restored
+          while power domain switches state.
+
+    patternProperties:
+      "^power-domain@[0-9a-f]+$":
+        type: object
+        description: |
+          Represents a power domain child within a power domain parent node.
+
+        properties:
+
+          "#power-domain-cells":
+            description:
+              Must be 0 for nodes representing a single PM domain and 1 for nodes
+              providing multiple PM domains.
+
+          "#address-cells":
+            const: 1
+
+          "#size-cells":
+            const: 0
+
+          reg:
+            maxItems: 1
+
+          clocks:
+            description: |
+              A number of phandles to clocks that need to be enabled while power domain
+              switches state.
+
+          pm_qos:
+            description: |
+              A number of phandles to qos blocks which need to be saved and restored
+              while power domain switches state.
+
+        patternProperties:
+          "^power-domain@[0-9a-f]+$":
+            type: object
+            description: |
+              Represents a power domain child within a power domain parent node.
+
+            properties:
+
+              "#power-domain-cells":
+                description:
+                  Must be 0 for nodes representing a single PM domain and 1 for nodes
+                  providing multiple PM domains.
+
+              "#address-cells":
+                const: 1
+
+              "#size-cells":
+                const: 0
+
+              reg:
+                maxItems: 1
+
+              clocks:
+                description: |
+                  A number of phandles to clocks that need to be enabled while power domain
+                  switches state.
+
+              pm_qos:
+                description: |
+                  A number of phandles to qos blocks which need to be saved and restored
+                  while power domain switches state.
+
+            required:
+              - reg
+
+            additionalProperties: false
+
+        required:
+          - reg
+
+        additionalProperties: false
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - "#power-domain-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3399-cru.h>
+    #include <dt-bindings/power/rk3399-power.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        qos_hdcp: qos at ffa90000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa90000 0x0 0x20>;
+        };
+
+        qos_iep: qos at ffa98000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa98000 0x0 0x20>;
+        };
+
+        qos_rga_r: qos at ffab0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0000 0x0 0x20>;
+        };
+
+        qos_rga_w: qos at ffab0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0080 0x0 0x20>;
+        };
+
+        qos_video_m0: qos at ffab8000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab8000 0x0 0x20>;
+        };
+
+        qos_video_m1_r: qos at ffac0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0000 0x0 0x20>;
+        };
+
+        qos_video_m1_w: qos at ffac0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0080 0x0 0x20>;
+        };
+
+        power-management at ff310000 {
+            compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
+            reg = <0x0 0xff310000 0x0 0x1000>;
+
+            power-controller {
+                compatible = "rockchip,rk3399-power-controller";
+                #power-domain-cells = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                /* These power domains are grouped by VD_CENTER */
+                power-domain at RK3399_PD_IEP {
+                    reg = <RK3399_PD_IEP>;
+                    clocks = <&cru ACLK_IEP>,
+                             <&cru HCLK_IEP>;
+                    pm_qos = <&qos_iep>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_RGA {
+                    reg = <RK3399_PD_RGA>;
+                    clocks = <&cru ACLK_RGA>,
+                             <&cru HCLK_RGA>;
+                    pm_qos = <&qos_rga_r>,
+                             <&qos_rga_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VCODEC {
+                    reg = <RK3399_PD_VCODEC>;
+                    clocks = <&cru ACLK_VCODEC>,
+                             <&cru HCLK_VCODEC>;
+                    pm_qos = <&qos_video_m0>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VDU {
+                    reg = <RK3399_PD_VDU>;
+                    clocks = <&cru ACLK_VDU>,
+                             <&cru HCLK_VDU>;
+                    pm_qos = <&qos_video_m1_r>,
+                             <&qos_video_m1_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VIO {
+                    reg = <RK3399_PD_VIO>;
+                    #power-domain-cells = <1>;
+                    #address-cells = <1>;
+                    #size-cells = <0>;
+
+                    power-domain at RK3399_PD_HDCP {
+                        reg = <RK3399_PD_HDCP>;
+                        clocks = <&cru ACLK_HDCP>,
+                                 <&cru HCLK_HDCP>,
+                                 <&cru PCLK_HDCP>;
+                        pm_qos = <&qos_hdcp>;
+                        #power-domain-cells = <0>;
+                    };
+                };
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
deleted file mode 100644
index 8304eceb6..000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-* Rockchip Power Domains
-
-Rockchip processors include support for multiple power domains which can be
-powered up/down by software based on different application scenes to save power.
-
-Required properties for power domain controller:
-- compatible: Should be one of the following.
-	"rockchip,px30-power-controller" - for PX30 SoCs.
-	"rockchip,rk3036-power-controller" - for RK3036 SoCs.
-	"rockchip,rk3066-power-controller" - for RK3066 SoCs.
-	"rockchip,rk3128-power-controller" - for RK3128 SoCs.
-	"rockchip,rk3188-power-controller" - for RK3188 SoCs.
-	"rockchip,rk3228-power-controller" - for RK3228 SoCs.
-	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
-	"rockchip,rk3328-power-controller" - for RK3328 SoCs.
-	"rockchip,rk3366-power-controller" - for RK3366 SoCs.
-	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
-	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
-- #power-domain-cells: Number of cells in a power-domain specifier.
-	Should be 1 for multiple PM domains.
-- #address-cells: Should be 1.
-- #size-cells: Should be 0.
-
-Required properties for power domain sub nodes:
-- reg: index of the power domain, should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
-	"include/dt-bindings/power/rk3066-power.h" - for RK3066 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
-	"include/dt-bindings/power/rk3188-power.h" - for RK3188 type power domain.
-	"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
-- clocks (optional): phandles to clocks which need to be enabled while power domain
-	switches state.
-- pm_qos (optional): phandles to qos blocks which need to be saved and restored
-	while power domain switches state.
-
-Qos Example:
-
-	qos_gpu: qos_gpu at ffaf0000 {
-		compatible ="syscon";
-		reg = <0x0 0xffaf0000 0x0 0x20>;
-	};
-
-Example:
-
-	power: power-controller {
-		compatible = "rockchip,rk3288-power-controller";
-		#power-domain-cells = <1>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pd_gpu {
-			reg = <RK3288_PD_GPU>;
-			clocks = <&cru ACLK_GPU>;
-			pm_qos = <&qos_gpu>;
-		};
-	};
-
-	 power: power-controller {
-                compatible = "rockchip,rk3368-power-controller";
-                #power-domain-cells = <1>;
-                #address-cells = <1>;
-                #size-cells = <0>;
-
-                pd_gpu_1 {
-                        reg = <RK3368_PD_GPU_1>;
-                        clocks = <&cru ACLK_GPU_CFG>;
-                };
-        };
-
-Example 2:
-		power: power-controller {
-			compatible = "rockchip,rk3399-power-controller";
-			#power-domain-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			pd_vio {
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <RK3399_PD_VIO>;
-
-				pd_vo {
-					#address-cells = <1>;
-					#size-cells = <0>;
-					reg = <RK3399_PD_VO>;
-
-					pd_vopb {
-						reg = <RK3399_PD_VOPB>;
-					};
-
-					pd_vopl {
-						reg = <RK3399_PD_VOPL>;
-					};
-				};
-			};
-		};
-
-Node of a device using power domains must have a power-domains property,
-containing a phandle to the power device node and an index specifying which
-power domain to use.
-The index should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for px30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
-
-Example of the node using power domain:
-
-	node {
-		/* ... */
-		power-domains = <&power RK3288_PD_GPU>;
-		/* ... */
-	};
-
-	node {
-                /* ... */
-                power-domains = <&power RK3368_PD_GPU_1>;
-                /* ... */
-        };
-
-	node {
-		/* ... */
-		power-domains = <&power RK3399_PD_VOPB>;
-		/* ... */
-	};
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:55 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:55 +0200
Subject: [PATCH v7 10/11] dt-bindings: power: rockchip: Add bindings for
 RK3568 Soc
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-11-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the compatible string for RK3568 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
index 934308006..1354f1dc0 100644
--- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -37,6 +37,7 @@ properties:
       - rockchip,rk3366-power-controller
       - rockchip,rk3368-power-controller
       - rockchip,rk3399-power-controller
+      - rockchip,rk3568-power-controller
 
   "#power-domain-cells":
     const: 1
@@ -82,6 +83,7 @@ patternProperties:
           "include/dt-bindings/power/rk3366-power.h"
           "include/dt-bindings/power/rk3368-power.h"
           "include/dt-bindings/power/rk3399-power.h"
+          "include/dt-bindings/power/rk3568-power.h"
 
       clocks:
         description: |
-- 
2.11.0



From jbx6244 at gmail.com  Wed Apr 14 22:18:52 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 14 Apr 2021 23:18:52 +0200
Subject: [PATCH v7 07/11] soc: rockchip: pm-domains: Add a meaningful power
 domain name
In-Reply-To: <20210414211856.12104-1-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
Message-ID: <20210414211856.12104-8-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the power domains names to the power domain info struct so we
have meaningful name for every power domain.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix TAB warning
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 221 ++++++++++++++++++++------------------
 1 file changed, 114 insertions(+), 107 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 54eb6cfc5..1d1b06672 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -29,6 +29,7 @@
 #include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
+	const char *name;
 	int pwr_mask;
 	int status_mask;
 	int req_mask;
@@ -85,8 +86,9 @@ struct rockchip_pmu {
 
 #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
 
-#define DOMAIN(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
 	.req_mask = (req),				\
@@ -95,8 +97,9 @@ struct rockchip_pmu {
 	.active_wakeup = (wakeup),			\
 }
 
-#define DOMAIN_M(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN_M(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_w_mask = (pwr) << 16,			\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
@@ -107,8 +110,9 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_RK3036(req, ack, idle, wakeup)		\
+#define DOMAIN_RK3036(_name, req, ack, idle, wakeup)		\
 {							\
+	.name = _name,				\
 	.req_mask = (req),				\
 	.req_w_mask = (req) << 16,			\
 	.ack_mask = (ack),				\
@@ -116,20 +120,20 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_PX30(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_PX30(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3288(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, (req) << 16, wakeup)
+#define DOMAIN_RK3288(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, (req) << 16, wakeup)
 
-#define DOMAIN_RK3328(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, pwr, req, (req) << 10, req, wakeup)
+#define DOMAIN_RK3328(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, (req) << 10, req, wakeup)
 
-#define DOMAIN_RK3368(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_RK3368(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3399(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, req, wakeup)
+#define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
@@ -490,7 +494,10 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
 		goto err_unprepare_clocks;
 	}
 
-	pd->genpd.name = node->name;
+	if (pd->info->name)
+		pd->genpd.name = pd->info->name;
+	else
+		pd->genpd.name = kbasename(node->full_name);
 	pd->genpd.power_off = rockchip_pd_power_off;
 	pd->genpd.power_on = rockchip_pd_power_on;
 	pd->genpd.attach_dev = rockchip_pd_attach_dev;
@@ -716,129 +723,129 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 }
 
 static const struct rockchip_domain_info px30_pm_domains[] = {
-	[PX30_PD_USB]		= DOMAIN_PX30(BIT(5),  BIT(5),  BIT(10), false),
-	[PX30_PD_SDCARD]	= DOMAIN_PX30(BIT(8),  BIT(8),  BIT(9),  false),
-	[PX30_PD_GMAC]		= DOMAIN_PX30(BIT(10), BIT(10), BIT(6),  false),
-	[PX30_PD_MMC_NAND]	= DOMAIN_PX30(BIT(11), BIT(11), BIT(5),  false),
-	[PX30_PD_VPU]		= DOMAIN_PX30(BIT(12), BIT(12), BIT(14), false),
-	[PX30_PD_VO]		= DOMAIN_PX30(BIT(13), BIT(13), BIT(7),  false),
-	[PX30_PD_VI]		= DOMAIN_PX30(BIT(14), BIT(14), BIT(8),  false),
-	[PX30_PD_GPU]		= DOMAIN_PX30(BIT(15), BIT(15), BIT(2),  false),
+	[PX30_PD_USB]		= DOMAIN_PX30("usb",      BIT(5),  BIT(5),  BIT(10), false),
+	[PX30_PD_SDCARD]	= DOMAIN_PX30("sdcard",   BIT(8),  BIT(8),  BIT(9),  false),
+	[PX30_PD_GMAC]		= DOMAIN_PX30("gmac",     BIT(10), BIT(10), BIT(6),  false),
+	[PX30_PD_MMC_NAND]	= DOMAIN_PX30("mmc_nand", BIT(11), BIT(11), BIT(5),  false),
+	[PX30_PD_VPU]		= DOMAIN_PX30("vpu",      BIT(12), BIT(12), BIT(14), false),
+	[PX30_PD_VO]		= DOMAIN_PX30("vo",       BIT(13), BIT(13), BIT(7),  false),
+	[PX30_PD_VI]		= DOMAIN_PX30("vi",       BIT(14), BIT(14), BIT(8),  false),
+	[PX30_PD_GPU]		= DOMAIN_PX30("gpu",      BIT(15), BIT(15), BIT(2),  false),
 };
 
 static const struct rockchip_domain_info rk3036_pm_domains[] = {
-	[RK3036_PD_MSCH]	= DOMAIN_RK3036(BIT(14), BIT(23), BIT(30), true),
-	[RK3036_PD_CORE]	= DOMAIN_RK3036(BIT(13), BIT(17), BIT(24), false),
-	[RK3036_PD_PERI]	= DOMAIN_RK3036(BIT(12), BIT(18), BIT(25), false),
-	[RK3036_PD_VIO]		= DOMAIN_RK3036(BIT(11), BIT(19), BIT(26), false),
-	[RK3036_PD_VPU]		= DOMAIN_RK3036(BIT(10), BIT(20), BIT(27), false),
-	[RK3036_PD_GPU]		= DOMAIN_RK3036(BIT(9),  BIT(21), BIT(28), false),
-	[RK3036_PD_SYS]		= DOMAIN_RK3036(BIT(8),  BIT(22), BIT(29), false),
+	[RK3036_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(14), BIT(23), BIT(30), true),
+	[RK3036_PD_CORE]	= DOMAIN_RK3036("core", BIT(13), BIT(17), BIT(24), false),
+	[RK3036_PD_PERI]	= DOMAIN_RK3036("peri", BIT(12), BIT(18), BIT(25), false),
+	[RK3036_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(11), BIT(19), BIT(26), false),
+	[RK3036_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(10), BIT(20), BIT(27), false),
+	[RK3036_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(9),  BIT(21), BIT(28), false),
+	[RK3036_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(8),  BIT(22), BIT(29), false),
 };
 
 static const struct rockchip_domain_info rk3066_pm_domains[] = {
-	[RK3066_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3066_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3066_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3066_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3066_PD_CPU]		= DOMAIN(0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3066_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3066_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3066_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3066_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3066_PD_CPU]		= DOMAIN("cpu",   0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3128_pm_domains[] = {
-	[RK3128_PD_CORE]	= DOMAIN_RK3288(BIT(0), BIT(0), BIT(4), false),
-	[RK3128_PD_MSCH]	= DOMAIN_RK3288(0,      0,      BIT(6), true),
-	[RK3128_PD_VIO]		= DOMAIN_RK3288(BIT(3), BIT(3), BIT(2), false),
-	[RK3128_PD_VIDEO]	= DOMAIN_RK3288(BIT(2), BIT(2), BIT(1), false),
-	[RK3128_PD_GPU]		= DOMAIN_RK3288(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),
 };
 
 static const struct rockchip_domain_info rk3188_pm_domains[] = {
-	[RK3188_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3188_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3188_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3188_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3188_PD_CPU]		= DOMAIN(BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3188_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3188_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3188_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3188_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3188_PD_CPU]		= DOMAIN("cpu",   BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3228_pm_domains[] = {
-	[RK3228_PD_CORE]	= DOMAIN_RK3036(BIT(0),  BIT(0),  BIT(16), true),
-	[RK3228_PD_MSCH]	= DOMAIN_RK3036(BIT(1),  BIT(1),  BIT(17), true),
-	[RK3228_PD_BUS]		= DOMAIN_RK3036(BIT(2),  BIT(2),  BIT(18), true),
-	[RK3228_PD_SYS]		= DOMAIN_RK3036(BIT(3),  BIT(3),  BIT(19), true),
-	[RK3228_PD_VIO]		= DOMAIN_RK3036(BIT(4),  BIT(4),  BIT(20), false),
-	[RK3228_PD_VOP]		= DOMAIN_RK3036(BIT(5),  BIT(5),  BIT(21), false),
-	[RK3228_PD_VPU]		= DOMAIN_RK3036(BIT(6),  BIT(6),  BIT(22), false),
-	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036(BIT(7),  BIT(7),  BIT(23), false),
-	[RK3228_PD_GPU]		= DOMAIN_RK3036(BIT(8),  BIT(8),  BIT(24), false),
-	[RK3228_PD_PERI]	= DOMAIN_RK3036(BIT(9),  BIT(9),  BIT(25), true),
-	[RK3228_PD_GMAC]	= DOMAIN_RK3036(BIT(10), BIT(10), BIT(26), false),
+	[RK3228_PD_CORE]	= DOMAIN_RK3036("core", BIT(0),  BIT(0),  BIT(16), true),
+	[RK3228_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(1),  BIT(1),  BIT(17), true),
+	[RK3228_PD_BUS]		= DOMAIN_RK3036("bus",  BIT(2),  BIT(2),  BIT(18), true),
+	[RK3228_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(3),  BIT(3),  BIT(19), true),
+	[RK3228_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(4),  BIT(4),  BIT(20), false),
+	[RK3228_PD_VOP]		= DOMAIN_RK3036("vop",  BIT(5),  BIT(5),  BIT(21), false),
+	[RK3228_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(6),  BIT(6),  BIT(22), false),
+	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036("vdec", BIT(7),  BIT(7),  BIT(23), false),
+	[RK3228_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(8),  BIT(8),  BIT(24), false),
+	[RK3228_PD_PERI]	= DOMAIN_RK3036("peri", BIT(9),  BIT(9),  BIT(25), true),
+	[RK3228_PD_GMAC]	= DOMAIN_RK3036("gmac", BIT(10), BIT(10), BIT(26), false),
 };
 
 static const struct rockchip_domain_info rk3288_pm_domains[] = {
-	[RK3288_PD_VIO]		= DOMAIN_RK3288(BIT(7),  BIT(7),  BIT(4), false),
-	[RK3288_PD_HEVC]	= DOMAIN_RK3288(BIT(14), BIT(10), BIT(9), false),
-	[RK3288_PD_VIDEO]	= DOMAIN_RK3288(BIT(8),  BIT(8),  BIT(3), false),
-	[RK3288_PD_GPU]		= DOMAIN_RK3288(BIT(9),  BIT(9),  BIT(2), false),
+	[RK3288_PD_VIO]		= DOMAIN_RK3288("vio",   BIT(7),  BIT(7),  BIT(4), false),
+	[RK3288_PD_HEVC]	= DOMAIN_RK3288("hevc",  BIT(14), BIT(10), BIT(9), false),
+	[RK3288_PD_VIDEO]	= DOMAIN_RK3288("video", BIT(8),  BIT(8),  BIT(3), false),
+	[RK3288_PD_GPU]		= DOMAIN_RK3288("gpu",   BIT(9),  BIT(9),  BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3328_pm_domains[] = {
-	[RK3328_PD_CORE]	= DOMAIN_RK3328(0, BIT(0), BIT(0), false),
-	[RK3328_PD_GPU]		= DOMAIN_RK3328(0, BIT(1), BIT(1), false),
-	[RK3328_PD_BUS]		= DOMAIN_RK3328(0, BIT(2), BIT(2), true),
-	[RK3328_PD_MSCH]	= DOMAIN_RK3328(0, BIT(3), BIT(3), true),
-	[RK3328_PD_PERI]	= DOMAIN_RK3328(0, BIT(4), BIT(4), true),
-	[RK3328_PD_VIDEO]	= DOMAIN_RK3328(0, BIT(5), BIT(5), false),
-	[RK3328_PD_HEVC]	= DOMAIN_RK3328(0, BIT(6), BIT(6), false),
-	[RK3328_PD_VIO]		= DOMAIN_RK3328(0, BIT(8), BIT(8), false),
-	[RK3328_PD_VPU]		= DOMAIN_RK3328(0, BIT(9), BIT(9), false),
+	[RK3328_PD_CORE]	= DOMAIN_RK3328("core",  0, BIT(0), BIT(0), false),
+	[RK3328_PD_GPU]		= DOMAIN_RK3328("gpu",   0, BIT(1), BIT(1), false),
+	[RK3328_PD_BUS]		= DOMAIN_RK3328("bus",   0, BIT(2), BIT(2), true),
+	[RK3328_PD_MSCH]	= DOMAIN_RK3328("msch",  0, BIT(3), BIT(3), true),
+	[RK3328_PD_PERI]	= DOMAIN_RK3328("peri",  0, BIT(4), BIT(4), true),
+	[RK3328_PD_VIDEO]	= DOMAIN_RK3328("video", 0, BIT(5), BIT(5), false),
+	[RK3328_PD_HEVC]	= DOMAIN_RK3328("hevc",  0, BIT(6), BIT(6), false),
+	[RK3328_PD_VIO]		= DOMAIN_RK3328("vio",   0, BIT(8), BIT(8), false),
+	[RK3328_PD_VPU]		= DOMAIN_RK3328("vpu",   0, BIT(9), BIT(9), false),
 };
 
 static const struct rockchip_domain_info rk3366_pm_domains[] = {
-	[RK3366_PD_PERI]	= DOMAIN_RK3368(BIT(10), BIT(10), BIT(6), true),
-	[RK3366_PD_VIO]		= DOMAIN_RK3368(BIT(14), BIT(14), BIT(8), false),
-	[RK3366_PD_VIDEO]	= DOMAIN_RK3368(BIT(13), BIT(13), BIT(7), false),
-	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368(BIT(11), BIT(11), BIT(7), false),
-	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368(BIT(8),  BIT(8),  BIT(9), false),
-	[RK3366_PD_VPU]		= DOMAIN_RK3368(BIT(12), BIT(12), BIT(7), false),
-	[RK3366_PD_GPU]		= DOMAIN_RK3368(BIT(15), BIT(15), BIT(2), false),
+	[RK3366_PD_PERI]	= DOMAIN_RK3368("peri",   BIT(10), BIT(10), BIT(6), true),
+	[RK3366_PD_VIO]		= DOMAIN_RK3368("vio",    BIT(14), BIT(14), BIT(8), false),
+	[RK3366_PD_VIDEO]	= DOMAIN_RK3368("video",  BIT(13), BIT(13), BIT(7), false),
+	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368("vdec",   BIT(11), BIT(11), BIT(7), false),
+	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368("wifibt", BIT(8),  BIT(8),  BIT(9), false),
+	[RK3366_PD_VPU]		= DOMAIN_RK3368("vpu",    BIT(12), BIT(12), BIT(7), false),
+	[RK3366_PD_GPU]		= DOMAIN_RK3368("gpu",    BIT(15), BIT(15), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3368_pm_domains[] = {
-	[RK3368_PD_PERI]	= DOMAIN_RK3368(BIT(13), BIT(12), BIT(6), true),
-	[RK3368_PD_VIO]		= DOMAIN_RK3368(BIT(15), BIT(14), BIT(8), false),
-	[RK3368_PD_VIDEO]	= DOMAIN_RK3368(BIT(14), BIT(13), BIT(7), false),
-	[RK3368_PD_GPU_0]	= DOMAIN_RK3368(BIT(16), BIT(15), BIT(2), false),
-	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(BIT(17), BIT(16), BIT(2), false),
+	[RK3368_PD_PERI]	= DOMAIN_RK3368("peri",  BIT(13), BIT(12), BIT(6), true),
+	[RK3368_PD_VIO]		= DOMAIN_RK3368("vio",   BIT(15), BIT(14), BIT(8), false),
+	[RK3368_PD_VIDEO]	= DOMAIN_RK3368("video", BIT(14), BIT(13), BIT(7), false),
+	[RK3368_PD_GPU_0]	= DOMAIN_RK3368("gpu_0", BIT(16), BIT(15), BIT(2), false),
+	[RK3368_PD_GPU_1]	= DOMAIN_RK3368("gpu_1", BIT(17), BIT(16), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3399_pm_domains[] = {
-	[RK3399_PD_TCPD0]	= DOMAIN_RK3399(BIT(8),  BIT(8),  0,	   false),
-	[RK3399_PD_TCPD1]	= DOMAIN_RK3399(BIT(9),  BIT(9),  0,	   false),
-	[RK3399_PD_CCI]		= DOMAIN_RK3399(BIT(10), BIT(10), 0,	   true),
-	[RK3399_PD_CCI0]	= DOMAIN_RK3399(0,	 0,	  BIT(15), true),
-	[RK3399_PD_CCI1]	= DOMAIN_RK3399(0,	 0,	  BIT(16), true),
-	[RK3399_PD_PERILP]	= DOMAIN_RK3399(BIT(11), BIT(11), BIT(1),  true),
-	[RK3399_PD_PERIHP]	= DOMAIN_RK3399(BIT(12), BIT(12), BIT(2),  true),
-	[RK3399_PD_CENTER]	= DOMAIN_RK3399(BIT(13), BIT(13), BIT(14), true),
-	[RK3399_PD_VIO]		= DOMAIN_RK3399(BIT(14), BIT(14), BIT(17), false),
-	[RK3399_PD_GPU]		= DOMAIN_RK3399(BIT(15), BIT(15), BIT(0),  false),
-	[RK3399_PD_VCODEC]	= DOMAIN_RK3399(BIT(16), BIT(16), BIT(3),  false),
-	[RK3399_PD_VDU]		= DOMAIN_RK3399(BIT(17), BIT(17), BIT(4),  false),
-	[RK3399_PD_RGA]		= DOMAIN_RK3399(BIT(18), BIT(18), BIT(5),  false),
-	[RK3399_PD_IEP]		= DOMAIN_RK3399(BIT(19), BIT(19), BIT(6),  false),
-	[RK3399_PD_VO]		= DOMAIN_RK3399(BIT(20), BIT(20), 0,	   false),
-	[RK3399_PD_VOPB]	= DOMAIN_RK3399(0,	 0,	  BIT(7),  false),
-	[RK3399_PD_VOPL]	= DOMAIN_RK3399(0, 	 0,	  BIT(8),  false),
-	[RK3399_PD_ISP0]	= DOMAIN_RK3399(BIT(22), BIT(22), BIT(9),  false),
-	[RK3399_PD_ISP1]	= DOMAIN_RK3399(BIT(23), BIT(23), BIT(10), false),
-	[RK3399_PD_HDCP]	= DOMAIN_RK3399(BIT(24), BIT(24), BIT(11), false),
-	[RK3399_PD_GMAC]	= DOMAIN_RK3399(BIT(25), BIT(25), BIT(23), true),
-	[RK3399_PD_EMMC]	= DOMAIN_RK3399(BIT(26), BIT(26), BIT(24), true),
-	[RK3399_PD_USB3]	= DOMAIN_RK3399(BIT(27), BIT(27), BIT(12), true),
-	[RK3399_PD_EDP]		= DOMAIN_RK3399(BIT(28), BIT(28), BIT(22), false),
-	[RK3399_PD_GIC]		= DOMAIN_RK3399(BIT(29), BIT(29), BIT(27), true),
-	[RK3399_PD_SD]		= DOMAIN_RK3399(BIT(30), BIT(30), BIT(28), true),
-	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399(BIT(31), BIT(31), BIT(29), true),
+	[RK3399_PD_TCPD0]	= DOMAIN_RK3399("tcpd0",     BIT(8),  BIT(8),  0,       false),
+	[RK3399_PD_TCPD1]	= DOMAIN_RK3399("tcpd1",     BIT(9),  BIT(9),  0,       false),
+	[RK3399_PD_CCI]		= DOMAIN_RK3399("cci",       BIT(10), BIT(10), 0,       true),
+	[RK3399_PD_CCI0]	= DOMAIN_RK3399("cci0",      0,       0,       BIT(15), true),
+	[RK3399_PD_CCI1]	= DOMAIN_RK3399("cci1",      0,       0,       BIT(16), true),
+	[RK3399_PD_PERILP]	= DOMAIN_RK3399("perilp",    BIT(11), BIT(11), BIT(1),  true),
+	[RK3399_PD_PERIHP]	= DOMAIN_RK3399("perihp",    BIT(12), BIT(12), BIT(2),  true),
+	[RK3399_PD_CENTER]	= DOMAIN_RK3399("center",    BIT(13), BIT(13), BIT(14), true),
+	[RK3399_PD_VIO]		= DOMAIN_RK3399("vio",       BIT(14), BIT(14), BIT(17), false),
+	[RK3399_PD_GPU]		= DOMAIN_RK3399("gpu",       BIT(15), BIT(15), BIT(0),  false),
+	[RK3399_PD_VCODEC]	= DOMAIN_RK3399("vcodec",    BIT(16), BIT(16), BIT(3),  false),
+	[RK3399_PD_VDU]		= DOMAIN_RK3399("vdu",       BIT(17), BIT(17), BIT(4),  false),
+	[RK3399_PD_RGA]		= DOMAIN_RK3399("rga",       BIT(18), BIT(18), BIT(5),  false),
+	[RK3399_PD_IEP]		= DOMAIN_RK3399("iep",       BIT(19), BIT(19), BIT(6),  false),
+	[RK3399_PD_VO]		= DOMAIN_RK3399("vo",        BIT(20), BIT(20), 0,       false),
+	[RK3399_PD_VOPB]	= DOMAIN_RK3399("vopb",      0,       0,       BIT(7),  false),
+	[RK3399_PD_VOPL]	= DOMAIN_RK3399("vopl",      0,       0,       BIT(8),  false),
+	[RK3399_PD_ISP0]	= DOMAIN_RK3399("isp0",      BIT(22), BIT(22), BIT(9),  false),
+	[RK3399_PD_ISP1]	= DOMAIN_RK3399("isp1",      BIT(23), BIT(23), BIT(10), false),
+	[RK3399_PD_HDCP]	= DOMAIN_RK3399("hdcp",      BIT(24), BIT(24), BIT(11), false),
+	[RK3399_PD_GMAC]	= DOMAIN_RK3399("gmac",      BIT(25), BIT(25), BIT(23), true),
+	[RK3399_PD_EMMC]	= DOMAIN_RK3399("emmc",      BIT(26), BIT(26), BIT(24), true),
+	[RK3399_PD_USB3]	= DOMAIN_RK3399("usb3",      BIT(27), BIT(27), BIT(12), true),
+	[RK3399_PD_EDP]		= DOMAIN_RK3399("edp",       BIT(28), BIT(28), BIT(22), false),
+	[RK3399_PD_GIC]		= DOMAIN_RK3399("gic",       BIT(29), BIT(29), BIT(27), true),
+	[RK3399_PD_SD]		= DOMAIN_RK3399("sd",        BIT(30), BIT(30), BIT(28), true),
+	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
 static const struct rockchip_pmu_info px30_pmu = {
-- 
2.11.0



From willy at infradead.org  Wed Apr 14 22:35:56 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Wed, 14 Apr 2021 22:35:56 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414211322.3799afd4@carbon>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
Message-ID: <20210414213556.GY2531743@casper.infradead.org>

On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> (If others want to reproduce).  First I could not reproduce on ARM32.
> Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.

hmmm ... you should be able to provoke it by enabling ARM_LPAE,
which selects PHYS_ADDR_T_64BIT, and

config ARCH_DMA_ADDR_T_64BIT
        def_bool 64BIT || PHYS_ADDR_T_64BIT

>  struct page {
>         long unsigned int          flags;                /*     0     4 */
> 
>         /* XXX 4 bytes hole, try to pack */
> 
>         union {
>                 struct {
>                         struct list_head lru;            /*     8     8 */
>                         struct address_space * mapping;  /*    16     4 */
>                         long unsigned int index;         /*    20     4 */
>                         long unsigned int private;       /*    24     4 */
>                 };                                       /*     8    20 */
>                 struct {
>                         dma_addr_t dma_addr;             /*     8     8 */
>                 };                                       /*     8     8 */
[...]
>         } __attribute__((__aligned__(8)));               /*     8    24 */
>         union {
>                 atomic_t           _mapcount;            /*    32     4 */
>                 unsigned int       page_type;            /*    32     4 */
>                 unsigned int       active;               /*    32     4 */
>                 int                units;                /*    32     4 */
>         };                                               /*    32     4 */
>         atomic_t                   _refcount;            /*    36     4 */
> 
>         /* size: 40, cachelines: 1, members: 4 */
>         /* sum members: 36, holes: 1, sum holes: 4 */
>         /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
>         /* last cacheline: 40 bytes */
> } __attribute__((__aligned__(8)));

If you also enable CONFIG_MEMCG or enough options to make
LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte
hole at the end.


From ndesaulniers at google.com  Wed Apr 14 22:45:45 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Wed, 14 Apr 2021 14:45:45 -0700
Subject: [PATCH v2] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <YHYlQnFRMNdn/CDp@archlinux-ax161>
References: <YHYlQnFRMNdn/CDp@archlinux-ax161>
Message-ID: <20210414214548.700993-1-ndesaulniers@google.com>

Clang can assemble these files just fine; this is a relic from the top
level Makefile conditionally adding this. We no longer need --prefix,
--gcc-toolchain, or -Qunused-arguments flags either with this change, so
remove those too.

To test building:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
  CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
  defconfig arch/arm64/kernel/vdso32/

Suggested-by: Nathan Chancellor <nathan at kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
---
Changes V1 -> V2:
* Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and
  COMPAT_GCC_TOOLCHAIN_DIR as per Nathan.
* Credit Nathan with Suggested-by tag.
* Remove -Qunused-arguments.
* Update commit message.

 arch/arm64/kernel/vdso32/Makefile | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 789ad420f16b..3dba0c4f8f42 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile
 
 # Same as cc-*option, but using CC_COMPAT instead of CC
 ifeq ($(CONFIG_CC_IS_CLANG), y)
-COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE_COMPAT)elfedit))
-COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
-
 CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
-CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
-CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
-ifneq ($(COMPAT_GCC_TOOLCHAIN),)
-CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
-endif
 
 CC_COMPAT ?= $(CC)
 CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
-- 
2.31.1.295.g9ea45b61b8-goog



From David.Laight at ACULAB.COM  Wed Apr 14 22:56:39 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 14 Apr 2021 21:56:39 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210414213556.GY2531743@casper.infradead.org>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
Message-ID: <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>

From: Matthew Wilcox
> Sent: 14 April 2021 22:36
> 
> On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > (If others want to reproduce).  First I could not reproduce on ARM32.
> > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
> 
> hmmm ... you should be able to provoke it by enabling ARM_LPAE,
> which selects PHYS_ADDR_T_64BIT, and
> 
> config ARCH_DMA_ADDR_T_64BIT
>         def_bool 64BIT || PHYS_ADDR_T_64BIT
> 
> >  struct page {
> >         long unsigned int          flags;                /*     0     4 */
> >
> >         /* XXX 4 bytes hole, try to pack */
> >
> >         union {
> >                 struct {
> >                         struct list_head lru;            /*     8     8 */
> >                         struct address_space * mapping;  /*    16     4 */
> >                         long unsigned int index;         /*    20     4 */
> >                         long unsigned int private;       /*    24     4 */
> >                 };                                       /*     8    20 */
> >                 struct {
> >                         dma_addr_t dma_addr

Adding __packed here will remove the 4 byte hole before the union
and the compiler seems clever enough to know that anything following
a 'long' must also be 'long' aligned.
So you don't get anything horrid like byte accesses.
On 64bit dma_addr will remain 64bit aligned.
On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access
won't make any difference.

So definitely the only simple fix.

	David

> >                                            ;             /*     8     8 */
> >                 };                                       /*     8     8 */
> [...]
> >         } __attribute__((__aligned__(8)));               /*     8    24 */
> >         union {
> >                 atomic_t           _mapcount;            /*    32     4 */
> >                 unsigned int       page_type;            /*    32     4 */
> >                 unsigned int       active;               /*    32     4 */
> >                 int                units;                /*    32     4 */
> >         };                                               /*    32     4 */
> >         atomic_t                   _refcount;            /*    36     4 */
> >
> >         /* size: 40, cachelines: 1, members: 4 */
> >         /* sum members: 36, holes: 1, sum holes: 4 */
> >         /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
> >         /* last cacheline: 40 bytes */
> > } __attribute__((__aligned__(8)));
> 
> If you also enable CONFIG_MEMCG or enough options to make
> LAST_CPUPID_NOT_IN_PAGE_FLAGS true, you'll end up with another 4-byte
> hole at the end.

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From robh at kernel.org  Wed Apr 14 23:15:53 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 17:15:53 -0500
Subject: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
In-Reply-To: <20210414104939.1093-2-billy_tsai@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
 <20210414104939.1093-2-billy_tsai@aspeedtech.com>
Message-ID: <20210414221553.GA56046@robh.at.kernel.org>

On Wed, Apr 14, 2021 at 06:49:38PM +0800, Billy Tsai wrote:
> This patch adds device bindings for aspeed pwm-tach device which is a
> multi-function device include pwn and tach function and pwm device which
> should be the sub-node of pwm-tach device.
> 
> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545

Drop

> ---
>  .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++++++++++++++++++
>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 44 ++++++++++++++
>  2 files changed, 104 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> new file mode 100644
> index 000000000000..eaf8bdf8d44e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 ASPEED, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM Tach controller Device Tree Bindings
> +
> +description: |
> +  The PWM Tach controller is represented as a multi-function device which
> +  includes:
> +    PWM
> +    Tach

But is it really? A PWM and tach sounds like a fan controller. Look at 
other existing PWM+tach bindings we have for fans.

> +
> +maintainers:
> +  - Billy Tsai <billy_tsai at aspeedtech.com>
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - aspeed,ast2600-pwm-tach
> +      - const: syscon
> +      - const: simple-mfd
> +  reg:
> +    maxItems: 1
> +  "#address-cells":
> +    const: 1
> +  "#size-cells":
> +    const: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - "#address-cells"
> +  - "#size-cells"
> +
> +additionalProperties:
> +  type: object

As you know the 2 node names, they should be documented. However, see 
below.

> +
> +examples:
> +  - |
> +    pwm_tach: pwm_tach at 1e610000 {
> +      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +      reg = <0x1e610000 0x100>;
> +
> +      pwm: pwm at 0 {
> +        compatible = "aspeed,ast2600-pwm";
> +        #pwm-cells = <3>;
> +        reg = <0x0 0x100>;
> +      };
> +
> +      tach: tach at 1 {
> +        compatible = "aspeed,ast2600-tach";
> +        reg = <0x0 0x100>;

You have 2 nodes at the same address. Not valid.

> +      };

There's no real need for 2 child nodes. The parent node can be a PWM 
provider.

> +    };
> diff --git a/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> new file mode 100644
> index 000000000000..97923e68ccb9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2021 ASPEED, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/aspeed,ast2600-pwm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED AST2600 PWM controller
> +
> +maintainers:
> +  - Billy Tsai <billy_tsai at aspeedtech.com>
> +
> +description: |
> +  The ASPEED PWM controller can support upto 16 PWM outputs.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - aspeed,ast2600-pwm
> +
> +  "#pwm-cells":
> +    const: 3
> +
> +  reg:
> +    maxItems: 1
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    // The PWM should be a subnode of a "aspeed,ast2600-pwm-tach" compatible
> +    // node.
> +    pwm_tach: pwm_tach at 1e610000 {
> +      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +      reg = <0x1e610000 0x100>;
> +
> +      pwm: pwm at 0 {
> +        compatible = "aspeed,ast2600-pwm";
> +        #pwm-cells = <3>;
> +        reg = <0x0 0x100>;
> +      };
> +    };
> -- 
> 2.25.1
> 


From robh at kernel.org  Wed Apr 14 23:19:26 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 17:19:26 -0500
Subject: [Intel-gfx] [PATCH v19 2/6] dt-binding: i2c: mt65xx: add
 vbus-supply property
In-Reply-To: <20210414172916.2689361-3-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
 <20210414172916.2689361-3-hsinyi@chromium.org>
Message-ID: <20210414221926.GA69036@robh.at.kernel.org>

On Thu, 15 Apr 2021 01:29:12 +0800, Hsin-Yi Wang wrote:
> Add vbus-supply property for mt65xx. The regulator can be passed into
> core and turned off during suspend/sleep to reduce power consumption.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Wed Apr 14 23:20:23 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 17:20:23 -0500
Subject: [PATCH v7 08/11] dt-bindings: add power-domain header for RK3568
 SoCs
In-Reply-To: <20210414211856.12104-9-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
 <20210414211856.12104-9-jbx6244@gmail.com>
Message-ID: <20210414222023.GA70402@robh.at.kernel.org>

On Wed, 14 Apr 2021 23:18:53 +0200, Johan Jonker wrote:
> From: Elaine Zhang <zhangqing at rock-chips.com>
> 
> According to a description from TRM, add all the power domains
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  include/dt-bindings/power/rk3568-power.h | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>  create mode 100644 include/dt-bindings/power/rk3568-power.h
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Wed Apr 14 23:27:23 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 17:27:23 -0500
Subject: [PATCH v7 09/11] dt-bindings: power: rockchip: Convert to
 json-schema
In-Reply-To: <20210414211856.12104-10-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
 <20210414211856.12104-10-jbx6244@gmail.com>
Message-ID: <20210414222723.GA70669@robh.at.kernel.org>

On Wed, Apr 14, 2021 at 11:18:54PM +0200, Johan Jonker wrote:
> From: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> 
> Convert the soc/rockchip/power_domain.txt binding document to
> json-schema and move to the power bindings directory.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Note for rob+dt:
> A tag was not added on purpose, because:
>   Add "rockchip," prefix to the qos compatible name
>   in example.
>   Changed maintainers.
>   Size reg description is reduced.
>   Little style changes '' to ""
> Please have a look at it again.
> 
> For some SoC nodes this patch serie generates notifications
> for undocumented "assigned-clocks" and "assigned-clock-parents"
> properties till there is consensus of what to do with it.

If the node has 'clocks', then you shouldn't get a warning now.

> ---
> Changed V7:
>   Fix commit message and author format
>   Changed SPDX-License-Identifier back to GPL-2.0
>   Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
>   Fix indent example
> Changed V6:
>   Changed author
> Changed V5:
>   Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
>   Remove a maintainer
>   Changed patternProperties to power-domain
>   Add "clocks", "assigned-clocks" and "assigned-clock-parents"
> Changed V4:
>   Remove new compatible string
>   Style changes '' to ""
> Changed V3:
>   Use Enric's conversion with rk3399 example
> Changed V2:
>   Convert power_domain.txt to YAML with rk3568 example
> ---
>  .../bindings/power/rockchip,power-controller.yaml  | 283 +++++++++++++++++++++
>  .../bindings/soc/rockchip/power_domain.txt         | 136 ----------
>  2 files changed, 283 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> new file mode 100644
> index 000000000..934308006
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> @@ -0,0 +1,283 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip Power Domains
> +
> +maintainers:
> +  - Elaine Zhang <zhangqing at rock-chips.com>
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +description: |
> +  Rockchip processors include support for multiple power domains which can be
> +  powered up/down by software based on different application scenarios to save power.
> +
> +  Power domains contained within power-controller node are generic power domain
> +  providers documented in Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +  IP cores belonging to a power domain should contain a "power-domains"
> +  property that is a phandle for the power domain node representing the domain.
> +
> +properties:
> +  $nodename:
> +    const: power-controller
> +
> +  compatible:
> +    enum:
> +      - rockchip,px30-power-controller
> +      - rockchip,rk3036-power-controller
> +      - rockchip,rk3066-power-controller
> +      - rockchip,rk3128-power-controller
> +      - rockchip,rk3188-power-controller
> +      - rockchip,rk3228-power-controller
> +      - rockchip,rk3288-power-controller
> +      - rockchip,rk3328-power-controller
> +      - rockchip,rk3366-power-controller
> +      - rockchip,rk3368-power-controller
> +      - rockchip,rk3399-power-controller
> +
> +  "#power-domain-cells":
> +    const: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^power-domain@[0-9a-f]+$":
> +    type: object
> +    description: |
> +      Represents the power domains within the power controller node as documented
> +      in Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +    properties:
> +
> +      "#power-domain-cells":
> +        description:
> +          Must be 0 for nodes representing a single PM domain and 1 for nodes
> +          providing multiple PM domains.
> +
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
> +      reg:
> +        maxItems: 1
> +        description: |
> +          Power domain index. Valid values are defined in
> +          "include/dt-bindings/power/px30-power.h"
> +          "include/dt-bindings/power/rk3036-power.h"
> +          "include/dt-bindings/power/rk3066-power.h"
> +          "include/dt-bindings/power/rk3128-power.h"
> +          "include/dt-bindings/power/rk3188-power.h"
> +          "include/dt-bindings/power/rk3228-power.h"
> +          "include/dt-bindings/power/rk3288-power.h"
> +          "include/dt-bindings/power/rk3328-power.h"
> +          "include/dt-bindings/power/rk3366-power.h"
> +          "include/dt-bindings/power/rk3368-power.h"
> +          "include/dt-bindings/power/rk3399-power.h"
> +
> +      clocks:
> +        description: |
> +          A number of phandles to clocks that need to be enabled while power domain
> +          switches state.

I probably asked before, but can we have some max here?

> +
> +      pm_qos:

Needs a type ref.

> +        description: |
> +          A number of phandles to qos blocks which need to be saved and restored
> +          while power domain switches state.
> +
> +    patternProperties:
> +      "^power-domain@[0-9a-f]+$":
> +        type: object
> +        description: |
> +          Represents a power domain child within a power domain parent node.
> +
> +        properties:
> +
> +          "#power-domain-cells":
> +            description:
> +              Must be 0 for nodes representing a single PM domain and 1 for nodes
> +              providing multiple PM domains.
> +
> +          "#address-cells":
> +            const: 1
> +
> +          "#size-cells":
> +            const: 0
> +
> +          reg:
> +            maxItems: 1
> +
> +          clocks:
> +            description: |
> +              A number of phandles to clocks that need to be enabled while power domain
> +              switches state.
> +
> +          pm_qos:
> +            description: |
> +              A number of phandles to qos blocks which need to be saved and restored
> +              while power domain switches state.
> +
> +        patternProperties:
> +          "^power-domain@[0-9a-f]+$":

Create a '$defs' section an avoid the duplication.

> +            type: object
> +            description: |
> +              Represents a power domain child within a power domain parent node.
> +
> +            properties:
> +
> +              "#power-domain-cells":
> +                description:
> +                  Must be 0 for nodes representing a single PM domain and 1 for nodes
> +                  providing multiple PM domains.
> +
> +              "#address-cells":
> +                const: 1
> +
> +              "#size-cells":
> +                const: 0
> +
> +              reg:
> +                maxItems: 1
> +
> +              clocks:
> +                description: |
> +                  A number of phandles to clocks that need to be enabled while power domain
> +                  switches state.
> +
> +              pm_qos:
> +                description: |
> +                  A number of phandles to qos blocks which need to be saved and restored
> +                  while power domain switches state.
> +
> +            required:
> +              - reg
> +
> +            additionalProperties: false
> +
> +        required:
> +          - reg
> +
> +        additionalProperties: false
> +
> +    required:
> +      - reg
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - "#power-domain-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3399-cru.h>
> +    #include <dt-bindings/power/rk3399-power.h>
> +
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        qos_hdcp: qos at ffa90000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffa90000 0x0 0x20>;
> +        };
> +
> +        qos_iep: qos at ffa98000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffa98000 0x0 0x20>;
> +        };
> +
> +        qos_rga_r: qos at ffab0000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab0000 0x0 0x20>;
> +        };
> +
> +        qos_rga_w: qos at ffab0080 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab0080 0x0 0x20>;
> +        };
> +
> +        qos_video_m0: qos at ffab8000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab8000 0x0 0x20>;
> +        };
> +
> +        qos_video_m1_r: qos at ffac0000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffac0000 0x0 0x20>;
> +        };
> +
> +        qos_video_m1_w: qos at ffac0080 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffac0080 0x0 0x20>;
> +        };
> +
> +        power-management at ff310000 {
> +            compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
> +            reg = <0x0 0xff310000 0x0 0x1000>;
> +
> +            power-controller {
> +                compatible = "rockchip,rk3399-power-controller";
> +                #power-domain-cells = <1>;
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                /* These power domains are grouped by VD_CENTER */
> +                power-domain at RK3399_PD_IEP {
> +                    reg = <RK3399_PD_IEP>;
> +                    clocks = <&cru ACLK_IEP>,
> +                             <&cru HCLK_IEP>;
> +                    pm_qos = <&qos_iep>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_RGA {
> +                    reg = <RK3399_PD_RGA>;
> +                    clocks = <&cru ACLK_RGA>,
> +                             <&cru HCLK_RGA>;
> +                    pm_qos = <&qos_rga_r>,
> +                             <&qos_rga_w>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VCODEC {
> +                    reg = <RK3399_PD_VCODEC>;
> +                    clocks = <&cru ACLK_VCODEC>,
> +                             <&cru HCLK_VCODEC>;
> +                    pm_qos = <&qos_video_m0>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VDU {
> +                    reg = <RK3399_PD_VDU>;
> +                    clocks = <&cru ACLK_VDU>,
> +                             <&cru HCLK_VDU>;
> +                    pm_qos = <&qos_video_m1_r>,
> +                             <&qos_video_m1_w>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VIO {
> +                    reg = <RK3399_PD_VIO>;
> +                    #power-domain-cells = <1>;
> +                    #address-cells = <1>;
> +                    #size-cells = <0>;
> +
> +                    power-domain at RK3399_PD_HDCP {
> +                        reg = <RK3399_PD_HDCP>;
> +                        clocks = <&cru ACLK_HDCP>,
> +                                 <&cru HCLK_HDCP>,
> +                                 <&cru PCLK_HDCP>;
> +                        pm_qos = <&qos_hdcp>;
> +                        #power-domain-cells = <0>;
> +                    };
> +                };
> +            };
> +        };
> +    };


From robh at kernel.org  Wed Apr 14 23:27:59 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 14 Apr 2021 17:27:59 -0500
Subject: [PATCH v7 10/11] dt-bindings: power: rockchip: Add bindings for
 RK3568 Soc
In-Reply-To: <20210414211856.12104-11-jbx6244@gmail.com>
References: <20210414211856.12104-1-jbx6244@gmail.com>
 <20210414211856.12104-11-jbx6244@gmail.com>
Message-ID: <20210414222759.GA80384@robh.at.kernel.org>

On Wed, 14 Apr 2021 23:18:55 +0200, Johan Jonker wrote:
> From: Elaine Zhang <zhangqing at rock-chips.com>
> 
> Add the compatible string for RK3568 SoC.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Thu Apr 15 00:13:41 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 15 Apr 2021 07:13:41 +0800
Subject: [arm64:for-next/misc 13/14] ld.lld: error: undefined symbol:
 sve_get_vl
Message-ID: <202104150734.PulXU4BV-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/misc
head:   839157876f97fcc7ead0b62c9377bb50f75a3df9
commit: ef9c5d09797db874a29a97407c3ea3990210432b [13/14] arm64/sve: Remove redundant system_supports_sve() tests
config: arm64-randconfig-r036-20210414 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 9829f5e6b1bca9b61efc629770d28bb9014dec45)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=ef9c5d09797db874a29a97407c3ea3990210432b
        git remote add arm64 https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
        git fetch --no-tags arm64 for-next/misc
        git checkout ef9c5d09797db874a29a97407c3ea3990210432b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: sve_get_vl
   >>> referenced by fpsimd.c
   >>> kernel/fpsimd.o:(fpsimd_save) in archive arch/arm64/built-in.a
--
>> ld.lld: error: undefined symbol: sve_save_state
   >>> referenced by fpsimd.c
   >>> kernel/fpsimd.o:(fpsimd_save) in archive arch/arm64/built-in.a
--
>> ld.lld: error: undefined symbol: sve_load_state
   >>> referenced by fpsimd.c
   >>> kernel/fpsimd.o:(task_fpsimd_load) in archive arch/arm64/built-in.a

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 41296 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210415/86e5fdcb/attachment-0001.gz>

From nathan at kernel.org  Thu Apr 15 01:17:43 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Wed, 14 Apr 2021 17:17:43 -0700
Subject: [PATCH v2] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210414214548.700993-1-ndesaulniers@google.com>
References: <YHYlQnFRMNdn/CDp@archlinux-ax161>
 <20210414214548.700993-1-ndesaulniers@google.com>
Message-ID: <YHeGJzhIhSFJLprr@archlinux-ax161>

On Wed, Apr 14, 2021 at 02:45:45PM -0700, Nick Desaulniers wrote:
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this. We no longer need --prefix,
> --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> remove those too.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/
> 
> Suggested-by: Nathan Chancellor <nathan at kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>

Reviewed-by: Nathan Chancellor <nathan at kernel.org>

> ---
> Changes V1 -> V2:
> * Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and
>   COMPAT_GCC_TOOLCHAIN_DIR as per Nathan.
> * Credit Nathan with Suggested-by tag.
> * Remove -Qunused-arguments.
> * Update commit message.
> 
>  arch/arm64/kernel/vdso32/Makefile | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 789ad420f16b..3dba0c4f8f42 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile
>  
>  # Same as cc-*option, but using CC_COMPAT instead of CC
>  ifeq ($(CONFIG_CC_IS_CLANG), y)
> -COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE_COMPAT)elfedit))
> -COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
> -
>  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
> -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> -ifneq ($(COMPAT_GCC_TOOLCHAIN),)
> -CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
> -endif
>  
>  CC_COMPAT ?= $(CC)
>  CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
> -- 
> 2.31.1.295.g9ea45b61b8-goog
> 
> 


From drinkcat at chromium.org  Thu Apr 15 01:29:04 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Thu, 15 Apr 2021 08:29:04 +0800
Subject: [PATCH 3/3] arm64: dts: mt8183-kukui: fix dtbs_check warnings
In-Reply-To: <20210414144643.17435-3-matthias.bgg@kernel.org>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
 <20210414144643.17435-3-matthias.bgg@kernel.org>
Message-ID: <CANMq1KAxZ+QiRR7LgR22pvhs4us=ne_VtSM-S_byCC0N__6BZA@mail.gmail.com>

On Wed, Apr 14, 2021 at 10:46 PM <matthias.bgg at kernel.org> wrote:
>
> From: Matthias Brugger <matthias.bgg at gmail.com>
>
> The dsi children don't have any reg property,

Confused, see below.

> so we don't need address and
> size cells. This makes dtbs_check happy.
>
> CC: Hsin-Yi Wang <hsinyi at chromium.org>
> CC: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> CC: Nicolas Boichat <drinkcat at chromium.org>
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
>
> ---
>
>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index ff56bcfa3370..f4dca6a33168 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -251,8 +251,7 @@ &cpu7 {
>
>  &dsi0 {
>         status = "okay";
> -       #address-cells = <1>;
> -       #size-cells = <0>;
> +
>         panel: panel at 0 {
>                 /* compatible will be set in board dts */
>                 reg = <0>;

^^ isn't that... a reg property?

> --
> 2.30.2
>


From leo.yan at linaro.org  Thu Apr 15 01:43:25 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 08:43:25 +0800
Subject: [PATCH] coresight: etm-perf: Fix define build issue when built
 as module
In-Reply-To: <20210414194808.22872-1-mike.leach@linaro.org>
References: <20210414194808.22872-1-mike.leach@linaro.org>
Message-ID: <20210415004325.GA955389@leoy-ThinkPad-X240s>

On Wed, Apr 14, 2021 at 08:48:08PM +0100, Mike Leach wrote:
> CONFIG_CORESIGHT_SOURCE_ETM4X is undefined when built as module,
> CONFIG_CORESIGHT_SOURCE_ETM4X_MODULE is defined instead.
> 
> Therefore code in format_attr_contextid_show() not correctly complied
> when coresight built as module.
> 
> Use IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) to correct this.
> 
> Fixes: 88f11864cf1d ("coresight: etm-perf: Support PID tracing for kernel at EL2")
> Signed-off-by: Mike Leach <mike.leach at linaro.org>

Reviewed-by: Leo Yan <leo.yan at linaro.org>

And sorry for introducing mistakes when sending the patches.

> ---
>  drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 560baefdfed8..b2d6db78a025 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -78,7 +78,7 @@ static ssize_t format_attr_contextid_show(struct device *dev,
>  {
>  	int pid_fmt = ETM_OPT_CTXTID;
>  
> -#if defined(CONFIG_CORESIGHT_SOURCE_ETM4X)
> +#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
>  	pid_fmt = is_kernel_in_hyp_mode() ? ETM_OPT_CTXTID2 : ETM_OPT_CTXTID;
>  #endif
>  	return sprintf(page, "config:%d\n", pid_fmt);
> -- 
> 2.17.1
> 


From ck.hu at mediatek.com  Thu Apr 15 02:09:28 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Thu, 15 Apr 2021 09:09:28 +0800
Subject: [SPAM][v2,PATCH 3/3] drm/mediatek: dpi: add bus format negotiation
In-Reply-To: <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <1618448968.29238.1.camel@mtksdaap41>

Hi, Rex:

On Wed, 2021-04-14 at 21:35 +0800, Rex-BC Chen wrote:
> Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
> the possible output and input formats for the current mode and monitor,
> and use the negotiated formats in a basic atomic_check callback.
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 89 ++++++++++++++++++++++++++++--
>  1 file changed, 84 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 76431fe849b8..b4e9c6c8d706 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>  	return 0;
>  }
>  
> +#define MAX_OUTPUT_SEL_FORMATS	2
> +
> +static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> +					struct drm_bridge_state *bridge_state,
> +					struct drm_crtc_state *crtc_state,
> +					struct drm_connector_state *conn_state,
> +					unsigned int *num_output_fmts)
> +{
> +	struct drm_display_mode *mode = &crtc_state->mode;
> +	u32 *output_fmts;
> +	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> +
> +	*num_output_fmts = 0;
> +
> +	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
> +			      GFP_KERNEL);
> +	if (!output_fmts)
> +		return NULL;
> +
> +	/* Default 8bit RGB fallback */
> +	if (dpi->conf->dual_edge) {
> +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
> +		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;

MT8183 does not support MEDIA_BUS_FMT_RGB888_1X24?

Regards,
CK

> +		*num_output_fmts = 2;
> +	} else {
> +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
> +		*num_output_fmts = 1;
> +	}
> +
> +	return output_fmts;
> +}
> +
> +#define MAX_INPUT_SEL_FORMATS	1
> +
> +static u32 *mtk_dpi_bridge_atomic_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)
> +{
> +	u32 *input_fmts;
> +
> +	*num_input_fmts = 0;
> +
> +	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> +			     GFP_KERNEL);
> +	if (!input_fmts)
> +		return NULL;
> +
> +	*num_input_fmts = 1;
> +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> +
> +	return input_fmts;
> +}
> +
> +static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
> +				       struct drm_bridge_state *bridge_state,
> +				       struct drm_crtc_state *crtc_state,
> +				       struct drm_connector_state *conn_state)
> +{
> +	struct mtk_dpi *dpi = bridge->driver_private;
> +	unsigned int out_bus_format;
> +
> +	out_bus_format = bridge_state->output_bus_cfg.format;
> +
> +	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
> +		bridge_state->input_bus_cfg.format,
> +		bridge_state->output_bus_cfg.format);
> +
> +	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
> +		 		true : false;
> +
> +	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> +	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> +	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> +	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> +
> +	return 0;
> +}
> +
>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>  				 enum drm_bridge_attach_flags flags)
>  {
> @@ -574,6 +655,9 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
>  	.mode_set = mtk_dpi_bridge_mode_set,
>  	.disable = mtk_dpi_bridge_disable,
>  	.enable = mtk_dpi_bridge_enable,
> +	.atomic_check = mtk_dpi_bridge_atomic_check,
> +	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
> +	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
>  };
>  
>  void mtk_dpi_start(struct device *dev)
> @@ -620,11 +704,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
>  	}
>  	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
>  
> -	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> -	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> -	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> -	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> -
>  	return 0;
>  
>  err_cleanup:


From quanyang.wang at windriver.com  Thu Apr 15 02:21:58 2021
From: quanyang.wang at windriver.com (wqyoung)
Date: Thu, 15 Apr 2021 09:21:58 +0800
Subject: [PATCH] [v2] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210412073154.25011-1-dinghao.liu@zju.edu.cn>
References: <20210412073154.25011-1-dinghao.liu@zju.edu.cn>
Message-ID: <20210415012158.GA2465158@pek-qwang2-d1>

Hi Dinghao,
On Mon, Apr 12, 2021 at 03:31:54PM +0800, Dinghao Liu wrote:
> There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> without any refcount increment, which leads to refcount leak.Add
> a refcount increment to balance the refcount. Also set
> auto_runtime_pm to resume suspended spi controller.
> 
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> ---
> changelog:
> 
> v2: - Add a refcount increment to fix refcout leak instead of the
>       refcount decrement on error.
>       Set ctlr->auto_runtime_pm = true.
> ---
>  drivers/spi/spi-zynqmp-gqspi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> index c8fa6ee18ae7..8b21c7b0e7eb 100644
> --- a/drivers/spi/spi-zynqmp-gqspi.c
> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -1160,6 +1160,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>  	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
>  	pm_runtime_set_active(&pdev->dev);
>  	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_get_sync(&pdev->dev);
Please check the return value here, if ret is "< 0", goto error label,
and a pm_runtime_put_sync is needed in error label
>  	/* QSPI controller initializations */
>  	zynqmp_qspi_init_hw(xqspi);
>  
> @@ -1187,6 +1188,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>  	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
>  			    SPI_TX_DUAL | SPI_TX_QUAD;
>  	ctlr->dev.of_node = np;
> +	ctlr->auto_runtime_pm = true;
>  
>  	ret = devm_spi_register_controller(&pdev->dev, ctlr);
>  	if (ret) {
These 2 function
     pm_runtime_mark_last_busy(&pdev->dev);
      pm_runtime_put_autosuspend(&pdev->dev);
are the last operations in probe function since if they runs,
spi_controller will enter suspend state and disable clks after 3s
passing. So please move them just before "return 0".

And would you please cc me when you send V3? I am preparing to send a patch series
to fix clk and suspend/resume issues which bases on the pm_runtime issue.

Thanks,
Quanyang
> -- 
> 2.17.1
> 


From dominique.martinet at atmark-techno.com  Thu Apr 15 02:27:58 2021
From: dominique.martinet at atmark-techno.com (Dominique MARTINET)
Date: Thu, 15 Apr 2021 10:27:58 +0900
Subject: [EXT] regression due to soc_device_match not handling defer
 (Was: [PATCH v4 4/4] soc: imx8m: change to use platform driver)
In-Reply-To: <AM6PR04MB60536EF0DEEE6EB64CF29390E27D9@AM6PR04MB6053.eurprd04.prod.outlook.com>
References: <20201120101112.31819-4-alice.guo@nxp.com>
 <YGGZJjAxA1IO+/VU@atmark-techno.com>
 <AM6PR04MB60536EF0DEEE6EB64CF29390E27D9@AM6PR04MB6053.eurprd04.prod.outlook.com>
Message-ID: <YHeWnuDQo76rYoz5@atmark-techno.com>

Alice Guo (OSS) wrote on Tue, Mar 30, 2021 at 02:41:23AM +0000:
> Thanks for reporting this issue, I'll check and add a fix to handle defer probe.

I haven't seen any follow up on this, have you had a chance to take a
look?
If this won't make it for 5.12 (in a couple of week probably?) would it
make sense to revert 7d981405d0fd ("soc: imx8m: change to use platform
driver") for now?



While looking at the code earlier I also have an unrelated, late-review
on the patch itself:

> +static u32 __init imx8mq_soc_revision(struct device *dev)
> [...]
>  @@ -191,8 +223,16 @@ static int __init imx8_soc_init(void)
>         data = id->data;
>         if (data) {
>                 soc_dev_attr->soc_id = data->name;
> -               if (data->soc_revision)
> -                       soc_rev = data->soc_revision();
> +               if (data->soc_revision) {
> +                       if (pdev) {
> +                               soc_rev = data->soc_revision(&pdev->dev);
> +                               ret = soc_rev;
> +                               if (ret < 0)

I appreciate current soc_revision are "small enough" (looking at
include/soc/imx/revision.h we're talking < 256) so this actually works,
but would it make sense to either make soc_rev signed, or to have
soc_revision() return a s64, or have the revision filled in another *u32
argument to make sure the error is an error and not just a large rev?

This is most definitely fine for now but that kind of code patterns can
lead to weird errors down the road.

Thanks,
-- 
Dominique


From peng.fan at nxp.com  Thu Apr 15 02:33:02 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Thu, 15 Apr 2021 01:33:02 +0000
Subject: [EXT] regression due to soc_device_match not handling defer (Was:
 [PATCH v4 4/4] soc: imx8m: change to use platform driver)
In-Reply-To: <YHeWnuDQo76rYoz5@atmark-techno.com>
References: <20201120101112.31819-4-alice.guo@nxp.com>
 <YGGZJjAxA1IO+/VU@atmark-techno.com>
 <AM6PR04MB60536EF0DEEE6EB64CF29390E27D9@AM6PR04MB6053.eurprd04.prod.outlook.com>
 <YHeWnuDQo76rYoz5@atmark-techno.com>
Message-ID: <DB6PR0402MB27607D28703D8C3E614E2F2A884D9@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> (Was: [PATCH v4 4/4] soc: imx8m: change to use platform driver)
> 
> Alice Guo (OSS) wrote on Tue, Mar 30, 2021 at 02:41:23AM +0000:
> > Thanks for reporting this issue, I'll check and add a fix to handle defer probe.
> 
> I haven't seen any follow up on this, have you had a chance to take a look?

We are trying to find a proper solution for this.

The proper method might be make soc_device_match return probe defer,
and take early soc attr into consideration, but I am not sure this would win
maintainer's vote.

> If this won't make it for 5.12 (in a couple of week probably?) would it make
> sense to revert 7d981405d0fd ("soc: imx8m: change to use platform
> driver") for now?

Please no. We are targeting android GKI, make driver as modules.
And reverting to original method will also break kexec.

I am on IRC #linux-imx, we could take more if you would like to.

Thanks,
Peng.

> 
> 
> 
> While looking at the code earlier I also have an unrelated, late-review on the
> patch itself:
> 
> > +static u32 __init imx8mq_soc_revision(struct device *dev)
> > [...]
> >  @@ -191,8 +223,16 @@ static int __init imx8_soc_init(void)
> >         data = id->data;
> >         if (data) {
> >                 soc_dev_attr->soc_id = data->name;
> > -               if (data->soc_revision)
> > -                       soc_rev = data->soc_revision();
> > +               if (data->soc_revision) {
> > +                       if (pdev) {
> > +                               soc_rev =
> data->soc_revision(&pdev->dev);
> > +                               ret = soc_rev;
> > +                               if (ret < 0)
> 
> I appreciate current soc_revision are "small enough" (looking at
> include/soc/imx/revision.h we're talking < 256) so this actually works, but
> would it make sense to either make soc_rev signed, or to have
> soc_revision() return a s64, or have the revision filled in another *u32
> argument to make sure the error is an error and not just a large rev?
> 
> This is most definitely fine for now but that kind of code patterns can lead to
> weird errors down the road.
> 
> Thanks,
> --
> Dominique

From kernelfans at gmail.com  Thu Apr 15 03:14:09 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Thu, 15 Apr 2021 10:14:09 +0800
Subject: [RFC 0/8] use __create_pgd_mapping() to implement idmap and unify
 codes
In-Reply-To: <CA+CK2bCLwRWiNf-pUbD_qSRPt=taQxSvrEMOP-8D7FgNhXQKug@mail.gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
 <CA+CK2bCLwRWiNf-pUbD_qSRPt=taQxSvrEMOP-8D7FgNhXQKug@mail.gmail.com>
Message-ID: <CAFgQCTvq3VAm7yztoR9jw=EYUdS1K-cuTKcUn_DNdGsnxMyrHA@mail.gmail.com>

Hi Pavel,

First of all, sorry to stir up this topic too late.

On Wed, Apr 14, 2021 at 10:06 PM Pavel Tatashin
<pasha.tatashin at soleen.com> wrote:
>
[...]
> Hi Pingfan,
>
> The MMU enabled kexec code has been in development for a while, and
> has gone through several iterations:
>

Yes, I have gone through the whole iterations after reviewing v12.

> 1. simply reserve memory (similar to crash kernel) so no relocation is
> needed. The approach was only ~50 LOC, but since this was an ARM64
> specific problem I was asked to fix it in ARM64, not in generic code.
> 2. The second approach was to use idmap (as you are proposing now),
> but James Morse explained to me that there are arm systems that have
> very high starting physical addresses that they cannot cover all
> physical memory via idamp. So, I cannot assume that I can idmap any
> page in PA.

I think here, the exact blocking factor is the routines in hand can
not set up idmap. But the current routines have the capability if
enhanced. And  it turns out easy to achieve the goal by redefining
CONFIG_PGTABLE_LEVEL.

> 3. The third approach was to unify some of page table management code
> with hibernations (trans_pgd), and use contiguous VA maps, so the
> relocation function can be as simply as possible. However, both, Eric
> Biederman and James Morse asked me to change it to a linear map
> instead: to be inline with other arches, and also for easier
> debugging.
> 4. The fourth approach is the current one, I am using a linear map,
> and a lot of patches for this project have already landed into the
> mainline. The last set of changes does not add any new LOC: "18 files
> changed, 315 insertions(+), 330 deletions(-)", as all the preliminary
> work has landed upstream.
>
> What is the benefit of going back to approach 2, when the current
> approach has already been agreed with James and Eric, and does not add
> new complexity, as the net LOC change is negative?
>

It takes me some time to understand the stub handling. But James is
expert on this field and sure about it.  In contrast, idmap is similar
to linear map, meanwhile free of kvm stub handling. As a result, the
code scarcely needs change against MMU-disabled code.

Anyway, the primary target of my series is to share the common code
with [5/8] and [8/8].

Thanks,
Pingfan


From zhukeqian1 at huawei.com  Thu Apr 15 03:20:52 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 10:20:52 +0800
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <87pmyxme2m.wl-maz@kernel.org>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
 <20210414065109.8616-3-zhukeqian1@huawei.com> <87pmyxme2m.wl-maz@kernel.org>
Message-ID: <b434317f-ef6d-1d91-0189-8343c404c88c@huawei.com>

Hi Marc,

On 2021/4/14 17:05, Marc Zyngier wrote:
> + Santosh, who found some interesting bugs in that area before.
> 
> On Wed, 14 Apr 2021 07:51:09 +0100,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> The MMIO region of a device maybe huge (GB level), try to use
>> block mapping in stage2 to speedup both map and unmap.
>>
>> Compared to normal memory mapping, we should consider two more
>> points when try block mapping for MMIO region:
>>
>> 1. For normal memory mapping, the PA(host physical address) and
>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>> the HVA to request hugepage, so we don't need to consider PA
>> alignment when verifing block mapping. But for device memory
>> mapping, the PA and HVA may have different alignment.
>>
>> 2. For normal memory mapping, we are sure hugepage size properly
>> fit into vma, so we don't check whether the mapping size exceeds
>> the boundary of vma. But for device memory mapping, we should pay
>> attention to this.
>>
>> This adds device_rough_page_shift() to check these two points when
>> selecting block mapping size.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> ---
>>  arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
>>  1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index c59af5ca01b0..1a6d96169d60 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>>  }
>>  
>> +/*
>> + * Find a max mapping size that properly insides the vma. And hva and pa must
>> + * have the same alignment to this mapping size. It's rough as there are still
>> + * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
>> + */
>> +static short device_rough_page_shift(struct vm_area_struct *vma,
>> +				     unsigned long hva)
> 
> My earlier question still stands. Under which circumstances would this
> function return something that is *not* the final mapping size? I
> really don't see a reason why this would not return the final mapping
> size.

IIUC, all the restrictions are about alignment and area boundary.

That's to say, HVA, IPA and PA must have same alignment within the mapping size.
And the areas are memslot and vma, which means the mapping size must properly fit
into the memslot and vma.

In this function, we just checked the alignment of HVA and PA, and the boundary of vma.
So we still need to check the alignment of HVA and IPA, and the boundary of memslot.
These will be checked by fault_supports_stage2_huge_mapping().

> 
>> +{
>> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>> +
>> +#ifndef __PAGETABLE_PMD_FOLDED
>> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
>> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
>> +		return PUD_SHIFT;
>> +#endif
>> +
>> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
>> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
>> +		return PMD_SHIFT;
>> +
>> +	return PAGE_SHIFT;
>> +}
>> +
>>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>>  					       unsigned long hva,
>>  					       unsigned long map_size)
>> @@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  		return -EFAULT;
>>  	}
>>  
>> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
>> +	/*
>> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
>> +	 * get block mapping for device MMIO region.
>> +	 */
>>  	mmap_read_lock(current->mm);
>>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>>  	if (unlikely(!vma)) {
>> @@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (is_vm_hugetlb_page(vma))
>>  		vma_shift = huge_page_shift(hstate_vma(vma));
>> +	else if (vma->vm_flags & VM_PFNMAP)
>> +		vma_shift = device_rough_page_shift(vma, hva);
> 
> What prevents a VMA from having both VM_HUGETLB and VM_PFNMAP? This is
> pretty unlikely, but I'd like to see this case catered for.
> 
I'm not sure whether VM_HUGETLB and VM_PFNMAP are compatible, and I failed to find a case.

VM_PFNMAP is used for page-ranges managed without "struct page", just pure PFN.
IIUC, VM_HUGETLB is used for hugetlbfs, which always has "struct page".
So I think they should not be compatible, otherwise it's a bug of driver.

>>  	else
>>  		vma_shift = PAGE_SHIFT;
>>  
>> -	if (logging_active ||
>> -	    (vma->vm_flags & VM_PFNMAP)) {
>> +	if (logging_active) {
>>  		force_pte = true;
>>  		vma_shift = PAGE_SHIFT;
>>  	}
>> @@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  
>>  	if (kvm_is_device_pfn(pfn)) {
>>  		device = true;
>> -		force_pte = true;
>> +		force_pte = (vma_pagesize == PAGE_SIZE);
> 
> Why do we need to set force_pte if we are already dealing with
> PAGE_SIZE? I guess you are doing this for the sake of avoiding the
> call to transparent_hugepage_adjust(), right?
Yes.

> 
> I'd rather you simply don't try to upgrade a device mapping by
> explicitly checking for this and keep force_pte for *memory*
> exclusively.
Agree, that's better.

> 
> Santosh, can you please take a look at this series and try to see if
> the problem you fixed in [1] (which ended up as commit 91a2c34b7d6f)
> is still OK with this series?
I searched the initial version[*], VM_PFNMAP is set when we call gfn_to_pfn_prot()->vma_mmio_fault()->remap_pfn_range().
Then the check of VM_PFNMAP in user_mem_abort() failed, so we will try to call transparent_hugepage_adjust() for device pfn.

In that case, our logic of trying block mapping for MMIO is not used. And we still set force_pte for device pfn, so
this bugfix is not affected. Santosh, do you agree that?

I still found that the reason vfio_pci does not have this bug. vfio_pci set VM_PFNMAP for vma when userspace calls mmap().
I will apply this logic for vfio_mdev too, let's see what vfio maintainer think about it.


Thanks,
Keqian.

[*] https://lore.kernel.org/kvmarm/1603297010-18787-1-git-send-email-sashukla at nvidia.com/

> 
>>  	} else if (logging_active && !write_fault) {
>>  		/*
>>  		 * Only actually map the page as writable if this was a write
> 
> Thanks,
> 
> 	M.
> 
> [1] https://lore.kernel.org/kvmarm/1603711447-11998-1-git-send-email-sashukla at nvidia.com/
> 


From dillon.minfei at gmail.com  Thu Apr 15 04:22:24 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Thu, 15 Apr 2021 11:22:24 +0800
Subject: [PATCH v2 1/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC board dts support
In-Reply-To: <6d8a5d4c-b741-dc7a-7cfb-eb66a642cb6f@canonical.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
 <1618383117-17179-2-git-send-email-dillon.minfei@gmail.com>
 <6d8a5d4c-b741-dc7a-7cfb-eb66a642cb6f@canonical.com>
Message-ID: <CAL9mu0KqrbxUtKgPkQyTMj1pfqx5Ch+LGuLzzWEAHtSO9z0izA@mail.gmail.com>

On Wed, Apr 14, 2021 at 9:00 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On 14/04/2021 08:51, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> > featuring:
> > - i.MX6Q
> > - 2GiB LPDDR3 DRAM
> > - 8GiB eMMC 5.0 FLASH
> > - 4MiB SPI Flash
> > - USB 2.0 Host/Device
> > - Multiple multi-protocol RS232/RS485 Serial ports
> > - microSD socket
> > - 5V DC power input
> > - HDMI1.4a,1080p at 60
> > - RGMIIx1 Gigabit Ethernet
> > - CSI0x1, connect with ov2659
> >
> > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> > ---
> > v2: no changes
> >
> >  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 297c87f45db8..24bdfbd4853f 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -206,6 +206,7 @@ properties:
> >                - fsl,imx6q-sabreauto
> >                - fsl,imx6q-sabrelite
> >                - fsl,imx6q-sabresd
> > +              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
>
> You break here the alphabetical order. Should be after dmo,imx6q-edmqmx6.
Agree? will move to below dmo,imx6q-edmqmx6 in v3, thanks for patient.

Best regards.
Dillon
>
>
> Best regards,
> Krzysztof


From dillon.minfei at gmail.com  Thu Apr 15 04:24:08 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Thu, 15 Apr 2021 11:24:08 +0800
Subject: [PATCH v2 4/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <9f8f3d55-b3f3-54d6-9143-5d676a21c901@canonical.com>
References: <1618383117-17179-1-git-send-email-dillon.minfei@gmail.com>
 <1618383117-17179-5-git-send-email-dillon.minfei@gmail.com>
 <9f8f3d55-b3f3-54d6-9143-5d676a21c901@canonical.com>
Message-ID: <CAL9mu0KB9cm6khKzftaW=X+RGkBEPEnRWFPHVaxLaHrQEzOGKw@mail.gmail.com>

On Wed, Apr 14, 2021 at 9:01 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On 14/04/2021 08:51, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > Add vendor prefix for DaSheng, Inc.
> >
> > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > ---
> > v2: new add
> >
> >  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> >  1 file changed, 2 insertions(+)
>
> This should be the first patch in the series.
OK, will place this patch at v3's first. thanks

Best regards
Dillon,
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
>
>
> Best regards,
> Krzysztof


From wanjiabing at vivo.com  Thu Apr 15 04:24:56 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Thu, 15 Apr 2021 11:24:56 +0800
Subject: [PATCH] power: reset: Remove unneeded semicolon
Message-ID: <20210415032456.24070-1-wanjiabing@vivo.com>

Fix the following coccicheck warning:

./drivers/power/reset/vexpress-poweroff.c:136:2-3: Unneeded semicolon

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 drivers/power/reset/vexpress-poweroff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
index 1fdbcbd95fc2..447ffdacddf9 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -133,7 +133,7 @@ static int vexpress_reset_probe(struct platform_device *pdev)
 	case FUNC_REBOOT:
 		ret = _vexpress_register_restart_handler(&pdev->dev);
 		break;
-	};
+	}
 
 	return ret;
 }
-- 
2.25.1



From dillon.minfei at gmail.com  Thu Apr 15 05:05:31 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Thu, 15 Apr 2021 12:05:31 +0800
Subject: [PATCH v3 0/4] arm: imx: Add i.mx6q DaSheng COM-9XX SBC board support
Message-ID: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

This patchset aims to add kernel support on DaSheng COM-8XX SBC board
optimize ov2659 driver to handle xvclk on/off at proper stage to save power

changes based on master branch, since commit id:
89698becf06d341a700913c3d89ce2a914af69a2

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

---
v3:
- optimize commit message for patch v3 ov2659 part
- move 'imx6q-ds.dtb' after 'imx6q-dms-ba16.dtb' to follow the alphabetical order
  (arch/arm/boot/dts/Makefile)
- move 'ds,imx6q-sbc' after 'dmo,imx6q-edmqmx6' to follow the alphabetical
  order. (Documentation/devicetree/bindings/arm/fsl.yaml)
- move v2 patch 4 to v3 patch 1
- add 'Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>'
  for [PATCH v3 1/4]

- v2 link:
https://lore.kernel.org/linux-arm-kernel/1618383117-17179-1-git-send-email-dillon.minfei at gmail.com/T/#md2dc86ac665ed7f10cffe4909825b97608805d3f

v2:
- add "[PATCH v2 4/4] dt-bindings: add dasheng vendor prefix" to fix
  checkpatch.pl warning.


dillon min (4):
  dt-bindings: add dasheng vendor prefix
  dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
  arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support
  media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to
    set xvclk on/off

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/imx6q-ds.dts                     |  17 +
 arch/arm/boot/dts/imx6qdl-ds.dtsi                  | 465 +++++++++++++++++++++
 drivers/media/i2c/ov2659.c                         |  24 +-
 6 files changed, 504 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

-- 
2.7.4



From dillon.minfei at gmail.com  Thu Apr 15 05:05:32 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Thu, 15 Apr 2021 12:05:32 +0800
Subject: [PATCH v3 1/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618459535-8141-2-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

Add vendor prefix for DaSheng, Inc.

Signed-off-by: dillon min <dillon.minfei at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
v3:
- move v2 patch 4 to v3 patch 1
- add 'Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.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 f6064d84a424..4ec28488c963 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -309,6 +309,8 @@ patternProperties:
     description: DPTechnics
   "^dragino,.*":
     description: Dragino Technology Co., Limited
+  "^ds,.*":
+    description: DaSheng, Inc.
   "^dserve,.*":
     description: dServe Technology B.V.
   "^dynaimage,.*":
-- 
2.7.4



From dillon.minfei at gmail.com  Thu Apr 15 05:05:33 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Thu, 15 Apr 2021 12:05:33 +0800
Subject: [PATCH v3 2/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
In-Reply-To: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618459535-8141-3-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
v3: move 'ds,imx6q-sbc' after 'dmo,imx6q-edmqmx6' to follow the alphabetical
order.

 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 297c87f45db8..598fb44c1bb8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -197,6 +197,7 @@ properties:
               - boundary,imx6q-nitrogen6x
               - compulab,cm-fx6           # CompuLab CM-FX6
               - dmo,imx6q-edmqmx6         # Data Modul eDM-QMX6 Board
+              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
               - embest,imx6q-marsboard    # Embest MarS Board i.MX6Dual
               - emtrion,emcon-mx6         # emCON-MX6D or emCON-MX6Q SoM
               - emtrion,emcon-mx6-avari   # emCON-MX6D or emCON-MX6Q SoM on Avari Base
-- 
2.7.4



From dillon.minfei at gmail.com  Thu Apr 15 05:05:34 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Thu, 15 Apr 2021 12:05:34 +0800
Subject: [PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board
 support
In-Reply-To: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v3: move imx6q-ds.dtb after imx6q-dms-ba16.dtb to follow the alphabetical order

 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/imx6q-ds.dts    |  17 ++
 arch/arm/boot/dts/imx6qdl-ds.dtsi | 465 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 483 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a19c5ab9df84..425fe17ef7c1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-display5-tianma-tm070-1280x768.dtb \
 	imx6q-dmo-edmqmx6.dtb \
 	imx6q-dms-ba16.dtb \
+	imx6q-ds.dtb \
 	imx6q-emcon-avari.dtb \
 	imx6q-evi.dtb \
 	imx6q-gk802.dtb \
diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
new file mode 100644
index 000000000000..b0a63a133977
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ds.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-ds.dtsi"
+
+/ {
+	model = "DaSheng i.MX6 Quad Com-9xx Board";
+	compatible = "ds,imx6q-sbc", "fsl,imx6q";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
new file mode 100644
index 000000000000..d28e065349cd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	memory at 10000000 {
+		device_type = "memory";
+		reg = <0x10000000 0x80000000>;
+	};
+
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb_h1_vbus: regulator-usb-h1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_h1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_leds>;
+
+		green {
+			gpios = <&gpio4 8 0>;
+			default-state = "on";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+	bus-width = <8>;
+	data-shift = <12>; /* Lines 19:12 used */
+	hsync-active = <1>;
+	vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+	remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ipu1_csi0>;
+	status = "okay";
+};
+
+&clks {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&ecspi1 {
+	cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "okay";
+
+	flash: m25p80 at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,m25p80", "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy>;
+	fsl,magic-packet;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy: ethernet-phy at 1 {
+			reg = <1>;
+			qca,clk-out-frequency = <125000000>;
+			reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+		};
+	};
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hdmi_cec>;
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	pmic: pfuze100 at 8 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3b_reg: sw3b {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw4_reg: sw4 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vgen1 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen2_reg: vgen2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ov2659: camera at 30 {
+		compatible = "ovti,ov2659";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ov2659>;
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		clock-names = "xvclk";
+		reg = <0x30>;
+		powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+		status = "okay";
+
+		port {
+			ov2659_to_ipu1_csi0_mux: endpoint {
+				remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+				link-frequencies = /bits/ 64 <70000000>;
+				bus-width = <8>;
+				hsync-active = <1>;
+				vsync-active = <1>;
+			};
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	imx6qdl-ds {
+		pinctrl_hog: hoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
+				MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+				MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
+				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+				MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+			>;
+		};
+
+		pinctrl_ecspi1: ecspi1grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_ROW1__GPIO4_IO09	0x1b0b0
+				MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
+				MX6QDL_PAD_EIM_D16__ECSPI1_SCLK	0x100b1
+				MX6QDL_PAD_EIM_D18__ECSPI1_MOSI	0x100b1
+				MX6QDL_PAD_EIM_D17__ECSPI1_MISO	0x100b1
+			>;
+		};
+
+		pinctrl_enet: enetgrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
+				MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
+				MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x1b030
+				MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x1b030
+				MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x1b030
+				MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x1b030
+				MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x1b030
+				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x1b030
+				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x1b0b0
+				MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b030
+				MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b030
+				MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b030
+				MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b030
+				MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b030
+				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b030
+			>;
+		};
+
+		pinctrl_hdmi_cec: hdmicecgrp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE	0x1f8b0
+			>;
+		};
+
+		pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+				MX6QDL_PAD_EIM_EB2__I2C2_SCL		0x4001b8b1
+				MX6QDL_PAD_KEY_ROW3__I2C2_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_i2c3: i2c3grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_5__I2C3_SCL		0x4001b8b1
+				MX6QDL_PAD_GPIO_6__I2C3_SDA		0x4001b8b1
+			>;
+		};
+
+		pinctrl_ipu1_csi0: ipu1csi0grp {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
+				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
+				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
+				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
+				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
+			>;
+		};
+
+		pinctrl_ov2659: ov2659grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x1b0b0
+				MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+			>;
+		};
+
+		pinctrl_uart4: uart4grp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL0__UART4_TX_DATA	0x1b0b1
+				MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA	0x1b0b1
+			>;
+		};
+
+		pinctrl_usbotg: usbotggrp {
+			fsl,pins = <
+				MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID	0x17059
+			>;
+		};
+
+		pinctrl_usdhc1: usdhc1grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD1_CMD__SD1_CMD		0x17059
+				MX6QDL_PAD_SD1_CLK__SD1_CLK		0x10059
+				MX6QDL_PAD_SD1_DAT0__SD1_DATA0		0x17059
+				MX6QDL_PAD_SD1_DAT1__SD1_DATA1		0x17059
+				MX6QDL_PAD_SD1_DAT2__SD1_DATA2		0x17059
+				MX6QDL_PAD_SD1_DAT3__SD1_DATA3		0x17059
+				MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28	0x1b0b0
+			>;
+		};
+
+		pinctrl_usdhc2: usdhc2grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+				MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10059
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+			>;
+		};
+
+		pinctrl_usdhc3: usdhc3grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+				MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10059
+				MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+				MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+				MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+				MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+				MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+				MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+				MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+				MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+			>;
+		};
+
+		pinctrl_wdog: wdoggrp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_1__WDOG2_B		0x1b0b0
+			>;
+		};
+	};
+
+	gpio_leds {
+		pinctrl_gpio_leds: gpioledsgrp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
+			>;
+		};
+	};
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usb_h1_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	bus-width = <8>;
+	non-removable;
+	no-1-8-v;
+	status = "okay";
+};
+
+&wdog1 {
+	status = "okay";
+};
+
+&wdog2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "disabled";
+};
-- 
2.7.4



From dillon.minfei at gmail.com  Thu Apr 15 05:05:35 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Thu, 15 Apr 2021 12:05:35 +0800
Subject: [PATCH v3 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618459535-8141-5-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

On some platform(imx6q), xvclk might not switch on in advance,
also for power save purpose, xvclk should not be always on.
so, add clk_prepare_enable(), clk_disable_unprepare() in driver
side to set xvclk on/off at proper stage.

Add following changes:
- add 'struct clk *clk;' in 'struct ov2659 {}'
- enable xvclk in ov2659_power_on()
- disable xvclk in ov2659_power_off()

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v3: optimize commit message

 drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 42f64175a6df..fb78a1cedc03 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -204,6 +204,7 @@ struct ov2659 {
 	struct i2c_client *client;
 	struct v4l2_ctrl_handler ctrls;
 	struct v4l2_ctrl *link_frequency;
+	struct clk *clk;
 	const struct ov2659_framesize *frame_size;
 	struct sensor_register *format_ctrl_regs;
 	struct ov2659_pll_ctrl pll;
@@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
 
 	gpiod_set_value(ov2659->pwdn_gpio, 1);
 
+	clk_disable_unprepare(ov2659->clk);
+
 	return 0;
 }
 
@@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
 	struct i2c_client *client = to_i2c_client(dev);
 	struct v4l2_subdev *sd = i2c_get_clientdata(client);
 	struct ov2659 *ov2659 = to_ov2659(sd);
+	int ret;
 
 	dev_dbg(&client->dev, "%s:\n", __func__);
 
+	ret = clk_prepare_enable(ov2659->clk);
+	if (ret) {
+		dev_err(&client->dev, "%s: failed to enable clock\n",
+			__func__);
+		return ret;
+	}
+
 	gpiod_set_value(ov2659->pwdn_gpio, 0);
 
 	if (ov2659->resetb_gpio) {
@@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
 	const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
 	struct v4l2_subdev *sd;
 	struct ov2659 *ov2659;
-	struct clk *clk;
 	int ret;
 
 	if (!pdata) {
@@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->pdata = pdata;
 	ov2659->client = client;
 
-	clk = devm_clk_get(&client->dev, "xvclk");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
+	ov2659->clk = devm_clk_get(&client->dev, "xvclk");
+	if (IS_ERR(ov2659->clk))
+		return PTR_ERR(ov2659->clk);
 
-	ov2659->xvclk_frequency = clk_get_rate(clk);
+	ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
 	if (ov2659->xvclk_frequency < 6000000 ||
 	    ov2659->xvclk_frequency > 27000000)
 		return -EINVAL;
@@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->frame_size = &ov2659_framesizes[2];
 	ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
 
-	ov2659_power_on(&client->dev);
+	ret = ov2659_power_on(&client->dev);
+	if (ret < 0)
+		goto error;
 
 	ret = ov2659_detect(sd);
 	if (ret < 0)
-- 
2.7.4



From anshuman.khandual at arm.com  Thu Apr 15 05:40:38 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 15 Apr 2021 10:10:38 +0530
Subject: [PATCH] mm: Define ARCH_HAS_FIRST_USER_ADDRESS
In-Reply-To: <ec7bbb30-dbbd-197b-4d65-eb3600fe6413@csgroup.eu>
References: <1618368899-20311-1-git-send-email-anshuman.khandual@arm.com>
 <f29ba8e2-3071-c963-1e9f-e8c88526ed8d@csgroup.eu>
 <6d24d3cc-b2df-f0d7-f4bf-f505f679c77e@arm.com>
 <ec7bbb30-dbbd-197b-4d65-eb3600fe6413@csgroup.eu>
Message-ID: <e9d1a342-b444-efd5-d11f-79aa4d11fabc@arm.com>

On 4/14/21 11:40 AM, Christophe Leroy wrote:
> 
> 
> Le 14/04/2021 ? 07:59, Anshuman Khandual a ?crit?:
>>
>>
>> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/04/2021 ? 04:54, Anshuman Khandual a ?crit?:
>>>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>>>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>>>> for those platforms which would override generic default FIRST_USER_ADDRESS
>>>> value 0UL. This makes it much cleaner with reduced code.
>>>>
>>>> Cc: linux-alpha at vger.kernel.org
>>>> Cc: linux-snps-arc at lists.infradead.org
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Cc: linux-csky at vger.kernel.org
>>>> Cc: linux-hexagon at vger.kernel.org
>>>> Cc: linux-ia64 at vger.kernel.org
>>>> Cc: linux-m68k at lists.linux-m68k.org
>>>> Cc: linux-mips at vger.kernel.org
>>>> Cc: openrisc at lists.librecores.org
>>>> Cc: linux-parisc at vger.kernel.org
>>>> Cc: linuxppc-dev at lists.ozlabs.org
>>>> Cc: linux-riscv at lists.infradead.org
>>>> Cc: linux-s390 at vger.kernel.org
>>>> Cc: linux-sh at vger.kernel.org
>>>> Cc: sparclinux at vger.kernel.org
>>>> Cc: linux-um at lists.infradead.org
>>>> Cc: linux-xtensa at linux-xtensa.org
>>>> Cc: x86 at kernel.org
>>>> Cc: linux-mm at kvack.org
>>>> Cc: linux-kernel at vger.kernel.org
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>>> ---
>>>> ?? arch/alpha/include/asm/pgtable.h???????????? | 1 -
>>>> ?? arch/arc/include/asm/pgtable.h?????????????? | 6 ------
>>>> ?? arch/arm/Kconfig???????????????????????????? | 1 +
>>>> ?? arch/arm64/include/asm/pgtable.h???????????? | 2 --
>>>> ?? arch/csky/include/asm/pgtable.h????????????? | 1 -
>>>> ?? arch/hexagon/include/asm/pgtable.h?????????? | 3 ---
>>>> ?? arch/ia64/include/asm/pgtable.h????????????? | 1 -
>>>> ?? arch/m68k/include/asm/pgtable_mm.h?????????? | 1 -
>>>> ?? arch/microblaze/include/asm/pgtable.h??????? | 2 --
>>>> ?? arch/mips/include/asm/pgtable-32.h?????????? | 1 -
>>>> ?? arch/mips/include/asm/pgtable-64.h?????????? | 1 -
>>>> ?? arch/nds32/Kconfig?????????????????????????? | 1 +
>>>> ?? arch/nios2/include/asm/pgtable.h???????????? | 2 --
>>>> ?? arch/openrisc/include/asm/pgtable.h????????? | 1 -
>>>> ?? arch/parisc/include/asm/pgtable.h??????????? | 2 --
>>>> ?? arch/powerpc/include/asm/book3s/pgtable.h??? | 1 -
>>>> ?? arch/powerpc/include/asm/nohash/32/pgtable.h | 1 -
>>>> ?? arch/powerpc/include/asm/nohash/64/pgtable.h | 2 --
>>>> ?? arch/riscv/include/asm/pgtable.h???????????? | 2 --
>>>> ?? arch/s390/include/asm/pgtable.h????????????? | 2 --
>>>> ?? arch/sh/include/asm/pgtable.h??????????????? | 2 --
>>>> ?? arch/sparc/include/asm/pgtable_32.h????????? | 1 -
>>>> ?? arch/sparc/include/asm/pgtable_64.h????????? | 3 ---
>>>> ?? arch/um/include/asm/pgtable-2level.h???????? | 1 -
>>>> ?? arch/um/include/asm/pgtable-3level.h???????? | 1 -
>>>> ?? arch/x86/include/asm/pgtable_types.h???????? | 2 --
>>>> ?? arch/xtensa/include/asm/pgtable.h??????????? | 1 -
>>>> ?? include/linux/mm.h?????????????????????????? | 4 ++++
>>>> ?? mm/Kconfig?????????????????????????????????? | 4 ++++
>>>> ?? 29 files changed, 10 insertions(+), 43 deletions(-)
>>>>
>>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>>> index 8ba434287387..47098ccd715e 100644
>>>> --- a/include/linux/mm.h
>>>> +++ b/include/linux/mm.h
>>>> @@ -46,6 +46,10 @@ extern int sysctl_page_lock_unfairness;
>>>> ?? ? void init_mm_internals(void);
>>>> ?? +#ifndef ARCH_HAS_FIRST_USER_ADDRESS
>>>
>>> I guess you didn't test it ..... :)
>>
>> In fact I did :) Though just booted it on arm64 and cross compiled on
>> multiple others platforms.

I guess for all platforms, ARCH_HAS_FIRST_USER_ADDRESS would have just
evaluated to be false hence falling back on the generic definition. So
this never complained during build any where or during boot on arm64.

>>
>>>
>>> should be #ifndef CONFIG_ARCH_HAS_FIRST_USER_ADDRESS
>>
>> Right, meant that instead.
>>
>>>
>>>> +#define FIRST_USER_ADDRESS??? 0UL
>>>> +#endif
>>>
>>> But why do we need a config option at all for that ?
>>>
>>> Why not just:
>>>
>>> #ifndef FIRST_USER_ADDRESS
>>> #define FIRST_USER_ADDRESS??? 0UL
>>> #endif
>>
>> This sounds simpler. But just wondering, would not there be any possibility
>> of build problems due to compilation sequence between arch and generic code ?
>>
> 
> For sure it has to be addresses carefully, but there are already a lot of stuff like that around pgtables.h
> 
> For instance, pte_offset_kernel() has a generic definition in linux/pgtables.h based on whether it is already defined or not.
> 
> Taking into account that FIRST_USER_ADDRESS is today in the architectures's asm/pgtables.h, I think putting the fallback definition in linux/pgtable.h would do the trick.

Agreed, <linux/pgtable.h> includes <asm/pgtable.h> at the beginning and
if the arch defines FIRST_USER_ADDRESS, the generic one afterwards would
be skipped. The following change builds on multiple platforms.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ad086e6d7155..5da96f5df48f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
 	select ARCH_HAS_DEBUG_VIRTUAL if MMU
 	select ARCH_HAS_DMA_WRITE_COMBINE if !ARM_DMA_MEM_BUFFERABLE
 	select ARCH_HAS_ELF_RANDOMIZE
-	select ARCH_HAS_FIRST_USER_ADDRESS
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_KEEPINITRD
 	select ARCH_HAS_KCOV
diff --git a/arch/nds32/Kconfig b/arch/nds32/Kconfig
index 23ec4fcc0d0f..62313902d75d 100644
--- a/arch/nds32/Kconfig
+++ b/arch/nds32/Kconfig
@@ -8,7 +8,6 @@ config NDS32
 	def_bool y
 	select ARCH_32BIT_OFF_T
 	select ARCH_HAS_DMA_PREP_COHERENT
-	select ARCH_HAS_FIRST_USER_ADDRESS
 	select ARCH_HAS_SYNC_DMA_FOR_CPU
 	select ARCH_HAS_SYNC_DMA_FOR_DEVICE
 	select ARCH_WANT_FRAME_POINTERS if FTRACE
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 47098ccd715e..8ba434287387 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -46,10 +46,6 @@ extern int sysctl_page_lock_unfairness;
 
 void init_mm_internals(void);
 
-#ifndef ARCH_HAS_FIRST_USER_ADDRESS
-#define FIRST_USER_ADDRESS	0UL
-#endif
-
 #ifndef CONFIG_NEED_MULTIPLE_NODES	/* Don't use mapnrs, do it properly */
 extern unsigned long max_mapnr;
 
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 5e772392a379..f3da6a5cc35a 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -28,6 +28,10 @@
 #define USER_PGTABLES_CEILING	0UL
 #endif
 
+#ifndef FIRST_USER_ADDRESS
+#define FIRST_USER_ADDRESS	0UL
+#endif
+
 /*
  * A page table page can be thought of an array like this: pXd_t[PTRS_PER_PxD]
  *
diff --git a/mm/Kconfig b/mm/Kconfig
index 373fbe377075..4494501aa403 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -807,9 +807,6 @@ config VMAP_PFN
 config ARCH_USES_HIGH_VMA_FLAGS
 	bool
 
-config ARCH_HAS_FIRST_USER_ADDRESS
-	bool
-
 config ARCH_HAS_PKEYS
 	bool
 
-- 
2.20.1


From dinghao.liu at zju.edu.cn  Thu Apr 15 06:27:22 2021
From: dinghao.liu at zju.edu.cn (dinghao.liu at zju.edu.cn)
Date: Thu, 15 Apr 2021 13:27:22 +0800 (GMT+08:00)
Subject: [PATCH] [v2] spi: spi-zynqmp-gqspi: Fix runtime PM
 imbalance in zynqmp_qspi_probe
In-Reply-To: <20210415012158.GA2465158@pek-qwang2-d1>
References: <20210412073154.25011-1-dinghao.liu@zju.edu.cn>
 <20210415012158.GA2465158@pek-qwang2-d1>
Message-ID: <7b720ae6.58927.178d3ff88f3.Coremail.dinghao.liu@zju.edu.cn>

> Hi Dinghao,
> On Mon, Apr 12, 2021 at 03:31:54PM +0800, Dinghao Liu wrote:
> > There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> > without any refcount increment, which leads to refcount leak.Add
> > a refcount increment to balance the refcount. Also set
> > auto_runtime_pm to resume suspended spi controller.
> > 
> > Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> > ---
> > changelog:
> > 
> > v2: - Add a refcount increment to fix refcout leak instead of the
> >       refcount decrement on error.
> >       Set ctlr->auto_runtime_pm = true.
> > ---
> >  drivers/spi/spi-zynqmp-gqspi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> > index c8fa6ee18ae7..8b21c7b0e7eb 100644
> > --- a/drivers/spi/spi-zynqmp-gqspi.c
> > +++ b/drivers/spi/spi-zynqmp-gqspi.c
> > @@ -1160,6 +1160,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
> >  	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
> >  	pm_runtime_set_active(&pdev->dev);
> >  	pm_runtime_enable(&pdev->dev);
> > +	pm_runtime_get_sync(&pdev->dev);
> Please check the return value here, if ret is "< 0", goto error label,
> and a pm_runtime_put_sync is needed in error label
> >  	/* QSPI controller initializations */
> >  	zynqmp_qspi_init_hw(xqspi);
> >  
> > @@ -1187,6 +1188,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
> >  	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
> >  			    SPI_TX_DUAL | SPI_TX_QUAD;
> >  	ctlr->dev.of_node = np;
> > +	ctlr->auto_runtime_pm = true;
> >  
> >  	ret = devm_spi_register_controller(&pdev->dev, ctlr);
> >  	if (ret) {
> These 2 function
>      pm_runtime_mark_last_busy(&pdev->dev);
>       pm_runtime_put_autosuspend(&pdev->dev);
> are the last operations in probe function since if they runs,
> spi_controller will enter suspend state and disable clks after 3s
> passing. So please move them just before "return 0".
> 
> And would you please cc me when you send V3? I am preparing to send a patch series
> to fix clk and suspend/resume issues which bases on the pm_runtime issue.
> 

Thanks for your advice and I will send a new patch soon.

Regards,
Dinghao

From flora.fu at mediatek.com  Thu Apr 15 06:52:34 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:34 +0800
Subject: [PATCH v2 1/7] dt-bindings: clock: Add MT8192 APU clock bindings
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-2-git-send-email-flora.fu@mediatek.com>

Add clock bindings for APU on MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/clock/mt8192-clk.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/dt-bindings/clock/mt8192-clk.h b/include/dt-bindings/clock/mt8192-clk.h
index ece5b4c0356c..71e07858f5dc 100644
--- a/include/dt-bindings/clock/mt8192-clk.h
+++ b/include/dt-bindings/clock/mt8192-clk.h
@@ -164,7 +164,15 @@
 #define CLK_TOP_APLL12_DIV9		152
 #define CLK_TOP_SSUSB_TOP_REF		153
 #define CLK_TOP_SSUSB_PHY_REF		154
-#define CLK_TOP_NR_CLK			155
+#define CLK_TOP_DSP_SEL			155
+#define CLK_TOP_DSP1_SEL		156
+#define CLK_TOP_DSP1_NPUPLL_SEL		157
+#define CLK_TOP_DSP2_SEL		158
+#define CLK_TOP_DSP2_NPUPLL_SEL		159
+#define CLK_TOP_DSP5_SEL		160
+#define CLK_TOP_DSP5_APUPLL_SEL		161
+#define CLK_TOP_IPU_IF_SEL		162
+#define CLK_TOP_NR_CLK			163
 
 /* INFRACFG */
 
@@ -309,7 +317,9 @@
 #define CLK_APMIXED_APLL1		8
 #define CLK_APMIXED_APLL2		9
 #define CLK_APMIXED_MIPID26M		10
-#define CLK_APMIXED_NR_CLK		11
+#define CLK_APMIXED_APUPLL		11
+#define CLK_APMIXED_NPUPLL		12
+#define CLK_APMIXED_NR_CLK		13
 
 /* SCP_ADSP */
 
-- 
2.18.0

From navam at xilinx.com  Thu Apr 15 06:57:54 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 15 Apr 2021 05:57:54 +0000
Subject: [PATCH 1/2] fpga: mgr: Adds secure BitStream loading support
In-Reply-To: <YEAXxuU2J1yaAl3U@archbook>
References: <20210118025058.10051-1-nava.manne@xilinx.com>
 <YApf1jlEghbnDFo/@archbook> <YEAXxuU2J1yaAl3U@archbook>
Message-ID: <MWHPR02MB262373853A19250FDFB7CEE9C24D9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Moritz,

	Thanks for providing the review comments.
Please find my response inline.

> -----Original Message-----
> From: Moritz Fischer <mdf at kernel.org>
> Sent: Thursday, March 4, 2021 4:42 AM
> To: Moritz Fischer <mdf at kernel.org>
> Cc: Nava kishore Manne <navam at xilinx.com>; trix at redhat.com;
> robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; linux-
> fpga at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; git
> <git at xilinx.com>; chinnikishore369 at gmail.com
> Subject: Re: [PATCH 1/2] fpga: mgr: Adds secure BitStream loading support
> 
> Hi Nava,
> 
> On Thu, Jan 21, 2021 at 09:17:10PM -0800, Moritz Fischer wrote:
> > On Mon, Jan 18, 2021 at 08:20:57AM +0530, Nava kishore Manne wrote:
> > > This commit adds secure flags to the framework to support secure
> > > BitStream Loading.
> > >
> > > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > > ---
> > >  drivers/fpga/of-fpga-region.c | 10 ++++++++++
> > > include/linux/fpga/fpga-mgr.h | 12 ++++++++++++
> > >  2 files changed, 22 insertions(+)
> > >
> > > diff --git a/drivers/fpga/of-fpga-region.c
> > > b/drivers/fpga/of-fpga-region.c index e405309baadc..3a5eb4808888
> > > 100644
> > > --- a/drivers/fpga/of-fpga-region.c
> > > +++ b/drivers/fpga/of-fpga-region.c
> > > @@ -228,6 +228,16 @@ static struct fpga_image_info
> *of_fpga_region_parse_ov(
> > >  	if (of_property_read_bool(overlay, "encrypted-fpga-config"))
> > >  		info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM;
> > >
> > > +	if (of_property_read_bool(overlay, "userkey-encrypted-fpga-
> config"))
> > > +		info->flags |=
> FPGA_MGR_USERKEY_ENCRYPTED_BITSTREAM;
> >
> > Can this just be encrypted-fpga-config/FPGA_MGR_ENCRYPTED?
> > > +
> > > +	if (of_property_read_bool(overlay, "ddrmem-authenticated-fpga-
> config"))
> > > +		info->flags |= FPGA_MGR_DDR_MEM_AUTH_BITSTREAM;
> > > +
> > > +	if (of_property_read_bool(overlay,
> > > +				  "securemem-authenticated-fpga-config"))
> > > +		info->flags |= FPGA_MGR_SECURE_MEM_AUTH_BITSTREAM;
> Shouldn't all these get binding docs? I remember Richard adding
> authentication support for an Intel platform, too and I'd like to avoid adding
> random bindings per vendor.
> 
> Would it be possible to have an 'authentication method / type' that is more
> extensible with different methods maybe?
> 
Yes, I agree this flags should not be a vendor specific we should make it as generic.
can we have flags something like below .
1) authenticated-fpga-config --> By default it uses kernel memory(DDR) to authenticate the image(FPGA_MGR_MEM_AUTH_BITSTREAM)
2) authenticated-onchip-fpga-config --> It uses the On chip memory to authenticate the image ( FPGA_MGR_AUTH_ON_CHIP_BITSTREAM)

if you have any other thoughts let me know will try to adopt the same...


Regards,
Navakishore.


From flora.fu at mediatek.com  Thu Apr 15 06:48:23 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:48:23 +0800
Subject: [PATCH v2 0/7] Add Support for MediaTek MT8192 APU Power
Message-ID: <1618465710-2965-1-git-send-email-flora.fu@mediatek.com>

The MediaTek AI Processing Unit (APU) is a proprietary hardware
in the SoC to support AI operations.
The series is to create apusys in the SoC folder for developing
the related drivers. Add the apu clocks, basic apu nodes and the
power domain to provide the power controller of APU subsystem.

This series is based on MT8192 clock[1] and PMIC[2] patches.
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=454523
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=458733

Change notes:
v1->v2:
  1) update expression "s/_/-/" in dt-bindings documents.
  2) drop apu power domain header file for mt8192.

v1: https://patchwork.kernel.org/project/linux-mediatek/list/?series=461999

Flora Fu (7):
  dt-bindings: clock: Add MT8192 APU clock bindings
  clk: mediatek: mt8192: Add APU clocks support
  dt-bindings: arm: mediatek: Add new document bindings for APU
  dt-bindings: soc: mediatek: apusys: Add new document for APU power
    domain
  soc: mediatek: apu: Add apusys and add apu power domain driver
  arm64: dts: mt8192: Add APU node
  arm64: dts: mt8192: Add APU power domain node

 .../arm/mediatek/mediatek,apusys.yaml         |  56 ++
 .../soc/mediatek/mediatek,apu-pm.yaml         | 145 +++++
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts   |   7 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |  45 ++
 drivers/clk/mediatek/clk-mt8192.c             |  91 +++
 drivers/soc/mediatek/Kconfig                  |  10 +
 drivers/soc/mediatek/Makefile                 |   1 +
 drivers/soc/mediatek/apusys/Makefile          |   2 +
 drivers/soc/mediatek/apusys/mtk-apu-pm.c      | 612 ++++++++++++++++++
 include/dt-bindings/clock/mt8192-clk.h        |  14 +-
 10 files changed, 981 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
 create mode 100644 drivers/soc/mediatek/apusys/Makefile
 create mode 100644 drivers/soc/mediatek/apusys/mtk-apu-pm.c

-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:38 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:38 +0800
Subject: [PATCH v2 5/7] soc: mediatek: apu: Add apusys and add apu power
 domain driver
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-6-git-send-email-flora.fu@mediatek.com>

Add the apusys in soc.
Add driver for apu power domains.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 drivers/soc/mediatek/Kconfig             |  10 +
 drivers/soc/mediatek/Makefile            |   1 +
 drivers/soc/mediatek/apusys/Makefile     |   2 +
 drivers/soc/mediatek/apusys/mtk-apu-pm.c | 612 +++++++++++++++++++++++
 4 files changed, 625 insertions(+)
 create mode 100644 drivers/soc/mediatek/apusys/Makefile
 create mode 100644 drivers/soc/mediatek/apusys/mtk-apu-pm.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..76ee7e354b27 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -5,6 +5,16 @@
 menu "MediaTek SoC drivers"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_APUSYS
+	bool "MediaTek APUSYS Support"
+	select REGMAP
+	select PM_GENERIC_DOMAINS if PM
+	help
+	  Say yes here to add support for the MediaTek AI Processing Unit
+	  Subsystem(APUSYS).
+	  The APUSYS is a proprietary hardware in SoC to support AI
+	  operations.
+
 config MTK_CMDQ
 	tristate "MediaTek CMDQ Support"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index c916b6799baa..4ca2d59b75cb 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_MTK_APUSYS) += apusys/
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
diff --git a/drivers/soc/mediatek/apusys/Makefile b/drivers/soc/mediatek/apusys/Makefile
new file mode 100644
index 000000000000..01c339e35b80
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_MTK_APUSYS) += mtk-apu-pm.o
diff --git a/drivers/soc/mediatek/apusys/mtk-apu-pm.c b/drivers/soc/mediatek/apusys/mtk-apu-pm.c
new file mode 100644
index 000000000000..c21f8b4085fd
--- /dev/null
+++ b/drivers/soc/mediatek/apusys/mtk-apu-pm.c
@@ -0,0 +1,612 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_clk.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define APU_PD_IPUIF_HW_CG		BIT(0)
+#define APU_PD_RPC_AUTO_BUCK		BIT(1)
+#define APU_PD_CAPS(_pd, _x)		((_pd)->data->caps & (_x))
+
+#define MTK_POLL_DELAY_US               10
+#define MTK_POLL_TIMEOUT                USEC_PER_SEC
+
+/*spm_cross_wake_m01*/
+#define WAKEUP_APU		(0x1 << 0)
+
+/* spm_other_pwr_status*/
+#define PWR_STATUS		(0x1 << 5)
+
+/* rpc_intf_pwr_rdy */
+#define PWR0_RDY		(0x1 << 0)
+
+/* rpc_top_con*/
+#define SLEEP_REQ		BIT(0)
+#define APU_BUCK_ELS_EN		BIT(3)
+
+/*conn_clr, conn1_clr, vcore_clr */
+#define CG_CLR	(0xFFFFFFFF)
+
+/* mt8192 rpc_sw_type */
+#define MT8192_RPC_SW_TYPE0	(0x200)
+#define MT8192_RPC_SW_TYPE1	(0x210)
+#define MT8192_RPC_SW_TYPE2	(0x220)
+#define MT8192_RPC_SW_TYPE3	(0x230)
+#define MT8192_RPC_SW_TYPE4	(0x240)
+#define MT8192_RPC_SW_TYPE6	(0x260)
+#define MT8192_RPC_SW_TYPE7	(0x270)
+
+/* rpc_sw_type*/
+static const struct reg_sequence mt8192_rpc_sw_type[] = {
+	{ MT8192_RPC_SW_TYPE0, 0xFF },
+	{ MT8192_RPC_SW_TYPE2, 0x7 },
+	{ MT8192_RPC_SW_TYPE3, 0x7 },
+	{ MT8192_RPC_SW_TYPE6, 0x3 },
+};
+
+struct apu_top_domain {
+	u32 spm_ext_buck_iso;
+	u32 spm_ext_buck_iso_mask;
+	u32 spm_cross_wake_m01;
+	u32 spm_other_pwr;
+	u32 conn_clr;
+	u32 conn1_clr;
+	u32 vcore_clr;
+	u32 rpc_top_con;
+	u32 rpc_top_con_init_mask;
+	u32 rpc_top_sel;
+	u32 rpc_top_intf_pwr_rdy;
+	const struct reg_sequence *rpc_sw_type;
+	int rpc_sw_ntype;
+};
+
+static struct apu_top_domain mt8192_top_reg = {
+	.spm_ext_buck_iso = 0x39C,
+	.spm_ext_buck_iso_mask = 0x21,
+	.spm_cross_wake_m01 = 0x670,
+	.spm_other_pwr = 0x178,
+	.conn_clr = 0x008,
+	.vcore_clr = 0x008,
+	.rpc_top_con = 0x000,
+	.rpc_top_con_init_mask = 0x49E,
+	.rpc_top_sel = 0x004,
+	.rpc_top_intf_pwr_rdy = 0x044,
+	.rpc_sw_type = mt8192_rpc_sw_type,
+	.rpc_sw_ntype = ARRAY_SIZE(mt8192_rpc_sw_type),
+};
+
+struct apusys {
+	struct device *dev;
+	struct regmap *scpsys;
+	struct regmap *conn;
+	struct regmap *conn1;
+	struct regmap *vcore;
+	struct regmap *rpc;
+	struct regulator *vsram_supply;
+	const struct apu_pm_data *data;
+	struct genpd_onecell_data pd_data;
+	struct generic_pm_domain *domains[];
+};
+
+struct apu_domain {
+	struct generic_pm_domain genpd;
+	const struct apu_domain_data *data;
+	struct apusys *apusys;
+	struct regulator *domain_supply;
+	int num_clks;
+	struct clk_bulk_data *clks;
+	struct clk *clk_top_conn;
+	struct clk *clk_top_ipu_if;
+	struct clk *clk_off;
+	struct clk *clk_on_def;
+};
+
+struct apu_domain_data {
+	int domain_idx;
+	char *name;
+	struct apu_top_domain *topd;
+	u8 caps;
+};
+
+struct apu_pm_data {
+	const struct apu_domain_data *domains_data;
+	int num_domains;
+};
+
+#define to_apu_domain(gpd) container_of(gpd, struct apu_domain, genpd)
+
+static int apu_top_init_hw(struct apu_domain *pd)
+{
+	struct apusys *apusys = pd->apusys;
+	int ret;
+
+	/*
+	 * set memory type to PD or sleep group
+	 * sw_type register for each memory group, set to PD mode default
+	 */
+	if (pd->data->topd->rpc_sw_ntype) {
+		ret = regmap_register_patch(apusys->rpc,
+					    pd->data->topd->rpc_sw_type,
+					    pd->data->topd->rpc_sw_ntype);
+		if (ret < 0) {
+			dev_err(apusys->dev, "Failed to rpc patch: %d\n", ret);
+			return ret;
+		}
+	}
+
+	/* mask RPC IRQ and bypass WFI */
+	regmap_set_bits(apusys->rpc, pd->data->topd->rpc_top_sel,
+			pd->data->topd->rpc_top_con_init_mask);
+
+	if (APU_PD_CAPS(pd, APU_PD_RPC_AUTO_BUCK))
+		regmap_set_bits(apusys->rpc,
+				pd->data->topd->rpc_top_con, APU_BUCK_ELS_EN);
+
+	return 0;
+}
+
+static const struct apu_domain_data apu_domain_data_mt8192[] = {
+	{
+		.domain_idx = 0,
+		.name = "apu-top",
+		.caps = APU_PD_IPUIF_HW_CG,
+		.topd = &mt8192_top_reg,
+	}
+};
+
+static const struct apu_pm_data mt8192_apu_pm_data = {
+	.domains_data = apu_domain_data_mt8192,
+	.num_domains = ARRAY_SIZE(apu_domain_data_mt8192),
+};
+
+static int apu_top_power_on(struct generic_pm_domain *genpd)
+{
+	struct apu_domain *pd = to_apu_domain(genpd);
+	struct apusys *apusys = pd->apusys;
+	int ret, tmp;
+
+	if (apusys->vsram_supply) {
+		ret = regulator_enable(apusys->vsram_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	if (pd->domain_supply) {
+		ret = regulator_enable(pd->domain_supply);
+		if (ret < 0)
+			goto err_regulator;
+	}
+
+	regmap_clear_bits(apusys->scpsys, pd->data->topd->spm_ext_buck_iso,
+			  pd->data->topd->spm_ext_buck_iso_mask);
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		ret = clk_prepare_enable(pd->clk_top_conn);
+		if (ret) {
+			dev_err(apusys->dev, "Failed enable top_conn clk\n");
+			goto err_clk;
+		}
+
+		ret = clk_set_parent(pd->clk_top_ipu_if, pd->clk_on_def);
+		if (ret) {
+			dev_err(apusys->dev, "Failed set ipu_if mux\n");
+			goto err_clk;
+		}
+
+		/* The ipu_if clock is gatting by HW. Only enable once. */
+		if (!__clk_is_enabled(pd->clk_top_ipu_if)) {
+			ret = clk_prepare_enable(pd->clk_top_ipu_if);
+			if (ret) {
+				dev_err(apusys->dev, "Failed enable ipu_if\n");
+				goto err_clk;
+			}
+		}
+	} else {
+		ret = clk_bulk_prepare_enable(pd->num_clks, pd->clks);
+		if (ret)
+			goto err_clk;
+	}
+
+	regmap_set_bits(apusys->scpsys,
+			pd->data->topd->spm_cross_wake_m01, WAKEUP_APU);
+
+	ret = regmap_read_poll_timeout(apusys->scpsys,
+				       pd->data->topd->spm_other_pwr,
+				       tmp, (tmp & PWR_STATUS) == PWR_STATUS,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top on wait SPM PWR_ACK != 0\n");
+		goto err_clk;
+	}
+
+	ret = regmap_read_poll_timeout(apusys->rpc,
+				       pd->data->topd->rpc_top_intf_pwr_rdy,
+				       tmp, (tmp & PWR0_RDY) == PWR0_RDY,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top on wait RPC PWR_RDY != 0\n");
+		goto err_clk;
+	}
+
+	if (apusys->vcore)
+		regmap_write(apusys->vcore, pd->data->topd->vcore_clr, CG_CLR);
+
+	if (apusys->conn)
+		regmap_write(apusys->conn, pd->data->topd->conn_clr, CG_CLR);
+
+	if (apusys->conn1)
+		regmap_write(apusys->conn1, pd->data->topd->conn1_clr, CG_CLR);
+
+	return 0;
+
+err_clk:
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_disable_unprepare(pd->clk_top_conn);
+		clk_disable_unprepare(pd->clk_top_ipu_if);
+	} else {
+		clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
+	}
+	if (pd->domain_supply)
+		ret = regulator_disable(pd->domain_supply);
+err_regulator:
+	if (apusys->vsram_supply)
+		ret = regulator_disable(apusys->vsram_supply);
+
+	return ret;
+}
+
+static int apu_top_power_off(struct generic_pm_domain *genpd)
+{
+	struct apu_domain *pd = to_apu_domain(genpd);
+	struct apusys *apusys = pd->apusys;
+	int ret, tmp;
+
+	if (apusys->vcore)
+		regmap_write(apusys->vcore, pd->data->topd->vcore_clr, CG_CLR);
+
+	if (apusys->conn)
+		regmap_write(apusys->conn, pd->data->topd->conn_clr, CG_CLR);
+
+	if (apusys->conn1)
+		regmap_write(apusys->conn1, pd->data->topd->conn1_clr, CG_CLR);
+
+	regmap_clear_bits(apusys->scpsys,
+			  pd->data->topd->spm_cross_wake_m01, WAKEUP_APU);
+
+	regmap_set_bits(apusys->rpc, pd->data->topd->rpc_top_con, SLEEP_REQ);
+
+	ret = regmap_read_poll_timeout(apusys->rpc,
+				       pd->data->topd->rpc_top_intf_pwr_rdy,
+				       tmp, (tmp & PWR0_RDY) == 0x0,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top off wait RPC PWR_RDY != 0\n");
+		return ret;
+	}
+
+	ret = regmap_read_poll_timeout(apusys->scpsys,
+				       pd->data->topd->spm_other_pwr, tmp,
+				       (tmp & PWR_STATUS) == 0x0,
+				       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+	if (ret < 0) {
+		dev_err(apusys->dev, "apu top off wait SPM PWR_ACK != 0\n");
+		return ret;
+	}
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_disable_unprepare(pd->clk_top_conn);
+		ret = clk_set_parent(pd->clk_top_ipu_if, pd->clk_off);
+		if (ret) {
+			dev_err(apusys->dev, "Failed set ipu_if rate\n");
+			return ret;
+		}
+	} else {
+		clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
+	}
+
+	regmap_set_bits(apusys->scpsys,
+			pd->data->topd->spm_ext_buck_iso,
+			pd->data->topd->spm_ext_buck_iso_mask);
+
+	if (apusys->vsram_supply) {
+		ret = regulator_disable(apusys->vsram_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	if (pd->domain_supply) {
+		ret = regulator_disable(pd->domain_supply);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+static struct generic_pm_domain *apu_add_one_domain(struct apusys *apusys,
+						    struct device_node *node)
+{
+	const struct apu_domain_data *domain_data;
+	struct apu_domain *pd;
+	int ret;
+	u32 id;
+
+	ret = of_property_read_u32(node, "reg", &id);
+	if (ret) {
+		dev_dbg(apusys->dev, "%pOF: invalid reg: %d\n", node, ret);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (id >= apusys->data->num_domains) {
+		dev_dbg(apusys->dev, "%pOF: invalid id %d\n", node, id);
+		return ERR_PTR(-EINVAL);
+	}
+
+	domain_data = &apusys->data->domains_data[id];
+
+	pd = devm_kzalloc(apusys->dev, sizeof(*pd), GFP_KERNEL);
+	if (!pd)
+		return ERR_PTR(-ENOMEM);
+
+	pd->data   = domain_data;
+	pd->apusys = apusys;
+
+	pd->domain_supply = devm_regulator_get_optional(apusys->dev, "domain");
+	if (IS_ERR(pd->domain_supply))
+		pd->domain_supply = NULL;
+
+	/*
+	 * For HW using ipu_if, the clock is switched to 26M
+	 * when power down top domain and switch to default clock rate
+	 * before power on.
+	 */
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		pd->clk_top_conn = of_clk_get_by_name(node, "clk_top_conn");
+		if (IS_ERR(pd->clk_top_conn)) {
+			dev_err(apusys->dev, "Fail to get clk_top_conn clock\n");
+			ret = PTR_ERR(pd->clk_top_conn);
+			goto err_put_clocks;
+		}
+
+		pd->clk_top_ipu_if = of_clk_get_by_name(node, "clk_top_ipu_if");
+		if (IS_ERR(pd->clk_top_ipu_if)) {
+			dev_err(apusys->dev, "Fail to get clk_top_ipu_if clock\n");
+			ret = PTR_ERR(pd->clk_top_ipu_if);
+			goto err_put_clocks;
+		}
+
+		pd->clk_off = of_clk_get_by_name(node, "clk_off");
+		if (IS_ERR(pd->clk_off)) {
+			dev_err(apusys->dev, "Fail to get clk_off clock\n");
+			ret = PTR_ERR(pd->clk_off);
+			goto err_put_clocks;
+		}
+
+		pd->clk_on_def = of_clk_get_by_name(node, "clk_on_default");
+		if (IS_ERR(pd->clk_on_def)) {
+			dev_err(apusys->dev, "Fail to get clk_on_default clock\n");
+			ret = PTR_ERR(pd->clk_on_def);
+			goto err_put_clocks;
+		}
+	} else {
+		ret = devm_clk_bulk_get_all(apusys->dev, &pd->clks);
+		if (ret < 0) {
+			dev_err(apusys->dev, "failed to get clocks %d\n", ret);
+			return ERR_PTR(ret);
+		}
+		pd->num_clks = ret;
+	}
+
+	if (apusys->domains[id]) {
+		ret = -EINVAL;
+		dev_err(apusys->dev, "domain id %d already exists\n", id);
+		goto err_put_clocks;
+	}
+
+	/* set rpc hw init status */
+	ret = apu_top_init_hw(pd);
+	if (ret < 0) {
+		dev_dbg(apusys->dev, "top init fail ret = %d\n", ret);
+		goto err_put_clocks;
+	}
+
+	if (!pd->data->name)
+		pd->genpd.name = node->name;
+	else
+		pd->genpd.name = pd->data->name;
+	pd->genpd.power_off = apu_top_power_off;
+	pd->genpd.power_on = apu_top_power_on;
+
+	/*
+	 * Initially turn on all domains to make the domains usable
+	 * with !CONFIG_PM and to get the hardware in sync with the
+	 * software.  The unused domains will be switched off during
+	 * late_init time.
+	 */
+	ret = pd->genpd.power_on(&pd->genpd);
+	if (ret < 0) {
+		dev_dbg(apusys->dev, "%pOF: power on domain fail: %d\n",
+			node, ret);
+		goto err_put_clocks;
+	}
+
+	pm_genpd_init(&pd->genpd, NULL, false);
+
+	apusys->domains[id] = &pd->genpd;
+
+	return apusys->pd_data.domains[id];
+
+err_put_clocks:
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_put(pd->clk_top_conn);
+		clk_put(pd->clk_top_ipu_if);
+		clk_put(pd->clk_off);
+		clk_put(pd->clk_on_def);
+	}
+	return ERR_PTR(ret);
+}
+
+static void apu_remove_one_domain(struct apu_domain *pd)
+{
+	int ret;
+
+	if (pd->genpd.power_off)
+		pd->genpd.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.
+	 */
+	ret = pm_genpd_remove(&pd->genpd);
+	if (ret < 0)
+		dev_dbg(pd->apusys->dev,
+			"Remove domain '%s' : %d - state may be inconsistent\n",
+			pd->genpd.name, ret);
+
+	if (APU_PD_CAPS(pd, APU_PD_IPUIF_HW_CG)) {
+		clk_put(pd->clk_top_conn);
+		clk_put(pd->clk_top_ipu_if);
+		clk_put(pd->clk_off);
+		clk_put(pd->clk_on_def);
+	}
+}
+
+static void apu_domain_cleanup(struct apusys *apusys)
+{
+	struct generic_pm_domain *genpd;
+	struct apu_domain *pd;
+	int i;
+
+	for (i = apusys->pd_data.num_domains - 1; i >= 0; i--) {
+		genpd = apusys->pd_data.domains[i];
+		if (genpd) {
+			pd = to_apu_domain(genpd);
+			apu_remove_one_domain(pd);
+		}
+	}
+}
+
+static const struct of_device_id apu_pm_of_match[] = {
+	{
+		.compatible = "mediatek,mt8192-apu-pm",
+		.data = &mt8192_apu_pm_data,
+	},
+	{ }
+};
+
+static int apu_pm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct genpd_onecell_data *pd_data;
+	const struct apu_pm_data *data;
+	struct device_node *node;
+	struct apusys *apusys;
+	int ret;
+
+	data = of_device_get_match_data(&pdev->dev);
+	if (!data) {
+		dev_dbg(&pdev->dev, "no power domain data\n");
+		return -EINVAL;
+	}
+
+	apusys = devm_kzalloc(dev,
+			      struct_size(apusys, domains, data->num_domains),
+			      GFP_KERNEL);
+	if (!apusys)
+		return -ENOMEM;
+
+	apusys->dev = dev;
+	apusys->data = data;
+	apusys->pd_data.domains = apusys->domains;
+	apusys->pd_data.num_domains = data->num_domains;
+
+	apusys->vsram_supply = devm_regulator_get_optional(dev, "vsram");
+	if (IS_ERR(apusys->vsram_supply)) {
+		ret = PTR_ERR(apusys->vsram_supply);
+		if (ret != -EPROBE_DEFER) {
+			dev_err(dev, "vsram_supply fail, ret=%d", ret);
+			apusys->vsram_supply = NULL;
+		}
+		return ret;
+	}
+
+	/* rpc */
+	apusys->rpc = syscon_node_to_regmap(np);
+	if (IS_ERR(apusys->rpc)) {
+		dev_err(dev, "Unable to get rpc\n");
+		return PTR_ERR(apusys->rpc);
+	}
+
+	/* scpsys */
+	apusys->scpsys = syscon_regmap_lookup_by_phandle(np, "mediatek,scpsys");
+	if (IS_ERR(apusys->scpsys)) {
+		dev_err(dev, "Unable to get scpsys\n");
+		return PTR_ERR(apusys->scpsys);
+	}
+
+	/* apusys conn */
+	apusys->conn = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu-conn");
+	if (IS_ERR(apusys->conn))
+		dev_info(dev, "No optional phandle apu_conn\n");
+
+	/* apusys conn1 */
+	apusys->conn1 = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu-conn1");
+	if (IS_ERR(apusys->conn1))
+		dev_info(dev, "No optional phandle apu_conn1\n");
+
+	/* apusys vcore */
+	apusys->vcore = syscon_regmap_lookup_by_phandle_optional(np, "mediatek,apu-vcore");
+	if (IS_ERR(apusys->vcore))
+		dev_info(dev, "No optional phandle apu_vcore\n");
+
+	for_each_available_child_of_node(np, node) {
+		struct generic_pm_domain *domain;
+
+		domain = apu_add_one_domain(apusys, node);
+		if (IS_ERR(domain)) {
+			ret = PTR_ERR(domain);
+			of_node_put(node);
+			goto err_cleanup_domains;
+		}
+	}
+
+	ret = of_genpd_add_provider_onecell(np, &apusys->pd_data);
+	if (ret) {
+		dev_dbg(dev, "failed to add provider: %d\n", ret);
+		goto err_cleanup_domains;
+	}
+
+	pd_data = &apusys->pd_data;
+
+	return 0;
+
+err_cleanup_domains:
+	apu_domain_cleanup(apusys);
+	return ret;
+}
+
+static struct platform_driver apu_pm_driver = {
+	.probe = apu_pm_probe,
+	.driver = {
+		.name = "mtk-apu-pm",
+		.suppress_bind_attrs = true,
+		.of_match_table = apu_pm_of_match,
+	},
+};
+builtin_platform_driver(apu_pm_driver);
+
-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:35 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:35 +0800
Subject: [PATCH v2 2/7] clk: mediatek: mt8192: Add APU clocks support
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-3-git-send-email-flora.fu@mediatek.com>

Add APU clocks support on MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 drivers/clk/mediatek/clk-mt8192.c | 91 +++++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mt8192.c b/drivers/clk/mediatek/clk-mt8192.c
index bf6a2084a348..4eb61f006306 100644
--- a/drivers/clk/mediatek/clk-mt8192.c
+++ b/drivers/clk/mediatek/clk-mt8192.c
@@ -244,6 +244,65 @@ static const char * const ccu_parents[] = {
 	"univpll_d6_d2"
 };
 
+static const char * const dsp_parents[] = {
+	"clk26m",
+	"univpll_d6_d2",
+	"univpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mmpll_d4",
+	"mainpll_d3",
+	"univpll_d3"
+};
+
+static const char * const dsp1_parents[] = {
+	"clk26m",
+	"npupll_ck",
+	"mainpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mainpll_d3",
+	"univpll_d3",
+	"apupll_ck"
+};
+
+static const char * const dsp1_npupll_parents[] = {
+	"dsp1_sel",
+	"npupll_ck"
+};
+
+static const char * const dsp2_parents[] = {
+	"clk26m",
+	"npupll_ck",
+	"mainpll_d4_d2",
+	"univpll_d5",
+	"univpll_d4",
+	"mainpll_d3",
+	"univpll_d3",
+	"apupll_ck"
+};
+
+static const char * const dsp2_npupll_parents[] = {
+	"dsp2_sel",
+	"npupll_ck"
+};
+
+static const char * const dsp5_parents[] = {
+	"clk26m",
+	"apupll_ck",
+	"univpll_d4_d2",
+	"mainpll_d4",
+	"univpll_d4",
+	"mmpll_d4",
+	"mainpll_d3",
+	"univpll_d3"
+};
+
+static const char * const dsp5_apupll_parents[] = {
+	"dsp5_sel",
+	"apupll_ck"
+};
+
 static const char * const dsp7_parents[] = {
 	"clk26m",
 	"mainpll_d4_d2",
@@ -255,6 +314,17 @@ static const char * const dsp7_parents[] = {
 	"mmpll_d4"
 };
 
+static const char * const ipu_if_parents[] = {
+	"clk26m",
+	"univpll_d6_d2",
+	"mainpll_d4_d2",
+	"univpll_d4_d2",
+	"univpll_d5",
+	"mainpll_d4",
+	"tvdpll_ck",
+	"univpll_d4"
+};
+
 static const char * const mfg_ref_parents[] = {
 	"clk26m",
 	"clk26m",
@@ -734,9 +804,26 @@ static const struct mtk_mux top_mtk_muxes[] = {
 		cam_parents, 0x030, 0x034, 0x038, 16, 4, 23, 0x004, 10),
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_CCU_SEL, "ccu_sel",
 		ccu_parents, 0x030, 0x034, 0x038, 24, 4, 31, 0x004, 11),
+	/* CLK_CFG_3 */
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP_SEL, "dsp_sel",
+		dsp_parents, 0x040, 0x044, 0x048, 0, 3, 7, 0x004, 12),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP1_SEL, "dsp1_sel",
+		dsp1_parents, 0x040, 0x044, 0x048, 8, 3, 15, 0x004, 13),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP1_NPUPLL_SEL, "dsp1_npupll_sel",
+		dsp1_npupll_parents, 0x040, 0x044, 0x048, 11, 1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP2_SEL, "dsp2_sel",
+		dsp2_parents, 0x040, 0x044, 0x048, 16, 3, 23, 0x004, 14),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP2_NPUPLL_SEL, "dsp2_npupll_sel",
+		dsp2_npupll_parents, 0x040, 0x044, 0x048, 19, 1, -1, -1),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP5_SEL, "dsp5_sel",
+		dsp5_parents, 0x040, 0x044, 0x048, 24, 3, 31, 0x004, 15),
+	MUX_CLR_SET_UPD(CLK_TOP_DSP5_APUPLL_SEL, "dsp5_apupll_sel",
+		dsp5_apupll_parents, 0x040, 0x044, 0x048, 27, 1, -1, -1),
 	/* CLK_CFG_4 */
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_DSP7_SEL, "dsp7_sel",
 		dsp7_parents, 0x050, 0x054, 0x058, 0, 3, 7, 0x004, 16),
+	MUX_GATE_CLR_SET_UPD(CLK_TOP_IPU_IF_SEL, "ipu_if_sel",
+		ipu_if_parents, 0x050, 0x054, 0x058, 8, 3, 15, 0x004, 17),
 	MUX_GATE_CLR_SET_UPD(CLK_TOP_MFG_REF_SEL, "mfg_ref_sel",
 		mfg_ref_parents, 0x050, 0x054, 0x058, 16, 2, 23, 0x004, 18),
 	MUX_CLR_SET_UPD(CLK_TOP_MFG_PLL_SEL, "mfg_pll_sel",
@@ -1175,6 +1262,10 @@ static const struct mtk_pll_data plls[] = {
 		0, 0, 32, 0x031c, 24, 0x0040, 0x000c, 0, 0x0320, 0),
 	PLL_B(CLK_APMIXED_APLL2, "apll2", 0x032c, 0x033c, 0x00000000,
 		0, 0, 32, 0x0330, 24, 0, 0, 0, 0x0334, 0),
+	PLL_B(CLK_APMIXED_APUPLL, "apupll", 0x03a0, 0x03ac, 0xff000001,
+		HAVE_RST_BAR, BIT(23), 22, 0x03a4, 24, 0, 0, 0, 0x03a4, 0),
+	PLL_B(CLK_APMIXED_NPUPLL, "npupll", 0x03b4, 0x03c0, 0x00000001,
+		0, 0, 22, 0x03b8, 24, 0, 0, 0, 0x03b8, 0),
 };
 
 static struct clk_onecell_data *top_clk_data;
-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:39 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:39 +0800
Subject: [PATCH v2 6/7] arm64: dts: mt8192: Add APU node
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-7-git-send-email-flora.fu@mediatek.com>

Add APU node to MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index eb17274c3719..561025d2ebab 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1016,6 +1016,23 @@
 			#clock-cells = <1>;
 		};
 
+		apu_mbox: apu_mbox at 19000000 {
+			compatible = "mediatek,mt8192-apu-mbox", "syscon";
+			reg = <0 0x19000000 0 0x1000>;
+		};
+
+		apu_conn: apu_conn at 19020000 {
+			compatible = "mediatek,mt8192-apu-conn", "syscon";
+			reg = <0 0x19020000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
+		apu_vcore: apu_vcore at 19029000 {
+			compatible = "mediatek,mt8192-apu-vcore", "syscon";
+			reg = <0 0x19029000 0 0x1000>;
+			#clock-cells = <1>;
+		};
+
 		larb13: larb at 1a001000 {
 			compatible = "mediatek,mt8192-smi-larb";
 			reg = <0 0x1a001000 0 0x1000>;
-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:37 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:37 +0800
Subject: [PATCH v2 4/7] dt-bindings: soc: mediatek: apusys: Add new document
 for APU power domain
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-5-git-send-email-flora.fu@mediatek.com>

Document the bindings for APU power domain on MediaTek SoC.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
Note:
This patch depends on MT8192 clock[1] patches which haven't yet been accepted.
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/
---
 .../soc/mediatek/mediatek,apu-pm.yaml         | 145 ++++++++++++++++++
 1 file changed, 145 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
new file mode 100644
index 000000000000..6ff966920917
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek APU Power Domains
+
+maintainers:
+  - Flora Fu <flora.fu at mediatek.com>
+
+description: |
+  Mediatek AI Process Unit (APU) include support for power domains which can be
+  powered up/down by software.
+  APU subsys belonging to a power domain should contain a 'power-domains'
+  property that is a phandle for apuspm node representing the domain.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8192-apu-pm
+      - const: syscon
+
+  reg:
+    description: Address range of the APU power domain controller.
+    maxItems: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  '#power-domain-cells':
+    const: 1
+
+  vsram-supply:
+    description: apu sram regulator supply.
+
+  mediatek,scpsys:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys register range.
+
+  mediatek,apu-conn:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu conn register range.
+
+  mediatek,apu-conn1:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu conn1 register range.
+
+  mediatek,apu-vcore:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: |
+      phandle to the device containing the scpsys apu vcore register range.
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+    type: object
+    description: |
+      Represents the power domains within the power controller node as
+      documented in Documentation/devicetree/bindings/power/power-domain.yaml.
+
+    properties:
+      reg:
+        description: |
+          Power domain index. Valid values are defined in:
+          "include/dt-bindings/power/mt8182-apu-power.h"
+        maxItems: 1
+
+      '#power-domain-cells':
+        description: |
+          Must be 0 for nodes representing a single PM domain and 1 for nodes
+          providing multiple PM.
+
+      clocks:
+        description: |
+          List of phandles of clocks list. Specify by order according to
+          power-up sequence.
+
+      clock-names:
+        description: |
+          List of names of clocks. Specify by order according to power-up
+          sequence.
+
+      assigned-clocks:
+        maxItems: 2
+
+      assigned-clock-parents:
+        maxItems: 2
+
+      domain-supply:
+        description: domain regulator supply.
+
+    required:
+      - reg
+      - '#power-domain-cells'
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - '#power-domain-cells'
+  - vsram-supply
+  - mediatek,scpsys
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8192-clk.h>
+    apuspm: power-domain at 190f0000 {
+        compatible = "mediatek,mt8192-apu-pm", "syscon";
+        reg = <0x190f0000 0x1000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        #power-domain-cells = <1>;
+        vsram-supply = <&mt6359_vsram_md_ldo_reg>;
+        mediatek,scpsys = <&scpsys>;
+        mediatek,apu-conn = <&apu_conn>;
+        mediatek,apu-vcore = <&apu_vcore>;
+
+        apu_top: power-domain at 0 {
+            reg = <0>;
+            #power-domain-cells = <0>;
+            clocks = <&topckgen CLK_TOP_DSP_SEL>,
+                     <&topckgen CLK_TOP_IPU_IF_SEL>,
+                     <&clk26m>,
+                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+            clock-names = "clk_top_conn",
+                          "clk_top_ipu_if",
+                          "clk_off",
+                          "clk_on_default";
+            assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
+                              <&topckgen CLK_TOP_IPU_IF_SEL>;
+            assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
+                                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+            domain-supply = <&mt6359_vproc1_buck_reg>;
+        };
+    };
-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:36 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:36 +0800
Subject: [PATCH v2 3/7] dt-bindings: arm: mediatek: Add new document bindings
 for APU
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-4-git-send-email-flora.fu@mediatek.com>

Document the apusys bindings.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
 .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
new file mode 100644
index 000000000000..d46290548b34
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek APUSYS Controller
+
+maintainers:
+  - Flora Fu <flora.fu at mediatek.com>
+
+description:
+  The Mediatek apusys controller provides functional configurations and clocks
+  to the system.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - mediatek,mt8192-apu-mbox
+          - mediatek,mt8192-apu-conn
+          - mediatek,mt8192-apu-vcore
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  '#clock-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    apu_mbox: apu_mbox at 19000000 {
+        compatible = "mediatek,mt8192-apu-mbox", "syscon";
+        reg = <0x19000000 0x1000>;
+    };
+
+  - |
+    apu_conn: apu_conn at 19020000 {
+        compatible = "mediatek,mt8192-apu-conn", "syscon";
+        reg = <0x19020000 0x1000>;
+        #clock-cells = <1>;
+    };
+
+  - |
+    apu_vcore: apu_vcore at 19029000 {
+        compatible = "mediatek,mt8192-apu-vcore", "syscon";
+        reg = <0x19029000 0x1000>;
+        #clock-cells = <1>;
+    };
-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:33 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:33 +0800
Subject: [PATCH v2 0/7] Add Support for MediaTek MT8192 APU Power
Message-ID: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>

The MediaTek AI Processing Unit (APU) is a proprietary hardware
in the SoC to support AI operations.
The series is to create apusys in the SoC folder for developing
the related drivers. Add the apu clocks, basic apu nodes and the
power domain to provide the power controller of APU subsystem.

This series is based on MT8192 clock[1] and PMIC[2] patches.
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=454523
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=458733

Change notes:
v1->v2:
  1) update expression "s/_/-/" in dt-bindings documents.
  2) drop apu power domain header file for mt8192.

v1: https://patchwork.kernel.org/project/linux-mediatek/list/?series=461999

Flora Fu (7):
  dt-bindings: clock: Add MT8192 APU clock bindings
  clk: mediatek: mt8192: Add APU clocks support
  dt-bindings: arm: mediatek: Add new document bindings for APU
  dt-bindings: soc: mediatek: apusys: Add new document for APU power
    domain
  soc: mediatek: apu: Add apusys and add apu power domain driver
  arm64: dts: mt8192: Add APU node
  arm64: dts: mt8192: Add APU power domain node

 .../arm/mediatek/mediatek,apusys.yaml         |  56 ++
 .../soc/mediatek/mediatek,apu-pm.yaml         | 145 +++++
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts   |   7 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |  45 ++
 drivers/clk/mediatek/clk-mt8192.c             |  91 +++
 drivers/soc/mediatek/Kconfig                  |  10 +
 drivers/soc/mediatek/Makefile                 |   1 +
 drivers/soc/mediatek/apusys/Makefile          |   2 +
 drivers/soc/mediatek/apusys/mtk-apu-pm.c      | 612 ++++++++++++++++++
 include/dt-bindings/clock/mt8192-clk.h        |  14 +-
 10 files changed, 981 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
 create mode 100644 drivers/soc/mediatek/apusys/Makefile
 create mode 100644 drivers/soc/mediatek/apusys/mtk-apu-pm.c

-- 
2.18.0

From flora.fu at mediatek.com  Thu Apr 15 06:52:40 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Thu, 15 Apr 2021 13:52:40 +0800
Subject: [PATCH v2 7/7] arm64: dts: mt8192: Add APU power domain node
In-Reply-To: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
Message-ID: <1618465960-3013-8-git-send-email-flora.fu@mediatek.com>

Add APU power domain node to MT8192.

Signed-off-by: Flora Fu <flora.fu at mediatek.com>
---
Note:
This patch depends on MT8192 clock[1] and PMIC[2] patches which haven't yet been accepted.
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/1617188527-3392-9-git-send-email-hsin-hsiung.wang at mediatek.com/
---
 arch/arm64/boot/dts/mediatek/mt8192-evb.dts |  7 ++++++
 arch/arm64/boot/dts/mediatek/mt8192.dtsi    | 28 +++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 1769f3a9b510..688c97c46d44 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -65,3 +65,10 @@
 &mt6359_vrf12_ldo_reg {
 	regulator-always-on;
 };
+
+&apuspm {
+	vsram-supply = <&mt6359_vsram_md_ldo_reg>;
+	apu_top: power-domain at 0 {
+		domain-supply = <&mt6359_vproc1_buck_reg>;
+	};
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 561025d2ebab..90436757386e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1033,6 +1033,34 @@
 			#clock-cells = <1>;
 		};
 
+		apuspm: power-domain at 190f0000 {
+			compatible = "mediatek,mt8192-apu-pm", "syscon";
+			reg = <0 0x190f0000 0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#power-domain-cells = <1>;
+			mediatek,scpsys = <&scpsys>;
+			mediatek,apu-conn = <&apu_conn>;
+			mediatek,apu-vcore = <&apu_vcore>;
+
+			apu_top: power-domain at 0 {
+				reg = <0>;
+				#power-domain-cells = <0>;
+				clocks = <&topckgen CLK_TOP_DSP_SEL>,
+					 <&topckgen CLK_TOP_IPU_IF_SEL>,
+					 <&clk26m>,
+					 <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+				clock-names = "clk_top_conn",
+					      "clk_top_ipu_if",
+					      "clk_off",
+					      "clk_on_default";
+				assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
+						  <&topckgen CLK_TOP_IPU_IF_SEL>;
+				assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
+							 <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
+			};
+		};
+
 		larb13: larb at 1a001000 {
 			compatible = "mediatek,mt8192-smi-larb";
 			reg = <0 0x1a001000 0 0x1000>;
-- 
2.18.0

From navam at xilinx.com  Thu Apr 15 07:07:43 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 15 Apr 2021 06:07:43 +0000
Subject: [PATCH v3 2/3] dt-bindings: fpga: Add binding doc for versal fpga
 manager
In-Reply-To: <CAL_JsqKAP5Up7=qJEM6E0HuV2-faaVqTg+S=pdD8RpWyJ3KVcQ@mail.gmail.com>
References: <20210304070224.22346-1-nava.manne@xilinx.com>
 <20210304070224.22346-3-nava.manne@xilinx.com>
 <20210308201944.GA2886704@robh.at.kernel.org>
 <MWHPR02MB26231DD759D8C9D1CB26EC1EC2919@MWHPR02MB2623.namprd02.prod.outlook.com>
 <CAL_JsqLDK5pNprA5RJq8VfTbQX=hP-8NUyY6Xsesz3TE6=YYeg@mail.gmail.com>
 <CAL_JsqKAP5Up7=qJEM6E0HuV2-faaVqTg+S=pdD8RpWyJ3KVcQ@mail.gmail.com>
Message-ID: <MWHPR02MB26239FBFB985D5AE1A052C24C24D9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Rob,

	Please find my response inline.

> -----Original Message-----
> From: Rob Herring <robh at kernel.org>
> Sent: Wednesday, March 10, 2021 10:50 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: mdf at kernel.org; trix at redhat.com; Michal Simek <michals at xilinx.com>;
> gregkh at linuxfoundation.org; Jolly Shah <JOLLYS at xilinx.com>; Rajan Vaja
> <RAJANV at xilinx.com>; arnd at arndb.de; Manish Narani
> <MNARANI at xilinx.com>; Amit Sunil Dhamne <amitsuni at xilinx.com>; Tejas
> Patel <tejasp at xlnx.xilinx.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; chinnikishore369 at gmail.com; Appana Durga
> Kedareswara Rao <appanad at xilinx.com>
> Subject: Re: [PATCH v3 2/3] dt-bindings: fpga: Add binding doc for versal fpga
> manager
> 
> On Wed, Mar 10, 2021 at 10:12 AM Rob Herring <robh at kernel.org> wrote:
> >
> > On Wed, Mar 10, 2021 at 3:50 AM Nava kishore Manne
> <navam at xilinx.com> wrote:
> > >
> > > Hi Rob,
> > >
> > >         Thanks for providing the review comments.
> > > Please find my response inline.
> > >
> > > > -----Original Message-----
> > > > From: Rob Herring <robh at kernel.org>
> > > > Sent: Tuesday, March 9, 2021 1:50 AM
> > > > To: Nava kishore Manne <navam at xilinx.com>
> > > > Cc: mdf at kernel.org; trix at redhat.com; Michal Simek
> > > > <michals at xilinx.com>; gregkh at linuxfoundation.org; Jolly Shah
> > > > <JOLLYS at xilinx.com>; Rajan Vaja <RAJANV at xilinx.com>;
> > > > arnd at arndb.de; Manish Narani <MNARANI at xilinx.com>; Amit Sunil
> > > > Dhamne <amitsuni at xilinx.com>; Tejas Patel
> > > > <tejasp at xlnx.xilinx.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; chinnikishore369 at gmail.com;
> > > > Appana Durga Kedareswara Rao <appanad at xilinx.com>
> > > > Subject: Re: [PATCH v3 2/3] dt-bindings: fpga: Add binding doc for
> > > > versal fpga manager
> > > >
> > > > On Thu, Mar 04, 2021 at 12:32:23PM +0530, Nava kishore Manne
> wrote:
> > > > > From: Appana Durga Kedareswara rao
> <appana.durga.rao at xilinx.com>
> > > > >
> > > > > This patch adds binding doc for versal fpga manager driver.
> > > >
> > > > Why do you need a DT entry for this? Can't the Versal firmware
> > > > driver instantiate the fpga-mgr device?
> > > >
> > > This dt entry is need to handle the fpga regions properly for both full and
> Partial bitstream loading use cases and it cannot be done by Versal firmware
> driver instantiate.
> >
> > Ah yes, I forgot about that.
> 
> Looking at this some more, please convert xlnx,zynqmp-firmware.txt to
> schema and add the node for this there. We don't need a whole other
> schema file just for a node and compatible. Also, looks like xlnx,zynqmp-
> pcap-fpga.txt is the prior version of the same thing, so it should be handled
> in the schema too.
> 

Will fix this in the next version

Regards,
Navakishore.

From rex-bc.chen at mediatek.com  Thu Apr 15 07:14:58 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 15 Apr 2021 14:14:58 +0800
Subject: [SPAM][v2,PATCH 3/3] drm/mediatek: dpi: add bus format negotiation
In-Reply-To: <1618448968.29238.1.camel@mtksdaap41>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>
 <1618448968.29238.1.camel@mtksdaap41>
Message-ID: <1618467298.4349.3.camel@mtksdccf07>

On Thu, 2021-04-15 at 09:09 +0800, CK Hu wrote:
Hello CK,
> Hi, Rex:
> 
> On Wed, 2021-04-14 at 21:35 +0800, Rex-BC Chen wrote:
> > Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
> > the possible output and input formats for the current mode and monitor,
> > and use the negotiated formats in a basic atomic_check callback.
> > 
> > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 89 ++++++++++++++++++++++++++++--
> >  1 file changed, 84 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index 76431fe849b8..b4e9c6c8d706 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> >  	return 0;
> >  }
> >  
> > +#define MAX_OUTPUT_SEL_FORMATS	2
> > +
> > +static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> > +					struct drm_bridge_state *bridge_state,
> > +					struct drm_crtc_state *crtc_state,
> > +					struct drm_connector_state *conn_state,
> > +					unsigned int *num_output_fmts)
> > +{
> > +	struct drm_display_mode *mode = &crtc_state->mode;
> > +	u32 *output_fmts;
> > +	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > +
> > +	*num_output_fmts = 0;
> > +
> > +	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
> > +			      GFP_KERNEL);
> > +	if (!output_fmts)
> > +		return NULL;
> > +
> > +	/* Default 8bit RGB fallback */
> > +	if (dpi->conf->dual_edge) {
> > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
> > +		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
> 
> MT8183 does not support MEDIA_BUS_FMT_RGB888_1X24?
> 
> Regards,
> CK
> 
Yes, MT8183 only support MEDIA_BUS_FMT_RGB888_1X24

BRs,
Rex-BC
> > +		*num_output_fmts = 2;
> > +	} else {
> > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
> > +		*num_output_fmts = 1;
> > +	}
> > +
> > +	return output_fmts;
> > +}
> > +
> > +#define MAX_INPUT_SEL_FORMATS	1
> > +
> > +static u32 *mtk_dpi_bridge_atomic_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)
> > +{
> > +	u32 *input_fmts;
> > +
> > +	*num_input_fmts = 0;
> > +
> > +	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> > +			     GFP_KERNEL);
> > +	if (!input_fmts)
> > +		return NULL;
> > +
> > +	*num_input_fmts = 1;
> > +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> > +
> > +	return input_fmts;
> > +}
> > +
> > +static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
> > +				       struct drm_bridge_state *bridge_state,
> > +				       struct drm_crtc_state *crtc_state,
> > +				       struct drm_connector_state *conn_state)
> > +{
> > +	struct mtk_dpi *dpi = bridge->driver_private;
> > +	unsigned int out_bus_format;
> > +
> > +	out_bus_format = bridge_state->output_bus_cfg.format;
> > +
> > +	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
> > +		bridge_state->input_bus_cfg.format,
> > +		bridge_state->output_bus_cfg.format);
> > +
> > +	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
> > +		 		true : false;
> > +
> > +	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > +	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > +	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > +	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > +
> > +	return 0;
> > +}
> > +
> >  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> >  				 enum drm_bridge_attach_flags flags)
> >  {
> > @@ -574,6 +655,9 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> >  	.mode_set = mtk_dpi_bridge_mode_set,
> >  	.disable = mtk_dpi_bridge_disable,
> >  	.enable = mtk_dpi_bridge_enable,
> > +	.atomic_check = mtk_dpi_bridge_atomic_check,
> > +	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
> > +	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
> >  };
> >  
> >  void mtk_dpi_start(struct device *dev)
> > @@ -620,11 +704,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
> >  	}
> >  	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
> >  
> > -	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > -	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > -	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > -	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > -
> >  	return 0;
> >  
> >  err_cleanup:
> 
> 


From zhukeqian1 at huawei.com  Thu Apr 15 07:18:09 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 14:18:09 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
Message-ID: <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>

Hi Baolu,

Thanks for the review!

On 2021/4/14 15:00, Lu Baolu wrote:
> Hi Keqian,
> 
> On 4/13/21 4:54 PM, Keqian Zhu wrote:
>> Some types of IOMMU are capable of tracking DMA dirty log, such as
>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
>> dirty log tracking framework in the IOMMU base layer.
>>
>> Three new essential interfaces are added, and we maintaince the status
>> of dirty log tracking in iommu_domain.
>> 1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
>> 2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
>> 3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
>>
>> A new dev feature are added to indicate whether a specific type of
>> iommu hardware supports and its driver realizes them.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
>> ---
>>   drivers/iommu/iommu.c | 150 ++++++++++++++++++++++++++++++++++++++++++
>>   include/linux/iommu.h |  53 +++++++++++++++
>>   2 files changed, 203 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index d0b0a15dba84..667b2d6d2fc0 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1922,6 +1922,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>       domain->type = type;
>>       /* Assume all sizes by default; the driver may override this later */
>>       domain->pgsize_bitmap  = bus->iommu_ops->pgsize_bitmap;
>> +    mutex_init(&domain->switch_log_lock);
>>         return domain;
>>   }
>> @@ -2720,6 +2721,155 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>>   }
>>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>>   +int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
>> +               unsigned long iova, size_t size, int prot)
>> +{
>> +    const struct iommu_ops *ops = domain->ops;
>> +    int ret;
>> +
>> +    if (unlikely(!ops || !ops->switch_dirty_log))
>> +        return -ENODEV;
>> +
>> +    mutex_lock(&domain->switch_log_lock);
>> +    if (enable && domain->dirty_log_tracking) {
>> +        ret = -EBUSY;
>> +        goto out;
>> +    } else if (!enable && !domain->dirty_log_tracking) {
>> +        ret = -EINVAL;
>> +        goto out;
>> +    }
>> +
>> +    ret = ops->switch_dirty_log(domain, enable, iova, size, prot);
>> +    if (ret)
>> +        goto out;
>> +
>> +    domain->dirty_log_tracking = enable;
>> +out:
>> +    mutex_unlock(&domain->switch_log_lock);
>> +    return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_switch_dirty_log);
> 
> Since you also added IOMMU_DEV_FEAT_HWDBM, I am wondering what's the
> difference between
> 
> iommu_switch_dirty_log(on) vs. iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)
> 
> iommu_switch_dirty_log(off) vs. iommu_dev_disable_feature(IOMMU_DEV_FEAT_HWDBM)
Indeed. As I can see, IOMMU_DEV_FEAT_AUX is not switchable, so enable/disable
are not applicable for it. IOMMU_DEV_FEAT_SVA is switchable, so we can use these
interfaces for it.

IOMMU_DEV_FEAT_HWDBM is used to indicate whether hardware supports HWDBM, so we should
design it as not switchable. I will modify the commit message of patch#12, thanks!

> 
>> +
>> +int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
>> +             size_t size, unsigned long *bitmap,
>> +             unsigned long base_iova, unsigned long bitmap_pgshift)
>> +{
>> +    const struct iommu_ops *ops = domain->ops;
>> +    unsigned int min_pagesz;
>> +    size_t pgsize;
>> +    int ret = 0;
>> +
>> +    if (unlikely(!ops || !ops->sync_dirty_log))
>> +        return -ENODEV;
>> +
>> +    min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
>> +    if (!IS_ALIGNED(iova | size, min_pagesz)) {
>> +        pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
>> +               iova, size, min_pagesz);
>> +        return -EINVAL;
>> +    }
>> +
>> +    mutex_lock(&domain->switch_log_lock);
>> +    if (!domain->dirty_log_tracking) {
>> +        ret = -EINVAL;
>> +        goto out;
>> +    }
>> +
>> +    while (size) {
>> +        pgsize = iommu_pgsize(domain, iova, size);
>> +
>> +        ret = ops->sync_dirty_log(domain, iova, pgsize,
>> +                      bitmap, base_iova, bitmap_pgshift);
> 
> Any reason why do you want to do this in a per-4K page manner? This can
> lead to a lot of indirect calls and bad performance.
> 
> How about a sync_dirty_pages()?
The function name of iommu_pgsize() is a bit puzzling. Actually it will try to
compute the max size that fit into size, so the pgsize can be a large page size
even if the underlying mapping is 4K. The __iommu_unmap() also has a similar logic.

BRs,
Keqian


From zajec5 at gmail.com  Thu Apr 15 07:28:39 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 15 Apr 2021 08:28:39 +0200
Subject: [PATCH robh dt/next] dt-bindings: mfd: add Broadcom CRU
Message-ID: <20210415062839.11713-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

CRU is a block used in e.g. Northstar devices. It can be seen in the
bcm5301x.dtsi and this binding documents its proper usage.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
This is reworked version of the
[PATCH robh next] dt-bindings: bus: add Broadcom CRU
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210309142241.16259-1-zajec5 at gmail.com/
---
 .../devicetree/bindings/mfd/brcm,cru.yaml     | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/brcm,cru.yaml

diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
new file mode 100644
index 000000000000..f5bce6453c33
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/brcm,cru.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom CRU
+
+maintainers:
+  - Rafa? Mi?ecki <rafal at milecki.pl>
+
+description: |
+  Broadcom CRU ("Clock and Reset Unit" or "Central Resource Unit") is a hardware
+  block grouping smaller blocks. On Broadcom Northstar platform it contains e.g.
+  clocks, pinctrl, USB PHY and thermal.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - brcm,ns-cru
+      - const: simple-mfd
+
+  reg:
+    description: CRU registers
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+additionalProperties: true
+
+required:
+  - reg
+
+examples:
+  - |
+    cru-bus at 1800c100 {
+      compatible = "brcm,ns-cru", "simple-mfd";
+      reg = <0x1800c100 0x1d0>;
+      ranges;
+      #address-cells = <1>;
+      #size-cells = <1>;
+    };
-- 
2.26.2



From krzysztof.kozlowski at canonical.com  Thu Apr 15 07:29:27 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 15 Apr 2021 08:29:27 +0200
Subject: [PATCH v3 2/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC
In-Reply-To: <1618459535-8141-3-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-3-git-send-email-dillon.minfei@gmail.com>
Message-ID: <eb850981-e8bc-0cee-734e-475f79ea64e4@canonical.com>

On 15/04/2021 06:05, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
> v3: move 'ds,imx6q-sbc' after 'dmo,imx6q-edmqmx6' to follow the alphabetical
> order.
> 
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>


Best regards,
Krzysztof


From balbi at kernel.org  Thu Apr 15 07:31:29 2021
From: balbi at kernel.org (Felipe Balbi)
Date: Thu, 15 Apr 2021 09:31:29 +0300
Subject: [PATCH V3 2/4] soc: qcom: dcc:Add driver support for Data
 Capture and Compare unit(DCC)
In-Reply-To: <59b2e83d5d0f435112f6ae266612ff91c85b120f.1618387606.git.schowdhu@codeaurora.org>
References: <cover.1618387606.git.schowdhu@codeaurora.org>
 <59b2e83d5d0f435112f6ae266612ff91c85b120f.1618387606.git.schowdhu@codeaurora.org>
Message-ID: <87k0p4njni.fsf@kernel.org>


Hi,

Souradeep Chowdhury <schowdhu at codeaurora.org> writes:
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ad675a6..e7f0ccb 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,19 +1,22 @@
>  # SPDX-License-Identifier: GPL-2.0
>  CFLAGS_rpmh-rsc.o := -I$(src)
>  obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
> -obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
> +obj-$(CONFIG_QCOM_APR) += apr.o
>  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>  obj-$(CONFIG_QCOM_CPR)		+= cpr.o
> +obj-$(CONFIG_QCOM_DCC) += dcc.o
> +obj-$(CONFIG_QCOM_GENI_SE) +=   qcom-geni-se.o
>  obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
> +obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) += kryo-l2-accessors.o
> +obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
>  obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
>  obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
>  obj-$(CONFIG_QCOM_PDR_HELPERS)	+= pdr_interface.o
>  obj-$(CONFIG_QCOM_QMI_HELPERS)	+= qmi_helpers.o
> -qmi_helpers-y	+= qmi_encdec.o qmi_interface.o
>  obj-$(CONFIG_QCOM_RMTFS_MEM)	+= rmtfs_mem.o
>  obj-$(CONFIG_QCOM_RPMH)		+= qcom_rpmh.o
> -qcom_rpmh-y			+= rpmh-rsc.o
> -qcom_rpmh-y			+= rpmh.o
> +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
> +obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
>  obj-$(CONFIG_QCOM_SMD_RPM)	+= smd-rpm.o
>  obj-$(CONFIG_QCOM_SMEM) +=	smem.o
>  obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
> @@ -21,8 +24,6 @@ obj-$(CONFIG_QCOM_SMP2P)	+= smp2p.o
>  obj-$(CONFIG_QCOM_SMSM)	+= smsm.o
>  obj-$(CONFIG_QCOM_SOCINFO)	+= socinfo.o
>  obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
> -obj-$(CONFIG_QCOM_APR) += apr.o
> -obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
> -obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
> -obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
> -obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=	kryo-l2-accessors.o
> +qmi_helpers-y   += qmi_encdec.o qmi_interface.o
> +qcom_rpmh-y                     += rpmh-rsc.o
> +qcom_rpmh-y                     += rpmh.o

why so many changes?

> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> new file mode 100644
> index 0000000..fcd5580
> --- /dev/null
> +++ b/drivers/soc/qcom/dcc.c
> @@ -0,0 +1,1539 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/cdev.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +

one blank line is enough

> +#define TIMEOUT_US		100
> +
> +#define dcc_writel(drvdata, val, off)					\
> +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
> +#define dcc_readl(drvdata, off)						\
> +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
> +
> +#define dcc_sram_readl(drvdata, off)					\
> +	readl(drvdata->ram_base + off)

this would be probably be better as static inlines.

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

From zhukeqian1 at huawei.com  Thu Apr 15 07:59:26 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 14:59:26 +0800
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile
 helpers
In-Reply-To: <20210414134409.1266357-2-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-2-maz@kernel.org>
Message-ID: <baa268cf-c92d-6b97-da4c-e7da2a9ccb7a@huawei.com>

Hi Marc,

On 2021/4/14 21:44, Marc Zyngier wrote:
> KVM/arm64 is the sole user of perf_num_counters(), and really
> could do without it. Stop using the obsolete API by relying on
> the existing probing code.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/kvm/perf.c     | 7 +------
>  arch/arm64/kvm/pmu-emul.c | 2 +-
>  include/kvm/arm_pmu.h     | 4 ++++
>  3 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> index 739164324afe..b8b398670ef2 100644
> --- a/arch/arm64/kvm/perf.c
> +++ b/arch/arm64/kvm/perf.c
> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
>  
>  int kvm_perf_init(void)
>  {
> -	/*
> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> -	 * hardware performance counters. This could ensure the presence of
> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> -	 */
> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> +	if (kvm_pmu_probe_pmuver() != 0xf)
The probe() function may be called many times (kvm_arm_pmu_v3_set_attr also calls it).
I don't know whether the first calling is enough. If so, can we use a static variable
in it, so the following calling can return the result right away?

Thanks,
Keqian


From lars at metafoo.de  Thu Apr 15 08:06:25 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 15 Apr 2021 09:06:25 +0200
Subject: [RFC v2 PATCH 0/7] Xilinx DMA enhancements and optimization
In-Reply-To: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <0948eae0-b304-79f8-7d9a-543cba78fbe5@metafoo.de>

On 4/9/21 7:55 PM, Radhey Shyam Pandey wrote:
> Some background about the patch series: Xilinx Axi Ethernet device driver
> (xilinx_axienet_main.c) currently has axi-dma code inside it. The goal
> is to refactor axiethernet driver and use existing AXI DMA driver using
> DMAEngine API.

This is pretty neat! Do you have the patches that modify the AXI 
Ethernet driver in a public tree somewhere, so this series can be seen 
in context?



From lars at metafoo.de  Thu Apr 15 08:08:59 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 15 Apr 2021 09:08:59 +0200
Subject: [RFC v2 PATCH 5/7] dmaengine: xilinx_dma: Freeup active list
 based on descriptor completion bit
In-Reply-To: <1617990965-35337-6-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-6-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <ec177886-fc14-b52e-4c98-da523fa711d9@metafoo.de>

On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
> AXIDMA IP in SG mode sets completion bit to 1 when the transfer is
> completed. Read this bit to move descriptor from active list to the
> done list. This feature is needed when interrupt delay timeout and
> IRQThreshold is enabled i.e Dly_IrqEn is triggered w/o completing
> interrupt threshold.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> - Check BD completion bit only for SG mode.
> - Modify the logic to have early return path.
> ---
>   drivers/dma/xilinx/xilinx_dma.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 890bf46b36e5..f2305a73cb91 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -177,6 +177,7 @@
>   #define XILINX_DMA_CR_COALESCE_SHIFT	16
>   #define XILINX_DMA_BD_SOP		BIT(27)
>   #define XILINX_DMA_BD_EOP		BIT(26)
> +#define XILINX_DMA_BD_COMP_MASK		BIT(31)
>   #define XILINX_DMA_COALESCE_MAX		255
>   #define XILINX_DMA_NUM_DESCS		512
>   #define XILINX_DMA_NUM_APP_WORDS	5
> @@ -1683,12 +1684,18 @@ static void xilinx_dma_issue_pending(struct dma_chan *dchan)
>   static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
>   {
>   	struct xilinx_dma_tx_descriptor *desc, *next;
> +	struct xilinx_axidma_tx_segment *seg;
>   
>   	/* This function was invoked with lock held */
>   	if (list_empty(&chan->active_list))
>   		return;
>   
>   	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
> +		/* TODO: remove hardcoding for axidma_tx_segment */
> +		seg = list_last_entry(&desc->segments,
> +				      struct xilinx_axidma_tx_segment, node);
This needs to be fixed before this can be merged as it right now will 
break the non AXIDMA variants.
> +		if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
> +			break;
>   		if (chan->has_sg && chan->xdev->dma_config->dmatype !=
>   		    XDMA_TYPE_VDMA)
>   			desc->residue = xilinx_dma_get_residue(chan, desc);




From lars at metafoo.de  Thu Apr 15 08:10:54 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 15 Apr 2021 09:10:54 +0200
Subject: [RFC v2 PATCH 6/7] dmaengine: xilinx_dma: Use tasklet_hi_schedule
 for timing critical usecase
In-Reply-To: <1617990965-35337-7-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-7-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <52f01459-13be-ff29-1c07-b98636169c74@metafoo.de>

On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
> Schedule tasklet with high priority to ensure that callback processing
> is prioritized. It improves throughput for netdev dma clients.
Do you have specific numbers on the throughput improvement?


From baolu.lu at linux.intel.com  Thu Apr 15 08:03:52 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Thu, 15 Apr 2021 15:03:52 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
 <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
Message-ID: <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>

On 4/15/21 2:18 PM, Keqian Zhu wrote:
> Hi Baolu,
> 
> Thanks for the review!
> 
> On 2021/4/14 15:00, Lu Baolu wrote:
>> Hi Keqian,
>>
>> On 4/13/21 4:54 PM, Keqian Zhu wrote:
>>> Some types of IOMMU are capable of tracking DMA dirty log, such as
>>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
>>> dirty log tracking framework in the IOMMU base layer.
>>>
>>> Three new essential interfaces are added, and we maintaince the status
>>> of dirty log tracking in iommu_domain.
>>> 1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
>>> 2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
>>> 3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
>>>
>>> A new dev feature are added to indicate whether a specific type of
>>> iommu hardware supports and its driver realizes them.
>>>
>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
>>> ---
>>>    drivers/iommu/iommu.c | 150 ++++++++++++++++++++++++++++++++++++++++++
>>>    include/linux/iommu.h |  53 +++++++++++++++
>>>    2 files changed, 203 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index d0b0a15dba84..667b2d6d2fc0 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -1922,6 +1922,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>>        domain->type = type;
>>>        /* Assume all sizes by default; the driver may override this later */
>>>        domain->pgsize_bitmap  = bus->iommu_ops->pgsize_bitmap;
>>> +    mutex_init(&domain->switch_log_lock);
>>>          return domain;
>>>    }
>>> @@ -2720,6 +2721,155 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>>>    }
>>>    EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>>>    +int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
>>> +               unsigned long iova, size_t size, int prot)
>>> +{
>>> +    const struct iommu_ops *ops = domain->ops;
>>> +    int ret;
>>> +
>>> +    if (unlikely(!ops || !ops->switch_dirty_log))
>>> +        return -ENODEV;
>>> +
>>> +    mutex_lock(&domain->switch_log_lock);
>>> +    if (enable && domain->dirty_log_tracking) {
>>> +        ret = -EBUSY;
>>> +        goto out;
>>> +    } else if (!enable && !domain->dirty_log_tracking) {
>>> +        ret = -EINVAL;
>>> +        goto out;
>>> +    }
>>> +
>>> +    ret = ops->switch_dirty_log(domain, enable, iova, size, prot);
>>> +    if (ret)
>>> +        goto out;
>>> +
>>> +    domain->dirty_log_tracking = enable;
>>> +out:
>>> +    mutex_unlock(&domain->switch_log_lock);
>>> +    return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(iommu_switch_dirty_log);
>>
>> Since you also added IOMMU_DEV_FEAT_HWDBM, I am wondering what's the
>> difference between
>>
>> iommu_switch_dirty_log(on) vs. iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)
>>
>> iommu_switch_dirty_log(off) vs. iommu_dev_disable_feature(IOMMU_DEV_FEAT_HWDBM)
> Indeed. As I can see, IOMMU_DEV_FEAT_AUX is not switchable, so enable/disable
> are not applicable for it. IOMMU_DEV_FEAT_SVA is switchable, so we can use these
> interfaces for it.
> 
> IOMMU_DEV_FEAT_HWDBM is used to indicate whether hardware supports HWDBM, so we should

Previously we had iommu_dev_has_feature() and then was cleaned up due to
lack of real users. If you have a real case for it, why not bringing it
back?

> design it as not switchable. I will modify the commit message of patch#12, thanks!

I am not sure that I fully get your point. But I can't see any gaps of
using iommu_dev_enable/disable_feature() to switch dirty log on and off.
Probably I missed anything.

> 
>>
>>> +
>>> +int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
>>> +             size_t size, unsigned long *bitmap,
>>> +             unsigned long base_iova, unsigned long bitmap_pgshift)
>>> +{
>>> +    const struct iommu_ops *ops = domain->ops;
>>> +    unsigned int min_pagesz;
>>> +    size_t pgsize;
>>> +    int ret = 0;
>>> +
>>> +    if (unlikely(!ops || !ops->sync_dirty_log))
>>> +        return -ENODEV;
>>> +
>>> +    min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
>>> +    if (!IS_ALIGNED(iova | size, min_pagesz)) {
>>> +        pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
>>> +               iova, size, min_pagesz);
>>> +        return -EINVAL;
>>> +    }
>>> +
>>> +    mutex_lock(&domain->switch_log_lock);
>>> +    if (!domain->dirty_log_tracking) {
>>> +        ret = -EINVAL;
>>> +        goto out;
>>> +    }
>>> +
>>> +    while (size) {
>>> +        pgsize = iommu_pgsize(domain, iova, size);
>>> +
>>> +        ret = ops->sync_dirty_log(domain, iova, pgsize,
>>> +                      bitmap, base_iova, bitmap_pgshift);
>>
>> Any reason why do you want to do this in a per-4K page manner? This can
>> lead to a lot of indirect calls and bad performance.
>>
>> How about a sync_dirty_pages()?
> The function name of iommu_pgsize() is a bit puzzling. Actually it will try to
> compute the max size that fit into size, so the pgsize can be a large page size
> even if the underlying mapping is 4K. The __iommu_unmap() also has a similar logic.

This series has some improvement on the iommu_pgsize() helper.

https://lore.kernel.org/linux-iommu/20210405191112.28192-1-isaacm at codeaurora.org/

Best regards,
baolu


From dinghao.liu at zju.edu.cn  Thu Apr 15 08:17:14 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Thu, 15 Apr 2021 15:17:14 +0800
Subject: [PATCH] [v3] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
Message-ID: <20210415071714.19334-1-dinghao.liu@zju.edu.cn>

There is a PM usage counter decrement after zynqmp_qspi_init_hw()
without any refcount increment, which leads to refcount leak.Add
a refcount increment to balance the refcount. Also set
auto_runtime_pm to resume suspended spi controller.

Fixes: 9e3a000362aec ("spi: zynqmp: Add pm runtime support")
Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---

Changelog:

v2: - Add a refcount increment to fix refcout leak instead of the
      refcount decrement on error.
      Set ctlr->auto_runtime_pm = true.

v3: - Add fix tag.
      Add a return value check against pm_runtime_get_sync().
      Move pm_runtime_{mark_last_busy & put_autosuspend} to the
      end of current function.
---
 drivers/spi/spi-zynqmp-gqspi.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..781ef3fc76e2 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1160,11 +1160,14 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
+
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0)
+		goto clk_dis_all;
+
 	/* QSPI controller initializations */
 	zynqmp_qspi_init_hw(xqspi);
 
-	pm_runtime_mark_last_busy(&pdev->dev);
-	pm_runtime_put_autosuspend(&pdev->dev);
 	xqspi->irq = platform_get_irq(pdev, 0);
 	if (xqspi->irq <= 0) {
 		ret = -ENXIO;
@@ -1187,6 +1190,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
 			    SPI_TX_DUAL | SPI_TX_QUAD;
 	ctlr->dev.of_node = np;
+	ctlr->auto_runtime_pm = true;
 
 	ret = devm_spi_register_controller(&pdev->dev, ctlr);
 	if (ret) {
@@ -1194,9 +1198,13 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_all;
 	}
 
+	pm_runtime_mark_last_busy(&pdev->dev);
+	pm_runtime_put_autosuspend(&pdev->dev);
+
 	return 0;
 
 clk_dis_all:
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	clk_disable_unprepare(xqspi->refclk);
-- 
2.17.1



From lars at metafoo.de  Thu Apr 15 08:26:01 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 15 Apr 2021 09:26:01 +0200
Subject: [RFC v2 PATCH 5/7] dmaengine: xilinx_dma: Freeup active list
 based on descriptor completion bit
In-Reply-To: <1617990965-35337-6-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-6-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <94a2a053-46b6-77be-7c1f-3ece3a0f9af3@metafoo.de>

On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
> AXIDMA IP in SG mode sets completion bit to 1 when the transfer is
> completed. Read this bit to move descriptor from active list to the
> done list. This feature is needed when interrupt delay timeout and
> IRQThreshold is enabled i.e Dly_IrqEn is triggered w/o completing
> interrupt threshold.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> - Check BD completion bit only for SG mode.
> - Modify the logic to have early return path.
> ---
>   drivers/dma/xilinx/xilinx_dma.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 890bf46b36e5..f2305a73cb91 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -177,6 +177,7 @@
>   #define XILINX_DMA_CR_COALESCE_SHIFT	16
>   #define XILINX_DMA_BD_SOP		BIT(27)
>   #define XILINX_DMA_BD_EOP		BIT(26)
> +#define XILINX_DMA_BD_COMP_MASK		BIT(31)
>   #define XILINX_DMA_COALESCE_MAX		255
>   #define XILINX_DMA_NUM_DESCS		512
>   #define XILINX_DMA_NUM_APP_WORDS	5
> @@ -1683,12 +1684,18 @@ static void xilinx_dma_issue_pending(struct dma_chan *dchan)
>   static void xilinx_dma_complete_descriptor(struct xilinx_dma_chan *chan)
>   {
>   	struct xilinx_dma_tx_descriptor *desc, *next;
> +	struct xilinx_axidma_tx_segment *seg;
>   
>   	/* This function was invoked with lock held */
>   	if (list_empty(&chan->active_list))
>   		return;
>   
>   	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
> +		/* TODO: remove hardcoding for axidma_tx_segment */
> +		seg = list_last_entry(&desc->segments,
> +				      struct xilinx_axidma_tx_segment, node);
> +		if (!(seg->hw.status & XILINX_DMA_BD_COMP_MASK) && chan->has_sg)
> +			break;
>   		if (chan->has_sg && chan->xdev->dma_config->dmatype !=
>   		    XDMA_TYPE_VDMA)
>   			desc->residue = xilinx_dma_get_residue(chan, desc);

Since not all descriptors will be completed in this function the 
`chan->idle = true;` in xilinx_dma_irq_handler() needs to be gated on 
the active_list being empty.

xilinx_dma_complete_descriptor



From eric.auger at redhat.com  Thu Apr 15 08:27:10 2021
From: eric.auger at redhat.com (Auger Eric)
Date: Thu, 15 Apr 2021 09:27:10 +0200
Subject: [RFC PATCH v2 1/8] ACPICA: IORT: Update for revision E
In-Reply-To: <20201119121150.3316-2-shameerali.kolothum.thodi@huawei.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
 <20201119121150.3316-2-shameerali.kolothum.thodi@huawei.com>
Message-ID: <da7b36fb-b30c-2d87-0934-7021d1093a1a@redhat.com>

Hi Shameer,

On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> IORT revision E contains a few additions like,
> ? ? -Added an identifier field in the node descriptors to aid table
> ? ? ?cross-referencing.
> ? ? -Introduced the Reserved Memory Range(RMR) node. This is used
>  ? ? to describe memory ranges that are used by endpoints and requires
>  ? ? a unity mapping in SMMU.
>     -Introduced a flag in the RC node to express support for PRI.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> ---
>  include/acpi/actbl2.h | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index ec66779cb193..274fce7b5c01 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -68,7 +68,7 @@
>   * IORT - IO Remapping Table
>   *
>   * Conforms to "IO Remapping Table System Software on ARM Platforms",
> - * Document number: ARM DEN 0049D, March 2018
> + * Document number: ARM DEN 0049E, June 2020
>   *
>   ******************************************************************************/
>  
> @@ -86,7 +86,8 @@ struct acpi_iort_node {
>  	u8 type;
>  	u16 length;
>  	u8 revision;
> -	u32 reserved;
> +	u16 reserved;
> +	u16 identifier;
>  	u32 mapping_count;
>  	u32 mapping_offset;
>  	char node_data[1];
> @@ -100,7 +101,8 @@ enum acpi_iort_node_type {
>  	ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
>  	ACPI_IORT_NODE_SMMU = 0x03,
>  	ACPI_IORT_NODE_SMMU_V3 = 0x04,
> -	ACPI_IORT_NODE_PMCG = 0x05
> +	ACPI_IORT_NODE_PMCG = 0x05,
> +	ACPI_IORT_NODE_RMR = 0x06,
>  };
>  
>  struct acpi_iort_id_mapping {
> @@ -167,10 +169,10 @@ struct acpi_iort_root_complex {
>  	u8 reserved[3];		/* Reserved, must be zero */
>  };
>  
> -/* Values for ats_attribute field above */
> +/* Masks for ats_attribute field above */
>  
> -#define ACPI_IORT_ATS_SUPPORTED         0x00000001	/* The root complex supports ATS */
> -#define ACPI_IORT_ATS_UNSUPPORTED       0x00000000	/* The root complex doesn't support ATS */
> +#define ACPI_IORT_ATS_SUPPORTED         (1)	/* The root complex supports ATS */
> +#define ACPI_IORT_PRI_SUPPORTED         (1<<1)	/* The root complex supports PRI */
>  
>  struct acpi_iort_smmu {
>  	u64 base_address;	/* SMMU base address */
> @@ -241,6 +243,17 @@ struct acpi_iort_pmcg {
>  	u64 page1_base_address;
>  };
>  
> +struct acpi_iort_rmr {
so indeed in E.b there is a new field here.
u32 flags
> +	u32 rmr_count;
> +	u32 rmr_offset;
> +};
> +
> +struct acpi_iort_rmr_desc {
> +	u64 base_address;
> +	u64 length;
> +	u32 reserved;
> +};
> +
>  /*******************************************************************************
>   *
>   * IVRS - I/O Virtualization Reporting Structure
> 
Thanks

Eric



From quanyang.wang at windriver.com  Thu Apr 15 08:27:51 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Thu, 15 Apr 2021 15:27:51 +0800
Subject: [PATCH] [v3] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210415071714.19334-1-dinghao.liu@zju.edu.cn>
References: <20210415071714.19334-1-dinghao.liu@zju.edu.cn>
Message-ID: <a9fd2d17-ff87-f4cb-e255-8023ff0bba8b@windriver.com>

Hi Dinghao,

On 4/15/21 3:17 PM, Dinghao Liu wrote:
> There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> without any refcount increment, which leads to refcount leak.Add
> a refcount increment to balance the refcount. Also set
> auto_runtime_pm to resume suspended spi controller.
>
> Fixes: 9e3a000362aec ("spi: zynqmp: Add pm runtime support")
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> ---
>
> Changelog:
>
> v2: - Add a refcount increment to fix refcout leak instead of the
>        refcount decrement on error.
>        Set ctlr->auto_runtime_pm = true.
>
> v3: - Add fix tag.
>        Add a return value check against pm_runtime_get_sync().
>        Move pm_runtime_{mark_last_busy & put_autosuspend} to the
>        end of current function.
> ---
>   drivers/spi/spi-zynqmp-gqspi.c | 12 ++++++++++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> index c8fa6ee18ae7..781ef3fc76e2 100644
> --- a/drivers/spi/spi-zynqmp-gqspi.c
> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -1160,11 +1160,14 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
>   	pm_runtime_set_active(&pdev->dev);
>   	pm_runtime_enable(&pdev->dev);
> +
> +	ret = pm_runtime_get_sync(&pdev->dev);
> +	if (ret < 0)
> +		goto clk_dis_all;

Would you please add some error info output here? Just like:

+?????? if (ret < 0) {
+?????????????? dev_err(&pdev->dev, "failed to pm_runtime_get_sync: 
%d\n", ret);
+?????????????? goto clk_dis_all;
+?????? }
Because sometimes it is very helpful to analyse probe failure.

Thanks,

Quanyang

> +
>   	/* QSPI controller initializations */
>   	zynqmp_qspi_init_hw(xqspi);
>   
> -	pm_runtime_mark_last_busy(&pdev->dev);
> -	pm_runtime_put_autosuspend(&pdev->dev);
>   	xqspi->irq = platform_get_irq(pdev, 0);
>   	if (xqspi->irq <= 0) {
>   		ret = -ENXIO;
> @@ -1187,6 +1190,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
>   			    SPI_TX_DUAL | SPI_TX_QUAD;
>   	ctlr->dev.of_node = np;
> +	ctlr->auto_runtime_pm = true;
>   
>   	ret = devm_spi_register_controller(&pdev->dev, ctlr);
>   	if (ret) {
> @@ -1194,9 +1198,13 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   		goto clk_dis_all;
>   	}
>   
> +	pm_runtime_mark_last_busy(&pdev->dev);
> +	pm_runtime_put_autosuspend(&pdev->dev);
> +
>   	return 0;
>   
>   clk_dis_all:
> +	pm_runtime_put_sync(&pdev->dev);
>   	pm_runtime_set_suspended(&pdev->dev);
>   	pm_runtime_disable(&pdev->dev);
>   	clk_disable_unprepare(xqspi->refclk);


From Claudiu.Beznea at microchip.com  Thu Apr 15 08:31:36 2021
From: Claudiu.Beznea at microchip.com (Claudiu.Beznea at microchip.com)
Date: Thu, 15 Apr 2021 07:31:36 +0000
Subject: [PATCH v2 16/24] dt-bindings: atmel-sysreg: add bindings for
 sama7g5
In-Reply-To: <20210412160216.GA3970458@robh.at.kernel.org>
References: <20210409111345.294472-1-claudiu.beznea@microchip.com>
 <20210409111345.294472-17-claudiu.beznea@microchip.com>
 <20210412160216.GA3970458@robh.at.kernel.org>
Message-ID: <11fa6a06-7498-bff3-2b40-3c5eb908f7a5@microchip.com>

On 12.04.2021 19:02, Rob Herring wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Apr 09, 2021 at 02:13:37PM +0300, Claudiu Beznea wrote:
>> Add RAM controller and RAM PHY controller DT bindings.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
>> ---
>>  .../devicetree/bindings/arm/atmel-sysregs.txt     | 15 ++++++++++++++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
>> index 807264a78edc..7cd55a760d41 100644
>> --- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
>> +++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
>> @@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties:
>>                       "atmel,at91sam9260-sdramc",
>>                       "atmel,at91sam9g45-ddramc",
>>                       "atmel,sama5d3-ddramc",
>> -                     "microchip,sam9x60-ddramc"
>> +                     "microchip,sam9x60-ddramc",
>> +                     "microchip,sama7g5-uddrc"
>>  - reg: Should contain registers location and length
>>
>>  Examples:
>> @@ -55,6 +56,18 @@ Examples:
>>               reg = <0xffffe800 0x200>;
>>       };
>>
>> +RAMC PHY Controller required properties:
>> +- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
>> +- reg: Should contain registers location and length
>> +
>> +Example:
>> +
>> +     ddr3phy: ddr3phy at e3804000 {
>> +             compatible = "microchip,sama7g5-ddr3phy", "syscon";
>> +             reg = <0xe3804000 0x1000>;
>> +             status = "okay";
> 
> Really need an example for this? If so, drop 'status'.

The self-refresh code needs the address for this, this is why I've added
it. The status is not needed so, as you suggested, I will remove it.

Thank you,
Claudiu

> 
>> +};
>> +
>>  SHDWC Shutdown Controller
>>
>>  required properties:
>> --
>> 2.25.1
>>


From lars at metafoo.de  Thu Apr 15 08:33:17 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 15 Apr 2021 09:33:17 +0200
Subject: [RFC v2 PATCH 7/7] dmaengine: xilinx_dma: Program interrupt delay
 timeout
In-Reply-To: <1617990965-35337-8-git-send-email-radhey.shyam.pandey@xilinx.com>
References: <1617990965-35337-1-git-send-email-radhey.shyam.pandey@xilinx.com>
 <1617990965-35337-8-git-send-email-radhey.shyam.pandey@xilinx.com>
Message-ID: <2985f8ac-ae2c-c142-f2d6-c5051bd6bfb2@metafoo.de>

On 4/9/21 7:56 PM, Radhey Shyam Pandey wrote:
> Program IRQDelay for AXI DMA. The interrupt timeout mechanism causes
> the DMA engine to generate an interrupt after the delay time period
> has expired. It enables dmaengine to respond in real-time even though
> interrupt coalescing is configured. It also remove the placeholder
> for delay interrupt and merge it with frame completion interrupt.
> Since by default interrupt delay timeout is disabled this feature
> addition has no functional impact on VDMA and CDMA IP's.

In my opinion this should not come from the devicetree. This setting is 
application specific and should be configured through a runtime API.

For the VDMA there is already xilinx_vdma_channel_set_config() which 
allows to configure the maximum number of IRQs that can be coalesced and 
the IRQ delay. Something similar is probably needed for the AXIDMA.

>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey at xilinx.com>
> ---
> Changes for v2:
> - Read irq delay timeout value from DT.
> - Merge interrupt processing for frame done and delay interrupt.
> ---
>   drivers/dma/xilinx/xilinx_dma.c | 20 +++++++++++---------
>   1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index a2ea2d649332..0c0dc9882a01 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -173,8 +173,10 @@
>   #define XILINX_DMA_MAX_TRANS_LEN_MAX	23
>   #define XILINX_DMA_V2_MAX_TRANS_LEN_MAX	26
>   #define XILINX_DMA_CR_COALESCE_MAX	GENMASK(23, 16)
> +#define XILINX_DMA_CR_DELAY_MAX		GENMASK(31, 24)
>   #define XILINX_DMA_CR_CYCLIC_BD_EN_MASK	BIT(4)
>   #define XILINX_DMA_CR_COALESCE_SHIFT	16
> +#define XILINX_DMA_CR_DELAY_SHIFT	24
>   #define XILINX_DMA_BD_SOP		BIT(27)
>   #define XILINX_DMA_BD_EOP		BIT(26)
>   #define XILINX_DMA_BD_COMP_MASK		BIT(31)
> @@ -410,6 +412,7 @@ struct xilinx_dma_tx_descriptor {
>    * @stop_transfer: Differentiate b/w DMA IP's quiesce
>    * @tdest: TDEST value for mcdma
>    * @has_vflip: S2MM vertical flip
> + * @irq_delay: Interrupt delay timeout
>    */
>   struct xilinx_dma_chan {
>   	struct xilinx_dma_device *xdev;
> @@ -447,6 +450,7 @@ struct xilinx_dma_chan {
>   	int (*stop_transfer)(struct xilinx_dma_chan *chan);
>   	u16 tdest;
>   	bool has_vflip;
> +	u8 irq_delay;
>   };
>   
>   /**
> @@ -1555,6 +1559,9 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
>   	if (chan->has_sg)
>   		xilinx_write(chan, XILINX_DMA_REG_CURDESC,
>   			     head_desc->async_tx.phys);
> +	reg  &= ~XILINX_DMA_CR_DELAY_MAX;
> +	reg  |= chan->irq_delay << XILINX_DMA_CR_DELAY_SHIFT;
> +	dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
>   
>   	xilinx_dma_start(chan);
>   
> @@ -1877,15 +1884,8 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
>   		}
>   	}
>   
> -	if (status & XILINX_DMA_DMASR_DLY_CNT_IRQ) {
> -		/*
> -		 * Device takes too long to do the transfer when user requires
> -		 * responsiveness.
> -		 */
> -		dev_dbg(chan->dev, "Inter-packet latency too long\n");
> -	}
> -
> -	if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
> +	if (status & (XILINX_DMA_DMASR_FRM_CNT_IRQ |
> +		      XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
>   		spin_lock(&chan->lock);
>   		xilinx_dma_complete_descriptor(chan);
>   		chan->idle = true;
> @@ -2802,6 +2802,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
>   	/* Retrieve the channel properties from the device tree */
>   	has_dre = of_property_read_bool(node, "xlnx,include-dre");
>   
> +	of_property_read_u8(node, "xlnx,irq-delay", &chan->irq_delay);
> +
>   	chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
>   
>   	err = of_property_read_u32(node, "xlnx,datawidth", &value);




From zhukeqian1 at huawei.com  Thu Apr 15 08:43:08 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 15:43:08 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
 <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
 <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>
Message-ID: <88cba608-2f22-eb83-f22e-50cb547b6ee8@huawei.com>



On 2021/4/15 15:03, Lu Baolu wrote:
> On 4/15/21 2:18 PM, Keqian Zhu wrote:
>> Hi Baolu,
>>
>> Thanks for the review!
>>
>> On 2021/4/14 15:00, Lu Baolu wrote:
>>> Hi Keqian,
>>>
>>> On 4/13/21 4:54 PM, Keqian Zhu wrote:
>>>> Some types of IOMMU are capable of tracking DMA dirty log, such as
>>>> ARM SMMU with HTTU or Intel IOMMU with SLADE. This introduces the
>>>> dirty log tracking framework in the IOMMU base layer.
>>>>
>>>> Three new essential interfaces are added, and we maintaince the status
>>>> of dirty log tracking in iommu_domain.
>>>> 1. iommu_switch_dirty_log: Perform actions to start|stop dirty log tracking
>>>> 2. iommu_sync_dirty_log: Sync dirty log from IOMMU into a dirty bitmap
>>>> 3. iommu_clear_dirty_log: Clear dirty log of IOMMU by a mask bitmap
>>>>
>>>> A new dev feature are added to indicate whether a specific type of
>>>> iommu hardware supports and its driver realizes them.
>>>>
>>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>>> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
>>>> ---
>>>>    drivers/iommu/iommu.c | 150 ++++++++++++++++++++++++++++++++++++++++++
>>>>    include/linux/iommu.h |  53 +++++++++++++++
>>>>    2 files changed, 203 insertions(+)
>>>>
>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>> index d0b0a15dba84..667b2d6d2fc0 100644
>>>> --- a/drivers/iommu/iommu.c
>>>> +++ b/drivers/iommu/iommu.c
>>>> @@ -1922,6 +1922,7 @@ static struct iommu_domain *__iommu_domain_alloc(struct bus_type *bus,
>>>>        domain->type = type;
>>>>        /* Assume all sizes by default; the driver may override this later */
>>>>        domain->pgsize_bitmap  = bus->iommu_ops->pgsize_bitmap;
>>>> +    mutex_init(&domain->switch_log_lock);
>>>>          return domain;
>>>>    }
>>>> @@ -2720,6 +2721,155 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>>>>    +int iommu_switch_dirty_log(struct iommu_domain *domain, bool enable,
>>>> +               unsigned long iova, size_t size, int prot)
>>>> +{
>>>> +    const struct iommu_ops *ops = domain->ops;
>>>> +    int ret;
>>>> +
>>>> +    if (unlikely(!ops || !ops->switch_dirty_log))
>>>> +        return -ENODEV;
>>>> +
>>>> +    mutex_lock(&domain->switch_log_lock);
>>>> +    if (enable && domain->dirty_log_tracking) {
>>>> +        ret = -EBUSY;
>>>> +        goto out;
>>>> +    } else if (!enable && !domain->dirty_log_tracking) {
>>>> +        ret = -EINVAL;
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    ret = ops->switch_dirty_log(domain, enable, iova, size, prot);
>>>> +    if (ret)
>>>> +        goto out;
>>>> +
>>>> +    domain->dirty_log_tracking = enable;
>>>> +out:
>>>> +    mutex_unlock(&domain->switch_log_lock);
>>>> +    return ret;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(iommu_switch_dirty_log);
>>>
>>> Since you also added IOMMU_DEV_FEAT_HWDBM, I am wondering what's the
>>> difference between
>>>
>>> iommu_switch_dirty_log(on) vs. iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)
>>>
>>> iommu_switch_dirty_log(off) vs. iommu_dev_disable_feature(IOMMU_DEV_FEAT_HWDBM)
>> Indeed. As I can see, IOMMU_DEV_FEAT_AUX is not switchable, so enable/disable
>> are not applicable for it. IOMMU_DEV_FEAT_SVA is switchable, so we can use these
>> interfaces for it.
>>
>> IOMMU_DEV_FEAT_HWDBM is used to indicate whether hardware supports HWDBM, so we should
> 
> Previously we had iommu_dev_has_feature() and then was cleaned up due to
> lack of real users. If you have a real case for it, why not bringing it
> back?
Yep, good suggestion.

> 
>> design it as not switchable. I will modify the commit message of patch#12, thanks!
> 
> I am not sure that I fully get your point. But I can't see any gaps of
> using iommu_dev_enable/disable_feature() to switch dirty log on and off.
> Probably I missed anything.
IOMMU_DEV_FEAT_HWDBM just tells user whether underlying IOMMU driver supports
dirty tracking, it is not used to management the status of dirty log tracking.

The feature reporting is per device, but the status management is per iommu_domain.
Only when all devices in a domain support HWDBM, we can start dirty log for the domain.

And I think we'd better not mix the feature reporting and status management. Thoughts?

> 
>>
>>>
>>>> +
>>>> +int iommu_sync_dirty_log(struct iommu_domain *domain, unsigned long iova,
>>>> +             size_t size, unsigned long *bitmap,
>>>> +             unsigned long base_iova, unsigned long bitmap_pgshift)
>>>> +{
>>>> +    const struct iommu_ops *ops = domain->ops;
>>>> +    unsigned int min_pagesz;
>>>> +    size_t pgsize;
>>>> +    int ret = 0;
>>>> +
>>>> +    if (unlikely(!ops || !ops->sync_dirty_log))
>>>> +        return -ENODEV;
>>>> +
>>>> +    min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
>>>> +    if (!IS_ALIGNED(iova | size, min_pagesz)) {
>>>> +        pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
>>>> +               iova, size, min_pagesz);
>>>> +        return -EINVAL;
>>>> +    }
>>>> +
>>>> +    mutex_lock(&domain->switch_log_lock);
>>>> +    if (!domain->dirty_log_tracking) {
>>>> +        ret = -EINVAL;
>>>> +        goto out;
>>>> +    }
>>>> +
>>>> +    while (size) {
>>>> +        pgsize = iommu_pgsize(domain, iova, size);
>>>> +
>>>> +        ret = ops->sync_dirty_log(domain, iova, pgsize,
>>>> +                      bitmap, base_iova, bitmap_pgshift);
>>>
>>> Any reason why do you want to do this in a per-4K page manner? This can
>>> lead to a lot of indirect calls and bad performance.
>>>
>>> How about a sync_dirty_pages()?
>> The function name of iommu_pgsize() is a bit puzzling. Actually it will try to
>> compute the max size that fit into size, so the pgsize can be a large page size
>> even if the underlying mapping is 4K. The __iommu_unmap() also has a similar logic.
> 
> This series has some improvement on the iommu_pgsize() helper.
> 
> https://lore.kernel.org/linux-iommu/20210405191112.28192-1-isaacm at codeaurora.org/
OK, I get your idea. I will look into that, thanks!

BRs,
Keqian


From dinghao.liu at zju.edu.cn  Thu Apr 15 08:46:44 2021
From: dinghao.liu at zju.edu.cn (Dinghao Liu)
Date: Thu, 15 Apr 2021 15:46:44 +0800
Subject: [PATCH] [v4] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
Message-ID: <20210415074644.24646-1-dinghao.liu@zju.edu.cn>

There is a PM usage counter decrement after zynqmp_qspi_init_hw()
without any refcount increment, which leads to refcount leak.Add
a refcount increment to balance the refcount. Also set
auto_runtime_pm to resume suspended spi controller.

Fixes: 9e3a000362aec ("spi: zynqmp: Add pm runtime support")
Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
---

Changelog:

v2: - Add a refcount increment to fix refcout leak instead of the
      refcount decrement on error.
      Set ctlr->auto_runtime_pm = true.

v3: - Add fix tag.
      Add a return value check against pm_runtime_get_sync().
      Move pm_runtime_{mark_last_busy & put_autosuspend} to the
      end of current function.

v4: - Add error message on failure of pm_runtime_get_sync().
---
 drivers/spi/spi-zynqmp-gqspi.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index c8fa6ee18ae7..38f3ddd3ea7c 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1160,11 +1160,16 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
 	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
+
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to pm_runtime_get_sync: %d\n", ret);
+		goto clk_dis_all;
+	}
+
 	/* QSPI controller initializations */
 	zynqmp_qspi_init_hw(xqspi);
 
-	pm_runtime_mark_last_busy(&pdev->dev);
-	pm_runtime_put_autosuspend(&pdev->dev);
 	xqspi->irq = platform_get_irq(pdev, 0);
 	if (xqspi->irq <= 0) {
 		ret = -ENXIO;
@@ -1187,6 +1192,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
 			    SPI_TX_DUAL | SPI_TX_QUAD;
 	ctlr->dev.of_node = np;
+	ctlr->auto_runtime_pm = true;
 
 	ret = devm_spi_register_controller(&pdev->dev, ctlr);
 	if (ret) {
@@ -1194,9 +1200,13 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_all;
 	}
 
+	pm_runtime_mark_last_busy(&pdev->dev);
+	pm_runtime_put_autosuspend(&pdev->dev);
+
 	return 0;
 
 clk_dis_all:
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	clk_disable_unprepare(xqspi->refclk);
-- 
2.17.1



From matthias.bgg at gmail.com  Thu Apr 15 08:47:25 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 15 Apr 2021 09:47:25 +0200
Subject: [PATCH 3/3] arm64: dts: mt8183-kukui: fix dtbs_check warnings
In-Reply-To: <CANMq1KAxZ+QiRR7LgR22pvhs4us=ne_VtSM-S_byCC0N__6BZA@mail.gmail.com>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
 <20210414144643.17435-3-matthias.bgg@kernel.org>
 <CANMq1KAxZ+QiRR7LgR22pvhs4us=ne_VtSM-S_byCC0N__6BZA@mail.gmail.com>
Message-ID: <d87f20bd-2195-663b-dd0b-ea1fa2f28a46@gmail.com>

Hi Nicolas,

On 15/04/2021 02:29, Nicolas Boichat wrote:
> On Wed, Apr 14, 2021 at 10:46 PM <matthias.bgg at kernel.org> wrote:
>>
>> From: Matthias Brugger <matthias.bgg at gmail.com>
>>
>> The dsi children don't have any reg property,
> 
> Confused, see below.
> 
>> so we don't need address and
>> size cells. This makes dtbs_check happy.
>>
>> CC: Hsin-Yi Wang <hsinyi at chromium.org>
>> CC: Enric Balletbo i Serra <enric.balletbo at collabora.com>
>> CC: Nicolas Boichat <drinkcat at chromium.org>
>> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
>>
>> ---
>>
>>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>> index ff56bcfa3370..f4dca6a33168 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>> @@ -251,8 +251,7 @@ &cpu7 {
>>
>>  &dsi0 {
>>         status = "okay";
>> -       #address-cells = <1>;
>> -       #size-cells = <0>;
>> +
>>         panel: panel at 0 {
>>                 /* compatible will be set in board dts */
>>                 reg = <0>;
> 
> ^^ isn't that... a reg property?
> 

Yes, that's my fault. I'm not quite sure why we would need this reg property. In
any case also we have it present "dtbs_check W=1" throws the following warning:
mediatek/mt8183.dtsi:1234.22-1246.5: Warning (avoid_unnecessary_addr_size):
/soc/dsi at 14014000: unnecessary #address-cells/#size-cells without "ranges" or
child "reg" property


Can you have a look at that?

Regards,
Matthias

>> --
>> 2.30.2
>>


From maxime at cerno.tech  Thu Apr 15 09:08:35 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 15 Apr 2021 10:08:35 +0200
Subject: [PATCH v4 0/5] add devicetree for Forlinx FETA40i-C & OKA40i-C
In-Reply-To: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
References: <20210407111428.3755684-1-i.uvarov@cognitivepilot.com>
Message-ID: <20210415080835.qieyynhxcwtx6vyj@gilmour>

On Wed, Apr 07, 2021 at 02:14:23PM +0300, Ivan Uvarov wrote:
> This patch series adds devicetree support for the Forlinx FETA40i-C SoM
> and OKA40i-C carrier board/devboard.
> 
> The FETA40i-C is an "industrial/automotive" SoM by Forlinx.
> 
> SoM specs:
> - SoC: R40 or A40i
> - PMIC: AXP221S
> - RAM: 1GiB/2GiB DDR3 (dual-rank)
> - eMMC: 8GB,
> - Mates with carrier board via four 80-pin connectors (AXK6F80337YG).
> 
> OKA40i-C is a carrier board by the same manufacturer for this SoM,
> whose main purpose is as a development board with a variety of
> peripherals:
> 
> - Power: DC5V barrel or USB OTG or 4.2V Lipo battery
> - Video out: HDMI, TV out, LVDS
> - WiFi+Bluetooth: RL-UM02WBS-8723BU-V1.2 (802.11 b/g/n, BT V2.1/3.0/4.0)
> - Ethernet: 10/100Mbps
> - Storage: ?SD, fullsize SD, eMMC (on SoM), SATA
> - USB: 3 x USB2.0 Host (2 via hub, 1 native), 1 x USB2.0 OTG (micro-B)
> - UART: RS232, RS485, 4 3.3v uarts (of which 2 have RTS/CTS)
> - Other I/O: SPI x2, TWI, SDIO header, GPIO header, JTAG header
> - Mini PCIe slot with sim holder for WLAN modem
> - Smart card holder
> - RTC (RX8010SJ)
> - Two user LEDs
> - Three user buttons (via KeyADC).
> 
> Of the board features listed above, support for the following has *NOT*
> been tested:
> - TV out & LVDS
> - SATA
> - Smart cards
> - KeyADC buttons (no support)
> 
> The series consists of five patches, with dependencies as follows:
> 
> * Patch 4 depends on patch 3;
> * Patch 5 depends on patches 2&4.
> 
> The rest are independent, however patch 2 may refuse to apply
> without patch 1.
> 
> Signed-off-by: Ivan Uvarov <i.uvarov at cognitivepilot.com>

Applied, 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/20210415/a98ca6fd/attachment.sig>

From yangyicong at hisilicon.com  Thu Apr 15 09:18:15 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Thu, 15 Apr 2021 16:18:15 +0800
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
Message-ID: <21d833f0-b1b8-9732-21c7-3a73676e07d3@hisilicon.com>

On 2021/4/15 2:06, Geert Uytterhoeven wrote:
> Hi Yicong,
> 
> On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
>> On 2021/4/13 20:26, Geert Uytterhoeven wrote:
>>> The HiSilicon Kunpeng I2C controller is only present on HiSilicon
>>> Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
>>> Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
>>> about this driver when configuring a kernel without Hisilicon platform
>>> or ACPI firmware support.
>>
>> this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
>> not sure all the platform this IP on has ARCH_HISI configured. The driver
>> will not be compiled by default config. This is not correct to have
>> this dependence.
> 
> Thanks for your answer!
> 
> I guess it's still fine to add a dependency on ACPI?

yes. currently we only use this driver through ACPI. So at least
for this driver, it make sense to keep the dependency.

> 
> Thanks again!
> 
>>> Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>> ---
>>>  drivers/i2c/busses/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>>> index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
>>> --- a/drivers/i2c/busses/Kconfig
>>> +++ b/drivers/i2c/busses/Kconfig
>>> @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
>>>
>>>  config I2C_HISI
>>>       tristate "HiSilicon I2C controller"
>>> -     depends on ARM64 || COMPILE_TEST
>>> +     depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
>>>       help
>>>         Say Y here if you want to have Hisilicon I2C controller support
>>>         available on the Kunpeng Server.
> \
> Gr{oetje,eeting}s,
> 
>                         Geert
> 



From quanyang.wang at windriver.com  Thu Apr 15 09:19:27 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Thu, 15 Apr 2021 16:19:27 +0800
Subject: [PATCH] [v4] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210415074644.24646-1-dinghao.liu@zju.edu.cn>
References: <20210415074644.24646-1-dinghao.liu@zju.edu.cn>
Message-ID: <59f9e657-37e8-a91a-08a9-d2bdb734d9cd@windriver.com>


On 4/15/21 3:46 PM, Dinghao Liu wrote:
> There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> without any refcount increment, which leads to refcount leak.Add
> a refcount increment to balance the refcount. Also set
> auto_runtime_pm to resume suspended spi controller.
>
> Fixes: 9e3a000362aec ("spi: zynqmp: Add pm runtime support")
> Signed-off-by: Dinghao Liu <dinghao.liu at zju.edu.cn>
> ---
>
> Changelog:
>
> v2: - Add a refcount increment to fix refcout leak instead of the
>        refcount decrement on error.
>        Set ctlr->auto_runtime_pm = true.
>
> v3: - Add fix tag.
>        Add a return value check against pm_runtime_get_sync().
>        Move pm_runtime_{mark_last_busy & put_autosuspend} to the
>        end of current function.
>
> v4: - Add error message on failure of pm_runtime_get_sync().
> ---
>   drivers/spi/spi-zynqmp-gqspi.c | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
> index c8fa6ee18ae7..38f3ddd3ea7c 100644
> --- a/drivers/spi/spi-zynqmp-gqspi.c
> +++ b/drivers/spi/spi-zynqmp-gqspi.c
> @@ -1160,11 +1160,16 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   	pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
>   	pm_runtime_set_active(&pdev->dev);
>   	pm_runtime_enable(&pdev->dev);
> +
> +	ret = pm_runtime_get_sync(&pdev->dev);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to pm_runtime_get_sync: %d\n", ret);
> +		goto clk_dis_all;
> +	}
> +
>   	/* QSPI controller initializations */
>   	zynqmp_qspi_init_hw(xqspi);
>   
> -	pm_runtime_mark_last_busy(&pdev->dev);
> -	pm_runtime_put_autosuspend(&pdev->dev);
>   	xqspi->irq = platform_get_irq(pdev, 0);
>   	if (xqspi->irq <= 0) {
>   		ret = -ENXIO;
> @@ -1187,6 +1192,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_RX_DUAL | SPI_RX_QUAD |
>   			    SPI_TX_DUAL | SPI_TX_QUAD;
>   	ctlr->dev.of_node = np;
> +	ctlr->auto_runtime_pm = true;
>   
>   	ret = devm_spi_register_controller(&pdev->dev, ctlr);
>   	if (ret) {
> @@ -1194,9 +1200,13 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
>   		goto clk_dis_all;
>   	}
>   
> +	pm_runtime_mark_last_busy(&pdev->dev);
> +	pm_runtime_put_autosuspend(&pdev->dev);
> +
>   	return 0;
>   
>   clk_dis_all:
> +	pm_runtime_put_sync(&pdev->dev);
>   	pm_runtime_set_suspended(&pdev->dev);
>   	pm_runtime_disable(&pdev->dev);
>   	clk_disable_unprepare(xqspi->refclk);

Test this patch at zcu102 board:

root at xilinx-zynqmp:~# dmesg | grep domain2
[??? 0.905407] zynqmp_gpd_attach_dev() ff0f0000.spi attached to domain2 
domain
[??? 0.912390] zynqmp_gpd_power_on() Powered on domain2 domain
[??? 4.350331] zynqmp_gpd_power_off() Powered off domain2 domain
root at xilinx-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 4 Kibyte @ 0 --? 0 % complete [? 153.125894] 
zynqmp_gpd_power_on() Powered on domain2 domain
Erasing 4 Kibyte @ 2e8000 -- 49 % complete [? 156.134884] 
zynqmp_gpd_power_off() Powered off domain2 domain
[? 156.142648] zynqmp_gpd_power_on() Powered on domain2 domain
Erasing 4 Kibyte @ 5d5000 -- 99 % complete [? 159.148329] 
zynqmp_gpd_power_off() Powered off domain2 domain
[? 159.154579] zynqmp_gpd_power_on() Powered on domain2 domain
Erasing 4 Kibyte @ 5df000 -- 100 % complete
root at xilinx-zynqmp:~# [? 162.910329] zynqmp_gpd_power_off() Powered off 
domain2 domain

pm_runtime works now. So

Tested-by: Quanyang Wang <quanyang.wang at windriver.com>

Regards,

Quanyang



From jiapeng.chong at linux.alibaba.com  Thu Apr 15 09:34:23 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Thu, 15 Apr 2021 16:34:23 +0800
Subject: [PATCH] soc: fsl: qe: remove unused function
Message-ID: <1618475663-100748-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following clang warning:

drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
'qe_ic_from_irq' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/soc/fsl/qe/qe_ic.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 0390af9..b573712 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32  __iomem *base, unsigned int reg,
 	qe_iowrite32be(value, base + (reg >> 2));
 }
 
-static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
-{
-	return irq_get_chip_data(virq);
-}
-
 static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
 {
 	return irq_data_get_irq_chip_data(d);
-- 
1.8.3.1



From jiapeng.chong at linux.alibaba.com  Thu Apr 15 09:35:53 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Thu, 15 Apr 2021 16:35:53 +0800
Subject: [PATCH] pwm: mediatek: remove unused function
Message-ID: <1618475753-102123-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following clang warning:

drivers/pwm/pwm-mediatek.c:110:19: warning: unused function
'pwm_mediatek_readl' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/pwm/pwm-mediatek.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index fcfc3b1..cae0f48 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -107,12 +107,6 @@ static void pwm_mediatek_clk_disable(struct pwm_chip *chip,
 	clk_disable_unprepare(pc->clk_top);
 }
 
-static inline u32 pwm_mediatek_readl(struct pwm_mediatek_chip *chip,
-				     unsigned int num, unsigned int offset)
-{
-	return readl(chip->regs + pwm_mediatek_reg_offset[num] + offset);
-}
-
 static inline void pwm_mediatek_writel(struct pwm_mediatek_chip *chip,
 				       unsigned int num, unsigned int offset,
 				       u32 value)
-- 
1.8.3.1



From pali at kernel.org  Thu Apr 15 09:36:40 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Thu, 15 Apr 2021 10:36:40 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
Message-ID: <20210415083640.ntg6kv6ayppxldgd@pali>

On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
> >
> > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > function and allow to build it as module") PCIe controller driver for
> > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > allows dynamic binding and unbinding of PCIe controller device.
> >
> > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > number (starting from zero) for this PCIe controller every time when device
> > is bound. So PCI domain changes after every unbind / bind operation.
> 
> PCI host bridges as a module are relatively new, so seems likely a bug to me.

Why a bug? It is there since 5.10 and it is working.

> > Alternative way for assigning PCI domain number is to use static allocated
> > numbers defined in Device Tree. This option has requirement that every PCI
> > controller in system must have defined PCI bus number in Device Tree.
> 
> That seems entirely pointless from a DT point of view with a single PCI bridge.

If domain id is not specified in DT then kernel uses counter and assigns
counter++. So it is not pointless if we want to have stable domain id.

> > Armada 37xx has only one PCIe controller, so assign for it PCI domain 0 in
> > Device Tree.
> >
> > After this change PCI domain on Armada 37xx is always zero, even after
> > repeated unbind and bind operations.
> >
> > Signed-off-by: Pali Roh?r <pali at kernel.org>
> > Fixes: 526a76991b7b ("PCI: aardvark: Implement driver 'remove' function and allow to build it as module")
> > ---
> >  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> > index 7a2df148c6a3..f02058ef5364 100644
> > --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> > +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> > @@ -495,6 +495,7 @@
> >                                         <0 0 0 2 &pcie_intc 1>,
> >                                         <0 0 0 3 &pcie_intc 2>,
> >                                         <0 0 0 4 &pcie_intc 3>;
> > +                       linux,pci-domain = <0>;
> >                         max-link-speed = <2>;
> >                         phys = <&comphy1 0>;
> >                         pcie_intc: interrupt-controller {
> > --
> > 2.20.1
> >


From colin.king at canonical.com  Thu Apr 15 09:37:57 2021
From: colin.king at canonical.com (Colin King)
Date: Thu, 15 Apr 2021 09:37:57 +0100
Subject: [PATCH][next] net: stmmac: replace redundant comparison with true
Message-ID: <20210415083757.1807538-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The comparison of the u32 variable queue with <= zero is always true
since an unsigned can never be negative. Replace the conditional
check with the boolean true to simplify the code.  The while loop
will terminate because of the zero check on queue before queue is
decremented.

Addresses-Coverity: ("Unsigned compared against 0")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index e3e22200a4fd..6e5b4c4b375c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1673,7 +1673,7 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
 	return;
 
 err_reinit_rx_buffers:
-	while (queue >= 0) {
+	while (true) {
 		dma_free_rx_skbufs(priv, queue);
 
 		if (queue == 0)
@@ -1781,7 +1781,7 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
 	return 0;
 
 err_init_rx_buffers:
-	while (queue >= 0) {
+	while (true) {
 		struct stmmac_rx_queue *rx_q = &priv->rx_queue[queue];
 
 		if (rx_q->xsk_pool)
-- 
2.30.2



From enric.balletbo at collabora.com  Thu Apr 15 09:37:59 2021
From: enric.balletbo at collabora.com (Enric Balletbo i Serra)
Date: Thu, 15 Apr 2021 10:37:59 +0200
Subject: [PATCH 3/3] arm64: dts: mt8183-kukui: fix dtbs_check warnings
In-Reply-To: <d87f20bd-2195-663b-dd0b-ea1fa2f28a46@gmail.com>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
 <20210414144643.17435-3-matthias.bgg@kernel.org>
 <CANMq1KAxZ+QiRR7LgR22pvhs4us=ne_VtSM-S_byCC0N__6BZA@mail.gmail.com>
 <d87f20bd-2195-663b-dd0b-ea1fa2f28a46@gmail.com>
Message-ID: <82fdfa6e-9c4d-7146-fd90-353e350159c2@collabora.com>

Hi Matthias,

On 15/4/21 9:47, Matthias Brugger wrote:
> Hi Nicolas,
> 
> On 15/04/2021 02:29, Nicolas Boichat wrote:
>> On Wed, Apr 14, 2021 at 10:46 PM <matthias.bgg at kernel.org> wrote:
>>>
>>> From: Matthias Brugger <matthias.bgg at gmail.com>
>>>
>>> The dsi children don't have any reg property,
>>
>> Confused, see below.
>>
>>> so we don't need address and
>>> size cells. This makes dtbs_check happy.
>>>
>>> CC: Hsin-Yi Wang <hsinyi at chromium.org>
>>> CC: Enric Balletbo i Serra <enric.balletbo at collabora.com>
>>> CC: Nicolas Boichat <drinkcat at chromium.org>
>>> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
>>>
>>> ---
>>>
>>>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> index ff56bcfa3370..f4dca6a33168 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> @@ -251,8 +251,7 @@ &cpu7 {
>>>
>>>  &dsi0 {
>>>         status = "okay";
>>> -       #address-cells = <1>;
>>> -       #size-cells = <0>;
>>> +
>>>         panel: panel at 0 {
>>>                 /* compatible will be set in board dts */
>>>                 reg = <0>;
>>
>> ^^ isn't that... a reg property?
>>
> 
> Yes, that's my fault. I'm not quite sure why we would need this reg property. In
> any case also we have it present "dtbs_check W=1" throws the following warning:
> mediatek/mt8183.dtsi:1234.22-1246.5: Warning (avoid_unnecessary_addr_size):
> /soc/dsi at 14014000: unnecessary #address-cells/#size-cells without "ranges" or
> child "reg" property
> 
> 
> Can you have a look at that?
> 

I think it is needed reg. See at
Documentation/devicetree/bindings/display/dsi-controller.yaml

Regards,
Enric

> Regards,
> Matthias
> 
>>> --
>>> 2.30.2
>>>


From marek.behun at nic.cz  Thu Apr 15 09:45:37 2021
From: marek.behun at nic.cz (Marek Behun)
Date: Thu, 15 Apr 2021 10:45:37 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <20210415083640.ntg6kv6ayppxldgd@pali>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali>
Message-ID: <20210415104537.403de52e@thinkpad>

On Thu, 15 Apr 2021 10:36:40 +0200
Pali Roh?r <pali at kernel.org> wrote:

> On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:  
> > >
> > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > function and allow to build it as module") PCIe controller driver for
> > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > > allows dynamic binding and unbinding of PCIe controller device.
> > >
> > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > number (starting from zero) for this PCIe controller every time when device
> > > is bound. So PCI domain changes after every unbind / bind operation.  
> > 
> > PCI host bridges as a module are relatively new, so seems likely a bug to me.  
> 
> Why a bug? It is there since 5.10 and it is working.
> 
> > > Alternative way for assigning PCI domain number is to use static allocated
> > > numbers defined in Device Tree. This option has requirement that every PCI
> > > controller in system must have defined PCI bus number in Device Tree.  
> > 
> > That seems entirely pointless from a DT point of view with a single PCI bridge.  
> 
> If domain id is not specified in DT then kernel uses counter and assigns
> counter++. So it is not pointless if we want to have stable domain id.

What Rob is trying to say is that
- the bug is that kernel assigns counter++
- device-tree should not be used to fix problems with how kernel does
  things
- if a device has only one PCIe controller, it is pointless to define
  it's pci-domain. If there were multiple controllers, then it would
  make sense, but there is only one


From jiapeng.chong at linux.alibaba.com  Thu Apr 15 09:47:01 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Thu, 15 Apr 2021 16:47:01 +0800
Subject: [PATCH] drm/rockchip: remove unused function
Message-ID: <1618476421-114429-1-git-send-email-jiapeng.chong@linux.alibaba.com>

Fix the following clang warning:

drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:320:20: warning: unused
function 'dsi_set' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 24a7109..60d64a1 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -317,11 +317,6 @@ static inline u32 dsi_read(struct dw_mipi_dsi_rockchip *dsi, u32 reg)
 	return readl(dsi->base + reg);
 }
 
-static inline void dsi_set(struct dw_mipi_dsi_rockchip *dsi, u32 reg, u32 mask)
-{
-	dsi_write(dsi, reg, dsi_read(dsi, reg) | mask);
-}
-
 static inline void dsi_update_bits(struct dw_mipi_dsi_rockchip *dsi, u32 reg,
 				   u32 mask, u32 val)
 {
-- 
1.8.3.1



From andy.shevchenko at gmail.com  Thu Apr 15 09:50:36 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 15 Apr 2021 11:50:36 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
Message-ID: <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>

On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:

...

> > > > > I guess it's still fine to add a dependency on ACPI?
> > > >
> > > > But why?
> > >
> > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> >
> > I'm not using it at all. Ask the author :-)
> >
> > But if we follow your logic, then we need to mark all the _platform_ drivers
> > for x86 world as ACPI dependent? This sounds ugly.
>
> Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> (2) no other way of instantiating their devices?
> The first driver from the top of my memory I looked at is rtc-cmos:
> it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> from arch/x86/kernel/rtc.c.
>
> For drivers with only an .of_match_table(), and no legacy users
> instantiating platform devices, we do have dependencies on OF.

This is not true. Entire IIO subsystem is an example.

-- 
With Best Regards,
Andy Shevchenko


From tony at atomide.com  Thu Apr 15 09:53:05 2021
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 15 Apr 2021 11:53:05 +0300
Subject: [PATCH] gpio: omap: Save and restore sysconfig
Message-ID: <20210415085305.56413-1-tony@atomide.com>

As we are using cpu_pm to save and restore context, we must also save and
restore the timer sysconfig register TIOCP_CFG. This is needed because
we are not calling PM runtime functions at all with cpu_pm.

We need to save the sysconfig on idle as it's value can get reconfigured by
PM runtime and can be different from the init time value. Device specific
flags like "ti,no-idle-on-init" can affect the init value.

Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
Cc: Adam Ford <aford173 at gmail.com>
Cc: Andreas Kemnade <andreas at kemnade.info>
Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/gpio/gpio-omap.c                | 9 +++++++++
 include/linux/platform_data/gpio-omap.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -29,6 +29,7 @@
 #define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF
 
 struct gpio_regs {
+	u32 sysconfig;
 	u32 irqenable1;
 	u32 irqenable2;
 	u32 wake_en;
@@ -1069,6 +1070,7 @@ static void omap_gpio_init_context(struct gpio_bank *p)
 	const struct omap_gpio_reg_offs *regs = p->regs;
 	void __iomem *base = p->base;
 
+	p->context.sysconfig	= readl_relaxed(base + regs->sysconfig);
 	p->context.ctrl		= readl_relaxed(base + regs->ctrl);
 	p->context.oe		= readl_relaxed(base + regs->direction);
 	p->context.wake_en	= readl_relaxed(base + regs->wkup_en);
@@ -1088,6 +1090,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 	const struct omap_gpio_reg_offs *regs = bank->regs;
 	void __iomem *base = bank->base;
 
+	writel_relaxed(bank->context.sysconfig, base + regs->sysconfig);
 	writel_relaxed(bank->context.wake_en, base + regs->wkup_en);
 	writel_relaxed(bank->context.ctrl, base + regs->ctrl);
 	writel_relaxed(bank->context.leveldetect0, base + regs->leveldetect0);
@@ -1115,6 +1118,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
 
 	bank->saved_datain = readl_relaxed(base + bank->regs->datain);
 
+	/* Save syconfig, it's runtime value can be different from init value */
+	if (bank->loses_context)
+		bank->context.sysconfig = readl_relaxed(base + bank->regs->sysconfig);
+
 	if (!bank->enabled_non_wakeup_gpios)
 		goto update_gpio_context_count;
 
@@ -1279,6 +1286,7 @@ static int gpio_omap_cpu_notifier(struct notifier_block *nb,
 
 static const struct omap_gpio_reg_offs omap2_gpio_regs = {
 	.revision =		OMAP24XX_GPIO_REVISION,
+	.sysconfig =		OMAP24XX_GPIO_SYSCONFIG,
 	.direction =		OMAP24XX_GPIO_OE,
 	.datain =		OMAP24XX_GPIO_DATAIN,
 	.dataout =		OMAP24XX_GPIO_DATAOUT,
@@ -1302,6 +1310,7 @@ static const struct omap_gpio_reg_offs omap2_gpio_regs = {
 
 static const struct omap_gpio_reg_offs omap4_gpio_regs = {
 	.revision =		OMAP4_GPIO_REVISION,
+	.sysconfig =		OMAP4_GPIO_SYSCONFIG,
 	.direction =		OMAP4_GPIO_OE,
 	.datain =		OMAP4_GPIO_DATAIN,
 	.dataout =		OMAP4_GPIO_DATAOUT,
diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -85,6 +85,7 @@
  * omap2+ specific GPIO registers
  */
 #define OMAP24XX_GPIO_REVISION		0x0000
+#define OMAP24XX_GPIO_SYSCONFIG		0x0010
 #define OMAP24XX_GPIO_IRQSTATUS1	0x0018
 #define OMAP24XX_GPIO_IRQSTATUS2	0x0028
 #define OMAP24XX_GPIO_IRQENABLE2	0x002c
@@ -108,6 +109,7 @@
 #define OMAP24XX_GPIO_SETDATAOUT	0x0094
 
 #define OMAP4_GPIO_REVISION		0x0000
+#define OMAP4_GPIO_SYSCONFIG		0x0010
 #define OMAP4_GPIO_EOI			0x0020
 #define OMAP4_GPIO_IRQSTATUSRAW0	0x0024
 #define OMAP4_GPIO_IRQSTATUSRAW1	0x0028
@@ -148,6 +150,7 @@
 #ifndef __ASSEMBLER__
 struct omap_gpio_reg_offs {
 	u16 revision;
+	u16 sysconfig;
 	u16 direction;
 	u16 datain;
 	u16 dataout;
-- 
2.31.1


From tony at atomide.com  Thu Apr 15 09:55:06 2021
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 15 Apr 2021 11:55:06 +0300
Subject: [PATCH] clocksource/drivers/timer-ti-dm: Save and restore timer
 TIOCP_CFG
Message-ID: <20210415085506.56828-1-tony@atomide.com>

As we are using cpu_pm to save and restore context, we must also save and
restore the timer sysconfig register TIOCP_CFG. This is needed because
we are not calling PM runtime functions at all with cpu_pm.

Fixes: b34677b0999a ("clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore")
Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
Cc: Adam Ford <aford173 at gmail.com>
Cc: Andreas Kemnade <andreas at kemnade.info>
Cc: Lokesh Vutla <lokeshvutla at ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/clocksource/timer-ti-dm.c | 6 ++++++
 include/clocksource/timer-ti-dm.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clocksource/timer-ti-dm.c b/drivers/clocksource/timer-ti-dm.c
--- a/drivers/clocksource/timer-ti-dm.c
+++ b/drivers/clocksource/timer-ti-dm.c
@@ -78,6 +78,9 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,
 
 static void omap_timer_restore_context(struct omap_dm_timer *timer)
 {
+	__omap_dm_timer_write(timer, OMAP_TIMER_OCP_CFG_OFFSET,
+			      timer->context.ocp_cfg, 0);
+
 	omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
 				timer->context.twer);
 	omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
@@ -95,6 +98,9 @@ static void omap_timer_restore_context(struct omap_dm_timer *timer)
 
 static void omap_timer_save_context(struct omap_dm_timer *timer)
 {
+	timer->context.ocp_cfg =
+		__omap_dm_timer_read(timer, OMAP_TIMER_OCP_CFG_OFFSET, 0);
+
 	timer->context.tclr =
 			omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
 	timer->context.twer =
diff --git a/include/clocksource/timer-ti-dm.h b/include/clocksource/timer-ti-dm.h
--- a/include/clocksource/timer-ti-dm.h
+++ b/include/clocksource/timer-ti-dm.h
@@ -74,6 +74,7 @@
 #define OMAP_TIMER_ERRATA_I103_I767			0x80000000
 
 struct timer_regs {
+	u32 ocp_cfg;
 	u32 tidr;
 	u32 tier;
 	u32 twer;
-- 
2.31.1


From eugen.hristev at microchip.com  Thu Apr 15 09:55:30 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 15 Apr 2021 11:55:30 +0300
Subject: [PATCH v4 29/33] dt-bindings: media: atmel-isc: convert to yaml
In-Reply-To: <20210413105731.610028-30-eugen.hristev@microchip.com>
References: <20210413105731.610028-30-eugen.hristev@microchip.com>
Message-ID: <20210415085530.824638-1-eugen.hristev@microchip.com>

Convert the Atmel ISC to yaml binding format.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v4:
- added '|' at description to maintain line breaks

 .../devicetree/bindings/media/atmel,isc.yaml  | 115 ++++++++++++++++++
 .../devicetree/bindings/media/atmel-isc.txt   |  65 ----------
 2 files changed, 115 insertions(+), 65 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml
 delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel,isc.yaml b/Documentation/devicetree/bindings/media/atmel,isc.yaml
new file mode 100644
index 000000000000..a29c11667c82
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel,isc.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2016-2021 Microchip Technology, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/atmel,isc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel Image Sensor Controller (ISC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev at microchip.com>
+
+description: |
+  The Image Sensor Controller (ISC) device provides the video input capabilities for the
+  Atmel/Microchip AT91 SAMA family of devices.
+
+  The ISC has a single parallel input that supports RAW Bayer, RGB or YUV video,
+  with both external synchronization and BT.656 synchronization for the latter.
+
+properties:
+  compatible:
+    const: atmel,sama5d2-isc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    minItems: 3
+    maxItems: 3
+
+  clock-names:
+    items:
+      - const: hclock
+      - const: iscck
+      - const: gck
+
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    const: isc-mck
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      endpoint:
+        $ref: video-interfaces.yaml#
+
+        properties:
+          remote-endpoint: true
+
+          bus-width:
+            enum: [8, 9, 10, 11, 12]
+            default: 12
+
+          hsync-active:
+            enum: [0, 1]
+            default: 1
+
+          vsync-active:
+            enum: [0, 1]
+            default: 1
+
+          pclk-sample:
+            enum: [0, 1]
+            default: 1
+
+        required:
+          - remote-endpoint
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - clock-output-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    isc: isc at f0008000 {
+        compatible = "atmel,sama5d2-isc";
+        reg = <0xf0008000 0x4000>;
+        interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+        clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
+        clock-names = "hclock", "iscck", "gck";
+        #clock-cells = <0>;
+        clock-output-names = "isc-mck";
+
+        port {
+                isc_0: endpoint {
+                       remote-endpoint = <&ov7740_0>;
+                       hsync-active = <1>;
+                       vsync-active = <0>;
+                       pclk-sample = <1>;
+                       bus-width = <8>;
+                };
+        };
+    };
+
diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt b/Documentation/devicetree/bindings/media/atmel-isc.txt
deleted file mode 100644
index bbe0e87c6188..000000000000
--- a/Documentation/devicetree/bindings/media/atmel-isc.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Atmel Image Sensor Controller (ISC)
-----------------------------------------------
-
-Required properties for ISC:
-- compatible
-	Must be "atmel,sama5d2-isc".
-- reg
-	Physical base address and length of the registers set for the device.
-- interrupts
-	Should contain IRQ line for the ISC.
-- clocks
-	List of clock specifiers, corresponding to entries in
-	the clock-names property;
-	Please refer to clock-bindings.txt.
-- clock-names
-	Required elements: "hclock", "iscck", "gck".
-- #clock-cells
-	Should be 0.
-- clock-output-names
-	Should be "isc-mck".
-- pinctrl-names, pinctrl-0
-	Please refer to pinctrl-bindings.txt.
-
-ISC supports a single port node with parallel bus. It should contain one
-'port' child node with child 'endpoint' node. Please refer to the bindings
-defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-isc: isc at f0008000 {
-	compatible = "atmel,sama5d2-isc";
-	reg = <0xf0008000 0x4000>;
-	interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
-	clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
-	clock-names = "hclock", "iscck", "gck";
-	#clock-cells = <0>;
-	clock-output-names = "isc-mck";
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>;
-
-	port {
-		isc_0: endpoint {
-			remote-endpoint = <&ov7740_0>;
-			hsync-active = <1>;
-			vsync-active = <0>;
-			pclk-sample = <1>;
-		};
-	};
-};
-
-i2c1: i2c at fc028000 {
-	ov7740: camera at 21 {
-		compatible = "ovti,ov7740";
-		reg = <0x21>;
-		clocks = <&isc>;
-		clock-names = "xvclk";
-		assigned-clocks = <&isc>;
-		assigned-clock-rates = <24000000>;
-
-		port {
-			ov7740_0: endpoint {
-				remote-endpoint = <&isc_0>;
-			};
-		};
-	};
-};
-- 
2.25.1



From eugen.hristev at microchip.com  Thu Apr 15 09:58:46 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 15 Apr 2021 11:58:46 +0300
Subject: [PATCH v4 30/33] dt-bindings: media: add microchip,
 xisc device bindings
In-Reply-To: <20210413105731.610028-31-eugen.hristev@microchip.com>
References: <20210413105731.610028-31-eugen.hristev@microchip.com>
Message-ID: <20210415085846.824796-1-eugen.hristev@microchip.com>

Add bindings for the Microchip eXtended Image Sensor Controller.
Based on the atmel,isc.yaml binding.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
 .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml

diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
new file mode 100644
index 000000000000..c829fa3d2e0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2021 Microchip Technology, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip eXtended Image Sensor Controller (XISC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev at microchip.com>
+
+description: |
+  The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
+  Microchip AT91 SAM family of devices.
+
+  The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
+  The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
+  parallel sensor.
+
+  The XISC provides one clock output that is used to clock the demuxer/bridge.
+
+properties:
+  compatible:
+    const: microchip,sama7g5-isc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: hclock
+
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    const: isc-mck
+
+  microchip,mipi-mode:
+    type: boolean
+    description:
+      As the XISC is usually connected to a demux/bridge, the XISC receives
+      the same type of input, however, it should be aware of the type of
+      signals received. The mipi-mode enables different internal handling
+      of the data and clock lines.
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      endpoint:
+        $ref: video-interfaces.yaml#
+
+        properties:
+          bus-type:
+            enum: [5, 6]
+
+          remote-endpoint: true
+
+          bus-width:
+            enum: [8, 9, 10, 11, 12]
+            default: 12
+
+          hsync-active:
+            enum: [0, 1]
+            default: 1
+
+          vsync-active:
+            enum: [0, 1]
+            default: 1
+
+          pclk-sample:
+            enum: [0, 1]
+            default: 1
+
+        required:
+          - remote-endpoint
+          - bus-type
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - clock-output-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/at91.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    xisc: xisc at e1408000 {
+        compatible = "microchip,sama7g5-isc";
+        reg = <0xe1408000 0x2000>;
+        interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+        clock-names = "hclock";
+        #clock-cells = <0>;
+        clock-output-names = "isc-mck";
+
+        port {
+                xisc_in: endpoint {
+                       bus-type = <5>; /* Parallel */
+                       remote-endpoint = <&csi2dc_out>;
+                       hsync-active = <1>;
+                       vsync-active = <1>;
+                       bus-width = <12>;
+                };
+        };
+    };
+
-- 
2.25.1



From yangyicong at hisilicon.com  Thu Apr 15 10:04:39 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Thu, 15 Apr 2021 17:04:39 +0800
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <21d833f0-b1b8-9732-21c7-3a73676e07d3@hisilicon.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <21d833f0-b1b8-9732-21c7-3a73676e07d3@hisilicon.com>
Message-ID: <39f6bbed-9eea-963a-1ef1-a83248f162aa@hisilicon.com>

On 2021/4/15 16:18, Yicong Yang wrote:
> On 2021/4/15 2:06, Geert Uytterhoeven wrote:
>> Hi Yicong,
>>
>> On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
>>> On 2021/4/13 20:26, Geert Uytterhoeven wrote:
>>>> The HiSilicon Kunpeng I2C controller is only present on HiSilicon
>>>> Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
>>>> Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
>>>> about this driver when configuring a kernel without Hisilicon platform
>>>> or ACPI firmware support.
>>>
>>> this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
>>> not sure all the platform this IP on has ARCH_HISI configured. The driver
>>> will not be compiled by default config. This is not correct to have
>>> this dependence.
>>
>> Thanks for your answer!
>>
>> I guess it's still fine to add a dependency on ACPI?
> 
> yes. currently we only use this driver through ACPI. So at least
> for this driver, it make sense to keep the dependency.
> 

sorry. i was a little mess about this. I dropped this in [1].
so just keep it as is.

[1] https://lore.kernel.org/linux-i2c/YGMntYT2iz72wgrd at smile.fi.intel.com/

>>
>> Thanks again!
>>
>>>> Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller")
>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>>> ---
>>>>  drivers/i2c/busses/Kconfig | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>>>> index b5b4e0d0ff4dd0bc..3ead6d9e130b2ebc 100644
>>>> --- a/drivers/i2c/busses/Kconfig
>>>> +++ b/drivers/i2c/busses/Kconfig
>>>> @@ -647,7 +647,7 @@ config I2C_HIGHLANDER
>>>>
>>>>  config I2C_HISI
>>>>       tristate "HiSilicon I2C controller"
>>>> -     depends on ARM64 || COMPILE_TEST
>>>> +     depends on (ARM64 && ARCH_HISI && ACPI) || COMPILE_TEST
>>>>       help
>>>>         Say Y here if you want to have Hisilicon I2C controller support
>>>>         available on the Kunpeng Server.
>> \
>> Gr{oetje,eeting}s,
>>
>>                         Geert
>>
> 
> 
> .
> 



From u.kleine-koenig at pengutronix.de  Thu Apr 15 10:06:11 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 15 Apr 2021 11:06:11 +0200
Subject: [PATCH] pwm: mediatek: remove unused function
In-Reply-To: <1618475753-102123-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1618475753-102123-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <20210415090611.jjbwoz2nbcam3kct@pengutronix.de>

On Thu, Apr 15, 2021 at 04:35:53PM +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
> 
> drivers/pwm/pwm-mediatek.c:110:19: warning: unused function
> 'pwm_mediatek_readl' [-Wunused-function].
> 
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>

Looks right, even though I would prefer to see a patch implementing
.get_state instead (which probably would make use of this function).

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/20210415/90373a89/attachment.sig>

From ulf.hansson at linaro.org  Thu Apr 15 10:07:03 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 15 Apr 2021 11:07:03 +0200
Subject: [PATCH] mmc: meson-gx: remove useless warning about scatterlist
 size alignment in block mode
In-Reply-To: <20210414100010.3877669-1-narmstrong@baylibre.com>
References: <20210414100010.3877669-1-narmstrong@baylibre.com>
Message-ID: <CAPDyKFpNLu3R+7ODZaC7yWMYbSOujswgLTkN97FQNg5zhwSxgw@mail.gmail.com>

On Wed, 14 Apr 2021 at 12:00, Neil Armstrong <narmstrong at baylibre.com> wrote:
>
> Since commit e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode"),
> support for SDIO SD_IO_RW_EXTENDED transferts are properly filtered but some driver
> like brcmfmac still gives a block sg buffer size not aligned with SDIO block,
> triggerring a warning even if the transfer works in degraded mode.
>
> This should be ultimately fixed in brcmfmac, but since it's only a performance issue
> the warning should be removed.
>
> Fixes: e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  drivers/mmc/host/meson-gx-mmc.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index eb6c02bc4a02..6bc151045843 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -246,11 +246,8 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>                  * size, otherwise chain mode could not be used.
>                  */
>                 for_each_sg(data->sg, sg, data->sg_len, i) {
> -                       if (sg->length % data->blksz) {
> -                               WARN_ONCE(1, "unaligned sg len %u blksize %u\n",
> -                                         sg->length, data->blksz);

Rather than removing this warning, perhaps an option could be to use
dev_warn_once() instead?

> +                       if (sg->length % data->blksz)
>                                 return;
> -                       }
>                 }
>         }
>

Kind regards
Uffe


From catalin.marinas at arm.com  Thu Apr 15 10:17:43 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 10:17:43 +0100
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn,endif}
In-Reply-To: <20210414000803.662534-1-nathan@kernel.org>
References: <20210414000803.662534-1-nathan@kernel.org>
Message-ID: <20210415091743.GB1015@arm.com>

Hi Nathan,

On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
> 
> <instantiation>:5:7: error: expected assembly-time absolute expression
>  .org . - (664b-663b) + (662b-661b)
>       ^
> <instantiation>:6:7: error: expected assembly-time absolute expression
>  .org . - (662b-661b) + (664b-663b)
>       ^

I tried the latest Linus' tree and linux-next (defconfig) with this
commit in and I can't get your build error. I used both clang-10 from
Debian stable and clang-11 from Debian sid. So, which clang version did
you use or which kernel config options?

-- 
Catalin


From david at redhat.com  Thu Apr 15 10:30:12 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 15 Apr 2021 11:30:12 +0200
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <YHdPmtpzFxHE9mAt@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
 <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>
 <YHdPmtpzFxHE9mAt@kernel.org>
Message-ID: <f5503130-c0e7-329f-86c4-727ece1c860f@redhat.com>

> Not sure we really need a new pagetype here, PG_Reserved seems to be quite
> enough to say "don't touch this".  I generally agree that we could make
> PG_Reserved a PageType and then have several sub-types for reserved memory.
> This definitely will add clarity but I'm not sure that this justifies
> amount of churn and effort required to audit uses of PageResrved().
>   
>> Then, we could mostly avoid having to query memblock at runtime to figure
>> out that this is special memory. This would obviously be an extension to
>> this series. Just a thought.
> 
> Stop pushing memblock out of kernel! ;-)

Can't stop. Won't stop. :D

It's lovely for booting up a kernel until we have other data-structures 
in place ;)


-- 
Thanks,

David / dhildenb



From david at redhat.com  Thu Apr 15 10:31:26 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 15 Apr 2021 11:31:26 +0200
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <YHdQtmuxpqi4wCE/@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
 <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
 <9c0956f0-494e-5c6b-bdc2-d4213afd5e2f@redhat.com>
 <YHdQtmuxpqi4wCE/@kernel.org>
Message-ID: <62161846-4f03-e4b1-ae0b-fdf96f78d97c@redhat.com>

On 14.04.21 22:29, Mike Rapoport wrote:
> On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
>> On 08.04.21 07:14, Anshuman Khandual wrote:
>>>
>>> On 4/7/21 10:56 PM, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>>
>>>> The intended semantics of pfn_valid() is to verify whether there is a
>>>> struct page for the pfn in question and nothing else.
>>>
>>> Should there be a comment affirming this semantics interpretation, above the
>>> generic pfn_valid() in include/linux/mmzone.h ?
>>>
>>>>
>>>> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
>>>> linear map vs those that require ioremap() to access them.
>>>>
>>>> Introduce a dedicated pfn_is_memory() to perform such check and use it
>>>> where appropriate.
>>>>
>>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>>> ---
>>>>    arch/arm64/include/asm/memory.h | 2 +-
>>>>    arch/arm64/include/asm/page.h   | 1 +
>>>>    arch/arm64/kvm/mmu.c            | 2 +-
>>>>    arch/arm64/mm/init.c            | 6 ++++++
>>>>    arch/arm64/mm/ioremap.c         | 4 ++--
>>>>    arch/arm64/mm/mmu.c             | 2 +-
>>>>    6 files changed, 12 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>>> index 0aabc3be9a75..7e77fdf71b9d 100644
>>>> --- a/arch/arm64/include/asm/memory.h
>>>> +++ b/arch/arm64/include/asm/memory.h
>>>> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>>>    #define virt_addr_valid(addr)	({					\
>>>>    	__typeof__(addr) __addr = __tag_reset(addr);			\
>>>> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
>>>> +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
>>>>    })
>>>>    void dump_mem_limit(void);
>>>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>>>> index 012cffc574e8..32b485bcc6ff 100644
>>>> --- a/arch/arm64/include/asm/page.h
>>>> +++ b/arch/arm64/include/asm/page.h
>>>> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>>>>    typedef struct page *pgtable_t;
>>>>    extern int pfn_valid(unsigned long);
>>>> +extern int pfn_is_memory(unsigned long);
>>>>    #include <asm/memory.h>
>>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>>> index 8711894db8c2..ad2ea65a3937 100644
>>>> --- a/arch/arm64/kvm/mmu.c
>>>> +++ b/arch/arm64/kvm/mmu.c
>>>> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>>>>    static bool kvm_is_device_pfn(unsigned long pfn)
>>>>    {
>>>> -	return !pfn_valid(pfn);
>>>> +	return !pfn_is_memory(pfn);
>>>>    }
>>>>    /*
>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>> index 3685e12aba9b..258b1905ed4a 100644
>>>> --- a/arch/arm64/mm/init.c
>>>> +++ b/arch/arm64/mm/init.c
>>>> @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
>>>>    }
>>>>    EXPORT_SYMBOL(pfn_valid);
>>>> +int pfn_is_memory(unsigned long pfn)
>>>> +{
>>>> +	return memblock_is_map_memory(PFN_PHYS(pfn));
>>>> +}
>>>> +EXPORT_SYMBOL(pfn_is_memory);> +
>>>
>>> Should not this be generic though ? There is nothing platform or arm64
>>> specific in here. Wondering as pfn_is_memory() just indicates that the
>>> pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
>>> instead ? Regardless, it's fine either way.
>>
>> TBH, I dislike (generic) pfn_is_memory(). It feels like we're mixing
>> concepts.
> 
> Yeah, at the moment NOMAP is very much arm specific so I'd keep it this way
> for now.
> 
>>   NOMAP memory vs !NOMAP memory; even NOMAP is some kind of memory
>> after all. pfn_is_map_memory() would be more expressive, although still
>> sub-optimal.
>>
>> We'd actually want some kind of arm64-specific pfn_is_system_memory() or the
>> inverse pfn_is_device_memory() -- to be improved.
> 
> In my current version (to be posted soon) I've started with
> pfn_lineary_mapped() but then ended up with pfn_mapped() to make it
> "upward" compatible with architectures that use direct rather than linear
> map :)

And even that is moot. It doesn't tell you if a PFN is *actually* mapped 
(hello secretmem).

I'd suggest to just use memblock_is_map_memory() in arch specific code. 
Then it's clear what we are querying exactly and what the semantics 
might be.

-- 
Thanks,

David / dhildenb



From hsinyi at chromium.org  Thu Apr 15 10:35:12 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:12 +0800
Subject: [PATCH 1/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kappa
Message-ID: <20210415093519.1920877-1-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index aff57a8c8c30..81b86b189a8d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -144,6 +144,10 @@ properties:
           - const: google,kakadu-rev2
           - const: google,kakadu
           - const: mediatek,mt8183
+      - description: Google Kappa (HP Chromebook 11a)
+        items:
+          - const: google,kappa
+          - const: mediatek,mt8183
       - description: Google Kodama (Lenovo 10e Chromebook Tablet)
         items:
           - enum:
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:13 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:13 +0800
Subject: [PATCH 2/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-willow
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-2-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T).

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 81b86b189a8d..96c401597bd8 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -157,6 +157,13 @@ properties:
               - google,kodama-sku32
           - const: google,kodama
           - const: mediatek,mt8183
+      - description: Google Willow (Acer Chromebook 311 C722/C722T)
+        items:
+          - enum:
+              - google,willow-sku0
+              - google,willow-sku1
+          - const: google,willow
+          - const: mediatek,mt8183
       - items:
           - enum:
               - mediatek,mt8183-pumpkin
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:14 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:14 +0800
Subject: [PATCH 3/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-burnet
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-3-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 96c401597bd8..0870490aa350 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -122,6 +122,10 @@ properties:
           - enum:
               - 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:
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:15 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:15 +0800
Subject: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-4-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 0870490aa350..39e4a99ebb37 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -137,9 +137,11 @@ properties:
         items:
           - const: google,damu
           - const: mediatek,mt8183
-      - description: Google Juniper (Acer Chromebook Spin 311)
+      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Crhomebook 311)
         items:
-          - const: google,juniper-sku16
+          - enum:
+              - google,juniper-sku16
+              - google,juniper-sku17
           - const: google,juniper
           - const: mediatek,mt8183
       - description: Google Kakadu (ASUS Chromebook Detachable CM3)
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:16 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:16 +0800
Subject: [PATCH 5/8] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-5-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/Makefile            |  1 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts  | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index a1c50adc98fa..df70674949ce 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
new file mode 100644
index 000000000000..b3f46c16e5d7
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google kappa board";
+	compatible = "google,kappa", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:18 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:18 +0800
Subject: [PATCH 7/8] arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-7-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  1 +
 .../mediatek/mt8183-kukui-jacuzzi-burnet.dts  | 33 +++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 5f43bbc2ea72..b33d0bc58021 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
new file mode 100644
index 000000000000..b97ca331970e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google burnet board";
+	compatible = "google,burnet", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
+
+&i2c0 {
+	touchscreen at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		interrupts-extended = <&pio 155 IRQ_TYPE_LEVEL_LOW>;
+
+		post-power-on-delay-ms = <200>;
+		hid-descr-addr = <0x0020>;
+	};
+};
+
+&i2c2 {
+	clock-stretch-ns = <4100>;
+};
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:19 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:19 +0800
Subject: [PATCH 8/8] arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-8-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/Makefile                |  1 +
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12 ++++++++++++
 2 files changed, 13 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index b33d0bc58021..25770d83059d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
new file mode 100644
index 000000000000..6f1aa692753a
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-juniper.dtsi"
+
+/ {
+	model = "Google kenzo sku17 board";
+	compatible = "google,juniper-sku17", "google,juniper", "mediatek,mt8183";
+};
-- 
2.31.1.295.g9ea45b61b8-goog



From hsinyi at chromium.org  Thu Apr 15 10:35:17 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 15 Apr 2021 17:35:17 +0800
Subject: [PATCH 6/8] arm64: dts: mt8183: Add kukui-jacuzzi-willow board
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <20210415093519.1920877-6-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T)

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  2 ++
 .../mt8183-kukui-jacuzzi-willow-sku0.dts      | 13 +++++++++
 .../mt8183-kukui-jacuzzi-willow-sku1.dts      | 12 ++++++++
 .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 28 +++++++++++++++++++
 4 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index df70674949ce..5f43bbc2ea72 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -16,6 +16,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
new file mode 100644
index 000000000000..281265f082db
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku0";
+	compatible = "google,willow-sku0", "google,willow", "mediatek,mt8183";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
new file mode 100644
index 000000000000..22e56bdc1ee3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku1";
+	compatible = "google,willow-sku1", "google,willow", "mediatek,mt8183";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
new file mode 100644
index 000000000000..3204c1abc4ee
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+&i2c2 {
+	clock-stretch-ns = <9500>;
+
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_pins>;
+
+		interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
+
+		wakeup-source;
+	};
+};
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_JUNIPER";
+};
-- 
2.31.1.295.g9ea45b61b8-goog



From krzysztof.kozlowski at canonical.com  Thu Apr 15 10:38:03 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 15 Apr 2021 11:38:03 +0200
Subject: [RFT 2/2] i2c: s3c2410: fix possible NULL pointer deref on read
 message after write
In-Reply-To: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
References: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210415093803.162673-2-krzysztof.kozlowski@canonical.com>

Interrupt handler processes multiple message write requests one after
another, till the driver message queue is drained.  However if driver
encounters a read message without preceding START, it stops the I2C
transfer as it is an invalid condition for the controller.  At least the
comment describes a requirement "the controller forces us to send a new
START when we change direction".  This stop results in clearing the
message queue (i2c->msg = NULL).

The code however immediately jumped back to label "retry_write" which
dereferenced the "i2c->msg" making it a possible NULL pointer
dereference.

The Coverity analysis:
1. Condition !is_msgend(i2c), taking false branch.
   if (!is_msgend(i2c)) {

2. Condition !is_lastmsg(i2c), taking true branch.
   } else if (!is_lastmsg(i2c)) {

3. Condition i2c->msg->flags & 1, taking true branch.
   if (i2c->msg->flags & I2C_M_RD) {

4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL.
   s3c24xx_i2c_stop(i2c, -EINVAL);

5. Jumping to label retry_write.
   goto retry_write;

All previous calls to s3c24xx_i2c_stop() in this interrupt service
routine are followed by jumping to end of function (acknowledging
the interrupt and returning).  This seems a reasonable choice also here
since message buffer was entirely emptied.

Addresses-Coverity: Explicit null dereferenced
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/i2c/busses/i2c-s3c2410.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index ab928613afba..4d82761e1585 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -480,7 +480,10 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat)
 					 * forces us to send a new START
 					 * when we change direction
 					 */
+					dev_dbg(i2c->dev,
+						"missing START before write->read\n");
 					s3c24xx_i2c_stop(i2c, -EINVAL);
+					break;
 				}
 
 				goto retry_write;
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Thu Apr 15 10:38:02 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 15 Apr 2021 11:38:02 +0200
Subject: [PATCH 1/2] i2c: s3c2410: simplify getting of_device_id match data
Message-ID: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>

Use of_device_get_match_data() to make the code slightly smaller.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/i2c/busses/i2c-s3c2410.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 62a903fbe912..ab928613afba 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -24,6 +24,7 @@
 #include <linux/slab.h>
 #include <linux/io.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/gpio/consumer.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/mfd/syscon.h>
@@ -156,12 +157,8 @@ MODULE_DEVICE_TABLE(of, s3c24xx_i2c_match);
  */
 static inline kernel_ulong_t s3c24xx_get_device_quirks(struct platform_device *pdev)
 {
-	if (pdev->dev.of_node) {
-		const struct of_device_id *match;
-
-		match = of_match_node(s3c24xx_i2c_match, pdev->dev.of_node);
-		return (kernel_ulong_t)match->data;
-	}
+	if (pdev->dev.of_node)
+		return (kernel_ulong_t)of_device_get_match_data(&pdev->dev);
 
 	return platform_get_device_id(pdev)->driver_data;
 }
-- 
2.25.1



From eric.auger at redhat.com  Thu Apr 15 10:39:17 2021
From: eric.auger at redhat.com (Auger Eric)
Date: Thu, 15 Apr 2021 11:39:17 +0200
Subject: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
In-Reply-To: <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
 <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>
Message-ID: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>

Hi Shameer,
On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream ids and smmu node?info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> ---
>  drivers/acpi/arm64/iort.c | 122 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 121 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 9929ff50c0c0..a9705aa35028 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -40,6 +40,25 @@ struct iort_fwnode {
>  static LIST_HEAD(iort_fwnode_list);
>  static DEFINE_SPINLOCK(iort_fwnode_lock);
>  
> +struct iort_rmr_id {
> +	u32  sid;
> +	struct acpi_iort_node *smmu;
> +};
> +
> +/*
> + * One entry for IORT RMR.
> + */
> +struct iort_rmr_entry {
> +	struct list_head list;
> +
> +	unsigned int rmr_ids_num;
> +	struct iort_rmr_id *rmr_ids;
> +
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +};
> +
> +static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI */
> +
>  /**
>   * iort_set_fwnode() - Create iort_fwnode and use it to register
>   *		       iommu data in the iort_fwnode_list
> @@ -393,7 +412,8 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
>  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
>  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
>  		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
> -		    node->type == ACPI_IORT_NODE_PMCG) {
> +		    node->type == ACPI_IORT_NODE_PMCG ||
> +		    node->type == ACPI_IORT_NODE_RMR) {
>  			*id_out = map->output_base;
>  			return parent;
>  		}
> @@ -1647,6 +1667,103 @@ static void __init iort_enable_acs(struct acpi_iort_node *iort_node)
>  #else
>  static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
>  #endif
> +static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc)
> +{
> +	struct iort_rmr_entry *e;
> +	u64 end, start = desc->base_address, length = desc->length;
> +
> +	if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
> +		return -EINVAL;
> +
> +	end = start + length - 1;
> +
> +	/* Check for address overlap */
I don't get this check. What is the problem if you attach the same range
to different stream ids. Shouldn't you check there is no overlap for the
same sid?


> +	list_for_each_entry(e, &iort_rmr_list, list) {
> +		u64 e_start = e->rmr_desc->base_address;
> +		u64 e_end = e_start + e->rmr_desc->length - 1;
> +
> +		if (start <= e_end && end >= e_start)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
> +{
> +	struct iort_rmr_id *rmr_ids, *ids;
> +	struct iort_rmr_entry *e;
> +	struct acpi_iort_rmr *rmr;
> +	struct acpi_iort_rmr_desc *rmr_desc;
> +	u32 map_count = iort_node->mapping_count;
> +	int i, ret = 0, desc_count = 0;
> +
> +	if (iort_node->type != ACPI_IORT_NODE_RMR)
> +		return 0;
> +
> +	if (!iort_node->mapping_offset || !map_count) {
> +		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> +		       iort_node);
> +		return -EINVAL;
> +	}
> +
> +	rmr_ids = kmalloc(sizeof(*rmr_ids) * map_count, GFP_KERNEL);
> +	if (!rmr_ids)
> +		return -ENOMEM;
> +
> +	/* Retrieve associated smmu and stream id */
> +	ids = rmr_ids;
nit: do you need both rmr_ids and ids?
> +	for (i = 0; i < map_count; i++, ids++) {
> +		ids->smmu = iort_node_get_id(iort_node, &ids->sid, i);
> +		if (!ids->smmu) {
> +			pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
> +			       iort_node);
> +			ret = -EINVAL;
> +			goto out;
> +		}
> +	}
> +
> +	/* Retrieve RMR data */
> +	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> +	if (!rmr->rmr_offset || !rmr->rmr_count) {
> +		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
> +		       iort_node);
> +		ret = -EINVAL;
> +		goto out;
> +	}
> +
> +	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> +				rmr->rmr_offset);
> +
> +	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> +		ret = iort_rmr_desc_valid(rmr_desc);
> +		if (ret) {
> +			pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p, skipping...\n",
> +			       i, iort_node);
> +			goto out;
so I understand you skip the whole node and not just that rmr desc,
otherwise you would continue. so in that case don't you need to free
both rmr_ids and already allocated 'e'?
> +		}
> +
> +		e = kmalloc(sizeof(*e), GFP_KERNEL);
> +		if (!e) {
> +			ret = -ENOMEM;
> +			goto out;
> +		}
> +
> +		e->rmr_ids_num = map_count;
> +		e->rmr_ids = rmr_ids;
> +		e->rmr_desc = rmr_desc;
> +
> +		list_add_tail(&e->list, &iort_rmr_list);
> +		desc_count++;
> +	}
> +
> +	return 0;
> +
> +out:
> +	if (!desc_count)
don't you want to test ret instead? see comment above. + free allocated ''e'
> +		kfree(rmr_ids);
> +	return ret;
> +}
>  
>  static void __init iort_init_platform_devices(void)
>  {
> @@ -1676,6 +1793,9 @@ static void __init iort_init_platform_devices(void)
>  
>  		iort_enable_acs(iort_node);
>  
> +		if (iort_table->revision == 1)
> +			iort_parse_rmr(iort_node);
> +
>  		ops = iort_get_dev_cfg(iort_node);
>  		if (ops) {
>  			fwnode = acpi_alloc_fwnode_static();
> 
Thanks

Eric



From dqfext at gmail.com  Thu Apr 15 10:40:05 2021
From: dqfext at gmail.com (DENG Qingfang)
Date: Thu, 15 Apr 2021 17:40:05 +0800
Subject: [PATCH net-next] net: ethernet: mediatek: fix typo in offload code
Message-ID: <20210415094005.2673-1-dqfext@gmail.com>

.key_offset was assigned to .head_offset instead. Fix the typo.

Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support")
Signed-off-by: DENG Qingfang <dqfext at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_ppe_offload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
index 4975106fbc42..f47f319f3ae0 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
@@ -43,7 +43,7 @@ struct mtk_flow_entry {
 
 static const struct rhashtable_params mtk_flow_ht_params = {
 	.head_offset = offsetof(struct mtk_flow_entry, node),
-	.head_offset = offsetof(struct mtk_flow_entry, cookie),
+	.key_offset = offsetof(struct mtk_flow_entry, cookie),
 	.key_len = sizeof(unsigned long),
 	.automatic_shrinking = true,
 };
-- 
2.25.1



From wangqing at vivo.com  Thu Apr 15 10:40:05 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Thu, 15 Apr 2021 17:40:05 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSCBWM10gd2F0Y2hkb2c6IG10azogc3VwcG9ydCBwcmUtdGltZW91dCB3aGVuIHRoZSBiYXJrIGlycSBpcyBhdmFpbGFibGU=?=
In-Reply-To: <1e60551b-4961-91d6-1ea8-7e3b6becd385@roeck-us.net>
Message-ID: <AAgApgCdDjCicbWFGpPmeaor.3.1618479605424.Hmail.wangqing@vivo.com>


>On 4/14/21 4:48 AM, Wang Qing wrote:
>> Use the bark interrupt as the pretimeout notifier if available.
>> 
>> By default, the pretimeout notification shall occur one second earlier
>> than the timeout.
>> 
>> V2:
>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>> 
>> V3:
>> - Modify the pretimeout behavior, manually reset after the pretimeout
>> - is processed and wait until timeout.
>> 
>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>> ---
>>  drivers/watchdog/mtk_wdt.c | 62 ++++++++++++++++++++++++++++++++++++++++++----
>>  1 file changed, 57 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>> index 97ca993..7bef1e3
>> --- a/drivers/watchdog/mtk_wdt.c
>> +++ b/drivers/watchdog/mtk_wdt.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/reset-controller.h>
>>  #include <linux/types.h>
>>  #include <linux/watchdog.h>
>> +#include <linux/interrupt.h>
>>  
>>  #define WDT_MAX_TIMEOUT		31
>>  #define WDT_MIN_TIMEOUT		1
>> @@ -234,18 +235,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>  	int ret;
>>  
>> -	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
>> +	ret = mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout - wdt_dev->pretimeout);
>>  	if (ret < 0)
>>  		return ret;
>>  
>>  	reg = ioread32(wdt_base + WDT_MODE);
>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	reg &= ~WDT_MODE_IRQ_EN;
>> +	if (wdt_dev->pretimeout)
>> +		reg |= WDT_MODE_IRQ_EN;
>> +	else
>> +		reg &= ~WDT_MODE_IRQ_EN;
>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>>  	iowrite32(reg, wdt_base + WDT_MODE);
>>  
>>  	return 0;
>>  }
>>  
>> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
>> +				   unsigned int timeout)
>> +{
>> +	wdd->pretimeout = timeout;
>> +	return mtk_wdt_start(wdd);
>
>The watchdog is not necessarily active here.
>
>> +}
>> +
>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
>> +{
>> +	struct watchdog_device *wdd = arg;
>> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
>> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
>> +
>> +	watchdog_notify_pretimeout(wdd);
>> +	/*
>> +	 * Guaranteed to be reset when the timeout
>> +	 * expires under any situations
>> +	 */
>> +	mdelay(1000*wdd->pretimeout);
>
>That is not how this is supposed to work. The idea with a pretimeout is that the
>real watchdog reset will happen under all circumstances, and that executing
>the pretimeout (and changing some hardware registers) is not a prerequisite
>for the real timeout to happen. After all, the system could be stuck hard, with
>interrupts disabled.
>
>On top of that, just sleeping here while waiting for the real timeout and
>then resetting the system isn't the idea either. On a single core system this
>will just hang. On a multi-core system, who knows if userspace managed to ping
>the watchdog in the meantime.
>
>Unless there is a means to trigger the watchdog twice, without intervention,
>the first time generating an interrupt and the second time resetting the system,
>there is no way for this to work. I don't see how this chip really supports
>pretimeout. It seems that it supports either a hard reset or generating an
>interrupt on watchdog timeout, and there is only a single timeout.
>
>If you have a use case for generating an interrupt and resetting the system via
>software (ie panic) _instead_ of having it generate a hard reset, please feel
>free to submit a patch along that line, together with a description of its use
>case.
>
>Thanks,
>Guenter
>

Yes, as mentioned before, the behavior of WDT_MODE_IRQ_EN is use irq instead of
reset, so we must use WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN if like you said
"the first time generating an interrupt and the second time resetting the system" . 

The Dual mode is mentioned in the MTK datasheet:
In this mode, the watchdog will be AUTO-RESTART after interrupt is triggered. 
AP need to clear WDT_STA after receiving interrupt from TOPRGU, or system reset
will be triggered after watchdog timer expires.
Instructions for use?
Set wdt_en = 1'b1.
Set dual_mode = 1'b1.
Set wdt_irq = 1'b1.

We can use Dual mode to achieve pretimeout behavior, only in this way can we
get more information during pretimeout processing, instead of directly resetting.

Thanks,
Qing


From snawrocki at kernel.org  Thu Apr 15 10:45:26 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Thu, 15 Apr 2021 11:45:26 +0200
Subject: [PATCH 1/2] i2c: s3c2410: simplify getting of_device_id match data
In-Reply-To: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
References: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
Message-ID: <acb1c39f-8098-1457-c996-05f647bfa25f@kernel.org>


On 15.04.2021 11:38, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller.
> 
> Signed-off-by: Krzysztof Kozlowski<krzysztof.kozlowski at canonical.com>

Reviewed-by: Sylwester Nawrocki <snawrocki at kernel.org>


From snawrocki at kernel.org  Thu Apr 15 10:48:08 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Thu, 15 Apr 2021 11:48:08 +0200
Subject: [PATCH 1/3] spi: s3c64xx: simplify getting of_device_id match data
In-Reply-To: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
Message-ID: <74b0de2c-1ef0-1dbe-318f-dd238d81c0ce@kernel.org>



On 14.04.2021 22:33, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller and to
> remove the of_device_id table forward declaration.
> 
> Signed-off-by: Krzysztof Kozlowski<krzysztof.kozlowski at canonical.com>

Reviewed-by: Sylwester Nawrocki <snawrocki at kernel.org>


From eric.auger at redhat.com  Thu Apr 15 10:48:57 2021
From: eric.auger at redhat.com (Auger Eric)
Date: Thu, 15 Apr 2021 11:48:57 +0200
Subject: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
In-Reply-To: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <2e58d4e6-83fd-b5cf-b2db-7575cb197058@redhat.com>

Hi Shameer,

+ Jean-Philippe


On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> RFC v1 --> v2:
> ?- Added a generic interface for IOMMU drivers to retrieve all the 
> ? ?RMR info associated with a given IOMMU.
> ?- SMMUv3 driver gets the RMR list during probe() and installs
> ?? bypass STEs for all the SIDs in the RMR list. This is to keep
>  ? the ongoing traffic alive(if any) during SMMUv3 reset. This is
>    based on the suggestions received for v1 to take care of the
>    EFI framebuffer use case. Only sanity tested for now.
> ?- During the probe/attach device, SMMUv3 driver reserves any
> ? ?RMR region associated with the device such that there is a unity
> ? ?mapping for them in SMMU.
> ---? ??
> 
> The series adds support to IORT RMR nodes specified in IORT
> Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
> ranges that are used by endpoints and require a unity mapping
> in SMMU.
> 
> We have faced issues with 3408iMR RAID controller cards which
> fail to boot when SMMU is enabled. This is because these controllers
> make use of host memory for various caching related purposes and when
> SMMU is enabled the iMR firmware fails to access these memory regions
> as there is no mapping for them. IORT RMR provides a way for UEFI to
> describe and report these memory regions so that the kernel can make
> a unity mapping for these in SMMU.
> 
> RFC because, Patch #1 is to update the actbl2.h and should be done
> through acpica update. I have send out a pull request[1] for that.
> 
> Tests:
> 
> With a UEFI, that reports the RMR for the dev,
> ....
> [16F0h 5872   1]                         Type : 06
> [16F1h 5873   2]                       Length : 007C
> [16F3h 5875   1]                     Revision : 00
> [1038h 0056   2]                     Reserved : 00000000
> [1038h 0056   2]                   Identifier : 00000000
> [16F8h 5880   4]                Mapping Count : 00000001
> [16FCh 5884   4]               Mapping Offset : 00000040
> 
> [1700h 5888   4]    Number of RMR Descriptors : 00000002
> [1704h 5892   4]        RMR Descriptor Offset : 00000018
> 
> [1708h 5896   8]          Base Address of RMR : 0000E6400000
> [1710h 5904   8]                Length of RMR : 000000100000
> [1718h 5912   4]                     Reserved : 00000000
> 
> [171Ch 5916   8]          Base Address of RMR : 0000000027B00000
> [1724h 5924   8]                Length of RMR : 0000000000C00000
> [172Ch 5932   4]                     Reserved : 00000000
> 
> [1730h 5936   4]                   Input base : 00000000
> [1734h 5940   4]                     ID Count : 00000001
> [1738h 5944   4]                  Output Base : 00000003
> [173Ch 5948   4]             Output Reference : 00000064
> [1740h 5952   4]        Flags (decoded below) : 00000001
>                                Single Mapping : 1

Following Jean-Philippe's suggestion I have used your series for nested
stage SMMUv3 integration, ie. to simplify the MSI nested stage mapping.

Host allocates hIOVA -> physical doorbell (pDB) as it normally does for
VFIO device passthrough. IOVA Range is 0x8000000 - 0x8100000.

I expose this MIS IOVA range to the guest as an RMR and as a result
guest has a flat mapping for this range. As the physical device is
programmed with hIOVA we have the following mapping:

IOVA            IPA          PA
hIOVA   ->     hIOVA     ->  pDB
        S1               s2

This works.

The only weird thing is that I need to expose 256 RMRs due to the
'Single Mapping' mandatory flag. I need to have 1 RMR per potential SID
on the bus.

I will post a new version of SMMUv3 nested stage soon for people to test
& compare. Obviously this removes a bunch of code on both SMMU/VFIO and
QEMU code so I think this solution looks better overall.

Thanks

Eric
> ...
> 
> Without the series the RAID controller initialization fails as
> below,
> 
> ...
> [   12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache        : Yes   
> [   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0                                                                         
> [   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state 
> [  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready                                    
> [  106.695186] megaraid_sas 0000:03:00.0: System Register set:                  
> [  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.                                                                   
> [  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407      
> estuary:/$
> 
> With the series, now the kernel has direct mapping for the dev as
> below,
> 
> estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions                      
> 0x0000000008000000 0x00000000080fffff msi                                       
> 0x0000000027b00000 0x00000000286fffff direct                                    
> 0x00000000e6400000 0x00000000e64fffff direct                                    
> estuary:/$
> 
> ....
> [   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
> [   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0      max_lds: 32                                                                      
> [   12.746628] megaraid_sas 0000:03:00.0: controller type       : iMR(0MB)      
> [   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  : Enabled                                                                               
> [   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes           
> [   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes           
> [   12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs                                                                 
> [   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support     : Yes   
> [   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support    : No    
> [   12.819179] megaraid_sas 0000:03:00.0: NVME page size        : (4096)        
> [   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000                                                    
> [   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done                     
> [   12.873932] megaraid_sas 0000:03:00.0: pci id                : (0x1000)/(0x0017)/(0x19e5)/(0xd213)                                                           
> [   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no            
> [   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no            
> [   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     : enabled       
> 
> RAID controller init is now success and can detect the drives
> attached as well.
> 
> Thanks,
> Shameer
> 
> [0]. https://developer.arm.com/documentation/den0049/latest/
> [1]. https://github.com/acpica/acpica/pull/638
> 
> Shameer Kolothum (8):
>   ACPICA: IORT: Update for revision E
>   ACPI/IORT: Add support for RMR node parsing
>   iommu/dma: Introduce generic helper to retrieve RMR info
>   ACPI/IORT: Add RMR memory regions reservation helper
>   iommu/arm-smmu-v3: Introduce strtab init helper
>   iommu/arm-smmu-v3: Add bypass flag to?arm_smmu_write_strtab_ent()
>   iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
>   iommu/arm-smmu-v3: Reserve any RMR regions associated with a?dev
> 
>  drivers/acpi/arm64/iort.c                   | 182 +++++++++++++++++++-
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |   2 +
>  drivers/iommu/dma-iommu.c                   |  39 +++++
>  include/acpi/actbl2.h                       |  25 ++-
>  include/linux/acpi_iort.h                   |   6 +
>  include/linux/dma-iommu.h                   |   7 +
>  include/linux/iommu.h                       |  16 ++
>  8 files changed, 367 insertions(+), 22 deletions(-)
> 



From suzuki.poulose at arm.com  Thu Apr 15 10:49:30 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 15 Apr 2021 10:49:30 +0100
Subject: [PATCH] coresight: add support to enable more coresight paths
In-Reply-To: <1618479207-22243-1-git-send-email-taozha@codeaurora.org>
References: <1618479207-22243-1-git-send-email-taozha@codeaurora.org>
Message-ID: <3c280b36-82ec-7ffc-2ad1-4c901899ffe2@arm.com>

Hi

On 15/04/2021 10:33, Tao Zhang wrote:
> Current coresight implementation only supports enabling source
> ETMs or STM. This patch adds support to enable more kinds of
> coresight source to sink paths. We build a path from source to
> sink when any source is enabled and store it in a list. When the
> source is disabled, we fetch the corresponding path from the list
> and decrement the refcount on each device in the path. The device
> is disabled if the refcount reaches zero. Don't store path to
> coresight data structure of source to avoid unnecessary change to
> ABI.
> Since some targets may have coresight sources other than STM and
> ETMs, we need to add this change to support these coresight
> devices.

While I am not against the patch, I would like to see why this change is
needed. Which compnents are we talking about , other than STM / ETM ?
Where is the "device" support code ? Without a legitimate user, we 
cannot add this change in.

Some other comments below.

> 
> Signed-off-by: Satyajit Desai <sadesai at codeaurora.org>
> Signed-off-by: Rama Aparna Mallavarapu <aparnam at codeaurora.org>
> Signed-off-by: Mulu He <muluhe at codeaurora.org>
> Signed-off-by: Tingwei Zhang <tingwei at codeaurora.org>
> Signed-off-by: Tao Zhang <taozha at codeaurora.org>
> ---
>   drivers/hwtracing/coresight/coresight-core.c | 101 +++++++++++++++------------
>   1 file changed, 56 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 4ba801d..7dfadb6 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -35,18 +35,16 @@ struct coresight_node {
>   };
>   
>   /*
> - * When operating Coresight drivers from the sysFS interface, only a single
> - * path can exist from a tracer (associated to a CPU) to a sink.
> + * struct coresight_path - path from source to sink
> + * @path:	Address of path list.
> + * @link:	hook to the list.
>    */
> -static DEFINE_PER_CPU(struct list_head *, tracer_path);
> +struct coresight_path {
> +	struct list_head *path;
> +	struct list_head link;
> +};
>   
> -/*
> - * As of this writing only a single STM can be found in CS topologies.  Since
> - * there is no way to know if we'll ever see more and what kind of
> - * configuration they will enact, for the time being only define a single path
> - * for STM.
> - */
> -static struct list_head *stm_path;
> +static LIST_HEAD(cs_active_paths);
>   
>   /*
>    * When losing synchronisation a new barrier packet needs to be inserted at the
> @@ -326,7 +324,7 @@ static void coresight_disable_sink(struct coresight_device *csdev)
>   	if (ret)
>   		return;
>   	coresight_control_assoc_ectdev(csdev, false);
> -	csdev->enable = false;
> +	csdev->activated = false;
>   }
>   
>   static int coresight_enable_link(struct coresight_device *csdev,
> @@ -562,6 +560,20 @@ int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data)
>   	goto out;
>   }
>   
> +static struct coresight_device *coresight_get_source(struct list_head *path)
> +{
> +	struct coresight_device *csdev;
> +
> +	if (!path)
> +		return NULL;
> +
> +	csdev = list_first_entry(path, struct coresight_node, link)->csdev;
> +	if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
> +		return NULL;
> +
> +	return csdev;
> +}
> +
>   struct coresight_device *coresight_get_sink(struct list_head *path)
>   {
>   	struct coresight_device *csdev;
> @@ -1047,9 +1059,23 @@ static int coresight_validate_source(struct coresight_device *csdev,
>   	return 0;
>   }
>   
> +static int coresight_store_path(struct list_head *path)
> +{
> +	struct coresight_path *node;
> +
> +	node = kzalloc(sizeof(struct coresight_path), GFP_KERNEL);

Have you run this with all the "DEBUG" whistles turned on ? This could 
be problematic when called from a context where you are not allowed to 
sleep. e.g, perf enable call back.

> +	if (!node)
> +		return -ENOMEM;
> +
> +	node->path = path;
> +	list_add(&node->link, &cs_active_paths);
> +
> +	return 0;
> +}
> +
>   int coresight_enable(struct coresight_device *csdev)
>   {
> -	int cpu, ret = 0;
> +	int ret = 0;
>   	struct coresight_device *sink;
>   	struct list_head *path;
>   	enum coresight_dev_subtype_source subtype;
> @@ -1094,25 +1120,9 @@ int coresight_enable(struct coresight_device *csdev)
>   	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:
> -		stm_path = path;
> -		break;
> -	default:
> -		/* We can't be here */
> -		break;
> -	}
> +	ret = coresight_store_path(path);
> +	if (ret)
> +		goto err_source;
>   
>   out:
>   	mutex_unlock(&coresight_mutex);
> @@ -1129,8 +1139,11 @@ EXPORT_SYMBOL_GPL(coresight_enable);
>   
>   void coresight_disable(struct coresight_device *csdev)
>   {
> -	int cpu, ret;
> +	int  ret;
>   	struct list_head *path = NULL;
> +	struct coresight_path *cspath = NULL;
> +	struct coresight_path *cspath_next = NULL;
> +	struct coresight_device *src_csdev = NULL;
>   
>   	mutex_lock(&coresight_mutex);
>   
> @@ -1141,20 +1154,18 @@ void coresight_disable(struct coresight_device *csdev)
>   	if (!csdev->enable || !coresight_disable_source(csdev))
>   		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:
> -		path = stm_path;
> -		stm_path = NULL;
> -		break;
> -	default:
> -		/* We can't be here */
> -		break;

--> Cut here <---

> +	list_for_each_entry_safe(cspath, cspath_next, &cs_active_paths, link) {
> +		src_csdev = coresight_get_source(cspath->path);
> +		if (!src_csdev)
> +			continue;
> +		if (src_csdev == csdev) {
> +			path = cspath->path;
> +			list_del(&cspath->link);
> +			kfree(cspath);
> +		}
>   	}

Why not add the above to coresight_{retrieve/remove/}_active_path(csdev) ?



Suzuki


From snawrocki at kernel.org  Thu Apr 15 10:53:36 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Thu, 15 Apr 2021 11:53:36 +0200
Subject: [PATCH 2/3] spi: s3c64xx: correct kerneldoc of
 s3c64xx_spi_port_config
In-Reply-To: <20210414203343.203119-2-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
 <20210414203343.203119-2-krzysztof.kozlowski@canonical.com>
Message-ID: <d51a4940-737a-7667-4223-6a5c92133c38@kernel.org>


On 14.04.2021 22:33, Krzysztof Kozlowski wrote:
> Correct the name of s3c64xx_spi_port_config structure in kerneldoc:
> 
>    drivers/spi/spi-s3c64xx.c:154: warning:
>      expecting prototype for struct s3c64xx_spi_info. Prototype was for struct s3c64xx_spi_port_config instead
> 
> Signed-off-by: Krzysztof Kozlowski<krzysztof.kozlowski at canonical.com>


Reviewed-by: Sylwester Nawrocki <snawrocki at kernel.org>


From snawrocki at kernel.org  Thu Apr 15 10:54:05 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Thu, 15 Apr 2021 11:54:05 +0200
Subject: [PATCH 3/3] spi: s3c64xx: constify driver/match data
In-Reply-To: <20210414203343.203119-3-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
 <20210414203343.203119-3-krzysztof.kozlowski@canonical.com>
Message-ID: <90b3fced-f06e-913c-1bc1-08b482630b21@kernel.org>


On 14.04.2021 22:33, Krzysztof Kozlowski wrote:
> The match data (struct s3c64xx_spi_port_config) stored in of_device_id
> and platform_device_id tables is not modified by the driver and can be
> handled entirely in a const-way to increase the code safety.
> 
> Signed-off-by: Krzysztof Kozlowski<krzysztof.kozlowski at canonical.com>

Reviewed-by: Sylwester Nawrocki <snawrocki at kernel.org>


From frank-w at public-files.de  Thu Apr 15 11:05:26 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Thu, 15 Apr 2021 12:05:26 +0200
Subject: [PATCH net-next] net: ethernet: mediatek: fix typo in offload code
In-Reply-To: <20210415094005.2673-1-dqfext@gmail.com>
References: <20210415094005.2673-1-dqfext@gmail.com>
Message-ID: <86DA3F5B-32B2-446B-B83D-AFDC5EE6BF53@public-files.de>

Am 15. April 2021 11:40:05 MESZ schrieb DENG Qingfang <dqfext at gmail.com>:
>.key_offset was assigned to .head_offset instead. Fix the typo.
>
>Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading
>support")
>Signed-off-by: DENG Qingfang <dqfext at gmail.com>

Thanks for posting the fix,but imho commit-message is not good.

Issue were traffic problems after a while with increased ping times if flow offload is active.

It turns out that key_offset with cookie is needed in rhashtable_params and head_offset was defined twice.
regards Frank


From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:29 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:29 +0200
Subject: [PATCH 05/13] ARM: dts: stm32: update pinctrl node name on STM32 MCU
 to prevent warnings
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-6-alexandre.torgue@foss.st.com>

Update node name to avoid a DT schema validation issue seen with
"make dtbs_check W=1". It also cleans picntrl dtsi files for f429/f469 MCU.

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
index 4774163af54b..155d9ffacc83 100644
--- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
@@ -45,7 +45,7 @@
 
 / {
 	soc {
-		pinctrl: pin-controller {
+		pinctrl: pin-controller at 40020000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0 0x40020000 0x3000>;
diff --git a/arch/arm/boot/dts/stm32f429-pinctrl.dtsi b/arch/arm/boot/dts/stm32f429-pinctrl.dtsi
index 3e7a17d9112e..e10d7a1f3207 100644
--- a/arch/arm/boot/dts/stm32f429-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f429-pinctrl.dtsi
@@ -42,54 +42,50 @@
 
 #include "stm32f4-pinctrl.dtsi"
 
-/ {
-	soc {
-		pinctrl: pin-controller {
-			compatible = "st,stm32f429-pinctrl";
+&pinctrl {
+	compatible = "st,stm32f429-pinctrl";
 
-			gpioa: gpio at 40020000 {
-				gpio-ranges = <&pinctrl 0 0 16>;
-			};
+	gpioa: gpio at 40020000 {
+		gpio-ranges = <&pinctrl 0 0 16>;
+	};
 
-			gpiob: gpio at 40020400 {
-				gpio-ranges = <&pinctrl 0 16 16>;
-			};
+	gpiob: gpio at 40020400 {
+		gpio-ranges = <&pinctrl 0 16 16>;
+	};
 
-			gpioc: gpio at 40020800 {
-				gpio-ranges = <&pinctrl 0 32 16>;
-			};
+	gpioc: gpio at 40020800 {
+		gpio-ranges = <&pinctrl 0 32 16>;
+	};
 
-			gpiod: gpio at 40020c00 {
-				gpio-ranges = <&pinctrl 0 48 16>;
-			};
+	gpiod: gpio at 40020c00 {
+		gpio-ranges = <&pinctrl 0 48 16>;
+	};
 
-			gpioe: gpio at 40021000 {
-				gpio-ranges = <&pinctrl 0 64 16>;
-			};
+	gpioe: gpio at 40021000 {
+		gpio-ranges = <&pinctrl 0 64 16>;
+	};
 
-			gpiof: gpio at 40021400 {
-				gpio-ranges = <&pinctrl 0 80 16>;
-			};
+	gpiof: gpio at 40021400 {
+		gpio-ranges = <&pinctrl 0 80 16>;
+	};
 
-			gpiog: gpio at 40021800 {
-				gpio-ranges = <&pinctrl 0 96 16>;
-			};
+	gpiog: gpio at 40021800 {
+		gpio-ranges = <&pinctrl 0 96 16>;
+	};
 
-			gpioh: gpio at 40021c00 {
-				gpio-ranges = <&pinctrl 0 112 16>;
-			};
+	gpioh: gpio at 40021c00 {
+		gpio-ranges = <&pinctrl 0 112 16>;
+	};
 
-			gpioi: gpio at 40022000 {
-				gpio-ranges = <&pinctrl 0 128 16>;
-			};
+	gpioi: gpio at 40022000 {
+		gpio-ranges = <&pinctrl 0 128 16>;
+	};
 
-			gpioj: gpio at 40022400 {
-				gpio-ranges = <&pinctrl 0 144 16>;
-			};
+	gpioj: gpio at 40022400 {
+		gpio-ranges = <&pinctrl 0 144 16>;
+	};
 
-			gpiok: gpio at 40022800 {
-				gpio-ranges = <&pinctrl 0 160 8>;
-			};
-		};
+	gpiok: gpio at 40022800 {
+		gpio-ranges = <&pinctrl 0 160 8>;
 	};
 };
diff --git a/arch/arm/boot/dts/stm32f469-pinctrl.dtsi b/arch/arm/boot/dts/stm32f469-pinctrl.dtsi
index fff542662eea..6bf60263dff8 100644
--- a/arch/arm/boot/dts/stm32f469-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f469-pinctrl.dtsi
@@ -42,55 +42,51 @@
 
 #include "stm32f4-pinctrl.dtsi"
 
-/ {
-	soc {
-		pinctrl: pin-controller {
-			compatible = "st,stm32f469-pinctrl";
+&pinctrl {
+	compatible = "st,stm32f469-pinctrl";
 
-			gpioa: gpio at 40020000 {
-				gpio-ranges = <&pinctrl 0 0 16>;
-			};
+	gpioa: gpio at 40020000 {
+		gpio-ranges = <&pinctrl 0 0 16>;
+	};
 
-			gpiob: gpio at 40020400 {
-				gpio-ranges = <&pinctrl 0 16 16>;
-			};
+	gpiob: gpio at 40020400 {
+		gpio-ranges = <&pinctrl 0 16 16>;
+	};
 
-			gpioc: gpio at 40020800 {
-				gpio-ranges = <&pinctrl 0 32 16>;
-			};
+	gpioc: gpio at 40020800 {
+		gpio-ranges = <&pinctrl 0 32 16>;
+	};
 
-			gpiod: gpio at 40020c00 {
-				gpio-ranges = <&pinctrl 0 48 16>;
-			};
+	gpiod: gpio at 40020c00 {
+		gpio-ranges = <&pinctrl 0 48 16>;
+	};
 
-			gpioe: gpio at 40021000 {
-				gpio-ranges = <&pinctrl 0 64 16>;
-			};
+	gpioe: gpio at 40021000 {
+		gpio-ranges = <&pinctrl 0 64 16>;
+	};
 
-			gpiof: gpio at 40021400 {
-				gpio-ranges = <&pinctrl 0 80 16>;
-			};
+	gpiof: gpio at 40021400 {
+		gpio-ranges = <&pinctrl 0 80 16>;
+	};
 
-			gpiog: gpio at 40021800 {
-				gpio-ranges = <&pinctrl 0 96 16>;
-			};
+	gpiog: gpio at 40021800 {
+		gpio-ranges = <&pinctrl 0 96 16>;
+	};
 
-			gpioh: gpio at 40021c00 {
-				gpio-ranges = <&pinctrl 0 112 16>;
-			};
+	gpioh: gpio at 40021c00 {
+		gpio-ranges = <&pinctrl 0 112 16>;
+	};
 
-			gpioi: gpio at 40022000 {
-				gpio-ranges = <&pinctrl 0 128 16>;
-			};
+	gpioi: gpio at 40022000 {
+		gpio-ranges = <&pinctrl 0 128 16>;
+	};
 
-			gpioj: gpio at 40022400 {
-				gpio-ranges = <&pinctrl 0 144 6>,
-					      <&pinctrl 12 156 4>;
-			};
+	gpioj: gpio at 40022400 {
+		gpio-ranges = <&pinctrl 0 144 6>,
+			      <&pinctrl 12 156 4>;
+	};
 
-			gpiok: gpio at 40022800 {
-				gpio-ranges = <&pinctrl 3 163 5>;
-			};
-		};
+	gpiok: gpio at 40022800 {
+		gpio-ranges = <&pinctrl 3 163 5>;
 	};
 };
diff --git a/arch/arm/boot/dts/stm32f7-pinctrl.dtsi b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
index fe4cfda72a47..1cf8a23c2644 100644
--- a/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
@@ -9,7 +9,7 @@
 
 / {
 	soc {
-		pinctrl: pin-controller {
+		pinctrl: pin-controller at 40020000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges = <0 0x40020000 0x3000>;
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:27 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:27 +0200
Subject: [PATCH 03/13] ARM: dts: stm32: fix timer nodes on STM32 MCU to
 prevent warnings
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-4-alexandre.torgue@foss.st.com>

Prevent warning seen with "make dtbs_check W=1" command:

Warning (avoid_unnecessary_addr_size): /soc/timers at 40001c00: unnecessary
address-cells/size-cells without "ranges" or child "reg" property

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 41e0087bdbf9..8748d5850298 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -283,8 +283,6 @@
 		};
 
 		timers13: timers at 40001c00 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40001C00 0x400>;
 			clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM13)>;
@@ -299,8 +297,6 @@
 		};
 
 		timers14: timers at 40002000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40002000 0x400>;
 			clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM14)>;
@@ -633,8 +629,6 @@
 		};
 
 		timers10: timers at 40014400 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40014400 0x400>;
 			clocks = <&rcc 0 STM32F4_APB2_CLOCK(TIM10)>;
@@ -649,8 +643,6 @@
 		};
 
 		timers11: timers at 40014800 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40014800 0x400>;
 			clocks = <&rcc 0 STM32F4_APB2_CLOCK(TIM11)>;
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index e1df603fc981..72c1b76684b6 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -265,8 +265,6 @@
 		};
 
 		timers13: timers at 40001c00 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40001C00 0x400>;
 			clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM13)>;
@@ -281,8 +279,6 @@
 		};
 
 		timers14: timers at 40002000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40002000 0x400>;
 			clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM14)>;
@@ -531,8 +527,6 @@
 		};
 
 		timers10: timers at 40014400 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40014400 0x400>;
 			clocks = <&rcc 0 STM32F7_APB2_CLOCK(TIM10)>;
@@ -547,8 +541,6 @@
 		};
 
 		timers11: timers at 40014800 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-timers";
 			reg = <0x40014800 0x400>;
 			clocks = <&rcc 0 STM32F7_APB2_CLOCK(TIM11)>;
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index 05ecdf9ff03a..6e42ca2dada2 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -485,8 +485,6 @@
 		};
 
 		lptimer4: timer at 58002c00 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-lptimer";
 			reg = <0x58002c00 0x400>;
 			clocks = <&rcc LPTIM4_CK>;
@@ -501,8 +499,6 @@
 		};
 
 		lptimer5: timer at 58003000 {
-			#address-cells = <1>;
-			#size-cells = <0>;
 			compatible = "st,stm32-lptimer";
 			reg = <0x58003000 0x400>;
 			clocks = <&rcc LPTIM5_CK>;
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:26 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:26 +0200
Subject: [PATCH 02/13] ARM: dts: stm32: fix RCC node name on stm32f429 MCU
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-3-alexandre.torgue@foss.st.com>

This prevent warning observed with "make dtbs_check W=1"

Warning (simple_bus_reg): /soc/rcc at 40023810: simple-bus unit address format
error, expected "40023800"

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index f6530d724d00..41e0087bdbf9 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -709,7 +709,7 @@
 			status = "disabled";
 		};
 
-		rcc: rcc at 40023810 {
+		rcc: rcc at 40023800 {
 			#reset-cells = <1>;
 			#clock-cells = <2>;
 			compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:25 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:25 +0200
Subject: [PATCH 01/13] ARM: dts: stm32: fix gpio-keys node on STM32 MCU boards
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-2-alexandre.torgue@foss.st.com>

Fix following warning observed with "make dtbs_check W=1" command.
It concerns f429 eval and disco boards, f769 disco board.

Warning (unit_address_vs_reg): /gpio_keys/button at 0: node has a unit name,
but no reg or ranges property

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 7e10ae744c9d..9ac1ffe53413 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -119,17 +119,15 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
 		autorepeat;
-		button at 0 {
+		button-0 {
 			label = "Wake up";
 			linux,code = <KEY_WAKEUP>;
 			gpios = <&gpioa 0 0>;
 		};
-		button at 1 {
+		button-1 {
 			label = "Tamper";
 			linux,code = <KEY_RESTART>;
 			gpios = <&gpioc 13 0>;
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index ca8c192449ee..327613fd9666 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -81,12 +81,10 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
 		autorepeat;
-		button at 0 {
+		button-0 {
 			label = "Wake up";
 			linux,code = <KEY_WAKEUP>;
 			gpios = <&gpioc 13 0>;
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
index 3dc068b91ca1..075ac57d0bf4 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -81,12 +81,10 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
 		autorepeat;
-		button at 0 {
+		button-0 {
 			label = "User";
 			linux,code = <KEY_HOME>;
 			gpios = <&gpioa 0 0>;
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 2e1b3bbbe4b5..8c982ae79f43 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -104,12 +104,10 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
 		autorepeat;
-		button at 0 {
+		button-0 {
 			label = "User";
 			linux,code = <KEY_WAKEUP>;
 			gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
index 0ce7fbc20fa4..be943b701980 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -75,12 +75,10 @@
 		};
 	};
 
-	gpio_keys {
+	gpio-keys {
 		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
 		autorepeat;
-		button at 0 {
+		button-0 {
 			label = "User";
 			linux,code = <KEY_HOME>;
 			gpios = <&gpioa 0 GPIO_ACTIVE_HIGH>;
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:24 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:24 +0200
Subject: [PATCH 00/13] ARM: dts: stm32: fix "make dtbs_check W=1" round1
Message-ID: <20210415101037.1465-1-alexandre.torgue@foss.st.com>

Hi,

First round to cleanup warnings and yaml validation issues seen running
"make dtbs_check W=1" command for STM32 platform. It concerns all SoC
(MCU: f429/429, f746/769, h743, MPU) and all boards (ST reference boards,
DH, Engicam, LxA ...).

Main fixes are done in device tree files but some imply a change in yaml
dt-bindings file.

regards
Alex

Alexandre Torgue (13):
  ARM: dts: stm32: fix gpio-keys node on STM32 MCU boards
  ARM: dts: stm32: fix RCC node name on stm32f429 MCU
  ARM: dts: stm32: fix timer nodes on STM32 MCU to prevent warnings
  dt-bindings: mfd: stm32-timers: remove #address/size cells from
    required properties
  ARM: dts: stm32: update pinctrl node name on STM32 MCU to prevent
    warnings
  ARM: dts: stm32: fix i2c node name on stm32f746 to prevent warnings
  ARM: dts: stm32: move stmmac axi config in ethernet node on stm32mp15
  dt-bindings: net: document ptp_ref clk in dwmac
  ARM: dts: stm32: fix stpmic node for stm32mp1 boards
  dt-bindings: mfd: add vref_ddr-supply to st,stpmic1 yaml
  ARM: dts: stm32: fix LTDC port node on STM32 MCU ad MPU
  ARM: dts: stm32: fix DSI port node on STM32MP15
  ARM: dts: stm32: fix ltdc pinctrl on microdev2.0-of7

 .../bindings/mfd/st,stm32-timers.yaml         |  2 -
 .../devicetree/bindings/mfd/st,stpmic1.yaml   |  2 +-
 .../devicetree/bindings/net/snps,dwmac.yaml   |  4 +-
 .../devicetree/bindings/net/stm32-dwmac.yaml  |  6 +-
 arch/arm/boot/dts/stm32429i-eval.dts          |  8 +-
 arch/arm/boot/dts/stm32746g-eval.dts          |  6 +-
 arch/arm/boot/dts/stm32f4-pinctrl.dtsi        |  2 +-
 arch/arm/boot/dts/stm32f429-disco.dts         |  6 +-
 arch/arm/boot/dts/stm32f429-pinctrl.dtsi      | 72 +++++++++---------
 arch/arm/boot/dts/stm32f429.dtsi              | 10 +--
 arch/arm/boot/dts/stm32f469-disco.dts         |  8 +-
 arch/arm/boot/dts/stm32f469-pinctrl.dtsi      | 74 +++++++++----------
 arch/arm/boot/dts/stm32f7-pinctrl.dtsi        |  2 +-
 arch/arm/boot/dts/stm32f746.dtsi              | 12 +--
 arch/arm/boot/dts/stm32f769-disco.dts         |  6 +-
 arch/arm/boot/dts/stm32h743.dtsi              |  4 -
 arch/arm/boot/dts/stm32mp151.dtsi             | 16 ++--
 arch/arm/boot/dts/stm32mp157.dtsi             |  2 -
 arch/arm/boot/dts/stm32mp157a-dk1.dts         |  8 ++
 ...157a-microgea-stm32mp1-microdev2.0-of7.dts |  5 +-
 arch/arm/boot/dts/stm32mp157a-stinger96.dtsi  |  7 +-
 arch/arm/boot/dts/stm32mp157c-dk2.dts         | 12 ++-
 arch/arm/boot/dts/stm32mp157c-ev1.dts         |  5 +-
 arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts     |  3 +-
 .../arm/boot/dts/stm32mp157c-odyssey-som.dtsi |  5 +-
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi  |  5 +-
 .../boot/dts/stm32mp15xx-dhcor-avenger96.dtsi |  6 +-
 arch/arm/boot/dts/stm32mp15xx-dkx.dtsi        |  7 --
 arch/arm/boot/dts/stm32mp15xx-osd32.dtsi      |  7 +-
 29 files changed, 130 insertions(+), 182 deletions(-)

-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:28 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:28 +0200
Subject: [PATCH 04/13] dt-bindings: mfd: stm32-timers: remove #address/size
 cells from required properties
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-5-alexandre.torgue@foss.st.com>

address-cells and size-cells can't be declared as "required" properties
as they are not needed if subnodes don't have a "reg" entry.

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
index 0f16c8864a87..dace35362a7a 100644
--- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
@@ -119,8 +119,6 @@ patternProperties:
       - compatible
 
 required:
-  - "#address-cells"
-  - "#size-cells"
   - compatible
   - reg
   - clocks
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:30 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:30 +0200
Subject: [PATCH 06/13] ARM: dts: stm32: fix i2c node name on stm32f746 to
 prevent warnings
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-7-alexandre.torgue@foss.st.com>

Replace upper case by lower case in i2c nodes name.

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 72c1b76684b6..014b416f57e6 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -360,9 +360,9 @@
 			status = "disabled";
 		};
 
-		i2c3: i2c at 40005C00 {
+		i2c3: i2c at 40005c00 {
 			compatible = "st,stm32f7-i2c";
-			reg = <0x40005C00 0x400>;
+			reg = <0x40005c00 0x400>;
 			interrupts = <72>,
 				     <73>;
 			resets = <&rcc STM32F7_APB1_RESET(I2C3)>;
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:31 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:31 +0200
Subject: [PATCH 07/13] ARM: dts: stm32: move stmmac axi config in ethernet
 node on stm32mp15
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-8-alexandre.torgue@foss.st.com>

It fixes the following warning seen running "make dtbs_check W=1"

Warning (simple_bus_reg): /soc/stmmac-axi-config: missing or empty
reg/ranges property

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index fb80d53e6be2..8aa87cb86821 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1409,12 +1409,6 @@
 			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>;
@@ -1440,6 +1434,12 @@
 			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 {
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:33 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:33 +0200
Subject: [PATCH 09/13] ARM: dts: stm32: fix stpmic node for stm32mp1 boards
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-10-alexandre.torgue@foss.st.com>

On some STM32 MP15 boards, stpmic node is not correct which generates
warnings running "make dtbs_check W=1" command. Issues are:

-"regulator-active-discharge" is not a boolean but an uint32.
-"regulator-over-current-protection" is not a valid entry for vref_ddr.
-LDO4 has a fixed voltage (3v3) so min/max entries are not allowed.

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32mp157a-stinger96.dtsi b/arch/arm/boot/dts/stm32mp157a-stinger96.dtsi
index 113c48b2ef93..a4b14ef3caee 100644
--- a/arch/arm/boot/dts/stm32mp157a-stinger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp157a-stinger96.dtsi
@@ -184,8 +184,6 @@
 
 			vdd_usb: ldo4 {
 				regulator-name = "vdd_usb";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
 				interrupts = <IT_CURLIM_LDO4 0>;
 			};
 
@@ -208,7 +206,6 @@
 			vref_ddr: vref_ddr {
 				regulator-name = "vref_ddr";
 				regulator-always-on;
-				regulator-over-current-protection;
 			};
 
 			bst_out: boost {
@@ -219,13 +216,13 @@
 			vbus_otg: pwr_sw1 {
 				regulator-name = "vbus_otg";
 				interrupts = <IT_OCP_OTG 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			};
 
 			vbus_sw: pwr_sw2 {
 				regulator-name = "vbus_sw";
 				interrupts = <IT_OCP_SWOUT 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
index 6cf49a0a9e69..0c0b66788ea1 100644
--- a/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
@@ -173,8 +173,6 @@
 
 			vdd_usb: ldo4 {
 				regulator-name = "vdd_usb";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
 				interrupts = <IT_CURLIM_LDO4 0>;
 			};
 
@@ -197,7 +195,6 @@
 			vref_ddr: vref_ddr {
 				regulator-name = "vref_ddr";
 				regulator-always-on;
-				regulator-over-current-protection;
 			};
 
 			 bst_out: boost {
@@ -213,7 +210,7 @@
 			 vbus_sw: pwr_sw2 {
 				regulator-name = "vbus_sw";
 				interrupts = <IT_OCP_SWOUT 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			 };
 		};
 
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
index 272a1a67a9ad..769fcf74685a 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
@@ -327,8 +327,6 @@
 
 			vdd_usb: ldo4 {
 				regulator-name = "vdd_usb";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
 				interrupts = <IT_CURLIM_LDO4 0>;
 			};
 
@@ -350,7 +348,6 @@
 			vref_ddr: vref_ddr {
 				regulator-name = "vref_ddr";
 				regulator-always-on;
-				regulator-over-current-protection;
 			};
 
 			bst_out: boost {
@@ -366,7 +363,7 @@
 			vbus_sw: pwr_sw2 {
 				regulator-name = "vbus_sw";
 				interrupts = <IT_OCP_SWOUT 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/stm32mp15xx-osd32.dtsi b/arch/arm/boot/dts/stm32mp15xx-osd32.dtsi
index 713485a95795..6706d8311a66 100644
--- a/arch/arm/boot/dts/stm32mp15xx-osd32.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-osd32.dtsi
@@ -146,8 +146,6 @@
 
 			vdd_usb: ldo4 {
 				regulator-name = "vdd_usb";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
 				interrupts = <IT_CURLIM_LDO4 0>;
 			};
 
@@ -171,7 +169,6 @@
 			vref_ddr: vref_ddr {
 				regulator-name = "vref_ddr";
 				regulator-always-on;
-				regulator-over-current-protection;
 			};
 
 			bst_out: boost {
@@ -182,13 +179,13 @@
 			vbus_otg: pwr_sw1 {
 				regulator-name = "vbus_otg";
 				interrupts = <IT_OCP_OTG 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			};
 
 			vbus_sw: pwr_sw2 {
 				regulator-name = "vbus_sw";
 				interrupts = <IT_OCP_SWOUT 0>;
-				regulator-active-discharge;
+				regulator-active-discharge = <1>;
 			};
 		};
 
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:37 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:37 +0200
Subject: [PATCH 13/13] ARM: dts: stm32: fix ltdc pinctrl on microdev2.0-of7
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-14-alexandre.torgue@foss.st.com>

It prevents the following warning:

 pin-controller at 50002000: 'ltdc' does not match any of the regexes:
'-[0-9]*$', '^gpio@[0-9a-f]*$', 'pinctrl-[0-9]+'

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
index ba1e2d7f06bf..dffd9d588af2 100644
--- a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
@@ -88,7 +88,7 @@
 };
 
 &pinctrl {
-	ltdc_pins: ltdc {
+	ltdc_pins: ltdc-0 {
 		pins {
 			pinmux = <STM32_PINMUX('G', 10, AF14)>,	/* LTDC_B2 */
 				 <STM32_PINMUX('H', 12, AF14)>,	/* LTDC_R6 */
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:36 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:36 +0200
Subject: [PATCH 12/13] ARM: dts: stm32: fix DSI port node on STM32MP15
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-13-alexandre.torgue@foss.st.com>

Running "make dtbs_check W=1", some warnings are reported concerning
DSI. This patch reorder DSI nodes to avoid:

soc/dsi at 5a000000: unnecessary #address-cells/#size-cells without
"ranges" or child "reg" property

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32mp157.dtsi b/arch/arm/boot/dts/stm32mp157.dtsi
index 54e73ccea446..c355fcf26ec3 100644
--- a/arch/arm/boot/dts/stm32mp157.dtsi
+++ b/arch/arm/boot/dts/stm32mp157.dtsi
@@ -24,8 +24,6 @@
 			clock-names = "pclk", "ref", "px_clk";
 			resets = <&rcc DSI_R>;
 			reset-names = "apb";
-			#address-cells = <1>;
-			#size-cells = <0>;
 			status = "disabled";
 
 			ports {
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 19ef475a48fc..763dde1dbbaf 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -36,6 +36,8 @@
 &dsi {
 	status = "okay";
 	phy-dsi-supply = <&reg18>;
+	#address-cells = <1>;
+	#size-cells = <0>;
 
 	ports {
 		port at 0 {
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 6fe5b0fee7c4..4625bb58cc6d 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -102,6 +102,8 @@
 &dsi {
 	phy-dsi-supply = <&reg18>;
 	status = "okay";
+	#address-cells = <1>;
+	#size-cells = <0>;
 
 	ports {
 		port at 0 {
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:32 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:32 +0200
Subject: [PATCH 08/13] dt-bindings: net: document ptp_ref clk in dwmac
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-9-alexandre.torgue@foss.st.com>

ptp_ref clk has been added in DT but not documented which makes yaml
validation failed:

ethernet at 5800a000: clocks: [[6, 105], [6, 103], [6, 104], [6, 123],
[6, 169], [6, 112]] is too long
ethernet at 5800a000: clock-names: ['stmmaceth', 'mac-clk-tx', 'mac-clk-rx',
'eth-ck', 'ptp_ref', 'ethstp'] is too long

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 0642b0f59491..0201a879399f 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -89,7 +89,7 @@ properties:
 
   clocks:
     minItems: 1
-    maxItems: 5
+    maxItems: 6
     additionalItems: true
     items:
       - description: GMAC main clock
@@ -101,7 +101,7 @@ properties:
 
   clock-names:
     minItems: 1
-    maxItems: 5
+    maxItems: 6
     additionalItems: true
     contains:
       enum:
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index 27eb6066793f..a1c490f3af02 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -46,17 +46,18 @@ properties:
 
   clocks:
     minItems: 3
-    maxItems: 5
+    maxItems: 6
     items:
       - description: GMAC main clock
       - description: MAC TX clock
       - description: MAC RX clock
       - description: For MPU family, used for power mode
       - description: For MPU family, used for PHY without quartz
+      - description: PTP clock
 
   clock-names:
     minItems: 3
-    maxItems: 5
+    maxItems: 6
     contains:
       enum:
         - stmmaceth
@@ -64,6 +65,7 @@ properties:
         - mac-clk-rx
         - ethstp
         - eth-ck
+        - ptp_ref
 
   st,syscon:
     $ref: "/schemas/types.yaml#/definitions/phandle-array"
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:34 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:34 +0200
Subject: [PATCH 10/13] dt-bindings: mfd: add vref_ddr-supply to st,
 stpmic1 yaml
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-11-alexandre.torgue@foss.st.com>

Add vref_ddr-supply to the STPMIC1 regulators supplies pattern
list.

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
index 305123e74a58..ffc32d209496 100644
--- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -184,7 +184,7 @@ properties:
         additionalProperties: false
 
     patternProperties:
-      "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
+      "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])-supply$":
         description: STPMIC1 voltage regulators supplies
 
       "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
-- 
2.17.1



From alexandre.torgue at foss.st.com  Thu Apr 15 11:10:35 2021
From: alexandre.torgue at foss.st.com (Alexandre Torgue)
Date: Thu, 15 Apr 2021 12:10:35 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad MPU
In-Reply-To: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
Message-ID: <20210415101037.1465-12-alexandre.torgue@foss.st.com>

Running "make dtbs_check W=1", some warnings are reported concerning
LTDC port subnode:

/soc/display-controller at 5a001000/port:
unnecessary #address-cells/#size-cells without "ranges" or child "reg"
property
/soc/display-controller at 5a001000/port: graph node has single child node
'endpoint', #address-cells/#size-cells are not necessary

Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8c982ae79f43..f530f84474ea 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -175,7 +175,7 @@
 	status = "okay";
 
 	port {
-		ltdc_out_dsi: endpoint at 0 {
+		ltdc_out_dsi: endpoint {
 			remote-endpoint = <&dsi_in>;
 		};
 	};
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 8aa87cb86821..98a703d1c3a0 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1471,11 +1471,7 @@
 			resets = <&rcc LTDC_R>;
 			status = "disabled";
 
-			port {
-				#address-cells = <1>;
-				#size-cells = <0>;
 			};
-		};
 
 		iwdg2: watchdog at 5a002000 {
 			compatible = "st,stm32mp1-iwdg";
diff --git a/arch/arm/boot/dts/stm32mp157a-dk1.dts b/arch/arm/boot/dts/stm32mp157a-dk1.dts
index 4c8be9c8eb20..c06763d24890 100644
--- a/arch/arm/boot/dts/stm32mp157a-dk1.dts
+++ b/arch/arm/boot/dts/stm32mp157a-dk1.dts
@@ -26,3 +26,11 @@
 		stdout-path = "serial0:115200n8";
 	};
 };
+
+&ltdc {
+	port {
+		ltdc_ep0_out: endpoint {
+			remote-endpoint = <&sii9022_in>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
index 674b2d330dc4..ba1e2d7f06bf 100644
--- a/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
+++ b/arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
@@ -81,8 +81,7 @@
 	status = "okay";
 
 	port {
-		ltdc_ep0_out: endpoint at 0 {
-			reg = <0>;
+		ltdc_ep0_out: endpoint {
 			remote-endpoint = <&panel_in>;
 		};
 	};
diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
index 2bc92ef3aeb9..19ef475a48fc 100644
--- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
@@ -82,9 +82,15 @@
 };
 
 &ltdc {
-	status = "okay";
-
 	port {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ltdc_ep0_out: endpoint at 0 {
+			reg = <0>;
+			remote-endpoint = <&sii9022_in>;
+		};
+
 		ltdc_ep1_out: endpoint at 1 {
 			reg = <1>;
 			remote-endpoint = <&dsi_in>;
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 5c5b1ddf7bfd..6fe5b0fee7c4 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -239,8 +239,7 @@
 	status = "okay";
 
 	port {
-		ltdc_ep0_out: endpoint at 0 {
-			reg = <0>;
+		ltdc_ep0_out: endpoint {
 			remote-endpoint = <&dsi_in>;
 		};
 	};
diff --git a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
index 1e9bf7eea0f1..70202ef5267c 100644
--- a/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dts
@@ -161,8 +161,7 @@
 	status = "okay";
 
 	port {
-		ltdc_ep0_out: endpoint at 0 {
-			reg = <0>;
+		ltdc_ep0_out: endpoint {
 			remote-endpoint = <&panel_input>;
 		};
 	};
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
index 64dca5b7f748..e7f10975cacf 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
@@ -277,11 +277,7 @@
 	status = "okay";
 
 	port {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		ltdc_ep0_out: endpoint at 0 {
-			reg = <0>;
+		ltdc_ep0_out: endpoint {
 			remote-endpoint = <&adv7513_in>;
 		};
 	};
diff --git a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
index 59f18846cf5d..ca2d21689ecc 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi
@@ -458,13 +458,6 @@
 	pinctrl-0 = <&ltdc_pins_a>;
 	pinctrl-1 = <&ltdc_sleep_pins_a>;
 	status = "okay";
-
-	port {
-		ltdc_ep0_out: endpoint at 0 {
-			reg = <0>;
-			remote-endpoint = <&sii9022_in>;
-		};
-	};
 };
 
 &m4_rproc {
-- 
2.17.1



From s.hauer at pengutronix.de  Thu Apr 15 11:15:09 2021
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 15 Apr 2021 12:15:09 +0200
Subject: [PATCH 1/2] drivers/edac: Add L1 and L2 error detection for A53
 and A57
In-Reply-To: <87czvdf1a7.wl-maz@kernel.org>
References: <20210401110615.15326-1-s.hauer@pengutronix.de>
 <20210401110615.15326-2-s.hauer@pengutronix.de>
 <87czvdf1a7.wl-maz@kernel.org>
Message-ID: <20210415101509.GD19819@pengutronix.de>

Hi Marc,

Thanks for the input.

On Fri, Apr 02, 2021 at 11:06:56AM +0100, Marc Zyngier wrote:
> > +config EDAC_CORTEX_ARM64_L1_L2
> > +	tristate "ARM Cortex A57/A53"
> > +	depends on ARM64
> > +	help
> > +	  Support for L1/L2 cache error detection on ARM Cortex A57 and A53.
> 
> I went through the TRMs for a few other Cortex-A cores, and this
> feature looks more common than this comment suggests. At least A35 and
> A72 implement something similar (if not strictly identical), probably
> owing to their ancestry.

Ok, I'll add these to the description.

> > +		}
> > +
> > +		snprintf(msg, MESSAGE_SIZE, "%s %s error(s) on CPU %d",
> > +			 str, fatal ? "fatal" : "correctable", cpu);
> > +
> > +		if (fatal)
> > +			edac_device_handle_ue(edac_ctl, cpu, 0, msg);
> > +		else
> > +			edac_device_handle_ce(edac_ctl, cpu, 0, msg);
> > +	}
> > +
> > +	if (l2merr & L2MERRSR_EL1_VALID) {
> > +		bool fatal = l2merr & L2MERRSR_EL1_FATAL;
> > +
> > +		snprintf(msg, MESSAGE_SIZE, "L2 %s error(s) on CPU %d",
> > +			 fatal ? "fatal" : "correctable", cpu);
> 
> The shared nature of the L2 makes the CPU it has been detected on
> pretty much irrelevant. What you really want here is the CPUID+Way
> that is in the register data.

You are right. For the next round I added some more code to decode the
CPUID/Way field. What's still missing then is information which L2
cache has errors in case there is more than one. I wonder if we should
add get_cpu_cacheinfo(cpu)->id to the message or if there's more to it.

> 
> > +		if (fatal)
> > +			edac_device_handle_ue(edac_ctl, cpu, 1, msg);
> > +		else
> > +			edac_device_handle_ce(edac_ctl, cpu, 1, msg);
> > +	}
> > +}
> > +
> > +static void read_errors(void *data)
> > +{
> > +	struct merrsr *merrsr = data;
> > +
> > +	merrsr->cpumerr = read_sysreg_s(SYS_CPUMERRSR_EL1);
> > +	write_sysreg_s(0, SYS_CPUMERRSR_EL1);
> > +	merrsr->l2merr = read_sysreg_s(SYS_L2MERRSR_EL1);
> > +	write_sysreg_s(0, SYS_L2MERRSR_EL1);
> 
> If an error happens between read and write, you lose it. That's not
> great. You could improve things by only writing 0 if you have found an
> error. You probably also need an isb after the write if you want it to
> take effect in a timely manner.

Ok, will change.

> 
> I'm also not sure of how valuable it is to probe for L2 errors on each
> CPU, given that it is shared with up to 3 other cores. You probably
> want to use the cache topology information for this.

I have no idea how l2merr is implemented. When there is only one
register for all CPUs sharing the same L2 cache then it shouldn't
do any harm to read it more than once. The expensive part is
probably to schedule a function on all CPUs, and we have to do that
anyway to read the L1 cache errors.

Sascha

-- 
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 baolu.lu at linux.intel.com  Thu Apr 15 11:21:22 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Thu, 15 Apr 2021 18:21:22 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <88cba608-2f22-eb83-f22e-50cb547b6ee8@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
 <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
 <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>
 <88cba608-2f22-eb83-f22e-50cb547b6ee8@huawei.com>
Message-ID: <2c01425f-813c-4278-ba06-26d651496a5c@linux.intel.com>

Hi,

On 2021/4/15 15:43, Keqian Zhu wrote:
>>> design it as not switchable. I will modify the commit message of patch#12, thanks!
>> I am not sure that I fully get your point. But I can't see any gaps of
>> using iommu_dev_enable/disable_feature() to switch dirty log on and off.
>> Probably I missed anything.
> IOMMU_DEV_FEAT_HWDBM just tells user whether underlying IOMMU driver supports
> dirty tracking, it is not used to management the status of dirty log tracking.
> 
> The feature reporting is per device, but the status management is per iommu_domain.
> Only when all devices in a domain support HWDBM, we can start dirty log for the domain.

So why not

	for_each_device_attached_domain()
		iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)

?
> 
> And I think we'd better not mix the feature reporting and status management. Thoughts?
> 

I am worrying about having two sets of APIs for single purpose. From
vendor iommu driver's point of view, this feature is per device. Hence,
it still needs to do the same thing.

Best regards,
baolu


From maz at kernel.org  Thu Apr 15 11:23:44 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 15 Apr 2021 11:23:44 +0100
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <b434317f-ef6d-1d91-0189-8343c404c88c@huawei.com>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
 <20210414065109.8616-3-zhukeqian1@huawei.com>
 <87pmyxme2m.wl-maz@kernel.org>
 <b434317f-ef6d-1d91-0189-8343c404c88c@huawei.com>
Message-ID: <87im4nn8wf.wl-maz@kernel.org>

On Thu, 15 Apr 2021 03:20:52 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/14 17:05, Marc Zyngier wrote:
> > + Santosh, who found some interesting bugs in that area before.
> > 
> > On Wed, 14 Apr 2021 07:51:09 +0100,
> > Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >>
> >> The MMIO region of a device maybe huge (GB level), try to use
> >> block mapping in stage2 to speedup both map and unmap.
> >>
> >> Compared to normal memory mapping, we should consider two more
> >> points when try block mapping for MMIO region:
> >>
> >> 1. For normal memory mapping, the PA(host physical address) and
> >> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> >> the HVA to request hugepage, so we don't need to consider PA
> >> alignment when verifing block mapping. But for device memory
> >> mapping, the PA and HVA may have different alignment.
> >>
> >> 2. For normal memory mapping, we are sure hugepage size properly
> >> fit into vma, so we don't check whether the mapping size exceeds
> >> the boundary of vma. But for device memory mapping, we should pay
> >> attention to this.
> >>
> >> This adds device_rough_page_shift() to check these two points when
> >> selecting block mapping size.
> >>
> >> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> >> ---
> >>  arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
> >>  1 file changed, 33 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> >> index c59af5ca01b0..1a6d96169d60 100644
> >> --- a/arch/arm64/kvm/mmu.c
> >> +++ b/arch/arm64/kvm/mmu.c
> >> @@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
> >>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
> >>  }
> >>  
> >> +/*
> >> + * Find a max mapping size that properly insides the vma. And hva and pa must
> >> + * have the same alignment to this mapping size. It's rough as there are still
> >> + * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
> >> + */
> >> +static short device_rough_page_shift(struct vm_area_struct *vma,
> >> +				     unsigned long hva)
> > 
> > My earlier question still stands. Under which circumstances would this
> > function return something that is *not* the final mapping size? I
> > really don't see a reason why this would not return the final mapping
> > size.
> 
> IIUC, all the restrictions are about alignment and area boundary.
> 
> That's to say, HVA, IPA and PA must have same alignment within the
> mapping size.  And the areas are memslot and vma, which means the
> mapping size must properly fit into the memslot and vma.
> 
> In this function, we just checked the alignment of HVA and PA, and
> the boundary of vma.  So we still need to check the alignment of HVA
> and IPA, and the boundary of memslot.  These will be checked by
> fault_supports_stage2_huge_mapping().

But that's no different from what we do with normal memory, is it? So
it really feels like we should have *one* function that deals with
establishing the basic mapping size from the VMA (see below for what I
have in mind).

> 
> > 
> >> +{
> >> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> >> +
> >> +#ifndef __PAGETABLE_PMD_FOLDED
> >> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> >> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> >> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> >> +		return PUD_SHIFT;
> >> +#endif
> >> +
> >> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> >> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> >> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> >> +		return PMD_SHIFT;
> >> +
> >> +	return PAGE_SHIFT;
> >> +}
> >> +
> >>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
> >>  					       unsigned long hva,
> >>  					       unsigned long map_size)
> >> @@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>  		return -EFAULT;
> >>  	}
> >>  
> >> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> >> +	/*
> >> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> >> +	 * get block mapping for device MMIO region.
> >> +	 */
> >>  	mmap_read_lock(current->mm);
> >>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
> >>  	if (unlikely(!vma)) {
> >> @@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>  
> >>  	if (is_vm_hugetlb_page(vma))
> >>  		vma_shift = huge_page_shift(hstate_vma(vma));
> >> +	else if (vma->vm_flags & VM_PFNMAP)
> >> +		vma_shift = device_rough_page_shift(vma, hva);
> > 
> > What prevents a VMA from having both VM_HUGETLB and VM_PFNMAP? This is
> > pretty unlikely, but I'd like to see this case catered for.
> > 
> I'm not sure whether VM_HUGETLB and VM_PFNMAP are compatible, and I
> failed to find a case.
> 
> VM_PFNMAP is used for page-ranges managed without "struct page",
> just pure PFN.  IIUC, VM_HUGETLB is used for hugetlbfs, which always
> has "struct page".  So I think they should not be compatible,
> otherwise it's a bug of driver.

For now, maybe. But huge mappings of PFN could land at some point, and
it'd be hard to catch. I think this case deserves a VM_BUG_ON().

> 
> >>  	else
> >>  		vma_shift = PAGE_SHIFT;
> >>  
> >> -	if (logging_active ||
> >> -	    (vma->vm_flags & VM_PFNMAP)) {
> >> +	if (logging_active) {

BTW, don't you introduce a bug here? Logging shouldn't affect device
mappings.


> >>  		force_pte = true;
> >>  		vma_shift = PAGE_SHIFT;
> >>  	}
> >> @@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>  
> >>  	if (kvm_is_device_pfn(pfn)) {
> >>  		device = true;
> >> -		force_pte = true;
> >> +		force_pte = (vma_pagesize == PAGE_SIZE);
> > 
> > Why do we need to set force_pte if we are already dealing with
> > PAGE_SIZE? I guess you are doing this for the sake of avoiding the
> > call to transparent_hugepage_adjust(), right?
> Yes.
> 
> > 
> > I'd rather you simply don't try to upgrade a device mapping by
> > explicitly checking for this and keep force_pte for *memory*
> > exclusively.
> Agree, that's better.
> 
> > 
> > Santosh, can you please take a look at this series and try to see if
> > the problem you fixed in [1] (which ended up as commit 91a2c34b7d6f)
> > is still OK with this series?
> I searched the initial version[*], VM_PFNMAP is set when we call
> gfn_to_pfn_prot()->vma_mmio_fault()->remap_pfn_range().  Then the
> check of VM_PFNMAP in user_mem_abort() failed, so we will try to
> call transparent_hugepage_adjust() for device pfn.
> 
> In that case, our logic of trying block mapping for MMIO is not
> used. And we still set force_pte for device pfn, so this bugfix is
> not affected. Santosh, do you agree that?

But isn't what we just agreed to get rid of just above?

> 
> I still found that the reason vfio_pci does not have this
> bug. vfio_pci set VM_PFNMAP for vma when userspace calls mmap().  I
> will apply this logic for vfio_mdev too, let's see what vfio
> maintainer think about it.

I think that'd be good to see what Alex thinks about it...

Here's the changes I propose. It is completely untested, of course.

Thanks,

	M.

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..f32d956cc199 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
 	return PAGE_SIZE;
 }
 
+static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
+{
+	unsigned long pa;
+
+	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
+		return huge_page_shift(hstate_vma(vma));
+
+	if (!(vma->vm_flags & VM_PFNMAP))
+		return PAGE_SHIFT;
+
+	VM_BUG_ON(is_vm_hugetlb_page(vma));
+
+	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
+		return PUD_SHIFT;
+#endif
+
+	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
+		return PMD_SHIFT;
+
+	return PAGE_SHIFT;
+}
+
 static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 			  struct kvm_memory_slot *memslot, unsigned long hva,
 			  unsigned long fault_status)
@@ -778,13 +807,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 	}
 
-	if (is_vm_hugetlb_page(vma))
-		vma_shift = huge_page_shift(hstate_vma(vma));
-	else
-		vma_shift = PAGE_SHIFT;
+	vma_shift = get_vma_page_shift(vma, hva);
 
-	if (logging_active ||
-	    (vma->vm_flags & VM_PFNMAP)) {
+	if (logging_active && !(vma->vm_flags & VM_PFNMAP)) {
 		force_pte = true;
 		vma_shift = PAGE_SHIFT;
 	}
@@ -854,8 +879,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 
 	if (kvm_is_device_pfn(pfn)) {
+		/*
+		 * If the page was identified as device early by looking at
+		 * the VMA flags, vma_pagesize is already representing the
+		 * largest quantity we can map.  If instead it was mapped
+		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
+		 * and must not be upgraded.
+		 *
+		 * In both cases, we don't let transparent_hugepage_adjust()
+		 * change things at the last minute.
+		 */
 		device = true;
-		force_pte = true;
 	} else if (logging_active && !write_fault) {
 		/*
 		 * Only actually map the page as writable if this was a write
@@ -876,7 +910,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	 * If we are not forced to use page mapping, check if we are
 	 * backed by a THP and thus use block mapping if possible.
 	 */
-	if (vma_pagesize == PAGE_SIZE && !force_pte)
+	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
 		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
 							   &pfn, &fault_ipa);
 	if (writable)

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


From shameerali.kolothum.thodi at huawei.com  Thu Apr 15 11:30:03 2021
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Thu, 15 Apr 2021 10:30:03 +0000
Subject: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
In-Reply-To: <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
 <20201119121150.3316-3-shameerali.kolothum.thodi@huawei.com>
 <a64025cd-3312-9621-1771-8e0430220ed8@redhat.com>
Message-ID: <0c5ef81c82984f6eaabdc9b27ee79070@huawei.com>

Hi Eric,

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger at redhat.com]
> Sent: 15 April 2021 10:39
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
> iommu at lists.linux-foundation.org; devel at acpica.org
> Cc: Linuxarm <linuxarm at huawei.com>; steven.price at arm.com; Guohanjun
> (Hanjun Guo) <guohanjun at huawei.com>; Sami.Mujawar at arm.com;
> robin.murphy at arm.com; wanghuiqiang <wanghuiqiang at huawei.com>
> Subject: Re: [RFC PATCH v2 2/8] ACPI/IORT: Add support for RMR node parsing
> 
> Hi Shameer,
> On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> > Add support for parsing RMR node information from ACPI.
> > Find associated stream ids and smmu node?info from the
> > RMR node and populate a linked list with RMR memory
> > descriptors.
> >
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
> > ---
> >  drivers/acpi/arm64/iort.c | 122
> +++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 121 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 9929ff50c0c0..a9705aa35028 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -40,6 +40,25 @@ struct iort_fwnode {
> >  static LIST_HEAD(iort_fwnode_list);
> >  static DEFINE_SPINLOCK(iort_fwnode_lock);
> >
> > +struct iort_rmr_id {
> > +	u32  sid;
> > +	struct acpi_iort_node *smmu;
> > +};
> > +
> > +/*
> > + * One entry for IORT RMR.
> > + */
> > +struct iort_rmr_entry {
> > +	struct list_head list;
> > +
> > +	unsigned int rmr_ids_num;
> > +	struct iort_rmr_id *rmr_ids;
> > +
> > +	struct acpi_iort_rmr_desc *rmr_desc;
> > +};
> > +
> > +static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI
> */
> > +
> >  /**
> >   * iort_set_fwnode() - Create iort_fwnode and use it to register
> >   *		       iommu data in the iort_fwnode_list
> > @@ -393,7 +412,8 @@ static struct acpi_iort_node
> *iort_node_get_id(struct acpi_iort_node *node,
> >  		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> >  		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
> >  		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
> > -		    node->type == ACPI_IORT_NODE_PMCG) {
> > +		    node->type == ACPI_IORT_NODE_PMCG ||
> > +		    node->type == ACPI_IORT_NODE_RMR) {
> >  			*id_out = map->output_base;
> >  			return parent;
> >  		}
> > @@ -1647,6 +1667,103 @@ static void __init iort_enable_acs(struct
> acpi_iort_node *iort_node)
> >  #else
> >  static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
> >  #endif
> > +static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc)
> > +{
> > +	struct iort_rmr_entry *e;
> > +	u64 end, start = desc->base_address, length = desc->length;
> > +
> > +	if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
> > +		return -EINVAL;
> > +
> > +	end = start + length - 1;
> > +
> > +	/* Check for address overlap */
> I don't get this check. What is the problem if you attach the same range
> to different stream ids. Shouldn't you check there is no overlap for the
> same sid?

That?s right. The check should be for memory descriptors within an RMR.
I got confused by the wordings in the IORT spec and that is now clarified
with Lorenzo here,

https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

I will change this.
> 
> 
> > +	list_for_each_entry(e, &iort_rmr_list, list) {
> > +		u64 e_start = e->rmr_desc->base_address;
> > +		u64 e_end = e_start + e->rmr_desc->length - 1;
> > +
> > +		if (start <= e_end && end >= e_start)
> > +			return -EINVAL;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
> > +{
> > +	struct iort_rmr_id *rmr_ids, *ids;
> > +	struct iort_rmr_entry *e;
> > +	struct acpi_iort_rmr *rmr;
> > +	struct acpi_iort_rmr_desc *rmr_desc;
> > +	u32 map_count = iort_node->mapping_count;
> > +	int i, ret = 0, desc_count = 0;
> > +
> > +	if (iort_node->type != ACPI_IORT_NODE_RMR)
> > +		return 0;
> > +
> > +	if (!iort_node->mapping_offset || !map_count) {
> > +		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
> > +		       iort_node);
> > +		return -EINVAL;
> > +	}
> > +
> > +	rmr_ids = kmalloc(sizeof(*rmr_ids) * map_count, GFP_KERNEL);
> > +	if (!rmr_ids)
> > +		return -ENOMEM;
> > +
> > +	/* Retrieve associated smmu and stream id */
> > +	ids = rmr_ids;
> nit: do you need both rmr_ids and ids?

Not really as the spec says it is M:1 mapping. So we only will have one 
single id here(also map_count for the node must be set to 1 as well).

> > +	for (i = 0; i < map_count; i++, ids++) {
> > +		ids->smmu = iort_node_get_id(iort_node, &ids->sid, i);
> > +		if (!ids->smmu) {
> > +			pr_err(FW_BUG "Invalid SMMU reference, skipping RMR
> node %p\n",
> > +			       iort_node);
> > +			ret = -EINVAL;
> > +			goto out;
> > +		}
> > +	}
> > +
> > +	/* Retrieve RMR data */
> > +	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
> > +	if (!rmr->rmr_offset || !rmr->rmr_count) {
> > +		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR
> node %p\n",
> > +		       iort_node);
> > +		ret = -EINVAL;
> > +		goto out;
> > +	}
> > +
> > +	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
> > +				rmr->rmr_offset);
> > +
> > +	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
> > +		ret = iort_rmr_desc_valid(rmr_desc);
> > +		if (ret) {
> > +			pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p,
> skipping...\n",
> > +			       i, iort_node);
> > +			goto out;
> so I understand you skip the whole node and not just that rmr desc,
> otherwise you would continue. so in that case don't you need to free
> both rmr_ids and already allocated 'e'?

Agree. This needs to be changed.

> > +		}
> > +
> > +		e = kmalloc(sizeof(*e), GFP_KERNEL);
> > +		if (!e) {
> > +			ret = -ENOMEM;
> > +			goto out;
> > +		}
> > +
> > +		e->rmr_ids_num = map_count;
> > +		e->rmr_ids = rmr_ids;
> > +		e->rmr_desc = rmr_desc;
> > +
> > +		list_add_tail(&e->list, &iort_rmr_list);
> > +		desc_count++;
> > +	}
> > +
> > +	return 0;
> > +
> > +out:
> > +	if (!desc_count)
> don't you want to test ret instead? see comment above. + free allocated ''e'

Right. I will change it next revision.

Thanks for taking a look.

Regards,
Shameer

> > +		kfree(rmr_ids);
> > +	return ret;
> > +}
> >
> >  static void __init iort_init_platform_devices(void)
> >  {
> > @@ -1676,6 +1793,9 @@ static void __init iort_init_platform_devices(void)
> >
> >  		iort_enable_acs(iort_node);
> >
> > +		if (iort_table->revision == 1)
> > +			iort_parse_rmr(iort_node);
> > +
> >  		ops = iort_get_dev_cfg(iort_node);
> >  		if (ops) {
> >  			fwnode = acpi_alloc_fwnode_static();
> >
> Thanks
> 
> Eric


From andriy.shevchenko at linux.intel.com  Thu Apr 15 11:36:24 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Thu, 15 Apr 2021 13:36:24 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <39f6bbed-9eea-963a-1ef1-a83248f162aa@hisilicon.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <21d833f0-b1b8-9732-21c7-3a73676e07d3@hisilicon.com>
 <39f6bbed-9eea-963a-1ef1-a83248f162aa@hisilicon.com>
Message-ID: <YHgXKHvjnC5qzDPy@smile.fi.intel.com>

On Thu, Apr 15, 2021 at 05:04:39PM +0800, Yicong Yang wrote:
> On 2021/4/15 16:18, Yicong Yang wrote:
> > On 2021/4/15 2:06, Geert Uytterhoeven wrote:
> >> On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> >>> On 2021/4/13 20:26, Geert Uytterhoeven wrote:
> >>>> The HiSilicon Kunpeng I2C controller is only present on HiSilicon
> >>>> Kunpeng SoCs, and its driver relies on ACPI to probe for its presence.
> >>>> Hence add dependencies on ARCH_HISI and ACPI, to prevent asking the user
> >>>> about this driver when configuring a kernel without Hisilicon platform
> >>>> or ACPI firmware support.
> >>>
> >>> this is a public IP which doesn't specifically depend on ARCH_HISI. I'm
> >>> not sure all the platform this IP on has ARCH_HISI configured. The driver
> >>> will not be compiled by default config. This is not correct to have
> >>> this dependence.
> >>
> >> Thanks for your answer!
> >>
> >> I guess it's still fine to add a dependency on ACPI?
> > 
> > yes. currently we only use this driver through ACPI. So at least
> > for this driver, it make sense to keep the dependency.
> > 
> 
> sorry. i was a little mess about this. I dropped this in [1].
> so just keep it as is.
> 
> [1] https://lore.kernel.org/linux-i2c/YGMntYT2iz72wgrd at smile.fi.intel.com/

If you think that ACPI dependency is good to have there, go ahead, not my
worries of the consequences. I just consider that as unneeded dependencies.

The proper fix would be to have a split in Kbuild infra for compile
dependencies and run-time dependencies.

+Cc: Masahiro for the discussion, maybe it had already taken place and there is
an impediment to do so.

-- 
With Best Regards,
Andy Shevchenko




From shameerali.kolothum.thodi at huawei.com  Thu Apr 15 11:37:02 2021
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Thu, 15 Apr 2021 10:37:02 +0000
Subject: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
In-Reply-To: <2e58d4e6-83fd-b5cf-b2db-7575cb197058@redhat.com>
References: <20201119121150.3316-1-shameerali.kolothum.thodi@huawei.com>
 <2e58d4e6-83fd-b5cf-b2db-7575cb197058@redhat.com>
Message-ID: <f061e603b440466db26be9baf334f2b0@huawei.com>

[+Lorenzo]

> -----Original Message-----
> From: Auger Eric [mailto:eric.auger at redhat.com]
> Sent: 15 April 2021 10:49
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
> iommu at lists.linux-foundation.org; devel at acpica.org
> Cc: Linuxarm <linuxarm at huawei.com>; steven.price at arm.com; Guohanjun
> (Hanjun Guo) <guohanjun at huawei.com>; Sami.Mujawar at arm.com;
> robin.murphy at arm.com; wanghuiqiang <wanghuiqiang at huawei.com>;
> Jean-Philippe Brucker <jean-philippe at linaro.org>
> Subject: Re: [RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
> 
> Hi Shameer,
> 
> + Jean-Philippe
> 
> 
> On 11/19/20 1:11 PM, Shameer Kolothum wrote:
> > RFC v1 --> v2:
> > ?- Added a generic interface for IOMMU drivers to retrieve all the
> > ? ?RMR info associated with a given IOMMU.
> > ?- SMMUv3 driver gets the RMR list during probe() and installs
> > ?? bypass STEs for all the SIDs in the RMR list. This is to keep
> >  ? the ongoing traffic alive(if any) during SMMUv3 reset. This is
> >    based on the suggestions received for v1 to take care of the
> >    EFI framebuffer use case. Only sanity tested for now.
> > ?- During the probe/attach device, SMMUv3 driver reserves any
> > ? ?RMR region associated with the device such that there is a unity
> > ? ?mapping for them in SMMU.
> > ---
> >
> > The series adds support to IORT RMR nodes specified in IORT
> > Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
> > ranges that are used by endpoints and require a unity mapping
> > in SMMU.
> >
> > We have faced issues with 3408iMR RAID controller cards which
> > fail to boot when SMMU is enabled. This is because these controllers
> > make use of host memory for various caching related purposes and when
> > SMMU is enabled the iMR firmware fails to access these memory regions
> > as there is no mapping for them. IORT RMR provides a way for UEFI to
> > describe and report these memory regions so that the kernel can make
> > a unity mapping for these in SMMU.
> >
> > RFC because, Patch #1 is to update the actbl2.h and should be done
> > through acpica update. I have send out a pull request[1] for that.
> >
> > Tests:
> >
> > With a UEFI, that reports the RMR for the dev,
> > ....
> > [16F0h 5872   1]                         Type : 06
> > [16F1h 5873   2]                       Length : 007C
> > [16F3h 5875   1]                     Revision : 00
> > [1038h 0056   2]                     Reserved : 00000000
> > [1038h 0056   2]                   Identifier : 00000000
> > [16F8h 5880   4]                Mapping Count : 00000001
> > [16FCh 5884   4]               Mapping Offset : 00000040
> >
> > [1700h 5888   4]    Number of RMR Descriptors : 00000002
> > [1704h 5892   4]        RMR Descriptor Offset : 00000018
> >
> > [1708h 5896   8]          Base Address of RMR : 0000E6400000
> > [1710h 5904   8]                Length of RMR : 000000100000
> > [1718h 5912   4]                     Reserved : 00000000
> >
> > [171Ch 5916   8]          Base Address of RMR : 0000000027B00000
> > [1724h 5924   8]                Length of RMR : 0000000000C00000
> > [172Ch 5932   4]                     Reserved : 00000000
> >
> > [1730h 5936   4]                   Input base : 00000000
> > [1734h 5940   4]                     ID Count : 00000001
> > [1738h 5944   4]                  Output Base : 00000003
> > [173Ch 5948   4]             Output Reference : 00000064
> > [1740h 5952   4]        Flags (decoded below) : 00000001
> >                                Single Mapping : 1
> 
> Following Jean-Philippe's suggestion I have used your series for nested
> stage SMMUv3 integration, ie. to simplify the MSI nested stage mapping.
> 
> Host allocates hIOVA -> physical doorbell (pDB) as it normally does for
> VFIO device passthrough. IOVA Range is 0x8000000 - 0x8100000.
> 
> I expose this MIS IOVA range to the guest as an RMR and as a result
> guest has a flat mapping for this range. As the physical device is
> programmed with hIOVA we have the following mapping:
> 
> IOVA            IPA          PA
> hIOVA   ->     hIOVA     ->  pDB
>         S1               s2
> 
> This works.
> 
> The only weird thing is that I need to expose 256 RMRs due to the
> 'Single Mapping' mandatory flag. I need to have 1 RMR per potential SID
> on the bus.

Please see the discussion here,
https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

Hi Lorenzo,

May be this is a use case for relaxing that single mapping requirement.

Thanks,
Shameer

> 
> I will post a new version of SMMUv3 nested stage soon for people to test
> & compare. Obviously this removes a bunch of code on both SMMU/VFIO and
> QEMU code so I think this solution looks better overall.
> 
> Thanks
> 
> Eric
> > ...
> >
> > Without the series the RAID controller initialization fails as
> > below,
> >
> > ...
> > [   12.631117] megaraid_sas 0000:03:00.0: FW supports sync
> cache        : Yes
> > [   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is
> called outbound_intr_mask:0x40000009
> > [   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED
> for SCSI host 0
> > [   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to
> ready state
> > [  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault
> code:0x10000 subcode:0x0 func:megasas_transition_to_ready
> > [  106.695186] megaraid_sas 0000:03:00.0: System Register set:
> > [  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to
> ready for scsi0.
> > [  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw
> 6407
> > estuary:/$
> >
> > With the series, now the kernel has direct mapping for the dev as
> > below,
> >
> > estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions
> > 0x0000000008000000 0x00000000080fffff msi
> > 0x0000000027b00000 0x00000000286fffff direct
> > 0x00000000e6400000 0x00000000e64fffff direct
> > estuary:/$
> >
> > ....
> > [   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is
> called outbound_intr_mask:0x40000009
> > [   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs:
> 0      max_lds: 32
> > [   12.746628] megaraid_sas 0000:03:00.0: controller type       :
> iMR(0MB)
> > [   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  :
> Enabled
> > [   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes
> > [   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes
> > [   12.771931] megaraid_sas 0000:03:00.0: FW provided TM
> TaskAbort/Reset timeou: 6 secs/60 secs
> > [   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map
> support     : Yes
> > [   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining
> support    : No
> > [   12.819179] megaraid_sas 0000:03:00.0: NVME page size        :
> (4096)
> > [   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is
> called outbound_intr_mask:0x40000000
> > [   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done
> > [   12.873932] megaraid_sas 0000:03:00.0: pci id                :
> (0x1000)/(0x0017)/(0x19e5)/(0xd213)
> > [   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no
> > [   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no
> > [   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     :
> enabled
> >
> > RAID controller init is now success and can detect the drives
> > attached as well.
> >
> > Thanks,
> > Shameer
> >
> > [0]. https://developer.arm.com/documentation/den0049/latest/
> > [1]. https://github.com/acpica/acpica/pull/638
> >
> > Shameer Kolothum (8):
> >   ACPICA: IORT: Update for revision E
> >   ACPI/IORT: Add support for RMR node parsing
> >   iommu/dma: Introduce generic helper to retrieve RMR info
> >   ACPI/IORT: Add RMR memory regions reservation helper
> >   iommu/arm-smmu-v3: Introduce strtab init helper
> >   iommu/arm-smmu-v3: Add bypass flag to?arm_smmu_write_strtab_ent()
> >   iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
> >   iommu/arm-smmu-v3: Reserve any RMR regions associated with a?dev
> >
> >  drivers/acpi/arm64/iort.c                   | 182
> +++++++++++++++++++-
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |   2 +
> >  drivers/iommu/dma-iommu.c                   |  39 +++++
> >  include/acpi/actbl2.h                       |  25 ++-
> >  include/linux/acpi_iort.h                   |   6 +
> >  include/linux/dma-iommu.h                   |   7 +
> >  include/linux/iommu.h                       |  16 ++
> >  8 files changed, 367 insertions(+), 22 deletions(-)
> >


From jonas.rabenstein at studium.uni-erlangen.de  Thu Apr 15 11:39:55 2021
From: jonas.rabenstein at studium.uni-erlangen.de (Jonas Rabenstein)
Date: Thu, 15 Apr 2021 12:39:55 +0200
Subject: [PATCH] ARM: vfp: fix misspelled identifier in documentation
Message-ID: <20210415103955.38983-1-jonas.rabenstein@studium.uni-erlangen.de>

The documentation comment for vfp_notifier misspelled
THREAD_NOTIFY_SWITCH as THREAD_NOFTIFY_SWITCH.

Signed-off-by: Jonas Rabenstein <jonas.rabenstein at studium.uni-erlangen.de>
---
 arch/arm/vfp/vfpmodule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2cb355c1b5b7..4f8c6f583b79 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -140,7 +140,7 @@ static void vfp_thread_copy(struct thread_info *thread)
 /*
  * When this function is called with the following 'cmd's, the following
  * is true while this function is being run:
- *  THREAD_NOFTIFY_SWTICH:
+ *  THREAD_NOTIFY_SWITCH:
  *   - the previously running thread will not be scheduled onto another CPU.
  *   - the next thread to be run (v) will not be running on another CPU.
  *   - thread->cpu is the local CPU number
-- 
2.26.3



From hca at linux.ibm.com  Thu Apr 15 11:38:52 2021
From: hca at linux.ibm.com (Heiko Carstens)
Date: Thu, 15 Apr 2021 12:38:52 +0200
Subject: [PATCH 3/5] s390: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-4-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-4-maz@kernel.org>
Message-ID: <YHgXvFCLh0Ls0b9t@osiris>

On Wed, Apr 14, 2021 at 02:44:07PM +0100, Marc Zyngier wrote:
> perf_pmu_name() and perf_num_counters() are unused. Drop them.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/s390/kernel/perf_event.c | 21 ---------------------
>  1 file changed, 21 deletions(-)

Acked-by: Heiko Carstens <hca at linux.ibm.com>

...or do you want me to pick this up and route via the s390 tree(?).


From maz at kernel.org  Thu Apr 15 11:42:00 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 15 Apr 2021 11:42:00 +0100
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile
 helpers
In-Reply-To: <baa268cf-c92d-6b97-da4c-e7da2a9ccb7a@huawei.com>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-2-maz@kernel.org>
 <baa268cf-c92d-6b97-da4c-e7da2a9ccb7a@huawei.com>
Message-ID: <87h7k7n81z.wl-maz@kernel.org>

On Thu, 15 Apr 2021 07:59:26 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/14 21:44, Marc Zyngier wrote:
> > KVM/arm64 is the sole user of perf_num_counters(), and really
> > could do without it. Stop using the obsolete API by relying on
> > the existing probing code.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  arch/arm64/kvm/perf.c     | 7 +------
> >  arch/arm64/kvm/pmu-emul.c | 2 +-
> >  include/kvm/arm_pmu.h     | 4 ++++
> >  3 files changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> > index 739164324afe..b8b398670ef2 100644
> > --- a/arch/arm64/kvm/perf.c
> > +++ b/arch/arm64/kvm/perf.c
> > @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
> >  
> >  int kvm_perf_init(void)
> >  {
> > -	/*
> > -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> > -	 * hardware performance counters. This could ensure the presence of
> > -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> > -	 */
> > -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> > +	if (kvm_pmu_probe_pmuver() != 0xf)
> The probe() function may be called many times
> (kvm_arm_pmu_v3_set_attr also calls it).  I don't know whether the
> first calling is enough. If so, can we use a static variable in it,
> so the following calling can return the result right away?

No, because that wouldn't help with crappy big-little implementations
that could have PMUs with different versions. We want to find the
version at the point where the virtual PMU is created, which is why we
call the probe function once per vcpu.

This of course is broken in other ways (BL+KVM is a total disaster
when it comes to PMU), but making this static would just make it
worse.

	M.

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


From a.fatoum at pengutronix.de  Thu Apr 15 11:43:06 2021
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Thu, 15 Apr 2021 12:43:06 +0200
Subject: [PATCH 12/13] ARM: dts: stm32: fix DSI port node on STM32MP15
In-Reply-To: <20210415101037.1465-13-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-13-alexandre.torgue@foss.st.com>
Message-ID: <ececc78c-4fca-bb93-ef62-5d107501d963@pengutronix.de>

Hi,

On 15.04.21 12:10, Alexandre Torgue wrote:
> Running "make dtbs_check W=1", some warnings are reported concerning
> DSI. This patch reorder DSI nodes to avoid:
> 
> soc/dsi at 5a000000: unnecessary #address-cells/#size-cells without
> "ranges" or child "reg" property

This reverts parts of commit 9c32f980d9 ("ARM: dts: stm32: preset
stm32mp15x video #address- and #size-cells"):
    
    The cell count for address and size is defined by the binding and not
    something a board would change. Avoid each board adding this
    boilerplate by having the cell size specification in the SoC DTSI.
    

The DSI can have child nodes with a unit address (e.g. a panel) and ones
without (ports { } container). ports is described in the dtsi, panels are
described in the dts if available.

Apparently, the checker is fine with
ports {
	#address-cells = <1>;
	#size-cells = <0>;
};

I think my rationale for the patch above was sound, so I think the checker
taking offense at the DSI cells here should be considered a false positive.

Thanks,
Ahmad

> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
> 
> diff --git a/arch/arm/boot/dts/stm32mp157.dtsi b/arch/arm/boot/dts/stm32mp157.dtsi
> index 54e73ccea446..c355fcf26ec3 100644
> --- a/arch/arm/boot/dts/stm32mp157.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157.dtsi
> @@ -24,8 +24,6 @@
>  			clock-names = "pclk", "ref", "px_clk";
>  			resets = <&rcc DSI_R>;
>  			reset-names = "apb";
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			status = "disabled";
>  
>  			ports {
> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> index 19ef475a48fc..763dde1dbbaf 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> @@ -36,6 +36,8 @@
>  &dsi {
>  	status = "okay";
>  	phy-dsi-supply = <&reg18>;
> +	#address-cells = <1>;
> +	#size-cells = <0>;
>  
>  	ports {
>  		port at 0 {
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> index 6fe5b0fee7c4..4625bb58cc6d 100644
> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> @@ -102,6 +102,8 @@
>  &dsi {
>  	phy-dsi-supply = <&reg18>;
>  	status = "okay";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
>  
>  	ports {
>  		port at 0 {
> 

-- 
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 andy.shevchenko at gmail.com  Thu Apr 15 11:46:37 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 15 Apr 2021 13:46:37 +0300
Subject: [PATCH v6 3/4] serial: 8250_aspeed_vuart: add aspeed,lpc-io-reg
 and aspeed,lpc-interrupts DT properties
In-Reply-To: <20210412034712.16778-4-zev@bewilderbeest.net>
References: <20210412034712.16778-1-zev@bewilderbeest.net>
 <20210412034712.16778-4-zev@bewilderbeest.net>
Message-ID: <CAHp75VfCKRn+ER4bKf+PLhXHT0yZeN4JDufxfROa4UMf=Bc6bQ@mail.gmail.com>

On Mon, Apr 12, 2021 at 7:05 AM Zev Weiss <zev at bewilderbeest.net> wrote:
>
> These allow describing all the Aspeed VUART attributes currently
> available via sysfs.  aspeed,lpc-interrupts provides a replacement for
> the deprecated aspeed,sirq-polarity-sense property.

One nit-pick below.

In any case it's fine.

> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
> ---
>  drivers/tty/serial/8250/8250_aspeed_vuart.c | 51 ++++++++++++++++++++-
>  1 file changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> index 8433f8dbb186..3c239d98747f 100644
> --- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
> +++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
> @@ -28,6 +28,10 @@
>  #define ASPEED_VUART_ADDRL             0x28
>  #define ASPEED_VUART_ADDRH             0x2c
>
> +#define ASPEED_VUART_DEFAULT_LPC_ADDR  0x3f8
> +#define ASPEED_VUART_DEFAULT_SIRQ      4
> +#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY     IRQ_TYPE_LEVEL_LOW
> +
>  struct aspeed_vuart {
>         struct device           *dev;
>         void __iomem            *regs;
> @@ -386,6 +390,18 @@ static void aspeed_vuart_auto_configure_sirq_polarity(
>         aspeed_vuart_set_sirq_polarity(vuart, (value & reg_mask) == 0);
>  }
>
> +static int aspeed_vuart_map_irq_polarity(u32 dt)
> +{
> +       switch (dt) {
> +       case IRQ_TYPE_LEVEL_LOW:
> +               return 0;
> +       case IRQ_TYPE_LEVEL_HIGH:
> +               return 1;
> +       default:
> +               return -EINVAL;
> +       }
> +}
> +
>  static int aspeed_vuart_probe(struct platform_device *pdev)
>  {
>         struct of_phandle_args sirq_polarity_sense_args;
> @@ -393,8 +409,8 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>         struct aspeed_vuart *vuart;
>         struct device_node *np;
>         struct resource *res;
> -       u32 clk, prop;
> -       int rc;
> +       u32 clk, prop, sirq[2];
> +       int rc, sirq_polarity;
>
>         np = pdev->dev.of_node;
>
> @@ -501,6 +517,37 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
>                 of_node_put(sirq_polarity_sense_args.np);
>         }
>
> +       rc = of_property_read_u32(np, "aspeed,lpc-io-reg", &prop);
> +       if (rc < 0)
> +               prop = ASPEED_VUART_DEFAULT_LPC_ADDR;
> +
> +       rc = aspeed_vuart_set_lpc_address(vuart, prop);
> +       if (rc < 0) {
> +               dev_err(&pdev->dev, "invalid value in aspeed,lpc-io-reg property\n");
> +               goto err_clk_disable;
> +       }
> +
> +       rc = of_property_read_u32_array(np, "aspeed,lpc-interrupts", sirq, 2);
> +       if (rc < 0) {
> +               sirq[0] = ASPEED_VUART_DEFAULT_SIRQ;
> +               sirq[1] = ASPEED_VUART_DEFAULT_SIRQ_POLARITY;
> +       }
> +
> +       rc = aspeed_vuart_set_sirq(vuart, sirq[0]);
> +       if (rc < 0) {
> +               dev_err(&pdev->dev, "invalid sirq number in aspeed,lpc-interrupts property\n");
> +               goto err_clk_disable;
> +       }
> +
> +       sirq_polarity = aspeed_vuart_map_irq_polarity(sirq[1]);
> +       if (sirq_polarity < 0) {
> +               dev_err(&pdev->dev, "invalid sirq polarity in aspeed,lpc-interrupts property\n");

> +               rc = sirq_polarity;
> +               goto err_clk_disable;
> +       }

Why not to use the same pattern as above, i.e.

       rc = aspeed_vuart_map_irq_polarity(sirq[1]);
       if (rc < 0) {
               dev_err(&pdev->dev, "invalid sirq polarity in
aspeed,lpc-interrupts property\n");
               goto err_clk_disable;
       }
       sirq_polarity = rc;

?

> +       aspeed_vuart_set_sirq_polarity(vuart, sirq_polarity);
> +
>         aspeed_vuart_set_enabled(vuart, true);
>         aspeed_vuart_set_host_tx_discard(vuart, true);
>         platform_set_drvdata(pdev, vuart);


-- 
With Best Regards,
Andy Shevchenko


From maz at kernel.org  Thu Apr 15 11:47:26 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 15 Apr 2021 11:47:26 +0100
Subject: [PATCH 3/5] s390: Get rid of oprofile leftovers
In-Reply-To: <YHgXvFCLh0Ls0b9t@osiris>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-4-maz@kernel.org> <YHgXvFCLh0Ls0b9t@osiris>
Message-ID: <87fszrn7sx.wl-maz@kernel.org>

On Thu, 15 Apr 2021 11:38:52 +0100,
Heiko Carstens <hca at linux.ibm.com> wrote:
> 
> On Wed, Apr 14, 2021 at 02:44:07PM +0100, Marc Zyngier wrote:
> > perf_pmu_name() and perf_num_counters() are unused. Drop them.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> >  arch/s390/kernel/perf_event.c | 21 ---------------------
> >  1 file changed, 21 deletions(-)
> 
> Acked-by: Heiko Carstens <hca at linux.ibm.com>
> 
> ...or do you want me to pick this up and route via the s390 tree(?).

Either way work for me, but I just want to make sure the last patch
doesn't get applied before the previous ones.

Thanks,

	M.

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


From claudiu.beznea at microchip.com  Thu Apr 15 11:49:46 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:46 +0300
Subject: [PATCH v3 00/24] ARM: at91: pm: add support for sama7g5
Message-ID: <20210415105010.569620-1-claudiu.beznea@microchip.com>

Hi,

This series adds PM support for SAMA7G5. The standby, ulp0, ulp1, and
backup modes are supported.

Thank you,
Claudiu Beznea

Changes in v3:
- drop: status = "okay" in patch 16/24

Changes in v2:
- keep only the generic sama7_dt in patch 22/24 and adapt patch 23/24
- collected tags

Claudiu Beznea (23):
  ARM: at91: pm: move pm_bu to soc_pm data structure
  ARM: at91: pm: move the setup of soc_pm.bu->suspended
  ARM: at91: pm: document at91_soc_pm structure
  ARM: at91: pm: check for different controllers in at91_pm_modes_init()
  ARM: at91: pm: do not initialize pdev
  ARM: at91: pm: use r7 instead of tmp1
  ARM: at91: pm: avoid push and pop on stack while memory is in
    self-refersh
  ARM: at91: pm: s/CONFIG_SOC_SAM9X60/CONFIG_HAVE_AT91_SAM9X60_PLL/g
  ARM: at91: pm: add support for waiting MCK1..4
  ARM: at91: sfrbu: add sfrbu registers definitions for sama7g5
  ARM: at91: ddr: add registers definitions for sama7g5's ddr
  ARM: at91: pm: add self-refresh support for sama7g5
  ARM: at91: pm: add support for MCK1..4 save/restore for ulp modes
  ARM: at91: pm: add support for 2.5V LDO regulator control
  ARM: at91: pm: wait for ddr power mode off
  dt-bindings: atmel-sysreg: add bindings for sama7g5
  ARM: at91: pm: add sama7g5 ddr controller
  ARM: at91: pm: add sama7g5 ddr phy controller
  ARM: at91: pm: save ddr phy calibration data to securam
  ARM: at91: pm: add backup mode support for SAMA7G5
  ARM: at91: pm: add sama7g5's pmc
  ARM: at91: pm: add pm support for SAMA7G5
  ARM: at91: pm: add sama7g5 shdwc

Eugen Hristev (1):
  ARM: at91: sama7: introduce sama7 SoC family

 .../devicetree/bindings/arm/atmel-sysregs.txt |  14 +-
 arch/arm/mach-at91/Makefile                   |   1 +
 arch/arm/mach-at91/generic.h                  |   2 +
 arch/arm/mach-at91/pm.c                       | 343 ++++++--
 arch/arm/mach-at91/pm.h                       |   3 +
 arch/arm/mach-at91/pm_data-offsets.c          |   2 +
 arch/arm/mach-at91/pm_suspend.S               | 827 +++++++++++++-----
 arch/arm/mach-at91/sama7.c                    |  33 +
 include/soc/at91/sama7-ddr.h                  |  80 ++
 include/soc/at91/sama7-sfrbu.h                |  34 +
 10 files changed, 1049 insertions(+), 290 deletions(-)
 create mode 100644 arch/arm/mach-at91/sama7.c
 create mode 100644 include/soc/at91/sama7-ddr.h
 create mode 100644 include/soc/at91/sama7-sfrbu.h

-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:47 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:47 +0300
Subject: [PATCH v3 01/24] ARM: at91: pm: move pm_bu to soc_pm data structure
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-2-claudiu.beznea@microchip.com>

Move pm_bu to soc_pm data structure.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 34 +++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 90dcdfe3b3d0..e13ceef7ac9a 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -27,10 +27,25 @@
 #include "generic.h"
 #include "pm.h"
 
+/**
+ * struct at91_pm_bu - AT91 power management backup unit data structure
+ * @suspended: true if suspended to backup mode
+ * @reserved: reserved
+ * @canary: canary data for memory checking after exit from backup mode
+ * @resume: resume API
+ */
+struct at91_pm_bu {
+	int suspended;
+	unsigned long reserved;
+	phys_addr_t canary;
+	phys_addr_t resume;
+};
+
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
 	int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
 	const struct of_device_id *ws_ids;
+	struct at91_pm_bu *bu;
 	struct at91_pm_data data;
 };
 
@@ -71,13 +86,6 @@ static int at91_pm_valid_state(suspend_state_t state)
 
 static int canary = 0xA5A5A5A5;
 
-static struct at91_pm_bu {
-	int suspended;
-	unsigned long reserved;
-	phys_addr_t canary;
-	phys_addr_t resume;
-} *pm_bu;
-
 struct wakeup_source_info {
 	unsigned int pmc_fsmr_bit;
 	unsigned int shdwc_mr_bit;
@@ -288,7 +296,7 @@ static int at91_suspend_finish(unsigned long val)
 static void at91_pm_suspend(suspend_state_t state)
 {
 	if (soc_pm.data.mode == AT91_PM_BACKUP) {
-		pm_bu->suspended = 1;
+		soc_pm.bu->suspended = 1;
 
 		cpu_suspend(0, at91_suspend_finish);
 
@@ -657,16 +665,16 @@ static int __init at91_pm_backup_init(void)
 		goto securam_fail;
 	}
 
-	pm_bu = (void *)gen_pool_alloc(sram_pool, sizeof(struct at91_pm_bu));
-	if (!pm_bu) {
+	soc_pm.bu = (void *)gen_pool_alloc(sram_pool, sizeof(struct at91_pm_bu));
+	if (!soc_pm.bu) {
 		pr_warn("%s: unable to alloc securam!\n", __func__);
 		ret = -ENOMEM;
 		goto securam_fail;
 	}
 
-	pm_bu->suspended = 0;
-	pm_bu->canary = __pa_symbol(&canary);
-	pm_bu->resume = __pa_symbol(cpu_resume);
+	soc_pm.bu->suspended = 0;
+	soc_pm.bu->canary = __pa_symbol(&canary);
+	soc_pm.bu->resume = __pa_symbol(cpu_resume);
 
 	return 0;
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:49 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:49 +0300
Subject: [PATCH v3 03/24] ARM: at91: pm: document at91_soc_pm structure
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-4-claudiu.beznea@microchip.com>

Document at91_soc_pm structure.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 3742a1fb76db..3029351ec78e 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -41,6 +41,14 @@ struct at91_pm_bu {
 	phys_addr_t resume;
 };
 
+/**
+ * struct at91_soc_pm - AT91 SoC power management data structure
+ * @config_shdwc_ws: wakeup sources configuration function for SHDWC
+ * @config_pmc_ws: wakeup srouces configuration function for PMC
+ * @ws_ids: wakup sources of_device_id array
+ * @data: PM data to be used on last phase of suspend
+ * @bu: backup unit mapped data (for backup mode)
+ */
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
 	int (*config_pmc_ws)(void __iomem *pmc, u32 mode, u32 polarity);
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:50 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:50 +0300
Subject: [PATCH v3 04/24] ARM: at91: pm: check for different controllers in
 at91_pm_modes_init()
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-5-claudiu.beznea@microchip.com>

at91_pm_modes_init() checks for proper nodes in device tree and maps
them accordingly. Up to SAMA7G5 all AT91 SoCs had the same mapping
b/w power saving modes and different controllers needed in the
final/first steps of suspend/resume. SAMA7G5 is not aligned with the
old SoCs thus the code is adapted for this. This patch prepares
the field for next commits.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 143 +++++++++++++++++++++++++---------------
 1 file changed, 91 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 3029351ec78e..5a6ce1d88971 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -57,6 +57,18 @@ struct at91_soc_pm {
 	struct at91_pm_data data;
 };
 
+/**
+ * enum at91_pm_iomaps:	IOs that needs to be mapped for different PM modes
+ * @AT91_PM_IOMAP_SHDWC:	SHDWC controller
+ * @AT91_PM_IOMAP_SFRBU:	SFRBU controller
+ */
+enum at91_pm_iomaps {
+	AT91_PM_IOMAP_SHDWC,
+	AT91_PM_IOMAP_SFRBU,
+};
+
+#define AT91_PM_IOMAP(name)	BIT(AT91_PM_IOMAP_##name)
+
 static struct at91_soc_pm soc_pm = {
 	.data = {
 		.standby_mode = AT91_PM_STANDBY,
@@ -656,24 +668,15 @@ static int __init at91_pm_backup_init(void)
 	if (!at91_is_pm_mode_active(AT91_PM_BACKUP))
 		return 0;
 
-	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-sfrbu");
-	if (!np) {
-		pr_warn("%s: failed to find sfrbu!\n", __func__);
-		return ret;
-	}
-
-	soc_pm.data.sfrbu = of_iomap(np, 0);
-	of_node_put(np);
-
 	np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-securam");
 	if (!np)
-		goto securam_fail_no_ref_dev;
+		return ret;
 
 	pdev = of_find_device_by_node(np);
 	of_node_put(np);
 	if (!pdev) {
 		pr_warn("%s: failed to find securam device!\n", __func__);
-		goto securam_fail_no_ref_dev;
+		return ret;
 	}
 
 	sram_pool = gen_pool_get(&pdev->dev, NULL);
@@ -697,64 +700,92 @@ static int __init at91_pm_backup_init(void)
 
 securam_fail:
 	put_device(&pdev->dev);
-securam_fail_no_ref_dev:
-	iounmap(soc_pm.data.sfrbu);
-	soc_pm.data.sfrbu = NULL;
 	return ret;
 }
 
-static void __init at91_pm_use_default_mode(int pm_mode)
-{
-	if (pm_mode != AT91_PM_ULP1 && pm_mode != AT91_PM_BACKUP)
-		return;
-
-	if (soc_pm.data.standby_mode == pm_mode)
-		soc_pm.data.standby_mode = AT91_PM_ULP0;
-	if (soc_pm.data.suspend_mode == pm_mode)
-		soc_pm.data.suspend_mode = AT91_PM_ULP0;
-}
-
 static const struct of_device_id atmel_shdwc_ids[] = {
 	{ .compatible = "atmel,sama5d2-shdwc" },
 	{ .compatible = "microchip,sam9x60-shdwc" },
 	{ /* sentinel. */ }
 };
 
-static void __init at91_pm_modes_init(void)
+static void __init at91_pm_modes_init(const u32 *maps, int len)
 {
 	struct device_node *np;
-	int ret;
+	int ret, mode;
 
-	if (!at91_is_pm_mode_active(AT91_PM_BACKUP) &&
-	    !at91_is_pm_mode_active(AT91_PM_ULP1))
-		return;
+	ret = at91_pm_backup_init();
+	if (ret) {
+		if (soc_pm.data.standby_mode == AT91_PM_BACKUP)
+			soc_pm.data.standby_mode = AT91_PM_ULP0;
+		if (soc_pm.data.suspend_mode == AT91_PM_BACKUP)
+			soc_pm.data.suspend_mode = AT91_PM_ULP0;
+	}
 
-	np = of_find_matching_node(NULL, atmel_shdwc_ids);
-	if (!np) {
-		pr_warn("%s: failed to find shdwc!\n", __func__);
-		goto ulp1_default;
+	if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC) ||
+	    maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC)) {
+		np = of_find_matching_node(NULL, atmel_shdwc_ids);
+		if (!np) {
+			pr_warn("%s: failed to find shdwc!\n", __func__);
+
+			/* Use ULP0 if it doesn't needs SHDWC.*/
+			if (!(maps[AT91_PM_ULP0] & AT91_PM_IOMAP(SHDWC)))
+				mode = AT91_PM_ULP0;
+			else
+				mode = AT91_PM_STANDBY;
+
+			if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC))
+				soc_pm.data.standby_mode = mode;
+			if (maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC))
+				soc_pm.data.suspend_mode = mode;
+		} else {
+			soc_pm.data.shdwc = of_iomap(np, 0);
+			of_node_put(np);
+		}
 	}
 
-	soc_pm.data.shdwc = of_iomap(np, 0);
-	of_node_put(np);
+	if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU) ||
+	    maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU)) {
+		np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-sfrbu");
+		if (!np) {
+			pr_warn("%s: failed to find sfrbu!\n", __func__);
+
+			/*
+			 * Use ULP0 if it doesn't need SHDWC or if SHDWC
+			 * was already located.
+			 */
+			if (!(maps[AT91_PM_ULP0] & AT91_PM_IOMAP(SHDWC)) ||
+			    soc_pm.data.shdwc)
+				mode = AT91_PM_ULP0;
+			else
+				mode = AT91_PM_STANDBY;
+
+			if (maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU))
+				soc_pm.data.standby_mode = mode;
+			if (maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU))
+				soc_pm.data.suspend_mode = mode;
+		} else {
+			soc_pm.data.sfrbu = of_iomap(np, 0);
+			of_node_put(np);
+		}
+	}
 
-	ret = at91_pm_backup_init();
-	if (ret) {
-		if (!at91_is_pm_mode_active(AT91_PM_ULP1))
-			goto unmap;
-		else
-			goto backup_default;
+	/* Unmap all unnecessary. */
+	if (soc_pm.data.shdwc &&
+	    !(maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SHDWC) ||
+	      maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SHDWC))) {
+		iounmap(soc_pm.data.shdwc);
+		soc_pm.data.shdwc = NULL;
 	}
 
-	return;
+	if (soc_pm.data.sfrbu &&
+	    !(maps[soc_pm.data.standby_mode] & AT91_PM_IOMAP(SFRBU) ||
+	      maps[soc_pm.data.suspend_mode] & AT91_PM_IOMAP(SFRBU))) {
+		iounmap(soc_pm.data.sfrbu);
+		soc_pm.data.sfrbu = NULL;
+	}
 
-unmap:
-	iounmap(soc_pm.data.shdwc);
-	soc_pm.data.shdwc = NULL;
-ulp1_default:
-	at91_pm_use_default_mode(AT91_PM_ULP1);
-backup_default:
-	at91_pm_use_default_mode(AT91_PM_BACKUP);
+	return;
 }
 
 struct pmc_info {
@@ -917,12 +948,15 @@ void __init sam9x60_pm_init(void)
 	static const int modes[] __initconst = {
 		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP0_FAST, AT91_PM_ULP1,
 	};
+	static const int iomaps[] __initconst = {
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SHDWC),
+	};
 
 	if (!IS_ENABLED(CONFIG_SOC_SAM9X60))
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_pm_modes_init();
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
 	at91_dt_ramc();
 	at91_pm_init(NULL);
 
@@ -967,12 +1001,17 @@ void __init sama5d2_pm_init(void)
 		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP0_FAST, AT91_PM_ULP1,
 		AT91_PM_BACKUP,
 	};
+	static const u32 iomaps[] __initconst = {
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SHDWC),
+		[AT91_PM_BACKUP]	= AT91_PM_IOMAP(SHDWC) |
+					  AT91_PM_IOMAP(SFRBU),
+	};
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_pm_modes_init();
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
 	at91_dt_ramc();
 	at91_pm_init(NULL);
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:48 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:48 +0300
Subject: [PATCH v3 02/24] ARM: at91: pm: move the setup of soc_pm.bu->suspended
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-3-claudiu.beznea@microchip.com>

Move the setup of soc_pm.bu->suspended in platform_suspend::begin
function so that the PMC code in charge with clocks suspend/resume
to differentiate b/w standard PM mode and backup mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 arch/arm/mach-at91/pm.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index e13ceef7ac9a..3742a1fb76db 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -214,6 +214,8 @@ static int at91_sam9x60_config_pmc_ws(void __iomem *pmc, u32 mode, u32 polarity)
  */
 static int at91_pm_begin(suspend_state_t state)
 {
+	int ret;
+
 	switch (state) {
 	case PM_SUSPEND_MEM:
 		soc_pm.data.mode = soc_pm.data.suspend_mode;
@@ -227,7 +229,16 @@ static int at91_pm_begin(suspend_state_t state)
 		soc_pm.data.mode = -1;
 	}
 
-	return at91_pm_config_ws(soc_pm.data.mode, true);
+	ret = at91_pm_config_ws(soc_pm.data.mode, true);
+	if (ret)
+		return ret;
+
+	if (soc_pm.data.mode == AT91_PM_BACKUP)
+		soc_pm.bu->suspended = 1;
+	else if (soc_pm.bu)
+		soc_pm.bu->suspended = 0;
+
+	return 0;
 }
 
 /*
@@ -296,8 +307,6 @@ static int at91_suspend_finish(unsigned long val)
 static void at91_pm_suspend(suspend_state_t state)
 {
 	if (soc_pm.data.mode == AT91_PM_BACKUP) {
-		soc_pm.bu->suspended = 1;
-
 		cpu_suspend(0, at91_suspend_finish);
 
 		/* The SRAM is lost between suspend cycles */
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:51 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:51 +0300
Subject: [PATCH v3 05/24] ARM: at91: pm: do not initialize pdev
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-6-claudiu.beznea@microchip.com>

There is no need to initialize pdev.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5a6ce1d88971..65e13769cf50 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -659,7 +659,7 @@ static int __init at91_pm_backup_init(void)
 {
 	struct gen_pool *sram_pool;
 	struct device_node *np;
-	struct platform_device *pdev = NULL;
+	struct platform_device *pdev;
 	int ret = -ENODEV;
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:52 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:52 +0300
Subject: [PATCH v3 06/24] ARM: at91: pm: use r7 instead of tmp1
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-7-claudiu.beznea@microchip.com>

Use r7 instead of tmp1 in macros. This prepares the filed for
next commits.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index b683c2caa40b..3d20c9880fee 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -31,30 +31,36 @@ tmp3	.req	r6
 
 /*
  * Wait until master oscillator has stabilized.
+ *
+ * Side effects: overwrites r7
  */
 	.macro wait_moscrdy
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MOSCS
+1:	ldr	r7, [pmc, #AT91_PMC_SR]
+	tst	r7, #AT91_PMC_MOSCS
 	beq	1b
 	.endm
 
 /*
  * Wait for main oscillator selection is done
+ *
+ * Side effects: overwrites r7
  */
 	.macro wait_moscsels
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MOSCSELS
+1:	ldr	r7, [pmc, #AT91_PMC_SR]
+	tst	r7, #AT91_PMC_MOSCSELS
 	beq	1b
 	.endm
 
 /*
  * Put the processor to enter the idle state
+ *
+ * Side effects: overwrites r7
  */
 	.macro at91_cpu_idle
 
 #if defined(CONFIG_CPU_V7)
-	mov	tmp1, #AT91_PMC_PCK
-	str	tmp1, [pmc, #AT91_PMC_SCDR]
+	mov	r7, #AT91_PMC_PCK
+	str	r7, [pmc, #AT91_PMC_SCDR]
 
 	dsb
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:53 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:53 +0300
Subject: [PATCH v3 07/24] ARM: at91: pm: avoid push and pop on stack while
 memory is in self-refersh
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-8-claudiu.beznea@microchip.com>

For the previous AT91 RAM controller and self-refresh procedure this
had no side effects. However, for SAMA7G5 the self-refresh procedure
doesn't allow this anymore as the RAM controller ports are closed
before switching it to self-refresh. This commits prepares the code
for the following ones adding self-refresh and PM support for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 397 +++++++++++++++++---------------
 1 file changed, 205 insertions(+), 192 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 3d20c9880fee..960ad29cce51 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -75,98 +75,147 @@ tmp3	.req	r6
 
 	.arm
 
-/*
- * void at91_suspend_sram_fn(struct at91_pm_data*)
- * @input param:
- * 	@r0: base address of struct at91_pm_data
+/**
+ * Enable self-refresh
+ *
+ * register usage:
+ * 	@r1: memory type
+ *	@r2: base address of the sram controller
+ *	@r3: temporary
  */
-/* at91_pm_suspend_in_sram must be 8-byte aligned per the requirements of fncpy() */
-	.align 3
-ENTRY(at91_pm_suspend_in_sram)
-	/* Save registers on stack */
-	stmfd	sp!, {r4 - r12, lr}
+.macro at91_sramc_self_refresh_ena
+	ldr	r1, .memtype
+	ldr	r2, .sramc_base
 
-	/* Drain write buffer */
-	mov	tmp1, #0
-	mcr	p15, 0, tmp1, c7, c10, 4
+	cmp	r1, #AT91_MEMCTRL_MC
+	bne	sr_ena_ddrc_sf
 
-	ldr	tmp1, [r0, #PM_DATA_PMC]
-	str	tmp1, .pmc_base
-	ldr	tmp1, [r0, #PM_DATA_RAMC0]
-	str	tmp1, .sramc_base
-	ldr	tmp1, [r0, #PM_DATA_RAMC1]
-	str	tmp1, .sramc1_base
-	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
-	str	tmp1, .memtype
-	ldr	tmp1, [r0, #PM_DATA_MODE]
-	str	tmp1, .pm_mode
-	ldr	tmp1, [r0, #PM_DATA_PMC_MCKR_OFFSET]
-	str	tmp1, .mckr_offset
-	ldr	tmp1, [r0, #PM_DATA_PMC_VERSION]
-	str	tmp1, .pmc_version
-	/* Both ldrne below are here to preload their address in the TLB */
-	ldr	tmp1, [r0, #PM_DATA_SHDWC]
-	str	tmp1, .shdwc
-	cmp	tmp1, #0
-	ldrne	tmp2, [tmp1, #0]
-	ldr	tmp1, [r0, #PM_DATA_SFRBU]
-	str	tmp1, .sfrbu
-	cmp	tmp1, #0
-	ldrne	tmp2, [tmp1, #0x10]
+	/* Active SDRAM self-refresh mode */
+	mov	r3, #1
+	str	r3, [r2, #AT91_MC_SDRAMC_SRR]
+	b	sr_ena_exit
 
-	/* Active the self-refresh mode */
-	mov	r0, #SRAMC_SELF_FRESH_ACTIVE
-	bl	at91_sramc_self_refresh
+sr_ena_ddrc_sf:
+	cmp	r1, #AT91_MEMCTRL_DDRSDR
+	bne	sr_ena_sdramc_sf
 
-	ldr	r0, .pm_mode
-	cmp	r0, #AT91_PM_STANDBY
-	beq	standby
-	cmp	r0, #AT91_PM_BACKUP
-	beq	backup_mode
+	/*
+	 * DDR Memory controller
+	 */
 
-	bl	at91_ulp_mode
-	b	exit_suspend
+	/* LPDDR1 --> force DDR2 mode during self-refresh */
+	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
+	str	r3, .saved_sam9_mdr
+	bic	r3, r3, #~AT91_DDRSDRC_MD
+	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
+	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
+	biceq	r3, r3, #AT91_DDRSDRC_MD
+	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
+	streq	r3, [r2, #AT91_DDRSDRC_MDR]
 
-standby:
-	/* Wait for interrupt */
-	ldr	pmc, .pmc_base
-	at91_cpu_idle
-	b	exit_suspend
+	/* Active DDRC self-refresh mode */
+	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
+	str	r3, .saved_sam9_lpr
+	bic	r3, r3, #AT91_DDRSDRC_LPCB
+	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
 
-backup_mode:
-	bl	at91_backup_mode
-	b	exit_suspend
+	/* If using the 2nd ddr controller */
+	ldr	r2, .sramc1_base
+	cmp	r2, #0
+	beq	sr_ena_no_2nd_ddrc
 
-exit_suspend:
-	/* Exit the self-refresh mode */
-	mov	r0, #SRAMC_SELF_FRESH_EXIT
-	bl	at91_sramc_self_refresh
+	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
+	str	r3, .saved_sam9_mdr1
+	bic	r3, r3, #~AT91_DDRSDRC_MD
+	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
+	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
+	biceq	r3, r3, #AT91_DDRSDRC_MD
+	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
+	streq	r3, [r2, #AT91_DDRSDRC_MDR]
 
-	/* Restore registers, and return */
-	ldmfd	sp!, {r4 - r12, pc}
-ENDPROC(at91_pm_suspend_in_sram)
+	/* Active DDRC self-refresh mode */
+	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
+	str	r3, .saved_sam9_lpr1
+	bic	r3, r3, #AT91_DDRSDRC_LPCB
+	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
 
-ENTRY(at91_backup_mode)
-	/* Switch the master clock source to slow clock. */
-	ldr	pmc, .pmc_base
-	ldr	tmp2, .mckr_offset
-	ldr	tmp1, [pmc, tmp2]
-	bic	tmp1, tmp1, #AT91_PMC_CSS
-	str	tmp1, [pmc, tmp2]
+sr_ena_no_2nd_ddrc:
+	b	sr_ena_exit
 
-	wait_mckrdy
+	/*
+	 * SDRAMC Memory controller
+	 */
+sr_ena_sdramc_sf:
+	/* Active SDRAMC self-refresh mode */
+	ldr	r3, [r2, #AT91_SDRAMC_LPR]
+	str	r3, .saved_sam9_lpr
+	bic	r3, r3, #AT91_SDRAMC_LPCB
+	orr	r3, r3, #AT91_SDRAMC_LPCB_SELF_REFRESH
+	str	r3, [r2, #AT91_SDRAMC_LPR]
 
-	/*BUMEN*/
-	ldr	r0, .sfrbu
-	mov	tmp1, #0x1
-	str	tmp1, [r0, #0x10]
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_SDRAMC_LPR]
 
-	/* Shutdown */
-	ldr	r0, .shdwc
-	mov	tmp1, #0xA5000000
-	add	tmp1, tmp1, #0x1
-	str	tmp1, [r0, #0]
-ENDPROC(at91_backup_mode)
+sr_ena_exit:
+.endm
+
+/**
+ * Disable self-refresh
+ *
+ * register usage:
+ * 	@r1: memory type
+ *	@r2: base address of the sram controller
+ *	@r3: temporary
+ */
+.macro at91_sramc_self_refresh_dis
+	ldr	r1, .memtype
+	ldr	r2, .sramc_base
+
+	cmp	r1, #AT91_MEMCTRL_MC
+	bne	sr_dis_ddrc_exit_sf
+
+	/*
+	 * at91rm9200 Memory controller
+	 */
+
+	 /*
+	  * For exiting the self-refresh mode, do nothing,
+	  * automatically exit the self-refresh mode.
+	  */
+	b	sr_dis_exit
+
+sr_dis_ddrc_exit_sf:
+	cmp	r1, #AT91_MEMCTRL_DDRSDR
+	bne	sdramc_exit_sf
+
+	/* DDR Memory controller */
+
+	/* Restore MDR in case of LPDDR1 */
+	ldr	r3, .saved_sam9_mdr
+	str	r3, [r2, #AT91_DDRSDRC_MDR]
+	/* Restore LPR on AT91 with DDRAM */
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_DDRSDRC_LPR]
+
+	/* If using the 2nd ddr controller */
+	ldr	r2, .sramc1_base
+	cmp	r2, #0
+	ldrne	r3, .saved_sam9_mdr1
+	strne	r3, [r2, #AT91_DDRSDRC_MDR]
+	ldrne	r3, .saved_sam9_lpr1
+	strne	r3, [r2, #AT91_DDRSDRC_LPR]
+
+	b	sr_dis_exit
+
+sdramc_exit_sf:
+	/* SDRAMC Memory controller */
+	ldr	r3, .saved_sam9_lpr
+	str	r3, [r2, #AT91_SDRAMC_LPR]
+
+sr_dis_exit:
+.endm
 
 .macro at91_pm_ulp0_mode
 	ldr	pmc, .pmc_base
@@ -503,7 +552,7 @@ ENDPROC(at91_backup_mode)
 2:
 .endm
 
-ENTRY(at91_ulp_mode)
+.macro at91_ulp_mode
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
 	ldr	tmp3, .pm_mode
@@ -552,133 +601,97 @@ ulp_exit:
 
 	wait_mckrdy
 
-	mov	pc, lr
-ENDPROC(at91_ulp_mode)
-
-/*
- * void at91_sramc_self_refresh(unsigned int is_active)
- *
- * @input param:
- *	@r0: 1 - active self-refresh mode
- *	     0 - exit self-refresh mode
- * register usage:
- * 	@r1: memory type
- *	@r2: base address of the sram controller
- */
-
-ENTRY(at91_sramc_self_refresh)
-	ldr	r1, .memtype
-	ldr	r2, .sramc_base
-
-	cmp	r1, #AT91_MEMCTRL_MC
-	bne	ddrc_sf
-
-	/*
-	 * at91rm9200 Memory controller
-	 */
-
-	 /*
-	  * For exiting the self-refresh mode, do nothing,
-	  * automatically exit the self-refresh mode.
-	  */
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	exit_sramc_sf
-
-	/* Active SDRAM self-refresh mode */
-	mov	r3, #1
-	str	r3, [r2, #AT91_MC_SDRAMC_SRR]
-	b	exit_sramc_sf
-
-ddrc_sf:
-	cmp	r1, #AT91_MEMCTRL_DDRSDR
-	bne	sdramc_sf
+.endm
 
-	/*
-	 * DDR Memory controller
-	 */
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	ddrc_exit_sf
+.macro at91_backup_mode
+	/* Switch the master clock source to slow clock. */
+	ldr	pmc, .pmc_base
+	ldr	tmp2, .mckr_offset
+	ldr	tmp1, [pmc, tmp2]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	str	tmp1, [pmc, tmp2]
 
-	/* LPDDR1 --> force DDR2 mode during self-refresh */
-	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
-	str	r3, .saved_sam9_mdr
-	bic	r3, r3, #~AT91_DDRSDRC_MD
-	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
-	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
-	biceq	r3, r3, #AT91_DDRSDRC_MD
-	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
-	streq	r3, [r2, #AT91_DDRSDRC_MDR]
+	wait_mckrdy
 
-	/* Active DDRC self-refresh mode */
-	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
-	str	r3, .saved_sam9_lpr
-	bic	r3, r3, #AT91_DDRSDRC_LPCB
-	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/*BUMEN*/
+	ldr	r0, .sfrbu
+	mov	tmp1, #0x1
+	str	tmp1, [r0, #0x10]
 
-	/* If using the 2nd ddr controller */
-	ldr	r2, .sramc1_base
-	cmp	r2, #0
-	beq	no_2nd_ddrc
+	/* Shutdown */
+	ldr	r0, .shdwc
+	mov	tmp1, #0xA5000000
+	add	tmp1, tmp1, #0x1
+	str	tmp1, [r0, #0]
+.endm
 
-	ldr	r3, [r2, #AT91_DDRSDRC_MDR]
-	str	r3, .saved_sam9_mdr1
-	bic	r3, r3, #~AT91_DDRSDRC_MD
-	cmp	r3, #AT91_DDRSDRC_MD_LOW_POWER_DDR
-	ldreq	r3, [r2, #AT91_DDRSDRC_MDR]
-	biceq	r3, r3, #AT91_DDRSDRC_MD
-	orreq	r3, r3, #AT91_DDRSDRC_MD_DDR2
-	streq	r3, [r2, #AT91_DDRSDRC_MDR]
+/*
+ * void at91_suspend_sram_fn(struct at91_pm_data*)
+ * @input param:
+ * 	@r0: base address of struct at91_pm_data
+ */
+/* at91_pm_suspend_in_sram must be 8-byte aligned per the requirements of fncpy() */
+	.align 3
+ENTRY(at91_pm_suspend_in_sram)
+	/* Save registers on stack */
+	stmfd	sp!, {r4 - r12, lr}
 
-	/* Active DDRC self-refresh mode */
-	ldr	r3, [r2, #AT91_DDRSDRC_LPR]
-	str	r3, .saved_sam9_lpr1
-	bic	r3, r3, #AT91_DDRSDRC_LPCB
-	orr	r3, r3, #AT91_DDRSDRC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/* Drain write buffer */
+	mov	tmp1, #0
+	mcr	p15, 0, tmp1, c7, c10, 4
 
-no_2nd_ddrc:
-	b	exit_sramc_sf
+	ldr	tmp1, [r0, #PM_DATA_PMC]
+	str	tmp1, .pmc_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC0]
+	str	tmp1, .sramc_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC1]
+	str	tmp1, .sramc1_base
+	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
+	str	tmp1, .memtype
+	ldr	tmp1, [r0, #PM_DATA_MODE]
+	str	tmp1, .pm_mode
+	ldr	tmp1, [r0, #PM_DATA_PMC_MCKR_OFFSET]
+	str	tmp1, .mckr_offset
+	ldr	tmp1, [r0, #PM_DATA_PMC_VERSION]
+	str	tmp1, .pmc_version
+	/* Both ldrne below are here to preload their address in the TLB */
+	ldr	tmp1, [r0, #PM_DATA_SHDWC]
+	str	tmp1, .shdwc
+	cmp	tmp1, #0
+	ldrne	tmp2, [tmp1, #0]
+	ldr	tmp1, [r0, #PM_DATA_SFRBU]
+	str	tmp1, .sfrbu
+	cmp	tmp1, #0
+	ldrne	tmp2, [tmp1, #0x10]
 
-ddrc_exit_sf:
-	/* Restore MDR in case of LPDDR1 */
-	ldr	r3, .saved_sam9_mdr
-	str	r3, [r2, #AT91_DDRSDRC_MDR]
-	/* Restore LPR on AT91 with DDRAM */
-	ldr	r3, .saved_sam9_lpr
-	str	r3, [r2, #AT91_DDRSDRC_LPR]
+	/* Active the self-refresh mode */
+	at91_sramc_self_refresh_ena
 
-	/* If using the 2nd ddr controller */
-	ldr	r2, .sramc1_base
-	cmp	r2, #0
-	ldrne	r3, .saved_sam9_mdr1
-	strne	r3, [r2, #AT91_DDRSDRC_MDR]
-	ldrne	r3, .saved_sam9_lpr1
-	strne	r3, [r2, #AT91_DDRSDRC_LPR]
+	ldr	r0, .pm_mode
+	cmp	r0, #AT91_PM_STANDBY
+	beq	standby
+	cmp	r0, #AT91_PM_BACKUP
+	beq	backup_mode
 
-	b	exit_sramc_sf
+	at91_ulp_mode
+	b	exit_suspend
 
-	/*
-	 * SDRAMC Memory controller
-	 */
-sdramc_sf:
-	tst	r0, #SRAMC_SELF_FRESH_ACTIVE
-	beq	sdramc_exit_sf
+standby:
+	/* Wait for interrupt */
+	ldr	pmc, .pmc_base
+	at91_cpu_idle
+	b	exit_suspend
 
-	/* Active SDRAMC self-refresh mode */
-	ldr	r3, [r2, #AT91_SDRAMC_LPR]
-	str	r3, .saved_sam9_lpr
-	bic	r3, r3, #AT91_SDRAMC_LPCB
-	orr	r3, r3, #AT91_SDRAMC_LPCB_SELF_REFRESH
-	str	r3, [r2, #AT91_SDRAMC_LPR]
+backup_mode:
+	at91_backup_mode
 
-sdramc_exit_sf:
-	ldr	r3, .saved_sam9_lpr
-	str	r3, [r2, #AT91_SDRAMC_LPR]
+exit_suspend:
+	/* Exit the self-refresh mode */
+	at91_sramc_self_refresh_dis
 
-exit_sramc_sf:
-	mov	pc, lr
-ENDPROC(at91_sramc_self_refresh)
+	/* Restore registers, and return */
+	ldmfd	sp!, {r4 - r12, pc}
+ENDPROC(at91_pm_suspend_in_sram)
 
 .pmc_base:
 	.word 0
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:54 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:54 +0300
Subject: [PATCH v3 08/24] ARM: at91: pm:
 s/CONFIG_SOC_SAM9X60/CONFIG_HAVE_AT91_SAM9X60_PLL/g
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-9-claudiu.beznea@microchip.com>

Replace CONFIG_SOC_SAM9X60 with CONFIG_HAVE_AT91_SAM9X60_PLL as the
SAM9X60's PLL is also present on SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 960ad29cce51..1f63bbfad728 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -422,7 +422,7 @@ sr_dis_exit:
 	cmp	tmp1, #AT91_PMC_V1
 	beq	1f
 
-#ifdef CONFIG_SOC_SAM9X60
+#ifdef CONFIG_HAVE_AT91_SAM9X60_PLL
 	/* Save PLLA settings. */
 	ldr	tmp2, [pmc, #AT91_PMC_PLL_UPDT]
 	bic	tmp2, tmp2, #AT91_PMC_PLL_UPDT_ID
@@ -489,7 +489,7 @@ sr_dis_exit:
 	cmp	tmp3, #AT91_PMC_V1
 	beq	4f
 
-#ifdef CONFIG_SOC_SAM9X60
+#ifdef CONFIG_HAVE_AT91_SAM9X60_PLL
 	/* step 1. */
 	ldr	tmp1, [pmc, #AT91_PMC_PLL_UPDT]
 	bic	tmp1, tmp1, #AT91_PMC_PLL_UPDT_ID
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:55 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:55 +0300
Subject: [PATCH v3 09/24] ARM: at91: pm: add support for waiting MCK1..4
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-10-claudiu.beznea@microchip.com>

SAMA7G5 has 5 master clocks 0..4. MCK0 is controlled differently than
MCK 1..4. MCK 1..4 should also be saved/restored in the last phase of
suspend/resume. Thus, adapt wait_mckrdy to support also MCK1..4.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 48 ++++++++++++++++++++++++---------
 1 file changed, 35 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 1f63bbfad728..7669b32d5257 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -22,11 +22,23 @@ tmp3	.req	r6
 
 /*
  * Wait until master clock is ready (after switching master clock source)
+ *
+ * @r_mckid:	register holding master clock identifier
+ *
+ * Side effects: overwrites r7, r8
  */
-	.macro wait_mckrdy
-1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
-	tst	tmp1, #AT91_PMC_MCKRDY
-	beq	1b
+	.macro wait_mckrdy r_mckid
+#ifdef CONFIG_SOC_SAMA7
+	cmp	\r_mckid, #0
+	beq	1f
+	mov	r7, #AT91_PMC_MCKXRDY
+	b	2f
+#endif
+1:	mov	r7, #AT91_PMC_MCKRDY
+2:	ldr	r8, [pmc, #AT91_PMC_SR]
+	and	r8, r7
+	cmp	r8, r7
+	bne	2b
 	.endm
 
 /*
@@ -231,7 +243,9 @@ sr_dis_exit:
 	bic	tmp1, tmp1, #AT91_PMC_PRES
 	orr	tmp1, tmp1, #AT91_PMC_PRES_64
 	str	tmp1, [pmc, tmp3]
-	wait_mckrdy
+
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 	b	1f
 
 0:
@@ -267,10 +281,13 @@ sr_dis_exit:
 	bne	5f
 
 	/* Set lowest prescaler for fast resume. */
+	ldr	tmp3, .mckr_offset
 	ldr	tmp1, [pmc, tmp3]
 	bic	tmp1, tmp1, #AT91_PMC_PRES
 	str	tmp1, [pmc, tmp3]
-	wait_mckrdy
+
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 	b	6f
 
 5:	/* Restore RC oscillator state */
@@ -307,6 +324,7 @@ sr_dis_exit:
 .macro at91_pm_ulp1_mode
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
+	mov	tmp3, #0
 
 	/* Save RC oscillator state and check if it is enabled. */
 	ldr	tmp1, [pmc, #AT91_PMC_SR]
@@ -348,7 +366,7 @@ sr_dis_exit:
 	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Enter the ULP1 mode by set WAITMODE bit in CKGR_MOR */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -361,7 +379,7 @@ sr_dis_exit:
 	nop
 	nop
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Enable the crystal oscillator */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -377,7 +395,7 @@ sr_dis_exit:
 	bic	tmp1, tmp1, #AT91_PMC_CSS
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Switch main clock source to crystal oscillator */
 	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
@@ -394,7 +412,7 @@ sr_dis_exit:
 	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	wait_mckrdy tmp3
 
 	/* Restore RC oscillator state */
 	ldr	tmp1, .saved_osc_status
@@ -573,10 +591,12 @@ sr_dis_exit:
 save_mck:
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 	at91_plla_disable
 
+	ldr	tmp3, .pm_mode
 	cmp	tmp3, #AT91_PM_ULP1
 	beq	ulp1_mode
 
@@ -599,7 +619,8 @@ ulp_exit:
 	ldr	tmp2, .saved_mckr
 	str	tmp2, [pmc, tmp1]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 .endm
 
@@ -611,7 +632,8 @@ ulp_exit:
 	bic	tmp1, tmp1, #AT91_PMC_CSS
 	str	tmp1, [pmc, tmp2]
 
-	wait_mckrdy
+	mov	tmp3, #0
+	wait_mckrdy tmp3
 
 	/*BUMEN*/
 	ldr	r0, .sfrbu
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:56 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:56 +0300
Subject: [PATCH v3 10/24] ARM: at91: sfrbu: add sfrbu registers definitions
 for sama7g5
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-11-claudiu.beznea@microchip.com>

Add SFRBU registers definitions for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 include/soc/at91/sama7-sfrbu.h | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 include/soc/at91/sama7-sfrbu.h

diff --git a/include/soc/at91/sama7-sfrbu.h b/include/soc/at91/sama7-sfrbu.h
new file mode 100644
index 000000000000..76b740810d34
--- /dev/null
+++ b/include/soc/at91/sama7-sfrbu.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SAMA7 SFRBU registers offsets and bit definitions.
+ *
+ * Copyright (C) [2020] Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudu Beznea <claudiu.beznea at microchip.com>
+ */
+
+#ifndef __SAMA7_SFRBU_H__
+#define __SAMA7_SFRBU_H__
+
+#ifdef CONFIG_SOC_SAMA7
+
+#define AT91_SFRBU_PSWBU			(0x00)		/* SFRBU Power Switch BU Control Register */
+#define		AT91_SFRBU_PSWBU_PSWKEY		(0x4BD20C << 8)	/* Specific value mandatory to allow writing of other register bits */
+#define		AT91_SFRBU_PSWBU_STATE		(1 << 2)	/* Power switch BU state */
+#define		AT91_SFRBU_PSWBU_SOFTSWITCH	(1 << 1)	/* Power switch BU source selection */
+#define		AT91_SFRBU_PSWBU_CTRL		(1 << 0)	/* Power switch BU control */
+
+#define AT91_SFRBU_25LDOCR			(0x0C)		/* SFRBU 2.5V LDO Control Register */
+#define		AT91_SFRBU_25LDOCR_LDOANAKEY	(0x3B6E18 << 8)	/* Specific value mandatory to allow writing of other register bits. */
+#define		AT91_SFRBU_25LDOCR_STATE	(1 << 3)	/* LDOANA Switch On/Off Control */
+#define		AT91_SFRBU_25LDOCR_LP		(1 << 2)	/* LDOANA Low-Power Mode Control */
+#define		AT91_SFRBU_PD_VALUE_MSK		(0x3)
+#define		AT91_SFRBU_25LDOCR_PD_VALUE(v)	((v) & AT91_SFRBU_PD_VALUE_MSK)	/* LDOANA Pull-down value */
+
+#define AT91_FRBU_DDRPWR			(0x10)		/* SFRBU DDR Power Control Register */
+#define		AT91_FRBU_DDRPWR_STATE		(1 << 0)	/* DDR Power Mode State */
+
+#endif /* CONFIG_SOC_SAMA7 */
+
+#endif /* __SAMA7_SFRBU_H__ */
+
-- 
2.25.1



From a.fatoum at pengutronix.de  Thu Apr 15 11:51:23 2021
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Thu, 15 Apr 2021 12:51:23 +0200
Subject: [PATCH 10/13] dt-bindings: mfd: add vref_ddr-supply to st, stpmic1
 yaml
In-Reply-To: <20210415101037.1465-11-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-11-alexandre.torgue@foss.st.com>
Message-ID: <9fc27672-765b-9bd3-bb0a-d9159cb7d502@pengutronix.de>

Hi,

On 15.04.21 12:10, Alexandre Torgue wrote:
> Add vref_ddr-supply to the STPMIC1 regulators supplies pattern
> list.
> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
> 
> diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
> index 305123e74a58..ffc32d209496 100644
> --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
> +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
> @@ -184,7 +184,7 @@ properties:
>          additionalProperties: false
>  
>      patternProperties:
> -      "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
> +      "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])-supply$":

IIRC, vref-ddr was a hack because a change in the regulator core broke
the STM32MP1 boards. I believe vref-ddr should be removed altogether
instead. It's supplied from BUCK2IN, which is already in the binding,
so it's redundant.

Cheers,
Ahmad

>          description: STPMIC1 voltage regulators supplies
>  
>        "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
> 

-- 
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 claudiu.beznea at microchip.com  Thu Apr 15 11:49:58 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:58 +0300
Subject: [PATCH v3 12/24] ARM: at91: pm: add self-refresh support for sama7g5
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-13-claudiu.beznea@microchip.com>

Add self-refresh support for SAMA7G5.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.h              |   2 +
 arch/arm/mach-at91/pm_data-offsets.c |   2 +
 arch/arm/mach-at91/pm_suspend.S      | 199 +++++++++++++++++++++++++++
 3 files changed, 203 insertions(+)

diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index bfb260be371e..666474088d55 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -12,6 +12,7 @@
 #include <linux/mfd/syscon/atmel-mc.h>
 #include <soc/at91/at91sam9_ddrsdr.h>
 #include <soc/at91/at91sam9_sdramc.h>
+#include <soc/at91/sama7-ddr.h>
 
 #define AT91_MEMCTRL_MC		0
 #define AT91_MEMCTRL_SDRAMC	1
@@ -27,6 +28,7 @@
 struct at91_pm_data {
 	void __iomem *pmc;
 	void __iomem *ramc[2];
+	void __iomem *ramc_phy;
 	unsigned long uhp_udp_mask;
 	unsigned int memctrl;
 	unsigned int mode;
diff --git a/arch/arm/mach-at91/pm_data-offsets.c b/arch/arm/mach-at91/pm_data-offsets.c
index 82089ff258c0..40bd4e8fe40a 100644
--- a/arch/arm/mach-at91/pm_data-offsets.c
+++ b/arch/arm/mach-at91/pm_data-offsets.c
@@ -8,6 +8,8 @@ int main(void)
 	DEFINE(PM_DATA_PMC,		offsetof(struct at91_pm_data, pmc));
 	DEFINE(PM_DATA_RAMC0,		offsetof(struct at91_pm_data, ramc[0]));
 	DEFINE(PM_DATA_RAMC1,		offsetof(struct at91_pm_data, ramc[1]));
+	DEFINE(PM_DATA_RAMC_PHY,	offsetof(struct at91_pm_data,
+						 ramc_phy));
 	DEFINE(PM_DATA_MEMCTRL,	offsetof(struct at91_pm_data, memctrl));
 	DEFINE(PM_DATA_MODE,		offsetof(struct at91_pm_data, mode));
 	DEFINE(PM_DATA_SHDWC,		offsetof(struct at91_pm_data, shdwc));
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 7669b32d5257..84418120ba67 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -87,6 +87,200 @@ tmp3	.req	r6
 
 	.arm
 
+#ifdef CONFIG_SOC_SAMA7
+/**
+ * Enable self-refresh
+ *
+ * Side effects: overwrites r2, r3, tmp1, tmp2, tmp3, r7
+ */
+.macro at91_sramc_self_refresh_ena
+	ldr	r2, .sramc_base
+	ldr	r3, .sramc_phy_base
+	ldr	r7, .pm_mode
+
+	dsb
+
+	/* Disable all AXI ports. */
+	ldr	tmp1, [r2, #UDDRC_PCTRL_0]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_0]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_1]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_1]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_2]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_2]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_3]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_3]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_4]
+	bic	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_4]
+
+sr_ena_1:
+	/* Wait for all ports to disable. */
+	ldr	tmp1, [r2, #UDDRC_PSTAT]
+	ldr	tmp2, =UDDRC_PSTAT_ALL_PORTS
+	tst	tmp1, tmp2
+	bne	sr_ena_1
+
+	/* Switch to self-refresh. */
+	ldr	tmp1, [r2, #UDDRC_PWRCTL]
+	orr	tmp1, tmp1, #UDDRC_PWRCTRL_SELFREF_SW
+	str	tmp1, [r2, #UDDRC_PWRCTL]
+
+sr_ena_2:
+	/* Wait for self-refresh enter. */
+	ldr	tmp1, [r2, #UDDRC_STAT]
+	bic	tmp1, tmp1, #~UDDRC_STAT_SELFREF_TYPE_MSK
+	cmp	tmp1, #UDDRC_STAT_SELFREF_TYPE_SW
+	bne	sr_ena_2
+
+	/* Put DDR PHY's DLL in bypass mode for non-backup modes. */
+	cmp	r7, #AT91_PM_BACKUP
+	beq	sr_ena_3
+	ldr	tmp1, [r3, #DDR3PHY_PIR]
+	orr	tmp1, tmp1, #DDR3PHY_PIR_DLLBYP
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+sr_ena_3:
+	/* Power down DDR PHY data receivers. */
+	ldr	tmp1, [r3, #DDR3PHY_DXCCR]
+	orr	tmp1, tmp1, #DDR3PHY_DXCCR_DXPDR
+	str	tmp1, [r3, #DDR3PHY_DXCCR]
+
+	/* Power down ADDR/CMD IO. */
+	ldr	tmp1, [r3, #DDR3PHY_ACIOCR]
+	orr	tmp1, tmp1, #DDR3PHY_ACIORC_ACPDD
+	orr	tmp1, tmp1, #DDR3PHY_ACIOCR_CKPDD_CK0
+	orr	tmp1, tmp1, #DDR3PHY_ACIOCR_CSPDD_CS0
+	str	tmp1, [r3, #DDR3PHY_ACIOCR]
+
+	/* Power down ODT. */
+	ldr	tmp1, [r3, #DDR3PHY_DSGCR]
+	orr	tmp1, tmp1, #DDR3PHY_DSGCR_ODTPDD_ODT0
+	str	tmp1, [r3, #DDR3PHY_DSGCR]
+.endm
+
+/**
+ * Disable self-refresh
+ *
+ * Side effects: overwrites r2, r3, tmp1, tmp2, tmp3
+ */
+.macro at91_sramc_self_refresh_dis
+	ldr	r2, .sramc_base
+	ldr	r3, .sramc_phy_base
+
+	/* Power up DDR PHY data receivers. */
+	ldr	tmp1, [r3, #DDR3PHY_DXCCR]
+	bic	tmp1, tmp1, #DDR3PHY_DXCCR_DXPDR
+	str	tmp1, [r3, #DDR3PHY_DXCCR]
+
+	/* Power up the output of CK and CS pins. */
+	ldr	tmp1, [r3, #DDR3PHY_ACIOCR]
+	bic	tmp1, tmp1, #DDR3PHY_ACIORC_ACPDD
+	bic	tmp1, tmp1, #DDR3PHY_ACIOCR_CKPDD_CK0
+	bic	tmp1, tmp1, #DDR3PHY_ACIOCR_CSPDD_CS0
+	str	tmp1, [r3, #DDR3PHY_ACIOCR]
+
+	/* Power up ODT. */
+	ldr	tmp1, [r3, #DDR3PHY_DSGCR]
+	bic	tmp1, tmp1, #DDR3PHY_DSGCR_ODTPDD_ODT0
+	str	tmp1, [r3, #DDR3PHY_DSGCR]
+
+	/* Take DDR PHY's DLL out of bypass mode. */
+	ldr	tmp1, [r3, #DDR3PHY_PIR]
+	bic	tmp1, tmp1, #DDR3PHY_PIR_DLLBYP
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+	/* Enable quasi-dynamic programming. */
+	mov	tmp1, #0
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+	/* De-assert SDRAM initialization. */
+	ldr	tmp1, [r2, #UDDRC_DFIMISC]
+	bic	tmp1, tmp1, #UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN
+	str	tmp1, [r2, #UDDRC_DFIMISC]
+
+	/* Quasi-dynamic programming done. */
+	mov	tmp1, #UDDRC_SWCTRL_SW_DONE
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+sr_dis_1:
+	ldr	tmp1, [r2, #UDDRC_SWSTAT]
+	tst	tmp1, #UDDRC_SWSTAT_SW_DONE_ACK
+	beq	sr_dis_1
+
+	/* DLL soft-reset + DLL lock wait + ITM reset */
+	mov	tmp1, #(DDR3PHY_PIR_INIT | DDR3PHY_PIR_DLLSRST | \
+			DDR3PHY_PIR_DLLLOCK | DDR3PHY_PIR_ITMSRST)
+	str	tmp1, [r3, #DDR3PHY_PIR]
+
+sr_dis_4:
+	/* Wait for it. */
+	ldr	tmp1, [r3, #DDR3PHY_PGSR]
+	tst	tmp1, #DDR3PHY_PGSR_IDONE
+	beq	sr_dis_4
+
+	/* Enable quasi-dynamic programming. */
+	mov	tmp1, #0
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+	/* Assert PHY init complete enable signal. */
+	ldr	tmp1, [r2, #UDDRC_DFIMISC]
+	orr	tmp1, tmp1, #UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN
+	str	tmp1, [r2, #UDDRC_DFIMISC]
+
+	/* Programming is done. Set sw_done. */
+	mov	tmp1, #UDDRC_SWCTRL_SW_DONE
+	str	tmp1, [r2, #UDDRC_SWCTRL]
+
+sr_dis_5:
+	/* Wait for it. */
+	ldr	tmp1, [r2, #UDDRC_SWSTAT]
+	tst	tmp1, #UDDRC_SWSTAT_SW_DONE_ACK
+	beq	sr_dis_5
+
+	/* Trigger self-refresh exit. */
+	ldr	tmp1, [r2, #UDDRC_PWRCTL]
+	bic	tmp1, tmp1, #UDDRC_PWRCTRL_SELFREF_SW
+	str	tmp1, [r2, #UDDRC_PWRCTL]
+
+sr_dis_6:
+	/* Wait for self-refresh exit done. */
+	ldr	tmp1, [r2, #UDDRC_STAT]
+	bic	tmp1, tmp1, #~UDDRC_STAT_OPMODE_MSK
+	cmp	tmp1, #UDDRC_STAT_OPMODE_NORMAL
+	bne	sr_dis_6
+
+	/* Enable all AXI ports. */
+	ldr	tmp1, [r2, #UDDRC_PCTRL_0]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_0]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_1]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_1]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_2]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_2]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_3]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_3]
+
+	ldr	tmp1, [r2, #UDDRC_PCTRL_4]
+	orr	tmp1, tmp1, #0x1
+	str	tmp1, [r2, #UDDRC_PCTRL_4]
+
+	dsb
+.endm
+#else
 /**
  * Enable self-refresh
  *
@@ -228,6 +422,7 @@ sdramc_exit_sf:
 
 sr_dis_exit:
 .endm
+#endif
 
 .macro at91_pm_ulp0_mode
 	ldr	pmc, .pmc_base
@@ -668,6 +863,8 @@ ENTRY(at91_pm_suspend_in_sram)
 	str	tmp1, .sramc_base
 	ldr	tmp1, [r0, #PM_DATA_RAMC1]
 	str	tmp1, .sramc1_base
+	ldr	tmp1, [r0, #PM_DATA_RAMC_PHY]
+	str	tmp1, .sramc_phy_base
 	ldr	tmp1, [r0, #PM_DATA_MEMCTRL]
 	str	tmp1, .memtype
 	ldr	tmp1, [r0, #PM_DATA_MODE]
@@ -721,6 +918,8 @@ ENDPROC(at91_pm_suspend_in_sram)
 	.word 0
 .sramc1_base:
 	.word 0
+.sramc_phy_base:
+	.word 0
 .shdwc:
 	.word 0
 .sfrbu:
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:57 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:57 +0300
Subject: [PATCH v3 11/24] ARM: at91: ddr: add registers definitions for
 sama7g5's ddr
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-12-claudiu.beznea@microchip.com>

Add registers and bits definitions for SAMA7G5's UDDRC and DDR3PHY.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 include/soc/at91/sama7-ddr.h | 80 ++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 include/soc/at91/sama7-ddr.h

diff --git a/include/soc/at91/sama7-ddr.h b/include/soc/at91/sama7-ddr.h
new file mode 100644
index 000000000000..f6542584ca13
--- /dev/null
+++ b/include/soc/at91/sama7-ddr.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Microchip SAMA7 UDDR Controller and DDR3 PHY Controller registers offsets
+ * and bit definitions.
+ *
+ * Copyright (C) [2020] Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudu Beznea <claudiu.beznea at microchip.com>
+ */
+
+#ifndef __SAMA7_DDR_H__
+#define __SAMA7_DDR_H__
+
+#ifdef CONFIG_SOC_SAMA7
+
+/* DDR3PHY */
+#define DDR3PHY_PIR				(0x04)		/* DDR3PHY PHY Initialization Register	*/
+#define	DDR3PHY_PIR_DLLBYP		(1 << 17)	/* DLL Bypass */
+#define		DDR3PHY_PIR_ITMSRST		(1 << 4)	/* Interface Timing Module Soft Reset */
+#define	DDR3PHY_PIR_DLLLOCK		(1 << 2)	/* DLL Lock */
+#define		DDR3PHY_PIR_DLLSRST		(1 << 1)	/* DLL Soft Rest */
+#define	DDR3PHY_PIR_INIT		(1 << 0)	/* Initialization Trigger */
+
+#define DDR3PHY_PGCR				(0x08)		/* DDR3PHY PHY General Configuration Register */
+#define		DDR3PHY_PGCR_CKDV1		(1 << 13)	/* CK# Disable Value */
+#define		DDR3PHY_PGCR_CKDV0		(1 << 12)	/* CK Disable Value */
+
+#define	DDR3PHY_PGSR				(0x0C)		/* DDR3PHY PHY General Status Register */
+#define		DDR3PHY_PGSR_IDONE		(1 << 0)	/* Initialization Done */
+
+#define DDR3PHY_ACIOCR				(0x24)		/*  DDR3PHY AC I/O Configuration Register */
+#define		DDR3PHY_ACIOCR_CSPDD_CS0	(1 << 18)	/* CS#[0] Power Down Driver */
+#define		DDR3PHY_ACIOCR_CKPDD_CK0	(1 << 8)	/* CK[0] Power Down Driver */
+#define		DDR3PHY_ACIORC_ACPDD		(1 << 3)	/* AC Power Down Driver */
+
+#define DDR3PHY_DXCCR				(0x28)		/* DDR3PHY DATX8 Common Configuration Register */
+#define		DDR3PHY_DXCCR_DXPDR		(1 << 3)	/* Data Power Down Receiver */
+
+#define DDR3PHY_DSGCR				(0x2C)		/* DDR3PHY DDR System General Configuration Register */
+#define		DDR3PHY_DSGCR_ODTPDD_ODT0	(1 << 20)	/* ODT[0] Power Down Driver */
+
+#define DDR3PHY_ZQ0SR0				(0x188)		/* ZQ status register 0 */
+
+/* UDDRC */
+#define UDDRC_STAT				(0x04)		/* UDDRC Operating Mode Status Register */
+#define		UDDRC_STAT_SELFREF_TYPE_DIS	(0x0 << 4)	/* SDRAM is not in Self-refresh */
+#define		UDDRC_STAT_SELFREF_TYPE_PHY	(0x1 << 4)	/* SDRAM is in Self-refresh, which was caused by PHY Master Request */
+#define		UDDRC_STAT_SELFREF_TYPE_SW	(0x2 << 4)	/* SDRAM is in Self-refresh, which was not caused solely under Automatic Self-refresh control */
+#define		UDDRC_STAT_SELFREF_TYPE_AUTO	(0x3 << 4)	/* SDRAM is in Self-refresh, which was caused by Automatic Self-refresh only */
+#define		UDDRC_STAT_SELFREF_TYPE_MSK	(0x3 << 4)	/* Self-refresh type mask */
+#define		UDDRC_STAT_OPMODE_INIT		(0x0 << 0)	/* Init */
+#define		UDDRC_STAT_OPMODE_NORMAL	(0x1 << 0)	/* Normal */
+#define		UDDRC_STAT_OPMODE_PWRDOWN	(0x2 << 0)	/* Power-down */
+#define		UDDRC_STAT_OPMODE_SELF_REFRESH	(0x3 << 0)	/* Self-refresh */
+#define		UDDRC_STAT_OPMODE_MSK		(0x7 << 0)	/* Operating mode mask */
+
+#define UDDRC_PWRCTL				(0x30)		/* UDDRC Low Power Control Register */
+#define		UDDRC_PWRCTRL_SELFREF_SW	(1 << 5)	/* Software self-refresh */
+
+#define UDDRC_DFIMISC				(0x1B0)		/* UDDRC DFI Miscellaneous Control Register */
+#define		UDDRC_DFIMISC_DFI_INIT_COMPLETE_EN (1 << 0)	/* PHY initialization complete enable signal */
+
+#define UDDRC_SWCTRL				(0x320)		/* UDDRC Software Register Programming Control Enable */
+#define		UDDRC_SWCTRL_SW_DONE		(1 << 0)	/* Enable quasi-dynamic register programming outside reset */
+
+#define UDDRC_SWSTAT				(0x324)		/* UDDRC Software Register Programming Control Status */
+#define		UDDRC_SWSTAT_SW_DONE_ACK	(1 << 0)	/* Register programming done */
+
+#define UDDRC_PSTAT				(0x3FC)		/* UDDRC Port Status Register */
+#define	UDDRC_PSTAT_ALL_PORTS		(0x1F001F)	/* Read + writes outstanding transactions on all ports */
+
+#define UDDRC_PCTRL_0				(0x490)		/* UDDRC Port 0 Control Register */
+#define UDDRC_PCTRL_1				(0x540)		/* UDDRC Port 1 Control Register */
+#define UDDRC_PCTRL_2				(0x5F0)		/* UDDRC Port 2 Control Register */
+#define UDDRC_PCTRL_3				(0x6A0)		/* UDDRC Port 3 Control Register */
+#define UDDRC_PCTRL_4				(0x750)		/* UDDRC Port 4 Control Register */
+
+#endif /* CONFIG_SOC_SAMA7 */
+
+#endif /* __SAMA7_DDR_H__ */
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:49:59 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:49:59 +0300
Subject: [PATCH v3 13/24] ARM: at91: pm: add support for MCK1..4 save/restore
 for ulp modes
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-14-claudiu.beznea@microchip.com>

Add support for MCK1..4 save restore for ULP modes.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 126 ++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 84418120ba67..8b0b8619ee8a 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -765,7 +765,122 @@ sr_dis_exit:
 2:
 .endm
 
+/**
+ * at91_mckx_ps_enable:	save MCK1..4 settings and switch it to main clock
+ *
+ * Side effects: overwrites tmp1, tmp2
+ */
+.macro at91_mckx_ps_enable
+#ifdef CONFIG_SOC_SAMA7
+	ldr	pmc, .pmc_base
+
+	/* There are 4 MCKs we need to handle: MCK1..4 */
+	mov	tmp1, #1
+e_loop:	cmp	tmp1, #5
+	beq	e_done
+
+	/* Write MCK ID to retrieve the settings. */
+	str	tmp1, [pmc, #AT91_PMC_MCR_V2]
+	ldr	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+e_save_mck1:
+	cmp	tmp1, #1
+	bne	e_save_mck2
+	str	tmp2, .saved_mck1
+	b	e_ps
+
+e_save_mck2:
+	cmp	tmp1, #2
+	bne	e_save_mck3
+	str	tmp2, .saved_mck2
+	b	e_ps
+
+e_save_mck3:
+	cmp	tmp1, #3
+	bne	e_save_mck4
+	str	tmp2, .saved_mck3
+	b	e_ps
+
+e_save_mck4:
+	str	tmp2, .saved_mck4
+
+e_ps:
+	/* Use CSS=MAINCK and DIV=1. */
+	bic	tmp2, tmp2, #AT91_PMC_MCR_V2_CSS
+	bic	tmp2, tmp2, #AT91_PMC_MCR_V2_DIV
+	orr	tmp2, tmp2, #AT91_PMC_MCR_V2_CSS_MAINCK
+	orr	tmp2, tmp2, #AT91_PMC_MCR_V2_DIV1
+	str	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+	wait_mckrdy tmp1
+
+	add	tmp1, tmp1, #1
+	b	e_loop
+
+e_done:
+#endif
+.endm
+
+/**
+ * at91_mckx_ps_restore: restore MCK1..4 settings
+ *
+ * Side effects: overwrites tmp1, tmp2
+ */
+.macro at91_mckx_ps_restore
+#ifdef CONFIG_SOC_SAMA7
+	ldr	pmc, .pmc_base
+
+	/* There are 4 MCKs we need to handle: MCK1..4 */
+	mov	tmp1, #1
+r_loop:	cmp	tmp1, #5
+	beq	r_done
+
+r_save_mck1:
+	cmp	tmp1, #1
+	bne	r_save_mck2
+	ldr	tmp2, .saved_mck1
+	b	r_ps
+
+r_save_mck2:
+	cmp	tmp1, #2
+	bne	r_save_mck3
+	ldr	tmp2, .saved_mck2
+	b	r_ps
+
+r_save_mck3:
+	cmp	tmp1, #3
+	bne	r_save_mck4
+	ldr	tmp2, .saved_mck3
+	b	r_ps
+
+r_save_mck4:
+	ldr	tmp2, .saved_mck4
+
+r_ps:
+	/* Write MCK ID to retrieve the settings. */
+	str	tmp1, [pmc, #AT91_PMC_MCR_V2]
+	ldr	tmp3, [pmc, #AT91_PMC_MCR_V2]
+
+	/* We need to restore CSS and DIV. */
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_CSS
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_DIV
+	orr	tmp3, tmp3, tmp2
+	bic	tmp3, tmp3, #AT91_PMC_MCR_V2_ID_MSK
+	orr	tmp3, tmp3, tmp1
+	orr	tmp3, tmp3, #AT91_PMC_MCR_V2_CMD
+	str	tmp2, [pmc, #AT91_PMC_MCR_V2]
+
+	wait_mckrdy tmp1
+
+	add	tmp1, tmp1, #1
+	b	r_loop
+r_done:
+#endif
+.endm
+
 .macro at91_ulp_mode
+	at91_mckx_ps_enable
+
 	ldr	pmc, .pmc_base
 	ldr	tmp2, .mckr_offset
 	ldr	tmp3, .pm_mode
@@ -817,6 +932,7 @@ ulp_exit:
 	mov	tmp3, #0
 	wait_mckrdy tmp3
 
+	at91_mckx_ps_restore
 .endm
 
 .macro at91_backup_mode
@@ -946,6 +1062,16 @@ ENDPROC(at91_pm_suspend_in_sram)
 	.word 0
 .saved_osc_status:
 	.word 0
+#ifdef CONFIG_SOC_SAMA7
+.saved_mck1:
+	.word 0
+.saved_mck2:
+	.word 0
+.saved_mck3:
+	.word 0
+.saved_mck4:
+	.word 0
+#endif
 
 ENTRY(at91_pm_suspend_in_sram_sz)
 	.word .-at91_pm_suspend_in_sram
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:00 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:00 +0300
Subject: [PATCH v3 14/24] ARM: at91: pm: add support for 2.5V LDO regulator
 control
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-15-claudiu.beznea@microchip.com>

Add support to disable/enable 2.5V LDO regulator when entering/exiting
any ULP mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.h         |  1 +
 arch/arm/mach-at91/pm_suspend.S | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 666474088d55..53bdc9000e44 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -13,6 +13,7 @@
 #include <soc/at91/at91sam9_ddrsdr.h>
 #include <soc/at91/at91sam9_sdramc.h>
 #include <soc/at91/sama7-ddr.h>
+#include <soc/at91/sama7-sfrbu.h>
 
 #define AT91_MEMCTRL_MC		0
 #define AT91_MEMCTRL_SDRAMC	1
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 8b0b8619ee8a..9c9e08fd8300 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -83,6 +83,29 @@ tmp3	.req	r6
 
 	.endm
 
+/**
+ * Set state for 2.5V low power regulator
+ * @ena: 0 - disable regulator
+ *	 1 - enable regulator
+ *
+ * Side effects: overwrites r7, r8, r9, r10
+ */
+	.macro at91_2_5V_reg_set_low_power ena
+#ifdef CONFIG_SOC_SAMA7
+	ldr	r7, .sfrbu
+	mov	r8, #\ena
+	ldr	r9, [r7, #AT91_SFRBU_25LDOCR]
+	orr	r9, r9, #AT91_SFRBU_25LDOCR_LP
+	cmp	r8, #1
+	beq	lp_done_\ena
+	bic	r9, r9, #AT91_SFRBU_25LDOCR_LP
+lp_done_\ena:
+	ldr	r10, =AT91_SFRBU_25LDOCR_LDOANAKEY
+	orr	r9, r9, r10
+	str	r9, [r7, #AT91_SFRBU_25LDOCR]
+#endif
+	.endm
+
 	.text
 
 	.arm
@@ -906,6 +929,9 @@ save_mck:
 
 	at91_plla_disable
 
+	/* Enable low power mode for 2.5V regulator. */
+	at91_2_5V_reg_set_low_power 1
+
 	ldr	tmp3, .pm_mode
 	cmp	tmp3, #AT91_PM_ULP1
 	beq	ulp1_mode
@@ -918,6 +944,9 @@ ulp1_mode:
 	b	ulp_exit
 
 ulp_exit:
+	/* Disable low power mode for 2.5V regulator. */
+	at91_2_5V_reg_set_low_power 0
+
 	ldr	pmc, .pmc_base
 
 	at91_plla_enable
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:01 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:01 +0300
Subject: [PATCH v3 15/24] ARM: at91: pm: wait for ddr power mode off
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-16-claudiu.beznea@microchip.com>

Wait for DDR power mode off before shutting down the core.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm_suspend.S | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 9c9e08fd8300..7396e18dd7e5 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -980,6 +980,11 @@ ulp_exit:
 	mov	tmp1, #0x1
 	str	tmp1, [r0, #0x10]
 
+	/* Wait for it. */
+1:	ldr	tmp1, [r0, #0x10]
+	tst	tmp1, #0x1
+	beq	1b
+
 	/* Shutdown */
 	ldr	r0, .shdwc
 	mov	tmp1, #0xA5000000
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:02 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:02 +0300
Subject: [PATCH v3 16/24] dt-bindings: atmel-sysreg: add bindings for sama7g5
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-17-claudiu.beznea@microchip.com>

Add RAM controller and RAM PHY controller DT bindings.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 .../devicetree/bindings/arm/atmel-sysregs.txt      | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
index 807264a78edc..16eef600d599 100644
--- a/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-sysregs.txt
@@ -45,7 +45,8 @@ RAMC SDRAM/DDR Controller required properties:
 			"atmel,at91sam9260-sdramc",
 			"atmel,at91sam9g45-ddramc",
 			"atmel,sama5d3-ddramc",
-			"microchip,sam9x60-ddramc"
+			"microchip,sam9x60-ddramc",
+			"microchip,sama7g5-uddrc"
 - reg: Should contain registers location and length
 
 Examples:
@@ -55,6 +56,17 @@ Examples:
 		reg = <0xffffe800 0x200>;
 	};
 
+RAMC PHY Controller required properties:
+- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
+- reg: Should contain registers location and length
+
+Example:
+
+	ddr3phy: ddr3phy at e3804000 {
+		compatible = "microchip,sama7g5-ddr3phy", "syscon";
+		reg = <0xe3804000 0x1000>;
+};
+
 SHDWC Shutdown Controller
 
 required properties:
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:03 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:03 +0300
Subject: [PATCH v3 17/24] ARM: at91: pm: add sama7g5 ddr controller
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-18-claudiu.beznea@microchip.com>

Add SAMA7G5 DDR controller to the list of DDR controller compatibles.
At the moment there is no standby support. Adapt the code for this.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 65e13769cf50..5dc942a2012d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -548,6 +548,7 @@ static const struct of_device_id ramc_ids[] __initconst = {
 	{ .compatible = "atmel,at91sam9260-sdramc", .data = &ramc_infos[1] },
 	{ .compatible = "atmel,at91sam9g45-ddramc", .data = &ramc_infos[2] },
 	{ .compatible = "atmel,sama5d3-ddramc", .data = &ramc_infos[3] },
+	{ .compatible = "microchip,sama7g5-uddrc", },
 	{ /*sentinel*/ }
 };
 
@@ -565,9 +566,11 @@ static __init void at91_dt_ramc(void)
 			panic(pr_fmt("unable to map ramc[%d] cpu registers\n"), idx);
 
 		ramc = of_id->data;
-		if (!standby)
-			standby = ramc->idle;
-		soc_pm.data.memctrl = ramc->memctrl;
+		if (ramc) {
+			if (!standby)
+				standby = ramc->idle;
+			soc_pm.data.memctrl = ramc->memctrl;
+		}
 
 		idx++;
 	}
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:04 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:04 +0300
Subject: [PATCH v3 18/24] ARM: at91: pm: add sama7g5 ddr phy controller
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-19-claudiu.beznea@microchip.com>

SAMA7G5 self-refresh procedure accesses also the DDR PHY registers.
Adapt the code so that the at91_dt_ramc() to look also for DDR PHYs,
in case it is mandatory.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5dc942a2012d..4dec7216a80e 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -552,7 +552,12 @@ static const struct of_device_id ramc_ids[] __initconst = {
 	{ /*sentinel*/ }
 };
 
-static __init void at91_dt_ramc(void)
+static const struct of_device_id ramc_phy_ids[] __initconst = {
+	{ .compatible = "microchip,sama7g5-ddr3phy", },
+	{ /* Sentinel. */ },
+};
+
+static __init void at91_dt_ramc(bool phy_mandatory)
 {
 	struct device_node *np;
 	const struct of_device_id *of_id;
@@ -578,6 +583,16 @@ static __init void at91_dt_ramc(void)
 	if (!idx)
 		panic(pr_fmt("unable to find compatible ram controller node in dtb\n"));
 
+	/* Lookup for DDR PHY node, if any. */
+	for_each_matching_node_and_match(np, ramc_phy_ids, &of_id) {
+		soc_pm.data.ramc_phy = of_iomap(np, 0);
+		if (!soc_pm.data.ramc_phy)
+			panic(pr_fmt("unable to map ramc phy cpu registers\n"));
+	}
+
+	if (phy_mandatory && !soc_pm.data.ramc_phy)
+		panic(pr_fmt("DDR PHY is mandatory!\n"));
+
 	if (!standby) {
 		pr_warn("ramc no standby function available\n");
 		return;
@@ -936,7 +951,7 @@ void __init at91rm9200_pm_init(void)
 	soc_pm.data.standby_mode = AT91_PM_STANDBY;
 	soc_pm.data.suspend_mode = AT91_PM_ULP0;
 
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 
 	/*
 	 * AT91RM9200 SDRAM low-power mode cannot be used with self-refresh.
@@ -960,7 +975,7 @@ void __init sam9x60_pm_init(void)
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
 	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 
 	soc_pm.ws_ids = sam9x60_ws_ids;
@@ -980,7 +995,7 @@ void __init at91sam9_pm_init(void)
 	soc_pm.data.standby_mode = AT91_PM_STANDBY;
 	soc_pm.data.suspend_mode = AT91_PM_ULP0;
 
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(at91sam9_idle);
 }
 
@@ -994,7 +1009,7 @@ void __init sama5_pm_init(void)
 		return;
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 }
 
@@ -1015,7 +1030,7 @@ void __init sama5d2_pm_init(void)
 
 	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
 	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
-	at91_dt_ramc();
+	at91_dt_ramc(false);
 	at91_pm_init(NULL);
 
 	soc_pm.ws_ids = sama5d2_ws_ids;
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:05 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:05 +0300
Subject: [PATCH v3 19/24] ARM: at91: pm: save ddr phy calibration data to
 securam
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-20-claudiu.beznea@microchip.com>

The resuming from backup mode is done with the help of bootloader.
The bootloader reconfigure the DDR controller and DDR PHY controller.
To speed-up the resuming process save the PHY calibration data into
SECURAM before suspending (securam is powered on backup mode).
This data will be later used by bootloader in DDR PHY reconfiguration
process. Also, in the process or recalibration the first 8 words of
the memory may get corrupted. To solve this, these 8 words are saved
in the securam and restored by bootloader in the process of PHY
configuration.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 60 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 4dec7216a80e..91b4014d2e10 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -10,6 +10,7 @@
 #include <linux/io.h>
 #include <linux/of_address.h>
 #include <linux/of.h>
+#include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/parser.h>
 #include <linux/suspend.h>
@@ -27,18 +28,23 @@
 #include "generic.h"
 #include "pm.h"
 
+#define BACKUP_DDR_PHY_CALIBRATION	(9)
+
 /**
  * struct at91_pm_bu - AT91 power management backup unit data structure
  * @suspended: true if suspended to backup mode
  * @reserved: reserved
  * @canary: canary data for memory checking after exit from backup mode
  * @resume: resume API
+ * @ddr_phy_calibration: DDR PHY calibration data: ZQ0CR0, first 8 words
+ * of the memory
  */
 struct at91_pm_bu {
 	int suspended;
 	unsigned long reserved;
 	phys_addr_t canary;
 	phys_addr_t resume;
+	unsigned long ddr_phy_calibration[BACKUP_DDR_PHY_CALIBRATION];
 };
 
 /**
@@ -48,6 +54,7 @@ struct at91_pm_bu {
  * @ws_ids: wakup sources of_device_id array
  * @data: PM data to be used on last phase of suspend
  * @bu: backup unit mapped data (for backup mode)
+ * @memcs: memory chip select
  */
 struct at91_soc_pm {
 	int (*config_shdwc_ws)(void __iomem *shdwc, u32 *mode, u32 *polarity);
@@ -55,6 +62,7 @@ struct at91_soc_pm {
 	const struct of_device_id *ws_ids;
 	struct at91_pm_bu *bu;
 	struct at91_pm_data data;
+	void *memcs;
 };
 
 /**
@@ -316,6 +324,19 @@ extern u32 at91_pm_suspend_in_sram_sz;
 
 static int at91_suspend_finish(unsigned long val)
 {
+	int i;
+
+	if (soc_pm.data.mode == AT91_PM_BACKUP && soc_pm.data.ramc_phy) {
+		/*
+		 * The 1st 8 words of memory might get corrupted in the process
+		 * of DDR PHY recalibration; it is saved here in securam and it
+		 * will be restored later, after recalibration, by bootloader
+		 */
+		for (i = 1; i < BACKUP_DDR_PHY_CALIBRATION; i++)
+			soc_pm.bu->ddr_phy_calibration[i] =
+				*((unsigned int *)soc_pm.memcs + (i - 1));
+	}
+
 	flush_cache_all();
 	outer_disable();
 
@@ -673,12 +694,40 @@ static bool __init at91_is_pm_mode_active(int pm_mode)
 		soc_pm.data.suspend_mode == pm_mode);
 }
 
+static int __init at91_pm_backup_scan_memcs(unsigned long node,
+					    const char *uname, int depth,
+					    void *data)
+{
+	const char *type;
+	const __be32 *reg;
+	int *located = data;
+	int size;
+
+	/* Memory node already located. */
+	if (*located)
+		return 0;
+
+	type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	/* We are scanning "memory" nodes only. */
+	if (!type || strcmp(type, "memory"))
+		return 0;
+
+	reg = of_get_flat_dt_prop(node, "reg", &size);
+	if (reg) {
+		soc_pm.memcs = __va((phys_addr_t)be32_to_cpu(*reg));
+		*located = 1;
+	}
+
+	return 0;
+}
+
 static int __init at91_pm_backup_init(void)
 {
 	struct gen_pool *sram_pool;
 	struct device_node *np;
 	struct platform_device *pdev;
-	int ret = -ENODEV;
+	int ret = -ENODEV, located = 0;
 
 	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
 		return -EPERM;
@@ -713,6 +762,15 @@ static int __init at91_pm_backup_init(void)
 	soc_pm.bu->suspended = 0;
 	soc_pm.bu->canary = __pa_symbol(&canary);
 	soc_pm.bu->resume = __pa_symbol(cpu_resume);
+	if (soc_pm.data.ramc_phy) {
+		of_scan_flat_dt(at91_pm_backup_scan_memcs, &located);
+		if (!located)
+			goto securam_fail;
+
+		/* DDR3PHY_ZQ0SR0 */
+		soc_pm.bu->ddr_phy_calibration[0] = readl(soc_pm.data.ramc_phy +
+							  0x188);
+	}
 
 	return 0;
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:06 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:06 +0300
Subject: [PATCH v3 20/24] ARM: at91: pm: add backup mode support for SAMA7G5
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-21-claudiu.beznea@microchip.com>

Adapt at91_pm_backup_init() to work for SAMA7G5. Also, set the LPM pin
to shutdown controller. This will signal to PMIC that it needs to switch
to the state corresponding to backup mode.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c         | 3 ++-
 arch/arm/mach-at91/pm_suspend.S | 7 +++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 91b4014d2e10..fcb20272d65d 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -729,7 +729,8 @@ static int __init at91_pm_backup_init(void)
 	struct platform_device *pdev;
 	int ret = -ENODEV, located = 0;
 
-	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2))
+	if (!IS_ENABLED(CONFIG_SOC_SAMA5D2) &&
+	    !IS_ENABLED(CONFIG_SOC_SAMA7G5))
 		return -EPERM;
 
 	if (!at91_is_pm_mode_active(AT91_PM_BACKUP))
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 7396e18dd7e5..cbd61a3bcab1 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -106,6 +106,12 @@ lp_done_\ena:
 #endif
 	.endm
 
+	.macro at91_backup_set_lpm reg
+#ifdef CONFIG_SOC_SAMA7
+	orr	\reg, \reg, #0x200000
+#endif
+	.endm
+
 	.text
 
 	.arm
@@ -989,6 +995,7 @@ ulp_exit:
 	ldr	r0, .shdwc
 	mov	tmp1, #0xA5000000
 	add	tmp1, tmp1, #0x1
+	at91_backup_set_lpm tmp1
 	str	tmp1, [r0, #0]
 .endm
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:07 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:07 +0300
Subject: [PATCH v3 21/24] ARM: at91: pm: add sama7g5's pmc
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-22-claudiu.beznea@microchip.com>

Add SAMA7G5's PMC to compatible list.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index fcb20272d65d..f4e66a7c7d18 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -897,6 +897,11 @@ static const struct pmc_info pmc_infos[] __initconst = {
 		.mckr = 0x28,
 		.version = AT91_PMC_V2,
 	},
+	{
+		.mckr = 0x28,
+		.version = AT91_PMC_V2,
+	},
+
 };
 
 static const struct of_device_id atmel_pmc_ids[] __initconst = {
@@ -912,6 +917,7 @@ static const struct of_device_id atmel_pmc_ids[] __initconst = {
 	{ .compatible = "atmel,sama5d4-pmc", .data = &pmc_infos[1] },
 	{ .compatible = "atmel,sama5d2-pmc", .data = &pmc_infos[1] },
 	{ .compatible = "microchip,sam9x60-pmc", .data = &pmc_infos[4] },
+	{ .compatible = "microchip,sama7g5-pmc", .data = &pmc_infos[5] },
 	{ /* sentinel */ },
 };
 
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:08 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:08 +0300
Subject: [PATCH v3 22/24] ARM: at91: sama7: introduce sama7 SoC family
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-23-claudiu.beznea@microchip.com>

From: Eugen Hristev <eugen.hristev at microchip.com>

Introduce new family of SoCs, sama7, and first SoC, sama7g5.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
[claudiu.beznea at microchip.com: keep only the sama7_dt]
Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/Makefile |  1 +
 arch/arm/mach-at91/sama7.c  | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)
 create mode 100644 arch/arm/mach-at91/sama7.c

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index f565490f1b70..522b680b6446 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_AT91RM9200)	+= at91rm9200.o
 obj-$(CONFIG_SOC_AT91SAM9)	+= at91sam9.o
 obj-$(CONFIG_SOC_SAM9X60)	+= sam9x60.o
 obj-$(CONFIG_SOC_SAMA5)		+= sama5.o
+obj-$(CONFIG_SOC_SAMA7)		+= sama7.o
 obj-$(CONFIG_SOC_SAMV7)		+= samv7.o
 
 # Power Management
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
new file mode 100644
index 000000000000..19d7bcbc97f1
--- /dev/null
+++ b/arch/arm/mach-at91/sama7.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Setup code for SAMA7
+ *
+ * Copyright (C) 2021 Microchip Technology, Inc. and its subsidiaries
+ *
+ */
+
+#include <linux/of.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+#include <asm/system_misc.h>
+
+#include "generic.h"
+
+static void __init sama7_dt_device_init(void)
+{
+	of_platform_default_populate(NULL, NULL, NULL);
+}
+
+static const char *const sama7_dt_board_compat[] __initconst = {
+	"microchip,sama7",
+	NULL
+};
+
+DT_MACHINE_START(sama7_dt, "Microchip SAMA7")
+	/* Maintainer: Microchip */
+	.init_machine	= sama7_dt_device_init,
+	.dt_compat	= sama7_dt_board_compat,
+MACHINE_END
+
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:09 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:09 +0300
Subject: [PATCH v3 23/24] ARM: at91: pm: add pm support for SAMA7G5
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-24-claudiu.beznea@microchip.com>

Add support for SAMA7G5 power management modes: standby, ulp0, ulp1, backup.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/generic.h |  2 ++
 arch/arm/mach-at91/pm.c      | 37 ++++++++++++++++++++++++++++++++++++
 arch/arm/mach-at91/sama7.c   |  1 +
 3 files changed, 40 insertions(+)

diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index 0a4cdcb4985b..0c3960a8b3eb 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -14,12 +14,14 @@ extern void __init at91sam9_pm_init(void);
 extern void __init sam9x60_pm_init(void);
 extern void __init sama5_pm_init(void);
 extern void __init sama5d2_pm_init(void);
+extern void __init sama7_pm_init(void);
 #else
 static inline void __init at91rm9200_pm_init(void) { }
 static inline void __init at91sam9_pm_init(void) { }
 static inline void __init sam9x60_pm_init(void) { }
 static inline void __init sama5_pm_init(void) { }
 static inline void __init sama5d2_pm_init(void) { }
+static inline void __init sama7_pm_init(void) { }
 #endif
 
 #endif /* _AT91_GENERIC_H */
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index f4e66a7c7d18..24d5fd06d487 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -152,6 +152,17 @@ static const struct of_device_id sam9x60_ws_ids[] = {
 	{ /* sentinel */ }
 };
 
+static const struct of_device_id sama7g5_ws_ids[] = {
+	{ .compatible = "atmel,at91sam9x5-rtc",		.data = &ws_info[1] },
+	{ .compatible = "microchip,sama7g5-ohci",	.data = &ws_info[2] },
+	{ .compatible = "usb-ohci",			.data = &ws_info[2] },
+	{ .compatible = "atmel,at91sam9g45-ehci",	.data = &ws_info[2] },
+	{ .compatible = "usb-ehci",			.data = &ws_info[2] },
+	{ .compatible = "microchip,sama7g5-sdhci",	.data = &ws_info[3] },
+	{ .compatible = "atmel,at91sam9260-rtt",	.data = &ws_info[4] },
+	{ /* sentinel */ }
+};
+
 static int at91_pm_config_ws(unsigned int pm_mode, bool set)
 {
 	const struct wakeup_source_info *wsi;
@@ -1103,6 +1114,32 @@ void __init sama5d2_pm_init(void)
 	soc_pm.config_pmc_ws = at91_sama5d2_config_pmc_ws;
 }
 
+void __init sama7_pm_init(void)
+{
+	static const int modes[] __initconst = {
+		AT91_PM_STANDBY, AT91_PM_ULP0, AT91_PM_ULP1, AT91_PM_BACKUP,
+	};
+	static const u32 iomaps[] __initconst = {
+		[AT91_PM_ULP0]		= AT91_PM_IOMAP(SFRBU),
+		[AT91_PM_ULP1]		= AT91_PM_IOMAP(SFRBU) |
+					  AT91_PM_IOMAP(SHDWC),
+		[AT91_PM_BACKUP]	= AT91_PM_IOMAP(SFRBU) |
+					  AT91_PM_IOMAP(SHDWC),
+	};
+
+	if (!IS_ENABLED(CONFIG_SOC_SAMA7))
+		return;
+
+	at91_pm_modes_validate(modes, ARRAY_SIZE(modes));
+
+	at91_dt_ramc(true);
+	at91_pm_modes_init(iomaps, ARRAY_SIZE(iomaps));
+	at91_pm_init(NULL);
+
+	soc_pm.ws_ids = sama7g5_ws_ids;
+	soc_pm.config_pmc_ws = at91_sam9x60_config_pmc_ws;
+}
+
 static int __init at91_pm_modes_select(char *str)
 {
 	char *s;
diff --git a/arch/arm/mach-at91/sama7.c b/arch/arm/mach-at91/sama7.c
index 19d7bcbc97f1..bd43733ede18 100644
--- a/arch/arm/mach-at91/sama7.c
+++ b/arch/arm/mach-at91/sama7.c
@@ -17,6 +17,7 @@
 static void __init sama7_dt_device_init(void)
 {
 	of_platform_default_populate(NULL, NULL, NULL);
+	sama7_pm_init();
 }
 
 static const char *const sama7_dt_board_compat[] __initconst = {
-- 
2.25.1



From claudiu.beznea at microchip.com  Thu Apr 15 11:50:10 2021
From: claudiu.beznea at microchip.com (Claudiu Beznea)
Date: Thu, 15 Apr 2021 13:50:10 +0300
Subject: [PATCH v3 24/24] ARM: at91: pm: add sama7g5 shdwc
In-Reply-To: <20210415105010.569620-1-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
Message-ID: <20210415105010.569620-25-claudiu.beznea@microchip.com>

Add SAMA7G5 SHDWC.

Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
---
 arch/arm/mach-at91/pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 24d5fd06d487..d6cfe7c4bb00 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -794,6 +794,7 @@ static int __init at91_pm_backup_init(void)
 static const struct of_device_id atmel_shdwc_ids[] = {
 	{ .compatible = "atmel,sama5d2-shdwc" },
 	{ .compatible = "microchip,sam9x60-shdwc" },
+	{ .compatible = "microchip,sama7g5-shdwc" },
 	{ /* sentinel. */ }
 };
 
-- 
2.25.1



From tzimmermann at suse.de  Thu Apr 15 12:00:38 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 13:00:38 +0200
Subject: [PATCH 2/4] drm/mxsfb: Don't select DRM_KMS_FB_HELPER
In-Reply-To: <20210415110040.23525-1-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
Message-ID: <20210415110040.23525-3-tzimmermann@suse.de>

Selecting DRM_FBDEV_EMULATION will include the correct secttings for
fbdev emulation. Drivers should not override this.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 0143d539f8f8..ee22cd25d3e3 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -10,7 +10,6 @@ config DRM_MXSFB
 	depends on COMMON_CLK
 	select DRM_MXS
 	select DRM_KMS_HELPER
-	select DRM_KMS_FB_HELPER
 	select DRM_KMS_CMA_HELPER
 	select DRM_PANEL
 	select DRM_PANEL_BRIDGE
-- 
2.31.1



From tzimmermann at suse.de  Thu Apr 15 12:00:37 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 13:00:37 +0200
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <20210415110040.23525-1-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
Message-ID: <20210415110040.23525-2-tzimmermann@suse.de>

Respect DRM's kconfig setting for fbdev console emulation. If enabled,
it will select all required config options. So remove them from vmwgfx's
Kconfig file.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
---
 drivers/gpu/drm/vmwgfx/Kconfig      |  7 +------
 drivers/gpu/drm/vmwgfx/Makefile     |  4 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
 3 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index 15acdf2a7c0f..b3a34196935b 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -2,12 +2,7 @@
 config DRM_VMWGFX
 	tristate "DRM driver for VMware Virtual GPU"
 	depends on DRM && PCI && X86 && MMU
-	select FB_DEFERRED_IO
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
 	select DRM_TTM
-	select FB
 	select MAPPING_DIRTY_HELPERS
 	# Only needed for the transitional use of drm_crtc_init - can be removed
 	# again once vmwgfx sets up the primary plane itself.
@@ -20,7 +15,7 @@ config DRM_VMWGFX
 	  The compiled module will be called "vmwgfx.ko".
 
 config DRM_VMWGFX_FBCON
-	depends on DRM_VMWGFX && FB
+	depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
 	bool "Enable framebuffer console under vmwgfx by default"
 	help
 	   Choose this option if you are shipping a new vmwgfx
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 8c02fa5852e7..9f5743013cbb 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
-	    vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
+	    vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
 	    vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
 	    vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
 	    vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
@@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
 	    vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
 	    ttm_object.o ttm_lock.o ttm_memory.o
 
+vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
 vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
+
 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 7e6518709e14..e7836da190c4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct vmw_private *dev_priv,
  * Kernel framebuffer - vmwgfx_fb.c
  */
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 int vmw_fb_init(struct vmw_private *vmw_priv);
 int vmw_fb_close(struct vmw_private *dev_priv);
 int vmw_fb_off(struct vmw_private *vmw_priv);
 int vmw_fb_on(struct vmw_private *vmw_priv);
+#else
+static inline int vmw_fb_init(struct vmw_private *vmw_priv)
+{
+	return 0;
+}
+static inline int vmw_fb_close(struct vmw_private *dev_priv)
+{
+	return 0;
+}
+static inline int vmw_fb_off(struct vmw_private *vmw_priv)
+{
+	return 0;
+}
+static inline int vmw_fb_on(struct vmw_private *vmw_priv)
+{
+	return 0;
+}
+#endif
 
 /**
  * Kernel modesetting - vmwgfx_kms.c
-- 
2.31.1



From tzimmermann at suse.de  Thu Apr 15 12:00:40 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 13:00:40 +0200
Subject: [PATCH 4/4] drm: Remove DRM_KMS_FB_HELPER Kconfig option
In-Reply-To: <20210415110040.23525-1-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
Message-ID: <20210415110040.23525-5-tzimmermann@suse.de>

It's only used by DRM_FBDEV_EMULATION, so inline it there.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
---
 drivers/gpu/drm/Kconfig | 28 +++++++++++-----------------
 1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c16bd1afd87..d3a9ca4b1cec 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -80,23 +80,6 @@ config DRM_KMS_HELPER
 	help
 	  CRTC helpers for KMS drivers.
 
-config DRM_KMS_FB_HELPER
-	bool
-	depends on DRM_KMS_HELPER
-	select FB
-	select FRAMEBUFFER_CONSOLE if !EXPERT
-	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
-	select FB_SYS_FOPS
-	select FB_SYS_FILLRECT
-	select FB_SYS_COPYAREA
-	select FB_SYS_IMAGEBLIT
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	select FB_DEFERRED_IO
-	help
-	  FBDEV helpers for KMS drivers.
-
 config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
         bool "Enable refcount backtrace history in the DP MST helpers"
 	depends on STACKTRACE_SUPPORT
@@ -117,6 +100,17 @@ config DRM_FBDEV_EMULATION
 	depends on DRM
 	select DRM_KMS_HELPER
 	select DRM_KMS_FB_HELPER
+	select FB
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	select FB_DEFERRED_IO
+	select FB_SYS_FOPS
+	select FB_SYS_FILLRECT
+	select FB_SYS_COPYAREA
+	select FB_SYS_IMAGEBLIT
+	select FRAMEBUFFER_CONSOLE if !EXPERT
+	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
 	default y
 	help
 	  Choose this option if you have a need for the legacy fbdev
-- 
2.31.1



From tzimmermann at suse.de  Thu Apr 15 12:00:36 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 13:00:36 +0200
Subject: [PATCH 0/4] drm: Fix config dependencies for fbdev emulation
Message-ID: <20210415110040.23525-1-tzimmermann@suse.de>

While working on the recent aperture helpers, I found it hard to
disable fbdev because drivers keep on selecting it automatically.

Cleanup the config dependencies. Fbdev support should be configured
by users. DRM drivers should check for DRM_FBDEV_EMULATION to enable
fbdev support.

Thomas Zimmermann (4):
  drm/vmwgfx: Make console emulation depend on DRM_FBDEV_EMULATION
  drm/mxsfb: Don't select DRM_KMS_FB_HELPER
  drm/zte: Don't select DRM_KMS_FB_HELPER
  drm: Remove DRM_KMS_FB_HELPER Kconfig option

 drivers/gpu/drm/Kconfig             | 28 +++++++++++-----------------
 drivers/gpu/drm/mxsfb/Kconfig       |  1 -
 drivers/gpu/drm/vmwgfx/Kconfig      |  7 +------
 drivers/gpu/drm/vmwgfx/Makefile     |  4 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
 drivers/gpu/drm/zte/Kconfig         |  1 -
 6 files changed, 34 insertions(+), 26 deletions(-)

--
2.31.1



From tzimmermann at suse.de  Thu Apr 15 12:00:39 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 13:00:39 +0200
Subject: [PATCH 3/4] drm/zte: Don't select DRM_KMS_FB_HELPER
In-Reply-To: <20210415110040.23525-1-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
Message-ID: <20210415110040.23525-4-tzimmermann@suse.de>

Selecting DRM_FBDEV_EMULATION will include the correct secttings for
fbdev emulation. Drivers should not override this.

Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
---
 drivers/gpu/drm/zte/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
index 90ebaedc11fd..aa8594190b50 100644
--- a/drivers/gpu/drm/zte/Kconfig
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -3,7 +3,6 @@ config DRM_ZTE
 	tristate "DRM Support for ZTE SoCs"
 	depends on DRM && ARCH_ZX
 	select DRM_KMS_CMA_HELPER
-	select DRM_KMS_FB_HELPER
 	select DRM_KMS_HELPER
 	select SND_SOC_HDMI_CODEC if SND_SOC
 	select VIDEOMODE_HELPERS
-- 
2.31.1



From adrian.hunter at intel.com  Thu Apr 15 12:06:58 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Thu, 15 Apr 2021 14:06:58 +0300
Subject: [PATCH v18 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>
References: <cover.1618426513.git.asutoshd@codeaurora.org>
 <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>
Message-ID: <47049515-be9d-23b0-6dbd-24b3b09fdb82@intel.com>

On 14/04/21 9:58 pm, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes.

Can you also explain the new driver for RPMB WLUN and UAC changes here?

And also mention that the driver will now always be runtime
resumed before system suspend.

> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

<SNIP>

> +static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
> +{
> +	struct device_link *link;
> +
> +	/*
> +	 * device wlun is the supplier & rest of the luns are consumers
> +	 * This ensures that device wlun suspends after all other luns.
> +	 */
> +	if (hba->sdev_ufs_device) {
> +		link = device_link_add(&sdev->sdev_gendev,
> +				       &hba->sdev_ufs_device->sdev_gendev,
> +				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);

"|" could be surrounded by spaces i.e.
				       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);

> +		if (!link) {
> +			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
> +				dev_name(&hba->sdev_ufs_device->sdev_gendev));
> +			return;
> +		}
> +		hba->luns_avail--;
> +		/* Ignore REPORT_LUN wlun probing */
> +		if (hba->luns_avail == 1) {
> +			ufshcd_rpm_put(hba);
> +			return;
> +		}
> +	} else {
> +		/* device wlun is probed */
> +		hba->luns_avail--;
> +	}
> +}

<SNIP>

> @@ -8916,42 +8906,214 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  	if (hba->ee_usr_mask)
>  		ufshcd_write_ee_control(hba);
>  
> -	hba->clk_gating.is_suspended = false;
> -
> -	if (ufshcd_is_clkscaling_supported(hba))
> -		ufshcd_clk_scaling_suspend(hba, false);
> -
> -	/* Enable Auto-Hibernate if configured */
> -	ufshcd_auto_hibern8_enable(hba);
> +	if (hba->clk_scaling.is_allowed)
> +		ufshcd_resume_clkscaling(hba);

We don't use clks, regulators, clk gating, clk scaling, but the
original code looks more correct because hba->clk_scaling.is_allowed
will have been set to false by ufshcd_clk_scaling_suspend(hba, true)
in __ufshcd_wl_suspend().

<SNIP>

> +#ifdef CONFIG_PM_SLEEP
> +static int ufshcd_wl_suspend(struct device *dev)
> +{
> +	struct scsi_device *sdev = to_scsi_device(dev);
> +	struct ufs_hba *hba;
> +	int ret;

For below:
	int ret = 0;

> +	ktime_t start = ktime_get();
> +
> +	hba = shost_priv(sdev->host);
> +	down(&hba->host_sem);

If we get here with dev runtime suspended, then skip
__ufshcd_wl_suspend() i.e.

	if (pm_runtime_suspended(dev))
		goto out;

> +	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
> +	if (ret) {
> +		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
> +		up(&hba->host_sem);
> +	} else {
> +		hba->is_sys_suspended = true;
> +	}

out:
	if (!ret)
		hba->is_sys_suspended = true;

> +
> +	trace_ufshcd_wl_suspend(dev_name(dev), ret,
> +		ktime_to_us(ktime_sub(ktime_get(), start)),
> +		hba->curr_dev_pwr_mode, hba->uic_link_state);
> +
> +	return ret;
> +}

<SNIP>


From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 15 12:13:10 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 15 Apr 2021 16:43:10 +0530
Subject: [PATCH v5 0/3] Add ZynqMP pinctrl driver
Message-ID: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Add support for Xilinx ZynqMP pinctrl driver and also update
the Xilinx firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and
allow configuring the pins as per the request.

changes in v5:
- Used generic property 'power-source' instead of driver specific for
configuring the IO voltages, updated the same in dt-binding.
- Added support to build driver as a module.
- Used error codes returned by the Xilinx firmware instead of shadowing the
error codes in the driver.
- Fixed comments from Andy related to spell checks, NULL checks, explicit
typecast, header inclusion ordering, removing kernel docs for the
obvious ones.

changes in v4:
- Added comment for ignoring the return value for GET_FUNCTION_NAME qid.
- Updated the zynqmp_pinctrl_get_function_name() API prototype to void as
it always returns zero.

changes in v3:
- Fixed binding doc comments from Rob.
- Used 'maxItems' for groups and pins properties.
- Updated commit subject and description to have present tense statements.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

Sai Krishna Potthuri (3):
  firmware: xilinx: Add pinctrl support
  dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver
  pinctrl: Add Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 +++++++
 drivers/firmware/xilinx/zynqmp.c              | 114 +++
 drivers/pinctrl/Kconfig                       |  14 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c              | 906 ++++++++++++++++++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 include/linux/firmware/xlnx-zynqmp.h          |  90 ++
 7 files changed, 1480 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 15 12:13:11 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 15 Apr 2021 16:43:11 +0530
Subject: [PATCH v5 1/3] firmware: xilinx: Add pinctrl support
In-Reply-To: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1618485193-5403-2-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
Acked-by: Michal Simek <michal.simek at xilinx.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 114 +++++++++++++++++++++++++++
 include/linux/firmware/xlnx-zynqmp.h |  90 +++++++++++++++++++++
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+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, pin, 0,
+				  0, 0, ret_payload);
+	*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
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+				   0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+				 u32 *value)
+{
+	u32 ret_payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	if (!value)
+		return -EINVAL;
+
+	ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+				  0, 0, ret_payload);
+	*value = ret_payload[1];
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+				 u32 value)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+				   param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *			       master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
 	PM_FPGA_LOAD,
 	PM_FPGA_GET_STATUS,
 	PM_GET_CHIPID = 24,
+	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,
 	PM_IOCTL = 34,
 	PM_QUERY_DATA,
 	PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
 	PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
 	PM_QID_CLOCK_GET_PARENTS,
 	PM_QID_CLOCK_GET_ATTRIBUTES,
+	PM_QID_PINCTRL_GET_NUM_PINS = 6,
+	PM_QID_PINCTRL_GET_NUM_FUNCTIONS = 7,
+	PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS = 8,
+	PM_QID_PINCTRL_GET_FUNCTION_NAME = 9,
+	PM_QID_PINCTRL_GET_FUNCTION_GROUPS = 10,
+	PM_QID_PINCTRL_GET_PIN_GROUPS = 11,
 	PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
 	PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
@@ -288,6 +300,44 @@ enum dll_reset_type {
 	PM_DLL_RESET_PULSE,
 };
 
+enum pm_pinctrl_config_param {
+	PM_PINCTRL_CONFIG_SLEW_RATE = 0,
+	PM_PINCTRL_CONFIG_BIAS_STATUS = 1,
+	PM_PINCTRL_CONFIG_PULL_CTRL = 2,
+	PM_PINCTRL_CONFIG_SCHMITT_CMOS = 3,
+	PM_PINCTRL_CONFIG_DRIVE_STRENGTH = 4,
+	PM_PINCTRL_CONFIG_VOLTAGE_STATUS = 5,
+	PM_PINCTRL_CONFIG_TRI_STATE = 6,
+	PM_PINCTRL_CONFIG_MAX = 7,
+};
+
+enum pm_pinctrl_slew_rate {
+	PM_PINCTRL_SLEW_RATE_FAST = 0,
+	PM_PINCTRL_SLEW_RATE_SLOW = 1,
+};
+
+enum pm_pinctrl_bias_status {
+	PM_PINCTRL_BIAS_DISABLE = 0,
+	PM_PINCTRL_BIAS_ENABLE = 1,
+};
+
+enum pm_pinctrl_pull_ctrl {
+	PM_PINCTRL_BIAS_PULL_DOWN = 0,
+	PM_PINCTRL_BIAS_PULL_UP = 1,
+};
+
+enum pm_pinctrl_schmitt_cmos {
+	PM_PINCTRL_INPUT_TYPE_CMOS = 0,
+	PM_PINCTRL_INPUT_TYPE_SCHMITT = 1,
+};
+
+enum pm_pinctrl_drive_strength {
+	PM_PINCTRL_DRIVE_STRENGTH_2MA = 0,
+	PM_PINCTRL_DRIVE_STRENGTH_4MA = 1,
+	PM_PINCTRL_DRIVE_STRENGTH_8MA = 2,
+	PM_PINCTRL_DRIVE_STRENGTH_12MA = 3,
+};
+
 enum zynqmp_pm_shutdown_type {
 	ZYNQMP_PM_SHUTDOWN_TYPE_SHUTDOWN,
 	ZYNQMP_PM_SHUTDOWN_TYPE_RESET,
@@ -357,6 +407,14 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 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);
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+				 u32 value);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -507,6 +565,38 @@ static inline int zynqmp_pm_set_boot_health_status(u32 value)
 {
 	return -ENODEV;
 }
+
+static inline int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+	return -ENODEV;
+}
+
+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_pinctrl_set_function(const u32 pin, const u32 id)
+{
+	return -ENODEV;
+}
+
+static inline int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+					       u32 *value)
+{
+	return -ENODEV;
+}
+
+static inline int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+					       u32 value)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 15 12:13:12 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 15 Apr 2021 16:43:12 +0530
Subject: [PATCH v5 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl
 driver
In-Reply-To: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1618485193-5403-3-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 ++++++++++++++++++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 2 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index 000000000000..8ef0d07d35fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,336 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
+  - Rajan Vaja <rajan.vaja at xilinx.com>
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+    const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+    type: object
+    patternProperties:
+      '^mux':
+        type: object
+        description:
+          Pinctrl node's client devices use subnodes for pin muxes,
+          which in turn use below standard properties.
+        $ref: pinmux-node.yaml#
+
+        properties:
+          groups:
+            description:
+              List of groups to select (either this or "pins" must be
+              specified), available groups for this subnode.
+            items:
+              enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+                     ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+                     gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+                     mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+                     qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+                     spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+                     spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+                     spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+                     spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+                     spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+                     spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+                     spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+                     spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+                     spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+                     spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+                     spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+                     spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+                     spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+                     spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+                     spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+                     spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+                     sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+                     sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+                     sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+                     sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+                     sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+                     sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+                     sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+                     sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+                     sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+                     sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+                     sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+                     sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+                     sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+                     sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+                     sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+                     sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+                     sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
+                     sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
+                     sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+                     sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+                     sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+                     sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+                     nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+                     nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+                     can0_1_grp, can0_2_grp, can0_3_grp,
+                     can0_4_grp, can0_5_grp, can0_6_grp,
+                     can0_7_grp, can0_8_grp, can0_9_grp,
+                     can0_10_grp, can0_11_grp, can0_12_grp,
+                     can0_13_grp, can0_14_grp, can0_15_grp,
+                     can0_16_grp, can0_17_grp, can0_18_grp,
+                     can1_0_grp, can1_1_grp, can1_2_grp,
+                     can1_3_grp, can1_4_grp, can1_5_grp,
+                     can1_6_grp, can1_7_grp, can1_8_grp,
+                     can1_9_grp, can1_10_grp, can1_11_grp,
+                     can1_12_grp, can1_13_grp, can1_14_grp,
+                     can1_15_grp, can1_16_grp, can1_17_grp,
+                     can1_18_grp, can1_19_grp, uart0_0_grp,
+                     uart0_1_grp, uart0_2_grp, uart0_3_grp,
+                     uart0_4_grp, uart0_5_grp, uart0_6_grp,
+                     uart0_7_grp, uart0_8_grp, uart0_9_grp,
+                     uart0_10_grp, uart0_11_grp, uart0_12_grp,
+                     uart0_13_grp, uart0_14_grp, uart0_15_grp,
+                     uart0_16_grp, uart0_17_grp, uart0_18_grp,
+                     uart1_0_grp, uart1_1_grp, uart1_2_grp,
+                     uart1_3_grp, uart1_4_grp, uart1_5_grp,
+                     uart1_6_grp, uart1_7_grp, uart1_8_grp,
+                     uart1_9_grp, uart1_10_grp, uart1_11_grp,
+                     uart1_12_grp, uart1_13_grp, uart1_14_grp,
+                     uart1_15_grp, uart1_16_grp, uart1_17_grp,
+                     uart1_18_grp, i2c0_0_grp, i2c0_1_grp,
+                     i2c0_2_grp, i2c0_3_grp, i2c0_4_grp,
+                     i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
+                     i2c0_8_grp, i2c0_9_grp, i2c0_10_grp,
+                     i2c0_11_grp, i2c0_12_grp, i2c0_13_grp,
+                     i2c0_14_grp, i2c0_15_grp, i2c0_16_grp,
+                     i2c0_17_grp, i2c0_18_grp, i2c1_0_grp,
+                     i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
+                     i2c1_4_grp, i2c1_5_grp, i2c1_6_grp,
+                     i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
+                     i2c1_10_grp, i2c1_11_grp, i2c1_12_grp,
+                     i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
+                     i2c1_16_grp, i2c1_17_grp, i2c1_18_grp,
+                     i2c1_19_grp, ttc0_clk_0_grp, ttc0_wav_0_grp,
+                     ttc0_clk_1_grp, ttc0_wav_1_grp, ttc0_clk_2_grp,
+                     ttc0_wav_2_grp, ttc0_clk_3_grp, ttc0_wav_3_grp,
+                     ttc0_clk_4_grp, ttc0_wav_4_grp, ttc0_clk_5_grp,
+                     ttc0_wav_5_grp, ttc0_clk_6_grp, ttc0_wav_6_grp,
+                     ttc0_clk_7_grp, ttc0_wav_7_grp, ttc0_clk_8_grp,
+                     ttc0_wav_8_grp, ttc1_clk_0_grp, ttc1_wav_0_grp,
+                     ttc1_clk_1_grp, ttc1_wav_1_grp, ttc1_clk_2_grp,
+                     ttc1_wav_2_grp, ttc1_clk_3_grp, ttc1_wav_3_grp,
+                     ttc1_clk_4_grp, ttc1_wav_4_grp, ttc1_clk_5_grp,
+                     ttc1_wav_5_grp, ttc1_clk_6_grp, ttc1_wav_6_grp,
+                     ttc1_clk_7_grp, ttc1_wav_7_grp, ttc1_clk_8_grp,
+                     ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_wav_0_grp,
+                     ttc2_clk_1_grp, ttc2_wav_1_grp, ttc2_clk_2_grp,
+                     ttc2_wav_2_grp, ttc2_clk_3_grp, ttc2_wav_3_grp,
+                     ttc2_clk_4_grp, ttc2_wav_4_grp, ttc2_clk_5_grp,
+                     ttc2_wav_5_grp, ttc2_clk_6_grp, ttc2_wav_6_grp,
+                     ttc2_clk_7_grp, ttc2_wav_7_grp, ttc2_clk_8_grp,
+                     ttc2_wav_8_grp, ttc3_clk_0_grp, ttc3_wav_0_grp,
+                     ttc3_clk_1_grp, ttc3_wav_1_grp, ttc3_clk_2_grp,
+                     ttc3_wav_2_grp, ttc3_clk_3_grp, ttc3_wav_3_grp,
+                     ttc3_clk_4_grp, ttc3_wav_4_grp, ttc3_clk_5_grp,
+                     ttc3_wav_5_grp, ttc3_clk_6_grp, ttc3_wav_6_grp,
+                     ttc3_clk_7_grp, ttc3_wav_7_grp, ttc3_clk_8_grp,
+                     ttc3_wav_8_grp, swdt0_clk_0_grp, swdt0_rst_0_grp,
+                     swdt0_clk_1_grp, swdt0_rst_1_grp, swdt0_clk_2_grp,
+                     swdt0_rst_2_grp, swdt0_clk_3_grp, swdt0_rst_3_grp,
+                     swdt0_clk_4_grp, swdt0_rst_4_grp, swdt0_clk_5_grp,
+                     swdt0_rst_5_grp, swdt0_clk_6_grp, swdt0_rst_6_grp,
+                     swdt0_clk_7_grp, swdt0_rst_7_grp, swdt0_clk_8_grp,
+                     swdt0_rst_8_grp, swdt0_clk_9_grp, swdt0_rst_9_grp,
+                     swdt0_clk_10_grp, swdt0_rst_10_grp, swdt0_clk_11_grp,
+                     swdt0_rst_11_grp, swdt0_clk_12_grp, swdt0_rst_12_grp,
+                     swdt1_clk_0_grp, swdt1_rst_0_grp, swdt1_clk_1_grp,
+                     swdt1_rst_1_grp, swdt1_clk_2_grp, swdt1_rst_2_grp,
+                     swdt1_clk_3_grp, swdt1_rst_3_grp, swdt1_clk_4_grp,
+                     swdt1_rst_4_grp, swdt1_clk_5_grp, swdt1_rst_5_grp,
+                     swdt1_clk_6_grp, swdt1_rst_6_grp, swdt1_clk_7_grp,
+                     swdt1_rst_7_grp, swdt1_clk_8_grp, swdt1_rst_8_grp,
+                     swdt1_clk_9_grp, swdt1_rst_9_grp, swdt1_clk_10_grp,
+                     swdt1_rst_10_grp, swdt1_clk_11_grp, swdt1_rst_11_grp,
+                     swdt1_clk_12_grp, swdt1_rst_12_grp, gpio0_0_grp,
+                     gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
+                     gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
+                     gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
+                     gpio0_10_grp, gpio0_11_grp, gpio0_12_grp,
+                     gpio0_13_grp, gpio0_14_grp, gpio0_15_grp,
+                     gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
+                     gpio0_19_grp, gpio0_20_grp, gpio0_21_grp,
+                     gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
+                     gpio0_25_grp, gpio0_26_grp, gpio0_27_grp,
+                     gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
+                     gpio0_31_grp, gpio0_32_grp, gpio0_33_grp,
+                     gpio0_34_grp, gpio0_35_grp, gpio0_36_grp,
+                     gpio0_37_grp, gpio0_38_grp, gpio0_39_grp,
+                     gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
+                     gpio0_43_grp, gpio0_44_grp, gpio0_45_grp,
+                     gpio0_46_grp, gpio0_47_grp, gpio0_48_grp,
+                     gpio0_49_grp, gpio0_50_grp, gpio0_51_grp,
+                     gpio0_52_grp, gpio0_53_grp, gpio0_54_grp,
+                     gpio0_55_grp, gpio0_56_grp, gpio0_57_grp,
+                     gpio0_58_grp, gpio0_59_grp, gpio0_60_grp,
+                     gpio0_61_grp, gpio0_62_grp, gpio0_63_grp,
+                     gpio0_64_grp, gpio0_65_grp, gpio0_66_grp,
+                     gpio0_67_grp, gpio0_68_grp, gpio0_69_grp,
+                     gpio0_70_grp, gpio0_71_grp, gpio0_72_grp,
+                     gpio0_73_grp, gpio0_74_grp, gpio0_75_grp,
+                     gpio0_76_grp, gpio0_77_grp, usb0_0_grp,
+                     usb1_0_grp, pmu0_0_grp, pmu0_1_grp,
+                     pmu0_2_grp, pmu0_3_grp, pmu0_4_grp,
+                     pmu0_5_grp, pmu0_6_grp, pmu0_7_grp,
+                     pmu0_8_grp, pmu0_9_grp, pmu0_10_grp,
+                     pmu0_11_grp, pcie0_0_grp, pcie0_1_grp,
+                     pcie0_2_grp, pcie0_3_grp, pcie0_4_grp,
+                     pcie0_5_grp, pcie0_6_grp, pcie0_7_grp,
+                     csu0_0_grp, csu0_1_grp, csu0_2_grp,
+                     csu0_3_grp, csu0_4_grp, csu0_5_grp,
+                     csu0_6_grp, csu0_7_grp, csu0_8_grp,
+                     csu0_9_grp, csu0_10_grp, csu0_11_grp,
+                     dpaux0_0_grp, dpaux0_1_grp, dpaux0_2_grp,
+                     dpaux0_3_grp, pjtag0_0_grp, pjtag0_1_grp,
+                     pjtag0_2_grp, pjtag0_3_grp, pjtag0_4_grp,
+                     pjtag0_5_grp, trace0_0_grp, trace0_clk_0_grp,
+                     trace0_1_grp, trace0_clk_1_grp, trace0_2_grp,
+                     trace0_clk_2_grp, testscan0_0_grp]
+            maxItems: 78
+
+          function:
+            description:
+              Specify the alternative function to be configured for the
+              given pin groups.
+            enum: [ethernet0, ethernet1, ethernet2, ethernet3, gemtsu0, usb0, usb1, mdio0,
+                   mdio1, mdio2, mdio3, qspi0, qspi_fbclk, qspi_ss, spi0, spi1, spi0_ss,
+                   spi1_ss, sdio0, sdio0_pc, sdio0_wp, sdio0_cd, sdio1, sdio1_pc, sdio1_wp,
+                   sdio1_cd, nand0, nand0_ce, nand0_rb, nand0_dqs, can0, can1, uart0, uart1,
+                   i2c0, i2c1, ttc0_clk, ttc0_wav, ttc1_clk, ttc1_wav, ttc2_clk, ttc2_wav,
+                   ttc3_clk, ttc3_wav, swdt0_clk, swdt0_rst, swdt1_clk, swdt1_rst, gpio0, pmu0,
+                   pcie0, csu0, dpaux0, pjtag0, trace0, trace0_clk, testscan0]
+
+        required:
+          - groups
+          - function
+
+        additionalProperties: false
+
+      '^conf':
+        type: object
+        description:
+          Pinctrl node's client devices use subnodes for pin configurations,
+          which in turn use the standard properties below.
+        $ref: pincfg-node.yaml#
+
+        properties:
+          groups:
+            description:
+              List of pin groups as mentioned above.
+
+          pins:
+            description:
+              List of pin names to select in this subnode.
+            items:
+              pattern: '^MIO([0-9]|[1-6][0-9]|7[0-7])$'
+            maxItems: 78
+
+          bias-pull-up: true
+
+          bias-pull-down: true
+
+          bias-disable: true
+
+          input-schmitt-enable: true
+
+          input-schmitt-disable: true
+
+          bias-high-impedance: true
+
+          low-power-enable: true
+
+          low-power-disable: true
+
+          slew-rate:
+            enum: [0, 1]
+
+          drive-strength:
+            description:
+              Selects the drive strength for MIO pins, in mA.
+            enum: [2, 4, 8, 12]
+
+          power-source:
+            enum: [0, 1]
+
+        oneOf:
+          - required: [ groups ]
+          - required: [ pins ]
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+    zynqmp_firmware: zynqmp-firmware {
+        pinctrl0: pinctrl {
+          compatible = "xlnx,zynqmp-pinctrl";
+
+          pinctrl_uart1_default: uart1-default {
+             mux {
+                 groups = "uart0_4_grp", "uart0_5_grp";
+                 function = "uart0";
+             };
+
+             conf {
+                groups = "uart0_4_grp";
+                slew-rate = <SLEW_RATE_SLOW>;
+                power-source = <IO_STANDARD_LVCMOS18>;
+             };
+
+             conf-rx {
+                pins = "MIO18";
+                bias-pull-up;
+             };
+
+             conf-tx {
+                pins = "MIO19";
+                bias-disable;
+                input-schmitt-disable;
+             };
+          };
+        };
+    };
+
+    uart1 {
+         pinctrl-names = "default";
+         pinctrl-0 = <&pinctrl_uart1_default>;
+    };
+
+...
diff --git a/include/dt-bindings/pinctrl/pinctrl-zynqmp.h b/include/dt-bindings/pinctrl/pinctrl-zynqmp.h
new file mode 100644
index 000000000000..cdb215734bdf
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pinctrl-zynqmp.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * MIO pin configuration defines for Xilinx ZynqMP
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_ZYNQMP_H
+#define _DT_BINDINGS_PINCTRL_ZYNQMP_H
+
+/* Bit value for different voltage levels */
+#define IO_STANDARD_LVCMOS33	0
+#define IO_STANDARD_LVCMOS18	1
+
+/* Bit values for Slew Rates */
+#define SLEW_RATE_FAST		0
+#define SLEW_RATE_SLOW		1
+
+#endif /* _DT_BINDINGS_PINCTRL_ZYNQMP_H */
-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 15 12:13:13 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 15 Apr 2021 16:43:13 +0530
Subject: [PATCH v5 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1618485193-5403-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
---
 drivers/pinctrl/Kconfig          |  14 +
 drivers/pinctrl/Makefile         |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 906 +++++++++++++++++++++++++++++++
 3 files changed, 921 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..736f5230590b 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,20 @@ config PINCTRL_ZYNQ
 	help
 	  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+	tristate "Pinctrl driver for Xilinx ZynqMP"
+	depends on ZYNQMP_FIRMWARE
+	select PINMUX
+	select GENERIC_PINCONF
+	default ZYNQMP_FIRMWARE
+	help
+	  This selects the pinctrl driver for Xilinx ZynqMP platform.
+	  This driver will query the pin information from the firmware
+	  and allow configuring the pins.
+	  Configuration can include the mux function to select on those
+	  pin(s)/group(s), and various pin configuration parameters
+	  such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
 	bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
 	default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..cd28423fd8d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X)	+= pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX) 	+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ)	+= pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)	+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)	+= pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)	+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)	+= pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index 000000000000..e5f3f5794c66
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,906 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
+ * Rajan Vaja <rajan.vaja at xilinx.com>
+ */
+
+#include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+
+#include <linux/pinctrl/pinmux.h>
+#include <linux/pinctrl/pinconf-generic.h>
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX			"MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN		16
+#define MAX_FUNC_NAME_LEN			16
+#define MAX_GROUP_PIN				50
+#define MAX_PIN_GROUPS				50
+#define END_OF_FUNCTIONS			"END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP			6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN	12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN		12
+#define NA_GROUP				0xFFFF
+#define RESERVED_GROUP				0xFFFE
+
+#define DRIVE_STRENGTH_2MA	2
+#define DRIVE_STRENGTH_4MA	4
+#define DRIVE_STRENGTH_8MA	8
+#define DRIVE_STRENGTH_12MA	12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:	Name of the pin mux function
+ * @groups:	List of pin groups for this function
+ * @ngroups:	Number of entries in @groups
+ * @node:	Firmware node matching with the function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+	char name[MAX_FUNC_NAME_LEN];
+	const char * const *groups;
+	unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl:	Pin control device
+ * @groups:	Pin groups
+ * @ngroups:	Number of @groups
+ * @funcs:	Pin mux functions
+ * @nfuncs:	Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+	struct pinctrl_dev *pctrl;
+	const struct zynqmp_pctrl_group *groups;
+	unsigned int ngroups;
+	const struct zynqmp_pmux_function *funcs;
+	unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:	Group name
+ * @pins:	Group pin numbers
+ * @npins:	Number of pins in the group
+ */
+struct zynqmp_pctrl_group {
+	const char *name;
+	unsigned int pins[MAX_GROUP_PIN];
+	unsigned int npins;
+};
+
+static struct pinctrl_desc zynqmp_desc;
+
+static int zynqmp_pctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->ngroups;
+}
+
+static const char *zynqmp_pctrl_get_group_name(struct pinctrl_dev *pctldev,
+					       unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->groups[selector].name;
+}
+
+static int zynqmp_pctrl_get_group_pins(struct pinctrl_dev *pctldev,
+				       unsigned int selector,
+				       const unsigned int **pins,
+				       unsigned int *npins)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = pctrl->groups[selector].pins;
+	*npins = pctrl->groups[selector].npins;
+
+	return 0;
+}
+
+static const struct pinctrl_ops zynqmp_pctrl_ops = {
+	.get_groups_count = zynqmp_pctrl_get_groups_count,
+	.get_group_name = zynqmp_pctrl_get_group_name,
+	.get_group_pins = zynqmp_pctrl_get_group_pins,
+	.dt_node_to_map = pinconf_generic_dt_node_to_map_all,
+	.dt_free_map = pinctrl_utils_free_map,
+};
+
+static int zynqmp_pinmux_request_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_request(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "request failed for pin %u\n", pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int zynqmp_pmux_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->nfuncs;
+}
+
+static const char *zynqmp_pmux_get_function_name(struct pinctrl_dev *pctldev,
+						 unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->funcs[selector].name;
+}
+
+/**
+ * zynqmp_pmux_get_function_groups() - Get groups for the function
+ * @pctldev:	Pincontrol device pointer.
+ * @selector:	Function ID
+ * @groups:	Group names.
+ * @num_groups:	Number of function groups.
+ *
+ * Get function's group count and group names.
+ */
+static int zynqmp_pmux_get_function_groups(struct pinctrl_dev *pctldev,
+					   unsigned int selector,
+					   const char * const **groups,
+					   unsigned * const num_groups)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*groups = pctrl->funcs[selector].groups;
+	*num_groups = pctrl->funcs[selector].ngroups;
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinmux_set_mux() - Set requested function for the group
+ * @pctldev:	Pincontrol device pointer.
+ * @function:	Function ID.
+ * @group:	Group ID.
+ *
+ * Loop through all pins of the group and call firmware API
+ * to set requested function for all pins in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinmux_set_mux(struct pinctrl_dev *pctldev,
+				 unsigned int function,
+				 unsigned int group)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[group];
+	int ret, i;
+
+	for (i = 0; i < pgrp->npins; i++) {
+		unsigned int pin = pgrp->pins[i];
+
+		ret = zynqmp_pm_pinctrl_set_function(pin, function);
+		if (ret) {
+			dev_err(pctldev->dev, "set mux failed for pin %u\n",
+				pin);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int zynqmp_pinmux_release_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_release(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "free pin failed for pin %u\n",
+			pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinmux_ops zynqmp_pinmux_ops = {
+	.request = zynqmp_pinmux_request_pin,
+	.get_functions_count = zynqmp_pmux_get_functions_count,
+	.get_function_name = zynqmp_pmux_get_function_name,
+	.get_function_groups = zynqmp_pmux_get_function_groups,
+	.set_mux = zynqmp_pinmux_set_mux,
+	.free = zynqmp_pinmux_release_pin,
+};
+
+/**
+ * zynqmp_pinconf_cfg_get() - get config value for the pin
+ * @pctldev:	Pin control device pointer.
+ * @pin:	Pin number.
+ * @config:	Value of config param.
+ *
+ * Get value of the requested configuration parameter for the
+ * given pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
+				  unsigned int pin,
+				  unsigned long *config)
+{
+	unsigned int arg, param = pinconf_to_config_param(*config);
+	int ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	switch (param) {
+	case PIN_CONFIG_SLEW_RATE:
+		param = PM_PINCTRL_CONFIG_SLEW_RATE;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_UP)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_DISABLE:
+		param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_DISABLE)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_POWER_SOURCE:
+		param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+		param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_DRIVE_STRENGTH:
+		param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		switch (arg) {
+		case PM_PINCTRL_DRIVE_STRENGTH_2MA:
+			arg = DRIVE_STRENGTH_2MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_4MA:
+			arg = DRIVE_STRENGTH_4MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_8MA:
+			arg = DRIVE_STRENGTH_8MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_12MA:
+			arg = DRIVE_STRENGTH_12MA;
+			break;
+		default:
+			/* Invalid drive strength */
+			dev_warn(pctldev->dev,
+				 "Invalid drive strength for pin %d\n",
+				 pin);
+			return -EINVAL;
+		}
+		break;
+	default:
+		ret = -EOPNOTSUPP;
+		break;
+	}
+
+	if (ret)
+		return ret;
+
+	param = pinconf_to_config_param(*config);
+	*config = pinconf_to_config_packed(param, arg);
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_cfg_set() - Set requested config for the pin
+ * @pctldev:		Pincontrol device pointer.
+ * @pin:		Pin number.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Loop through all configurations and call firmware API
+ * to set requested configurations for the pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_set(struct pinctrl_dev *pctldev,
+				  unsigned int pin, unsigned long *configs,
+				  unsigned int num_configs)
+{
+	int i, ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < num_configs; i++) {
+		unsigned int param = pinconf_to_config_param(configs[i]);
+		unsigned int arg = pinconf_to_config_argument(configs[i]);
+		unsigned int value;
+
+		switch (param) {
+		case PIN_CONFIG_SLEW_RATE:
+			param = PM_PINCTRL_CONFIG_SLEW_RATE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_UP:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_UP;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_DOWN:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_DOWN;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_DISABLE:
+			param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+			arg = PM_PINCTRL_BIAS_DISABLE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+			param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_DRIVE_STRENGTH:
+			switch (arg) {
+			case DRIVE_STRENGTH_2MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_2MA;
+				break;
+			case DRIVE_STRENGTH_4MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_4MA;
+				break;
+			case DRIVE_STRENGTH_8MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_8MA;
+				break;
+			case DRIVE_STRENGTH_12MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_12MA;
+				break;
+			default:
+				/* Invalid drive strength */
+				dev_warn(pctldev->dev,
+					 "Invalid drive strength for pin %d\n",
+					 pin);
+				return -EINVAL;
+			}
+
+			param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, value);
+			break;
+		case PIN_CONFIG_POWER_SOURCE:
+			param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+			ret = zynqmp_pm_pinctrl_get_config(pin, param, &value);
+
+			if (arg != value)
+				dev_warn(pctldev->dev,
+					 "Invalid IO Standard requested for pin %d\n",
+					 pin);
+
+			break;
+		case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
+		case PIN_CONFIG_LOW_POWER_MODE:
+			/*
+			 * These cases are mentioned in dts but configurable
+			 * registers are unknown. So falling through to ignore
+			 * boot time warnings as of now.
+			 */
+			ret = 0;
+			break;
+		default:
+			dev_warn(pctldev->dev,
+				 "unsupported configuration parameter '%u'\n",
+				 param);
+			ret = -EOPNOTSUPP;
+			break;
+		}
+
+		param = pinconf_to_config_param(configs[i]);
+		arg = pinconf_to_config_argument(configs[i]);
+		if (ret)
+			dev_warn(pctldev->dev,
+				 "failed to set: pin %u param %u value %u\n",
+				 pin, param, arg);
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_group_set() - Set requested config for the group
+ * @pctldev:		Pincontrol device pointer.
+ * @selector:		Group ID.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Call function to set configs for each pin in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_group_set(struct pinctrl_dev *pctldev,
+				    unsigned int selector,
+				    unsigned long *configs,
+				    unsigned int num_configs)
+{
+	int i, ret;
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[selector];
+
+	for (i = 0; i < pgrp->npins; i++) {
+		ret = zynqmp_pinconf_cfg_set(pctldev, pgrp->pins[i], configs,
+					     num_configs);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinconf_ops zynqmp_pinconf_ops = {
+	.is_generic = true,
+	.pin_config_get = zynqmp_pinconf_cfg_get,
+	.pin_config_set = zynqmp_pinconf_cfg_set,
+	.pin_config_group_set = zynqmp_pinconf_group_set,
+};
+
+static struct pinctrl_desc zynqmp_desc = {
+	.name = "zynqmp_pinctrl",
+	.owner = THIS_MODULE,
+	.pctlops = &zynqmp_pctrl_ops,
+	.pmxops = &zynqmp_pinmux_ops,
+	.confops = &zynqmp_pinconf_ops,
+};
+
+static int zynqmp_pinctrl_get_function_groups(u32 fid, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_FUNC_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_func_num_groups(u32 fid, unsigned int *ngroups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*ngroups = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_func_groups() - prepare function and groups data
+ * @dev:	Device pointer.
+ * @fid:	Function ID.
+ * @func:	Function data.
+ * @groups:	Groups data.
+ *
+ * Query firmware to get group IDs for each function. Firmware returns
+ * group IDs. Based on group index for the function, group names in
+ * the function are stored. For example, the first group in "eth0" function
+ * is named as "eth0_0" and second group as "eth0_1" and so on.
+ *
+ * Based on the group ID received from the firmware, function stores name of
+ * the group for that group ID. For example, if "eth0" first group ID
+ * is x, groups[x] name will be stored as "eth0_0".
+ *
+ * Once done for each function, each function would have its group names
+ * and each groups would also have their names.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_func_groups(struct device *dev, u32 fid,
+					      struct zynqmp_pmux_function *func,
+					      struct zynqmp_pctrl_group *groups)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	const char **fgroups;
+	int ret = 0, index, i;
+
+	fgroups = devm_kzalloc(dev, sizeof(*fgroups) * func->ngroups, GFP_KERNEL);
+	if (!fgroups)
+		return -ENOMEM;
+
+	for (index = 0; index < func->ngroups; index += NUM_GROUPS_PER_RESP) {
+		ret = zynqmp_pinctrl_get_function_groups(fid, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				goto done;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			fgroups[index + i] = devm_kasprintf(dev, GFP_KERNEL,
+							    "%s_%d_grp",
+							    func->name,
+							    index + i);
+			if (!fgroups[index + i])
+				return -ENOMEM;
+
+			groups[resp[i]].name = devm_kasprintf(dev, GFP_KERNEL,
+							      "%s_%d_grp",
+							      func->name,
+							      index + i);
+			if (!groups[resp[i]].name)
+				return -ENOMEM;
+		}
+	}
+done:
+	func->groups = fgroups;
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_get_function_name(u32 fid, char *name)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_NAME;
+	qdata.arg1 = fid;
+
+	/*
+	 * Name of the function is maximum 16 bytes and cannot
+	 * accommodate the return value in SMC buffers, hence ignoring
+	 * the return value for this specific qid.
+	 */
+	zynqmp_pm_query_data(qdata, payload);
+	memcpy(name, payload, PINCTRL_GET_FUNC_NAME_RESP_LEN);
+}
+
+static int zynqmp_pinctrl_get_num_functions(unsigned int *nfuncs)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTIONS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*nfuncs = payload[1];
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_pin_groups(u32 pin, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_PIN_GROUPS;
+	qdata.arg1 = pin;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_PIN_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_group_add_pin(struct zynqmp_pctrl_group *group,
+					 unsigned int pin)
+{
+	group->pins[group->npins++] = pin;
+}
+
+/**
+ * zynqmp_pinctrl_create_pin_groups() - assign pins to respective groups
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @pin:	Pin number.
+ *
+ * Query firmware to get groups available for the given pin.
+ * Based on the firmware response(group IDs for the pin), add
+ * pin number to the respective group's pin array.
+ *
+ * Once all pins are queries, each groups would have its number
+ * of pins and pin numbers data.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_create_pin_groups(struct device *dev,
+					    struct zynqmp_pctrl_group *groups,
+					    unsigned int pin)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	int ret, i, index = 0;
+
+	do {
+		ret = zynqmp_pinctrl_get_pin_groups(pin, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				return ret;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			zynqmp_pinctrl_group_add_pin(&groups[resp[i]], pin);
+		}
+		index += NUM_GROUPS_PER_RESP;
+	} while (index <= MAX_PIN_GROUPS);
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_group_pins() - prepare each group's pin data
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @ngroups:	Number of groups.
+ *
+ * Prepare pin number and number of pins data for each pins.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_group_pins(struct device *dev,
+					     struct zynqmp_pctrl_group *groups,
+					     unsigned int ngroups)
+{
+	unsigned int pin;
+	int ret;
+
+	for (pin = 0; pin < zynqmp_desc.npins; pin++) {
+		ret = zynqmp_pinctrl_create_pin_groups(dev, groups, pin);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_function_info() - prepare function info
+ * @dev:	Device pointer.
+ * @pctrl:	Pin control driver data.
+ *
+ * Query firmware for functions, groups and pin information and
+ * prepare pin control driver data.
+ *
+ * Query number of functions and number of function groups (number
+ * of groups in given function) to allocate required memory buffers
+ * for functions and groups. Once buffers are allocated to store
+ * functions and groups data, query and store required information
+ * (number of groups and group names for each function, number of
+ * pins and pin numbers for each group).
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_function_info(struct device *dev,
+						struct zynqmp_pinctrl *pctrl)
+{
+	struct zynqmp_pmux_function *funcs;
+	struct zynqmp_pctrl_group *groups;
+	int ret, i;
+
+	ret = zynqmp_pinctrl_get_num_functions(&pctrl->nfuncs);
+	if (ret)
+		return ret;
+
+	funcs = devm_kzalloc(dev, sizeof(*funcs) * pctrl->nfuncs, GFP_KERNEL);
+	if (!funcs)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		zynqmp_pinctrl_get_function_name(i, funcs[i].name);
+
+		ret = zynqmp_pinctrl_get_func_num_groups(i, &funcs[i].ngroups);
+		if (ret)
+			return ret;
+
+		pctrl->ngroups += funcs[i].ngroups;
+	}
+
+	groups = devm_kzalloc(dev, sizeof(*groups) * pctrl->ngroups, GFP_KERNEL);
+	if (!groups)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		ret = zynqmp_pinctrl_prepare_func_groups(dev, i, &funcs[i],
+							 groups);
+		if (ret)
+			return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_group_pins(dev, groups, pctrl->ngroups);
+	if (ret)
+		return ret;
+
+	pctrl->funcs = funcs;
+	pctrl->groups = groups;
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_num_pins(unsigned int *npins)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_PINS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*npins = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_pin_desc() - prepare pin description info
+ * @dev:		Device pointer.
+ * @zynqmp_pins:	Pin information.
+ * @npins:		Number of pins.
+ *
+ * Query number of pins information from firmware and prepare pin
+ * description containing pin number and pin name.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_pin_desc(struct device *dev,
+					   const struct pinctrl_pin_desc
+					   **zynqmp_pins,
+					   unsigned int *npins)
+{
+	struct pinctrl_pin_desc *pins, *pin;
+	int ret;
+	int i;
+
+	ret = zynqmp_pinctrl_get_num_pins(npins);
+	if (ret)
+		return ret;
+
+	pins = devm_kzalloc(dev, sizeof(*pins) * *npins, GFP_KERNEL);
+	if (!pins)
+		return -ENOMEM;
+
+	for (i = 0; i < *npins; i++) {
+		pin = &pins[i];
+		pin->number = i;
+		pin->name = devm_kasprintf(dev, GFP_KERNEL, "%s%d",
+					   ZYNQMP_PIN_PREFIX, i);
+		if (!pin->name)
+			return -ENOMEM;
+	}
+
+	*zynqmp_pins = pins;
+
+	return 0;
+}
+
+static int zynqmp_pinctrl_probe(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl;
+	int ret;
+
+	pctrl = devm_kzalloc(&pdev->dev, sizeof(*pctrl), GFP_KERNEL);
+	if (!pctrl)
+		return -ENOMEM;
+
+	ret = zynqmp_pinctrl_prepare_pin_desc(&pdev->dev,
+					      &zynqmp_desc.pins,
+					      &zynqmp_desc.npins);
+	if (ret) {
+		dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_function_info(&pdev->dev, pctrl);
+	if (ret) {
+		dev_err(&pdev->dev, "function info prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);
+	if (IS_ERR(pctrl->pctrl))
+		return PTR_ERR(pctrl->pctrl);
+
+	platform_set_drvdata(pdev, pctrl);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_remove(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl = platform_get_drvdata(pdev);
+
+	pinctrl_unregister(pctrl->pctrl);
+
+	return 0;
+}
+
+static const struct of_device_id zynqmp_pinctrl_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-pinctrl" },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);
+
+static struct platform_driver zynqmp_pinctrl_driver = {
+	.driver = {
+		.name = "zynqmp-pinctrl",
+		.of_match_table = zynqmp_pinctrl_of_match,
+	},
+	.probe = zynqmp_pinctrl_probe,
+	.remove = zynqmp_pinctrl_remove,
+};
+
+module_platform_driver(zynqmp_pinctrl_driver);
+
+MODULE_AUTHOR("Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>");
+MODULE_DESCRIPTION("ZynqMP Pin Controller Driver");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1



From zhukeqian1 at huawei.com  Thu Apr 15 12:26:26 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 19:26:26 +0800
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <87im4nn8wf.wl-maz@kernel.org>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
 <20210414065109.8616-3-zhukeqian1@huawei.com> <87pmyxme2m.wl-maz@kernel.org>
 <b434317f-ef6d-1d91-0189-8343c404c88c@huawei.com>
 <87im4nn8wf.wl-maz@kernel.org>
Message-ID: <7b5789fb-920d-e797-ba7a-49780bd3d587@huawei.com>

Hi Marc,

On 2021/4/15 18:23, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 03:20:52 +0100,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> Hi Marc,
>>
>> On 2021/4/14 17:05, Marc Zyngier wrote:
>>> + Santosh, who found some interesting bugs in that area before.
>>>
>>> On Wed, 14 Apr 2021 07:51:09 +0100,
>>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>>>
>>>> The MMIO region of a device maybe huge (GB level), try to use
>>>> block mapping in stage2 to speedup both map and unmap.
>>>>
>>>> Compared to normal memory mapping, we should consider two more
>>>> points when try block mapping for MMIO region:
>>>>
>>>> 1. For normal memory mapping, the PA(host physical address) and
>>>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>>>> the HVA to request hugepage, so we don't need to consider PA
>>>> alignment when verifing block mapping. But for device memory
>>>> mapping, the PA and HVA may have different alignment.
>>>>
>>>> 2. For normal memory mapping, we are sure hugepage size properly
>>>> fit into vma, so we don't check whether the mapping size exceeds
>>>> the boundary of vma. But for device memory mapping, we should pay
>>>> attention to this.
>>>>
>>>> This adds device_rough_page_shift() to check these two points when
>>>> selecting block mapping size.
>>>>
>>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>>> ---
>>>>  arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
>>>>  1 file changed, 33 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>>> index c59af5ca01b0..1a6d96169d60 100644
>>>> --- a/arch/arm64/kvm/mmu.c
>>>> +++ b/arch/arm64/kvm/mmu.c
>>>> @@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
>>>>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>>>>  }
>>>>  
>>>> +/*
>>>> + * Find a max mapping size that properly insides the vma. And hva and pa must
>>>> + * have the same alignment to this mapping size. It's rough as there are still
>>>> + * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
>>>> + */
>>>> +static short device_rough_page_shift(struct vm_area_struct *vma,
>>>> +				     unsigned long hva)
>>>
>>> My earlier question still stands. Under which circumstances would this
>>> function return something that is *not* the final mapping size? I
>>> really don't see a reason why this would not return the final mapping
>>> size.
>>
>> IIUC, all the restrictions are about alignment and area boundary.
>>
>> That's to say, HVA, IPA and PA must have same alignment within the
>> mapping size.  And the areas are memslot and vma, which means the
>> mapping size must properly fit into the memslot and vma.
>>
>> In this function, we just checked the alignment of HVA and PA, and
>> the boundary of vma.  So we still need to check the alignment of HVA
>> and IPA, and the boundary of memslot.  These will be checked by
>> fault_supports_stage2_huge_mapping().
> 
> But that's no different from what we do with normal memory, is it? So
> it really feels like we should have *one* function that deals with
> establishing the basic mapping size from the VMA (see below for what I
> have in mind).
Right. And it looks better.

> 
>>
>>>
>>>> +{
>>>> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>>>> +
>>>> +#ifndef __PAGETABLE_PMD_FOLDED
>>>> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>>>> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
>>>> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
>>>> +		return PUD_SHIFT;
>>>> +#endif
>>>> +
>>>> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>>>> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
>>>> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
>>>> +		return PMD_SHIFT;
>>>> +
>>>> +	return PAGE_SHIFT;
>>>> +}
>>>> +
>>>>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
>>>>  					       unsigned long hva,
>>>>  					       unsigned long map_size)
>>>> @@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>>>  		return -EFAULT;
>>>>  	}
>>>>  
>>>> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
>>>> +	/*
>>>> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
>>>> +	 * get block mapping for device MMIO region.
>>>> +	 */
>>>>  	mmap_read_lock(current->mm);
>>>>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>>>>  	if (unlikely(!vma)) {
>>>> @@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>>>  
>>>>  	if (is_vm_hugetlb_page(vma))
>>>>  		vma_shift = huge_page_shift(hstate_vma(vma));
>>>> +	else if (vma->vm_flags & VM_PFNMAP)
>>>> +		vma_shift = device_rough_page_shift(vma, hva);
>>>
>>> What prevents a VMA from having both VM_HUGETLB and VM_PFNMAP? This is
>>> pretty unlikely, but I'd like to see this case catered for.
>>>
>> I'm not sure whether VM_HUGETLB and VM_PFNMAP are compatible, and I
>> failed to find a case.
>>
>> VM_PFNMAP is used for page-ranges managed without "struct page",
>> just pure PFN.  IIUC, VM_HUGETLB is used for hugetlbfs, which always
>> has "struct page".  So I think they should not be compatible,
>> otherwise it's a bug of driver.
> 
> For now, maybe. But huge mappings of PFN could land at some point, and
> it'd be hard to catch. I think this case deserves a VM_BUG_ON().
OK.

> 
>>
>>>>  	else
>>>>  		vma_shift = PAGE_SHIFT;
>>>>  
>>>> -	if (logging_active ||
>>>> -	    (vma->vm_flags & VM_PFNMAP)) {
>>>> +	if (logging_active) {
> 
> BTW, don't you introduce a bug here? Logging shouldn't affect device
> mappings.
I think it's not a bug, because for memlsot with VM_PFNMAP, the logging_active is always false.

In kvm_arch_prepare_memory_region(), we make sure KVM_MEM_LOG_DIRTY_PAGES can't be set for a VM_PFNMAP memslot.
Then in __kvm_set_memory_region(), we're sure dirty_bitmap is not allocated for this memslot.
Then memslot_is_logging() will return false for this memslot.

> 
> 
>>>>  		force_pte = true;
>>>>  		vma_shift = PAGE_SHIFT;
>>>>  	}
>>>> @@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>>>  
>>>>  	if (kvm_is_device_pfn(pfn)) {
>>>>  		device = true;
>>>> -		force_pte = true;
>>>> +		force_pte = (vma_pagesize == PAGE_SIZE);
>>>
>>> Why do we need to set force_pte if we are already dealing with
>>> PAGE_SIZE? I guess you are doing this for the sake of avoiding the
>>> call to transparent_hugepage_adjust(), right?
>> Yes.
>>
>>>
>>> I'd rather you simply don't try to upgrade a device mapping by
>>> explicitly checking for this and keep force_pte for *memory*
>>> exclusively.
>> Agree, that's better.
>>
>>>
>>> Santosh, can you please take a look at this series and try to see if
>>> the problem you fixed in [1] (which ended up as commit 91a2c34b7d6f)
>>> is still OK with this series?
>> I searched the initial version[*], VM_PFNMAP is set when we call
>> gfn_to_pfn_prot()->vma_mmio_fault()->remap_pfn_range().  Then the
>> check of VM_PFNMAP in user_mem_abort() failed, so we will try to
>> call transparent_hugepage_adjust() for device pfn.
>>
>> In that case, our logic of trying block mapping for MMIO is not
>> used. And we still set force_pte for device pfn, so this bugfix is
>> not affected. Santosh, do you agree that?
> 
> But isn't what we just agreed to get rid of just above?
Yes, I agree to get rid of force_pte for device. I'm sure your code
doesn't break the bugfix.

> 
>>
>> I still found that the reason vfio_pci does not have this
>> bug. vfio_pci set VM_PFNMAP for vma when userspace calls mmap().  I
>> will apply this logic for vfio_mdev too, let's see what vfio
>> maintainer think about it.
> 
> I think that'd be good to see what Alex thinks about it...
> 
> Here's the changes I propose. It is completely untested, of course.
> 
> Thanks,
> 
> 	M.
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..f32d956cc199 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>  	return PAGE_SIZE;
>  }
>  
> +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> +{
> +	unsigned long pa;
> +
> +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> +		return huge_page_shift(hstate_vma(vma));
> +
> +	if (!(vma->vm_flags & VM_PFNMAP))
> +		return PAGE_SHIFT;
> +
> +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> +
> +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +
>  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  			  struct kvm_memory_slot *memslot, unsigned long hva,
>  			  unsigned long fault_status)
> @@ -778,13 +807,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  	}
>  
> -	if (is_vm_hugetlb_page(vma))
> -		vma_shift = huge_page_shift(hstate_vma(vma));
> -	else
> -		vma_shift = PAGE_SHIFT;
> +	vma_shift = get_vma_page_shift(vma, hva);
>  
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	if (logging_active && !(vma->vm_flags & VM_PFNMAP)) {
Maybe we don't need this. I can add some comments to explain it.

>  		force_pte = true;
>  		vma_shift = PAGE_SHIFT;
>  	}
> @@ -854,8 +879,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  
>  	if (kvm_is_device_pfn(pfn)) {
> +		/*
> +		 * If the page was identified as device early by looking at
> +		 * the VMA flags, vma_pagesize is already representing the
> +		 * largest quantity we can map.  If instead it was mapped
> +		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> +		 * and must not be upgraded.
> +		 *
> +		 * In both cases, we don't let transparent_hugepage_adjust()
> +		 * change things at the last minute.
> +		 */
>  		device = true;
> -		force_pte = true;
>  	} else if (logging_active && !write_fault) {
>  		/*
>  		 * Only actually map the page as writable if this was a write
> @@ -876,7 +910,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	 * If we are not forced to use page mapping, check if we are
>  	 * backed by a THP and thus use block mapping if possible.
>  	 */
> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> +	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
>  		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>  							   &pfn, &fault_ipa);
>  	if (writable)
> 
Looks good to me. :)

I will test it. And when I send v4, should I add your Suggested-by or SoB?


Thanks,
Keqian


From zhukeqian1 at huawei.com  Thu Apr 15 12:34:40 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 19:34:40 +0800
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile
 helpers
In-Reply-To: <87h7k7n81z.wl-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-2-maz@kernel.org>
 <baa268cf-c92d-6b97-da4c-e7da2a9ccb7a@huawei.com>
 <87h7k7n81z.wl-maz@kernel.org>
Message-ID: <da73e0c7-4dd7-ce69-3304-3da8f1521127@huawei.com>

Hi Marc,

On 2021/4/15 18:42, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 07:59:26 +0100,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> Hi Marc,
>>
>> On 2021/4/14 21:44, Marc Zyngier wrote:
>>> KVM/arm64 is the sole user of perf_num_counters(), and really
>>> could do without it. Stop using the obsolete API by relying on
>>> the existing probing code.
>>>
>>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>>> ---
>>>  arch/arm64/kvm/perf.c     | 7 +------
>>>  arch/arm64/kvm/pmu-emul.c | 2 +-
>>>  include/kvm/arm_pmu.h     | 4 ++++
>>>  3 files changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
>>> index 739164324afe..b8b398670ef2 100644
>>> --- a/arch/arm64/kvm/perf.c
>>> +++ b/arch/arm64/kvm/perf.c
>>> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
>>>  
>>>  int kvm_perf_init(void)
>>>  {
>>> -	/*
>>> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
>>> -	 * hardware performance counters. This could ensure the presence of
>>> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
>>> -	 */
>>> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
>>> +	if (kvm_pmu_probe_pmuver() != 0xf)
>> The probe() function may be called many times
>> (kvm_arm_pmu_v3_set_attr also calls it).  I don't know whether the
>> first calling is enough. If so, can we use a static variable in it,
>> so the following calling can return the result right away?
> 
> No, because that wouldn't help with crappy big-little implementations
> that could have PMUs with different versions. We want to find the
> version at the point where the virtual PMU is created, which is why we
> call the probe function once per vcpu.
I see.

But AFAICS the pmuver is placed in kvm->arch, and the probe function is called
once per VM. Maybe I miss something.

> 
> This of course is broken in other ways (BL+KVM is a total disaster
> when it comes to PMU), but making this static would just make it
> worse.
OK.

Thanks,
Keqian


From daniel at ffwll.ch  Thu Apr 15 12:35:36 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 15 Apr 2021 13:35:36 +0200
Subject: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
In-Reply-To: <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <20210413094904.3736372-5-daniel.vetter@ffwll.ch>
 <290aef5ed13749d465eb19235aa87a2cef63dd2a.camel@pengutronix.de>
Message-ID: <YHglCIAhDFPoLPRL@phenom.ffwll.local>

On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> > 
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > Date:   Fri Jan 4 09:56:10 2019 +0100
> > 
> > ????drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > 
> > this is done automatically as part of plane init, if drivers set the
> > modifier list correctly. Which is the case here.
> > 
> > This one actually set it twice on top of what drm_plane_init does, so
> > double-redundant!
> 
> That's not true. imx-dcss and imx-drm are two totally separate drivers.
> Maybe we should move imx-drm into its own ipuv3 directory one day to
> make this more clear. Change is still correct, though.

I've fixed the commit message to reflect reality and merged to
drm-misc-next. Thanks for taking a look.
-Daniel

> 
> Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > Cc: Philipp Zabel <p.zabel at pengutronix.de>
> > Cc: Shawn Guo <shawnguo at kernel.org>
> > Cc: Sascha Hauer <s.hauer at pengutronix.de>
> > Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
> > Cc: Fabio Estevam <festevam at gmail.com>
> > Cc: NXP Linux Team <linux-imx at nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > ---
> > ?drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 -
> > ?drivers/gpu/drm/imx/imx-drm-core.c  | 1 -
> > ?2 files changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > index b549ce5e7607..37ae68a7fba5 100644
> > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev *kms)
> > ?	config->min_height = 1;
> > ?	config->max_width = 4096;
> > ?	config->max_height = 4096;
> > -	config->allow_fb_modifiers = true;
> > ?	config->normalize_zpos = true;
> > ?
> > 
> > 
> > 
> > ?	config->funcs = &dcss_drm_mode_config_funcs;
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 2ded8e4f32d0..8be4edaec958 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev)
> > ?	drm->mode_config.max_height = 4096;
> > ?	drm->mode_config.funcs = &imx_drm_mode_config_funcs;
> > ?	drm->mode_config.helper_private = &imx_drm_mode_config_helpers;
> > -	drm->mode_config.allow_fb_modifiers = true;
> > ?	drm->mode_config.normalize_zpos = true;
> > ?
> > 
> > 
> > 
> > ?	ret = drmm_mode_config_init(drm);
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From wangyanan55 at huawei.com  Thu Apr 15 12:50:29 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:29 +0800
Subject: [PATCH v5 3/6] KVM: arm64: Add mm_ops member for structure
 stage2_attr_data
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-4-wangyanan55@huawei.com>

Also add a mm_ops member for structure stage2_attr_data, since we
will move I-cache maintenance for guest stage-2 to the permission
path and as a result will need mm_ops for address transformation.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/kvm/hyp/pgtable.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index e3606c9dcec7..b480f6d1171e 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -869,10 +869,11 @@ int kvm_pgtable_stage2_unmap(struct kvm_pgtable *pgt, u64 addr, u64 size)
 }
 
 struct stage2_attr_data {
-	kvm_pte_t	attr_set;
-	kvm_pte_t	attr_clr;
-	kvm_pte_t	pte;
-	u32		level;
+	kvm_pte_t			attr_set;
+	kvm_pte_t			attr_clr;
+	kvm_pte_t			pte;
+	u32				level;
+	struct kvm_pgtable_mm_ops	*mm_ops;
 };
 
 static int stage2_attr_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
@@ -911,6 +912,7 @@ static int stage2_update_leaf_attrs(struct kvm_pgtable *pgt, u64 addr,
 	struct stage2_attr_data data = {
 		.attr_set	= attr_set & attr_mask,
 		.attr_clr	= attr_clr & attr_mask,
+		.mm_ops		= pgt->mm_ops,
 	};
 	struct kvm_pgtable_walker walker = {
 		.cb		= stage2_attr_walker,
-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:31 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:31 +0800
Subject: [PATCH v5 5/6] KVM: arm64: Move I-cache flush to the fault handlers
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-6-wangyanan55@huawei.com>

In this patch, we move invalidation of I-cache to the fault handlers to
avoid unnecessary I-cache maintenances. On the map path, invalidate the
I-cache if we are going to create an executable stage-2 mapping for guest.
And on the permission path, invalidate the I-cache if we are going to add
an executable permission to the existing guest stage-2 mapping.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 15 --------------
 arch/arm64/kvm/hyp/pgtable.c     | 35 +++++++++++++++++++++++++++++++-
 arch/arm64/kvm/mmu.c             |  9 +-------
 3 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index e9b163c5f023..155492fe5b15 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -187,21 +187,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 	return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
 }
 
-static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
-						  unsigned long size)
-{
-	if (icache_is_aliasing()) {
-		/* any kind of VIPT cache */
-		__flush_icache_all();
-	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
-		/* PIPT or VPIPT at EL2 (see comment in __kvm_tlb_flush_vmid_ipa) */
-		void *va = page_address(pfn_to_page(pfn));
-
-		invalidate_icache_range((unsigned long)va,
-					(unsigned long)va + size);
-	}
-}
-
 void kvm_set_way_flush(struct kvm_vcpu *vcpu);
 void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);
 
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index b480f6d1171e..9f4429d80df0 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -568,6 +568,26 @@ static bool stage2_pte_cacheable(struct kvm_pgtable *pgt, kvm_pte_t pte)
 	return memattr == KVM_S2_MEMATTR(pgt, NORMAL);
 }
 
+static bool stage2_pte_executable(kvm_pte_t pte)
+{
+	return !(pte & KVM_PTE_LEAF_ATTR_HI_S2_XN);
+}
+
+static void stage2_invalidate_icache(void *addr, u64 size)
+{
+	if (icache_is_aliasing()) {
+		/* Any kind of VIPT cache */
+		__flush_icache_all();
+	} else if (is_kernel_in_hyp_mode() || !icache_is_vpipt()) {
+		/*
+		 * See comment in __kvm_tlb_flush_vmid_ipa().
+		 * Invalidate PIPT, or VPIPT at EL2.
+		 */
+		invalidate_icache_range((unsigned long)addr,
+					(unsigned long)addr + size);
+	}
+}
+
 static void stage2_put_pte(kvm_pte_t *ptep, struct kvm_s2_mmu *mmu, u64 addr,
 			   u32 level, struct kvm_pgtable_mm_ops *mm_ops)
 {
@@ -618,6 +638,10 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 		if (stage2_pte_cacheable(pgt, new) && !stage2_has_fwb(pgt))
 			__flush_dcache_area(mm_ops->phys_to_virt(phys),
 					    granule);
+
+		if (stage2_pte_executable(new))
+			stage2_invalidate_icache(mm_ops->phys_to_virt(phys),
+						 granule);
 	}
 
 	smp_store_release(ptep, new);
@@ -896,8 +920,17 @@ static int stage2_attr_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 	 * but worst-case the access flag update gets lost and will be
 	 * set on the next access instead.
 	 */
-	if (data->pte != pte)
+	if (data->pte != pte) {
+		/*
+		 * Invalidate the instruction cache before updating
+		 * if we are going to add the executable permission
+		 * for the guest stage-2 PTE.
+		 */
+		if (!stage2_pte_executable(*ptep) && stage2_pte_executable(pte))
+			stage2_invalidate_icache(kvm_pte_follow(pte, data->mm_ops),
+						 kvm_granule_size(level));
 		WRITE_ONCE(*ptep, pte);
+	}
 
 	return 0;
 }
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 86f7dd1c234f..aa536392b308 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -694,11 +694,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
 	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
 }
 
-static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	__invalidate_icache_guest_page(pfn, size);
-}
-
 static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
 {
 	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
@@ -967,10 +962,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (writable)
 		prot |= KVM_PGTABLE_PROT_W;
 
-	if (exec_fault) {
+	if (exec_fault)
 		prot |= KVM_PGTABLE_PROT_X;
-		invalidate_icache_guest_page(pfn, vma_pagesize);
-	}
 
 	if (device)
 		prot |= KVM_PGTABLE_PROT_DEVICE;
-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:28 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:28 +0800
Subject: [PATCH v5 2/6] KVM: arm64: Move D-cache flush to the fault handlers
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-3-wangyanan55@huawei.com>

We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.

By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the page table code.

This patch only moves clean of D-cache to the map path, and drop the
original APIs in mmu.c/mmu.h for D-cache maintenance by using what we
already have in pgtable.c. Change about the I-side will come from a
later patch.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 16 ----------------
 arch/arm64/kvm/hyp/pgtable.c     | 20 ++++++++++++++------
 arch/arm64/kvm/mmu.c             | 14 +++-----------
 3 files changed, 17 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 25ed956f9af1..e9b163c5f023 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -187,22 +187,6 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 	return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101;
 }
 
-static inline void __clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	void *va = page_address(pfn_to_page(pfn));
-
-	/*
-	 * With FWB, we ensure that the guest always accesses memory using
-	 * cacheable attributes, and we don't have to clean to PoC when
-	 * faulting in pages. Furthermore, FWB implies IDC, so cleaning to
-	 * PoU is not required either in this case.
-	 */
-	if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
-		return;
-
-	kvm_flush_dcache_to_poc(va, size);
-}
-
 static inline void __invalidate_icache_guest_page(kvm_pfn_t pfn,
 						  unsigned long size)
 {
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index c37c1dc4feaf..e3606c9dcec7 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -562,6 +562,12 @@ static bool stage2_pte_is_counted(kvm_pte_t pte)
 	return !!pte;
 }
 
+static bool stage2_pte_cacheable(struct kvm_pgtable *pgt, kvm_pte_t pte)
+{
+	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
+	return memattr == KVM_S2_MEMATTR(pgt, NORMAL);
+}
+
 static void stage2_put_pte(kvm_pte_t *ptep, struct kvm_s2_mmu *mmu, u64 addr,
 			   u32 level, struct kvm_pgtable_mm_ops *mm_ops)
 {
@@ -583,6 +589,7 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 {
 	kvm_pte_t new, old = *ptep;
 	u64 granule = kvm_granule_size(level), phys = data->phys;
+	struct kvm_pgtable *pgt = data->mmu->pgt;
 	struct kvm_pgtable_mm_ops *mm_ops = data->mm_ops;
 
 	if (!kvm_block_mapping_supported(addr, end, phys, level))
@@ -606,6 +613,13 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 		stage2_put_pte(ptep, data->mmu, addr, level, mm_ops);
 	}
 
+	/* Perform CMOs before installation of the guest stage-2 PTE */
+	if (pgt->flags & KVM_PGTABLE_S2_GUEST) {
+		if (stage2_pte_cacheable(pgt, new) && !stage2_has_fwb(pgt))
+			__flush_dcache_area(mm_ops->phys_to_virt(phys),
+					    granule);
+	}
+
 	smp_store_release(ptep, new);
 	if (stage2_pte_is_counted(new))
 		mm_ops->get_page(ptep);
@@ -798,12 +812,6 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
 	return ret;
 }
 
-static bool stage2_pte_cacheable(struct kvm_pgtable *pgt, kvm_pte_t pte)
-{
-	u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
-	return memattr == KVM_S2_MEMATTR(pgt, NORMAL);
-}
-
 static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
 			       enum kvm_pgtable_walk_flags flag,
 			       void * const arg)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 2cfcfc5f4e4e..86f7dd1c234f 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -694,11 +694,6 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm,
 	kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
 }
 
-static void clean_dcache_guest_page(kvm_pfn_t pfn, unsigned long size)
-{
-	__clean_dcache_guest_page(pfn, size);
-}
-
 static void invalidate_icache_guest_page(kvm_pfn_t pfn, unsigned long size)
 {
 	__invalidate_icache_guest_page(pfn, size);
@@ -972,9 +967,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (writable)
 		prot |= KVM_PGTABLE_PROT_W;
 
-	if (fault_status != FSC_PERM && !device)
-		clean_dcache_guest_page(pfn, vma_pagesize);
-
 	if (exec_fault) {
 		prot |= KVM_PGTABLE_PROT_X;
 		invalidate_icache_guest_page(pfn, vma_pagesize);
@@ -1234,10 +1226,10 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 	trace_kvm_set_spte_hva(hva);
 
 	/*
-	 * We've moved a page around, probably through CoW, so let's treat it
-	 * just like a translation fault and clean the cache to the PoC.
+	 * We've moved a page around, probably through CoW, so let's treat
+	 * it just like a translation fault and the map handler will clean
+	 * the cache to the PoC.
 	 */
-	clean_dcache_guest_page(pfn, PAGE_SIZE);
 	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
 	return 0;
 }
-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:30 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:30 +0800
Subject: [PATCH v5 4/6] KVM: arm64: Provide invalidate_icache_range at non-VHE
 EL2
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-5-wangyanan55@huawei.com>

We want to move I-cache maintenance for the guest to the stage-2
page table code for performance improvement. Before it can work,
we should first make function invalidate_icache_range available
to non-VHE EL2 to avoid compiling or program running error, as
pgtable.c is now linked into the non-VHE EL2 code for pKVM mode.

In this patch, we only introduce symbol of invalidate_icache_range
with no real functionality in nvhe/cache.S, because there haven't
been situations found currently where I-cache maintenance is also
needed in non-VHE EL2 for pKVM mode.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/kvm/hyp/nvhe/cache.S | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/cache.S b/arch/arm64/kvm/hyp/nvhe/cache.S
index 36cef6915428..a125ec9aeed2 100644
--- a/arch/arm64/kvm/hyp/nvhe/cache.S
+++ b/arch/arm64/kvm/hyp/nvhe/cache.S
@@ -11,3 +11,14 @@ SYM_FUNC_START_PI(__flush_dcache_area)
 	dcache_by_line_op civac, sy, x0, x1, x2, x3
 	ret
 SYM_FUNC_END_PI(__flush_dcache_area)
+
+/*
+ *	invalidate_icache_range(start,end)
+ *
+ *	Ensure that the I cache is invalid within specified region.
+ *
+ *	- start   - virtual start address of region
+ *	- end     - virtual end address of region
+ */
+SYM_FUNC_START(invalidate_icache_range)
+SYM_FUNC_END(invalidate_icache_range)
-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:26 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:26 +0800
Subject: [PATCH v5 0/6] KVM: arm64: Improve efficiency of stage2 page table
Message-ID: <20210415115032.35760-1-wangyanan55@huawei.com>

Hi,

This series makes some efficiency improvement of guest stage-2 page
table code, and there are some test results to quantify the benefit.
The code has been re-arranged based on the latest kvmarm/next tree.

Descriptions:
We currently uniformly permorm CMOs of D-cache and I-cache in function
user_mem_abort before calling the fault handlers. If we get concurrent
guest faults(e.g. translation faults, permission faults) or some really
unnecessary guest faults caused by BBM, CMOs for the first vcpu are
necessary while the others later are not.

By moving CMOs to the fault handlers, we can easily identify conditions
where they are really needed and avoid the unnecessary ones. As it's a
time consuming process to perform CMOs especially when flushing a block
range, so this solution reduces much load of kvm and improve efficiency
of the stage-2 page table code.

In this series, patch #1, #3, #4 make preparation for place movement
of CMOs (adapt to the latest stage-2 page table framework). And patch
#2, #5 move CMOs of D-cache and I-cache to the fault handlers. Patch
#6 introduces a new way to distinguish cases of memcache allocations.

The following are results in v3 to represent the benefit introduced
by movement of CMOs, and they were tested by [1] (kvm/selftest) that
I have posted recently.
[1] https://lore.kernel.org/lkml/20210302125751.19080-1-wangyanan55 at huawei.com/

When there are muitiple vcpus concurrently accessing the same memory
region, we can test the execution time of KVM creating new mappings,
updating the permissions of old mappings from RO to RW, and the time
of re-creating the blocks after they have been split.

hardware platform: HiSilicon Kunpeng920 Server
host kernel: Linux mainline v5.12-rc2

cmdline: ./kvm_page_table_test -m 4 -s anonymous -b 1G -v 80
           (80 vcpus, 1G memory, page mappings(normal 4K))
KVM_CREATE_MAPPINGS: before 104.35s -> after  90.42s  +13.35%
KVM_UPDATE_MAPPINGS: before  78.64s -> after  75.45s  + 4.06%

cmdline: ./kvm_page_table_test -m 4 -s anonymous_thp -b 20G -v 40
           (40 vcpus, 20G memory, block mappings(THP 2M))
KVM_CREATE_MAPPINGS: before  15.66s -> after   6.92s  +55.80%
KVM_UPDATE_MAPPINGS: before 178.80s -> after 123.35s  +31.00%
KVM_REBUILD_BLOCKS:  before 187.34s -> after 131.76s  +30.65%

cmdline: ./kvm_page_table_test -m 4 -s anonymous_hugetlb_1gb -b 20G -v 40
           (40 vcpus, 20G memory, block mappings(HUGETLB 1G))
KVM_CREATE_MAPPINGS: before 104.54s -> after   3.70s  +96.46%
KVM_UPDATE_MAPPINGS: before 174.20s -> after 115.94s  +33.44%
KVM_REBUILD_BLOCKS:  before 103.95s -> after   2.96s  +97.15%

---

Changelogs:
v4->v5:
- rebased on the latest kvmarm/tree to adapt to the new stage-2 page-table code
- v4: https://lore.kernel.org/lkml/20210409033652.28316-1-wangyanan55 at huawei.com/

v3->v4:
- perform D-cache flush if we are not mapping device memory
- rebased on top of mainline v5.12-rc6
- v3: https://lore.kernel.org/lkml/20210326031654.3716-1-wangyanan55 at huawei.com/

v2->v3:
- drop patch #3 in v2
- retest v3 based on v5.12-rc2
- v2: https://lore.kernel.org/lkml/20210310094319.18760-1-wangyanan55 at huawei.com/

v1->v2:
- rebased on top of mainline v5.12-rc2
- also move CMOs of I-cache to the fault handlers
- retest v2 based on v5.12-rc2
- v1: https://lore.kernel.org/lkml/20210208112250.163568-1-wangyanan55 at huawei.com/

---

Yanan Wang (6):
  KVM: arm64: Introduce KVM_PGTABLE_S2_GUEST stage-2 flag
  KVM: arm64: Move D-cache flush to the fault handlers
  KVM: arm64: Add mm_ops member for structure stage2_attr_data
  KVM: arm64: Provide invalidate_icache_range at non-VHE EL2
  KVM: arm64: Move I-cache flush to the fault handlers
  KVM: arm64: Distinguish cases of memcache allocations completely

 arch/arm64/include/asm/kvm_mmu.h     | 31 -------------
 arch/arm64/include/asm/kvm_pgtable.h | 38 ++++++++++------
 arch/arm64/kvm/hyp/nvhe/cache.S      | 11 +++++
 arch/arm64/kvm/hyp/pgtable.c         | 65 +++++++++++++++++++++++-----
 arch/arm64/kvm/mmu.c                 | 51 ++++++++--------------
 5 files changed, 107 insertions(+), 89 deletions(-)

-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:32 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:32 +0800
Subject: [PATCH v5 6/6] KVM: arm64: Distinguish cases of memcache allocations
 completely
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-7-wangyanan55@huawei.com>

With a guest translation fault, the memcache pages are not needed if KVM
is only about to install a new leaf entry into the existing page table.
And with a guest permission fault, the memcache pages are also not needed
for a write_fault in dirty-logging time if KVM is only about to update
the existing leaf entry instead of collapsing a block entry into a table.

By comparing fault_granule and vma_pagesize, cases that require allocations
from memcache and cases that don't can be distinguished completely.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index aa536392b308..9e35aa5d29f2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -895,19 +895,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	gfn = fault_ipa >> PAGE_SHIFT;
 	mmap_read_unlock(current->mm);
 
-	/*
-	 * Permission faults just need to update the existing leaf entry,
-	 * and so normally don't require allocations from the memcache. The
-	 * only exception to this is when dirty logging is enabled at runtime
-	 * and a write fault needs to collapse a block entry into a table.
-	 */
-	if (fault_status != FSC_PERM || (logging_active && write_fault)) {
-		ret = kvm_mmu_topup_memory_cache(memcache,
-						 kvm_mmu_cache_min_pages(kvm));
-		if (ret)
-			return ret;
-	}
-
 	mmu_seq = vcpu->kvm->mmu_notifier_seq;
 	/*
 	 * Ensure the read of mmu_notifier_seq happens before we call
@@ -970,6 +957,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
 		prot |= KVM_PGTABLE_PROT_X;
 
+	/*
+	 * Allocations from the memcache are required only when granule of the
+	 * lookup level where the guest fault happened exceeds vma_pagesize,
+	 * which means new page tables will be created in the fault handlers.
+	 */
+	if (fault_granule > vma_pagesize) {
+		ret = kvm_mmu_topup_memory_cache(memcache,
+						 kvm_mmu_cache_min_pages(kvm));
+		if (ret)
+			return ret;
+	}
+
 	/*
 	 * Under the premise of getting a FSC_PERM fault, we just need to relax
 	 * permissions only if vma_pagesize equals fault_granule. Otherwise,
-- 
2.23.0



From wangyanan55 at huawei.com  Thu Apr 15 12:50:27 2021
From: wangyanan55 at huawei.com (Yanan Wang)
Date: Thu, 15 Apr 2021 19:50:27 +0800
Subject: [PATCH v5 1/6] KVM: arm64: Introduce KVM_PGTABLE_S2_GUEST stage-2 flag
In-Reply-To: <20210415115032.35760-1-wangyanan55@huawei.com>
References: <20210415115032.35760-1-wangyanan55@huawei.com>
Message-ID: <20210415115032.35760-2-wangyanan55@huawei.com>

The stage-2 page table code in pgtable.c now is generally used for
guest stage-2 and host stage-2. There may be some different issues
between guest S2 page-table and host S2 page-table that we should
consider, e.g., whether CMOs are needed when creating a new mapping.

So introduce the KVM_PGTABLE_S2_GUEST flag to determine if we are
doing something about guest stage-2. This flag will be used in a
coming patch, in which we will move CMOs for guest to pgtable.c.

Signed-off-by: Yanan Wang <wangyanan55 at huawei.com>
---
 arch/arm64/include/asm/kvm_pgtable.h | 38 ++++++++++++++++++----------
 arch/arm64/kvm/mmu.c                 |  3 ++-
 2 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index c3674c47d48c..a43cbe697b37 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -61,10 +61,12 @@ struct kvm_pgtable_mm_ops {
  * @KVM_PGTABLE_S2_NOFWB:	Don't enforce Normal-WB even if the CPUs have
  *				ARM64_HAS_STAGE2_FWB.
  * @KVM_PGTABLE_S2_IDMAP:	Only use identity mappings.
+ * @KVM_PGTABLE_S2_GUEST:	Whether the page-tables are guest stage-2.
  */
 enum kvm_pgtable_stage2_flags {
 	KVM_PGTABLE_S2_NOFWB			= BIT(0),
 	KVM_PGTABLE_S2_IDMAP			= BIT(1),
+	KVM_PGTABLE_S2_GUEST			= BIT(2),
 };
 
 /**
@@ -221,12 +223,10 @@ int kvm_pgtable_stage2_init_flags(struct kvm_pgtable *pgt, struct kvm_arch *arch
 				  struct kvm_pgtable_mm_ops *mm_ops,
 				  enum kvm_pgtable_stage2_flags flags);
 
-#define kvm_pgtable_stage2_init(pgt, arch, mm_ops) \
-	kvm_pgtable_stage2_init_flags(pgt, arch, mm_ops, 0)
-
 /**
  * kvm_pgtable_stage2_destroy() - Destroy an unused guest stage-2 page-table.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  *
  * The page-table is assumed to be unreachable by any hardware walkers prior
  * to freeing and therefore no TLB invalidation is performed.
@@ -235,7 +235,8 @@ void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt);
 
 /**
  * kvm_pgtable_stage2_map() - Install a mapping in a guest stage-2 page-table.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address at which to place the mapping.
  * @size:	Size of the mapping.
  * @phys:	Physical address of the memory to map.
@@ -268,7 +269,8 @@ int kvm_pgtable_stage2_map(struct kvm_pgtable *pgt, u64 addr, u64 size,
 /**
  * kvm_pgtable_stage2_set_owner() - Unmap and annotate pages in the IPA space to
  *				    track ownership.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Base intermediate physical address to annotate.
  * @size:	Size of the annotated range.
  * @mc:		Cache of pre-allocated and zeroed memory from which to allocate
@@ -287,7 +289,8 @@ int kvm_pgtable_stage2_set_owner(struct kvm_pgtable *pgt, u64 addr, u64 size,
 
 /**
  * kvm_pgtable_stage2_unmap() - Remove a mapping from a guest stage-2 page-table.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address from which to remove the mapping.
  * @size:	Size of the mapping.
  *
@@ -307,7 +310,8 @@ int kvm_pgtable_stage2_unmap(struct kvm_pgtable *pgt, u64 addr, u64 size);
 /**
  * kvm_pgtable_stage2_wrprotect() - Write-protect guest stage-2 address range
  *                                  without TLB invalidation.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address from which to write-protect,
  * @size:	Size of the range.
  *
@@ -324,7 +328,8 @@ int kvm_pgtable_stage2_wrprotect(struct kvm_pgtable *pgt, u64 addr, u64 size);
 
 /**
  * kvm_pgtable_stage2_mkyoung() - Set the access flag in a page-table entry.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address to identify the page-table entry.
  *
  * The offset of @addr within a page is ignored.
@@ -338,7 +343,8 @@ kvm_pte_t kvm_pgtable_stage2_mkyoung(struct kvm_pgtable *pgt, u64 addr);
 
 /**
  * kvm_pgtable_stage2_mkold() - Clear the access flag in a page-table entry.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address to identify the page-table entry.
  *
  * The offset of @addr within a page is ignored.
@@ -357,7 +363,8 @@ kvm_pte_t kvm_pgtable_stage2_mkold(struct kvm_pgtable *pgt, u64 addr);
 /**
  * kvm_pgtable_stage2_relax_perms() - Relax the permissions enforced by a
  *				      page-table entry.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address to identify the page-table entry.
  * @prot:	Additional permissions to grant for the mapping.
  *
@@ -376,7 +383,8 @@ int kvm_pgtable_stage2_relax_perms(struct kvm_pgtable *pgt, u64 addr,
 /**
  * kvm_pgtable_stage2_is_young() - Test whether a page-table entry has the
  *				   access flag set.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address to identify the page-table entry.
  *
  * The offset of @addr within a page is ignored.
@@ -389,7 +397,8 @@ bool kvm_pgtable_stage2_is_young(struct kvm_pgtable *pgt, u64 addr);
  * kvm_pgtable_stage2_flush_range() - Clean and invalidate data cache to Point
  * 				      of Coherency for guest stage-2 address
  *				      range.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Intermediate physical address from which to flush.
  * @size:	Size of the range.
  *
@@ -428,7 +437,8 @@ int kvm_pgtable_walk(struct kvm_pgtable *pgt, u64 addr, u64 size,
  * kvm_pgtable_stage2_find_range() - Find a range of Intermediate Physical
  *				     Addresses with compatible permission
  *				     attributes.
- * @pgt:	Page-table structure initialised by kvm_pgtable_stage2_init*().
+ * @pgt:	Page-table structure initialised by function
+ *		kvm_pgtable_stage2_init_flags().
  * @addr:	Address that must be covered by the range.
  * @prot:	Protection attributes that the range must be compatible with.
  * @range:	Range structure used to limit the search space at call time and
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index cd4d51ae3d4a..2cfcfc5f4e4e 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -457,7 +457,8 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu)
 	if (!pgt)
 		return -ENOMEM;
 
-	err = kvm_pgtable_stage2_init(pgt, &kvm->arch, &kvm_s2_mm_ops);
+	err = kvm_pgtable_stage2_init_flags(pgt, &kvm->arch, &kvm_s2_mm_ops,
+					    KVM_PGTABLE_S2_GUEST);
 	if (err)
 		goto out_free_pgtable;
 
-- 
2.23.0



From hca at linux.ibm.com  Thu Apr 15 13:12:10 2021
From: hca at linux.ibm.com (Heiko Carstens)
Date: Thu, 15 Apr 2021 14:12:10 +0200
Subject: [PATCH 3/5] s390: Get rid of oprofile leftovers
In-Reply-To: <87fszrn7sx.wl-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-4-maz@kernel.org> <YHgXvFCLh0Ls0b9t@osiris>
 <87fszrn7sx.wl-maz@kernel.org>
Message-ID: <YHgtmjjtk9dDa7/R@osiris>

On Thu, Apr 15, 2021 at 11:47:26AM +0100, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 11:38:52 +0100,
> Heiko Carstens <hca at linux.ibm.com> wrote:
> > 
> > On Wed, Apr 14, 2021 at 02:44:07PM +0100, Marc Zyngier wrote:
> > > perf_pmu_name() and perf_num_counters() are unused. Drop them.
> > > 
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > ---
> > >  arch/s390/kernel/perf_event.c | 21 ---------------------
> > >  1 file changed, 21 deletions(-)
> > 
> > Acked-by: Heiko Carstens <hca at linux.ibm.com>
> > 
> > ...or do you want me to pick this up and route via the s390 tree(?).
> 
> Either way work for me, but I just want to make sure the last patch
> doesn't get applied before the previous ones.

Ok, I applied this one to the s390 tree. Thanks!


From alexandre.torgue at foss.st.com  Thu Apr 15 13:12:18 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 15 Apr 2021 14:12:18 +0200
Subject: [PATCH 10/13] dt-bindings: mfd: add vref_ddr-supply to st, stpmic1
 yaml
In-Reply-To: <9fc27672-765b-9bd3-bb0a-d9159cb7d502@pengutronix.de>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-11-alexandre.torgue@foss.st.com>
 <9fc27672-765b-9bd3-bb0a-d9159cb7d502@pengutronix.de>
Message-ID: <906ea3e5-0aaa-2307-e6fb-aaac1a5e5d00@foss.st.com>

Hi Ahmad

On 4/15/21 12:51 PM, Ahmad Fatoum wrote:
> Hi,
> 
> On 15.04.21 12:10, Alexandre Torgue wrote:
>> Add vref_ddr-supply to the STPMIC1 regulators supplies pattern
>> list.
>>
>> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
>> index 305123e74a58..ffc32d209496 100644
>> --- a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
>> +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
>> @@ -184,7 +184,7 @@ properties:
>>           additionalProperties: false
>>   
>>       patternProperties:
>> -      "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
>> +      "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])-supply$":
> 
> IIRC, vref-ddr was a hack because a change in the regulator core broke
> the STM32MP1 boards. I believe vref-ddr should be removed altogether
> instead. It's supplied from BUCK2IN, which is already in the binding,
> so it's redundant.

Correct I forgot this point. We got random crash without this 
vddr_ref_supply but I don't know if regulator FW has been updated to fix 
it. If yes, I'll drop this one and remove
vddr_ref_supply from DT file.

> 
> Cheers,
> Ahmad
> 
>>           description: STPMIC1 voltage regulators supplies
>>   
>>         "^(buck[1-4]|ldo[1-6]|boost|vref_ddr|pwr_sw[1-2])$":
>>
> 


From broonie at kernel.org  Thu Apr 15 13:17:42 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 15 Apr 2021 13:17:42 +0100
Subject: [PATCH] arm64/sve: Add compile time checks for SVE hooks in generic
 functions
Message-ID: <20210415121742.36628-1-broonie@kernel.org>

The FPSIMD code was relying on IS_ENABLED() checks in system_suppors_sve()
to cause the compiler to delete references to SVE functions in some places,
add explicit IS_ENABLED() checks back.

Fixes: ef9c5d09797db874a2 (arm64/sve: Remove redundant system_supports_sve() tests)
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/kernel/fpsimd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index f6cd89131dc3..ad3dd34a83cf 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -285,7 +285,7 @@ static void task_fpsimd_load(void)
 	WARN_ON(!system_supports_fpsimd());
 	WARN_ON(!have_cpu_fpsimd_context());
 
-	if (test_thread_flag(TIF_SVE))
+	if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE))
 		sve_load_state(sve_pffr(&current->thread),
 			       &current->thread.uw.fpsimd_state.fpsr,
 			       sve_vq_from_vl(current->thread.sve_vl) - 1);
@@ -307,7 +307,8 @@ static void fpsimd_save(void)
 	WARN_ON(!have_cpu_fpsimd_context());
 
 	if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
-		if (test_thread_flag(TIF_SVE)) {
+		if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+		    test_thread_flag(TIF_SVE)) {
 			if (WARN_ON(sve_get_vl() != last->sve_vl)) {
 				/*
 				 * Can't save the user regs, so current would
-- 
2.20.1



From hca at linux.ibm.com  Thu Apr 15 13:20:48 2021
From: hca at linux.ibm.com (Heiko Carstens)
Date: Thu, 15 Apr 2021 14:20:48 +0200
Subject: consolidate the flock uapi definitions
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
References: <20210412085545.2595431-1-hch@lst.de>
Message-ID: <YHgvoCpqLrcbQETJ@osiris>

On Mon, Apr 12, 2021 at 10:55:40AM +0200, Christoph Hellwig wrote:
> Hi all,
> 
> currently we deal with the slight differents in the various architecture
> variants of the flock and flock64 stuctures in a very cruft way.  This
> series switches to just use small arch hooks and define the rest in
> asm-generic and linux/compat.h instead.
> 
> Diffstat:
>  arch/arm64/include/asm/compat.h        |   20 --------------------
>  arch/mips/include/asm/compat.h         |   23 ++---------------------
>  arch/mips/include/uapi/asm/fcntl.h     |   28 +++-------------------------
>  arch/parisc/include/asm/compat.h       |   16 ----------------
>  arch/powerpc/include/asm/compat.h      |   20 --------------------
>  arch/s390/include/asm/compat.h         |   20 --------------------
>  arch/sparc/include/asm/compat.h        |   22 +---------------------
>  arch/x86/include/asm/compat.h          |   24 +++---------------------
>  include/linux/compat.h                 |   31 +++++++++++++++++++++++++++++++
>  include/uapi/asm-generic/fcntl.h       |   21 +++++++--------------
>  tools/include/uapi/asm-generic/fcntl.h |   21 +++++++--------------
>  11 files changed, 54 insertions(+), 192 deletions(-)

for the s390 bits:
Acked-by: Heiko Carstens <hca at linux.ibm.com>


From alexandre.torgue at foss.st.com  Thu Apr 15 13:23:32 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 15 Apr 2021 14:23:32 +0200
Subject: [PATCH 12/13] ARM: dts: stm32: fix DSI port node on STM32MP15
In-Reply-To: <ececc78c-4fca-bb93-ef62-5d107501d963@pengutronix.de>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-13-alexandre.torgue@foss.st.com>
 <ececc78c-4fca-bb93-ef62-5d107501d963@pengutronix.de>
Message-ID: <96da49dc-f24d-aa12-e1d8-39b5a5b6fbc9@foss.st.com>

Hi Ahmad

On 4/15/21 12:43 PM, Ahmad Fatoum wrote:
> Hi,
> 
> On 15.04.21 12:10, Alexandre Torgue wrote:
>> Running "make dtbs_check W=1", some warnings are reported concerning
>> DSI. This patch reorder DSI nodes to avoid:
>>
>> soc/dsi at 5a000000: unnecessary #address-cells/#size-cells without
>> "ranges" or child "reg" property
> 
> This reverts parts of commit 9c32f980d9 ("ARM: dts: stm32: preset
> stm32mp15x video #address- and #size-cells"):
>      
>      The cell count for address and size is defined by the binding and not
>      something a board would change. Avoid each board adding this
>      boilerplate by having the cell size specification in the SoC DTSI.
>      
> 
> The DSI can have child nodes with a unit address (e.g. a panel) and ones
> without (ports { } container). ports is described in the dtsi, panels are
> described in the dts if available.
> 
> Apparently, the checker is fine with
> ports {
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> };
> 
> I think my rationale for the patch above was sound, so I think the checker
> taking offense at the DSI cells here should be considered a false positive.

If it's a "false positive" warning then we need to find a way to not 
print it out. Else, it'll be difficult to distinguish which warnings are 
"normal" and which are not. This question could also be applied to patch[3].

Arnd, Rob what is your feeling about this case ?

thanks
alex



> Thanks,
> Ahmad
> 
>>
>> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>
>> diff --git a/arch/arm/boot/dts/stm32mp157.dtsi b/arch/arm/boot/dts/stm32mp157.dtsi
>> index 54e73ccea446..c355fcf26ec3 100644
>> --- a/arch/arm/boot/dts/stm32mp157.dtsi
>> +++ b/arch/arm/boot/dts/stm32mp157.dtsi
>> @@ -24,8 +24,6 @@
>>   			clock-names = "pclk", "ref", "px_clk";
>>   			resets = <&rcc DSI_R>;
>>   			reset-names = "apb";
>> -			#address-cells = <1>;
>> -			#size-cells = <0>;
>>   			status = "disabled";
>>   
>>   			ports {
>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> index 19ef475a48fc..763dde1dbbaf 100644
>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> @@ -36,6 +36,8 @@
>>   &dsi {
>>   	status = "okay";
>>   	phy-dsi-supply = <&reg18>;
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>>   
>>   	ports {
>>   		port at 0 {
>> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> index 6fe5b0fee7c4..4625bb58cc6d 100644
>> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> @@ -102,6 +102,8 @@
>>   &dsi {
>>   	phy-dsi-supply = <&reg18>;
>>   	status = "okay";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>>   
>>   	ports {
>>   		port at 0 {
>>
> 


From leo.yan at linaro.org  Thu Apr 15 13:30:23 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 20:30:23 +0800
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210414143919.12605-2-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
Message-ID: <20210415123023.GA1011890@leoy-ThinkPad-X240s>

Hi James,

On Wed, Apr 14, 2021 at 05:39:19PM +0300, James Clark wrote:
> The following attribute is set when synthesising samples in
> timed decoding mode:
> 
>     attr.sample_type |= PERF_SAMPLE_TIME;
> 
> This results in new samples that appear to have timestamps but
> because we don't assign any timestamps to the samples, when the
> resulting inject file is opened again, the synthesised samples
> will be on the wrong side of the MMAP or COMM events.
> 
> For example this results in the samples being associated with
> the perf binary, rather than the target of the record:
> 
>     perf record -e cs_etm/@tmc_etr0/u top
>     perf inject -i perf.data -o perf.inject --itrace=i100il
>     perf report -i perf.inject
> 
> Where 'Command' == perf should show as 'top':
> 
>     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>     # ........  .......  ....................  ......................  ......................  ..................
>     #
>         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
> 
> If the perf.data file is opened directly with perf, without the
> inject step, then this already works correctly because the
> events are synthesised after the COMM and MMAP events and
> no second sorting happens. Re-sorting only happens when opening
> the perf.inject file for the second time so timestamps are
> needed.
> 
> Using the timestamp from the AUX record mirrors the current
> behaviour when opening directly with perf, because the events
> are generated on the call to cs_etm__process_queues().
> 
> Signed-off-by: James Clark <james.clark at arm.com>
> Co-developed-by: Al Grant <al.grant at arm.com>
> Signed-off-by: Al Grant <al.grant at arm.com>
> ---
>  tools/perf/util/cs-etm.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index c25da2ffa8f3..d0fa9dce47f1 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>  	u8 sample_instructions;
>  
>  	int num_cpu;
> +	u64 latest_kernel_timestamp;
>  	u32 auxtrace_type;
>  	u64 branches_sample_type;
>  	u64 branches_id;
> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = addr;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = ip;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>  		return cs_etm__process_switch_cpu_wide(etm, event);
>  
> -	if (!etm->timeless_decoding &&
> -	    event->header.type == PERF_RECORD_AUX)
> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
>  		return cs_etm__process_queues(etm);
> +	}

The change looks good to me, I went through these two patches for at
least twice, and didn't find issue.

And given the trace data might be overflow and overwritten, it's
reasonable for me to use the PERF_RECORD_AUX timestamp from the tail of
trace data.

Reviewed-by: Leo Yan <leo.yan at linaro.org>

>  	return 0;
>  }
> -- 
> 2.28.0
> 


From leo.yan at linaro.org  Thu Apr 15 13:39:53 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 20:39:53 +0800
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
 <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>
Message-ID: <20210415123953.GB1011890@leoy-ThinkPad-X240s>

On Wed, Apr 14, 2021 at 05:41:46PM +0300, James Clark wrote:
> Hi,
> 
> For this change, I also tried removing the setting of PERF_SAMPLE_TIME in cs_etm__synth_events(). In theory, this would remove the sorting when opening the file, but the change doesn't affect when the built-in events are saved to the inject file. Resulting in events like MMAP and COMM with timestamps, but the synthesised events without. This results in the same issue of the synthesised events appearing before the COMM and MMAP events. If it was possible to somehow tell perf to remove timestamps from built-in events, removing PERF_SAMPLE_TIME would probably be the right solution, because we don't set sample.time.
> 
> For Arm v8.4 we will have the kernel time in the etm timestamps, so an if can be added to switch between this behaviour and the next (more correct) one depending on the hardware. 
> 
> On the subject of timestamps, but not related to this change, some combinations of timestamp options aren't working. For example:
> 
>     perf record -e cs_etm/time, at tmc_etr0/u --per-thread
> or  perf record -e cs_etm/@tmc_etr0/u --timestamp --per-thread
> 
> These don't work because of the assumption that etm->timeless_decoding == --per-thread
> and kernel timestamps enabled (/time/ or --timestamp) == etm timestamps enabled (/timestamp/), which isn't necessarily true.
> 
> This can be made to work with a few code changes for cs_etm/time,timestamp/u --per-thread, but cs_etm/time/u --per-thread could be a bit more work. Changes involved would be using "per_cpu_mmaps" in some places instead of etm->timeless_decoding, and also setting etm->timeless_decoding based on whether there are any etm timestamps, not kernel ones. Although to search for any etm timestamp would involve a full decode ahead of time which might not be feasible (or maybe just checking the options, although that's not how it's done in cs_etm__is_timeless_decoding() currently).

Confirm for one thing:

For the orignal perf data file with "--per-thread" option, the decoder
runs into the condition for "etm->timeless_decoding"; and it doesn't
contain ETM timestamp.

Afterwards, the injected perf data file also misses ETM timestamp and
hit the condition "etm->timeless_decoding".

So I am confusing why the original perf data can be processed properly
but fails to handle the injected perf data file.

Thanks,
Leo

> Or, we could force /time/ and /timestamp/ options to always be enabled together in the record stage. 
> 
> 
> Thanks
> James
> 
> On 14/04/2021 17:39, James Clark wrote:
> > The following attribute is set when synthesising samples in
> > timed decoding mode:
> > 
> >     attr.sample_type |= PERF_SAMPLE_TIME;
> > 
> > This results in new samples that appear to have timestamps but
> > because we don't assign any timestamps to the samples, when the
> > resulting inject file is opened again, the synthesised samples
> > will be on the wrong side of the MMAP or COMM events.
> > 
> > For example this results in the samples being associated with
> > the perf binary, rather than the target of the record:
> > 
> >     perf record -e cs_etm/@tmc_etr0/u top
> >     perf inject -i perf.data -o perf.inject --itrace=i100il
> >     perf report -i perf.inject
> > 
> > Where 'Command' == perf should show as 'top':
> > 
> >     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
> >     # ........  .......  ....................  ......................  ......................  ..................
> >     #
> >         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
> > 
> > If the perf.data file is opened directly with perf, without the
> > inject step, then this already works correctly because the
> > events are synthesised after the COMM and MMAP events and
> > no second sorting happens. Re-sorting only happens when opening
> > the perf.inject file for the second time so timestamps are
> > needed.
> > 
> > Using the timestamp from the AUX record mirrors the current
> > behaviour when opening directly with perf, because the events
> > are generated on the call to cs_etm__process_queues().
> > 
> > Signed-off-by: James Clark <james.clark at arm.com>
> > Co-developed-by: Al Grant <al.grant at arm.com>
> > Signed-off-by: Al Grant <al.grant at arm.com>
> > ---
> >  tools/perf/util/cs-etm.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > index c25da2ffa8f3..d0fa9dce47f1 100644
> > --- a/tools/perf/util/cs-etm.c
> > +++ b/tools/perf/util/cs-etm.c
> > @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
> >  	u8 sample_instructions;
> >  
> >  	int num_cpu;
> > +	u64 latest_kernel_timestamp;
> >  	u32 auxtrace_type;
> >  	u64 branches_sample_type;
> >  	u64 branches_id;
> > @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
> >  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
> >  	event->sample.header.size = sizeof(struct perf_event_header);
> >  
> > +	if (!etm->timeless_decoding)
> > +		sample.time = etm->latest_kernel_timestamp;
> >  	sample.ip = addr;
> >  	sample.pid = tidq->pid;
> >  	sample.tid = tidq->tid;
> > @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
> >  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
> >  	event->sample.header.size = sizeof(struct perf_event_header);
> >  
> > +	if (!etm->timeless_decoding)
> > +		sample.time = etm->latest_kernel_timestamp;
> >  	sample.ip = ip;
> >  	sample.pid = tidq->pid;
> >  	sample.tid = tidq->tid;
> > @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
> >  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
> >  		return cs_etm__process_switch_cpu_wide(etm, event);
> >  
> > -	if (!etm->timeless_decoding &&
> > -	    event->header.type == PERF_RECORD_AUX)
> > +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
> > +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
> >  		return cs_etm__process_queues(etm);
> > +	}
> >  
> >  	return 0;
> >  }
> > 


From catalin.marinas at arm.com  Thu Apr 15 13:41:22 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 13:41:22 +0100
Subject: [arm64:for-next/misc 13/14] ld.lld: error: undefined symbol:
 sve_get_vl
In-Reply-To: <202104150734.PulXU4BV-lkp@intel.com>
References: <202104150734.PulXU4BV-lkp@intel.com>
Message-ID: <20210415124121.GC1015@arm.com>

On Thu, Apr 15, 2021 at 07:13:41AM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/misc
> head:   839157876f97fcc7ead0b62c9377bb50f75a3df9
> commit: ef9c5d09797db874a29a97407c3ea3990210432b [13/14] arm64/sve: Remove redundant system_supports_sve() tests
> config: arm64-randconfig-r036-20210414 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 9829f5e6b1bca9b61efc629770d28bb9014dec45)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # install arm64 cross compiling tool for clang build
>         # apt-get install binutils-aarch64-linux-gnu
>         # https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=ef9c5d09797db874a29a97407c3ea3990210432b
>         git remote add arm64 https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>         git fetch --no-tags arm64 for-next/misc
>         git checkout ef9c5d09797db874a29a97407c3ea3990210432b
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>

Thanks for the report. That indeed triggers if CONFIG_ARM64_SVE is
disabled. Proposed fix:

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index f6cd89131dc3..9d433854a662 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -285,7 +285,7 @@ static void task_fpsimd_load(void)
 	WARN_ON(!system_supports_fpsimd());
 	WARN_ON(!have_cpu_fpsimd_context());
 
-	if (test_thread_flag(TIF_SVE))
+	if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE))
 		sve_load_state(sve_pffr(&current->thread),
 			       &current->thread.uw.fpsimd_state.fpsr,
 			       sve_vq_from_vl(current->thread.sve_vl) - 1);
@@ -307,7 +307,7 @@ static void fpsimd_save(void)
 	WARN_ON(!have_cpu_fpsimd_context());
 
 	if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
-		if (test_thread_flag(TIF_SVE)) {
+		if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) {
 			if (WARN_ON(sve_get_vl() != last->sve_vl)) {
 				/*
 				 * Can't save the user regs, so current would

-- 
Catalin


From liuqi115 at huawei.com  Thu Apr 15 13:48:03 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Thu, 15 Apr 2021 20:48:03 +0800
Subject: [PATCH v3 0/2] drivers/perf: hisi: Add support for PCIe PMU
Message-ID: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>

This patchset adds support for HiSilicon PCIe Performance Monitoring
Unit(PMU). It is a PCIe Root Complex integrated End Point(RCiEP) device
added on Hip09. Each PCIe Core has a PMU RCiEP to monitor multi root
ports and all Endpoints downstream these root ports.

HiSilicon PCIe PMU is supported to collect performance data of PCIe bus,
such as: bandwidth, latency etc.

This patchset is based on 5.12-rc6. 

Changes since v2:
- Address the comments from John.
- Link: https://lore.kernel.org/linux-arm-kernel/1617959157-22956-1-git-send-email-liuqi115 at huawei.com/

Changes since v1:
- Drop the internal Reviewed-by tag.
- Fix some build warnings when W=1.
- Link: https://lore.kernel.org/linux-arm-kernel/1617788943-52722-1-git-send-email-liuqi115 at huawei.com/

Qi Liu (2):
  docs: perf: Add description for HiSilicon PCIe PMU driver
  drivers/perf: hisi: Add driver for HiSilicon PCIe PMU

 Documentation/admin-guide/perf/hisi-pcie-pmu.rst |  104 +++
 MAINTAINERS                                      |    6 +
 drivers/perf/Kconfig                             |    2 +
 drivers/perf/Makefile                            |    1 +
 drivers/perf/pci/Kconfig                         |   16 +
 drivers/perf/pci/Makefile                        |    2 +
 drivers/perf/pci/hisilicon/Makefile              |    3 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c       | 1014 ++++++++++++++++++++++
 include/linux/cpuhotplug.h                       |    1 +
 9 files changed, 1149 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

-- 
2.7.4



From liuqi115 at huawei.com  Thu Apr 15 13:48:04 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Thu, 15 Apr 2021 20:48:04 +0800
Subject: [PATCH v3 1/2] docs: perf: Add description for HiSilicon PCIe PMU
 driver
In-Reply-To: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
References: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1618490885-44612-2-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported on
HiSilicon HIP09 platform. Document it to provide guidance on how to
use it.

Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 Documentation/admin-guide/perf/hisi-pcie-pmu.rst | 104 +++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/admin-guide/perf/hisi-pcie-pmu.rst

diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
new file mode 100644
index 0000000..2084b53
--- /dev/null
+++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst
@@ -0,0 +1,104 @@
+================================================
+HiSilicon PCIe Performance Monitoring Unit (PMU)
+================================================
+
+HiSilicon PCIe Performance Monitoring Unit (PMU) is a PCIe Root Complex
+integrated End Point (RCiEP) device. On Hip09, each PCIe Core has a PMU RCiEP
+to monitor multi Root Ports and all Endpoints downstream these Root Ports.
+
+HiSilicon PCIe PMU is supported to collect performance data of PCIe bus, such
+as: bandwidth, latency etc.
+
+
+HiSilicon PCIe PMU driver
+=========================
+
+The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe
+Core id.::
+
+  /sys/bus/event_source/hisi_pcie<sicl>_<core>
+
+PMU driver provides description of available events and filter options in sysfs,
+see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>.
+
+The "format" directory describes all formats of the config (events) and config1
+(filter options) fields of the perf_event_attr structure. The "events" directory
+describes all documented events shown in perf list.
+
+The "identifier" sysfs file allows users to identify the version of the
+PMU hardware device.
+
+The "bus" sysfs file allows users to get the bus number of Root Ports
+monitored by PMU.
+
+Example usage of perf::
+
+  $# perf list
+  hisi_pcie0_0/bw_rx/ [kernel PMU event]
+  ------------------------------------------
+
+  $# perf stat -e hisi_pcie0_0/bw_rx/ sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported for PCIe PMU.
+
+Filter options
+--------------
+
+1. Target filter
+PMU could only monitor the performance of traffic downstream target Root Ports
+or downstream target Endpoint. PCIe PMU driver support "port" and "bdf"
+interfaces for users, and these two interfaces aren't supported at the same
+time.
+
+-port
+"port" filter can be used in all PCIe PMU events, target Root Port can be
+selected by configuring the 16-bits-bitmap "port". Multi ports can be selected
+for AP-layer-events, and only one port can be selected for TL/DL-layer-events.
+
+For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of bitmap
+should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 lanes),
+bit8 is set, port=0x100; if these two Root Ports are both monitored, port=0x101.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,port=0x1/ sleep 5
+
+-bdf
+
+"bdf" filter can only be used in bandwidth events, target Endpoint is selected
+by configuring BDF to "bdf". Counter only counts the bandwidth of message
+requested by target Endpoint.
+
+For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,bdf=0x3900/ sleep 5
+
+2. Trigger filter
+Event statistics start when the first time TLP length is greater/smaller
+than trigger condition. You can set the trigger condition by writing "trig_len",
+and set the trigger mode by writing "trig_mode". This filter can only be used
+in bandwidth events.
+
+For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0"
+means statistics start when TLP length > trigger condition, "trig_mode=1"
+means start when TLP length < condition.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,trig_len=0x4,trig_mode=1/ sleep 5
+
+3. Threshold filter
+Counter counts when TLP length within the specified range. You can set the
+threshold by writing "thr_len", and set the threshold mode by writing
+"thr_mode". This filter can only be used in bandwidth events.
+
+For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means
+counter counts when TLP length >= threshold, and "thr_mode=1" means counts
+when TLP length < threshold.
+
+Example usage of perf::
+
+  $# perf stat -e hisi_pcie0_0/bw_rx,thr_len=0x4,thr_mode=1/ sleep 5
-- 
2.7.4



From liuqi115 at huawei.com  Thu Apr 15 13:48:05 2021
From: liuqi115 at huawei.com (Qi Liu)
Date: Thu, 15 Apr 2021 20:48:05 +0800
Subject: [PATCH v3 2/2] drivers/perf: hisi: Add driver for HiSilicon PCIe PMU
In-Reply-To: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
References: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
Message-ID: <1618490885-44612-3-git-send-email-liuqi115@huawei.com>

PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
to sample bandwidth, latency, buffer occupation etc.

Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
registered as a PMU in /sys/bus/event_source/devices, so users can
select target PMU, and use filter to do further sets.

Filtering options contains:
event        - select the event.
subevent     - select the subevent.
port         - select target Root Ports. Information of Root Ports
               are shown under sysfs.
bdf          - select requester_id of target EP device.
trig_len     - set trigger condition for starting event statistics.
trigger_mode - set trigger mode. 0 means starting to statistic when
               bigger than trigger condition, and 1 means smaller.
thr_len      - set threshold for statistics.
thr_mode     - set threshold mode. 0 means count when bigger than
               threshold, and 1 means smaller.

Signed-off-by: Qi Liu <liuqi115 at huawei.com>
---
 MAINTAINERS                                |    6 +
 drivers/perf/Kconfig                       |    2 +
 drivers/perf/Makefile                      |    1 +
 drivers/perf/pci/Kconfig                   |   16 +
 drivers/perf/pci/Makefile                  |    2 +
 drivers/perf/pci/hisilicon/Makefile        |    3 +
 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1014 ++++++++++++++++++++++++++++
 include/linux/cpuhotplug.h                 |    1 +
 8 files changed, 1045 insertions(+)
 create mode 100644 drivers/perf/pci/Kconfig
 create mode 100644 drivers/perf/pci/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/Makefile
 create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7fdc513..efe06cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8084,6 +8084,12 @@ W:	http://www.hisilicon.com
 F:	Documentation/admin-guide/perf/hisi-pmu.rst
 F:	drivers/perf/hisilicon
 
+HISILICON PCIE PMU DRIVER
+M:	Qi Liu <liuqi115 at huawei.com>
+S:	Maintained
+F:	Documentation/admin-guide/perf/hisi-pcie-pmu.rst
+F:	drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
+
 HISILICON QM AND ZIP Controller DRIVER
 M:	Zhou Wang <wangzhou1 at hisilicon.com>
 L:	linux-crypto at vger.kernel.org
diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 77522e5..ddd82fa 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -139,4 +139,6 @@ config ARM_DMC620_PMU
 
 source "drivers/perf/hisilicon/Kconfig"
 
+source "drivers/perf/pci/Kconfig"
+
 endmenu
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index 5260b11..1208c08 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
 obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
+obj-y += pci/
diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
new file mode 100644
index 0000000..9f30291
--- /dev/null
+++ b/drivers/perf/pci/Kconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# PCIe Performance Monitor Drivers
+#
+menu "PCIe Performance Monitor"
+
+config HISI_PCIE_PMU
+	tristate "HiSilicon PCIE PERF PMU"
+	depends on (ARM64 && PCI) || COMPILE_TEST
+	help
+	  Provide support for HiSilicon PCIe performance monitoring unit (PMU)
+	  RCiEP devices.
+	  Adds the PCIe PMU into perf events system for monitoring latency,
+	  bandwidth etc.
+
+endmenu
diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
new file mode 100644
index 0000000..a56b1a9
--- /dev/null
+++ b/drivers/perf/pci/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-y += hisilicon/
diff --git a/drivers/perf/pci/hisilicon/Makefile b/drivers/perf/pci/hisilicon/Makefile
new file mode 100644
index 0000000..65b0bd7
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
new file mode 100644
index 0000000..415bf39
--- /dev/null
+++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
@@ -0,0 +1,1014 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This driver adds support for PCIe PMU RCiEP device. Related
+ * perf events are bandwidth, bandwidth utilization, latency
+ * etc.
+ *
+ * Copyright (C) 2021 HiSilicon Limited
+ * Author: Qi Liu<liuqi115 at huawei.com>
+ */
+#include <linux/bitfield.h>
+#include <linux/bitmap.h>
+#include <linux/bug.h>
+#include <linux/cpuhotplug.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/perf_event.h>
+
+/* Define registers */
+#define HISI_PCIE_GLOBAL_CTRL		0x00
+#define HISI_PCIE_EVENT_CTRL		0x010
+#define HISI_PCIE_CNT			0x090
+#define HISI_PCIE_EXT_CNT		0x110
+#define HISI_PCIE_INT_STAT		0x150
+#define HISI_PCIE_INT_MASK		0x154
+#define HISI_PCIE_REG_BDF		0xfe0
+#define HISI_PCIE_REG_VERSION		0xfe4
+#define HISI_PCIE_REG_INFO		0xfe8
+#define HISI_PCIE_REG_FREQ		0xfec
+
+/* Define PCIE CTRL CMD */
+#define HISI_PCIE_GLOBAL_EN		0x01
+#define HISI_PCIE_GLOBAL_NONE		0
+#define HISI_PCIE_EVENT_EN		BIT(20)
+#define HISI_PCIE_RESET_CNT		BIT(22)
+#define HISI_PCIE_DEFAULT_SET		BIT(34)
+#define HISI_PCIE_THR_EN		BIT(26)
+#define HISI_PCIE_TARGET_EN		BIT(32)
+#define HISI_PCIE_TRIG_EN		BIT(52)
+
+/* Define offsets in event ctrl regesiter */
+#define HISI_PCIE_EVENT_M		GENMASK_ULL(7, 0)
+#define HISI_PCIE_SUBEVENT_M		GENMASK_ULL(15, 8)
+#define HISI_PCIE_THR_MODE_M		GENMASK_ULL(27, 27)
+#define HISI_PCIE_THR_M			GENMASK_ULL(31, 28)
+#define HISI_PCIE_TARGET_M		GENMASK_ULL(52, 36)
+#define HISI_PCIE_TRIG_MODE_M		GENMASK_ULL(53, 53)
+#define HISI_PCIE_TRIG_M		GENMASK_ULL(59, 56)
+
+#define HISI_PCIE_MAX_COUNTERS		8
+#define HISI_PCIE_REG_STEP		8
+#define HISI_PCIE_EVENT_MAX		0xa2
+#define HISI_PCIE_SUBEVENT_MAX		0x20
+#define HISI_PCIE_THR_MAX_VAL		10
+#define HISI_PCIE_TRIG_MAX_VAL		10
+#define HISI_PCIE_COUNTER_BITS		64
+#define HISI_PCIE_MAX_PERIOD		BIT_ULL(63)
+
+struct hisi_pcie_pmu {
+	struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
+	struct hlist_node node;
+	struct pci_dev *pdev;
+	struct pmu pmu;
+	void __iomem *base;
+	int irq;
+	u32 identifier;
+	/* Minimum and maximum bdf of root ports monitored by PMU */
+	u16 bdf_min;
+	u16 bdf_max;
+	int on_cpu;
+};
+
+#define to_pcie_pmu(p)  (container_of((p), struct hisi_pcie_pmu, pmu))
+#define GET_PCI_DEVFN(bdf)  ((bdf) & 0xff)
+
+#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)		  \
+	static u64 hisi_pcie_get_##_name(struct perf_event *event)	  \
+	{								  \
+		return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
+	}								  \
+
+HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
+HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
+HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
+HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
+HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
+HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
+HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
+HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
+
+#define HISI_PCIE_BUILD_EVENTS(name)				     	\
+	static bool is_##name##_event(u32 idx)				\
+	{								\
+		return (idx >= name##_events_list[0] &&			\
+			idx <= name##_events_list[1]) ||		\
+			idx == name##_events_list[2]; 			\
+	}								\
+
+/*
+ * The first element of event list is minimum index of TL-layer events
+ * and the second element is maximum index. The third element is index
+ * of a DL-layer event.
+ */
+static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
+static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
+static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
+static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
+
+HISI_PCIE_BUILD_EVENTS(bw);
+HISI_PCIE_BUILD_EVENTS(latency);
+HISI_PCIE_BUILD_EVENTS(bus_util);
+HISI_PCIE_BUILD_EVENTS(buf_util);
+
+static ssize_t hisi_pcie_format_sysfs_show(struct device *dev,
+				    struct device_attribute *attr, char *buf)
+{
+	struct dev_ext_attribute *eattr;
+
+	eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+	return sysfs_emit(buf, "%s\n", (char *)eattr->var);
+}
+
+static ssize_t hisi_pcie_event_sysfs_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct dev_ext_attribute *eattr;
+
+	eattr = container_of(attr, struct dev_ext_attribute, attr);
+
+	return sysfs_emit(buf, "config=0x%lx\n", (unsigned long)eattr->var);
+}
+
+#define HISI_PCIE_PMU_ATTR(_name, _func, _config)			\
+	(&((struct dev_ext_attribute[]) {				\
+		{ __ATTR(_name, 0444, _func, NULL), (void *)_config }   \
+	})[0].attr.attr)
+
+#define HISI_PCIE_PMU_FORMAT_ATTR(_name, _format)			\
+	HISI_PCIE_PMU_ATTR(_name, hisi_pcie_format_sysfs_show, (void *)_format)
+#define HISI_PCIE_PMU_EVENT_ATTR(_name, _event)			\
+	HISI_PCIE_PMU_ATTR(_name, hisi_pcie_event_sysfs_show, (void *)_event)
+
+static ssize_t hisi_pcie_cpumask_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "%d\n", pcie_pmu->on_cpu);
+}
+
+static ssize_t hisi_pcie_identifier_show(struct device *dev,
+					 struct device_attribute *attr,
+					 char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%x\n", pcie_pmu->identifier);
+}
+
+static ssize_t hisi_pcie_bus_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(dev_get_drvdata(dev));
+
+	return sysfs_emit(buf, "0x%02x\n", PCI_BUS_NUM(pcie_pmu->bdf_min));
+}
+
+static void hisi_pcie_parse_reg_value(struct hisi_pcie_pmu *pcie_pmu,
+				      u32 reg_off, u16 *arg0, u16 *arg1)
+{
+	u32 val = readl(pcie_pmu->base + reg_off);
+
+	*arg0 = val & 0xffff;
+	*arg1 = (val & 0xffff0000) >> 16;
+}
+
+static u32 hisi_pcie_pmu_get_offset(u32 offset, u32 idx)
+{
+	return offset + HISI_PCIE_REG_STEP * idx;
+}
+
+static u32 hisi_pcie_pmu_readl(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readl(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writel(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u32 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writel(val, pcie_pmu->base + offset);
+}
+
+static u64 hisi_pcie_pmu_readq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+			       u32 idx)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	return readq(pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_writeq(struct hisi_pcie_pmu *pcie_pmu, u32 reg_offset,
+				 u32 idx, u64 val)
+{
+	u32 offset = hisi_pcie_pmu_get_offset(reg_offset, idx);
+
+	writeq(val, pcie_pmu->base + offset);
+}
+
+static void hisi_pcie_pmu_config_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 reg = HISI_PCIE_DEFAULT_SET;
+	u64 port, trig_len, thr_len;
+	u32 idx = hwc->idx;
+
+	/* Config HISI_PCIE_EVENT_CTRL according to event and subevent. */
+	reg |= FIELD_PREP(HISI_PCIE_EVENT_M, hisi_pcie_get_event(event)) |
+	       FIELD_PREP(HISI_PCIE_SUBEVENT_M, hisi_pcie_get_subevent(event));
+
+	/* Config HISI_PCIE_EVENT_CTRL according to ROOT PORT or EP device. */
+	port = hisi_pcie_get_port(event);
+	if (port)
+		reg |= FIELD_PREP(HISI_PCIE_TARGET_M, port);
+	else
+		reg |= HISI_PCIE_TARGET_EN |
+		       FIELD_PREP(HISI_PCIE_TARGET_M, hisi_pcie_get_bdf(event));
+
+	/* Config HISI_PCIE_EVENT_CTRL according to trigger condition. */
+	trig_len = hisi_pcie_get_trig_len(event);
+	if (trig_len)
+		reg |= FIELD_PREP(HISI_PCIE_TRIG_M, trig_len) |
+		       FIELD_PREP(HISI_PCIE_TRIG_MODE_M,
+		       hisi_pcie_get_trig_mode(event)) | HISI_PCIE_TRIG_EN;
+
+	/* Config HISI_PCIE_EVENT_CTRL according to threshold condition. */
+	thr_len = hisi_pcie_get_thr_len(event);
+	if (thr_len)
+		reg |= FIELD_PREP(HISI_PCIE_THR_M, thr_len) |
+		       FIELD_PREP(HISI_PCIE_THR_MODE_M,
+		       hisi_pcie_get_thr_mode(event)) | HISI_PCIE_THR_EN;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, reg);
+}
+
+static void hisi_pcie_pmu_clear_filter(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, hwc->idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+static bool hisi_pcie_pmu_valid_port(struct hisi_pcie_pmu *pcie_pmu, u16 rp_bdf)
+{
+	return rp_bdf >= pcie_pmu->bdf_min && rp_bdf <= pcie_pmu->bdf_max;
+}
+
+static bool hisi_pcie_pmu_valid_requester_id(struct hisi_pcie_pmu *pcie_pmu,
+					    u32 bdf)
+{
+	struct pci_dev *root_port, *pdev;
+
+	pdev = pci_get_domain_bus_and_slot(pci_domain_nr(pcie_pmu->pdev->bus),
+					   PCI_BUS_NUM(bdf),
+					   GET_PCI_DEVFN(bdf));
+	if (!pdev)
+		return false;
+
+	root_port = pcie_find_root_port(pdev);
+	if (!root_port)
+		return false;
+
+	pci_dev_put(pdev);
+	return hisi_pcie_pmu_valid_port(pcie_pmu, pci_dev_id(root_port));
+}
+
+static bool hisi_pcie_pmu_valid_filter(struct perf_event *event,
+				       struct hisi_pcie_pmu *pcie_pmu)
+{
+	u32 subev_idx = hisi_pcie_get_subevent(event);
+	u32 event_idx = hisi_pcie_get_event(event);
+	u32 requester_id = hisi_pcie_get_bdf(event);
+
+	if (subev_idx > HISI_PCIE_SUBEVENT_MAX ||
+	    event_idx > HISI_PCIE_EVENT_MAX) {
+		pci_err(pcie_pmu->pdev,
+			"Max event index and max subevent index is: %d, %d.\n",
+			HISI_PCIE_EVENT_MAX, HISI_PCIE_SUBEVENT_MAX);
+		return false;
+	}
+
+	if (hisi_pcie_get_thr_len(event) > HISI_PCIE_THR_MAX_VAL)
+		return false;
+
+	if (hisi_pcie_get_trig_len(event) > HISI_PCIE_TRIG_MAX_VAL)
+		return false;
+
+	if (requester_id) {
+		if (!hisi_pcie_pmu_valid_requester_id(pcie_pmu, requester_id))
+			return false;
+	}
+
+	return true;
+}
+
+static bool hisi_pcie_pmu_validate_event_group(struct perf_event *event)
+{
+	struct perf_event *sibling, *leader = event->group_leader;
+	int counters = 1;
+
+	if (!is_software_event(leader)) {
+		if (leader->pmu != event->pmu)
+			return false;
+
+		if (leader != event)
+			counters++;
+	}
+
+	for_each_sibling_event(sibling, event->group_leader) {
+		if (is_software_event(sibling))
+			continue;
+
+		if (sibling->pmu != event->pmu)
+			return false;
+
+		counters++;
+	}
+
+	return counters <= HISI_PCIE_MAX_COUNTERS;
+}
+
+static int hisi_pcie_pmu_event_init(struct perf_event *event)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+
+	event->cpu = pcie_pmu->on_cpu;
+
+	if (event->attr.type != event->pmu->type)
+		return -ENOENT;
+
+	/* Sampling is not supported. */
+	if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
+		return -EOPNOTSUPP;
+
+	if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
+		pci_err(pcie_pmu->pdev, "Invalid filter!\n");
+		return -EINVAL;
+	}
+
+	if (!hisi_pcie_pmu_validate_event_group(event))
+		return -EINVAL;
+
+	return 0;
+}
+
+/*
+ * The bandwidth, latency, bus utilization and buffer occupancy features are
+ * calculated from data in HISI_PCIE_CNT and extern data in HISI_PCIE_EXT_CNT.
+ * Other features are obtained only by HISI_PCIE_CNT.
+ * So data and data_ext are processed in this function to get performanace
+ * value like, bandwidth, latency, etc.
+ */
+static u64 hisi_pcie_pmu_get_performance(struct perf_event *event, u64 data,
+					 u64 data_ext)
+{
+#define CONVERT_DW_TO_BYTE(x)	(sizeof(u32) * (x))
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
+	u32 idx = hisi_pcie_get_event(event);
+
+	if (!data_ext)
+		return 0;
+
+	/* Process data to set unit of bandwidth as "Byte/ms". */
+	if (is_bw_event(idx)) {
+		if (!data_ext / 1000)
+			return 0;
+
+		return (CONVERT_DW_TO_BYTE(data)) / (data_ext / 1000);
+	}
+
+	/* Process data to set unit of latency as "us". */
+	if (is_latency_event(idx))
+		return (data * us_per_cycle) / data_ext;
+
+	if (is_bus_util_event(idx))
+		return (data * us_per_cycle) / data_ext;
+
+	if (is_buf_util_event(idx))
+		return data / (data_ext * us_per_cycle);
+
+	return data;
+}
+
+static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 *cnt,
+				       u64 *cnt_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	*cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
+	*cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
+}
+
+static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 val,
+					u64 val_ext)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	u32 idx = event->hw.idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
+}
+
+static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
+{
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		if (!pcie_pmu->hw_events[idx])
+			return idx;
+	}
+
+	return -EINVAL;
+}
+
+static void hisi_pcie_pmu_event_update(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
+	u64 new_cnt_ext, prev_cnt_ext;
+	u64 new_cnt, prev_cnt, delta;
+
+	hwc_ext = &hwc->extra_reg;
+	do {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
+	} while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
+				 new_cnt) != prev_cnt);
+
+	hwc_ext->config = new_cnt_ext;
+
+	delta = hisi_pcie_pmu_get_performance(event, new_cnt - prev_cnt,
+					      new_cnt_ext - prev_cnt_ext);
+	local64_add(delta, &event->count);
+}
+
+static void hisi_pcie_pmu_read(struct perf_event *event)
+{
+	hisi_pcie_pmu_event_update(event);
+}
+
+static void hisi_pcie_pmu_set_period(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 val = BIT_ULL(HISI_PCIE_COUNTER_BITS - 1);
+
+	hwc_ext = &hwc->extra_reg;
+	local64_set(&hwc->prev_count, val);
+	hwc_ext->config = 0;
+	hisi_pcie_pmu_write_counter(event, val, 0);
+}
+
+static void hisi_pcie_pmu_enable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					 struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val |= HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_disable_counter(struct hisi_pcie_pmu *pcie_pmu,
+					  struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+	u64 val;
+
+	val = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx);
+	val &= ~HISI_PCIE_EVENT_EN;
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx, val);
+}
+
+static void hisi_pcie_pmu_enable_int(struct hisi_pcie_pmu *pcie_pmu,
+				     struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 0);
+}
+
+static void hisi_pcie_pmu_disable_int(struct hisi_pcie_pmu *pcie_pmu,
+				      struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_MASK, idx, 1);
+}
+
+static void hisi_pcie_pmu_reset_counter(struct hisi_pcie_pmu *pcie_pmu,
+					struct hw_perf_event *hwc)
+{
+	u32 idx = hwc->idx;
+
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_RESET_CNT);
+	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EVENT_CTRL, idx,
+			     HISI_PCIE_DEFAULT_SET);
+}
+
+static void hisi_pcie_pmu_start(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	struct hw_perf_event_extra *hwc_ext;
+	u64 prev_cnt, prev_cnt_ext;
+
+	hwc_ext = &hwc->extra_reg;
+	if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
+		return;
+
+	WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
+	hwc->state = 0;
+
+	hisi_pcie_pmu_config_filter(event);
+	hisi_pcie_pmu_enable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_enable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_set_period(event);
+
+	if (flags & PERF_EF_RELOAD) {
+		prev_cnt = local64_read(&hwc->prev_count);
+		prev_cnt_ext = hwc_ext->config;
+		hisi_pcie_pmu_write_counter(event, prev_cnt, prev_cnt_ext);
+	}
+
+	perf_event_update_userpage(event);
+}
+
+static void hisi_pcie_pmu_stop(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_event_update(event);
+	hisi_pcie_pmu_disable_int(pcie_pmu, hwc);
+	hisi_pcie_pmu_disable_counter(pcie_pmu, hwc);
+	hisi_pcie_pmu_clear_filter(event);
+	WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED);
+	hwc->state |= PERF_HES_STOPPED;
+
+	if (hwc->state & PERF_HES_UPTODATE)
+		return;
+
+	hwc->state |= PERF_HES_UPTODATE;
+}
+
+static int hisi_pcie_pmu_add(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+	int idx;
+
+	hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+	idx = hisi_pcie_pmu_get_event_idx(pcie_pmu);
+	if (idx < 0)
+		return idx;
+
+	hwc->idx = idx;
+	pcie_pmu->hw_events[idx] = event;
+
+	/* Reset Counter to avoid interference caused by previous statistic. */
+	hisi_pcie_pmu_reset_counter(pcie_pmu, hwc);
+
+	if (flags & PERF_EF_START)
+		hisi_pcie_pmu_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+static void hisi_pcie_pmu_del(struct perf_event *event, int flags)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
+	struct hw_perf_event *hwc = &event->hw;
+
+	hisi_pcie_pmu_stop(event, PERF_EF_UPDATE);
+	pcie_pmu->hw_events[hwc->idx] = NULL;
+	perf_event_update_userpage(event);
+}
+
+static void hisi_pcie_pmu_enable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+	int num;
+
+	for (num = 0; num < HISI_PCIE_MAX_COUNTERS; num++) {
+		if (pcie_pmu->hw_events[num])
+			break;
+	}
+
+	if (num == HISI_PCIE_MAX_COUNTERS)
+		return;
+
+	writel(HISI_PCIE_GLOBAL_EN, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+static void hisi_pcie_pmu_disable(struct pmu *pmu)
+{
+	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(pmu);
+
+	writel(HISI_PCIE_GLOBAL_NONE, pcie_pmu->base + HISI_PCIE_GLOBAL_CTRL);
+}
+
+static irqreturn_t hisi_pcie_pmu_irq(int irq, void *data)
+{
+	struct hisi_pcie_pmu *pcie_pmu = data;
+	irqreturn_t ret = IRQ_NONE;
+	struct perf_event *event;
+	u32 overflown;
+	int idx;
+
+	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
+		overflown = hisi_pcie_pmu_readl(pcie_pmu, HISI_PCIE_INT_STAT,
+						idx);
+		if (!overflown)
+			continue;
+
+		/* Clear status of interrupt. */
+		hisi_pcie_pmu_writel(pcie_pmu, HISI_PCIE_INT_STAT, idx, 1);
+		event = pcie_pmu->hw_events[idx];
+		if (!event)
+			continue;
+
+		hisi_pcie_pmu_event_update(event);
+		hisi_pcie_pmu_set_period(event);
+		ret = IRQ_HANDLED;
+	}
+
+	return ret;
+}
+
+static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
+				      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int irq, ret;
+
+	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
+	if (ret < 0) {
+		pci_err(pdev, "Failed to enable MSI vectors, ret = %d!\n", ret);
+		return ret;
+	}
+
+	irq = pci_irq_vector(pdev, 0);
+	ret = request_irq(irq, hisi_pcie_pmu_irq,
+			  IRQF_NOBALANCING | IRQF_NO_THREAD, "hisi_pcie_pmu",
+			  pcie_pmu);
+	if (ret) {
+		pci_err(pdev, "Failed to register irq, ret = %d!\n", ret);
+		pci_free_irq_vectors(pdev);
+		return ret;
+	}
+
+	pcie_pmu->irq = irq;
+
+	return 0;
+}
+
+static void hisi_pcie_pmu_irq_unregister(struct pci_dev *pdev,
+					 struct hisi_pcie_pmu *pcie_pmu)
+{
+	free_irq(pcie_pmu->irq, pcie_pmu);
+	pci_free_irq_vectors(pdev);
+}
+
+static int hisi_pcie_pmu_online_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+
+	if (pcie_pmu->on_cpu == -1) {
+		pcie_pmu->on_cpu = cpu;
+		WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(cpu)));
+	}
+
+	return 0;
+}
+
+static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
+{
+	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
+					 struct hisi_pcie_pmu, node);
+	unsigned int target;
+
+	/* Nothing to do if this CPU doesn't own the PMU */
+	if (pcie_pmu->on_cpu != cpu)
+		return 0;
+
+	/* Choose a new CPU from all online cpus. */
+	target = cpumask_any_but(cpu_online_mask, cpu);
+	if (target >= nr_cpu_ids)
+		return 0;
+
+	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
+	/* Use this CPU for event counting */
+	pcie_pmu->on_cpu = target;
+	WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
+
+	return 0;
+}
+
+/*
+ * Events with the "dl" suffix in their names count performance in DL layer,
+ * otherswise, events count performance in TL layer.
+ */
+static struct attribute *hisi_pcie_pmu_events_attr[] = {
+	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
+	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
+	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
+	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
+	HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
+	HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
+	HISI_PCIE_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
+	HISI_PCIE_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
+	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
+	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_events_group = {
+	.name = "events",
+	.attrs = hisi_pcie_pmu_events_attr,
+};
+
+static struct attribute *hisi_pcie_pmu_format_attr[] = {
+	HISI_PCIE_PMU_FORMAT_ATTR(event, "config:0-7"),
+	HISI_PCIE_PMU_FORMAT_ATTR(subevent, "config:8-15"),
+	HISI_PCIE_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
+	HISI_PCIE_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
+	HISI_PCIE_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
+	HISI_PCIE_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
+	HISI_PCIE_PMU_FORMAT_ATTR(port, "config2:0-15"),
+	HISI_PCIE_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_format_group = {
+	.name = "format",
+	.attrs = hisi_pcie_pmu_format_attr,
+};
+
+static struct device_attribute hisi_pcie_pmu_bus_attr =
+	__ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
+	&hisi_pcie_pmu_bus_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
+	.attrs = hisi_pcie_pmu_bus_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_cpumask_attr =
+	__ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
+	&hisi_pcie_pmu_cpumask_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
+	.attrs = hisi_pcie_pmu_cpumask_attrs,
+};
+
+static struct device_attribute hisi_pcie_pmu_identifier_attr =
+	__ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
+
+static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
+	&hisi_pcie_pmu_identifier_attr.attr,
+	NULL
+};
+
+static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
+	.attrs = hisi_pcie_pmu_identifier_attrs,
+};
+
+static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
+	&hisi_pcie_pmu_events_group,
+	&hisi_pcie_pmu_format_group,
+	&hisi_pcie_pmu_bus_attr_group,
+	&hisi_pcie_pmu_cpumask_attr_group,
+	&hisi_pcie_pmu_identifier_attr_group,
+	NULL
+};
+
+static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
+			     struct hisi_pcie_pmu *pcie_pmu)
+{
+	u16 sicl_id, device_id;
+	char *name;
+
+	pcie_pmu->base = pci_ioremap_bar(pdev, 2);
+	if (!pcie_pmu->base) {
+		pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
+		return -ENOMEM;
+	}
+
+	hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_BDF,
+				  &pcie_pmu->bdf_min, &pcie_pmu->bdf_max);
+	hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
+				  &sicl_id);
+	name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
+			      "hisi_pcie%u_%u", sicl_id, device_id);
+	if (!name)
+		return -ENOMEM;
+
+	pcie_pmu->pdev = pdev;
+	pcie_pmu->on_cpu = -1;
+	pcie_pmu->identifier = readl(pcie_pmu->base + HISI_PCIE_REG_VERSION);
+	pcie_pmu->pmu = (struct pmu) {
+		.name		= name,
+		.module		= THIS_MODULE,
+		.event_init	= hisi_pcie_pmu_event_init,
+		.pmu_enable	= hisi_pcie_pmu_enable,
+		.pmu_disable	= hisi_pcie_pmu_disable,
+		.add		= hisi_pcie_pmu_add,
+		.del		= hisi_pcie_pmu_del,
+		.start		= hisi_pcie_pmu_start,
+		.stop		= hisi_pcie_pmu_stop,
+		.read		= hisi_pcie_pmu_read,
+		.task_ctx_nr	= perf_invalid_context,
+		.attr_groups	= hisi_pcie_pmu_attr_groups,
+		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
+	};
+
+	return 0;
+}
+
+static int hisi_pcie_init_pmu(struct pci_dev *pdev,
+			      struct hisi_pcie_pmu *pcie_pmu)
+{
+	int ret;
+
+	ret = hisi_pcie_alloc_pmu(pdev, pcie_pmu);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_pmu_irq_register(pdev, pcie_pmu);
+	if (ret)
+		goto err_set_pmu_fail;
+
+	ret = cpuhp_state_add_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				       &pcie_pmu->node);
+	if (ret) {
+		pci_err(pdev, "Failed to register hotplug, ret = %d.\n", ret);
+		goto err_irq_unregister;
+	}
+
+	ret = perf_pmu_register(&pcie_pmu->pmu, pcie_pmu->pmu.name, -1);
+	if (ret) {
+		pci_err(pdev, "Failed to register PCIe PMU, ret = %d.\n", ret);
+		goto err_hotplug_unregister;
+	}
+
+	return ret;
+
+err_hotplug_unregister:
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+
+err_irq_unregister:
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+
+err_set_pmu_fail:
+	iounmap(pcie_pmu->base);
+
+	return ret;
+}
+
+static void hisi_pcie_uninit_pmu(struct pci_dev *pdev)
+{
+	struct hisi_pcie_pmu *pcie_pmu = pci_get_drvdata(pdev);
+
+	perf_pmu_unregister(&pcie_pmu->pmu);
+	cpuhp_state_remove_instance(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				    &pcie_pmu->node);
+	irq_set_affinity_hint(pcie_pmu->irq, NULL);
+	hisi_pcie_pmu_irq_unregister(pdev, pcie_pmu);
+	iounmap(pcie_pmu->base);
+}
+
+static int hisi_pcie_init_dev(struct pci_dev *pdev)
+{
+	int ret;
+
+	ret = pci_enable_device(pdev);
+	if (ret) {
+		pci_err(pdev, "Failed to enable pci device, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
+	if (ret < 0) {
+		pci_err(pdev, "Failed to request pci mem regions, ret = %d.\n",
+			ret);
+		pci_disable_device(pdev);
+		return ret;
+	}
+
+	pci_set_master(pdev);
+
+	return 0;
+}
+
+static void hisi_pcie_uninit_dev(struct pci_dev *pdev)
+{
+	pci_clear_master(pdev);
+	pci_release_mem_regions(pdev);
+	pci_disable_device(pdev);
+}
+
+static int hisi_pcie_pmu_probe(struct pci_dev *pdev,
+			       const struct pci_device_id *id)
+{
+	struct hisi_pcie_pmu *pcie_pmu;
+	int ret;
+
+	pcie_pmu = devm_kzalloc(&pdev->dev, sizeof(*pcie_pmu), GFP_KERNEL);
+	if (!pcie_pmu)
+		return -ENOMEM;
+
+	ret = hisi_pcie_init_dev(pdev);
+	if (ret)
+		return ret;
+
+	ret = hisi_pcie_init_pmu(pdev, pcie_pmu);
+	if (ret)
+		hisi_pcie_uninit_dev(pdev);
+
+	pci_set_drvdata(pdev, pcie_pmu);
+
+	return ret;
+}
+
+static void hisi_pcie_pmu_remove(struct pci_dev *pdev)
+{
+	hisi_pcie_uninit_pmu(pdev);
+	hisi_pcie_uninit_dev(pdev);
+	pci_set_drvdata(pdev, NULL);
+}
+
+static const struct pci_device_id hisi_pcie_pmu_ids[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12d) },
+	{ 0, }
+};
+MODULE_DEVICE_TABLE(pci, hisi_pcie_pmu_ids);
+
+static struct pci_driver hisi_pcie_pmu_driver = {
+	.name = "hisi_pcie_pmu",
+	.id_table = hisi_pcie_pmu_ids,
+	.probe = hisi_pcie_pmu_probe,
+	.remove = hisi_pcie_pmu_remove,
+};
+
+static int __init hisi_pcie_module_init(void)
+{
+	int ret;
+
+	ret = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
+				      "AP_PERF_ARM_HISI_PCIE_PMU_ONLINE",
+				      hisi_pcie_pmu_online_cpu,
+				      hisi_pcie_pmu_offline_cpu);
+	if (ret) {
+		pr_err("Failed to setup PCIE PMU hotplug, ret = %d.\n", ret);
+		return ret;
+	}
+
+	ret = pci_register_driver(&hisi_pcie_pmu_driver);
+	if (ret)
+		cpuhp_remove_multi_state(
+				CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+
+	return ret;
+}
+module_init(hisi_pcie_module_init);
+
+static void __exit hisi_pcie_module_exit(void)
+{
+	pci_unregister_driver(&hisi_pcie_pmu_driver);
+	cpuhp_remove_multi_state(CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE);
+}
+module_exit(hisi_pcie_module_exit);
+
+MODULE_DESCRIPTION("HiSilicon PCIe PMU driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Qi Liu <liuqi115 at huawei.com>");
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index f14adb8..6a765cb 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -175,6 +175,7 @@ enum cpuhp_state {
 	CPUHP_AP_PERF_ARM_HISI_DDRC_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_HHA_ONLINE,
 	CPUHP_AP_PERF_ARM_HISI_L3_ONLINE,
+	CPUHP_AP_PERF_ARM_HISI_PCIE_PMU_ONLINE,
 	CPUHP_AP_PERF_ARM_L2X0_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
 	CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
-- 
2.7.4



From broonie at kernel.org  Thu Apr 15 13:49:22 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 15 Apr 2021 13:49:22 +0100
Subject: [arm64:for-next/misc 13/14] ld.lld: error: undefined symbol:
 sve_get_vl
In-Reply-To: <20210415124121.GC1015@arm.com>
References: <202104150734.PulXU4BV-lkp@intel.com>
 <20210415124121.GC1015@arm.com>
Message-ID: <20210415124922.GD5514@sirena.org.uk>

On Thu, Apr 15, 2021 at 01:41:22PM +0100, Catalin Marinas wrote:

> Thanks for the report. That indeed triggers if CONFIG_ARM64_SVE is
> disabled. Proposed fix:

Yes, I sent a patch that looks very similar earlier today.
-------------- 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/20210415/4b3a8be6/attachment.sig>

From james.clark at arm.com  Thu Apr 15 13:51:46 2021
From: james.clark at arm.com (James Clark)
Date: Thu, 15 Apr 2021 15:51:46 +0300
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210415123953.GB1011890@leoy-ThinkPad-X240s>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
 <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>
 <20210415123953.GB1011890@leoy-ThinkPad-X240s>
Message-ID: <4c173b86-b045-0514-b293-c39cc74d353d@arm.com>



On 15/04/2021 15:39, Leo Yan wrote:
> On Wed, Apr 14, 2021 at 05:41:46PM +0300, James Clark wrote:
>> Hi,
>>
>> For this change, I also tried removing the setting of PERF_SAMPLE_TIME in cs_etm__synth_events(). In theory, this would remove the sorting when opening the file, but the change doesn't affect when the built-in events are saved to the inject file. Resulting in events like MMAP and COMM with timestamps, but the synthesised events without. This results in the same issue of the synthesised events appearing before the COMM and MMAP events. If it was possible to somehow tell perf to remove timestamps from built-in events, removing PERF_SAMPLE_TIME would probably be the right solution, because we don't set sample.time.
>>
>> For Arm v8.4 we will have the kernel time in the etm timestamps, so an if can be added to switch between this behaviour and the next (more correct) one depending on the hardware. 
>>
>> On the subject of timestamps, but not related to this change, some combinations of timestamp options aren't working. For example:
>>
>>     perf record -e cs_etm/time, at tmc_etr0/u --per-thread
>> or  perf record -e cs_etm/@tmc_etr0/u --timestamp --per-thread
>>
>> These don't work because of the assumption that etm->timeless_decoding == --per-thread
>> and kernel timestamps enabled (/time/ or --timestamp) == etm timestamps enabled (/timestamp/), which isn't necessarily true.
>>
>> This can be made to work with a few code changes for cs_etm/time,timestamp/u --per-thread, but cs_etm/time/u --per-thread could be a bit more work. Changes involved would be using "per_cpu_mmaps" in some places instead of etm->timeless_decoding, and also setting etm->timeless_decoding based on whether there are any etm timestamps, not kernel ones. Although to search for any etm timestamp would involve a full decode ahead of time which might not be feasible (or maybe just checking the options, although that's not how it's done in cs_etm__is_timeless_decoding() currently).
> 
> Confirm for one thing:
> 
> For the orignal perf data file with "--per-thread" option, the decoder
> runs into the condition for "etm->timeless_decoding"; and it doesn't
> contain ETM timestamp.
> 
> Afterwards, the injected perf data file also misses ETM timestamp and
> hit the condition "etm->timeless_decoding".
> 
> So I am confusing why the original perf data can be processed properly
> but fails to handle the injected perf data file.

Hi Leo,

My patch only deals with per-cpu mode. With per-thread mode everything is already working
because _none_ of the events have timestamps because they are not enabled by default:

	/* In per-cpu case, always need the time of mmap events etc */
	if (!perf_cpu_map__empty(cpus))
		evsel__set_sample_bit(tracking_evsel, TIME);

When none of the events have timestamps, I think perf doesn't use the ordering code in
ordered-events.c. So when the inject file is opened, the events are read in file order.
In file order, MMAP and COMM events come first, because they were encountered before the
AUX record where we generated synthetic events.

So it's not really about --per-thread vs per-cpu mode, it's actually about whether
PERF_SAMPLE_TIME is set, which is set as a by-product of per-cpu mode.

I hope I understood your question properly.

James


> 
> Thanks,
> Leo
> 
>> Or, we could force /time/ and /timestamp/ options to always be enabled together in the record stage. 
>>
>>
>> Thanks
>> James
>>
>> On 14/04/2021 17:39, James Clark wrote:
>>> The following attribute is set when synthesising samples in
>>> timed decoding mode:
>>>
>>>     attr.sample_type |= PERF_SAMPLE_TIME;
>>>
>>> This results in new samples that appear to have timestamps but
>>> because we don't assign any timestamps to the samples, when the
>>> resulting inject file is opened again, the synthesised samples
>>> will be on the wrong side of the MMAP or COMM events.
>>>
>>> For example this results in the samples being associated with
>>> the perf binary, rather than the target of the record:
>>>
>>>     perf record -e cs_etm/@tmc_etr0/u top
>>>     perf inject -i perf.data -o perf.inject --itrace=i100il
>>>     perf report -i perf.inject
>>>
>>> Where 'Command' == perf should show as 'top':
>>>
>>>     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>>>     # ........  .......  ....................  ......................  ......................  ..................
>>>     #
>>>         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
>>>
>>> If the perf.data file is opened directly with perf, without the
>>> inject step, then this already works correctly because the
>>> events are synthesised after the COMM and MMAP events and
>>> no second sorting happens. Re-sorting only happens when opening
>>> the perf.inject file for the second time so timestamps are
>>> needed.
>>>
>>> Using the timestamp from the AUX record mirrors the current
>>> behaviour when opening directly with perf, because the events
>>> are generated on the call to cs_etm__process_queues().
>>>
>>> Signed-off-by: James Clark <james.clark at arm.com>
>>> Co-developed-by: Al Grant <al.grant at arm.com>
>>> Signed-off-by: Al Grant <al.grant at arm.com>
>>> ---
>>>  tools/perf/util/cs-etm.c | 10 ++++++++--
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>>> index c25da2ffa8f3..d0fa9dce47f1 100644
>>> --- a/tools/perf/util/cs-etm.c
>>> +++ b/tools/perf/util/cs-etm.c
>>> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>>>  	u8 sample_instructions;
>>>  
>>>  	int num_cpu;
>>> +	u64 latest_kernel_timestamp;
>>>  	u32 auxtrace_type;
>>>  	u64 branches_sample_type;
>>>  	u64 branches_id;
>>> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>>>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>>>  	event->sample.header.size = sizeof(struct perf_event_header);
>>>  
>>> +	if (!etm->timeless_decoding)
>>> +		sample.time = etm->latest_kernel_timestamp;
>>>  	sample.ip = addr;
>>>  	sample.pid = tidq->pid;
>>>  	sample.tid = tidq->tid;
>>> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>>>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>>>  	event->sample.header.size = sizeof(struct perf_event_header);
>>>  
>>> +	if (!etm->timeless_decoding)
>>> +		sample.time = etm->latest_kernel_timestamp;
>>>  	sample.ip = ip;
>>>  	sample.pid = tidq->pid;
>>>  	sample.tid = tidq->tid;
>>> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>>>  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>>>  		return cs_etm__process_switch_cpu_wide(etm, event);
>>>  
>>> -	if (!etm->timeless_decoding &&
>>> -	    event->header.type == PERF_RECORD_AUX)
>>> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
>>> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
>>>  		return cs_etm__process_queues(etm);
>>> +	}
>>>  
>>>  	return 0;
>>>  }
>>>


From catalin.marinas at arm.com  Thu Apr 15 13:52:52 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 13:52:52 +0100
Subject: [arm64:for-next/misc 13/14] ld.lld: error: undefined symbol:
 sve_get_vl
In-Reply-To: <20210415124922.GD5514@sirena.org.uk>
References: <202104150734.PulXU4BV-lkp@intel.com>
 <20210415124121.GC1015@arm.com>
 <20210415124922.GD5514@sirena.org.uk>
Message-ID: <20210415125251.GD1015@arm.com>

On Thu, Apr 15, 2021 at 01:49:22PM +0100, Mark Brown wrote:
> On Thu, Apr 15, 2021 at 01:41:22PM +0100, Catalin Marinas wrote:
> 
> > Thanks for the report. That indeed triggers if CONFIG_ARM64_SVE is
> > disabled. Proposed fix:
> 
> Yes, I sent a patch that looks very similar earlier today.

Ah, haven't got there yet. I'll apply yours. Thanks.

-- 
Catalin


From ulf.hansson at linaro.org  Thu Apr 15 14:01:56 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 15 Apr 2021 15:01:56 +0200
Subject: [RFC PATCH v3 5/8] cpuidle: Factor-out power domain related code
 from PSCI domain driver
In-Reply-To: <20210318130512.1025416-6-anup.patel@wdc.com>
References: <20210318130512.1025416-1-anup.patel@wdc.com>
 <20210318130512.1025416-6-anup.patel@wdc.com>
Message-ID: <CAPDyKFq3JLqFabmay25e6JGX+UD-=yEPRykgYBadFo3y3sGbOw@mail.gmail.com>

Hi Anup,

First, my apologies for the very long delay.

On Thu, 18 Mar 2021 at 14:06, Anup Patel <anup.patel at wdc.com> wrote:
>
> The generic power domain related code in PSCI domain driver is largely
> independent of PSCI and can be shared with RISC-V SBI domain driver
> hence we factor-out this code into dt_idle_genpd.c and dt_idle_genpd.h.

I do agree that some parts could be considered as independent of PSCI,
perhaps those are rather "cpuidle-dt" specific.

Although, while I was looking at the changes in $subject patch, it
looks like you are adding another layer on top of
genpd/cpuidle-psci-domain. For example, you add the struct
dt_idle_genpd_ops with a couple of new callbacks. Even if this might
reduce open-coding a bit, I think it also introduces complexity. In my
opinion, those changes aren't really worth it.

Perhaps you can find some smaller pieces of code that are really
independent, which can be shared!?

>
> Signed-off-by: Anup Patel <anup.patel at wdc.com>

Kind regards
Uffe

> ---
>  drivers/cpuidle/Kconfig                       |   4 +
>  drivers/cpuidle/Kconfig.arm                   |   1 +
>  drivers/cpuidle/Makefile                      |   1 +
>  drivers/cpuidle/cpuidle-psci-domain.c         | 244 +-----------------
>  drivers/cpuidle/cpuidle-psci.h                |  15 +-
>  ...{cpuidle-psci-domain.c => dt_idle_genpd.c} | 165 ++++--------
>  drivers/cpuidle/dt_idle_genpd.h               |  42 +++
>  7 files changed, 121 insertions(+), 351 deletions(-)
>  copy drivers/cpuidle/{cpuidle-psci-domain.c => dt_idle_genpd.c} (52%)
>  create mode 100644 drivers/cpuidle/dt_idle_genpd.h
>
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index c0aeedd66f02..f1afe7ab6b54 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -47,6 +47,10 @@ config CPU_IDLE_GOV_HALTPOLL
>  config DT_IDLE_STATES
>         bool
>
> +config DT_IDLE_GENPD
> +       depends on PM_GENERIC_DOMAINS_OF
> +       bool
> +
>  menu "ARM CPU Idle Drivers"
>  depends on ARM || ARM64
>  source "drivers/cpuidle/Kconfig.arm"
> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
> index 0844fadc4be8..1007435ae298 100644
> --- a/drivers/cpuidle/Kconfig.arm
> +++ b/drivers/cpuidle/Kconfig.arm
> @@ -27,6 +27,7 @@ config ARM_PSCI_CPUIDLE_DOMAIN
>         bool "PSCI CPU idle Domain"
>         depends on ARM_PSCI_CPUIDLE
>         depends on PM_GENERIC_DOMAINS_OF
> +       select DT_IDLE_GENPD
>         default y
>         help
>           Select this to enable the PSCI based CPUidle driver to use PM domains,
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 26bbc5e74123..11a26cef279f 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -6,6 +6,7 @@
>  obj-y += cpuidle.o driver.o governor.o sysfs.o governors/
>  obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  obj-$(CONFIG_DT_IDLE_STATES)             += dt_idle_states.o
> +obj-$(CONFIG_DT_IDLE_GENPD)              += dt_idle_genpd.o
>  obj-$(CONFIG_ARCH_HAS_CPU_RELAX)         += poll_state.o
>  obj-$(CONFIG_HALTPOLL_CPUIDLE)           += cpuidle-haltpoll.o
>
> diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/cpuidle-psci-domain.c
> index ff2c3f8e4668..b0621d890ab7 100644
> --- a/drivers/cpuidle/cpuidle-psci-domain.c
> +++ b/drivers/cpuidle/cpuidle-psci-domain.c
> @@ -16,17 +16,9 @@
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/psci.h>
> -#include <linux/slab.h>
> -#include <linux/string.h>
>
>  #include "cpuidle-psci.h"
>
> -struct psci_pd_provider {
> -       struct list_head link;
> -       struct device_node *node;
> -};
> -
> -static LIST_HEAD(psci_pd_providers);
>  static bool psci_pd_allow_domain_state;
>
>  static int psci_pd_power_off(struct generic_pm_domain *pd)
> @@ -47,178 +39,6 @@ static int psci_pd_power_off(struct generic_pm_domain *pd)
>         return 0;
>  }
>
> -static int psci_pd_parse_state_nodes(struct genpd_power_state *states,
> -                                    int state_count)
> -{
> -       int i, ret;
> -       u32 psci_state, *psci_state_buf;
> -
> -       for (i = 0; i < state_count; i++) {
> -               ret = psci_dt_parse_state_node(to_of_node(states[i].fwnode),
> -                                       &psci_state);
> -               if (ret)
> -                       goto free_state;
> -
> -               psci_state_buf = kmalloc(sizeof(u32), GFP_KERNEL);
> -               if (!psci_state_buf) {
> -                       ret = -ENOMEM;
> -                       goto free_state;
> -               }
> -               *psci_state_buf = psci_state;
> -               states[i].data = psci_state_buf;
> -       }
> -
> -       return 0;
> -
> -free_state:
> -       i--;
> -       for (; i >= 0; i--)
> -               kfree(states[i].data);
> -       return ret;
> -}
> -
> -static int psci_pd_parse_states(struct device_node *np,
> -                       struct genpd_power_state **states, int *state_count)
> -{
> -       int ret;
> -
> -       /* Parse the domain idle states. */
> -       ret = of_genpd_parse_idle_states(np, states, state_count);
> -       if (ret)
> -               return ret;
> -
> -       /* Fill out the PSCI specifics for each found state. */
> -       ret = psci_pd_parse_state_nodes(*states, *state_count);
> -       if (ret)
> -               kfree(*states);
> -
> -       return ret;
> -}
> -
> -static void psci_pd_free_states(struct genpd_power_state *states,
> -                               unsigned int state_count)
> -{
> -       int i;
> -
> -       for (i = 0; i < state_count; i++)
> -               kfree(states[i].data);
> -       kfree(states);
> -}
> -
> -static int psci_pd_init(struct device_node *np, bool use_osi)
> -{
> -       struct generic_pm_domain *pd;
> -       struct psci_pd_provider *pd_provider;
> -       struct dev_power_governor *pd_gov;
> -       struct genpd_power_state *states = NULL;
> -       int ret = -ENOMEM, state_count = 0;
> -
> -       pd = kzalloc(sizeof(*pd), GFP_KERNEL);
> -       if (!pd)
> -               goto out;
> -
> -       pd_provider = kzalloc(sizeof(*pd_provider), GFP_KERNEL);
> -       if (!pd_provider)
> -               goto free_pd;
> -
> -       pd->name = kasprintf(GFP_KERNEL, "%pOF", np);
> -       if (!pd->name)
> -               goto free_pd_prov;
> -
> -       /*
> -        * Parse the domain idle states and let genpd manage the state selection
> -        * for those being compatible with "domain-idle-state".
> -        */
> -       ret = psci_pd_parse_states(np, &states, &state_count);
> -       if (ret)
> -               goto free_name;
> -
> -       pd->free_states = psci_pd_free_states;
> -       pd->name = kbasename(pd->name);
> -       pd->states = states;
> -       pd->state_count = state_count;
> -       pd->flags |= GENPD_FLAG_IRQ_SAFE | GENPD_FLAG_CPU_DOMAIN;
> -
> -       /* Allow power off when OSI has been successfully enabled. */
> -       if (use_osi)
> -               pd->power_off = psci_pd_power_off;
> -       else
> -               pd->flags |= GENPD_FLAG_ALWAYS_ON;
> -
> -       /* Use governor for CPU PM domains if it has some states to manage. */
> -       pd_gov = state_count > 0 ? &pm_domain_cpu_gov : NULL;
> -
> -       ret = pm_genpd_init(pd, pd_gov, false);
> -       if (ret) {
> -               psci_pd_free_states(states, state_count);
> -               goto free_name;
> -       }
> -
> -       ret = of_genpd_add_provider_simple(np, pd);
> -       if (ret)
> -               goto remove_pd;
> -
> -       pd_provider->node = of_node_get(np);
> -       list_add(&pd_provider->link, &psci_pd_providers);
> -
> -       pr_debug("init PM domain %s\n", pd->name);
> -       return 0;
> -
> -remove_pd:
> -       pm_genpd_remove(pd);
> -free_name:
> -       kfree(pd->name);
> -free_pd_prov:
> -       kfree(pd_provider);
> -free_pd:
> -       kfree(pd);
> -out:
> -       pr_err("failed to init PM domain ret=%d %pOF\n", ret, np);
> -       return ret;
> -}
> -
> -static void psci_pd_remove(void)
> -{
> -       struct psci_pd_provider *pd_provider, *it;
> -       struct generic_pm_domain *genpd;
> -
> -       list_for_each_entry_safe(pd_provider, it, &psci_pd_providers, link) {
> -               of_genpd_del_provider(pd_provider->node);
> -
> -               genpd = of_genpd_remove_last(pd_provider->node);
> -               if (!IS_ERR(genpd))
> -                       kfree(genpd);
> -
> -               of_node_put(pd_provider->node);
> -               list_del(&pd_provider->link);
> -               kfree(pd_provider);
> -       }
> -}
> -
> -static int psci_pd_init_topology(struct device_node *np)
> -{
> -       struct device_node *node;
> -       struct of_phandle_args child, parent;
> -       int ret;
> -
> -       for_each_child_of_node(np, node) {
> -               if (of_parse_phandle_with_args(node, "power-domains",
> -                                       "#power-domain-cells", 0, &parent))
> -                       continue;
> -
> -               child.np = node;
> -               child.args_count = 0;
> -               ret = of_genpd_add_subdomain(&parent, &child);
> -               of_node_put(parent.np);
> -               if (ret) {
> -                       of_node_put(node);
> -                       return ret;
> -               }
> -       }
> -
> -       return 0;
> -}
> -
>  static bool psci_pd_try_set_osi_mode(void)
>  {
>         int ret;
> @@ -244,6 +64,10 @@ static void psci_cpuidle_domain_sync_state(struct device *dev)
>         psci_pd_allow_domain_state = true;
>  }
>
> +static struct dt_idle_genpd_ops psci_genpd_ops = {
> +       .parse_state_node = psci_dt_parse_state_node,
> +};
> +
>  static const struct of_device_id psci_of_match[] = {
>         { .compatible = "arm,psci-1.0" },
>         {}
> @@ -252,48 +76,25 @@ static const struct of_device_id psci_of_match[] = {
>  static int psci_cpuidle_domain_probe(struct platform_device *pdev)
>  {
>         struct device_node *np = pdev->dev.of_node;
> -       struct device_node *node;
>         bool use_osi;
> -       int ret = 0, pd_count = 0;
> +       int ret = 0;
>
>         if (!np)
>                 return -ENODEV;
>
>         /* If OSI mode is supported, let's try to enable it. */
>         use_osi = psci_pd_try_set_osi_mode();
> +       if (use_osi)
> +               psci_genpd_ops.power_off = psci_pd_power_off;
>
> -       /*
> -        * Parse child nodes for the "#power-domain-cells" property and
> -        * initialize a genpd/genpd-of-provider pair when it's found.
> -        */
> -       for_each_child_of_node(np, node) {
> -               if (!of_find_property(node, "#power-domain-cells", NULL))
> -                       continue;
> -
> -               ret = psci_pd_init(node, use_osi);
> -               if (ret)
> -                       goto put_node;
> -
> -               pd_count++;
> -       }
> -
> -       /* Bail out if not using the hierarchical CPU topology. */
> -       if (!pd_count)
> -               goto no_pd;
> -
> -       /* Link genpd masters/subdomains to model the CPU topology. */
> -       ret = psci_pd_init_topology(np);
> +       /* Generic power domain probing based on DT node. */
> +       ret = dt_idle_genpd_probe(&psci_genpd_ops, np);
>         if (ret)
> -               goto remove_pd;
> +               goto no_pd;
>
>         pr_info("Initialized CPU PM domain topology\n");
>         return 0;
>
> -put_node:
> -       of_node_put(node);
> -remove_pd:
> -       psci_pd_remove();
> -       pr_err("failed to create CPU PM domains ret=%d\n", ret);
>  no_pd:
>         if (use_osi)
>                 psci_set_osi_mode(false);
> @@ -314,28 +115,3 @@ static int __init psci_idle_init_domains(void)
>         return platform_driver_register(&psci_cpuidle_domain_driver);
>  }
>  subsys_initcall(psci_idle_init_domains);
> -
> -struct device *psci_dt_attach_cpu(int cpu)
> -{
> -       struct device *dev;
> -
> -       dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), "psci");
> -       if (IS_ERR_OR_NULL(dev))
> -               return dev;
> -
> -       pm_runtime_irq_safe(dev);
> -       if (cpu_online(cpu))
> -               pm_runtime_get_sync(dev);
> -
> -       dev_pm_syscore_device(dev, true);
> -
> -       return dev;
> -}
> -
> -void psci_dt_detach_cpu(struct device *dev)
> -{
> -       if (IS_ERR_OR_NULL(dev))
> -               return;
> -
> -       dev_pm_domain_detach(dev, false);
> -}
> diff --git a/drivers/cpuidle/cpuidle-psci.h b/drivers/cpuidle/cpuidle-psci.h
> index d8e925e84c27..70de1e3c00af 100644
> --- a/drivers/cpuidle/cpuidle-psci.h
> +++ b/drivers/cpuidle/cpuidle-psci.h
> @@ -10,8 +10,19 @@ void psci_set_domain_state(u32 state);
>  int psci_dt_parse_state_node(struct device_node *np, u32 *state);
>
>  #ifdef CONFIG_ARM_PSCI_CPUIDLE_DOMAIN
> -struct device *psci_dt_attach_cpu(int cpu);
> -void psci_dt_detach_cpu(struct device *dev);
> +
> +#include "dt_idle_genpd.h"
> +
> +static inline struct device *psci_dt_attach_cpu(int cpu)
> +{
> +       return dt_idle_genpd_attach_cpu(cpu, "psci");
> +}
> +
> +static inline void psci_dt_detach_cpu(struct device *dev)
> +{
> +       dt_idle_genpd_detach_cpu(dev);
> +}
> +
>  #else
>  static inline struct device *psci_dt_attach_cpu(int cpu) { return NULL; }
>  static inline void psci_dt_detach_cpu(struct device *dev) { }
> diff --git a/drivers/cpuidle/cpuidle-psci-domain.c b/drivers/cpuidle/dt_idle_genpd.c
> similarity index 52%
> copy from drivers/cpuidle/cpuidle-psci-domain.c
> copy to drivers/cpuidle/dt_idle_genpd.c
> index ff2c3f8e4668..805c4c81d60f 100644
> --- a/drivers/cpuidle/cpuidle-psci-domain.c
> +++ b/drivers/cpuidle/dt_idle_genpd.c
> @@ -1,71 +1,52 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0-only
>  /*
> - * PM domains for CPUs via genpd - managed by cpuidle-psci.
> + * PM domains for CPUs via genpd.
>   *
>   * Copyright (C) 2019 Linaro Ltd.
>   * Author: Ulf Hansson <ulf.hansson at linaro.org>
>   *
> + * Copyright (c) 2021 Western Digital Corporation or its affiliates.
>   */
>
> -#define pr_fmt(fmt) "CPUidle PSCI: " fmt
> +#define pr_fmt(fmt) "dt-idle-genpd: " fmt
>
>  #include <linux/cpu.h>
>  #include <linux/device.h>
>  #include <linux/kernel.h>
> -#include <linux/platform_device.h>
>  #include <linux/pm_domain.h>
>  #include <linux/pm_runtime.h>
> -#include <linux/psci.h>
>  #include <linux/slab.h>
>  #include <linux/string.h>
>
> -#include "cpuidle-psci.h"
> +#include "dt_idle_genpd.h"
>
> -struct psci_pd_provider {
> +struct dt_pd_provider {
>         struct list_head link;
>         struct device_node *node;
>  };
>
> -static LIST_HEAD(psci_pd_providers);
> -static bool psci_pd_allow_domain_state;
> +static LIST_HEAD(dt_pd_providers);
>
> -static int psci_pd_power_off(struct generic_pm_domain *pd)
> -{
> -       struct genpd_power_state *state = &pd->states[pd->state_idx];
> -       u32 *pd_state;
> -
> -       if (!state->data)
> -               return 0;
> -
> -       if (!psci_pd_allow_domain_state)
> -               return -EBUSY;
> -
> -       /* OSI mode is enabled, set the corresponding domain state. */
> -       pd_state = state->data;
> -       psci_set_domain_state(*pd_state);
> -
> -       return 0;
> -}
> -
> -static int psci_pd_parse_state_nodes(struct genpd_power_state *states,
> -                                    int state_count)
> +static int dt_pd_parse_state_nodes(const struct dt_idle_genpd_ops *ops,
> +                                  struct genpd_power_state *states,
> +                                  int state_count)
>  {
>         int i, ret;
> -       u32 psci_state, *psci_state_buf;
> +       u32 state, *state_buf;
>
>         for (i = 0; i < state_count; i++) {
> -               ret = psci_dt_parse_state_node(to_of_node(states[i].fwnode),
> -                                       &psci_state);
> +               ret = ops->parse_state_node(to_of_node(states[i].fwnode),
> +                                           &state);
>                 if (ret)
>                         goto free_state;
>
> -               psci_state_buf = kmalloc(sizeof(u32), GFP_KERNEL);
> -               if (!psci_state_buf) {
> +               state_buf = kmalloc(sizeof(u32), GFP_KERNEL);
> +               if (!state_buf) {
>                         ret = -ENOMEM;
>                         goto free_state;
>                 }
> -               *psci_state_buf = psci_state;
> -               states[i].data = psci_state_buf;
> +               *state_buf = state;
> +               states[i].data = state_buf;
>         }
>
>         return 0;
> @@ -77,8 +58,10 @@ static int psci_pd_parse_state_nodes(struct genpd_power_state *states,
>         return ret;
>  }
>
> -static int psci_pd_parse_states(struct device_node *np,
> -                       struct genpd_power_state **states, int *state_count)
> +static int dt_pd_parse_states(const struct dt_idle_genpd_ops *ops,
> +                             struct device_node *np,
> +                             struct genpd_power_state **states,
> +                             int *state_count)
>  {
>         int ret;
>
> @@ -87,15 +70,15 @@ static int psci_pd_parse_states(struct device_node *np,
>         if (ret)
>                 return ret;
>
> -       /* Fill out the PSCI specifics for each found state. */
> -       ret = psci_pd_parse_state_nodes(*states, *state_count);
> +       /* Fill out the dt specifics for each found state. */
> +       ret = dt_pd_parse_state_nodes(ops, *states, *state_count);
>         if (ret)
>                 kfree(*states);
>
>         return ret;
>  }
>
> -static void psci_pd_free_states(struct genpd_power_state *states,
> +static void dt_pd_free_states(struct genpd_power_state *states,
>                                 unsigned int state_count)
>  {
>         int i;
> @@ -105,10 +88,11 @@ static void psci_pd_free_states(struct genpd_power_state *states,
>         kfree(states);
>  }
>
> -static int psci_pd_init(struct device_node *np, bool use_osi)
> +static int dt_pd_init(const struct dt_idle_genpd_ops *ops,
> +                     struct device_node *np)
>  {
>         struct generic_pm_domain *pd;
> -       struct psci_pd_provider *pd_provider;
> +       struct dt_pd_provider *pd_provider;
>         struct dev_power_governor *pd_gov;
>         struct genpd_power_state *states = NULL;
>         int ret = -ENOMEM, state_count = 0;
> @@ -129,19 +113,19 @@ static int psci_pd_init(struct device_node *np, bool use_osi)
>          * Parse the domain idle states and let genpd manage the state selection
>          * for those being compatible with "domain-idle-state".
>          */
> -       ret = psci_pd_parse_states(np, &states, &state_count);
> +       ret = dt_pd_parse_states(ops, np, &states, &state_count);
>         if (ret)
>                 goto free_name;
>
> -       pd->free_states = psci_pd_free_states;
> +       pd->free_states = dt_pd_free_states;
>         pd->name = kbasename(pd->name);
>         pd->states = states;
>         pd->state_count = state_count;
>         pd->flags |= GENPD_FLAG_IRQ_SAFE | GENPD_FLAG_CPU_DOMAIN;
>
> -       /* Allow power off when OSI has been successfully enabled. */
> -       if (use_osi)
> -               pd->power_off = psci_pd_power_off;
> +       /* Allow power off when available. */
> +       if (ops->power_off)
> +               pd->power_off = ops->power_off;
>         else
>                 pd->flags |= GENPD_FLAG_ALWAYS_ON;
>
> @@ -150,7 +134,7 @@ static int psci_pd_init(struct device_node *np, bool use_osi)
>
>         ret = pm_genpd_init(pd, pd_gov, false);
>         if (ret) {
> -               psci_pd_free_states(states, state_count);
> +               dt_pd_free_states(states, state_count);
>                 goto free_name;
>         }
>
> @@ -159,7 +143,7 @@ static int psci_pd_init(struct device_node *np, bool use_osi)
>                 goto remove_pd;
>
>         pd_provider->node = of_node_get(np);
> -       list_add(&pd_provider->link, &psci_pd_providers);
> +       list_add(&pd_provider->link, &dt_pd_providers);
>
>         pr_debug("init PM domain %s\n", pd->name);
>         return 0;
> @@ -177,12 +161,12 @@ static int psci_pd_init(struct device_node *np, bool use_osi)
>         return ret;
>  }
>
> -static void psci_pd_remove(void)
> +static void dt_pd_remove(void)
>  {
> -       struct psci_pd_provider *pd_provider, *it;
> +       struct dt_pd_provider *pd_provider, *it;
>         struct generic_pm_domain *genpd;
>
> -       list_for_each_entry_safe(pd_provider, it, &psci_pd_providers, link) {
> +       list_for_each_entry_safe(pd_provider, it, &dt_pd_providers, link) {
>                 of_genpd_del_provider(pd_provider->node);
>
>                 genpd = of_genpd_remove_last(pd_provider->node);
> @@ -195,7 +179,7 @@ static void psci_pd_remove(void)
>         }
>  }
>
> -static int psci_pd_init_topology(struct device_node *np)
> +static int dt_pd_init_topology(struct device_node *np)
>  {
>         struct device_node *node;
>         struct of_phandle_args child, parent;
> @@ -219,49 +203,15 @@ static int psci_pd_init_topology(struct device_node *np)
>         return 0;
>  }
>
> -static bool psci_pd_try_set_osi_mode(void)
> -{
> -       int ret;
> -
> -       if (!psci_has_osi_support())
> -               return false;
> -
> -       ret = psci_set_osi_mode(true);
> -       if (ret) {
> -               pr_warn("failed to enable OSI mode: %d\n", ret);
> -               return false;
> -       }
> -
> -       return true;
> -}
> -
> -static void psci_cpuidle_domain_sync_state(struct device *dev)
> +int dt_idle_genpd_probe(const struct dt_idle_genpd_ops *ops,
> +                       struct device_node *np)
>  {
> -       /*
> -        * All devices have now been attached/probed to the PM domain topology,
> -        * hence it's fine to allow domain states to be picked.
> -        */
> -       psci_pd_allow_domain_state = true;
> -}
> -
> -static const struct of_device_id psci_of_match[] = {
> -       { .compatible = "arm,psci-1.0" },
> -       {}
> -};
> -
> -static int psci_cpuidle_domain_probe(struct platform_device *pdev)
> -{
> -       struct device_node *np = pdev->dev.of_node;
>         struct device_node *node;
> -       bool use_osi;
>         int ret = 0, pd_count = 0;
>
> -       if (!np)
> +       if (!np || !ops || !ops->parse_state_node)
>                 return -ENODEV;
>
> -       /* If OSI mode is supported, let's try to enable it. */
> -       use_osi = psci_pd_try_set_osi_mode();
> -
>         /*
>          * Parse child nodes for the "#power-domain-cells" property and
>          * initialize a genpd/genpd-of-provider pair when it's found.
> @@ -270,7 +220,7 @@ static int psci_cpuidle_domain_probe(struct platform_device *pdev)
>                 if (!of_find_property(node, "#power-domain-cells", NULL))
>                         continue;
>
> -               ret = psci_pd_init(node, use_osi);
> +               ret = dt_pd_init(ops, node);
>                 if (ret)
>                         goto put_node;
>
> @@ -282,44 +232,27 @@ static int psci_cpuidle_domain_probe(struct platform_device *pdev)
>                 goto no_pd;
>
>         /* Link genpd masters/subdomains to model the CPU topology. */
> -       ret = psci_pd_init_topology(np);
> +       ret = dt_pd_init_topology(np);
>         if (ret)
>                 goto remove_pd;
>
> -       pr_info("Initialized CPU PM domain topology\n");
>         return 0;
>
>  put_node:
>         of_node_put(node);
>  remove_pd:
> -       psci_pd_remove();
> +       dt_pd_remove();
>         pr_err("failed to create CPU PM domains ret=%d\n", ret);
>  no_pd:
> -       if (use_osi)
> -               psci_set_osi_mode(false);
>         return ret;
>  }
> +EXPORT_SYMBOL_GPL(dt_idle_genpd_probe);
>
> -static struct platform_driver psci_cpuidle_domain_driver = {
> -       .probe  = psci_cpuidle_domain_probe,
> -       .driver = {
> -               .name = "psci-cpuidle-domain",
> -               .of_match_table = psci_of_match,
> -               .sync_state = psci_cpuidle_domain_sync_state,
> -       },
> -};
> -
> -static int __init psci_idle_init_domains(void)
> -{
> -       return platform_driver_register(&psci_cpuidle_domain_driver);
> -}
> -subsys_initcall(psci_idle_init_domains);
> -
> -struct device *psci_dt_attach_cpu(int cpu)
> +struct device *dt_idle_genpd_attach_cpu(int cpu, const char *name)
>  {
>         struct device *dev;
>
> -       dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), "psci");
> +       dev = dev_pm_domain_attach_by_name(get_cpu_device(cpu), name);
>         if (IS_ERR_OR_NULL(dev))
>                 return dev;
>
> @@ -331,11 +264,13 @@ struct device *psci_dt_attach_cpu(int cpu)
>
>         return dev;
>  }
> +EXPORT_SYMBOL_GPL(dt_idle_genpd_attach_cpu);
>
> -void psci_dt_detach_cpu(struct device *dev)
> +void dt_idle_genpd_detach_cpu(struct device *dev)
>  {
>         if (IS_ERR_OR_NULL(dev))
>                 return;
>
>         dev_pm_domain_detach(dev, false);
>  }
> +EXPORT_SYMBOL_GPL(dt_idle_genpd_detach_cpu);
> diff --git a/drivers/cpuidle/dt_idle_genpd.h b/drivers/cpuidle/dt_idle_genpd.h
> new file mode 100644
> index 000000000000..a3d3d2e85871
> --- /dev/null
> +++ b/drivers/cpuidle/dt_idle_genpd.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __DT_IDLE_GENPD
> +#define __DT_IDLE_GENPD
> +
> +struct device_node;
> +struct generic_pm_domain;
> +
> +struct dt_idle_genpd_ops {
> +       int (*parse_state_node)(struct device_node *np, u32 *state);
> +       int (*power_off)(struct generic_pm_domain *pd);
> +};
> +
> +#ifdef CONFIG_DT_IDLE_GENPD
> +
> +int dt_idle_genpd_probe(const struct dt_idle_genpd_ops *ops,
> +                       struct device_node *np);
> +
> +struct device *dt_idle_genpd_attach_cpu(int cpu, const char *name);
> +
> +void dt_idle_genpd_detach_cpu(struct device *dev);
> +
> +#else
> +
> +int dt_idle_genpd_probe(const struct dt_idle_genpd_ops *ops,
> +                       struct device_node *np)
> +{
> +       return 0;
> +}
> +
> +static inline struct device *dt_idle_genpd_attach_cpu(int cpu,
> +                                                     const char *name)
> +{
> +       return NULL;
> +}
> +
> +static inline void dt_idle_genpd_detach_cpu(struct device *dev)
> +{
> +}
> +
> +#endif
> +
> +#endif
> --
> 2.25.1
>


From catalin.marinas at arm.com  Thu Apr 15 14:06:14 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 14:06:14 +0100
Subject: [PATCH] arm64/sve: Add compile time checks for SVE hooks in
 generic functions
In-Reply-To: <20210415121742.36628-1-broonie@kernel.org>
References: <20210415121742.36628-1-broonie@kernel.org>
Message-ID: <161849196747.25627.994983825884748297.b4-ty@arm.com>

On Thu, 15 Apr 2021 13:17:42 +0100, Mark Brown wrote:
> The FPSIMD code was relying on IS_ENABLED() checks in system_suppors_sve()
> to cause the compiler to delete references to SVE functions in some places,
> add explicit IS_ENABLED() checks back.

Applied to arm64 (for-next/misc), thanks!

[1/1] arm64/sve: Add compile time checks for SVE hooks in generic functions
      https://git.kernel.org/arm64/c/087dfa5ca7d8

-- 
Catalin



From o.rempel at pengutronix.de  Thu Apr 15 14:07:34 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:34 +0200
Subject: [PATCH v2 3/7] net: phy: at803x: AR8085 & AR9331: add loopback support
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-4-o.rempel@pengutronix.de>

PHY loopback is needed for the ethernet controller self test support.
This PHY was tested with the generic net sefltest in combination with
FEC ethernet controller and AR9331 switch.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/phy/at803x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index d7799beb811c..f74f427a8da5 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -1128,6 +1128,7 @@ static struct phy_driver at803x_driver[] = {
 	.get_wol		= at803x_get_wol,
 	.suspend		= at803x_suspend,
 	.resume			= at803x_resume,
+	.set_loopback		= genphy_loopback,
 	/* PHY_GBIT_FEATURES */
 	.read_status		= at803x_read_status,
 	.config_intr		= at803x_config_intr,
@@ -1207,6 +1208,7 @@ static struct phy_driver at803x_driver[] = {
 	.read_status		= at803x_read_status,
 	.soft_reset		= genphy_soft_reset,
 	.config_aneg		= at803x_config_aneg,
+	.set_loopback		= genphy_loopback,
 } };
 
 module_phy_driver(at803x_driver);
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:33 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:33 +0200
Subject: [PATCH v2 2/7] net: phy: micrel: KSZ8081 & KSZ9031: add loopback
 support
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-3-o.rempel@pengutronix.de>

PHY loopback is needed for the ethernet controller self test support.
This PHY was tested with the generic net sefltest in combination with
FEC ethernet controller and SJA1105 switch.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/phy/micrel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index a14a00328fa3..26066b1e02e5 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1311,6 +1311,7 @@ static struct phy_driver ksphy_driver[] = {
 	.get_stats	= kszphy_get_stats,
 	.suspend	= kszphy_suspend,
 	.resume		= kszphy_resume,
+	.set_loopback	= genphy_loopback,
 }, {
 	.phy_id		= PHY_ID_KSZ8061,
 	.name		= "Micrel KSZ8061",
@@ -1356,6 +1357,7 @@ static struct phy_driver ksphy_driver[] = {
 	.get_stats	= kszphy_get_stats,
 	.suspend	= genphy_suspend,
 	.resume		= kszphy_resume,
+	.set_loopback	= genphy_loopback,
 }, {
 	.phy_id		= PHY_ID_LAN8814,
 	.phy_id_mask	= MICREL_PHY_ID_MASK,
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:35 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:35 +0200
Subject: [PATCH v2 4/7] net: add generic selftest support
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-5-o.rempel@pengutronix.de>

Port some parts of the stmmac selftest and reuse it as basic generic selftest
library. This patch was tested with following combinations:
- iMX6DL FEC -> AT8035
- iMX6DL FEC -> SJA1105Q switch -> KSZ8081
- iMX6DL FEC -> SJA1105Q switch -> KSZ9031
- AR9331 ag71xx -> AR9331 PHY
- AR9331 ag71xx -> AR9331 switch -> AR9331 PHY

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 include/net/selftests.h |  12 ++
 net/Kconfig             |   4 +
 net/core/Makefile       |   1 +
 net/core/selftests.c    | 366 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 383 insertions(+)
 create mode 100644 include/net/selftests.h
 create mode 100644 net/core/selftests.c

diff --git a/include/net/selftests.h b/include/net/selftests.h
new file mode 100644
index 000000000000..9993b9498cf3
--- /dev/null
+++ b/include/net/selftests.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _NET_SELFTESTS
+#define _NET_SELFTESTS
+
+#include <linux/ethtool.h>
+
+void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
+		  u64 *buf);
+int net_selftest_get_count(void);
+void net_selftest_get_strings(u8 *data);
+
+#endif /* _NET_SELFTESTS */
diff --git a/net/Kconfig b/net/Kconfig
index 9c456acc379e..6e1285c8340e 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -429,6 +429,10 @@ config GRO_CELLS
 config SOCK_VALIDATE_XMIT
 	bool
 
+config NET_SELFTESTS
+	bool
+	default n
+
 config NET_SOCK_MSG
 	bool
 	default n
diff --git a/net/core/Makefile b/net/core/Makefile
index 0c2233c826fd..1a6168d8f23b 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_NET_DEVLINK) += devlink.o
 obj-$(CONFIG_GRO_CELLS) += gro_cells.o
 obj-$(CONFIG_FAILOVER) += failover.o
 ifeq ($(CONFIG_INET),y)
+obj-$(CONFIG_NET_SELFTESTS) += selftests.o
 obj-$(CONFIG_NET_SOCK_MSG) += skmsg.o
 obj-$(CONFIG_BPF_SYSCALL) += sock_map.o
 endif
diff --git a/net/core/selftests.c b/net/core/selftests.c
new file mode 100644
index 000000000000..da1871d0f4ef
--- /dev/null
+++ b/net/core/selftests.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Synopsys, Inc. and/or its affiliates.
+ * stmmac Selftests Support
+ *
+ * Author: Jose Abreu <joabreu at synopsys.com>
+ *
+ * Ported from stmmac by:
+ * Copyright (C) 2021 Oleksij Rempel <o.rempel at pengutronix.de>
+ */
+
+#include <linux/phy.h>
+#include <net/selftests.h>
+#include <net/tcp.h>
+#include <net/udp.h>
+
+struct net_packet_attrs {
+	unsigned char *src;
+	unsigned char *dst;
+	u32 ip_src;
+	u32 ip_dst;
+	int tcp;
+	int sport;
+	int dport;
+	int timeout;
+	int size;
+	int max_size;
+	u8 id;
+	u16 queue_mapping;
+};
+
+struct net_test_priv {
+	struct net_packet_attrs *packet;
+	struct packet_type pt;
+	struct completion comp;
+	int double_vlan;
+	int vlan_id;
+	int ok;
+};
+
+struct netsfhdr {
+	__be32 version;
+	__be64 magic;
+	u8 id;
+} __packed;
+
+static u8 net_test_next_id;
+
+#define NET_TEST_PKT_SIZE (sizeof(struct ethhdr) + sizeof(struct iphdr) + \
+			   sizeof(struct netsfhdr))
+#define NET_TEST_PKT_MAGIC	0xdeadcafecafedeadULL
+#define NET_LB_TIMEOUT		msecs_to_jiffies(200)
+
+static struct sk_buff *net_test_get_udp_skb(struct net_device *ndev,
+					    struct net_packet_attrs *attr)
+{
+	struct sk_buff *skb = NULL;
+	struct udphdr *uhdr = NULL;
+	struct tcphdr *thdr = NULL;
+	struct netsfhdr *shdr;
+	struct ethhdr *ehdr;
+	struct iphdr *ihdr;
+	int iplen, size;
+
+	size = attr->size + NET_TEST_PKT_SIZE;
+
+	if (attr->tcp)
+		size += sizeof(struct tcphdr);
+	else
+		size += sizeof(struct udphdr);
+
+	if (attr->max_size && attr->max_size > size)
+		size = attr->max_size;
+
+	skb = netdev_alloc_skb(ndev, size);
+	if (!skb)
+		return NULL;
+
+	prefetchw(skb->data);
+
+	ehdr = skb_push(skb, ETH_HLEN);
+	skb_reset_mac_header(skb);
+
+	skb_set_network_header(skb, skb->len);
+	ihdr = skb_put(skb, sizeof(*ihdr));
+
+	skb_set_transport_header(skb, skb->len);
+	if (attr->tcp)
+		thdr = skb_put(skb, sizeof(*thdr));
+	else
+		uhdr = skb_put(skb, sizeof(*uhdr));
+
+	eth_zero_addr(ehdr->h_dest);
+
+	if (attr->src)
+		ether_addr_copy(ehdr->h_source, attr->src);
+	if (attr->dst)
+		ether_addr_copy(ehdr->h_dest, attr->dst);
+
+	ehdr->h_proto = htons(ETH_P_IP);
+
+	if (attr->tcp) {
+		thdr->source = htons(attr->sport);
+		thdr->dest = htons(attr->dport);
+		thdr->doff = sizeof(struct tcphdr) / 4;
+		thdr->check = 0;
+	} else {
+		uhdr->source = htons(attr->sport);
+		uhdr->dest = htons(attr->dport);
+		uhdr->len = htons(sizeof(*shdr) + sizeof(*uhdr) + attr->size);
+		if (attr->max_size)
+			uhdr->len = htons(attr->max_size -
+					  (sizeof(*ihdr) + sizeof(*ehdr)));
+		uhdr->check = 0;
+	}
+
+	ihdr->ihl = 5;
+	ihdr->ttl = 32;
+	ihdr->version = 4;
+	if (attr->tcp)
+		ihdr->protocol = IPPROTO_TCP;
+	else
+		ihdr->protocol = IPPROTO_UDP;
+	iplen = sizeof(*ihdr) + sizeof(*shdr) + attr->size;
+	if (attr->tcp)
+		iplen += sizeof(*thdr);
+	else
+		iplen += sizeof(*uhdr);
+
+	if (attr->max_size)
+		iplen = attr->max_size - sizeof(*ehdr);
+
+	ihdr->tot_len = htons(iplen);
+	ihdr->frag_off = 0;
+	ihdr->saddr = htonl(attr->ip_src);
+	ihdr->daddr = htonl(attr->ip_dst);
+	ihdr->tos = 0;
+	ihdr->id = 0;
+	ip_send_check(ihdr);
+
+	shdr = skb_put(skb, sizeof(*shdr));
+	shdr->version = 0;
+	shdr->magic = cpu_to_be64(NET_TEST_PKT_MAGIC);
+	attr->id = net_test_next_id;
+	shdr->id = net_test_next_id++;
+
+	if (attr->size)
+		skb_put(skb, attr->size);
+	if (attr->max_size && attr->max_size > skb->len)
+		skb_put(skb, attr->max_size - skb->len);
+
+	skb->csum = 0;
+	skb->ip_summed = CHECKSUM_PARTIAL;
+	if (attr->tcp) {
+		thdr->check = ~tcp_v4_check(skb->len, ihdr->saddr,
+					    ihdr->daddr, 0);
+		skb->csum_start = skb_transport_header(skb) - skb->head;
+		skb->csum_offset = offsetof(struct tcphdr, check);
+	} else {
+		udp4_hwcsum(skb, ihdr->saddr, ihdr->daddr);
+	}
+
+	skb->protocol = htons(ETH_P_IP);
+	skb->pkt_type = PACKET_HOST;
+	skb->dev = ndev;
+
+	return skb;
+}
+
+static int net_test_loopback_validate(struct sk_buff *skb,
+				      struct net_device *ndev,
+				      struct packet_type *pt,
+				      struct net_device *orig_ndev)
+{
+	struct net_test_priv *tpriv = pt->af_packet_priv;
+	unsigned char *src = tpriv->packet->src;
+	unsigned char *dst = tpriv->packet->dst;
+	struct netsfhdr *shdr;
+	struct ethhdr *ehdr;
+	struct udphdr *uhdr;
+	struct tcphdr *thdr;
+	struct iphdr *ihdr;
+
+	skb = skb_unshare(skb, GFP_ATOMIC);
+	if (!skb)
+		goto out;
+
+	if (skb_linearize(skb))
+		goto out;
+	if (skb_headlen(skb) < (NET_TEST_PKT_SIZE - ETH_HLEN))
+		goto out;
+
+	ehdr = (struct ethhdr *)skb_mac_header(skb);
+	if (dst) {
+		if (!ether_addr_equal_unaligned(ehdr->h_dest, dst))
+			goto out;
+	}
+
+	if (src) {
+		if (!ether_addr_equal_unaligned(ehdr->h_source, src))
+			goto out;
+	}
+
+	ihdr = ip_hdr(skb);
+	if (tpriv->double_vlan)
+		ihdr = (struct iphdr *)(skb_network_header(skb) + 4);
+
+	if (tpriv->packet->tcp) {
+		if (ihdr->protocol != IPPROTO_TCP)
+			goto out;
+
+		thdr = (struct tcphdr *)((u8 *)ihdr + 4 * ihdr->ihl);
+		if (thdr->dest != htons(tpriv->packet->dport))
+			goto out;
+
+		shdr = (struct netsfhdr *)((u8 *)thdr + sizeof(*thdr));
+	} else {
+		if (ihdr->protocol != IPPROTO_UDP)
+			goto out;
+
+		uhdr = (struct udphdr *)((u8 *)ihdr + 4 * ihdr->ihl);
+		if (uhdr->dest != htons(tpriv->packet->dport))
+			goto out;
+
+		shdr = (struct netsfhdr *)((u8 *)uhdr + sizeof(*uhdr));
+	}
+
+	if (shdr->magic != cpu_to_be64(NET_TEST_PKT_MAGIC))
+		goto out;
+	if (tpriv->packet->id != shdr->id)
+		goto out;
+
+	tpriv->ok = true;
+	complete(&tpriv->comp);
+out:
+	kfree_skb(skb);
+	return 0;
+}
+
+static int __net_test_loopback(struct net_device *ndev,
+			       struct net_packet_attrs *attr)
+{
+	struct net_test_priv *tpriv;
+	struct sk_buff *skb = NULL;
+	int ret = 0;
+
+	tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
+	if (!tpriv)
+		return -ENOMEM;
+
+	tpriv->ok = false;
+	init_completion(&tpriv->comp);
+
+	tpriv->pt.type = htons(ETH_P_IP);
+	tpriv->pt.func = net_test_loopback_validate;
+	tpriv->pt.dev = ndev;
+	tpriv->pt.af_packet_priv = tpriv;
+	tpriv->packet = attr;
+	dev_add_pack(&tpriv->pt);
+
+	skb = net_test_get_udp_skb(ndev, attr);
+	if (!skb) {
+		ret = -ENOMEM;
+		goto cleanup;
+	}
+
+	ret = dev_direct_xmit(skb, attr->queue_mapping);
+	if (ret)
+		goto cleanup;
+
+	if (!attr->timeout)
+		attr->timeout = NET_LB_TIMEOUT;
+
+	wait_for_completion_timeout(&tpriv->comp, attr->timeout);
+	ret = tpriv->ok ? 0 : -ETIMEDOUT;
+
+cleanup:
+	dev_remove_pack(&tpriv->pt);
+	kfree(tpriv);
+	return ret;
+}
+
+static int net_test_phy_loopback_udp(struct net_device *ndev)
+{
+	struct net_packet_attrs attr = { };
+
+	attr.dst = ndev->dev_addr;
+	return __net_test_loopback(ndev, &attr);
+}
+
+static int net_test_phy_loopback_tcp(struct net_device *ndev)
+{
+	struct net_packet_attrs attr = { };
+
+	attr.dst = ndev->dev_addr;
+	attr.tcp = true;
+	return __net_test_loopback(ndev, &attr);
+}
+
+static const struct net_test {
+	char name[ETH_GSTRING_LEN];
+	int (*fn)(struct net_device *ndev);
+} net_selftests[] = {
+	{
+		.name = "PHY Loopback, UDP          ",
+		.fn = net_test_phy_loopback_udp,
+	}, {
+		.name = "PHY Loopback, TCP          ",
+		.fn = net_test_phy_loopback_tcp,
+	},
+};
+
+void net_selftest(struct net_device *ndev, struct ethtool_test *etest, u64 *buf)
+{
+	int count = net_selftest_get_count();
+	int i;
+
+	memset(buf, 0, sizeof(*buf) * count);
+	net_test_next_id = 0;
+
+	if (etest->flags != ETH_TEST_FL_OFFLINE) {
+		netdev_err(ndev, "Only offline tests are supported\n");
+		etest->flags |= ETH_TEST_FL_FAILED;
+		return;
+	} else if (!netif_carrier_ok(ndev)) {
+		netdev_err(ndev, "You need valid Link to execute tests\n");
+		etest->flags |= ETH_TEST_FL_FAILED;
+		return;
+	}
+
+	if (!ndev->phydev)
+		return;
+
+	/* PHY loopback tests should be combined to avoid delays on each PHY
+	 * reconfiguration
+	 */
+	phy_loopback(ndev->phydev, true);
+
+	/* give PHYs some time to establish the loopback link */
+	msleep(100);
+
+	for (i = 0; i < count; i++) {
+		buf[i] = net_selftests[i].fn(ndev);
+		if (buf[i] && (buf[i] != -EOPNOTSUPP))
+			etest->flags |= ETH_TEST_FL_FAILED;
+	}
+
+	phy_loopback(ndev->phydev, false);
+}
+
+int net_selftest_get_count(void)
+{
+	return ARRAY_SIZE(net_selftests);
+}
+
+void net_selftest_get_strings(u8 *data)
+{
+	u8 *p = data;
+	int i;
+
+	for (i = 0; i < net_selftest_get_count(); i++) {
+		snprintf(p, ETH_GSTRING_LEN, "%2d. %s", i + 1,
+			 net_selftests[i].name);
+		p += ETH_GSTRING_LEN;
+	}
+}
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:32 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:32 +0200
Subject: [PATCH v2 1/7] net: phy: genphy_loopback: add link speed configuration
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-2-o.rempel@pengutronix.de>

In case of loopback, in most cases we need to disable autoneg support
and force some speed configuration. Otherwise, depending on currently
active auto negotiated link speed, the loopback may or may not work.

This patch was tested with following PHYs: TJA1102, KSZ8081, KSZ9031,
AT8035, AR9331.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/phy/phy.c        |  3 ++-
 drivers/net/phy/phy_device.c | 21 +++++++++++++++++++--
 include/linux/phy.h          |  1 +
 3 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index fc2e7cb5b2e5..1f0512e39c65 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -701,7 +701,7 @@ int phy_start_cable_test_tdr(struct phy_device *phydev,
 }
 EXPORT_SYMBOL(phy_start_cable_test_tdr);
 
-static int phy_config_aneg(struct phy_device *phydev)
+int phy_config_aneg(struct phy_device *phydev)
 {
 	if (phydev->drv->config_aneg)
 		return phydev->drv->config_aneg(phydev);
@@ -714,6 +714,7 @@ static int phy_config_aneg(struct phy_device *phydev)
 
 	return genphy_config_aneg(phydev);
 }
+EXPORT_SYMBOL(phy_config_aneg);
 
 /**
  * phy_check_link_status - check link status and set state accordingly
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 73d29fd5e03d..f484f191d2ff 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2562,8 +2562,25 @@ EXPORT_SYMBOL(genphy_resume);
 
 int genphy_loopback(struct phy_device *phydev, bool enable)
 {
-	return phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK,
-			  enable ? BMCR_LOOPBACK : 0);
+	if (enable) {
+		u16 ctl = BMCR_LOOPBACK;
+
+		if (phydev->speed == SPEED_1000)
+			ctl |= BMCR_SPEED1000;
+		else if (phydev->speed == SPEED_100)
+			ctl |= BMCR_SPEED100;
+
+		if (phydev->duplex == DUPLEX_FULL)
+			ctl |= BMCR_FULLDPLX;
+
+		phy_modify(phydev, MII_BMCR, ~0, ctl);
+	} else {
+		phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK, 0);
+
+		phy_config_aneg(phydev);
+	}
+
+	return 0;
 }
 EXPORT_SYMBOL(genphy_loopback);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 98fb441dd72e..98e351bb0964 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1410,6 +1410,7 @@ void phy_disconnect(struct phy_device *phydev);
 void phy_detach(struct phy_device *phydev);
 void phy_start(struct phy_device *phydev);
 void phy_stop(struct phy_device *phydev);
+int phy_config_aneg(struct phy_device *phydev);
 int phy_start_aneg(struct phy_device *phydev);
 int phy_aneg_done(struct phy_device *phydev);
 int phy_speed_down(struct phy_device *phydev, bool sync);
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:37 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:37 +0200
Subject: [PATCH v2 6/7] net: ag71xx: make use of generic NET_SELFTESTS library
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-7-o.rempel@pengutronix.de>

With this patch the ag71xx on Atheros AR9331 will able to run generic net
selftests.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/ethernet/atheros/Kconfig  |  1 +
 drivers/net/ethernet/atheros/ag71xx.c | 20 ++++++++++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/atheros/Kconfig b/drivers/net/ethernet/atheros/Kconfig
index fb803bf92ded..6842b74b0696 100644
--- a/drivers/net/ethernet/atheros/Kconfig
+++ b/drivers/net/ethernet/atheros/Kconfig
@@ -20,6 +20,7 @@ if NET_VENDOR_ATHEROS
 config AG71XX
 	tristate "Atheros AR7XXX/AR9XXX built-in ethernet mac support"
 	depends on ATH79
+	select NET_SELFTESTS
 	select PHYLINK
 	help
 	  If you wish to compile a kernel for AR7XXX/91XXX and enable
diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
index 7352f98123c7..eb067ce978ae 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -37,6 +37,7 @@
 #include <linux/reset.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <net/selftests.h>
 
 /* For our NAPI weight bigger does *NOT* mean better - it means more
  * D-cache misses and lots more wasted cycles than we'll ever
@@ -497,12 +498,17 @@ static int ag71xx_ethtool_set_pauseparam(struct net_device *ndev,
 static void ag71xx_ethtool_get_strings(struct net_device *netdev, u32 sset,
 				       u8 *data)
 {
-	if (sset == ETH_SS_STATS) {
-		int i;
+	int i;
 
+	switch (sset) {
+	case ETH_SS_STATS:
 		for (i = 0; i < ARRAY_SIZE(ag71xx_statistics); i++)
 			memcpy(data + i * ETH_GSTRING_LEN,
 			       ag71xx_statistics[i].name, ETH_GSTRING_LEN);
+		break;
+	case ETH_SS_TEST:
+		net_selftest_get_strings(data);
+		break;
 	}
 }
 
@@ -519,9 +525,14 @@ static void ag71xx_ethtool_get_stats(struct net_device *ndev,
 
 static int ag71xx_ethtool_get_sset_count(struct net_device *ndev, int sset)
 {
-	if (sset == ETH_SS_STATS)
+	switch (sset) {
+	case ETH_SS_STATS:
 		return ARRAY_SIZE(ag71xx_statistics);
-	return -EOPNOTSUPP;
+	case ETH_SS_TEST:
+		return net_selftest_get_count();
+	default:
+		return -EOPNOTSUPP;
+	}
 }
 
 static const struct ethtool_ops ag71xx_ethtool_ops = {
@@ -536,6 +547,7 @@ static const struct ethtool_ops ag71xx_ethtool_ops = {
 	.get_strings			= ag71xx_ethtool_get_strings,
 	.get_ethtool_stats		= ag71xx_ethtool_get_stats,
 	.get_sset_count			= ag71xx_ethtool_get_sset_count,
+	.self_test			= net_selftest,
 };
 
 static int ag71xx_mdio_wait_busy(struct ag71xx *ag)
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:31 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:31 +0200
Subject: [PATCH net-next v2 0/7] provide generic net selftest support
Message-ID: <20210415130738.19603-1-o.rempel@pengutronix.de>

changes v2:
- make this tests available for all netowking devices.
- enable them on FEC, ag71xx and all DSA switches.
- add and test loopback support on more PHYs.

This patch set provides diagnostic capabilities for some iMX, ag71xx or
any DSA based devices. For proper functionality, PHY loopback support is
needed.
So far there is only initial infrastructure with basic tests. 

Oleksij Rempel (7):
  net: phy: genphy_loopback: add link speed configuration
  net: phy: micrel: KSZ8081 & KSZ9031: add loopback support
  net: phy: at803x: AR8085 & AR9331: add loopback support
  net: add generic selftest support
  net: fec: make use of generic NET_SELFTESTS library
  net: ag71xx: make use of generic NET_SELFTESTS library
  net: dsa: enable selftest support for all switches by default

 drivers/net/ethernet/atheros/Kconfig      |   1 +
 drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
 drivers/net/ethernet/freescale/Kconfig    |   1 +
 drivers/net/ethernet/freescale/fec_main.c |   7 +
 drivers/net/phy/at803x.c                  |   2 +
 drivers/net/phy/micrel.c                  |   2 +
 drivers/net/phy/phy.c                     |   3 +-
 drivers/net/phy/phy_device.c              |  21 +-
 include/linux/phy.h                       |   1 +
 include/net/dsa.h                         |   2 +
 include/net/selftests.h                   |  12 +
 net/Kconfig                               |   4 +
 net/core/Makefile                         |   1 +
 net/core/selftests.c                      | 366 ++++++++++++++++++++++
 net/dsa/Kconfig                           |   1 +
 net/dsa/slave.c                           |  21 ++
 16 files changed, 458 insertions(+), 7 deletions(-)
 create mode 100644 include/net/selftests.h
 create mode 100644 net/core/selftests.c

-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:36 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:36 +0200
Subject: [PATCH v2 5/7] net: fec: make use of generic NET_SELFTESTS library
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-6-o.rempel@pengutronix.de>

With this patch FEC on iMX will able to run generic net selftests

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/ethernet/freescale/Kconfig    | 1 +
 drivers/net/ethernet/freescale/fec_main.c | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3f9175bdce77..3d937b4650b2 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -26,6 +26,7 @@ config FEC
 		   ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
 	default ARCH_MXC || SOC_IMX28 if ARM
 	select CRC32
+	select NET_SELFTESTS
 	select PHYLIB
 	imply PTP_1588_CLOCK
 	help
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 70aea9c274fe..d51b2eb1de71 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -38,6 +38,7 @@
 #include <linux/in.h>
 #include <linux/ip.h>
 #include <net/ip.h>
+#include <net/selftests.h>
 #include <net/tso.h>
 #include <linux/tcp.h>
 #include <linux/udp.h>
@@ -2481,6 +2482,9 @@ static void fec_enet_get_strings(struct net_device *netdev,
 			memcpy(data + i * ETH_GSTRING_LEN,
 				fec_stats[i].name, ETH_GSTRING_LEN);
 		break;
+	case ETH_SS_TEST:
+		net_selftest_get_strings(data);
+		break;
 	}
 }
 
@@ -2489,6 +2493,8 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 	switch (sset) {
 	case ETH_SS_STATS:
 		return ARRAY_SIZE(fec_stats);
+	case ETH_SS_TEST:
+		return net_selftest_get_count();
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -2740,6 +2746,7 @@ static const struct ethtool_ops fec_enet_ethtool_ops = {
 	.set_wol		= fec_enet_set_wol,
 	.get_link_ksettings	= phy_ethtool_get_link_ksettings,
 	.set_link_ksettings	= phy_ethtool_set_link_ksettings,
+	.self_test		= net_selftest,
 };
 
 static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
-- 
2.29.2



From o.rempel at pengutronix.de  Thu Apr 15 14:07:38 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Thu, 15 Apr 2021 15:07:38 +0200
Subject: [PATCH v2 7/7] net: dsa: enable selftest support for all switches by
 default
In-Reply-To: <20210415130738.19603-1-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
Message-ID: <20210415130738.19603-8-o.rempel@pengutronix.de>

Most of generic selftest should be able to work with probably all ethernet
controllers. The DSA switches are not exception, so enable it by default at
least for DSA.

This patch was tested with SJA1105 and AR9331.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 include/net/dsa.h |  2 ++
 net/dsa/Kconfig   |  1 +
 net/dsa/slave.c   | 21 +++++++++++++++++++++
 3 files changed, 24 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 57b2c49f72f4..b4f89522b545 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -577,6 +577,8 @@ struct dsa_switch_ops {
 					 int port, uint64_t *data);
 	void	(*get_stats64)(struct dsa_switch *ds, int port,
 				   struct rtnl_link_stats64 *s);
+	void	(*self_test)(struct dsa_switch *ds, int port,
+			     struct ethtool_test *etest, u64 *data);
 
 	/*
 	 * ethtool Wake-on-LAN
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 8746b07668ae..cbc2bd643ab2 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -9,6 +9,7 @@ menuconfig NET_DSA
 	select NET_SWITCHDEV
 	select PHYLINK
 	select NET_DEVLINK
+	select NET_SELFTESTS
 	help
 	  Say Y if you want to enable support for the hardware switches supported
 	  by the Distributed Switch Architecture.
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 995e0e16f295..e282b422f733 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -15,6 +15,7 @@
 #include <linux/mdio.h>
 #include <net/rtnetlink.h>
 #include <net/pkt_cls.h>
+#include <net/selftests.h>
 #include <net/tc_act/tc_mirred.h>
 #include <linux/if_bridge.h>
 #include <linux/if_hsr.h>
@@ -748,7 +749,10 @@ static void dsa_slave_get_strings(struct net_device *dev,
 		if (ds->ops->get_strings)
 			ds->ops->get_strings(ds, dp->index, stringset,
 					     data + 4 * len);
+	} else if (stringset ==  ETH_SS_TEST) {
+		net_selftest_get_strings(data);
 	}
+
 }
 
 static void dsa_slave_get_ethtool_stats(struct net_device *dev,
@@ -794,11 +798,27 @@ static int dsa_slave_get_sset_count(struct net_device *dev, int sset)
 			count += ds->ops->get_sset_count(ds, dp->index, sset);
 
 		return count;
+	} else if (sset ==  ETH_SS_TEST) {
+		return net_selftest_get_count();
 	}
 
 	return -EOPNOTSUPP;
 }
 
+static void dsa_slave_net_selftest(struct net_device *ndev,
+				   struct ethtool_test *etest, u64 *buf)
+{
+	struct dsa_port *dp = dsa_slave_to_port(ndev);
+	struct dsa_switch *ds = dp->ds;
+
+	if (ds->ops->self_test) {
+		ds->ops->self_test(ds, dp->index, etest, buf);
+		return;
+	}
+
+	net_selftest(ndev, etest, buf);
+}
+
 static void dsa_slave_get_wol(struct net_device *dev, struct ethtool_wolinfo *w)
 {
 	struct dsa_port *dp = dsa_slave_to_port(dev);
@@ -1630,6 +1650,7 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
 	.get_rxnfc		= dsa_slave_get_rxnfc,
 	.set_rxnfc		= dsa_slave_set_rxnfc,
 	.get_ts_info		= dsa_slave_get_ts_info,
+	.self_test		= dsa_slave_net_selftest,
 };
 
 /* legacy way, bypassing the bridge *****************************************/
-- 
2.29.2



From marex at denx.de  Thu Apr 15 14:21:26 2021
From: marex at denx.de (Marek Vasut)
Date: Thu, 15 Apr 2021 15:21:26 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
In-Reply-To: <20210415101037.1465-12-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
Message-ID: <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>

On 4/15/21 12:10 PM, Alexandre Torgue wrote:
> Running "make dtbs_check W=1", some warnings are reported concerning
> LTDC port subnode:
> 
> /soc/display-controller at 5a001000/port:
> unnecessary #address-cells/#size-cells without "ranges" or child "reg"
> property
> /soc/display-controller at 5a001000/port: graph node has single child node
> 'endpoint', #address-cells/#size-cells are not necessary

btw could you retain diffstat on your patches ? It's useful to see which 
files changed right away.

[...]

> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> index 2bc92ef3aeb9..19ef475a48fc 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> @@ -82,9 +82,15 @@
>   };
>   
>   &ltdc {
> -	status = "okay";
> -
>   	port {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ltdc_ep0_out: endpoint at 0 {
> +			reg = <0>;
> +			remote-endpoint = <&sii9022_in>;
> +		};
> +
>   		ltdc_ep1_out: endpoint at 1 {
>   			reg = <1>;
>   			remote-endpoint = <&dsi_in>;

[...]

> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> index 64dca5b7f748..e7f10975cacf 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> @@ -277,11 +277,7 @@
>   	status = "okay";
>   
>   	port {
> -		#address-cells = <1>;
> -		#size-cells = <0>;
> -
> -		ltdc_ep0_out: endpoint at 0 {
> -			reg = <0>;
> +		ltdc_ep0_out: endpoint {
>   			remote-endpoint = <&adv7513_in>;
>   		};
>   	};

I think this is wrong, the AV96 can have two displays connected to two 
ports of the LTDC, just like DK2 for example.


From nathan at kernel.org  Thu Apr 15 14:25:57 2021
From: nathan at kernel.org (Nathan Chancellor)
Date: Thu, 15 Apr 2021 06:25:57 -0700
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn,endif}
In-Reply-To: <20210415091743.GB1015@arm.com>
References: <20210414000803.662534-1-nathan@kernel.org>
 <20210415091743.GB1015@arm.com>
Message-ID: <YHg+5RSG4XPLlZD8@archlinux-ax161>

On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> Hi Nathan,
> 
> On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > set atomically"), LLVM's integrated assembler fails to build entry.S:
> > 
> > <instantiation>:5:7: error: expected assembly-time absolute expression
> >  .org . - (664b-663b) + (662b-661b)
> >       ^
> > <instantiation>:6:7: error: expected assembly-time absolute expression
> >  .org . - (662b-661b) + (664b-663b)
> >       ^
> 
> I tried the latest Linus' tree and linux-next (defconfig) with this
> commit in and I can't get your build error. I used both clang-10 from
> Debian stable and clang-11 from Debian sid. So, which clang version did
> you use or which kernel config options?
> 
> -- 
> Catalin
> 

Hi Catalin,

Interesting, this reproduces for me with LLVM 12 or newer with just
defconfig.

$ make -j"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LLVM=1 LLVM_IAS=1 defconfig arch/arm64/kernel/entry.o

https://github.com/ClangBuiltLinux/continuous-integration2/runs/2350258778?check_suite_focus=true

Cheers,
Nathan


From linux at roeck-us.net  Thu Apr 15 14:29:09 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 15 Apr 2021 06:29:09 -0700
Subject: [PATCH V3] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <AAgApgCdDjCicbWFGpPmeaor.3.1618479605424.Hmail.wangqing@vivo.com>
References: <AAgApgCdDjCicbWFGpPmeaor.3.1618479605424.Hmail.wangqing@vivo.com>
Message-ID: <7555c705-a12d-5d51-3881-68feb5d078c1@roeck-us.net>

On 4/15/21 2:40 AM, ?? wrote:

> 
> Yes, as mentioned before, the behavior of WDT_MODE_IRQ_EN is use irq instead of
> reset, so we must use WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN if like you said
> "the first time generating an interrupt and the second time resetting the system" . 
> 
> The Dual mode is mentioned in the MTK datasheet:
> In this mode, the watchdog will be AUTO-RESTART after interrupt is triggered. 
> AP need to clear WDT_STA after receiving interrupt from TOPRGU, or system reset
> will be triggered after watchdog timer expires.
> Instructions for use?
> Set wdt_en = 1'b1.
> Set dual_mode = 1'b1.
> Set wdt_irq = 1'b1.
> 
> We can use Dual mode to achieve pretimeout behavior, only in this way can we
> get more information during pretimeout processing, instead of directly resetting.
> 

If so, the pretimeout would always be half of the full timeout, and the timeout
to configure would be timeout / 2. The code would have to adjust the pretimeout
time accordingly. Also, to avoid unexpected and changed behavior, the prefimeout
should by default be disabled.

Guenter




From vincenzo.frascino at arm.com  Thu Apr 15 14:31:06 2021
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Date: Thu, 15 Apr 2021 14:31:06 +0100
Subject: [PATCH v2] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210414214548.700993-1-ndesaulniers@google.com>
References: <YHYlQnFRMNdn/CDp@archlinux-ax161>
 <20210414214548.700993-1-ndesaulniers@google.com>
Message-ID: <a2ddf4d2-110a-9290-f766-3925e451ddef@arm.com>



On 4/14/21 10:45 PM, Nick Desaulniers wrote:
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this. We no longer need --prefix,
> --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> remove those too.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/
> 
> Suggested-by: Nathan Chancellor <nathan at kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>

The patch looks fine, but I have one question: the kernel requires as a minimum
Clang/LLVM version 10.0.1. Did you verify that with that version compat vDSOs
still builds and works correctly?

Otherwise:

Reviewed-by: Vincenzo Frascino <vincenzo.frascino at arm.com>

> ---
> Changes V1 -> V2:
> * Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and
>   COMPAT_GCC_TOOLCHAIN_DIR as per Nathan.
> * Credit Nathan with Suggested-by tag.
> * Remove -Qunused-arguments.
> * Update commit message.
> 
>  arch/arm64/kernel/vdso32/Makefile | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 789ad420f16b..3dba0c4f8f42 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile
>  
>  # Same as cc-*option, but using CC_COMPAT instead of CC
>  ifeq ($(CONFIG_CC_IS_CLANG), y)
> -COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE_COMPAT)elfedit))
> -COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
> -
>  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
> -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> -ifneq ($(COMPAT_GCC_TOOLCHAIN),)
> -CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
> -endif
>  
>  CC_COMPAT ?= $(CC)
>  CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
> 

-- 
Regards,
Vincenzo


From alexandre.torgue at foss.st.com  Thu Apr 15 14:34:06 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 15 Apr 2021 15:34:06 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
In-Reply-To: <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
 <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
Message-ID: <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>

Hi Marek

On 4/15/21 3:21 PM, Marek Vasut wrote:
> On 4/15/21 12:10 PM, Alexandre Torgue wrote:
>> Running "make dtbs_check W=1", some warnings are reported concerning
>> LTDC port subnode:
>>
>> /soc/display-controller at 5a001000/port:
>> unnecessary #address-cells/#size-cells without "ranges" or child "reg"
>> property
>> /soc/display-controller at 5a001000/port: graph node has single child node
>> 'endpoint', #address-cells/#size-cells are not necessary
> 
> btw could you retain diffstat on your patches ? It's useful to see which 
> files changed right away.
> [...]
> 
>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> index 2bc92ef3aeb9..19ef475a48fc 100644
>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>> @@ -82,9 +82,15 @@
>> ? };
>> ? &ltdc {
>> -??? status = "okay";
>> -
>> ????? port {
>> +??????? #address-cells = <1>;
>> +??????? #size-cells = <0>;
>> +
>> +??????? ltdc_ep0_out: endpoint at 0 {
>> +??????????? reg = <0>;
>> +??????????? remote-endpoint = <&sii9022_in>;
>> +??????? };
>> +
>> ????????? ltdc_ep1_out: endpoint at 1 {
>> ????????????? reg = <1>;
>> ????????????? remote-endpoint = <&dsi_in>;
> 
> [...]
> 
>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>> index 64dca5b7f748..e7f10975cacf 100644
>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>> @@ -277,11 +277,7 @@
>> ????? status = "okay";
>> ????? port {
>> -??????? #address-cells = <1>;
>> -??????? #size-cells = <0>;
>> -
>> -??????? ltdc_ep0_out: endpoint at 0 {
>> -??????????? reg = <0>;
>> +??????? ltdc_ep0_out: endpoint {
>> ????????????? remote-endpoint = <&adv7513_in>;
>> ????????? };
>> ????? };
> 
> I think this is wrong, the AV96 can have two displays connected to two 
> ports of the LTDC, just like DK2 for example.

As for dk2 address/size cells are added only if there are 2 endpoints. 
It is for this reason I moved endpoint0 definition from stm32mp15xx-dkx 
to stm32mp151a-dk1.dts (dk1 has only one endpoint).

Here it's the same, if you have second endpoint then adress/size will 
have to be added.

alex












From joro at 8bytes.org  Thu Apr 15 14:34:26 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 15 Apr 2021 15:34:26 +0200
Subject: [PATCH] iommu/mediatek: always enable the clk on resume
In-Reply-To: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
References: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
Message-ID: <YHhA4u7zat3vtJfD@8bytes.org>

On Thu, Apr 08, 2021 at 02:28:42PM +0200, Dafna Hirschfeld wrote:
>  drivers/iommu/mtk_iommu.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)

Applied, thanks.


From joro at 8bytes.org  Thu Apr 15 14:36:16 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 15 Apr 2021 15:36:16 +0200
Subject: [PATCH] iommu: exynos: remove unneeded local variable
 initialization
In-Reply-To: <20210408201622.78009-1-krzysztof.kozlowski@canonical.com>
References: <20210408201622.78009-1-krzysztof.kozlowski@canonical.com>
Message-ID: <YHhBUBe9ZT+P9TfJ@8bytes.org>

On Thu, Apr 08, 2021 at 10:16:22PM +0200, Krzysztof Kozlowski wrote:
>  drivers/iommu/exynos-iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.


From peng.fan at oss.nxp.com  Thu Apr 15 14:27:33 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:33 +0800
Subject: [PATCH V4 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
Message-ID: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

V4:
 Typo fix 
 patch 4: take state as a check condition
 patch 5: move regmap lookup/attach to imx_rproc_detect_mode
 patch 6: add imx_rproc_clk_enable for optional clk
 patch 8: use switch/case in imx_rproc_detect_mode
V3:
 Add A-b tag for Patch 1/2
 Fix the checkpatch warning for Patch 6,8

V2:
 Patch 1/8, use fsl as vendor, typo fix
 Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that
 change.

This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
parse fsl,auto-boot


Peng Fan (8):
  dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
  dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
  dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
  remoteproc: imx_rproc: parse fsl,auto-boot
  remoteproc: imx_rproc: initial support for mutilple start/stop method
  remoteproc: imx_rproc: make clk optional
  remoteproc: imx_rproc: support i.MX7ULP
  remoteproc: imx_rproc: support i.MX8MN/P

 .../bindings/remoteproc/fsl,imx-rproc.yaml         |  11 +-
 drivers/remoteproc/imx_rproc.c                     | 206 +++++++++++++++++----
 2 files changed, 179 insertions(+), 38 deletions(-)

-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:34 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:34 +0800
Subject: [PATCH V4 1/8] dt-bindings: remoteproc: imx_rproc: add fsl,
 auto-boot property
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-2-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add an optional property "fsl,auto-boot" to indicate remote processor
auto boot.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 208a628..b13bf8d 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -49,6 +49,12 @@ properties:
     minItems: 1
     maxItems: 32
 
+  fsl,auto-boot:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Indicate whether need to load the default firmware and start the remote
+      processor automatically.
+
 required:
   - compatible
   - clocks
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:35 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:35 +0800
Subject: [PATCH V4 2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
 support
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-3-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX7ULP compatible.

We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
control of M4 core, M4 core starts by ROM and powers most services used
by A7 core, so A7 core has no power to start and stop M4 core. So
clocks and syscon are not required.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index b13bf8d..58bc2a2 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -18,6 +18,7 @@ properties:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
       - fsl,imx7d-cm4
+      - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
 
   clocks:
@@ -57,8 +58,6 @@ properties:
 
 required:
   - compatible
-  - clocks
-  - syscon
 
 additionalProperties: false
 
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:36 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:36 +0800
Subject: [PATCH V4 3/8] dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-4-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) compatible string

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 58bc2a2..1dc34cf 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -17,6 +17,8 @@ properties:
     enum:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
+      - fsl,imx8mn-cm7
+      - fsl,imx8mp-cm7
       - fsl,imx7d-cm4
       - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:37 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:37 +0800
Subject: [PATCH V4 4/8] remoteproc: imx_rproc: parse fsl,auto-boot
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-5-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Parse fsl,auto-boot to indicate whether need remoteproc framework
auto boot or not.

When remote processor is booted before Linux Kernel up, do not parse
fsl,auto-boot, so only need to parse the property when rproc state is
RPROC_DETACHED.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d633887..06dac92 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -654,6 +654,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 
 	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
 
+	if (rproc->state != RPROC_DETACHED)
+		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "rproc_add failed\n");
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:38 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:38 +0800
Subject: [PATCH V4 5/8] remoteproc: imx_rproc: initial support for mutilple
 start/stop method
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-6-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
(start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).

The current SoCs supported are all using IMX_RPROC_MMIO, add a restrict
in imx_rproc_detect_mode that only SoCs using IMX_RPROC_MMIO needs syscon
regmap to access registers.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 51 +++++++++++++++++++++++++++++-------------
 1 file changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 06dac92..2b633fd 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -74,6 +74,15 @@ struct imx_rproc_att {
 	int flags;
 };
 
+/* Remote core start/stop method */
+enum imx_rproc_method {
+	IMX_RPROC_NONE,
+	/* Through syscon regmap */
+	IMX_RPROC_MMIO,
+	/* Through ARM SMCCC */
+	IMX_RPROC_SMC,
+};
+
 struct imx_rproc_dcfg {
 	u32				src_reg;
 	u32				src_mask;
@@ -81,6 +90,7 @@ struct imx_rproc_dcfg {
 	u32				src_stop;
 	const struct imx_rproc_att	*att;
 	size_t				att_size;
+	enum imx_rproc_method		method;
 };
 
 struct imx_rproc {
@@ -183,6 +193,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx8mq,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mq),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
@@ -192,6 +203,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx7d,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7d),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
@@ -201,6 +213,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
 	.src_stop	= IMX6SX_M4_STOP,
 	.att		= imx_rproc_att_imx6sx,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx6sx),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static int imx_rproc_start(struct rproc *rproc)
@@ -560,19 +573,35 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
 
 static int imx_rproc_detect_mode(struct imx_rproc *priv)
 {
+	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct regmap *regmap;
 	int ret;
 	u32 val;
 
-	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
-	if (ret) {
-		dev_err(dev, "Failed to read src\n");
-		return ret;
+	if (dcfg->method != IMX_RPROC_MMIO)
+		return 0;
+
+	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "failed to find syscon\n");
+		return PTR_ERR(regmap);
 	}
 
-	if (!(val & dcfg->src_stop))
-		priv->rproc->state = RPROC_DETACHED;
+	priv->regmap = regmap;
+	regmap_attach_dev(dev, regmap, &config);
+
+	if (regmap) {
+		ret = regmap_read(regmap, dcfg->src_reg, &val);
+		if (ret) {
+			dev_err(dev, "Failed to read src\n");
+			return ret;
+		}
+
+		if (!(val & dcfg->src_stop))
+			priv->rproc->state = RPROC_DETACHED;
+	}
 
 	return 0;
 }
@@ -583,18 +612,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	struct device_node *np = dev->of_node;
 	struct imx_rproc *priv;
 	struct rproc *rproc;
-	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg;
-	struct regmap *regmap;
 	int ret;
 
-	regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
-	if (IS_ERR(regmap)) {
-		dev_err(dev, "failed to find syscon\n");
-		return PTR_ERR(regmap);
-	}
-	regmap_attach_dev(dev, regmap, &config);
-
 	/* set some other name then imx */
 	rproc = rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
 			    NULL, sizeof(*priv));
@@ -609,7 +629,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
 
 	priv = rproc->priv;
 	priv->rproc = rproc;
-	priv->regmap = regmap;
 	priv->dcfg = dcfg;
 	priv->dev = dev;
 
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:39 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:39 +0800
Subject: [PATCH V4 6/8] remoteproc: imx_rproc: make clk optional
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-7-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

To i.MX7ULP, M4 is the master to control everything, no need to provide
clk from Linux side. So make clk optional when method is IMX_RPROC_NONE.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 46 ++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 2b633fd..56dfcc1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -606,6 +606,35 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	return 0;
 }
 
+static int imx_rproc_clk_enable(struct imx_rproc *priv)
+{
+	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+	struct device *dev = priv->dev;
+	int ret;
+
+	/* Remote core is not under control of Linux */
+	if (dcfg->method == IMX_RPROC_NONE)
+		return 0;
+
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk)) {
+		dev_err(dev, "Failed to get clock\n");
+		return PTR_ERR(priv->clk);
+	}
+
+	/*
+	 * clk for M4 block including memory. Should be
+	 * enabled before .start for FW transfer.
+	 */
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(dev, "Failed to enable clock\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -654,22 +683,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_put_mbox;
 
-	priv->clk = devm_clk_get(dev, NULL);
-	if (IS_ERR(priv->clk)) {
-		dev_err(dev, "Failed to get clock\n");
-		ret = PTR_ERR(priv->clk);
-		goto err_put_mbox;
-	}
-
-	/*
-	 * clk for M4 block including memory. Should be
-	 * enabled before .start for FW transfer.
-	 */
-	ret = clk_prepare_enable(priv->clk);
-	if (ret) {
-		dev_err(&rproc->dev, "Failed to enable clock\n");
+	ret = imx_rproc_clk_enable(priv);
+	if (ret)
 		goto err_put_mbox;
-	}
 
 	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
 
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:40 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:40 +0800
Subject: [PATCH V4 7/8] remoteproc: imx_rproc: support i.MX7ULP
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-8-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
and powers most serivces used by A7 core, so A7 core has no power to
start and stop M4 core. And the M4 core's state is default RPROC_DETACHED
and remoteproc framework not able to stop the M4 core.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 56dfcc1..0592865 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -136,6 +136,14 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	{ 0x40000000, 0x40000000, 0x80000000, 0 },
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx7ulp[] = {
+	{0x1FFD0000, 0x1FFD0000, 0x30000, ATT_OWN},
+	{0x20000000, 0x20000000, 0x10000, ATT_OWN},
+	{0x2F000000, 0x2F000000, 0x20000, ATT_OWN},
+	{0x2F020000, 0x2F020000, 0x20000, ATT_OWN},
+	{0x60000000, 0x60000000, 0x40000000, 0}
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* OCRAM_S (M4 Boot code) - alias */
@@ -196,6 +204,12 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.method		= IMX_RPROC_MMIO,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx7ulp = {
+	.att		= imx_rproc_att_imx7ulp,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7ulp),
+	.method		= IMX_RPROC_NONE,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -238,6 +252,9 @@ static int imx_rproc_stop(struct rproc *rproc)
 	struct device *dev = priv->dev;
 	int ret;
 
+	if (dcfg->method == IMX_RPROC_NONE)
+		return -EOPNOTSUPP;
+
 	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
 				 dcfg->src_mask, dcfg->src_stop);
 	if (ret)
@@ -580,8 +597,13 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	int ret;
 	u32 val;
 
-	if (dcfg->method != IMX_RPROC_MMIO)
+	switch (dcfg->method) {
+	case IMX_RPROC_NONE:
+		priv->rproc->state = RPROC_DETACHED;
 		return 0;
+	default:
+		break;
+	}
 
 	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
 	if (IS_ERR(regmap)) {
@@ -726,6 +748,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id imx_rproc_of_match[] = {
+	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
 	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
-- 
2.7.4



From peng.fan at oss.nxp.com  Thu Apr 15 14:27:41 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Thu, 15 Apr 2021 21:27:41 +0800
Subject: [PATCH V4 8/8] remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618493261-32606-9-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
SMCCC to start/stop M core, not using regmap interface.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 87 ++++++++++++++++++++++++++++++++++++++----
 1 file changed, 80 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 0592865..0ff16e3 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2017 Pengutronix, Oleksij Rempel <kernel at pengutronix.de>
  */
 
+#include <linux/arm-smccc.h>
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
@@ -50,6 +51,11 @@
 
 #define IMX_RPROC_MEM_MAX		32
 
+#define IMX_SIP_RPROC			0xC2000005
+#define IMX_SIP_RPROC_START		0x00
+#define IMX_SIP_RPROC_STARTED		0x01
+#define IMX_SIP_RPROC_STOP		0x02
+
 /**
  * struct imx_rproc_mem - slim internal memory structure
  * @cpu_addr: MPU virtual address of the memory region
@@ -108,6 +114,36 @@ struct imx_rproc {
 	void __iomem			*rsc_table;
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx8mn[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* ITCM   */
+	{ 0x00000000, 0x007E0000, 0x00020000, ATT_OWN },
+	/* OCRAM_S */
+	{ 0x00180000, 0x00180000, 0x00009000, 0 },
+	/* OCRAM */
+	{ 0x00900000, 0x00900000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00920000, 0x00920000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00940000, 0x00940000, 0x00050000, 0 },
+	/* QSPI Code - alias */
+	{ 0x08000000, 0x08000000, 0x08000000, 0 },
+	/* DDR (Code) - alias */
+	{ 0x10000000, 0x40000000, 0x0FFE0000, 0 },
+	/* DTCM */
+	{ 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
+	/* OCRAM_S - alias */
+	{ 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20240000, 0x00940000, 0x00040000, ATT_OWN },
+	/* DDR (Data) */
+	{ 0x40000000, 0x40000000, 0x80000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCML - alias */
@@ -194,6 +230,12 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
 	{ 0x80000000, 0x80000000, 0x60000000, 0 },
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn = {
+	.att		= imx_rproc_att_imx8mn,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mn),
+	.method		= IMX_RPROC_SMC,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -235,12 +277,24 @@ static int imx_rproc_start(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_start);
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_start);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
 	if (ret)
-		dev_err(dev, "Failed to enable M4!\n");
+		dev_err(dev, "Failed to enable remote cores!\n");
 
 	return ret;
 }
@@ -250,15 +304,26 @@ static int imx_rproc_stop(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	if (dcfg->method == IMX_RPROC_NONE)
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_stop);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STOP, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		if (res.a1)
+			dev_info(dev, "Not in wfi, force stopped\n");
+		break;
+	default:
 		return -EOPNOTSUPP;
+	}
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_stop);
 	if (ret)
-		dev_err(dev, "Failed to stop M4!\n");
+		dev_err(dev, "Failed to stop remote cores\n");
 
 	return ret;
 }
@@ -594,6 +659,7 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
 	struct regmap *regmap;
+	struct arm_smccc_res res;
 	int ret;
 	u32 val;
 
@@ -601,6 +667,11 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	case IMX_RPROC_NONE:
 		priv->rproc->state = RPROC_DETACHED;
 		return 0;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STARTED, 0, 0, 0, 0, 0, 0, &res);
+		if (res.a0)
+			priv->rproc->state = RPROC_DETACHED;
+		return 0;
 	default:
 		break;
 	}
@@ -753,6 +824,8 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
 	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
+	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
+	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
-- 
2.7.4



From maz at kernel.org  Thu Apr 15 14:46:32 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 15 Apr 2021 14:46:32 +0100
Subject: [PATCH v3 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <7b5789fb-920d-e797-ba7a-49780bd3d587@huawei.com>
References: <20210414065109.8616-1-zhukeqian1@huawei.com>
 <20210414065109.8616-3-zhukeqian1@huawei.com>
 <87pmyxme2m.wl-maz@kernel.org>
 <b434317f-ef6d-1d91-0189-8343c404c88c@huawei.com>
 <87im4nn8wf.wl-maz@kernel.org>
 <7b5789fb-920d-e797-ba7a-49780bd3d587@huawei.com>
Message-ID: <87eefbmzif.wl-maz@kernel.org>

On Thu, 15 Apr 2021 12:26:26 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/15 18:23, Marc Zyngier wrote:
> > On Thu, 15 Apr 2021 03:20:52 +0100,
> > Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 2021/4/14 17:05, Marc Zyngier wrote:
> >>> + Santosh, who found some interesting bugs in that area before.
> >>>
> >>> On Wed, 14 Apr 2021 07:51:09 +0100,
> >>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >>>>
> >>>> The MMIO region of a device maybe huge (GB level), try to use
> >>>> block mapping in stage2 to speedup both map and unmap.
> >>>>
> >>>> Compared to normal memory mapping, we should consider two more
> >>>> points when try block mapping for MMIO region:
> >>>>
> >>>> 1. For normal memory mapping, the PA(host physical address) and
> >>>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> >>>> the HVA to request hugepage, so we don't need to consider PA
> >>>> alignment when verifing block mapping. But for device memory
> >>>> mapping, the PA and HVA may have different alignment.
> >>>>
> >>>> 2. For normal memory mapping, we are sure hugepage size properly
> >>>> fit into vma, so we don't check whether the mapping size exceeds
> >>>> the boundary of vma. But for device memory mapping, we should pay
> >>>> attention to this.
> >>>>
> >>>> This adds device_rough_page_shift() to check these two points when
> >>>> selecting block mapping size.
> >>>>
> >>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> >>>> ---
> >>>>  arch/arm64/kvm/mmu.c | 37 +++++++++++++++++++++++++++++++++----
> >>>>  1 file changed, 33 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> >>>> index c59af5ca01b0..1a6d96169d60 100644
> >>>> --- a/arch/arm64/kvm/mmu.c
> >>>> +++ b/arch/arm64/kvm/mmu.c
> >>>> @@ -624,6 +624,31 @@ static void kvm_send_hwpoison_signal(unsigned long address, short lsb)
> >>>>  	send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
> >>>>  }
> >>>>  
> >>>> +/*
> >>>> + * Find a max mapping size that properly insides the vma. And hva and pa must
> >>>> + * have the same alignment to this mapping size. It's rough as there are still
> >>>> + * other restrictions, will be checked by fault_supports_stage2_huge_mapping().
> >>>> + */
> >>>> +static short device_rough_page_shift(struct vm_area_struct *vma,
> >>>> +				     unsigned long hva)
> >>>
> >>> My earlier question still stands. Under which circumstances would this
> >>> function return something that is *not* the final mapping size? I
> >>> really don't see a reason why this would not return the final mapping
> >>> size.
> >>
> >> IIUC, all the restrictions are about alignment and area boundary.
> >>
> >> That's to say, HVA, IPA and PA must have same alignment within the
> >> mapping size.  And the areas are memslot and vma, which means the
> >> mapping size must properly fit into the memslot and vma.
> >>
> >> In this function, we just checked the alignment of HVA and PA, and
> >> the boundary of vma.  So we still need to check the alignment of HVA
> >> and IPA, and the boundary of memslot.  These will be checked by
> >> fault_supports_stage2_huge_mapping().
> > 
> > But that's no different from what we do with normal memory, is it? So
> > it really feels like we should have *one* function that deals with
> > establishing the basic mapping size from the VMA (see below for what I
> > have in mind).
> Right. And it looks better.
> 
> > 
> >>
> >>>
> >>>> +{
> >>>> +	phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> >>>> +
> >>>> +#ifndef __PAGETABLE_PMD_FOLDED
> >>>> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> >>>> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> >>>> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> >>>> +		return PUD_SHIFT;
> >>>> +#endif
> >>>> +
> >>>> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> >>>> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> >>>> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> >>>> +		return PMD_SHIFT;
> >>>> +
> >>>> +	return PAGE_SHIFT;
> >>>> +}
> >>>> +
> >>>>  static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
> >>>>  					       unsigned long hva,
> >>>>  					       unsigned long map_size)
> >>>> @@ -769,7 +794,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>>>  		return -EFAULT;
> >>>>  	}
> >>>>  
> >>>> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> >>>> +	/*
> >>>> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> >>>> +	 * get block mapping for device MMIO region.
> >>>> +	 */
> >>>>  	mmap_read_lock(current->mm);
> >>>>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
> >>>>  	if (unlikely(!vma)) {
> >>>> @@ -780,11 +808,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>>>  
> >>>>  	if (is_vm_hugetlb_page(vma))
> >>>>  		vma_shift = huge_page_shift(hstate_vma(vma));
> >>>> +	else if (vma->vm_flags & VM_PFNMAP)
> >>>> +		vma_shift = device_rough_page_shift(vma, hva);
> >>>
> >>> What prevents a VMA from having both VM_HUGETLB and VM_PFNMAP? This is
> >>> pretty unlikely, but I'd like to see this case catered for.
> >>>
> >> I'm not sure whether VM_HUGETLB and VM_PFNMAP are compatible, and I
> >> failed to find a case.
> >>
> >> VM_PFNMAP is used for page-ranges managed without "struct page",
> >> just pure PFN.  IIUC, VM_HUGETLB is used for hugetlbfs, which always
> >> has "struct page".  So I think they should not be compatible,
> >> otherwise it's a bug of driver.
> > 
> > For now, maybe. But huge mappings of PFN could land at some point, and
> > it'd be hard to catch. I think this case deserves a VM_BUG_ON().
> OK.
> 
> > 
> >>
> >>>>  	else
> >>>>  		vma_shift = PAGE_SHIFT;
> >>>>  
> >>>> -	if (logging_active ||
> >>>> -	    (vma->vm_flags & VM_PFNMAP)) {
> >>>> +	if (logging_active) {
> > 
> > BTW, don't you introduce a bug here? Logging shouldn't affect device
> > mappings.
> I think it's not a bug, because for memlsot with VM_PFNMAP, the
> logging_active is always false.
>
> In kvm_arch_prepare_memory_region(), we make sure
> KVM_MEM_LOG_DIRTY_PAGES can't be set for a VM_PFNMAP memslot.  Then
> in __kvm_set_memory_region(), we're sure dirty_bitmap is not
> allocated for this memslot.  Then memslot_is_logging() will return
> false for this memslot.

Fair enough. I think the first part is what makes it safe.

> 
> > 
> > 
> >>>>  		force_pte = true;
> >>>>  		vma_shift = PAGE_SHIFT;
> >>>>  	}
> >>>> @@ -855,7 +884,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>>>  
> >>>>  	if (kvm_is_device_pfn(pfn)) {
> >>>>  		device = true;
> >>>> -		force_pte = true;
> >>>> +		force_pte = (vma_pagesize == PAGE_SIZE);
> >>>
> >>> Why do we need to set force_pte if we are already dealing with
> >>> PAGE_SIZE? I guess you are doing this for the sake of avoiding the
> >>> call to transparent_hugepage_adjust(), right?
> >> Yes.
> >>
> >>>
> >>> I'd rather you simply don't try to upgrade a device mapping by
> >>> explicitly checking for this and keep force_pte for *memory*
> >>> exclusively.
> >> Agree, that's better.
> >>
> >>>
> >>> Santosh, can you please take a look at this series and try to see if
> >>> the problem you fixed in [1] (which ended up as commit 91a2c34b7d6f)
> >>> is still OK with this series?
> >> I searched the initial version[*], VM_PFNMAP is set when we call
> >> gfn_to_pfn_prot()->vma_mmio_fault()->remap_pfn_range().  Then the
> >> check of VM_PFNMAP in user_mem_abort() failed, so we will try to
> >> call transparent_hugepage_adjust() for device pfn.
> >>
> >> In that case, our logic of trying block mapping for MMIO is not
> >> used. And we still set force_pte for device pfn, so this bugfix is
> >> not affected. Santosh, do you agree that?
> > 
> > But isn't what we just agreed to get rid of just above?
> Yes, I agree to get rid of force_pte for device. I'm sure your code
> doesn't break the bugfix.
> 
> > 
> >>
> >> I still found that the reason vfio_pci does not have this
> >> bug. vfio_pci set VM_PFNMAP for vma when userspace calls mmap().  I
> >> will apply this logic for vfio_mdev too, let's see what vfio
> >> maintainer think about it.
> > 
> > I think that'd be good to see what Alex thinks about it...
> > 
> > Here's the changes I propose. It is completely untested, of course.
> > 
> > Thanks,
> > 
> > 	M.
> > 
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 8711894db8c2..f32d956cc199 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
> >  	return PAGE_SIZE;
> >  }
> >  
> > +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> > +{
> > +	unsigned long pa;
> > +
> > +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> > +		return huge_page_shift(hstate_vma(vma));
> > +
> > +	if (!(vma->vm_flags & VM_PFNMAP))
> > +		return PAGE_SHIFT;
> > +
> > +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> > +
> > +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> > +
> > +#ifndef __PAGETABLE_PMD_FOLDED
> > +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> > +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> > +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> > +		return PUD_SHIFT;
> > +#endif
> > +
> > +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> > +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> > +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> > +		return PMD_SHIFT;
> > +
> > +	return PAGE_SHIFT;
> > +}
> > +
> >  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  			  struct kvm_memory_slot *memslot, unsigned long hva,
> >  			  unsigned long fault_status)
> > @@ -778,13 +807,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  		return -EFAULT;
> >  	}
> >  
> > -	if (is_vm_hugetlb_page(vma))
> > -		vma_shift = huge_page_shift(hstate_vma(vma));
> > -	else
> > -		vma_shift = PAGE_SHIFT;
> > +	vma_shift = get_vma_page_shift(vma, hva);
> >  
> > -	if (logging_active ||
> > -	    (vma->vm_flags & VM_PFNMAP)) {
> > +	if (logging_active && !(vma->vm_flags & VM_PFNMAP)) {
> Maybe we don't need this. I can add some comments to explain it.

Yeah. Please add something along the lines of:

/* logging_active is guaranteed to never be true for VM_PFNMAP memslots */

> 
> >  		force_pte = true;
> >  		vma_shift = PAGE_SHIFT;
> >  	}
> > @@ -854,8 +879,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  		return -EFAULT;
> >  
> >  	if (kvm_is_device_pfn(pfn)) {
> > +		/*
> > +		 * If the page was identified as device early by looking at
> > +		 * the VMA flags, vma_pagesize is already representing the
> > +		 * largest quantity we can map.  If instead it was mapped
> > +		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> > +		 * and must not be upgraded.
> > +		 *
> > +		 * In both cases, we don't let transparent_hugepage_adjust()
> > +		 * change things at the last minute.
> > +		 */
> >  		device = true;
> > -		force_pte = true;
> >  	} else if (logging_active && !write_fault) {
> >  		/*
> >  		 * Only actually map the page as writable if this was a write
> > @@ -876,7 +910,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  	 * If we are not forced to use page mapping, check if we are
> >  	 * backed by a THP and thus use block mapping if possible.
> >  	 */
> > -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> > +	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
> >  		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
> >  							   &pfn, &fault_ipa);
> >  	if (writable)
> > 
> Looks good to me. :)
> 
> I will test it. And when I send v4, should I add your Suggested-by or SoB?

No need.

Thanks,

	M.

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


From peng.fan at oss.nxp.com  Thu Apr 15 14:47:46 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 15 Apr 2021 13:47:46 +0000
Subject: [PATCH V3 8/8] remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <20210413175235.GF750651@xps15>
References: <1617846898-13662-1-git-send-email-peng.fan@oss.nxp.com>
 <1617846898-13662-9-git-send-email-peng.fan@oss.nxp.com>
 <20210413175235.GF750651@xps15>
Message-ID: <DB6PR0402MB2760D408BAA2A781E02191B3884D9@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH V3 8/8] remoteproc: imx_rproc: support i.MX8MN/P

Hi Mathieu,

Your all comments are good suggestion in the patchset, I not reply your
comment one by one for each patch. In V4 patchset, hope I have fixed
all the issues you pointed.

Thanks for your reviewing.

Thanks,
Peng.

> 
> On Thu, Apr 08, 2021 at 09:54:58AM +0800, peng.fan at oss.nxp.com wrote:
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
> > SMCCC to start/stop M core, not using regmap interface.
> >
> > Signed-off-by: Peng Fan <peng.fan at nxp.com>
> > ---
> >  drivers/remoteproc/imx_rproc.c | 89
> > +++++++++++++++++++++++++++++++---
> >  1 file changed, 82 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/remoteproc/imx_rproc.c
> > b/drivers/remoteproc/imx_rproc.c index b911a7539897..9351626f09c0
> > 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -3,6 +3,7 @@
> >   * Copyright (c) 2017 Pengutronix, Oleksij Rempel
> <kernel at pengutronix.de>
> >   */
> >
> > +#include <linux/arm-smccc.h>
> >  #include <linux/clk.h>
> >  #include <linux/err.h>
> >  #include <linux/interrupt.h>
> > @@ -50,6 +51,11 @@
> >
> >  #define IMX_RPROC_MEM_MAX		32
> >
> > +#define IMX_SIP_RPROC			0xC2000005
> > +#define IMX_SIP_RPROC_START		0x00
> > +#define IMX_SIP_RPROC_STARTED		0x01
> > +#define IMX_SIP_RPROC_STOP		0x02
> > +
> >  /**
> >   * struct imx_rproc_mem - slim internal memory structure
> >   * @cpu_addr: MPU virtual address of the memory region @@ -119,6
> > +125,36 @@ struct imx_rproc {
> >  	enum imx_rproc_mode		mode;
> >  };
> >
> > +static const struct imx_rproc_att imx_rproc_att_imx8mn[] = {
> > +	/* dev addr , sys addr  , size	    , flags */
> > +	/* ITCM   */
> > +	{ 0x00000000, 0x007E0000, 0x00020000, ATT_OWN },
> > +	/* OCRAM_S */
> > +	{ 0x00180000, 0x00180000, 0x00009000, 0 },
> > +	/* OCRAM */
> > +	{ 0x00900000, 0x00900000, 0x00020000, 0 },
> > +	/* OCRAM */
> > +	{ 0x00920000, 0x00920000, 0x00020000, 0 },
> > +	/* OCRAM */
> > +	{ 0x00940000, 0x00940000, 0x00050000, 0 },
> > +	/* QSPI Code - alias */
> > +	{ 0x08000000, 0x08000000, 0x08000000, 0 },
> > +	/* DDR (Code) - alias */
> > +	{ 0x10000000, 0x40000000, 0x0FFE0000, 0 },
> > +	/* DTCM */
> > +	{ 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
> > +	/* OCRAM_S - alias */
> > +	{ 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
> > +	/* OCRAM */
> > +	{ 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
> > +	/* OCRAM */
> > +	{ 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
> > +	/* OCRAM */
> > +	{ 0x20240000, 0x00940000, 0x00040000, ATT_OWN },
> > +	/* DDR (Data) */
> > +	{ 0x40000000, 0x40000000, 0x80000000, 0 }, };
> > +
> >  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> >  	/* dev addr , sys addr  , size	    , flags */
> >  	/* TCML - alias */
> > @@ -205,6 +241,12 @@ static const struct imx_rproc_att
> imx_rproc_att_imx6sx[] = {
> >  	{ 0x80000000, 0x80000000, 0x60000000, 0 },  };
> >
> > +static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn = {
> > +	.att		= imx_rproc_att_imx8mn,
> > +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mn),
> > +	.method		= IMX_RPROC_SMC,
> > +};
> > +
> >  static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
> >  	.src_reg	= IMX7D_SRC_SCR,
> >  	.src_mask	= IMX7D_M4_RST_MASK,
> > @@ -246,12 +288,24 @@ static int imx_rproc_start(struct rproc *rproc)
> >  	struct imx_rproc *priv = rproc->priv;
> >  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> >  	struct device *dev = priv->dev;
> > +	struct arm_smccc_res res;
> >  	int ret;
> >
> > -	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> > -				 dcfg->src_mask, dcfg->src_start);
> > +	switch (dcfg->method) {
> > +	case IMX_RPROC_MMIO:
> > +		ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> dcfg->src_mask,
> > +					 dcfg->src_start);
> > +		break;
> > +	case IMX_RPROC_SMC:
> > +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0,
> 0, 0, 0, &res);
> > +		ret = res.a0;
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> >  	if (ret)
> > -		dev_err(dev, "Failed to enable M4!\n");
> > +		dev_err(dev, "Failed to enable remote cores!\n");
> >
> >  	return ret;
> >  }
> > @@ -261,12 +315,26 @@ static int imx_rproc_stop(struct rproc *rproc)
> >  	struct imx_rproc *priv = rproc->priv;
> >  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> >  	struct device *dev = priv->dev;
> > +	struct arm_smccc_res res;
> >  	int ret;
> >
> > -	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> > -				 dcfg->src_mask, dcfg->src_stop);
> > +	switch (dcfg->method) {
> > +	case IMX_RPROC_MMIO:
> > +		ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
> dcfg->src_mask,
> > +					 dcfg->src_stop);
> > +		break;
> > +	case IMX_RPROC_SMC:
> > +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STOP, 0, 0, 0, 0,
> 0, 0, &res);
> > +		ret = res.a0;
> > +		if (res.a1)
> > +			dev_info(dev, "Not in wfi, force stopped\n");
> > +		break;
> > +	default:
> > +		return -EOPNOTSUPP;
> > +	}
> > +
> >  	if (ret)
> > -		dev_err(dev, "Failed to stop M4!\n");
> > +		dev_err(dev, "Failed to stop remote cores\n");
> >
> >  	return ret;
> >  }
> > @@ -600,6 +668,7 @@ static int imx_rproc_detect_mode(struct imx_rproc
> > *priv)  {
> >  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> >  	struct device *dev = priv->dev;
> > +	struct arm_smccc_res res;
> >  	int ret;
> >  	u32 val;
> >
> > @@ -616,8 +685,12 @@ static int imx_rproc_detect_mode(struct
> imx_rproc *priv)
> >  			priv->mode = IMX_RPROC_EARLY_BOOT;
> >  	}
> >
> > -	if (dcfg->method == IMX_RPROC_NONE)
> > +	if (dcfg->method == IMX_RPROC_NONE) {
> >  		priv->mode = IMX_RPROC_EARLY_BOOT;
> > +	} else if (dcfg->method == IMX_RPROC_SMC) {
> > +		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STARTED, 0, 0,
> 0, 0, 0, 0, &res);
> > +		priv->mode = res.a0 ? IMX_RPROC_EARLY_BOOT :
> IMX_RPROC_NORMAL;
> > +	}
> 
> When all patches have been applied this function is really hard to read.  I
> suggest using a switch() statement like you did in imx_rproc_start() and
> imx_rproc_stop().
> 
> Thanks,
> Mathieu
> 
> >
> >  	if (priv->mode == IMX_RPROC_EARLY_BOOT)
> >  		priv->rproc->state = RPROC_DETACHED; @@ -747,6 +820,8 @@
> static
> > const struct of_device_id imx_rproc_of_match[] = {
> >  	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
> >  	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
> >  	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
> > +	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
> > +	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
> >  	{},
> >  };
> >  MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
> > --
> > 2.30.0
> >


From joro at 8bytes.org  Thu Apr 15 14:48:38 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 15 Apr 2021 15:48:38 +0200
Subject: [PATCH 1/2] iommu/mediatek-v1: Avoid build fail when build as
 module
In-Reply-To: <20210412064843.11614-1-yong.wu@mediatek.com>
References: <20210412064843.11614-1-yong.wu@mediatek.com>
Message-ID: <YHhENs5Jh5h0Pz+r@8bytes.org>

On Mon, Apr 12, 2021 at 02:48:42PM +0800, Yong Wu wrote:
> When this driver build as module, It build fail like:
> 
> ERROR: modpost: "of_phandle_iterator_args"
> [drivers/iommu/mtk_iommu_v1.ko] undefined!
> 
> This patch remove this interface to avoid this build fail.
> 
> Reported-by: Valdis Kletnieks <valdis.kletnieks at vt.edu>
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> ---
> Currently below patch is only in linux-next-20210409. This fixes tag may be
> not needed. we can add this if it is need.
> Fixes: 8de000cf0265 ("iommu/mediatek-v1: Allow building as module")
> ---
>  drivers/iommu/mtk_iommu_v1.c | 62 ++++++++++++++++--------------------
>  1 file changed, 28 insertions(+), 34 deletions(-)

Applied both, thanks.


From maz at kernel.org  Thu Apr 15 14:49:30 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 15 Apr 2021 14:49:30 +0100
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile
 helpers
In-Reply-To: <da73e0c7-4dd7-ce69-3304-3da8f1521127@huawei.com>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-2-maz@kernel.org>
 <baa268cf-c92d-6b97-da4c-e7da2a9ccb7a@huawei.com>
 <87h7k7n81z.wl-maz@kernel.org>
 <da73e0c7-4dd7-ce69-3304-3da8f1521127@huawei.com>
Message-ID: <87czuvmzdh.wl-maz@kernel.org>

On Thu, 15 Apr 2021 12:34:40 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/15 18:42, Marc Zyngier wrote:
> > On Thu, 15 Apr 2021 07:59:26 +0100,
> > Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 2021/4/14 21:44, Marc Zyngier wrote:
> >>> KVM/arm64 is the sole user of perf_num_counters(), and really
> >>> could do without it. Stop using the obsolete API by relying on
> >>> the existing probing code.
> >>>
> >>> Signed-off-by: Marc Zyngier <maz at kernel.org>
> >>> ---
> >>>  arch/arm64/kvm/perf.c     | 7 +------
> >>>  arch/arm64/kvm/pmu-emul.c | 2 +-
> >>>  include/kvm/arm_pmu.h     | 4 ++++
> >>>  3 files changed, 6 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> >>> index 739164324afe..b8b398670ef2 100644
> >>> --- a/arch/arm64/kvm/perf.c
> >>> +++ b/arch/arm64/kvm/perf.c
> >>> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
> >>>  
> >>>  int kvm_perf_init(void)
> >>>  {
> >>> -	/*
> >>> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> >>> -	 * hardware performance counters. This could ensure the presence of
> >>> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> >>> -	 */
> >>> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> >>> +	if (kvm_pmu_probe_pmuver() != 0xf)
> >> The probe() function may be called many times
> >> (kvm_arm_pmu_v3_set_attr also calls it).  I don't know whether the
> >> first calling is enough. If so, can we use a static variable in it,
> >> so the following calling can return the result right away?
> > 
> > No, because that wouldn't help with crappy big-little implementations
> > that could have PMUs with different versions. We want to find the
> > version at the point where the virtual PMU is created, which is why we
> > call the probe function once per vcpu.
> I see.
> 
> But AFAICS the pmuver is placed in kvm->arch, and the probe function is called
> once per VM. Maybe I miss something.

You're right, I mis-remembered. This doesn't change much though.

Thanks,

	M.

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


From catalin.marinas at arm.com  Thu Apr 15 15:02:25 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 15:02:25 +0100
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn,endif}
In-Reply-To: <YHg+5RSG4XPLlZD8@archlinux-ax161>
References: <20210414000803.662534-1-nathan@kernel.org>
 <20210415091743.GB1015@arm.com> <YHg+5RSG4XPLlZD8@archlinux-ax161>
Message-ID: <20210415140224.GE1015@arm.com>

On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > > set atomically"), LLVM's integrated assembler fails to build entry.S:
> > > 
> > > <instantiation>:5:7: error: expected assembly-time absolute expression
> > >  .org . - (664b-663b) + (662b-661b)
> > >       ^
> > > <instantiation>:6:7: error: expected assembly-time absolute expression
> > >  .org . - (662b-661b) + (664b-663b)
> > >       ^
> > 
> > I tried the latest Linus' tree and linux-next (defconfig) with this
> > commit in and I can't get your build error. I used both clang-10 from
> > Debian stable and clang-11 from Debian sid. So, which clang version did
> > you use or which kernel config options?
> 
> Interesting, this reproduces for me with LLVM 12 or newer with just
> defconfig.

It fails for me as well with clang-12. Do you happen to know why it
works fine with previous clang versions?

-- 
Catalin


From lokeshvutla at ti.com  Thu Apr 15 15:02:28 2021
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Thu, 15 Apr 2021 19:32:28 +0530
Subject: [PATCH] dt-bindings: mailbox: ti, message-manager: Convert to yaml
In-Reply-To: <20210414002721.23638-1-nm@ti.com>
References: <20210414002721.23638-1-nm@ti.com>
Message-ID: <e649b712-071b-0287-a1bc-2de422806619@ti.com>

[..snip..]

> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
> new file mode 100644
> index 000000000000..4987e803ac37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments' Message Manager Driver

Driver is not the right word here. Can you change it to node?

Thanks and regards,
Lokesh



From zhukeqian1 at huawei.com  Thu Apr 15 15:03:26 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 22:03:26 +0800
Subject: [PATCH v4 0/2] kvm/arm64: Try stage2 block mapping for host device
 MMIO
Message-ID: <20210415140328.24200-1-zhukeqian1@huawei.com>

Hi,

We have two pathes to build stage2 mapping for MMIO regions.

Create time's path and stage2 fault path.

Patch#1 removes the creation time's mapping of MMIO regions
Patch#2 tries stage2 block mapping for host device MMIO at fault path

Changelog:

v4:
 - use get_vma_page_shift() handle all cases. (Marc)
 - get rid of force_pte for device mapping. (Marc)

v3:
 - Do not need to check memslot boundary in device_rough_page_shift(). (Marc)

Thanks,
Keqian


Keqian Zhu (2):
  kvm/arm64: Remove the creation time's mapping of MMIO regions
  kvm/arm64: Try stage2 block mapping for host device MMIO

 arch/arm64/kvm/mmu.c | 99 ++++++++++++++++++++++++--------------------
 1 file changed, 54 insertions(+), 45 deletions(-)

-- 
2.19.1



From zhukeqian1 at huawei.com  Thu Apr 15 15:03:27 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 22:03:27 +0800
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of MMIO
 regions
In-Reply-To: <20210415140328.24200-1-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
Message-ID: <20210415140328.24200-2-zhukeqian1@huawei.com>

The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.

Remove the mapping code while keep the useful sanity check.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
 1 file changed, 3 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..c59af5ca01b0 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 {
 	hva_t hva = mem->userspace_addr;
 	hva_t reg_end = hva + mem->memory_size;
-	bool writable = !(mem->flags & KVM_MEM_READONLY);
 	int ret = 0;
 
 	if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
@@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 	mmap_read_lock(current->mm);
 	/*
 	 * A memory region could potentially cover multiple VMAs, and any holes
-	 * between them, so iterate over all of them to find out if we can map
-	 * any of them right now.
+	 * between them, so iterate over all of them.
 	 *
 	 *     +--------------------------------------------+
 	 * +---------------+----------------+   +----------------+
@@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 	 */
 	do {
 		struct vm_area_struct *vma = find_vma(current->mm, hva);
-		hva_t vm_start, vm_end;
 
 		if (!vma || vma->vm_start >= reg_end)
 			break;
 
-		/*
-		 * Take the intersection of this VMA with the memory region
-		 */
-		vm_start = max(hva, vma->vm_start);
-		vm_end = min(reg_end, vma->vm_end);
-
 		if (vma->vm_flags & VM_PFNMAP) {
-			gpa_t gpa = mem->guest_phys_addr +
-				    (vm_start - mem->userspace_addr);
-			phys_addr_t pa;
-
-			pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
-			pa += vm_start - vma->vm_start;
-
 			/* IO region dirty page logging not allowed */
 			if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
 				ret = -EINVAL;
-				goto out;
-			}
-
-			ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
-						    vm_end - vm_start,
-						    writable);
-			if (ret)
 				break;
+			}
 		}
-		hva = vm_end;
+		hva = min(reg_end, vma->vm_end);
 	} while (hva < reg_end);
 
-	if (change == KVM_MR_FLAGS_ONLY)
-		goto out;
-
-	spin_lock(&kvm->mmu_lock);
-	if (ret)
-		unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
-	else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
-		stage2_flush_memslot(kvm, memslot);
-	spin_unlock(&kvm->mmu_lock);
-out:
 	mmap_read_unlock(current->mm);
 	return ret;
 }
-- 
2.19.1



From zhukeqian1 at huawei.com  Thu Apr 15 15:03:28 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 22:03:28 +0800
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host device
 MMIO
In-Reply-To: <20210415140328.24200-1-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
Message-ID: <20210415140328.24200-3-zhukeqian1@huawei.com>

The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.

Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:

1. For normal memory mapping, the PA(host physical address) and
HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
the HVA to request hugepage, so we don't need to consider PA
alignment when verifing block mapping. But for device memory
mapping, the PA and HVA may have different alignment.

2. For normal memory mapping, we are sure hugepage size properly
fit into vma, so we don't check whether the mapping size exceeds
the boundary of vma. But for device memory mapping, we should pay
attention to this.

This adds get_vma_page_shift() to get page shift for both normal
memory and device MMIO region, and check these two points when
selecting block mapping size for MMIO region.

Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
---
 arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 51 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index c59af5ca01b0..5a1cc7751e6d 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
 	return PAGE_SIZE;
 }
 
+static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
+{
+	unsigned long pa;
+
+	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
+		return huge_page_shift(hstate_vma(vma));
+
+	if (!(vma->vm_flags & VM_PFNMAP))
+		return PAGE_SHIFT;
+
+	VM_BUG_ON(is_vm_hugetlb_page(vma));
+
+	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
+
+#ifndef __PAGETABLE_PMD_FOLDED
+	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
+		return PUD_SHIFT;
+#endif
+
+	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
+	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
+	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
+		return PMD_SHIFT;
+
+	return PAGE_SHIFT;
+}
+
 static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 			  struct kvm_memory_slot *memslot, unsigned long hva,
 			  unsigned long fault_status)
@@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 	}
 
-	/* Let's check if we will get back a huge page backed by hugetlbfs */
+	/*
+	 * Let's check if we will get back a huge page backed by hugetlbfs, or
+	 * get block mapping for device MMIO region.
+	 */
 	mmap_read_lock(current->mm);
 	vma = find_vma_intersection(current->mm, hva, hva + 1);
 	if (unlikely(!vma)) {
@@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 	}
 
-	if (is_vm_hugetlb_page(vma))
-		vma_shift = huge_page_shift(hstate_vma(vma));
-	else
-		vma_shift = PAGE_SHIFT;
-
-	if (logging_active ||
-	    (vma->vm_flags & VM_PFNMAP)) {
+	/*
+	 * logging_active is guaranteed to never be true for VM_PFNMAP
+	 * memslots.
+	 */
+	if (logging_active) {
 		force_pte = true;
 		vma_shift = PAGE_SHIFT;
+	} else {
+		vma_shift = get_vma_page_shift(vma, hva);
 	}
 
 	switch (vma_shift) {
@@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		return -EFAULT;
 
 	if (kvm_is_device_pfn(pfn)) {
+		/*
+		 * If the page was identified as device early by looking at
+		 * the VMA flags, vma_pagesize is already representing the
+		 * largest quantity we can map.  If instead it was mapped
+		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
+		 * and must not be upgraded.
+		 *
+		 * In both cases, we don't let transparent_hugepage_adjust()
+		 * change things at the last minute.
+		 */
 		device = true;
-		force_pte = true;
 	} else if (logging_active && !write_fault) {
 		/*
 		 * Only actually map the page as writable if this was a write
@@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	 * If we are not forced to use page mapping, check if we are
 	 * backed by a THP and thus use block mapping if possible.
 	 */
-	if (vma_pagesize == PAGE_SIZE && !force_pte)
+	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
 		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
 							   &pfn, &fault_ipa);
 	if (writable)
-- 
2.19.1



From fercerpav at gmail.com  Thu Apr 15 15:05:00 2021
From: fercerpav at gmail.com (Paul Fertser)
Date: Thu, 15 Apr 2021 17:05:00 +0300
Subject: [PATCH] arm: dts: aspeed: tiogapass: add hotplug controller
Message-ID: <20210415140521.11352-1-fercerpav@gmail.com>

The ADM1278 IC is accessible on I2C bus and on both Wiwynn and Quanta
Tioga Pass implementations a pair of parallel 0.5 mOhm resistors is used
for current measurement.

Signed-off-by: Paul Fertser <fercerpav at gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
index 3cc2004fa2f2..500661956dea 100644
--- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
@@ -591,6 +591,11 @@
 &i2c7 {
 	status = "okay";
 	//HSC, AirMax Conn A
+	adm1278 at 0x45 {
+		compatible = "adm1275";
+		reg = <0x45>;
+		shunt-resistor-micro-ohms = <250>;
+	};
 };
 
 &i2c8 {
-- 
2.17.1



From zhukeqian1 at huawei.com  Thu Apr 15 15:08:09 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 15 Apr 2021 22:08:09 +0800
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <20210415140328.24200-3-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
Message-ID: <8f55b64f-b4dd-700e-c997-8de9c5ea282f@huawei.com>

Hi Marc,

On 2021/4/15 22:03, Keqian Zhu wrote:
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
> 
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
> 
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
> 
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
> 
> This adds get_vma_page_shift() to get page shift for both normal
> memory and device MMIO region, and check these two points when
> selecting block mapping size for MMIO region.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>  arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 51 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..5a1cc7751e6d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>  	return PAGE_SIZE;
>  }
>  
> +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> +{
> +	unsigned long pa;
> +
> +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> +		return huge_page_shift(hstate_vma(vma));
> +
> +	if (!(vma->vm_flags & VM_PFNMAP))
> +		return PAGE_SHIFT;
> +
> +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> +
> +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +
>  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  			  struct kvm_memory_slot *memslot, unsigned long hva,
>  			  unsigned long fault_status)
> @@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  	}
>  
> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> +	/*
> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> +	 * get block mapping for device MMIO region.
> +	 */
>  	mmap_read_lock(current->mm);
>  	vma = find_vma_intersection(current->mm, hva, hva + 1);
>  	if (unlikely(!vma)) {
> @@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  	}
>  
> -	if (is_vm_hugetlb_page(vma))
> -		vma_shift = huge_page_shift(hstate_vma(vma));
> -	else
> -		vma_shift = PAGE_SHIFT;
> -
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	/*
> +	 * logging_active is guaranteed to never be true for VM_PFNMAP
> +	 * memslots.
> +	 */
> +	if (logging_active) {
>  		force_pte = true;
>  		vma_shift = PAGE_SHIFT;
> +	} else {
> +		vma_shift = get_vma_page_shift(vma, hva);
>  	}
I use a if/else manner in v4, please check that. Thanks very much!


BRs,
Keqian

>  
>  	switch (vma_shift) {
> @@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  		return -EFAULT;
>  
>  	if (kvm_is_device_pfn(pfn)) {
> +		/*
> +		 * If the page was identified as device early by looking at
> +		 * the VMA flags, vma_pagesize is already representing the
> +		 * largest quantity we can map.  If instead it was mapped
> +		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> +		 * and must not be upgraded.
> +		 *
> +		 * In both cases, we don't let transparent_hugepage_adjust()
> +		 * change things at the last minute.
> +		 */
>  		device = true;
> -		force_pte = true;
>  	} else if (logging_active && !write_fault) {
>  		/*
>  		 * Only actually map the page as writable if this was a write
> @@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	 * If we are not forced to use page mapping, check if we are
>  	 * backed by a THP and thus use block mapping if possible.
>  	 */
> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> +	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
>  		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>  							   &pfn, &fault_ipa);
>  	if (writable)
> 


From nm at ti.com  Thu Apr 15 15:13:21 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 15 Apr 2021 09:13:21 -0500
Subject: [PATCH] dt-bindings: mailbox: ti, message-manager: Convert to yaml
In-Reply-To: <e649b712-071b-0287-a1bc-2de422806619@ti.com>
References: <20210414002721.23638-1-nm@ti.com>
 <e649b712-071b-0287-a1bc-2de422806619@ti.com>
Message-ID: <20210415141321.fbzzjgwpavoggpqh@endless>

On 19:32-20210415, Lokesh Vutla wrote:
> [..snip..]
> 
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
> > new file mode 100644
> > index 000000000000..4987e803ac37
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
> > @@ -0,0 +1,75 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Texas Instruments' Message Manager Driver
> 
> Driver is not the right word here. Can you change it to node?


Indeed, thanks. v2 incoming. I also noticed a commit message typo while
at it.

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


From james.clark at arm.com  Thu Apr 15 15:13:36 2021
From: james.clark at arm.com (James Clark)
Date: Thu, 15 Apr 2021 17:13:36 +0300
Subject: [PATCH v4 1/6] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <20210412091006.468557-2-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-2-leo.yan@linaro.org>
Message-ID: <882e13d1-c793-88c6-0b1e-629462fb99ac@arm.com>



On 12/04/2021 12:10, Leo Yan wrote:
> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.

Hi Leo,

I think this causes an error when attempting to open a newly recorded file
with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here:

	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
	struct perf_record_time_conv *tc = &session->time_conv;
	struct arm_spe *spe;
	int err;

	if (auxtrace_info->header.size < sizeof(struct perf_record_auxtrace_info) +
					min_sz)
		return -EINVAL;

And removing ARM_SPE_PER_CPU_MMAPS changes the value of ARM_SPE_AUXTRACE_PRIV_MAX.

At least I think that's what's causing the problem. I get this error:

	./perf report -i per-thread-spe-time.data
	0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
	Error:
	failed to process sample
	# To display the perf.data header info, please use --header/--header-only options.
	#

James

> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  tools/perf/util/arm-spe.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/perf/util/arm-spe.h b/tools/perf/util/arm-spe.h
> index 98d3235781c3..105ce0ea0a01 100644
> --- a/tools/perf/util/arm-spe.h
> +++ b/tools/perf/util/arm-spe.h
> @@ -11,7 +11,6 @@
>  
>  enum {
>  	ARM_SPE_PMU_TYPE,
> -	ARM_SPE_PER_CPU_MMAPS,
>  	ARM_SPE_AUXTRACE_PRIV_MAX,
>  };
>  
> 


From nm at ti.com  Thu Apr 15 15:19:09 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 15 Apr 2021 09:19:09 -0500
Subject: [PATCH V2] dt-bindings: mailbox: ti,
 message-manager: Convert to json schema
Message-ID: <20210415141909.3013-1-nm@ti.com>

Convert the ti,message-manager to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
  tisci node definition
- included header in example for buildable example

NOTE: The following checkpatch warning is generated since we do include
the header in the example, but this is a false positive warning.
  WARNING: DT binding docs and includes should be a separate patch. See:
  Documentation/devicetree/bindings/submitting-patches.rst

Signed-off-by: Nishanth Menon <nm at ti.com>
---
Changes since v1:
 - Fixed title in yaml (not driver)
 - Commit message update to fix up a copy paste error (not secure-proxy).
 - Subject line rewording to indicate json schema rather than yaml -
   more inline with patches elsewhere.

V1: https://lore.kernel.org/linux-arm-kernel/20210414002721.23638-1-nm at ti.com/
 .../bindings/mailbox/ti,message-manager.txt   | 50 -------------
 .../bindings/mailbox/ti,message-manager.yaml  | 75 +++++++++++++++++++
 2 files changed, 75 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
deleted file mode 100644
index ebf0e3710cee..000000000000
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Message Manager Driver
-========================================
-
-The Texas Instruments' Message Manager is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The Message
-manager is broken up into queues in different address regions that are called
-"proxies" - each instance is unidirectional and is instantiated at SoC
-integration level to indicate receive or transmit path.
-
-Message Manager Device Node:
-===========================
-Required properties:
---------------------
-- compatible:		Shall be: "ti,k2g-message-manager"
-- reg-names 		queue_proxy_region - Map the queue proxy region.
-			queue_state_debug_region - Map the queue state debug
-			region.
-- reg:			Contains the register map per reg-names.
-- #mbox-cells		Shall be 2. Contains the queue ID and proxy ID in that
-		        order referring to the transfer path.
-- interrupt-names:	Contains interrupt names matching the rx transfer path
-			for a given SoC. Receive interrupts shall be of the
-			format: "rx_<QID>".
-			For ti,k2g-message-manager, this shall contain:
-				"rx_005", "rx_057"
-- interrupts:		Contains the interrupt information corresponding to
-			interrupt-names property.
-
-Example(K2G):
-------------
-
-	msgmgr: msgmgr at 2a00000 {
-		compatible = "ti,k2g-message-manager";
-		#mbox-cells = <2>;
-		reg-names = "queue_proxy_region", "queue_state_debug_region";
-		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
-		interrupt-names = "rx_005", "rx_057";
-		interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
-			     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
-	};
-
-	pmmc: pmmc {
-		[...]
-		mbox-names = "rx", "tx";
-		# RX queue ID is 5, proxy ID is 2
-		# TX queue ID is 0, proxy ID is 0
-		mboxes= <&msgmgr 5 2>,
-			<&msgmgr 0 0>;
-		[...]
-	};
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
new file mode 100644
index 000000000000..1cbf9a75522e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' message manager node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  The Texas Instruments' Message Manager is a mailbox controller that has
+  configurable queues selectable at SoC(System on Chip) integration. The Message
+  manager is broken up into queues in different address regions that are called
+  "proxies" - each instance is unidirectional and is instantiated at SoC
+  integration level to indicate receive or transmit path.
+
+properties:
+  $nodename:
+    pattern: "^mailbox@[0-9a-f]+$"
+
+  compatible:
+    const: ti,k2g-message-manager
+
+  "#mbox-cells":
+    const: 2
+    description:
+      Contains the queue ID and proxy ID in that order referring to the
+      transfer path.
+
+  reg-names:
+    items:
+      - const: queue_proxy_region
+      - const: queue_state_debug_region
+
+  reg:
+    minItems: 2
+
+  interrupt-names:
+    items:
+      - const: rx_005
+      - const: rx_057
+    description:
+      Contains interrupt names matching the Rx transfer path for a given SoC.
+      Receive interrupts shall be of the format "rx_<QID>".
+
+  interrupts:
+    minItems: 2
+    description:
+      Contains the interrupt information for the Rx interrupt paths for message
+      manager corresponding to the interrupt-names.
+
+required:
+  - compatible
+  - reg-names
+  - reg
+  - interrupt-names
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    msgmgr: mailbox at 2a00000 {
+          compatible = "ti,k2g-message-manager";
+          #mbox-cells = <2>;
+          reg-names = "queue_proxy_region", "queue_state_debug_region";
+          reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
+          interrupt-names = "rx_005", "rx_057";
+          interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+                       <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
+    };
-- 
2.31.0



From narmstrong at baylibre.com  Thu Apr 15 15:28:39 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 15 Apr 2021 16:28:39 +0200
Subject: 2021 Amlogic SoCs Features Status
Message-ID: <f13f7006-2d0c-40c7-cea6-03b5190fd106@baylibre.com>

I'd like to summarize the actual missing & broken features on all Amlogic SoCs,
because (this month) is the 4th anniversary of the HDMI support on Amlogic SoC,
but not only.

A lot of people are asking about the status on multimedia & display features,
this would help understanding what's missing.

I would like to thanks all the contributors (code, test, bug reports, ...) for the last
4,5 years !

But first, I would like to list what's working and stable : (you can find more details on http://linux-meson.com/)

# Display
DRM/KMS Atomic Driver
CVBS i480/i576
HDMI 2.0a up to 4k60 with 444/420 support
OSD with multiple plane formats supported
Video with multiple plane formats supported + compressed video formats from the decoder
HDMI CEC
GPU (Lima for GXBB/GXL, Panfrost for GXM/G12A/G12B/SM1)

# Multimedia
GE2D Accelerator for plane rotation and format transform
MPEG-2, H264, VP9 decoder (up to 4k for vp9)

# Audio
I2S, SPDIF In/Out TDM interfaces support
I2S/SPDIF feeding to HDMI support
AXG/G12A/G12B/SM1 advanced audio routing features supported

# System
CCF Clock support
SCPI DVFS
Thermal
Power Domains
SoC identification
eMMC up to HS200/SDCard/SDIO support
NAND flash support
PCIe support
USB2/3.0 SuperSpeed + Gadget/OTG

# Misc
MIPI DSI PHY support
RTC on pre-GXBB
vRTC to support suspend wakeup
I2C up to 400KHz
SPI for SPI NOR Flash
SPI for general purpose SPI
User eFuses
ADCs
HW Crypto Engine
Internal Clock Measuring
PWM
Infrared Decoding

This makes it an usable system without advanced multimedia features.
You can find very recent Desktop Armbian images running on the Odroid-N2(+)
running very decently, and build Upstream AOSP on the now reference boards
Khadas VIM3/VIM3L.

And U-boot has almost the same support status, see:
https://u-boot.readthedocs.io/en/latest/board/amlogic/index.html

Now what/s missing/broken.

# Families

## All Families

### Display
Missing:
 - 10/12-bit HDMI Output
Plumbing is there, only needs clock generation setup and understand how to switch to 10/12bits...

 - HDMI 4:2:0 Output
Plumbing is there, only needs mode setup and testing

 - Cursor Plane support
More complex, would need refactor so support updating the cursor plane manually when in interlaced mode

 - Second Video plane support
 - HDR Transformations
Needs documentation

 - Parallel Video output
 - Picture post-processing
Needs documentation

### Multimedia
Missing:
 - MPEG-4/2/1/JPEG Decoder
 - H264 Encoder
 - JPEG Encoder
 - DVB TS Interface
 - HDMI Audio via S/PDIF

### Misc
Missing:
 - Smart Card reader
 - I2C Slave
 - HW IR decoder support
 - DMA support for SPICC
 - USB OTG

## Meson6 / Meson8 / Meson8b

I'll let martin elaborate on that, but it seems the biggest missing bits are Display, Video Decoder & Encoder support.

## GXBB

### Audio
Broken:
Multiple issues are reported with the Mainline AIU driver:
 - "Machine Gun Noise"
 - 5-8 second dropouts
 - unable to play 48KHz audio on GXBB
 - channels are messed up in both AIU/AXG when playing 5.1+

### Display
Missing:
 - Secure Video Path
 - HDCP2

### Multimedia
Missing:
 - HEVC Decoder
 - GE2D
Driver exists, but must be adapted

Broken:
 - H264 Decoder needs some fixup to be stable (Seeking, ...)

## GXL/GXM

### Audio
Broken:
Multiple issues are reported with the Mainline AIU driver:
 - "Machine Gun Noise"
 - 5-8 second dropouts
 - channels are messed up in both AIU/AXG when playing 5.1+

### Display
Missing:
 - Secure Video Path
 - HDCP2

### Multimedia
Missing:
 - HEVC Decoder
 - GE2D
Driver exists, but must be adapted

Broken:
 - VP9 Decoder needs some fixup to be stable (Seeking, ...)

## AXG
### Display
Missing:
 - MIPI DSI Controller
Code was submitted, but needs some refactor before re-submitted.

### Misc
Missing:
 - Crypto Accelerator

## G12A/G12B/SM1

### Audio
Broken:
Multiple issues are reported with the Mainline AIU driver:
 - 5-8 second dropouts
 - channels are messed up in both AIU/AXG when playing 5.1+

### Display
Missing:
 - Secure Video Path
 - HDCP2
 - Dual display support
Needs documentation to understand how the works

 - MIPI DSI Controller
Code was submitted, but needs some refactor before re-submitted.

 - MIPI DSI PHY
Code was submitted, but needs some refactor before re-submitted.

 - Support for complex planes blending
Needs documentation to understand how this works

 - Support for complex Picture post-processing
Needs documentation to understand how this works

 - Support for complex OSD and Video HDR transformations
Needs documentation to understand how this works

 - Dynamic HDR

This is not supported by any framework in the kernel

### Multimedia
Missing:
 - HEVC Decoder
 - MIPI CSI Input
 - MIPI CSI Phys
 - Camera Image Processor
Only for A311D/S922X, is an ARM ISP core.

 - GE2D
Driver exists, but must be adapted

### Misc
Missing:
 - Crypto Accelerator
 - NPU (Vivante Core)

Please follow-up if I missed something in my working or broken/missing list !

Neil


From marex at denx.de  Thu Apr 15 15:30:38 2021
From: marex at denx.de (Marek Vasut)
Date: Thu, 15 Apr 2021 16:30:38 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
In-Reply-To: <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
 <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
 <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>
Message-ID: <fa3885df-8977-9540-f2af-d4095f519483@denx.de>

On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
> Hi Marek

Hello Alexandre,

>>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>> index 2bc92ef3aeb9..19ef475a48fc 100644
>>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>> @@ -82,9 +82,15 @@
>>> ? };
>>> ? &ltdc {
>>> -??? status = "okay";
>>> -
>>> ????? port {
>>> +??????? #address-cells = <1>;
>>> +??????? #size-cells = <0>;
>>> +
>>> +??????? ltdc_ep0_out: endpoint at 0 {
>>> +??????????? reg = <0>;
>>> +??????????? remote-endpoint = <&sii9022_in>;
>>> +??????? };
>>> +
>>> ????????? ltdc_ep1_out: endpoint at 1 {
>>> ????????????? reg = <1>;
>>> ????????????? remote-endpoint = <&dsi_in>;
>>
>> [...]
>>
>>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>> index 64dca5b7f748..e7f10975cacf 100644
>>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>> @@ -277,11 +277,7 @@
>>> ????? status = "okay";
>>> ????? port {
>>> -??????? #address-cells = <1>;
>>> -??????? #size-cells = <0>;
>>> -
>>> -??????? ltdc_ep0_out: endpoint at 0 {
>>> -??????????? reg = <0>;
>>> +??????? ltdc_ep0_out: endpoint {
>>> ????????????? remote-endpoint = <&adv7513_in>;
>>> ????????? };
>>> ????? };
>>
>> I think this is wrong, the AV96 can have two displays connected to two 
>> ports of the LTDC, just like DK2 for example.
> 
> As for dk2 address/size cells are added only if there are 2 endpoints. 
> It is for this reason I moved endpoint0 definition from stm32mp15xx-dkx 
> to stm32mp151a-dk1.dts (dk1 has only one endpoint).
> 
> Here it's the same, if you have second endpoint then adress/size will 
> have to be added.

That's a bit problematic. Consider either the use case of DTO which adds 
the other display, or even a custom board DTS. Without your patch, this 
works:

arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
&ltdc {
   ...
   ports {
     ltdc_ep0_out: endpoint at 0 {
       remote-endpoint = <&adv7513_in>;
     };
   };
};

board-with-display.dts or board-overlay.dts
&ltdc {
   ports {
     endpoint at 1 { // just add another endpoint at 1, no problem
       remote-endpoint = <&display>;
     };
   };
};

With your patch, the DTS would have to modify the "endpoint" node to be 
"endpoint at 0" probably with a whole lot of /detele-node/ etc. magic (DTO 
cannot do that, so that's a problem, and I do use DTOs on AV96 
extensively for the various expansion cards) and then add the 
endpoint at 1. That becomes real complicated in custom board DT, and 
impossible with DTO.


From leo.yan at linaro.org  Thu Apr 15 15:33:29 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 22:33:29 +0800
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <4c173b86-b045-0514-b293-c39cc74d353d@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
 <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>
 <20210415123953.GB1011890@leoy-ThinkPad-X240s>
 <4c173b86-b045-0514-b293-c39cc74d353d@arm.com>
Message-ID: <20210415143329.GC1011890@leoy-ThinkPad-X240s>

Hi James,

On Thu, Apr 15, 2021 at 03:51:46PM +0300, James Clark wrote:

[...]

> > For the orignal perf data file with "--per-thread" option, the decoder
> > runs into the condition for "etm->timeless_decoding"; and it doesn't
> > contain ETM timestamp.
> > 
> > Afterwards, the injected perf data file also misses ETM timestamp and
> > hit the condition "etm->timeless_decoding".
> > 
> > So I am confusing why the original perf data can be processed properly
> > but fails to handle the injected perf data file.
> 
> Hi Leo,
> 
> My patch only deals with per-cpu mode. With per-thread mode everything is already working
> because _none_ of the events have timestamps because they are not enabled by default:
> 
> 	/* In per-cpu case, always need the time of mmap events etc */
> 	if (!perf_cpu_map__empty(cpus))
> 		evsel__set_sample_bit(tracking_evsel, TIME);
> 
> When none of the events have timestamps, I think perf doesn't use the ordering code in
> ordered-events.c. So when the inject file is opened, the events are read in file order.

The explination makes sense to me.  One thinking: if the original file
doesn't use the ordered event, is it possible for the injected file to
not use the ordered event as well?

Could you confirm Intel-pt can work well for per-cpu mode for inject
file?

> So it's not really about --per-thread vs per-cpu mode, it's actually about whether
> PERF_SAMPLE_TIME is set, which is set as a by-product of per-cpu mode.
>
> I hope I understood your question properly.

Thanks for info, sorry if I miss any info you have elaborated.

Leo


From dan.carpenter at oracle.com  Thu Apr 15 15:34:09 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 15 Apr 2021 17:34:09 +0300
Subject: [PATCH][next] net: stmmac: replace redundant comparison with true
In-Reply-To: <20210415083757.1807538-1-colin.king@canonical.com>
References: <20210415083757.1807538-1-colin.king@canonical.com>
Message-ID: <20210415143409.GC6021@kadam>

On Thu, Apr 15, 2021 at 09:37:57AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> The comparison of the u32 variable queue with <= zero is always true
> since an unsigned can never be negative. Replace the conditional
> check with the boolean true to simplify the code.  The while loop
> will terminate because of the zero check on queue before queue is
> decremented.
> 
> Addresses-Coverity: ("Unsigned compared against 0")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e3e22200a4fd..6e5b4c4b375c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1673,7 +1673,7 @@ static void stmmac_reinit_rx_buffers(struct stmmac_priv *priv)
>  	return;
>  
>  err_reinit_rx_buffers:
> -	while (queue >= 0) {

This is an off by one from what the original developer was intending
because we're freeing the most recent queue that wasn't allocated.
In other words, we're freeing everything that we need to plus *one
more thing that we don't need to*.  But it's harmless in this case:

The better fix would be to make queue an int type and do:

	while (--queue >= 0)
		dma_free_rx_skbufs(priv, queue);



From alexandre.torgue at foss.st.com  Thu Apr 15 15:35:25 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Thu, 15 Apr 2021 16:35:25 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
In-Reply-To: <fa3885df-8977-9540-f2af-d4095f519483@denx.de>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
 <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
 <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>
 <fa3885df-8977-9540-f2af-d4095f519483@denx.de>
Message-ID: <3961c9ae-41cc-5a15-2704-ffc0832f0fe8@foss.st.com>



On 4/15/21 4:30 PM, Marek Vasut wrote:
> On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
>> Hi Marek
> 
> Hello Alexandre,
> 
>>>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>>>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> index 2bc92ef3aeb9..19ef475a48fc 100644
>>>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>> @@ -82,9 +82,15 @@
>>>> ? };
>>>> ? &ltdc {
>>>> -??? status = "okay";
>>>> -
>>>> ????? port {
>>>> +??????? #address-cells = <1>;
>>>> +??????? #size-cells = <0>;
>>>> +
>>>> +??????? ltdc_ep0_out: endpoint at 0 {
>>>> +??????????? reg = <0>;
>>>> +??????????? remote-endpoint = <&sii9022_in>;
>>>> +??????? };
>>>> +
>>>> ????????? ltdc_ep1_out: endpoint at 1 {
>>>> ????????????? reg = <1>;
>>>> ????????????? remote-endpoint = <&dsi_in>;
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>>>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> index 64dca5b7f748..e7f10975cacf 100644
>>>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>> @@ -277,11 +277,7 @@
>>>> ????? status = "okay";
>>>> ????? port {
>>>> -??????? #address-cells = <1>;
>>>> -??????? #size-cells = <0>;
>>>> -
>>>> -??????? ltdc_ep0_out: endpoint at 0 {
>>>> -??????????? reg = <0>;
>>>> +??????? ltdc_ep0_out: endpoint {
>>>> ????????????? remote-endpoint = <&adv7513_in>;
>>>> ????????? };
>>>> ????? };
>>>
>>> I think this is wrong, the AV96 can have two displays connected to 
>>> two ports of the LTDC, just like DK2 for example.
>>
>> As for dk2 address/size cells are added only if there are 2 endpoints. 
>> It is for this reason I moved endpoint0 definition from 
>> stm32mp15xx-dkx to stm32mp151a-dk1.dts (dk1 has only one endpoint).
>>
>> Here it's the same, if you have second endpoint then adress/size will 
>> have to be added.
> 
> That's a bit problematic. Consider either the use case of DTO which adds 
> the other display, or even a custom board DTS. Without your patch, this 
> works:
> 
> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> &ltdc {
>  ? ...
>  ? ports {
>  ??? ltdc_ep0_out: endpoint at 0 {
>  ????? remote-endpoint = <&adv7513_in>;
>  ??? };
>  ? };
> };
> 
> board-with-display.dts or board-overlay.dts
> &ltdc {
>  ? ports {
>  ??? endpoint at 1 { // just add another endpoint at 1, no problem
>  ????? remote-endpoint = <&display>;
>  ??? };
>  ? };
> };
> 
> With your patch, the DTS would have to modify the "endpoint" node to be 
> "endpoint at 0" probably with a whole lot of /detele-node/ etc. magic (DTO 
> cannot do that, so that's a problem, and I do use DTOs on AV96 
> extensively for the various expansion cards) and then add the 
> endpoint at 1. That becomes real complicated in custom board DT, and 
> impossible with DTO.

Yes I agree that it'll be problematic. So maybe so solution would be to 
not detect a warning for the initial case (only one endpoint with a reg)


From leo.yan at linaro.org  Thu Apr 15 15:41:58 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 22:41:58 +0800
Subject: [PATCH v4 1/6] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <882e13d1-c793-88c6-0b1e-629462fb99ac@arm.com>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-2-leo.yan@linaro.org>
 <882e13d1-c793-88c6-0b1e-629462fb99ac@arm.com>
Message-ID: <20210415144158.GD1011890@leoy-ThinkPad-X240s>

Hi James,

On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote:
> On 12/04/2021 12:10, Leo Yan wrote:
> > The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.
> 
> Hi Leo,
> 
> I think this causes an error when attempting to open a newly recorded file
> with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here:
> 
> 	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
> 	struct perf_record_time_conv *tc = &session->time_conv;
> 	struct arm_spe *spe;
> 	int err;
> 
> 	if (auxtrace_info->header.size < sizeof(struct perf_record_auxtrace_info) +
> 					min_sz)
> 		return -EINVAL;
> 
> And removing ARM_SPE_PER_CPU_MMAPS changes the value of ARM_SPE_AUXTRACE_PRIV_MAX.
> 
> At least I think that's what's causing the problem. I get this error:
> 
> 	./perf report -i per-thread-spe-time.data
> 	0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
> 	Error:
> 	failed to process sample
> 	# To display the perf.data header info, please use --header/--header-only options.
> 	#

Yes, when working on this patch I had concern as well.

I carefully thought that the perf tool should be backwards-compatible,
but there have no requirement for forwards-compatibility.  This is the
main reason why I kept this patch.

If you or anyone could confirm the forwards-compatibility is required,
it's quite fine for me to drop this patch.

Thanks a lot for the reviewing and testing!
Leo


From james.clark at arm.com  Thu Apr 15 15:43:24 2021
From: james.clark at arm.com (James Clark)
Date: Thu, 15 Apr 2021 17:43:24 +0300
Subject: [PATCH v4 0/6] perf arm-spe: Enable timestamp
In-Reply-To: <20210412091006.468557-1-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
Message-ID: <570051ef-eda0-ead2-96de-0e22ca226e0a@arm.com>

Hi Leo,

I was looking at testing this on N1SDP and I thought I would try the round trip with perf inject and
then perf report but saw that perf inject with SPE always results in an error (unrelated to your change)

	 -> ./perf report -i per-thread-spe-time.inject.data
	0x1328 [0x8]: failed to process type: 9 [Bad address]
	Error:
	failed to process sample


Do you have any test suggestions other than looking at the raw data?

Thanks
James

On 12/04/2021 12:10, Leo Yan wrote:
> This patch set is to enable timestamp for Arm SPE trace.  It reads out
> TSC parameters from the TIME_CONV event, the parameters are used for
> conversion between timer counter and kernel time and which is applied
> for Arm SPE samples.
> 
> This version dropped the change for adding hardware clock parameters
> into auxtrace info, alternatively, it utilizes the TIME_CONV event to
> extract the clock parameters which is used for timestamp calculation.
> 
> This patch set can be clearly applied on perf/core branch with:
> 
>   commit 2c0cb9f56020 ("perf test: Add a shell test for 'perf stat --bpf-counters' new option")
> 
> Ths patch series has been tested on Hisilicon D06 platform.
> 
> Changes from v3:
> * Let to be backwards-compatible for TIME_CONV event (Adrian).
> 
> Changes from v2:
> * Changed to use TIME_CONV event for extracting clock parameters (Al).
> 
> Changes from v1:
> * Rebased patch series on the latest perf/core branch;
> * Fixed the patch for dumping TSC parameters to support both the
>   older and new auxtrace info format.
> 
> 
> Leo Yan (6):
>   perf arm-spe: Remove unused enum value ARM_SPE_PER_CPU_MMAPS
>   perf arm-spe: Save clock parameters from TIME_CONV event
>   perf arm-spe: Convert event kernel time to counter value
>   perf arm-spe: Assign kernel time to synthesized event
>   perf arm-spe: Bail out if the trace is later than perf event
>   perf arm-spe: Don't wait for PERF_RECORD_EXIT event
> 
>  tools/perf/util/arm-spe.c | 74 +++++++++++++++++++++++++++++++++------
>  tools/perf/util/arm-spe.h |  1 -
>  2 files changed, 64 insertions(+), 11 deletions(-)
> 


From robh at kernel.org  Thu Apr 15 15:43:42 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 09:43:42 -0500
Subject: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
In-Reply-To: <B9287FE7-5EF5-40B3-BCB3-08DA11D6CDD7@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
 <20210414104939.1093-2-billy_tsai@aspeedtech.com>
 <20210414221553.GA56046@robh.at.kernel.org>
 <B9287FE7-5EF5-40B3-BCB3-08DA11D6CDD7@aspeedtech.com>
Message-ID: <CAL_JsqLuswcRqQ-JQ9qgWQEhykPWCTsnVFLxCEPV6BbF86vWOw@mail.gmail.com>

On Wed, Apr 14, 2021 at 10:44 PM Billy Tsai <billy_tsai at aspeedtech.com> wrote:
>
> Hi Rob,
>
> On 2021/4/15, 6:16 AM,Rob Herringwrote:
>
>     On Wed, Apr 14, 2021 at 06:49:38PM +0800, Billy Tsai wrote:
>     >> This patch adds device bindings for aspeed pwm-tach device which is a
>     >> multi-function device include pwn and tach function and pwm device which
>     >> should be the sub-node of pwm-tach device.
>     >>
>     >> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
>     >> Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545
>     >
>     >Drop
>     >
>     >> ---
>     >>  .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++++++++++++++++++
>     >>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 44 ++++++++++++++
>     >>  2 files changed, 104 insertions(+)
>     >>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>     >>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
>     >>
>     >> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>     >> new file mode 100644
>     >> index 000000000000..eaf8bdf8d44e
>     >> --- /dev/null
>     >> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
>     >> @@ -0,0 +1,60 @@
>     >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>     >> +# Copyright (C) 2021 ASPEED, Inc.
>     >> +%YAML 1.2
>     >> +---
>     >> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
>     >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>     >> +
>     >> +title: PWM Tach controller Device Tree Bindings
>     >> +
>     >> +description: |
>     >> +  The PWM Tach controller is represented as a multi-function device which
>     >> +  includes:
>     >> +    PWM
>     >> +    Tach
>
>     > But is it really? A PWM and tach sounds like a fan controller. Look at
>
> Our PWM is not only for fans but also used for the motor, led, buzzer, and so on.
> So I want to split the function into two devices with a multi-function device.
> One for PWM output and one for tach monitor.
>
>     > other existing PWM+tach bindings we have for fans.
>
> I didn't see the PWM+tach bindings can you give some example for me, thanks.

Let me grep 'tach' for you:

Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt

Hey, look at that, there's already one for ASpeed. So the question is
how is the newer h/w different?

>
>     >> +
>     >> +maintainers:
>     >> +  - Billy Tsai <billy_tsai at aspeedtech.com>
>     >> +
>     >> +properties:
>     >> +  compatible:
>     >> +    items:
>     >> +      - enum:
>     >> +          - aspeed,ast2600-pwm-tach
>     >> +      - const: syscon
>     >> +      - const: simple-mfd
>     >> +  reg:
>     >> +    maxItems: 1
>     >> +  "#address-cells":
>     >> +    const: 1
>     >> +  "#size-cells":
>     >> +    const: 1
>     >> +
>     >> +required:
>     >> +  - compatible
>     >> +  - reg
>     >> +  - "#address-cells"
>     >> +  - "#size-cells"
>     >> +
>     >> +additionalProperties:
>     >> +  type: object
>
>     > As you know the 2 node names, they should be documented. However, see
>     > below.
>
>     >> +
>     >> +examples:
>     >> +  - |
>     >> +    pwm_tach: pwm_tach at 1e610000 {
>     >> +      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
>     >> +      #address-cells = <1>;
>     >> +      #size-cells = <1>;
>     >> +      reg = <0x1e610000 0x100>;
>     >> +
>     >> +      pwm: pwm at 0 {
>     >> +        compatible = "aspeed,ast2600-pwm";
>     >> +        #pwm-cells = <3>;
>     >> +        reg = <0x0 0x100>;
>     >> +      };
>     >> +
>     >> +      tach: tach at 1 {
>     >> +        compatible = "aspeed,ast2600-tach";
>     >> +        reg = <0x0 0x100>;
>
>     > You have 2 nodes at the same address. Not valid.
>
> Our pwm and tach is used the same base address and the offset is like below:
>
> PWM0 used 0x0 0x4, Tach0 used 0x8 0xc
> PWM1 used 0x10 0x14, Tach1 used 0x18 0x1c
> ...
>
> I will remove the reg property from pwm and tach node and remove the "#address-cells" and
> "#size-cells" from the parent node.

That's not really the solution...

>
>     >> +      };
>
>     > There's no real need for 2 child nodes. The parent node can be a PWM
>     > provider.
>
> However, In our usage, the parent node is a mfd, not a simple PWM device only. I don't want to
> combine the different functions with the one device node.

Looks like a single h/w block to me. If you want to divide that up
into multiple drivers, then that's an OS problem. A single node can be
multiple providers. For example, on the existing aspeed binding, just
add '#pwm-cells' to the node if you want to also expose it as a PWM
provider.

Rob


From james.clark at arm.com  Thu Apr 15 15:46:31 2021
From: james.clark at arm.com (James Clark)
Date: Thu, 15 Apr 2021 17:46:31 +0300
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized
 event
In-Reply-To: <20210412091006.468557-5-leo.yan@linaro.org>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-5-leo.yan@linaro.org>
Message-ID: <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>



On 12/04/2021 12:10, Leo Yan wrote:
> In current code, it assigns the arch timer counter to the synthesized
> samples Arm SPE trace, thus the samples don't contain the kernel time
> but only contain the raw counter value.
> 
> To fix the issue, this patch converts the timer counter to kernel time
> and assigns it to sample timestamp.
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  tools/perf/util/arm-spe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> index 23714cf0380e..c13a89f06ab8 100644
> --- a/tools/perf/util/arm-spe.c
> +++ b/tools/perf/util/arm-spe.c
> @@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
>  	struct arm_spe_record *record = &speq->decoder->record;
>  
>  	if (!spe->timeless_decoding)
> -		sample->time = speq->timestamp;
> +		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);


I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options.
I don't know of a way to remove this, and if there isn't, does that mean that all the code in this
file that looks at spe->timeless_decoding is untested and has never been hit?

Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one
might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding
is always false.



>  
>  	sample->ip = record->from_ip;
>  	sample->cpumode = arm_spe_cpumode(spe, sample->ip);
> 


From james.clark at arm.com  Thu Apr 15 15:49:45 2021
From: james.clark at arm.com (James Clark)
Date: Thu, 15 Apr 2021 17:49:45 +0300
Subject: [PATCH v4 1/6] perf arm-spe: Remove unused enum value
 ARM_SPE_PER_CPU_MMAPS
In-Reply-To: <20210415144158.GD1011890@leoy-ThinkPad-X240s>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-2-leo.yan@linaro.org>
 <882e13d1-c793-88c6-0b1e-629462fb99ac@arm.com>
 <20210415144158.GD1011890@leoy-ThinkPad-X240s>
Message-ID: <a3a516c5-fc13-50d6-d80f-66f68d1c89c1@arm.com>



On 15/04/2021 17:41, Leo Yan wrote:
> Hi James,
> 
> On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote:
>> On 12/04/2021 12:10, Leo Yan wrote:
>>> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.
>>
>> Hi Leo,
>>
>> I think this causes an error when attempting to open a newly recorded file
>> with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used here:
>>
>> 	size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
>> 	struct perf_record_time_conv *tc = &session->time_conv;
>> 	struct arm_spe *spe;
>> 	int err;
>>
>> 	if (auxtrace_info->header.size < sizeof(struct perf_record_auxtrace_info) +
>> 					min_sz)
>> 		return -EINVAL;
>>
>> And removing ARM_SPE_PER_CPU_MMAPS changes the value of ARM_SPE_AUXTRACE_PRIV_MAX.
>>
>> At least I think that's what's causing the problem. I get this error:
>>
>> 	./perf report -i per-thread-spe-time.data
>> 	0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
>> 	Error:
>> 	failed to process sample
>> 	# To display the perf.data header info, please use --header/--header-only options.
>> 	#
> 
> Yes, when working on this patch I had concern as well.
> 
> I carefully thought that the perf tool should be backwards-compatible,
> but there have no requirement for forwards-compatibility.  This is the
> main reason why I kept this patch.
> 
> If you or anyone could confirm the forwards-compatibility is required,
> it's quite fine for me to drop this patch.
> 

Personally, I can easily imagine sending a file to someone to open with an older version and it causing
friction where it could be easily avoided. And it even made testing a bit more difficult because
I wanted to compare opening the same file with the patched and un-patched version. But if there
is no hard requirement I can't really put too much pressure to not remove it.

> Thanks a lot for the reviewing and testing!
> Leo
> 


From gregkh at linuxfoundation.org  Thu Apr 15 15:46:55 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 15 Apr 2021 16:46:55 +0200
Subject: [PATCH 4.14 14/68] ARM: dts: turris-omnia: configure LED[2]/INTn pin
 as interrupt pin
In-Reply-To: <20210415144414.464797272@linuxfoundation.org>
References: <20210415144414.464797272@linuxfoundation.org>
Message-ID: <20210415144414.936192266@linuxfoundation.org>

From: Marek Beh?n <kabel at kernel.org>

commit a26c56ae67fa9fbb45a8a232dcd7ebaa7af16086 upstream.

Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.

Without this the pin is by default in LED[2] mode, and the Marvell PHY
driver configures LED[2] into "On - Link, Blink - Activity" mode.

This fixes the issue where the pca9538 GPIO/interrupt controller (which
can't mask interrupts in HW) received too many interrupts and after a
time started ignoring the interrupt with error message:
  IRQ 71: nobody cared

There is a work in progress to have the Marvell PHY driver support
parsing PHY LED nodes from OF and registering the LEDs as Linux LED
class devices. Once this is done the PHY driver can also automatically
set the pin into INTn mode if it does not find LED[2] in OF.

Until then, though, we fix this via `marvell,reg-init` DT property.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Reported-by: Rui Salvaterra <rsalvaterra at gmail.com>
Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
Cc: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: Gregory CLEMENT <gregory.clement at bootlin.com>
Cc: <stable at vger.kernel.org>
Tested-by: Rui Salvaterra <rsalvaterra at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement at bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
---
 arch/arm/boot/dts/armada-385-turris-omnia.dts |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -269,6 +269,7 @@
 		status = "okay";
 		compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
 		reg = <1>;
+		marvell,reg-init = <3 18 0 0x4985>;
 
 		/* irq is connected to &pcawan pin 7 */
 	};




From gregkh at linuxfoundation.org  Thu Apr 15 15:47:11 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 15 Apr 2021 16:47:11 +0200
Subject: [PATCH 4.14 30/68] ASoC: sunxi: sun4i-codec: fill ASoC card owner
In-Reply-To: <20210415144414.464797272@linuxfoundation.org>
References: <20210415144414.464797272@linuxfoundation.org>
Message-ID: <20210415144415.449714640@linuxfoundation.org>

From: Bastian Germann <bage at linutronix.de>

[ Upstream commit 7c0d6e482062eb5c06ecccfab340abc523bdca00 ]

card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn on empty module") a warning is issued if it is empty. Add it.
This fixes following warning observed on Lamobo R1:

WARNING: CPU: 1 PID: 190 at sound/core/init.c:207 snd_card_new+0x430/0x480 [snd]
Modules linked in: sun4i_codec(E+) sun4i_backend(E+) snd_soc_core(E) ...
CPU: 1 PID: 190 Comm: systemd-udevd Tainted: G         C  E     5.10.0-1-armmp #1 Debian 5.10.4-1
Hardware name: Allwinner sun7i (A20) Family
Call trace:
 (snd_card_new [snd])
 (snd_soc_bind_card [snd_soc_core])
 (snd_soc_register_card [snd_soc_core])
 (sun4i_codec_probe [sun4i_codec])

Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on early Allwinner SoCs")
Related: commit 3c27ea23ffb4 ("ASoC: qcom: Set card->owner to avoid warnings")
Related: commit ec653df2a0cb ("drm/vc4/vc4_hdmi: fill ASoC card owner")
Cc: linux-arm-kernel at lists.infradead.org
Cc: alsa-devel at alsa-project.org
Signed-off-by: Bastian Germann <bage at linutronix.de>
Link: https://lore.kernel.org/r/20210331151843.30583-1-bage at linutronix.de
Signed-off-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 sound/soc/sunxi/sun4i-codec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index baa9007464ed..700779ca82d0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1199,6 +1199,7 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "sun4i-codec";
 	card->dapm_widgets	= sun4i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun4i_codec_card_dapm_widgets);
@@ -1231,6 +1232,7 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A31 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1284,6 +1286,7 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "A23 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1322,6 +1325,7 @@ static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "H3 Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
@@ -1360,6 +1364,7 @@ static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
 		return ERR_PTR(-ENOMEM);
 
 	card->dev		= dev;
+	card->owner		= THIS_MODULE;
 	card->name		= "V3s Audio Codec";
 	card->dapm_widgets	= sun6i_codec_card_dapm_widgets;
 	card->num_dapm_widgets	= ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
-- 
2.30.2





From leo.yan at linaro.org  Thu Apr 15 15:56:22 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 22:56:22 +0800
Subject: [PATCH v4 0/6] perf arm-spe: Enable timestamp
In-Reply-To: <570051ef-eda0-ead2-96de-0e22ca226e0a@arm.com>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <570051ef-eda0-ead2-96de-0e22ca226e0a@arm.com>
Message-ID: <20210415145622.GE1011890@leoy-ThinkPad-X240s>

On Thu, Apr 15, 2021 at 05:43:24PM +0300, James Clark wrote:
> Hi Leo,
> 
> I was looking at testing this on N1SDP and I thought I would try the round trip with perf inject and
> then perf report but saw that perf inject with SPE always results in an error (unrelated to your change)
> 
> 	 -> ./perf report -i per-thread-spe-time.inject.data
> 	0x1328 [0x8]: failed to process type: 9 [Bad address]
> 	Error:
> 	failed to process sample
> 
> 
> Do you have any test suggestions other than looking at the raw data?

Good catching!  I didn't use inject mode for Arm SPE before (it's not
not like Arm CoreSight for instruction sample, or SPE's branch sample
is statistical so we cannot generate branch samples based on accurate
interval).

For the debugging, it's good to use "git grep" to search "Bad address"
to check where the error happens, and can use gdb.  I personally think
it's possible to go back to check the sythenization flow, simply to
say, it might have problems when inject samples but not in the
decoding flow.

Thanks,
Leo


From marex at denx.de  Thu Apr 15 15:59:39 2021
From: marex at denx.de (Marek Vasut)
Date: Thu, 15 Apr 2021 16:59:39 +0200
Subject: [PATCH 11/13] ARM: dts: stm32: fix LTDC port node on STM32 MCU ad
 MPU
In-Reply-To: <3961c9ae-41cc-5a15-2704-ffc0832f0fe8@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-12-alexandre.torgue@foss.st.com>
 <3b39908b-a263-a5d4-f6ac-ac30ffb06269@denx.de>
 <36e9f0df-dfdb-e2f5-3d6e-ac32a1b8156e@foss.st.com>
 <fa3885df-8977-9540-f2af-d4095f519483@denx.de>
 <3961c9ae-41cc-5a15-2704-ffc0832f0fe8@foss.st.com>
Message-ID: <57a7f4bf-42e9-56fb-e898-2c5749f53c60@denx.de>

On 4/15/21 4:35 PM, Alexandre TORGUE wrote:
> 
> 
> On 4/15/21 4:30 PM, Marek Vasut wrote:
>> On 4/15/21 3:34 PM, Alexandre TORGUE wrote:
>>> Hi Marek
>>
>> Hello Alexandre,
>>
>>>>> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts 
>>>>> b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> index 2bc92ef3aeb9..19ef475a48fc 100644
>>>>> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
>>>>> @@ -82,9 +82,15 @@
>>>>> ? };
>>>>> ? &ltdc {
>>>>> -??? status = "okay";
>>>>> -
>>>>> ????? port {
>>>>> +??????? #address-cells = <1>;
>>>>> +??????? #size-cells = <0>;
>>>>> +
>>>>> +??????? ltdc_ep0_out: endpoint at 0 {
>>>>> +??????????? reg = <0>;
>>>>> +??????????? remote-endpoint = <&sii9022_in>;
>>>>> +??????? };
>>>>> +
>>>>> ????????? ltdc_ep1_out: endpoint at 1 {
>>>>> ????????????? reg = <1>;
>>>>> ????????????? remote-endpoint = <&dsi_in>;
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi 
>>>>> b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> index 64dca5b7f748..e7f10975cacf 100644
>>>>> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>>>>> @@ -277,11 +277,7 @@
>>>>> ????? status = "okay";
>>>>> ????? port {
>>>>> -??????? #address-cells = <1>;
>>>>> -??????? #size-cells = <0>;
>>>>> -
>>>>> -??????? ltdc_ep0_out: endpoint at 0 {
>>>>> -??????????? reg = <0>;
>>>>> +??????? ltdc_ep0_out: endpoint {
>>>>> ????????????? remote-endpoint = <&adv7513_in>;
>>>>> ????????? };
>>>>> ????? };
>>>>
>>>> I think this is wrong, the AV96 can have two displays connected to 
>>>> two ports of the LTDC, just like DK2 for example.
>>>
>>> As for dk2 address/size cells are added only if there are 2 
>>> endpoints. It is for this reason I moved endpoint0 definition from 
>>> stm32mp15xx-dkx to stm32mp151a-dk1.dts (dk1 has only one endpoint).
>>>
>>> Here it's the same, if you have second endpoint then adress/size will 
>>> have to be added.
>>
>> That's a bit problematic. Consider either the use case of DTO which 
>> adds the other display, or even a custom board DTS. Without your 
>> patch, this works:
>>
>> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
>> &ltdc {
>> ?? ...
>> ?? ports {
>> ???? ltdc_ep0_out: endpoint at 0 {
>> ?????? remote-endpoint = <&adv7513_in>;
>> ???? };
>> ?? };
>> };
>>
>> board-with-display.dts or board-overlay.dts
>> &ltdc {
>> ?? ports {
>> ???? endpoint at 1 { // just add another endpoint at 1, no problem
>> ?????? remote-endpoint = <&display>;
>> ???? };
>> ?? };
>> };
>>
>> With your patch, the DTS would have to modify the "endpoint" node to 
>> be "endpoint at 0" probably with a whole lot of /detele-node/ etc. magic 
>> (DTO cannot do that, so that's a problem, and I do use DTOs on AV96 
>> extensively for the various expansion cards) and then add the 
>> endpoint at 1. That becomes real complicated in custom board DT, and 
>> impossible with DTO.
> 
> Yes I agree that it'll be problematic. So maybe so solution would be to 
> not detect a warning for the initial case (only one endpoint with a reg)

That looks OK. Or even better, if the checker warned only on IPs which 
cannot have more than one endpoint, but have endpoint at N in DT (where N 
in 0..+inf) . On IPs which can have one or more endpoints, the warning 
should not be emitted.


From stefan at agner.ch  Thu Apr 15 16:03:08 2021
From: stefan at agner.ch (Stefan Agner)
Date: Thu, 15 Apr 2021 17:03:08 +0200
Subject: [PATCH 2/4] drm/mxsfb: Don't select DRM_KMS_FB_HELPER
In-Reply-To: <20210415110040.23525-3-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-3-tzimmermann@suse.de>
Message-ID: <edc956f96a143d8fd27abea47b6d5eaf@agner.ch>

On 2021-04-15 13:00, Thomas Zimmermann wrote:
> Selecting DRM_FBDEV_EMULATION will include the correct secttings for
> fbdev emulation. Drivers should not override this.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Acked-by: Stefan Agner <stefan at agner.ch>

--
Stefan

> ---
>  drivers/gpu/drm/mxsfb/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 0143d539f8f8..ee22cd25d3e3 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -10,7 +10,6 @@ config DRM_MXSFB
>  	depends on COMMON_CLK
>  	select DRM_MXS
>  	select DRM_KMS_HELPER
> -	select DRM_KMS_FB_HELPER
>  	select DRM_KMS_CMA_HELPER
>  	select DRM_PANEL
>  	select DRM_PANEL_BRIDGE


From lkp at intel.com  Thu Apr 15 16:11:53 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 15 Apr 2021 23:11:53 +0800
Subject: [PATCH v3 2/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <1618490885-44612-3-git-send-email-liuqi115@huawei.com>
References: <1618490885-44612-3-git-send-email-liuqi115@huawei.com>
Message-ID: <202104152306.HwFJY9OK-lkp@intel.com>

Hi Qi,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc7]
[cannot apply to next-20210415]
[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]

url:    https://github.com/0day-ci/linux/commits/Qi-Liu/drivers-perf-hisi-Add-support-for-PCIe-PMU/20210415-204823
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 7f75285ca572eaabc028cf78c6ab5473d0d160be
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/94ad51ddfebbb5df3aa85fdb8a3781737accb159
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Qi-Liu/drivers-perf-hisi-Add-support-for-PCIe-PMU/20210415-204823
        git checkout 94ad51ddfebbb5df3aa85fdb8a3781737accb159
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=sh 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/bits.h:6,
                    from include/linux/bitops.h:6,
                    from include/linux/bitmap.h:8,
                    from drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:11:
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_pmu_config_filter':
   include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
       7 | #define BIT(nr)   (UL(1) << (nr))
         |                          ^~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:42:32: note: in expansion of macro 'BIT'
      42 | #define HISI_PCIE_DEFAULT_SET  BIT(34)
         |                                ^~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:225:12: note: in expansion of macro 'HISI_PCIE_DEFAULT_SET'
     225 |  u64 reg = HISI_PCIE_DEFAULT_SET;
         |            ^~~~~~~~~~~~~~~~~~~~~
   include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
       7 | #define BIT(nr)   (UL(1) << (nr))
         |                          ^~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:44:30: note: in expansion of macro 'BIT'
      44 | #define HISI_PCIE_TARGET_EN  BIT(32)
         |                              ^~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:238:10: note: in expansion of macro 'HISI_PCIE_TARGET_EN'
     238 |   reg |= HISI_PCIE_TARGET_EN |
         |          ^~~~~~~~~~~~~~~~~~~
   include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
       7 | #define BIT(nr)   (UL(1) << (nr))
         |                          ^~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:45:28: note: in expansion of macro 'BIT'
      45 | #define HISI_PCIE_TRIG_EN  BIT(52)
         |                            ^~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:246:44: note: in expansion of macro 'HISI_PCIE_TRIG_EN'
     246 |          hisi_pcie_get_trig_mode(event)) | HISI_PCIE_TRIG_EN;
         |                                            ^~~~~~~~~~~~~~~~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_pmu_clear_filter':
   include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
       7 | #define BIT(nr)   (UL(1) << (nr))
         |                          ^~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:42:32: note: in expansion of macro 'BIT'
      42 | #define HISI_PCIE_DEFAULT_SET  BIT(34)
         |                                ^~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:264:9: note: in expansion of macro 'HISI_PCIE_DEFAULT_SET'
     264 |         HISI_PCIE_DEFAULT_SET);
         |         ^~~~~~~~~~~~~~~~~~~~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_pmu_reset_counter':
   include/vdso/bits.h:7:26: warning: left shift count >= width of type [-Wshift-count-overflow]
       7 | #define BIT(nr)   (UL(1) << (nr))
         |                          ^~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:42:32: note: in expansion of macro 'BIT'
      42 | #define HISI_PCIE_DEFAULT_SET  BIT(34)
         |                                ^~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:526:9: note: in expansion of macro 'HISI_PCIE_DEFAULT_SET'
     526 |         HISI_PCIE_DEFAULT_SET);
         |         ^~~~~~~~~~~~~~~~~~~~~
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_pmu_irq_register':
>> drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:676:3: error: implicit declaration of function 'pci_free_irq_vectors'; did you mean 'pci_alloc_irq_vectors'? [-Werror=implicit-function-declaration]
     676 |   pci_free_irq_vectors(pdev);
         |   ^~~~~~~~~~~~~~~~~~~~
         |   pci_alloc_irq_vectors
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_init_dev':
>> drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:920:8: error: implicit declaration of function 'pci_request_mem_regions'; did you mean 'pci_request_regions'? [-Werror=implicit-function-declaration]
     920 |  ret = pci_request_mem_regions(pdev, "hisi_pcie_pmu");
         |        ^~~~~~~~~~~~~~~~~~~~~~~
         |        pci_request_regions
   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c: In function 'hisi_pcie_uninit_dev':
>> drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:935:2: error: implicit declaration of function 'pci_clear_master'; did you mean 'pci_set_master'? [-Werror=implicit-function-declaration]
     935 |  pci_clear_master(pdev);
         |  ^~~~~~~~~~~~~~~~
         |  pci_set_master
>> drivers/perf/pci/hisilicon/hisi_pcie_pmu.c:936:2: error: implicit declaration of function 'pci_release_mem_regions'; did you mean 'pci_release_regions'? [-Werror=implicit-function-declaration]
     936 |  pci_release_mem_regions(pdev);
         |  ^~~~~~~~~~~~~~~~~~~~~~~
         |  pci_release_regions
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC
   Depends on SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && HAS_DMA
   Selected by
   - SND_ATMEL_SOC_SSC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC
   - SND_ATMEL_SOC_SSC_PDC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && ATMEL_SSC


vim +676 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c

   658	
   659	static int hisi_pcie_pmu_irq_register(struct pci_dev *pdev,
   660					      struct hisi_pcie_pmu *pcie_pmu)
   661	{
   662		int irq, ret;
   663	
   664		ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI);
   665		if (ret < 0) {
   666			pci_err(pdev, "Failed to enable MSI vectors, ret = %d!\n", ret);
   667			return ret;
   668		}
   669	
   670		irq = pci_irq_vector(pdev, 0);
   671		ret = request_irq(irq, hisi_pcie_pmu_irq,
   672				  IRQF_NOBALANCING | IRQF_NO_THREAD, "hisi_pcie_pmu",
   673				  pcie_pmu);
   674		if (ret) {
   675			pci_err(pdev, "Failed to register irq, ret = %d!\n", ret);
 > 676			pci_free_irq_vectors(pdev);
   677			return ret;
   678		}
   679	
   680		pcie_pmu->irq = irq;
   681	
   682		return 0;
   683	}
   684	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 54267 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210415/77c0a91e/attachment-0001.gz>

From robh+dt at kernel.org  Thu Apr 15 16:13:17 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 10:13:17 -0500
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,
 pci-domain to zero
In-Reply-To: <20210415104537.403de52e@thinkpad>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali> <20210415104537.403de52e@thinkpad>
Message-ID: <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>

On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun at nic.cz> wrote:
>
> On Thu, 15 Apr 2021 10:36:40 +0200
> Pali Roh?r <pali at kernel.org> wrote:
>
> > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
> > > >
> > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > > function and allow to build it as module") PCIe controller driver for
> > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > > > allows dynamic binding and unbinding of PCIe controller device.
> > > >
> > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > > number (starting from zero) for this PCIe controller every time when device
> > > > is bound. So PCI domain changes after every unbind / bind operation.
> > >
> > > PCI host bridges as a module are relatively new, so seems likely a bug to me.
> >
> > Why a bug? It is there since 5.10 and it is working.

I mean historically, the PCI subsystem didn't even support host
bridges as a module. They weren't even proper drivers and it was all
arch specific code. Most of the host bridge drivers are still built-in
only. This seems like a small detail that was easily overlooked.
unbind is not a well tested path.

> > > > Alternative way for assigning PCI domain number is to use static allocated
> > > > numbers defined in Device Tree. This option has requirement that every PCI
> > > > controller in system must have defined PCI bus number in Device Tree.
> > >
> > > That seems entirely pointless from a DT point of view with a single PCI bridge.
> >
> > If domain id is not specified in DT then kernel uses counter and assigns
> > counter++. So it is not pointless if we want to have stable domain id.
>
> What Rob is trying to say is that
> - the bug is that kernel assigns counter++
> - device-tree should not be used to fix problems with how kernel does
>   things
> - if a device has only one PCIe controller, it is pointless to define
>   it's pci-domain. If there were multiple controllers, then it would
>   make sense, but there is only one

Yes. I think what we want here is a domain bitmap rather than a
counter and we assign the lowest free bit. That could also allow for
handling a mixture of fixed domain numbers and dynamically assigned
ones.

You could create scenarios where the numbers change on you, but it
wouldn't be any different than say plugging in USB serial adapters.
You get the same ttyUSBx device when you re-attach unless there's been
other ttyUSBx devices attached/detached.

Rob


From syednwaris at gmail.com  Thu Apr 15 16:13:35 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:43:35 +0530
Subject: [PATCH v10 03/33] counter: 104-quad-8: Remove pointless comment
In-Reply-To: <e53df4416573f16069090f4c660afbd8d501f2a0.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <e53df4416573f16069090f4c660afbd8d501f2a0.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151335.GA8933@syed>

On Fri, Mar 19, 2021 at 08:00:22PM +0900, William Breathitt Gray wrote:
> It is obvious that devm_counter_register() is used to register a Counter
> device, so a comment stating such is pointless here.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 9691f8612be8..4bb9abffae48 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -1082,7 +1082,6 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  	/* Enable all counters */
>  	outb(QUAD8_CHAN_OP_ENABLE_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
>  
> -	/* Register Counter device */
>  	return devm_counter_register(dev, &priv->counter);
>  }
>  
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:14:31 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:44:31 +0530
Subject: [PATCH v10 04/33] counter: 104-quad-8: Return error when invalid
 mode during ceiling_write
In-Reply-To: <98676f9a2e9cf991d7a002b3b264cca774e5b3c8.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <98676f9a2e9cf991d7a002b3b264cca774e5b3c8.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151431.GB8933@syed>

On Fri, Mar 19, 2021 at 08:00:23PM +0900, William Breathitt Gray wrote:
> The 104-QUAD-8 only has two count modes where a ceiling value makes
> sense: Range Limit and Modulo-N. Outside of these two modes, setting a
> ceiling value is an invalid operation -- so let's report it as such by
> returning -EINVAL.
> 
> Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface")
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 4bb9abffae48..233a3acc1377 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -714,13 +714,14 @@ static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
>  	switch (priv->count_mode[count->id]) {
>  	case 1:
>  	case 3:
> +		mutex_unlock(&priv->lock);
>  		quad8_preset_register_set(priv, count->id, ceiling);
> -		break;
> +		return len;
>  	}
>  
>  	mutex_unlock(&priv->lock);
>  
> -	return len;
> +	return -EINVAL;
>  }
>  
>  static ssize_t quad8_count_preset_enable_read(struct counter_device *counter,
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:15:28 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:45:28 +0530
Subject: [PATCH v10 05/33] counter: 104-quad-8: Annotate hardware config
 module parameter
In-Reply-To: <203f1b6084ed86a6696eb422bcadc0955c6427bb.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <203f1b6084ed86a6696eb422bcadc0955c6427bb.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151528.GC8933@syed>

On Fri, Mar 19, 2021 at 08:00:24PM +0900, William Breathitt Gray wrote:
> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
> 
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
> 
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
> 
> This patch annotates the 104-QUAD-8 driver.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 233a3acc1377..0fd61cc82d30 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -21,7 +21,7 @@
>  
>  static unsigned int base[max_num_isa_dev(QUAD8_EXTENT)];
>  static unsigned int num_quad8;
> -module_param_array(base, uint, &num_quad8, 0);
> +module_param_hw_array(base, uint, ioport, &num_quad8, 0);
>  MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>  
>  #define QUAD8_NUM_COUNTERS 8
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:16:29 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:46:29 +0530
Subject: [PATCH v10 06/33] counter: 104-quad-8: Add const qualifiers for
 quad8_preset_register_set
In-Reply-To: <4a227eea6fa6aa1648fb0ccba6e924b6f95b2752.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <4a227eea6fa6aa1648fb0ccba6e924b6f95b2752.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151629.GD8933@syed>

On Fri, Mar 19, 2021 at 08:00:25PM +0900, William Breathitt Gray wrote:
> Add some safety by qualifying the quad8_preset_register_set() function
> parameters as const.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 0fd61cc82d30..51fba8cf9c2a 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -632,8 +632,8 @@ static ssize_t quad8_count_preset_read(struct counter_device *counter,
>  	return sprintf(buf, "%u\n", priv->preset[count->id]);
>  }
>  
> -static void quad8_preset_register_set(struct quad8 *priv, int id,
> -				      unsigned int preset)
> +static void quad8_preset_register_set(struct quad8 *const priv, const int id,
> +				      const unsigned int preset)
>  {
>  	const unsigned int base_offset = priv->base + 2 * id;
>  	int i;
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:17:16 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:47:16 +0530
Subject: [PATCH v10 07/33] counter: 104-quad-8: Add const qualifier for
 functions_list array
In-Reply-To: <c3d989972172945bbc616c973c1a759df5fa3d19.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <c3d989972172945bbc616c973c1a759df5fa3d19.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151716.GE8933@syed>

On Fri, Mar 19, 2021 at 08:00:26PM +0900, William Breathitt Gray wrote:
> The struct counter_count functions_list member expects a const enum
> counter_count_function array. This patch adds the const qualifier to the
> quad8_count_functions_list to match functions_list.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 51fba8cf9c2a..ae89ad7a91c6 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -193,7 +193,7 @@ enum quad8_count_function {
>  	QUAD8_COUNT_FUNCTION_QUADRATURE_X4
>  };
>  
> -static enum counter_count_function quad8_count_functions_list[] = {
> +static const enum counter_count_function quad8_count_functions_list[] = {
>  	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
>  	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A,
>  	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:18:13 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:48:13 +0530
Subject: [PATCH v10 12/33] counter: 104-quad-8: Add const qualifier for
 actions_list array
In-Reply-To: <92caedb694b4c66d9a5e9190f8c4545ae28dd418.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <92caedb694b4c66d9a5e9190f8c4545ae28dd418.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151813.GF8933@syed>

On Fri, Mar 19, 2021 at 08:00:31PM +0900, William Breathitt Gray wrote:
> The struct counter_synapse actions_list member expects a const enum
> counter_synapse_action array. This patch adds the const qualifier to the
> quad8_index_actions_list and quad8_synapse_actions_list to match
> actions_list.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index ae89ad7a91c6..09d779544969 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -305,12 +305,12 @@ enum quad8_synapse_action {
>  	QUAD8_SYNAPSE_ACTION_BOTH_EDGES
>  };
>  
> -static enum counter_synapse_action quad8_index_actions_list[] = {
> +static const enum counter_synapse_action quad8_index_actions_list[] = {
>  	[QUAD8_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
>  	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = COUNTER_SYNAPSE_ACTION_RISING_EDGE
>  };
>  
> -static enum counter_synapse_action quad8_synapse_actions_list[] = {
> +static const enum counter_synapse_action quad8_synapse_actions_list[] = {
>  	[QUAD8_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
>  	[QUAD8_SYNAPSE_ACTION_RISING_EDGE] = COUNTER_SYNAPSE_ACTION_RISING_EDGE,
>  	[QUAD8_SYNAPSE_ACTION_FALLING_EDGE] = COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
> -- 
> 2.30.2
>

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>


From syednwaris at gmail.com  Thu Apr 15 16:19:34 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:49:34 +0530
Subject: [PATCH v10 18/33] counter: Return error code on invalid modes
In-Reply-To: <e1dd9e43f713ccaa29e1c05d7b21d86bff02ab34.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <e1dd9e43f713ccaa29e1c05d7b21d86bff02ab34.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415151934.GG8933@syed>

On Fri, Mar 19, 2021 at 08:00:37PM +0900, William Breathitt Gray wrote:
> Only a select set of modes (function, action, etc.) are valid for a
> given device configuration. This patch ensures that invalid modes result
> in a return -EINVAL. Such a situation should never occur in reality, but
> it's good to define a default switch cases for the sake of making the
> intent of the code clear.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Cc: Kamel Bouhara <kamel.bouhara at bootlin.com>
> Cc: Fabrice Gasnier <fabrice.gasnier at st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Cc: David Lechner <david at lechnology.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c            | 20 +++++++----

For the 104-quad-8 driver:
Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

>  drivers/counter/microchip-tcb-capture.c |  6 ++++
>  drivers/counter/stm32-lptimer-cnt.c     | 10 +++---
>  drivers/counter/ti-eqep.c               | 45 +++++++++++--------------
>  4 files changed, 46 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 09d779544969..b7d6c1c43655 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -273,6 +273,10 @@ static int quad8_function_set(struct counter_device *counter,
>  			*scale = 2;
>  			mode_cfg |= QUAD8_CMR_QUADRATURE_X4;
>  			break;
> +		default:
> +			/* should never reach this path */
> +			mutex_unlock(&priv->lock);
> +			return -EINVAL;
>  		}
>  	}
>  
> @@ -349,7 +353,7 @@ static int quad8_action_get(struct counter_device *counter,
>  	case QUAD8_COUNT_FUNCTION_PULSE_DIRECTION:
>  		if (synapse->signal->id == signal_a_id)
>  			*action = QUAD8_SYNAPSE_ACTION_RISING_EDGE;
> -		break;
> +		return 0;
>  	case QUAD8_COUNT_FUNCTION_QUADRATURE_X1:
>  		if (synapse->signal->id == signal_a_id) {
>  			quad8_direction_get(counter, count, &direction);
> @@ -359,17 +363,18 @@ static int quad8_action_get(struct counter_device *counter,
>  			else
>  				*action = QUAD8_SYNAPSE_ACTION_FALLING_EDGE;
>  		}
> -		break;
> +		return 0;
>  	case QUAD8_COUNT_FUNCTION_QUADRATURE_X2:
>  		if (synapse->signal->id == signal_a_id)
>  			*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
> -		break;
> +		return 0;
>  	case QUAD8_COUNT_FUNCTION_QUADRATURE_X4:
>  		*action = QUAD8_SYNAPSE_ACTION_BOTH_EDGES;
> -		break;
> +		return 0;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
> -
> -	return 0;
>  }
>  
>  static const struct counter_ops quad8_ops = {
> @@ -529,6 +534,9 @@ static int quad8_count_mode_set(struct counter_device *counter,
>  	case COUNTER_COUNT_MODE_MODULO_N:
>  		cnt_mode = 3;
>  		break;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
>  
>  	mutex_lock(&priv->lock);
> diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
> index 51b8af80f98b..0c9a61962911 100644
> --- a/drivers/counter/microchip-tcb-capture.c
> +++ b/drivers/counter/microchip-tcb-capture.c
> @@ -133,6 +133,9 @@ static int mchp_tc_count_function_set(struct counter_device *counter,
>  		bmr |= ATMEL_TC_QDEN | ATMEL_TC_POSEN;
>  		cmr |= ATMEL_TC_ETRGEDG_RISING | ATMEL_TC_ABETRG | ATMEL_TC_XC0;
>  		break;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
>  
>  	regmap_write(priv->regmap, ATMEL_TC_BMR, bmr);
> @@ -226,6 +229,9 @@ static int mchp_tc_count_action_set(struct counter_device *counter,
>  	case MCHP_TC_SYNAPSE_ACTION_BOTH_EDGE:
>  		edge = ATMEL_TC_ETRGEDG_BOTH;
>  		break;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
>  
>  	return regmap_write_bits(priv->regmap,
> diff --git a/drivers/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
> index c19d998df5ba..78f383b77bd2 100644
> --- a/drivers/counter/stm32-lptimer-cnt.c
> +++ b/drivers/counter/stm32-lptimer-cnt.c
> @@ -206,9 +206,10 @@ static int stm32_lptim_cnt_function_set(struct counter_device *counter,
>  		priv->quadrature_mode = 1;
>  		priv->polarity = STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES;
>  		return 0;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
> -
> -	return -EINVAL;
>  }
>  
>  static ssize_t stm32_lptim_cnt_enable_read(struct counter_device *counter,
> @@ -326,9 +327,10 @@ static int stm32_lptim_cnt_action_get(struct counter_device *counter,
>  	case STM32_LPTIM_ENCODER_BOTH_EDGE:
>  		*action = priv->polarity;
>  		return 0;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
>  	}
> -
> -	return -EINVAL;
>  }
>  
>  static int stm32_lptim_cnt_action_set(struct counter_device *counter,
> diff --git a/drivers/counter/ti-eqep.c b/drivers/counter/ti-eqep.c
> index 65df9ef5b5bc..878725c2f010 100644
> --- a/drivers/counter/ti-eqep.c
> +++ b/drivers/counter/ti-eqep.c
> @@ -157,44 +157,39 @@ static int ti_eqep_action_get(struct counter_device *counter,
>  		 * QEPA and QEPB trigger QCLK.
>  		 */
>  		*action = TI_EQEP_SYNAPSE_ACTION_BOTH_EDGES;
> -		break;
> +		return 0;
>  	case TI_EQEP_COUNT_FUNC_DIR_COUNT:
>  		/* In direction-count mode only rising edge of QEPA is counted
>  		 * and QEPB gives direction.
>  		 */
> -		switch (synapse->signal->id) {
> -		case TI_EQEP_SIGNAL_QEPA:
> -			*action = TI_EQEP_SYNAPSE_ACTION_RISING_EDGE;
> -			break;
> -		default:
> +		if (synapse->signal->id == TI_EQEP_SIGNAL_QEPB)
>  			*action = TI_EQEP_SYNAPSE_ACTION_NONE;
> -			break;
> -		}
> -		break;
> +		else
> +			*action = TI_EQEP_SYNAPSE_ACTION_RISING_EDGE;
> +		return 0;
>  	case TI_EQEP_COUNT_FUNC_UP_COUNT:
>  	case TI_EQEP_COUNT_FUNC_DOWN_COUNT:
>  		/* In up/down-count modes only QEPA is counted and QEPB is not
>  		 * used.
>  		 */
> -		switch (synapse->signal->id) {
> -		case TI_EQEP_SIGNAL_QEPA:
> -			err = regmap_read(priv->regmap16, QDECCTL, &qdecctl);
> -			if (err)
> -				return err;
> -
> -			if (qdecctl & QDECCTL_XCR)
> -				*action = TI_EQEP_SYNAPSE_ACTION_BOTH_EDGES;
> -			else
> -				*action = TI_EQEP_SYNAPSE_ACTION_RISING_EDGE;
> -			break;
> -		default:
> +		if (synapse->signal->id == TI_EQEP_SIGNAL_QEPB) {
>  			*action = TI_EQEP_SYNAPSE_ACTION_NONE;
> -			break;
> +			return 0;
>  		}
> -		break;
> -	}
>  
> -	return 0;
> +		err = regmap_read(priv->regmap16, QDECCTL, &qdecctl);
> +		if (err)
> +			return err;
> +
> +		if (qdecctl & QDECCTL_XCR)
> +			*action = TI_EQEP_SYNAPSE_ACTION_BOTH_EDGES;
> +		else
> +			*action = TI_EQEP_SYNAPSE_ACTION_RISING_EDGE;
> +		return 0;
> +	default:
> +		/* should never reach this path */
> +		return -EINVAL;
> +	}
>  }
>  
>  static const struct counter_ops ti_eqep_counter_ops = {
> -- 
> 2.30.2
> 


From syednwaris at gmail.com  Thu Apr 15 16:20:31 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:50:31 +0530
Subject: [PATCH v10 19/33] counter: Standardize to ERANGE for limit
 exceeded errors
In-Reply-To: <f09068dd8b89aa81c4310ea39cbdb0d631dddf98.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <f09068dd8b89aa81c4310ea39cbdb0d631dddf98.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415152031.GH8933@syed>

On Fri, Mar 19, 2021 at 08:00:38PM +0900, William Breathitt Gray wrote:
> ERANGE is a semantically better error code to return when an argument
> value falls outside the supported limit range of a device.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Cc: Oleksij Rempel <o.rempel at pengutronix.de>
> Cc: Fabrice Gasnier <fabrice.gasnier at st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Reviewed-by: David Lechner <david at lechnology.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c        | 6 +++---

For the 104-quad-8 driver:
Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

>  drivers/counter/interrupt-cnt.c     | 3 +++
>  drivers/counter/stm32-lptimer-cnt.c | 2 +-
>  3 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index b7d6c1c43655..0409b1771fd9 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -154,7 +154,7 @@ static int quad8_count_write(struct counter_device *counter,
>  
>  	/* Only 24-bit values are supported */
>  	if (val > 0xFFFFFF)
> -		return -EINVAL;
> +		return -ERANGE;
>  
>  	mutex_lock(&priv->lock);
>  
> @@ -669,7 +669,7 @@ static ssize_t quad8_count_preset_write(struct counter_device *counter,
>  
>  	/* Only 24-bit values are supported */
>  	if (preset > 0xFFFFFF)
> -		return -EINVAL;
> +		return -ERANGE;
>  
>  	mutex_lock(&priv->lock);
>  
> @@ -714,7 +714,7 @@ static ssize_t quad8_count_ceiling_write(struct counter_device *counter,
>  
>  	/* Only 24-bit values are supported */
>  	if (ceiling > 0xFFFFFF)
> -		return -EINVAL;
> +		return -ERANGE;
>  
>  	mutex_lock(&priv->lock);
>  
> diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c
> index 0e07607f2cd3..f27dea317965 100644
> --- a/drivers/counter/interrupt-cnt.c
> +++ b/drivers/counter/interrupt-cnt.c
> @@ -107,6 +107,9 @@ static int interrupt_cnt_write(struct counter_device *counter,
>  {
>  	struct interrupt_cnt_priv *priv = counter->priv;
>  
> +	if (val != (typeof(priv->count.counter))val)
> +		return -ERANGE;
> +
>  	atomic_set(&priv->count, val);
>  
>  	return 0;
> diff --git a/drivers/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
> index 78f383b77bd2..49aeb9e393f3 100644
> --- a/drivers/counter/stm32-lptimer-cnt.c
> +++ b/drivers/counter/stm32-lptimer-cnt.c
> @@ -283,7 +283,7 @@ static ssize_t stm32_lptim_cnt_ceiling_write(struct counter_device *counter,
>  		return ret;
>  
>  	if (ceiling > STM32_LPTIM_MAX_ARR)
> -		return -EINVAL;
> +		return -ERANGE;
>  
>  	priv->ceiling = ceiling;
>  
> -- 
> 2.30.2
> 


From syednwaris at gmail.com  Thu Apr 15 16:21:13 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:51:13 +0530
Subject: [PATCH v10 20/33] counter: Rename counter_signal_value to
 counter_signal_level
In-Reply-To: <33a89af04c3dbba1c9d2f97927b7c2ffcd921af9.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <33a89af04c3dbba1c9d2f97927b7c2ffcd921af9.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415152113.GI8933@syed>

On Fri, Mar 19, 2021 at 08:00:39PM +0900, William Breathitt Gray wrote:
> Signal values will always be levels so let's be explicit it about it to
> make the intent of the code clear.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Cc: Oleksij Rempel <o.rempel at pengutronix.de>
> Cc: Kamel Bouhara <kamel.bouhara at bootlin.com>
> Reviewed-by: David Lechner <david at lechnology.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c            |  5 +++--

For the 104-quad-8 driver:
Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

>  drivers/counter/counter.c               | 12 ++++++------
>  drivers/counter/interrupt-cnt.c         |  4 ++--
>  drivers/counter/microchip-tcb-capture.c |  4 ++--
>  include/linux/counter.h                 | 12 ++++++------
>  5 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index 0409b1771fd9..fb0f021c0751 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -97,7 +97,8 @@ struct quad8 {
>  #define QUAD8_CMR_QUADRATURE_X4 0x18
>  
>  static int quad8_signal_read(struct counter_device *counter,
> -	struct counter_signal *signal, enum counter_signal_value *val)
> +			     struct counter_signal *signal,
> +			     enum counter_signal_level *level)
>  {
>  	const struct quad8 *const priv = counter->priv;
>  	unsigned int state;
> @@ -109,7 +110,7 @@ static int quad8_signal_read(struct counter_device *counter,
>  	state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
>  		& BIT(signal->id - 16);
>  
> -	*val = (state) ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
> +	*level = (state) ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
>  
>  	return 0;
>  }
> diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
> index 6a683d086008..cb92673552b5 100644
> --- a/drivers/counter/counter.c
> +++ b/drivers/counter/counter.c
> @@ -289,9 +289,9 @@ struct counter_signal_unit {
>  	struct counter_signal *signal;
>  };
>  
> -static const char *const counter_signal_value_str[] = {
> -	[COUNTER_SIGNAL_LOW] = "low",
> -	[COUNTER_SIGNAL_HIGH] = "high"
> +static const char *const counter_signal_level_str[] = {
> +	[COUNTER_SIGNAL_LEVEL_LOW] = "low",
> +	[COUNTER_SIGNAL_LEVEL_HIGH] = "high"
>  };
>  
>  static ssize_t counter_signal_show(struct device *dev,
> @@ -302,13 +302,13 @@ static ssize_t counter_signal_show(struct device *dev,
>  	const struct counter_signal_unit *const component = devattr->component;
>  	struct counter_signal *const signal = component->signal;
>  	int err;
> -	enum counter_signal_value val;
> +	enum counter_signal_level level;
>  
> -	err = counter->ops->signal_read(counter, signal, &val);
> +	err = counter->ops->signal_read(counter, signal, &level);
>  	if (err)
>  		return err;
>  
> -	return sprintf(buf, "%s\n", counter_signal_value_str[val]);
> +	return sprintf(buf, "%s\n", counter_signal_level_str[level]);
>  }
>  
>  struct counter_name_unit {
> diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c
> index f27dea317965..cce579c1c6ae 100644
> --- a/drivers/counter/interrupt-cnt.c
> +++ b/drivers/counter/interrupt-cnt.c
> @@ -130,7 +130,7 @@ static int interrupt_cnt_function_get(struct counter_device *counter,
>  
>  static int interrupt_cnt_signal_read(struct counter_device *counter,
>  				     struct counter_signal *signal,
> -				     enum counter_signal_value *val)
> +				     enum counter_signal_level *level)
>  {
>  	struct interrupt_cnt_priv *priv = counter->priv;
>  	int ret;
> @@ -142,7 +142,7 @@ static int interrupt_cnt_signal_read(struct counter_device *counter,
>  	if (ret < 0)
>  		return ret;
>  
> -	*val = ret ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
> +	*level = ret ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
>  
>  	return 0;
>  }
> diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
> index 0c9a61962911..6be3adf74114 100644
> --- a/drivers/counter/microchip-tcb-capture.c
> +++ b/drivers/counter/microchip-tcb-capture.c
> @@ -158,7 +158,7 @@ static int mchp_tc_count_function_set(struct counter_device *counter,
>  
>  static int mchp_tc_count_signal_read(struct counter_device *counter,
>  				     struct counter_signal *signal,
> -				     enum counter_signal_value *val)
> +				     enum counter_signal_level *lvl)
>  {
>  	struct mchp_tc_data *const priv = counter->priv;
>  	bool sigstatus;
> @@ -171,7 +171,7 @@ static int mchp_tc_count_signal_read(struct counter_device *counter,
>  	else
>  		sigstatus = (sr & ATMEL_TC_MTIOA);
>  
> -	*val = sigstatus ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
> +	*lvl = sigstatus ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
>  
>  	return 0;
>  }
> diff --git a/include/linux/counter.h b/include/linux/counter.h
> index 9dbd5df4cd34..79f5dcaf6ba0 100644
> --- a/include/linux/counter.h
> +++ b/include/linux/counter.h
> @@ -290,16 +290,16 @@ struct counter_device_state {
>  	const struct attribute_group **groups;
>  };
>  
> -enum counter_signal_value {
> -	COUNTER_SIGNAL_LOW = 0,
> -	COUNTER_SIGNAL_HIGH
> +enum counter_signal_level {
> +	COUNTER_SIGNAL_LEVEL_LOW,
> +	COUNTER_SIGNAL_LEVEL_HIGH,
>  };
>  
>  /**
>   * struct counter_ops - Callbacks from driver
>   * @signal_read:	optional read callback for Signal attribute. The read
> - *			value of the respective Signal should be passed back via
> - *			the val parameter.
> + *			level of the respective Signal should be passed back via
> + *			the level parameter.
>   * @count_read:		optional read callback for Count attribute. The read
>   *			value of the respective Count should be passed back via
>   *			the val parameter.
> @@ -324,7 +324,7 @@ enum counter_signal_value {
>  struct counter_ops {
>  	int (*signal_read)(struct counter_device *counter,
>  			   struct counter_signal *signal,
> -			   enum counter_signal_value *val);
> +			   enum counter_signal_level *level);
>  	int (*count_read)(struct counter_device *counter,
>  			  struct counter_count *count, unsigned long *val);
>  	int (*count_write)(struct counter_device *counter,
> -- 
> 2.30.2
> 


From syednwaris at gmail.com  Thu Apr 15 16:22:17 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:52:17 +0530
Subject: [PATCH v10 21/33] counter: Rename counter_count_function to
 counter_function
In-Reply-To: <a0e07cf7131556233bbd0236a944a032451c79ae.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <a0e07cf7131556233bbd0236a944a032451c79ae.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415152217.GJ8933@syed>

On Fri, Mar 19, 2021 at 08:00:40PM +0900, William Breathitt Gray wrote:
> The phrase "Counter Count function" is verbose and unintentionally
> implies that function is a Count extension. This patch adjusts the
> Counter subsystem code to use the more direct "Counter function" phrase
> to make the intent of this code clearer.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Cc: Patrick Havelange <patrick.havelange at essensium.com>
> Cc: Oleksij Rempel <o.rempel at pengutronix.de>
> Cc: Kamel Bouhara <kamel.bouhara at bootlin.com>
> Cc: Fabrice Gasnier <fabrice.gasnier at st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Alexandre Torgue <alexandre.torgue at st.com>
> Cc: David Lechner <david at lechnology.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c            | 10 +++----

For the 104-quad-8 driver:
Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

>  drivers/counter/counter.c               | 38 ++++++++++++-------------
>  drivers/counter/ftm-quaddec.c           |  5 ++--
>  drivers/counter/interrupt-cnt.c         |  4 +--
>  drivers/counter/microchip-tcb-capture.c |  4 +--
>  drivers/counter/stm32-lptimer-cnt.c     |  6 ++--
>  drivers/counter/stm32-timer-cnt.c       | 10 +++----
>  drivers/counter/ti-eqep.c               | 10 +++----
>  include/linux/counter.h                 | 20 ++++++-------
>  9 files changed, 53 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index fb0f021c0751..5a49ace2d4a6 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -194,11 +194,11 @@ enum quad8_count_function {
>  	QUAD8_COUNT_FUNCTION_QUADRATURE_X4
>  };
>  
> -static const enum counter_count_function quad8_count_functions_list[] = {
> -	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
> -	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A,
> -	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
> -	[QUAD8_COUNT_FUNCTION_QUADRATURE_X4] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4
> +static const enum counter_function quad8_count_functions_list[] = {
> +	[QUAD8_COUNT_FUNCTION_PULSE_DIRECTION] = COUNTER_FUNCTION_PULSE_DIRECTION,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X1] = COUNTER_FUNCTION_QUADRATURE_X1_A,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X2] = COUNTER_FUNCTION_QUADRATURE_X2_A,
> +	[QUAD8_COUNT_FUNCTION_QUADRATURE_X4] = COUNTER_FUNCTION_QUADRATURE_X4
>  };
>  
>  static int quad8_function_get(struct counter_device *counter,
> diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
> index cb92673552b5..de921e8a3f72 100644
> --- a/drivers/counter/counter.c
> +++ b/drivers/counter/counter.c
> @@ -744,15 +744,15 @@ static ssize_t counter_count_store(struct device *dev,
>  	return len;
>  }
>  
> -static const char *const counter_count_function_str[] = {
> -	[COUNTER_COUNT_FUNCTION_INCREASE] = "increase",
> -	[COUNTER_COUNT_FUNCTION_DECREASE] = "decrease",
> -	[COUNTER_COUNT_FUNCTION_PULSE_DIRECTION] = "pulse-direction",
> -	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A] = "quadrature x1 a",
> -	[COUNTER_COUNT_FUNCTION_QUADRATURE_X1_B] = "quadrature x1 b",
> -	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A] = "quadrature x2 a",
> -	[COUNTER_COUNT_FUNCTION_QUADRATURE_X2_B] = "quadrature x2 b",
> -	[COUNTER_COUNT_FUNCTION_QUADRATURE_X4] = "quadrature x4"
> +static const char *const counter_function_str[] = {
> +	[COUNTER_FUNCTION_INCREASE] = "increase",
> +	[COUNTER_FUNCTION_DECREASE] = "decrease",
> +	[COUNTER_FUNCTION_PULSE_DIRECTION] = "pulse-direction",
> +	[COUNTER_FUNCTION_QUADRATURE_X1_A] = "quadrature x1 a",
> +	[COUNTER_FUNCTION_QUADRATURE_X1_B] = "quadrature x1 b",
> +	[COUNTER_FUNCTION_QUADRATURE_X2_A] = "quadrature x2 a",
> +	[COUNTER_FUNCTION_QUADRATURE_X2_B] = "quadrature x2 b",
> +	[COUNTER_FUNCTION_QUADRATURE_X4] = "quadrature x4"
>  };
>  
>  static ssize_t counter_function_show(struct device *dev,
> @@ -764,7 +764,7 @@ static ssize_t counter_function_show(struct device *dev,
>  	const struct counter_count_unit *const component = devattr->component;
>  	struct counter_count *const count = component->count;
>  	size_t func_index;
> -	enum counter_count_function function;
> +	enum counter_function function;
>  
>  	err = counter->ops->function_get(counter, count, &func_index);
>  	if (err)
> @@ -773,7 +773,7 @@ static ssize_t counter_function_show(struct device *dev,
>  	count->function = func_index;
>  
>  	function = count->functions_list[func_index];
> -	return sprintf(buf, "%s\n", counter_count_function_str[function]);
> +	return sprintf(buf, "%s\n", counter_function_str[function]);
>  }
>  
>  static ssize_t counter_function_store(struct device *dev,
> @@ -785,14 +785,14 @@ static ssize_t counter_function_store(struct device *dev,
>  	struct counter_count *const count = component->count;
>  	const size_t num_functions = count->num_functions;
>  	size_t func_index;
> -	enum counter_count_function function;
> +	enum counter_function function;
>  	int err;
>  	struct counter_device *const counter = dev_get_drvdata(dev);
>  
>  	/* Find requested Count function mode */
>  	for (func_index = 0; func_index < num_functions; func_index++) {
>  		function = count->functions_list[func_index];
> -		if (sysfs_streq(buf, counter_count_function_str[function]))
> +		if (sysfs_streq(buf, counter_function_str[function]))
>  			break;
>  	}
>  	/* Return error if requested Count function mode not found */
> @@ -880,25 +880,25 @@ static int counter_count_ext_register(
>  }
>  
>  struct counter_func_avail_unit {
> -	const enum counter_count_function *functions_list;
> +	const enum counter_function *functions_list;
>  	size_t num_functions;
>  };
>  
> -static ssize_t counter_count_function_available_show(struct device *dev,
> +static ssize_t counter_function_available_show(struct device *dev,
>  	struct device_attribute *attr, char *buf)
>  {
>  	const struct counter_device_attr *const devattr = to_counter_attr(attr);
>  	const struct counter_func_avail_unit *const component = devattr->component;
> -	const enum counter_count_function *const func_list = component->functions_list;
> +	const enum counter_function *const func_list = component->functions_list;
>  	const size_t num_functions = component->num_functions;
>  	size_t i;
> -	enum counter_count_function function;
> +	enum counter_function function;
>  	ssize_t len = 0;
>  
>  	for (i = 0; i < num_functions; i++) {
>  		function = func_list[i];
>  		len += sprintf(buf + len, "%s\n",
> -			       counter_count_function_str[function]);
> +			       counter_function_str[function]);
>  	}
>  
>  	return len;
> @@ -968,7 +968,7 @@ static int counter_count_attributes_create(
>  	parm.group = group;
>  	parm.prefix = "";
>  	parm.name = "function_available";
> -	parm.show = counter_count_function_available_show;
> +	parm.show = counter_function_available_show;
>  	parm.store = NULL;
>  	parm.component = avail_comp;
>  	err = counter_attribute_create(&parm);
> diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
> index 9371532406ca..53c15f84909b 100644
> --- a/drivers/counter/ftm-quaddec.c
> +++ b/drivers/counter/ftm-quaddec.c
> @@ -171,9 +171,8 @@ enum ftm_quaddec_count_function {
>  	FTM_QUADDEC_COUNT_ENCODER_MODE_1,
>  };
>  
> -static const enum counter_count_function ftm_quaddec_count_functions[] = {
> -	[FTM_QUADDEC_COUNT_ENCODER_MODE_1] =
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X4
> +static const enum counter_function ftm_quaddec_count_functions[] = {
> +	[FTM_QUADDEC_COUNT_ENCODER_MODE_1] = COUNTER_FUNCTION_QUADRATURE_X4
>  };
>  
>  static int ftm_quaddec_count_read(struct counter_device *counter,
> diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c
> index cce579c1c6ae..3dbb8acc67eb 100644
> --- a/drivers/counter/interrupt-cnt.c
> +++ b/drivers/counter/interrupt-cnt.c
> @@ -115,8 +115,8 @@ static int interrupt_cnt_write(struct counter_device *counter,
>  	return 0;
>  }
>  
> -static const enum counter_count_function interrupt_cnt_functions[] = {
> -	COUNTER_COUNT_FUNCTION_INCREASE,
> +static const enum counter_function interrupt_cnt_functions[] = {
> +	COUNTER_FUNCTION_INCREASE,
>  };
>  
>  static int interrupt_cnt_function_get(struct counter_device *counter,
> diff --git a/drivers/counter/microchip-tcb-capture.c b/drivers/counter/microchip-tcb-capture.c
> index 6be3adf74114..4c57d43e7d66 100644
> --- a/drivers/counter/microchip-tcb-capture.c
> +++ b/drivers/counter/microchip-tcb-capture.c
> @@ -38,8 +38,8 @@ enum mchp_tc_count_function {
>  };
>  
>  static const enum counter_count_function mchp_tc_count_functions[] = {
> -	[MCHP_TC_FUNCTION_INCREASE] = COUNTER_COUNT_FUNCTION_INCREASE,
> -	[MCHP_TC_FUNCTION_QUADRATURE] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
> +	[MCHP_TC_FUNCTION_INCREASE] = COUNTER_FUNCTION_INCREASE,
> +	[MCHP_TC_FUNCTION_QUADRATURE] = COUNTER_FUNCTION_QUADRATURE_X4,
>  };
>  
>  enum mchp_tc_synapse_action {
> diff --git a/drivers/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
> index 49aeb9e393f3..13656957c45f 100644
> --- a/drivers/counter/stm32-lptimer-cnt.c
> +++ b/drivers/counter/stm32-lptimer-cnt.c
> @@ -134,9 +134,9 @@ enum stm32_lptim_cnt_function {
>  	STM32_LPTIM_ENCODER_BOTH_EDGE,
>  };
>  
> -static const enum counter_count_function stm32_lptim_cnt_functions[] = {
> -	[STM32_LPTIM_COUNTER_INCREASE] = COUNTER_COUNT_FUNCTION_INCREASE,
> -	[STM32_LPTIM_ENCODER_BOTH_EDGE] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
> +static const enum counter_function stm32_lptim_cnt_functions[] = {
> +	[STM32_LPTIM_COUNTER_INCREASE] = COUNTER_FUNCTION_INCREASE,
> +	[STM32_LPTIM_ENCODER_BOTH_EDGE] = COUNTER_FUNCTION_QUADRATURE_X4,
>  };
>  
>  enum stm32_lptim_synapse_action {
> diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
> index 603b30ada839..3fb0debd7425 100644
> --- a/drivers/counter/stm32-timer-cnt.c
> +++ b/drivers/counter/stm32-timer-cnt.c
> @@ -50,11 +50,11 @@ enum stm32_count_function {
>  	STM32_COUNT_ENCODER_MODE_3,
>  };
>  
> -static const enum counter_count_function stm32_count_functions[] = {
> -	[STM32_COUNT_SLAVE_MODE_DISABLED] = COUNTER_COUNT_FUNCTION_INCREASE,
> -	[STM32_COUNT_ENCODER_MODE_1] = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
> -	[STM32_COUNT_ENCODER_MODE_2] = COUNTER_COUNT_FUNCTION_QUADRATURE_X2_B,
> -	[STM32_COUNT_ENCODER_MODE_3] = COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
> +static const enum counter_function stm32_count_functions[] = {
> +	[STM32_COUNT_SLAVE_MODE_DISABLED] = COUNTER_FUNCTION_INCREASE,
> +	[STM32_COUNT_ENCODER_MODE_1] = COUNTER_FUNCTION_QUADRATURE_X2_A,
> +	[STM32_COUNT_ENCODER_MODE_2] = COUNTER_FUNCTION_QUADRATURE_X2_B,
> +	[STM32_COUNT_ENCODER_MODE_3] = COUNTER_FUNCTION_QUADRATURE_X4,
>  };
>  
>  static int stm32_count_read(struct counter_device *counter,
> diff --git a/drivers/counter/ti-eqep.c b/drivers/counter/ti-eqep.c
> index 878725c2f010..04be25ebf4a4 100644
> --- a/drivers/counter/ti-eqep.c
> +++ b/drivers/counter/ti-eqep.c
> @@ -284,11 +284,11 @@ static struct counter_signal ti_eqep_signals[] = {
>  	},
>  };
>  
> -static const enum counter_count_function ti_eqep_position_functions[] = {
> -	[TI_EQEP_COUNT_FUNC_QUAD_COUNT]	= COUNTER_COUNT_FUNCTION_QUADRATURE_X4,
> -	[TI_EQEP_COUNT_FUNC_DIR_COUNT]	= COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
> -	[TI_EQEP_COUNT_FUNC_UP_COUNT]	= COUNTER_COUNT_FUNCTION_INCREASE,
> -	[TI_EQEP_COUNT_FUNC_DOWN_COUNT]	= COUNTER_COUNT_FUNCTION_DECREASE,
> +static const enum counter_function ti_eqep_position_functions[] = {
> +	[TI_EQEP_COUNT_FUNC_QUAD_COUNT]	= COUNTER_FUNCTION_QUADRATURE_X4,
> +	[TI_EQEP_COUNT_FUNC_DIR_COUNT]	= COUNTER_FUNCTION_PULSE_DIRECTION,
> +	[TI_EQEP_COUNT_FUNC_UP_COUNT]	= COUNTER_FUNCTION_INCREASE,
> +	[TI_EQEP_COUNT_FUNC_DOWN_COUNT]	= COUNTER_FUNCTION_DECREASE,
>  };
>  
>  static const enum counter_synapse_action ti_eqep_position_synapse_actions[] = {
> diff --git a/include/linux/counter.h b/include/linux/counter.h
> index 79f5dcaf6ba0..d16ce2819b48 100644
> --- a/include/linux/counter.h
> +++ b/include/linux/counter.h
> @@ -162,15 +162,15 @@ struct counter_count_ext {
>  	void *priv;
>  };
>  
> -enum counter_count_function {
> -	COUNTER_COUNT_FUNCTION_INCREASE = 0,
> -	COUNTER_COUNT_FUNCTION_DECREASE,
> -	COUNTER_COUNT_FUNCTION_PULSE_DIRECTION,
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X1_A,
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X1_B,
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X2_A,
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X2_B,
> -	COUNTER_COUNT_FUNCTION_QUADRATURE_X4
> +enum counter_function {
> +	COUNTER_FUNCTION_INCREASE = 0,
> +	COUNTER_FUNCTION_DECREASE,
> +	COUNTER_FUNCTION_PULSE_DIRECTION,
> +	COUNTER_FUNCTION_QUADRATURE_X1_A,
> +	COUNTER_FUNCTION_QUADRATURE_X1_B,
> +	COUNTER_FUNCTION_QUADRATURE_X2_A,
> +	COUNTER_FUNCTION_QUADRATURE_X2_B,
> +	COUNTER_FUNCTION_QUADRATURE_X4
>  };
>  
>  /**
> @@ -192,7 +192,7 @@ struct counter_count {
>  	const char *name;
>  
>  	size_t function;
> -	const enum counter_count_function *functions_list;
> +	const enum counter_function *functions_list;
>  	size_t num_functions;
>  
>  	struct counter_synapse *synapses;
> -- 
> 2.30.2
> 


From leo.yan at linaro.org  Thu Apr 15 16:23:48 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 15 Apr 2021 23:23:48 +0800
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized
 event
In-Reply-To: <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-5-leo.yan@linaro.org>
 <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>
Message-ID: <20210415152348.GF1011890@leoy-ThinkPad-X240s>

On Thu, Apr 15, 2021 at 05:46:31PM +0300, James Clark wrote:
> 
> 
> On 12/04/2021 12:10, Leo Yan wrote:
> > In current code, it assigns the arch timer counter to the synthesized
> > samples Arm SPE trace, thus the samples don't contain the kernel time
> > but only contain the raw counter value.
> > 
> > To fix the issue, this patch converts the timer counter to kernel time
> > and assigns it to sample timestamp.
> > 
> > Signed-off-by: Leo Yan <leo.yan at linaro.org>
> > ---
> >  tools/perf/util/arm-spe.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> > index 23714cf0380e..c13a89f06ab8 100644
> > --- a/tools/perf/util/arm-spe.c
> > +++ b/tools/perf/util/arm-spe.c
> > @@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
> >  	struct arm_spe_record *record = &speq->decoder->record;
> >  
> >  	if (!spe->timeless_decoding)
> > -		sample->time = speq->timestamp;
> > +		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
> 
> 
> I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options.
> I don't know of a way to remove this, and if there isn't, does that mean that all the code in this
> file that looks at spe->timeless_decoding is untested and has never been hit?
> 
> Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one
> might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding
> is always false.

Good point.  To be honest, I never noticed this issue until you
mentioned this.

We should fix for the "timeless" flow; and it's questionable for the
function arm_spe_recording_options(), except for setting
PERF_SAMPLE_TIME, it also hard codes for setting
PERF_SAMPLE_CPU and PERF_SAMPLE_TID.  Might need to carefully go
through this function.

Thanks,
Leo


From syednwaris at gmail.com  Thu Apr 15 16:24:09 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:54:09 +0530
Subject: [PATCH v10 32/33] counter: 104-quad-8: Replace mutex with spinlock
In-Reply-To: <52016584522ed9b733cd52057f6974c274e34003.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <52016584522ed9b733cd52057f6974c274e34003.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415152409.GK8933@syed>

On Fri, Mar 19, 2021 at 08:00:51PM +0900, William Breathitt Gray wrote:
> This patch replaces the mutex I/O lock with a spinlock. This is in
> preparation for a subsequent patch adding IRQ support for 104-QUAD-8
> devices; we can't sleep in an interrupt context, so we'll need to use a
> spinlock instead.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 90 +++++++++++++++++++++---------------
>  1 file changed, 53 insertions(+), 37 deletions(-)

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index eb7d63769f4c..d46b8101f207 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -16,6 +16,7 @@
>  #include <linux/module.h>
>  #include <linux/moduleparam.h>
>  #include <linux/types.h>
> +#include <linux/spinlock.h>
>  
>  #define QUAD8_EXTENT 32
>  
> @@ -28,6 +29,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>  
>  /**
>   * struct quad8 - device private data structure
> + * @lock:		lock to prevent clobbering device states during R/W ops
>   * @counter:		instance of the counter_device
>   * @fck_prescaler:	array of filter clock prescaler configurations
>   * @preset:		array of preset values
> @@ -42,7 +44,7 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>   * @base:		base port address of the device
>   */
>  struct quad8 {
> -	struct mutex lock;
> +	spinlock_t lock;
>  	struct counter_device counter;
>  	unsigned int fck_prescaler[QUAD8_NUM_COUNTERS];
>  	unsigned int preset[QUAD8_NUM_COUNTERS];
> @@ -123,6 +125,7 @@ static int quad8_count_read(struct counter_device *counter,
>  	unsigned int flags;
>  	unsigned int borrow;
>  	unsigned int carry;
> +	unsigned long irqflags;
>  	int i;
>  
>  	flags = inb(base_offset + 1);
> @@ -132,7 +135,7 @@ static int quad8_count_read(struct counter_device *counter,
>  	/* Borrow XOR Carry effectively doubles count range */
>  	*val = (unsigned long)(borrow ^ carry) << 24;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	/* Reset Byte Pointer; transfer Counter to Output Latch */
>  	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
> @@ -141,7 +144,7 @@ static int quad8_count_read(struct counter_device *counter,
>  	for (i = 0; i < 3; i++)
>  		*val |= (unsigned long)inb(base_offset) << (8 * i);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -151,13 +154,14 @@ static int quad8_count_write(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const int base_offset = priv->base + 2 * count->id;
> +	unsigned long irqflags;
>  	int i;
>  
>  	/* Only 24-bit values are supported */
>  	if (val > 0xFFFFFF)
>  		return -ERANGE;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	/* Reset Byte Pointer */
>  	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
> @@ -182,7 +186,7 @@ static int quad8_count_write(struct counter_device *counter,
>  	/* Reset Error flag */
>  	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_E, base_offset + 1);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -200,8 +204,9 @@ static int quad8_function_read(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const int id = count->id;
> +	unsigned long irqflags;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	if (priv->quadrature_mode[id])
>  		switch (priv->quadrature_scale[id]) {
> @@ -218,7 +223,7 @@ static int quad8_function_read(struct counter_device *counter,
>  	else
>  		*function = COUNTER_FUNCTION_PULSE_DIRECTION;
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -233,10 +238,11 @@ static int quad8_function_write(struct counter_device *counter,
>  	unsigned int *const scale = priv->quadrature_scale + id;
>  	unsigned int *const synchronous_mode = priv->synchronous_mode + id;
>  	const int base_offset = priv->base + 2 * id + 1;
> +	unsigned long irqflags;
>  	unsigned int mode_cfg;
>  	unsigned int idr_cfg;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	mode_cfg = priv->count_mode[id] << 1;
>  	idr_cfg = priv->index_polarity[id] << 1;
> @@ -271,7 +277,7 @@ static int quad8_function_write(struct counter_device *counter,
>  			break;
>  		default:
>  			/* should never reach this path */
> -			mutex_unlock(&priv->lock);
> +			spin_unlock_irqrestore(&priv->lock, irqflags);
>  			return -EINVAL;
>  		}
>  	}
> @@ -279,7 +285,7 @@ static int quad8_function_write(struct counter_device *counter,
>  	/* Load mode configuration to Counter Mode Register */
>  	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -405,9 +411,10 @@ static int quad8_index_polarity_set(struct counter_device *counter,
>  	struct quad8 *const priv = counter->priv;
>  	const size_t channel_id = signal->id - 16;
>  	const int base_offset = priv->base + 2 * channel_id + 1;
> +	unsigned long irqflags;
>  	unsigned int idr_cfg = index_polarity << 1;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	idr_cfg |= priv->synchronous_mode[channel_id];
>  
> @@ -416,7 +423,7 @@ static int quad8_index_polarity_set(struct counter_device *counter,
>  	/* Load Index Control configuration to Index Control Register */
>  	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -445,15 +452,16 @@ static int quad8_synchronous_mode_set(struct counter_device *counter,
>  	struct quad8 *const priv = counter->priv;
>  	const size_t channel_id = signal->id - 16;
>  	const int base_offset = priv->base + 2 * channel_id + 1;
> +	unsigned long irqflags;
>  	unsigned int idr_cfg = synchronous_mode;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	idr_cfg |= priv->index_polarity[channel_id] << 1;
>  
>  	/* Index function must be non-synchronous in non-quadrature mode */
>  	if (synchronous_mode && !priv->quadrature_mode[channel_id]) {
> -		mutex_unlock(&priv->lock);
> +		spin_unlock_irqrestore(&priv->lock, irqflags);
>  		return -EINVAL;
>  	}
>  
> @@ -462,7 +470,7 @@ static int quad8_synchronous_mode_set(struct counter_device *counter,
>  	/* Load Index Control configuration to Index Control Register */
>  	outb(QUAD8_CTR_IDR | idr_cfg, base_offset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -509,6 +517,7 @@ static int quad8_count_mode_write(struct counter_device *counter,
>  	unsigned int count_mode;
>  	unsigned int mode_cfg;
>  	const int base_offset = priv->base + 2 * count->id + 1;
> +	unsigned long irqflags;
>  
>  	/* Map Generic Counter count mode to 104-QUAD-8 count mode */
>  	switch (cnt_mode) {
> @@ -529,7 +538,7 @@ static int quad8_count_mode_write(struct counter_device *counter,
>  		return -EINVAL;
>  	}
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	priv->count_mode[count->id] = count_mode;
>  
> @@ -543,7 +552,7 @@ static int quad8_count_mode_write(struct counter_device *counter,
>  	/* Load mode configuration to Counter Mode Register */
>  	outb(QUAD8_CTR_CMR | mode_cfg, base_offset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -563,9 +572,10 @@ static int quad8_count_enable_write(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const int base_offset = priv->base + 2 * count->id;
> +	unsigned long irqflags;
>  	unsigned int ior_cfg;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	priv->ab_enable[count->id] = enable;
>  
> @@ -574,7 +584,7 @@ static int quad8_count_enable_write(struct counter_device *counter,
>  	/* Load I/O control configuration */
>  	outb(QUAD8_CTR_IOR | ior_cfg, base_offset + 1);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -625,16 +635,17 @@ static int quad8_count_preset_write(struct counter_device *counter,
>  				    struct counter_count *count, u64 preset)
>  {
>  	struct quad8 *const priv = counter->priv;
> +	unsigned long irqflags;
>  
>  	/* Only 24-bit values are supported */
>  	if (preset > 0xFFFFFF)
>  		return -ERANGE;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	quad8_preset_register_set(priv, count->id, preset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -643,8 +654,9 @@ static int quad8_count_ceiling_read(struct counter_device *counter,
>  				    struct counter_count *count, u64 *ceiling)
>  {
>  	struct quad8 *const priv = counter->priv;
> +	unsigned long irqflags;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	/* Range Limit and Modulo-N count modes use preset value as ceiling */
>  	switch (priv->count_mode[count->id]) {
> @@ -658,7 +670,7 @@ static int quad8_count_ceiling_read(struct counter_device *counter,
>  		break;
>  	}
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -667,23 +679,24 @@ static int quad8_count_ceiling_write(struct counter_device *counter,
>  				     struct counter_count *count, u64 ceiling)
>  {
>  	struct quad8 *const priv = counter->priv;
> +	unsigned long irqflags;
>  
>  	/* Only 24-bit values are supported */
>  	if (ceiling > 0xFFFFFF)
>  		return -ERANGE;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	/* Range Limit and Modulo-N count modes use preset value as ceiling */
>  	switch (priv->count_mode[count->id]) {
>  	case 1:
>  	case 3:
> -		mutex_unlock(&priv->lock);
> +		spin_unlock_irqrestore(&priv->lock, irqflags);
>  		quad8_preset_register_set(priv, count->id, ceiling);
>  		return 0;
>  	}
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return -EINVAL;
>  }
> @@ -705,12 +718,13 @@ static int quad8_count_preset_enable_write(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const int base_offset = priv->base + 2 * count->id + 1;
> +	unsigned long irqflags;
>  	unsigned int ior_cfg;
>  
>  	/* Preset enable is active low in Input/Output Control register */
>  	preset_enable = !preset_enable;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	priv->preset_enable[count->id] = preset_enable;
>  
> @@ -719,7 +733,7 @@ static int quad8_count_preset_enable_write(struct counter_device *counter,
>  	/* Load I/O control configuration to Input / Output Control Register */
>  	outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -730,22 +744,23 @@ static int quad8_signal_cable_fault_read(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const size_t channel_id = signal->id / 2;
> +	unsigned long irqflags;
>  	bool disabled;
>  	unsigned int status;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	disabled = !(priv->cable_fault_enable & BIT(channel_id));
>  
>  	if (disabled) {
> -		mutex_unlock(&priv->lock);
> +		spin_unlock_irqrestore(&priv->lock, irqflags);
>  		return -EINVAL;
>  	}
>  
>  	/* Logic 0 = cable fault */
>  	status = inb(priv->base + QUAD8_DIFF_ENCODER_CABLE_STATUS);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	/* Mask respective channel and invert logic */
>  	*cable_fault = !(status & BIT(channel_id));
> @@ -771,9 +786,10 @@ static int quad8_signal_cable_fault_enable_write(struct counter_device *counter,
>  {
>  	struct quad8 *const priv = counter->priv;
>  	const size_t channel_id = signal->id / 2;
> +	unsigned long irqflags;
>  	unsigned int cable_fault_enable;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	if (enable)
>  		priv->cable_fault_enable |= BIT(channel_id);
> @@ -785,7 +801,7 @@ static int quad8_signal_cable_fault_enable_write(struct counter_device *counter,
>  
>  	outb(cable_fault_enable, priv->base + QUAD8_DIFF_ENCODER_CABLE_STATUS);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -808,8 +824,9 @@ static int quad8_signal_fck_prescaler_write(struct counter_device *counter,
>  	struct quad8 *const priv = counter->priv;
>  	const size_t channel_id = signal->id / 2;
>  	const int base_offset = priv->base + 2 * channel_id;
> +	unsigned long irqflags;
>  
> -	mutex_lock(&priv->lock);
> +	spin_lock_irqsave(&priv->lock, irqflags);
>  
>  	priv->fck_prescaler[channel_id] = prescaler;
>  
> @@ -821,7 +838,7 @@ static int quad8_signal_fck_prescaler_write(struct counter_device *counter,
>  	outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_PRESET_PSC,
>  	     base_offset + 1);
>  
> -	mutex_unlock(&priv->lock);
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
>  
>  	return 0;
>  }
> @@ -990,8 +1007,7 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  	priv->counter.priv = priv;
>  	priv->base = base[id];
>  
> -	/* Initialize mutex */
> -	mutex_init(&priv->lock);
> +	spin_lock_init(&priv->lock);
>  
>  	/* Reset all counters and disable interrupt function */
>  	outb(QUAD8_CHAN_OP_RESET_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
> -- 
> 2.30.2
> 


From robh at kernel.org  Thu Apr 15 16:25:00 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 10:25:00 -0500
Subject: [PATCH v2 4/7] dt-bindings: soc: mediatek: apusys: Add new
 document for APU power domain
In-Reply-To: <1618465960-3013-5-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
 <1618465960-3013-5-git-send-email-flora.fu@mediatek.com>
Message-ID: <20210415152500.GA1424680@robh.at.kernel.org>

On Thu, Apr 15, 2021 at 01:52:37PM +0800, Flora Fu wrote:
> Document the bindings for APU power domain on MediaTek SoC.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---
> Note:
> This patch depends on MT8192 clock[1] patches which haven't yet been accepted.
> [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/
> ---
>  .../soc/mediatek/mediatek,apu-pm.yaml         | 145 ++++++++++++++++++
>  1 file changed, 145 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> new file mode 100644
> index 000000000000..6ff966920917
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> @@ -0,0 +1,145 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek APU Power Domains
> +
> +maintainers:
> +  - Flora Fu <flora.fu at mediatek.com>
> +
> +description: |
> +  Mediatek AI Process Unit (APU) include support for power domains which can be
> +  powered up/down by software.
> +  APU subsys belonging to a power domain should contain a 'power-domains'
> +  property that is a phandle for apuspm node representing the domain.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - mediatek,mt8192-apu-pm
> +      - const: syscon
> +
> +  reg:
> +    description: Address range of the APU power domain controller.
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  '#power-domain-cells':
> +    const: 1
> +
> +  vsram-supply:
> +    description: apu sram regulator supply.
> +
> +  mediatek,scpsys:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: |
> +      phandle to the device containing the scpsys register range.
> +
> +  mediatek,apu-conn:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: |
> +      phandle to the device containing the scpsys apu conn register range.
> +
> +  mediatek,apu-conn1:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: |
> +      phandle to the device containing the scpsys apu conn1 register range.
> +
> +  mediatek,apu-vcore:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description: |
> +      phandle to the device containing the scpsys apu vcore register range.
> +
> +patternProperties:
> +  "^power-domain@[0-9a-f]+$":
> +    type: object
> +    description: |
> +      Represents the power domains within the power controller node as
> +      documented in Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +    properties:
> +      reg:
> +        description: |
> +          Power domain index. Valid values are defined in:
> +          "include/dt-bindings/power/mt8182-apu-power.h"
> +        maxItems: 1
> +
> +      '#power-domain-cells':
> +        description: |
> +          Must be 0 for nodes representing a single PM domain and 1 for nodes
> +          providing multiple PM.
> +
> +      clocks:
> +        description: |
> +          List of phandles of clocks list. Specify by order according to
> +          power-up sequence.
> +
> +      clock-names:
> +        description: |
> +          List of names of clocks. Specify by order according to power-up
> +          sequence.
> +
> +      assigned-clocks:
> +        maxItems: 2
> +
> +      assigned-clock-parents:
> +        maxItems: 2
> +
> +      domain-supply:
> +        description: domain regulator supply.
> +
> +    required:
> +      - reg
> +      - '#power-domain-cells'
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#power-domain-cells'
> +  - vsram-supply
> +  - mediatek,scpsys
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/mt8192-clk.h>
> +    apuspm: power-domain at 190f0000 {
> +        compatible = "mediatek,mt8192-apu-pm", "syscon";
> +        reg = <0x190f0000 0x1000>;
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        #power-domain-cells = <1>;

So you have domains provided by this node and then...

> +        vsram-supply = <&mt6359_vsram_md_ldo_reg>;
> +        mediatek,scpsys = <&scpsys>;
> +        mediatek,apu-conn = <&apu_conn>;
> +        mediatek,apu-vcore = <&apu_vcore>;
> +
> +        apu_top: power-domain at 0 {
> +            reg = <0>;
> +            #power-domain-cells = <0>;

...each child node provides a domain. What's the difference?

> +            clocks = <&topckgen CLK_TOP_DSP_SEL>,
> +                     <&topckgen CLK_TOP_IPU_IF_SEL>,
> +                     <&clk26m>,
> +                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
> +            clock-names = "clk_top_conn",
> +                          "clk_top_ipu_if",
> +                          "clk_off",
> +                          "clk_on_default";
> +            assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
> +                              <&topckgen CLK_TOP_IPU_IF_SEL>;
> +            assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
> +                                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
> +            domain-supply = <&mt6359_vproc1_buck_reg>;
> +        };
> +    };
> -- 
> 2.18.0
> 


From syednwaris at gmail.com  Thu Apr 15 16:25:03 2021
From: syednwaris at gmail.com (Syed Nayyar Waris)
Date: Thu, 15 Apr 2021 20:55:03 +0530
Subject: [PATCH v10 33/33] counter: 104-quad-8: Add IRQ support for the
 ACCES 104-QUAD-8
In-Reply-To: <24f0eacf6d2e320c2ed1bc20e07a6e723da75737.1616150619.git.vilhelm.gray@gmail.com>
References: <cover.1616150619.git.vilhelm.gray@gmail.com>
 <24f0eacf6d2e320c2ed1bc20e07a6e723da75737.1616150619.git.vilhelm.gray@gmail.com>
Message-ID: <20210415152503.GL8933@syed>

On Fri, Mar 19, 2021 at 08:00:52PM +0900, William Breathitt Gray wrote:
> The LSI/CSI LS7266R1 chip provides programmable output via the FLG pins.
> When interrupts are enabled on the ACCES 104-QUAD-8, they occur whenever
> FLG1 is active. Four functions are available for the FLG1 signal: Carry,
> Compare, Carry-Borrow, and Index.
> 
> 	Carry:
> 		Interrupt generated on active low Carry signal. Carry
> 		signal toggles every time the respective channel's
> 		counter overflows.
> 
> 	Compare:
> 		Interrupt generated on active low Compare signal.
> 		Compare signal toggles every time respective channel's
> 		preset register is equal to the respective channel's
> 		counter.
> 
> 	Carry-Borrow:
> 		Interrupt generated on active low Carry signal and
> 		active low Borrow signal. Carry signal toggles every
> 		time the respective channel's counter overflows. Borrow
> 		signal toggles every time the respective channel's
> 		counter underflows.
> 
> 	Index:
> 		Interrupt generated on active high Index signal.
> 
> These four functions correspond respectivefly to the following four
> Counter event types: COUNTER_EVENT_OVERFLOW, COUNTER_EVENT_THRESHOLD,
> COUNTER_EVENT_OVERFLOW_UNDERFLOW, and COUNTER_EVENT_INDEX. Interrupts
> push Counter events to event channel X, where 'X' is the respective
> channel whose FLG1 activated.
> 
> This patch adds IRQ support for the ACCES 104-QUAD-8. The interrupt line
> numbers for the devices may be configured via the irq array module
> parameter.
> 
> Cc: Syed Nayyar Waris <syednwaris at gmail.com>
> Signed-off-by: William Breathitt Gray <vilhelm.gray at gmail.com>
> ---
>  drivers/counter/104-quad-8.c | 167 +++++++++++++++++++++++++++++++++--
>  drivers/counter/Kconfig      |   6 +-
>  2 files changed, 164 insertions(+), 9 deletions(-)

Acked-by: Syed Nayyar Waris <syednwaris at gmail.com>

> 
> diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> index d46b8101f207..09b0b0ba8fe7 100644
> --- a/drivers/counter/104-quad-8.c
> +++ b/drivers/counter/104-quad-8.c
> @@ -11,6 +11,7 @@
>  #include <linux/errno.h>
>  #include <linux/io.h>
>  #include <linux/ioport.h>
> +#include <linux/interrupt.h>
>  #include <linux/isa.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> @@ -25,6 +26,10 @@ static unsigned int num_quad8;
>  module_param_hw_array(base, uint, ioport, &num_quad8, 0);
>  MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>  
> +static unsigned int irq[max_num_isa_dev(QUAD8_EXTENT)];
> +module_param_hw_array(irq, uint, irq, NULL, 0);
> +MODULE_PARM_DESC(irq, "ACCES 104-QUAD-8 interrupt line numbers");
> +
>  #define QUAD8_NUM_COUNTERS 8
>  
>  /**
> @@ -38,6 +43,8 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses");
>   * @quadrature_scale:	array of quadrature mode scale configurations
>   * @ab_enable:		array of A and B inputs enable configurations
>   * @preset_enable:	array of set_to_preset_on_index attribute configurations
> + * @irq_trigger:	array of current IRQ trigger function configurations
> + * @next_irq_trigger:	array of next IRQ trigger function configurations
>   * @synchronous_mode:	array of index function synchronous mode configurations
>   * @index_polarity:	array of index function polarity configurations
>   * @cable_fault_enable:	differential encoder cable status enable configurations
> @@ -53,13 +60,17 @@ struct quad8 {
>  	unsigned int quadrature_scale[QUAD8_NUM_COUNTERS];
>  	unsigned int ab_enable[QUAD8_NUM_COUNTERS];
>  	unsigned int preset_enable[QUAD8_NUM_COUNTERS];
> +	unsigned int irq_trigger[QUAD8_NUM_COUNTERS];
> +	unsigned int next_irq_trigger[QUAD8_NUM_COUNTERS];
>  	unsigned int synchronous_mode[QUAD8_NUM_COUNTERS];
>  	unsigned int index_polarity[QUAD8_NUM_COUNTERS];
>  	unsigned int cable_fault_enable;
>  	unsigned int base;
>  };
>  
> +#define QUAD8_REG_INTERRUPT_STATUS 0x10
>  #define QUAD8_REG_CHAN_OP 0x11
> +#define QUAD8_REG_INDEX_INTERRUPT 0x12
>  #define QUAD8_REG_INDEX_INPUT_LEVELS 0x16
>  #define QUAD8_DIFF_ENCODER_CABLE_STATUS 0x17
>  /* Borrow Toggle flip-flop */
> @@ -92,8 +103,8 @@ struct quad8 {
>  #define QUAD8_RLD_CNTR_OUT 0x10
>  /* Transfer Preset Register LSB to FCK Prescaler */
>  #define QUAD8_RLD_PRESET_PSC 0x18
> -#define QUAD8_CHAN_OP_ENABLE_COUNTERS 0x00
>  #define QUAD8_CHAN_OP_RESET_COUNTERS 0x01
> +#define QUAD8_CHAN_OP_ENABLE_INTERRUPT_FUNC 0x04
>  #define QUAD8_CMR_QUADRATURE_X1 0x08
>  #define QUAD8_CMR_QUADRATURE_X2 0x10
>  #define QUAD8_CMR_QUADRATURE_X4 0x18
> @@ -378,13 +389,103 @@ static int quad8_action_read(struct counter_device *counter,
>  	}
>  }
>  
> +enum {
> +	QUAD8_EVENT_NONE = -1,
> +	QUAD8_EVENT_CARRY = 0,
> +	QUAD8_EVENT_COMPARE = 1,
> +	QUAD8_EVENT_CARRY_BORROW = 2,
> +	QUAD8_EVENT_INDEX = 3,
> +};
> +
> +static int quad8_events_configure(struct counter_device *counter)
> +{
> +	struct quad8 *const priv = counter->priv;
> +	unsigned long irq_enabled = 0;
> +	unsigned long irqflags;
> +	size_t channel;
> +	unsigned long ior_cfg;
> +	unsigned long base_offset;
> +
> +	spin_lock_irqsave(&priv->lock, irqflags);
> +
> +	/* Enable interrupts for the requested channels, disable for the rest */
> +	for (channel = 0; channel < QUAD8_NUM_COUNTERS; channel++) {
> +		if (priv->next_irq_trigger[channel] == QUAD8_EVENT_NONE)
> +			continue;
> +
> +		if (priv->irq_trigger[channel] != priv->next_irq_trigger[channel]) {
> +			/* Save new IRQ function configuration */
> +			priv->irq_trigger[channel] = priv->next_irq_trigger[channel];
> +
> +			/* Load configuration to I/O Control Register */
> +			ior_cfg = priv->ab_enable[channel] |
> +				  priv->preset_enable[channel] << 1 |
> +				  priv->irq_trigger[channel] << 3;
> +			base_offset = priv->base + 2 * channel + 1;
> +			outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
> +		}
> +
> +		/* Reset next IRQ trigger function configuration */
> +		priv->next_irq_trigger[channel] = QUAD8_EVENT_NONE;
> +
> +		/* Enable IRQ line */
> +		irq_enabled |= BIT(channel);
> +	}
> +
> +	outb(irq_enabled, priv->base + QUAD8_REG_INDEX_INTERRUPT);
> +
> +	spin_unlock_irqrestore(&priv->lock, irqflags);
> +
> +	return 0;
> +}
> +
> +static int quad8_watch_validate(struct counter_device *counter,
> +				const struct counter_watch *watch)
> +{
> +	struct quad8 *const priv = counter->priv;
> +
> +	if (watch->channel > QUAD8_NUM_COUNTERS - 1)
> +		return -EINVAL;
> +
> +	switch (watch->event) {
> +	case COUNTER_EVENT_OVERFLOW:
> +		if (priv->next_irq_trigger[watch->channel] == QUAD8_EVENT_NONE)
> +			priv->next_irq_trigger[watch->channel] = QUAD8_EVENT_CARRY;
> +		else if (priv->next_irq_trigger[watch->channel] != QUAD8_EVENT_CARRY)
> +			return -EINVAL;
> +		return 0;
> +	case COUNTER_EVENT_THRESHOLD:
> +		if (priv->next_irq_trigger[watch->channel] == QUAD8_EVENT_NONE)
> +			priv->next_irq_trigger[watch->channel] = QUAD8_EVENT_COMPARE;
> +		else if (priv->next_irq_trigger[watch->channel] != QUAD8_EVENT_COMPARE)
> +			return -EINVAL;
> +		return 0;
> +	case COUNTER_EVENT_OVERFLOW_UNDERFLOW:
> +		if (priv->next_irq_trigger[watch->channel] == QUAD8_EVENT_NONE)
> +			priv->next_irq_trigger[watch->channel] = QUAD8_EVENT_CARRY_BORROW;
> +		else if (priv->next_irq_trigger[watch->channel] != QUAD8_EVENT_CARRY_BORROW)
> +			return -EINVAL;
> +		return 0;
> +	case COUNTER_EVENT_INDEX:
> +		if (priv->next_irq_trigger[watch->channel] == QUAD8_EVENT_NONE)
> +			priv->next_irq_trigger[watch->channel] = QUAD8_EVENT_INDEX;
> +		else if (priv->next_irq_trigger[watch->channel] != QUAD8_EVENT_INDEX)
> +			return -EINVAL;
> +		return 0;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
>  static const struct counter_ops quad8_ops = {
>  	.signal_read = quad8_signal_read,
>  	.count_read = quad8_count_read,
>  	.count_write = quad8_count_write,
>  	.function_read = quad8_function_read,
>  	.function_write = quad8_function_write,
> -	.action_read = quad8_action_read
> +	.action_read = quad8_action_read,
> +	.events_configure = quad8_events_configure,
> +	.watch_validate = quad8_watch_validate,
>  };
>  
>  static const char *const quad8_index_polarity_modes[] = {
> @@ -579,7 +680,8 @@ static int quad8_count_enable_write(struct counter_device *counter,
>  
>  	priv->ab_enable[count->id] = enable;
>  
> -	ior_cfg = enable | priv->preset_enable[count->id] << 1;
> +	ior_cfg = enable | priv->preset_enable[count->id] << 1 |
> +		  priv->irq_trigger[count->id] << 3;
>  
>  	/* Load I/O control configuration */
>  	outb(QUAD8_CTR_IOR | ior_cfg, base_offset + 1);
> @@ -728,7 +830,8 @@ static int quad8_count_preset_enable_write(struct counter_device *counter,
>  
>  	priv->preset_enable[count->id] = preset_enable;
>  
> -	ior_cfg = priv->ab_enable[count->id] | preset_enable << 1;
> +	ior_cfg = priv->ab_enable[count->id] | preset_enable << 1 |
> +		  priv->irq_trigger[count->id] << 3;
>  
>  	/* Load I/O control configuration to Input / Output Control Register */
>  	outb(QUAD8_CTR_IOR | ior_cfg, base_offset);
> @@ -980,11 +1083,54 @@ static struct counter_count quad8_counts[] = {
>  	QUAD8_COUNT(7, "Channel 8 Count")
>  };
>  
> +static irqreturn_t quad8_irq_handler(int irq, void *private)
> +{
> +	struct quad8 *const priv = private;
> +	const unsigned long base = priv->base;
> +	unsigned long irq_status;
> +	unsigned long channel;
> +	u8 event;
> +
> +	irq_status = inb(base + QUAD8_REG_INTERRUPT_STATUS);
> +	if (!irq_status)
> +		return IRQ_NONE;
> +
> +	for_each_set_bit(channel, &irq_status, QUAD8_NUM_COUNTERS) {
> +		switch (priv->irq_trigger[channel]) {
> +		case QUAD8_EVENT_CARRY:
> +			event = COUNTER_EVENT_OVERFLOW;
> +				break;
> +		case QUAD8_EVENT_COMPARE:
> +			event = COUNTER_EVENT_THRESHOLD;
> +				break;
> +		case QUAD8_EVENT_CARRY_BORROW:
> +			event = COUNTER_EVENT_OVERFLOW_UNDERFLOW;
> +				break;
> +		case QUAD8_EVENT_INDEX:
> +			event = COUNTER_EVENT_INDEX;
> +				break;
> +		default:
> +			/* should never reach this path */
> +			WARN_ONCE(true, "invalid interrupt trigger function %u configured for channel %lu\n",
> +				  priv->irq_trigger[channel], channel);
> +			continue;
> +		}
> +
> +		counter_push_event(&priv->counter, event, channel);
> +	}
> +
> +	/* Clear pending interrupts on device */
> +	outb(QUAD8_CHAN_OP_ENABLE_INTERRUPT_FUNC, base + QUAD8_REG_CHAN_OP);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static int quad8_probe(struct device *dev, unsigned int id)
>  {
>  	struct quad8 *priv;
>  	int i, j;
>  	unsigned int base_offset;
> +	int err;
>  
>  	if (!devm_request_region(dev, base[id], QUAD8_EXTENT, dev_name(dev))) {
>  		dev_err(dev, "Unable to lock port addresses (0x%X-0x%X)\n",
> @@ -1009,6 +1155,8 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  
>  	spin_lock_init(&priv->lock);
>  
> +	/* Reset Index/Interrupt Register */
> +	outb(0x00, base[id] + QUAD8_REG_INDEX_INTERRUPT);
>  	/* Reset all counters and disable interrupt function */
>  	outb(QUAD8_CHAN_OP_RESET_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
>  	/* Set initial configuration for all counters */
> @@ -1035,11 +1183,18 @@ static int quad8_probe(struct device *dev, unsigned int id)
>  		outb(QUAD8_CTR_IOR, base_offset + 1);
>  		/* Disable index function; negative index polarity */
>  		outb(QUAD8_CTR_IDR, base_offset + 1);
> +		/* Initialize next IRQ trigger function configuration */
> +		priv->next_irq_trigger[i] = QUAD8_EVENT_NONE;
>  	}
>  	/* Disable Differential Encoder Cable Status for all channels */
>  	outb(0xFF, base[id] + QUAD8_DIFF_ENCODER_CABLE_STATUS);
> -	/* Enable all counters */
> -	outb(QUAD8_CHAN_OP_ENABLE_COUNTERS, base[id] + QUAD8_REG_CHAN_OP);
> +	/* Enable all counters and enable interrupt function */
> +	outb(QUAD8_CHAN_OP_ENABLE_INTERRUPT_FUNC, base[id] + QUAD8_REG_CHAN_OP);
> +
> +	err = devm_request_irq(dev, irq[id], quad8_irq_handler, IRQF_SHARED,
> +			       priv->counter.name, priv);
> +	if (err)
> +		return err;
>  
>  	return devm_counter_register(dev, &priv->counter);
>  }
> diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig
> index 5328705aa09c..2c2862dd46a5 100644
> --- a/drivers/counter/Kconfig
> +++ b/drivers/counter/Kconfig
> @@ -23,11 +23,11 @@ config 104_QUAD_8
>  	  A counter's respective error flag may be cleared by performing a write
>  	  operation on the respective count value attribute. Although the
>  	  104-QUAD-8 counters have a 25-bit range, only the lower 24 bits may be
> -	  set, either directly or via the counter's preset attribute. Interrupts
> -	  are not supported by this driver.
> +	  set, either directly or via the counter's preset attribute.
>  
>  	  The base port addresses for the devices may be configured via the base
> -	  array module parameter.
> +	  array module parameter. The interrupt line numbers for the devices may
> +	  be configured via the irq array module parameter.
>  
>  config INTERRUPT_CNT
>  	tristate "Interrupt counter driver"
> -- 
> 2.30.2
> 


From daniel at ffwll.ch  Thu Apr 15 16:39:40 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 15 Apr 2021 17:39:40 +0200
Subject: [PATCH 4/4] drm: Remove DRM_KMS_FB_HELPER Kconfig option
In-Reply-To: <20210415110040.23525-5-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-5-tzimmermann@suse.de>
Message-ID: <YHhePNFHkX2cmkwt@phenom.ffwll.local>

On Thu, Apr 15, 2021 at 01:00:40PM +0200, Thomas Zimmermann wrote:
> It's only used by DRM_FBDEV_EMULATION, so inline it there.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

I'm not sure on patch 1, I'll leave that to Zack, but I think 2-4 would
work alone too. On those:

Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>

> ---
>  drivers/gpu/drm/Kconfig | 28 +++++++++++-----------------
>  1 file changed, 11 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 3c16bd1afd87..d3a9ca4b1cec 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -80,23 +80,6 @@ config DRM_KMS_HELPER
>  	help
>  	  CRTC helpers for KMS drivers.
>  
> -config DRM_KMS_FB_HELPER
> -	bool
> -	depends on DRM_KMS_HELPER
> -	select FB
> -	select FRAMEBUFFER_CONSOLE if !EXPERT
> -	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> -	select FB_SYS_FOPS
> -	select FB_SYS_FILLRECT
> -	select FB_SYS_COPYAREA
> -	select FB_SYS_IMAGEBLIT
> -	select FB_CFB_FILLRECT
> -	select FB_CFB_COPYAREA
> -	select FB_CFB_IMAGEBLIT
> -	select FB_DEFERRED_IO
> -	help
> -	  FBDEV helpers for KMS drivers.
> -
>  config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>          bool "Enable refcount backtrace history in the DP MST helpers"
>  	depends on STACKTRACE_SUPPORT
> @@ -117,6 +100,17 @@ config DRM_FBDEV_EMULATION
>  	depends on DRM
>  	select DRM_KMS_HELPER
>  	select DRM_KMS_FB_HELPER
> +	select FB
> +	select FB_CFB_FILLRECT
> +	select FB_CFB_COPYAREA
> +	select FB_CFB_IMAGEBLIT
> +	select FB_DEFERRED_IO
> +	select FB_SYS_FOPS
> +	select FB_SYS_FILLRECT
> +	select FB_SYS_COPYAREA
> +	select FB_SYS_IMAGEBLIT
> +	select FRAMEBUFFER_CONSOLE if !EXPERT
> +	select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
>  	default y
>  	help
>  	  Choose this option if you have a need for the legacy fbdev
> -- 
> 2.31.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From samitolvanen at google.com  Thu Apr 15 16:50:25 2021
From: samitolvanen at google.com (Sami Tolvanen)
Date: Thu, 15 Apr 2021 08:50:25 -0700
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn, endif}
In-Reply-To: <20210415140224.GE1015@arm.com>
References: <20210414000803.662534-1-nathan@kernel.org>
 <20210415091743.GB1015@arm.com>
 <YHg+5RSG4XPLlZD8@archlinux-ax161> <20210415140224.GE1015@arm.com>
Message-ID: <CABCJKufDUgPSRQi1ZQRk=upNtziKDJ8rTBHgq2oQpPWS=utrvg@mail.gmail.com>

On Thu, Apr 15, 2021 at 7:02 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
>
> On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> > On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > > > set atomically"), LLVM's integrated assembler fails to build entry.S:
> > > >
> > > > <instantiation>:5:7: error: expected assembly-time absolute expression
> > > >  .org . - (664b-663b) + (662b-661b)
> > > >       ^
> > > > <instantiation>:6:7: error: expected assembly-time absolute expression
> > > >  .org . - (662b-661b) + (664b-663b)
> > > >       ^
> > >
> > > I tried the latest Linus' tree and linux-next (defconfig) with this
> > > commit in and I can't get your build error. I used both clang-10 from
> > > Debian stable and clang-11 from Debian sid. So, which clang version did
> > > you use or which kernel config options?
> >
> > Interesting, this reproduces for me with LLVM 12 or newer with just
> > defconfig.
>
> It fails for me as well with clang-12. Do you happen to know why it
> works fine with previous clang versions?

It looks like CONFIG_ARM64_AS_HAS_MTE is not set when we use the
integrated assembler with LLVM 11, and the code that breaks later
versions is gated behind CONFIG_ARM64_MTE.

Sami


From aladyshev22 at gmail.com  Thu Apr 15 16:52:59 2021
From: aladyshev22 at gmail.com (Konstantin Aladyshev)
Date: Thu, 15 Apr 2021 18:52:59 +0300
Subject: [PATCH] ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses
Message-ID: <20210415155300.1135-1-aladyshev22@gmail.com>

Enable all I2C busses that are used in AMD EthanolX CRB:
 i2c0 - APML P0
 i2c1 - APML P1
 i2c2 - FPGA
 i2c3 - 24LC128 EEPROM
 i2c4 - P0 Power regulators
 i2c5 - P1 Power regulators
 i2c6 - P0/P1 Thermal diode
 i2c7 - Thermal Sensors
 i2c8 - BMC I2C

Signed-off-by: Konstantin Aladyshev <aladyshev22 at gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
index ac2d04cfaf2f..6aeb47c44eba 100644
--- a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
@@ -151,6 +151,31 @@ &i2c1 {
 	status = "okay";
 };
 
+//FPGA
+&i2c2 {
+	status = "okay";
+};
+
+//24LC128 EEPROM
+&i2c3 {
+	status = "okay";
+};
+
+//P0 Power regulators
+&i2c4 {
+	status = "okay";
+};
+
+//P1 Power regulators
+&i2c5 {
+	status = "okay";
+};
+
+//P0/P1 Thermal diode
+&i2c6 {
+	status = "okay";
+};
+
 // Thermal Sensors
 &i2c7 {
 	status = "okay";
@@ -196,6 +221,11 @@ lm75a at 4f {
 	};
 };
 
+//BMC I2C
+&i2c8 {
+	status = "okay";
+};
+
 &kcs1 {
 	status = "okay";
 	aspeed,lpc-io-reg = <0x60>;
-- 
2.25.1



From robh at kernel.org  Thu Apr 15 17:16:56 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 11:16:56 -0500
Subject: [PATCH v4 29/33] dt-bindings: media: atmel-isc: convert to yaml
In-Reply-To: <20210415085530.824638-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-30-eugen.hristev@microchip.com>
 <20210415085530.824638-1-eugen.hristev@microchip.com>
Message-ID: <20210415161656.GA1501812@robh.at.kernel.org>

On Thu, 15 Apr 2021 11:55:30 +0300, Eugen Hristev wrote:
> Convert the Atmel ISC to yaml binding format.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
> Changes in v4:
> - added '|' at description to maintain line breaks
> 
>  .../devicetree/bindings/media/atmel,isc.yaml  | 115 ++++++++++++++++++
>  .../devicetree/bindings/media/atmel-isc.txt   |  65 ----------
>  2 files changed, 115 insertions(+), 65 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/atmel,isc.yaml
>  delete mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From RAJANV at xilinx.com  Thu Apr 15 17:27:58 2021
From: RAJANV at xilinx.com (Rajan Vaja)
Date: Thu, 15 Apr 2021 16:27:58 +0000
Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
 PM_INIT_FINALIZE
In-Reply-To: <20210317160410.2097178-1-m.tretter@pengutronix.de>
References: <20210317160410.2097178-1-m.tretter@pengutronix.de>
Message-ID: <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>

Hi Michael,

Thanks for the patch.

> -----Original Message-----
> From: Michael Tretter <m.tretter at pengutronix.de>
> Sent: 17 March 2021 09:34 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Michal Simek <michals at xilinx.com>; Rajan Vaja <RAJANV at xilinx.com>; Jolly
> Shah <JOLLYS at xilinx.com>; m.tretter at pengutronix.de
> Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE
> 
> CAUTION: This message has originated from an External Source. Please use proper
> judgment and caution when opening attachments, clicking links, or responding to
> this email.
> 
> 
> Hi,
> 
> Patch 1 of this series fixes the ZynqMP PMU FW power management
> initialization, which was done by the wrong driver. PM_INIT_FINALIZE must be
> called from the zynqmp_pm_domains driver, which handles power domains, instead
> of the zynmp_power driver, which is responsible for suspend and shutdown.
[Rajan] I am fine with moving to genpd but zynqmp_pm_init_finalize() needs to be late call.
zynqmp_pm_init_finalize() should be called when Linux has requested all the devices through
genpd driver. Making it late call will make sure it. 

> 
> Patches 2 to 4 are various cleanup patches to improve the readability and
> debugging experience of the zynqmp_pm_domains driver.
> 
> Michael
> 
> Michael Tretter (4):
>   soc: xilinx: move PM_INIT_FINALIZE to zynqmp_pm_domains driver
>   soc: xilinx: cleanup debug and error messages
>   soc: xilinx: use a properly named field instead of flags
>   soc: xilinx: add a to_zynqmp_pm_domain macro
> 
>  drivers/soc/xilinx/zynqmp_pm_domains.c | 79 +++++++++++++-------------
>  drivers/soc/xilinx/zynqmp_power.c      |  1 -
>  2 files changed, 38 insertions(+), 42 deletions(-)
> 
> --
> 2.29.2



From robh at kernel.org  Thu Apr 15 17:40:11 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 11:40:11 -0500
Subject: [PATCH v4 30/33] dt-bindings: media: add microchip,xisc device
 bindings
In-Reply-To: <20210415085846.824796-1-eugen.hristev@microchip.com>
References: <20210413105731.610028-31-eugen.hristev@microchip.com>
 <20210415085846.824796-1-eugen.hristev@microchip.com>
Message-ID: <20210415164011.GA1533489@robh.at.kernel.org>

On Thu, Apr 15, 2021 at 11:58:46AM +0300, Eugen Hristev wrote:
> Add bindings for the Microchip eXtended Image Sensor Controller.
> Based on the atmel,isc.yaml binding.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
>  .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
>  1 file changed, 129 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
> new file mode 100644
> index 000000000000..c829fa3d2e0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: GPL-2.0-only

Dual license still missing.

> +# Copyright (C) 2021 Microchip Technology, Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip eXtended Image Sensor Controller (XISC)
> +
> +maintainers:
> +  - Eugen Hristev <eugen.hristev at microchip.com>
> +
> +description: |
> +  The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
> +  Microchip AT91 SAM family of devices.
> +
> +  The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
> +  The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
> +  parallel sensor.
> +
> +  The XISC provides one clock output that is used to clock the demuxer/bridge.
> +
> +properties:
> +  compatible:
> +    const: microchip,sama7g5-isc
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  clock-names:
> +    items:
> +      - const: hclock
> +
> +  '#clock-cells':
> +    const: 0
> +
> +  clock-output-names:
> +    const: isc-mck
> +
> +  microchip,mipi-mode:
> +    type: boolean
> +    description:
> +      As the XISC is usually connected to a demux/bridge, the XISC receives
> +      the same type of input, however, it should be aware of the type of
> +      signals received. The mipi-mode enables different internal handling
> +      of the data and clock lines.
> +
> +  port:
> +    $ref: /schemas/graph.yaml#/properties/port
> +    description:
> +      Input port node, single endpoint describing the input pad.
> +
> +    properties:
> +      endpoint:
> +        $ref: video-interfaces.yaml#
> +
> +        properties:
> +          bus-type:
> +            enum: [5, 6]
> +
> +          remote-endpoint: true
> +
> +          bus-width:
> +            enum: [8, 9, 10, 11, 12]
> +            default: 12
> +
> +          hsync-active:
> +            enum: [0, 1]
> +            default: 1
> +
> +          vsync-active:
> +            enum: [0, 1]
> +            default: 1
> +
> +          pclk-sample:
> +            enum: [0, 1]
> +            default: 1
> +
> +        required:
> +          - remote-endpoint
> +          - bus-type
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - '#clock-cells'
> +  - clock-output-names
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/clock/at91.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +
> +    xisc: xisc at e1408000 {
> +        compatible = "microchip,sama7g5-isc";
> +        reg = <0xe1408000 0x2000>;
> +        interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
> +        clock-names = "hclock";
> +        #clock-cells = <0>;
> +        clock-output-names = "isc-mck";
> +
> +        port {
> +                xisc_in: endpoint {
> +                       bus-type = <5>; /* Parallel */
> +                       remote-endpoint = <&csi2dc_out>;
> +                       hsync-active = <1>;
> +                       vsync-active = <1>;
> +                       bus-width = <12>;
> +                };
> +        };
> +    };
> +
> -- 
> 2.25.1
> 


From ndesaulniers at google.com  Thu Apr 15 17:52:14 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Thu, 15 Apr 2021 09:52:14 -0700
Subject: [PATCH v2] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <a2ddf4d2-110a-9290-f766-3925e451ddef@arm.com>
References: <YHYlQnFRMNdn/CDp@archlinux-ax161>
 <20210414214548.700993-1-ndesaulniers@google.com>
 <a2ddf4d2-110a-9290-f766-3925e451ddef@arm.com>
Message-ID: <CAKwvOdms0SVJMMLOwK-w=fzsw1FmCSK9qjZ_Syq0A-kRzYkHLQ@mail.gmail.com>

On Thu, Apr 15, 2021 at 6:31 AM Vincenzo Frascino
<vincenzo.frascino at arm.com> wrote:
>
>
>
> On 4/14/21 10:45 PM, Nick Desaulniers wrote:
> > Clang can assemble these files just fine; this is a relic from the top
> > level Makefile conditionally adding this. We no longer need --prefix,
> > --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> > remove those too.
> >
> > To test building:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> >   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
> >   defconfig arch/arm64/kernel/vdso32/
> >
> > Suggested-by: Nathan Chancellor <nathan at kernel.org>
> > Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
>
> The patch looks fine, but I have one question: the kernel requires as a minimum
> Clang/LLVM version 10.0.1. Did you verify that with that version compat vDSOs
> still builds and works correctly?

Hi Vincenzo,
Great question, let's check.
$ cd path/to/llvm-project
$ git checkout origin/release/10.x
$ cd llvm/build && ninja
$ cd path/to/linux
$ b4 am https://lore.kernel.org/lkml/20210413230609.3114365-1-ndesaulniers at google.com/
-o - | git am -3

We can't generally build ARCH=arm64 defconfig with LLVM_IAS=1 with
clang-10, but dropping LLVM_IAS=1 it looks like we can still build
without that.

$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 -j72 defconfig
clean all
$ ls -l arch/arm64/kernel/vdso32
total 116
-rw-r----- 1 ndesaulniers primarygroup  7534 Apr 14 14:41 Makefile
-rw-r----- 1 ndesaulniers primarygroup   387 Mar 31 10:47 note.c
-rw-r----- 1 ndesaulniers primarygroup  2544 Apr 15 09:48 note.o
-rw-r----- 1 ndesaulniers primarygroup  4552 Apr 15 09:48 vdso.lds
-rw-r----- 1 ndesaulniers primarygroup  1587 Apr  1 12:55 vdso.lds.S
-rw------- 1 ndesaulniers primarygroup  3576 Apr 15 09:48 vdso.so
-rw------- 1 ndesaulniers primarygroup 24380 Apr 15 09:48 vdso.so.dbg
-rwxr-x--- 1 ndesaulniers primarygroup 24380 Apr 15 09:48 vdso.so.raw
-rw-r----- 1 ndesaulniers primarygroup   828 Apr  1 12:55 vgettimeofday.c
-rw-r----- 1 ndesaulniers primarygroup 29084 Apr 15 09:48 vgettimeofday.o

FWIW, clang-10 was missing support for R_AARCH64_PREL32, which affects
building arch/arm64/kvm/hyp/nvhe/hyp-reloc.S.

>
> Otherwise:
>
> Reviewed-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
>
> > ---
> > Changes V1 -> V2:
> > * Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and
> >   COMPAT_GCC_TOOLCHAIN_DIR as per Nathan.
> > * Credit Nathan with Suggested-by tag.
> > * Remove -Qunused-arguments.
> > * Update commit message.
> >
> >  arch/arm64/kernel/vdso32/Makefile | 8 --------
> >  1 file changed, 8 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > index 789ad420f16b..3dba0c4f8f42 100644
> > --- a/arch/arm64/kernel/vdso32/Makefile
> > +++ b/arch/arm64/kernel/vdso32/Makefile
> > @@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile
> >
> >  # Same as cc-*option, but using CC_COMPAT instead of CC
> >  ifeq ($(CONFIG_CC_IS_CLANG), y)
> > -COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE_COMPAT)elfedit))
> > -COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
> > -
> >  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> > -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
> > -CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> > -ifneq ($(COMPAT_GCC_TOOLCHAIN),)
> > -CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
> > -endif
> >
> >  CC_COMPAT ?= $(CC)
> >  CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
> >
>
> --
> Regards,
> Vincenzo



-- 
Thanks,
~Nick Desaulniers


From catalin.marinas at arm.com  Thu Apr 15 17:57:48 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 17:57:48 +0100
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn,endif}
In-Reply-To: <CABCJKufDUgPSRQi1ZQRk=upNtziKDJ8rTBHgq2oQpPWS=utrvg@mail.gmail.com>
References: <20210414000803.662534-1-nathan@kernel.org>
 <20210415091743.GB1015@arm.com> <YHg+5RSG4XPLlZD8@archlinux-ax161>
 <20210415140224.GE1015@arm.com>
 <CABCJKufDUgPSRQi1ZQRk=upNtziKDJ8rTBHgq2oQpPWS=utrvg@mail.gmail.com>
Message-ID: <20210415165748.GG1015@arm.com>

On Thu, Apr 15, 2021 at 08:50:25AM -0700, Sami Tolvanen wrote:
> On Thu, Apr 15, 2021 at 7:02 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
> >
> > On Thu, Apr 15, 2021 at 06:25:57AM -0700, Nathan Chancellor wrote:
> > > On Thu, Apr 15, 2021 at 10:17:43AM +0100, Catalin Marinas wrote:
> > > > On Tue, Apr 13, 2021 at 05:08:04PM -0700, Nathan Chancellor wrote:
> > > > > After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> > > > > set atomically"), LLVM's integrated assembler fails to build entry.S:
> > > > >
> > > > > <instantiation>:5:7: error: expected assembly-time absolute expression
> > > > >  .org . - (664b-663b) + (662b-661b)
> > > > >       ^
> > > > > <instantiation>:6:7: error: expected assembly-time absolute expression
> > > > >  .org . - (662b-661b) + (664b-663b)
> > > > >       ^
> > > >
> > > > I tried the latest Linus' tree and linux-next (defconfig) with this
> > > > commit in and I can't get your build error. I used both clang-10 from
> > > > Debian stable and clang-11 from Debian sid. So, which clang version did
> > > > you use or which kernel config options?
> > >
> > > Interesting, this reproduces for me with LLVM 12 or newer with just
> > > defconfig.
> >
> > It fails for me as well with clang-12. Do you happen to know why it
> > works fine with previous clang versions?
> 
> It looks like CONFIG_ARM64_AS_HAS_MTE is not set when we use the
> integrated assembler with LLVM 11, and the code that breaks later
> versions is gated behind CONFIG_ARM64_MTE.

That explains it, thanks.

-- 
Catalin


From kuba at kernel.org  Thu Apr 15 17:58:56 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Thu, 15 Apr 2021 09:58:56 -0700
Subject: [PATCH v2 5/7] net: fec: make use of generic NET_SELFTESTS library
In-Reply-To: <20210415130738.19603-6-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
 <20210415130738.19603-6-o.rempel@pengutronix.de>
Message-ID: <20210415095856.2966dd7c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Thu, 15 Apr 2021 15:07:36 +0200 Oleksij Rempel wrote:
> With this patch FEC on iMX will able to run generic net selftests
> 
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>

allmodconfig build fails starting from this patch and still fails 
after patch 7:

net/core/selftests.o: In function `net_selftest':
selftests.c:(.text+0x75c): undefined reference to `phy_loopback'
selftests.c:(.text+0x7c2): undefined reference to `phy_loopback'


From erwan.leray at foss.st.com  Thu Apr 15 18:09:14 2021
From: erwan.leray at foss.st.com (Erwan LE RAY)
Date: Thu, 15 Apr 2021 19:09:14 +0200
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
 <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
Message-ID: <e17fddfb-f9b8-238f-da74-a4746f33134f@foss.st.com>

Hi Dillon,

STM32MP151 is mono-core, but both STM32MP153 and STM32MP157 are 
dual-core (see 
https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-arm-cortex-mpus.html).
So your point is fully relevant, thanks.

ST already fixed the same issue in st-asc.c driver in the past (see 
ef49ffd8), because a systematic deadlock was detected with RT kernel.

You proposed a first implementation in your patch, and a second one in 
the discussion. It seems that your initial proposal (ie your V2 patch) 
is the most standard one (implemented in 6 drivers). The second 
implementation is implemented by only 1 company.

It looks that the solution is to avoid locking in the sysrq case and 
trylock in the oops_in_progress case (see detailed analysis in 
677fe555cbfb1).

So your initial patch looks to the right proposal, but it would be safer 
if Greg could confirm it.

BR, Erwan.


On 4/13/21 1:44 AM, dillon min wrote:
> Hi Johan, Erwan
> 
> It seems still a bit of a problem in the current version, not deadlock
> but access register at the same time.
> 
> For driver , we should consider it running under smp, let's think
> about it for this case:
> 
> static void stm32_usart_console_write(struct console *co, const char *s,
>                                        unsigned int cnt)
> {
>           .....
>           local_irq_save(flags);
>           if (port->sysrq)
>                      locked = 0;
>           .....
>           access register cr1, tdr, isr
>           .....
> 
>           local_irq_restore(flags);
> }
> 
> if port->sysrq is 1, stm32_usart_console_write() just disable local
> irq response by local_irq_save(), at the time of access register cr1,
> tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> mpu/mcu do not have multi cores, just assume it has), it still has a
> chance to handle interrupt.  Then there is no lock to protect the uart
> register.
> 
> changes to below, should be more safe:
> 
> .....
> if (port->sysrq || oops_in_progress)
>        locked = spin_trylock_irqsave(&port->lock, flags);
> else
>        spin_lock_irqsave(&port->lock, flags);
> 
> ....
> 
> if (locked)
>       spin_unlock_irqrestore(&port->lock, flags);
> 
> For current stm32 soc, it shouldn't happen. just a reminder for future.
> 
> Thanks.
> 
> Dillon
> 
> On Mon, Apr 12, 2021 at 10:04 PM dillon min <dillon.minfei at gmail.com> wrote:
>>
>> Hi Johan,
>>
>> Yes, there is no deadlock. my fault.
>> I forget the local_irq_save() plus spin_lock() is spin_lock_irqsave().
>>
>> Thanks for your review. please ignore this patch.
>>
>> Best regards
>>
>> Dillon
>>
>> On Mon, Apr 12, 2021 at 9:08 PM Johan Hovold <johan at kernel.org> wrote:
>>>
>>> On Mon, Apr 12, 2021 at 05:31:38PM +0800, dillon.minfei at gmail.com wrote:
>>>> From: dillon min <dillon.minfei at gmail.com>
>>>>
>>>> To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
>>>> spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.
>>>
>>> This doesn't make much sense as console_write can be called in any
>>> context. And where's the deadlock you claim to be fixing here?
>>>
>>>> remove unused local_irq_save/restore call.
>>>>
>>>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
>>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>>> Cc: Gerald Baeza <gerald.baeza at foss.st.com>
>>>> Cc: Erwan Le Ray <erwan.leray at foss.st.com>
>>>> Reported-by: kernel test robot <lkp at intel.com>
>>>> Signed-off-by: dillon min <dillon.minfei at gmail.com>
>>>> ---
>>>> v2: remove unused code from stm32_usart_threaded_interrupt() according from
>>>>      Greg's review.
>>>>
>>>>   drivers/tty/serial/stm32-usart.c | 8 +++-----
>>>>   1 file changed, 3 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
>>>> index b3675cf25a69..b1ba5e36e36e 100644
>>>> --- a/drivers/tty/serial/stm32-usart.c
>>>> +++ b/drivers/tty/serial/stm32-usart.c
>>>> @@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
>>>>        u32 old_cr1, new_cr1;
>>>>        int locked = 1;
>>>>
>>>> -     local_irq_save(flags);
>>>>        if (port->sysrq)
>>>>                locked = 0;
>>>>        else if (oops_in_progress)
>>>> -             locked = spin_trylock(&port->lock);
>>>> +             locked = spin_trylock_irqsave(&port->lock, flags);
>>>>        else
>>>> -             spin_lock(&port->lock);
>>>> +             spin_lock_irqsave(&port->lock, flags);
>>>>
>>>>        /* Save and disable interrupts, enable the transmitter */
>>>>        old_cr1 = readl_relaxed(port->membase + ofs->cr1);
>>>> @@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
>>>>        writel_relaxed(old_cr1, port->membase + ofs->cr1);
>>>>
>>>>        if (locked)
>>>> -             spin_unlock(&port->lock);
>>>> -     local_irq_restore(flags);
>>>> +             spin_unlock_irqrestore(&port->lock, flags);
>>>>   }
>>>>
>>>>   static int stm32_usart_console_setup(struct console *co, char *options)
>>>
>>> Johan


From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:13 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:13 +0000 (UTC)
Subject: [PATCH v1 0/5] Convert powerpc to GENERIC_PTDUMP
Message-ID: <cover.1618506910.git.christophe.leroy@csgroup.eu>

This series converts powerpc to generic PTDUMP.

For that, we first need to add missing hugepd support
to pagewalk and ptdump.

Christophe Leroy (5):
  mm: pagewalk: Fix walk for hugepage tables
  mm: ptdump: Fix build failure
  mm: ptdump: Provide page size to notepage()
  mm: ptdump: Support hugepd table entries
  powerpc/mm: Convert powerpc to GENERIC_PTDUMP

 arch/arm64/mm/ptdump.c            |   2 +-
 arch/powerpc/Kconfig              |   2 +
 arch/powerpc/Kconfig.debug        |  30 ------
 arch/powerpc/mm/Makefile          |   2 +-
 arch/powerpc/mm/mmu_decl.h        |   2 +-
 arch/powerpc/mm/ptdump/8xx.c      |   6 +-
 arch/powerpc/mm/ptdump/Makefile   |   9 +-
 arch/powerpc/mm/ptdump/book3s64.c |   6 +-
 arch/powerpc/mm/ptdump/ptdump.c   | 161 +++++++++---------------------
 arch/powerpc/mm/ptdump/shared.c   |   6 +-
 arch/riscv/mm/ptdump.c            |   2 +-
 arch/s390/mm/dump_pagetables.c    |   3 +-
 arch/x86/mm/dump_pagetables.c     |   2 +-
 include/linux/ptdump.h            |   2 +-
 mm/pagewalk.c                     |  54 ++++++++--
 mm/ptdump.c                       |  33 ++++--
 16 files changed, 145 insertions(+), 177 deletions(-)

-- 
2.25.0



From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:14 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:14 +0000 (UTC)
Subject: [PATCH v1 1/5] mm: pagewalk: Fix walk for hugepage tables
In-Reply-To: <cover.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <733408f48b1ed191f53518123ee6fc6d42287cc6.1618506910.git.christophe.leroy@csgroup.eu>

Pagewalk ignores hugepd entries and walk down the tables
as if it was traditionnal entries, leading to crazy result.

Add walk_hugepd_range() and use it to walk hugepage tables.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 mm/pagewalk.c | 54 +++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 48 insertions(+), 6 deletions(-)

diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index e81640d9f177..410a9d8f7572 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -58,6 +58,32 @@ static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 	return err;
 }
 
+static int walk_hugepd_range(hugepd_t *phpd, unsigned long addr,
+			     unsigned long end, struct mm_walk *walk, int pdshift)
+{
+	int err = 0;
+#ifdef CONFIG_ARCH_HAS_HUGEPD
+	const struct mm_walk_ops *ops = walk->ops;
+	int shift = hugepd_shift(*phpd);
+	int page_size = 1 << shift;
+
+	if (addr & (page_size - 1))
+		return 0;
+
+	for (;;) {
+		pte_t *pte = hugepte_offset(*phpd, addr, pdshift);
+
+		err = ops->pte_entry(pte, addr, addr + page_size, walk);
+		if (err)
+			break;
+		if (addr >= end - page_size)
+			break;
+		addr += page_size;
+	}
+#endif
+	return err;
+}
+
 static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
 			  struct mm_walk *walk)
 {
@@ -108,7 +134,10 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
 				goto again;
 		}
 
-		err = walk_pte_range(pmd, addr, next, walk);
+		if (is_hugepd(__hugepd(pmd_val(*pmd))))
+			err = walk_hugepd_range((hugepd_t *)pmd, addr, next, walk, PMD_SHIFT);
+		else
+			err = walk_pte_range(pmd, addr, next, walk);
 		if (err)
 			break;
 	} while (pmd++, addr = next, addr != end);
@@ -157,7 +186,10 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
 		if (pud_none(*pud))
 			goto again;
 
-		err = walk_pmd_range(pud, addr, next, walk);
+		if (is_hugepd(__hugepd(pud_val(*pud))))
+			err = walk_hugepd_range((hugepd_t *)pud, addr, next, walk, PUD_SHIFT);
+		else
+			err = walk_pmd_range(pud, addr, next, walk);
 		if (err)
 			break;
 	} while (pud++, addr = next, addr != end);
@@ -189,8 +221,13 @@ static int walk_p4d_range(pgd_t *pgd, unsigned long addr, unsigned long end,
 			if (err)
 				break;
 		}
-		if (ops->pud_entry || ops->pmd_entry || ops->pte_entry)
-			err = walk_pud_range(p4d, addr, next, walk);
+		if (ops->pud_entry || ops->pmd_entry || ops->pte_entry) {
+			if (is_hugepd(__hugepd(p4d_val(*p4d))))
+				err = walk_hugepd_range((hugepd_t *)p4d, addr, next, walk,
+							P4D_SHIFT);
+			else
+				err = walk_pud_range(p4d, addr, next, walk);
+		}
 		if (err)
 			break;
 	} while (p4d++, addr = next, addr != end);
@@ -225,8 +262,13 @@ static int walk_pgd_range(unsigned long addr, unsigned long end,
 				break;
 		}
 		if (ops->p4d_entry || ops->pud_entry || ops->pmd_entry ||
-		    ops->pte_entry)
-			err = walk_p4d_range(pgd, addr, next, walk);
+		    ops->pte_entry) {
+			if (is_hugepd(__hugepd(pgd_val(*pgd))))
+				err = walk_hugepd_range((hugepd_t *)pgd, addr, next, walk,
+							PGDIR_SHIFT);
+			else
+				err = walk_p4d_range(pgd, addr, next, walk);
+		}
 		if (err)
 			break;
 	} while (pgd++, addr = next, addr != end);
-- 
2.25.0



From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:15 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:15 +0000 (UTC)
Subject: [PATCH v1 2/5] mm: ptdump: Fix build failure
In-Reply-To: <cover.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <9bd00b3ca42dbec81a0139626e780a8f8c871988.1618506910.git.christophe.leroy@csgroup.eu>

	  CC      mm/ptdump.o
	In file included from <command-line>:
	mm/ptdump.c: In function 'ptdump_pte_entry':
	././include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_207' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
	  320 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
	      |                                      ^
	././include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert'
	  301 |    prefix ## suffix();    \
	      |    ^~~~~~
	././include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert'
	  320 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
	      |  ^~~~~~~~~~~~~~~~~~~
	./include/asm-generic/rwonce.h:36:2: note: in expansion of macro 'compiletime_assert'
	   36 |  compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
	      |  ^~~~~~~~~~~~~~~~~~
	./include/asm-generic/rwonce.h:49:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
	   49 |  compiletime_assert_rwonce_type(x);    \
	      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	mm/ptdump.c:114:14: note: in expansion of macro 'READ_ONCE'
	  114 |  pte_t val = READ_ONCE(*pte);
	      |              ^~~~~~~~~
	make[2]: *** [mm/ptdump.o] Error 1

READ_ONCE() cannot be used for reading PTEs. Use ptep_get()
instead. See commit 481e980a7c19 ("mm: Allow arches to provide ptep_get()")
and commit c0e1c8c22beb ("powerpc/8xx: Provide ptep_get() with 16k pages")
for details.

Fixes: 30d621f6723b ("mm: add generic ptdump")
Cc: Steven Price <steven.price at arm.com>
Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 mm/ptdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/ptdump.c b/mm/ptdump.c
index 4354c1422d57..da751448d0e4 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -111,7 +111,7 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
 			    unsigned long next, struct mm_walk *walk)
 {
 	struct ptdump_state *st = walk->private;
-	pte_t val = READ_ONCE(*pte);
+	pte_t val = ptep_get(pte);
 
 	if (st->effective_prot)
 		st->effective_prot(st, 4, pte_val(val));
-- 
2.25.0



From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:17 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:17 +0000 (UTC)
Subject: [PATCH v1 4/5] mm: ptdump: Support hugepd table entries
In-Reply-To: <cover.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <f41a177a0fd5a71db616e586a9ec5c51102c6656.1618506910.git.christophe.leroy@csgroup.eu>

Which hugepd, page table entries can be at any level
and can be of any size.

Add support for them.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 mm/ptdump.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/mm/ptdump.c b/mm/ptdump.c
index 61cd16afb1c8..6efdb8c15a7d 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -112,11 +112,24 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
 {
 	struct ptdump_state *st = walk->private;
 	pte_t val = ptep_get(pte);
+	unsigned long page_size = next - addr;
+	int level;
+
+	if (page_size >= PGDIR_SIZE)
+		level = 0;
+	else if (page_size >= P4D_SIZE)
+		level = 1;
+	else if (page_size >= PUD_SIZE)
+		level = 2;
+	else if (page_size >= PMD_SIZE)
+		level = 3;
+	else
+		level = 4;
 
 	if (st->effective_prot)
-		st->effective_prot(st, 4, pte_val(val));
+		st->effective_prot(st, level, pte_val(val));
 
-	st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
+	st->note_page(st, addr, level, pte_val(val), page_size);
 
 	return 0;
 }
-- 
2.25.0



From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:16 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:16 +0000 (UTC)
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <cover.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>

In order to support large pages on powerpc, notepage()
needs to know the page size of the page.

Add a page_size argument to notepage().

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/arm64/mm/ptdump.c         |  2 +-
 arch/riscv/mm/ptdump.c         |  2 +-
 arch/s390/mm/dump_pagetables.c |  3 ++-
 arch/x86/mm/dump_pagetables.c  |  2 +-
 include/linux/ptdump.h         |  2 +-
 mm/ptdump.c                    | 16 ++++++++--------
 6 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 0e050d76b83a..ea1a1c3a3ea0 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -257,7 +257,7 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
 }
 
 static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
-		      u64 val)
+		      u64 val, unsigned long page_size)
 {
 	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
 	static const char units[] = "KMGTPE";
diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
index ace74dec7492..0a7f276ba799 100644
--- a/arch/riscv/mm/ptdump.c
+++ b/arch/riscv/mm/ptdump.c
@@ -235,7 +235,7 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
 }
 
 static void note_page(struct ptdump_state *pt_st, unsigned long addr,
-		      int level, u64 val)
+		      int level, u64 val, unsigned long page_size)
 {
 	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
 	u64 pa = PFN_PHYS(pte_pfn(__pte(val)));
diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c
index e40a30647d99..29673c38e773 100644
--- a/arch/s390/mm/dump_pagetables.c
+++ b/arch/s390/mm/dump_pagetables.c
@@ -116,7 +116,8 @@ static void note_prot_wx(struct pg_state *st, unsigned long addr)
 #endif /* CONFIG_DEBUG_WX */
 }
 
-static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level, u64 val)
+static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
+		      u64 val, unsigned long page_size)
 {
 	int width = sizeof(unsigned long) * 2;
 	static const char units[] = "KMGTPE";
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index e1b599ecbbc2..2ec76737c1f1 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -272,7 +272,7 @@ static void effective_prot(struct ptdump_state *pt_st, int level, u64 val)
  * print what we collected so far.
  */
 static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
-		      u64 val)
+		      u64 val, unsigned long page_size)
 {
 	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
 	pgprotval_t new_prot, new_eff;
diff --git a/include/linux/ptdump.h b/include/linux/ptdump.h
index 2a3a95586425..3a971fadc95e 100644
--- a/include/linux/ptdump.h
+++ b/include/linux/ptdump.h
@@ -13,7 +13,7 @@ struct ptdump_range {
 struct ptdump_state {
 	/* level is 0:PGD to 4:PTE, or -1 if unknown */
 	void (*note_page)(struct ptdump_state *st, unsigned long addr,
-			  int level, u64 val);
+			  int level, u64 val, unsigned long page_size);
 	void (*effective_prot)(struct ptdump_state *st, int level, u64 val);
 	const struct ptdump_range *range;
 };
diff --git a/mm/ptdump.c b/mm/ptdump.c
index da751448d0e4..61cd16afb1c8 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
 {
 	struct ptdump_state *st = walk->private;
 
-	st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
+	st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), PAGE_SIZE);
 
 	walk->action = ACTION_CONTINUE;
 
@@ -41,7 +41,7 @@ static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr,
 		st->effective_prot(st, 0, pgd_val(val));
 
 	if (pgd_leaf(val))
-		st->note_page(st, addr, 0, pgd_val(val));
+		st->note_page(st, addr, 0, pgd_val(val), PGDIR_SIZE);
 
 	return 0;
 }
@@ -62,7 +62,7 @@ static int ptdump_p4d_entry(p4d_t *p4d, unsigned long addr,
 		st->effective_prot(st, 1, p4d_val(val));
 
 	if (p4d_leaf(val))
-		st->note_page(st, addr, 1, p4d_val(val));
+		st->note_page(st, addr, 1, p4d_val(val), P4D_SIZE);
 
 	return 0;
 }
@@ -83,7 +83,7 @@ static int ptdump_pud_entry(pud_t *pud, unsigned long addr,
 		st->effective_prot(st, 2, pud_val(val));
 
 	if (pud_leaf(val))
-		st->note_page(st, addr, 2, pud_val(val));
+		st->note_page(st, addr, 2, pud_val(val), PUD_SIZE);
 
 	return 0;
 }
@@ -102,7 +102,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr,
 	if (st->effective_prot)
 		st->effective_prot(st, 3, pmd_val(val));
 	if (pmd_leaf(val))
-		st->note_page(st, addr, 3, pmd_val(val));
+		st->note_page(st, addr, 3, pmd_val(val), PMD_SIZE);
 
 	return 0;
 }
@@ -116,7 +116,7 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
 	if (st->effective_prot)
 		st->effective_prot(st, 4, pte_val(val));
 
-	st->note_page(st, addr, 4, pte_val(val));
+	st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
 
 	return 0;
 }
@@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long next,
 {
 	struct ptdump_state *st = walk->private;
 
-	st->note_page(st, addr, depth, 0);
+	st->note_page(st, addr, depth, 0, 0);
 
 	return 0;
 }
@@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
 	mmap_read_unlock(mm);
 
 	/* Flush out the last page */
-	st->note_page(st, 0, -1, 0);
+	st->note_page(st, 0, -1, 0, 0);
 }
-- 
2.25.0



From christophe.leroy at csgroup.eu  Thu Apr 15 18:18:18 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Thu, 15 Apr 2021 17:18:18 +0000 (UTC)
Subject: [PATCH v1 5/5] powerpc/mm: Convert powerpc to GENERIC_PTDUMP
In-Reply-To: <cover.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <39ef2dffd6adb6a2bd36e78d301f8be1348fa06b.1618506910.git.christophe.leroy@csgroup.eu>

This patch converts powerpc to the generic PTDUMP implementation.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/powerpc/Kconfig              |   2 +
 arch/powerpc/Kconfig.debug        |  30 ------
 arch/powerpc/mm/Makefile          |   2 +-
 arch/powerpc/mm/mmu_decl.h        |   2 +-
 arch/powerpc/mm/ptdump/8xx.c      |   6 +-
 arch/powerpc/mm/ptdump/Makefile   |   9 +-
 arch/powerpc/mm/ptdump/book3s64.c |   6 +-
 arch/powerpc/mm/ptdump/ptdump.c   | 161 +++++++++---------------------
 arch/powerpc/mm/ptdump/shared.c   |   6 +-
 9 files changed, 68 insertions(+), 156 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 475d77a6ebbe..40259437a28f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -120,6 +120,7 @@ config PPC
 	select ARCH_32BIT_OFF_T if PPC32
 	select ARCH_HAS_DEBUG_VIRTUAL
 	select ARCH_HAS_DEBUG_VM_PGTABLE
+	select ARCH_HAS_DEBUG_WX		if STRICT_KERNEL_RWX
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FORTIFY_SOURCE
@@ -177,6 +178,7 @@ config PPC
 	select GENERIC_IRQ_SHOW
 	select GENERIC_IRQ_SHOW_LEVEL
 	select GENERIC_PCI_IOMAP		if PCI
+	select GENERIC_PTDUMP
 	select GENERIC_SMP_IDLE_THREAD
 	select GENERIC_STRNCPY_FROM_USER
 	select GENERIC_STRNLEN_USER
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 6342f9da4545..05b1180ea502 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -360,36 +360,6 @@ config FAIL_IOMMU
 
 	  If you are unsure, say N.
 
-config PPC_PTDUMP
-	bool "Export kernel pagetable layout to userspace via debugfs"
-	depends on DEBUG_KERNEL && DEBUG_FS
-	help
-	  This option exports the state of the kernel pagetables to a
-	  debugfs file. This is only useful for kernel developers who are
-	  working in architecture specific areas of the kernel - probably
-	  not a good idea to enable this feature in a production kernel.
-
-	  If you are unsure, say N.
-
-config PPC_DEBUG_WX
-	bool "Warn on W+X mappings at boot"
-	depends on PPC_PTDUMP && STRICT_KERNEL_RWX
-	help
-	  Generate a warning if any W+X mappings are found at boot.
-
-	  This is useful for discovering cases where the kernel is leaving
-	  W+X mappings after applying NX, as such mappings are a security risk.
-
-	  Note that even if the check fails, your kernel is possibly
-	  still fine, as W+X mappings are not a security hole in
-	  themselves, what they do is that they make the exploitation
-	  of other unfixed kernel bugs easier.
-
-	  There is no runtime or memory usage effect of this option
-	  once the kernel has booted up - it's a one time check.
-
-	  If in doubt, say "Y".
-
 config PPC_FAST_ENDIAN_SWITCH
 	bool "Deprecated fast endian-switch syscall"
 	depends on DEBUG_KERNEL && PPC_BOOK3S_64
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index c3df3a8501d4..c90d58aaebe2 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -18,5 +18,5 @@ obj-$(CONFIG_PPC_MM_SLICES)	+= slice.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
 obj-$(CONFIG_PPC_COPRO_BASE)	+= copro_fault.o
-obj-$(CONFIG_PPC_PTDUMP)	+= ptdump/
+obj-$(CONFIG_PTDUMP_CORE)	+= ptdump/
 obj-$(CONFIG_KASAN)		+= kasan/
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 7dac910c0b21..dd1cabc2ea0f 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -180,7 +180,7 @@ static inline void mmu_mark_rodata_ro(void) { }
 void __init mmu_mapin_immr(void);
 #endif
 
-#ifdef CONFIG_PPC_DEBUG_WX
+#ifdef CONFIG_DEBUG_WX
 void ptdump_check_wx(void);
 #else
 static inline void ptdump_check_wx(void) { }
diff --git a/arch/powerpc/mm/ptdump/8xx.c b/arch/powerpc/mm/ptdump/8xx.c
index 86da2a669680..fac932eb8f9a 100644
--- a/arch/powerpc/mm/ptdump/8xx.c
+++ b/arch/powerpc/mm/ptdump/8xx.c
@@ -75,8 +75,10 @@ static const struct flag_info flag_array[] = {
 };
 
 struct pgtable_level pg_level[5] = {
-	{
-	}, { /* pgd */
+	{ /* pgd */
+		.flag	= flag_array,
+		.num	= ARRAY_SIZE(flag_array),
+	}, { /* p4d */
 		.flag	= flag_array,
 		.num	= ARRAY_SIZE(flag_array),
 	}, { /* pud */
diff --git a/arch/powerpc/mm/ptdump/Makefile b/arch/powerpc/mm/ptdump/Makefile
index 712762be3cb1..4050cbb55acf 100644
--- a/arch/powerpc/mm/ptdump/Makefile
+++ b/arch/powerpc/mm/ptdump/Makefile
@@ -5,5 +5,10 @@ obj-y	+= ptdump.o
 obj-$(CONFIG_4xx)		+= shared.o
 obj-$(CONFIG_PPC_8xx)		+= 8xx.o
 obj-$(CONFIG_PPC_BOOK3E_MMU)	+= shared.o
-obj-$(CONFIG_PPC_BOOK3S_32)	+= shared.o bats.o segment_regs.o
-obj-$(CONFIG_PPC_BOOK3S_64)	+= book3s64.o hashpagetable.o
+obj-$(CONFIG_PPC_BOOK3S_32)	+= shared.o
+obj-$(CONFIG_PPC_BOOK3S_64)	+= book3s64.o
+
+ifdef CONFIG_PTDUMP_DEBUGFS
+obj-$(CONFIG_PPC_BOOK3S_32)	+= bats.o segment_regs.o
+obj-$(CONFIG_PPC_BOOK3S_64)	+= hashpagetable.o
+endif
diff --git a/arch/powerpc/mm/ptdump/book3s64.c b/arch/powerpc/mm/ptdump/book3s64.c
index 14f73868db66..5ad92d9dc5d1 100644
--- a/arch/powerpc/mm/ptdump/book3s64.c
+++ b/arch/powerpc/mm/ptdump/book3s64.c
@@ -103,8 +103,10 @@ static const struct flag_info flag_array[] = {
 };
 
 struct pgtable_level pg_level[5] = {
-	{
-	}, { /* pgd */
+	{ /* pgd */
+		.flag	= flag_array,
+		.num	= ARRAY_SIZE(flag_array),
+	}, { /* p4d */
 		.flag	= flag_array,
 		.num	= ARRAY_SIZE(flag_array),
 	}, { /* pud */
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index aca354fb670b..9fb1f4fd8af4 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -16,6 +16,7 @@
 #include <linux/io.h>
 #include <linux/mm.h>
 #include <linux/highmem.h>
+#include <linux/ptdump.h>
 #include <linux/sched.h>
 #include <linux/seq_file.h>
 #include <asm/fixmap.h>
@@ -54,13 +55,14 @@
  *
  */
 struct pg_state {
+	struct ptdump_state ptdump;
 	struct seq_file *seq;
 	const struct addr_marker *marker;
 	unsigned long start_address;
 	unsigned long start_pa;
 	unsigned long last_pa;
 	unsigned long page_size;
-	unsigned int level;
+	int level;
 	u64 current_flags;
 	bool check_wx;
 	unsigned long wx_pages;
@@ -216,14 +218,18 @@ static void note_page_update_state(struct pg_state *st, unsigned long addr,
 	}
 }
 
-static void note_page(struct pg_state *st, unsigned long addr,
-	       unsigned int level, u64 val, unsigned long page_size)
+static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
+		      u64 val, unsigned long page_size)
 {
-	u64 flag = val & pg_level[level].mask;
+	struct pg_state *st = container_of(pt_st, struct pg_state, ptdump);
+	u64 flag = 0;
 	u64 pa = val & PTE_RPN_MASK;
 
+	if (level >= 0)
+		flag = val & pg_level[level].mask;
+
 	/* At first no level is set */
-	if (!st->level) {
+	if (st->level == -1) {
 		pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
 		note_page_update_state(st, addr, level, val, page_size);
 	/*
@@ -262,94 +268,6 @@ static void note_page(struct pg_state *st, unsigned long addr,
 	st->last_pa = pa;
 }
 
-static void walk_pte(struct pg_state *st, pmd_t *pmd, unsigned long start)
-{
-	pte_t *pte = pte_offset_kernel(pmd, 0);
-	unsigned long addr;
-	unsigned int i;
-
-	for (i = 0; i < PTRS_PER_PTE; i++, pte++) {
-		addr = start + i * PAGE_SIZE;
-		note_page(st, addr, 4, pte_val(*pte), PAGE_SIZE);
-
-	}
-}
-
-static void walk_hugepd(struct pg_state *st, hugepd_t *phpd, unsigned long start,
-			int pdshift, int level)
-{
-#ifdef CONFIG_ARCH_HAS_HUGEPD
-	unsigned int i;
-	int shift = hugepd_shift(*phpd);
-	int ptrs_per_hpd = pdshift - shift > 0 ? 1 << (pdshift - shift) : 1;
-
-	if (start & ((1 << shift) - 1))
-		return;
-
-	for (i = 0; i < ptrs_per_hpd; i++) {
-		unsigned long addr = start + (i << shift);
-		pte_t *pte = hugepte_offset(*phpd, addr, pdshift);
-
-		note_page(st, addr, level + 1, pte_val(*pte), 1 << shift);
-	}
-#endif
-}
-
-static void walk_pmd(struct pg_state *st, pud_t *pud, unsigned long start)
-{
-	pmd_t *pmd = pmd_offset(pud, 0);
-	unsigned long addr;
-	unsigned int i;
-
-	for (i = 0; i < PTRS_PER_PMD; i++, pmd++) {
-		addr = start + i * PMD_SIZE;
-		if (!pmd_none(*pmd) && !pmd_is_leaf(*pmd))
-			/* pmd exists */
-			walk_pte(st, pmd, addr);
-		else
-			note_page(st, addr, 3, pmd_val(*pmd), PMD_SIZE);
-	}
-}
-
-static void walk_pud(struct pg_state *st, p4d_t *p4d, unsigned long start)
-{
-	pud_t *pud = pud_offset(p4d, 0);
-	unsigned long addr;
-	unsigned int i;
-
-	for (i = 0; i < PTRS_PER_PUD; i++, pud++) {
-		addr = start + i * PUD_SIZE;
-		if (!pud_none(*pud) && !pud_is_leaf(*pud))
-			/* pud exists */
-			walk_pmd(st, pud, addr);
-		else
-			note_page(st, addr, 2, pud_val(*pud), PUD_SIZE);
-	}
-}
-
-static void walk_pagetables(struct pg_state *st)
-{
-	unsigned int i;
-	unsigned long addr = st->start_address & PGDIR_MASK;
-	pgd_t *pgd = pgd_offset_k(addr);
-
-	/*
-	 * Traverse the linux pagetable structure and dump pages that are in
-	 * the hash pagetable.
-	 */
-	for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr += PGDIR_SIZE) {
-		p4d_t *p4d = p4d_offset(pgd, 0);
-
-		if (p4d_none(*p4d) || p4d_is_leaf(*p4d))
-			note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
-		else if (is_hugepd(__hugepd(p4d_val(*p4d))))
-			walk_hugepd(st, (hugepd_t *)p4d, addr, PGDIR_SHIFT, 1);
-		else
-			/* p4d exists */
-			walk_pud(st, p4d, addr);
-	}
-}
-
 static void populate_markers(void)
 {
 	int i = 0;
@@ -399,32 +317,29 @@ static int ptdump_show(struct seq_file *m, void *v)
 	struct pg_state st = {
 		.seq = m,
 		.marker = address_markers,
-		.start_address = IS_ENABLED(CONFIG_PPC64) ? PAGE_OFFSET : TASK_SIZE,
+		.level = -1,
+		.ptdump = {
+			.note_page = note_page,
+			.range = (struct ptdump_range[]){
+				{TASK_SIZE, ~0UL},
+				{0, 0}
+			}
+		}
 	};
 
 #ifdef CONFIG_PPC64
 	if (!radix_enabled())
-		st.start_address = KERN_VIRT_START;
+		st.ptdump.range.start = KERN_VIRT_START;
+	else
+		st.ptdump.range.start = PAGE_OFFSET;
 #endif
 
 	/* Traverse kernel page tables */
-	walk_pagetables(&st);
-	note_page(&st, 0, 0, 0, 0);
+	ptdump_walk_pgd(&st.ptdump, &init_mm, NULL);
 	return 0;
 }
 
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
-	return single_open(file, ptdump_show, NULL);
-}
-
-static const struct file_operations ptdump_fops = {
-	.open		= ptdump_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
 
 static void build_pgtable_complete_mask(void)
 {
@@ -436,22 +351,34 @@ static void build_pgtable_complete_mask(void)
 				pg_level[i].mask |= pg_level[i].flag[j].mask;
 }
 
-#ifdef CONFIG_PPC_DEBUG_WX
+#ifdef CONFIG_DEBUG_WX
 void ptdump_check_wx(void)
 {
 	struct pg_state st = {
 		.seq = NULL,
-		.marker = address_markers,
+		.marker = (struct addr_marker[]) {
+			{ 0, NULL},
+			{ -1, NULL},
+		},
+		.level = -1,
 		.check_wx = true,
-		.start_address = IS_ENABLED(CONFIG_PPC64) ? PAGE_OFFSET : TASK_SIZE,
+		.ptdump = {
+			.note_page = note_page,
+			.range = (struct ptdump_range[]){
+				{TASK_SIZE, ~0UL},
+				{0, 0}
+			}
+		}
 	};
 
 #ifdef CONFIG_PPC64
 	if (!radix_enabled())
-		st.start_address = KERN_VIRT_START;
+		st.ptdump.range.start = KERN_VIRT_START;
+	else
+		st.ptdump.range.start = PAGE_OFFSET;
 #endif
 
-	walk_pagetables(&st);
+	ptdump_walk_pgd(&st.ptdump, &init_mm, NULL);
 
 	if (st.wx_pages)
 		pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found\n",
@@ -465,8 +392,10 @@ static int ptdump_init(void)
 {
 	populate_markers();
 	build_pgtable_complete_mask();
-	debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
-			    &ptdump_fops);
+
+	if (IS_ENABLED(CONFIG_PTDUMP_DEBUGFS))
+		debugfs_create_file("kernel_page_tables", 0400, NULL, NULL, &ptdump_fops);
+
 	return 0;
 }
 device_initcall(ptdump_init);
diff --git a/arch/powerpc/mm/ptdump/shared.c b/arch/powerpc/mm/ptdump/shared.c
index c005fe041c18..03607ab90c66 100644
--- a/arch/powerpc/mm/ptdump/shared.c
+++ b/arch/powerpc/mm/ptdump/shared.c
@@ -68,8 +68,10 @@ static const struct flag_info flag_array[] = {
 };
 
 struct pgtable_level pg_level[5] = {
-	{
-	}, { /* pgd */
+	{ /* pgd */
+		.flag	= flag_array,
+		.num	= ARRAY_SIZE(flag_array),
+	}, { /* p4d */
 		.flag	= flag_array,
 		.num	= ARRAY_SIZE(flag_array),
 	}, { /* pud */
-- 
2.25.0



From catalin.marinas at arm.com  Thu Apr 15 18:48:29 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 15 Apr 2021 18:48:29 +0100
Subject: [PATCH] arm64: alternatives: Move length validation in
 alternative_{insn, endif}
In-Reply-To: <20210414000803.662534-1-nathan@kernel.org>
References: <20210414000803.662534-1-nathan@kernel.org>
Message-ID: <161850887861.19953.221061108559265600.b4-ty@arm.com>

On Tue, 13 Apr 2021 17:08:04 -0700, Nathan Chancellor wrote:
> After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
> set atomically"), LLVM's integrated assembler fails to build entry.S:
> 
> <instantiation>:5:7: error: expected assembly-time absolute expression
>  .org . - (664b-663b) + (662b-661b)
>       ^
> <instantiation>:6:7: error: expected assembly-time absolute expression
>  .org . - (662b-661b) + (664b-663b)
>       ^
> 
> [...]

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64: alternatives: Move length validation in alternative_{insn, endif}
      https://git.kernel.org/arm64/c/22315a2296f4

-- 
Catalin



From brouer at redhat.com  Thu Apr 15 19:08:32 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Thu, 15 Apr 2021 20:08:32 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
References: <20210410205246.507048-1-willy@infradead.org>
 <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
Message-ID: <20210415200832.32796445@carbon>

On Wed, 14 Apr 2021 21:56:39 +0000
David Laight <David.Laight at ACULAB.COM> wrote:

> From: Matthew Wilcox
> > Sent: 14 April 2021 22:36
> > 
> > On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:  
> > > (If others want to reproduce).  First I could not reproduce on ARM32.
> > > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > > cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.  
> > 
> > hmmm ... you should be able to provoke it by enabling ARM_LPAE,
> > which selects PHYS_ADDR_T_64BIT, and
> > 
> > config ARCH_DMA_ADDR_T_64BIT
> >         def_bool 64BIT || PHYS_ADDR_T_64BIT
> >   
> > >  struct page {
> > >         long unsigned int          flags;                /*     0     4 */
> > >
> > >         /* XXX 4 bytes hole, try to pack */
> > >
> > >         union {
> > >                 struct {
> > >                         struct list_head lru;            /*     8     8 */
> > >                         struct address_space * mapping;  /*    16     4 */
> > >                         long unsigned int index;         /*    20     4 */
> > >                         long unsigned int private;       /*    24     4 */
> > >                 };                                       /*     8    20 */
> > >                 struct {
> > >                         dma_addr_t dma_addr  
> 
> Adding __packed here will remove the 4 byte hole before the union
> and the compiler seems clever enough to know that anything following
> a 'long' must also be 'long' aligned.

Played with __packed in below patch, and I can confirm it seems to work.

> So you don't get anything horrid like byte accesses.
> On 64bit dma_addr will remain 64bit aligned.
> On arm32 dma_addr will be 32bit aligned - but forcing two 32bit access
> won't make any difference.

See below patch.  Where I swap32 the dma address to satisfy
page->compound having bit zero cleared. (It is the simplest fix I could
come up with).


[PATCH] page_pool: handling 32-bit archs with 64-bit dma_addr_t

From: Jesper Dangaard Brouer <brouer at redhat.com>

Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
page.  The page->dma_addr share area with page->compound_head which
use bit zero to mark compound pages. This is okay, as DMA-addr are
aligned pointers which have bit zero cleared.

In the 32-bit case, page->compound_head is 32-bit.  Thus, when
dma_addr_t is 64-bit it will be located in top 32-bit.  Solve by
swapping dma_addr 32-bit segments.

Signed-off-by: Jesper Dangaard Brouer <brouer at redhat.com>
---
 include/linux/mm_types.h |    2 +-
 include/linux/types.h    |    1 +
 include/net/page_pool.h  |   21 ++++++++++++++++++++-
 net/core/page_pool.c     |    8 +++++---
 4 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..27406e3b1e1b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -100,7 +100,7 @@ struct page {
 			 * @dma_addr: might require a 64-bit value even on
 			 * 32-bit architectures.
 			 */
-			dma_addr_t dma_addr;
+			dma_addr_t dma_addr __packed;
 		};
 		struct {	/* slab, slob and slub */
 			union {
diff --git a/include/linux/types.h b/include/linux/types.h
index ac825ad90e44..65fd5d630016 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -141,6 +141,7 @@ typedef u64 blkcnt_t;
  */
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
 typedef u64 dma_addr_t;
+//typedef u64 __attribute__((aligned(sizeof(void *)))) dma_addr_t;
 #else
 typedef u32 dma_addr_t;
 #endif
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b5b195305346..c2329088665c 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -196,9 +196,28 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
 	page_pool_put_full_page(pool, page, true);
 }
 
+static inline
+dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
+{
+	/* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
+	 * page.  The page->dma_addr share area with page->compound_head which
+	 * use bit zero to mark compound pages. This is okay, as DMA-addr are
+	 * aligned pointers which have bit zero cleared.
+	 *
+	 * In the 32-bit case, page->compound_head is 32-bit.  Thus, when
+	 * dma_addr_t is 64-bit it will be located in top 32-bit.  Solve by
+	 * swapping dma_addr 32-bit segments.
+	 */
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+	if (sizeof(long unsigned int) == 4) /* 32-bit system */
+		dma_addr = (dma_addr << 32) | (dma_addr >> 32);
+#endif
+	return dma_addr;
+}
+
 static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
 {
-	return page->dma_addr;
+	return page_pool_dma_addr_read(page->dma_addr);
 }
 
 static inline bool is_page_pool_compiled_in(void)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index ad8b0707af04..813598ea23f6 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
 					  struct page *page,
 					  unsigned int dma_sync_size)
 {
+	dma_addr_t dma = page_pool_dma_addr_read(page->dma_addr);
+
 	dma_sync_size = min(dma_sync_size, pool->p.max_len);
-	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
+	dma_sync_single_range_for_device(pool->p.dev, dma,
 					 pool->p.offset, dma_sync_size,
 					 pool->p.dma_dir);
 }
@@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
 		put_page(page);
 		return NULL;
 	}
-	page->dma_addr = dma;
+	page->dma_addr = page_pool_dma_addr_read(dma);
 
 	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
 		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
@@ -294,7 +296,7 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
 		 */
 		goto skip_dma_unmap;
 
-	dma = page->dma_addr;
+	dma = page_pool_dma_addr_read(page->dma_addr);
 
 	/* When page is unmapped, it cannot be returned our pool */
 	dma_unmap_page_attrs(pool->p.dev, dma,


--
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer



From valentin.schneider at arm.com  Thu Apr 15 19:09:28 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu, 15 Apr 2021 19:09:28 +0100
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
Message-ID: <8735vrmnc7.mognet@arm.com>

On 14/04/21 20:23, Ruifeng Zhang wrote:
> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>
> In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
> version, one of them is the kernel running on EL1 using aarch32.
>                 user(EL0)             kernel(EL1)
> sc9863a_go      aarch32               aarch32
> sc9863a         aarch64               aarch64
>
> When kernel runs on EL1 using aarch32, the topology will parse wrong.
> For example,
> The MPIDR has been written to the chip register in armv8.2 format.
> For example,
> core0: 0000000080000000
> core1: 0000000080000100
> core2: 0000000080000200
> ...
>
> It will parse to:
> |       | aff2 | packageid | coreid |
> |-------+------+-----------+--------|
> | Core0 |    0 |         0 |    0   |
> | Core1 |    0 |         1 |    0   |
> | Core2 |    0 |         2 |    0   |
> |  ...  |      |           |        |
>
> The wrong topology is that all of the coreid are 0 and unexpected
> packageid.
>
> The reason is the MPIDR format is different between armv7 and armv8.2.
> armv7 (A7) mpidr is:
> [11:8]      [7:2]       [1:0]
> cluster     reserved    cpu
> The cortex-a7 spec DDI0464F 4.3.5
> https://developer.arm.com/documentation/ddi0464/f/?lang=en
>
> armv8.2 (A55) mpidr is:
> [23:16]     [15:8]      [7:0]
> cluster     cpu         thread
>

What I had understood from our conversation was that there *isn't* a format
difference (at least for the bottom 32 bits) - arm64/kernel/topopology.c
would parse it the same, except that MPIDR parsing has been deprecated for
arm64.

The problem is that those MPIDR values don't match the actual topology. If
they had the MT bit set, i.e.

  core0: 0000000081000000
  core1: 0000000081000100
  core2: 0000000081000200

then it would be parsed as:

  |       | package_id | core_id | thread_id |
  |-------+------------+---------+-----------|
  | Core0 |          0 |       0 |         0 |
  | Core1 |          0 |       1 |         0 |
  | Core2 |          0 |       2 |         0 |

which would make more sense (wrt the actual, physical topology).


From valentin.schneider at arm.com  Thu Apr 15 19:09:41 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Thu, 15 Apr 2021 19:09:41 +0100
Subject: [PATCH v2 1/1] arm: topology: parse the topology from the dt
In-Reply-To: <20210414122326.5255-2-ruifeng.zhang0110@gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <20210414122326.5255-2-ruifeng.zhang0110@gmail.com>
Message-ID: <871rbbmnbu.mognet@arm.com>

On 14/04/21 20:23, Ruifeng Zhang wrote:
> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>
> The arm topology still parse from the MPIDR, but it is incomplete.  When
> the armv8.2 or above cpu runs kernel in EL1 with aarch32 mode, it will
> parse out the wrong topology.
>

Per my other email, isn't the problem that MPIDR can't be trusted to
properly represent the topology, and thus a new method of describing the
topology (cpu-map) has to be used?


From dan.carpenter at oracle.com  Thu Apr 15 19:18:50 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 15 Apr 2021 21:18:50 +0300
Subject: [PATCH] clk: uniphier: Fix potential infinite loop
In-Reply-To: <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>
References: <20210407152457.497346-1-colin.king@canonical.com>
 <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>
Message-ID: <20210415181850.GD6021@kadam>

On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote:
> On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king at canonical.com> wrote:
> >
> > From: Colin Ian King <colin.king at canonical.com>
> >
> > The for-loop iterates with a u8 loop counter i and compares this
> > with the loop upper limit of num_parents that is an int type.
> > There is a potential infinite loop if num_parents is larger than
> > the u8 loop counter. Fix this by making the loop counter the same
> > type as num_parents.
> >
> > Addresses-Coverity: ("Infinite loop")
> > Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
> > Signed-off-by: Colin Ian King <colin.king at canonical.com>
> > ---
> >  drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
> > index 462c84321b2d..ce219e0d2a85 100644
> > --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> > +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> > @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
> >         int num_parents = clk_hw_get_num_parents(hw);
> >         int ret;
> >         unsigned int val;
> > -       u8 i;
> > +       int i;
> >
> >         ret = regmap_read(mux->regmap, mux->reg, &val);
> >         if (ret)
> > --
> > 2.30.2
> >
> 
> clk_hw_get_num_parents() returns 'unsigned int', so
> I think 'num_parents' should also have been 'unsigned int'.
> 
> Maybe, the loop counter 'i' also should be 'unsigned int' then?

The clk_hw_get_num_parents() function returns 0-255 so the original code
works fine.

It should basically always be "int i;"  That's the safest assumption.
There are other case where it has to be size_t but in those cases I
think people should call the list iterator something else instead of "i"
like "size_t pg_idx;".

Making everthing u32 causes more bugs than it prevents.  Signedness bugs
with comparing to zero, type promotion bugs, or subtraction bugs where
subtracting wraps to a high value.  It's rare to loop more than INT_MAX
times in the kernel.  When we do need to count about 2 million then
we're probably not going to stop counting at 4 million, we're going to
go to 10 million or higher so size_t is more appropriate than u32.

Btw, if you have a loop that does:

	for (i = 0; i < UINT_MAX; i++) {

that loop works exactly the same if "i" is an int or if it's a u32
because of type promotion.  So you have to look really hard to find a
place where changing a loop iterator from int to u32 fixes bug in real
life.

regards,
dan carpenter


From zackr at vmware.com  Thu Apr 15 19:21:45 2021
From: zackr at vmware.com (Zack Rusin)
Date: Thu, 15 Apr 2021 14:21:45 -0400
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <20210415110040.23525-2-tzimmermann@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-2-tzimmermann@suse.de>
Message-ID: <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>

On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
> Respect DRM's kconfig setting for fbdev console emulation. If enabled,
> it will select all required config options. So remove them from vmwgfx's
> Kconfig file.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
> ---
>   drivers/gpu/drm/vmwgfx/Kconfig      |  7 +------
>   drivers/gpu/drm/vmwgfx/Makefile     |  4 +++-
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
>   3 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
> index 15acdf2a7c0f..b3a34196935b 100644
> --- a/drivers/gpu/drm/vmwgfx/Kconfig
> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> @@ -2,12 +2,7 @@
>   config DRM_VMWGFX
>   	tristate "DRM driver for VMware Virtual GPU"
>   	depends on DRM && PCI && X86 && MMU
> -	select FB_DEFERRED_IO
> -	select FB_CFB_FILLRECT
> -	select FB_CFB_COPYAREA
> -	select FB_CFB_IMAGEBLIT
>   	select DRM_TTM
> -	select FB
>   	select MAPPING_DIRTY_HELPERS
>   	# Only needed for the transitional use of drm_crtc_init - can be removed
>   	# again once vmwgfx sets up the primary plane itself.
> @@ -20,7 +15,7 @@ config DRM_VMWGFX
>   	  The compiled module will be called "vmwgfx.ko".
>   
>   config DRM_VMWGFX_FBCON
> -	depends on DRM_VMWGFX && FB
> +	depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
>   	bool "Enable framebuffer console under vmwgfx by default"
>   	help
>   	   Choose this option if you are shipping a new vmwgfx
> diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
> index 8c02fa5852e7..9f5743013cbb 100644
> --- a/drivers/gpu/drm/vmwgfx/Makefile
> +++ b/drivers/gpu/drm/vmwgfx/Makefile
> @@ -1,6 +1,6 @@
>   # SPDX-License-Identifier: GPL-2.0
>   vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
> -	    vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
> +	    vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
>   	    vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
>   	    vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
>   	    vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
> @@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
>   	    vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
>   	    ttm_object.o ttm_lock.o ttm_memory.o
>   
> +vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
>   vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
> +
>   obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 7e6518709e14..e7836da190c4 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct vmw_private *dev_priv,
>    * Kernel framebuffer - vmwgfx_fb.c
>    */
>   
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>   int vmw_fb_init(struct vmw_private *vmw_priv);
>   int vmw_fb_close(struct vmw_private *dev_priv);
>   int vmw_fb_off(struct vmw_private *vmw_priv);
>   int vmw_fb_on(struct vmw_private *vmw_priv);
> +#else
> +static inline int vmw_fb_init(struct vmw_private *vmw_priv)
> +{
> +	return 0;
> +}
> +static inline int vmw_fb_close(struct vmw_private *dev_priv)
> +{
> +	return 0;
> +}
> +static inline int vmw_fb_off(struct vmw_private *vmw_priv)
> +{
> +	return 0;
> +}
> +static inline int vmw_fb_on(struct vmw_private *vmw_priv)
> +{
> +	return 0;
> +}
> +#endif
>   
>   /**
>    * Kernel modesetting - vmwgfx_kms.c
> 

This changes the behavior a bit, I guess DRM_VMWGFX (or at least DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve the old behavior, but that's largely due to the fact that given how those options were setup we never run without FB set. In general it should be ok and looks more reasonable than the current setup. I'll try it out on Monday just in case, but for now:

Reviewed-by: Zack Rusin <zackr at vmware.com>

z


From willy at infradead.org  Thu Apr 15 19:21:55 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Thu, 15 Apr 2021 19:21:55 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210415200832.32796445@carbon>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
Message-ID: <20210415182155.GD2531743@casper.infradead.org>

On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> +static inline
> +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> +{
> +	/* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> +	 * page.  The page->dma_addr share area with page->compound_head which
> +	 * use bit zero to mark compound pages. This is okay, as DMA-addr are
> +	 * aligned pointers which have bit zero cleared.
> +	 *
> +	 * In the 32-bit case, page->compound_head is 32-bit.  Thus, when
> +	 * dma_addr_t is 64-bit it will be located in top 32-bit.  Solve by
> +	 * swapping dma_addr 32-bit segments.
> +	 */
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT

#if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) && defined(__BIG_ENDIAN)
otherwise you'll create the problem on ARM that you're avoiding on PPC ...

I think you want to delete the word '_read' from this function name because
you're using it for both read and write.



From broonie at kernel.org  Thu Apr 15 19:33:42 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 15 Apr 2021 19:33:42 +0100
Subject: [PATCH 1/3] spi: s3c64xx: simplify getting of_device_id match data
In-Reply-To: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
References: <20210414203343.203119-1-krzysztof.kozlowski@canonical.com>
Message-ID: <161851161879.23304.6673914019585638025.b4-ty@kernel.org>

On Wed, 14 Apr 2021 22:33:41 +0200, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller and to
> remove the of_device_id table forward declaration.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/3] spi: s3c64xx: simplify getting of_device_id match data
      commit: 609a2f9529d3d3e627776614b6cff34b21f64144
[2/3] spi: s3c64xx: correct kerneldoc of s3c64xx_spi_port_config
      commit: 7d712f799a938b37d24359ea836f58866be5e0bb
[3/3] spi: s3c64xx: constify driver/match data
      commit: d6371415517700ae225dd1aaa8a35a86a659ada6

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 Apr 15 19:33:41 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 15 Apr 2021 19:33:41 +0100
Subject: [PATCH] [v4] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in
 zynqmp_qspi_probe
In-Reply-To: <20210415074644.24646-1-dinghao.liu@zju.edu.cn>
References: <20210415074644.24646-1-dinghao.liu@zju.edu.cn>
Message-ID: <161851161878.23304.12649397818878323854.b4-ty@kernel.org>

On Thu, 15 Apr 2021 15:46:44 +0800, Dinghao Liu wrote:
> There is a PM usage counter decrement after zynqmp_qspi_init_hw()
> without any refcount increment, which leads to refcount leak.Add
> a refcount increment to balance the refcount. Also set
> auto_runtime_pm to resume suspended spi controller.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe
      commit: 58eaa7b2d07d3c25e1068b0bf42ca7e7464f4bca

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 eugen.hristev at microchip.com  Thu Apr 15 19:45:00 2021
From: eugen.hristev at microchip.com (Eugen Hristev)
Date: Thu, 15 Apr 2021 21:45:00 +0300
Subject: [PATCH v5 30/33] dt-bindings: media: add microchip,
 xisc device bindings
In-Reply-To: <20210415085846.824796-1-eugen.hristev@microchip.com>
References: <20210415085846.824796-1-eugen.hristev@microchip.com>
Message-ID: <20210415184500.868264-1-eugen.hristev@microchip.com>

Add bindings for the Microchip eXtended Image Sensor Controller.
Based on the atmel,isc.yaml binding.

Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
---
Changes in v5:
- fixed license clause to add BSD-2
Changes in v4:
- added '|' at description to preserve line breaks

 .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
 1 file changed, 129 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml

diff --git a/Documentation/devicetree/bindings/media/microchip,xisc.yaml b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
new file mode 100644
index 000000000000..41afe2e5f133
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/microchip,xisc.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2021 Microchip Technology, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/microchip,xisc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip eXtended Image Sensor Controller (XISC)
+
+maintainers:
+  - Eugen Hristev <eugen.hristev at microchip.com>
+
+description: |
+  The eXtended Image Sensor Controller (XISC) device provides the video input capabilities for the
+  Microchip AT91 SAM family of devices.
+
+  The XISC has a single internal parallel input that supports RAW Bayer, RGB or YUV video.
+  The source can be either a demuxer from a CSI2 type of bus, or a simple direct bridge to a
+  parallel sensor.
+
+  The XISC provides one clock output that is used to clock the demuxer/bridge.
+
+properties:
+  compatible:
+    const: microchip,sama7g5-isc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: hclock
+
+  '#clock-cells':
+    const: 0
+
+  clock-output-names:
+    const: isc-mck
+
+  microchip,mipi-mode:
+    type: boolean
+    description:
+      As the XISC is usually connected to a demux/bridge, the XISC receives
+      the same type of input, however, it should be aware of the type of
+      signals received. The mipi-mode enables different internal handling
+      of the data and clock lines.
+
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description:
+      Input port node, single endpoint describing the input pad.
+
+    properties:
+      endpoint:
+        $ref: video-interfaces.yaml#
+
+        properties:
+          bus-type:
+            enum: [5, 6]
+
+          remote-endpoint: true
+
+          bus-width:
+            enum: [8, 9, 10, 11, 12]
+            default: 12
+
+          hsync-active:
+            enum: [0, 1]
+            default: 1
+
+          vsync-active:
+            enum: [0, 1]
+            default: 1
+
+          pclk-sample:
+            enum: [0, 1]
+            default: 1
+
+        required:
+          - remote-endpoint
+          - bus-type
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - clock-output-names
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/at91.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    xisc: xisc at e1408000 {
+        compatible = "microchip,sama7g5-isc";
+        reg = <0xe1408000 0x2000>;
+        interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+        clock-names = "hclock";
+        #clock-cells = <0>;
+        clock-output-names = "isc-mck";
+
+        port {
+                xisc_in: endpoint {
+                       bus-type = <5>; /* Parallel */
+                       remote-endpoint = <&csi2dc_out>;
+                       hsync-active = <1>;
+                       vsync-active = <1>;
+                       bus-width = <12>;
+                };
+        };
+    };
+
-- 
2.25.1



From daniel at ffwll.ch  Thu Apr 15 19:49:32 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 15 Apr 2021 20:49:32 +0200
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-2-tzimmermann@suse.de>
 <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
Message-ID: <CAKMK7uGVuw_ViUL3do=VD6o1Xj-6Wd3a4uuF=yTc5oDhtu77Jg@mail.gmail.com>

On Thu, Apr 15, 2021 at 8:21 PM Zack Rusin <zackr at vmware.com> wrote:
>
> On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
> > Respect DRM's kconfig setting for fbdev console emulation. If enabled,
> > it will select all required config options. So remove them from vmwgfx's
> > Kconfig file.
> >
> > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
> > ---
> >   drivers/gpu/drm/vmwgfx/Kconfig      |  7 +------
> >   drivers/gpu/drm/vmwgfx/Makefile     |  4 +++-
> >   drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
> >   3 files changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
> > index 15acdf2a7c0f..b3a34196935b 100644
> > --- a/drivers/gpu/drm/vmwgfx/Kconfig
> > +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> > @@ -2,12 +2,7 @@
> >   config DRM_VMWGFX
> >       tristate "DRM driver for VMware Virtual GPU"
> >       depends on DRM && PCI && X86 && MMU
> > -     select FB_DEFERRED_IO
> > -     select FB_CFB_FILLRECT
> > -     select FB_CFB_COPYAREA
> > -     select FB_CFB_IMAGEBLIT
> >       select DRM_TTM
> > -     select FB
> >       select MAPPING_DIRTY_HELPERS
> >       # Only needed for the transitional use of drm_crtc_init - can be removed
> >       # again once vmwgfx sets up the primary plane itself.
> > @@ -20,7 +15,7 @@ config DRM_VMWGFX
> >         The compiled module will be called "vmwgfx.ko".
> >
> >   config DRM_VMWGFX_FBCON
> > -     depends on DRM_VMWGFX && FB
> > +     depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
> >       bool "Enable framebuffer console under vmwgfx by default"
> >       help
> >          Choose this option if you are shipping a new vmwgfx
> > diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
> > index 8c02fa5852e7..9f5743013cbb 100644
> > --- a/drivers/gpu/drm/vmwgfx/Makefile
> > +++ b/drivers/gpu/drm/vmwgfx/Makefile
> > @@ -1,6 +1,6 @@
> >   # SPDX-License-Identifier: GPL-2.0
> >   vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
> > -         vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
> > +         vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
> >           vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
> >           vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
> >           vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
> > @@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
> >           vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
> >           ttm_object.o ttm_lock.o ttm_memory.o
> >
> > +vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
> >   vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
> > +
> >   obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index 7e6518709e14..e7836da190c4 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct vmw_private *dev_priv,
> >    * Kernel framebuffer - vmwgfx_fb.c
> >    */
> >
> > +#ifdef CONFIG_DRM_FBDEV_EMULATION
> >   int vmw_fb_init(struct vmw_private *vmw_priv);
> >   int vmw_fb_close(struct vmw_private *dev_priv);
> >   int vmw_fb_off(struct vmw_private *vmw_priv);
> >   int vmw_fb_on(struct vmw_private *vmw_priv);
> > +#else
> > +static inline int vmw_fb_init(struct vmw_private *vmw_priv)
> > +{
> > +     return 0;
> > +}
> > +static inline int vmw_fb_close(struct vmw_private *dev_priv)
> > +{
> > +     return 0;
> > +}
> > +static inline int vmw_fb_off(struct vmw_private *vmw_priv)
> > +{
> > +     return 0;
> > +}
> > +static inline int vmw_fb_on(struct vmw_private *vmw_priv)
> > +{
> > +     return 0;
> > +}
> > +#endif
> >
> >   /**
> >    * Kernel modesetting - vmwgfx_kms.c
> >
>
> This changes the behavior a bit, I guess DRM_VMWGFX (or at least DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve the old behavior, but that's largely due to the fact that given how those options were setup we never run without FB set. In general it should be ok and looks more reasonable than the current setup. I'll try it out on Monday just in case, but for now:

The issue is that select in Kconfig is pretty annoying (hard to
disable, and it's not recursive), so there's a bit a push to retire
it. Especially for user-facing config knobs like whether you want
fbdev emulation or not. Hence the change.
-Daniel

> Reviewed-by: Zack Rusin <zackr at vmware.com>
>
> z



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From tzimmermann at suse.de  Thu Apr 15 19:50:26 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Thu, 15 Apr 2021 20:50:26 +0200
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-2-tzimmermann@suse.de>
 <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
Message-ID: <a7c61e61-cc6f-93db-7d49-2dc666143ab8@suse.de>

Hi

Am 15.04.21 um 20:21 schrieb Zack Rusin:
> On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
>> Respect DRM's kconfig setting for fbdev console emulation. If enabled,
>> it will select all required config options. So remove them from vmwgfx's
>> Kconfig file.
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>> ---
>> ? drivers/gpu/drm/vmwgfx/Kconfig????? |? 7 +------
>> ? drivers/gpu/drm/vmwgfx/Makefile???? |? 
4 +++-
>> ? drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
>> ? 3 files changed, 23 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig 
>> b/drivers/gpu/drm/vmwgfx/Kconfig
>> index 15acdf2a7c0f..b3a34196935b 100644
>> --- a/drivers/gpu/drm/vmwgfx/Kconfig
>> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
>> @@ -2,12 +2,7 @@
>> ? config DRM_VMWGFX
>> ????? tristate "DRM driver for VMware Virtual 
GPU"
>> ????? depends on DRM && PCI && X86 && MMU
>> -??? select FB_DEFERRED_IO
>> -??? select FB_CFB_FILLRECT
>> -??? select FB_CFB_COPYAREA
>> -??? select FB_CFB_IMAGEBLIT
>> ????? select DRM_TTM
>> -??? select FB
>> ????? select MAPPING_DIRTY_HELPERS
>> ????? # Only needed for the transitional use of drm_crtc_init - can be 
>> removed
>> ????? # again once vmwgfx sets up the primary 
plane itself.
>> @@ -20,7 +15,7 @@ config DRM_VMWGFX
>> ??????? The compiled module will be 
called "vmwgfx.ko".
>> ? config DRM_VMWGFX_FBCON
>> -??? depends on DRM_VMWGFX && FB
>> +??? depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
>> ????? bool "Enable framebuffer console under vmwgfx by default"
>> ????? help
>> ???????? Choose this option if 
you are shipping a new vmwgfx
>> diff --git a/drivers/gpu/drm/vmwgfx/Makefile 
>> b/drivers/gpu/drm/vmwgfx/Makefile
>> index 8c02fa5852e7..9f5743013cbb 100644
>> --- a/drivers/gpu/drm/vmwgfx/Makefile
>> +++ b/drivers/gpu/drm/vmwgfx/Makefile
>> @@ -1,6 +1,6 @@
>> ? # SPDX-License-Identifier: GPL-2.0
>> ? vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
>> -??????? vmwgfx_fb.o vmwgfx_ioctl.o 
vmwgfx_resource.o 
>> vmwgfx_ttm_buffer.o \
>> +??????? vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
>> ????????? vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
>> ????????? vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
>> ????????? vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
>> @@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o 
>> vmwgfx_kms.o vmwgfx_drv.o \
>> ????????? vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
>> ????????? ttm_object.o ttm_lock.o ttm_memory.o
>> +vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
>> ? vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
>> +
>> ? obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> index 7e6518709e14..e7836da190c4 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>> @@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct 
>> vmw_private *dev_priv,
>> ?? * Kernel framebuffer - vmwgfx_fb.c
>> ?? */
>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>> ? int vmw_fb_init(struct vmw_private *vmw_priv);
>> ? int vmw_fb_close(struct vmw_private *dev_priv);
>> ? int vmw_fb_off(struct vmw_private *vmw_priv);
>> ? int vmw_fb_on(struct vmw_private *vmw_priv);
>> +#else
>> +static inline int vmw_fb_init(struct vmw_private *vmw_priv)
>> +{
>> +??? return 0;
>> +}
>> +static inline int vmw_fb_close(struct vmw_private *dev_priv)
>> +{
>> +??? return 0;
>> +}
>> +static inline int vmw_fb_off(struct vmw_private *vmw_priv)
>> +{
>> +??? return 0;
>> +}
>> +static inline int vmw_fb_on(struct vmw_private *vmw_priv)
>> +{
>> +??? return 0;
>> +}
>> +#endif
>> ? /**
>> ?? * Kernel modesetting - vmwgfx_kms.c
>>
> 
> This changes the behavior a bit, I guess DRM_VMWGFX (or at least 
> DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve 
> the old behavior, but that's largely due to the fact that given how 
> those options were setup we never run without FB set. In general it 
> should be ok and looks more reasonable than the current setup. I'll try 

> it out on Monday just in case, but for now:
> 
> Reviewed-by: Zack Rusin <zackr at vmware.com>
> 

All other drivers use DRM_FBDEV_EMULATION, so vmwgfx would follow common 
conventions.

AFAICT DRM_VMWGFX_FBCON is just the default on/off setting. How about 
making DRM_VMWGFX_FBCON depend on DRM_FBDEV_EMULATION? Users would be 
able to enable fbdev emulation in general and, if needed, still pick a 
separate default on/off for vmwgfx.

Best regards
Thomas

> z

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 N?rnberg, Germany
(HRB 36809, AG N?rnberg)
Gesch?ftsf?hrer: Felix Imend?rffer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210415/d0591c71/attachment.sig>

From zackr at vmware.com  Thu Apr 15 20:14:40 2021
From: zackr at vmware.com (Zack Rusin)
Date: Thu, 15 Apr 2021 15:14:40 -0400
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <CAKMK7uGVuw_ViUL3do=VD6o1Xj-6Wd3a4uuF=yTc5oDhtu77Jg@mail.gmail.com>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-2-tzimmermann@suse.de>
 <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
 <CAKMK7uGVuw_ViUL3do=VD6o1Xj-6Wd3a4uuF=yTc5oDhtu77Jg@mail.gmail.com>
Message-ID: <0144bd91-0a40-e201-0ec8-d1d87a297433@vmware.com>

On 4/15/21 2:49 PM, Daniel Vetter wrote:
> On Thu, Apr 15, 2021 at 8:21 PM Zack Rusin <zackr at vmware.com> wrote:
>>
>> On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
>>> Respect DRM's kconfig setting for fbdev console emulation. If enabled,
>>> it will select all required config options. So remove them from vmwgfx's
>>> Kconfig file.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>>> ---
>>>    drivers/gpu/drm/vmwgfx/Kconfig      |  7 +------
>>>    drivers/gpu/drm/vmwgfx/Makefile     |  4 +++-
>>>    drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
>>>    3 files changed, 23 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
>>> index 15acdf2a7c0f..b3a34196935b 100644
>>> --- a/drivers/gpu/drm/vmwgfx/Kconfig
>>> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
>>> @@ -2,12 +2,7 @@
>>>    config DRM_VMWGFX
>>>        tristate "DRM driver for VMware Virtual GPU"
>>>        depends on DRM && PCI && X86 && MMU
>>> -     select FB_DEFERRED_IO
>>> -     select FB_CFB_FILLRECT
>>> -     select FB_CFB_COPYAREA
>>> -     select FB_CFB_IMAGEBLIT
>>>        select DRM_TTM
>>> -     select FB
>>>        select MAPPING_DIRTY_HELPERS
>>>        # Only needed for the transitional use of drm_crtc_init - can be removed
>>>        # again once vmwgfx sets up the primary plane itself.
>>> @@ -20,7 +15,7 @@ config DRM_VMWGFX
>>>          The compiled module will be called "vmwgfx.ko".
>>>
>>>    config DRM_VMWGFX_FBCON
>>> -     depends on DRM_VMWGFX && FB
>>> +     depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
>>>        bool "Enable framebuffer console under vmwgfx by default"
>>>        help
>>>           Choose this option if you are shipping a new vmwgfx
>>> diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
>>> index 8c02fa5852e7..9f5743013cbb 100644
>>> --- a/drivers/gpu/drm/vmwgfx/Makefile
>>> +++ b/drivers/gpu/drm/vmwgfx/Makefile
>>> @@ -1,6 +1,6 @@
>>>    # SPDX-License-Identifier: GPL-2.0
>>>    vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
>>> -         vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
>>> +         vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
>>>            vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
>>>            vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
>>>            vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
>>> @@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
>>>            vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
>>>            ttm_object.o ttm_lock.o ttm_memory.o
>>>
>>> +vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
>>>    vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
>>> +
>>>    obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
>>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> index 7e6518709e14..e7836da190c4 100644
>>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> @@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct vmw_private *dev_priv,
>>>     * Kernel framebuffer - vmwgfx_fb.c
>>>     */
>>>
>>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>>>    int vmw_fb_init(struct vmw_private *vmw_priv);
>>>    int vmw_fb_close(struct vmw_private *dev_priv);
>>>    int vmw_fb_off(struct vmw_private *vmw_priv);
>>>    int vmw_fb_on(struct vmw_private *vmw_priv);
>>> +#else
>>> +static inline int vmw_fb_init(struct vmw_private *vmw_priv)
>>> +{
>>> +     return 0;
>>> +}
>>> +static inline int vmw_fb_close(struct vmw_private *dev_priv)
>>> +{
>>> +     return 0;
>>> +}
>>> +static inline int vmw_fb_off(struct vmw_private *vmw_priv)
>>> +{
>>> +     return 0;
>>> +}
>>> +static inline int vmw_fb_on(struct vmw_private *vmw_priv)
>>> +{
>>> +     return 0;
>>> +}
>>> +#endif
>>>
>>>    /**
>>>     * Kernel modesetting - vmwgfx_kms.c
>>>
>>
>> This changes the behavior a bit, I guess DRM_VMWGFX (or at least DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve the old behavior, but that's largely due to the fact that given how those options were setup we never run without FB set. In general it should be ok and looks more reasonable than the current setup. I'll try it out on Monday just in case, but for now:
> 
> The issue is that select in Kconfig is pretty annoying (hard to
> disable, and it's not recursive), so there's a bit a push to retire
> it. Especially for user-facing config knobs like whether you want
> fbdev emulation or not. Hence the change.

Yes, I understand the change. It makes sense. I'm just saying that given how hard it was to even build vmwgfx without FB, it's likely it's never been used/tested in this configuration so it might be broken without FB config set. But like I said, it should be fine (it's basically only if we had some generic init code for the rest of the codebase tied to fb initialization).

z


From lkp at intel.com  Thu Apr 15 20:20:41 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 16 Apr 2021 03:20:41 +0800
Subject: [PATCH v2 7/7] net: dsa: enable selftest support for all
 switches by default
In-Reply-To: <20210415130738.19603-8-o.rempel@pengutronix.de>
References: <20210415130738.19603-8-o.rempel@pengutronix.de>
Message-ID: <202104160312.wFkIbAZ4-lkp@intel.com>

Hi Oleksij,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:    https://github.com/0day-ci/linux/commits/Oleksij-Rempel/provide-generic-net-selftest-support/20210415-211011
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 3a1aa533f7f676aad68f8dbbbba10b9502903770
config: microblaze-randconfig-r023-20210415 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/588de0d11c3a08c5d379652b1a8c69ecf99769f9
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Oleksij-Rempel/provide-generic-net-selftest-support/20210415-211011
        git checkout 588de0d11c3a08c5d379652b1a8c69ecf99769f9
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "net_selftest_get_count" [net/dsa/dsa_core.ko] undefined!
>> ERROR: modpost: "net_selftest" [net/dsa/dsa_core.ko] undefined!
>> ERROR: modpost: "net_selftest_get_strings" [net/dsa/dsa_core.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36029 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210416/22b7a88f/attachment-0001.gz>

From mathieu.poirier at linaro.org  Thu Apr 15 20:46:08 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 13:46:08 -0600
Subject: [PATCH 1/2] perf cs-etm: Refactor timestamp variable names
In-Reply-To: <20210414143919.12605-1-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
Message-ID: <20210415194608.GA937505@xps15>

On Wed, Apr 14, 2021 at 05:39:18PM +0300, James Clark wrote:
> Remove ambiguity in variable names relating to timestamps.
> A later commit will save the sample kernel timestamp in one
> of the etm structs, so name all elements appropriately to
> avoid confusion.
> 
> This is also removes some ambiguity arising from the fact
> that the --timestamp argument to perf record refers to
> sample kernel timestamps, and the /timestamp/ event modifier
> refers to etm timestamps, so the term is overloaded.
> 
> Signed-off-by: James Clark <james.clark at arm.com>
> ---
>  .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 ++++----
>  tools/perf/util/cs-etm.c                      | 42 +++++++++----------
>  tools/perf/util/cs-etm.h                      |  4 +-
>  3 files changed, 31 insertions(+), 33 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index 059bcec3f651..055cb93eca59 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -276,13 +276,13 @@ cs_etm_decoder__do_soft_timestamp(struct cs_etm_queue *etmq,
>  				  const uint8_t trace_chan_id)
>  {
>  	/* No timestamp packet has been received, nothing to do */
> -	if (!packet_queue->timestamp)
> +	if (!packet_queue->etm_timestamp)
>  		return OCSD_RESP_CONT;
>  
> -	packet_queue->timestamp = packet_queue->next_timestamp;
> +	packet_queue->etm_timestamp = packet_queue->next_etm_timestamp;
>  
>  	/* Estimate the timestamp for the next range packet */
> -	packet_queue->next_timestamp += packet_queue->instr_count;
> +	packet_queue->next_etm_timestamp += packet_queue->instr_count;
>  	packet_queue->instr_count = 0;
>  
>  	/* Tell the front end which traceid_queue needs attention */
> @@ -308,8 +308,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
>  	 * Function do_soft_timestamp() will report the value to the front end,
>  	 * hence asking the decoder to keep decoding rather than stopping.
>  	 */
> -	if (packet_queue->timestamp) {
> -		packet_queue->next_timestamp = elem->timestamp;
> +	if (packet_queue->etm_timestamp) {
> +		packet_queue->next_etm_timestamp = elem->timestamp;
>  		return OCSD_RESP_CONT;
>  	}
>  
> @@ -320,8 +320,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
>  	 * which instructions started by subtracting the number of instructions
>  	 * executed to the timestamp.
>  	 */
> -	packet_queue->timestamp = elem->timestamp - packet_queue->instr_count;
> -	packet_queue->next_timestamp = elem->timestamp;
> +	packet_queue->etm_timestamp = elem->timestamp - packet_queue->instr_count;
> +	packet_queue->next_etm_timestamp = elem->timestamp;
>  	packet_queue->instr_count = 0;
>  
>  	/* Tell the front end which traceid_queue needs attention */
> @@ -334,8 +334,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
>  static void
>  cs_etm_decoder__reset_timestamp(struct cs_etm_packet_queue *packet_queue)
>  {
> -	packet_queue->timestamp = 0;
> -	packet_queue->next_timestamp = 0;
> +	packet_queue->etm_timestamp = 0;
> +	packet_queue->next_etm_timestamp = 0;
>  	packet_queue->instr_count = 0;
>  }
>  
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 7e63e7dedc33..c25da2ffa8f3 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -38,8 +38,6 @@
>  #include <tools/libc_compat.h>
>  #include "util/synthetic-events.h"
>  
> -#define MAX_TIMESTAMP (~0ULL)
> -
>  struct cs_etm_auxtrace {
>  	struct auxtrace auxtrace;
>  	struct auxtrace_queues queues;
> @@ -86,7 +84,7 @@ struct cs_etm_queue {
>  	struct cs_etm_decoder *decoder;
>  	struct auxtrace_buffer *buffer;
>  	unsigned int queue_nr;
> -	u8 pending_timestamp;
> +	u8 pending_timestamp_chan_id;
>  	u64 offset;
>  	const unsigned char *buf;
>  	size_t buf_len, buf_used;
> @@ -208,7 +206,7 @@ void cs_etm__etmq_set_traceid_queue_timestamp(struct cs_etm_queue *etmq,
>  	 * be more than one channel per cs_etm_queue, we need to specify
>  	 * what traceID queue needs servicing.
>  	 */
> -	etmq->pending_timestamp = trace_chan_id;
> +	etmq->pending_timestamp_chan_id = trace_chan_id;
>  }
>  
>  static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
> @@ -216,22 +214,22 @@ static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
>  {
>  	struct cs_etm_packet_queue *packet_queue;
>  
> -	if (!etmq->pending_timestamp)
> +	if (!etmq->pending_timestamp_chan_id)
>  		return 0;
>  
>  	if (trace_chan_id)
> -		*trace_chan_id = etmq->pending_timestamp;
> +		*trace_chan_id = etmq->pending_timestamp_chan_id;
>  
>  	packet_queue = cs_etm__etmq_get_packet_queue(etmq,
> -						     etmq->pending_timestamp);
> +						     etmq->pending_timestamp_chan_id);
>  	if (!packet_queue)
>  		return 0;
>  
>  	/* Acknowledge pending status */
> -	etmq->pending_timestamp = 0;
> +	etmq->pending_timestamp_chan_id = 0;
>  
>  	/* See function cs_etm_decoder__do_{hard|soft}_timestamp() */
> -	return packet_queue->timestamp;
> +	return packet_queue->etm_timestamp;
>  }
>  
>  static void cs_etm__clear_packet_queue(struct cs_etm_packet_queue *queue)
> @@ -814,7 +812,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
>  	int ret = 0;
>  	unsigned int cs_queue_nr;
>  	u8 trace_chan_id;
> -	u64 timestamp;
> +	u64 etm_timestamp;
>  	struct cs_etm_queue *etmq = queue->priv;
>  
>  	if (list_empty(&queue->head) || etmq)
> @@ -854,7 +852,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
>  
>  		/*
>  		 * Run decoder on the trace block.  The decoder will stop when
> -		 * encountering a timestamp, a full packet queue or the end of
> +		 * encountering an ETM timestamp, a full packet queue or the end of
>  		 * trace for that block.
>  		 */
>  		ret = cs_etm__decode_data_block(etmq);
> @@ -865,10 +863,10 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
>  		 * Function cs_etm_decoder__do_{hard|soft}_timestamp() does all
>  		 * the timestamp calculation for us.
>  		 */
> -		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
> +		etm_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
>  
>  		/* We found a timestamp, no need to continue. */
> -		if (timestamp)
> +		if (etm_timestamp)
>  			break;
>  
>  		/*
> @@ -892,7 +890,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
>  	 * queue and will be processed in cs_etm__process_queues().
>  	 */
>  	cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
> -	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
> +	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, etm_timestamp);
>  out:
>  	return ret;
>  }
> @@ -2221,7 +2219,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
>  	int ret = 0;
>  	unsigned int cs_queue_nr, queue_nr;
>  	u8 trace_chan_id;
> -	u64 timestamp;
> +	u64 etm_timestamp;
>  	struct auxtrace_queue *queue;
>  	struct cs_etm_queue *etmq;
>  	struct cs_etm_traceid_queue *tidq;
> @@ -2283,9 +2281,9 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
>  		if (ret)
>  			goto out;
>  
> -		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
> +		etm_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
>  
> -		if (!timestamp) {
> +		if (!etm_timestamp) {
>  			/*
>  			 * Function cs_etm__decode_data_block() returns when
>  			 * there is no more traces to decode in the current
> @@ -2308,7 +2306,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
>  		 * this queue/traceID.
>  		 */
>  		cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
> -		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
> +		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, etm_timestamp);
>  	}
>  
>  out:
> @@ -2380,7 +2378,7 @@ static int cs_etm__process_event(struct perf_session *session,
>  				 struct perf_tool *tool)
>  {
>  	int err = 0;
> -	u64 timestamp;
> +	u64 sample_kernel_timestamp;
>  	struct cs_etm_auxtrace *etm = container_of(session->auxtrace,
>  						   struct cs_etm_auxtrace,
>  						   auxtrace);
> @@ -2394,11 +2392,11 @@ static int cs_etm__process_event(struct perf_session *session,
>  	}
>  
>  	if (sample->time && (sample->time != (u64) -1))
> -		timestamp = sample->time;
> +		sample_kernel_timestamp = sample->time;
>  	else
> -		timestamp = 0;
> +		sample_kernel_timestamp = 0;
>  
> -	if (timestamp || etm->timeless_decoding) {
> +	if (sample_kernel_timestamp || etm->timeless_decoding) {
>  		err = cs_etm__update_queues(etm);
>  		if (err)
>  			return err;
> diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
> index 36428918411e..b300f6fa19cc 100644
> --- a/tools/perf/util/cs-etm.h
> +++ b/tools/perf/util/cs-etm.h
> @@ -171,8 +171,8 @@ struct cs_etm_packet_queue {
>  	u32 head;
>  	u32 tail;
>  	u32 instr_count;
> -	u64 timestamp;
> -	u64 next_timestamp;
> +	u64 etm_timestamp;
> +	u64 next_etm_timestamp;

I find the "etm" part confusing since timestamps are generated by a specific CS
component, not the ETM itself.  As such I think it should be "cs_timestamp" and
"next_cs_timestamp".  But this is just a naming convention and won't press the
case further if you feel strongly about it.

Otherwise I think this renaming exercise is worth it.  

With or without the above:

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  	struct cs_etm_packet packet_buffer[CS_ETM_PACKET_MAX_BUFFER];
>  };
>  
> -- 
> 2.28.0
> 


From mathieu.poirier at linaro.org  Thu Apr 15 20:54:16 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 13:54:16 -0600
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210414143919.12605-2-james.clark@arm.com>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
Message-ID: <20210415195416.GB937505@xps15>

On Wed, Apr 14, 2021 at 05:39:19PM +0300, James Clark wrote:
> The following attribute is set when synthesising samples in
> timed decoding mode:
> 
>     attr.sample_type |= PERF_SAMPLE_TIME;
> 
> This results in new samples that appear to have timestamps but
> because we don't assign any timestamps to the samples, when the
> resulting inject file is opened again, the synthesised samples
> will be on the wrong side of the MMAP or COMM events.
>

I understand the problem.  Once again an issue caused by CS and the kernel
having a different view of time. 

> For example this results in the samples being associated with
> the perf binary, rather than the target of the record:
> 
>     perf record -e cs_etm/@tmc_etr0/u top
>     perf inject -i perf.data -o perf.inject --itrace=i100il
>     perf report -i perf.inject
> 
> Where 'Command' == perf should show as 'top':
> 
>     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>     # ........  .......  ....................  ......................  ......................  ..................
>     #
>         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
> 
> If the perf.data file is opened directly with perf, without the
> inject step, then this already works correctly because the
> events are synthesised after the COMM and MMAP events and
> no second sorting happens. Re-sorting only happens when opening
> the perf.inject file for the second time so timestamps are
> needed.
> 
> Using the timestamp from the AUX record mirrors the current
> behaviour when opening directly with perf, because the events
> are generated on the call to cs_etm__process_queues().
> 
> Signed-off-by: James Clark <james.clark at arm.com>
> Co-developed-by: Al Grant <al.grant at arm.com>
> Signed-off-by: Al Grant <al.grant at arm.com>

Suzuki is correct, your name has to appear after Al's.

> ---
>  tools/perf/util/cs-etm.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index c25da2ffa8f3..d0fa9dce47f1 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>  	u8 sample_instructions;
>  
>  	int num_cpu;
> +	u64 latest_kernel_timestamp;
>  	u32 auxtrace_type;
>  	u64 branches_sample_type;
>  	u64 branches_id;
> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = addr;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>  	event->sample.header.size = sizeof(struct perf_event_header);
>  
> +	if (!etm->timeless_decoding)
> +		sample.time = etm->latest_kernel_timestamp;
>  	sample.ip = ip;
>  	sample.pid = tidq->pid;
>  	sample.tid = tidq->tid;
> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>  		return cs_etm__process_switch_cpu_wide(etm, event);
>  
> -	if (!etm->timeless_decoding &&
> -	    event->header.type == PERF_RECORD_AUX)
> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;

It will be fun to fix this when 8.4 comes out but for now it's the best we've
got.

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  		return cs_etm__process_queues(etm);
> +	}
>  
>  	return 0;
>  }
> -- 
> 2.28.0
> 


From f.fainelli at gmail.com  Thu Apr 15 20:58:48 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 15 Apr 2021 12:58:48 -0700
Subject: [PATCH v2 2/7] net: phy: micrel: KSZ8081 & KSZ9031: add loopback
 support
In-Reply-To: <20210415130738.19603-3-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
 <20210415130738.19603-3-o.rempel@pengutronix.de>
Message-ID: <2bf45888-98e5-7c3c-1732-05d685d59d54@gmail.com>



On 4/15/2021 6:07 AM, Oleksij Rempel wrote:
> PHY loopback is needed for the ethernet controller self test support.
> This PHY was tested with the generic net sefltest in combination with
> FEC ethernet controller and SJA1105 switch.
> 
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> ---
>  drivers/net/phy/micrel.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index a14a00328fa3..26066b1e02e5 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -1311,6 +1311,7 @@ static struct phy_driver ksphy_driver[] = {
>  	.get_stats	= kszphy_get_stats,
>  	.suspend	= kszphy_suspend,
>  	.resume		= kszphy_resume,
> +	.set_loopback	= genphy_loopback,

The generic loopback is really generic and is defined by the 802.3
standard, we should just mandate that drivers implement a custom
loopback if the generic one cannot work. I would change the PHY library
to do something like this:

if (phydev->drv->set_loopback)
	ret = phydev->drv->set_loopback(phydev, ...)
else
	ret = genphy_loopback(phydev, ...)

This would enable many more drivers than that we currently have today.

>  }, {
>  	.phy_id		= PHY_ID_KSZ8061,
>  	.name		= "Micrel KSZ8061",
> @@ -1356,6 +1357,7 @@ static struct phy_driver ksphy_driver[] = {
>  	.get_stats	= kszphy_get_stats,
>  	.suspend	= genphy_suspend,
>  	.resume		= kszphy_resume,
> +	.set_loopback	= genphy_loopback,
>  }, {
>  	.phy_id		= PHY_ID_LAN8814,
>  	.phy_id_mask	= MICREL_PHY_ID_MASK,
> 

-- 
Florian


From f.fainelli at gmail.com  Thu Apr 15 21:06:45 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 15 Apr 2021 13:06:45 -0700
Subject: [PATCH v2 4/7] net: add generic selftest support
In-Reply-To: <20210415130738.19603-5-o.rempel@pengutronix.de>
References: <20210415130738.19603-1-o.rempel@pengutronix.de>
 <20210415130738.19603-5-o.rempel@pengutronix.de>
Message-ID: <347139c5-d7be-04c0-8857-3bb4891522cf@gmail.com>



On 4/15/2021 6:07 AM, Oleksij Rempel wrote:
> Port some parts of the stmmac selftest and reuse it as basic generic selftest
> library. This patch was tested with following combinations:
> - iMX6DL FEC -> AT8035
> - iMX6DL FEC -> SJA1105Q switch -> KSZ8081
> - iMX6DL FEC -> SJA1105Q switch -> KSZ9031
> - AR9331 ag71xx -> AR9331 PHY
> - AR9331 ag71xx -> AR9331 switch -> AR9331 PHY
> 
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> ---

[snip]

> +
> +struct net_packet_attrs {
> +	unsigned char *src;
> +	unsigned char *dst;
> +	u32 ip_src;
> +	u32 ip_dst;
> +	int tcp;

This can be an u8 and named proto maybe?

> +	int sport;
> +	int dport;

These two can be u16

> +	int timeout;
> +	int size;
> +	int max_size;
> +	u8 id;
> +	u16 queue_mapping;
> +};

[snip]

> +static const struct net_test {
> +	char name[ETH_GSTRING_LEN];
> +	int (*fn)(struct net_device *ndev);
> +} net_selftests[] = {
> +	{
> +		.name = "PHY Loopback, UDP          ",

This should be "PHY internal loopback, UDP"

> +		.fn = net_test_phy_loopback_udp,
> +	}, {
> +		.name = "PHY Loopback, TCP          ",
> +		.fn = net_test_phy_loopback_tcp,

and "PHY internal loopback, TCP"

to make it clear that the loopback is internal, as opposed to external.
Or if you prefer to use the line-side or MAC-side that works too.

> +	},
> +};
> +
> +void net_selftest(struct net_device *ndev, struct ethtool_test *etest, u64 *buf)
> +{
> +	int count = net_selftest_get_count();
> +	int i;
> +
> +	memset(buf, 0, sizeof(*buf) * count);
> +	net_test_next_id = 0;
> +
> +	if (etest->flags != ETH_TEST_FL_OFFLINE) {
> +		netdev_err(ndev, "Only offline tests are supported\n");
> +		etest->flags |= ETH_TEST_FL_FAILED;
> +		return;
> +	} else if (!netif_carrier_ok(ndev)) {
> +		netdev_err(ndev, "You need valid Link to execute tests\n");
> +		etest->flags |= ETH_TEST_FL_FAILED;
> +		return;
> +	}
> +
> +	if (!ndev->phydev)
> +		return;

Can you move that as the first test and return -EOPNOTSUPP instead?

> +
> +	/* PHY loopback tests should be combined to avoid delays on each PHY
> +	 * reconfiguration
> +	 */
> +	phy_loopback(ndev->phydev, true);
> +
> +	/* give PHYs some time to establish the loopback link */
> +	msleep(100);

Cannot you poll for LSTATUS instead?

> +
> +	for (i = 0; i < count; i++) {
> +		buf[i] = net_selftests[i].fn(ndev);
> +		if (buf[i] && (buf[i] != -EOPNOTSUPP))
> +			etest->flags |= ETH_TEST_FL_FAILED;
> +	}
> +
> +	phy_loopback(ndev->phydev, false);

Can you propagate the return value here?

As spotted by the test robot please export all of these symbols as
EXPORT_SYMBOL_GPL().
-- 
Florian


From dietmar.eggemann at arm.com  Thu Apr 15 21:10:47 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Thu, 15 Apr 2021 22:10:47 +0200
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <8735vrmnc7.mognet@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com>
Message-ID: <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>

On 15/04/2021 20:09, Valentin Schneider wrote:
> On 14/04/21 20:23, Ruifeng Zhang wrote:
>> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
>>
>> In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
>> version, one of them is the kernel running on EL1 using aarch32.
>>                 user(EL0)             kernel(EL1)
>> sc9863a_go      aarch32               aarch32
>> sc9863a         aarch64               aarch64
>>
>> When kernel runs on EL1 using aarch32, the topology will parse wrong.
>> For example,
>> The MPIDR has been written to the chip register in armv8.2 format.
>> For example,
>> core0: 0000000080000000
>> core1: 0000000080000100
>> core2: 0000000080000200
>> ...
>>
>> It will parse to:
>> |       | aff2 | packageid | coreid |
>> |-------+------+-----------+--------|
>> | Core0 |    0 |         0 |    0   |
>> | Core1 |    0 |         1 |    0   |
>> | Core2 |    0 |         2 |    0   |
>> |  ...  |      |           |        |
>>
>> The wrong topology is that all of the coreid are 0 and unexpected
>> packageid.
>>
>> The reason is the MPIDR format is different between armv7 and armv8.2.
>> armv7 (A7) mpidr is:
>> [11:8]      [7:2]       [1:0]
>> cluster     reserved    cpu
>> The cortex-a7 spec DDI0464F 4.3.5
>> https://developer.arm.com/documentation/ddi0464/f/?lang=en
>>
>> armv8.2 (A55) mpidr is:
>> [23:16]     [15:8]      [7:0]
>> cluster     cpu         thread
>>
> 
> What I had understood from our conversation was that there *isn't* a format
> difference (at least for the bottom 32 bits) - arm64/kernel/topopology.c
> would parse it the same, except that MPIDR parsing has been deprecated for
> arm64.
> 
> The problem is that those MPIDR values don't match the actual topology. If
> they had the MT bit set, i.e.
> 
>   core0: 0000000081000000
>   core1: 0000000081000100
>   core2: 0000000081000200
> 
> then it would be parsed as:
> 
>   |       | package_id | core_id | thread_id |
>   |-------+------------+---------+-----------|
>   | Core0 |          0 |       0 |         0 |
>   | Core1 |          0 |       1 |         0 |
>   | Core2 |          0 |       2 |         0 |
> 
> which would make more sense (wrt the actual, physical topology).

... and this would be in sync with
https://developer.arm.com/documentation/100442/0200/register-descriptions/aarch32-system-registers/mpidr--multiprocessor-affinity-register

MT, [24]

   0b1 ...

There is no 0b0 for MT.



From mathieu.poirier at linaro.org  Thu Apr 15 21:24:03 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 14:24:03 -0600
Subject: [PATCH 0/1] coresight: Fix for v5.12-rc7 
Message-ID: <20210415202404.945368-1-mathieu.poirier@linaro.org>

Hi Greg,

Please consider this patch as a fix for v5.12-rc7.  Applies cleanly
to your char-misc-linus branch (e49d033bddf5).

Thanks,
Mathieu

Mike Leach (1):
  coresight: etm-perf: Fix define build issue when built as module

 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.25.1



From mathieu.poirier at linaro.org  Thu Apr 15 21:24:04 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 14:24:04 -0600
Subject: [PATCH 1/1] coresight: etm-perf: Fix define build issue when built as
 module
In-Reply-To: <20210415202404.945368-1-mathieu.poirier@linaro.org>
References: <20210415202404.945368-1-mathieu.poirier@linaro.org>
Message-ID: <20210415202404.945368-2-mathieu.poirier@linaro.org>

From: Mike Leach <mike.leach at linaro.org>

CONFIG_CORESIGHT_SOURCE_ETM4X is undefined when built as module,
CONFIG_CORESIGHT_SOURCE_ETM4X_MODULE is defined instead.

Therefore code in format_attr_contextid_show() not correctly complied
when coresight built as module.

Use IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X) to correct this.

Fixes: 88f11864cf1d ("coresight: etm-perf: Support PID tracing for kernel at EL2")
Signed-off-by: Mike Leach <mike.leach at linaro.org>
Reviewed-by: Leo Yan <leo.yan at linaro.org>
Link: https://lore.kernel.org/r/20210414194808.22872-1-mike.leach at linaro.org
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 0f603b4094f2..a706ba11b93e 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -52,7 +52,7 @@ static ssize_t format_attr_contextid_show(struct device *dev,
 {
 	int pid_fmt = ETM_OPT_CTXTID;
 
-#if defined(CONFIG_CORESIGHT_SOURCE_ETM4X)
+#if IS_ENABLED(CONFIG_CORESIGHT_SOURCE_ETM4X)
 	pid_fmt = is_kernel_in_hyp_mode() ? ETM_OPT_CTXTID2 : ETM_OPT_CTXTID;
 #endif
 	return sprintf(page, "config:%d\n", pid_fmt);
-- 
2.25.1



From robh at kernel.org  Thu Apr 15 21:37:20 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 15:37:20 -0500
Subject: [PATCH v3 1/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <1618459535-8141-2-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-2-git-send-email-dillon.minfei@gmail.com>
Message-ID: <20210415203720.GA1841552@robh.at.kernel.org>

On Thu, 15 Apr 2021 12:05:32 +0800, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> Add vendor prefix for DaSheng, Inc.
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
> v3:
> - move v2 patch 4 to v3 patch 1
> - add 'Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>'
> 
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From mathieu.poirier at linaro.org  Thu Apr 15 21:37:28 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 14:37:28 -0600
Subject: [PATCH 0/7] Split Coresight decode by aux records
In-Reply-To: <20210212144513.31765-1-james.clark@arm.com>
References: <20210212144513.31765-1-james.clark@arm.com>
Message-ID: <20210415203728.GD937505@xps15>

Hi James,

On Fri, Feb 12, 2021 at 04:45:06PM +0200, James Clark wrote:
> Hi All,
> 
> Since my previous RFC, I've fixed --per-thread mode and solved
> most of the open questions. I've also changed --dump-raw-trace
> to use the same code path so it's also working now.
> 
> I think the only open questions are:
>   * General approach
>   * If aux records need to be saved, or if they can be pulled
>     from elsewhere.
> 
> I've also tested perf inject which is now working with troublesome
> files.
>

This patchset is now at the top of the coresight review list.  I suggest you
rebase this on top of your two timestamp related patches and send another
revision.
 
> Thanks
> James
> 
> James Clark (7):
>   perf cs-etm: Split up etm queue setup function
>   perf cs-etm: Only search timestamp in current sample's queue.
>   perf cs-etm: Save aux records in each etm queue
>   perf cs-etm: don't process queues until cs_etm__flush_events
>   perf cs-etm: split decode by aux records.
>   perf cs-etm: Use existing decode code path for --dump-raw-trace
>   perf cs-etm: Suppress printing when resetting decoder
> 
>  .../perf/util/cs-etm-decoder/cs-etm-decoder.c |  10 +-
>  tools/perf/util/cs-etm.c                      | 300 ++++++++++--------
>  2 files changed, 168 insertions(+), 142 deletions(-)
> 
> -- 
> 2.28.0
> 


From robh at kernel.org  Thu Apr 15 21:37:41 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 15:37:41 -0500
Subject: [PATCH v3 2/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX
 SBC
In-Reply-To: <1618459535-8141-3-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-3-git-send-email-dillon.minfei@gmail.com>
Message-ID: <20210415203741.GA1842113@robh.at.kernel.org>

On Thu, 15 Apr 2021 12:05:33 +0800, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
> 
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
> v3: move 'ds,imx6q-sbc' after 'dmo,imx6q-edmqmx6' to follow the alphabetical
> order.
> 
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr 15 21:59:07 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 15:59:07 -0500
Subject: [PATCH v3 16/24] dt-bindings: atmel-sysreg: add bindings for
 sama7g5
In-Reply-To: <20210415105010.569620-17-claudiu.beznea@microchip.com>
References: <20210415105010.569620-1-claudiu.beznea@microchip.com>
 <20210415105010.569620-17-claudiu.beznea@microchip.com>
Message-ID: <20210415205907.GA1871251@robh.at.kernel.org>

On Thu, 15 Apr 2021 13:50:02 +0300, Claudiu Beznea wrote:
> Add RAM controller and RAM PHY controller DT bindings.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea at microchip.com>
> ---
>  .../devicetree/bindings/arm/atmel-sysregs.txt      | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr 15 22:11:17 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:11:17 -0500
Subject: [PATCH v2 1/2] dt-bindings: phy: add vbus-supply optional
 property to phy-stm32-usbphyc
In-Reply-To: <20210413143141.12919-2-amelie.delaunay@foss.st.com>
References: <20210413143141.12919-1-amelie.delaunay@foss.st.com>
 <20210413143141.12919-2-amelie.delaunay@foss.st.com>
Message-ID: <20210415211117.GA1889278@robh.at.kernel.org>

On Tue, 13 Apr 2021 16:31:40 +0200, Amelie Delaunay wrote:
> This patch adds vbus-supply optional property to phy sub-nodes using
> connector node.
> A regulator for USB VBUS may be needed for host mode.
> 
> Signed-off-by: Amelie Delaunay <amelie.delaunay at foss.st.com>
> ---
> Changes in v2:
> - add connector vbus-supply property as suggested by Rob
> ---
>  .../devicetree/bindings/phy/phy-stm32-usbphyc.yaml    | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From David.Laight at ACULAB.COM  Thu Apr 15 22:11:56 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 15 Apr 2021 21:11:56 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210415182155.GD2531743@casper.infradead.org>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210415182155.GD2531743@casper.infradead.org>
Message-ID: <5179a01a462f43d6951a65de2a299070@AcuMS.aculab.com>

From: Matthew Wilcox <willy at infradead.org>
> Sent: 15 April 2021 19:22
> 
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > +static inline
> > +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> > +{
> > +	/* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> > +	 * page.  The page->dma_addr share area with page->compound_head which
> > +	 * use bit zero to mark compound pages. This is okay, as DMA-addr are
> > +	 * aligned pointers which have bit zero cleared.
> > +	 *
> > +	 * In the 32-bit case, page->compound_head is 32-bit.  Thus, when
> > +	 * dma_addr_t is 64-bit it will be located in top 32-bit.  Solve by
> > +	 * swapping dma_addr 32-bit segments.
> > +	 */
> > +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> 
> #if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) && defined(__BIG_ENDIAN)
> otherwise you'll create the problem on ARM that you're avoiding on PPC ...
> 
> I think you want to delete the word '_read' from this function name because
> you're using it for both read and write.

I think I'd use explicit dma_addr_hi and dma_addr_lo and
separate read/write functions just to make absolutely sure
nothing picks up the swapped value.

Isn't it possible to move the field down one long?
This might require an explicit zero - but this is not a common
code path - the extra write will be noise.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From robh at kernel.org  Thu Apr 15 22:12:44 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:12:44 -0500
Subject: [PATCH v2 1/4] dt-bindings: serial: add RX and TX FIFO properties
In-Reply-To: <20210413174015.23011-2-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
 <20210413174015.23011-2-erwan.leray@foss.st.com>
Message-ID: <20210415211244.GA1891289@robh.at.kernel.org>

On Tue, 13 Apr 2021 19:40:12 +0200, Erwan Le Ray wrote:
> Add two optional DT properties to configure RX and TX FIFO thresholds:
> - rx-threshold
> - tx-threshold
> 
> Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr 15 22:13:00 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:13:00 -0500
Subject: [PATCH v2 2/4] dt-bindings: serial: stm32: override FIFO
 threshold properties
In-Reply-To: <20210413174015.23011-3-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
 <20210413174015.23011-3-erwan.leray@foss.st.com>
Message-ID: <20210415211300.GA1891734@robh.at.kernel.org>

On Tue, 13 Apr 2021 19:40:13 +0200, Erwan Le Ray wrote:
> Override rx-threshold and tx-threshold properties:
> - extend description
> - provide default and expected values
> 
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>
> Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>
> 
> Changes in v2:
> Change added properties naming and factorize it in serial.yaml as proposed
> by Rob Herring.
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr 15 22:13:12 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:13:12 -0500
Subject: [PATCH v2 3/4] dt-bindings: serial: 8250: update TX FIFO trigger
 level
In-Reply-To: <20210413174015.23011-4-erwan.leray@foss.st.com>
References: <20210413174015.23011-1-erwan.leray@foss.st.com>
 <20210413174015.23011-4-erwan.leray@foss.st.com>
Message-ID: <20210415211312.GA1892117@robh.at.kernel.org>

On Tue, 13 Apr 2021 19:40:14 +0200, Erwan Le Ray wrote:
> Remove data type from tx-threshold trigger level as defined now as a
> serial generic property.
> 
> Signed-off-by: Erwan Le Ray <erwan.leray at foss.st.com>
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Apr 15 22:17:31 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:17:31 -0500
Subject: [PATCH V2] dt-bindings: mailbox: ti, secure-proxy: Convert to yaml
In-Reply-To: <20210413224535.30910-1-nm@ti.com>
References: <20210413224535.30910-1-nm@ti.com>
Message-ID: <20210415211731.GA1892348@robh.at.kernel.org>

On Tue, Apr 13, 2021 at 05:45:35PM -0500, Nishanth Menon wrote:
> Convert the ti,secure-proxy to yaml for better checks and documentation.
> Differences being mostly in the examples:
> - I've dropped the example usage of mailbox client, it is better done in
>   tisci node definition
> - Switched reg usage for address-cells and size-cells 1 - aligned with
>   schema checks as well
> - included header in example for buildable example
> 
> While at this, lets make sure to support upto 100 rx threads even though
> typically upto 1 threads is practically in use.
> 
> NOTE: The following checkpatch warning is generated since we do include the header
> in the example, but this is a false positive warning.
>   WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
> Changes since V1: (Thanks Suman for some offline comments)
> - Strengthened interrupt-names property to be on rails
> - More documentation (we dont want an information loss between txt and
>   yaml)
> - Added a max interrupts of 100, which is a rather conservative limit on
>   current devices, but who knows..
> - Commit message updates
> - compatible is a simpler const.
> - interrupt-names are required property - makes no sense in not knowing
>   which interrupts belong to which thread irqs.
> 
> V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1-nm at ti.com/
> 
>  .../bindings/mailbox/ti,secure-proxy.txt      | 50 ------------
>  .../bindings/mailbox/ti,secure-proxy.yaml     | 79 +++++++++++++++++++
>  2 files changed, 79 insertions(+), 50 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
> deleted file mode 100644
> index 6c9c7daf0f5c..000000000000
> --- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
> +++ /dev/null
> @@ -1,50 +0,0 @@
> -Texas Instruments' Secure Proxy
> -========================================
> -
> -The Texas Instruments' secure proxy is a mailbox controller that has
> -configurable queues selectable at SoC(System on Chip) integration. The
> -Message manager is broken up into different address regions that are
> -called "threads" or "proxies" - each instance is unidirectional and is
> -instantiated at SoC integration level by system controller to indicate
> -receive or transmit path.
> -
> -Message Manager Device Node:
> -===========================
> -Required properties:
> ---------------------
> -- compatible:		Shall be "ti,am654-secure-proxy"
> -- reg-names 		target_data - Map the proxy data region
> -			rt - Map the realtime status region
> -			scfg - Map the configuration region
> -- reg:			Contains the register map per reg-names.
> -- #mbox-cells		Shall be 1 and shall refer to the transfer path
> -			called thread.
> -- interrupt-names:	Contains interrupt names matching the rx transfer path
> -			for a given SoC. Receive interrupts shall be of the
> -			format: "rx_<PID>".
> -- interrupts:		Contains the interrupt information corresponding to
> -			interrupt-names property.
> -
> -Example(AM654):
> -------------
> -
> -	secure_proxy: mailbox at 32c00000 {
> -		compatible = "ti,am654-secure-proxy";
> -		#mbox-cells = <1>;
> -		reg-names = "target_data", "rt", "scfg";
> -		reg = <0x0 0x32c00000 0x0 0x100000>,
> -		      <0x0 0x32400000 0x0 0x100000>,
> -		      <0x0 0x32800000 0x0 0x100000>;
> -		interrupt-names = "rx_011";
> -		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> -	};
> -
> -	dmsc: dmsc {
> -		[...]
> -		mbox-names = "rx", "tx";
> -		# RX Thread ID is 11
> -		# TX Thread ID is 13
> -		mboxes= <&secure_proxy 11>,
> -			<&secure_proxy 13>;
> -		[...]
> -	};
> diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> new file mode 100644
> index 000000000000..08a4837fdfcc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments' Secure Proxy
> +
> +maintainers:
> +  - Nishanth Menon <nm at ti.com>
> +
> +description: |
> +  The Texas Instruments' secure proxy is a mailbox controller that has
> +  configurable queues selectable at SoC(System on Chip) integration. The
> +  Message manager is broken up into different address regions that are
> +  called "threads" or "proxies" - each instance is unidirectional and is
> +  instantiated at SoC integration level by system controller to indicate
> +  receive or transmit path.
> +
> +properties:
> +  $nodename:
> +    pattern: "^mailbox@[0-9a-f]+$"
> +
> +  compatible:
> +    const: ti,am654-secure-proxy
> +
> +  "#mbox-cells":
> +    const: 1
> +    description:
> +      Contains the secure proxy thread ID used for the specific transfer path.
> +
> +  reg-names:
> +    items:
> +      - const: target_data
> +      - const: rt
> +      - const: scfg
> +
> +  reg:
> +    minItems: 3
> +
> +  interrupt-names:
> +    minItems: 1
> +    maxItems: 100
> +    items:
> +      - pattern: "^rx_[0-9]{3}$"

Need to drop the '-' to make this apply to all entries. Otherwise, it's 
just the first one.

> +    description:
> +      Contains the interrupt name information for the Rx interrupt path for
> +      secure proxy thread in the form 'rx_<PID>'.
> +
> +  interrupts:
> +    minItems: 1
> +    maxItems: 100
> +    description:
> +      Contains the interrupt information for the Rx interrupt path for secure
> +      proxy.
> +
> +required:
> +  - compatible
> +  - reg-names
> +  - reg
> +  - interrupt-names
> +  - interrupts
> +  - "#mbox-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    secure_proxy: mailbox at 32c00000 {
> +          compatible = "ti,am654-secure-proxy";
> +          #mbox-cells = <1>;
> +          reg-names = "target_data", "rt", "scfg";
> +          reg = <0x32c00000 0x100000>,
> +                <0x32400000 0x100000>,
> +                <0x32800000 0x100000>;
> +          interrupt-names = "rx_011";
> +          interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> +    };
> -- 
> 2.31.0
> 


From robh at kernel.org  Thu Apr 15 22:20:08 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:20:08 -0500
Subject: =?utf-8?B?W+KAnVBBVENI4oCdIHYyIDMvNV0g?=
 =?utf-8?Q?dt-bindings=3A_pci=3A_add_system_controlle?= =?utf-8?Q?r?= and MAC
 reset bit to Armada 7K/8K controller bindings
In-Reply-To: <1618406454-7953-4-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
 <1618406454-7953-4-git-send-email-bpeled@marvell.com>
Message-ID: <20210415212008.GA1899572@robh.at.kernel.org>

On Wed, Apr 14, 2021 at 04:20:52PM +0300, bpeled at marvell.com wrote:
> From: Ben Peled <bpeled at marvell.com>
> 
> Adding optional system-controller and mac-reset-bit-mask
> needed for linkdown procedure.

Same comment as v1.

BTW, it's PATCH not "PATCH". Don't do anything and git will do the right 
thing here.

> 
> Signed-off-by: Ben Peled <bpeled at marvell.com>
> ---
>  Documentation/devicetree/bindings/pci/pci-armada8k.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> index 7a813d0..2696e79 100644
> --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> @@ -24,6 +24,10 @@ Optional properties:
>  - phy-names: names of the PHYs corresponding to the number of lanes.
>  	Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
>  	2 PHYs.
> +- marvell,system-controller: address of system controller needed
> +	in order to reset MAC used by link-down handle
> +- marvell,mac-reset-bit-mask: MAC reset bit of system controller
> +	needed in order to reset MAC used by link-down handle
>  
>  Example:
>  
> @@ -45,4 +49,6 @@ Example:
>  		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
>  		num-lanes = <1>;
>  		clocks = <&cpm_syscon0 1 13>;
> +		marvell,system-controller = <&CP11X_LABEL(syscon0)>;
> +		marvell,mac-reset-bit-mask = <CP11X_PCIEx_MAC_RESET_BIT_MASK(1)>;
>  	};
> -- 
> 2.7.4
> 


From robh at kernel.org  Thu Apr 15 22:24:50 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:24:50 -0500
Subject: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document bindings
 for APU
In-Reply-To: <1618209895.25062.11.camel@mtksdccf07>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>
 <20210409182538.GA3913794@robh.at.kernel.org>
 <1618209895.25062.11.camel@mtksdccf07>
Message-ID: <CAL_JsqLKaYY=NHm1hD=YaQgvDOBTtraoUqcycA7tu7n-f2GVDw@mail.gmail.com>

On Mon, Apr 12, 2021 at 1:45 AM Flora Fu <flora.fu at mediatek.com> wrote:
>
> On Fri, 2021-04-09 at 13:25 -0500, Rob Herring wrote:
> > On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> > > Document the apusys bindings.
> > >
> > > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > > ---
> > >  .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
> > >  1 file changed, 56 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > new file mode 100644
> > > index 000000000000..dc04a46f1bad
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > @@ -0,0 +1,56 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrAYYvZWcw$
> > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrARlhCQ0w$
> > > +
> > > +title: MediaTek APUSYS Controller
> > > +
> > > +maintainers:
> > > +  - Flora Fu <flora.fu at mediatek.com>
> > > +
> > > +description:
> > > +  The Mediatek apusys controller provides functional configurations and clocks
> > > +  to the system.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    items:
> > > +      - enum:
> > > +          - mediatek,mt8192-apu_mbox
> > > +          - mediatek,mt8192-apu_conn
> > > +          - mediatek,mt8192-apu_vcore
> >
> > s/_/-/
> >
>
> OK. I will update expression strings in the next version.
>
> > > +      - const: syscon
> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  '#clock-cells':
> > > +    const: 1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    apu_mbox: apu_mbox at 19000000 {
> >
> > mailbox at ...? Is this a mailbox provider?
> >
>
> Yes, the apu_mbox is the for setup mailbox in the APU hardware.

Then you need #mbox-cells here.

And in that case, what makes it a syscon?

>
> > > +        compatible = "mediatek,mt8192-apu_mbox", "syscon";
> > > +        reg = <0x19000000 0x1000>;
> > > +    };


From mathieu.poirier at linaro.org  Thu Apr 15 22:27:54 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 15 Apr 2021 15:27:54 -0600
Subject: [PATCH v7 00/10] CoreSight configuration management; ETM strobing
In-Reply-To: <20210414191903.18349-1-mike.leach@linaro.org>
References: <20210414191903.18349-1-mike.leach@linaro.org>
Message-ID: <20210415212754.GF937505@xps15>

[...]

> 
> Mike Leach (10):
>   coresight: syscfg: Initial coresight system configuration
>   coresight: syscfg: Add registration and feature loading for cs devices
>   coresight: config: Add configuration and feature generic functions
>   coresight: etm-perf: update to handle configuration selection
>   coresight: syscfg: Add API to activate and enable configurations
>   coresight: etm-perf: Update to activate selected configuration
>   coresight: etm4x: Add complex configuration handlers to etmv4
>   coresight: config: Add preloaded configurations
>   coresight: syscfg: Add initial configfs support
>   Documentation: coresight: Add documentation for CoreSight config
> 
>  .../trace/coresight/coresight-config.rst      | 244 ++++++
>  Documentation/trace/coresight/coresight.rst   |  16 +
>  drivers/hwtracing/coresight/Makefile          |   7 +-
>  .../hwtracing/coresight/coresight-cfg-afdo.c  | 153 ++++
>  .../coresight/coresight-cfg-preload.c         |  31 +
>  .../coresight/coresight-cfg-preload.h         |  13 +
>  .../hwtracing/coresight/coresight-config.c    | 275 ++++++
>  .../hwtracing/coresight/coresight-config.h    | 253 ++++++
>  drivers/hwtracing/coresight/coresight-core.c  |  12 +-
>  .../hwtracing/coresight/coresight-etm-perf.c  | 150 +++-
>  .../hwtracing/coresight/coresight-etm-perf.h  |  12 +-
>  .../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++
>  .../hwtracing/coresight/coresight-etm4x-cfg.h |  30 +
>  .../coresight/coresight-etm4x-core.c          |  38 +-
>  .../coresight/coresight-etm4x-sysfs.c         |   3 +
>  .../coresight/coresight-syscfg-configfs.c     | 396 +++++++++
>  .../coresight/coresight-syscfg-configfs.h     |  45 +
>  .../hwtracing/coresight/coresight-syscfg.c    | 804 ++++++++++++++++++
>  .../hwtracing/coresight/coresight-syscfg.h    |  81 ++
>  include/linux/coresight.h                     |   7 +
>  20 files changed, 2716 insertions(+), 36 deletions(-)
>  create mode 100644 Documentation/trace/coresight/coresight-config.rst
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h
>  create mode 100644 drivers/hwtracing/coresight/coresight-config.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-config.h
>  create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h
> 

I have added this set to next-ETE-TRBE where it will be rebased to v5.13-rc1
when it comes out.

Thanks,
Mathieu

> -- 
> 2.17.1
> 


From robh at kernel.org  Thu Apr 15 22:35:02 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 15 Apr 2021 16:35:02 -0500
Subject: [PATCH V2] dt-bindings: mailbox: ti, message-manager: Convert to
 json schema
In-Reply-To: <20210415141909.3013-1-nm@ti.com>
References: <20210415141909.3013-1-nm@ti.com>
Message-ID: <20210415213502.GA1921174@robh.at.kernel.org>

On Thu, 15 Apr 2021 09:19:09 -0500, Nishanth Menon wrote:
> Convert the ti,message-manager to yaml for better checks and documentation.
> Differences being mostly in the examples:
> - I've dropped the example usage of mailbox client, it is better done in
>   tisci node definition
> - included header in example for buildable example
> 
> NOTE: The following checkpatch warning is generated since we do include
> the header in the example, but this is a false positive warning.
>   WARNING: DT binding docs and includes should be a separate patch. See:
>   Documentation/devicetree/bindings/submitting-patches.rst
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
> Changes since v1:
>  - Fixed title in yaml (not driver)
>  - Commit message update to fix up a copy paste error (not secure-proxy).
>  - Subject line rewording to indicate json schema rather than yaml -
>    more inline with patches elsewhere.
> 
> V1: https://lore.kernel.org/linux-arm-kernel/20210414002721.23638-1-nm at ti.com/
>  .../bindings/mailbox/ti,message-manager.txt   | 50 -------------
>  .../bindings/mailbox/ti,message-manager.yaml  | 75 +++++++++++++++++++
>  2 files changed, 75 insertions(+), 50 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Thu Apr 15 22:37:22 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 16 Apr 2021 05:37:22 +0800
Subject: [PATCH v2 5/7] net: fec: make use of generic NET_SELFTESTS library
In-Reply-To: <20210415130738.19603-6-o.rempel@pengutronix.de>
References: <20210415130738.19603-6-o.rempel@pengutronix.de>
Message-ID: <202104160538.e493Hslw-lkp@intel.com>

Hi Oleksij,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]

url:    https://github.com/0day-ci/linux/commits/Oleksij-Rempel/provide-generic-net-selftest-support/20210415-211011
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 3a1aa533f7f676aad68f8dbbbba10b9502903770
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/918b3886de4e3cbe278ddac71a69939b6a6abf80
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Oleksij-Rempel/provide-generic-net-selftest-support/20210415-211011
        git checkout 918b3886de4e3cbe278ddac71a69939b6a6abf80
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=sh 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   sh4-linux-ld: net/core/selftests.o: in function `net_selftest':
>> (.text+0x7d0): undefined reference to `phy_loopback'

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC
   Depends on SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && HAS_DMA
   Selected by
   - SND_ATMEL_SOC_SSC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC
   - SND_ATMEL_SOC_SSC_PDC && SOUND && !UML && SND && SND_SOC && SND_ATMEL_SOC && ATMEL_SSC

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 54267 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210416/56a61ad1/attachment-0001.gz>

From willy at infradead.org  Thu Apr 15 23:22:11 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Thu, 15 Apr 2021 23:22:11 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <5179a01a462f43d6951a65de2a299070@AcuMS.aculab.com>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210415182155.GD2531743@casper.infradead.org>
 <5179a01a462f43d6951a65de2a299070@AcuMS.aculab.com>
Message-ID: <20210415222211.GG2531743@casper.infradead.org>

On Thu, Apr 15, 2021 at 09:11:56PM +0000, David Laight wrote:
> Isn't it possible to move the field down one long?
> This might require an explicit zero - but this is not a common
> code path - the extra write will be noise.

Then it overlaps page->mapping.  See emails passim.


From dja at axtens.net  Thu Apr 15 23:43:38 2021
From: dja at axtens.net (Daniel Axtens)
Date: Fri, 16 Apr 2021 08:43:38 +1000
Subject: [PATCH v1 1/5] mm: pagewalk: Fix walk for hugepage tables
In-Reply-To: <733408f48b1ed191f53518123ee6fc6d42287cc6.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <733408f48b1ed191f53518123ee6fc6d42287cc6.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <877dl3184l.fsf@dja-thinkpad.axtens.net>

Hi Christophe,

> Pagewalk ignores hugepd entries and walk down the tables
> as if it was traditionnal entries, leading to crazy result.
>
> Add walk_hugepd_range() and use it to walk hugepage tables.
>
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
>  mm/pagewalk.c | 54 +++++++++++++++++++++++++++++++++++++++++++++------
>  1 file changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index e81640d9f177..410a9d8f7572 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c
> @@ -58,6 +58,32 @@ static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	return err;
>  }
>  
> +static int walk_hugepd_range(hugepd_t *phpd, unsigned long addr,
> +			     unsigned long end, struct mm_walk *walk, int pdshift)
> +{
> +	int err = 0;
> +#ifdef CONFIG_ARCH_HAS_HUGEPD
> +	const struct mm_walk_ops *ops = walk->ops;
> +	int shift = hugepd_shift(*phpd);
> +	int page_size = 1 << shift;
> +
> +	if (addr & (page_size - 1))
> +		return 0;
> +
> +	for (;;) {
> +		pte_t *pte = hugepte_offset(*phpd, addr, pdshift);
> +
> +		err = ops->pte_entry(pte, addr, addr + page_size, walk);
> +		if (err)
> +			break;
> +		if (addr >= end - page_size)
> +			break;
> +		addr += page_size;
> +	}

Initially I thought this was a somewhat unintuitive way to structure
this loop, but I see it parallels the structure of walk_pte_range_inner,
so I think the consistency is worth it.

I notice the pte walking code potentially takes some locks: does this
code need to do that?

arch/powerpc/mm/hugetlbpage.c says that hugepds are protected by the
mm->page_table_lock, but I don't think we're taking it in this code.

> +#endif
> +	return err;
> +}
> +
>  static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>  			  struct mm_walk *walk)
>  {
> @@ -108,7 +134,10 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>  				goto again;
>  		}
>  
> -		err = walk_pte_range(pmd, addr, next, walk);
> +		if (is_hugepd(__hugepd(pmd_val(*pmd))))
> +			err = walk_hugepd_range((hugepd_t *)pmd, addr, next, walk, PMD_SHIFT);
> +		else
> +			err = walk_pte_range(pmd, addr, next, walk);
>  		if (err)
>  			break;
>  	} while (pmd++, addr = next, addr != end);
> @@ -157,7 +186,10 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
>  		if (pud_none(*pud))
>  			goto again;
>  
> -		err = walk_pmd_range(pud, addr, next, walk);
> +		if (is_hugepd(__hugepd(pud_val(*pud))))
> +			err = walk_hugepd_range((hugepd_t *)pud, addr, next, walk, PUD_SHIFT);
> +		else
> +			err = walk_pmd_range(pud, addr, next, walk);

I'm a bit worried you might end up calling into walk_hugepd_range with
ops->pte_entry == NULL, and then jumping to 0.

static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
			  struct mm_walk *walk)
{
...
        pud = pud_offset(p4d, addr);
	do {
                ...
                if ((!walk->vma && (pud_leaf(*pud) || !pud_present(*pud))) ||
		    walk->action == ACTION_CONTINUE ||
		    !(ops->pmd_entry || ops->pte_entry)) <<< THIS CHECK
			continue;
                ...
		if (is_hugepd(__hugepd(pud_val(*pud))))
			err = walk_hugepd_range((hugepd_t *)pud, addr, next, walk, PUD_SHIFT);
		else
			err = walk_pmd_range(pud, addr, next, walk);
		if (err)
			break;
	} while (pud++, addr = next, addr != end);

walk_pud_range will proceed if there is _either_ an ops->pmd_entry _or_
an ops->pte_entry, but walk_hugepd_range will call ops->pte_entry
unconditionally.

The same issue applies to walk_{p4d,pgd}_range...

Kind regards,
Daniel


From ilya.lipnitskiy at gmail.com  Fri Apr 16 00:02:34 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 15 Apr 2021 16:02:34 -0700
Subject: [PATCH net-next] net: ethernet: mediatek: ppe: fix busy wait loop
Message-ID: <20210415230234.14895-1-ilya.lipnitskiy@gmail.com>

The intention is for the loop to timeout if the body does not succeed.
The current logic calls time_is_before_jiffies(timeout) which is false
until after the timeout, so the loop body never executes.

time_is_after_jiffies(timeout) will return true until timeout is less
than jiffies, which is the intended behavior here.

Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
Cc: Felix Fietkau <nbd at nbd.name>
---
 drivers/net/ethernet/mediatek/mtk_ppe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 71e1ccea6e72..af3c266297aa 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -46,7 +46,7 @@ static int mtk_ppe_wait_busy(struct mtk_ppe *ppe)
 {
 	unsigned long timeout = jiffies + HZ;
 
-	while (time_is_before_jiffies(timeout)) {
+	while (time_is_after_jiffies(timeout)) {
 		if (!(ppe_r32(ppe, MTK_PPE_GLO_CFG) & MTK_PPE_GLO_CFG_BUSY))
 			return 0;
 
-- 
2.31.1



From andrew at lunn.ch  Fri Apr 16 00:10:20 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 16 Apr 2021 01:10:20 +0200
Subject: [PATCH net-next] net: ethernet: mediatek: ppe: fix busy wait loop
In-Reply-To: <20210415230234.14895-1-ilya.lipnitskiy@gmail.com>
References: <20210415230234.14895-1-ilya.lipnitskiy@gmail.com>
Message-ID: <YHjH3DxteZrID2hW@lunn.ch>

On Thu, Apr 15, 2021 at 04:02:34PM -0700, Ilya Lipnitskiy wrote:
> The intention is for the loop to timeout if the body does not succeed.
> The current logic calls time_is_before_jiffies(timeout) which is false
> until after the timeout, so the loop body never executes.
> 
> time_is_after_jiffies(timeout) will return true until timeout is less
> than jiffies, which is the intended behavior here.
> 
> Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> Cc: Felix Fietkau <nbd at nbd.name>
> ---
>  drivers/net/ethernet/mediatek/mtk_ppe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
> index 71e1ccea6e72..af3c266297aa 100644
> --- a/drivers/net/ethernet/mediatek/mtk_ppe.c
> +++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
> @@ -46,7 +46,7 @@ static int mtk_ppe_wait_busy(struct mtk_ppe *ppe)
>  {
>  	unsigned long timeout = jiffies + HZ;
>  
> -	while (time_is_before_jiffies(timeout)) {
> +	while (time_is_after_jiffies(timeout)) {
>  		if (!(ppe_r32(ppe, MTK_PPE_GLO_CFG) & MTK_PPE_GLO_CFG_BUSY))
>  			return 0;

Maybe see is iopoll.h can be used.

      Andrew

>  
> -- 
> 2.31.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From bvanassche at acm.org  Fri Apr 16 00:11:23 2021
From: bvanassche at acm.org (Bart Van Assche)
Date: Thu, 15 Apr 2021 16:11:23 -0700
Subject: [PATCH v18 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>
References: <cover.1618426513.git.asutoshd@codeaurora.org>
 <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>
Message-ID: <f111e363-c709-fe3c-65da-450c9e9e3408@acm.org>

On 4/14/21 11:58 AM, Asutosh Das wrote:
> [ ... ]

Patches sent to the SCSI mailing list should not have a "scsi: " prefix
in the subject. That prefix is inserted before any SCSI patches go into
Martin's tree.

> diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
> index 13d9204..b9105e4 100644
> --- a/drivers/scsi/ufs/cdns-pltfrm.c
> +++ b/drivers/scsi/ufs/cdns-pltfrm.c
> @@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
>  	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
>  	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
>  	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
> +	.prepare	 = ufshcd_suspend_prepare,
> +	.complete	= ufshcd_resume_complete,
>  };
>  
>  static struct platform_driver cdns_ufs_pltfrm_driver = {
> diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
> index 67a6a61..b01db12 100644
> --- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
> +++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
> @@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
>  	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
>  	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
>  	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
> +	.prepare	 = ufshcd_suspend_prepare,
> +	.complete	= ufshcd_resume_complete,
>  };

[ ... ]

> --- a/drivers/scsi/ufs/ufs-exynos.c
> +++ b/drivers/scsi/ufs/ufs-exynos.c
> @@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
>  	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
>  	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
>  	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
> +	.prepare	 = ufshcd_suspend_prepare,
> +	.complete	= ufshcd_resume_complete,
>  };
>  
>  static struct platform_driver exynos_ufs_pltform = {
> diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
> index 0aa5813..d463b44 100644
> --- a/drivers/scsi/ufs/ufs-hisi.c
> +++ b/drivers/scsi/ufs/ufs-hisi.c
> @@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
>  	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
>  	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
>  	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
> +	.prepare	 = ufshcd_suspend_prepare,
> +	.complete	= ufshcd_resume_complete,
>  };

A minor comment about source code formatting: please make sure that the
equality signs are aligned in struct dev_pm_ops definitions.

> +static inline bool is_rpmb_wlun(struct scsi_device *sdev)
> +{
> +	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
> +}
> +
> +static inline bool is_device_wlun(struct scsi_device *sdev)
> +{
> +	return (sdev->lun ==
> +		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
> +}

The Linux kernel coding style requires not to surround expressions with
parentheses in return statements.

>  /**
> + * ufshcd_setup_links - associate link b/w device wlun and other luns
> + * @sdev: pointer to SCSI device
> + * @hba: pointer to ufs hba
> + */
> +static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
> +{
> +	struct device_link *link;
> +
> +	/*
> +	 * device wlun is the supplier & rest of the luns are consumers
> +	 * This ensures that device wlun suspends after all other luns.
> +	 */
> +	if (hba->sdev_ufs_device) {
> +		link = device_link_add(&sdev->sdev_gendev,
> +				       &hba->sdev_ufs_device->sdev_gendev,
> +				       DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
> +		if (!link) {
> +			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
> +				dev_name(&hba->sdev_ufs_device->sdev_gendev));
> +			return;
> +		}
> +		hba->luns_avail--;
> +		/* Ignore REPORT_LUN wlun probing */
> +		if (hba->luns_avail == 1) {
> +			ufshcd_rpm_put(hba);
> +			return;
> +		}
> +	} else {
> +		/* device wlun is probed */
> +		hba->luns_avail--;
> +	}
> +}

Please add a comment that explains that it is assumed that the WLUNs are
scanned before the other LUNs.

> @@ -4862,8 +4913,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
>  	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
>  	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
>  		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
> -
> -	if (ufshcd_is_rpm_autosuspend_allowed(hba))
> +	/*
> +	 * Block runtime-pm until all consumers are added.
> +	 * Refer ufshcd_setup_links().
> +	 */
> +	if (is_device_wlun(sdev))
> +		pm_runtime_get_noresume(&sdev->sdev_gendev);
> +	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
>  		sdev->rpm_autosuspend = 1;
>  
>  	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);

The following code is executed before ufshcd_async_scan() is called:

	dev = hba->dev;
	[ ... ]
	/* Hold auto suspend until async scan completes */
	pm_runtime_get_sync(dev);

and the following code occurs in ufshcd_add_lus():

	pm_runtime_put_sync(hba->dev);

Isn't that sufficient to postpone enabling of runtime PM until LUN
scanning has finished? Or in other words, is adding a
pm_runtime_get_noresume() call in ufshcd_slave_configure() really necessary?

> @@ -4979,15 +5035,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
>  			 */
>  			if (!hba->pm_op_in_progress &&
>  			    !ufshcd_eh_in_progress(hba) &&
> -			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
> -			    schedule_work(&hba->eeh_work)) {
> -				/*
> -				 * Prevent suspend once eeh_work is scheduled
> -				 * to avoid deadlock between ufshcd_suspend
> -				 * and exception event handler.
> -				 */
> -				pm_runtime_get_noresume(hba->dev);
> -			}
> +			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
> +				/* Flushed in suspend */
> +				schedule_work(&hba->eeh_work);

What makes it safe to leave out the above pm_runtime_get_noresume() call?

Thanks,

Bart.


From dja at axtens.net  Fri Apr 16 00:12:34 2021
From: dja at axtens.net (Daniel Axtens)
Date: Fri, 16 Apr 2021 09:12:34 +1000
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <8735vr16sd.fsf@dja-thinkpad.axtens.net>

Hi Christophe,

>  static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
> -		      u64 val)
> +		      u64 val, unsigned long page_size)

Compilers can warn about unused parameters at -Wextra level.  However,
reading scripts/Makefile.extrawarn it looks like the warning is
explicitly _disabled_ in the kernel at W=1 and not reenabled at W=2 or
W=3. So I guess this is fine...

> @@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long next,
>  {
>  	struct ptdump_state *st = walk->private;
>  
> -	st->note_page(st, addr, depth, 0);
> +	st->note_page(st, addr, depth, 0, 0);

I know it doesn't matter at this point, but I'm not really thrilled by
the idea of passing 0 as the size here. Doesn't the hole have a known
page size?

>  
>  	return 0;
>  }
> @@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>  	mmap_read_unlock(mm);
>  
>  	/* Flush out the last page */
> -	st->note_page(st, 0, -1, 0);
> +	st->note_page(st, 0, -1, 0, 0);

I'm more OK with the idea of passing 0 as the size when the depth is -1
(don't know): if we don't know the depth we conceptually can't know the
page size.

Regards,
Daniel



From bradwworkk at gmail.com  Fri Apr 16 00:21:01 2021
From: bradwworkk at gmail.com (Brad Wallwork)
Date: Thu, 15 Apr 2021 16:21:01 -0700
Subject: Good Day
Message-ID: <CAGAFM7Q7kzvwva-OvWkeamrTNRRnML7FJvjD23FSDD=u5P3Yrw@mail.gmail.com>

Hello,
Brad Wallwork. Can I trust you to be a partner?
Can you handle a lucrative Crude Oil business?
I have a business proposal that involves Crude Oil.
If interested please reply for more details.
bradwworkk at gmail.com
Brad Wallwork.


From dja at axtens.net  Fri Apr 16 00:29:20 2021
From: dja at axtens.net (Daniel Axtens)
Date: Fri, 16 Apr 2021 09:29:20 +1000
Subject: [PATCH v1 4/5] mm: ptdump: Support hugepd table entries
In-Reply-To: <f41a177a0fd5a71db616e586a9ec5c51102c6656.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <f41a177a0fd5a71db616e586a9ec5c51102c6656.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <87zgxzyvn3.fsf@dja-thinkpad.axtens.net>

Hi Christophe,

> Which hugepd, page table entries can be at any level
> and can be of any size.
>
> Add support for them.
>
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
>  mm/ptdump.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/mm/ptdump.c b/mm/ptdump.c
> index 61cd16afb1c8..6efdb8c15a7d 100644
> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -112,11 +112,24 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
>  {
>  	struct ptdump_state *st = walk->private;
>  	pte_t val = ptep_get(pte);
> +	unsigned long page_size = next - addr;
> +	int level;
> +
> +	if (page_size >= PGDIR_SIZE)
> +		level = 0;
> +	else if (page_size >= P4D_SIZE)
> +		level = 1;
> +	else if (page_size >= PUD_SIZE)
> +		level = 2;
> +	else if (page_size >= PMD_SIZE)
> +		level = 3;
> +	else
> +		level = 4;
>  
>  	if (st->effective_prot)
> -		st->effective_prot(st, 4, pte_val(val));
> +		st->effective_prot(st, level, pte_val(val));
>  
> -	st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
> +	st->note_page(st, addr, level, pte_val(val), page_size);

It seems to me that passing both level and page_size is a bit redundant,
but I guess it does reduce the impact on each arch's code?

Kind regards,
Daniel

>  
>  	return 0;
>  }
> -- 
> 2.25.0


From asutoshd at codeaurora.org  Fri Apr 16 00:36:06 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Thu, 15 Apr 2021 16:36:06 -0700
Subject: [PATCH v19 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1618529652.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v18 -> v19:
- Addressed Adrian's comments
- Fixed smatch warnings

v17 -> v18:
- Addressed Adrian's comments

v16 -> v17:
- Addressed Adrian's & Daejun's comments

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing


Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  24 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 691 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 563 insertions(+), 265 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Fri Apr 16 00:36:07 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Thu, 15 Apr 2021 16:36:07 -0700
Subject: [PATCH v19 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1618529652.git.asutoshd@codeaurora.org>
References: <cover.1618529652.git.asutoshd@codeaurora.org>
Message-ID: <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes.
This also registers a new scsi driver for rpmb wlun.
This new driver is mostly used to clear rpmb uac.
With this design, the driver would always be runtime resumed
before system suspend.

Fixed smatch warnings:
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 691 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 551 insertions(+), 253 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..b9105e4 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..4e1ff20 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..49a918c 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..d463b44 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..39bf204 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			ufshcd_rpm_put_sync(hba);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..7fdb9e3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return (sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4098,12 +4112,13 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	}
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
-	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+	if (update &&
+	    !pm_runtime_suspended(&hba->sdev_ufs_device->sdev_gendev)) {
+		ufshcd_rpm_get_sync(hba);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		ufshcd_rpm_put_sync(hba);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4816,40 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			ufshcd_rpm_put(hba);
+			return;
+		}
+	} else {
+		/* device wlun is probed */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4880,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4913,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5035,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5636,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
+	ufshcd_rpm_put_sync(hba);
 }
 
 /**
@@ -5604,7 +5654,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5670,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5794,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	ufshcd_rpm_get_sync(hba);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5836,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	ufshcd_rpm_put(hba);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5857,18 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
+
+	/* hba device might have a runtime error otherwise */
+	if (ret)
+		ret = pm_runtime_set_active(hba->dev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7292,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7455,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7935,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8521,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8697,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8705,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8728,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto vops_suspend;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8750,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8778,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8791,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
+vops_suspend:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8800,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8824,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
-
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8858,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,42 +8906,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
 	if (ufshcd_is_clkscaling_supported(hba))
-		ufshcd_clk_scaling_suspend(hba, false);
-
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
+		ufshcd_resume_clkscaling(hba);
 
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	down(&hba->host_sem);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret) {
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+		up(&hba->host_sem);
+	}
+
+out:
+	if (!ret)
+		hba->is_sys_suspended = true;
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+out:
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+	if (!ret)
+		hba->is_sys_suspended = false;
+	up(&hba->host_sem);
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	ufshcd_rpm_get_sync(hba);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static int ufshcd_suspend(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
-	ufshcd_setup_clocks(hba, false);
+	ret = ufshcd_setup_clocks(hba, false);
+	if (ret) {
+		ufshcd_enable_irq(hba);
+		return ret;
+	}
 	if (ufshcd_is_clkgating_allowed(hba)) {
 		hba->clk_gating.state = CLKS_OFF;
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	return ret;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
-	hba->pm_op_in_progress = 0;
 	if (ret)
 		ufshcd_update_evt_hist(hba, UFS_EVT_RESUME_ERR, (u32)ret);
 	return ret;
@@ -8962,6 +9129,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8970,41 +9138,14 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	down(&hba->host_sem);
-
-	if (!hba->is_powered)
-		return 0;
-
-	if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
-	     hba->curr_dev_pwr_mode) &&
-	    (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-	     hba->uic_link_state) &&
-	     !hba->dev_info.b_rpm_dev_flush_capable)
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ret = ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = true;
-	else
-		up(&hba->host_sem);
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_suspend);
@@ -9021,21 +9162,16 @@ int ufshcd_system_resume(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+
+	ret = ufshcd_resume(hba);
+
 out:
 	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
-	up(&hba->host_sem);
+
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
@@ -9045,19 +9181,17 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_suspend(hba);
+
 	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9069,33 +9203,19 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_resume(hba);
+
 	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9113,30 +9233,20 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
-	if (!hba->is_powered)
-		goto out;
-
 	if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
 		goto out;
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9260,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		ufshcd_rpm_get_sync(hba);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9565,176 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	ufshcd_rpm_put(hba);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * Force it to honor system-suspend.
+	 * Refer ufshcd_resume_complete()
+	 */
+	ufshcd_rpm_get_sync(hba);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba = shost_priv(sdev->host);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
-	return 0;
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret)
+		goto debugfs_exit;
+
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret)
+		goto unregister;
+
+	return ret;
+unregister:
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+debugfs_exit:
+	ufs_debugfs_exit();
+	return ret;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..3a8dc0d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
@@ -1309,4 +1315,19 @@ static inline int ufshcd_update_ee_usr_mask(struct ufs_hba *hba,
 					&hba->ee_drv_mask, set, clr);
 }
 
+static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_put_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+}
+
 #endif /* End of Header */
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From grygorii.strashko at ti.com  Fri Apr 16 00:46:40 2021
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 16 Apr 2021 02:46:40 +0300
Subject: [PATCH] gpio: omap: Save and restore sysconfig
In-Reply-To: <20210415085305.56413-1-tony@atomide.com>
References: <20210415085305.56413-1-tony@atomide.com>
Message-ID: <67113b0b-5e5f-b2f4-1b1c-b58a1055f0ed@ti.com>



On 15/04/2021 11:53, Tony Lindgren wrote:
> As we are using cpu_pm to save and restore context, we must also save and
> restore the timer sysconfig register TIOCP_CFG. This is needed because
> we are not calling PM runtime functions at all with cpu_pm.

Smth. is wrong with description.

> 
> We need to save the sysconfig on idle as it's value can get reconfigured by
> PM runtime and can be different from the init time value. Device specific
> flags like "ti,no-idle-on-init" can affect the init value.
> 
> Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
> Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
> Cc: Adam Ford <aford173 at gmail.com>
> Cc: Andreas Kemnade <andreas at kemnade.info>
> Cc: Grygorii Strashko <grygorii.strashko at ti.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>   drivers/gpio/gpio-omap.c                | 9 +++++++++
>   include/linux/platform_data/gpio-omap.h | 3 +++
>   2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -29,6 +29,7 @@
>   #define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF
>   
>   struct gpio_regs {
> +	u32 sysconfig;
>   	u32 irqenable1;
>   	u32 irqenable2;
>   	u32 wake_en;
> @@ -1069,6 +1070,7 @@ static void omap_gpio_init_context(struct gpio_bank *p)
>   	const struct omap_gpio_reg_offs *regs = p->regs;
>   	void __iomem *base = p->base;
>   
> +	p->context.sysconfig	= readl_relaxed(base + regs->sysconfig);
>   	p->context.ctrl		= readl_relaxed(base + regs->ctrl);
>   	p->context.oe		= readl_relaxed(base + regs->direction);
>   	p->context.wake_en	= readl_relaxed(base + regs->wkup_en);
> @@ -1088,6 +1090,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
>   	const struct omap_gpio_reg_offs *regs = bank->regs;
>   	void __iomem *base = bank->base;
>   
> +	writel_relaxed(bank->context.sysconfig, base + regs->sysconfig);
>   	writel_relaxed(bank->context.wake_en, base + regs->wkup_en);
>   	writel_relaxed(bank->context.ctrl, base + regs->ctrl);
>   	writel_relaxed(bank->context.leveldetect0, base + regs->leveldetect0);
> @@ -1115,6 +1118,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
>   
>   	bank->saved_datain = readl_relaxed(base + bank->regs->datain);
>   
> +	/* Save syconfig, it's runtime value can be different from init value */
> +	if (bank->loses_context)
> +		bank->context.sysconfig = readl_relaxed(base + bank->regs->sysconfig);
> +
>   	if (!bank->enabled_non_wakeup_gpios)
>   		goto update_gpio_context_count;
>   
> @@ -1279,6 +1286,7 @@ static int gpio_omap_cpu_notifier(struct notifier_block *nb,
>   
>   static const struct omap_gpio_reg_offs omap2_gpio_regs = {
>   	.revision =		OMAP24XX_GPIO_REVISION,
> +	.sysconfig =		OMAP24XX_GPIO_SYSCONFIG,
>   	.direction =		OMAP24XX_GPIO_OE,
>   	.datain =		OMAP24XX_GPIO_DATAIN,
>   	.dataout =		OMAP24XX_GPIO_DATAOUT,
> @@ -1302,6 +1310,7 @@ static const struct omap_gpio_reg_offs omap2_gpio_regs = {
>   
>   static const struct omap_gpio_reg_offs omap4_gpio_regs = {
>   	.revision =		OMAP4_GPIO_REVISION,
> +	.sysconfig =		OMAP4_GPIO_SYSCONFIG,
>   	.direction =		OMAP4_GPIO_OE,
>   	.datain =		OMAP4_GPIO_DATAIN,
>   	.dataout =		OMAP4_GPIO_DATAOUT,
> diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h
> --- a/include/linux/platform_data/gpio-omap.h
> +++ b/include/linux/platform_data/gpio-omap.h
> @@ -85,6 +85,7 @@
>    * omap2+ specific GPIO registers
>    */
>   #define OMAP24XX_GPIO_REVISION		0x0000
> +#define OMAP24XX_GPIO_SYSCONFIG		0x0010
>   #define OMAP24XX_GPIO_IRQSTATUS1	0x0018
>   #define OMAP24XX_GPIO_IRQSTATUS2	0x0028
>   #define OMAP24XX_GPIO_IRQENABLE2	0x002c
> @@ -108,6 +109,7 @@
>   #define OMAP24XX_GPIO_SETDATAOUT	0x0094
>   
>   #define OMAP4_GPIO_REVISION		0x0000
> +#define OMAP4_GPIO_SYSCONFIG		0x0010
>   #define OMAP4_GPIO_EOI			0x0020
>   #define OMAP4_GPIO_IRQSTATUSRAW0	0x0024
>   #define OMAP4_GPIO_IRQSTATUSRAW1	0x0028
> @@ -148,6 +150,7 @@
>   #ifndef __ASSEMBLER__
>   struct omap_gpio_reg_offs {
>   	u16 revision;
> +	u16 sysconfig;
>   	u16 direction;
>   	u16 datain;
>   	u16 dataout;
> 

-- 
Best regards,
grygorii


From dillonhua at gmail.com  Fri Apr 16 01:06:10 2021
From: dillonhua at gmail.com (Hua Dillon)
Date: Fri, 16 Apr 2021 08:06:10 +0800
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <e17fddfb-f9b8-238f-da74-a4746f33134f@foss.st.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
 <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
 <e17fddfb-f9b8-238f-da74-a4746f33134f@foss.st.com>
Message-ID: <CAPTRvHksyOR-XoLUOA+fCf33CWj--Y8jUiN99qMFcnxrQ3M_FA@mail.gmail.com>

Hi Erwan,

Erwan LE RAY <erwan.leray at foss.st.com> ?2021?4?16??? ??1:10???
>
> Hi Dillon,
>
> STM32MP151 is mono-core, but both STM32MP153 and STM32MP157 are
> dual-core (see
> https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-arm-cortex-mpus.html).
> So your point is fully relevant, thanks.

Thanks.
>
> ST already fixed the same issue in st-asc.c driver in the past (see
> ef49ffd8), because a systematic deadlock was detected with RT kernel.
>
> You proposed a first implementation in your patch, and a second one in
> the discussion. It seems that your initial proposal (ie your V2 patch)
> is the most standard one (implemented in 6 drivers). The second
> implementation is implemented by only 1 company.
>
> It looks that the solution is to avoid locking in the sysrq case and
> trylock in the oops_in_progress case (see detailed analysis in
> 677fe555cbfb1).

Thanks for the detail information. the V2 patch didn't cover this case:

    stm32_usart_threaded_interrupt()
      spin_lock(&port->lock);
      ...
      uart_handle_sysrq_char();
        sysrq_function();
          printk();
            stm32_usart_console_write();
              locked = spin_trylock_irqsave(&port->lock); //better
than no lock(locked = 0) if other uart interrupt coming at this point

Find a same solution on fsl_lpuart.c
commit abf1e0a98083fd0a1069ce68ad8c92bfb97a57db

Thanks.

Best regards
Dillon
>
> So your initial patch looks to the right proposal, but it would be safer
> if Greg could confirm it.
>
> BR, Erwan.
>
>
> On 4/13/21 1:44 AM, dillon min wrote:
> > Hi Johan, Erwan
> >
> > It seems still a bit of a problem in the current version, not deadlock
> > but access register at the same time.
> >
> > For driver , we should consider it running under smp, let's think
> > about it for this case:
> >
> > static void stm32_usart_console_write(struct console *co, const char *s,
> >                                        unsigned int cnt)
> > {
> >           .....
> >           local_irq_save(flags);
> >           if (port->sysrq)
> >                      locked = 0;
> >           .....
> >           access register cr1, tdr, isr
> >           .....
> >
> >           local_irq_restore(flags);
> > }
> >
> > if port->sysrq is 1, stm32_usart_console_write() just disable local
> > irq response by local_irq_save(), at the time of access register cr1,
> > tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> > mpu/mcu do not have multi cores, just assume it has), it still has a
> > chance to handle interrupt.  Then there is no lock to protect the uart
> > register.
> >
> > changes to below, should be more safe:
> >
> > .....
> > if (port->sysrq || oops_in_progress)
> >        locked = spin_trylock_irqsave(&port->lock, flags);
> > else
> >        spin_lock_irqsave(&port->lock, flags);
> >
> > ....
> >
> > if (locked)
> >       spin_unlock_irqrestore(&port->lock, flags);
> >
> > For current stm32 soc, it shouldn't happen. just a reminder for future.
> >
> > Thanks.
> >
> > Dillon
> >
> > On Mon, Apr 12, 2021 at 10:04 PM dillon min <dillon.minfei at gmail.com> wrote:
> >>
> >> Hi Johan,
> >>
> >> Yes, there is no deadlock. my fault.
> >> I forget the local_irq_save() plus spin_lock() is spin_lock_irqsave().
> >>
> >> Thanks for your review. please ignore this patch.
> >>
> >> Best regards
> >>
> >> Dillon
> >>
> >> On Mon, Apr 12, 2021 at 9:08 PM Johan Hovold <johan at kernel.org> wrote:
> >>>
> >>> On Mon, Apr 12, 2021 at 05:31:38PM +0800, dillon.minfei at gmail.com wrote:
> >>>> From: dillon min <dillon.minfei at gmail.com>
> >>>>
> >>>> To avoid potential deadlock in spin_lock usage, use spin_lock_irqsave,
> >>>> spin_trylock_irqsave(), spin_unlock_irqrestore() in process context.
> >>>
> >>> This doesn't make much sense as console_write can be called in any
> >>> context. And where's the deadlock you claim to be fixing here?
> >>>
> >>>> remove unused local_irq_save/restore call.
> >>>>
> >>>> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> >>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> >>>> Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> >>>> Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> >>>> Reported-by: kernel test robot <lkp at intel.com>
> >>>> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> >>>> ---
> >>>> v2: remove unused code from stm32_usart_threaded_interrupt() according from
> >>>>      Greg's review.
> >>>>
> >>>>   drivers/tty/serial/stm32-usart.c | 8 +++-----
> >>>>   1 file changed, 3 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> >>>> index b3675cf25a69..b1ba5e36e36e 100644
> >>>> --- a/drivers/tty/serial/stm32-usart.c
> >>>> +++ b/drivers/tty/serial/stm32-usart.c
> >>>> @@ -1354,13 +1354,12 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> >>>>        u32 old_cr1, new_cr1;
> >>>>        int locked = 1;
> >>>>
> >>>> -     local_irq_save(flags);
> >>>>        if (port->sysrq)
> >>>>                locked = 0;
> >>>>        else if (oops_in_progress)
> >>>> -             locked = spin_trylock(&port->lock);
> >>>> +             locked = spin_trylock_irqsave(&port->lock, flags);
> >>>>        else
> >>>> -             spin_lock(&port->lock);
> >>>> +             spin_lock_irqsave(&port->lock, flags);
> >>>>
> >>>>        /* Save and disable interrupts, enable the transmitter */
> >>>>        old_cr1 = readl_relaxed(port->membase + ofs->cr1);
> >>>> @@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
> >>>>        writel_relaxed(old_cr1, port->membase + ofs->cr1);
> >>>>
> >>>>        if (locked)
> >>>> -             spin_unlock(&port->lock);
> >>>> -     local_irq_restore(flags);
> >>>> +             spin_unlock_irqrestore(&port->lock, flags);
> >>>>   }
> >>>>
> >>>>   static int stm32_usart_console_setup(struct console *co, char *options)
> >>>
> >>> Johan


From ilya.lipnitskiy at gmail.com  Fri Apr 16 01:11:48 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 15 Apr 2021 17:11:48 -0700
Subject: [PATCH net-next,v2] net: ethernet: mediatek: ppe: fix busy wait loop
In-Reply-To: <YHjH3DxteZrID2hW@lunn.ch>
References: <YHjH3DxteZrID2hW@lunn.ch>
Message-ID: <20210416001148.333969-1-ilya.lipnitskiy@gmail.com>

The intention is for the loop to timeout if the body does not succeed.
The current logic calls time_is_before_jiffies(timeout) which is false
until after the timeout, so the loop body never executes.

Fix by using readl_poll_timeout as a more standard and less error-prone
solution.

Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
Cc: Felix Fietkau <nbd at nbd.name>
---
 drivers/net/ethernet/mediatek/mtk_ppe.c | 18 +++++++++---------
 drivers/net/ethernet/mediatek/mtk_ppe.h |  1 +
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 71e1ccea6e72..f4b3fc0eeb50 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -5,6 +5,7 @@
 #include <linux/jiffies.h>
 #include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/etherdevice.h>
 #include <linux/platform_device.h>
 #include "mtk_ppe.h"
@@ -44,18 +45,17 @@ static u32 ppe_clear(struct mtk_ppe *ppe, u32 reg, u32 val)
 
 static int mtk_ppe_wait_busy(struct mtk_ppe *ppe)
 {
-	unsigned long timeout = jiffies + HZ;
-
-	while (time_is_before_jiffies(timeout)) {
-		if (!(ppe_r32(ppe, MTK_PPE_GLO_CFG) & MTK_PPE_GLO_CFG_BUSY))
-			return 0;
+	int ret;
+	u32 val;
 
-		usleep_range(10, 20);
-	}
+	ret = readl_poll_timeout(ppe->base + MTK_PPE_GLO_CFG, val,
+				 !(val & MTK_PPE_GLO_CFG_BUSY),
+				 20, MTK_PPE_WAIT_TIMEOUT_US);
 
-	dev_err(ppe->dev, "PPE table busy");
+	if (ret)
+		dev_err(ppe->dev, "PPE table busy");
 
-	return -ETIMEDOUT;
+	return ret;
 }
 
 static void mtk_ppe_cache_clear(struct mtk_ppe *ppe)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h
index 51bd5e75bbbd..242fb8f2ae65 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.h
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.h
@@ -12,6 +12,7 @@
 #define MTK_PPE_ENTRIES_SHIFT		3
 #define MTK_PPE_ENTRIES			(1024 << MTK_PPE_ENTRIES_SHIFT)
 #define MTK_PPE_HASH_MASK		(MTK_PPE_ENTRIES - 1)
+#define MTK_PPE_WAIT_TIMEOUT_US		1000000
 
 #define MTK_FOE_IB1_UNBIND_TIMESTAMP	GENMASK(7, 0)
 #define MTK_FOE_IB1_UNBIND_PACKETS	GENMASK(23, 8)
-- 
2.31.1



From rentao.bupt at gmail.com  Fri Apr 16 01:12:08 2021
From: rentao.bupt at gmail.com (rentao.bupt at gmail.com)
Date: Thu, 15 Apr 2021 17:12:08 -0700
Subject: [PATCH] watchdog: aspeed: fix integer overflow in set_timeout handler
Message-ID: <20210416001208.16788-1-rentao.bupt@gmail.com>

From: Tao Ren <rentao.bupt at gmail.com>

Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
handler to avoid potential integer overflow when the supplied timeout is
greater than aspeed's maximum allowed timeout (4294 seconds).

Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad <amithash at fb.com>
Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
---
 drivers/watchdog/aspeed_wdt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index 7e00960651fa..9f77272dc906 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -145,9 +145,8 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
 	struct aspeed_wdt *wdt = to_aspeed_wdt(wdd);
 	u32 actual;
 
-	wdd->timeout = timeout;
-
-	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
+	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
+	wdd->timeout = actual;
 
 	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
 	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
-- 
2.17.1



From andrew at lunn.ch  Fri Apr 16 01:27:49 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 16 Apr 2021 02:27:49 +0200
Subject: [PATCH net-next,v2] net: ethernet: mediatek: ppe: fix busy wait
 loop
In-Reply-To: <20210416001148.333969-1-ilya.lipnitskiy@gmail.com>
References: <YHjH3DxteZrID2hW@lunn.ch>
 <20210416001148.333969-1-ilya.lipnitskiy@gmail.com>
Message-ID: <YHjaBWdMzrhajq2Q@lunn.ch>

On Thu, Apr 15, 2021 at 05:11:48PM -0700, Ilya Lipnitskiy wrote:
> The intention is for the loop to timeout if the body does not succeed.
> The current logic calls time_is_before_jiffies(timeout) which is false
> until after the timeout, so the loop body never executes.
> 
> Fix by using readl_poll_timeout as a more standard and less error-prone
> solution.
> 
> Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> Cc: Felix Fietkau <nbd at nbd.name>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From joel at jms.id.au  Fri Apr 16 01:36:06 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 16 Apr 2021 00:36:06 +0000
Subject: [PATCH] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <20210416001208.16788-1-rentao.bupt@gmail.com>
References: <20210416001208.16788-1-rentao.bupt@gmail.com>
Message-ID: <CACPK8Xdmm-LL+xvbG6bBe0Yd9ZQbPuvwBKhszhjvbOc3pPoH3w@mail.gmail.com>

On Fri, 16 Apr 2021 at 00:12, <rentao.bupt at gmail.com> wrote:
>
> From: Tao Ren <rentao.bupt at gmail.com>
>
> Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> handler to avoid potential integer overflow when the supplied timeout is
> greater than aspeed's maximum allowed timeout (4294 seconds).
>
> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> Reported-by: Amithash Prasad <amithash at fb.com>
> Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
> ---
>  drivers/watchdog/aspeed_wdt.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index 7e00960651fa..9f77272dc906 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -145,9 +145,8 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
>         struct aspeed_wdt *wdt = to_aspeed_wdt(wdd);
>         u32 actual;
>
> -       wdd->timeout = timeout;
> -
> -       actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> +       actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);

The unit of timeout is seconds. You're comparing to ms/1000, which are
microseconds. I think the existing test is correct?

As far as integer overflow is concerned, max_hw_heartbeat_ms is an
unsigned int. We set it to 4294967, which *1000 = 0xfffffed8. This
should be fine.

> +       wdd->timeout = actual;

This might be the correct thing to do though. I'll defer to the
watchdog maintainers for their input.

Cheers,

Joel

>
>         writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
>         writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> --
> 2.17.1
>


From ilya.lipnitskiy at gmail.com  Fri Apr 16 01:37:48 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 15 Apr 2021 17:37:48 -0700
Subject: [PATCH net-next,v3] net: ethernet: mediatek: ppe: fix busy wait loop
In-Reply-To: <YHjaBWdMzrhajq2Q@lunn.ch>
References: <YHjaBWdMzrhajq2Q@lunn.ch>
Message-ID: <20210416003747.340041-1-ilya.lipnitskiy@gmail.com>

The intention is for the loop to timeout if the body does not succeed.
The current logic calls time_is_before_jiffies(timeout) which is false
until after the timeout, so the loop body never executes.

Fix by using readl_poll_timeout as a more standard and less error-prone
solution.

Fixes: ba37b7caf1ed ("net: ethernet: mtk_eth_soc: add support for initializing the PPE")
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
Cc: Felix Fietkau <nbd at nbd.name>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
v2:
  - Use readl_poll_timeout as suggested by Andrew Lunn
v3:
  - Remove unused #include's

 drivers/net/ethernet/mediatek/mtk_ppe.c | 20 +++++++++-----------
 drivers/net/ethernet/mediatek/mtk_ppe.h |  1 +
 2 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 71e1ccea6e72..3ad10c793308 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -2,9 +2,8 @@
 /* Copyright (C) 2020 Felix Fietkau <nbd at nbd.name> */
 
 #include <linux/kernel.h>
-#include <linux/jiffies.h>
-#include <linux/delay.h>
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/etherdevice.h>
 #include <linux/platform_device.h>
 #include "mtk_ppe.h"
@@ -44,18 +43,17 @@ static u32 ppe_clear(struct mtk_ppe *ppe, u32 reg, u32 val)
 
 static int mtk_ppe_wait_busy(struct mtk_ppe *ppe)
 {
-	unsigned long timeout = jiffies + HZ;
-
-	while (time_is_before_jiffies(timeout)) {
-		if (!(ppe_r32(ppe, MTK_PPE_GLO_CFG) & MTK_PPE_GLO_CFG_BUSY))
-			return 0;
+	int ret;
+	u32 val;
 
-		usleep_range(10, 20);
-	}
+	ret = readl_poll_timeout(ppe->base + MTK_PPE_GLO_CFG, val,
+				 !(val & MTK_PPE_GLO_CFG_BUSY),
+				 20, MTK_PPE_WAIT_TIMEOUT_US);
 
-	dev_err(ppe->dev, "PPE table busy");
+	if (ret)
+		dev_err(ppe->dev, "PPE table busy");
 
-	return -ETIMEDOUT;
+	return ret;
 }
 
 static void mtk_ppe_cache_clear(struct mtk_ppe *ppe)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h
index 51bd5e75bbbd..242fb8f2ae65 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.h
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.h
@@ -12,6 +12,7 @@
 #define MTK_PPE_ENTRIES_SHIFT		3
 #define MTK_PPE_ENTRIES			(1024 << MTK_PPE_ENTRIES_SHIFT)
 #define MTK_PPE_HASH_MASK		(MTK_PPE_ENTRIES - 1)
+#define MTK_PPE_WAIT_TIMEOUT_US		1000000
 
 #define MTK_FOE_IB1_UNBIND_TIMESTAMP	GENMASK(7, 0)
 #define MTK_FOE_IB1_UNBIND_PACKETS	GENMASK(23, 8)
-- 
2.31.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:47 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:47 +0800
Subject: [PATCH 0/5] spi: spi-zynqmp-gqspi: fix spi issues
Message-ID: <20210416004652.2975446-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

Hi all,

This series fix some issues that occurs in spi-zynqmp-gqspi.c.

Thanks,
Quanyang

Amit Kumar Mahapatra (1):
  spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug

Quanyang Wang (4):
  spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue
  spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
  spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
  spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails

 drivers/spi/spi-zynqmp-gqspi.c | 115 +++++++++++++++------------------
 1 file changed, 51 insertions(+), 64 deletions(-)

-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:48 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:48 +0800
Subject: [PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance
 issue
In-Reply-To: <20210416004652.2975446-1-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
Message-ID: <20210416004652.2975446-2-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The clks "pclk" and "ref_clk" are enabled twice during the probe. The
first time is in the function zynqmp_qspi_probe and the second time is
in zynqmp_qspi_setup_op which is called by devm_spi_register_controller.
Then calling zynqmp_qspi_remove (rmmod this module) to disable these clks
will trigger a warning as below:

[  309.124604] Unpreparing enabled qspi_ref
[  309.128641] WARNING: CPU: 1 PID: 537 at drivers/clk/clk.c:824 clk_core_unprepare+0x108/0x110

Since pm_runtime works now, clks can be enabled/disabled by calling
zynqmp_runtime_suspend/resume. So we don't need to enable these clks
explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue.

And remove clk enabling/disabling in zynqmp_qspi_resume because there is
no spi transfer operation so enabling ref_clk is redundant meanwhile pclk
is not disabled for it is shared with other peripherals.

Furthermore replace clk_enable/disable with clk_prepare_enable and
clk_disable_unprepare in runtime_suspend/resume functions.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 47 ++++++----------------------------
 1 file changed, 8 insertions(+), 39 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 32e53f379e9b..f9056f0a480c 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -487,24 +487,10 @@ static int zynqmp_qspi_setup_op(struct spi_device *qspi)
 {
 	struct spi_controller *ctlr = qspi->master;
 	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
-	struct device *dev = &ctlr->dev;
-	int ret;
 
 	if (ctlr->busy)
 		return -EBUSY;
 
-	ret = clk_enable(xqspi->refclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable device clock.\n");
-		return ret;
-	}
-
-	ret = clk_enable(xqspi->pclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable APB clock.\n");
-		clk_disable(xqspi->refclk);
-		return ret;
-	}
 	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, GQSPI_EN_MASK);
 
 	return 0;
@@ -863,26 +849,9 @@ static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
 static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
 {
 	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
-	int ret = 0;
-
-	ret = clk_enable(xqspi->pclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable APB clock.\n");
-		return ret;
-	}
-
-	ret = clk_enable(xqspi->refclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable device clock.\n");
-		clk_disable(xqspi->pclk);
-		return ret;
-	}
 
 	spi_controller_resume(ctlr);
 
-	clk_disable(xqspi->refclk);
-	clk_disable(xqspi->pclk);
 	return 0;
 }
 
@@ -898,8 +867,8 @@ static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
 {
 	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
 
-	clk_disable(xqspi->refclk);
-	clk_disable(xqspi->pclk);
+	clk_disable_unprepare(xqspi->refclk);
+	clk_disable_unprepare(xqspi->pclk);
 
 	return 0;
 }
@@ -917,16 +886,16 @@ static int __maybe_unused zynqmp_runtime_resume(struct device *dev)
 	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
 	int ret;
 
-	ret = clk_enable(xqspi->pclk);
+	ret = clk_prepare_enable(xqspi->pclk);
 	if (ret) {
 		dev_err(dev, "Cannot enable APB clock.\n");
 		return ret;
 	}
 
-	ret = clk_enable(xqspi->refclk);
+	ret = clk_prepare_enable(xqspi->refclk);
 	if (ret) {
 		dev_err(dev, "Cannot enable device clock.\n");
-		clk_disable(xqspi->pclk);
+		clk_disable_unprepare(xqspi->pclk);
 		return ret;
 	}
 
@@ -1136,13 +1105,11 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto remove_master;
 	}
 
-	init_completion(&xqspi->data_completion);
-
 	xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
 	if (IS_ERR(xqspi->refclk)) {
 		dev_err(dev, "ref_clk clock not found.\n");
 		ret = PTR_ERR(xqspi->refclk);
-		goto clk_dis_pclk;
+		goto remove_master;
 	}
 
 	ret = clk_prepare_enable(xqspi->pclk);
@@ -1157,6 +1124,8 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_pclk;
 	}
 
+	init_completion(&xqspi->data_completion);
+
 	mutex_init(&xqspi->op_lock);
 
 	pm_runtime_use_autosuspend(&pdev->dev);
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:49 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:49 +0800
Subject: [PATCH 2/5] spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
In-Reply-To: <20210416004652.2975446-1-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
Message-ID: <20210416004652.2975446-3-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.

And we should check the return value of spi_controller_suspend, if
an error is returned, return it to PM subsystem to stop suspend.

Also, GQSPI_EN_MASK should be written to GQSPI_EN_OFST to enable
the spi controller in zynqmp_qspi_resume since it was disabled in
zynqmp_qspi_suspend before.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index f9056f0a480c..1146359528b9 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -157,6 +157,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
  * @data_completion:	completion structure
  */
 struct zynqmp_qspi {
+	struct spi_controller *ctlr;
 	void __iomem *regs;
 	struct clk *refclk;
 	struct clk *pclk;
@@ -827,10 +828,13 @@ static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
  */
 static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
+	struct spi_controller *ctlr = xqspi->ctlr;
+	int ret;
 
-	spi_controller_suspend(ctlr);
+	ret = spi_controller_suspend(ctlr);
+	if (ret)
+		return ret;
 
 	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, 0x0);
 
@@ -848,7 +852,10 @@ static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
  */
 static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
+	struct spi_controller *ctlr = xqspi->ctlr;
+
+	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, GQSPI_EN_MASK);
 
 	spi_controller_resume(ctlr);
 
@@ -865,7 +872,7 @@ static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
  */
 static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
 {
-	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
 
 	clk_disable_unprepare(xqspi->refclk);
 	clk_disable_unprepare(xqspi->pclk);
@@ -883,7 +890,7 @@ static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
  */
 static int __maybe_unused zynqmp_runtime_resume(struct device *dev)
 {
-	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
 	int ret;
 
 	ret = clk_prepare_enable(xqspi->pclk);
@@ -1090,6 +1097,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 
 	xqspi = spi_controller_get_devdata(ctlr);
 	xqspi->dev = dev;
+	xqspi->ctlr = ctlr;
 	platform_set_drvdata(pdev, xqspi);
 
 	xqspi->regs = devm_platform_ioremap_resource(pdev, 0);
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:50 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:50 +0800
Subject: [PATCH 3/5] spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
In-Reply-To: <20210416004652.2975446-1-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
Message-ID: <20210416004652.2975446-4-quanyang.wang@windriver.com>

From: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>

During a transfer the driver filled the fifo with 4bytes,
even if the data that needs to be transfer is less that 4bytes.
This resulted in slab-out-of-bounds bug in KernelAddressSanitizer.

This patch resolves slab-out-of-bounds bug by filling the fifo
with the number of bytes that needs to transferred.

Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 1146359528b9..2e2607b5dee9 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -509,17 +509,19 @@ static void zynqmp_qspi_filltxfifo(struct zynqmp_qspi *xqspi, int size)
 	u32 count = 0, intermediate;
 
 	while ((xqspi->bytes_to_transfer > 0) && (count < size) && (xqspi->txbuf)) {
-		memcpy(&intermediate, xqspi->txbuf, 4);
-		zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
-
 		if (xqspi->bytes_to_transfer >= 4) {
+			memcpy(&intermediate, xqspi->txbuf, 4);
 			xqspi->txbuf += 4;
 			xqspi->bytes_to_transfer -= 4;
+			count += 4;
 		} else {
+			memcpy(&intermediate, xqspi->txbuf,
+			       xqspi->bytes_to_transfer);
 			xqspi->txbuf += xqspi->bytes_to_transfer;
 			xqspi->bytes_to_transfer = 0;
+			count += xqspi->bytes_to_transfer;
 		}
-		count++;
+		zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
 	}
 }
 
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:51 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:51 +0800
Subject: [PATCH 4/5] spi: spi-zynqmp-gqspi: fix use-after-free in
 zynqmp_qspi_exec_op
In-Reply-To: <20210416004652.2975446-1-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
Message-ID: <20210416004652.2975446-5-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

When handling op->addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op->addr.val and op->cmd.opcode to fix
this issue.

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 2e2607b5dee9..419bc1e6358b 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -928,8 +928,9 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 	struct zynqmp_qspi *xqspi = spi_controller_get_devdata
 				    (mem->spi->master);
 	int err = 0, i;
-	u8 *tmpbuf;
 	u32 genfifoentry = 0;
+	u16 opcode = op->cmd.opcode;
+	u64 opaddr;
 
 	dev_dbg(xqspi->dev, "cmd:%#x mode:%d.%d.%d.%d\n",
 		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
@@ -942,14 +943,8 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 	genfifoentry |= xqspi->genfifobus;
 
 	if (op->cmd.opcode) {
-		tmpbuf = kzalloc(op->cmd.nbytes, GFP_KERNEL | GFP_DMA);
-		if (!tmpbuf) {
-			mutex_unlock(&xqspi->op_lock);
-			return -ENOMEM;
-		}
-		tmpbuf[0] = op->cmd.opcode;
 		reinit_completion(&xqspi->data_completion);
-		xqspi->txbuf = tmpbuf;
+		xqspi->txbuf = &opcode;
 		xqspi->rxbuf = NULL;
 		xqspi->bytes_to_transfer = op->cmd.nbytes;
 		xqspi->bytes_to_receive = 0;
@@ -963,13 +958,12 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 		if (!wait_for_completion_timeout
 		    (&xqspi->data_completion, msecs_to_jiffies(1000))) {
 			err = -ETIMEDOUT;
-			kfree(tmpbuf);
 			goto return_err;
 		}
-		kfree(tmpbuf);
 	}
 
 	if (op->addr.nbytes) {
+		xqspi->txbuf = &opaddr;
 		for (i = 0; i < op->addr.nbytes; i++) {
 			*(((u8 *)xqspi->txbuf) + i) = op->addr.val >>
 					(8 * (op->addr.nbytes - i - 1));
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 01:46:52 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 08:46:52 +0800
Subject: [PATCH 5/5] spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single
 fails
In-Reply-To: <20210416004652.2975446-1-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
Message-ID: <20210416004652.2975446-6-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP

Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 419bc1e6358b..328b6559bb19 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -733,7 +733,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
  * zynqmp_qspi_setuprxdma - This function sets up the RX DMA operation
  * @xqspi:	xqspi is a pointer to the GQSPI instance.
  */
-static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
+static int zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 {
 	u32 rx_bytes, rx_rem, config_reg;
 	dma_addr_t addr;
@@ -747,7 +747,7 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 		zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST, config_reg);
 		xqspi->mode = GQSPI_MODE_IO;
 		xqspi->dma_rx_bytes = 0;
-		return;
+		return 0;
 	}
 
 	rx_rem = xqspi->bytes_to_receive % 4;
@@ -755,8 +755,10 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 
 	addr = dma_map_single(xqspi->dev, (void *)xqspi->rxbuf,
 			      rx_bytes, DMA_FROM_DEVICE);
-	if (dma_mapping_error(xqspi->dev, addr))
+	if (dma_mapping_error(xqspi->dev, addr)) {
 		dev_err(xqspi->dev, "ERR:rxdma:memory not mapped\n");
+		return -ENOMEM;
+	}
 
 	xqspi->dma_rx_bytes = rx_bytes;
 	xqspi->dma_addr = addr;
@@ -777,6 +779,8 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 
 	/* Write the number of bytes to transfer */
 	zynqmp_gqspi_write(xqspi, GQSPI_QSPIDMA_DST_SIZE_OFST, rx_bytes);
+
+	return 0;
 }
 
 /**
@@ -813,11 +817,17 @@ static void zynqmp_qspi_write_op(struct zynqmp_qspi *xqspi, u8 tx_nbits,
  * @genfifoentry:	genfifoentry is pointer to the variable in which
  *			GENFIFO	mask is returned to calling function
  */
-static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
+static int zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
 				u32 genfifoentry)
 {
-	zynqmp_qspi_setuprxdma(xqspi);
+	int ret;
+
+	ret = zynqmp_qspi_setuprxdma(xqspi);
+	if (ret)
+		return ret;
 	zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
+
+	return 0;
 }
 
 /**
@@ -1031,8 +1041,11 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 			xqspi->rxbuf = (u8 *)op->data.buf.in;
 			xqspi->bytes_to_receive = op->data.nbytes;
 			xqspi->bytes_to_transfer = 0;
-			zynqmp_qspi_read_op(xqspi, op->data.buswidth,
+			err = zynqmp_qspi_read_op(xqspi, op->data.buswidth,
 					    genfifoentry);
+			if (err)
+				goto return_err;
+
 			zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
 					   zynqmp_gqspi_read
 					   (xqspi, GQSPI_CONFIG_OFST) |
@@ -1159,6 +1172,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_all;
 	}
 
+	dma_set_mask(&pdev->dev, DMA_BIT_MASK(44));
 	ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
 	ctlr->num_chipselect = GQSPI_DEFAULT_NUM_CS;
 	ctlr->mem_ops = &zynqmp_qspi_mem_ops;
-- 
2.25.1



From linux at roeck-us.net  Fri Apr 16 01:50:32 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 15 Apr 2021 17:50:32 -0700
Subject: [PATCH] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <20210416001208.16788-1-rentao.bupt@gmail.com>
References: <20210416001208.16788-1-rentao.bupt@gmail.com>
Message-ID: <469ac948-d65b-471f-102f-726466c19c5c@roeck-us.net>

On 4/15/21 5:12 PM, rentao.bupt at gmail.com wrote:
> From: Tao Ren <rentao.bupt at gmail.com>
> 
> Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> handler to avoid potential integer overflow when the supplied timeout is
> greater than aspeed's maximum allowed timeout (4294 seconds).
> 
> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> Reported-by: Amithash Prasad <amithash at fb.com>
> Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
> ---
>  drivers/watchdog/aspeed_wdt.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index 7e00960651fa..9f77272dc906 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -145,9 +145,8 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
>  	struct aspeed_wdt *wdt = to_aspeed_wdt(wdd);
>  	u32 actual;
>  
> -	wdd->timeout = timeout;
> -
> -	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
> +	wdd->timeout = actual;
>  
>  	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
>  	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> 

If the provided timeout is larger than the supported hardware timeout,
the watchdog core will ping the hardware on behalf of userspace.
The above code would defeat that mechanism for no good reason.

NACK.

Guenter


From nm at ti.com  Fri Apr 16 01:59:53 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 15 Apr 2021 19:59:53 -0500
Subject: [PATCH V3] dt-bindings: mailbox: ti,
 secure-proxy: Convert to json schema
Message-ID: <20210416005953.17147-1-nm@ti.com>

Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- Dropped the example usage of mailbox client, it is better done in
  tisci node definition.
- Switched reg usage for address-cells and size-cells 1 - aligned with
  schema checks as well.
- included header in example for a buildable example.

While at this, lets make sure to support upto 100 rx threads even though
typically upto 1 threads is practically in use.

NOTE: The following checkpatch warning is generated since we do include the header
in the example, but this is a false positive warning.
  WARNING: DT binding docs and includes should be a separate patch. See:
  Documentation/devicetree/bindings/submitting-patches.rst

Signed-off-by: Nishanth Menon <nm at ti.com>
---

Changes since v2:
 - Subject line rewording to indicate json schema rather than yaml
 - Review comment: Dropped "-" in interrupt-names pattern so that it will match all
   entries
 - Minor commit message formatting changes

V2: https://lore.kernel.org/linux-arm-kernel/20210413224535.30910-1-nm at ti.com/
V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1-nm at ti.com/

 .../bindings/mailbox/ti,secure-proxy.txt      | 50 ------------
 .../bindings/mailbox/ti,secure-proxy.yaml     | 79 +++++++++++++++++++
 2 files changed, 79 insertions(+), 50 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..000000000000
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-========================================
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===========================
-Required properties:
---------------------
-- compatible:		Shall be "ti,am654-secure-proxy"
-- reg-names 		target_data - Map the proxy data region
-			rt - Map the realtime status region
-			scfg - Map the configuration region
-- reg:			Contains the register map per reg-names.
-- #mbox-cells		Shall be 1 and shall refer to the transfer path
-			called thread.
-- interrupt-names:	Contains interrupt names matching the rx transfer path
-			for a given SoC. Receive interrupts shall be of the
-			format: "rx_<PID>".
-- interrupts:		Contains the interrupt information corresponding to
-			interrupt-names property.
-
-Example(AM654):
-------------
-
-	secure_proxy: mailbox at 32c00000 {
-		compatible = "ti,am654-secure-proxy";
-		#mbox-cells = <1>;
-		reg-names = "target_data", "rt", "scfg";
-		reg = <0x0 0x32c00000 0x0 0x100000>,
-		      <0x0 0x32400000 0x0 0x100000>,
-		      <0x0 0x32800000 0x0 0x100000>;
-		interrupt-names = "rx_011";
-		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
-	};
-
-	dmsc: dmsc {
-		[...]
-		mbox-names = "rx", "tx";
-		# RX Thread ID is 11
-		# TX Thread ID is 13
-		mboxes= <&secure_proxy 11>,
-			<&secure_proxy 13>;
-		[...]
-	};
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index 000000000000..eea822861804
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  The Texas Instruments' secure proxy is a mailbox controller that has
+  configurable queues selectable at SoC(System on Chip) integration. The
+  Message manager is broken up into different address regions that are
+  called "threads" or "proxies" - each instance is unidirectional and is
+  instantiated at SoC integration level by system controller to indicate
+  receive or transmit path.
+
+properties:
+  $nodename:
+    pattern: "^mailbox@[0-9a-f]+$"
+
+  compatible:
+    const: ti,am654-secure-proxy
+
+  "#mbox-cells":
+    const: 1
+    description:
+      Contains the secure proxy thread ID used for the specific transfer path.
+
+  reg-names:
+    items:
+      - const: target_data
+      - const: rt
+      - const: scfg
+
+  reg:
+    minItems: 3
+
+  interrupt-names:
+    minItems: 1
+    maxItems: 100
+    items:
+      pattern: "^rx_[0-9]{3}$"
+    description:
+      Contains the interrupt name information for the Rx interrupt path for
+      secure proxy thread in the form 'rx_<PID>'.
+
+  interrupts:
+    minItems: 1
+    maxItems: 100
+    description:
+      Contains the interrupt information for the Rx interrupt path for secure
+      proxy.
+
+required:
+  - compatible
+  - reg-names
+  - reg
+  - interrupt-names
+  - interrupts
+  - "#mbox-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    secure_proxy: mailbox at 32c00000 {
+          compatible = "ti,am654-secure-proxy";
+          #mbox-cells = <1>;
+          reg-names = "target_data", "rt", "scfg";
+          reg = <0x32c00000 0x100000>,
+                <0x32400000 0x100000>,
+                <0x32800000 0x100000>;
+          interrupt-names = "rx_011";
+          interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+    };
-- 
2.31.0



From nm at ti.com  Fri Apr 16 02:01:00 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 15 Apr 2021 20:01:00 -0500
Subject: [PATCH V2] dt-bindings: mailbox: ti, secure-proxy: Convert to yaml
In-Reply-To: <20210415211731.GA1892348@robh.at.kernel.org>
References: <20210413224535.30910-1-nm@ti.com>
 <20210415211731.GA1892348@robh.at.kernel.org>
Message-ID: <20210416010100.y3mbfzvx2i3x5dmz@curliness>

On 16:17-20210415, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> > new file mode 100644
> > index 000000000000..08a4837fdfcc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
[...]
> > +
> > +  interrupt-names:
> > +    minItems: 1
> > +    maxItems: 100
> > +    items:
> > +      - pattern: "^rx_[0-9]{3}$"
> 
> Need to drop the '-' to make this apply to all entries. Otherwise, it's 
> just the first one.

Aaah.. Thanks. done in v3[1]


[1] https://lore.kernel.org/r/20210416005953.17147-1-nm at ti.com
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From rentao.bupt at gmail.com  Fri Apr 16 02:04:45 2021
From: rentao.bupt at gmail.com (Tao Ren)
Date: Thu, 15 Apr 2021 18:04:45 -0700
Subject: [PATCH] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <469ac948-d65b-471f-102f-726466c19c5c@roeck-us.net>
References: <20210416001208.16788-1-rentao.bupt@gmail.com>
 <469ac948-d65b-471f-102f-726466c19c5c@roeck-us.net>
Message-ID: <20210416010444.GA17388@taoren-ubuntu-R90MNF91>

On Thu, Apr 15, 2021 at 05:50:32PM -0700, Guenter Roeck wrote:
> On 4/15/21 5:12 PM, rentao.bupt at gmail.com wrote:
> > From: Tao Ren <rentao.bupt at gmail.com>
> > 
> > Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> > handler to avoid potential integer overflow when the supplied timeout is
> > greater than aspeed's maximum allowed timeout (4294 seconds).
> > 
> > Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> > Reported-by: Amithash Prasad <amithash at fb.com>
> > Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
> > ---
> >  drivers/watchdog/aspeed_wdt.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> > index 7e00960651fa..9f77272dc906 100644
> > --- a/drivers/watchdog/aspeed_wdt.c
> > +++ b/drivers/watchdog/aspeed_wdt.c
> > @@ -145,9 +145,8 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
> >  	struct aspeed_wdt *wdt = to_aspeed_wdt(wdd);
> >  	u32 actual;
> >  
> > -	wdd->timeout = timeout;
> > -
> > -	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> > +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
> > +	wdd->timeout = actual;
> >  
> >  	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
> >  	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> > 
> 
> If the provided timeout is larger than the supported hardware timeout,
> the watchdog core will ping the hardware on behalf of userspace.
> The above code would defeat that mechanism for no good reason.
> 
> NACK.
> 
> Guenter

Thanks Guenter for Joel for the quick review!

The integer overflow happens at (actual * WDT_RATE_1MHZ). For example,
if a user tries to set timeout to 4295 seconds, then the hardware would
be programmed to timeout after about 32 milliseconds. I would say this
behavior is not expected?


Cheers,

Tao


From linux at roeck-us.net  Fri Apr 16 02:47:50 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 15 Apr 2021 18:47:50 -0700
Subject: [PATCH] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <20210416010444.GA17388@taoren-ubuntu-R90MNF91>
References: <20210416001208.16788-1-rentao.bupt@gmail.com>
 <469ac948-d65b-471f-102f-726466c19c5c@roeck-us.net>
 <20210416010444.GA17388@taoren-ubuntu-R90MNF91>
Message-ID: <20210416014750.GA53153@roeck-us.net>

On Thu, Apr 15, 2021 at 06:04:45PM -0700, Tao Ren wrote:
> On Thu, Apr 15, 2021 at 05:50:32PM -0700, Guenter Roeck wrote:
> > On 4/15/21 5:12 PM, rentao.bupt at gmail.com wrote:
> > > From: Tao Ren <rentao.bupt at gmail.com>
> > > 
> > > Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> > > handler to avoid potential integer overflow when the supplied timeout is
> > > greater than aspeed's maximum allowed timeout (4294 seconds).
> > > 
> > > Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> > > Reported-by: Amithash Prasad <amithash at fb.com>
> > > Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
> > > ---
> > >  drivers/watchdog/aspeed_wdt.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> > > index 7e00960651fa..9f77272dc906 100644
> > > --- a/drivers/watchdog/aspeed_wdt.c
> > > +++ b/drivers/watchdog/aspeed_wdt.c
> > > @@ -145,9 +145,8 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
> > >  	struct aspeed_wdt *wdt = to_aspeed_wdt(wdd);
> > >  	u32 actual;
> > >  
> > > -	wdd->timeout = timeout;
> > > -
> > > -	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> > > +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
> > > +	wdd->timeout = actual;
> > >  
> > >  	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
> > >  	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> > > 
> > 
> > If the provided timeout is larger than the supported hardware timeout,
> > the watchdog core will ping the hardware on behalf of userspace.
> > The above code would defeat that mechanism for no good reason.
> > 
> > NACK.
> > 
> > Guenter
> 
> Thanks Guenter for Joel for the quick review!
> 
> The integer overflow happens at (actual * WDT_RATE_1MHZ). For example,
> if a user tries to set timeout to 4295 seconds, then the hardware would
> be programmed to timeout after about 32 milliseconds. I would say this
> behavior is not expected?

The fix would be

-	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
+	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);

without modifying
	wdd->timeout = timeout;

The real problem here is that "wdd->max_hw_heartbeat_ms * 1000"
is simply wrong. The overflow is a side effect of the wrong
calculation, and concentrating on it disguises the real problem.

Guenter


From martin.petersen at oracle.com  Fri Apr 16 03:10:21 2021
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Thu, 15 Apr 2021 22:10:21 -0400
Subject: [PATCH v18 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <f111e363-c709-fe3c-65da-450c9e9e3408@acm.org> (Bart Van Assche's
 message of "Thu, 15 Apr 2021 16:11:23 -0700")
References: <cover.1618426513.git.asutoshd@codeaurora.org>
 <d1a6af736730b9d79f977100286c5d9325546ac2.1618426513.git.asutoshd@codeaurora.org>
 <f111e363-c709-fe3c-65da-450c9e9e3408@acm.org>
Message-ID: <yq11rbb0ynx.fsf@ca-mkp.ca.oracle.com>


Hi Bart!

> Patches sent to the SCSI mailing list should not have a "scsi: " prefix
> in the subject. That prefix is inserted before any SCSI patches go into
> Martin's tree.

This doesn't actually matter. My script will add the prefix if it's not
present.

-- 
Martin K. Petersen	Oracle Linux Engineering


From rentao.bupt at gmail.com  Fri Apr 16 03:13:37 2021
From: rentao.bupt at gmail.com (rentao.bupt at gmail.com)
Date: Thu, 15 Apr 2021 19:13:37 -0700
Subject: [PATCH v2] watchdog: aspeed: fix integer overflow in set_timeout
 handler
Message-ID: <20210416021337.18715-1-rentao.bupt@gmail.com>

From: Tao Ren <rentao.bupt at gmail.com>

Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
handler to avoid potential integer overflow when the supplied timeout is
greater than aspeed's maximum allowed timeout (4294 seconds).

Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad <amithash at fb.com>
Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
---
 Changes in v2:
   - do not touch "wdd->timeout": only "max_hw_heartbeat_ms * 1000" is
     updated to "max_hw_heartbeat_ms / 1000".

 drivers/watchdog/aspeed_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index 7e00960651fa..507fd815d767 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -147,7 +147,7 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
 
 	wdd->timeout = timeout;
 
-	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
+	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
 
 	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
 	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
-- 
2.17.1



From alex.kogan at oracle.com  Fri Apr 16 03:52:57 2021
From: alex.kogan at oracle.com (Alex Kogan)
Date: Thu, 15 Apr 2021 22:52:57 -0400
Subject: [External] : Re: [PATCH v14 4/6] locking/qspinlock: Introduce
 starvation avoidance into CNA
In-Reply-To: <YHWIezK9pbmbWxsu@hirez.programming.kicks-ass.net>
References: <20210401153156.1165900-1-alex.kogan@oracle.com>
 <20210401153156.1165900-5-alex.kogan@oracle.com>
 <YHWIezK9pbmbWxsu@hirez.programming.kicks-ass.net>
Message-ID: <02D4688A-FB4C-4100-8B85-C915F130BB99@oracle.com>



> On Apr 13, 2021, at 8:03 AM, Peter Zijlstra <peterz at infradead.org> wrote:
> 
> On Thu, Apr 01, 2021 at 11:31:54AM -0400, Alex Kogan wrote:
> 
>> @@ -49,13 +55,33 @@ struct cna_node {
>> 	u16			real_numa_node;
>> 	u32			encoded_tail;	/* self */
>> 	u32			partial_order;	/* enum val */
>> +	s32			start_time;
>> };
> 
>> +/*
>> + * Controls the threshold time in ms (default = 10) for intra-node lock
>> + * hand-offs before the NUMA-aware variant of spinlock is forced to be
>> + * passed to a thread on another NUMA node. The default setting can be
>> + * changed with the "numa_spinlock_threshold" boot option.
>> + */
>> +#define MSECS_TO_JIFFIES(m)	\
>> +	(((m) + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ))
>> +static int intra_node_handoff_threshold __ro_after_init = MSECS_TO_JIFFIES(10);
>> +
>> +static inline bool intra_node_threshold_reached(struct cna_node *cn)
>> +{
>> +	s32 current_time = (s32)jiffies;
>> +	s32 threshold = cn->start_time + intra_node_handoff_threshold;
>> +
>> +	return current_time - threshold > 0;
>> +}
> 
> None of this makes any sense:
> 
> - why do you track time elapsed as a signed entity?
> - why are you using jiffies; that's terrible granularity.
Good points. I will address that (see below). I will just mention that 
those suggestions came from senior folks on this mailing list,
and it seemed prudent to take their counsel. 

> 
> As Andi already said, 10ms is silly large. You've just inflated the
> lock-acquire time for every contended lock to stupid land just because
> NUMA.
I just ran a few quick tests ? local_clock() (a wrapper around sched_clock()) 
works well, so I will switch to using that.

I also took a few numbers with different thresholds. Looks like we can drop 
the threshold to 1ms with a minor penalty to performance. However, 
pushing the threshold to 100us has a more significant cost. Here are
the numbers for reference:

will-it-scale/lock2_threads:
threshold:                     10ms     1ms      100us
speedup at 142 threads:       2.184    1.974     1.1418 

will-it-scale/open1_threads:
threshold:                     10ms     1ms      100us
speedup at 142 threads:       2.146    1.974     1.291

Would you be more comfortable with setting the default at 1ms?

> And this also brings me to the whole premise of this series; *why* are
> we optimizing this? What locks are so contended that this actually helps
> and shouldn't you be spending your time breaking those locks? That would
> improve throughput more than this ever can.

I think for the same reason the kernel switched from ticket locks to queue locks
several years back. There always will be applications with contended locks. 
Sometimes the workarounds are easy, but many times they are not, like with 
legacy applications or when the workload is skewed (e.g., every client tries to
update the metadata of the same file protected by the same lock). The results
show that for those cases we leave > 2x performance on the table. Those are not
only our numbers ? LKP reports show similar or even better results, 
on a wide range of benchmarks, e.g.:
https://lists.01.org/hyperkitty/list/lkp at lists.01.org/thread/HGVOCYDEE5KTLYPTAFBD2RXDQOCDPFUJ/
https://lists.01.org/hyperkitty/list/lkp at lists.01.org/thread/OUPS7MZ3GJA2XYWM52GMU7H7EI25IT37/
https://lists.01.org/hyperkitty/list/lkp at lists.01.org/thread/DNMEQPXJRQY2IKHZ3ERGRY6TUPWDTFUN/

Regards,
? Alex



From masahiroy at kernel.org  Fri Apr 16 03:53:07 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Fri, 16 Apr 2021 11:53:07 +0900
Subject: [PATCH] clk: uniphier: Fix potential infinite loop
In-Reply-To: <20210415181850.GD6021@kadam>
References: <20210407152457.497346-1-colin.king@canonical.com>
 <CAK7LNAT+JTg5QYYbYqCm+m11X7CF_ZWyYRA4eAtqeTEuHRqoyw@mail.gmail.com>
 <20210415181850.GD6021@kadam>
Message-ID: <CAK7LNATySocPRr4BdaKr5_GZ=G4tQYgPQEDe0piiTS_qiWawkA@mail.gmail.com>

On Fri, Apr 16, 2021 at 3:19 AM Dan Carpenter <dan.carpenter at oracle.com> wrote:
>
> On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote:
> > On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king at canonical.com> wrote:
> > >
> > > From: Colin Ian King <colin.king at canonical.com>
> > >
> > > The for-loop iterates with a u8 loop counter i and compares this
> > > with the loop upper limit of num_parents that is an int type.
> > > There is a potential infinite loop if num_parents is larger than
> > > the u8 loop counter. Fix this by making the loop counter the same
> > > type as num_parents.
> > >
> > > Addresses-Coverity: ("Infinite loop")
> > > Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver")
> > > Signed-off-by: Colin Ian King <colin.king at canonical.com>
> > > ---
> > >  drivers/clk/uniphier/clk-uniphier-mux.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c
> > > index 462c84321b2d..ce219e0d2a85 100644
> > > --- a/drivers/clk/uniphier/clk-uniphier-mux.c
> > > +++ b/drivers/clk/uniphier/clk-uniphier-mux.c
> > > @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw)
> > >         int num_parents = clk_hw_get_num_parents(hw);
> > >         int ret;
> > >         unsigned int val;
> > > -       u8 i;
> > > +       int i;
> > >
> > >         ret = regmap_read(mux->regmap, mux->reg, &val);
> > >         if (ret)
> > > --
> > > 2.30.2
> > >
> >
> > clk_hw_get_num_parents() returns 'unsigned int', so
> > I think 'num_parents' should also have been 'unsigned int'.
> >
> > Maybe, the loop counter 'i' also should be 'unsigned int' then?
>
> The clk_hw_get_num_parents() function returns 0-255 so the original code
> works fine.

True.  clk->core->num_parents is u8,
but it is not clear just by looking at the
prototype of clk_hw_get_num_parents().

At least, it is not clear enough for tools,
and actually Coverity raised a flag.


Personally, I prefer 'unsigned int' (or 'int')
when I count the number of something.
Historically, the clk subsystem uses u8,
(maybe to save memory??), and there exists
distortion.

For example, the return type of
uniphier_clk_mux_get_parent() is u8,
but it actually returns -EINVAL for error cases.

So, u8 is not wide enough, in my opinion.



>
> It should basically always be "int i;"  That's the safest assumption.
> There are other case where it has to be size_t but in those cases I
> think people should call the list iterator something else instead of "i"
> like "size_t pg_idx;".
>
> Making everthing u32 causes more bugs than it prevents.  Signedness bugs
> with comparing to zero, type promotion bugs, or subtraction bugs where
> subtracting wraps to a high value.  It's rare to loop more than INT_MAX
> times in the kernel.  When we do need to count about 2 million then
> we're probably not going to stop counting at 4 million, we're going to
> go to 10 million or higher so size_t is more appropriate than u32.
>
> Btw, if you have a loop that does:
>
>         for (i = 0; i < UINT_MAX; i++) {
>
> that loop works exactly the same if "i" is an int or if it's a u32
> because of type promotion.

You are right.

Perhaps, in hindsight, the following were natural:


   unsigned int num_parents = clk_hw_get_num_parents(hw);
   ...
   int i;


I am fine with this if it is not too late.
But, Stephen has already picked up this patch.





>  So you have to look really hard to find a
> place where changing a loop iterator from int to u32 fixes bug in real
> life.
>
> regards,
> dan carpenter



-- 
Best Regards
Masahiro Yamada


From joel at jms.id.au  Fri Apr 16 03:55:17 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 16 Apr 2021 02:55:17 +0000
Subject: [PATCH] ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses
In-Reply-To: <20210415155300.1135-1-aladyshev22@gmail.com>
References: <20210415155300.1135-1-aladyshev22@gmail.com>
Message-ID: <CACPK8XedxKUpgtXCzsmdHw7-U+ySzHmvvb8mGE8QJcxQrEMayg@mail.gmail.com>

On Thu, 15 Apr 2021 at 15:53, Konstantin Aladyshev
<aladyshev22 at gmail.com> wrote:
>
> Enable all I2C busses that are used in AMD EthanolX CRB:
>  i2c0 - APML P0
>  i2c1 - APML P1
>  i2c2 - FPGA
>  i2c3 - 24LC128 EEPROM
>  i2c4 - P0 Power regulators
>  i2c5 - P1 Power regulators
>  i2c6 - P0/P1 Thermal diode
>  i2c7 - Thermal Sensors
>  i2c8 - BMC I2C
>
> Signed-off-by: Konstantin Aladyshev <aladyshev22 at gmail.com>

Thanks, applied.

> ---
>  arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts | 30 +++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> index ac2d04cfaf2f..6aeb47c44eba 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts
> @@ -151,6 +151,31 @@ &i2c1 {
>         status = "okay";
>  };
>
> +//FPGA
> +&i2c2 {
> +       status = "okay";
> +};
> +
> +//24LC128 EEPROM
> +&i2c3 {
> +       status = "okay";
> +};
> +
> +//P0 Power regulators
> +&i2c4 {
> +       status = "okay";
> +};
> +
> +//P1 Power regulators
> +&i2c5 {
> +       status = "okay";
> +};
> +
> +//P0/P1 Thermal diode
> +&i2c6 {
> +       status = "okay";
> +};
> +
>  // Thermal Sensors
>  &i2c7 {
>         status = "okay";
> @@ -196,6 +221,11 @@ lm75a at 4f {
>         };
>  };
>
> +//BMC I2C
> +&i2c8 {
> +       status = "okay";
> +};
> +
>  &kcs1 {
>         status = "okay";
>         aspeed,lpc-io-reg = <0x60>;
> --
> 2.25.1
>


From joel at jms.id.au  Fri Apr 16 03:56:21 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 16 Apr 2021 02:56:21 +0000
Subject: [PATCH] arm: dts: aspeed: tiogapass: add hotplug controller
In-Reply-To: <20210415140521.11352-1-fercerpav@gmail.com>
References: <20210415140521.11352-1-fercerpav@gmail.com>
Message-ID: <CACPK8Xft_59tCyYnMqx10ZcSnMFZjd1MWCEEr1XYcfX-zMcV=w@mail.gmail.com>

On Thu, 15 Apr 2021 at 14:05, Paul Fertser <fercerpav at gmail.com> wrote:
>
> The ADM1278 IC is accessible on I2C bus and on both Wiwynn and Quanta
> Tioga Pass implementations a pair of parallel 0.5 mOhm resistors is used
> for current measurement.
>
> Signed-off-by: Paul Fertser <fercerpav at gmail.com>

Thanks, applied.

> ---
>  arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> index 3cc2004fa2f2..500661956dea 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts
> @@ -591,6 +591,11 @@
>  &i2c7 {
>         status = "okay";
>         //HSC, AirMax Conn A
> +       adm1278 at 0x45 {
> +               compatible = "adm1275";
> +               reg = <0x45>;
> +               shunt-resistor-micro-ohms = <250>;
> +       };
>  };
>
>  &i2c8 {
> --
> 2.17.1
>


From flora.fu at mediatek.com  Fri Apr 16 04:01:10 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Fri, 16 Apr 2021 11:01:10 +0800
Subject: [PATCH 4/8] dt-bindings: arm: mediatek: Add new document
 bindings for APU
In-Reply-To: <CAL_JsqLKaYY=NHm1hD=YaQgvDOBTtraoUqcycA7tu7n-f2GVDw@mail.gmail.com>
References: <1617766086-5502-1-git-send-email-flora.fu@mediatek.com>
 <1617766086-5502-5-git-send-email-flora.fu@mediatek.com>
 <20210409182538.GA3913794@robh.at.kernel.org>
 <1618209895.25062.11.camel@mtksdccf07>
 <CAL_JsqLKaYY=NHm1hD=YaQgvDOBTtraoUqcycA7tu7n-f2GVDw@mail.gmail.com>
Message-ID: <1618542070.27491.15.camel@mtksdccf07>

On Thu, 2021-04-15 at 16:24 -0500, Rob Herring wrote:
> On Mon, Apr 12, 2021 at 1:45 AM Flora Fu <flora.fu at mediatek.com> wrote:
> >
> > On Fri, 2021-04-09 at 13:25 -0500, Rob Herring wrote:
> > > On Wed, Apr 07, 2021 at 11:28:02AM +0800, Flora Fu wrote:
> > > > Document the apusys bindings.
> > > >
> > > > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > > > ---
> > > >  .../arm/mediatek/mediatek,apusys.yaml         | 56 +++++++++++++++++++
> > > >  1 file changed, 56 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > > new file mode 100644
> > > > index 000000000000..dc04a46f1bad
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apusys.yaml
> > > > @@ -0,0 +1,56 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/arm/mediatek/mediatek,apusys.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrAYYvZWcw$
> > > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!3ryKFTA2CvsVss4Pt2ZOG7wv4jgR-2LPxuGn30IxFmpxoxSRdzNdf8FrARlhCQ0w$
> > > > +
> > > > +title: MediaTek APUSYS Controller
> > > > +
> > > > +maintainers:
> > > > +  - Flora Fu <flora.fu at mediatek.com>
> > > > +
> > > > +description:
> > > > +  The Mediatek apusys controller provides functional configurations and clocks
> > > > +  to the system.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    items:
> > > > +      - enum:
> > > > +          - mediatek,mt8192-apu_mbox
> > > > +          - mediatek,mt8192-apu_conn
> > > > +          - mediatek,mt8192-apu_vcore
> > >
> > > s/_/-/
> > >
> >
> > OK. I will update expression strings in the next version.
> >
> > > > +      - const: syscon
> > > > +
> > > > +  reg:
> > > > +    maxItems: 1
> > > > +
> > > > +  '#clock-cells':
> > > > +    const: 1
> > > > +
> > > > +required:
> > > > +  - compatible
> > > > +  - reg
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > +  - |
> > > > +    apu_mbox: apu_mbox at 19000000 {
> > >
> > > mailbox at ...? Is this a mailbox provider?
> > >
> >
> > Yes, the apu_mbox is the for setup mailbox in the APU hardware.
> 
> Then you need #mbox-cells here.
> 
> And in that case, what makes it a syscon?
> 
The apu_mbox are registers for setup mail box communications between apu
processor and the AP side kernel drivers. It also has spare registers
that reserved for keep specific information between apu and AP side.
That's why I set it as syscon to avoid ioremap from users. Do you think
it is reasonable or it is better to be kept inside the user nodes when
using it?

> >
> > > > +        compatible = "mediatek,mt8192-apu_mbox", "syscon";
> > > > +        reg = <0x19000000 0x1000>;
> > > > +    };


From joel at jms.id.au  Fri Apr 16 04:03:25 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 16 Apr 2021 03:03:25 +0000
Subject: [PATCH v1] ARM: dts: Fix 64MiB OpenBMC flash layout and
 aspeed-ast2600-evb.dts
In-Reply-To: <20210316085932.2601-1-troy_lee@aspeedtech.com>
References: <20210316085932.2601-1-troy_lee@aspeedtech.com>
Message-ID: <CACPK8XeYtaLLWDMR8xZhERrQ_WCUJ2RM_JZmZNQ6oZSvgSDM_w@mail.gmail.com>

On Tue, 16 Mar 2021 at 08:59, Troy Lee <troy_lee at aspeedtech.com> wrote:
>
> Aspeed AST2600 u-boot requires 600KiB+ flash space. Sharing the same
> openbmc-flash-layout-64.dtsi requires to resize the flash partition.
>
> The updated flash layout as follows:
> - u-boot: 896 KiB
> - u-boot-env: 128 KiB
> - kernel: 9MiB
> - rofs: 32 MiB
> - rwfs: 22 MiB

Changing the 64MB layout will break the systems that are already using
this layout. I'll get the Bytedance people to chime in, as theirs is
the only system using this layout so far.

John, Lei?

>
> Signed-off-by: Troy Lee <troy_lee at aspeedtech.com>
> ---
>  arch/arm/boot/dts/aspeed-ast2600-evb.dts      | 32 +------------------
>  .../arm/boot/dts/openbmc-flash-layout-64.dtsi | 18 +++++------
>  2 files changed, 10 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> index 89be13197780..2cfae9cfed3a 100644
> --- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -121,37 +121,7 @@ flash at 0 {
>                 m25p,fast-read;
>                 label = "bmc";
>                 spi-max-frequency = <50000000>;
> -
> -               partitions {
> -                       compatible = "fixed-partitions";
> -                       #address-cells = <1>;
> -                       #size-cells = <1>;
> -
> -                       u-boot at 0 {
> -                               reg = <0x0 0xe0000>; // 896KB
> -                               label = "u-boot";
> -                       };
> -
> -                       u-boot-env at e0000 {
> -                               reg = <0xe0000 0x20000>; // 128KB
> -                               label = "u-boot-env";
> -                       };
> -
> -                       kernel at 100000 {
> -                               reg = <0x100000 0x900000>; // 9MB
> -                               label = "kernel";
> -                       };
> -
> -                       rofs at a00000 {
> -                               reg = <0xa00000 0x2000000>; // 32MB
> -                               label = "rofs";
> -                       };
> -
> -                       rwfs at 6000000 {
> -                               reg = <0x2a00000 0x1600000>; // 22MB
> -                               label = "rwfs";
> -                       };
> -               };
> +#include "openbmc-flash-layout-64.dtsi"
>         };
>  };
>
> diff --git a/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi b/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> index 91163867be34..31f59de5190b 100644
> --- a/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> +++ b/arch/arm/boot/dts/openbmc-flash-layout-64.dtsi
> @@ -9,27 +9,27 @@ partitions {
>         #size-cells = <1>;
>
>         u-boot at 0 {
> -               reg = <0x0 0x60000>; // 384KB
> +               reg = <0x0 0xe0000>; // 896KB
>                 label = "u-boot";
>         };
>
> -       u-boot-env at 60000 {
> -               reg = <0x60000 0x20000>; // 128KB
> +       u-boot-env at e0000 {
> +               reg = <0xe0000 0x20000>; // 128KB
>                 label = "u-boot-env";
>         };
>
> -       kernel at 80000 {
> -               reg = <0x80000 0x500000>; // 5MB
> +       kernel at 100000 {
> +               reg = <0x100000 0x900000>; // 9MB
>                 label = "kernel";
>         };
>
> -       rofs at 580000 {
> -               reg = <0x580000 0x2a80000>; // 42.5MB
> +       rofs at a00000 {
> +               reg = <0xa00000 0x2000000>; // 32MB
>                 label = "rofs";
>         };
>
> -       rwfs at 3000000 {
> -               reg = <0x3000000 0x1000000>; // 16MB
> +       rwfs at 6000000 {
> +               reg = <0x2a00000 0x1600000>; // 22MB
>                 label = "rwfs";
>         };
>  };
> --
> 2.25.1
>


From joel at jms.id.au  Fri Apr 16 04:27:31 2021
From: joel at jms.id.au (Joel Stanley)
Date: Fri, 16 Apr 2021 03:27:31 +0000
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13, v2
Message-ID: <CACPK8Xeet50bqWAY0jG_GRkgvKvFn94XtGDaq1gaVYVkyV_JUQ@mail.gmail.com>

Hello Soc maintainers,

Here are some fixes for the changes that have already been merged for v5.13.

I also merged some changes that came in later. If you would prefer to
not take them then I can send a pull with just the fixes.

The following changes since commit f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:

  ARM: dts: aspeed: tiogapass: add hotplug controller (2021-04-16
12:28:38 +0930)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc.git
tags/bmc-5.13-devicetree-2

for you to fetch changes up to f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:

  ARM: dts: aspeed: tiogapass: add hotplug controller (2021-04-16
12:28:38 +0930)

----------------------------------------------------------------
BMC device tree updates for 5.13, round two

 - Fixes to the first pull request for Rainier

 - Small changes for Rainier, EthanolX and Tiogapass

----------------------------------------------------------------
Eddie James (4):
      ARM: dts: aspeed: Rainier: Fix PCA9552 on bus 8
      ARM: dts: aspeed: Rainier: Fix humidity sensor bus address
      ARM: dts: aspeed: Rainier 1S4U: Fix fan nodes
      ARM: dts: aspeed: Rainier: Update to pass 2 hardware

Konstantin Aladyshev (1):
      ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses

Paul Fertser (1):
      ARM: dts: aspeed: tiogapass: add hotplug controller


From zhuguangqing83 at gmail.com  Fri Apr 16 04:47:12 2021
From: zhuguangqing83 at gmail.com (zhuguangqing83 at gmail.com)
Date: Fri, 16 Apr 2021 11:47:12 +0800
Subject: [PATCH] regulator: mt6360: Fix missing IRQF_ONESHOT as only threaded
 handler
Message-ID: <20210416034712.7891-1-zhuguangqing83@gmail.com>

From: Guangqing Zhu <zhuguangqing83 at gmail.com>

Coccinelle noticed:
drivers/regulator/mt6360-regulator.c:386:8-33: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT

Signed-off-by: Guangqing Zhu <zhuguangqing83 at gmail.com>
---
 drivers/regulator/mt6360-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/mt6360-regulator.c b/drivers/regulator/mt6360-regulator.c
index 4d34be94d166..34c354721ef0 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -383,8 +383,8 @@ static int mt6360_regulator_irq_register(struct platform_device *pdev,
 		if (irq < 0)
 			return irq;
 
-		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, irq_desc->handler, 0,
-						irq_desc->name, rdev);
+		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, irq_desc->handler,
+						IRQF_ONESHOT, irq_desc->name, rdev);
 		if (ret) {
 			dev_err(&pdev->dev, "Fail to request %s irq\n", irq_desc->name);
 			return ret;
-- 
2.17.1



From flora.fu at mediatek.com  Fri Apr 16 04:54:07 2021
From: flora.fu at mediatek.com (Flora Fu)
Date: Fri, 16 Apr 2021 11:54:07 +0800
Subject: [PATCH v2 4/7] dt-bindings: soc: mediatek: apusys: Add new
 document for APU power domain
In-Reply-To: <20210415152500.GA1424680@robh.at.kernel.org>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
 <1618465960-3013-5-git-send-email-flora.fu@mediatek.com>
 <20210415152500.GA1424680@robh.at.kernel.org>
Message-ID: <1618545247.1478.21.camel@mtksdccf07>

On Thu, 2021-04-15 at 10:25 -0500, Rob Herring wrote:
> On Thu, Apr 15, 2021 at 01:52:37PM +0800, Flora Fu wrote:
> > Document the bindings for APU power domain on MediaTek SoC.
> > 
> > Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> > ---
> > Note:
> > This patch depends on MT8192 clock[1] patches which haven't yet been accepted.
> > [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20210324104110.13383-7-chun-jie.chen at mediatek.com/__;!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmFz2gPbBV$ 
> > ---
> >  .../soc/mediatek/mediatek,apu-pm.yaml         | 145 ++++++++++++++++++
> >  1 file changed, 145 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > new file mode 100644
> > index 000000000000..6ff966920917
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,apu-pm.yaml
> > @@ -0,0 +1,145 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: https://urldefense.com/v3/__http://devicetree.org/schemas/soc/mediatek/mediatek,apu-pm.yaml*__;Iw!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmF_yHpQUx$ 
> > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zINTC3jweo4_C2yxqf9kHaxAXhO-k-I_JplIY4OQ390IeSfk5QCR4ojmFy1L2FzU$ 
> > +
> > +title: Mediatek APU Power Domains
> > +
> > +maintainers:
> > +  - Flora Fu <flora.fu at mediatek.com>
> > +
> > +description: |
> > +  Mediatek AI Process Unit (APU) include support for power domains which can be
> > +  powered up/down by software.
> > +  APU subsys belonging to a power domain should contain a 'power-domains'
> > +  property that is a phandle for apuspm node representing the domain.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - mediatek,mt8192-apu-pm
> > +      - const: syscon
> > +
> > +  reg:
> > +    description: Address range of the APU power domain controller.
> > +    maxItems: 1
> > +
> > +  '#address-cells':
> > +    const: 1
> > +
> > +  '#size-cells':
> > +    const: 0
> > +
> > +  '#power-domain-cells':
> > +    const: 1
> > +
> > +  vsram-supply:
> > +    description: apu sram regulator supply.
> > +
> > +  mediatek,scpsys:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: |
> > +      phandle to the device containing the scpsys register range.
> > +
> > +  mediatek,apu-conn:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: |
> > +      phandle to the device containing the scpsys apu conn register range.
> > +
> > +  mediatek,apu-conn1:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: |
> > +      phandle to the device containing the scpsys apu conn1 register range.
> > +
> > +  mediatek,apu-vcore:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description: |
> > +      phandle to the device containing the scpsys apu vcore register range.
> > +
> > +patternProperties:
> > +  "^power-domain@[0-9a-f]+$":
> > +    type: object
> > +    description: |
> > +      Represents the power domains within the power controller node as
> > +      documented in Documentation/devicetree/bindings/power/power-domain.yaml.
> > +
> > +    properties:
> > +      reg:
> > +        description: |
> > +          Power domain index. Valid values are defined in:
> > +          "include/dt-bindings/power/mt8182-apu-power.h"
> > +        maxItems: 1
> > +
> > +      '#power-domain-cells':
> > +        description: |
> > +          Must be 0 for nodes representing a single PM domain and 1 for nodes
> > +          providing multiple PM.
> > +
> > +      clocks:
> > +        description: |
> > +          List of phandles of clocks list. Specify by order according to
> > +          power-up sequence.
> > +
> > +      clock-names:
> > +        description: |
> > +          List of names of clocks. Specify by order according to power-up
> > +          sequence.
> > +
> > +      assigned-clocks:
> > +        maxItems: 2
> > +
> > +      assigned-clock-parents:
> > +        maxItems: 2
> > +
> > +      domain-supply:
> > +        description: domain regulator supply.
> > +
> > +    required:
> > +      - reg
> > +      - '#power-domain-cells'
> > +
> > +    additionalProperties: false
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - '#power-domain-cells'
> > +  - vsram-supply
> > +  - mediatek,scpsys
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/mt8192-clk.h>
> > +    apuspm: power-domain at 190f0000 {
> > +        compatible = "mediatek,mt8192-apu-pm", "syscon";
> > +        reg = <0x190f0000 0x1000>;
> > +        #address-cells = <1>;
> > +        #size-cells = <0>;
> > +        #power-domain-cells = <1>;
> 
> So you have domains provided by this node and then...
> 
> > +        vsram-supply = <&mt6359_vsram_md_ldo_reg>;
> > +        mediatek,scpsys = <&scpsys>;
> > +        mediatek,apu-conn = <&apu_conn>;
> > +        mediatek,apu-vcore = <&apu_vcore>;
> > +
> > +        apu_top: power-domain at 0 {
> > +            reg = <0>;
> > +            #power-domain-cells = <0>;
> 
> ...each child node provides a domain. What's the difference?

The hardware @190f0000 have controller for several child power domains
in apu subsys and now only one domain (apu_top) is exposed to mt8192
kernel. For the software extension purpose, the driver parses child
nodes even if it has only one child. In previous v1 patch, I add a
domain id index in a header file but it seems not necessary to create a
standalone file for the case. So I just set the index in the device tree
but keep dts structure to present hardware design.

> 
> > +            clocks = <&topckgen CLK_TOP_DSP_SEL>,
> > +                     <&topckgen CLK_TOP_IPU_IF_SEL>,
> > +                     <&clk26m>,
> > +                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
> > +            clock-names = "clk_top_conn",
> > +                          "clk_top_ipu_if",
> > +                          "clk_off",
> > +                          "clk_on_default";
> > +            assigned-clocks = <&topckgen CLK_TOP_DSP_SEL>,
> > +                              <&topckgen CLK_TOP_IPU_IF_SEL>;
> > +            assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D6_D2>,
> > +                                     <&topckgen CLK_TOP_UNIVPLL_D6_D2>;
> > +            domain-supply = <&mt6359_vproc1_buck_reg>;
> > +        };
> > +    };
> > -- 
> > 2.18.0
> > 


From danielwa at cisco.com  Fri Apr 16 05:09:11 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Thu, 15 Apr 2021 21:09:11 -0700
Subject: [PATCH 0/8] generic command line v4
Message-ID: <20210416040924.2882771-1-danielwa@cisco.com>


v4 release changes

* Updated insert-sys-cert tool to change command line symbols after
  compilation.

	This tool is used to release binary kernels internally to companies
	and then later insert certificates for each product by consumers of
	the binary kernel. Cisco uses this tool for this purpose.

	Cisco has a similar need for the command line to be modified on a
	binary released kernels similar to how certificates are setup.

* Added global symbols to hold append and prepend values.

	These changes follow the system certificate code to allow the
	insert-sys-cert tool to be used.

* Added a test case to confirm functionality.

	Seemed sensible to add this to make sure everything is working.

* Dropped powerpc changes

	Christophe Leroy has reservations about the features for powerpc. I
	don't think his reservations are founded, and these changes should
	fully work on powerpc. However, I dropped these changes so Christophe
	can have more time to get comfortable with the changes.


Enjoy!


Daniel Walker (8):
  CMDLINE: add generic builtin command line
  scripts: insert-sys-cert: add command line insert capability
  scripts: insert-sys-cert: change name to insert-symbol
  CMDLINE: mips: convert to generic builtin command line
  drivers: firmware: efi: libstub: enable generic commandline
  CMDLINE: x86: convert to generic builtin command line
  of: allow sending a NULL value to early_init_dt_scan_chosen
  CMDLINE: arm64: convert to generic builtin command line

 arch/arm64/Kconfig                            |  33 +--
 arch/arm64/include/asm/setup.h                |   2 +
 arch/arm64/kernel/idreg-override.c            |   9 +-
 arch/mips/Kconfig                             |   4 +-
 arch/mips/Kconfig.debug                       |  44 ----
 arch/mips/configs/ar7_defconfig               |   9 +-
 arch/mips/configs/bcm47xx_defconfig           |   8 +-
 arch/mips/configs/bcm63xx_defconfig           |  15 +-
 arch/mips/configs/bmips_be_defconfig          |  11 +-
 arch/mips/configs/bmips_stb_defconfig         |  11 +-
 arch/mips/configs/capcella_defconfig          |  11 +-
 arch/mips/configs/ci20_defconfig              |  10 +-
 arch/mips/configs/cu1000-neo_defconfig        |  10 +-
 arch/mips/configs/cu1830-neo_defconfig        |  10 +-
 arch/mips/configs/e55_defconfig               |   4 +-
 arch/mips/configs/generic_defconfig           |   6 +-
 arch/mips/configs/gpr_defconfig               |  18 +-
 arch/mips/configs/loongson3_defconfig         |  13 +-
 arch/mips/configs/mpc30x_defconfig            |   7 +-
 arch/mips/configs/tb0219_defconfig            |   7 +-
 arch/mips/configs/tb0226_defconfig            |   7 +-
 arch/mips/configs/tb0287_defconfig            |   7 +-
 arch/mips/configs/workpad_defconfig           |  11 +-
 arch/mips/include/asm/setup.h                 |   2 +
 arch/mips/kernel/relocate.c                   |  17 +-
 arch/mips/kernel/setup.c                      |  36 +--
 arch/mips/pic32/pic32mzda/early_console.c     |   2 +-
 arch/mips/pic32/pic32mzda/init.c              |   3 +-
 arch/x86/Kconfig                              |  44 +---
 arch/x86/kernel/setup.c                       |  18 +-
 .../firmware/efi/libstub/efi-stub-helper.c    |  29 +++
 drivers/firmware/efi/libstub/efi-stub.c       |   9 +
 drivers/firmware/efi/libstub/efistub.h        |   1 +
 drivers/firmware/efi/libstub/x86-stub.c       |  13 +-
 drivers/of/fdt.c                              |  44 ++--
 include/linux/cmdline.h                       | 103 ++++++++
 init/Kconfig                                  |  78 ++++++
 lib/Kconfig                                   |   4 +
 lib/Makefile                                  |   3 +
 lib/generic_cmdline.S                         |  53 ++++
 lib/test_cmdline1.c                           | 139 ++++++++++
 scripts/Makefile                              |   2 +-
 .../{insert-sys-cert.c => insert-symbol.c}    | 243 ++++++++++++------
 43 files changed, 716 insertions(+), 394 deletions(-)
 create mode 100644 include/linux/cmdline.h
 create mode 100644 lib/generic_cmdline.S
 create mode 100644 lib/test_cmdline1.c
 rename scripts/{insert-sys-cert.c => insert-symbol.c} (72%)

-- 
2.25.1



From danielwa at cisco.com  Fri Apr 16 05:09:15 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Thu, 15 Apr 2021 21:09:15 -0700
Subject: [PATCH 4/8] CMDLINE: mips: convert to generic builtin command line
In-Reply-To: <20210416040924.2882771-1-danielwa@cisco.com>
References: <20210416040924.2882771-1-danielwa@cisco.com>
Message-ID: <20210416040924.2882771-5-danielwa@cisco.com>

This updates the mips code to use the CONFIG_GENERIC_CMDLINE
option.

This deletes the option for MIPS_CMDLINE_BUILTIN_EXTEND
and replaces the functionality with generic code.

Of note, the pic32 has some strange handling of the current built
in command line. It was converted to use the static variant which
can't be updated after compilation. It should eventually be updated
to use to append and prepend symbols.

This includes a scripted mass convert of the config files to use
the new generic cmdline. There is a bit of a trim effect here.
It would seems that some of the config haven't been trimmed in
a while.

The script used is as follows,

if [[ -z "$1" || -z "$2" ]]; then
        echo "Two arguments are needed."
        exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
make ARCH=$1 O=$1 olddefconfig
make ARCH=$1 O=$1 savedefconfig
cp $1/defconfig $2
rm -Rf $1

Cc: xe-linux-external at cisco.com
Signed-off-by: Ruslan Ruslichenko <rruslich at cisco.com>
Signed-off-by: Ruslan Bilovol <rbilovol at cisco.com>
Signed-off-by: Daniel Walker <danielwa at cisco.com>
---
 arch/mips/Kconfig                         |  4 +--
 arch/mips/Kconfig.debug                   | 44 -----------------------
 arch/mips/configs/ar7_defconfig           |  9 ++---
 arch/mips/configs/bcm47xx_defconfig       |  8 ++---
 arch/mips/configs/bcm63xx_defconfig       | 15 +++-----
 arch/mips/configs/bmips_be_defconfig      | 11 +++---
 arch/mips/configs/bmips_stb_defconfig     | 11 +++---
 arch/mips/configs/capcella_defconfig      | 11 ++----
 arch/mips/configs/ci20_defconfig          | 10 +++---
 arch/mips/configs/cu1000-neo_defconfig    | 10 +++---
 arch/mips/configs/cu1830-neo_defconfig    | 10 +++---
 arch/mips/configs/e55_defconfig           |  4 +--
 arch/mips/configs/generic_defconfig       |  6 ++--
 arch/mips/configs/gpr_defconfig           | 18 ++--------
 arch/mips/configs/loongson3_defconfig     | 13 ++-----
 arch/mips/configs/mpc30x_defconfig        |  7 ++--
 arch/mips/configs/tb0219_defconfig        |  7 ++--
 arch/mips/configs/tb0226_defconfig        |  7 ++--
 arch/mips/configs/tb0287_defconfig        |  7 ++--
 arch/mips/configs/workpad_defconfig       | 11 +++---
 arch/mips/include/asm/setup.h             |  2 ++
 arch/mips/kernel/relocate.c               | 17 +++++++--
 arch/mips/kernel/setup.c                  | 36 +++----------------
 arch/mips/pic32/pic32mzda/early_console.c |  2 +-
 arch/mips/pic32/pic32mzda/init.c          |  3 +-
 25 files changed, 78 insertions(+), 205 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..0e753894d28d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
 	select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
 	select CPU_PM if CPU_IDLE
 	select GENERIC_ATOMIC64 if !64BIT
+	select GENERIC_CMDLINE
 	select GENERIC_CMOS_UPDATE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_GETTIMEOFDAY
@@ -3212,9 +3213,6 @@ choice
 	config MIPS_CMDLINE_FROM_BOOTLOADER
 		bool "Bootloader kernel arguments if available"
 
-	config MIPS_CMDLINE_BUILTIN_EXTEND
-		depends on CMDLINE_BOOL
-		bool "Extend builtin kernel arguments with bootloader arguments"
 endchoice
 
 endmenu
diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 7a8d94cdd493..b5a099c74eb6 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -30,50 +30,6 @@ config EARLY_PRINTK_8250
 config USE_GENERIC_EARLY_PRINTK_8250
 	bool
 
-config CMDLINE_BOOL
-	bool "Built-in kernel command line"
-	help
-	  For most systems, it is firmware or second stage bootloader that
-	  by default specifies the kernel command line options.  However,
-	  it might be necessary or advantageous to either override the
-	  default kernel command line or add a few extra options to it.
-	  For such cases, this option allows you to hardcode your own
-	  command line options directly into the kernel.  For that, you
-	  should choose 'Y' here, and fill in the extra boot arguments
-	  in CONFIG_CMDLINE.
-
-	  The built-in options will be concatenated to the default command
-	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
-	  command line will be ignored and replaced by the built-in string.
-
-	  Most MIPS systems will normally expect 'N' here and rely upon
-	  the command line from the firmware or the second-stage bootloader.
-
-config CMDLINE
-	string "Default kernel command string"
-	depends on CMDLINE_BOOL
-	help
-	  On some platforms, there is currently no way for the boot loader to
-	  pass arguments to the kernel.  For these platforms, and for the cases
-	  when you want to add some extra options to the command line or ignore
-	  the default command line, you can supply some command-line options at
-	  build time by entering them here.  In other cases you can specify
-	  kernel args so that you don't have to set them up in board prom
-	  initialization routines.
-
-	  For more information, see the CMDLINE_BOOL and CMDLINE_OVERRIDE
-	  options.
-
-config CMDLINE_OVERRIDE
-	bool "Built-in command line overrides firmware arguments"
-	depends on CMDLINE_BOOL
-	help
-	  By setting this option to 'Y' you will have your kernel ignore
-	  command line arguments from firmware or second stage bootloader.
-	  Instead, the built-in command line will be used exclusively.
-
-	  Normally, you will choose 'N' here.
-
 config SB1XXX_CORELIS
 	bool "Corelis Debugger"
 	depends on SIBYTE_SB1xxx_SOC
diff --git a/arch/mips/configs/ar7_defconfig b/arch/mips/configs/ar7_defconfig
index cf9c6329b807..c09470aa672f 100644
--- a/arch/mips/configs/ar7_defconfig
+++ b/arch/mips/configs/ar7_defconfig
@@ -12,6 +12,8 @@ CONFIG_EXPERT=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="rootfstype=squashfs,jffs2"
 CONFIG_AR7=y
 CONFIG_HZ_100=y
 CONFIG_KEXEC=y
@@ -32,9 +34,6 @@ CONFIG_IP_ROUTE_MULTIPATH=y
 CONFIG_IP_ROUTE_VERBOSE=y
 CONFIG_IP_MROUTE=y
 CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
 CONFIG_TCP_CONG_ADVANCED=y
 # CONFIG_TCP_CONG_BIC is not set
@@ -43,7 +42,6 @@ CONFIG_TCP_CONG_WESTWOOD=y
 # CONFIG_TCP_CONG_HTCP is not set
 # CONFIG_IPV6 is not set
 CONFIG_NETFILTER=y
-# CONFIG_BRIDGE_NETFILTER is not set
 CONFIG_NF_CONNTRACK=m
 CONFIG_NF_CONNTRACK_MARK=y
 CONFIG_NF_CONNTRACK_FTP=m
@@ -117,8 +115,5 @@ CONFIG_JFFS2_SUMMARY=y
 CONFIG_JFFS2_COMPRESSION_OPTIONS=y
 CONFIG_SQUASHFS=y
 # CONFIG_CRYPTO_HW is not set
-# CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_STRIP_ASM_SYMS=y
 CONFIG_DEBUG_FS=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="rootfstype=squashfs,jffs2"
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index 91ce75edbfb4..69a965bb2dd9 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -4,8 +4,9 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_EMBEDDED=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="console=ttyS0,115200"
 CONFIG_BCM47XX=y
-CONFIG_PCI=y
 # CONFIG_SUSPEND is not set
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
@@ -32,6 +33,7 @@ CONFIG_NET_SCH_FQ_CODEL=y
 CONFIG_HAMRADIO=y
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
+CONFIG_PCI=y
 CONFIG_MTD=y
 CONFIG_MTD_BCM47XX_PARTS=y
 CONFIG_MTD_BLOCK=y
@@ -75,7 +77,5 @@ CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_INFO=y
 CONFIG_DEBUG_INFO_REDUCED=y
 CONFIG_STRIP_ASM_SYMS=y
-CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=ttyS0,115200"
+CONFIG_DEBUG_FS=y
diff --git a/arch/mips/configs/bcm63xx_defconfig b/arch/mips/configs/bcm63xx_defconfig
index 861f680184b9..6791e48b2d7d 100644
--- a/arch/mips/configs/bcm63xx_defconfig
+++ b/arch/mips/configs/bcm63xx_defconfig
@@ -11,27 +11,26 @@ CONFIG_EXPERT=y
 # CONFIG_AIO is not set
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_SLUB_DEBUG is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="console=ttyS0,115200"
 CONFIG_BCM63XX=y
 CONFIG_BCM63XX_CPU_6338=y
 CONFIG_BCM63XX_CPU_6345=y
 CONFIG_BCM63XX_CPU_6348=y
 CONFIG_BCM63XX_CPU_6358=y
 # CONFIG_SECCOMP is not set
-CONFIG_PCI=y
-CONFIG_PCCARD=y
-CONFIG_PCMCIA_BCM63XX=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_NET=y
 CONFIG_UNIX=y
 CONFIG_INET=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
 # CONFIG_IPV6 is not set
 CONFIG_CFG80211=y
 CONFIG_NL80211_TESTMODE=y
 CONFIG_MAC80211=y
+CONFIG_PCI=y
+CONFIG_PCCARD=y
+CONFIG_PCMCIA_BCM63XX=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 CONFIG_MTD=y
@@ -50,8 +49,6 @@ CONFIG_B43=y
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
 # CONFIG_UNIX98_PTYS is not set
-CONFIG_SERIAL_BCM63XX=y
-CONFIG_SERIAL_BCM63XX_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
 # CONFIG_VGA_ARB is not set
@@ -65,5 +62,3 @@ CONFIG_PROC_KCORE=y
 # CONFIG_NETWORK_FILESYSTEMS is not set
 # CONFIG_CRYPTO_HW is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=ttyS0,115200"
diff --git a/arch/mips/configs/bmips_be_defconfig b/arch/mips/configs/bmips_be_defconfig
index 032bb51defe8..ae1c4adf8d98 100644
--- a/arch/mips/configs/bmips_be_defconfig
+++ b/arch/mips/configs/bmips_be_defconfig
@@ -5,21 +5,20 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_SLUB_DEBUG is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon"
 CONFIG_BMIPS_GENERIC=y
 CONFIG_HIGHMEM=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=4
-# CONFIG_SECCOMP is not set
 CONFIG_MIPS_O32_FP64_SUPPORT=y
+# CONFIG_SECCOMP is not set
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_PACKET_DIAG=y
 CONFIG_UNIX=y
 CONFIG_INET=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
 CONFIG_CFG80211=y
 CONFIG_NL80211_TESTMODE=y
@@ -73,7 +72,5 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 # CONFIG_CRYPTO_HW is not set
 CONFIG_PRINTK_TIME=y
-CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon"
+CONFIG_DEBUG_FS=y
diff --git a/arch/mips/configs/bmips_stb_defconfig b/arch/mips/configs/bmips_stb_defconfig
index 625bd2d7e685..cb3b114b10d0 100644
--- a/arch/mips/configs/bmips_stb_defconfig
+++ b/arch/mips/configs/bmips_stb_defconfig
@@ -5,12 +5,13 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_SLUB_DEBUG is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon"
 CONFIG_BMIPS_GENERIC=y
 CONFIG_CPU_LITTLE_ENDIAN=y
 CONFIG_HIGHMEM=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=4
-# CONFIG_SECCOMP is not set
 CONFIG_MIPS_O32_FP64_SUPPORT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT=y
@@ -20,15 +21,13 @@ CONFIG_CPU_FREQ_GOV_ONDEMAND=y
 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
 CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
 CONFIG_BMIPS_CPUFREQ=y
+# CONFIG_SECCOMP is not set
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_PACKET_DIAG=y
 CONFIG_UNIX=y
 CONFIG_INET=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
 CONFIG_CFG80211=y
 CONFIG_NL80211_TESTMODE=y
@@ -84,7 +83,5 @@ CONFIG_NLS_ASCII=y
 CONFIG_NLS_ISO8859_1=y
 # CONFIG_CRYPTO_HW is not set
 CONFIG_PRINTK_TIME=y
-CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon"
+CONFIG_DEBUG_FS=y
diff --git a/arch/mips/configs/capcella_defconfig b/arch/mips/configs/capcella_defconfig
index 7bf8971af53b..a8b87cccfade 100644
--- a/arch/mips/configs/capcella_defconfig
+++ b/arch/mips/configs/capcella_defconfig
@@ -2,6 +2,8 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="mem=32M console=ttyVR0,38400"
 CONFIG_MACH_VR41XX=y
 CONFIG_ZAO_CAPCELLA=y
 CONFIG_MODULES=y
@@ -20,9 +22,6 @@ CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_BOOTP=y
-CONFIG_INET_XFRM_MODE_TRANSPORT=m
-CONFIG_INET_XFRM_MODE_TUNNEL=m
-CONFIG_INET_XFRM_MODE_BEET=m
 CONFIG_TCP_MD5SIG=y
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
@@ -73,19 +72,13 @@ CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_TGR192=m
 CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_ARC4=m
 CONFIG_CRYPTO_BLOWFISH=m
 CONFIG_CRYPTO_CAMELLIA=m
 CONFIG_CRYPTO_CAST5=m
 CONFIG_CRYPTO_CAST6=m
 CONFIG_CRYPTO_DES=m
 CONFIG_CRYPTO_FCRYPT=m
-CONFIG_CRYPTO_KHAZAD=m
 CONFIG_CRYPTO_SERPENT=m
-CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_DEFLATE=m
 # CONFIG_CRYPTO_HW is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="mem=32M console=ttyVR0,38400"
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index ab7ebb066834..28e72ae87ca9 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -22,12 +22,14 @@ CONFIG_EMBEDDED=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon console=ttyS4,115200 clk_ignore_unused"
 CONFIG_MACH_INGENIC_SOC=y
 CONFIG_JZ4780_CI20=y
 CONFIG_HIGHMEM=y
 CONFIG_HZ_100=y
-# CONFIG_SECCOMP is not set
 # CONFIG_SUSPEND is not set
+# CONFIG_SECCOMP is not set
 CONFIG_MODULES=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPACTION is not set
@@ -99,12 +101,12 @@ CONFIG_IR_GPIO_CIR=m
 CONFIG_IR_GPIO_TX=m
 CONFIG_MEDIA_SUPPORT=m
 # CONFIG_VGA_CONSOLE is not set
-# CONFIG_HID is not set
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_SERIAL=y
 CONFIG_USB_SERIAL_CH341=y
+CONFIG_JZ4770_PHY=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
@@ -138,7 +140,6 @@ CONFIG_JZ4780_NEMC=y
 CONFIG_PWM=y
 CONFIG_PWM_JZ4740=m
 CONFIG_JZ4780_EFUSE=y
-CONFIG_JZ4770_PHY=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_AUTOFS_FS=y
@@ -151,7 +152,6 @@ CONFIG_CONFIGFS_FS=y
 CONFIG_UBIFS_FS=y
 CONFIG_NFS_FS=y
 CONFIG_ROOT_NFS=y
-CONFIG_NLS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_737=y
 CONFIG_NLS_CODEPAGE_775=y
@@ -203,5 +203,3 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon console=ttyS4,115200 clk_ignore_unused"
diff --git a/arch/mips/configs/cu1000-neo_defconfig b/arch/mips/configs/cu1000-neo_defconfig
index 9d75f5b77d5d..e54e708783d9 100644
--- a/arch/mips/configs/cu1000-neo_defconfig
+++ b/arch/mips/configs/cu1000-neo_defconfig
@@ -19,12 +19,14 @@ CONFIG_EMBEDDED=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon clk_ignore_unused"
 CONFIG_MACH_INGENIC_SOC=y
 CONFIG_X1000_CU1000_NEO=y
 CONFIG_HIGHMEM=y
 CONFIG_HZ_100=y
-# CONFIG_SECCOMP is not set
 # CONFIG_SUSPEND is not set
+# CONFIG_SECCOMP is not set
 CONFIG_MODULES=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPACTION is not set
@@ -67,12 +69,12 @@ CONFIG_SENSORS_ADS7828=m
 CONFIG_WATCHDOG=y
 CONFIG_JZ4740_WDT=y
 # CONFIG_VGA_CONSOLE is not set
-# CONFIG_HID is not set
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_SERIAL=y
 CONFIG_USB_SERIAL_CH341=y
+CONFIG_JZ4770_PHY=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
@@ -87,7 +89,6 @@ CONFIG_DMA_JZ4780=y
 # CONFIG_INGENIC_TIMER is not set
 CONFIG_INGENIC_SYSOST=y
 # CONFIG_IOMMU_SUPPORT is not set
-CONFIG_JZ4770_PHY=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_AUTOFS_FS=y
@@ -98,7 +99,6 @@ CONFIG_PROC_KCORE=y
 CONFIG_TMPFS=y
 CONFIG_CONFIGFS_FS=y
 CONFIG_NFS_FS=y
-CONFIG_NLS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_936=y
 CONFIG_NLS_CODEPAGE_950=y
@@ -123,5 +123,3 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon clk_ignore_unused"
diff --git a/arch/mips/configs/cu1830-neo_defconfig b/arch/mips/configs/cu1830-neo_defconfig
index 29decd0003c6..06267749acc9 100644
--- a/arch/mips/configs/cu1830-neo_defconfig
+++ b/arch/mips/configs/cu1830-neo_defconfig
@@ -19,12 +19,14 @@ CONFIG_EMBEDDED=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon clk_ignore_unused"
 CONFIG_MACH_INGENIC_SOC=y
 CONFIG_X1830_CU1830_NEO=y
 CONFIG_HIGHMEM=y
 CONFIG_HZ_100=y
-# CONFIG_SECCOMP is not set
 # CONFIG_SUSPEND is not set
+# CONFIG_SECCOMP is not set
 CONFIG_MODULES=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 # CONFIG_COMPACTION is not set
@@ -70,12 +72,12 @@ CONFIG_SENSORS_ADS7828=m
 CONFIG_WATCHDOG=y
 CONFIG_JZ4740_WDT=y
 # CONFIG_VGA_CONSOLE is not set
-# CONFIG_HID is not set
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_SERIAL=y
 CONFIG_USB_SERIAL_CH341=y
+CONFIG_JZ4770_PHY=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
@@ -90,7 +92,6 @@ CONFIG_DMA_JZ4780=y
 # CONFIG_INGENIC_TIMER is not set
 CONFIG_INGENIC_SYSOST=y
 # CONFIG_IOMMU_SUPPORT is not set
-CONFIG_JZ4770_PHY=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_AUTOFS_FS=y
@@ -101,7 +102,6 @@ CONFIG_PROC_KCORE=y
 CONFIG_TMPFS=y
 CONFIG_CONFIGFS_FS=y
 CONFIG_NFS_FS=y
-CONFIG_NLS=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_936=y
 CONFIG_NLS_CODEPAGE_950=y
@@ -126,5 +126,3 @@ CONFIG_PANIC_TIMEOUT=10
 # CONFIG_DEBUG_PREEMPT is not set
 CONFIG_STACKTRACE=y
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon clk_ignore_unused"
diff --git a/arch/mips/configs/e55_defconfig b/arch/mips/configs/e55_defconfig
index fd82b858a8f0..19769d645fcb 100644
--- a/arch/mips/configs/e55_defconfig
+++ b/arch/mips/configs/e55_defconfig
@@ -2,6 +2,8 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="console=ttyVR0,19200 ide0=0x1f0,0x3f6,40 mem=8M"
 CONFIG_MACH_VR41XX=y
 CONFIG_CASIO_E55=y
 CONFIG_MODULES=y
@@ -33,5 +35,3 @@ CONFIG_AUTOFS4_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_TMPFS=y
 CONFIG_TMPFS_POSIX_ACL=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=ttyVR0,19200 ide0=0x1f0,0x3f6,40 mem=8M"
diff --git a/arch/mips/configs/generic_defconfig b/arch/mips/configs/generic_defconfig
index 714169e411cf..665ae8d63ef3 100644
--- a/arch/mips/configs/generic_defconfig
+++ b/arch/mips/configs/generic_defconfig
@@ -3,7 +3,6 @@ CONFIG_NO_HZ_IDLE=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_MEMCG=y
-CONFIG_MEMCG_SWAP=y
 CONFIG_BLK_CGROUP=y
 CONFIG_CFS_BANDWIDTH=y
 CONFIG_RT_GROUP_SCHED=y
@@ -21,6 +20,8 @@ CONFIG_USERFAULTFD=y
 CONFIG_EMBEDDED=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="earlycon"
 CONFIG_CPU_LITTLE_ENDIAN=y
 CONFIG_MIPS_CPS=y
 CONFIG_HIGHMEM=y
@@ -52,7 +53,6 @@ CONFIG_HID_CHICONY=y
 CONFIG_HID_CYPRESS=y
 CONFIG_HID_EZKEY=y
 CONFIG_HID_KENSINGTON=y
-CONFIG_HID_LOGITECH=y
 CONFIG_HID_MICROSOFT=y
 CONFIG_HID_MONTEREY=y
 # CONFIG_MIPS_PLATFORM_DEVICES is not set
@@ -88,5 +88,3 @@ CONFIG_DEBUG_INFO_REDUCED=y
 CONFIG_DEBUG_FS=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="earlycon"
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 5cb91509bb7c..cb642d14dd93 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@ -10,9 +10,10 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="console=ttyS0,115200 root=/dev/nfs rw ip=auto"
 CONFIG_MIPS_ALCHEMY=y
 CONFIG_MIPS_GPR=y
-CONFIG_PCI=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_PARTITION_ADVANCED=y
@@ -29,9 +30,6 @@ CONFIG_IP_ROUTE_VERBOSE=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
 CONFIG_NETFILTER=y
@@ -49,7 +47,6 @@ CONFIG_NETFILTER_XT_MATCH_LIMIT=m
 CONFIG_NETFILTER_XT_MATCH_MAC=m
 CONFIG_NETFILTER_XT_MATCH_MARK=m
 CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
-CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
 CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
 CONFIG_NETFILTER_XT_MATCH_QUOTA=m
 CONFIG_NETFILTER_XT_MATCH_REALM=m
@@ -151,6 +148,7 @@ CONFIG_BAYCOM_SER_HDX=m
 CONFIG_YAM=m
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
+CONFIG_PCI=y
 CONFIG_MTD=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
@@ -225,9 +223,6 @@ CONFIG_HDLC_X25=m
 CONFIG_PCI200SYN=m
 CONFIG_WANXL=m
 CONFIG_FARSYNC=m
-CONFIG_DSCC4=m
-CONFIG_DSCC4_PCISYNC=y
-CONFIG_DSCC4_PCI_RST=y
 CONFIG_LAPBETHER=m
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
@@ -247,7 +242,6 @@ CONFIG_WATCHDOG_NOWAYOUT=y
 CONFIG_SSB=m
 CONFIG_SSB_DRIVER_PCICORE=y
 # CONFIG_VGA_ARB is not set
-# CONFIG_LCD_CLASS_DEVICE is not set
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_USB_HID=m
@@ -295,16 +289,10 @@ CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_TGR192=m
 CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_ANUBIS=m
 CONFIG_CRYPTO_BLOWFISH=m
 CONFIG_CRYPTO_CAST5=m
 CONFIG_CRYPTO_CAST6=m
-CONFIG_CRYPTO_KHAZAD=m
 CONFIG_CRYPTO_SERPENT=m
-CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_DEFLATE=m
-# CONFIG_ENABLE_MUST_CHECK is not set
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=ttyS0,115200 root=/dev/nfs rw ip=auto"
diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig
index 0e79f81217bc..f3b8c64ea379 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -13,7 +13,6 @@ CONFIG_TASK_DELAY_ACCT=y
 CONFIG_TASK_XACCT=y
 CONFIG_TASK_IO_ACCOUNTING=y
 CONFIG_MEMCG=y
-CONFIG_MEMCG_SWAP=y
 CONFIG_BLK_CGROUP=y
 CONFIG_CGROUP_PIDS=y
 CONFIG_CGROUP_FREEZER=y
@@ -28,6 +27,8 @@ CONFIG_RELAY=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EMBEDDED=y
 CONFIG_PERF_EVENTS=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="ieee754=relaxed"
 CONFIG_MACH_LOONGSON64=y
 CONFIG_CPU_HAS_MSA=y
 CONFIG_NR_CPUS=16
@@ -39,7 +40,6 @@ CONFIG_MIPS32_O32=y
 CONFIG_MIPS32_N32=y
 CONFIG_VIRTUALIZATION=y
 CONFIG_KVM=m
-CONFIG_KVM_MIPS_VZ=y
 CONFIG_MODULES=y
 CONFIG_MODULE_FORCE_LOAD=y
 CONFIG_MODULE_UNLOAD=y
@@ -204,7 +204,6 @@ CONFIG_VIRTIO_NET=m
 # CONFIG_NET_VENDOR_DEC is not set
 # CONFIG_NET_VENDOR_DLINK is not set
 # CONFIG_NET_VENDOR_EMULEX is not set
-# CONFIG_NET_VENDOR_HP is not set
 # CONFIG_NET_VENDOR_I825XX is not set
 CONFIG_E1000=y
 CONFIG_E1000E=y
@@ -246,7 +245,6 @@ CONFIG_PPP_ASYNC=m
 CONFIG_PPP_SYNC_TTY=m
 CONFIG_ATH9K=m
 CONFIG_HOSTAP=m
-CONFIG_INPUT_POLLDEV=m
 CONFIG_INPUT_SPARSEKMAP=y
 CONFIG_INPUT_MOUSEDEV=y
 CONFIG_INPUT_MOUSEDEV_PSAUX=y
@@ -278,7 +276,6 @@ CONFIG_SENSORS_LM75=m
 CONFIG_SENSORS_LM93=m
 CONFIG_SENSORS_W83627HF=m
 CONFIG_MEDIA_SUPPORT=m
-CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_DRM=y
@@ -388,18 +385,14 @@ CONFIG_SECURITY_SELINUX=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
 CONFIG_SECURITY_SELINUX_DISABLE=y
 CONFIG_DEFAULT_SECURITY_DAC=y
-CONFIG_CRYPTO_AUTHENC=m
 CONFIG_CRYPTO_HMAC=y
 CONFIG_CRYPTO_MD5=y
 CONFIG_CRYPTO_TGR192=m
 CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_ANUBIS=m
 CONFIG_CRYPTO_BLOWFISH=m
 CONFIG_CRYPTO_CAST5=m
 CONFIG_CRYPTO_CAST6=m
-CONFIG_CRYPTO_KHAZAD=m
 CONFIG_CRYPTO_SERPENT=m
-CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_TWOFISH=m
 CONFIG_CRYPTO_DEFLATE=m
 CONFIG_PRINTK_TIME=y
@@ -408,5 +401,3 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_FTRACE is not set
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="ieee754=relaxed"
diff --git a/arch/mips/configs/mpc30x_defconfig b/arch/mips/configs/mpc30x_defconfig
index d4e038802510..925e71b9a9a7 100644
--- a/arch/mips/configs/mpc30x_defconfig
+++ b/arch/mips/configs/mpc30x_defconfig
@@ -3,6 +3,8 @@ CONFIG_LOG_BUF_SHIFT=14
 CONFIG_RELAY=y
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="mem=32M console=ttyVR0,19200 ide0=0x170,0x376,73"
 CONFIG_MACH_VR41XX=y
 CONFIG_VICTOR_MPC30X=y
 CONFIG_MODULES=y
@@ -18,9 +20,6 @@ CONFIG_NET_KEY=y
 CONFIG_NET_KEY_MIGRATE=y
 CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
-CONFIG_INET_XFRM_MODE_TRANSPORT=m
-CONFIG_INET_XFRM_MODE_TUNNEL=m
-CONFIG_INET_XFRM_MODE_BEET=m
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
 CONFIG_CONNECTOR=m
@@ -49,5 +48,3 @@ CONFIG_AUTOFS4_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_CONFIGFS_FS=m
 CONFIG_NFS_FS=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="mem=32M console=ttyVR0,19200 ide0=0x170,0x376,73"
diff --git a/arch/mips/configs/tb0219_defconfig b/arch/mips/configs/tb0219_defconfig
index 6547f84750b5..1d1bacd3eb2b 100644
--- a/arch/mips/configs/tb0219_defconfig
+++ b/arch/mips/configs/tb0219_defconfig
@@ -2,6 +2,8 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
 CONFIG_MACH_VR41XX=y
 CONFIG_TANBAC_TB0219=y
 CONFIG_MODULES=y
@@ -23,9 +25,6 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_NET_IPIP=m
 CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
 CONFIG_BLK_DEV_LOOP=m
@@ -73,5 +72,3 @@ CONFIG_NFS_FS=y
 CONFIG_ROOT_NFS=y
 CONFIG_NFSD=y
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
diff --git a/arch/mips/configs/tb0226_defconfig b/arch/mips/configs/tb0226_defconfig
index 7e099f7c2286..072ac9fa92a7 100644
--- a/arch/mips/configs/tb0226_defconfig
+++ b/arch/mips/configs/tb0226_defconfig
@@ -2,6 +2,8 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="cca=3 mem=32M console=ttyVR0,115200"
 CONFIG_MACH_VR41XX=y
 CONFIG_TANBAC_TB0226=y
 CONFIG_MODULES=y
@@ -21,9 +23,6 @@ CONFIG_IP_ROUTE_VERBOSE=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
 CONFIG_BLK_DEV_LOOP=m
@@ -68,5 +67,3 @@ CONFIG_NFS_FS=y
 CONFIG_ROOT_NFS=y
 CONFIG_NFSD=m
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="cca=3 mem=32M console=ttyVR0,115200"
diff --git a/arch/mips/configs/tb0287_defconfig b/arch/mips/configs/tb0287_defconfig
index 0d881dd862c0..30b1b84fe46b 100644
--- a/arch/mips/configs/tb0287_defconfig
+++ b/arch/mips/configs/tb0287_defconfig
@@ -2,6 +2,8 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
 CONFIG_MACH_VR41XX=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
@@ -22,9 +24,6 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_NET_IPIP=m
 CONFIG_SYN_COOKIES=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 CONFIG_TCP_CONG_ADVANCED=y
 CONFIG_TCP_CONG_BIC=y
 CONFIG_TCP_CONG_CUBIC=m
@@ -81,5 +80,3 @@ CONFIG_NFSD_V3=y
 CONFIG_FONTS=y
 CONFIG_FONT_8x8=y
 CONFIG_FONT_8x16=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="cca=3 mem=64M console=ttyVR0,115200 ip=any root=/dev/nfs"
diff --git a/arch/mips/configs/workpad_defconfig b/arch/mips/configs/workpad_defconfig
index 891a5f77305d..81bf360060a2 100644
--- a/arch/mips/configs/workpad_defconfig
+++ b/arch/mips/configs/workpad_defconfig
@@ -2,10 +2,10 @@ CONFIG_SYSVIPC=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_EXPERT=y
 CONFIG_SLAB=y
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="console=ttyVR0,19200 ide0=0x170,0x376,49 mem=16M"
 CONFIG_MACH_VR41XX=y
 CONFIG_IBM_WORKPAD=y
-CONFIG_PCCARD=y
-CONFIG_PCMCIA_VRC4171=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
@@ -20,11 +20,10 @@ CONFIG_NET_KEY=y
 CONFIG_NET_KEY_MIGRATE=y
 CONFIG_INET=y
 CONFIG_IP_MULTICAST=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_IPV6 is not set
 CONFIG_NETWORK_SECMARK=y
+CONFIG_PCCARD=y
+CONFIG_PCMCIA_VRC4171=y
 CONFIG_BLK_DEV_RAM=m
 CONFIG_IDE=y
 CONFIG_BLK_DEV_IDECS=m
@@ -61,5 +60,3 @@ CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_NFS_FS=m
 CONFIG_NFSD=m
 CONFIG_NFSD_V3=y
-CONFIG_CMDLINE_BOOL=y
-CONFIG_CMDLINE="console=ttyVR0,19200 ide0=0x170,0x376,49 mem=16M"
diff --git a/arch/mips/include/asm/setup.h b/arch/mips/include/asm/setup.h
index bb36a400203d..085f0b503f07 100644
--- a/arch/mips/include/asm/setup.h
+++ b/arch/mips/include/asm/setup.h
@@ -5,6 +5,7 @@
 #include <linux/types.h>
 #include <uapi/asm/setup.h>
 
+#ifndef __ASSEMBLY__
 extern void prom_putchar(char);
 extern void setup_early_printk(void);
 
@@ -27,5 +28,6 @@ extern unsigned long ebase;
 extern unsigned int hwrena;
 extern void per_cpu_trap_init(bool);
 extern void cpu_cache_init(void);
+#endif
 
 #endif /* __SETUP_H */
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 499a5357c09f..67ad1c481417 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -22,6 +22,7 @@
 #include <linux/start_kernel.h>
 #include <linux/string.h>
 #include <linux/printk.h>
+#include <linux/cmdline.h>
 
 #define RELOCATED(x) ((void *)((long)x + offset))
 
@@ -246,16 +247,26 @@ static inline __init bool kaslr_disabled(void)
 	char *str;
 
 #if defined(CONFIG_CMDLINE_BOOL)
-	const char *builtin_cmdline = CONFIG_CMDLINE;
+	char *builtin_cmdline = CMDLINE_PREPEND;
 
 	str = strstr(builtin_cmdline, "nokaslr");
 	if (str == builtin_cmdline ||
 	    (str > builtin_cmdline && *(str - 1) == ' '))
 		return true;
 #endif
-	str = strstr(arcs_cmdline, "nokaslr");
-	if (str == arcs_cmdline || (str > arcs_cmdline && *(str - 1) == ' '))
+	if (!IS_ENABLED(CONFIG_CMDLINE_OVERRIDE)) {
+		str = strstr(arcs_cmdline, "nokaslr");
+		if (str == arcs_cmdline || (str > arcs_cmdline && *(str - 1) == ' '))
+			return true;
+	}
+
+#if defined(CONFIG_CMDLINE_BOOL)
+	builtin_cmdline = CMDLINE_APPEND;
+	str = strstr(builtin_cmdline, "nokaslr");
+	if (str == builtin_cmdline ||
+	    (str > builtin_cmdline && *(str - 1) == ' '))
 		return true;
+#endif
 
 	return false;
 }
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 23a140327a0b..bbe1b34339ab 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -23,6 +23,7 @@
 #include <linux/debugfs.h>
 #include <linux/kexec.h>
 #include <linux/sizes.h>
+#include <linux/cmdline.h>
 #include <linux/device.h>
 #include <linux/dma-map-ops.h>
 #include <linux/decompress/generic.h>
@@ -66,12 +67,6 @@ EXPORT_SYMBOL(mips_machtype);
 static char __initdata command_line[COMMAND_LINE_SIZE];
 char __initdata arcs_cmdline[COMMAND_LINE_SIZE];
 
-#ifdef CONFIG_CMDLINE_BOOL
-static const char builtin_cmdline[] __initconst = CONFIG_CMDLINE;
-#else
-static const char builtin_cmdline[] __initconst = "";
-#endif
-
 /*
  * mips_io_port_base is the begin of the address space to which x86 style
  * I/O ports are mapped.
@@ -546,27 +541,7 @@ static void __init bootcmdline_init(void)
 {
 	bool dt_bootargs = false;
 
-	/*
-	 * If CMDLINE_OVERRIDE is enabled then initializing the command line is
-	 * trivial - we simply use the built-in command line unconditionally &
-	 * unmodified.
-	 */
-	if (IS_ENABLED(CONFIG_CMDLINE_OVERRIDE)) {
-		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-		return;
-	}
-
-	/*
-	 * If the user specified a built-in command line &
-	 * MIPS_CMDLINE_BUILTIN_EXTEND, then the built-in command line is
-	 * prepended to arguments from the bootloader or DT so we'll copy them
-	 * to the start of boot_command_line here. Otherwise, empty
-	 * boot_command_line to undo anything early_init_dt_scan_chosen() did.
-	 */
-	if (IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND))
-		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-	else
-		boot_command_line[0] = 0;
+	boot_command_line[0] = 0;
 
 #ifdef CONFIG_OF_EARLY_FLATTREE
 	/*
@@ -589,12 +564,9 @@ static void __init bootcmdline_init(void)
 		bootcmdline_append(arcs_cmdline, COMMAND_LINE_SIZE);
 
 	/*
-	 * If the user specified a built-in command line & we didn't already
-	 * prepend it, we append it to boot_command_line here.
+	 * Use the generic system for builtin prepend and append.
 	 */
-	if (IS_ENABLED(CONFIG_CMDLINE_BOOL) &&
-	    !IS_ENABLED(CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND))
-		bootcmdline_append(builtin_cmdline, COMMAND_LINE_SIZE);
+	cmdline_add_builtin(boot_command_line);
 }
 
 /*
diff --git a/arch/mips/pic32/pic32mzda/early_console.c b/arch/mips/pic32/pic32mzda/early_console.c
index 25372e62783b..213e318d7ad4 100644
--- a/arch/mips/pic32/pic32mzda/early_console.c
+++ b/arch/mips/pic32/pic32mzda/early_console.c
@@ -76,7 +76,7 @@ static char * __init pic32_getcmdline(void)
 	 * command line setup if using CONFIG_CMDLINE_BOOL.
 	 */
 #ifdef CONFIG_CMDLINE_OVERRIDE
-	return CONFIG_CMDLINE;
+	return CMDLINE_STATIC_PREPEND " " CMDLINE_STATIC_APPEND;
 #else
 	return fw_getcmdline();
 #endif
diff --git a/arch/mips/pic32/pic32mzda/init.c b/arch/mips/pic32/pic32mzda/init.c
index 764f2d022fae..9a3328ba8ea1 100644
--- a/arch/mips/pic32/pic32mzda/init.c
+++ b/arch/mips/pic32/pic32mzda/init.c
@@ -9,6 +9,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/platform_data/sdhci-pic32.h>
+#include <linux/cmdline.h>
 
 #include <asm/fw/fw.h>
 #include <asm/mips-boards/generic.h>
@@ -41,7 +42,7 @@ void __init plat_mem_setup(void)
 	pr_info(" boot_command_line: %s\n", boot_command_line);
 	pr_info(" arcs_cmdline     : %s\n", arcs_cmdline);
 #ifdef CONFIG_CMDLINE_BOOL
-	pr_info(" builtin_cmdline  : %s\n", CONFIG_CMDLINE);
+	pr_info(" builtin_cmdline  : %s\n", CMDLINE_STATIC_PREPEND " " CMDLINE_STATIC_APPEND);
 #endif
 	if (dtb != __dtb_start)
 		strlcpy(arcs_cmdline, boot_command_line, COMMAND_LINE_SIZE);
-- 
2.25.1



From danielwa at cisco.com  Fri Apr 16 05:09:19 2021
From: danielwa at cisco.com (Daniel Walker)
Date: Thu, 15 Apr 2021 21:09:19 -0700
Subject: [PATCH 8/8] CMDLINE: arm64: convert to generic builtin command line
In-Reply-To: <20210416040924.2882771-1-danielwa@cisco.com>
References: <20210416040924.2882771-1-danielwa@cisco.com>
Message-ID: <20210416040924.2882771-9-danielwa@cisco.com>

This removes arm64 from the device tree handling of the
command line arguments.

The boot_command_line variable is populated inside the earliest
user of the command line, which is in idreg-override.c.

The device tree should not be needed to do any further handling
of the boot command line options.

Cc: xe-linux-external at cisco.com
Signed-off-by: Daniel Walker <danielwa at cisco.com>
---
 arch/arm64/Kconfig                 | 33 +-----------------------------
 arch/arm64/include/asm/setup.h     |  2 ++
 arch/arm64/kernel/idreg-override.c |  9 ++++----
 3 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..9781ba3758b1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -105,6 +105,7 @@ config ARM64
 	select GENERIC_ALLOCATOR
 	select GENERIC_ARCH_TOPOLOGY
 	select GENERIC_CLOCKEVENTS_BROADCAST
+	select GENERIC_CMDLINE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_CPU_VULNERABILITIES
 	select GENERIC_EARLY_IOREMAP
@@ -1841,38 +1842,6 @@ config ARM64_ACPI_PARKING_PROTOCOL
 	  protocol even if the corresponding data is present in the ACPI
 	  MADT table.
 
-config CMDLINE
-	string "Default kernel command string"
-	default ""
-	help
-	  Provide a set of default command-line options at build time by
-	  entering them here. As a minimum, you should specify the the
-	  root device (e.g. root=/dev/nfs).
-
-choice
-	prompt "Kernel command line type" if CMDLINE != ""
-	default CMDLINE_FROM_BOOTLOADER
-	help
-	  Choose how the kernel will handle the provided default kernel
-	  command line string.
-
-config CMDLINE_FROM_BOOTLOADER
-	bool "Use bootloader kernel arguments if available"
-	help
-	  Uses the command-line options passed by the boot loader. If
-	  the boot loader doesn't provide any, the default kernel command
-	  string provided in CMDLINE will be used.
-
-config CMDLINE_FORCE
-	bool "Always use the default kernel command string"
-	help
-	  Always use the default kernel command string, even if the boot
-	  loader passes other arguments to the kernel.
-	  This is useful if you cannot or don't want to change the
-	  command-line options your boot loader passes to the kernel.
-
-endchoice
-
 config EFI_STUB
 	bool
 
diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
index d3320618ed14..1f5b6d8f2433 100644
--- a/arch/arm64/include/asm/setup.h
+++ b/arch/arm64/include/asm/setup.h
@@ -5,7 +5,9 @@
 
 #include <uapi/asm/setup.h>
 
+#ifndef __ASSEMBLY__
 void *get_early_fdt_ptr(void);
 void early_fdt_map(u64 dt_phys);
+#endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index 83f1c4b92095..0a3fcae13043 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -9,6 +9,7 @@
 #include <linux/ctype.h>
 #include <linux/kernel.h>
 #include <linux/libfdt.h>
+#include <linux/cmdline.h>
 
 #include <asm/cacheflush.h>
 #include <asm/cpufeature.h>
@@ -188,11 +189,11 @@ static __init void parse_cmdline(void)
 {
 	const u8 *prop = get_bootargs_cmdline();
 
-	if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !prop)
-		__parse_cmdline(CONFIG_CMDLINE, true);
+	strscpy(boot_command_line, prop, COMMAND_LINE_SIZE);
+	cmdline_add_builtin(boot_command_line);
+
+	__parse_cmdline(boot_command_line, true);
 
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
-		__parse_cmdline(prop, true);
 }
 
 /* Keep checkers quiet */
-- 
2.25.1



From linux at roeck-us.net  Fri Apr 16 06:07:32 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 15 Apr 2021 22:07:32 -0700
Subject: [PATCH v2] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <20210416021337.18715-1-rentao.bupt@gmail.com>
References: <20210416021337.18715-1-rentao.bupt@gmail.com>
Message-ID: <2771f72a-cc3c-54a5-cc2c-715ea61be6b7@roeck-us.net>

On 4/15/21 7:13 PM, rentao.bupt at gmail.com wrote:
> From: Tao Ren <rentao.bupt at gmail.com>
> 
> Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> handler to avoid potential integer overflow when the supplied timeout is
> greater than aspeed's maximum allowed timeout (4294 seconds).
> 

I think this is the wrong focus: What this fixes is the wrong hardware
timeout calculation. Again, I think that the wrong calculation leads to
the overflow should not be the focus of this patch, though it can of
course be mentioned.

I'll leave it up to Wim to decide if he wants to apply the patch with the
current explanation.

Thanks,
Guenter

> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> Reported-by: Amithash Prasad <amithash at fb.com>
> Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
> ---
>  Changes in v2:
>    - do not touch "wdd->timeout": only "max_hw_heartbeat_ms * 1000" is
>      updated to "max_hw_heartbeat_ms / 1000".
> 
>  drivers/watchdog/aspeed_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index 7e00960651fa..507fd815d767 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -147,7 +147,7 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
>  
>  	wdd->timeout = timeout;
>  
> -	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
>  
>  	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
>  	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> 



From christophe.leroy at csgroup.eu  Fri Apr 16 06:19:46 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 07:19:46 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <8735vr16sd.fsf@dja-thinkpad.axtens.net>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <8735vr16sd.fsf@dja-thinkpad.axtens.net>
Message-ID: <ce7773ea-80d0-14c8-3547-d53424682469@csgroup.eu>



Le 16/04/2021 ? 01:12, Daniel Axtens a ?crit?:
> Hi Christophe,
> 
>>   static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
>> -		      u64 val)
>> +		      u64 val, unsigned long page_size)
> 
> Compilers can warn about unused parameters at -Wextra level.  However,
> reading scripts/Makefile.extrawarn it looks like the warning is
> explicitly _disabled_ in the kernel at W=1 and not reenabled at W=2 or
> W=3. So I guess this is fine...

There are a lot lot lot functions having unused parameters in the kernel , especially the ones that 
are re-implemented by each architecture.

> 
>> @@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long next,
>>   {
>>   	struct ptdump_state *st = walk->private;
>>   
>> -	st->note_page(st, addr, depth, 0);
>> +	st->note_page(st, addr, depth, 0, 0);
> 
> I know it doesn't matter at this point, but I'm not really thrilled by
> the idea of passing 0 as the size here. Doesn't the hole have a known
> page size?

The hole has a size for sure, I don't think we can call it a page size:

On powerpc 8xx, we have 4 page sizes: 8M, 512k, 16k and 4k.
A page table will cover 4M areas and will contain pages of size 512k, 16k and 4k.
A PGD table contains either entries which points to a page table (covering 4M), or two identical 
consecutive entries pointing to the same hugepd which contains a single PTE for an 8M page.

So, if a PGD entry is empty, the hole is 4M, it corresponds to none of the page sizes the 
architecture supports.


But looking at what is done with that size, it can make sense to pass it to notepage() anyway. Let's 
do that.

> 
>>   
>>   	return 0;
>>   }
>> @@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>>   	mmap_read_unlock(mm);
>>   
>>   	/* Flush out the last page */
>> -	st->note_page(st, 0, -1, 0);
>> +	st->note_page(st, 0, -1, 0, 0);
> 
> I'm more OK with the idea of passing 0 as the size when the depth is -1
> (don't know): if we don't know the depth we conceptually can't know the
> page size.
> 
> Regards,
> Daniel
> 


From christophe.leroy at csgroup.eu  Fri Apr 16 06:25:36 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 07:25:36 +0200
Subject: [PATCH v1 4/5] mm: ptdump: Support hugepd table entries
In-Reply-To: <87zgxzyvn3.fsf@dja-thinkpad.axtens.net>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <f41a177a0fd5a71db616e586a9ec5c51102c6656.1618506910.git.christophe.leroy@csgroup.eu>
 <87zgxzyvn3.fsf@dja-thinkpad.axtens.net>
Message-ID: <0e7b9312-888c-2e53-b7fd-a887fd9fb429@csgroup.eu>

Hi Daniel,

Le 16/04/2021 ? 01:29, Daniel Axtens a ?crit?:
> Hi Christophe,
> 
>> Which hugepd, page table entries can be at any level
>> and can be of any size.
>>
>> Add support for them.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   mm/ptdump.c | 17 +++++++++++++++--
>>   1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>> index 61cd16afb1c8..6efdb8c15a7d 100644
>> --- a/mm/ptdump.c
>> +++ b/mm/ptdump.c
>> @@ -112,11 +112,24 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
>>   {
>>   	struct ptdump_state *st = walk->private;
>>   	pte_t val = ptep_get(pte);
>> +	unsigned long page_size = next - addr;
>> +	int level;
>> +
>> +	if (page_size >= PGDIR_SIZE)
>> +		level = 0;
>> +	else if (page_size >= P4D_SIZE)
>> +		level = 1;
>> +	else if (page_size >= PUD_SIZE)
>> +		level = 2;
>> +	else if (page_size >= PMD_SIZE)
>> +		level = 3;
>> +	else
>> +		level = 4;
>>   
>>   	if (st->effective_prot)
>> -		st->effective_prot(st, 4, pte_val(val));
>> +		st->effective_prot(st, level, pte_val(val));
>>   
>> -	st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
>> +	st->note_page(st, addr, level, pte_val(val), page_size);
> 
> It seems to me that passing both level and page_size is a bit redundant,
> but I guess it does reduce the impact on each arch's code?

Exactly, as shown above, the level can be re-calculated based on the page size, but it would be a 
unnecessary impact on all architectures and would duplicate the re-calculation of the level whereas 
in most cases we get it for free from the caller.

> 
> Kind regards,
> Daniel
> 
>>   
>>   	return 0;
>>   }
>> -- 
>> 2.25.0


From christophe.leroy at csgroup.eu  Fri Apr 16 06:48:41 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 07:48:41 +0200
Subject: [PATCH v1 1/5] mm: pagewalk: Fix walk for hugepage tables
In-Reply-To: <877dl3184l.fsf@dja-thinkpad.axtens.net>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <733408f48b1ed191f53518123ee6fc6d42287cc6.1618506910.git.christophe.leroy@csgroup.eu>
 <877dl3184l.fsf@dja-thinkpad.axtens.net>
Message-ID: <56d4c630-ac1e-6b75-39a5-7b5bfbd5b1aa@csgroup.eu>



Le 16/04/2021 ? 00:43, Daniel Axtens a ?crit?:
> Hi Christophe,
> 
>> Pagewalk ignores hugepd entries and walk down the tables
>> as if it was traditionnal entries, leading to crazy result.
>>
>> Add walk_hugepd_range() and use it to walk hugepage tables.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>>   mm/pagewalk.c | 54 +++++++++++++++++++++++++++++++++++++++++++++------
>>   1 file changed, 48 insertions(+), 6 deletions(-)
>>
>> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
>> index e81640d9f177..410a9d8f7572 100644
>> --- a/mm/pagewalk.c
>> +++ b/mm/pagewalk.c
>> @@ -58,6 +58,32 @@ static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
>>   	return err;
>>   }
>>   
>> +static int walk_hugepd_range(hugepd_t *phpd, unsigned long addr,
>> +			     unsigned long end, struct mm_walk *walk, int pdshift)
>> +{
>> +	int err = 0;
>> +#ifdef CONFIG_ARCH_HAS_HUGEPD
>> +	const struct mm_walk_ops *ops = walk->ops;
>> +	int shift = hugepd_shift(*phpd);
>> +	int page_size = 1 << shift;
>> +
>> +	if (addr & (page_size - 1))
>> +		return 0;
>> +
>> +	for (;;) {
>> +		pte_t *pte = hugepte_offset(*phpd, addr, pdshift);
>> +
>> +		err = ops->pte_entry(pte, addr, addr + page_size, walk);
>> +		if (err)
>> +			break;
>> +		if (addr >= end - page_size)
>> +			break;
>> +		addr += page_size;
>> +	}
> 
> Initially I thought this was a somewhat unintuitive way to structure
> this loop, but I see it parallels the structure of walk_pte_range_inner,
> so I think the consistency is worth it.
> 
> I notice the pte walking code potentially takes some locks: does this
> code need to do that?
> 
> arch/powerpc/mm/hugetlbpage.c says that hugepds are protected by the
> mm->page_table_lock, but I don't think we're taking it in this code.

I'll add it, thanks.

> 
>> +#endif
>> +	return err;
>> +}
>> +
>>   static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>>   			  struct mm_walk *walk)
>>   {
>> @@ -108,7 +134,10 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
>>   				goto again;
>>   		}
>>   
>> -		err = walk_pte_range(pmd, addr, next, walk);
>> +		if (is_hugepd(__hugepd(pmd_val(*pmd))))
>> +			err = walk_hugepd_range((hugepd_t *)pmd, addr, next, walk, PMD_SHIFT);
>> +		else
>> +			err = walk_pte_range(pmd, addr, next, walk);
>>   		if (err)
>>   			break;
>>   	} while (pmd++, addr = next, addr != end);
>> @@ -157,7 +186,10 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
>>   		if (pud_none(*pud))
>>   			goto again;
>>   
>> -		err = walk_pmd_range(pud, addr, next, walk);
>> +		if (is_hugepd(__hugepd(pud_val(*pud))))
>> +			err = walk_hugepd_range((hugepd_t *)pud, addr, next, walk, PUD_SHIFT);
>> +		else
>> +			err = walk_pmd_range(pud, addr, next, walk);
> 
> I'm a bit worried you might end up calling into walk_hugepd_range with
> ops->pte_entry == NULL, and then jumping to 0.

You are right, I missed it.
I'll bail out of walk_hugepd_range() when ops->pte_entry is NULL.


> 
> static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
> 			  struct mm_walk *walk)
> {
> ...
>          pud = pud_offset(p4d, addr);
> 	do {
>                  ...
>                  if ((!walk->vma && (pud_leaf(*pud) || !pud_present(*pud))) ||
> 		    walk->action == ACTION_CONTINUE ||
> 		    !(ops->pmd_entry || ops->pte_entry)) <<< THIS CHECK
> 			continue;
>                  ...
> 		if (is_hugepd(__hugepd(pud_val(*pud))))
> 			err = walk_hugepd_range((hugepd_t *)pud, addr, next, walk, PUD_SHIFT);
> 		else
> 			err = walk_pmd_range(pud, addr, next, walk);
> 		if (err)
> 			break;
> 	} while (pud++, addr = next, addr != end);
> 
> walk_pud_range will proceed if there is _either_ an ops->pmd_entry _or_
> an ops->pte_entry, but walk_hugepd_range will call ops->pte_entry
> unconditionally.
> 
> The same issue applies to walk_{p4d,pgd}_range...
> 
> Kind regards,
> Daniel
> 

Thanks
Christophe


From eballetbo at gmail.com  Fri Apr 16 06:52:26 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:52:26 +0200
Subject: [PATCH 1/3] arm64: dts: mt8183-pumpkin: fix dtbs_check warning
In-Reply-To: <20210414144643.17435-1-matthias.bgg@kernel.org>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
Message-ID: <CAFqH_53TOM6oyByRaMb8d7caX+u5Wn5DyrXuXHYKVUwBCfrkZg@mail.gmail.com>

Hi Matthias,

Thank you for your patch.

Missatge de l'adre?a <matthias.bgg at kernel.org> del dia dc., 14 d?abr.
2021 a les 16:48:
>
> From: Matthias Brugger <matthias.bgg at gmail.com>
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> ---
>
>  arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> index eb6e595c2975..0aff5eb52e88 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> @@ -32,7 +32,7 @@ reserved-memory {
>                 #size-cells = <2>;
>                 ranges;
>
> -               scp_mem_reserved: scp_mem_region {
> +               scp_mem_reserved: scp_mem_region at 50000000 {
>                         compatible = "shared-dma-pool";
>                         reg = <0 0x50000000 0 0x2900000>;
>                         no-map;
> @@ -55,7 +55,7 @@ led-green {
>                 };
>         };
>
> -       ntc at 0 {
> +       ntc {
>                 compatible = "murata,ncp03wf104";
>                 pullup-uv = <1800000>;
>                 pullup-ohm = <390000>;
> --
> 2.30.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>


From eballetbo at gmail.com  Fri Apr 16 06:53:11 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:53:11 +0200
Subject: [PATCH 2/3] arm64: dts: mt8183: fix dtbs_check warning
In-Reply-To: <20210414144643.17435-2-matthias.bgg@kernel.org>
References: <20210414144643.17435-1-matthias.bgg@kernel.org>
 <20210414144643.17435-2-matthias.bgg@kernel.org>
Message-ID: <CAFqH_51iP+V1hQ=J+YtLv0K9qoEK9WJgoCiNyqp6Yd1T9RKfXw@mail.gmail.com>

Hi Matthias,

Thank you for your patch.

Missatge de l'adre?a <matthias.bgg at kernel.org> del dia dc., 14 d?abr.
2021 a les 16:48:
>
> From: Matthias Brugger <matthias.bgg at gmail.com>
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> ---
>
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 0ff7b67a6806..c5e822b6b77a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -681,13 +681,13 @@ cpu_thermal: cpu_thermal {
>                                 sustainable-power = <5000>;
>
>                                 trips {
> -                                       threshold: trip-point at 0 {
> +                                       threshold: trip-point0 {
>                                                 temperature = <68000>;
>                                                 hysteresis = <2000>;
>                                                 type = "passive";
>                                         };
>
> -                                       target: trip-point at 1 {
> +                                       target: trip-point1 {
>                                                 temperature = <80000>;
>                                                 hysteresis = <2000>;
>                                                 type = "passive";
> @@ -1103,7 +1103,7 @@ u2port0: usb-phy at 0 {
>                                 status = "okay";
>                         };
>
> -                       u3port0: usb-phy at 0700 {
> +                       u3port0: usb-phy at 700 {
>                                 reg = <0x0700 0x900>;
>                                 clocks = <&clk26m>;
>                                 clock-names = "ref";
> --
> 2.30.2
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>


From eballetbo at gmail.com  Fri Apr 16 06:55:54 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:55:54 +0200
Subject: [PATCH 1/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kappa
In-Reply-To: <20210415093519.1920877-1-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
Message-ID: <CAFqH_52buFMF6rvyYDgSZ7wCyP2PHXa771N1L28NR8K=XAVO+w@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Kappa is known as HP Chromebook 11a.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index aff57a8c8c30..81b86b189a8d 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -144,6 +144,10 @@ properties:
>            - const: google,kakadu-rev2
>            - const: google,kakadu
>            - const: mediatek,mt8183
> +      - description: Google Kappa (HP Chromebook 11a)
> +        items:
> +          - const: google,kappa
> +          - const: mediatek,mt8183
>        - description: Google Kodama (Lenovo 10e Chromebook Tablet)
>          items:
>            - enum:
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 06:56:33 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:56:33 +0200
Subject: [PATCH 2/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-willow
In-Reply-To: <20210415093519.1920877-2-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-2-hsinyi@chromium.org>
Message-ID: <CAFqH_51rfSf5QR5xE5v=Fky5djT3uR_=0Ho8hD-wXS57tNXtpw@mail.gmail.com>

Hi Hsin-Yi.

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Willow is known as Acer Chromebook 311 (C722/C722T).
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  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 81b86b189a8d..96c401597bd8 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -157,6 +157,13 @@ properties:
>                - google,kodama-sku32
>            - const: google,kodama
>            - const: mediatek,mt8183
> +      - description: Google Willow (Acer Chromebook 311 C722/C722T)
> +        items:
> +          - enum:
> +              - google,willow-sku0
> +              - google,willow-sku1
> +          - const: google,willow
> +          - const: mediatek,mt8183
>        - items:
>            - enum:
>                - mediatek,mt8183-pumpkin
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 06:57:21 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:57:21 +0200
Subject: [PATCH 3/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-burnet
In-Reply-To: <20210415093519.1920877-3-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-3-hsinyi@chromium.org>
Message-ID: <CAFqH_50725CK30jWksqDxvKFUuGdsS4MOtFK58Kqhi7-vcGg9A@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Burnet is known as HP Chromebook x360 11MK G3 EE.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 96c401597bd8..0870490aa350 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -122,6 +122,10 @@ properties:
>            - enum:
>                - 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:
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 06:58:01 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:58:01 +0200
Subject: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210415093519.1920877-4-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-4-hsinyi@chromium.org>
Message-ID: <CAFqH_506gmouWeLRXhRbUpaQ7Xb+bOOJt_65GnPsYE4oRs05XA@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Kenzo is known as Acer Chromebook 311.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 0870490aa350..39e4a99ebb37 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -137,9 +137,11 @@ properties:
>          items:
>            - const: google,damu
>            - const: mediatek,mt8183
> -      - description: Google Juniper (Acer Chromebook Spin 311)
> +      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Crhomebook 311)
>          items:
> -          - const: google,juniper-sku16
> +          - enum:
> +              - google,juniper-sku16
> +              - google,juniper-sku17
>            - const: google,juniper
>            - const: mediatek,mt8183
>        - description: Google Kakadu (ASUS Chromebook Detachable CM3)
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 06:59:17 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 07:59:17 +0200
Subject: [PATCH 5/8] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
In-Reply-To: <20210415093519.1920877-5-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-5-hsinyi@chromium.org>
Message-ID: <CAFqH_515cZrto3wHuUsiMtoQMHjDv-isH3LMRkkgJ+KMZFd6oQ@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Kappa is known as HP Chromebook 11a
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  arch/arm64/boot/dts/mediatek/Makefile            |  1 +
>  .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts  | 16 ++++++++++++++++
>  2 files changed, 17 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index a1c50adc98fa..df70674949ce 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> new file mode 100644
> index 000000000000..b3f46c16e5d7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> +       model = "Google kappa board";
> +       compatible = "google,kappa", "mediatek,mt8183";
> +};
> +
> +&mt6358codec {
> +       mediatek,dmic-mode = <1>; /* one-wire */
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 07:00:22 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 08:00:22 +0200
Subject: [PATCH 6/8] arm64: dts: mt8183: Add kukui-jacuzzi-willow board
In-Reply-To: <20210415093519.1920877-6-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-6-hsinyi@chromium.org>
Message-ID: <CAFqH_52+AdGMhKBOpJ_=tYd0tDRrxYu==nUM1Yrw=wA7KUyecw@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:38:
>
> Willow is known as Acer Chromebook 311 (C722/C722T)
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  arch/arm64/boot/dts/mediatek/Makefile         |  2 ++
>  .../mt8183-kukui-jacuzzi-willow-sku0.dts      | 13 +++++++++
>  .../mt8183-kukui-jacuzzi-willow-sku1.dts      | 12 ++++++++
>  .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 28 +++++++++++++++++++
>  4 files changed, 55 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index df70674949ce..5f43bbc2ea72 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -16,6 +16,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> new file mode 100644
> index 000000000000..281265f082db
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-willow.dtsi"
> +
> +/ {
> +       model = "Google willow board sku0";
> +       compatible = "google,willow-sku0", "google,willow", "mediatek,mt8183";
> +};
> +
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> new file mode 100644
> index 000000000000..22e56bdc1ee3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-willow.dtsi"
> +
> +/ {
> +       model = "Google willow board sku1";
> +       compatible = "google,willow-sku1", "google,willow", "mediatek,mt8183";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
> new file mode 100644
> index 000000000000..3204c1abc4ee
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +&i2c2 {
> +       clock-stretch-ns = <9500>;
> +
> +       trackpad at 2c {
> +               compatible = "hid-over-i2c";
> +               reg = <0x2c>;
> +               hid-descr-addr = <0x20>;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&trackpad_pins>;
> +
> +               interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
> +
> +               wakeup-source;
> +       };
> +};
> +
> +&qca_wifi {
> +       qcom,ath10k-calibration-variant = "GO_JUNIPER";
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 07:01:02 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 08:01:02 +0200
Subject: [PATCH 7/8] arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
In-Reply-To: <20210415093519.1920877-7-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-7-hsinyi@chromium.org>
Message-ID: <CAFqH_50LbYBbJKs_yYQRuW7RPnwVTyJo_n7ZyJ-H_4u955b1NA@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:36:
>
> Burnet is known as HP Chromebook x360 11MK G3 EE
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  arch/arm64/boot/dts/mediatek/Makefile         |  1 +
>  .../mediatek/mt8183-kukui-jacuzzi-burnet.dts  | 33 +++++++++++++++++++
>  2 files changed, 34 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index 5f43bbc2ea72..b33d0bc58021 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
> new file mode 100644
> index 000000000000..b97ca331970e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> +       model = "Google burnet board";
> +       compatible = "google,burnet", "mediatek,mt8183";
> +};
> +
> +&mt6358codec {
> +       mediatek,dmic-mode = <1>; /* one-wire */
> +};
> +
> +&i2c0 {
> +       touchscreen at 2c {
> +               compatible = "hid-over-i2c";
> +               reg = <0x2c>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&touchscreen_pins>;
> +               interrupts-extended = <&pio 155 IRQ_TYPE_LEVEL_LOW>;
> +
> +               post-power-on-delay-ms = <200>;
> +               hid-descr-addr = <0x0020>;
> +       };
> +};
> +
> +&i2c2 {
> +       clock-stretch-ns = <4100>;
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From eballetbo at gmail.com  Fri Apr 16 07:01:38 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 08:01:38 +0200
Subject: [PATCH 8/8] arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
In-Reply-To: <20210415093519.1920877-8-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-8-hsinyi@chromium.org>
Message-ID: <CAFqH_53t4Y-D2tvi7yySc04VeJrYQWBFtVE7ZipHvpwPN-Zy6g@mail.gmail.com>

Hi Hsin-Yi,

Thank you for your patch.

Missatge de Hsin-Yi Wang <hsinyi at chromium.org> del dia dj., 15 d?abr.
2021 a les 11:37:
>
> Kenzo is known as Acer Chromebook 311.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  arch/arm64/boot/dts/mediatek/Makefile                |  1 +
>  .../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12 ++++++++++++
>  2 files changed, 13 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
> index b33d0bc58021..25770d83059d 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
> new file mode 100644
> index 000000000000..6f1aa692753a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-juniper.dtsi"
> +
> +/ {
> +       model = "Google kenzo sku17 board";
> +       compatible = "google,juniper-sku17", "google,juniper", "mediatek,mt8183";
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From heying24 at huawei.com  Fri Apr 16 07:22:17 2021
From: heying24 at huawei.com (He Ying)
Date: Fri, 16 Apr 2021 02:22:17 -0400
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling spurious
 interrups
Message-ID: <20210416062217.25157-1-heying24@huawei.com>

We found this problem in our kernel src tree:

[   14.816231] ------------[ cut here ]------------
[   14.816231] kernel BUG at irq.c:99!
[   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
[   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
[   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95-1.h1.AOS2.0.aarch64 #14
[   14.816233] Hardware name: evb (DT)
[   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[   14.816234] pc : asm_nmi_enter+0x94/0x98
[   14.816235] lr : asm_nmi_enter+0x18/0x98
[   14.816235] sp : ffff000008003c50
[   14.816235] pmr_save: 00000070
[   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
[   14.816238] x27: 0000000000000000 x26: ffff000008004000
[   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
[   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
[   14.816241] x21: ffff000008003da0 x20: 0000000000000060
[   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
[   14.816243] x17: 0000000000000008 x16: 003d090000000000
[   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
[   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
[   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
[   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
[   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
[   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
[   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
[   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
[   14.816251] Call trace:
[   14.816251]  asm_nmi_enter+0x94/0x98
[   14.816251]  el1_irq+0x8c/0x180
[   14.816252]  gic_handle_irq+0xbc/0x2e4
[   14.816252]  el1_irq+0xcc/0x180
[   14.816253]  arch_timer_handler_virt+0x38/0x58
[   14.816253]  handle_percpu_devid_irq+0x90/0x240
[   14.816253]  generic_handle_irq+0x34/0x50
[   14.816254]  __handle_domain_irq+0x68/0xc0
[   14.816254]  gic_handle_irq+0xf8/0x2e4
[   14.816255]  el1_irq+0xcc/0x180
[   14.816255]  arch_cpu_idle+0x34/0x1c8
[   14.816255]  default_idle_call+0x24/0x44
[   14.816256]  do_idle+0x1d0/0x2c8
[   14.816256]  cpu_startup_entry+0x28/0x30
[   14.816256]  rest_init+0xb8/0xc8
[   14.816257]  start_kernel+0x4c8/0x4f4
[   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
[   14.816258] Modules linked in: start_dp(O) smeth(O)
[   15.103092] ---[ end trace 701753956cb14aa8 ]---
[   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
[   15.103099] SMP: stopping secondary CPUs
[   15.103100] Kernel Offset: disabled
[   15.103100] CPU features: 0x36,a2400218
[   15.103100] Memory Limit: none

Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
patches but doesn't support nested NMI. Its top relative commit is
commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs").

I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
in nmi_enter(). From the call trace, we find two 'el1_irqs' which
means an interrupt preempts the other one and the new one is an NMI.
Furthermore, by adding some prints, we find the first irq also calls
nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
is 1023. It enables irq by calling gic_arch_enable_irqs() in
gic_handle_irq(). At this moment, the second irq preempts the first irq
and it's an NMI but current context is already in nmi. So that may be
the problem.

In my opinion, when handling spurious interrupts, we shouldn't enable irqs.
My reason is that for spurious interrupts we may enter nmi context in
el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
at this time, another NMI may happen and preempt this spurious interrupt
but the context is already in nmi. That causes a bug on if nested NMI is
not supported. Even for nested nmi, I think it's not a normal scenario.

Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
Signed-off-by: He Ying <heying24 at huawei.com>
---
 drivers/irqchip/irq-gic-v3.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 94b89258d045..d3b52734a2c5 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -654,15 +654,15 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 		return;
 	}
 
+	/* Check for special IDs first */
+	if ((irqnr >= 1020 && irqnr <= 1023))
+		return;
+
 	if (gic_prio_masking_enabled()) {
 		gic_pmr_mask_irqs();
 		gic_arch_enable_irqs();
 	}
 
-	/* Check for special IDs first */
-	if ((irqnr >= 1020 && irqnr <= 1023))
-		return;
-
 	if (static_branch_likely(&supports_deactivate_key))
 		gic_write_eoir(irqnr);
 	else
-- 
2.17.1



From nm at ti.com  Fri Apr 16 07:37:17 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 01:37:17 -0500
Subject: [PATCH 0/4] dt-bindings: soc/arm: Convert pending ti,
 sci* bindings to json format
Message-ID: <20210416063721.20538-1-nm@ti.com>

Hi,

I understand that the following series belong to various maintainers,
but, it is a bit better reviewed as a single series for
cohesiveness.

There are also dts fixups that this series exposes, which is good, but
I chose to hold them back for now pending binding review at least. The
complete series is available in [1] if folks are curious.

Nishanth Menon (4):
  dt-bindings: reset: Convert ti,sci-reset to json schema
  dt-bindings: clock: Convert ti,sci-clk to json schema
  dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
  dt-bindings: arm: keystone: Convert ti,sci to json schema

 .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
 .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
 .../devicetree/bindings/clock/ti,sci-clk.txt  |  36 -----
 .../devicetree/bindings/clock/ti,sci-clk.yaml |  52 +++++++
 .../bindings/reset/ti,sci-reset.txt           |  62 ---------
 .../bindings/reset/ti,sci-reset.yaml          |  51 +++++++
 .../bindings/soc/ti/sci-pm-domain.txt         |  65 ---------
 .../bindings/soc/ti/sci-pm-domain.yaml        |  59 ++++++++
 8 files changed, 291 insertions(+), 249 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
 delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml

[1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci

Regards,
Nishanth Menon
-- 
2.31.0



From nm at ti.com  Fri Apr 16 07:37:19 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 01:37:19 -0500
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <20210416063721.20538-3-nm@ti.com>

Convert the ti,sci-clk to json schema for better checks and documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Standardize the node name as clock-controller rather than clocks as
   it is more appropriate.
 - Drop phandle description for clock-cells as it is redundant.

NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../devicetree/bindings/clock/ti,sci-clk.txt  | 36 -------------
 .../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++++++++++++++++++
 2 files changed, 52 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml

diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
deleted file mode 100644
index 4e59dc6b1778..000000000000
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Texas Instruments TI-SCI Clocks
-===============================
-
-All clocks on Texas Instruments' SoCs that contain a System Controller,
-are only controlled by this entity. Communication between a host processor
-running an OS and the System Controller happens through a protocol known
-as TI-SCI[1]. This clock implementation plugs into the common clock
-framework and makes use of the TI-SCI protocol on clock API requests.
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-Required properties:
--------------------
-- compatible: Must be "ti,k2g-sci-clk"
-- #clock-cells: Shall be 2.
-  In clock consumers, this cell represents the device ID and clock ID
-  exposed by the PM firmware. The list of valid values for the device IDs
-  and clocks IDs for 66AK2G SoC are documented at
-  http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Examples:
---------
-
-pmmc: pmmc {
-	compatible = "ti,k2g-sci";
-
-	k2g_clks: clocks {
-		compatible = "ti,k2g-sci-clk";
-		#clock-cells = <2>;
-	};
-};
-
-uart0: serial at 2530c00 {
-	compatible = "ns16550a";
-	clocks = <&k2g_clks 0x2c 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
new file mode 100644
index 000000000000..72633651f0c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI clock controller node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+allOf:
+  - $ref: /schemas/clock/clock.yaml#
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This clock controller node uses the TI SCI protocol to perform various clock
+  management of various hardware modules (devices) present on the SoC. This
+  node must be a child node of the associated TI-SCI system controller node.
+
+properties:
+  $nodename:
+    pattern: "^clock-controller$"
+
+  compatible:
+    const: ti,k2g-sci-clk
+
+  "#clock-cells":
+    const: 2
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell should contain the clock ID.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+  - |
+    k3_clks: clock-controller {
+        compatible = "ti,k2g-sci-clk";
+        #clock-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Fri Apr 16 07:37:18 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 01:37:18 -0500
Subject: [PATCH 1/4] dt-bindings: reset: Convert ti,sci-reset to json schema
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <20210416063721.20538-2-nm@ti.com>

Convert the ti,sci-reset to json schema for better checks and documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Drop phandle description for reset consumer or cell definition as it is
   redundant.

NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/reset/ti,sci-reset.txt           | 62 -------------------
 .../bindings/reset/ti,sci-reset.yaml          | 51 +++++++++++++++
 2 files changed, 51 insertions(+), 62 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml

diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
deleted file mode 100644
index 8b1cf022f18a..000000000000
--- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Reset Controller
-=====================================================================
-
-Some TI SoCs contain a system controller (like the Power Management Micro
-Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
-the state of the various hardware modules present on the SoC. Communication
-between the host processor running an OS and the system controller happens
-through a protocol called TI System Control Interface (TI-SCI protocol).
-For TI SCI details, please refer to the document,
-Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-TI-SCI Reset Controller Node
-============================
-This reset controller node uses the TI SCI protocol to perform the reset
-management of various hardware modules present on the SoC. Must be a child
-node of the associated TI-SCI system controller node.
-
-Required properties:
---------------------
- - compatible	: Should be "ti,sci-reset"
- - #reset-cells	: Should be 2. Please see the reset consumer node below for
-		  usage details.
-
-TI-SCI Reset Consumer Nodes
-===========================
-Each of the reset consumer nodes should have the following properties,
-in addition to their own properties.
-
-Required properties:
---------------------
- - resets	: A phandle and reset specifier pair, one pair for each reset
-		  signal that affects the device, or that the device manages.
-		  The phandle should point to the TI-SCI reset controller node,
-		  and the reset specifier should have 2 cell-values. The first
-		  cell should contain the device ID. The second cell should
-		  contain the reset mask value used by system controller.
-		  Please refer to the protocol documentation for these values
-		  to be used for different devices,
-		  http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
-common reset controller usage by consumers.
-
-Example:
---------
-The following example demonstrates both a TI-SCI reset controller node and a
-consumer (a DSP device) on the 66AK2G SoC.
-
-pmmc: pmmc {
-	compatible = "ti,k2g-sci";
-
-	k2g_reset: reset-controller {
-		compatible = "ti,sci-reset";
-		#reset-cells = <2>;
-	};
-};
-
-dsp0: dsp at 10800000 {
-	...
-	resets = <&k2g_reset 0x0046 0x1>;
-	...
-};
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
new file mode 100644
index 000000000000..4639d2cec557
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI reset controller node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This reset controller node uses the TI SCI protocol to perform the reset
+  management of various hardware modules present on the SoC. Must be a child
+  node of the associated TI-SCI system controller node.
+
+properties:
+  $nodename:
+    pattern: "^reset-controller$"
+
+  compatible:
+    const: ti,sci-reset
+
+  "#reset-cells":
+    const: 2
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell should contain the reset mask corresponding to the device
+      used by system controller.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+
+additionalProperties: false
+
+examples:
+  - |
+    k3_reset: reset-controller {
+        compatible = "ti,sci-reset";
+        #reset-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Fri Apr 16 07:37:20 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 01:37:20 -0500
Subject: [PATCH 3/4] dt-bindings: soc: ti: Convert ti,
 sci-pm-domain to json schema
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <20210416063721.20538-4-nm@ti.com>

Convert the ti,sci-pm-domain to json schema for better checks and
documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Drop phandle description for reset consumer or cell definition as it
   is redundant.

NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/soc/ti/sci-pm-domain.txt         | 65 -------------------
 .../bindings/soc/ti/sci-pm-domain.yaml        | 59 +++++++++++++++++
 2 files changed, 59 insertions(+), 65 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml

diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
deleted file mode 100644
index 6217e64309de..000000000000
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Texas Instruments TI-SCI Generic Power Domain
----------------------------------------------
-
-Some TI SoCs contain a system controller (like the PMMC, etc...) that is
-responsible for controlling the state of the IPs that are present.
-Communication between the host processor running an OS and the system
-controller happens through a protocol known as TI-SCI [1].
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-PM Domain Node
-==============
-The PM domain node represents the global PM domain managed by the PMMC, which
-in this case is the implementation as documented by the generic PM domain
-bindings in Documentation/devicetree/bindings/power/power-domain.yaml.  Because
-this relies on the TI SCI protocol to communicate with the PMMC it must be a
-child of the pmmc node.
-
-Required Properties:
---------------------
-- compatible: should be "ti,sci-pm-domain"
-- #power-domain-cells: Can be one of the following:
-			1: Containing the device id of each node
-			2: First entry should be device id
-			   Second entry should be one of the floowing:
-			   TI_SCI_PD_EXCLUSIVE: To allow device to be
-						exclusively controlled by
-						the requesting hosts.
-			   TI_SCI_PD_SHARED: To allow device to be shared
-					     by multiple hosts.
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		...
-
-		k2g_pds: power-controller {
-			compatible = "ti,sci-pm-domain";
-			#power-domain-cells = <1>;
-		};
-	};
-
-PM Domain Consumers
-===================
-Hardware blocks belonging to a PM domain should contain a "power-domains"
-property that is a phandle pointing to the corresponding PM domain node
-along with an index representing the device id to be passed to the PMMC
-for device control.
-
-Required Properties:
---------------------
-- power-domains: phandle pointing to the corresponding PM domain node
-		 and an ID representing the device.
-
-See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list
-of valid identifiers for k2g.
-
-Example (K2G):
---------------------
-	uart0: serial at 2530c00 {
-		compatible = "ns16550a";
-		...
-		power-domains = <&k2g_pds 0x002c>;
-	};
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
new file mode 100644
index 000000000000..9e6cb4ee9755
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI generic power domain node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+allOf:
+  - $ref: /schemas/power/power-domain.yaml#
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This PM domain node represents the global PM domain managed by the TI-SCI
+  controller. Since this relies on the TI SCI protocol to communicate with
+  the TI-SCI controller, it must be a child of the TI-SCI controller node.
+
+properties:
+  compatible:
+    const: ti,sci-pm-domain
+
+  "#power-domain-cells":
+    enum: [1, 2]
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell, if cell-value is 2, should be one of the following
+      TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled
+      or
+      TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts.
+      Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+  - |
+    k2g_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <1>;
+    };
+
+  - |
+    k3_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Fri Apr 16 07:37:21 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 01:37:21 -0500
Subject: [PATCH 4/4] dt-bindings: arm: keystone: Convert ti, sci to json schema
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <20210416063721.20538-5-nm@ti.com>

Convert the ti,sci to json schema for better checks and documentation.

NOTE: This change does introduce a stricter naming convention for
TI-SCI controller nodes.

NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
 .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
 2 files changed, 129 insertions(+), 86 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml

diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
deleted file mode 100644
index 6f0cd31c1520..000000000000
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Message Protocol
---------------------------------------------------------------------
-
-Texas Instrument's processors including those belonging to Keystone generation
-of processors have separate hardware entity which is now responsible for the
-management of the System on Chip (SoC) system. These include various system
-level functions as well.
-
-An example of such an SoC is K2G, which contains the system control hardware
-block called Power Management Micro Controller (PMMC). This hardware block is
-initialized early into boot process and provides services to Operating Systems
-on multiple processors including ones running Linux.
-
-See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
-
-TI-SCI controller Device Node:
-=============================
-
-The TI-SCI node describes the Texas Instrument's System Controller entity node.
-This parent node may optionally have additional children nodes which describe
-specific functionality such as clocks, power domain, reset or additional
-functionality as may be required for the SoC. This hierarchy also describes the
-relationship between the TI-SCI parent node to the child node.
-
-Required properties:
--------------------
-- compatible:	should be "ti,k2g-sci" for TI 66AK2G SoC
-		should be "ti,am654-sci" for for TI AM654 SoC
-- mbox-names:
-	"rx" - Mailbox corresponding to receive path
-	"tx" - Mailbox corresponding to transmit path
-
-- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
-	  property should contain a phandle to the mailbox controller device
-	  node and an args specifier that will be the phandle to the intended
-	  sub-mailbox child node to be used for communication.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings. Also see
-Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
-controller that is used to communicate with this System controllers.
-
-Optional Properties:
--------------------
-- reg-names:
-	debug_messages - Map the Debug message region
-- reg:  register space corresponding to the debug_messages
-- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
-- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
-	for identification of host processing entities such as virtual
-	machines
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		ti,host-id = <2>;
-		mbox-names = "rx", "tx";
-		mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
-			<&msgmgr &msgmgr_proxy_pmmc_tx>;
-		reg-names = "debug_messages";
-		reg = <0x02921800 0x800>;
-	};
-
-
-TI-SCI Client Device Node:
-=========================
-
-Client nodes are maintained as children of the relevant TI-SCI device node.
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		...
-
-		my_clk_node: clk_node {
-			...
-			...
-		};
-
-		my_pd_node: pd_node {
-			...
-			...
-		};
-	};
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
new file mode 100644
index 000000000000..3e835ad84dc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI controller device node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+allOf:
+  - $ref: /schemas/mbox/mbox-consumer.yaml#
+
+description: |
+  Texas Instrument's processors including those belonging to Keystone generation
+  of processors have separate hardware entity which is now responsible for the
+  management of the System on Chip (SoC) system. These include various system
+  level functions as well.
+
+  An example of such an SoC is K2G, which contains the system control hardware
+  block called Power Management Micro Controller (PMMC). This hardware block is
+  initialized early into boot process and provides services to Operating Systems
+  on multiple processors including ones running Linux.
+
+  See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+
+  The TI-SCI node describes the Texas Instrument's System Controller entity node.
+  This parent node may optionally have additional children nodes which describe
+  specific functionality such as clocks, power domain, reset or additional
+  functionality as may be required for the SoC. This hierarchy also describes the
+  relationship between the TI-SCI parent node to the child node.
+
+properties:
+  $nodename:
+    pattern: "^system-controller@[0-9a-f]+$"
+
+  compatible:
+    oneOf:
+      - description: System controller on TI 66AK2G SoC and other K3 SoCs
+        items:
+          - const: ti,k2g-sci
+      - description: System controller on TI AM654 SoC
+        items:
+          - const: ti,am654-sci
+
+  reg-names:
+    description: |
+      Specifies the debug messages memory mapped region that is optionally
+      made available from TI-SCI controller.
+      - const: debug_messages
+
+  reg:
+    minItems: 1
+
+  mbox-names:
+    description: |
+      Specifies the mailboxes used to communicate with TI-SCI Controller
+      made available from TI-SCI controller.
+    items:
+      - const: rx
+      - const: tx
+
+  mboxes:
+    minItems: 2
+
+  ti,system-reboot-controller:
+    description: Determines If system reboot can be triggered by SoC reboot
+    type: boolean
+
+  ti,host-id:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      Value corresponding to the host ID assigned by Firmware
+      for identification of host processing entities such as virtual machines.
+
+required:
+  - compatible
+  - mbox-names
+  - mboxes
+
+additionalProperties: false
+
+patternProperties:
+  # All other properties should be a power, clock or reset controller
+  "^(power-controller|clock-controller|reset-controller)$":
+    type: object
+    oneOf:
+      - $ref: /schemas/soc/ti/sci-pm-domain.yaml#
+      - $ref: /schemas/clock/ti,sci-clk.yaml#
+      - $ref: /schemas/reset/ti,sci-reset.yaml#
+
+examples:
+  - |
+    pmmc: system-controller at 2921800 {
+      compatible = "ti,k2g-sci";
+      ti,system-reboot-controller;
+      mbox-names = "rx", "tx";
+      mboxes= <&msgmgr 5 2>,
+              <&msgmgr 0 0>;
+      reg-names = "debug_messages";
+      reg = <0x02921800 0x800>;
+    };
+
+  - |
+    dmsc: system-controller at 44083000 {
+      compatible = "ti,k2g-sci";
+      ti,host-id = <12>;
+      mbox-names = "rx", "tx";
+      mboxes= <&secure_proxy_main 11>,
+              <&secure_proxy_main 13>;
+      reg-names = "debug_messages";
+      reg = <0x44083000 0x1000>;
+
+      k3_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <2>;
+      };
+
+      k3_clks: clock-controller {
+        compatible = "ti,k2g-sci-clk";
+        #clock-cells = <2>;
+      };
+
+      k3_reset: reset-controller {
+        compatible = "ti,sci-reset";
+        #reset-cells = <2>;
+      };
+    };
-- 
2.31.0



From gabriel.fernandez at foss.st.com  Fri Apr 16 07:44:25 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 16 Apr 2021 08:44:25 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
 <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
Message-ID: <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>

Hi Marek

On 4/14/21 4:04 PM, Marek Vasut wrote:
> On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
>> Hi Marek,
> 
> Hello Gabriel,
> 
>> Thanks for the patchset
>>
>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>> The ETHCK_K are modeled as composite clock of MUX and GATE, however per
>>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. Peripheral
>>> clock distribution for Ethernet, ETHPTPDIV divider is attached past the
>>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN gate.
>>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
>>> in use, ETHCKEN gate can be turned off. Current driver does not permit
>>> that, fix it.
>>
>> I don"t understand, it's already the case.
>>
>> ETHCK_K it's a composite with a MUX and a GATE.
> 
> But ETHCK_K is _not_ a composite clock, look at the Figure 83 in the 
> datasheet again and schematic below.
> 
>> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV (no 
>> gate)
> 
> But ETHPTP_K shouldn't control any mux, it is only a divider.
> 
>> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.
> 
> Look, this is what you have today:
> 
>  ?????????? .------------ ETHCK_K -----------.
>  ?????????? |_______?????????????? _______?? |
> pll4_p_ck--|M_ETHCK\???????????? |G_ETHCK\? |
>  ?????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>  ?????????? |?????????????? |
>  ?????????? |?????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>  ?????????? |????????????????????????????????????????? |
>  ?????????? '------------ ETHPTP_K --------------------'
> 
> And this is what you should have, to avoid having two composite clock 
> which control the same mux using the same register bit, i.e. what this 
> patch implements:
> 
>  ?????????? .- ck_ker_eth -.? .--- ETHCK_K --.
>  ?????????? |_______?????? |? |??? _______?? |
> pll4_p_ck--|M_ETHCK\????? |? |?? |G_ETHCK\? |
>  ?????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>  ?????????????????????????? |
>  ?????????????????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>  ??????????????????????????? |???????????????????????? |
>  ??????????????????????????? '---- ETHPTP_K -----------'
> 

These 2 solutions are valid. I made the choice to implement the first 
one to be able to change parent with the kernel clock of the IP (no need 
to add an intermediate binding). It's the same principle for all kernel 
of this soc.
I can ask to Alexandre to comeback of this principle, but i 'm not 
favorable.

>>> This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
>>> ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
>>> NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent clock
>>> to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
>>> ETHPTP_K remain functional as before.
>>>
>>> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>>> ???? Figure 83. Peripheral clock distribution for Ethernet
>>> https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf 
>>>
> 
> [...]
> 
>>> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
>>> index a875649df8b8..a7c7f544ee5d 100644
>>> --- a/drivers/clk/clk-stm32mp1.c
>>> +++ b/drivers/clk/clk-stm32mp1.c
>>> @@ -1949,7 +1949,6 @@ static const struct clock_config 
>>> stm32mp1_clock_cfg[] = {
>>> ????? KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
>>> ????? KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
>>> ????? KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
>>> -??? KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
>>> ????? /* Particulary Kernel Clocks (no mux or no gate) */
>>> ????? MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
>>> @@ -1958,11 +1957,16 @@ static const struct clock_config 
>>> stm32mp1_clock_cfg[] = {
>>> ????? MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
>>> ????? MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
>>> -??? COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
>>> +??? COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
>>> ??????????? CLK_SET_RATE_NO_REPARENT,
>>> ??????????? _NO_GATE,
>>> ??????????? _MMUX(M_ETHCK),
>>> -????????? _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
>>> +????????? _NO_DIV),
>>> +
>>> +??? MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
>> assigned parent with ETHCK_K will not work
>>> +
>>> +??? DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |
>>
>> CLK_OPS_PARENT_ENABLE flags not useful with a divider.
> 
> How so ?


From gabriel.fernandez at foss.st.com  Fri Apr 16 07:44:28 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Fri, 16 Apr 2021 08:44:28 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it
 with np
In-Reply-To: <20210408185731.135511-3-marex@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-3-marex@denx.de>
Message-ID: <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>

Hi Marek,

I have a patch-set in progress using $dev (convertion into module driver).

https://patchwork.kernel.org/project/linux-clk/list/?series=421767

Then rebase of your patch, [PATCH 4/7] clk: stm32mp1: Add parent_data to 
ETHRX clock, can be done easily.

Best regards
Gabriel

On 4/8/21 8:57 PM, Marek Vasut wrote:
> Instead of passing around $dev to all the registration functions, which
> is always NULL, pass around struct device_node pointer $np. This way it
> is possible to use of_clk_hw_register*() functions and/or register clock
> with associated $np pointer.
> 
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: Christophe Roullier <christophe.roullier at foss.st.com>
> Cc: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> Cc: Patrice Chotard <patrice.chotard at foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay at foss.st.com>
> Cc: Stephen Boyd <swboyd at chromium.org>
> Cc: linux-clk at vger.kernel.org
> Cc: linux-stm32 at st-md-mailman.stormreply.com
> To: linux-arm-kernel at lists.infradead.org
> ---
>   drivers/clk/clk-stm32mp1.c | 56 +++++++++++++++++++-------------------
>   1 file changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
> index a7c7f544ee5d..cf5a1d055c5a 100644
> --- a/drivers/clk/clk-stm32mp1.c
> +++ b/drivers/clk/clk-stm32mp1.c
> @@ -317,7 +317,7 @@ struct clock_config {
>   	int num_parents;
>   	unsigned long flags;
>   	void *cfg;
> -	struct clk_hw * (*func)(struct device *dev,
> +	struct clk_hw * (*func)(struct device_node *np,
>   				struct clk_hw_onecell_data *clk_data,
>   				void __iomem *base, spinlock_t *lock,
>   				const struct clock_config *cfg);
> @@ -377,14 +377,14 @@ struct stm32_composite_cfg {
>   };
>   
>   static struct clk_hw *
> -_clk_hw_register_gate(struct device *dev,
> +_clk_hw_register_gate(struct device_node *np,
>   		      struct clk_hw_onecell_data *clk_data,
>   		      void __iomem *base, spinlock_t *lock,
>   		      const struct clock_config *cfg)
>   {
>   	struct gate_cfg *gate_cfg = cfg->cfg;
>   
> -	return clk_hw_register_gate(dev,
> +	return clk_hw_register_gate(NULL,
>   				    cfg->name,
>   				    cfg->parent_name,
>   				    cfg->flags,
> @@ -395,27 +395,27 @@ _clk_hw_register_gate(struct device *dev,
>   }
>   
>   static struct clk_hw *
> -_clk_hw_register_fixed_factor(struct device *dev,
> +_clk_hw_register_fixed_factor(struct device_node *np,
>   			      struct clk_hw_onecell_data *clk_data,
>   			      void __iomem *base, spinlock_t *lock,
>   			      const struct clock_config *cfg)
>   {
>   	struct fixed_factor_cfg *ff_cfg = cfg->cfg;
>   
> -	return clk_hw_register_fixed_factor(dev, cfg->name, cfg->parent_name,
> +	return clk_hw_register_fixed_factor(NULL, cfg->name, cfg->parent_name,
>   					    cfg->flags, ff_cfg->mult,
>   					    ff_cfg->div);
>   }
>   
>   static struct clk_hw *
> -_clk_hw_register_divider_table(struct device *dev,
> +_clk_hw_register_divider_table(struct device_node *np,
>   			       struct clk_hw_onecell_data *clk_data,
>   			       void __iomem *base, spinlock_t *lock,
>   			       const struct clock_config *cfg)
>   {
>   	struct div_cfg *div_cfg = cfg->cfg;
>   
> -	return clk_hw_register_divider_table(dev,
> +	return clk_hw_register_divider_table(NULL,
>   					     cfg->name,
>   					     cfg->parent_name,
>   					     cfg->flags,
> @@ -428,14 +428,14 @@ _clk_hw_register_divider_table(struct device *dev,
>   }
>   
>   static struct clk_hw *
> -_clk_hw_register_mux(struct device *dev,
> +_clk_hw_register_mux(struct device_node *np,
>   		     struct clk_hw_onecell_data *clk_data,
>   		     void __iomem *base, spinlock_t *lock,
>   		     const struct clock_config *cfg)
>   {
>   	struct mux_cfg *mux_cfg = cfg->cfg;
>   
> -	return clk_hw_register_mux(dev, cfg->name, cfg->parent_names,
> +	return clk_hw_register_mux(NULL, cfg->name, cfg->parent_names,
>   				   cfg->num_parents, cfg->flags,
>   				   mux_cfg->reg_off + base, mux_cfg->shift,
>   				   mux_cfg->width, mux_cfg->mux_flags, lock);
> @@ -570,7 +570,7 @@ _get_stm32_gate(void __iomem *base,
>   }
>   
>   static struct clk_hw *
> -clk_stm32_register_gate_ops(struct device *dev,
> +clk_stm32_register_gate_ops(struct device_node *np,
>   			    const char *name,
>   			    const char *parent_name,
>   			    unsigned long flags,
> @@ -598,7 +598,7 @@ clk_stm32_register_gate_ops(struct device *dev,
>   
>   	hw->init = &init;
>   
> -	ret = clk_hw_register(dev, hw);
> +	ret = clk_hw_register(NULL, hw);
>   	if (ret)
>   		hw = ERR_PTR(ret);
>   
> @@ -606,7 +606,7 @@ clk_stm32_register_gate_ops(struct device *dev,
>   }
>   
>   static struct clk_hw *
> -clk_stm32_register_composite(struct device *dev,
> +clk_stm32_register_composite(struct device_node *np,
>   			     const char *name, const char * const *parent_names,
>   			     int num_parents, void __iomem *base,
>   			     const struct stm32_composite_cfg *cfg,
> @@ -655,7 +655,7 @@ clk_stm32_register_composite(struct device *dev,
>   		}
>   	}
>   
> -	return clk_hw_register_composite(dev, name, parent_names, num_parents,
> +	return clk_hw_register_composite(NULL, name, parent_names, num_parents,
>   				       mux_hw, mux_ops, div_hw, div_ops,
>   				       gate_hw, gate_ops, flags);
>   }
> @@ -863,7 +863,7 @@ static const struct clk_ops pll_ops = {
>   	.is_enabled	= pll_is_enabled,
>   };
>   
> -static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
> +static struct clk_hw *clk_register_pll(struct device_node *np, const char *name,
>   				       const char *parent_name,
>   				       void __iomem *reg,
>   				       unsigned long flags,
> @@ -889,7 +889,7 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
>   	element->lock = lock;
>   
>   	hw = &element->hw;
> -	err = clk_hw_register(dev, hw);
> +	err = clk_hw_register(NULL, hw);
>   
>   	if (err) {
>   		kfree(element);
> @@ -993,7 +993,7 @@ static const struct clk_ops timer_ker_ops = {
>   
>   };
>   
> -static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
> +static struct clk_hw *clk_register_cktim(struct device_node *np, const char *name,
>   					 const char *parent_name,
>   					 unsigned long flags,
>   					 void __iomem *apbdiv,
> @@ -1021,7 +1021,7 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
>   	tim_ker->timpre = timpre;
>   
>   	hw = &tim_ker->hw;
> -	err = clk_hw_register(dev, hw);
> +	err = clk_hw_register(NULL, hw);
>   
>   	if (err) {
>   		kfree(tim_ker);
> @@ -1035,14 +1035,14 @@ struct stm32_pll_cfg {
>   	u32 offset;
>   };
>   
> -static struct clk_hw *_clk_register_pll(struct device *dev,
> +static struct clk_hw *_clk_register_pll(struct device_node *np,
>   					struct clk_hw_onecell_data *clk_data,
>   					void __iomem *base, spinlock_t *lock,
>   					const struct clock_config *cfg)
>   {
>   	struct stm32_pll_cfg *stm_pll_cfg = cfg->cfg;
>   
> -	return clk_register_pll(dev, cfg->name, cfg->parent_name,
> +	return clk_register_pll(np, cfg->name, cfg->parent_name,
>   				base + stm_pll_cfg->offset, cfg->flags, lock);
>   }
>   
> @@ -1051,25 +1051,25 @@ struct stm32_cktim_cfg {
>   	u32 offset_timpre;
>   };
>   
> -static struct clk_hw *_clk_register_cktim(struct device *dev,
> +static struct clk_hw *_clk_register_cktim(struct device_node *np,
>   					  struct clk_hw_onecell_data *clk_data,
>   					  void __iomem *base, spinlock_t *lock,
>   					  const struct clock_config *cfg)
>   {
>   	struct stm32_cktim_cfg *cktim_cfg = cfg->cfg;
>   
> -	return clk_register_cktim(dev, cfg->name, cfg->parent_name, cfg->flags,
> +	return clk_register_cktim(np, cfg->name, cfg->parent_name, cfg->flags,
>   				  cktim_cfg->offset_apbdiv + base,
>   				  cktim_cfg->offset_timpre + base, lock);
>   }
>   
>   static struct clk_hw *
> -_clk_stm32_register_gate(struct device *dev,
> +_clk_stm32_register_gate(struct device_node *np,
>   			 struct clk_hw_onecell_data *clk_data,
>   			 void __iomem *base, spinlock_t *lock,
>   			 const struct clock_config *cfg)
>   {
> -	return clk_stm32_register_gate_ops(dev,
> +	return clk_stm32_register_gate_ops(np,
>   				    cfg->name,
>   				    cfg->parent_name,
>   				    cfg->flags,
> @@ -1079,12 +1079,12 @@ _clk_stm32_register_gate(struct device *dev,
>   }
>   
>   static struct clk_hw *
> -_clk_stm32_register_composite(struct device *dev,
> +_clk_stm32_register_composite(struct device_node *np,
>   			      struct clk_hw_onecell_data *clk_data,
>   			      void __iomem *base, spinlock_t *lock,
>   			      const struct clock_config *cfg)
>   {
> -	return clk_stm32_register_composite(dev, cfg->name, cfg->parent_names,
> +	return clk_stm32_register_composite(np, cfg->name, cfg->parent_names,
>   					    cfg->num_parents, base, cfg->cfg,
>   					    cfg->flags, lock);
>   }
> @@ -2020,7 +2020,7 @@ static const struct of_device_id stm32mp1_match_data[] = {
>   	{ }
>   };
>   
> -static int stm32_register_hw_clk(struct device *dev,
> +static int stm32_register_hw_clk(struct device_node *np,
>   				 struct clk_hw_onecell_data *clk_data,
>   				 void __iomem *base, spinlock_t *lock,
>   				 const struct clock_config *cfg)
> @@ -2031,7 +2031,7 @@ static int stm32_register_hw_clk(struct device *dev,
>   	hws = clk_data->hws;
>   
>   	if (cfg->func)
> -		hw = (*cfg->func)(dev, clk_data, base, lock, cfg);
> +		hw = (*cfg->func)(np, clk_data, base, lock, cfg);
>   
>   	if (IS_ERR(hw)) {
>   		pr_err("Unable to register %s\n", cfg->name);
> @@ -2077,7 +2077,7 @@ static int stm32_rcc_init(struct device_node *np,
>   		hws[n] = ERR_PTR(-ENOENT);
>   
>   	for (n = 0; n < data->num; n++) {
> -		err = stm32_register_hw_clk(NULL, clk_data, base, &rlock,
> +		err = stm32_register_hw_clk(np, clk_data, base, &rlock,
>   					    &data->cfg[n]);
>   		if (err) {
>   			pr_err("%s: can't register  %s\n", __func__,
> 


From chunfeng.yun at mediatek.com  Fri Apr 16 07:48:26 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 16 Apr 2021 14:48:26 +0800
Subject: [next PATCH] usb: xhci-mtk: remove bus status check
Message-ID: <1618555706-6810-1-git-send-email-chunfeng.yun@mediatek.com>

PM will take care of the status of child device, so no need
check each port anymore.

Suggested-by: Ikjoon Jang <ikjn at chromium.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 43 ++-----------------------------------
 1 file changed, 2 insertions(+), 41 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index d4c455eecb8d..1fdeb315a124 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -654,42 +654,6 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
 	return ret;
 }
 
-static int check_rhub_status(struct xhci_hcd *xhci, struct xhci_hub *rhub)
-{
-	u32 suspended_ports;
-	u32 status;
-	int num_ports;
-	int i;
-
-	num_ports = rhub->num_ports;
-	suspended_ports = rhub->bus_state.suspended_ports;
-	for (i = 0; i < num_ports; i++) {
-		if (!(suspended_ports & BIT(i))) {
-			status = readl(rhub->ports[i]->addr);
-			if (status & PORT_CONNECT)
-				return -EBUSY;
-		}
-	}
-
-	return 0;
-}
-
-/*
- * check the bus whether it could suspend or not
- * the bus will suspend if the downstream ports are already suspended,
- * or no devices connected.
- */
-static int check_bus_status(struct xhci_hcd *xhci)
-{
-	int ret;
-
-	ret = check_rhub_status(xhci, &xhci->usb3_rhub);
-	if (ret)
-		return ret;
-
-	return check_rhub_status(xhci, &xhci->usb2_rhub);
-}
-
 static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
 {
 	struct xhci_hcd_mtk  *mtk = dev_get_drvdata(dev);
@@ -699,11 +663,8 @@ static int __maybe_unused xhci_mtk_runtime_suspend(struct device *dev)
 	if (xhci->xhc_state)
 		return -ESHUTDOWN;
 
-	if (device_may_wakeup(dev)) {
-		ret = check_bus_status(xhci);
-		if (!ret)
-			ret = xhci_mtk_suspend(dev);
-	}
+	if (device_may_wakeup(dev))
+		ret = xhci_mtk_suspend(dev);
 
 	/* -EBUSY: let PM automatically reschedule another autosuspend */
 	return ret ? -EBUSY : 0;
-- 
2.18.0

From laurent.pinchart at ideasonboard.com  Fri Apr 16 07:49:35 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 16 Apr 2021 09:49:35 +0300
Subject: [PATCH V2] drm/bridge: lvds-codec: Add support for pixel data
 sampling edge select
In-Reply-To: <YFhze79nDdtf7KQS@pendragon.ideasonboard.com>
References: <20201224061832.92010-1-marex@denx.de>
 <YFfvjyllBa/tqTqI@pendragon.ideasonboard.com>
 <4372d1cd-ffdb-e545-7262-d1ad1a649770@denx.de>
 <YFhze79nDdtf7KQS@pendragon.ideasonboard.com>
Message-ID: <YHkzf0fswqGYbU7R@pendragon.ideasonboard.com>

Hi Rob,

There's a question for you below.

On Mon, Mar 22, 2021 at 12:37:47PM +0200, Laurent Pinchart wrote:
> Hi Marek,
> 
> (CC'ing Ron and the DT mailing list for the DT discussion)
> 
> On Mon, Mar 22, 2021 at 11:29:04AM +0100, Marek Vasut wrote:
> > On 3/22/21 2:14 AM, Laurent Pinchart wrote:
> > > Hi Marek,
> > 
> > Hi,
> > 
> > [...]
> > 
> > >> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > >> index e5e3c72630cf..399a6528780a 100644
> > >> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > >> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > >> @@ -74,6 +74,13 @@ properties:
> > >>   
> > >>       additionalProperties: false
> > >>   
> > >> +  pixelclk-active:
> > >> +    description: |
> > >> +      Data sampling on rising or falling edge.
> > >> +      Use 0 to sample pixel data on rising edge and
> > >> +      Use 1 to sample pixel data on falling edge and
> > >> +    enum: [0, 1]
> > > 
> > > The idea is good, but instead of adding a custom property, how about
> > > reusing the pclk-sample property defined in
> > > ../../media/video-interfaces.yaml ?
> > 
> > Repeating myself from V1 discussion ... Either is fine by me, but I 
> > think pixelclk-active, which comes from panel-timings.yaml is closer to 
> > the video than multimedia bindings.
> 
> That's a good point. The part that bothers me a bit is that it would be
> nice to define the property in a single YAML schema, referenced by
> individual bindings. video-interfaces.yaml is there for that purpose. We
> could do something similar on the display side, or consider the
> pixelclk-active usage in panel-timings.yaml an exception that we can't
> switch to video-interfaces.yaml as backward compatibility must be
> preserved.
> 
> I don't have a too strong preference, whatever Rob prefers would be fine
> with me.
> 
> > > The property is only valid for encoders, so I would at least mention
> > > that in the description, or, better, handle this based on the compatible
> > > string to allow validation.
> > 
> > How does that work in the Yaml file ?
> 
> Something along the lines of
> 
> if:
>   not:
>     properties:
>       compatible:
>         contains:
>           const: lvds-encoder
> then:
>   properties:
>     pixelclk-active: false
> 
> My YAML schema foo is a bit rusty though, I apologize if this doesn't
> work as-is. There are lots of similar examples in DT bindings that
> should hopefully be right :-)
> 
> > >> +
> > >>     powerdown-gpios:
> > >>       description:
> > >>         The GPIO used to control the power down line of this device.
> > >> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
> > >> index dcf579a4cf83..cab81ccd895d 100644
> > >> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > >> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > 
> > [...]
> > 
> > >> @@ -126,6 +146,7 @@ static int lvds_codec_probe(struct platform_device *pdev)
> > >>   	 */
> > >>   	lvds_codec->bridge.of_node = dev->of_node;
> > >>   	lvds_codec->bridge.funcs = &funcs;
> > >> +	lvds_codec->bridge.timings = &lvds_codec->timings;
> > >>   	drm_bridge_add(&lvds_codec->bridge);
> > >>   
> > >>   	platform_set_drvdata(pdev, lvds_codec);
> > >> @@ -142,19 +163,20 @@ static int lvds_codec_remove(struct platform_device *pdev)
> > >>   	return 0;
> > >>   }
> > >>   
> > >> +static const struct lvds_codec_data decoder_data = {
> > >> +	.connector_type = DRM_MODE_CONNECTOR_DPI,
> > >> +	.is_encoder = false,
> > > 
> > > The two fields are a bit redundant, as the decoder is always
> > > LVDS-to-DPI, and the encoder DPI-to-LVDS. I don't mind too much, but
> > > maybe we could drop the connector_type field, and derive the connector
> > > type from is_encoder ?
> > 
> > Or the other way around instead ? That is, if the connector_type is 
> > LVDS, then it is encoder , otherwise its decoder ?
> 
> Either way works for me.
> 
> > > One may then say that we could drop the lvds_codec_data structure as it
> > > contains a single field, but I foresee a need to have device-specific
> > > timings at some point, so I think it's a good addition.
> > 
> > [...]

-- 
Regards,

Laurent Pinchart


From gregkh at linuxfoundation.org  Fri Apr 16 07:54:00 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 16 Apr 2021 08:54:00 +0200
Subject: [PATCH 0/1] coresight: Fix for v5.12-rc7
In-Reply-To: <20210415202404.945368-1-mathieu.poirier@linaro.org>
References: <20210415202404.945368-1-mathieu.poirier@linaro.org>
Message-ID: <YHk0iDnfujBR3mTB@kroah.com>

On Thu, Apr 15, 2021 at 02:24:03PM -0600, Mathieu Poirier wrote:
> Hi Greg,
> 
> Please consider this patch as a fix for v5.12-rc7.  Applies cleanly
> to your char-misc-linus branch (e49d033bddf5).

It's too late for 5.12-final, and really my tree should be closed for
5.13-rc1 now.  I can sneak this in for the merge window, is that ok?

thanks,

greg k-h


From dja at axtens.net  Fri Apr 16 07:57:27 2021
From: dja at axtens.net (Daniel Axtens)
Date: Fri, 16 Apr 2021 16:57:27 +1000
Subject: [PATCH] soc: fsl: qe: remove unused function
In-Reply-To: <1618475663-100748-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1618475663-100748-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <87blaeg1ig.fsf@linkitivity.dja.id.au>

Hi Jiapeng,

> Fix the following clang warning:
>
> drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
> 'qe_ic_from_irq' [-Wunused-function].
>
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
> ---
>  drivers/soc/fsl/qe/qe_ic.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
> index 0390af9..b573712 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32  __iomem *base, unsigned int reg,
>  	qe_iowrite32be(value, base + (reg >> 2));
>  }
>  
> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
> -{
> -	return irq_get_chip_data(virq);
> -}

This seems good to me.

 * We know that this function can't be called directly from outside the
  file, because it is static.

 * The function address isn't used as a function pointer anywhere, so
   that means it can't be called from outside the file that way (also
   it's inline, which would make using a function pointer unwise!)

 * There's no obvious macros in that file that might construct the name
   of the function in a way that is hidden from grep.

All in all, I am fairly confident that the function is indeed not used.

Reviewed-by: Daniel Axtens <dja at axtens.net>

Kind regards,
Daniel

> -
>  static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>  {
>  	return irq_data_get_irq_chip_data(d);
> -- 
> 1.8.3.1


From christophe.leroy at csgroup.eu  Fri Apr 16 08:06:23 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 09:06:23 +0200
Subject: [PATCH] soc: fsl: qe: remove unused function
In-Reply-To: <87blaeg1ig.fsf@linkitivity.dja.id.au>
References: <1618475663-100748-1-git-send-email-jiapeng.chong@linux.alibaba.com>
 <87blaeg1ig.fsf@linkitivity.dja.id.au>
Message-ID: <76468b5b-0eb0-8772-b7b5-21bb708aa053@csgroup.eu>



Le 16/04/2021 ? 08:57, Daniel Axtens a ?crit?:
> Hi Jiapeng,
> 
>> Fix the following clang warning:

You are not fixing a warning, you are removing a function in order to fix a warning ...

>>
>> drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
>> 'qe_ic_from_irq' [-Wunused-function].

Would be wise to tell that the last users of the function where removed by commit d7c2878cfcfa 
("soc: fsl: qe: remove unused qe_ic_set_* functions")

https://github.com/torvalds/linux/commit/d7c2878cfcfa

>>
>> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
>> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
>> ---
>>   drivers/soc/fsl/qe/qe_ic.c | 5 -----
>>   1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
>> index 0390af9..b573712 100644
>> --- a/drivers/soc/fsl/qe/qe_ic.c
>> +++ b/drivers/soc/fsl/qe/qe_ic.c
>> @@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32  __iomem *base, unsigned int reg,
>>   	qe_iowrite32be(value, base + (reg >> 2));
>>   }
>>   
>> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
>> -{
>> -	return irq_get_chip_data(virq);
>> -}
> 
> This seems good to me.
> 
>   * We know that this function can't be called directly from outside the
>    file, because it is static.
> 
>   * The function address isn't used as a function pointer anywhere, so
>     that means it can't be called from outside the file that way (also
>     it's inline, which would make using a function pointer unwise!)
> 
>   * There's no obvious macros in that file that might construct the name
>     of the function in a way that is hidden from grep.
> 
> All in all, I am fairly confident that the function is indeed not used.
> 
> Reviewed-by: Daniel Axtens <dja at axtens.net>
> 
> Kind regards,
> Daniel
> 
>> -
>>   static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>>   {
>>   	return irq_data_get_irq_chip_data(d);
>> -- 
>> 1.8.3.1


From David.Laight at ACULAB.COM  Fri Apr 16 08:32:35 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Fri, 16 Apr 2021 07:32:35 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210415222211.GG2531743@casper.infradead.org>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210415182155.GD2531743@casper.infradead.org>
 <5179a01a462f43d6951a65de2a299070@AcuMS.aculab.com>
 <20210415222211.GG2531743@casper.infradead.org>
Message-ID: <f51e1aa98cb94880a236d58c75c20994@AcuMS.aculab.com>

From: Matthew Wilcox <willy at infradead.org>
> Sent: 15 April 2021 23:22
> 
> On Thu, Apr 15, 2021 at 09:11:56PM +0000, David Laight wrote:
> > Isn't it possible to move the field down one long?
> > This might require an explicit zero - but this is not a common
> > code path - the extra write will be noise.
> 
> Then it overlaps page->mapping.  See emails passim.

The rules on overlaps make be wonder if every 'long'
should be in its own union.
The comments would need to say when each field is used.
It would, at least, make these errors less common.

That doesn't solve the 64bit dma_addr though.

Actually rather that word-swapping dma_addr on 32bit BE
could you swap over the two fields it overlays with.
That might look messy in the .h, but it doesn't require
an accessor function to do the swap - easily missed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From yulei.sh at bytedance.com  Fri Apr 16 08:35:01 2021
From: yulei.sh at bytedance.com (Lei Yu)
Date: Fri, 16 Apr 2021 15:35:01 +0800
Subject: [External] Re: [PATCH v1] ARM: dts: Fix 64MiB OpenBMC flash
 layout and aspeed-ast2600-evb.dts
In-Reply-To: <CACPK8XeYtaLLWDMR8xZhERrQ_WCUJ2RM_JZmZNQ6oZSvgSDM_w@mail.gmail.com>
References: <20210316085932.2601-1-troy_lee@aspeedtech.com>
 <CACPK8XeYtaLLWDMR8xZhERrQ_WCUJ2RM_JZmZNQ6oZSvgSDM_w@mail.gmail.com>
Message-ID: <CAGm54UHgQSMh8WLzRf7Swhv9mmzNBuEK6eKf9eX0ASp95hjARw@mail.gmail.com>

On Fri, Apr 16, 2021 at 11:03 AM Joel Stanley <joel at jms.id.au> wrote:
>
> On Tue, 16 Mar 2021 at 08:59, Troy Lee <troy_lee at aspeedtech.com> wrote:
> >
> > Aspeed AST2600 u-boot requires 600KiB+ flash space. Sharing the same
> > openbmc-flash-layout-64.dtsi requires to resize the flash partition.
> >
> > The updated flash layout as follows:
> > - u-boot: 896 KiB
> > - u-boot-env: 128 KiB
> > - kernel: 9MiB
> > - rofs: 32 MiB
> > - rwfs: 22 MiB
>
> Changing the 64MB layout will break the systems that are already using
> this layout. I'll get the Bytedance people to chime in, as theirs is
> the only system using this layout so far.
>
> John, Lei?

Because the kernel's offset is updated, several other changes are required:
1. The related offsets, which is already sent to
https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/39343
2. The u-boot patch to update the `bootm` address and make sure it
only applies to the 64MiB layout.

Without the above two changes, I would suggest holding the merge.

-- 
BRs,
Lei YU


From gregkh at linuxfoundation.org  Fri Apr 16 08:36:45 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 16 Apr 2021 09:36:45 +0200
Subject: [PATCH 0/1] coresight: Fix for v5.12-rc7
In-Reply-To: <YHk0iDnfujBR3mTB@kroah.com>
References: <20210415202404.945368-1-mathieu.poirier@linaro.org>
 <YHk0iDnfujBR3mTB@kroah.com>
Message-ID: <YHk+jRT/164eCnWa@kroah.com>

On Fri, Apr 16, 2021 at 08:54:00AM +0200, Greg KH wrote:
> On Thu, Apr 15, 2021 at 02:24:03PM -0600, Mathieu Poirier wrote:
> > Hi Greg,
> > 
> > Please consider this patch as a fix for v5.12-rc7.  Applies cleanly
> > to your char-misc-linus branch (e49d033bddf5).
> 
> It's too late for 5.12-final, and really my tree should be closed for
> 5.13-rc1 now.  I can sneak this in for the merge window, is that ok?

I've just taken it for my 5.13-rc1 set of patches and added a cc: stable
to get it backported to 5.12.1.

thanks,

greg k-h


From ruifeng.zhang0110 at gmail.com  Fri Apr 16 08:47:15 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Fri, 16 Apr 2021 15:47:15 +0800
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
Message-ID: <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??4:10???
>
> On 15/04/2021 20:09, Valentin Schneider wrote:
> > On 14/04/21 20:23, Ruifeng Zhang wrote:
> >> From: Ruifeng Zhang <ruifeng.zhang1 at unisoc.com>
> >>
> >> In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
> >> version, one of them is the kernel running on EL1 using aarch32.
> >>                 user(EL0)             kernel(EL1)
> >> sc9863a_go      aarch32               aarch32
> >> sc9863a         aarch64               aarch64
> >>
> >> When kernel runs on EL1 using aarch32, the topology will parse wrong.
> >> For example,
> >> The MPIDR has been written to the chip register in armv8.2 format.
> >> For example,
> >> core0: 0000000080000000
> >> core1: 0000000080000100
> >> core2: 0000000080000200
> >> ...
> >>
> >> It will parse to:
> >> |       | aff2 | packageid | coreid |
> >> |-------+------+-----------+--------|
> >> | Core0 |    0 |         0 |    0   |
> >> | Core1 |    0 |         1 |    0   |
> >> | Core2 |    0 |         2 |    0   |
> >> |  ...  |      |           |        |
> >>
> >> The wrong topology is that all of the coreid are 0 and unexpected
> >> packageid.
> >>
> >> The reason is the MPIDR format is different between armv7 and armv8.2.
> >> armv7 (A7) mpidr is:
> >> [11:8]      [7:2]       [1:0]
> >> cluster     reserved    cpu
> >> The cortex-a7 spec DDI0464F 4.3.5
> >> https://developer.arm.com/documentation/ddi0464/f/?lang=en
> >>
> >> armv8.2 (A55) mpidr is:
> >> [23:16]     [15:8]      [7:0]
> >> cluster     cpu         thread
> >>
> >
> > What I had understood from our conversation was that there *isn't* a format
> > difference (at least for the bottom 32 bits) - arm64/kernel/topopology.c
> > would parse it the same, except that MPIDR parsing has been deprecated for
> > arm64.

I agree, I should change my description.

> >
> > The problem is that those MPIDR values don't match the actual topology. If
> > they had the MT bit set, i.e.
> >
> >   core0: 0000000081000000
> >   core1: 0000000081000100
> >   core2: 0000000081000200
> >
> > then it would be parsed as:
> >
> >   |       | package_id | core_id | thread_id |
> >   |-------+------------+---------+-----------|
> >   | Core0 |          0 |       0 |         0 |
> >   | Core1 |          0 |       1 |         0 |
> >   | Core2 |          0 |       2 |         0 |
> >
> > which would make more sense (wrt the actual, physical topology).
>
> ... and this would be in sync with
> https://developer.arm.com/documentation/100442/0200/register-descriptions/aarch32-system-registers/mpidr--multiprocessor-affinity-register
>
> MT, [24]
>
>    0b1 ...
>
> There is no 0b0 for MT.
>
As you said, the MT must be 0b1, so the {aff1} means coreid for A55.
It's no problem for parsing coreid.

For more requirements, if all cores in one physical cluster, the
{aff2} of all cores are the same value.
i.e. the sc9863a,
core0: 0000000081000000
core1: 0000000081000100
core2: 0000000081000200
core3: 0000000081000300
core4: 0000000081000400
core5: 0000000081000500
core6: 0000000081000600
core7: 0000000081000700

According to MPIDR all cores will parse to the one cluster, but it's
the big.LITTLE system, it's need two logic cluster for schedule or
cpufreq.
So I think it's better to add the logic of parse topology from DT.


From eballetbo at gmail.com  Fri Apr 16 08:50:50 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 09:50:50 +0200
Subject: [PATCH v5, 1/4] soc: mediatek: mmsys: add component OVL_2L2
In-Reply-To: <1618236288-1617-2-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618236288-1617-2-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <CAFqH_50wSBVHnkzr1+Jh=1pppM7rKwZLjkVwhZnBnO=zEo46CA@mail.gmail.com>

Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu <yongqiang.niu at mediatek.com> del dia dl., 12
d?abr. 2021 a les 16:04:
>
> This patch add component OVL_2L2
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
> Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
> index 2228bf6..f6b58f9 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
>         DDP_COMPONENT_OVL0,
>         DDP_COMPONENT_OVL_2L0,
>         DDP_COMPONENT_OVL_2L1,
> +       DDP_COMPONENT_OVL_2L2,
>         DDP_COMPONENT_OVL1,
>         DDP_COMPONENT_PWM0,
>         DDP_COMPONENT_PWM1,
> --
> 1.8.1.1.dirty
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From eballetbo at gmail.com  Fri Apr 16 08:51:36 2021
From: eballetbo at gmail.com (Enric Balletbo Serra)
Date: Fri, 16 Apr 2021 09:51:36 +0200
Subject: [PATCH v5, 2/4] soc: mediatek: mmsys: add component POSTMASK
In-Reply-To: <1618236288-1617-3-git-send-email-yongqiang.niu@mediatek.com>
References: <1618236288-1617-1-git-send-email-yongqiang.niu@mediatek.com>
 <1618236288-1617-3-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <CAFqH_50kRmQLukyRERwtRGErETuKP8jry9+oG1CSX+=-Ckz7gw@mail.gmail.com>

Hi Yongqiang,

Thank you for your patch.

Missatge de Yongqiang Niu <yongqiang.niu at mediatek.com> del dia dl., 12
d?abr. 2021 a les 16:05:
>
> This patch add component POSTMASK
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  include/linux/soc/mediatek/mtk-mmsys.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h b/include/linux/soc/mediatek/mtk-mmsys.h
> index f6b58f9..7718cd6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
>         DDP_COMPONENT_OVL_2L1,
>         DDP_COMPONENT_OVL_2L2,
>         DDP_COMPONENT_OVL1,
> +       DDP_COMPONENT_POSTMASK0,
>         DDP_COMPONENT_PWM0,
>         DDP_COMPONENT_PWM1,
>         DDP_COMPONENT_PWM2,
> --
> 1.8.1.1.dirty
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From zev at bewilderbeest.net  Fri Apr 16 08:51:13 2021
From: zev at bewilderbeest.net (Zev Weiss)
Date: Fri, 16 Apr 2021 02:51:13 -0500
Subject: [PATCH] ARM: dts: aspeed: update e3c246d4i vuart properties
Message-ID: <20210416075113.18047-1-zev@bewilderbeest.net>

This device-tree was merged with a provisional vuart IRQ-polarity
property that was still under review and ended up taking a somewhat
different form.  This patch updates it to match the final form of the
new vuart properties, which additionally allow specifying the SIRQ
number and LPC address.

Signed-off-by: Zev Weiss <zev at bewilderbeest.net>
---

The relevant aspeed-vuart patches [0] have been merged into Greg KH's
tty-next tree, so I figure it's probably okay to proceed with the
corresponding dts adjustments now.

[0] https://lore.kernel.org/openbmc/20210412034712.16778-1-zev at bewilderbeest.net/

 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
index dcab6e78dfa4..8be40c8283af 100644
--- a/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
@@ -4,6 +4,7 @@
 #include "aspeed-g5.dtsi"
 #include <dt-bindings/gpio/aspeed-gpio.h>
 #include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/interrupt-controller/irq.h>
 
 /{
 	model = "ASRock E3C246D4I BMC";
@@ -73,7 +74,8 @@ &uart5 {
 
 &vuart {
 	status = "okay";
-	aspeed,sirq-active-high;
+	aspeed,lpc-io-reg = <0x2f8>;
+	aspeed,lpc-interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
 };
 
 &mac0 {
-- 
2.31.1



From zhe.he at windriver.com  Fri Apr 16 08:55:31 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 16 Apr 2021 15:55:31 +0800
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
Message-ID: <20210416075533.7720-1-zhe.he@windriver.com>

The general version of is_syscall_success does not handle 32-bit
compatible case, which would cause 32-bit negative return code to be
recoganized as a positive number later and seen as a "success".

Since is_compat_thread is defined in compat.h, implementing
is_syscall_success in ptrace.h would introduce build failure due to
recursive inclusion of some basic headers like mutex.h. We put the
implementation to ptrace.c

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 arch/arm64/include/asm/ptrace.h |  3 +++
 arch/arm64/kernel/ptrace.c      | 10 ++++++++++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e58bca832dff..3c415e9e5d85 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
 	regs->regs[0] = rc;
 }
 
+extern inline int is_syscall_success(struct pt_regs *regs);
+#define is_syscall_success(regs) is_syscall_success(regs)
+
 /**
  * regs_get_kernel_argument() - get Nth function argument in kernel
  * @regs:	pt_regs of that context
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 170f42fd6101..3266201f8c60 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
 	else
 		return valid_native_regs(regs);
 }
+
+inline int is_syscall_success(struct pt_regs *regs)
+{
+	unsigned long val = regs->regs[0];
+
+	if (is_compat_thread(task_thread_info(current)))
+		val = sign_extend64(val, 31);
+
+	return !IS_ERR_VALUE(val);
+}
-- 
2.17.1



From zhe.he at windriver.com  Fri Apr 16 08:55:32 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 16 Apr 2021 15:55:32 +0800
Subject: [PATCH 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210416075533.7720-1-zhe.he@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
Message-ID: <20210416075533.7720-2-zhe.he@windriver.com>

Add sign extension handling in syscall_get_return_value so that it can
handle 32-bit compatible case and can be used by for example audit, just
like what syscall_get_error does.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 arch/arm64/include/asm/syscall.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index cfc0672013f6..cd7a22787aeb 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct *task,
 static inline long syscall_get_return_value(struct task_struct *task,
 					    struct pt_regs *regs)
 {
-	return regs->regs[0];
+	long val = regs->regs[0];
+
+	if (is_compat_thread(task_thread_info(task)))
+		val = sign_extend64(val, 31);
+
+	return val;
 }
 
 static inline void syscall_set_return_value(struct task_struct *task,
-- 
2.17.1



From zhe.he at windriver.com  Fri Apr 16 08:55:33 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 16 Apr 2021 15:55:33 +0800
Subject: [PATCH 3/3] audit: Use syscall_get_return_value to get syscall return
 code in audit_syscall_exit
In-Reply-To: <20210416075533.7720-1-zhe.he@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
Message-ID: <20210416075533.7720-3-zhe.he@windriver.com>

regs_return_value for some architectures like arm64 simply retrieve
register value from pt_regs without sign extension in 32-bit compatible
case and cause audit to have false syscall return code. For example,
32-bit -13 would be treated as 4294967283 below.

type=SYSCALL msg=audit(1611110715.887:582): arch=40000028 syscall=322
success=yes exit=4294967283

We just added proper sign extension in syscall_get_return_value which
should be used instead.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 include/linux/audit.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 82b7c1116a85..135adbe22c19 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -334,7 +334,7 @@ static inline void audit_syscall_exit(void *pt_regs)
 {
 	if (unlikely(audit_context())) {
 		int success = is_syscall_success(pt_regs);
-		long return_code = regs_return_value(pt_regs);
+		long return_code = syscall_get_return_value(current, pt_regs);
 
 		__audit_syscall_exit(success, return_code);
 	}
-- 
2.17.1



From jbx6244 at gmail.com  Fri Apr 16 09:03:27 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:27 +0200
Subject: [PATCH v8 00/15] soc: rockchip: power-domain: add rk3568 powerdomains
Message-ID: <20210416080342.18614-1-jbx6244@gmail.com>

Fix power-controller node names for dtbs_check.
Convert power domain documentation to json-schema.
Add a meaningful power domain name.
Support power domain function for RK3568 Soc.

Changed in V8:
  Add #power-domain-cells to power domain nodes.
  Convert pmu.txt to YAML.
  Add more compatible strings to pmu.yaml
  Add pd-node ref schema.

Changed in V7:
[PATCH v7 07/11]:
  Fix TAB warning
  Fix alignment
[PATCH v7 09/11]:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
[PATCH v7 11/11]:
  Fix alignment

Changed in V6:
[PATCH v6 7/11]: Use kbasename(node->full_name).
[PATCH v6 9/11]: Update the commit message.

Changed in V5:
[PATCH v5 1/11]: New.
[PATCH v5 2/11]: New.
[PATCH v5 3/11]: New.
[PATCH v5 4/11]: New.
[PATCH v5 5/11]: New.
[PATCH v5 6/11]: New.
[PATCH v5 7/11]: New.
[PATCH v5 8/11]: No change. Same as [PATCH v4 1/4].
[PATCH v5 9/11]: [PATCH v4 2/4] Fix up yaml code styles.
[PATCH v5 10/11]: No change. Same as [PATCH v4 3/4].
[PATCH v5 11/11]: [PATCH v4 4/4] add a meaningful power domain name for
RK3568 Soc.

Changed in V4:
[PATCH v4 2/4]: Fix up yaml code styles. Remove the new compatible to [PATCH v4 3/4]
[PATCH v4 3/4]: Adding new compatible for RK3568 Soc.
[PATCH v4 4/4]: No change. Same as [PATCH v3 3/3].

Changed in V3:
[PATCH v3 2/3]: Fix up the code styles and add rk3568 base on:
https://patchwork.kernel.org/project/linux-rockchip/patch/20210225102643.653095-1-enric.balletbo at collabora.com/

Changed in V2:
[PATCH v2 2/3]: Fix up yaml code styles.

Elaine Zhang (10):
  ARM: dts: rockchip: Fix power-controller node names for rk3066a
  ARM: dts: rockchip: Fix power-controller node names for rk3188
  ARM: dts: rockchip: Fix power-controller node names for rk3288
  arm64: dts: rockchip: Fix power-controller node names for px30
  arm64: dts: rockchip: Fix power-controller node names for rk3328
  arm64: dts: rockchip: Fix power-controller node names for rk3399
  soc: rockchip: pm-domains: Add a meaningful power domain name
  dt-bindings: add power-domain header for RK3568 SoCs
  dt-bindings: power: rockchip: Add bindings for RK3568 Soc
  soc: rockchip: power-domain: add rk3568 powerdomains

Enric Balletbo i Serra (1):
  dt-bindings: power: rockchip: Convert to json-schema

Johan Jonker (4):
  ARM: dts: rockchip: add #power-domain-cells to power domain nodes
  arm64: dts: rockchip: add #power-domain-cells to power domain nodes
  dt-bindings: arm: rockchip: convert pmu.txt to YAML
  dt-bindings: arm: rockchip: add more compatible strings to pmu.yaml

 .../devicetree/bindings/arm/rockchip/pmu.txt       |  16 --
 .../devicetree/bindings/arm/rockchip/pmu.yaml      |  57 +++++
 .../bindings/power/rockchip,power-controller.yaml  | 259 +++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 -----------
 arch/arm/boot/dts/rk3066a.dtsi                     |   9 +-
 arch/arm/boot/dts/rk3188.dtsi                      |   9 +-
 arch/arm/boot/dts/rk3288.dtsi                      |  12 +-
 arch/arm64/boot/dts/rockchip/px30.dtsi             |  24 +-
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |   9 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  60 +++--
 drivers/soc/rockchip/pm_domains.c                  | 252 +++++++++++---------
 include/dt-bindings/power/rk3568-power.h           |  32 +++
 12 files changed, 575 insertions(+), 300 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
 create mode 100644 include/dt-bindings/power/rk3568-power.h

-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:28 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:28 +0200
Subject: [PATCH v8 01/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3066a
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-2-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed
---
 arch/arm/boot/dts/rk3066a.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..bbc3bff50 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -755,7 +755,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3066_PD_VIO {
+		power-domain at RK3066_PD_VIO {
 			reg = <RK3066_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -782,7 +782,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3066_PD_VIDEO {
+		power-domain at RK3066_PD_VIDEO {
 			reg = <RK3066_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -791,7 +791,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3066_PD_GPU {
+		power-domain at RK3066_PD_GPU {
 			reg = <RK3066_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:29 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:29 +0200
Subject: [PATCH v8 02/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3188
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-3-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3188.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 2298a8d84..5db32fdbe 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -699,7 +699,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3188_PD_VIO {
+		power-domain at RK3188_PD_VIO {
 			reg = <RK3188_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -721,7 +721,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3188_PD_VIDEO {
+		power-domain at RK3188_PD_VIDEO {
 			reg = <RK3188_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -730,7 +730,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3188_PD_GPU {
+		power-domain at RK3188_PD_GPU {
 			reg = <RK3188_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:31 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:31 +0200
Subject: [PATCH v8 04/15] ARM: dts: rockchip: add #power-domain-cells to power
 domain nodes
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-5-jbx6244@gmail.com>

Add #power-domain-cells to power domain nodes, because they
are required by power-domain.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 3 +++
 arch/arm/boot/dts/rk3188.dtsi  | 3 +++
 arch/arm/boot/dts/rk3288.dtsi  | 4 ++++
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index bbc3bff50..8e087c34b 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -780,6 +780,7 @@
 				 <&qos_cif1>,
 				 <&qos_ipp>,
 				 <&qos_rga>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3066_PD_VIDEO {
@@ -789,12 +790,14 @@
 				 <&cru HCLK_VDPU>,
 				 <&cru HCLK_VEPU>;
 			pm_qos = <&qos_vpu>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3066_PD_GPU {
 			reg = <RK3066_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
+			#power-domain-cells = <0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 5db32fdbe..f438170b4 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -719,6 +719,7 @@
 				 <&qos_cif0>,
 				 <&qos_ipp>,
 				 <&qos_rga>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3188_PD_VIDEO {
@@ -728,12 +729,14 @@
 				 <&cru HCLK_VDPU>,
 				 <&cru HCLK_VEPU>;
 			pm_qos = <&qos_vpu>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3188_PD_GPU {
 			reg = <RK3188_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
+			#power-domain-cells = <0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6f4d7929e..bf2d8ab61 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -805,6 +805,7 @@
 					 <&qos_vio2_rga_r>,
 					 <&qos_vio2_rga_w>,
 					 <&qos_vio1_isp_r>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -818,6 +819,7 @@
 					 <&cru SCLK_HEVC_CORE>;
 				pm_qos = <&qos_hevc_r>,
 					 <&qos_hevc_w>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -830,6 +832,7 @@
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -841,6 +844,7 @@
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu_r>,
 					 <&qos_gpu_w>;
+				#power-domain-cells = <0>;
 			};
 		};
 
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:32 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:32 +0200
Subject: [PATCH v8 05/15] arm64: dts: rockchip: Fix power-controller node
 names for px30
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-6-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a16..2b43c3d72 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -244,20 +244,20 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_usb at PX30_PD_USB {
+			power-domain at PX30_PD_USB {
 				reg = <PX30_PD_USB>;
 				clocks = <&cru HCLK_HOST>,
 					 <&cru HCLK_OTG>,
 					 <&cru SCLK_OTG_ADP>;
 				pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
 			};
-			pd_sdcard at PX30_PD_SDCARD {
+			power-domain at PX30_PD_SDCARD {
 				reg = <PX30_PD_SDCARD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sdmmc>;
 			};
-			pd_gmac at PX30_PD_GMAC {
+			power-domain at PX30_PD_GMAC {
 				reg = <PX30_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>,
@@ -265,7 +265,7 @@
 					 <&cru SCLK_GMAC_RX_TX>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_mmc_nand at PX30_PD_MMC_NAND {
+			power-domain at PX30_PD_MMC_NAND {
 				reg = <PX30_PD_MMC_NAND>;
 				clocks =  <&cru HCLK_NANDC>,
 					  <&cru HCLK_EMMC>,
@@ -278,14 +278,14 @@
 				pm_qos = <&qos_emmc>, <&qos_nand>,
 					 <&qos_sdio>, <&qos_sfc>;
 			};
-			pd_vpu at PX30_PD_VPU {
+			power-domain at PX30_PD_VPU {
 				reg = <PX30_PD_VPU>;
 				clocks = <&cru ACLK_VPU>,
 					 <&cru HCLK_VPU>,
 					 <&cru SCLK_CORE_VPU>;
 				pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
 			};
-			pd_vo at PX30_PD_VO {
+			power-domain at PX30_PD_VO {
 				reg = <PX30_PD_VO>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru ACLK_VOPB>,
@@ -301,7 +301,7 @@
 				pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
 					 <&qos_vop_m0>, <&qos_vop_m1>;
 			};
-			pd_vi at PX30_PD_VI {
+			power-domain at PX30_PD_VI {
 				reg = <PX30_PD_VI>;
 				clocks = <&cru ACLK_CIF>,
 					 <&cru ACLK_ISP>,
@@ -312,7 +312,7 @@
 					 <&qos_isp_wr>, <&qos_isp_m1>,
 					 <&qos_vip>;
 			};
-			pd_gpu at PX30_PD_GPU {
+			power-domain at PX30_PD_GPU {
 				reg = <PX30_PD_GPU>;
 				clocks = <&cru SCLK_GPU>;
 				pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:30 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:30 +0200
Subject: [PATCH v8 03/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3288
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-4-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ea7416c31..6f4d7929e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -769,7 +769,7 @@
 			 *	*_HDMI		HDMI
 			 *	*_MIPI_*	MIPI
 			 */
-			pd_vio at RK3288_PD_VIO {
+			power-domain at RK3288_PD_VIO {
 				reg = <RK3288_PD_VIO>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru ACLK_ISP>,
@@ -811,7 +811,7 @@
 			 * Note: The following 3 are HEVC(H.265) clocks,
 			 * and on the ACLK_HEVC_NIU (NOC).
 			 */
-			pd_hevc at RK3288_PD_HEVC {
+			power-domain at RK3288_PD_HEVC {
 				reg = <RK3288_PD_HEVC>;
 				clocks = <&cru ACLK_HEVC>,
 					 <&cru SCLK_HEVC_CABAC>,
@@ -825,7 +825,7 @@
 			 * (video endecoder & decoder) clocks that on the
 			 * ACLK_VCODEC_NIU and HCLK_VCODEC_NIU (NOC).
 			 */
-			pd_video at RK3288_PD_VIDEO {
+			power-domain at RK3288_PD_VIDEO {
 				reg = <RK3288_PD_VIDEO>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
@@ -836,7 +836,7 @@
 			 * Note: ACLK_GPU is the GPU clock,
 			 * and on the ACLK_GPU_NIU (NOC).
 			 */
-			pd_gpu at RK3288_PD_GPU {
+			power-domain at RK3288_PD_GPU {
 				reg = <RK3288_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu_r>,
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:33 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:33 +0200
Subject: [PATCH v8 06/15] arm64: dts: rockchip: Fix power-controller node
 names for rk3328
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-7-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 5bab61784..35df57535 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -300,13 +300,13 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 
-			pd_hevc at RK3328_PD_HEVC {
+			power-domain at RK3328_PD_HEVC {
 				reg = <RK3328_PD_HEVC>;
 			};
-			pd_video at RK3328_PD_VIDEO {
+			power-domain at RK3328_PD_VIDEO {
 				reg = <RK3328_PD_VIDEO>;
 			};
-			pd_vpu at RK3328_PD_VPU {
+			power-domain at RK3328_PD_VPU {
 				reg = <RK3328_PD_VPU>;
 				clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
 			};
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:34 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:34 +0200
Subject: [PATCH v8 07/15] arm64: dts: rockchip: Fix power-controller node
 names for rk3399
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-8-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 40 ++++++++++++++++----------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 0f2879cc1..19614c2ce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -968,26 +968,26 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_CENTER */
-			pd_iep at RK3399_PD_IEP {
+			power-domain at RK3399_PD_IEP {
 				reg = <RK3399_PD_IEP>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru HCLK_IEP>;
 				pm_qos = <&qos_iep>;
 			};
-			pd_rga at RK3399_PD_RGA {
+			power-domain at RK3399_PD_RGA {
 				reg = <RK3399_PD_RGA>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru HCLK_RGA>;
 				pm_qos = <&qos_rga_r>,
 					 <&qos_rga_w>;
 			};
-			pd_vcodec at RK3399_PD_VCODEC {
+			power-domain at RK3399_PD_VCODEC {
 				reg = <RK3399_PD_VCODEC>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video_m0>;
 			};
-			pd_vdu at RK3399_PD_VDU {
+			power-domain at RK3399_PD_VDU {
 				reg = <RK3399_PD_VDU>;
 				clocks = <&cru ACLK_VDU>,
 					 <&cru HCLK_VDU>;
@@ -996,94 +996,94 @@
 			};
 
 			/* These power domains are grouped by VD_GPU */
-			pd_gpu at RK3399_PD_GPU {
+			power-domain at RK3399_PD_GPU {
 				reg = <RK3399_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu>;
 			};
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_edp at RK3399_PD_EDP {
+			power-domain at RK3399_PD_EDP {
 				reg = <RK3399_PD_EDP>;
 				clocks = <&cru PCLK_EDP_CTRL>;
 			};
-			pd_emmc at RK3399_PD_EMMC {
+			power-domain at RK3399_PD_EMMC {
 				reg = <RK3399_PD_EMMC>;
 				clocks = <&cru ACLK_EMMC>;
 				pm_qos = <&qos_emmc>;
 			};
-			pd_gmac at RK3399_PD_GMAC {
+			power-domain at RK3399_PD_GMAC {
 				reg = <RK3399_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_sd at RK3399_PD_SD {
+			power-domain at RK3399_PD_SD {
 				reg = <RK3399_PD_SD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sd>;
 			};
-			pd_sdioaudio at RK3399_PD_SDIOAUDIO {
+			power-domain at RK3399_PD_SDIOAUDIO {
 				reg = <RK3399_PD_SDIOAUDIO>;
 				clocks = <&cru HCLK_SDIO>;
 				pm_qos = <&qos_sdioaudio>;
 			};
-			pd_tcpc0 at RK3399_PD_TCPD0 {
+			power-domain at RK3399_PD_TCPD0 {
 				reg = <RK3399_PD_TCPD0>;
 				clocks = <&cru SCLK_UPHY0_TCPDCORE>,
 					 <&cru SCLK_UPHY0_TCPDPHY_REF>;
 			};
-			pd_tcpc1 at RK3399_PD_TCPD1 {
+			power-domain at RK3399_PD_TCPD1 {
 				reg = <RK3399_PD_TCPD1>;
 				clocks = <&cru SCLK_UPHY1_TCPDCORE>,
 					 <&cru SCLK_UPHY1_TCPDPHY_REF>;
 			};
-			pd_usb3 at RK3399_PD_USB3 {
+			power-domain at RK3399_PD_USB3 {
 				reg = <RK3399_PD_USB3>;
 				clocks = <&cru ACLK_USB3>;
 				pm_qos = <&qos_usb_otg0>,
 					 <&qos_usb_otg1>;
 			};
-			pd_vio at RK3399_PD_VIO {
+			power-domain at RK3399_PD_VIO {
 				reg = <RK3399_PD_VIO>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				pd_hdcp at RK3399_PD_HDCP {
+				power-domain at RK3399_PD_HDCP {
 					reg = <RK3399_PD_HDCP>;
 					clocks = <&cru ACLK_HDCP>,
 						 <&cru HCLK_HDCP>,
 						 <&cru PCLK_HDCP>;
 					pm_qos = <&qos_hdcp>;
 				};
-				pd_isp0 at RK3399_PD_ISP0 {
+				power-domain at RK3399_PD_ISP0 {
 					reg = <RK3399_PD_ISP0>;
 					clocks = <&cru ACLK_ISP0>,
 						 <&cru HCLK_ISP0>;
 					pm_qos = <&qos_isp0_m0>,
 						 <&qos_isp0_m1>;
 				};
-				pd_isp1 at RK3399_PD_ISP1 {
+				power-domain at RK3399_PD_ISP1 {
 					reg = <RK3399_PD_ISP1>;
 					clocks = <&cru ACLK_ISP1>,
 						 <&cru HCLK_ISP1>;
 					pm_qos = <&qos_isp1_m0>,
 						 <&qos_isp1_m1>;
 				};
-				pd_vo at RK3399_PD_VO {
+				power-domain at RK3399_PD_VO {
 					reg = <RK3399_PD_VO>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 
-					pd_vopb at RK3399_PD_VOPB {
+					power-domain at RK3399_PD_VOPB {
 						reg = <RK3399_PD_VOPB>;
 						clocks = <&cru ACLK_VOP0>,
 							 <&cru HCLK_VOP0>;
 						pm_qos = <&qos_vop_big_r>,
 							 <&qos_vop_big_w>;
 					};
-					pd_vopl at RK3399_PD_VOPL {
+					power-domain at RK3399_PD_VOPL {
 						reg = <RK3399_PD_VOPL>;
 						clocks = <&cru ACLK_VOP1>,
 							 <&cru HCLK_VOP1>;
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:35 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:35 +0200
Subject: [PATCH v8 08/15] arm64: dts: rockchip: add #power-domain-cells to
 power domain nodes
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-9-jbx6244@gmail.com>

Add #power-domain-cells to power domain nodes, because they
are required by power-domain.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi   |  8 ++++++++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  3 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 ++++++++++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2b43c3d72..c96ebfe3e 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -250,12 +250,14 @@
 					 <&cru HCLK_OTG>,
 					 <&cru SCLK_OTG_ADP>;
 				pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_SDCARD {
 				reg = <PX30_PD_SDCARD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sdmmc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_GMAC {
 				reg = <PX30_PD_GMAC>;
@@ -264,6 +266,7 @@
 					 <&cru SCLK_MAC_REF>,
 					 <&cru SCLK_GMAC_RX_TX>;
 				pm_qos = <&qos_gmac>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_MMC_NAND {
 				reg = <PX30_PD_MMC_NAND>;
@@ -277,6 +280,7 @@
 					  <&cru SCLK_SFC>;
 				pm_qos = <&qos_emmc>, <&qos_nand>,
 					 <&qos_sdio>, <&qos_sfc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VPU {
 				reg = <PX30_PD_VPU>;
@@ -284,6 +288,7 @@
 					 <&cru HCLK_VPU>,
 					 <&cru SCLK_CORE_VPU>;
 				pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VO {
 				reg = <PX30_PD_VO>;
@@ -300,6 +305,7 @@
 					 <&cru SCLK_VOPB_PWM>;
 				pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
 					 <&qos_vop_m0>, <&qos_vop_m1>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VI {
 				reg = <PX30_PD_VI>;
@@ -311,11 +317,13 @@
 				pm_qos = <&qos_isp_128>, <&qos_isp_rd>,
 					 <&qos_isp_wr>, <&qos_isp_m1>,
 					 <&qos_vip>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_GPU {
 				reg = <PX30_PD_GPU>;
 				clocks = <&cru SCLK_GPU>;
 				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
 			};
 		};
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 35df57535..470da614e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -302,13 +302,16 @@
 
 			power-domain at RK3328_PD_HEVC {
 				reg = <RK3328_PD_HEVC>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3328_PD_VIDEO {
 				reg = <RK3328_PD_VIDEO>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3328_PD_VPU {
 				reg = <RK3328_PD_VPU>;
 				clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+				#power-domain-cells = <0>;
 			};
 		};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 19614c2ce..99f85b1d9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -973,6 +973,7 @@
 				clocks = <&cru ACLK_IEP>,
 					 <&cru HCLK_IEP>;
 				pm_qos = <&qos_iep>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_RGA {
 				reg = <RK3399_PD_RGA>;
@@ -980,12 +981,14 @@
 					 <&cru HCLK_RGA>;
 				pm_qos = <&qos_rga_r>,
 					 <&qos_rga_w>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VCODEC {
 				reg = <RK3399_PD_VCODEC>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video_m0>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VDU {
 				reg = <RK3399_PD_VDU>;
@@ -993,6 +996,7 @@
 					 <&cru HCLK_VDU>;
 				pm_qos = <&qos_video_m1_r>,
 					 <&qos_video_m1_w>;
+				#power-domain-cells = <0>;
 			};
 
 			/* These power domains are grouped by VD_GPU */
@@ -1000,53 +1004,63 @@
 				reg = <RK3399_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
 			};
 
 			/* These power domains are grouped by VD_LOGIC */
 			power-domain at RK3399_PD_EDP {
 				reg = <RK3399_PD_EDP>;
 				clocks = <&cru PCLK_EDP_CTRL>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_EMMC {
 				reg = <RK3399_PD_EMMC>;
 				clocks = <&cru ACLK_EMMC>;
 				pm_qos = <&qos_emmc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_GMAC {
 				reg = <RK3399_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>;
 				pm_qos = <&qos_gmac>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_SD {
 				reg = <RK3399_PD_SD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sd>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_SDIOAUDIO {
 				reg = <RK3399_PD_SDIOAUDIO>;
 				clocks = <&cru HCLK_SDIO>;
 				pm_qos = <&qos_sdioaudio>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_TCPD0 {
 				reg = <RK3399_PD_TCPD0>;
 				clocks = <&cru SCLK_UPHY0_TCPDCORE>,
 					 <&cru SCLK_UPHY0_TCPDPHY_REF>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_TCPD1 {
 				reg = <RK3399_PD_TCPD1>;
 				clocks = <&cru SCLK_UPHY1_TCPDCORE>,
 					 <&cru SCLK_UPHY1_TCPDPHY_REF>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_USB3 {
 				reg = <RK3399_PD_USB3>;
 				clocks = <&cru ACLK_USB3>;
 				pm_qos = <&qos_usb_otg0>,
 					 <&qos_usb_otg1>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VIO {
 				reg = <RK3399_PD_VIO>;
+				#power-domain-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 
@@ -1056,6 +1070,7 @@
 						 <&cru HCLK_HDCP>,
 						 <&cru PCLK_HDCP>;
 					pm_qos = <&qos_hdcp>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_ISP0 {
 					reg = <RK3399_PD_ISP0>;
@@ -1063,6 +1078,7 @@
 						 <&cru HCLK_ISP0>;
 					pm_qos = <&qos_isp0_m0>,
 						 <&qos_isp0_m1>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_ISP1 {
 					reg = <RK3399_PD_ISP1>;
@@ -1070,9 +1086,11 @@
 						 <&cru HCLK_ISP1>;
 					pm_qos = <&qos_isp1_m0>,
 						 <&qos_isp1_m1>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_VO {
 					reg = <RK3399_PD_VO>;
+					#power-domain-cells = <1>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 
@@ -1082,12 +1100,14 @@
 							 <&cru HCLK_VOP0>;
 						pm_qos = <&qos_vop_big_r>,
 							 <&qos_vop_big_w>;
+						#power-domain-cells = <0>;
 					};
 					power-domain at RK3399_PD_VOPL {
 						reg = <RK3399_PD_VOPL>;
 						clocks = <&cru ACLK_VOP1>,
 							 <&cru HCLK_VOP1>;
 						pm_qos = <&qos_vop_little>;
+						#power-domain-cells = <0>;
 					};
 				};
 			};
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:36 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:36 +0200
Subject: [PATCH v8 09/15] soc: rockchip: pm-domains: Add a meaningful power
 domain name
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-10-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the power domains names to the power domain info struct so we
have meaningful name for every power domain.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix TAB warning
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 221 ++++++++++++++++++++------------------
 1 file changed, 114 insertions(+), 107 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 54eb6cfc5..1d1b06672 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -29,6 +29,7 @@
 #include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
+	const char *name;
 	int pwr_mask;
 	int status_mask;
 	int req_mask;
@@ -85,8 +86,9 @@ struct rockchip_pmu {
 
 #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
 
-#define DOMAIN(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
 	.req_mask = (req),				\
@@ -95,8 +97,9 @@ struct rockchip_pmu {
 	.active_wakeup = (wakeup),			\
 }
 
-#define DOMAIN_M(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN_M(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_w_mask = (pwr) << 16,			\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
@@ -107,8 +110,9 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_RK3036(req, ack, idle, wakeup)		\
+#define DOMAIN_RK3036(_name, req, ack, idle, wakeup)		\
 {							\
+	.name = _name,				\
 	.req_mask = (req),				\
 	.req_w_mask = (req) << 16,			\
 	.ack_mask = (ack),				\
@@ -116,20 +120,20 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_PX30(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_PX30(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3288(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, (req) << 16, wakeup)
+#define DOMAIN_RK3288(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, (req) << 16, wakeup)
 
-#define DOMAIN_RK3328(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, pwr, req, (req) << 10, req, wakeup)
+#define DOMAIN_RK3328(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, (req) << 10, req, wakeup)
 
-#define DOMAIN_RK3368(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_RK3368(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3399(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, req, wakeup)
+#define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
@@ -490,7 +494,10 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
 		goto err_unprepare_clocks;
 	}
 
-	pd->genpd.name = node->name;
+	if (pd->info->name)
+		pd->genpd.name = pd->info->name;
+	else
+		pd->genpd.name = kbasename(node->full_name);
 	pd->genpd.power_off = rockchip_pd_power_off;
 	pd->genpd.power_on = rockchip_pd_power_on;
 	pd->genpd.attach_dev = rockchip_pd_attach_dev;
@@ -716,129 +723,129 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 }
 
 static const struct rockchip_domain_info px30_pm_domains[] = {
-	[PX30_PD_USB]		= DOMAIN_PX30(BIT(5),  BIT(5),  BIT(10), false),
-	[PX30_PD_SDCARD]	= DOMAIN_PX30(BIT(8),  BIT(8),  BIT(9),  false),
-	[PX30_PD_GMAC]		= DOMAIN_PX30(BIT(10), BIT(10), BIT(6),  false),
-	[PX30_PD_MMC_NAND]	= DOMAIN_PX30(BIT(11), BIT(11), BIT(5),  false),
-	[PX30_PD_VPU]		= DOMAIN_PX30(BIT(12), BIT(12), BIT(14), false),
-	[PX30_PD_VO]		= DOMAIN_PX30(BIT(13), BIT(13), BIT(7),  false),
-	[PX30_PD_VI]		= DOMAIN_PX30(BIT(14), BIT(14), BIT(8),  false),
-	[PX30_PD_GPU]		= DOMAIN_PX30(BIT(15), BIT(15), BIT(2),  false),
+	[PX30_PD_USB]		= DOMAIN_PX30("usb",      BIT(5),  BIT(5),  BIT(10), false),
+	[PX30_PD_SDCARD]	= DOMAIN_PX30("sdcard",   BIT(8),  BIT(8),  BIT(9),  false),
+	[PX30_PD_GMAC]		= DOMAIN_PX30("gmac",     BIT(10), BIT(10), BIT(6),  false),
+	[PX30_PD_MMC_NAND]	= DOMAIN_PX30("mmc_nand", BIT(11), BIT(11), BIT(5),  false),
+	[PX30_PD_VPU]		= DOMAIN_PX30("vpu",      BIT(12), BIT(12), BIT(14), false),
+	[PX30_PD_VO]		= DOMAIN_PX30("vo",       BIT(13), BIT(13), BIT(7),  false),
+	[PX30_PD_VI]		= DOMAIN_PX30("vi",       BIT(14), BIT(14), BIT(8),  false),
+	[PX30_PD_GPU]		= DOMAIN_PX30("gpu",      BIT(15), BIT(15), BIT(2),  false),
 };
 
 static const struct rockchip_domain_info rk3036_pm_domains[] = {
-	[RK3036_PD_MSCH]	= DOMAIN_RK3036(BIT(14), BIT(23), BIT(30), true),
-	[RK3036_PD_CORE]	= DOMAIN_RK3036(BIT(13), BIT(17), BIT(24), false),
-	[RK3036_PD_PERI]	= DOMAIN_RK3036(BIT(12), BIT(18), BIT(25), false),
-	[RK3036_PD_VIO]		= DOMAIN_RK3036(BIT(11), BIT(19), BIT(26), false),
-	[RK3036_PD_VPU]		= DOMAIN_RK3036(BIT(10), BIT(20), BIT(27), false),
-	[RK3036_PD_GPU]		= DOMAIN_RK3036(BIT(9),  BIT(21), BIT(28), false),
-	[RK3036_PD_SYS]		= DOMAIN_RK3036(BIT(8),  BIT(22), BIT(29), false),
+	[RK3036_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(14), BIT(23), BIT(30), true),
+	[RK3036_PD_CORE]	= DOMAIN_RK3036("core", BIT(13), BIT(17), BIT(24), false),
+	[RK3036_PD_PERI]	= DOMAIN_RK3036("peri", BIT(12), BIT(18), BIT(25), false),
+	[RK3036_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(11), BIT(19), BIT(26), false),
+	[RK3036_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(10), BIT(20), BIT(27), false),
+	[RK3036_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(9),  BIT(21), BIT(28), false),
+	[RK3036_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(8),  BIT(22), BIT(29), false),
 };
 
 static const struct rockchip_domain_info rk3066_pm_domains[] = {
-	[RK3066_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3066_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3066_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3066_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3066_PD_CPU]		= DOMAIN(0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3066_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3066_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3066_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3066_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3066_PD_CPU]		= DOMAIN("cpu",   0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3128_pm_domains[] = {
-	[RK3128_PD_CORE]	= DOMAIN_RK3288(BIT(0), BIT(0), BIT(4), false),
-	[RK3128_PD_MSCH]	= DOMAIN_RK3288(0,      0,      BIT(6), true),
-	[RK3128_PD_VIO]		= DOMAIN_RK3288(BIT(3), BIT(3), BIT(2), false),
-	[RK3128_PD_VIDEO]	= DOMAIN_RK3288(BIT(2), BIT(2), BIT(1), false),
-	[RK3128_PD_GPU]		= DOMAIN_RK3288(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),
 };
 
 static const struct rockchip_domain_info rk3188_pm_domains[] = {
-	[RK3188_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3188_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3188_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3188_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3188_PD_CPU]		= DOMAIN(BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3188_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3188_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3188_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3188_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3188_PD_CPU]		= DOMAIN("cpu",   BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3228_pm_domains[] = {
-	[RK3228_PD_CORE]	= DOMAIN_RK3036(BIT(0),  BIT(0),  BIT(16), true),
-	[RK3228_PD_MSCH]	= DOMAIN_RK3036(BIT(1),  BIT(1),  BIT(17), true),
-	[RK3228_PD_BUS]		= DOMAIN_RK3036(BIT(2),  BIT(2),  BIT(18), true),
-	[RK3228_PD_SYS]		= DOMAIN_RK3036(BIT(3),  BIT(3),  BIT(19), true),
-	[RK3228_PD_VIO]		= DOMAIN_RK3036(BIT(4),  BIT(4),  BIT(20), false),
-	[RK3228_PD_VOP]		= DOMAIN_RK3036(BIT(5),  BIT(5),  BIT(21), false),
-	[RK3228_PD_VPU]		= DOMAIN_RK3036(BIT(6),  BIT(6),  BIT(22), false),
-	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036(BIT(7),  BIT(7),  BIT(23), false),
-	[RK3228_PD_GPU]		= DOMAIN_RK3036(BIT(8),  BIT(8),  BIT(24), false),
-	[RK3228_PD_PERI]	= DOMAIN_RK3036(BIT(9),  BIT(9),  BIT(25), true),
-	[RK3228_PD_GMAC]	= DOMAIN_RK3036(BIT(10), BIT(10), BIT(26), false),
+	[RK3228_PD_CORE]	= DOMAIN_RK3036("core", BIT(0),  BIT(0),  BIT(16), true),
+	[RK3228_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(1),  BIT(1),  BIT(17), true),
+	[RK3228_PD_BUS]		= DOMAIN_RK3036("bus",  BIT(2),  BIT(2),  BIT(18), true),
+	[RK3228_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(3),  BIT(3),  BIT(19), true),
+	[RK3228_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(4),  BIT(4),  BIT(20), false),
+	[RK3228_PD_VOP]		= DOMAIN_RK3036("vop",  BIT(5),  BIT(5),  BIT(21), false),
+	[RK3228_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(6),  BIT(6),  BIT(22), false),
+	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036("vdec", BIT(7),  BIT(7),  BIT(23), false),
+	[RK3228_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(8),  BIT(8),  BIT(24), false),
+	[RK3228_PD_PERI]	= DOMAIN_RK3036("peri", BIT(9),  BIT(9),  BIT(25), true),
+	[RK3228_PD_GMAC]	= DOMAIN_RK3036("gmac", BIT(10), BIT(10), BIT(26), false),
 };
 
 static const struct rockchip_domain_info rk3288_pm_domains[] = {
-	[RK3288_PD_VIO]		= DOMAIN_RK3288(BIT(7),  BIT(7),  BIT(4), false),
-	[RK3288_PD_HEVC]	= DOMAIN_RK3288(BIT(14), BIT(10), BIT(9), false),
-	[RK3288_PD_VIDEO]	= DOMAIN_RK3288(BIT(8),  BIT(8),  BIT(3), false),
-	[RK3288_PD_GPU]		= DOMAIN_RK3288(BIT(9),  BIT(9),  BIT(2), false),
+	[RK3288_PD_VIO]		= DOMAIN_RK3288("vio",   BIT(7),  BIT(7),  BIT(4), false),
+	[RK3288_PD_HEVC]	= DOMAIN_RK3288("hevc",  BIT(14), BIT(10), BIT(9), false),
+	[RK3288_PD_VIDEO]	= DOMAIN_RK3288("video", BIT(8),  BIT(8),  BIT(3), false),
+	[RK3288_PD_GPU]		= DOMAIN_RK3288("gpu",   BIT(9),  BIT(9),  BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3328_pm_domains[] = {
-	[RK3328_PD_CORE]	= DOMAIN_RK3328(0, BIT(0), BIT(0), false),
-	[RK3328_PD_GPU]		= DOMAIN_RK3328(0, BIT(1), BIT(1), false),
-	[RK3328_PD_BUS]		= DOMAIN_RK3328(0, BIT(2), BIT(2), true),
-	[RK3328_PD_MSCH]	= DOMAIN_RK3328(0, BIT(3), BIT(3), true),
-	[RK3328_PD_PERI]	= DOMAIN_RK3328(0, BIT(4), BIT(4), true),
-	[RK3328_PD_VIDEO]	= DOMAIN_RK3328(0, BIT(5), BIT(5), false),
-	[RK3328_PD_HEVC]	= DOMAIN_RK3328(0, BIT(6), BIT(6), false),
-	[RK3328_PD_VIO]		= DOMAIN_RK3328(0, BIT(8), BIT(8), false),
-	[RK3328_PD_VPU]		= DOMAIN_RK3328(0, BIT(9), BIT(9), false),
+	[RK3328_PD_CORE]	= DOMAIN_RK3328("core",  0, BIT(0), BIT(0), false),
+	[RK3328_PD_GPU]		= DOMAIN_RK3328("gpu",   0, BIT(1), BIT(1), false),
+	[RK3328_PD_BUS]		= DOMAIN_RK3328("bus",   0, BIT(2), BIT(2), true),
+	[RK3328_PD_MSCH]	= DOMAIN_RK3328("msch",  0, BIT(3), BIT(3), true),
+	[RK3328_PD_PERI]	= DOMAIN_RK3328("peri",  0, BIT(4), BIT(4), true),
+	[RK3328_PD_VIDEO]	= DOMAIN_RK3328("video", 0, BIT(5), BIT(5), false),
+	[RK3328_PD_HEVC]	= DOMAIN_RK3328("hevc",  0, BIT(6), BIT(6), false),
+	[RK3328_PD_VIO]		= DOMAIN_RK3328("vio",   0, BIT(8), BIT(8), false),
+	[RK3328_PD_VPU]		= DOMAIN_RK3328("vpu",   0, BIT(9), BIT(9), false),
 };
 
 static const struct rockchip_domain_info rk3366_pm_domains[] = {
-	[RK3366_PD_PERI]	= DOMAIN_RK3368(BIT(10), BIT(10), BIT(6), true),
-	[RK3366_PD_VIO]		= DOMAIN_RK3368(BIT(14), BIT(14), BIT(8), false),
-	[RK3366_PD_VIDEO]	= DOMAIN_RK3368(BIT(13), BIT(13), BIT(7), false),
-	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368(BIT(11), BIT(11), BIT(7), false),
-	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368(BIT(8),  BIT(8),  BIT(9), false),
-	[RK3366_PD_VPU]		= DOMAIN_RK3368(BIT(12), BIT(12), BIT(7), false),
-	[RK3366_PD_GPU]		= DOMAIN_RK3368(BIT(15), BIT(15), BIT(2), false),
+	[RK3366_PD_PERI]	= DOMAIN_RK3368("peri",   BIT(10), BIT(10), BIT(6), true),
+	[RK3366_PD_VIO]		= DOMAIN_RK3368("vio",    BIT(14), BIT(14), BIT(8), false),
+	[RK3366_PD_VIDEO]	= DOMAIN_RK3368("video",  BIT(13), BIT(13), BIT(7), false),
+	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368("vdec",   BIT(11), BIT(11), BIT(7), false),
+	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368("wifibt", BIT(8),  BIT(8),  BIT(9), false),
+	[RK3366_PD_VPU]		= DOMAIN_RK3368("vpu",    BIT(12), BIT(12), BIT(7), false),
+	[RK3366_PD_GPU]		= DOMAIN_RK3368("gpu",    BIT(15), BIT(15), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3368_pm_domains[] = {
-	[RK3368_PD_PERI]	= DOMAIN_RK3368(BIT(13), BIT(12), BIT(6), true),
-	[RK3368_PD_VIO]		= DOMAIN_RK3368(BIT(15), BIT(14), BIT(8), false),
-	[RK3368_PD_VIDEO]	= DOMAIN_RK3368(BIT(14), BIT(13), BIT(7), false),
-	[RK3368_PD_GPU_0]	= DOMAIN_RK3368(BIT(16), BIT(15), BIT(2), false),
-	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(BIT(17), BIT(16), BIT(2), false),
+	[RK3368_PD_PERI]	= DOMAIN_RK3368("peri",  BIT(13), BIT(12), BIT(6), true),
+	[RK3368_PD_VIO]		= DOMAIN_RK3368("vio",   BIT(15), BIT(14), BIT(8), false),
+	[RK3368_PD_VIDEO]	= DOMAIN_RK3368("video", BIT(14), BIT(13), BIT(7), false),
+	[RK3368_PD_GPU_0]	= DOMAIN_RK3368("gpu_0", BIT(16), BIT(15), BIT(2), false),
+	[RK3368_PD_GPU_1]	= DOMAIN_RK3368("gpu_1", BIT(17), BIT(16), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3399_pm_domains[] = {
-	[RK3399_PD_TCPD0]	= DOMAIN_RK3399(BIT(8),  BIT(8),  0,	   false),
-	[RK3399_PD_TCPD1]	= DOMAIN_RK3399(BIT(9),  BIT(9),  0,	   false),
-	[RK3399_PD_CCI]		= DOMAIN_RK3399(BIT(10), BIT(10), 0,	   true),
-	[RK3399_PD_CCI0]	= DOMAIN_RK3399(0,	 0,	  BIT(15), true),
-	[RK3399_PD_CCI1]	= DOMAIN_RK3399(0,	 0,	  BIT(16), true),
-	[RK3399_PD_PERILP]	= DOMAIN_RK3399(BIT(11), BIT(11), BIT(1),  true),
-	[RK3399_PD_PERIHP]	= DOMAIN_RK3399(BIT(12), BIT(12), BIT(2),  true),
-	[RK3399_PD_CENTER]	= DOMAIN_RK3399(BIT(13), BIT(13), BIT(14), true),
-	[RK3399_PD_VIO]		= DOMAIN_RK3399(BIT(14), BIT(14), BIT(17), false),
-	[RK3399_PD_GPU]		= DOMAIN_RK3399(BIT(15), BIT(15), BIT(0),  false),
-	[RK3399_PD_VCODEC]	= DOMAIN_RK3399(BIT(16), BIT(16), BIT(3),  false),
-	[RK3399_PD_VDU]		= DOMAIN_RK3399(BIT(17), BIT(17), BIT(4),  false),
-	[RK3399_PD_RGA]		= DOMAIN_RK3399(BIT(18), BIT(18), BIT(5),  false),
-	[RK3399_PD_IEP]		= DOMAIN_RK3399(BIT(19), BIT(19), BIT(6),  false),
-	[RK3399_PD_VO]		= DOMAIN_RK3399(BIT(20), BIT(20), 0,	   false),
-	[RK3399_PD_VOPB]	= DOMAIN_RK3399(0,	 0,	  BIT(7),  false),
-	[RK3399_PD_VOPL]	= DOMAIN_RK3399(0, 	 0,	  BIT(8),  false),
-	[RK3399_PD_ISP0]	= DOMAIN_RK3399(BIT(22), BIT(22), BIT(9),  false),
-	[RK3399_PD_ISP1]	= DOMAIN_RK3399(BIT(23), BIT(23), BIT(10), false),
-	[RK3399_PD_HDCP]	= DOMAIN_RK3399(BIT(24), BIT(24), BIT(11), false),
-	[RK3399_PD_GMAC]	= DOMAIN_RK3399(BIT(25), BIT(25), BIT(23), true),
-	[RK3399_PD_EMMC]	= DOMAIN_RK3399(BIT(26), BIT(26), BIT(24), true),
-	[RK3399_PD_USB3]	= DOMAIN_RK3399(BIT(27), BIT(27), BIT(12), true),
-	[RK3399_PD_EDP]		= DOMAIN_RK3399(BIT(28), BIT(28), BIT(22), false),
-	[RK3399_PD_GIC]		= DOMAIN_RK3399(BIT(29), BIT(29), BIT(27), true),
-	[RK3399_PD_SD]		= DOMAIN_RK3399(BIT(30), BIT(30), BIT(28), true),
-	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399(BIT(31), BIT(31), BIT(29), true),
+	[RK3399_PD_TCPD0]	= DOMAIN_RK3399("tcpd0",     BIT(8),  BIT(8),  0,       false),
+	[RK3399_PD_TCPD1]	= DOMAIN_RK3399("tcpd1",     BIT(9),  BIT(9),  0,       false),
+	[RK3399_PD_CCI]		= DOMAIN_RK3399("cci",       BIT(10), BIT(10), 0,       true),
+	[RK3399_PD_CCI0]	= DOMAIN_RK3399("cci0",      0,       0,       BIT(15), true),
+	[RK3399_PD_CCI1]	= DOMAIN_RK3399("cci1",      0,       0,       BIT(16), true),
+	[RK3399_PD_PERILP]	= DOMAIN_RK3399("perilp",    BIT(11), BIT(11), BIT(1),  true),
+	[RK3399_PD_PERIHP]	= DOMAIN_RK3399("perihp",    BIT(12), BIT(12), BIT(2),  true),
+	[RK3399_PD_CENTER]	= DOMAIN_RK3399("center",    BIT(13), BIT(13), BIT(14), true),
+	[RK3399_PD_VIO]		= DOMAIN_RK3399("vio",       BIT(14), BIT(14), BIT(17), false),
+	[RK3399_PD_GPU]		= DOMAIN_RK3399("gpu",       BIT(15), BIT(15), BIT(0),  false),
+	[RK3399_PD_VCODEC]	= DOMAIN_RK3399("vcodec",    BIT(16), BIT(16), BIT(3),  false),
+	[RK3399_PD_VDU]		= DOMAIN_RK3399("vdu",       BIT(17), BIT(17), BIT(4),  false),
+	[RK3399_PD_RGA]		= DOMAIN_RK3399("rga",       BIT(18), BIT(18), BIT(5),  false),
+	[RK3399_PD_IEP]		= DOMAIN_RK3399("iep",       BIT(19), BIT(19), BIT(6),  false),
+	[RK3399_PD_VO]		= DOMAIN_RK3399("vo",        BIT(20), BIT(20), 0,       false),
+	[RK3399_PD_VOPB]	= DOMAIN_RK3399("vopb",      0,       0,       BIT(7),  false),
+	[RK3399_PD_VOPL]	= DOMAIN_RK3399("vopl",      0,       0,       BIT(8),  false),
+	[RK3399_PD_ISP0]	= DOMAIN_RK3399("isp0",      BIT(22), BIT(22), BIT(9),  false),
+	[RK3399_PD_ISP1]	= DOMAIN_RK3399("isp1",      BIT(23), BIT(23), BIT(10), false),
+	[RK3399_PD_HDCP]	= DOMAIN_RK3399("hdcp",      BIT(24), BIT(24), BIT(11), false),
+	[RK3399_PD_GMAC]	= DOMAIN_RK3399("gmac",      BIT(25), BIT(25), BIT(23), true),
+	[RK3399_PD_EMMC]	= DOMAIN_RK3399("emmc",      BIT(26), BIT(26), BIT(24), true),
+	[RK3399_PD_USB3]	= DOMAIN_RK3399("usb3",      BIT(27), BIT(27), BIT(12), true),
+	[RK3399_PD_EDP]		= DOMAIN_RK3399("edp",       BIT(28), BIT(28), BIT(22), false),
+	[RK3399_PD_GIC]		= DOMAIN_RK3399("gic",       BIT(29), BIT(29), BIT(27), true),
+	[RK3399_PD_SD]		= DOMAIN_RK3399("sd",        BIT(30), BIT(30), BIT(28), true),
+	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
 static const struct rockchip_pmu_info px30_pmu = {
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:38 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:38 +0200
Subject: [PATCH v8 11/15] dt-bindings: arm: rockchip: convert pmu.txt to YAML
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-12-jbx6244@gmail.com>

Current dts files with 'pmu' nodes are manually verified.
In order to automate this process pmu.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 .../devicetree/bindings/arm/rockchip/pmu.txt       | 16 -------
 .../devicetree/bindings/arm/rockchip/pmu.yaml      | 49 ++++++++++++++++++++++
 2 files changed, 49 insertions(+), 16 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
deleted file mode 100644
index 3ee9b428b..000000000
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Rockchip power-management-unit:
--------------------------------
-
-The pmu is used to turn off and on different power domains of the SoCs
-This includes the power to the CPU cores.
-
-Required node properties:
-- compatible value : = "rockchip,rk3066-pmu";
-- reg : physical base address and the size of the registers window
-
-Example:
-
-	pmu at 20004000 {
-		compatible = "rockchip,rk3066-pmu";
-		reg = <0x20004000 0x100>;
-	};
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
new file mode 100644
index 000000000..0b816943d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/rockchip/pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Management Unit (PMU)
+
+maintainers:
+  - Elaine Zhang <zhangqing at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |
+  The PMU is used to turn on and off different power domains of the SoCs.
+  This includes the power to the CPU cores.
+
+select:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - rockchip,rk3066-pmu
+
+  required:
+    - compatible
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - rockchip,rk3066-pmu
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: true
+
+examples:
+  - |
+    pmu at 20004000 {
+      compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
+      reg = <0x20004000 0x100>;
+    };
-- 
2.11.0



From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr 16 09:07:21 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri, 16 Apr 2021 17:07:21 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
 <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
Message-ID: <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>

Hi,

Thanks for your review.

On Mon, Apr 12, 2021 at 09:02:32AM +0200, Uwe Kleine-K?nig wrote:
> On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> > Hi Uwe,
> > 
> > Thanks for your review.
> > 
> > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K?nig wrote:
> > > Hello,
> > > 
> > > just a few small details left to criticize ...
> > > 
> > > On Sat, Apr 10, 2021 at 08:08:37AM +0900, Nobuhiro Iwamatsu wrote:
> > > > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > > > new file mode 100644
> > > > index 000000000000..99d83f94ed86
> > > > --- /dev/null
> > > > +++ b/drivers/pwm/pwm-visconti.c
> > > > @@ -0,0 +1,188 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * Toshiba Visconti pulse-width-modulation controller driver
> > > > + *
> > > > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > > > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> > > > + *
> > > > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > > > + *
> > > > + */
> > > > +
> > > > +#include <linux/err.h>
> > > > +#include <linux/io.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of_device.h>
> > > > +#include <linux/platform_device.h>
> > > > +#include <linux/pwm.h>
> > > > +
> > > > +#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
> > > > +#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
> > > > +#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
> > > > +
> > > > +#define PIPGM_PWMC_PWMACT		BIT(5)
> > > > +#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
> > > > +#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 *to_visconti_chip(struct pwm_chip *chip)
> > > > +{
> > > > +	return container_of(chip, struct visconti_pwm_chip, chip);
> > > > +}
> > > > +
> > > > +static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> > > > +			      const struct pwm_state *state)
> > > > +{
> > > > +	struct visconti_pwm_chip *priv = to_visconti_chip(chip);
> > > > +	u32 period, duty_cycle, pwmc0;
> > > > +
> > > > +	/*
> > > > +	 * pwmc is a 2-bit divider for the input clock running at 1 MHz.
> > > > +	 * When the settings of the PWM are modified, the new values are shadowed in hardware until
> > > > +	 * the period register (PCSR) is written and the currently running period is completed. This
> > > > +	 * way the hardware switches atomically from the old setting to the new.
> > > > +	 * Also, disabling the hardware completes the currently running period and keeps the output
> > > > +	 * at low level at all times.
> > > 
> > > Can you please put a paragraph analogous to the one in pwm-sifive in the
> > > same format. This simplified keeping an overview about the oddities of
> > > the various supported chips.
> > 
> > OK, I will check pwm-sifive's, and add.

I will add the following :

 * Limitations:
 * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8) for the input
 *   clock running at 1 MHz.
 * - When the settings of the PWM are modified, the new values are shadowed
 *   in hardware until the PIPGM_PCSR register is written and the currently
 *   running period is completed. This way the hardware switches atomically
 *   from the old setting to the new.
 * - Disabling the hardware completes the currently running period and keeps
 *   the output at low level at all times.


> > 
> > > 
> > > > +	 */
> > > > +	if (!state->enabled) {
> > > > +		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > > > +		return 0;
> > > > +	}
> > > > +
> > > > [...]
> > > > +
> > > > +static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> > > > +				   struct pwm_state *state)
> > > > +{
> > > > +	struct visconti_pwm_chip *priv = chip_to_priv(chip);
> > > > +	u32 period, duty, pwmc0, pwmc0_clk;
> > > > +
> > > > +	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
> > > > +	if (period)
> > > > +		state->enabled = true;
> > > > +	else
> > > > +		state->enabled = false;
> > > 
> > > If PIPGM_PCSR is 0 the hardware is still active and setting a new
> > > configuration completes the currently running period, right? Then I
> > > think having always state->enabled = true is a better match.
> >
> > If PIPGM_PCSR is 0, the hardware is stopped. Even if the settings of
> > other registers are written, the values of other registers will not work
> > unless PIPGM_PCSR is written.
> 
> Correct me if I'm wrong, but how I understand it, PCSR is special as the
> other registers are shadow until PCSR is written. (And that is
> irrespective of which value is active in PCSR or what is written to
> PCSR.)

This is correct.

>  
> > However, as a logic, if PIPGM_PCSR becomes 0, it is only
> > visconti_pwm_apply () in this driver,
> > so I think that this process should always be state-> enabled = true
> > as you pointed out.
> > I wil drop this, thanks.
> 
> For me the critical (and only) difference between "off" and
> "duty cycle = 0" is that when a new configuration is to be applied. In
> the "off" state a new period can (and should) start immediately, while
> with "duty_cycle = 0" the rising edge should be delayed until the
> currently running period is over.[1]
> 
> So the thing to do here (IMHO) is:
> 
> Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
> with writing a non-zero value to PIPGM_PCSR) completes the currently
> running period, then always assume the PWM as enabled.

Yes, this device works that way.

> 
> And so if the hardware is stopped and the counter is reset when 0 is
> written to PIPGM_PCSR, model that as enabled = false.

I don't think the current this driver can handle the above.
As far as I can see your comment, I think I need to implement this,
but after writing 0 to PIPGM_PCSR, driver need to confirm that signal has
changed to low level and change state->enabled to false. 
But with this device has no way of knowing that the signal has changed
to low level.

> 
> Best regards
> Uwe
> 
> [1] In practise this is more difficult because several PWMs don't
> complete periods in general. But the hardware under discussion luckily
> isn't one of these. And (worse) there are other hardware implementations
> where off doesn't emit an inactive level.

I see.

Best regards,
  Nobuhiro


From jbx6244 at gmail.com  Fri Apr 16 09:03:37 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:37 +0200
Subject: [PATCH v8 10/15] dt-bindings: add power-domain header for RK3568 SoCs
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-11-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/power/rk3568-power.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3568-power.h

diff --git a/include/dt-bindings/power/rk3568-power.h b/include/dt-bindings/power/rk3568-power.h
new file mode 100644
index 000000000..6cc1af1a9
--- /dev/null
+++ b/include/dt-bindings/power/rk3568-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3568_POWER_H__
+#define __DT_BINDINGS_POWER_RK3568_POWER_H__
+
+/* VD_CORE */
+#define RK3568_PD_CPU_0		0
+#define RK3568_PD_CPU_1		1
+#define RK3568_PD_CPU_2		2
+#define RK3568_PD_CPU_3		3
+#define RK3568_PD_CORE_ALIVE	4
+
+/* VD_PMU */
+#define RK3568_PD_PMU		5
+
+/* VD_NPU */
+#define RK3568_PD_NPU		6
+
+/* VD_GPU */
+#define RK3568_PD_GPU		7
+
+/* VD_LOGIC */
+#define RK3568_PD_VI		8
+#define RK3568_PD_VO		9
+#define RK3568_PD_RGA		10
+#define RK3568_PD_VPU		11
+#define RK3568_PD_CENTER	12
+#define RK3568_PD_RKVDEC	13
+#define RK3568_PD_RKVENC	14
+#define RK3568_PD_PIPE		15
+#define RK3568_PD_LOGIC_ALIVE	16
+
+#endif
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:40 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:40 +0200
Subject: [PATCH v8 13/15] dt-bindings: power: rockchip: Convert to json-schema
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-14-jbx6244@gmail.com>

From: Enric Balletbo i Serra <enric.balletbo at collabora.com>

Convert the soc/rockchip/power_domain.txt binding document to
json-schema and move to the power bindings directory.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Note for rob+dt:
A tag was not added on purpose, because:
  Add "rockchip," prefix to the qos compatible name
  in example.
  Changed maintainers.
  Size reg description is reduced.
  Little style changes '' to ""
Please have a look at it again.

For some SoC nodes this patch serie generates notifications
for undocumented "assigned-clocks" and "assigned-clock-parents"
properties till there is consensus of what to do with it.
---
Changed V8:
  Add pd-node ref schema
Changed V7:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
Changed V6:
  Changed author
Changed V5:
  Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
  Remove a maintainer
  Changed patternProperties to power-domain
  Add "clocks", "assigned-clocks" and "assigned-clock-parents"
Changed V4:
  Remove new compatible string
  Style changes '' to ""
Changed V3:
  Use Enric's conversion with rk3399 example
Changed V2:
  Convert power_domain.txt to YAML with rk3568 example
---
 .../bindings/power/rockchip,power-controller.yaml  | 257 +++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 -----------
 2 files changed, 257 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
new file mode 100644
index 000000000..2b9950fd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -0,0 +1,257 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Domains
+
+maintainers:
+  - Elaine Zhang <zhangqing at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |
+  Rockchip processors include support for multiple power domains
+  which can be powered up/down by software based on different
+  application scenarios to save power.
+
+  Power domains contained within power-controller node are
+  generic power domain providers documented in
+  Documentation/devicetree/bindings/power/power-domain.yaml.
+
+  IP cores belonging to a power domain should contain a
+  "power-domains" property that is a phandle for the
+  power domain node representing the domain.
+
+properties:
+  $nodename:
+    const: power-controller
+
+  compatible:
+    enum:
+      - rockchip,px30-power-controller
+      - rockchip,rk3036-power-controller
+      - rockchip,rk3066-power-controller
+      - rockchip,rk3128-power-controller
+      - rockchip,rk3188-power-controller
+      - rockchip,rk3228-power-controller
+      - rockchip,rk3288-power-controller
+      - rockchip,rk3328-power-controller
+      - rockchip,rk3366-power-controller
+      - rockchip,rk3368-power-controller
+      - rockchip,rk3399-power-controller
+
+  "#power-domain-cells":
+    const: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+    properties:
+
+      "#power-domain-cells":
+        enum: [0, 1]
+        description:
+          Must be 0 for nodes representing a single PM domain and 1 for nodes
+          providing multiple PM domains.
+
+      "#address-cells":
+        const: 1
+
+      "#size-cells":
+        const: 0
+
+    $ref: "#/definitions/pd-node"
+
+    patternProperties:
+      "^power-domain@[0-9a-f]+$":
+        properties:
+
+          "#power-domain-cells":
+            enum: [0, 1]
+
+          "#address-cells":
+            const: 1
+
+          "#size-cells":
+            const: 0
+
+        $ref: "#/definitions/pd-node"
+
+        patternProperties:
+          "^power-domain@[0-9a-f]+$":
+            properties:
+
+              "#power-domain-cells":
+                const: 0
+
+            $ref: "#/definitions/pd-node"
+
+            required:
+              - "#power-domain-cells"
+
+            unevaluatedProperties: false
+
+        required:
+          - "#power-domain-cells"
+
+        unevaluatedProperties: false
+
+    required:
+      - "#power-domain-cells"
+
+    unevaluatedProperties: false
+
+required:
+  - compatible
+  - "#power-domain-cells"
+
+additionalProperties: false
+
+definitions:
+  pd-node:
+    type: object
+    description: |
+      Represents the power domains within the power controller node.
+
+    properties:
+      reg:
+        maxItems: 1
+        description: |
+          Power domain index. Valid values are defined in
+          "include/dt-bindings/power/px30-power.h"
+          "include/dt-bindings/power/rk3036-power.h"
+          "include/dt-bindings/power/rk3066-power.h"
+          "include/dt-bindings/power/rk3128-power.h"
+          "include/dt-bindings/power/rk3188-power.h"
+          "include/dt-bindings/power/rk3228-power.h"
+          "include/dt-bindings/power/rk3288-power.h"
+          "include/dt-bindings/power/rk3328-power.h"
+          "include/dt-bindings/power/rk3366-power.h"
+          "include/dt-bindings/power/rk3368-power.h"
+          "include/dt-bindings/power/rk3399-power.h"
+
+      clocks:
+        minItems: 1
+        maxItems: 30
+        description: |
+          A number of phandles to clocks that need to be enabled
+          while power domain switches state.
+
+      pm_qos:
+        $ref: /schemas/types.yaml#/definitions/phandle-array
+        description: |
+          A number of phandles to qos blocks which need to be saved and restored
+          while power domain switches state.
+
+    required:
+      - reg
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3399-cru.h>
+    #include <dt-bindings/power/rk3399-power.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        qos_hdcp: qos at ffa90000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa90000 0x0 0x20>;
+        };
+
+        qos_iep: qos at ffa98000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa98000 0x0 0x20>;
+        };
+
+        qos_rga_r: qos at ffab0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0000 0x0 0x20>;
+        };
+
+        qos_rga_w: qos at ffab0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0080 0x0 0x20>;
+        };
+
+        qos_video_m0: qos at ffab8000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab8000 0x0 0x20>;
+        };
+
+        qos_video_m1_r: qos at ffac0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0000 0x0 0x20>;
+        };
+
+        qos_video_m1_w: qos at ffac0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0080 0x0 0x20>;
+        };
+
+        power-management at ff310000 {
+            compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
+            reg = <0x0 0xff310000 0x0 0x1000>;
+
+            power-controller {
+                compatible = "rockchip,rk3399-power-controller";
+                #power-domain-cells = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                /* These power domains are grouped by VD_CENTER */
+                power-domain at RK3399_PD_IEP {
+                    reg = <RK3399_PD_IEP>;
+                    clocks = <&cru ACLK_IEP>,
+                             <&cru HCLK_IEP>;
+                    pm_qos = <&qos_iep>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_RGA {
+                    reg = <RK3399_PD_RGA>;
+                    clocks = <&cru ACLK_RGA>,
+                             <&cru HCLK_RGA>;
+                    pm_qos = <&qos_rga_r>,
+                             <&qos_rga_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VCODEC {
+                    reg = <RK3399_PD_VCODEC>;
+                    clocks = <&cru ACLK_VCODEC>,
+                             <&cru HCLK_VCODEC>;
+                    pm_qos = <&qos_video_m0>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VDU {
+                    reg = <RK3399_PD_VDU>;
+                    clocks = <&cru ACLK_VDU>,
+                             <&cru HCLK_VDU>;
+                    pm_qos = <&qos_video_m1_r>,
+                             <&qos_video_m1_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VIO {
+                    reg = <RK3399_PD_VIO>;
+                    #power-domain-cells = <1>;
+                    #address-cells = <1>;
+                    #size-cells = <0>;
+
+                    power-domain at RK3399_PD_HDCP {
+                        reg = <RK3399_PD_HDCP>;
+                        clocks = <&cru ACLK_HDCP>,
+                                 <&cru HCLK_HDCP>,
+                                 <&cru PCLK_HDCP>;
+                        pm_qos = <&qos_hdcp>;
+                        #power-domain-cells = <0>;
+                    };
+                };
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
deleted file mode 100644
index 8304eceb6..000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-* Rockchip Power Domains
-
-Rockchip processors include support for multiple power domains which can be
-powered up/down by software based on different application scenes to save power.
-
-Required properties for power domain controller:
-- compatible: Should be one of the following.
-	"rockchip,px30-power-controller" - for PX30 SoCs.
-	"rockchip,rk3036-power-controller" - for RK3036 SoCs.
-	"rockchip,rk3066-power-controller" - for RK3066 SoCs.
-	"rockchip,rk3128-power-controller" - for RK3128 SoCs.
-	"rockchip,rk3188-power-controller" - for RK3188 SoCs.
-	"rockchip,rk3228-power-controller" - for RK3228 SoCs.
-	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
-	"rockchip,rk3328-power-controller" - for RK3328 SoCs.
-	"rockchip,rk3366-power-controller" - for RK3366 SoCs.
-	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
-	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
-- #power-domain-cells: Number of cells in a power-domain specifier.
-	Should be 1 for multiple PM domains.
-- #address-cells: Should be 1.
-- #size-cells: Should be 0.
-
-Required properties for power domain sub nodes:
-- reg: index of the power domain, should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
-	"include/dt-bindings/power/rk3066-power.h" - for RK3066 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
-	"include/dt-bindings/power/rk3188-power.h" - for RK3188 type power domain.
-	"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
-- clocks (optional): phandles to clocks which need to be enabled while power domain
-	switches state.
-- pm_qos (optional): phandles to qos blocks which need to be saved and restored
-	while power domain switches state.
-
-Qos Example:
-
-	qos_gpu: qos_gpu at ffaf0000 {
-		compatible ="syscon";
-		reg = <0x0 0xffaf0000 0x0 0x20>;
-	};
-
-Example:
-
-	power: power-controller {
-		compatible = "rockchip,rk3288-power-controller";
-		#power-domain-cells = <1>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pd_gpu {
-			reg = <RK3288_PD_GPU>;
-			clocks = <&cru ACLK_GPU>;
-			pm_qos = <&qos_gpu>;
-		};
-	};
-
-	 power: power-controller {
-                compatible = "rockchip,rk3368-power-controller";
-                #power-domain-cells = <1>;
-                #address-cells = <1>;
-                #size-cells = <0>;
-
-                pd_gpu_1 {
-                        reg = <RK3368_PD_GPU_1>;
-                        clocks = <&cru ACLK_GPU_CFG>;
-                };
-        };
-
-Example 2:
-		power: power-controller {
-			compatible = "rockchip,rk3399-power-controller";
-			#power-domain-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			pd_vio {
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <RK3399_PD_VIO>;
-
-				pd_vo {
-					#address-cells = <1>;
-					#size-cells = <0>;
-					reg = <RK3399_PD_VO>;
-
-					pd_vopb {
-						reg = <RK3399_PD_VOPB>;
-					};
-
-					pd_vopl {
-						reg = <RK3399_PD_VOPL>;
-					};
-				};
-			};
-		};
-
-Node of a device using power domains must have a power-domains property,
-containing a phandle to the power device node and an index specifying which
-power domain to use.
-The index should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for px30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
-
-Example of the node using power domain:
-
-	node {
-		/* ... */
-		power-domains = <&power RK3288_PD_GPU>;
-		/* ... */
-	};
-
-	node {
-                /* ... */
-                power-domains = <&power RK3368_PD_GPU_1>;
-                /* ... */
-        };
-
-	node {
-		/* ... */
-		power-domains = <&power RK3399_PD_VOPB>;
-		/* ... */
-	};
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:39 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:39 +0200
Subject: [PATCH v8 12/15] dt-bindings: arm: rockchip: add more compatible
 strings to pmu.yaml
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-13-jbx6244@gmail.com>

The compatible strings below are already in use in the Rockchip
dtsi files, but were somehow never added to a document, so add

"rockchip,px30-pmu", "syscon", "simple-mfd"
"rockchip,rk3288-pmu", "syscon", "simple-mfd"
"rockchip,rk3328-pmu", "syscon", "simple-mfd"
"rockchip,rk3399-pmu", "syscon", "simple-mfd"

for pmu nodes to pmu.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 0b816943d..678be9011 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -19,7 +19,11 @@ select:
     compatible:
       contains:
         enum:
+          - rockchip,px30-pmu
           - rockchip,rk3066-pmu
+          - rockchip,rk3288-pmu
+          - rockchip,rk3328-pmu
+          - rockchip,rk3399-pmu
 
   required:
     - compatible
@@ -28,7 +32,11 @@ properties:
   compatible:
     items:
       - enum:
+          - rockchip,px30-pmu
           - rockchip,rk3066-pmu
+          - rockchip,rk3288-pmu
+          - rockchip,rk3328-pmu
+          - rockchip,rk3399-pmu
       - const: syscon
       - const: simple-mfd
 
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:42 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:42 +0200
Subject: [PATCH v8 15/15] soc: rockchip: power-domain: add rk3568 powerdomains
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-16-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add power-domains found on rk3568 socs.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 1d1b06672..0868b7d40 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -27,6 +27,7 @@
 #include <dt-bindings/power/rk3366-power.h>
 #include <dt-bindings/power/rk3368-power.h>
 #include <dt-bindings/power/rk3399-power.h>
+#include <dt-bindings/power/rk3568-power.h>
 
 struct rockchip_domain_info {
 	const char *name;
@@ -135,6 +136,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
 	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
+#define DOMAIN_RK3568(name, pwr, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, req, req, wakeup)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -848,6 +852,18 @@ static const struct rockchip_domain_info rk3399_pm_domains[] = {
 	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
+static const struct rockchip_domain_info rk3568_pm_domains[] = {
+	[RK3568_PD_NPU]		= DOMAIN_RK3568("npu",  BIT(1), BIT(2),  false),
+	[RK3568_PD_GPU]		= DOMAIN_RK3568("gpu",  BIT(0), BIT(1),  false),
+	[RK3568_PD_VI]		= DOMAIN_RK3568("vi",   BIT(6), BIT(3),  false),
+	[RK3568_PD_VO]		= DOMAIN_RK3568("vo",   BIT(7), BIT(4),  false),
+	[RK3568_PD_RGA]		= DOMAIN_RK3568("rga",  BIT(5), BIT(5),  false),
+	[RK3568_PD_VPU]		= DOMAIN_RK3568("vpu",  BIT(2), BIT(6),  false),
+	[RK3568_PD_RKVDEC]	= DOMAIN_RK3568("vdec", BIT(4), BIT(8),  false),
+	[RK3568_PD_RKVENC]	= DOMAIN_RK3568("venc", BIT(3), BIT(7),  false),
+	[RK3568_PD_PIPE]	= DOMAIN_RK3568("pipe", BIT(8), BIT(11), false),
+};
+
 static const struct rockchip_pmu_info px30_pmu = {
 	.pwr_offset = 0x18,
 	.status_offset = 0x20,
@@ -983,6 +999,17 @@ static const struct rockchip_pmu_info rk3399_pmu = {
 	.domain_info = rk3399_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3568_pmu = {
+	.pwr_offset = 0xa0,
+	.status_offset = 0x98,
+	.req_offset = 0x50,
+	.idle_offset = 0x68,
+	.ack_offset = 0x60,
+
+	.num_domains = ARRAY_SIZE(rk3568_pm_domains),
+	.domain_info = rk3568_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,px30-power-controller",
@@ -1028,6 +1055,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3399-power-controller",
 		.data = (void *)&rk3399_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3568-power-controller",
+		.data = (void *)&rk3568_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
2.11.0



From jbx6244 at gmail.com  Fri Apr 16 09:03:41 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 16 Apr 2021 10:03:41 +0200
Subject: [PATCH v8 14/15] dt-bindings: power: rockchip: Add bindings for
 RK3568 Soc
In-Reply-To: <20210416080342.18614-1-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
Message-ID: <20210416080342.18614-15-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the compatible string for RK3568 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
A note for rob+dt and others:
  A review and ack tag was not added, because in this version
  the schema layout changed a bit
Please have a look at it again

Changed V8:
  Add pd-node ref schema
---
 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
index 2b9950fd6..24eb00834 100644
--- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -40,6 +40,7 @@ properties:
       - rockchip,rk3366-power-controller
       - rockchip,rk3368-power-controller
       - rockchip,rk3399-power-controller
+      - rockchip,rk3568-power-controller
 
   "#power-domain-cells":
     const: 1
@@ -135,6 +136,7 @@ definitions:
           "include/dt-bindings/power/rk3366-power.h"
           "include/dt-bindings/power/rk3368-power.h"
           "include/dt-bindings/power/rk3399-power.h"
+          "include/dt-bindings/power/rk3568-power.h"
 
       clocks:
         minItems: 1
-- 
2.11.0



From gregkh at linuxfoundation.org  Fri Apr 16 09:11:25 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 16 Apr 2021 10:11:25 +0200
Subject: [PATCH 0/2] *** SUBJECT HERE ***
In-Reply-To: <1618560476-28908-1-git-send-email-taozha@codeaurora.org>
References: <1618560476-28908-1-git-send-email-taozha@codeaurora.org>
Message-ID: <YHlGrcghXrwe2RKm@kroah.com>

On Fri, Apr 16, 2021 at 04:07:54PM +0800, Tao Zhang wrote:
> *** BLURB HERE ***

Where is the blurb?

And your subject is not ok :(



From johan at kernel.org  Fri Apr 16 09:35:45 2021
From: johan at kernel.org (Johan Hovold)
Date: Fri, 16 Apr 2021 10:35:45 +0200
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
 <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
Message-ID: <YHlMYZCCxL+SS9ye@hovoldconsulting.com>

On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote:
> Hi Johan, Erwan
> 
> It seems still a bit of a problem in the current version, not deadlock
> but access register at the same time.
> 
> For driver , we should consider it running under smp, let's think
> about it for this case:
> 
> static void stm32_usart_console_write(struct console *co, const char *s,
>                                       unsigned int cnt)
> {
>          .....
>          local_irq_save(flags);
>          if (port->sysrq)
>                     locked = 0;
>          .....
>          access register cr1, tdr, isr
>          .....
> 
>          local_irq_restore(flags);
> }
> 
> if port->sysrq is 1, stm32_usart_console_write() just disable local
> irq response by local_irq_save(), at the time of access register cr1,
> tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> mpu/mcu do not have multi cores, just assume it has), it still has a
> chance to handle interrupt.  Then there is no lock to protect the uart
> register.

Right, the sysrq handling is a bit of a hack.

> changes to below, should be more safe:
> 
> .....
> if (port->sysrq || oops_in_progress)
>       locked = spin_trylock_irqsave(&port->lock, flags);

Except that the lock debugging code would detect the attempt at
recursive locking here and complain loudly on UP.

If you really want to fix this, we have uart_unlock_and_check_sysrq()
which can be used to defer sysrq processing until the interrupt handler
has released the lock.

> else
>       spin_lock_irqsave(&port->lock, flags);
> 
> ....
> 
> if (locked)
>      spin_unlock_irqrestore(&port->lock, flags);

Johan


From steen.hegelund at microchip.com  Fri Apr 16 09:40:52 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 10:40:52 +0200
Subject: [PATCH v9 1/3] dt-bindings: reset: microchip sparx5 reset driver
 bindings
In-Reply-To: <20210416084054.2922327-1-steen.hegelund@microchip.com>
References: <20210416084054.2922327-1-steen.hegelund@microchip.com>
Message-ID: <20210416084054.2922327-2-steen.hegelund@microchip.com>

Document the Sparx5 reset device driver bindings

The driver uses a syscon and an IO range on sparx5 for access to
the reset control and the reset status.

Sparx5 will no longer use the existing Ocelot chip reset driver, but use
this new switch reset driver as it has the reset controller interface that
allows the first client to perform the reset on behalf of all the Sparx5
component drivers.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/reset/microchip,rst.yaml         | 58 +++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml

diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
new file mode 100644
index 000000000000..370579aeeca1
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Microchip Sparx5 Switch Reset Controller
+
+maintainers:
+  - Steen Hegelund <steen.hegelund at microchip.com>
+  - Lars Povlsen <lars.povlsen at microchip.com>
+
+description: |
+  The Microchip Sparx5 Switch provides reset control and implements the following
+  functions
+    - One Time Switch Core Reset (Soft Reset)
+
+properties:
+  $nodename:
+    pattern: "^reset-controller@[0-9a-f]+$"
+
+  compatible:
+    const: microchip,sparx5-switch-reset
+
+  reg:
+    items:
+      - description: global control block registers
+
+  reg-names:
+    items:
+      - const: gcb
+
+  "#reset-cells":
+    const: 1
+
+  cpu-syscon:
+    $ref: "/schemas/types.yaml#/definitions/phandle"
+    description: syscon used to access CPU reset
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - "#reset-cells"
+  - cpu-syscon
+
+additionalProperties: false
+
+examples:
+  - |
+    reset: reset-controller at 11010008 {
+        compatible = "microchip,sparx5-switch-reset";
+        reg = <0x11010008 0x4>;
+        reg-names = "gcb";
+        #reset-cells = <1>;
+        cpu-syscon = <&cpu_ctrl>;
+    };
+
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 09:40:51 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 10:40:51 +0200
Subject: [PATCH v9 0/3] Adding the Sparx5 Switch Reset Driver
Message-ID: <20210416084054.2922327-1-steen.hegelund@microchip.com>

This series provides the Microchip Sparx5 Switch Reset Driver

The Sparx5 Switch SoC has a number of components that can be reset
individually, but at least the Switch Core needs to be in a well defined
state at power on, when any of the Sparx5 drivers starts to access the
Switch Core, this reset driver is available.

The reset driver is loaded early via the postcore_initcall interface, and
will then be available for the other Sparx5 drivers (SGPIO, SwitchDev etc)
that are loaded next, and the first of them to be loaded can perform the
one-time Switch Core reset that is needed.

The driver has protection so that the system busses, DDR controller, PCI-E
and ARM A53 CPU and a few other subsystems are not touched by the reset.

Sparx5 will no longer use the existing Ocelot chip reset driver, but use
this new switch reset driver as it has the reset controller interface that
allows the first client to perform the reset on behalf of all the Sparx5
component drivers.

The Sparx5 Chip Register Model can be browsed at this location:
https://github.com/microchip-ung/sparx-5_reginfo
and the datasheet is available here:
https://ww1.microchip.com/downloads/en/DeviceDoc/SparX-5_Family_L2L3_Enterprise_10G_Ethernet_Switches_Datasheet_00003822B.pdf

History:

v8 -> v9 Added reviewed-by tag.

v7 -> v8 Updated the commit descriptions to explain the change from using
         the existing Ocelot chip reset driver to use a new switch reset
         driver.

v6 -> v7 Use devm_platform_get_and_ioremap_resource to get the IO range.
         Rebase on v5.12-rc1

v5 -> v6 Using the existing CPU syscon for reset protection and add a small
         IO range for the GCB Reset Register.

v4 -> v5 Changed the two syscons into IO ranges and updated the bindings to
         reflect this change.

v3 -> v4 Added commit message descriptions

v2 -> v3 Removed unused headers
         Renamed the reset controller dev member.
         Use regmap_read_poll_timeout instead of polling a function.
         Used two separate syscon entries in the binding
         Simplified the syscon error handling.
         Simplified the devm_reset_controller_register error handling.
         Moved the contents of the mchp_sparx5_reset_config function into
         the probe function.

v1 -> v2 Removed debug prints
         Changed the error handling to save the error code before jumping.

Steen Hegelund (3):
  dt-bindings: reset: microchip sparx5 reset driver bindings
  reset: mchp: sparx5: add switch reset driver
  arm64: dts: reset: add microchip sparx5 switch reset driver

 .../bindings/reset/microchip,rst.yaml         |  58 +++++++
 arch/arm64/boot/dts/microchip/sparx5.dtsi     |   7 +-
 drivers/reset/Kconfig                         |   8 +
 drivers/reset/Makefile                        |   1 +
 drivers/reset/reset-microchip-sparx5.c        | 146 ++++++++++++++++++
 5 files changed, 218 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml
 create mode 100644 drivers/reset/reset-microchip-sparx5.c

-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 09:40:53 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 10:40:53 +0200
Subject: [PATCH v9 2/3] reset: mchp: sparx5: add switch reset driver
In-Reply-To: <20210416084054.2922327-1-steen.hegelund@microchip.com>
References: <20210416084054.2922327-1-steen.hegelund@microchip.com>
Message-ID: <20210416084054.2922327-3-steen.hegelund@microchip.com>

The Sparx5 Switch SoC has a number of components that can be reset
indiviually, but at least the Switch Core needs to be in a well defined
state at power on, when any of the Sparx5 drivers starts to access the
Switch Core, this reset driver is available.

The reset driver is loaded early via the postcore_initcall interface, and
will then be available for the other Sparx5 drivers (SGPIO, SwitchDev etc)
that are loaded next, and the first of them to be loaded can perform the
one-time Switch Core reset that is needed.

The driver has protection so that the system busses, DDR controller, PCI-E
and ARM A53 CPU and a few other subsystems are not touched by the reset.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 drivers/reset/Kconfig                  |   8 ++
 drivers/reset/Makefile                 |   1 +
 drivers/reset/reset-microchip-sparx5.c | 146 +++++++++++++++++++++++++
 3 files changed, 155 insertions(+)
 create mode 100644 drivers/reset/reset-microchip-sparx5.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 4171c6f76385..c26798092ccf 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -111,6 +111,14 @@ config RESET_LPC18XX
 	help
 	  This enables the reset controller driver for NXP LPC18xx/43xx SoCs.
 
+config RESET_MCHP_SPARX5
+	bool "Microchip Sparx5 reset driver"
+	depends on HAS_IOMEM || COMPILE_TEST
+	default y if SPARX5_SWITCH
+	select MFD_SYSCON
+	help
+	  This driver supports switch core reset for the Microchip Sparx5 SoC.
+
 config RESET_MESON
 	tristate "Meson Reset Driver"
 	depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 65a118a91b27..c1d6aa9b1b52 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o
 obj-$(CONFIG_RESET_K210) += reset-k210.o
 obj-$(CONFIG_RESET_LANTIQ) += reset-lantiq.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_RESET_MCHP_SPARX5) += reset-microchip-sparx5.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_MESON_AUDIO_ARB) += reset-meson-audio-arb.o
 obj-$(CONFIG_RESET_NPCM) += reset-npcm.o
diff --git a/drivers/reset/reset-microchip-sparx5.c b/drivers/reset/reset-microchip-sparx5.c
new file mode 100644
index 000000000000..cff39a643a14
--- /dev/null
+++ b/drivers/reset/reset-microchip-sparx5.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch Reset driver
+ *
+ * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
+ *
+ * The Sparx5 Chip Register Model can be browsed at this location:
+ * https://github.com/microchip-ung/sparx-5_reginfo
+ */
+#include <linux/mfd/syscon.h>
+#include <linux/of_device.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/reset-controller.h>
+
+#define PROTECT_REG    0x84
+#define PROTECT_BIT    BIT(10)
+#define SOFT_RESET_REG 0x00
+#define SOFT_RESET_BIT BIT(1)
+
+struct mchp_reset_context {
+	struct regmap *cpu_ctrl;
+	struct regmap *gcb_ctrl;
+	struct reset_controller_dev rcdev;
+};
+
+static struct regmap_config sparx5_reset_regmap_config = {
+	.reg_bits	= 32,
+	.val_bits	= 32,
+	.reg_stride	= 4,
+};
+
+static int sparx5_switch_reset(struct reset_controller_dev *rcdev,
+			       unsigned long id)
+{
+	struct mchp_reset_context *ctx =
+		container_of(rcdev, struct mchp_reset_context, rcdev);
+	u32 val;
+
+	/* Make sure the core is PROTECTED from reset */
+	regmap_update_bits(ctx->cpu_ctrl, PROTECT_REG, PROTECT_BIT, PROTECT_BIT);
+
+	/* Start soft reset */
+	regmap_write(ctx->gcb_ctrl, SOFT_RESET_REG, SOFT_RESET_BIT);
+
+	/* Wait for soft reset done */
+	return regmap_read_poll_timeout(ctx->gcb_ctrl, SOFT_RESET_REG, val,
+					(val & SOFT_RESET_BIT) == 0,
+					1, 100);
+}
+
+static const struct reset_control_ops sparx5_reset_ops = {
+	.reset = sparx5_switch_reset,
+};
+
+static int mchp_sparx5_map_syscon(struct platform_device *pdev, char *name,
+				  struct regmap **target)
+{
+	struct device_node *syscon_np;
+	struct regmap *regmap;
+	int err;
+
+	syscon_np = of_parse_phandle(pdev->dev.of_node, name, 0);
+	if (!syscon_np)
+		return -ENODEV;
+	regmap = syscon_node_to_regmap(syscon_np);
+	of_node_put(syscon_np);
+	if (IS_ERR(regmap)) {
+		err = PTR_ERR(regmap);
+		dev_err(&pdev->dev, "No '%s' map: %d\n", name, err);
+		return err;
+	}
+	*target = regmap;
+	return 0;
+}
+
+static int mchp_sparx5_map_io(struct platform_device *pdev, int index,
+			      struct regmap **target)
+{
+	struct resource *res;
+	struct regmap *map;
+	void __iomem *mem;
+
+	mem = devm_platform_get_and_ioremap_resource(pdev, index, &res);
+	if (!mem) {
+		dev_err(&pdev->dev, "Could not map resource %d\n", index);
+		return -ENXIO;
+	}
+	sparx5_reset_regmap_config.name = res->name;
+	map = devm_regmap_init_mmio(&pdev->dev, mem, &sparx5_reset_regmap_config);
+	if (IS_ERR(map))
+		return PTR_ERR(map);
+	*target = map;
+	return 0;
+}
+
+static int mchp_sparx5_reset_probe(struct platform_device *pdev)
+{
+	struct device_node *dn = pdev->dev.of_node;
+	struct mchp_reset_context *ctx;
+	int err;
+
+	ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	err = mchp_sparx5_map_syscon(pdev, "cpu-syscon", &ctx->cpu_ctrl);
+	if (err)
+		return err;
+	err = mchp_sparx5_map_io(pdev, 0, &ctx->gcb_ctrl);
+	if (err)
+		return err;
+
+	ctx->rcdev.owner = THIS_MODULE;
+	ctx->rcdev.nr_resets = 1;
+	ctx->rcdev.ops = &sparx5_reset_ops;
+	ctx->rcdev.of_node = dn;
+
+	return devm_reset_controller_register(&pdev->dev, &ctx->rcdev);
+}
+
+static const struct of_device_id mchp_sparx5_reset_of_match[] = {
+	{
+		.compatible = "microchip,sparx5-switch-reset",
+	},
+	{ }
+};
+
+static struct platform_driver mchp_sparx5_reset_driver = {
+	.probe = mchp_sparx5_reset_probe,
+	.driver = {
+		.name = "sparx5-switch-reset",
+		.of_match_table = mchp_sparx5_reset_of_match,
+	},
+};
+
+static int __init mchp_sparx5_reset_init(void)
+{
+	return platform_driver_register(&mchp_sparx5_reset_driver);
+}
+
+postcore_initcall(mchp_sparx5_reset_init);
+
+MODULE_DESCRIPTION("Microchip Sparx5 switch reset driver");
+MODULE_AUTHOR("Steen Hegelund <steen.hegelund at microchip.com>");
+MODULE_LICENSE("Dual MIT/GPL");
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 09:40:54 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 10:40:54 +0200
Subject: [PATCH v9 3/3] arm64: dts: reset: add microchip sparx5 switch reset
 driver
In-Reply-To: <20210416084054.2922327-1-steen.hegelund@microchip.com>
References: <20210416084054.2922327-1-steen.hegelund@microchip.com>
Message-ID: <20210416084054.2922327-4-steen.hegelund@microchip.com>

This provides reset driver support for the Microchip Sparx5 PCB134 and
PCB135 reference boards.

The Sparx5 Switch will no longer use the Ocelot Chip Reset Driver (with the
compatible string "microchip,sparx5-chip-reset"), but use a separate driver
that exposes a reset controller interface and has the compatiple string
"microchip,sparx5-switch-reset".

Eventually the Sparx5 reset support will be removed from the Ocelot chip
reset driver.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 380281f312d8..dc3ada5cf9fc 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -132,9 +132,12 @@ mux: mux-controller {
 			};
 		};
 
-		reset at 611010008 {
-			compatible = "microchip,sparx5-chip-reset";
+		reset: reset-controller at 611010008 {
+			compatible = "microchip,sparx5-switch-reset";
 			reg = <0x6 0x11010008 0x4>;
+			reg-names = "gcb";
+			#reset-cells = <1>;
+			cpu-syscon = <&cpu_ctrl>;
 		};
 
 		uart0: serial at 600100000 {
-- 
2.31.1



From billy_tsai at aspeedtech.com  Fri Apr 16 09:44:52 2021
From: billy_tsai at aspeedtech.com (Billy Tsai)
Date: Fri, 16 Apr 2021 08:44:52 +0000
Subject: [v2 1/2] dt-bindings: Add bindings for aspeed pwm-tach and pwm.
In-Reply-To: <CAL_JsqLuswcRqQ-JQ9qgWQEhykPWCTsnVFLxCEPV6BbF86vWOw@mail.gmail.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
 <20210414104939.1093-2-billy_tsai@aspeedtech.com>
 <20210414221553.GA56046@robh.at.kernel.org>
 <B9287FE7-5EF5-40B3-BCB3-08DA11D6CDD7@aspeedtech.com>
 <CAL_JsqLuswcRqQ-JQ9qgWQEhykPWCTsnVFLxCEPV6BbF86vWOw@mail.gmail.com>
Message-ID: <C487E9FF-3DAD-4322-996A-8164861572CF@aspeedtech.com>


On 2021/4/15, 10:44 PM,Rob Herringwrote:

    >On Wed, Apr 14, 2021 at 10:44 PM Billy Tsai <billy_tsai at aspeedtech.com> wrote:
    >>
    >> Hi Rob,
    >>
    >> On 2021/4/15, 6:16 AM,Rob Herringwrote:
    >>
    >>     On Wed, Apr 14, 2021 at 06:49:38PM +0800, Billy Tsai wrote:
    >>     >> This patch adds device bindings for aspeed pwm-tach device which is a
    >>     >> multi-function device include pwn and tach function and pwm device which
    >>     >> should be the sub-node of pwm-tach device.
    >>     >>
    >>     >> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
    >>     >> Change-Id: I18d9dea14c3a04e1b7e38ffecd49d45917b9b545
    >>     >
    >>     >Drop
    >>     >
    >>     >> ---
    >>     >>  .../bindings/mfd/aspeed,ast2600-pwm-tach.yaml | 60 +++++++++++++++++++
    >>     >>  .../bindings/pwm/aspeed,ast2600-pwm.yaml      | 44 ++++++++++++++
    >>     >>  2 files changed, 104 insertions(+)
    >>     >>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
    >>     >>  create mode 100644 Documentation/devicetree/bindings/pwm/aspeed,ast2600-pwm.yaml
    >>     >>
    >>     >> diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
    >>     >> new file mode 100644
    >>     >> index 000000000000..eaf8bdf8d44e
    >>     >> --- /dev/null
    >>     >> +++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2600-pwm-tach.yaml
    >>     >> @@ -0,0 +1,60 @@
    >>     >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
    >>     >> +# Copyright (C) 2021 ASPEED, Inc.
    >>     >> +%YAML 1.2
    >>     >> +---
    >>     >> +$id: http://devicetree.org/schemas/mfd/aspeed,ast2600-pwm-tach.yaml#
    >>     >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
    >>     >> +
    >>     >> +title: PWM Tach controller Device Tree Bindings
    >>     >> +
    >>     >> +description: |
    >>     >> +  The PWM Tach controller is represented as a multi-function device which
    >>     >> +  includes:
    >>     >> +    PWM
    >>     >> +    Tach
    >>
    >>     > But is it really? A PWM and tach sounds like a fan controller. Look at
    >>
    >> Our PWM is not only for fans but also used for the motor, led, buzzer, and so on.
    >> So I want to split the function into two devices with a multi-function device.
    >> One for PWM output and one for tach monitor.
    >>
    >>     > other existing PWM+tach bindings we have for fans.
    >>
    >> I didn't see the PWM+tach bindings can you give some example for me, thanks.
    >
    >Let me grep 'tach' for you:
    >
    >Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
    >Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt
    >
    >Hey, look at that, there's already one for ASpeed. So the question is
    >how is the newer h/w different?
    >>
    >>     >> +
    >>     >> +maintainers:
    >>     >> +  - Billy Tsai <billy_tsai at aspeedtech.com>
    >>     >> +
    >>     >> +properties:
    >>     >> +  compatible:
    >>     >> +    items:
    >>     >> +      - enum:
    >>     >> +          - aspeed,ast2600-pwm-tach
    >>     >> +      - const: syscon
    >>     >> +      - const: simple-mfd
    >>     >> +  reg:
    >>     >> +    maxItems: 1
    >>     >> +  "#address-cells":
    >>     >> +    const: 1
    >>     >> +  "#size-cells":
    >>     >> +    const: 1
    >>     >> +
    >>     >> +required:
    >>     >> +  - compatible
    >>     >> +  - reg
    >>     >> +  - "#address-cells"
    >>     >> +  - "#size-cells"
    >>     >> +
    >>     >> +additionalProperties:
    >>     >> +  type: object
    >>
    >>     > As you know the 2 node names, they should be documented. However, see
    >>     > below.
    >>
    >>     >> +
    >>     >> +examples:
    >>     >> +  - |
    >>     >> +    pwm_tach: pwm_tach at 1e610000 {
    >>     >> +      compatible = "aspeed,ast2600-pwm-tach", "syscon", "simple-mfd";
    >>     >> +      #address-cells = <1>;
    >>     >> +      #size-cells = <1>;
    >>     >> +      reg = <0x1e610000 0x100>;
    >>     >> +
    >>     >> +      pwm: pwm at 0 {
    >>     >> +        compatible = "aspeed,ast2600-pwm";
    >>     >> +        #pwm-cells = <3>;
    >>     >> +        reg = <0x0 0x100>;
    >>     >> +      };
    >>     >> +
    >>     >> +      tach: tach at 1 {
    >>     >> +        compatible = "aspeed,ast2600-tach";
    >>     >> +        reg = <0x0 0x100>;
    >>
    >>     > You have 2 nodes at the same address. Not valid.
    >>
    >> Our pwm and tach is used the same base address and the offset is like below:
    >>
    >> PWM0 used 0x0 0x4, Tach0 used 0x8 0xc
    >> PWM1 used 0x10 0x14, Tach1 used 0x18 0x1c
    >> ...
    >>
    >> I will remove the reg property from pwm and tach node and remove the "#address-cells" and
    >> "#size-cells" from the parent node.
    >
    >That's not really the solution...
    >
    >>
    >>     >> +      };
    >>
    >>     > There's no real need for 2 child nodes. The parent node can be a PWM
    >>     > provider.
    >>
    >> However, In our usage, the parent node is a mfd, not a simple PWM device only. I don't want to
    >> combine the different functions with the one device node.
    >
    >Looks like a single h/w block to me. If you want to divide that up
    >into multiple drivers, then that's an OS problem. A single node can be
    >multiple providers. For example, on the existing aspeed binding, just
    >add '#pwm-cells' to the node if you want to also expose it as a PWM
    >provider.
    >
    >Rob

I don't think the pwm/tach should be a single h/w block. 
See the kontron,sl28cpld.yaml:
hwmon at b {
        compatible = "kontron,sl28cpld-fan";
        reg = <0xb>;
};

pwm at c {
        compatible = "kontron,sl28cpld-pwm";
        reg = <0xc>;
        #pwm-cells = <2>;
};
They can be the different function from the dts.

Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
Documentation/devicetree/bindings/hwmon/npcm750-pwm-fan.txt

These two devices are specific to the used for fan like
Documentation/devicetree/bindings/hwmon/pwm-fan.txt, but with our usage,
it doesn't just for the fan. In our scenario, the customer wants to
create a pwm-beeper, so he needs one pwm input and he doesn't need the
tach function. If I used the pwm-fan as the beeper's pwm input, it look
weird.
Therefore, I want to split these two functions into different devices.

If my thinking is wrong, please let me know.

Very appreciate.


From krzk at kernel.org  Fri Apr 16 09:45:33 2021
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Fri, 16 Apr 2021 10:45:33 +0200
Subject: [PATCH] regulator: mt6360: Fix missing IRQF_ONESHOT as only
 threaded handler
In-Reply-To: <20210416034712.7891-1-zhuguangqing83@gmail.com>
References: <20210416034712.7891-1-zhuguangqing83@gmail.com>
Message-ID: <CAJKOXPe+eK-2cZ2h-WUUrfPwkXrHGopaEmx0Kwjsa4Nqq0DyeA@mail.gmail.com>

On Fri, 16 Apr 2021 at 06:30, <zhuguangqing83 at gmail.com> wrote:
>
> From: Guangqing Zhu <zhuguangqing83 at gmail.com>
>
> Coccinelle noticed:
> drivers/regulator/mt6360-regulator.c:386:8-33: ERROR: Threaded IRQ with no
> primary handler requested without IRQF_ONESHOT

This should be tested. There are several patches like this all over
the tree so it looks like "let's fix everything from Coccinelle"
because you ignored at least in some of the cases that the handler is
not the primary one. I am not saying that the change is bad, but
rather it looks automated.

Best regards,
Krzysztof


From johan at kernel.org  Fri Apr 16 09:51:09 2021
From: johan at kernel.org (Johan Hovold)
Date: Fri, 16 Apr 2021 10:51:09 +0200
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <e17fddfb-f9b8-238f-da74-a4746f33134f@foss.st.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
 <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
 <e17fddfb-f9b8-238f-da74-a4746f33134f@foss.st.com>
Message-ID: <YHlP/SryZXr/nNLM@hovoldconsulting.com>

[ Please avoid top-posting. ]

On Thu, Apr 15, 2021 at 07:09:14PM +0200, Erwan LE RAY wrote:
> Hi Dillon,
> 
> STM32MP151 is mono-core, but both STM32MP153 and STM32MP157 are 
> dual-core (see 
> https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-arm-cortex-mpus.html).
> So your point is fully relevant, thanks.
> 
> ST already fixed the same issue in st-asc.c driver in the past (see 
> ef49ffd8), because a systematic deadlock was detected with RT kernel.

That's not the same issue. The above mentioned commit fixed an issue on
*RT* where local_irq_save() should be avoided.

> You proposed a first implementation in your patch, and a second one in 
> the discussion. It seems that your initial proposal (ie your V2 patch) 
> is the most standard one (implemented in 6 drivers). The second 
> implementation is implemented by only 1 company.
> 
> It looks that the solution is to avoid locking in the sysrq case and 
> trylock in the oops_in_progress case (see detailed analysis in 
> 677fe555cbfb1).
>
> So your initial patch looks to the right proposal, but it would be safer 
> if Greg could confirm it.

That would only fix the RT issue (and by making the sysrq one slightly
worse).

Using uart_unlock_and_check_sysrq() would address both issues.

Johan


From dillon.minfei at gmail.com  Fri Apr 16 09:56:57 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Fri, 16 Apr 2021 16:56:57 +0800
Subject: [PATCH v2] serial: stm32: optimize spin lock usage
In-Reply-To: <YHlMYZCCxL+SS9ye@hovoldconsulting.com>
References: <1618219898-4600-1-git-send-email-dillon.minfei@gmail.com>
 <YHRGPpQ03XgBMkiy@hovoldconsulting.com>
 <CAL9mu0JF-9hy3Z_ytpEO+hzKh0D+f-0gYaUBEA0v28EOHpC80w@mail.gmail.com>
 <CAL9mu0Ke97FUZ03jvdH8Lz2qRnVY82B7tAEtjbhW97sPOVkAxQ@mail.gmail.com>
 <YHlMYZCCxL+SS9ye@hovoldconsulting.com>
Message-ID: <CAL9mu0K4L-vGL1EyYc+p0q7tadQ39-VHcp1nd4gZs_HGKSmP2w@mail.gmail.com>

Hi Johan,

On Fri, Apr 16, 2021 at 4:35 PM Johan Hovold <johan at kernel.org> wrote:
>
> On Tue, Apr 13, 2021 at 07:44:39AM +0800, dillon min wrote:
> > Hi Johan, Erwan
> >
> > It seems still a bit of a problem in the current version, not deadlock
> > but access register at the same time.
> >
> > For driver , we should consider it running under smp, let's think
> > about it for this case:
> >
> > static void stm32_usart_console_write(struct console *co, const char *s,
> >                                       unsigned int cnt)
> > {
> >          .....
> >          local_irq_save(flags);
> >          if (port->sysrq)
> >                     locked = 0;
> >          .....
> >          access register cr1, tdr, isr
> >          .....
> >
> >          local_irq_restore(flags);
> > }
> >
> > if port->sysrq is 1, stm32_usart_console_write() just disable local
> > irq response by local_irq_save(), at the time of access register cr1,
> > tdr, isr. an TXE interrupt raised, for other cores(I know stm32
> > mpu/mcu do not have multi cores, just assume it has), it still has a
> > chance to handle interrupt.  Then there is no lock to protect the uart
> > register.
>
> Right, the sysrq handling is a bit of a hack.
>
> > changes to below, should be more safe:
> >
> > .....
> > if (port->sysrq || oops_in_progress)
> >       locked = spin_trylock_irqsave(&port->lock, flags);
>
> Except that the lock debugging code would detect the attempt at
> recursive locking here and complain loudly on UP.
>
> If you really want to fix this, we have uart_unlock_and_check_sysrq()
> which can be used to defer sysrq processing until the interrupt handler
> has released the lock.

Great, uart_unlock_and_check_sysrq() is fit to fix this. you mean make
the flow like below:

    stm32_usart_threaded_interrupt()
      spin_lock(&port->lock);
      uart_unlock_and_check_sysrq(port, flags);
      ...
      uart_prepare_sysrq_char();
          printk();
            stm32_usart_console_write();
              locked = spin_trylock_irqsave(&port->lock); //only
handle oops, normal case

If so, I will submit v3 as you suggested. thanks.

Best regards.
Dillon,
>
> > else
> >       spin_lock_irqsave(&port->lock, flags);
> >
> > ....
> >
> > if (locked)
> >      spin_unlock_irqrestore(&port->lock, flags);
>
> Johan


From zhukeqian1 at huawei.com  Fri Apr 16 10:07:27 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Fri, 16 Apr 2021 17:07:27 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <2c01425f-813c-4278-ba06-26d651496a5c@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
 <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
 <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>
 <88cba608-2f22-eb83-f22e-50cb547b6ee8@huawei.com>
 <2c01425f-813c-4278-ba06-26d651496a5c@linux.intel.com>
Message-ID: <64c87f67-3687-61bd-1587-724cc2f9cc97@huawei.com>

Hi Baolu,

On 2021/4/15 18:21, Lu Baolu wrote:
> Hi,
> 
> On 2021/4/15 15:43, Keqian Zhu wrote:
>>>> design it as not switchable. I will modify the commit message of patch#12, thanks!
>>> I am not sure that I fully get your point. But I can't see any gaps of
>>> using iommu_dev_enable/disable_feature() to switch dirty log on and off.
>>> Probably I missed anything.
>> IOMMU_DEV_FEAT_HWDBM just tells user whether underlying IOMMU driver supports
>> dirty tracking, it is not used to management the status of dirty log tracking.
>>
>> The feature reporting is per device, but the status management is per iommu_domain.
>> Only when all devices in a domain support HWDBM, we can start dirty log for the domain.
> 
> So why not
> 
>     for_each_device_attached_domain()
>         iommu_dev_enable_feature(IOMMU_DEV_FEAT_HWDBM)
Looks reasonable, but the problem is that we just need to enable dirty log once per domain.

> 
> ?
>>
>> And I think we'd better not mix the feature reporting and status management. Thoughts?
>>
> 
> I am worrying about having two sets of APIs for single purpose. From
> vendor iommu driver's point of view, this feature is per device. Hence,
> it still needs to do the same thing.
Yes, we can unify the granule of feature reporting and status management.

The basic granule of dirty tracking is iommu_domain, I think it's very reasonable. We need an
interface to report the feature of iommu_domain, then the logic is much more clear.

Every time we add new device or remove device from the domain, we should update the feature (e.g.,
maintain a counter of unsupported devices).

What do you think about this idea?

Thanks,
Keqian


From adrian.hunter at intel.com  Fri Apr 16 10:22:52 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 16 Apr 2021 12:22:52 +0300
Subject: [PATCH v19 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org>
References: <cover.1618529652.git.asutoshd@codeaurora.org>
 <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org>
Message-ID: <d28cb2d4-8f24-c2c4-e87e-bb51ac73af6e@intel.com>

On 16/04/21 2:36 am, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes.
> This also registers a new scsi driver for rpmb wlun.
> This new driver is mostly used to clear rpmb uac.
> With this design, the driver would always be runtime resumed
> before system suspend.

I thought some more about that and I think we can still support
allowing runtime suspend to work with system suspend, without
too much difficulty. See ufshcd_suspend_prepare() below.

> 
> Fixed smatch warnings:
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

<SNIP>

> -static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
> +static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  {
>  	int ret;
> -	enum uic_link_state old_link_state;
> +	enum uic_link_state old_link_state = hba->uic_link_state;
>  
> -	hba->pm_op_in_progress = 1;
> -	old_link_state = hba->uic_link_state;
> -
> -	ufshcd_hba_vreg_set_hpm(hba);
> -	ret = ufshcd_vreg_set_hpm(hba);
> -	if (ret)
> -		goto out;
> -
> -	/* Make sure clocks are enabled before accessing controller */
> -	ret = ufshcd_setup_clocks(hba, true);
> -	if (ret)
> -		goto disable_vreg;
> -
> -	/* enable the host irq as host controller would be active soon */
> -	ufshcd_enable_irq(hba);
> +	hba->pm_op_in_progress = true;
>  
>  	/*
>  	 * Call vendor specific resume callback. As these callbacks may access
> @@ -8868,7 +8858,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  	 */
>  	ret = ufshcd_vops_resume(hba, pm_op);
>  	if (ret)
> -		goto disable_irq_and_vops_clks;
> +		goto out;
>  
>  	/* For DeepSleep, the only supported option is to have the link off */
>  	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
> @@ -8916,42 +8906,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>  	if (hba->ee_usr_mask)
>  		ufshcd_write_ee_control(hba);
>  
> -	hba->clk_gating.is_suspended = false;
> -
>  	if (ufshcd_is_clkscaling_supported(hba))
> -		ufshcd_clk_scaling_suspend(hba, false);
> -
> -	/* Enable Auto-Hibernate if configured */
> -	ufshcd_auto_hibern8_enable(hba);
> +		ufshcd_resume_clkscaling(hba);

This still doesn't look right. ufshcd_resume_clkscaling()
doesn't update hba->clk_scaling.is_allowed whereas
ufshcd_clk_scaling_suspend() does.

>  
>  	if (hba->dev_info.b_rpm_dev_flush_capable) {
>  		hba->dev_info.b_rpm_dev_flush_capable = false;
>  		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
>  	}
>  
> -	ufshcd_clear_ua_wluns(hba);
> -
> -	/* Schedule clock gating in case of no access to UFS device yet */
> -	ufshcd_release(hba);
> -
> +	/* Enable Auto-Hibernate if configured */
> +	ufshcd_auto_hibern8_enable(hba);
>  	goto out;
>  
>  set_old_link_state:
>  	ufshcd_link_state_transition(hba, old_link_state, 0);
>  vendor_suspend:
>  	ufshcd_vops_suspend(hba, pm_op);
> -disable_irq_and_vops_clks:
> +out:
> +	if (ret)
> +		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
> +	hba->clk_gating.is_suspended = false;
> +	ufshcd_release(hba);
> +	hba->pm_op_in_progress = false;
> +	return ret;
> +}

<SNIP>

> +void ufshcd_resume_complete(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	ufshcd_rpm_put(hba);
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
> +
> +int ufshcd_suspend_prepare(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	/*
> +	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
> +	 * are same. And it doesn't wake up the device for system-suspend
> +	 * if it's runtime suspended. But ufs doesn't follow that.
> +	 * The rpm-lvl and spm-lvl can be different in ufs.
> +	 * Force it to honor system-suspend.
> +	 * Refer ufshcd_resume_complete()
> +	 */
> +	ufshcd_rpm_get_sync(hba);
> +
> +	return 0;
> +}

I think we can support allowing runtime suspend to work with
system suspend.  ufshcd_resume_complete() remains the same,
and ufshcd_suspend_prepare() is like this:


/*
 * SCSI assumes that runtime-pm and system-pm for scsi drivers are same, and it
 * doesn't wake up the device for system-suspend if it's runtime suspended.
 * However UFS doesn't follow that. The rpm-lvl and spm-lvl can be different in
 * UFS, so special care is needed.
 * Refer also ufshcd_resume_complete()
 */
int ufshcd_suspend_prepare(struct device *dev)
{
	struct ufs_hba *hba = dev_get_drvdata(dev);
	struct device *ufs_dev = &hba->sdev_ufs_device->sdev_gendev;
	enum ufs_dev_pwr_mode spm_pwr_mode;
	enum uic_link_state spm_link_state;
	unsigned long flags;
	bool rpm_state_ok;

	/*
	 * First prevent runtime suspend. Note this does not prevent runtime
	 * resume e.g. pm_runtime_get_sync() will still do the right thing.
	 */
	pm_runtime_get_noresume(ufs_dev);

	/* Now check if the rpm state is ok to use for spm */
	spin_lock_irqsave(&ufs_dev->power.lock, flags);

	spm_pwr_mode = ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl);
	spm_link_state = ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl);

	rpm_state_ok = pm_runtime_suspended(ufs_dev) &&
		       hba->curr_dev_pwr_mode == spm_pwr_mode &&
		       hba->uic_link_state == spm_link_state &&
		       !hba->dev_info.b_rpm_dev_flush_capable;

	spin_unlock_irqrestore(&ufs_dev->power.lock, flags);

	/* If is isn't, do a runtime resume */
	if (!rpm_state_ok)
		pm_runtime_resume(ufs_dev);

	return 0;
}



From grygorii.strashko at ti.com  Fri Apr 16 10:26:44 2021
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 16 Apr 2021 12:26:44 +0300
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
 <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
Message-ID: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>

Hi Ilias, All,

On 10/04/2021 11:52, Ilias Apalodimas wrote:
> +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> 
> Thanks for catching this. Interesting indeed...
> 
> On Sat, 10 Apr 2021 at 09:22, Jesper Dangaard Brouer <brouer at redhat.com> wrote:
>>
>> On Sat, 10 Apr 2021 03:43:13 +0100
>> Matthew Wilcox <willy at infradead.org> wrote:
>>
>>> On Sat, Apr 10, 2021 at 06:45:35AM +0800, kernel test robot wrote:
>>>>>> include/linux/mm_types.h:274:1: error: static_assert failed due to requirement '__builtin_offsetof(struct page, lru) == __builtin_offsetof(struct folio, lru)' "offsetof(struct page, lru) == offsetof(struct folio, lru)"
>>>>     FOLIO_MATCH(lru, lru);
>>>>     include/linux/mm_types.h:272:2: note: expanded from macro 'FOLIO_MATCH'
>>>>             static_assert(offsetof(struct page, pg) == offsetof(struct folio, fl))
>>>
>>> Well, this is interesting.  pahole reports:
>>>
>>> struct page {
>>>          long unsigned int          flags;                /*     0     4 */
>>>          /* XXX 4 bytes hole, try to pack */
>>>          union {
>>>                  struct {
>>>                          struct list_head lru;            /*     8     8 */
>>> ...
>>> struct folio {
>>>          union {
>>>                  struct {
>>>                          long unsigned int flags;         /*     0     4 */
>>>                          struct list_head lru;            /*     4     8 */
>>>
>>> so this assert has absolutely done its job.
>>>
>>> But why has this assert triggered?  Why is struct page layout not what
>>> we thought it was?  Turns out it's the dma_addr added in 2019 by commit
>>> c25fff7171be ("mm: add dma_addr_t to struct page").  On this particular
>>> config, it's 64-bit, and ppc32 requires alignment to 64-bit.  So
>>> the whole union gets moved out by 4 bytes.
>>
>> Argh, good that you are catching this!
>>
>>> Unfortunately, we can't just fix this by putting an 'unsigned long pad'
>>> in front of it.  It still aligns the entire union to 8 bytes, and then
>>> it skips another 4 bytes after the pad.
>>>
>>> We can fix it like this ...
>>>
>>> +++ b/include/linux/mm_types.h
>>> @@ -96,11 +96,12 @@ struct page {
>>>                          unsigned long private;
>>>                  };
>>>                  struct {        /* page_pool used by netstack */
>>> +                       unsigned long _page_pool_pad;
>>
>> I'm fine with this pad.  Matteo is currently proposing[1] to add a 32-bit
>> value after @dma_addr, and he could use this area instead.
>>
>> [1] https://lore.kernel.org/netdev/20210409223801.104657-3-mcroce at linux.microsoft.com/
>>
>> When adding/changing this, we need to make sure that it doesn't overlap
>> member @index, because network stack use/check page_is_pfmemalloc().
>> As far as my calculations this is safe to add.  I always try to keep an
>> eye out for this, but I wonder if we could have a build check like yours.
>>
>>
>>>                          /**
>>>                           * @dma_addr: might require a 64-bit value even on
>>>                           * 32-bit architectures.
>>>                           */
>>> -                       dma_addr_t dma_addr;
>>> +                       dma_addr_t dma_addr __packed;
>>>                  };
>>>                  struct {        /* slab, slob and slub */
>>>                          union {
>>>
>>> but I don't know if GCC is smart enough to realise that dma_addr is now
>>> on an 8 byte boundary and it can use a normal instruction to access it,
>>> or whether it'll do something daft like use byte loads to access it.
>>>
>>> We could also do:
>>>
>>> +                       dma_addr_t dma_addr __packed __aligned(sizeof(void *));
>>>
>>> and I see pahole, at least sees this correctly:
>>>
>>>                  struct {
>>>                          long unsigned int _page_pool_pad; /*     4     4 */
>>>                          dma_addr_t dma_addr __attribute__((__aligned__(4))); /*     8     8 */
>>>                  } __attribute__((__packed__)) __attribute__((__aligned__(4)));
>>>
>>> This presumably affects any 32-bit architecture with a 64-bit phys_addr_t
>>> / dma_addr_t.  Advice, please?
>>
>> I'm not sure that the 32-bit behavior is with 64-bit (dma) addrs.
>>
>> I don't have any 32-bit boards with 64-bit DMA.  Cc. Ivan, wasn't your
>> board (572x ?) 32-bit with driver 'cpsw' this case (where Ivan added
>> XDP+page_pool) ?

Sry, for delayed reply.

The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
optimizations and unification.
(just checked - not set in 4.14)

Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").

The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using things like (__force u32)
for example.

Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.

-- 
Best regards,
grygorii


From narmstrong at baylibre.com  Fri Apr 16 10:27:35 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 11:27:35 +0200
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
Message-ID: <20210416092737.1971876-1-narmstrong@baylibre.com>

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Jernej Skrabec (1):
  drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
    driver

Neil Armstrong (1):
  drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
 include/drm/bridge/dw_hdmi.h              | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.25.1



From narmstrong at baylibre.com  Fri Apr 16 10:27:36 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 11:27:36 +0200
Subject: [PATCH 1/2] drm/bridge/synopsys: dw-hdmi: Add an option to suppress
 loading CEC driver
In-Reply-To: <20210416092737.1971876-1-narmstrong@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
Message-ID: <20210416092737.1971876-2-narmstrong@baylibre.com>

From: Jernej Skrabec <jernej.skrabec at siol.net>

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.

On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
confusion when the DW-HDMI CEC controller can't communicate on the bus.

Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec at siol.net>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
 include/drm/bridge/dw_hdmi.h              | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index dda4fa9a1a08..ae97513ef886 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3421,7 +3421,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
 		hdmi->audio = platform_device_register_full(&pdevinfo);
 	}
 
-	if (config0 & HDMI_CONFIG0_CEC) {
+	if (!plat_data->disable_cec && (config0 & HDMI_CONFIG0_CEC)) {
 		cec.hdmi = hdmi;
 		cec.ops = &dw_hdmi_cec_ops;
 		cec.irq = irq;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ea34ca146b82..6a5716655619 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -153,6 +153,8 @@ struct dw_hdmi_plat_data {
 	const struct dw_hdmi_phy_config *phy_config;
 	int (*configure_phy)(struct dw_hdmi *hdmi, void *data,
 			     unsigned long mpixelclock);
+
+	unsigned int disable_cec : 1;
 };
 
 struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
-- 
2.25.1



From narmstrong at baylibre.com  Fri Apr 16 10:27:37 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 11:27:37 +0200
Subject: [PATCH 2/2] drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
In-Reply-To: <20210416092737.1971876-1-narmstrong@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
Message-ID: <20210416092737.1971876-3-narmstrong@baylibre.com>

On the Amlogic SoCs, the DW-HDMI HW support is here but the DW-HDMI CEC signal
is not connected to a physical pin, leading to confusion when the dw-hdmi cec
controller can't communicate on the bus.

Disable it to avoid exposing a non-functinal bus.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index aad75a22dc33..2ed87cfdd735 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -1103,6 +1103,7 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master,
 	dw_plat_data->phy_data = meson_dw_hdmi;
 	dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709;
 	dw_plat_data->ycbcr_420_allowed = true;
+	dw_plat_data->disable_cec = true;
 
 	if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
 	    dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
-- 
2.25.1



From steven.price at arm.com  Fri Apr 16 10:28:56 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 10:28:56 +0100
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
Message-ID: <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>

On 15/04/2021 18:18, Christophe Leroy wrote:
> In order to support large pages on powerpc, notepage()
> needs to know the page size of the page.
> 
> Add a page_size argument to notepage().
> 
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
>   arch/arm64/mm/ptdump.c         |  2 +-
>   arch/riscv/mm/ptdump.c         |  2 +-
>   arch/s390/mm/dump_pagetables.c |  3 ++-
>   arch/x86/mm/dump_pagetables.c  |  2 +-
>   include/linux/ptdump.h         |  2 +-
>   mm/ptdump.c                    | 16 ++++++++--------
>   6 files changed, 14 insertions(+), 13 deletions(-)
>
[...]
> diff --git a/mm/ptdump.c b/mm/ptdump.c
> index da751448d0e4..61cd16afb1c8 100644
> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
>   {
>   	struct ptdump_state *st = walk->private;
>   
> -	st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
> +	st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), PAGE_SIZE);

I'm not completely sure what the page_size is going to be used for, but 
note that KASAN presents an interesting case here. We short-cut by 
detecting it's a KASAN region at a high level (PGD/P4D/PUD/PMD) and 
instead of walking the tree down just call note_page() *once* but with 
level==4 because we know KASAN sets up the page table like that.

However the one call actually covers a much larger region - so while 
PAGE_SIZE matches the level it doesn't match the region covered. AFAICT 
this will lead to odd results if you enable KASAN on powerpc.

To be honest I don't fully understand why powerpc requires the page_size 
- it appears to be using it purely to find "holes" in the calls to 
note_page(), but I haven't worked out why such holes would occur.

Steve

>   
>   	walk->action = ACTION_CONTINUE;
>   
> @@ -41,7 +41,7 @@ static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr,
>   		st->effective_prot(st, 0, pgd_val(val));
>   
>   	if (pgd_leaf(val))
> -		st->note_page(st, addr, 0, pgd_val(val));
> +		st->note_page(st, addr, 0, pgd_val(val), PGDIR_SIZE);
>   
>   	return 0;
>   }
> @@ -62,7 +62,7 @@ static int ptdump_p4d_entry(p4d_t *p4d, unsigned long addr,
>   		st->effective_prot(st, 1, p4d_val(val));
>   
>   	if (p4d_leaf(val))
> -		st->note_page(st, addr, 1, p4d_val(val));
> +		st->note_page(st, addr, 1, p4d_val(val), P4D_SIZE);
>   
>   	return 0;
>   }
> @@ -83,7 +83,7 @@ static int ptdump_pud_entry(pud_t *pud, unsigned long addr,
>   		st->effective_prot(st, 2, pud_val(val));
>   
>   	if (pud_leaf(val))
> -		st->note_page(st, addr, 2, pud_val(val));
> +		st->note_page(st, addr, 2, pud_val(val), PUD_SIZE);
>   
>   	return 0;
>   }
> @@ -102,7 +102,7 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr,
>   	if (st->effective_prot)
>   		st->effective_prot(st, 3, pmd_val(val));
>   	if (pmd_leaf(val))
> -		st->note_page(st, addr, 3, pmd_val(val));
> +		st->note_page(st, addr, 3, pmd_val(val), PMD_SIZE);
>   
>   	return 0;
>   }
> @@ -116,7 +116,7 @@ static int ptdump_pte_entry(pte_t *pte, unsigned long addr,
>   	if (st->effective_prot)
>   		st->effective_prot(st, 4, pte_val(val));
>   
> -	st->note_page(st, addr, 4, pte_val(val));
> +	st->note_page(st, addr, 4, pte_val(val), PAGE_SIZE);
>   
>   	return 0;
>   }
> @@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long next,
>   {
>   	struct ptdump_state *st = walk->private;
>   
> -	st->note_page(st, addr, depth, 0);
> +	st->note_page(st, addr, depth, 0, 0);
>   
>   	return 0;
>   }
> @@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>   	mmap_read_unlock(mm);
>   
>   	/* Flush out the last page */
> -	st->note_page(st, 0, -1, 0);
> +	st->note_page(st, 0, -1, 0, 0);
>   }
> 



From valentin.schneider at arm.com  Fri Apr 16 10:32:35 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Fri, 16 Apr 2021 10:32:35 +0100
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
Message-ID: <87wnt2lglo.mognet@arm.com>

On 16/04/21 15:47, Ruifeng Zhang wrote:
> For more requirements, if all cores in one physical cluster, the
> {aff2} of all cores are the same value.
> i.e. the sc9863a,
> core0: 0000000081000000
> core1: 0000000081000100
> core2: 0000000081000200
> core3: 0000000081000300
> core4: 0000000081000400
> core5: 0000000081000500
> core6: 0000000081000600
> core7: 0000000081000700
>
> According to MPIDR all cores will parse to the one cluster, but it's
> the big.LITTLE system, it's need two logic cluster for schedule or
> cpufreq.
> So I think it's better to add the logic of parse topology from DT.

Ah, so it's a slightly different issue, but still one that requires a
different means of specifying topology.


From narmstrong at baylibre.com  Fri Apr 16 10:33:34 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 11:33:34 +0200
Subject: [PATCH] mmc: meson-gx: remove useless warning about scatterlist
 size alignment in block mode
In-Reply-To: <CAPDyKFpNLu3R+7ODZaC7yWMYbSOujswgLTkN97FQNg5zhwSxgw@mail.gmail.com>
References: <20210414100010.3877669-1-narmstrong@baylibre.com>
 <CAPDyKFpNLu3R+7ODZaC7yWMYbSOujswgLTkN97FQNg5zhwSxgw@mail.gmail.com>
Message-ID: <ff1d8605-4f45-c272-9bd6-e55ea8a9c68c@baylibre.com>

On 15/04/2021 11:07, Ulf Hansson wrote:
> On Wed, 14 Apr 2021 at 12:00, Neil Armstrong <narmstrong at baylibre.com> wrote:
>>
>> Since commit e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode"),
>> support for SDIO SD_IO_RW_EXTENDED transferts are properly filtered but some driver
>> like brcmfmac still gives a block sg buffer size not aligned with SDIO block,
>> triggerring a warning even if the transfer works in degraded mode.
>>
>> This should be ultimately fixed in brcmfmac, but since it's only a performance issue
>> the warning should be removed.
>>
>> Fixes: e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode")
>> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
>> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
>> ---
>>  drivers/mmc/host/meson-gx-mmc.c | 5 +----
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
>> index eb6c02bc4a02..6bc151045843 100644
>> --- a/drivers/mmc/host/meson-gx-mmc.c
>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>> @@ -246,11 +246,8 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>>                  * size, otherwise chain mode could not be used.
>>                  */
>>                 for_each_sg(data->sg, sg, data->sg_len, i) {
>> -                       if (sg->length % data->blksz) {
>> -                               WARN_ONCE(1, "unaligned sg len %u blksize %u\n",
>> -                                         sg->length, data->blksz);
> 
> Rather than removing this warning, perhaps an option could be to use
> dev_warn_once() instead?


Yep, I'll re-spin.

Neil

> 
>> +                       if (sg->length % data->blksz)
>>                                 return;
>> -                       }
>>                 }
>>         }
>>
> 
> Kind regards
> Uffe
> 



From oleg at redhat.com  Fri Apr 16 10:43:25 2021
From: oleg at redhat.com (Oleg Nesterov)
Date: Fri, 16 Apr 2021 11:43:25 +0200
Subject: [PATCH 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210416075533.7720-2-zhe.he@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416075533.7720-2-zhe.he@windriver.com>
Message-ID: <20210416094324.GA1962@redhat.com>

On 04/16, He Zhe wrote:
>
> --- a/arch/arm64/include/asm/syscall.h
> +++ b/arch/arm64/include/asm/syscall.h
> @@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct *task,
>  static inline long syscall_get_return_value(struct task_struct *task,
>  					    struct pt_regs *regs)
>  {
> -	return regs->regs[0];
> +	long val = regs->regs[0];
> +
> +	if (is_compat_thread(task_thread_info(task)))
> +		val = sign_extend64(val, 31);
> +
> +	return val;
>  }

I can't really review these arm-specific patches, but with this change both
syscall_get_error() and is_syscall_success() can use syscall_get_return_value()
to avoid the code duplication.

Oleg.



From narmstrong at baylibre.com  Fri Apr 16 10:43:47 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 11:43:47 +0200
Subject: [PATCH v2] mmc: meson-gx: replace WARN_ONCE with dev_warn_once about
 scatterlist size alignment in block mode
Message-ID: <20210416094347.2015896-1-narmstrong@baylibre.com>

Since commit e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode"),
support for SDIO SD_IO_RW_EXTENDED transferts are properly filtered but some driver
like brcmfmac still gives a block sg buffer size not aligned with SDIO block,
triggerring a WARN_ONCE() with scary stacktrace even if the transfer works fine
but with possible degraded performances.

Simply replace with dev_warn_once() to inform user this should be fixed to avoid
degraded performance.

This should be ultimately fixed in brcmfmac, but since it's only a performance issue
the warning should be removed.

Fixes: e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode")
Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
Changes since v1:
- replace WARN_ONCE with dev_warn_once and explicit the warning message

 drivers/mmc/host/meson-gx-mmc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index eb6c02bc4a02..b8b771b643cc 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -247,8 +247,9 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
 		 */
 		for_each_sg(data->sg, sg, data->sg_len, i) {
 			if (sg->length % data->blksz) {
-				WARN_ONCE(1, "unaligned sg len %u blksize %u\n",
-					  sg->length, data->blksz);
+				dev_warn_once(mmc_dev(mmc),
+					      "unaligned sg len %u blksize %u, disabling descriptor DMA for transfer\n",
+					      sg->length, data->blksz);
 				return;
 			}
 		}
-- 
2.25.1



From u.kleine-koenig at pengutronix.de  Fri Apr 16 10:44:26 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 16 Apr 2021 11:44:26 +0200
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
 <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
 <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>
Message-ID: <20210416094426.x4gyw3drp2fcwczs@pengutronix.de>

Hello Nobuhiro,

On Fri, Apr 16, 2021 at 05:07:21PM +0900, Nobuhiro Iwamatsu wrote:
> On Mon, Apr 12, 2021 at 09:02:32AM +0200, Uwe Kleine-K?nig wrote:
> > On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> > > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K?nig wrote:
> > > > Can you please put a paragraph analogous to the one in pwm-sifive in the
> > > > same format. This simplified keeping an overview about the oddities of
> > > > the various supported chips.
> > > 
> > > OK, I will check pwm-sifive's, and add.
> 
> I will add the following :
> 
>  * Limitations:
>  * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8) for the input
>  *   clock running at 1 MHz.

I would strip that to:

 - Fixed input clock running at 1 MHz

>  * - When the settings of the PWM are modified, the new values are shadowed
>  *   in hardware until the PIPGM_PCSR register is written and the currently
>  *   running period is completed. This way the hardware switches atomically
>  *   from the old setting to the new.
>  * - Disabling the hardware completes the currently running period and keeps
>  *   the output at low level at all times.

This looks fine.
 
> > For me the critical (and only) difference between "off" and
> > "duty cycle = 0" is that when a new configuration is to be applied. In
> > the "off" state a new period can (and should) start immediately, while
> > with "duty_cycle = 0" the rising edge should be delayed until the
> > currently running period is over.[1]
> > 
> > So the thing to do here (IMHO) is:
> > 
> > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
> > with writing a non-zero value to PIPGM_PCSR) completes the currently
> > running period, then always assume the PWM as enabled.
> 
> Yes, this device works that way.

OK, then please use

	state->enabled = true

unconditionally in visconti_pwm_get_state().

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/20210416/e6a7b067/attachment-0001.sig>

From james.clark at arm.com  Fri Apr 16 10:55:42 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 12:55:42 +0300
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210415143329.GC1011890@leoy-ThinkPad-X240s>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com>
 <06e1cc2e-1108-81cd-59e4-79277807b80c@arm.com>
 <20210415123953.GB1011890@leoy-ThinkPad-X240s>
 <4c173b86-b045-0514-b293-c39cc74d353d@arm.com>
 <20210415143329.GC1011890@leoy-ThinkPad-X240s>
Message-ID: <476662dd-eddb-e537-9940-6bc5b3293d2b@arm.com>



On 15/04/2021 17:33, Leo Yan wrote:
> Hi James,
> 
> On Thu, Apr 15, 2021 at 03:51:46PM +0300, James Clark wrote:
> 
> [...]
> 
>>> For the orignal perf data file with "--per-thread" option, the decoder
>>> runs into the condition for "etm->timeless_decoding"; and it doesn't
>>> contain ETM timestamp.
>>>
>>> Afterwards, the injected perf data file also misses ETM timestamp and
>>> hit the condition "etm->timeless_decoding".
>>>
>>> So I am confusing why the original perf data can be processed properly
>>> but fails to handle the injected perf data file.
>>
>> Hi Leo,
>>
>> My patch only deals with per-cpu mode. With per-thread mode everything is already working
>> because _none_ of the events have timestamps because they are not enabled by default:
>>
>> 	/* In per-cpu case, always need the time of mmap events etc */
>> 	if (!perf_cpu_map__empty(cpus))
>> 		evsel__set_sample_bit(tracking_evsel, TIME);
>>
>> When none of the events have timestamps, I think perf doesn't use the ordering code in
>> ordered-events.c. So when the inject file is opened, the events are read in file order.
> 
> The explination makes sense to me.  One thinking: if the original file
> doesn't use the ordered event, is it possible for the injected file to
> not use the ordered event as well?

Yes if you inject on a file with no timestamps and then open it, then the function queue_event()
in ordered_events.c is not hit.

If you create a file based on one with timestamps, then the queue_event() function is hit
even on the injected file.

The relevant bit of code is here:

	if (tool->ordered_events) {
		u64 timestamp = -1ULL;

		ret = evlist__parse_sample_timestamp(evlist, event, &timestamp);
		if (ret && ret != -1)
			return ret;

		ret = perf_session__queue_event(session, event, timestamp, file_offset);
		if (ret != -ETIME)
			return ret;
	}

	return perf_session__deliver_event(session, event, tool, file_offset);

If tool->ordered_events is set AND the timestamp for the sample parses to be non zero
and non -1:

	if (!timestamp || timestamp == ~0ULL)
		return -ETIME;

Then the event is added into the queue, otherwise it goes straight through to perf_session__deliver_event()
The ordering can be disabled manually with tool->ordered_events and --disable-order and is also disabled
with --dump-raw-trace.

It seems like processing the file only really works when all events are unordered but in the right order,
or ordered with the right timestamps set.

> 
> Could you confirm Intel-pt can work well for per-cpu mode for inject
> file?

Yes it seems like synthesised samples are assigned sensible timestamps.

	perf record -e intel_pt//u top
	perf inject -i perf.data -o perf-intel-per-cpu.inject.data --itrace=i100i --strip
	perf report -i perf-intel-per-cpu.inject.data -D

Results in the correct binary and DSO names and the SAMPLE timestamp is after the COMM:

	0 381165621595220 0x1200 [0x38]: PERF_RECORD_COMM exec: top:20173/20173
	
	...
	
	2 381165622169297 0x13b0 [0x38]: PERF_RECORD_SAMPLE(IP, 0x2): 20173/20173: 0x7fdaa14abf53 period: 100 addr: 0
 	... thread: top:20173
 	...... dso: /lib/x86_64-linux-gnu/ld-2.27.so

Per-thread also works, but no samples or events have timestamps.

> 
>> So it's not really about --per-thread vs per-cpu mode, it's actually about whether
>> PERF_SAMPLE_TIME is set, which is set as a by-product of per-cpu mode.
>>
>> I hope I understood your question properly.
> 
> Thanks for info, sorry if I miss any info you have elaborated.
> 
> Leo
> 


From laurent.pinchart at ideasonboard.com  Fri Apr 16 10:58:00 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 16 Apr 2021 12:58:00 +0300
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <20210416092737.1971876-1-narmstrong@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
Message-ID: <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>

Hi Neil,

On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
> 
> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
> confusion when the DW-HDMI CEC controller can't communicate on the bus.

If we can't trust the CEC config bit, would it be better to not use it
at all, and instead let each platform glue logic tell whether to enable
CEC or not ?

> Jernej Skrabec (1):
>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>     driver
> 
> Neil Armstrong (1):
>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
> 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
>  include/drm/bridge/dw_hdmi.h              | 2 ++
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 

-- 
Regards,

Laurent Pinchart


From adrian.hunter at intel.com  Fri Apr 16 11:08:31 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 16 Apr 2021 13:08:31 +0300
Subject: [PATCH v19 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <d28cb2d4-8f24-c2c4-e87e-bb51ac73af6e@intel.com>
References: <cover.1618529652.git.asutoshd@codeaurora.org>
 <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org>
 <d28cb2d4-8f24-c2c4-e87e-bb51ac73af6e@intel.com>
Message-ID: <9ea33def-e2c0-7899-5d47-f9ade59a0dcd@intel.com>

On 16/04/21 12:22 pm, Adrian Hunter wrote:
> On 16/04/21 2:36 am, Asutosh Das wrote:
>> During runtime-suspend of ufs host, the scsi devices are
>> already suspended and so are the queues associated with them.
>> But the ufs host sends SSU (START_STOP_UNIT) to wlun
>> during its runtime-suspend.
>> During the process blk_queue_enter checks if the queue is not in
>> suspended state. If so, it waits for the queue to resume, and never
>> comes out of it.
>> The commit
>> (d55d15a33: scsi: block: Do not accept any requests while suspended)
>> adds the check if the queue is in suspended state in blk_queue_enter().
>>
>> Call trace:
>>  __switch_to+0x174/0x2c4
>>  __schedule+0x478/0x764
>>  schedule+0x9c/0xe0
>>  blk_queue_enter+0x158/0x228
>>  blk_mq_alloc_request+0x40/0xa4
>>  blk_get_request+0x2c/0x70
>>  __scsi_execute+0x60/0x1c4
>>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>>  ufshcd_suspend+0x208/0x83c
>>  ufshcd_runtime_suspend+0x40/0x154
>>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>>  pm_generic_runtime_suspend+0x28/0x3c
>>  __rpm_callback+0x80/0x2a4
>>  rpm_suspend+0x308/0x614
>>  rpm_idle+0x158/0x228
>>  pm_runtime_work+0x84/0xac
>>  process_one_work+0x1f0/0x470
>>  worker_thread+0x26c/0x4c8
>>  kthread+0x13c/0x320
>>  ret_from_fork+0x10/0x18
>>
>> Fix this by registering ufs device wlun as a scsi driver and
>> registering it for block runtime-pm. Also make this as a
>> supplier for all other luns. That way, this device wlun
>> suspends after all the consumers and resumes after
>> hba resumes.
>> This also registers a new scsi driver for rpmb wlun.
>> This new driver is mostly used to clear rpmb uac.
>> With this design, the driver would always be runtime resumed
>> before system suspend.
> 
> I thought some more about that and I think we can still support
> allowing runtime suspend to work with system suspend, without
> too much difficulty. See ufshcd_suspend_prepare() below.
> 
>>
>> Fixed smatch warnings:
>> Reported-by: kernel test robot <lkp at intel.com>
>> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
>>
>> Co-developed-by: Can Guo <cang at codeaurora.org>
>> Signed-off-by: Can Guo <cang at codeaurora.org>
>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>> ---
> 
> <SNIP>
> 
>> -static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>> +static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>>  {
>>  	int ret;
>> -	enum uic_link_state old_link_state;
>> +	enum uic_link_state old_link_state = hba->uic_link_state;
>>  
>> -	hba->pm_op_in_progress = 1;
>> -	old_link_state = hba->uic_link_state;
>> -
>> -	ufshcd_hba_vreg_set_hpm(hba);
>> -	ret = ufshcd_vreg_set_hpm(hba);
>> -	if (ret)
>> -		goto out;
>> -
>> -	/* Make sure clocks are enabled before accessing controller */
>> -	ret = ufshcd_setup_clocks(hba, true);
>> -	if (ret)
>> -		goto disable_vreg;
>> -
>> -	/* enable the host irq as host controller would be active soon */
>> -	ufshcd_enable_irq(hba);
>> +	hba->pm_op_in_progress = true;
>>  
>>  	/*
>>  	 * Call vendor specific resume callback. As these callbacks may access
>> @@ -8868,7 +8858,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>>  	 */
>>  	ret = ufshcd_vops_resume(hba, pm_op);
>>  	if (ret)
>> -		goto disable_irq_and_vops_clks;
>> +		goto out;
>>  
>>  	/* For DeepSleep, the only supported option is to have the link off */
>>  	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
>> @@ -8916,42 +8906,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
>>  	if (hba->ee_usr_mask)
>>  		ufshcd_write_ee_control(hba);
>>  
>> -	hba->clk_gating.is_suspended = false;
>> -
>>  	if (ufshcd_is_clkscaling_supported(hba))
>> -		ufshcd_clk_scaling_suspend(hba, false);
>> -
>> -	/* Enable Auto-Hibernate if configured */
>> -	ufshcd_auto_hibern8_enable(hba);
>> +		ufshcd_resume_clkscaling(hba);
> 
> This still doesn't look right. ufshcd_resume_clkscaling()
> doesn't update hba->clk_scaling.is_allowed whereas
> ufshcd_clk_scaling_suspend() does.
> 
>>  
>>  	if (hba->dev_info.b_rpm_dev_flush_capable) {
>>  		hba->dev_info.b_rpm_dev_flush_capable = false;
>>  		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
>>  	}
>>  
>> -	ufshcd_clear_ua_wluns(hba);
>> -
>> -	/* Schedule clock gating in case of no access to UFS device yet */
>> -	ufshcd_release(hba);
>> -
>> +	/* Enable Auto-Hibernate if configured */
>> +	ufshcd_auto_hibern8_enable(hba);
>>  	goto out;
>>  
>>  set_old_link_state:
>>  	ufshcd_link_state_transition(hba, old_link_state, 0);
>>  vendor_suspend:
>>  	ufshcd_vops_suspend(hba, pm_op);
>> -disable_irq_and_vops_clks:
>> +out:
>> +	if (ret)
>> +		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
>> +	hba->clk_gating.is_suspended = false;
>> +	ufshcd_release(hba);
>> +	hba->pm_op_in_progress = false;
>> +	return ret;
>> +}
> 
> <SNIP>
> 
>> +void ufshcd_resume_complete(struct device *dev)
>> +{
>> +	struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +	ufshcd_rpm_put(hba);
>> +}
>> +EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
>> +
>> +int ufshcd_suspend_prepare(struct device *dev)
>> +{
>> +	struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +	/*
>> +	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
>> +	 * are same. And it doesn't wake up the device for system-suspend
>> +	 * if it's runtime suspended. But ufs doesn't follow that.
>> +	 * The rpm-lvl and spm-lvl can be different in ufs.
>> +	 * Force it to honor system-suspend.
>> +	 * Refer ufshcd_resume_complete()
>> +	 */
>> +	ufshcd_rpm_get_sync(hba);
>> +
>> +	return 0;
>> +}
> 
> I think we can support allowing runtime suspend to work with
> system suspend.  ufshcd_resume_complete() remains the same,
> and ufshcd_suspend_prepare() is like this:
> 
> 
> /*
>  * SCSI assumes that runtime-pm and system-pm for scsi drivers are same, and it
>  * doesn't wake up the device for system-suspend if it's runtime suspended.
>  * However UFS doesn't follow that. The rpm-lvl and spm-lvl can be different in
>  * UFS, so special care is needed.
>  * Refer also ufshcd_resume_complete()
>  */
> int ufshcd_suspend_prepare(struct device *dev)
> {
> 	struct ufs_hba *hba = dev_get_drvdata(dev);
> 	struct device *ufs_dev = &hba->sdev_ufs_device->sdev_gendev;
> 	enum ufs_dev_pwr_mode spm_pwr_mode;
> 	enum uic_link_state spm_link_state;
> 	unsigned long flags;
> 	bool rpm_state_ok;
> 
> 	/*
> 	 * First prevent runtime suspend. Note this does not prevent runtime
> 	 * resume e.g. pm_runtime_get_sync() will still do the right thing.
> 	 */
> 	pm_runtime_get_noresume(ufs_dev);
> 
> 	/* Now check if the rpm state is ok to use for spm */
> 	spin_lock_irqsave(&ufs_dev->power.lock, flags);
> 
> 	spm_pwr_mode = ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl);
> 	spm_link_state = ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl);
> 
> 	rpm_state_ok = pm_runtime_suspended(ufs_dev) &&
> 		       hba->curr_dev_pwr_mode == spm_pwr_mode &&
> 		       hba->uic_link_state == spm_link_state &&
> 		       !hba->dev_info.b_rpm_dev_flush_capable;
> 
> 	spin_unlock_irqrestore(&ufs_dev->power.lock, flags);
> 
> 	/* If is isn't, do a runtime resume */
> 	if (!rpm_state_ok)
> 		pm_runtime_resume(ufs_dev);

But we should return an error if runtime resume
fails.

 	if (!rpm_state_ok) {
 		int ret = pm_runtime_resume(ufs_dev);

		if (ret < 0 && ret != EACCES) {
			pm_runtime_put(ufs_dev);
			return ret;
		}
	}

> 
> 	return 0;
> }
> 



From dillon.minfei at gmail.com  Fri Apr 16 11:10:41 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Fri, 16 Apr 2021 18:10:41 +0800
Subject: [PATCH v3] serial: stm32: optimize spin lock usage
Message-ID: <1618567841-18546-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

This patch aims to fix two potential bug:
- no lock to protect uart register in this case

  stm32_usart_threaded_interrupt()
     spin_lock(&port->lock);
     ...
     stm32_usart_receive_chars()
       uart_handle_sysrq_char();
       sysrq_function();
       printk();
         stm32_usart_console_write();
           locked = 0; //since port->sysrq is not zero,
                         no lock to protect forward register
                         access.

- if add spin_trylock_irqsave() to protect uart register for sysrq = 1 case,
  that might got recursive locking under UP.
  So, use uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq()
  move sysrq handler position to irq/thread_d handler, just record
  sysrq_ch in stm32_usart_receive_chars() by uart_prepare_sysrq_char()
  delay the sysrq process to next interrupt handler.

  new flow:

  stm32_usart_threaded_interrupt()/stm32_usart_interrupt()
  spin_lock_irqsave(&port->lock);
  ...
  uart_unlock_and_check_sysrq();
     spin_unlock_irqrestore();
     handle_sysrq(sysrq_ch);
  stm32_usart_threaded_interrupt()//stm32_usart_interrupt() return

Cc: Johan Hovold <johan at kernel.org>
Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Gerald Baeza <gerald.baeza at foss.st.com>
Cc: Erwan Le Ray <erwan.leray at foss.st.com>
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v3: add uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq() to move
    sysrq handler inside interrupt routinei to avoid recursive locking,
    according to Johan Hovold suggestion, thanks.

 drivers/tty/serial/stm32-usart.c | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index b3675cf25a69..981f50ec784e 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -271,7 +271,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
 			}
 		}
 
-		if (uart_handle_sysrq_char(port, c))
+		if (uart_prepare_sysrq_char(port, c))
 			continue;
 		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
 	}
@@ -457,9 +457,10 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
 	struct uart_port *port = ptr;
 	struct stm32_port *stm32_port = to_stm32_port(port);
 	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
+	unsigned long flags;
 	u32 sr;
 
-	spin_lock(&port->lock);
+	spin_lock_irqsave(&port->lock, flags);
 
 	sr = readl_relaxed(port->membase + ofs->isr);
 
@@ -477,7 +478,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
 	if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch))
 		stm32_usart_transmit_chars(port);
 
-	spin_unlock(&port->lock);
+	uart_unlock_and_check_sysrq(port, flags);
 
 	if (stm32_port->rx_ch)
 		return IRQ_WAKE_THREAD;
@@ -489,13 +490,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
 {
 	struct uart_port *port = ptr;
 	struct stm32_port *stm32_port = to_stm32_port(port);
+	unsigned long flags;
 
-	spin_lock(&port->lock);
+	spin_lock_irqsave(&port->lock, flags);
 
 	if (stm32_port->rx_ch)
 		stm32_usart_receive_chars(port, true);
 
-	spin_unlock(&port->lock);
+	uart_unlock_and_check_sysrq(port, flags);
 
 	return IRQ_HANDLED;
 }
@@ -1354,13 +1356,10 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	u32 old_cr1, new_cr1;
 	int locked = 1;
 
-	local_irq_save(flags);
-	if (port->sysrq)
-		locked = 0;
-	else if (oops_in_progress)
-		locked = spin_trylock(&port->lock);
+	if (oops_in_progress)
+		locked = spin_trylock_irqsave(&port->lock, flags);
 	else
-		spin_lock(&port->lock);
+		spin_lock_irqsave(&port->lock, flags);
 
 	/* Save and disable interrupts, enable the transmitter */
 	old_cr1 = readl_relaxed(port->membase + ofs->cr1);
@@ -1374,8 +1373,7 @@ static void stm32_usart_console_write(struct console *co, const char *s,
 	writel_relaxed(old_cr1, port->membase + ofs->cr1);
 
 	if (locked)
-		spin_unlock(&port->lock);
-	local_irq_restore(flags);
+		spin_unlock_irqrestore(&port->lock, flags);
 }
 
 static int stm32_usart_console_setup(struct console *co, char *options)
-- 
2.7.4



From james.clark at arm.com  Fri Apr 16 11:16:36 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 13:16:36 +0300
Subject: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210415195416.GB937505@xps15>
References: <20210414143919.12605-1-james.clark@arm.com>
 <20210414143919.12605-2-james.clark@arm.com> <20210415195416.GB937505@xps15>
Message-ID: <0ca8c095-9165-bcd1-26bc-3e5d2191affb@arm.com>



On 15/04/2021 22:54, Mathieu Poirier wrote:
> On Wed, Apr 14, 2021 at 05:39:19PM +0300, James Clark wrote:
>> The following attribute is set when synthesising samples in
>> timed decoding mode:
>>
>>     attr.sample_type |= PERF_SAMPLE_TIME;
>>
>> This results in new samples that appear to have timestamps but
>> because we don't assign any timestamps to the samples, when the
>> resulting inject file is opened again, the synthesised samples
>> will be on the wrong side of the MMAP or COMM events.
>>
> 
> I understand the problem.  Once again an issue caused by CS and the kernel
> having a different view of time. 
> 
>> For example this results in the samples being associated with
>> the perf binary, rather than the target of the record:
>>
>>     perf record -e cs_etm/@tmc_etr0/u top
>>     perf inject -i perf.data -o perf.inject --itrace=i100il
>>     perf report -i perf.inject
>>
>> Where 'Command' == perf should show as 'top':
>>
>>     # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
>>     # ........  .......  ....................  ......................  ......................  ..................
>>     #
>>         31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -
>>
>> If the perf.data file is opened directly with perf, without the
>> inject step, then this already works correctly because the
>> events are synthesised after the COMM and MMAP events and
>> no second sorting happens. Re-sorting only happens when opening
>> the perf.inject file for the second time so timestamps are
>> needed.
>>
>> Using the timestamp from the AUX record mirrors the current
>> behaviour when opening directly with perf, because the events
>> are generated on the call to cs_etm__process_queues().
>>
>> Signed-off-by: James Clark <james.clark at arm.com>
>> Co-developed-by: Al Grant <al.grant at arm.com>
>> Signed-off-by: Al Grant <al.grant at arm.com>
> 
> Suzuki is correct, your name has to appear after Al's.
> 
>> ---
>>  tools/perf/util/cs-etm.c | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> index c25da2ffa8f3..d0fa9dce47f1 100644
>> --- a/tools/perf/util/cs-etm.c
>> +++ b/tools/perf/util/cs-etm.c
>> @@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
>>  	u8 sample_instructions;
>>  
>>  	int num_cpu;
>> +	u64 latest_kernel_timestamp;
>>  	u32 auxtrace_type;
>>  	u64 branches_sample_type;
>>  	u64 branches_id;
>> @@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
>>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
>>  	event->sample.header.size = sizeof(struct perf_event_header);
>>  
>> +	if (!etm->timeless_decoding)
>> +		sample.time = etm->latest_kernel_timestamp;
>>  	sample.ip = addr;
>>  	sample.pid = tidq->pid;
>>  	sample.tid = tidq->tid;
>> @@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
>>  	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
>>  	event->sample.header.size = sizeof(struct perf_event_header);
>>  
>> +	if (!etm->timeless_decoding)
>> +		sample.time = etm->latest_kernel_timestamp;
>>  	sample.ip = ip;
>>  	sample.pid = tidq->pid;
>>  	sample.tid = tidq->tid;
>> @@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
>>  	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
>>  		return cs_etm__process_switch_cpu_wide(etm, event);
>>  
>> -	if (!etm->timeless_decoding &&
>> -	    event->header.type == PERF_RECORD_AUX)
>> +	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
>> +		etm->latest_kernel_timestamp = sample_kernel_timestamp;
> 
> It will be fun to fix this when 8.4 comes out but for now it's the best we've
> got.
> 

Thanks for the reviews Leo, Mathieu and Suzuki. Yes I think for 8.4 we can also do something
very similar to Leo's "perf arm-spe: Bail out if the trace is later than perf event"
patch where decoding is paused until the other events with later timestamps
have been received. At the moment the CS decoding happens all at once.

I will submit a new set with the fixes and better variable name.

James

> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> 
>>  		return cs_etm__process_queues(etm);
>> +	}
>>  
>>  	return 0;
>>  }
>> -- 
>> 2.28.0
>>


From kristo at kernel.org  Fri Apr 16 11:37:27 2021
From: kristo at kernel.org (Tero Kristo)
Date: Fri, 16 Apr 2021 13:37:27 +0300
Subject: [PATCH 0/4] dt-bindings: soc/arm: Convert pending ti,sci*
 bindings to json format
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <56388707-c8d3-ebdf-77a2-c5a983856b4d@kernel.org>

On 16/04/2021 09:37, Nishanth Menon wrote:
> Hi,
> 
> I understand that the following series belong to various maintainers,
> but, it is a bit better reviewed as a single series for
> cohesiveness.
> 
> There are also dts fixups that this series exposes, which is good, but
> I chose to hold them back for now pending binding review at least. The
> complete series is available in [1] if folks are curious.
> 
> Nishanth Menon (4):
>    dt-bindings: reset: Convert ti,sci-reset to json schema
>    dt-bindings: clock: Convert ti,sci-clk to json schema
>    dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
>    dt-bindings: arm: keystone: Convert ti,sci to json schema

For the whole series:

Reviewed-by: Tero Kristo <kristo at kernel.org>

> 
>   .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
>   .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
>   .../devicetree/bindings/clock/ti,sci-clk.txt  |  36 -----
>   .../devicetree/bindings/clock/ti,sci-clk.yaml |  52 +++++++
>   .../bindings/reset/ti,sci-reset.txt           |  62 ---------
>   .../bindings/reset/ti,sci-reset.yaml          |  51 +++++++
>   .../bindings/soc/ti/sci-pm-domain.txt         |  65 ---------
>   .../bindings/soc/ti/sci-pm-domain.yaml        |  59 ++++++++
>   8 files changed, 291 insertions(+), 249 deletions(-)
>   delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>   create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
>   delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>   create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
>   delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>   create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
>   delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>   create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
> 
> [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci
> 
> Regards,
> Nishanth Menon
> 



From christophe.leroy at csgroup.eu  Fri Apr 16 11:38:18 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 12:38:18 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
Message-ID: <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>



Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
> On 15/04/2021 18:18, Christophe Leroy wrote:
>> In order to support large pages on powerpc, notepage()
>> needs to know the page size of the page.
>>
>> Add a page_size argument to notepage().
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>> ? arch/arm64/mm/ptdump.c???????? |? 2 +-
>> ? arch/riscv/mm/ptdump.c???????? |? 2 +-
>> ? arch/s390/mm/dump_pagetables.c |? 3 ++-
>> ? arch/x86/mm/dump_pagetables.c? |? 2 +-
>> ? include/linux/ptdump.h???????? |? 2 +-
>> ? mm/ptdump.c??????????????????? | 16 ++++++++--------
>> ? 6 files changed, 14 insertions(+), 13 deletions(-)
>>
> [...]
>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>> index da751448d0e4..61cd16afb1c8 100644
>> --- a/mm/ptdump.c
>> +++ b/mm/ptdump.c
>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
>> ? {
>> ????? struct ptdump_state *st = walk->private;
>> -??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
>> +??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), PAGE_SIZE);
> 
> I'm not completely sure what the page_size is going to be used for, but note that KASAN presents an 
> interesting case here. We short-cut by detecting it's a KASAN region at a high level 
> (PGD/P4D/PUD/PMD) and instead of walking the tree down just call note_page() *once* but with 
> level==4 because we know KASAN sets up the page table like that.
> 
> However the one call actually covers a much larger region - so while PAGE_SIZE matches the level it 
> doesn't match the region covered. AFAICT this will lead to odd results if you enable KASAN on powerpc.

Hum .... I successfully tested it with KASAN, I now realise that I tested it with 
CONFIG_KASAN_VMALLOC selected. In this situation, since 
https://github.com/torvalds/linux/commit/af3d0a686 we don't have any common shadow page table anymore.

I'll test again without CONFIG_KASAN_VMALLOC.

> 
> To be honest I don't fully understand why powerpc requires the page_size - it appears to be using it 
> purely to find "holes" in the calls to note_page(), but I haven't worked out why such holes would 
> occur.

I was indeed introduced for KASAN. We have a first commit 
https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is a 
KASAN like stuff.

Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what the 
problem was exactly, something around the use of hugepages for kernel memory, came as part of the 
series 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/


Christophe


From dietmar.eggemann at arm.com  Fri Apr 16 11:39:30 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Fri, 16 Apr 2021 12:39:30 +0200
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <87wnt2lglo.mognet@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com>
Message-ID: <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>

On 16/04/2021 11:32, Valentin Schneider wrote:
> On 16/04/21 15:47, Ruifeng Zhang wrote:
>> For more requirements, if all cores in one physical cluster, the
>> {aff2} of all cores are the same value.
>> i.e. the sc9863a,
>> core0: 0000000081000000
>> core1: 0000000081000100
>> core2: 0000000081000200
>> core3: 0000000081000300
>> core4: 0000000081000400
>> core5: 0000000081000500
>> core6: 0000000081000600
>> core7: 0000000081000700
>>
>> According to MPIDR all cores will parse to the one cluster, but it's
>> the big.LITTLE system, it's need two logic cluster for schedule or
>> cpufreq.
>> So I think it's better to add the logic of parse topology from DT.
> 
> Ah, so it's a slightly different issue, but still one that requires a
> different means of specifying topology.

I'm confused. Do you have the MT bit set to 1 then? So the issue that
the mpidr handling in arm32's store_cpu_topology() is not correct does
not exist?

With DynamIQ you have only *one* cluster, you should also be able to run
your big.LITTLE system with only an MC sched domain.

# cat /proc/schedstat
cpu0 ....
domain0 ff ... <- MC
...

You can introduce a cpu-map to create what we called Phantom Domains in
Android products.

# cat /proc/schedstat

cpu0 ....
domain0 0f ... <- MC
domain1 ff ... < DIE

Is this what you need for your arm32 kernel system? Adding the
possibility to parse cpu-map to create Phantom Domains?


From valentin.schneider at arm.com  Fri Apr 16 11:47:29 2021
From: valentin.schneider at arm.com (Valentin Schneider)
Date: Fri, 16 Apr 2021 11:47:29 +0100
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
Message-ID: <87r1jald4u.mognet@arm.com>

On 16/04/21 12:39, Dietmar Eggemann wrote:
> On 16/04/2021 11:32, Valentin Schneider wrote:
>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>>> For more requirements, if all cores in one physical cluster, the
>>> {aff2} of all cores are the same value.
>>> i.e. the sc9863a,
>>> core0: 0000000081000000
>>> core1: 0000000081000100
>>> core2: 0000000081000200
>>> core3: 0000000081000300
>>> core4: 0000000081000400
>>> core5: 0000000081000500
>>> core6: 0000000081000600
>>> core7: 0000000081000700
>>>
>>> According to MPIDR all cores will parse to the one cluster, but it's
>>> the big.LITTLE system, it's need two logic cluster for schedule or
>>> cpufreq.
>>> So I think it's better to add the logic of parse topology from DT.
>>
>> Ah, so it's a slightly different issue, but still one that requires a
>> different means of specifying topology.
>
> I'm confused. Do you have the MT bit set to 1 then? So the issue that
> the mpidr handling in arm32's store_cpu_topology() is not correct does
> not exist?
>
> With DynamIQ you have only *one* cluster, you should also be able to run
> your big.LITTLE system with only an MC sched domain.
>
> # cat /proc/schedstat
> cpu0 ....
> domain0 ff ... <- MC
> ...
>

You're right, this is actually a DynamIQ system, not a (legacy) big.LITTLE
one, so all CPUs are under the same LLC (the DSU). I probably should have
checked this earlier on, but this is quite obvious from sc9863a.dtsi:

                cpu-map {
                        cluster0 {
                                core0 {
                                        cpu = <&CPU0>;
                                };
                                core1 {
                                        cpu = <&CPU1>;
                                };
                                core2 {
                                        cpu = <&CPU2>;
                                };
                                core3 {
                                        cpu = <&CPU3>;
                                };
                                core4 {
                                        cpu = <&CPU4>;
                                };
                                core5 {
                                        cpu = <&CPU5>;
                                };
                                core6 {
                                        cpu = <&CPU6>;
                                };
                                core7 {
                                        cpu = <&CPU7>;
                                };
                        };
                };

All CPUs are in the same cluster, and the MPIDR values actually match that.

> You can introduce a cpu-map to create what we called Phantom Domains in
> Android products.
>
> # cat /proc/schedstat
>
> cpu0 ....
> domain0 0f ... <- MC
> domain1 ff ... < DIE
>
> Is this what you need for your arm32 kernel system? Adding the
> possibility to parse cpu-map to create Phantom Domains?


From hsinyi at chromium.org  Fri Apr 16 11:47:39 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri, 16 Apr 2021 18:47:39 +0800
Subject: [PATCH] [v4, 1/1] clocksource/drivers/timer-mediatek: optimize
 systimer irq clear flow on shutdown
In-Reply-To: <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>
References: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>
 <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>
Message-ID: <CAJMQK-jyUzAQu_Yi5zJSRREC5fzPvQoTFpSVyKB8YBi1cK2j7g@mail.gmail.com>

On Fri, Apr 9, 2021 at 5:22 PM Fengquan Chen <Fengquan.Chen at mediatek.com> wrote:
>
> mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
> clear any pending systimer irq when shutdown to avoid suspend aborted
> due to timer irq pending
>
> Also as for systimer in mediatek socs, there must be firstly enable
> timer before clear systimer irq
>
> Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer")
> Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>
>

Tested-by: Hsin-Yi Wang <hsinyi at chromium.org>

Tested on a mt8183 device. This patch solves an issue that device
would hang on resume during genpd_resume_noirq:

[  724.342834] mtk-smi-larb 17010000.larb: genpd_resume_noirq+0x0/0xd0
returned 0 after 976593 usecs
[  724.351721] mtk-smi-larb 1a001000.larb: calling
genpd_resume_noirq+0x0/0xd0 @ 6629, parent: soc
[  736.845047] Kernel panic - not syncing: Watchdog detected hard
LOCKUP on cpu 3
[  736.852268] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G        W
  5.10.26 #17
[  736.859743] Hardware name: MediaTek krane sku176 board (DT)
[  736.865309] Call trace:
[  736.867756]  dump_backtrace+0x0/0x1bc
[  736.871415]  show_stack+0x20/0x2c
[  736.874728]  dump_stack+0xc0/0x11c
[  736.878124]  panic+0x174/0x378
[  736.881178]  watchdog_check_hardlockup+0x11c/0x124
[  736.885963]  watchdog_timer_fn+0x70/0x274
<snip>



> ---
>  drivers/clocksource/timer-mediatek.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 9318edc..6461fd3 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -60,9 +60,9 @@
>   * SYST_CON_EN: Clock enable. Shall be set to
>   *   - Start timer countdown.
>   *   - Allow timeout ticks being updated.
> - *   - Allow changing interrupt functions.
> + *   - Allow changing interrupt status,like clear irq pending.
>   *
> - * SYST_CON_IRQ_EN: Set to allow interrupt.
> + * SYST_CON_IRQ_EN: Set to enable interrupt.
>   *
>   * SYST_CON_IRQ_CLR: Set to clear interrupt.
>   */
> @@ -75,6 +75,7 @@
>  static void mtk_syst_ack_irq(struct timer_of *to)
>  {
>         /* Clear and disable interrupt */
> +       writel(SYST_CON_EN, SYST_CON_REG(to));
>         writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
>  }
>
> @@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
>
>  static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
>  {
> +       /* Clear any irq */
> +       mtk_syst_ack_irq(to_timer_of(clkevt));
> +
>         /* Disable timer */
>         writel(0, SYST_CON_REG(to_timer_of(clkevt)));
>
> --
> 1.8.1.1.dirty
>


From tzimmermann at suse.de  Fri Apr 16 11:48:39 2021
From: tzimmermann at suse.de (Thomas Zimmermann)
Date: Fri, 16 Apr 2021 12:48:39 +0200
Subject: [PATCH 1/4] drm/vmwgfx: Make console emulation depend on
 DRM_FBDEV_EMULATION
In-Reply-To: <a7c61e61-cc6f-93db-7d49-2dc666143ab8@suse.de>
References: <20210415110040.23525-1-tzimmermann@suse.de>
 <20210415110040.23525-2-tzimmermann@suse.de>
 <af143092-edd3-91eb-025d-836de1e4a104@vmware.com>
 <a7c61e61-cc6f-93db-7d49-2dc666143ab8@suse.de>
Message-ID: <ea2a739d-f9d4-14c2-4c0c-111b272b5671@suse.de>



Am 15.04.21 um 20:50 schrieb Thomas Zimmermann:
> Hi
> 
> Am 15.04.21 um 20:21 schrieb Zack Rusin:
>> On 4/15/21 7:00 AM, Thomas Zimmermann wrote:
>>> Respect DRM's kconfig setting for fbdev console emulation. If enabled,
>>> it will select all required config options. So remove them from vmwgfx's
>>> Kconfig file.
>>>
>>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>>> ---
>>> ? drivers/gpu/drm/vmwgfx/Kconfig????? |? 7 +------
>>> ? drivers/gpu/drm/vmwgfx/Makefile???? | 
> 4 +++-
>>> ? drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 19 +++++++++++++++++++
>>> ? 3 files changed, 23 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig 
>>> b/drivers/gpu/drm/vmwgfx/Kconfig
>>> index 15acdf2a7c0f..b3a34196935b 100644
>>> --- a/drivers/gpu/drm/vmwgfx/Kconfig
>>> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
>>> @@ -2,12 +2,7 @@
>>> ? config DRM_VMWGFX
>>> ????? tristate "DRM driver for VMware Virtual 
> GPU"
>>> ????? depends on DRM && PCI && X86 && MMU
>>> -??? select FB_DEFERRED_IO
>>> -??? select FB_CFB_FILLRECT
>>> -??? select FB_CFB_COPYAREA
>>> -??? select FB_CFB_IMAGEBLIT
>>> ????? select DRM_TTM
>>> -??? select FB
>>> ????? select MAPPING_DIRTY_HELPERS
>>> ????? # Only needed for the transitional use 
of drm_crtc_init - can 
>>> be removed
>>> ????? # again once vmwgfx sets up the primary 
> plane itself.
>>> @@ -20,7 +15,7 @@ config DRM_VMWGFX
>>> ??????? The compiled module will be 
> called "vmwgfx.ko".
>>> ? config DRM_VMWGFX_FBCON
>>> -??? depends on DRM_VMWGFX && FB
>>> +??? depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
>>> ????? bool "Enable framebuffer console under 
vmwgfx by default"
>>> ????? help
>>> ???????? Choose this option if 
> you are shipping a new vmwgfx
>>> diff --git a/drivers/gpu/drm/vmwgfx/Makefile 
>>> b/drivers/gpu/drm/vmwgfx/Makefile
>>> index 8c02fa5852e7..9f5743013cbb 100644
>>> --- a/drivers/gpu/drm/vmwgfx/Makefile
>>> +++ b/drivers/gpu/drm/vmwgfx/Makefile
>>> @@ -1,6 +1,6 @@
>>> ? # SPDX-License-Identifier: GPL-2.0
>>> ? vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
>>> -??????? vmwgfx_fb.o vmwgfx_ioctl.o 
> vmwgfx_resource.o
>>> vmwgfx_ttm_buffer.o \
>>> +??????? vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
>>> ????????? vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
>>> ????????? vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
>>> ????????? vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
>>> @@ -11,5 +11,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o 
>>> vmwgfx_kms.o vmwgfx_drv.o \
>>> ????????? vmwgfx_validation.o vmwgfx_page_dirty.o 
>>> vmwgfx_streamoutput.o \
>>> ????????? ttm_object.o ttm_lock.o ttm_memory.o
>>> +vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
>>> ? vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
>>> +
>>> ? obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
>>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
>>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> index 7e6518709e14..e7836da190c4 100644
>>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
>>> @@ -1116,10 +1116,29 @@ extern void vmw_generic_waiter_remove(struct 
>>> vmw_private *dev_priv,
>>> ?? * Kernel framebuffer - vmwgfx_fb.c
>>> ?? */
>>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>>> ? int vmw_fb_init(struct vmw_private *vmw_priv);
>>> ? int vmw_fb_close(struct vmw_private *dev_priv);
>>> ? int vmw_fb_off(struct vmw_private *vmw_priv);
>>> ? int vmw_fb_on(struct vmw_private *vmw_priv);
>>> +#else
>>> +static inline int vmw_fb_init(struct vmw_private *vmw_priv)
>>> +{
>>> +??? return 0;
>>> +}
>>> +static inline int vmw_fb_close(struct vmw_private *dev_priv)
>>> +{
>>> +??? return 0;
>>> +}
>>> +static inline int vmw_fb_off(struct vmw_private *vmw_priv)
>>> +{
>>> +??? return 0;
>>> +}
>>> +static inline int vmw_fb_on(struct vmw_private *vmw_priv)
>>> +{
>>> +??? return 0;
>>> +}
>>> +#endif
>>> ? /**
>>> ?? * Kernel modesetting - vmwgfx_kms.c
>>>
>>
>> This changes the behavior a bit, I guess DRM_VMWGFX (or at least 
>> DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve 

>> the old behavior, but that's largely due to the fact that given how 
>> those options were setup we never run without FB set. In general it 
>> should be ok and looks more reasonable than the current setup. I'll try 
> 
>> it out on Monday just in case, but for now:
>>
>> Reviewed-by: Zack Rusin <zackr at vmware.com>
>>
> 
> All other drivers use DRM_FBDEV_EMULATION, so vmwgfx would follow common 
> conventions.
> 
> AFAICT DRM_VMWGFX_FBCON is just the default on/off setting. How about 
> making DRM_VMWGFX_FBCON depend on DRM_FBDEV_EMULATION? Users would be 
> able to enable fbdev emulation in general and, if needed, still pick a 
> separate default on/off for vmwgfx.

Oh, lol. That's already in the patchset.

> 
> Best regards
> Thomas
> 
>> z
> 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 N?rnberg, Germany
(HRB 36809, AG N?rnberg)
Gesch?ftsf?hrer: Felix Imend?rffer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210416/f5a52ed5/attachment.sig>

From steven.price at arm.com  Fri Apr 16 11:51:14 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 11:51:14 +0100
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
Message-ID: <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>

On 16/04/2021 11:38, Christophe Leroy wrote:
> 
> 
> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>> In order to support large pages on powerpc, notepage()
>>> needs to know the page size of the page.
>>>
>>> Add a page_size argument to notepage().
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>>> ---
>>> ? arch/arm64/mm/ptdump.c???????? |? 2 +-
>>> ? arch/riscv/mm/ptdump.c???????? |? 2 +-
>>> ? arch/s390/mm/dump_pagetables.c |? 3 ++-
>>> ? arch/x86/mm/dump_pagetables.c? |? 2 +-
>>> ? include/linux/ptdump.h???????? |? 2 +-
>>> ? mm/ptdump.c??????????????????? | 16 ++++++++--------
>>> ? 6 files changed, 14 insertions(+), 13 deletions(-)
>>>
>> [...]
>>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>>> index da751448d0e4..61cd16afb1c8 100644
>>> --- a/mm/ptdump.c
>>> +++ b/mm/ptdump.c
>>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct 
>>> mm_walk *walk,
>>> ? {
>>> ????? struct ptdump_state *st = walk->private;
>>> -??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
>>> +??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), 
>>> PAGE_SIZE);
>>
>> I'm not completely sure what the page_size is going to be used for, 
>> but note that KASAN presents an interesting case here. We short-cut by 
>> detecting it's a KASAN region at a high level (PGD/P4D/PUD/PMD) and 
>> instead of walking the tree down just call note_page() *once* but with 
>> level==4 because we know KASAN sets up the page table like that.
>>
>> However the one call actually covers a much larger region - so while 
>> PAGE_SIZE matches the level it doesn't match the region covered. 
>> AFAICT this will lead to odd results if you enable KASAN on powerpc.
> 
> Hum .... I successfully tested it with KASAN, I now realise that I 
> tested it with CONFIG_KASAN_VMALLOC selected. In this situation, since 
> https://github.com/torvalds/linux/commit/af3d0a686 we don't have any 
> common shadow page table anymore.
> 
> I'll test again without CONFIG_KASAN_VMALLOC.
> 
>>
>> To be honest I don't fully understand why powerpc requires the 
>> page_size - it appears to be using it purely to find "holes" in the 
>> calls to note_page(), but I haven't worked out why such holes would 
>> occur.
> 
> I was indeed introduced for KASAN. We have a first commit 
> https://github.com/torvalds/linux/commit/cabe8138 which uses page size 
> to detect whether it is a KASAN like stuff.
> 
> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I 
> can't remember what the problem was exactly, something around the use of 
> hugepages for kernel memory, came as part of the series 
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 

Ah, that's useful context. So it looks like powerpc took a different 
route to reducing the KASAN output to x86.

Given the generic ptdump code has handling for KASAN already it should 
be possible to drop that from the powerpc arch code, which I think means 
we don't actually need to provide page size to notepage(). Hopefully 
that means more code to delete ;)

Steve


From l.stach at pengutronix.de  Fri Apr 16 11:54:16 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 16 Apr 2021 12:54:16 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <20210407073534.376722-4-benjamin.gaignard@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
Message-ID: <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>

Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> In order to be able to share the control hardware block between
> VPUs use a syscon instead a ioremap it in the driver.
> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
> phandle is not found look at 'ctrl' reg-name.
> With the method it becomes useless to provide a list of register
> names so remove it.

Sorry for putting a spoke in the wheel after many iterations of the
series.

We just discussed a way forward on how to handle the clocks and resets
provided by the blkctl block on i.MX8MM and later and it seems there is
a consensus on trying to provide virtual power domains from a blkctl
driver, controlling clocks and resets for the devices in the power
domain. I would like to avoid introducing yet another way of handling
the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
what we are planning to do on the later chip generations.

CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
virtual power domain thing a shot.

Regards,
Lucas

> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
> version 9:
> ?- Corrections in commit message
> 
> version 7:
> ?- Add Philipp reviewed-by tag.
> ?- Change syscon phandle name.
> ?
> 
> 
> 
> version 5:
> ?- use syscon instead of VPU reset driver.
> ?- if DT doesn't provide syscon keep backward compatibilty by using
> ???'ctrl' reg-name.
> 
> ?drivers/staging/media/hantro/hantro.h       |  5 +-
> ?drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
> ?2 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
> index 6c1b888abe75..37b9ce04bd4e 100644
> --- a/drivers/staging/media/hantro/hantro.h
> +++ b/drivers/staging/media/hantro/hantro.h
> @@ -13,6 +13,7 @@
> ?#define HANTRO_H_
> ?
> 
> 
> 
> ?#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> ?#include <linux/videodev2.h>
> ?#include <linux/wait.h>
> ?#include <linux/clk.h>
> @@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
> ??* @reg_bases:		Mapped addresses of VPU registers.
> ??* @enc_base:		Mapped address of VPU encoder register for convenience.
> ??* @dec_base:		Mapped address of VPU decoder register for convenience.
> - * @ctrl_base:		Mapped address of VPU control block.
> + * @ctrl_base:		Regmap of VPU control block.
> ??* @vpu_mutex:		Mutex to synchronize V4L2 calls.
> ??* @irqlock:		Spinlock to synchronize access to data structures
> ??*			shared with interrupt handlers.
> @@ -186,7 +187,7 @@ struct hantro_dev {
> ?	void __iomem **reg_bases;
> ?	void __iomem *enc_base;
> ?	void __iomem *dec_base;
> -	void __iomem *ctrl_base;
> +	struct regmap *ctrl_base;
> ?
> 
> 
> 
> ?	struct mutex vpu_mutex;	/* video_device lock */
> ?	spinlock_t irqlock;
> diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
> index c222de075ef4..8d0c3425234b 100644
> --- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
> +++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
> @@ -7,6 +7,7 @@
> ?
> 
> 
> 
> ?#include <linux/clk.h>
> ?#include <linux/delay.h>
> +#include <linux/mfd/syscon.h>
> ?
> 
> 
> 
> ?#include "hantro.h"
> ?#include "hantro_jpeg.h"
> @@ -24,30 +25,28 @@
> ?#define CTRL_G1_PP_FUSE		0x0c
> ?#define CTRL_G2_DEC_FUSE	0x10
> ?
> 
> 
> 
> +static const struct regmap_config ctrl_regmap_ctrl = {
> +	.reg_bits = 32,
> +	.val_bits = 32,
> +	.reg_stride = 0x14,
> +};
> +
> ?static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
> ?{
> -	u32 val;
> -
> ?	/* Assert */
> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
> -	val &= ~reset_bits;
> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
> ?
> 
> 
> 
> ?	udelay(2);
> ?
> 
> 
> 
> ?	/* Release */
> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
> -	val |= reset_bits;
> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
> +			   reset_bits, reset_bits);
> ?}
> ?
> 
> 
> 
> ?static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
> ?{
> -	u32 val;
> -
> -	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
> -	val |= clock_bits;
> -	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
> +	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
> +			   clock_bits, clock_bits);
> ?}
> ?
> 
> 
> 
> ?static int imx8mq_runtime_resume(struct hantro_dev *vpu)
> @@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
> ?	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
> ?
> 
> 
> 
> ?	/* Set values of the fuse registers */
> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
> +	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
> +	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
> +	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
> ?
> 
> 
> 
> ?	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
> ?
> 
> 
> 
> @@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
> ?
> 
> 
> 
> ?static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
> ?{
> -	vpu->dec_base = vpu->reg_bases[0];
> -	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
> +	struct device_node *np = vpu->dev->of_node;
> +
> +	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
> +	if (IS_ERR(vpu->ctrl_base)) {
> +		struct resource *res;
> +		void __iomem *ctrl;
> +
> +		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
> +		ctrl = devm_ioremap_resource(vpu->dev, res);
> +		if (IS_ERR(ctrl))
> +			return PTR_ERR(ctrl);
> +
> +		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
> +		if (IS_ERR(vpu->ctrl_base))
> +			return PTR_ERR(vpu->ctrl_base);
> +	}
> ?
> 
> 
> 
> ?	return 0;
> ?}
> @@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
> ?};
> ?
> 
> 
> 
> ?static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
> -static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
> ?
> 
> 
> 
> ?const struct hantro_variant imx8mq_vpu_variant = {
> ?	.dec_fmts = imx8m_vpu_dec_fmts,
> @@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
> ?	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
> ?	.clk_names = imx8mq_clk_names,
> ?	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
> -	.reg_names = imx8mq_reg_names,
> -	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
> ?};




From james.clark at arm.com  Fri Apr 16 11:56:30 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 13:56:30 +0300
Subject: [PATCH v2 0/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
Message-ID: <20210416105632.8771-1-james.clark@arm.com>

Changes since v1:
 * Improved variable name from etm_timestamp -> cs_timestamp
 * Fixed ordering of Signed-off-by

James Clark (2):
  perf cs-etm: Refactor timestamp variable names
  perf cs-etm: Set time on synthesised samples to preserve ordering

 .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++----
 tools/perf/util/cs-etm.c                      | 52 ++++++++++---------
 tools/perf/util/cs-etm.h                      |  4 +-
 3 files changed, 39 insertions(+), 35 deletions(-)

-- 
2.28.0



From james.clark at arm.com  Fri Apr 16 11:56:31 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 13:56:31 +0300
Subject: [PATCH v2 2/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210416105632.8771-1-james.clark@arm.com>
References: <20210416105632.8771-1-james.clark@arm.com>
Message-ID: <20210416105632.8771-2-james.clark@arm.com>

The following attribute is set when synthesising samples in
timed decoding mode:

    attr.sample_type |= PERF_SAMPLE_TIME;

This results in new samples that appear to have timestamps but
because we don't assign any timestamps to the samples, when the
resulting inject file is opened again, the synthesised samples
will be on the wrong side of the MMAP or COMM events.

For example this results in the samples being associated with
the perf binary, rather than the target of the record:

    perf record -e cs_etm/@tmc_etr0/u top
    perf inject -i perf.data -o perf.inject --itrace=i100il
    perf report -i perf.inject

Where 'Command' == perf should show as 'top':

    # Overhead  Command  Source Shared Object  Source Symbol           Target Symbol           Basic Block Cycles
    # ........  .......  ....................  ......................  ......................  ..................
    #
        31.08%  perf     [unknown]             [.] 0x000000000040c3f8  [.] 0x000000000040c3e8  -

If the perf.data file is opened directly with perf, without the
inject step, then this already works correctly because the
events are synthesised after the COMM and MMAP events and
no second sorting happens. Re-sorting only happens when opening
the perf.inject file for the second time so timestamps are
needed.

Using the timestamp from the AUX record mirrors the current
behaviour when opening directly with perf, because the events
are generated on the call to cs_etm__process_queues().

Co-developed-by: Al Grant <al.grant at arm.com>
Signed-off-by: Al Grant <al.grant at arm.com>
Signed-off-by: James Clark <james.clark at arm.com>
---
 tools/perf/util/cs-etm.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 533f6f2f0685..e5c1a1b22a2a 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -54,6 +54,7 @@ struct cs_etm_auxtrace {
 	u8 sample_instructions;
 
 	int num_cpu;
+	u64 latest_kernel_timestamp;
 	u32 auxtrace_type;
 	u64 branches_sample_type;
 	u64 branches_id;
@@ -1192,6 +1193,8 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
 	event->sample.header.misc = cs_etm__cpu_mode(etmq, addr);
 	event->sample.header.size = sizeof(struct perf_event_header);
 
+	if (!etm->timeless_decoding)
+		sample.time = etm->latest_kernel_timestamp;
 	sample.ip = addr;
 	sample.pid = tidq->pid;
 	sample.tid = tidq->tid;
@@ -1248,6 +1251,8 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
 	event->sample.header.misc = cs_etm__cpu_mode(etmq, ip);
 	event->sample.header.size = sizeof(struct perf_event_header);
 
+	if (!etm->timeless_decoding)
+		sample.time = etm->latest_kernel_timestamp;
 	sample.ip = ip;
 	sample.pid = tidq->pid;
 	sample.tid = tidq->tid;
@@ -2412,9 +2417,10 @@ static int cs_etm__process_event(struct perf_session *session,
 	else if (event->header.type == PERF_RECORD_SWITCH_CPU_WIDE)
 		return cs_etm__process_switch_cpu_wide(etm, event);
 
-	if (!etm->timeless_decoding &&
-	    event->header.type == PERF_RECORD_AUX)
+	if (!etm->timeless_decoding && event->header.type == PERF_RECORD_AUX) {
+		etm->latest_kernel_timestamp = sample_kernel_timestamp;
 		return cs_etm__process_queues(etm);
+	}
 
 	return 0;
 }
-- 
2.28.0



From james.clark at arm.com  Fri Apr 16 11:56:32 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 13:56:32 +0300
Subject: [PATCH v2 1/2] perf cs-etm: Refactor timestamp variable names
In-Reply-To: <20210416105632.8771-1-james.clark@arm.com>
References: <20210416105632.8771-1-james.clark@arm.com>
Message-ID: <20210416105632.8771-3-james.clark@arm.com>

Remove ambiguity in variable names relating to timestamps.
A later commit will save the sample kernel timestamp in one
of the etm structs, so name all elements appropriately to
avoid confusion.

This is also removes some ambiguity arising from the fact
that the --timestamp argument to perf record refers to
sample kernel timestamps, and the /timestamp/ event modifier
refers to CS timestamps, so the term is overloaded.

Signed-off-by: James Clark <james.clark at arm.com>
---
 .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 ++++----
 tools/perf/util/cs-etm.c                      | 42 +++++++++----------
 tools/perf/util/cs-etm.h                      |  4 +-
 3 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index 059bcec3f651..b01d363b9301 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -276,13 +276,13 @@ cs_etm_decoder__do_soft_timestamp(struct cs_etm_queue *etmq,
 				  const uint8_t trace_chan_id)
 {
 	/* No timestamp packet has been received, nothing to do */
-	if (!packet_queue->timestamp)
+	if (!packet_queue->cs_timestamp)
 		return OCSD_RESP_CONT;
 
-	packet_queue->timestamp = packet_queue->next_timestamp;
+	packet_queue->cs_timestamp = packet_queue->next_cs_timestamp;
 
 	/* Estimate the timestamp for the next range packet */
-	packet_queue->next_timestamp += packet_queue->instr_count;
+	packet_queue->next_cs_timestamp += packet_queue->instr_count;
 	packet_queue->instr_count = 0;
 
 	/* Tell the front end which traceid_queue needs attention */
@@ -308,8 +308,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 	 * Function do_soft_timestamp() will report the value to the front end,
 	 * hence asking the decoder to keep decoding rather than stopping.
 	 */
-	if (packet_queue->timestamp) {
-		packet_queue->next_timestamp = elem->timestamp;
+	if (packet_queue->cs_timestamp) {
+		packet_queue->next_cs_timestamp = elem->timestamp;
 		return OCSD_RESP_CONT;
 	}
 
@@ -320,8 +320,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 	 * which instructions started by subtracting the number of instructions
 	 * executed to the timestamp.
 	 */
-	packet_queue->timestamp = elem->timestamp - packet_queue->instr_count;
-	packet_queue->next_timestamp = elem->timestamp;
+	packet_queue->cs_timestamp = elem->timestamp - packet_queue->instr_count;
+	packet_queue->next_cs_timestamp = elem->timestamp;
 	packet_queue->instr_count = 0;
 
 	/* Tell the front end which traceid_queue needs attention */
@@ -334,8 +334,8 @@ cs_etm_decoder__do_hard_timestamp(struct cs_etm_queue *etmq,
 static void
 cs_etm_decoder__reset_timestamp(struct cs_etm_packet_queue *packet_queue)
 {
-	packet_queue->timestamp = 0;
-	packet_queue->next_timestamp = 0;
+	packet_queue->cs_timestamp = 0;
+	packet_queue->next_cs_timestamp = 0;
 	packet_queue->instr_count = 0;
 }
 
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 7e63e7dedc33..533f6f2f0685 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -38,8 +38,6 @@
 #include <tools/libc_compat.h>
 #include "util/synthetic-events.h"
 
-#define MAX_TIMESTAMP (~0ULL)
-
 struct cs_etm_auxtrace {
 	struct auxtrace auxtrace;
 	struct auxtrace_queues queues;
@@ -86,7 +84,7 @@ struct cs_etm_queue {
 	struct cs_etm_decoder *decoder;
 	struct auxtrace_buffer *buffer;
 	unsigned int queue_nr;
-	u8 pending_timestamp;
+	u8 pending_timestamp_chan_id;
 	u64 offset;
 	const unsigned char *buf;
 	size_t buf_len, buf_used;
@@ -208,7 +206,7 @@ void cs_etm__etmq_set_traceid_queue_timestamp(struct cs_etm_queue *etmq,
 	 * be more than one channel per cs_etm_queue, we need to specify
 	 * what traceID queue needs servicing.
 	 */
-	etmq->pending_timestamp = trace_chan_id;
+	etmq->pending_timestamp_chan_id = trace_chan_id;
 }
 
 static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
@@ -216,22 +214,22 @@ static u64 cs_etm__etmq_get_timestamp(struct cs_etm_queue *etmq,
 {
 	struct cs_etm_packet_queue *packet_queue;
 
-	if (!etmq->pending_timestamp)
+	if (!etmq->pending_timestamp_chan_id)
 		return 0;
 
 	if (trace_chan_id)
-		*trace_chan_id = etmq->pending_timestamp;
+		*trace_chan_id = etmq->pending_timestamp_chan_id;
 
 	packet_queue = cs_etm__etmq_get_packet_queue(etmq,
-						     etmq->pending_timestamp);
+						     etmq->pending_timestamp_chan_id);
 	if (!packet_queue)
 		return 0;
 
 	/* Acknowledge pending status */
-	etmq->pending_timestamp = 0;
+	etmq->pending_timestamp_chan_id = 0;
 
 	/* See function cs_etm_decoder__do_{hard|soft}_timestamp() */
-	return packet_queue->timestamp;
+	return packet_queue->cs_timestamp;
 }
 
 static void cs_etm__clear_packet_queue(struct cs_etm_packet_queue *queue)
@@ -814,7 +812,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 	int ret = 0;
 	unsigned int cs_queue_nr;
 	u8 trace_chan_id;
-	u64 timestamp;
+	u64 cs_timestamp;
 	struct cs_etm_queue *etmq = queue->priv;
 
 	if (list_empty(&queue->head) || etmq)
@@ -854,7 +852,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 
 		/*
 		 * Run decoder on the trace block.  The decoder will stop when
-		 * encountering a timestamp, a full packet queue or the end of
+		 * encountering a CS timestamp, a full packet queue or the end of
 		 * trace for that block.
 		 */
 		ret = cs_etm__decode_data_block(etmq);
@@ -865,10 +863,10 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 		 * Function cs_etm_decoder__do_{hard|soft}_timestamp() does all
 		 * the timestamp calculation for us.
 		 */
-		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
+		cs_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
 
 		/* We found a timestamp, no need to continue. */
-		if (timestamp)
+		if (cs_timestamp)
 			break;
 
 		/*
@@ -892,7 +890,7 @@ static int cs_etm__setup_queue(struct cs_etm_auxtrace *etm,
 	 * queue and will be processed in cs_etm__process_queues().
 	 */
 	cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
-	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
+	ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, cs_timestamp);
 out:
 	return ret;
 }
@@ -2221,7 +2219,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 	int ret = 0;
 	unsigned int cs_queue_nr, queue_nr;
 	u8 trace_chan_id;
-	u64 timestamp;
+	u64 cs_timestamp;
 	struct auxtrace_queue *queue;
 	struct cs_etm_queue *etmq;
 	struct cs_etm_traceid_queue *tidq;
@@ -2283,9 +2281,9 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 		if (ret)
 			goto out;
 
-		timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
+		cs_timestamp = cs_etm__etmq_get_timestamp(etmq, &trace_chan_id);
 
-		if (!timestamp) {
+		if (!cs_timestamp) {
 			/*
 			 * Function cs_etm__decode_data_block() returns when
 			 * there is no more traces to decode in the current
@@ -2308,7 +2306,7 @@ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
 		 * this queue/traceID.
 		 */
 		cs_queue_nr = TO_CS_QUEUE_NR(queue_nr, trace_chan_id);
-		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, timestamp);
+		ret = auxtrace_heap__add(&etm->heap, cs_queue_nr, cs_timestamp);
 	}
 
 out:
@@ -2380,7 +2378,7 @@ static int cs_etm__process_event(struct perf_session *session,
 				 struct perf_tool *tool)
 {
 	int err = 0;
-	u64 timestamp;
+	u64 sample_kernel_timestamp;
 	struct cs_etm_auxtrace *etm = container_of(session->auxtrace,
 						   struct cs_etm_auxtrace,
 						   auxtrace);
@@ -2394,11 +2392,11 @@ static int cs_etm__process_event(struct perf_session *session,
 	}
 
 	if (sample->time && (sample->time != (u64) -1))
-		timestamp = sample->time;
+		sample_kernel_timestamp = sample->time;
 	else
-		timestamp = 0;
+		sample_kernel_timestamp = 0;
 
-	if (timestamp || etm->timeless_decoding) {
+	if (sample_kernel_timestamp || etm->timeless_decoding) {
 		err = cs_etm__update_queues(etm);
 		if (err)
 			return err;
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 36428918411e..d65c7b19407d 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -171,8 +171,8 @@ struct cs_etm_packet_queue {
 	u32 head;
 	u32 tail;
 	u32 instr_count;
-	u64 timestamp;
-	u64 next_timestamp;
+	u64 cs_timestamp;
+	u64 next_cs_timestamp;
 	struct cs_etm_packet packet_buffer[CS_ETM_PACKET_MAX_BUFFER];
 };
 
-- 
2.28.0



From ruifeng.zhang0110 at gmail.com  Fri Apr 16 12:04:38 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Fri, 16 Apr 2021 19:04:38 +0800
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
Message-ID: <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??6:39???
>
> On 16/04/2021 11:32, Valentin Schneider wrote:
> > On 16/04/21 15:47, Ruifeng Zhang wrote:
> >> For more requirements, if all cores in one physical cluster, the
> >> {aff2} of all cores are the same value.
> >> i.e. the sc9863a,
> >> core0: 0000000081000000
> >> core1: 0000000081000100
> >> core2: 0000000081000200
> >> core3: 0000000081000300
> >> core4: 0000000081000400
> >> core5: 0000000081000500
> >> core6: 0000000081000600
> >> core7: 0000000081000700
> >>
> >> According to MPIDR all cores will parse to the one cluster, but it's
> >> the big.LITTLE system, it's need two logic cluster for schedule or
> >> cpufreq.
> >> So I think it's better to add the logic of parse topology from DT.
> >
> > Ah, so it's a slightly different issue, but still one that requires a
> > different means of specifying topology.
>
> I'm confused. Do you have the MT bit set to 1 then? So the issue that
> the mpidr handling in arm32's store_cpu_topology() is not correct does
> not exist?

I have reconfirmed it, the MT bit has been set to 1. I am sorry for
the previous messages.
The mpidr parse by store_cpu_topology is correct, at least for the sc9863a.

>
> With DynamIQ you have only *one* cluster, you should also be able to run
> your big.LITTLE system with only an MC sched domain.
>
> # cat /proc/schedstat
> cpu0 ....
> domain0 ff ... <- MC
> ...
>
> You can introduce a cpu-map to create what we called Phantom Domains in
> Android products.
>
> # cat /proc/schedstat
>
> cpu0 ....
> domain0 0f ... <- MC
> domain1 ff ... < DIE
>
> Is this what you need for your arm32 kernel system? Adding the
> possibility to parse cpu-map to create Phantom Domains?

Yes, I need parse DT cpu-map to create different Phantom Domains.
With it, the dts should be change to:
                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>;
                                };
                        };
                };


From willy at infradead.org  Fri Apr 16 12:05:53 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 16 Apr 2021 12:05:53 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <f51e1aa98cb94880a236d58c75c20994@AcuMS.aculab.com>
References: <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210415182155.GD2531743@casper.infradead.org>
 <5179a01a462f43d6951a65de2a299070@AcuMS.aculab.com>
 <20210415222211.GG2531743@casper.infradead.org>
 <f51e1aa98cb94880a236d58c75c20994@AcuMS.aculab.com>
Message-ID: <20210416110553.GH2531743@casper.infradead.org>

On Fri, Apr 16, 2021 at 07:32:35AM +0000, David Laight wrote:
> From: Matthew Wilcox <willy at infradead.org>
> > Sent: 15 April 2021 23:22
> > 
> > On Thu, Apr 15, 2021 at 09:11:56PM +0000, David Laight wrote:
> > > Isn't it possible to move the field down one long?
> > > This might require an explicit zero - but this is not a common
> > > code path - the extra write will be noise.
> > 
> > Then it overlaps page->mapping.  See emails passim.
> 
> The rules on overlaps make be wonder if every 'long'
> should be in its own union.

That was what we used to have.  It was worse.

> The comments would need to say when each field is used.
> It would, at least, make these errors less common.
> 
> That doesn't solve the 64bit dma_addr though.
> 
> Actually rather that word-swapping dma_addr on 32bit BE
> could you swap over the two fields it overlays with.
> That might look messy in the .h, but it doesn't require
> an accessor function to do the swap - easily missed.

No.


From christophe.leroy at csgroup.eu  Fri Apr 16 12:08:25 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 13:08:25 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
Message-ID: <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>



Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
> On 16/04/2021 11:38, Christophe Leroy wrote:
>>
>>
>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>> In order to support large pages on powerpc, notepage()
>>>> needs to know the page size of the page.
>>>>
>>>> Add a page_size argument to notepage().
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>>>> ---
>>>> ? arch/arm64/mm/ptdump.c???????? |? 2 +-
>>>> ? arch/riscv/mm/ptdump.c???????? |? 2 +-
>>>> ? arch/s390/mm/dump_pagetables.c |? 3 ++-
>>>> ? arch/x86/mm/dump_pagetables.c? |? 2 +-
>>>> ? include/linux/ptdump.h???????? |? 2 +-
>>>> ? mm/ptdump.c??????????????????? | 16 ++++++++--------
>>>> ? 6 files changed, 14 insertions(+), 13 deletions(-)
>>>>
>>> [...]
>>>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>>>> index da751448d0e4..61cd16afb1c8 100644
>>>> --- a/mm/ptdump.c
>>>> +++ b/mm/ptdump.c
>>>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
>>>> ? {
>>>> ????? struct ptdump_state *st = walk->private;
>>>> -??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
>>>> +??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), PAGE_SIZE);
>>>
>>> I'm not completely sure what the page_size is going to be used for, but note that KASAN presents 
>>> an interesting case here. We short-cut by detecting it's a KASAN region at a high level 
>>> (PGD/P4D/PUD/PMD) and instead of walking the tree down just call note_page() *once* but with 
>>> level==4 because we know KASAN sets up the page table like that.
>>>
>>> However the one call actually covers a much larger region - so while PAGE_SIZE matches the level 
>>> it doesn't match the region covered. AFAICT this will lead to odd results if you enable KASAN on 
>>> powerpc.
>>
>> Hum .... I successfully tested it with KASAN, I now realise that I tested it with 
>> CONFIG_KASAN_VMALLOC selected. In this situation, since 
>> https://github.com/torvalds/linux/commit/af3d0a686 we don't have any common shadow page table 
>> anymore.
>>
>> I'll test again without CONFIG_KASAN_VMALLOC.
>>
>>>
>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be using 
>>> it purely to find "holes" in the calls to note_page(), but I haven't worked out why such holes 
>>> would occur.
>>
>> I was indeed introduced for KASAN. We have a first commit 
>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is a 
>> KASAN like stuff.
>>
>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what the 
>> problem was exactly, something around the use of hugepages for kernel memory, came as part of the 
>> series 
>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
> 
> 
> Ah, that's useful context. So it looks like powerpc took a different route to reducing the KASAN 
> output to x86.
> 
> Given the generic ptdump code has handling for KASAN already it should be possible to drop that from 
> the powerpc arch code, which I think means we don't actually need to provide page size to 
> notepage(). Hopefully that means more code to delete ;)
> 

Yes ... and no.

It looks like the generic ptdump handles the case when several pgdir entries points to the same 
kasan_early_shadow_pte. But it doesn't take into account the powerpc case where we have regular page 
tables where several (if not all) PTEs are pointing to the kasan_early_shadow_page .

Christophe


From alexander.shishkin at linux.intel.com  Fri Apr 16 12:19:27 2021
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 16 Apr 2021 14:19:27 +0300
Subject: [PATCH v1 1/2] coresight: Add support for device names
In-Reply-To: <1618560476-28908-2-git-send-email-taozha@codeaurora.org>
References: <1618560476-28908-1-git-send-email-taozha@codeaurora.org>
 <1618560476-28908-2-git-send-email-taozha@codeaurora.org>
Message-ID: <87im4mfpds.fsf@ashishki-desk.ger.corp.intel.com>

Tao Zhang <taozha at codeaurora.org> writes:

> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 4ba801d..b79c726 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -1640,6 +1640,12 @@ char *coresight_alloc_device_name(struct coresight_dev_list *dict,
>  	int idx;
>  	char *name = NULL;
>  	struct fwnode_handle **list;
> +	struct device_node *node = dev->of_node;
> +
> +	if (!node) {
> +		if (!of_property_read_string(node, "coresight-name", &name))

Ok, I'm not a device tree expert, but I'm pretty sure the above is a
nop.

Regards,
--
Alex


From alexander.shishkin at linux.intel.com  Fri Apr 16 12:23:45 2021
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 16 Apr 2021 14:23:45 +0300
Subject: [PATCH v1 2/2] dt-bindings: arm: add property for coresight
 component name
In-Reply-To: <1618560476-28908-3-git-send-email-taozha@codeaurora.org>
References: <1618560476-28908-1-git-send-email-taozha@codeaurora.org>
 <1618560476-28908-3-git-send-email-taozha@codeaurora.org>
Message-ID: <87fszqfp6m.fsf@ashishki-desk.ger.corp.intel.com>

Tao Zhang <taozha at codeaurora.org> writes:

> Add property "coresight-name" for coresight component name. This
> allows coresight driver to read device name from device entries.
>
> Signed-off-by: Tao Zhang <taozha at codeaurora.org>
> ---
>  Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index d711676..0e980ce 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -103,6 +103,8 @@ its hardware characteristcs.
>  	  powers down the coresight component also powers down and loses its
>  	  context. This property is currently only used for the ETM 4.x driver.
>  
> +	* coresight-name: the name of the coresight devices.

Which devices? Also, is it a common practice to extend device tree
definitions based on arbitrary driver needs, or should there be some
sort of a discussion first?

Regards,
--
Alex


From noodles at earth.li  Fri Apr 16 12:30:04 2021
From: noodles at earth.li (Jonathan McDowell)
Date: Fri, 16 Apr 2021 12:30:04 +0100
Subject: [PATCH] drm/rockchip: Cope with endpoints that haven't been
 registered yet
In-Reply-To: <3104631.44csPzL39Z@phil>
References: <20210316182753.GA25685@earth.li>
 <3104631.44csPzL39Z@phil>
Message-ID: <20210416113004.GW11733@earth.li>

On Sun, Mar 21, 2021 at 07:58:13PM +0100, Heiko Stuebner wrote:
> Am Dienstag, 16. M?rz 2021, 19:27:53 CET schrieb Jonathan McDowell:
> > The Rockchip RGB CRTC output driver attempts to avoid probing Rockchip
> > subdrivers to see if they're a connected panel or bridge. However part
> > of its checks assumes that if no OF platform device is found then it
> > can't be a valid bridge or panel. This causes issues with I2C controlled
> > bridges that have not yet been registered to the point they can be
> > found.
> > 
> > Change this to return EPROBE_DEFER instead of ENODEV and don't ignore
> > such devices. The subsequent call to drm_of_find_panel_or_bridge() will
> > return EPROBE_DEFER as well if there's actually a valid device we should
> > wait for.
> > 
> > Signed-off-by: Jonathan McDowell <noodles at earth.li>
> > ---
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 8 ++++++--
> >  drivers/gpu/drm/rockchip/rockchip_rgb.c     | 7 ++++---
> >  2 files changed, 10 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > index 212bd87c0c4a..b0d63a566501 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > @@ -270,11 +270,15 @@ int rockchip_drm_endpoint_is_subdriver(struct device_node *ep)
> >  	if (!node)
> >  		return -ENODEV;
> >  
> > -	/* status disabled will prevent creation of platform-devices */
> > +	/*
> > +	 * status disabled will prevent creation of platform-devices,
> > +	 * but equally we can't rely on the driver having been registered
> > +	 * yet (e.g. I2C bridges).
> > +	 */
> >  	pdev = of_find_device_by_node(node);
> >  	of_node_put(node);
> >  	if (!pdev)
> > -		return -ENODEV;
> > +		return -EPROBE_DEFER;
> 
> In general, how does that relate to i2c-bridge-drivers, as
> of_find_device_by_node supposedly only acts on platform-devices?

I think the problem here is that not finding the device node means we
return an error here, which means it's not actually possible to attach
an i2c bridge driver to the Rockchip RGB interface at present.

> Also if that points to a disabled bridge (hdmi, etc) that would likely make
> it probe-defer indefinitly, as that device will never become available?
> 
> Maybe we could do something like of_device_is_available() which checks
> the status property of the node. So something like:
> 
>   	pdev = of_find_device_by_node(node);
>   	if (!pdev) {
> 		bool avail = of_device_is_available(node);
> 
> 		of_node_put(node);
> 
> 		/* if disabled
> 		if (!avail)
> 			return -ENODEV;
> 		else
> 			return -EPROBE_DEFER;
> 	}
>   	of_node_put(node);
> 
> Though I still do not understand how that should actually pick up on
> i2c devices at all.

of_find_device_by_node will fail here, as it's not a platform device,
but then of_device_is_available should return true so I think I can
actually just return false here rather than EPROBE_DEFER - because if
it's not a platform device then it's not a subdriver, which is what
we're checking for.

I'll re-roll and test this weekend and post an updated revision. Thanks
for the pointers.

J.

-- 
101 things you can't have too much of : 3 - Sleep.


From herbert at gondor.apana.org.au  Fri Apr 16 12:30:57 2021
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 16 Apr 2021 21:30:57 +1000
Subject: [PATCH -next 0/5] Remove redundant dev_err call
In-Reply-To: <20210407141819.32588-1-yuehaibing@huawei.com>
References: <20210407141819.32588-1-yuehaibing@huawei.com>
Message-ID: <20210416113057.GG16633@gondor.apana.org.au>

On Wed, Apr 07, 2021 at 10:18:14PM +0800, YueHaibing wrote:
> This patchset remove some redundant dev_err calls
> 
> YueHaibing (5):
>   crypto: atmel-tdes - Remove redundant dev_err call in
>     atmel_tdes_probe()
>   crypto: img-hash - Remove redundant dev_err call in img_hash_probe()
>   crypto: ux500 - Remove redundant dev_err calls
>   crypto: keembay - Remove redundant dev_err calls
>   crypto: ccree - Remove redundant dev_err call in init_cc_resources()
> 
>  drivers/crypto/atmel-tdes.c                   | 1 -
>  drivers/crypto/ccree/cc_driver.c              | 4 +---
>  drivers/crypto/img-hash.c                     | 3 ---
>  drivers/crypto/keembay/keembay-ocs-aes-core.c | 4 +---
>  drivers/crypto/keembay/keembay-ocs-hcu-core.c | 4 +---
>  drivers/crypto/ux500/cryp/cryp_core.c         | 1 -
>  drivers/crypto/ux500/hash/hash_core.c         | 1 -
>  7 files changed, 3 insertions(+), 15 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 herbert at gondor.apana.org.au  Fri Apr 16 12:31:40 2021
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 16 Apr 2021 21:31:40 +1000
Subject: [PATCH -next 1/7] crypto: sun4i-ss - Fix PM reference leak when
 pm_runtime_get_sync() fails
In-Reply-To: <20210408071831.836638-1-liushixin2@huawei.com>
References: <20210408071831.836638-1-liushixin2@huawei.com>
Message-ID: <20210416113140.GI16633@gondor.apana.org.au>

On Thu, Apr 08, 2021 at 03:18:31PM +0800, Shixin Liu wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get to keep usage
> counter balanced.
> 
> Signed-off-by: Shixin Liu <liushixin2 at huawei.com>
> ---
>  drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 2 +-
>  drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c   | 2 +-
>  drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c   | 2 +-
>  drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c   | 2 +-
>  4 files changed, 4 insertions(+), 4 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 herbert at gondor.apana.org.au  Fri Apr 16 12:32:48 2021
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Fri, 16 Apr 2021 21:32:48 +1000
Subject: [PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
In-Reply-To: <20210409221155.1113205-1-nathan@kernel.org>
References: <20210409221155.1113205-1-nathan@kernel.org>
Message-ID: <20210416113248.GM16633@gondor.apana.org.au>

On Fri, Apr 09, 2021 at 03:11:55PM -0700, Nathan Chancellor wrote:
> Debian's clang carries a patch that makes the default FPU mode
> 'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
> instructions on hardware that does not support them:
> 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
> https://bugs.debian.org/841474
> https://bugs.debian.org/842142
> https://bugs.debian.org/914268
> 
> This results in the following build error when clang's integrated
> assembler is used because the '.arch' directive overrides the '.fpu'
> directive:
> 
> arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
>  vmov.i32 q0, #1
>  ^
> arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
>  vshr.u64 q1, q0, #7
>  ^
> arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
>  vshr.u64 q0, q0, #8
>  ^
> arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
>  vmov.i32 d4, #19
>  ^
> 
> Shuffle the order of the '.arch' and '.fpu' directives so that the code
> builds regardless of the default FPU mode. This has been tested against
> both clang with and without Debian's patch and GCC.
> 
> Cc: stable at vger.kernel.org
> Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
> Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Suggested-by: Arnd Bergmann <arnd at arndb.de>
> Suggested-by: Jessica Clarke <jrtc27 at jrtc27.com>
> Signed-off-by: Nathan Chancellor <nathan at kernel.org>
> ---
>  arch/arm/crypto/curve25519-core.S | 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 mindal at semihalf.com  Fri Apr 16 12:36:28 2021
From: mindal at semihalf.com (=?UTF-8?Q?Kornel_Dul=C4=99ba?=)
Date: Fri, 16 Apr 2021 13:36:28 +0200
Subject: [PATCH] arm64: dts: fsl-ls1028a: Correct ECAM PCIE window ranges
In-Reply-To: <20210407123438.224551-1-mindal@semihalf.com>
References: <20210407123438.224551-1-mindal@semihalf.com>
Message-ID: <CAKpxNiySoggtGdy784evjFWzErikSdp7JxV5z05i7Dc51c3MMg@mail.gmail.com>

Hi,

On Wed, Apr 7, 2021 at 2:35 PM Kornel Duleba <mindal at semihalf.com> wrote:
>
> Currently all PCIE windows point to bus address 0x0, which does not match
> the values obtained from hardware during EA.
> Replace those values with CPU addresses, since in reality we
> have a 1:1 mapping between the two.
>
> Signed-off-by: Kornel Duleba <mindal at semihalf.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 262fbad8f0ec..85c62a6fabb6 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -994,19 +994,19 @@ pcie at 1f0000000 { /* Integrated Endpoint Root Complex */
>                         msi-map = <0 &its 0x17 0xe>;
>                         iommu-map = <0 &smmu 0x17 0xe>;
>                                   /* PF0-6 BAR0 - non-prefetchable memory */
> -                       ranges = <0x82000000 0x0 0x00000000  0x1 0xf8000000  0x0 0x160000
> +                       ranges = <0x82000000 0x1 0xf8000000  0x1 0xf8000000  0x0 0x160000
>                                   /* PF0-6 BAR2 - prefetchable memory */
> -                                 0xc2000000 0x0 0x00000000  0x1 0xf8160000  0x0 0x070000
> +                                 0xc2000000 0x1 0xf8160000  0x1 0xf8160000  0x0 0x070000
>                                   /* PF0: VF0-1 BAR0 - non-prefetchable memory */
> -                                 0x82000000 0x0 0x00000000  0x1 0xf81d0000  0x0 0x020000
> +                                 0x82000000 0x1 0xf81d0000  0x1 0xf81d0000  0x0 0x020000
>                                   /* PF0: VF0-1 BAR2 - prefetchable memory */
> -                                 0xc2000000 0x0 0x00000000  0x1 0xf81f0000  0x0 0x020000
> +                                 0xc2000000 0x1 0xf81f0000  0x1 0xf81f0000  0x0 0x020000
>                                   /* PF1: VF0-1 BAR0 - non-prefetchable memory */
> -                                 0x82000000 0x0 0x00000000  0x1 0xf8210000  0x0 0x020000
> +                                 0x82000000 0x1 0xf8210000  0x1 0xf8210000  0x0 0x020000
>                                   /* PF1: VF0-1 BAR2 - prefetchable memory */
> -                                 0xc2000000 0x0 0x00000000  0x1 0xf8230000  0x0 0x020000
> +                                 0xc2000000 0x1 0xf8230000  0x1 0xf8230000  0x0 0x020000
>                                   /* BAR4 (PF5) - non-prefetchable memory */
> -                                 0x82000000 0x0 0x00000000  0x1 0xfc000000  0x0 0x400000>;
> +                                 0x82000000 0x1 0xfc000000  0x1 0xfc000000  0x0 0x400000>;
>
>                         enetc_port0: ethernet at 0,0 {
>                                 compatible = "fsl,enetc";
> --
> 2.31.1
>

Have you had a chance to to review the patch? Any questions or remarks?

Regards,
Kornel


From narmstrong at baylibre.com  Fri Apr 16 12:38:59 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 16 Apr 2021 13:38:59 +0200
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
 <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
Message-ID: <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>

On 16/04/2021 11:58, Laurent Pinchart wrote:
> Hi Neil,
> 
> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>> This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
>>
>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
> 
> If we can't trust the CEC config bit, would it be better to not use it
> at all, and instead let each platform glue logic tell whether to enable
> CEC or not ?

Actually, the CEC config bit is right, the HW exists and should be functional, but
this bit doesn't tell if the CEC signal is connected to something.

This lies in the IP integration, like other bits under the "amlogic,meson-*-dw-hdmi"
umbrella.

The first attempt was by Hans using DT, but adding a property in DT for a vendor
specific compatible doesn't make sense. Another idea would be to describe the
CEC signal endpoint like we do for video signal, but I think this is out of scope and
this solution is much simpler and straightforward, and it's more an exception than
a general use case to solve.

Neil

> 
>> Jernej Skrabec (1):
>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>>     driver
>>
>> Neil Armstrong (1):
>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
>>  include/drm/bridge/dw_hdmi.h              | 2 ++
>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>
> 



From rppt at kernel.org  Fri Apr 16 12:40:28 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Fri, 16 Apr 2021 14:40:28 +0300
Subject: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal
 memory from pfn_valid()
In-Reply-To: <62161846-4f03-e4b1-ae0b-fdf96f78d97c@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-3-rppt@kernel.org>
 <4a788546-b854-fd35-644a-f1d9075a9a78@arm.com>
 <9c0956f0-494e-5c6b-bdc2-d4213afd5e2f@redhat.com>
 <YHdQtmuxpqi4wCE/@kernel.org>
 <62161846-4f03-e4b1-ae0b-fdf96f78d97c@redhat.com>
Message-ID: <YHl3rM6D6/Y2rtru@kernel.org>

On Thu, Apr 15, 2021 at 11:31:26AM +0200, David Hildenbrand wrote:
> On 14.04.21 22:29, Mike Rapoport wrote:
> > On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> > > On 08.04.21 07:14, Anshuman Khandual wrote:
> > > > 
> > > > On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > > > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > > > 
> > > > > The intended semantics of pfn_valid() is to verify whether there is a
> > > > > struct page for the pfn in question and nothing else.
> > > > 
> > > > Should there be a comment affirming this semantics interpretation, above the
> > > > generic pfn_valid() in include/linux/mmzone.h ?
> > > > 
> > > > > 
> > > > > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > > > > linear map vs those that require ioremap() to access them.
> > > > > 
> > > > > Introduce a dedicated pfn_is_memory() to perform such check and use it
> > > > > where appropriate.
> > > > > 
> > > > > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > > > > ---
> > > > >    arch/arm64/include/asm/memory.h | 2 +-
> > > > >    arch/arm64/include/asm/page.h   | 1 +
> > > > >    arch/arm64/kvm/mmu.c            | 2 +-
> > > > >    arch/arm64/mm/init.c            | 6 ++++++
> > > > >    arch/arm64/mm/ioremap.c         | 4 ++--
> > > > >    arch/arm64/mm/mmu.c             | 2 +-
> > > > >    6 files changed, 12 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > > > > index 0aabc3be9a75..7e77fdf71b9d 100644
> > > > > --- a/arch/arm64/include/asm/memory.h
> > > > > +++ b/arch/arm64/include/asm/memory.h
> > > > > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> > > > >    #define virt_addr_valid(addr)	({					\
> > > > >    	__typeof__(addr) __addr = __tag_reset(addr);			\
> > > > > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > > > > +	__is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));	\
> > > > >    })
> > > > >    void dump_mem_limit(void);
> > > > > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > > > > index 012cffc574e8..32b485bcc6ff 100644
> > > > > --- a/arch/arm64/include/asm/page.h
> > > > > +++ b/arch/arm64/include/asm/page.h
> > > > > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> > > > >    typedef struct page *pgtable_t;
> > > > >    extern int pfn_valid(unsigned long);
> > > > > +extern int pfn_is_memory(unsigned long);
> > > > >    #include <asm/memory.h>
> > > > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > > > index 8711894db8c2..ad2ea65a3937 100644
> > > > > --- a/arch/arm64/kvm/mmu.c
> > > > > +++ b/arch/arm64/kvm/mmu.c
> > > > > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> > > > >    static bool kvm_is_device_pfn(unsigned long pfn)
> > > > >    {
> > > > > -	return !pfn_valid(pfn);
> > > > > +	return !pfn_is_memory(pfn);
> > > > >    }
> > > > >    /*
> > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > > index 3685e12aba9b..258b1905ed4a 100644
> > > > > --- a/arch/arm64/mm/init.c
> > > > > +++ b/arch/arm64/mm/init.c
> > > > > @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
> > > > >    }
> > > > >    EXPORT_SYMBOL(pfn_valid);
> > > > > +int pfn_is_memory(unsigned long pfn)
> > > > > +{
> > > > > +	return memblock_is_map_memory(PFN_PHYS(pfn));
> > > > > +}
> > > > > +EXPORT_SYMBOL(pfn_is_memory);> +
> > > > 
> > > > Should not this be generic though ? There is nothing platform or arm64
> > > > specific in here. Wondering as pfn_is_memory() just indicates that the
> > > > pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
> > > > instead ? Regardless, it's fine either way.
> > > 
> > > TBH, I dislike (generic) pfn_is_memory(). It feels like we're mixing
> > > concepts.
> > 
> > Yeah, at the moment NOMAP is very much arm specific so I'd keep it this way
> > for now.
> > 
> > >   NOMAP memory vs !NOMAP memory; even NOMAP is some kind of memory
> > > after all. pfn_is_map_memory() would be more expressive, although still
> > > sub-optimal.
> > > 
> > > We'd actually want some kind of arm64-specific pfn_is_system_memory() or the
> > > inverse pfn_is_device_memory() -- to be improved.
> > 
> > In my current version (to be posted soon) I've started with
> > pfn_lineary_mapped() but then ended up with pfn_mapped() to make it
> > "upward" compatible with architectures that use direct rather than linear
> > map :)
> 
> And even that is moot. It doesn't tell you if a PFN is *actually* mapped
> (hello secretmem).
> 
> I'd suggest to just use memblock_is_map_memory() in arch specific code. Then
> it's clear what we are querying exactly and what the semantics might be.

Ok, let's export memblock_is_map_memory() for the KEEP_MEMBLOCK case.

-- 
Sincerely yours,
Mike.


From clabbe at baylibre.com  Fri Apr 16 12:42:05 2021
From: clabbe at baylibre.com (Corentin Labbe)
Date: Fri, 16 Apr 2021 11:42:05 +0000
Subject: [PATCH] MAINTAINERS: gemini: add missing dts pattern
Message-ID: <20210416114205.16469-1-clabbe@baylibre.com>

The MAINTAINERS entry for cortina/gemini miss all dts of this platform.

Signed-off-by: Corentin Labbe <clabbe at baylibre.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f64a75945b06..927fa29f05ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1816,6 +1816,7 @@ F:	Documentation/devicetree/bindings/arm/gemini.txt
 F:	Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
 F:	Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
 F:	Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt
+F:	arch/arm/boot/dts/gemini*
 F:	arch/arm/mach-gemini/
 F:	drivers/net/ethernet/cortina/
 F:	drivers/pinctrl/pinctrl-gemini.c
-- 
2.26.3



From rppt at kernel.org  Fri Apr 16 12:44:26 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Fri, 16 Apr 2021 14:44:26 +0300
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <f5503130-c0e7-329f-86c4-727ece1c860f@redhat.com>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
 <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>
 <YHdPmtpzFxHE9mAt@kernel.org>
 <f5503130-c0e7-329f-86c4-727ece1c860f@redhat.com>
Message-ID: <YHl4mqgh5CtNk1l7@kernel.org>

On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote:
> > Not sure we really need a new pagetype here, PG_Reserved seems to be quite
> > enough to say "don't touch this".  I generally agree that we could make
> > PG_Reserved a PageType and then have several sub-types for reserved memory.
> > This definitely will add clarity but I'm not sure that this justifies
> > amount of churn and effort required to audit uses of PageResrved().
> > > Then, we could mostly avoid having to query memblock at runtime to figure
> > > out that this is special memory. This would obviously be an extension to
> > > this series. Just a thought.
> > 
> > Stop pushing memblock out of kernel! ;-)
> 
> Can't stop. Won't stop. :D
> 
> It's lovely for booting up a kernel until we have other data-structures in
> place ;)

A bit more seriously, we don't have any data structure that reliably
represents physical memory layout and arch-independent fashion. 
memblock is probably the best starting point for eventually having one.

-- 
Sincerely yours,
Mike.


From david at redhat.com  Fri Apr 16 12:54:00 2021
From: david at redhat.com (David Hildenbrand)
Date: Fri, 16 Apr 2021 13:54:00 +0200
Subject: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved
 pages
In-Reply-To: <YHl4mqgh5CtNk1l7@kernel.org>
References: <20210407172607.8812-1-rppt@kernel.org>
 <20210407172607.8812-2-rppt@kernel.org>
 <0c48f98c-7454-1458-15a5-cc5a7e1fb7cd@redhat.com>
 <CAMj1kXGw97epyP2HdHjA8Yp6+VF1j5xmd0AgVBBv3k+h_B610w@mail.gmail.com>
 <3811547a-9057-3c80-3805-2e658488ac99@redhat.com>
 <YHdPmtpzFxHE9mAt@kernel.org>
 <f5503130-c0e7-329f-86c4-727ece1c860f@redhat.com>
 <YHl4mqgh5CtNk1l7@kernel.org>
Message-ID: <1065c0ac-f9e3-2d3a-1ec4-a5c28f98c6ae@redhat.com>

On 16.04.21 13:44, Mike Rapoport wrote:
> On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote:
>>> Not sure we really need a new pagetype here, PG_Reserved seems to be quite
>>> enough to say "don't touch this".  I generally agree that we could make
>>> PG_Reserved a PageType and then have several sub-types for reserved memory.
>>> This definitely will add clarity but I'm not sure that this justifies
>>> amount of churn and effort required to audit uses of PageResrved().
>>>> Then, we could mostly avoid having to query memblock at runtime to figure
>>>> out that this is special memory. This would obviously be an extension to
>>>> this series. Just a thought.
>>>
>>> Stop pushing memblock out of kernel! ;-)
>>
>> Can't stop. Won't stop. :D
>>
>> It's lovely for booting up a kernel until we have other data-structures in
>> place ;)
> 
> A bit more seriously, we don't have any data structure that reliably
> represents physical memory layout and arch-independent fashion.
> memblock is probably the best starting point for eventually having one.

We have the (slowish) kernel resource tree after boot and the (faster) 
memmap. I really don't see why we really need another slowish variant.

We might be better off to just extend and speed up the kernel resource tree.

Memblock as is is not a reasonable datastructure to keep around after 
boot: for example, how we handle boottime allocations and reserve 
regions both as reserved.

-- 
Thanks,

David / dhildenb



From nobuhiro1.iwamatsu at toshiba.co.jp  Fri Apr 16 13:15:23 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Fri, 16 Apr 2021 21:15:23 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210416094426.x4gyw3drp2fcwczs@pengutronix.de>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
 <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
 <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>
 <20210416094426.x4gyw3drp2fcwczs@pengutronix.de>
Message-ID: <20210416121523.c34trzsrlcjuzirl@toshiba.co.jp>

Hi Uwe,

Thanks for your comment.

On Fri, Apr 16, 2021 at 11:44:26AM +0200, Uwe Kleine-K?nig wrote:
> Hello Nobuhiro,
> 
> On Fri, Apr 16, 2021 at 05:07:21PM +0900, Nobuhiro Iwamatsu wrote:
> > On Mon, Apr 12, 2021 at 09:02:32AM +0200, Uwe Kleine-K?nig wrote:
> > > On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> > > > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-K?nig wrote:
> > > > > Can you please put a paragraph analogous to the one in pwm-sifive in the
> > > > > same format. This simplified keeping an overview about the oddities of
> > > > > the various supported chips.
> > > > 
> > > > OK, I will check pwm-sifive's, and add.
> > 
> > I will add the following :
> > 
> >  * Limitations:
> >  * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8) for the input
> >  *   clock running at 1 MHz.
> 
> I would strip that to:
> 
>  - Fixed input clock running at 1 MHz
> 

OK, I will update.

> >  * - When the settings of the PWM are modified, the new values are shadowed
> >  *   in hardware until the PIPGM_PCSR register is written and the currently
> >  *   running period is completed. This way the hardware switches atomically
> >  *   from the old setting to the new.
> >  * - Disabling the hardware completes the currently running period and keeps
> >  *   the output at low level at all times.
> 
> This looks fine.
>  
> > > For me the critical (and only) difference between "off" and
> > > "duty cycle = 0" is that when a new configuration is to be applied. In
> > > the "off" state a new period can (and should) start immediately, while
> > > with "duty_cycle = 0" the rising edge should be delayed until the
> > > currently running period is over.[1]
> > > 
> > > So the thing to do here (IMHO) is:
> > > 
> > > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
> > > with writing a non-zero value to PIPGM_PCSR) completes the currently
> > > running period, then always assume the PWM as enabled.
> > 
> > Yes, this device works that way.
> 
> OK, then please use
> 
> 	state->enabled = true
> 
> unconditionally in visconti_pwm_get_state().
> 

Please let me check.
If I unconditionally add 'state->enabled = true' to visconti_pwm_get_state(),
state->enabled is set to true because visconti_pwm_get_state() is called when
the device is created (this is when I write the device number to the export of
/sys/class/pwm/pwmchip0 ).
And since PIPGM_PCSR is 0 in this state, the pulse by PWM is not output.
However, I think this means that the device is working as this driver.
Is this correct?

> Best regards
> Uwe
> 

Best regards,
  Nobuhiro


From catalin.marinas at arm.com  Fri Apr 16 13:33:22 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 16 Apr 2021 13:33:22 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210416075533.7720-1-zhe.he@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
Message-ID: <20210416123322.GA23184@arm.com>

On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> The general version of is_syscall_success does not handle 32-bit
> compatible case, which would cause 32-bit negative return code to be
> recoganized as a positive number later and seen as a "success".
> 
> Since is_compat_thread is defined in compat.h, implementing
> is_syscall_success in ptrace.h would introduce build failure due to
> recursive inclusion of some basic headers like mutex.h. We put the
> implementation to ptrace.c
> 
> Signed-off-by: He Zhe <zhe.he at windriver.com>
> ---
>  arch/arm64/include/asm/ptrace.h |  3 +++
>  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index e58bca832dff..3c415e9e5d85 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
>  	regs->regs[0] = rc;
>  }
>  
> +extern inline int is_syscall_success(struct pt_regs *regs);
> +#define is_syscall_success(regs) is_syscall_success(regs)
> +
>  /**
>   * regs_get_kernel_argument() - get Nth function argument in kernel
>   * @regs:	pt_regs of that context
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 170f42fd6101..3266201f8c60 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
>  	else
>  		return valid_native_regs(regs);
>  }
> +
> +inline int is_syscall_success(struct pt_regs *regs)
> +{
> +	unsigned long val = regs->regs[0];
> +
> +	if (is_compat_thread(task_thread_info(current)))
> +		val = sign_extend64(val, 31);
> +
> +	return !IS_ERR_VALUE(val);
> +}

It's better to use compat_user_mode(regs) here instead of
is_compat_thread(). It saves us from worrying whether regs are for the
current context.

I think we should change regs_return_value() instead. This function
seems to be called from several other places and it has the same
potential problems if called on compat pt_regs.

-- 
Catalin


From daniel.kiss at arm.com  Fri Apr 16 13:50:15 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Fri, 16 Apr 2021 14:50:15 +0200
Subject: [PATCH v4 2/2] arm64: Conditionally configure PTR_AUTH key of the
 kernel.
In-Reply-To: <20210416125015.2651652-1-daniel.kiss@arm.com>
References: <20210416125015.2651652-1-daniel.kiss@arm.com>
Message-ID: <20210416125015.2651652-3-daniel.kiss@arm.com>

If the kernel is not compiled with CONFIG_ARM64_PTR_AUTH_KERNEL=y,
then no PACI/AUTI instructions are expected while the kernel is running
so the kernel's key will not be used. Write of a system regiters
is expensive therefore avoid it not required.

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
---
 arch/arm64/include/asm/asm_pointer_auth.h | 63 +++++++++++++----------
 arch/arm64/include/asm/pointer_auth.h     | 44 +++++++++-------
 arch/arm64/include/asm/processor.h        |  2 +
 arch/arm64/kernel/asm-offsets.c           |  2 +
 4 files changed, 65 insertions(+), 46 deletions(-)

diff --git a/arch/arm64/include/asm/asm_pointer_auth.h b/arch/arm64/include/asm/asm_pointer_auth.h
index 52dead2a8640..413cc36fdd5c 100644
--- a/arch/arm64/include/asm/asm_pointer_auth.h
+++ b/arch/arm64/include/asm/asm_pointer_auth.h
@@ -7,6 +7,38 @@
 #include <asm/cpufeature.h>
 #include <asm/sysreg.h>
 
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
+	.macro __ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
+	mov	\tmp1, #THREAD_KEYS_KERNEL
+	add	\tmp1, \tsk, \tmp1
+	ldp	\tmp2, \tmp3, [\tmp1, #PTRAUTH_KERNEL_KEY_APIA]
+	msr_s	SYS_APIAKEYLO_EL1, \tmp2
+	msr_s	SYS_APIAKEYHI_EL1, \tmp3
+	.endm
+
+	.macro ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
+alternative_if ARM64_HAS_ADDRESS_AUTH
+	__ptrauth_keys_install_kernel_nosync \tsk, \tmp1, \tmp2, \tmp3
+alternative_else_nop_endif
+	.endm
+
+	.macro ptrauth_keys_install_kernel tsk, tmp1, tmp2, tmp3
+alternative_if ARM64_HAS_ADDRESS_AUTH
+	__ptrauth_keys_install_kernel_nosync \tsk, \tmp1, \tmp2, \tmp3
+	isb
+alternative_else_nop_endif
+	.endm
+
+#else /* CONFIG_ARM64_PTR_AUTH_KERNEL */
+
+	.macro ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
+	.endm
+
+	.macro ptrauth_keys_install_kernel tsk, tmp1, tmp2, tmp3
+	.endm
+
+#endif /* CONFIG_ARM64_PTR_AUTH_KERNEL */
+
 #ifdef CONFIG_ARM64_PTR_AUTH
 /*
  * thread.keys_user.ap* as offset exceeds the #imm offset range
@@ -39,27 +71,6 @@ alternative_if ARM64_HAS_GENERIC_AUTH
 alternative_else_nop_endif
 	.endm
 
-	.macro __ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
-	mov	\tmp1, #THREAD_KEYS_KERNEL
-	add	\tmp1, \tsk, \tmp1
-	ldp	\tmp2, \tmp3, [\tmp1, #PTRAUTH_KERNEL_KEY_APIA]
-	msr_s	SYS_APIAKEYLO_EL1, \tmp2
-	msr_s	SYS_APIAKEYHI_EL1, \tmp3
-	.endm
-
-	.macro ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
-alternative_if ARM64_HAS_ADDRESS_AUTH
-	__ptrauth_keys_install_kernel_nosync \tsk, \tmp1, \tmp2, \tmp3
-alternative_else_nop_endif
-	.endm
-
-	.macro ptrauth_keys_install_kernel tsk, tmp1, tmp2, tmp3
-alternative_if ARM64_HAS_ADDRESS_AUTH
-	__ptrauth_keys_install_kernel_nosync \tsk, \tmp1, \tmp2, \tmp3
-	isb
-alternative_else_nop_endif
-	.endm
-
 	.macro __ptrauth_keys_init_cpu tsk, tmp1, tmp2, tmp3
 	mrs	\tmp1, id_aa64isar1_el1
 	ubfx	\tmp1, \tmp1, #ID_AA64ISAR1_APA_SHIFT, #8
@@ -69,7 +80,9 @@ alternative_else_nop_endif
 	mrs	\tmp2, sctlr_el1
 	orr	\tmp2, \tmp2, \tmp1
 	msr	sctlr_el1, \tmp2
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
 	__ptrauth_keys_install_kernel_nosync \tsk, \tmp1, \tmp2, \tmp3
+#endif
 	isb
 .Lno_addr_auth\@:
 	.endm
@@ -82,17 +95,11 @@ alternative_else_nop_endif
 .Lno_addr_auth\@:
 	.endm
 
-#else /* CONFIG_ARM64_PTR_AUTH */
+#else /* !CONFIG_ARM64_PTR_AUTH */
 
 	.macro ptrauth_keys_install_user tsk, tmp1, tmp2, tmp3
 	.endm
 
-	.macro ptrauth_keys_install_kernel_nosync tsk, tmp1, tmp2, tmp3
-	.endm
-
-	.macro ptrauth_keys_install_kernel tsk, tmp1, tmp2, tmp3
-	.endm
-
 #endif /* CONFIG_ARM64_PTR_AUTH */
 
 #endif /* __ASM_ASM_POINTER_AUTH_H */
diff --git a/arch/arm64/include/asm/pointer_auth.h b/arch/arm64/include/asm/pointer_auth.h
index b112a11e9302..32e540e3042f 100644
--- a/arch/arm64/include/asm/pointer_auth.h
+++ b/arch/arm64/include/asm/pointer_auth.h
@@ -30,23 +30,12 @@ struct ptrauth_keys_user {
 	struct ptrauth_key apga;
 };
 
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
+
 struct ptrauth_keys_kernel {
 	struct ptrauth_key apia;
 };
 
-static inline void ptrauth_keys_init_user(struct ptrauth_keys_user *keys)
-{
-	if (system_supports_address_auth()) {
-		get_random_bytes(&keys->apia, sizeof(keys->apia));
-		get_random_bytes(&keys->apib, sizeof(keys->apib));
-		get_random_bytes(&keys->apda, sizeof(keys->apda));
-		get_random_bytes(&keys->apdb, sizeof(keys->apdb));
-	}
-
-	if (system_supports_generic_auth())
-		get_random_bytes(&keys->apga, sizeof(keys->apga));
-}
-
 #define __ptrauth_key_install_nosync(k, v)			\
 do {								\
 	struct ptrauth_key __pki_v = (v);			\
@@ -69,6 +58,21 @@ static __always_inline void ptrauth_keys_switch_kernel(struct ptrauth_keys_kerne
 	isb();
 }
 
+#endif /* CONFIG_ARM64_PTR_AUTH_KERNEL */
+
+static inline void ptrauth_keys_init_user(struct ptrauth_keys_user *keys)
+{
+	if (system_supports_address_auth()) {
+		get_random_bytes(&keys->apia, sizeof(keys->apia));
+		get_random_bytes(&keys->apib, sizeof(keys->apib));
+		get_random_bytes(&keys->apda, sizeof(keys->apda));
+		get_random_bytes(&keys->apdb, sizeof(keys->apdb));
+	}
+
+	if (system_supports_generic_auth())
+		get_random_bytes(&keys->apga, sizeof(keys->apga));
+}
+
 extern int ptrauth_prctl_reset_keys(struct task_struct *tsk, unsigned long arg);
 
 static inline unsigned long ptrauth_strip_insn_pac(unsigned long ptr)
@@ -87,18 +91,22 @@ static __always_inline void ptrauth_enable(void)
 
 #define ptrauth_thread_init_user(tsk)					\
 	ptrauth_keys_init_user(&(tsk)->thread.keys_user)
-#define ptrauth_thread_init_kernel(tsk)					\
-	ptrauth_keys_init_kernel(&(tsk)->thread.keys_kernel)
-#define ptrauth_thread_switch_kernel(tsk)				\
-	ptrauth_keys_switch_kernel(&(tsk)->thread.keys_kernel)
 
 #else /* CONFIG_ARM64_PTR_AUTH */
 #define ptrauth_enable()
 #define ptrauth_prctl_reset_keys(tsk, arg)	(-EINVAL)
 #define ptrauth_strip_insn_pac(lr)	(lr)
 #define ptrauth_thread_init_user(tsk)
+#endif /* CONFIG_ARM64_PTR_AUTH */
+
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
+#define ptrauth_thread_init_kernel(tsk)					\
+	ptrauth_keys_init_kernel(&(tsk)->thread.keys_kernel)
+#define ptrauth_thread_switch_kernel(tsk)				\
+	ptrauth_keys_switch_kernel(&(tsk)->thread.keys_kernel)
+#else
 #define ptrauth_thread_init_kernel(tsk)
 #define ptrauth_thread_switch_kernel(tsk)
-#endif /* CONFIG_ARM64_PTR_AUTH */
+#endif /* CONFIG_ARM64_PTR_AUTH_KERNEL */
 
 #endif /* __ASM_POINTER_AUTH_H */
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index efc10e9041a0..9392c0dc2eeb 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -148,8 +148,10 @@ struct thread_struct {
 	struct debug_info	debug;		/* debugging */
 #ifdef CONFIG_ARM64_PTR_AUTH
 	struct ptrauth_keys_user	keys_user;
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
 	struct ptrauth_keys_kernel	keys_kernel;
 #endif
+#endif
 #ifdef CONFIG_ARM64_MTE
 	u64			sctlr_tcf0;
 	u64			gcr_user_excl;
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index e4c6585909ed..443ec8b7622b 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -153,7 +153,9 @@ int main(void)
   DEFINE(PTRAUTH_USER_KEY_APDA,		offsetof(struct ptrauth_keys_user, apda));
   DEFINE(PTRAUTH_USER_KEY_APDB,		offsetof(struct ptrauth_keys_user, apdb));
   DEFINE(PTRAUTH_USER_KEY_APGA,		offsetof(struct ptrauth_keys_user, apga));
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
   DEFINE(PTRAUTH_KERNEL_KEY_APIA,	offsetof(struct ptrauth_keys_kernel, apia));
+#endif
   BLANK();
 #endif
   return 0;
-- 
2.25.1



From daniel.kiss at arm.com  Fri Apr 16 13:50:14 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Fri, 16 Apr 2021 14:50:14 +0200
Subject: [PATCH v4 1/2] arm64: Add ARM64_PTR_AUTH_KERNEL config option
In-Reply-To: <20210416125015.2651652-1-daniel.kiss@arm.com>
References: <20210416125015.2651652-1-daniel.kiss@arm.com>
Message-ID: <20210416125015.2651652-2-daniel.kiss@arm.com>

This patch add the ARM64_PTR_AUTH_KERNEL config and deals with the
build aspect of it.

Userspace support has no dependency on the toolchain therefore all
toolchain checks and build flags are controlled the new config
option.
The default config behavior will not be changed.

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
Acked-by: Will Deacon <will at kernel.org>
---
 arch/arm64/Kconfig              | 33 +++++++++++++++++++--------------
 arch/arm64/Makefile             |  2 +-
 arch/arm64/kernel/asm-offsets.c |  2 ++
 drivers/misc/lkdtm/bugs.c       |  6 +++---
 4 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..ebee6d396d58 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1492,12 +1492,6 @@ menu "ARMv8.3 architectural features"
 config ARM64_PTR_AUTH
 	bool "Enable support for pointer authentication"
 	default y
-	depends on (CC_HAS_SIGN_RETURN_ADDRESS || CC_HAS_BRANCH_PROT_PAC_RET) && AS_HAS_PAC
-	# Modern compilers insert a .note.gnu.property section note for PAC
-	# which is only understood by binutils starting with version 2.33.1.
-	depends on LD_IS_LLD || LD_VERSION >= 23301 || (CC_IS_GCC && GCC_VERSION < 90100)
-	depends on !CC_IS_CLANG || AS_HAS_CFI_NEGATE_RA_STATE
-	depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
 	help
 	  Pointer authentication (part of the ARMv8.3 Extensions) provides
 	  instructions for signing and authenticating pointers against secret
@@ -1509,13 +1503,6 @@ config ARM64_PTR_AUTH
 	  for each process at exec() time, with these keys being
 	  context-switched along with the process.
 
-	  If the compiler supports the -mbranch-protection or
-	  -msign-return-address flag (e.g. GCC 7 or later), then this option
-	  will also cause the kernel itself to be compiled with return address
-	  protection. In this case, and if the target hardware is known to
-	  support pointer authentication, then CONFIG_STACKPROTECTOR can be
-	  disabled with minimal loss of protection.
-
 	  The feature is detected at runtime. If the feature is not present in
 	  hardware it will not be advertised to userspace/KVM guest nor will it
 	  be enabled.
@@ -1526,6 +1513,24 @@ config ARM64_PTR_AUTH
 	  but with the feature disabled. On such a system, this option should
 	  not be selected.
 
+config ARM64_PTR_AUTH_KERNEL
+	bool "Use pointer authentication for kernel"
+	default y
+	depends on ARM64_PTR_AUTH
+	depends on (CC_HAS_SIGN_RETURN_ADDRESS || CC_HAS_BRANCH_PROT_PAC_RET) && AS_HAS_PAC
+	# Modern compilers insert a .note.gnu.property section note for PAC
+	# which is only understood by binutils starting with version 2.33.1.
+	depends on LD_IS_LLD || LD_VERSION >= 233010000 || (CC_IS_GCC && GCC_VERSION < 90100)
+	depends on !CC_IS_CLANG || AS_HAS_CFI_NEGATE_RA_STATE
+	depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
+	help
+	  If the compiler supports the -mbranch-protection or
+	  -msign-return-address flag (e.g. GCC 7 or later), then this option
+	  will cause the kernel itself to be compiled with return address
+	  protection. In this case, and if the target hardware is known to
+	  support pointer authentication, then CONFIG_STACKPROTECTOR can be
+	  disabled with minimal loss of protection.
+
 	  This feature works with FUNCTION_GRAPH_TRACER option only if
 	  DYNAMIC_FTRACE_WITH_REGS is enabled.
 
@@ -1617,7 +1622,7 @@ config ARM64_BTI_KERNEL
 	bool "Use Branch Target Identification for kernel"
 	default y
 	depends on ARM64_BTI
-	depends on ARM64_PTR_AUTH
+	depends on ARM64_PTR_AUTH_KERNEL
 	depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI
 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
 	depends on !CC_IS_GCC || GCC_VERSION >= 100100
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5b84aec31ed3..3b9d156b3e5e 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -70,7 +70,7 @@ endif
 # off, this will be overridden if we are using branch protection.
 branch-prot-flags-y += $(call cc-option,-mbranch-protection=none)
 
-ifeq ($(CONFIG_ARM64_PTR_AUTH),y)
+ifeq ($(CONFIG_ARM64_PTR_AUTH_KERNEL),y)
 branch-prot-flags-$(CONFIG_CC_HAS_SIGN_RETURN_ADDRESS) := -msign-return-address=all
 # We enable additional protection for leaf functions as there is some
 # narrow potential for ROP protection benefits and no substantial
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index a36e2fc330d4..e4c6585909ed 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -45,6 +45,8 @@ int main(void)
   DEFINE(THREAD_CPU_CONTEXT,	offsetof(struct task_struct, thread.cpu_context));
 #ifdef CONFIG_ARM64_PTR_AUTH
   DEFINE(THREAD_KEYS_USER,	offsetof(struct task_struct, thread.keys_user));
+#endif
+#ifdef CONFIG_ARM64_PTR_AUTH_KERNEL
   DEFINE(THREAD_KEYS_KERNEL,	offsetof(struct task_struct, thread.keys_kernel));
 #endif
 #ifdef CONFIG_ARM64_MTE
diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c
index 110f5a8538e9..b5b809b3e1ef 100644
--- a/drivers/misc/lkdtm/bugs.c
+++ b/drivers/misc/lkdtm/bugs.c
@@ -446,7 +446,7 @@ void lkdtm_DOUBLE_FAULT(void)
 #ifdef CONFIG_ARM64
 static noinline void change_pac_parameters(void)
 {
-	if (IS_ENABLED(CONFIG_ARM64_PTR_AUTH)) {
+	if (IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL)) {
 		/* Reset the keys of current task */
 		ptrauth_thread_init_kernel(current);
 		ptrauth_thread_switch_kernel(current);
@@ -460,8 +460,8 @@ noinline void lkdtm_CORRUPT_PAC(void)
 #define CORRUPT_PAC_ITERATE	10
 	int i;
 
-	if (!IS_ENABLED(CONFIG_ARM64_PTR_AUTH))
-		pr_err("FAIL: kernel not built with CONFIG_ARM64_PTR_AUTH\n");
+	if (!IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL))
+		pr_err("FAIL: kernel not built with CONFIG_ARM64_PTR_AUTH_KERNEL\n");
 
 	if (!system_supports_address_auth()) {
 		pr_err("FAIL: CPU lacks pointer authentication feature\n");
-- 
2.25.1



From daniel.kiss at arm.com  Fri Apr 16 13:50:13 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Fri, 16 Apr 2021 14:50:13 +0200
Subject: [PATCH v4 0/2] arm64: split ARM64_PTR_AUTH option to userspace and
 kernel
Message-ID: <20210416125015.2651652-1-daniel.kiss@arm.com>

This patch series is to support pointer authentication in userspace
independently from the kernel use.

Use of pointer authentication in kernel depends on toolchain suppport
and might not be desired in production due to deployment problems.
Debugging the kernel also a bit harder with PAC. Let the distributions
choose where the pointer authentication is used. 
Config structure for BTI is similar.

This patch series can be cleanly applied on v5.12.rc7

The patch series has been tested on Arm FVP in all three
config combinations.

Changes from v3:
* Removed the duplicated #ifdef block in asm/pointer_auth.h.

Changes from v2:
* Moved the toolchain version check under ARM64_PTR_AUTH_KERNEL.

Changes from v1:
* Keep the A key in register while running in the kernel.

Daniel Kiss (2):
  arm64: Add ARM64_PTR_AUTH_KERNEL config option
  arm64: Conditionally configure PTR_AUTH key of the kernel.

 arch/arm64/Kconfig                        | 33 +++++++-----
 arch/arm64/Makefile                       |  2 +-
 arch/arm64/include/asm/asm_pointer_auth.h | 63 +++++++++++++----------
 arch/arm64/include/asm/pointer_auth.h     | 44 +++++++++-------
 arch/arm64/include/asm/processor.h        |  2 +
 arch/arm64/kernel/asm-offsets.c           |  4 ++
 drivers/misc/lkdtm/bugs.c                 |  6 +--
 7 files changed, 90 insertions(+), 64 deletions(-)

-- 
2.25.1



From james.clark at arm.com  Fri Apr 16 13:51:25 2021
From: james.clark at arm.com (James Clark)
Date: Fri, 16 Apr 2021 15:51:25 +0300
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized
 event
In-Reply-To: <20210415152348.GF1011890@leoy-ThinkPad-X240s>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-5-leo.yan@linaro.org>
 <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>
 <20210415152348.GF1011890@leoy-ThinkPad-X240s>
Message-ID: <c9c060d1-0884-b67d-7689-6b45ad10baa9@arm.com>



On 15/04/2021 18:23, Leo Yan wrote:
> On Thu, Apr 15, 2021 at 05:46:31PM +0300, James Clark wrote:
>>
>>
>> On 12/04/2021 12:10, Leo Yan wrote:
>>> In current code, it assigns the arch timer counter to the synthesized
>>> samples Arm SPE trace, thus the samples don't contain the kernel time
>>> but only contain the raw counter value.
>>>
>>> To fix the issue, this patch converts the timer counter to kernel time
>>> and assigns it to sample timestamp.
>>>
>>> Signed-off-by: Leo Yan <leo.yan at linaro.org>
>>> ---
>>>  tools/perf/util/arm-spe.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
>>> index 23714cf0380e..c13a89f06ab8 100644
>>> --- a/tools/perf/util/arm-spe.c
>>> +++ b/tools/perf/util/arm-spe.c
>>> @@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
>>>  	struct arm_spe_record *record = &speq->decoder->record;
>>>  
>>>  	if (!spe->timeless_decoding)
>>> -		sample->time = speq->timestamp;
>>> +		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
>>
>>
>> I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options.
>> I don't know of a way to remove this, and if there isn't, does that mean that all the code in this
>> file that looks at spe->timeless_decoding is untested and has never been hit?
>>
>> Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one
>> might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding
>> is always false.
> 
> Good point.  To be honest, I never noticed this issue until you
> mentioned this.
> 
> We should fix for the "timeless" flow; and it's questionable for the
> function arm_spe_recording_options(), except for setting
> PERF_SAMPLE_TIME, it also hard codes for setting
> PERF_SAMPLE_CPU and PERF_SAMPLE_TID.  Might need to carefully go
> through this function.
> 

Yeah, it's not strictly related to your change, which is definitely an improvement.
But maybe we should have a look at the SPE implementation relating to timestamps as a whole.

> Thanks,
> Leo
> 


From broonie at kernel.org  Fri Apr 16 13:55:58 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 13:55:58 +0100
Subject: [PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable
 imbalance issue
In-Reply-To: <20210416004652.2975446-2-quanyang.wang@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
 <20210416004652.2975446-2-quanyang.wang@windriver.com>
Message-ID: <20210416125558.GA5560@sirena.org.uk>

On Fri, Apr 16, 2021 at 08:46:48AM +0800, quanyang.wang at windriver.com wrote:

> Since pm_runtime works now, clks can be enabled/disabled by calling
> zynqmp_runtime_suspend/resume. So we don't need to enable these clks
> explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue.

> Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")

Are you *sure* this fixes is accurate?  The patch (and several of the
others that flag the same commit) doesn't apply against for-5.12, though
at this point there's not really enough time to send another pull request
so it doesn't super matter though someone will probably need to help out
with stable backports.
-------------- 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/20210416/0d8ea20e/attachment.sig>

From steven.price at arm.com  Fri Apr 16 14:00:28 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 14:00:28 +0100
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
Message-ID: <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>

On 16/04/2021 12:08, Christophe Leroy wrote:
> 
> 
> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>
>>>
>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>>> In order to support large pages on powerpc, notepage()
>>>>> needs to know the page size of the page.
>>>>>
>>>>> Add a page_size argument to notepage().
>>>>>
>>>>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>>>>> ---
>>>>> ? arch/arm64/mm/ptdump.c???????? |? 2 +-
>>>>> ? arch/riscv/mm/ptdump.c???????? |? 2 +-
>>>>> ? arch/s390/mm/dump_pagetables.c |? 3 ++-
>>>>> ? arch/x86/mm/dump_pagetables.c? |? 2 +-
>>>>> ? include/linux/ptdump.h???????? |? 2 +-
>>>>> ? mm/ptdump.c??????????????????? | 16 ++++++++--------
>>>>> ? 6 files changed, 14 insertions(+), 13 deletions(-)
>>>>>
>>>> [...]
>>>>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>>>>> index da751448d0e4..61cd16afb1c8 100644
>>>>> --- a/mm/ptdump.c
>>>>> +++ b/mm/ptdump.c
>>>>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct 
>>>>> mm_walk *walk,
>>>>> ? {
>>>>> ????? struct ptdump_state *st = walk->private;
>>>>> -??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
>>>>> +??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), 
>>>>> PAGE_SIZE);
>>>>
>>>> I'm not completely sure what the page_size is going to be used for, 
>>>> but note that KASAN presents an interesting case here. We short-cut 
>>>> by detecting it's a KASAN region at a high level (PGD/P4D/PUD/PMD) 
>>>> and instead of walking the tree down just call note_page() *once* 
>>>> but with level==4 because we know KASAN sets up the page table like 
>>>> that.
>>>>
>>>> However the one call actually covers a much larger region - so while 
>>>> PAGE_SIZE matches the level it doesn't match the region covered. 
>>>> AFAICT this will lead to odd results if you enable KASAN on powerpc.
>>>
>>> Hum .... I successfully tested it with KASAN, I now realise that I 
>>> tested it with CONFIG_KASAN_VMALLOC selected. In this situation, 
>>> since https://github.com/torvalds/linux/commit/af3d0a686 we don't 
>>> have any common shadow page table anymore.
>>>
>>> I'll test again without CONFIG_KASAN_VMALLOC.
>>>
>>>>
>>>> To be honest I don't fully understand why powerpc requires the 
>>>> page_size - it appears to be using it purely to find "holes" in the 
>>>> calls to note_page(), but I haven't worked out why such holes would 
>>>> occur.
>>>
>>> I was indeed introduced for KASAN. We have a first commit 
>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page 
>>> size to detect whether it is a KASAN like stuff.
>>>
>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a 
>>> fix. I can't remember what the problem was exactly, something around 
>>> the use of hugepages for kernel memory, came as part of the series 
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>
>>
>>
>> Ah, that's useful context. So it looks like powerpc took a different 
>> route to reducing the KASAN output to x86.
>>
>> Given the generic ptdump code has handling for KASAN already it should 
>> be possible to drop that from the powerpc arch code, which I think 
>> means we don't actually need to provide page size to notepage(). 
>> Hopefully that means more code to delete ;)
>>
> 
> Yes ... and no.
> 
> It looks like the generic ptdump handles the case when several pgdir 
> entries points to the same kasan_early_shadow_pte. But it doesn't take 
> into account the powerpc case where we have regular page tables where 
> several (if not all) PTEs are pointing to the kasan_early_shadow_page .

I'm not sure I follow quite how powerpc is different here. But could you 
have a similar check for PTEs against kasan_early_shadow_pte as the 
other levels already have?

I'm just worried that page_size isn't well defined in this interface and 
it's going to cause problems in the future.

Steve


From benjamin.gaignard at collabora.com  Fri Apr 16 14:08:45 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Fri, 16 Apr 2021 15:08:45 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
Message-ID: <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>


Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>> In order to be able to share the control hardware block between
>> VPUs use a syscon instead a ioremap it in the driver.
>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>> phandle is not found look at 'ctrl' reg-name.
>> With the method it becomes useless to provide a list of register
>> names so remove it.
> Sorry for putting a spoke in the wheel after many iterations of the
> series.
>
> We just discussed a way forward on how to handle the clocks and resets
> provided by the blkctl block on i.MX8MM and later and it seems there is
> a consensus on trying to provide virtual power domains from a blkctl
> driver, controlling clocks and resets for the devices in the power
> domain. I would like to avoid introducing yet another way of handling
> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
> what we are planning to do on the later chip generations.
>
> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
> virtual power domain thing a shot.

That could replace the 3 first patches and Dt patche of this series
but that will not impact the hevc part, so I wonder if pure hevc patches
could be merged anyway ?
They are reviewed and don't depend of how the ctrl block is managed.

Regards,
Benjamin

>
> Regards,
> Lucas
>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
>> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
>> ---
>> version 9:
>>  ?- Corrections in commit message
>>
>> version 7:
>>  ?- Add Philipp reviewed-by tag.
>>  ?- Change syscon phandle name.
>>   
>>
>>
>>
>> version 5:
>>  ?- use syscon instead of VPU reset driver.
>>  ?- if DT doesn't provide syscon keep backward compatibilty by using
>>  ???'ctrl' reg-name.
>>
>>  ?drivers/staging/media/hantro/hantro.h       |  5 +-
>>  ?drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
>>  ?2 files changed, 34 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
>> index 6c1b888abe75..37b9ce04bd4e 100644
>> --- a/drivers/staging/media/hantro/hantro.h
>> +++ b/drivers/staging/media/hantro/hantro.h
>> @@ -13,6 +13,7 @@
>>  ?#define HANTRO_H_
>>   
>>
>>
>>
>>  ?#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>>  ?#include <linux/videodev2.h>
>>  ?#include <linux/wait.h>
>>  ?#include <linux/clk.h>
>> @@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
>>  ??* @reg_bases:		Mapped addresses of VPU registers.
>>  ??* @enc_base:		Mapped address of VPU encoder register for convenience.
>>  ??* @dec_base:		Mapped address of VPU decoder register for convenience.
>> - * @ctrl_base:		Mapped address of VPU control block.
>> + * @ctrl_base:		Regmap of VPU control block.
>>  ??* @vpu_mutex:		Mutex to synchronize V4L2 calls.
>>  ??* @irqlock:		Spinlock to synchronize access to data structures
>>  ??*			shared with interrupt handlers.
>> @@ -186,7 +187,7 @@ struct hantro_dev {
>>  ?	void __iomem **reg_bases;
>>  ?	void __iomem *enc_base;
>>  ?	void __iomem *dec_base;
>> -	void __iomem *ctrl_base;
>> +	struct regmap *ctrl_base;
>>   
>>
>>
>>
>>  ?	struct mutex vpu_mutex;	/* video_device lock */
>>  ?	spinlock_t irqlock;
>> diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
>> index c222de075ef4..8d0c3425234b 100644
>> --- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
>> +++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
>> @@ -7,6 +7,7 @@
>>   
>>
>>
>>
>>  ?#include <linux/clk.h>
>>  ?#include <linux/delay.h>
>> +#include <linux/mfd/syscon.h>
>>   
>>
>>
>>
>>  ?#include "hantro.h"
>>  ?#include "hantro_jpeg.h"
>> @@ -24,30 +25,28 @@
>>  ?#define CTRL_G1_PP_FUSE		0x0c
>>  ?#define CTRL_G2_DEC_FUSE	0x10
>>   
>>
>>
>>
>> +static const struct regmap_config ctrl_regmap_ctrl = {
>> +	.reg_bits = 32,
>> +	.val_bits = 32,
>> +	.reg_stride = 0x14,
>> +};
>> +
>>  ?static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
>>  ?{
>> -	u32 val;
>> -
>>  ?	/* Assert */
>> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
>> -	val &= ~reset_bits;
>> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
>> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
>>   
>>
>>
>>
>>  ?	udelay(2);
>>   
>>
>>
>>
>>  ?	/* Release */
>> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
>> -	val |= reset_bits;
>> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
>> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
>> +			   reset_bits, reset_bits);
>>  ?}
>>   
>>
>>
>>
>>  ?static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
>>  ?{
>> -	u32 val;
>> -
>> -	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
>> -	val |= clock_bits;
>> -	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
>> +	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
>> +			   clock_bits, clock_bits);
>>  ?}
>>   
>>
>>
>>
>>  ?static int imx8mq_runtime_resume(struct hantro_dev *vpu)
>> @@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
>>  ?	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
>>   
>>
>>
>>
>>  ?	/* Set values of the fuse registers */
>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
>> +	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
>> +	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
>> +	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
>>   
>>
>>
>>
>>  ?	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
>>   
>>
>>
>>
>> @@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
>>   
>>
>>
>>
>>  ?static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
>>  ?{
>> -	vpu->dec_base = vpu->reg_bases[0];
>> -	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
>> +	struct device_node *np = vpu->dev->of_node;
>> +
>> +	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
>> +	if (IS_ERR(vpu->ctrl_base)) {
>> +		struct resource *res;
>> +		void __iomem *ctrl;
>> +
>> +		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
>> +		ctrl = devm_ioremap_resource(vpu->dev, res);
>> +		if (IS_ERR(ctrl))
>> +			return PTR_ERR(ctrl);
>> +
>> +		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
>> +		if (IS_ERR(vpu->ctrl_base))
>> +			return PTR_ERR(vpu->ctrl_base);
>> +	}
>>   
>>
>>
>>
>>  ?	return 0;
>>  ?}
>> @@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
>>  ?};
>>   
>>
>>
>>
>>  ?static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
>> -static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
>>   
>>
>>
>>
>>  ?const struct hantro_variant imx8mq_vpu_variant = {
>>  ?	.dec_fmts = imx8m_vpu_dec_fmts,
>> @@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
>>  ?	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
>>  ?	.clk_names = imx8mq_clk_names,
>>  ?	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
>> -	.reg_names = imx8mq_reg_names,
>> -	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
>>  ?};
>
>


From ulf.hansson at linaro.org  Fri Apr 16 14:13:27 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 16 Apr 2021 15:13:27 +0200
Subject: [PATCH v2] mmc: meson-gx: replace WARN_ONCE with dev_warn_once
 about scatterlist size alignment in block mode
In-Reply-To: <20210416094347.2015896-1-narmstrong@baylibre.com>
References: <20210416094347.2015896-1-narmstrong@baylibre.com>
Message-ID: <CAPDyKFpu3bz64R-t9KxEkobKKoOY6Dy6H9j2W2LEzeoz4-D4Yw@mail.gmail.com>

On Fri, 16 Apr 2021 at 11:43, Neil Armstrong <narmstrong at baylibre.com> wrote:
>
> Since commit e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode"),
> support for SDIO SD_IO_RW_EXTENDED transferts are properly filtered but some driver
> like brcmfmac still gives a block sg buffer size not aligned with SDIO block,
> triggerring a WARN_ONCE() with scary stacktrace even if the transfer works fine
> but with possible degraded performances.
>
> Simply replace with dev_warn_once() to inform user this should be fixed to avoid
> degraded performance.
>
> This should be ultimately fixed in brcmfmac, but since it's only a performance issue
> the warning should be removed.
>
> Fixes: e085b51c74cc ("mmc: meson-gx: check for scatterlist size alignment in block mode")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>

Applied for next, thanks! (I move to fixes if there is another rc on Monday).

Kind regards
Uffe


> ---
> Changes since v1:
> - replace WARN_ONCE with dev_warn_once and explicit the warning message
>
>  drivers/mmc/host/meson-gx-mmc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index eb6c02bc4a02..b8b771b643cc 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -247,8 +247,9 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
>                  */
>                 for_each_sg(data->sg, sg, data->sg_len, i) {
>                         if (sg->length % data->blksz) {
> -                               WARN_ONCE(1, "unaligned sg len %u blksize %u\n",
> -                                         sg->length, data->blksz);
> +                               dev_warn_once(mmc_dev(mmc),
> +                                             "unaligned sg len %u blksize %u, disabling descriptor DMA for transfer\n",
> +                                             sg->length, data->blksz);
>                                 return;
>                         }
>                 }
> --
> 2.25.1
>


From steen.hegelund at microchip.com  Fri Apr 16 14:16:47 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:47 +0200
Subject: [PATCH net-next 00/10] Adding the Sparx5 Switch Driver
Message-ID: <20210416131657.3151464-1-steen.hegelund@microchip.com>

This series provides the Microchip Sparx5 Switch Driver

The Sparx5 Carrier Ethernet and Industrial switch family delivers 64
Ethernet ports and up to 200 Gbps of switching bandwidth.

It provides a rich set of Ethernet switching features such as hierarchical
QoS, hardware-based OAM  and service activation testing, protection
switching, IEEE 1588, and Synchronous Ethernet.

Using provider bridging (Q-in-Q) and MPLS/MPLS-TP technology, it delivers
MEF CE
2.0 Ethernet virtual connections (EVCs) and features advanced TCAM
  classification in both ingress and egress.

Per-EVC features include advanced L3-aware classification, a rich set of
statistics, OAM for end-to-end performance monitoring, and dual-rate
policing and shaping.

Time sensitive networking (TSN) is supported through a comprehensive set of
features including frame preemption, cut-through, frame replication and
elimination for reliability, enhanced scheduling: credit-based shaping,
time-aware shaping, cyclic queuing, and forwarding, and per-stream policing
and filtering.

Together with IEEE 1588 and IEEE 802.1AS support, this guarantees
low-latency deterministic networking for Fronthaul, Carrier, and Industrial
Ethernet.

The Sparx5 switch family consists of following SKUs:

- VSC7546 Sparx5-64 up to 64 Gbps of bandwidth with the following primary
  port configurations:
  - 6 *10G
  - 16 * 2.5G + 2 * 10G
  - 24 * 1G + 4 * 10G

- VSC7549 Sparx5-90 up to 90 Gbps of bandwidth with the following primary
  port configurations:
  - 9 * 10G
  - 16 * 2.5G + 4 * 10G
  - 48 * 1G + 4 * 10G

- VSC7552 Sparx5-128 up to 128 Gbps of bandwidth with the following primary
  port configurations:
  - 12 * 10G
  - 16 * 2.5G + 8 * 10G
  - 48 * 1G + 8 * 10G

- VSC7556 Sparx5-160 up to 160 Gbps of bandwidth with the following primary
  port configurations:
  - 16 * 10G
  - 10 * 10G + 2 * 25G
  - 16 * 2.5G + 10 * 10G
  - 48 * 1G + 10 * 10G

- VSC7558 Sparx5-200 up to 200 Gbps of bandwidth with the following primary
  port configurations:
  - 20 * 10G
  - 8 * 25G

In addition, the device supports one 10/100/1000/2500/5000 Mbps
SGMII/SerDes node processor interface (NPI) Ethernet port.

The Sparx5 support is developed on the PCB134 and PCB135 evaluation boards.

- PCB134 main networking features:
  - 12x SFP+ front 10G module slots (connected to Sparx5 through SFI).
  - 8x SFP28 front 25G module slots (connected to Sparx5 through SFI high
    speed).
  - Optional, one additional 10/100/1000BASE-T (RJ45) Ethernet port
    (on-board VSC8211 PHY connected to Sparx5 through SGMII).

- PCB135 main networking features:
  - 48x1G (10/100/1000M) RJ45 front ports using 12xVSC8514 QuadPHY?s each
    connected to VSC7558 through QSGMII.
  - 4x10G (1G/2.5G/5G/10G) RJ45 front ports using the AQR407 10G QuadPHY
    each port connects to VSC7558 through SFI.
  - 4x SFP28 25G module slots on back connected to VSC7558 through SFI high
    speed.
  - Optional, one additional 1G (10/100/1000M) RJ45 port using an on-board
    VSC8211 PHY, which can be connected to VSC7558 NPI port through SGMII
    using a loopback add-on PCB)

This series provides support for:
  - SFPs and DAC cables via PHYLINK with a number of 5G, 10G and 25G
    devices and media types.
  - Port module configuration for 10M to 25G speeds with SGMII, QSGMII,
    1000BASEX, 2500BASEX and 10GBASER as appropriate for these modes.
  - SerDes configuration via the Sparx5 SerDes driver (see below).
  - Host mode providing register based injection and extraction.
  - Switch mode providing MAC/VLAN table learning and Layer2 switching
    offloaded to the Sparx5 switch.
  - STP state, VLAN support, host/bridge port mode, Forwarding DB, and
    configuration and statistics via ethtool.

More support will be added at a later stage.

The Sparx5 Chip Register Model can be browsed at this location:
https://github.com/microchip-ung/sparx-5_reginfo
and the datasheet is available here:
https://ww1.microchip.com/downloads/en/DeviceDoc/SparX-5_Family_L2L3_Enterprise_10G_Ethernet_Switches_Datasheet_00003822B.pdf

The series depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: https://lore.kernel.org/r/20210218161451.3489955-1-steen.hegelund at microchip.com/

- Sparx5 Reset Driver
  Link: https://lore.kernel.org/r/20210416084054.2922327-1-steen.hegelund at microchip.com/

Steen Hegelund (10):
  dt-bindings: net: sparx5: Add sparx5-switch bindings
  net: sparx5: add the basic sparx5 driver
  net: sparx5: add hostmode with phylink support
  net: sparx5: add port module support
  net: sparx5: add mactable support
  net: sparx5: add vlan support
  net: sparx5: add switching support
  net: sparx5: add calendar bandwidth allocation support
  net: sparx5: add ethtool configuration and statistics support
  arm64: dts: sparx5: Add the Sparx5 switch node

 .../bindings/net/microchip,sparx5-switch.yaml |  227 +
 arch/arm64/boot/dts/microchip/sparx5.dtsi     |   94 +-
 .../dts/microchip/sparx5_pcb134_board.dtsi    |  481 +-
 .../dts/microchip/sparx5_pcb135_board.dtsi    |  621 ++-
 drivers/net/ethernet/microchip/Kconfig        |    2 +
 drivers/net/ethernet/microchip/Makefile       |    2 +
 drivers/net/ethernet/microchip/sparx5/Kconfig |    9 +
 .../net/ethernet/microchip/sparx5/Makefile    |   10 +
 .../microchip/sparx5/sparx5_calendar.c        |  596 +++
 .../microchip/sparx5/sparx5_ethtool.c         |  999 ++++
 .../microchip/sparx5/sparx5_mactable.c        |  500 ++
 .../ethernet/microchip/sparx5/sparx5_main.c   |  867 ++++
 .../ethernet/microchip/sparx5/sparx5_main.h   |  363 ++
 .../microchip/sparx5/sparx5_main_regs.h       | 4402 +++++++++++++++++
 .../ethernet/microchip/sparx5/sparx5_netdev.c |  247 +
 .../ethernet/microchip/sparx5/sparx5_packet.c |  292 ++
 .../microchip/sparx5/sparx5_phylink.c         |  195 +
 .../ethernet/microchip/sparx5/sparx5_port.c   | 1129 +++++
 .../ethernet/microchip/sparx5/sparx5_port.h   |   98 +
 .../microchip/sparx5/sparx5_switchdev.c       |  508 ++
 .../ethernet/microchip/sparx5/sparx5_vlan.c   |  224 +
 21 files changed, 11782 insertions(+), 84 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
 create mode 100644 drivers/net/ethernet/microchip/sparx5/Kconfig
 create mode 100644 drivers/net/ethernet/microchip/sparx5/Makefile
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_main.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_main.h
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_main_regs.h
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.h
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c

-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:48 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:48 +0200
Subject: [PATCH net-next 01/10] dt-bindings: net: sparx5: Add sparx5-switch
 bindings
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-2-steen.hegelund@microchip.com>

Document the Sparx5 switch device driver bindings

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
---
 .../bindings/net/microchip,sparx5-switch.yaml | 227 ++++++++++++++++++
 1 file changed, 227 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml

diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
new file mode 100644
index 000000000000..2eeb5230d8c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Ethernet switch controller
+
+maintainers:
+  - Steen Hegelund <steen.hegelund at microchip.com>
+  - Lars Povlsen <lars.povlsen at microchip.com>
+
+description: |
+  The SparX-5 Enterprise Ethernet switch family provides a rich set of
+  Enterprise switching features such as advanced TCAM-based VLAN and
+  QoS processing enabling delivery of differentiated services, and
+  security through TCAM-based frame processing using versatile content
+  aware processor (VCAP).
+
+  IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported
+  with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K
+  IPv6 (S,G) multicast groups.
+
+  L3 security features include source guard and reverse path
+  forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and
+  IP tunnels (IP over GRE/IP).
+
+  The SparX-5 switch family targets managed Layer 2 and Layer 3
+  equipment in SMB, SME, and Enterprise where high port count
+  1G/2.5G/5G/10G switching with 10G/25G aggregation links is required.
+
+properties:
+  $nodename:
+    pattern: "^switch@[0-9a-f]+$"
+
+  compatible:
+    const: microchip,sparx5-switch
+
+  reg:
+    minItems: 3
+    items:
+      - description: cpu target
+      - description: devices target
+      - description: general control block target
+
+  reg-names:
+    items:
+      - const: cpu
+      - const: devices
+      - const: gcb
+
+  interrupts:
+    minItems: 1
+    items:
+      - description: register based extraction
+      - description: frame dma based extraction
+
+  interrupt-names:
+    minItems: 1
+    items:
+      - const: xtr
+      - const: fdma
+
+  resets:
+    items:
+      - description: Reset controller used for switch core reset (soft reset)
+
+  reset-names:
+    items:
+      - const: switch
+
+  mac-address: true
+
+  ethernet-ports:
+    type: object
+    patternProperties:
+      "^port@[0-9a-f]+$":
+        type: object
+
+        properties:
+          '#address-cells':
+            const: 1
+          '#size-cells':
+            const: 0
+
+          reg:
+            description: Switch port number
+
+          phys:
+            maxItems: 1
+            description:
+              phandle of a Ethernet SerDes PHY.  This defines which SerDes
+              instance will handle the Ethernet traffic.
+
+          phy-mode:
+            description:
+              This specifies the interface used by the Ethernet SerDes towards
+              the PHY or SFP.
+
+          microchip,bandwidth:
+            description: Specifies bandwidth in Mbit/s allocated to the port.
+            $ref: "/schemas/types.yaml#/definitions/uint32"
+            maximum: 25000
+
+          phy-handle:
+            description:
+              phandle of a Ethernet PHY.  This is optional and if provided it
+              points to the cuPHY used by the Ethernet SerDes.
+
+          sfp:
+            description:
+              phandle of an SFP.  This is optional and used when not specifying
+              a cuPHY.  It points to the SFP node that describes the SFP used by
+              the Ethernet SerDes.
+
+          managed: true
+
+          microchip,sd-sgpio:
+            description:
+              Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs
+              This is optional, and only needed if the default used index is
+              is not correct.
+            $ref: "/schemas/types.yaml#/definitions/uint32"
+            minimum: 0
+            maximum: 383
+
+        required:
+          - reg
+          - phys
+          - phy-mode
+          - microchip,bandwidth
+
+        oneOf:
+          - required:
+              - phy-handle
+          - required:
+              - sfp
+              - managed
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - interrupt-names
+  - resets
+  - reset-names
+  - ethernet-ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    switch: switch at 600000000 {
+      compatible = "microchip,sparx5-switch";
+      reg =  <0 0x401000>,
+             <0x10004000 0x7fc000>,
+             <0x11010000 0xaf0000>;
+      reg-names = "cpu", "devices", "gcb";
+      interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+      interrupt-names = "xtr";
+      resets = <&reset 0>;
+      reset-names = "switch";
+      ethernet-ports {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        port0: port at 0 {
+          reg = <0>;
+          microchip,bandwidth = <1000>;
+          phys = <&serdes 13>;
+          phy-handle = <&phy0>;
+          phy-mode = "qsgmii";
+        };
+        /* ... */
+        /* Then the 25G interfaces */
+        port60: port at 60 {
+          reg = <60>;
+          microchip,bandwidth = <25000>;
+          phys = <&serdes 29>;
+          phy-mode = "10gbase-r";
+          sfp = <&sfp_eth60>;
+          managed = "in-band-status";
+          microchip,sd-sgpio = <365>;
+        };
+        port61: port at 61 {
+          reg = <61>;
+          microchip,bandwidth = <25000>;
+          phys = <&serdes 30>;
+          phy-mode = "10gbase-r";
+          sfp = <&sfp_eth61>;
+          managed = "in-band-status";
+          microchip,sd-sgpio = <369>;
+        };
+        port62: port at 62 {
+          reg = <62>;
+          microchip,bandwidth = <25000>;
+          phys = <&serdes 31>;
+          phy-mode = "10gbase-r";
+          sfp = <&sfp_eth62>;
+          managed = "in-band-status";
+          microchip,sd-sgpio = <373>;
+        };
+        port63: port at 63 {
+          reg = <63>;
+          microchip,bandwidth = <25000>;
+          phys = <&serdes 32>;
+          phy-mode = "10gbase-r";
+          sfp = <&sfp_eth63>;
+          managed = "in-band-status";
+          microchip,sd-sgpio = <377>;
+        };
+        /* Finally the Management interface */
+        port64: port at 64 {
+          reg = <64>;
+          microchip,bandwidth = <1000>;
+          phys = <&serdes 0>;
+          phy-handle = <&phy64>;
+          phy-mode = "sgmii";
+          mac-address = [ 00 00 00 01 02 03 ];
+        };
+      };
+    };
+
+...
+#  vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml :
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:50 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:50 +0200
Subject: [PATCH net-next 03/10] net: sparx5: add hostmode with phylink support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-4-steen.hegelund@microchip.com>

This patch adds netdevs and phylink support for the ports in the switch.
It also adds register based injection and extraction for these ports.

Frame DMA support for injection and extraction will be added in a later
series.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   2 +-
 .../ethernet/microchip/sparx5/sparx5_main.c   |  77 ++++-
 .../ethernet/microchip/sparx5/sparx5_main.h   |  21 ++
 .../ethernet/microchip/sparx5/sparx5_netdev.c | 204 +++++++++++++
 .../ethernet/microchip/sparx5/sparx5_packet.c | 286 ++++++++++++++++++
 .../microchip/sparx5/sparx5_phylink.c         | 170 +++++++++++
 6 files changed, 750 insertions(+), 10 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index 41a31843d86f..19a593d17f4a 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -5,4 +5,4 @@
 
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
-sparx5-switch-objs  := sparx5_main.o
+sparx5-switch-objs  := sparx5_main.o sparx5_packet.o sparx5_netdev.o sparx5_phylink.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 43a67e5c507e..68fd0d5353ba 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -250,9 +250,16 @@ static int sparx5_create_port(struct sparx5 *sparx5,
 			      struct initial_port_config *config)
 {
 	struct sparx5_port *spx5_port;
-
-	/* netdev creation to be added in later patches */
-	spx5_port = devm_kzalloc(sparx5->dev, sizeof(*spx5_port), GFP_KERNEL);
+	struct net_device *ndev;
+	struct phylink *phylink;
+
+	ndev = sparx5_create_netdev(sparx5, config->portno);
+	if (IS_ERR(ndev)) {
+		dev_err(sparx5->dev, "Could not create net device: %02u\n",
+			config->portno);
+		return PTR_ERR(ndev);
+	}
+	spx5_port = netdev_priv(ndev);
 	spx5_port->of_node = config->node;
 	spx5_port->serdes = config->serdes;
 	spx5_port->pvid = NULL_VID;
@@ -262,8 +269,25 @@ static int sparx5_create_port(struct sparx5 *sparx5,
 	spx5_port->max_vlan_tags = SPX5_PORT_MAX_TAGS_NONE;
 	spx5_port->vlan_type = SPX5_VLAN_PORT_TYPE_UNAWARE;
 	spx5_port->custom_etype = 0x8880; /* Vitesse */
+	sparx5->ports[config->portno] = spx5_port;
+
+	spx5_port->conf = config->conf;
+
+	/* VLAN setup to be added in later patches */
+
+	/* Create a phylink for PHY management.  Also handles SFPs */
+	spx5_port->phylink_config.dev = &spx5_port->ndev->dev;
+	spx5_port->phylink_config.type = PHYLINK_NETDEV;
+	spx5_port->phylink_config.pcs_poll = true;
+
+	phylink = phylink_create(&spx5_port->phylink_config,
+				 of_fwnode_handle(config->node),
+				 config->conf.phy_mode,
+				 &sparx5_phylink_mac_ops);
+	if (IS_ERR(phylink))
+		return PTR_ERR(phylink);
 
-	/* PHYLINK support to be added in later patches */
+	spx5_port->phylink = phylink;
 
 	return 0;
 }
@@ -525,6 +549,7 @@ static void sparx5_board_init(struct sparx5 *sparx5)
 static int sparx5_start(struct sparx5 *sparx5)
 {
 	u32 idx;
+	int err;
 
 	/* Setup own UPSIDs */
 	for (idx = 0; idx < 3; idx++) {
@@ -559,13 +584,33 @@ static int sparx5_start(struct sparx5 *sparx5)
 	/* Enable queue limitation watermarks */
 	sparx5_qlim_set(sparx5);
 
-	/* netdev and resource calendar support to be added in later patches */
+	/* Resource calendar support to be added in later patches */
+
+	err = sparx5_register_netdevs(sparx5);
+	if (err)
+		return err;
 
 	sparx5_board_init(sparx5);
 
-	/* Injection/Extraction config to be added in later patches */
+	/* Start register based INJ/XTR */
+	err = -ENXIO;
+	if (err && sparx5->xtr_irq >= 0) {
+		err = devm_request_irq(sparx5->dev, sparx5->xtr_irq,
+				       sparx5_xtr_handler, IRQF_SHARED,
+				       "sparx5-xtr", sparx5);
+		if (!err)
+			err = sparx5_manual_injection_mode(sparx5);
+		if (err)
+			sparx5->xtr_irq = -ENXIO;
+	} else {
+		sparx5->xtr_irq = -ENXIO;
+	}
+	return err;
+}
 
-	return 0;
+static void sparx5_cleanup_ports(struct sparx5 *sparx5)
+{
+	/* Port cleanup to be added in later patches */
 }
 
 static int mchp_sparx5_probe(struct platform_device *pdev)
@@ -677,7 +722,8 @@ static int mchp_sparx5_probe(struct platform_device *pdev)
 		ether_addr_copy(sparx5->base_mac, mac_addr);
 	}
 
-	/* Inj/Xtr IRQ support to be added in later patches */
+	sparx5->xtr_irq = platform_get_irq_byname(sparx5->pdev, "xtr");
+
 	/* Read chip ID to check CPU interface */
 	sparx5->chip_id = spx5_rd(sparx5, GCB_CHIP_ID);
 
@@ -717,12 +763,24 @@ static int mchp_sparx5_probe(struct platform_device *pdev)
 	return err;
 
 cleanup_ports:
-	/* Port cleanup to be added in later patches */
+	sparx5_cleanup_ports(sparx5);
 cleanup_config:
 	kfree(configs);
 	return err;
 }
 
+static int mchp_sparx5_remove(struct platform_device *pdev)
+{
+	struct sparx5 *sparx5 = platform_get_drvdata(pdev);
+
+	if (sparx5->xtr_irq) {
+		disable_irq(sparx5->xtr_irq);
+		sparx5->xtr_irq = -ENXIO;
+	}
+	sparx5_cleanup_ports(sparx5);
+	return 0;
+}
+
 static const struct of_device_id mchp_sparx5_match[] = {
 	{ .compatible = "microchip,sparx5-switch" },
 	{ }
@@ -731,6 +789,7 @@ MODULE_DEVICE_TABLE(of, mchp_sparx5_match);
 
 static struct platform_driver mchp_sparx5_driver = {
 	.probe = mchp_sparx5_probe,
+	.remove = mchp_sparx5_remove,
 	.driver = {
 		.name = "sparx5-switch",
 		.of_match_table = mchp_sparx5_match,
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index c714af96c5d9..3c2334359998 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -69,6 +69,9 @@ enum sparx5_vlan_port_type {
 #define SPX5_BUFFER_CELL_SZ    184   /* Cell size  */
 #define SPX5_BUFFER_MEMORY     4194280 /* 22795 words * 184 bytes */
 
+#define XTR_QUEUE     0
+#define INJ_QUEUE     0
+
 struct sparx5;
 
 struct sparx5_port_config      {
@@ -92,6 +95,9 @@ struct sparx5_port {
 	struct device_node *of_node;
 	struct phy *serdes;
 	struct sparx5_port_config conf;
+	struct phylink_config phylink_config;
+	struct phylink *phylink;
+	struct phylink_pcs phylink_pcs;
 	u16 portno;
 	/* Ingress default VLAN (pvid) */
 	u16 pvid;
@@ -130,8 +136,21 @@ struct sparx5 {
 	u8 base_mac[ETH_ALEN];
 	/* Board specifics */
 	bool sd_sgpio_remapping;
+	/* Register based inj/xtr */
+	int xtr_irq;
 };
 
+/* sparx5_packet.c */
+irqreturn_t sparx5_xtr_handler(int irq, void *_priv);
+int sparx5_port_xmit_impl(struct sk_buff *skb, struct net_device *dev);
+int sparx5_manual_injection_mode(struct sparx5 *sparx5);
+
+/* sparx5_netdev.c */
+bool sparx5_netdevice_check(const struct net_device *dev);
+struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno);
+int sparx5_register_netdevs(struct sparx5 *sparx5);
+void sparx5_destroy_netdev(struct sparx5 *sparx5, struct sparx5_port *port);
+
 /* Clock period in picoseconds */
 static inline u32 sparx5_clk_period(enum sparx5_core_clockfreq cclock)
 {
@@ -146,6 +165,8 @@ static inline u32 sparx5_clk_period(enum sparx5_core_clockfreq cclock)
 	}
 }
 
+extern const struct phylink_mac_ops sparx5_phylink_mac_ops;
+
 /* Calculate raw offset */
 static inline __pure int spx5_offset(int id, int tinst, int tcnt,
 				     int gbase, int ginst,
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
new file mode 100644
index 000000000000..5574cdfb212e
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+/* The IFH bit position of the first VSTAX bit. This is because the
+ * VSTAX bit positions in Data sheet is starting from zero.
+ */
+#define VSTAX 73
+
+static void ifh_encode_bitfield(void *ifh, u64 value, u32 pos, u32 width)
+{
+	u8 *ifh_hdr = ifh;
+	/* Calculate the Start IFH byte position of this IFH bit position */
+	u32 byte = (35 - (pos / 8));
+	/* Calculate the Start bit position in the Start IFH byte */
+	u32 bit  = (pos % 8);
+	u64 encode = GENMASK(bit + width - 1, bit) & (value << bit);
+
+	/* Max width is 5 bytes - 40 bits. In worst case this will
+	 * spread over 6 bytes - 48 bits
+	 */
+	compiletime_assert(width <= 40, "Unsupported width, must be <= 40");
+
+	/* The b0-b7 goes into the start IFH byte */
+	if (encode & 0xFF)
+		ifh_hdr[byte] |= (u8)((encode & 0xFF));
+	/* The b8-b15 goes into the next IFH byte */
+	if (encode & 0xFF00)
+		ifh_hdr[byte - 1] |= (u8)((encode & 0xFF00) >> 8);
+	/* The b16-b23 goes into the next IFH byte */
+	if (encode & 0xFF0000)
+		ifh_hdr[byte - 2] |= (u8)((encode & 0xFF0000) >> 16);
+	/* The b24-b31 goes into the next IFH byte */
+	if (encode & 0xFF000000)
+		ifh_hdr[byte - 3] |= (u8)((encode & 0xFF000000) >> 24);
+	/* The b32-b39 goes into the next IFH byte */
+	if (encode & 0xFF00000000)
+		ifh_hdr[byte - 4] |= (u8)((encode & 0xFF00000000) >> 32);
+	/* The b40-b47 goes into the next IFH byte */
+	if (encode & 0xFF0000000000)
+		ifh_hdr[byte - 5] |= (u8)((encode & 0xFF0000000000) >> 40);
+}
+
+static void sparx5_set_port_ifh(void *ifh_hdr, u16 portno)
+{
+	/* VSTAX.RSV = 1. MSBit must be 1 */
+	ifh_encode_bitfield(ifh_hdr, 1, VSTAX + 79,  1);
+	/* VSTAX.INGR_DROP_MODE = Enable. Don't make head-of-line blocking */
+	ifh_encode_bitfield(ifh_hdr, 1, VSTAX + 55,  1);
+	/* MISC.CPU_MASK/DPORT = Destination port */
+	ifh_encode_bitfield(ifh_hdr, portno,   29, 8);
+	/* MISC.PIPELINE_PT */
+	ifh_encode_bitfield(ifh_hdr, 16,       37, 5);
+	/* MISC.PIPELINE_ACT */
+	ifh_encode_bitfield(ifh_hdr, 1,        42, 3);
+	/* FWD.SRC_PORT = CPU */
+	ifh_encode_bitfield(ifh_hdr, SPX5_PORT_CPU, 46, 7);
+	/* FWD.SFLOW_ID (disable SFlow sampling) */
+	ifh_encode_bitfield(ifh_hdr, 124,      57, 7);
+	/* FWD.UPDATE_FCS = Enable. Enforce update of FCS. */
+	ifh_encode_bitfield(ifh_hdr, 1,        67, 1);
+}
+
+static int sparx5_port_open(struct net_device *ndev)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	int err = 0;
+
+	err = phylink_of_phy_connect(port->phylink, port->of_node, 0);
+	if (err) {
+		netdev_err(ndev, "Could not attach to PHY\n");
+		return err;
+	}
+
+	phylink_start(port->phylink);
+
+	if (!ndev->phydev) {
+		/* power up serdes */
+		port->conf.power_down = false;
+		err = phy_power_on(port->serdes);
+		if (err)
+			netdev_err(ndev, "%s failed\n", __func__);
+	}
+
+	return err;
+}
+
+static int sparx5_port_stop(struct net_device *ndev)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	int err = 0;
+
+	phylink_stop(port->phylink);
+	phylink_disconnect_phy(port->phylink);
+
+	if (!ndev->phydev) {
+		port->conf.power_down = true;
+		err = phy_power_off(port->serdes);
+		if (err)
+			netdev_err(ndev, "%s failed\n", __func__);
+	}
+	return 0;
+}
+
+static int sparx5_port_get_phys_port_name(struct net_device *dev,
+					  char *buf, size_t len)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	int ret;
+
+	ret = snprintf(buf, len, "p%d", port->portno);
+	if (ret >= len)
+		return -EINVAL;
+
+	return 0;
+}
+
+static int sparx5_set_mac_address(struct net_device *dev, void *p)
+{
+	const struct sockaddr *addr = p;
+
+	/* Record the address */
+	ether_addr_copy(dev->dev_addr, addr->sa_data);
+
+	return 0;
+}
+
+static const struct net_device_ops sparx5_port_netdev_ops = {
+	.ndo_open               = sparx5_port_open,
+	.ndo_stop               = sparx5_port_stop,
+	.ndo_start_xmit         = sparx5_port_xmit_impl,
+	.ndo_get_phys_port_name = sparx5_port_get_phys_port_name,
+	.ndo_set_mac_address    = sparx5_set_mac_address,
+	.ndo_validate_addr      = eth_validate_addr,
+};
+
+bool sparx5_netdevice_check(const struct net_device *dev)
+{
+	return dev && (dev->netdev_ops == &sparx5_port_netdev_ops);
+}
+
+struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno)
+{
+	struct sparx5_port *spx5_port;
+	struct net_device *ndev;
+	u64 val;
+
+	ndev = devm_alloc_etherdev(sparx5->dev, sizeof(struct sparx5_port));
+	if (!ndev)
+		return ERR_PTR(-ENOMEM);
+
+	SET_NETDEV_DEV(ndev, sparx5->dev);
+	spx5_port = netdev_priv(ndev);
+	spx5_port->ndev = ndev;
+	spx5_port->sparx5 = sparx5;
+	spx5_port->portno = portno;
+	sparx5_set_port_ifh(spx5_port->ifh, portno);
+	snprintf(ndev->name, IFNAMSIZ, "eth%d", portno);
+
+	ndev->netdev_ops = &sparx5_port_netdev_ops;
+	ndev->features |= NETIF_F_LLTX; /* software tx */
+
+	val = ether_addr_to_u64(sparx5->base_mac) + portno + 1;
+	u64_to_ether_addr(val, ndev->dev_addr);
+
+	return ndev;
+}
+
+int sparx5_register_netdevs(struct sparx5 *sparx5)
+{
+	int portno;
+	int err;
+
+	for (portno = 0; portno < SPX5_PORTS; portno++)
+		if (sparx5->ports[portno]) {
+			err = devm_register_netdev(sparx5->dev,
+						   sparx5->ports[portno]->ndev);
+			if (err) {
+				dev_err(sparx5->dev,
+					"port: %02u: netdev registration failed\n",
+					portno);
+				return err;
+			}
+		}
+	return 0;
+}
+
+void sparx5_destroy_netdev(struct sparx5 *sparx5, struct sparx5_port *port)
+{
+	if (port->phylink) {
+		/* Disconnect the phy */
+		rtnl_lock();
+		sparx5_port_stop(port->ndev);
+		phylink_disconnect_phy(port->phylink);
+		rtnl_unlock();
+		phylink_destroy(port->phylink);
+		port->phylink = NULL;
+	}
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c b/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
new file mode 100644
index 000000000000..2c4106a87fac
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+#define XTR_EOF_0     ntohl((__force __be32)0x80000000u)
+#define XTR_EOF_1     ntohl((__force __be32)0x80000001u)
+#define XTR_EOF_2     ntohl((__force __be32)0x80000002u)
+#define XTR_EOF_3     ntohl((__force __be32)0x80000003u)
+#define XTR_PRUNED    ntohl((__force __be32)0x80000004u)
+#define XTR_ABORT     ntohl((__force __be32)0x80000005u)
+#define XTR_ESCAPE    ntohl((__force __be32)0x80000006u)
+#define XTR_NOT_READY ntohl((__force __be32)0x80000007u)
+
+#define XTR_VALID_BYTES(x)      (4 - ((x) & 3))
+
+struct frame_info {
+	int src_port;
+};
+
+static void sparx5_xtr_flush(struct sparx5 *sparx5, u8 grp)
+{
+	/* Start flush */
+	spx5_wr(QS_XTR_FLUSH_FLUSH_SET(BIT(grp)), sparx5, QS_XTR_FLUSH);
+
+	/* Allow to drain */
+	mdelay(1);
+
+	/* All Queues normal */
+	spx5_wr(0, sparx5, QS_XTR_FLUSH);
+}
+
+static void sparx5_ifh_parse(u32 *ifh, struct frame_info *info)
+{
+	u8 *xtr_hdr = (u8 *)ifh;
+
+	/* FWD is bit 45-72 (28 bits), but we only read the 27 LSB for now */
+	u32 fwd =
+		((u32)xtr_hdr[27] << 24) |
+		((u32)xtr_hdr[28] << 16) |
+		((u32)xtr_hdr[29] <<  8) |
+		((u32)xtr_hdr[30] <<  0);
+	fwd = (fwd >> 5);
+	info->src_port = FIELD_GET(GENMASK(7, 1), fwd);
+}
+
+static void sparx5_xtr_grp(struct sparx5 *sparx5, u8 grp, bool byte_swap)
+{
+	bool eof_flag = false, pruned_flag = false, abort_flag = false;
+	struct net_device *netdev;
+	struct sparx5_port *port;
+	struct frame_info fi;
+	int i, byte_cnt = 0;
+	struct sk_buff *skb;
+	u32 ifh[IFH_LEN];
+	u32 *rxbuf;
+
+	/* Get IFH */
+	for (i = 0; i < IFH_LEN; i++)
+		ifh[i] = spx5_rd(sparx5, QS_XTR_RD(grp));
+
+	/* Decode IFH (whats needed) */
+	sparx5_ifh_parse(ifh, &fi);
+
+	/* Map to port netdev */
+	port = fi.src_port < SPX5_PORTS ?
+		sparx5->ports[fi.src_port] : NULL;
+	if (!port || !port->ndev) {
+		dev_err(sparx5->dev, "Data on inactive port %d\n", fi.src_port);
+		sparx5_xtr_flush(sparx5, grp);
+		return;
+	}
+
+	/* Have netdev, get skb */
+	netdev = port->ndev;
+	skb = netdev_alloc_skb(netdev, netdev->mtu + ETH_HLEN);
+	if (!skb) {
+		sparx5_xtr_flush(sparx5, grp);
+		dev_err(sparx5->dev, "No skb allocated\n");
+		return;
+	}
+	rxbuf = (u32 *)skb->data;
+
+	/* Now, pull frame data */
+	while (!eof_flag) {
+		u32 val = spx5_rd(sparx5, QS_XTR_RD(grp));
+		u32 cmp = val;
+
+		if (byte_swap)
+			cmp = ntohl((__force __be32)val);
+
+		switch (cmp) {
+		case XTR_NOT_READY:
+			break;
+		case XTR_ABORT:
+			/* No accompanying data */
+			abort_flag = true;
+			eof_flag = true;
+			break;
+		case XTR_EOF_0:
+		case XTR_EOF_1:
+		case XTR_EOF_2:
+		case XTR_EOF_3:
+			/* This assumes STATUS_WORD_POS == 1, Status
+			 * just after last data
+			 */
+			byte_cnt -= (4 - XTR_VALID_BYTES(val));
+			eof_flag = true;
+			break;
+		case XTR_PRUNED:
+			/* But get the last 4 bytes as well */
+			eof_flag = true;
+			pruned_flag = true;
+			fallthrough;
+		case XTR_ESCAPE:
+			*rxbuf = spx5_rd(sparx5, QS_XTR_RD(grp));
+			byte_cnt += 4;
+			rxbuf++;
+			break;
+		default:
+			*rxbuf = val;
+			byte_cnt += 4;
+			rxbuf++;
+		}
+	}
+
+	if (abort_flag || pruned_flag || !eof_flag) {
+		netdev_err(netdev, "Discarded frame: abort:%d pruned:%d eof:%d\n",
+			   abort_flag, pruned_flag, eof_flag);
+		kfree_skb(skb);
+		return;
+	}
+
+#if defined(CONFIG_DEBUG_KERNEL) /* TODO: Remove before upstreaming */
+	if (!netif_oper_up(netdev)) {
+		netdev_err(netdev, "Discarded frame: Interface not up\n");
+		kfree_skb(skb);
+		return;
+	}
+#endif
+
+	/* Finish up skb */
+	skb_put(skb, byte_cnt - ETH_FCS_LEN);
+	eth_skb_pad(skb);
+	skb->protocol = eth_type_trans(skb, netdev);
+	netif_rx(skb);
+	netdev->stats.rx_bytes += skb->len;
+	netdev->stats.rx_packets++;
+}
+
+static int sparx5_inject(struct sparx5 *sparx5,
+			 u32 *ifh,
+			 struct sk_buff *skb)
+{
+	int grp = INJ_QUEUE;
+	u32 val, w, count;
+	u8 *buf;
+
+	val = spx5_rd(sparx5, QS_INJ_STATUS);
+	if (!(QS_INJ_STATUS_FIFO_RDY_GET(val) & BIT(grp))) {
+		pr_err("Injection: Queue not ready: 0x%lx\n",
+		       QS_INJ_STATUS_FIFO_RDY_GET(val));
+		return -EBUSY;
+	}
+
+	if (QS_INJ_STATUS_WMARK_REACHED_GET(val) & BIT(grp)) {
+		pr_err("Injection: Watermark reached: 0x%lx\n",
+		       QS_INJ_STATUS_WMARK_REACHED_GET(val));
+		return -EBUSY;
+	}
+
+	/* Indicate SOF */
+	spx5_wr(QS_INJ_CTRL_SOF_SET(1) |
+		QS_INJ_CTRL_GAP_SIZE_SET(1),
+		sparx5, QS_INJ_CTRL(grp));
+
+	// Write the IFH to the chip.
+	for (w = 0; w < IFH_LEN; w++)
+		spx5_wr(ifh[w], sparx5, QS_INJ_WR(grp));
+
+	/* Write words, round up */
+	count = ((skb->len + 3) / 4);
+	buf = skb->data;
+	for (w = 0; w < count; w++, buf += 4) {
+		val = get_unaligned((const u32 *)buf);
+		spx5_wr(val, sparx5, QS_INJ_WR(grp));
+	}
+
+	/* Add padding */
+	while (w < (60 / 4)) {
+		spx5_wr(0, sparx5, QS_INJ_WR(grp));
+		w++;
+	}
+
+	/* Indicate EOF and valid bytes in last word */
+	spx5_wr(QS_INJ_CTRL_GAP_SIZE_SET(1) |
+		QS_INJ_CTRL_VLD_BYTES_SET(skb->len < 60 ? 0 : skb->len % 4) |
+		QS_INJ_CTRL_EOF_SET(1),
+		sparx5, QS_INJ_CTRL(grp));
+
+	/* Add dummy CRC */
+	spx5_wr(0, sparx5, QS_INJ_WR(grp));
+	w++;
+
+	return NETDEV_TX_OK;
+}
+
+int sparx5_port_xmit_impl(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device_stats *stats = &dev->stats;
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
+	int ret;
+
+	ret = sparx5_inject(sparx5, port->ifh, skb);
+
+	if (ret == NETDEV_TX_OK) {
+		stats->tx_bytes += skb->len;
+		stats->tx_packets++;
+		skb_tx_timestamp(skb);
+		dev_kfree_skb_any(skb);
+	} else {
+		stats->tx_dropped++;
+	}
+	return ret;
+}
+
+int sparx5_manual_injection_mode(struct sparx5 *sparx5)
+{
+	const int byte_swap = 1;
+	int portno;
+
+	/* Change mode to manual extraction and injection */
+	spx5_wr(QS_XTR_GRP_CFG_MODE_SET(1) |
+		QS_XTR_GRP_CFG_STATUS_WORD_POS_SET(1) |
+		QS_XTR_GRP_CFG_BYTE_SWAP_SET(byte_swap),
+		sparx5, QS_XTR_GRP_CFG(XTR_QUEUE));
+	spx5_wr(QS_INJ_GRP_CFG_MODE_SET(1) |
+		QS_INJ_GRP_CFG_BYTE_SWAP_SET(byte_swap),
+		sparx5, QS_INJ_GRP_CFG(INJ_QUEUE));
+
+	/* CPU ports capture setup */
+	for (portno = SPX5_PORT_CPU_0; portno <= SPX5_PORT_CPU_1; portno++) {
+		/* ASM CPU port: No preamble, IFH, enable padding */
+		spx5_wr(ASM_PORT_CFG_PAD_ENA_SET(1) |
+			ASM_PORT_CFG_NO_PREAMBLE_ENA_SET(1) |
+			ASM_PORT_CFG_INJ_FORMAT_CFG_SET(1), /* 1 = IFH */
+			sparx5, ASM_PORT_CFG(portno));
+
+		/* Reset WM cnt to unclog queued frames */
+		spx5_rmw(DSM_DEV_TX_STOP_WM_CFG_DEV_TX_CNT_CLR_SET(1),
+			 DSM_DEV_TX_STOP_WM_CFG_DEV_TX_CNT_CLR,
+			 sparx5,
+			 DSM_DEV_TX_STOP_WM_CFG(portno));
+
+		/* Set Disassembler Stop Watermark level */
+		spx5_rmw(DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM_SET(0),
+			 DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM,
+			 sparx5,
+			 DSM_DEV_TX_STOP_WM_CFG(portno));
+
+		/* Enable Disassembler buffer underrun watchdog
+		 */
+		spx5_rmw(DSM_BUF_CFG_UNDERFLOW_WATCHDOG_DIS_SET(0),
+			 DSM_BUF_CFG_UNDERFLOW_WATCHDOG_DIS,
+			 sparx5,
+			 DSM_BUF_CFG(portno));
+	}
+	return 0;
+}
+
+irqreturn_t sparx5_xtr_handler(int irq, void *_sparx5)
+{
+	struct sparx5 *s5 = _sparx5;
+	int poll = 64;
+
+	/* Check data in queue */
+	while (spx5_rd(s5, QS_XTR_DATA_PRESENT) & BIT(XTR_QUEUE) && poll-- > 0)
+		sparx5_xtr_grp(s5, XTR_QUEUE, false);
+
+	return IRQ_HANDLED;
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
new file mode 100644
index 000000000000..3f0155b05c1e
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/module.h>
+#include <linux/phylink.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+#include <linux/sfp.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+static void sparx5_phylink_validate(struct phylink_config *config,
+				    unsigned long *supported,
+				    struct phylink_link_state *state)
+{
+	struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
+	__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+	phylink_set(mask, Autoneg);
+	phylink_set_port_modes(mask);
+	phylink_set(mask, Pause);
+	phylink_set(mask, Asym_Pause);
+
+	switch (state->interface) {
+	case PHY_INTERFACE_MODE_10GBASER:
+	case PHY_INTERFACE_MODE_NA:
+		if (port->conf.bandwidth == SPEED_25000 ||
+		    port->conf.bandwidth == SPEED_10000) {
+			phylink_set(mask, 5000baseT_Full);
+			phylink_set(mask, 10000baseT_Full);
+			phylink_set(mask, 10000baseCR_Full);
+			phylink_set(mask, 10000baseSR_Full);
+			phylink_set(mask, 10000baseLR_Full);
+			phylink_set(mask, 10000baseLRM_Full);
+			phylink_set(mask, 10000baseER_Full);
+		}
+		if (port->conf.bandwidth == SPEED_25000) {
+			phylink_set(mask, 25000baseCR_Full);
+			phylink_set(mask, 25000baseSR_Full);
+		}
+		if (state->interface != PHY_INTERFACE_MODE_NA)
+			break;
+		fallthrough;
+	case PHY_INTERFACE_MODE_SGMII:
+	case PHY_INTERFACE_MODE_QSGMII:
+		phylink_set(mask, 10baseT_Half);
+		phylink_set(mask, 10baseT_Full);
+		phylink_set(mask, 100baseT_Half);
+		phylink_set(mask, 100baseT_Full);
+		phylink_set(mask, 1000baseT_Full);
+		phylink_set(mask, 1000baseX_Full);
+		if (state->interface != PHY_INTERFACE_MODE_NA)
+			break;
+		fallthrough;
+	case PHY_INTERFACE_MODE_1000BASEX:
+	case PHY_INTERFACE_MODE_2500BASEX:
+		if (state->interface != PHY_INTERFACE_MODE_2500BASEX) {
+			phylink_set(mask, 1000baseT_Full);
+			phylink_set(mask, 1000baseX_Full);
+		}
+		if (state->interface == PHY_INTERFACE_MODE_2500BASEX ||
+		    state->interface == PHY_INTERFACE_MODE_NA) {
+			phylink_set(mask, 2500baseT_Full);
+			phylink_set(mask, 2500baseX_Full);
+		}
+		break;
+	default:
+		bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
+		return;
+	}
+	bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
+	bitmap_and(state->advertising, state->advertising, mask,
+		   __ETHTOOL_LINK_MODE_MASK_NBITS);
+}
+
+static bool port_conf_has_changed(struct sparx5_port_config *a, struct sparx5_port_config *b)
+{
+	if (a->speed != b->speed ||
+	    a->portmode != b->portmode ||
+	    a->autoneg != b->autoneg ||
+	    a->pause != b->pause ||
+	    a->media != b->media)
+		return true;
+	return false;
+}
+
+static void sparx5_phylink_mac_config(struct phylink_config *config,
+				      unsigned int mode,
+				      const struct phylink_link_state *state)
+{
+	struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
+	struct sparx5_port_config conf;
+
+	conf = port->conf;
+	conf.power_down = false;
+	conf.portmode = state->interface;
+	conf.speed = state->speed;
+	conf.autoneg = state->an_enabled;
+	conf.pause = state->pause;
+
+	if (state->interface == PHY_INTERFACE_MODE_10GBASER) {
+		if (state->speed == SPEED_UNKNOWN) {
+			/* When a SFP is plugged in we use capabilities to
+			 * default to the highest supported speed
+			 */
+			if (phylink_test(state->advertising, 25000baseSR_Full) ||
+			    phylink_test(state->advertising, 25000baseCR_Full))
+				conf.speed = SPEED_25000;
+			else if (state->interface == PHY_INTERFACE_MODE_10GBASER)
+				conf.speed = SPEED_10000;
+		} else if (state->speed == SPEED_2500) {
+			conf.portmode = PHY_INTERFACE_MODE_2500BASEX;
+		} else if (state->speed == SPEED_1000) {
+			conf.portmode = PHY_INTERFACE_MODE_1000BASEX;
+		}
+
+		if (phylink_test(state->advertising, FIBRE))
+			conf.media = PHY_MEDIA_SR;
+		else
+			conf.media = PHY_MEDIA_DAC;
+	}
+
+	if (!port_conf_has_changed(&port->conf, &conf))
+		return;
+}
+
+static void sparx5_phylink_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)
+{
+	/* Currently not used */
+}
+
+static void sparx5_phylink_mac_link_state(struct phylink_config *config,
+					  struct phylink_link_state *state)
+{
+	state->link = true;
+	state->an_complete = true;
+	state->speed = SPEED_1000;
+	state->duplex = true;
+	state->pause = MLO_PAUSE_AN;
+}
+
+static void sparx5_phylink_mac_aneg_restart(struct phylink_config *config)
+{
+	/* Currently not used */
+}
+
+static void sparx5_phylink_mac_link_down(struct phylink_config *config,
+					 unsigned int mode,
+					 phy_interface_t interface)
+{
+	/* Currently not used */
+}
+
+const struct phylink_mac_ops sparx5_phylink_mac_ops = {
+	.validate = sparx5_phylink_validate,
+	.mac_pcs_get_state = sparx5_phylink_mac_link_state,
+	.mac_config = sparx5_phylink_mac_config,
+	.mac_an_restart = sparx5_phylink_mac_aneg_restart,
+	.mac_link_down = sparx5_phylink_mac_link_down,
+	.mac_link_up = sparx5_phylink_mac_link_up,
+};
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:51 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:51 +0200
Subject: [PATCH net-next 04/10] net: sparx5: add port module support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-5-steen.hegelund@microchip.com>

This add configuration of the Sparx5 port module instances.

Sparx5 has in total 65 logical ports (denoted D0 to D64) and 33
physical SerDes connections (S0 to S32).  The 65th port (D64) is fixed
allocated to SerDes0 (S0). The remaining 64 ports can in various
multiplexing scenarios be connected to the remaining 32 SerDes using
QSGMII, or USGMII or USXGMII extenders. 32 of the ports can have a 1:1
mapping to the 32 SerDes.

Some additional ports (D65 to D69) are internal to the device and do not
connect to port modules or SerDes macros. For example, internal ports are
used for frame injection and extraction to the CPU queues.

The 65 logical ports are split up into the following blocks.

- 13 x 5G ports (D0-D11, D64)
- 32 x 2G5 ports (D16-D47)
- 12 x 10G ports (D12-D15, D48-D55)
- 8 x 25G ports (D56-D63)

Each logical port supports different line speeds, and depending on the
speeds supported, different port modules (MAC+PCS) are needed. A port
supporting 5 Gbps, 10 Gbps, or 25 Gbps as maximum line speed, will have a
DEV5G, DEV10G, or DEV25G module to support the 5 Gbps, 10 Gbps (incl 5
Gbps), or 25 Gbps (including 10 Gbps and 5 Gbps) speeds. As well as, it
will have a shadow DEV2G5 port module to support the lower speeds
(10/100/1000/2500Mbps). When a port needs to operate at lower speed and the
shadow DEV2G5 needs to be connected to its corresponding SerDes

Not all interface modes are supported in this series, but will be added at
a later stage.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |    3 +-
 .../ethernet/microchip/sparx5/sparx5_main.c   |   21 +-
 .../ethernet/microchip/sparx5/sparx5_netdev.c |   14 +-
 .../microchip/sparx5/sparx5_phylink.c         |   37 +-
 .../ethernet/microchip/sparx5/sparx5_port.c   | 1129 +++++++++++++++++
 .../ethernet/microchip/sparx5/sparx5_port.h   |   98 ++
 6 files changed, 1292 insertions(+), 10 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.h

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index 19a593d17f4a..9c14eec33fd7 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -5,4 +5,5 @@
 
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
-sparx5-switch-objs  := sparx5_main.o sparx5_packet.o sparx5_netdev.o sparx5_phylink.o
+sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 68fd0d5353ba..0ae8320a5bbb 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -26,6 +26,7 @@
 
 #include "sparx5_main_regs.h"
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 #define QLIM_WM(fraction) \
 	((SPX5_BUFFER_MEMORY / SPX5_BUFFER_CELL_SZ - 100) * (fraction) / 100)
@@ -252,6 +253,7 @@ static int sparx5_create_port(struct sparx5 *sparx5,
 	struct sparx5_port *spx5_port;
 	struct net_device *ndev;
 	struct phylink *phylink;
+	int err;
 
 	ndev = sparx5_create_netdev(sparx5, config->portno);
 	if (IS_ERR(ndev)) {
@@ -271,9 +273,26 @@ static int sparx5_create_port(struct sparx5 *sparx5,
 	spx5_port->custom_etype = 0x8880; /* Vitesse */
 	sparx5->ports[config->portno] = spx5_port;
 
+	err = sparx5_port_init(sparx5, spx5_port, &config->conf);
+	if (err) {
+		dev_err(sparx5->dev, "port init failed\n");
+		return err;
+	}
 	spx5_port->conf = config->conf;
 
-	/* VLAN setup to be added in later patches */
+	/* VLAN support to be added in later patches */
+
+	/* Create a phylink for PHY management.  Also handles SFPs */
+	spx5_port->phylink_config.dev = &spx5_port->ndev->dev;
+	spx5_port->phylink_config.type = PHYLINK_NETDEV;
+	spx5_port->phylink_config.pcs_poll = true;
+
+	phylink = phylink_create(&spx5_port->phylink_config,
+				 of_fwnode_handle(config->node),
+				 config->conf.phy_mode,
+				 &sparx5_phylink_mac_ops);
+	if (IS_ERR(phylink))
+		return PTR_ERR(phylink);
 
 	/* Create a phylink for PHY management.  Also handles SFPs */
 	spx5_port->phylink_config.dev = &spx5_port->ndev->dev;
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
index 5574cdfb212e..9f053b91e8e0 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -6,6 +6,7 @@
 
 #include "sparx5_main_regs.h"
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 /* The IFH bit position of the first VSTAX bit. This is because the
  * VSTAX bit positions in Data sheet is starting from zero.
@@ -71,6 +72,7 @@ static int sparx5_port_open(struct net_device *ndev)
 	struct sparx5_port *port = netdev_priv(ndev);
 	int err = 0;
 
+	sparx5_port_enable(port, true);
 	err = phylink_of_phy_connect(port->phylink, port->of_node, 0);
 	if (err) {
 		netdev_err(ndev, "Could not attach to PHY\n");
@@ -82,7 +84,10 @@ static int sparx5_port_open(struct net_device *ndev)
 	if (!ndev->phydev) {
 		/* power up serdes */
 		port->conf.power_down = false;
-		err = phy_power_on(port->serdes);
+		if (port->conf.serdes_reset)
+			err = sparx5_serdes_set(port->sparx5, port, &port->conf);
+		else
+			err = phy_power_on(port->serdes);
 		if (err)
 			netdev_err(ndev, "%s failed\n", __func__);
 	}
@@ -95,12 +100,17 @@ static int sparx5_port_stop(struct net_device *ndev)
 	struct sparx5_port *port = netdev_priv(ndev);
 	int err = 0;
 
+	sparx5_port_enable(port, false);
 	phylink_stop(port->phylink);
 	phylink_disconnect_phy(port->phylink);
 
 	if (!ndev->phydev) {
+		/* power down serdes */
 		port->conf.power_down = true;
-		err = phy_power_off(port->serdes);
+		if (port->conf.serdes_reset)
+			err = sparx5_serdes_set(port->sparx5, port, &port->conf);
+		else
+			err = phy_power_off(port->serdes);
 		if (err)
 			netdev_err(ndev, "%s failed\n", __func__);
 	}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
index 3f0155b05c1e..6f8eb456e93f 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
@@ -12,6 +12,7 @@
 
 #include "sparx5_main_regs.h"
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 static void sparx5_phylink_validate(struct phylink_config *config,
 				    unsigned long *supported,
@@ -94,6 +95,7 @@ static void sparx5_phylink_mac_config(struct phylink_config *config,
 {
 	struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
 	struct sparx5_port_config conf;
+	int err = 0;
 
 	conf = port->conf;
 	conf.power_down = false;
@@ -126,6 +128,11 @@ static void sparx5_phylink_mac_config(struct phylink_config *config,
 
 	if (!port_conf_has_changed(&port->conf, &conf))
 		return;
+
+	/* Enable the PCS matching this interface type */
+	err = sparx5_port_pcs_set(port->sparx5, port, &conf);
+	if (err)
+		netdev_err(port->ndev, "port config failed: %d\n", err);
 }
 
 static void sparx5_phylink_mac_link_up(struct phylink_config *config,
@@ -135,17 +142,35 @@ static void sparx5_phylink_mac_link_up(struct phylink_config *config,
 				       int speed, int duplex,
 				       bool tx_pause, bool rx_pause)
 {
-	/* Currently not used */
+	struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
+	struct sparx5_port_config conf;
+	int err = 0;
+
+	conf = port->conf;
+	conf.duplex = duplex;
+	conf.pause = 0;
+	conf.pause |= tx_pause ? MLO_PAUSE_TX : 0;
+	conf.pause |= rx_pause ? MLO_PAUSE_RX : 0;
+	conf.speed = speed;
+
+	/* Configure the port to speed/duplex/pause */
+	err = sparx5_port_config(port->sparx5, port, &conf);
+	if (err)
+		netdev_err(port->ndev, "port config failed: %d\n", err);
 }
 
 static void sparx5_phylink_mac_link_state(struct phylink_config *config,
 					  struct phylink_link_state *state)
 {
-	state->link = true;
-	state->an_complete = true;
-	state->speed = SPEED_1000;
-	state->duplex = true;
-	state->pause = MLO_PAUSE_AN;
+	struct sparx5_port *port = netdev_priv(to_net_dev(config->dev));
+	struct sparx5_port_status status;
+
+	sparx5_get_port_status(port->sparx5, port, &status);
+	state->link = status.link && !status.link_down;
+	state->an_complete = status.an_complete;
+	state->speed = status.speed;
+	state->duplex = status.duplex;
+	state->pause = status.pause;
 }
 
 static void sparx5_phylink_mac_aneg_restart(struct phylink_config *config)
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_port.c b/drivers/net/ethernet/microchip/sparx5/sparx5_port.c
new file mode 100644
index 000000000000..21c7d14d050c
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_port.c
@@ -0,0 +1,1129 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/module.h>
+#include <linux/phy/phy.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+#include "sparx5_port.h"
+
+#define SPX5_ETYPE_TAG_C     0x8100
+#define SPX5_ETYPE_TAG_S     0x88a8
+
+#define SPX5_WAIT_US         1000
+#define SPX5_WAIT_MAX_US     2000
+
+enum port_error {
+	SPX5_PERR_SPEED,
+	SPX5_PERR_IFTYPE,
+};
+
+#define PAUSE_DISCARD        0xC
+#define ETH_MAXLEN           (ETH_DATA_LEN + ETH_HLEN + ETH_FCS_LEN)
+
+static void decode_sgmii_word(u16 lp_abil, struct sparx5_port_status *status)
+{
+	status->an_complete = true;
+	if (!(lp_abil & LPA_SGMII_LINK)) {
+		status->link = false;
+		return;
+	}
+
+	switch (lp_abil & LPA_SGMII_SPD_MASK) {
+	case LPA_SGMII_10:
+		status->speed = SPEED_10;
+		break;
+	case LPA_SGMII_100:
+		status->speed = SPEED_100;
+		break;
+	case LPA_SGMII_1000:
+		status->speed = SPEED_1000;
+		break;
+	default:
+		status->link = false;
+		return;
+	}
+	if (lp_abil & LPA_SGMII_FULL_DUPLEX)
+		status->duplex = DUPLEX_FULL;
+	else
+		status->duplex = DUPLEX_HALF;
+}
+
+static void decode_cl37_word(u16 lp_abil, uint16_t ld_abil, struct sparx5_port_status *status)
+{
+	status->link = !(lp_abil & ADVERTISE_RFAULT) && status->link;
+	status->an_complete = true;
+	status->duplex = (ADVERTISE_1000XFULL & lp_abil) ?
+		DUPLEX_FULL : DUPLEX_UNKNOWN; // 1G HDX not supported
+
+	if ((ld_abil & ADVERTISE_1000XPAUSE) &&
+	    (lp_abil & ADVERTISE_1000XPAUSE)) {
+		status->pause = MLO_PAUSE_RX | MLO_PAUSE_TX;
+	} else if ((ld_abil & ADVERTISE_1000XPSE_ASYM) &&
+		   (lp_abil & ADVERTISE_1000XPSE_ASYM)) {
+		status->pause |= (lp_abil & ADVERTISE_1000XPAUSE) ?
+			MLO_PAUSE_TX : 0;
+		status->pause |= (ld_abil & ADVERTISE_1000XPAUSE) ?
+			MLO_PAUSE_RX : 0;
+	} else {
+		status->pause = MLO_PAUSE_NONE;
+	}
+}
+
+static int sparx5_get_dev2g5_status(struct sparx5 *sparx5,
+				    struct sparx5_port *port,
+				    struct sparx5_port_status *status)
+{
+	u32 portno = port->portno;
+	u16 lp_adv, ld_adv;
+	u32 value;
+
+	/* Get PCS Link down sticky */
+	value = spx5_rd(sparx5, DEV2G5_PCS1G_STICKY(portno));
+	status->link_down = DEV2G5_PCS1G_STICKY_LINK_DOWN_STICKY_GET(value);
+	if (status->link_down)	/* Clear the sticky */
+		spx5_wr(value, sparx5, DEV2G5_PCS1G_STICKY(portno));
+
+	/* Get both current Link and Sync status */
+	value = spx5_rd(sparx5, DEV2G5_PCS1G_LINK_STATUS(portno));
+	status->link = DEV2G5_PCS1G_LINK_STATUS_LINK_STATUS_GET(value) &&
+		       DEV2G5_PCS1G_LINK_STATUS_SYNC_STATUS_GET(value);
+
+	if (port->conf.portmode == PHY_INTERFACE_MODE_1000BASEX)
+		status->speed = SPEED_1000;
+	else if (port->conf.portmode == PHY_INTERFACE_MODE_2500BASEX)
+		status->speed = SPEED_2500;
+
+	status->duplex = DUPLEX_FULL;
+
+	/* Get PCS ANEG status register */
+	value = spx5_rd(sparx5, DEV2G5_PCS1G_ANEG_STATUS(portno));
+
+	/* Aneg complete provides more information  */
+	if (DEV2G5_PCS1G_ANEG_STATUS_ANEG_COMPLETE_GET(value)) {
+		lp_adv = DEV2G5_PCS1G_ANEG_STATUS_LP_ADV_ABILITY_GET(value);
+		if (port->conf.portmode == PHY_INTERFACE_MODE_SGMII) {
+			decode_sgmii_word(lp_adv, status);
+		} else {
+			value = spx5_rd(sparx5, DEV2G5_PCS1G_ANEG_CFG(portno));
+			ld_adv = DEV2G5_PCS1G_ANEG_CFG_ADV_ABILITY_GET(value);
+			decode_cl37_word(lp_adv, ld_adv, status);
+		}
+	}
+	return 0;
+}
+
+static int sparx5_get_sfi_status(struct sparx5 *sparx5,
+				 struct sparx5_port *port,
+				 struct sparx5_port_status *status)
+{
+	bool high_speed_dev = sparx5_is_high_speed_device(&port->conf);
+	u32 portno = port->portno;
+	u32 value, dev, tinst;
+	void __iomem *inst;
+
+	if (!high_speed_dev) {
+		netdev_err(port->ndev, "error: low speed and SFI mode\n");
+		return -EINVAL;
+	}
+
+	dev = sparx5_to_high_dev(portno);
+	tinst = sparx5_port_dev_index(portno);
+	inst = spx5_inst_get(sparx5, dev, tinst);
+
+	value = spx5_inst_rd(inst, DEV10G_MAC_TX_MONITOR_STICKY(0));
+	if (value != DEV10G_MAC_TX_MONITOR_STICKY_IDLE_STATE_STICKY) {
+		/* The link is or has been down. Clear the sticky bit */
+		status->link_down = 1;
+		spx5_inst_wr(0xffffffff, inst, DEV10G_MAC_TX_MONITOR_STICKY(0));
+		value = spx5_inst_rd(inst, DEV10G_MAC_TX_MONITOR_STICKY(0));
+	}
+	status->link = (value == DEV10G_MAC_TX_MONITOR_STICKY_IDLE_STATE_STICKY);
+	status->speed = port->conf.speed;
+	status->duplex = DUPLEX_FULL;
+	return 0;
+}
+
+/* Get link status of 1000Base-X/in-band and SFI ports.
+ */
+int sparx5_get_port_status(struct sparx5 *sparx5,
+			   struct sparx5_port *port,
+			   struct sparx5_port_status *status)
+{
+	memset(status, 0, sizeof(*status));
+	status->speed = port->conf.speed;
+	if (port->conf.power_down) {
+		status->link = false;
+		return 0;
+	}
+	switch (port->conf.portmode) {
+	case PHY_INTERFACE_MODE_SGMII:
+	case PHY_INTERFACE_MODE_QSGMII:
+	case PHY_INTERFACE_MODE_1000BASEX:
+	case PHY_INTERFACE_MODE_2500BASEX:
+		return sparx5_get_dev2g5_status(sparx5, port, status);
+	case PHY_INTERFACE_MODE_10GBASER:
+		return sparx5_get_sfi_status(sparx5, port, status);
+	case PHY_INTERFACE_MODE_NA:
+		return 0;
+	default:
+		netdev_err(port->ndev, "Status not supported");
+		return -ENODEV;
+	}
+	return 0;
+}
+
+static int sparx5_port_error(struct sparx5_port *port,
+			     struct sparx5_port_config *conf,
+			     enum port_error errtype)
+{
+	switch (errtype) {
+	case SPX5_PERR_SPEED:
+		netdev_err(port->ndev,
+			   "Interface does not support speed: %u: for %s\n",
+			   conf->speed, phy_modes(conf->portmode));
+		break;
+	case SPX5_PERR_IFTYPE:
+		netdev_err(port->ndev,
+			   "Switch port does not support interface type: %s\n",
+			   phy_modes(conf->portmode));
+		break;
+	default:
+		netdev_err(port->ndev,
+			   "Interface configuration error\n");
+	}
+
+	return -EINVAL;
+}
+
+static int sparx5_port_verify_speed(struct sparx5 *sparx5,
+				    struct sparx5_port *port,
+				    struct sparx5_port_config *conf)
+{
+	if ((sparx5_port_is_2g5(port->portno) &&
+	     conf->speed > SPEED_2500) ||
+	    (sparx5_port_is_5g(port->portno)  &&
+	     conf->speed > SPEED_5000) ||
+	    (sparx5_port_is_10g(port->portno) &&
+	     conf->speed > SPEED_10000))
+		return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
+
+	switch (conf->portmode) {
+	case PHY_INTERFACE_MODE_NA:
+		return -EINVAL;
+	case PHY_INTERFACE_MODE_1000BASEX:
+		if (conf->speed != SPEED_1000 ||
+		    sparx5_port_is_2g5(port->portno))
+			return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
+		if (sparx5_port_is_2g5(port->portno))
+			return sparx5_port_error(port, conf, SPX5_PERR_IFTYPE);
+		break;
+	case PHY_INTERFACE_MODE_2500BASEX:
+		if (conf->speed != SPEED_2500 ||
+		    sparx5_port_is_2g5(port->portno))
+			return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
+		break;
+	case PHY_INTERFACE_MODE_QSGMII:
+		if (port->portno > 47)
+			return sparx5_port_error(port, conf, SPX5_PERR_IFTYPE);
+		fallthrough;
+	case PHY_INTERFACE_MODE_SGMII:
+		if (conf->speed != SPEED_1000 &&
+		    conf->speed != SPEED_100 &&
+		    conf->speed != SPEED_10 &&
+		    conf->speed != SPEED_2500)
+			return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
+		break;
+	case PHY_INTERFACE_MODE_10GBASER:
+		if ((conf->speed != SPEED_5000 &&
+		     conf->speed != SPEED_10000 &&
+		     conf->speed != SPEED_25000))
+			return sparx5_port_error(port, conf, SPX5_PERR_SPEED);
+		break;
+	default:
+		return sparx5_port_error(port, conf, SPX5_PERR_IFTYPE);
+	}
+	return 0;
+}
+
+static bool sparx5_dev_change(struct sparx5 *sparx5,
+			      struct sparx5_port *port,
+			      struct sparx5_port_config *conf)
+{
+	if (port->conf.portmode != conf->portmode)
+		if (port->conf.portmode == PHY_INTERFACE_MODE_10GBASER ||
+		    conf->portmode == PHY_INTERFACE_MODE_10GBASER)
+			return true;
+
+	return false;
+}
+
+static int sparx5_port_flush_poll(struct sparx5 *sparx5, u32 portno)
+{
+	u32  value, resource, prio, delay_cnt = 0;
+	bool poll_src = true;
+	char *mem = "";
+
+	/* Resource == 0: Memory tracked per source (SRC-MEM)
+	 * Resource == 1: Frame references tracked per source (SRC-REF)
+	 * Resource == 2: Memory tracked per destination (DST-MEM)
+	 * Resource == 3: Frame references tracked per destination. (DST-REF)
+	 */
+	while (1) {
+		bool empty = true;
+
+		for (resource = 0; resource < (poll_src ? 2 : 1); resource++) {
+			u32 base;
+
+			base = (resource == 0 ? 2048 : 0) + SPX5_PRIOS * portno;
+			for (prio = 0; prio < SPX5_PRIOS; prio++) {
+				value = spx5_rd(sparx5,
+						QRES_RES_STAT(base + prio));
+				if (value) {
+					mem = resource == 0 ?
+						"DST-MEM" : "SRC-MEM";
+					empty = false;
+				}
+			}
+		}
+
+		if (empty)
+			break;
+
+		if (delay_cnt++ == 2000) {
+			dev_err(sparx5->dev,
+				"Flush timeout port %u. %s queue not empty\n",
+				portno, mem);
+			return -EINVAL;
+		}
+
+		usleep_range(SPX5_WAIT_US, SPX5_WAIT_MAX_US);
+	}
+	return 0;
+}
+
+static int sparx5_port_disable(struct sparx5 *sparx5, struct sparx5_port *port, bool high_spd_dev)
+{
+	u32 tinst = high_spd_dev ?
+		    sparx5_port_dev_index(port->portno) : port->portno;
+	u32 dev = high_spd_dev ?
+		  sparx5_to_high_dev(port->portno) : TARGET_DEV2G5;
+	void __iomem *devinst = spx5_inst_get(sparx5, dev, tinst);
+	u32 spd = port->conf.speed;
+	u32 spd_prm;
+	int err;
+
+	if (high_spd_dev) {
+		/* 1: Reset the PCS Rx clock domain  */
+		spx5_inst_rmw(DEV10G_DEV_RST_CTRL_PCS_RX_RST,
+			      DEV10G_DEV_RST_CTRL_PCS_RX_RST,
+			      devinst,
+			      DEV10G_DEV_RST_CTRL(0));
+
+		/* 2: Disable MAC frame reception */
+		spx5_inst_rmw(0,
+			      DEV10G_MAC_ENA_CFG_RX_ENA,
+			      devinst,
+			      DEV10G_MAC_ENA_CFG(0));
+	} else {
+		/* 1: Reset the PCS Rx clock domain  */
+		spx5_inst_rmw(DEV2G5_DEV_RST_CTRL_PCS_RX_RST,
+			      DEV2G5_DEV_RST_CTRL_PCS_RX_RST,
+			      devinst,
+			      DEV2G5_DEV_RST_CTRL(0));
+		/* 2: Disable MAC frame reception */
+		spx5_inst_rmw(0,
+			      DEV2G5_MAC_ENA_CFG_RX_ENA,
+			      devinst,
+			      DEV2G5_MAC_ENA_CFG(0));
+	}
+	/* 3: Disable traffic being sent to or from switch port->portno */
+	spx5_rmw(0,
+		 QFWD_SWITCH_PORT_MODE_PORT_ENA,
+		 sparx5,
+		 QFWD_SWITCH_PORT_MODE(port->portno));
+
+	/* 4: Disable dequeuing from the egress queues  */
+	spx5_rmw(HSCH_PORT_MODE_DEQUEUE_DIS,
+		 HSCH_PORT_MODE_DEQUEUE_DIS,
+		 sparx5,
+		 HSCH_PORT_MODE(port->portno));
+
+	/* 5: Disable Flowcontrol */
+	spx5_rmw(QSYS_PAUSE_CFG_PAUSE_STOP_SET(0xFFF - 1),
+		 QSYS_PAUSE_CFG_PAUSE_STOP,
+		 sparx5,
+		 QSYS_PAUSE_CFG(port->portno));
+
+	spd_prm = spd == SPEED_10 ? 1000 : spd == SPEED_100 ? 100 : 10;
+	/* 6: Wait while the last frame is exiting the queues */
+	usleep_range(8 * spd_prm, 10 * spd_prm);
+
+	/* 7: Flush the queues accociated with the port->portno */
+	spx5_rmw(HSCH_FLUSH_CTRL_FLUSH_PORT_SET(port->portno) |
+		 HSCH_FLUSH_CTRL_FLUSH_DST_SET(1) |
+		 HSCH_FLUSH_CTRL_FLUSH_SRC_SET(1) |
+		 HSCH_FLUSH_CTRL_FLUSH_ENA_SET(1),
+		 HSCH_FLUSH_CTRL_FLUSH_PORT |
+		 HSCH_FLUSH_CTRL_FLUSH_DST |
+		 HSCH_FLUSH_CTRL_FLUSH_SRC |
+		 HSCH_FLUSH_CTRL_FLUSH_ENA,
+		 sparx5,
+		 HSCH_FLUSH_CTRL);
+
+	/* 8: Enable dequeuing from the egress queues */
+	spx5_rmw(0,
+		 HSCH_PORT_MODE_DEQUEUE_DIS,
+		 sparx5,
+		 HSCH_PORT_MODE(port->portno));
+
+	/* 9: Wait until flushing is complete */
+	err = sparx5_port_flush_poll(sparx5, port->portno);
+	if (err)
+		return err;
+
+	/* 10: Reset the  MAC clock domain */
+	if (high_spd_dev) {
+		spx5_inst_rmw(DEV10G_DEV_RST_CTRL_PCS_TX_RST_SET(1) |
+			      DEV10G_DEV_RST_CTRL_MAC_RX_RST_SET(1) |
+			      DEV10G_DEV_RST_CTRL_MAC_TX_RST_SET(1),
+			      DEV10G_DEV_RST_CTRL_PCS_TX_RST |
+			      DEV10G_DEV_RST_CTRL_MAC_RX_RST |
+			      DEV10G_DEV_RST_CTRL_MAC_TX_RST,
+			      devinst,
+			      DEV10G_DEV_RST_CTRL(0));
+
+	} else {
+		spx5_inst_rmw(DEV2G5_DEV_RST_CTRL_SPEED_SEL_SET(3) |
+			      DEV2G5_DEV_RST_CTRL_PCS_TX_RST_SET(1) |
+			      DEV2G5_DEV_RST_CTRL_PCS_RX_RST_SET(1) |
+			      DEV2G5_DEV_RST_CTRL_MAC_TX_RST_SET(1) |
+			      DEV2G5_DEV_RST_CTRL_MAC_RX_RST_SET(1),
+			      DEV2G5_DEV_RST_CTRL_SPEED_SEL |
+			      DEV2G5_DEV_RST_CTRL_PCS_TX_RST |
+			      DEV2G5_DEV_RST_CTRL_PCS_RX_RST |
+			      DEV2G5_DEV_RST_CTRL_MAC_TX_RST |
+			      DEV2G5_DEV_RST_CTRL_MAC_RX_RST,
+			      devinst,
+			      DEV2G5_DEV_RST_CTRL(0));
+	}
+	/* 11: Clear flushing */
+	spx5_rmw(HSCH_FLUSH_CTRL_FLUSH_PORT_SET(port->portno) |
+		 HSCH_FLUSH_CTRL_FLUSH_ENA_SET(0),
+		 HSCH_FLUSH_CTRL_FLUSH_PORT |
+		 HSCH_FLUSH_CTRL_FLUSH_ENA,
+		 sparx5,
+		 HSCH_FLUSH_CTRL);
+
+	if (high_spd_dev) {
+		u32 pcs = sparx5_to_pcs_dev(port->portno);
+		void __iomem *pcsinst = spx5_inst_get(sparx5, pcs, tinst);
+
+		/* 12: Disable 5G/10G/25 BaseR PCS */
+		spx5_inst_rmw(PCS10G_BR_PCS_CFG_PCS_ENA_SET(0),
+			      PCS10G_BR_PCS_CFG_PCS_ENA,
+			      pcsinst,
+			      PCS10G_BR_PCS_CFG(0));
+
+		if (sparx5_port_is_25g(port->portno))
+			/* Disable 25G PCS */
+			spx5_rmw(DEV25G_PCS25G_CFG_PCS25G_ENA_SET(0),
+				 DEV25G_PCS25G_CFG_PCS25G_ENA,
+				 sparx5,
+				 DEV25G_PCS25G_CFG(tinst));
+	} else {
+		/* 12: Disable 1G PCS */
+		spx5_rmw(DEV2G5_PCS1G_CFG_PCS_ENA_SET(0),
+			 DEV2G5_PCS1G_CFG_PCS_ENA,
+			 sparx5,
+			 DEV2G5_PCS1G_CFG(port->portno));
+	}
+
+	/* The port is now flushed and disabled  */
+	return 0;
+}
+
+static int sparx5_port_fifo_sz(struct sparx5 *sparx5,
+			       u32 portno, u32 speed)
+{
+	u32 sys_clk = sparx5_clk_period(sparx5->coreclock);
+	const u32 taxi_dist[SPX5_PORTS_ALL] = {
+		6, 8, 10, 6, 8, 10, 6, 8, 10, 6, 8, 10,
+		4, 4, 4, 4,
+		11, 12, 13, 14, 15, 16, 17, 18,
+		11, 12, 13, 14, 15, 16, 17, 18,
+		11, 12, 13, 14, 15, 16, 17, 18,
+		11, 12, 13, 14, 15, 16, 17, 18,
+		4, 6, 8, 4, 6, 8, 6, 8,
+		2, 2, 2, 2, 2, 2, 2, 4, 2
+	};
+	u32 mac_per    = 6400, tmp1, tmp2, tmp3;
+	u32 fifo_width = 16;
+	u32 mac_width  = 8;
+	u32 addition   = 0;
+
+	switch (speed) {
+	case SPEED_25000:
+		return 0;
+	case SPEED_10000:
+		mac_per = 6400;
+		mac_width = 8;
+		addition = 1;
+		break;
+	case SPEED_5000:
+		mac_per = 12800;
+		mac_width = 8;
+		addition = 0;
+		break;
+	case SPEED_2500:
+		mac_per = 3200;
+		mac_width = 1;
+		addition = 0;
+		break;
+	case SPEED_1000:
+		mac_per =  8000;
+		mac_width = 1;
+		addition = 0;
+		break;
+	case SPEED_100:
+	case SPEED_10:
+		return 1;
+	default:
+		break;
+	}
+
+	tmp1 = 1000 * mac_width / fifo_width;
+	tmp2 = 3000 + ((12000 + 2 * taxi_dist[portno] * 1000)
+		       * sys_clk / mac_per);
+	tmp3 = tmp1 * tmp2 / 1000;
+	return  (tmp3 + 2000 + 999) / 1000 + addition;
+}
+
+/* Configure port muxing:
+ * QSGMII:     4x2G5 devices
+ */
+static int sparx5_port_mux_set(struct sparx5 *sparx5,
+			       struct sparx5_port *port,
+			       struct sparx5_port_config *conf)
+{
+	u32 portno = port->portno;
+	u32 inst;
+
+	if (port->conf.portmode == conf->portmode)
+		return 0; /* Nothing to do */
+
+	switch (conf->portmode) {
+	case PHY_INTERFACE_MODE_QSGMII: /* QSGMII: 4x2G5 devices. Mode Q'  */
+		inst = (portno - portno % 4) / 4;
+		spx5_rmw(BIT(inst),
+			 BIT(inst),
+			 sparx5,
+			 PORT_CONF_QSGMII_ENA);
+
+		if ((portno / 4 % 2) == 0) {
+			/* Affects d0-d3,d8-d11..d40-d43 */
+			spx5_rmw(PORT_CONF_USGMII_CFG_BYPASS_SCRAM_SET(1) |
+				 PORT_CONF_USGMII_CFG_BYPASS_DESCRAM_SET(1) |
+				 PORT_CONF_USGMII_CFG_QUAD_MODE_SET(1),
+				 PORT_CONF_USGMII_CFG_BYPASS_SCRAM |
+				 PORT_CONF_USGMII_CFG_BYPASS_DESCRAM |
+				 PORT_CONF_USGMII_CFG_QUAD_MODE,
+				 sparx5,
+				 PORT_CONF_USGMII_CFG((portno / 8)));
+		}
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static int sparx5_port_max_tags_set(struct sparx5 *sparx5,
+				    struct sparx5_port *port)
+{
+	enum sparx5_port_max_tags max_tags    = port->max_vlan_tags;
+	int tag_ct          = max_tags == SPX5_PORT_MAX_TAGS_ONE ? 1 :
+			      max_tags == SPX5_PORT_MAX_TAGS_TWO ? 2 : 0;
+	bool dtag           = max_tags == SPX5_PORT_MAX_TAGS_TWO;
+	enum sparx5_vlan_port_type vlan_type  = port->vlan_type;
+	bool dotag          = max_tags != SPX5_PORT_MAX_TAGS_NONE;
+	u32 dev             = sparx5_to_high_dev(port->portno);
+	u32 tinst           = sparx5_port_dev_index(port->portno);
+	void __iomem *inst  = spx5_inst_get(sparx5, dev, tinst);
+	u32 etype;
+
+	etype = (vlan_type == SPX5_VLAN_PORT_TYPE_S_CUSTOM ?
+		 port->custom_etype :
+		 vlan_type == SPX5_VLAN_PORT_TYPE_C ?
+		 SPX5_ETYPE_TAG_C : SPX5_ETYPE_TAG_S);
+
+	spx5_wr(DEV2G5_MAC_TAGS_CFG_TAG_ID_SET(etype) |
+		DEV2G5_MAC_TAGS_CFG_PB_ENA_SET(dtag) |
+		DEV2G5_MAC_TAGS_CFG_VLAN_AWR_ENA_SET(dotag) |
+		DEV2G5_MAC_TAGS_CFG_VLAN_LEN_AWR_ENA_SET(dotag),
+		sparx5,
+		DEV2G5_MAC_TAGS_CFG(port->portno));
+
+	if (sparx5_port_is_2g5(port->portno))
+		return 0;
+
+	spx5_inst_rmw(DEV10G_MAC_TAGS_CFG_TAG_ID_SET(etype) |
+		      DEV10G_MAC_TAGS_CFG_TAG_ENA_SET(dotag),
+		      DEV10G_MAC_TAGS_CFG_TAG_ID |
+		      DEV10G_MAC_TAGS_CFG_TAG_ENA,
+		      inst,
+		      DEV10G_MAC_TAGS_CFG(0, 0));
+
+	spx5_inst_rmw(DEV10G_MAC_NUM_TAGS_CFG_NUM_TAGS_SET(tag_ct),
+		      DEV10G_MAC_NUM_TAGS_CFG_NUM_TAGS,
+		      inst,
+		      DEV10G_MAC_NUM_TAGS_CFG(0));
+
+	spx5_inst_rmw(DEV10G_MAC_MAXLEN_CFG_MAX_LEN_TAG_CHK_SET(dotag),
+		      DEV10G_MAC_MAXLEN_CFG_MAX_LEN_TAG_CHK,
+		      inst,
+		      DEV10G_MAC_MAXLEN_CFG(0));
+	return 0;
+}
+
+static int sparx5_port_fwd_urg(struct sparx5 *sparx5, u32 speed)
+{
+	u32 clk_period_ps = 1600; /* 625Mhz for now */
+	u32 urg = 672000;
+
+	switch (speed) {
+	case SPEED_10:
+	case SPEED_100:
+	case SPEED_1000:
+		urg = 672000;
+		break;
+	case SPEED_2500:
+		urg = 270000;
+		break;
+	case SPEED_5000:
+		urg = 135000;
+		break;
+	case SPEED_10000:
+		urg = 67200;
+		break;
+	case SPEED_25000:
+		urg = 27000;
+		break;
+	}
+	return urg / clk_period_ps - 1;
+}
+
+static u16 sparx5_wm_enc(u16 value)
+{
+	if (value >= 2048)
+		return 2048 + value / 16;
+
+	return value;
+}
+
+static int sparx5_port_fc_setup(struct sparx5 *sparx5,
+				struct sparx5_port *port,
+				struct sparx5_port_config *conf)
+{
+	bool fc_obey = conf->pause & MLO_PAUSE_RX ? 1 : 0;
+	u32 pause_stop = 0xFFF - 1; /* FC gen disabled */
+
+	if (conf->pause & MLO_PAUSE_TX)
+		pause_stop = sparx5_wm_enc(4  * (ETH_MAXLEN /
+						 SPX5_BUFFER_CELL_SZ));
+
+	/* Set HDX flowcontrol */
+	spx5_rmw(DSM_MAC_CFG_HDX_BACKPREASSURE_SET(conf->duplex == DUPLEX_HALF),
+		 DSM_MAC_CFG_HDX_BACKPREASSURE,
+		 sparx5,
+		 DSM_MAC_CFG(port->portno));
+
+	/* Obey flowcontrol  */
+	spx5_rmw(DSM_RX_PAUSE_CFG_RX_PAUSE_EN_SET(fc_obey),
+		 DSM_RX_PAUSE_CFG_RX_PAUSE_EN,
+		 sparx5,
+		 DSM_RX_PAUSE_CFG(port->portno));
+
+	/* Disable forward pressure */
+	spx5_rmw(QSYS_FWD_PRESSURE_FWD_PRESSURE_DIS_SET(fc_obey),
+		 QSYS_FWD_PRESSURE_FWD_PRESSURE_DIS,
+		 sparx5,
+		 QSYS_FWD_PRESSURE(port->portno));
+
+	/* Generate pause frames */
+	spx5_rmw(QSYS_PAUSE_CFG_PAUSE_STOP_SET(pause_stop),
+		 QSYS_PAUSE_CFG_PAUSE_STOP,
+		 sparx5,
+		 QSYS_PAUSE_CFG(port->portno));
+
+	return 0;
+}
+
+static u16 sparx5_get_aneg_word(struct sparx5_port_config *conf)
+{
+	if (conf->portmode == PHY_INTERFACE_MODE_1000BASEX) /* cl-37 aneg */
+		return (ADVERTISE_LPACK |
+		(conf->pause == MLO_PAUSE_AN ? ADVERTISE_1000XPAUSE : 0)  |
+		(conf->pause == MLO_PAUSE_AN ? ADVERTISE_1000XPSE_ASYM : 0) |
+		ADVERTISE_1000XFULL);
+	else
+		return 1; /* Enable SGMII Aneg */
+}
+
+int sparx5_serdes_set(struct sparx5 *sparx5,
+		      struct sparx5_port *port,
+		      struct sparx5_port_config *conf)
+{
+	int err;
+
+	if (conf->portmode == PHY_INTERFACE_MODE_QSGMII &&
+	    ((port->portno % 4) != 0)) {
+		return 0;
+	}
+	err = phy_set_media(port->serdes, conf->media);
+	if (err)
+		return err;
+	if (conf->speed > 0) {
+		err = phy_set_speed(port->serdes, conf->speed);
+		if (err)
+			return err;
+	}
+	if (conf->serdes_reset) {
+		err = phy_reset(port->serdes);
+		if (err)
+			return err;
+	}
+	/* Configure SerDes with port parameters */
+	err = phy_set_mode_ext(port->serdes, PHY_MODE_ETHERNET, conf->portmode);
+	if (err)
+		return err;
+	conf->serdes_reset = false;
+	return err;
+}
+
+static int sparx5_port_pcs_low_set(struct sparx5 *sparx5,
+				   struct sparx5_port *port,
+				   struct sparx5_port_config *conf)
+{
+	bool sgmii = false, inband_aneg = false;
+	int err;
+
+	if (!port->conf.has_sfp) {
+		sgmii = true; /* Phy is connnected to the MAC */
+	} else {
+		if (conf->portmode == PHY_INTERFACE_MODE_SGMII ||
+		    conf->portmode == PHY_INTERFACE_MODE_QSGMII)
+			inband_aneg = true; /* Cisco-SGMII in-band-aneg */
+		else if (conf->portmode == PHY_INTERFACE_MODE_1000BASEX &&
+			 conf->autoneg)
+			inband_aneg = true; /* Clause-37 in-band-aneg */
+
+		err = sparx5_serdes_set(sparx5, port, conf);
+		if (err)
+			return -EINVAL;
+	}
+
+	/* Choose SGMII or 1000BaseX/2500BaseX PCS mode */
+	spx5_rmw(DEV2G5_PCS1G_MODE_CFG_SGMII_MODE_ENA_SET(sgmii),
+		 DEV2G5_PCS1G_MODE_CFG_SGMII_MODE_ENA,
+		 sparx5,
+		 DEV2G5_PCS1G_MODE_CFG(port->portno));
+
+	/* Enable PCS */
+	spx5_wr(DEV2G5_PCS1G_CFG_PCS_ENA_SET(1),
+		sparx5,
+		DEV2G5_PCS1G_CFG(port->portno));
+
+	if (inband_aneg) {
+		u16 abil = sparx5_get_aneg_word(conf);
+
+		/* Enable in-band aneg */
+		spx5_wr(DEV2G5_PCS1G_ANEG_CFG_ADV_ABILITY_SET(abil) |
+			DEV2G5_PCS1G_ANEG_CFG_SW_RESOLVE_ENA_SET(1) |
+			DEV2G5_PCS1G_ANEG_CFG_ANEG_ENA_SET(1) |
+			DEV2G5_PCS1G_ANEG_CFG_ANEG_RESTART_ONE_SHOT_SET(1),
+			sparx5,
+			DEV2G5_PCS1G_ANEG_CFG(port->portno));
+	} else {
+		spx5_wr(0, sparx5, DEV2G5_PCS1G_ANEG_CFG(port->portno));
+	}
+
+	/* Take PCS out of reset */
+	spx5_rmw(DEV2G5_DEV_RST_CTRL_SPEED_SEL_SET(2) |
+		 DEV2G5_DEV_RST_CTRL_PCS_TX_RST_SET(0) |
+		 DEV2G5_DEV_RST_CTRL_PCS_RX_RST_SET(0),
+		 DEV2G5_DEV_RST_CTRL_SPEED_SEL |
+		 DEV2G5_DEV_RST_CTRL_PCS_TX_RST |
+		 DEV2G5_DEV_RST_CTRL_PCS_RX_RST,
+		 sparx5,
+		 DEV2G5_DEV_RST_CTRL(port->portno));
+
+	return 0;
+}
+
+static int sparx5_port_pcs_high_set(struct sparx5 *sparx5,
+				    struct sparx5_port *port,
+				    struct sparx5_port_config *conf)
+{
+	u32 clk_spd = conf->speed == SPEED_5000 ? 1 : 0;
+	u32 pix = sparx5_port_dev_index(port->portno);
+	u32 dev = sparx5_to_high_dev(port->portno);
+	u32 pcs = sparx5_to_pcs_dev(port->portno);
+	void __iomem *devinst;
+	void __iomem *pcsinst;
+	int err;
+
+	devinst = spx5_inst_get(sparx5, dev, pix);
+	pcsinst = spx5_inst_get(sparx5, pcs, pix);
+
+	/*  SFI : No in-band-aneg. Speeds 5G/10G/25G */
+	err = sparx5_serdes_set(sparx5, port, conf);
+	if (err)
+		return -EINVAL;
+
+	if (conf->speed == SPEED_25000) {
+		/* Enable PCS for 25G device, speed 25G */
+		spx5_rmw(DEV25G_PCS25G_CFG_PCS25G_ENA_SET(1),
+			 DEV25G_PCS25G_CFG_PCS25G_ENA,
+			 sparx5,
+			 DEV25G_PCS25G_CFG(pix));
+	} else {
+		/* Enable PCS for 5G/10G/25G devices, speed 5G/10G */
+		spx5_inst_rmw(PCS10G_BR_PCS_CFG_PCS_ENA_SET(1),
+			      PCS10G_BR_PCS_CFG_PCS_ENA,
+			      pcsinst,
+			      PCS10G_BR_PCS_CFG(0));
+	}
+
+	/* Enable 5G/10G/25G MAC module */
+	spx5_inst_wr(DEV10G_MAC_ENA_CFG_RX_ENA_SET(1) |
+		     DEV10G_MAC_ENA_CFG_TX_ENA_SET(1),
+		     devinst,
+		     DEV10G_MAC_ENA_CFG(0));
+
+	/* Take the device out of reset */
+	spx5_inst_rmw(DEV10G_DEV_RST_CTRL_PCS_RX_RST_SET(0) |
+		      DEV10G_DEV_RST_CTRL_PCS_TX_RST_SET(0) |
+		      DEV10G_DEV_RST_CTRL_MAC_RX_RST_SET(0) |
+		      DEV10G_DEV_RST_CTRL_MAC_TX_RST_SET(0) |
+		      DEV10G_DEV_RST_CTRL_SPEED_SEL_SET(clk_spd),
+		      DEV10G_DEV_RST_CTRL_PCS_RX_RST |
+		      DEV10G_DEV_RST_CTRL_PCS_TX_RST |
+		      DEV10G_DEV_RST_CTRL_MAC_RX_RST |
+		      DEV10G_DEV_RST_CTRL_MAC_TX_RST |
+		      DEV10G_DEV_RST_CTRL_SPEED_SEL,
+		      devinst,
+		      DEV10G_DEV_RST_CTRL(0));
+
+	return 0;
+}
+
+/* Switch between 1G/2500 and 5G/10G/25G devices */
+static void sparx5_dev_switch(struct sparx5 *sparx5, int port, bool hsd)
+{
+	int bt_indx = BIT(sparx5_port_dev_index(port));
+
+	if (sparx5_port_is_5g(port)) {
+		spx5_rmw(hsd ? 0 : bt_indx,
+			 bt_indx,
+			 sparx5,
+			 PORT_CONF_DEV5G_MODES);
+	} else if (sparx5_port_is_10g(port)) {
+		spx5_rmw(hsd ? 0 : bt_indx,
+			 bt_indx,
+			 sparx5,
+			 PORT_CONF_DEV10G_MODES);
+	} else if (sparx5_port_is_25g(port)) {
+		spx5_rmw(hsd ? 0 : bt_indx,
+			 bt_indx,
+			 sparx5,
+			 PORT_CONF_DEV25G_MODES);
+	}
+}
+
+/* Configure speed/duplex dependent registers */
+static int sparx5_port_config_low_set(struct sparx5 *sparx5,
+				      struct sparx5_port *port,
+				      struct sparx5_port_config *conf)
+{
+	u32 clk_spd, gig_mode, tx_gap, hdx_gap_1, hdx_gap_2;
+	bool fdx = conf->duplex == DUPLEX_FULL;
+	int spd = conf->speed;
+
+	clk_spd = spd == SPEED_10 ? 0 : spd == SPEED_100 ? 1 : 2;
+	gig_mode = spd == SPEED_1000 || spd == SPEED_2500;
+	tx_gap = spd == SPEED_1000 ? 4 : fdx ? 6 : 5;
+	hdx_gap_1 = spd == SPEED_1000 ? 0 : spd == SPEED_100 ? 1 : 2;
+	hdx_gap_2 = spd == SPEED_1000 ? 0 : spd == SPEED_100 ? 4 : 1;
+
+	/* GIG/FDX mode */
+	spx5_rmw(DEV2G5_MAC_MODE_CFG_GIGA_MODE_ENA_SET(gig_mode) |
+		 DEV2G5_MAC_MODE_CFG_FDX_ENA_SET(fdx),
+		 DEV2G5_MAC_MODE_CFG_GIGA_MODE_ENA |
+		 DEV2G5_MAC_MODE_CFG_FDX_ENA,
+		 sparx5,
+		 DEV2G5_MAC_MODE_CFG(port->portno));
+
+	/* Set MAC IFG Gaps */
+	spx5_wr(DEV2G5_MAC_IFG_CFG_TX_IFG_SET(tx_gap) |
+		DEV2G5_MAC_IFG_CFG_RX_IFG1_SET(hdx_gap_1) |
+		DEV2G5_MAC_IFG_CFG_RX_IFG2_SET(hdx_gap_2),
+		sparx5,
+		DEV2G5_MAC_IFG_CFG(port->portno));
+
+	/* Disabling frame aging when in HDX (due to HDX issue) */
+	spx5_rmw(HSCH_PORT_MODE_AGE_DIS_SET(fdx == 0),
+		 HSCH_PORT_MODE_AGE_DIS,
+		 sparx5,
+		 HSCH_PORT_MODE(port->portno));
+
+	/* Enable MAC module */
+	spx5_wr(DEV2G5_MAC_ENA_CFG_RX_ENA |
+		DEV2G5_MAC_ENA_CFG_TX_ENA,
+		sparx5,
+		DEV2G5_MAC_ENA_CFG(port->portno));
+
+	/* Select speed and take MAC out of reset */
+	spx5_rmw(DEV2G5_DEV_RST_CTRL_SPEED_SEL_SET(clk_spd) |
+		 DEV2G5_DEV_RST_CTRL_MAC_TX_RST_SET(0) |
+		 DEV2G5_DEV_RST_CTRL_MAC_RX_RST_SET(0),
+		 DEV2G5_DEV_RST_CTRL_SPEED_SEL |
+		 DEV2G5_DEV_RST_CTRL_MAC_TX_RST |
+		 DEV2G5_DEV_RST_CTRL_MAC_RX_RST,
+		 sparx5,
+		 DEV2G5_DEV_RST_CTRL(port->portno));
+
+	return 0;
+}
+
+int sparx5_port_pcs_set(struct sparx5 *sparx5,
+			struct sparx5_port *port,
+			struct sparx5_port_config *conf)
+
+{
+	bool high_speed_dev = sparx5_is_high_speed_device(conf);
+	int err;
+
+	if (sparx5_dev_change(sparx5, port, conf)) {
+		/* switch device */
+		sparx5_dev_switch(sparx5, port->portno, high_speed_dev);
+
+		/* Disable the not-in-use device */
+		err = sparx5_port_disable(sparx5, port, !high_speed_dev);
+		if (err)
+			return err;
+	}
+	/* Disable the port before re-configuring */
+	err = sparx5_port_disable(sparx5, port, high_speed_dev);
+	if (err)
+		return -EINVAL;
+
+	if (high_speed_dev)
+		err = sparx5_port_pcs_high_set(sparx5, port, conf);
+	else
+		err = sparx5_port_pcs_low_set(sparx5, port, conf);
+
+	if (err)
+		return -EINVAL;
+
+	if (port->conf.has_sfp) {
+		/* Enable/disable 1G counters in ASM */
+		spx5_rmw(ASM_PORT_CFG_CSC_STAT_DIS_SET(high_speed_dev),
+			 ASM_PORT_CFG_CSC_STAT_DIS,
+			 sparx5,
+			 ASM_PORT_CFG(port->portno));
+
+		/* Enable/disable 1G counters in DSM */
+		spx5_rmw(DSM_BUF_CFG_CSC_STAT_DIS_SET(high_speed_dev),
+			 DSM_BUF_CFG_CSC_STAT_DIS,
+			 sparx5,
+			 DSM_BUF_CFG(port->portno));
+	}
+
+	port->conf = *conf;
+
+	return 0;
+}
+
+int sparx5_port_config(struct sparx5 *sparx5,
+		       struct sparx5_port *port,
+		       struct sparx5_port_config *conf)
+{
+	bool high_speed_dev = sparx5_is_high_speed_device(conf);
+	int err, urgency, stop_wm;
+
+	err = sparx5_port_verify_speed(sparx5, port, conf);
+	if (err)
+		return err;
+
+	/* high speed device is already configured */
+	if (!high_speed_dev)
+		sparx5_port_config_low_set(sparx5, port, conf);
+
+	/* Configure flow control */
+	err = sparx5_port_fc_setup(sparx5, port, conf);
+	if (err)
+		return err;
+
+	/* Set the DSM stop watermark */
+	stop_wm = sparx5_port_fifo_sz(sparx5, port->portno, conf->speed);
+	spx5_rmw(DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM_SET(stop_wm),
+		 DSM_DEV_TX_STOP_WM_CFG_DEV_TX_STOP_WM,
+		 sparx5,
+		 DSM_DEV_TX_STOP_WM_CFG(port->portno));
+
+	/* Enable port in queue system */
+	urgency = sparx5_port_fwd_urg(sparx5, conf->speed);
+	spx5_rmw(QFWD_SWITCH_PORT_MODE_PORT_ENA_SET(1) |
+		 QFWD_SWITCH_PORT_MODE_FWD_URGENCY_SET(urgency),
+		 QFWD_SWITCH_PORT_MODE_PORT_ENA |
+		 QFWD_SWITCH_PORT_MODE_FWD_URGENCY,
+		 sparx5,
+		 QFWD_SWITCH_PORT_MODE(port->portno));
+
+	/* Save the new values */
+	port->conf = *conf;
+
+	return 0;
+}
+
+/* Initialize port config to default */
+int sparx5_port_init(struct sparx5 *sparx5,
+		     struct sparx5_port *port,
+		     struct sparx5_port_config *conf)
+{
+	u32 pause_start = sparx5_wm_enc(6  * (ETH_MAXLEN / SPX5_BUFFER_CELL_SZ));
+	u32 atop = sparx5_wm_enc(20 * (ETH_MAXLEN / SPX5_BUFFER_CELL_SZ));
+	u32 devhigh = sparx5_to_high_dev(port->portno);
+	u32 pix = sparx5_port_dev_index(port->portno);
+	u32 pcs = sparx5_to_pcs_dev(port->portno);
+	bool sd_pol = port->signd_active_high;
+	bool sd_sel = !port->signd_internal;
+	bool sd_ena = port->signd_enable;
+	u32 pause_stop = 0xFFF - 1; /* FC generate disabled */
+	void __iomem *devinst;
+	void __iomem *pcsinst;
+	int err;
+
+	devinst = spx5_inst_get(sparx5, devhigh, pix);
+	pcsinst = spx5_inst_get(sparx5, pcs, pix);
+
+	/* Set the mux port mode  */
+	err = sparx5_port_mux_set(sparx5, port, conf);
+	if (err)
+		return err;
+
+	/* Configure MAC vlan awareness */
+	err = sparx5_port_max_tags_set(sparx5, port);
+	if (err)
+		return err;
+
+	/* Set Max Length */
+	spx5_rmw(DEV2G5_MAC_MAXLEN_CFG_MAX_LEN_SET(ETH_MAXLEN),
+		 DEV2G5_MAC_MAXLEN_CFG_MAX_LEN,
+		 sparx5,
+		 DEV2G5_MAC_MAXLEN_CFG(port->portno));
+
+	/* 1G/2G5: Signal Detect configuration */
+	spx5_wr(DEV2G5_PCS1G_SD_CFG_SD_POL_SET(sd_pol) |
+		DEV2G5_PCS1G_SD_CFG_SD_SEL_SET(sd_sel) |
+		DEV2G5_PCS1G_SD_CFG_SD_ENA_SET(sd_ena),
+		sparx5,
+		DEV2G5_PCS1G_SD_CFG(port->portno));
+
+	/* Set Pause WM hysteresis */
+	spx5_rmw(QSYS_PAUSE_CFG_PAUSE_START_SET(pause_start) |
+		 QSYS_PAUSE_CFG_PAUSE_STOP_SET(pause_stop) |
+		 QSYS_PAUSE_CFG_PAUSE_ENA_SET(1),
+		 QSYS_PAUSE_CFG_PAUSE_START |
+		 QSYS_PAUSE_CFG_PAUSE_STOP |
+		 QSYS_PAUSE_CFG_PAUSE_ENA,
+		 sparx5,
+		 QSYS_PAUSE_CFG(port->portno));
+
+	/* Port ATOP. Frames are tail dropped when this WM is hit */
+	spx5_wr(QSYS_ATOP_ATOP_SET(atop),
+		sparx5,
+		QSYS_ATOP(port->portno));
+
+	/* Discard pause frame 01-80-C2-00-00-01 */
+	spx5_wr(PAUSE_DISCARD, sparx5, ANA_CL_CAPTURE_BPDU_CFG(port->portno));
+
+	if (conf->portmode == PHY_INTERFACE_MODE_QSGMII ||
+	    conf->portmode == PHY_INTERFACE_MODE_SGMII) {
+		err = sparx5_serdes_set(sparx5, port, conf);
+		if (err)
+			return err;
+
+		if (!sparx5_port_is_2g5(port->portno))
+			/* Enable shadow device */
+			spx5_rmw(DSM_DEV_TX_STOP_WM_CFG_DEV10G_SHADOW_ENA_SET(1),
+				 DSM_DEV_TX_STOP_WM_CFG_DEV10G_SHADOW_ENA,
+				 sparx5,
+				 DSM_DEV_TX_STOP_WM_CFG(port->portno));
+
+		sparx5_dev_switch(sparx5, port->portno, false);
+	}
+	if (conf->portmode == PHY_INTERFACE_MODE_QSGMII) {
+		// All ports must be PCS enabled in QSGMII mode
+		spx5_rmw(DEV2G5_DEV_RST_CTRL_PCS_TX_RST_SET(0),
+			 DEV2G5_DEV_RST_CTRL_PCS_TX_RST,
+			 sparx5,
+			 DEV2G5_DEV_RST_CTRL(port->portno));
+	}
+	/* Default IFGs for 1G */
+	spx5_wr(DEV2G5_MAC_IFG_CFG_TX_IFG_SET(6) |
+		DEV2G5_MAC_IFG_CFG_RX_IFG1_SET(0) |
+		DEV2G5_MAC_IFG_CFG_RX_IFG2_SET(0),
+		sparx5,
+		DEV2G5_MAC_IFG_CFG(port->portno));
+
+	if (sparx5_port_is_2g5(port->portno))
+		return 0; /* Low speed device only - return */
+
+	/* Now setup the high speed device */
+	if (conf->portmode == PHY_INTERFACE_MODE_NA)
+		conf->portmode = PHY_INTERFACE_MODE_10GBASER;
+
+	if (sparx5_is_high_speed_device(conf))
+		sparx5_dev_switch(sparx5, port->portno, true);
+
+	/* Set Max Length */
+	spx5_inst_rmw(DEV10G_MAC_MAXLEN_CFG_MAX_LEN_SET(ETH_MAXLEN),
+		      DEV10G_MAC_MAXLEN_CFG_MAX_LEN,
+		      devinst,
+		      DEV10G_MAC_ENA_CFG(0));
+
+	/* Handle Signal Detect in 10G PCS */
+	spx5_inst_wr(PCS10G_BR_PCS_SD_CFG_SD_POL_SET(sd_pol) |
+		     PCS10G_BR_PCS_SD_CFG_SD_SEL_SET(sd_sel) |
+		     PCS10G_BR_PCS_SD_CFG_SD_ENA_SET(sd_ena),
+		     pcsinst,
+		     PCS10G_BR_PCS_SD_CFG(0));
+
+	if (sparx5_port_is_25g(port->portno)) {
+		/* Handle Signal Detect in 25G PCS */
+		spx5_wr(DEV25G_PCS25G_SD_CFG_SD_POL_SET(sd_pol) |
+			DEV25G_PCS25G_SD_CFG_SD_SEL_SET(sd_sel) |
+			DEV25G_PCS25G_SD_CFG_SD_ENA_SET(sd_ena),
+			sparx5,
+			DEV25G_PCS25G_SD_CFG(pix));
+	}
+
+	return 0;
+}
+
+void sparx5_port_enable(struct sparx5_port *port, bool enable)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+
+	/* Enable port for frame transfer? */
+	spx5_rmw(QFWD_SWITCH_PORT_MODE_PORT_ENA_SET(enable),
+		 QFWD_SWITCH_PORT_MODE_PORT_ENA,
+		 sparx5,
+		 QFWD_SWITCH_PORT_MODE(port->portno));
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_port.h b/drivers/net/ethernet/microchip/sparx5/sparx5_port.h
new file mode 100644
index 000000000000..86214683f86c
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_port.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#ifndef __SPARX5_PORT_H__
+#define __SPARX5_PORT_H__
+
+#include "sparx5_main.h"
+
+static inline bool sparx5_port_is_2g5(int portno)
+{
+	return portno >= 16 && portno <= 47;
+}
+
+static inline bool sparx5_port_is_5g(int portno)
+{
+	return portno <= 11 || portno == 64;
+}
+
+static inline bool sparx5_port_is_10g(int portno)
+{
+	return (portno >= 12 && portno <= 15) || (portno >= 48 && portno <= 55);
+}
+
+static inline bool sparx5_port_is_25g(int portno)
+{
+	return portno >= 56 && portno <= 63;
+}
+
+static inline u32 sparx5_to_high_dev(int port)
+{
+	if (sparx5_port_is_5g(port))
+		return TARGET_DEV5G;
+	if (sparx5_port_is_10g(port))
+		return TARGET_DEV10G;
+	return TARGET_DEV25G;
+}
+
+static inline u32 sparx5_to_pcs_dev(int port)
+{
+	if (sparx5_port_is_5g(port))
+		return TARGET_PCS5G_BR;
+	if (sparx5_port_is_10g(port))
+		return TARGET_PCS10G_BR;
+	return TARGET_PCS25G_BR;
+}
+
+static inline int sparx5_port_dev_index(int port)
+{
+	if (sparx5_port_is_2g5(port))
+		return port;
+	if (sparx5_port_is_5g(port))
+		return (port <= 11 ? port : 12);
+	if (sparx5_port_is_10g(port))
+		return (port >= 12 && port <= 15) ?
+			port - 12 : port - 44;
+	return (port - 56);
+}
+
+static inline bool sparx5_is_high_speed_device(struct sparx5_port_config *conf)
+{
+	return conf->portmode == PHY_INTERFACE_MODE_10GBASER;
+}
+
+int sparx5_port_init(struct sparx5 *sparx5,
+		     struct sparx5_port *spx5_port,
+		     struct sparx5_port_config *conf);
+
+int sparx5_port_config(struct sparx5 *sparx5,
+		       struct sparx5_port *spx5_port,
+		       struct sparx5_port_config *conf);
+
+int sparx5_port_pcs_set(struct sparx5 *sparx5,
+			struct sparx5_port *port,
+			struct sparx5_port_config *conf);
+
+int sparx5_serdes_set(struct sparx5 *sparx5,
+		      struct sparx5_port *spx5_port,
+		      struct sparx5_port_config *conf);
+
+struct sparx5_port_status {
+	bool link;
+	bool link_down;
+	int  speed;
+	bool an_complete;
+	int  duplex;
+	int  pause;
+};
+
+int sparx5_get_port_status(struct sparx5 *sparx5,
+			   struct sparx5_port *port,
+			   struct sparx5_port_status *status);
+
+void sparx5_port_enable(struct sparx5_port *port, bool enable);
+
+#endif	/* __SPARX5_PORT_H__ */
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:52 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:52 +0200
Subject: [PATCH net-next 05/10] net: sparx5: add mactable support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-6-steen.hegelund@microchip.com>

This adds the Sparx5 MAC tables: listening for MAC table updates and
updating on request.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   2 +-
 .../microchip/sparx5/sparx5_mactable.c        | 497 ++++++++++++++++++
 .../ethernet/microchip/sparx5/sparx5_main.c   |  21 +-
 .../ethernet/microchip/sparx5/sparx5_main.h   |  26 +
 .../ethernet/microchip/sparx5/sparx5_netdev.c |  21 +
 5 files changed, 565 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index 9c14eec33fd7..4ccb09d275bc 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -6,4 +6,4 @@
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
- sparx5_netdev.o sparx5_port.o sparx5_phylink.o
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
new file mode 100644
index 000000000000..6c5e04eccaa3
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
@@ -0,0 +1,497 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <net/switchdev.h>
+#include <linux/if_bridge.h>
+#include <linux/iopoll.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+/* Commands for Mac Table Command register */
+#define MAC_CMD_LEARN         0 /* Insert (Learn) 1 entry */
+#define MAC_CMD_UNLEARN       1 /* Unlearn (Forget) 1 entry */
+#define MAC_CMD_LOOKUP        2 /* Look up 1 entry */
+#define MAC_CMD_READ          3 /* Read entry at Mac Table Index */
+#define MAC_CMD_WRITE         4 /* Write entry at Mac Table Index */
+#define MAC_CMD_SCAN          5 /* Scan (Age or find next) */
+#define MAC_CMD_FIND_SMALLEST 6 /* Get next entry */
+#define MAC_CMD_CLEAR_ALL     7 /* Delete all entries in table */
+
+/* Commands for MAC_ENTRY_ADDR_TYPE */
+#define  MAC_ENTRY_ADDR_TYPE_UPSID_PN         0
+#define  MAC_ENTRY_ADDR_TYPE_UPSID_CPU_OR_INT 1
+#define  MAC_ENTRY_ADDR_TYPE_GLAG             2
+#define  MAC_ENTRY_ADDR_TYPE_MC_IDX           3
+
+#define TABLE_UPDATE_SLEEP_US 10
+#define TABLE_UPDATE_TIMEOUT_US 100000
+
+struct sparx5_mact_entry {
+	struct list_head list;
+	unsigned char mac[ETH_ALEN];
+	u32 flags;
+#define MAC_ENT_ALIVE	BIT(0)
+#define MAC_ENT_MOVED	BIT(1)
+#define MAC_ENT_LOCK	BIT(2)
+	u16 vid;
+	u16 port;
+};
+
+static int sparx5_mact_get_status(struct sparx5 *sparx5)
+{
+	return spx5_rd(sparx5, LRN_COMMON_ACCESS_CTRL);
+}
+
+static int sparx5_mact_wait_for_completion(struct sparx5 *sparx5)
+{
+	u32 val;
+
+	return readx_poll_timeout(sparx5_mact_get_status,
+		sparx5, val,
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_GET(val) == 0,
+		TABLE_UPDATE_SLEEP_US, TABLE_UPDATE_TIMEOUT_US);
+}
+
+static void sparx5_mact_select(struct sparx5 *sparx5,
+			       const unsigned char mac[ETH_ALEN],
+			       u16 vid)
+{
+	u32 macl = 0, mach = 0;
+
+	/* Set the MAC address to handle and the vlan associated in a format
+	 * understood by the hardware.
+	 */
+	mach |= vid    << 16;
+	mach |= mac[0] << 8;
+	mach |= mac[1] << 0;
+	macl |= mac[2] << 24;
+	macl |= mac[3] << 16;
+	macl |= mac[4] << 8;
+	macl |= mac[5] << 0;
+
+	spx5_wr(mach, sparx5, LRN_MAC_ACCESS_CFG_0);
+	spx5_wr(macl, sparx5, LRN_MAC_ACCESS_CFG_1);
+}
+
+int sparx5_mact_learn(struct sparx5 *sparx5, int pgid,
+		      const unsigned char mac[ETH_ALEN], u16 vid)
+{
+	int addr, type, ret;
+
+	if (pgid < SPX5_PORTS) {
+		type = MAC_ENTRY_ADDR_TYPE_UPSID_PN;
+		addr = pgid % 32;
+		addr += (pgid / 32) << 5; /* Add upsid */
+	} else {
+		type = MAC_ENTRY_ADDR_TYPE_MC_IDX;
+		addr = pgid - SPX5_PORTS;
+	}
+
+	mutex_lock(&sparx5->lock);
+
+	sparx5_mact_select(sparx5, mac, vid);
+
+	/* MAC entry properties */
+	spx5_wr(LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_SET(addr) |
+		LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_TYPE_SET(type) |
+		LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_VLD_SET(1) |
+		LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_LOCKED_SET(1),
+		sparx5, LRN_MAC_ACCESS_CFG_2);
+	spx5_wr(0, sparx5, LRN_MAC_ACCESS_CFG_3);
+
+	/*  Insert/learn new entry */
+	spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET(MAC_CMD_LEARN) |
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+		sparx5, LRN_COMMON_ACCESS_CTRL);
+
+	ret = sparx5_mact_wait_for_completion(sparx5);
+
+	mutex_unlock(&sparx5->lock);
+
+	return ret;
+}
+
+int sparx5_mc_unsync(struct net_device *dev, const unsigned char *addr)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
+
+	return sparx5_mact_forget(sparx5, addr, port->pvid);
+}
+
+int sparx5_mc_sync(struct net_device *dev, const unsigned char *addr)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
+
+	return sparx5_mact_learn(sparx5, PGID_CPU, addr, port->pvid);
+}
+
+static int sparx5_mact_get(struct sparx5 *sparx5,
+			   unsigned char mac[ETH_ALEN],
+			   u16 *vid, u32 *pcfg2)
+{
+	u32 mach, macl, cfg2;
+	int ret = -ENOENT;
+
+	cfg2 = spx5_rd(sparx5, LRN_MAC_ACCESS_CFG_2);
+	if (LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_VLD_GET(cfg2)) {
+		mach = spx5_rd(sparx5, LRN_MAC_ACCESS_CFG_0);
+		macl = spx5_rd(sparx5, LRN_MAC_ACCESS_CFG_1);
+		mac[0] = ((mach >> 8)  & 0xff);
+		mac[1] = ((mach >> 0)  & 0xff);
+		mac[2] = ((macl >> 24) & 0xff);
+		mac[3] = ((macl >> 16) & 0xff);
+		mac[4] = ((macl >> 8)  & 0xff);
+		mac[5] = ((macl >> 0)  & 0xff);
+		*vid = mach >> 16;
+		*pcfg2 = cfg2;
+		ret = 0;
+	}
+
+	return ret;
+}
+
+bool sparx5_mact_getnext(struct sparx5 *sparx5,
+			 unsigned char mac[ETH_ALEN], u16 *vid, u32 *pcfg2)
+{
+	u32 cfg2;
+	int ret;
+
+	mutex_lock(&sparx5->lock);
+
+	sparx5_mact_select(sparx5, mac, *vid);
+
+	spx5_wr(LRN_SCAN_NEXT_CFG_SCAN_NEXT_IGNORE_LOCKED_ENA_SET(1) |
+		LRN_SCAN_NEXT_CFG_SCAN_NEXT_UNTIL_FOUND_ENA_SET(1),
+		sparx5, LRN_SCAN_NEXT_CFG);
+	spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET
+		(MAC_CMD_FIND_SMALLEST) |
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+		sparx5, LRN_COMMON_ACCESS_CTRL);
+
+	ret = sparx5_mact_wait_for_completion(sparx5);
+	if (ret == 0) {
+		ret = sparx5_mact_get(sparx5, mac, vid, &cfg2);
+		if (ret == 0)
+			*pcfg2 = cfg2;
+	}
+
+	mutex_unlock(&sparx5->lock);
+
+	return ret == 0;
+}
+
+static int sparx5_mact_lookup(struct sparx5 *sparx5,
+			      const unsigned char mac[ETH_ALEN],
+			      u16 vid)
+{
+	int ret;
+
+	mutex_lock(&sparx5->lock);
+
+	sparx5_mact_select(sparx5, mac, vid);
+
+	/* Issue a lookup command */
+	spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET(MAC_CMD_LOOKUP) |
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+		sparx5, LRN_COMMON_ACCESS_CTRL);
+
+	ret = sparx5_mact_wait_for_completion(sparx5);
+	if (ret)
+		goto out;
+
+	ret = LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_VLD_GET
+		(spx5_rd(sparx5, LRN_MAC_ACCESS_CFG_2));
+
+out:
+	mutex_unlock(&sparx5->lock);
+
+	return ret;
+}
+
+int sparx5_mact_forget(struct sparx5 *sparx5,
+		       const unsigned char mac[ETH_ALEN], u16 vid)
+{
+	int ret;
+
+	mutex_lock(&sparx5->lock);
+
+	sparx5_mact_select(sparx5, mac, vid);
+
+	/* Issue an unlearn command */
+	spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET(MAC_CMD_UNLEARN) |
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+		sparx5, LRN_COMMON_ACCESS_CTRL);
+
+	ret = sparx5_mact_wait_for_completion(sparx5);
+
+	mutex_unlock(&sparx5->lock);
+
+	return ret;
+}
+
+static struct sparx5_mact_entry *alloc_mact_entry(struct sparx5 *sparx5,
+						  const unsigned char *mac,
+						  u16 vid, u16 port_index)
+{
+	struct sparx5_mact_entry *mact_entry;
+
+	mact_entry = devm_kzalloc(sparx5->dev,
+				  sizeof(*mact_entry), GFP_ATOMIC);
+	if (!mact_entry)
+		return NULL;
+
+	memcpy(mact_entry->mac, mac, ETH_ALEN);
+	mact_entry->vid = vid;
+	mact_entry->port = port_index;
+	return mact_entry;
+}
+
+static struct sparx5_mact_entry *find_mact_entry(struct sparx5 *sparx5,
+						 const unsigned char *mac,
+						 u16 vid, u16 port_index)
+{
+	struct sparx5_mact_entry *mact_entry;
+	struct sparx5_mact_entry *res = NULL;
+
+	mutex_lock(&sparx5->mact_lock);
+	list_for_each_entry(mact_entry, &sparx5->mact_entries, list) {
+		if (mact_entry->vid == vid &&
+		    ether_addr_equal(mac, mact_entry->mac) &&
+		    mact_entry->port == port_index) {
+			res = mact_entry;
+			break;
+		}
+	}
+	mutex_unlock(&sparx5->mact_lock);
+
+	return res;
+}
+
+static void sparx5_fdb_call_notifiers(enum switchdev_notifier_type type,
+				      const char *mac, u16 vid,
+				      struct net_device *dev, bool offloaded)
+{
+	struct switchdev_notifier_fdb_info info;
+
+	info.addr = mac;
+	info.vid = vid;
+	info.offloaded = offloaded;
+	call_switchdev_notifiers(type, dev, &info.info, NULL);
+}
+
+int sparx5_add_mact_entry(struct sparx5 *sparx5,
+			  struct sparx5_port *port,
+			  const unsigned char *addr, u16 vid)
+{
+	struct sparx5_mact_entry *mact_entry;
+	int ret;
+
+	ret = sparx5_mact_lookup(sparx5, addr, vid);
+	if (ret)
+		return 0;
+
+	/* In case the entry already exists, don't add it again to SW,
+	 * just update HW, but we need to look in the actual HW because
+	 * it is possible for an entry to be learn by HW and before the
+	 * mact thread to start the frame will reach CPU and the CPU will
+	 * add the entry but without the extern_learn flag.
+	 */
+	mact_entry = find_mact_entry(sparx5, addr, vid, port->portno);
+	if (mact_entry)
+		goto update_hw;
+
+	/* Add the entry in SW MAC table not to get the notification when
+	 * SW is pulling again
+	 */
+	mact_entry = alloc_mact_entry(sparx5, addr, vid, port->portno);
+	if (!mact_entry)
+		return -ENOMEM;
+
+	mutex_lock(&sparx5->mact_lock);
+	list_add_tail(&mact_entry->list, &sparx5->mact_entries);
+	mutex_unlock(&sparx5->mact_lock);
+
+update_hw:
+	ret = sparx5_mact_learn(sparx5, port->portno, addr, vid);
+
+	/* New entry? */
+	if (mact_entry->flags == 0) {
+		mact_entry->flags |= MAC_ENT_LOCK; /* Don't age this */
+		sparx5_fdb_call_notifiers(SWITCHDEV_FDB_ADD_TO_BRIDGE, addr, vid,
+					  port->ndev, true);
+	}
+
+	return ret;
+}
+
+int sparx5_del_mact_entry(struct sparx5 *sparx5,
+			  const unsigned char *addr,
+			  u16 vid)
+{
+	struct sparx5_mact_entry *mact_entry, *tmp;
+
+	/* Delete the entry in SW MAC table not to get the notification when
+	 * SW is pulling again
+	 */
+	mutex_lock(&sparx5->mact_lock);
+	list_for_each_entry_safe(mact_entry, tmp, &sparx5->mact_entries,
+				 list) {
+		if ((vid == 0 || mact_entry->vid == vid) &&
+		    ether_addr_equal(addr, mact_entry->mac)) {
+			list_del(&mact_entry->list);
+			devm_kfree(sparx5->dev, mact_entry);
+
+			sparx5_mact_forget(sparx5, addr, mact_entry->vid);
+		}
+	}
+	mutex_unlock(&sparx5->mact_lock);
+
+	return 0;
+}
+
+static void sparx5_mact_handle_entry(struct sparx5 *sparx5,
+				     unsigned char mac[ETH_ALEN],
+				     u16 vid, u32 cfg2)
+{
+	struct sparx5_mact_entry *mact_entry;
+	bool found = false;
+	u16 port;
+
+	if (LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_TYPE_GET(cfg2) !=
+	    MAC_ENTRY_ADDR_TYPE_UPSID_PN)
+		return;
+
+	port = LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_GET(cfg2);
+	if (port >= SPX5_PORTS)
+		return;
+
+	mutex_lock(&sparx5->mact_lock);
+	list_for_each_entry(mact_entry, &sparx5->mact_entries, list) {
+		if (mact_entry->vid == vid &&
+		    ether_addr_equal(mac, mact_entry->mac)) {
+			found = true;
+			mact_entry->flags |= MAC_ENT_ALIVE;
+			if (mact_entry->port != port) {
+				dev_warn(sparx5->dev, "Entry move: %d -> %d\n",
+					 mact_entry->port, port);
+				mact_entry->port = port;
+				mact_entry->flags |= MAC_ENT_MOVED;
+			}
+			/* Entry handled */
+			break;
+		}
+	}
+	mutex_unlock(&sparx5->mact_lock);
+
+	if (found && !(mact_entry->flags & MAC_ENT_MOVED))
+		/* Present, not moved */
+		return;
+
+	if (!found) {
+		/* Entry not found - now add */
+		mact_entry = alloc_mact_entry(sparx5, mac, vid, port);
+		if (!mact_entry)
+			return;
+
+		mact_entry->flags |= MAC_ENT_ALIVE;
+		mutex_lock(&sparx5->mact_lock);
+		list_add_tail(&mact_entry->list, &sparx5->mact_entries);
+		mutex_unlock(&sparx5->mact_lock);
+	}
+
+	/* New or moved entry - notify bridge */
+	sparx5_fdb_call_notifiers(SWITCHDEV_FDB_ADD_TO_BRIDGE,
+				  mac, vid, sparx5->ports[port]->ndev,
+				  true);
+}
+
+void sparx5_mact_pull_work(struct work_struct *work)
+{
+	struct delayed_work *del_work = to_delayed_work(work);
+	struct sparx5 *sparx5 = container_of(del_work, struct sparx5,
+					     mact_work);
+	struct sparx5_mact_entry *mact_entry, *tmp;
+	unsigned char mac[ETH_ALEN];
+	u32 cfg2;
+	u16 vid;
+	int ret;
+
+	/* Reset MAC entry flags */
+	mutex_lock(&sparx5->mact_lock);
+	list_for_each_entry(mact_entry, &sparx5->mact_entries, list)
+		mact_entry->flags &= MAC_ENT_LOCK;
+	mutex_unlock(&sparx5->mact_lock);
+
+	/* MAIN mac address processing loop */
+	vid = 0;
+	memset(mac, 0, sizeof(mac));
+	do {
+		mutex_lock(&sparx5->lock);
+		sparx5_mact_select(sparx5, mac, vid);
+		spx5_wr(LRN_SCAN_NEXT_CFG_SCAN_NEXT_UNTIL_FOUND_ENA_SET(1),
+			sparx5, LRN_SCAN_NEXT_CFG);
+		spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET
+			(MAC_CMD_FIND_SMALLEST) |
+			LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+			sparx5, LRN_COMMON_ACCESS_CTRL);
+		ret = sparx5_mact_wait_for_completion(sparx5);
+		if (ret == 0)
+			ret = sparx5_mact_get(sparx5, mac, &vid, &cfg2);
+		mutex_unlock(&sparx5->lock);
+		if (ret == 0)
+			sparx5_mact_handle_entry(sparx5, mac, vid, cfg2);
+	} while (ret == 0);
+
+	mutex_lock(&sparx5->mact_lock);
+	list_for_each_entry_safe(mact_entry, tmp, &sparx5->mact_entries,
+				 list) {
+		/* If the entry is in HW or permanent, then skip */
+		if (mact_entry->flags & (MAC_ENT_ALIVE | MAC_ENT_LOCK))
+			continue;
+
+		sparx5_fdb_call_notifiers(SWITCHDEV_FDB_DEL_TO_BRIDGE,
+					  mact_entry->mac, mact_entry->vid,
+					  sparx5->ports[mact_entry->port]->ndev,
+					  true);
+
+		list_del(&mact_entry->list);
+		devm_kfree(sparx5->dev, mact_entry);
+	}
+	mutex_unlock(&sparx5->mact_lock);
+
+	queue_delayed_work(sparx5->mact_queue, &sparx5->mact_work,
+			   SPX5_MACT_PULL_DELAY);
+}
+
+void sparx5_set_ageing(struct sparx5 *sparx5, int msecs)
+{
+	int value = max(1, msecs / 10); /* unit 10 ms */
+
+	spx5_rmw(LRN_AUTOAGE_CFG_UNIT_SIZE_SET(2) | /* 10 ms */
+		 LRN_AUTOAGE_CFG_PERIOD_VAL_SET(value / 2), /* one bit ageing */
+		 LRN_AUTOAGE_CFG_UNIT_SIZE |
+		 LRN_AUTOAGE_CFG_PERIOD_VAL,
+		 sparx5,
+		 LRN_AUTOAGE_CFG(0));
+}
+
+void sparx5_mact_init(struct sparx5 *sparx5)
+{
+	mutex_init(&sparx5->lock);
+
+	/*  Flush MAC table */
+	spx5_wr(LRN_COMMON_ACCESS_CTRL_CPU_ACCESS_CMD_SET(MAC_CMD_CLEAR_ALL) |
+		LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_SET(1),
+		sparx5, LRN_COMMON_ACCESS_CTRL);
+
+	if (sparx5_mact_wait_for_completion(sparx5) != 0)
+		dev_warn(sparx5->dev, "MAC flush error\n");
+
+	sparx5_set_ageing(sparx5, BR_DEFAULT_AGEING_TIME / HZ * 1000);
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 0ae8320a5bbb..33568ad0bd2f 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -567,6 +567,8 @@ static void sparx5_board_init(struct sparx5 *sparx5)
 
 static int sparx5_start(struct sparx5 *sparx5)
 {
+	u8 broadcast[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+	char queue_name[32];
 	u32 idx;
 	int err;
 
@@ -599,12 +601,29 @@ static int sparx5_start(struct sparx5 *sparx5)
 			 ANA_CL_FILTER_CTRL_FORCE_FCS_UPDATE_ENA,
 			 sparx5, ANA_CL_FILTER_CTRL(idx));
 
-	/* MAC/VLAN support to be added in later patches */
+	/* Init MAC table, ageing */
+	sparx5_mact_init(sparx5);
+
+	/* VLAN support to be added in later patches */
+
+	/* Add host mode BC address (points only to CPU) */
+	sparx5_mact_learn(sparx5, PGID_CPU, broadcast, NULL_VID);
+
 	/* Enable queue limitation watermarks */
 	sparx5_qlim_set(sparx5);
 
 	/* Resource calendar support to be added in later patches */
 
+	/* Init mact_sw struct */
+	mutex_init(&sparx5->mact_lock);
+	INIT_LIST_HEAD(&sparx5->mact_entries);
+	snprintf(queue_name, sizeof(queue_name), "%s-mact",
+		 dev_name(sparx5->dev));
+	sparx5->mact_queue = create_singlethread_workqueue(queue_name);
+	INIT_DELAYED_WORK(&sparx5->mact_work, sparx5_mact_pull_work);
+	queue_delayed_work(sparx5->mact_queue, &sparx5->mact_work,
+			   SPX5_MACT_PULL_DELAY);
+
 	err = sparx5_register_netdevs(sparx5);
 	if (err)
 		return err;
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index 3c2334359998..5185104a7a0f 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -133,7 +133,14 @@ struct sparx5 {
 	/* port structures are in net device */
 	struct sparx5_port *ports[SPX5_PORTS];
 	enum sparx5_core_clockfreq coreclock;
+	/* Switch state */
 	u8 base_mac[ETH_ALEN];
+	/* SW MAC table */
+	struct list_head mact_entries;
+	/* mac table list (mact_entries) mutex */
+	struct mutex mact_lock;
+	struct delayed_work mact_work;
+	struct workqueue_struct *mact_queue;
 	/* Board specifics */
 	bool sd_sgpio_remapping;
 	/* Register based inj/xtr */
@@ -145,6 +152,25 @@ irqreturn_t sparx5_xtr_handler(int irq, void *_priv);
 int sparx5_port_xmit_impl(struct sk_buff *skb, struct net_device *dev);
 int sparx5_manual_injection_mode(struct sparx5 *sparx5);
 
+/* sparx5_mactable.c */
+void sparx5_mact_pull_work(struct work_struct *work);
+int sparx5_mact_learn(struct sparx5 *sparx5, int port,
+		      const unsigned char mac[ETH_ALEN], u16 vid);
+bool sparx5_mact_getnext(struct sparx5 *sparx5,
+			 unsigned char mac[ETH_ALEN], u16 *vid, u32 *pcfg2);
+int sparx5_mact_forget(struct sparx5 *sparx5,
+		       const unsigned char mac[ETH_ALEN], u16 vid);
+int sparx5_add_mact_entry(struct sparx5 *sparx5,
+			  struct sparx5_port *port,
+			  const unsigned char *addr, u16 vid);
+int sparx5_del_mact_entry(struct sparx5 *sparx5,
+			  const unsigned char *addr,
+			  u16 vid);
+int sparx5_mc_sync(struct net_device *dev, const unsigned char *addr);
+int sparx5_mc_unsync(struct net_device *dev, const unsigned char *addr);
+void sparx5_set_ageing(struct sparx5 *sparx5, int msecs);
+void sparx5_mact_init(struct sparx5 *sparx5);
+
 /* sparx5_netdev.c */
 bool sparx5_netdevice_check(const struct net_device *dev);
 struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
index 9f053b91e8e0..48512a59c887 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -132,14 +132,34 @@ static int sparx5_port_get_phys_port_name(struct net_device *dev,
 
 static int sparx5_set_mac_address(struct net_device *dev, void *p)
 {
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
 	const struct sockaddr *addr = p;
 
+	/* Remove current */
+	sparx5_mact_forget(sparx5, dev->dev_addr,  port->pvid);
+
+	/* Add new */
+	sparx5_mact_learn(sparx5, PGID_CPU, addr->sa_data, port->pvid);
+
 	/* Record the address */
 	ether_addr_copy(dev->dev_addr, addr->sa_data);
 
 	return 0;
 }
 
+static int sparx5_get_port_parent_id(struct net_device *dev,
+				     struct netdev_phys_item_id *ppid)
+{
+	struct sparx5_port *sparx5_port = netdev_priv(dev);
+	struct sparx5 *sparx5 = sparx5_port->sparx5;
+
+	ppid->id_len = sizeof(sparx5->base_mac);
+	memcpy(&ppid->id, &sparx5->base_mac, ppid->id_len);
+
+	return 0;
+}
+
 static const struct net_device_ops sparx5_port_netdev_ops = {
 	.ndo_open               = sparx5_port_open,
 	.ndo_stop               = sparx5_port_stop,
@@ -147,6 +167,7 @@ static const struct net_device_ops sparx5_port_netdev_ops = {
 	.ndo_get_phys_port_name = sparx5_port_get_phys_port_name,
 	.ndo_set_mac_address    = sparx5_set_mac_address,
 	.ndo_validate_addr      = eth_validate_addr,
+	.ndo_get_port_parent_id = sparx5_get_port_parent_id,
 };
 
 bool sparx5_netdevice_check(const struct net_device *dev)
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:53 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:53 +0200
Subject: [PATCH net-next 06/10] net: sparx5: add vlan support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-7-steen.hegelund@microchip.com>

This adds Sparx5 VLAN support.

Sparx5 has more VLAN features than provided here, but these will be added
in later series. For now we only add the basic L2 features.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   2 +-
 .../ethernet/microchip/sparx5/sparx5_main.c   |  10 +-
 .../ethernet/microchip/sparx5/sparx5_main.h   |  14 ++
 .../ethernet/microchip/sparx5/sparx5_vlan.c   | 224 ++++++++++++++++++
 4 files changed, 246 insertions(+), 4 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index 4ccb09d275bc..81685c3f428e 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -6,4 +6,4 @@
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
- sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o sparx5_vlan.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 33568ad0bd2f..fb3618be8e5d 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -280,7 +280,8 @@ static int sparx5_create_port(struct sparx5 *sparx5,
 	}
 	spx5_port->conf = config->conf;
 
-	/* VLAN support to be added in later patches */
+	/* Setup VLAN */
+	sparx5_vlan_port_setup(sparx5, spx5_port->portno);
 
 	/* Create a phylink for PHY management.  Also handles SFPs */
 	spx5_port->phylink_config.dev = &spx5_port->ndev->dev;
@@ -588,7 +589,9 @@ static int sparx5_start(struct sparx5 *sparx5)
 			 QFWD_SWITCH_PORT_MODE(idx));
 	}
 
-	/* Forwarding masks to be added in later patches */
+	/* Init masks */
+	sparx5_update_fwd(sparx5);
+
 	/* CPU copy CPU pgids */
 	spx5_wr(ANA_AC_PGID_MISC_CFG_PGID_CPU_COPY_ENA_SET(1),
 		sparx5, ANA_AC_PGID_MISC_CFG(PGID_CPU));
@@ -604,7 +607,8 @@ static int sparx5_start(struct sparx5 *sparx5)
 	/* Init MAC table, ageing */
 	sparx5_mact_init(sparx5);
 
-	/* VLAN support to be added in later patches */
+	/* Setup VLANs */
+	sparx5_vlan_init(sparx5);
 
 	/* Add host mode BC address (points only to CPU) */
 	sparx5_mact_learn(sparx5, PGID_CPU, broadcast, NULL_VID);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index 5185104a7a0f..d82700614abf 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -135,6 +135,10 @@ struct sparx5 {
 	enum sparx5_core_clockfreq coreclock;
 	/* Switch state */
 	u8 base_mac[ETH_ALEN];
+	/* Bridged interfaces */
+	DECLARE_BITMAP(bridge_fwd_mask, SPX5_PORTS);
+	DECLARE_BITMAP(bridge_lrn_mask, SPX5_PORTS);
+	DECLARE_BITMAP(vlan_mask[VLAN_N_VID], SPX5_PORTS);
 	/* SW MAC table */
 	struct list_head mact_entries;
 	/* mac table list (mact_entries) mutex */
@@ -171,6 +175,16 @@ int sparx5_mc_unsync(struct net_device *dev, const unsigned char *addr);
 void sparx5_set_ageing(struct sparx5 *sparx5, int msecs);
 void sparx5_mact_init(struct sparx5 *sparx5);
 
+/* sparx5_vlan.c */
+void sparx5_pgid_update_mask(struct sparx5_port *port, int pgid, bool enable);
+void sparx5_update_fwd(struct sparx5 *sparx5);
+void sparx5_vlan_init(struct sparx5 *sparx5);
+void sparx5_vlan_port_setup(struct sparx5 *sparx5, int portno);
+int sparx5_vlan_vid_add(struct sparx5_port *port, u16 vid, bool pvid,
+			bool untagged);
+int sparx5_vlan_vid_del(struct sparx5_port *port, u16 vid);
+void sparx5_vlan_port_apply(struct sparx5 *sparx5, struct sparx5_port *port);
+
 /* sparx5_netdev.c */
 bool sparx5_netdevice_check(const struct net_device *dev);
 struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c b/drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c
new file mode 100644
index 000000000000..4ce490a25f33
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+static int sparx5_vlant_set_mask(struct sparx5 *sparx5, u16 vid)
+{
+	u32 mask[3];
+
+	/* Divide up mask in 32 bit words */
+	bitmap_to_arr32(mask, sparx5->vlan_mask[vid], SPX5_PORTS);
+
+	/* Output mask to respective registers */
+	spx5_wr(mask[0], sparx5, ANA_L3_VLAN_MASK_CFG(vid));
+	spx5_wr(mask[1], sparx5, ANA_L3_VLAN_MASK_CFG1(vid));
+	spx5_wr(mask[2], sparx5, ANA_L3_VLAN_MASK_CFG2(vid));
+
+	return 0;
+}
+
+void sparx5_vlan_init(struct sparx5 *sparx5)
+{
+	u16 vid;
+
+	spx5_rmw(ANA_L3_VLAN_CTRL_VLAN_ENA_SET(1),
+		 ANA_L3_VLAN_CTRL_VLAN_ENA,
+		 sparx5,
+		 ANA_L3_VLAN_CTRL);
+
+	/* Map VLAN = FID */
+	for (vid = NULL_VID; vid < VLAN_N_VID; vid++)
+		spx5_rmw(ANA_L3_VLAN_CFG_VLAN_FID_SET(vid),
+			 ANA_L3_VLAN_CFG_VLAN_FID,
+			 sparx5,
+			 ANA_L3_VLAN_CFG(vid));
+}
+
+void sparx5_vlan_port_setup(struct sparx5 *sparx5, int portno)
+{
+	struct sparx5_port *port = sparx5->ports[portno];
+
+	/* Configure PVID */
+	spx5_rmw(ANA_CL_VLAN_CTRL_VLAN_AWARE_ENA_SET(0) |
+		 ANA_CL_VLAN_CTRL_PORT_VID_SET(port->pvid),
+		 ANA_CL_VLAN_CTRL_VLAN_AWARE_ENA |
+		 ANA_CL_VLAN_CTRL_PORT_VID,
+		 sparx5,
+		 ANA_CL_VLAN_CTRL(port->portno));
+}
+
+int sparx5_vlan_vid_add(struct sparx5_port *port, u16 vid, bool pvid,
+			bool untagged)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+	int ret;
+
+	/* Make the port a member of the VLAN */
+	set_bit(port->portno, sparx5->vlan_mask[vid]);
+	ret = sparx5_vlant_set_mask(sparx5, vid);
+	if (ret)
+		return ret;
+
+	/* Default ingress vlan classification */
+	if (pvid)
+		port->pvid = vid;
+
+	/* Untagged egress vlan classification */
+	if (untagged && port->vid != vid) {
+		if (port->vid) {
+			netdev_err(port->ndev,
+				   "Port already has a native VLAN: %d\n",
+				   port->vid);
+			return -EBUSY;
+		}
+		port->vid = vid;
+	}
+
+	sparx5_vlan_port_apply(sparx5, port);
+
+	return 0;
+}
+
+int sparx5_vlan_vid_del(struct sparx5_port *port, u16 vid)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+	int ret;
+
+	/* 8021q removes VID 0 on module unload for all interfaces
+	 * with VLAN filtering feature. We need to keep it to receive
+	 * untagged traffic.
+	 */
+	if (vid == 0)
+		return 0;
+
+	/* Stop the port from being a member of the vlan */
+	clear_bit(port->portno, sparx5->vlan_mask[vid]);
+	ret = sparx5_vlant_set_mask(sparx5, vid);
+	if (ret)
+		return ret;
+
+	/* Ingress */
+	if (port->pvid == vid)
+		port->pvid = 0;
+
+	/* Egress */
+	if (port->vid == vid)
+		port->vid = 0;
+
+	sparx5_vlan_port_apply(sparx5, port);
+
+	return 0;
+}
+
+void sparx5_pgid_update_mask(struct sparx5_port *port, int pgid, bool enable)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+	u32 val, mask;
+
+	/* mask is spread across 3 registers x 32 bit */
+	if (port->portno < 32) {
+		mask = BIT(port->portno);
+		val = enable ? mask : 0;
+		spx5_rmw(val, mask, sparx5, ANA_AC_PGID_CFG(pgid));
+	} else if (port->portno < 64) {
+		mask = BIT(port->portno - 32);
+		val = enable ? mask : 0;
+		spx5_rmw(val, mask, sparx5, ANA_AC_PGID_CFG1(pgid));
+	} else if (port->portno < SPX5_PORTS) {
+		mask = BIT(port->portno - 64);
+		val = enable ? mask : 0;
+		spx5_rmw(val, mask, sparx5, ANA_AC_PGID_CFG2(pgid));
+	} else {
+		netdev_err(port->ndev, "Invalid port no: %d\n", port->portno);
+	}
+}
+
+void sparx5_update_fwd(struct sparx5 *sparx5)
+{
+	DECLARE_BITMAP(workmask, SPX5_PORTS);
+	u32 mask[3];
+	int port;
+
+	/* Divide up fwd mask in 32 bit words */
+	bitmap_to_arr32(mask, sparx5->bridge_fwd_mask, SPX5_PORTS);
+
+	/* Update flood masks */
+	for (port = PGID_UC_FLOOD; port <= PGID_BCAST; port++) {
+		spx5_wr(mask[0], sparx5, ANA_AC_PGID_CFG(port));
+		spx5_wr(mask[1], sparx5, ANA_AC_PGID_CFG1(port));
+		spx5_wr(mask[2], sparx5, ANA_AC_PGID_CFG2(port));
+	}
+
+	/* Update SRC masks */
+	for (port = 0; port < SPX5_PORTS; port++) {
+		if (test_bit(port, sparx5->bridge_fwd_mask)) {
+			/* Allow to send to all bridged but self */
+			bitmap_copy(workmask, sparx5->bridge_fwd_mask, SPX5_PORTS);
+			clear_bit(port, workmask);
+			bitmap_to_arr32(mask, workmask, SPX5_PORTS);
+			spx5_wr(mask[0], sparx5, ANA_AC_SRC_CFG(port));
+			spx5_wr(mask[1], sparx5, ANA_AC_SRC_CFG1(port));
+			spx5_wr(mask[2], sparx5, ANA_AC_SRC_CFG2(port));
+		} else {
+			spx5_wr(0, sparx5, ANA_AC_SRC_CFG(port));
+			spx5_wr(0, sparx5, ANA_AC_SRC_CFG1(port));
+			spx5_wr(0, sparx5, ANA_AC_SRC_CFG2(port));
+		}
+	}
+
+	/* Learning enabled only for bridged ports */
+	bitmap_and(workmask, sparx5->bridge_fwd_mask,
+		   sparx5->bridge_lrn_mask, SPX5_PORTS);
+	bitmap_to_arr32(mask, workmask, SPX5_PORTS);
+
+	/* Apply learning mask */
+	spx5_wr(mask[0], sparx5, ANA_L2_AUTO_LRN_CFG);
+	spx5_wr(mask[1], sparx5, ANA_L2_AUTO_LRN_CFG1);
+	spx5_wr(mask[2], sparx5, ANA_L2_AUTO_LRN_CFG2);
+}
+
+void sparx5_vlan_port_apply(struct sparx5 *sparx5,
+			    struct sparx5_port *port)
+
+{
+	u32 val;
+
+	/* Configure PVID, vlan aware */
+	val = ANA_CL_VLAN_CTRL_VLAN_AWARE_ENA_SET(port->vlan_aware) |
+		ANA_CL_VLAN_CTRL_VLAN_POP_CNT_SET(port->vlan_aware) |
+		ANA_CL_VLAN_CTRL_PORT_VID_SET(port->pvid);
+	spx5_wr(val, sparx5, ANA_CL_VLAN_CTRL(port->portno));
+
+	val = 0;
+	if (port->vlan_aware && !port->pvid)
+		/* If port is vlan-aware and tagged, drop untagged and
+		 * priority tagged frames.
+		 */
+		val = ANA_CL_VLAN_FILTER_CTRL_TAG_REQUIRED_ENA_SET(1) |
+			ANA_CL_VLAN_FILTER_CTRL_PRIO_CTAG_DIS_SET(1) |
+			ANA_CL_VLAN_FILTER_CTRL_PRIO_STAG_DIS_SET(1);
+	spx5_wr(val, sparx5,
+		ANA_CL_VLAN_FILTER_CTRL(port->portno, 0));
+
+	/* Egress configuration (REW_TAG_CFG): VLAN tag type to 8021Q */
+	val = REW_TAG_CTRL_TAG_TPID_CFG_SET(0);
+	if (port->vlan_aware) {
+		if (port->vid)
+			/* Tag all frames except when VID == DEFAULT_VLAN */
+			val |= REW_TAG_CTRL_TAG_CFG_SET(1);
+		else
+			val |= REW_TAG_CTRL_TAG_CFG_SET(3);
+	}
+	spx5_wr(val, sparx5, REW_TAG_CTRL(port->portno));
+
+	/* Egress VID */
+	spx5_rmw(REW_PORT_VLAN_CFG_PORT_VID_SET(port->vid),
+		 REW_PORT_VLAN_CFG_PORT_VID,
+		 sparx5,
+		 REW_PORT_VLAN_CFG(port->portno));
+}
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:54 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:54 +0200
Subject: [PATCH net-next 07/10] net: sparx5: add switching support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-8-steen.hegelund@microchip.com>

This adds SwitchDev support by hardware offloading the
software bridge.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   3 +-
 .../microchip/sparx5/sparx5_mactable.c        |   3 +
 .../ethernet/microchip/sparx5/sparx5_main.c   |  13 +-
 .../ethernet/microchip/sparx5/sparx5_main.h   |  11 +
 .../ethernet/microchip/sparx5/sparx5_netdev.c |  10 +
 .../ethernet/microchip/sparx5/sparx5_packet.c |   6 +
 .../microchip/sparx5/sparx5_switchdev.c       | 508 ++++++++++++++++++
 7 files changed, 552 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index 81685c3f428e..d2788e8b7798 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -6,4 +6,5 @@
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
- sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o sparx5_vlan.o
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o sparx5_vlan.o \
+ sparx5_switchdev.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
index 6c5e04eccaa3..0443f66b5550 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
@@ -371,6 +371,9 @@ static void sparx5_mact_handle_entry(struct sparx5 *sparx5,
 	if (port >= SPX5_PORTS)
 		return;
 
+	if (!test_bit(port, sparx5->bridge_mask))
+		return;
+
 	mutex_lock(&sparx5->mact_lock);
 	list_for_each_entry(mact_entry, &sparx5->mact_entries, list) {
 		if (mact_entry->vid == vid &&
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index fb3618be8e5d..8121f0b1c0ea 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -633,6 +633,7 @@ static int sparx5_start(struct sparx5 *sparx5)
 		return err;
 
 	sparx5_board_init(sparx5);
+	err = sparx5_register_notifier_blocks(sparx5);
 
 	/* Start register based INJ/XTR */
 	err = -ENXIO;
@@ -652,7 +653,14 @@ static int sparx5_start(struct sparx5 *sparx5)
 
 static void sparx5_cleanup_ports(struct sparx5 *sparx5)
 {
-	/* Port cleanup to be added in later patches */
+	int idx;
+
+	for (idx = 0; idx < SPX5_PORTS; ++idx) {
+		struct sparx5_port *port = sparx5->ports[idx];
+
+		if (port && port->ndev)
+			sparx5_destroy_netdev(sparx5, port);
+	}
 }
 
 static int mchp_sparx5_probe(struct platform_device *pdev)
@@ -820,6 +828,9 @@ static int mchp_sparx5_remove(struct platform_device *pdev)
 		sparx5->xtr_irq = -ENXIO;
 	}
 	sparx5_cleanup_ports(sparx5);
+	/* Unregister netdevs */
+	sparx5_unregister_notifier_blocks(sparx5);
+
 	return 0;
 }
 
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index d82700614abf..e427adad4555 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -133,9 +133,16 @@ struct sparx5 {
 	/* port structures are in net device */
 	struct sparx5_port *ports[SPX5_PORTS];
 	enum sparx5_core_clockfreq coreclock;
+	/* Notifiers */
+	struct notifier_block netdevice_nb;
+	struct notifier_block switchdev_nb;
+	struct notifier_block switchdev_blocking_nb;
 	/* Switch state */
 	u8 base_mac[ETH_ALEN];
+	/* Associated bridge device (when bridged) */
+	struct net_device *hw_bridge_dev;
 	/* Bridged interfaces */
+	DECLARE_BITMAP(bridge_mask, SPX5_PORTS);
 	DECLARE_BITMAP(bridge_fwd_mask, SPX5_PORTS);
 	DECLARE_BITMAP(bridge_lrn_mask, SPX5_PORTS);
 	DECLARE_BITMAP(vlan_mask[VLAN_N_VID], SPX5_PORTS);
@@ -151,6 +158,10 @@ struct sparx5 {
 	int xtr_irq;
 };
 
+/* sparx5_switchdev.c */
+int sparx5_register_notifier_blocks(struct sparx5 *sparx5);
+void sparx5_unregister_notifier_blocks(struct sparx5 *sparx5);
+
 /* sparx5_packet.c */
 irqreturn_t sparx5_xtr_handler(int irq, void *_priv);
 int sparx5_port_xmit_impl(struct sk_buff *skb, struct net_device *dev);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
index 48512a59c887..6b0bfd512dfb 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -117,6 +117,15 @@ static int sparx5_port_stop(struct net_device *ndev)
 	return 0;
 }
 
+static void sparx5_set_rx_mode(struct net_device *dev)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
+
+	if (!test_bit(port->portno, sparx5->bridge_mask))
+		__dev_mc_sync(dev, sparx5_mc_sync, sparx5_mc_unsync);
+}
+
 static int sparx5_port_get_phys_port_name(struct net_device *dev,
 					  char *buf, size_t len)
 {
@@ -164,6 +173,7 @@ static const struct net_device_ops sparx5_port_netdev_ops = {
 	.ndo_open               = sparx5_port_open,
 	.ndo_stop               = sparx5_port_stop,
 	.ndo_start_xmit         = sparx5_port_xmit_impl,
+	.ndo_set_rx_mode        = sparx5_set_rx_mode,
 	.ndo_get_phys_port_name = sparx5_port_get_phys_port_name,
 	.ndo_set_mac_address    = sparx5_set_mac_address,
 	.ndo_validate_addr      = eth_validate_addr,
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c b/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
index 2c4106a87fac..f3bca7fcb874 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
@@ -143,6 +143,12 @@ static void sparx5_xtr_grp(struct sparx5 *sparx5, u8 grp, bool byte_swap)
 	}
 #endif
 
+	/* Everything we see on an interface that is in the HW bridge
+	 * has already been forwarded
+	 */
+	if (test_bit(port->portno, sparx5->bridge_mask))
+		skb->offload_fwd_mark = 1;
+
 	/* Finish up skb */
 	skb_put(skb, byte_cnt - ETH_FCS_LEN);
 	eth_skb_pad(skb);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c
new file mode 100644
index 000000000000..19c7cb795b4b
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c
@@ -0,0 +1,508 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/if_bridge.h>
+#include <net/switchdev.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+static struct workqueue_struct *sparx5_owq;
+
+struct sparx5_switchdev_event_work {
+	struct work_struct work;
+	struct switchdev_notifier_fdb_info fdb_info;
+	struct net_device *dev;
+	unsigned long event;
+};
+
+static void sparx5_port_attr_bridge_flags(struct sparx5_port *port,
+					  struct switchdev_brport_flags flags)
+{
+	if (flags.mask & BR_MCAST_FLOOD)
+		sparx5_pgid_update_mask(port, PGID_MC_FLOOD, true);
+}
+
+static void sparx5_attr_stp_state_set(struct sparx5_port *port,
+				      u8 state)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+
+	if (!test_bit(port->portno, sparx5->bridge_mask)) {
+		netdev_err(port->ndev,
+			   "Controlling non-bridged port %d?\n", port->portno);
+		return;
+	}
+
+	switch (state) {
+	case BR_STATE_FORWARDING:
+		set_bit(port->portno, sparx5->bridge_fwd_mask);
+		fallthrough;
+	case BR_STATE_LEARNING:
+		set_bit(port->portno, sparx5->bridge_lrn_mask);
+		break;
+
+	default:
+		/* All other states treated as blocking */
+		clear_bit(port->portno, sparx5->bridge_fwd_mask);
+		clear_bit(port->portno, sparx5->bridge_lrn_mask);
+		break;
+	}
+
+	/* apply the bridge_fwd_mask to all the ports */
+	sparx5_update_fwd(sparx5);
+}
+
+static void sparx5_port_attr_ageing_set(struct sparx5_port *port,
+					unsigned long ageing_clock_t)
+{
+	unsigned long ageing_jiffies = clock_t_to_jiffies(ageing_clock_t);
+	u32 ageing_time = jiffies_to_msecs(ageing_jiffies);
+
+	sparx5_set_ageing(port->sparx5, ageing_time);
+}
+
+static int sparx5_port_attr_set(struct net_device *dev,
+				const struct switchdev_attr *attr,
+				struct netlink_ext_ack *extack)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+
+	switch (attr->id) {
+	case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS:
+		sparx5_port_attr_bridge_flags(port, attr->u.brport_flags);
+		break;
+	case SWITCHDEV_ATTR_ID_PORT_STP_STATE:
+		sparx5_attr_stp_state_set(port, attr->u.stp_state);
+		break;
+	case SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME:
+		sparx5_port_attr_ageing_set(port, attr->u.ageing_time);
+		break;
+	case SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING:
+		port->vlan_aware = attr->u.vlan_filtering;
+		sparx5_vlan_port_apply(port->sparx5, port);
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+
+static int sparx5_port_bridge_join(struct sparx5_port *port,
+				   struct net_device *bridge)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+
+	if (bitmap_empty(sparx5->bridge_mask, SPX5_PORTS))
+		/* First bridged port */
+		sparx5->hw_bridge_dev = bridge;
+	else
+		if (sparx5->hw_bridge_dev != bridge)
+			/* This is adding the port to a second bridge, this is
+			 * unsupported
+			 */
+			return -ENODEV;
+
+	set_bit(port->portno, sparx5->bridge_mask);
+
+	/* Port enters in bridge mode therefor don't need to copy to CPU
+	 * frames for multicast in case the bridge is not requesting them
+	 */
+	__dev_mc_unsync(port->ndev, sparx5_mc_unsync);
+
+	return 0;
+}
+
+static void sparx5_port_bridge_leave(struct sparx5_port *port,
+				     struct net_device *bridge)
+{
+	struct sparx5 *sparx5 = port->sparx5;
+
+	clear_bit(port->portno, sparx5->bridge_mask);
+	if (bitmap_empty(sparx5->bridge_mask, SPX5_PORTS))
+		sparx5->hw_bridge_dev = NULL;
+
+	/* Clear bridge vlan settings before updating the port settings */
+	port->vlan_aware = 0;
+	port->pvid = NULL_VID;
+	port->vid = NULL_VID;
+
+	/* Port enters in host more therefore restore mc list */
+	__dev_mc_sync(port->ndev, sparx5_mc_sync, sparx5_mc_unsync);
+}
+
+static int sparx5_port_changeupper(struct net_device *dev,
+				   struct netdev_notifier_changeupper_info *info)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	int err = 0;
+
+	if (netif_is_bridge_master(info->upper_dev)) {
+		if (info->linking)
+			err = sparx5_port_bridge_join(port, info->upper_dev);
+		else
+			sparx5_port_bridge_leave(port, info->upper_dev);
+
+		sparx5_vlan_port_apply(port->sparx5, port);
+	}
+
+	return err;
+}
+
+static int sparx5_port_add_addr(struct net_device *dev, bool up)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	struct sparx5 *sparx5 = port->sparx5;
+	u16 vid = port->pvid;
+
+	if (up)
+		sparx5_mact_learn(sparx5, PGID_CPU, port->ndev->dev_addr, vid);
+	else
+		sparx5_mact_forget(sparx5, port->ndev->dev_addr, vid);
+
+	return 0;
+}
+
+static int sparx5_netdevice_port_event(struct net_device *dev,
+				       struct notifier_block *nb,
+				       unsigned long event, void *ptr)
+{
+	int err = 0;
+
+	if (!sparx5_netdevice_check(dev))
+		return 0;
+
+	switch (event) {
+	case NETDEV_CHANGEUPPER:
+		err = sparx5_port_changeupper(dev, ptr);
+		break;
+	case NETDEV_PRE_UP:
+		err = sparx5_port_add_addr(dev, true);
+		break;
+	case NETDEV_DOWN:
+		err = sparx5_port_add_addr(dev, false);
+		break;
+	}
+
+	return err;
+}
+
+static int sparx5_netdevice_event(struct notifier_block *nb,
+				  unsigned long event, void *ptr)
+{
+	struct net_device *dev = netdev_notifier_info_to_dev(ptr);
+	int ret = 0;
+
+	ret = sparx5_netdevice_port_event(dev, nb, event, ptr);
+
+	return notifier_from_errno(ret);
+}
+
+static void sparx5_switchdev_bridge_fdb_event_work(struct work_struct *work)
+{
+	struct sparx5_switchdev_event_work *switchdev_work =
+		container_of(work, struct sparx5_switchdev_event_work, work);
+	struct net_device *dev = switchdev_work->dev;
+	struct switchdev_notifier_fdb_info *fdb_info;
+	struct sparx5_port *port;
+	struct sparx5 *sparx5;
+
+	rtnl_lock();
+	if (!sparx5_netdevice_check(dev))
+		goto out;
+
+	port = netdev_priv(dev);
+	sparx5 = port->sparx5;
+
+	fdb_info = &switchdev_work->fdb_info;
+
+	switch (switchdev_work->event) {
+	case SWITCHDEV_FDB_ADD_TO_DEVICE:
+		if (!fdb_info->added_by_user)
+			break;
+		sparx5_add_mact_entry(sparx5, port, fdb_info->addr,
+				      fdb_info->vid);
+		break;
+	case SWITCHDEV_FDB_DEL_TO_DEVICE:
+		if (!fdb_info->added_by_user)
+			break;
+		sparx5_del_mact_entry(sparx5, fdb_info->addr, fdb_info->vid);
+		break;
+	}
+
+out:
+	rtnl_unlock();
+	kfree(switchdev_work->fdb_info.addr);
+	kfree(switchdev_work);
+	dev_put(dev);
+}
+
+static void sparx5_schedule_work(struct work_struct *work)
+{
+	queue_work(sparx5_owq, work);
+}
+
+static int sparx5_switchdev_event(struct notifier_block *unused,
+				  unsigned long event, void *ptr)
+{
+	struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
+	struct sparx5_switchdev_event_work *switchdev_work;
+	struct switchdev_notifier_fdb_info *fdb_info;
+	struct switchdev_notifier_info *info = ptr;
+	int err;
+
+	switch (event) {
+	case SWITCHDEV_PORT_ATTR_SET:
+		err = switchdev_handle_port_attr_set(dev, ptr,
+						     sparx5_netdevice_check,
+						     sparx5_port_attr_set);
+		return notifier_from_errno(err);
+	case SWITCHDEV_FDB_ADD_TO_DEVICE:
+		fallthrough;
+	case SWITCHDEV_FDB_DEL_TO_DEVICE:
+		switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
+		if (!switchdev_work)
+			return NOTIFY_BAD;
+
+		switchdev_work->dev = dev;
+		switchdev_work->event = event;
+
+		fdb_info = container_of(info,
+					struct switchdev_notifier_fdb_info,
+					info);
+		INIT_WORK(&switchdev_work->work,
+			  sparx5_switchdev_bridge_fdb_event_work);
+		memcpy(&switchdev_work->fdb_info, ptr,
+		       sizeof(switchdev_work->fdb_info));
+		switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
+		if (!switchdev_work->fdb_info.addr)
+			goto err_addr_alloc;
+
+		ether_addr_copy((u8 *)switchdev_work->fdb_info.addr,
+				fdb_info->addr);
+		dev_hold(dev);
+
+		sparx5_schedule_work(&switchdev_work->work);
+		break;
+	}
+
+	return NOTIFY_DONE;
+err_addr_alloc:
+	kfree(switchdev_work);
+	return NOTIFY_BAD;
+}
+
+static void sparx5_sync_port_dev_addr(struct sparx5 *sparx5,
+				      struct sparx5_port *port,
+				      u16 vid, bool add)
+{
+	if (!port ||
+	    !test_bit(port->portno, sparx5->bridge_mask))
+		return; /* Skip null/host interfaces */
+
+	/* Bridge connects to vid? */
+	if (add) {
+		/* Add port MAC address from the VLAN */
+		sparx5_mact_learn(sparx5, PGID_CPU,
+				  port->ndev->dev_addr, vid);
+	} else {
+		/* Control port addr visibility depending on
+		 * port VLAN connectivity.
+		 */
+		if (test_bit(port->portno, sparx5->vlan_mask[vid]))
+			sparx5_mact_learn(sparx5, PGID_CPU,
+					  port->ndev->dev_addr, vid);
+		else
+			sparx5_mact_forget(sparx5,
+					   port->ndev->dev_addr, vid);
+	}
+}
+
+static void sparx5_sync_bridge_dev_addr(struct net_device *dev,
+					struct sparx5 *sparx5,
+					u16 vid, bool add)
+{
+	int i;
+
+	/* First, handle bridge address'es */
+	if (add) {
+		sparx5_mact_learn(sparx5, PGID_CPU, dev->dev_addr,
+				  vid);
+		sparx5_mact_learn(sparx5, PGID_BCAST, dev->broadcast,
+				  vid);
+	} else {
+		sparx5_mact_forget(sparx5, dev->dev_addr, vid);
+		sparx5_mact_forget(sparx5, dev->broadcast, vid);
+	}
+
+	/* Now look at bridged ports */
+	for (i = 0; i < SPX5_PORTS; i++)
+		sparx5_sync_port_dev_addr(sparx5, sparx5->ports[i], vid, add);
+}
+
+static int sparx5_handle_port_vlan_add(struct net_device *dev,
+				       struct notifier_block *nb,
+				       const struct switchdev_obj_port_vlan *v)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+
+	if (netif_is_bridge_master(dev)) {
+		if (v->flags & BRIDGE_VLAN_INFO_BRENTRY) {
+			struct sparx5 *sparx5 =
+				container_of(nb, struct sparx5,
+					     switchdev_blocking_nb);
+
+			sparx5_sync_bridge_dev_addr(dev, sparx5, v->vid, true);
+		}
+		return 0;
+	}
+
+	if (!sparx5_netdevice_check(dev))
+		return -EOPNOTSUPP;
+
+	return sparx5_vlan_vid_add(port, v->vid,
+				  v->flags & BRIDGE_VLAN_INFO_PVID,
+				  v->flags & BRIDGE_VLAN_INFO_UNTAGGED);
+}
+
+static int sparx5_handle_port_obj_add(struct net_device *dev,
+				      struct notifier_block *nb,
+				      struct switchdev_notifier_port_obj_info *info)
+{
+	const struct switchdev_obj *obj = info->obj;
+	int err;
+
+	switch (obj->id) {
+	case SWITCHDEV_OBJ_ID_PORT_VLAN:
+		err = sparx5_handle_port_vlan_add(dev, nb,
+						  SWITCHDEV_OBJ_PORT_VLAN(obj));
+		break;
+	default:
+		err = -EOPNOTSUPP;
+		break;
+	}
+
+	info->handled = true;
+	return err;
+}
+
+static int sparx5_handle_port_vlan_del(struct net_device *dev,
+				       struct notifier_block *nb,
+				       u16 vid)
+{
+	struct sparx5_port *port = netdev_priv(dev);
+	int ret;
+
+	/* Master bridge? */
+	if (netif_is_bridge_master(dev)) {
+		struct sparx5 *sparx5 =
+			container_of(nb, struct sparx5,
+				     switchdev_blocking_nb);
+
+		sparx5_sync_bridge_dev_addr(dev, sparx5, vid, false);
+		return 0;
+	}
+
+	if (!sparx5_netdevice_check(dev))
+		return -EOPNOTSUPP;
+
+	ret = sparx5_vlan_vid_del(port, vid);
+	if (ret)
+		return ret;
+
+	/* Delete the port MAC address with the matching VLAN information */
+	sparx5_mact_forget(port->sparx5, port->ndev->dev_addr, vid);
+
+	return 0;
+}
+
+static int sparx5_handle_port_obj_del(struct net_device *dev,
+				      struct notifier_block *nb,
+				      struct switchdev_notifier_port_obj_info *info)
+{
+	const struct switchdev_obj *obj = info->obj;
+	int err;
+
+	switch (obj->id) {
+	case SWITCHDEV_OBJ_ID_PORT_VLAN:
+		err = sparx5_handle_port_vlan_del(dev, nb,
+						  SWITCHDEV_OBJ_PORT_VLAN(obj)->vid);
+		break;
+	default:
+		err = -EOPNOTSUPP;
+		break;
+	}
+
+	info->handled = true;
+	return err;
+}
+
+static int sparx5_switchdev_blocking_event(struct notifier_block *nb,
+					   unsigned long event,
+					   void *ptr)
+{
+	struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
+	int err;
+
+	switch (event) {
+	case SWITCHDEV_PORT_OBJ_ADD:
+		err = sparx5_handle_port_obj_add(dev, nb, ptr);
+		return notifier_from_errno(err);
+	case SWITCHDEV_PORT_OBJ_DEL:
+		err = sparx5_handle_port_obj_del(dev, nb, ptr);
+		return notifier_from_errno(err);
+	case SWITCHDEV_PORT_ATTR_SET:
+		err = switchdev_handle_port_attr_set(dev, ptr,
+						     sparx5_netdevice_check,
+						     sparx5_port_attr_set);
+		return notifier_from_errno(err);
+	}
+
+	return NOTIFY_DONE;
+}
+
+int sparx5_register_notifier_blocks(struct sparx5 *s5)
+{
+	int err;
+
+	s5->netdevice_nb.notifier_call = sparx5_netdevice_event;
+	err = register_netdevice_notifier(&s5->netdevice_nb);
+	if (err)
+		return err;
+
+	s5->switchdev_nb.notifier_call = sparx5_switchdev_event;
+	err = register_switchdev_notifier(&s5->switchdev_nb);
+	if (err)
+		goto err_switchdev_nb;
+
+	s5->switchdev_blocking_nb.notifier_call = sparx5_switchdev_blocking_event;
+	err = register_switchdev_blocking_notifier(&s5->switchdev_blocking_nb);
+	if (err)
+		goto err_switchdev_blocking_nb;
+
+	sparx5_owq = alloc_ordered_workqueue("sparx5_order", 0);
+	if (!sparx5_owq)
+		goto err_switchdev_blocking_nb;
+
+	return 0;
+
+err_switchdev_blocking_nb:
+	unregister_switchdev_notifier(&s5->switchdev_nb);
+err_switchdev_nb:
+	unregister_netdevice_notifier(&s5->netdevice_nb);
+
+	return err;
+}
+
+void sparx5_unregister_notifier_blocks(struct sparx5 *s5)
+{
+	destroy_workqueue(sparx5_owq);
+
+	unregister_switchdev_blocking_notifier(&s5->switchdev_blocking_nb);
+	unregister_switchdev_notifier(&s5->switchdev_nb);
+	unregister_netdevice_notifier(&s5->netdevice_nb);
+}
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:55 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:55 +0200
Subject: [PATCH net-next 08/10] net: sparx5: add calendar bandwidth allocation
 support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-9-steen.hegelund@microchip.com>

This configures the Sparx5 calendars according to the bandwidth
requested in the Device Tree nodes.
It also checks if the total requested bandwidth is within the
specs of the detected Sparx5 models limits.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   2 +-
 .../microchip/sparx5/sparx5_calendar.c        | 596 ++++++++++++++++++
 .../ethernet/microchip/sparx5/sparx5_main.c   |   9 +-
 .../ethernet/microchip/sparx5/sparx5_main.h   |   4 +
 4 files changed, 609 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index d2788e8b7798..e7dea25eb479 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
  sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o sparx5_vlan.o \
- sparx5_switchdev.o
+ sparx5_switchdev.o sparx5_calendar.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c b/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c
new file mode 100644
index 000000000000..76a8bb596aec
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c
@@ -0,0 +1,596 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+
+/* QSYS calendar information */
+#define SPX5_PORTS_PER_CALREG          10  /* Ports mapped in a calendar register */
+#define SPX5_CALBITS_PER_PORT          3   /* Bit per port in calendar register */
+
+/* DSM calendar information */
+#define SPX5_DSM_CAL_LEN               64
+#define SPX5_DSM_CAL_EMPTY             0xFFFF
+#define SPX5_DSM_CAL_MAX_DEVS_PER_TAXI 13
+#define SPX5_DSM_CAL_TAXIS             8
+#define SPX5_DSM_CAL_BW_LOSS           553
+
+#define SPX5_TAXI_PORT_MAX             70
+
+#define SPEED_12500                    12500
+
+/* Maps from taxis to port numbers */
+static u32 sparx5_taxi_ports[SPX5_DSM_CAL_TAXIS][SPX5_DSM_CAL_MAX_DEVS_PER_TAXI] = {
+	{57, 12, 0, 1, 2, 16, 17, 18, 19, 20, 21, 22, 23},
+	{58, 13, 3, 4, 5, 24, 25, 26, 27, 28, 29, 30, 31},
+	{59, 14, 6, 7, 8, 32, 33, 34, 35, 36, 37, 38, 39},
+	{60, 15, 9, 10, 11, 40, 41, 42, 43, 44, 45, 46, 47},
+	{61, 48, 49, 50, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+	{62, 51, 52, 53, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+	{56, 63, 54, 55, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+	{64, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+};
+
+struct sparx5_calendar_data {
+	u32 schedule[SPX5_DSM_CAL_LEN];
+	u32 avg_dist[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+	u32 taxi_ports[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+	u32 taxi_speeds[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+	u32 dev_slots[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+	u32 new_slots[SPX5_DSM_CAL_LEN];
+	u32 temp_sched[SPX5_DSM_CAL_LEN];
+	u32 indices[SPX5_DSM_CAL_LEN];
+	u32 short_list[SPX5_DSM_CAL_LEN];
+	u32 long_list[SPX5_DSM_CAL_LEN];
+};
+
+static u32 sparx5_target_bandwidth(struct sparx5 *sparx5)
+{
+	switch (sparx5->target_ct) {
+	case SPX5_TARGET_CT_7546:
+	case SPX5_TARGET_CT_7546TSN:
+		return 65000;
+	case SPX5_TARGET_CT_7549:
+	case SPX5_TARGET_CT_7549TSN:
+		return 91000;
+	case SPX5_TARGET_CT_7552:
+	case SPX5_TARGET_CT_7552TSN:
+		return 129000;
+	case SPX5_TARGET_CT_7556:
+	case SPX5_TARGET_CT_7556TSN:
+		return 161000;
+	case SPX5_TARGET_CT_7558:
+	case SPX5_TARGET_CT_7558TSN:
+		return 201000;
+	default:
+		return 0;
+	}
+}
+
+/* This is used in calendar configuration */
+enum sparx5_cal_bw {
+	SPX5_CAL_SPEED_NONE = 0,
+	SPX5_CAL_SPEED_1G   = 1,
+	SPX5_CAL_SPEED_2G5  = 2,
+	SPX5_CAL_SPEED_5G   = 3,
+	SPX5_CAL_SPEED_10G  = 4,
+	SPX5_CAL_SPEED_25G  = 5,
+	SPX5_CAL_SPEED_0G5  = 6,
+	SPX5_CAL_SPEED_12G5 = 7
+};
+
+static u32 sparx5_clk_to_bandwidth(enum sparx5_core_clockfreq cclock)
+{
+	switch (cclock) {
+	case SPX5_CORE_CLOCK_250MHZ: return 83000; /* 250000 / 3 */
+	case SPX5_CORE_CLOCK_500MHZ: return 166000; /* 500000 / 3 */
+	case SPX5_CORE_CLOCK_625MHZ: return  208000; /* 625000 / 3 */
+	default: return 0;
+	}
+	return 0;
+}
+
+static u32 sparx5_cal_speed_to_value(enum sparx5_cal_bw speed)
+{
+	switch (speed) {
+	case SPX5_CAL_SPEED_1G:   return 1000;
+	case SPX5_CAL_SPEED_2G5:  return 2500;
+	case SPX5_CAL_SPEED_5G:   return 5000;
+	case SPX5_CAL_SPEED_10G:  return 10000;
+	case SPX5_CAL_SPEED_25G:  return 25000;
+	case SPX5_CAL_SPEED_0G5:  return 500;
+	case SPX5_CAL_SPEED_12G5: return 12500;
+	default: return 0;
+	}
+}
+
+static u32 sparx5_bandwidth_to_calendar(u32 bw)
+{
+	switch (bw) {
+	case SPEED_10:      return SPX5_CAL_SPEED_0G5;
+	case SPEED_100:     return SPX5_CAL_SPEED_0G5;
+	case SPEED_1000:    return SPX5_CAL_SPEED_1G;
+	case SPEED_2500:    return SPX5_CAL_SPEED_2G5;
+	case SPEED_5000:    return SPX5_CAL_SPEED_5G;
+	case SPEED_10000:   return SPX5_CAL_SPEED_10G;
+	case SPEED_12500:   return SPX5_CAL_SPEED_12G5;
+	case SPEED_25000:   return SPX5_CAL_SPEED_25G;
+	case SPEED_UNKNOWN: return SPX5_CAL_SPEED_1G;
+	default:            return SPX5_CAL_SPEED_NONE;
+	}
+}
+
+static enum sparx5_cal_bw sparx5_get_port_cal_speed(struct sparx5 *sparx5,
+						    u32 portno)
+{
+	struct sparx5_port *port;
+
+	if (portno >= SPX5_PORTS) {
+		/* Internal ports */
+		if (portno == SPX5_PORT_CPU_0 || portno == SPX5_PORT_CPU_1) {
+			/* Equals 1.25G */
+			return SPX5_CAL_SPEED_2G5;
+		} else if (portno == SPX5_PORT_VD0) {
+			/* IPMC only idle BW */
+			return SPX5_CAL_SPEED_NONE;
+		} else if (portno == SPX5_PORT_VD1) {
+			/* OAM only idle BW */
+			return SPX5_CAL_SPEED_NONE;
+		} else if (portno == SPX5_PORT_VD2) {
+			/* IPinIP gets only idle BW */
+			return SPX5_CAL_SPEED_NONE;
+		}
+		/* not in port map */
+		return SPX5_CAL_SPEED_NONE;
+	}
+	/* Front ports - may be used */
+	port = sparx5->ports[portno];
+	if (!port)
+		return SPX5_CAL_SPEED_NONE;
+	return sparx5_bandwidth_to_calendar(port->conf.bandwidth);
+}
+
+/* Auto configure the QSYS calendar based on port configuration */
+int sparx5_config_auto_calendar(struct sparx5 *sparx5)
+{
+	u32 cal[7], value, idx, portno;
+	u32 max_core_bw;
+	u32 total_bw = 0, used_port_bw = 0;
+	int err = 0;
+	enum sparx5_cal_bw spd;
+
+	memset(cal, 0, sizeof(cal));
+
+	max_core_bw = sparx5_clk_to_bandwidth(sparx5->coreclock);
+	if (max_core_bw == 0) {
+		dev_err(sparx5->dev, "Core clock not supported");
+		return -EINVAL;
+	}
+
+	/* Setup the calendar with the bandwidth to each port */
+	for (portno = 0; portno < SPX5_PORTS_ALL; portno++) {
+		u64 reg, offset, this_bw;
+
+		spd = sparx5_get_port_cal_speed(sparx5, portno);
+		if (spd == SPX5_CAL_SPEED_NONE)
+			continue;
+
+		this_bw = sparx5_cal_speed_to_value(spd);
+		if (portno < SPX5_PORTS)
+			used_port_bw += this_bw;
+		else
+			/* Internal ports are granted half the value */
+			this_bw = this_bw / 2;
+		total_bw += this_bw;
+		reg = portno;
+		offset = do_div(reg, SPX5_PORTS_PER_CALREG);
+		cal[reg] |= spd << (offset * SPX5_CALBITS_PER_PORT);
+	}
+
+	if (used_port_bw > sparx5_target_bandwidth(sparx5)) {
+		dev_err(sparx5->dev,
+			"Port BW %u above target BW %u\n",
+			used_port_bw, sparx5_target_bandwidth(sparx5));
+		return -EINVAL;
+	}
+
+	if (total_bw > max_core_bw) {
+		dev_err(sparx5->dev,
+			"Total BW %u above switch core BW %u\n",
+			total_bw, max_core_bw);
+		return -EINVAL;
+	}
+
+	/* Halt the calendar while changing it */
+	spx5_rmw(QSYS_CAL_CTRL_CAL_MODE_SET(10),
+		 QSYS_CAL_CTRL_CAL_MODE,
+		 sparx5, QSYS_CAL_CTRL);
+
+	/* Assign port bandwidth to auto calendar */
+	for (idx = 0; idx < ARRAY_SIZE(cal); idx++)
+		spx5_wr(cal[idx], sparx5, QSYS_CAL_AUTO(idx));
+
+	/* Increase grant rate of all ports to account for
+	 * core clock ppm deviations
+	 */
+	spx5_rmw(QSYS_CAL_CTRL_CAL_AUTO_GRANT_RATE_SET(671), /* 672->671 */
+		 QSYS_CAL_CTRL_CAL_AUTO_GRANT_RATE,
+		 sparx5,
+		 QSYS_CAL_CTRL);
+
+	/* Grant idle usage to VD 0-2 */
+	for (idx = 2; idx < 5; idx++)
+		spx5_wr(HSCH_OUTB_SHARE_ENA_OUTB_SHARE_ENA_SET(12),
+			sparx5,
+			HSCH_OUTB_SHARE_ENA(idx));
+
+	/* Enable Auto mode */
+	spx5_rmw(QSYS_CAL_CTRL_CAL_MODE_SET(8),
+		 QSYS_CAL_CTRL_CAL_MODE,
+		 sparx5, QSYS_CAL_CTRL);
+
+	/* Verify successful calendar config */
+	value = spx5_rd(sparx5, QSYS_CAL_CTRL);
+	if (QSYS_CAL_CTRL_CAL_AUTO_ERROR_GET(value)) {
+		dev_err(sparx5->dev, "QSYS calendar error\n");
+		err = -EINVAL;
+	}
+	return err;
+}
+
+static u32 sparx5_dsm_exb_gcd(u32 a, u32 b)
+{
+	if (b == 0)
+		return a;
+	return sparx5_dsm_exb_gcd(b, a % b);
+}
+
+static u32 sparx5_dsm_cal_len(u32 *cal)
+{
+	u32 idx = 0, len = 0;
+
+	while (idx < SPX5_DSM_CAL_LEN) {
+		if (cal[idx] != SPX5_DSM_CAL_EMPTY)
+			len++;
+		idx++;
+	}
+	return len;
+}
+
+static u32 sparx5_dsm_cp_cal(u32 *sched)
+{
+	u32 idx = 0, tmp;
+
+	while (idx < SPX5_DSM_CAL_LEN) {
+		if (sched[idx] != SPX5_DSM_CAL_EMPTY) {
+			tmp = sched[idx];
+			sched[idx] = SPX5_DSM_CAL_EMPTY;
+			return tmp;
+		}
+		idx++;
+	}
+	return SPX5_DSM_CAL_EMPTY;
+}
+
+static int sparx5_dsm_calendar_calc(struct sparx5 *sparx5, u32 taxi,
+				    struct sparx5_calendar_data *data)
+{
+	bool slow_mode;
+	u32 gcd, idx, sum, min, factor;
+	u32 num_of_slots, slot_spd, empty_slots;
+	u32 taxi_bw, clk_period_ps;
+
+	clk_period_ps = sparx5_clk_period(sparx5->coreclock);
+	taxi_bw = 128 * 1000000 / clk_period_ps;
+	slow_mode = !!(clk_period_ps > 2000);
+	memcpy(data->taxi_ports, &sparx5_taxi_ports[taxi],
+	       sizeof(data->taxi_ports));
+
+	for (idx = 0; idx < SPX5_DSM_CAL_LEN; idx++) {
+		data->new_slots[idx] = SPX5_DSM_CAL_EMPTY;
+		data->schedule[idx] = SPX5_DSM_CAL_EMPTY;
+		data->temp_sched[idx] = SPX5_DSM_CAL_EMPTY;
+	}
+	/* Default empty calendar */
+	data->schedule[0] = SPX5_DSM_CAL_MAX_DEVS_PER_TAXI;
+
+	/* Map ports to taxi positions */
+	for (idx = 0; idx < SPX5_DSM_CAL_MAX_DEVS_PER_TAXI; idx++) {
+		u32 portno = data->taxi_ports[idx];
+
+		if (portno < SPX5_TAXI_PORT_MAX) {
+			data->taxi_speeds[idx] = sparx5_cal_speed_to_value
+				(sparx5_get_port_cal_speed(sparx5, portno));
+		} else {
+			data->taxi_speeds[idx] = 0;
+		}
+	}
+
+	sum = 0;
+	min = 25000;
+	for (idx = 0; idx < ARRAY_SIZE(data->taxi_speeds); idx++) {
+		u32 jdx;
+
+		sum += data->taxi_speeds[idx];
+		if (data->taxi_speeds[idx] && data->taxi_speeds[idx] < min)
+			min = data->taxi_speeds[idx];
+		gcd = min;
+		for (jdx = 0; jdx < ARRAY_SIZE(data->taxi_speeds); jdx++)
+			gcd = sparx5_dsm_exb_gcd(gcd, data->taxi_speeds[jdx]);
+	}
+	if (sum == 0) /* Empty calendar */
+		return 0;
+	/* Make room for overhead traffic */
+	factor = 100 * 100 * 1000 / (100 * 100 - SPX5_DSM_CAL_BW_LOSS);
+
+	if (sum * factor > (taxi_bw * 1000)) {
+		dev_err(sparx5->dev,
+			"Taxi %u, Requested BW %u above available BW %u\n",
+			taxi, sum, taxi_bw);
+		return -EINVAL;
+	}
+	for (idx = 0; idx < 4; idx++) {
+		u32 raw_spd;
+
+		if (idx == 0)
+			raw_spd = gcd / 5;
+		else if (idx == 1)
+			raw_spd = gcd / 2;
+		else if (idx == 2)
+			raw_spd = gcd;
+		else
+			raw_spd = min;
+		slot_spd = raw_spd * factor / 1000;
+		num_of_slots = taxi_bw / slot_spd;
+		if (num_of_slots <= 64)
+			break;
+	}
+
+	num_of_slots = num_of_slots > 64 ? 64 : num_of_slots;
+	slot_spd = taxi_bw / num_of_slots;
+
+	sum = 0;
+	for (idx = 0; idx < ARRAY_SIZE(data->taxi_speeds); idx++) {
+		u32 spd = data->taxi_speeds[idx];
+		u32 adjusted_speed = data->taxi_speeds[idx] * factor / 1000;
+
+		if (adjusted_speed > 0) {
+			data->avg_dist[idx] = (128 * 1000000 * 10) /
+				(adjusted_speed * clk_period_ps);
+		} else {
+			data->avg_dist[idx] = -1;
+		}
+		data->dev_slots[idx] = ((spd * factor / slot_spd) + 999) / 1000;
+		if (spd != 25000 && (spd != 10000 || !slow_mode)) {
+			if (num_of_slots < (5 * data->dev_slots[idx])) {
+				dev_err(sparx5->dev,
+					"Taxi %u, speed %u, Low slot sep.\n",
+					taxi, spd);
+				return -EINVAL;
+			}
+		}
+		sum += data->dev_slots[idx];
+		if (sum > num_of_slots) {
+			dev_err(sparx5->dev,
+				"Taxi %u with overhead factor %u\n",
+				taxi, factor);
+			return -EINVAL;
+		}
+	}
+
+	empty_slots = num_of_slots - sum;
+
+	for (idx = 0; idx < empty_slots; idx++)
+		data->schedule[idx] = SPX5_DSM_CAL_MAX_DEVS_PER_TAXI;
+
+	for (idx = 1; idx < num_of_slots; idx++) {
+		u32 indices_len = 0;
+		u32 slot, jdx, kdx, ts;
+		s32 cnt;
+		u32 num_of_old_slots, num_of_new_slots, tgt_score;
+
+		for (slot = 0; slot < ARRAY_SIZE(data->dev_slots); slot++) {
+			if (data->dev_slots[slot] == idx) {
+				data->indices[indices_len] = slot;
+				indices_len++;
+			}
+		}
+		if (indices_len == 0)
+			continue;
+		kdx = 0;
+		for (slot = 0; slot < idx; slot++) {
+			for (jdx = 0; jdx < indices_len; jdx++, kdx++)
+				data->new_slots[kdx] = data->indices[jdx];
+		}
+
+		for (slot = 0; slot < SPX5_DSM_CAL_LEN; slot++) {
+			if (data->schedule[slot] == SPX5_DSM_CAL_EMPTY)
+				break;
+		}
+
+		num_of_old_slots =  slot;
+		num_of_new_slots =  kdx;
+		cnt = 0;
+		ts = 0;
+
+		if (num_of_new_slots > num_of_old_slots) {
+			memcpy(data->short_list, data->schedule,
+			       sizeof(data->short_list));
+			memcpy(data->long_list, data->new_slots,
+			       sizeof(data->long_list));
+			tgt_score = 100000 * num_of_old_slots /
+				num_of_new_slots;
+		} else {
+			memcpy(data->short_list, data->new_slots,
+			       sizeof(data->short_list));
+			memcpy(data->long_list, data->schedule,
+			       sizeof(data->long_list));
+			tgt_score = 100000 * num_of_new_slots /
+				num_of_old_slots;
+		}
+
+		while (sparx5_dsm_cal_len(data->short_list) > 0 ||
+		       sparx5_dsm_cal_len(data->long_list) > 0) {
+			u32 act = 0;
+
+			if (sparx5_dsm_cal_len(data->short_list) > 0) {
+				data->temp_sched[ts] =
+					sparx5_dsm_cp_cal(data->short_list);
+				ts++;
+				cnt += 100000;
+				act = 1;
+			}
+			while (sparx5_dsm_cal_len(data->long_list) > 0 &&
+			       cnt > 0) {
+				data->temp_sched[ts] =
+					sparx5_dsm_cp_cal(data->long_list);
+				ts++;
+				cnt -= tgt_score;
+				act = 1;
+			}
+			if (act == 0) {
+				dev_err(sparx5->dev,
+					"Error in DSM calendar calculation\n");
+				return -EINVAL;
+			}
+		}
+
+		for (slot = 0; slot < SPX5_DSM_CAL_LEN; slot++) {
+			if (data->temp_sched[slot] == SPX5_DSM_CAL_EMPTY)
+				break;
+		}
+		for (slot = 0; slot < SPX5_DSM_CAL_LEN; slot++) {
+			data->schedule[slot] = data->temp_sched[slot];
+			data->temp_sched[slot] = SPX5_DSM_CAL_EMPTY;
+			data->new_slots[slot] = SPX5_DSM_CAL_EMPTY;
+		}
+	}
+	return 0;
+}
+
+static int sparx5_dsm_calendar_check(struct sparx5 *sparx5,
+				     struct sparx5_calendar_data *data)
+{
+	u32 num_of_slots, idx, port;
+	int cnt, max_dist;
+	u32 slot_indices[SPX5_DSM_CAL_LEN], distances[SPX5_DSM_CAL_LEN];
+	u32 cal_length = sparx5_dsm_cal_len(data->schedule);
+
+	for (port = 0; port < SPX5_DSM_CAL_MAX_DEVS_PER_TAXI; port++) {
+		num_of_slots = 0;
+		max_dist = data->avg_dist[port];
+		for (idx = 0; idx < SPX5_DSM_CAL_LEN; idx++) {
+			slot_indices[idx] = SPX5_DSM_CAL_EMPTY;
+			distances[idx] = SPX5_DSM_CAL_EMPTY;
+		}
+
+		for (idx = 0; idx < cal_length; idx++) {
+			if (data->schedule[idx] == port) {
+				slot_indices[num_of_slots] = idx;
+				num_of_slots++;
+			}
+		}
+
+		slot_indices[num_of_slots] = slot_indices[0] + cal_length;
+
+		for (idx = 0; idx < num_of_slots; idx++) {
+			distances[idx] = (slot_indices[idx + 1] -
+					  slot_indices[idx]) * 10;
+		}
+
+		for (idx = 0; idx < num_of_slots; idx++) {
+			u32 jdx, kdx;
+
+			cnt = distances[idx] - max_dist;
+			if (cnt < 0)
+				cnt = -cnt;
+			kdx = 0;
+			for (jdx = (idx + 1) % num_of_slots;
+			     jdx != idx;
+			     jdx = (jdx + 1) % num_of_slots, kdx++) {
+				cnt =  cnt + distances[jdx] - max_dist;
+				if (cnt < 0)
+					cnt = -cnt;
+				if (cnt > max_dist)
+					goto check_err;
+			}
+		}
+	}
+	return 0;
+check_err:
+	dev_err(sparx5->dev,
+		"Port %u: distance %u above limit %d\n",
+		port, cnt, max_dist);
+	return -EINVAL;
+}
+
+static int sparx5_dsm_calendar_update(struct sparx5 *sparx5, u32 taxi,
+				      struct sparx5_calendar_data *data)
+{
+	u32 idx;
+	u32 cal_len = sparx5_dsm_cal_len(data->schedule), len;
+
+	spx5_wr(DSM_TAXI_CAL_CFG_CAL_PGM_ENA_SET(1),
+		sparx5,
+		DSM_TAXI_CAL_CFG(taxi));
+	for (idx = 0; idx < cal_len; idx++) {
+		spx5_rmw(DSM_TAXI_CAL_CFG_CAL_IDX_SET(idx),
+			 DSM_TAXI_CAL_CFG_CAL_IDX,
+			 sparx5,
+			 DSM_TAXI_CAL_CFG(taxi));
+		spx5_rmw(DSM_TAXI_CAL_CFG_CAL_PGM_VAL_SET(data->schedule[idx]),
+			 DSM_TAXI_CAL_CFG_CAL_PGM_VAL,
+			 sparx5,
+			 DSM_TAXI_CAL_CFG(taxi));
+	}
+	spx5_wr(DSM_TAXI_CAL_CFG_CAL_PGM_ENA_SET(0),
+		sparx5,
+		DSM_TAXI_CAL_CFG(taxi));
+	len = DSM_TAXI_CAL_CFG_CAL_CUR_LEN_GET(spx5_rd(sparx5,
+						       DSM_TAXI_CAL_CFG(taxi)));
+	if (len != cal_len - 1)
+		goto update_err;
+	return 0;
+update_err:
+	dev_err(sparx5->dev, "Incorrect calendar length: %u\n", len);
+	return -EINVAL;
+}
+
+/* Configure the DSM calendar based on port configuration */
+int sparx5_config_dsm_calendar(struct sparx5 *sparx5)
+{
+	int taxi;
+	struct sparx5_calendar_data *data;
+	int err = 0;
+
+	data = kzalloc(sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	for (taxi = 0; taxi < SPX5_DSM_CAL_TAXIS; ++taxi) {
+		err = sparx5_dsm_calendar_calc(sparx5, taxi, data);
+		if (err) {
+			dev_err(sparx5->dev, "DSM calendar calculation failed\n");
+			goto cal_out;
+		}
+		err = sparx5_dsm_calendar_check(sparx5, data);
+		if (err) {
+			dev_err(sparx5->dev, "DSM calendar check failed\n");
+			goto cal_out;
+		}
+		err = sparx5_dsm_calendar_update(sparx5, taxi, data);
+		if (err) {
+			dev_err(sparx5->dev, "DSM calendar update failed\n");
+			goto cal_out;
+		}
+	}
+cal_out:
+	kfree(data);
+	return err;
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 8121f0b1c0ea..7c101afc7322 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -616,7 +616,14 @@ static int sparx5_start(struct sparx5 *sparx5)
 	/* Enable queue limitation watermarks */
 	sparx5_qlim_set(sparx5);
 
-	/* Resource calendar support to be added in later patches */
+	err = sparx5_config_auto_calendar(sparx5);
+	if (err)
+		return err;
+
+	err = sparx5_config_dsm_calendar(sparx5);
+	if (err)
+		return err;
+
 
 	/* Init mact_sw struct */
 	mutex_init(&sparx5->mact_lock);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index e427adad4555..e9c48915842d 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -196,6 +196,10 @@ int sparx5_vlan_vid_add(struct sparx5_port *port, u16 vid, bool pvid,
 int sparx5_vlan_vid_del(struct sparx5_port *port, u16 vid);
 void sparx5_vlan_port_apply(struct sparx5 *sparx5, struct sparx5_port *port);
 
+/* sparx5_calendar.c */
+int sparx5_config_auto_calendar(struct sparx5 *sparx5);
+int sparx5_config_dsm_calendar(struct sparx5 *sparx5);
+
 /* sparx5_netdev.c */
 bool sparx5_netdevice_check(const struct net_device *dev);
 struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno);
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:56 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:56 +0200
Subject: [PATCH net-next 09/10] net: sparx5: add ethtool configuration and
 statistics support
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-10-steen.hegelund@microchip.com>

This adds statistic counters for the network interfaces provided
by the driver.  It also adds CPU port counters (which are not
exposed by ethtool).
This also adds support for configuring the network interface
parameters via ethtool: speed, duplex, aneg etc.

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
---
 .../net/ethernet/microchip/sparx5/Makefile    |   2 +-
 .../microchip/sparx5/sparx5_ethtool.c         | 999 ++++++++++++++++++
 .../ethernet/microchip/sparx5/sparx5_main.c   |   4 +
 .../ethernet/microchip/sparx5/sparx5_main.h   |  12 +
 .../ethernet/microchip/sparx5/sparx5_netdev.c |   2 +
 5 files changed, 1018 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile b/drivers/net/ethernet/microchip/sparx5/Makefile
index e7dea25eb479..5df99f9a12e9 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
  sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_mactable.o sparx5_vlan.o \
- sparx5_switchdev.o sparx5_calendar.o
+ sparx5_switchdev.o sparx5_calendar.o sparx5_ethtool.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
new file mode 100644
index 000000000000..5cbde50533b9
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
@@ -0,0 +1,999 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/ethtool.h>
+
+#include "sparx5_main_regs.h"
+#include "sparx5_main.h"
+#include "sparx5_port.h"
+
+/* Index of ANA_AC port counters */
+#define SPX5_PORT_POLICER_DROPS 0
+
+/* Add a potentially wrapping 32 bit value to a 64 bit counter */
+static void sparx5_update_counter(u64 *cnt, u32 val)
+{
+	if (val < (*cnt & U32_MAX))
+		*cnt += (u64)1 << 32; /* value has wrapped */
+
+	*cnt = (*cnt & ~(u64)U32_MAX) + val;
+}
+
+/* Get a set of Queue System statistics */
+static void sparx5_xqs_prio_stats(struct sparx5 *sparx5,
+				  u32 addr,
+				  u64 *stats)
+{
+	int idx;
+
+	for (idx = 0; idx < 2 * SPX5_PRIOS; ++idx, ++addr, ++stats)
+		sparx5_update_counter(stats, spx5_rd(sparx5, XQS_CNT(addr)));
+}
+
+#define SPX5_STAT_GET(sname)        portstats[spx5_stats_##sname]
+#define SPX5_STAT_SUM(sname)        (portstats[spx5_stats_##sname] + \
+				     portstats[spx5_stats_pmac_##sname])
+#define SPX5_STAT_XQS_PRIOS_COUNTER_SUM(sname)    \
+	(portstats[spx5_stats_green_p0_##sname] + \
+	portstats[spx5_stats_green_p1_##sname] +  \
+	portstats[spx5_stats_green_p2_##sname] +  \
+	portstats[spx5_stats_green_p3_##sname] +  \
+	portstats[spx5_stats_green_p4_##sname] +  \
+	portstats[spx5_stats_green_p5_##sname] +  \
+	portstats[spx5_stats_green_p6_##sname] +  \
+	portstats[spx5_stats_green_p7_##sname] +  \
+	portstats[spx5_stats_yellow_p0_##sname] + \
+	portstats[spx5_stats_yellow_p1_##sname] + \
+	portstats[spx5_stats_yellow_p2_##sname] + \
+	portstats[spx5_stats_yellow_p3_##sname] + \
+	portstats[spx5_stats_yellow_p4_##sname] + \
+	portstats[spx5_stats_yellow_p5_##sname] + \
+	portstats[spx5_stats_yellow_p6_##sname] + \
+	portstats[spx5_stats_yellow_p7_##sname])
+
+enum sparx5_stats_entry {
+	spx5_stats_rx_in_bytes,
+	spx5_stats_rx_symbol_err,
+	spx5_stats_rx_pause,
+	spx5_stats_rx_unsup_opcode,
+	spx5_stats_rx_ok_bytes,
+	spx5_stats_rx_bad_bytes,
+	spx5_stats_rx_unicast,
+	spx5_stats_rx_multicast,
+	spx5_stats_rx_broadcast,
+	spx5_stats_rx_crc_err,
+	spx5_stats_rx_undersize,
+	spx5_stats_rx_fragments,
+	spx5_stats_rx_inrangelen_err,
+	spx5_stats_rx_outofrangelen_err,
+	spx5_stats_rx_oversize,
+	spx5_stats_rx_jabbers,
+	spx5_stats_rx_size64,
+	spx5_stats_rx_size65_127,
+	spx5_stats_rx_size128_255,
+	spx5_stats_rx_size256_511,
+	spx5_stats_rx_size512_1023,
+	spx5_stats_rx_size1024_1518,
+	spx5_stats_rx_size1519_max,
+	spx5_stats_pmac_rx_symbol_err,
+	spx5_stats_pmac_rx_pause,
+	spx5_stats_pmac_rx_unsup_opcode,
+	spx5_stats_pmac_rx_ok_bytes,
+	spx5_stats_pmac_rx_bad_bytes,
+	spx5_stats_pmac_rx_unicast,
+	spx5_stats_pmac_rx_multicast,
+	spx5_stats_pmac_rx_broadcast,
+	spx5_stats_pmac_rx_crc_err,
+	spx5_stats_pmac_rx_undersize,
+	spx5_stats_pmac_rx_fragments,
+	spx5_stats_pmac_rx_inrangelen_err,
+	spx5_stats_pmac_rx_outofrangelen_err,
+	spx5_stats_pmac_rx_oversize,
+	spx5_stats_pmac_rx_jabbers,
+	spx5_stats_pmac_rx_size64,
+	spx5_stats_pmac_rx_size65_127,
+	spx5_stats_pmac_rx_size128_255,
+	spx5_stats_pmac_rx_size256_511,
+	spx5_stats_pmac_rx_size512_1023,
+	spx5_stats_pmac_rx_size1024_1518,
+	spx5_stats_pmac_rx_size1519_max,
+	spx5_stats_green_p0_rx_fwd,
+	spx5_stats_green_p1_rx_fwd,
+	spx5_stats_green_p2_rx_fwd,
+	spx5_stats_green_p3_rx_fwd,
+	spx5_stats_green_p4_rx_fwd,
+	spx5_stats_green_p5_rx_fwd,
+	spx5_stats_green_p6_rx_fwd,
+	spx5_stats_green_p7_rx_fwd,
+	spx5_stats_yellow_p0_rx_fwd,
+	spx5_stats_yellow_p1_rx_fwd,
+	spx5_stats_yellow_p2_rx_fwd,
+	spx5_stats_yellow_p3_rx_fwd,
+	spx5_stats_yellow_p4_rx_fwd,
+	spx5_stats_yellow_p5_rx_fwd,
+	spx5_stats_yellow_p6_rx_fwd,
+	spx5_stats_yellow_p7_rx_fwd,
+	spx5_stats_green_p0_rx_port_drop,
+	spx5_stats_green_p1_rx_port_drop,
+	spx5_stats_green_p2_rx_port_drop,
+	spx5_stats_green_p3_rx_port_drop,
+	spx5_stats_green_p4_rx_port_drop,
+	spx5_stats_green_p5_rx_port_drop,
+	spx5_stats_green_p6_rx_port_drop,
+	spx5_stats_green_p7_rx_port_drop,
+	spx5_stats_yellow_p0_rx_port_drop,
+	spx5_stats_yellow_p1_rx_port_drop,
+	spx5_stats_yellow_p2_rx_port_drop,
+	spx5_stats_yellow_p3_rx_port_drop,
+	spx5_stats_yellow_p4_rx_port_drop,
+	spx5_stats_yellow_p5_rx_port_drop,
+	spx5_stats_yellow_p6_rx_port_drop,
+	spx5_stats_yellow_p7_rx_port_drop,
+	spx5_stats_rx_local_drop,
+	spx5_stats_rx_port_policer_drop,
+	spx5_stats_tx_out_bytes,
+	spx5_stats_tx_pause,
+	spx5_stats_tx_ok_bytes,
+	spx5_stats_tx_unicast,
+	spx5_stats_tx_multicast,
+	spx5_stats_tx_broadcast,
+	spx5_stats_tx_size64,
+	spx5_stats_tx_size65_127,
+	spx5_stats_tx_size128_255,
+	spx5_stats_tx_size256_511,
+	spx5_stats_tx_size512_1023,
+	spx5_stats_tx_size1024_1518,
+	spx5_stats_tx_size1519_max,
+	spx5_stats_tx_multi_coll,
+	spx5_stats_tx_late_coll,
+	spx5_stats_tx_xcoll,
+	spx5_stats_tx_defer,
+	spx5_stats_tx_xdefer,
+	spx5_stats_tx_backoff1,
+	spx5_stats_pmac_tx_pause,
+	spx5_stats_pmac_tx_ok_bytes,
+	spx5_stats_pmac_tx_unicast,
+	spx5_stats_pmac_tx_multicast,
+	spx5_stats_pmac_tx_broadcast,
+	spx5_stats_pmac_tx_size64,
+	spx5_stats_pmac_tx_size65_127,
+	spx5_stats_pmac_tx_size128_255,
+	spx5_stats_pmac_tx_size256_511,
+	spx5_stats_pmac_tx_size512_1023,
+	spx5_stats_pmac_tx_size1024_1518,
+	spx5_stats_pmac_tx_size1519_max,
+	spx5_stats_green_p0_tx_port,
+	spx5_stats_green_p1_tx_port,
+	spx5_stats_green_p2_tx_port,
+	spx5_stats_green_p3_tx_port,
+	spx5_stats_green_p4_tx_port,
+	spx5_stats_green_p5_tx_port,
+	spx5_stats_green_p6_tx_port,
+	spx5_stats_green_p7_tx_port,
+	spx5_stats_yellow_p0_tx_port,
+	spx5_stats_yellow_p1_tx_port,
+	spx5_stats_yellow_p2_tx_port,
+	spx5_stats_yellow_p3_tx_port,
+	spx5_stats_yellow_p4_tx_port,
+	spx5_stats_yellow_p5_tx_port,
+	spx5_stats_yellow_p6_tx_port,
+	spx5_stats_yellow_p7_tx_port,
+	spx5_stats_tx_local_drop,
+};
+
+static const char *const sparx5_stats_layout[] = {
+	"rx_in_bytes",
+	"rx_symbol_err",
+	"rx_pause",
+	"rx_unsup_opcode",
+	"rx_ok_bytes",
+	"rx_bad_bytes",
+	"rx_unicast",
+	"rx_multicast",
+	"rx_broadcast",
+	"rx_crc_err",
+	"rx_undersize",
+	"rx_fragments",
+	"rx_inrangelen_err",
+	"rx_outofrangelen_err",
+	"rx_oversize",
+	"rx_jabbers",
+	"rx_size64",
+	"rx_size65_127",
+	"rx_size128_255",
+	"rx_size256_511",
+	"rx_size512_1023",
+	"rx_size1024_1518",
+	"rx_size1519_max",
+	"pmac_rx_symbol_err",
+	"pmac_rx_pause",
+	"pmac_rx_unsup_opcode",
+	"pmac_rx_ok_bytes",
+	"pmac_rx_bad_bytes",
+	"pmac_rx_unicast",
+	"pmac_rx_multicast",
+	"pmac_rx_broadcast",
+	"pmac_rx_crc_err",
+	"pmac_rx_undersize",
+	"pmac_rx_fragments",
+	"pmac_rx_inrangelen_err",
+	"pmac_rx_outofrangelen_err",
+	"pmac_rx_oversize",
+	"pmac_rx_jabbers",
+	"pmac_rx_size64",
+	"pmac_rx_size65_127",
+	"pmac_rx_size128_255",
+	"pmac_rx_size256_511",
+	"pmac_rx_size512_1023",
+	"pmac_rx_size1024_1518",
+	"pmac_rx_size1519_max",
+	"rx_fwd_green_p0_q",
+	"rx_fwd_green_p1_q",
+	"rx_fwd_green_p2_q",
+	"rx_fwd_green_p3_q",
+	"rx_fwd_green_p4_q",
+	"rx_fwd_green_p5_q",
+	"rx_fwd_green_p6_q",
+	"rx_fwd_green_p7_q",
+	"rx_fwd_yellow_p0_q",
+	"rx_fwd_yellow_p1_q",
+	"rx_fwd_yellow_p2_q",
+	"rx_fwd_yellow_p3_q",
+	"rx_fwd_yellow_p4_q",
+	"rx_fwd_yellow_p5_q",
+	"rx_fwd_yellow_p6_q",
+	"rx_fwd_yellow_p7_q",
+	"rx_port_drop_green_p0_q",
+	"rx_port_drop_green_p1_q",
+	"rx_port_drop_green_p2_q",
+	"rx_port_drop_green_p3_q",
+	"rx_port_drop_green_p4_q",
+	"rx_port_drop_green_p5_q",
+	"rx_port_drop_green_p6_q",
+	"rx_port_drop_green_p7_q",
+	"rx_port_drop_yellow_p0_q",
+	"rx_port_drop_yellow_p1_q",
+	"rx_port_drop_yellow_p2_q",
+	"rx_port_drop_yellow_p3_q",
+	"rx_port_drop_yellow_p4_q",
+	"rx_port_drop_yellow_p5_q",
+	"rx_port_drop_yellow_p6_q",
+	"rx_port_drop_yellow_p7_q",
+	"rx_local_drop",
+	"rx_port_policer_drop",
+	"tx_out_bytes",
+	"tx_pause",
+	"tx_ok_bytes",
+	"tx_unicast",
+	"tx_multicast",
+	"tx_broadcast",
+	"tx_size64",
+	"tx_size65_127",
+	"tx_size128_255",
+	"tx_size256_511",
+	"tx_size512_1023",
+	"tx_size1024_1518",
+	"tx_size1519_max",
+	"tx_multi_coll",
+	"tx_late_coll",
+	"tx_xcoll",
+	"tx_defer",
+	"tx_xdefer",
+	"tx_backoff1",
+	"pmac_tx_pause",
+	"pmac_tx_ok_bytes",
+	"pmac_tx_unicast",
+	"pmac_tx_multicast",
+	"pmac_tx_broadcast",
+	"pmac_tx_size64",
+	"pmac_tx_size65_127",
+	"pmac_tx_size128_255",
+	"pmac_tx_size256_511",
+	"pmac_tx_size512_1023",
+	"pmac_tx_size1024_1518",
+	"pmac_tx_size1519_max",
+	"tx_port_green_p0_q",
+	"tx_port_green_p1_q",
+	"tx_port_green_p2_q",
+	"tx_port_green_p3_q",
+	"tx_port_green_p4_q",
+	"tx_port_green_p5_q",
+	"tx_port_green_p6_q",
+	"tx_port_green_p7_q",
+	"tx_port_yellow_p0_q",
+	"tx_port_yellow_p1_q",
+	"tx_port_yellow_p2_q",
+	"tx_port_yellow_p3_q",
+	"tx_port_yellow_p4_q",
+	"tx_port_yellow_p5_q",
+	"tx_port_yellow_p6_q",
+	"tx_port_yellow_p7_q",
+	"tx_local_drop",
+};
+
+/* Device Statistics */
+static void sparx5_get_device_stats(struct sparx5 *sparx5, int portno)
+{
+	u64 *portstats = &sparx5->stats[portno * sparx5->num_stats];
+	u32 tinst = sparx5_port_dev_index(portno);
+	u32 dev = sparx5_to_high_dev(portno);
+	void __iomem *inst;
+
+	inst = spx5_inst_get(sparx5, dev, tinst);
+	sparx5_update_counter(&portstats[spx5_stats_rx_in_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_IN_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_symbol_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SYMBOL_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_pause],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_PAUSE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_unsup_opcode],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_UNSUP_OPCODE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_OK_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_bad_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_BAD_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_unicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_UC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_multicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_MC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_broadcast],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_BC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_crc_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_CRC_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_undersize],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_UNDERSIZE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_fragments],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_FRAGMENTS_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_inrangelen_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_IN_RANGE_LEN_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_outofrangelen_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_OUT_OF_RANGE_LEN_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_oversize],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_OVERSIZE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_jabbers],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_JABBERS_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size64],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE64_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size65_127],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE65TO127_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size128_255],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE128TO255_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size256_511],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE256TO511_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size512_1023],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE512TO1023_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE1024TO1518_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size1519_max],
+			      spx5_inst_rd(inst,
+					   DEV5G_RX_SIZE1519TOMAX_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_symbol_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SYMBOL_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_pause],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_PAUSE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_unsup_opcode],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_UNSUP_OPCODE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_OK_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_bad_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_BAD_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_unicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_UC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_multicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_MC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_broadcast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_BC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_crc_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_CRC_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_undersize],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_UNDERSIZE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_fragments],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_FRAGMENTS_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_inrangelen_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_IN_RANGE_LEN_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_outofrangelen_err],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_OUT_OF_RANGE_LEN_ERR_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_oversize],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_OVERSIZE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_jabbers],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_JABBERS_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size64],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE64_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size65_127],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE65TO127_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size128_255],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE128TO255_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size256_511],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE256TO511_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size512_1023],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE512TO1023_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE1024TO1518_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size1519_max],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_RX_SIZE1519TOMAX_CNT(tinst)));
+	sparx5_xqs_prio_stats(sparx5,
+			      0,
+			      &portstats[spx5_stats_green_p0_rx_fwd]);
+	sparx5_xqs_prio_stats(sparx5,
+			      16,
+			      &portstats[spx5_stats_green_p0_rx_port_drop]);
+	sparx5_update_counter(&portstats[spx5_stats_rx_local_drop],
+			      spx5_rd(sparx5, XQS_CNT(32)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_port_policer_drop],
+			      spx5_rd(sparx5,
+				      ANA_AC_PORT_STAT_LSB_CNT(portno,
+							       SPX5_PORT_POLICER_DROPS)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_out_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_OUT_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_pause],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_PAUSE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_OK_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_unicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_UC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_multicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_MC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_broadcast],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_BC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size64],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE64_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size65_127],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE65TO127_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size128_255],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE128TO255_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size256_511],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE256TO511_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size512_1023],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE512TO1023_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE1024TO1518_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size1519_max],
+			      spx5_inst_rd(inst,
+					   DEV5G_TX_SIZE1519TOMAX_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_pause],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_PAUSE_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_OK_BYTES_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_unicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_UC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_multicast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_MC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_broadcast],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_BC_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size64],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE64_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size65_127],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE65TO127_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size128_255],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE128TO255_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size256_511],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE256TO511_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size512_1023],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE512TO1023_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE1024TO1518_CNT(tinst)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size1519_max],
+			      spx5_inst_rd(inst,
+					   DEV5G_PMAC_TX_SIZE1519TOMAX_CNT(tinst)));
+	sparx5_xqs_prio_stats(sparx5,
+			      256,
+			      &portstats[spx5_stats_green_p0_tx_port]);
+	sparx5_update_counter(&portstats[spx5_stats_tx_local_drop],
+			      spx5_rd(sparx5, XQS_CNT(272)));
+}
+
+/* ASM Statistics */
+static void sparx5_get_asm_stats(struct sparx5 *sparx5, int portno)
+{
+	u64 *portstats = &sparx5->stats[portno * sparx5->num_stats];
+	void __iomem *inst = spx5_inst_get(sparx5, TARGET_ASM, 0);
+
+	sparx5_update_counter(&portstats[spx5_stats_rx_in_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_RX_IN_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_symbol_err],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SYMBOL_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_pause],
+			      spx5_inst_rd(inst,
+					   ASM_RX_PAUSE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_unsup_opcode],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_UNSUP_OPCODE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_RX_OK_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_bad_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_RX_BAD_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_unicast],
+			      spx5_inst_rd(inst,
+					   ASM_RX_UC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_multicast],
+			      spx5_inst_rd(inst,
+					   ASM_RX_MC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_broadcast],
+			      spx5_inst_rd(inst,
+					   ASM_RX_BC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_crc_err],
+			      spx5_inst_rd(inst,
+					   ASM_RX_CRC_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_undersize],
+			      spx5_inst_rd(inst,
+					   ASM_RX_UNDERSIZE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_fragments],
+			      spx5_inst_rd(inst,
+					   ASM_RX_FRAGMENTS_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_inrangelen_err],
+			      spx5_inst_rd(inst,
+					   ASM_RX_IN_RANGE_LEN_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_outofrangelen_err],
+			      spx5_inst_rd(inst,
+					   ASM_RX_OUT_OF_RANGE_LEN_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_oversize],
+			      spx5_inst_rd(inst,
+					   ASM_RX_OVERSIZE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_jabbers],
+			      spx5_inst_rd(inst,
+					   ASM_RX_JABBERS_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size64],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE64_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size65_127],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE65TO127_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size128_255],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE128TO255_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size256_511],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE256TO511_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size512_1023],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE512TO1023_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE1024TO1518_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_size1519_max],
+			      spx5_inst_rd(inst,
+					   ASM_RX_SIZE1519TOMAX_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_symbol_err],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SYMBOL_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_pause],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_PAUSE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_unsup_opcode],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_UNSUP_OPCODE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_OK_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_bad_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_BAD_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_unicast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_UC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_multicast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_MC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_broadcast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_BC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_crc_err],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_CRC_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_undersize],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_UNDERSIZE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_fragments],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_FRAGMENTS_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_inrangelen_err],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_IN_RANGE_LEN_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_outofrangelen_err],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_OUT_OF_RANGE_LEN_ERR_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_oversize],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_OVERSIZE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_jabbers],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_JABBERS_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size64],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE64_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size65_127],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE65TO127_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size128_255],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE128TO255_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size256_511],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE256TO511_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size512_1023],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE512TO1023_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE1024TO1518_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_rx_size1519_max],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_RX_SIZE1519TOMAX_CNT(portno)));
+	sparx5_xqs_prio_stats(sparx5,
+			      0,
+			      &portstats[spx5_stats_green_p0_rx_fwd]);
+	sparx5_xqs_prio_stats(sparx5,
+			      16,
+			      &portstats[spx5_stats_green_p0_rx_port_drop]);
+	sparx5_update_counter(&portstats[spx5_stats_rx_local_drop],
+			      spx5_rd(sparx5, XQS_CNT(32)));
+	sparx5_update_counter(&portstats[spx5_stats_rx_port_policer_drop],
+			      spx5_rd(sparx5,
+				      ANA_AC_PORT_STAT_LSB_CNT(portno,
+							       SPX5_PORT_POLICER_DROPS)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_out_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_TX_OUT_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_pause],
+			      spx5_inst_rd(inst,
+					   ASM_TX_PAUSE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_TX_OK_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_unicast],
+			      spx5_inst_rd(inst,
+					   ASM_TX_UC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_multicast],
+			      spx5_inst_rd(inst,
+					   ASM_TX_MC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_broadcast],
+			      spx5_inst_rd(inst,
+					   ASM_TX_BC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size64],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE64_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size65_127],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE65TO127_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size128_255],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE128TO255_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size256_511],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE256TO511_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size512_1023],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE512TO1023_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE1024TO1518_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_size1519_max],
+			      spx5_inst_rd(inst,
+					   ASM_TX_SIZE1519TOMAX_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_multi_coll],
+			      spx5_inst_rd(inst,
+					   ASM_TX_MULTI_COLL_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_late_coll],
+			      spx5_inst_rd(inst,
+					   ASM_TX_LATE_COLL_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_xcoll],
+			      spx5_inst_rd(inst,
+					   ASM_TX_XCOLL_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_defer],
+			      spx5_inst_rd(inst,
+					   ASM_TX_DEFER_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_xdefer],
+			      spx5_inst_rd(inst,
+					   ASM_TX_XDEFER_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_tx_backoff1],
+			      spx5_inst_rd(inst,
+					   ASM_TX_BACKOFF1_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_pause],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_PAUSE_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_ok_bytes],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_OK_BYTES_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_unicast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_UC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_multicast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_MC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_broadcast],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_BC_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size64],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE64_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size65_127],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE65TO127_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size128_255],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE128TO255_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size256_511],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE256TO511_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size512_1023],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE512TO1023_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size1024_1518],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE1024TO1518_CNT(portno)));
+	sparx5_update_counter(&portstats[spx5_stats_pmac_tx_size1519_max],
+			      spx5_inst_rd(inst,
+					   ASM_PMAC_TX_SIZE1519TOMAX_CNT(portno)));
+	sparx5_xqs_prio_stats(sparx5,
+			      256,
+			      &portstats[spx5_stats_green_p0_tx_port]);
+	sparx5_update_counter(&portstats[spx5_stats_tx_local_drop],
+			      spx5_rd(sparx5, XQS_CNT(272)));
+}
+
+static void sparx5_config_stats(struct sparx5 *sparx5)
+{
+	/* Enable global events for port policer drops */
+	spx5_rmw(ANA_AC_PORT_SGE_CFG_MASK_SET(0xf0f0),
+		 ANA_AC_PORT_SGE_CFG_MASK,
+		 sparx5,
+		 ANA_AC_PORT_SGE_CFG(SPX5_PORT_POLICER_DROPS));
+}
+
+static void sparx5_config_port_stats(struct sparx5 *sparx5, int portno)
+{
+	/* Clear Queue System counters */
+	spx5_wr(XQS_STAT_CFG_STAT_VIEW_SET(portno) |
+		XQS_STAT_CFG_STAT_CLEAR_SHOT_SET(3), sparx5,
+		XQS_STAT_CFG);
+
+	/* Use counter for port policer drop count */
+	spx5_rmw(ANA_AC_PORT_STAT_CFG_CFG_CNT_FRM_TYPE_SET(1) |
+		 ANA_AC_PORT_STAT_CFG_CFG_CNT_BYTE_SET(0) |
+		 ANA_AC_PORT_STAT_CFG_CFG_PRIO_MASK_SET(0xff),
+		 ANA_AC_PORT_STAT_CFG_CFG_CNT_FRM_TYPE |
+		 ANA_AC_PORT_STAT_CFG_CFG_CNT_BYTE |
+		 ANA_AC_PORT_STAT_CFG_CFG_PRIO_MASK,
+		 sparx5, ANA_AC_PORT_STAT_CFG(portno, SPX5_PORT_POLICER_DROPS));
+}
+
+static void sparx5_update_port_stats(struct sparx5 *sparx5, int portno)
+{
+	/* Set XQS port number */
+	spx5_wr(XQS_STAT_CFG_STAT_VIEW_SET(portno), sparx5, XQS_STAT_CFG);
+	if (sparx5_is_high_speed_device(&sparx5->ports[portno]->conf))
+		sparx5_get_device_stats(sparx5, portno);
+	else
+		sparx5_get_asm_stats(sparx5, portno);
+}
+
+static void sparx5_update_stats(struct sparx5 *sparx5)
+{
+	int idx;
+
+	for (idx = 0; idx < SPX5_PORTS; idx++)
+		if (sparx5->ports[idx])
+			sparx5_update_port_stats(sparx5, idx);
+}
+
+static void sparx5_check_stats_work(struct work_struct *work)
+{
+	struct delayed_work *dwork = to_delayed_work(work);
+	struct sparx5 *sparx5 = container_of(dwork,
+					     struct sparx5,
+					     stats_work);
+
+	sparx5_update_stats(sparx5);
+
+	queue_delayed_work(sparx5->stats_queue, &sparx5->stats_work,
+			   SPX5_STATS_CHECK_DELAY);
+}
+
+static int sparx5_get_sset_count(struct net_device *ndev, int sset)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	struct sparx5  *sparx5 = port->sparx5;
+
+	if (sset != ETH_SS_STATS)
+		return -EOPNOTSUPP;
+	return sparx5->num_stats;
+}
+
+static void sparx5_get_sset_strings(struct net_device *ndev, u32 sset, u8 *data)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	struct sparx5  *sparx5 = port->sparx5;
+	int idx;
+
+	if (sset != ETH_SS_STATS)
+		return;
+
+	for (idx = 0; idx < sparx5->num_stats; idx++)
+		strncpy(data + idx * ETH_GSTRING_LEN,
+			sparx5->stats_layout[idx], ETH_GSTRING_LEN);
+}
+
+static void sparx5_get_stats(struct net_device *ndev,
+			     struct ethtool_stats *stats, u64 *data)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	struct sparx5 *sparx5 = port->sparx5;
+	u64 *portstats;
+	int idx;
+
+	portstats = &sparx5->stats[port->portno * sparx5->num_stats];
+	/* Copy port counters to the ethtool buffer */
+	for (idx = 0; idx < sparx5->num_stats; idx++)
+		*data++ = portstats[idx];
+}
+
+void sparx5_get_stats64(struct net_device *ndev,
+			struct rtnl_link_stats64 *stats)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+	struct sparx5 *sparx5 = port->sparx5;
+	u64 *portstats;
+
+	if (!sparx5->stats)
+		return; /* Not initialized yet */
+
+	portstats = &sparx5->stats[port->portno * sparx5->num_stats];
+
+	stats->rx_errors = SPX5_STAT_SUM(rx_crc_err) +
+		SPX5_STAT_SUM(rx_undersize) + SPX5_STAT_SUM(rx_oversize) +
+		SPX5_STAT_SUM(rx_outofrangelen_err) +
+		SPX5_STAT_SUM(rx_symbol_err) + SPX5_STAT_SUM(rx_jabbers) +
+		SPX5_STAT_SUM(rx_fragments);
+
+	stats->rx_bytes = SPX5_STAT_SUM(rx_ok_bytes) +
+		SPX5_STAT_SUM(rx_bad_bytes);
+
+	stats->rx_packets = SPX5_STAT_SUM(rx_unicast) +
+		SPX5_STAT_SUM(rx_multicast) + SPX5_STAT_SUM(rx_broadcast) +
+		stats->rx_errors;
+
+	stats->multicast = SPX5_STAT_SUM(rx_unicast);
+
+	stats->rx_dropped = SPX5_STAT_GET(rx_port_policer_drop) +
+		SPX5_STAT_XQS_PRIOS_COUNTER_SUM(rx_port_drop);
+
+	/* Get Tx stats */
+	stats->tx_bytes = SPX5_STAT_SUM(tx_ok_bytes);
+
+	stats->tx_packets = SPX5_STAT_SUM(tx_unicast) +
+		SPX5_STAT_SUM(tx_multicast) + SPX5_STAT_SUM(tx_broadcast);
+
+	stats->tx_dropped = SPX5_STAT_GET(tx_local_drop);
+
+	stats->collisions = SPX5_STAT_GET(tx_multi_coll) +
+		SPX5_STAT_GET(tx_late_coll) +
+		SPX5_STAT_GET(tx_xcoll) +
+		SPX5_STAT_GET(tx_backoff1);
+}
+
+static int sparx5_get_link_settings(struct net_device *ndev,
+				    struct ethtool_link_ksettings *cmd)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+
+	return phylink_ethtool_ksettings_get(port->phylink, cmd);
+}
+
+static int sparx5_set_link_settings(struct net_device *ndev,
+				    const struct ethtool_link_ksettings *cmd)
+{
+	struct sparx5_port *port = netdev_priv(ndev);
+
+	return phylink_ethtool_ksettings_set(port->phylink, cmd);
+}
+
+const struct ethtool_ops sparx5_ethtool_ops = {
+	.get_sset_count         = sparx5_get_sset_count,
+	.get_strings            = sparx5_get_sset_strings,
+	.get_ethtool_stats      = sparx5_get_stats,
+	.get_link_ksettings	= sparx5_get_link_settings,
+	.set_link_ksettings	= sparx5_set_link_settings,
+	.get_link               = ethtool_op_get_link,
+};
+
+int sparx_stats_init(struct sparx5 *sparx5)
+{
+	char queue_name[32];
+	int portno;
+
+	sparx5->stats_layout = sparx5_stats_layout;
+	sparx5->num_stats = ARRAY_SIZE(sparx5_stats_layout);
+	sparx5->stats = devm_kcalloc(sparx5->dev,
+				     SPX5_PORTS_ALL * sparx5->num_stats,
+				     sizeof(u64), GFP_KERNEL);
+	if (!sparx5->stats)
+		return -ENOMEM;
+
+	sparx5_config_stats(sparx5);
+	for (portno = 0; portno < SPX5_PORTS; portno++)
+		if (sparx5->ports[portno])
+			sparx5_config_port_stats(sparx5, portno);
+
+	snprintf(queue_name, sizeof(queue_name), "%s-stats",
+		 dev_name(sparx5->dev));
+	sparx5->stats_queue = create_singlethread_workqueue(queue_name);
+	INIT_DELAYED_WORK(&sparx5->stats_work, sparx5_check_stats_work);
+	queue_delayed_work(sparx5->stats_queue, &sparx5->stats_work,
+			   SPX5_STATS_CHECK_DELAY);
+
+	return 0;
+}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 7c101afc7322..7ffd4b61dd33 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -624,6 +624,10 @@ static int sparx5_start(struct sparx5 *sparx5)
 	if (err)
 		return err;
 
+	/* Init stats */
+	err = sparx_stats_init(sparx5);
+	if (err)
+		return err;
 
 	/* Init mact_sw struct */
 	mutex_init(&sparx5->mact_lock);
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
index e9c48915842d..863f7a081ccb 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.h
@@ -133,6 +133,13 @@ struct sparx5 {
 	/* port structures are in net device */
 	struct sparx5_port *ports[SPX5_PORTS];
 	enum sparx5_core_clockfreq coreclock;
+	/* Statistics */
+	u32 num_stats;
+	const char * const *stats_layout;
+	u64 *stats;
+	/* Workqueue for reading stats */
+	struct delayed_work stats_work;
+	struct workqueue_struct *stats_queue;
 	/* Notifiers */
 	struct notifier_block netdevice_nb;
 	struct notifier_block switchdev_nb;
@@ -200,6 +207,10 @@ void sparx5_vlan_port_apply(struct sparx5 *sparx5, struct sparx5_port *port);
 int sparx5_config_auto_calendar(struct sparx5 *sparx5);
 int sparx5_config_dsm_calendar(struct sparx5 *sparx5);
 
+/* sparx5_ethtool.c */
+void sparx5_get_stats64(struct net_device *ndev, struct rtnl_link_stats64 *stats);
+int sparx_stats_init(struct sparx5 *sparx5);
+
 /* sparx5_netdev.c */
 bool sparx5_netdevice_check(const struct net_device *dev);
 struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno);
@@ -221,6 +232,7 @@ static inline u32 sparx5_clk_period(enum sparx5_core_clockfreq cclock)
 }
 
 extern const struct phylink_mac_ops sparx5_phylink_mac_ops;
+extern const struct ethtool_ops sparx5_ethtool_ops;
 
 /* Calculate raw offset */
 static inline __pure int spx5_offset(int id, int tinst, int tcnt,
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
index 6b0bfd512dfb..feb71a8f4348 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -177,6 +177,7 @@ static const struct net_device_ops sparx5_port_netdev_ops = {
 	.ndo_get_phys_port_name = sparx5_port_get_phys_port_name,
 	.ndo_set_mac_address    = sparx5_set_mac_address,
 	.ndo_validate_addr      = eth_validate_addr,
+	.ndo_get_stats64        = sparx5_get_stats64,
 	.ndo_get_port_parent_id = sparx5_get_port_parent_id,
 };
 
@@ -204,6 +205,7 @@ struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno)
 	snprintf(ndev->name, IFNAMSIZ, "eth%d", portno);
 
 	ndev->netdev_ops = &sparx5_port_netdev_ops;
+	ndev->ethtool_ops = &sparx5_ethtool_ops;
 	ndev->features |= NETIF_F_LLTX; /* software tx */
 
 	val = ether_addr_to_u64(sparx5->base_mac) + portno + 1;
-- 
2.31.1



From steen.hegelund at microchip.com  Fri Apr 16 14:16:57 2021
From: steen.hegelund at microchip.com (Steen Hegelund)
Date: Fri, 16 Apr 2021 15:16:57 +0200
Subject: [PATCH net-next 10/10] arm64: dts: sparx5: Add the Sparx5 switch node
In-Reply-To: <20210416131657.3151464-1-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
Message-ID: <20210416131657.3151464-11-steen.hegelund@microchip.com>

This provides the configuration for the currently available evaluation
boards PCB134 and PCB135.

The series depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: https://lore.kernel.org/r/20210218161451.3489955-1-steen.hegelund at microchip.com/

- Sparx5 Reset Driver
  Link: https://lore.kernel.org/r/20210416084054.2922327-1-steen.hegelund at microchip.com/

- Serial GPIO Controller
  Link: https://lore.kernel.org/r/20201113145151.68900-1-lars.povlsen at microchip.com/

Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi     |  94 ++-
 .../dts/microchip/sparx5_pcb134_board.dtsi    | 481 ++++++++++++--
 .../dts/microchip/sparx5_pcb135_board.dtsi    | 621 +++++++++++++++++-
 3 files changed, 1112 insertions(+), 84 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index d64621d1213b..ad07fff40544 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -135,9 +135,12 @@ mux: mux-controller {
 			};
 		};
 
-		reset at 611010008 {
-			compatible = "microchip,sparx5-chip-reset";
+		reset: reset-controller at 611010008 {
+			compatible = "microchip,sparx5-switch-reset";
 			reg = <0x6 0x11010008 0x4>;
+			reg-names = "gcb";
+			#reset-cells = <1>;
+			cpu-syscon = <&cpu_ctrl>;
 		};
 
 		uart0: serial at 600100000 {
@@ -275,6 +278,21 @@ emmc_pins: emmc-pins {
 					"GPIO_46", "GPIO_47";
 				function = "emmc";
 			};
+
+			miim1_pins: miim1-pins {
+				pins = "GPIO_56", "GPIO_57";
+				function = "miim";
+			};
+
+			miim2_pins: miim2-pins {
+				pins = "GPIO_58", "GPIO_59";
+				function = "miim";
+			};
+
+			miim3_pins: miim3-pins {
+				pins = "GPIO_52", "GPIO_53";
+				function = "miim";
+			};
 		};
 
 		sgpio0: gpio at 61101036c {
@@ -285,6 +303,8 @@ sgpio0: gpio at 61101036c {
 			clocks = <&sys_clk>;
 			pinctrl-0 = <&sgpio0_pins>;
 			pinctrl-names = "default";
+			resets = <&reset 0>;
+			reset-names = "switch";
 			reg = <0x6 0x1101036c 0x100>;
 			sgpio_in0: gpio at 0 {
 				compatible = "microchip,sparx5-sgpio-bank";
@@ -292,6 +312,9 @@ sgpio_in0: gpio at 0 {
 				gpio-controller;
 				#gpio-cells = <3>;
 				ngpios = <96>;
+				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#interrupt-cells = <3>;
 			};
 			sgpio_out0: gpio at 1 {
 				compatible = "microchip,sparx5-sgpio-bank";
@@ -310,6 +333,8 @@ sgpio1: gpio at 611010484 {
 			clocks = <&sys_clk>;
 			pinctrl-0 = <&sgpio1_pins>;
 			pinctrl-names = "default";
+			resets = <&reset 0>;
+			reset-names = "switch";
 			reg = <0x6 0x11010484 0x100>;
 			sgpio_in1: gpio at 0 {
 				compatible = "microchip,sparx5-sgpio-bank";
@@ -317,6 +342,9 @@ sgpio_in1: gpio at 0 {
 				gpio-controller;
 				#gpio-cells = <3>;
 				ngpios = <96>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#interrupt-cells = <3>;
 			};
 			sgpio_out1: gpio at 1 {
 				compatible = "microchip,sparx5-sgpio-bank";
@@ -335,6 +363,8 @@ sgpio2: gpio at 61101059c {
 			clocks = <&sys_clk>;
 			pinctrl-0 = <&sgpio2_pins>;
 			pinctrl-names = "default";
+			resets = <&reset 0>;
+			reset-names = "switch";
 			reg = <0x6 0x1101059c 0x100>;
 			sgpio_in2: gpio at 0 {
 				reg = <0>;
@@ -342,6 +372,9 @@ sgpio_in2: gpio at 0 {
 				gpio-controller;
 				#gpio-cells = <3>;
 				ngpios = <96>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-controller;
+				#interrupt-cells = <3>;
 			};
 			sgpio_out2: gpio at 1 {
 				compatible = "microchip,sparx5-sgpio-bank";
@@ -386,5 +419,62 @@ tmon0: tmon at 610508110 {
 			#thermal-sensor-cells = <0>;
 			clocks = <&ahb_clk>;
 		};
+
+		mdio0: mdio at 6110102b0 {
+			compatible = "mscc,ocelot-miim";
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6 0x110102b0 0x24>;
+		};
+
+		mdio1: mdio at 6110102d4 {
+			compatible = "mscc,ocelot-miim";
+			status = "disabled";
+			pinctrl-0 = <&miim1_pins>;
+			pinctrl-names = "default";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6 0x110102d4 0x24>;
+		};
+
+		mdio2: mdio at 6110102f8 {
+			compatible = "mscc,ocelot-miim";
+			status = "disabled";
+			pinctrl-0 = <&miim2_pins>;
+			pinctrl-names = "default";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6 0x110102d4 0x24>;
+		};
+
+		mdio3: mdio at 61101031c {
+			compatible = "mscc,ocelot-miim";
+			status = "disabled";
+			pinctrl-0 = <&miim3_pins>;
+			pinctrl-names = "default";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6 0x1101031c 0x24>;
+		};
+
+		serdes: serdes at 10808000 {
+			compatible = "microchip,sparx5-serdes";
+			#phy-cells = <1>;
+			clocks = <&sys_clk>;
+			reg = <0x6 0x10808000 0x5d0000>;
+		};
+
+		switch: switch at 0x600000000 {
+			compatible = "microchip,sparx5-switch";
+			reg =	<0x6 0 0x401000>,
+				<0x6 0x10004000 0x7fc000>,
+				<0x6 0x11010000 0xaf0000>;
+			reg-names = "cpu", "dev", "gcb";
+			interrupt-names = "xtr";
+			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+			resets = <&reset 0>;
+			reset-names = "switch";
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f0c915160990..33faf1f3264f 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -7,30 +7,6 @@
 #include "sparx5_pcb_common.dtsi"
 
 /{
-	aliases {
-	    i2c0   = &i2c0;
-	    i2c100 = &i2c100;
-	    i2c101 = &i2c101;
-	    i2c102 = &i2c102;
-	    i2c103 = &i2c103;
-	    i2c104 = &i2c104;
-	    i2c105 = &i2c105;
-	    i2c106 = &i2c106;
-	    i2c107 = &i2c107;
-	    i2c108 = &i2c108;
-	    i2c109 = &i2c109;
-	    i2c110 = &i2c110;
-	    i2c111 = &i2c111;
-	    i2c112 = &i2c112;
-	    i2c113 = &i2c113;
-	    i2c114 = &i2c114;
-	    i2c115 = &i2c115;
-	    i2c116 = &i2c116;
-	    i2c117 = &i2c117;
-	    i2c118 = &i2c118;
-	    i2c119 = &i2c119;
-	};
-
 	gpio-restart {
 		compatible = "gpio-restart";
 		gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
@@ -298,17 +274,10 @@ gpio at 1 {
 
 &spi0 {
 	status = "okay";
-	spi at 0 {
-		compatible = "spi-mux";
-		mux-controls = <&mux>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		reg = <0>;	/* CS0 */
-		spi-flash at 9 {
-			compatible = "jedec,spi-nor";
-			spi-max-frequency = <8000000>;
-			reg = <0x9>;	/* SPI */
-		};
+	spi-flash at 0 {
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <8000000>;
+		reg = <0>;
 	};
 };
 
@@ -328,6 +297,33 @@ spi-flash at 9 {
 	};
 };
 
+&sgpio0 {
+	status = "okay";
+	microchip,sgpio-port-ranges = <8 15>;
+	gpio at 0 {
+		ngpios = <64>;
+	};
+	gpio at 1 {
+		ngpios = <64>;
+	};
+};
+
+&sgpio1 {
+	status = "okay";
+	microchip,sgpio-port-ranges = <24 31>;
+	gpio at 0 {
+		ngpios = <64>;
+	};
+	gpio at 1 {
+		ngpios = <64>;
+	};
+};
+
+&sgpio2 {
+	status = "okay";
+	microchip,sgpio-port-ranges = <0 0>, <11 31>;
+};
+
 &gpio {
 	i2cmux_pins_i: i2cmux-pins-i {
 	       pins = "GPIO_16", "GPIO_17", "GPIO_18", "GPIO_19",
@@ -415,9 +411,9 @@ i2c0_emux: i2c0-emux at 0 {
 
 &i2c0_imux {
 	pinctrl-names =
-		"i2c100", "i2c101", "i2c102", "i2c103",
-		"i2c104", "i2c105", "i2c106", "i2c107",
-		"i2c108", "i2c109", "i2c110", "i2c111", "idle";
+		"i2c_sfp1", "i2c_sfp2", "i2c_sfp3", "i2c_sfp4",
+		"i2c_sfp5", "i2c_sfp6", "i2c_sfp7", "i2c_sfp8",
+		"i2c_sfp9", "i2c_sfp10", "i2c_sfp11", "i2c_sfp12", "idle";
 	pinctrl-0 = <&i2cmux_0>;
 	pinctrl-1 = <&i2cmux_1>;
 	pinctrl-2 = <&i2cmux_2>;
@@ -431,62 +427,62 @@ &i2c0_imux {
 	pinctrl-10 = <&i2cmux_10>;
 	pinctrl-11 = <&i2cmux_11>;
 	pinctrl-12 = <&i2cmux_pins_i>;
-	i2c100: i2c_sfp1 {
+	i2c_sfp1: i2c_sfp1 {
 		reg = <0x0>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c101: i2c_sfp2 {
+	i2c_sfp2: i2c_sfp2 {
 		reg = <0x1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c102: i2c_sfp3 {
+	i2c_sfp3: i2c_sfp3 {
 		reg = <0x2>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c103: i2c_sfp4 {
+	i2c_sfp4: i2c_sfp4 {
 		reg = <0x3>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c104: i2c_sfp5 {
+	i2c_sfp5: i2c_sfp5 {
 		reg = <0x4>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c105: i2c_sfp6 {
+	i2c_sfp6: i2c_sfp6 {
 		reg = <0x5>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c106: i2c_sfp7 {
+	i2c_sfp7: i2c_sfp7 {
 		reg = <0x6>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c107: i2c_sfp8 {
+	i2c_sfp8: i2c_sfp8 {
 		reg = <0x7>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c108: i2c_sfp9 {
+	i2c_sfp9: i2c_sfp9 {
 		reg = <0x8>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c109: i2c_sfp10 {
+	i2c_sfp10: i2c_sfp10 {
 		reg = <0x9>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c110: i2c_sfp11 {
+	i2c_sfp11: i2c_sfp11 {
 		reg = <0xa>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c111: i2c_sfp12 {
+	i2c_sfp12: i2c_sfp12 {
 		reg = <0xb>;
 		#address-cells = <1>;
 		#size-cells = <0>;
@@ -499,44 +495,413 @@ &gpio 60 GPIO_ACTIVE_HIGH
 		     &gpio 61 GPIO_ACTIVE_HIGH
 		     &gpio 54 GPIO_ACTIVE_HIGH>;
 	idle-state = <0x8>;
-	i2c112: i2c_sfp13 {
+	i2c_sfp13: i2c_sfp13 {
 		reg = <0x0>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c113: i2c_sfp14 {
+	i2c_sfp14: i2c_sfp14 {
 		reg = <0x1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c114: i2c_sfp15 {
+	i2c_sfp15: i2c_sfp15 {
 		reg = <0x2>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c115: i2c_sfp16 {
+	i2c_sfp16: i2c_sfp16 {
 		reg = <0x3>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c116: i2c_sfp17 {
+	i2c_sfp17: i2c_sfp17 {
 		reg = <0x4>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c117: i2c_sfp18 {
+	i2c_sfp18: i2c_sfp18 {
 		reg = <0x5>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c118: i2c_sfp19 {
+	i2c_sfp19: i2c_sfp19 {
 		reg = <0x6>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c119: i2c_sfp20 {
+	i2c_sfp20: i2c_sfp20 {
 		reg = <0x7>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
 };
+
+&mdio3 {
+	status = "ok";
+	phy64: ethernet-phy at 64 {
+		reg = <28>;
+	};
+};
+
+&axi {
+	sfp_eth12: sfp-eth12 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp1>;
+		tx-disable-gpios = <&sgpio_out2 11 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 11 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 11 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 12 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth13: sfp-eth13 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp2>;
+		tx-disable-gpios = <&sgpio_out2 12 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 12 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 12 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 13 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth14: sfp-eth14 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp3>;
+		tx-disable-gpios = <&sgpio_out2 13 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 13 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 13 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 14 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth15: sfp-eth15 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp4>;
+		tx-disable-gpios = <&sgpio_out2 14 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 14 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 14 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 15 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth48: sfp-eth48 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp5>;
+		tx-disable-gpios = <&sgpio_out2 15 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 15 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 15 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 16 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth49: sfp-eth49 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp6>;
+		tx-disable-gpios = <&sgpio_out2 16 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 16 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 16 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 17 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth50: sfp-eth50 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp7>;
+		tx-disable-gpios = <&sgpio_out2 17 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 17 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 17 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 18 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth51: sfp-eth51 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp8>;
+		tx-disable-gpios = <&sgpio_out2 18 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 18 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 18 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 19 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth52: sfp-eth52 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp9>;
+		tx-disable-gpios = <&sgpio_out2 19 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 19 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 19 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 20 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth53: sfp-eth53 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp10>;
+		tx-disable-gpios = <&sgpio_out2 20 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 20 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 20 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 21 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth54: sfp-eth54 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp11>;
+		tx-disable-gpios = <&sgpio_out2 21 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 21 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 21 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 22 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth55: sfp-eth55 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp12>;
+		tx-disable-gpios = <&sgpio_out2 22 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 22 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 22 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 23 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth56: sfp-eth56 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp13>;
+		tx-disable-gpios = <&sgpio_out2 23 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 23 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 23 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 24 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth57: sfp-eth57 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp14>;
+		tx-disable-gpios = <&sgpio_out2 24 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 24 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 24 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 25 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth58: sfp-eth58 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp15>;
+		tx-disable-gpios = <&sgpio_out2 25 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 25 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 25 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 26 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth59: sfp-eth59 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp16>;
+		tx-disable-gpios = <&sgpio_out2 26 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 26 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 26 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 27 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth60: sfp-eth60 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp17>;
+		tx-disable-gpios = <&sgpio_out2 27 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 27 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 27 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 28 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth61: sfp-eth61 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp18>;
+		tx-disable-gpios = <&sgpio_out2 28 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 28 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 28 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 29 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth62: sfp-eth62 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp19>;
+		tx-disable-gpios = <&sgpio_out2 29 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 29 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 29 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 30 0 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth63: sfp-eth63 {
+		compatible       = "sff,sfp";
+		i2c-bus          = <&i2c_sfp20>;
+		tx-disable-gpios = <&sgpio_out2 30 1 GPIO_ACTIVE_LOW>;
+		los-gpios        = <&sgpio_in2 30 1 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios   = <&sgpio_in2 30 2 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios   = <&sgpio_in2 31 0 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&switch {
+	ethernet-ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/* 10G SFPs */
+		port12: port at 12 {
+			reg = <12>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 13>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth12>;
+			microchip,sd-sgpio = <301>;
+			managed = "in-band-status";
+		};
+		port13: port at 13 {
+			reg = <13>;
+			/* Example: CU SFP, 1G speed */
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 14>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth13>;
+			microchip,sd-sgpio = <305>;
+			managed = "in-band-status";
+		};
+		port14: port at 14 {
+			reg = <14>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 15>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth14>;
+			microchip,sd-sgpio = <309>;
+			managed = "in-band-status";
+		};
+		port15: port at 15 {
+			reg = <15>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 16>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth15>;
+			microchip,sd-sgpio = <313>;
+			managed = "in-band-status";
+		};
+		port48: port at 48 {
+			reg = <48>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 17>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth48>;
+			microchip,sd-sgpio = <317>;
+			managed = "in-band-status";
+		};
+		port49: port at 49 {
+			reg = <49>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 18>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth49>;
+			microchip,sd-sgpio = <321>;
+			managed = "in-band-status";
+		};
+		port50: port at 50 {
+			reg = <50>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 19>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth50>;
+			microchip,sd-sgpio = <325>;
+			managed = "in-band-status";
+		};
+		port51: port at 51 {
+			reg = <51>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 20>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth51>;
+			microchip,sd-sgpio = <329>;
+			managed = "in-band-status";
+		};
+		port52: port at 52 {
+			reg = <52>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 21>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth52>;
+			microchip,sd-sgpio = <333>;
+			managed = "in-band-status";
+		};
+		port53: port at 53 {
+			reg = <53>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 22>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth53>;
+			microchip,sd-sgpio = <337>;
+			managed = "in-band-status";
+		};
+		port54: port at 54 {
+			reg = <54>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 23>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth54>;
+			microchip,sd-sgpio = <341>;
+			managed = "in-band-status";
+		};
+		port55: port at 55 {
+			reg = <55>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 24>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth55>;
+			microchip,sd-sgpio = <345>;
+			managed = "in-band-status";
+		};
+		/* 25G SFPs */
+		port56: port at 56 {
+			reg = <56>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 25>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth56>;
+			microchip,sd-sgpio = <349>;
+			managed = "in-band-status";
+		};
+		port57: port at 57 {
+			reg = <57>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 26>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth57>;
+			microchip,sd-sgpio = <353>;
+			managed = "in-band-status";
+		};
+		port58: port at 58 {
+			reg = <58>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 27>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth58>;
+			microchip,sd-sgpio = <357>;
+			managed = "in-band-status";
+		};
+		port59: port at 59 {
+			reg = <59>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 28>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth59>;
+			microchip,sd-sgpio = <361>;
+			managed = "in-band-status";
+		};
+		port60: port at 60 {
+			reg = <60>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 29>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth60>;
+			microchip,sd-sgpio = <365>;
+			managed = "in-band-status";
+		};
+		port61: port at 61 {
+			reg = <61>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 30>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth61>;
+			microchip,sd-sgpio = <369>;
+			managed = "in-band-status";
+		};
+		port62: port at 62 {
+			reg = <62>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 31>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth62>;
+			microchip,sd-sgpio = <373>;
+			managed = "in-band-status";
+		};
+		port63: port at 63 {
+			reg = <63>;
+			microchip,bandwidth = <10000>;
+			phys = <&serdes 32>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth63>;
+			microchip,sd-sgpio = <377>;
+			managed = "in-band-status";
+		};
+		/* Finally the Management interface */
+		port64: port at 64 {
+			reg = <64>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 0>;
+			phy-handle = <&phy64>;
+			phy-mode = "sgmii";
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index e28c6dd16377..ef96e6d8c6b3 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -7,14 +7,6 @@
 #include "sparx5_pcb_common.dtsi"
 
 /{
-	aliases {
-	    i2c0   = &i2c0;
-	    i2c152 = &i2c152;
-	    i2c153 = &i2c153;
-	    i2c154 = &i2c154;
-	    i2c155 = &i2c155;
-	};
-
 	gpio-restart {
 		compatible = "gpio-restart";
 		gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
@@ -97,17 +89,10 @@ i2cmux_s32: i2cmux-3 {
 
 &spi0 {
 	status = "okay";
-	spi at 0 {
-		compatible = "spi-mux";
-		mux-controls = <&mux>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		reg = <0>; /* CS0 */
-		spi-flash at 9 {
-			compatible = "jedec,spi-nor";
-			spi-max-frequency = <8000000>;
-			reg = <0x9>; /* SPI */
-		};
+	spi-flash at 0 {
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <8000000>;
+		reg = <0>;
 	};
 };
 
@@ -138,6 +123,11 @@ gpio at 1 {
 	};
 };
 
+&sgpio2 {
+	status = "okay";
+	microchip,sgpio-port-ranges = <0 0>, <16 18>, <28 31>;
+};
+
 &axi {
 	i2c0_imux: i2c0-imux at 0 {
 		compatible = "i2c-mux-pinctrl";
@@ -149,31 +139,614 @@ i2c0_imux: i2c0-imux at 0 {
 
 &i2c0_imux {
 	pinctrl-names =
-		"i2c152", "i2c153", "i2c154", "i2c155",
+		"i2c_sfp1", "i2c_sfp2", "i2c_sfp3", "i2c_sfp4",
 		"idle";
 	pinctrl-0 = <&i2cmux_s29>;
 	pinctrl-1 = <&i2cmux_s30>;
 	pinctrl-2 = <&i2cmux_s31>;
 	pinctrl-3 = <&i2cmux_s32>;
 	pinctrl-4 = <&i2cmux_pins_i>;
-	i2c152: i2c_sfp1 {
+	i2c_sfp1: i2c_sfp1 {
 		reg = <0x0>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c153: i2c_sfp2 {
+	i2c_sfp2: i2c_sfp2 {
 		reg = <0x1>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c154: i2c_sfp3 {
+	i2c_sfp3: i2c_sfp3 {
 		reg = <0x2>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
-	i2c155: i2c_sfp4 {
+	i2c_sfp4: i2c_sfp4 {
 		reg = <0x3>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
 };
+
+&axi {
+	sfp_eth60: sfp-eth60 {
+		compatible	   = "sff,sfp";
+		i2c-bus            = <&i2c_sfp1>;
+		tx-disable-gpios   = <&sgpio_out2 28 0 GPIO_ACTIVE_LOW>;
+		rate-select0-gpios = <&sgpio_out2 28 1 GPIO_ACTIVE_HIGH>;
+		los-gpios          = <&sgpio_in2 28 0 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios     = <&sgpio_in2 28 1 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios     = <&sgpio_in2 28 2 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth61: sfp-eth61 {
+		compatible         = "sff,sfp";
+		i2c-bus            = <&i2c_sfp2>;
+		tx-disable-gpios   = <&sgpio_out2 29 0 GPIO_ACTIVE_LOW>;
+		rate-select0-gpios = <&sgpio_out2 29 1 GPIO_ACTIVE_HIGH>;
+		los-gpios          = <&sgpio_in2 29 0 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios     = <&sgpio_in2 29 1 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios     = <&sgpio_in2 29 2 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth62: sfp-eth62 {
+		compatible         = "sff,sfp";
+		i2c-bus            = <&i2c_sfp3>;
+		tx-disable-gpios   = <&sgpio_out2 30 0 GPIO_ACTIVE_LOW>;
+		rate-select0-gpios = <&sgpio_out2 30 1 GPIO_ACTIVE_HIGH>;
+		los-gpios          = <&sgpio_in2 30 0 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios     = <&sgpio_in2 30 1 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios     = <&sgpio_in2 30 2 GPIO_ACTIVE_HIGH>;
+	};
+	sfp_eth63: sfp-eth63 {
+		compatible         = "sff,sfp";
+		i2c-bus            = <&i2c_sfp4>;
+		tx-disable-gpios   = <&sgpio_out2 31 0 GPIO_ACTIVE_LOW>;
+		rate-select0-gpios = <&sgpio_out2 31 1 GPIO_ACTIVE_HIGH>;
+		los-gpios          = <&sgpio_in2 31 0 GPIO_ACTIVE_HIGH>;
+		mod-def0-gpios     = <&sgpio_in2 31 1 GPIO_ACTIVE_LOW>;
+		tx-fault-gpios     = <&sgpio_in2 31 2 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&mdio0 {
+	status = "ok";
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+	phy1: ethernet-phy at 1 {
+		reg = <1>;
+	};
+	phy2: ethernet-phy at 2 {
+		reg = <2>;
+	};
+	phy3: ethernet-phy at 3 {
+		reg = <3>;
+	};
+	phy4: ethernet-phy at 4 {
+		reg = <4>;
+	};
+	phy5: ethernet-phy at 5 {
+		reg = <5>;
+	};
+	phy6: ethernet-phy at 6 {
+		reg = <6>;
+	};
+	phy7: ethernet-phy at 7 {
+		reg = <7>;
+	};
+	phy8: ethernet-phy at 8 {
+		reg = <8>;
+	};
+	phy9: ethernet-phy at 9 {
+		reg = <9>;
+	};
+	phy10: ethernet-phy at 10 {
+		reg = <10>;
+	};
+	phy11: ethernet-phy at 11 {
+		reg = <11>;
+	};
+	phy12: ethernet-phy at 12 {
+		reg = <12>;
+	};
+	phy13: ethernet-phy at 13 {
+		reg = <13>;
+	};
+	phy14: ethernet-phy at 14 {
+		reg = <14>;
+	};
+	phy15: ethernet-phy at 15 {
+		reg = <15>;
+	};
+	phy16: ethernet-phy at 16 {
+		reg = <16>;
+	};
+	phy17: ethernet-phy at 17 {
+		reg = <17>;
+	};
+	phy18: ethernet-phy at 18 {
+		reg = <18>;
+	};
+	phy19: ethernet-phy at 19 {
+		reg = <19>;
+	};
+	phy20: ethernet-phy at 20 {
+		reg = <20>;
+	};
+	phy21: ethernet-phy at 21 {
+		reg = <21>;
+	};
+	phy22: ethernet-phy at 22 {
+		reg = <22>;
+	};
+	phy23: ethernet-phy at 23 {
+		reg = <23>;
+	};
+};
+
+&mdio1 {
+	status = "ok";
+	phy24: ethernet-phy at 24 {
+		reg = <0>;
+	};
+	phy25: ethernet-phy at 25 {
+		reg = <1>;
+	};
+	phy26: ethernet-phy at 26 {
+		reg = <2>;
+	};
+	phy27: ethernet-phy at 27 {
+		reg = <3>;
+	};
+	phy28: ethernet-phy at 28 {
+		reg = <4>;
+	};
+	phy29: ethernet-phy at 29 {
+		reg = <5>;
+	};
+	phy30: ethernet-phy at 30 {
+		reg = <6>;
+	};
+	phy31: ethernet-phy at 31 {
+		reg = <7>;
+	};
+	phy32: ethernet-phy at 32 {
+		reg = <8>;
+	};
+	phy33: ethernet-phy at 33 {
+		reg = <9>;
+	};
+	phy34: ethernet-phy at 34 {
+		reg = <10>;
+	};
+	phy35: ethernet-phy at 35 {
+		reg = <11>;
+	};
+	phy36: ethernet-phy at 36 {
+		reg = <12>;
+	};
+	phy37: ethernet-phy at 37 {
+		reg = <13>;
+	};
+	phy38: ethernet-phy at 38 {
+		reg = <14>;
+	};
+	phy39: ethernet-phy at 39 {
+		reg = <15>;
+	};
+	phy40: ethernet-phy at 40 {
+		reg = <16>;
+	};
+	phy41: ethernet-phy at 41 {
+		reg = <17>;
+	};
+	phy42: ethernet-phy at 42 {
+		reg = <18>;
+	};
+	phy43: ethernet-phy at 43 {
+		reg = <19>;
+	};
+	phy44: ethernet-phy at 44 {
+		reg = <20>;
+	};
+	phy45: ethernet-phy at 45 {
+		reg = <21>;
+	};
+	phy46: ethernet-phy at 46 {
+		reg = <22>;
+	};
+	phy47: ethernet-phy at 47 {
+		reg = <23>;
+	};
+};
+
+&mdio3 {
+	status = "ok";
+	phy64: ethernet-phy at 64 {
+		reg = <28>;
+	};
+};
+
+&switch {
+	ethernet-ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port0: port at 0 {
+			reg = <0>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 13>;
+			phy-handle = <&phy0>;
+			phy-mode = "qsgmii";
+		};
+		port1: port at 1 {
+			reg = <1>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 13>;
+			phy-handle = <&phy1>;
+			phy-mode = "qsgmii";
+		};
+		port2: port at 2 {
+			reg = <2>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 13>;
+			phy-handle = <&phy2>;
+			phy-mode = "qsgmii";
+		};
+		port3: port at 3 {
+			reg = <3>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 13>;
+			phy-handle = <&phy3>;
+			phy-mode = "qsgmii";
+		};
+		port4: port at 4 {
+			reg = <4>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 14>;
+			phy-handle = <&phy4>;
+			phy-mode = "qsgmii";
+		};
+		port5: port at 5 {
+			reg = <5>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 14>;
+			phy-handle = <&phy5>;
+			phy-mode = "qsgmii";
+		};
+		port6: port at 6 {
+			reg = <6>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 14>;
+			phy-handle = <&phy6>;
+			phy-mode = "qsgmii";
+		};
+		port7: port at 7 {
+			reg = <7>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 14>;
+			phy-handle = <&phy7>;
+			phy-mode = "qsgmii";
+		};
+		port8: port at 8 {
+			reg = <8>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 15>;
+			phy-handle = <&phy8>;
+			phy-mode = "qsgmii";
+		};
+		port9: port at 9 {
+			reg = <9>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 15>;
+			phy-handle = <&phy9>;
+			phy-mode = "qsgmii";
+		};
+		port10: port at 10 {
+			reg = <10>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 15>;
+			phy-handle = <&phy10>;
+			phy-mode = "qsgmii";
+		};
+		port11: port at 11 {
+			reg = <11>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 15>;
+			phy-handle = <&phy11>;
+			phy-mode = "qsgmii";
+		};
+		port12: port at 12 {
+			reg = <12>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 16>;
+			phy-handle = <&phy12>;
+			phy-mode = "qsgmii";
+		};
+		port13: port at 13 {
+			reg = <13>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 16>;
+			phy-handle = <&phy13>;
+			phy-mode = "qsgmii";
+		};
+		port14: port at 14 {
+			reg = <14>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 16>;
+			phy-handle = <&phy14>;
+			phy-mode = "qsgmii";
+		};
+		port15: port at 15 {
+			reg = <15>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 16>;
+			phy-handle = <&phy15>;
+			phy-mode = "qsgmii";
+		};
+		port16: port at 16 {
+			reg = <16>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 17>;
+			phy-handle = <&phy16>;
+			phy-mode = "qsgmii";
+		};
+		port17: port at 17 {
+			reg = <17>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 17>;
+			phy-handle = <&phy17>;
+			phy-mode = "qsgmii";
+		};
+		port18: port at 18 {
+			reg = <18>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 17>;
+			phy-handle = <&phy18>;
+			phy-mode = "qsgmii";
+		};
+		port19: port at 19 {
+			reg = <19>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 17>;
+			phy-handle = <&phy19>;
+			phy-mode = "qsgmii";
+		};
+		port20: port at 20 {
+			reg = <20>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 18>;
+			phy-handle = <&phy20>;
+			phy-mode = "qsgmii";
+		};
+		port21: port at 21 {
+			reg = <21>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 18>;
+			phy-handle = <&phy21>;
+			phy-mode = "qsgmii";
+		};
+		port22: port at 22 {
+			reg = <22>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 18>;
+			phy-handle = <&phy22>;
+			phy-mode = "qsgmii";
+		};
+		port23: port at 23 {
+			reg = <23>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 18>;
+			phy-handle = <&phy23>;
+			phy-mode = "qsgmii";
+		};
+		port24: port at 24 {
+			reg = <24>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 19>;
+			phy-handle = <&phy24>;
+			phy-mode = "qsgmii";
+		};
+		port25: port at 25 {
+			reg = <25>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 19>;
+			phy-handle = <&phy25>;
+			phy-mode = "qsgmii";
+		};
+		port26: port at 26 {
+			reg = <26>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 19>;
+			phy-handle = <&phy26>;
+			phy-mode = "qsgmii";
+		};
+		port27: port at 27 {
+			reg = <27>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 19>;
+			phy-handle = <&phy27>;
+			phy-mode = "qsgmii";
+		};
+		port28: port at 28 {
+			reg = <28>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 20>;
+			phy-handle = <&phy28>;
+			phy-mode = "qsgmii";
+		};
+		port29: port at 29 {
+			reg = <29>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 20>;
+			phy-handle = <&phy29>;
+			phy-mode = "qsgmii";
+		};
+		port30: port at 30 {
+			reg = <30>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 20>;
+			phy-handle = <&phy30>;
+			phy-mode = "qsgmii";
+		};
+		port31: port at 31 {
+			reg = <31>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 20>;
+			phy-handle = <&phy31>;
+			phy-mode = "qsgmii";
+		};
+		port32: port at 32 {
+			reg = <32>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 21>;
+			phy-handle = <&phy32>;
+			phy-mode = "qsgmii";
+		};
+		port33: port at 33 {
+			reg = <33>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 21>;
+			phy-handle = <&phy33>;
+			phy-mode = "qsgmii";
+		};
+		port34: port at 34 {
+			reg = <34>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 21>;
+			phy-handle = <&phy34>;
+			phy-mode = "qsgmii";
+		};
+		port35: port at 35 {
+			reg = <35>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 21>;
+			phy-handle = <&phy35>;
+			phy-mode = "qsgmii";
+		};
+		port36: port at 36 {
+			reg = <36>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 22>;
+			phy-handle = <&phy36>;
+			phy-mode = "qsgmii";
+		};
+		port37: port at 37 {
+			reg = <37>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 22>;
+			phy-handle = <&phy37>;
+			phy-mode = "qsgmii";
+		};
+		port38: port at 38 {
+			reg = <38>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 22>;
+			phy-handle = <&phy38>;
+			phy-mode = "qsgmii";
+		};
+		port39: port at 39 {
+			reg = <39>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 22>;
+			phy-handle = <&phy39>;
+			phy-mode = "qsgmii";
+		};
+		port40: port at 40 {
+			reg = <40>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 23>;
+			phy-handle = <&phy40>;
+			phy-mode = "qsgmii";
+		};
+		port41: port at 41 {
+			reg = <41>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 23>;
+			phy-handle = <&phy41>;
+			phy-mode = "qsgmii";
+		};
+		port42: port at 42 {
+			reg = <42>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 23>;
+			phy-handle = <&phy42>;
+			phy-mode = "qsgmii";
+		};
+		port43: port at 43 {
+			reg = <43>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 23>;
+			phy-handle = <&phy43>;
+			phy-mode = "qsgmii";
+		};
+		port44: port at 44 {
+			reg = <44>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 24>;
+			phy-handle = <&phy44>;
+			phy-mode = "qsgmii";
+		};
+		port45: port at 45 {
+			reg = <45>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 24>;
+			phy-handle = <&phy45>;
+			phy-mode = "qsgmii";
+		};
+		port46: port at 46 {
+			reg = <46>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 24>;
+			phy-handle = <&phy46>;
+			phy-mode = "qsgmii";
+		};
+		port47: port at 47 {
+			reg = <47>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 24>;
+			phy-handle = <&phy47>;
+			phy-mode = "qsgmii";
+		};
+		/* Then the 25G interfaces */
+		port60: port at 60 {
+			reg = <60>;
+			microchip,bandwidth = <25000>;
+			phys = <&serdes 29>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth60>;
+			managed = "in-band-status";
+		};
+		port61: port at 61 {
+			reg = <61>;
+			microchip,bandwidth = <25000>;
+			phys = <&serdes 30>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth61>;
+			managed = "in-band-status";
+		};
+		port62: port at 62 {
+			reg = <62>;
+			microchip,bandwidth = <25000>;
+			phys = <&serdes 31>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth62>;
+			managed = "in-band-status";
+		};
+		port63: port at 63 {
+			reg = <63>;
+			microchip,bandwidth = <25000>;
+			phys = <&serdes 32>;
+			phy-mode = "10gbase-r";
+			sfp = <&sfp_eth63>;
+			managed = "in-band-status";
+		};
+		/* Finally the Management interface */
+		port64: port at 64 {
+			reg = <64>;
+			microchip,bandwidth = <1000>;
+			phys = <&serdes 0>;
+			phy-handle = <&phy64>;
+			phy-mode = "sgmii";
+		};
+	};
+};
-- 
2.31.1



From leo.yan at linaro.org  Fri Apr 16 14:21:04 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 16 Apr 2021 21:21:04 +0800
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized
 event
In-Reply-To: <c9c060d1-0884-b67d-7689-6b45ad10baa9@arm.com>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-5-leo.yan@linaro.org>
 <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>
 <20210415152348.GF1011890@leoy-ThinkPad-X240s>
 <c9c060d1-0884-b67d-7689-6b45ad10baa9@arm.com>
Message-ID: <20210416132104.GG1011890@leoy-ThinkPad-X240s>

On Fri, Apr 16, 2021 at 03:51:25PM +0300, James Clark wrote:

[...]

> >> I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options.
> >> I don't know of a way to remove this, and if there isn't, does that mean that all the code in this
> >> file that looks at spe->timeless_decoding is untested and has never been hit?
> >>
> >> Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one
> >> might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding
> >> is always false.
> > 
> > Good point.  To be honest, I never noticed this issue until you
> > mentioned this.
> > 
> > We should fix for the "timeless" flow; and it's questionable for the
> > function arm_spe_recording_options(), except for setting
> > PERF_SAMPLE_TIME, it also hard codes for setting
> > PERF_SAMPLE_CPU and PERF_SAMPLE_TID.  Might need to carefully go
> > through this function.
> > 
> 
> Yeah, it's not strictly related to your change, which is definitely an improvement.
> But maybe we should have a look at the SPE implementation relating to timestamps as a whole.

Totally agree, at least this patch series should not introduce any
barrier for timeless case.  I will go back to verify it; if you'd
like to fix timeless issue, please feel free to go ahead.

Thanks,
Leo


From mark.rutland at arm.com  Fri Apr 16 14:34:41 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 16 Apr 2021 14:34:41 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210416123322.GA23184@arm.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
Message-ID: <20210416133431.GA2303@C02TD0UTHF1T.local>

On Fri, Apr 16, 2021 at 01:33:22PM +0100, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> > The general version of is_syscall_success does not handle 32-bit
> > compatible case, which would cause 32-bit negative return code to be
> > recoganized as a positive number later and seen as a "success".
> > 
> > Since is_compat_thread is defined in compat.h, implementing
> > is_syscall_success in ptrace.h would introduce build failure due to
> > recursive inclusion of some basic headers like mutex.h. We put the
> > implementation to ptrace.c
> > 
> > Signed-off-by: He Zhe <zhe.he at windriver.com>
> > ---
> >  arch/arm64/include/asm/ptrace.h |  3 +++
> >  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
> >  2 files changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> > index e58bca832dff..3c415e9e5d85 100644
> > --- a/arch/arm64/include/asm/ptrace.h
> > +++ b/arch/arm64/include/asm/ptrace.h
> > @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> >  	regs->regs[0] = rc;
> >  }
> >  
> > +extern inline int is_syscall_success(struct pt_regs *regs);
> > +#define is_syscall_success(regs) is_syscall_success(regs)
> > +
> >  /**
> >   * regs_get_kernel_argument() - get Nth function argument in kernel
> >   * @regs:	pt_regs of that context
> > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > index 170f42fd6101..3266201f8c60 100644
> > --- a/arch/arm64/kernel/ptrace.c
> > +++ b/arch/arm64/kernel/ptrace.c
> > @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> >  	else
> >  		return valid_native_regs(regs);
> >  }
> > +
> > +inline int is_syscall_success(struct pt_regs *regs)
> > +{
> > +	unsigned long val = regs->regs[0];
> > +
> > +	if (is_compat_thread(task_thread_info(current)))
> > +		val = sign_extend64(val, 31);
> > +
> > +	return !IS_ERR_VALUE(val);
> > +}
> 
> It's better to use compat_user_mode(regs) here instead of
> is_compat_thread(). It saves us from worrying whether regs are for the
> current context.
> 
> I think we should change regs_return_value() instead. This function
> seems to be called from several other places and it has the same
> potential problems if called on compat pt_regs.

I think this is a problem we created for ourselves back in commit:

  15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)

AFAICT, the perf regs samples are the only place this matters, since for
ptrace the compat regs are implicitly truncated to compat_ulong_t, and
audit expects the non-truncated return value. Other architectures don't
truncate here, so I think we're setting ourselves up for a game of
whack-a-mole to truncate and extend wherever we need to.

Given that, I suspect it'd be better to do something like the below.

Will, thoughts?

Mark.

---->8----
>From df0f7c160240d9ee6f20f87a180326d3253e80fb Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland at arm.com>
Date: Fri, 16 Apr 2021 13:58:54 +0100
Subject: [PATCH] arm64: perf: truncate compat regs

For compat userspace, it doesn't generally make sense for the upper 32
bits of GPRs to be set, as these bits don't really exist in AArch32.
However, for structural reasons the kernel may transiently set the upper
32 bits of registers in pt_regs at points where a perf sample can be
taken.

We tried to avoid this happening in commit:

  15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return")

... by having invoke_syscall() truncate the return value for compat
tasks, with helpers in <asm/syscall.h> extending the return value when
required.

Unfortunately this is not complete, as there are other places where we
assign the return value, such as when el0_svc_common() sets up a return
of -ENOSYS.

Further, this approach breaks the audit code, which relies on the upper
32 bits of the return value.

Instead, let's have the perf code explicitly truncate the user regs to
32 bits, and otherwise preserve those within the kernel.

Fixes: 15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return")
Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Will Deacon <will at kernel.org>
---
 arch/arm64/include/asm/syscall.h | 11 +----------
 arch/arm64/kernel/perf_regs.c    | 26 ++++++++++++++++----------
 arch/arm64/kernel/syscall.c      |  3 ---
 3 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index cfc0672013f6..0ebeaf6dbd45 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -35,9 +35,6 @@ static inline long syscall_get_error(struct task_struct *task,
 {
 	unsigned long error = regs->regs[0];
 
-	if (is_compat_thread(task_thread_info(task)))
-		error = sign_extend64(error, 31);
-
 	return IS_ERR_VALUE(error) ? error : 0;
 }
 
@@ -51,13 +48,7 @@ static inline void syscall_set_return_value(struct task_struct *task,
 					    struct pt_regs *regs,
 					    int error, long val)
 {
-	if (error)
-		val = error;
-
-	if (is_compat_thread(task_thread_info(task)))
-		val = lower_32_bits(val);
-
-	regs->regs[0] = val;
+	regs->regs[0] = (long) error ? error : val;
 }
 
 #define SYSCALL_MAX_ARGS 6
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
index f6f58e6265df..296f0c55b4e2 100644
--- a/arch/arm64/kernel/perf_regs.c
+++ b/arch/arm64/kernel/perf_regs.c
@@ -9,6 +9,17 @@
 #include <asm/perf_regs.h>
 #include <asm/ptrace.h>
 
+static u64 __perf_reg_value(struct pt_regs *regs, int idx)
+{
+	if ((u32)idx == PERF_REG_ARM64_SP)
+		return regs->sp;
+
+	if ((u32)idx == PERF_REG_ARM64_PC)
+		return regs->pc;
+
+	return regs->regs[idx];
+}
+
 u64 perf_reg_value(struct pt_regs *regs, int idx)
 {
 	if (WARN_ON_ONCE((u32)idx >= PERF_REG_ARM64_MAX))
@@ -38,20 +49,15 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
 	 */
 	if (compat_user_mode(regs)) {
 		if ((u32)idx == PERF_REG_ARM64_SP)
-			return regs->compat_sp;
+			return lower_32_bits(regs->compat_sp);
 		if ((u32)idx == PERF_REG_ARM64_LR)
-			return regs->compat_lr;
+			return lower_32_bits(regs->compat_lr);
 		if (idx == 15)
-			return regs->pc;
+			return lower_32_bits(regs->pc);
+		return lower_32_bits(__perf_reg_value(regs, idx));
 	}
 
-	if ((u32)idx == PERF_REG_ARM64_SP)
-		return regs->sp;
-
-	if ((u32)idx == PERF_REG_ARM64_PC)
-		return regs->pc;
-
-	return regs->regs[idx];
+	return __perf_reg_value(regs, idx);
 }
 
 #define REG_RESERVED (~((1ULL << PERF_REG_ARM64_MAX) - 1))
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index b9cf12b271d7..84314fae4b5c 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -51,9 +51,6 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
 		ret = do_ni_syscall(regs, scno);
 	}
 
-	if (is_compat_task())
-		ret = lower_32_bits(ret);
-
 	regs->regs[0] = ret;
 }
 
-- 
2.11.0



From zajec5 at gmail.com  Fri Apr 16 14:37:50 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:50 +0200
Subject: [PATCH stblinux 3/6] ARM: Cygnus: dts: fix NAND nodes names
In-Reply-To: <20210416133753.32756-1-zajec5@gmail.com>
References: <20210416133753.32756-1-zajec5@gmail.com>
Message-ID: <20210416133753.32756-3-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm-cygnus.dtsi      | 2 +-
 arch/arm/boot/dts/bcm911360_entphn.dts | 4 ++--
 arch/arm/boot/dts/bcm958300k.dts       | 4 ++--
 arch/arm/boot/dts/bcm958305k.dts       | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 0025c88f660c..8ecb7861ce10 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -460,7 +460,7 @@ sdhci1: sdhci at 18043000 {
 			status = "disabled";
 		};
 
-		nand: nand at 18046000 {
+		nand_controller: nand-controller at 18046000 {
 			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
 			reg = <0x18046000 0x600>, <0xf8105408 0x600>,
 			      <0x18046f00 0x20>;
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts b/arch/arm/boot/dts/bcm911360_entphn.dts
index b2d323f4a5ab..a76c74b44bba 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -82,8 +82,8 @@ &uart3 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 1 {
+&nand_controller {
+	nand at 1 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958300k.dts b/arch/arm/boot/dts/bcm958300k.dts
index b4a1392bd5a6..dda3e11b711f 100644
--- a/arch/arm/boot/dts/bcm958300k.dts
+++ b/arch/arm/boot/dts/bcm958300k.dts
@@ -60,8 +60,8 @@ &uart3 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 1 {
+&nand_controller {
+	nand at 1 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
index 3378683321d3..ea3c6b88b313 100644
--- a/arch/arm/boot/dts/bcm958305k.dts
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -68,8 +68,8 @@ &uart3 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 1 {
+&nand_controller {
+	nand at 1 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
-- 
2.26.2



From zajec5 at gmail.com  Fri Apr 16 14:37:48 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:48 +0200
Subject: [PATCH stblinux 1/6] ARM: dts: BCM5301X: Fix NAND nodes names
Message-ID: <20210416133753.32756-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts      | 4 ++--
 arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts     | 4 ++--
 arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi          | 4 ++--
 arch/arm/boot/dts/bcm5301x.dtsi                   | 2 +-
 arch/arm/boot/dts/bcm953012k.dts                  | 4 ++--
 arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
index 8636600385fd..c81944cd6d0b 100644
--- a/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
+++ b/arch/arm/boot/dts/bcm4708-luxul-xwc-1000.dts
@@ -24,8 +24,8 @@ memory at 0 {
 		reg = <0x00000000 0x08000000>;
 	};
 
-	nand: nand at 18028000 {
-		nandcs at 0 {
+	nand_controller: nand-controller at 18028000 {
+		nand at 0 {
 			partitions {
 				compatible = "fixed-partitions";
 				#address-cells = <1>;
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index e635a15041dd..a6e2aeb28675 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -25,8 +25,8 @@ memory at 0 {
 		      <0x88000000 0x08000000>;
 	};
 
-	nand: nand at 18028000 {
-		nandcs at 0 {
+	nand_controller: nand-controller at 18028000 {
+		nand at 0 {
 			partitions {
 				compatible = "fixed-partitions";
 				#address-cells = <1>;
diff --git a/arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi b/arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi
index 925a7c9ce5b7..be9a00ff752d 100644
--- a/arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi
+++ b/arch/arm/boot/dts/bcm5301x-nand-cs0.dtsi
@@ -6,8 +6,8 @@
  */
 
 / {
-	nand at 18028000 {
-		nandcs: nandcs at 0 {
+	nand-controller at 18028000 {
+		nandcs: nand at 0 {
 			compatible = "brcm,nandcs";
 			reg = <0>;
 			#address-cells = <1>;
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 7db72a2f1020..092ec525c01c 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -501,7 +501,7 @@ rng: rng at 18004000 {
 		reg = <0x18004000 0x14>;
 	};
 
-	nand: nand at 18028000 {
+	nand_controller: nand-controller at 18028000 {
 		compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1", "brcm,brcmnand";
 		reg = <0x18028000 0x600>, <0x1811a408 0x600>, <0x18028f00 0x20>;
 		reg-names = "nand", "iproc-idm", "iproc-ext";
diff --git a/arch/arm/boot/dts/bcm953012k.dts b/arch/arm/boot/dts/bcm953012k.dts
index 046c59fb4846..de40bd59a5fa 100644
--- a/arch/arm/boot/dts/bcm953012k.dts
+++ b/arch/arm/boot/dts/bcm953012k.dts
@@ -49,8 +49,8 @@ memory at 80000000 {
 	};
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi b/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
index 9354077f74cd..b69c87d7d9a2 100644
--- a/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi
@@ -269,7 +269,7 @@ nand at 1800 {
 			interrupt-names = "nand";
 			status = "okay";
 
-			nandcs: nandcs at 0 {
+			nandcs: nand at 0 {
 				compatible = "brcm,nandcs";
 				reg = <0>;
 			};
-- 
2.26.2



From zajec5 at gmail.com  Fri Apr 16 14:37:49 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:49 +0200
Subject: [PATCH stblinux 2/6] ARM: brcmstb: dts: fix NAND nodes names
In-Reply-To: <20210416133753.32756-1-zajec5@gmail.com>
References: <20210416133753.32756-1-zajec5@gmail.com>
Message-ID: <20210416133753.32756-2-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts | 4 ++--
 arch/arm/boot/dts/bcm7445.dtsi             | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts b/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
index 8313b7cad542..f92d2cf85972 100644
--- a/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
+++ b/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
@@ -14,10 +14,10 @@ memory at 0 {
 	};
 };
 
-&nand {
+&nand_controller {
 	status = "okay";
 
-	nandcs at 1 {
+	nand at 1 {
 		compatible = "brcm,nandcs";
 		reg = <1>;
 		nand-ecc-step-size = <512>;
diff --git a/arch/arm/boot/dts/bcm7445.dtsi b/arch/arm/boot/dts/bcm7445.dtsi
index 58f67c9b830b..5ac2042515b8 100644
--- a/arch/arm/boot/dts/bcm7445.dtsi
+++ b/arch/arm/boot/dts/bcm7445.dtsi
@@ -148,7 +148,7 @@ aon-ctrl at 410000 {
 			reg-names = "aon-ctrl", "aon-sram";
 		};
 
-		nand: nand at 3e2800 {
+		nand_controller: nand-controller at 3e2800 {
 			status = "disabled";
 			#address-cells = <1>;
 			#size-cells = <0>;
-- 
2.26.2



From zajec5 at gmail.com  Fri Apr 16 14:37:51 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:51 +0200
Subject: [PATCH stblinux 4/6] ARM: NSP: dts: fix NAND nodes names
In-Reply-To: <20210416133753.32756-1-zajec5@gmail.com>
References: <20210416133753.32756-1-zajec5@gmail.com>
Message-ID: <20210416133753.32756-4-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm-nsp.dtsi     | 2 +-
 arch/arm/boot/dts/bcm958522er.dts  | 4 ++--
 arch/arm/boot/dts/bcm958525er.dts  | 4 ++--
 arch/arm/boot/dts/bcm958525xmc.dts | 4 ++--
 arch/arm/boot/dts/bcm958622hr.dts  | 4 ++--
 arch/arm/boot/dts/bcm958623hr.dts  | 4 ++--
 arch/arm/boot/dts/bcm958625hr.dts  | 4 ++--
 arch/arm/boot/dts/bcm958625k.dts   | 4 ++--
 arch/arm/boot/dts/bcm988312hr.dts  | 4 ++--
 9 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index b4d2cc70afb1..748df7955ae6 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -269,7 +269,7 @@ mailbox: mailbox at 25c00 {
 			dma-coherent;
 		};
 
-		nand: nand at 26000 {
+		nand_controller: nand-controller at 26000 {
 			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
 			reg = <0x026000 0x600>,
 			      <0x11b408 0x600>,
diff --git a/arch/arm/boot/dts/bcm958522er.dts b/arch/arm/boot/dts/bcm958522er.dts
index 5443fc079e6e..1f73885ec274 100644
--- a/arch/arm/boot/dts/bcm958522er.dts
+++ b/arch/arm/boot/dts/bcm958522er.dts
@@ -74,8 +74,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958525er.dts b/arch/arm/boot/dts/bcm958525er.dts
index e1e3c26cef19..b6b9ca8b0972 100644
--- a/arch/arm/boot/dts/bcm958525er.dts
+++ b/arch/arm/boot/dts/bcm958525er.dts
@@ -74,8 +74,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958525xmc.dts b/arch/arm/boot/dts/bcm958525xmc.dts
index f161ba2e7e5e..ecf426f6ad5d 100644
--- a/arch/arm/boot/dts/bcm958525xmc.dts
+++ b/arch/arm/boot/dts/bcm958525xmc.dts
@@ -90,8 +90,8 @@ rtc at 68 {
 	};
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958622hr.dts b/arch/arm/boot/dts/bcm958622hr.dts
index 83cb877d63db..8ca18da981ad 100644
--- a/arch/arm/boot/dts/bcm958622hr.dts
+++ b/arch/arm/boot/dts/bcm958622hr.dts
@@ -78,8 +78,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958623hr.dts b/arch/arm/boot/dts/bcm958623hr.dts
index 4e106ce1384a..9747378db531 100644
--- a/arch/arm/boot/dts/bcm958623hr.dts
+++ b/arch/arm/boot/dts/bcm958623hr.dts
@@ -78,8 +78,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958625hr.dts b/arch/arm/boot/dts/bcm958625hr.dts
index cda6cc281e18..0f92b773afb8 100644
--- a/arch/arm/boot/dts/bcm958625hr.dts
+++ b/arch/arm/boot/dts/bcm958625hr.dts
@@ -89,8 +89,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index ffbff0014c65..9e984ca0e6df 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -68,8 +68,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
diff --git a/arch/arm/boot/dts/bcm988312hr.dts b/arch/arm/boot/dts/bcm988312hr.dts
index 3fd39c479a3c..5475dab8181d 100644
--- a/arch/arm/boot/dts/bcm988312hr.dts
+++ b/arch/arm/boot/dts/bcm988312hr.dts
@@ -74,8 +74,8 @@ &ehci0 {
 	status = "okay";
 };
 
-&nand {
-	nandcs at 0 {
+&nand_controller {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-on-flash-bbt;
-- 
2.26.2



From zajec5 at gmail.com  Fri Apr 16 14:37:53 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:53 +0200
Subject: [PATCH stblinux 6/6] ARM: dts: Hurricane 2: Fix NAND nodes names
In-Reply-To: <20210416133753.32756-1-zajec5@gmail.com>
References: <20210416133753.32756-1-zajec5@gmail.com>
Message-ID: <20210416133753.32756-6-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm-hr2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index e8df458aad39..84cda16f68a2 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -179,7 +179,7 @@ amac0: ethernet at 22000 {
 			status = "disabled";
 		};
 
-		nand: nand at 26000 {
+		nand_controller: nand-controller at 26000 {
 			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
 			reg = <0x26000 0x600>,
 			      <0x11b408 0x600>,
-- 
2.26.2



From zajec5 at gmail.com  Fri Apr 16 14:37:52 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Fri, 16 Apr 2021 15:37:52 +0200
Subject: [PATCH stblinux 5/6] ARM: dts: BCM63xx: Fix NAND nodes names
In-Reply-To: <20210416133753.32756-1-zajec5@gmail.com>
References: <20210416133753.32756-1-zajec5@gmail.com>
Message-ID: <20210416133753.32756-5-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches nand-controller.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm63138.dtsi    | 2 +-
 arch/arm/boot/dts/bcm963138dvt.dts | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi
index 9c0325cf9e22..cca49a2e2d62 100644
--- a/arch/arm/boot/dts/bcm63138.dtsi
+++ b/arch/arm/boot/dts/bcm63138.dtsi
@@ -203,7 +203,7 @@ serial1: serial at 620 {
 			status = "disabled";
 		};
 
-		nand: nand at 2000 {
+		nand_controller: nand-controller at 2000 {
 			#address-cells = <1>;
 			#size-cells = <0>;
 			compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.0", "brcm,brcmnand";
diff --git a/arch/arm/boot/dts/bcm963138dvt.dts b/arch/arm/boot/dts/bcm963138dvt.dts
index 5b177274f182..df5c8ab90627 100644
--- a/arch/arm/boot/dts/bcm963138dvt.dts
+++ b/arch/arm/boot/dts/bcm963138dvt.dts
@@ -31,10 +31,10 @@ &serial1 {
 	status = "okay";
 };
 
-&nand {
+&nand_controller {
 	status = "okay";
 
-	nandcs at 0 {
+	nand at 0 {
 		compatible = "brcm,nandcs";
 		reg = <0>;
 		nand-ecc-strength = <4>;
-- 
2.26.2



From marex at denx.de  Fri Apr 16 14:39:54 2021
From: marex at denx.de (Marek Vasut)
Date: Fri, 16 Apr 2021 15:39:54 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it
 with np
In-Reply-To: <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-3-marex@denx.de>
 <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>
Message-ID: <362315e2-1398-4d11-e179-0ab7ca64e591@denx.de>

On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
> Hi Marek,

Hello Gabriel,

> I have a patch-set in progress using $dev (convertion into module driver).
> 
> https://patchwork.kernel.org/project/linux-clk/list/?series=421767
> 
> Then rebase of your patch, [PATCH 4/7] clk: stm32mp1: Add parent_data to 
> ETHRX clock, can be done easily.

I suspect the aforementioned patchset will have to be reworked, since 
the current approach to push SCMI onto every system and renumerate the 
clock has been rejected, because it caused DT ABI break and boot 
problems on many systems.

btw please don't top-post.

> Best regards
> Gabriel
> 
> On 4/8/21 8:57 PM, Marek Vasut wrote:
>> Instead of passing around $dev to all the registration functions, which
>> is always NULL, pass around struct device_node pointer $np. This way it
>> is possible to use of_clk_hw_register*() functions and/or register clock
>> with associated $np pointer.
[...]


From dafna.hirschfeld at collabora.com  Fri Apr 16 14:47:01 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Fri, 16 Apr 2021 15:47:01 +0200
Subject: [PATCH] iommu/mediatek: always enable the clk on resume
In-Reply-To: <YHhA4u7zat3vtJfD@8bytes.org>
References: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
 <YHhA4u7zat3vtJfD@8bytes.org>
Message-ID: <3c1f184f-e666-5198-e89e-c3774917c6d4@collabora.com>

Hi,
I sent v2, removing the word 'comment' from the 'Fixes' tag
after a problem report from Stephen Rothwell,
could you replace v1 with v2?

Thanks,
Dafna

On 15.04.21 15:34, Joerg Roedel wrote:
> On Thu, Apr 08, 2021 at 02:28:42PM +0200, Dafna Hirschfeld wrote:
>>   drivers/iommu/mtk_iommu.c | 19 ++++++++-----------
>>   1 file changed, 8 insertions(+), 11 deletions(-)
> 
> Applied, thanks.
> 


From marex at denx.de  Fri Apr 16 14:47:26 2021
From: marex at denx.de (Marek Vasut)
Date: Fri, 16 Apr 2021 15:47:26 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
 <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
 <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>
Message-ID: <e27dbccd-518f-7718-8cf7-cc9c8adb8a56@denx.de>

On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
> Hi Marek

Hello Gabriel,

> On 4/14/21 4:04 PM, Marek Vasut wrote:
>> On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
>>> Hi Marek,
>>
>> Hello Gabriel,
>>
>>> Thanks for the patchset
>>>
>>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>>> The ETHCK_K are modeled as composite clock of MUX and GATE, however per
>>>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. Peripheral
>>>> clock distribution for Ethernet, ETHPTPDIV divider is attached past the
>>>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN gate.
>>>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
>>>> in use, ETHCKEN gate can be turned off. Current driver does not permit
>>>> that, fix it.
>>>
>>> I don"t understand, it's already the case.
>>>
>>> ETHCK_K it's a composite with a MUX and a GATE.
>>
>> But ETHCK_K is _not_ a composite clock, look at the Figure 83 in the 
>> datasheet again and schematic below.
>>
>>> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV (no 
>>> gate)
>>
>> But ETHPTP_K shouldn't control any mux, it is only a divider.
>>
>>> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.
>>
>> Look, this is what you have today:
>>
>> ??????????? .------------ ETHCK_K -----------.
>> ??????????? |_______?????????????? _______?? |
>> pll4_p_ck--|M_ETHCK\???????????? |G_ETHCK\? |
>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>> ??????????? |?????????????? |
>> ??????????? |?????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>> ??????????? |????????????????????????????????????????? |
>> ??????????? '------------ ETHPTP_K --------------------'
>>
>> And this is what you should have, to avoid having two composite clock 
>> which control the same mux using the same register bit, i.e. what this 
>> patch implements:
>>
>> ??????????? .- ck_ker_eth -.? .--- ETHCK_K --.
>> ??????????? |_______?????? |? |??? _______?? |
>> pll4_p_ck--|M_ETHCK\????? |? |?? |G_ETHCK\? |
>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>> ??????????????????????????? |
>> ??????????????????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>> ???????????????????????????? |???????????????????????? |
>> ???????????????????????????? '---- ETHPTP_K -----------'
>>
> 
> These 2 solutions are valid. I made the choice to implement the first 
> one to be able to change parent with the kernel clock of the IP (no need 
> to add an intermediate binding).

Which IP are you talking about in here ?

> It's the same principle for all kernel 
> of this soc.

The first option is wrong, because in that model, you have two composite 
clock which control the same one mux bit in the same register. Basically 
you register two distinct clock which operate the same hardware knob.

> I can ask to Alexandre to comeback of this principle, but i 'm not 
> favorable.

Please ask.

>>>> This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
>>>> ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
>>>> NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent 
>>>> clock
>>>> to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
>>>> ETHPTP_K remain functional as before.
>>>>
>>>> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>>>> ???? Figure 83. Peripheral clock distribution for Ethernet
>>>> https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf 
>>>>
>>
>> [...]
>>
>>>> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
>>>> index a875649df8b8..a7c7f544ee5d 100644
>>>> --- a/drivers/clk/clk-stm32mp1.c
>>>> +++ b/drivers/clk/clk-stm32mp1.c
>>>> @@ -1949,7 +1949,6 @@ static const struct clock_config 
>>>> stm32mp1_clock_cfg[] = {
>>>> ????? KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
>>>> ????? KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
>>>> ????? KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
>>>> -??? KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
>>>> ????? /* Particulary Kernel Clocks (no mux or no gate) */
>>>> ????? MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
>>>> @@ -1958,11 +1957,16 @@ static const struct clock_config 
>>>> stm32mp1_clock_cfg[] = {
>>>> ????? MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
>>>> ????? MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
>>>> -??? COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
>>>> +??? COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
>>>> ??????????? CLK_SET_RATE_NO_REPARENT,
>>>> ??????????? _NO_GATE,
>>>> ??????????? _MMUX(M_ETHCK),
>>>> -????????? _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
>>>> +????????? _NO_DIV),
>>>> +
>>>> +??? MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
>>> assigned parent with ETHCK_K will not work
>>>> +
>>>> +??? DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |
>>>
>>> CLK_OPS_PARENT_ENABLE flags not useful with a divider.
>>
>> How so ?


From quanyang.wang at windriver.com  Fri Apr 16 15:04:30 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Fri, 16 Apr 2021 22:04:30 +0800
Subject: [PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable
 imbalance issue
In-Reply-To: <20210416125558.GA5560@sirena.org.uk>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
 <20210416004652.2975446-2-quanyang.wang@windriver.com>
 <20210416125558.GA5560@sirena.org.uk>
Message-ID: <03f4152a-e66e-6b4a-5b4a-5f79f9ce2302@windriver.com>

Hi Mark,

On 4/16/21 8:55 PM, Mark Brown wrote:
> On Fri, Apr 16, 2021 at 08:46:48AM +0800, quanyang.wang at windriver.com wrote:
>
>> Since pm_runtime works now, clks can be enabled/disabled by calling
>> zynqmp_runtime_suspend/resume. So we don't need to enable these clks
>> explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue.
>> Fixes: 1c26372e5aa9 ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework")
> Are you *sure* this fixes is accurate?  The patch (and several of the
> others that flag the same commit) doesn't apply against for-5.12, though
> at this point there's not really enough time to send another pull request
> so it doesn't super matter though someone will probably need to help out
> with stable backports.

I am sorry. These patches should NOT be with "Fixes" tag since they base 
on the patches

which are not with "Fixes". May I send a V2 patch series which remove 
these "Fixes" tags?

Thanks,

Quanyang



From bgolaszewski at baylibre.com  Fri Apr 16 15:09:28 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Fri, 16 Apr 2021 16:09:28 +0200
Subject: [PATCH v19 4/6] misc: eeprom: at24: check suspend status before
 disable regulator
In-Reply-To: <20210414172916.2689361-5-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
 <20210414172916.2689361-5-hsinyi@chromium.org>
Message-ID: <CAMpxmJUGxUPYC9NEnJDHYq7Nu=akP5GTpU0ts9htf1vELhK15Q@mail.gmail.com>

On Wed, Apr 14, 2021 at 7:29 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
> regulator in runtime suspend. If runtime suspend is called before
> regulator disable, it will results in regulator unbalanced disabling.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Please add the Fixes tag.

> ---
>  drivers/misc/eeprom/at24.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 926408b41270..7a6f01ace78a 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client *client)
>         at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
>         if (IS_ERR(at24->nvmem)) {
>                 pm_runtime_disable(dev);
> -               regulator_disable(at24->vcc_reg);
> +               if (!pm_runtime_status_suspended(dev))
> +                       regulator_disable(at24->vcc_reg);
>                 return PTR_ERR(at24->nvmem);
>         }
>
> @@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client *client)
>         err = at24_read(at24, 0, &test_byte, 1);
>         if (err) {
>                 pm_runtime_disable(dev);
> -               regulator_disable(at24->vcc_reg);
> +               if (!pm_runtime_status_suspended(dev))
> +                       regulator_disable(at24->vcc_reg);
>                 return -ENODEV;
>         }
>
> --
> 2.31.1.295.g9ea45b61b8-goog
>

Acked-by: Bartosz Golaszewski <bgolaszewski at baylibre.com>


From arnd at kernel.org  Fri Apr 16 15:10:37 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 16 Apr 2021 16:10:37 +0200
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
 <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
 <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
Message-ID: <CAK8P3a1+Dpu3ef+VYA+owTVGoGqfK6APbYbLSH1_ZKT0aMYQCw@mail.gmail.com>

On Fri, Apr 16, 2021 at 11:27 AM 'Grygorii Strashko' via Clang Built
Linux <clang-built-linux at googlegroups.com> wrote:
> On 10/04/2021 11:52, Ilias Apalodimas wrote:
> > +CC Grygorii for the cpsw part as Ivan's email is not valid anymore
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
>
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").

I completely missed this change in the past, and I don't really agree
with it either.

Most 32-bit Arm platforms are in fact limited to 32-bit DMA, even when they have
MMIO or RAM areas above the 4GB boundary that require LPAE.

> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using
> things like (__force u32) for example.
>
> Honestly, I've done sanity check of CPSW with LPAE=y (ARCH_DMA_ADDR_T_64BIT=y) very long time ago.

This is of course a good idea, drivers should work with any
combination of 32-bit
or 64-bit phys_addr_t and dma_addr_t.

        Arnd


From johan at kernel.org  Fri Apr 16 15:10:52 2021
From: johan at kernel.org (Johan Hovold)
Date: Fri, 16 Apr 2021 16:10:52 +0200
Subject: [PATCH v3] serial: stm32: optimize spin lock usage
In-Reply-To: <1618567841-18546-1-git-send-email-dillon.minfei@gmail.com>
References: <1618567841-18546-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <YHma7H3RoLyeH650@hovoldconsulting.com>

On Fri, Apr 16, 2021 at 06:10:41PM +0800, dillon.minfei at gmail.com wrote:
> From: dillon min <dillon.minfei at gmail.com>
> 
> This patch aims to fix two potential bug:
> - no lock to protect uart register in this case
> 
>   stm32_usart_threaded_interrupt()
>      spin_lock(&port->lock);
>      ...
>      stm32_usart_receive_chars()
>        uart_handle_sysrq_char();
>        sysrq_function();
>        printk();
>          stm32_usart_console_write();
>            locked = 0; //since port->sysrq is not zero,
>                          no lock to protect forward register
>                          access.
> 
> - if add spin_trylock_irqsave() to protect uart register for sysrq = 1 case,
>   that might got recursive locking under UP.
>   So, use uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq()
>   move sysrq handler position to irq/thread_d handler, just record
>   sysrq_ch in stm32_usart_receive_chars() by uart_prepare_sysrq_char()
>   delay the sysrq process to next interrupt handler.
> 
>   new flow:
> 
>   stm32_usart_threaded_interrupt()/stm32_usart_interrupt()
>   spin_lock_irqsave(&port->lock);
>   ...
>   uart_unlock_and_check_sysrq();
>      spin_unlock_irqrestore();
>      handle_sysrq(sysrq_ch);
>   stm32_usart_threaded_interrupt()//stm32_usart_interrupt() return
> 
> Cc: Johan Hovold <johan at kernel.org>
> Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v3: add uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq() to move
>     sysrq handler inside interrupt routinei to avoid recursive locking,
>     according to Johan Hovold suggestion, thanks.
> 
>  drivers/tty/serial/stm32-usart.c | 24 +++++++++++-------------
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> index b3675cf25a69..981f50ec784e 100644
> --- a/drivers/tty/serial/stm32-usart.c
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -271,7 +271,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
>  			}
>  		}
>  
> -		if (uart_handle_sysrq_char(port, c))
> +		if (uart_prepare_sysrq_char(port, c))
>  			continue;
>  		uart_insert_char(port, sr, USART_SR_ORE, c, flag);
>  	}
> @@ -457,9 +457,10 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
>  	struct uart_port *port = ptr;
>  	struct stm32_port *stm32_port = to_stm32_port(port);
>  	const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> +	unsigned long flags;
>  	u32 sr;
>  
> -	spin_lock(&port->lock);
> +	spin_lock_irqsave(&port->lock, flags);
>  
>  	sr = readl_relaxed(port->membase + ofs->isr);
>  
> @@ -477,7 +478,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
>  	if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch))
>  		stm32_usart_transmit_chars(port);
>  
> -	spin_unlock(&port->lock);
> +	uart_unlock_and_check_sysrq(port, flags);
>  
>  	if (stm32_port->rx_ch)
>  		return IRQ_WAKE_THREAD;
> @@ -489,13 +490,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
>  {
>  	struct uart_port *port = ptr;
>  	struct stm32_port *stm32_port = to_stm32_port(port);
> +	unsigned long flags;
>  
> -	spin_lock(&port->lock);
> +	spin_lock_irqsave(&port->lock, flags);

This essentially turns the threaded handler into a non-threaded one,
which is a bad idea.

>  	if (stm32_port->rx_ch)
>  		stm32_usart_receive_chars(port, true);
>  
> -	spin_unlock(&port->lock);
> +	uart_unlock_and_check_sysrq(port, flags);
>  
>  	return IRQ_HANDLED;
>  }

You also didn't base this patch on tty-next, which has a number of
updates to this driver. Before noting that myself, I had fixed a couple
of deadlocks in this driver which turned out to have been incidentally
fixed by an unrelated path in -next.

I'll be posting a series that should fix up all of this.

Johan


From maz at kernel.org  Fri Apr 16 15:15:00 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 16 Apr 2021 15:15:00 +0100
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <20210416062217.25157-1-heying24@huawei.com>
References: <20210416062217.25157-1-heying24@huawei.com>
Message-ID: <87y2dis4d7.wl-maz@kernel.org>

[+ Mark]

On Fri, 16 Apr 2021 07:22:17 +0100,
He Ying <heying24 at huawei.com> wrote:
> 
> We found this problem in our kernel src tree:
> 
> [   14.816231] ------------[ cut here ]------------
> [   14.816231] kernel BUG at irq.c:99!
> [   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
> [   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
> [   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95-1.h1.AOS2.0.aarch64 #14
> [   14.816233] Hardware name: evb (DT)
> [   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
> [   14.816234] pc : asm_nmi_enter+0x94/0x98
> [   14.816235] lr : asm_nmi_enter+0x18/0x98
> [   14.816235] sp : ffff000008003c50
> [   14.816235] pmr_save: 00000070
> [   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
> [   14.816238] x27: 0000000000000000 x26: ffff000008004000
> [   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
> [   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
> [   14.816241] x21: ffff000008003da0 x20: 0000000000000060
> [   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
> [   14.816243] x17: 0000000000000008 x16: 003d090000000000
> [   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
> [   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
> [   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
> [   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
> [   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
> [   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
> [   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
> [   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
> [   14.816251] Call trace:
> [   14.816251]  asm_nmi_enter+0x94/0x98
> [   14.816251]  el1_irq+0x8c/0x180
> [   14.816252]  gic_handle_irq+0xbc/0x2e4
> [   14.816252]  el1_irq+0xcc/0x180
> [   14.816253]  arch_timer_handler_virt+0x38/0x58
> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> [   14.816253]  generic_handle_irq+0x34/0x50
> [   14.816254]  __handle_domain_irq+0x68/0xc0
> [   14.816254]  gic_handle_irq+0xf8/0x2e4
> [   14.816255]  el1_irq+0xcc/0x180
> [   14.816255]  arch_cpu_idle+0x34/0x1c8
> [   14.816255]  default_idle_call+0x24/0x44
> [   14.816256]  do_idle+0x1d0/0x2c8
> [   14.816256]  cpu_startup_entry+0x28/0x30
> [   14.816256]  rest_init+0xb8/0xc8
> [   14.816257]  start_kernel+0x4c8/0x4f4
> [   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
> [   14.816258] Modules linked in: start_dp(O) smeth(O)
> [   15.103092] ---[ end trace 701753956cb14aa8 ]---
> [   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
> [   15.103099] SMP: stopping secondary CPUs
> [   15.103100] Kernel Offset: disabled
> [   15.103100] CPU features: 0x36,a2400218
> [   15.103100] Memory Limit: none

Urgh...

> Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
> patches but doesn't support nested NMI. Its top relative commit is
> commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs").

Can you please reproduce it with mainline and without any backport?
It is hard to reason about something that isn't a vanilla kernel.

> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
> means an interrupt preempts the other one and the new one is an NMI.
> Furthermore, by adding some prints, we find the first irq also calls
> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
> is 1023. It enables irq by calling gic_arch_enable_irqs() in
> gic_handle_irq(). At this moment, the second irq preempts the first irq
> and it's an NMI but current context is already in nmi. So that may be
> the problem.

I'm not sure I get it. From the stack trace, I see this:

[   14.816251]  asm_nmi_enter+0x94/0x98
[   14.816251]  el1_irq+0x8c/0x180			(C)
[   14.816252]  gic_handle_irq+0xbc/0x2e4
[   14.816252]  el1_irq+0xcc/0x180			(B)
[   14.816253]  arch_timer_handler_virt+0x38/0x58
[   14.816253]  handle_percpu_devid_irq+0x90/0x240
[   14.816253]  generic_handle_irq+0x34/0x50
[   14.816254]  __handle_domain_irq+0x68/0xc0
[   14.816254]  gic_handle_irq+0xf8/0x2e4
[   14.816255]  el1_irq+0xcc/0x180			(A)

which indicates that we preempted a timer interrupt (A) with another
IRQ (B), itself immediately preempted by another IRQ (C)? That's
indeed at least one too many.

Can you please describe for each of (A), (B) and (C) whether they are
spurious or not, what their priorities are if they aren't spurious?

> In my opinion, when handling spurious interrupts, we shouldn't enable irqs.
> My reason is that for spurious interrupts we may enter nmi context in
> el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
> at this time, another NMI may happen and preempt this spurious interrupt
> but the context is already in nmi. That causes a bug on if nested NMI is
> not supported. Even for nested nmi, I think it's not a normal scenario.

I would tend to agree that this isn't great. Actually, I'd probably
move the check for a spurious interrupt right after the read of
ICC_IAR1_EL1, because there is no real need to do anything else at
that point.

However, upstream is quite different from 4.19 in that respect, and
I'm not sure if what I am looking at is what you are seeing with your
older kernel.

Thanks,

	M.

> Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
> Signed-off-by: He Ying <heying24 at huawei.com>
> ---
>  drivers/irqchip/irq-gic-v3.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 94b89258d045..d3b52734a2c5 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -654,15 +654,15 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>  		return;
>  	}
>  
> +	/* Check for special IDs first */
> +	if ((irqnr >= 1020 && irqnr <= 1023))
> +		return;
> +
>  	if (gic_prio_masking_enabled()) {
>  		gic_pmr_mask_irqs();
>  		gic_arch_enable_irqs();
>  	}
>  
> -	/* Check for special IDs first */
> -	if ((irqnr >= 1020 && irqnr <= 1023))
> -		return;
> -
>  	if (static_branch_likely(&supports_deactivate_key))
>  		gic_write_eoir(irqnr);
>  	else
> -- 
> 2.17.1
> 
> 

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


From quanyang.wang at windriver.com  Fri Apr 16 15:20:42 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:42 +0800
Subject: [V2][PATCH 0/5] spi: spi-zynqmp-gqspi: fix spi issues
Message-ID: <20210416142047.6349-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

Hi all,

V2:
Remove all "Fixes:" tags since they base on some patches are not
with "Fixes:".

V1:
This series fix some issues that occurs in spi-zynqmp-gqspi.c.

Thanks,
Quanyang

Amit Kumar Mahapatra (1):
  spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug

Quanyang Wang (4):
  spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue
  spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
  spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
  spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails

 drivers/spi/spi-zynqmp-gqspi.c | 115 +++++++++++++++------------------
 1 file changed, 51 insertions(+), 64 deletions(-)

-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 15:20:43 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:43 +0800
Subject: [V2][PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable
 imbalance issue
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <20210416142047.6349-2-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The clks "pclk" and "ref_clk" are enabled twice during the probe. The
first time is in the function zynqmp_qspi_probe and the second time is
in zynqmp_qspi_setup_op which is called by devm_spi_register_controller.
Then calling zynqmp_qspi_remove (rmmod this module) to disable these clks
will trigger a warning as below:

[  309.124604] Unpreparing enabled qspi_ref
[  309.128641] WARNING: CPU: 1 PID: 537 at drivers/clk/clk.c:824 clk_core_unprepare+0x108/0x110

Since pm_runtime works now, clks can be enabled/disabled by calling
zynqmp_runtime_suspend/resume. So we don't need to enable these clks
explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue.

And remove clk enabling/disabling in zynqmp_qspi_resume because there is
no spi transfer operation so enabling ref_clk is redundant meanwhile pclk
is not disabled for it is shared with other peripherals.

Furthermore replace clk_enable/disable with clk_prepare_enable and
clk_disable_unprepare in runtime_suspend/resume functions.

Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 47 ++++++----------------------------
 1 file changed, 8 insertions(+), 39 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 32e53f379e9b..f9056f0a480c 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -487,24 +487,10 @@ static int zynqmp_qspi_setup_op(struct spi_device *qspi)
 {
 	struct spi_controller *ctlr = qspi->master;
 	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
-	struct device *dev = &ctlr->dev;
-	int ret;
 
 	if (ctlr->busy)
 		return -EBUSY;
 
-	ret = clk_enable(xqspi->refclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable device clock.\n");
-		return ret;
-	}
-
-	ret = clk_enable(xqspi->pclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable APB clock.\n");
-		clk_disable(xqspi->refclk);
-		return ret;
-	}
 	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, GQSPI_EN_MASK);
 
 	return 0;
@@ -863,26 +849,9 @@ static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
 static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
 {
 	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
-	int ret = 0;
-
-	ret = clk_enable(xqspi->pclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable APB clock.\n");
-		return ret;
-	}
-
-	ret = clk_enable(xqspi->refclk);
-	if (ret) {
-		dev_err(dev, "Cannot enable device clock.\n");
-		clk_disable(xqspi->pclk);
-		return ret;
-	}
 
 	spi_controller_resume(ctlr);
 
-	clk_disable(xqspi->refclk);
-	clk_disable(xqspi->pclk);
 	return 0;
 }
 
@@ -898,8 +867,8 @@ static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
 {
 	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
 
-	clk_disable(xqspi->refclk);
-	clk_disable(xqspi->pclk);
+	clk_disable_unprepare(xqspi->refclk);
+	clk_disable_unprepare(xqspi->pclk);
 
 	return 0;
 }
@@ -917,16 +886,16 @@ static int __maybe_unused zynqmp_runtime_resume(struct device *dev)
 	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
 	int ret;
 
-	ret = clk_enable(xqspi->pclk);
+	ret = clk_prepare_enable(xqspi->pclk);
 	if (ret) {
 		dev_err(dev, "Cannot enable APB clock.\n");
 		return ret;
 	}
 
-	ret = clk_enable(xqspi->refclk);
+	ret = clk_prepare_enable(xqspi->refclk);
 	if (ret) {
 		dev_err(dev, "Cannot enable device clock.\n");
-		clk_disable(xqspi->pclk);
+		clk_disable_unprepare(xqspi->pclk);
 		return ret;
 	}
 
@@ -1136,13 +1105,11 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto remove_master;
 	}
 
-	init_completion(&xqspi->data_completion);
-
 	xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
 	if (IS_ERR(xqspi->refclk)) {
 		dev_err(dev, "ref_clk clock not found.\n");
 		ret = PTR_ERR(xqspi->refclk);
-		goto clk_dis_pclk;
+		goto remove_master;
 	}
 
 	ret = clk_prepare_enable(xqspi->pclk);
@@ -1157,6 +1124,8 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_pclk;
 	}
 
+	init_completion(&xqspi->data_completion);
+
 	mutex_init(&xqspi->op_lock);
 
 	pm_runtime_use_autosuspend(&pdev->dev);
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 15:20:44 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:44 +0800
Subject: [V2][PATCH 2/5] spi: spi-zynqmp-gqspi: fix hang issue when
 suspend/resume
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <20210416142047.6349-3-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.

And we should check the return value of spi_controller_suspend, if
an error is returned, return it to PM subsystem to stop suspend.

Also, GQSPI_EN_MASK should be written to GQSPI_EN_OFST to enable
the spi controller in zynqmp_qspi_resume since it was disabled in
zynqmp_qspi_suspend before.

Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index f9056f0a480c..1146359528b9 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -157,6 +157,7 @@ enum mode_type {GQSPI_MODE_IO, GQSPI_MODE_DMA};
  * @data_completion:	completion structure
  */
 struct zynqmp_qspi {
+	struct spi_controller *ctlr;
 	void __iomem *regs;
 	struct clk *refclk;
 	struct clk *pclk;
@@ -827,10 +828,13 @@ static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
  */
 static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
-	struct zynqmp_qspi *xqspi = spi_controller_get_devdata(ctlr);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
+	struct spi_controller *ctlr = xqspi->ctlr;
+	int ret;
 
-	spi_controller_suspend(ctlr);
+	ret = spi_controller_suspend(ctlr);
+	if (ret)
+		return ret;
 
 	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, 0x0);
 
@@ -848,7 +852,10 @@ static int __maybe_unused zynqmp_qspi_suspend(struct device *dev)
  */
 static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
 {
-	struct spi_controller *ctlr = dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
+	struct spi_controller *ctlr = xqspi->ctlr;
+
+	zynqmp_gqspi_write(xqspi, GQSPI_EN_OFST, GQSPI_EN_MASK);
 
 	spi_controller_resume(ctlr);
 
@@ -865,7 +872,7 @@ static int __maybe_unused zynqmp_qspi_resume(struct device *dev)
  */
 static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
 {
-	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
 
 	clk_disable_unprepare(xqspi->refclk);
 	clk_disable_unprepare(xqspi->pclk);
@@ -883,7 +890,7 @@ static int __maybe_unused zynqmp_runtime_suspend(struct device *dev)
  */
 static int __maybe_unused zynqmp_runtime_resume(struct device *dev)
 {
-	struct zynqmp_qspi *xqspi = (struct zynqmp_qspi *)dev_get_drvdata(dev);
+	struct zynqmp_qspi *xqspi = dev_get_drvdata(dev);
 	int ret;
 
 	ret = clk_prepare_enable(xqspi->pclk);
@@ -1090,6 +1097,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 
 	xqspi = spi_controller_get_devdata(ctlr);
 	xqspi->dev = dev;
+	xqspi->ctlr = ctlr;
 	platform_set_drvdata(pdev, xqspi);
 
 	xqspi->regs = devm_platform_ioremap_resource(pdev, 0);
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 15:20:45 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:45 +0800
Subject: [V2][PATCH 3/5] spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <20210416142047.6349-4-quanyang.wang@windriver.com>

From: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>

During a transfer the driver filled the fifo with 4bytes,
even if the data that needs to be transfer is less that 4bytes.
This resulted in slab-out-of-bounds bug in KernelAddressSanitizer.

This patch resolves slab-out-of-bounds bug by filling the fifo
with the number of bytes that needs to transferred.

Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra at xilinx.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 1146359528b9..2e2607b5dee9 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -509,17 +509,19 @@ static void zynqmp_qspi_filltxfifo(struct zynqmp_qspi *xqspi, int size)
 	u32 count = 0, intermediate;
 
 	while ((xqspi->bytes_to_transfer > 0) && (count < size) && (xqspi->txbuf)) {
-		memcpy(&intermediate, xqspi->txbuf, 4);
-		zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
-
 		if (xqspi->bytes_to_transfer >= 4) {
+			memcpy(&intermediate, xqspi->txbuf, 4);
 			xqspi->txbuf += 4;
 			xqspi->bytes_to_transfer -= 4;
+			count += 4;
 		} else {
+			memcpy(&intermediate, xqspi->txbuf,
+			       xqspi->bytes_to_transfer);
 			xqspi->txbuf += xqspi->bytes_to_transfer;
 			xqspi->bytes_to_transfer = 0;
+			count += xqspi->bytes_to_transfer;
 		}
-		count++;
+		zynqmp_gqspi_write(xqspi, GQSPI_TXD_OFST, intermediate);
 	}
 }
 
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 15:20:46 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:46 +0800
Subject: [V2][PATCH 4/5] spi: spi-zynqmp-gqspi: fix use-after-free in
 zynqmp_qspi_exec_op
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <20210416142047.6349-5-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

When handling op->addr, it is using the buffer "tmpbuf" which has been
freed. This will trigger a use-after-free KASAN warning. Let's use
temporary variables to store op->addr.val and op->cmd.opcode to fix
this issue.

Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 2e2607b5dee9..419bc1e6358b 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -928,8 +928,9 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 	struct zynqmp_qspi *xqspi = spi_controller_get_devdata
 				    (mem->spi->master);
 	int err = 0, i;
-	u8 *tmpbuf;
 	u32 genfifoentry = 0;
+	u16 opcode = op->cmd.opcode;
+	u64 opaddr;
 
 	dev_dbg(xqspi->dev, "cmd:%#x mode:%d.%d.%d.%d\n",
 		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
@@ -942,14 +943,8 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 	genfifoentry |= xqspi->genfifobus;
 
 	if (op->cmd.opcode) {
-		tmpbuf = kzalloc(op->cmd.nbytes, GFP_KERNEL | GFP_DMA);
-		if (!tmpbuf) {
-			mutex_unlock(&xqspi->op_lock);
-			return -ENOMEM;
-		}
-		tmpbuf[0] = op->cmd.opcode;
 		reinit_completion(&xqspi->data_completion);
-		xqspi->txbuf = tmpbuf;
+		xqspi->txbuf = &opcode;
 		xqspi->rxbuf = NULL;
 		xqspi->bytes_to_transfer = op->cmd.nbytes;
 		xqspi->bytes_to_receive = 0;
@@ -963,13 +958,12 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 		if (!wait_for_completion_timeout
 		    (&xqspi->data_completion, msecs_to_jiffies(1000))) {
 			err = -ETIMEDOUT;
-			kfree(tmpbuf);
 			goto return_err;
 		}
-		kfree(tmpbuf);
 	}
 
 	if (op->addr.nbytes) {
+		xqspi->txbuf = &opaddr;
 		for (i = 0; i < op->addr.nbytes; i++) {
 			*(((u8 *)xqspi->txbuf) + i) = op->addr.val >>
 					(8 * (op->addr.nbytes - i - 1));
-- 
2.25.1



From quanyang.wang at windriver.com  Fri Apr 16 15:20:47 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 16 Apr 2021 22:20:47 +0800
Subject: [V2][PATCH 5/5] spi: spi-zynqmp-gqspi: return -ENOMEM if
 dma_map_single fails
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <20210416142047.6349-6-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP

Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/spi/spi-zynqmp-gqspi.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index 419bc1e6358b..328b6559bb19 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -733,7 +733,7 @@ static irqreturn_t zynqmp_qspi_irq(int irq, void *dev_id)
  * zynqmp_qspi_setuprxdma - This function sets up the RX DMA operation
  * @xqspi:	xqspi is a pointer to the GQSPI instance.
  */
-static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
+static int zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 {
 	u32 rx_bytes, rx_rem, config_reg;
 	dma_addr_t addr;
@@ -747,7 +747,7 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 		zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST, config_reg);
 		xqspi->mode = GQSPI_MODE_IO;
 		xqspi->dma_rx_bytes = 0;
-		return;
+		return 0;
 	}
 
 	rx_rem = xqspi->bytes_to_receive % 4;
@@ -755,8 +755,10 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 
 	addr = dma_map_single(xqspi->dev, (void *)xqspi->rxbuf,
 			      rx_bytes, DMA_FROM_DEVICE);
-	if (dma_mapping_error(xqspi->dev, addr))
+	if (dma_mapping_error(xqspi->dev, addr)) {
 		dev_err(xqspi->dev, "ERR:rxdma:memory not mapped\n");
+		return -ENOMEM;
+	}
 
 	xqspi->dma_rx_bytes = rx_bytes;
 	xqspi->dma_addr = addr;
@@ -777,6 +779,8 @@ static void zynqmp_qspi_setuprxdma(struct zynqmp_qspi *xqspi)
 
 	/* Write the number of bytes to transfer */
 	zynqmp_gqspi_write(xqspi, GQSPI_QSPIDMA_DST_SIZE_OFST, rx_bytes);
+
+	return 0;
 }
 
 /**
@@ -813,11 +817,17 @@ static void zynqmp_qspi_write_op(struct zynqmp_qspi *xqspi, u8 tx_nbits,
  * @genfifoentry:	genfifoentry is pointer to the variable in which
  *			GENFIFO	mask is returned to calling function
  */
-static void zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
+static int zynqmp_qspi_read_op(struct zynqmp_qspi *xqspi, u8 rx_nbits,
 				u32 genfifoentry)
 {
-	zynqmp_qspi_setuprxdma(xqspi);
+	int ret;
+
+	ret = zynqmp_qspi_setuprxdma(xqspi);
+	if (ret)
+		return ret;
 	zynqmp_qspi_fillgenfifo(xqspi, rx_nbits, genfifoentry);
+
+	return 0;
 }
 
 /**
@@ -1031,8 +1041,11 @@ static int zynqmp_qspi_exec_op(struct spi_mem *mem,
 			xqspi->rxbuf = (u8 *)op->data.buf.in;
 			xqspi->bytes_to_receive = op->data.nbytes;
 			xqspi->bytes_to_transfer = 0;
-			zynqmp_qspi_read_op(xqspi, op->data.buswidth,
+			err = zynqmp_qspi_read_op(xqspi, op->data.buswidth,
 					    genfifoentry);
+			if (err)
+				goto return_err;
+
 			zynqmp_gqspi_write(xqspi, GQSPI_CONFIG_OFST,
 					   zynqmp_gqspi_read
 					   (xqspi, GQSPI_CONFIG_OFST) |
@@ -1159,6 +1172,7 @@ static int zynqmp_qspi_probe(struct platform_device *pdev)
 		goto clk_dis_all;
 	}
 
+	dma_set_mask(&pdev->dev, DMA_BIT_MASK(44));
 	ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
 	ctlr->num_chipselect = GQSPI_DEFAULT_NUM_CS;
 	ctlr->mem_ops = &zynqmp_qspi_mem_ops;
-- 
2.25.1



From jani.nikula at linux.intel.com  Fri Apr 16 15:23:37 2021
From: jani.nikula at linux.intel.com (Jani Nikula)
Date: Fri, 16 Apr 2021 17:23:37 +0300
Subject: [PATCH v19 6/6] drm/i915/selftests: Rename functions names
In-Reply-To: <20210414172916.2689361-7-hsinyi@chromium.org>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
 <20210414172916.2689361-7-hsinyi@chromium.org>
Message-ID: <87y2dicnpy.fsf@intel.com>

On Thu, 15 Apr 2021, Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> pm_resume and pm_suspend might be conflict with the ones defined in
> include/linux/suspend.h. Rename pm_resume{suspend} to
> i915_pm_resume{suspend} since they are only used here.

I agree with the rationale here.

Do you need this to be part of your series, or shall we just pick this
up for i915? (We might consider renaming to something else or prefix the
functions with _ though, as we also have existing i915_pm_suspend and
i915_pm_resume elsewhere.)

BR,
Jani.

>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Reported-by: kernel test robot <lkp at intel.com>
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index dc394fb7ccfa..525afda9d31f 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -94,7 +94,7 @@ static int pm_prepare(struct drm_i915_private *i915)
>  	return 0;
>  }
>  
> -static void pm_suspend(struct drm_i915_private *i915)
> +static void i915_pm_suspend(struct drm_i915_private *i915)
>  {
>  	intel_wakeref_t wakeref;
>  
> @@ -116,7 +116,7 @@ static void pm_hibernate(struct drm_i915_private *i915)
>  	}
>  }
>  
> -static void pm_resume(struct drm_i915_private *i915)
> +static void i915_pm_resume(struct drm_i915_private *i915)
>  {
>  	intel_wakeref_t wakeref;
>  
> @@ -152,12 +152,12 @@ static int igt_gem_suspend(void *arg)
>  	if (err)
>  		goto out;
>  
> -	pm_suspend(i915);
> +	i915_pm_suspend(i915);
>  
>  	/* Here be dragons! Note that with S3RST any S3 may become S4! */
>  	simulate_hibernate(i915);
>  
> -	pm_resume(i915);
> +	i915_pm_resume(i915);
>  
>  	err = switch_to_context(ctx);
>  out:
> @@ -192,7 +192,7 @@ static int igt_gem_hibernate(void *arg)
>  	/* Here be dragons! */
>  	simulate_hibernate(i915);
>  
> -	pm_resume(i915);
> +	i915_pm_resume(i915);
>  
>  	err = switch_to_context(ctx);
>  out:

-- 
Jani Nikula, Intel Open Source Graphics Center


From chun-jie.chen at mediatek.com  Fri Apr 16 15:30:37 2021
From: chun-jie.chen at mediatek.com (Chun-Jie Chen)
Date: Fri, 16 Apr 2021 22:30:37 +0800
Subject: [PATCH v2] soc: mediatek: Fix the clock prepared issue
Message-ID: <20210416143037.27318-1-chun-jie.chen@mediatek.com>

From: "chun-jie.chen" <chun-jie.chen at mediatek.com>

In this new power domain driver, when adding one power domain
it will prepare the depenedent clocks at the same.
So we only do clk_bulk_enable/disable control during power ON/OFF.
When system suspend, the pm runtime framework will forcely power off
power domains. However, the dependent clocks are disabled but kept
preapred.

In MediaTek clock drivers, PLL would be turned ON when we do
clk_bulk_prepare control.

Clock hierarchy:
PLL -->
       DIV_CK -->
                 CLK_MUX
                 (may be dependent clocks)
                         -->
                             SUBSYS_CG
                             (may be dependent clocks)

It will lead some unexpected clock states during system suspend.
This patch will fix by doing prepare_enable/disable_unprepare on
dependent clocks at the same time while we are going to power on/off
any power domain.

Signed-off-by: Weiyi Lu <weiyi.lu at mediatek.com>
Signed-off-by: chun-jie.chen <chun-jie.chen at mediatek.com>
---
The capacity of regulator supply in power domain is provided by
the patch series [1], so resend [2] as a standalone patch.

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=410535
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/1609757093-30618-3-git-send-email-weiyi.lu at mediatek.com/
---
 drivers/soc/mediatek/mtk-pm-domains.c | 31 +++++++--------------------
 1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
index b7f697666bdd..bb466363f14f 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -211,7 +211,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 	if (ret)
 		return ret;
 
-	ret = clk_bulk_enable(pd->num_clks, pd->clks);
+	ret = clk_bulk_prepare_enable(pd->num_clks, pd->clks);
 	if (ret)
 		goto err_reg;
 
@@ -229,7 +229,7 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 	regmap_clear_bits(scpsys->base, pd->data->ctl_offs, PWR_ISO_BIT);
 	regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_RST_B_BIT);
 
-	ret = clk_bulk_enable(pd->num_subsys_clks, pd->subsys_clks);
+	ret = clk_bulk_prepare_enable(pd->num_subsys_clks, pd->subsys_clks);
 	if (ret)
 		goto err_pwr_ack;
 
@@ -246,9 +246,9 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 err_disable_sram:
 	scpsys_sram_disable(pd);
 err_disable_subsys_clks:
-	clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
+	clk_bulk_disable_unprepare(pd->num_subsys_clks, pd->subsys_clks);
 err_pwr_ack:
-	clk_bulk_disable(pd->num_clks, pd->clks);
+	clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
 err_reg:
 	scpsys_regulator_disable(pd->supply);
 	return ret;
@@ -269,7 +269,7 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
 	if (ret < 0)
 		return ret;
 
-	clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
+	clk_bulk_disable_unprepare(pd->num_subsys_clks, pd->subsys_clks);
 
 	/* subsys power off */
 	regmap_clear_bits(scpsys->base, pd->data->ctl_offs, PWR_RST_B_BIT);
@@ -284,7 +284,7 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
 	if (ret < 0)
 		return ret;
 
-	clk_bulk_disable(pd->num_clks, pd->clks);
+	clk_bulk_disable_unprepare(pd->num_clks, pd->clks);
 
 	scpsys_regulator_disable(pd->supply);
 
@@ -405,14 +405,6 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
 		pd->subsys_clks[i].clk = clk;
 	}
 
-	ret = clk_bulk_prepare(pd->num_clks, pd->clks);
-	if (ret)
-		goto err_put_subsys_clocks;
-
-	ret = clk_bulk_prepare(pd->num_subsys_clks, pd->subsys_clks);
-	if (ret)
-		goto err_unprepare_clocks;
-
 	/*
 	 * Initially turn on all domains to make the domains usable
 	 * with !CONFIG_PM and to get the hardware in sync with the
@@ -427,7 +419,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
 		ret = scpsys_power_on(&pd->genpd);
 		if (ret < 0) {
 			dev_err(scpsys->dev, "%pOF: failed to power on domain: %d\n", node, ret);
-			goto err_unprepare_clocks;
+			goto err_put_subsys_clocks;
 		}
 	}
 
@@ -435,7 +427,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
 		ret = -EINVAL;
 		dev_err(scpsys->dev,
 			"power domain with id %d already exists, check your device-tree\n", id);
-		goto err_unprepare_subsys_clocks;
+		goto err_put_subsys_clocks;
 	}
 
 	pd->genpd.name = node->name;
@@ -451,10 +443,6 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
 
 	return scpsys->pd_data.domains[id];
 
-err_unprepare_subsys_clocks:
-	clk_bulk_unprepare(pd->num_subsys_clks, pd->subsys_clks);
-err_unprepare_clocks:
-	clk_bulk_unprepare(pd->num_clks, pd->clks);
 err_put_subsys_clocks:
 	clk_bulk_put(pd->num_subsys_clks, pd->subsys_clks);
 err_put_clocks:
@@ -532,10 +520,7 @@ static void scpsys_remove_one_domain(struct scpsys_domain *pd)
 			"failed to remove domain '%s' : %d - state may be inconsistent\n",
 			pd->genpd.name, ret);
 
-	clk_bulk_unprepare(pd->num_clks, pd->clks);
 	clk_bulk_put(pd->num_clks, pd->clks);
-
-	clk_bulk_unprepare(pd->num_subsys_clks, pd->subsys_clks);
 	clk_bulk_put(pd->num_subsys_clks, pd->subsys_clks);
 }
 
-- 
2.18.0

From lee.jones at linaro.org  Fri Apr 16 15:37:05 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:05 +0100
Subject: [PATCH 20/40] drm/xlnx/zynqmp_disp: Fix incorrectly documented enum
 'zynqmp_disp_id'
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-21-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/xlnx/zynqmp_disp.c:101: warning: expecting prototype for enum zynqmp_disp_id. Prototype was for enum zynqmp_disp_layer_id instead

Cc: Hyun Kwon <hyun.kwon at xilinx.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 109d627968ac0..ca1161ec9e16f 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -91,7 +91,7 @@ struct zynqmp_disp_format {
 };
 
 /**
- * enum zynqmp_disp_id - Layer identifier
+ * enum zynqmp_disp_layer_id - Layer identifier
  * @ZYNQMP_DISP_LAYER_VID: Video layer
  * @ZYNQMP_DISP_LAYER_GFX: Graphics layer
  */
-- 
2.27.0



From lee.jones at linaro.org  Fri Apr 16 15:37:06 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:06 +0100
Subject: [PATCH 21/40] drm/xlnx/zynqmp_dp: Fix a little potential doc-rot
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-22-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/xlnx/zynqmp_dp.c:806: warning: expecting prototype for zynqmp_dp_link_train(). Prototype was for zynqmp_dp_train() instead

Cc: Hyun Kwon <hyun.kwon at xilinx.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 59d1fb017da01..5ce96421acf40 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -797,7 +797,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
 }
 
 /**
- * zynqmp_dp_link_train - Train the link
+ * zynqmp_dp_train - Train the link
  * @dp: DisplayPort IP core structure
  *
  * Return: 0 if all trains are done successfully, or corresponding error code.
-- 
2.27.0



From lee.jones at linaro.org  Fri Apr 16 15:37:19 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:19 +0100
Subject: [PATCH 34/40] drm/exynos/exynos_drm_fimd: Realign function name with
 its header
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-35-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype for shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead

Cc: Inki Dae <inki.dae at samsung.com>
Cc: Joonyoung Shim <jy0922.shim at samsung.com>
Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 49a2e0c539187..ae576122873e0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -723,7 +723,7 @@ static void fimd_win_set_colkey(struct fimd_context *ctx, unsigned int win)
 }
 
 /**
- * shadow_protect_win() - disable updating values from shadow registers at vsync
+ * fimd_shadow_protect_win() - disable updating values from shadow registers at vsync
  *
  * @ctx: local driver data
  * @win: window to protect registers for
-- 
2.27.0



From lee.jones at linaro.org  Fri Apr 16 15:37:21 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:21 +0100
Subject: [PATCH 36/40] drm/exynos/exynos7_drm_decon: Realign function name
 with its header
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-37-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/exynos/exynos7_drm_decon.c:355: warning: expecting prototype for shadow_protect_win(). Prototype was for decon_shadow_protect_win() instead

Cc: Inki Dae <inki.dae at samsung.com>
Cc: Joonyoung Shim <jy0922.shim at samsung.com>
Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
Cc: Akshu Agarwal <akshua at gmail.com>
Cc: Ajay Kumar <ajaykumar.rs at samsung.com>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 431c5d32f9a47..9b5e6f94e5585 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -344,7 +344,7 @@ static void decon_win_set_colkey(struct decon_context *ctx, unsigned int win)
 }
 
 /**
- * shadow_protect_win() - disable updating values from shadow registers at vsync
+ * decon_shadow_protect_win() - disable updating values from shadow registers at vsync
  *
  * @ctx: display and enhancement controller context
  * @win: window to protect registers for
-- 
2.27.0



From lee.jones at linaro.org  Fri Apr 16 15:37:23 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:23 +0100
Subject: [PATCH 38/40] drm/exynos/exynos_drm_ipp: Fix some function name
 disparity issues
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-39-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/exynos/exynos_drm_ipp.c:105: warning: expecting prototype for exynos_drm_ipp_ioctl_get_res_ioctl(). Prototype was for exynos_drm_ipp_get_res_ioctl() instead
 drivers/gpu/drm/exynos/exynos_drm_ipp.c:153: warning: expecting prototype for exynos_drm_ipp_ioctl_get_caps(). Prototype was for exynos_drm_ipp_get_caps_ioctl() instead

Cc: Inki Dae <inki.dae at samsung.com>
Cc: Joonyoung Shim <jy0922.shim at samsung.com>
Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
Cc: Kyungmin Park <kyungmin.park at samsung.com>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
Cc: Marek Szyprowski <m.szyprowski at samsung.com>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 4f2b7551b2515..9ae8689353579 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -88,7 +88,7 @@ void exynos_drm_ipp_unregister(struct device *dev,
 }
 
 /**
- * exynos_drm_ipp_ioctl_get_res_ioctl - enumerate all ipp modules
+ * exynos_drm_ipp_get_res_ioctl - enumerate all ipp modules
  * @dev: DRM device
  * @data: ioctl data
  * @file_priv: DRM file info
@@ -136,7 +136,7 @@ static inline struct exynos_drm_ipp *__ipp_get(uint32_t id)
 }
 
 /**
- * exynos_drm_ipp_ioctl_get_caps - get ipp module capabilities and formats
+ * exynos_drm_ipp_get_caps_ioctl - get ipp module capabilities and formats
  * @dev: DRM device
  * @data: ioctl data
  * @file_priv: DRM file info
-- 
2.27.0



From lee.jones at linaro.org  Fri Apr 16 15:37:25 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:37:25 +0100
Subject: [PATCH 40/40] drm/mediatek/mtk_disp_ccorr: Demote less than
 half-populated struct header
In-Reply-To: <20210416143725.2769053-1-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
Message-ID: <20210416143725.2769053-41-lee.jones@linaro.org>

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or member 'clk' not described in 'mtk_disp_ccorr'
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or member 'regs' not described in 'mtk_disp_ccorr'
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or member 'cmdq_reg' not described in 'mtk_disp_ccorr'
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c:46: warning: Function parameter or member 'data' not described in 'mtk_disp_ccorr'

Cc: Chun-Kuang Hu <chunkuang.hu at kernel.org>
Cc: Philipp Zabel <p.zabel at pengutronix.de>
Cc: David Airlie <airlied at linux.ie>
Cc: Daniel Vetter <daniel at ffwll.ch>
Cc: Matthias Brugger <matthias.bgg at gmail.com>
Cc: dri-devel at lists.freedesktop.org
Cc: linux-mediatek at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 141cb36b9c07b..5276909a775fc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -33,7 +33,7 @@ struct mtk_disp_ccorr_data {
 	u32 matrix_bits;
 };
 
-/**
+/*
  * struct mtk_disp_ccorr - DISP_CCORR driver structure
  * @ddp_comp - structure containing type enum and hardware resources
  * @crtc - associated crtc to report irq events to
-- 
2.27.0



From matthias.bgg at kernel.org  Fri Apr 16 15:39:21 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Fri, 16 Apr 2021 16:39:21 +0200
Subject: [PATCH 0/2] dts: mediatek: fixes for v5.13
Message-ID: <20210416143923.23406-1-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

Hi Olof and Arnd,

Here come two smaller fixes for dtbs_check. I realized that we have tons
of warnings, so I'll try to get rid of them over time, but it will be a
longer run :)

Please have a look.
Regards,
Matthias



Matthias Brugger (2):
  arm64: dts: mt8183-pumpkin: fix dtbs_check warning
  arm64: dts: mt8183: fix dtbs_check warning

 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
 arch/arm64/boot/dts/mediatek/mt8183.dtsi        | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.30.2



From matthias.bgg at kernel.org  Fri Apr 16 15:39:22 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Fri, 16 Apr 2021 16:39:22 +0200
Subject: [PATCH 1/2] arm64: dts: mt8183-pumpkin: fix dtbs_check warning
In-Reply-To: <20210416143923.23406-1-matthias.bgg@kernel.org>
References: <20210416143923.23406-1-matthias.bgg@kernel.org>
Message-ID: <20210416143923.23406-2-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

Fix unit names to make dtbs_check happy.

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-1-matthias.bgg at kernel.org
Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
---

 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index eb6e595c2975..0aff5eb52e88 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -32,7 +32,7 @@ reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
-		scp_mem_reserved: scp_mem_region {
+		scp_mem_reserved: scp_mem_region at 50000000 {
 			compatible = "shared-dma-pool";
 			reg = <0 0x50000000 0 0x2900000>;
 			no-map;
@@ -55,7 +55,7 @@ led-green {
 		};
 	};
 
-	ntc at 0 {
+	ntc {
 		compatible = "murata,ncp03wf104";
 		pullup-uv = <1800000>;
 		pullup-ohm = <390000>;
-- 
2.30.2



From matthias.bgg at kernel.org  Fri Apr 16 15:39:23 2021
From: matthias.bgg at kernel.org (matthias.bgg at kernel.org)
Date: Fri, 16 Apr 2021 16:39:23 +0200
Subject: [PATCH 2/2] arm64: dts: mt8183: fix dtbs_check warning
In-Reply-To: <20210416143923.23406-1-matthias.bgg@kernel.org>
References: <20210416143923.23406-1-matthias.bgg@kernel.org>
Message-ID: <20210416143923.23406-3-matthias.bgg@kernel.org>

From: Matthias Brugger <matthias.bgg at gmail.com>

Fix unit names to make dtbs_check happy.

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-2-matthias.bgg at kernel.org
Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>

---

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 0ff7b67a6806..c5e822b6b77a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -681,13 +681,13 @@ cpu_thermal: cpu_thermal {
 				sustainable-power = <5000>;
 
 				trips {
-					threshold: trip-point at 0 {
+					threshold: trip-point0 {
 						temperature = <68000>;
 						hysteresis = <2000>;
 						type = "passive";
 					};
 
-					target: trip-point at 1 {
+					target: trip-point1 {
 						temperature = <80000>;
 						hysteresis = <2000>;
 						type = "passive";
@@ -1103,7 +1103,7 @@ u2port0: usb-phy at 0 {
 				status = "okay";
 			};
 
-			u3port0: usb-phy at 0700 {
+			u3port0: usb-phy at 700 {
 				reg = <0x0700 0x900>;
 				clocks = <&clk26m>;
 				clock-names = "ref";
-- 
2.30.2



From alexandre.torgue at foss.st.com  Fri Apr 16 15:39:45 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Fri, 16 Apr 2021 16:39:45 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it
 with np
In-Reply-To: <362315e2-1398-4d11-e179-0ab7ca64e591@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-3-marex@denx.de>
 <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>
 <362315e2-1398-4d11-e179-0ab7ca64e591@denx.de>
Message-ID: <ffcd327e-c5b7-089c-1009-cfc97219495b@foss.st.com>

Hi Marek

On 4/16/21 3:39 PM, Marek Vasut wrote:
> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>> Hi Marek,
> 
> Hello Gabriel,
> 
>> I have a patch-set in progress using $dev (convertion into module 
>> driver).
>>
>> https://patchwork.kernel.org/project/linux-clk/list/?series=421767
>>
>> Then rebase of your patch, [PATCH 4/7] clk: stm32mp1: Add parent_data 
>> to ETHRX clock, can be done easily.
> 
> I suspect the aforementioned patchset will have to be reworked, since 
> the current approach to push SCMI onto every system and renumerate the 
> clock has been rejected, because it caused DT ABI break and boot 
> problems on many systems.

SCMI patches for clock drivers will be pushed (and merged one day :)). 
We only drop the DT part which will be done through dtbo in uboot/tfa/optee.

regards
alex

> 
> btw please don't top-post.
> 
>> Best regards
>> Gabriel
>>
>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>> Instead of passing around $dev to all the registration functions, which
>>> is always NULL, pass around struct device_node pointer $np. This way it
>>> is possible to use of_clk_hw_register*() functions and/or register clock
>>> with associated $np pointer.
> [...]


From krzysztof.kozlowski at canonical.com  Fri Apr 16 15:40:06 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Fri, 16 Apr 2021 16:40:06 +0200
Subject: [PATCH 34/40] drm/exynos/exynos_drm_fimd: Realign function name
 with its header
In-Reply-To: <20210416143725.2769053-35-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-35-lee.jones@linaro.org>
Message-ID: <f871839d-6b1b-84b4-19d1-860d209ef193@canonical.com>

On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype for shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead
> 
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hi Lee,

I already sent a fix for this one on 5th of April:
https://lore.kernel.org/lkml/20210405181524.52426-1-krzysztof.kozlowski at canonical.com/


Best regards,
Krzysztof

> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 49a2e0c539187..ae576122873e0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -723,7 +723,7 @@ static void fimd_win_set_colkey(struct fimd_context *ctx, unsigned int win)
>  }
>  
>  /**
> - * shadow_protect_win() - disable updating values from shadow registers at vsync
> + * fimd_shadow_protect_win() - disable updating values from shadow registers at vsync
>   *
>   * @ctx: local driver data
>   * @win: window to protect registers for
> 



From christophe.leroy at csgroup.eu  Fri Apr 16 15:40:52 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 16:40:52 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
 <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>
Message-ID: <b6b5300d-35a0-3bc0-ad1d-f2af433ef27e@csgroup.eu>



Le 16/04/2021 ? 15:00, Steven Price a ?crit?:
> On 16/04/2021 12:08, Christophe Leroy wrote:
>>
>>
>> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>>>> In order to support large pages on powerpc, notepage()
>>>>>> needs to know the page size of the page.
>>>>>>
>>>>>> Add a page_size argument to notepage().
>>>>>>
>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>>>>>> ---
>>>>>> ? arch/arm64/mm/ptdump.c???????? |? 2 +-
>>>>>> ? arch/riscv/mm/ptdump.c???????? |? 2 +-
>>>>>> ? arch/s390/mm/dump_pagetables.c |? 3 ++-
>>>>>> ? arch/x86/mm/dump_pagetables.c? |? 2 +-
>>>>>> ? include/linux/ptdump.h???????? |? 2 +-
>>>>>> ? mm/ptdump.c??????????????????? | 16 ++++++++--------
>>>>>> ? 6 files changed, 14 insertions(+), 13 deletions(-)
>>>>>>
>>>>> [...]
>>>>>> diff --git a/mm/ptdump.c b/mm/ptdump.c
>>>>>> index da751448d0e4..61cd16afb1c8 100644
>>>>>> --- a/mm/ptdump.c
>>>>>> +++ b/mm/ptdump.c
>>>>>> @@ -17,7 +17,7 @@ static inline int note_kasan_page_table(struct mm_walk *walk,
>>>>>> ? {
>>>>>> ????? struct ptdump_state *st = walk->private;
>>>>>> -??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]));
>>>>>> +??? st->note_page(st, addr, 4, pte_val(kasan_early_shadow_pte[0]), PAGE_SIZE);
>>>>>
>>>>> I'm not completely sure what the page_size is going to be used for, but note that KASAN 
>>>>> presents an interesting case here. We short-cut by detecting it's a KASAN region at a high 
>>>>> level (PGD/P4D/PUD/PMD) and instead of walking the tree down just call note_page() *once* but 
>>>>> with level==4 because we know KASAN sets up the page table like that.
>>>>>
>>>>> However the one call actually covers a much larger region - so while PAGE_SIZE matches the 
>>>>> level it doesn't match the region covered. AFAICT this will lead to odd results if you enable 
>>>>> KASAN on powerpc.
>>>>
>>>> Hum .... I successfully tested it with KASAN, I now realise that I tested it with 
>>>> CONFIG_KASAN_VMALLOC selected. In this situation, since 
>>>> https://github.com/torvalds/linux/commit/af3d0a686 we don't have any common shadow page table 
>>>> anymore.
>>>>
>>>> I'll test again without CONFIG_KASAN_VMALLOC.
>>>>
>>>>>
>>>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be 
>>>>> using it purely to find "holes" in the calls to note_page(), but I haven't worked out why such 
>>>>> holes would occur.
>>>>
>>>> I was indeed introduced for KASAN. We have a first commit 
>>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is a 
>>>> KASAN like stuff.
>>>>
>>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what the 
>>>> problem was exactly, something around the use of hugepages for kernel memory, came as part of 
>>>> the series 
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>>
>>>
>>>
>>>
>>> Ah, that's useful context. So it looks like powerpc took a different route to reducing the KASAN 
>>> output to x86.
>>>
>>> Given the generic ptdump code has handling for KASAN already it should be possible to drop that 
>>> from the powerpc arch code, which I think means we don't actually need to provide page size to 
>>> notepage(). Hopefully that means more code to delete ;)
>>>
>>
>> Yes ... and no.
>>
>> It looks like the generic ptdump handles the case when several pgdir entries points to the same 
>> kasan_early_shadow_pte. But it doesn't take into account the powerpc case where we have regular 
>> page tables where several (if not all) PTEs are pointing to the kasan_early_shadow_page .
> 
> I'm not sure I follow quite how powerpc is different here. But could you have a similar check for 
> PTEs against kasan_early_shadow_pte as the other levels already have?
> 
> I'm just worried that page_size isn't well defined in this interface and it's going to cause 
> problems in the future.
> 

I'm trying. I reverted the two commits b00ff6d8c and cabe8138.

At the moment, I don't get exactly what I expect: For linear memory I get one line for each 8M page 
whereas before reverting the patches I got one 16M line and one 112M line.

And for KASAN shadow area I get two lines for the 2x 8M pages shadowing linear mem then I get one 4M 
line for each PGDIR entry pointing to kasan_early_shadow_pte.

0xf8000000-0xf87fffff 0x07000000         8M   huge        rw       present
0xf8800000-0xf8ffffff 0x07800000         8M   huge        rw       present
0xf9000000-0xf93fffff 0x01430000         4M               r        present
0xf9400000-0xf97fffff 0x01430000         4M               r        present
0xf9800000-0xf9bfffff 0x01430000         4M               r        present
0xf9c00000-0xf9ffffff 0x01430000         4M               r        present
0xfa000000-0xfa3fffff 0x01430000         4M               r        present
0xfa400000-0xfa7fffff 0x01430000         4M               r        present
0xfa800000-0xfabfffff 0x01430000         4M               r        present
0xfac00000-0xfaffffff 0x01430000         4M               r        present
0xfb000000-0xfb3fffff 0x01430000         4M               r        present
0xfb400000-0xfb7fffff 0x01430000         4M               r        present
0xfb800000-0xfbbfffff 0x01430000         4M               r        present
0xfbc00000-0xfbffffff 0x01430000         4M               r        present
0xfc000000-0xfc3fffff 0x01430000         4M               r        present
0xfc400000-0xfc7fffff 0x01430000         4M               r        present
0xfc800000-0xfcbfffff 0x01430000         4M               r        present
0xfcc00000-0xfcffffff 0x01430000         4M               r        present
0xfd000000-0xfd3fffff 0x01430000         4M               r        present
0xfd400000-0xfd7fffff 0x01430000         4M               r        present
0xfd800000-0xfdbfffff 0x01430000         4M               r        present
0xfdc00000-0xfdffffff 0x01430000         4M               r        present
0xfe000000-0xfe3fffff 0x01430000         4M               r        present
0xfe400000-0xfe7fffff 0x01430000         4M               r        present
0xfe800000-0xfebfffff 0x01430000         4M               r        present
0xfec00000-0xfeffffff 0x01430000         4M               r        present

Any idea ?

Christophe


From krzysztof.kozlowski at canonical.com  Fri Apr 16 15:41:07 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Fri, 16 Apr 2021 16:41:07 +0200
Subject: [PATCH 36/40] drm/exynos/exynos7_drm_decon: Realign function name
 with its header
In-Reply-To: <20210416143725.2769053-37-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-37-lee.jones@linaro.org>
Message-ID: <9b6753f4-a448-514d-85b0-2f3ab3049f1c@canonical.com>

On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c:355: warning: expecting prototype for shadow_protect_win(). Prototype was for decon_shadow_protect_win() instead
> 
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> Cc: Akshu Agarwal <akshua at gmail.com>
> Cc: Ajay Kumar <ajaykumar.rs at samsung.com>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Fri Apr 16 15:42:04 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Fri, 16 Apr 2021 16:42:04 +0200
Subject: [PATCH 38/40] drm/exynos/exynos_drm_ipp: Fix some function name
 disparity issues
In-Reply-To: <20210416143725.2769053-39-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-39-lee.jones@linaro.org>
Message-ID: <81a27ab8-9e2e-8f29-c1dd-19ec54ec3d28@canonical.com>

On 16/04/2021 16:37, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c:105: warning: expecting prototype for exynos_drm_ipp_ioctl_get_res_ioctl(). Prototype was for exynos_drm_ipp_get_res_ioctl() instead
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c:153: warning: expecting prototype for exynos_drm_ipp_ioctl_get_caps(). Prototype was for exynos_drm_ipp_get_caps_ioctl() instead
> 
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> Cc: Marek Szyprowski <m.szyprowski at samsung.com>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Best regards,
Krzysztof


From matthias.bgg at gmail.com  Fri Apr 16 15:42:25 2021
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 16 Apr 2021 16:42:25 +0200
Subject: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210415093519.1920877-4-hsinyi@chromium.org>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-4-hsinyi@chromium.org>
Message-ID: <face0af7-8630-31fa-4975-a80311257d13@gmail.com>



On 15/04/2021 11:35, Hsin-Yi Wang wrote:
> Kenzo is known as Acer Chromebook 311.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 0870490aa350..39e4a99ebb37 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -137,9 +137,11 @@ properties:
>          items:
>            - const: google,damu
>            - const: mediatek,mt8183
> -      - description: Google Juniper (Acer Chromebook Spin 311)
> +      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Crhomebook 311)

Crhomebook -> Chromebook :)

>          items:
> -          - const: google,juniper-sku16
> +          - enum:
> +              - google,juniper-sku16
> +              - google,juniper-sku17
>            - const: google,juniper
>            - const: mediatek,mt8183
>        - description: Google Kakadu (ASUS Chromebook Detachable CM3)
> 


From hsinyi at chromium.org  Fri Apr 16 15:42:44 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri, 16 Apr 2021 22:42:44 +0800
Subject: [PATCH v19 6/6] drm/i915/selftests: Rename functions names
In-Reply-To: <87y2dicnpy.fsf@intel.com>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
 <20210414172916.2689361-7-hsinyi@chromium.org>
 <87y2dicnpy.fsf@intel.com>
Message-ID: <CAJMQK-iUgQBH8uW07fpbptE33D5NsVwmZXngcZknPw93apRK0A@mail.gmail.com>

On Fri, Apr 16, 2021 at 10:23 PM Jani Nikula
<jani.nikula at linux.intel.com> wrote:
>
> On Thu, 15 Apr 2021, Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> > pm_resume and pm_suspend might be conflict with the ones defined in
> > include/linux/suspend.h. Rename pm_resume{suspend} to
> > i915_pm_resume{suspend} since they are only used here.
>
> I agree with the rationale here.
>
> Do you need this to be part of your series, or shall we just pick this
> up for i915? (We might consider renaming to something else or prefix the
> functions with _ though, as we also have existing i915_pm_suspend and
> i915_pm_resume elsewhere.)
>

This patch can be separated from the series, thanks.


> BR,
> Jani.
>
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> > Reported-by: kernel test robot <lkp at intel.com>
> > ---
> >  drivers/gpu/drm/i915/selftests/i915_gem.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
> > index dc394fb7ccfa..525afda9d31f 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> > @@ -94,7 +94,7 @@ static int pm_prepare(struct drm_i915_private *i915)
> >       return 0;
> >  }
> >
> > -static void pm_suspend(struct drm_i915_private *i915)
> > +static void i915_pm_suspend(struct drm_i915_private *i915)
> >  {
> >       intel_wakeref_t wakeref;
> >
> > @@ -116,7 +116,7 @@ static void pm_hibernate(struct drm_i915_private *i915)
> >       }
> >  }
> >
> > -static void pm_resume(struct drm_i915_private *i915)
> > +static void i915_pm_resume(struct drm_i915_private *i915)
> >  {
> >       intel_wakeref_t wakeref;
> >
> > @@ -152,12 +152,12 @@ static int igt_gem_suspend(void *arg)
> >       if (err)
> >               goto out;
> >
> > -     pm_suspend(i915);
> > +     i915_pm_suspend(i915);
> >
> >       /* Here be dragons! Note that with S3RST any S3 may become S4! */
> >       simulate_hibernate(i915);
> >
> > -     pm_resume(i915);
> > +     i915_pm_resume(i915);
> >
> >       err = switch_to_context(ctx);
> >  out:
> > @@ -192,7 +192,7 @@ static int igt_gem_hibernate(void *arg)
> >       /* Here be dragons! */
> >       simulate_hibernate(i915);
> >
> > -     pm_resume(i915);
> > +     i915_pm_resume(i915);
> >
> >       err = switch_to_context(ctx);
> >  out:
>
> --
> Jani Nikula, Intel Open Source Graphics Center


From madvenka at linux.microsoft.com  Fri Apr 16 15:43:48 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 16 Apr 2021 09:43:48 -0500
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
 <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
 <20210413110255.GB5586@sirena.org.uk>
 <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>
Message-ID: <e8367fe9-6fd0-f962-422d-daa4548cc3b7@linux.microsoft.com>



On 4/14/21 5:23 AM, Madhavan T. Venkataraman wrote:
> In any case, I have absolutely no problems in implementing your section idea. I will
> make an attempt to do that in version 3 of my patch series.

So, I attempted a patch with just declaring all .entry.text functions as unreliable
by checking just the section bounds. It does work for EL1 exceptions. But there
are other functions that are actually reliable that show up as unreliable.
The example in my test is el0_sync() which is at the base of all system call stacks.

How would you prefer I handle this? Should I place all SYM_CODE functions that
are actually safe for the unwinder in a separate section? I could just take
some approach and solve this. But I would like to get your opinion and Mark
Rutland's opinion so we are all on the same page.

Please let me know.

Madhavan


From maz at kernel.org  Fri Apr 16 15:44:22 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 16 Apr 2021 15:44:22 +0100
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <8f55b64f-b4dd-700e-c997-8de9c5ea282f@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <8f55b64f-b4dd-700e-c997-8de9c5ea282f@huawei.com>
Message-ID: <87a6py2ss9.wl-maz@kernel.org>

On Thu, 15 Apr 2021 15:08:09 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Marc,
> 
> On 2021/4/15 22:03, Keqian Zhu wrote:
> > The MMIO region of a device maybe huge (GB level), try to use
> > block mapping in stage2 to speedup both map and unmap.
> > 
> > Compared to normal memory mapping, we should consider two more
> > points when try block mapping for MMIO region:
> > 
> > 1. For normal memory mapping, the PA(host physical address) and
> > HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> > the HVA to request hugepage, so we don't need to consider PA
> > alignment when verifing block mapping. But for device memory
> > mapping, the PA and HVA may have different alignment.
> > 
> > 2. For normal memory mapping, we are sure hugepage size properly
> > fit into vma, so we don't check whether the mapping size exceeds
> > the boundary of vma. But for device memory mapping, we should pay
> > attention to this.
> > 
> > This adds get_vma_page_shift() to get page shift for both normal
> > memory and device MMIO region, and check these two points when
> > selecting block mapping size for MMIO region.
> > 
> > Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> > ---
> >  arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
> >  1 file changed, 51 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index c59af5ca01b0..5a1cc7751e6d 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
> >  	return PAGE_SIZE;
> >  }
> >  
> > +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> > +{
> > +	unsigned long pa;
> > +
> > +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> > +		return huge_page_shift(hstate_vma(vma));
> > +
> > +	if (!(vma->vm_flags & VM_PFNMAP))
> > +		return PAGE_SHIFT;
> > +
> > +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> > +
> > +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> > +
> > +#ifndef __PAGETABLE_PMD_FOLDED
> > +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> > +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> > +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> > +		return PUD_SHIFT;
> > +#endif
> > +
> > +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> > +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> > +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> > +		return PMD_SHIFT;
> > +
> > +	return PAGE_SHIFT;
> > +}
> > +
> >  static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  			  struct kvm_memory_slot *memslot, unsigned long hva,
> >  			  unsigned long fault_status)
> > @@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  		return -EFAULT;
> >  	}
> >  
> > -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> > +	/*
> > +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> > +	 * get block mapping for device MMIO region.
> > +	 */
> >  	mmap_read_lock(current->mm);
> >  	vma = find_vma_intersection(current->mm, hva, hva + 1);
> >  	if (unlikely(!vma)) {
> > @@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >  		return -EFAULT;
> >  	}
> >  
> > -	if (is_vm_hugetlb_page(vma))
> > -		vma_shift = huge_page_shift(hstate_vma(vma));
> > -	else
> > -		vma_shift = PAGE_SHIFT;
> > -
> > -	if (logging_active ||
> > -	    (vma->vm_flags & VM_PFNMAP)) {
> > +	/*
> > +	 * logging_active is guaranteed to never be true for VM_PFNMAP
> > +	 * memslots.
> > +	 */
> > +	if (logging_active) {
> >  		force_pte = true;
> >  		vma_shift = PAGE_SHIFT;
> > +	} else {
> > +		vma_shift = get_vma_page_shift(vma, hva);
> >  	}
> I use a if/else manner in v4, please check that. Thanks very much!

That's fine. However, it is getting a bit late for 5.13, and we don't
have much time to left it simmer in -next. I'll probably wait until
after the merge window to pick it up.

Thanks,

	M.

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


From laurent.pinchart at ideasonboard.com  Fri Apr 16 15:45:02 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 16 Apr 2021 17:45:02 +0300
Subject: [PATCH 20/40] drm/xlnx/zynqmp_disp: Fix incorrectly documented
 enum 'zynqmp_disp_id'
In-Reply-To: <20210416143725.2769053-21-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-21-lee.jones@linaro.org>
Message-ID: <YHmi7psSllqh9WwG@pendragon.ideasonboard.com>

Hi Lee,

Thank you for the patch.

On Fri, Apr 16, 2021 at 03:37:05PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/xlnx/zynqmp_disp.c:101: warning: expecting prototype for enum zynqmp_disp_id. Prototype was for enum zynqmp_disp_layer_id instead
> 
> Cc: Hyun Kwon <hyun.kwon at xilinx.com>
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 109d627968ac0..ca1161ec9e16f 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -91,7 +91,7 @@ struct zynqmp_disp_format {
>  };
>  
>  /**
> - * enum zynqmp_disp_id - Layer identifier
> + * enum zynqmp_disp_layer_id - Layer identifier
>   * @ZYNQMP_DISP_LAYER_VID: Video layer
>   * @ZYNQMP_DISP_LAYER_GFX: Graphics layer
>   */

-- 
Regards,

Laurent Pinchart


From mathieu.poirier at linaro.org  Fri Apr 16 15:46:01 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 08:46:01 -0600
Subject: [PATCH 0/1] coresight: Fix for v5.12-rc7
In-Reply-To: <YHk+jRT/164eCnWa@kroah.com>
References: <20210415202404.945368-1-mathieu.poirier@linaro.org>
 <YHk0iDnfujBR3mTB@kroah.com> <YHk+jRT/164eCnWa@kroah.com>
Message-ID: <CANLsYky+tu0a-h1V=1AegXm8UvpfAbSfwYv0TgSQzRj1fZ=1UA@mail.gmail.com>

On Fri, 16 Apr 2021 at 01:36, Greg KH <gregkh at linuxfoundation.org> wrote:
>
> On Fri, Apr 16, 2021 at 08:54:00AM +0200, Greg KH wrote:
> > On Thu, Apr 15, 2021 at 02:24:03PM -0600, Mathieu Poirier wrote:
> > > Hi Greg,
> > >
> > > Please consider this patch as a fix for v5.12-rc7.  Applies cleanly
> > > to your char-misc-linus branch (e49d033bddf5).
> >
> > It's too late for 5.12-final, and really my tree should be closed for
> > 5.13-rc1 now.  I can sneak this in for the merge window, is that ok?
>

Yes, definitely.

> I've just taken it for my 5.13-rc1 set of patches and added a cc: stable
> to get it backported to 5.12.1.
>

That will be just fine.

> thanks,
>
> greg k-h


From laurent.pinchart at ideasonboard.com  Fri Apr 16 15:46:57 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 16 Apr 2021 17:46:57 +0300
Subject: [PATCH 21/40] drm/xlnx/zynqmp_dp: Fix a little potential doc-rot
In-Reply-To: <20210416143725.2769053-22-lee.jones@linaro.org>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-22-lee.jones@linaro.org>
Message-ID: <YHmjYRKouy9P/YGb@pendragon.ideasonboard.com>

Hi Lee,

Thank you for the patch.

On Fri, Apr 16, 2021 at 03:37:06PM +0100, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/xlnx/zynqmp_dp.c:806: warning: expecting prototype for zynqmp_dp_link_train(). Prototype was for zynqmp_dp_train() instead
> 
> Cc: Hyun Kwon <hyun.kwon at xilinx.com>
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

I assume you'll merge the whole series in one go through drm-misc. If
that's not the case, please let me know and I'll take the zynqmp patches
in my tree.

> ---
>  drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 59d1fb017da01..5ce96421acf40 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -797,7 +797,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
>  }
>  
>  /**
> - * zynqmp_dp_link_train - Train the link
> + * zynqmp_dp_train - Train the link
>   * @dp: DisplayPort IP core structure
>   *
>   * Return: 0 if all trains are done successfully, or corresponding error code.

-- 
Regards,

Laurent Pinchart


From lee.jones at linaro.org  Fri Apr 16 15:47:21 2021
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 16 Apr 2021 15:47:21 +0100
Subject: [PATCH 34/40] drm/exynos/exynos_drm_fimd: Realign function name
 with its header
In-Reply-To: <f871839d-6b1b-84b4-19d1-860d209ef193@canonical.com>
References: <20210416143725.2769053-1-lee.jones@linaro.org>
 <20210416143725.2769053-35-lee.jones@linaro.org>
 <f871839d-6b1b-84b4-19d1-860d209ef193@canonical.com>
Message-ID: <20210416144721.GZ4869@dell>

On Fri, 16 Apr 2021, Krzysztof Kozlowski wrote:

> On 16/04/2021 16:37, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> > 
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c:734: warning: expecting prototype for shadow_protect_win(). Prototype was for fimd_shadow_protect_win() instead
> > 
> > Cc: Inki Dae <inki.dae at samsung.com>
> > Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> > Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> > Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > Cc: David Airlie <airlied at linux.ie>
> > Cc: Daniel Vetter <daniel at ffwll.ch>
> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-samsung-soc at vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones at linaro.org>
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Hi Lee,
> 
> I already sent a fix for this one on 5th of April:
> https://lore.kernel.org/lkml/20210405181524.52426-1-krzysztof.kozlowski at canonical.com/

No problem.  Thanks for letting me know.

-- 
Lee Jones [???]
Senior Technical Lead - Developer Services
Linaro.org ? Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


From mike.leach at linaro.org  Fri Apr 16 15:47:35 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Fri, 16 Apr 2021 15:47:35 +0100
Subject: [PATCH v1 2/2] dt-bindings: arm: add property for coresight
 component name
In-Reply-To: <4c91ac77d6a9def6e521c6a2aeaa32eb@codeaurora.org>
References: <4c91ac77d6a9def6e521c6a2aeaa32eb@codeaurora.org>
Message-ID: <CAJ9a7VhKLcptnONy2ZAQxWZb1eREU6fn-voU9xon_nw7gVKPqQ@mail.gmail.com>

Hi

On Fri, 16 Apr 2021 at 15:16, <taozha at codeaurora.org> wrote:
>
> On 2021-04-16 19:23, Alexander Shishkin wrote:
> > Tao Zhang <taozha at codeaurora.org> writes:
> >
> >> Add property "coresight-name" for coresight component name. This
> >> allows coresight driver to read device name from device entries.
> >>
> >> Signed-off-by: Tao Zhang <taozha at codeaurora.org>
> >> ---
> >>  Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
> >> b/Documentation/devicetree/bindings/arm/coresight.txt
> >> index d711676..0e980ce 100644
> >> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> >> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> >> @@ -103,6 +103,8 @@ its hardware characteristcs.
> >>        powers down the coresight component also powers down and loses its
> >>        context. This property is currently only used for the ETM 4.x
> >> driver.
> >>
> >> +    * coresight-name: the name of the coresight devices.
> >
> > Which devices? Also, is it a common practice to extend device tree
> > definitions based on arbitrary driver needs, or should there be some
> > sort of a discussion first?
> >
> > Regards,
> > --
> > Alex
> Through the device tree entries, we can define their own name for any
> coresight device. This design is mainly used to facilitate the unified
> naming of coresight devgies across targets. e.g, without this patch, we
> can only see from sysFS there are multiple funnels, but we cannot know
> which funnel it is based on their names from sysFS. After applying this
> patch, we can directly know what device it is by observing the device
> name in sysFS. And the common scripts can be developed, since applying
> this patch, the same coresight device can have the same name across
> targets. Each developer or vendor can define the name of each coresight
> device according to their preferences and products.
>
> Tao

1) I am concerned that this will break the existing protocol which
associates a fixed device type name + number with each device - i.e.
etm0, funnel1 etc.
This naming convention allows for generic common scripts to be developed - see:
./tools/perf/tests/shel/test_arm_coresight.sh
This relies on the device type prefixes to iterate across all devices
in a system - and uses the connections links that are present in each
of the devices to determine the topology.
Replacing these with arbitrary names will break existing scripts.

2) Using the current system it is entirely possible to determine which
specific device a given name relates to.
e.g. ls -al /sys/bus/coresight/devices/

lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu0 ->
../../../devices/platform/soc/858000.cti/cti_cpu0
lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu1 ->
../../../devices/platform/soc/859000.cti/cti_cpu1
lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu2 ->
../../../devices/platform/soc/85a000.cti/cti_cpu2
lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_cpu3 ->
../../../devices/platform/soc/85b000.cti/cti_cpu3
lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys0 ->
../../../devices/platform/soc/810000.cti/cti_sys0
lrwxrwxrwx 1 root root 0 Apr 14 19:02 cti_sys1 ->
../../../devices/platform/soc/811000.cti/cti_sys1
lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm0 ->
../../../devices/platform/soc/85c000.etm/etm0
lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm1 ->
../../../devices/platform/soc/85d000.etm/etm1
lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm2 ->
../../../devices/platform/soc/85e000.etm/etm2
lrwxrwxrwx 1 root root 0 Apr 14 19:02 etm3 ->
../../../devices/platform/soc/85f000.etm/etm3
lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel0 ->
../../../devices/platform/soc/821000.funnel/funnel0
lrwxrwxrwx 1 root root 0 Apr 16 14:17 funnel1 ->
../../../devices/platform/soc/841000.funnel/funnel1
lrwxrwxrwx 1 root root 0 Apr 16 14:17 replicator0 ->
../../../devices/platform/soc/824000.replicator/replicator0
lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etf0 ->
../../../devices/platform/soc/825000.etf/tmc_etf0
lrwxrwxrwx 1 root root 0 Apr 16 14:17 tmc_etr0 ->
../../../devices/platform/soc/826000.etr/tmc_etr0
lrwxrwxrwx 1 root root 0 Apr 16 14:17 tpiu0 ->
../../../devices/platform/soc/820000.tpiu/tpiu

Further topology can be determined using the connections sub-directory
in each device:-

ls -al  /sys/bus/coresight/devices/etm0/connections/out\:0
lrwxrwxrwx 1 root root 0 Apr 16 14:18
/sys/bus/coresight/devices/etm0/connections/out:0 ->
../../../841000.funnel/funnel1

Using this information it is possible to iterate across the entire
topology of any coresight system.

3) If there is some scripting requirement that cannot be solved with
the information available above - then it would be better to add this
name as an alias rather than a direct replacement.
Therefore any coresight device could have an alias_name entry, that
could be interrogated by a script and used as required. This avoids
breaking any existing scripts using the established naming convention.

4) Any devicetree attribute should follow the <owner>,<attribute>
naming convention. e.g. arm,some_attribute.
I agree with Alex that it may not be normal practice to add in
attributes in these circumstances - this does not appear to relate to
a specific hardware feature or limitation. You may wish to discuss
this with the device tree maintainers.

Thanks and Regards

Mike

-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From marex at denx.de  Fri Apr 16 15:54:22 2021
From: marex at denx.de (Marek Vasut)
Date: Fri, 16 Apr 2021 16:54:22 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it
 with np
In-Reply-To: <ffcd327e-c5b7-089c-1009-cfc97219495b@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-3-marex@denx.de>
 <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>
 <362315e2-1398-4d11-e179-0ab7ca64e591@denx.de>
 <ffcd327e-c5b7-089c-1009-cfc97219495b@foss.st.com>
Message-ID: <4fc3589d-8602-6567-9800-71f2fd21e450@denx.de>

On 4/16/21 4:39 PM, Alexandre TORGUE wrote:
> Hi Marek

Hello Alexandre,

> On 4/16/21 3:39 PM, Marek Vasut wrote:
>> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>>> Hi Marek,
>>
>> Hello Gabriel,
>>
>>> I have a patch-set in progress using $dev (convertion into module 
>>> driver).
>>>
>>> https://patchwork.kernel.org/project/linux-clk/list/?series=421767
>>>
>>> Then rebase of your patch, [PATCH 4/7] clk: stm32mp1: Add parent_data 
>>> to ETHRX clock, can be done easily.
>>
>> I suspect the aforementioned patchset will have to be reworked, since 
>> the current approach to push SCMI onto every system and renumerate the 
>> clock has been rejected, because it caused DT ABI break and boot 
>> problems on many systems.
> 
> SCMI patches for clock drivers will be pushed (and merged one day :)). 
> We only drop the DT part which will be done through dtbo in 
> uboot/tfa/optee.
If the result works for both options (without SCMI and opt-in with 
SCMI), then that's fine. Does the aforementioned patchset already 
implement that ?

If so (or if there is a rebase + repost of the above patchset which 
does), then I am happy to rebase this one on top.

-- 
Best regards,
Marek Vasut


From alexandre.torgue at foss.st.com  Fri Apr 16 16:01:01 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Fri, 16 Apr 2021 17:01:01 +0200
Subject: [PATCH 2/7] clk: stm32mp1: The dev is always NULL, replace it
 with np
In-Reply-To: <4fc3589d-8602-6567-9800-71f2fd21e450@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-3-marex@denx.de>
 <a1768f19-fd80-abd7-03ee-8e47c124a271@foss.st.com>
 <362315e2-1398-4d11-e179-0ab7ca64e591@denx.de>
 <ffcd327e-c5b7-089c-1009-cfc97219495b@foss.st.com>
 <4fc3589d-8602-6567-9800-71f2fd21e450@denx.de>
Message-ID: <230f1d58-6f26-fbba-b39b-6a569a40cc3d@foss.st.com>



On 4/16/21 4:54 PM, Marek Vasut wrote:
> On 4/16/21 4:39 PM, Alexandre TORGUE wrote:
>> Hi Marek
> 
> Hello Alexandre,
> 
>> On 4/16/21 3:39 PM, Marek Vasut wrote:
>>> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>>>> Hi Marek,
>>>
>>> Hello Gabriel,
>>>
>>>> I have a patch-set in progress using $dev (convertion into module 
>>>> driver).
>>>>
>>>> https://patchwork.kernel.org/project/linux-clk/list/?series=421767
>>>>
>>>> Then rebase of your patch, [PATCH 4/7] clk: stm32mp1: Add 
>>>> parent_data to ETHRX clock, can be done easily.
>>>
>>> I suspect the aforementioned patchset will have to be reworked, since 
>>> the current approach to push SCMI onto every system and renumerate 
>>> the clock has been rejected, because it caused DT ABI break and boot 
>>> problems on many systems.
>>
>> SCMI patches for clock drivers will be pushed (and merged one day :)). 
>> We only drop the DT part which will be done through dtbo in 
>> uboot/tfa/optee.
> If the result works for both options (without SCMI and opt-in with 
> SCMI), then that's fine. Does the aforementioned patchset already 
> implement that ?

yes it will work with basic boot. You can have a try with on your DH board.

> 
> If so (or if there is a rebase + repost of the above patchset which 
> does), then I am happy to rebase this one on top.
> 

thanks


From christophe.leroy at csgroup.eu  Fri Apr 16 16:04:56 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 17:04:56 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <b6b5300d-35a0-3bc0-ad1d-f2af433ef27e@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
 <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>
 <b6b5300d-35a0-3bc0-ad1d-f2af433ef27e@csgroup.eu>
Message-ID: <b245cf06-f2e5-87a5-9a5e-64efc39d415a@csgroup.eu>



Le 16/04/2021 ? 16:40, Christophe Leroy a ?crit?:
> 
> 
> Le 16/04/2021 ? 15:00, Steven Price a ?crit?:
>> On 16/04/2021 12:08, Christophe Leroy wrote:
>>>
>>>
>>> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>>>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be 
>>>>>> using it purely to find "holes" in the calls to note_page(), but I haven't worked out why such 
>>>>>> holes would occur.
>>>>>
>>>>> I was indeed introduced for KASAN. We have a first commit 
>>>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is 
>>>>> a KASAN like stuff.
>>>>>
>>>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what 
>>>>> the problem was exactly, something around the use of hugepages for kernel memory, came as part 
>>>>> of the series 
>>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ah, that's useful context. So it looks like powerpc took a different route to reducing the KASAN 
>>>> output to x86.
>>>>
>>>> Given the generic ptdump code has handling for KASAN already it should be possible to drop that 
>>>> from the powerpc arch code, which I think means we don't actually need to provide page size to 
>>>> notepage(). Hopefully that means more code to delete ;)
>>>>
>>>
>>> Yes ... and no.
>>>
>>> It looks like the generic ptdump handles the case when several pgdir entries points to the same 
>>> kasan_early_shadow_pte. But it doesn't take into account the powerpc case where we have regular 
>>> page tables where several (if not all) PTEs are pointing to the kasan_early_shadow_page .
>>
>> I'm not sure I follow quite how powerpc is different here. But could you have a similar check for 
>> PTEs against kasan_early_shadow_pte as the other levels already have?
>>
>> I'm just worried that page_size isn't well defined in this interface and it's going to cause 
>> problems in the future.
>>
> 
> I'm trying. I reverted the two commits b00ff6d8c and cabe8138.
> 
> At the moment, I don't get exactly what I expect: For linear memory I get one line for each 8M page 
> whereas before reverting the patches I got one 16M line and one 112M line.
> 
> And for KASAN shadow area I get two lines for the 2x 8M pages shadowing linear mem then I get one 4M 
> line for each PGDIR entry pointing to kasan_early_shadow_pte.
> 
> 0xf8000000-0xf87fffff 0x07000000???????? 8M?? huge??????? rw?????? present
> 0xf8800000-0xf8ffffff 0x07800000???????? 8M?? huge??????? rw?????? present
> 0xf9000000-0xf93fffff 0x01430000???????? 4M?????????????? r??????? present
...
> 0xfec00000-0xfeffffff 0x01430000???????? 4M?????????????? r??????? present
> 
> Any idea ?
> 


I think the different with other architectures is here:

	} else if (flag != st->current_flags || level != st->level ||
		   addr >= st->marker[1].start_address ||
		   pa != st->last_pa + PAGE_SIZE) {


In addition to the checks everyone do, powerpc also checks "pa != st->last_pa + PAGE_SIZE".
And it is definitely for that test that page_size argument add been added.

I see that other architectures except RISCV don't dump the physical address. But even RISCV doesn't 
include that check.

That physical address dump was added by commit aaa229529244 ("powerpc/mm: Add physical address to 
Linux page table dump") [https://github.com/torvalds/linux/commit/aaa2295]

How do other architectures deal with the problem described by the commit log of that patch ?

Christophe


From mathieu.poirier at linaro.org  Fri Apr 16 16:07:09 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 09:07:09 -0600
Subject: [PATCH v2 0/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210416105632.8771-1-james.clark@arm.com>
References: <20210416105632.8771-1-james.clark@arm.com>
Message-ID: <20210416150709.GA1046932@xps15>

Hi James,

On Fri, Apr 16, 2021 at 01:56:30PM +0300, James Clark wrote:
> Changes since v1:
>  * Improved variable name from etm_timestamp -> cs_timestamp
>  * Fixed ordering of Signed-off-by
> 

You forgot to add the RB and AB you received.  Since Arnaldo is responsible for
the perf tools subsystem, please send another revision.

Thanks,
Mathieu

> James Clark (2):
>   perf cs-etm: Refactor timestamp variable names
>   perf cs-etm: Set time on synthesised samples to preserve ordering
> 
>  .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++----
>  tools/perf/util/cs-etm.c                      | 52 ++++++++++---------
>  tools/perf/util/cs-etm.h                      |  4 +-
>  3 files changed, 39 insertions(+), 35 deletions(-)
> 
> -- 
> 2.28.0
> 


From broonie at kernel.org  Fri Apr 16 16:12:35 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 16:12:35 +0100
Subject: [PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable
 imbalance issue
In-Reply-To: <03f4152a-e66e-6b4a-5b4a-5f79f9ce2302@windriver.com>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
 <20210416004652.2975446-2-quanyang.wang@windriver.com>
 <20210416125558.GA5560@sirena.org.uk>
 <03f4152a-e66e-6b4a-5b4a-5f79f9ce2302@windriver.com>
Message-ID: <20210416151235.GC5560@sirena.org.uk>

On Fri, Apr 16, 2021 at 10:04:30PM +0800, quanyang.wang wrote:

> I am sorry. These patches should NOT be with "Fixes" tag since they base on
> the patches

> which are not with "Fixes". May I send a V2 patch series which remove these
> "Fixes" tags?

Well, if they're fixing bugs that were present in the named commit then
the the tag makes sense, it's just a question of if they are actually
for that commit or if they are fixing things for other commits like the
runtime PM enablement.
-------------- 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/20210416/357ce920/attachment.sig>

From l.stach at pengutronix.de  Fri Apr 16 16:14:18 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 16 Apr 2021 17:14:18 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
 <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
Message-ID: <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>

Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
> Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
> > Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> > > In order to be able to share the control hardware block between
> > > VPUs use a syscon instead a ioremap it in the driver.
> > > To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
> > > phandle is not found look at 'ctrl' reg-name.
> > > With the method it becomes useless to provide a list of register
> > > names so remove it.
> > Sorry for putting a spoke in the wheel after many iterations of the
> > series.
> > 
> > We just discussed a way forward on how to handle the clocks and resets
> > provided by the blkctl block on i.MX8MM and later and it seems there is
> > a consensus on trying to provide virtual power domains from a blkctl
> > driver, controlling clocks and resets for the devices in the power
> > domain. I would like to avoid introducing yet another way of handling
> > the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
> > what we are planning to do on the later chip generations.
> > 
> > CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
> > virtual power domain thing a shot.
> 
> That could replace the 3 first patches and Dt patche of this series
> but that will not impact the hevc part, so I wonder if pure hevc patches
> could be merged anyway ?
> They are reviewed and don't depend of how the ctrl block is managed.

I'm not really in a position to give any informed opinion about that
hvec patches, as I only skimmed them, but I don't see any reason to
delay patches 04-11 from this series until the i.MX8M platform issues
are sorted. AFAICS those things are totally orthogonal.

Regards,
Lucas

> > 
> > Regards,
> > Lucas
> > 
> > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> > > Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> > > ---
> > > version 9:
> > > ??- Corrections in commit message
> > > 
> > > version 7:
> > > ??- Add Philipp reviewed-by tag.
> > > ??- Change syscon phandle name.
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > version 5:
> > > ??- use syscon instead of VPU reset driver.
> > > ??- if DT doesn't provide syscon keep backward compatibilty by using
> > > ????'ctrl' reg-name.
> > > 
> > > ??drivers/staging/media/hantro/hantro.h       |  5 +-
> > > ??drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
> > > ??2 files changed, 34 insertions(+), 23 deletions(-)
> > > 
> > > diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
> > > index 6c1b888abe75..37b9ce04bd4e 100644
> > > --- a/drivers/staging/media/hantro/hantro.h
> > > +++ b/drivers/staging/media/hantro/hantro.h
> > > @@ -13,6 +13,7 @@
> > > ??#define HANTRO_H_
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??#include <linux/platform_device.h>
> > > +#include <linux/regmap.h>
> > > ??#include <linux/videodev2.h>
> > > ??#include <linux/wait.h>
> > > ??#include <linux/clk.h>
> > > @@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
> > > ???* @reg_bases:		Mapped addresses of VPU registers.
> > > ???* @enc_base:		Mapped address of VPU encoder register for convenience.
> > > ???* @dec_base:		Mapped address of VPU decoder register for convenience.
> > > - * @ctrl_base:		Mapped address of VPU control block.
> > > + * @ctrl_base:		Regmap of VPU control block.
> > > ???* @vpu_mutex:		Mutex to synchronize V4L2 calls.
> > > ???* @irqlock:		Spinlock to synchronize access to data structures
> > > ???*			shared with interrupt handlers.
> > > @@ -186,7 +187,7 @@ struct hantro_dev {
> > > ??	void __iomem **reg_bases;
> > > ??	void __iomem *enc_base;
> > > ??	void __iomem *dec_base;
> > > -	void __iomem *ctrl_base;
> > > +	struct regmap *ctrl_base;
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	struct mutex vpu_mutex;	/* video_device lock */
> > > ??	spinlock_t irqlock;
> > > diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
> > > index c222de075ef4..8d0c3425234b 100644
> > > --- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
> > > +++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
> > > @@ -7,6 +7,7 @@
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??#include <linux/clk.h>
> > > ??#include <linux/delay.h>
> > > +#include <linux/mfd/syscon.h>
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??#include "hantro.h"
> > > ??#include "hantro_jpeg.h"
> > > @@ -24,30 +25,28 @@
> > > ??#define CTRL_G1_PP_FUSE		0x0c
> > > ??#define CTRL_G2_DEC_FUSE	0x10
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > +static const struct regmap_config ctrl_regmap_ctrl = {
> > > +	.reg_bits = 32,
> > > +	.val_bits = 32,
> > > +	.reg_stride = 0x14,
> > > +};
> > > +
> > > ??static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
> > > ??{
> > > -	u32 val;
> > > -
> > > ??	/* Assert */
> > > -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
> > > -	val &= ~reset_bits;
> > > -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
> > > +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	udelay(2);
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	/* Release */
> > > -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
> > > -	val |= reset_bits;
> > > -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
> > > +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
> > > +			   reset_bits, reset_bits);
> > > ??}
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
> > > ??{
> > > -	u32 val;
> > > -
> > > -	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
> > > -	val |= clock_bits;
> > > -	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
> > > +	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
> > > +			   clock_bits, clock_bits);
> > > ??}
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??static int imx8mq_runtime_resume(struct hantro_dev *vpu)
> > > @@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
> > > ??	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	/* Set values of the fuse registers */
> > > -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
> > > -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
> > > -	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
> > > +	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
> > > +	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
> > > +	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > @@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
> > > ??{
> > > -	vpu->dec_base = vpu->reg_bases[0];
> > > -	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
> > > +	struct device_node *np = vpu->dev->of_node;
> > > +
> > > +	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
> > > +	if (IS_ERR(vpu->ctrl_base)) {
> > > +		struct resource *res;
> > > +		void __iomem *ctrl;
> > > +
> > > +		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
> > > +		ctrl = devm_ioremap_resource(vpu->dev, res);
> > > +		if (IS_ERR(ctrl))
> > > +			return PTR_ERR(ctrl);
> > > +
> > > +		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
> > > +		if (IS_ERR(vpu->ctrl_base))
> > > +			return PTR_ERR(vpu->ctrl_base);
> > > +	}
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??	return 0;
> > > ??}
> > > @@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
> > > ??};
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
> > > -static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
> > > ??
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ??const struct hantro_variant imx8mq_vpu_variant = {
> > > ??	.dec_fmts = imx8m_vpu_dec_fmts,
> > > @@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
> > > ??	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
> > > ??	.clk_names = imx8mq_clk_names,
> > > ??	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
> > > -	.reg_names = imx8mq_reg_names,
> > > -	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
> > > ??};
> > 
> > 
> 




From naresh.kamboju at linaro.org  Fri Apr 16 16:15:04 2021
From: naresh.kamboju at linaro.org (Naresh Kamboju)
Date: Fri, 16 Apr 2021 20:45:04 +0530
Subject: [next] aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
Message-ID: <CA+G9fYtVGhCJbnY8Hro2qx-i21cOeEBD6t_yz7B=O6Y7gD5bkQ@mail.gmail.com>

The arm64 allnoconfig build failed on linux -next tag 20210416

kernel/sched/fair.c:8428:13: warning: 'update_nohz_stats' defined but
not used [-Wunused-function]
 static bool update_nohz_stats(struct rq *rq)
             ^~~~~~~~~~~~~~~~~
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function
`task_fpsimd_load':
fpsimd.c:(.text+0x144): undefined reference to `sve_load_state'
aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `fpsimd_save':
fpsimd.c:(.text+0x1f8): undefined reference to `sve_get_vl'
aarch64-linux-gnu-ld: fpsimd.c:(.text+0x230): undefined reference to
`sve_save_state'
make[1]: *** [/builds/linux/Makefile:1277: vmlinux] Error 1
make[1]: Target '__all' not remade because of errors.
make: *** [Makefile:222: __sub-make] Error 2
make: Target '__all' not remade because of errors.

Reported-by: Naresh Kamboju <naresh.kamboju at linaro.org>

steps to reproduce:
--------------------
# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of
# architectures, toolchains, kernel configurations, and make targets.
#
# TuxMake supports the concept of runtimes.
# See https://docs.tuxmake.org/runtimes/, for that to work it requires
# that you install podman or docker on your system.
#
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.


tuxmake --runtime podman --target-arch arm64 --toolchain gcc-8
--kconfig allnoconfig

metadata:
---------
    git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
    git_describe: next-20210415
    kconfig: allnoconfig
    target_arch: arm64
    toolchain: gcc-8


--
Linaro LKFT
https://lkft.linaro.org


From christophe.leroy at csgroup.eu  Fri Apr 16 16:15:23 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Fri, 16 Apr 2021 17:15:23 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <b245cf06-f2e5-87a5-9a5e-64efc39d415a@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
 <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>
 <b6b5300d-35a0-3bc0-ad1d-f2af433ef27e@csgroup.eu>
 <b245cf06-f2e5-87a5-9a5e-64efc39d415a@csgroup.eu>
Message-ID: <10adad00-14de-61b6-ce2a-bdde23a34bcf@csgroup.eu>



Le 16/04/2021 ? 17:04, Christophe Leroy a ?crit?:
> 
> 
> Le 16/04/2021 ? 16:40, Christophe Leroy a ?crit?:
>>
>>
>> Le 16/04/2021 ? 15:00, Steven Price a ?crit?:
>>> On 16/04/2021 12:08, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>>>>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>>>>
>>>>>>
>>>>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>>>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be 
>>>>>>> using it purely to find "holes" in the calls to note_page(), but I haven't worked out why 
>>>>>>> such holes would occur.
>>>>>>
>>>>>> I was indeed introduced for KASAN. We have a first commit 
>>>>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is 
>>>>>> a KASAN like stuff.
>>>>>>
>>>>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what 
>>>>>> the problem was exactly, something around the use of hugepages for kernel memory, came as part 
>>>>>> of the series 
>>>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ah, that's useful context. So it looks like powerpc took a different route to reducing the 
>>>>> KASAN output to x86.
>>>>>
>>>>> Given the generic ptdump code has handling for KASAN already it should be possible to drop that 
>>>>> from the powerpc arch code, which I think means we don't actually need to provide page size to 
>>>>> notepage(). Hopefully that means more code to delete ;)
>>>>>
>>>>
>>>> Yes ... and no.
>>>>
>>>> It looks like the generic ptdump handles the case when several pgdir entries points to the same 
>>>> kasan_early_shadow_pte. But it doesn't take into account the powerpc case where we have regular 
>>>> page tables where several (if not all) PTEs are pointing to the kasan_early_shadow_page .
>>>
>>> I'm not sure I follow quite how powerpc is different here. But could you have a similar check for 
>>> PTEs against kasan_early_shadow_pte as the other levels already have?
>>>
>>> I'm just worried that page_size isn't well defined in this interface and it's going to cause 
>>> problems in the future.
>>>
>>
>> I'm trying. I reverted the two commits b00ff6d8c and cabe8138.
>>
>> At the moment, I don't get exactly what I expect: For linear memory I get one line for each 8M 
>> page whereas before reverting the patches I got one 16M line and one 112M line.
>>
>> And for KASAN shadow area I get two lines for the 2x 8M pages shadowing linear mem then I get one 
>> 4M line for each PGDIR entry pointing to kasan_early_shadow_pte.
>>
>> 0xf8000000-0xf87fffff 0x07000000???????? 8M?? huge??????? rw?????? present
>> 0xf8800000-0xf8ffffff 0x07800000???????? 8M?? huge??????? rw?????? present
>> 0xf9000000-0xf93fffff 0x01430000???????? 4M?????????????? r??????? present
> ...
>> 0xfec00000-0xfeffffff 0x01430000???????? 4M?????????????? r??????? present
>>
>> Any idea ?
>>
> 
> 
> I think the different with other architectures is here:
> 
>  ????} else if (flag != st->current_flags || level != st->level ||
>  ?????????? addr >= st->marker[1].start_address ||
>  ?????????? pa != st->last_pa + PAGE_SIZE) {
> 
> 
> In addition to the checks everyone do, powerpc also checks "pa != st->last_pa + PAGE_SIZE".
> And it is definitely for that test that page_size argument add been added.

By replacing that test by (pa - st->start_pa != addr - st->start_address) it works again. So we 
definitely don't need the real page size.


> 
> I see that other architectures except RISCV don't dump the physical address. But even RISCV doesn't 
> include that check.
> 
> That physical address dump was added by commit aaa229529244 ("powerpc/mm: Add physical address to 
> Linux page table dump") [https://github.com/torvalds/linux/commit/aaa2295]
> 
> How do other architectures deal with the problem described by the commit log of that patch ?
> 
> Christophe


From joro at 8bytes.org  Fri Apr 16 16:16:46 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Fri, 16 Apr 2021 17:16:46 +0200
Subject: [PATCH] iommu/mediatek: always enable the clk on resume
In-Reply-To: <3c1f184f-e666-5198-e89e-c3774917c6d4@collabora.com>
References: <20210408122842.29009-1-dafna.hirschfeld@collabora.com>
 <YHhA4u7zat3vtJfD@8bytes.org>
 <3c1f184f-e666-5198-e89e-c3774917c6d4@collabora.com>
Message-ID: <YHmqXi8JHK5CoNNS@8bytes.org>

On Fri, Apr 16, 2021 at 03:47:01PM +0200, Dafna Hirschfeld wrote:
> Hi,
> I sent v2, removing the word 'comment' from the 'Fixes' tag
> after a problem report from Stephen Rothwell,
> could you replace v1 with v2?

Replaced it, thanks.


From acme at kernel.org  Fri Apr 16 16:16:52 2021
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Fri, 16 Apr 2021 12:16:52 -0300
Subject: [PATCH v2 0/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <20210416150709.GA1046932@xps15>
References: <20210416105632.8771-1-james.clark@arm.com>
 <20210416150709.GA1046932@xps15>
Message-ID: <YHmqZKGMFydbsvEy@kernel.org>

Em Fri, Apr 16, 2021 at 09:07:09AM -0600, Mathieu Poirier escreveu:
> Hi James,
> 
> On Fri, Apr 16, 2021 at 01:56:30PM +0300, James Clark wrote:
> > Changes since v1:
> >  * Improved variable name from etm_timestamp -> cs_timestamp
> >  * Fixed ordering of Signed-off-by
> > 
> 
> You forgot to add the RB and AB you received.  Since Arnaldo is responsible for
> the perf tools subsystem, please send another revision.
 


Yep, please collect Reported-by and Acked-by as you go sending new
versions of a patchset, the last one I don't have a problem collecting
myself, but if you have to resend, please collect the feedback tags.

- Arnaldo

> Thanks,
> Mathieu
> 
> > James Clark (2):
> >   perf cs-etm: Refactor timestamp variable names
> >   perf cs-etm: Set time on synthesised samples to preserve ordering
> > 
> >  .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++----
> >  tools/perf/util/cs-etm.c                      | 52 ++++++++++---------
> >  tools/perf/util/cs-etm.h                      |  4 +-
> >  3 files changed, 39 insertions(+), 35 deletions(-)
> > 
> > -- 
> > 2.28.0
> > 

-- 

- Arnaldo


From alexandre.torgue at foss.st.com  Fri Apr 16 16:23:05 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Fri, 16 Apr 2021 17:23:05 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <e27dbccd-518f-7718-8cf7-cc9c8adb8a56@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
 <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
 <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>
 <e27dbccd-518f-7718-8cf7-cc9c8adb8a56@denx.de>
Message-ID: <6416577a-ea06-a014-543a-9ef86aae603d@foss.st.com>



On 4/16/21 3:47 PM, Marek Vasut wrote:
> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>> Hi Marek
> 
> Hello Gabriel,
> 
>> On 4/14/21 4:04 PM, Marek Vasut wrote:
>>> On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
>>>> Hi Marek,
>>>
>>> Hello Gabriel,
>>>
>>>> Thanks for the patchset
>>>>
>>>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>>>> The ETHCK_K are modeled as composite clock of MUX and GATE, however 
>>>>> per
>>>>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. 
>>>>> Peripheral
>>>>> clock distribution for Ethernet, ETHPTPDIV divider is attached past 
>>>>> the
>>>>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN 
>>>>> gate.
>>>>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock are
>>>>> in use, ETHCKEN gate can be turned off. Current driver does not permit
>>>>> that, fix it.
>>>>
>>>> I don"t understand, it's already the case.
>>>>
>>>> ETHCK_K it's a composite with a MUX and a GATE.
>>>
>>> But ETHCK_K is _not_ a composite clock, look at the Figure 83 in the 
>>> datasheet again and schematic below.
>>>
>>>> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV 
>>>> (no gate)
>>>
>>> But ETHPTP_K shouldn't control any mux, it is only a divider.
>>>
>>>> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.
>>>
>>> Look, this is what you have today:
>>>
>>> ??????????? .------------ ETHCK_K -----------.
>>> ??????????? |_______?????????????? _______?? |
>>> pll4_p_ck--|M_ETHCK\???????????? |G_ETHCK\? |
>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>> ??????????? |?????????????? |
>>> ??????????? |?????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>>> ??????????? |????????????????????????????????????????? |
>>> ??????????? '------------ ETHPTP_K --------------------'
>>>
>>> And this is what you should have, to avoid having two composite clock 
>>> which control the same mux using the same register bit, i.e. what 
>>> this patch implements:
>>>
>>> ??????????? .- ck_ker_eth -.? .--- ETHCK_K --.
>>> ??????????? |_______?????? |? |??? _______?? |
>>> pll4_p_ck--|M_ETHCK\????? |? |?? |G_ETHCK\? |
>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>> ??????????????????????????? |
>>> ??????????????????????????? '--(ETHCKSELR[7:4] divider)--[x] clk_ptp_ref
>>> ???????????????????????????? |???????????????????????? |
>>> ???????????????????????????? '---- ETHPTP_K -----------'
>>>
>>
>> These 2 solutions are valid. I made the choice to implement the first 
>> one to be able to change parent with the kernel clock of the IP (no 
>> need to add an intermediate binding).
> 
> Which IP are you talking about in here ?
> 
>> It's the same principle for all kernel of this soc.
> 
> The first option is wrong, because in that model, you have two composite 
> clock which control the same one mux bit in the same register. Basically 
> you register two distinct clock which operate the same hardware knob.
> 
>> I can ask to Alexandre to comeback of this principle, but i 'm not 
>> favorable.
> 

The only discussing thing is how the clock is shown. I mean either two 
composites or one mux plus two gates. Gabriel made a choice to abstract 
the mux in two composite clocks. But it seems that at the end we have 
the same behaviour, isn't ?

Adding "ck_ker_eth" would impose a new clock to take in DT ?

regards
alex

> Please ask.
> 
>>>>> This patch converts ETHCK_K from composite clock into a ETHCKEN gate,
>>>>> ETHPTP_K from composite clock into ETHPTPDIV divider, and adds another
>>>>> NO_ID clock "ck_ker_eth" which models the ETHSRC mux and is parent 
>>>>> clock
>>>>> to both ETHCK_K and ETHPTP_K. Therefore, all references to ETHCK_K and
>>>>> ETHPTP_K remain functional as before.
>>>>>
>>>>> [1] STM32MP1 Reference Manual RM0436 Rev 3, Page 574,
>>>>> ???? Figure 83. Peripheral clock distribution for Ethernet
>>>>> https://www.st.com/resource/en/reference_manual/dm00327659-stm32mp157-advanced-armbased-32bit-mpus-stmicroelectronics.pdf 
>>>>>
>>>
>>> [...]
>>>
>>>>> diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
>>>>> index a875649df8b8..a7c7f544ee5d 100644
>>>>> --- a/drivers/clk/clk-stm32mp1.c
>>>>> +++ b/drivers/clk/clk-stm32mp1.c
>>>>> @@ -1949,7 +1949,6 @@ static const struct clock_config 
>>>>> stm32mp1_clock_cfg[] = {
>>>>> ????? KCLK(DSI_K, "dsi_k", dsi_src, 0, G_DSI, M_DSI),
>>>>> ????? KCLK(ADFSDM_K, "adfsdm_k", sai_src, 0, G_ADFSDM, M_SAI1),
>>>>> ????? KCLK(USBO_K, "usbo_k", usbo_src, 0, G_USBO, M_USBO),
>>>>> -??? KCLK(ETHCK_K, "ethck_k", eth_src, 0, G_ETHCK, M_ETHCK),
>>>>> ????? /* Particulary Kernel Clocks (no mux or no gate) */
>>>>> ????? MGATE_MP1(DFSDM_K, "dfsdm_k", "ck_mcu", 0, G_DFSDM),
>>>>> @@ -1958,11 +1957,16 @@ static const struct clock_config 
>>>>> stm32mp1_clock_cfg[] = {
>>>>> ????? MGATE_MP1(GPU_K, "gpu_k", "pll2_q", 0, G_GPU),
>>>>> ????? MGATE_MP1(DAC12_K, "dac12_k", "ck_lsi", 0, G_DAC12),
>>>>> -??? COMPOSITE(ETHPTP_K, "ethptp_k", eth_src, CLK_OPS_PARENT_ENABLE |
>>>>> +??? COMPOSITE(NO_ID, "ck_ker_eth", eth_src, CLK_OPS_PARENT_ENABLE |
>>>>> ??????????? CLK_SET_RATE_NO_REPARENT,
>>>>> ??????????? _NO_GATE,
>>>>> ??????????? _MMUX(M_ETHCK),
>>>>> -????????? _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
>>>>> +????????? _NO_DIV),
>>>>> +
>>>>> +??? MGATE_MP1(ETHCK_K, "ethck_k", "ck_ker_eth", 0, G_ETHCK),
>>>> assigned parent with ETHCK_K will not work
>>>>> +
>>>>> +??? DIV(ETHPTP_K, "ethptp_k", "ck_ker_eth", CLK_OPS_PARENT_ENABLE |
>>>>
>>>> CLK_OPS_PARENT_ENABLE flags not useful with a divider.
>>>
>>> How so ?


From joro at 8bytes.org  Fri Apr 16 16:24:50 2021
From: joro at 8bytes.org (Joerg Roedel)
Date: Fri, 16 Apr 2021 17:24:50 +0200
Subject: [PATCH 0/8] iommu: fix a couple of spelling mistakes detected by
 codespell tool
In-Reply-To: <20210326062412.1262-1-thunder.leizhen@huawei.com>
References: <20210326062412.1262-1-thunder.leizhen@huawei.com>
Message-ID: <YHmsQtm4o5f7fAru@8bytes.org>

On Fri, Mar 26, 2021 at 02:24:04PM +0800, Zhen Lei wrote:
> This detection and correction covers the entire driver/iommu directory.
> 
> Zhen Lei (8):
>   iommu/pamu: fix a couple of spelling mistakes
>   iommu/omap: Fix spelling mistake "alignement" -> "alignment"
>   iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical"
>   iommu/sun50i: Fix spelling mistake "consits" -> "consists"
>   iommu: fix a couple of spelling mistakes
>   iommu/amd: fix a couple of spelling mistakes
>   iommu/arm-smmu: Fix spelling mistake "initally" -> "initially"
>   iommu/vt-d: fix a couple of spelling mistakes

This patch-set doesn't apply. Please re-send it as a single patch when
v5.13-rc1 is released.

Thanks,

	Joerg


From willy at infradead.org  Fri Apr 16 16:27:55 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 16 Apr 2021 16:27:55 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210415200832.32796445@carbon>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
Message-ID: <20210416152755.GL2531743@casper.infradead.org>

On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> See below patch.  Where I swap32 the dma address to satisfy
> page->compound having bit zero cleared. (It is the simplest fix I could
> come up with).

I think this is slightly simpler, and as a bonus code that assumes the
old layout won't compile.

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..5aacc1c10a45 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -97,10 +97,10 @@ struct page {
 		};
 		struct {	/* page_pool used by netstack */
 			/**
-			 * @dma_addr: might require a 64-bit value even on
+			 * @dma_addr: might require a 64-bit value on
 			 * 32-bit architectures.
 			 */
-			dma_addr_t dma_addr;
+			unsigned long dma_addr[2];
 		};
 		struct {	/* slab, slob and slub */
 			union {
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b5b195305346..db7c7020746a 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
 
 static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
 {
-	return page->dma_addr;
+	dma_addr_t ret = page->dma_addr[0];
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		ret |= (dma_addr_t)page->dma_addr[1] << 32;
+	return ret;
+}
+
+static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
+{
+	page->dma_addr[0] = addr;
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		page->dma_addr[1] = addr >> 32;
 }
 
 static inline bool is_page_pool_compiled_in(void)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index ad8b0707af04..f014fd8c19a6 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
 					  struct page *page,
 					  unsigned int dma_sync_size)
 {
+	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
+
 	dma_sync_size = min(dma_sync_size, pool->p.max_len);
-	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
+	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
 					 pool->p.offset, dma_sync_size,
 					 pool->p.dma_dir);
 }
@@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
 		put_page(page);
 		return NULL;
 	}
-	page->dma_addr = dma;
+	page_pool_set_dma_addr(page, dma);
 
 	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
 		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
@@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
 		 */
 		goto skip_dma_unmap;
 
-	dma = page->dma_addr;
+	dma = page_pool_get_dma_addr(page);
 
-	/* When page is unmapped, it cannot be returned our pool */
+	/* When page is unmapped, it cannot be returned to our pool */
 	dma_unmap_page_attrs(pool->p.dev, dma,
 			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
 			     DMA_ATTR_SKIP_CPU_SYNC);
-	page->dma_addr = 0;
+	page_pool_set_dma_addr(page, 0);
 skip_dma_unmap:
 	/* This may be the last page returned, releasing the pool, so
 	 * it is not safe to reference pool afterwards.


From marex at denx.de  Fri Apr 16 16:31:40 2021
From: marex at denx.de (Marek Vasut)
Date: Fri, 16 Apr 2021 17:31:40 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <6416577a-ea06-a014-543a-9ef86aae603d@foss.st.com>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
 <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
 <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>
 <e27dbccd-518f-7718-8cf7-cc9c8adb8a56@denx.de>
 <6416577a-ea06-a014-543a-9ef86aae603d@foss.st.com>
Message-ID: <2281af74-33a0-df45-968b-baa1ddd9d6e0@denx.de>

On 4/16/21 5:23 PM, Alexandre TORGUE wrote:

Hello Alexandre,

> On 4/16/21 3:47 PM, Marek Vasut wrote:
>> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>>> Hi Marek
>>
>> Hello Gabriel,
>>
>>> On 4/14/21 4:04 PM, Marek Vasut wrote:
>>>> On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
>>>>> Hi Marek,
>>>>
>>>> Hello Gabriel,
>>>>
>>>>> Thanks for the patchset
>>>>>
>>>>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>>>>> The ETHCK_K are modeled as composite clock of MUX and GATE, 
>>>>>> however per
>>>>>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. 
>>>>>> Peripheral
>>>>>> clock distribution for Ethernet, ETHPTPDIV divider is attached 
>>>>>> past the
>>>>>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN 
>>>>>> gate.
>>>>>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP clock 
>>>>>> are
>>>>>> in use, ETHCKEN gate can be turned off. Current driver does not 
>>>>>> permit
>>>>>> that, fix it.
>>>>>
>>>>> I don"t understand, it's already the case.
>>>>>
>>>>> ETHCK_K it's a composite with a MUX and a GATE.
>>>>
>>>> But ETHCK_K is _not_ a composite clock, look at the Figure 83 in the 
>>>> datasheet again and schematic below.
>>>>
>>>>> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV 
>>>>> (no gate)
>>>>
>>>> But ETHPTP_K shouldn't control any mux, it is only a divider.
>>>>
>>>>> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.
>>>>
>>>> Look, this is what you have today:
>>>>
>>>> ??????????? .------------ ETHCK_K -----------.
>>>> ??????????? |_______?????????????? _______?? |
>>>> pll4_p_ck--|M_ETHCK\???????????? |G_ETHCK\? |
>>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>>> ??????????? |?????????????? |
>>>> ??????????? |?????????????? '--(ETHCKSELR[7:4] divider)--[x] 
>>>> clk_ptp_ref
>>>> ??????????? |????????????????????????????????????????? |
>>>> ??????????? '------------ ETHPTP_K --------------------'
>>>>
>>>> And this is what you should have, to avoid having two composite 
>>>> clock which control the same mux using the same register bit, i.e. 
>>>> what this patch implements:
>>>>
>>>> ??????????? .- ck_ker_eth -.? .--- ETHCK_K --.
>>>> ??????????? |_______?????? |? |??? _______?? |
>>>> pll4_p_ck--|M_ETHCK\????? |? |?? |G_ETHCK\? |
>>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>>> ??????????????????????????? |
>>>> ??????????????????????????? '--(ETHCKSELR[7:4] divider)--[x] 
>>>> clk_ptp_ref
>>>> ???????????????????????????? |???????????????????????? |
>>>> ???????????????????????????? '---- ETHPTP_K -----------'
>>>>
>>>
>>> These 2 solutions are valid. I made the choice to implement the first 
>>> one to be able to change parent with the kernel clock of the IP (no 
>>> need to add an intermediate binding).
>>
>> Which IP are you talking about in here ?
>>
>>> It's the same principle for all kernel of this soc.
>>
>> The first option is wrong, because in that model, you have two 
>> composite clock which control the same one mux bit in the same 
>> register. Basically you register two distinct clock which operate the 
>> same hardware knob.
>>
>>> I can ask to Alexandre to comeback of this principle, but i 'm not 
>>> favorable.
>>
> 
> The only discussing thing is how the clock is shown. I mean either two 
> composites or one mux plus two gates. Gabriel made a choice to abstract 
> the mux in two composite clocks. But it seems that at the end we have 
> the same behaviour, isn't ?

Not really. Since the two composite clock control the same mux bit, 
consider what would happen if you were to select pll4_p_ck as parent for 
one (e.g. ETHCK_K), and pll3_q_ck as parent for the other (e.g. 
ETHPTP_K), what would be the result ? I guess the result would depend on 
when the reparenting of each ETHCK_K/ETHPTP_K happens on boot, and I 
don't think that's how it should work. With a single mux controlling 
that one single bit, such situation wouldn't happen.

> Adding "ck_ker_eth" would impose a new clock to take in DT ?
Nope, the ck_ker_eth is without ID and internal to the driver. They 
exist only to describe the clock tree correctly.

[...]


From broonie at kernel.org  Fri Apr 16 16:36:08 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 16:36:08 +0100
Subject: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks
In-Reply-To: <e8367fe9-6fd0-f962-422d-daa4548cc3b7@linux.microsoft.com>
References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd>
 <20210405204313.21346-1-madvenka@linux.microsoft.com>
 <20210409120859.GA51636@C02TD0UTHF1T.local>
 <20210409213741.kqmwyajoppuqrkge@treble>
 <20210412173617.GE5379@sirena.org.uk>
 <d92ec07e-81e1-efb8-b417-d1d8a211ef7f@linux.microsoft.com>
 <20210413110255.GB5586@sirena.org.uk>
 <714e748c-bb79-aa9a-abb5-cf5e677e847b@linux.microsoft.com>
 <e8367fe9-6fd0-f962-422d-daa4548cc3b7@linux.microsoft.com>
Message-ID: <20210416153608.GD5560@sirena.org.uk>

On Fri, Apr 16, 2021 at 09:43:48AM -0500, Madhavan T. Venkataraman wrote:

> How would you prefer I handle this? Should I place all SYM_CODE functions that
> are actually safe for the unwinder in a separate section? I could just take
> some approach and solve this. But I would like to get your opinion and Mark
> Rutland's opinion so we are all on the same page.

That sounds reasonable to me, obviously we'd have to look at how
exactly the annotation ends up getting done and general bikeshed colour
discussions.  I'm not sure if we want a specific "safe for unwinder
section" or to split things up into sections per reason things are safe
for the unwinder (kind of like what you were proposing for flagging
things as a problem), that might end up being useful for other things at
some point.
-------------- 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/20210416/dc1c82e1/attachment.sig>

From quanyang.wang at windriver.com  Fri Apr 16 16:37:27 2021
From: quanyang.wang at windriver.com (Quanyang Wang)
Date: Fri, 16 Apr 2021 23:37:27 +0800
Subject: [PATCH 1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable
 imbalance issue
In-Reply-To: <20210416151235.GC5560@sirena.org.uk>
References: <20210416004652.2975446-1-quanyang.wang@windriver.com>
 <20210416004652.2975446-2-quanyang.wang@windriver.com>
 <20210416125558.GA5560@sirena.org.uk>
 <03f4152a-e66e-6b4a-5b4a-5f79f9ce2302@windriver.com>
 <20210416151235.GC5560@sirena.org.uk>
Message-ID: <1c7f42ed-cd2f-4fff-61c9-4460720dfd84@windriver.com>

Hi Mark,

On 4/16/21 11:12 PM, Mark Brown wrote:
> On Fri, Apr 16, 2021 at 10:04:30PM +0800, quanyang.wang wrote:
>
>> I am sorry. These patches should NOT be with "Fixes" tag since they base on
>> the patches
>> which are not with "Fixes". May I send a V2 patch series which remove these
>> "Fixes" tags?
> Well, if they're fixing bugs that were present in the named commit then
> the the tag makes sense, it's just a question of if they are actually
> for that commit or if they are fixing things for other commits like the
> runtime PM enablement.

Yes,? they are fixing bugs which are introduced by the named commit.

But if only picking they to stable without the patch "spi: 
spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe",

this spi driver will not work. I don't know how to handle this 
condition, so I send a V2 patch series to delete the tags.

Thanks,

Quanyang



From broonie at kernel.org  Fri Apr 16 16:40:01 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 16:40:01 +0100
Subject: [next] aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
In-Reply-To: <CA+G9fYtVGhCJbnY8Hro2qx-i21cOeEBD6t_yz7B=O6Y7gD5bkQ@mail.gmail.com>
References: <CA+G9fYtVGhCJbnY8Hro2qx-i21cOeEBD6t_yz7B=O6Y7gD5bkQ@mail.gmail.com>
Message-ID: <20210416154001.GE5560@sirena.org.uk>

On Fri, Apr 16, 2021 at 08:45:04PM +0530, Naresh Kamboju wrote:

> The arm64 allnoconfig build failed on linux -next tag 20210416

> fpsimd.c:(.text+0x144): undefined reference to `sve_load_state'
> aarch64-linux-gnu-ld: arch/arm64/kernel/fpsimd.o: in function `fpsimd_save':
> fpsimd.c:(.text+0x1f8): undefined reference to `sve_get_vl'
> aarch64-linux-gnu-ld: fpsimd.c:(.text+0x230): undefined reference to
> `sve_save_state'

This was already reported and fixed yesterday.
-------------- 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/20210416/c20e434e/attachment.sig>

From steven.price at arm.com  Fri Apr 16 16:43:03 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:03 +0100
Subject: [PATCH v11 0/6] MTE support for KVM guest
Message-ID: <20210416154309.22129-1-steven.price@arm.com>

I know it's likely to be the merge window next week, but since there
were a couple of changes from Catalin's review I thought I'd send
another version out - there are some minor conflicts with what's
currently in -next so I'll rebase after -rc1.

This series adds support for using the Arm Memory Tagging Extensions
(MTE) in a KVM guest.

This version is rebased on v5.12-rc2.

Changes since v10[1]:

 * Replace pte_valid_user() with (pte_val(pte) & PTE_USER) in
   set_pte_at() as the former has been removed with the EPAN patches.
 * Don't attempt to check tags on memory which is going to be mapped in
   stage 2 as DEVICE as the guest won't be able to see the tags.
 * Use pfn_to_online_page() instead of pfn_to_page() in user_mem_abort()
   to prevent ZONE_DEVICE memory being populated in stage 2 if tags are
   enabled.

[1] https://lore.kernel.org/r/20210312151902.17853-1-steven.price%40arm.com

Steven Price (6):
  arm64: mte: Sync tags for pages where PTE is untagged
  arm64: kvm: Introduce MTE VM feature
  arm64: kvm: Save/restore MTE registers
  arm64: kvm: Expose KVM_ARM_CAP_MTE
  KVM: arm64: ioctl to fetch/store tags in a guest
  KVM: arm64: Document MTE capability and ioctl

 Documentation/virt/kvm/api.rst             | 53 +++++++++++++++
 arch/arm64/include/asm/kvm_emulate.h       |  3 +
 arch/arm64/include/asm/kvm_host.h          |  9 +++
 arch/arm64/include/asm/kvm_mte.h           | 66 ++++++++++++++++++
 arch/arm64/include/asm/pgtable.h           |  2 +-
 arch/arm64/include/asm/sysreg.h            |  3 +-
 arch/arm64/include/uapi/asm/kvm.h          | 14 ++++
 arch/arm64/kernel/asm-offsets.c            |  3 +
 arch/arm64/kernel/mte.c                    | 16 +++--
 arch/arm64/kvm/arm.c                       | 78 ++++++++++++++++++++++
 arch/arm64/kvm/hyp/entry.S                 |  7 ++
 arch/arm64/kvm/hyp/exception.c             |  3 +-
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 21 ++++++
 arch/arm64/kvm/mmu.c                       | 20 ++++++
 arch/arm64/kvm/sys_regs.c                  | 28 ++++++--
 include/uapi/linux/kvm.h                   |  2 +
 16 files changed, 317 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/include/asm/kvm_mte.h

-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:04 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:04 +0100
Subject: [PATCH v11 1/6] arm64: mte: Sync tags for pages where PTE is untagged
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-2-steven.price@arm.com>

A KVM guest could store tags in a page even if the VMM hasn't mapped
the page with PROT_MTE. So when restoring pages from swap we will
need to check to see if there are any saved tags even if !pte_tagged().

However don't check pages which are !pte_valid_user() as these will
not have been swapped out.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 arch/arm64/include/asm/pgtable.h |  2 +-
 arch/arm64/kernel/mte.c          | 16 ++++++++++++----
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e17b96d0e4b5..cf4b52a33b3c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
 		__sync_icache_dcache(pte);
 
 	if (system_supports_mte() &&
-	    pte_present(pte) && pte_tagged(pte) && !pte_special(pte))
+	    pte_present(pte) && (pte_val(pte) & PTE_USER) && !pte_special(pte))
 		mte_sync_tags(ptep, pte);
 
 	__check_racy_pte_update(mm, ptep, pte);
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index b3c70a612c7a..e016ab57ea36 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -26,17 +26,23 @@ u64 gcr_kernel_excl __ro_after_init;
 
 static bool report_fault_once = true;
 
-static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
+static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap,
+			       bool pte_is_tagged)
 {
 	pte_t old_pte = READ_ONCE(*ptep);
 
 	if (check_swap && is_swap_pte(old_pte)) {
 		swp_entry_t entry = pte_to_swp_entry(old_pte);
 
-		if (!non_swap_entry(entry) && mte_restore_tags(entry, page))
+		if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) {
+			set_bit(PG_mte_tagged, &page->flags);
 			return;
+		}
 	}
 
+	if (!pte_is_tagged || test_and_set_bit(PG_mte_tagged, &page->flags))
+		return;
+
 	page_kasan_tag_reset(page);
 	/*
 	 * We need smp_wmb() in between setting the flags and clearing the
@@ -54,11 +60,13 @@ void mte_sync_tags(pte_t *ptep, pte_t pte)
 	struct page *page = pte_page(pte);
 	long i, nr_pages = compound_nr(page);
 	bool check_swap = nr_pages == 1;
+	bool pte_is_tagged = pte_tagged(pte);
 
 	/* if PG_mte_tagged is set, tags have already been initialised */
 	for (i = 0; i < nr_pages; i++, page++) {
-		if (!test_and_set_bit(PG_mte_tagged, &page->flags))
-			mte_sync_page_tags(page, ptep, check_swap);
+		if (!test_bit(PG_mte_tagged, &page->flags))
+			mte_sync_page_tags(page, ptep, check_swap,
+					   pte_is_tagged);
 	}
 }
 
-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:07 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:07 +0100
Subject: [PATCH v11 4/6] arm64: kvm: Expose KVM_ARM_CAP_MTE
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-5-steven.price@arm.com>

It's now safe for the VMM to enable MTE in a guest, so expose the
capability to user space.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 arch/arm64/kvm/arm.c      | 9 +++++++++
 arch/arm64/kvm/sys_regs.c | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index fc4c95dd2d26..46bf319f6cb7 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -93,6 +93,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
 		r = 0;
 		kvm->arch.return_nisv_io_abort_to_user = true;
 		break;
+	case KVM_CAP_ARM_MTE:
+		if (!system_supports_mte() || kvm->created_vcpus)
+			return -EINVAL;
+		r = 0;
+		kvm->arch.mte_enabled = true;
+		break;
 	default:
 		r = -EINVAL;
 		break;
@@ -234,6 +240,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		 */
 		r = 1;
 		break;
+	case KVM_CAP_ARM_MTE:
+		r = system_supports_mte();
+		break;
 	case KVM_CAP_STEAL_TIME:
 		r = kvm_arm_pvtime_supported();
 		break;
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 377ae6efb0ef..46937bfaac8a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1306,6 +1306,9 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 static unsigned int mte_visibility(const struct kvm_vcpu *vcpu,
 				   const struct sys_reg_desc *rd)
 {
+	if (kvm_has_mte(vcpu->kvm))
+		return 0;
+
 	return REG_HIDDEN;
 }
 
-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:05 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:05 +0100
Subject: [PATCH v11 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-3-steven.price@arm.com>

Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
for a VM. This will expose the feature to the guest and automatically
tag memory pages touched by the VM as PG_mte_tagged (and clear the tag
storage) to ensure that the guest cannot see stale tags, and so that
the tags are correctly saved/restored across swap.

Actually exposing the new capability to user space happens in a later
patch.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 arch/arm64/include/asm/kvm_emulate.h |  3 +++
 arch/arm64/include/asm/kvm_host.h    |  3 +++
 arch/arm64/kvm/hyp/exception.c       |  3 ++-
 arch/arm64/kvm/mmu.c                 | 20 ++++++++++++++++++++
 arch/arm64/kvm/sys_regs.c            |  3 +++
 include/uapi/linux/kvm.h             |  1 +
 6 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index f612c090f2e4..6bf776c2399c 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -84,6 +84,9 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
 	if (cpus_have_const_cap(ARM64_MISMATCHED_CACHE_TYPE) ||
 	    vcpu_el1_is_32bit(vcpu))
 		vcpu->arch.hcr_el2 |= HCR_TID2;
+
+	if (kvm_has_mte(vcpu->kvm))
+		vcpu->arch.hcr_el2 |= HCR_ATA;
 }
 
 static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527f7d..1170ee137096 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -132,6 +132,8 @@ struct kvm_arch {
 
 	u8 pfr0_csv2;
 	u8 pfr0_csv3;
+	/* Memory Tagging Extension enabled for the guest */
+	bool mte_enabled;
 };
 
 struct kvm_vcpu_fault_info {
@@ -767,6 +769,7 @@ bool kvm_arm_vcpu_is_finalized(struct kvm_vcpu *vcpu);
 #define kvm_arm_vcpu_sve_finalized(vcpu) \
 	((vcpu)->arch.flags & KVM_ARM64_VCPU_SVE_FINALIZED)
 
+#define kvm_has_mte(kvm) (system_supports_mte() && (kvm)->arch.mte_enabled)
 #define kvm_vcpu_has_pmu(vcpu)					\
 	(test_bit(KVM_ARM_VCPU_PMU_V3, (vcpu)->arch.features))
 
diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c
index 73629094f903..56426565600c 100644
--- a/arch/arm64/kvm/hyp/exception.c
+++ b/arch/arm64/kvm/hyp/exception.c
@@ -112,7 +112,8 @@ static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode,
 	new |= (old & PSR_C_BIT);
 	new |= (old & PSR_V_BIT);
 
-	// TODO: TCO (if/when ARMv8.5-MemTag is exposed to guests)
+	if (kvm_has_mte(vcpu->kvm))
+		new |= PSR_TCO_BIT;
 
 	new |= (old & PSR_DIT_BIT);
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f2a4..5f8e165ea053 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -879,6 +879,26 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	if (vma_pagesize == PAGE_SIZE && !force_pte)
 		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
 							   &pfn, &fault_ipa);
+
+	if (fault_status != FSC_PERM && kvm_has_mte(kvm) && !device &&
+	    pfn_valid(pfn)) {
+		/*
+		 * VM will be able to see the page's tags, so we must ensure
+		 * they have been initialised. if PG_mte_tagged is set, tags
+		 * have already been initialised.
+		 */
+		unsigned long i, nr_pages = vma_pagesize >> PAGE_SHIFT;
+		struct page *page = pfn_to_online_page(pfn);
+
+		if (!page)
+			return -EFAULT;
+
+		for (i = 0; i < nr_pages; i++, page++) {
+			if (!test_and_set_bit(PG_mte_tagged, &page->flags))
+				mte_clear_page_tags(page_address(page));
+		}
+	}
+
 	if (writable)
 		prot |= KVM_PGTABLE_PROT_W;
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4f2f1e3145de..18c87500a7a8 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1047,6 +1047,9 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
 		break;
 	case SYS_ID_AA64PFR1_EL1:
 		val &= ~FEATURE(ID_AA64PFR1_MTE);
+		if (kvm_has_mte(vcpu->kvm))
+			val |= FIELD_PREP(FEATURE(ID_AA64PFR1_MTE),
+					  ID_AA64PFR1_MTE);
 		break;
 	case SYS_ID_AA64ISAR1_EL1:
 		if (!vcpu_has_ptrauth(vcpu))
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f6afee209620..6dc16c09a2d1 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1078,6 +1078,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_DIRTY_LOG_RING 192
 #define KVM_CAP_X86_BUS_LOCK_EXIT 193
 #define KVM_CAP_PPC_DAWR1 194
+#define KVM_CAP_ARM_MTE 195
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:06 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:06 +0100
Subject: [PATCH v11 3/6] arm64: kvm: Save/restore MTE registers
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-4-steven.price@arm.com>

Define the new system registers that MTE introduces and context switch
them. The MTE feature is still hidden from the ID register as it isn't
supported in a VM yet.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 arch/arm64/include/asm/kvm_host.h          |  6 ++
 arch/arm64/include/asm/kvm_mte.h           | 66 ++++++++++++++++++++++
 arch/arm64/include/asm/sysreg.h            |  3 +-
 arch/arm64/kernel/asm-offsets.c            |  3 +
 arch/arm64/kvm/hyp/entry.S                 |  7 +++
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 21 +++++++
 arch/arm64/kvm/sys_regs.c                  | 22 ++++++--
 7 files changed, 123 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/kvm_mte.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1170ee137096..d00cc3590f6e 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -208,6 +208,12 @@ enum vcpu_sysreg {
 	CNTP_CVAL_EL0,
 	CNTP_CTL_EL0,
 
+	/* Memory Tagging Extension registers */
+	RGSR_EL1,	/* Random Allocation Tag Seed Register */
+	GCR_EL1,	/* Tag Control Register */
+	TFSR_EL1,	/* Tag Fault Status Register (EL1) */
+	TFSRE0_EL1,	/* Tag Fault Status Register (EL0) */
+
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
 	IFSR32_EL2,	/* Instruction Fault Status Register */
diff --git a/arch/arm64/include/asm/kvm_mte.h b/arch/arm64/include/asm/kvm_mte.h
new file mode 100644
index 000000000000..6541c7d6ce06
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_mte.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 ARM Ltd.
+ */
+#ifndef __ASM_KVM_MTE_H
+#define __ASM_KVM_MTE_H
+
+#ifdef __ASSEMBLY__
+
+#include <asm/sysreg.h>
+
+#ifdef CONFIG_ARM64_MTE
+
+.macro mte_switch_to_guest g_ctxt, h_ctxt, reg1
+alternative_if_not ARM64_MTE
+	b	.L__skip_switch\@
+alternative_else_nop_endif
+	mrs	\reg1, hcr_el2
+	and	\reg1, \reg1, #(HCR_ATA)
+	cbz	\reg1, .L__skip_switch\@
+
+	mrs_s	\reg1, SYS_RGSR_EL1
+	str	\reg1, [\h_ctxt, #CPU_RGSR_EL1]
+	mrs_s	\reg1, SYS_GCR_EL1
+	str	\reg1, [\h_ctxt, #CPU_GCR_EL1]
+
+	ldr	\reg1, [\g_ctxt, #CPU_RGSR_EL1]
+	msr_s	SYS_RGSR_EL1, \reg1
+	ldr	\reg1, [\g_ctxt, #CPU_GCR_EL1]
+	msr_s	SYS_GCR_EL1, \reg1
+
+.L__skip_switch\@:
+.endm
+
+.macro mte_switch_to_hyp g_ctxt, h_ctxt, reg1
+alternative_if_not ARM64_MTE
+	b	.L__skip_switch\@
+alternative_else_nop_endif
+	mrs	\reg1, hcr_el2
+	and	\reg1, \reg1, #(HCR_ATA)
+	cbz	\reg1, .L__skip_switch\@
+
+	mrs_s	\reg1, SYS_RGSR_EL1
+	str	\reg1, [\g_ctxt, #CPU_RGSR_EL1]
+	mrs_s	\reg1, SYS_GCR_EL1
+	str	\reg1, [\g_ctxt, #CPU_GCR_EL1]
+
+	ldr	\reg1, [\h_ctxt, #CPU_RGSR_EL1]
+	msr_s	SYS_RGSR_EL1, \reg1
+	ldr	\reg1, [\h_ctxt, #CPU_GCR_EL1]
+	msr_s	SYS_GCR_EL1, \reg1
+
+.L__skip_switch\@:
+.endm
+
+#else /* CONFIG_ARM64_MTE */
+
+.macro mte_switch_to_guest g_ctxt, h_ctxt, reg1
+.endm
+
+.macro mte_switch_to_hyp g_ctxt, h_ctxt, reg1
+.endm
+
+#endif /* CONFIG_ARM64_MTE */
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_KVM_MTE_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index dfd4edbfe360..5424d195cf96 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -580,7 +580,8 @@
 #define SCTLR_ELx_M	(BIT(0))
 
 #define SCTLR_ELx_FLAGS	(SCTLR_ELx_M  | SCTLR_ELx_A | SCTLR_ELx_C | \
-			 SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB)
+			 SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB | \
+			 SCTLR_ELx_ITFSB)
 
 /* SCTLR_EL2 specific flags. */
 #define SCTLR_EL2_RES1	((BIT(4))  | (BIT(5))  | (BIT(11)) | (BIT(16)) | \
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index a36e2fc330d4..944e4f1f45d9 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -108,6 +108,9 @@ int main(void)
   DEFINE(VCPU_WORKAROUND_FLAGS,	offsetof(struct kvm_vcpu, arch.workaround_flags));
   DEFINE(VCPU_HCR_EL2,		offsetof(struct kvm_vcpu, arch.hcr_el2));
   DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_cpu_context, regs));
+  DEFINE(CPU_RGSR_EL1,		offsetof(struct kvm_cpu_context, sys_regs[RGSR_EL1]));
+  DEFINE(CPU_GCR_EL1,		offsetof(struct kvm_cpu_context, sys_regs[GCR_EL1]));
+  DEFINE(CPU_TFSRE0_EL1,	offsetof(struct kvm_cpu_context, sys_regs[TFSRE0_EL1]));
   DEFINE(CPU_APIAKEYLO_EL1,	offsetof(struct kvm_cpu_context, sys_regs[APIAKEYLO_EL1]));
   DEFINE(CPU_APIBKEYLO_EL1,	offsetof(struct kvm_cpu_context, sys_regs[APIBKEYLO_EL1]));
   DEFINE(CPU_APDAKEYLO_EL1,	offsetof(struct kvm_cpu_context, sys_regs[APDAKEYLO_EL1]));
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index b0afad7a99c6..c67582c6dd55 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -13,6 +13,7 @@
 #include <asm/kvm_arm.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_mmu.h>
+#include <asm/kvm_mte.h>
 #include <asm/kvm_ptrauth.h>
 
 	.text
@@ -51,6 +52,9 @@ alternative_else_nop_endif
 
 	add	x29, x0, #VCPU_CONTEXT
 
+	// mte_switch_to_guest(g_ctxt, h_ctxt, tmp1)
+	mte_switch_to_guest x29, x1, x2
+
 	// Macro ptrauth_switch_to_guest format:
 	// 	ptrauth_switch_to_guest(guest cxt, tmp1, tmp2, tmp3)
 	// The below macro to restore guest keys is not implemented in C code
@@ -140,6 +144,9 @@ SYM_INNER_LABEL(__guest_exit, SYM_L_GLOBAL)
 	// when this feature is enabled for kernel code.
 	ptrauth_switch_to_hyp x1, x2, x3, x4, x5
 
+	// mte_switch_to_hyp(g_ctxt, h_ctxt, reg1)
+	mte_switch_to_hyp x1, x2, x3
+
 	// Restore hyp's sp_el0
 	restore_sp_el0 x2, x3
 
diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
index cce43bfe158f..de7e14c862e6 100644
--- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
+++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
@@ -14,6 +14,7 @@
 #include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_hyp.h>
+#include <asm/kvm_mmu.h>
 
 static inline void __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
 {
@@ -26,6 +27,16 @@ static inline void __sysreg_save_user_state(struct kvm_cpu_context *ctxt)
 	ctxt_sys_reg(ctxt, TPIDRRO_EL0)	= read_sysreg(tpidrro_el0);
 }
 
+static inline bool ctxt_has_mte(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 kvm_has_mte(kern_hyp_va(vcpu->kvm));
+}
+
 static inline void __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt_sys_reg(ctxt, CSSELR_EL1)	= read_sysreg(csselr_el1);
@@ -46,6 +57,11 @@ static inline void __sysreg_save_el1_state(struct kvm_cpu_context *ctxt)
 	ctxt_sys_reg(ctxt, PAR_EL1)	= read_sysreg_par();
 	ctxt_sys_reg(ctxt, TPIDR_EL1)	= read_sysreg(tpidr_el1);
 
+	if (ctxt_has_mte(ctxt)) {
+		ctxt_sys_reg(ctxt, TFSR_EL1) = read_sysreg_el1(SYS_TFSR);
+		ctxt_sys_reg(ctxt, TFSRE0_EL1) = read_sysreg_s(SYS_TFSRE0_EL1);
+	}
+
 	ctxt_sys_reg(ctxt, SP_EL1)	= read_sysreg(sp_el1);
 	ctxt_sys_reg(ctxt, ELR_EL1)	= read_sysreg_el1(SYS_ELR);
 	ctxt_sys_reg(ctxt, SPSR_EL1)	= read_sysreg_el1(SYS_SPSR);
@@ -107,6 +123,11 @@ static inline void __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt_sys_reg(ctxt, PAR_EL1),	par_el1);
 	write_sysreg(ctxt_sys_reg(ctxt, TPIDR_EL1),	tpidr_el1);
 
+	if (ctxt_has_mte(ctxt)) {
+		write_sysreg_el1(ctxt_sys_reg(ctxt, TFSR_EL1), SYS_TFSR);
+		write_sysreg_s(ctxt_sys_reg(ctxt, TFSRE0_EL1), SYS_TFSRE0_EL1);
+	}
+
 	if (!has_vhe() &&
 	    cpus_have_final_cap(ARM64_WORKAROUND_SPECULATIVE_AT) &&
 	    ctxt->__hyp_running_vcpu) {
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 18c87500a7a8..377ae6efb0ef 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -1303,6 +1303,20 @@ static bool access_ccsidr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static unsigned int mte_visibility(const struct kvm_vcpu *vcpu,
+				   const struct sys_reg_desc *rd)
+{
+	return REG_HIDDEN;
+}
+
+#define MTE_REG(name) {				\
+	SYS_DESC(SYS_##name),			\
+	.access = undef_access,			\
+	.reset = reset_unknown,			\
+	.reg = name,				\
+	.visibility = mte_visibility,		\
+}
+
 /* sys_reg_desc initialiser for known cpufeature ID registers */
 #define ID_SANITISED(name) {			\
 	SYS_DESC(SYS_##name),			\
@@ -1471,8 +1485,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_ACTLR_EL1), access_actlr, reset_actlr, ACTLR_EL1 },
 	{ SYS_DESC(SYS_CPACR_EL1), NULL, reset_val, CPACR_EL1, 0 },
 
-	{ SYS_DESC(SYS_RGSR_EL1), undef_access },
-	{ SYS_DESC(SYS_GCR_EL1), undef_access },
+	MTE_REG(RGSR_EL1),
+	MTE_REG(GCR_EL1),
 
 	{ SYS_DESC(SYS_ZCR_EL1), NULL, reset_val, ZCR_EL1, 0, .visibility = sve_visibility },
 	{ SYS_DESC(SYS_TTBR0_EL1), access_vm_reg, reset_unknown, TTBR0_EL1 },
@@ -1498,8 +1512,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ SYS_DESC(SYS_ERXMISC0_EL1), trap_raz_wi },
 	{ SYS_DESC(SYS_ERXMISC1_EL1), trap_raz_wi },
 
-	{ SYS_DESC(SYS_TFSR_EL1), undef_access },
-	{ SYS_DESC(SYS_TFSRE0_EL1), undef_access },
+	MTE_REG(TFSR_EL1),
+	MTE_REG(TFSRE0_EL1),
 
 	{ SYS_DESC(SYS_FAR_EL1), access_vm_reg, reset_unknown, FAR_EL1 },
 	{ SYS_DESC(SYS_PAR_EL1), NULL, reset_unknown, PAR_EL1 },
-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:08 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:08 +0100
Subject: [PATCH v11 5/6] KVM: arm64: ioctl to fetch/store tags in a guest
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-6-steven.price@arm.com>

The VMM may not wish to have it's own mapping of guest memory mapped
with PROT_MTE because this causes problems if the VMM has tag checking
enabled (the guest controls the tags in physical RAM and it's unlikely
the tags are correct for the VMM).

Instead add a new ioctl which allows the VMM to easily read/write the
tags from guest memory, allowing the VMM's mapping to be non-PROT_MTE
while the VMM can still read/write the tags for the purpose of
migration.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 arch/arm64/include/uapi/asm/kvm.h | 14 +++++++
 arch/arm64/kvm/arm.c              | 69 +++++++++++++++++++++++++++++++
 include/uapi/linux/kvm.h          |  1 +
 3 files changed, 84 insertions(+)

diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 24223adae150..2b85a047c37d 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -184,6 +184,20 @@ struct kvm_vcpu_events {
 	__u32 reserved[12];
 };
 
+struct kvm_arm_copy_mte_tags {
+	__u64 guest_ipa;
+	__u64 length;
+	union {
+		void __user *addr;
+		__u64 padding;
+	};
+	__u64 flags;
+	__u64 reserved[2];
+};
+
+#define KVM_ARM_TAGS_TO_GUEST		0
+#define KVM_ARM_TAGS_FROM_GUEST		1
+
 /* If you need to interpret the index values, here is the key: */
 #define KVM_REG_ARM_COPROC_MASK		0x000000000FFF0000
 #define KVM_REG_ARM_COPROC_SHIFT	16
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 46bf319f6cb7..9a6b26d37236 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1297,6 +1297,65 @@ static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
 	}
 }
 
+static int kvm_vm_ioctl_mte_copy_tags(struct kvm *kvm,
+				      struct kvm_arm_copy_mte_tags *copy_tags)
+{
+	gpa_t guest_ipa = copy_tags->guest_ipa;
+	size_t length = copy_tags->length;
+	void __user *tags = copy_tags->addr;
+	gpa_t gfn;
+	bool write = !(copy_tags->flags & KVM_ARM_TAGS_FROM_GUEST);
+	int ret = 0;
+
+	if (copy_tags->reserved[0] || copy_tags->reserved[1])
+		return -EINVAL;
+
+	if (copy_tags->flags & ~KVM_ARM_TAGS_FROM_GUEST)
+		return -EINVAL;
+
+	if (length & ~PAGE_MASK || guest_ipa & ~PAGE_MASK)
+		return -EINVAL;
+
+	gfn = gpa_to_gfn(guest_ipa);
+
+	mutex_lock(&kvm->slots_lock);
+
+	while (length > 0) {
+		kvm_pfn_t pfn = gfn_to_pfn_prot(kvm, gfn, write, NULL);
+		void *maddr;
+		unsigned long num_tags = PAGE_SIZE / MTE_GRANULE_SIZE;
+
+		if (is_error_noslot_pfn(pfn)) {
+			ret = -EFAULT;
+			goto out;
+		}
+
+		maddr = page_address(pfn_to_page(pfn));
+
+		if (!write) {
+			num_tags = mte_copy_tags_to_user(tags, maddr, num_tags);
+			kvm_release_pfn_clean(pfn);
+		} else {
+			num_tags = mte_copy_tags_from_user(maddr, tags,
+							   num_tags);
+			kvm_release_pfn_dirty(pfn);
+		}
+
+		if (num_tags != PAGE_SIZE / MTE_GRANULE_SIZE) {
+			ret = -EFAULT;
+			goto out;
+		}
+
+		gfn++;
+		tags += num_tags;
+		length -= PAGE_SIZE;
+	}
+
+out:
+	mutex_unlock(&kvm->slots_lock);
+	return ret;
+}
+
 long kvm_arch_vm_ioctl(struct file *filp,
 		       unsigned int ioctl, unsigned long arg)
 {
@@ -1333,6 +1392,16 @@ long kvm_arch_vm_ioctl(struct file *filp,
 
 		return 0;
 	}
+	case KVM_ARM_MTE_COPY_TAGS: {
+		struct kvm_arm_copy_mte_tags copy_tags;
+
+		if (!kvm_has_mte(kvm))
+			return -EINVAL;
+
+		if (copy_from_user(&copy_tags, argp, sizeof(copy_tags)))
+			return -EFAULT;
+		return kvm_vm_ioctl_mte_copy_tags(kvm, &copy_tags);
+	}
 	default:
 		return -EINVAL;
 	}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6dc16c09a2d1..470c122f4c2d 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1424,6 +1424,7 @@ struct kvm_s390_ucas_mapping {
 /* Available with KVM_CAP_PMU_EVENT_FILTER */
 #define KVM_SET_PMU_EVENT_FILTER  _IOW(KVMIO,  0xb2, struct kvm_pmu_event_filter)
 #define KVM_PPC_SVM_OFF		  _IO(KVMIO,  0xb3)
+#define KVM_ARM_MTE_COPY_TAGS	  _IOR(KVMIO,  0xb4, struct kvm_arm_copy_mte_tags)
 
 /* ioctl for vm fd */
 #define KVM_CREATE_DEVICE	  _IOWR(KVMIO,  0xe0, struct kvm_create_device)
-- 
2.20.1



From steven.price at arm.com  Fri Apr 16 16:43:09 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 16:43:09 +0100
Subject: [PATCH v11 6/6] KVM: arm64: Document MTE capability and ioctl
In-Reply-To: <20210416154309.22129-1-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
Message-ID: <20210416154309.22129-7-steven.price@arm.com>

A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
granting a guest access to the tags, and provides a mechanism for the
VMM to enable it.

A new ioctl (KVM_ARM_MTE_COPY_TAGS) provides a simple way for a VMM to
access the tags of a guest without having to maintain a PROT_MTE mapping
in userspace. The above capability gates access to the ioctl.

Signed-off-by: Steven Price <steven.price at arm.com>
---
 Documentation/virt/kvm/api.rst | 53 ++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 1a2b5210cdbf..ccc84f21ba5e 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -4938,6 +4938,40 @@ see KVM_XEN_VCPU_SET_ATTR above.
 The KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST type may not be used
 with the KVM_XEN_VCPU_GET_ATTR ioctl.
 
+4.131 KVM_ARM_MTE_COPY_TAGS
+---------------------------
+
+:Capability: KVM_CAP_ARM_MTE
+:Architectures: arm64
+:Type: vm ioctl
+:Parameters: struct kvm_arm_copy_mte_tags
+:Returns: 0 on success, < 0 on error
+
+::
+
+  struct kvm_arm_copy_mte_tags {
+	__u64 guest_ipa;
+	__u64 length;
+	union {
+		void __user *addr;
+		__u64 padding;
+	};
+	__u64 flags;
+	__u64 reserved[2];
+  };
+
+Copies Memory Tagging Extension (MTE) tags to/from guest tag memory. The
+``guest_ipa`` and ``length`` fields must be ``PAGE_SIZE`` aligned. The ``addr``
+fieldmust point to a buffer which the tags will be copied to or from.
+
+``flags`` specifies the direction of copy, either ``KVM_ARM_TAGS_TO_GUEST`` or
+``KVM_ARM_TAGS_FROM_GUEST``.
+
+The size of the buffer to store the tags is ``(length / MTE_GRANULE_SIZE)``
+bytes (i.e. 1/16th of the corresponding size). Each byte contains a single tag
+value. This matches the format of ``PTRACE_PEEKMTETAGS`` and
+``PTRACE_POKEMTETAGS``.
+
 5. The kvm_run structure
 ========================
 
@@ -6227,6 +6261,25 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between them.
 This capability can be used to check / enable 2nd DAWR feature provided
 by POWER10 processor.
 
+7.23 KVM_CAP_ARM_MTE
+--------------------
+
+:Architectures: arm64
+:Parameters: none
+
+This capability indicates that KVM (and the hardware) supports exposing the
+Memory Tagging Extensions (MTE) to the guest. It must also be enabled by the
+VMM before the guest will be granted access.
+
+When enabled the guest is able to access tags associated with any memory given
+to the guest. KVM will ensure that the pages are flagged ``PG_mte_tagged`` so
+that the tags are maintained during swap or hibernation of the host; however
+the VMM needs to manually save/restore the tags as appropriate if the VM is
+migrated.
+
+When enabled the VMM may make use of the ``KVM_ARM_MTE_COPY_TAGS`` ioctl to
+perform a bulk copy of tags to/from the guest.
+
 8. Other capabilities.
 ======================
 
-- 
2.20.1



From fabrice.gasnier at foss.st.com  Fri Apr 16 16:52:44 2021
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Fri, 16 Apr 2021 17:52:44 +0200
Subject: [Linux-stm32] [PATCH 04/13] dt-bindings: mfd: stm32-timers:
 remove #address/size cells from required properties
In-Reply-To: <20210415101037.1465-5-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-5-alexandre.torgue@foss.st.com>
Message-ID: <bd85bd41-d899-7e7a-1878-35301a267eb9@foss.st.com>

On 4/15/21 12:10 PM, Alexandre Torgue wrote:
> address-cells and size-cells can't be declared as "required" properties
> as they are not needed if subnodes don't have a "reg" entry.
> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
> 
> diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
> index 0f16c8864a87..dace35362a7a 100644
> --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml
> +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml

Hi Alexandre,

Not sure if this matters: patches 3 and 4 could be swapped in the
series. Apart from that:

Reviewed-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Thanks,
Fabrice
> @@ -119,8 +119,6 @@ patternProperties:
>        - compatible
>  
>  required:
> -  - "#address-cells"
> -  - "#size-cells"
>    - compatible
>    - reg
>    - clocks
> 


From fabrice.gasnier at foss.st.com  Fri Apr 16 16:52:17 2021
From: fabrice.gasnier at foss.st.com (Fabrice Gasnier)
Date: Fri, 16 Apr 2021 17:52:17 +0200
Subject: [Linux-stm32] [PATCH 03/13] ARM: dts: stm32: fix timer nodes on
 STM32 MCU to prevent warnings
In-Reply-To: <20210415101037.1465-4-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-4-alexandre.torgue@foss.st.com>
Message-ID: <c329f116-458c-0d33-3c8f-ee5d22189ca4@foss.st.com>

On 4/15/21 12:10 PM, Alexandre Torgue wrote:
> Prevent warning seen with "make dtbs_check W=1" command:
> 
> Warning (avoid_unnecessary_addr_size): /soc/timers at 40001c00: unnecessary
> address-cells/size-cells without "ranges" or child "reg" property
> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>

Hi Alexandre,

Reviewed-by: Fabrice Gasnier <fabrice.gasnier at foss.st.com>

Thanks,
Fabrice
> 
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 41e0087bdbf9..8748d5850298 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -283,8 +283,6 @@
>  		};
>  
>  		timers13: timers at 40001c00 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40001C00 0x400>;
>  			clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM13)>;
> @@ -299,8 +297,6 @@
>  		};
>  
>  		timers14: timers at 40002000 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40002000 0x400>;
>  			clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM14)>;
> @@ -633,8 +629,6 @@
>  		};
>  
>  		timers10: timers at 40014400 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40014400 0x400>;
>  			clocks = <&rcc 0 STM32F4_APB2_CLOCK(TIM10)>;
> @@ -649,8 +643,6 @@
>  		};
>  
>  		timers11: timers at 40014800 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40014800 0x400>;
>  			clocks = <&rcc 0 STM32F4_APB2_CLOCK(TIM11)>;
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
> index e1df603fc981..72c1b76684b6 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -265,8 +265,6 @@
>  		};
>  
>  		timers13: timers at 40001c00 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40001C00 0x400>;
>  			clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM13)>;
> @@ -281,8 +279,6 @@
>  		};
>  
>  		timers14: timers at 40002000 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40002000 0x400>;
>  			clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM14)>;
> @@ -531,8 +527,6 @@
>  		};
>  
>  		timers10: timers at 40014400 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40014400 0x400>;
>  			clocks = <&rcc 0 STM32F7_APB2_CLOCK(TIM10)>;
> @@ -547,8 +541,6 @@
>  		};
>  
>  		timers11: timers at 40014800 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-timers";
>  			reg = <0x40014800 0x400>;
>  			clocks = <&rcc 0 STM32F7_APB2_CLOCK(TIM11)>;
> diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
> index 05ecdf9ff03a..6e42ca2dada2 100644
> --- a/arch/arm/boot/dts/stm32h743.dtsi
> +++ b/arch/arm/boot/dts/stm32h743.dtsi
> @@ -485,8 +485,6 @@
>  		};
>  
>  		lptimer4: timer at 58002c00 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-lptimer";
>  			reg = <0x58002c00 0x400>;
>  			clocks = <&rcc LPTIM4_CK>;
> @@ -501,8 +499,6 @@
>  		};
>  
>  		lptimer5: timer at 58003000 {
> -			#address-cells = <1>;
> -			#size-cells = <0>;
>  			compatible = "st,stm32-lptimer";
>  			reg = <0x58003000 0x400>;
>  			clocks = <&rcc LPTIM5_CK>;
> 


From john.garry at huawei.com  Fri Apr 16 16:55:29 2021
From: john.garry at huawei.com (John Garry)
Date: Fri, 16 Apr 2021 16:55:29 +0100
Subject: [PATCH 5/8] iommu: fix a couple of spelling mistakes
In-Reply-To: <20210326062412.1262-6-thunder.leizhen@huawei.com>
References: <20210326062412.1262-1-thunder.leizhen@huawei.com>
 <20210326062412.1262-6-thunder.leizhen@huawei.com>
Message-ID: <e04d117a-4832-7f95-7adf-dbece21aad8c@huawei.com>

On 26/03/2021 06:24, Zhen Lei wrote:
> There are several spelling mistakes, as follows:
> funcions ==> functions
> distiguish ==> distinguish
> detroyed ==> destroyed
> 
> Signed-off-by: Zhen Lei<thunder.leizhen at huawei.com>

I think that there should be a /s/appropriatley/appropriately/ in iommu.c

Thanks,
john


From steven.price at arm.com  Fri Apr 16 17:00:22 2021
From: steven.price at arm.com (Steven Price)
Date: Fri, 16 Apr 2021 17:00:22 +0100
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <10adad00-14de-61b6-ce2a-bdde23a34bcf@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <6ff4816b-8ff6-19de-73a2-3fcadc003ccd@csgroup.eu>
 <e39d500a-2154-3c5d-9393-8bf53a567fad@arm.com>
 <b6b5300d-35a0-3bc0-ad1d-f2af433ef27e@csgroup.eu>
 <b245cf06-f2e5-87a5-9a5e-64efc39d415a@csgroup.eu>
 <10adad00-14de-61b6-ce2a-bdde23a34bcf@csgroup.eu>
Message-ID: <a94fa51b-577f-b520-f8e8-a9304425c265@arm.com>

On 16/04/2021 16:15, Christophe Leroy wrote:
> 
> 
> Le 16/04/2021 ? 17:04, Christophe Leroy a ?crit?:
>>
>>
>> Le 16/04/2021 ? 16:40, Christophe Leroy a ?crit?:
>>>
>>>
>>> Le 16/04/2021 ? 15:00, Steven Price a ?crit?:
>>>> On 16/04/2021 12:08, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>>>>>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>>>>>
>>>>>>>
>>>>>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>>>>>> To be honest I don't fully understand why powerpc requires the 
>>>>>>>> page_size - it appears to be using it purely to find "holes" in 
>>>>>>>> the calls to note_page(), but I haven't worked out why such 
>>>>>>>> holes would occur.
>>>>>>>
>>>>>>> I was indeed introduced for KASAN. We have a first commit 
>>>>>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page 
>>>>>>> size to detect whether it is a KASAN like stuff.
>>>>>>>
>>>>>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a 
>>>>>>> fix. I can't remember what the problem was exactly, something 
>>>>>>> around the use of hugepages for kernel memory, came as part of 
>>>>>>> the series 
>>>>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ah, that's useful context. So it looks like powerpc took a 
>>>>>> different route to reducing the KASAN output to x86.
>>>>>>
>>>>>> Given the generic ptdump code has handling for KASAN already it 
>>>>>> should be possible to drop that from the powerpc arch code, which 
>>>>>> I think means we don't actually need to provide page size to 
>>>>>> notepage(). Hopefully that means more code to delete ;)
>>>>>>
>>>>>
>>>>> Yes ... and no.
>>>>>
>>>>> It looks like the generic ptdump handles the case when several 
>>>>> pgdir entries points to the same kasan_early_shadow_pte. But it 
>>>>> doesn't take into account the powerpc case where we have regular 
>>>>> page tables where several (if not all) PTEs are pointing to the 
>>>>> kasan_early_shadow_page .
>>>>
>>>> I'm not sure I follow quite how powerpc is different here. But could 
>>>> you have a similar check for PTEs against kasan_early_shadow_pte as 
>>>> the other levels already have?
>>>>
>>>> I'm just worried that page_size isn't well defined in this interface 
>>>> and it's going to cause problems in the future.
>>>>
>>>
>>> I'm trying. I reverted the two commits b00ff6d8c and cabe8138.
>>>
>>> At the moment, I don't get exactly what I expect: For linear memory I 
>>> get one line for each 8M page whereas before reverting the patches I 
>>> got one 16M line and one 112M line.
>>>
>>> And for KASAN shadow area I get two lines for the 2x 8M pages 
>>> shadowing linear mem then I get one 4M line for each PGDIR entry 
>>> pointing to kasan_early_shadow_pte.
>>>
>>> 0xf8000000-0xf87fffff 0x07000000???????? 8M?? huge??????? rw       
>>> present
>>> 0xf8800000-0xf8ffffff 0x07800000???????? 8M?? huge??????? rw       
>>> present
>>> 0xf9000000-0xf93fffff 0x01430000???????? 4M?????????????? r        
>>> present
>> ...
>>> 0xfec00000-0xfeffffff 0x01430000???????? 4M?????????????? r        
>>> present
>>>
>>> Any idea ?
>>>
>>
>>
>> I think the different with other architectures is here:
>>
>> ?????} else if (flag != st->current_flags || level != st->level ||
>> ??????????? addr >= st->marker[1].start_address ||
>> ??????????? pa != st->last_pa + PAGE_SIZE) {
>>
>>
>> In addition to the checks everyone do, powerpc also checks "pa != 
>> st->last_pa + PAGE_SIZE".
>> And it is definitely for that test that page_size argument add been 
>> added.
> 
> By replacing that test by (pa - st->start_pa != addr - 
> st->start_address) it works again. So we definitely don't need the real 
> page size.

Yes that should work. Thanks for figuring it out!

> 
>>
>> I see that other architectures except RISCV don't dump the physical 
>> address. But even RISCV doesn't include that check.

Yes not having the physical address certainly simplifies things - 
although I can see why that can be handy to see. The disadvantage is 
that user space or vmalloc()'d memory will produce a lot of output 
because the physical addresses are unlikely to be contiguous. And for 
most uses you don't need the information.

>> That physical address dump was added by commit aaa229529244 
>> ("powerpc/mm: Add physical address to Linux page table dump") 
>> [https://github.com/torvalds/linux/commit/aaa2295]
>>
>> How do other architectures deal with the problem described by the 
>> commit log of that patch ?

AFAIK other architectures are "broken" in this regard. In practice I 
don't think it often causes an issue though.

Steve


From broonie at kernel.org  Fri Apr 16 17:01:46 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 17:01:46 +0100
Subject: [PATCH 0/5] spi: spi-zynqmp-gqspi: fix spi issues
In-Reply-To: <20210416142047.6349-1-quanyang.wang@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
Message-ID: <161858883110.29027.5432599534762847384.b4-ty@kernel.org>

On Fri, 16 Apr 2021 22:20:42 +0800, quanyang.wang at windriver.com wrote:
> V2:
> Remove all "Fixes:" tags since they base on some patches are not
> with "Fixes:".
> 
> V1:
> This series fix some issues that occurs in spi-zynqmp-gqspi.c.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue
      commit: c6bdae08012b2ca3e94f3a41ef4ca8cfe7c9ab6f
[2/5] spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
      commit: 799f923f0a66a9c99f0a3eaa078b306db7a8b33a
[3/5] spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
      commit: 2530b3df4326023a171977ab46fdfeac0340f5b2
[4/5] spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
      commit: a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58
[5/5] spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
      commit: 126bdb606fd2802454e6048caef1be3e25dd121e

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 Apr 16 17:17:40 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 17:17:40 +0100
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210402032404.47239-2-madvenka@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
Message-ID: <20210416161740.GH5560@sirena.org.uk>

On Thu, Apr 01, 2021 at 10:24:04PM -0500, madvenka at linux.microsoft.com wrote:

> Reliable stacktracing requires that we identify when a stacktrace is
> terminated early. We can do this by ensuring all tasks have a final
> frame record at a known location on their task stack, and checking
> that this is the final frame record in the chain.

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/20210416/e262f7cd/attachment.sig>

From pcc at google.com  Fri Apr 16 17:20:12 2021
From: pcc at google.com (Peter Collingbourne)
Date: Fri, 16 Apr 2021 09:20:12 -0700
Subject: [PATCH v8 1/3] arm64: mte: make the per-task SCTLR_EL1 field
 usable elsewhere
In-Reply-To: <161839488327.21932.16461913261970131291.b4-ty@arm.com>
References: <13d725cb8e741950fb9d6e64b2cd9bd54ff7c3f9.1616123271.git.pcc@google.com>
 <161839488327.21932.16461913261970131291.b4-ty@arm.com>
Message-ID: <CAMn1gO7-DnGdhP6gO61ZR6o-jq5ymMOYuCdEeLu+xH7kFrvaTw@mail.gmail.com>

On Wed, Apr 14, 2021 at 3:10 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
>
> On Thu, 18 Mar 2021 20:10:52 -0700, Peter Collingbourne wrote:
> > In an upcoming change we are going to introduce per-task SCTLR_EL1
> > bits for PAC. Move the existing per-task SCTLR_EL1 field out of the
> > MTE-specific code so that we will be able to use it from both the
> > PAC and MTE code paths and make the task switching code more efficient.
>
> Applied to arm64 (for-next/pac-set-get-enabled-keys).
>
> Peter, can you please have a look and give it a try as part of the arm64
> for-next/core branch? I rebased your patches on top of the
> for-next/mte-async-kernel-mode branch as this was adding more code to
> mte_thread_switch(), so I kept the function for now.
>
> Thanks.
>
> [1/3] arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere
>       https://git.kernel.org/arm64/c/2f79d2fc391e
> [2/3] arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)
>       https://git.kernel.org/arm64/c/201698626fbc
> [3/3] arm64: pac: Optimize kernel entry/exit key installation code paths
>       https://git.kernel.org/arm64/c/b90e483938ce

Hi Catalin,

I tested the rebased patch series on an Apple M1 under a hypervisor
with my Android forward-edge PAC prototype and it seems to work.

I think it should be possible to get rid of at least one of the ISBs
that are now on the task switch path, but let's leave that to a later
patch. The patch series looks good otherwise.

Peter


From catalin.marinas at arm.com  Fri Apr 16 17:24:55 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 16 Apr 2021 17:24:55 +0100
Subject: [GIT PULL] arm64 fix for 5.12-rc8/final
Message-ID: <20210416162451.GA11506@arm.com>

Hi Linus,

A recent commit (2decad92f473, "arm64: mte: Ensure TIF_MTE_ASYNC_FAULT
is set atomically") broke the kernel build when using the LLVM
integrated assembly (only noticeable with clang-12 as MTE is not
supported by earlier versions and the code in question not compiled).
The Fixes: tag in the commit refers to the original patch introducing
subsections for the alternative code sequences.

Please pull the fix below for -rc8/final (Will's off today). Thanks.

The following changes since commit 738fa58ee1328481d1d7889e7c430b3401c571b9:

  arm64: kprobes: Restore local irqflag if kprobes is cancelled (2021-04-13 09:30:16 +0100)

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 22315a2296f4c251fa92aec45fbbae37e9301b6c:

  arm64: alternatives: Move length validation in alternative_{insn, endif} (2021-04-15 18:33:25 +0100)

----------------------------------------------------------------
Fix kernel compilation when using the LLVM integrated assembly.

----------------------------------------------------------------
Nathan Chancellor (1):
      arm64: alternatives: Move length validation in alternative_{insn, endif}

 arch/arm64/include/asm/alternative-macros.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
Catalin


From mark.rutland at arm.com  Fri Apr 16 17:30:32 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 16 Apr 2021 17:30:32 +0100
Subject: [PATCH] arm64: alternative: simplify passing alt_region
Message-ID: <20210416163032.10857-1-mark.rutland@arm.com>

In __apply_alternatives() we take a pointer to void which we later
assign to a pointer to struct alt_region. As all callers are passing a
pointer to struct alt_region to begin with, it's simpler and more robust
to take a pointer to struct alt region, so let's do so and avoid the
need for a temporary variable.

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/kernel/alternative.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 1184c44ea2c7..f6fd16185040 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -133,11 +133,10 @@ static void clean_dcache_range_nopatch(u64 start, u64 end)
 	} while (cur += d_size, cur < end);
 }
 
-static void __apply_alternatives(void *alt_region,  bool is_module,
+static void __apply_alternatives(struct alt_region *region, bool is_module,
 				 unsigned long *feature_mask)
 {
 	struct alt_instr *alt;
-	struct alt_region *region = alt_region;
 	__le32 *origptr, *updptr;
 	alternative_cb_t alt_cb;
 
-- 
2.11.0



From quanyang.wang at windriver.com  Fri Apr 16 17:31:44 2021
From: quanyang.wang at windriver.com (Quanyang Wang)
Date: Sat, 17 Apr 2021 00:31:44 +0800
Subject: [PATCH 0/5] spi: spi-zynqmp-gqspi: fix spi issues
In-Reply-To: <161858883110.29027.5432599534762847384.b4-ty@kernel.org>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
 <161858883110.29027.5432599534762847384.b4-ty@kernel.org>
Message-ID: <fb308dee-6ca4-e2de-964a-f67684f15e54@windriver.com>

Hi Mark,

Sorry for any confusion caused.

Thanks,

Quanyang

On 4/17/21 12:01 AM, Mark Brown wrote:
> On Fri, 16 Apr 2021 22:20:42 +0800, quanyang.wang at windriver.com wrote:
>> V2:
>> Remove all "Fixes:" tags since they base on some patches are not
>> with "Fixes:".
>>
>> V1:
>> This series fix some issues that occurs in spi-zynqmp-gqspi.c.
>>
>> [...]
> Applied to
>
>     https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>
> Thanks!
>
> [1/5] spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue
>        commit: c6bdae08012b2ca3e94f3a41ef4ca8cfe7c9ab6f
> [2/5] spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
>        commit: 799f923f0a66a9c99f0a3eaa078b306db7a8b33a
> [3/5] spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
>        commit: 2530b3df4326023a171977ab46fdfeac0340f5b2
> [4/5] spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
>        commit: a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58
> [5/5] spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
>        commit: 126bdb606fd2802454e6048caef1be3e25dd121e
>
> 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 Apr 16 17:33:41 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 17:33:41 +0100
Subject: [PATCH 0/5] spi: spi-zynqmp-gqspi: fix spi issues
In-Reply-To: <fb308dee-6ca4-e2de-964a-f67684f15e54@windriver.com>
References: <20210416142047.6349-1-quanyang.wang@windriver.com>
 <161858883110.29027.5432599534762847384.b4-ty@kernel.org>
 <fb308dee-6ca4-e2de-964a-f67684f15e54@windriver.com>
Message-ID: <20210416163341.GJ5560@sirena.org.uk>

On Sat, Apr 17, 2021 at 12:31:44AM +0800, Quanyang Wang wrote:

> Sorry for any confusion caused.

No worries, it's mainly just an issue for anyone doing stable backports
- hopefully they'll figure things out.
-------------- 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/20210416/215de847/attachment.sig>

From hsinyi at chromium.org  Fri Apr 16 17:40:48 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:48 +0800
Subject: [PATCH v2 1/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kappa
Message-ID: <20210416164055.3223088-1-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index aff57a8c8c30..81b86b189a8d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -144,6 +144,10 @@ properties:
           - const: google,kakadu-rev2
           - const: google,kakadu
           - const: mediatek,mt8183
+      - description: Google Kappa (HP Chromebook 11a)
+        items:
+          - const: google,kappa
+          - const: mediatek,mt8183
       - description: Google Kodama (Lenovo 10e Chromebook Tablet)
         items:
           - enum:
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:49 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:49 +0800
Subject: [PATCH v2 2/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-willow
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-2-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T).

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 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 81b86b189a8d..96c401597bd8 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -157,6 +157,13 @@ properties:
               - google,kodama-sku32
           - const: google,kodama
           - const: mediatek,mt8183
+      - description: Google Willow (Acer Chromebook 311 C722/C722T)
+        items:
+          - enum:
+              - google,willow-sku0
+              - google,willow-sku1
+          - const: google,willow
+          - const: mediatek,mt8183
       - items:
           - enum:
               - mediatek,mt8183-pumpkin
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:50 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:50 +0800
Subject: [PATCH v2 3/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-burnet
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-3-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 96c401597bd8..0870490aa350 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -122,6 +122,10 @@ properties:
           - enum:
               - 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:
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:52 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:52 +0800
Subject: [PATCH v2 5/8] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-5-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile            |  1 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts  | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index a1c50adc98fa..df70674949ce 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
new file mode 100644
index 000000000000..b3f46c16e5d7
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google kappa board";
+	compatible = "google,kappa", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:51 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:51 +0800
Subject: [PATCH v2 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-4-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 0870490aa350..7afd01aad964 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -137,9 +137,11 @@ properties:
         items:
           - const: google,damu
           - const: mediatek,mt8183
-      - description: Google Juniper (Acer Chromebook Spin 311)
+      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311)
         items:
-          - const: google,juniper-sku16
+          - enum:
+              - google,juniper-sku16
+              - google,juniper-sku17
           - const: google,juniper
           - const: mediatek,mt8183
       - description: Google Kakadu (ASUS Chromebook Detachable CM3)
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:54 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:54 +0800
Subject: [PATCH v2 7/8] arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-7-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  1 +
 .../mediatek/mt8183-kukui-jacuzzi-burnet.dts  | 33 +++++++++++++++++++
 2 files changed, 34 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 5f43bbc2ea72..b33d0bc58021 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
new file mode 100644
index 000000000000..b97ca331970e
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google burnet board";
+	compatible = "google,burnet", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
+
+&i2c0 {
+	touchscreen at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		interrupts-extended = <&pio 155 IRQ_TYPE_LEVEL_LOW>;
+
+		post-power-on-delay-ms = <200>;
+		hid-descr-addr = <0x0020>;
+	};
+};
+
+&i2c2 {
+	clock-stretch-ns = <4100>;
+};
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:53 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:53 +0800
Subject: [PATCH v2 6/8] arm64: dts: mt8183: Add kukui-jacuzzi-willow board
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-6-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T)

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  2 ++
 .../mt8183-kukui-jacuzzi-willow-sku0.dts      | 13 +++++++++
 .../mt8183-kukui-jacuzzi-willow-sku1.dts      | 12 ++++++++
 .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 28 +++++++++++++++++++
 4 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index df70674949ce..5f43bbc2ea72 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -16,6 +16,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
new file mode 100644
index 000000000000..281265f082db
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku0";
+	compatible = "google,willow-sku0", "google,willow", "mediatek,mt8183";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
new file mode 100644
index 000000000000..22e56bdc1ee3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku1";
+	compatible = "google,willow-sku1", "google,willow", "mediatek,mt8183";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
new file mode 100644
index 000000000000..3204c1abc4ee
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+&i2c2 {
+	clock-stretch-ns = <9500>;
+
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_pins>;
+
+		interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
+
+		wakeup-source;
+	};
+};
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_JUNIPER";
+};
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:40:55 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:40:55 +0800
Subject: [PATCH v2 8/8] arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210416164055.3223088-8-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile                |  1 +
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12 ++++++++++++
 2 files changed, 13 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index b33d0bc58021..25770d83059d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
new file mode 100644
index 000000000000..6f1aa692753a
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-juniper.dtsi"
+
+/ {
+	model = "Google kenzo sku17 board";
+	compatible = "google,juniper-sku17", "google,juniper", "mediatek,mt8183";
+};
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Fri Apr 16 17:41:43 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Sat, 17 Apr 2021 00:41:43 +0800
Subject: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <face0af7-8630-31fa-4975-a80311257d13@gmail.com>
References: <20210415093519.1920877-1-hsinyi@chromium.org>
 <20210415093519.1920877-4-hsinyi@chromium.org>
 <face0af7-8630-31fa-4975-a80311257d13@gmail.com>
Message-ID: <CAJMQK-h9YGmuDU5r+Ook=OODLK_n75+1o_Bs1KWrZOgMmyX0=Q@mail.gmail.com>

On Fri, Apr 16, 2021 at 10:42 PM Matthias Brugger
<matthias.bgg at gmail.com> wrote:
>
>
>
> On 15/04/2021 11:35, Hsin-Yi Wang wrote:
> > Kenzo is known as Acer Chromebook 311.
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> > ---
> >  Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> > index 0870490aa350..39e4a99ebb37 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> > @@ -137,9 +137,11 @@ properties:
> >          items:
> >            - const: google,damu
> >            - const: mediatek,mt8183
> > -      - description: Google Juniper (Acer Chromebook Spin 311)
> > +      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Crhomebook 311)
>
> Crhomebook -> Chromebook :)

Thanks. Fixed in v2.
>
> >          items:
> > -          - const: google,juniper-sku16
> > +          - enum:
> > +              - google,juniper-sku16
> > +              - google,juniper-sku17
> >            - const: google,juniper
> >            - const: mediatek,mt8183
> >        - description: Google Kakadu (ASUS Chromebook Detachable CM3)
> >


From pr-tracker-bot at kernel.org  Fri Apr 16 17:53:07 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Fri, 16 Apr 2021 16:53:07 +0000
Subject: [GIT PULL] arm64 fix for 5.12-rc8/final
In-Reply-To: <20210416162451.GA11506@arm.com>
References: <20210416162451.GA11506@arm.com>
Message-ID: <161859198705.3799.3259163036200596055.pr-tracker-bot@kernel.org>

The pull request you sent on Fri, 16 Apr 2021 17:24:55 +0100:

> 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/06c2aac4014c38247256fe49c61b7f55890271e7

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From dietmar.eggemann at arm.com  Fri Apr 16 18:00:32 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Fri, 16 Apr 2021 19:00:32 +0200
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
 <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>
Message-ID: <2a4efeea-cc70-ca0a-81fd-84d8b54586c0@arm.com>

On 16/04/2021 13:04, Ruifeng Zhang wrote:
> Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??6:39???
>>
>> On 16/04/2021 11:32, Valentin Schneider wrote:
>>> On 16/04/21 15:47, Ruifeng Zhang wrote:

[...]

>> I'm confused. Do you have the MT bit set to 1 then? So the issue that
>> the mpidr handling in arm32's store_cpu_topology() is not correct does
>> not exist?
> 
> I have reconfirmed it, the MT bit has been set to 1. I am sorry for
> the previous messages.
> The mpidr parse by store_cpu_topology is correct, at least for the sc9863a.

Nice! This is sorted then.

[...]

>> Is this what you need for your arm32 kernel system? Adding the
>> possibility to parse cpu-map to create Phantom Domains?
> 
> Yes, I need parse DT cpu-map to create different Phantom Domains.
> With it, the dts should be change to:
>                 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>;
>                                 };
>                         };
>                 };
> 

I'm afraid that this is now a much weaker case to get this into
mainline.

I'm able to run with an extra cpu-map entry:

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 012d40a7228c..f60d9b448253 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -35,6 +35,29 @@ cpus {
                #address-cells = <1>;
                #size-cells = <0>;
 
+               cpu-map {
+                       cluster0 {
+                               core0 {
+                                       cpu = <&cpu0>;
+                               };
+                               core1 {
+                                       cpu = <&cpu1>;
+                               };
+                       };
+
+                       cluster1 {
+                               core0 {
+                                       cpu = <&cpu2>;
+                               };
+                               core1 {
+                                       cpu = <&cpu3>;
+                               };
+                               core2 {
+                                       cpu = <&cpu4>;
+                               };
+                       };
+               };
+
                cpu0: cpu at 0 {
 
a condensed version (see below) of your patch on my Arm32 TC2.
The move of update_cpu_capacity() in store_cpu_topology() is only
necessary when I use the old clock-frequency based cpu_efficiency
approach for asymmetric CPU capacity (TC2 is a15/a7):

diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index f60d9b448253..e0679cca40ed 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -64,7 +64,7 @@ cpu0: cpu at 0 {
                        reg = <0>;
                        cci-control-port = <&cci_control1>;
                        cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
-                       capacity-dmips-mhz = <1024>;
+                       clock-frequency = <1000000000>;
                        dynamic-power-coefficient = <990>;
                };
 
@@ -74,7 +74,7 @@ cpu1: cpu at 1 {
                        reg = <1>;
                        cci-control-port = <&cci_control1>;
                        cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
-                       capacity-dmips-mhz = <1024>;
+                       clock-frequency = <1000000000>;
                        dynamic-power-coefficient = <990>;
                };
 
@@ -84,7 +84,7 @@ cpu2: cpu at 2 {
                        reg = <0x100>;
                        cci-control-port = <&cci_control2>;
                        cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
-                       capacity-dmips-mhz = <516>;
+                       clock-frequency = <800000000>;
                        dynamic-power-coefficient = <133>;
                };
 
@@ -94,7 +94,7 @@ cpu3: cpu at 3 {
                        reg = <0x101>;
                        cci-control-port = <&cci_control2>;
                        cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
-                       capacity-dmips-mhz = <516>;
+                       clock-frequency = <800000000>;
                        dynamic-power-coefficient = <133>;
                };
 
@@ -104,7 +104,7 @@ cpu4: cpu at 4 {
                        reg = <0x102>;
                        cci-control-port = <&cci_control2>;
                        cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
-                       capacity-dmips-mhz = <516>;
+                       clock-frequency = <800000000>;
                        dynamic-power-coefficient = <133>;
                };



diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index ef0058de432b..bff56c12c3a6 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -82,7 +82,7 @@ static bool cap_from_dt = true;
  * 'average' CPU is of middle capacity. Also see the comments near
  * table_efficiency[] and update_cpu_capacity().
  */
-static void __init parse_dt_topology(void)
+static void __init get_coretype_capacity(void)
 {
        const struct cpu_efficiency *cpu_eff;
        struct device_node *cn = NULL;
@@ -173,7 +173,7 @@ static void update_cpu_capacity(unsigned int cpu)
 }
 
 #else
-static inline void parse_dt_topology(void) {}
+static inline void get_coretype_capacity(void) {}
 static inline void update_cpu_capacity(unsigned int cpuid) {}
 #endif
 
@@ -221,14 +221,13 @@ void store_cpu_topology(unsigned int cpuid)
                cpuid_topo->package_id = -1;
        }
 
-       update_cpu_capacity(cpuid);
-
        pr_info("CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
                cpuid, cpu_topology[cpuid].thread_id,
                cpu_topology[cpuid].core_id,
                cpu_topology[cpuid].package_id, mpidr);
 
 topology_populated:
+       update_cpu_capacity(cpuid);
        update_siblings_masks(cpuid);
 }
 
@@ -241,5 +240,6 @@ void __init init_cpu_topology(void)
        reset_cpu_topology();
        smp_wmb();
 
+       get_coretype_capacity();
        parse_dt_topology();
 }
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index de8587cc119e..a2335da28f2a 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -295,7 +295,6 @@ static void parsing_done_workfn(struct work_struct *work)
 core_initcall(free_raw_capacity);
 #endif
 
-#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
 /*
  * This function returns the logic cpu number of the node.
  * There are basically three kinds of return values:
@@ -441,7 +440,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
        return 0;
 }
 
-static int __init parse_dt_topology(void)
+int __init parse_dt_topology(void)
 {
        struct device_node *cn, *map;
        int ret = 0;
@@ -481,7 +480,6 @@ static int __init parse_dt_topology(void)
        of_node_put(cn);
        return ret;
 }
-#endif
 
 /*
  * cpu topology table
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 0f6cd6b73a61..cfa5a5072aa0 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -66,6 +66,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 #define topology_llc_cpumask(cpu)      (&cpu_topology[cpu].llc_sibling)
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
+int __init parse_dt_topology(void);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 void update_siblings_masks(unsigned int cpu);
 void remove_cpu_topology(unsigned int cpuid);


From brouer at redhat.com  Fri Apr 16 18:08:23 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Fri, 16 Apr 2021 19:08:23 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416152755.GL2531743@casper.infradead.org>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
Message-ID: <20210416190823.3b3aace0@carbon>

On Fri, 16 Apr 2021 16:27:55 +0100
Matthew Wilcox <willy at infradead.org> wrote:

> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch.  Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).  
> 
> I think this is slightly simpler, and as a bonus code that assumes the
> old layout won't compile.

This is clever, I like it!  When reading the code one just have to
remember 'unsigned long' size difference between 64-bit vs 32-bit.
And I assume compiler can optimize the sizeof check out then doable.

> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>  		};
>  		struct {	/* page_pool used by netstack */
>  			/**
> -			 * @dma_addr: might require a 64-bit value even on
> +			 * @dma_addr: might require a 64-bit value on
>  			 * 32-bit architectures.
>  			 */
> -			dma_addr_t dma_addr;
> +			unsigned long dma_addr[2];
>  		};
>  		struct {	/* slab, slob and slub */
>  			union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..db7c7020746a 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>  
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 32;
> +	return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +	page->dma_addr[0] = addr;
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		page->dma_addr[1] = addr >> 32;
>  }
>  
>  static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
>  					  struct page *page,
>  					  unsigned int dma_sync_size)
>  {
> +	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
>  	dma_sync_size = min(dma_sync_size, pool->p.max_len);
> -	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> +	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>  					 pool->p.offset, dma_sync_size,
>  					 pool->p.dma_dir);
>  }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
>  		put_page(page);
>  		return NULL;
>  	}
> -	page->dma_addr = dma;
> +	page_pool_set_dma_addr(page, dma);
>  
>  	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
>  		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
>  		 */
>  		goto skip_dma_unmap;
>  
> -	dma = page->dma_addr;
> +	dma = page_pool_get_dma_addr(page);
>  
> -	/* When page is unmapped, it cannot be returned our pool */
> +	/* When page is unmapped, it cannot be returned to our pool */
>  	dma_unmap_page_attrs(pool->p.dev, dma,
>  			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
>  			     DMA_ATTR_SKIP_CPU_SYNC);
> -	page->dma_addr = 0;
> +	page_pool_set_dma_addr(page, 0);
>  skip_dma_unmap:
>  	/* This may be the last page returned, releasing the pool, so
>  	 * it is not safe to reference pool afterwards.
> 



-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer



From madvenka at linux.microsoft.com  Fri Apr 16 18:31:55 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Fri, 16 Apr 2021 12:31:55 -0500
Subject: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210416161740.GH5560@sirena.org.uk>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <20210402032404.47239-2-madvenka@linux.microsoft.com>
 <20210416161740.GH5560@sirena.org.uk>
Message-ID: <765d0a08-d65f-162b-b20d-07a51b05d984@linux.microsoft.com>

Thanks!

Madhavan

On 4/16/21 11:17 AM, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madvenka at linux.microsoft.com wrote:
> 
>> Reliable stacktracing requires that we identify when a stacktrace is
>> terminated early. We can do this by ensuring all tasks have a final
>> frame record at a known location on their task stack, and checking
>> that this is the final frame record in the chain.
> 
> Reviewed-by: Mark Brown <broonie at kernel.org>
> 


From mathieu.poirier at linaro.org  Fri Apr 16 18:41:50 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 11:41:50 -0600
Subject: [PATCH V4 4/8] remoteproc: imx_rproc: parse fsl,auto-boot
In-Reply-To: <1618493261-32606-5-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
 <1618493261-32606-5-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210416174150.GA1050209@xps15>

On Thu, Apr 15, 2021 at 09:27:37PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Parse fsl,auto-boot to indicate whether need remoteproc framework
> auto boot or not.
> 
> When remote processor is booted before Linux Kernel up, do not parse
> fsl,auto-boot, so only need to parse the property when rproc state is
> RPROC_DETACHED.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index d633887..06dac92 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -654,6 +654,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  
>  	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
>  
> +	if (rproc->state != RPROC_DETACHED)
> +		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
> +

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  	ret = rproc_add(rproc);
>  	if (ret) {
>  		dev_err(dev, "rproc_add failed\n");
> -- 
> 2.7.4
> 


From mathieu.poirier at linaro.org  Fri Apr 16 18:44:20 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 11:44:20 -0600
Subject: [PATCH V4 5/8] remoteproc: imx_rproc: initial support for
 mutilple start/stop method
In-Reply-To: <1618493261-32606-6-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
 <1618493261-32606-6-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210416174420.GB1050209@xps15>

On Thu, Apr 15, 2021 at 09:27:38PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
> (start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).
> 
> The current SoCs supported are all using IMX_RPROC_MMIO, add a restrict
> in imx_rproc_detect_mode that only SoCs using IMX_RPROC_MMIO needs syscon
> regmap to access registers.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 51 +++++++++++++++++++++++++++++-------------
>  1 file changed, 35 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 06dac92..2b633fd 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -74,6 +74,15 @@ struct imx_rproc_att {
>  	int flags;
>  };
>  
> +/* Remote core start/stop method */
> +enum imx_rproc_method {
> +	IMX_RPROC_NONE,
> +	/* Through syscon regmap */
> +	IMX_RPROC_MMIO,
> +	/* Through ARM SMCCC */
> +	IMX_RPROC_SMC,
> +};
> +
>  struct imx_rproc_dcfg {
>  	u32				src_reg;
>  	u32				src_mask;
> @@ -81,6 +90,7 @@ struct imx_rproc_dcfg {
>  	u32				src_stop;
>  	const struct imx_rproc_att	*att;
>  	size_t				att_size;
> +	enum imx_rproc_method		method;
>  };
>  
>  struct imx_rproc {
> @@ -183,6 +193,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
>  	.src_stop	= IMX7D_M4_STOP,
>  	.att		= imx_rproc_att_imx8mq,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mq),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
> @@ -192,6 +203,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
>  	.src_stop	= IMX7D_M4_STOP,
>  	.att		= imx_rproc_att_imx7d,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7d),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
> @@ -201,6 +213,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
>  	.src_stop	= IMX6SX_M4_STOP,
>  	.att		= imx_rproc_att_imx6sx,
>  	.att_size	= ARRAY_SIZE(imx_rproc_att_imx6sx),
> +	.method		= IMX_RPROC_MMIO,
>  };
>  
>  static int imx_rproc_start(struct rproc *rproc)
> @@ -560,19 +573,35 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
>  
>  static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  {
> +	struct regmap_config config = { .name = "imx-rproc" };
>  	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
>  	struct device *dev = priv->dev;
> +	struct regmap *regmap;
>  	int ret;
>  	u32 val;
>  
> -	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
> -	if (ret) {
> -		dev_err(dev, "Failed to read src\n");
> -		return ret;
> +	if (dcfg->method != IMX_RPROC_MMIO)
> +		return 0;
> +
> +	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
> +	if (IS_ERR(regmap)) {
> +		dev_err(dev, "failed to find syscon\n");
> +		return PTR_ERR(regmap);
>  	}
>  
> -	if (!(val & dcfg->src_stop))
> -		priv->rproc->state = RPROC_DETACHED;
> +	priv->regmap = regmap;
> +	regmap_attach_dev(dev, regmap, &config);
> +
> +	if (regmap) {

This if() statement is not needed.  Moreover all the modifications in this
function should go under a IMX_RPROC_MMIO case statement in patch 7.

> +		ret = regmap_read(regmap, dcfg->src_reg, &val);
> +		if (ret) {
> +			dev_err(dev, "Failed to read src\n");
> +			return ret;
> +		}
> +
> +		if (!(val & dcfg->src_stop))
> +			priv->rproc->state = RPROC_DETACHED;
> +	}
>  
>  	return 0;
>  }
> @@ -583,18 +612,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  	struct device_node *np = dev->of_node;
>  	struct imx_rproc *priv;
>  	struct rproc *rproc;
> -	struct regmap_config config = { .name = "imx-rproc" };
>  	const struct imx_rproc_dcfg *dcfg;
> -	struct regmap *regmap;
>  	int ret;
>  
> -	regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
> -	if (IS_ERR(regmap)) {
> -		dev_err(dev, "failed to find syscon\n");
> -		return PTR_ERR(regmap);
> -	}
> -	regmap_attach_dev(dev, regmap, &config);
> -
>  	/* set some other name then imx */
>  	rproc = rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
>  			    NULL, sizeof(*priv));
> @@ -609,7 +629,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  
>  	priv = rproc->priv;
>  	priv->rproc = rproc;
> -	priv->regmap = regmap;
>  	priv->dcfg = dcfg;
>  	priv->dev = dev;
>  
> -- 
> 2.7.4
> 


From mathieu.poirier at linaro.org  Fri Apr 16 18:46:22 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 11:46:22 -0600
Subject: [PATCH V4 6/8] remoteproc: imx_rproc: make clk optional
In-Reply-To: <1618493261-32606-7-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
 <1618493261-32606-7-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210416174622.GC1050209@xps15>

On Thu, Apr 15, 2021 at 09:27:39PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> To i.MX7ULP, M4 is the master to control everything, no need to provide
> clk from Linux side. So make clk optional when method is IMX_RPROC_NONE.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 46 ++++++++++++++++++++++++++++--------------
>  1 file changed, 31 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 2b633fd..56dfcc1 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -606,6 +606,35 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  	return 0;
>  }
>  
> +static int imx_rproc_clk_enable(struct imx_rproc *priv)
> +{
> +	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> +	struct device *dev = priv->dev;
> +	int ret;
> +
> +	/* Remote core is not under control of Linux */
> +	if (dcfg->method == IMX_RPROC_NONE)
> +		return 0;
> +
> +	priv->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(priv->clk)) {
> +		dev_err(dev, "Failed to get clock\n");
> +		return PTR_ERR(priv->clk);
> +	}
> +
> +	/*
> +	 * clk for M4 block including memory. Should be
> +	 * enabled before .start for FW transfer.
> +	 */
> +	ret = clk_prepare_enable(priv->clk);
> +	if (ret) {
> +		dev_err(dev, "Failed to enable clock\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  static int imx_rproc_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -654,22 +683,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
>  	if (ret)
>  		goto err_put_mbox;
>  
> -	priv->clk = devm_clk_get(dev, NULL);
> -	if (IS_ERR(priv->clk)) {
> -		dev_err(dev, "Failed to get clock\n");
> -		ret = PTR_ERR(priv->clk);
> -		goto err_put_mbox;
> -	}
> -
> -	/*
> -	 * clk for M4 block including memory. Should be
> -	 * enabled before .start for FW transfer.
> -	 */
> -	ret = clk_prepare_enable(priv->clk);
> -	if (ret) {
> -		dev_err(&rproc->dev, "Failed to enable clock\n");
> +	ret = imx_rproc_clk_enable(priv);
> +	if (ret)

Much better

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>

>  		goto err_put_mbox;
> -	}
>  
>  	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
>  
> -- 
> 2.7.4
> 


From mathieu.poirier at linaro.org  Fri Apr 16 18:47:09 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 11:47:09 -0600
Subject: [PATCH V4 7/8] remoteproc: imx_rproc: support i.MX7ULP
In-Reply-To: <1618493261-32606-8-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
 <1618493261-32606-8-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210416174709.GD1050209@xps15>

On Thu, Apr 15, 2021 at 09:27:40PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
> and powers most serivces used by A7 core, so A7 core has no power to

s/serivces/services

> start and stop M4 core. And the M4 core's state is default RPROC_DETACHED
> and remoteproc framework not able to stop the M4 core.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/remoteproc/imx_rproc.c | 25 ++++++++++++++++++++++++-
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 56dfcc1..0592865 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -136,6 +136,14 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
>  	{ 0x40000000, 0x40000000, 0x80000000, 0 },
>  };
>  
> +static const struct imx_rproc_att imx_rproc_att_imx7ulp[] = {
> +	{0x1FFD0000, 0x1FFD0000, 0x30000, ATT_OWN},
> +	{0x20000000, 0x20000000, 0x10000, ATT_OWN},
> +	{0x2F000000, 0x2F000000, 0x20000, ATT_OWN},
> +	{0x2F020000, 0x2F020000, 0x20000, ATT_OWN},
> +	{0x60000000, 0x60000000, 0x40000000, 0}
> +};
> +
>  static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
>  	/* dev addr , sys addr  , size	    , flags */
>  	/* OCRAM_S (M4 Boot code) - alias */
> @@ -196,6 +204,12 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
>  	.method		= IMX_RPROC_MMIO,
>  };
>  
> +static const struct imx_rproc_dcfg imx_rproc_cfg_imx7ulp = {
> +	.att		= imx_rproc_att_imx7ulp,
> +	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7ulp),
> +	.method		= IMX_RPROC_NONE,
> +};
> +
>  static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
>  	.src_reg	= IMX7D_SRC_SCR,
>  	.src_mask	= IMX7D_M4_RST_MASK,
> @@ -238,6 +252,9 @@ static int imx_rproc_stop(struct rproc *rproc)
>  	struct device *dev = priv->dev;
>  	int ret;
>  
> +	if (dcfg->method == IMX_RPROC_NONE)
> +		return -EOPNOTSUPP;
> +
>  	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
>  				 dcfg->src_mask, dcfg->src_stop);
>  	if (ret)
> @@ -580,8 +597,13 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
>  	int ret;
>  	u32 val;
>  
> -	if (dcfg->method != IMX_RPROC_MMIO)
> +	switch (dcfg->method) {
> +	case IMX_RPROC_NONE:
> +		priv->rproc->state = RPROC_DETACHED;
>  		return 0;
> +	default:
> +		break;
> +	}
>  
>  	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
>  	if (IS_ERR(regmap)) {
> @@ -726,6 +748,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
>  }
>  
>  static const struct of_device_id imx_rproc_of_match[] = {
> +	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
>  	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
>  	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
>  	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
> -- 
> 2.7.4
> 


From derrick.mckee at gmail.com  Fri Apr 16 18:58:27 2021
From: derrick.mckee at gmail.com (Derrick McKee)
Date: Fri, 16 Apr 2021 13:58:27 -0400
Subject: Removed MTE function
In-Reply-To: <20210402123415.GA2830@arm.com>
References: <CAJoBWHz5GdRVnYAuvCkVxcx8qFEMnkmLToSy4Lwckg1LptHfpA@mail.gmail.com>
 <20210402123415.GA2830@arm.com>
Message-ID: <CAJoBWHwvkoTx=01FQDn6TcsFUPps_7cmjLG3nopJMdpHOJEvhw@mail.gmail.com>

On Fri, Apr 2, 2021 at 8:34 AM Catalin Marinas <catalin.marinas at arm.com> wrote:

> It was added in commit 85f49cae4dfc ("arm64: mte: add in-kernel MTE
> helpers") in 5.11 but moved out of mte.S by commit 2cb34276427a ("arm64:
> kasan: simplify and inline MTE functions") in 5.12 and renamed to
> mte_set_mem_tag_range(). Unfortunately, that commit did not delete the
> old function prototypes in mte.h. I'll clean it up next week, unless
> someone beats me to it with a patch.

Ahh, ok, thanks for the information.

> What do you need this function for? It's supposed to be used only by
> kasan, hence moved to mte-kasan.h.

I am working on a research prototype attempting to harden kernel
modules using a combination of MTE and PAC.  I'd actually be
interested in hearing how KASAN handles dynamic percpu allocations,
because that's been a challenge for me in this project.



--
Derrick McKee
Phone: (703) 957-9362
Email: derrick.mckee at gmail.com


From mathieu.poirier at linaro.org  Fri Apr 16 18:58:52 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 16 Apr 2021 11:58:52 -0600
Subject: [PATCH V4 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618493261-32606-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210416175852.GE1050209@xps15>

On Thu, Apr 15, 2021 at 09:27:33PM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> V4:
>  Typo fix 
>  patch 4: take state as a check condition
>  patch 5: move regmap lookup/attach to imx_rproc_detect_mode
>  patch 6: add imx_rproc_clk_enable for optional clk
>  patch 8: use switch/case in imx_rproc_detect_mode
> V3:
>  Add A-b tag for Patch 1/2
>  Fix the checkpatch warning for Patch 6,8
> 
> V2:
>  Patch 1/8, use fsl as vendor, typo fix
>  Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that
>  change.
> 
> This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
> parse fsl,auto-boot
>

Always specify what branch your work applies on and dependencies for it.  If
this was ready to go Bjorn would have a fun time figuring out it depends on your
other set[1].

I am done reviewing this pathset.

Mathieu 

[1] [PATCH V3 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
 
> 
> Peng Fan (8):
>   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
>   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
>   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
>   remoteproc: imx_rproc: parse fsl,auto-boot
>   remoteproc: imx_rproc: initial support for mutilple start/stop method
>   remoteproc: imx_rproc: make clk optional
>   remoteproc: imx_rproc: support i.MX7ULP
>   remoteproc: imx_rproc: support i.MX8MN/P
> 
>  .../bindings/remoteproc/fsl,imx-rproc.yaml         |  11 +-
>  drivers/remoteproc/imx_rproc.c                     | 206 +++++++++++++++++----
>  2 files changed, 179 insertions(+), 38 deletions(-)
> 
> -- 
> 2.7.4
> 


From robh at kernel.org  Fri Apr 16 19:01:18 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 13:01:18 -0500
Subject: [PATCH] Revert "ASoC: mt6359: add ASoC mt6359 ASoC accdet jack
 document"
Message-ID: <20210416180118.3662904-1-robh@kernel.org>

This reverts commit e61c589587c772c5f672b22683c3e0b38be20702.

The binding document has lots of schema errors and there's been no
effort to fix them, so let's remove it.

Cc: Argus Lin <argus.lin at mediatek.com>
Cc: Mark Brown <broonie at kernel.org>
Cc: Liam Girdwood <lgirdwood at gmail.com>
Cc: Matthias Brugger <matthias.bgg at gmail.com>
Cc: alsa-devel at alsa-project.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mediatek at lists.infradead.org
Signed-off-by: Rob Herring <robh at kernel.org>
---
 .../bindings/sound/mt6359-accdet.yaml         | 164 ------------------
 1 file changed, 164 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/mt6359-accdet.yaml

diff --git a/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml b/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml
deleted file mode 100644
index 7fb3e8dfb4c5..000000000000
--- a/Documentation/devicetree/bindings/sound/mt6359-accdet.yaml
+++ /dev/null
@@ -1,164 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/sound/mt6359-accdet.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mediatek Technologies Inc. MT6359 ASoC accdet jack driver bindings
-
-maintainers:
-  - Chipeng Chang <chipeng.chang at mediatek.com>
-
-description: |
-  This binding describes the Mediatek Technologies MT6359 ASoC
-  accdet jack driver.
-
-properties:
-  mediatek,accdet-name:
-    maxItems: 1
-    description: named as "mt6359-accdet" jack.
-
-  mediatek,mic-vol:
-    maxItems: 1
-    description: |
-      accdet micbias1 voltage.
-
-      enum:
-        - 0x00 # 1.7v - micbias1 volage is 1.7v.
-        - 0x01 # 1.8v - micbias1 volage is 1.8v.
-        - 0x02 # 1.9v - micbias1 volage is 1.9v.
-        - 0x03 # 2.0v - micbias1 volage is 2.0v.
-        - 0x04 # 2.1v - micbias1 volage is 2.1v.
-        - 0x05 # 2.5v - micbias1 volage is 2.5v.
-        - 0x06 # 2.6v - micbias1 volage is 2.6v.
-        - 0x07 # 2.7v - micbias1 volage is 2.7v.
-        - 0x08 # 2.8v - micbias1 volage is 2.8v.
-        - 0x09 # 2.85v - micbias1 volage is 2.85v.
-
-  mediatek,mic-mode:
-    maxItems: 1
-    description: |
-      value as 1, 2, 6 to indicate ACC/DCC mode. default is DCC mode 2.
-
-      enum:
-        - 0x01 # ACC - ACC mode.
-        - 0x02 # DCC - low cost without in bias.
-        - 0x06 # DCC - low cost with in bias.
-
-  mediatek,pwm-deb-setting:
-    maxItems: 15
-    description: |
-       headset-mode-setting : Indicates customized pwm, debounce setting
-       accdet pwm_width, pwm_thresh, fall_delay, rise_delay
-       debounce0, debounce1, debounce3, debounce4
-       eint pwm_width, eint pwm_thresh
-       eint deb(debounce0, debounce1, debounce2, debounce3), inv_debounce.
-
-  mediatek,eint-use-ap:
-    maxItems: 1
-    description: |
-      indicates to use ap gpio.
-
-      enum:
-        - 0x00 # MT6359 eint detection mode.
-        - 0x01 # SoC GPIO detection mode.
-
-  mediatek,eint-detect-mode:
-    maxItems: 1
-    description: |
-      indicates to use ap gpio.
-
-      enum:
-        - 0x00 # detection mode with higher detection power.
-        - 0x01 # detection mode with lower detection power.
-        - 0x02 # detection mode with sw moisture detection mode.
-        - 0x03 # detection mode with hw moisture detection mode1.
-        - 0x04 # detection mode with hw moisture detection mode2.
-
-  mediatek,eint-num:
-    maxItems: 1
-    description: |
-      incicates pmic eint usage.
-
-      enum:
-        - 0x0 # PMIC_EINT0 - use pmic eint0 to trigger plug interrupt.
-        - 0x1 # PMIC_EINT1 - use pmic eint1 to trigger plug interrupt.
-        - 0x2 # PMIC_BI_EINT - use pmic eint0/1 to trigger plug interrupt.
-
-  mediatek,eint-trig-mode:
-    maxItems: 1
-    description: |
-      incicates pmic eint trigger mode.
-
-      enum:
-        - 0x0 # PMIC_GPIO - use pmic gpio to detect plug status.
-        - 0x1 # PMIC_INVERTER - use pmic inverter to detect plug status.
-
-  mediatek,eint-use-ext-res:
-    maxItems: 1
-    description: |
-      select HP_EINT pull up resistance, default 0 use internal resistance.
-
-      enum:
-        - 0x0 # use internal resistor.
-        - 0x1 # use external resistor.
-
-  mediatek,eint-comp-vth:
-    maxItems: 1
-    description: |
-      indicates comparator detection voltage.
-
-      enum:
-        - 0x00 # 2.8v.
-        - 0x01 # 2.4v.
-        - 0x02 # 2.0v.
-        - 0x03 # 0.7v.
-
-  mediatek,key-mode:
-    maxItems: 1
-    description: |
-      incicates key mode type.
-
-      enum:
-        - 0x0 # THREE_KEY - support 3-key key mode.
-        - 0x1 # FOUR_KEY - support 4-key key mode.
-        - 0x2 # TRI_KEY_CDD - support 3-key google CDD key mode.
-
-  mediatek,three-key-thr:
-    maxItems: 4
-    description: |
-      3 key device detection threshold: 0--MD_MAX--UP_MAX--DW_MAX.
-
-  mediatek,tri-key-cdd-thr:
-    maxItems: 4
-    description: |
-      3 key CDD device detection threshold: 0--MD_MAX--UP_MAX--DW_MAX.
-
-  mediatek,four-key-thr:
-    maxItems: 4
-    description: |
-      4 key device detection threshold: 0--MD_MAX--VOICE_MAX--UP_MAX--DW_MAX.
-
-additionalProperties: false
-
-examples:
-  - |
-    accdet: accdet {
-        mediatek,accdet-name = "mt6359-accdet";
-        mediatek,mic-vol = <8>;
-        mediatek,mic-mode = <2>;
-        mediatek,pwm-deb-setting = <0x500 0x500 1 0x1f0
-                                    0x800 0x800 0x20 0x44
-                                    0x4 0x1
-                                    0x5 0x3 0x3 0x5 0xe>;
-        mediatek,eint-use-ap = <0>;
-        mediatek,eint-detect-mode = <4>;
-        mediatek,eint-num = <0>;
-        mediatek,eint-trig-mode = <1>;
-        mediatek,eint-use-ext-res = <0>;
-        mediatek,eint-comp-vth = <2>;
-        mediatek,key-mode = <0>;
-        mediatek,three-key-thr = <0 80 220 400>;
-        status = "okay";
-    };
-...
-- 
2.27.0



From jiancai at google.com  Fri Apr 16 19:14:21 2021
From: jiancai at google.com (Jian Cai)
Date: Fri, 16 Apr 2021 11:14:21 -0700
Subject: [PATCH] arm64: vdso: remove commas between macro name and arguments
Message-ID: <20210416181421.2374588-1-jiancai@google.com>

LLVM's integrated assembler does not support using commas separating
the name and arguments in .macro. However, only spaces are used in the
manual page. This replaces commas between macro names and the subsequent
arguments with space in calls to clock_gettime_return to make it
compatible with IAS.

Link:
https://sourceware.org/binutils/docs/as/Macro.html#Macro
Signed-off-by: Jian Cai <jiancai at google.com>
---
 arch/arm64/kernel/vdso/gettimeofday.S | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index 856fee6d3512..7ee685d9adfc 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -122,7 +122,7 @@ x_tmp		.req	x8
 9998:
 	.endm
 
-	.macro clock_gettime_return, shift=0
+	.macro clock_gettime_return shift=0
 	.if \shift == 1
 	lsr	x11, x11, x12
 	.endif
@@ -227,7 +227,7 @@ realtime:
 	seqcnt_check fail=realtime
 	get_ts_realtime res_sec=x10, res_nsec=x11, \
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic:
@@ -250,7 +250,7 @@ monotonic:
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic_raw:
@@ -271,7 +271,7 @@ monotonic_raw:
 		clock_nsec=x15, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 realtime_coarse:
-- 
2.31.1.368.gbe11c130af-goog



From jiancai at google.com  Fri Apr 16 19:23:53 2021
From: jiancai at google.com (Jian Cai)
Date: Fri, 16 Apr 2021 11:23:53 -0700
Subject: [PATCH] arm64: vdso: remove commas between macro name and
 arguments
In-Reply-To: <20210416181421.2374588-1-jiancai@google.com>
References: <20210416181421.2374588-1-jiancai@google.com>
Message-ID: <CA+SOCLL28Hej9zMmKJpU5vffVGviDo59uG=kWm0zPtCyZodR5g@mail.gmail.com>

I should've mentioned this patch is for 4.19 only as the code has been
rewritten in later versions, but requires a large amount of backports
(https://github.com/ClangBuiltLinux/linux/issues/1349). This is the
only blocker for 4.19 migration to LLVM's integrated assembler on CrOS
that I am aware of.

Thanks,
Jian

On Fri, Apr 16, 2021 at 11:14 AM Jian Cai <jiancai at google.com> wrote:
>
> LLVM's integrated assembler does not support using commas separating
> the name and arguments in .macro. However, only spaces are used in the
> manual page. This replaces commas between macro names and the subsequent
> arguments with space in calls to clock_gettime_return to make it
> compatible with IAS.
>
> Link:
> https://sourceware.org/binutils/docs/as/Macro.html#Macro
> Signed-off-by: Jian Cai <jiancai at google.com>
> ---
>  arch/arm64/kernel/vdso/gettimeofday.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index 856fee6d3512..7ee685d9adfc 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -122,7 +122,7 @@ x_tmp               .req    x8
>  9998:
>         .endm
>
> -       .macro clock_gettime_return, shift=0
> +       .macro clock_gettime_return shift=0
>         .if \shift == 1
>         lsr     x11, x11, x12
>         .endif
> @@ -227,7 +227,7 @@ realtime:
>         seqcnt_check fail=realtime
>         get_ts_realtime res_sec=x10, res_nsec=x11, \
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic:
> @@ -250,7 +250,7 @@ monotonic:
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic_raw:
> @@ -271,7 +271,7 @@ monotonic_raw:
>                 clock_nsec=x15, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  realtime_coarse:
> --
> 2.31.1.368.gbe11c130af-goog
>


From rentao.bupt at gmail.com  Fri Apr 16 19:25:59 2021
From: rentao.bupt at gmail.com (Tao Ren)
Date: Fri, 16 Apr 2021 11:25:59 -0700
Subject: [PATCH v2] watchdog: aspeed: fix integer overflow in set_timeout
 handler
In-Reply-To: <2771f72a-cc3c-54a5-cc2c-715ea61be6b7@roeck-us.net>
References: <20210416021337.18715-1-rentao.bupt@gmail.com>
 <2771f72a-cc3c-54a5-cc2c-715ea61be6b7@roeck-us.net>
Message-ID: <20210416182558.GA4816@taoren-ubuntu-R90MNF91>

On Thu, Apr 15, 2021 at 10:07:32PM -0700, Guenter Roeck wrote:
> On 4/15/21 7:13 PM, rentao.bupt at gmail.com wrote:
> > From: Tao Ren <rentao.bupt at gmail.com>
> > 
> > Fix the time comparison (timeout vs. max_hw_heartbeat_ms) in set_timeout
> > handler to avoid potential integer overflow when the supplied timeout is
> > greater than aspeed's maximum allowed timeout (4294 seconds).
> > 
> 
> I think this is the wrong focus: What this fixes is the wrong hardware
> timeout calculation. Again, I think that the wrong calculation leads to
> the overflow should not be the focus of this patch, though it can of
> course be mentioned.
> 
> I'll leave it up to Wim to decide if he wants to apply the patch with the
> current explanation.
> 
> Thanks,
> Guenter

Sorry I didn't get your point correctly, and I guess it was because of
my lack of knowledge in timeout/max_hw_heartbeat_ms/worker (hopefully
my understanding is correct now :))

Let me drop this patch and send a new one with different subject and
description soon.


Cheers,

Tao


From bgolaszewski at baylibre.com  Fri Apr 16 19:27:52 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Fri, 16 Apr 2021 20:27:52 +0200
Subject: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
 the code
In-Reply-To: <DM6PR02MB5386CADF5A10EF28A640AD76AF4E9@DM6PR02MB5386.namprd02.prod.outlook.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
 <20210409140806.31824-2-srinivas.neeli@xilinx.com>
 <CAHp75Vddd6ygr4mJ9Z+SuGZmfLcgDLWLZaxby2XE2mX8War-qQ@mail.gmail.com>
 <CAMpxmJW=HWf_NxGpfBkX=utgOTs4+6RtypxnKGtpuYnX=t8rGQ@mail.gmail.com>
 <DM6PR02MB5386CADF5A10EF28A640AD76AF4E9@DM6PR02MB5386.namprd02.prod.outlook.com>
Message-ID: <CAMpxmJV_CtFQpZvr_H0g3DvPMQZwqa-9z2FVxCLX=tF9Ytkj7Q@mail.gmail.com>

On Wed, Apr 14, 2021 at 4:45 PM Srinivas Neeli <sneeli at xilinx.com> wrote:
>
> HI baratosz and Andy,
>

It's Bartosz. You literally just need to copy & paste the name from my email...

> > -----Original Message-----
> > From: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > Sent: Tuesday, April 13, 2021 4:14 PM
> > To: Andy Shevchenko <andy.shevchenko at gmail.com>
> > Cc: Srinivas Neeli <sneeli at xilinx.com>; linus.walleij at linaro.org; Michal Simek
> > <michals at xilinx.com>; Shubhrajyoti Datta <shubhraj at xilinx.com>; Srinivas
> > Goud <sgoud at xilinx.com>; linux-gpio at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linux-kernel at vger.kernel.org; git
> > <git at xilinx.com>
> > Subject: Re: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
> > the code
> >
> > On Sat, Apr 10, 2021 at 12:08 AM Andy Shevchenko
> > <andy.shevchenko at gmail.com> wrote:
> > >
> > >
> > >
> > > On Friday, April 9, 2021, Srinivas Neeli <srinivas.neeli at xilinx.com> wrote:
> > >>
> > >> module_platform_driver() makes the code simpler by eliminating
> > >> boilerplate code.
> > >>
> > >> Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
> > >> ---
> > >>  drivers/gpio/gpio-zynq.c | 17 +----------------
> > >>  1 file changed, 1 insertion(+), 16 deletions(-)
> > >>
> > >> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> > >> index 3521c1dc3ac0..bb1ac0c5cf26 100644
> > >> --- a/drivers/gpio/gpio-zynq.c
> > >> +++ b/drivers/gpio/gpio-zynq.c
> > >> @@ -1020,22 +1020,7 @@ static struct platform_driver zynq_gpio_driver
> > = {
> > >>         .remove = zynq_gpio_remove,
> > >>  };
> > >>
> > >> -/**
> > >> - * zynq_gpio_init - Initial driver registration call
> > >> - *
> > >> - * Return: value from platform_driver_register
> > >> - */
> > >> -static int __init zynq_gpio_init(void) -{
> > >> -       return platform_driver_register(&zynq_gpio_driver);
> > >> -}
> > >> -postcore_initcall(zynq_gpio_init);
> > >
> > >
> > >
> > > It?s not an equivalent. Have you tested on actual hardware? If no, there is
> > no go for this change.
> > >
> >
> > Yep, this has been like this since the initial introduction of this driver.
> > Unfortunately there's no documented reason so unless we can test it, it has
> > to stay this way.
> >
> I tested driver, functionality wise everything working fine.
> Based on below conversation, I moved driver to module driver.
> https://lore.kernel.org/patchwork/patch/818202/
>

Andy: How about we give it a try then? If anyone yells, we'll just revert it.

> Thanks
> Srinivas Neeli
>
> > Bartosz

Bartosz


From broonie at kernel.org  Fri Apr 16 19:34:30 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 16 Apr 2021 19:34:30 +0100
Subject: [PATCH] Revert "ASoC: mt6359: add ASoC mt6359 ASoC accdet jack
 document"
In-Reply-To: <20210416180118.3662904-1-robh@kernel.org>
References: <20210416180118.3662904-1-robh@kernel.org>
Message-ID: <161859792866.33058.12744070673579269607.b4-ty@kernel.org>

On Fri, 16 Apr 2021 13:01:18 -0500, Rob Herring wrote:
> This reverts commit e61c589587c772c5f672b22683c3e0b38be20702.
> 
> The binding document has lots of schema errors and there's been no
> effort to fix them, so let's remove it.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] Revert "ASoC: mt6359: add ASoC mt6359 ASoC accdet jack document"
      commit: d63f2a88d5cfaad025f26e1107f3807d579654c5

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 robh at kernel.org  Fri Apr 16 19:53:01 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 13:53:01 -0500
Subject: [PATCH v8 14/15] dt-bindings: power: rockchip: Add bindings for
 RK3568 Soc
In-Reply-To: <20210416080342.18614-15-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
 <20210416080342.18614-15-jbx6244@gmail.com>
Message-ID: <20210416185301.GA3747214@robh.at.kernel.org>

On Fri, 16 Apr 2021 10:03:41 +0200, Johan Jonker wrote:
> From: Elaine Zhang <zhangqing at rock-chips.com>
> 
> Add the compatible string for RK3568 SoC.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> A note for rob+dt and others:
>   A review and ack tag was not added, because in this version
>   the schema layout changed a bit
> Please have a look at it again
> 
> Changed V8:
>   Add pd-node ref schema
> ---
>  Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 16 19:55:39 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 13:55:39 -0500
Subject: [PATCH v8 11/15] dt-bindings: arm: rockchip: convert pmu.txt to
 YAML
In-Reply-To: <20210416080342.18614-12-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
 <20210416080342.18614-12-jbx6244@gmail.com>
Message-ID: <20210416185539.GA3751624@robh.at.kernel.org>

On Fri, 16 Apr 2021 10:03:38 +0200, Johan Jonker wrote:
> Current dts files with 'pmu' nodes are manually verified.
> In order to automate this process pmu.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  .../devicetree/bindings/arm/rockchip/pmu.txt       | 16 -------
>  .../devicetree/bindings/arm/rockchip/pmu.yaml      | 49 ++++++++++++++++++++++
>  2 files changed, 49 insertions(+), 16 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 16 19:55:52 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 13:55:52 -0500
Subject: [PATCH v8 12/15] dt-bindings: arm: rockchip: add more compatible
 strings to pmu.yaml
In-Reply-To: <20210416080342.18614-13-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
 <20210416080342.18614-13-jbx6244@gmail.com>
Message-ID: <20210416185552.GA3752233@robh.at.kernel.org>

On Fri, 16 Apr 2021 10:03:39 +0200, Johan Jonker wrote:
> The compatible strings below are already in use in the Rockchip
> dtsi files, but were somehow never added to a document, so add
> 
> "rockchip,px30-pmu", "syscon", "simple-mfd"
> "rockchip,rk3288-pmu", "syscon", "simple-mfd"
> "rockchip,rk3328-pmu", "syscon", "simple-mfd"
> "rockchip,rk3399-pmu", "syscon", "simple-mfd"
> 
> for pmu nodes to pmu.yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
>  Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 16 20:05:44 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 14:05:44 -0500
Subject: [PATCH v8 13/15] dt-bindings: power: rockchip: Convert to
 json-schema
In-Reply-To: <20210416080342.18614-14-jbx6244@gmail.com>
References: <20210416080342.18614-1-jbx6244@gmail.com>
 <20210416080342.18614-14-jbx6244@gmail.com>
Message-ID: <20210416190544.GA3752460@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 10:03:40AM +0200, Johan Jonker wrote:
> From: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> 
> Convert the soc/rockchip/power_domain.txt binding document to
> json-schema and move to the power bindings directory.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Note for rob+dt:
> A tag was not added on purpose, because:
>   Add "rockchip," prefix to the qos compatible name
>   in example.
>   Changed maintainers.
>   Size reg description is reduced.
>   Little style changes '' to ""
> Please have a look at it again.
> 
> For some SoC nodes this patch serie generates notifications
> for undocumented "assigned-clocks" and "assigned-clock-parents"
> properties till there is consensus of what to do with it.
> ---
> Changed V8:
>   Add pd-node ref schema
> Changed V7:
>   Fix commit message and author format
>   Changed SPDX-License-Identifier back to GPL-2.0
>   Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
>   Fix indent example
> Changed V6:
>   Changed author
> Changed V5:
>   Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
>   Remove a maintainer
>   Changed patternProperties to power-domain
>   Add "clocks", "assigned-clocks" and "assigned-clock-parents"
> Changed V4:
>   Remove new compatible string
>   Style changes '' to ""
> Changed V3:
>   Use Enric's conversion with rk3399 example
> Changed V2:
>   Convert power_domain.txt to YAML with rk3568 example
> ---
>  .../bindings/power/rockchip,power-controller.yaml  | 257 +++++++++++++++++++++
>  .../bindings/soc/rockchip/power_domain.txt         | 136 -----------
>  2 files changed, 257 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> new file mode 100644
> index 000000000..2b9950fd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> @@ -0,0 +1,257 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip Power Domains
> +
> +maintainers:
> +  - Elaine Zhang <zhangqing at rock-chips.com>
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +description: |
> +  Rockchip processors include support for multiple power domains
> +  which can be powered up/down by software based on different
> +  application scenarios to save power.
> +
> +  Power domains contained within power-controller node are
> +  generic power domain providers documented in
> +  Documentation/devicetree/bindings/power/power-domain.yaml.
> +
> +  IP cores belonging to a power domain should contain a
> +  "power-domains" property that is a phandle for the
> +  power domain node representing the domain.
> +
> +properties:
> +  $nodename:
> +    const: power-controller
> +
> +  compatible:
> +    enum:
> +      - rockchip,px30-power-controller
> +      - rockchip,rk3036-power-controller
> +      - rockchip,rk3066-power-controller
> +      - rockchip,rk3128-power-controller
> +      - rockchip,rk3188-power-controller
> +      - rockchip,rk3228-power-controller
> +      - rockchip,rk3288-power-controller
> +      - rockchip,rk3328-power-controller
> +      - rockchip,rk3366-power-controller
> +      - rockchip,rk3368-power-controller
> +      - rockchip,rk3399-power-controller
> +
> +  "#power-domain-cells":
> +    const: 1
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^power-domain@[0-9a-f]+$":
> +    properties:
> +
> +      "#power-domain-cells":
> +        enum: [0, 1]
> +        description:
> +          Must be 0 for nodes representing a single PM domain and 1 for nodes
> +          providing multiple PM domains.

Can't this and 'required' go into pd-node?

> +
> +      "#address-cells":
> +        const: 1
> +
> +      "#size-cells":
> +        const: 0
> +
> +    $ref: "#/definitions/pd-node"

Move this and 'unevaluatedProperties' above 'properties'. It's a bit 
easier to read than trying to follow the indentation.

> +
> +    patternProperties:
> +      "^power-domain@[0-9a-f]+$":
> +        properties:
> +
> +          "#power-domain-cells":
> +            enum: [0, 1]
> +
> +          "#address-cells":
> +            const: 1
> +
> +          "#size-cells":
> +            const: 0
> +
> +        $ref: "#/definitions/pd-node"
> +
> +        patternProperties:
> +          "^power-domain@[0-9a-f]+$":
> +            properties:
> +
> +              "#power-domain-cells":
> +                const: 0

You can keep this one since it adds additional constraints.

> +
> +            $ref: "#/definitions/pd-node"
> +
> +            required:
> +              - "#power-domain-cells"
> +
> +            unevaluatedProperties: false
> +
> +        required:
> +          - "#power-domain-cells"
> +
> +        unevaluatedProperties: false
> +
> +    required:
> +      - "#power-domain-cells"
> +
> +    unevaluatedProperties: false
> +
> +required:
> +  - compatible
> +  - "#power-domain-cells"
> +
> +additionalProperties: false
> +
> +definitions:

'$defs' rather than 'definitions'. The former is in the json-schema 
spec, the latter was only convention.

> +  pd-node:
> +    type: object
> +    description: |
> +      Represents the power domains within the power controller node.
> +
> +    properties:
> +      reg:
> +        maxItems: 1
> +        description: |
> +          Power domain index. Valid values are defined in
> +          "include/dt-bindings/power/px30-power.h"
> +          "include/dt-bindings/power/rk3036-power.h"
> +          "include/dt-bindings/power/rk3066-power.h"
> +          "include/dt-bindings/power/rk3128-power.h"
> +          "include/dt-bindings/power/rk3188-power.h"
> +          "include/dt-bindings/power/rk3228-power.h"
> +          "include/dt-bindings/power/rk3288-power.h"
> +          "include/dt-bindings/power/rk3328-power.h"
> +          "include/dt-bindings/power/rk3366-power.h"
> +          "include/dt-bindings/power/rk3368-power.h"
> +          "include/dt-bindings/power/rk3399-power.h"
> +
> +      clocks:
> +        minItems: 1
> +        maxItems: 30
> +        description: |
> +          A number of phandles to clocks that need to be enabled
> +          while power domain switches state.
> +
> +      pm_qos:
> +        $ref: /schemas/types.yaml#/definitions/phandle-array
> +        description: |
> +          A number of phandles to qos blocks which need to be saved and restored
> +          while power domain switches state.
> +
> +    required:
> +      - reg
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3399-cru.h>
> +    #include <dt-bindings/power/rk3399-power.h>
> +
> +    soc {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +
> +        qos_hdcp: qos at ffa90000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffa90000 0x0 0x20>;
> +        };
> +
> +        qos_iep: qos at ffa98000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffa98000 0x0 0x20>;
> +        };
> +
> +        qos_rga_r: qos at ffab0000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab0000 0x0 0x20>;
> +        };
> +
> +        qos_rga_w: qos at ffab0080 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab0080 0x0 0x20>;
> +        };
> +
> +        qos_video_m0: qos at ffab8000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffab8000 0x0 0x20>;
> +        };
> +
> +        qos_video_m1_r: qos at ffac0000 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffac0000 0x0 0x20>;
> +        };
> +
> +        qos_video_m1_w: qos at ffac0080 {
> +            compatible = "rockchip,rk3399-qos", "syscon";
> +            reg = <0x0 0xffac0080 0x0 0x20>;
> +        };
> +
> +        power-management at ff310000 {
> +            compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
> +            reg = <0x0 0xff310000 0x0 0x1000>;
> +
> +            power-controller {
> +                compatible = "rockchip,rk3399-power-controller";
> +                #power-domain-cells = <1>;
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                /* These power domains are grouped by VD_CENTER */
> +                power-domain at RK3399_PD_IEP {
> +                    reg = <RK3399_PD_IEP>;
> +                    clocks = <&cru ACLK_IEP>,
> +                             <&cru HCLK_IEP>;
> +                    pm_qos = <&qos_iep>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_RGA {
> +                    reg = <RK3399_PD_RGA>;
> +                    clocks = <&cru ACLK_RGA>,
> +                             <&cru HCLK_RGA>;
> +                    pm_qos = <&qos_rga_r>,
> +                             <&qos_rga_w>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VCODEC {
> +                    reg = <RK3399_PD_VCODEC>;
> +                    clocks = <&cru ACLK_VCODEC>,
> +                             <&cru HCLK_VCODEC>;
> +                    pm_qos = <&qos_video_m0>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VDU {
> +                    reg = <RK3399_PD_VDU>;
> +                    clocks = <&cru ACLK_VDU>,
> +                             <&cru HCLK_VDU>;
> +                    pm_qos = <&qos_video_m1_r>,
> +                             <&qos_video_m1_w>;
> +                    #power-domain-cells = <0>;
> +                };
> +                power-domain at RK3399_PD_VIO {
> +                    reg = <RK3399_PD_VIO>;
> +                    #power-domain-cells = <1>;
> +                    #address-cells = <1>;
> +                    #size-cells = <0>;
> +
> +                    power-domain at RK3399_PD_HDCP {
> +                        reg = <RK3399_PD_HDCP>;
> +                        clocks = <&cru ACLK_HDCP>,
> +                                 <&cru HCLK_HDCP>,
> +                                 <&cru PCLK_HDCP>;
> +                        pm_qos = <&qos_hdcp>;
> +                        #power-domain-cells = <0>;
> +                    };
> +                };
> +            };
> +        };
> +    };


From robh at kernel.org  Fri Apr 16 20:06:58 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 14:06:58 -0500
Subject: [PATCH v5 30/33] dt-bindings: media: add microchip, xisc device
 bindings
In-Reply-To: <20210415184500.868264-1-eugen.hristev@microchip.com>
References: <20210415085846.824796-1-eugen.hristev@microchip.com>
 <20210415184500.868264-1-eugen.hristev@microchip.com>
Message-ID: <20210416190658.GA3769824@robh.at.kernel.org>

On Thu, 15 Apr 2021 21:45:00 +0300, Eugen Hristev wrote:
> Add bindings for the Microchip eXtended Image Sensor Controller.
> Based on the atmel,isc.yaml binding.
> 
> Signed-off-by: Eugen Hristev <eugen.hristev at microchip.com>
> ---
> Changes in v5:
> - fixed license clause to add BSD-2
> Changes in v4:
> - added '|' at description to preserve line breaks
> 
>  .../bindings/media/microchip,xisc.yaml        | 129 ++++++++++++++++++
>  1 file changed, 129 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip,xisc.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From ardb at kernel.org  Fri Apr 16 20:08:03 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Fri, 16 Apr 2021 21:08:03 +0200
Subject: [PATCH] arm64: vdso: remove commas between macro name and
 arguments
In-Reply-To: <20210416181421.2374588-1-jiancai@google.com>
References: <20210416181421.2374588-1-jiancai@google.com>
Message-ID: <CAMj1kXER9EmB4wD9SbFhJL5VHc1qJ_bDC+GhPTFdxzHAJWLT0w@mail.gmail.com>

On Fri, 16 Apr 2021 at 20:16, Jian Cai <jiancai at google.com> wrote:
>
> LLVM's integrated assembler does not support using commas separating
> the name and arguments in .macro. However, only spaces are used in the
> manual page. This replaces commas between macro names and the subsequent
> arguments with space in calls to clock_gettime_return to make it
> compatible with IAS.
>
> Link:
> https://sourceware.org/binutils/docs/as/Macro.html#Macro
> Signed-off-by: Jian Cai <jiancai at google.com>
> ---
>  arch/arm64/kernel/vdso/gettimeofday.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index 856fee6d3512..7ee685d9adfc 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -122,7 +122,7 @@ x_tmp               .req    x8
>  9998:
>         .endm
>
> -       .macro clock_gettime_return, shift=0
> +       .macro clock_gettime_return shift=0

Are you sure the definition needs to be changed as well? The majority
of GAS macros in arch/arm64 (if not all) use a comma after the
identifier, so I would prefer not to deviate from that arbitrarily.

Just look at

$ git grep -E \.macro\\s+\\S+,  arch/arm64/*.S


>         .if \shift == 1
>         lsr     x11, x11, x12
>         .endif
> @@ -227,7 +227,7 @@ realtime:
>         seqcnt_check fail=realtime
>         get_ts_realtime res_sec=x10, res_nsec=x11, \
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic:
> @@ -250,7 +250,7 @@ monotonic:
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic_raw:
> @@ -271,7 +271,7 @@ monotonic_raw:
>                 clock_nsec=x15, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  realtime_coarse:
> --
> 2.31.1.368.gbe11c130af-goog
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From robh at kernel.org  Fri Apr 16 20:12:54 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 16 Apr 2021 14:12:54 -0500
Subject: [PATCH V3] dt-bindings: mailbox: ti, secure-proxy: Convert to
 json schema
In-Reply-To: <20210416005953.17147-1-nm@ti.com>
References: <20210416005953.17147-1-nm@ti.com>
Message-ID: <20210416191254.GA3779553@robh.at.kernel.org>

On Thu, 15 Apr 2021 19:59:53 -0500, Nishanth Menon wrote:
> Convert the ti,secure-proxy to yaml for better checks and documentation.
> Differences being mostly in the examples:
> - Dropped the example usage of mailbox client, it is better done in
>   tisci node definition.
> - Switched reg usage for address-cells and size-cells 1 - aligned with
>   schema checks as well.
> - included header in example for a buildable example.
> 
> While at this, lets make sure to support upto 100 rx threads even though
> typically upto 1 threads is practically in use.
> 
> NOTE: The following checkpatch warning is generated since we do include the header
> in the example, but this is a false positive warning.
>   WARNING: DT binding docs and includes should be a separate patch. See:
>   Documentation/devicetree/bindings/submitting-patches.rst
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
> 
> Changes since v2:
>  - Subject line rewording to indicate json schema rather than yaml
>  - Review comment: Dropped "-" in interrupt-names pattern so that it will match all
>    entries
>  - Minor commit message formatting changes
> 
> V2: https://lore.kernel.org/linux-arm-kernel/20210413224535.30910-1-nm at ti.com/
> V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1-nm at ti.com/
> 
>  .../bindings/mailbox/ti,secure-proxy.txt      | 50 ------------
>  .../bindings/mailbox/ti,secure-proxy.yaml     | 79 +++++++++++++++++++
>  2 files changed, 79 insertions(+), 50 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From helgaas at kernel.org  Fri Apr 16 20:21:00 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 16 Apr 2021 14:21:00 -0500
Subject: [v9,0/7] PCI: mediatek: Add new generation controller support
In-Reply-To: <20210324030510.29177-1-jianjun.wang@mediatek.com>
Message-ID: <20210416192100.GA2745484@bjorn-Precision-5520>

On Wed, Mar 24, 2021 at 11:05:03AM +0800, Jianjun Wang wrote:
> These series patches add pcie-mediatek-gen3.c and dt-bindings file to
> support new generation PCIe controller.

Incidental: b4 doesn't work on this thread, I suspect because the
usual subject line format is:

  [PATCH v9 9/7]

instead of:

  [v9,0/7]

For b4 info, see https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst


From helgaas at kernel.org  Fri Apr 16 20:24:09 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 16 Apr 2021 14:24:09 -0500
Subject: [v9,2/7] PCI: Export pci_pio_to_address() for module use
In-Reply-To: <20210413095257.GA21802@lpieralisi>
Message-ID: <20210416192409.GA2744791@bjorn-Precision-5520>

On Tue, Apr 13, 2021 at 10:53:05AM +0100, Lorenzo Pieralisi wrote:
> On Wed, Mar 24, 2021 at 10:09:42AM +0100, Pali Roh?r wrote:
> > On Wednesday 24 March 2021 11:05:05 Jianjun Wang wrote:
> > > This interface will be used by PCI host drivers for PIO translation,
> > > export it to support compiling those drivers as kernel modules.
> > > 
> > > Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
> > > ---
> > >  drivers/pci/pci.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 16a17215f633..12bba221c9f2 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -4052,6 +4052,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> > >  
> > >  	return address;
> > >  }
> > > +EXPORT_SYMBOL(pci_pio_to_address);
> > 
> > Hello! I'm not sure if EXPORT_SYMBOL is correct because file has GPL-2.0
> > header. Should not be in this case used only EXPORT_SYMBOL_GPL? Maybe
> > other people would know what is correct?
> 
> I think this should be EXPORT_SYMBOL_GPL(), I can make this change
> but this requires Bjorn's ACK to go upstream (Bjorn, it is my fault,
> it was assigned to me on patchwork, now updated, please have a look).

Yep, looks good to me, and I agree it should be EXPORT_SYMBOL_GPL().

Acked-by: Bjorn Helgaas <bhelgaas at google.com>

> > >  
> > >  unsigned long __weak pci_address_to_pio(phys_addr_t address)
> > >  {
> > > -- 
> > > 2.25.1
> > > 


From asutoshd at codeaurora.org  Fri Apr 16 20:49:24 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Fri, 16 Apr 2021 12:49:24 -0700
Subject: [PATCH v20 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1618600985.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v19 -> v20:
- Addressed Adrian's comments
- Addressed Bart's comments

v18 -> v19:
- Addressed Adrian's comments
- Fixed smatch warnings

v17 -> v18:
- Addressed Adrian's comments

v16 -> v17:
- Addressed Adrian's & Daejun's comments

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing


Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  24 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 719 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 592 insertions(+), 264 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Fri Apr 16 20:49:25 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Fri, 16 Apr 2021 12:49:25 -0700
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1618600985.git.asutoshd@codeaurora.org>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
Message-ID: <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes. This also registers a new scsi driver for rpmb wlun.
This new driver is mostly used to clear rpmb uac.

Fixed smatch warnings:
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 719 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  21 ++
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 580 insertions(+), 252 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..908ff39 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..ec4589a 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..4e1ff20 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..8b31efb 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..a473349 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..4862a7b 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..6651b87 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..39bf204 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			ufshcd_rpm_put_sync(hba);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..eb36f753 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN);
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN);
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4098,12 +4112,13 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	}
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
-	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+	if (update &&
+	    !pm_runtime_suspended(&hba->sdev_ufs_device->sdev_gendev)) {
+		ufshcd_rpm_get_sync(hba);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		ufshcd_rpm_put_sync(hba);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4816,43 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			ufshcd_rpm_put(hba);
+			return;
+		}
+	} else {
+		/*
+		 * Device wlun is probed. The assumption is that WLUNs are
+		 * scanned before other LUNs.
+		 */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4883,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4916,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5038,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5639,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
+	ufshcd_rpm_put_sync(hba);
 }
 
 /**
@@ -5604,7 +5657,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5673,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5797,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	ufshcd_rpm_get_sync(hba);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	ufshcd_rpm_put(hba);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
@@ -5815,14 +5860,18 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
+
+	/* hba device might have a runtime error otherwise */
+	if (ret)
+		ret = pm_runtime_set_active(hba->dev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7295,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7458,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7938,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8524,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8700,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8708,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8731,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto vops_suspend;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8753,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8781,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8794,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
+vops_suspend:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8803,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8827,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
-
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
-
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
-
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8861,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,42 +8909,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
-
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	down(&hba->host_sem);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret) {
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+		up(&hba->host_sem);
+	}
+
+out:
+	if (!ret)
+		hba->is_sys_suspended = true;
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+out:
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+	if (!ret)
+		hba->is_sys_suspended = false;
+	up(&hba->host_sem);
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	ufshcd_rpm_get_sync(hba);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static int ufshcd_suspend(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
-	ufshcd_setup_clocks(hba, false);
+	ret = ufshcd_setup_clocks(hba, false);
+	if (ret) {
+		ufshcd_enable_irq(hba);
+		return ret;
+	}
 	if (ufshcd_is_clkgating_allowed(hba)) {
 		hba->clk_gating.state = CLKS_OFF;
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	return ret;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
-	hba->pm_op_in_progress = 0;
 	if (ret)
 		ufshcd_update_evt_hist(hba, UFS_EVT_RESUME_ERR, (u32)ret);
 	return ret;
@@ -8962,6 +9132,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8970,41 +9141,14 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	down(&hba->host_sem);
-
-	if (!hba->is_powered)
-		return 0;
-
-	if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
-	     hba->curr_dev_pwr_mode) &&
-	    (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-	     hba->uic_link_state) &&
-	     !hba->dev_info.b_rpm_dev_flush_capable)
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ret = ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = true;
-	else
-		up(&hba->host_sem);
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_suspend);
@@ -9021,21 +9165,16 @@ int ufshcd_system_resume(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+
+	ret = ufshcd_resume(hba);
+
 out:
 	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
-	up(&hba->host_sem);
+
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
@@ -9045,19 +9184,17 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_suspend(hba);
+
 	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9069,33 +9206,19 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_resume(hba);
+
 	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9113,30 +9236,20 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
-	if (!hba->is_powered)
-		goto out;
-
 	if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
 		goto out;
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9263,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		ufshcd_rpm_get_sync(hba);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9568,203 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	ufshcd_rpm_put(hba);
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	struct device *ufs_dev = &hba->sdev_ufs_device->sdev_gendev;
+	enum ufs_dev_pwr_mode spm_pwr_mode;
+	enum uic_link_state spm_link_state;
+	unsigned long flags;
+	bool rpm_state_ok;
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * The rpm-lvl and spm-lvl can be different in ufs.
+	 * However, if the current_{pwr_mode, link_state} is same as the
+	 * desired_{pwr_mode, link_state}, there's no need to rpm resume
+	 * the device.
+	 * Refer ufshcd_resume_complete()
+	 */
+	pm_runtime_get_noresume(ufs_dev);
+
+	spin_lock_irqsave(&ufs_dev->power.lock, flags);
+
+	spm_pwr_mode = ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl);
+	spm_link_state = ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl);
+
+	rpm_state_ok = pm_runtime_suspended(ufs_dev) &&
+		hba->curr_dev_pwr_mode == spm_pwr_mode &&
+		hba->uic_link_state == spm_link_state &&
+		!hba->dev_info.b_rpm_dev_flush_capable;
+
+	spin_unlock_irqrestore(&ufs_dev->power.lock, flags);
+
+	if (!rpm_state_ok) {
+		int ret = pm_runtime_resume(ufs_dev);
+
+		if (ret < 0 && ret != -EACCES) {
+			pm_runtime_put(ufs_dev);
+			return ret;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba = shost_priv(sdev->host);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_runtime_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
+		return ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
-	return 0;
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret)
+		goto debugfs_exit;
+
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret)
+		goto unregister;
+
+	return ret;
+unregister:
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+debugfs_exit:
+	ufs_debugfs_exit();
+	return ret;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..3a8dc0d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,7 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1109,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
@@ -1309,4 +1315,19 @@ static inline int ufshcd_update_ee_usr_mask(struct ufs_hba *hba,
 					&hba->ee_drv_mask, set, clr);
 }
 
+static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_put_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+}
+
 #endif /* End of Header */
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From jiancai at google.com  Fri Apr 16 21:35:21 2021
From: jiancai at google.com (Jian Cai)
Date: Fri, 16 Apr 2021 13:35:21 -0700
Subject: [PATCH v2] arm64: vdso: remove commas between macro name and arguments
In-Reply-To: <20210416181421.2374588-1-jiancai@google.com>
References: <20210416181421.2374588-1-jiancai@google.com>
Message-ID: <20210416203522.2397801-1-jiancai@google.com>

LLVM's integrated assembler does not support using commas separating
the name and arguments in .macro. However, only spaces are used in the
manual page. This replaces commas between macro names and the subsequent
arguments with space in calls to clock_gettime_return to make it
compatible with IAS.

Link:
https://sourceware.org/binutils/docs/as/Macro.html#Macro
https://github.com/ClangBuiltLinux/linux/issues/1349

Suggested-by: Ard Biesheuvel <ardb at kernel.org>
Signed-off-by: Jian Cai <jiancai at google.com>
---

Changes v1 -> v2:
  Keep the comma in the macro definition to be consistent with other
  definitions.

 arch/arm64/kernel/vdso/gettimeofday.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index 856fee6d3512..b6faf8b5d1fe 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -227,7 +227,7 @@ realtime:
 	seqcnt_check fail=realtime
 	get_ts_realtime res_sec=x10, res_nsec=x11, \
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic:
@@ -250,7 +250,7 @@ monotonic:
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic_raw:
@@ -271,7 +271,7 @@ monotonic_raw:
 		clock_nsec=x15, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 realtime_coarse:
-- 
2.31.1.368.gbe11c130af-goog



From kuba at kernel.org  Fri Apr 16 22:22:44 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 16 Apr 2021 14:22:44 -0700
Subject: [PATCH net-next 03/10] net: sparx5: add hostmode with phylink
 support
In-Reply-To: <20210416131657.3151464-4-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
 <20210416131657.3151464-4-steen.hegelund@microchip.com>
Message-ID: <20210416142244.244656a8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, 16 Apr 2021 15:16:50 +0200 Steen Hegelund wrote:
> +static int sparx5_set_mac_address(struct net_device *dev, void *p)
> +{
> +	const struct sockaddr *addr = p;
> +
> +	/* Record the address */
> +	ether_addr_copy(dev->dev_addr, addr->sa_data);

I think you need to validate that add is a valid ethernet address.
is_valid_ether_addr()

> +struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno)
> +{
> +	struct sparx5_port *spx5_port;
> +	struct net_device *ndev;
> +	u64 val;
> +
> +	ndev = devm_alloc_etherdev(sparx5->dev, sizeof(struct sparx5_port));
> +	if (!ndev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	SET_NETDEV_DEV(ndev, sparx5->dev);
> +	spx5_port = netdev_priv(ndev);
> +	spx5_port->ndev = ndev;
> +	spx5_port->sparx5 = sparx5;
> +	spx5_port->portno = portno;
> +	sparx5_set_port_ifh(spx5_port->ifh, portno);
> +	snprintf(ndev->name, IFNAMSIZ, "eth%d", portno);

Please don't try to name interfaces in the kernel.


From kuba at kernel.org  Fri Apr 16 22:26:13 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Fri, 16 Apr 2021 14:26:13 -0700
Subject: [PATCH net-next 09/10] net: sparx5: add ethtool configuration
 and statistics support
In-Reply-To: <20210416131657.3151464-10-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
 <20210416131657.3151464-10-steen.hegelund@microchip.com>
Message-ID: <20210416142613.7307cbc0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, 16 Apr 2021 15:16:56 +0200 Steen Hegelund wrote:
> +	"rx_in_bytes",
> +	"rx_symbol_err",
> +	"rx_pause",
> +	"rx_unsup_opcode",
> +	"rx_ok_bytes",
> +	"rx_bad_bytes",
> +	"rx_unicast",
> +	"rx_multicast",
> +	"rx_broadcast",
> +	"rx_crc_err",
> +	"rx_undersize",
> +	"rx_fragments",
> +	"rx_inrangelen_err",
> +	"rx_outofrangelen_err",
> +	"rx_oversize",
> +	"rx_jabbers",
> +	"rx_size64",
> +	"rx_size65_127",
> +	"rx_size128_255",
> +	"rx_size256_511",
> +	"rx_size512_1023",
> +	"rx_size1024_1518",
> +	"rx_size1519_max",
> +	"pmac_rx_symbol_err",
> +	"pmac_rx_pause",
> +	"pmac_rx_unsup_opcode",
> +	"pmac_rx_ok_bytes",
> +	"pmac_rx_bad_bytes",
> +	"pmac_rx_unicast",
> +	"pmac_rx_multicast",
> +	"pmac_rx_broadcast",
> +	"pmac_rx_crc_err",
> +	"pmac_rx_undersize",
> +	"pmac_rx_fragments",
> +	"pmac_rx_inrangelen_err",
> +	"pmac_rx_outofrangelen_err",
> +	"pmac_rx_oversize",
> +	"pmac_rx_jabbers",
> +	"pmac_rx_size64",
> +	"pmac_rx_size65_127",
> +	"pmac_rx_size128_255",
> +	"pmac_rx_size256_511",
> +	"pmac_rx_size512_1023",
> +	"pmac_rx_size1024_1518",
> +	"pmac_rx_size1519_max",

> +	"rx_local_drop",
> +	"rx_port_policer_drop",
> +	"tx_out_bytes",
> +	"tx_pause",
> +	"tx_ok_bytes",
> +	"tx_unicast",
> +	"tx_multicast",
> +	"tx_broadcast",
> +	"tx_size64",
> +	"tx_size65_127",
> +	"tx_size128_255",
> +	"tx_size256_511",
> +	"tx_size512_1023",
> +	"tx_size1024_1518",
> +	"tx_size1519_max",
> +	"tx_multi_coll",
> +	"tx_late_coll",
> +	"tx_xcoll",
> +	"tx_defer",
> +	"tx_xdefer",
> +	"tx_backoff1",
> +	"pmac_tx_pause",
> +	"pmac_tx_ok_bytes",
> +	"pmac_tx_unicast",
> +	"pmac_tx_multicast",
> +	"pmac_tx_broadcast",
> +	"pmac_tx_size64",
> +	"pmac_tx_size65_127",
> +	"pmac_tx_size128_255",
> +	"pmac_tx_size256_511",
> +	"pmac_tx_size512_1023",
> +	"pmac_tx_size1024_1518",
> +	"pmac_tx_size1519_max",

Please see 

https://patchwork.kernel.org/project/netdevbpf/list/?series=468795

(hopefully to be merged by the end of the week) and earlier patches for
pause and FEC stats. Anything that has a standardized interface is off
limits for the random ethtool -S grab bag.


From ardb at kernel.org  Fri Apr 16 22:40:15 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Fri, 16 Apr 2021 23:40:15 +0200
Subject: [PATCH v2] arm64: vdso: remove commas between macro name and
 arguments
In-Reply-To: <20210416203522.2397801-1-jiancai@google.com>
References: <20210416181421.2374588-1-jiancai@google.com>
 <20210416203522.2397801-1-jiancai@google.com>
Message-ID: <CAMj1kXEBR7MMiXyOEHO+si1Fp7ZfzqFD-ks-tS=_3ncw_RmKVg@mail.gmail.com>

On Fri, 16 Apr 2021 at 22:35, Jian Cai <jiancai at google.com> wrote:
>
> LLVM's integrated assembler does not support using commas separating
> the name and arguments in .macro. However, only spaces are used in the
> manual page. This replaces commas between macro names and the subsequent
> arguments with space in calls to clock_gettime_return to make it
> compatible with IAS.
>
> Link:
> https://sourceware.org/binutils/docs/as/Macro.html#Macro
> https://github.com/ClangBuiltLinux/linux/issues/1349
>
> Suggested-by: Ard Biesheuvel <ardb at kernel.org>

Please remove this tag - the only thing I suggested was to drop part
of the original patch.


> Signed-off-by: Jian Cai <jiancai at google.com>
> ---
>
> Changes v1 -> v2:
>   Keep the comma in the macro definition to be consistent with other
>   definitions.
>
>  arch/arm64/kernel/vdso/gettimeofday.S | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index 856fee6d3512..b6faf8b5d1fe 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -227,7 +227,7 @@ realtime:
>         seqcnt_check fail=realtime
>         get_ts_realtime res_sec=x10, res_nsec=x11, \
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic:
> @@ -250,7 +250,7 @@ monotonic:
>                 clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  monotonic_raw:
> @@ -271,7 +271,7 @@ monotonic_raw:
>                 clock_nsec=x15, nsec_to_sec=x9
>
>         add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
> -       clock_gettime_return, shift=1
> +       clock_gettime_return shift=1
>
>         ALIGN
>  realtime_coarse:
> --
> 2.31.1.368.gbe11c130af-goog
>


From irogers at google.com  Fri Apr 16 22:41:13 2021
From: irogers at google.com (Ian Rogers)
Date: Fri, 16 Apr 2021 14:41:13 -0700
Subject: [PATCH] perf arm64: Fix off-by-one directory paths.
Message-ID: <20210416214113.552252-1-irogers@google.com>

Relative path include works in the regular build due to -I paths but may
break in other situations.

Signed-off-by: Ian Rogers <irogers at google.com>
---
 tools/perf/arch/arm64/util/kvm-stat.c         | 4 ++--
 tools/perf/arch/arm64/util/pmu.c              | 4 ++--
 tools/perf/arch/arm64/util/unwind-libunwind.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/perf/arch/arm64/util/kvm-stat.c b/tools/perf/arch/arm64/util/kvm-stat.c
index 50376b9062c1..2303256b7d05 100644
--- a/tools/perf/arch/arm64/util/kvm-stat.c
+++ b/tools/perf/arch/arm64/util/kvm-stat.c
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0
 #include <errno.h>
 #include <memory.h>
-#include "../../util/evsel.h"
-#include "../../util/kvm-stat.h"
+#include "../../../util/evsel.h"
+#include "../../../util/kvm-stat.h"
 #include "arm64_exception_types.h"
 #include "debug.h"
 
diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
index d3259d61ca75..2234fbd0a912 100644
--- a/tools/perf/arch/arm64/util/pmu.c
+++ b/tools/perf/arch/arm64/util/pmu.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
-#include "../../util/cpumap.h"
-#include "../../util/pmu.h"
+#include "../../../util/cpumap.h"
+#include "../../../util/pmu.h"
 
 struct pmu_events_map *pmu_events_map__find(void)
 {
diff --git a/tools/perf/arch/arm64/util/unwind-libunwind.c b/tools/perf/arch/arm64/util/unwind-libunwind.c
index 1495a9523a23..5aecf88e3de6 100644
--- a/tools/perf/arch/arm64/util/unwind-libunwind.c
+++ b/tools/perf/arch/arm64/util/unwind-libunwind.c
@@ -4,9 +4,9 @@
 #ifndef REMOTE_UNWIND_LIBUNWIND
 #include <libunwind.h>
 #include "perf_regs.h"
-#include "../../util/unwind.h"
+#include "../../../util/unwind.h"
 #endif
-#include "../../util/debug.h"
+#include "../../../util/debug.h"
 
 int LIBUNWIND__ARCH_REG_ID(int regnum)
 {
-- 
2.31.1.368.gbe11c130af-goog



From nm at ti.com  Fri Apr 16 23:25:18 2021
From: nm at ti.com (Nishanth Menon)
Date: Fri, 16 Apr 2021 17:25:18 -0500
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,
 optee-tz to json schema
Message-ID: <20210416222518.15801-1-nm@ti.com>

Convert linaro,optee-tz to json schema format for better documentation
and error checks.

NOTE:
1. This change does introduce a stricter naming convention for
   optee nodes.
2. We do have false positive checkpatch warning with this patch:
   "DT binding docs and includes should be a separate patch"

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ----------
 .../arm/firmware/linaro,optee-tz.yaml         | 62 +++++++++++++++++++
 2 files changed, 62 insertions(+), 31 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml

diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
deleted file mode 100644
index d38834c67dff..000000000000
--- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OP-TEE Device Tree Bindings
-
-OP-TEE is a piece of software using hardware features to provide a Trusted
-Execution Environment. The security can be provided with ARM TrustZone, but
-also by virtualization or a separate chip.
-
-We're using "linaro" as the first part of the compatible property for
-the reference implementation maintained by Linaro.
-
-* OP-TEE based on ARM TrustZone required properties:
-
-- compatible     : should contain "linaro,optee-tz"
-
-- method         : The method of calling the OP-TEE Trusted OS. Permitted
-                   values are:
-
-                   "smc" : SMC #0, with the register assignments specified
-		           in drivers/tee/optee/optee_smc.h
-
-                   "hvc" : HVC #0, with the register assignments specified
-		           in drivers/tee/optee/optee_smc.h
-
-
-
-Example:
-	firmware {
-		optee {
-			compatible = "linaro,optee-tz";
-			method = "smc";
-		};
-	};
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
new file mode 100644
index 000000000000..6513b5ac8b2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OP-TEE Device Tree Bindings
+
+maintainers:
+  - Jens Wiklander <jens.wiklander at linaro.org>
+
+description: |
+  OP-TEE is a piece of software using hardware features to provide a Trusted
+  Execution Environment. The security can be provided with ARM TrustZone, but
+  also by virtualization or a separate chip.
+
+  We're using "linaro" as the first part of the compatible property for
+  the reference implementation maintained by Linaro.
+
+properties:
+  $nodename:
+    const: 'optee'
+
+  compatible:
+    const: linaro,optee-tz
+
+  method:
+    description: The method of calling the OP-TEE Trusted OS.
+    oneOf:
+      - description: |
+          SMC #0, with the register assignments specified
+          in drivers/tee/optee/optee_smc.h
+        items:
+          - const: smc
+      - description: |
+          HVC #0, with the register assignments specified
+          in drivers/tee/optee/optee_smc.h
+        items:
+          - const: hvc
+
+required:
+  - compatible
+  - method
+
+additionalProperties: false
+
+examples:
+  - |
+    firmware  {
+        optee  {
+            compatible = "linaro,optee-tz";
+            method = "smc";
+        };
+    };
+
+  - |
+    firmware  {
+        optee  {
+            compatible = "linaro,optee-tz";
+            method = "hvc";
+        };
+    };
-- 
2.31.0



From patchwork-bot+netdevbpf at kernel.org  Fri Apr 16 23:30:12 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Fri, 16 Apr 2021 22:30:12 +0000
Subject: [PATCH net-next,
 v3] net: ethernet: mediatek: ppe: fix busy wait loop
In-Reply-To: <20210416003747.340041-1-ilya.lipnitskiy@gmail.com>
References: <20210416003747.340041-1-ilya.lipnitskiy@gmail.com>
Message-ID: <161861221238.19916.9391393406931701740.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Thu, 15 Apr 2021 17:37:48 -0700 you wrote:
> The intention is for the loop to timeout if the body does not succeed.
> The current logic calls time_is_before_jiffies(timeout) which is false
> until after the timeout, so the loop body never executes.
> 
> Fix by using readl_poll_timeout as a more standard and less error-prone
> solution.
> 
> [...]

Here is the summary with links:
  - [net-next,v3] net: ethernet: mediatek: ppe: fix busy wait loop
    https://git.kernel.org/netdev/net-next/c/c5d66587b890

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From alexandre.belloni at bootlin.com  Sat Apr 17 00:04:42 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Sat, 17 Apr 2021 01:04:42 +0200
Subject: [PATCH] rtc: st-lpc: move to use request_irq by IRQF_NO_AUTOEN
 flag
In-Reply-To: <1617761937-58318-1-git-send-email-tiantao6@hisilicon.com>
References: <1617761937-58318-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <161861427504.875812.2882489673201893898.b4-ty@bootlin.com>

On Wed, 7 Apr 2021 10:18:57 +0800, Tian Tao wrote:
> disable_irq() after request_irq() still has a time gap in which
> interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
> disable IRQ auto-enable because of requesting.
> 
> this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
> is being merged: https://lore.kernel.org/patchwork/patch/1388765/

Applied, thanks!

[1/1] rtc: st-lpc: move to use request_irq by IRQF_NO_AUTOEN flag
      commit: 81a0eaf28af6bcf925cee63ba5f6ab4d73c1d072

Best regards,
-- 
Alexandre Belloni <alexandre.belloni at bootlin.com>


From willy at infradead.org  Sat Apr 17 00:07:22 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Sat, 17 Apr 2021 00:07:22 +0100
Subject: [PATCH 0/2] Change struct page layout for page_pool
Message-ID: <20210416230724.2519198-1-willy@infradead.org>

The first patch here fixes two bugs on ppc32, and mips32.  It fixes one
bug on arc and arm32 (in certain configurations).  It probably makes
sense to get it in ASAP through the networking tree.  I'd like to see
testing on those four architectures if possible?

The second patch enables new functionality.  It is much less urgent.
I'd really like to see Mel & Michal's thoughts on it.

I have only compile-tested these patches.

Matthew Wilcox (Oracle) (2):
  mm: Fix struct page layout on 32-bit systems
  mm: Indicate pfmemalloc pages in compound_head

 include/linux/mm.h       | 12 +++++++-----
 include/linux/mm_types.h |  9 ++++-----
 include/net/page_pool.h  | 12 +++++++++++-
 net/core/page_pool.c     | 12 +++++++-----
 4 files changed, 29 insertions(+), 16 deletions(-)

-- 
2.30.2



From willy at infradead.org  Sat Apr 17 00:07:23 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Sat, 17 Apr 2021 00:07:23 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416230724.2519198-1-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
Message-ID: <20210416230724.2519198-2-willy@infradead.org>

32-bit architectures which expect 8-byte alignment for 8-byte integers
and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
page inadvertently expanded in 2019.  When the dma_addr_t was added,
it forced the alignment of the union to 8 bytes, which inserted a 4 byte
gap between 'flags' and the union.

Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
This restores the alignment to that of an unsigned long, and also fixes a
potential problem where (on a big endian platform), the bit used to denote
PageTail could inadvertently get set, and a racing get_user_pages_fast()
could dereference a bogus compound_head().

Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 include/linux/mm_types.h |  4 ++--
 include/net/page_pool.h  | 12 +++++++++++-
 net/core/page_pool.c     | 12 +++++++-----
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..5aacc1c10a45 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -97,10 +97,10 @@ struct page {
 		};
 		struct {	/* page_pool used by netstack */
 			/**
-			 * @dma_addr: might require a 64-bit value even on
+			 * @dma_addr: might require a 64-bit value on
 			 * 32-bit architectures.
 			 */
-			dma_addr_t dma_addr;
+			unsigned long dma_addr[2];
 		};
 		struct {	/* slab, slob and slub */
 			union {
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b5b195305346..db7c7020746a 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
 
 static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
 {
-	return page->dma_addr;
+	dma_addr_t ret = page->dma_addr[0];
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		ret |= (dma_addr_t)page->dma_addr[1] << 32;
+	return ret;
+}
+
+static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
+{
+	page->dma_addr[0] = addr;
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		page->dma_addr[1] = addr >> 32;
 }
 
 static inline bool is_page_pool_compiled_in(void)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index ad8b0707af04..f014fd8c19a6 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
 					  struct page *page,
 					  unsigned int dma_sync_size)
 {
+	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
+
 	dma_sync_size = min(dma_sync_size, pool->p.max_len);
-	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
+	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
 					 pool->p.offset, dma_sync_size,
 					 pool->p.dma_dir);
 }
@@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
 		put_page(page);
 		return NULL;
 	}
-	page->dma_addr = dma;
+	page_pool_set_dma_addr(page, dma);
 
 	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
 		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
@@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
 		 */
 		goto skip_dma_unmap;
 
-	dma = page->dma_addr;
+	dma = page_pool_get_dma_addr(page);
 
-	/* When page is unmapped, it cannot be returned our pool */
+	/* When page is unmapped, it cannot be returned to our pool */
 	dma_unmap_page_attrs(pool->p.dev, dma,
 			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
 			     DMA_ATTR_SKIP_CPU_SYNC);
-	page->dma_addr = 0;
+	page_pool_set_dma_addr(page, 0);
 skip_dma_unmap:
 	/* This may be the last page returned, releasing the pool, so
 	 * it is not safe to reference pool afterwards.
-- 
2.30.2



From wsa at kernel.org  Sat Apr 17 00:07:45 2021
From: wsa at kernel.org (Wolfram Sang)
Date: Sat, 17 Apr 2021 01:07:45 +0200
Subject: [PATCH 1/2] i2c: s3c2410: simplify getting of_device_id match data
In-Reply-To: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
References: <20210415093803.162673-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210416230745.GB2680@kunai>

On Thu, Apr 15, 2021 at 11:38:02AM +0200, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.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/20210417/d63ca10a/attachment-0001.sig>

From willy at infradead.org  Sat Apr 17 00:07:24 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Sat, 17 Apr 2021 00:07:24 +0100
Subject: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
In-Reply-To: <20210416230724.2519198-1-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
Message-ID: <20210416230724.2519198-3-willy@infradead.org>

The net page_pool wants to use a magic value to identify page pool pages.
The best place to put it is in the first word where it can be clearly a
non-pointer value.  That means shifting dma_addr up to alias with ->index,
which means we need to find another way to indicate page_is_pfmemalloc().
Since page_pool doesn't want to set its magic value on pages which are
pfmemalloc, we can use bit 1 of compound_head to indicate that the page
came from the memory reserves.

Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 include/linux/mm.h       | 12 +++++++-----
 include/linux/mm_types.h |  7 +++----
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ba434287387..44eab3f6d5ae 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1629,10 +1629,12 @@ struct address_space *page_mapping_file(struct page *page);
 static inline bool page_is_pfmemalloc(const struct page *page)
 {
 	/*
-	 * Page index cannot be this large so this must be
-	 * a pfmemalloc page.
+	 * This is not a tail page; compound_head of a head page is unused
+	 * at return from the page allocator, and will be overwritten
+	 * by callers who do not care whether the page came from the
+	 * reserves.
 	 */
-	return page->index == -1UL;
+	return page->compound_head & 2;
 }
 
 /*
@@ -1641,12 +1643,12 @@ static inline bool page_is_pfmemalloc(const struct page *page)
  */
 static inline void set_page_pfmemalloc(struct page *page)
 {
-	page->index = -1UL;
+	page->compound_head = 2;
 }
 
 static inline void clear_page_pfmemalloc(struct page *page)
 {
-	page->index = 0;
+	page->compound_head = 0;
 }
 
 /*
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5aacc1c10a45..39f7163dcace 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -96,10 +96,9 @@ struct page {
 			unsigned long private;
 		};
 		struct {	/* page_pool used by netstack */
-			/**
-			 * @dma_addr: might require a 64-bit value on
-			 * 32-bit architectures.
-			 */
+			unsigned long pp_magic;
+			unsigned long xmi;
+			unsigned long _pp_mapping_pad;
 			unsigned long dma_addr[2];
 		};
 		struct {	/* slab, slob and slub */
-- 
2.30.2



From jiancai at google.com  Sat Apr 17 00:23:41 2021
From: jiancai at google.com (Jian Cai)
Date: Fri, 16 Apr 2021 16:23:41 -0700
Subject: [PATCH v3] arm64: vdso: remove commas between macro name and arguments
In-Reply-To: <20210416203522.2397801-1-jiancai@google.com>
References: <20210416203522.2397801-1-jiancai@google.com>
Message-ID: <20210416232341.2421342-1-jiancai@google.com>

LLVM's integrated assembler does not support using commas separating
the name and arguments in .macro. However, only spaces are used in the
manual page. This replaces commas between macro names and the subsequent
arguments with space in calls to clock_gettime_return to make it
compatible with IAS.

Link:
https://sourceware.org/binutils/docs/as/Macro.html#Macro
https://github.com/ClangBuiltLinux/linux/issues/1349

Signed-off-by: Jian Cai <jiancai at google.com>
---

Changes v1 -> v2:
  Keep the comma in the macro definition to be consistent with other
  definitions.

Changes v2 -> v3:
  Edit tags.

 arch/arm64/kernel/vdso/gettimeofday.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index 856fee6d3512..b6faf8b5d1fe 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -227,7 +227,7 @@ realtime:
 	seqcnt_check fail=realtime
 	get_ts_realtime res_sec=x10, res_nsec=x11, \
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic:
@@ -250,7 +250,7 @@ monotonic:
 		clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x3, ts_nsec=x4, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 monotonic_raw:
@@ -271,7 +271,7 @@ monotonic_raw:
 		clock_nsec=x15, nsec_to_sec=x9
 
 	add_ts sec=x10, nsec=x11, ts_sec=x13, ts_nsec=x14, nsec_to_sec=x9
-	clock_gettime_return, shift=1
+	clock_gettime_return shift=1
 
 	ALIGN
 realtime_coarse:
-- 
2.31.1.368.gbe11c130af-goog



From olteanv at gmail.com  Sat Apr 17 00:42:20 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:20 +0300
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
Message-ID: <20210416234225.3715819-1-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

This patch series contains logic for enabling the lossless mode on the
RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
memory.

During testing it was found that, with the default FIFO configuration,
a sender which isn't persuaded by our PAUSE frames and keeps sending
will cause some MAC RX frame errors. To mitigate this, we need to ensure
that the FIFO never runs completely full, so we need to fix up a setting
that was supposed to be configured well out of reset. Unfortunately this
requires the addition of a new mini-driver.

Vladimir Oltean (5):
  net: enetc: create a common enetc_pf_to_port helper
  dt-bindings: net: fsl: enetc: add the IERB documentation
  net: enetc: add a mini driver for the Integrated Endpoint Register
    Block
  arm64: dts: ls1028a: declare the Integrated Endpoint Register Block
    node
  net: enetc: add support for flow control

 .../devicetree/bindings/net/fsl-enetc.txt     |  15 ++
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi |   6 +
 drivers/net/ethernet/freescale/enetc/Kconfig  |   9 +
 drivers/net/ethernet/freescale/enetc/Makefile |   3 +
 drivers/net/ethernet/freescale/enetc/enetc.h  |  16 ++
 .../ethernet/freescale/enetc/enetc_ethtool.c  |  18 ++
 .../net/ethernet/freescale/enetc/enetc_hw.h   |   9 +
 .../net/ethernet/freescale/enetc/enetc_ierb.c | 155 ++++++++++++++++++
 .../net/ethernet/freescale/enetc/enetc_ierb.h |  20 +++
 .../net/ethernet/freescale/enetc/enetc_pf.c   |  95 ++++++++++-
 .../net/ethernet/freescale/enetc/enetc_qos.c  |  16 +-
 11 files changed, 349 insertions(+), 13 deletions(-)
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_ierb.c
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_ierb.h

-- 
2.25.1



From olteanv at gmail.com  Sat Apr 17 00:42:21 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:21 +0300
Subject: [PATCH net-next 1/5] net: enetc: create a common enetc_pf_to_port
 helper
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210416234225.3715819-2-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

Even though ENETC interfaces are exposed as individual PCIe PFs with
their own driver instances, the ENETC is still fundamentally a
multi-port Ethernet controller, and some parts of the IP take a port
number (as can be seen in the PSFP implementation).

Create a common helper that can be used outside of the TSN code for
retrieving the ENETC port number based on the PF number. This is only
correct for LS1028A, the only Linux-capable instantiation of ENETC thus
far.

Note that ENETC port 3 is PF 6. The TSN code did not care about this
because ENETC port 3 does not support TSN, so the wrong mapping done by
enetc_get_port for PF 6 could have never been hit.

Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
---
 drivers/net/ethernet/freescale/enetc/enetc.h     | 16 ++++++++++++++++
 drivers/net/ethernet/freescale/enetc/enetc_qos.c | 16 ++++++----------
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc.h b/drivers/net/ethernet/freescale/enetc/enetc.h
index 3de71669e317..08b283347d9c 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc.h
@@ -237,6 +237,22 @@ static inline bool enetc_si_is_pf(struct enetc_si *si)
 	return !!(si->hw.port);
 }
 
+static inline int enetc_pf_to_port(struct pci_dev *pf_pdev)
+{
+	switch (pf_pdev->devfn) {
+	case 0:
+		return 0;
+	case 1:
+		return 1;
+	case 2:
+		return 2;
+	case 6:
+		return 3;
+	default:
+		return -1;
+	}
+}
+
 #define ENETC_MAX_NUM_TXQS	8
 #define ENETC_INT_NAME_MAX	(IFNAMSIZ + 8)
 
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index cb7fa4bceaf2..af699f2ad095 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -455,11 +455,6 @@ static struct enetc_psfp epsfp = {
 
 static LIST_HEAD(enetc_block_cb_list);
 
-static inline int enetc_get_port(struct enetc_ndev_priv *priv)
-{
-	return priv->si->pdev->devfn & 0x7;
-}
-
 /* Stream Identity Entry Set Descriptor */
 static int enetc_streamid_hw_set(struct enetc_ndev_priv *priv,
 				 struct enetc_streamid *sid,
@@ -504,7 +499,7 @@ static int enetc_streamid_hw_set(struct enetc_ndev_priv *priv,
 
 	si_conf = &cbd.sid_set;
 	/* Only one port supported for one entry, set itself */
-	si_conf->iports = cpu_to_le32(1 << enetc_get_port(priv));
+	si_conf->iports = cpu_to_le32(1 << enetc_pf_to_port(priv->si->pdev));
 	si_conf->id_type = 1;
 	si_conf->oui[2] = 0x0;
 	si_conf->oui[1] = 0x80;
@@ -529,7 +524,7 @@ static int enetc_streamid_hw_set(struct enetc_ndev_priv *priv,
 
 	si_conf->en = 0x80;
 	si_conf->stream_handle = cpu_to_le32(sid->handle);
-	si_conf->iports = cpu_to_le32(1 << enetc_get_port(priv));
+	si_conf->iports = cpu_to_le32(1 << enetc_pf_to_port(priv->si->pdev));
 	si_conf->id_type = sid->filtertype;
 	si_conf->oui[2] = 0x0;
 	si_conf->oui[1] = 0x80;
@@ -591,7 +586,8 @@ static int enetc_streamfilter_hw_set(struct enetc_ndev_priv *priv,
 	}
 
 	sfi_config->sg_inst_table_index = cpu_to_le16(sfi->gate_id);
-	sfi_config->input_ports = cpu_to_le32(1 << enetc_get_port(priv));
+	sfi_config->input_ports =
+		cpu_to_le32(1 << enetc_pf_to_port(priv->si->pdev));
 
 	/* The priority value which may be matched against the
 	 * frame?s priority value to determine a match for this entry.
@@ -1562,10 +1558,10 @@ int enetc_setup_tc_psfp(struct net_device *ndev, void *type_data)
 
 	switch (f->command) {
 	case FLOW_BLOCK_BIND:
-		set_bit(enetc_get_port(priv), &epsfp.dev_bitmap);
+		set_bit(enetc_pf_to_port(priv->si->pdev), &epsfp.dev_bitmap);
 		break;
 	case FLOW_BLOCK_UNBIND:
-		clear_bit(enetc_get_port(priv), &epsfp.dev_bitmap);
+		clear_bit(enetc_pf_to_port(priv->si->pdev), &epsfp.dev_bitmap);
 		if (!epsfp.dev_bitmap)
 			clean_psfp_all();
 		break;
-- 
2.25.1



From olteanv at gmail.com  Sat Apr 17 00:42:22 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:22 +0300
Subject: [PATCH net-next 2/5] dt-bindings: net: fsl: enetc: add the IERB
 documentation
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210416234225.3715819-3-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

Mention the required compatible string and base address for the
Integrated Endpoint Register Block node.

Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
---
 .../devicetree/bindings/net/fsl-enetc.txt         | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
index b7034ccbc1bd..9b9a3f197e2d 100644
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -102,3 +102,18 @@ Example:
 			full-duplex;
 		};
 	};
+
+* Integrated Endpoint Register Block bindings
+
+Optionally, the fsl_enetc driver can probe on the Integrated Endpoint Register
+Block, which preconfigures the FIFO limits for the ENETC ports. This is a node
+with the following properties:
+
+- reg		: Specifies the address in the SoC memory space.
+- compatible	: Must be "fsl,ls1028a-enetc-ierb".
+
+Example:
+	ierb at 1f0800000 {
+		compatible = "fsl,ls1028a-enetc-ierb";
+		reg = <0x01 0xf0800000 0x0 0x10000>;
+	};
-- 
2.25.1



From olteanv at gmail.com  Sat Apr 17 00:42:23 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:23 +0300
Subject: [PATCH net-next 3/5] net: enetc: add a mini driver for the Integrated
 Endpoint Register Block
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210416234225.3715819-4-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

The NXP ENETC is a 4-port Ethernet controller which 'smells' to
operating systems like 4 distinct PCIe PFs with SR-IOV, each PF having
its own driver instance, but in fact there are some hardware resources
which are shared between all ports, like for example the 256 KB SRAM
FIFO between the MACs and the Host Transfer Agent which DMAs frames to
DRAM.

To hide the stuff that cannot be neatly exposed per port, the hardware
designers came up with this idea of having a dedicated register block
which is supposed to be populated by the bootloader, and contains
everything configuration-related: MAC addresses, FIFO partitioning, etc.

When a port is reset using PCIe Function Level Reset, its defaults are
transferred from the IERB configuration. Most of the time, the settings
made through the IERB are read-only in the port's memory space (if they
are even visible), so they cannot be modified at runtime.

Linux doesn't have any advanced FIFO partitioning requirements at all,
but when reading through the hardware manual, it became clear that, even
though there are many good 'recommendations' for default values, many of
them were not actually put in practice on LS1028A. So we end up with a
default configuration that:

(a) does not have enough TX and RX byte credits to support the max MTU
    of 9600 (which the Linux driver claims already) properly (at full speed)
(b) allows the FIFO to be overrun with RX traffic, potentially
    overwriting internal data structures.

The last part sounds a bit catastrophic, but it isn't. Frames are
supposed to transit the FIFO for a very short time, but they can
actually accumulate there under 2 conditions:

(a) there is very severe congestion on DRAM memory, or
(b) the RX rings visible to the operating system were configured for
    lossless operation, and they just ran out of free buffers to copy
    the frame to. This is what is used to put backpressure onto the MAC
    with flow control.

So since ENETC has not supported flow control thus far, RX FIFO overruns
were never seen with Linux. But with the addition of flow control, we
should configure some registers to prevent this from happening. What we
are trying to protect against are bad actors which continue to send us
traffic despite the fact that we have signaled a PAUSE condition. Of
course we can't be lossless in that case, but it is best to configure
the FIFO to do tail dropping rather than letting it overrun.

So in a nutshell, this driver is a fixup for all the IERB default values
that should have been but aren't.

The IERB configuration needs to be done _before_ the PFs are enabled.
So every PF searches for the presence of the "fsl,ls1028a-enetc-ierb"
node in the device tree, and if it finds it, it "registers" with the
IERB, which means that it requests the IERB to fix up its default
values. This is done through -EPROBE_DEFER. The IERB driver is part of
the fsl_enetc module, but is technically a platform driver, since the
IERB is a good old fashioned MMIO region, as opposed to ENETC ports
which pretend to be PCIe devices.

The driver was already configuring ENETC_PTXMBAR (FIFO allocation for
TX) because due to an omission, TXMBAR is a read/write register in the
PF memory space. But the manual is quite clear that the formula for this
should depend upon the TX byte credits (TXBCR). In turn, the TX byte
credits are only readable/writable through the IERB. So if we want to
ensure that the TXBCR register also has a value that is correct and in
line with TXMBAR, there is simply no way this can be done from the PF
driver, access to the IERB is needed.

I could have modified U-Boot to fix up the IERB values, but that is
quite undesirable, as old U-Boot versions are likely to be floating
around for quite some time from now.

Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
---
 drivers/net/ethernet/freescale/enetc/Kconfig  |   9 +
 drivers/net/ethernet/freescale/enetc/Makefile |   3 +
 .../net/ethernet/freescale/enetc/enetc_ierb.c | 155 ++++++++++++++++++
 .../net/ethernet/freescale/enetc/enetc_ierb.h |  20 +++
 .../net/ethernet/freescale/enetc/enetc_pf.c   |  35 +++-
 5 files changed, 221 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_ierb.c
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_ierb.h

diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig b/drivers/net/ethernet/freescale/enetc/Kconfig
index ab92382c399a..d88f60c2bb82 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -2,6 +2,7 @@
 config FSL_ENETC
 	tristate "ENETC PF driver"
 	depends on PCI && PCI_MSI
+	depends on FSL_ENETC_IERB || FSL_ENETC_IERB=n
 	select FSL_ENETC_MDIO
 	select PHYLINK
 	select PCS_LYNX
@@ -25,6 +26,14 @@ config FSL_ENETC_VF
 
 	  If compiled as module (M), the module name is fsl-enetc-vf.
 
+config FSL_ENETC_IERB
+	tristate "ENETC IERB driver"
+	help
+	  This driver configures the Integrated Endpoint Register Block on NXP
+	  LS1028A.
+
+	  If compiled as module (M), the module name is fsl-enetc-ierb.
+
 config FSL_ENETC_MDIO
 	tristate "ENETC MDIO driver"
 	depends on PCI && MDIO_DEVRES && MDIO_BUS
diff --git a/drivers/net/ethernet/freescale/enetc/Makefile b/drivers/net/ethernet/freescale/enetc/Makefile
index 74f7ac253b8b..a139f2e9d59f 100644
--- a/drivers/net/ethernet/freescale/enetc/Makefile
+++ b/drivers/net/ethernet/freescale/enetc/Makefile
@@ -11,6 +11,9 @@ obj-$(CONFIG_FSL_ENETC_VF) += fsl-enetc-vf.o
 fsl-enetc-vf-y := enetc_vf.o $(common-objs)
 fsl-enetc-vf-$(CONFIG_FSL_ENETC_QOS) += enetc_qos.o
 
+obj-$(CONFIG_FSL_ENETC_IERB) += fsl-enetc-ierb.o
+fsl-enetc-ierb-y := enetc_ierb.o
+
 obj-$(CONFIG_FSL_ENETC_MDIO) += fsl-enetc-mdio.o
 fsl-enetc-mdio-y := enetc_pci_mdio.o enetc_mdio.o
 
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ierb.c b/drivers/net/ethernet/freescale/enetc/enetc_ierb.c
new file mode 100644
index 000000000000..8b356c485507
--- /dev/null
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ierb.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/* Copyright 2021 NXP Semiconductors
+ *
+ * The Integrated Endpoint Register Block (IERB) is configured by pre-boot
+ * software and is supposed to be to ENETC what a NVRAM is to a 'real' PCIe
+ * card. Upon FLR, values from the IERB are transferred to the ENETC PFs, and
+ * are read-only in the PF memory space.
+ *
+ * This driver fixes up the power-on reset values for the ENETC shared FIFO,
+ * such that the TX and RX allocations are sufficient for jumbo frames, and
+ * that intelligent FIFO dropping is enabled before the internal data
+ * structures are corrupted.
+ *
+ * Even though not all ports might be used on a given board, we are not
+ * concerned with partitioning the FIFO, because the default values configure
+ * no strict reservations, so the entire FIFO can be used by the RX of a single
+ * port, or the TX of a single port.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include "enetc.h"
+#include "enetc_ierb.h"
+
+/* IERB registers */
+#define ENETC_IERB_TXMBAR(port)			(((port) * 0x100) + 0x8080)
+#define ENETC_IERB_RXMBER(port)			(((port) * 0x100) + 0x8090)
+#define ENETC_IERB_RXMBLR(port)			(((port) * 0x100) + 0x8094)
+#define ENETC_IERB_RXBCR(port)			(((port) * 0x100) + 0x80a0)
+#define ENETC_IERB_TXBCR(port)			(((port) * 0x100) + 0x80a8)
+#define ENETC_IERB_FMBDTR			0xa000
+
+#define ENETC_RESERVED_FOR_ICM			1024
+
+struct enetc_ierb {
+	void __iomem *regs;
+};
+
+static void enetc_ierb_write(struct enetc_ierb *ierb, u32 offset, u32 val)
+{
+	iowrite32(val, ierb->regs + offset);
+}
+
+int enetc_ierb_register_pf(struct platform_device *pdev,
+			   struct pci_dev *pf_pdev)
+{
+	struct enetc_ierb *ierb = platform_get_drvdata(pdev);
+	int port = enetc_pf_to_port(pf_pdev);
+	u16 tx_credit, rx_credit, tx_alloc;
+
+	if (port < 0)
+		return -ENODEV;
+
+	if (!ierb)
+		return -EPROBE_DEFER;
+
+	/* By default, it is recommended to set the Host Transfer Agent
+	 * per port transmit byte credit to "1000 + max_frame_size/2".
+	 * The power-on reset value (1800 bytes) is rounded up to the nearest
+	 * 100 assuming a maximum frame size of 1536 bytes.
+	 */
+	tx_credit = roundup(1000 + ENETC_MAC_MAXFRM_SIZE / 2, 100);
+
+	/* Internal memory allocated for transmit buffering is guaranteed but
+	 * not reserved; i.e. if the total transmit allocation is not used,
+	 * then the unused portion is not left idle, it can be used for receive
+	 * buffering but it will be reclaimed, if required, from receive by
+	 * intelligently dropping already stored receive frames in the internal
+	 * memory to ensure that the transmit allocation is respected.
+	 *
+	 * PaTXMBAR must be set to a value larger than
+	 *     PaTXBCR + 2 * max_frame_size + 32
+	 * if frame preemption is not enabled, or to
+	 *     2 * PaTXBCR + 2 * p_max_frame_size (pMAC maximum frame size) +
+	 *     2 * np_max_frame_size (eMAC maximum frame size) + 64
+	 * if frame preemption is enabled.
+	 */
+	tx_alloc = roundup(2 * tx_credit + 4 * ENETC_MAC_MAXFRM_SIZE + 64, 16);
+
+	/* Initial credits, in units of 8 bytes, to the Ingress Congestion
+	 * Manager for the maximum amount of bytes the port is allocated for
+	 * pending traffic.
+	 * It is recommended to set the initial credits to 2 times the maximum
+	 * frame size (2 frames of maximum size).
+	 */
+	rx_credit = DIV_ROUND_UP(ENETC_MAC_MAXFRM_SIZE * 2, 8);
+
+	enetc_ierb_write(ierb, ENETC_IERB_TXBCR(port), tx_credit);
+	enetc_ierb_write(ierb, ENETC_IERB_TXMBAR(port), tx_alloc);
+	enetc_ierb_write(ierb, ENETC_IERB_RXBCR(port), rx_credit);
+
+	return 0;
+}
+EXPORT_SYMBOL(enetc_ierb_register_pf);
+
+static int enetc_ierb_probe(struct platform_device *pdev)
+{
+	struct enetc_ierb *ierb;
+	struct resource *res;
+	void __iomem *regs;
+
+	ierb = devm_kzalloc(&pdev->dev, sizeof(*ierb), GFP_KERNEL);
+	if (!ierb)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(regs))
+		return PTR_ERR(regs);
+
+	ierb->regs = regs;
+
+	/* Free buffer depletion threshold in bytes.
+	 * This sets the minimum amount of free buffer memory that should be
+	 * maintained in the datapath sub system, and when the amount of free
+	 * buffer memory falls below this threshold, a depletion indication is
+	 * asserted, which may trigger "intelligent drop" frame releases from
+	 * the ingress queues in the ICM.
+	 * It is recommended to set the free buffer depletion threshold to 1024
+	 * bytes, since the ICM needs some FIFO memory for its own use.
+	 */
+	enetc_ierb_write(ierb, ENETC_IERB_FMBDTR, ENETC_RESERVED_FOR_ICM);
+
+	platform_set_drvdata(pdev, ierb);
+
+	return 0;
+}
+
+static int enetc_ierb_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static const struct of_device_id enetc_ierb_match[] = {
+	{ .compatible = "fsl,ls1028a-enetc-ierb", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, enetc_ierb_match);
+
+static struct platform_driver enetc_ierb_driver = {
+	.driver = {
+		.name = "fsl-enetc-ierb",
+		.of_match_table = enetc_ierb_match,
+	},
+	.probe = enetc_ierb_probe,
+	.remove = enetc_ierb_remove,
+};
+
+module_platform_driver(enetc_ierb_driver);
+
+MODULE_DESCRIPTION("NXP ENETC IERB");
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ierb.h b/drivers/net/ethernet/freescale/enetc/enetc_ierb.h
new file mode 100644
index 000000000000..b3b774e0998a
--- /dev/null
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ierb.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
+/* Copyright 2021 NXP Semiconductors */
+
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+#if IS_ENABLED(CONFIG_FSL_ENETC_IERB)
+
+int enetc_ierb_register_pf(struct platform_device *pdev,
+			   struct pci_dev *pf_pdev);
+
+#else
+
+static inline int enetc_ierb_register_pf(struct platform_device *pdev,
+					 struct pci_dev *pf_pdev)
+{
+	return -EOPNOTSUPP;
+}
+
+#endif
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index be3dde0618e7..1ae2473cbc16 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -4,8 +4,10 @@
 #include <linux/mdio.h>
 #include <linux/module.h>
 #include <linux/fsl/enetc_mdio.h>
+#include <linux/of_platform.h>
 #include <linux/of_mdio.h>
 #include <linux/of_net.h>
+#include "enetc_ierb.h"
 #include "enetc_pf.h"
 
 #define ENETC_DRV_NAME_STR "ENETC PF driver"
@@ -518,7 +520,6 @@ static void enetc_configure_port_mac(struct enetc_hw *hw)
 		      ENETC_SET_MAXFRM(ENETC_RX_MAXFRM_SIZE));
 
 	enetc_port_wr(hw, ENETC_PTCMSDUR(0), ENETC_MAC_MAXFRM_SIZE);
-	enetc_port_wr(hw, ENETC_PTXMBAR, 2 * ENETC_MAC_MAXFRM_SIZE);
 
 	enetc_port_wr(hw, ENETC_PM0_CMD_CFG, ENETC_PM0_CMD_PHY_TX_EN |
 		      ENETC_PM0_CMD_TXP	| ENETC_PM0_PROMISC);
@@ -1116,6 +1117,30 @@ static int enetc_init_port_rss_memory(struct enetc_si *si)
 	return err;
 }
 
+static int enetc_pf_register_with_ierb(struct pci_dev *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct platform_device *ierb_pdev;
+	struct device_node *ierb_node;
+
+	/* Don't register with the IERB if the PF itself is disabled */
+	if (!node || !of_device_is_available(node))
+		return 0;
+
+	ierb_node = of_find_compatible_node(NULL, NULL,
+					    "fsl,ls1028a-enetc-ierb");
+	if (!ierb_node || !of_device_is_available(ierb_node))
+		return -ENODEV;
+
+	ierb_pdev = of_find_device_by_node(ierb_node);
+	of_node_put(ierb_node);
+
+	if (!ierb_pdev)
+		return -EPROBE_DEFER;
+
+	return enetc_ierb_register_pf(ierb_pdev, pdev);
+}
+
 static int enetc_pf_probe(struct pci_dev *pdev,
 			  const struct pci_device_id *ent)
 {
@@ -1126,6 +1151,14 @@ static int enetc_pf_probe(struct pci_dev *pdev,
 	struct enetc_pf *pf;
 	int err;
 
+	err = enetc_pf_register_with_ierb(pdev);
+	if (err == -EPROBE_DEFER)
+		return err;
+	if (err)
+		dev_warn(&pdev->dev,
+			 "Could not register with IERB driver: %pe, please update the device tree\n",
+			 ERR_PTR(err));
+
 	err = enetc_pci_probe(pdev, KBUILD_MODNAME, sizeof(*pf));
 	if (err) {
 		dev_err(&pdev->dev, "PCI probing failed\n");
-- 
2.25.1



From olteanv at gmail.com  Sat Apr 17 00:42:24 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:24 +0300
Subject: [PATCH net-next 4/5] arm64: dts: ls1028a: declare the Integrated
 Endpoint Register Block node
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210416234225.3715819-5-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

Add a node describing the address in the SoC memory space for the IERB.

Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 7b45fba7a9cc..44e18603e678 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -1130,6 +1130,12 @@ fixed-link {
 			};
 		};
 
+		/* Integrated Endpoint Register Block */
+		ierb at 1f0800000 {
+			compatible = "fsl,ls1028a-enetc-ierb";
+			reg = <0x01 0xf0800000 0x0 0x10000>;
+		};
+
 		rcpm: power-controller at 1e34040 {
 			compatible = "fsl,ls1028a-rcpm", "fsl,qoriq-rcpm-2.1+";
 			reg = <0x0 0x1e34040 0x0 0x1c>;
-- 
2.25.1



From olteanv at gmail.com  Sat Apr 17 00:42:25 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Sat, 17 Apr 2021 02:42:25 +0300
Subject: [PATCH net-next 5/5] net: enetc: add support for flow control
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210416234225.3715819-6-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean at nxp.com>

In the ENETC receive path, a frame received by the MAC is first stored
in a 256KB 'FIFO' memory, then transferred to DRAM when enqueuing it to
the RX ring. The FIFO is a shared resource for all ENETC ports, but
every port keeps track of its own memory utilization, on RX and on TX.

There is a setting for RX rings through which they can either operate in
'lossy' mode (where the lack of a free buffer causes an immediate
discard of the frame) or in 'lossless' mode (where the lack of a free
buffer in the ring makes the frame stay longer in the FIFO).

In turn, when the memory utilization of the FIFO exceeds a certain
margin, the MAC can be configured to emit PAUSE frames.

There is enough FIFO memory to buffer up to 3 MTU-sized frames per RX
port while not jeopardizing the other use cases (jumbo frames), and
also not consume bytes from the port TX allocations. Also, 3 MTU-sized
frames worth of memory is enough to ensure zero loss for 64 byte packets
at 1G line rate.

Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
---
 .../ethernet/freescale/enetc/enetc_ethtool.c  | 18 ++++++
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  9 +++
 .../net/ethernet/freescale/enetc/enetc_pf.c   | 60 ++++++++++++++++++-
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
index 49835e878bbb..ebccaf02411c 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_ethtool.c
@@ -708,6 +708,22 @@ static int enetc_set_wol(struct net_device *dev,
 	return ret;
 }
 
+static void enetc_get_pauseparam(struct net_device *dev,
+				 struct ethtool_pauseparam *pause)
+{
+	struct enetc_ndev_priv *priv = netdev_priv(dev);
+
+	phylink_ethtool_get_pauseparam(priv->phylink, pause);
+}
+
+static int enetc_set_pauseparam(struct net_device *dev,
+				struct ethtool_pauseparam *pause)
+{
+	struct enetc_ndev_priv *priv = netdev_priv(dev);
+
+	return phylink_ethtool_set_pauseparam(priv->phylink, pause);
+}
+
 static int enetc_get_link_ksettings(struct net_device *dev,
 				    struct ethtool_link_ksettings *cmd)
 {
@@ -754,6 +770,8 @@ static const struct ethtool_ops enetc_pf_ethtool_ops = {
 	.get_ts_info = enetc_get_ts_info,
 	.get_wol = enetc_get_wol,
 	.set_wol = enetc_set_wol,
+	.get_pauseparam = enetc_get_pauseparam,
+	.set_pauseparam = enetc_set_pauseparam,
 };
 
 static const struct ethtool_ops enetc_vf_ethtool_ops = {
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 04ac7fc23ead..0f5f081a5baf 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -109,6 +109,7 @@ enum enetc_bdr_type {TX, RX};
 /* RX BDR reg offsets */
 #define ENETC_RBMR	0
 #define ENETC_RBMR_BDS	BIT(2)
+#define ENETC_RBMR_CM	BIT(4)
 #define ENETC_RBMR_VTE	BIT(5)
 #define ENETC_RBMR_EN	BIT(31)
 #define ENETC_RBSR	0x4
@@ -180,6 +181,8 @@ enum enetc_bdr_type {TX, RX};
 #define ENETC_PSIVLANR(n)	(0x0240 + (n) * 4) /* n = SI index */
 #define ENETC_PSIVLAN_EN	BIT(31)
 #define ENETC_PSIVLAN_SET_QOS(val)	((u32)(val) << 12)
+#define ENETC_PPAUONTR		0x0410
+#define ENETC_PPAUOFFTR		0x0414
 #define ENETC_PTXMBAR		0x0608
 #define ENETC_PCAPR0		0x0900
 #define ENETC_PCAPR0_RXBDR(val)	((val) >> 24)
@@ -227,6 +230,7 @@ enum enetc_bdr_type {TX, RX};
 #define ENETC_PM0_TX_EN		BIT(0)
 #define ENETC_PM0_RX_EN		BIT(1)
 #define ENETC_PM0_PROMISC	BIT(4)
+#define ENETC_PM0_PAUSE_IGN	BIT(8)
 #define ENETC_PM0_CMD_XGLP	BIT(10)
 #define ENETC_PM0_CMD_TXP	BIT(11)
 #define ENETC_PM0_CMD_PHY_TX_EN	BIT(15)
@@ -239,6 +243,11 @@ enum enetc_bdr_type {TX, RX};
 
 #define ENETC_PM_IMDIO_BASE	0x8030
 
+#define ENETC_PM0_PAUSE_QUANTA	0x8054
+#define ENETC_PM0_PAUSE_THRESH	0x8064
+#define ENETC_PM1_PAUSE_QUANTA	0x9054
+#define ENETC_PM1_PAUSE_THRESH	0x9064
+
 #define ENETC_PM0_SINGLE_STEP		0x80c0
 #define ENETC_PM1_SINGLE_STEP		0x90c0
 #define ENETC_PM0_SINGLE_STEP_CH	BIT(7)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 1ae2473cbc16..aff1339442cc 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
@@ -1015,7 +1015,12 @@ static void enetc_pl_mac_link_up(struct phylink_config *config,
 				 int duplex, bool tx_pause, bool rx_pause)
 {
 	struct enetc_pf *pf = phylink_to_enetc_pf(config);
+	u32 pause_off_thresh = 0, pause_on_thresh = 0;
+	u32 init_quanta = 0, refresh_quanta = 0;
+	struct enetc_hw *hw = &pf->si->hw;
 	struct enetc_ndev_priv *priv;
+	u32 rbmr, cmd_cfg;
+	int idx;
 
 	priv = netdev_priv(pf->si->ndev);
 	if (priv->active_offloads & ENETC_F_QBV)
@@ -1023,9 +1028,60 @@ static void enetc_pl_mac_link_up(struct phylink_config *config,
 
 	if (!phylink_autoneg_inband(mode) &&
 	    phy_interface_mode_is_rgmii(interface))
-		enetc_force_rgmii_mac(&pf->si->hw, speed, duplex);
+		enetc_force_rgmii_mac(hw, speed, duplex);
+
+	/* Flow control */
+	for (idx = 0; idx < priv->num_rx_rings; idx++) {
+		rbmr = enetc_rxbdr_rd(hw, idx, ENETC_RBMR);
+
+		if (tx_pause)
+			rbmr |= ENETC_RBMR_CM;
+		else
+			rbmr &= ~ENETC_RBMR_CM;
+
+		enetc_rxbdr_wr(hw, idx, ENETC_RBMR, rbmr);
+	}
+
+	if (tx_pause) {
+		/* When the port first enters congestion, send a PAUSE request
+		 * with the maximum number of quanta. When the port exits
+		 * congestion, it will automatically send a PAUSE frame with
+		 * zero quanta.
+		 */
+		init_quanta = 0xffff;
+
+		/* Also, set up the refresh timer to send follow-up PAUSE
+		 * frames at half the quanta value, in case the congestion
+		 * condition persists.
+		 */
+		refresh_quanta = 0xffff / 2;
+
+		/* Start emitting PAUSE frames when 3 large frames (or more
+		 * smaller frames) have accumulated in the FIFO waiting to be
+		 * DMAed to the RX ring.
+		 */
+		pause_on_thresh = 3 * ENETC_MAC_MAXFRM_SIZE;
+		pause_off_thresh = 1 * ENETC_MAC_MAXFRM_SIZE;
+	}
+
+	enetc_port_wr(hw, ENETC_PM0_PAUSE_QUANTA, init_quanta);
+	enetc_port_wr(hw, ENETC_PM1_PAUSE_QUANTA, init_quanta);
+	enetc_port_wr(hw, ENETC_PM0_PAUSE_THRESH, refresh_quanta);
+	enetc_port_wr(hw, ENETC_PM1_PAUSE_THRESH, refresh_quanta);
+	enetc_port_wr(hw, ENETC_PPAUONTR, pause_on_thresh);
+	enetc_port_wr(hw, ENETC_PPAUOFFTR, pause_off_thresh);
+
+	cmd_cfg = enetc_port_rd(hw, ENETC_PM0_CMD_CFG);
+
+	if (rx_pause)
+		cmd_cfg &= ~ENETC_PM0_PAUSE_IGN;
+	else
+		cmd_cfg |= ENETC_PM0_PAUSE_IGN;
+
+	enetc_port_wr(hw, ENETC_PM0_CMD_CFG, cmd_cfg);
+	enetc_port_wr(hw, ENETC_PM1_CMD_CFG, cmd_cfg);
 
-	enetc_mac_enable(&pf->si->hw, true);
+	enetc_mac_enable(hw, true);
 }
 
 static void enetc_pl_mac_link_down(struct phylink_config *config,
-- 
2.25.1



From sboyd at kernel.org  Sat Apr 17 00:55:11 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Fri, 16 Apr 2021 16:55:11 -0700
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema
In-Reply-To: <20210416063721.20538-3-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-3-nm@ti.com>
Message-ID: <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>

Quoting Nishanth Menon (2021-04-15 23:37:19)
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> new file mode 100644
> index 000000000000..72633651f0c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI-SCI clock controller node bindings
> +
> +maintainers:
> +  - Nishanth Menon <nm at ti.com>
> +
> +allOf:
> +  - $ref: /schemas/clock/clock.yaml#

Is this needed?

> +
> +description: |
> +  Some TI SoCs contain a system controller (like the Power Management Micro
> +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> +  the state of the various hardware modules present on the SoC. Communication
> +  between the host processor running an OS and the system controller happens
> +  through a protocol called TI System Control Interface (TI-SCI protocol).
> +
> +  This clock controller node uses the TI SCI protocol to perform various clock
> +  management of various hardware modules (devices) present on the SoC. This
> +  node must be a child node of the associated TI-SCI system controller node.
> +
> +properties:
> +  $nodename:
> +    pattern: "^clock-controller$"

Is this nodename pattern check required?

> +
> +  compatible:
> +    const: ti,k2g-sci-clk

I thought most things keyed off the compatible string.

> +
> +  "#clock-cells":
> +    const: 2
> +    description:
> +      The two cells represent values that the TI-SCI controller defines.
> +
> +      The first cell should contain the device ID.
> +
> +      The second cell should contain the clock ID.
> +
> +      Please see  http://processors.wiki.ti.com/index.php/TISCI for
> +      protocol documentation for the values to be used for different devices.
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    k3_clks: clock-controller {
> +        compatible = "ti,k2g-sci-clk";
> +        #clock-cells = <2>;
> +    };


From sboyd at kernel.org  Sat Apr 17 01:02:20 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Fri, 16 Apr 2021 17:02:20 -0700
Subject: [PATCH v2 2/7] clk: mediatek: mt8192: Add APU clocks support
In-Reply-To: <1618465960-3013-3-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
 <1618465960-3013-3-git-send-email-flora.fu@mediatek.com>
Message-ID: <161861774045.46595.16984607053300669956@swboyd.mtv.corp.google.com>

Quoting Flora Fu (2021-04-14 22:52:35)
> Add APU clocks support on MT8192.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> ---

Acked-by: Stephen Boyd <sboyd at kernel.org>


From sboyd at kernel.org  Sat Apr 17 01:02:29 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Fri, 16 Apr 2021 17:02:29 -0700
Subject: [PATCH v2 1/7] dt-bindings: clock: Add MT8192 APU clock bindings
In-Reply-To: <1618465960-3013-2-git-send-email-flora.fu@mediatek.com>
References: <1618465960-3013-1-git-send-email-flora.fu@mediatek.com>
 <1618465960-3013-2-git-send-email-flora.fu@mediatek.com>
Message-ID: <161861774904.46595.8483541757848028552@swboyd.mtv.corp.google.com>

Quoting Flora Fu (2021-04-14 22:52:34)
> Add clock bindings for APU on MT8192.
> 
> Signed-off-by: Flora Fu <flora.fu at mediatek.com>
> Acked-by: Rob Herring <robh at kernel.org>
> ---

Acked-by: Stephen Boyd <sboyd at kernel.org>


From zhukeqian1 at huawei.com  Sat Apr 17 02:05:05 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Sat, 17 Apr 2021 09:05:05 +0800
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <87a6py2ss9.wl-maz@kernel.org>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <8f55b64f-b4dd-700e-c997-8de9c5ea282f@huawei.com>
 <87a6py2ss9.wl-maz@kernel.org>
Message-ID: <d8af7360-ee96-2344-336d-bfaf8828fc8e@huawei.com>

Hi Marc,

On 2021/4/16 22:44, Marc Zyngier wrote:
> On Thu, 15 Apr 2021 15:08:09 +0100,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>
>> Hi Marc,
>>
>> On 2021/4/15 22:03, Keqian Zhu wrote:
>>> The MMIO region of a device maybe huge (GB level), try to use
>>> block mapping in stage2 to speedup both map and unmap.
>>>
>>> Compared to normal memory mapping, we should consider two more
>>> points when try block mapping for MMIO region:
>>>
>>> 1. For normal memory mapping, the PA(host physical address) and
>>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>>> the HVA to request hugepage, so we don't need to consider PA
>>> alignment when verifing block mapping. But for device memory
>>> mapping, the PA and HVA may have different alignment.
>>>
>>> 2. For normal memory mapping, we are sure hugepage size properly
>>> fit into vma, so we don't check whether the mapping size exceeds
>>> the boundary of vma. But for device memory mapping, we should pay
>>> attention to this.
>>>
>>> This adds get_vma_page_shift() to get page shift for both normal
>>> memory and device MMIO region, and check these two points when
>>> selecting block mapping size for MMIO region.
>>>
>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>> ---
>>>  arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>>>  1 file changed, 51 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index c59af5ca01b0..5a1cc7751e6d 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>>>  	return PAGE_SIZE;
>>>  }
>>>  
[...]

>>> +	/*
>>> +	 * logging_active is guaranteed to never be true for VM_PFNMAP
>>> +	 * memslots.
>>> +	 */
>>> +	if (logging_active) {
>>>  		force_pte = true;
>>>  		vma_shift = PAGE_SHIFT;
>>> +	} else {
>>> +		vma_shift = get_vma_page_shift(vma, hva);
>>>  	}
>> I use a if/else manner in v4, please check that. Thanks very much!
> 
> That's fine. However, it is getting a bit late for 5.13, and we don't
> have much time to left it simmer in -next. I'll probably wait until
> after the merge window to pick it up.
OK, no problem. Thanks! :)

BRs,
Keqian


From lkp at intel.com  Sat Apr 17 02:08:41 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 17 Apr 2021 09:08:41 +0800
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416230724.2519198-2-willy@infradead.org>
References: <20210416230724.2519198-2-willy@infradead.org>
Message-ID: <202104170943.saIArN8X-lkp@intel.com>

Hi "Matthew,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linux/master]
[also build test WARNING on linus/master v5.12-rc7]
[cannot apply to hnaz-linux-mm/master next-20210416]
[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]

url:    https://github.com/0day-ci/linux/commits/Matthew-Wilcox-Oracle/Change-struct-page-layout-for-page_pool/20210417-070951
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5e46d1b78a03d52306f21f77a4e4a144b6d31486
config: parisc-randconfig-s031-20210416 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-280-g2cd6d34e-dirty
        # https://github.com/0day-ci/linux/commit/898e155048088be20b2606575a24108eacc4c91b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Matthew-Wilcox-Oracle/Change-struct-page-layout-for-page_pool/20210417-070951
        git checkout 898e155048088be20b2606575a24108eacc4c91b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from net/core/xdp.c:15:
   include/net/page_pool.h: In function 'page_pool_get_dma_addr':
>> include/net/page_pool.h:203:40: warning: left shift count >= width of type [-Wshift-count-overflow]
     203 |   ret |= (dma_addr_t)page->dma_addr[1] << 32;
         |                                        ^~
   include/net/page_pool.h: In function 'page_pool_set_dma_addr':
>> include/net/page_pool.h:211:28: warning: right shift count >= width of type [-Wshift-count-overflow]
     211 |   page->dma_addr[1] = addr >> 32;
         |                            ^~


vim +203 include/net/page_pool.h

   198	
   199	static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
   200	{
   201		dma_addr_t ret = page->dma_addr[0];
   202		if (sizeof(dma_addr_t) > sizeof(unsigned long))
 > 203			ret |= (dma_addr_t)page->dma_addr[1] << 32;
   204		return ret;
   205	}
   206	
   207	static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
   208	{
   209		page->dma_addr[0] = addr;
   210		if (sizeof(dma_addr_t) > sizeof(unsigned long))
 > 211			page->dma_addr[1] = addr >> 32;
   212	}
   213	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23601 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210417/742df533/attachment-0001.gz>

From thunder.leizhen at huawei.com  Sat Apr 17 02:10:53 2021
From: thunder.leizhen at huawei.com (Leizhen (ThunderTown))
Date: Sat, 17 Apr 2021 09:10:53 +0800
Subject: [PATCH 5/8] iommu: fix a couple of spelling mistakes
In-Reply-To: <e04d117a-4832-7f95-7adf-dbece21aad8c@huawei.com>
References: <20210326062412.1262-1-thunder.leizhen@huawei.com>
 <20210326062412.1262-6-thunder.leizhen@huawei.com>
 <e04d117a-4832-7f95-7adf-dbece21aad8c@huawei.com>
Message-ID: <b3bd3aed-f02f-2056-1d98-ef164974b0ea@huawei.com>



On 2021/4/16 23:55, John Garry wrote:
> On 26/03/2021 06:24, Zhen Lei wrote:
>> There are several spelling mistakes, as follows:
>> funcions ==> functions
>> distiguish ==> distinguish
>> detroyed ==> destroyed
>>
>> Signed-off-by: Zhen Lei<thunder.leizhen at huawei.com>
> 
> I think that there should be a /s/appropriatley/appropriately/ in iommu.c

OK, I will fix it in v2.

> 
> Thanks,
> john
> 
> .
> 



From daniel at 0x0f.com  Sat Apr 17 02:10:12 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Sat, 17 Apr 2021 10:10:12 +0900
Subject: [PATCH 0/3] ARM: mstar: Add initial support for M5Stack UnitV2
Message-ID: <20210417011015.2105280-1-daniel@0x0f.com>

This series adds basic support for the soon to be released M5Stack
UnitV2 based on the SigmaStar SSD202D.

With the rest of the commits in my tree the SPI NAND, ethernet, USB etc
should work so the UnitV2 should be fully usable with a mainline-ish
kernel.

Hopefully this will encourage someone else to help with cleaning
up and pushing the commits for these SoCs.

Link: https://m5stack-store.myshopify.com/products/unitv2-ai-camera-gc2145

Daniel Palmer (3):
  dt-bindings: vendor-prefixes: Add vendor prefix for M5Stack
  dt-bindings: arm: mstar: Add compatible for M5Stack UnitV2
  ARM: dts: mstar: Add a dts for M5Stack UnitV2

 .../devicetree/bindings/arm/mstar/mstar.yaml  |  1 +
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 ++
 arch/arm/boot/dts/Makefile                    |  1 +
 .../dts/mstar-infinity2m-ssd202d-unitv2.dts   | 25 +++++++++++++++++++
 4 files changed, 29 insertions(+)
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts

-- 
2.31.0



From daniel at 0x0f.com  Sat Apr 17 02:10:13 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Sat, 17 Apr 2021 10:10:13 +0900
Subject: [PATCH 1/3] dt-bindings: vendor-prefixes: Add vendor prefix for
 M5Stack
In-Reply-To: <20210417011015.2105280-1-daniel@0x0f.com>
References: <20210417011015.2105280-1-daniel@0x0f.com>
Message-ID: <20210417011015.2105280-2-daniel@0x0f.com>

M5Stack make various modules for STEM, Makers, IoT.
Their UnitV2 is based on a SigmaStar SSD202D SoC which
we already have some minimal support for so add a
prefix in preparation for UnitV2 board support.

Link: https://m5stack.com/
Signed-off-by: Daniel Palmer <daniel at 0x0f.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 f6064d84a424..7129fe3b9144 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -651,6 +651,8 @@ patternProperties:
     description: Liebherr-Werk Nenzing GmbH
   "^lxa,.*":
     description: Linux Automation GmbH
+  "^m5stack,.*":
+    description: M5Stack
   "^macnica,.*":
     description: Macnica Americas
   "^mantix,.*":
-- 
2.31.0



From daniel at 0x0f.com  Sat Apr 17 02:10:14 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Sat, 17 Apr 2021 10:10:14 +0900
Subject: [PATCH 2/3] dt-bindings: arm: mstar: Add compatible for M5Stack UnitV2
In-Reply-To: <20210417011015.2105280-1-daniel@0x0f.com>
References: <20210417011015.2105280-1-daniel@0x0f.com>
Message-ID: <20210417011015.2105280-3-daniel@0x0f.com>

Add a compatible for the M5Stack UnitV2 that is based on the
SigmaStar SSD202D (inifinity2m).

Signed-off-by: Daniel Palmer <daniel at 0x0f.com>
---
 Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
index 61d08c473eb8..a316eef1b728 100644
--- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
+++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml
@@ -24,6 +24,7 @@ properties:
         items:
           - enum:
               - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit
+              - m5stack,unitv2 # M5Stack UnitV2
           - const: mstar,infinity2m
 
       - description: infinity3 boards
-- 
2.31.0



From daniel at 0x0f.com  Sat Apr 17 02:10:15 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Sat, 17 Apr 2021 10:10:15 +0900
Subject: [PATCH 3/3] ARM: dts: mstar: Add a dts for M5Stack UnitV2
In-Reply-To: <20210417011015.2105280-1-daniel@0x0f.com>
References: <20210417011015.2105280-1-daniel@0x0f.com>
Message-ID: <20210417011015.2105280-4-daniel@0x0f.com>

M5Stack are releasing a new widget based on the
SigmaStar SSD202D. We have some support for the
SSD202D so lets add a dts for it.

Link: https://m5stack-store.myshopify.com/products/unitv2-ai-camera-gc2145
Signed-off-by: Daniel Palmer <daniel at 0x0f.com>
---
 arch/arm/boot/dts/Makefile                    |  1 +
 .../dts/mstar-infinity2m-ssd202d-unitv2.dts   | 25 +++++++++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..66ddc7d0bd03 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1397,6 +1397,7 @@ dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
 dtb-$(CONFIG_ARCH_MSTARV7) += \
 	mstar-infinity-msc313-breadbee_crust.dtb \
 	mstar-infinity2m-ssd202d-ssd201htv2.dtb \
+	mstar-infinity2m-ssd202d-unitv2.dtb \
 	mstar-infinity3-msc313e-breadbee.dtb \
 	mstar-mercury5-ssc8336n-midrived08.dtb
 dtb-$(CONFIG_ARCH_ASPEED) += \
diff --git a/arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts b/arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts
new file mode 100644
index 000000000000..a81684002e45
--- /dev/null
+++ b/arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2021 thingy.jp.
+ * Author: Daniel Palmer <daniel at thingy.jp>
+ */
+
+/dts-v1/;
+#include "mstar-infinity2m-ssd202d.dtsi"
+
+/ {
+	model = "UnitV2";
+	compatible = "m5stack,unitv2", "mstar,infinity2m";
+
+	aliases {
+		serial0 = &pm_uart;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&pm_uart {
+	status = "okay";
+};
-- 
2.31.0



From thunder.leizhen at huawei.com  Sat Apr 17 02:11:28 2021
From: thunder.leizhen at huawei.com (Leizhen (ThunderTown))
Date: Sat, 17 Apr 2021 09:11:28 +0800
Subject: [PATCH 0/8] iommu: fix a couple of spelling mistakes detected by
 codespell tool
In-Reply-To: <YHmsQtm4o5f7fAru@8bytes.org>
References: <20210326062412.1262-1-thunder.leizhen@huawei.com>
 <YHmsQtm4o5f7fAru@8bytes.org>
Message-ID: <2025c88d-0711-22c8-3e1c-2d8c9f053fbf@huawei.com>



On 2021/4/16 23:24, Joerg Roedel wrote:
> On Fri, Mar 26, 2021 at 02:24:04PM +0800, Zhen Lei wrote:
>> This detection and correction covers the entire driver/iommu directory.
>>
>> Zhen Lei (8):
>>   iommu/pamu: fix a couple of spelling mistakes
>>   iommu/omap: Fix spelling mistake "alignement" -> "alignment"
>>   iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical"
>>   iommu/sun50i: Fix spelling mistake "consits" -> "consists"
>>   iommu: fix a couple of spelling mistakes
>>   iommu/amd: fix a couple of spelling mistakes
>>   iommu/arm-smmu: Fix spelling mistake "initally" -> "initially"
>>   iommu/vt-d: fix a couple of spelling mistakes
> 
> This patch-set doesn't apply. Please re-send it as a single patch when
> v5.13-rc1 is released.

OK

> 
> Thanks,
> 
> 	Joerg
> 
> .
> 



From heying24 at huawei.com  Sat Apr 17 03:01:54 2021
From: heying24 at huawei.com (He Ying)
Date: Sat, 17 Apr 2021 10:01:54 +0800
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <87y2dis4d7.wl-maz@kernel.org>
References: <20210416062217.25157-1-heying24@huawei.com>
 <87y2dis4d7.wl-maz@kernel.org>
Message-ID: <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>

Hello Marc,


? 2021/4/16 22:15, Marc Zyngier ??:
> [+ Mark]
>
> On Fri, 16 Apr 2021 07:22:17 +0100,
> He Ying <heying24 at huawei.com> wrote:
>> We found this problem in our kernel src tree:
>>
>> [   14.816231] ------------[ cut here ]------------
>> [   14.816231] kernel BUG at irq.c:99!
>> [   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
>> [   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
>> [   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95-1.h1.AOS2.0.aarch64 #14
>> [   14.816233] Hardware name: evb (DT)
>> [   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
>> [   14.816234] pc : asm_nmi_enter+0x94/0x98
>> [   14.816235] lr : asm_nmi_enter+0x18/0x98
>> [   14.816235] sp : ffff000008003c50
>> [   14.816235] pmr_save: 00000070
>> [   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
>> [   14.816238] x27: 0000000000000000 x26: ffff000008004000
>> [   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
>> [   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
>> [   14.816241] x21: ffff000008003da0 x20: 0000000000000060
>> [   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
>> [   14.816243] x17: 0000000000000008 x16: 003d090000000000
>> [   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
>> [   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
>> [   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
>> [   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
>> [   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
>> [   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
>> [   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
>> [   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
>> [   14.816251] Call trace:
>> [   14.816251]  asm_nmi_enter+0x94/0x98
>> [   14.816251]  el1_irq+0x8c/0x180
>> [   14.816252]  gic_handle_irq+0xbc/0x2e4
>> [   14.816252]  el1_irq+0xcc/0x180
>> [   14.816253]  arch_timer_handler_virt+0x38/0x58
>> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
>> [   14.816253]  generic_handle_irq+0x34/0x50
>> [   14.816254]  __handle_domain_irq+0x68/0xc0
>> [   14.816254]  gic_handle_irq+0xf8/0x2e4
>> [   14.816255]  el1_irq+0xcc/0x180
>> [   14.816255]  arch_cpu_idle+0x34/0x1c8
>> [   14.816255]  default_idle_call+0x24/0x44
>> [   14.816256]  do_idle+0x1d0/0x2c8
>> [   14.816256]  cpu_startup_entry+0x28/0x30
>> [   14.816256]  rest_init+0xb8/0xc8
>> [   14.816257]  start_kernel+0x4c8/0x4f4
>> [   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
>> [   14.816258] Modules linked in: start_dp(O) smeth(O)
>> [   15.103092] ---[ end trace 701753956cb14aa8 ]---
>> [   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
>> [   15.103099] SMP: stopping secondary CPUs
>> [   15.103100] Kernel Offset: disabled
>> [   15.103100] CPU features: 0x36,a2400218
>> [   15.103100] Memory Limit: none
> Urgh...
>
>> Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
>> patches but doesn't support nested NMI. Its top relative commit is
>> commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs").
> Can you please reproduce it with mainline and without any backport?
> It is hard to reason about something that isn't a vanilla kernel.

I think our kernel is quite like v5.3 mainline. Reproducing it in v5.3 
mainline may

be a little difficult for us because our product needs some more self 
developed

patches to work.

>
>> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
>> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
>> means an interrupt preempts the other one and the new one is an NMI.
>> Furthermore, by adding some prints, we find the first irq also calls
>> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
>> is 1023. It enables irq by calling gic_arch_enable_irqs() in
>> gic_handle_irq(). At this moment, the second irq preempts the first irq
>> and it's an NMI but current context is already in nmi. So that may be
>> the problem.
> I'm not sure I get it. From the stack trace, I see this:
>
> [   14.816251]  asm_nmi_enter+0x94/0x98
> [   14.816251]  el1_irq+0x8c/0x180			(C)
> [   14.816252]  gic_handle_irq+0xbc/0x2e4
> [   14.816252]  el1_irq+0xcc/0x180			(B)
> [   14.816253]  arch_timer_handler_virt+0x38/0x58
> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> [   14.816253]  generic_handle_irq+0x34/0x50
> [   14.816254]  __handle_domain_irq+0x68/0xc0
> [   14.816254]  gic_handle_irq+0xf8/0x2e4
> [   14.816255]  el1_irq+0xcc/0x180			(A)
>
> which indicates that we preempted a timer interrupt (A) with another
> IRQ (B), itself immediately preempted by another IRQ (C)? That's
> indeed at least one too many.
>
> Can you please describe for each of (A), (B) and (C) whether they are
> spurious or not, what their priorities are if they aren't spurious?

Yes. I ignored interrupt (A). (B) is spurious and its priority is 0xa0 
and PMR is 0x70.

(C) is an NMI and its priority is 0x20. Note that GIC_PRIO_IRQON is 0xe0,

GIC_PRIO_IRQOFF is 0x60, GICD_INT_DEF_PRI is 0xa0 and GICD_INT_NMI_PRI is

0x20 in our kernel.

>> In my opinion, when handling spurious interrupts, we shouldn't enable irqs.
>> My reason is that for spurious interrupts we may enter nmi context in
>> el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
>> at this time, another NMI may happen and preempt this spurious interrupt
>> but the context is already in nmi. That causes a bug on if nested NMI is
>> not supported. Even for nested nmi, I think it's not a normal scenario.
> I would tend to agree that this isn't great. Actually, I'd probably
> move the check for a spurious interrupt right after the read of
> ICC_IAR1_EL1, because there is no real need to do anything else at
> that point.

So, we don't need to check NMI for spurious interrupts? Do you mean that 
spurious

interrupts' can't be NMIs? Or even spurious interrups are NMIs, we 
shouldn't do

anything for them? If so, I will move the check after the read of 
ICC_IAR1_EL1 and

send a V2.

>
> However, upstream is quite different from 4.19 in that respect, and
> I'm not sure if what I am looking at is what you are seeing with your
> older kernel.

I know that. And I look into all patches about arm64 pseudo NMIs. As I 
said before,

our kernel is very quite like v5.3 mainline. I think we are talking 
about the same thing.


In my opinion, since commit 17ce302f3117 ("arm64: Fix interrupt tracing 
in the presence of NMIs"),

spurious interrups can enter nmi context in interrupt entry because PMR 
can be GIC_PRIO_IRQOFF

for spurious interrupts. That means test_irqs_unmasked is not 0 and 
asm_nmi_enter is called.

 ?? (some el1_irq entry code from v5.3)

 ?? test_irqs_unmasked? res=x0, pmr=x20

 ?? cbz x0, 1f

 ?? bl asm_nmi_enter


And it then calls gic_handle_irq(). It doesn't call gic_handle_nmi() 
because its priority is not GICD_INT_NMI_PRI.

Then it enables irqs. If at that point another NMI comes and preempts 
it, which means NMI occurs in nmi

context. That may cause a bug on if nested NMI is not supported.

 ?? (some gic_handle_irq code from v5.3)

 ?? irqnr = gic_read_iar();

 ?? if (gic_supports_nmi() &&
 ? ? ?? unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
 ?????????? gic_handle_nmi(irqnr, 
regs);?????????????????????????????????? (C)
 ?????????? return;
 ?? }

 ?? if (gic_prio_masking_enabled()) {
 ???????? gic_pmr_mask_irqs();
gic_arch_enable_irqs(); (D)
 ?? }

>
> Thanks,
>
> 	M.
>
>> Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
>> Signed-off-by: He Ying <heying24 at huawei.com>
>> ---
>>   drivers/irqchip/irq-gic-v3.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>> index 94b89258d045..d3b52734a2c5 100644
>> --- a/drivers/irqchip/irq-gic-v3.c
>> +++ b/drivers/irqchip/irq-gic-v3.c
>> @@ -654,15 +654,15 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>>   		return;
>>   	}
>>   
>> +	/* Check for special IDs first */
>> +	if ((irqnr >= 1020 && irqnr <= 1023))
>> +		return;
>> +
>>   	if (gic_prio_masking_enabled()) {
>>   		gic_pmr_mask_irqs();
>>   		gic_arch_enable_irqs();
>>   	}
>>   
>> -	/* Check for special IDs first */
>> -	if ((irqnr >= 1020 && irqnr <= 1023))
>> -		return;
>> -
>>   	if (static_branch_likely(&supports_deactivate_key))
>>   		gic_write_eoir(irqnr);
>>   	else
>> -- 
>> 2.17.1
>>
>>


From willy at infradead.org  Sat Apr 17 03:45:22 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 03:45:22 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416230724.2519198-2-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
Message-ID: <20210417024522.GP2531743@casper.infradead.org>


Replacement patch to fix compiler warning.

From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
Date: Fri, 16 Apr 2021 16:34:55 -0400
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
To: brouer at redhat.com
Cc: linux-kernel at vger.kernel.org,
    linux-mm at kvack.org,
    netdev at vger.kernel.org,
    linuxppc-dev at lists.ozlabs.org,
    linux-arm-kernel at lists.infradead.org,
    linux-mips at vger.kernel.org,
    ilias.apalodimas at linaro.org,
    mcroce at linux.microsoft.com,
    grygorii.strashko at ti.com,
    arnd at kernel.org,
    hch at lst.de,
    linux-snps-arc at lists.infradead.org,
    mhocko at kernel.org,
    mgorman at suse.de

32-bit architectures which expect 8-byte alignment for 8-byte integers
and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
page inadvertently expanded in 2019.  When the dma_addr_t was added,
it forced the alignment of the union to 8 bytes, which inserted a 4 byte
gap between 'flags' and the union.

Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
This restores the alignment to that of an unsigned long, and also fixes a
potential problem where (on a big endian platform), the bit used to denote
PageTail could inadvertently get set, and a racing get_user_pages_fast()
could dereference a bogus compound_head().

Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 include/linux/mm_types.h |  4 ++--
 include/net/page_pool.h  | 12 +++++++++++-
 net/core/page_pool.c     | 12 +++++++-----
 3 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6613b26a8894..5aacc1c10a45 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -97,10 +97,10 @@ struct page {
 		};
 		struct {	/* page_pool used by netstack */
 			/**
-			 * @dma_addr: might require a 64-bit value even on
+			 * @dma_addr: might require a 64-bit value on
 			 * 32-bit architectures.
 			 */
-			dma_addr_t dma_addr;
+			unsigned long dma_addr[2];
 		};
 		struct {	/* slab, slob and slub */
 			union {
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index b5b195305346..ad6154dc206c 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
 
 static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
 {
-	return page->dma_addr;
+	dma_addr_t ret = page->dma_addr[0];
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
+	return ret;
+}
+
+static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
+{
+	page->dma_addr[0] = addr;
+	if (sizeof(dma_addr_t) > sizeof(unsigned long))
+		page->dma_addr[1] = addr >> 16 >> 16;
 }
 
 static inline bool is_page_pool_compiled_in(void)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index ad8b0707af04..f014fd8c19a6 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
 					  struct page *page,
 					  unsigned int dma_sync_size)
 {
+	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
+
 	dma_sync_size = min(dma_sync_size, pool->p.max_len);
-	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
+	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
 					 pool->p.offset, dma_sync_size,
 					 pool->p.dma_dir);
 }
@@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
 		put_page(page);
 		return NULL;
 	}
-	page->dma_addr = dma;
+	page_pool_set_dma_addr(page, dma);
 
 	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
 		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
@@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
 		 */
 		goto skip_dma_unmap;
 
-	dma = page->dma_addr;
+	dma = page_pool_get_dma_addr(page);
 
-	/* When page is unmapped, it cannot be returned our pool */
+	/* When page is unmapped, it cannot be returned to our pool */
 	dma_unmap_page_attrs(pool->p.dev, dma,
 			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
 			     DMA_ATTR_SKIP_CPU_SYNC);
-	page->dma_addr = 0;
+	page_pool_set_dma_addr(page, 0);
 skip_dma_unmap:
 	/* This may be the last page returned, releasing the pool, so
 	 * it is not safe to reference pool afterwards.
-- 
2.30.2



From willy at infradead.org  Sat Apr 17 04:19:06 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 04:19:06 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416190823.3b3aace0@carbon>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
 <20210416190823.3b3aace0@carbon>
Message-ID: <20210417031906.GQ2531743@casper.infradead.org>

On Fri, Apr 16, 2021 at 07:08:23PM +0200, Jesper Dangaard Brouer wrote:
> On Fri, 16 Apr 2021 16:27:55 +0100
> Matthew Wilcox <willy at infradead.org> wrote:
> 
> > On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > > See below patch.  Where I swap32 the dma address to satisfy
> > > page->compound having bit zero cleared. (It is the simplest fix I could
> > > come up with).  
> > 
> > I think this is slightly simpler, and as a bonus code that assumes the
> > old layout won't compile.
> 
> This is clever, I like it!  When reading the code one just have to
> remember 'unsigned long' size difference between 64-bit vs 32-bit.
> And I assume compiler can optimize the sizeof check out then doable.

I checked before/after with the replacement patch that doesn't
have compiler warnings.  On x86, there is zero codegen difference
(objdump -dr before/after matches exactly) for both x86-32 with 32-bit
dma_addr_t and x86-64.  For x86-32 with 64-bit dma_addr_t, the compiler
makes some different inlining decisions in page_pool_empty_ring(),
page_pool_put_page() and page_pool_put_page_bulk(), but it's not clear
to me that they're wrong.

Function                                     old     new   delta
page_pool_empty_ring                         387     307     -80
page_pool_put_page                           604     516     -88
page_pool_put_page_bulk                      690     517    -173



From rentao.bupt at gmail.com  Sat Apr 17 04:42:49 2021
From: rentao.bupt at gmail.com (rentao.bupt at gmail.com)
Date: Fri, 16 Apr 2021 20:42:49 -0700
Subject: [PATCH] watchdog: aspeed: fix hardware timeout calculation
Message-ID: <20210417034249.5978-1-rentao.bupt@gmail.com>

From: Tao Ren <rentao.bupt at gmail.com>

Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
ensure the reload value does not exceed the hardware limit.

Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
Reported-by: Amithash Prasad <amithash at fb.com>
Signed-off-by: Tao Ren <rentao.bupt at gmail.com>
---
 drivers/watchdog/aspeed_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index 7e00960651fa..507fd815d767 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -147,7 +147,7 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
 
 	wdd->timeout = timeout;
 
-	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
+	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
 
 	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
 	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
-- 
2.17.1



From linux at roeck-us.net  Sat Apr 17 05:20:48 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 16 Apr 2021 21:20:48 -0700
Subject: [PATCH] watchdog: aspeed: fix hardware timeout calculation
In-Reply-To: <20210417034249.5978-1-rentao.bupt@gmail.com>
References: <20210417034249.5978-1-rentao.bupt@gmail.com>
Message-ID: <20210417042048.GA109800@roeck-us.net>

On Fri, Apr 16, 2021 at 08:42:49PM -0700, rentao.bupt at gmail.com wrote:
> From: Tao Ren <rentao.bupt at gmail.com>
> 
> Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
> ensure the reload value does not exceed the hardware limit.
> 
> Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
> Reported-by: Amithash Prasad <amithash at fb.com>
> Signed-off-by: Tao Ren <rentao.bupt at gmail.com>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>  drivers/watchdog/aspeed_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index 7e00960651fa..507fd815d767 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -147,7 +147,7 @@ static int aspeed_wdt_set_timeout(struct watchdog_device *wdd,
>  
>  	wdd->timeout = timeout;
>  
> -	actual = min(timeout, wdd->max_hw_heartbeat_ms * 1000);
> +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
>  
>  	writel(actual * WDT_RATE_1MHZ, wdt->base + WDT_RELOAD_VALUE);
>  	writel(WDT_RESTART_MAGIC, wdt->base + WDT_RESTART);
> -- 
> 2.17.1
> 


From jernej.skrabec at siol.net  Sat Apr 17 07:07:28 2021
From: jernej.skrabec at siol.net (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Sat, 17 Apr 2021 08:07:28 +0200
Subject: [PATCH 4/8] iommu/sun50i: Fix spelling mistake "consits" ->
 "consists"
In-Reply-To: <20210326062412.1262-5-thunder.leizhen@huawei.com>
References: <20210326062412.1262-1-thunder.leizhen@huawei.com>
 <20210326062412.1262-5-thunder.leizhen@huawei.com>
Message-ID: <4000375.Ibcesr10vN@jernej-laptop>

Hi!

Dne petek, 26. marec 2021 ob 07:24:08 CEST je Zhen Lei napisal(a):
> There is a spelling mistake in a comment, fix it.
> 
> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
> ---
>  drivers/iommu/sun50i-iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Jernej Skrabec <jernej.skrabec at siol.net>

Best regards,
Jernej




From jernej.skrabec at siol.net  Sat Apr 17 07:31:39 2021
From: jernej.skrabec at siol.net (Jernej =?utf-8?B?xaBrcmFiZWM=?=)
Date: Sat, 17 Apr 2021 08:31:39 +0200
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
 <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
 <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
Message-ID: <9525152.Q8VVBrNj5Z@jernej-laptop>

CC Hans Verkuil

Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a):
> On 16/04/2021 11:58, Laurent Pinchart wrote:
> > Hi Neil,
> > 
> > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> >> This adds DW-HDMI driver a glue option to disable loading of the CEC
> >> sub-driver.
> >> 
> >> On some SoCs, the CEC functionality is enabled in the IP config bits, but
> >> the CEC bus is non-functional like on Amlogic SoCs, where the CEC config
> >> bit is set but the DW-HDMI CEC signal is not connected to a physical
> >> pin, leading to some confusion when the DW-HDMI CEC controller can't
> >> communicate on the bus.> 
> > If we can't trust the CEC config bit, would it be better to not use it
> > at all, and instead let each platform glue logic tell whether to enable
> > CEC or not ?
> 
> Actually, the CEC config bit is right, the HW exists and should be
> functional, but this bit doesn't tell if the CEC signal is connected to
> something.

I'm in favour of Neil's solution. Currently we have only one exception.

> 
> This lies in the IP integration, like other bits under the
> "amlogic,meson-*-dw-hdmi" umbrella.
> 
> The first attempt was by Hans using DT, but adding a property in DT for a
> vendor specific compatible doesn't make sense. Another idea would be to
> describe the CEC signal endpoint like we do for video signal, but I think
> this is out of scope and this solution is much simpler and straightforward,
> and it's more an exception than a general use case to solve.

Note that we still need DT property for disabling CEC. I have one Allwinner H3 
board where board designer decided to use GPIO CEC implementation instead of 
DW HDMI one (vendor Linux doesn't implement DW HDMI CEC driver). Other H3 
boards happily use DW HDMI CEC.

Best regards,
Jernej

> 
> Neil
> 
> >> Jernej Skrabec (1):
> >>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
> >>   
> >>     driver
> >> 
> >> Neil Armstrong (1):
> >>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
> >>  
> >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> >>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
> >>  include/drm/bridge/dw_hdmi.h              | 2 ++
> >>  3 files changed, 4 insertions(+), 1 deletion(-)






From qii.wang at mediatek.com  Sat Apr 17 07:46:52 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Sat, 17 Apr 2021 14:46:52 +0800
Subject: [PATCH 3/3] i2c: mediatek: Use scl_int_delay_ns to compensate
 clock-stretching
In-Reply-To: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
Message-ID: <1618642012-10444-4-git-send-email-qii.wang@mediatek.com>

The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due
to device clock-stretch or circuit loss, we could get a suitable
scl_int_delay_ns from i2c_timings to compensate these parameters
to meet the spec via EXT_CONF register.

Signed-off-by: Qii Wang <qii.wang at mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index bf25acb..5ddfa4e 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -231,6 +231,7 @@ struct mtk_i2c {
 	struct i2c_adapter adap;	/* i2c host adapter */
 	struct device *dev;
 	struct completion msg_complete;
+	struct i2c_timings timing_info;
 
 	/* set in i2c probe */
 	void __iomem *base;		/* i2c base addr */
@@ -607,7 +608,8 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
 	else
 		clk_ns = sample_ns / 2;
 
-	su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
+	su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns +
+				  i2c->timing_info.scl_int_delay_ns, clk_ns);
 	if (su_sta_cnt > max_sta_cnt)
 		return -1;
 
@@ -1176,6 +1178,8 @@ static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c)
 	i2c->use_push_pull =
 		of_property_read_bool(np, "mediatek,use-push-pull");
 
+	i2c_parse_fw_timings(i2c->dev, &i2c->timing_info, true);
+
 	return 0;
 }
 
-- 
1.9.1

From qii.wang at mediatek.com  Sat Apr 17 07:46:49 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Sat, 17 Apr 2021 14:46:49 +0800
Subject: [PATCH 0/3] Add some fix patches
Message-ID: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>

This series are based on 5.12-rc2 and we provide three i2c patches
to fix some historical issues.

Qii Wang (3):
  i2c: mediatek: Fix send master code at more than 1MHz
  i2c: mediatek: Fix wrong dma sync flag
  i2c: mediatek: Use scl_int_delay_ns to compensate clock-stretching

 drivers/i2c/busses/i2c-mt65xx.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

-- 
1.9.1

From qii.wang at mediatek.com  Sat Apr 17 07:46:50 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Sat, 17 Apr 2021 14:46:50 +0800
Subject: [PATCH 1/3] i2c: mediatek: Fix send master code at more than 1MHz
In-Reply-To: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
Message-ID: <1618642012-10444-2-git-send-email-qii.wang@mediatek.com>

There are some omissions in the previous patch about replacing
I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and
need to fix it.

Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz")
Signed-off-by: Qii Wang <qii.wang at mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ffd2f3..3e34261 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -564,7 +564,7 @@ static const struct i2c_spec_values *mtk_i2c_get_spec(unsigned int speed)
 
 static int mtk_i2c_max_step_cnt(unsigned int target_speed)
 {
-	if (target_speed > I2C_MAX_FAST_MODE_FREQ)
+	if (target_speed > I2C_MAX_FAST_MODE_PLUS_FREQ)
 		return MAX_HS_STEP_CNT_DIV;
 	else
 		return MAX_STEP_CNT_DIV;
@@ -635,7 +635,7 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
 	if (sda_min > sda_max)
 		return -3;
 
-	if (check_speed > I2C_MAX_FAST_MODE_FREQ) {
+	if (check_speed > I2C_MAX_FAST_MODE_PLUS_FREQ) {
 		if (i2c->dev_comp->ltiming_adjust) {
 			i2c->ac_timing.hs = I2C_TIME_DEFAULT_VALUE |
 				(sample_cnt << 12) | (high_cnt << 8);
@@ -850,7 +850,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 
 	control_reg = mtk_i2c_readw(i2c, OFFSET_CONTROL) &
 			~(I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS);
-	if ((i2c->speed_hz > I2C_MAX_FAST_MODE_FREQ) || (left_num >= 1))
+	if ((i2c->speed_hz > I2C_MAX_FAST_MODE_PLUS_FREQ) || (left_num >= 1))
 		control_reg |= I2C_CONTROL_RS;
 
 	if (i2c->op == I2C_MASTER_WRRD)
@@ -1067,7 +1067,8 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 		}
 	}
 
-	if (i2c->auto_restart && num >= 2 && i2c->speed_hz > I2C_MAX_FAST_MODE_FREQ)
+	if (i2c->auto_restart && num >= 2 &&
+		i2c->speed_hz > I2C_MAX_FAST_MODE_PLUS_FREQ)
 		/* ignore the first restart irq after the master code,
 		 * otherwise the first transfer will be discarded.
 		 */
-- 
1.9.1

From qii.wang at mediatek.com  Sat Apr 17 07:46:51 2021
From: qii.wang at mediatek.com (Qii Wang)
Date: Sat, 17 Apr 2021 14:46:51 +0800
Subject: [PATCH 2/3] i2c: mediatek: Fix wrong dma sync flag
In-Reply-To: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
Message-ID: <1618642012-10444-3-git-send-email-qii.wang@mediatek.com>

The right flag is apdma_sync when apdma remove hand-shake signel.

Signed-off-by: Qii Wang <qii.wang at mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 3e34261..bf25acb 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -479,7 +479,7 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
 {
 	u16 control_reg;
 
-	if (i2c->dev_comp->dma_sync) {
+	if (i2c->dev_comp->apdma_sync) {
 		writel(I2C_DMA_WARM_RST, i2c->pdmabase + OFFSET_RST);
 		udelay(10);
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST);
-- 
1.9.1

From dqfext at gmail.com  Sat Apr 17 08:29:04 2021
From: dqfext at gmail.com (DENG Qingfang)
Date: Sat, 17 Apr 2021 15:29:04 +0800
Subject: [PATCH v2 net-next] net: ethernet: mediatek: fix a typo bug in flow
 offloading
Message-ID: <20210417072905.207032-1-dqfext@gmail.com>

Issue was traffic problems after a while with increased ping times if
flow offload is active. It turns out that key_offset with cookie is
needed in rhashtable_params but was re-assigned to head_offset.
Fix the assignment.

Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support")
Signed-off-by: DENG Qingfang <dqfext at gmail.com>
---
v1 -> v2:
  Refined commit message according to Frank.

 drivers/net/ethernet/mediatek/mtk_ppe_offload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
index 4975106fbc42..f47f319f3ae0 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe_offload.c
@@ -43,7 +43,7 @@ struct mtk_flow_entry {
 
 static const struct rhashtable_params mtk_flow_ht_params = {
 	.head_offset = offsetof(struct mtk_flow_entry, node),
-	.head_offset = offsetof(struct mtk_flow_entry, cookie),
+	.key_offset = offsetof(struct mtk_flow_entry, cookie),
 	.key_len = sizeof(unsigned long),
 	.automatic_shrinking = true,
 };
-- 
2.25.1



From brouer at redhat.com  Sat Apr 17 08:34:15 2021
From: brouer at redhat.com (Jesper Dangaard Brouer)
Date: Sat, 17 Apr 2021 09:34:15 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416230724.2519198-2-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
Message-ID: <20210417093415.41bcfde7@carbon>

On Sat, 17 Apr 2021 00:07:23 +0100
"Matthew Wilcox (Oracle)" <willy at infradead.org> wrote:

> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
> 
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
> 
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---

Acked-by: Jesper Dangaard Brouer <brouer at redhat.com>

Thanks you Matthew for working on a fix for this.  It's been a pleasure
working with you and exchanging crazy ideas with you for solving this.
Most of them didn't work out, especially those that came to me during
restless nights ;-).

Having worked through the other solutions, some very intrusive and some
could even be consider ugly.  I think we have a good and non-intrusive
solution/workaround in this patch.  Thanks!


>  include/linux/mm_types.h |  4 ++--
>  include/net/page_pool.h  | 12 +++++++++++-
>  net/core/page_pool.c     | 12 +++++++-----
>  3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>  		};
>  		struct {	/* page_pool used by netstack */
>  			/**
> -			 * @dma_addr: might require a 64-bit value even on
> +			 * @dma_addr: might require a 64-bit value on
>  			 * 32-bit architectures.
>  			 */
> -			dma_addr_t dma_addr;
> +			unsigned long dma_addr[2];
>  		};
>  		struct {	/* slab, slob and slub */
>  			union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..db7c7020746a 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>  
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 32;
> +	return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +	page->dma_addr[0] = addr;
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		page->dma_addr[1] = addr >> 32;
>  }
>  
>  static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
>  					  struct page *page,
>  					  unsigned int dma_sync_size)
>  {
> +	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
>  	dma_sync_size = min(dma_sync_size, pool->p.max_len);
> -	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> +	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>  					 pool->p.offset, dma_sync_size,
>  					 pool->p.dma_dir);
>  }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
>  		put_page(page);
>  		return NULL;
>  	}
> -	page->dma_addr = dma;
> +	page_pool_set_dma_addr(page, dma);
>  
>  	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
>  		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
>  		 */
>  		goto skip_dma_unmap;
>  
> -	dma = page->dma_addr;
> +	dma = page_pool_get_dma_addr(page);
>  
> -	/* When page is unmapped, it cannot be returned our pool */
> +	/* When page is unmapped, it cannot be returned to our pool */
>  	dma_unmap_page_attrs(pool->p.dev, dma,
>  			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
>  			     DMA_ATTR_SKIP_CPU_SYNC);
> -	page->dma_addr = 0;
> +	page_pool_set_dma_addr(page, 0);
>  skip_dma_unmap:
>  	/* This may be the last page returned, releasing the pool, so
>  	 * it is not safe to reference pool afterwards.



-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer



From frank-w at public-files.de  Sat Apr 17 08:34:42 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Sat, 17 Apr 2021 09:34:42 +0200
Subject: [PATCH v2 net-next] net: ethernet: mediatek: fix a typo bug in
 flow offloading
In-Reply-To: <20210417072905.207032-1-dqfext@gmail.com>
References: <20210417072905.207032-1-dqfext@gmail.com>
Message-ID: <E7AA60BD-142A-4F25-9AFC-D04D48EE4B8E@public-files.de>

Tested on Bananapi-r2 (please see my mt7623 patch for supporting offloading) with ~300 iperf3 iterations and uptime >6h

Tested-by: Frank Wunderlich <frank-w at public-files.de>
regards Frank


From tony at atomide.com  Sat Apr 17 09:28:28 2021
From: tony at atomide.com (Tony Lindgren)
Date: Sat, 17 Apr 2021 11:28:28 +0300
Subject: [PATCH] gpio: omap: Save and restore sysconfig
In-Reply-To: <67113b0b-5e5f-b2f4-1b1c-b58a1055f0ed@ti.com>
References: <20210415085305.56413-1-tony@atomide.com>
 <67113b0b-5e5f-b2f4-1b1c-b58a1055f0ed@ti.com>
Message-ID: <YHqcLHxnCDfcd+6s@atomide.com>

* Grygorii Strashko <grygorii.strashko at ti.com> [210415 23:48]:
> On 15/04/2021 11:53, Tony Lindgren wrote:
> > As we are using cpu_pm to save and restore context, we must also save and
> > restore the timer sysconfig register TIOCP_CFG. This is needed because
> > we are not calling PM runtime functions at all with cpu_pm.
> 
> Smth. is wrong with description.

Oops yeah sorry about that. Both timer-ti-dm and gpio-omap suffer from
the same issue since the cpu_pm conversion. Will post v2.

Regards,

Tony


From tony at atomide.com  Sat Apr 17 09:38:39 2021
From: tony at atomide.com (Tony Lindgren)
Date: Sat, 17 Apr 2021 11:38:39 +0300
Subject: [PATCHv2] gpio: omap: Save and restore sysconfig
Message-ID: <20210417083839.46985-1-tony@atomide.com>

As we are using cpu_pm to save and restore context, we must also save and
restore the GPIO sysconfig register. This is needed because we are not
calling PM runtime functions at all with cpu_pm.

We need to save the sysconfig on idle as it's value can get reconfigured by
PM runtime and can be different from the init time value. Device specific
flags like "ti,no-idle-on-init" can affect the init value.

Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
Cc: Adam Ford <aford173 at gmail.com>
Cc: Andreas Kemnade <andreas at kemnade.info>
Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/gpio/gpio-omap.c                | 9 +++++++++
 include/linux/platform_data/gpio-omap.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -29,6 +29,7 @@
 #define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF
 
 struct gpio_regs {
+	u32 sysconfig;
 	u32 irqenable1;
 	u32 irqenable2;
 	u32 wake_en;
@@ -1069,6 +1070,7 @@ static void omap_gpio_init_context(struct gpio_bank *p)
 	const struct omap_gpio_reg_offs *regs = p->regs;
 	void __iomem *base = p->base;
 
+	p->context.sysconfig	= readl_relaxed(base + regs->sysconfig);
 	p->context.ctrl		= readl_relaxed(base + regs->ctrl);
 	p->context.oe		= readl_relaxed(base + regs->direction);
 	p->context.wake_en	= readl_relaxed(base + regs->wkup_en);
@@ -1088,6 +1090,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
 	const struct omap_gpio_reg_offs *regs = bank->regs;
 	void __iomem *base = bank->base;
 
+	writel_relaxed(bank->context.sysconfig, base + regs->sysconfig);
 	writel_relaxed(bank->context.wake_en, base + regs->wkup_en);
 	writel_relaxed(bank->context.ctrl, base + regs->ctrl);
 	writel_relaxed(bank->context.leveldetect0, base + regs->leveldetect0);
@@ -1115,6 +1118,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
 
 	bank->saved_datain = readl_relaxed(base + bank->regs->datain);
 
+	/* Save syconfig, it's runtime value can be different from init value */
+	if (bank->loses_context)
+		bank->context.sysconfig = readl_relaxed(base + bank->regs->sysconfig);
+
 	if (!bank->enabled_non_wakeup_gpios)
 		goto update_gpio_context_count;
 
@@ -1279,6 +1286,7 @@ static int gpio_omap_cpu_notifier(struct notifier_block *nb,
 
 static const struct omap_gpio_reg_offs omap2_gpio_regs = {
 	.revision =		OMAP24XX_GPIO_REVISION,
+	.sysconfig =		OMAP24XX_GPIO_SYSCONFIG,
 	.direction =		OMAP24XX_GPIO_OE,
 	.datain =		OMAP24XX_GPIO_DATAIN,
 	.dataout =		OMAP24XX_GPIO_DATAOUT,
@@ -1302,6 +1310,7 @@ static const struct omap_gpio_reg_offs omap2_gpio_regs = {
 
 static const struct omap_gpio_reg_offs omap4_gpio_regs = {
 	.revision =		OMAP4_GPIO_REVISION,
+	.sysconfig =		OMAP4_GPIO_SYSCONFIG,
 	.direction =		OMAP4_GPIO_OE,
 	.datain =		OMAP4_GPIO_DATAIN,
 	.dataout =		OMAP4_GPIO_DATAOUT,
diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@ -85,6 +85,7 @@
  * omap2+ specific GPIO registers
  */
 #define OMAP24XX_GPIO_REVISION		0x0000
+#define OMAP24XX_GPIO_SYSCONFIG		0x0010
 #define OMAP24XX_GPIO_IRQSTATUS1	0x0018
 #define OMAP24XX_GPIO_IRQSTATUS2	0x0028
 #define OMAP24XX_GPIO_IRQENABLE2	0x002c
@@ -108,6 +109,7 @@
 #define OMAP24XX_GPIO_SETDATAOUT	0x0094
 
 #define OMAP4_GPIO_REVISION		0x0000
+#define OMAP4_GPIO_SYSCONFIG		0x0010
 #define OMAP4_GPIO_EOI			0x0020
 #define OMAP4_GPIO_IRQSTATUSRAW0	0x0024
 #define OMAP4_GPIO_IRQSTATUSRAW1	0x0028
@@ -148,6 +150,7 @@
 #ifndef __ASSEMBLER__
 struct omap_gpio_reg_offs {
 	u16 revision;
+	u16 sysconfig;
 	u16 direction;
 	u16 datain;
 	u16 dataout;
-- 
2.31.1


From yuzenghui at huawei.com  Sat Apr 17 09:42:37 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 16:42:37 +0800
Subject: [PATCH v19 7/7] ptp: arm/arm64: Enable ptp_kvm for arm/arm64
In-Reply-To: <20210330145430.996981-8-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-8-maz@kernel.org>
Message-ID: <d85fc46b-2076-ee0b-ac73-f7a3f393d87f@huawei.com>

On 2021/3/30 22:54, Marc Zyngier wrote:
> +int kvm_arch_ptp_init(void)
> +{
> +	int ret;
> +
> +	ret = kvm_arm_hyp_service_available(ARM_SMCCC_KVM_FUNC_PTP);
> +	if (ret <= 0)

kvm_arm_hyp_service_available() returns boolean. Maybe write as ?

	bool ret;

	ret = kvm_arm_hyp_service_available();
	if (!ret)
		return -ENODEV;

> +		return -EOPNOTSUPP;
> +
> +	return 0;
> +}


From yuzenghui at huawei.com  Sat Apr 17 09:59:39 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 16:59:39 +0800
Subject: [PATCH v19 6/7] KVM: arm64: Add support for the KVM PTP service
In-Reply-To: <20210330145430.996981-7-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-7-maz@kernel.org>
Message-ID: <5aadf0b4-b9e5-8521-db60-52a0f319cf28@huawei.com>

On 2021/3/30 22:54, Marc Zyngier wrote:
> +PTP_KVM support for arm/arm64
> +=============================
> +
> +PTP_KVM is used for high precision time sync between host and guests.
> +It relies on transferring the wall clock and counter value from the
> +host to the guest using a KVM-specific hypercall.
> +
> +* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001

Per include/linux/arm-smccc.h, this should be
ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.

> +
> +This hypercall uses the SMC32/HVC32 calling convention:
> +
> +ARM_SMCCC_HYP_KVM_PTP_FUNC_ID

ditto

> +    =============    ==========    ==========
> +    Function ID:     (uint32)      0x86000001
> +    Arguments:       (uint32)      KVM_PTP_VIRT_COUNTER(0)
> +                                   KVM_PTP_PHYS_COUNTER(1)


From maz at kernel.org  Sat Apr 17 10:05:28 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 17 Apr 2021 10:05:28 +0100
Subject: [PATCH v19 7/7] ptp: arm/arm64: Enable ptp_kvm for arm/arm64
In-Reply-To: <d85fc46b-2076-ee0b-ac73-f7a3f393d87f@huawei.com>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-8-maz@kernel.org>
 <d85fc46b-2076-ee0b-ac73-f7a3f393d87f@huawei.com>
Message-ID: <87wnt1s2lj.wl-maz@kernel.org>

On Sat, 17 Apr 2021 09:42:37 +0100,
Zenghui Yu <yuzenghui at huawei.com> wrote:
> 
> On 2021/3/30 22:54, Marc Zyngier wrote:
> > +int kvm_arch_ptp_init(void)
> > +{
> > +	int ret;
> > +
> > +	ret = kvm_arm_hyp_service_available(ARM_SMCCC_KVM_FUNC_PTP);
> > +	if (ret <= 0)
> 
> kvm_arm_hyp_service_available() returns boolean. Maybe write as ?
> 
> 	bool ret;
> 
> 	ret = kvm_arm_hyp_service_available();
> 	if (!ret)
> 		return -ENODEV;

Fixed in 300bb1fe7671, as previously reported by Dan Carpenter in [1].

Thanks,

	M.

https://lore.kernel.org/r/20210331043704.GG2065 at kadam

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


From maz at kernel.org  Sat Apr 17 10:10:47 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sat, 17 Apr 2021 10:10:47 +0100
Subject: [PATCH v19 6/7] KVM: arm64: Add support for the KVM PTP service
In-Reply-To: <5aadf0b4-b9e5-8521-db60-52a0f319cf28@huawei.com>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-7-maz@kernel.org>
 <5aadf0b4-b9e5-8521-db60-52a0f319cf28@huawei.com>
Message-ID: <87v98ls2co.wl-maz@kernel.org>

On Sat, 17 Apr 2021 09:59:39 +0100,
Zenghui Yu <yuzenghui at huawei.com> wrote:
> 
> On 2021/3/30 22:54, Marc Zyngier wrote:
> > +PTP_KVM support for arm/arm64
> > +=============================
> > +
> > +PTP_KVM is used for high precision time sync between host and guests.
> > +It relies on transferring the wall clock and counter value from the
> > +host to the guest using a KVM-specific hypercall.
> > +
> > +* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
> 
> Per include/linux/arm-smccc.h, this should be
> ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.

Well spotted. Care to send a patch on top of my kvm-arm64/ptp branch?

Thanks,

	M.

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


From yuzenghui at huawei.com  Sat Apr 17 10:27:11 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 17:27:11 +0800
Subject: [PATCH v19 4/7] time: Add mechanism to recognize clocksource in
 time_get_snapshot
In-Reply-To: <20210330145430.996981-5-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-5-maz@kernel.org>
Message-ID: <6e5fb440-156d-2b18-b3cd-89b1a09b0239@huawei.com>

On 2021/3/30 22:54, Marc Zyngier wrote:
> -	u64		cycles;
> -	ktime_t		real;
> -	ktime_t		raw;
> -	unsigned int	clock_was_set_seq;
> -	u8		cs_was_changed_seq;
> +	u64			cycles;
> +	ktime_t			real;
> +	ktime_t			raw;
> +	enum clocksource_ids	cs_id;

nit: worth adding a description for it (on top of the structure)?

> +	unsigned int		clock_was_set_seq;
> +	u8			cs_was_changed_seq;


From yuzenghui at huawei.com  Sat Apr 17 10:49:09 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 17:49:09 +0800
Subject: [PATCH v19 1/7] arm/arm64: Probe for the presence of KVM
 hypervisor
In-Reply-To: <20210330145430.996981-2-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-2-maz@kernel.org>
Message-ID: <41707ee7-da5e-896b-6362-18cfcf272b5c@huawei.com>

On 2021/3/30 22:54, Marc Zyngier wrote:
>  #define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED	1

I think it'd be better to keep this definition together with other
wa Function IDs. It's only a cosmetic comment anyway.


Zenghui


From yangyicong at hisilicon.com  Sat Apr 17 11:17:07 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Sat, 17 Apr 2021 18:17:07 +0800
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
Message-ID: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>

[RESEND with perf and coresight folks Cc'ed]

HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
integrated Endpoint (RCiEP) device, providing the capability
to dynamically monitor and tune the PCIe traffic (tune),
and trace the TLP headers (trace).

PTT tune is designed for monitoring and adjusting PCIe link parameters.
We provide several parameters of the PCIe link. Through the driver,
user can adjust the value of certain parameter to affect the PCIe link
for the purpose of enhancing the performance in certian situation.

PTT trace is designed for dumping the TLP headers to the memory, which
can be used to analyze the transactions and usage condition of the PCIe
Link. Users can choose filters to trace headers, by either requester
ID, or those downstream of a set of Root Ports on the same core of the
PTT device. It's also supported to trace the headers of certain type and
of certain direction.

We use debugfs to expose the interface. For tune, one parameter is a
debugfs file and user can set/get the value by reading/writing the
file. For trace, we have several control files for the user to
configure the trace parameters like filters, TLP type and format,
the desired trace data size and so on. There is one data file for
dumping the traced data to the user. The traced data maybe hundreds
of megabytes so sysfs cannot support. The reason for debugfs rather
than character device is that we don't want to have additional
userspace tools. The operation through debugfs is easier and a bit
like ftrace.

The reason for not using perf is because there is no current support
for uncore tracing in the perf facilities. We have our own format
of data and don't need perf doing the parsing. The setting through
perf tools doesn't seem to be friendly as well. For example,
we cannot count on perf to decode the usual format BDF number like
<domain>:<bus>:<dev>.<fn>, which user can use to filter the TLP
headers through the PTT device.

A similar approach for implementing this function is ETM, which use
sysfs for configuring and a character device for dumping data.

Greg has some comments on our implementation and doesn't advocate
to build driver on debugfs [1]. So I resend this series to
collect more feedbacks on the implementation of this driver.

Hi perf and ETM related experts, is it suggested to adapt this driver
to perf? Or is the debugfs approach acceptable? Otherwise use
sysfs + character device like ETM and use perf tools for decoding it?
Any comments is welcomed.

[1] https://lore.kernel.org/linux-pci/1617713154-35533-1-git-send-email-yangyicong at hisilicon.com/

Yicong Yang (4):
  hwtracing: Add trace function support for HiSilicon PCIe Tune and
    Trace device
  hwtracing: Add tune function support for HiSilicon PCIe Tune and Trace
    device
  docs: Add HiSilicon PTT device driver documentation
  MAINTAINERS: Add maintainer for HiSilicon PTT driver

 Documentation/trace/hisi-ptt.rst       |  326 +++++++
 MAINTAINERS                            |    7 +
 drivers/Makefile                       |    1 +
 drivers/hwtracing/Kconfig              |    2 +
 drivers/hwtracing/hisilicon/Kconfig    |   11 +
 drivers/hwtracing/hisilicon/Makefile   |    2 +
 drivers/hwtracing/hisilicon/hisi_ptt.c | 1636 ++++++++++++++++++++++++++++++++
 7 files changed, 1985 insertions(+)
 create mode 100644 Documentation/trace/hisi-ptt.rst
 create mode 100644 drivers/hwtracing/hisilicon/Kconfig
 create mode 100644 drivers/hwtracing/hisilicon/Makefile
 create mode 100644 drivers/hwtracing/hisilicon/hisi_ptt.c

-- 
2.8.1



From yangyicong at hisilicon.com  Sat Apr 17 11:17:10 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Sat, 17 Apr 2021 18:17:10 +0800
Subject: [PATCH RESEND 3/4] docs: Add HiSilicon PTT device driver documentation
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <1618654631-42454-4-git-send-email-yangyicong@hisilicon.com>

Document the introduction and usage of HiSilicon PTT device driver.

Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
---
 Documentation/trace/hisi-ptt.rst | 326 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 326 insertions(+)
 create mode 100644 Documentation/trace/hisi-ptt.rst

diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
new file mode 100644
index 0000000..f093846
--- /dev/null
+++ b/Documentation/trace/hisi-ptt.rst
@@ -0,0 +1,326 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+HiSilicon PCIe Tune and Trace device
+======================================
+
+Introduction
+============
+
+HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
+integrated Endpoint (RCiEP) device, providing the capability
+to dynamically monitor and tune the PCIe link's events (tune),
+and trace the TLP headers (trace). The two functions are independent,
+but is recommended to use them together to analyze and enhance the
+PCIe link's performance.
+
+On Kunpeng 930 SoC, the PCIe Root Complex is composed of several
+PCIe cores. Each PCIe core includes several Root Ports and a PTT
+RCiEP, like below. The PTT device is capable of tuning and
+tracing the link of the PCIe core.
+::
+          +--------------Core 0-------+
+          |       |       [   PTT   ] |
+          |       |       [Root Port]---[Endpoint]
+          |       |       [Root Port]---[Endpoint]
+          |       |       [Root Port]---[Endpoint]
+    Root Complex  |------Core 1-------+
+          |       |       [   PTT   ] |
+          |       |       [Root Port]---[ Switch ]---[Endpoint]
+          |       |       [Root Port]---[Endpoint] `-[Endpoint]
+          |       |       [Root Port]---[Endpoint]
+          +---------------------------+
+
+The PTT device driver cannot be loaded if debugfs is not mounted.
+Each PTT device will be presented under /sys/kernel/debugfs/hisi_ptt
+as its root directory, with name of its BDF number.
+::
+
+    /sys/kernel/debug/hisi_ptt/<domain>:<bus>:<device>.<function>
+
+Tune
+====
+
+PTT tune is designed for monitoring and adjusting PCIe link parameters (events).
+Currently we support events in 4 classes. The scope of the events
+covers the PCIe core to which the PTT device belongs.
+
+Each event is presented as a file under $(PTT root dir)/$(BDF)/tune, and
+mostly a simple open/read/write/close cycle will be used to tune
+the event.
+::
+    $ cd /sys/kernel/debug/hisi_ptt/$(BDF)/tune
+    $ ls
+    qos_tx_cpl    qos_tx_np    qos_tx_p
+    tx_path_rx_req_alloc_buf_level
+    tx_path_tx_req_alloc_buf_level
+    $ cat qos_tx_dp
+    1
+    $ echo 2 > qos_tx_dp
+    $ cat qos_tx_dp
+    2
+
+Current value (numerical value) of the event can be simply read
+from the file, and the desired value written to the file to tune.
+
+1. Tx path QoS control
+------------------------
+
+The following files are provided to tune the QoS of the tx path of
+the PCIe core.
+
+- qos_tx_cpl: weight of Tx completion TLPs
+- qos_tx_np: weight of Tx non-posted TLPs
+- qos_tx_p: weight of Tx posted TLPs
+
+The weight influences the proportion of certain packets on the PCIe link.
+For example, for the storage scenario, increase the proportion
+of the completion packets on the link to enhance the performance as
+more completions are consumed.
+
+The available tune data of these events is [0, 1, 2].
+Writing a negative value will return an error, and out of range
+values will be converted to 2. Note that the event value just
+indicates a probable level, but is not precise.
+
+2. Tx path buffer control
+-------------------------
+
+Following files are provided to tune the buffer of tx path of the PCIe core.
+
+- tx_path_rx_req_alloc_buf_level: watermark of Rx requested
+- tx_path_tx_req_alloc_buf_level: watermark of Tx requested
+
+These events influence the watermark of the buffer allocated for each
+type. Rx means the inbound while Tx means outbound. The packets will
+be stored in the buffer first and then posted either when the watermark
+reached or when timed out. For a busy direction, you should increase
+the related buffer watermark to avoid frequently posting and thus
+enhance the performance. In most cases just keep the default value.
+
+The available tune data of above events is [0, 1, 2].
+Writing a negative value will return an error, and out of range
+values will be converted to 2. Note that the event value just
+indicates a probable level, but is not precise.
+
+Trace
+=====
+
+PTT trace is designed for dumping the TLP headers to the memory, which
+can be used to analyze the transactions and usage condition of the PCIe
+Link. You can choose to filter the traced headers by either requester ID,
+or those downstream of a set of Root Ports on the same core of the PTT
+device. It's also supported to trace the headers of certain type and of
+certain direction.
+
+In order to start trace, you need to configure the parameters first.
+The parameters files are provided under $(PTT root dir)/$(BDF)/trace.
+::
+    $ cd /sys/kernel/debug/hisi_ptt/$(BDF)/trace
+    $ ls
+    free_buffer     filter      buflet_nums     buflet_size
+    direction       type        data            trace_on
+    data_format
+
+1. filter
+---------
+
+You can configure the filter of TLP headers through the file. The filter
+is provided as BDF numbers of either Root Port or subordinates, which
+belong to the same PCIe core. You can get the filters available and
+currently configured by reading the file, and write the desired BDF to
+the file to set the filters. There is no default filter, which means you
+must specify at least one filter before starting tracing. Writing an
+invalid BDF (not in the available list) will return a failure.
+::
+    $ echo 0000:80:04.0 > filter
+    $ cat filter
+    #### Root Ports ####
+    0000:80:00.0
+    [0000:80:04.0]
+    #### Functions ####
+    0000:81:00.0
+    0000:81:00.1
+    0000:82:00.0
+
+Note that multiple Root Ports can be specified at one time, but only
+one Endpoint function can be specified in one trace. Specifying both
+Root Port and function at the same time is not supported.
+
+If no filter is available, reading the filter will get the hint.
+::
+    $ cat filter
+    #### No available filter ####
+
+The filter can be dynamically updated, which means you can always
+get correct filter information when hotplug events happen, or
+when you manually remove/rescan the devices.
+
+2. type
+-------
+
+You can trace the TLP headers of certain types by configuring the file.
+Reading the file will get available types and current setting, and write
+the desired type to the file to configure. The default type is
+`posted_request`. Write the types not in the available list will return
+a failure.
+::
+    $ echo completion > type
+    $ cat type
+    all  posted_request  non-posted_request  [completion]
+
+3. direction
+------------
+
+You can trace the TLP headers from certain direction, which is relative
+to the Root Port or the PCIe core. Read the file to get available
+directions and current configurition, and write the desired direction
+to configure. The default value is `rx` and any invalid direction will
+return a failure. Note `rxtx_no_dma_p2p` means the headers of both
+directions, but not include P2P DMA access.
+::
+    $ echo rxtx > direction
+    $ cat direction
+    rx  tx  [rxtx]  rxtx_no_dma_p2p
+
+4. buflet_size
+--------------
+
+The traced TLP headers will be written to the memory allocated
+by the driver. The hardware accepts 4 DMA address with same size,
+and writes the buflet sequentially like below. If DMA addr 3 is
+finished and the trace is still on, it will return to addr 0.
+Driver will allocate each DMA buffer (we call it buflet).
+The finished buflet will be replaced with a new one, so
+a long time trace can be achieved.
+::
+    +->[DMA addr 0]->[DMA addr 1]->[DMA addr 2]->[DMA addr 3]-+
+    +---------------------------------------------------------+
+
+You should both configure the buflet_size and buflet_nums to
+configure the `trace buffer` to receive the TLP headers. The
+total trace buffer size is buflet_size * buflet_nums. Note
+that the trace buffer will not be allocated immediately after you
+configure the parameters, but will be allocated right before
+the trace starts.
+
+This file configures the buflet size. Read the file will get
+available buflet size and size set currently; write the desired
+size to the file to configure. The default size is 2 MiB and any
+invalid size written will return a failure.
+::
+    $ cat buflet_size
+    [2 MiB]     4 MiB
+    $ echo 4 > buflet_size
+    $ cat buflet_size
+    2 MiB     [4 MiB]
+
+5. buflet_nums
+--------------
+
+You can write the desired buflet count to the file to configure,
+and read the file to get current buflet count. The default
+value is 64. Any positive value is valid. Note that big value
+may lead to DMA memory allocation failure, and you will not be
+able to start tracing. If it happens, you should consider adjusting
+buflet_nums or buflet_size.
+::
+    $ cat buflet_nums
+    64
+    $ echo 128 > buflet_nums
+    $ cat buflet_nums
+    128
+
+6. data
+-------
+
+The file to access the traced data. You can read the file to get the
+binary blob of traced TLP headers. The format of the headers is
+4 Dword length and is just as defined by the PCIe Spec r4.0,
+Sec 2.2.4.1, or 8 Dword length with additional 4 Dword extra
+information.
+
+echo "" > data will free all the trace buffers allocated as well as
+the traced datas.
+
+7. trace_on
+-----------
+
+Start or end the trace by writing to the file, and monitor the trace
+status by reading the file.
+::
+    $ echo 1 > trace_on     # start trace
+    $ cat trace_on          # get the trace status
+    1
+    $ echo 0 > trace_on     # manually end trace
+
+The read value of the trace_on will be auto cleared if the buffer
+allocated is full. 1 indicates the trace is running and 0 for
+stopped. Writing any non-zero value to the file starts tracing.
+
+8. free_buffer
+--------------
+
+File to indicate the trace buffer status and to manually free the
+trace buffer. The read value of 1 indicates the trace buffer has
+been allocated and exists in the memory, while 0 indicates there
+is no buffer allocated. Write 1 to the file to free the trace
+buffer as well as the traced data.
+::
+    $ cat free_buffer
+    1                       # indicate the buffer exists
+    $ echo 1 > free_buffer  # free the trace buffer
+    $ cat free_buffer
+    0
+
+9. data_format
+--------------
+
+File to indicate the format of the traced TLP headers. User can
+specify the desired format of traced TLP headers. Available formats
+are 4DW, 8DW which indicates the length of each TLP headers traced.
+::
+    $ cat data_format
+    [4DW]    8DW
+    $ echo 8 > data_format
+    $ cat data_format
+    4DW     [8DW]
+
+The traced TLP header format is different from the PCIe standard.
+
+When using the 8DW data format, the entire TLP header is logged
+(Header DW0-3 shown below). For example, the TLP header for Memory
+Reads with 64-bit addresses is shown in PCIe r5.0, Figure 2-17;
+the header for Configuration Requests is shown in Figure 2.20, etc.
+
+In addition, 8DW trace buffer entries contain a timestamp and
+possibly a prefix for a PASID TLP prefix (see Figure 6-20).
+Otherwise this field will be all 0.
+
+The bit[31:11] of DW0 is always 0x1fffff, which can be
+used to distinguish the data format. 8DW format is like
+::
+    bits [                 31:11                 ][       10:0       ]
+         |---------------------------------------|-------------------|
+     DW0 [                0x1fffff               ][ Reserved (0x7ff) ]
+     DW1 [                       Prefix                              ]
+     DW2 [                     Header DW0                            ]
+     DW3 [                     Header DW1                            ]
+     DW4 [                     Header DW2                            ]
+     DW5 [                     Header DW3                            ]
+     DW6 [                   Reserved (0x0)                          ]
+     DW7 [                        Time                               ]
+
+When using the 4DW data format, DW0 of the trace buffer entry
+contains selected fields of DW0 of the TLP, together with a
+timestamp.  DW1-DW3 of the trace buffer entry contain DW1-DW3
+directly from the TLP header.
+
+4DW format is like
+::
+    bits [31:30] [ 29:25 ][24][23][22][21][    20:11   ][    10:0    ]
+         |-----|---------|---|---|---|---|-------------|-------------|
+     DW0 [ Fmt ][  Type  ][T9][T8][TH][SO][   Length   ][    Time    ]
+     DW1 [                     Header DW1                            ]
+     DW2 [                     Header DW2                            ]
+     DW3 [                     Header DW3                            ]
-- 
2.8.1



From yangyicong at hisilicon.com  Sat Apr 17 11:17:11 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Sat, 17 Apr 2021 18:17:11 +0800
Subject: [PATCH RESEND 4/4] MAINTAINERS: Add maintainer for HiSilicon PTT
 driver
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <1618654631-42454-5-git-send-email-yangyicong@hisilicon.com>

Add maintainer for driver and documentation of HiSilicon PTT device.

Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7fdc513..647f0bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8084,6 +8084,13 @@ W:	http://www.hisilicon.com
 F:	Documentation/admin-guide/perf/hisi-pmu.rst
 F:	drivers/perf/hisilicon
 
+HISILICON PTT DRIVER
+M:	Yicong Yang <yangyicong at hisilicon.com>
+L:	linux-kernel at vger.kernel.org
+S:	Maintained
+F:	Documentation/trace/hisi-ptt.rst
+F:	drivers/hwtracing/hisilicon/
+
 HISILICON QM AND ZIP Controller DRIVER
 M:	Zhou Wang <wangzhou1 at hisilicon.com>
 L:	linux-crypto at vger.kernel.org
-- 
2.8.1



From yangyicong at hisilicon.com  Sat Apr 17 11:17:09 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Sat, 17 Apr 2021 18:17:09 +0800
Subject: [PATCH RESEND 2/4] hwtracing: Add tune function support for HiSilicon
 PCIe Tune and Trace device
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <1618654631-42454-3-git-send-email-yangyicong@hisilicon.com>

Add tune function for the HiSilicon Tune and Trace device. The interface
of tune is also exposed through debugfs.

Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
---
 drivers/hwtracing/hisilicon/hisi_ptt.c | 187 +++++++++++++++++++++++++++++++++
 1 file changed, 187 insertions(+)

diff --git a/drivers/hwtracing/hisilicon/hisi_ptt.c b/drivers/hwtracing/hisilicon/hisi_ptt.c
index a1feece..2e3631b 100644
--- a/drivers/hwtracing/hisilicon/hisi_ptt.c
+++ b/drivers/hwtracing/hisilicon/hisi_ptt.c
@@ -72,6 +72,7 @@ struct hisi_ptt_debugfs_file_desc {
 	struct hisi_ptt *hisi_ptt;
 	const char *name;
 	const struct file_operations *fops;
+	struct hisi_ptt_tune_event_desc *private;
 };
 
 #define PTT_FILE_INIT(__name, __fops)	\
@@ -85,6 +86,15 @@ struct hisi_ptt_trace_event_desc {
 #define PTT_TRACE_EVENT_INIT(__name, __event_code) \
 	{ .name = __name, .event_code = __event_code }
 
+struct hisi_ptt_tune_event_desc {
+	const char *name;
+	u32 event_code;
+	int (*set)(struct hisi_ptt *hisi_ptt, void *data);
+	int (*get)(struct hisi_ptt *hisi_ptt, void *data);
+};
+#define PTT_TUNE_EVENT_INIT(__name, __event_code, __set, __get)	\
+	{ .name = __name, .event_code = __event_code, .set = __set, .get = __get }
+
 enum hisi_ptt_trace_rxtx {
 	HISI_PTT_TRACE_RX = 0,
 	HISI_PTT_TRACE_TX,
@@ -217,6 +227,8 @@ struct hisi_ptt {
 		bool is_port;
 		u16 val;
 	} cur_filter;
+
+	u32 tune_event;
 };
 
 static int hisi_ptt_write_to_buffer(void *buf, size_t len, loff_t *pos,
@@ -234,6 +246,131 @@ static int hisi_ptt_write_to_buffer(void *buf, size_t len, loff_t *pos,
 	return 0;
 }
 
+static int hisi_ptt_wait_tuning_finish(struct hisi_ptt *hisi_ptt)
+{
+	u32 val;
+
+	return readl_poll_timeout(hisi_ptt->iobase + HISI_PTT_TUNING_INT_STAT,
+				  val, !(val & HISI_PTT_TUNING_INT_STAT_MASK),
+				  HISI_PTT_WAIT_POLL_INTERVAL_US,
+				  HISI_PTT_WAIT_TIMEOUT_US);
+}
+
+static int hisi_ptt_tune_data_get(struct hisi_ptt *hisi_ptt, void *data)
+{
+	u32 *val = data, reg;
+
+	reg = readl(hisi_ptt->iobase + HISI_PTT_TUNING_CTRL);
+	reg &= ~(HISI_PTT_TUNING_CTRL_CODE | HISI_PTT_TUNING_CTRL_SUB);
+	reg |= FIELD_PREP(HISI_PTT_TUNING_CTRL_CODE | HISI_PTT_TUNING_CTRL_SUB,
+			  hisi_ptt->tune_event);
+	writel(reg, hisi_ptt->iobase + HISI_PTT_TUNING_CTRL);
+	/* Write all 1 to indicates it's the read process */
+	writel(HISI_PTT_TUNING_DATA_VAL_MASK,
+	       hisi_ptt->iobase + HISI_PTT_TUNING_DATA);
+
+	if (hisi_ptt_wait_tuning_finish(hisi_ptt)) {
+		pci_err(hisi_ptt->pdev, "failed to read tune data, device timeout.\n");
+		return -ETIMEDOUT;
+	}
+
+	*val = readl(hisi_ptt->iobase + HISI_PTT_TUNING_DATA);
+	*val &= HISI_PTT_TUNING_DATA_VAL_MASK;
+
+	return 0;
+}
+
+static int hisi_ptt_tune_data_set(struct hisi_ptt *hisi_ptt, void *data)
+{
+	u32 *val = data, reg;
+
+	reg = readl(hisi_ptt->iobase + HISI_PTT_TUNING_CTRL);
+	reg &= ~(HISI_PTT_TUNING_CTRL_CODE | HISI_PTT_TUNING_CTRL_SUB);
+	reg |= FIELD_PREP(HISI_PTT_TUNING_CTRL_CODE | HISI_PTT_TUNING_CTRL_SUB,
+			  hisi_ptt->tune_event);
+	writel(reg, hisi_ptt->iobase + HISI_PTT_TUNING_CTRL);
+	*val &= HISI_PTT_TUNING_DATA_VAL_MASK;
+	writel(*val, hisi_ptt->iobase + HISI_PTT_TUNING_DATA);
+
+	if (hisi_ptt_wait_tuning_finish(hisi_ptt)) {
+		pci_err(hisi_ptt->pdev, "failed to write tune data, device timeout.\n");
+		return -ETIMEDOUT;
+	}
+
+	return 0;
+}
+
+static ssize_t hisi_ptt_tune_common_read(struct file *filp, char __user *buf,
+					 size_t count, loff_t *pos)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = filp->private_data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+	struct hisi_ptt_tune_event_desc *e_desc = desc->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	int len, ret;
+	u32 val;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	hisi_ptt->tune_event = e_desc->event_code;
+	ret = e_desc->get(hisi_ptt, &val);
+	mutex_unlock(&hisi_ptt->mutex);
+	if (ret)
+		return ret;
+
+	len = snprintf(tbuf, HISI_PTT_CTRL_STR_LEN, "%d\n", val);
+
+	return simple_read_from_buffer(buf, count, pos, tbuf, len);
+}
+
+static ssize_t hisi_ptt_tune_common_write(struct file *filp,
+					  const char __user *buf,
+					  size_t count, loff_t *pos)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = filp->private_data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+	struct hisi_ptt_tune_event_desc *e_desc = desc->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	int ret;
+	u16 val;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	if (kstrtou16(tbuf, 0, &val))
+		return -EINVAL;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	hisi_ptt->tune_event = e_desc->event_code;
+	ret = e_desc->set(hisi_ptt, &val);
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return ret ? ret : count;
+}
+
+static const struct file_operations tune_common_fops = {
+	.owner		= THIS_MODULE,
+	.open		= simple_open,
+	.read		= hisi_ptt_tune_common_read,
+	.write		= hisi_ptt_tune_common_write,
+	.llseek		= no_llseek,
+};
+
+#define PTT_SIMPLE_TUNE_EVENTS(__name, __event_code)	\
+	PTT_TUNE_EVENT_INIT(__name, __event_code, hisi_ptt_tune_data_set, hisi_ptt_tune_data_get)
+
+static struct hisi_ptt_tune_event_desc tune_events[] = {
+	PTT_SIMPLE_TUNE_EVENTS("qos_tx_cpl",			(0x4 | (3 << 16))),
+	PTT_SIMPLE_TUNE_EVENTS("qos_tx_np",			(0x4 | (4 << 16))),
+	PTT_SIMPLE_TUNE_EVENTS("qos_tx_p",			(0x4 | (5 << 16))),
+	PTT_SIMPLE_TUNE_EVENTS("tx_path_rx_req_alloc_buf_level",	(0x5 | (6 << 16))),
+	PTT_SIMPLE_TUNE_EVENTS("tx_path_tx_req_alloc_buf_level",	(0x5 | (7 << 16))),
+};
+
 static u16 hisi_ptt_get_filter_val(struct pci_dev *pdev)
 {
 	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
@@ -1241,6 +1378,49 @@ static void hisi_ptt_init_ctrls(struct hisi_ptt *hisi_ptt)
 	hisi_ptt->trace_ctrl.tr_event = HISI_PTT_TRACE_DEFAULT_EVENT.event_code;
 }
 
+static int hisi_ptt_create_tune_entries(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_debugfs_file_desc *tune_files;
+	struct dentry *dir;
+	int i, ret = 0;
+
+	dir = debugfs_create_dir("tune", hisi_ptt->debugfs_dir);
+	if (IS_ERR(dir))
+		return PTR_ERR(dir);
+
+	tune_files = devm_kcalloc(&hisi_ptt->pdev->dev, ARRAY_SIZE(tune_events),
+				  sizeof(struct hisi_ptt_debugfs_file_desc),
+				  GFP_KERNEL);
+	if (IS_ERR(tune_files)) {
+		ret = PTR_ERR(tune_files);
+		goto err;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(tune_events); ++i) {
+		struct dentry *file;
+
+		tune_files[i].hisi_ptt = hisi_ptt;
+
+		/* We use tune event string as control file name. */
+		tune_files[i].name = tune_events[i].name;
+		tune_files[i].fops = &tune_common_fops;
+		tune_files[i].private = &tune_events[i];
+		file = debugfs_create_file(tune_files[i].name, 0600,
+					   dir, &tune_files[i],
+					   &tune_common_fops);
+		if (IS_ERR(file)) {
+			ret = PTR_ERR(file);
+			goto err;
+		}
+	}
+
+	return 0;
+
+err:
+	debugfs_remove_recursive(dir);
+	return ret;
+}
+
 static int hisi_ptt_create_trace_entries(struct hisi_ptt *hisi_ptt)
 {
 	struct hisi_ptt_debugfs_file_desc *trace_files;
@@ -1294,6 +1474,13 @@ static int hisi_ptt_create_debugfs_entries(struct hisi_ptt *hisi_ptt)
 		return ret;
 	}
 
+	ret = hisi_ptt_create_tune_entries(hisi_ptt);
+	if (ret) {
+		pci_err(hisi_ptt->pdev, "failed to create tune entries.\n");
+		debugfs_remove_recursive(hisi_ptt->debugfs_dir);
+		return ret;
+	}
+
 	return 0;
 }
 
-- 
2.8.1



From yangyicong at hisilicon.com  Sat Apr 17 11:17:08 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Sat, 17 Apr 2021 18:17:08 +0800
Subject: [PATCH RESEND 1/4] hwtracing: Add trace function support for
 HiSilicon PCIe Tune and Trace device
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <1618654631-42454-2-git-send-email-yangyicong@hisilicon.com>

HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex
integrated Endpoint(RCiEP) device, providing the capability
to dynamically monitor and tune the PCIe traffic(tune),
and trace the TLP headers(trace).

Add the driver for the device to enable the trace function. The driver
will create debugfs directory for each PTT device, and users can
operate the device through the files under its directory.

Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
---
 drivers/Makefile                       |    1 +
 drivers/hwtracing/Kconfig              |    2 +
 drivers/hwtracing/hisilicon/Kconfig    |   11 +
 drivers/hwtracing/hisilicon/Makefile   |    2 +
 drivers/hwtracing/hisilicon/hisi_ptt.c | 1449 ++++++++++++++++++++++++++++++++
 5 files changed, 1465 insertions(+)
 create mode 100644 drivers/hwtracing/hisilicon/Kconfig
 create mode 100644 drivers/hwtracing/hisilicon/Makefile
 create mode 100644 drivers/hwtracing/hisilicon/hisi_ptt.c

diff --git a/drivers/Makefile b/drivers/Makefile
index 6fba7da..9a0f76d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -174,6 +174,7 @@ obj-$(CONFIG_PERF_EVENTS)	+= perf/
 obj-$(CONFIG_RAS)		+= ras/
 obj-$(CONFIG_USB4)		+= thunderbolt/
 obj-$(CONFIG_CORESIGHT)		+= hwtracing/coresight/
+obj-$(CONFIG_HISI_PTT)		+= hwtracing/hisilicon/
 obj-y				+= hwtracing/intel_th/
 obj-$(CONFIG_STM)		+= hwtracing/stm/
 obj-$(CONFIG_ANDROID)		+= android/
diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
index 1308583..e3796b1 100644
--- a/drivers/hwtracing/Kconfig
+++ b/drivers/hwtracing/Kconfig
@@ -5,4 +5,6 @@ source "drivers/hwtracing/stm/Kconfig"
 
 source "drivers/hwtracing/intel_th/Kconfig"
 
+source "drivers/hwtracing/hisilicon/Kconfig"
+
 endmenu
diff --git a/drivers/hwtracing/hisilicon/Kconfig b/drivers/hwtracing/hisilicon/Kconfig
new file mode 100644
index 0000000..e169771
--- /dev/null
+++ b/drivers/hwtracing/hisilicon/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config HISI_PTT
+	tristate "HiSilicon PCIe Tune and Trace Device"
+	depends on ARM64
+	depends on PCI && PCI_MSI
+	depends on HAS_DMA && HAS_IOMEM
+	depends on DEBUG_FS
+	help
+	  HiSilicon PCIe Tune and Trace Device exist as a PCIe iEP
+	  device, provides support for PCIe traffic tuning and
+	  tracing TLP headers to the memory.
diff --git a/drivers/hwtracing/hisilicon/Makefile b/drivers/hwtracing/hisilicon/Makefile
new file mode 100644
index 0000000..908c09a
--- /dev/null
+++ b/drivers/hwtracing/hisilicon/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_HISI_PTT) += hisi_ptt.o
diff --git a/drivers/hwtracing/hisilicon/hisi_ptt.c b/drivers/hwtracing/hisilicon/hisi_ptt.c
new file mode 100644
index 0000000..a1feece
--- /dev/null
+++ b/drivers/hwtracing/hisilicon/hisi_ptt.c
@@ -0,0 +1,1449 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for HiSilicon PCIe tune and trace device
+ *
+ * Copyright (c) 2021 HiSilicon Limited.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kfifo.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/seq_file.h>
+#include <linux/pci.h>
+#include <linux/workqueue.h>
+
+#define HISI_PTT_CTRL_STR_LEN			40
+#define HISI_PTT_DEFAULT_TRACE_BUF_CNT		64
+#define HISI_PTT_FILTER_UPDATE_FIFO_SIZE	16
+
+#define HISI_PTT_RESET_WAIT_MS		1000UL
+#define HISI_PTT_WORK_DELAY_MS		100UL
+#define HISI_PTT_WAIT_TIMEOUT_US	1000000UL
+#define HISI_PTT_WAIT_POLL_INTERVAL_US	100UL
+
+#define HISI_PTT_IRQ_NUMS	1
+#define HISI_PTT_DMA_IRQ	0
+#define HISI_PTT_DMA_NUMS	4
+
+#define HISI_PTT_TUNING_CTRL		0x0000
+#define   HISI_PTT_TUNING_CTRL_CODE	GENMASK(15, 0)
+#define   HISI_PTT_TUNING_CTRL_SUB	GENMASK(23, 16)
+#define   HISI_PTT_TUNING_CTRL_CHN	GENMASK(31, 24)
+#define HISI_PTT_TUNING_DATA		0x0004
+#define   HISI_PTT_TUNING_DATA_VAL_MASK	GENMASK(15, 0)
+#define HISI_PTT_TRACE_ADDR_SIZE	0x0800
+#define HISI_PTT_TRACE_ADDR_BASE_LO_0	0x0810
+#define HISI_PTT_TRACE_ADDR_BASE_HI_0	0x0814
+#define HISI_PTT_TRACE_ADDR_STRIDE	0x8
+#define HISI_PTT_TRACE_CTRL		0x0850
+#define   HISI_PTT_TRACE_CTRL_EN	BIT(0)
+#define   HISI_PTT_TRACE_CTRL_RST	BIT(1)
+#define   HISI_PTT_TRACE_CTRL_RXTX_SEL	GENMASK(3, 2)
+#define   HISI_PTT_TRACE_CTRL_TYPE_SEL	GENMASK(7, 4)
+#define   HISI_PTT_TRACE_CTRL_DATA_FORMAT	BIT(14)
+#define   HISI_PTT_TRACE_CTRL_FILTER_MODE	BIT(15)
+#define   HISI_PTT_TRACE_CTRL_TARGET_SEL	GENMASK(31, 16)
+#define HISI_PTT_TRACE_INT_STAT		0x0890
+#define   HISI_PTT_TRACE_INT_STAT_MASK	GENMASK(3, 0)
+#define HISI_PTT_TRACE_INT_MASK_REG	0x0894
+#define HISI_PTT_TUNING_INT_STAT	0x0898
+#define   HISI_PTT_TUNING_INT_STAT_MASK	BIT(0)
+#define HISI_PTT_TUNING_INT_MASK	0x089c
+#define HISI_PTT_TRACE_WR_STS		0x08a0
+#define   HISI_PTT_TRACE_WR_STS_WRITE	GENMASK(27, 0)
+#define   HISI_PTT_TRACE_WR_STS_BUFFER	GENMASK(29, 28)
+#define HISI_PTT_TRACE_STS		0x08b0
+#define   HISI_PTT_TRACE_IDLE		BIT(0)
+#define HISI_PTT_DEVICE_RANGE		0x0fe0
+
+#define HISI_PCIE_CORE_PORT_ID(v)	(((v) & 7) << 1)
+
+static struct dentry *hisi_ptt_debugfs_root;
+
+struct hisi_ptt_debugfs_file_desc {
+	struct hisi_ptt *hisi_ptt;
+	const char *name;
+	const struct file_operations *fops;
+};
+
+#define PTT_FILE_INIT(__name, __fops)	\
+	{ .name = __name, .fops = __fops }
+
+struct hisi_ptt_trace_event_desc {
+	const char *name;
+	u32 event_code;
+};
+
+#define PTT_TRACE_EVENT_INIT(__name, __event_code) \
+	{ .name = __name, .event_code = __event_code }
+
+enum hisi_ptt_trace_rxtx {
+	HISI_PTT_TRACE_RX = 0,
+	HISI_PTT_TRACE_TX,
+	HISI_PTT_TRACE_RXTX,
+	HISI_PTT_TRACE_RXTX_NO_DMA_P2P,
+};
+
+static const struct hisi_ptt_trace_event_desc trace_rxtx[] = {
+	PTT_TRACE_EVENT_INIT("rx",
+			      HISI_PTT_TRACE_RX),
+	PTT_TRACE_EVENT_INIT("tx",
+			      HISI_PTT_TRACE_TX),
+	PTT_TRACE_EVENT_INIT("rxtx",
+			      HISI_PTT_TRACE_RXTX),
+	PTT_TRACE_EVENT_INIT("rxtx_no_dma_p2p",
+			      HISI_PTT_TRACE_RXTX_NO_DMA_P2P),
+};
+#define HISI_PTT_TRACE_DEFAULT_RXTX	trace_rxtx[2]
+
+
+enum hisi_ptt_trace_event {
+	HISI_PTT_TRACE_POSTED_REQUEST		= 1,
+	HISI_PTT_TRACE_NON_POSTED_REQUEST	= 2,
+	HISI_PTT_TRACE_COMPLETION		= 4,
+	HISI_PTT_TRACE_ALL			= 7,
+};
+
+static const struct hisi_ptt_trace_event_desc trace_events[] = {
+	PTT_TRACE_EVENT_INIT("all",
+			      HISI_PTT_TRACE_POSTED_REQUEST),
+	PTT_TRACE_EVENT_INIT("posted_request",
+			      HISI_PTT_TRACE_NON_POSTED_REQUEST),
+	PTT_TRACE_EVENT_INIT("non-posted_request",
+			      HISI_PTT_TRACE_COMPLETION),
+	PTT_TRACE_EVENT_INIT("completion",
+			      HISI_PTT_TRACE_ALL),
+};
+#define HISI_PTT_TRACE_DEFAULT_EVENT	trace_events[0]
+
+static const unsigned int available_buflet_size[] = {
+	0x00200000,	/* 2  MiB */
+	0x00400000,	/* 4  MiB */
+};
+#define HISI_PTT_TRACE_DEFAULT_BUFLET_SIZE	available_buflet_size[0]
+
+struct hisi_ptt_dma_buflet {
+	struct list_head list;
+	unsigned int size;
+	dma_addr_t dma;
+
+	/*
+	 * The address of the buflet holding the trace data.
+	 * See Documentation/trace/hisi-ptt.rst for the details
+	 * of the data format.
+	 */
+	u32 *addr;
+	int index;
+};
+
+enum hisi_ptt_trace_data_format {
+	HISI_PTT_TRACE_DATA_4DW = 0,
+	HISI_PTT_TRACE_DATA_8DW,
+};
+
+struct hisi_ptt_trace_ctrl {
+	struct list_head trace_buf;
+	struct hisi_ptt_dma_buflet *cur;
+	u64 buflet_nums;
+	u32 buflet_size;
+	unsigned int status; /* 0:idle, 1:tracing */
+#define	HISI_PTT_TRACE_STATUS_OFF	0
+#define	HISI_PTT_TRACE_STATUS_ON	1
+
+	enum hisi_ptt_trace_data_format tr_format;
+	enum hisi_ptt_trace_event tr_event;
+	enum hisi_ptt_trace_rxtx rxtx;
+};
+
+struct hisi_ptt_filter_desc {
+	struct list_head list;
+	struct pci_dev *pdev;
+	u16 val;
+};
+
+/* Structure containing the information for filter updating */
+struct hisi_ptt_filter_update_info {
+	struct pci_dev *pdev;
+	bool is_port;
+	bool is_add;
+	u32 port_devid;
+	u16 val;
+};
+
+struct hisi_ptt {
+	struct notifier_block hisi_ptt_nb;
+	struct dentry *debugfs_dir;
+	struct pci_dev *pdev;
+	void __iomem *iobase;
+	/* protects the hisi_ptt structure */
+	struct mutex mutex;
+	const char *name;
+
+	/*
+	 * We use a delayed work here to avoid indefinitely waiting for
+	 * the hisi_ptt->mutex which protecting the filter list. The
+	 * work will be delayed only if the mutex can not be held,
+	 * otherwise no delay will be applied.
+	 */
+	struct delayed_work work;
+	spinlock_t filter_update_lock;
+	DECLARE_KFIFO(filter_update_kfifo, struct hisi_ptt_filter_update_info,
+		      HISI_PTT_FILTER_UPDATE_FIFO_SIZE);
+
+	/*
+	 * The upper and lower BDF numbers of the root port,
+	 * which PTT device can control and trace.
+	 */
+	u16 upper;
+	u16 lower;
+
+	/*
+	 * The trace TLP headers can either be filtered by certain
+	 * root port, or by the requester ID. Organize the filters
+	 * by @port_filters and @req_filters here.
+	 */
+	struct list_head port_filters;
+	struct list_head req_filters;
+	struct hisi_ptt_trace_ctrl trace_ctrl;
+	struct {
+		bool is_port;
+		u16 val;
+	} cur_filter;
+};
+
+static int hisi_ptt_write_to_buffer(void *buf, size_t len, loff_t *pos,
+				    const void __user *ubuf, size_t count)
+{
+	char *cp;
+
+	if (simple_write_to_buffer(buf, len, pos, ubuf, count) < 0)
+		return -EINVAL;
+
+	cp = strchr(buf, '\n');
+	if (cp)
+		*cp = '\0';
+
+	return 0;
+}
+
+static u16 hisi_ptt_get_filter_val(struct pci_dev *pdev)
+{
+	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+		return BIT(HISI_PCIE_CORE_PORT_ID(PCI_SLOT(pdev->devfn)));
+	else
+		return PCI_DEVID(pdev->bus->number, pdev->devfn);
+}
+
+static int hisi_ptt_wait_trace_hw_idle(struct hisi_ptt *hisi_ptt)
+{
+	u32 val;
+
+	return readl_poll_timeout(hisi_ptt->iobase + HISI_PTT_TRACE_STS, val,
+				  val & HISI_PTT_TRACE_IDLE,
+				  HISI_PTT_WAIT_POLL_INTERVAL_US,
+				  HISI_PTT_WAIT_TIMEOUT_US);
+}
+
+static void hisi_ptt_free_trace_buf(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	struct device *dev = &hisi_ptt->pdev->dev;
+	struct hisi_ptt_dma_buflet *buflet, *tbuflet;
+
+	if (list_empty(&ctrl->trace_buf))
+		return;
+
+	list_for_each_entry_safe(buflet, tbuflet, &ctrl->trace_buf, list) {
+		dma_free_coherent(dev, buflet->size, buflet->addr, buflet->dma);
+		list_del(&buflet->list);
+		kfree(buflet);
+	}
+}
+
+static int hisi_ptt_alloc_trace_buf(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	struct device *dev = &hisi_ptt->pdev->dev;
+	struct hisi_ptt_dma_buflet *buflet;
+	int i, ret;
+
+	/* Make sure the trace buffer is empty before allocating */
+	if (!list_empty(&ctrl->trace_buf))
+		hisi_ptt_free_trace_buf(hisi_ptt);
+
+	for (i = 0; i < ctrl->buflet_nums; ++i) {
+		buflet = kzalloc(sizeof(*buflet), GFP_KERNEL);
+		if (!buflet) {
+			ret = -ENOMEM;
+			goto err;
+		}
+		buflet->addr = dma_alloc_coherent(dev, ctrl->buflet_size,
+						  &buflet->dma, GFP_KERNEL);
+		if (!buflet->addr) {
+			kfree(buflet);
+			ret = -ENOMEM;
+			goto err;
+		}
+
+		buflet->index = i;
+		buflet->size = ctrl->buflet_size;
+		list_add_tail(&buflet->list, &ctrl->trace_buf);
+	}
+
+	return 0;
+
+err:
+	hisi_ptt_free_trace_buf(hisi_ptt);
+	return ret;
+}
+
+static void hisi_ptt_trace_end(struct hisi_ptt *hisi_ptt)
+{
+	writel(0, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+	hisi_ptt->trace_ctrl.status = HISI_PTT_TRACE_STATUS_OFF;
+	hisi_ptt->trace_ctrl.cur = NULL;
+}
+
+static int hisi_ptt_trace_start(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	u32 val;
+	int i;
+
+	if (!hisi_ptt->cur_filter.val) {
+		pci_err(hisi_ptt->pdev, "no filter specified\n");
+		return -ENODEV;
+	}
+
+	if (!ctrl->tr_event) {
+		pci_err(hisi_ptt->pdev, "no trace type specified\n");
+		return -EINVAL;
+	}
+
+	/* Check device idle before start trace */
+	if (hisi_ptt_wait_trace_hw_idle(hisi_ptt)) {
+		pci_err(hisi_ptt->pdev, "the device is still busy\n");
+		return -EBUSY;
+	}
+
+	/* Reset the DMA before start tracing */
+	val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+	val |= HISI_PTT_TRACE_CTRL_RST;
+	writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+
+	/* Wait for the reset finished */
+	msleep(HISI_PTT_RESET_WAIT_MS);
+
+	val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+	val &= ~HISI_PTT_TRACE_CTRL_RST;
+	writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+
+	/* clear the interrupt status */
+	writel(HISI_PTT_TRACE_INT_STAT_MASK,
+	       hisi_ptt->iobase + HISI_PTT_TRACE_INT_STAT);
+	writel(0, hisi_ptt->iobase + HISI_PTT_TRACE_INT_MASK_REG);
+
+	for (i = 0; i < HISI_PTT_DMA_NUMS; ++i) {
+		if (!ctrl->cur)
+			ctrl->cur = list_first_entry(&ctrl->trace_buf,
+						     struct hisi_ptt_dma_buflet,
+						     list);
+		else
+			ctrl->cur = list_next_entry(ctrl->cur, list);
+
+		writel(lower_32_bits(ctrl->cur->dma),
+		       hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_BASE_LO_0 +
+		       i * HISI_PTT_TRACE_ADDR_STRIDE);
+		writel(upper_32_bits(ctrl->cur->dma),
+		       hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_BASE_HI_0 +
+		       i * HISI_PTT_TRACE_ADDR_STRIDE);
+	}
+	writel(ctrl->buflet_size, hisi_ptt->iobase + HISI_PTT_TRACE_ADDR_SIZE);
+
+	/* set the trace control register */
+	val = 0;
+	val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_TYPE_SEL, ctrl->tr_event);
+	val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_RXTX_SEL, ctrl->rxtx);
+	val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_DATA_FORMAT, ctrl->tr_format);
+	val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_FILTER_MODE,
+			  hisi_ptt->cur_filter.is_port ? 0 : 1);
+	val |= FIELD_PREP(HISI_PTT_TRACE_CTRL_TARGET_SEL,
+			  hisi_ptt->cur_filter.val);
+
+	val |= HISI_PTT_TRACE_CTRL_EN;
+	writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
+
+	ctrl->status = HISI_PTT_TRACE_STATUS_ON;
+
+	return 0;
+}
+
+#define HISI_PTT_TRACE_ATTR(__name)					\
+static int __name ## _open(struct inode *inode, struct file *filp)	\
+{									\
+	struct hisi_ptt_debugfs_file_desc *desc = inode->i_private;	\
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;			\
+	if (!mutex_trylock(&hisi_ptt->mutex))				\
+		return -EBUSY;						\
+	return single_open(filp, __name ## _show, hisi_ptt);		\
+}									\
+static int __name ## _release(struct inode *inode, struct file *filp)	\
+{									\
+	struct hisi_ptt_debugfs_file_desc *desc = inode->i_private;	\
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;			\
+	mutex_unlock(&hisi_ptt->mutex);					\
+	return seq_release(inode, filp);				\
+}									\
+static const struct file_operations __name ## _fops = {			\
+	.owner		= THIS_MODULE,					\
+	.open		= __name ## _open,				\
+	.read		= seq_read,					\
+	.write		= __name ## _write,				\
+	.llseek		= seq_lseek,					\
+	.release	= __name ## _release,				\
+}
+
+static void hisi_ptt_print_filter_list(struct seq_file *m,
+				       struct hisi_ptt *hisi_ptt,
+				       struct list_head *filter_list,
+				       bool port_filter)
+{
+	struct hisi_ptt_filter_desc *filter;
+
+	list_for_each_entry(filter, filter_list, list) {
+		struct pci_dev *pdev = filter->pdev;
+		bool selected = false;
+
+		if (port_filter && hisi_ptt->cur_filter.is_port)
+			selected = filter->val & hisi_ptt->cur_filter.val;
+		else
+			selected = filter->val == hisi_ptt->cur_filter.val;
+
+		seq_printf(m, "%s%04x:%02x:%02x.%u%s\n",
+			   selected ? "[" : "",
+			   pci_domain_nr(pdev->bus),
+			   pdev->bus->number, PCI_SLOT(pdev->devfn),
+			   PCI_FUNC(pdev->devfn),
+			   selected ? "]" : "");
+	}
+}
+
+static int hisi_ptt_set_filter_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+
+	if (list_empty(&hisi_ptt->port_filters)) {
+		seq_puts(m, "#### No available filter ####\n");
+		return 0;
+	}
+
+	seq_puts(m, "#### Root Ports ####\n");
+	hisi_ptt_print_filter_list(m, hisi_ptt, &hisi_ptt->port_filters, true);
+
+	if (list_empty(&hisi_ptt->req_filters))
+		return 0;
+
+	seq_puts(m, "#### Functions ####\n");
+	hisi_ptt_print_filter_list(m, hisi_ptt, &hisi_ptt->req_filters, false);
+
+	return 0;
+}
+
+static int hisi_ptt_parse_set_filter(struct hisi_ptt *hisi_ptt, const char *buf)
+{
+	struct hisi_ptt_filter_desc *filter;
+	u32 domain, bus, dev, fn, devfn;
+	struct list_head *filter_list;
+	struct pci_dev *pdev;
+	u16 filter_val;
+	int num;
+
+	/*
+	 * the input should be like 0000:80:01.1, etc. Parse it
+	 * and check whether it's in the available func list.
+	 */
+	num = sscanf(buf, "%04x:%02x:%02x.%u", &domain, &bus, &dev, &fn);
+	if (num != 4)
+		return -EINVAL;
+
+	devfn = PCI_DEVFN(dev, fn);
+	pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
+	if (!pdev)
+		return -EINVAL;
+
+	filter_val = hisi_ptt_get_filter_val(pdev);
+	if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+		filter_list = &hisi_ptt->port_filters;
+	else
+		filter_list = &hisi_ptt->req_filters;
+
+	list_for_each_entry(filter, filter_list, list) {
+		if (filter_val != filter->val)
+			continue;
+
+		if (hisi_ptt->cur_filter.is_port &&
+		    pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+			hisi_ptt->cur_filter.val |= filter_val;
+		else
+			hisi_ptt->cur_filter.val = filter_val;
+
+		hisi_ptt->cur_filter.is_port = pci_pcie_type(pdev) ==
+					       PCI_EXP_TYPE_ROOT_PORT;
+
+		pci_dev_put(pdev);
+		return 0;
+	}
+
+	pci_dev_put(pdev);
+	return -EINVAL;
+}
+
+static ssize_t hisi_ptt_set_filter_write(struct file *filp,
+					 const char __user *buf,
+					 size_t count, loff_t *pos)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+
+	if (list_empty(&hisi_ptt->port_filters))
+		return -EINVAL;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	if (!strlen(tbuf)) {
+		hisi_ptt->cur_filter.val = 0;
+		hisi_ptt->cur_filter.is_port = false;
+		return count;
+	}
+
+	if (hisi_ptt_parse_set_filter(hisi_ptt, tbuf) < 0)
+		return -EINVAL;
+
+	return count;
+}
+HISI_PTT_TRACE_ATTR(hisi_ptt_set_filter);
+
+static int hisi_ptt_set_direction_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(trace_rxtx); ++i) {
+		bool selected = false;
+
+		if (hisi_ptt->trace_ctrl.rxtx == trace_rxtx[i].event_code)
+			selected = true;
+
+		seq_printf(m, "%s%s%s  ",
+			   selected ? "[" : "", trace_rxtx[i].name,
+			   selected ? "]" : "");
+	}
+	seq_putc(m, '\n');
+
+	return 0;
+}
+
+static ssize_t hisi_ptt_set_direction_write(struct file *filp,
+					    const char __user *buf,
+					    size_t count, loff_t *pos)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	int i;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	for (i = 0; i < ARRAY_SIZE(trace_rxtx); ++i) {
+		if (!strcmp(tbuf, trace_rxtx[i].name)) {
+			hisi_ptt->trace_ctrl.rxtx = trace_rxtx[i].event_code;
+			return count;
+		}
+	}
+
+	return -EINVAL;
+}
+HISI_PTT_TRACE_ATTR(hisi_ptt_set_direction);
+
+static int hisi_ptt_set_trace_type_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	bool select_all = false;
+	int i;
+
+	if (hisi_ptt->trace_ctrl.tr_event == trace_events[0].event_code)
+		select_all = true;
+
+	for (i = 0; i < ARRAY_SIZE(trace_events); ++i) {
+		bool selected = false;
+
+		if (((hisi_ptt->trace_ctrl.tr_event &
+		      trace_events[i].event_code) &&
+		     !select_all && i) || (i == 0 && select_all))
+			selected = true;
+
+		seq_printf(m, "%s%s%s  ",
+			   selected ? "[" : "", trace_events[i].name,
+			   selected ? "]" : "");
+	}
+	seq_putc(m, '\n');
+
+	return 0;
+}
+
+static ssize_t hisi_ptt_set_trace_type_write(struct file *filp,
+					     const char __user *buf,
+					     size_t count, loff_t *pos)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	int i;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	if (!strlen(tbuf)) {
+		hisi_ptt->trace_ctrl.tr_event = 0;
+		return count;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(trace_events); ++i) {
+		if (!strcmp(tbuf, trace_events[i].name)) {
+			hisi_ptt->trace_ctrl.tr_event |= trace_events[i].event_code;
+			return count;
+		}
+	}
+
+	return -EINVAL;
+}
+HISI_PTT_TRACE_ATTR(hisi_ptt_set_trace_type);
+
+static int hisi_ptt_trace_on_get(void *data, u64 *val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	*val = hisi_ptt->trace_ctrl.status;
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return 0;
+}
+
+static int hisi_ptt_trace_on_set(void *data, u64 val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+	int ret = 0;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	if (val) {
+		if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_ON)
+			goto out;
+
+		ret = hisi_ptt_alloc_trace_buf(hisi_ptt);
+		if (ret)
+			goto out;
+
+		ret = hisi_ptt_trace_start(hisi_ptt);
+		if (ret) {
+			hisi_ptt_free_trace_buf(hisi_ptt);
+			goto out;
+		}
+	} else {
+		if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_OFF)
+			goto out;
+
+		hisi_ptt_trace_end(hisi_ptt);
+	}
+
+out:
+	mutex_unlock(&hisi_ptt->mutex);
+	return ret;
+}
+DEFINE_DEBUGFS_ATTRIBUTE(hisi_ptt_trace_on_fops, hisi_ptt_trace_on_get,
+			 hisi_ptt_trace_on_set, "%llu\n");
+
+static int hisi_ptt_set_trace_buf_nums_get(void *data, u64 *val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	*val = hisi_ptt->trace_ctrl.buflet_nums;
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return 0;
+}
+
+static int hisi_ptt_set_trace_buf_nums_set(void *data, u64 val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+
+	if (val < HISI_PTT_DMA_NUMS) {
+		pci_warn(hisi_ptt->pdev, "buflet numbers should be more than %d\n",
+			 HISI_PTT_DMA_NUMS - 1);
+		return -EINVAL;
+	}
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	hisi_ptt->trace_ctrl.buflet_nums = val;
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return 0;
+}
+DEFINE_DEBUGFS_ATTRIBUTE(hisi_ptt_set_trace_buf_nums_fops,
+			 hisi_ptt_set_trace_buf_nums_get,
+			 hisi_ptt_set_trace_buf_nums_set, "%llu\n");
+
+static int hisi_ptt_set_trace_buflet_size_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(available_buflet_size); ++i) {
+		bool selected = false;
+
+		if (ctrl->buflet_size == available_buflet_size[i])
+			selected = true;
+
+		seq_printf(m, "%s%uMiB%s  ",
+			   selected ? "[" : "", available_buflet_size[i] >> 20,
+			   selected ? "]" : "");
+	}
+	seq_putc(m, '\n');
+
+	return 0;
+}
+
+static ssize_t hisi_ptt_set_trace_buflet_size_write(struct file *filp,
+						    const char __user *buf,
+						    size_t count, loff_t *pos)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	unsigned int size;
+	int i;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	if (kstrtouint(tbuf, 0, &size))
+		return -EINVAL;
+
+	size <<= 20;
+	for (i = 0; i < ARRAY_SIZE(available_buflet_size); ++i) {
+		if (available_buflet_size[i] == size) {
+			ctrl->buflet_size = size;
+			return count;
+		}
+	}
+
+	return -EINVAL;
+}
+HISI_PTT_TRACE_ATTR(hisi_ptt_set_trace_buflet_size);
+
+static int hisi_ptt_free_trace_buf_get(void *data, u64 *val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	*val = list_empty(&hisi_ptt->trace_ctrl.trace_buf);
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return 0;
+}
+
+static int hisi_ptt_free_trace_buf_set(void *data, u64 val)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = data;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+	int ret = 0;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	if (!list_empty(&hisi_ptt->trace_ctrl.trace_buf)) {
+		if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_ON)
+			ret = -EBUSY;
+		else
+			hisi_ptt_free_trace_buf(hisi_ptt);
+	}
+
+	mutex_unlock(&hisi_ptt->mutex);
+	return ret;
+}
+DEFINE_DEBUGFS_ATTRIBUTE(hisi_ptt_free_trace_buf_fops,
+			 hisi_ptt_free_trace_buf_get,
+			 hisi_ptt_free_trace_buf_set, "%llu\n");
+
+static int hisi_ptt_trace_data_format_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+
+	seq_printf(m, "%s\n", ctrl->tr_format ? "4DW [8DW]" : "[4DW] 8DW");
+
+	return 0;
+}
+
+static ssize_t hisi_ptt_trace_data_format_write(struct file *filp,
+						const char __user *buf,
+						size_t count, loff_t *pos)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+	u32 format;
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     pos, buf, count))
+		return -EINVAL;
+
+	if (kstrtouint(tbuf, 0, &format))
+		return -EINVAL;
+
+	/* The data format can only be 4DW or 8DW */
+	if (format == 4)
+		ctrl->tr_format = HISI_PTT_TRACE_DATA_4DW;
+	else if (format == 8)
+		ctrl->tr_format = HISI_PTT_TRACE_DATA_8DW;
+	else
+		return -EINVAL;
+
+	return count;
+}
+HISI_PTT_TRACE_ATTR(hisi_ptt_trace_data_format);
+
+static void *hisi_ptt_trace_data_next(struct seq_file *m, void *v, loff_t *pos)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_dma_buflet *buflet = v;
+
+	(*pos)++;
+
+	if (!list_is_last(&buflet->list, &hisi_ptt->trace_ctrl.trace_buf))
+		return list_next_entry(buflet, list);
+
+	return NULL;
+}
+
+static void *hisi_ptt_trace_data_start(struct seq_file *m, loff_t *pos)
+{
+	struct hisi_ptt *hisi_ptt = m->private;
+	struct hisi_ptt_dma_buflet *buflet;
+	loff_t off = 0;
+
+	buflet = list_first_entry(&hisi_ptt->trace_ctrl.trace_buf,
+				  struct hisi_ptt_dma_buflet, list);
+	while (off < *pos)
+		buflet = hisi_ptt_trace_data_next(m, buflet, &off);
+
+	return buflet;
+}
+
+static void hisi_ptt_trace_data_stop(struct seq_file *m, void *p)
+{
+	/* Nothing to do, only a stub */
+}
+
+static int hisi_ptt_trace_data_show(struct seq_file *m, void *v)
+{
+	struct hisi_ptt_dma_buflet *buflet = v;
+
+	if (buflet)
+		seq_write(m, buflet->addr, buflet->size);
+
+	return 0;
+}
+
+/*
+ * The operations of the seq_file will exist when the mutex of
+ * hisi_ptt being held in the open(), and the mutex will be
+ * released in the release().
+ */
+static const struct seq_operations hisi_ptt_trace_data_seq_ops = {
+	.start	= hisi_ptt_trace_data_start,
+	.next	= hisi_ptt_trace_data_next,
+	.stop	= hisi_ptt_trace_data_stop,
+	.show	= hisi_ptt_trace_data_show,
+};
+
+static int hisi_ptt_trace_data_open(struct inode *inode, struct file *filep)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = inode->i_private;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+	struct seq_file *m;
+	int ret;
+
+	if (!mutex_trylock(&hisi_ptt->mutex))
+		return -EBUSY;
+
+	/*
+	 * Check the trace status, we cannot read the
+	 * data if the trace is still on. Then hold the
+	 * lock when reading the traced data.
+	 */
+	if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_ON ||
+	    hisi_ptt_wait_trace_hw_idle(hisi_ptt)) {
+		ret = -EBUSY;
+		goto err;
+	}
+
+	if (list_empty(&hisi_ptt->trace_ctrl.trace_buf)) {
+		pci_info(hisi_ptt->pdev, "the trace buffer is empty\n");
+		ret = -ENOTTY;
+		goto err;
+	}
+
+	ret = seq_open(filep, &hisi_ptt_trace_data_seq_ops);
+	if (ret)
+		goto err;
+
+	m = filep->private_data;
+	m->private = hisi_ptt;
+
+	return 0;
+
+err:
+	mutex_unlock(&hisi_ptt->mutex);
+	return ret;
+}
+
+static ssize_t hisi_ptt_trace_data_write(struct file *filp,
+					 const char __user *buf,
+					 size_t count, loff_t *off)
+{
+	struct seq_file *m = filp->private_data;
+	struct hisi_ptt *hisi_ptt = m->private;
+	char tbuf[HISI_PTT_CTRL_STR_LEN];
+
+	if (hisi_ptt_write_to_buffer(tbuf, HISI_PTT_CTRL_STR_LEN - 1,
+				     off, buf, count))
+		return -EINVAL;
+
+	/* Free the trace buffer when `echo "" > trace_data` */
+	if (!strlen(tbuf) && !list_empty(&hisi_ptt->trace_ctrl.trace_buf)) {
+		if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_ON)
+			return -EBUSY;
+		hisi_ptt_free_trace_buf(hisi_ptt);
+	}
+
+	return count;
+}
+
+static int hisi_ptt_trace_data_release(struct inode *inode, struct file *filp)
+{
+	struct hisi_ptt_debugfs_file_desc *desc = inode->i_private;
+	struct hisi_ptt *hisi_ptt = desc->hisi_ptt;
+
+	mutex_unlock(&hisi_ptt->mutex);
+
+	return seq_release(inode, filp);
+}
+
+static const struct file_operations hisi_ptt_trace_data_fops = {
+	.owner		= THIS_MODULE,
+	.open		= hisi_ptt_trace_data_open,
+	.read		= seq_read,
+	.write		= hisi_ptt_trace_data_write,
+	.llseek		= no_llseek,
+	.release	= hisi_ptt_trace_data_release,
+};
+
+static struct hisi_ptt_debugfs_file_desc trace_entries[] = {
+	PTT_FILE_INIT("filter",		&hisi_ptt_set_filter_fops),
+	PTT_FILE_INIT("direction",	&hisi_ptt_set_direction_fops),
+	PTT_FILE_INIT("type",		&hisi_ptt_set_trace_type_fops),
+	PTT_FILE_INIT("data_format",	&hisi_ptt_trace_data_format_fops),
+	PTT_FILE_INIT("trace_on",	&hisi_ptt_trace_on_fops),
+	PTT_FILE_INIT("buf_nums",	&hisi_ptt_set_trace_buf_nums_fops),
+	PTT_FILE_INIT("buflet_size",	&hisi_ptt_set_trace_buflet_size_fops),
+	PTT_FILE_INIT("free_buffer",	&hisi_ptt_free_trace_buf_fops),
+	PTT_FILE_INIT("data",		&hisi_ptt_trace_data_fops),
+};
+
+static irqreturn_t hisi_ptt_isr(int irq, void *context)
+{
+	struct hisi_ptt *hisi_ptt = context;
+	struct hisi_ptt_dma_buflet *next, *cur;
+	u32 status, val, buf_idx;
+
+	status = readl(hisi_ptt->iobase + HISI_PTT_TRACE_INT_STAT);
+	buf_idx = fls(status) - 1;
+
+	/*
+	 * Check whether the trace buffer is full. Stop tracing
+	 * when the last DMA buffer is finished. Otherwise, assign
+	 * the address of next buflet to the DMA register.
+	 */
+	cur = hisi_ptt->trace_ctrl.cur;
+	if (list_is_last(&cur->list, &hisi_ptt->trace_ctrl.trace_buf)) {
+		if ((status & HISI_PTT_TRACE_INT_STAT_MASK) ==
+		    HISI_PTT_TRACE_INT_STAT_MASK)
+			hisi_ptt_trace_end(hisi_ptt);
+
+		val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_INT_MASK_REG);
+		val |= BIT(buf_idx);
+		writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_INT_MASK_REG);
+	} else {
+		next = list_next_entry(cur, list);
+		writel(lower_32_bits(next->dma), hisi_ptt->iobase +
+				  HISI_PTT_TRACE_ADDR_BASE_LO_0 +
+				  buf_idx * HISI_PTT_TRACE_ADDR_STRIDE);
+		writel(upper_32_bits(next->dma), hisi_ptt->iobase +
+					HISI_PTT_TRACE_ADDR_BASE_HI_0 +
+					buf_idx * HISI_PTT_TRACE_ADDR_STRIDE);
+		hisi_ptt->trace_ctrl.cur = next;
+		val = BIT(buf_idx);
+		writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_INT_STAT);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t hisi_ptt_irq(int irq, void *context)
+{
+	struct hisi_ptt *hisi_ptt = context;
+	u32 status;
+
+	status = readl(hisi_ptt->iobase + HISI_PTT_TRACE_INT_STAT);
+	if (status & HISI_PTT_TRACE_INT_STAT_MASK)
+		return IRQ_WAKE_THREAD;
+
+	return IRQ_NONE;
+}
+
+static int hisi_ptt_irq_register(struct hisi_ptt *hisi_ptt)
+{
+	struct pci_dev *pdev = hisi_ptt->pdev;
+	int ret;
+
+	ret = pci_alloc_irq_vectors(pdev, HISI_PTT_IRQ_NUMS, HISI_PTT_IRQ_NUMS,
+				    PCI_IRQ_MSI);
+	if (ret < 0) {
+		pci_err(pdev, "failed to allocate irq vector, ret = %d\n", ret);
+		return ret;
+	}
+
+	ret = request_threaded_irq(pci_irq_vector(pdev, HISI_PTT_DMA_IRQ),
+				   hisi_ptt_irq, hisi_ptt_isr, IRQF_SHARED,
+				   "hisi-ptt", hisi_ptt);
+	if (ret) {
+		pci_err(pdev, "failed to request irq %d, ret = %d\n",
+			pci_irq_vector(pdev, HISI_PTT_DMA_IRQ), ret);
+		pci_free_irq_vectors(pdev);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void hisi_ptt_irq_unregister(struct hisi_ptt *hisi_ptt)
+{
+	struct pci_dev *pdev = hisi_ptt->pdev;
+
+	free_irq(pci_irq_vector(pdev, HISI_PTT_DMA_IRQ), hisi_ptt);
+	pci_free_irq_vectors(pdev);
+}
+
+static void hisi_ptt_update_filters(struct work_struct *work)
+{
+	struct delayed_work *delayed_work = to_delayed_work(work);
+	struct hisi_ptt_filter_update_info info;
+	struct hisi_ptt_filter_desc *filter;
+	struct list_head *target_list;
+	struct hisi_ptt *hisi_ptt;
+
+	hisi_ptt = container_of(delayed_work, struct hisi_ptt, work);
+
+	if (!mutex_trylock(&hisi_ptt->mutex)) {
+		schedule_delayed_work(&hisi_ptt->work, HISI_PTT_WORK_DELAY_MS);
+		return;
+	}
+
+	while (kfifo_get(&hisi_ptt->filter_update_kfifo, &info)) {
+		target_list = info.is_port ? &hisi_ptt->port_filters :
+			      &hisi_ptt->req_filters;
+
+		if (info.is_add) {
+			filter = kzalloc(sizeof(*filter), GFP_KERNEL);
+			if (!filter) {
+				pci_err(hisi_ptt->pdev,
+					"failed to update the filters\n");
+				continue;
+			}
+
+			filter->pdev = info.pdev;
+			filter->val = info.val;
+
+			list_add_tail(&filter->list, target_list);
+		} else {
+			list_for_each_entry(filter, target_list, list)
+				if (filter->val == info.val) {
+					list_del(&filter->list);
+					kfree(filter);
+					break;
+				}
+		}
+	}
+
+	mutex_unlock(&hisi_ptt->mutex);
+}
+
+static void hisi_ptt_update_fifo_in(struct hisi_ptt *hisi_ptt,
+				    struct hisi_ptt_filter_update_info *info)
+{
+	struct pci_dev *root_port = pcie_find_root_port(info->pdev);
+
+	if (!root_port)
+		return;
+
+	info->port_devid = PCI_DEVID(root_port->bus->number, root_port->devfn);
+	if (info->port_devid < hisi_ptt->lower ||
+	    info->port_devid > hisi_ptt->upper)
+			return;
+
+	info->is_port = pci_pcie_type(info->pdev) == PCI_EXP_TYPE_ROOT_PORT;
+	info->val = hisi_ptt_get_filter_val(info->pdev);
+
+	if (kfifo_in_spinlocked(&hisi_ptt->filter_update_kfifo, info, 1,
+				&hisi_ptt->filter_update_lock))
+		schedule_delayed_work(&hisi_ptt->work, 0);
+	else
+		pci_warn(hisi_ptt->pdev,
+			 "filter update fifo overflow for target %s\n",
+			 pci_name(info->pdev));
+}
+
+/*
+ * A PCI bus notifier is used here for dynamically updating the filter
+ * list.
+ */
+static int hisi_ptt_notifier_call(struct notifier_block *nb,
+				  unsigned long action,
+				  void *data)
+{
+	struct hisi_ptt *hisi_ptt = container_of(nb, struct hisi_ptt, hisi_ptt_nb);
+	struct hisi_ptt_filter_update_info info;
+	struct device *dev = data;
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	info.pdev = pdev;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		info.is_add = true;
+		break;
+	case BUS_NOTIFY_DEL_DEVICE:
+		info.is_add = false;
+		break;
+	default:
+		return 0;
+	}
+
+	hisi_ptt_update_fifo_in(hisi_ptt, &info);
+
+	return 0;
+}
+
+static int hisi_ptt_init_filters(struct pci_dev *pdev, void *data)
+{
+	struct hisi_ptt_filter_update_info info = {
+		.pdev = pdev,
+		.is_add = true,
+	};
+	struct hisi_ptt *hisi_ptt = data;
+
+	hisi_ptt_update_fifo_in(hisi_ptt, &info);
+
+	return 0;
+}
+
+static void hisi_ptt_release_filters(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_filter_desc *filter, *tfilter;
+
+	list_for_each_entry_safe(filter, tfilter, &hisi_ptt->req_filters, list) {
+		list_del(&filter->list);
+		kfree(filter);
+	}
+
+	list_for_each_entry_safe(filter, tfilter, &hisi_ptt->port_filters, list) {
+		list_del(&filter->list);
+		kfree(filter);
+	}
+}
+
+static void hisi_ptt_init_ctrls(struct hisi_ptt *hisi_ptt)
+{
+	struct pci_bus *bus;
+	u32 reg;
+
+	INIT_LIST_HEAD(&hisi_ptt->port_filters);
+	INIT_LIST_HEAD(&hisi_ptt->req_filters);
+
+	/*
+	 * The device range register provides the information about the
+	 * root ports which the RCiEP can control and trace. The RCiEP
+	 * and the root ports it support are on the same PCIe core, with
+	 * same domain number but maybe different bus number. The device
+	 * range register will tell us which root ports we can support,
+	 * Bit[31:16] indicates the upper BDF numbers of the root port,
+	 * while Bit[15:0] indicates the lower.
+	 */
+	reg = readl(hisi_ptt->iobase + HISI_PTT_DEVICE_RANGE);
+	hisi_ptt->upper = reg >> 16;
+	hisi_ptt->lower = reg & 0xffff;
+
+	bus = pci_find_bus(pci_domain_nr(hisi_ptt->pdev->bus),
+			   PCI_BUS_NUM(hisi_ptt->upper));
+	if (bus)
+		pci_walk_bus(bus, hisi_ptt_init_filters, hisi_ptt);
+
+	/* Initialize trace controls */
+	INIT_LIST_HEAD(&hisi_ptt->trace_ctrl.trace_buf);
+	hisi_ptt->trace_ctrl.buflet_nums = HISI_PTT_DEFAULT_TRACE_BUF_CNT;
+	hisi_ptt->trace_ctrl.buflet_size = HISI_PTT_TRACE_DEFAULT_BUFLET_SIZE;
+	hisi_ptt->trace_ctrl.rxtx = HISI_PTT_TRACE_DEFAULT_RXTX.event_code;
+	hisi_ptt->trace_ctrl.tr_event = HISI_PTT_TRACE_DEFAULT_EVENT.event_code;
+}
+
+static int hisi_ptt_create_trace_entries(struct hisi_ptt *hisi_ptt)
+{
+	struct hisi_ptt_debugfs_file_desc *trace_files;
+	struct dentry *dir;
+	int i, ret = 0;
+
+	dir = debugfs_create_dir("trace", hisi_ptt->debugfs_dir);
+	if (IS_ERR(dir))
+		return PTR_ERR(dir);
+
+	trace_files = devm_kmemdup(&hisi_ptt->pdev->dev, trace_entries,
+				   sizeof(trace_entries), GFP_KERNEL);
+	if (IS_ERR(trace_files)) {
+		ret = PTR_ERR(trace_files);
+		goto err;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(trace_entries); ++i) {
+		struct dentry *file;
+
+		trace_files[i].hisi_ptt = hisi_ptt;
+		file = debugfs_create_file(trace_files[i].name, 0600,
+					   dir, &trace_files[i],
+					   trace_files[i].fops);
+		if (IS_ERR(file)) {
+			ret = PTR_ERR(file);
+			goto err;
+		}
+	}
+
+	return 0;
+
+err:
+	debugfs_remove_recursive(dir);
+	return ret;
+}
+
+static int hisi_ptt_create_debugfs_entries(struct hisi_ptt *hisi_ptt)
+{
+	int ret;
+
+	hisi_ptt->debugfs_dir = debugfs_create_dir(hisi_ptt->name,
+						   hisi_ptt_debugfs_root);
+	if (IS_ERR(hisi_ptt->debugfs_dir))
+		return PTR_ERR(hisi_ptt->debugfs_dir);
+
+	ret = hisi_ptt_create_trace_entries(hisi_ptt);
+	if (ret) {
+		pci_err(hisi_ptt->pdev, "failed to create debugfs entries\n");
+		debugfs_remove_recursive(hisi_ptt->debugfs_dir);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int hisi_ptt_probe(struct pci_dev *pdev,
+			  const struct pci_device_id *id)
+{
+	struct hisi_ptt *hisi_ptt;
+	int ret;
+
+	hisi_ptt = devm_kzalloc(&pdev->dev, sizeof(*hisi_ptt), GFP_KERNEL);
+	if (!hisi_ptt)
+		return -ENOMEM;
+
+	mutex_init(&hisi_ptt->mutex);
+	hisi_ptt->pdev = pdev;
+
+	/*
+	 * Lifetime of pci_dev is longer than hisi_ptt,
+	 * so directly reference to the pci name string.
+	 */
+	hisi_ptt->name = pci_name(pdev);
+	pci_set_drvdata(pdev, hisi_ptt);
+
+	ret = pcim_enable_device(pdev);
+	if (ret) {
+		pci_err(pdev, "failed to enable device, ret = %d\n", ret);
+		return ret;
+	}
+
+	ret = pcim_iomap_regions(pdev, BIT(2), hisi_ptt->name);
+	if (ret) {
+		pci_err(pdev, "failed to remap io memory, ret = %d\n", ret);
+		return ret;
+	}
+
+	hisi_ptt->iobase = pcim_iomap_table(pdev)[2];
+
+	ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
+	if (ret) {
+		pci_err(pdev, "failed to set 64 bit dma mask, ret = %d\n", ret);
+		return ret;
+	}
+
+	pci_set_master(pdev);
+	ret = hisi_ptt_irq_register(hisi_ptt);
+	if (ret)
+		return ret;
+
+	spin_lock_init(&hisi_ptt->filter_update_lock);
+	INIT_DELAYED_WORK(&hisi_ptt->work, hisi_ptt_update_filters);
+	INIT_KFIFO(hisi_ptt->filter_update_kfifo);
+
+	hisi_ptt_init_ctrls(hisi_ptt);
+
+	ret = hisi_ptt_create_debugfs_entries(hisi_ptt);
+	if (ret) {
+		hisi_ptt_irq_unregister(hisi_ptt);
+		return ret;
+	}
+
+	/* Register the bus notifier for dynamically updating the filter list */
+	hisi_ptt->hisi_ptt_nb.notifier_call = hisi_ptt_notifier_call;
+	ret = bus_register_notifier(&pci_bus_type, &hisi_ptt->hisi_ptt_nb);
+	if (ret)
+		pci_warn(pdev, "failed to register notifier block, filter list cannot be updated dynamically\n");
+
+	return 0;
+}
+
+void hisi_ptt_remove(struct pci_dev *pdev)
+{
+	struct hisi_ptt *hisi_ptt = pci_get_drvdata(pdev);
+
+	bus_unregister_notifier(&pci_bus_type, &hisi_ptt->hisi_ptt_nb);
+	debugfs_remove_recursive(hisi_ptt->debugfs_dir);
+
+	/* Cancel any work that has been queued */
+	cancel_delayed_work_sync(&hisi_ptt->work);
+
+	/* Make sure trace is ended before free trace buffer */
+	if (hisi_ptt->trace_ctrl.status == HISI_PTT_TRACE_STATUS_ON)
+		hisi_ptt_trace_end(hisi_ptt);
+
+	hisi_ptt_release_filters(hisi_ptt);
+	hisi_ptt_free_trace_buf(hisi_ptt);
+	hisi_ptt_irq_unregister(hisi_ptt);
+}
+
+static const struct pci_device_id hisi_ptt_id_tbl[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_HUAWEI, 0xa12e) },
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, hisi_ptt_id_tbl);
+
+static struct pci_driver hisi_ptt_driver = {
+	.name = "hisi_ptt",
+	.id_table = hisi_ptt_id_tbl,
+	.probe = hisi_ptt_probe,
+	.remove = hisi_ptt_remove,
+};
+
+static int hisi_ptt_register_debugfs(void)
+{
+	if (!debugfs_initialized()) {
+		pr_err("failed to create debugfs directory: debugfs uninitialized\n");
+		return -ENOENT;
+	}
+
+	hisi_ptt_debugfs_root = debugfs_create_dir("hisi_ptt", NULL);
+	if (IS_ERR(hisi_ptt_debugfs_root)) {
+		pr_err("failed to create debugfs directory.\n");
+		return PTR_ERR(hisi_ptt_debugfs_root);
+	}
+
+	return 0;
+}
+
+static void hisi_ptt_unregister_debugfs(void)
+{
+	debugfs_remove_recursive(hisi_ptt_debugfs_root);
+}
+
+static int __init hisi_ptt_module_init(void)
+{
+	int ret;
+
+	/* The driver cannot work without debugfs entry */
+	ret = hisi_ptt_register_debugfs();
+	if (ret)
+		return ret;
+
+	ret = pci_register_driver(&hisi_ptt_driver);
+	if (ret) {
+		pr_err("failed to register hisi ptt driver, ret = %d.\n", ret);
+		hisi_ptt_unregister_debugfs();
+		return ret;
+	}
+
+	return 0;
+}
+
+static void __exit hisi_ptt_module_exit(void)
+{
+	pci_unregister_driver(&hisi_ptt_driver);
+	hisi_ptt_unregister_debugfs();
+}
+
+module_init(hisi_ptt_module_init);
+module_exit(hisi_ptt_module_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Yicong Yang <yangyicong at hisilicon.com>");
+MODULE_DESCRIPTION("Driver for HiSilicon PCIe tune and trace device");
-- 
2.8.1



From yuzenghui at huawei.com  Sat Apr 17 11:24:49 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 18:24:49 +0800
Subject: [PATCH v19 6/7] KVM: arm64: Add support for the KVM PTP service
In-Reply-To: <87v98ls2co.wl-maz@kernel.org>
References: <20210330145430.996981-1-maz@kernel.org>
 <20210330145430.996981-7-maz@kernel.org>
 <5aadf0b4-b9e5-8521-db60-52a0f319cf28@huawei.com>
 <87v98ls2co.wl-maz@kernel.org>
Message-ID: <e4130244-10a6-3251-227b-6f99c3c5899b@huawei.com>

On 2021/4/17 17:10, Marc Zyngier wrote:
> On Sat, 17 Apr 2021 09:59:39 +0100,
> Zenghui Yu <yuzenghui at huawei.com> wrote:
>>
>> On 2021/3/30 22:54, Marc Zyngier wrote:
>>> +PTP_KVM support for arm/arm64
>>> +=============================
>>> +
>>> +PTP_KVM is used for high precision time sync between host and guests.
>>> +It relies on transferring the wall clock and counter value from the
>>> +host to the guest using a KVM-specific hypercall.
>>> +
>>> +* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
>>
>> Per include/linux/arm-smccc.h, this should be
>> ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID.
> 
> Well spotted. Care to send a patch on top of my kvm-arm64/ptp branch?

Okay. I'll have a patch for that.


Zenghui


From arnd at kernel.org  Sat Apr 17 11:31:37 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sat, 17 Apr 2021 12:31:37 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416152755.GL2531743@casper.infradead.org>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
Message-ID: <CAK8P3a2dekzohOrHpLq6yyuaoyC4UOxxucu6kX2oddeq5Jdqfg@mail.gmail.com>

On Fri, Apr 16, 2021 at 5:27 PM Matthew Wilcox <willy at infradead.org> wrote:
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..db7c7020746a 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -       return page->dma_addr;
> +       dma_addr_t ret = page->dma_addr[0];
> +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +               ret |= (dma_addr_t)page->dma_addr[1] << 32;
> +       return ret;
> +}

Have you considered using a PFN type address here? I suspect you
can prove that shifting the DMA address by PAGE_BITS would
make it fit into an 'unsigned long' on all 32-bit architectures with
64-bit dma_addr_t. This requires that page->dma_addr to be
page aligned, as well as fit into 44 bits. I recently went through the
maximum address space per architecture to define a
MAX_POSSIBLE_PHYSMEM_BITS, and none of them have more than
40 here, presumably the same is true for dma address space.

        Arnd


From pali at kernel.org  Sat Apr 17 11:51:26 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Sat, 17 Apr 2021 12:51:26 +0200
Subject: =?utf-8?B?W+KAnVBBVENI?= =?utf-8?B?4oCd?= v2 2/5] PCI: armada8k:
 Add link-down handle
In-Reply-To: <1618406454-7953-3-git-send-email-bpeled@marvell.com>
References: <1618406454-7953-1-git-send-email-bpeled@marvell.com>
 <1618406454-7953-3-git-send-email-bpeled@marvell.com>
Message-ID: <20210417105126.qrqmviqnbppktzw7@pali>

On Wednesday 14 April 2021 16:20:51 bpeled at marvell.com wrote:
> From: Ben Peled <bpeled at marvell.com>
> 
> In PCIE ISR routine caused by RST_LINK_DOWN
> we schedule work to handle the link-down procedure.
> Link-down procedure will:
> 1. Remove PCIe bus
> 2. Reset the MAC
> 3. Reconfigure link back up
> 4. Rescan PCIe bus

Hello! This looks like a part of PCIe Hot Plug procedure, which is
already handled by kernel pci hotplug code, it can detect link down
interrupt and remove PCI device from the bus. I'm not sure if it would
not be better to use existing "infrastructure" for hotplug rather then
implementing new in controller driver. But I do not know what is
"correct" way, so I hope that other people (maybe Bjorn?) would say
something about this topic.

> Signed-off-by: Ben Peled <bpeled at marvell.com>
> ---
>  drivers/pci/controller/dwc/pcie-armada8k.c | 69 ++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c b/drivers/pci/controller/dwc/pcie-armada8k.c
> index b2278b1..34b253c 100644
> --- a/drivers/pci/controller/dwc/pcie-armada8k.c
> +++ b/drivers/pci/controller/dwc/pcie-armada8k.c
> @@ -22,6 +22,8 @@
>  #include <linux/resource.h>
>  #include <linux/of_pci.h>
>  #include <linux/of_irq.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
>  
>  #include "pcie-designware.h"
>  
> @@ -33,6 +35,9 @@ struct armada8k_pcie {
>  	struct clk *clk_reg;
>  	struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
>  	unsigned int phy_count;
> +	struct regmap *sysctrl_base;
> +	u32 mac_rest_bitmask;
> +	struct work_struct recover_link_work;
>  };
>  
>  #define PCIE_VENDOR_REGS_OFFSET		0x8000
> @@ -73,6 +78,8 @@ struct armada8k_pcie {
>  #define AX_USER_DOMAIN_MASK		0x3
>  #define AX_USER_DOMAIN_SHIFT		4
>  
> +#define UNIT_SOFT_RESET_CONFIG_REG	0x268
> +
>  #define to_armada8k_pcie(x)	dev_get_drvdata((x)->dev)
>  
>  static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie)
> @@ -225,6 +232,50 @@ static int armada8k_pcie_host_init(struct pcie_port *pp)
>  	return 0;
>  }
>  
> +static void armada8k_pcie_recover_link(struct work_struct *ws)
> +{
> +	struct armada8k_pcie *pcie = container_of(ws, struct armada8k_pcie, recover_link_work);
> +	struct pcie_port *pp = &pcie->pci->pp;
> +	struct pci_bus *bus = pp->bridge->bus;
> +	struct pci_dev *root_port;
> +	int ret;
> +
> +	root_port = pci_get_slot(bus, 0);
> +	if (!root_port) {
> +		dev_err(pcie->pci->dev, "failed to get root port\n");
> +		return;
> +	}
> +	pci_lock_rescan_remove();
> +	pci_stop_and_remove_bus_device(root_port);
> +	/*
> +	 * Sleep needed to make sure all pcie transactions and access
> +	 * are flushed before resetting the mac
> +	 */
> +	msleep(100);
> +
> +	/* Reset mac */
> +	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> +				pcie->mac_rest_bitmask, 0, NULL, false, true);
> +	udelay(1);
> +	regmap_update_bits_base(pcie->sysctrl_base, UNIT_SOFT_RESET_CONFIG_REG,
> +				pcie->mac_rest_bitmask, pcie->mac_rest_bitmask,
> +				NULL, false, true);
> +	udelay(1);
> +	ret = armada8k_pcie_host_init(pp);
> +	if (ret) {
> +		dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
> +		pci_unlock_rescan_remove();
> +		pci_dev_put(root_port);
> +		return;
> +	}
> +
> +	bus = NULL;
> +	while ((bus = pci_find_next_bus(bus)) != NULL)
> +		pci_rescan_bus(bus);
> +	pci_unlock_rescan_remove();
> +	pci_dev_put(root_port);
> +}
> +
>  static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
>  {
>  	struct armada8k_pcie *pcie = arg;
> @@ -262,6 +313,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)
>  		 * initiate a link retrain. If link retrains were
>  		 * possible, that is.
>  		 */
> +		if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
> +			schedule_work(&pcie->recover_link_work);
> +
>  		dev_dbg(pci->dev, "%s: link went down\n", __func__);
>  	}
>  
> @@ -330,6 +384,8 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
>  
>  	pcie->pci = pci;
>  
> +	INIT_WORK(&pcie->recover_link_work, armada8k_pcie_recover_link);
> +
>  	pcie->clk = devm_clk_get(dev, NULL);
>  	if (IS_ERR(pcie->clk))
>  		return PTR_ERR(pcie->clk);
> @@ -357,6 +413,19 @@ static int armada8k_pcie_probe(struct platform_device *pdev)
>  		goto fail_clkreg;
>  	}
>  
> +	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> +						       "marvell,system-controller");
> +	if (IS_ERR(pcie->sysctrl_base)) {
> +		dev_warn(dev, "failed to find marvell,system-controller\n");
> +		pcie->sysctrl_base = 0x0;
> +	}
> +
> +	ret = of_property_read_u32(pdev->dev.of_node, "marvell,mac-reset-bit-mask",
> +				   &pcie->mac_rest_bitmask);
> +	if (ret < 0) {
> +		dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
> +		pcie->mac_rest_bitmask = 0x0;
> +	}
>  	ret = armada8k_pcie_setup_phys(pcie);
>  	if (ret)
>  		goto fail_clkreg;
> -- 
> 2.7.4
> 


From David.Laight at ACULAB.COM  Sat Apr 17 11:59:09 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 17 Apr 2021 10:59:09 +0000
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416152755.GL2531743@casper.infradead.org>
References: <20210410205246.507048-2-willy@infradead.org>
 <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
Message-ID: <a9db4abd89624c698e86a527b93efbf6@AcuMS.aculab.com>

From: Matthew Wilcox
> Sent: 16 April 2021 16:28
> 
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch.  Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
> 
> I think this is slightly simpler, and as a bonus code that assumes the
> old layout won't compile.

Always a good plan.

...
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 32;
> +	return ret;
> +}

Won't some compiler/option combinations generate an
error for the '<< 32' when dma_addr_t is 32bit?

You might need to use a (u64) cast.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From andy.shevchenko at gmail.com  Sat Apr 17 12:06:16 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Sat, 17 Apr 2021 14:06:16 +0300
Subject: [PATCH 1/3] gpio: zynq: use module_platform_driver to simplify
 the code
In-Reply-To: <CAMpxmJV_CtFQpZvr_H0g3DvPMQZwqa-9z2FVxCLX=tF9Ytkj7Q@mail.gmail.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
 <20210409140806.31824-2-srinivas.neeli@xilinx.com>
 <CAHp75Vddd6ygr4mJ9Z+SuGZmfLcgDLWLZaxby2XE2mX8War-qQ@mail.gmail.com>
 <CAMpxmJW=HWf_NxGpfBkX=utgOTs4+6RtypxnKGtpuYnX=t8rGQ@mail.gmail.com>
 <DM6PR02MB5386CADF5A10EF28A640AD76AF4E9@DM6PR02MB5386.namprd02.prod.outlook.com>
 <CAMpxmJV_CtFQpZvr_H0g3DvPMQZwqa-9z2FVxCLX=tF9Ytkj7Q@mail.gmail.com>
Message-ID: <CAHp75VcdXg+Z0Xz7X_cZSdbockvMO6YjdqxcWp9-_P85SPFKZw@mail.gmail.com>

On Fri, Apr 16, 2021 at 9:28 PM Bartosz Golaszewski
<bgolaszewski at baylibre.com> wrote:
> On Wed, Apr 14, 2021 at 4:45 PM Srinivas Neeli <sneeli at xilinx.com> wrote:
> > > From: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > > Sent: Tuesday, April 13, 2021 4:14 PM
> > > On Sat, Apr 10, 2021 at 12:08 AM Andy Shevchenko
> > > <andy.shevchenko at gmail.com> wrote:

...

> > > Yep, this has been like this since the initial introduction of this driver.
> > > Unfortunately there's no documented reason so unless we can test it, it has
> > > to stay this way.
> > >
> > I tested driver, functionality wise everything working fine.
> > Based on below conversation, I moved driver to module driver.
> > https://lore.kernel.org/patchwork/patch/818202/
> >
>
> Andy: How about we give it a try then? If anyone yells, we'll just revert it.

Sounds like a plan!

-- 
With Best Regards,
Andy Shevchenko


From jbx6244 at gmail.com  Sat Apr 17 12:29:37 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:37 +0200
Subject: [PATCH v9 00/15] soc: rockchip: power-domain: add rk3568 powerdomains
Message-ID: <20210417112952.8516-1-jbx6244@gmail.com>

Fix power-controller node names for dtbs_check.
Convert power domain documentation to json-schema.
Add a meaningful power domain name.
Support power domain function for RK3568 Soc.

Changed in V9:
[PATCH v9 13/15]:
  Rename definitions to $defs
  Restyle patternProperties

Changed in V8:
  Add #power-domain-cells to power domain nodes.
  Convert pmu.txt to YAML.
  Add more compatible strings to pmu.yaml
[PATCH v8 13/15]:
  Add pd-node ref schema.

Changed in V7:
[PATCH v7 07/11]:
  Fix TAB warning
  Fix alignment
[PATCH v7 09/11]:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
[PATCH v7 11/11]:
  Fix alignment

Changed in V6:
[PATCH v6 7/11]: Use kbasename(node->full_name).
[PATCH v6 9/11]: Update the commit message.

Changed in V5:
[PATCH v5 1/11]: New.
[PATCH v5 2/11]: New.
[PATCH v5 3/11]: New.
[PATCH v5 4/11]: New.
[PATCH v5 5/11]: New.
[PATCH v5 6/11]: New.
[PATCH v5 7/11]: New.
[PATCH v5 8/11]: No change. Same as [PATCH v4 1/4].
[PATCH v5 9/11]: [PATCH v4 2/4] Fix up yaml code styles.
[PATCH v5 10/11]: No change. Same as [PATCH v4 3/4].
[PATCH v5 11/11]: [PATCH v4 4/4] add a meaningful power domain name for
RK3568 Soc.

Changed in V4:
[PATCH v4 2/4]: Fix up yaml code styles. Remove the new compatible to [PATCH v4 3/4]
[PATCH v4 3/4]: Adding new compatible for RK3568 Soc.
[PATCH v4 4/4]: No change. Same as [PATCH v3 3/3].

Changed in V3:
[PATCH v3 2/3]: Fix up the code styles and add rk3568 base on:
https://patchwork.kernel.org/project/linux-rockchip/patch/20210225102643.653095-1-enric.balletbo at collabora.com/

Changed in V2:
[PATCH v2 2/3]: Fix up yaml code styles.

Elaine Zhang (10):
  ARM: dts: rockchip: Fix power-controller node names for rk3066a
  ARM: dts: rockchip: Fix power-controller node names for rk3188
  ARM: dts: rockchip: Fix power-controller node names for rk3288
  arm64: dts: rockchip: Fix power-controller node names for px30
  arm64: dts: rockchip: Fix power-controller node names for rk3328
  arm64: dts: rockchip: Fix power-controller node names for rk3399
  soc: rockchip: pm-domains: Add a meaningful power domain name
  dt-bindings: add power-domain header for RK3568 SoCs
  dt-bindings: power: rockchip: Add bindings for RK3568 Soc
  soc: rockchip: power-domain: add rk3568 powerdomains

Enric Balletbo i Serra (1):
  dt-bindings: power: rockchip: Convert to json-schema

Johan Jonker (4):
  ARM: dts: rockchip: add #power-domain-cells to power domain nodes
  arm64: dts: rockchip: add #power-domain-cells to power domain nodes
  dt-bindings: arm: rockchip: convert pmu.txt to YAML
  dt-bindings: arm: rockchip: add more compatible strings to pmu.yaml

 .../devicetree/bindings/arm/rockchip/pmu.txt       |  16 --
 .../devicetree/bindings/arm/rockchip/pmu.yaml      |  57 +++++
 .../bindings/power/rockchip,power-controller.yaml  | 248 ++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 -----------
 arch/arm/boot/dts/rk3066a.dtsi                     |   9 +-
 arch/arm/boot/dts/rk3188.dtsi                      |   9 +-
 arch/arm/boot/dts/rk3288.dtsi                      |  12 +-
 arch/arm64/boot/dts/rockchip/px30.dtsi             |  24 +-
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |   9 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  60 +++--
 drivers/soc/rockchip/pm_domains.c                  | 252 ++++++++++++---------
 include/dt-bindings/power/rk3568-power.h           |  32 +++
 12 files changed, 564 insertions(+), 300 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
 create mode 100644 include/dt-bindings/power/rk3568-power.h

-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:38 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:38 +0200
Subject: [PATCH v9 01/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3066a
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-2-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed
---
 arch/arm/boot/dts/rk3066a.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..bbc3bff50 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -755,7 +755,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3066_PD_VIO {
+		power-domain at RK3066_PD_VIO {
 			reg = <RK3066_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -782,7 +782,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3066_PD_VIDEO {
+		power-domain at RK3066_PD_VIDEO {
 			reg = <RK3066_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -791,7 +791,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3066_PD_GPU {
+		power-domain at RK3066_PD_GPU {
 			reg = <RK3066_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:39 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:39 +0200
Subject: [PATCH v9 02/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3188
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-3-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3188.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 2298a8d84..5db32fdbe 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -699,7 +699,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		pd_vio at RK3188_PD_VIO {
+		power-domain at RK3188_PD_VIO {
 			reg = <RK3188_PD_VIO>;
 			clocks = <&cru ACLK_LCDC0>,
 				 <&cru ACLK_LCDC1>,
@@ -721,7 +721,7 @@
 				 <&qos_rga>;
 		};
 
-		pd_video at RK3188_PD_VIDEO {
+		power-domain at RK3188_PD_VIDEO {
 			reg = <RK3188_PD_VIDEO>;
 			clocks = <&cru ACLK_VDPU>,
 				 <&cru ACLK_VEPU>,
@@ -730,7 +730,7 @@
 			pm_qos = <&qos_vpu>;
 		};
 
-		pd_gpu at RK3188_PD_GPU {
+		power-domain at RK3188_PD_GPU {
 			reg = <RK3188_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:41 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:41 +0200
Subject: [PATCH v9 04/15] ARM: dts: rockchip: add #power-domain-cells to power
 domain nodes
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-5-jbx6244@gmail.com>

Add #power-domain-cells to power domain nodes, because they
are required by power-domain.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3066a.dtsi | 3 +++
 arch/arm/boot/dts/rk3188.dtsi  | 3 +++
 arch/arm/boot/dts/rk3288.dtsi  | 4 ++++
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index bbc3bff50..8e087c34b 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -780,6 +780,7 @@
 				 <&qos_cif1>,
 				 <&qos_ipp>,
 				 <&qos_rga>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3066_PD_VIDEO {
@@ -789,12 +790,14 @@
 				 <&cru HCLK_VDPU>,
 				 <&cru HCLK_VEPU>;
 			pm_qos = <&qos_vpu>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3066_PD_GPU {
 			reg = <RK3066_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
+			#power-domain-cells = <0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 5db32fdbe..f438170b4 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -719,6 +719,7 @@
 				 <&qos_cif0>,
 				 <&qos_ipp>,
 				 <&qos_rga>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3188_PD_VIDEO {
@@ -728,12 +729,14 @@
 				 <&cru HCLK_VDPU>,
 				 <&cru HCLK_VEPU>;
 			pm_qos = <&qos_vpu>;
+			#power-domain-cells = <0>;
 		};
 
 		power-domain at RK3188_PD_GPU {
 			reg = <RK3188_PD_GPU>;
 			clocks = <&cru ACLK_GPU>;
 			pm_qos = <&qos_gpu>;
+			#power-domain-cells = <0>;
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6f4d7929e..bf2d8ab61 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -805,6 +805,7 @@
 					 <&qos_vio2_rga_r>,
 					 <&qos_vio2_rga_w>,
 					 <&qos_vio1_isp_r>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -818,6 +819,7 @@
 					 <&cru SCLK_HEVC_CORE>;
 				pm_qos = <&qos_hevc_r>,
 					 <&qos_hevc_w>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -830,6 +832,7 @@
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video>;
+				#power-domain-cells = <0>;
 			};
 
 			/*
@@ -841,6 +844,7 @@
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu_r>,
 					 <&qos_gpu_w>;
+				#power-domain-cells = <0>;
 			};
 		};
 
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:42 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:42 +0200
Subject: [PATCH v9 05/15] arm64: dts: rockchip: Fix power-controller node
 names for px30
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-6-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a16..2b43c3d72 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -244,20 +244,20 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_usb at PX30_PD_USB {
+			power-domain at PX30_PD_USB {
 				reg = <PX30_PD_USB>;
 				clocks = <&cru HCLK_HOST>,
 					 <&cru HCLK_OTG>,
 					 <&cru SCLK_OTG_ADP>;
 				pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
 			};
-			pd_sdcard at PX30_PD_SDCARD {
+			power-domain at PX30_PD_SDCARD {
 				reg = <PX30_PD_SDCARD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sdmmc>;
 			};
-			pd_gmac at PX30_PD_GMAC {
+			power-domain at PX30_PD_GMAC {
 				reg = <PX30_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>,
@@ -265,7 +265,7 @@
 					 <&cru SCLK_GMAC_RX_TX>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_mmc_nand at PX30_PD_MMC_NAND {
+			power-domain at PX30_PD_MMC_NAND {
 				reg = <PX30_PD_MMC_NAND>;
 				clocks =  <&cru HCLK_NANDC>,
 					  <&cru HCLK_EMMC>,
@@ -278,14 +278,14 @@
 				pm_qos = <&qos_emmc>, <&qos_nand>,
 					 <&qos_sdio>, <&qos_sfc>;
 			};
-			pd_vpu at PX30_PD_VPU {
+			power-domain at PX30_PD_VPU {
 				reg = <PX30_PD_VPU>;
 				clocks = <&cru ACLK_VPU>,
 					 <&cru HCLK_VPU>,
 					 <&cru SCLK_CORE_VPU>;
 				pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
 			};
-			pd_vo at PX30_PD_VO {
+			power-domain at PX30_PD_VO {
 				reg = <PX30_PD_VO>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru ACLK_VOPB>,
@@ -301,7 +301,7 @@
 				pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
 					 <&qos_vop_m0>, <&qos_vop_m1>;
 			};
-			pd_vi at PX30_PD_VI {
+			power-domain at PX30_PD_VI {
 				reg = <PX30_PD_VI>;
 				clocks = <&cru ACLK_CIF>,
 					 <&cru ACLK_ISP>,
@@ -312,7 +312,7 @@
 					 <&qos_isp_wr>, <&qos_isp_m1>,
 					 <&qos_vip>;
 			};
-			pd_gpu at PX30_PD_GPU {
+			power-domain at PX30_PD_GPU {
 				reg = <PX30_PD_GPU>;
 				clocks = <&cru SCLK_GPU>;
 				pm_qos = <&qos_gpu>;
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:40 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:40 +0200
Subject: [PATCH v9 03/15] ARM: dts: rockchip: Fix power-controller node names
 for rk3288
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-4-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ea7416c31..6f4d7929e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -769,7 +769,7 @@
 			 *	*_HDMI		HDMI
 			 *	*_MIPI_*	MIPI
 			 */
-			pd_vio at RK3288_PD_VIO {
+			power-domain at RK3288_PD_VIO {
 				reg = <RK3288_PD_VIO>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru ACLK_ISP>,
@@ -811,7 +811,7 @@
 			 * Note: The following 3 are HEVC(H.265) clocks,
 			 * and on the ACLK_HEVC_NIU (NOC).
 			 */
-			pd_hevc at RK3288_PD_HEVC {
+			power-domain at RK3288_PD_HEVC {
 				reg = <RK3288_PD_HEVC>;
 				clocks = <&cru ACLK_HEVC>,
 					 <&cru SCLK_HEVC_CABAC>,
@@ -825,7 +825,7 @@
 			 * (video endecoder & decoder) clocks that on the
 			 * ACLK_VCODEC_NIU and HCLK_VCODEC_NIU (NOC).
 			 */
-			pd_video at RK3288_PD_VIDEO {
+			power-domain at RK3288_PD_VIDEO {
 				reg = <RK3288_PD_VIDEO>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
@@ -836,7 +836,7 @@
 			 * Note: ACLK_GPU is the GPU clock,
 			 * and on the ACLK_GPU_NIU (NOC).
 			 */
-			pd_gpu at RK3288_PD_GPU {
+			power-domain at RK3288_PD_GPU {
 				reg = <RK3288_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu_r>,
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:44 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:44 +0200
Subject: [PATCH v9 07/15] arm64: dts: rockchip: Fix power-controller node
 names for rk3399
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-8-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 40 ++++++++++++++++----------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 0f2879cc1..19614c2ce 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -968,26 +968,26 @@
 			#size-cells = <0>;
 
 			/* These power domains are grouped by VD_CENTER */
-			pd_iep at RK3399_PD_IEP {
+			power-domain at RK3399_PD_IEP {
 				reg = <RK3399_PD_IEP>;
 				clocks = <&cru ACLK_IEP>,
 					 <&cru HCLK_IEP>;
 				pm_qos = <&qos_iep>;
 			};
-			pd_rga at RK3399_PD_RGA {
+			power-domain at RK3399_PD_RGA {
 				reg = <RK3399_PD_RGA>;
 				clocks = <&cru ACLK_RGA>,
 					 <&cru HCLK_RGA>;
 				pm_qos = <&qos_rga_r>,
 					 <&qos_rga_w>;
 			};
-			pd_vcodec at RK3399_PD_VCODEC {
+			power-domain at RK3399_PD_VCODEC {
 				reg = <RK3399_PD_VCODEC>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video_m0>;
 			};
-			pd_vdu at RK3399_PD_VDU {
+			power-domain at RK3399_PD_VDU {
 				reg = <RK3399_PD_VDU>;
 				clocks = <&cru ACLK_VDU>,
 					 <&cru HCLK_VDU>;
@@ -996,94 +996,94 @@
 			};
 
 			/* These power domains are grouped by VD_GPU */
-			pd_gpu at RK3399_PD_GPU {
+			power-domain at RK3399_PD_GPU {
 				reg = <RK3399_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu>;
 			};
 
 			/* These power domains are grouped by VD_LOGIC */
-			pd_edp at RK3399_PD_EDP {
+			power-domain at RK3399_PD_EDP {
 				reg = <RK3399_PD_EDP>;
 				clocks = <&cru PCLK_EDP_CTRL>;
 			};
-			pd_emmc at RK3399_PD_EMMC {
+			power-domain at RK3399_PD_EMMC {
 				reg = <RK3399_PD_EMMC>;
 				clocks = <&cru ACLK_EMMC>;
 				pm_qos = <&qos_emmc>;
 			};
-			pd_gmac at RK3399_PD_GMAC {
+			power-domain at RK3399_PD_GMAC {
 				reg = <RK3399_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>;
 				pm_qos = <&qos_gmac>;
 			};
-			pd_sd at RK3399_PD_SD {
+			power-domain at RK3399_PD_SD {
 				reg = <RK3399_PD_SD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sd>;
 			};
-			pd_sdioaudio at RK3399_PD_SDIOAUDIO {
+			power-domain at RK3399_PD_SDIOAUDIO {
 				reg = <RK3399_PD_SDIOAUDIO>;
 				clocks = <&cru HCLK_SDIO>;
 				pm_qos = <&qos_sdioaudio>;
 			};
-			pd_tcpc0 at RK3399_PD_TCPD0 {
+			power-domain at RK3399_PD_TCPD0 {
 				reg = <RK3399_PD_TCPD0>;
 				clocks = <&cru SCLK_UPHY0_TCPDCORE>,
 					 <&cru SCLK_UPHY0_TCPDPHY_REF>;
 			};
-			pd_tcpc1 at RK3399_PD_TCPD1 {
+			power-domain at RK3399_PD_TCPD1 {
 				reg = <RK3399_PD_TCPD1>;
 				clocks = <&cru SCLK_UPHY1_TCPDCORE>,
 					 <&cru SCLK_UPHY1_TCPDPHY_REF>;
 			};
-			pd_usb3 at RK3399_PD_USB3 {
+			power-domain at RK3399_PD_USB3 {
 				reg = <RK3399_PD_USB3>;
 				clocks = <&cru ACLK_USB3>;
 				pm_qos = <&qos_usb_otg0>,
 					 <&qos_usb_otg1>;
 			};
-			pd_vio at RK3399_PD_VIO {
+			power-domain at RK3399_PD_VIO {
 				reg = <RK3399_PD_VIO>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				pd_hdcp at RK3399_PD_HDCP {
+				power-domain at RK3399_PD_HDCP {
 					reg = <RK3399_PD_HDCP>;
 					clocks = <&cru ACLK_HDCP>,
 						 <&cru HCLK_HDCP>,
 						 <&cru PCLK_HDCP>;
 					pm_qos = <&qos_hdcp>;
 				};
-				pd_isp0 at RK3399_PD_ISP0 {
+				power-domain at RK3399_PD_ISP0 {
 					reg = <RK3399_PD_ISP0>;
 					clocks = <&cru ACLK_ISP0>,
 						 <&cru HCLK_ISP0>;
 					pm_qos = <&qos_isp0_m0>,
 						 <&qos_isp0_m1>;
 				};
-				pd_isp1 at RK3399_PD_ISP1 {
+				power-domain at RK3399_PD_ISP1 {
 					reg = <RK3399_PD_ISP1>;
 					clocks = <&cru ACLK_ISP1>,
 						 <&cru HCLK_ISP1>;
 					pm_qos = <&qos_isp1_m0>,
 						 <&qos_isp1_m1>;
 				};
-				pd_vo at RK3399_PD_VO {
+				power-domain at RK3399_PD_VO {
 					reg = <RK3399_PD_VO>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 
-					pd_vopb at RK3399_PD_VOPB {
+					power-domain at RK3399_PD_VOPB {
 						reg = <RK3399_PD_VOPB>;
 						clocks = <&cru ACLK_VOP0>,
 							 <&cru HCLK_VOP0>;
 						pm_qos = <&qos_vop_big_r>,
 							 <&qos_vop_big_w>;
 					};
-					pd_vopl at RK3399_PD_VOPL {
+					power-domain at RK3399_PD_VOPL {
 						reg = <RK3399_PD_VOPL>;
 						clocks = <&cru ACLK_VOP1>,
 							 <&cru HCLK_VOP1>;
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:47 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:47 +0200
Subject: [PATCH v9 10/15] dt-bindings: add power-domain header for RK3568 SoCs
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-11-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/power/rk3568-power.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3568-power.h

diff --git a/include/dt-bindings/power/rk3568-power.h b/include/dt-bindings/power/rk3568-power.h
new file mode 100644
index 000000000..6cc1af1a9
--- /dev/null
+++ b/include/dt-bindings/power/rk3568-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3568_POWER_H__
+#define __DT_BINDINGS_POWER_RK3568_POWER_H__
+
+/* VD_CORE */
+#define RK3568_PD_CPU_0		0
+#define RK3568_PD_CPU_1		1
+#define RK3568_PD_CPU_2		2
+#define RK3568_PD_CPU_3		3
+#define RK3568_PD_CORE_ALIVE	4
+
+/* VD_PMU */
+#define RK3568_PD_PMU		5
+
+/* VD_NPU */
+#define RK3568_PD_NPU		6
+
+/* VD_GPU */
+#define RK3568_PD_GPU		7
+
+/* VD_LOGIC */
+#define RK3568_PD_VI		8
+#define RK3568_PD_VO		9
+#define RK3568_PD_RGA		10
+#define RK3568_PD_VPU		11
+#define RK3568_PD_CENTER	12
+#define RK3568_PD_RKVDEC	13
+#define RK3568_PD_RKVENC	14
+#define RK3568_PD_PIPE		15
+#define RK3568_PD_LOGIC_ALIVE	16
+
+#endif
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:45 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:45 +0200
Subject: [PATCH v9 08/15] arm64: dts: rockchip: add #power-domain-cells to
 power domain nodes
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-9-jbx6244@gmail.com>

Add #power-domain-cells to power domain nodes, because they
are required by power-domain.yaml

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/px30.dtsi   |  8 ++++++++
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  3 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 ++++++++++++++++++++
 3 files changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2b43c3d72..c96ebfe3e 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -250,12 +250,14 @@
 					 <&cru HCLK_OTG>,
 					 <&cru SCLK_OTG_ADP>;
 				pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_SDCARD {
 				reg = <PX30_PD_SDCARD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sdmmc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_GMAC {
 				reg = <PX30_PD_GMAC>;
@@ -264,6 +266,7 @@
 					 <&cru SCLK_MAC_REF>,
 					 <&cru SCLK_GMAC_RX_TX>;
 				pm_qos = <&qos_gmac>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_MMC_NAND {
 				reg = <PX30_PD_MMC_NAND>;
@@ -277,6 +280,7 @@
 					  <&cru SCLK_SFC>;
 				pm_qos = <&qos_emmc>, <&qos_nand>,
 					 <&qos_sdio>, <&qos_sfc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VPU {
 				reg = <PX30_PD_VPU>;
@@ -284,6 +288,7 @@
 					 <&cru HCLK_VPU>,
 					 <&cru SCLK_CORE_VPU>;
 				pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VO {
 				reg = <PX30_PD_VO>;
@@ -300,6 +305,7 @@
 					 <&cru SCLK_VOPB_PWM>;
 				pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
 					 <&qos_vop_m0>, <&qos_vop_m1>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_VI {
 				reg = <PX30_PD_VI>;
@@ -311,11 +317,13 @@
 				pm_qos = <&qos_isp_128>, <&qos_isp_rd>,
 					 <&qos_isp_wr>, <&qos_isp_m1>,
 					 <&qos_vip>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at PX30_PD_GPU {
 				reg = <PX30_PD_GPU>;
 				clocks = <&cru SCLK_GPU>;
 				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
 			};
 		};
 	};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 35df57535..470da614e 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -302,13 +302,16 @@
 
 			power-domain at RK3328_PD_HEVC {
 				reg = <RK3328_PD_HEVC>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3328_PD_VIDEO {
 				reg = <RK3328_PD_VIDEO>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3328_PD_VPU {
 				reg = <RK3328_PD_VPU>;
 				clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+				#power-domain-cells = <0>;
 			};
 		};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 19614c2ce..99f85b1d9 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -973,6 +973,7 @@
 				clocks = <&cru ACLK_IEP>,
 					 <&cru HCLK_IEP>;
 				pm_qos = <&qos_iep>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_RGA {
 				reg = <RK3399_PD_RGA>;
@@ -980,12 +981,14 @@
 					 <&cru HCLK_RGA>;
 				pm_qos = <&qos_rga_r>,
 					 <&qos_rga_w>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VCODEC {
 				reg = <RK3399_PD_VCODEC>;
 				clocks = <&cru ACLK_VCODEC>,
 					 <&cru HCLK_VCODEC>;
 				pm_qos = <&qos_video_m0>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VDU {
 				reg = <RK3399_PD_VDU>;
@@ -993,6 +996,7 @@
 					 <&cru HCLK_VDU>;
 				pm_qos = <&qos_video_m1_r>,
 					 <&qos_video_m1_w>;
+				#power-domain-cells = <0>;
 			};
 
 			/* These power domains are grouped by VD_GPU */
@@ -1000,53 +1004,63 @@
 				reg = <RK3399_PD_GPU>;
 				clocks = <&cru ACLK_GPU>;
 				pm_qos = <&qos_gpu>;
+				#power-domain-cells = <0>;
 			};
 
 			/* These power domains are grouped by VD_LOGIC */
 			power-domain at RK3399_PD_EDP {
 				reg = <RK3399_PD_EDP>;
 				clocks = <&cru PCLK_EDP_CTRL>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_EMMC {
 				reg = <RK3399_PD_EMMC>;
 				clocks = <&cru ACLK_EMMC>;
 				pm_qos = <&qos_emmc>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_GMAC {
 				reg = <RK3399_PD_GMAC>;
 				clocks = <&cru ACLK_GMAC>,
 					 <&cru PCLK_GMAC>;
 				pm_qos = <&qos_gmac>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_SD {
 				reg = <RK3399_PD_SD>;
 				clocks = <&cru HCLK_SDMMC>,
 					 <&cru SCLK_SDMMC>;
 				pm_qos = <&qos_sd>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_SDIOAUDIO {
 				reg = <RK3399_PD_SDIOAUDIO>;
 				clocks = <&cru HCLK_SDIO>;
 				pm_qos = <&qos_sdioaudio>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_TCPD0 {
 				reg = <RK3399_PD_TCPD0>;
 				clocks = <&cru SCLK_UPHY0_TCPDCORE>,
 					 <&cru SCLK_UPHY0_TCPDPHY_REF>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_TCPD1 {
 				reg = <RK3399_PD_TCPD1>;
 				clocks = <&cru SCLK_UPHY1_TCPDCORE>,
 					 <&cru SCLK_UPHY1_TCPDPHY_REF>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_USB3 {
 				reg = <RK3399_PD_USB3>;
 				clocks = <&cru ACLK_USB3>;
 				pm_qos = <&qos_usb_otg0>,
 					 <&qos_usb_otg1>;
+				#power-domain-cells = <0>;
 			};
 			power-domain at RK3399_PD_VIO {
 				reg = <RK3399_PD_VIO>;
+				#power-domain-cells = <1>;
 				#address-cells = <1>;
 				#size-cells = <0>;
 
@@ -1056,6 +1070,7 @@
 						 <&cru HCLK_HDCP>,
 						 <&cru PCLK_HDCP>;
 					pm_qos = <&qos_hdcp>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_ISP0 {
 					reg = <RK3399_PD_ISP0>;
@@ -1063,6 +1078,7 @@
 						 <&cru HCLK_ISP0>;
 					pm_qos = <&qos_isp0_m0>,
 						 <&qos_isp0_m1>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_ISP1 {
 					reg = <RK3399_PD_ISP1>;
@@ -1070,9 +1086,11 @@
 						 <&cru HCLK_ISP1>;
 					pm_qos = <&qos_isp1_m0>,
 						 <&qos_isp1_m1>;
+					#power-domain-cells = <0>;
 				};
 				power-domain at RK3399_PD_VO {
 					reg = <RK3399_PD_VO>;
+					#power-domain-cells = <1>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 
@@ -1082,12 +1100,14 @@
 							 <&cru HCLK_VOP0>;
 						pm_qos = <&qos_vop_big_r>,
 							 <&qos_vop_big_w>;
+						#power-domain-cells = <0>;
 					};
 					power-domain at RK3399_PD_VOPL {
 						reg = <RK3399_PD_VOPL>;
 						clocks = <&cru ACLK_VOP1>,
 							 <&cru HCLK_VOP1>;
 						pm_qos = <&qos_vop_little>;
+						#power-domain-cells = <0>;
 					};
 				};
 			};
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:46 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:46 +0200
Subject: [PATCH v9 09/15] soc: rockchip: pm-domains: Add a meaningful power
 domain name
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-10-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the power domains names to the power domain info struct so we
have meaningful name for every power domain.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix TAB warning
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 221 ++++++++++++++++++++------------------
 1 file changed, 114 insertions(+), 107 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 54eb6cfc5..1d1b06672 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -29,6 +29,7 @@
 #include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
+	const char *name;
 	int pwr_mask;
 	int status_mask;
 	int req_mask;
@@ -85,8 +86,9 @@ struct rockchip_pmu {
 
 #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
 
-#define DOMAIN(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
 	.req_mask = (req),				\
@@ -95,8 +97,9 @@ struct rockchip_pmu {
 	.active_wakeup = (wakeup),			\
 }
 
-#define DOMAIN_M(pwr, status, req, idle, ack, wakeup)	\
+#define DOMAIN_M(_name, pwr, status, req, idle, ack, wakeup)	\
 {							\
+	.name = _name,				\
 	.pwr_w_mask = (pwr) << 16,			\
 	.pwr_mask = (pwr),				\
 	.status_mask = (status),			\
@@ -107,8 +110,9 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_RK3036(req, ack, idle, wakeup)		\
+#define DOMAIN_RK3036(_name, req, ack, idle, wakeup)		\
 {							\
+	.name = _name,				\
 	.req_mask = (req),				\
 	.req_w_mask = (req) << 16,			\
 	.ack_mask = (ack),				\
@@ -116,20 +120,20 @@ struct rockchip_pmu {
 	.active_wakeup = wakeup,			\
 }
 
-#define DOMAIN_PX30(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_PX30(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3288(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, (req) << 16, wakeup)
+#define DOMAIN_RK3288(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, (req) << 16, wakeup)
 
-#define DOMAIN_RK3328(pwr, status, req, wakeup)		\
-	DOMAIN_M(pwr, pwr, req, (req) << 10, req, wakeup)
+#define DOMAIN_RK3328(name, pwr, status, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, (req) << 10, req, wakeup)
 
-#define DOMAIN_RK3368(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, (req) << 16, req, wakeup)
+#define DOMAIN_RK3368(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, (req) << 16, req, wakeup)
 
-#define DOMAIN_RK3399(pwr, status, req, wakeup)		\
-	DOMAIN(pwr, status, req, req, req, wakeup)
+#define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
+	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
@@ -490,7 +494,10 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
 		goto err_unprepare_clocks;
 	}
 
-	pd->genpd.name = node->name;
+	if (pd->info->name)
+		pd->genpd.name = pd->info->name;
+	else
+		pd->genpd.name = kbasename(node->full_name);
 	pd->genpd.power_off = rockchip_pd_power_off;
 	pd->genpd.power_on = rockchip_pd_power_on;
 	pd->genpd.attach_dev = rockchip_pd_attach_dev;
@@ -716,129 +723,129 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 }
 
 static const struct rockchip_domain_info px30_pm_domains[] = {
-	[PX30_PD_USB]		= DOMAIN_PX30(BIT(5),  BIT(5),  BIT(10), false),
-	[PX30_PD_SDCARD]	= DOMAIN_PX30(BIT(8),  BIT(8),  BIT(9),  false),
-	[PX30_PD_GMAC]		= DOMAIN_PX30(BIT(10), BIT(10), BIT(6),  false),
-	[PX30_PD_MMC_NAND]	= DOMAIN_PX30(BIT(11), BIT(11), BIT(5),  false),
-	[PX30_PD_VPU]		= DOMAIN_PX30(BIT(12), BIT(12), BIT(14), false),
-	[PX30_PD_VO]		= DOMAIN_PX30(BIT(13), BIT(13), BIT(7),  false),
-	[PX30_PD_VI]		= DOMAIN_PX30(BIT(14), BIT(14), BIT(8),  false),
-	[PX30_PD_GPU]		= DOMAIN_PX30(BIT(15), BIT(15), BIT(2),  false),
+	[PX30_PD_USB]		= DOMAIN_PX30("usb",      BIT(5),  BIT(5),  BIT(10), false),
+	[PX30_PD_SDCARD]	= DOMAIN_PX30("sdcard",   BIT(8),  BIT(8),  BIT(9),  false),
+	[PX30_PD_GMAC]		= DOMAIN_PX30("gmac",     BIT(10), BIT(10), BIT(6),  false),
+	[PX30_PD_MMC_NAND]	= DOMAIN_PX30("mmc_nand", BIT(11), BIT(11), BIT(5),  false),
+	[PX30_PD_VPU]		= DOMAIN_PX30("vpu",      BIT(12), BIT(12), BIT(14), false),
+	[PX30_PD_VO]		= DOMAIN_PX30("vo",       BIT(13), BIT(13), BIT(7),  false),
+	[PX30_PD_VI]		= DOMAIN_PX30("vi",       BIT(14), BIT(14), BIT(8),  false),
+	[PX30_PD_GPU]		= DOMAIN_PX30("gpu",      BIT(15), BIT(15), BIT(2),  false),
 };
 
 static const struct rockchip_domain_info rk3036_pm_domains[] = {
-	[RK3036_PD_MSCH]	= DOMAIN_RK3036(BIT(14), BIT(23), BIT(30), true),
-	[RK3036_PD_CORE]	= DOMAIN_RK3036(BIT(13), BIT(17), BIT(24), false),
-	[RK3036_PD_PERI]	= DOMAIN_RK3036(BIT(12), BIT(18), BIT(25), false),
-	[RK3036_PD_VIO]		= DOMAIN_RK3036(BIT(11), BIT(19), BIT(26), false),
-	[RK3036_PD_VPU]		= DOMAIN_RK3036(BIT(10), BIT(20), BIT(27), false),
-	[RK3036_PD_GPU]		= DOMAIN_RK3036(BIT(9),  BIT(21), BIT(28), false),
-	[RK3036_PD_SYS]		= DOMAIN_RK3036(BIT(8),  BIT(22), BIT(29), false),
+	[RK3036_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(14), BIT(23), BIT(30), true),
+	[RK3036_PD_CORE]	= DOMAIN_RK3036("core", BIT(13), BIT(17), BIT(24), false),
+	[RK3036_PD_PERI]	= DOMAIN_RK3036("peri", BIT(12), BIT(18), BIT(25), false),
+	[RK3036_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(11), BIT(19), BIT(26), false),
+	[RK3036_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(10), BIT(20), BIT(27), false),
+	[RK3036_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(9),  BIT(21), BIT(28), false),
+	[RK3036_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(8),  BIT(22), BIT(29), false),
 };
 
 static const struct rockchip_domain_info rk3066_pm_domains[] = {
-	[RK3066_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3066_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3066_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3066_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3066_PD_CPU]		= DOMAIN(0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3066_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3066_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3066_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3066_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3066_PD_CPU]		= DOMAIN("cpu",   0,      BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3128_pm_domains[] = {
-	[RK3128_PD_CORE]	= DOMAIN_RK3288(BIT(0), BIT(0), BIT(4), false),
-	[RK3128_PD_MSCH]	= DOMAIN_RK3288(0,      0,      BIT(6), true),
-	[RK3128_PD_VIO]		= DOMAIN_RK3288(BIT(3), BIT(3), BIT(2), false),
-	[RK3128_PD_VIDEO]	= DOMAIN_RK3288(BIT(2), BIT(2), BIT(1), false),
-	[RK3128_PD_GPU]		= DOMAIN_RK3288(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),
 };
 
 static const struct rockchip_domain_info rk3188_pm_domains[] = {
-	[RK3188_PD_GPU]		= DOMAIN(BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
-	[RK3188_PD_VIDEO]	= DOMAIN(BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
-	[RK3188_PD_VIO]		= DOMAIN(BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
-	[RK3188_PD_PERI]	= DOMAIN(BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
-	[RK3188_PD_CPU]		= DOMAIN(BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
+	[RK3188_PD_GPU]		= DOMAIN("gpu",   BIT(9), BIT(9), BIT(3), BIT(24), BIT(29), false),
+	[RK3188_PD_VIDEO]	= DOMAIN("video", BIT(8), BIT(8), BIT(4), BIT(23), BIT(28), false),
+	[RK3188_PD_VIO]		= DOMAIN("vio",   BIT(7), BIT(7), BIT(5), BIT(22), BIT(27), false),
+	[RK3188_PD_PERI]	= DOMAIN("peri",  BIT(6), BIT(6), BIT(2), BIT(25), BIT(30), false),
+	[RK3188_PD_CPU]		= DOMAIN("cpu",   BIT(5), BIT(5), BIT(1), BIT(26), BIT(31), false),
 };
 
 static const struct rockchip_domain_info rk3228_pm_domains[] = {
-	[RK3228_PD_CORE]	= DOMAIN_RK3036(BIT(0),  BIT(0),  BIT(16), true),
-	[RK3228_PD_MSCH]	= DOMAIN_RK3036(BIT(1),  BIT(1),  BIT(17), true),
-	[RK3228_PD_BUS]		= DOMAIN_RK3036(BIT(2),  BIT(2),  BIT(18), true),
-	[RK3228_PD_SYS]		= DOMAIN_RK3036(BIT(3),  BIT(3),  BIT(19), true),
-	[RK3228_PD_VIO]		= DOMAIN_RK3036(BIT(4),  BIT(4),  BIT(20), false),
-	[RK3228_PD_VOP]		= DOMAIN_RK3036(BIT(5),  BIT(5),  BIT(21), false),
-	[RK3228_PD_VPU]		= DOMAIN_RK3036(BIT(6),  BIT(6),  BIT(22), false),
-	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036(BIT(7),  BIT(7),  BIT(23), false),
-	[RK3228_PD_GPU]		= DOMAIN_RK3036(BIT(8),  BIT(8),  BIT(24), false),
-	[RK3228_PD_PERI]	= DOMAIN_RK3036(BIT(9),  BIT(9),  BIT(25), true),
-	[RK3228_PD_GMAC]	= DOMAIN_RK3036(BIT(10), BIT(10), BIT(26), false),
+	[RK3228_PD_CORE]	= DOMAIN_RK3036("core", BIT(0),  BIT(0),  BIT(16), true),
+	[RK3228_PD_MSCH]	= DOMAIN_RK3036("msch", BIT(1),  BIT(1),  BIT(17), true),
+	[RK3228_PD_BUS]		= DOMAIN_RK3036("bus",  BIT(2),  BIT(2),  BIT(18), true),
+	[RK3228_PD_SYS]		= DOMAIN_RK3036("sys",  BIT(3),  BIT(3),  BIT(19), true),
+	[RK3228_PD_VIO]		= DOMAIN_RK3036("vio",  BIT(4),  BIT(4),  BIT(20), false),
+	[RK3228_PD_VOP]		= DOMAIN_RK3036("vop",  BIT(5),  BIT(5),  BIT(21), false),
+	[RK3228_PD_VPU]		= DOMAIN_RK3036("vpu",  BIT(6),  BIT(6),  BIT(22), false),
+	[RK3228_PD_RKVDEC]	= DOMAIN_RK3036("vdec", BIT(7),  BIT(7),  BIT(23), false),
+	[RK3228_PD_GPU]		= DOMAIN_RK3036("gpu",  BIT(8),  BIT(8),  BIT(24), false),
+	[RK3228_PD_PERI]	= DOMAIN_RK3036("peri", BIT(9),  BIT(9),  BIT(25), true),
+	[RK3228_PD_GMAC]	= DOMAIN_RK3036("gmac", BIT(10), BIT(10), BIT(26), false),
 };
 
 static const struct rockchip_domain_info rk3288_pm_domains[] = {
-	[RK3288_PD_VIO]		= DOMAIN_RK3288(BIT(7),  BIT(7),  BIT(4), false),
-	[RK3288_PD_HEVC]	= DOMAIN_RK3288(BIT(14), BIT(10), BIT(9), false),
-	[RK3288_PD_VIDEO]	= DOMAIN_RK3288(BIT(8),  BIT(8),  BIT(3), false),
-	[RK3288_PD_GPU]		= DOMAIN_RK3288(BIT(9),  BIT(9),  BIT(2), false),
+	[RK3288_PD_VIO]		= DOMAIN_RK3288("vio",   BIT(7),  BIT(7),  BIT(4), false),
+	[RK3288_PD_HEVC]	= DOMAIN_RK3288("hevc",  BIT(14), BIT(10), BIT(9), false),
+	[RK3288_PD_VIDEO]	= DOMAIN_RK3288("video", BIT(8),  BIT(8),  BIT(3), false),
+	[RK3288_PD_GPU]		= DOMAIN_RK3288("gpu",   BIT(9),  BIT(9),  BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3328_pm_domains[] = {
-	[RK3328_PD_CORE]	= DOMAIN_RK3328(0, BIT(0), BIT(0), false),
-	[RK3328_PD_GPU]		= DOMAIN_RK3328(0, BIT(1), BIT(1), false),
-	[RK3328_PD_BUS]		= DOMAIN_RK3328(0, BIT(2), BIT(2), true),
-	[RK3328_PD_MSCH]	= DOMAIN_RK3328(0, BIT(3), BIT(3), true),
-	[RK3328_PD_PERI]	= DOMAIN_RK3328(0, BIT(4), BIT(4), true),
-	[RK3328_PD_VIDEO]	= DOMAIN_RK3328(0, BIT(5), BIT(5), false),
-	[RK3328_PD_HEVC]	= DOMAIN_RK3328(0, BIT(6), BIT(6), false),
-	[RK3328_PD_VIO]		= DOMAIN_RK3328(0, BIT(8), BIT(8), false),
-	[RK3328_PD_VPU]		= DOMAIN_RK3328(0, BIT(9), BIT(9), false),
+	[RK3328_PD_CORE]	= DOMAIN_RK3328("core",  0, BIT(0), BIT(0), false),
+	[RK3328_PD_GPU]		= DOMAIN_RK3328("gpu",   0, BIT(1), BIT(1), false),
+	[RK3328_PD_BUS]		= DOMAIN_RK3328("bus",   0, BIT(2), BIT(2), true),
+	[RK3328_PD_MSCH]	= DOMAIN_RK3328("msch",  0, BIT(3), BIT(3), true),
+	[RK3328_PD_PERI]	= DOMAIN_RK3328("peri",  0, BIT(4), BIT(4), true),
+	[RK3328_PD_VIDEO]	= DOMAIN_RK3328("video", 0, BIT(5), BIT(5), false),
+	[RK3328_PD_HEVC]	= DOMAIN_RK3328("hevc",  0, BIT(6), BIT(6), false),
+	[RK3328_PD_VIO]		= DOMAIN_RK3328("vio",   0, BIT(8), BIT(8), false),
+	[RK3328_PD_VPU]		= DOMAIN_RK3328("vpu",   0, BIT(9), BIT(9), false),
 };
 
 static const struct rockchip_domain_info rk3366_pm_domains[] = {
-	[RK3366_PD_PERI]	= DOMAIN_RK3368(BIT(10), BIT(10), BIT(6), true),
-	[RK3366_PD_VIO]		= DOMAIN_RK3368(BIT(14), BIT(14), BIT(8), false),
-	[RK3366_PD_VIDEO]	= DOMAIN_RK3368(BIT(13), BIT(13), BIT(7), false),
-	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368(BIT(11), BIT(11), BIT(7), false),
-	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368(BIT(8),  BIT(8),  BIT(9), false),
-	[RK3366_PD_VPU]		= DOMAIN_RK3368(BIT(12), BIT(12), BIT(7), false),
-	[RK3366_PD_GPU]		= DOMAIN_RK3368(BIT(15), BIT(15), BIT(2), false),
+	[RK3366_PD_PERI]	= DOMAIN_RK3368("peri",   BIT(10), BIT(10), BIT(6), true),
+	[RK3366_PD_VIO]		= DOMAIN_RK3368("vio",    BIT(14), BIT(14), BIT(8), false),
+	[RK3366_PD_VIDEO]	= DOMAIN_RK3368("video",  BIT(13), BIT(13), BIT(7), false),
+	[RK3366_PD_RKVDEC]	= DOMAIN_RK3368("vdec",   BIT(11), BIT(11), BIT(7), false),
+	[RK3366_PD_WIFIBT]	= DOMAIN_RK3368("wifibt", BIT(8),  BIT(8),  BIT(9), false),
+	[RK3366_PD_VPU]		= DOMAIN_RK3368("vpu",    BIT(12), BIT(12), BIT(7), false),
+	[RK3366_PD_GPU]		= DOMAIN_RK3368("gpu",    BIT(15), BIT(15), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3368_pm_domains[] = {
-	[RK3368_PD_PERI]	= DOMAIN_RK3368(BIT(13), BIT(12), BIT(6), true),
-	[RK3368_PD_VIO]		= DOMAIN_RK3368(BIT(15), BIT(14), BIT(8), false),
-	[RK3368_PD_VIDEO]	= DOMAIN_RK3368(BIT(14), BIT(13), BIT(7), false),
-	[RK3368_PD_GPU_0]	= DOMAIN_RK3368(BIT(16), BIT(15), BIT(2), false),
-	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(BIT(17), BIT(16), BIT(2), false),
+	[RK3368_PD_PERI]	= DOMAIN_RK3368("peri",  BIT(13), BIT(12), BIT(6), true),
+	[RK3368_PD_VIO]		= DOMAIN_RK3368("vio",   BIT(15), BIT(14), BIT(8), false),
+	[RK3368_PD_VIDEO]	= DOMAIN_RK3368("video", BIT(14), BIT(13), BIT(7), false),
+	[RK3368_PD_GPU_0]	= DOMAIN_RK3368("gpu_0", BIT(16), BIT(15), BIT(2), false),
+	[RK3368_PD_GPU_1]	= DOMAIN_RK3368("gpu_1", BIT(17), BIT(16), BIT(2), false),
 };
 
 static const struct rockchip_domain_info rk3399_pm_domains[] = {
-	[RK3399_PD_TCPD0]	= DOMAIN_RK3399(BIT(8),  BIT(8),  0,	   false),
-	[RK3399_PD_TCPD1]	= DOMAIN_RK3399(BIT(9),  BIT(9),  0,	   false),
-	[RK3399_PD_CCI]		= DOMAIN_RK3399(BIT(10), BIT(10), 0,	   true),
-	[RK3399_PD_CCI0]	= DOMAIN_RK3399(0,	 0,	  BIT(15), true),
-	[RK3399_PD_CCI1]	= DOMAIN_RK3399(0,	 0,	  BIT(16), true),
-	[RK3399_PD_PERILP]	= DOMAIN_RK3399(BIT(11), BIT(11), BIT(1),  true),
-	[RK3399_PD_PERIHP]	= DOMAIN_RK3399(BIT(12), BIT(12), BIT(2),  true),
-	[RK3399_PD_CENTER]	= DOMAIN_RK3399(BIT(13), BIT(13), BIT(14), true),
-	[RK3399_PD_VIO]		= DOMAIN_RK3399(BIT(14), BIT(14), BIT(17), false),
-	[RK3399_PD_GPU]		= DOMAIN_RK3399(BIT(15), BIT(15), BIT(0),  false),
-	[RK3399_PD_VCODEC]	= DOMAIN_RK3399(BIT(16), BIT(16), BIT(3),  false),
-	[RK3399_PD_VDU]		= DOMAIN_RK3399(BIT(17), BIT(17), BIT(4),  false),
-	[RK3399_PD_RGA]		= DOMAIN_RK3399(BIT(18), BIT(18), BIT(5),  false),
-	[RK3399_PD_IEP]		= DOMAIN_RK3399(BIT(19), BIT(19), BIT(6),  false),
-	[RK3399_PD_VO]		= DOMAIN_RK3399(BIT(20), BIT(20), 0,	   false),
-	[RK3399_PD_VOPB]	= DOMAIN_RK3399(0,	 0,	  BIT(7),  false),
-	[RK3399_PD_VOPL]	= DOMAIN_RK3399(0, 	 0,	  BIT(8),  false),
-	[RK3399_PD_ISP0]	= DOMAIN_RK3399(BIT(22), BIT(22), BIT(9),  false),
-	[RK3399_PD_ISP1]	= DOMAIN_RK3399(BIT(23), BIT(23), BIT(10), false),
-	[RK3399_PD_HDCP]	= DOMAIN_RK3399(BIT(24), BIT(24), BIT(11), false),
-	[RK3399_PD_GMAC]	= DOMAIN_RK3399(BIT(25), BIT(25), BIT(23), true),
-	[RK3399_PD_EMMC]	= DOMAIN_RK3399(BIT(26), BIT(26), BIT(24), true),
-	[RK3399_PD_USB3]	= DOMAIN_RK3399(BIT(27), BIT(27), BIT(12), true),
-	[RK3399_PD_EDP]		= DOMAIN_RK3399(BIT(28), BIT(28), BIT(22), false),
-	[RK3399_PD_GIC]		= DOMAIN_RK3399(BIT(29), BIT(29), BIT(27), true),
-	[RK3399_PD_SD]		= DOMAIN_RK3399(BIT(30), BIT(30), BIT(28), true),
-	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399(BIT(31), BIT(31), BIT(29), true),
+	[RK3399_PD_TCPD0]	= DOMAIN_RK3399("tcpd0",     BIT(8),  BIT(8),  0,       false),
+	[RK3399_PD_TCPD1]	= DOMAIN_RK3399("tcpd1",     BIT(9),  BIT(9),  0,       false),
+	[RK3399_PD_CCI]		= DOMAIN_RK3399("cci",       BIT(10), BIT(10), 0,       true),
+	[RK3399_PD_CCI0]	= DOMAIN_RK3399("cci0",      0,       0,       BIT(15), true),
+	[RK3399_PD_CCI1]	= DOMAIN_RK3399("cci1",      0,       0,       BIT(16), true),
+	[RK3399_PD_PERILP]	= DOMAIN_RK3399("perilp",    BIT(11), BIT(11), BIT(1),  true),
+	[RK3399_PD_PERIHP]	= DOMAIN_RK3399("perihp",    BIT(12), BIT(12), BIT(2),  true),
+	[RK3399_PD_CENTER]	= DOMAIN_RK3399("center",    BIT(13), BIT(13), BIT(14), true),
+	[RK3399_PD_VIO]		= DOMAIN_RK3399("vio",       BIT(14), BIT(14), BIT(17), false),
+	[RK3399_PD_GPU]		= DOMAIN_RK3399("gpu",       BIT(15), BIT(15), BIT(0),  false),
+	[RK3399_PD_VCODEC]	= DOMAIN_RK3399("vcodec",    BIT(16), BIT(16), BIT(3),  false),
+	[RK3399_PD_VDU]		= DOMAIN_RK3399("vdu",       BIT(17), BIT(17), BIT(4),  false),
+	[RK3399_PD_RGA]		= DOMAIN_RK3399("rga",       BIT(18), BIT(18), BIT(5),  false),
+	[RK3399_PD_IEP]		= DOMAIN_RK3399("iep",       BIT(19), BIT(19), BIT(6),  false),
+	[RK3399_PD_VO]		= DOMAIN_RK3399("vo",        BIT(20), BIT(20), 0,       false),
+	[RK3399_PD_VOPB]	= DOMAIN_RK3399("vopb",      0,       0,       BIT(7),  false),
+	[RK3399_PD_VOPL]	= DOMAIN_RK3399("vopl",      0,       0,       BIT(8),  false),
+	[RK3399_PD_ISP0]	= DOMAIN_RK3399("isp0",      BIT(22), BIT(22), BIT(9),  false),
+	[RK3399_PD_ISP1]	= DOMAIN_RK3399("isp1",      BIT(23), BIT(23), BIT(10), false),
+	[RK3399_PD_HDCP]	= DOMAIN_RK3399("hdcp",      BIT(24), BIT(24), BIT(11), false),
+	[RK3399_PD_GMAC]	= DOMAIN_RK3399("gmac",      BIT(25), BIT(25), BIT(23), true),
+	[RK3399_PD_EMMC]	= DOMAIN_RK3399("emmc",      BIT(26), BIT(26), BIT(24), true),
+	[RK3399_PD_USB3]	= DOMAIN_RK3399("usb3",      BIT(27), BIT(27), BIT(12), true),
+	[RK3399_PD_EDP]		= DOMAIN_RK3399("edp",       BIT(28), BIT(28), BIT(22), false),
+	[RK3399_PD_GIC]		= DOMAIN_RK3399("gic",       BIT(29), BIT(29), BIT(27), true),
+	[RK3399_PD_SD]		= DOMAIN_RK3399("sd",        BIT(30), BIT(30), BIT(28), true),
+	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
 static const struct rockchip_pmu_info px30_pmu = {
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:43 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:43 +0200
Subject: [PATCH v9 06/15] arm64: dts: rockchip: Fix power-controller node
 names for rk3328
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-7-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Use more generic names (as recommended in the device tree specification
or the binding documentation)

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 5bab61784..35df57535 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -300,13 +300,13 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 
-			pd_hevc at RK3328_PD_HEVC {
+			power-domain at RK3328_PD_HEVC {
 				reg = <RK3328_PD_HEVC>;
 			};
-			pd_video at RK3328_PD_VIDEO {
+			power-domain at RK3328_PD_VIDEO {
 				reg = <RK3328_PD_VIDEO>;
 			};
-			pd_vpu at RK3328_PD_VPU {
+			power-domain at RK3328_PD_VPU {
 				reg = <RK3328_PD_VPU>;
 				clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
 			};
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:48 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:48 +0200
Subject: [PATCH v9 11/15] dt-bindings: arm: rockchip: convert pmu.txt to YAML
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-12-jbx6244@gmail.com>

Current dts files with 'pmu' nodes are manually verified.
In order to automate this process pmu.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/rockchip/pmu.txt       | 16 -------
 .../devicetree/bindings/arm/rockchip/pmu.yaml      | 49 ++++++++++++++++++++++
 2 files changed, 49 insertions(+), 16 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.txt
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
deleted file mode 100644
index 3ee9b428b..000000000
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Rockchip power-management-unit:
--------------------------------
-
-The pmu is used to turn off and on different power domains of the SoCs
-This includes the power to the CPU cores.
-
-Required node properties:
-- compatible value : = "rockchip,rk3066-pmu";
-- reg : physical base address and the size of the registers window
-
-Example:
-
-	pmu at 20004000 {
-		compatible = "rockchip,rk3066-pmu";
-		reg = <0x20004000 0x100>;
-	};
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
new file mode 100644
index 000000000..0b816943d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/rockchip/pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Management Unit (PMU)
+
+maintainers:
+  - Elaine Zhang <zhangqing at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |
+  The PMU is used to turn on and off different power domains of the SoCs.
+  This includes the power to the CPU cores.
+
+select:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - rockchip,rk3066-pmu
+
+  required:
+    - compatible
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - rockchip,rk3066-pmu
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: true
+
+examples:
+  - |
+    pmu at 20004000 {
+      compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
+      reg = <0x20004000 0x100>;
+    };
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:49 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:49 +0200
Subject: [PATCH v9 12/15] dt-bindings: arm: rockchip: add more compatible
 strings to pmu.yaml
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-13-jbx6244@gmail.com>

The compatible strings below are already in use in the Rockchip
dtsi files, but were somehow never added to a document, so add

"rockchip,px30-pmu", "syscon", "simple-mfd"
"rockchip,rk3288-pmu", "syscon", "simple-mfd"
"rockchip,rk3328-pmu", "syscon", "simple-mfd"
"rockchip,rk3399-pmu", "syscon", "simple-mfd"

for pmu nodes to pmu.yaml.

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/rockchip/pmu.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
index 0b816943d..678be9011 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.yaml
@@ -19,7 +19,11 @@ select:
     compatible:
       contains:
         enum:
+          - rockchip,px30-pmu
           - rockchip,rk3066-pmu
+          - rockchip,rk3288-pmu
+          - rockchip,rk3328-pmu
+          - rockchip,rk3399-pmu
 
   required:
     - compatible
@@ -28,7 +32,11 @@ properties:
   compatible:
     items:
       - enum:
+          - rockchip,px30-pmu
           - rockchip,rk3066-pmu
+          - rockchip,rk3288-pmu
+          - rockchip,rk3328-pmu
+          - rockchip,rk3399-pmu
       - const: syscon
       - const: simple-mfd
 
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:50 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:50 +0200
Subject: [PATCH v9 13/15] dt-bindings: power: rockchip: Convert to json-schema
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-14-jbx6244@gmail.com>

From: Enric Balletbo i Serra <enric.balletbo at collabora.com>

Convert the soc/rockchip/power_domain.txt binding document to
json-schema and move to the power bindings directory.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Note for rob+dt:
A tag was not added on purpose, because:
  Add "rockchip," prefix to the qos compatible name
  in example.
  Changed maintainers.
  Size reg description is reduced.
  Little style changes '' to ""
  Restyle patternProperties
Please have a look at it again.

For some SoC nodes this patch serie generates notifications
for undocumented "assigned-clocks" and "assigned-clock-parents"
properties till there is consensus of what to do with it.
---
Changed V9:
  Rename definitions to $defs
  Restyle patternProperties
Changed V8:
  Add pd-node ref schema
Changed V7:
  Fix commit message and author format
  Changed SPDX-License-Identifier back to GPL-2.0
  Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
  Fix indent example
Changed V6:
  Changed author
Changed V5:
  Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
  Remove a maintainer
  Changed patternProperties to power-domain
  Add "clocks", "assigned-clocks" and "assigned-clock-parents"
Changed V4:
  Remove new compatible string
  Style changes '' to ""
Changed V3:
  Use Enric's conversion with rk3399 example
Changed V2:
  Convert power_domain.txt to YAML with rk3568 example
---
 .../bindings/power/rockchip,power-controller.yaml  | 246 +++++++++++++++++++++
 .../bindings/soc/rockchip/power_domain.txt         | 136 ------------
 2 files changed, 246 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
new file mode 100644
index 000000000..f71569de9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -0,0 +1,246 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Power Domains
+
+maintainers:
+  - Elaine Zhang <zhangqing at rock-chips.com>
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |
+  Rockchip processors include support for multiple power domains
+  which can be powered up/down by software based on different
+  application scenarios to save power.
+
+  Power domains contained within power-controller node are
+  generic power domain providers documented in
+  Documentation/devicetree/bindings/power/power-domain.yaml.
+
+  IP cores belonging to a power domain should contain a
+  "power-domains" property that is a phandle for the
+  power domain node representing the domain.
+
+properties:
+  $nodename:
+    const: power-controller
+
+  compatible:
+    enum:
+      - rockchip,px30-power-controller
+      - rockchip,rk3036-power-controller
+      - rockchip,rk3066-power-controller
+      - rockchip,rk3128-power-controller
+      - rockchip,rk3188-power-controller
+      - rockchip,rk3228-power-controller
+      - rockchip,rk3288-power-controller
+      - rockchip,rk3328-power-controller
+      - rockchip,rk3366-power-controller
+      - rockchip,rk3368-power-controller
+      - rockchip,rk3399-power-controller
+
+  "#power-domain-cells":
+    const: 1
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+required:
+  - compatible
+  - "#power-domain-cells"
+
+additionalProperties: false
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+
+    $ref: "#/$defs/pd-node"
+
+    unevaluatedProperties: false
+
+    properties:
+      "#address-cells":
+        const: 1
+
+      "#size-cells":
+        const: 0
+
+    patternProperties:
+      "^power-domain@[0-9a-f]+$":
+
+        $ref: "#/$defs/pd-node"
+
+        unevaluatedProperties: false
+
+        properties:
+          "#address-cells":
+            const: 1
+
+          "#size-cells":
+            const: 0
+
+        patternProperties:
+          "^power-domain@[0-9a-f]+$":
+
+            $ref: "#/$defs/pd-node"
+
+            unevaluatedProperties: false
+
+            properties:
+              "#power-domain-cells":
+                const: 0
+
+$defs:
+  pd-node:
+    type: object
+    description: |
+      Represents the power domains within the power controller node.
+
+    properties:
+      reg:
+        maxItems: 1
+        description: |
+          Power domain index. Valid values are defined in
+          "include/dt-bindings/power/px30-power.h"
+          "include/dt-bindings/power/rk3036-power.h"
+          "include/dt-bindings/power/rk3066-power.h"
+          "include/dt-bindings/power/rk3128-power.h"
+          "include/dt-bindings/power/rk3188-power.h"
+          "include/dt-bindings/power/rk3228-power.h"
+          "include/dt-bindings/power/rk3288-power.h"
+          "include/dt-bindings/power/rk3328-power.h"
+          "include/dt-bindings/power/rk3366-power.h"
+          "include/dt-bindings/power/rk3368-power.h"
+          "include/dt-bindings/power/rk3399-power.h"
+
+      clocks:
+        minItems: 1
+        maxItems: 30
+        description: |
+          A number of phandles to clocks that need to be enabled
+          while power domain switches state.
+
+      pm_qos:
+        $ref: /schemas/types.yaml#/definitions/phandle-array
+        description: |
+          A number of phandles to qos blocks which need to be saved and restored
+          while power domain switches state.
+
+      "#power-domain-cells":
+        enum: [0, 1]
+        description:
+          Must be 0 for nodes representing a single PM domain and 1 for nodes
+          providing multiple PM domains.
+
+    required:
+      - reg
+      - "#power-domain-cells"
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3399-cru.h>
+    #include <dt-bindings/power/rk3399-power.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        qos_hdcp: qos at ffa90000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa90000 0x0 0x20>;
+        };
+
+        qos_iep: qos at ffa98000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffa98000 0x0 0x20>;
+        };
+
+        qos_rga_r: qos at ffab0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0000 0x0 0x20>;
+        };
+
+        qos_rga_w: qos at ffab0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab0080 0x0 0x20>;
+        };
+
+        qos_video_m0: qos at ffab8000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffab8000 0x0 0x20>;
+        };
+
+        qos_video_m1_r: qos at ffac0000 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0000 0x0 0x20>;
+        };
+
+        qos_video_m1_w: qos at ffac0080 {
+            compatible = "rockchip,rk3399-qos", "syscon";
+            reg = <0x0 0xffac0080 0x0 0x20>;
+        };
+
+        power-management at ff310000 {
+            compatible = "rockchip,rk3399-pmu", "syscon", "simple-mfd";
+            reg = <0x0 0xff310000 0x0 0x1000>;
+
+            power-controller {
+                compatible = "rockchip,rk3399-power-controller";
+                #power-domain-cells = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                /* These power domains are grouped by VD_CENTER */
+                power-domain at RK3399_PD_IEP {
+                    reg = <RK3399_PD_IEP>;
+                    clocks = <&cru ACLK_IEP>,
+                             <&cru HCLK_IEP>;
+                    pm_qos = <&qos_iep>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_RGA {
+                    reg = <RK3399_PD_RGA>;
+                    clocks = <&cru ACLK_RGA>,
+                             <&cru HCLK_RGA>;
+                    pm_qos = <&qos_rga_r>,
+                             <&qos_rga_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VCODEC {
+                    reg = <RK3399_PD_VCODEC>;
+                    clocks = <&cru ACLK_VCODEC>,
+                             <&cru HCLK_VCODEC>;
+                    pm_qos = <&qos_video_m0>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VDU {
+                    reg = <RK3399_PD_VDU>;
+                    clocks = <&cru ACLK_VDU>,
+                             <&cru HCLK_VDU>;
+                    pm_qos = <&qos_video_m1_r>,
+                             <&qos_video_m1_w>;
+                    #power-domain-cells = <0>;
+                };
+                power-domain at RK3399_PD_VIO {
+                    reg = <RK3399_PD_VIO>;
+                    #power-domain-cells = <1>;
+                    #address-cells = <1>;
+                    #size-cells = <0>;
+
+                    power-domain at RK3399_PD_HDCP {
+                        reg = <RK3399_PD_HDCP>;
+                        clocks = <&cru ACLK_HDCP>,
+                                 <&cru HCLK_HDCP>,
+                                 <&cru PCLK_HDCP>;
+                        pm_qos = <&qos_hdcp>;
+                        #power-domain-cells = <0>;
+                    };
+                };
+            };
+        };
+    };
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
deleted file mode 100644
index 8304eceb6..000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-* Rockchip Power Domains
-
-Rockchip processors include support for multiple power domains which can be
-powered up/down by software based on different application scenes to save power.
-
-Required properties for power domain controller:
-- compatible: Should be one of the following.
-	"rockchip,px30-power-controller" - for PX30 SoCs.
-	"rockchip,rk3036-power-controller" - for RK3036 SoCs.
-	"rockchip,rk3066-power-controller" - for RK3066 SoCs.
-	"rockchip,rk3128-power-controller" - for RK3128 SoCs.
-	"rockchip,rk3188-power-controller" - for RK3188 SoCs.
-	"rockchip,rk3228-power-controller" - for RK3228 SoCs.
-	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
-	"rockchip,rk3328-power-controller" - for RK3328 SoCs.
-	"rockchip,rk3366-power-controller" - for RK3366 SoCs.
-	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
-	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
-- #power-domain-cells: Number of cells in a power-domain specifier.
-	Should be 1 for multiple PM domains.
-- #address-cells: Should be 1.
-- #size-cells: Should be 0.
-
-Required properties for power domain sub nodes:
-- reg: index of the power domain, should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
-	"include/dt-bindings/power/rk3066-power.h" - for RK3066 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
-	"include/dt-bindings/power/rk3188-power.h" - for RK3188 type power domain.
-	"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for RK3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
-- clocks (optional): phandles to clocks which need to be enabled while power domain
-	switches state.
-- pm_qos (optional): phandles to qos blocks which need to be saved and restored
-	while power domain switches state.
-
-Qos Example:
-
-	qos_gpu: qos_gpu at ffaf0000 {
-		compatible ="syscon";
-		reg = <0x0 0xffaf0000 0x0 0x20>;
-	};
-
-Example:
-
-	power: power-controller {
-		compatible = "rockchip,rk3288-power-controller";
-		#power-domain-cells = <1>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		pd_gpu {
-			reg = <RK3288_PD_GPU>;
-			clocks = <&cru ACLK_GPU>;
-			pm_qos = <&qos_gpu>;
-		};
-	};
-
-	 power: power-controller {
-                compatible = "rockchip,rk3368-power-controller";
-                #power-domain-cells = <1>;
-                #address-cells = <1>;
-                #size-cells = <0>;
-
-                pd_gpu_1 {
-                        reg = <RK3368_PD_GPU_1>;
-                        clocks = <&cru ACLK_GPU_CFG>;
-                };
-        };
-
-Example 2:
-		power: power-controller {
-			compatible = "rockchip,rk3399-power-controller";
-			#power-domain-cells = <1>;
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			pd_vio {
-				#address-cells = <1>;
-				#size-cells = <0>;
-				reg = <RK3399_PD_VIO>;
-
-				pd_vo {
-					#address-cells = <1>;
-					#size-cells = <0>;
-					reg = <RK3399_PD_VO>;
-
-					pd_vopb {
-						reg = <RK3399_PD_VOPB>;
-					};
-
-					pd_vopl {
-						reg = <RK3399_PD_VOPL>;
-					};
-				};
-			};
-		};
-
-Node of a device using power domains must have a power-domains property,
-containing a phandle to the power device node and an index specifying which
-power domain to use.
-The index should use macros in:
-	"include/dt-bindings/power/px30-power.h" - for px30 type power domain.
-	"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
-	"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
-	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
-	"include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain.
-	"include/dt-bindings/power/rk3366-power.h" - for rk3366 type power domain.
-	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
-	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
-
-Example of the node using power domain:
-
-	node {
-		/* ... */
-		power-domains = <&power RK3288_PD_GPU>;
-		/* ... */
-	};
-
-	node {
-                /* ... */
-                power-domains = <&power RK3368_PD_GPU_1>;
-                /* ... */
-        };
-
-	node {
-		/* ... */
-		power-domains = <&power RK3399_PD_VOPB>;
-		/* ... */
-	};
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:51 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:51 +0200
Subject: [PATCH v9 14/15] dt-bindings: power: rockchip: Add bindings for
 RK3568 Soc
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-15-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add the compatible string for RK3568 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changed V8:
  Add pd-node ref schema
---
 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
index f71569de9..9b9d71087 100644
--- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -40,6 +40,7 @@ properties:
       - rockchip,rk3366-power-controller
       - rockchip,rk3368-power-controller
       - rockchip,rk3399-power-controller
+      - rockchip,rk3568-power-controller
 
   "#power-domain-cells":
     const: 1
@@ -117,6 +118,7 @@ $defs:
           "include/dt-bindings/power/rk3366-power.h"
           "include/dt-bindings/power/rk3368-power.h"
           "include/dt-bindings/power/rk3399-power.h"
+          "include/dt-bindings/power/rk3568-power.h"
 
       clocks:
         minItems: 1
-- 
2.11.0



From jbx6244 at gmail.com  Sat Apr 17 12:29:52 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Sat, 17 Apr 2021 13:29:52 +0200
Subject: [PATCH v9 15/15] soc: rockchip: power-domain: add rk3568 powerdomains
In-Reply-To: <20210417112952.8516-1-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
Message-ID: <20210417112952.8516-16-jbx6244@gmail.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

Add power-domains found on rk3568 socs.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
Changed V7:
  Fix alignment
---
 drivers/soc/rockchip/pm_domains.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 1d1b06672..0868b7d40 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -27,6 +27,7 @@
 #include <dt-bindings/power/rk3366-power.h>
 #include <dt-bindings/power/rk3368-power.h>
 #include <dt-bindings/power/rk3399-power.h>
+#include <dt-bindings/power/rk3568-power.h>
 
 struct rockchip_domain_info {
 	const char *name;
@@ -135,6 +136,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3399(name, pwr, status, req, wakeup)		\
 	DOMAIN(name, pwr, status, req, req, req, wakeup)
 
+#define DOMAIN_RK3568(name, pwr, req, wakeup)		\
+	DOMAIN_M(name, pwr, pwr, req, req, req, wakeup)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -848,6 +852,18 @@ static const struct rockchip_domain_info rk3399_pm_domains[] = {
 	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399("sdioaudio", BIT(31), BIT(31), BIT(29), true),
 };
 
+static const struct rockchip_domain_info rk3568_pm_domains[] = {
+	[RK3568_PD_NPU]		= DOMAIN_RK3568("npu",  BIT(1), BIT(2),  false),
+	[RK3568_PD_GPU]		= DOMAIN_RK3568("gpu",  BIT(0), BIT(1),  false),
+	[RK3568_PD_VI]		= DOMAIN_RK3568("vi",   BIT(6), BIT(3),  false),
+	[RK3568_PD_VO]		= DOMAIN_RK3568("vo",   BIT(7), BIT(4),  false),
+	[RK3568_PD_RGA]		= DOMAIN_RK3568("rga",  BIT(5), BIT(5),  false),
+	[RK3568_PD_VPU]		= DOMAIN_RK3568("vpu",  BIT(2), BIT(6),  false),
+	[RK3568_PD_RKVDEC]	= DOMAIN_RK3568("vdec", BIT(4), BIT(8),  false),
+	[RK3568_PD_RKVENC]	= DOMAIN_RK3568("venc", BIT(3), BIT(7),  false),
+	[RK3568_PD_PIPE]	= DOMAIN_RK3568("pipe", BIT(8), BIT(11), false),
+};
+
 static const struct rockchip_pmu_info px30_pmu = {
 	.pwr_offset = 0x18,
 	.status_offset = 0x20,
@@ -983,6 +999,17 @@ static const struct rockchip_pmu_info rk3399_pmu = {
 	.domain_info = rk3399_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3568_pmu = {
+	.pwr_offset = 0xa0,
+	.status_offset = 0x98,
+	.req_offset = 0x50,
+	.idle_offset = 0x68,
+	.ack_offset = 0x60,
+
+	.num_domains = ARRAY_SIZE(rk3568_pm_domains),
+	.domain_info = rk3568_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,px30-power-controller",
@@ -1028,6 +1055,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3399-power-controller",
 		.data = (void *)&rk3399_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3568-power-controller",
+		.data = (void *)&rk3568_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
2.11.0



From yuzenghui at huawei.com  Sat Apr 17 12:38:04 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sat, 17 Apr 2021 19:38:04 +0800
Subject: [PATCH] KVM: arm64: Fix Function ID typo for PTP_KVM service
Message-ID: <20210417113804.1992-1-yuzenghui@huawei.com>

Per include/linux/arm-smccc.h, the Function ID of PTP_KVM service is
defined as ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID. Fix the typo in
documentation to keep the git grep consistent.

Signed-off-by: Zenghui Yu <yuzenghui at huawei.com>
---

On branch kvm-arm64/ptp

 Documentation/virt/kvm/arm/ptp_kvm.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/virt/kvm/arm/ptp_kvm.rst b/Documentation/virt/kvm/arm/ptp_kvm.rst
index 5d2bc4558b9d..aecdc80ddcd8 100644
--- a/Documentation/virt/kvm/arm/ptp_kvm.rst
+++ b/Documentation/virt/kvm/arm/ptp_kvm.rst
@@ -7,11 +7,11 @@ PTP_KVM is used for high precision time sync between host and guests.
 It relies on transferring the wall clock and counter value from the
 host to the guest using a KVM-specific hypercall.
 
-* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0x86000001
+* ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: 0x86000001
 
 This hypercall uses the SMC32/HVC32 calling convention:
 
-ARM_SMCCC_HYP_KVM_PTP_FUNC_ID
+ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID
     ==============    ========    =====================================
     Function ID:      (uint32)    0x86000001
     Arguments:        (uint32)    KVM_PTP_VIRT_COUNTER(0)
-- 
2.19.1



From nm at ti.com  Sat Apr 17 13:51:27 2021
From: nm at ti.com (Nishanth Menon)
Date: Sat, 17 Apr 2021 07:51:27 -0500
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema
In-Reply-To: <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-3-nm@ti.com>
 <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>
Message-ID: <20210417125127.vigq23mdoodje6b5@velcro>

On 16:55-20210416, Stephen Boyd wrote:
> Quoting Nishanth Menon (2021-04-15 23:37:19)
> > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > new file mode 100644
> > index 000000000000..72633651f0c7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: TI-SCI clock controller node bindings
> > +
> > +maintainers:
> > +  - Nishanth Menon <nm at ti.com>
> > +
> > +allOf:
> > +  - $ref: /schemas/clock/clock.yaml#
> 
> Is this needed?

https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
This standardizes provider properties like '#clock-cells' etc, allowing
you to add more stricter checks or controls in the future if necessary.

while:

https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
is more a consumer node description.

Should I have picked a different yaml as base for a standard clock-controller
base?

> 
> > +
> > +description: |
> > +  Some TI SoCs contain a system controller (like the Power Management Micro
> > +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > +  the state of the various hardware modules present on the SoC. Communication
> > +  between the host processor running an OS and the system controller happens
> > +  through a protocol called TI System Control Interface (TI-SCI protocol).
> > +
> > +  This clock controller node uses the TI SCI protocol to perform various clock
> > +  management of various hardware modules (devices) present on the SoC. This
> > +  node must be a child node of the associated TI-SCI system controller node.
> > +
> > +properties:
> > +  $nodename:
> > +    pattern: "^clock-controller$"
> 
> Is this nodename pattern check required?

I'd like the definition on rails and not subject to interpretation, and
restrict the kind of subnodes under TISCI controller node.

> 
> > +
> > +  compatible:
> > +    const: ti,k2g-sci-clk
> 
> I thought most things keyed off the compatible string.

Yes, they are. I am not sure I understand your question here. Did you
mean to indicate that having $nodename and compatible both are
redundant?

Redundancy was'nt the intent of this schema definition, rather, I'd like
to make sure that it is not upto interpretation or debate as to what the
node name should be: I believe clock-controller is the correct nodename
(without @0x... since this does'nt use reg property) instead of using
clocks, tisci-clock as the node names.


Do you suggest something  different?

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


From dillon.minfei at gmail.com  Sat Apr 17 14:07:55 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Sat, 17 Apr 2021 21:07:55 +0800
Subject: [PATCH v3] serial: stm32: optimize spin lock usage
In-Reply-To: <YHma7H3RoLyeH650@hovoldconsulting.com>
References: <1618567841-18546-1-git-send-email-dillon.minfei@gmail.com>
 <YHma7H3RoLyeH650@hovoldconsulting.com>
Message-ID: <CAL9mu0Kxny5JOGDk67ByMCVAJFOCF44rEOjbt68VxHz_2gZHrg@mail.gmail.com>

Hi Johan,

On Fri, Apr 16, 2021 at 10:10 PM Johan Hovold <johan at kernel.org> wrote:
>
> On Fri, Apr 16, 2021 at 06:10:41PM +0800, dillon.minfei at gmail.com wrote:
> > From: dillon min <dillon.minfei at gmail.com>
> >
> > This patch aims to fix two potential bug:
> > - no lock to protect uart register in this case
> >
> >   stm32_usart_threaded_interrupt()
> >      spin_lock(&port->lock);
> >      ...
> >      stm32_usart_receive_chars()
> >        uart_handle_sysrq_char();
> >        sysrq_function();
> >        printk();
> >          stm32_usart_console_write();
> >            locked = 0; //since port->sysrq is not zero,
> >                          no lock to protect forward register
> >                          access.
> >
> > - if add spin_trylock_irqsave() to protect uart register for sysrq = 1 case,
> >   that might got recursive locking under UP.
> >   So, use uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq()
> >   move sysrq handler position to irq/thread_d handler, just record
> >   sysrq_ch in stm32_usart_receive_chars() by uart_prepare_sysrq_char()
> >   delay the sysrq process to next interrupt handler.
> >
> >   new flow:
> >
> >   stm32_usart_threaded_interrupt()/stm32_usart_interrupt()
> >   spin_lock_irqsave(&port->lock);
> >   ...
> >   uart_unlock_and_check_sysrq();
> >      spin_unlock_irqrestore();
> >      handle_sysrq(sysrq_ch);
> >   stm32_usart_threaded_interrupt()//stm32_usart_interrupt() return
> >
> > Cc: Johan Hovold <johan at kernel.org>
> > Cc: Alexandre Torgue <alexandre.torgue at foss.st.com>
> > Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> > Cc: Gerald Baeza <gerald.baeza at foss.st.com>
> > Cc: Erwan Le Ray <erwan.leray at foss.st.com>
> > Reported-by: kernel test robot <lkp at intel.com>
> > Signed-off-by: dillon min <dillon.minfei at gmail.com>
> > ---
> > v3: add uart_prepare_sysrq_char(), uart_unlock_and_check_sysrq() to move
> >     sysrq handler inside interrupt routinei to avoid recursive locking,
> >     according to Johan Hovold suggestion, thanks.
> >
> >  drivers/tty/serial/stm32-usart.c | 24 +++++++++++-------------
> >  1 file changed, 11 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
> > index b3675cf25a69..981f50ec784e 100644
> > --- a/drivers/tty/serial/stm32-usart.c
> > +++ b/drivers/tty/serial/stm32-usart.c
> > @@ -271,7 +271,7 @@ static void stm32_usart_receive_chars(struct uart_port *port, bool threaded)
> >                       }
> >               }
> >
> > -             if (uart_handle_sysrq_char(port, c))
> > +             if (uart_prepare_sysrq_char(port, c))
> >                       continue;
> >               uart_insert_char(port, sr, USART_SR_ORE, c, flag);
> >       }
> > @@ -457,9 +457,10 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
> >       struct uart_port *port = ptr;
> >       struct stm32_port *stm32_port = to_stm32_port(port);
> >       const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
> > +     unsigned long flags;
> >       u32 sr;
> >
> > -     spin_lock(&port->lock);
> > +     spin_lock_irqsave(&port->lock, flags);
> >
> >       sr = readl_relaxed(port->membase + ofs->isr);
> >
> > @@ -477,7 +478,7 @@ static irqreturn_t stm32_usart_interrupt(int irq, void *ptr)
> >       if ((sr & USART_SR_TXE) && !(stm32_port->tx_ch))
> >               stm32_usart_transmit_chars(port);
> >
> > -     spin_unlock(&port->lock);
> > +     uart_unlock_and_check_sysrq(port, flags);
> >
> >       if (stm32_port->rx_ch)
> >               return IRQ_WAKE_THREAD;
> > @@ -489,13 +490,14 @@ static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
> >  {
> >       struct uart_port *port = ptr;
> >       struct stm32_port *stm32_port = to_stm32_port(port);
> > +     unsigned long flags;
> >
> > -     spin_lock(&port->lock);
> > +     spin_lock_irqsave(&port->lock, flags);
>
> This essentially turns the threaded handler into a non-threaded one,
> which is a bad idea.
This change is only to adapt for uart_unlock_and_check_sysrq() need flags.
Found your patch has removed this parameter from
uart_unlock_and_check_sysrq(), so this changes should be removed.

>
> >       if (stm32_port->rx_ch)
> >               stm32_usart_receive_chars(port, true);
> >
> > -     spin_unlock(&port->lock);
> > +     uart_unlock_and_check_sysrq(port, flags);
> >
> >       return IRQ_HANDLED;
> >  }
>
> You also didn't base this patch on tty-next, which has a number of
> updates to this driver. Before noting that myself, I had fixed a couple
> of deadlocks in this driver which turned out to have been incidentally
> fixed by an unrelated path in -next.
Yes, my submission is based on linux-5.12. based on the component's
next branch is a good idea , to avoid conflict. thanks.
>
> I'll be posting a series that should fix up all of this.
Thanks
>
> Johan


From David.Laight at ACULAB.COM  Sat Apr 17 14:08:30 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 17 Apr 2021 13:08:30 +0000
Subject: Bogus struct page layout on 32-bit
In-Reply-To: <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
References: <20210409185105.188284-3-willy@infradead.org>
 <202104100656.N7EVvkNZ-lkp@intel.com>
 <20210410024313.GX2531743@casper.infradead.org>
 <20210410082158.79ad09a6@carbon>
 <CAC_iWjLXZ6-hhvmvee6r4R_N64u-hrnLqE_CSS1nQk+YaMQQnA@mail.gmail.com>
 <ab9f1a6c-4099-2b59-457d-fcc45d2396f4@ti.com>
Message-ID: <e8247c8d079d45928990031870db7a9e@AcuMS.aculab.com>

From: Grygorii Strashko
> Sent: 16 April 2021 10:27
...
> Sry, for delayed reply.
> 
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA even in case of LPAE
> (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected for the LPAE case
> on TI platforms and the fact that it became set is the result of multi-paltform/allXXXconfig/DMA
> optimizations and unification.
> (just checked - not set in 4.14)
> 
> Probable commit 4965a68780c5 ("arch: define the ARCH_DMA_ADDR_T_64BIT config symbol in lib/Kconfig").
> 
> The TI drivers have been updated, finally to accept ARCH_DMA_ADDR_T_64BIT=y by using things like
> (__force u32)
> for example.

Hmmm using (__force u32) is probably wrong.
If an address +length >= 2**32 can get passed then the IO request
needs to be errored (or a bounce buffer used).

Otherwise you can get particularly horrid corruptions.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From David.Laight at ACULAB.COM  Sat Apr 17 14:19:02 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 17 Apr 2021 13:19:02 +0000
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210416133431.GA2303@C02TD0UTHF1T.local>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com> <20210416133431.GA2303@C02TD0UTHF1T.local>
Message-ID: <ba281040abc146fca5a2117d5476aa1b@AcuMS.aculab.com>

From: Mark Rutland
> Sent: 16 April 2021 14:35
..
> @@ -51,13 +48,7 @@ static inline void syscall_set_return_value(struct task_struct *task,
>  					    struct pt_regs *regs,
>  					    int error, long val)
>  {
> -	if (error)
> -		val = error;
> -
> -	if (is_compat_thread(task_thread_info(task)))
> -		val = lower_32_bits(val);
> -
> -	regs->regs[0] = val;
> +	regs->regs[0] = (long) error ? error : val;

	= error ? (long)error : rval;

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From alexander.shishkin at linux.intel.com  Sat Apr 17 14:56:35 2021
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Sat, 17 Apr 2021 16:56:35 +0300
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and
 Trace device
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com>

Yicong Yang <yangyicong at hisilicon.com> writes:

> The reason for not using perf is because there is no current support
> for uncore tracing in the perf facilities.

Not unless you count

$ perf list|grep -ic uncore
77

> We have our own format
> of data and don't need perf doing the parsing.

Perf has AUX buffers, which are used for all kinds of own formats.

> A similar approach for implementing this function is ETM, which use
> sysfs for configuring and a character device for dumping data.

And also perf. One reason ETM has a sysfs interface is because the
driver predates perf's AUX buffers. Can't say if it's the only
reason. I'm assuming you're talking about Coresight ETM.

> Greg has some comments on our implementation and doesn't advocate
> to build driver on debugfs [1]. So I resend this series to
> collect more feedbacks on the implementation of this driver.
>
> Hi perf and ETM related experts, is it suggested to adapt this driver
> to perf? Or is the debugfs approach acceptable? Otherwise use

Aside from the above, I don't think the use of debugfs for kernel ABIs
is ever encouraged.

Regards,
--
Ale


From willy at infradead.org  Sat Apr 17 14:56:42 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 14:56:42 +0100
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAK8P3a2dekzohOrHpLq6yyuaoyC4UOxxucu6kX2oddeq5Jdqfg@mail.gmail.com>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
 <CAK8P3a2dekzohOrHpLq6yyuaoyC4UOxxucu6kX2oddeq5Jdqfg@mail.gmail.com>
Message-ID: <20210417135642.GR2531743@casper.infradead.org>

On Sat, Apr 17, 2021 at 12:31:37PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 16, 2021 at 5:27 PM Matthew Wilcox <willy at infradead.org> wrote:
> > diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> > index b5b195305346..db7c7020746a 100644
> > --- a/include/net/page_pool.h
> > +++ b/include/net/page_pool.h
> > @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
> >
> >  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> >  {
> > -       return page->dma_addr;
> > +       dma_addr_t ret = page->dma_addr[0];
> > +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > +               ret |= (dma_addr_t)page->dma_addr[1] << 32;
> > +       return ret;
> > +}
> 
> Have you considered using a PFN type address here? I suspect you
> can prove that shifting the DMA address by PAGE_BITS would
> make it fit into an 'unsigned long' on all 32-bit architectures with
> 64-bit dma_addr_t. This requires that page->dma_addr to be
> page aligned, as well as fit into 44 bits. I recently went through the
> maximum address space per architecture to define a
> MAX_POSSIBLE_PHYSMEM_BITS, and none of them have more than
> 40 here, presumably the same is true for dma address space.

I wouldn't like to make that assumption.  I've come across IOMMUs (maybe
on parisc?  powerpc?) that like to encode fun information in the top
few bits.  So we could get it down to 52 bits, but I don't think we can
get all the way down to 32 bits.  Also, we need to keep the bottom bit
clear for PageTail, so that further constrains us.

Anyway, I like the "two unsigned longs" approach I posted yesterday,
but thanks for the suggestion.


From pali at kernel.org  Sat Apr 17 15:49:53 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Sat, 17 Apr 2021 16:49:53 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali>
 <20210415104537.403de52e@thinkpad>
 <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
Message-ID: <20210417144953.pznysgn5rdraxggx@pali>

On Thursday 15 April 2021 10:13:17 Rob Herring wrote:
> On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun at nic.cz> wrote:
> >
> > On Thu, 15 Apr 2021 10:36:40 +0200
> > Pali Roh?r <pali at kernel.org> wrote:
> >
> > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > > On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
> > > > >
> > > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > > > function and allow to build it as module") PCIe controller driver for
> > > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > > > > allows dynamic binding and unbinding of PCIe controller device.
> > > > >
> > > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > > > number (starting from zero) for this PCIe controller every time when device
> > > > > is bound. So PCI domain changes after every unbind / bind operation.
> > > >
> > > > PCI host bridges as a module are relatively new, so seems likely a bug to me.
> > >
> > > Why a bug? It is there since 5.10 and it is working.
> 
> I mean historically, the PCI subsystem didn't even support host
> bridges as a module. They weren't even proper drivers and it was all
> arch specific code. Most of the host bridge drivers are still built-in
> only. This seems like a small detail that was easily overlooked.
> unbind is not a well tested path.

Ok! Just to note that during my testing I have not spotted any issue.

> > > > > Alternative way for assigning PCI domain number is to use static allocated
> > > > > numbers defined in Device Tree. This option has requirement that every PCI
> > > > > controller in system must have defined PCI bus number in Device Tree.
> > > >
> > > > That seems entirely pointless from a DT point of view with a single PCI bridge.
> > >
> > > If domain id is not specified in DT then kernel uses counter and assigns
> > > counter++. So it is not pointless if we want to have stable domain id.
> >
> > What Rob is trying to say is that
> > - the bug is that kernel assigns counter++
> > - device-tree should not be used to fix problems with how kernel does
> >   things
> > - if a device has only one PCIe controller, it is pointless to define
> >   it's pci-domain. If there were multiple controllers, then it would
> >   make sense, but there is only one
> 
> Yes. I think what we want here is a domain bitmap rather than a
> counter and we assign the lowest free bit. That could also allow for
> handling a mixture of fixed domain numbers and dynamically assigned
> ones.

Currently this code is implemented in pci_bus_find_domain_nr() function.
IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
of memory. I'm not sure if it is fine or some other tree-based structure
for allocated domain numbers is needed.

> You could create scenarios where the numbers change on you, but it
> wouldn't be any different than say plugging in USB serial adapters.
> You get the same ttyUSBx device when you re-attach unless there's been
> other ttyUSBx devices attached/detached.

This should be fine for most scenarios. Dynamically attaching /
detaching PCI domain is not such common action...

Will you implement this new feature?


From andrew at lunn.ch  Sat Apr 17 16:19:38 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 17 Apr 2021 17:19:38 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <20210417144953.pznysgn5rdraxggx@pali>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali>
 <20210415104537.403de52e@thinkpad>
 <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
 <20210417144953.pznysgn5rdraxggx@pali>
Message-ID: <YHr8ikD+zoT2/K3W@lunn.ch>

> Currently this code is implemented in pci_bus_find_domain_nr() function.
> IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> of memory. I'm not sure if it is fine or some other tree-based structure
> for allocated domain numbers is needed.

Hi Pali

Have a look at lib/idr.c

     Andrew


From u.kleine-koenig at pengutronix.de  Sat Apr 17 16:50:09 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sat, 17 Apr 2021 17:50:09 +0200
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210416121523.c34trzsrlcjuzirl@toshiba.co.jp>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
 <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
 <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>
 <20210416094426.x4gyw3drp2fcwczs@pengutronix.de>
 <20210416121523.c34trzsrlcjuzirl@toshiba.co.jp>
Message-ID: <20210417155009.vnqxx3fn2yjzp3qc@pengutronix.de>

Hello Nobuhiro,

On Fri, Apr 16, 2021 at 09:15:23PM +0900, Nobuhiro Iwamatsu wrote:
> > > > For me the critical (and only) difference between "off" and
> > > > "duty cycle = 0" is that when a new configuration is to be applied. In
> > > > the "off" state a new period can (and should) start immediately, while
> > > > with "duty_cycle = 0" the rising edge should be delayed until the
> > > > currently running period is over.[1]
> > > > 
> > > > So the thing to do here (IMHO) is:
> > > > 
> > > > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
> > > > with writing a non-zero value to PIPGM_PCSR) completes the currently
> > > > running period, then always assume the PWM as enabled.
> > > 
> > > Yes, this device works that way.
> > 
> > OK, then please use
> > 
> > 	state->enabled = true
> > 
> > unconditionally in visconti_pwm_get_state().
> 
> Please let me check.
> If I unconditionally add 'state->enabled = true' to visconti_pwm_get_state(),
> state->enabled is set to true because visconti_pwm_get_state() is called when
> the device is created (this is when I write the device number to the export of
> /sys/class/pwm/pwmchip0 ).
> And since PIPGM_PCSR is 0 in this state, the pulse by PWM is not output.

A PWM that is currently configured with .enabled = true and .duty_cycle
= 0 doesn't have a pulse, so this is fine.

> However, I think this means that the device is working as this driver.

I don't understand this sentence.

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/20210417/e397ef11/attachment.sig>

From arnd at kernel.org  Sat Apr 17 18:30:21 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sat, 17 Apr 2021 19:30:21 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417135642.GR2531743@casper.infradead.org>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
 <CAK8P3a2dekzohOrHpLq6yyuaoyC4UOxxucu6kX2oddeq5Jdqfg@mail.gmail.com>
 <20210417135642.GR2531743@casper.infradead.org>
Message-ID: <CAK8P3a2M1fk-CAAjpLSNsobpOKKiHt_ffoKUNv3aqfie09d_PQ@mail.gmail.com>

On Sat, Apr 17, 2021 at 3:58 PM Matthew Wilcox <willy at infradead.org> wrote:
> I wouldn't like to make that assumption.  I've come across IOMMUs (maybe
> on parisc?  powerpc?) that like to encode fun information in the top
> few bits.  So we could get it down to 52 bits, but I don't think we can
> get all the way down to 32 bits.  Also, we need to keep the bottom bit
> clear for PageTail, so that further constrains us.

I'd be surprised to find such an IOMMU on a 32-bit machine, given that
the main reason for using an IOMMU on these is to avoid the 32-bit
address limit in DMA masters.

I see that parisc32 does not enable 64-bit dma_addr_t, while powerpc32
does not support any IOMMU, so it wouldn't be either of those two.

I do remember some powerpc systems that encode additional flags
(transaction ordering, caching, ...) into the high bits of the physical
address in the IOTLB, but not the virtual address used for looking
them up.

> Anyway, I like the "two unsigned longs" approach I posted yesterday,
> but thanks for the suggestion.

Ok, fair enough. As long as there are enough bits in this branch of
'struct page', I suppose it is the safe choice.

        Arnd


From drv at mailo.com  Sat Apr 17 19:02:22 2021
From: drv at mailo.com (Deepak R Varma)
Date: Sat, 17 Apr 2021 23:32:22 +0530
Subject: [PATCH 3/3] gpio: zynq: Check return value of irq_get_irq_data
In-Reply-To: <20210409140806.31824-4-srinivas.neeli@xilinx.com>
References: <20210409140806.31824-1-srinivas.neeli@xilinx.com>
 <20210409140806.31824-4-srinivas.neeli@xilinx.com>
Message-ID: <20210417180222.GA112239@localhost>

On Fri, Apr 09, 2021 at 07:38:06PM +0530, Srinivas Neeli wrote:
> In two different instances the return value of "irq_get_irq_data"
> API was neither captured nor checked.
> Fixed it by capturing the return value and then checking for any error.
> 
> Addresses-Coverity: "returned_null"
> Signed-off-by: Srinivas Neeli <srinivas.neeli at xilinx.com>
> ---
>  drivers/gpio/gpio-zynq.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-zynq.c b/drivers/gpio/gpio-zynq.c
> index c91302a16c77..f0cb8ccd03ed 100644
> --- a/drivers/gpio/gpio-zynq.c
> +++ b/drivers/gpio/gpio-zynq.c
> @@ -736,6 +736,11 @@ static int __maybe_unused zynq_gpio_suspend(struct device *dev)
>  	struct zynq_gpio *gpio = dev_get_drvdata(dev);
>  	struct irq_data *data = irq_get_irq_data(gpio->irq);
>  
> +	if (!data) {
> +		dev_err(dev, "irq_get_irq_data() failed\n");

It will be useful to include a tag such as "suspend: " in the error
message to uniquely identify where it failed from.

> +		return -EINVAL;
> +	}
> +
>  	if (!device_may_wakeup(dev))
>  		disable_irq(gpio->irq);
>  
> @@ -753,6 +758,11 @@ static int __maybe_unused zynq_gpio_resume(struct device *dev)
>  	struct irq_data *data = irq_get_irq_data(gpio->irq);
>  	int ret;
>  
> +	if (!data) {
> +		dev_err(dev, "irq_get_irq_data() failed\n");

Ditto. Suggest using "resume: " tag here.

> +		return -EINVAL;
> +	}
> +
>  	if (!device_may_wakeup(dev))
>  		enable_irq(gpio->irq);
>  
> -- 
> 2.9.1
> 




From ilias.apalodimas at linaro.org  Sat Apr 17 19:32:06 2021
From: ilias.apalodimas at linaro.org (Ilias Apalodimas)
Date: Sat, 17 Apr 2021 21:32:06 +0300
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417024522.GP2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
Message-ID: <YHspptFx+T588KcG@apalos.home>

Hi Matthew,

On Sat, Apr 17, 2021 at 03:45:22AM +0100, Matthew Wilcox wrote:
> 
> Replacement patch to fix compiler warning.
> 
> From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: brouer at redhat.com
> Cc: linux-kernel at vger.kernel.org,
>     linux-mm at kvack.org,
>     netdev at vger.kernel.org,
>     linuxppc-dev at lists.ozlabs.org,
>     linux-arm-kernel at lists.infradead.org,
>     linux-mips at vger.kernel.org,
>     ilias.apalodimas at linaro.org,
>     mcroce at linux.microsoft.com,
>     grygorii.strashko at ti.com,
>     arnd at kernel.org,
>     hch at lst.de,
>     linux-snps-arc at lists.infradead.org,
>     mhocko at kernel.org,
>     mgorman at suse.de
> 
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
> 
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
> 
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>  include/linux/mm_types.h |  4 ++--
>  include/net/page_pool.h  | 12 +++++++++++-
>  net/core/page_pool.c     | 12 +++++++-----
>  3 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>  		};
>  		struct {	/* page_pool used by netstack */
>  			/**
> -			 * @dma_addr: might require a 64-bit value even on
> +			 * @dma_addr: might require a 64-bit value on
>  			 * 32-bit architectures.
>  			 */
> -			dma_addr_t dma_addr;
> +			unsigned long dma_addr[2];
>  		};
>  		struct {	/* slab, slob and slub */
>  			union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>  
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> +	return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +	page->dma_addr[0] = addr;
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		page->dma_addr[1] = addr >> 16 >> 16;


The 'error' that was reported will never trigger right?
I assume this was compiled with dma_addr_t as 32bits (so it triggered the
compilation error), but the if check will never allow this codepath to run.
If so can we add a comment explaining this, since none of us will remember why
in 6 months from now?

>  }
>  
>  static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
>  					  struct page *page,
>  					  unsigned int dma_sync_size)
>  {
> +	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
>  	dma_sync_size = min(dma_sync_size, pool->p.max_len);
> -	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> +	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>  					 pool->p.offset, dma_sync_size,
>  					 pool->p.dma_dir);
>  }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
>  		put_page(page);
>  		return NULL;
>  	}
> -	page->dma_addr = dma;
> +	page_pool_set_dma_addr(page, dma);
>  
>  	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
>  		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
>  		 */
>  		goto skip_dma_unmap;
>  
> -	dma = page->dma_addr;
> +	dma = page_pool_get_dma_addr(page);
>  
> -	/* When page is unmapped, it cannot be returned our pool */
> +	/* When page is unmapped, it cannot be returned to our pool */
>  	dma_unmap_page_attrs(pool->p.dev, dma,
>  			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
>  			     DMA_ATTR_SKIP_CPU_SYNC);
> -	page->dma_addr = 0;
> +	page_pool_set_dma_addr(page, 0);
>  skip_dma_unmap:
>  	/* This may be the last page returned, releasing the pool, so
>  	 * it is not safe to reference pool afterwards.
> -- 
> 2.30.2
> 

Thanks
/Ilias


From pali at kernel.org  Sat Apr 17 20:42:41 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Sat, 17 Apr 2021 21:42:41 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <YHr8ikD+zoT2/K3W@lunn.ch>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali>
 <20210415104537.403de52e@thinkpad>
 <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
 <20210417144953.pznysgn5rdraxggx@pali> <YHr8ikD+zoT2/K3W@lunn.ch>
Message-ID: <20210417194241.zobxpau3ejwzhzbj@pali>

On Saturday 17 April 2021 17:19:38 Andrew Lunn wrote:
> > Currently this code is implemented in pci_bus_find_domain_nr() function.
> > IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> > of memory. I'm not sure if it is fine or some other tree-based structure
> > for allocated domain numbers is needed.
> 
> Hi Pali
> 
> Have a look at lib/idr.c
> 
>      Andrew

Great! So number allocation is already implemented in kernel (via radix trees).


From wsa at the-dreams.de  Sat Apr 17 21:06:51 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Sat, 17 Apr 2021 22:06:51 +0200
Subject: [PATCH 1/3] i2c: mediatek: Fix send master code at more than 1MHz
In-Reply-To: <1618642012-10444-2-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
 <1618642012-10444-2-git-send-email-qii.wang@mediatek.com>
Message-ID: <20210417200651.GB9996@kunai>

On Sat, Apr 17, 2021 at 02:46:50PM +0800, Qii Wang wrote:
> There are some omissions in the previous patch about replacing
> I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and
> need to fix it.
> 
> Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz")
> Signed-off-by: Qii Wang <qii.wang at mediatek.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/20210417/8065e688/attachment.sig>

From wsa at the-dreams.de  Sat Apr 17 21:07:06 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Sat, 17 Apr 2021 22:07:06 +0200
Subject: [PATCH 2/3] i2c: mediatek: Fix wrong dma sync flag
In-Reply-To: <1618642012-10444-3-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
 <1618642012-10444-3-git-send-email-qii.wang@mediatek.com>
Message-ID: <20210417200706.GC9996@kunai>

On Sat, Apr 17, 2021 at 02:46:51PM +0800, Qii Wang wrote:
> The right flag is apdma_sync when apdma remove hand-shake signel.
> 
> Signed-off-by: Qii Wang <qii.wang at mediatek.com>

Added:

Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout")

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/20210417/b1adce9f/attachment.sig>

From wsa at the-dreams.de  Sat Apr 17 21:09:23 2021
From: wsa at the-dreams.de (Wolfram Sang)
Date: Sat, 17 Apr 2021 22:09:23 +0200
Subject: [PATCH 3/3] i2c: mediatek: Use scl_int_delay_ns to compensate
 clock-stretching
In-Reply-To: <1618642012-10444-4-git-send-email-qii.wang@mediatek.com>
References: <1618642012-10444-1-git-send-email-qii.wang@mediatek.com>
 <1618642012-10444-4-git-send-email-qii.wang@mediatek.com>
Message-ID: <20210417200923.GD9996@kunai>

On Sat, Apr 17, 2021 at 02:46:52PM +0800, Qii Wang wrote:
> The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due
> to device clock-stretch or circuit loss, we could get a suitable
> scl_int_delay_ns from i2c_timings to compensate these parameters
> to meet the spec via EXT_CONF register.
> 
> Signed-off-by: Qii Wang <qii.wang at mediatek.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/20210417/44ce0c82/attachment.sig>

From willy at infradead.org  Sat Apr 17 21:22:40 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 21:22:40 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <YHspptFx+T588KcG@apalos.home>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <YHspptFx+T588KcG@apalos.home>
Message-ID: <20210417202240.GS2531743@casper.infradead.org>

On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> > +{
> > +	page->dma_addr[0] = addr;
> > +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > +		page->dma_addr[1] = addr >> 16 >> 16;
> 
> The 'error' that was reported will never trigger right?
> I assume this was compiled with dma_addr_t as 32bits (so it triggered the
> compilation error), but the if check will never allow this codepath to run.
> If so can we add a comment explaining this, since none of us will remember why
> in 6 months from now?

That's right.  I compiled it all three ways -- 32-bit, 64-bit dma, 32-bit long
and 64-bit.  The 32/64 bit case turn into:

	if (0)
		page->dma_addr[1] = addr >> 16 >> 16;

which gets elided.  So the only case that has to work is 64-bit dma and
32-bit long.

I can replace this with upper_32_bits().



From David.Laight at ACULAB.COM  Sat Apr 17 22:13:45 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 17 Apr 2021 21:13:45 +0000
Subject: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
In-Reply-To: <20210416230724.2519198-3-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-3-willy@infradead.org>
Message-ID: <2a531a42f23e4046833e0feb8faef0b5@AcuMS.aculab.com>

From: Matthew Wilcox (Oracle) <willy at infradead.org>
> Sent: 17 April 2021 00:07
> 
> The net page_pool wants to use a magic value to identify page pool pages.
> The best place to put it is in the first word where it can be clearly a
> non-pointer value.  That means shifting dma_addr up to alias with ->index,
> which means we need to find another way to indicate page_is_pfmemalloc().
> Since page_pool doesn't want to set its magic value on pages which are
> pfmemalloc, we can use bit 1 of compound_head to indicate that the page
> came from the memory reserves.
> 
...
>  		struct {	/* page_pool used by netstack */
> -			/**
> -			 * @dma_addr: might require a 64-bit value on
> -			 * 32-bit architectures.
> -			 */
> +			unsigned long pp_magic;
> +			unsigned long xmi;
> +			unsigned long _pp_mapping_pad;
>  			unsigned long dma_addr[2];
>  		};

You've deleted the comment.

I also think there should be a comment that dma_addr[0]
must be aliased to ->index.
(Or whatever all the exact requirements are.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From David.Laight at ACULAB.COM  Sat Apr 17 22:18:57 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Sat, 17 Apr 2021 21:18:57 +0000
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417024522.GP2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
Message-ID: <386d009232dc42bdaf83d4cc36b13864@AcuMS.aculab.com>

From: Matthew Wilcox <willy at infradead.org>
> Sent: 17 April 2021 03:45
> 
> Replacement patch to fix compiler warning.
...
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;

Ugly as well.

Why not just replace the (dma_addr_t) cast with a (u64) one?
Looks better than the double shift.

Same could be done for the '>> 32'.
Is there an upper_32_bits() that could be used??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From willy at infradead.org  Sat Apr 17 22:28:43 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 22:28:43 +0100
Subject: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
In-Reply-To: <2a531a42f23e4046833e0feb8faef0b5@AcuMS.aculab.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-3-willy@infradead.org>
 <2a531a42f23e4046833e0feb8faef0b5@AcuMS.aculab.com>
Message-ID: <20210417212843.GT2531743@casper.infradead.org>

On Sat, Apr 17, 2021 at 09:13:45PM +0000, David Laight wrote:
> >  		struct {	/* page_pool used by netstack */
> > -			/**
> > -			 * @dma_addr: might require a 64-bit value on
> > -			 * 32-bit architectures.
> > -			 */
> > +			unsigned long pp_magic;
> > +			unsigned long xmi;
> > +			unsigned long _pp_mapping_pad;
> >  			unsigned long dma_addr[2];
> >  		};
> 
> You've deleted the comment.

Yes.  It no longer added any value.  You can see dma_addr now occupies
two words.

> I also think there should be a comment that dma_addr[0]
> must be aliased to ->index.

That's not a requirement.  Moving the pfmemalloc indicator is a
requirement so that we _can_ use index, but there's no requirement about
how index is used.


From willy at infradead.org  Sat Apr 17 23:45:23 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Sat, 17 Apr 2021 23:45:23 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <386d009232dc42bdaf83d4cc36b13864@AcuMS.aculab.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <386d009232dc42bdaf83d4cc36b13864@AcuMS.aculab.com>
Message-ID: <20210417224523.GU2531743@casper.infradead.org>

On Sat, Apr 17, 2021 at 09:18:57PM +0000, David Laight wrote:
> Ugly as well.

Thank you for expressing your opinion.  Again.


From lkp at intel.com  Sat Apr 17 23:49:28 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 06:49:28 +0800
Subject: [nomadik:ux500-href-dts-fixups 30/30] init/initramfs.c:672:3:
 warning: cast from pointer to integer of different size
Message-ID: <202104180627.4W8fw2Am-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
head:   3f62443c165ea1c988d9b0855292785a28906698
commit: 3f62443c165ea1c988d9b0855292785a28906698 [30/30] hacks
config: mips-bigsur_defconfig (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=3f62443c165ea1c988d9b0855292785a28906698
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ux500-href-dts-fixups
        git checkout 3f62443c165ea1c988d9b0855292785a28906698
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:16,
                    from include/linux/list.h:9,
                    from include/linux/wait.h:7,
                    from include/linux/wait_bit.h:8,
                    from include/linux/fs.h:6,
                    from init/initramfs.c:3:
   init/initramfs.c: In function 'populate_rootfs':
>> init/initramfs.c:672:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     672 |   (unsigned int)__initramfs_start,
         |   ^
   include/linux/printk.h:373:34: note: in definition of macro 'pr_info'
     373 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
         |                                  ^~~~~~~~~~~
   init/initramfs.c:675:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
     675 |  char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
         |  ^~~~


vim +672 init/initramfs.c

   667	
   668	static int __init populate_rootfs(void)
   669	{
   670		pr_info("%s enter __initramfs_start = %08x, __initramfs_size = %08x\n",
   671			__func__,
 > 672			(unsigned int)__initramfs_start,

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 16780 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/6908c9ab/attachment-0001.gz>

From lkp at intel.com  Sun Apr 18 00:05:09 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 07:05:09 +0800
Subject: [nomadik:ux500-href-dts-fixups 30/30] init/initramfs.c:675:8:
 warning: ISO C90 forbids mixing declarations and code
Message-ID: <202104180702.QwjANdJc-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
head:   3f62443c165ea1c988d9b0855292785a28906698
commit: 3f62443c165ea1c988d9b0855292785a28906698 [30/30] hacks
config: mips-randconfig-r024-20210418 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f549176ad976caa3e19edd036df9a7e12770af7c)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install mips cross compiling tool for clang build
        # apt-get install binutils-mips-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=3f62443c165ea1c988d9b0855292785a28906698
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ux500-href-dts-fixups
        git checkout 3f62443c165ea1c988d9b0855292785a28906698
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> init/initramfs.c:675:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
           char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
                 ^
   1 warning generated.


vim +675 init/initramfs.c

7c184ecd262fe6 Christoph Hellwig 2019-05-13  667  
9a9e0d685553af Linus Torvalds    2008-03-15  668  static int __init populate_rootfs(void)
^1da177e4c3f41 Linus Torvalds    2005-04-16  669  {
3f62443c165ea1 Linus Walleij     2021-04-16  670  	pr_info("%s enter __initramfs_start = %08x, __initramfs_size = %08x\n",
3f62443c165ea1 Linus Walleij     2021-04-16  671  		__func__,
3f62443c165ea1 Linus Walleij     2021-04-16  672  		(unsigned int)__initramfs_start,
3f62443c165ea1 Linus Walleij     2021-04-16  673  		(unsigned int)__initramfs_size);
17a9be31747535 Stafford Horne    2017-05-04  674  	/* Load the built in initramfs */
ffe8018c342489 Hendrik Brueckner 2010-09-17 @675  	char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);

:::::: The code at line 675 was first introduced by commit
:::::: ffe8018c3424892c9590048fc36caa6c3e0c8a76 initramfs: fix initramfs size calculation

:::::: TO: Hendrik Brueckner <brueckner at linux.vnet.ibm.com>
:::::: CC: Michal Marek <mmarek at suse.cz>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35878 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/559552a9/attachment-0001.gz>

From lkp at intel.com  Sun Apr 18 00:12:45 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 07:12:45 +0800
Subject: [nomadik:ixp4 7/14] drivers/watchdog/ixp4xx_wdt.c:175:8: error:
 implicit declaration of function 'read_cpuid_id'
Message-ID: <202104180739.PIjYiLIj-lkp@intel.com>

Hi Arnd,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ixp4
head:   e0bf0c1bc94b9100d85ace594fd1f0fb0024dbf2
commit: f98dec27333d7a6d39cfafb90e3305b491bf7c4a [7/14] watchdog: ixp4xx: move mmio access to timer driver
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=f98dec27333d7a6d39cfafb90e3305b491bf7c4a
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ixp4
        git checkout f98dec27333d7a6d39cfafb90e3305b491bf7c4a
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/watchdog/ixp4xx_wdt.c: In function 'ixp4xx_wdt_init':
>> drivers/watchdog/ixp4xx_wdt.c:175:8: error: implicit declaration of function 'read_cpuid_id' [-Werror=implicit-function-declaration]
     175 |  if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) {
         |        ^~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +/read_cpuid_id +175 drivers/watchdog/ixp4xx_wdt.c

^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  164  
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  165  static int __init ixp4xx_wdt_init(void)
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  166  {
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  167  	int ret;
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  168  
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  169  	ret = ixp4xx_boot_status();
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  170  	if (ret < 0)
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  171  		return ret;
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  172  
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  173  	boot_status = ret ?  WDIOF_CARDRESET : 0;
f98dec27333d7a drivers/watchdog/ixp4xx_wdt.c      Arnd Bergmann  2019-08-26  174  
0ba8b9b273c45d drivers/watchdog/ixp4xx_wdt.c      Russell King   2008-08-10 @175  	if (!(read_cpuid_id() & 0xf) && !cpu_is_ixp46x()) {
27c766aaacb265 drivers/watchdog/ixp4xx_wdt.c      Joe Perches    2012-02-15  176  		pr_err("Rev. A0 IXP42x CPU detected - watchdog disabled\n");
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  177  
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  178  		return -ENODEV;
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  179  	}
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  180  	ret = misc_register(&ixp4xx_wdt_miscdev);
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  181  	if (ret == 0)
27c766aaacb265 drivers/watchdog/ixp4xx_wdt.c      Joe Perches    2012-02-15  182  		pr_info("timer heartbeat %d sec\n", heartbeat);
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  183  	return ret;
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  184  }
^1da177e4c3f41 drivers/char/watchdog/ixp4xx_wdt.c Linus Torvalds 2005-04-16  185  

:::::: The code at line 175 was first introduced by commit
:::::: 0ba8b9b273c45dd23f60ff700e265a0069b33758 [ARM] cputype: separate definitions, use them

:::::: TO: Russell King <rmk at dyn-67.arm.linux.org.uk>
:::::: CC: Russell King <rmk+kernel at arm.linux.org.uk>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 70234 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/3f47108b/attachment-0001.gz>

From lkp at intel.com  Sun Apr 18 00:47:45 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 07:47:45 +0800
Subject: [nomadik:ux500-href-dts-fixups 30/30] init/initramfs.c:672:3:
 warning: cast to smaller integer type 'unsigned int' from 'char *'
Message-ID: <202104180743.59pHsZJ6-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
head:   3f62443c165ea1c988d9b0855292785a28906698
commit: 3f62443c165ea1c988d9b0855292785a28906698 [30/30] hacks
config: x86_64-randconfig-r004-20210418 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f549176ad976caa3e19edd036df9a7e12770af7c)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=3f62443c165ea1c988d9b0855292785a28906698
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ux500-href-dts-fixups
        git checkout 3f62443c165ea1c988d9b0855292785a28906698
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> init/initramfs.c:672:3: warning: cast to smaller integer type 'unsigned int' from 'char *' [-Wpointer-to-int-cast]
                   (unsigned int)__initramfs_start,
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/printk.h:373:34: note: expanded from macro 'pr_info'
           printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
                                           ^~~~~~~~~~~
   init/initramfs.c:675:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
           char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
                 ^
   2 warnings generated.


vim +672 init/initramfs.c

   667	
   668	static int __init populate_rootfs(void)
   669	{
   670		pr_info("%s enter __initramfs_start = %08x, __initramfs_size = %08x\n",
   671			__func__,
 > 672			(unsigned int)__initramfs_start,

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35728 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/5733ba7d/attachment-0001.gz>

From alexandre.belloni at bootlin.com  Sun Apr 18 00:52:05 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Sun, 18 Apr 2021 01:52:05 +0200
Subject: [PATCH] imx-sc: remove .read_alarm
Message-ID: <20210417235205.994119-1-alexandre.belloni@bootlin.com>

The RTC core properly handles RTC without .read_alarm and doesn't use it to
set alarms. .read_alarm can be safely dropped.

Signed-off-by: Alexandre Belloni <alexandre.belloni at bootlin.com>
---
 drivers/rtc/rtc-imx-sc.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c
index cc9fbab49999..814d516645e2 100644
--- a/drivers/rtc/rtc-imx-sc.c
+++ b/drivers/rtc/rtc-imx-sc.c
@@ -80,16 +80,6 @@ static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
 	return imx_scu_irq_group_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable);
 }
 
-static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
-{
-	/*
-	 * SCU firmware does NOT provide read alarm API, but .read_alarm
-	 * callback is required by RTC framework to support alarm function,
-	 * so just return here.
-	 */
-	return 0;
-}
-
 static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
 {
 	struct imx_sc_msg_timer_rtc_set_alarm msg;
@@ -127,7 +117,6 @@ static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
 static const struct rtc_class_ops imx_sc_rtc_ops = {
 	.read_time = imx_sc_rtc_read_time,
 	.set_time = imx_sc_rtc_set_time,
-	.read_alarm = imx_sc_rtc_read_alarm,
 	.set_alarm = imx_sc_rtc_set_alarm,
 	.alarm_irq_enable = imx_sc_rtc_alarm_irq_enable,
 };
-- 
2.30.2



From lkp at intel.com  Sun Apr 18 00:52:55 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 07:52:55 +0800
Subject: [nomadik:ux500-href-dts-fixups 30/30] init/initramfs.c:670:9:
 sparse: sparse: non size-preserving pointer to integer cast
Message-ID: <202104180753.WcDMAXsq-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
head:   3f62443c165ea1c988d9b0855292785a28906698
commit: 3f62443c165ea1c988d9b0855292785a28906698 [30/30] hacks
config: x86_64-randconfig-s021-20210418 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-280-g2cd6d34e-dirty
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=3f62443c165ea1c988d9b0855292785a28906698
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ux500-href-dts-fixups
        git checkout 3f62443c165ea1c988d9b0855292785a28906698
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
   init/initramfs.c:675:9: sparse: sparse: mixing declarations and code
>> init/initramfs.c:670:9: sparse: sparse: non size-preserving pointer to integer cast

vim +670 init/initramfs.c

   667	
   668	static int __init populate_rootfs(void)
   669	{
 > 670		pr_info("%s enter __initramfs_start = %08x, __initramfs_size = %08x\n",

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36448 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/985f459f/attachment-0001.gz>

From lkp at intel.com  Sun Apr 18 01:00:47 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 08:00:47 +0800
Subject: [nomadik:ixp4 3/14] include/linux/compiler_types.h:320:38: error:
 call to '__compiletime_assert_370' declared with attribute error:
 BUILD_BUG_ON failed: sizeof(struct crypt_ctl) != 64
Message-ID: <202104180843.X7DH76fd-lkp@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ixp4
head:   e0bf0c1bc94b9100d85ace594fd1f0fb0024dbf2
commit: 3d583e289034b689125b10efb2f82c05ab93c507 [3/14] crypto: ixp4xx: convert to platform driver
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?id=3d583e289034b689125b10efb2f82c05ab93c507
        git remote add nomadik https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
        git fetch --no-tags nomadik ixp4
        git checkout 3d583e289034b689125b10efb2f82c05ab93c507
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from <command-line>:
   In function 'setup_crypt_desc',
       inlined from 'get_crypt_desc' at drivers/crypto/ixp4xx_crypto.c:276:3:
>> include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_370' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct crypt_ctl) != 64
     320 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
         |                                      ^
   include/linux/compiler_types.h:301:4: note: in definition of macro '__compiletime_assert'
     301 |    prefix ## suffix();    \
         |    ^~~~~~
   include/linux/compiler_types.h:320:2: note: in expansion of macro '_compiletime_assert'
     320 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
      50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
         |  ^~~~~~~~~~~~~~~~
   drivers/crypto/ixp4xx_crypto.c:257:2: note: in expansion of macro 'BUILD_BUG_ON'
     257 |  BUILD_BUG_ON(sizeof(struct crypt_ctl) != 64);
         |  ^~~~~~~~~~~~


vim +/__compiletime_assert_370 +320 include/linux/compiler_types.h

eb5c2d4b45e3d2 Will Deacon 2020-07-21  306  
eb5c2d4b45e3d2 Will Deacon 2020-07-21  307  #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21  308  	__compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2 Will Deacon 2020-07-21  309  
eb5c2d4b45e3d2 Will Deacon 2020-07-21  310  /**
eb5c2d4b45e3d2 Will Deacon 2020-07-21  311   * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21  312   * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2 Will Deacon 2020-07-21  313   * @msg:       a message to emit if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21  314   *
eb5c2d4b45e3d2 Will Deacon 2020-07-21  315   * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21  316   * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21  317   * compiler has support to do so.
eb5c2d4b45e3d2 Will Deacon 2020-07-21  318   */
eb5c2d4b45e3d2 Will Deacon 2020-07-21  319  #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 @320  	_compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2 Will Deacon 2020-07-21  321  

:::::: The code at line 320 was first introduced by commit
:::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h

:::::: TO: Will Deacon <will at kernel.org>
:::::: CC: Will Deacon <will at kernel.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67468 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/2325f28a/attachment-0001.gz>

From lkp at intel.com  Sun Apr 18 09:43:05 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 16:43:05 +0800
Subject: [nomadik:ixp4] BUILD REGRESSION
 e0bf0c1bc94b9100d85ace594fd1f0fb0024dbf2
Message-ID: <607bf119.dh1jC34tDCmcfCL9%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ixp4
branch HEAD: e0bf0c1bc94b9100d85ace594fd1f0fb0024dbf2  Drop OpenWRT mount from Camdria DTS

Error/Warning reports:

https://lore.kernel.org/linux-arm-kernel/202104180656.nvXvR6kO-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104180739.PIjYiLIj-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104180843.X7DH76fd-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104181158.aq88s29Z-lkp at intel.com

Error/Warning in current branch:

arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x1c24): undefined reference to `qmgr_put_entry'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x1c2c): undefined reference to `qmgr_stat_overflow'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x6e8): undefined reference to `qmgr_release_queue'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x708): undefined reference to `npe_release'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x818): undefined reference to `npe_running'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x860): undefined reference to `npe_load_firmware'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x88c): undefined reference to `npe_recv_message'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0x908): undefined reference to `npe_send_message'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0xa50): undefined reference to `__qmgr_request_queue'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0xad0): undefined reference to `qmgr_set_irq'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0xae8): undefined reference to `qmgr_enable_irq'
arm-linux-gnueabi-ld: ixp4xx_crypto.c:(.text+0xf40): undefined reference to `npe_names'
drivers/input/misc/ixp4xx-beeper.c:109:31: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/input/misc/ixp4xx-beeper.c:61:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/watchdog/ixp4xx_wdt.c:175:8: error: implicit declaration of function 'read_cpuid_id' [-Werror=implicit-function-declaration]
include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_370' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct crypt_ctl) != 64
include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_438' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct crypt_ctl) != 64
ixp4xx_crypto.c:(.text+0x18d8): undefined reference to `qmgr_stat_full'
ixp4xx_crypto.c:(.text+0x296c): undefined reference to `qmgr_put_entry'
ixp4xx_crypto.c:(.text+0x6d8): undefined reference to `qmgr_disable_irq'
ixp4xx_crypto.c:(.text+0x7ec): undefined reference to `npe_request'
ixp4xx_crypto.c:(.text+0xfe8): undefined reference to `qmgr_get_entry'

possible Error/Warning in current branch:

ERROR: modpost: "__qmgr_request_queue" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_load_firmware" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_names" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_recv_message" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_release" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_request" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_running" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "npe_send_message" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_disable_irq" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_enable_irq" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_get_entry" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_put_entry" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_release_queue" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_set_irq" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_stat_full" [drivers/crypto/ixp4xx_crypto.ko] undefined!
ERROR: modpost: "qmgr_stat_overflow" [drivers/crypto/ixp4xx_crypto.ko] undefined!

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-from-pointer-to-integer-of-different-size
|   `-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-to-pointer-from-integer-of-different-size
|-- arc-allyesconfig
|   `-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:BUILD_BUG_ON-failed:sizeof(struct-crypt_ctl)
|-- arm-allmodconfig
|   |-- ERROR:__qmgr_request_queue-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_load_firmware-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_names-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_recv_message-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_release-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_request-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_running-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:npe_send_message-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_disable_irq-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_enable_irq-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_get_entry-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_put_entry-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_release_queue-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_set_irq-drivers-crypto-ixp4xx_crypto.ko-undefined
|   |-- ERROR:qmgr_stat_full-drivers-crypto-ixp4xx_crypto.ko-undefined
|   `-- ERROR:qmgr_stat_overflow-drivers-crypto-ixp4xx_crypto.ko-undefined
|-- arm-allyesconfig
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-__qmgr_request_queue
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_load_firmware
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_names
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_recv_message
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_release
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_running
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-npe_send_message
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_enable_irq
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_put_entry
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_release_queue
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_set_irq
|   |-- arm-linux-gnueabi-ld:ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_stat_overflow
|   |-- ixp4xx_crypto.c:(.text):undefined-reference-to-npe_request
|   |-- ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_disable_irq
|   |-- ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_get_entry
|   |-- ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_put_entry
|   `-- ixp4xx_crypto.c:(.text):undefined-reference-to-qmgr_stat_full
|-- arm64-allyesconfig
|   |-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-from-pointer-to-integer-of-different-size
|   |-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-to-pointer-from-integer-of-different-size
|   `-- include-linux-compiler_types.h:error:call-to-__compiletime_assert_NNN-declared-with-attribute-error:BUILD_BUG_ON-failed:sizeof(struct-crypt_ctl)
|-- mips-allyesconfig
|   `-- drivers-watchdog-ixp4xx_wdt.c:error:implicit-declaration-of-function-read_cpuid_id
|-- parisc-allyesconfig
|   `-- drivers-watchdog-ixp4xx_wdt.c:error:implicit-declaration-of-function-read_cpuid_id
|-- sh-allmodconfig
|   `-- drivers-watchdog-ixp4xx_wdt.c:error:implicit-declaration-of-function-read_cpuid_id
`-- sparc-allyesconfig
    |-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-from-pointer-to-integer-of-different-size
    `-- drivers-input-misc-ixp4xx-beeper.c:warning:cast-to-pointer-from-integer-of-different-size

elapsed time: 724m

configs tested: 97
configs skipped: 3

gcc tested configs:
arm64                            allyesconfig
arm                                 defconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
um                             i386_defconfig
arm                           stm32_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
arm                        clps711x_defconfig
mips                          malta_defconfig
arm                       multi_v4t_defconfig
sh                          rsk7201_defconfig
arm                         nhk8815_defconfig
sh                      rts7751r2d1_defconfig
sh                          rsk7264_defconfig
mips                          rm200_defconfig
mips                malta_qemu_32r6_defconfig
arm                          pxa3xx_defconfig
powerpc                   lite5200b_defconfig
powerpc                     mpc83xx_defconfig
arm                       spear13xx_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20210418
i386                 randconfig-a001-20210418
i386                 randconfig-a006-20210418
i386                 randconfig-a005-20210418
i386                 randconfig-a004-20210418
i386                 randconfig-a002-20210418
x86_64               randconfig-a014-20210418
x86_64               randconfig-a015-20210418
x86_64               randconfig-a013-20210418
x86_64               randconfig-a011-20210418
x86_64               randconfig-a012-20210418
x86_64               randconfig-a016-20210418
i386                 randconfig-a015-20210418
i386                 randconfig-a013-20210418
i386                 randconfig-a014-20210418
i386                 randconfig-a016-20210418
i386                 randconfig-a012-20210418
i386                 randconfig-a011-20210418
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210418
x86_64               randconfig-a001-20210418
x86_64               randconfig-a005-20210418
x86_64               randconfig-a002-20210418
x86_64               randconfig-a006-20210418
x86_64               randconfig-a004-20210418

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sun Apr 18 09:43:09 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 16:43:09 +0800
Subject: [nomadik:ixp4-diet] BUILD SUCCESS
 007b2670eac90aed801f0d77e2f4db2039c3555a
Message-ID: <607bf11d.k5OIn269aiWER0Nz%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ixp4-diet
branch HEAD: 007b2670eac90aed801f0d77e2f4db2039c3555a  Drop OpenWRT mount from Camdria DTS

elapsed time: 724m

configs tested: 119
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
arm                         cm_x300_defconfig
powerpc                    ge_imp3a_defconfig
m68k                          amiga_defconfig
openrisc                            defconfig
sh                          sdk7786_defconfig
mips                       lemote2f_defconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
um                             i386_defconfig
arm                           stm32_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                      obs600_defconfig
mips                           xway_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
mips                           ci20_defconfig
mips                          rm200_defconfig
arc                            hsdk_defconfig
m68k                        m5272c3_defconfig
xtensa                              defconfig
powerpc                     stx_gp3_defconfig
arm                        clps711x_defconfig
mips                          malta_defconfig
arm                       multi_v4t_defconfig
sh                          rsk7201_defconfig
arm                         nhk8815_defconfig
arm                          pxa3xx_defconfig
powerpc                   lite5200b_defconfig
powerpc                     mpc83xx_defconfig
arm                       spear13xx_defconfig
sh                          polaris_defconfig
mips                      malta_kvm_defconfig
mips                        jmr3927_defconfig
arc                           tb10x_defconfig
um                               alldefconfig
powerpc                      ep88xc_defconfig
sh                          rsk7264_defconfig
mips                          rb532_defconfig
sh                           se7619_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20210418
i386                 randconfig-a001-20210418
i386                 randconfig-a005-20210418
i386                 randconfig-a004-20210418
i386                 randconfig-a002-20210418
i386                 randconfig-a006-20210418
x86_64               randconfig-a014-20210418
x86_64               randconfig-a015-20210418
x86_64               randconfig-a013-20210418
x86_64               randconfig-a011-20210418
x86_64               randconfig-a012-20210418
x86_64               randconfig-a016-20210418
i386                 randconfig-a015-20210418
i386                 randconfig-a013-20210418
i386                 randconfig-a014-20210418
i386                 randconfig-a016-20210418
i386                 randconfig-a012-20210418
i386                 randconfig-a011-20210418
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210418
x86_64               randconfig-a001-20210418
x86_64               randconfig-a005-20210418
x86_64               randconfig-a002-20210418
x86_64               randconfig-a006-20210418
x86_64               randconfig-a004-20210418

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sun Apr 18 09:43:03 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 16:43:03 +0800
Subject: [nomadik:nomadik] BUILD SUCCESS
 68e81419f56fa0915ec2fd8f65daafe3d8ed6cff
Message-ID: <607bf117.IScBqs57ctgimdon%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git nomadik
branch HEAD: 68e81419f56fa0915ec2fd8f65daafe3d8ed6cff  Input: tsc200x: Drop hard-coded IRQ edge

elapsed time: 724m

configs tested: 110
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allyesconfig
arm                         cm_x300_defconfig
powerpc                    ge_imp3a_defconfig
m68k                          amiga_defconfig
openrisc                            defconfig
sh                          sdk7786_defconfig
mips                       lemote2f_defconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
um                             i386_defconfig
arm                           stm32_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                      obs600_defconfig
mips                           xway_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
mips                           ci20_defconfig
mips                          rm200_defconfig
arc                            hsdk_defconfig
m68k                        m5272c3_defconfig
xtensa                              defconfig
powerpc                     stx_gp3_defconfig
sh                          polaris_defconfig
mips                      malta_kvm_defconfig
mips                        jmr3927_defconfig
arc                           tb10x_defconfig
um                               alldefconfig
powerpc                      ep88xc_defconfig
sh                          rsk7264_defconfig
mips                          rb532_defconfig
sh                           se7619_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20210418
i386                 randconfig-a001-20210418
i386                 randconfig-a006-20210418
i386                 randconfig-a005-20210418
i386                 randconfig-a004-20210418
i386                 randconfig-a002-20210418
x86_64               randconfig-a014-20210418
x86_64               randconfig-a015-20210418
x86_64               randconfig-a013-20210418
x86_64               randconfig-a011-20210418
x86_64               randconfig-a012-20210418
x86_64               randconfig-a016-20210418
i386                 randconfig-a015-20210418
i386                 randconfig-a013-20210418
i386                 randconfig-a014-20210418
i386                 randconfig-a016-20210418
i386                 randconfig-a012-20210418
i386                 randconfig-a011-20210418
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210418
x86_64               randconfig-a001-20210418
x86_64               randconfig-a005-20210418
x86_64               randconfig-a002-20210418
x86_64               randconfig-a006-20210418
x86_64               randconfig-a004-20210418

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sun Apr 18 09:43:07 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 16:43:07 +0800
Subject: [nomadik:ux500-href-dts-fixups] BUILD SUCCESS WITH WARNING
 3f62443c165ea1c988d9b0855292785a28906698
Message-ID: <607bf11b.0pIbLfrM0IZaYFry%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-href-dts-fixups
branch HEAD: 3f62443c165ea1c988d9b0855292785a28906698  hacks

Warning reports:

https://lore.kernel.org/linux-arm-kernel/202104180627.4W8fw2Am-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104180702.QwjANdJc-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104180743.59pHsZJ6-lkp at intel.com
https://lore.kernel.org/linux-arm-kernel/202104180753.WcDMAXsq-lkp at intel.com

Warning in current branch:

init/initramfs.c:672:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
init/initramfs.c:672:3: warning: cast to smaller integer type 'unsigned int' from 'char *' [-Wpointer-to-int-cast]
init/initramfs.c:675:8: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]

possible Warning in current branch:

init/initramfs.c:670 populate_rootfs() warn: argument 3 to %08x specifier is cast from pointer

Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- alpha-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- arm64-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- arm64-defconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- ia64-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- ia64-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- ia64-defconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- mips-bigsur_defconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- powerpc-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- powerpc-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- riscv-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- riscv-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- riscv-defconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- s390-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- s390-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- s390-defconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- s390-randconfig-r011-20210418
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- sparc-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- x86_64-allmodconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- x86_64-allyesconfig
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- x86_64-kexec
|   `-- init-initramfs.c:warning:cast-from-pointer-to-integer-of-different-size
|-- x86_64-randconfig-m001-20210418
|   `-- init-initramfs.c-populate_rootfs()-warn:argument-to-08x-specifier-is-cast-from-pointer
`-- x86_64-randconfig-s021-20210418
    `-- init-initramfs.c:sparse:sparse:non-size-preserving-pointer-to-integer-cast

clang_recent_errors
|-- mips-randconfig-r024-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|-- x86_64-randconfig-a001-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|-- x86_64-randconfig-a002-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|-- x86_64-randconfig-a003-20210418
|   |-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|   `-- init-initramfs.c:warning:cast-to-smaller-integer-type-unsigned-int-from-char
|-- x86_64-randconfig-a004-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|-- x86_64-randconfig-a005-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
|-- x86_64-randconfig-a006-20210418
|   `-- init-initramfs.c:warning:ISO-C90-forbids-mixing-declarations-and-code
`-- x86_64-randconfig-r004-20210418
    `-- init-initramfs.c:warning:cast-to-smaller-integer-type-unsigned-int-from-char

elapsed time: 724m

configs tested: 110
configs skipped: 2

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
arm                         cm_x300_defconfig
powerpc                    ge_imp3a_defconfig
m68k                          amiga_defconfig
openrisc                            defconfig
sh                          sdk7786_defconfig
mips                       lemote2f_defconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
um                             i386_defconfig
arm                           stm32_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                      obs600_defconfig
mips                           xway_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
mips                           ci20_defconfig
mips                          rm200_defconfig
arc                            hsdk_defconfig
m68k                        m5272c3_defconfig
xtensa                              defconfig
powerpc                     stx_gp3_defconfig
sh                          polaris_defconfig
mips                      malta_kvm_defconfig
mips                        jmr3927_defconfig
arc                           tb10x_defconfig
um                               alldefconfig
powerpc                      ep88xc_defconfig
sh                          rsk7264_defconfig
mips                          rb532_defconfig
sh                           se7619_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20210418
i386                 randconfig-a001-20210418
i386                 randconfig-a006-20210418
i386                 randconfig-a005-20210418
i386                 randconfig-a004-20210418
i386                 randconfig-a002-20210418
x86_64               randconfig-a014-20210418
x86_64               randconfig-a015-20210418
x86_64               randconfig-a013-20210418
x86_64               randconfig-a011-20210418
x86_64               randconfig-a012-20210418
x86_64               randconfig-a016-20210418
i386                 randconfig-a015-20210418
i386                 randconfig-a013-20210418
i386                 randconfig-a014-20210418
i386                 randconfig-a016-20210418
i386                 randconfig-a012-20210418
i386                 randconfig-a011-20210418
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec
x86_64                    rhel-8.3-kselftests

clang tested configs:
x86_64               randconfig-a003-20210418
x86_64               randconfig-a001-20210418
x86_64               randconfig-a005-20210418
x86_64               randconfig-a002-20210418
x86_64               randconfig-a006-20210418
x86_64               randconfig-a004-20210418

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Sun Apr 18 09:43:02 2021
From: lkp at intel.com (kernel test robot)
Date: Sun, 18 Apr 2021 16:43:02 +0800
Subject: [nomadik:gemini-defconfig] BUILD SUCCESS
 d8c7fea737df00815ae1c8e544447023a98aef89
Message-ID: <607bf116.9FRgg7Mb15mBmqvv%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git gemini-defconfig
branch HEAD: d8c7fea737df00815ae1c8e544447023a98aef89  net: gemini: Avoid NULL dereference

elapsed time: 724m

configs tested: 108
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allyesconfig
arm                         cm_x300_defconfig
powerpc                    ge_imp3a_defconfig
m68k                          amiga_defconfig
openrisc                            defconfig
sh                          sdk7786_defconfig
mips                       lemote2f_defconfig
arm                    vt8500_v6_v7_defconfig
mips                         bigsur_defconfig
um                             i386_defconfig
arm                           stm32_defconfig
mips                        qi_lb60_defconfig
powerpc                     pseries_defconfig
powerpc                      obs600_defconfig
mips                           xway_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
mips                           ci20_defconfig
mips                          rm200_defconfig
arc                            hsdk_defconfig
m68k                        m5272c3_defconfig
xtensa                              defconfig
powerpc                     stx_gp3_defconfig
sh                          polaris_defconfig
mips                      malta_kvm_defconfig
mips                        jmr3927_defconfig
arc                           tb10x_defconfig
um                               alldefconfig
powerpc                      ep88xc_defconfig
sh                          rsk7264_defconfig
mips                          rb532_defconfig
sh                           se7619_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
i386                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a003-20210418
i386                 randconfig-a001-20210418
i386                 randconfig-a006-20210418
i386                 randconfig-a005-20210418
i386                 randconfig-a004-20210418
i386                 randconfig-a002-20210418
x86_64               randconfig-a014-20210418
x86_64               randconfig-a015-20210418
x86_64               randconfig-a013-20210418
x86_64               randconfig-a011-20210418
x86_64               randconfig-a012-20210418
x86_64               randconfig-a016-20210418
i386                 randconfig-a015-20210418
i386                 randconfig-a013-20210418
i386                 randconfig-a014-20210418
i386                 randconfig-a016-20210418
i386                 randconfig-a012-20210418
i386                 randconfig-a011-20210418
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210418
x86_64               randconfig-a001-20210418
x86_64               randconfig-a005-20210418
x86_64               randconfig-a002-20210418
x86_64               randconfig-a006-20210418
x86_64               randconfig-a004-20210418

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From sebastian.fricke at posteo.net  Sun Apr 18 11:34:25 2021
From: sebastian.fricke at posteo.net (Sebastian Fricke)
Date: Sun, 18 Apr 2021 10:34:25 +0000
Subject: [PATCH] media: rkisp1: rksip1-capture.c: Improve comments and fix
 typos
Message-ID: <20210418103425.45525-1-sebastian.fricke@posteo.net>

Improve the wording of the function description to increase readability.

Fix three typos:
s/during processing a frame/while processing a frame/
s/it also update/it also updates/
s/there's not buf in shadow/there's no buffer in a shadow register/

Replace the abbreviation 'buf' with the full word buffer, the
abbreviation 'config' with the verb configure, and 'regs' with registers.
The goal of this change is to ease the reading flow of the comment.

Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>
---
Side-note:
I also believe there should be a description for the abbreviation FE, as
it is not described anywhere. I think it means frame end, right?.
---
 .../platform/rockchip/rkisp1/rkisp1-capture.c    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..9643bdd05b7b 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -830,8 +830,8 @@ static void rkisp1_return_all_buffers(struct rkisp1_capture *cap,
 }
 
 /*
- * Most of registers inside rockchip ISP1 have shadow register since
- * they must be not be changed during processing a frame.
+ * Most registers inside the rockchip ISP1 have shadow register since
+ * they must not be changed while processing a frame.
  * Usually, each sub-module updates its shadow register after
  * processing the last pixel of a frame.
  */
@@ -847,14 +847,14 @@ static void rkisp1_cap_stream_enable(struct rkisp1_capture *cap)
 	spin_lock_irq(&cap->buf.lock);
 	rkisp1_set_next_buf(cap);
 	cap->ops->enable(cap);
-	/* It's safe to config ACTIVE and SHADOW regs for the
+	/* It's safe to configure ACTIVE and SHADOW registers for the
 	 * first stream. While when the second is starting, do NOT
-	 * force update because it also update the first one.
+	 * force update because it also updates the first one.
 	 *
-	 * The latter case would drop one more buf(that is 2) since
-	 * there's not buf in shadow when the second FE received. This's
-	 * also required because the second FE maybe corrupt especially
-	 * when run at 120fps.
+	 * The latter case would drop one more buffer(that is 2) since
+	 * there's no buffer in a shadow register when the second FE received.
+	 * This's also required because the second FE maybe corrupt
+	 * especially when run at 120fps.
 	 */
 	if (!other->is_streaming) {
 		/* force cfg update */
-- 
2.25.1



From nobuhiro1.iwamatsu at toshiba.co.jp  Sun Apr 18 12:07:18 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sun, 18 Apr 2021 20:07:18 +0900
Subject: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210417155009.vnqxx3fn2yjzp3qc@pengutronix.de>
References: <20210409230837.1919744-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210409230837.1919744-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210410135321.oissremqropvrpd3@pengutronix.de>
 <20210412025536.i5chpp6sighunvfx@toshiba.co.jp>
 <20210412070232.6q3cgqvuj53p4cmi@pengutronix.de>
 <20210416080721.oa7xdvu22w2b2rkf@toshiba.co.jp>
 <20210416094426.x4gyw3drp2fcwczs@pengutronix.de>
 <20210416121523.c34trzsrlcjuzirl@toshiba.co.jp>
 <20210417155009.vnqxx3fn2yjzp3qc@pengutronix.de>
Message-ID: <20210418110718.4zrh665anbz3wmqc@toshiba.co.jp>

Hi Uwe,

On Sat, Apr 17, 2021 at 05:50:09PM +0200, Uwe Kleine-K?nig wrote:
> Hello Nobuhiro,
> 
> On Fri, Apr 16, 2021 at 09:15:23PM +0900, Nobuhiro Iwamatsu wrote:
> > > > > For me the critical (and only) difference between "off" and
> > > > > "duty cycle = 0" is that when a new configuration is to be applied. In
> > > > > the "off" state a new period can (and should) start immediately, while
> > > > > with "duty_cycle = 0" the rising edge should be delayed until the
> > > > > currently running period is over.[1]
> > > > > 
> > > > > So the thing to do here (IMHO) is:
> > > > > 
> > > > > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized
> > > > > with writing a non-zero value to PIPGM_PCSR) completes the currently
> > > > > running period, then always assume the PWM as enabled.
> > > > 
> > > > Yes, this device works that way.
> > > 
> > > OK, then please use
> > > 
> > > 	state->enabled = true
> > > 
> > > unconditionally in visconti_pwm_get_state().
> > 
> > Please let me check.
> > If I unconditionally add 'state->enabled = true' to visconti_pwm_get_state(),
> > state->enabled is set to true because visconti_pwm_get_state() is called when
> > the device is created (this is when I write the device number to the export of
> > /sys/class/pwm/pwmchip0 ).
> > And since PIPGM_PCSR is 0 in this state, the pulse by PWM is not output.
> 
> A PWM that is currently configured with .enabled = true and .duty_cycle
> = 0 doesn't have a pulse, so this is fine.
> 

I understood, thanks.

> > However, I think this means that the device is working as this driver.
> 
> I don't understand this sentence.

The description of the struct pwm_state says "PWM enabled status".
I thought 'state-> enabled' would hold the working state of the hardware.

> 
> Best regards
> Uwe

Best regards,
  Nobuhiro


From nobuhiro1.iwamatsu at toshiba.co.jp  Sun Apr 18 12:09:03 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sun, 18 Apr 2021 20:09:03 +0900
Subject: [PATCH v5 1/2] dt-bindings: pwm: Add bindings for Toshiba Visconti
 PWM Controller
In-Reply-To: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210418110904.1942806-2-nobuhiro1.iwamatsu@toshiba.co.jp>

Add bindings for the Toshiba Visconti PWM Controller.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pwm/toshiba,pwm-visconti.yaml    | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml

diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
new file mode 100644
index 000000000000..d350f5edfb67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/toshiba,pwm-visconti.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti PWM Controller
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,visconti-pwm
+
+  reg:
+    maxItems: 1
+
+  '#pwm-cells':
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pwm: pwm at 241c0000 {
+            compatible = "toshiba,visconti-pwm";
+            reg = <0 0x241c0000 0 0x1000>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&pwm_mux>;
+            #pwm-cells = <2>;
+        };
+    };
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Sun Apr 18 12:09:04 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sun, 18 Apr 2021 20:09:04 +0900
Subject: [PATCH v5 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210418110904.1942806-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add driver for the PWM controller on Toshiba Visconti ARM SoC.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pwm/Kconfig        |   9 ++
 drivers/pwm/Makefile       |   1 +
 drivers/pwm/pwm-visconti.c | 188 +++++++++++++++++++++++++++++++++++++
 3 files changed, 198 insertions(+)
 create mode 100644 drivers/pwm/pwm-visconti.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..8ae68d6203fb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -601,6 +601,15 @@ config PWM_TWL_LED
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-twl-led.
 
+config PWM_VISCONTI
+	tristate "Toshiba Visconti PWM support"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	help
+	  PWM Subsystem driver support for Toshiba Visconti SoCs.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-visconti.
+
 config PWM_VT8500
 	tristate "vt8500 PWM support"
 	depends on ARCH_VT8500 || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..d43b1e17e8e1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
+obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
 obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
new file mode 100644
index 000000000000..166b18ac1a3a
--- /dev/null
+++ b/drivers/pwm/pwm-visconti.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Toshiba Visconti pulse-width-modulation controller driver
+ *
+ * Copyright (c) 2020 TOSHIBA CORPORATION
+ * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
+ *
+ * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ * Limitations:
+ * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8).
+ * - Fixed input clock running at 1 MHz.
+ * - When the settings of the PWM are modified, the new values are shadowed
+ *   in hardware until the PIPGM_PCSR register is written and the currently
+ *   running period is completed. This way the hardware switches atomically
+ *   from the old setting to the new.
+ * - Disabling the hardware completes the currently running period and keeps
+ *   the output at low level at all times.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
+#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
+#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
+
+#define PIPGM_PWMC_PWMACT		BIT(5)
+#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
+#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);
+}
+
+static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = visconti_pwm_from_chip(chip);
+	u32 period, duty_cycle, pwmc0;
+
+	if (!state->enabled) {
+		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
+		return 0;
+	}
+
+	/*
+	 * The biggest period the hardware can provide is
+	 *	(0xffff << 3) * 1000 ns
+	 * This value fits easily in an u32, so simplify the maths by
+	 * capping the values to 32 bit integers.
+	 */
+	if (state->period > (0xffff << 3) * 1000)
+		period = (0xffff << 3) * 1000;
+	else
+		period = state->period;
+
+	if (state->duty_cycle > period)
+		duty_cycle = period;
+	else
+		duty_cycle = state->duty_cycle;
+
+	/*
+	 * The input clock runs fixed at 1 MHz, so we have only
+	 * microsecond resolution and so can divide by
+	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
+	 */
+	period /= 1000;
+	duty_cycle /= 1000;
+
+	if (!period)
+		return -ERANGE;
+
+	/*
+	 * PWMC controls a divider that divides the input clk by a
+	 * power of two between 1 and 8. As a smaller divider yields
+	 * higher precision, pick the smallest possible one.
+	 */
+	if (period > 0xffff) {
+		pwmc0 = ilog2(period >> 16);
+		BUG_ON(pwmc0 > 3);
+	} else
+		pwmc0 = 0;
+
+	period >>= pwmc0;
+	duty_cycle >>= pwmc0;
+
+	if (state->polarity == PWM_POLARITY_INVERSED)
+		pwmc0 |= PIPGM_PWMC_PWMACT;
+	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
+	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
+	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
+
+	return 0;
+}
+
+static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = visconti_pwm_from_chip(chip);
+	u32 period, duty, pwmc0, pwmc0_clk;
+
+	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
+	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
+	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
+	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
+
+	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
+	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
+	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
+		state->polarity = PWM_POLARITY_INVERSED;
+	else
+		state->polarity = PWM_POLARITY_NORMAL;
+
+	state->enabled = true;
+}
+
+static const struct pwm_ops visconti_pwm_ops = {
+	.apply = visconti_pwm_apply,
+	.get_state = visconti_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int visconti_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pwm_chip *priv;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &visconti_pwm_ops;
+	priv->chip.npwm = 4;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
+
+	return 0;
+}
+
+static int visconti_pwm_remove(struct platform_device *pdev)
+{
+	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
+
+	pwmchip_remove(&priv->chip);
+
+	return 0;
+}
+
+static const struct of_device_id visconti_pwm_of_match[] = {
+	{ .compatible = "toshiba,visconti-pwm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, visconti_pwm_of_match);
+
+static struct platform_driver visconti_pwm_driver = {
+	.driver = {
+		.name = "pwm-visconti",
+		.of_match_table = visconti_pwm_of_match,
+	},
+	.probe = visconti_pwm_probe,
+	.remove = visconti_pwm_remove,
+};
+module_platform_driver(visconti_pwm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>");
+MODULE_ALIAS("platform:pwm-visconti");
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Sun Apr 18 12:09:02 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Sun, 18 Apr 2021 20:09:02 +0900
Subject: [PATCH v5 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Message-ID: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation and device driver.

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

Updates:

  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
    v4 -> v5:
      - No update.
    v3 -> v4:
      - No update.
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm
      - Change filename to toshiba,visconti-pwm.yaml.
      - Add Reviewed-by tag from Rob.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
      - Set compatible toshiba,pwm-visconti only.
      - Drop unnecessary comments.

  pwm: visconti: Add Toshiba Visconti SoC PWM support
    v4 -> v5:
      - Droped checking PIPGM_PCSR from visconti_pwm_get_state.
      - Changed from to_visconti_chip to visconti_pwm_from_chip.
      - Removed pwmchip_remove return value management.
      - Add limitations of this device.
      - Add 'state->enabled = true' to visconti_pwm_get_state().
    v3 -> v4:
      - Sorted alphabetically include files.
      - Changed container_of to using static inline functions.
      - Dropped unnecessary dev_dbg().
      - Drop Initialization of chip.base.
      - Drop commnet "period too small".
      - Rebased for-next. 
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm.
      - Fix MODULE_ALIAS to platform:pwm-visconti, again.
      - Align continuation line to the opening parenthesis.
      - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only.
      - Add prefix for the register defines.
      - Drop struct device from struct visconti_pwm_chip.
      - Use '>>' instead of '/'.
      - Drop error message by devm_platform_ioremap_resource().
      - Use dev_err_probe instead of dev_err.
      - Change dev_info to dev_dbg.
      - Remove some empty lines.
      - Fix MODULE_ALIAS to platform:pwm-visconti.
      - Add .get_state() function.
      - Use the author name and email address to MODULE_AUTHOR.
      - Add more comment to function of the hardware.
      - Support .get_status() function.
      - Use NSEC_PER_USEC instead of 1000.
      - Alphabetically sorted for Makefile and Kconfig.
      - Added check for set value in visconti_pwm_apply().

Nobuhiro Iwamatsu (2):
  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
  pwm: visconti: Add Toshiba Visconti SoC PWM support

 .../bindings/pwm/toshiba,pwm-visconti.yaml    |  43 ++++
 drivers/pwm/Kconfig                           |   9 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-visconti.c                    | 188 ++++++++++++++++++
 4 files changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
 create mode 100644 drivers/pwm/pwm-visconti.c

-- 
2.30.0.rc2


From ilias.apalodimas at linaro.org  Sun Apr 18 12:21:21 2021
From: ilias.apalodimas at linaro.org (Ilias Apalodimas)
Date: Sun, 18 Apr 2021 14:21:21 +0300
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417202240.GS2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <YHspptFx+T588KcG@apalos.home>
 <20210417202240.GS2531743@casper.infradead.org>
Message-ID: <YHwWMfgqiRaKS2y6@apalos.home>

On Sat, Apr 17, 2021 at 09:22:40PM +0100, Matthew Wilcox wrote:
> On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> > > +{
> > > +	page->dma_addr[0] = addr;
> > > +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > > +		page->dma_addr[1] = addr >> 16 >> 16;
> > 
> > The 'error' that was reported will never trigger right?
> > I assume this was compiled with dma_addr_t as 32bits (so it triggered the
> > compilation error), but the if check will never allow this codepath to run.
> > If so can we add a comment explaining this, since none of us will remember why
> > in 6 months from now?
> 
> That's right.  I compiled it all three ways -- 32-bit, 64-bit dma, 32-bit long
> and 64-bit.  The 32/64 bit case turn into:
> 
> 	if (0)
> 		page->dma_addr[1] = addr >> 16 >> 16;
> 
> which gets elided.  So the only case that has to work is 64-bit dma and
> 32-bit long.
> 
> I can replace this with upper_32_bits().
> 

Ok up to you, I don't mind either way and thanks for solving this!

Acked-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>


From frank-w at public-files.de  Sun Apr 18 13:03:48 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Sun, 18 Apr 2021 14:03:48 +0200
Subject: Aw: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <20210320080646.49615-1-linux@fw-web.de>
References: <20210320080646.49615-1-linux@fw-web.de>
Message-ID: <trinity-93ab11dc-32c6-4e6b-8617-6bfff1a1b42d-1618747428085@3c-app-gmx-bap31>

Hi,

any opinion (except typo)?

thermanl => thermal

regards Frank


> Gesendet: Samstag, 20. M?rz 2021 um 10:06 Uhr
> Von: "Frank Wunderlich" <linux at fw-web.de>
> add HWMON-support to mediateks thermanl driver to allow lm-sensors
> userspace tools read soc temperature



From jan.kiszka at web.de  Sun Apr 18 13:12:04 2021
From: jan.kiszka at web.de (Jan Kiszka)
Date: Sun, 18 Apr 2021 14:12:04 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
 <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
Message-ID: <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>

On 01.04.21 16:52, Jan Kiszka wrote:
> On 01.04.21 13:42, Michal Simek wrote:
>> Hi Jan,
>>
>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>> Add clock nodes for zynqmp based on CCF.
>>>>
>>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>>> ---
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>> new file mode 100644
>>>> index 0000000..9868ca1
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>> @@ -0,0 +1,222 @@
>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>> +/*
>>>> + * Clock specification for Xilinx ZynqMP
>>>> + *
>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>> + *
>>>> + * Michal Simek <michal.simek at xilinx.com>
>>>> + */
>>>> +
>>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>>> +/ {
>>>> +	pss_ref_clk: pss_ref_clk {
>>>> +		u-boot,dm-pre-reloc;
>>>> +		compatible = "fixed-clock";
>>>> +		#clock-cells = <0>;
>>>> +		clock-frequency = <33333333>;
>>>> +	};
>>>> +
>>>> +	video_clk: video_clk {
>>>> +		u-boot,dm-pre-reloc;
>>>> +		compatible = "fixed-clock";
>>>> +		#clock-cells = <0>;
>>>> +		clock-frequency = <27000000>;
>>>> +	};
>>>> +
>>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>>> +		u-boot,dm-pre-reloc;
>>>> +		compatible = "fixed-clock";
>>>> +		#clock-cells = <0>;
>>>> +		clock-frequency = <0>;
>>>> +	};
>>>> +
>>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>>> +		u-boot,dm-pre-reloc;
>>>> +		compatible = "fixed-clock";
>>>> +		#clock-cells = <0>;
>>>> +		clock-frequency = <108000000>;
>>>> +	};
>>>> +
>>>> +	aux_ref_clk: aux_ref_clk {
>>>> +		u-boot,dm-pre-reloc;
>>>> +		compatible = "fixed-clock";
>>>> +		#clock-cells = <0>;
>>>> +		clock-frequency = <27000000>;
>>>> +	};
>>>> +};
>>>> +
>>>> +&can0 {
>>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&can1 {
>>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&cpu0 {
>>>> +	clocks = <&zynqmp_clk ACPU>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan1 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan2 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan3 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan4 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan5 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan6 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan7 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&fpd_dma_chan8 {
>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan1 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan2 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan3 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan4 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan5 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan6 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan7 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&lpd_dma_chan8 {
>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&gem0 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>> +};
>>>> +
>>>> +&gem1 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>> +};
>>>> +
>>>> +&gem2 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>> +};
>>>> +
>>>> +&gem3 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>> +};
>>>> +
>>>> +&gpio {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&i2c0 {
>>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>>> +};
>>>> +
>>>> +&i2c1 {
>>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>>> +};
>>>> +
>>>> +&pcie {
>>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>>> +};
>>>> +
>>>> +&sata {
>>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>>> +};
>>>> +
>>>> +&sdhci0 {
>>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&sdhci1 {
>>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&spi0 {
>>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&spi1 {
>>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&ttc0 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&ttc1 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&ttc2 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&ttc3 {
>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&uart0 {
>>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&uart1 {
>>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>> +};
>>>> +
>>>> +&usb0 {
>>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>> +};
>>>> +
>>>> +&usb1 {
>>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>> +};
>>>> +
>>>> +&watchdog0 {
>>>> +	clocks = <&zynqmp_clk WDT>;
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>> index 0f7b4cf..2e05fa4 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZC1232
>>>>   *
>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>
>>>>  / {
>>>>  	model = "ZynqMP ZC1232 RevA";
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>> index 9092828..3d0aaa0 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZC1254
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>> @@ -11,7 +11,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>
>>>>  / {
>>>>  	model = "ZynqMP ZC1254 RevA";
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>> index 4f404c5..1a8127d4 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>> @@ -11,7 +11,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>
>>>>  / {
>>>>  	model = "ZynqMP ZC1275 RevA";
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>> index 9a3e39d..fa7eb1b 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>>  / {
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>> index 2421ec7..4191dfa 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>>  / {
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>> index 7a49dee..3750690 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>>   *
>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>
>>>>  / {
>>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>> index 54c7b4f..2366cd9 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>
>>>>  / {
>>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>> index b8b5ff1..9a894e6 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>> @@ -11,7 +11,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>>  / {
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> index e5699d0..3e39454 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>>   *
>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   * Nathalie Chan King Choy
>>>> @@ -11,7 +11,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/input/input.h>
>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>> index 2a3b665..f6e9558 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>>   *
>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/input/input.h>
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>> index 8f45614..f457f8a 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZCU104
>>>>   *
>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>>  / {
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>> index 93ce7eb..f15b99a 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZCU106
>>>>   *
>>>> - * (C) Copyright 2016, Xilinx, Inc.
>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/input/input.h>
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>> index 8bb0001..e27cd60 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP ZCU111
>>>>   *
>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   */
>>>> @@ -10,7 +10,7 @@
>>>>  /dts-v1/;
>>>>
>>>>  #include "zynqmp.dtsi"
>>>> -#include "zynqmp-clk.dtsi"
>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>  #include <dt-bindings/input/input.h>
>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>
>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> index 9aa6734..59a547b 100644
>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>> @@ -2,7 +2,7 @@
>>>>  /*
>>>>   * dts file for Xilinx ZynqMP
>>>>   *
>>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>>   *
>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>   *
>>>> @@ -124,6 +124,28 @@
>>>>  			     <1 10 0xf08>;
>>>>  	};
>>>>
>>>> +	firmware {
>>>> +		zynqmp_firmware: zynqmp-firmware {
>>>> +			compatible = "xlnx,zynqmp-firmware";
>>>> +			method = "smc";
>>>> +			zynqmp_clk: clock-controller {
>>>> +				u-boot,dm-pre-reloc;
>>>> +				#clock-cells = <1>;
>>>> +				compatible = "xlnx,zynqmp-clk";
>>>> +				clocks = <&pss_ref_clk>,
>>>> +					 <&video_clk>,
>>>> +					 <&pss_alt_ref_clk>,
>>>> +					 <&aux_ref_clk>,
>>>> +					 <&gt_crx_ref_clk>;
>>>> +				clock-names = "pss_ref_clk",
>>>> +					      "video_clk",
>>>> +					      "pss_alt_ref_clk",
>>>> +					      "aux_ref_clk",
>>>> +					      "gt_crx_ref_clk";
>>>> +			};
>>>> +		};
>>>> +	};
>>>> +
>>>>  	amba_apu: amba-apu at 0 {
>>>>  		compatible = "simple-bus";
>>>>  		#address-cells = <2>;
>>>>
>>>
>>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>>> Starting from this commit on, I'm no longer getting the kernel to boot
>>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>>> DTBs back before this commit, even a kernel from today's head is fine.
>>>
>>> Further versions of potential relevance:
>>>  - PMUFW 2019.1 and 2020.2
>>>  - TF-A 2.3
>>>  - U-Boot 2020.10
>>>
>>> What's missing? I suspect someone forgot to document a subtle dependency
>>> of this change.
>>
>> Does this fix your issue?
>> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>>
>
> Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
> missing even more. If you have some reference, I'm happy to try. I
> suspect that earlyprintk will also not reveal more without clocks (but I
> didn't play with that yet).
>
> Meanwhile, I'm carrying a revert of this commit and a related cleanup.
> That helps for now.
>

OK, dependencies resolved (unfortunately the hard way): It either
requires TF-A master or latest release v2.4 + [1] and [2].

Those TF-A commits were upstream about a year after the firmware-based
clock control hit the kernel. A note would have been nice - or better
sychronization between both upstreaming efforts.

Jan

[1]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=c23cf053037ecc4521a7e03ba0100f1c78afd580
[2]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=a8b10c6490e5a4656bfa06fae5c0f19fabfe4ab2


From u.kleine-koenig at pengutronix.de  Sun Apr 18 14:44:11 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Sun, 18 Apr 2021 15:44:11 +0200
Subject: [PATCH v5 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210418110904.1942806-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210418110904.1942806-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210418134411.vfltokielrwuygqa@pengutronix.de>

Hello,

just a few smaller issues left to fix.

On Sun, Apr 18, 2021 at 08:09:04PM +0900, Nobuhiro Iwamatsu wrote:
> diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> new file mode 100644
> index 000000000000..166b18ac1a3a
> --- /dev/null
> +++ b/drivers/pwm/pwm-visconti.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Toshiba Visconti pulse-width-modulation controller driver
> + *
> + * Copyright (c) 2020 TOSHIBA CORPORATION
> + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation

We're in 2021, so you might want to adapt the year in the copy right
notice.

> + *
> + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> + *
> + * Limitations:
> + * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8).

This is too detailed for the purpose of this section. Please either drop
it or make this:

 - The fixed input clock is running at 1 MHz and is divided by either 1,
   2, 4 or 8.

> + * - Fixed input clock running at 1 MHz.
> + * - When the settings of the PWM are modified, the new values are shadowed
> + *   in hardware until the PIPGM_PCSR register is written and the currently
> + *   running period is completed. This way the hardware switches atomically
> + *   from the old setting to the new.
> + * - Disabling the hardware completes the currently running period and keeps
> + *   the output at low level at all times.
> + */
> +
> [...]
> +	/*
> +	 * PWMC controls a divider that divides the input clk by a
> +	 * power of two between 1 and 8. As a smaller divider yields
> +	 * higher precision, pick the smallest possible one.
> +	 */
> +	if (period > 0xffff) {
> +		pwmc0 = ilog2(period >> 16);
> +		BUG_ON(pwmc0 > 3);
> +	} else
> +		pwmc0 = 0;

The linux coding style mandates that you should use braces for both
branches. (i.e.

+	if (period > 0xffff) {
+		pwmc0 = ilog2(period >> 16);
+		BUG_ON(pwmc0 > 3);
+	} else {
+		pwmc0 = 0;
+	}
)

> +	period >>= pwmc0;
> +	duty_cycle >>= pwmc0;
> +
> +	if (state->polarity == PWM_POLARITY_INVERSED)
> +		pwmc0 |= PIPGM_PWMC_PWMACT;
> +	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> +	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> +	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +
> +	return 0;
> +}

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/20210418/09c54068/attachment.sig>

From jszhang3 at mail.ustc.edu.cn  Sun Apr 18 14:52:31 2021
From: jszhang3 at mail.ustc.edu.cn (Jisheng Zhang)
Date: Sun, 18 Apr 2021 21:52:31 +0800
Subject: [PATCH] arm64: remove HAVE_DEBUG_BUGVERBOSE
Message-ID: <20210418215231.563d4b72@xhacker>

From: Jisheng Zhang <jszhang at kernel.org>

After commit 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic
BUG traps"), arm64 has switched to generic BUG implementation, so
there's no need to select HAVE_DEBUG_BUGVERBOSE.

Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..f0e6ee157840 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -159,7 +159,6 @@ config ARM64
 	select HAVE_CMPXCHG_DOUBLE
 	select HAVE_CMPXCHG_LOCAL
 	select HAVE_CONTEXT_TRACKING
-	select HAVE_DEBUG_BUGVERBOSE
 	select HAVE_DEBUG_KMEMLEAK
 	select HAVE_DMA_CONTIGUOUS
 	select HAVE_DYNAMIC_FTRACE
-- 
2.31.0




From arnd at kernel.org  Sun Apr 18 20:23:10 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sun, 18 Apr 2021 21:23:10 +0200
Subject: ARM SoC fixes for v5.12, part 2
Message-ID: <CAK8P3a3h0QDvv-0yTVOMjx-8vUUcAFTQ6di71b2DwCELHNpPLw@mail.gmail.com>

The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:

  Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-fixes-5.12-3

for you to fetch changes up to b9a9786a13ea158ee3b23614217f2e3158178421:

  Merge tag 'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/fixes (2021-04-08 17:56:09 +0200)

----------------------------------------------------------------
ARM SoC fixes for v5.12, part 2

Another smaller set of fixes for three of the Arm platforms:

TI OMAP:

    Fix swapped mmc device order also for omap3 that got changed with the
    recent PROBE_PREFER_ASYNCHRONOUS changes. While eventually the aliases
    should be board specific, all the mmc device instances are all there in
    the SoC, and we do probe them by default so that PM runtime can idle the
    devices if left enabled from the bootloader.

Qualcomm Snapdragon:

    This bypasses the, recently introduced, interconnect handling in the
    GENI (serial engine) driver when running off ACPI, as this causes the
    GENI probe to fail and the Lenovo Yoga C630 to boot without keyboard
    and touchpad.

Allwinner:

    One 32kHz clock fix for the beelink gs1, a CD polarity fix for the SoPine,
    some MAINTAINERS maintainance, and a clk / reset switch to our headers.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Andre Przywara (1):
      arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems

Arnd Bergmann (3):
      Merge tag 'sunxi-fixes-for-5.12-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into
arm/fixes
      Merge tag 'qcom-drivers-fixes-for-5.12' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/fixes
      Merge tag 'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/fixes

Chen-Yu Tsai (1):
      arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices

Jernej Skrabec (1):
      arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference

Maxime Ripard (2):
      MAINTAINERS: Add our new mailing-list
      MAINTAINERS: Match on allwinner keyword

Shawn Guo (1):
      soc: qcom: geni: shield geni_icc_get() for ACPI boot

Tony Lindgren (3):
      ARM: OMAP2+: Fix warning for omap_init_time_of()
      ARM: dts: Fix swapped mmc order for omap3
      ARM: OMAP2+: Fix uninitialized sr_inst

 MAINTAINERS                                             | 2 ++
 arch/arm/boot/dts/omap3.dtsi                            | 3 +++
 arch/arm/mach-omap2/board-generic.c                     | 2 +-
 arch/arm/mach-omap2/sr_device.c                         | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 4 ++++
 arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi    | 2 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 ----
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi            | 4 ++--
 drivers/soc/qcom/qcom-geni-se.c                         | 3 +++
 9 files changed, 17 insertions(+), 9 deletions(-)


From arnd at kernel.org  Sun Apr 18 20:24:27 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Sun, 18 Apr 2021 21:24:27 +0200
Subject: [GIT PULL] Re: ARM SoC fixes for v5.12, part 2
In-Reply-To: <CAK8P3a3h0QDvv-0yTVOMjx-8vUUcAFTQ6di71b2DwCELHNpPLw@mail.gmail.com>
References: <CAK8P3a3h0QDvv-0yTVOMjx-8vUUcAFTQ6di71b2DwCELHNpPLw@mail.gmail.com>
Message-ID: <CAK8P3a3oQm7P=Mj2xU=8v=g82mN-OXk7yrPmFMcK0XpMpwRctg@mail.gmail.com>

I forgot to add the '[GIT PULL]' in the subject line, replying to myself
here to ensure it hits the right email folder.

On Sun, Apr 18, 2021 at 9:23 PM Arnd Bergmann <arnd at kernel.org> wrote:
>
> The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:
>
>   Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
> tags/arm-fixes-5.12-3
>
> for you to fetch changes up to b9a9786a13ea158ee3b23614217f2e3158178421:
>
>   Merge tag 'omap-for-v5.12/fixes-rc6-signed' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
> arm/fixes (2021-04-08 17:56:09 +0200)
>
> ----------------------------------------------------------------
> ARM SoC fixes for v5.12, part 2
>
> Another smaller set of fixes for three of the Arm platforms:
>
> TI OMAP:
>
>     Fix swapped mmc device order also for omap3 that got changed with the
>     recent PROBE_PREFER_ASYNCHRONOUS changes. While eventually the aliases
>     should be board specific, all the mmc device instances are all there in
>     the SoC, and we do probe them by default so that PM runtime can idle the
>     devices if left enabled from the bootloader.
>
> Qualcomm Snapdragon:
>
>     This bypasses the, recently introduced, interconnect handling in the
>     GENI (serial engine) driver when running off ACPI, as this causes the
>     GENI probe to fail and the Lenovo Yoga C630 to boot without keyboard
>     and touchpad.
>
> Allwinner:
>
>     One 32kHz clock fix for the beelink gs1, a CD polarity fix for the SoPine,
>     some MAINTAINERS maintainance, and a clk / reset switch to our headers.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>


From martin.blumenstingl at googlemail.com  Sun Apr 18 21:08:11 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Sun, 18 Apr 2021 22:08:11 +0200
Subject: 2021 Amlogic SoCs Features Status
In-Reply-To: <f13f7006-2d0c-40c7-cea6-03b5190fd106@baylibre.com>
References: <f13f7006-2d0c-40c7-cea6-03b5190fd106@baylibre.com>
Message-ID: <CAFBinCB6WLo1-kMMTC112tdBmdcJ=q2rpih56J1SfOX78xeEiw@mail.gmail.com>

Hi Neil,

thank you for this summary!

On Thu, Apr 15, 2021 at 4:29 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
[...]
> I would like to thanks all the contributors (code, test, bug reports, ...) for the last
> 4,5 years !
Indeed, thanks to everyone who helped to get where we are right now!

[...]
> ## Meson6 / Meson8 / Meson8b
>
> I'll let martin elaborate on that, but it seems the biggest missing bits are Display, Video Decoder & Encoder support.
Meson6: unknown status, I don't have any hardware so YMMV
Meson8: similar status as Meson8b/Meson8m2 as these SoCs are almost
identical. The only known differences are Ethernet (Meson8 and Meson6
use the same Ethernet IP, while Meson8b and Meson8m2 use a newer IP ->
same as found on GXBB) and some clocks (which means that Meson8 cannot
change the GPU clock at runtime for example because the glitch-free
mux is absent)

Meson8b/Meson8m2:
video output:
1. I need to re-spin and re-test my CCF series which makes the video
clock tree mutable. This means I need to use the PLL initialization
"magic registers" to set the PLL to the "doubling" mode
2. some of the existing DRM driver code needs to be converted to a
bridge so I don't have to duplicate the non-dw-HDMI part of
meson_dw_hdmi.c
3. 1080P and lower video modes are working with my out-of-tree driver
for me. upstreaming this driver will require multiple rounds of
reviews as this includes a driver for the TransSwitch HDMI controller
IP (not just the Amlogic part)
4. cleanup of the DRM patches sitting in my tree

HDMI CEC:
- untested, but I hope that it's similar enough to GXBB so it works
without too much effort

audio output:
- in my tests SPDIF output is working fine
- I2S over HDMI also worked "fine" in my (2-channel) tests. I expect
that it'll suffer from the MGN issue as GXBB, GXL and GXM
- for boards where the analog output path is known this can be made to
work. I did some experiments on my EC-100 some time ago where I could
get it to work. but I was unsuccessful with the analog out on other
boards

video encoders/decoders:
- according to what Maxime told me some time ago this should be very
similar to GXBB but I have not done any experiments so far

once implemented for any of Meson8/Meson8b/Meson8m2/GXBB we'll get it
for the "other" SoCs for free:
- IR hardware decoding
- USB OTG


Best regards,
Martin


From martin.blumenstingl at googlemail.com  Sun Apr 18 21:15:51 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Sun, 18 Apr 2021 22:15:51 +0200
Subject: [PATCH v2 2/3] arm64: dts: meson: add saradc node to ODROID N2/N2+
In-Reply-To: <20210407042609.9736-3-christianshewitt@gmail.com>
References: <20210407042609.9736-1-christianshewitt@gmail.com>
 <20210407042609.9736-3-christianshewitt@gmail.com>
Message-ID: <CAFBinCAL1zpcNm5VdbwpwZM1DPvfhnx0+npZvs8Hi5DOLz+7kA@mail.gmail.com>

On Wed, Apr 7, 2021 at 6:27 AM Christian Hewitt
<christianshewitt at gmail.com> wrote:
>
> From: Hyeonki Hong <hhk7734 at gmail.com>
>
> Add the meson saradc node to the ODROID N2/N2+ common dtsi.
>
> Signed-off-by: Hyeonki Hong <hhk7734 at gmail.com>
> Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From martin.blumenstingl at googlemail.com  Sun Apr 18 21:16:21 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Sun, 18 Apr 2021 22:16:21 +0200
Subject: [PATCH v2 3/3] arm64: dts: meson: add GPIO line names to ODROID
 N2/N2+
In-Reply-To: <20210407042609.9736-4-christianshewitt@gmail.com>
References: <20210407042609.9736-1-christianshewitt@gmail.com>
 <20210407042609.9736-4-christianshewitt@gmail.com>
Message-ID: <CAFBinCAhC6c-Q5Hhmb60TCeokJ805ep20WBCfzmctqxArS=eng@mail.gmail.com>

On Wed, Apr 7, 2021 at 6:27 AM Christian Hewitt
<christianshewitt at gmail.com> wrote:
>
> From: Hyeonki Hong <hhk7734 at gmail.com>
>
> Add GPIO line-name identifiers to the ODROID N2/N2+ common dtsi.
>
> Signed-off-by: Hyeonki Hong <hhk7734 at gmail.com>
> Signed-off-by: Christian Hewitt <christianshewitt at gmail.com>
> Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From torvalds at linux-foundation.org  Sun Apr 18 21:36:13 2021
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Sun, 18 Apr 2021 13:36:13 -0700
Subject: [GIT PULL] Re: ARM SoC fixes for v5.12, part 2
In-Reply-To: <CAK8P3a3oQm7P=Mj2xU=8v=g82mN-OXk7yrPmFMcK0XpMpwRctg@mail.gmail.com>
References: <CAK8P3a3h0QDvv-0yTVOMjx-8vUUcAFTQ6di71b2DwCELHNpPLw@mail.gmail.com>
 <CAK8P3a3oQm7P=Mj2xU=8v=g82mN-OXk7yrPmFMcK0XpMpwRctg@mail.gmail.com>
Message-ID: <CAHk-=wgNrFFVxF-9g1bjRZaG2OL4Big1_aKTMFyGagrhVNx2Kw@mail.gmail.com>

On Sun, Apr 18, 2021 at 12:24 PM Arnd Bergmann <arnd at kernel.org> wrote:
>
> I forgot to add the '[GIT PULL]' in the subject line, replying to myself
> here to ensure it hits the right email folder.

Well, the reply hit _my_ search criterion, but the pr-tracker-bot is a
bit more picky.

As a result, I don't think you'll get any automated reply from the bot.

So here's the manual one,

               Linus


From uwe at kleine-koenig.org  Sun Apr 18 21:57:47 2021
From: uwe at kleine-koenig.org (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Sun, 18 Apr 2021 22:57:47 +0200
Subject: [PATCH] pwm: atmel: Fix duty cycle calculation in .get_state()
Message-ID: <20210418205747.1488248-1-uwe@kleine-koenig.org>

The CDTY register contains the number of inactive cycles. .apply() does
this correctly, however .get_state got this wrong.

Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()")
Signed-off-by: Uwe Kleine-K?nig <uwe at kleine-koenig.org>
---
 drivers/pwm/pwm-atmel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index d49da708337f..c30a0dac4b2d 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -319,7 +319,7 @@ static void atmel_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		cdty = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
 					  atmel_pwm->data->regs.duty);
-		tmp = (u64)cdty * NSEC_PER_SEC;
+		tmp = (u64)(cdty - cprd) * NSEC_PER_SEC;
 		tmp <<= pres;
 		state->duty_cycle = DIV64_U64_ROUND_UP(tmp, rate);
 
-- 
2.30.2



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 00:20:01 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 08:20:01 +0900
Subject: [PATCH v5 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210418134411.vfltokielrwuygqa@pengutronix.de>
References: <20210418110904.1942806-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210418110904.1942806-3-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210418134411.vfltokielrwuygqa@pengutronix.de>
Message-ID: <20210418232001.lvx7ho2qo2ac2khy@toshiba.co.jp>

Hi Uwe,

Thanks for your review.

On Sun, Apr 18, 2021 at 03:44:11PM +0200, Uwe Kleine-K?nig wrote:
> Hello,
> 
> just a few smaller issues left to fix.
> 
> On Sun, Apr 18, 2021 at 08:09:04PM +0900, Nobuhiro Iwamatsu wrote:
> > diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
> > new file mode 100644
> > index 000000000000..166b18ac1a3a
> > --- /dev/null
> > +++ b/drivers/pwm/pwm-visconti.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Toshiba Visconti pulse-width-modulation controller driver
> > + *
> > + * Copyright (c) 2020 TOSHIBA CORPORATION
> > + * Copyright (c) 2020 Toshiba Electronic Devices & Storage Corporation
> 
> We're in 2021, so you might want to adapt the year in the copy right
> notice.

OK, I will update.

> 
> > + *
> > + * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> > + *
> > + * Limitations:
> > + * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8).
> 
> This is too detailed for the purpose of this section. Please either drop
> it or make this:
> 
>  - The fixed input clock is running at 1 MHz and is divided by either 1,
>    2, 4 or 8.


OK, I will add your sugggestion.

> 
> > + * - Fixed input clock running at 1 MHz.
> > + * - When the settings of the PWM are modified, the new values are shadowed
> > + *   in hardware until the PIPGM_PCSR register is written and the currently
> > + *   running period is completed. This way the hardware switches atomically
> > + *   from the old setting to the new.
> > + * - Disabling the hardware completes the currently running period and keeps
> > + *   the output at low level at all times.
> > + */
> > +
> > [...]
> > +	/*
> > +	 * PWMC controls a divider that divides the input clk by a
> > +	 * power of two between 1 and 8. As a smaller divider yields
> > +	 * higher precision, pick the smallest possible one.
> > +	 */
> > +	if (period > 0xffff) {
> > +		pwmc0 = ilog2(period >> 16);
> > +		BUG_ON(pwmc0 > 3);
> > +	} else
> > +		pwmc0 = 0;
> 
> The linux coding style mandates that you should use braces for both
> branches. (i.e.
> 
> +	if (period > 0xffff) {
> +		pwmc0 = ilog2(period >> 16);
> +		BUG_ON(pwmc0 > 3);
> +	} else {
> +		pwmc0 = 0;
> +	}
> )

Oh, I fotgot it, I will fix this. Thanks you.

> 
> > +	period >>= pwmc0;
> > +	duty_cycle >>= pwmc0;
> > +
> > +	if (state->polarity == PWM_POLARITY_INVERSED)
> > +		pwmc0 |= PIPGM_PWMC_PWMACT;
> > +	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> > +	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> > +	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> > +
> > +	return 0;
> > +}
> 
> Best regards
> Uwe


Best regards,
  Nobuhiro



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 01:00:07 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 09:00:07 +0900
Subject: [PATCH v6 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419000007.1944301-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add driver for the PWM controller on Toshiba Visconti ARM SoC.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pwm/Kconfig        |   9 ++
 drivers/pwm/Makefile       |   1 +
 drivers/pwm/pwm-visconti.c | 189 +++++++++++++++++++++++++++++++++++++
 3 files changed, 199 insertions(+)
 create mode 100644 drivers/pwm/pwm-visconti.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 9a4f66ae8070..8ae68d6203fb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -601,6 +601,15 @@ config PWM_TWL_LED
 	  To compile this driver as a module, choose M here: the module
 	  will be called pwm-twl-led.
 
+config PWM_VISCONTI
+	tristate "Toshiba Visconti PWM support"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	help
+	  PWM Subsystem driver support for Toshiba Visconti SoCs.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called pwm-visconti.
+
 config PWM_VT8500
 	tristate "vt8500 PWM support"
 	depends on ARCH_VT8500 || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 6374d3b1d6f3..d43b1e17e8e1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -56,4 +56,5 @@ obj-$(CONFIG_PWM_TIECAP)	+= pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM)	+= pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL)		+= pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)	+= pwm-twl-led.o
+obj-$(CONFIG_PWM_VISCONTI)	+= pwm-visconti.o
 obj-$(CONFIG_PWM_VT8500)	+= pwm-vt8500.o
diff --git a/drivers/pwm/pwm-visconti.c b/drivers/pwm/pwm-visconti.c
new file mode 100644
index 000000000000..beecadda566a
--- /dev/null
+++ b/drivers/pwm/pwm-visconti.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Toshiba Visconti pulse-width-modulation controller driver
+ *
+ * Copyright (c) 2020 - 2021 TOSHIBA CORPORATION
+ * Copyright (c) 2020 - 2021 Toshiba Electronic Devices & Storage Corporation
+ *
+ * Authors: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ * Limitations:
+ * - The fixed input clock is running at 1 MHz and is divided by either 1,
+ *   2, 4 or 8.
+ * - When the settings of the PWM are modified, the new values are shadowed
+ *   in hardware until the PIPGM_PCSR register is written and the currently
+ *   running period is completed. This way the hardware switches atomically
+ *   from the old setting to the new.
+ * - Disabling the hardware completes the currently running period and keeps
+ *   the output at low level at all times.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+#define PIPGM_PCSR(ch) (0x400 + 4 * (ch))
+#define PIPGM_PDUT(ch) (0x420 + 4 * (ch))
+#define PIPGM_PWMC(ch) (0x440 + 4 * (ch))
+
+#define PIPGM_PWMC_PWMACT		BIT(5)
+#define PIPGM_PWMC_CLK_MASK		GENMASK(1, 0)
+#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);
+}
+
+static int visconti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+			      const struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = visconti_pwm_from_chip(chip);
+	u32 period, duty_cycle, pwmc0;
+
+	if (!state->enabled) {
+		writel(0, priv->base + PIPGM_PCSR(pwm->hwpwm));
+		return 0;
+	}
+
+	/*
+	 * The biggest period the hardware can provide is
+	 *	(0xffff << 3) * 1000 ns
+	 * This value fits easily in an u32, so simplify the maths by
+	 * capping the values to 32 bit integers.
+	 */
+	if (state->period > (0xffff << 3) * 1000)
+		period = (0xffff << 3) * 1000;
+	else
+		period = state->period;
+
+	if (state->duty_cycle > period)
+		duty_cycle = period;
+	else
+		duty_cycle = state->duty_cycle;
+
+	/*
+	 * The input clock runs fixed at 1 MHz, so we have only
+	 * microsecond resolution and so can divide by
+	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
+	 */
+	period /= 1000;
+	duty_cycle /= 1000;
+
+	if (!period)
+		return -ERANGE;
+
+	/*
+	 * PWMC controls a divider that divides the input clk by a
+	 * power of two between 1 and 8. As a smaller divider yields
+	 * higher precision, pick the smallest possible one.
+	 */
+	if (period > 0xffff) {
+		pwmc0 = ilog2(period >> 16);
+		BUG_ON(pwmc0 > 3);
+	} else {
+		pwmc0 = 0;
+	}
+
+	period >>= pwmc0;
+	duty_cycle >>= pwmc0;
+
+	if (state->polarity == PWM_POLARITY_INVERSED)
+		pwmc0 |= PIPGM_PWMC_PWMACT;
+	writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
+	writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
+	writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
+
+	return 0;
+}
+
+static void visconti_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+				   struct pwm_state *state)
+{
+	struct visconti_pwm_chip *priv = visconti_pwm_from_chip(chip);
+	u32 period, duty, pwmc0, pwmc0_clk;
+
+	period = readl(priv->base + PIPGM_PCSR(pwm->hwpwm));
+	duty = readl(priv->base + PIPGM_PDUT(pwm->hwpwm));
+	pwmc0 = readl(priv->base + PIPGM_PWMC(pwm->hwpwm));
+	pwmc0_clk = pwmc0 & PIPGM_PWMC_CLK_MASK;
+
+	state->period = (period << pwmc0_clk) * NSEC_PER_USEC;
+	state->duty_cycle = (duty << pwmc0_clk) * NSEC_PER_USEC;
+	if (pwmc0 & PIPGM_PWMC_POLARITY_MASK)
+		state->polarity = PWM_POLARITY_INVERSED;
+	else
+		state->polarity = PWM_POLARITY_NORMAL;
+
+	state->enabled = true;
+}
+
+static const struct pwm_ops visconti_pwm_ops = {
+	.apply = visconti_pwm_apply,
+	.get_state = visconti_pwm_get_state,
+	.owner = THIS_MODULE,
+};
+
+static int visconti_pwm_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pwm_chip *priv;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->chip.dev = dev;
+	priv->chip.ops = &visconti_pwm_ops;
+	priv->chip.npwm = 4;
+
+	ret = pwmchip_add(&priv->chip);
+	if (ret < 0)
+		return dev_err_probe(&pdev->dev, ret, "Cannot register visconti PWM\n");
+
+	return 0;
+}
+
+static int visconti_pwm_remove(struct platform_device *pdev)
+{
+	struct visconti_pwm_chip *priv = platform_get_drvdata(pdev);
+
+	pwmchip_remove(&priv->chip);
+
+	return 0;
+}
+
+static const struct of_device_id visconti_pwm_of_match[] = {
+	{ .compatible = "toshiba,visconti-pwm", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, visconti_pwm_of_match);
+
+static struct platform_driver visconti_pwm_driver = {
+	.driver = {
+		.name = "pwm-visconti",
+		.of_match_table = visconti_pwm_of_match,
+	},
+	.probe = visconti_pwm_probe,
+	.remove = visconti_pwm_remove,
+};
+module_platform_driver(visconti_pwm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>");
+MODULE_ALIAS("platform:pwm-visconti");
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 01:00:06 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 09:00:06 +0900
Subject: [PATCH v6 1/2] dt-bindings: pwm: Add bindings for Toshiba Visconti
 PWM Controller
In-Reply-To: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419000007.1944301-2-nobuhiro1.iwamatsu@toshiba.co.jp>

Add bindings for the Toshiba Visconti PWM Controller.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pwm/toshiba,pwm-visconti.yaml    | 43 +++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml

diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
new file mode 100644
index 000000000000..d350f5edfb67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/toshiba,pwm-visconti.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti PWM Controller
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+properties:
+  compatible:
+    items:
+      - const: toshiba,visconti-pwm
+
+  reg:
+    maxItems: 1
+
+  '#pwm-cells':
+    const: 2
+
+required:
+  - compatible
+  - reg
+  - '#pwm-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pwm: pwm at 241c0000 {
+            compatible = "toshiba,visconti-pwm";
+            reg = <0 0x241c0000 0 0x1000>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&pwm_mux>;
+            #pwm-cells = <2>;
+        };
+    };
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 01:00:05 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 09:00:05 +0900
Subject: [PATCH v6 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Message-ID: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation and device driver.

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

Updates:

  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
    v5 -> v6:
      - No update.
    v4 -> v5:
      - No update.
    v3 -> v4:
      - No update.
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm
      - Change filename to toshiba,visconti-pwm.yaml.
      - Add Reviewed-by tag from Rob.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
      - Set compatible toshiba,pwm-visconti only.
      - Drop unnecessary comments.

  pwm: visconti: Add Toshiba Visconti SoC PWM support
    v5 -> v6:
     - Update year in copyright.
     - Update limitations.
     - Fix coding style, used braces for both branches.
    v4 -> v5:
      - Droped checking PIPGM_PCSR from visconti_pwm_get_state.
      - Changed from to_visconti_chip to visconti_pwm_from_chip.
      - Removed pwmchip_remove return value management.
      - Add limitations of this device.
      - Add 'state->enabled = true' to visconti_pwm_get_state().
    v3 -> v4:
      - Sorted alphabetically include files.
      - Changed container_of to using static inline functions.
      - Dropped unnecessary dev_dbg().
      - Drop Initialization of chip.base.
      - Drop commnet "period too small".
      - Rebased for-next. 
    v2 -> v3:
      - Change compatible to toshiba,visconti-pwm.
      - Fix MODULE_ALIAS to platform:pwm-visconti, again.
      - Align continuation line to the opening parenthesis.
      - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
    v1 -> v2:
      - Change SPDX-License-Identifier to GPL-2.0-only.
      - Add prefix for the register defines.
      - Drop struct device from struct visconti_pwm_chip.
      - Use '>>' instead of '/'.
      - Drop error message by devm_platform_ioremap_resource().
      - Use dev_err_probe instead of dev_err.
      - Change dev_info to dev_dbg.
      - Remove some empty lines.
      - Fix MODULE_ALIAS to platform:pwm-visconti.
      - Add .get_state() function.
      - Use the author name and email address to MODULE_AUTHOR.
      - Add more comment to function of the hardware.
      - Support .get_status() function.
      - Use NSEC_PER_USEC instead of 1000.
      - Alphabetically sorted for Makefile and Kconfig.
      - Added check for set value in visconti_pwm_apply().

Nobuhiro Iwamatsu (2):
  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
  pwm: visconti: Add Toshiba Visconti SoC PWM support

 .../bindings/pwm/toshiba,pwm-visconti.yaml    |  43 ++++
 drivers/pwm/Kconfig                           |   9 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-visconti.c                    | 189 ++++++++++++++++++
 4 files changed, 242 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
 create mode 100644 drivers/pwm/pwm-visconti.c

-- 
2.30.0.rc2



From valdis.kletnieks at vt.edu  Mon Apr 19 02:02:12 2021
From: valdis.kletnieks at vt.edu (Valdis =?utf-8?Q?Kl=c4=93tnieks?=)
Date: Sun, 18 Apr 2021 21:02:12 -0400
Subject: drivers/net/ethernet/mediatek/mtk_ppe_offload.c - suspicious code?
Message-ID: <526789.1618794132@turing-police>

While doing some code auditing for -Woverride_init, I spotted some questionable code

commit 502e84e2382d92654a2ecbc52cdbdb5a11cdcec7
Author: Felix Fietkau <nbd at nbd.name>
Date:   Wed Mar 24 02:30:54 2021 +0100

    net: ethernet: mtk_eth_soc: add flow offloading support

In drivers/net/ethernet/mediatek/mtk_ppe_offload.c:

+static const struct rhashtable_params mtk_flow_ht_params = {
+       .head_offset = offsetof(struct mtk_flow_entry, node),
+       .head_offset = offsetof(struct mtk_flow_entry, cookie),
+       .key_len = sizeof(unsigned long),
+       .automatic_shrinking = true,
+};

What's intended for head_offset here?

Christoph:  This was the only actual questionable code caught by override-init
across allmodconfig builds of arm, arm64, and x86_64. The other 218 warnings
not already silenced by Makefile twiddling of CFLAGS are all legitimate. I
admit not being sure what that means for its use in W=1 builds in general.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210418/c5771483/attachment-0001.sig>

From samuel at sholland.org  Mon Apr 19 02:45:49 2021
From: samuel at sholland.org (Samuel Holland)
Date: Sun, 18 Apr 2021 20:45:49 -0500
Subject: [PATCH] rtc: sun6i: Add NVMEM provider
Message-ID: <20210419014549.26900-1-samuel@sholland.org>

The sun6i RTC provides 32 bytes of general-purpose data registers.
They can be used to save data in the always-on RTC power domain.
The registers are writable via 32-bit MMIO accesses only.

Expose the region as a NVMEM provider so it can be used by userspace and
other drivers.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 drivers/rtc/rtc-sun6i.c | 42 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e75020ab8024..f4a5e7465148 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -69,6 +69,10 @@
 #define SUN6I_LOSC_OUT_GATING			0x0060
 #define SUN6I_LOSC_OUT_GATING_EN_OFFSET		0
 
+/* General-purpose data */
+#define SUN6I_GP_DATA				0x0100
+#define SUN6I_GP_DATA_SIZE			0x20
+
 /*
  * Get date values
  */
@@ -641,6 +645,39 @@ static const struct rtc_class_ops sun6i_rtc_ops = {
 	.alarm_irq_enable	= sun6i_rtc_alarm_irq_enable
 };
 
+static int sun6i_rtc_nvmem_read(void *priv, unsigned int offset, void *_val, size_t bytes)
+{
+	struct sun6i_rtc_dev *chip = priv;
+	u32 *val = _val;
+	int i;
+
+	for (i = 0; i < bytes / 4; ++i)
+		val[i] = readl(chip->base + SUN6I_GP_DATA + offset + 4 * i);
+
+	return 0;
+}
+
+static int sun6i_rtc_nvmem_write(void *priv, unsigned int offset, void *_val, size_t bytes)
+{
+	struct sun6i_rtc_dev *chip = priv;
+	u32 *val = _val;
+	int i;
+
+	for (i = 0; i < bytes / 4; ++i)
+		writel(val[i], chip->base + SUN6I_GP_DATA + offset + 4 * i);
+
+	return 0;
+}
+
+static struct nvmem_config sun6i_rtc_nvmem_cfg = {
+	.type		= NVMEM_TYPE_BATTERY_BACKED,
+	.reg_read	= sun6i_rtc_nvmem_read,
+	.reg_write	= sun6i_rtc_nvmem_write,
+	.size		= SUN6I_GP_DATA_SIZE,
+	.word_size	= 4,
+	.stride		= 4,
+};
+
 /* Enable IRQ wake on suspend, to wake up from RTC. */
 static int sun6i_rtc_suspend(struct device *dev)
 {
@@ -728,6 +765,11 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	sun6i_rtc_nvmem_cfg.priv = chip;
+	ret = devm_rtc_nvmem_register(chip->rtc, &sun6i_rtc_nvmem_cfg);
+	if (ret)
+		return ret;
+
 	dev_info(&pdev->dev, "RTC enabled\n");
 
 	return 0;
-- 
2.26.3



From samuel at sholland.org  Mon Apr 19 02:58:15 2021
From: samuel at sholland.org (Samuel Holland)
Date: Sun, 18 Apr 2021 20:58:15 -0500
Subject: [PATCH] nvmem: sunxi_sid: Set type to OTP
Message-ID: <20210419015815.38910-1-samuel@sholland.org>

This device currently reports an "Unknown" type in sysfs.
Since it is an eFuse hardware device, set its type to OTP.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 drivers/nvmem/sunxi_sid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index e26ef1bbf198..275b9155e473 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -142,6 +142,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 
 	nvmem_cfg->dev = dev;
 	nvmem_cfg->name = "sunxi-sid";
+	nvmem_cfg->type = NVMEM_TYPE_OTP;
 	nvmem_cfg->read_only = true;
 	nvmem_cfg->size = cfg->size;
 	nvmem_cfg->word_size = 1;
-- 
2.26.3



From tommyhebb at gmail.com  Mon Apr 19 03:03:04 2021
From: tommyhebb at gmail.com (Thomas Hebb)
Date: Sun, 18 Apr 2021 19:03:04 -0700
Subject: [RESEND PATCH] drm/rockchip: dsi: remove extra component_del() call
Message-ID: <201385acb0eeb5dfb037afdc6a94bfbcdab97f99.1618797778.git.tommyhebb@gmail.com>

commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added
this devcnt field and call to component_del(). However, these both
appear to be erroneous changes left over from an earlier version of the
patch. In the version merged, nothing ever modifies devcnt, meaning
component_del() runs unconditionally and in addition to the
component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second
call fails to delete anything and produces a warning in dmesg.

If we look at the previous version of the patch[1], however, we see that
it had logic to calculate devcnt and call component_add() in certain
situations. This was removed in v6, and the fact that the deletion code
was not appears to have been an oversight.

[1] https://patchwork.kernel.org/project/dri-devel/patch/20180821140515.22246-8-heiko at sntech.de/

Fixes: cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support")
Cc: stable at vger.kernel.org
Signed-off-by: Thomas Hebb <tommyhebb at gmail.com>
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 24a71091759c..8cc81d5b82f0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -243,7 +243,6 @@ struct dw_mipi_dsi_rockchip {
 	struct dw_mipi_dsi *dmd;
 	const struct rockchip_dw_dsi_chip_data *cdata;
 	struct dw_mipi_dsi_plat_data pdata;
-	int devcnt;
 };
 
 struct dphy_pll_parameter_map {
@@ -1121,9 +1120,6 @@ static int dw_mipi_dsi_rockchip_remove(struct platform_device *pdev)
 {
 	struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev);
 
-	if (dsi->devcnt == 0)
-		component_del(dsi->dev, &dw_mipi_dsi_rockchip_ops);
-
 	dw_mipi_dsi_remove(dsi->dmd);
 
 	return 0;
-- 
2.30.0



From tommyhebb at gmail.com  Mon Apr 19 03:04:10 2021
From: tommyhebb at gmail.com (Thomas Hebb)
Date: Sun, 18 Apr 2021 19:04:10 -0700
Subject: [RESEND PATCH] drm/rockchip: dsi: move all lane config except LCDC
 mux to bind()
Message-ID: <55fe7f3454d8c91dc3837ba5aa741d4a0e67378f.1618797813.git.tommyhebb@gmail.com>

When we first enable the DSI encoder, we currently program some per-chip
configuration that we look up in rk3399_chip_data based on the device
tree compatible we match. This data configures various parameters of the
MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a
dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan
out from.

This causes a problem in RK3399 dual-mode configurations, though: panel
prepare() callbacks run before the encoder gets enabled and expect to be
able to write commands to the DSI bus, but the bus isn't fully
functional until the lane and master/slave configuration have been
programmed. As a result, dual-mode panels (and possibly others too) fail
to turn on when the rockchipdrm driver is initially loaded.

Because the LCDC mux is the only thing we don't know until enable time
(and is the only thing that can ever change), we can actually move most
of the initialization to bind() and get it out of the way early. That's
what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(),
which also avoids the issue, but bind() seems like the more correct
place to me.)

Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a
Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's
backlight would turn on but no image would appear when initially loading
rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver,
it would come on. With this change, the panel successfully turns on
during initial rockchipdrm load as expected.

Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver")
Signed-off-by: Thomas Hebb <tommyhebb at gmail.com>
---

 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 36 ++++++++++++++-----
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 8cc81d5b82f0..520a0a0cd2b5 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -691,13 +691,8 @@ static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_rockchip_phy_ops = {
 	.get_timing = dw_mipi_dsi_phy_get_timing,
 };
 
-static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi,
-					int mux)
+static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi)
 {
-	if (dsi->cdata->lcdsel_grf_reg)
-		regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
-			mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
-
 	if (dsi->cdata->lanecfg1_grf_reg)
 		regmap_write(dsi->grf_regmap, dsi->cdata->lanecfg1_grf_reg,
 					      dsi->cdata->lanecfg1);
@@ -711,6 +706,13 @@ static void dw_mipi_dsi_rockchip_config(struct dw_mipi_dsi_rockchip *dsi,
 					      dsi->cdata->enable);
 }
 
+static void dw_mipi_dsi_rockchip_set_lcdsel(struct dw_mipi_dsi_rockchip *dsi,
+					    int mux)
+{
+	regmap_write(dsi->grf_regmap, dsi->cdata->lcdsel_grf_reg,
+		mux ? dsi->cdata->lcdsel_lit : dsi->cdata->lcdsel_big);
+}
+
 static int
 dw_mipi_dsi_encoder_atomic_check(struct drm_encoder *encoder,
 				 struct drm_crtc_state *crtc_state,
@@ -766,9 +768,9 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder *encoder)
 		return;
 	}
 
-	dw_mipi_dsi_rockchip_config(dsi, mux);
+	dw_mipi_dsi_rockchip_set_lcdsel(dsi, mux);
 	if (dsi->slave)
-		dw_mipi_dsi_rockchip_config(dsi->slave, mux);
+		dw_mipi_dsi_rockchip_set_lcdsel(dsi->slave, mux);
 
 	clk_disable_unprepare(dsi->grf_clk);
 }
@@ -922,6 +924,24 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
 		return ret;
 	}
 
+	/*
+	 * With the GRF clock running, write lane and dual-mode configurations
+	 * that won't change immediately. If we waited until enable() to do
+	 * this, things like panel preparation would not be able to send
+	 * commands over DSI.
+	 */
+	ret = clk_prepare_enable(dsi->grf_clk);
+	if (ret) {
+		DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
+		return ret;
+	}
+
+	dw_mipi_dsi_rockchip_config(dsi);
+	if (dsi->slave)
+		dw_mipi_dsi_rockchip_config(dsi->slave);
+
+	clk_disable_unprepare(dsi->grf_clk);
+
 	ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
 	if (ret) {
 		DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
-- 
2.30.0



From shenkai8 at huawei.com  Mon Apr 19 03:05:16 2021
From: shenkai8 at huawei.com (Kai Shen)
Date: Mon, 19 Apr 2021 10:05:16 +0800
Subject: [PATCH] arm64:align function __arch_clear_user
In-Reply-To: <20210414104144.GB8320@arm.com>
References: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
 <20210414104144.GB8320@arm.com>
Message-ID: <6829062c-a2d4-57da-4037-269fb7508993@huawei.com>

On 2021/4/14 18:41, Catalin Marinas wrote:
> On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
>> Performance decreases happen in __arch_clear_user when this
>> function is not correctly aligned on HISI-HIP08 arm64 SOC which
>> fetches 32 bytes (8 instructions) from icache with a 32-bytes
>> aligned end address. As a result, if the hot loop is not 32-bytes
>> aligned, it may take more icache fetches which leads to decrease
>> in performance.
>> Dump of assembler code for function __arch_clear_user:
>>         0xffff0000809e3f10 :    nop
>>         0xffff0000809e3f14 :    mov x2, x1
>>         0xffff0000809e3f18 :    subs x1, x1, #0x8
>>         0xffff0000809e3f1c :    b.mi 0xffff0000809e3f30 <__arch_clear_user+3
>> -----  0xffff0000809e3f20 :    str    xzr, [x0],#8
>> hot    0xffff0000809e3f24 :    nop
>> loop   0xffff0000809e3f28 :    subs x1, x1, #0x8
>> -----  0xffff0000809e3f2c :    b.pl  0xffff0000809e3f20 <__arch_clear_user+1
>> The hot loop above takes one icache fetch as the code is in one
>> 32-bytes aligned area and the loop takes one more icache fetch
>> when it is not aligned like below.
>>         0xffff0000809e4178 :   str    xzr, [x0],#8
>>         0xffff0000809e417c :   nop
>>         0xffff0000809e4180 :   subs x1, x1, #0x8
>>         0xffff0000809e4184 :   b.pl  0xffff0000809e4178 <__arch_clear_user+
>> Data collected by perf:
>>                           aligned   not aligned
>>            instructions   57733790     57739065
>>         L1-dcache-store   14938070     13718242
>> L1-dcache-store-misses     349280       349869
>>         L1-icache-loads   15380895     28500665
>> As we can see, L1-icache-loads almost double when the loop is not
>> aligned.
>> This problem is found in linux 4.19 on HISI-HIP08 arm64 SOC.
>> Not sure what the case is on other arm64 SOC, but it should do
>> no harm.
>> Signed-off-by: Kai Shen <shenkai8 at huawei.com>
> 
> Do you have a real world workload that's affected by this function?
> 
> I'm against adding alignments and nops for specific hardware
> implementations. What about lots of other loops that the compiler may
> generate or that we wrote in asm?
> 
 >
The benchmark we used which suffer performance decrease:
     https://github.com/redhat-performance/libMicro
     pread $OPTS -N "pread_z1k"    -s 1k    -I 300  -f /dev/zero
     pread $OPTS -N "pread_z10k"    -s 10k    -I 1000 -f /dev/zero
     pread $OPTS -N "pread_z100k"    -s 100k    -I 2000 -f /dev/zero

As far as I know, GCC has option falign-loops to align loop, as for
code written in asm, maybe we should take care of them on our own.

 From my point of view, the loop in __arch_clear_user is really hot
when being used, it is reasonable to align it.

Or maybe adding a errata CONFIG for HNS_HIP08 to fix this?

Previous message have some problems with formats of kernel mail list
So I resend this message.


From baolu.lu at linux.intel.com  Mon Apr 19 02:59:36 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Mon, 19 Apr 2021 09:59:36 +0800
Subject: [PATCH v3 01/12] iommu: Introduce dirty log tracking framework
In-Reply-To: <64c87f67-3687-61bd-1587-724cc2f9cc97@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-2-zhukeqian1@huawei.com>
 <fe337950-f8d0-3d21-a7b1-98b385d71f3e@linux.intel.com>
 <e42373e3-10d5-5a34-8f33-8bb82d64fb19@huawei.com>
 <56b001fa-b4fe-c595-dc5e-f362d2f07a19@linux.intel.com>
 <88cba608-2f22-eb83-f22e-50cb547b6ee8@huawei.com>
 <2c01425f-813c-4278-ba06-26d651496a5c@linux.intel.com>
 <64c87f67-3687-61bd-1587-724cc2f9cc97@huawei.com>
Message-ID: <4e7ae083-08f5-b273-f873-21a2960ea68a@linux.intel.com>

Hi Keqian,

On 4/16/21 5:07 PM, Keqian Zhu wrote:
>> I am worrying about having two sets of APIs for single purpose. From
>> vendor iommu driver's point of view, this feature is per device. Hence,
>> it still needs to do the same thing.
> Yes, we can unify the granule of feature reporting and status management.
> 
> The basic granule of dirty tracking is iommu_domain, I think it's very reasonable. We need an
> interface to report the feature of iommu_domain, then the logic is much more clear.
> 
> Every time we add new device or remove device from the domain, we should update the feature (e.g.,
> maintain a counter of unsupported devices).

Yes. This looks cleaner.

> 
> What do you think about this idea?
> 
> Thanks,
> Keqian

Best regards,
baolu


From wens at csie.org  Mon Apr 19 03:16:25 2021
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 19 Apr 2021 10:16:25 +0800
Subject: [PATCH] nvmem: sunxi_sid: Set type to OTP
In-Reply-To: <20210419015815.38910-1-samuel@sholland.org>
References: <20210419015815.38910-1-samuel@sholland.org>
Message-ID: <CAGb2v67cs5nVJihF7+zfPv7f2y+xxDG5ihAJ4pciZ9zm0b5nOw@mail.gmail.com>

On Mon, Apr 19, 2021 at 9:58 AM Samuel Holland <samuel at sholland.org> wrote:
>
> This device currently reports an "Unknown" type in sysfs.
> Since it is an eFuse hardware device, set its type to OTP.
>
> Signed-off-by: Samuel Holland <samuel at sholland.org>

Acked-by: Chen-Yu Tsai <wens at csie.org>


From samuel at sholland.org  Mon Apr 19 03:52:46 2021
From: samuel at sholland.org (Samuel Holland)
Date: Sun, 18 Apr 2021 21:52:46 -0500
Subject: [PATCH 2/2] arm64: dts: allwinner: Enforce consistent MMC numbering
In-Reply-To: <20210419025246.21722-1-samuel@sholland.org>
References: <20210419025246.21722-1-samuel@sholland.org>
Message-ID: <20210419025246.21722-3-samuel@sholland.org>

Traditionally, the sunxi-mmc device numbers matched the register address
order. However, that was broken by asynchronous probe, and now the MMC
device numbers are not deterministic. Add aliases to keep the device
numbers consistent between boots. Use the traditional order, since there
is no need to change it.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 9b58cfbefa6d..3df70a41b3b9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -17,6 +17,12 @@ / {
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	aliases {
+		mmc0 = &mmc0;
+		mmc1 = &mmc1;
+		mmc2 = &mmc2;
+	};
+
 	chosen {
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d8ebc1a84af9..4bdc48caf68a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -16,6 +16,12 @@ / {
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	aliases {
+		mmc0 = &mmc0;
+		mmc1 = &mmc1;
+		mmc2 = &mmc2;
+	};
+
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
-- 
2.26.3



From samuel at sholland.org  Mon Apr 19 03:52:44 2021
From: samuel at sholland.org (Samuel Holland)
Date: Sun, 18 Apr 2021 21:52:44 -0500
Subject: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
Message-ID: <20210419025246.21722-1-samuel@sholland.org>

Dealing with the inconsistent numbering has been a major pain, and
there is a solution with (as far as I can tell) no tangible downsides.
So let's use it.

Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help
when referencing the whole, unpartitioned device, like is needed for
updating the bootloader and firmware. So for the use case of "write a
bootloader to the SD card, regardless of where the board is currently
booted from", I know of two options:
  - Dig around in sysfs to find the mmc number from the MMIO address,
    which means I have to know the MMIO addresses for every SoC, or
  - Apply patches like these.

Samuel Holland (2):
  ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
  arm64: dts: allwinner: Enforce consistent MMC numbering

 arch/arm/boot/dts/sunxi-h3-h5.dtsi            | 6 ++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++
 3 files changed, 18 insertions(+)

-- 
2.26.3



From samuel at sholland.org  Mon Apr 19 03:52:45 2021
From: samuel at sholland.org (Samuel Holland)
Date: Sun, 18 Apr 2021 21:52:45 -0500
Subject: [PATCH 1/2] ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
In-Reply-To: <20210419025246.21722-1-samuel@sholland.org>
References: <20210419025246.21722-1-samuel@sholland.org>
Message-ID: <20210419025246.21722-2-samuel@sholland.org>

Traditionally, the sunxi-mmc device numbers matched the register address
order. However, that was broken by asynchronous probe, and now the MMC
device numbers are not deterministic. Add aliases to keep the device
numbers consistent between boots. Use the traditional order, since there
is no need to change it.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index e27399aa052c..1cb669c835bd 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -53,6 +53,12 @@ / {
 	#address-cells = <1>;
 	#size-cells = <1>;
 
+	aliases {
+		mmc0 = &mmc0;
+		mmc1 = &mmc1;
+		mmc2 = &mmc2;
+	};
+
 	chosen {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.26.3



From ruifeng.zhang0110 at gmail.com  Mon Apr 19 03:55:14 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Mon, 19 Apr 2021 10:55:14 +0800
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <2a4efeea-cc70-ca0a-81fd-84d8b54586c0@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
 <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>
 <2a4efeea-cc70-ca0a-81fd-84d8b54586c0@arm.com>
Message-ID: <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?17??? ??1:00???
>
> On 16/04/2021 13:04, Ruifeng Zhang wrote:
> > Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??6:39???
> >>
> >> On 16/04/2021 11:32, Valentin Schneider wrote:
> >>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>
> [...]
>
> >> I'm confused. Do you have the MT bit set to 1 then? So the issue that
> >> the mpidr handling in arm32's store_cpu_topology() is not correct does
> >> not exist?
> >
> > I have reconfirmed it, the MT bit has been set to 1. I am sorry for
> > the previous messages.
> > The mpidr parse by store_cpu_topology is correct, at least for the sc9863a.
>
> Nice! This is sorted then.
>
> [...]
>
> >> Is this what you need for your arm32 kernel system? Adding the
> >> possibility to parse cpu-map to create Phantom Domains?
> >
> > Yes, I need parse DT cpu-map to create different Phantom Domains.
> > With it, the dts should be change to:
> >                 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>;
> >                                 };
> >                         };
> >                 };
> >
>
> I'm afraid that this is now a much weaker case to get this into
> mainline.

But it's still a problem and it's not break the original logic ( parse
topology from MPIDR or parse capacity ), only add the support for
parse topology from DT.
I think it should still be merged into the mainline. If don't, the
DynamIQ SoC has some issue in sched and cpufreq.
>
> I'm able to run with an extra cpu-map entry:

Great.
>
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index 012d40a7228c..f60d9b448253 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -35,6 +35,29 @@ cpus {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>
> +               cpu-map {
> +                       cluster0 {
> +                               core0 {
> +                                       cpu = <&cpu0>;
> +                               };
> +                               core1 {
> +                                       cpu = <&cpu1>;
> +                               };
> +                       };
> +
> +                       cluster1 {
> +                               core0 {
> +                                       cpu = <&cpu2>;
> +                               };
> +                               core1 {
> +                                       cpu = <&cpu3>;
> +                               };
> +                               core2 {
> +                                       cpu = <&cpu4>;
> +                               };
> +                       };
> +               };
> +
>                 cpu0: cpu at 0 {
>
> a condensed version (see below) of your patch on my Arm32 TC2.
> The move of update_cpu_capacity() in store_cpu_topology() is only
> necessary when I use the old clock-frequency based cpu_efficiency
> approach for asymmetric CPU capacity (TC2 is a15/a7):
>
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> index f60d9b448253..e0679cca40ed 100644
> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
> @@ -64,7 +64,7 @@ cpu0: cpu at 0 {
>                         reg = <0>;
>                         cci-control-port = <&cci_control1>;
>                         cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
> -                       capacity-dmips-mhz = <1024>;
> +                       clock-frequency = <1000000000>;
>                         dynamic-power-coefficient = <990>;
>                 };
>
> @@ -74,7 +74,7 @@ cpu1: cpu at 1 {
>                         reg = <1>;
>                         cci-control-port = <&cci_control1>;
>                         cpu-idle-states = <&CLUSTER_SLEEP_BIG>;
> -                       capacity-dmips-mhz = <1024>;
> +                       clock-frequency = <1000000000>;
>                         dynamic-power-coefficient = <990>;
>                 };
>
> @@ -84,7 +84,7 @@ cpu2: cpu at 2 {
>                         reg = <0x100>;
>                         cci-control-port = <&cci_control2>;
>                         cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
> -                       capacity-dmips-mhz = <516>;
> +                       clock-frequency = <800000000>;
>                         dynamic-power-coefficient = <133>;
>                 };
>
> @@ -94,7 +94,7 @@ cpu3: cpu at 3 {
>                         reg = <0x101>;
>                         cci-control-port = <&cci_control2>;
>                         cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
> -                       capacity-dmips-mhz = <516>;
> +                       clock-frequency = <800000000>;
>                         dynamic-power-coefficient = <133>;
>                 };
>
> @@ -104,7 +104,7 @@ cpu4: cpu at 4 {
>                         reg = <0x102>;
>                         cci-control-port = <&cci_control2>;
>                         cpu-idle-states = <&CLUSTER_SLEEP_LITTLE>;
> -                       capacity-dmips-mhz = <516>;
> +                       clock-frequency = <800000000>;
>                         dynamic-power-coefficient = <133>;
>                 };
>
>
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index ef0058de432b..bff56c12c3a6 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -82,7 +82,7 @@ static bool cap_from_dt = true;
>   * 'average' CPU is of middle capacity. Also see the comments near
>   * table_efficiency[] and update_cpu_capacity().
>   */
> -static void __init parse_dt_topology(void)
> +static void __init get_coretype_capacity(void)
>  {
>         const struct cpu_efficiency *cpu_eff;
>         struct device_node *cn = NULL;
> @@ -173,7 +173,7 @@ static void update_cpu_capacity(unsigned int cpu)
>  }
>
>  #else
> -static inline void parse_dt_topology(void) {}
> +static inline void get_coretype_capacity(void) {}
>  static inline void update_cpu_capacity(unsigned int cpuid) {}
>  #endif
>
> @@ -221,14 +221,13 @@ void store_cpu_topology(unsigned int cpuid)
>                 cpuid_topo->package_id = -1;
>         }
>
> -       update_cpu_capacity(cpuid);
> -
>         pr_info("CPU%u: thread %d, cpu %d, socket %d, mpidr %x\n",
>                 cpuid, cpu_topology[cpuid].thread_id,
>                 cpu_topology[cpuid].core_id,
>                 cpu_topology[cpuid].package_id, mpidr);
>
>  topology_populated:
> +       update_cpu_capacity(cpuid);

Agree, it's more better than mine.
>         update_siblings_masks(cpuid);
>  }
>
> @@ -241,5 +240,6 @@ void __init init_cpu_topology(void)
>         reset_cpu_topology();
>         smp_wmb();
>
> +       get_coretype_capacity();
>         parse_dt_topology();
>  }
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index de8587cc119e..a2335da28f2a 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -295,7 +295,6 @@ static void parsing_done_workfn(struct work_struct *work)
>  core_initcall(free_raw_capacity);
>  #endif
>
> -#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)

It seems that the following functions are not defined on other CPU
architectures now, so I agree to remove it.
>  /*
>   * This function returns the logic cpu number of the node.
>   * There are basically three kinds of return values:
> @@ -441,7 +440,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
>         return 0;
>  }
>
> -static int __init parse_dt_topology(void)
> +int __init parse_dt_topology(void)
>  {
>         struct device_node *cn, *map;
>         int ret = 0;
> @@ -481,7 +480,6 @@ static int __init parse_dt_topology(void)
>         of_node_put(cn);
>         return ret;
>  }
> -#endif
>
>  /*
>   * cpu topology table
> diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> index 0f6cd6b73a61..cfa5a5072aa0 100644
> --- a/include/linux/arch_topology.h
> +++ b/include/linux/arch_topology.h
> @@ -66,6 +66,7 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>  #define topology_llc_cpumask(cpu)      (&cpu_topology[cpu].llc_sibling)
>  void init_cpu_topology(void);
>  void store_cpu_topology(unsigned int cpuid);
> +int __init parse_dt_topology(void);
>  const struct cpumask *cpu_coregroup_mask(int cpu);
>  void update_siblings_masks(unsigned int cpu);
>  void remove_cpu_topology(unsigned int cpuid);

Why do you keep the logic of topology_parse_cpu_capacity in arm
get_coretype_capacity function? The capacity-dmips-mhz will be parsed
by drivers/base/arch_topology.c as following:
parse_dt_topology
    parse_cluster
        parse_core
            get_cpu_for_node
                topology_parse_cpu_capacity


From wens at csie.org  Mon Apr 19 04:17:19 2021
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 19 Apr 2021 11:17:19 +0800
Subject: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
In-Reply-To: <20210419025246.21722-1-samuel@sholland.org>
References: <20210419025246.21722-1-samuel@sholland.org>
Message-ID: <CAGb2v642Z3iH7fUWa31Rb5j+nWdZ=sXn2BYw3_dyE9P6iuL0Cg@mail.gmail.com>

Hi,

On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland <samuel at sholland.org> wrote:
>
> Dealing with the inconsistent numbering has been a major pain, and
> there is a solution with (as far as I can tell) no tangible downsides.
> So let's use it.
>
> Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help
> when referencing the whole, unpartitioned device, like is needed for
> updating the bootloader and firmware. So for the use case of "write a
> bootloader to the SD card, regardless of where the board is currently
> booted from", I know of two options:
>   - Dig around in sysfs to find the mmc number from the MMIO address,
>     which means I have to know the MMIO addresses for every SoC, or
>   - Apply patches like these.
>
> Samuel Holland (2):
>   ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
>   arm64: dts: allwinner: Enforce consistent MMC numbering
>
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi            | 6 ++++++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++

At least with Rockchip this is now done at the board level. IIRC it was
a request from other people to not do it at the SoC level. I don't recall
exactly who though.

ChenYu


>  3 files changed, 18 insertions(+)
>
> --
> 2.26.3
>
>


From ilya.lipnitskiy at gmail.com  Mon Apr 19 04:42:53 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Sun, 18 Apr 2021 20:42:53 -0700
Subject: [PATCH] dt-bindings: net: mediatek: support MT7621 SoC
Message-ID: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>

Add missing binding documentation for SoC support that has been in place
since v5.1

Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware")
Cc: Bj?rn Mork <bjorn at mork.no>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 72d03e07cf7c..950ef6af20b1 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -10,6 +10,7 @@ Required properties:
 - compatible: Should be
 		"mediatek,mt2701-eth": for MT2701 SoC
 		"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
+		"mediatek,mt7621-eth": for MT7621 SoC
 		"mediatek,mt7622-eth": for MT7622 SoC
 		"mediatek,mt7629-eth": for MT7629 SoC
 		"ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Mon Apr 19 05:03:50 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Sun, 18 Apr 2021 21:03:50 -0700
Subject: [PATCH net-next 0/2] net: ethernet: mediatek: support custom GMAC
 label
Message-ID: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>

Add support for specifying GMAC label via DTS. Useful when it is desired
to use a master DSA interface name that is different from the "eth%d"
pattern.

Ilya Lipnitskiy (2):
  dt-bindings: net: mediatek: add optional GMAC labels
  net: ethernet: mediatek: support custom GMAC label

 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++
 drivers/net/ethernet/mediatek/mtk_eth_soc.c            | 4 ++++
 2 files changed, 10 insertions(+)

-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Mon Apr 19 05:03:51 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Sun, 18 Apr 2021 21:03:51 -0700
Subject: [PATCH net-next 1/2] dt-bindings: net: mediatek: add optional GMAC
 labels
In-Reply-To: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
References: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210419040352.2452-2-ilya.lipnitskiy@gmail.com>

Document the mediatek ethernet driver change that adds support for
custom labels and provide an example.

Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 72d03e07cf7c..500bf9351010 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -51,6 +51,10 @@ Required properties:
 	is equal to 0 and the MAC uses fixed-link to connect
 	with internal switch such as MT7530.
 
+Optional properties:
+- label: overrides the default netdevice name. Useful when a custom name for the
+	DSA master interface is desired.
+
 Example:
 
 eth: ethernet at 1b100000 {
@@ -74,12 +78,14 @@ eth: ethernet at 1b100000 {
 
 	gmac1: mac at 0 {
 		compatible = "mediatek,eth-mac";
+		label = "gmac1";
 		reg = <0>;
 		phy-handle = <&phy0>;
 	};
 
 	gmac2: mac at 1 {
 		compatible = "mediatek,eth-mac";
+		label = "gmac2";
 		reg = <1>;
 		phy-handle = <&phy1>;
 	};
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Mon Apr 19 05:03:52 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Sun, 18 Apr 2021 21:03:52 -0700
Subject: [PATCH net-next 2/2] net: ethernet: mediatek: support custom GMAC
 label
In-Reply-To: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
References: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210419040352.2452-3-ilya.lipnitskiy@gmail.com>

The MAC device name can now be set within DTS file instead of always
being "ethX". This is helpful for DSA to clearly label the DSA master
device and distinguish it from DSA slave ports.

For example, some devices, such as the Ubiquiti EdgeRouter X, may have
ports labeled ethX. Labeling the master GMAC with a different prefix
than DSA ports helps with clarity.

Suggested-by: Ren? van Dorst <opensource at vdorst.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6b00c12c6c43..4c0ce4fb7735 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
 
 static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 {
+	const char *label = of_get_property(np, "label", NULL);
 	const __be32 *_id = of_get_property(np, "reg", NULL);
 	phy_interface_t phy_mode;
 	struct phylink *phylink;
@@ -2940,6 +2941,9 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	else
 		eth->netdev[id]->max_mtu = MTK_MAX_RX_LENGTH_2K - MTK_RX_ETH_HLEN;
 
+	if (label)
+		strscpy(eth->netdev[id]->name, label, IFNAMSIZ);
+
 	return 0;
 
 free_netdev:
-- 
2.31.1



From navam at xilinx.com  Mon Apr 19 06:18:41 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Mon, 19 Apr 2021 05:18:41 +0000
Subject: [PATCH 3/3] fpga: region: Adds runtime PM support
In-Reply-To: <YHDHhf1tQo6vI49W@epycbox.lan>
References: <20210402092049.479-1-nava.manne@xilinx.com>
 <20210402092049.479-4-nava.manne@xilinx.com> <YHDHhf1tQo6vI49W@epycbox.lan>
Message-ID: <MWHPR02MB2623E61ABFBB478E95DC863FC2499@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Moritz,

	Please find my response inline.

> -----Original Message-----
> From: Moritz Fischer <mdf at kernel.org>
> Sent: Saturday, April 10, 2021 3:01 AM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: mdf at kernel.org; trix at redhat.com; robh+dt at kernel.org; Michal Simek
> <michals at xilinx.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; git <git at xilinx.com>
> Subject: Re: [PATCH 3/3] fpga: region: Adds runtime PM support
> 
> On Fri, Apr 02, 2021 at 02:50:49PM +0530, Nava kishore Manne wrote:
> > Adds support to handle FPGA/PL power domain. With this patch, the PL
> > power domain will be turned on before loading the bitstream and turned
> > off while removing/unloading the bitstream using overlays.
> > This can be achieved by adding the runtime PM support.
> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  drivers/fpga/of-fpga-region.c | 18 +++++++++++++++++-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/fpga/of-fpga-region.c
> > b/drivers/fpga/of-fpga-region.c index e405309baadc..35fc2f3d4bd8
> > 100644
> > --- a/drivers/fpga/of-fpga-region.c
> > +++ b/drivers/fpga/of-fpga-region.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/of_platform.h>
> >  #include <linux/slab.h>
> >  #include <linux/spinlock.h>
> > +#include <linux/pm_runtime.h>
> >
> >  static const struct of_device_id fpga_region_of_match[] = {
> >  	{ .compatible = "fpga-region", },
> > @@ -302,6 +303,7 @@ static int of_fpga_region_notify_pre_apply(struct
> fpga_region *region,
> >  	}
> >
> >  	region->info = info;
> > +	pm_runtime_get_sync(dev->parent);
> >  	ret = fpga_region_program_fpga(region);
> >  	if (ret) {
> >  		/* error; reject overlay */
> > @@ -324,10 +326,13 @@ static int
> > of_fpga_region_notify_pre_apply(struct fpga_region *region,  static void
> of_fpga_region_notify_post_remove(struct fpga_region *region,
> >  					      struct of_overlay_notify_data
> *nd)  {
> > +	struct device *dev = &region->dev;
> > +
> >  	fpga_bridges_disable(&region->bridge_list);
> >  	fpga_bridges_put(&region->bridge_list);
> >  	fpga_image_info_free(region->info);
> >  	region->info = NULL;
> > +	pm_runtime_put(dev->parent);
> >  }
> >
> >  /**
> > @@ -411,9 +416,16 @@ static int of_fpga_region_probe(struct
> platform_device *pdev)
> >  		goto eprobe_mgr_put;
> >  	}
> >
> > +	pm_runtime_enable(&pdev->dev);
> > +	ret = pm_runtime_get_sync(&pdev->dev);
> > +	if (ret < 0)
> > +		goto err_pm;
> > +
> > +	pm_runtime_put(&pdev->dev);
> > +
> >  	ret = fpga_region_register(region);
> >  	if (ret)
> > -		goto eprobe_mgr_put;
> > +		goto err_pm;
> >
> >  	of_platform_populate(np, fpga_region_of_match, NULL, &region-
> >dev);
> >  	platform_set_drvdata(pdev, region);
> > @@ -422,6 +434,9 @@ static int of_fpga_region_probe(struct
> > platform_device *pdev)
> >
> >  	return 0;
> >
> > +err_pm:
> > +	pm_runtime_put(&pdev->dev);
> > +	pm_runtime_disable(&pdev->dev);
> >  eprobe_mgr_put:
> >  	fpga_mgr_put(mgr);
> >  	return ret;
> > @@ -434,6 +449,7 @@ static int of_fpga_region_remove(struct
> > platform_device *pdev)
> >
> >  	fpga_region_unregister(region);
> >  	fpga_mgr_put(mgr);
> > +	pm_runtime_disable(region->dev.parent);
> >
> >  	return 0;
> >  }
> > --
> > 2.18.0
> >
> 
> Does this add a dependency on CONFIG_PM?
> 
Yes, the newly added functionality has a dependency on CONFIG_PM if it's disabled the expected power domain (in our cases it's PL) will not powered ON/OFF dynamically at runtime and this is as an expected behavior. Other than this it will not impact the any of the driver existing functionality.

Regards,
Navakishore.


From tzungbi at google.com  Mon Apr 19 06:21:36 2021
From: tzungbi at google.com (Tzung-Bi Shih)
Date: Mon, 19 Apr 2021 13:21:36 +0800
Subject: [RESEND PATCH] pinctrl: mediatek: use spin lock in mtk_rmw
Message-ID: <20210419052136.2475373-1-tzungbi@google.com>

Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
mutex lock in mtk_rmw.  However the function is possible called from
atomic context.

For example call trace:
  mutex_lock+0x28/0x64
  mtk_rmw+0x38/0x80
  mtk_hw_set_value+0x100/0x138
  mtk_gpio_set+0x48/0x58
  gpiod_set_raw_value_commit+0xf4/0x110
  gpiod_set_value_nocheck+0x4c/0x80
  gpiod_set_value+0x4c/0x6c
  max98357a_daiops_trigger+0x8c/0x9c
  soc_pcm_trigger+0x5c/0x10c

The max98357a_daiops_trigger() could run in either atomic or non-atomic
context.  As a result, dmesg shows some similar messages: "BUG: sleeping
function called from invalid context at kernel/locking/mutex.c:254".

Uses spin lock in mtk_rmw instead.

Fixes: 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.")
Signed-off-by: Tzung-Bi Shih <tzungbi at google.com>
---
 drivers/pinctrl/mediatek/pinctrl-moore.c         | 2 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 4 ++--
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 drivers/pinctrl/mediatek/pinctrl-paris.c         | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index f77921957f15..3a4a23c40a71 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -619,7 +619,7 @@ int mtk_moore_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	/* Copy from internal struct mtk_pin_desc to register to the core */
 	pins = devm_kmalloc_array(&pdev->dev, hw->soc->npins, sizeof(*pins),
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index fcf7c3eeee4a..9ffe01a8ceca 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -58,14 +58,14 @@ void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set)
 {
 	u32 val;
 
-	mutex_lock(&pctl->lock);
+	spin_lock(&pctl->lock);
 
 	val = mtk_r32(pctl, i, reg);
 	val &= ~mask;
 	val |= set;
 	mtk_w32(pctl, i, reg, val);
 
-	mutex_unlock(&pctl->lock);
+	spin_unlock(&pctl->lock);
 }
 
 static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 65eac708a3b3..13836bb188b7 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -252,7 +252,7 @@ struct mtk_pinctrl {
 	struct mtk_pinctrl_group	*groups;
 	const char          **grp_names;
 	/* lock pin's register resource to avoid multiple threads issue*/
-	struct mutex lock;
+	spinlock_t lock;
 };
 
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 48e823f6d293..85db2e4377f0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -970,7 +970,7 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	err = mtk_pctrl_build_state(pdev);
 	if (err) {
-- 
2.31.1.368.gbe11c130af-goog



From sebastian.fricke at posteo.net  Mon Apr 19 07:02:25 2021
From: sebastian.fricke at posteo.net (Sebastian Fricke)
Date: Mon, 19 Apr 2021 06:02:25 +0000
Subject: [PATCH] media: rkisp1: rkisp1-params.c: Fix typos
Message-ID: <20210419060224.44353-1-sebastian.fricke@posteo.net>

s/when the camera active/when the camera is active/
s/thus not isr protection/thus no ISR protection/

Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
index b6beddd988d0..ead948a2d01e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
@@ -1258,7 +1258,7 @@ void rkisp1_params_configure(struct rkisp1_params *params,
 	rkisp1_params_config_parameter(params);
 }
 
-/* Not called when the camera active, thus not isr protection. */
+/* Not called when the camera is active, thus no ISR protection. */
 void rkisp1_params_disable(struct rkisp1_params *params)
 {
 	rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPCC_MODE,
-- 
2.25.1



From u.kleine-koenig at pengutronix.de  Mon Apr 19 07:23:56 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 19 Apr 2021 08:23:56 +0200
Subject: [PATCH v6 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210419000007.1944301-3-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <20210419000007.1944301-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419062356.bfgkcdrceovdwkh5@pengutronix.de>

On Mon, Apr 19, 2021 at 09:00:07AM +0900, Nobuhiro Iwamatsu wrote:
> Add driver for the PWM controller on Toshiba Visconti ARM SoC.
> 
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>

Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Thanks for your endurance to improve the driver
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/20210419/374d2a16/attachment.sig>

From bjorn at mork.no  Mon Apr 19 07:24:09 2021
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 19 Apr 2021 08:24:09 +0200
Subject: [PATCH] dt-bindings: net: mediatek: support MT7621 SoC
In-Reply-To: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com> (Ilya
 Lipnitskiy's message of "Sun, 18 Apr 2021 20:42:53 -0700")
References: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>
Message-ID: <878s5e94hi.fsf@miraculix.mork.no>

Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com> writes:

> Add missing binding documentation for SoC support that has been in place
> since v5.1
>
> Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware")
> Cc: Bj?rn Mork <bjorn at mork.no>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index 72d03e07cf7c..950ef6af20b1 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -10,6 +10,7 @@ Required properties:
>  - compatible: Should be
>  		"mediatek,mt2701-eth": for MT2701 SoC
>  		"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
> +		"mediatek,mt7621-eth": for MT7621 SoC
>  		"mediatek,mt7622-eth": for MT7622 SoC
>  		"mediatek,mt7629-eth": for MT7629 SoC
>  		"ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC


Thanks for taking care of this!

Note, however, that this compatible value is defined in
Documentation/devicetree/bindings/net/ralink,rt2880-net.txt

I believe that file should go away. These two files are both documenting
the same compatible property AFAICS.


Bj?rn


From hch at lst.de  Mon Apr 19 07:34:41 2021
From: hch at lst.de (Christoph Hellwig)
Date: Mon, 19 Apr 2021 08:34:41 +0200
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416152755.GL2531743@casper.infradead.org>
References: <20210411114307.5087f958@carbon>
 <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
Message-ID: <20210419063441.GA18787@lst.de>

On Fri, Apr 16, 2021 at 04:27:55PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch.  Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
> 
> I think this is slightly simpler, and as a bonus code that assumes the
> old layout won't compile.

So, why do we even do this crappy overlay of a dma address?  This just
all seems like a giant hack.  Random subsystems should not just steal
a few struct page fields as that just turns into the desasters like the
one we've seen here or probably something worse next time.


From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 07:35:10 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 15:35:10 +0900
Subject: [PATCH v2 0/3] PCI: dwc: Visoconti: PCIe RC controller driver
Message-ID: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>

Hi,

This series is the PCIe driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files.

Best regards,
  Nobuhiro

[0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

  dt-bindings: pci: Add DT binding for Toshiba Visconti PCIe controller
    v1 -> v2:
      - Remove white space.
      - Drop num-viewport and bus-range from required.
      - Drop status line from example.
      - Drop bus-range from required.
      - Removed lines defined in pci-bus.yaml from required.

  PCI: dwc: Visconti: PCIe RC controller driver
    v1 -> v2:
      - Fix typo in commit message.
      - Drop "depends on OF && HAS_IOMEM" from Kconfig.
      - Stop using the pointer of struct dw_pcie.
      - Use _relaxed variant.
      - Drop dw_pcie_wait_for_link.
      - Drop dbi resource processing.
      - Drop MSI IRQ initialization processing.

  MAINTAINERS: Add entries for Toshiba Visconti PCIe controller
    v1 -> v2:
      - No update.

Nobuhiro Iwamatsu (3):
  dt-bindings: pci: Add DT binding for Toshiba Visconti PCIe controller
  PCI: dwc: Visconti: PCIe RC controller driver
  MAINTAINERS: Add entries for Toshiba Visconti PCIe controller

 .../bindings/pci/toshiba,visconti-pcie.yaml   | 110 ++++++
 MAINTAINERS                                   |   2 +
 drivers/pci/controller/dwc/Kconfig            |   9 +
 drivers/pci/controller/dwc/Makefile           |   1 +
 drivers/pci/controller/dwc/pcie-visconti.c    | 333 ++++++++++++++++++
 5 files changed, 455 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
 create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c

-- 
2.30.0.rc2


From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 07:35:11 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 15:35:11 +0900
Subject: [PATCH v2 1/3] dt-bindings: pci: Add DT binding for Toshiba Visconti
 PCIe controller
In-Reply-To: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419063513.1947003-2-nobuhiro1.iwamatsu@toshiba.co.jp>

This commit adds the Device Tree binding documentation that allows
to describe the PCIe controller found in Toshiba Visconti SoCs.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 .../bindings/pci/toshiba,visconti-pcie.yaml   | 110 ++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
new file mode 100644
index 000000000000..d47a4a3c49e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/toshiba,visconti-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti5 SoC PCIe Host Controller Device Tree Bindings
+
+maintainers:
+  - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+
+description: |+
+  Toshiba Visconti5 SoC PCIe host controller is based on the Synopsys DesignWare PCIe IP.
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+    const: toshiba,visconti-pcie
+
+  reg:
+    items:
+      - description: Data Bus Interface (DBI) registers.
+      - description: PCIe configuration space region.
+      - description: Visconti specific additional registers.
+      - description: Visconti specific SMU registers
+      - description: Visconti specific memory protection unit registers (MPU)
+
+  reg-names:
+    items:
+      - const: dbi
+      - const: config
+      - const: ulreg
+      - const: smu
+      - const: mpu
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: PCIe reference clock
+      - description: PCIe system clock
+      - description: Auxiliary clock
+
+  clock-names:
+    items:
+      - const: pcie_refclk
+      - const: sysclk
+      - const: auxclk
+
+  num-lanes:
+    const: 2
+
+required:
+  - reg
+  - reg-names
+  - interrupts
+  - "#interrupt-cells"
+  - interrupt-map
+  - interrupt-map-mask
+  - num-lanes
+  - clocks
+  - clock-names
+  - max-link-speed
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pcie: pcie at 28400000 {
+            compatible = "toshiba,visconti-pcie";
+            reg = <0x0 0x28400000 0x0 0x00400000>,
+                  <0x0 0x70000000 0x0 0x10000000>,
+                  <0x0 0x28050000 0x0 0x00010000>,
+                  <0x0 0x24200000 0x0 0x00002000>,
+                  <0x0 0x24162000 0x0 0x00001000>;
+            reg-names  = "dbi", "config", "ulreg", "smu", "mpu";
+            device_type = "pci";
+            bus-range = <0x00 0xff>;
+            num-lanes = <2>;
+            num-viewport = <8>;
+
+            #address-cells = <3>;
+            #size-cells = <2>;
+            #interrupt-cells = <1>;
+            ranges = <0x81000000 0 0x40000000 0 0x40000000 0 0x00010000>,
+                     <0x82000000 0 0x50000000 0 0x50000000 0 0x20000000>;
+            interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+            interrupt-names = "intr";
+            interrupt-map-mask = <0 0 0 7>;
+            interrupt-map =
+                <0 0 0 1 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 2 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 3 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+                 0 0 0 4 &gic GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&extclk100mhz>, <&clk600mhz>, <&clk25mhz>;
+            clock-names = "pcie_refclk", "sysclk", "auxclk";
+            max-link-speed = <2>;
+        };
+    };
+...
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 07:35:13 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 15:35:13 +0900
Subject: [PATCH v2 3/3] MAINTAINERS: Add entries for Toshiba Visconti PCIe
 controller
In-Reply-To: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419063513.1947003-4-nobuhiro1.iwamatsu@toshiba.co.jp>

Add entries for Toshiba Visconti PCIe controller binding and driver.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8a154939ae27..3e5187c5b8d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2621,11 +2621,13 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
 F:	Documentation/devicetree/bindings/arm/toshiba.yaml
 F:	Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
 F:	Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
+F:	Documentation/devicetree/bindings/pci/toshiba,visconti-pcie.yaml
 F:	Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
 F:	Documentation/devicetree/bindings/watchdog/toshiba,visconti-wdt.yaml
 F:	arch/arm64/boot/dts/toshiba/
 F:	drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
 F:	drivers/gpio/gpio-visconti.c
+F:	drivers/pci/controller/dwc/pcie-visconti.c
 F:	drivers/pinctrl/visconti/
 F:	drivers/watchdog/visconti_wdt.c
 N:	visconti
-- 
2.30.0.rc2



From nobuhiro1.iwamatsu at toshiba.co.jp  Mon Apr 19 07:35:12 2021
From: nobuhiro1.iwamatsu at toshiba.co.jp (Nobuhiro Iwamatsu)
Date: Mon, 19 Apr 2021 15:35:12 +0900
Subject: [PATCH v2 2/3] PCI: dwc: Visconti: PCIe RC controller driver
In-Reply-To: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419063513.1947003-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210419063513.1947003-3-nobuhiro1.iwamatsu@toshiba.co.jp>

Add support to PCIe RC controller on Toshiba Visconti ARM SoCs. PCIe controller is based of Synopsys
DesignWare PCIe core.

This patch does not yet use the clock framework to control the clock. This will be replaced in the
future.

Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
---
 drivers/pci/controller/dwc/Kconfig         |   9 +
 drivers/pci/controller/dwc/Makefile        |   1 +
 drivers/pci/controller/dwc/pcie-visconti.c | 333 +++++++++++++++++++++
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c

diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index b9aaa84452c4..043c2c70d566 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -286,6 +286,15 @@ config PCIE_TEGRA194_EP
 	  in order to enable device-specific features PCIE_TEGRA194_EP must be
 	  selected. This uses the DesignWare core.
 
+config PCIE_VISCONTI
+	bool "Toshiba VISCONTI PCIe controllers"
+	depends on ARCH_VISCONTI || COMPILE_TEST
+	depends on PCI_MSI_IRQ_DOMAIN
+	select PCIE_DW_HOST
+	help
+	  Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
+	  This driver supports TMPV77xx.
+
 config PCIE_UNIPHIER
 	bool "Socionext UniPhier PCIe host controllers"
 	depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index ba7c42f6df6f..46ac5d49dc75 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
 obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
 obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
 obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
+obj-$(CONFIG_PCIE_VISCONTI) += pcie-visconti.o
 
 # The following drivers are for devices that use the generic ACPI
 # pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-visconti.c b/drivers/pci/controller/dwc/pcie-visconti.c
new file mode 100644
index 000000000000..a4739e7187f0
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-visconti.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DWC PCIe RC driver for Toshiba Visconti ARM SoC
+ *
+ * Copyright (C) 2019, 2020 Toshiba Electronic Device & Storage Corporation
+ * Copyright (C) 2020, TOSHIBA CORPORATION
+ *
+ * Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/resource.h>
+#include <linux/types.h>
+
+#include "pcie-designware.h"
+#include "../../pci.h"
+
+struct visconti_pcie {
+	struct dw_pcie pci;
+	void __iomem *ulreg_base;
+	void __iomem *smu_base;
+	void __iomem *mpu_base;
+	struct clk *refclk;
+	struct clk *sysclk;
+	struct clk *auxclk;
+};
+
+#define PCIE_UL_REG_S_PCIE_MODE		0x00F4
+#define  PCIE_UL_REG_S_PCIE_MODE_EP	0x00
+#define  PCIE_UL_REG_S_PCIE_MODE_RC	0x04
+
+#define PCIE_UL_REG_S_PERSTN_CTRL	0x00F8
+#define  PCIE_UL_IOM_PCIE_PERSTN_I_EN	BIT(3)
+#define  PCIE_UL_DIRECT_PERSTN_EN	BIT(2)
+#define  PCIE_UL_PERSTN_OUT		BIT(1)
+#define  PCIE_UL_DIRECT_PERSTN		BIT(0)
+
+#define PCIE_UL_REG_S_PHY_INIT_02	0x0104
+#define  PCIE_UL_PHY0_SRAM_EXT_LD_DONE	BIT(0)
+
+#define PCIE_UL_REG_S_PHY_INIT_03	0x0108
+#define  PCIE_UL_PHY0_SRAM_INIT_DONE	BIT(0)
+
+#define PCIE_UL_REG_S_INT_EVENT_MASK1	0x0138
+#define  PCIE_UL_CFG_PME_INT		BIT(0)
+#define  PCIE_UL_CFG_LINK_EQ_REQ_INT	BIT(1)
+#define  PCIE_UL_EDMA_INT0		BIT(2)
+#define  PCIE_UL_EDMA_INT1		BIT(3)
+#define  PCIE_UL_EDMA_INT2		BIT(4)
+#define  PCIE_UL_EDMA_INT3		BIT(5)
+#define  PCIE_UL_S_INT_EVENT_MASK1_ALL  (PCIE_UL_CFG_PME_INT | PCIE_UL_CFG_LINK_EQ_REQ_INT | \
+					 PCIE_UL_EDMA_INT0 | PCIE_UL_EDMA_INT1 | \
+					 PCIE_UL_EDMA_INT2 | PCIE_UL_EDMA_INT3)
+
+#define PCIE_UL_REG_S_SB_MON		0x0198
+#define PCIE_UL_REG_S_SIG_MON		0x019C
+#define  PCIE_UL_CORE_RST_N_MON		BIT(0)
+
+#define PCIE_UL_REG_V_SII_DBG_00	0x0844
+#define PCIE_UL_REG_V_SII_GEN_CTRL_01	0x0860
+#define  PCIE_UL_APP_LTSSM_ENABLE	BIT(0)
+
+#define PCIE_UL_REG_V_PHY_ST_00		0x0864
+#define  PCIE_UL_SMLH_LINK_UP		BIT(0)
+
+#define PCIE_UL_REG_V_PHY_ST_02		0x0868
+#define  PCIE_UL_S_DETECT_ACT		0x01
+#define  PCIE_UL_S_L0			0x11
+
+#define PISMU_CKON_PCIE			0x0038
+#define  PISMU_CKON_PCIE_AUX_CLK	BIT(1)
+#define  PISMU_CKON_PCIE_MSTR_ACLK	BIT(0)
+
+#define PISMU_RSOFF_PCIE		0x0538
+#define  PISMU_RSOFF_PCIE_ULREG_RST_N	BIT(1)
+#define  PISMU_RSOFF_PCIE_PWR_UP_RST_N	BIT(0)
+
+#define PCIE_MPU_REG_MP_EN		0x0
+#define  MPU_MP_EN_DISABLE		BIT(0)
+
+#define PCIE_BUS_OFFSET			0x40000000
+
+/* Access registers in PCIe ulreg */
+static inline void visconti_ulreg_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel_relaxed(val, pcie->ulreg_base + reg);
+}
+
+/* Access registers in PCIe smu */
+static inline void visconti_smu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel_relaxed(val, pcie->smu_base + reg);
+}
+
+/* Access registers in PCIe mpu */
+static inline void visconti_mpu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
+{
+	writel_relaxed(val, pcie->mpu_base + reg);
+}
+
+static inline u32 visconti_mpu_readl(struct visconti_pcie *pcie, u32 reg)
+{
+	return readl_relaxed(pcie->mpu_base + reg);
+}
+
+static int visconti_pcie_check_link_status(struct visconti_pcie *pcie)
+{
+	int err;
+	u32 val;
+
+	/* wait for linkup of phy link layer */
+	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_00, val,
+				 (val & PCIE_UL_SMLH_LINK_UP), 1000, 10000);
+	if (err)
+		return err;
+
+	/* wait for linkup of data link layer */
+	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
+				 (val & PCIE_UL_S_DETECT_ACT), 1000, 10000);
+	if (err)
+		return err;
+
+	/* wait for LTSSM Status */
+	return readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
+				  (val & PCIE_UL_S_L0), 1000, 10000);
+}
+
+static int visconti_pcie_establish_link(struct pcie_port *pp)
+{
+	int ret;
+	u32 val;
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_APP_LTSSM_ENABLE, PCIE_UL_REG_V_SII_GEN_CTRL_01);
+
+	ret = visconti_pcie_check_link_status(pcie);
+	if (ret < 0) {
+		dev_info(pci->dev, "Link failure\n");
+		return ret;
+	}
+
+	val = visconti_mpu_readl(pcie, PCIE_MPU_REG_MP_EN);
+	visconti_mpu_writel(pcie, val & ~MPU_MP_EN_DISABLE, PCIE_MPU_REG_MP_EN);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_S_INT_EVENT_MASK1_ALL, PCIE_UL_REG_S_INT_EVENT_MASK1);
+
+	return 0;
+}
+
+static int visconti_pcie_host_init(struct pcie_port *pp)
+{
+	dw_pcie_setup_rc(pp);
+	return visconti_pcie_establish_link(pp);
+}
+
+static const struct dw_pcie_host_ops visconti_pcie_host_ops = {
+	.host_init = visconti_pcie_host_init,
+};
+
+static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 pci_addr)
+{
+	return pci_addr - PCIE_BUS_OFFSET;
+}
+
+static const struct dw_pcie_ops dw_pcie_ops = {
+	.cpu_addr_fixup = visconti_pcie_cpu_addr_fixup,
+};
+
+static int visconti_get_resources(struct platform_device *pdev,
+				  struct visconti_pcie *pcie)
+{
+	struct device *dev = &pdev->dev;
+
+	pcie->ulreg_base = devm_platform_ioremap_resource_byname(pdev, "ulreg");
+	if (IS_ERR(pcie->ulreg_base))
+		return PTR_ERR(pcie->ulreg_base);
+
+	pcie->smu_base = devm_platform_ioremap_resource_byname(pdev, "smu");
+	if (IS_ERR(pcie->smu_base))
+		return PTR_ERR(pcie->smu_base);
+
+	pcie->mpu_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
+	if (IS_ERR(pcie->mpu_base))
+		return PTR_ERR(pcie->mpu_base);
+
+	pcie->refclk = devm_clk_get(dev, "pcie_refclk");
+	if (IS_ERR(pcie->refclk)) {
+		dev_err(dev, "Failed to get refclk clock: %ld\n", PTR_ERR(pcie->refclk));
+		return PTR_ERR(pcie->refclk);
+	}
+
+	pcie->sysclk = devm_clk_get(dev, "sysclk");
+	if (IS_ERR(pcie->sysclk)) {
+		dev_err(dev, "Failed to get sysclk clock: %ld\n", PTR_ERR(pcie->sysclk));
+		return PTR_ERR(pcie->sysclk);
+	}
+
+	pcie->auxclk = devm_clk_get(dev, "auxclk");
+	if (IS_ERR(pcie->auxclk)) {
+		dev_err(dev, "Failed to get auxclk clock: %ld\n", PTR_ERR(pcie->auxclk));
+		return PTR_ERR(pcie->auxclk);
+	}
+
+	return 0;
+}
+
+static int visconti_device_turnon(struct visconti_pcie *pcie)
+{
+	int err;
+	u32 val;
+
+	visconti_smu_writel(pcie, PISMU_CKON_PCIE_AUX_CLK | PISMU_CKON_PCIE_MSTR_ACLK,
+			    PISMU_CKON_PCIE);
+	ndelay(250);
+
+	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_ULREG_RST_N, PISMU_RSOFF_PCIE);
+
+	visconti_ulreg_writel(pcie, PCIE_UL_REG_S_PCIE_MODE_RC, PCIE_UL_REG_S_PCIE_MODE);
+
+	val = PCIE_UL_IOM_PCIE_PERSTN_I_EN | PCIE_UL_DIRECT_PERSTN_EN | PCIE_UL_DIRECT_PERSTN;
+	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
+	udelay(100);
+
+	val |= PCIE_UL_PERSTN_OUT;
+	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
+	udelay(100);
+
+	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_PWR_UP_RST_N, PISMU_RSOFF_PCIE);
+
+	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_PHY_INIT_03, val,
+				 (val & PCIE_UL_PHY0_SRAM_INIT_DONE), 100, 1000);
+	if (err)
+		return err;
+
+	visconti_ulreg_writel(pcie, PCIE_UL_PHY0_SRAM_EXT_LD_DONE, PCIE_UL_REG_S_PHY_INIT_02);
+
+	return readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_SIG_MON, val,
+				 (val & PCIE_UL_CORE_RST_N_MON), 100, 1000);
+}
+
+static int visconti_add_pcie_port(struct visconti_pcie *pcie, struct platform_device *pdev)
+{
+	struct dw_pcie *pci = &pcie->pci;
+	struct pcie_port *pp = &pci->pp;
+	struct device *dev = &pdev->dev;
+	int ret;
+
+	pp->irq = platform_get_irq_byname(pdev, "intr");
+	if (pp->irq < 0) {
+		dev_err(dev, "interrupt intr is missing");
+		return pp->irq;
+	}
+
+	pp->ops = &visconti_pcie_host_ops;
+
+	pci->link_gen = of_pci_get_max_link_speed(pdev->dev.of_node);
+	if (pci->link_gen < 0 || pci->link_gen > 3) {
+		pci->link_gen = 3;
+		dev_dbg(dev, "Applied default link speed\n");
+	}
+
+	dev_dbg(dev, "link speed Gen %d", pci->link_gen);
+
+	ret = visconti_device_turnon(pcie);
+	if (ret)
+		goto error;
+
+	ret = dw_pcie_host_init(pp);
+	if (ret)
+		dev_err(dev, "Failed to initialize host\n");
+
+error:
+	return ret;
+}
+
+static int visconti_pcie_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct visconti_pcie *pcie;
+	struct pcie_port *pp;
+	struct dw_pcie *pci;
+	int ret;
+
+	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(36));
+	if (ret)
+		return ret;
+
+	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	pci = &pcie->pci;
+	pp = &pci->pp;
+	pp->num_vectors = MAX_MSI_IRQS;
+
+	pci->dev = dev;
+	pci->ops = &dw_pcie_ops;
+
+	ret = visconti_get_resources(pdev, pcie);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, pcie);
+
+	return visconti_add_pcie_port(pcie, pdev);
+}
+
+static const struct of_device_id visconti_pcie_match[] = {
+	{ .compatible = "toshiba,visconti-pcie" },
+	{},
+};
+
+static struct platform_driver visconti_pcie_driver = {
+	.probe = visconti_pcie_probe,
+	.driver = {
+		.name = "visconti-pcie",
+		.of_match_table = visconti_pcie_match,
+		.suppress_bind_attrs = true,
+	},
+};
+
+builtin_platform_driver(visconti_pcie_driver);
-- 
2.30.0.rc2



From ilias.apalodimas at linaro.org  Mon Apr 19 08:15:58 2021
From: ilias.apalodimas at linaro.org (Ilias Apalodimas)
Date: Mon, 19 Apr 2021 10:15:58 +0300
Subject: [PATCH 1/1] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210419063441.GA18787@lst.de>
References: <20210411103318.GC2531743@casper.infradead.org>
 <20210412011532.GG2531743@casper.infradead.org>
 <20210414101044.19da09df@carbon>
 <20210414115052.GS2531743@casper.infradead.org>
 <20210414211322.3799afd4@carbon>
 <20210414213556.GY2531743@casper.infradead.org>
 <a50c3156fe8943ef964db4345344862f@AcuMS.aculab.com>
 <20210415200832.32796445@carbon>
 <20210416152755.GL2531743@casper.infradead.org>
 <20210419063441.GA18787@lst.de>
Message-ID: <YH0uLsnzdE9ya6kw@apalos.home>

Hi Christoph,

On Mon, Apr 19, 2021 at 08:34:41AM +0200, Christoph Hellwig wrote:
> On Fri, Apr 16, 2021 at 04:27:55PM +0100, Matthew Wilcox wrote:
> > On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > > See below patch.  Where I swap32 the dma address to satisfy
> > > page->compound having bit zero cleared. (It is the simplest fix I could
> > > come up with).
> > 
> > I think this is slightly simpler, and as a bonus code that assumes the
> > old layout won't compile.
> 
> So, why do we even do this crappy overlay of a dma address?  This just
> all seems like a giant hack.  Random subsystems should not just steal
> a few struct page fields as that just turns into the desasters like the
> one we've seen here or probably something worse next time.

The page pool API was using page->private in the past to store these kind of
info. That caused a problem to begin with, since it would fail  on 32-bit
systems with 64bit DMA.  We had a similar discussion on the past but decided
struct page is the right place to store that [1].

Another advantage is that we can now use the information from the networking 
subsystem and enable recycling of SKBs and SKB fragments, by using the stored 
metadata of struct page [2].

[1] https://lore.kernel.org/netdev/20190207.132519.1698007650891404763.davem at davemloft.net/
[2] https://lore.kernel.org/netdev/20210409223801.104657-1-mcroce at linux.microsoft.com/

Cheers
/Ilias


From yibin.gong at nxp.com  Mon Apr 19 08:17:12 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Mon, 19 Apr 2021 07:17:12 +0000
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
Message-ID: <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>

Hi Lucas,

On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> Hi Robin,
> 
> Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > > Hi
> > > >
> > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > <l.stach at pengutronix.de>
> > > wrote:
> > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > > > There are two requirements that we need to move the request of
> > > > > > dma channel from probe to open.
> > > > >
> > > > > How do you handle -EPROBE_DEFER return code from the channel
> > > > > request if you don't do it in probe?
> > > >
> > > > I use the dma_request_slave_channel or dma_request_channel instead
> > > > of dmaengine_pcm_request_chan_of. so there should be not
> > > > -EPROBE_DEFER return code.
> > >
> > > This is a pretty weak argument. The dmaengine device might probe
> > > after you try to get the channel. Using a function to request the
> > > channel that doesn't allow you to handle probe deferral is IMHO a
> > > bug and should be fixed, instead of building even more assumptions on top
> of it.
> > >
> > > > > > - When dma device binds with power-domains, the power will be
> > > > > > enabled when we request dma channel. If the request of dma
> > > > > > channel happen on probe, then the power-domains will be always
> > > > > > enabled after kernel boot up,  which is not good for power
> > > > > > saving,  so we need to move the request of dma channel to
> > > > > > .open();
> > > > >
> > > > > This is certainly something which could be fixed in the
> > > > > dmaengine driver.
> > > >
> > > > Dma driver always call the pm_runtime_get_sync in
> > > > device_alloc_chan_resources, the device_alloc_chan_resources is
> > > > called when channel is requested. so power is enabled on channel
> request.
> > >
> > > So why can't you fix the dmaengine driver to do that RPM call at a
> > > later time when the channel is actually going to be used? This will
> > > allow further power savings with other slave devices than the audio PCM.
> > Hi Lucas,
> > ??Thanks for your suggestion. I have tried to implement runtime
> > autosuspend in fsl-edma driver on i.mx8qm/qxp with delay time (2 sec)
> > for this feature as below (or you can refer to
> > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > pm_runtime_put_autosuspend in all dmaengine driver interface like
> > device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_cycli
> > c/
> > device_tx_status...
> >
> >
> > ????????????????pm_runtime_use_autosuspend(fsl_chan->dev);
> > ????????????????pm_runtime_set_autosuspend_delay(fsl_chan->dev,
> 2000);
> >
> > That could resolve this audio case since the autosuspend could suspend
> > runtime after
> > 2 seconds if there is no further dma transfer but only channel
> request(device_alloc_chan_resources).
> > But unfortunately, it cause another issue. As you know, on our
> > i.mx8qm/qxp, power domain done by scfw (drivers/firmware/imx/scu-pd.c)
> over mailbox:
> > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > imx_scu_ipc_write()->mbox_send_message()
> > which means have to 'waits for completion', meanwhile, some driver
> > like tty will call dmaengine interfaces in non-atomic case as below,
> >
> > static int uart_write(struct tty_struct *tty, const unsigned char
> > *buf, int count) {
> > ???.......
> > 	    port = uart_port_lock(state, flags);
> > ???......
> > ????????__uart_start(tty);  //call start_tx()->dmaengine_prep_slave_sg...
> > ????????uart_port_unlock(port, flags);
> > ????????return ret;
> > }
> >
> > Thus dma runtime resume may happen in that timing window and cause
> kernel alarm.
> > I'm not sure whether there are similar limitations on other driver
> > subsystem. But for me, It looks like the only way to resolve the
> > contradiction between tty and scu-pd (hardware limitation on
> > i.mx8qm/qxp) is to give up autosuspend and keep pm_runtime_get_sync
> only in device_alloc_chan_resources because request channel is a safe
> non-atomic phase.
> > Do you have any idea? Thanks in advance.
> 
> If you look closely at the driver you used as an example (hidma.c) it looks like
> there is already something in there, which looks very much like what you need
> here:
> 
> In hidma_issue_pending() the driver tries to get the device to runtime resume.
> If this doesn't work, maybe due to the power domain code not being able to
> be called in atomic context, the actual work of waking up the dma hardware
> and issuing the descriptor is shunted to a tasklet.
> 
> If I'm reading this right, this is exactly what you need here to be able to call the
> dmaengine code from atomic context: try the rpm get and issue immediately
> when possible, otherwise shunt the work to a non- atomic context where you
> can deal with the requirements of scu-pd.
Yes, I can schedule_work to worker to runtime resume edma channel by calling scu-pd.
But that means all dmaengine interfaces should be taken care, not only issue_pending()
but also dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
dmaengine_tx_status(). Not sure why hidma only take care issue_pending. Maybe
their user case is just for memcpy/memset so that no further complicate case as ALSA
or TTY.
Besides, for autosuspend in cyclic, we have to add pm_runtime_get_sync into interrupt
handler as qcom/bam_dma.c. but how could resolve the scu-pd's non-atmoic limitation
in interrupt handler?  

> 
> Also you don't need the runtime resume in all of the functions you mentioned.
> From a quick look into the edma driver it looks like for example the
> prep_slave_dma() function only touches data structures in memory, so you
> don't actually need the device to be awake at that point. Only later in the flow
> when you write registers in the dma hardware and actually issue the transfer
> you need to wake the device from sleep.
Yes, don't need add pm_runtime_get_sync into prep_slave_dma, only care where
HW indeed touched like issue_pending()/terminated_all()/pause()/resume..etc.
 


From m.tretter at pengutronix.de  Mon Apr 19 08:32:39 2021
From: m.tretter at pengutronix.de (Michael Tretter)
Date: Mon, 19 Apr 2021 09:32:39 +0200
Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
 PM_INIT_FINALIZE
In-Reply-To: <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>
References: <20210317160410.2097178-1-m.tretter@pengutronix.de>
 <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>
Message-ID: <20210419073239.GA12636@pengutronix.de>

Hi Rajan,

On Thu, 15 Apr 2021 16:27:58 +0000, Rajan Vaja wrote:
> Thanks for the patch.
> 
> > -----Original Message-----
> > From: Michael Tretter <m.tretter at pengutronix.de>
> > Sent: 17 March 2021 09:34 PM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: Michal Simek <michals at xilinx.com>; Rajan Vaja <RAJANV at xilinx.com>; Jolly
> > Shah <JOLLYS at xilinx.com>; m.tretter at pengutronix.de
> > Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix PM_INIT_FINALIZE
> > 
> > Patch 1 of this series fixes the ZynqMP PMU FW power management
> > initialization, which was done by the wrong driver. PM_INIT_FINALIZE must be
> > called from the zynqmp_pm_domains driver, which handles power domains, instead
> > of the zynmp_power driver, which is responsible for suspend and shutdown.
> [Rajan] I am fine with moving to genpd but zynqmp_pm_init_finalize() needs to be late call.
> zynqmp_pm_init_finalize() should be called when Linux has requested all the devices through
> genpd driver. Making it late call will make sure it. 

What is the reason why all devices have to be requested before calling
zynqmp_pm_init_finalize()?

I was expecting that calling PM_INIT_FINALIZE only would tell the PMU_FW that
Linux is using the PM API and the PMU_FW should power down/up PM slaves as
requested by Linux. It is somewhat surprising that this isn't the case and all
PM slaves have to be powered up before calling PM_INIT_FINALIZE.

What would happen if some driver is built as a module? In that case, the
module would be loaded and request the pm node only after PM_INIT_FINALIZE was
called. Do we have to avoid/disallow such cases?

For USB, I am actually observing a similar situation: If I do not request the
USB PM slave before I call PM_INIT_FINALIZE, I see communication errors with
connected USB devices. Could this be related?

Thanks,

Michael

> 
> > 
> > Patches 2 to 4 are various cleanup patches to improve the readability and
> > debugging experience of the zynqmp_pm_domains driver.
> > 
> > Michael
> > 
> > Michael Tretter (4):
> >   soc: xilinx: move PM_INIT_FINALIZE to zynqmp_pm_domains driver
> >   soc: xilinx: cleanup debug and error messages
> >   soc: xilinx: use a properly named field instead of flags
> >   soc: xilinx: add a to_zynqmp_pm_domain macro
> > 
> >  drivers/soc/xilinx/zynqmp_pm_domains.c | 79 +++++++++++++-------------
> >  drivers/soc/xilinx/zynqmp_power.c      |  1 -
> >  2 files changed, 38 insertions(+), 42 deletions(-)
> > 
> > --
> > 2.29.2


From narmstrong at baylibre.com  Mon Apr 19 08:32:39 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:39 +0200
Subject: [PATCH v3 0/5] mediatek: hdmi: add MT8167 configuration
Message-ID: <20210419073244.2678688-1-narmstrong@baylibre.com>

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes.

To achieve this:
- switch the mediatek HDMI bindings to YAML
- add the MT8167 compatible
- add a boolean to discard the non-CEA modes
- add a value to specify mac TMDS supported clock
- add a conf entry for the MT8167 compatible

Changes since v4:
- fixed bindings

Neil Armstrong (5):
  dt-bindings: display: mediatek,hdmi: Convert to use graph schema
  dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings
  gpu/drm: mediatek: hdmi: add check for CEA modes only
  gpu/drm: mediatek: hdmi: add optional limit on maximal HDMI mode clock
  gpu/drm: mediatek: hdmi: add MT8167 configuration

 .../display/mediatek/mediatek,cec.yaml        |  52 +++++++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  58 ++++++++
 .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
 .../display/mediatek/mediatek,hdmi.yaml       | 133 +++++++++++++++++
 drivers/gpu/drm/mediatek/mtk_hdmi.c           |  17 +++
 5 files changed, 260 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:32:40 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:40 +0200
Subject: [PATCH v3 1/5] dt-bindings: display: mediatek,
 hdmi: Convert to use graph schema
In-Reply-To: <20210419073244.2678688-1-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
Message-ID: <20210419073244.2678688-2-narmstrong@baylibre.com>

Update the mediatek,dpi binding to use the graph schema.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 .../display/mediatek/mediatek,cec.yaml        |  51 +++++++
 .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 ++++++++
 .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
 .../display/mediatek/mediatek,hdmi.yaml       | 132 +++++++++++++++++
 4 files changed, 240 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
new file mode 100644
index 000000000000..b38d8732d7e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI CEC Controller Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The HDMI CEC controller handles hotplug detection and CEC communication.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt7623-cec
+      - mediatek,mt8173-cec
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    cec: cec at 10013000 {
+        compatible = "mediatek,mt8173-cec";
+        reg = <0x10013000 0xbc>;
+        interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&infracfg CLK_INFRA_CEC>;
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
new file mode 100644
index 000000000000..c8ba94d6908b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI DDC Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt7623-hdmi-ddc
+      - mediatek,mt8173-hdmi-ddc
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  clock-names:
+    items:
+      - const: ddc-i2c
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    hdmi_ddc0: i2c at 11012000 {
+        compatible = "mediatek,mt8173-hdmi-ddc";
+        reg = <0x11012000 0x1c>;
+        interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&pericfg CLK_PERI_I2C5>;
+        clock-names = "ddc-i2c";
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
deleted file mode 100644
index b284ca51b913..000000000000
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-Mediatek HDMI Encoder
-=====================
-
-The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
-its parallel input.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-hdmi".
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
-  See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
-- phys: phandle link to the HDMI PHY node.
-  See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
-- phy-names: must contain "hdmi"
-- mediatek,syscon-hdmi: phandle link and register offset to the system
-  configuration registers. For mt8173 this must be offset 0x900 into the
-  MMSYS_CONFIG region: <&mmsys 0x900>.
-- ports: A node containing input and output port nodes with endpoint
-  definitions as documented in Documentation/devicetree/bindings/graph.txt.
-- port at 0: The input port in the ports node should be connected to a DPI output
-  port.
-- port at 1: The output port in the ports node should be connected to the input
-  port of a connector node that contains a ddc-i2c-bus property, or to the
-  input port of an attached bridge chip, such as a SlimPort transmitter.
-
-HDMI CEC
-========
-
-The HDMI CEC controller handles hotplug detection and CEC communication.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-cec"
-- the supported chips are mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clock
-
-HDMI DDC
-========
-
-The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
-The Mediatek's I2C controller is used to interface with I2C devices.
-
-Required properties:
-- compatible: Should be "mediatek,<chip>-hdmi-ddc"
-- the supported chips are mt7623 and mt8173
-- reg: Physical base address and length of the controller's registers
-- clocks: device clock
-- clock-names: Should be "ddc-i2c".
-
-HDMI PHY
-========
-See phy/mediatek,hdmi-phy.yaml
-
-Example:
-
-cec: cec at 10013000 {
-	compatible = "mediatek,mt8173-cec";
-	reg = <0 0x10013000 0 0xbc>;
-	interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&infracfg CLK_INFRA_CEC>;
-};
-
-hdmi_phy: hdmi-phy at 10209100 {
-	compatible = "mediatek,mt8173-hdmi-phy";
-	reg = <0 0x10209100 0 0x24>;
-	clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
-	clock-names = "pll_ref";
-	clock-output-names = "hdmitx_dig_cts";
-	mediatek,ibias = <0xa>;
-	mediatek,ibias_up = <0x1c>;
-	#clock-cells = <0>;
-	#phy-cells = <0>;
-};
-
-hdmi_ddc0: i2c at 11012000 {
-	compatible = "mediatek,mt8173-hdmi-ddc";
-	reg = <0 0x11012000 0 0x1c>;
-	interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&pericfg CLK_PERI_I2C5>;
-	clock-names = "ddc-i2c";
-};
-
-hdmi0: hdmi at 14025000 {
-	compatible = "mediatek,mt8173-hdmi";
-	reg = <0 0x14025000 0 0x400>;
-	interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>;
-	clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
-		 <&mmsys CLK_MM_HDMI_PLLCK>,
-		 <&mmsys CLK_MM_HDMI_AUDIO>,
-		 <&mmsys CLK_MM_HDMI_SPDIF>;
-	clock-names = "pixel", "pll", "bclk", "spdif";
-	pinctrl-names = "default";
-	pinctrl-0 = <&hdmi_pin>;
-	phys = <&hdmi_phy>;
-	phy-names = "hdmi";
-	mediatek,syscon-hdmi = <&mmsys 0x900>;
-	assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
-	assigned-clock-parents = <&hdmi_phy>;
-
-	ports {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		port at 0 {
-			reg = <0>;
-
-			hdmi0_in: endpoint {
-				remote-endpoint = <&dpi0_out>;
-			};
-		};
-
-		port at 1 {
-			reg = <1>;
-
-			hdmi0_out: endpoint {
-				remote-endpoint = <&hdmi_con_in>;
-			};
-		};
-	};
-};
-
-connector {
-	compatible = "hdmi-connector";
-	type = "a";
-	ddc-i2c-bus = <&hdmiddc0>;
-
-	port {
-		hdmi_con_in: endpoint {
-			remote-endpoint = <&hdmi0_out>;
-		};
-	};
-};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
new file mode 100644
index 000000000000..6a144faed682
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek HDMI Encoder Device Tree Bindings
+
+maintainers:
+  - CK Hu <ck.hu at mediatek.com>
+  - Jitao shi <jitao.shi at mediatek.com>
+
+description: |
+  The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
+  its parallel input.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt2701-hdmi
+      - mediatek,mt7623-hdmi
+      - mediatek,mt8173-hdmi
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: Pixel Clock
+      - description: HDMI PLL
+      - description: Bit Clock
+      - description: S/PDIF Clock
+
+  clock-names:
+    items:
+      - const: pixel
+      - const: pll
+      - const: bclk
+      - const: spdif
+
+  phys:
+    maxItems: 1
+
+  phy-names:
+    items:
+      - const: hdmi
+
+  mediatek,syscon-hdmi:
+    $ref: '/schemas/types.yaml#/definitions/phandle-array'
+    maxItems: 1
+    description: |
+      phandle link and register offset to the system configuration registers.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port at 0:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          Input port node. This port should be connected to a DPI output port.
+
+      port at 1:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: |
+          Output port node. This port should be connected to the input port of a connector
+          node that contains a ddc-i2c-bus property, or to the  input port of an attached
+          bridge chip, such as a SlimPort transmitter.
+
+    required:
+      - port at 0
+      - port at 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - phys
+  - phy-names
+  - mediatek,syscon-hdmi
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8173-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    hdmi0: hdmi at 14025000 {
+        compatible = "mediatek,mt8173-hdmi";
+        reg = <0x14025000 0x400>;
+        interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>;
+        clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+             <&mmsys CLK_MM_HDMI_PLLCK>,
+             <&mmsys CLK_MM_HDMI_AUDIO>,
+             <&mmsys CLK_MM_HDMI_SPDIF>;
+        clock-names = "pixel", "pll", "bclk", "spdif";
+        pinctrl-names = "default";
+        pinctrl-0 = <&hdmi_pin>;
+        phys = <&hdmi_phy>;
+        phy-names = "hdmi";
+        mediatek,syscon-hdmi = <&mmsys 0x900>;
+
+        ports {
+          #address-cells = <1>;
+          #size-cells = <0>;
+
+          port at 0 {
+            reg = <0>;
+
+            hdmi0_in: endpoint {
+              remote-endpoint = <&dpi0_out>;
+            };
+          };
+
+          port at 1 {
+            reg = <1>;
+
+            hdmi0_out: endpoint {
+              remote-endpoint = <&hdmi_con_in>;
+            };
+          };
+        };
+    };
+
+...
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:32:41 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:41 +0200
Subject: [PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi,
 hdmi-ddc and cec bindings
In-Reply-To: <20210419073244.2678688-1-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
Message-ID: <20210419073244.2678688-3-narmstrong@baylibre.com>

Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 .../devicetree/bindings/display/mediatek/mediatek,cec.yaml       | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml  | 1 +
 .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml      | 1 +
 3 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index b38d8732d7e0..66288b9f0aa6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt7623-cec
+      - mediatek,mt8167-cec
       - mediatek,mt8173-cec
 
   reg:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
index c8ba94d6908b..b6fcdfb99ab2 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt7623-hdmi-ddc
+      - mediatek,mt8167-hdmi-ddc
       - mediatek,mt8173-hdmi-ddc
 
   reg:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
index 6a144faed682..111967efa999 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
@@ -19,6 +19,7 @@ properties:
     enum:
       - mediatek,mt2701-hdmi
       - mediatek,mt7623-hdmi
+      - mediatek,mt8167-hdmi
       - mediatek,mt8173-hdmi
 
   reg:
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:32:42 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:42 +0200
Subject: [PATCH v3 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes only
In-Reply-To: <20210419073244.2678688-1-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
Message-ID: <20210419073244.2678688-4-narmstrong@baylibre.com>

Some SoCs like the MT8167 are not validated and supported for HDMI modes
out of HDMI CEA modes, so add a configuration boolean to filter out
non-CEA modes.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index dea46d66e712..0539262e69d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -148,6 +148,7 @@ struct hdmi_audio_param {
 
 struct mtk_hdmi_conf {
 	bool tz_disabled;
+	bool cea_modes_only;
 };
 
 struct mtk_hdmi {
@@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
 			return MODE_BAD;
 	}
 
+	if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
+		return MODE_BAD;
+
 	if (mode->clock < 27000)
 		return MODE_CLOCK_LOW;
 	if (mode->clock > 297000)
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:32:43 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:43 +0200
Subject: [PATCH v3 4/5] gpu/drm: mediatek: hdmi: add optional limit on maximal
 HDMI mode clock
In-Reply-To: <20210419073244.2678688-1-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
Message-ID: <20210419073244.2678688-5-narmstrong@baylibre.com>

Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
clock, so add a configuration value to filter out those modes.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0539262e69d3..bc50d97f2553 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -149,6 +149,7 @@ struct hdmi_audio_param {
 struct mtk_hdmi_conf {
 	bool tz_disabled;
 	bool cea_modes_only;
+	unsigned long max_mode_clock;
 };
 
 struct mtk_hdmi {
@@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
 	if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
 		return MODE_BAD;
 
+	if (hdmi->conf->max_mode_clock &&
+	    mode->clock > hdmi->conf->max_mode_clock)
+		return MODE_CLOCK_HIGH;
+
 	if (mode->clock < 27000)
 		return MODE_CLOCK_LOW;
 	if (mode->clock > 297000)
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:32:44 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:32:44 +0200
Subject: [PATCH v3 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration
In-Reply-To: <20210419073244.2678688-1-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
Message-ID: <20210419073244.2678688-6-narmstrong@baylibre.com>

The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
and is not validated and supported for HDMI modes out of HDMI CEA modes,
so add a configuration entry linked to the MT8167 compatible.

Signed-off-by: Fabien Parent <fparent at baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index bc50d97f2553..c1651a83700d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
 	.tz_disabled = true,
 };
 
+static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
+	.max_mode_clock = 148500,
+	.cea_modes_only = true,
+};
+
 static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
 	{ .compatible = "mediatek,mt2701-hdmi",
 	  .data = &mtk_hdmi_conf_mt2701,
 	},
+	{ .compatible = "mediatek,mt8167-hdmi",
+	  .data = &mtk_hdmi_conf_mt8167,
+	},
 	{ .compatible = "mediatek,mt8173-hdmi",
 	},
 	{}
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 19 08:36:42 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 19 Apr 2021 09:36:42 +0200
Subject: [v2,PATCH 1/3] drm/mediatek: dpi dual edge sample mode support
In-Reply-To: <1618407316-10042-2-git-send-email-rex-bc.chen@mediatek.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-2-git-send-email-rex-bc.chen@mediatek.com>
Message-ID: <a1ffcce8-621e-7493-22d4-e28ff09c31a4@baylibre.com>

Hi,

On 14/04/2021 15:35, Rex-BC Chen wrote:
> DPI can sample on falling, rising or both edge.
> When DPI sample the data both rising and falling edge.
> It can reduce half data io pins.
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index b05f900d9322..21a3a7b78835 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -83,6 +83,7 @@ struct mtk_dpi {
>  	struct pinctrl *pinctrl;
>  	struct pinctrl_state *pins_gpio;
>  	struct pinctrl_state *pins_dpi;
> +	bool ddr_edge_sel;
>  	int refcount;
>  };
>  
> @@ -121,6 +122,7 @@ struct mtk_dpi_conf {
>  	unsigned int (*cal_factor)(int clock);
>  	u32 reg_h_fre_con;
>  	bool edge_sel_en;
> +	bool dual_edge;
>  };
>  
>  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
> @@ -380,6 +382,15 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
>  	}
>  }
>  
> +static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
> +{
> +	if (dpi->conf->dual_edge) {
> +		mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> +			     DDR_EN | DDR_4PHASE);
> +		mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, dpi->ddr_edge_sel ? EDGE_SEL : 0, EDGE_SEL);
> +	}
> +}
> +

By using the downstream code as reference:

-       clk_set_rate(dpi->pixel_clk, vm.pixelclock);
+       clk_set_rate(dpi->pixel_clk, vm.pixelclock * (dpi->conf->dual_edge ? 2 : 1));

is missing in mtk_dpi_set_display_mode()

>  static void mtk_dpi_power_off(struct mtk_dpi *dpi)
>  {
>  	if (WARN_ON(dpi->refcount == 0))
> @@ -518,6 +529,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>  	mtk_dpi_config_yc_map(dpi, dpi->yc_map);
>  	mtk_dpi_config_color_format(dpi, dpi->color_format);
>  	mtk_dpi_config_2n_h_fre(dpi);
> +	mtk_dpi_dual_edge(dpi);
>  	mtk_dpi_config_disable_edge(dpi);
>  	mtk_dpi_sw_reset(dpi, false);
>  
> 

Neil


From gabriel.fernandez at foss.st.com  Mon Apr 19 08:46:27 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 09:46:27 +0200
Subject: [PATCH 1/7] clk: stm32mp1: Split ETHCK_K into separate MUX and
 GATE clock
In-Reply-To: <2281af74-33a0-df45-968b-baa1ddd9d6e0@denx.de>
References: <20210408185731.135511-1-marex@denx.de>
 <20210408185731.135511-2-marex@denx.de>
 <2b10f5d9-54cb-ce83-b7aa-f4ec8e67c001@foss.st.com>
 <92dd5798-8f5a-66e4-06bc-e3beb16690f5@denx.de>
 <d168aed8-aebd-1bee-aa72-3a3601718cad@foss.st.com>
 <e27dbccd-518f-7718-8cf7-cc9c8adb8a56@denx.de>
 <6416577a-ea06-a014-543a-9ef86aae603d@foss.st.com>
 <2281af74-33a0-df45-968b-baa1ddd9d6e0@denx.de>
Message-ID: <8481872c-9ee0-c759-3ab0-5209165ad9b2@foss.st.com>

Hi Marek,

On 4/16/21 5:31 PM, Marek Vasut wrote:
> On 4/16/21 5:23 PM, Alexandre TORGUE wrote:
> 
> Hello Alexandre,
> 
>> On 4/16/21 3:47 PM, Marek Vasut wrote:
>>> On 4/16/21 8:44 AM, gabriel.fernandez at foss.st.com wrote:
>>>> Hi Marek
>>>
>>> Hello Gabriel,
>>>
>>>> On 4/14/21 4:04 PM, Marek Vasut wrote:
>>>>> On 4/14/21 3:03 PM, gabriel.fernandez at foss.st.com wrote:
>>>>>> Hi Marek,
>>>>>
>>>>> Hello Gabriel,
>>>>>
>>>>>> Thanks for the patchset
>>>>>>
>>>>>> On 4/8/21 8:57 PM, Marek Vasut wrote:
>>>>>>> The ETHCK_K are modeled as composite clock of MUX and GATE, 
>>>>>>> however per
>>>>>>> STM32MP1 Reference Manual RM0436 Rev 3, Page 574, Figure 83. 
>>>>>>> Peripheral
>>>>>>> clock distribution for Ethernet, ETHPTPDIV divider is attached 
>>>>>>> past the
>>>>>>> ETHCK_K mux, and ETH_CLK/eth_clk_fb clock are output past ETHCKEN 
>>>>>>> gate.
>>>>>>> Therefore, in case ETH_CLK/eth_clk_fb are not in use AND PTP 
>>>>>>> clock are
>>>>>>> in use, ETHCKEN gate can be turned off. Current driver does not 
>>>>>>> permit
>>>>>>> that, fix it.
>>>>>>
>>>>>> I don"t understand, it's already the case.
>>>>>>
>>>>>> ETHCK_K it's a composite with a MUX and a GATE.
>>>>>
>>>>> But ETHCK_K is _not_ a composite clock, look at the Figure 83 in 
>>>>> the datasheet again and schematic below.
>>>>>
>>>>>> ETHPTP_K (ETHPTPDIV) it's a composite with the same MUX and a DIV 
>>>>>> (no gate)
>>>>>
>>>>> But ETHPTP_K shouldn't control any mux, it is only a divider.
>>>>>
>>>>>> If you use only ETHPTPDIV,? ETHCKEN gate can be turned off.
>>>>>
>>>>> Look, this is what you have today:
>>>>>
>>>>> ??????????? .------------ ETHCK_K -----------.
>>>>> ??????????? |_______?????????????? _______?? |
>>>>> pll4_p_ck--|M_ETHCK\???????????? |G_ETHCK\? |
>>>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>>>> ??????????? |?????????????? |
>>>>> ??????????? |?????????????? '--(ETHCKSELR[7:4] divider)--[x] 
>>>>> clk_ptp_ref
>>>>> ??????????? |????????????????????????????????????????? |
>>>>> ??????????? '------------ ETHPTP_K --------------------'
>>>>>
>>>>> And this is what you should have, to avoid having two composite 
>>>>> clock which control the same mux using the same register bit, i.e. 
>>>>> what this patch implements:
>>>>>
>>>>> ??????????? .- ck_ker_eth -.? .--- ETHCK_K --.
>>>>> ??????????? |_______?????? |? |??? _______?? |
>>>>> pll4_p_ck--|M_ETHCK\????? |? |?? |G_ETHCK\? |
>>>>> ??????????? | MUX??? |------+-----| GATE?? |-------------[x] ETH_CLK
>>>>> pll3_q_ck--|_______/?????? |???? |_______/????????????????? eth_clk_fb
>>>>> ??????????????????????????? |
>>>>> ??????????????????????????? '--(ETHCKSELR[7:4] divider)--[x] 
>>>>> clk_ptp_ref
>>>>> ???????????????????????????? |???????????????????????? |
>>>>> ???????????????????????????? '---- ETHPTP_K -----------'
>>>>>
>>>>
>>>> These 2 solutions are valid. I made the choice to implement the 
>>>> first one to be able to change parent with the kernel clock of the 
>>>> IP (no need to add an intermediate binding).
>>>
>>> Which IP are you talking about in here ?
>>>
>>>> It's the same principle for all kernel of this soc.
>>>
>>> The first option is wrong, because in that model, you have two 
>>> composite clock which control the same one mux bit in the same 
>>> register. Basically you register two distinct clock which operate the 
>>> same hardware knob.
>>>
>>>> I can ask to Alexandre to comeback of this principle, but i 'm not 
>>>> favorable.
>>>
>>
>> The only discussing thing is how the clock is shown. I mean either two 
>> composites or one mux plus two gates. Gabriel made a choice to 
>> abstract the mux in two composite clocks. But it seems that at the end 
>> we have the same behaviour, isn't ?
> 
> Not really. Since the two composite clock control the same mux bit, 
> consider what would happen if you were to select pll4_p_ck as parent for 
> one (e.g. ETHCK_K), and pll3_q_ck as parent for the other (e.g. 
> ETHPTP_K), what would be the result ? I guess the result would depend on 
> when the reparenting of each ETHCK_K/ETHPTP_K happens on boot, and I 
> don't think that's how it should work. With a single mux controlling 
> that one single bit, such situation wouldn't happen.

The reparenting is managed. This mux has specific ops.
root at stm32mp1-disco-oss:~# cat /sys/kernel/debug/clk/ethck_k/clk_parent 
&& cat /sys/kernel/debug/clk/ethptp_k/clk_parent
pll4_p
pll4_p
root at stm32mp1-disco-oss:~# echo pll3_q > 
/sys/kernel/debug/clk/ethptp_k/clk_set_parent
root at stm32mp1-disco-oss:~# cat /sys/kernel/debug/clk/ethck_k/clk_parent 
&& cat /sys/kernel/debug/clk/ethptp_k/clk_parent
pll3_q
pll3_q

> 
>> Adding "ck_ker_eth" would impose a new clock to take in DT ?
> Nope, the ck_ker_eth is without ID and internal to the driver. They 
> exist only to describe the clock tree correctly.
> 
> [...]


From peterz at infradead.org  Mon Apr 19 08:46:52 2021
From: peterz at infradead.org (Peter Zijlstra)
Date: Mon, 19 Apr 2021 09:46:52 +0200
Subject: [PATCH v5 04/19] perf: aux: Add CoreSight PMU buffer formats
In-Reply-To: <20210329165625.GC2236953@xps15>
References: <20210323120647.454211-1-suzuki.poulose@arm.com>
 <20210323120647.454211-5-suzuki.poulose@arm.com>
 <20210329165625.GC2236953@xps15>
Message-ID: <YH01bIpu5MSwyqPt@hirez.programming.kicks-ass.net>

On Mon, Mar 29, 2021 at 10:56:25AM -0600, Mathieu Poirier wrote:
> Hi Peter,
> 
> On Tue, Mar 23, 2021 at 12:06:32PM +0000, Suzuki K Poulose wrote:
> > CoreSight PMU supports aux-buffer for the ETM tracing. The trace
> > generated by the ETM (associated with individual CPUs, like Intel PT)
> > is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
> > 
> > The TMC-ETR applies formatting of the raw ETM trace data, as it
> > can collect traces from multiple ETMs, with the TraceID to indicate
> > the source of a given trace packet.
> > 
> > Arm Trace Buffer Extension is new "sink" IP, attached to individual
> > CPUs and thus do not provide additional formatting, like TMC-ETR.
> > 
> > Additionally, a system could have both TRBE *and* TMC-ETR for
> > the trace collection. e.g, TMC-ETR could be used as a single
> > trace buffer to collect data from multiple ETMs to correlate
> > the traces from different CPUs. It is possible to have a
> > perf session where some events end up collecting the trace
> > in TMC-ETR while the others in TRBE. Thus we need a way
> > to identify the type of the trace for each AUX record.
> > 
> > Define the trace formats exported by the CoreSight PMU.
> > We don't define the flags following the "ETM" as this
> > information is available to the user when issuing
> > the session. What is missing is the additional
> > formatting applied by the "sink" which is decided
> > at the runtime and the user may not have a control on.
> > 
> > So we define :
> >  - CORESIGHT format (indicates the Frame format)
> >  - RAW format (indicates the format of the source)
> > 
> > The default value is CORESIGHT format for all the records
> > (i,e == 0). Add the RAW format for others that use
> > raw format.
> > 
> > Cc: Peter Zijlstra <peterz at infradead.org>
> > Cc: Mike Leach <mike.leach at linaro.org>
> > Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
> > Cc: Leo Yan <leo.yan at linaro.org>
> > Cc: Anshuman Khandual <anshuman.khandual at arm.com>
> > Reviewed-by: Mike Leach <mike.leach at linaro.org>
> > Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> > Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> > ---
> >  include/uapi/linux/perf_event.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > index f006eeab6f0e..63971eaef127 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -1162,6 +1162,10 @@ enum perf_callchain_context {
> >  #define PERF_AUX_FLAG_COLLISION			0x08	/* sample collided with another */
> >  #define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK	0xff00	/* PMU specific trace format type */
> >  
> > +/* CoreSight PMU AUX buffer formats */
> > +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT	0x0000 /* Default for backward compatibility */
> > +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW		0x0100 /* Raw format of the source */
> > +
> 
> Have you had time to review this patch?  Anything you'd like to see modified?

Ok I suppose..

Acked-by: Peter Zijlstra (Intel) <peterz at infradead.org>


From wangqing at vivo.com  Mon Apr 19 08:50:56 2021
From: wangqing at vivo.com (Wang Qing)
Date: Mon, 19 Apr 2021 15:50:56 +0800
Subject: [PATCH V4] watchdog: mtk: support dual mode when the bark irq is
 available
Message-ID: <1618818656-32410-1-git-send-email-wangqing@vivo.com>

Support using irq handling wdt bark first instead of directly resetting.

When the watchdog timer expires in Dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires, to prevent the system is stuck hard.

The dual mode is disabled by default.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 33 +++++++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..a1f34b5
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -57,6 +58,7 @@
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 static unsigned int timeout;
+static bool dual_mode;
 
 struct mtk_wdt_dev {
 	struct watchdog_device wdt_dev;
@@ -239,13 +241,23 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (dual_mode)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	panic("wdt bark!\n");
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -267,7 +279,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,6 +291,20 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
+	if (dual_mode) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq > 0) {
+			err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+									&mtk_wdt->wdt_dev);
+			if (err)
+				return err;
+		} else {
+			dual_mode = 0;
+			dev_err(&pdev->dev,
+			"couldn't get wdt irq, set dual_mode = 0\n");
+		}
+	}
+
 	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
@@ -368,6 +394,9 @@ module_param(nowayout, bool, 0);
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
 			__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
+module_param(dual_mode, bool, 0);
+MODULE_PARM_DESC(dual_mode, "Watchdog dual mode triggers irq before reset(default=0)");
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Matthias Brugger <matthias.bgg at gmail.com>");
 MODULE_DESCRIPTION("Mediatek WatchDog Timer Driver");
-- 
2.7.4



From pablo at netfilter.org  Mon Apr 19 09:06:10 2021
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Mon, 19 Apr 2021 10:06:10 +0200
Subject: drivers/net/ethernet/mediatek/mtk_ppe_offload.c - suspicious code?
In-Reply-To: <526789.1618794132@turing-police>
References: <526789.1618794132@turing-police>
Message-ID: <20210419080610.GA24040@salvia>

On Sun, Apr 18, 2021 at 09:02:12PM -0400, Valdis Kl?tnieks wrote:
> While doing some code auditing for -Woverride_init, I spotted some questionable code
> 
> commit 502e84e2382d92654a2ecbc52cdbdb5a11cdcec7
> Author: Felix Fietkau <nbd at nbd.name>
> Date:   Wed Mar 24 02:30:54 2021 +0100
> 
>     net: ethernet: mtk_eth_soc: add flow offloading support
> 
> In drivers/net/ethernet/mediatek/mtk_ppe_offload.c:
> 
> +static const struct rhashtable_params mtk_flow_ht_params = {
> +       .head_offset = offsetof(struct mtk_flow_entry, node),
> +       .head_offset = offsetof(struct mtk_flow_entry, cookie),
> +       .key_len = sizeof(unsigned long),
> +       .automatic_shrinking = true,
> +};
> 
> What's intended for head_offset here?

It's a bug, there's a fix here:

https://www.spinics.net/lists/netdev/msg736368.html


From james.clark at arm.com  Mon Apr 19 09:18:31 2021
From: james.clark at arm.com (James Clark)
Date: Mon, 19 Apr 2021 11:18:31 +0300
Subject: [PATCH v2 0/2] perf cs-etm: Set time on synthesised samples to
 preserve ordering
In-Reply-To: <YHmqZKGMFydbsvEy@kernel.org>
References: <20210416105632.8771-1-james.clark@arm.com>
 <20210416150709.GA1046932@xps15> <YHmqZKGMFydbsvEy@kernel.org>
Message-ID: <c3a75731-15b4-e052-1840-a881b05862df@arm.com>



On 16/04/2021 18:16, Arnaldo Carvalho de Melo wrote:
> Em Fri, Apr 16, 2021 at 09:07:09AM -0600, Mathieu Poirier escreveu:
>> Hi James,
>>
>> On Fri, Apr 16, 2021 at 01:56:30PM +0300, James Clark wrote:
>>> Changes since v1:
>>>  * Improved variable name from etm_timestamp -> cs_timestamp
>>>  * Fixed ordering of Signed-off-by
>>>
>>
>> You forgot to add the RB and AB you received.  Since Arnaldo is responsible for
>> the perf tools subsystem, please send another revision.
>  
> 
> 
> Yep, please collect Reported-by and Acked-by as you go sending new
> versions of a patchset, the last one I don't have a problem collecting
> myself, but if you have to resend, please collect the feedback tags.
> 
> - Arnaldo
> 

Ok thanks, I will keep that in mind for the future. I wasn't sure if they still
applied or not as it was a new version.

Thanks
James

>> Thanks,
>> Mathieu
>>
>>> James Clark (2):
>>>   perf cs-etm: Refactor timestamp variable names
>>>   perf cs-etm: Set time on synthesised samples to preserve ordering
>>>
>>>  .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 18 +++----
>>>  tools/perf/util/cs-etm.c                      | 52 ++++++++++---------
>>>  tools/perf/util/cs-etm.h                      |  4 +-
>>>  3 files changed, 39 insertions(+), 35 deletions(-)
>>>
>>> -- 
>>> 2.28.0
>>>
> 


From andy.shevchenko at gmail.com  Mon Apr 19 09:31:14 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 11:31:14 +0300
Subject: [RESEND PATCH] pinctrl: mediatek: use spin lock in mtk_rmw
In-Reply-To: <20210419052136.2475373-1-tzungbi@google.com>
References: <20210419052136.2475373-1-tzungbi@google.com>
Message-ID: <CAHp75VfgSaRmqg96KSabmwnf6xQRMM6GQi3XAv-cJb+Lhg91cQ@mail.gmail.com>

On Mon, Apr 19, 2021 at 8:32 AM Tzung-Bi Shih <tzungbi at google.com> wrote:
>
> Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
> mutex lock in mtk_rmw.  However the function is possible called from
> atomic context.
>
> For example call trace:

Please, shrink it to the necessary minimum.

>   mutex_lock+0x28/0x64
>   mtk_rmw+0x38/0x80
>   mtk_hw_set_value+0x100/0x138
>   mtk_gpio_set+0x48/0x58
>   gpiod_set_raw_value_commit+0xf4/0x110
>   gpiod_set_value_nocheck+0x4c/0x80
>   gpiod_set_value+0x4c/0x6c
>   max98357a_daiops_trigger+0x8c/0x9c
>   soc_pcm_trigger+0x5c/0x10c
>
> The max98357a_daiops_trigger() could run in either atomic or non-atomic
> context.  As a result, dmesg shows some similar messages: "BUG: sleeping
> function called from invalid context at kernel/locking/mutex.c:254".
>
> Uses spin lock in mtk_rmw instead.

It's nice, but now the question is, can you have this function be
called in a non-IRQ context concurrently with IRQ accessing registers?


-- 
With Best Regards,
Andy Shevchenko


From daniel.lezcano at linaro.org  Mon Apr 19 09:33:02 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 19 Apr 2021 10:33:02 +0200
Subject: [PATCH v3] drivers/clocksource/mediatek: Ack and disable
 interrupts on suspend
In-Reply-To: <20210412132200.v3.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid>
References: <20210412132200.v3.1.I1d9917047de06715da16e1620759f703fcfdcbcb@changeid>
Message-ID: <3e4803f8-7c38-6f71-fc89-2fa763e3395e@linaro.org>

On 12/04/2021 05:22, Evan Benn wrote:
> Interrupts are disabled during suspend before this driver disables its
> timers. ARM trusted firmware will abort suspend if the timer irq is
> pending, so ack and disable the timer interrupt during suspend.
> 
> Signed-off-by: Evan Benn <evanbenn at chromium.org>
> ---
> 
> Changes in v3:
> Move the ACK from the shutdown to the suspend function.
> 
> Changes in v2:
> Remove the patch that splits the drivers into 2 files.
> 
>  drivers/clocksource/timer-mediatek.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 9318edcd8963..1ae8fee639bf 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -241,6 +241,27 @@ static void mtk_gpt_enable_irq(struct timer_of *to, u8 timer)
>  	       timer_of_base(to) + GPT_IRQ_EN_REG);
>  }
>  
> +static void mtk_gpt_resume(struct clock_event_device *clk)
> +{
> +	struct timer_of *to = to_timer_of(clk);
> +
> +	mtk_gpt_enable_irq(to, TIMER_CLK_EVT);
> +}
> +
> +static void mtk_gpt_suspend(struct clock_event_device *clk)
> +{
> +	struct timer_of *to = to_timer_of(clk);
> +
> +	/* Disable all interrupts */
> +	writel(0x0, timer_of_base(to) + GPT_IRQ_EN_REG);
> +
> +	/* This is called with interrupts disabled,

Please fix the comment style:

	/*
	 * This is called with interrupts disabled
	 * so ...
	 * ...
	 */

Other than than that I'll be happy to pick it.

> +	 * so we need to ack any interrupt that is pending
> +	 * Or for example ATF will prevent a suspend from completing.
> +	 */
> +	writel(0x3f, timer_of_base(to) + GPT_IRQ_ACK_REG);
> +}
> +
>  static struct timer_of to = {
>  	.flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
>  
> @@ -286,6 +307,8 @@ static int __init mtk_gpt_init(struct device_node *node)
>  	to.clkevt.set_state_oneshot = mtk_gpt_clkevt_shutdown;
>  	to.clkevt.tick_resume = mtk_gpt_clkevt_shutdown;
>  	to.clkevt.set_next_event = mtk_gpt_clkevt_next_event;
> +	to.clkevt.suspend = mtk_gpt_suspend;
> +	to.clkevt.resume = mtk_gpt_resume;
>  	to.of_irq.handler = mtk_gpt_interrupt;
>  
>  	ret = timer_of_init(node, &to);
> 


-- 
<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 kishon at ti.com  Mon Apr 19 09:33:54 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:54 +0530
Subject: [PATCH v5 0/7] Add SR-IOV support in PCIe Endpoint Core
Message-ID: <20210419083401.31628-1-kishon@ti.com>

Patch series
*) Adds support to add virtual functions to enable endpoint controller
   which supports SR-IOV capability
*) Add support in Cadence endpoint driver to configure virtual functions
*) Enable pci_endpoint_test driver to create pci_device for virtual
   functions

v1 of the patch series can be found at [1]
v2 of the patch series can be found at [2]
v3 of the patch series can be found at [3]
v4 of the patch series can be found at [4]

Here both physical functions and virtual functions use the same
pci_endpoint_test driver and existing pcitest utility can be used
to test virtual functions as well.

Changes from v4:
*) Added a fix in Cadence driver which was overwriting BAR configuration
   of physical function.
*) Didn't include Tom's Acked-by since Cadence driver is modified in
   this revision.

Changes from v3:
*) Fixed Rob's comment and added his Reviewed-by as suggested by him.

Changes from v2:
*) Fixed DT binding documentation comment by Rob
*) Fixed the error check in pci-epc-core.c

Changes from v1:
*) Re-based and Re-worked to latest kernel 5.10.0-rc2+ (now has generic
   binding for EP)

[1] -> http://lore.kernel.org/r/20191231113534.30405-1-kishon at ti.com
[2] -> http://lore.kernel.org/r/20201112175358.2653-1-kishon at ti.com
[3] -> https://lore.kernel.org/r/20210305050410.9201-1-kishon at ti.com
[4] -> http://lore.kernel.org/r/20210310160943.7606-1-kishon at ti.com

Kishon Vijay Abraham I (7):
  dt-bindings: PCI: pci-ep: Add binding to specify virtual function
  PCI: endpoint: Add support to add virtual function in endpoint core
  PCI: endpoint: Add support to link a physical function to a virtual
    function
  PCI: endpoint: Add virtual function number in pci_epc ops
  PCI: cadence: Add support to configure virtual functions
  misc: pci_endpoint_test: Populate sriov_configure ops to configure
    SR-IOV device
  Documentation: PCI: endpoint/pci-endpoint-cfs: Guide to use SR-IOV

 .../PCI/endpoint/pci-endpoint-cfs.rst         |  12 +-
 .../devicetree/bindings/pci/pci-ep.yaml       |   7 +
 drivers/misc/pci_endpoint_test.c              |   1 +
 .../pci/controller/cadence/pcie-cadence-ep.c  | 285 ++++++++++++++----
 drivers/pci/controller/cadence/pcie-cadence.h |   7 +
 .../pci/controller/dwc/pcie-designware-ep.c   |  36 +--
 drivers/pci/controller/pcie-rcar-ep.c         |  19 +-
 drivers/pci/controller/pcie-rockchip-ep.c     |  18 +-
 drivers/pci/endpoint/functions/pci-epf-ntb.c  |  79 +++--
 drivers/pci/endpoint/functions/pci-epf-test.c |  66 ++--
 drivers/pci/endpoint/pci-ep-cfs.c             |  24 ++
 drivers/pci/endpoint/pci-epc-core.c           | 130 +++++---
 drivers/pci/endpoint/pci-epf-core.c           | 144 ++++++++-
 include/linux/pci-epc.h                       |  57 ++--
 include/linux/pci-epf.h                       |  16 +-
 15 files changed, 684 insertions(+), 217 deletions(-)

-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:33:55 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:55 +0530
Subject: [PATCH v5 1/7] dt-bindings: PCI: pci-ep: Add binding to specify
 virtual function
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-2-kishon@ti.com>

Add binding to specify virtual function (associated with each physical
function) in endpoint mode.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/pci/pci-ep.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/pci-ep.yaml b/Documentation/devicetree/bindings/pci/pci-ep.yaml
index 7847bbcd4a03..ccec51ab5247 100644
--- a/Documentation/devicetree/bindings/pci/pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/pci-ep.yaml
@@ -23,6 +23,13 @@ properties:
     default: 1
     maximum: 255
 
+  max-virtual-functions:
+    description: Array representing the number of virtual functions corresponding to each physical
+      function
+    $ref: /schemas/types.yaml#/definitions/uint8-array
+    minItems: 1
+    maxItems: 255
+
   max-link-speed:
     $ref: /schemas/types.yaml#/definitions/uint32
     enum: [ 1, 2, 3, 4 ]
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:33:56 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:56 +0530
Subject: [PATCH v5 2/7] PCI: endpoint: Add support to add virtual function in
 endpoint core
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-3-kishon@ti.com>

Add support to add virtual function in endpoint core. The virtual
function can only be associated with a physical function instead of a
endpoint controller. Provide APIs to associate a virtual function with
a physical function here.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/pci/endpoint/pci-epc-core.c |  2 +-
 drivers/pci/endpoint/pci-epf-core.c | 96 ++++++++++++++++++++++++++++-
 include/linux/pci-epf.h             | 16 ++++-
 3 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index cc8f9eb2b177..fe6d23849502 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -548,7 +548,7 @@ int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
 	u32 func_no;
 	int ret = 0;
 
-	if (IS_ERR_OR_NULL(epc))
+	if (IS_ERR_OR_NULL(epc) || epf->is_vf)
 		return -EINVAL;
 
 	if (type == PRIMARY_INTERFACE && epf->epc)
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index 7646c8660d42..3f1271a63be5 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -62,13 +62,20 @@ EXPORT_SYMBOL_GPL(pci_epf_type_add_cfs);
  */
 void pci_epf_unbind(struct pci_epf *epf)
 {
+	struct pci_epf *epf_vf;
+
 	if (!epf->driver) {
 		dev_WARN(&epf->dev, "epf device not bound to driver\n");
 		return;
 	}
 
 	mutex_lock(&epf->lock);
-	epf->driver->ops->unbind(epf);
+	list_for_each_entry(epf_vf, &epf->pci_vepf, list) {
+		if (epf_vf->is_bound)
+			epf_vf->driver->ops->unbind(epf_vf);
+	}
+	if (epf->is_bound)
+		epf->driver->ops->unbind(epf);
 	mutex_unlock(&epf->lock);
 	module_put(epf->driver->owner);
 }
@@ -83,6 +90,7 @@ EXPORT_SYMBOL_GPL(pci_epf_unbind);
  */
 int pci_epf_bind(struct pci_epf *epf)
 {
+	struct pci_epf *epf_vf;
 	int ret;
 
 	if (!epf->driver) {
@@ -94,13 +102,95 @@ int pci_epf_bind(struct pci_epf *epf)
 		return -EAGAIN;
 
 	mutex_lock(&epf->lock);
+	list_for_each_entry(epf_vf, &epf->pci_vepf, list) {
+		epf_vf->func_no = epf->func_no;
+		epf_vf->epc = epf->epc;
+		epf_vf->sec_epc = epf->sec_epc;
+		ret = epf_vf->driver->ops->bind(epf_vf);
+		if (ret)
+			goto ret;
+		epf_vf->is_bound = true;
+	}
+
 	ret = epf->driver->ops->bind(epf);
+	if (ret)
+		goto ret;
+	epf->is_bound = true;
+
+	mutex_unlock(&epf->lock);
+	return 0;
+
+ret:
 	mutex_unlock(&epf->lock);
+	pci_epf_unbind(epf);
 
 	return ret;
 }
 EXPORT_SYMBOL_GPL(pci_epf_bind);
 
+/**
+ * pci_epf_add_vepf() - associate virtual EP function to physical EP function
+ * @epf_pf: the physical EP function to which the virtual EP function should be
+ *   associated
+ * @epf_vf: the virtual EP function to be added
+ *
+ * A physical endpoint function can be associated with multiple virtual
+ * endpoint functions. Invoke pci_epf_add_epf() to add a virtual PCI endpoint
+ * function to a physical PCI endpoint function.
+ */
+int pci_epf_add_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf)
+{
+	u32 vfunc_no;
+
+	if (IS_ERR_OR_NULL(epf_pf) || IS_ERR_OR_NULL(epf_vf))
+		return -EINVAL;
+
+	if (epf_pf->epc || epf_vf->epc || epf_vf->epf_pf)
+		return -EBUSY;
+
+	if (epf_pf->sec_epc || epf_vf->sec_epc)
+		return -EBUSY;
+
+	mutex_lock(&epf_pf->lock);
+	vfunc_no = find_first_zero_bit(&epf_pf->vfunction_num_map,
+				       BITS_PER_LONG);
+	if (vfunc_no >= BITS_PER_LONG)
+		return -EINVAL;
+
+	set_bit(vfunc_no, &epf_pf->vfunction_num_map);
+	epf_vf->vfunc_no = vfunc_no;
+
+	epf_vf->epf_pf = epf_pf;
+	epf_vf->is_vf = true;
+
+	list_add_tail(&epf_vf->list, &epf_pf->pci_vepf);
+	mutex_unlock(&epf_pf->lock);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_epf_add_vepf);
+
+/**
+ * pci_epf_remove_vepf() - remove virtual EP function from physical EP function
+ * @epf_pf: the physical EP function from which the virtual EP function should
+ *   be removed
+ * @epf_vf: the virtual EP function to be removed
+ *
+ * Invoke to remove a virtual endpoint function from the physcial endpoint
+ * function.
+ */
+void pci_epf_remove_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf)
+{
+	if (IS_ERR_OR_NULL(epf_pf) || IS_ERR_OR_NULL(epf_vf))
+		return;
+
+	mutex_lock(&epf_pf->lock);
+	clear_bit(epf_vf->vfunc_no, &epf_pf->vfunction_num_map);
+	list_del(&epf_vf->list);
+	mutex_unlock(&epf_pf->lock);
+}
+EXPORT_SYMBOL_GPL(pci_epf_remove_vepf);
+
 /**
  * pci_epf_free_space() - free the allocated PCI EPF register space
  * @epf: the EPF device from whom to free the memory
@@ -317,6 +407,10 @@ struct pci_epf *pci_epf_create(const char *name)
 		return ERR_PTR(-ENOMEM);
 	}
 
+	/* VFs are numbered starting with 1. So set BIT(0) by default */
+	epf->vfunction_num_map = 1;
+	INIT_LIST_HEAD(&epf->pci_vepf);
+
 	dev = &epf->dev;
 	device_initialize(dev);
 	dev->bus = &pci_epf_bus_type;
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 6833e2160ef1..1de8fb72ce20 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -118,8 +118,10 @@ struct pci_epf_bar {
  * @header: represents standard configuration header
  * @bar: represents the BAR of EPF device
  * @msi_interrupts: number of MSI interrupts required by this function
- * @func_no: unique function number within this endpoint device
+ * @func_no: unique (physical) function number within this endpoint device
+ * @vfunc_no: unique virtual function number within a physical function
  * @epc: the EPC device to which this EPF device is bound
+ * @epf_pf: the physical EPF device to which this virtual EPF device is bound
  * @driver: the EPF driver to which this EPF device is bound
  * @list: to add pci_epf as a list of PCI endpoint functions to pci_epc
  * @nb: notifier block to notify EPF of any EPC events (like linkup)
@@ -130,6 +132,10 @@ struct pci_epf_bar {
  * @sec_epc_bar: represents the BAR of EPF device associated with secondary EPC
  * @sec_epc_func_no: unique (physical) function number within the secondary EPC
  * @group: configfs group associated with the EPF device
+ * @is_bound: indicates if bind notification to function driver has been invoked
+ * @is_vf: true - virtual function, false - physical function
+ * @vfunction_num_map: bitmap to manage virtual function number
+ * @pci_vepf: list of virtual endpoint functions associated with this function
  */
 struct pci_epf {
 	struct device		dev;
@@ -139,8 +145,10 @@ struct pci_epf {
 	u8			msi_interrupts;
 	u16			msix_interrupts;
 	u8			func_no;
+	u8			vfunc_no;
 
 	struct pci_epc		*epc;
+	struct pci_epf		*epf_pf;
 	struct pci_epf_driver	*driver;
 	struct list_head	list;
 	struct notifier_block   nb;
@@ -153,6 +161,10 @@ struct pci_epf {
 	struct pci_epf_bar	sec_epc_bar[6];
 	u8			sec_epc_func_no;
 	struct config_group	*group;
+	unsigned int		is_bound;
+	unsigned int		is_vf;
+	unsigned long		vfunction_num_map;
+	struct list_head	pci_vepf;
 };
 
 /**
@@ -196,4 +208,6 @@ int pci_epf_bind(struct pci_epf *epf);
 void pci_epf_unbind(struct pci_epf *epf);
 struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
 					  struct config_group *group);
+int pci_epf_add_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf);
+void pci_epf_remove_vepf(struct pci_epf *epf_pf, struct pci_epf *epf_vf);
 #endif /* __LINUX_PCI_EPF_H */
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:33:57 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:57 +0530
Subject: [PATCH v5 3/7] PCI: endpoint: Add support to link a physical function
 to a virtual function
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-4-kishon@ti.com>

While the physical function has to be linked to endpoint controller, the
virtual function has to be linked to a physical function. Add support to
link a physical function to a virtual function in pci-ep-cfs.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/pci/endpoint/pci-ep-cfs.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c
index f3a8b833b479..999911801877 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -475,6 +475,28 @@ static struct configfs_attribute *pci_epf_attrs[] = {
 	NULL,
 };
 
+static int pci_epf_vepf_link(struct config_item *epf_pf_item,
+			     struct config_item *epf_vf_item)
+{
+	struct pci_epf_group *epf_vf_group = to_pci_epf_group(epf_vf_item);
+	struct pci_epf_group *epf_pf_group = to_pci_epf_group(epf_pf_item);
+	struct pci_epf *epf_pf = epf_pf_group->epf;
+	struct pci_epf *epf_vf = epf_vf_group->epf;
+
+	return pci_epf_add_vepf(epf_pf, epf_vf);
+}
+
+static void pci_epf_vepf_unlink(struct config_item *epf_pf_item,
+				struct config_item *epf_vf_item)
+{
+	struct pci_epf_group *epf_vf_group = to_pci_epf_group(epf_vf_item);
+	struct pci_epf_group *epf_pf_group = to_pci_epf_group(epf_pf_item);
+	struct pci_epf *epf_pf = epf_pf_group->epf;
+	struct pci_epf *epf_vf = epf_vf_group->epf;
+
+	pci_epf_remove_vepf(epf_pf, epf_vf);
+}
+
 static void pci_epf_release(struct config_item *item)
 {
 	struct pci_epf_group *epf_group = to_pci_epf_group(item);
@@ -487,6 +509,8 @@ static void pci_epf_release(struct config_item *item)
 }
 
 static struct configfs_item_operations pci_epf_ops = {
+	.allow_link		= pci_epf_vepf_link,
+	.drop_link		= pci_epf_vepf_unlink,
 	.release		= pci_epf_release,
 };
 
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:33:58 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:58 +0530
Subject: [PATCH v5 4/7] PCI: endpoint: Add virtual function number in pci_epc
 ops
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-5-kishon@ti.com>

Add virtual function number in pci_epc ops. EPC controller driver
can perform virtual function specific initialization based on the
virtual function number.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../pci/controller/cadence/pcie-cadence-ep.c  |  44 +++---
 .../pci/controller/dwc/pcie-designware-ep.c   |  36 ++---
 drivers/pci/controller/pcie-rcar-ep.c         |  19 +--
 drivers/pci/controller/pcie-rockchip-ep.c     |  18 +--
 drivers/pci/endpoint/functions/pci-epf-ntb.c  |  79 ++++++-----
 drivers/pci/endpoint/functions/pci-epf-test.c |  66 +++++----
 drivers/pci/endpoint/pci-epc-core.c           | 128 ++++++++++++------
 drivers/pci/endpoint/pci-epf-core.c           |  48 ++++++-
 include/linux/pci-epc.h                       |  57 ++++----
 9 files changed, 313 insertions(+), 182 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 897cdde02bd8..912a15be8bfd 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -16,7 +16,7 @@
 #define CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE		0x1
 #define CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY	0x3
 
-static int cdns_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
+static int cdns_pcie_ep_write_header(struct pci_epc *epc, u8 fn, u8 vfn,
 				     struct pci_epf_header *hdr)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
@@ -47,7 +47,7 @@ static int cdns_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
+static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				struct pci_epf_bar *epf_bar)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
@@ -117,7 +117,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
+static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				   struct pci_epf_bar *epf_bar)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
@@ -147,8 +147,8 @@ static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
 	epf->epf_bar[bar] = NULL;
 }
 
-static int cdns_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, phys_addr_t addr,
-				 u64 pci_addr, size_t size)
+static int cdns_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, u8 vfn,
+				 phys_addr_t addr, u64 pci_addr, size_t size)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -169,7 +169,7 @@ static int cdns_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, phys_addr_t addr,
 	return 0;
 }
 
-static void cdns_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn,
+static void cdns_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 				    phys_addr_t addr)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
@@ -189,7 +189,7 @@ static void cdns_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn,
 	clear_bit(r, &ep->ob_region_map);
 }
 
-static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 mmc)
+static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 vfn, u8 mmc)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -209,7 +209,7 @@ static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 mmc)
 	return 0;
 }
 
-static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8 fn)
+static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8 fn, u8 vfn)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -230,7 +230,7 @@ static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8 fn)
 	return mme;
 }
 
-static int cdns_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
+static int cdns_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -247,8 +247,9 @@ static int cdns_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
 	return val;
 }
 
-static int cdns_pcie_ep_set_msix(struct pci_epc *epc, u8 fn, u16 interrupts,
-				 enum pci_barno bir, u32 offset)
+static int cdns_pcie_ep_set_msix(struct pci_epc *epc, u8 fn, u8 vfn,
+				 u16 interrupts, enum pci_barno bir,
+				 u32 offset)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -317,7 +318,8 @@ static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn,
 	writel(0, ep->irq_cpu_addr + offset);
 }
 
-static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 intx)
+static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
+					u8 intx)
 {
 	u16 cmd;
 
@@ -334,7 +336,7 @@ static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 intx)
 	return 0;
 }
 
-static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep *ep, u8 fn,
+static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 				     u8 interrupt_num)
 {
 	struct cdns_pcie *pcie = &ep->pcie;
@@ -382,7 +384,7 @@ static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep *ep, u8 fn,
 	return 0;
 }
 
-static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn,
+static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				    phys_addr_t addr, u8 interrupt_num,
 				    u32 entry_size, u32 *msi_data,
 				    u32 *msi_addr_offset)
@@ -419,7 +421,7 @@ static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn,
 	pci_addr &= GENMASK_ULL(63, 2);
 
 	for (i = 0; i < interrupt_num; i++) {
-		ret = cdns_pcie_ep_map_addr(epc, fn, addr,
+		ret = cdns_pcie_ep_map_addr(epc, fn, vfn, addr,
 					    pci_addr & ~pci_addr_mask,
 					    entry_size);
 		if (ret)
@@ -433,7 +435,7 @@ static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn,
+static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 				      u16 interrupt_num)
 {
 	u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
@@ -478,7 +480,7 @@ static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn,
 	return 0;
 }
 
-static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
+static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				  enum pci_epc_irq_type type,
 				  u16 interrupt_num)
 {
@@ -486,13 +488,13 @@ static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
 
 	switch (type) {
 	case PCI_EPC_IRQ_LEGACY:
-		return cdns_pcie_ep_send_legacy_irq(ep, fn, 0);
+		return cdns_pcie_ep_send_legacy_irq(ep, fn, vfn, 0);
 
 	case PCI_EPC_IRQ_MSI:
-		return cdns_pcie_ep_send_msi_irq(ep, fn, interrupt_num);
+		return cdns_pcie_ep_send_msi_irq(ep, fn, vfn, interrupt_num);
 
 	case PCI_EPC_IRQ_MSIX:
-		return cdns_pcie_ep_send_msix_irq(ep, fn, interrupt_num);
+		return cdns_pcie_ep_send_msix_irq(ep, fn, vfn, interrupt_num);
 
 	default:
 		break;
@@ -531,7 +533,7 @@ static const struct pci_epc_features cdns_pcie_epc_features = {
 };
 
 static const struct pci_epc_features*
-cdns_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+cdns_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	return &cdns_pcie_epc_features;
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 1c25d8337151..0f987b8dfb8a 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -125,7 +125,7 @@ static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8 func_no, u8 cap)
 	return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
 }
 
-static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
+static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				   struct pci_epf_header *hdr)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
@@ -202,7 +202,7 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
 	return 0;
 }
 
-static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no,
+static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				 struct pci_epf_bar *epf_bar)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
@@ -217,7 +217,7 @@ static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no,
 	ep->epf_bar[bar] = NULL;
 }
 
-static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
+static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			      struct pci_epf_bar *epf_bar)
 {
 	int ret;
@@ -276,7 +276,7 @@ static int dw_pcie_find_index(struct dw_pcie_ep *ep, phys_addr_t addr,
 	return -EINVAL;
 }
 
-static void dw_pcie_ep_unmap_addr(struct pci_epc *epc, u8 func_no,
+static void dw_pcie_ep_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				  phys_addr_t addr)
 {
 	int ret;
@@ -292,9 +292,8 @@ static void dw_pcie_ep_unmap_addr(struct pci_epc *epc, u8 func_no,
 	clear_bit(atu_index, ep->ob_window_map);
 }
 
-static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no,
-			       phys_addr_t addr,
-			       u64 pci_addr, size_t size)
+static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			       phys_addr_t addr, u64 pci_addr, size_t size)
 {
 	int ret;
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
@@ -309,7 +308,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no,
 	return 0;
 }
 
-static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8 func_no)
+static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -333,7 +332,8 @@ static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8 func_no)
 	return val;
 }
 
-static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
+static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			      u8 interrupts)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -358,7 +358,7 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
 	return 0;
 }
 
-static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
+static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -382,8 +382,8 @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
 	return val;
 }
 
-static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
-			       enum pci_barno bir, u32 offset)
+static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			       u16 interrupts, enum pci_barno bir, u32 offset)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 	struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -418,7 +418,7 @@ static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
 	return 0;
 }
 
-static int dw_pcie_ep_raise_irq(struct pci_epc *epc, u8 func_no,
+static int dw_pcie_ep_raise_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				enum pci_epc_irq_type type, u16 interrupt_num)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
@@ -450,7 +450,7 @@ static int dw_pcie_ep_start(struct pci_epc *epc)
 }
 
 static const struct pci_epc_features*
-dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+dw_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	struct dw_pcie_ep *ep = epc_get_drvdata(epc);
 
@@ -525,14 +525,14 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
 	aligned_offset = msg_addr_lower & (epc->mem->window.page_size - 1);
 	msg_addr = ((u64)msg_addr_upper) << 32 |
 			(msg_addr_lower & ~aligned_offset);
-	ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys, msg_addr,
+	ret = dw_pcie_ep_map_addr(epc, func_no, 0, ep->msi_mem_phys, msg_addr,
 				  epc->mem->window.page_size);
 	if (ret)
 		return ret;
 
 	writel(msg_data | (interrupt_num - 1), ep->msi_mem + aligned_offset);
 
-	dw_pcie_ep_unmap_addr(epc, func_no, ep->msi_mem_phys);
+	dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->msi_mem_phys);
 
 	return 0;
 }
@@ -593,14 +593,14 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
 	}
 
 	aligned_offset = msg_addr & (epc->mem->window.page_size - 1);
-	ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys,  msg_addr,
+	ret = dw_pcie_ep_map_addr(epc, func_no, 0, ep->msi_mem_phys, msg_addr,
 				  epc->mem->window.page_size);
 	if (ret)
 		return ret;
 
 	writel(msg_data, ep->msi_mem + aligned_offset);
 
-	dw_pcie_ep_unmap_addr(epc, func_no, ep->msi_mem_phys);
+	dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->msi_mem_phys);
 
 	return 0;
 }
diff --git a/drivers/pci/controller/pcie-rcar-ep.c b/drivers/pci/controller/pcie-rcar-ep.c
index b4a288e24aaf..6cee4e09acca 100644
--- a/drivers/pci/controller/pcie-rcar-ep.c
+++ b/drivers/pci/controller/pcie-rcar-ep.c
@@ -159,7 +159,7 @@ static int rcar_pcie_ep_get_pdata(struct rcar_pcie_endpoint *ep,
 	return 0;
 }
 
-static int rcar_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
+static int rcar_pcie_ep_write_header(struct pci_epc *epc, u8 fn, u8 vfn,
 				     struct pci_epf_header *hdr)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
@@ -195,7 +195,7 @@ static int rcar_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static int rcar_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
+static int rcar_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				struct pci_epf_bar *epf_bar)
 {
 	int flags = epf_bar->flags | LAR_ENABLE | LAM_64BIT;
@@ -246,7 +246,7 @@ static int rcar_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
 	return 0;
 }
 
-static void rcar_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
+static void rcar_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				   struct pci_epf_bar *epf_bar)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
@@ -259,7 +259,8 @@ static void rcar_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
 	clear_bit(atu_index + 1, ep->ib_window_map);
 }
 
-static int rcar_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 interrupts)
+static int rcar_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 vfn,
+				u8 interrupts)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
 	struct rcar_pcie *pcie = &ep->pcie;
@@ -272,7 +273,7 @@ static int rcar_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 interrupts)
 	return 0;
 }
 
-static int rcar_pcie_ep_get_msi(struct pci_epc *epc, u8 fn)
+static int rcar_pcie_ep_get_msi(struct pci_epc *epc, u8 fn, u8 vfn)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
 	struct rcar_pcie *pcie = &ep->pcie;
@@ -285,7 +286,7 @@ static int rcar_pcie_ep_get_msi(struct pci_epc *epc, u8 fn)
 	return ((flags & MSICAP0_MMESE_MASK) >> MSICAP0_MMESE_OFFSET);
 }
 
-static int rcar_pcie_ep_map_addr(struct pci_epc *epc, u8 fn,
+static int rcar_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 				 phys_addr_t addr, u64 pci_addr, size_t size)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
@@ -322,7 +323,7 @@ static int rcar_pcie_ep_map_addr(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static void rcar_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn,
+static void rcar_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 				    phys_addr_t addr)
 {
 	struct rcar_pcie_endpoint *ep = epc_get_drvdata(epc);
@@ -403,7 +404,7 @@ static int rcar_pcie_ep_assert_msi(struct rcar_pcie *pcie,
 	return 0;
 }
 
-static int rcar_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
+static int rcar_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				  enum pci_epc_irq_type type,
 				  u16 interrupt_num)
 {
@@ -451,7 +452,7 @@ static const struct pci_epc_features rcar_pcie_epc_features = {
 };
 
 static const struct pci_epc_features*
-rcar_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+rcar_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	return &rcar_pcie_epc_features;
 }
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c
index 7631dc3961c1..5fb9ce6e536e 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -122,7 +122,7 @@ static void rockchip_pcie_prog_ep_ob_atu(struct rockchip_pcie *rockchip, u8 fn,
 			    ROCKCHIP_PCIE_AT_OB_REGION_CPU_ADDR1(r));
 }
 
-static int rockchip_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
+static int rockchip_pcie_ep_write_header(struct pci_epc *epc, u8 fn, u8 vfn,
 					 struct pci_epf_header *hdr)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
@@ -159,7 +159,7 @@ static int rockchip_pcie_ep_write_header(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static int rockchip_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
+static int rockchip_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				    struct pci_epf_bar *epf_bar)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
@@ -227,7 +227,7 @@ static int rockchip_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static void rockchip_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
+static void rockchip_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				       struct pci_epf_bar *epf_bar)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
@@ -256,7 +256,7 @@ static void rockchip_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn,
 			    ROCKCHIP_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar));
 }
 
-static int rockchip_pcie_ep_map_addr(struct pci_epc *epc, u8 fn,
+static int rockchip_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 				     phys_addr_t addr, u64 pci_addr,
 				     size_t size)
 {
@@ -284,7 +284,7 @@ static int rockchip_pcie_ep_map_addr(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static void rockchip_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn,
+static void rockchip_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 					phys_addr_t addr)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
@@ -308,7 +308,7 @@ static void rockchip_pcie_ep_unmap_addr(struct pci_epc *epc, u8 fn,
 	clear_bit(r, &ep->ob_region_map);
 }
 
-static int rockchip_pcie_ep_set_msi(struct pci_epc *epc, u8 fn,
+static int rockchip_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 vfn,
 				    u8 multi_msg_cap)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
@@ -329,7 +329,7 @@ static int rockchip_pcie_ep_set_msi(struct pci_epc *epc, u8 fn,
 	return 0;
 }
 
-static int rockchip_pcie_ep_get_msi(struct pci_epc *epc, u8 fn)
+static int rockchip_pcie_ep_get_msi(struct pci_epc *epc, u8 fn, u8 vfn)
 {
 	struct rockchip_pcie_ep *ep = epc_get_drvdata(epc);
 	struct rockchip_pcie *rockchip = &ep->rockchip;
@@ -471,7 +471,7 @@ static int rockchip_pcie_ep_send_msi_irq(struct rockchip_pcie_ep *ep, u8 fn,
 	return 0;
 }
 
-static int rockchip_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
+static int rockchip_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				      enum pci_epc_irq_type type,
 				      u16 interrupt_num)
 {
@@ -510,7 +510,7 @@ static const struct pci_epc_features rockchip_pcie_epc_features = {
 };
 
 static const struct pci_epc_features*
-rockchip_pcie_ep_get_features(struct pci_epc *epc, u8 func_no)
+rockchip_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	return &rockchip_pcie_epc_features;
 }
diff --git a/drivers/pci/endpoint/functions/pci-epf-ntb.c b/drivers/pci/endpoint/functions/pci-epf-ntb.c
index 338148cf56f5..73714080a166 100644
--- a/drivers/pci/endpoint/functions/pci-epf-ntb.c
+++ b/drivers/pci/endpoint/functions/pci-epf-ntb.c
@@ -87,6 +87,7 @@ struct epf_ntb {
 
 struct epf_ntb_epc {
 	u8 func_no;
+	u8 vfunc_no;
 	bool linkup;
 	bool is_msix;
 	int msix_bar;
@@ -143,14 +144,15 @@ static int epf_ntb_link_up(struct epf_ntb *ntb, bool link_up)
 	struct epf_ntb_epc *ntb_epc;
 	struct epf_ntb_ctrl *ctrl;
 	struct pci_epc *epc;
+	u8 func_no, vfunc_no;
 	bool is_msix;
-	u8 func_no;
 	int ret;
 
 	for (type = PRIMARY_INTERFACE; type <= SECONDARY_INTERFACE; type++) {
 		ntb_epc = ntb->epc[type];
 		epc = ntb_epc->epc;
 		func_no = ntb_epc->func_no;
+		vfunc_no = ntb_epc->vfunc_no;
 		is_msix = ntb_epc->is_msix;
 		ctrl = ntb_epc->reg;
 		if (link_up)
@@ -158,7 +160,7 @@ static int epf_ntb_link_up(struct epf_ntb *ntb, bool link_up)
 		else
 			ctrl->link_status &= ~LINK_STATUS_UP;
 		irq_type = is_msix ? PCI_EPC_IRQ_MSIX : PCI_EPC_IRQ_MSI;
-		ret = pci_epc_raise_irq(epc, func_no, irq_type, 1);
+		ret = pci_epc_raise_irq(epc, func_no, vfunc_no, irq_type, 1);
 		if (ret) {
 			dev_err(&epc->dev,
 				"%s intf: Failed to raise Link Up IRQ\n",
@@ -238,10 +240,10 @@ static int epf_ntb_configure_mw(struct epf_ntb *ntb,
 	enum pci_barno peer_barno;
 	struct epf_ntb_ctrl *ctrl;
 	phys_addr_t phys_addr;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	u64 addr, size;
 	int ret = 0;
-	u8 func_no;
 
 	ntb_epc = ntb->epc[type];
 	epc = ntb_epc->epc;
@@ -267,8 +269,9 @@ static int epf_ntb_configure_mw(struct epf_ntb *ntb,
 	}
 
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
-	ret = pci_epc_map_addr(epc, func_no, phys_addr, addr, size);
+	ret = pci_epc_map_addr(epc, func_no, vfunc_no, phys_addr, addr, size);
 	if (ret)
 		dev_err(&epc->dev,
 			"%s intf: Failed to map memory window %d address\n",
@@ -296,8 +299,8 @@ static void epf_ntb_teardown_mw(struct epf_ntb *ntb,
 	enum pci_barno peer_barno;
 	struct epf_ntb_ctrl *ctrl;
 	phys_addr_t phys_addr;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 
 	ntb_epc = ntb->epc[type];
 	epc = ntb_epc->epc;
@@ -311,8 +314,9 @@ static void epf_ntb_teardown_mw(struct epf_ntb *ntb,
 	if (mw + NTB_MW_OFFSET == BAR_DB_MW1)
 		phys_addr += ctrl->mw1_offset;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
-	pci_epc_unmap_addr(epc, func_no, phys_addr);
+	pci_epc_unmap_addr(epc, func_no, vfunc_no, phys_addr);
 }
 
 /**
@@ -385,8 +389,8 @@ static int epf_ntb_configure_msi(struct epf_ntb *ntb,
 	struct epf_ntb_ctrl *peer_ctrl;
 	enum pci_barno peer_barno;
 	phys_addr_t phys_addr;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 	int ret, i;
 
 	ntb_epc = ntb->epc[type];
@@ -400,8 +404,9 @@ static int epf_ntb_configure_msi(struct epf_ntb *ntb,
 
 	phys_addr = peer_epf_bar->phys_addr;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
-	ret = pci_epc_map_msi_irq(epc, func_no, phys_addr, db_count,
+	ret = pci_epc_map_msi_irq(epc, func_no, vfunc_no, phys_addr, db_count,
 				  db_entry_size, &db_data, &db_offset);
 	if (ret) {
 		dev_err(&epc->dev, "%s intf: Failed to map MSI IRQ\n",
@@ -491,10 +496,10 @@ static int epf_ntb_configure_msix(struct epf_ntb *ntb,
 	u32 db_entry_size, msg_data;
 	enum pci_barno peer_barno;
 	phys_addr_t phys_addr;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	size_t align;
 	u64 msg_addr;
-	u8 func_no;
 	int ret, i;
 
 	ntb_epc = ntb->epc[type];
@@ -512,12 +517,13 @@ static int epf_ntb_configure_msix(struct epf_ntb *ntb,
 	align = epc_features->align;
 
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	db_entry_size = peer_ctrl->db_entry_size;
 
 	for (i = 0; i < db_count; i++) {
 		msg_addr = ALIGN_DOWN(msix_tbl[i].msg_addr, align);
 		msg_data = msix_tbl[i].msg_data;
-		ret = pci_epc_map_addr(epc, func_no, phys_addr, msg_addr,
+		ret = pci_epc_map_addr(epc, func_no, vfunc_no, phys_addr, msg_addr,
 				       db_entry_size);
 		if (ret) {
 			dev_err(&epc->dev,
@@ -586,8 +592,8 @@ epf_ntb_teardown_db(struct epf_ntb *ntb, enum pci_epc_interface_type type)
 	struct pci_epf_bar *peer_epf_bar;
 	enum pci_barno peer_barno;
 	phys_addr_t phys_addr;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 
 	ntb_epc = ntb->epc[type];
 	epc = ntb_epc->epc;
@@ -597,8 +603,9 @@ epf_ntb_teardown_db(struct epf_ntb *ntb, enum pci_epc_interface_type type)
 	peer_epf_bar = &peer_ntb_epc->epf_bar[peer_barno];
 	phys_addr = peer_epf_bar->phys_addr;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
-	pci_epc_unmap_addr(epc, func_no, phys_addr);
+	pci_epc_unmap_addr(epc, func_no, vfunc_no, phys_addr);
 }
 
 /**
@@ -727,14 +734,15 @@ static void epf_ntb_peer_spad_bar_clear(struct epf_ntb_epc *ntb_epc)
 {
 	struct pci_epf_bar *epf_bar;
 	enum pci_barno barno;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 
 	epc = ntb_epc->epc;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	barno = ntb_epc->epf_ntb_bar[BAR_PEER_SPAD];
 	epf_bar = &ntb_epc->epf_bar[barno];
-	pci_epc_clear_bar(epc, func_no, epf_bar);
+	pci_epc_clear_bar(epc, func_no, vfunc_no, epf_bar);
 }
 
 /**
@@ -773,9 +781,9 @@ static int epf_ntb_peer_spad_bar_set(struct epf_ntb *ntb,
 	struct pci_epf_bar *peer_epf_bar, *epf_bar;
 	enum pci_barno peer_barno, barno;
 	u32 peer_spad_offset;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	struct device *dev;
-	u8 func_no;
 	int ret;
 
 	dev = &ntb->epf->dev;
@@ -788,6 +796,7 @@ static int epf_ntb_peer_spad_bar_set(struct epf_ntb *ntb,
 	barno = ntb_epc->epf_ntb_bar[BAR_PEER_SPAD];
 	epf_bar = &ntb_epc->epf_bar[barno];
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	epc = ntb_epc->epc;
 
 	peer_spad_offset = peer_ntb_epc->reg->spad_offset;
@@ -796,7 +805,7 @@ static int epf_ntb_peer_spad_bar_set(struct epf_ntb *ntb,
 	epf_bar->barno = barno;
 	epf_bar->flags = PCI_BASE_ADDRESS_MEM_TYPE_32;
 
-	ret = pci_epc_set_bar(epc, func_no, epf_bar);
+	ret = pci_epc_set_bar(epc, func_no, vfunc_no, epf_bar);
 	if (ret) {
 		dev_err(dev, "%s intf: peer SPAD BAR set failed\n",
 			pci_epc_interface_string(type));
@@ -839,14 +848,15 @@ static void epf_ntb_config_sspad_bar_clear(struct epf_ntb_epc *ntb_epc)
 {
 	struct pci_epf_bar *epf_bar;
 	enum pci_barno barno;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 
 	epc = ntb_epc->epc;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	barno = ntb_epc->epf_ntb_bar[BAR_CONFIG];
 	epf_bar = &ntb_epc->epf_bar[barno];
-	pci_epc_clear_bar(epc, func_no, epf_bar);
+	pci_epc_clear_bar(epc, func_no, vfunc_no, epf_bar);
 }
 
 /**
@@ -882,10 +892,10 @@ static int epf_ntb_config_sspad_bar_set(struct epf_ntb_epc *ntb_epc)
 {
 	struct pci_epf_bar *epf_bar;
 	enum pci_barno barno;
+	u8 func_no, vfunc_no;
 	struct epf_ntb *ntb;
 	struct pci_epc *epc;
 	struct device *dev;
-	u8 func_no;
 	int ret;
 
 	ntb = ntb_epc->epf_ntb;
@@ -893,10 +903,11 @@ static int epf_ntb_config_sspad_bar_set(struct epf_ntb_epc *ntb_epc)
 
 	epc = ntb_epc->epc;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	barno = ntb_epc->epf_ntb_bar[BAR_CONFIG];
 	epf_bar = &ntb_epc->epf_bar[barno];
 
-	ret = pci_epc_set_bar(epc, func_no, epf_bar);
+	ret = pci_epc_set_bar(epc, func_no, vfunc_no, epf_bar);
 	if (ret) {
 		dev_err(dev, "%s inft: Config/Status/SPAD BAR set failed\n",
 			pci_epc_interface_string(ntb_epc->type));
@@ -1210,17 +1221,18 @@ static void epf_ntb_db_mw_bar_clear(struct epf_ntb_epc *ntb_epc)
 	struct pci_epf_bar *epf_bar;
 	enum epf_ntb_bar bar;
 	enum pci_barno barno;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
-	u8 func_no;
 
 	epc = ntb_epc->epc;
 
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
 	for (bar = BAR_DB_MW1; bar < BAR_MW4; bar++) {
 		barno = ntb_epc->epf_ntb_bar[bar];
 		epf_bar = &ntb_epc->epf_bar[barno];
-		pci_epc_clear_bar(epc, func_no, epf_bar);
+		pci_epc_clear_bar(epc, func_no, vfunc_no, epf_bar);
 	}
 }
 
@@ -1259,10 +1271,10 @@ static int epf_ntb_configure_interrupt(struct epf_ntb *ntb,
 	const struct pci_epc_features *epc_features;
 	bool msix_capable, msi_capable;
 	struct epf_ntb_epc *ntb_epc;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	struct device *dev;
 	u32 db_count;
-	u8 func_no;
 	int ret;
 
 	ntb_epc = ntb->epc[type];
@@ -1278,6 +1290,7 @@ static int epf_ntb_configure_interrupt(struct epf_ntb *ntb,
 	}
 
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
 	db_count = ntb->db_count;
 	if (db_count > MAX_DB_COUNT) {
@@ -1289,7 +1302,7 @@ static int epf_ntb_configure_interrupt(struct epf_ntb *ntb,
 	epc = ntb_epc->epc;
 
 	if (msi_capable) {
-		ret = pci_epc_set_msi(epc, func_no, db_count);
+		ret = pci_epc_set_msi(epc, func_no, vfunc_no, db_count);
 		if (ret) {
 			dev_err(dev, "%s intf: MSI configuration failed\n",
 				pci_epc_interface_string(type));
@@ -1298,7 +1311,7 @@ static int epf_ntb_configure_interrupt(struct epf_ntb *ntb,
 	}
 
 	if (msix_capable) {
-		ret = pci_epc_set_msix(epc, func_no, db_count,
+		ret = pci_epc_set_msix(epc, func_no, vfunc_no, db_count,
 				       ntb_epc->msix_bar,
 				       ntb_epc->msix_table_offset);
 		if (ret) {
@@ -1418,11 +1431,11 @@ static int epf_ntb_db_mw_bar_init(struct epf_ntb *ntb,
 	u32 num_mws, db_count;
 	enum epf_ntb_bar bar;
 	enum pci_barno barno;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	struct device *dev;
 	size_t align;
 	int ret, i;
-	u8 func_no;
 	u64 size;
 
 	ntb_epc = ntb->epc[type];
@@ -1432,6 +1445,7 @@ static int epf_ntb_db_mw_bar_init(struct epf_ntb *ntb,
 	epc_features = ntb_epc->epc_features;
 	align = epc_features->align;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 	epc = ntb_epc->epc;
 	num_mws = ntb->num_mws;
 	db_count = ntb->db_count;
@@ -1459,7 +1473,7 @@ static int epf_ntb_db_mw_bar_init(struct epf_ntb *ntb,
 		barno = ntb_epc->epf_ntb_bar[bar];
 		epf_bar = &ntb_epc->epf_bar[barno];
 
-		ret = pci_epc_set_bar(epc, func_no, epf_bar);
+		ret = pci_epc_set_bar(epc, func_no, vfunc_no, epf_bar);
 		if (ret) {
 			dev_err(dev, "%s intf: DoorBell BAR set failed\n",
 				pci_epc_interface_string(type));
@@ -1531,9 +1545,9 @@ static int epf_ntb_epc_create_interface(struct epf_ntb *ntb,
 	const struct pci_epc_features *epc_features;
 	struct pci_epf_bar *epf_bar;
 	struct epf_ntb_epc *ntb_epc;
+	u8 func_no, vfunc_no;
 	struct pci_epf *epf;
 	struct device *dev;
-	u8 func_no;
 
 	dev = &ntb->epf->dev;
 
@@ -1542,6 +1556,7 @@ static int epf_ntb_epc_create_interface(struct epf_ntb *ntb,
 		return -ENOMEM;
 
 	epf = ntb->epf;
+	vfunc_no = epf->vfunc_no;
 	if (type == PRIMARY_INTERFACE) {
 		func_no = epf->func_no;
 		epf_bar = epf->bar;
@@ -1553,11 +1568,12 @@ static int epf_ntb_epc_create_interface(struct epf_ntb *ntb,
 	ntb_epc->linkup = false;
 	ntb_epc->epc = epc;
 	ntb_epc->func_no = func_no;
+	ntb_epc->vfunc_no = vfunc_no;
 	ntb_epc->type = type;
 	ntb_epc->epf_bar = epf_bar;
 	ntb_epc->epf_ntb = ntb;
 
-	epc_features = pci_epc_get_features(epc, func_no);
+	epc_features = pci_epc_get_features(epc, func_no, vfunc_no);
 	if (!epc_features)
 		return -EINVAL;
 	ntb_epc->epc_features = epc_features;
@@ -1698,10 +1714,10 @@ static int epf_ntb_epc_init_interface(struct epf_ntb *ntb,
 				      enum pci_epc_interface_type type)
 {
 	struct epf_ntb_epc *ntb_epc;
+	u8 func_no, vfunc_no;
 	struct pci_epc *epc;
 	struct pci_epf *epf;
 	struct device *dev;
-	u8 func_no;
 	int ret;
 
 	ntb_epc = ntb->epc[type];
@@ -1709,6 +1725,7 @@ static int epf_ntb_epc_init_interface(struct epf_ntb *ntb,
 	dev = &epf->dev;
 	epc = ntb_epc->epc;
 	func_no = ntb_epc->func_no;
+	vfunc_no = ntb_epc->vfunc_no;
 
 	ret = epf_ntb_config_sspad_bar_set(ntb->epc[type]);
 	if (ret) {
@@ -1738,7 +1755,7 @@ static int epf_ntb_epc_init_interface(struct epf_ntb *ntb,
 		goto err_db_mw_bar_init;
 	}
 
-	ret = pci_epc_write_header(epc, func_no, epf->header);
+	ret = pci_epc_write_header(epc, func_no, vfunc_no, epf->header);
 	if (ret) {
 		dev_err(dev, "%s intf: Configuration header write failed\n",
 			pci_epc_interface_string(type));
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index c0ac4e9cbe72..b588c94d97e9 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -247,8 +247,8 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test)
 		goto err;
 	}
 
-	ret = pci_epc_map_addr(epc, epf->func_no, src_phys_addr, reg->src_addr,
-			       reg->size);
+	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, src_phys_addr,
+			       reg->src_addr, reg->size);
 	if (ret) {
 		dev_err(dev, "Failed to map source address\n");
 		reg->status = STATUS_SRC_ADDR_INVALID;
@@ -263,8 +263,8 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test)
 		goto err_src_map_addr;
 	}
 
-	ret = pci_epc_map_addr(epc, epf->func_no, dst_phys_addr, reg->dst_addr,
-			       reg->size);
+	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, dst_phys_addr,
+			       reg->dst_addr, reg->size);
 	if (ret) {
 		dev_err(dev, "Failed to map destination address\n");
 		reg->status = STATUS_DST_ADDR_INVALID;
@@ -291,13 +291,13 @@ static int pci_epf_test_copy(struct pci_epf_test *epf_test)
 	pci_epf_test_print_rate("COPY", reg->size, &start, &end, use_dma);
 
 err_map_addr:
-	pci_epc_unmap_addr(epc, epf->func_no, dst_phys_addr);
+	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, dst_phys_addr);
 
 err_dst_addr:
 	pci_epc_mem_free_addr(epc, dst_phys_addr, dst_addr, reg->size);
 
 err_src_map_addr:
-	pci_epc_unmap_addr(epc, epf->func_no, src_phys_addr);
+	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, src_phys_addr);
 
 err_src_addr:
 	pci_epc_mem_free_addr(epc, src_phys_addr, src_addr, reg->size);
@@ -331,8 +331,8 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test)
 		goto err;
 	}
 
-	ret = pci_epc_map_addr(epc, epf->func_no, phys_addr, reg->src_addr,
-			       reg->size);
+	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, phys_addr,
+			       reg->src_addr, reg->size);
 	if (ret) {
 		dev_err(dev, "Failed to map address\n");
 		reg->status = STATUS_SRC_ADDR_INVALID;
@@ -386,7 +386,7 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test)
 	kfree(buf);
 
 err_map_addr:
-	pci_epc_unmap_addr(epc, epf->func_no, phys_addr);
+	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, phys_addr);
 
 err_addr:
 	pci_epc_mem_free_addr(epc, phys_addr, src_addr, reg->size);
@@ -419,8 +419,8 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
 		goto err;
 	}
 
-	ret = pci_epc_map_addr(epc, epf->func_no, phys_addr, reg->dst_addr,
-			       reg->size);
+	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, phys_addr,
+			       reg->dst_addr, reg->size);
 	if (ret) {
 		dev_err(dev, "Failed to map address\n");
 		reg->status = STATUS_DST_ADDR_INVALID;
@@ -479,7 +479,7 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
 	kfree(buf);
 
 err_map_addr:
-	pci_epc_unmap_addr(epc, epf->func_no, phys_addr);
+	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, phys_addr);
 
 err_addr:
 	pci_epc_mem_free_addr(epc, phys_addr, dst_addr, reg->size);
@@ -501,13 +501,16 @@ static void pci_epf_test_raise_irq(struct pci_epf_test *epf_test, u8 irq_type,
 
 	switch (irq_type) {
 	case IRQ_TYPE_LEGACY:
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_LEGACY, 0);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_LEGACY, 0);
 		break;
 	case IRQ_TYPE_MSI:
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_MSI, irq);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_MSI, irq);
 		break;
 	case IRQ_TYPE_MSIX:
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_MSIX, irq);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_MSIX, irq);
 		break;
 	default:
 		dev_err(dev, "Failed to raise IRQ, unknown type\n");
@@ -542,7 +545,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work)
 
 	if (command & COMMAND_RAISE_LEGACY_IRQ) {
 		reg->status = STATUS_IRQ_RAISED;
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_LEGACY, 0);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_LEGACY, 0);
 		goto reset_handler;
 	}
 
@@ -580,22 +584,22 @@ static void pci_epf_test_cmd_handler(struct work_struct *work)
 	}
 
 	if (command & COMMAND_RAISE_MSI_IRQ) {
-		count = pci_epc_get_msi(epc, epf->func_no);
+		count = pci_epc_get_msi(epc, epf->func_no, epf->vfunc_no);
 		if (reg->irq_number > count || count <= 0)
 			goto reset_handler;
 		reg->status = STATUS_IRQ_RAISED;
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_MSI,
-				  reg->irq_number);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_MSI, reg->irq_number);
 		goto reset_handler;
 	}
 
 	if (command & COMMAND_RAISE_MSIX_IRQ) {
-		count = pci_epc_get_msix(epc, epf->func_no);
+		count = pci_epc_get_msix(epc, epf->func_no, epf->vfunc_no);
 		if (reg->irq_number > count || count <= 0)
 			goto reset_handler;
 		reg->status = STATUS_IRQ_RAISED;
-		pci_epc_raise_irq(epc, epf->func_no, PCI_EPC_IRQ_MSIX,
-				  reg->irq_number);
+		pci_epc_raise_irq(epc, epf->func_no, epf->vfunc_no,
+				  PCI_EPC_IRQ_MSIX, reg->irq_number);
 		goto reset_handler;
 	}
 
@@ -618,7 +622,8 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
 		epf_bar = &epf->bar[bar];
 
 		if (epf_test->reg[bar]) {
-			pci_epc_clear_bar(epc, epf->func_no, epf_bar);
+			pci_epc_clear_bar(epc, epf->func_no, epf->vfunc_no,
+					  epf_bar);
 			pci_epf_free_space(epf, epf_test->reg[bar], bar,
 					   PRIMARY_INTERFACE);
 		}
@@ -650,7 +655,8 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
 		if (!!(epc_features->reserved_bar & (1 << bar)))
 			continue;
 
-		ret = pci_epc_set_bar(epc, epf->func_no, epf_bar);
+		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no,
+				      epf_bar);
 		if (ret) {
 			pci_epf_free_space(epf, epf_test->reg[bar], bar,
 					   PRIMARY_INTERFACE);
@@ -674,13 +680,13 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
 	bool msi_capable = true;
 	int ret;
 
-	epc_features = pci_epc_get_features(epc, epf->func_no);
+	epc_features = pci_epc_get_features(epc, epf->func_no, epf->vfunc_no);
 	if (epc_features) {
 		msix_capable = epc_features->msix_capable;
 		msi_capable = epc_features->msi_capable;
 	}
 
-	ret = pci_epc_write_header(epc, epf->func_no, header);
+	ret = pci_epc_write_header(epc, epf->func_no, epf->vfunc_no, header);
 	if (ret) {
 		dev_err(dev, "Configuration header write failed\n");
 		return ret;
@@ -691,7 +697,8 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
 		return ret;
 
 	if (msi_capable) {
-		ret = pci_epc_set_msi(epc, epf->func_no, epf->msi_interrupts);
+		ret = pci_epc_set_msi(epc, epf->func_no, epf->vfunc_no,
+				      epf->msi_interrupts);
 		if (ret) {
 			dev_err(dev, "MSI configuration failed\n");
 			return ret;
@@ -699,7 +706,8 @@ static int pci_epf_test_core_init(struct pci_epf *epf)
 	}
 
 	if (msix_capable) {
-		ret = pci_epc_set_msix(epc, epf->func_no, epf->msix_interrupts,
+		ret = pci_epc_set_msix(epc, epf->func_no, epf->vfunc_no,
+				       epf->msix_interrupts,
 				       epf_test->test_reg_bar,
 				       epf_test->msix_table_offset);
 		if (ret) {
@@ -832,7 +840,7 @@ static int pci_epf_test_bind(struct pci_epf *epf)
 	if (WARN_ON_ONCE(!epc))
 		return -EINVAL;
 
-	epc_features = pci_epc_get_features(epc, epf->func_no);
+	epc_features = pci_epc_get_features(epc, epf->func_no, epf->vfunc_no);
 	if (epc_features) {
 		linkup_notifier = epc_features->linkup_notifier;
 		core_init_notifier = epc_features->core_init_notifier;
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index fe6d23849502..23594165fa68 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -137,24 +137,29 @@ EXPORT_SYMBOL_GPL(pci_epc_get_next_free_bar);
  * @epc: the features supported by *this* EPC device will be returned
  * @func_no: the features supported by the EPC device specific to the
  *	     endpoint function with func_no will be returned
+ * @vfunc_no: the features supported by the EPC device specific to the
+ *	     virtual endpoint function with vfunc_no will be returned
  *
  * Invoke to get the features provided by the EPC which may be
  * specific to an endpoint function. Returns pci_epc_features on success
  * and NULL for any failures.
  */
 const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
-						    u8 func_no)
+						    u8 func_no, u8 vfunc_no)
 {
 	const struct pci_epc_features *epc_features;
 
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return NULL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return NULL;
+
 	if (!epc->ops->get_features)
 		return NULL;
 
 	mutex_lock(&epc->lock);
-	epc_features = epc->ops->get_features(epc, func_no);
+	epc_features = epc->ops->get_features(epc, func_no, vfunc_no);
 	mutex_unlock(&epc->lock);
 
 	return epc_features;
@@ -205,13 +210,14 @@ EXPORT_SYMBOL_GPL(pci_epc_start);
 /**
  * pci_epc_raise_irq() - interrupt the host system
  * @epc: the EPC device which has to interrupt the host
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @type: specify the type of interrupt; legacy, MSI or MSI-X
  * @interrupt_num: the MSI or MSI-X interrupt number
  *
  * Invoke to raise an legacy, MSI or MSI-X interrupt
  */
-int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
+int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		      enum pci_epc_irq_type type, u16 interrupt_num)
 {
 	int ret;
@@ -219,11 +225,14 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->raise_irq)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->raise_irq(epc, func_no, type, interrupt_num);
+	ret = epc->ops->raise_irq(epc, func_no, vfunc_no, type, interrupt_num);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -235,6 +244,7 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  *                         MSI data
  * @epc: the EPC device which has the MSI capability
  * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @phys_addr: the physical address of the outbound region
  * @interrupt_num: the MSI interrupt number
  * @entry_size: Size of Outbound address region for each interrupt
@@ -250,21 +260,25 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  * physical address (in outbound region) of the other interface to ring
  * doorbell.
  */
-int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, phys_addr_t phys_addr,
-			u8 interrupt_num, u32 entry_size, u32 *msi_data,
-			u32 *msi_addr_offset)
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			phys_addr_t phys_addr, u8 interrupt_num, u32 entry_size,
+			u32 *msi_data, u32 *msi_addr_offset)
 {
 	int ret;
 
 	if (IS_ERR_OR_NULL(epc))
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->map_msi_irq)
 		return -EINVAL;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->map_msi_irq(epc, func_no, phys_addr, interrupt_num,
-				    entry_size, msi_data, msi_addr_offset);
+	ret = epc->ops->map_msi_irq(epc, func_no, vfunc_no, phys_addr,
+				    interrupt_num, entry_size, msi_data,
+				    msi_addr_offset);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -274,22 +288,26 @@ EXPORT_SYMBOL_GPL(pci_epc_map_msi_irq);
 /**
  * pci_epc_get_msi() - get the number of MSI interrupt numbers allocated
  * @epc: the EPC device to which MSI interrupts was requested
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  *
  * Invoke to get the number of MSI interrupts allocated by the RC
  */
-int pci_epc_get_msi(struct pci_epc *epc, u8 func_no)
+int pci_epc_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	int interrupt;
 
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return 0;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return 0;
+
 	if (!epc->ops->get_msi)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	interrupt = epc->ops->get_msi(epc, func_no);
+	interrupt = epc->ops->get_msi(epc, func_no, vfunc_no);
 	mutex_unlock(&epc->lock);
 
 	if (interrupt < 0)
@@ -304,12 +322,13 @@ EXPORT_SYMBOL_GPL(pci_epc_get_msi);
 /**
  * pci_epc_set_msi() - set the number of MSI interrupt numbers required
  * @epc: the EPC device on which MSI has to be configured
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @interrupts: number of MSI interrupts required by the EPF
  *
  * Invoke to set the required number of MSI interrupts.
  */
-int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
+int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no, u8 interrupts)
 {
 	int ret;
 	u8 encode_int;
@@ -318,13 +337,16 @@ int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
 	    interrupts > 32)
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->set_msi)
 		return 0;
 
 	encode_int = order_base_2(interrupts);
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->set_msi(epc, func_no, encode_int);
+	ret = epc->ops->set_msi(epc, func_no, vfunc_no, encode_int);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -334,22 +356,26 @@ EXPORT_SYMBOL_GPL(pci_epc_set_msi);
 /**
  * pci_epc_get_msix() - get the number of MSI-X interrupt numbers allocated
  * @epc: the EPC device to which MSI-X interrupts was requested
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  *
  * Invoke to get the number of MSI-X interrupts allocated by the RC
  */
-int pci_epc_get_msix(struct pci_epc *epc, u8 func_no)
+int pci_epc_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
 	int interrupt;
 
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return 0;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return 0;
+
 	if (!epc->ops->get_msix)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	interrupt = epc->ops->get_msix(epc, func_no);
+	interrupt = epc->ops->get_msix(epc, func_no, vfunc_no);
 	mutex_unlock(&epc->lock);
 
 	if (interrupt < 0)
@@ -362,15 +388,16 @@ EXPORT_SYMBOL_GPL(pci_epc_get_msix);
 /**
  * pci_epc_set_msix() - set the number of MSI-X interrupt numbers required
  * @epc: the EPC device on which MSI-X has to be configured
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @interrupts: number of MSI-X interrupts required by the EPF
  * @bir: BAR where the MSI-X table resides
  * @offset: Offset pointing to the start of MSI-X table
  *
  * Invoke to set the required number of MSI-X interrupts.
  */
-int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
-		     enum pci_barno bir, u32 offset)
+int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+		     u16 interrupts, enum pci_barno bir, u32 offset)
 {
 	int ret;
 
@@ -378,11 +405,15 @@ int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
 	    interrupts < 1 || interrupts > 2048)
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->set_msix)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->set_msix(epc, func_no, interrupts - 1, bir, offset);
+	ret = epc->ops->set_msix(epc, func_no, vfunc_no, interrupts - 1, bir,
+				 offset);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -392,22 +423,26 @@ EXPORT_SYMBOL_GPL(pci_epc_set_msix);
 /**
  * pci_epc_unmap_addr() - unmap CPU address from PCI address
  * @epc: the EPC device on which address is allocated
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @phys_addr: physical address of the local system
  *
  * Invoke to unmap the CPU address from PCI address.
  */
-void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no,
+void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			phys_addr_t phys_addr)
 {
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return;
+
 	if (!epc->ops->unmap_addr)
 		return;
 
 	mutex_lock(&epc->lock);
-	epc->ops->unmap_addr(epc, func_no, phys_addr);
+	epc->ops->unmap_addr(epc, func_no, vfunc_no, phys_addr);
 	mutex_unlock(&epc->lock);
 }
 EXPORT_SYMBOL_GPL(pci_epc_unmap_addr);
@@ -415,14 +450,15 @@ EXPORT_SYMBOL_GPL(pci_epc_unmap_addr);
 /**
  * pci_epc_map_addr() - map CPU address to PCI address
  * @epc: the EPC device on which address is allocated
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @phys_addr: physical address of the local system
  * @pci_addr: PCI address to which the physical address should be mapped
  * @size: the size of the allocation
  *
  * Invoke to map CPU address with PCI address.
  */
-int pci_epc_map_addr(struct pci_epc *epc, u8 func_no,
+int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		     phys_addr_t phys_addr, u64 pci_addr, size_t size)
 {
 	int ret;
@@ -430,11 +466,15 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no,
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->map_addr)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->map_addr(epc, func_no, phys_addr, pci_addr, size);
+	ret = epc->ops->map_addr(epc, func_no, vfunc_no, phys_addr, pci_addr,
+				 size);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -444,12 +484,13 @@ EXPORT_SYMBOL_GPL(pci_epc_map_addr);
 /**
  * pci_epc_clear_bar() - reset the BAR
  * @epc: the EPC device for which the BAR has to be cleared
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @epf_bar: the struct epf_bar that contains the BAR information
  *
  * Invoke to reset the BAR of the endpoint device.
  */
-void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no,
+void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		       struct pci_epf_bar *epf_bar)
 {
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions ||
@@ -457,11 +498,14 @@ void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no,
 	     epf_bar->flags & PCI_BASE_ADDRESS_MEM_TYPE_64))
 		return;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return;
+
 	if (!epc->ops->clear_bar)
 		return;
 
 	mutex_lock(&epc->lock);
-	epc->ops->clear_bar(epc, func_no, epf_bar);
+	epc->ops->clear_bar(epc, func_no, vfunc_no, epf_bar);
 	mutex_unlock(&epc->lock);
 }
 EXPORT_SYMBOL_GPL(pci_epc_clear_bar);
@@ -469,12 +513,13 @@ EXPORT_SYMBOL_GPL(pci_epc_clear_bar);
 /**
  * pci_epc_set_bar() - configure BAR in order for host to assign PCI addr space
  * @epc: the EPC device on which BAR has to be configured
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @epf_bar: the struct epf_bar that contains the BAR information
  *
  * Invoke to configure the BAR of the endpoint device.
  */
-int pci_epc_set_bar(struct pci_epc *epc, u8 func_no,
+int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		    struct pci_epf_bar *epf_bar)
 {
 	int ret;
@@ -489,11 +534,14 @@ int pci_epc_set_bar(struct pci_epc *epc, u8 func_no,
 	     !(flags & PCI_BASE_ADDRESS_MEM_TYPE_64)))
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->set_bar)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->set_bar(epc, func_no, epf_bar);
+	ret = epc->ops->set_bar(epc, func_no, vfunc_no, epf_bar);
 	mutex_unlock(&epc->lock);
 
 	return ret;
@@ -503,7 +551,8 @@ EXPORT_SYMBOL_GPL(pci_epc_set_bar);
 /**
  * pci_epc_write_header() - write standard configuration header
  * @epc: the EPC device to which the configuration header should be written
- * @func_no: the endpoint function number in the EPC device
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
  * @header: standard configuration header fields
  *
  * Invoke to write the configuration header to the endpoint controller. Every
@@ -511,7 +560,7 @@ EXPORT_SYMBOL_GPL(pci_epc_set_bar);
  * configuration header would be written. The callback function should write
  * the header fields to this dedicated location.
  */
-int pci_epc_write_header(struct pci_epc *epc, u8 func_no,
+int pci_epc_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			 struct pci_epf_header *header)
 {
 	int ret;
@@ -519,11 +568,14 @@ int pci_epc_write_header(struct pci_epc *epc, u8 func_no,
 	if (IS_ERR_OR_NULL(epc) || func_no >= epc->max_functions)
 		return -EINVAL;
 
+	if (vfunc_no > 0 && (!epc->max_vfs || vfunc_no > epc->max_vfs[func_no]))
+		return -EINVAL;
+
 	if (!epc->ops->write_header)
 		return 0;
 
 	mutex_lock(&epc->lock);
-	ret = epc->ops->write_header(epc, func_no, header);
+	ret = epc->ops->write_header(epc, func_no, vfunc_no, header);
 	mutex_unlock(&epc->lock);
 
 	return ret;
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index 3f1271a63be5..ff39b54e5d05 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -90,11 +90,14 @@ EXPORT_SYMBOL_GPL(pci_epf_unbind);
  */
 int pci_epf_bind(struct pci_epf *epf)
 {
+	struct device *dev = &epf->dev;
 	struct pci_epf *epf_vf;
+	u8 func_no, vfunc_no;
+	struct pci_epc *epc;
 	int ret;
 
 	if (!epf->driver) {
-		dev_WARN(&epf->dev, "epf device not bound to driver\n");
+		dev_WARN(dev, "epf device not bound to driver\n");
 		return -EINVAL;
 	}
 
@@ -103,7 +106,50 @@ int pci_epf_bind(struct pci_epf *epf)
 
 	mutex_lock(&epf->lock);
 	list_for_each_entry(epf_vf, &epf->pci_vepf, list) {
+		vfunc_no = epf_vf->vfunc_no;
+
+		if (vfunc_no < 1) {
+			dev_err(dev, "Invalid virtual function number\n");
+			ret = -EINVAL;
+			goto ret;
+		}
+
+		epc = epf->epc;
+		func_no = epf->func_no;
+		if (!IS_ERR_OR_NULL(epc)) {
+			if (!epc->max_vfs) {
+				dev_err(dev, "No support for virt function\n");
+				ret = -EINVAL;
+				goto ret;
+			}
+
+			if (vfunc_no > epc->max_vfs[func_no]) {
+				dev_err(dev, "PF%d: Exceeds max vfunc number\n",
+					func_no);
+				ret = -EINVAL;
+				goto ret;
+			}
+		}
+
+		epc = epf->sec_epc;
+		func_no = epf->sec_epc_func_no;
+		if (!IS_ERR_OR_NULL(epc)) {
+			if (!epc->max_vfs) {
+				dev_err(dev, "No support for virt function\n");
+				ret = -EINVAL;
+				goto ret;
+			}
+
+			if (vfunc_no > epc->max_vfs[func_no]) {
+				dev_err(dev, "PF%d: Exceeds max vfunc number\n",
+					func_no);
+				ret = -EINVAL;
+				goto ret;
+			}
+		}
+
 		epf_vf->func_no = epf->func_no;
+		epf_vf->sec_epc_func_no = epf->sec_epc_func_no;
 		epf_vf->epc = epf->epc;
 		epf_vf->sec_epc = epf->sec_epc;
 		ret = epf_vf->driver->ops->bind(epf_vf);
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index b82c9b100e97..3485d1a98682 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -61,31 +61,32 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
  * @owner: the module owner containing the ops
  */
 struct pci_epc_ops {
-	int	(*write_header)(struct pci_epc *epc, u8 func_no,
+	int	(*write_header)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 				struct pci_epf_header *hdr);
-	int	(*set_bar)(struct pci_epc *epc, u8 func_no,
+	int	(*set_bar)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			   struct pci_epf_bar *epf_bar);
-	void	(*clear_bar)(struct pci_epc *epc, u8 func_no,
+	void	(*clear_bar)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			     struct pci_epf_bar *epf_bar);
-	int	(*map_addr)(struct pci_epc *epc, u8 func_no,
+	int	(*map_addr)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			    phys_addr_t addr, u64 pci_addr, size_t size);
-	void	(*unmap_addr)(struct pci_epc *epc, u8 func_no,
+	void	(*unmap_addr)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			      phys_addr_t addr);
-	int	(*set_msi)(struct pci_epc *epc, u8 func_no, u8 interrupts);
-	int	(*get_msi)(struct pci_epc *epc, u8 func_no);
-	int	(*set_msix)(struct pci_epc *epc, u8 func_no, u16 interrupts,
-			    enum pci_barno, u32 offset);
-	int	(*get_msix)(struct pci_epc *epc, u8 func_no);
-	int	(*raise_irq)(struct pci_epc *epc, u8 func_no,
+	int	(*set_msi)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			   u8 interrupts);
+	int	(*get_msi)(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
+	int	(*set_msix)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+			    u16 interrupts, enum pci_barno, u32 offset);
+	int	(*get_msix)(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
+	int	(*raise_irq)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			     enum pci_epc_irq_type type, u16 interrupt_num);
-	int	(*map_msi_irq)(struct pci_epc *epc, u8 func_no,
+	int	(*map_msi_irq)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			       phys_addr_t phys_addr, u8 interrupt_num,
 			       u32 entry_size, u32 *msi_data,
 			       u32 *msi_addr_offset);
 	int	(*start)(struct pci_epc *epc);
 	void	(*stop)(struct pci_epc *epc);
 	const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
-						       u8 func_no);
+						       u8 func_no, u8 vfunc_no);
 	struct module *owner;
 };
 
@@ -127,6 +128,8 @@ struct pci_epc_mem {
  *       single window.
  * @num_windows: number of windows supported by device
  * @max_functions: max number of functions that can be configured in this EPC
+ * @max_vfs: Array indicating the maximum number of virtual functions that can
+ *   be associated with each physical function
  * @group: configfs group representing the PCI EPC device
  * @lock: mutex to protect pci_epc ops
  * @function_num_map: bitmap to manage physical function number
@@ -140,6 +143,7 @@ struct pci_epc {
 	struct pci_epc_mem		*mem;
 	unsigned int			num_windows;
 	u8				max_functions;
+	u8				*max_vfs;
 	struct config_group		*group;
 	/* mutex to protect against concurrent access of EP controller */
 	struct mutex			lock;
@@ -205,31 +209,32 @@ void pci_epc_linkup(struct pci_epc *epc);
 void pci_epc_init_notify(struct pci_epc *epc);
 void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf,
 			enum pci_epc_interface_type type);
-int pci_epc_write_header(struct pci_epc *epc, u8 func_no,
+int pci_epc_write_header(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			 struct pci_epf_header *hdr);
-int pci_epc_set_bar(struct pci_epc *epc, u8 func_no,
+int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		    struct pci_epf_bar *epf_bar);
-void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no,
+void pci_epc_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		       struct pci_epf_bar *epf_bar);
-int pci_epc_map_addr(struct pci_epc *epc, u8 func_no,
+int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		     phys_addr_t phys_addr,
 		     u64 pci_addr, size_t size);
-void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no,
+void pci_epc_unmap_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			phys_addr_t phys_addr);
-int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts);
-int pci_epc_get_msi(struct pci_epc *epc, u8 func_no);
-int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
-		     enum pci_barno, u32 offset);
-int pci_epc_get_msix(struct pci_epc *epc, u8 func_no);
-int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no,
+int pci_epc_set_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+		    u8 interrupts);
+int pci_epc_get_msi(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
+int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+		     u16 interrupts, enum pci_barno, u32 offset);
+int pci_epc_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no);
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 			phys_addr_t phys_addr, u8 interrupt_num,
 			u32 entry_size, u32 *msi_data, u32 *msi_addr_offset);
-int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
+int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
 		      enum pci_epc_irq_type type, u16 interrupt_num);
 int pci_epc_start(struct pci_epc *epc);
 void pci_epc_stop(struct pci_epc *epc);
 const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
-						    u8 func_no);
+						    u8 func_no, u8 vfunc_no);
 enum pci_barno
 pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features);
 enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:33:59 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:03:59 +0530
Subject: [PATCH v5 5/7] PCI: cadence: Add support to configure virtual
 functions
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-6-kishon@ti.com>

Now that support for SR-IOV is added in PCIe endpoint core, add support
to configure virtual functions in the Cadence PCIe EP driver.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 .../pci/controller/cadence/pcie-cadence-ep.c  | 241 +++++++++++++++---
 drivers/pci/controller/cadence/pcie-cadence.h |   7 +
 2 files changed, 217 insertions(+), 31 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 912a15be8bfd..791915054ff4 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -20,7 +20,18 @@ static int cdns_pcie_ep_write_header(struct pci_epc *epc, u8 fn, u8 vfn,
 				     struct pci_epf_header *hdr)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie *pcie = &ep->pcie;
+	u32 reg;
+
+	if (vfn > 1) {
+		dev_dbg(&epc->dev, "Only Virtual Function #1 has deviceID\n");
+		return 0;
+	} else if (vfn == 1) {
+		reg = cap + PCI_SRIOV_VF_DID;
+		cdns_pcie_ep_fn_writew(pcie, fn, reg, hdr->deviceid);
+		return 0;
+	}
 
 	cdns_pcie_ep_fn_writew(pcie, fn, PCI_DEVICE_ID, hdr->deviceid);
 	cdns_pcie_ep_fn_writeb(pcie, fn, PCI_REVISION_ID, hdr->revid);
@@ -51,12 +62,14 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				struct pci_epf_bar *epf_bar)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie_epf *epf = &ep->epf[fn];
 	struct cdns_pcie *pcie = &ep->pcie;
 	dma_addr_t bar_phys = epf_bar->phys_addr;
 	enum pci_barno bar = epf_bar->barno;
 	int flags = epf_bar->flags;
 	u32 addr0, addr1, reg, cfg, b, aperture, ctrl;
+	u32 first_vf_offset, stride;
 	u64 sz;
 
 	/* BAR size is 2^(aperture + 7) */
@@ -92,26 +105,50 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 
 	addr0 = lower_32_bits(bar_phys);
 	addr1 = upper_32_bits(bar_phys);
+
+	if (vfn == 1) {
+		/* All virtual functions use the same BAR config */
+		if (bar < BAR_4) {
+			reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG0(fn);
+			b = bar;
+		} else {
+			reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG1(fn);
+			b = bar - BAR_4;
+		}
+	} else if (vfn == 0) {
+		/* BAR configuration for physical function */
+		if (bar < BAR_4) {
+			reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
+			b = bar;
+		} else {
+			reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
+			b = bar - BAR_4;
+		}
+	}
+
+	if (vfn == 0 || vfn == 1) {
+		cfg = cdns_pcie_readl(pcie, reg);
+		cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
+			 CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
+		cfg |= (CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE(b, aperture) |
+			CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl));
+		cdns_pcie_writel(pcie, reg, cfg);
+	}
+
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+		epf = &epf->epf[vfn - 1];
+	}
+
 	cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar),
 			 addr0);
 	cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar),
 			 addr1);
 
-	if (bar < BAR_4) {
-		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
-		b = bar;
-	} else {
-		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
-		b = bar - BAR_4;
-	}
-
-	cfg = cdns_pcie_readl(pcie, reg);
-	cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
-		 CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
-	cfg |= (CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE(b, aperture) |
-		CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl));
-	cdns_pcie_writel(pcie, reg, cfg);
-
 	epf->epf_bar[bar] = epf_bar;
 
 	return 0;
@@ -121,25 +158,48 @@ static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, u8 fn, u8 vfn,
 				   struct pci_epf_bar *epf_bar)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie_epf *epf = &ep->epf[fn];
 	struct cdns_pcie *pcie = &ep->pcie;
 	enum pci_barno bar = epf_bar->barno;
+	u32 first_vf_offset, stride;
 	u32 reg, cfg, b, ctrl;
 
-	if (bar < BAR_4) {
-		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
-		b = bar;
-	} else {
-		reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
-		b = bar - BAR_4;
+	if (vfn == 1) {
+		if (bar < BAR_4) {
+			reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG0(fn);
+			b = bar;
+		} else {
+			reg = CDNS_PCIE_LM_EP_VFUNC_BAR_CFG1(fn);
+			b = bar - BAR_4;
+		}
+	} else if (vfn == 0) {
+		if (bar < BAR_4) {
+			reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
+			b = bar;
+		} else {
+			reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
+			b = bar - BAR_4;
+		}
 	}
 
-	ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED;
-	cfg = cdns_pcie_readl(pcie, reg);
-	cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
-		 CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
-	cfg |= CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl);
-	cdns_pcie_writel(pcie, reg, cfg);
+	if (vfn == 0 || vfn == 1) {
+		ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED;
+		cfg = cdns_pcie_readl(pcie, reg);
+		cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
+			 CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
+		cfg |= CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl);
+		cdns_pcie_writel(pcie, reg, cfg);
+	}
+
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+		epf = &epf->epf[vfn - 1];
+	}
 
 	cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar), 0);
 	cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar), 0);
@@ -152,8 +212,18 @@ static int cdns_pcie_ep_map_addr(struct pci_epc *epc, u8 fn, u8 vfn,
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
+	u32 cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
+	u32 first_vf_offset, stride;
 	u32 r;
 
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
+
 	r = find_first_zero_bit(&ep->ob_region_map,
 				sizeof(ep->ob_region_map) * BITS_PER_LONG);
 	if (r >= ep->max_regions - 1) {
@@ -193,9 +263,19 @@ static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 fn, u8 vfn, u8 mmc)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
+	u32 first_vf_offset, stride;
 	u16 flags;
 
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
+
 	/*
 	 * Set the Multiple Message Capable bitfield into the Message Control
 	 * register.
@@ -213,9 +293,19 @@ static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8 fn, u8 vfn)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
+	u32 first_vf_offset, stride;
 	u16 flags, mme;
 
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
+
 	/* Validate that the MSI feature is actually enabled. */
 	flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
 	if (!(flags & PCI_MSI_FLAGS_ENABLE))
@@ -232,11 +322,21 @@ static int cdns_pcie_ep_get_msi(struct pci_epc *epc, u8 fn, u8 vfn)
 
 static int cdns_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
+	u32 first_vf_offset, stride;
 	u32 val, reg;
 
+	if (vfunc_no > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, func_no, sriov_cap
+							+ PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, func_no, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		func_no = func_no + first_vf_offset + ((vfunc_no - 1) * stride);
+	}
+
 	reg = cap + PCI_MSIX_FLAGS;
 	val = cdns_pcie_ep_fn_readw(pcie, func_no, reg);
 	if (!(val & PCI_MSIX_FLAGS_ENABLE))
@@ -251,11 +351,21 @@ static int cdns_pcie_ep_set_msix(struct pci_epc *epc, u8 fn, u8 vfn,
 				 u16 interrupts, enum pci_barno bir,
 				 u32 offset)
 {
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	struct cdns_pcie *pcie = &ep->pcie;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
+	u32 first_vf_offset, stride;
 	u32 val, reg;
 
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
+
 	reg = cap + PCI_MSIX_FLAGS;
 	val = cdns_pcie_ep_fn_readw(pcie, fn, reg);
 	val &= ~PCI_MSIX_FLAGS_QSIZE;
@@ -275,8 +385,8 @@ static int cdns_pcie_ep_set_msix(struct pci_epc *epc, u8 fn, u8 vfn,
 	return 0;
 }
 
-static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn,
-				     u8 intx, bool is_asserted)
+static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn, u8 intx,
+				     bool is_asserted)
 {
 	struct cdns_pcie *pcie = &ep->pcie;
 	unsigned long flags;
@@ -339,11 +449,21 @@ static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 				     u8 interrupt_num)
 {
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie *pcie = &ep->pcie;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
 	u16 flags, mme, data, data_mask;
 	u8 msi_count;
 	u64 pci_addr, pci_addr_mask = 0xff;
+	u32 first_vf_offset, stride;
+
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
 
 	/* Check whether the MSI feature has been enabled by the PCI host. */
 	flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
@@ -389,15 +509,25 @@ static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				    u32 entry_size, u32 *msi_data,
 				    u32 *msi_addr_offset)
 {
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
 	u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
 	struct cdns_pcie *pcie = &ep->pcie;
 	u64 pci_addr, pci_addr_mask = 0xff;
 	u16 flags, mme, data, data_mask;
+	u32 first_vf_offset, stride;
 	u8 msi_count;
 	int ret;
 	int i;
 
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+	}
+
 	/* Check whether the MSI feature has been enabled by the PCI host. */
 	flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
 	if (!(flags & PCI_MSI_FLAGS_ENABLE))
@@ -438,16 +568,29 @@ static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 				      u16 interrupt_num)
 {
+	u32 sriov_cap = CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET;
 	u32 cap = CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET;
 	u32 tbl_offset, msg_data, reg;
 	struct cdns_pcie *pcie = &ep->pcie;
 	struct pci_epf_msix_tbl *msix_tbl;
+	u32 first_vf_offset, stride;
 	struct cdns_pcie_epf *epf;
 	u64 pci_addr_mask = 0xff;
 	u64 msg_addr;
 	u16 flags;
 	u8 bir;
 
+	epf = &ep->epf[fn];
+
+	if (vfn > 0) {
+		first_vf_offset = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+							PCI_SRIOV_VF_OFFSET);
+		stride = cdns_pcie_ep_fn_readw(pcie, fn, sriov_cap +
+					       PCI_SRIOV_VF_STRIDE);
+		fn = fn + first_vf_offset + ((vfn - 1) * stride);
+		epf = &epf->epf[vfn - 1];
+	}
+
 	/* Check whether the MSI-X feature has been enabled by the PCI host. */
 	flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSIX_FLAGS);
 	if (!(flags & PCI_MSIX_FLAGS_ENABLE))
@@ -458,7 +601,6 @@ static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn, u8 vfn,
 	bir = tbl_offset & PCI_MSIX_TABLE_BIR;
 	tbl_offset &= PCI_MSIX_TABLE_OFFSET;
 
-	epf = &ep->epf[fn];
 	msix_tbl = epf->epf_bar[bir]->addr + tbl_offset;
 	msg_addr = msix_tbl[(interrupt_num - 1)].msg_addr;
 	msg_data = msix_tbl[(interrupt_num - 1)].msg_data;
@@ -485,9 +627,15 @@ static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn, u8 vfn,
 				  u16 interrupt_num)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	struct cdns_pcie *pcie = &ep->pcie;
+	struct device *dev = pcie->dev;
 
 	switch (type) {
 	case PCI_EPC_IRQ_LEGACY:
+		if (vfn > 0) {
+			dev_err(dev, "Cannot raise legacy interrupts for VF\n");
+			return -EINVAL;
+		}
 		return cdns_pcie_ep_send_legacy_irq(ep, fn, vfn, 0);
 
 	case PCI_EPC_IRQ_MSI:
@@ -525,6 +673,13 @@ static int cdns_pcie_ep_start(struct pci_epc *epc)
 	return 0;
 }
 
+static const struct pci_epc_features cdns_pcie_epc_vf_features = {
+	.linkup_notifier = false,
+	.msi_capable = true,
+	.msix_capable = true,
+	.align = 65536,
+};
+
 static const struct pci_epc_features cdns_pcie_epc_features = {
 	.linkup_notifier = false,
 	.msi_capable = true,
@@ -535,7 +690,10 @@ static const struct pci_epc_features cdns_pcie_epc_features = {
 static const struct pci_epc_features*
 cdns_pcie_ep_get_features(struct pci_epc *epc, u8 func_no, u8 vfunc_no)
 {
-	return &cdns_pcie_epc_features;
+	if (!vfunc_no)
+		return &cdns_pcie_epc_features;
+
+	return &cdns_pcie_epc_vf_features;
 }
 
 static const struct pci_epc_ops cdns_pcie_epc_ops = {
@@ -561,9 +719,11 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct device_node *np = dev->of_node;
 	struct cdns_pcie *pcie = &ep->pcie;
+	struct cdns_pcie_epf *epf;
 	struct resource *res;
 	struct pci_epc *epc;
 	int ret;
+	int i;
 
 	pcie->is_rc = false;
 
@@ -608,6 +768,25 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 	if (!ep->epf)
 		return -ENOMEM;
 
+	epc->max_vfs = devm_kcalloc(dev, epc->max_functions,
+				    sizeof(*epc->max_vfs), GFP_KERNEL);
+	if (!epc->max_vfs)
+		return -ENOMEM;
+
+	ret = of_property_read_u8_array(np, "max-virtual-functions",
+					epc->max_vfs, epc->max_functions);
+	if (ret == 0) {
+		for (i = 0; i < epc->max_functions; i++) {
+			epf = &ep->epf[i];
+			if (epc->max_vfs[i] == 0)
+				continue;
+			epf->epf = devm_kcalloc(dev, epc->max_vfs[i],
+						sizeof(*ep->epf), GFP_KERNEL);
+			if (!epf->epf)
+				return -ENOMEM;
+		}
+	}
+
 	ret = pci_epc_mem_init(epc, pcie->mem_res->start,
 			       resource_size(pcie->mem_res), PAGE_SIZE);
 	if (ret < 0) {
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
index 254d2570f8c9..22ff4c9defd8 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -50,6 +50,10 @@
 	(CDNS_PCIE_LM_BASE + 0x0240 + (fn) * 0x0008)
 #define CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn) \
 	(CDNS_PCIE_LM_BASE + 0x0244 + (fn) * 0x0008)
+#define CDNS_PCIE_LM_EP_VFUNC_BAR_CFG0(fn) \
+	(CDNS_PCIE_LM_BASE + 0x0280 + (fn) * 0x0008)
+#define CDNS_PCIE_LM_EP_VFUNC_BAR_CFG1(fn) \
+	(CDNS_PCIE_LM_BASE + 0x0284 + (fn) * 0x0008)
 #define  CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) \
 	(GENMASK(4, 0) << ((b) * 8))
 #define  CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE(b, a) \
@@ -114,6 +118,7 @@
 
 #define CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET	0x90
 #define CDNS_PCIE_EP_FUNC_MSIX_CAP_OFFSET	0xb0
+#define CDNS_PCIE_EP_FUNC_SRIOV_CAP_OFFSET	0x200
 
 /*
  * Root Port Registers (PCI configuration space for the root port function)
@@ -305,9 +310,11 @@ struct cdns_pcie_rc {
 
 /**
  * struct cdns_pcie_epf - Structure to hold info about endpoint function
+ * @epf: Info about virtual functions attached to the physical function
  * @epf_bar: reference to the pci_epf_bar for the six Base Address Registers
  */
 struct cdns_pcie_epf {
+	struct cdns_pcie_epf *epf;
 	struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
 };
 
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:34:00 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:04:00 +0530
Subject: [PATCH v5 6/7] misc: pci_endpoint_test: Populate sriov_configure ops
 to configure SR-IOV device
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-7-kishon@ti.com>

Populate sriov_configure ops with pci_sriov_configure_simple to
configure SR-IOV device.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 drivers/misc/pci_endpoint_test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 1b2868ca4f2a..c7ee34013485 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -978,6 +978,7 @@ static struct pci_driver pci_endpoint_test_driver = {
 	.id_table	= pci_endpoint_test_tbl,
 	.probe		= pci_endpoint_test_probe,
 	.remove		= pci_endpoint_test_remove,
+	.sriov_configure = pci_sriov_configure_simple,
 };
 module_pci_driver(pci_endpoint_test_driver);
 
-- 
2.17.1



From kishon at ti.com  Mon Apr 19 09:34:01 2021
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 19 Apr 2021 14:04:01 +0530
Subject: [PATCH v5 7/7] Documentation: PCI: endpoint/pci-endpoint-cfs: Guide
 to use SR-IOV
In-Reply-To: <20210419083401.31628-1-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
Message-ID: <20210419083401.31628-8-kishon@ti.com>

Add Documentation to help users use PCI endpoint to create virtual
functions using configfs. An endpoint function is designated as a
virtual endpoint function device when it is linked to a physical
endpoint function device (instead of a endpoint controller).

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 Documentation/PCI/endpoint/pci-endpoint-cfs.rst | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
index 696f8eeb4738..56fb33c5e8fd 100644
--- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
@@ -43,6 +43,7 @@ entries corresponding to EPF driver will be created by the EPF core.
 		.. <EPF Driver1>/
 			... <EPF Device 11>/
 			... <EPF Device 21>/
+			... <EPF Device 31>/
 		.. <EPF Driver2>/
 			... <EPF Device 12>/
 			... <EPF Device 22>/
@@ -68,6 +69,7 @@ created)
 				... subsys_vendor_id
 				... subsys_id
 				... interrupt_pin
+			        ... <Symlink EPF Device 31>/
                                 ... primary/
 			                ... <Symlink EPC Device1>/
                                 ... secondary/
@@ -79,6 +81,13 @@ interface should be added in 'primary' directory and symlink of endpoint
 controller connected to secondary interface should be added in 'secondary'
 directory.
 
+The <EPF Device> directory can have a list of symbolic links
+(<Symlink EPF Device 31>) to other <EPF Device>. These symbolic links should
+be created by the user to represent the virtual functions that are bound to
+the physical function. In the above directory structure <EPF Device 11> is a
+physical function and <EPF Device 31> is a virtual function. An EPF device once
+it's linked to another EPF device, cannot be linked to a EPC device.
+
 EPC Device
 ==========
 
@@ -98,7 +107,8 @@ entries corresponding to EPC device will be created by the EPC core.
 
 The <EPC Device> directory will have a list of symbolic links to
 <EPF Device>. These symbolic links should be created by the user to
-represent the functions present in the endpoint device.
+represent the functions present in the endpoint device. Only <EPF Device>
+that represents a physical function can be linked to a EPC device.
 
 The <EPC Device> directory will also have a *start* field. Once
 "1" is written to this field, the endpoint device will be ready to
-- 
2.17.1



From alistair at alistair23.me  Sun Apr 18 22:00:03 2021
From: alistair at alistair23.me (Alistair Francis)
Date: Mon, 19 Apr 2021 07:00:03 +1000
Subject: [PATCH] ARM: imx7d-remarkable2.dts: Add WiFi support
Message-ID: <20210418210003.2806-1-alistair@alistair23.me>

Signed-off-by: Alistair Francis <alistair at alistair23.me>
---
 arch/arm/boot/dts/imx7d-remarkable2.dts | 91 +++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-remarkable2.dts b/arch/arm/boot/dts/imx7d-remarkable2.dts
index 8cbae656395c..c3dda2b92fe6 100644
--- a/arch/arm/boot/dts/imx7d-remarkable2.dts
+++ b/arch/arm/boot/dts/imx7d-remarkable2.dts
@@ -21,6 +21,27 @@ memory at 80000000 {
 		device_type = "memory";
 		reg = <0x80000000 0x40000000>;
 	};
+
+	reg_brcm: regulator-brcm {
+		compatible = "regulator-fixed";
+		regulator-name = "brcm_reg";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_brcm_reg>;
+		gpio = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		startup-delay-us = <150>;
+	};
+
+	wifi_pwrseq: wifi_pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_wifi>;
+		reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+		clocks = <&clks IMX7D_CLKO2_ROOT_DIV>;
+		clock-names = "ext_clock";
+	};
 };
 
 &clks {
@@ -56,6 +77,27 @@ &usbotg2 {
 	status = "okay";
 };
 
+&usdhc2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default", "state_100mhz", "sleep";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc2>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	vmmc-supply = <&reg_brcm>;
+	bus-width = <4>;
+	non-removable;
+	keep-power-in-suspend;
+	cap-power-off-card;
+	status = "okay";
+
+	brcmf: bcrmf at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
+};
+
 &usdhc3 {
 	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
 	pinctrl-0 = <&pinctrl_usdhc3>;
@@ -76,6 +118,13 @@ &wdog1 {
 };
 
 &iomuxc {
+	pinctrl_brcm_reg: brcmreggrp {
+		fsl,pins = <
+			/* WIFI_PWR_EN */
+			MX7D_PAD_SAI1_TX_BCLK__GPIO6_IO13	0x14
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX	0x79
@@ -90,6 +139,39 @@ MX7D_PAD_EPDC_DATA08__UART6_DCE_RX		0x79
 		>;
 	};
 
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX7D_PAD_SD2_CMD__SD2_CMD		0x59
+			MX7D_PAD_SD2_CLK__SD2_CLK		0x19
+			MX7D_PAD_SD2_DATA0__SD2_DATA0		0x59
+			MX7D_PAD_SD2_DATA1__SD2_DATA1		0x59
+			MX7D_PAD_SD2_DATA2__SD2_DATA2		0x59
+			MX7D_PAD_SD2_DATA3__SD2_DATA3		0x59
+		>;
+	};
+
+	pinctrl_usdhc2_100mhz: usdhc2grp_100mhz {
+		fsl,pins = <
+			MX7D_PAD_SD2_CMD__SD2_CMD		0x5a
+			MX7D_PAD_SD2_CLK__SD2_CLK		0x1a
+			MX7D_PAD_SD2_DATA0__SD2_DATA0		0x5a
+			MX7D_PAD_SD2_DATA1__SD2_DATA1		0x5a
+			MX7D_PAD_SD2_DATA2__SD2_DATA2		0x5a
+			MX7D_PAD_SD2_DATA3__SD2_DATA3		0x5a
+		>;
+	};
+
+	pinctrl_usdhc2_200mhz: usdhc2grp_200mhz {
+		fsl,pins = <
+			MX7D_PAD_SD2_CMD__SD2_CMD		0x5b
+			MX7D_PAD_SD2_CLK__SD2_CLK		0x1b
+			MX7D_PAD_SD2_DATA0__SD2_DATA0		0x5b
+			MX7D_PAD_SD2_DATA1__SD2_DATA1		0x5b
+			MX7D_PAD_SD2_DATA2__SD2_DATA2		0x5b
+			MX7D_PAD_SD2_DATA3__SD2_DATA3		0x5b
+		>;
+	};
+
 	pinctrl_usdhc3: usdhc3grp {
 		fsl,pins = <
 			MX7D_PAD_SD3_CMD__SD3_CMD		0x59
@@ -143,4 +225,13 @@ pinctrl_wdog: wdoggrp {
 			MX7D_PAD_ENET1_COL__WDOG1_WDOG_ANY	0x74
 		>;
 	};
+
+	pinctrl_wifi: wifigrp {
+		fsl,pins = <
+			/* WiFi Reg On */
+			MX7D_PAD_SD2_CD_B__GPIO5_IO9		0x00000014
+			/* WiFi Sleep 32k */
+			MX7D_PAD_SD1_WP__CCM_CLKO2		0x00000014
+		>;
+	};
 };
-- 
2.31.1



From rppt at kernel.org  Mon Apr 19 09:42:18 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 19 Apr 2021 11:42:18 +0300
Subject: [PATCH] secretmem: optimize page_is_secretmem()
Message-ID: <20210419084218.7466-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".

The perf profile of the test indicated that the regression is caused by
page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):

 27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
  0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
  0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem

Further analysis showed that the slow down happens because neither
page_is_secretmem() nor page_mapping() are not inline and moreover,
multiple page flags checks in page_mapping() involve calling
compound_head() several times for the same page.

Make page_is_secretmem() inline and replace page_mapping() with page flag
checks that do not imply page-to-head conversion.

Reported-by: kernel test robot <oliver.sang at intel.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---

@Andrew,
The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
be added as a fixup to the memfd_secret series.

 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/secretmem.c            | 12 +-----------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 907a6734059c..b842b38cbeb1 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -4,8 +4,32 @@
 
 #ifdef CONFIG_SECRETMEM
 
+extern const struct address_space_operations secretmem_aops;
+
+static inline bool page_is_secretmem(struct page *page)
+{
+	struct address_space *mapping;
+
+	/*
+	 * Using page_mapping() is quite slow because of the actual call
+	 * instruction and repeated compound_head(page) inside the
+	 * page_mapping() function.
+	 * We know that secretmem pages are not compound and LRU so we can
+	 * save a couple of cycles here.
+	 */
+	if (PageCompound(page) || !PageLRU(page))
+		return false;
+
+	mapping = (struct address_space *)
+		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
+
+	if (mapping != page->mapping)
+		return false;
+
+	return page->mapping->a_ops == &secretmem_aops;
+}
+
 bool vma_is_secretmem(struct vm_area_struct *vma);
-bool page_is_secretmem(struct page *page);
 bool secretmem_active(void);
 
 #else
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 3b1ba3991964..0bcd15e1b549 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -151,22 +151,12 @@ static void secretmem_freepage(struct page *page)
 	clear_highpage(page);
 }
 
-static const struct address_space_operations secretmem_aops = {
+const struct address_space_operations secretmem_aops = {
 	.freepage	= secretmem_freepage,
 	.migratepage	= secretmem_migratepage,
 	.isolate_page	= secretmem_isolate_page,
 };
 
-bool page_is_secretmem(struct page *page)
-{
-	struct address_space *mapping = page_mapping(page);
-
-	if (!mapping)
-		return false;
-
-	return mapping->a_ops == &secretmem_aops;
-}
-
 static struct vfsmount *secretmem_mnt;
 
 static struct file *secretmem_file_create(unsigned long flags)
-- 
2.28.0



From daniel.lezcano at linaro.org  Mon Apr 19 09:44:34 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 19 Apr 2021 10:44:34 +0200
Subject: [PATCH] [v4, 1/1] clocksource/drivers/timer-mediatek: optimize
 systimer irq clear flow on shutdown
In-Reply-To: <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>
References: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>
 <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>
Message-ID: <4d3b342c-a14f-f4ac-6860-9f6a88a24501@linaro.org>

On 09/04/2021 11:22, Fengquan Chen wrote:
> mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
> clear any pending systimer irq when shutdown to avoid suspend aborted
> due to timer irq pending
> 
> Also as for systimer in mediatek socs, there must be firstly enable
> timer before clear systimer irq
> 
> Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer")
> Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>
> 
> ---
>  drivers/clocksource/timer-mediatek.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> index 9318edc..6461fd3 100644
> --- a/drivers/clocksource/timer-mediatek.c
> +++ b/drivers/clocksource/timer-mediatek.c
> @@ -60,9 +60,9 @@
>   * SYST_CON_EN: Clock enable. Shall be set to
>   *   - Start timer countdown.
>   *   - Allow timeout ticks being updated.
> - *   - Allow changing interrupt functions.
> + *   - Allow changing interrupt status,like clear irq pending.
>   *
> - * SYST_CON_IRQ_EN: Set to allow interrupt.
> + * SYST_CON_IRQ_EN: Set to enable interrupt.
>   *
>   * SYST_CON_IRQ_CLR: Set to clear interrupt.
>   */
> @@ -75,6 +75,7 @@
>  static void mtk_syst_ack_irq(struct timer_of *to)
>  {
>  	/* Clear and disable interrupt */
> +	writel(SYST_CON_EN, SYST_CON_REG(to));
>  	writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
>  }

IIRC, there is a hardware issue here. If it is the case, please describe
it and refer to an errata if any.

Also Evan Benn commented your code and asked a couple of questions [1],
please answer before reposting a new version.

Comments ignored == patch ignored

> @@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
>  
>  static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
>  {
> +	/* Clear any irq */
> +	mtk_syst_ack_irq(to_timer_of(clkevt));
> +
>  	/* Disable timer */
>  	writel(0, SYST_CON_REG(to_timer_of(clkevt)));

Please check out the patch sent by Evan Benn [2], if you agree, ack it.

Thanks

  -- Daniel

[1] https://patchwork.kernel.org/comment/24059277/
[2]
https://lore.kernel.org/linux-arm-kernel/20210412132200.v3.1.I1d9917047de06715da16e1620759f703fcfdcbcb at changeid/

-- 
<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 kernellwp at gmail.com  Mon Apr 19 09:49:20 2021
From: kernellwp at gmail.com (Wanpeng Li)
Date: Mon, 19 Apr 2021 16:49:20 +0800
Subject: [PATCH v2 09/10] KVM: Don't take mmu_lock for range invalidation
 unless necessary
In-Reply-To: <20210402005658.3024832-10-seanjc@google.com>
References: <20210402005658.3024832-1-seanjc@google.com>
 <20210402005658.3024832-10-seanjc@google.com>
Message-ID: <CANRm+Cwt9Xs=13r9E4YWOhcE6oEJXmVrkKrv_wQ5jMUkY8+Stw@mail.gmail.com>

On Fri, 2 Apr 2021 at 08:59, Sean Christopherson <seanjc at google.com> wrote:
>
> Avoid taking mmu_lock for unrelated .invalidate_range_{start,end}()
> notifications.  Because mmu_notifier_count must be modified while holding
> mmu_lock for write, and must always be paired across start->end to stay
> balanced, lock elision must happen in both or none.  To meet that
> requirement, add a rwsem to prevent memslot updates across range_start()
> and range_end().
>
> Use a rwsem instead of a rwlock since most notifiers _allow_ blocking,
> and the lock will be endl across the entire start() ... end() sequence.
> If anything in the sequence sleeps, including the caller or a different
> notifier, holding the spinlock would be disastrous.
>
> For notifiers that _disallow_ blocking, e.g. OOM reaping, simply go down
> the slow path of unconditionally acquiring mmu_lock.  The sane
> alternative would be to try to acquire the lock and force the notifier
> to retry on failure.  But since OOM is currently the _only_ scenario
> where blocking is disallowed attempting to optimize a guest that has been
> marked for death is pointless.
>
> Unconditionally define and use mmu_notifier_slots_lock in the memslots
> code, purely to avoid more #ifdefs.  The overhead of acquiring the lock
> is negligible when the lock is uncontested, which will always be the case
> when the MMU notifiers are not used.
>
> Note, technically flag-only memslot updates could be allowed in parallel,
> but stalling a memslot update for a relatively short amount of time is
> not a scalability issue, and this is all more than complex enough.
>
> Based heavily on code from Ben Gardon.
>
> Suggested-by: Ben Gardon <bgardon at google.com>
> Signed-off-by: Sean Christopherson <seanjc at google.com>

I saw this splatting:

 ======================================================
 WARNING: possible circular locking dependency detected
 5.12.0-rc3+ #6 Tainted: G           OE
 ------------------------------------------------------
 qemu-system-x86/3069 is trying to acquire lock:
 ffffffff9c775ca0 (mmu_notifier_invalidate_range_start){+.+.}-{0:0},
at: __mmu_notifier_invalidate_range_end+0x5/0x190

 but task is already holding lock:
 ffffaff7410a9160 (&kvm->mmu_notifier_slots_lock){.+.+}-{3:3}, at:
kvm_mmu_notifier_invalidate_range_start+0x36d/0x4f0 [kvm]

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #1 (&kvm->mmu_notifier_slots_lock){.+.+}-{3:3}:
        down_read+0x48/0x250
        kvm_mmu_notifier_invalidate_range_start+0x36d/0x4f0 [kvm]
        __mmu_notifier_invalidate_range_start+0xe8/0x260
        wp_page_copy+0x82b/0xa30
        do_wp_page+0xde/0x420
        __handle_mm_fault+0x935/0x1230
        handle_mm_fault+0x179/0x420
        do_user_addr_fault+0x1b3/0x690
        exc_page_fault+0x82/0x2b0
        asm_exc_page_fault+0x1e/0x30

 -> #0 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
        __lock_acquire+0x110f/0x1980
        lock_acquire+0x1bc/0x400
        __mmu_notifier_invalidate_range_end+0x47/0x190
        wp_page_copy+0x796/0xa30
        do_wp_page+0xde/0x420
        __handle_mm_fault+0x935/0x1230
        handle_mm_fault+0x179/0x420
        do_user_addr_fault+0x1b3/0x690
        exc_page_fault+0x82/0x2b0
        asm_exc_page_fault+0x1e/0x30

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&kvm->mmu_notifier_slots_lock);
                                lock(mmu_notifier_invalidate_range_start);
                                lock(&kvm->mmu_notifier_slots_lock);
   lock(mmu_notifier_invalidate_range_start);

  *** DEADLOCK ***

 2 locks held by qemu-system-x86/3069:
  #0: ffff9e4269f8a9e0 (&mm->mmap_lock#2){++++}-{3:3}, at:
do_user_addr_fault+0x10e/0x690
  #1: ffffaff7410a9160 (&kvm->mmu_notifier_slots_lock){.+.+}-{3:3},
at: kvm_mmu_notifier_invalidate_range_start+0x36d/0x4f0 [kvm]

 stack backtrace:
 CPU: 0 PID: 3069 Comm: qemu-system-x86 Tainted: G           OE
5.12.0-rc3+ #6
 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS
FBKTC1AUS 02/16/2016
 Call Trace:
  dump_stack+0x87/0xb7
  print_circular_bug.isra.39+0x1b4/0x210
  check_noncircular+0x103/0x150
  __lock_acquire+0x110f/0x1980
  ? __lock_acquire+0x110f/0x1980
  lock_acquire+0x1bc/0x400
  ? __mmu_notifier_invalidate_range_end+0x5/0x190
  ? find_held_lock+0x40/0xb0
  __mmu_notifier_invalidate_range_end+0x47/0x190
  ? __mmu_notifier_invalidate_range_end+0x5/0x190
  wp_page_copy+0x796/0xa30
  do_wp_page+0xde/0x420
  __handle_mm_fault+0x935/0x1230
  handle_mm_fault+0x179/0x420
  do_user_addr_fault+0x1b3/0x690
  ? rcu_read_lock_sched_held+0x4f/0x80
  exc_page_fault+0x82/0x2b0
  ? asm_exc_page_fault+0x8/0x30
  asm_exc_page_fault+0x1e/0x30
 RIP: 0033:0x55f5bef2560f


From andre.przywara at arm.com  Mon Apr 19 09:54:43 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 19 Apr 2021 09:54:43 +0100
Subject: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
In-Reply-To: <CAGb2v642Z3iH7fUWa31Rb5j+nWdZ=sXn2BYw3_dyE9P6iuL0Cg@mail.gmail.com>
References: <20210419025246.21722-1-samuel@sholland.org>
 <CAGb2v642Z3iH7fUWa31Rb5j+nWdZ=sXn2BYw3_dyE9P6iuL0Cg@mail.gmail.com>
Message-ID: <20210419095443.1548432e@slackpad.fritz.box>

On Mon, 19 Apr 2021 11:17:19 +0800
Chen-Yu Tsai <wens at csie.org> wrote:

Hi,

> On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland <samuel at sholland.org> wrote:
> >
> > Dealing with the inconsistent numbering has been a major pain, and
> > there is a solution with (as far as I can tell) no tangible downsides.
> > So let's use it.

Thanks Samuel for sending this!

> > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help
> > when referencing the whole, unpartitioned device, like is needed for
> > updating the bootloader and firmware. So for the use case of "write a
> > bootloader to the SD card, regardless of where the board is currently
> > booted from", I know of two options:
> >   - Dig around in sysfs to find the mmc number from the MMIO address,
> >     which means I have to know the MMIO addresses for every SoC, or
> >   - Apply patches like these.
> >
> > Samuel Holland (2):
> >   ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
> >   arm64: dts: allwinner: Enforce consistent MMC numbering
> >
> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi            | 6 ++++++
> >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
> >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++  
> 
> At least with Rockchip this is now done at the board level. IIRC it was
> a request from other people to not do it at the SoC level. I don't recall
> exactly who though.

FWIW, I am very much in favour of these patches, at a SoC level:
The *SoC* BootROM imposes an order, by probing the first (by MMIO
address order) MMC controller first for boot devices. IIRC that's a
different story for Rockchip?
And if people really don't care about the order, then having a certain
order doesn't hurt, so we could as well use the "natural" order, as it
was before.

Also UUIDs only help if you boot with an initramfs to resolve them,
which proves to be extra pain if you don't compile kernels on the
device, or not inside a distribution environment.


One thing I was wondering about though is that U-Boot currently defines
"mmc1 = &mmc2;", so that the eMMC is always MMC device 1. This is also
the BootROM probe order (MMC1 is never touched). I wonder if we should
mimic this here, since MMC2 is clearly the device for eMMC (due to
8-bit bus width support)? So from a block device perspective we would
have always have mmcblk0 and mmcblk1.
Otherwise it would conflict with U-Boot's current fixup[1], so
U-Boot's DT would either need to deviate or create boot script breakages
there.

Cheers,
Andre

[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L14-16


From claudiu.manoil at nxp.com  Mon Apr 19 10:07:23 2021
From: claudiu.manoil at nxp.com (Claudiu Manoil)
Date: Mon, 19 Apr 2021 09:07:23 +0000
Subject: [PATCH net-next 5/5] net: enetc: add support for flow control
In-Reply-To: <20210416234225.3715819-6-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
 <20210416234225.3715819-6-olteanv@gmail.com>
Message-ID: <AM0PR04MB6754B48B5F0C5B166783680696499@AM0PR04MB6754.eurprd04.prod.outlook.com>



>-----Original Message-----
>From: Vladimir Oltean <olteanv at gmail.com>
>Sent: Saturday, April 17, 2021 2:42 AM
>To: Jakub Kicinski <kuba at kernel.org>; David S. Miller
><davem at davemloft.net>; netdev at vger.kernel.org; Po Liu
><po.liu at nxp.com>
>Cc: Claudiu Manoil <claudiu.manoil at nxp.com>; Alexandru Marginean
><alexandru.marginean at nxp.com>; Rob Herring <robh+dt at kernel.org>;
>Shawn Guo <shawnguo at kernel.org>; linux-arm-kernel at lists.infradead.org;
>devicetree at vger.kernel.org; Russell King - ARM Linux admin
><linux at armlinux.org.uk>; Andrew Lunn <andrew at lunn.ch>; Michael Walle
><michael at walle.cc>; Vladimir Oltean <vladimir.oltean at nxp.com>
>Subject: [PATCH net-next 5/5] net: enetc: add support for flow control
>
>From: Vladimir Oltean <vladimir.oltean at nxp.com>
>
>In the ENETC receive path, a frame received by the MAC is first stored
>in a 256KB 'FIFO' memory, then transferred to DRAM when enqueuing it to
>the RX ring. The FIFO is a shared resource for all ENETC ports, but
>every port keeps track of its own memory utilization, on RX and on TX.
>
>There is a setting for RX rings through which they can either operate in
>'lossy' mode (where the lack of a free buffer causes an immediate
>discard of the frame) or in 'lossless' mode (where the lack of a free
>buffer in the ring makes the frame stay longer in the FIFO).
>
>In turn, when the memory utilization of the FIFO exceeds a certain
>margin, the MAC can be configured to emit PAUSE frames.
>
>There is enough FIFO memory to buffer up to 3 MTU-sized frames per RX
>port while not jeopardizing the other use cases (jumbo frames), and
>also not consume bytes from the port TX allocations. Also, 3 MTU-sized
>frames worth of memory is enough to ensure zero loss for 64 byte packets
>at 1G line rate.
>
>Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>

Reviewed-by: Claudiu Manoil <claudiu.manoil at nxp.com>


From daniel.thompson at linaro.org  Mon Apr 19 10:07:50 2021
From: daniel.thompson at linaro.org (Daniel Thompson)
Date: Mon, 19 Apr 2021 10:07:50 +0100
Subject: [PATCH RESEND 3/4] docs: Add HiSilicon PTT device driver
 documentation
In-Reply-To: <1618654631-42454-4-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <1618654631-42454-4-git-send-email-yangyicong@hisilicon.com>
Message-ID: <20210419090750.g6aeyyrki7fiotxl@maple.lan>

On Sat, Apr 17, 2021 at 06:17:10PM +0800, Yicong Yang wrote:
> Document the introduction and usage of HiSilicon PTT device driver.
> 
> Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
> ---
>  Documentation/trace/hisi-ptt.rst | 326 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 326 insertions(+)
>  create mode 100644 Documentation/trace/hisi-ptt.rst
> 
> diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
> new file mode 100644
> index 0000000..f093846
> --- /dev/null
> +++ b/Documentation/trace/hisi-ptt.rst
> @@ -0,0 +1,326 @@
> [...]
> +On Kunpeng 930 SoC, the PCIe Root Complex is composed of several
> +PCIe cores. Each PCIe core includes several Root Ports and a PTT
> +RCiEP, like below. The PTT device is capable of tuning and
> +tracing the link of the PCIe core.
> +::
> +          +--------------Core 0-------+
> +          |       |       [   PTT   ] |
> +          |       |       [Root Port]---[Endpoint]
> +          |       |       [Root Port]---[Endpoint]
> +          |       |       [Root Port]---[Endpoint]
> +    Root Complex  |------Core 1-------+
> +          |       |       [   PTT   ] |
> +          |       |       [Root Port]---[ Switch ]---[Endpoint]
> +          |       |       [Root Port]---[Endpoint] `-[Endpoint]
> +          |       |       [Root Port]---[Endpoint]
> +          +---------------------------+
> +
> +The PTT device driver cannot be loaded if debugfs is not mounted.

This can't be right can it? Obviously debugfs must be enabled but why
mounted?


> +Each PTT device will be presented under /sys/kernel/debugfs/hisi_ptt
> +as its root directory, with name of its BDF number.
> +::
> +
> +    /sys/kernel/debug/hisi_ptt/<domain>:<bus>:<device>.<function>
> +
> +Tune
> +====
> +
> +PTT tune is designed for monitoring and adjusting PCIe link parameters (events).
> +Currently we support events in 4 classes. The scope of the events
> +covers the PCIe core to which the PTT device belongs.
> +
> +Each event is presented as a file under $(PTT root dir)/$(BDF)/tune, and
> +mostly a simple open/read/write/close cycle will be used to tune
> +the event.
> +::
> +    $ cd /sys/kernel/debug/hisi_ptt/$(BDF)/tune
> +    $ ls
> +    qos_tx_cpl    qos_tx_np    qos_tx_p
> +    tx_path_rx_req_alloc_buf_level
> +    tx_path_tx_req_alloc_buf_level
> +    $ cat qos_tx_dp
> +    1
> +    $ echo 2 > qos_tx_dp
> +    $ cat qos_tx_dp
> +    2
> +
> +Current value (numerical value) of the event can be simply read
> +from the file, and the desired value written to the file to tune.

I saw that this RFC asks about whether debugfs is an appropriate
interface for the *tracing* capability of the platform. Have similar
questions been raised about the tuning interfaces?

It looks to me like tuning could be handled entirely using sysfs
attributes. I think trying to handle these mostly decoupled feature
in the same place is likely to be a mistake.


Daniel.


From david at redhat.com  Mon Apr 19 10:15:02 2021
From: david at redhat.com (David Hildenbrand)
Date: Mon, 19 Apr 2021 11:15:02 +0200
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210419084218.7466-1-rppt@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
Message-ID: <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>

On 19.04.21 10:42, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
> due to commit "mm: introduce memfd_secret system call to create "secret"
> memory areas".
> 
> The perf profile of the test indicated that the regression is caused by
> page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
> 
>   27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
>    0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
>    0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
> 
> Further analysis showed that the slow down happens because neither
> page_is_secretmem() nor page_mapping() are not inline and moreover,
> multiple page flags checks in page_mapping() involve calling
> compound_head() several times for the same page.
> 
> Make page_is_secretmem() inline and replace page_mapping() with page flag
> checks that do not imply page-to-head conversion.
> 
> Reported-by: kernel test robot <oliver.sang at intel.com>
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
> 
> @Andrew,
> The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
> be added as a fixup to the memfd_secret series.
> 
>   include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
>   mm/secretmem.c            | 12 +-----------
>   2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
> index 907a6734059c..b842b38cbeb1 100644
> --- a/include/linux/secretmem.h
> +++ b/include/linux/secretmem.h
> @@ -4,8 +4,32 @@
>   
>   #ifdef CONFIG_SECRETMEM
>   
> +extern const struct address_space_operations secretmem_aops;
> +
> +static inline bool page_is_secretmem(struct page *page)
> +{
> +	struct address_space *mapping;
> +
> +	/*
> +	 * Using page_mapping() is quite slow because of the actual call
> +	 * instruction and repeated compound_head(page) inside the
> +	 * page_mapping() function.
> +	 * We know that secretmem pages are not compound and LRU so we can
> +	 * save a couple of cycles here.
> +	 */
> +	if (PageCompound(page) || !PageLRU(page))
> +		return false;

I'd assume secretmem pages are rare in basically every setup out there. 
So maybe throwing in a couple of likely()/unlikely() might make sense.

> +
> +	mapping = (struct address_space *)
> +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
> +

Not sure if open-coding page_mapping is really a good idea here -- or 
even necessary after the fast path above is in place. Anyhow, just my 2 
cents.

The idea of the patch makes sense to me.

-- 
Thanks,

David / dhildenb



From zhukeqian1 at huawei.com  Mon Apr 19 10:32:08 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Mon, 19 Apr 2021 17:32:08 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
Message-ID: <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>

Hi Baolu,

On 2021/4/14 15:14, Lu Baolu wrote:
> On 4/13/21 4:54 PM, Keqian Zhu wrote:
>> Block(largepage) mapping is not a proper granule for dirty log tracking.
>> Take an extreme example, if DMA writes one byte, under 1G mapping, the
>> dirty amount reported is 1G, but under 4K mapping, the dirty amount is
>> just 4K.
>>
>> This adds a new interface named iommu_split_block in IOMMU base layer.
>> A specific IOMMU driver can invoke it during start dirty log. If so, the
>> driver also need to realize the split_block iommu ops.
>>
>> We flush all iotlbs after the whole procedure is completed to ease the
>> pressure of IOMMU, as we will hanle a huge range of mapping in general.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> Signed-off-by: Kunkun Jiang <jiangkunkun at huawei.com>
>> ---
>>   drivers/iommu/iommu.c | 41 +++++++++++++++++++++++++++++++++++++++++
>>   include/linux/iommu.h | 11 +++++++++++
>>   2 files changed, 52 insertions(+)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 667b2d6d2fc0..bb413a927870 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -2721,6 +2721,47 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
>>   }
>>   EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
>>   +int iommu_split_block(struct iommu_domain *domain, unsigned long iova,
>> +              size_t size)
>> +{
>> +    const struct iommu_ops *ops = domain->ops;
>> +    unsigned int min_pagesz;
>> +    size_t pgsize;
>> +    bool flush = false;
>> +    int ret = 0;
>> +
>> +    if (unlikely(!ops || !ops->split_block))
>> +        return -ENODEV;
>> +
>> +    min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
>> +    if (!IS_ALIGNED(iova | size, min_pagesz)) {
>> +        pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz 0x%x\n",
>> +               iova, size, min_pagesz);
>> +        return -EINVAL;
>> +    }
>> +
>> +    while (size) {
>> +        flush = true;
>> +
>> +        pgsize = iommu_pgsize(domain, iova, size);
>> +
>> +        ret = ops->split_block(domain, iova, pgsize);
>> +        if (ret)
>> +            break;
>> +
>> +        pr_debug("split handled: iova 0x%lx size 0x%zx\n", iova, pgsize);
>> +
>> +        iova += pgsize;
>> +        size -= pgsize;
>> +    }
>> +
>> +    if (flush)
>> +        iommu_flush_iotlb_all(domain);
>> +
>> +    return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_split_block);
> 
> Do you really have any consumers of this interface other than the dirty
> bit tracking? If not, I don't suggest to make this as a generic IOMMU
> interface.
> 
> There is an implicit requirement for such interfaces. The
> iommu_map/unmap(iova, size) shouldn't be called at the same time.
> Currently there's no such sanity check in the iommu core. A poorly
> written driver could mess up the kernel by misusing this interface.

Yes, I don't think up a scenario except dirty tracking.

Indeed, we'd better not make them as a generic interface.

Do you have any suggestion that underlying iommu drivers can share these code but
not make it as a generic iommu interface?

I have a not so good idea. Make the "split" interfaces as a static function, and
transfer the function pointer to start_dirty_log. But it looks weird and inflexible.

On the other hand, if a driver calls map/unmap with split/merge at the same time,
it's a bug of driver, it should follow the rule.

> 
> This also applies to iommu_merge_page().
>

Thanks,
Keqian


From tzungbi at google.com  Mon Apr 19 10:34:49 2021
From: tzungbi at google.com (Tzung-Bi Shih)
Date: Mon, 19 Apr 2021 17:34:49 +0800
Subject: [PATCH v2] pinctrl: mediatek: use spin lock in mtk_rmw
Message-ID: <20210419093449.3125704-1-tzungbi@google.com>

Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
mutex lock in mtk_rmw.  However the function is possible called from
atomic context.

For example call trace:
  mutex_lock+0x28/0x64
  mtk_rmw+0x38/0x80
  [snip]
  max98357a_daiops_trigger+0x8c/0x9c
  soc_pcm_trigger+0x5c/0x10c

The max98357a_daiops_trigger() could run in either atomic or non-atomic
context.  As a result, dmesg shows some similar messages: "BUG: sleeping
function called from invalid context at kernel/locking/mutex.c:254".

Uses spin lock in mtk_rmw instead.

Fixes: 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.")
Signed-off-by: Tzung-Bi Shih <tzungbi at google.com>
---

Changes from v1[1]:
- Snip call trace.
- Use _irqsave and _irqrestore version of spin lock.

[1]: https://patchwork.ozlabs.org/project/linux-gpio/list/?series=239749

 drivers/pinctrl/mediatek/pinctrl-moore.c         | 2 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 5 +++--
 drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 2 +-
 drivers/pinctrl/mediatek/pinctrl-paris.c         | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c
index f77921957f15..3a4a23c40a71 100644
--- a/drivers/pinctrl/mediatek/pinctrl-moore.c
+++ b/drivers/pinctrl/mediatek/pinctrl-moore.c
@@ -619,7 +619,7 @@ int mtk_moore_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	/* Copy from internal struct mtk_pin_desc to register to the core */
 	pins = devm_kmalloc_array(&pdev->dev, hw->soc->npins, sizeof(*pins),
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index fcf7c3eeee4a..fc79b3a7a188 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -57,15 +57,16 @@ static u32 mtk_r32(struct mtk_pinctrl *pctl, u8 i, u32 reg)
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set)
 {
 	u32 val;
+	unsigned long flags;
 
-	mutex_lock(&pctl->lock);
+	spin_lock_irqsave(&pctl->lock, flags);
 
 	val = mtk_r32(pctl, i, reg);
 	val &= ~mask;
 	val |= set;
 	mtk_w32(pctl, i, reg, val);
 
-	mutex_unlock(&pctl->lock);
+	spin_unlock_irqrestore(&pctl->lock, flags);
 }
 
 static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 65eac708a3b3..13836bb188b7 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -252,7 +252,7 @@ struct mtk_pinctrl {
 	struct mtk_pinctrl_group	*groups;
 	const char          **grp_names;
 	/* lock pin's register resource to avoid multiple threads issue*/
-	struct mutex lock;
+	spinlock_t lock;
 };
 
 void mtk_rmw(struct mtk_pinctrl *pctl, u8 i, u32 reg, u32 mask, u32 set);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 48e823f6d293..85db2e4377f0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -970,7 +970,7 @@ int mtk_paris_pinctrl_probe(struct platform_device *pdev,
 
 	hw->nbase = hw->soc->nbase_names;
 
-	mutex_init(&hw->lock);
+	spin_lock_init(&hw->lock);
 
 	err = mtk_pctrl_build_state(pdev);
 	if (err) {
-- 
2.31.1.368.gbe11c130af-goog



From rppt at kernel.org  Mon Apr 19 10:36:19 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 19 Apr 2021 12:36:19 +0300
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
Message-ID: <YH1PE4oWeicpJT9g@kernel.org>

On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> On 19.04.21 10:42, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
> > due to commit "mm: introduce memfd_secret system call to create "secret"
> > memory areas".
> > 
> > The perf profile of the test indicated that the regression is caused by
> > page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
> > 
> >   27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
> >    0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
> >    0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
> > 
> > Further analysis showed that the slow down happens because neither
> > page_is_secretmem() nor page_mapping() are not inline and moreover,
> > multiple page flags checks in page_mapping() involve calling
> > compound_head() several times for the same page.
> > 
> > Make page_is_secretmem() inline and replace page_mapping() with page flag
> > checks that do not imply page-to-head conversion.
> > 
> > Reported-by: kernel test robot <oliver.sang at intel.com>
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> > 
> > @Andrew,
> > The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
> > be added as a fixup to the memfd_secret series.
> > 
> >   include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
> >   mm/secretmem.c            | 12 +-----------
> >   2 files changed, 26 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
> > index 907a6734059c..b842b38cbeb1 100644
> > --- a/include/linux/secretmem.h
> > +++ b/include/linux/secretmem.h
> > @@ -4,8 +4,32 @@
> >   #ifdef CONFIG_SECRETMEM
> > +extern const struct address_space_operations secretmem_aops;
> > +
> > +static inline bool page_is_secretmem(struct page *page)
> > +{
> > +	struct address_space *mapping;
> > +
> > +	/*
> > +	 * Using page_mapping() is quite slow because of the actual call
> > +	 * instruction and repeated compound_head(page) inside the
> > +	 * page_mapping() function.
> > +	 * We know that secretmem pages are not compound and LRU so we can
> > +	 * save a couple of cycles here.
> > +	 */
> > +	if (PageCompound(page) || !PageLRU(page))
> > +		return false;
> 
> I'd assume secretmem pages are rare in basically every setup out there. So
> maybe throwing in a couple of likely()/unlikely() might make sense.

I'd say we could do unlikely(page_is_secretmem()) at call sites. Here I can
hardly estimate which pages are going to be checked.
 
> > +
> > +	mapping = (struct address_space *)
> > +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
> > +
> 
> Not sure if open-coding page_mapping is really a good idea here -- or even
> necessary after the fast path above is in place. Anyhow, just my 2 cents.

Well, most if the -4.2% of the performance regression kbuild reported were
due to repeated compount_head(page) in page_mapping(). So the whole point
of this patch is to avoid calling page_mapping().

> The idea of the patch makes sense to me.

-- 
Sincerely yours,
Mike.


From tzungbi at google.com  Mon Apr 19 10:36:42 2021
From: tzungbi at google.com (Tzung-Bi Shih)
Date: Mon, 19 Apr 2021 17:36:42 +0800
Subject: [RESEND PATCH] pinctrl: mediatek: use spin lock in mtk_rmw
In-Reply-To: <CAHp75VfgSaRmqg96KSabmwnf6xQRMM6GQi3XAv-cJb+Lhg91cQ@mail.gmail.com>
References: <20210419052136.2475373-1-tzungbi@google.com>
 <CAHp75VfgSaRmqg96KSabmwnf6xQRMM6GQi3XAv-cJb+Lhg91cQ@mail.gmail.com>
Message-ID: <CA+Px+wUvrNT1p-pLDKd=2RyzBOiy_AuBfnyyapmbRuZWDdOErg@mail.gmail.com>

On Mon, Apr 19, 2021 at 4:31 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Mon, Apr 19, 2021 at 8:32 AM Tzung-Bi Shih <tzungbi at google.com> wrote:
> > For example call trace:
>
> Please, shrink it to the necessary minimum.

I'll snip the stack a bit in the next version.

> > Uses spin lock in mtk_rmw instead.
>
> It's nice, but now the question is, can you have this function be
> called in a non-IRQ context concurrently with IRQ accessing registers?

Fixed in v2.  See
https://patchwork.ozlabs.org/project/linux-gpio/list/?series=239787 .


From david at redhat.com  Mon Apr 19 10:38:40 2021
From: david at redhat.com (David Hildenbrand)
Date: Mon, 19 Apr 2021 11:38:40 +0200
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <YH1PE4oWeicpJT9g@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
 <YH1PE4oWeicpJT9g@kernel.org>
Message-ID: <f4d0c4bf-423b-e227-444b-f1ea722dc43f@redhat.com>

On 19.04.21 11:36, Mike Rapoport wrote:
> On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
>> On 19.04.21 10:42, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
>>> due to commit "mm: introduce memfd_secret system call to create "secret"
>>> memory areas".
>>>
>>> The perf profile of the test indicated that the regression is caused by
>>> page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
>>>
>>>    27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
>>>     0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
>>>     0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
>>>
>>> Further analysis showed that the slow down happens because neither
>>> page_is_secretmem() nor page_mapping() are not inline and moreover,
>>> multiple page flags checks in page_mapping() involve calling
>>> compound_head() several times for the same page.
>>>
>>> Make page_is_secretmem() inline and replace page_mapping() with page flag
>>> checks that do not imply page-to-head conversion.
>>>
>>> Reported-by: kernel test robot <oliver.sang at intel.com>
>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>> ---
>>>
>>> @Andrew,
>>> The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
>>> be added as a fixup to the memfd_secret series.
>>>
>>>    include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
>>>    mm/secretmem.c            | 12 +-----------
>>>    2 files changed, 26 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
>>> index 907a6734059c..b842b38cbeb1 100644
>>> --- a/include/linux/secretmem.h
>>> +++ b/include/linux/secretmem.h
>>> @@ -4,8 +4,32 @@
>>>    #ifdef CONFIG_SECRETMEM
>>> +extern const struct address_space_operations secretmem_aops;
>>> +
>>> +static inline bool page_is_secretmem(struct page *page)
>>> +{
>>> +	struct address_space *mapping;
>>> +
>>> +	/*
>>> +	 * Using page_mapping() is quite slow because of the actual call
>>> +	 * instruction and repeated compound_head(page) inside the
>>> +	 * page_mapping() function.
>>> +	 * We know that secretmem pages are not compound and LRU so we can
>>> +	 * save a couple of cycles here.
>>> +	 */
>>> +	if (PageCompound(page) || !PageLRU(page))
>>> +		return false;
>>
>> I'd assume secretmem pages are rare in basically every setup out there. So
>> maybe throwing in a couple of likely()/unlikely() might make sense.
> 
> I'd say we could do unlikely(page_is_secretmem()) at call sites. Here I can
> hardly estimate which pages are going to be checked.
>   
>>> +
>>> +	mapping = (struct address_space *)
>>> +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
>>> +
>>
>> Not sure if open-coding page_mapping is really a good idea here -- or even
>> necessary after the fast path above is in place. Anyhow, just my 2 cents.
> 
> Well, most if the -4.2% of the performance regression kbuild reported were
> due to repeated compount_head(page) in page_mapping(). So the whole point
> of this patch is to avoid calling page_mapping().

I would have thought the fast path "(PageCompound(page) || 
!PageLRU(page))" would already avoid calling page_mapping() in many cases.


-- 
Thanks,

David / dhildenb



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:41 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:41 +0200
Subject: [PATCH v3 00/11] Introduce STM32MP1 RCC in secured mode
Message-ID: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Platform STM32MP1 can be used in configuration where some clocks and
IP resets can relate as secure resources.
These resources are moved from a RCC clock/reset handle to a SCMI
clock/reset_domain handle.

The RCC clock driver is now dependent of the SCMI driver, then we have
to manage now the probe defering.

v2 -> v3:
  - use determine_rate op instead of round_rate for ck_rtc
  - remove DT patches from patchset to keek Kernel device tree as there are in basic boot.
     We will applied scmi clock phandle thanks dtbo in U-boot.
v1 -> v2:
  - fix yamllint warnings.

Gabriel Fernandez (11):
  clk: stm32mp1: merge 'clk-hsi-div' and 'ck_hsi' into one clock
  clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock
  clk: stm32mp1: remove intermediate pll clocks
  clk: stm32mp1: convert to module driver
  clk: stm32mp1: move RCC reset controller into RCC clock driver
  reset: stm32mp1: remove stm32mp1 reset
  dt-bindings: clock: add IDs for SCMI clocks on stm32mp15
  dt-bindings: reset: add IDs for SCMI reset domains on stm32mp15
  dt-bindings: reset: add MCU HOLD BOOT ID for SCMI reset domains on
    stm32mp15
  dt-bindings: clock: stm32mp1 new compatible for secure rcc
  clk: stm32mp1: new compatible for secure RCC support

 .../bindings/clock/st,stm32mp1-rcc.yaml       |   6 +-
 drivers/clk/Kconfig                           |  10 +
 drivers/clk/clk-stm32mp1.c                    | 500 +++++++++++++++---
 drivers/reset/Kconfig                         |   6 -
 drivers/reset/Makefile                        |   1 -
 drivers/reset/reset-stm32mp1.c                | 115 ----
 include/dt-bindings/clock/stm32mp1-clks.h     |  27 +
 include/dt-bindings/reset/stm32mp1-resets.h   |  15 +
 8 files changed, 469 insertions(+), 211 deletions(-)
 delete mode 100644 drivers/reset/reset-stm32mp1.c

-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:44 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:44 +0200
Subject: [PATCH v3 03/11] clk: stm32mp1: remove intermediate pll clocks
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-4-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This patch is to prepare STM32MP1 clocks in trusted mode.
Integrate the mux clock into pll clock will facilitate to have a more
coherent clock tree in no trusted / trusted mode.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/clk-stm32mp1.c | 65 ++++++++++++++++++++++++--------------
 1 file changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index a7c244fd0b03..24d99da07fc8 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -731,6 +731,7 @@ struct stm32_pll_obj {
 	spinlock_t *lock;
 	void __iomem *reg;
 	struct clk_hw hw;
+	struct clk_mux mux;
 };
 
 #define to_pll(_hw) container_of(_hw, struct stm32_pll_obj, hw)
@@ -745,6 +746,8 @@ struct stm32_pll_obj {
 #define FRAC_MASK	0x1FFF
 #define FRAC_SHIFT	3
 #define FRACLE		BIT(16)
+#define PLL_MUX_SHIFT	0
+#define PLL_MUX_MASK	3
 
 static int __pll_is_enabled(struct clk_hw *hw)
 {
@@ -856,16 +859,29 @@ static int pll_is_enabled(struct clk_hw *hw)
 	return ret;
 }
 
+static u8 pll_get_parent(struct clk_hw *hw)
+{
+	struct stm32_pll_obj *clk_elem = to_pll(hw);
+	struct clk_hw *mux_hw = &clk_elem->mux.hw;
+
+	__clk_hw_set_clk(mux_hw, hw);
+
+	return clk_mux_ops.get_parent(mux_hw);
+}
+
 static const struct clk_ops pll_ops = {
 	.enable		= pll_enable,
 	.disable	= pll_disable,
 	.recalc_rate	= pll_recalc_rate,
 	.is_enabled	= pll_is_enabled,
+	.get_parent	= pll_get_parent,
 };
 
 static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
-				       const char *parent_name,
+				       const char * const *parent_names,
+				       int num_parents,
 				       void __iomem *reg,
+				       void __iomem *mux_reg,
 				       unsigned long flags,
 				       spinlock_t *lock)
 {
@@ -881,8 +897,15 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	init.name = name;
 	init.ops = &pll_ops;
 	init.flags = flags;
-	init.parent_names = &parent_name;
-	init.num_parents = 1;
+	init.parent_names = parent_names;
+	init.num_parents = num_parents;
+
+	element->mux.lock = lock;
+	element->mux.reg =  mux_reg;
+	element->mux.shift = PLL_MUX_SHIFT;
+	element->mux.mask =  PLL_MUX_MASK;
+	element->mux.flags =  CLK_MUX_READ_ONLY;
+	element->mux.reg =  mux_reg;
 
 	element->hw.init = &init;
 	element->reg = reg;
@@ -1074,6 +1097,7 @@ static const struct clk_ops rtc_div_clk_ops = {
 
 struct stm32_pll_cfg {
 	u32 offset;
+	u32 muxoff;
 };
 
 static struct clk_hw *_clk_register_pll(struct device *dev,
@@ -1083,8 +1107,11 @@ static struct clk_hw *_clk_register_pll(struct device *dev,
 {
 	struct stm32_pll_cfg *stm_pll_cfg = cfg->cfg;
 
-	return clk_register_pll(dev, cfg->name, cfg->parent_name,
-				base + stm_pll_cfg->offset, cfg->flags, lock);
+	return clk_register_pll(dev, cfg->name, cfg->parent_names,
+				cfg->num_parents,
+				base + stm_pll_cfg->offset,
+				base + stm_pll_cfg->muxoff,
+				cfg->flags, lock);
 }
 
 struct stm32_cktim_cfg {
@@ -1194,14 +1221,16 @@ _clk_stm32_register_composite(struct device *dev,
 	.func		= _clk_hw_register_mux,\
 }
 
-#define PLL(_id, _name, _parent, _flags, _offset)\
+#define PLL(_id, _name, _parents, _flags, _offset_p, _offset_mux)\
 {\
 	.id		= _id,\
 	.name		= _name,\
-	.parent_name	= _parent,\
-	.flags		= _flags,\
+	.parent_names	= _parents,\
+	.num_parents	= ARRAY_SIZE(_parents),\
+	.flags		= CLK_IGNORE_UNUSED | (_flags),\
 	.cfg		=  &(struct stm32_pll_cfg) {\
-		.offset = _offset,\
+		.offset = _offset_p,\
+		.muxoff = _offset_mux,\
 	},\
 	.func		= _clk_register_pll,\
 }
@@ -1717,21 +1746,11 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 
 	FIXED_FACTOR(CK_HSE_DIV2, "clk-hse-div2", "ck_hse", 0, 1, 2),
 
-	/* ref clock pll */
-	MUX(NO_ID, "ref1", ref12_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK12SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
-	MUX(NO_ID, "ref3", ref3_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK3SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
-	MUX(NO_ID, "ref4", ref4_parents, CLK_OPS_PARENT_ENABLE, RCC_RCK4SELR,
-	    0, 2, CLK_MUX_READ_ONLY),
-
 	/* PLLs */
-	PLL(PLL1, "pll1", "ref1", CLK_IGNORE_UNUSED, RCC_PLL1CR),
-	PLL(PLL2, "pll2", "ref1", CLK_IGNORE_UNUSED, RCC_PLL2CR),
-	PLL(PLL3, "pll3", "ref3", CLK_IGNORE_UNUSED, RCC_PLL3CR),
-	PLL(PLL4, "pll4", "ref4", CLK_IGNORE_UNUSED, RCC_PLL4CR),
+	PLL(PLL1, "pll1", ref12_parents, 0, RCC_PLL1CR, RCC_RCK12SELR),
+	PLL(PLL2, "pll2", ref12_parents, 0, RCC_PLL2CR, RCC_RCK12SELR),
+	PLL(PLL3, "pll3", ref3_parents, 0, RCC_PLL3CR, RCC_RCK3SELR),
+	PLL(PLL4, "pll4", ref4_parents, 0, RCC_PLL4CR, RCC_RCK4SELR),
 
 	/* ODF */
 	COMPOSITE(PLL1_P, "pll1_p", PARENT("pll1"), 0,
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:47 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:47 +0200
Subject: [PATCH v3 06/11] reset: stm32mp1: remove stm32mp1 reset
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-7-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

st32mp1 RCC reset driver was moved into stm32mp1 RCC clock driver.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/reset/Kconfig          |   6 --
 drivers/reset/Makefile         |   1 -
 drivers/reset/reset-stm32mp1.c | 115 ---------------------------------
 3 files changed, 122 deletions(-)
 delete mode 100644 drivers/reset/reset-stm32mp1.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 4171c6f76385..8c26f7af70a4 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -198,12 +198,6 @@ config RESET_SIMPLE
 	   - Allwinner SoCs
 	   - ZTE's zx2967 family
 
-config RESET_STM32MP157
-	bool "STM32MP157 Reset Driver" if COMPILE_TEST
-	default MACH_STM32MP157
-	help
-	  This enables the RCC reset controller driver for STM32 MPUs.
-
 config RESET_SOCFPGA
 	bool "SoCFPGA Reset Driver" if COMPILE_TEST && !ARCH_SOCFPGA
 	default ARCH_SOCFPGA
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 65a118a91b27..ac3e612ad953 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -26,7 +26,6 @@ obj-$(CONFIG_RESET_QCOM_PDC) += reset-qcom-pdc.o
 obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
 obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
 obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
-obj-$(CONFIG_RESET_STM32MP157) += reset-stm32mp1.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
diff --git a/drivers/reset/reset-stm32mp1.c b/drivers/reset/reset-stm32mp1.c
deleted file mode 100644
index b221a28041fa..000000000000
--- a/drivers/reset/reset-stm32mp1.c
+++ /dev/null
@@ -1,115 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
- * Author: Gabriel Fernandez <gabriel.fernandez at st.com> for STMicroelectronics.
- */
-
-#include <linux/device.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/of.h>
-#include <linux/platform_device.h>
-#include <linux/reset-controller.h>
-
-#define CLR_OFFSET 0x4
-
-struct stm32_reset_data {
-	struct reset_controller_dev	rcdev;
-	void __iomem			*membase;
-};
-
-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);
-	void __iomem *addr;
-
-	addr = data->membase + (bank * reg_width);
-	if (!assert)
-		addr += CLR_OFFSET;
-
-	writel(BIT(offset), addr);
-
-	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 const struct of_device_id stm32_reset_dt_ids[] = {
-	{ .compatible = "st,stm32mp1-rcc"},
-	{ /* sentinel */ },
-};
-
-static int stm32_reset_probe(struct platform_device *pdev)
-{
-	struct device *dev = &pdev->dev;
-	struct stm32_reset_data *data;
-	void __iomem *membase;
-	struct resource *res;
-
-	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
-	if (!data)
-		return -ENOMEM;
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	membase = devm_ioremap_resource(dev, res);
-	if (IS_ERR(membase))
-		return PTR_ERR(membase);
-
-	data->membase = membase;
-	data->rcdev.owner = THIS_MODULE;
-	data->rcdev.nr_resets = resource_size(res) * BITS_PER_BYTE;
-	data->rcdev.ops = &stm32_reset_ops;
-	data->rcdev.of_node = dev->of_node;
-
-	return devm_reset_controller_register(dev, &data->rcdev);
-}
-
-static struct platform_driver stm32_reset_driver = {
-	.probe	= stm32_reset_probe,
-	.driver = {
-		.name		= "stm32mp1-reset",
-		.of_match_table	= stm32_reset_dt_ids,
-	},
-};
-
-builtin_platform_driver(stm32_reset_driver);
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:48 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:48 +0200
Subject: [PATCH v3 07/11] dt-bindings: clock: add IDs for SCMI clocks on
 stm32mp15
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-8-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces.
This change defines the SCMI clock identifiers used by SCMI agents
and servers.
Server SCMI0 exposes clocks and reset controllers for resources under
RCC[TZEN] configuration control.
Server SCMI1 exposes clocks for resources under RCC[MCKPROT] control.

Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/clock/stm32mp1-clks.h | 27 +++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/include/dt-bindings/clock/stm32mp1-clks.h b/include/dt-bindings/clock/stm32mp1-clks.h
index 4cdaf135829c..e02770b98e6c 100644
--- a/include/dt-bindings/clock/stm32mp1-clks.h
+++ b/include/dt-bindings/clock/stm32mp1-clks.h
@@ -248,4 +248,31 @@
 
 #define STM32MP1_LAST_CLK 232
 
+/* SCMI clock identifiers */
+#define CK_SCMI0_HSE		0
+#define CK_SCMI0_HSI		1
+#define CK_SCMI0_CSI		2
+#define CK_SCMI0_LSE		3
+#define CK_SCMI0_LSI		4
+#define CK_SCMI0_PLL2_Q		5
+#define CK_SCMI0_PLL2_R		6
+#define CK_SCMI0_MPU		7
+#define CK_SCMI0_AXI		8
+#define CK_SCMI0_BSEC		9
+#define CK_SCMI0_CRYP1		10
+#define CK_SCMI0_GPIOZ		11
+#define CK_SCMI0_HASH1		12
+#define CK_SCMI0_I2C4		13
+#define CK_SCMI0_I2C6		14
+#define CK_SCMI0_IWDG1		15
+#define CK_SCMI0_RNG1		16
+#define CK_SCMI0_RTC		17
+#define CK_SCMI0_RTCAPB		18
+#define CK_SCMI0_SPI6		19
+#define CK_SCMI0_USART1		20
+
+#define CK_SCMI1_PLL3_Q		0
+#define CK_SCMI1_PLL3_R		1
+#define CK_SCMI1_MCU		2
+
 #endif /* _DT_BINDINGS_STM32MP1_CLKS_H_ */
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:45 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:45 +0200
Subject: [PATCH v3 04/11] clk: stm32mp1: convert to module driver
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-5-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Adds support for  probe deferral in way to prepare
integration of the security in RCC clock and reset
drivers.
Some kernel clocks will be provided by the SCMI drivers.
Since RCC clock driver create clocks which parents
are SCMI clocks, RCC clock driver probe can be deferred.

Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/clk-stm32mp1.c | 121 ++++++++++++++++++++++++-------------
 1 file changed, 78 insertions(+), 43 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 24d99da07fc8..e2e9331f1cba 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -10,8 +10,10 @@
 #include <linux/delay.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>
 
@@ -469,7 +471,7 @@ static const struct clk_ops mp1_gate_clk_ops = {
 	.is_enabled	= clk_gate_is_enabled,
 };
 
-static struct clk_hw *_get_stm32_mux(void __iomem *base,
+static struct clk_hw *_get_stm32_mux(struct device *dev, void __iomem *base,
 				     const struct stm32_mux_cfg *cfg,
 				     spinlock_t *lock)
 {
@@ -478,7 +480,7 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 	struct clk_hw *mux_hw;
 
 	if (cfg->mmux) {
-		mmux = kzalloc(sizeof(*mmux), GFP_KERNEL);
+		mmux = devm_kzalloc(dev, sizeof(*mmux), GFP_KERNEL);
 		if (!mmux)
 			return ERR_PTR(-ENOMEM);
 
@@ -493,7 +495,7 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 		cfg->mmux->hws[cfg->mmux->nbr_clk++] = mux_hw;
 
 	} else {
-		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+		mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
 		if (!mux)
 			return ERR_PTR(-ENOMEM);
 
@@ -509,13 +511,13 @@ static struct clk_hw *_get_stm32_mux(void __iomem *base,
 	return mux_hw;
 }
 
-static struct clk_hw *_get_stm32_div(void __iomem *base,
+static struct clk_hw *_get_stm32_div(struct device *dev, void __iomem *base,
 				     const struct stm32_div_cfg *cfg,
 				     spinlock_t *lock)
 {
 	struct clk_divider *div;
 
-	div = kzalloc(sizeof(*div), GFP_KERNEL);
+	div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
 
 	if (!div)
 		return ERR_PTR(-ENOMEM);
@@ -530,16 +532,16 @@ static struct clk_hw *_get_stm32_div(void __iomem *base,
 	return &div->hw;
 }
 
-static struct clk_hw *
-_get_stm32_gate(void __iomem *base,
-		const struct stm32_gate_cfg *cfg, spinlock_t *lock)
+static struct clk_hw *_get_stm32_gate(struct device *dev, void __iomem *base,
+				      const struct stm32_gate_cfg *cfg,
+				      spinlock_t *lock)
 {
 	struct stm32_clk_mgate *mgate;
 	struct clk_gate *gate;
 	struct clk_hw *gate_hw;
 
 	if (cfg->mgate) {
-		mgate = kzalloc(sizeof(*mgate), GFP_KERNEL);
+		mgate = devm_kzalloc(dev, sizeof(*mgate), GFP_KERNEL);
 		if (!mgate)
 			return ERR_PTR(-ENOMEM);
 
@@ -554,7 +556,7 @@ _get_stm32_gate(void __iomem *base,
 		gate_hw = &mgate->gate.hw;
 
 	} else {
-		gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+		gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
 		if (!gate)
 			return ERR_PTR(-ENOMEM);
 
@@ -592,7 +594,7 @@ clk_stm32_register_gate_ops(struct device *dev,
 	if (cfg->ops)
 		init.ops = cfg->ops;
 
-	hw = _get_stm32_gate(base, cfg, lock);
+	hw = _get_stm32_gate(dev, base, cfg, lock);
 	if (IS_ERR(hw))
 		return ERR_PTR(-ENOMEM);
 
@@ -623,7 +625,7 @@ clk_stm32_register_composite(struct device *dev,
 	gate_ops = NULL;
 
 	if (cfg->mux) {
-		mux_hw = _get_stm32_mux(base, cfg->mux, lock);
+		mux_hw = _get_stm32_mux(dev, base, cfg->mux, lock);
 
 		if (!IS_ERR(mux_hw)) {
 			mux_ops = &clk_mux_ops;
@@ -634,7 +636,7 @@ clk_stm32_register_composite(struct device *dev,
 	}
 
 	if (cfg->div) {
-		div_hw = _get_stm32_div(base, cfg->div, lock);
+		div_hw = _get_stm32_div(dev, base, cfg->div, lock);
 
 		if (!IS_ERR(div_hw)) {
 			div_ops = &clk_divider_ops;
@@ -645,7 +647,7 @@ clk_stm32_register_composite(struct device *dev,
 	}
 
 	if (cfg->gate) {
-		gate_hw = _get_stm32_gate(base, cfg->gate, lock);
+		gate_hw = _get_stm32_gate(dev, base, cfg->gate, lock);
 
 		if (!IS_ERR(gate_hw)) {
 			gate_ops = &clk_gate_ops;
@@ -890,7 +892,7 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	struct clk_hw *hw;
 	int err;
 
-	element = kzalloc(sizeof(*element), GFP_KERNEL);
+	element = devm_kzalloc(dev, sizeof(*element), GFP_KERNEL);
 	if (!element)
 		return ERR_PTR(-ENOMEM);
 
@@ -914,10 +916,8 @@ static struct clk_hw *clk_register_pll(struct device *dev, const char *name,
 	hw = &element->hw;
 	err = clk_hw_register(dev, hw);
 
-	if (err) {
-		kfree(element);
+	if (err)
 		return ERR_PTR(err);
-	}
 
 	return hw;
 }
@@ -1028,7 +1028,7 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	struct clk_hw *hw;
 	int err;
 
-	tim_ker = kzalloc(sizeof(*tim_ker), GFP_KERNEL);
+	tim_ker = devm_kzalloc(dev, sizeof(*tim_ker), GFP_KERNEL);
 	if (!tim_ker)
 		return ERR_PTR(-ENOMEM);
 
@@ -1046,10 +1046,8 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	hw = &tim_ker->hw;
 	err = clk_hw_register(dev, hw);
 
-	if (err) {
-		kfree(tim_ker);
+	if (err)
 		return ERR_PTR(err);
-	}
 
 	return hw;
 }
@@ -2076,6 +2074,7 @@ static const struct of_device_id stm32mp1_match_data[] = {
 	},
 	{ }
 };
+MODULE_DEVICE_TABLE(of, stm32mp1_match_data);
 
 static int stm32_register_hw_clk(struct device *dev,
 				 struct clk_hw_onecell_data *clk_data,
@@ -2101,8 +2100,7 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-static int stm32_rcc_init(struct device_node *np,
-			  void __iomem *base,
+static int stm32_rcc_init(struct device *dev, void __iomem *base,
 			  const struct of_device_id *match_data)
 {
 	struct clk_hw_onecell_data *clk_data;
@@ -2111,9 +2109,9 @@ static int stm32_rcc_init(struct device_node *np,
 	const struct stm32_clock_match_data *data;
 	int err, n, max_binding;
 
-	match = of_match_node(match_data, np);
+	match = of_match_node(match_data, dev_of_node(dev));
 	if (!match) {
-		pr_err("%s: match data not found\n", __func__);
+		dev_err(dev, "match data not found\n");
 		return -ENODEV;
 	}
 
@@ -2121,8 +2119,8 @@ static int stm32_rcc_init(struct device_node *np,
 
 	max_binding =  data->maxbinding;
 
-	clk_data = kzalloc(struct_size(clk_data, hws, max_binding),
-			   GFP_KERNEL);
+	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, max_binding),
+				GFP_KERNEL);
 	if (!clk_data)
 		return -ENOMEM;
 
@@ -2134,36 +2132,73 @@ static int stm32_rcc_init(struct device_node *np,
 		hws[n] = ERR_PTR(-ENOENT);
 
 	for (n = 0; n < data->num; n++) {
-		err = stm32_register_hw_clk(NULL, clk_data, base, &rlock,
+		err = stm32_register_hw_clk(dev, clk_data, base, &rlock,
 					    &data->cfg[n]);
 		if (err) {
-			pr_err("%s: can't register  %s\n", __func__,
-			       data->cfg[n].name);
-
-			kfree(clk_data);
+			dev_err(dev, "Can't register clk %s: %d\n",
+				data->cfg[n].name, err);
 
 			return err;
 		}
 	}
 
-	return of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
+	return of_clk_add_hw_provider(dev_of_node(dev), of_clk_hw_onecell_get, clk_data);
 }
 
-static void stm32mp1_rcc_init(struct device_node *np)
+static int stm32mp1_rcc_init(struct device *dev)
 {
 	void __iomem *base;
+	int ret;
 
-	base = of_iomap(np, 0);
+	base = of_iomap(dev_of_node(dev), 0);
 	if (!base) {
-		pr_err("%pOFn: unable to map resource", np);
-		of_node_put(np);
-		return;
+		pr_err("%pOFn: unable to map resource", dev_of_node(dev));
+		ret = -ENOMEM;
+		goto out;
 	}
 
-	if (stm32_rcc_init(np, base, stm32mp1_match_data)) {
-		iounmap(base);
-		of_node_put(np);
+	ret = stm32_rcc_init(dev, base, stm32mp1_match_data);
+
+out:
+	if (ret) {
+		if (base)
+			iounmap(base);
+
+		of_node_put(dev_of_node(dev));
 	}
+
+	return ret;
+}
+
+static int stm32mp1_rcc_clocks_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+
+	return stm32mp1_rcc_init(dev);
+}
+
+static int stm32mp1_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;
 }
 
-CLK_OF_DECLARE_DRIVER(stm32mp1_rcc, "st,stm32mp1-rcc", stm32mp1_rcc_init);
+static struct platform_driver stm32mp1_rcc_clocks_driver = {
+	.driver	= {
+		.name = "stm32mp1_rcc",
+		.of_match_table = stm32mp1_match_data,
+	},
+	.probe = stm32mp1_rcc_clocks_probe,
+	.remove = stm32mp1_rcc_clocks_remove,
+};
+
+static int __init stm32mp1_clocks_init(void)
+{
+	return platform_driver_register(&stm32mp1_rcc_clocks_driver);
+}
+core_initcall(stm32mp1_clocks_init);
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:42 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:42 +0200
Subject: [PATCH v3 01/11] clk: stm32mp1: merge 'clk-hsi-div' and 'ck_hsi' into
 one clock
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-2-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

This patch is to prepare STM32MP1 clocks in trusted mode.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/clk-stm32mp1.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index a875649df8b8..35d5aee8f9b0 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -1657,16 +1657,16 @@ static const struct stm32_mux_cfg ker_mux_cfg[M_LAST] = {
 };
 
 static const struct clock_config stm32mp1_clock_cfg[] = {
-	/* Oscillator divider */
-	DIV(NO_ID, "clk-hsi-div", "clk-hsi", CLK_DIVIDER_POWER_OF_TWO,
-	    RCC_HSICFGR, 0, 2, CLK_DIVIDER_READ_ONLY),
-
 	/*  External / Internal Oscillators */
 	GATE_MP1(CK_HSE, "ck_hse", "clk-hse", 0, RCC_OCENSETR, 8, 0),
 	/* ck_csi is used by IO compensation and should be critical */
 	GATE_MP1(CK_CSI, "ck_csi", "clk-csi", CLK_IS_CRITICAL,
 		 RCC_OCENSETR, 4, 0),
-	GATE_MP1(CK_HSI, "ck_hsi", "clk-hsi-div", 0, RCC_OCENSETR, 0, 0),
+	COMPOSITE(CK_HSI, "ck_hsi", PARENT("clk-hsi"), 0,
+		  _GATE_MP1(RCC_OCENSETR, 0, 0),
+		  _NO_MUX,
+		  _DIV(RCC_HSICFGR, 0, 2, CLK_DIVIDER_POWER_OF_TWO |
+		       CLK_DIVIDER_READ_ONLY, NULL)),
 	GATE(CK_LSI, "ck_lsi", "clk-lsi", 0, RCC_RDLSICR, 0, 0),
 	GATE(CK_LSE, "ck_lse", "clk-lse", 0, RCC_BDCR, 0, 0),
 
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:43 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:43 +0200
Subject: [PATCH v3 02/11] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into
 one clock
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-3-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
A divider is available only on the specific rtc input for ck_hse.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/clk-stm32mp1.c | 54 +++++++++++++++++++++++++++++++++-----
 1 file changed, 48 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 35d5aee8f9b0..a7c244fd0b03 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
 };
 
 static const char * const rtc_src[] = {
-	"off", "ck_lse", "ck_lsi", "ck_hse_rtc"
+	"off", "ck_lse", "ck_lsi", "ck_hse"
 };
 
 static const char * const mco1_src[] = {
@@ -1031,6 +1031,47 @@ static struct clk_hw *clk_register_cktim(struct device *dev, const char *name,
 	return hw;
 }
 
+/* The divider of RTC clock concerns only ck_hse clock */
+#define HSE_RTC 3
+
+static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
+						 unsigned long parent_rate)
+{
+	if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+		return clk_divider_ops.recalc_rate(hw, parent_rate);
+
+	return parent_rate;
+}
+
+static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
+				    unsigned long parent_rate)
+{
+	if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+		return clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+	return parent_rate;
+}
+
+static int clk_divider_rtc_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+	unsigned long best_parent_rate = req->best_parent_rate;
+
+	if (req->best_parent_hw == clk_hw_get_parent_by_index(hw, HSE_RTC)) {
+		req->rate = clk_divider_ops.round_rate(hw, req->rate, &best_parent_rate);
+		req->best_parent_rate = best_parent_rate;
+	} else {
+		req->rate = best_parent_rate;
+	}
+
+	return 0;
+}
+
+static const struct clk_ops rtc_div_clk_ops = {
+	.recalc_rate	= clk_divider_rtc_recalc_rate,
+	.set_rate	= clk_divider_rtc_set_rate,
+	.determine_rate = clk_divider_rtc_determine_rate
+};
+
 struct stm32_pll_cfg {
 	u32 offset;
 };
@@ -1243,6 +1284,10 @@ _clk_stm32_register_composite(struct device *dev,
 	_STM32_DIV(_div_offset, _div_shift, _div_width,\
 		   _div_flags, _div_table, NULL)\
 
+#define _DIV_RTC(_div_offset, _div_shift, _div_width, _div_flags, _div_table)\
+	_STM32_DIV(_div_offset, _div_shift, _div_width,\
+		   _div_flags, _div_table, &rtc_div_clk_ops)
+
 #define _STM32_MUX(_offset, _shift, _width, _mux_flags, _mmux, _ops)\
 	.mux = &(struct stm32_mux_cfg) {\
 		&(struct mux_cfg) {\
@@ -1965,13 +2010,10 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_ETHCKSELR, 4, 4, 0, NULL)),
 
 	/* RTC clock */
-	DIV(NO_ID, "ck_hse_rtc", "ck_hse", 0, RCC_RTCDIVR, 0, 6, 0),
-
-	COMPOSITE(RTC, "ck_rtc", rtc_src, CLK_OPS_PARENT_ENABLE |
-		   CLK_SET_RATE_PARENT,
+	COMPOSITE(RTC, "ck_rtc", rtc_src, CLK_OPS_PARENT_ENABLE,
 		  _GATE(RCC_BDCR, 20, 0),
 		  _MUX(RCC_BDCR, 16, 2, 0),
-		  _NO_DIV),
+		  _DIV_RTC(RCC_RTCDIVR, 0, 6, 0, NULL)),
 
 	/* MCO clocks */
 	COMPOSITE(CK_MCO1, "ck_mco1", mco1_src, CLK_OPS_PARENT_ENABLE |
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:49 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:49 +0200
Subject: [PATCH v3 08/11] dt-bindings: reset: add IDs for SCMI reset domains
 on stm32mp15
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-9-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

stm32mp15 TZ secure firmware provides SCMI reset domains for
secure resources. This change defines the SCMI reset domain
identifiers used by SCMI agents and servers.

Stm32mp15 TZ secure firmware provides SCMI clocks for oscillators, some
PLL output and few secure aware interfaces. This change defines the
SCMI clock identifiers used by SCMI agents and servers.

Server SCMI0 exposes reset controllers for resources under RCC[TZEN]
configuration control.

Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/dt-bindings/reset/stm32mp1-resets.h b/include/dt-bindings/reset/stm32mp1-resets.h
index f0c3aaef67a0..bc71924faa54 100644
--- a/include/dt-bindings/reset/stm32mp1-resets.h
+++ b/include/dt-bindings/reset/stm32mp1-resets.h
@@ -105,4 +105,17 @@
 #define GPIOJ_R		19785
 #define GPIOK_R		19786
 
+/* SCMI reset domain identifiers */
+#define RST_SCMI0_SPI6		0
+#define RST_SCMI0_I2C4		1
+#define RST_SCMI0_I2C6		2
+#define RST_SCMI0_USART1	3
+#define RST_SCMI0_STGEN		4
+#define RST_SCMI0_GPIOZ		5
+#define RST_SCMI0_CRYP1		6
+#define RST_SCMI0_HASH1		7
+#define RST_SCMI0_RNG1		8
+#define RST_SCMI0_MDMA		9
+#define RST_SCMI0_MCU		10
+
 #endif /* _DT_BINDINGS_STM32MP1_RESET_H_ */
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:51 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:51 +0200
Subject: [PATCH v3 10/11] dt-bindings: clock: stm32mp1 new compatible for
 secure rcc
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-11-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Introduce new compatible string "st,stm32mp1-rcc-secure" for
stm32mp1 clock driver when the device is configured with RCC
security support hardened.

Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml          | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
index 4e385508f516..8b1ecb2ecdd5 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
+++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
@@ -54,7 +54,9 @@ properties:
 
   compatible:
     items:
-      - const: st,stm32mp1-rcc
+      - enum:
+          - st,stm32mp1-rcc-secure
+          - st,stm32mp1-rcc
       - const: syscon
 
   reg:
@@ -71,7 +73,7 @@ additionalProperties: false
 examples:
   - |
     rcc: rcc at 50000000 {
-        compatible = "st,stm32mp1-rcc", "syscon";
+        compatible = "st,stm32mp1-rcc-secure", "syscon";
         reg = <0x50000000 0x1000>;
         #clock-cells = <1>;
         #reset-cells = <1>;
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:52 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:52 +0200
Subject: [PATCH v3 11/11] clk: stm32mp1: new compatible for secure RCC support
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-12-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Platform STM32MP1 can be used in configuration where some clock
resources cannot be accessed by Linux kernel when executing in non-secure
state of the CPU(s).
In such configuration, the RCC clock driver must not register clocks
it cannot access.
They are expected to be registered from another clock driver such
as the SCMI clock driver.
This change uses specific compatible string "st,stm32mp1-rcc-secure"
to specify RCC clock driver configuration where RCC is secure.

Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/Kconfig        |  10 ++++
 drivers/clk/clk-stm32mp1.c | 101 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 110 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a588d56502d4..44cc662f11f2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -335,6 +335,16 @@ config COMMON_CLK_STM32MP157
 	help
 	  Support for stm32mp157 SoC family clocks
 
+config COMMON_CLK_STM32MP157_SCMI
+	bool "stm32mp157 Clock driver with Trusted Firmware"
+	depends on COMMON_CLK_STM32MP157
+	select COMMON_CLK_SCMI
+	select ARM_SCMI_PROTOCOL
+	default y
+	help
+	  Support for stm32mp157 SoC family clocks with Trusted Firmware using
+	  SCMI protocol.
+
 config COMMON_CLK_STM32F
 	def_bool COMMON_CLK && (MACH_STM32F429 || MACH_STM32F469 || MACH_STM32F746)
 	help
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 6d3a36f81b2d..6adc625e79cb 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -2056,11 +2056,61 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_DBGCFGR, 0, 3, 0, ck_trace_div_table)),
 };
 
+static const u32 stm32mp1_clock_secured[] = {
+	CK_HSE,
+	CK_HSI,
+	CK_CSI,
+	CK_LSI,
+	CK_LSE,
+	PLL1,
+	PLL2,
+	PLL1_P,
+	PLL2_P,
+	PLL2_Q,
+	PLL2_R,
+	CK_MPU,
+	CK_AXI,
+	SPI6,
+	I2C4,
+	I2C6,
+	USART1,
+	RTCAPB,
+	TZC1,
+	TZC2,
+	TZPC,
+	IWDG1,
+	BSEC,
+	STGEN,
+	GPIOZ,
+	CRYP1,
+	HASH1,
+	RNG1,
+	BKPSRAM,
+	RNG1_K,
+	STGEN_K,
+	SPI6_K,
+	I2C4_K,
+	I2C6_K,
+	USART1_K,
+	RTC,
+};
+
+static bool stm32_check_security(const struct clock_config *cfg)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(stm32mp1_clock_secured); i++)
+		if (cfg->id == stm32mp1_clock_secured[i])
+			return true;
+	return false;
+}
+
 struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
 	u32 clear_offset;
+	bool (*check_security)(const struct clock_config *cfg);
 };
 
 static struct stm32_rcc_match_data stm32mp1_data = {
@@ -2070,11 +2120,23 @@ static struct stm32_rcc_match_data stm32mp1_data = {
 	.clear_offset	= RCC_CLR,
 };
 
+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,
+	.check_security = &stm32_check_security
+};
+
 static const struct of_device_id stm32mp1_match_data[] = {
 	{
 		.compatible = "st,stm32mp1-rcc",
 		.data = &stm32mp1_data,
 	},
+	{
+		.compatible = "st,stm32mp1-rcc-secure",
+		.data = &stm32mp1_data_secure,
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, stm32mp1_match_data);
@@ -2234,6 +2296,9 @@ static int stm32_rcc_clock_init(struct device *dev, void __iomem *base,
 		hws[n] = ERR_PTR(-ENOENT);
 
 	for (n = 0; n < data->num; n++) {
+		if (data->check_security && data->check_security(&data->cfg[n]))
+			continue;
+
 		err = stm32_register_hw_clk(dev, clk_data, base, &rlock,
 					    &data->cfg[n]);
 		if (err) {
@@ -2301,11 +2366,45 @@ static int stm32mp1_rcc_init(struct device *dev)
 	return ret;
 }
 
+static int get_clock_deps(struct device *dev)
+{
+	static const char * const clock_deps_name[] = {
+		"hsi", "hse", "csi", "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 = 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 stm32mp1_rcc_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	int ret = get_clock_deps(dev);
+
+	if (!ret)
+		ret = stm32mp1_rcc_init(dev);
 
-	return stm32mp1_rcc_init(dev);
+	return ret;
 }
 
 static int stm32mp1_rcc_clocks_remove(struct platform_device *pdev)
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:46 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:46 +0200
Subject: [PATCH v3 05/11] clk: stm32mp1: move RCC reset controller into RCC
 clock driver
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-6-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

RCC clock and reset controller shared same memory mapping.
As RCC clock driver is now a module, the best way to register clock
and reset controller is to do it in same driver.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
---
 drivers/clk/clk-stm32mp1.c | 157 ++++++++++++++++++++++++++++++++++---
 1 file changed, 144 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index e2e9331f1cba..6d3a36f81b2d 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -14,6 +14,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
+#include <linux/reset-controller.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 
@@ -2055,16 +2056,18 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _DIV(RCC_DBGCFGR, 0, 3, 0, ck_trace_div_table)),
 };
 
-struct stm32_clock_match_data {
+struct stm32_rcc_match_data {
 	const struct clock_config *cfg;
 	unsigned int num;
 	unsigned int maxbinding;
+	u32 clear_offset;
 };
 
-static struct stm32_clock_match_data stm32mp1_data = {
+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,
 };
 
 static const struct of_device_id stm32mp1_match_data[] = {
@@ -2100,23 +2103,122 @@ static int stm32_register_hw_clk(struct device *dev,
 	return 0;
 }
 
-static int stm32_rcc_init(struct device *dev, void __iomem *base,
-			  const struct of_device_id *match_data)
+#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)
 {
-	struct clk_hw_onecell_data *clk_data;
-	struct clk_hw **hws;
-	const struct of_device_id *match;
-	const struct stm32_clock_match_data *data;
-	int err, n, max_binding;
+	return container_of(rcdev, struct stm32_reset_data, rcdev);
+}
 
-	match = of_match_node(match_data, dev_of_node(dev));
-	if (!match) {
-		dev_err(dev, "match data not found\n");
-		return -ENODEV;
+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;
+
 	data = match->data;
 
+	reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
+	if (!reset_data)
+		return -ENOMEM;
+
+	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)
+{
+	const struct stm32_rcc_match_data *data = match->data;
+	struct clk_hw_onecell_data *clk_data;
+	struct clk_hw **hws;
+	int err, n, max_binding;
+
 	max_binding =  data->maxbinding;
 
 	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, max_binding),
@@ -2145,6 +2247,35 @@ static int stm32_rcc_init(struct device *dev, void __iomem *base,
 	return of_clk_add_hw_provider(dev_of_node(dev), of_clk_hw_onecell_get, clk_data);
 }
 
+static int stm32_rcc_init(struct device *dev, void __iomem *base,
+			  const struct of_device_id *match_data)
+{
+	const struct of_device_id *match;
+	int err;
+
+	match = of_match_node(match_data, dev_of_node(dev));
+	if (!match) {
+		dev_err(dev, "match data not found\n");
+		return -ENODEV;
+	}
+
+	/* RCC Reset Configuration */
+	err = stm32_rcc_reset_init(dev, base, match);
+	if (err) {
+		pr_err("stm32mp1 reset failed to initialize\n");
+		return err;
+	}
+
+	/* RCC Clock Configuration */
+	err = stm32_rcc_clock_init(dev, base, match);
+	if (err) {
+		pr_err("stm32mp1 clock failed to initialize\n");
+		return err;
+	}
+
+	return 0;
+}
+
 static int stm32mp1_rcc_init(struct device *dev)
 {
 	void __iomem *base;
-- 
2.17.1



From gabriel.fernandez at foss.st.com  Mon Apr 19 10:38:50 2021
From: gabriel.fernandez at foss.st.com (gabriel.fernandez at foss.st.com)
Date: Mon, 19 Apr 2021 11:38:50 +0200
Subject: [PATCH v3 09/11] dt-bindings: reset: add MCU HOLD BOOT ID for SCMI
 reset domains on stm32mp15
In-Reply-To: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
Message-ID: <20210419093852.14978-10-gabriel.fernandez@foss.st.com>

From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>

Add ID to SCMI0 to exposes reset controller for the MCU HOLD BOOT resource.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen at foss.st.com>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 include/dt-bindings/reset/stm32mp1-resets.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/reset/stm32mp1-resets.h b/include/dt-bindings/reset/stm32mp1-resets.h
index bc71924faa54..f3a0ed317835 100644
--- a/include/dt-bindings/reset/stm32mp1-resets.h
+++ b/include/dt-bindings/reset/stm32mp1-resets.h
@@ -7,6 +7,7 @@
 #ifndef _DT_BINDINGS_STM32MP1_RESET_H_
 #define _DT_BINDINGS_STM32MP1_RESET_H_
 
+#define MCU_HOLD_BOOT_R	2144
 #define LTDC_R		3072
 #define DSI_R		3076
 #define DDRPERFM_R	3080
@@ -117,5 +118,6 @@
 #define RST_SCMI0_RNG1		8
 #define RST_SCMI0_MDMA		9
 #define RST_SCMI0_MCU		10
+#define RST_SCMI0_MCU_HOLD_BOOT	11
 
 #endif /* _DT_BINDINGS_STM32MP1_RESET_H_ */
-- 
2.17.1



From david at redhat.com  Mon Apr 19 10:40:56 2021
From: david at redhat.com (David Hildenbrand)
Date: Mon, 19 Apr 2021 11:40:56 +0200
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <f4d0c4bf-423b-e227-444b-f1ea722dc43f@redhat.com>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
 <YH1PE4oWeicpJT9g@kernel.org>
 <f4d0c4bf-423b-e227-444b-f1ea722dc43f@redhat.com>
Message-ID: <56d8b80c-ce2c-ed86-0eda-253768d8d463@redhat.com>

On 19.04.21 11:38, David Hildenbrand wrote:
> On 19.04.21 11:36, Mike Rapoport wrote:
>> On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
>>> On 19.04.21 10:42, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>>
>>>> Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
>>>> due to commit "mm: introduce memfd_secret system call to create "secret"
>>>> memory areas".
>>>>
>>>> The perf profile of the test indicated that the regression is caused by
>>>> page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
>>>>
>>>>     27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
>>>>      0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
>>>>      0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
>>>>
>>>> Further analysis showed that the slow down happens because neither
>>>> page_is_secretmem() nor page_mapping() are not inline and moreover,
>>>> multiple page flags checks in page_mapping() involve calling
>>>> compound_head() several times for the same page.
>>>>
>>>> Make page_is_secretmem() inline and replace page_mapping() with page flag
>>>> checks that do not imply page-to-head conversion.
>>>>
>>>> Reported-by: kernel test robot <oliver.sang at intel.com>
>>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>>> ---
>>>>
>>>> @Andrew,
>>>> The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
>>>> be added as a fixup to the memfd_secret series.
>>>>
>>>>     include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
>>>>     mm/secretmem.c            | 12 +-----------
>>>>     2 files changed, 26 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
>>>> index 907a6734059c..b842b38cbeb1 100644
>>>> --- a/include/linux/secretmem.h
>>>> +++ b/include/linux/secretmem.h
>>>> @@ -4,8 +4,32 @@
>>>>     #ifdef CONFIG_SECRETMEM
>>>> +extern const struct address_space_operations secretmem_aops;
>>>> +
>>>> +static inline bool page_is_secretmem(struct page *page)
>>>> +{
>>>> +	struct address_space *mapping;
>>>> +
>>>> +	/*
>>>> +	 * Using page_mapping() is quite slow because of the actual call
>>>> +	 * instruction and repeated compound_head(page) inside the
>>>> +	 * page_mapping() function.
>>>> +	 * We know that secretmem pages are not compound and LRU so we can
>>>> +	 * save a couple of cycles here.
>>>> +	 */
>>>> +	if (PageCompound(page) || !PageLRU(page))
>>>> +		return false;
>>>
>>> I'd assume secretmem pages are rare in basically every setup out there. So
>>> maybe throwing in a couple of likely()/unlikely() might make sense.
>>
>> I'd say we could do unlikely(page_is_secretmem()) at call sites. Here I can
>> hardly estimate which pages are going to be checked.
>>    
>>>> +
>>>> +	mapping = (struct address_space *)
>>>> +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
>>>> +
>>>
>>> Not sure if open-coding page_mapping is really a good idea here -- or even
>>> necessary after the fast path above is in place. Anyhow, just my 2 cents.
>>
>> Well, most if the -4.2% of the performance regression kbuild reported were
>> due to repeated compount_head(page) in page_mapping(). So the whole point
>> of this patch is to avoid calling page_mapping().
> 
> I would have thought the fast path "(PageCompound(page) ||
> !PageLRU(page))" would already avoid calling page_mapping() in many cases.

(and I do wonder if a generic page_mapping() optimization would make 
sense instead)

Willy can most probably give the best advise here :)

-- 
Thanks,

David / dhildenb



From l.stach at pengutronix.de  Mon Apr 19 10:46:15 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Mon, 19 Apr 2021 11:46:15 +0200
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
Message-ID: <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>

Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> Hi Lucas,
> 
> On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> > Hi Robin,
> > 
> > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > > > Hi
> > > > > 
> > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > <l.stach at pengutronix.de>
> > > > wrote:
> > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > > > > There are two requirements that we need to move the request of
> > > > > > > dma channel from probe to open.
> > > > > > 
> > > > > > How do you handle -EPROBE_DEFER return code from the channel
> > > > > > request if you don't do it in probe?
> > > > > 
> > > > > I use the dma_request_slave_channel or dma_request_channel instead
> > > > > of dmaengine_pcm_request_chan_of. so there should be not
> > > > > -EPROBE_DEFER return code.
> > > > 
> > > > This is a pretty weak argument. The dmaengine device might probe
> > > > after you try to get the channel. Using a function to request the
> > > > channel that doesn't allow you to handle probe deferral is IMHO a
> > > > bug and should be fixed, instead of building even more assumptions on top
> > of it.
> > > > 
> > > > > > > - When dma device binds with power-domains, the power will be
> > > > > > > enabled when we request dma channel. If the request of dma
> > > > > > > channel happen on probe, then the power-domains will be always
> > > > > > > enabled after kernel boot up,  which is not good for power
> > > > > > > saving,  so we need to move the request of dma channel to
> > > > > > > .open();
> > > > > > 
> > > > > > This is certainly something which could be fixed in the
> > > > > > dmaengine driver.
> > > > > 
> > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > device_alloc_chan_resources, the device_alloc_chan_resources is
> > > > > called when channel is requested. so power is enabled on channel
> > request.
> > > > 
> > > > So why can't you fix the dmaengine driver to do that RPM call at a
> > > > later time when the channel is actually going to be used? This will
> > > > allow further power savings with other slave devices than the audio PCM.
> > > Hi Lucas,
> > > ??Thanks for your suggestion. I have tried to implement runtime
> > > autosuspend in fsl-edma driver on i.mx8qm/qxp with delay time (2 sec)
> > > for this feature as below (or you can refer to
> > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > pm_runtime_put_autosuspend in all dmaengine driver interface like
> > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_cycli
> > > c/
> > > device_tx_status...
> > > 
> > > 
> > > ????????????????pm_runtime_use_autosuspend(fsl_chan->dev);
> > > ????????????????pm_runtime_set_autosuspend_delay(fsl_chan->dev,
> > 2000);
> > > 
> > > That could resolve this audio case since the autosuspend could suspend
> > > runtime after
> > > 2 seconds if there is no further dma transfer but only channel
> > request(device_alloc_chan_resources).
> > > But unfortunately, it cause another issue. As you know, on our
> > > i.mx8qm/qxp, power domain done by scfw (drivers/firmware/imx/scu-pd.c)
> > over mailbox:
> > > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > > imx_scu_ipc_write()->mbox_send_message()
> > > which means have to 'waits for completion', meanwhile, some driver
> > > like tty will call dmaengine interfaces in non-atomic case as below,
> > > 
> > > static int uart_write(struct tty_struct *tty, const unsigned char
> > > *buf, int count) {
> > > ???.......
> > > 	    port = uart_port_lock(state, flags);
> > > ???......
> > > ????????__uart_start(tty);  //call start_tx()->dmaengine_prep_slave_sg...
> > > ????????uart_port_unlock(port, flags);
> > > ????????return ret;
> > > }
> > > 
> > > Thus dma runtime resume may happen in that timing window and cause
> > kernel alarm.
> > > I'm not sure whether there are similar limitations on other driver
> > > subsystem. But for me, It looks like the only way to resolve the
> > > contradiction between tty and scu-pd (hardware limitation on
> > > i.mx8qm/qxp) is to give up autosuspend and keep pm_runtime_get_sync
> > only in device_alloc_chan_resources because request channel is a safe
> > non-atomic phase.
> > > Do you have any idea? Thanks in advance.
> > 
> > If you look closely at the driver you used as an example (hidma.c) it looks like
> > there is already something in there, which looks very much like what you need
> > here:
> > 
> > In hidma_issue_pending() the driver tries to get the device to runtime resume.
> > If this doesn't work, maybe due to the power domain code not being able to
> > be called in atomic context, the actual work of waking up the dma hardware
> > and issuing the descriptor is shunted to a tasklet.
> > 
> > If I'm reading this right, this is exactly what you need here to be able to call the
> > dmaengine code from atomic context: try the rpm get and issue immediately
> > when possible, otherwise shunt the work to a non- atomic context where you
> > can deal with the requirements of scu-pd.
> Yes, I can schedule_work to worker to runtime resume edma channel by calling scu-pd.
> But that means all dmaengine interfaces should be taken care, not only issue_pending()
> but also dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> dmaengine_tx_status(). Not sure why hidma only take care issue_pending. Maybe
> their user case is just for memcpy/memset so that no further complicate case as ALSA
> or TTY.
> Besides, for autosuspend in cyclic, we have to add pm_runtime_get_sync into interrupt
> handler as qcom/bam_dma.c. but how could resolve the scu-pd's non-atmoic limitation
> in interrupt handler?  

Sure, this all needs some careful analysis on how those functions are
called and what to do about atomic callers, but it should be doable. I
don't see any fundamental issues here.

I don't see why you would ever need to wake the hardware in an
interrupt handler. Surely the hardware is already awake, as it wouldn't
signal an interrupt otherwise. And for the issue with scu-pd you only
care about the state transition of suspended->running. If the hardware
is already running/awake, the runtime pm state handling is nothing more
than bumping a refcount, which is atomic safe. Putting the HW in
suspend is already handled asynchronously in a worker, so this is also
atomic safe.

Regards,
Lucas



From rppt at kernel.org  Mon Apr 19 11:14:19 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 19 Apr 2021 13:14:19 +0300
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <56d8b80c-ce2c-ed86-0eda-253768d8d463@redhat.com>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
 <YH1PE4oWeicpJT9g@kernel.org>
 <f4d0c4bf-423b-e227-444b-f1ea722dc43f@redhat.com>
 <56d8b80c-ce2c-ed86-0eda-253768d8d463@redhat.com>
Message-ID: <YH1X+0CMH/2yppHK@kernel.org>

On Mon, Apr 19, 2021 at 11:40:56AM +0200, David Hildenbrand wrote:
> On 19.04.21 11:38, David Hildenbrand wrote:
> > On 19.04.21 11:36, Mike Rapoport wrote:
> > > On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
> > > > On 19.04.21 10:42, Mike Rapoport wrote:
> > > > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > > > 
> > > > > Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
> > > > > due to commit "mm: introduce memfd_secret system call to create "secret"
> > > > > memory areas".
> > > > > 
> > > > > The perf profile of the test indicated that the regression is caused by
> > > > > page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
> > > > > 
> > > > >     27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
> > > > >      0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
> > > > >      0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
> > > > > 
> > > > > Further analysis showed that the slow down happens because neither
> > > > > page_is_secretmem() nor page_mapping() are not inline and moreover,
> > > > > multiple page flags checks in page_mapping() involve calling
> > > > > compound_head() several times for the same page.
> > > > > 
> > > > > Make page_is_secretmem() inline and replace page_mapping() with page flag
> > > > > checks that do not imply page-to-head conversion.
> > > > > 
> > > > > Reported-by: kernel test robot <oliver.sang at intel.com>
> > > > > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > > > > ---
> > > > > 
> > > > > @Andrew,
> > > > > The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
> > > > > be added as a fixup to the memfd_secret series.
> > > > > 
> > > > >     include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
> > > > >     mm/secretmem.c            | 12 +-----------
> > > > >     2 files changed, 26 insertions(+), 12 deletions(-)
> > > > > 
> > > > > diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
> > > > > index 907a6734059c..b842b38cbeb1 100644
> > > > > --- a/include/linux/secretmem.h
> > > > > +++ b/include/linux/secretmem.h
> > > > > @@ -4,8 +4,32 @@
> > > > >     #ifdef CONFIG_SECRETMEM
> > > > > +extern const struct address_space_operations secretmem_aops;
> > > > > +
> > > > > +static inline bool page_is_secretmem(struct page *page)
> > > > > +{
> > > > > +	struct address_space *mapping;
> > > > > +
> > > > > +	/*
> > > > > +	 * Using page_mapping() is quite slow because of the actual call
> > > > > +	 * instruction and repeated compound_head(page) inside the
> > > > > +	 * page_mapping() function.
> > > > > +	 * We know that secretmem pages are not compound and LRU so we can
> > > > > +	 * save a couple of cycles here.
> > > > > +	 */
> > > > > +	if (PageCompound(page) || !PageLRU(page))
> > > > > +		return false;
> > > > 
> > > > I'd assume secretmem pages are rare in basically every setup out there. So
> > > > maybe throwing in a couple of likely()/unlikely() might make sense.
> > > 
> > > I'd say we could do unlikely(page_is_secretmem()) at call sites. Here I can
> > > hardly estimate which pages are going to be checked.
> > > > > +
> > > > > +	mapping = (struct address_space *)
> > > > > +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
> > > > > +
> > > > 
> > > > Not sure if open-coding page_mapping is really a good idea here -- or even
> > > > necessary after the fast path above is in place. Anyhow, just my 2 cents.
> > > 
> > > Well, most if the -4.2% of the performance regression kbuild reported were
> > > due to repeated compount_head(page) in page_mapping(). So the whole point
> > > of this patch is to avoid calling page_mapping().
> > 
> > I would have thought the fast path "(PageCompound(page) ||
> > !PageLRU(page))" would already avoid calling page_mapping() in many cases.
> 
> (and I do wonder if a generic page_mapping() optimization would make sense
> instead)

Not sure. Replacing page_mapping() with page_file_mapping() at the
call sites at fs/ and mm/ increased the defconfig image by nearly 2k
and page_file_mapping() is way simpler than page_mapping()

add/remove: 1/0 grow/shrink: 35/0 up/down: 1960/0 (1960)
Function                                     old     new   delta
shrink_page_list                            3414    3670    +256
__set_page_dirty_nobuffers                   242     349    +107
check_move_unevictable_pages                 904     987     +83
move_to_new_page                             591     671     +80
shrink_active_list                           912     970     +58
move_pages_to_lru                            911     965     +54
migrate_pages                               2500    2554     +54
shmem_swapin_page                           1145    1197     +52
shmem_undo_range                            1669    1719     +50
__test_set_page_writeback                    620     670     +50
__set_page_dirty_buffers                     187     237     +50
__pagevec_lru_add                            757     807     +50
__munlock_pagevec                           1155    1205     +50
__dump_page                                 1101    1151     +50
__cancel_dirty_page                          182     232     +50
__remove_mapping                             461     510     +49
rmap_walk_file                               402     449     +47
isolate_movable_page                         240     287     +47
test_clear_page_writeback                    668     714     +46
page_cache_pipe_buf_try_steal                171     217     +46
page_endio                                   246     290     +44
page_file_mapping                              -      43     +43
__isolate_lru_page_prepare                   254     297     +43
hugetlb_page_mapping_lock_write               39      81     +42
iomap_set_page_dirty                         110     151     +41
clear_page_dirty_for_io                      324     364     +40
wait_on_page_writeback_killable              118     157     +39
wait_on_page_writeback                       105     144     +39
set_page_dirty                               159     198     +39
putback_movable_page                          32      71     +39
page_mkclean                                 172     211     +39
mark_buffer_dirty                            176     215     +39
invalidate_inode_page                        122     161     +39
delete_from_page_cache                       139     178     +39
PageMovable                                   49      86     +37
isolate_migratepages_block                  2843    2872     +29
Total: Before=17068648, After=17070608, chg +0.01%
 
> Willy can most probably give the best advise here :)

I think that's what folios are for :)

-- 
Sincerely yours,
Mike.


From david at redhat.com  Mon Apr 19 11:21:30 2021
From: david at redhat.com (David Hildenbrand)
Date: Mon, 19 Apr 2021 12:21:30 +0200
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <YH1X+0CMH/2yppHK@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
 <YH1PE4oWeicpJT9g@kernel.org>
 <f4d0c4bf-423b-e227-444b-f1ea722dc43f@redhat.com>
 <56d8b80c-ce2c-ed86-0eda-253768d8d463@redhat.com>
 <YH1X+0CMH/2yppHK@kernel.org>
Message-ID: <0a957f9b-b4d7-869a-44ec-14e92a40d941@redhat.com>

On 19.04.21 12:14, Mike Rapoport wrote:
> On Mon, Apr 19, 2021 at 11:40:56AM +0200, David Hildenbrand wrote:
>> On 19.04.21 11:38, David Hildenbrand wrote:
>>> On 19.04.21 11:36, Mike Rapoport wrote:
>>>> On Mon, Apr 19, 2021 at 11:15:02AM +0200, David Hildenbrand wrote:
>>>>> On 19.04.21 10:42, Mike Rapoport wrote:
>>>>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>>>>
>>>>>> Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
>>>>>> due to commit "mm: introduce memfd_secret system call to create "secret"
>>>>>> memory areas".
>>>>>>
>>>>>> The perf profile of the test indicated that the regression is caused by
>>>>>> page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
>>>>>>
>>>>>>      27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
>>>>>>       0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
>>>>>>       0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem
>>>>>>
>>>>>> Further analysis showed that the slow down happens because neither
>>>>>> page_is_secretmem() nor page_mapping() are not inline and moreover,
>>>>>> multiple page flags checks in page_mapping() involve calling
>>>>>> compound_head() several times for the same page.
>>>>>>
>>>>>> Make page_is_secretmem() inline and replace page_mapping() with page flag
>>>>>> checks that do not imply page-to-head conversion.
>>>>>>
>>>>>> Reported-by: kernel test robot <oliver.sang at intel.com>
>>>>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>>>>> ---
>>>>>>
>>>>>> @Andrew,
>>>>>> The patch is vs v5.12-rc7-mmots-2021-04-15-16-28, I'd appreciate if it would
>>>>>> be added as a fixup to the memfd_secret series.
>>>>>>
>>>>>>      include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
>>>>>>      mm/secretmem.c            | 12 +-----------
>>>>>>      2 files changed, 26 insertions(+), 12 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
>>>>>> index 907a6734059c..b842b38cbeb1 100644
>>>>>> --- a/include/linux/secretmem.h
>>>>>> +++ b/include/linux/secretmem.h
>>>>>> @@ -4,8 +4,32 @@
>>>>>>      #ifdef CONFIG_SECRETMEM
>>>>>> +extern const struct address_space_operations secretmem_aops;
>>>>>> +
>>>>>> +static inline bool page_is_secretmem(struct page *page)
>>>>>> +{
>>>>>> +	struct address_space *mapping;
>>>>>> +
>>>>>> +	/*
>>>>>> +	 * Using page_mapping() is quite slow because of the actual call
>>>>>> +	 * instruction and repeated compound_head(page) inside the
>>>>>> +	 * page_mapping() function.
>>>>>> +	 * We know that secretmem pages are not compound and LRU so we can
>>>>>> +	 * save a couple of cycles here.
>>>>>> +	 */
>>>>>> +	if (PageCompound(page) || !PageLRU(page))
>>>>>> +		return false;
>>>>>
>>>>> I'd assume secretmem pages are rare in basically every setup out there. So
>>>>> maybe throwing in a couple of likely()/unlikely() might make sense.
>>>>
>>>> I'd say we could do unlikely(page_is_secretmem()) at call sites. Here I can
>>>> hardly estimate which pages are going to be checked.
>>>>>> +
>>>>>> +	mapping = (struct address_space *)
>>>>>> +		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
>>>>>> +
>>>>>
>>>>> Not sure if open-coding page_mapping is really a good idea here -- or even
>>>>> necessary after the fast path above is in place. Anyhow, just my 2 cents.
>>>>
>>>> Well, most if the -4.2% of the performance regression kbuild reported were
>>>> due to repeated compount_head(page) in page_mapping(). So the whole point
>>>> of this patch is to avoid calling page_mapping().
>>>
>>> I would have thought the fast path "(PageCompound(page) ||
>>> !PageLRU(page))" would already avoid calling page_mapping() in many cases.
>>
>> (and I do wonder if a generic page_mapping() optimization would make sense
>> instead)
> 
> Not sure. Replacing page_mapping() with page_file_mapping() at the
> call sites at fs/ and mm/ increased the defconfig image by nearly 2k
> and page_file_mapping() is way simpler than page_mapping()
> 
> add/remove: 1/0 grow/shrink: 35/0 up/down: 1960/0 (1960)
> Function                                     old     new   delta
> shrink_page_list                            3414    3670    +256
> __set_page_dirty_nobuffers                   242     349    +107
> check_move_unevictable_pages                 904     987     +83
> move_to_new_page                             591     671     +80
> shrink_active_list                           912     970     +58
> move_pages_to_lru                            911     965     +54
> migrate_pages                               2500    2554     +54
> shmem_swapin_page                           1145    1197     +52
> shmem_undo_range                            1669    1719     +50
> __test_set_page_writeback                    620     670     +50
> __set_page_dirty_buffers                     187     237     +50
> __pagevec_lru_add                            757     807     +50
> __munlock_pagevec                           1155    1205     +50
> __dump_page                                 1101    1151     +50
> __cancel_dirty_page                          182     232     +50
> __remove_mapping                             461     510     +49
> rmap_walk_file                               402     449     +47
> isolate_movable_page                         240     287     +47
> test_clear_page_writeback                    668     714     +46
> page_cache_pipe_buf_try_steal                171     217     +46
> page_endio                                   246     290     +44
> page_file_mapping                              -      43     +43
> __isolate_lru_page_prepare                   254     297     +43
> hugetlb_page_mapping_lock_write               39      81     +42
> iomap_set_page_dirty                         110     151     +41
> clear_page_dirty_for_io                      324     364     +40
> wait_on_page_writeback_killable              118     157     +39
> wait_on_page_writeback                       105     144     +39
> set_page_dirty                               159     198     +39
> putback_movable_page                          32      71     +39
> page_mkclean                                 172     211     +39
> mark_buffer_dirty                            176     215     +39
> invalidate_inode_page                        122     161     +39
> delete_from_page_cache                       139     178     +39
> PageMovable                                   49      86     +37
> isolate_migratepages_block                  2843    2872     +29
> Total: Before=17068648, After=17070608, chg +0.01%
>   
>> Willy can most probably give the best advise here :)
> 
> I think that's what folios are for :)

Exactly my thought. :)


-- 
Thanks,

David / dhildenb



From lorenzo.pieralisi at arm.com  Mon Apr 19 11:44:32 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 19 Apr 2021 11:44:32 +0100
Subject: [v9,0/7] PCI: mediatek: Add new generation controller support
In-Reply-To: <20210416192100.GA2745484@bjorn-Precision-5520>
References: <20210324030510.29177-1-jianjun.wang@mediatek.com>
 <20210416192100.GA2745484@bjorn-Precision-5520>
Message-ID: <20210419104432.GA2427@lpieralisi>

On Fri, Apr 16, 2021 at 02:21:00PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 24, 2021 at 11:05:03AM +0800, Jianjun Wang wrote:
> > These series patches add pcie-mediatek-gen3.c and dt-bindings file to
> > support new generation PCIe controller.
> 
> Incidental: b4 doesn't work on this thread, I suspect because the
> usual subject line format is:
> 
>   [PATCH v9 9/7]
> 
> instead of:
> 
>   [v9,0/7]
> 
> For b4 info, see https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst

Jianjun will update the series accordingly (and please add to v10 the
review tags you received.

Lorenzo


From michal.simek at xilinx.com  Mon Apr 19 11:52:30 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 19 Apr 2021 12:52:30 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
 <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
 <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>
Message-ID: <2f2e3019-afdd-103f-b984-06e65b10fc50@xilinx.com>

Hi Jan,

On 4/18/21 2:12 PM, Jan Kiszka wrote:
> On 01.04.21 16:52, Jan Kiszka wrote:
>> On 01.04.21 13:42, Michal Simek wrote:
>>> Hi Jan,
>>>
>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>
>>>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>> new file mode 100644
>>>>> index 0000000..9868ca1
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>> @@ -0,0 +1,222 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>> +/*
>>>>> + * Clock specification for Xilinx ZynqMP
>>>>> + *
>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>> + *
>>>>> + * Michal Simek <michal.simek at xilinx.com>
>>>>> + */
>>>>> +
>>>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>>>> +/ {
>>>>> +	pss_ref_clk: pss_ref_clk {
>>>>> +		u-boot,dm-pre-reloc;
>>>>> +		compatible = "fixed-clock";
>>>>> +		#clock-cells = <0>;
>>>>> +		clock-frequency = <33333333>;
>>>>> +	};
>>>>> +
>>>>> +	video_clk: video_clk {
>>>>> +		u-boot,dm-pre-reloc;
>>>>> +		compatible = "fixed-clock";
>>>>> +		#clock-cells = <0>;
>>>>> +		clock-frequency = <27000000>;
>>>>> +	};
>>>>> +
>>>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>>>> +		u-boot,dm-pre-reloc;
>>>>> +		compatible = "fixed-clock";
>>>>> +		#clock-cells = <0>;
>>>>> +		clock-frequency = <0>;
>>>>> +	};
>>>>> +
>>>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>>>> +		u-boot,dm-pre-reloc;
>>>>> +		compatible = "fixed-clock";
>>>>> +		#clock-cells = <0>;
>>>>> +		clock-frequency = <108000000>;
>>>>> +	};
>>>>> +
>>>>> +	aux_ref_clk: aux_ref_clk {
>>>>> +		u-boot,dm-pre-reloc;
>>>>> +		compatible = "fixed-clock";
>>>>> +		#clock-cells = <0>;
>>>>> +		clock-frequency = <27000000>;
>>>>> +	};
>>>>> +};
>>>>> +
>>>>> +&can0 {
>>>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&can1 {
>>>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&cpu0 {
>>>>> +	clocks = <&zynqmp_clk ACPU>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan1 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan2 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan3 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan4 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan5 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan6 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan7 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&fpd_dma_chan8 {
>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan1 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan2 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan3 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan4 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan5 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan6 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan7 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&lpd_dma_chan8 {
>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&gem0 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>> +};
>>>>> +
>>>>> +&gem1 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>> +};
>>>>> +
>>>>> +&gem2 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>> +};
>>>>> +
>>>>> +&gem3 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>> +};
>>>>> +
>>>>> +&gpio {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&i2c0 {
>>>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>>>> +};
>>>>> +
>>>>> +&i2c1 {
>>>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>>>> +};
>>>>> +
>>>>> +&pcie {
>>>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>>>> +};
>>>>> +
>>>>> +&sata {
>>>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>>>> +};
>>>>> +
>>>>> +&sdhci0 {
>>>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&sdhci1 {
>>>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&spi0 {
>>>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&spi1 {
>>>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&ttc0 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&ttc1 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&ttc2 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&ttc3 {
>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&uart0 {
>>>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&uart1 {
>>>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>> +};
>>>>> +
>>>>> +&usb0 {
>>>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>> +};
>>>>> +
>>>>> +&usb1 {
>>>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>> +};
>>>>> +
>>>>> +&watchdog0 {
>>>>> +	clocks = <&zynqmp_clk WDT>;
>>>>> +};
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>> index 0f7b4cf..2e05fa4 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZC1232
>>>>>   *
>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>
>>>>>  / {
>>>>>  	model = "ZynqMP ZC1232 RevA";
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>> index 9092828..3d0aaa0 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZC1254
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>>> @@ -11,7 +11,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>
>>>>>  / {
>>>>>  	model = "ZynqMP ZC1254 RevA";
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>> index 4f404c5..1a8127d4 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>> @@ -11,7 +11,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>
>>>>>  / {
>>>>>  	model = "ZynqMP ZC1275 RevA";
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>> index 9a3e39d..fa7eb1b 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>>  / {
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>> index 2421ec7..4191dfa 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>>  / {
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>> index 7a49dee..3750690 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>>>   *
>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>
>>>>>  / {
>>>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>> index 54c7b4f..2366cd9 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>
>>>>>  / {
>>>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>> index b8b5ff1..9a894e6 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>> @@ -11,7 +11,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>>  / {
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>> index e5699d0..3e39454 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>>>   *
>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   * Nathalie Chan King Choy
>>>>> @@ -11,7 +11,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/input/input.h>
>>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>> index 2a3b665..f6e9558 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>>>   *
>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/input/input.h>
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>> index 8f45614..f457f8a 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZCU104
>>>>>   *
>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>>  / {
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>> index 93ce7eb..f15b99a 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZCU106
>>>>>   *
>>>>> - * (C) Copyright 2016, Xilinx, Inc.
>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/input/input.h>
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>> index 8bb0001..e27cd60 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP ZCU111
>>>>>   *
>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   */
>>>>> @@ -10,7 +10,7 @@
>>>>>  /dts-v1/;
>>>>>
>>>>>  #include "zynqmp.dtsi"
>>>>> -#include "zynqmp-clk.dtsi"
>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>  #include <dt-bindings/input/input.h>
>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>> index 9aa6734..59a547b 100644
>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>> @@ -2,7 +2,7 @@
>>>>>  /*
>>>>>   * dts file for Xilinx ZynqMP
>>>>>   *
>>>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>>>   *
>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>   *
>>>>> @@ -124,6 +124,28 @@
>>>>>  			     <1 10 0xf08>;
>>>>>  	};
>>>>>
>>>>> +	firmware {
>>>>> +		zynqmp_firmware: zynqmp-firmware {
>>>>> +			compatible = "xlnx,zynqmp-firmware";
>>>>> +			method = "smc";
>>>>> +			zynqmp_clk: clock-controller {
>>>>> +				u-boot,dm-pre-reloc;
>>>>> +				#clock-cells = <1>;
>>>>> +				compatible = "xlnx,zynqmp-clk";
>>>>> +				clocks = <&pss_ref_clk>,
>>>>> +					 <&video_clk>,
>>>>> +					 <&pss_alt_ref_clk>,
>>>>> +					 <&aux_ref_clk>,
>>>>> +					 <&gt_crx_ref_clk>;
>>>>> +				clock-names = "pss_ref_clk",
>>>>> +					      "video_clk",
>>>>> +					      "pss_alt_ref_clk",
>>>>> +					      "aux_ref_clk",
>>>>> +					      "gt_crx_ref_clk";
>>>>> +			};
>>>>> +		};
>>>>> +	};
>>>>> +
>>>>>  	amba_apu: amba-apu at 0 {
>>>>>  		compatible = "simple-bus";
>>>>>  		#address-cells = <2>;
>>>>>
>>>>
>>>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>>>> Starting from this commit on, I'm no longer getting the kernel to boot
>>>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>>>> DTBs back before this commit, even a kernel from today's head is fine.
>>>>
>>>> Further versions of potential relevance:
>>>>  - PMUFW 2019.1 and 2020.2
>>>>  - TF-A 2.3
>>>>  - U-Boot 2020.10
>>>>
>>>> What's missing? I suspect someone forgot to document a subtle dependency
>>>> of this change.
>>>
>>> Does this fix your issue?
>>> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>>>
>>
>> Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
>> missing even more. If you have some reference, I'm happy to try. I
>> suspect that earlyprintk will also not reveal more without clocks (but I
>> didn't play with that yet).
>>
>> Meanwhile, I'm carrying a revert of this commit and a related cleanup.
>> That helps for now.
>>
> 
> OK, dependencies resolved (unfortunately the hard way): It either
> requires TF-A master or latest release v2.4 + [1] and [2].
> 
> Those TF-A commits were upstream about a year after the firmware-based
> clock control hit the kernel. A note would have been nice - or better
> sychronization between both upstreaming efforts.

I wasn't responsible for TFA but I found this last year in Nov timeframe
that none really upstream this. Right now that development is working
like that. I am asking everybody to contribute upstream to have all the
time upstream heads to work together.
I haven't had a time to dig into this but unfortunatelly there is no
feature checking mechanism on zynqmp TFA side to check if this is there
or not but we are trying our best to check as much as possible but bugs
happen.
And we are lacking space in OCM to be able to add more features to TFA
anyway.

Thanks,
Michal





From suzuki.poulose at arm.com  Mon Apr 19 12:17:41 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 19 Apr 2021 12:17:41 +0100
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
Message-ID: <529defac-cd67-3a7b-91d3-76eb0bb9dc6c@arm.com>

On 17/04/2021 11:17, Yicong Yang wrote:
> [RESEND with perf and coresight folks Cc'ed]
> 
> HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
> integrated Endpoint (RCiEP) device, providing the capability
> to dynamically monitor and tune the PCIe traffic (tune),
> and trace the TLP headers (trace).
> 
> PTT tune is designed for monitoring and adjusting PCIe link parameters.
> We provide several parameters of the PCIe link. Through the driver,
> user can adjust the value of certain parameter to affect the PCIe link
> for the purpose of enhancing the performance in certian situation.

...

> 
> The reason for not using perf is because there is no current support
> for uncore tracing in the perf facilities. We have our own format
> of data and don't need perf doing the parsing. The setting through
> perf tools doesn't seem to be friendly as well. For example,
> we cannot count on perf to decode the usual format BDF number like
> <domain>:<bus>:<dev>.<fn>, which user can use to filter the TLP
> headers through the PTT device.
> 
> A similar approach for implementing this function is ETM, which use
> sysfs for configuring and a character device for dumping data.
> 
> Greg has some comments on our implementation and doesn't advocate
> to build driver on debugfs [1]. So I resend this series to
> collect more feedbacks on the implementation of this driver.
> 
> Hi perf and ETM related experts, is it suggested to adapt this driver
> to perf? Or is the debugfs approach acceptable? Otherwise use
> sysfs + character device like ETM and use perf tools for decoding it?
> Any comments is welcomed.

Please use perf. Debugfs / sysfs is not the right place for these things.

Also, please move your driver to drivers/perf/

As Alex mentioned, the ETM drivers were initially developed when the AUX
buffer was not available. The sysfs interface is there only for the 
backward compatibility and for bring up ( due to the nature of the
connections between the CoreSight components and sometimes the missing 
engineering spec).

Suzuki


From vee.khee.wong at linux.intel.com  Mon Apr 19 12:25:30 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Mon, 19 Apr 2021 19:25:30 +0800
Subject: [PATCH net-next 1/1] net: stmmac: fix memory leak during driver probe
Message-ID: <20210419112530.20395-1-vee.khee.wong@linux.intel.com>

On driver probe, kmemleak reported the following memory leak which was
due to allocated bitmap that was not being freed in stmmac_dvr_probe().

unreferenced object 0xffff9276014b13c0 (size 8):
  comm "systemd-udevd", pid 2143, jiffies 4294681112 (age 116.720s)
  hex dump (first 8 bytes):
    00 00 00 00 00 00 00 00                          ........
  backtrace:
    [<00000000c51e34b2>] stmmac_dvr_probe+0x1c0/0x440 [stmmac]
    [<00000000b530eb41>] intel_eth_pci_probe.cold+0x2b/0x14e [dwmac_intel]
    [<00000000b10f8929>] pci_device_probe+0xd2/0x150
    [<00000000fb254c74>] really_probe+0xf8/0x410
    [<0000000034128a59>] driver_probe_device+0x5d/0x150
    [<00000000016104d5>] device_driver_attach+0x53/0x60
    [<00000000cb18cd07>] __driver_attach+0x96/0x140
    [<00000000da9ffd5c>] bus_for_each_dev+0x7a/0xc0
    [<00000000af061a88>] bus_add_driver+0x184/0x1f0
    [<000000008be5c1c5>] driver_register+0x6c/0xc0
    [<0000000052b18a9e>] do_one_initcall+0x4d/0x210
    [<00000000154d4f07>] do_init_module+0x5c/0x230
    [<000000009b648d09>] load_module+0x2a5a/0x2d40
    [<000000000d86b76d>] __do_sys_finit_module+0xb5/0x120
    [<000000002b0cef95>] do_syscall_64+0x33/0x40
    [<0000000067b45bbb>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
Cc: Ong Boon Leong <boon.leong.ong at intel.com>
Signed-off-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9f396648d76f..d1ca07c846e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7035,6 +7035,7 @@ int stmmac_dvr_probe(struct device *device,
 error_hw_init:
 	destroy_workqueue(priv->wq);
 	stmmac_bus_clks_config(priv, false);
+	bitmap_free(priv->af_xdp_zc_qps);
 
 	return ret;
 }
@@ -7077,6 +7078,7 @@ int stmmac_dvr_remove(struct device *dev)
 		stmmac_mdio_unregister(ndev);
 	destroy_workqueue(priv->wq);
 	mutex_destroy(&priv->lock);
+	bitmap_free(priv->af_xdp_zc_qps);
 
 	return 0;
 }
-- 
2.25.1



From willy at infradead.org  Mon Apr 19 12:23:02 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 19 Apr 2021 12:23:02 +0100
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210419084218.7466-1-rppt@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
Message-ID: <20210419112302.GX2531743@casper.infradead.org>

On Mon, Apr 19, 2021 at 11:42:18AM +0300, Mike Rapoport wrote:
> The perf profile of the test indicated that the regression is caused by
> page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):

Uhh ... you're calling it in the wrong place!

                VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
                page = pte_page(pte);

                if (page_is_secretmem(page))
                        goto pte_unmap;

                head = try_grab_compound_head(page, 1, flags);
                if (!head)
                        goto pte_unmap;

So you're calling page_is_secretmem() on a struct page without having
a refcount on it.  That is definitely not allowed.  secretmem seems to
be full of these kinds of races; I know this isn't the first one I've
seen in it.  I don't think this patchset is ready for this merge window.

With that fixed, you'll have a head page that you can use for testing,
which means you don't need to test PageCompound() (because you know the
page isn't PageTail), you can just test PageHead().


From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:55 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:55 +0300
Subject: [PATCH v1 2/6] mmc: core: Convert mmc_of_parse_voltage() to use
 device property API
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210419112459.25241-2-andriy.shevchenko@linux.intel.com>

mmc_of_parse() for a few years has been using device property API.
Convert mmc_of_parse_voltage() as well.

At the same time switch users to new API.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/mmc/core/host.c            | 46 +++++++++++++++++++++---------
 drivers/mmc/host/mmc_spi.c         |  8 +++---
 drivers/mmc/host/of_mmc_spi.c      |  3 +-
 drivers/mmc/host/sdhci-esdhc-imx.c |  2 +-
 drivers/mmc/host/sdhci-of-esdhc.c  |  2 +-
 include/linux/mmc/host.h           |  2 +-
 6 files changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index ce030c5aa53c..793c7425d0dd 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -379,44 +379,62 @@ EXPORT_SYMBOL(mmc_of_parse);
 
 /**
  * mmc_of_parse_voltage - return mask of supported voltages
- * @np: The device node need to be parsed.
+ * @host: host whose properties should be parsed.
  * @mask: mask of voltages available for MMC/SD/SDIO
  *
- * Parse the "voltage-ranges" DT property, returning zero if it is not
+ * Parse the "voltage-ranges" property, returning zero if it is not
  * found, negative errno if the voltage-range specification is invalid,
  * or one if the voltage-range is specified and successfully parsed.
  */
-int mmc_of_parse_voltage(struct device_node *np, u32 *mask)
+int mmc_of_parse_voltage(struct mmc_host *host, u32 *mask)
 {
-	const u32 *voltage_ranges;
+	const char *prop = "voltage-ranges";
+	struct device *dev = host->parent;
+	u32 *voltage_ranges;
 	int num_ranges, i;
+	int ret;
 
-	voltage_ranges = of_get_property(np, "voltage-ranges", &num_ranges);
-	if (!voltage_ranges) {
-		pr_debug("%pOF: voltage-ranges unspecified\n", np);
+	if (!device_property_present(dev, prop)) {
+		dev_dbg(dev, "%s unspecified\n", prop);
 		return 0;
 	}
-	num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
+
+	ret = device_property_count_u32(dev, prop);
+	if (ret < 0)
+		return ret;
+
+	num_ranges = ret / 2;
 	if (!num_ranges) {
-		pr_err("%pOF: voltage-ranges empty\n", np);
+		dev_err(dev, "%s empty\n", prop);
 		return -EINVAL;
 	}
 
+	voltage_ranges = kcalloc(2 * num_ranges, sizeof(*voltage_ranges), GFP_KERNEL);
+	if (!voltage_ranges)
+		return -ENOMEM;
+
+	ret = device_property_read_u32_array(dev, prop, voltage_ranges, 2 * num_ranges);
+	if (ret) {
+		kfree(voltage_ranges);
+		return ret;
+	}
+
 	for (i = 0; i < num_ranges; i++) {
 		const int j = i * 2;
 		u32 ocr_mask;
 
-		ocr_mask = mmc_vddrange_to_ocrmask(
-				be32_to_cpu(voltage_ranges[j]),
-				be32_to_cpu(voltage_ranges[j + 1]));
+		ocr_mask = mmc_vddrange_to_ocrmask(voltage_ranges[j + 0],
+						   voltage_ranges[j + 1]);
 		if (!ocr_mask) {
-			pr_err("%pOF: voltage-range #%d is invalid\n",
-				np, i);
+			dev_err(dev, "range #%d in %s is invalid\n", i, prop);
+			kfree(voltage_ranges);
 			return -EINVAL;
 		}
 		*mask |= ocr_mask;
 	}
 
+	kfree(voltage_ranges);
+
 	return 1;
 }
 EXPORT_SYMBOL(mmc_of_parse_voltage);
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 02f4fd26e76a..9776a03a10f5 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1397,6 +1397,8 @@ static int mmc_spi_probe(struct spi_device *spi)
 
 	host->ones = ones;
 
+	dev_set_drvdata(&spi->dev, mmc);
+
 	/* Platform data is used to hook up things like card sensing
 	 * and power switching gpios.
 	 */
@@ -1413,8 +1415,6 @@ static int mmc_spi_probe(struct spi_device *spi)
 			host->powerup_msecs = 250;
 	}
 
-	dev_set_drvdata(&spi->dev, mmc);
-
 	/* preallocate dma buffers */
 	host->data = kmalloc(sizeof(*host->data), GFP_KERNEL);
 	if (!host->data)
@@ -1494,8 +1494,8 @@ static int mmc_spi_probe(struct spi_device *spi)
 fail_dma:
 	kfree(host->data);
 fail_nobuf1:
-	mmc_free_host(mmc);
 	mmc_spi_put_pdata(spi);
+	mmc_free_host(mmc);
 nomem:
 	kfree(ones);
 	return status;
@@ -1518,8 +1518,8 @@ static int mmc_spi_remove(struct spi_device *spi)
 	kfree(host->ones);
 
 	spi->max_speed_hz = mmc->f_max;
-	mmc_free_host(mmc);
 	mmc_spi_put_pdata(spi);
+	mmc_free_host(mmc);
 	return 0;
 }
 
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index 3c4d950a4755..acd96ea399b8 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -54,6 +54,7 @@ static void of_mmc_spi_exit(struct device *dev, void *mmc)
 
 struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 {
+	struct mmc_host *mmc = dev_get_drvdata(&spi->dev);
 	struct device *dev = &spi->dev;
 	struct device_node *np = dev->of_node;
 	struct of_mmc_spi *oms;
@@ -65,7 +66,7 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 	if (!oms)
 		return NULL;
 
-	if (mmc_of_parse_voltage(np, &oms->pdata.ocr_mask) <= 0)
+	if (mmc_of_parse_voltage(mmc, &oms->pdata.ocr_mask) <= 0)
 		goto err_ocr;
 
 	oms->detect_irq = irq_of_parse_and_map(np, 0);
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index a20459744d21..f39d85e8ea6d 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -1486,7 +1486,7 @@ sdhci_esdhc_imx_probe_dt(struct platform_device *pdev,
 	if (of_property_read_u32(np, "fsl,delay-line", &boarddata->delay_line))
 		boarddata->delay_line = 0;
 
-	mmc_of_parse_voltage(np, &host->ocr_mask);
+	mmc_of_parse_voltage(host->mmc, &host->ocr_mask);
 
 	if (esdhc_is_usdhc(imx_data)) {
 		imx_data->pins_100mhz = pinctrl_lookup_state(imx_data->pinctrl,
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index ab5ab969f711..a593b1fbd69e 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1489,7 +1489,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
 	if (ret)
 		goto err;
 
-	mmc_of_parse_voltage(np, &host->ocr_mask);
+	mmc_of_parse_voltage(host->mmc, &host->ocr_mask);
 
 	ret = sdhci_add_host(host);
 	if (ret)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 26a3c7bc29ae..ecd25a3b37f0 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -514,7 +514,7 @@ void mmc_free_host(struct mmc_host *);
 void mmc_of_parse_clk_phase(struct mmc_host *host,
 			    struct mmc_clk_phase_map *map);
 int mmc_of_parse(struct mmc_host *host);
-int mmc_of_parse_voltage(struct device_node *np, u32 *mask);
+int mmc_of_parse_voltage(struct mmc_host *host, u32 *mask);
 
 static inline void *mmc_priv(struct mmc_host *host)
 {
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:54 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:54 +0300
Subject: [PATCH v1 1/6] mmc: core: Correct descriptions in mmc_of_parse()
Message-ID: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>

Since it has been converted to use device property API, the function
and field descriptions become outdated. Correct them.

Fixes: 73a47a9bb3e2 ("mmc: core: Use device_property_read instead of of_property_read")
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/mmc/core/host.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 9b89a91b6b47..ce030c5aa53c 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -209,8 +209,8 @@ mmc_of_parse_clk_phase(struct mmc_host *host, struct mmc_clk_phase_map *map)
 EXPORT_SYMBOL(mmc_of_parse_clk_phase);
 
 /**
- *	mmc_of_parse() - parse host's device-tree node
- *	@host: host whose node should be parsed.
+ * mmc_of_parse() - parse host's device properties
+ * @host: host whose properties should be parsed.
  *
  * To keep the rest of the MMC subsystem unaware of whether DT has been
  * used to to instantiate and configure this host instance or not, we
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:59 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:59 +0300
Subject: [PATCH v1 6/6] mmc: mmc_spi: Make of_mmc_spi.c resource provider
 agnostic
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210419112459.25241-6-andriy.shevchenko@linux.intel.com>

In order to use the same driver on non-OF platforms, make
of_mmc_spi.c resource provider agnostic.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/mmc/host/Makefile     | 2 --
 drivers/mmc/host/of_mmc_spi.c | 6 ++----
 include/linux/spi/mmc_spi.h   | 9 ---------
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 6df5c4774260..14004cc09aaa 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -34,9 +34,7 @@ obj-$(CONFIG_MMC_TIFM_SD)	+= tifm_sd.o
 obj-$(CONFIG_MMC_MVSDIO)	+= mvsdio.o
 obj-$(CONFIG_MMC_DAVINCI)       += davinci_mmc.o
 obj-$(CONFIG_MMC_SPI)		+= mmc_spi.o
-ifeq ($(CONFIG_OF),y)
 obj-$(CONFIG_MMC_SPI)		+= of_mmc_spi.o
-endif
 obj-$(CONFIG_MMC_S3C)   	+= s3cmci.o
 obj-$(CONFIG_MMC_SDRICOH_CS)	+= sdricoh_cs.o
 obj-$(CONFIG_MMC_TMIO)		+= tmio_mmc.o
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index 009c3885f6ba..9d480a05f655 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -51,10 +51,9 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 {
 	struct mmc_host *mmc = dev_get_drvdata(&spi->dev);
 	struct device *dev = &spi->dev;
-	struct device_node *np = dev->of_node;
 	struct of_mmc_spi *oms;
 
-	if (dev->platform_data || !np)
+	if (dev->platform_data || !dev_fwnode(dev))
 		return dev->platform_data;
 
 	oms = kzalloc(sizeof(*oms), GFP_KERNEL);
@@ -83,10 +82,9 @@ EXPORT_SYMBOL(mmc_spi_get_pdata);
 void mmc_spi_put_pdata(struct spi_device *spi)
 {
 	struct device *dev = &spi->dev;
-	struct device_node *np = dev->of_node;
 	struct of_mmc_spi *oms = to_of_mmc_spi(dev);
 
-	if (!dev->platform_data || !np)
+	if (!dev->platform_data || !dev_fwnode(dev))
 		return;
 
 	kfree(oms);
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index 778ae8eb1f3e..9ad9a06e488d 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -35,16 +35,7 @@ struct mmc_spi_platform_data {
 	void (*setpower)(struct device *, unsigned int maskval);
 };
 
-#ifdef CONFIG_OF
 extern struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi);
 extern void mmc_spi_put_pdata(struct spi_device *spi);
-#else
-static inline struct mmc_spi_platform_data *
-mmc_spi_get_pdata(struct spi_device *spi)
-{
-	return spi->dev.platform_data;
-}
-static inline void mmc_spi_put_pdata(struct spi_device *spi) {}
-#endif /* CONFIG_OF */
 
 #endif /* __LINUX_SPI_MMC_SPI_H */
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:57 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:57 +0300
Subject: [PATCH v1 4/6] mmc: mmc_spi: Drop unused NO_IRQ definition
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210419112459.25241-4-andriy.shevchenko@linux.intel.com>

After the commit 073350f7b562 ("mmc: mmc_spi: Fix return value evaluation of
irq_of_parse_and_map()") the NO_IRQ is not used anymore, drop it for good.

Fixes: 073350f7b562 ("mmc: mmc_spi: Fix return value evaluation of irq_of_parse_and_map()")
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/mmc/host/of_mmc_spi.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index 843ec3db891b..0b038f5c392a 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -19,11 +19,6 @@
 #include <linux/mmc/core.h>
 #include <linux/mmc/host.h>
 
-/* For archs that don't support NO_IRQ (such as mips), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
 MODULE_LICENSE("GPL");
 
 struct of_mmc_spi {
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:56 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:56 +0300
Subject: [PATCH v1 3/6] mmc: mmc_spi: Set up polling even if voltage-ranges is
 not present
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210419112459.25241-3-andriy.shevchenko@linux.intel.com>

When voltage-ranges property is not present the driver assumes that
it is 3.3v (3.2v..3.4v). But at the same time it disallows polling.

Fix that by dropping the comparison to 0 when no property is provided.

While at it, mark voltage-ranges property optional as it was initially.

Fixes: 9c43df57910b ("mmc_spi: Add support for OpenFirmware bindings")
Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt | 6 +++---
 drivers/mmc/host/of_mmc_spi.c                          | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
index 75486cca8054..5e74db69f581 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
@@ -5,11 +5,11 @@ by mmc.txt and the properties used by the mmc_spi driver.
 
 Required properties:
 - spi-max-frequency : maximum frequency for this device (Hz).
-- voltage-ranges : two cells are required, first cell specifies minimum
-  slot voltage (mV), second cell specifies maximum slot voltage (mV).
-  Several ranges could be specified.
 
 Optional properties:
+- voltage-ranges : two cells are required, first cell specifies minimum
+  slot voltage (mV), second cell specifies maximum slot voltage (mV).
+  Several ranges could be specified. If not provided, 3.2v..3.4v is assumed.
 - gpios : may specify GPIOs in this order: Card-Detect GPIO,
   Write-Protect GPIO. Note that this does not follow the
   binding from mmc.txt, for historical reasons.
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index acd96ea399b8..843ec3db891b 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -66,7 +66,7 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 	if (!oms)
 		return NULL;
 
-	if (mmc_of_parse_voltage(mmc, &oms->pdata.ocr_mask) <= 0)
+	if (mmc_of_parse_voltage(mmc, &oms->pdata.ocr_mask) < 0)
 		goto err_ocr;
 
 	oms->detect_irq = irq_of_parse_and_map(np, 0);
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Mon Apr 19 12:24:58 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 14:24:58 +0300
Subject: [PATCH v1 5/6] mmc: mmc_spi: Use already parsed IRQ
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210419112459.25241-5-andriy.shevchenko@linux.intel.com>

SPI core already parses and maps IRQ for us if provided.
Use it instead of double parsing in mmc_spi_get_pdata().

Due to above, change condition, since SPI core can hold
an error pointer as invalid IRQ.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/mmc/host/of_mmc_spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index 0b038f5c392a..009c3885f6ba 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -64,8 +64,8 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct spi_device *spi)
 	if (mmc_of_parse_voltage(mmc, &oms->pdata.ocr_mask) < 0)
 		goto err_ocr;
 
-	oms->detect_irq = irq_of_parse_and_map(np, 0);
-	if (oms->detect_irq != 0) {
+	oms->detect_irq = spi->irq;
+	if (oms->detect_irq > 0) {
 		oms->pdata.init = of_mmc_spi_init;
 		oms->pdata.exit = of_mmc_spi_exit;
 	} else {
-- 
2.30.2



From willy at infradead.org  Mon Apr 19 12:43:17 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 19 Apr 2021 12:43:17 +0100
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <YH1PE4oWeicpJT9g@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <3b30ac54-8a92-5f54-28f0-f110a40700c7@redhat.com>
 <YH1PE4oWeicpJT9g@kernel.org>
Message-ID: <20210419114317.GY2531743@casper.infradead.org>

On Mon, Apr 19, 2021 at 12:36:19PM +0300, Mike Rapoport wrote:
> Well, most if the -4.2% of the performance regression kbuild reported were
> due to repeated compount_head(page) in page_mapping(). So the whole point
> of this patch is to avoid calling page_mapping().

It's quite ludicrous how many times we call compound_head() in
page_mapping() today:

 page = compound_head(page);
 if (__builtin_expect(!!(PageSlab(page)), 0))
 if (__builtin_expect(!!(PageSwapCache(page)), 0)) {

TESTPAGEFLAG(Slab, slab, PF_NO_TAIL) expands to:

static __always_inline int PageSlab(struct page *page)
{
	PF_POISONED_CHECK(compound_head(page));
	return test_bit(PG_slab, &compound_head(page));
}

static __always_inline int PageSwapCache(struct page *page)
{
        page = compound_head(page);
        return PageSwapBacked(page) && test_bit(PG_swapcache, &page->flags);
}

but then!

TESTPAGEFLAG(SwapBacked, swapbacked, PF_NO_TAIL) also expands like Slab does.

So that's six calls to compound_head(), depending what Kconfig options
you have enabled.

And folio_mapping() is one of the functions I add in the first batch of
patches, so review, etc will be helpful.


From jan.kiszka at web.de  Mon Apr 19 12:48:45 2021
From: jan.kiszka at web.de (Jan Kiszka)
Date: Mon, 19 Apr 2021 13:48:45 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <2f2e3019-afdd-103f-b984-06e65b10fc50@xilinx.com>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
 <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
 <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>
 <2f2e3019-afdd-103f-b984-06e65b10fc50@xilinx.com>
Message-ID: <5176e9bc-50a0-6952-0e5a-8e43095235eb@web.de>

On 19.04.21 12:52, Michal Simek wrote:
> Hi Jan,
>
> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>> On 01.04.21 16:52, Jan Kiszka wrote:
>>> On 01.04.21 13:42, Michal Simek wrote:
>>>> Hi Jan,
>>>>
>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>
>>>>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>>>>> ---
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>> new file mode 100644
>>>>>> index 0000000..9868ca1
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>> @@ -0,0 +1,222 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>> +/*
>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>> + *
>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>> + *
>>>>>> + * Michal Simek <michal.simek at xilinx.com>
>>>>>> + */
>>>>>> +
>>>>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>>>>> +/ {
>>>>>> +	pss_ref_clk: pss_ref_clk {
>>>>>> +		u-boot,dm-pre-reloc;
>>>>>> +		compatible = "fixed-clock";
>>>>>> +		#clock-cells = <0>;
>>>>>> +		clock-frequency = <33333333>;
>>>>>> +	};
>>>>>> +
>>>>>> +	video_clk: video_clk {
>>>>>> +		u-boot,dm-pre-reloc;
>>>>>> +		compatible = "fixed-clock";
>>>>>> +		#clock-cells = <0>;
>>>>>> +		clock-frequency = <27000000>;
>>>>>> +	};
>>>>>> +
>>>>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>> +		u-boot,dm-pre-reloc;
>>>>>> +		compatible = "fixed-clock";
>>>>>> +		#clock-cells = <0>;
>>>>>> +		clock-frequency = <0>;
>>>>>> +	};
>>>>>> +
>>>>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>> +		u-boot,dm-pre-reloc;
>>>>>> +		compatible = "fixed-clock";
>>>>>> +		#clock-cells = <0>;
>>>>>> +		clock-frequency = <108000000>;
>>>>>> +	};
>>>>>> +
>>>>>> +	aux_ref_clk: aux_ref_clk {
>>>>>> +		u-boot,dm-pre-reloc;
>>>>>> +		compatible = "fixed-clock";
>>>>>> +		#clock-cells = <0>;
>>>>>> +		clock-frequency = <27000000>;
>>>>>> +	};
>>>>>> +};
>>>>>> +
>>>>>> +&can0 {
>>>>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&can1 {
>>>>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&cpu0 {
>>>>>> +	clocks = <&zynqmp_clk ACPU>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan1 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan2 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan3 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan4 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan5 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan6 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan7 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&fpd_dma_chan8 {
>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan1 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan2 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan3 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan4 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan5 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan6 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan7 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&lpd_dma_chan8 {
>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&gem0 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>>>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>> +};
>>>>>> +
>>>>>> +&gem1 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>>>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>> +};
>>>>>> +
>>>>>> +&gem2 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>>>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>> +};
>>>>>> +
>>>>>> +&gem3 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>>>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>> +};
>>>>>> +
>>>>>> +&gpio {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&i2c0 {
>>>>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&i2c1 {
>>>>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&pcie {
>>>>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&sata {
>>>>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&sdhci0 {
>>>>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&sdhci1 {
>>>>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&spi0 {
>>>>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&spi1 {
>>>>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&ttc0 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&ttc1 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&ttc2 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&ttc3 {
>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&uart0 {
>>>>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&uart1 {
>>>>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>> +};
>>>>>> +
>>>>>> +&usb0 {
>>>>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&usb1 {
>>>>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>> +};
>>>>>> +
>>>>>> +&watchdog0 {
>>>>>> +	clocks = <&zynqmp_clk WDT>;
>>>>>> +};
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>> index 0f7b4cf..2e05fa4 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZC1232
>>>>>>   *
>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>
>>>>>>  / {
>>>>>>  	model = "ZynqMP ZC1232 RevA";
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>> index 9092828..3d0aaa0 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZC1254
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>>>> @@ -11,7 +11,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>
>>>>>>  / {
>>>>>>  	model = "ZynqMP ZC1254 RevA";
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>> index 4f404c5..1a8127d4 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>> @@ -11,7 +11,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>
>>>>>>  / {
>>>>>>  	model = "ZynqMP ZC1275 RevA";
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>> index 9a3e39d..fa7eb1b 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>>  / {
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>> index 2421ec7..4191dfa 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>>  / {
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>> index 7a49dee..3750690 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>>>>   *
>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>
>>>>>>  / {
>>>>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>> index 54c7b4f..2366cd9 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>
>>>>>>  / {
>>>>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>> index b8b5ff1..9a894e6 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>> @@ -11,7 +11,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>>  / {
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>> index e5699d0..3e39454 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>>>>   *
>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   * Nathalie Chan King Choy
>>>>>> @@ -11,7 +11,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>> index 2a3b665..f6e9558 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>>>>   *
>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>> index 8f45614..f457f8a 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZCU104
>>>>>>   *
>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>>  / {
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>> index 93ce7eb..f15b99a 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZCU106
>>>>>>   *
>>>>>> - * (C) Copyright 2016, Xilinx, Inc.
>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>> index 8bb0001..e27cd60 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP ZCU111
>>>>>>   *
>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   */
>>>>>> @@ -10,7 +10,7 @@
>>>>>>  /dts-v1/;
>>>>>>
>>>>>>  #include "zynqmp.dtsi"
>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> index 9aa6734..59a547b 100644
>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>> @@ -2,7 +2,7 @@
>>>>>>  /*
>>>>>>   * dts file for Xilinx ZynqMP
>>>>>>   *
>>>>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>>>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>>>>   *
>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>   *
>>>>>> @@ -124,6 +124,28 @@
>>>>>>  			     <1 10 0xf08>;
>>>>>>  	};
>>>>>>
>>>>>> +	firmware {
>>>>>> +		zynqmp_firmware: zynqmp-firmware {
>>>>>> +			compatible = "xlnx,zynqmp-firmware";
>>>>>> +			method = "smc";
>>>>>> +			zynqmp_clk: clock-controller {
>>>>>> +				u-boot,dm-pre-reloc;
>>>>>> +				#clock-cells = <1>;
>>>>>> +				compatible = "xlnx,zynqmp-clk";
>>>>>> +				clocks = <&pss_ref_clk>,
>>>>>> +					 <&video_clk>,
>>>>>> +					 <&pss_alt_ref_clk>,
>>>>>> +					 <&aux_ref_clk>,
>>>>>> +					 <&gt_crx_ref_clk>;
>>>>>> +				clock-names = "pss_ref_clk",
>>>>>> +					      "video_clk",
>>>>>> +					      "pss_alt_ref_clk",
>>>>>> +					      "aux_ref_clk",
>>>>>> +					      "gt_crx_ref_clk";
>>>>>> +			};
>>>>>> +		};
>>>>>> +	};
>>>>>> +
>>>>>>  	amba_apu: amba-apu at 0 {
>>>>>>  		compatible = "simple-bus";
>>>>>>  		#address-cells = <2>;
>>>>>>
>>>>>
>>>>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>>>>> Starting from this commit on, I'm no longer getting the kernel to boot
>>>>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>>>>> DTBs back before this commit, even a kernel from today's head is fine.
>>>>>
>>>>> Further versions of potential relevance:
>>>>>  - PMUFW 2019.1 and 2020.2
>>>>>  - TF-A 2.3
>>>>>  - U-Boot 2020.10
>>>>>
>>>>> What's missing? I suspect someone forgot to document a subtle dependency
>>>>> of this change.
>>>>
>>>> Does this fix your issue?
>>>> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>>>>
>>>
>>> Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
>>> missing even more. If you have some reference, I'm happy to try. I
>>> suspect that earlyprintk will also not reveal more without clocks (but I
>>> didn't play with that yet).
>>>
>>> Meanwhile, I'm carrying a revert of this commit and a related cleanup.
>>> That helps for now.
>>>
>>
>> OK, dependencies resolved (unfortunately the hard way): It either
>> requires TF-A master or latest release v2.4 + [1] and [2].
>>
>> Those TF-A commits were upstream about a year after the firmware-based
>> clock control hit the kernel. A note would have been nice - or better
>> sychronization between both upstreaming efforts.
>
> I wasn't responsible for TFA but I found this last year in Nov timeframe
> that none really upstream this. Right now that development is working
> like that. I am asking everybody to contribute upstream to have all the
> time upstream heads to work together.
> I haven't had a time to dig into this but unfortunatelly there is no
> feature checking mechanism on zynqmp TFA side to check if this is there
> or not but we are trying our best to check as much as possible but bugs
> happen.

OK, I understand. Reminding of "upstream first" is part of my daily
business as well. :)

And integration is generally more and more complicated with the growing
number of firmware services and interfaces, not only on this SOC...

> And we are lacking space in OCM to be able to add more features to TFA
> anyway.

Yeah, I know - I'm also overflowing it via the SDEI patch [1].

Jan

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9673


From rppt at kernel.org  Mon Apr 19 12:56:17 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 19 Apr 2021 14:56:17 +0300
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210419112302.GX2531743@casper.infradead.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <20210419112302.GX2531743@casper.infradead.org>
Message-ID: <YH1v4XVzfXC1dYND@kernel.org>

On Mon, Apr 19, 2021 at 12:23:02PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 11:42:18AM +0300, Mike Rapoport wrote:
> > The perf profile of the test indicated that the regression is caused by
> > page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):
> 
> Uhh ... you're calling it in the wrong place!
> 
>                 VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
>                 page = pte_page(pte);
> 
>                 if (page_is_secretmem(page))
>                         goto pte_unmap;
> 
>                 head = try_grab_compound_head(page, 1, flags);
>                 if (!head)
>                         goto pte_unmap;
> 
> So you're calling page_is_secretmem() on a struct page without having
> a refcount on it.  That is definitely not allowed.  secretmem seems to
> be full of these kinds of races; I know this isn't the first one I've
> seen in it.  I don't think this patchset is ready for this merge window.

There were races in the older version that did caching of large pages and
those were fixed then, but this is anyway irrelevant because all that code
was dropped in the latest respins.

I don't think that the fix of the race in gup_pte_range is that significant
to wait 3 more months because of it.
 
> With that fixed, you'll have a head page that you can use for testing,
> which means you don't need to test PageCompound() (because you know the
> page isn't PageTail), you can just test PageHead().

I can't say I follow you here. page_is_secretmem() is intended to be a
generic test, so I don't see how it will get PageHead() if it is called
from other places.

-- 
Sincerely yours,
Mike.


From andrew at lunn.ch  Mon Apr 19 13:15:12 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 19 Apr 2021 14:15:12 +0200
Subject: [PATCH net-next 2/2] net: ethernet: mediatek: support custom
 GMAC label
In-Reply-To: <20210419040352.2452-3-ilya.lipnitskiy@gmail.com>
References: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
 <20210419040352.2452-3-ilya.lipnitskiy@gmail.com>
Message-ID: <YH10UNuJZ5s7dfLh@lunn.ch>

On Sun, Apr 18, 2021 at 09:03:52PM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
> 
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
> 
> Suggested-by: Ren? van Dorst <opensource at vdorst.com>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 6b00c12c6c43..4c0ce4fb7735 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
>  
>  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
>  {
> +	const char *label = of_get_property(np, "label", NULL);
>  	const __be32 *_id = of_get_property(np, "reg", NULL);
>  	phy_interface_t phy_mode;
>  	struct phylink *phylink;
> @@ -2940,6 +2941,9 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
>  	else
>  		eth->netdev[id]->max_mtu = MTK_MAX_RX_LENGTH_2K - MTK_RX_ETH_HLEN;
>  
> +	if (label)
> +		strscpy(eth->netdev[id]->name, label, IFNAMSIZ);

It is better to use alloc_netdev_mqs() so you get validation the name
is unique.

   Andrew


From patrice.chotard at foss.st.com  Mon Apr 19 13:15:39 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 19 Apr 2021 14:15:39 +0200
Subject: [PATCH 1/3] spi: stm32-qspi: fix pm_runtime usage_count counter
In-Reply-To: <20210419121541.11617-1-patrice.chotard@foss.st.com>
References: <20210419121541.11617-1-patrice.chotard@foss.st.com>
Message-ID: <20210419121541.11617-2-patrice.chotard@foss.st.com>

From: Christophe Kerello <christophe.kerello at foss.st.com>

pm_runtime usage_count counter is not well managed.
pm_runtime_put_autosuspend callback drops the usage_counter but this
one has never been increased. Add pm_runtime_get_sync callback to bump up
the usage counter. It is also needed to use pm_runtime_force_suspend and
pm_runtime_force_resume APIs to handle properly the clock.

Fixes: 9d282c17b023 ("spi: stm32-qspi: Add pm_runtime support")
Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Cc: stable at vger.kernel.org
---
 drivers/spi/spi-stm32-qspi.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 947e6b9dc9f4..2786470a5201 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -727,21 +727,31 @@ static int __maybe_unused stm32_qspi_suspend(struct device *dev)
 {
 	pinctrl_pm_select_sleep_state(dev);
 
-	return 0;
+	return pm_runtime_force_suspend(dev);
 }
 
 static int __maybe_unused stm32_qspi_resume(struct device *dev)
 {
 	struct stm32_qspi *qspi = dev_get_drvdata(dev);
+	int ret;
+
+	ret = pm_runtime_force_resume(dev);
+	if (ret < 0)
+		return ret;
 
 	pinctrl_pm_select_default_state(dev);
-	clk_prepare_enable(qspi->clk);
+
+	ret = pm_runtime_get_sync(dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(dev);
+		return ret;
+	}
 
 	writel_relaxed(qspi->cr_reg, qspi->io_base + QSPI_CR);
 	writel_relaxed(qspi->dcr_reg, qspi->io_base + QSPI_DCR);
 
-	pm_runtime_mark_last_busy(qspi->dev);
-	pm_runtime_put_autosuspend(qspi->dev);
+	pm_runtime_mark_last_busy(dev);
+	pm_runtime_put_autosuspend(dev);
 
 	return 0;
 }
-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 19 13:15:40 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 19 Apr 2021 14:15:40 +0200
Subject: [PATCH 2/3] spi: stm32-qspi: Trigger DMA only if more than 4 bytes to
 transfer
In-Reply-To: <20210419121541.11617-1-patrice.chotard@foss.st.com>
References: <20210419121541.11617-1-patrice.chotard@foss.st.com>
Message-ID: <20210419121541.11617-3-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

In order to optimize accesses to spi flashes, trigger a DMA only
if more than 4 bytes has to be transferred.

DMA transfer preparation's cost becomes negligible above 4 bytes to
transfer. Below this threshold, indirect transfer give more throughput.

mtd_speedtest shows that page write throughtput increases :
  - from 779 to 853 KiB/s (~9.5%) with s25fl512s SPI-NOR.
  - from 5283 to 5666 KiB/s (~7.25%) with Micron SPI-NAND.

Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/spi/spi-stm32-qspi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 2786470a5201..6e74d6bed54c 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -269,8 +269,9 @@ static int stm32_qspi_tx(struct stm32_qspi *qspi, const struct spi_mem_op *op)
 
 	if (qspi->fmode == CCR_FMODE_MM)
 		return stm32_qspi_tx_mm(qspi, op);
-	else if ((op->data.dir == SPI_MEM_DATA_IN && qspi->dma_chrx) ||
-		 (op->data.dir == SPI_MEM_DATA_OUT && qspi->dma_chtx))
+	else if (((op->data.dir == SPI_MEM_DATA_IN && qspi->dma_chrx) ||
+		 (op->data.dir == SPI_MEM_DATA_OUT && qspi->dma_chtx)) &&
+		  op->data.nbytes > 4)
 		if (!stm32_qspi_tx_dma(qspi, op))
 			return 0;
 
-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 19 13:15:38 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 19 Apr 2021 14:15:38 +0200
Subject: [PATCH 0/3]  spi: stm32-qspi: Fix and update
Message-ID: <20210419121541.11617-1-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

Christophe Kerello (1):
  spi: stm32-qspi: fix pm_runtime usage_count counter

Patrice Chotard (2):
  spi: stm32-qspi: Trigger DMA only if more than 4 bytes to transfer
  spi: stm32-qspi: Add dirmap support

 drivers/spi/spi-stm32-qspi.c | 106 +++++++++++++++++++++++++++--------
 1 file changed, 84 insertions(+), 22 deletions(-)

-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 19 13:15:41 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 19 Apr 2021 14:15:41 +0200
Subject: [PATCH 3/3] spi: stm32-qspi: Add dirmap support
In-Reply-To: <20210419121541.11617-1-patrice.chotard@foss.st.com>
References: <20210419121541.11617-1-patrice.chotard@foss.st.com>
Message-ID: <20210419121541.11617-4-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

Add stm32_qspi_dirmap_read() and stm32_qspi_dirmap_create()
to get dirmap support.

Update the exec_op callback which doens't allow anymore memory map
access. Memory map access are only available through the dirmap_read
callback.

Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/spi/spi-stm32-qspi.c | 83 +++++++++++++++++++++++++++++-------
 1 file changed, 67 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 6e74d6bed54c..e2a99f054551 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -331,7 +331,7 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 {
 	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
 	struct stm32_qspi_flash *flash = &qspi->flash[mem->spi->chip_select];
-	u32 ccr, cr, addr_max;
+	u32 ccr, cr;
 	int timeout, err = 0;
 
 	dev_dbg(qspi->dev, "cmd:%#x mode:%d.%d.%d.%d addr:%#llx len:%#x\n",
@@ -343,18 +343,6 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 	if (err)
 		goto abort;
 
-	addr_max = op->addr.val + op->data.nbytes + 1;
-
-	if (op->data.dir == SPI_MEM_DATA_IN) {
-		if (addr_max < qspi->mm_size &&
-		    op->addr.buswidth)
-			qspi->fmode = CCR_FMODE_MM;
-		else
-			qspi->fmode = CCR_FMODE_INDR;
-	} else {
-		qspi->fmode = CCR_FMODE_INDW;
-	}
-
 	cr = readl_relaxed(qspi->io_base + QSPI_CR);
 	cr &= ~CR_PRESC_MASK & ~CR_FSEL;
 	cr |= FIELD_PREP(CR_PRESC_MASK, flash->presc);
@@ -364,8 +352,6 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 	if (op->data.nbytes)
 		writel_relaxed(op->data.nbytes - 1,
 			       qspi->io_base + QSPI_DLR);
-	else
-		qspi->fmode = CCR_FMODE_INDW;
 
 	ccr = qspi->fmode;
 	ccr |= FIELD_PREP(CCR_INST_MASK, op->cmd.opcode);
@@ -441,6 +427,11 @@ static int stm32_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
 	}
 
 	mutex_lock(&qspi->lock);
+	if (op->data.dir == SPI_MEM_DATA_IN && op->data.nbytes)
+		qspi->fmode = CCR_FMODE_INDR;
+	else
+		qspi->fmode = CCR_FMODE_INDW;
+
 	ret = stm32_qspi_send(mem, op);
 	mutex_unlock(&qspi->lock);
 
@@ -450,6 +441,64 @@ static int stm32_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
 	return ret;
 }
 
+static int stm32_qspi_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+	struct stm32_qspi *qspi = spi_controller_get_devdata(desc->mem->spi->master);
+
+	if (desc->info.op_tmpl.data.dir == SPI_MEM_DATA_OUT)
+		return -EOPNOTSUPP;
+
+	/* should never happen, as mm_base == null is an error probe exit condition */
+	if (!qspi->mm_base && desc->info.op_tmpl.data.dir == SPI_MEM_DATA_IN)
+		return -EOPNOTSUPP;
+
+	if (!qspi->mm_size)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
+static ssize_t stm32_qspi_dirmap_read(struct spi_mem_dirmap_desc *desc,
+				      u64 offs, size_t len, void *buf)
+{
+	struct stm32_qspi *qspi = spi_controller_get_devdata(desc->mem->spi->master);
+	struct spi_mem_op op;
+	u32 addr_max;
+	int ret;
+
+	ret = pm_runtime_get_sync(qspi->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(qspi->dev);
+		return ret;
+	}
+
+	mutex_lock(&qspi->lock);
+	/* make a local copy of desc op_tmpl and complete dirmap rdesc
+	 * spi_mem_op template with offs, len and *buf in  order to get
+	 * all needed transfer information into struct spi_mem_op
+	 */
+	memcpy(&op, &desc->info.op_tmpl, sizeof(struct spi_mem_op));
+	dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
+
+	op.data.nbytes = len;
+	op.addr.val = desc->info.offset + offs;
+	op.data.buf.in = buf;
+
+	addr_max = op.addr.val + op.data.nbytes + 1;
+	if (addr_max < qspi->mm_size && op.addr.buswidth)
+		qspi->fmode = CCR_FMODE_MM;
+	else
+		qspi->fmode = CCR_FMODE_INDR;
+
+	ret = stm32_qspi_send(desc->mem, &op);
+	mutex_unlock(&qspi->lock);
+
+	pm_runtime_mark_last_busy(qspi->dev);
+	pm_runtime_put_autosuspend(qspi->dev);
+
+	return ret ?: len;
+}
+
 static int stm32_qspi_setup(struct spi_device *spi)
 {
 	struct spi_controller *ctrl = spi->master;
@@ -555,7 +604,9 @@ static void stm32_qspi_dma_free(struct stm32_qspi *qspi)
  * to check supported mode.
  */
 static const struct spi_controller_mem_ops stm32_qspi_mem_ops = {
-	.exec_op = stm32_qspi_exec_op,
+	.exec_op	= stm32_qspi_exec_op,
+	.dirmap_create	= stm32_qspi_dirmap_create,
+	.dirmap_read	= stm32_qspi_dirmap_read,
 };
 
 static int stm32_qspi_probe(struct platform_device *pdev)
-- 
2.17.1



From will at kernel.org  Mon Apr 19 13:19:33 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 19 Apr 2021 13:19:33 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210416133431.GA2303@C02TD0UTHF1T.local>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <20210416133431.GA2303@C02TD0UTHF1T.local>
Message-ID: <20210419121932.GA30004@willie-the-truck>

On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> On Fri, Apr 16, 2021 at 01:33:22PM +0100, Catalin Marinas wrote:
> > On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> > > The general version of is_syscall_success does not handle 32-bit
> > > compatible case, which would cause 32-bit negative return code to be
> > > recoganized as a positive number later and seen as a "success".
> > > 
> > > Since is_compat_thread is defined in compat.h, implementing
> > > is_syscall_success in ptrace.h would introduce build failure due to
> > > recursive inclusion of some basic headers like mutex.h. We put the
> > > implementation to ptrace.c
> > > 
> > > Signed-off-by: He Zhe <zhe.he at windriver.com>
> > > ---
> > >  arch/arm64/include/asm/ptrace.h |  3 +++
> > >  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
> > >  2 files changed, 13 insertions(+)
> > > 
> > > diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> > > index e58bca832dff..3c415e9e5d85 100644
> > > --- a/arch/arm64/include/asm/ptrace.h
> > > +++ b/arch/arm64/include/asm/ptrace.h
> > > @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> > >  	regs->regs[0] = rc;
> > >  }
> > >  
> > > +extern inline int is_syscall_success(struct pt_regs *regs);
> > > +#define is_syscall_success(regs) is_syscall_success(regs)
> > > +
> > >  /**
> > >   * regs_get_kernel_argument() - get Nth function argument in kernel
> > >   * @regs:	pt_regs of that context
> > > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > > index 170f42fd6101..3266201f8c60 100644
> > > --- a/arch/arm64/kernel/ptrace.c
> > > +++ b/arch/arm64/kernel/ptrace.c
> > > @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> > >  	else
> > >  		return valid_native_regs(regs);
> > >  }
> > > +
> > > +inline int is_syscall_success(struct pt_regs *regs)
> > > +{
> > > +	unsigned long val = regs->regs[0];
> > > +
> > > +	if (is_compat_thread(task_thread_info(current)))
> > > +		val = sign_extend64(val, 31);
> > > +
> > > +	return !IS_ERR_VALUE(val);
> > > +}
> > 
> > It's better to use compat_user_mode(regs) here instead of
> > is_compat_thread(). It saves us from worrying whether regs are for the
> > current context.
> > 
> > I think we should change regs_return_value() instead. This function
> > seems to be called from several other places and it has the same
> > potential problems if called on compat pt_regs.
> 
> I think this is a problem we created for ourselves back in commit:
> 
>   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
> 
> AFAICT, the perf regs samples are the only place this matters, since for
> ptrace the compat regs are implicitly truncated to compat_ulong_t, and
> audit expects the non-truncated return value. Other architectures don't
> truncate here, so I think we're setting ourselves up for a game of
> whack-a-mole to truncate and extend wherever we need to.
> 
> Given that, I suspect it'd be better to do something like the below.
> 
> Will, thoughts?

I think perf is one example, but this is also visible to userspace via the
native ptrace interface and I distinctly remember needing this for some
versions of arm64 strace to work correctly when tracing compat tasks.

So I do think that clearing the upper bits on the return path is the right
approach, but it sounds like we need some more work to handle syscall(-1)
and audit (what exactly is the problem here after these patches have been
applied?)

Will


From willy at infradead.org  Mon Apr 19 13:21:56 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Mon, 19 Apr 2021 13:21:56 +0100
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <YH1v4XVzfXC1dYND@kernel.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <20210419112302.GX2531743@casper.infradead.org>
 <YH1v4XVzfXC1dYND@kernel.org>
Message-ID: <20210419122156.GZ2531743@casper.infradead.org>

On Mon, Apr 19, 2021 at 02:56:17PM +0300, Mike Rapoport wrote:
> On Mon, Apr 19, 2021 at 12:23:02PM +0100, Matthew Wilcox wrote:
> > So you're calling page_is_secretmem() on a struct page without having
> > a refcount on it.  That is definitely not allowed.  secretmem seems to
> > be full of these kinds of races; I know this isn't the first one I've
> > seen in it.  I don't think this patchset is ready for this merge window.
> 
> There were races in the older version that did caching of large pages and
> those were fixed then, but this is anyway irrelevant because all that code
> was dropped in the latest respins.
> 
> I don't think that the fix of the race in gup_pte_range is that significant
> to wait 3 more months because of it.

I have no particular interest in secretmem, but it seems that every time
I come across it while looking at something else, I see these kinds of
major mistakes in it.  That says to me it's not ready and hasn't seen
enough review.

> > With that fixed, you'll have a head page that you can use for testing,
> > which means you don't need to test PageCompound() (because you know the
> > page isn't PageTail), you can just test PageHead().
> 
> I can't say I follow you here. page_is_secretmem() is intended to be a
> generic test, so I don't see how it will get PageHead() if it is called
> from other places.

static inline bool head_is_secretmem(struct page *head)
{
	if (PageHead(head))
		return false;
	...
}

static inline bool page_is_secretmem(struct page *page)
{
	if (PageTail(page))
		return false;
	return head_is_secretmem(page);
}

(yes, calling it head is a misnomer, because it's not necessarily a head,
it might be a base page, but until we have a name for pages which might
be a head page or a base page, it'll have to do ...)


From RAJANV at xilinx.com  Mon Apr 19 13:29:34 2021
From: RAJANV at xilinx.com (Rajan Vaja)
Date: Mon, 19 Apr 2021 12:29:34 +0000
Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
 PM_INIT_FINALIZE
In-Reply-To: <20210419073239.GA12636@pengutronix.de>
References: <20210317160410.2097178-1-m.tretter@pengutronix.de>
 <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>
 <20210419073239.GA12636@pengutronix.de>
Message-ID: <BYAPR02MB3941CFEEF4C3D647C6315B3BB7499@BYAPR02MB3941.namprd02.prod.outlook.com>

Hi Michal,

> -----Original Message-----
> From: Michael Tretter <m.tretter at pengutronix.de>
> Sent: 19 April 2021 01:03 PM
> To: Rajan Vaja <RAJANV at xilinx.com>
> Cc: linux-arm-kernel at lists.infradead.org; Michal Simek <michals at xilinx.com>; Jolly
> Shah <JOLLYS at xilinx.com>
> Subject: Re: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
> PM_INIT_FINALIZE
> 
> Hi Rajan,
> 
> On Thu, 15 Apr 2021 16:27:58 +0000, Rajan Vaja wrote:
> > Thanks for the patch.
> >
> > > -----Original Message-----
> > > From: Michael Tretter <m.tretter at pengutronix.de>
> > > Sent: 17 March 2021 09:34 PM
> > > To: linux-arm-kernel at lists.infradead.org
> > > Cc: Michal Simek <michals at xilinx.com>; Rajan Vaja <RAJANV at xilinx.com>; Jolly
> > > Shah <JOLLYS at xilinx.com>; m.tretter at pengutronix.de
> > > Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
> PM_INIT_FINALIZE
> > >
> > > Patch 1 of this series fixes the ZynqMP PMU FW power management
> > > initialization, which was done by the wrong driver. PM_INIT_FINALIZE must be
> > > called from the zynqmp_pm_domains driver, which handles power domains,
> instead
> > > of the zynmp_power driver, which is responsible for suspend and shutdown.
> > [Rajan] I am fine with moving to genpd but zynqmp_pm_init_finalize() needs to
> be late call.
> > zynqmp_pm_init_finalize() should be called when Linux has requested all the
> devices through
> > genpd driver. Making it late call will make sure it.
> 
> What is the reason why all devices have to be requested before calling
> zynqmp_pm_init_finalize()?
[Rajan] This is required if device is not to be powered down. If zynqmp_pm_init_finalize()
Is called before requesting, device may go power down. So settings done in probe() may be
lost. In this case, driver needs to do config during runtime resume. However, some driver
may not do all config during runtime resume which may not work.

> 
> I was expecting that calling PM_INIT_FINALIZE only would tell the PMU_FW that
> Linux is using the PM API and the PMU_FW should power down/up PM slaves as
> requested by Linux. It is somewhat surprising that this isn't the case and all
> PM slaves have to be powered up before calling PM_INIT_FINALIZE.
[Rajan] Basically PMUFW will do power up/down as per request. However, device
config may be lost due to this power down. So device driver mat need to take care
during runtime suspend/resume



> 
> What would happen if some driver is built as a module? In that case, the
> module would be loaded and request the pm node only after PM_INIT_FINALIZE
> was
> called. Do we have to avoid/disallow such cases?
[Rajan] We allow that. When driver is init, it needs to setup device which will be fine
As probe do most of settings.

> 
> For USB, I am actually observing a similar situation: If I do not request the
> USB PM slave before I call PM_INIT_FINALIZE, I see communication errors with
> connected USB devices. Could this be related?
[Rajan] Yes, device config might have lost due to power down because of init finalize call.

Thanks,
Rajan

> 
> Thanks,
> 
> Michael
> 
> >
> > >
> > > Patches 2 to 4 are various cleanup patches to improve the readability and
> > > debugging experience of the zynqmp_pm_domains driver.
> > >
> > > Michael
> > >
> > > Michael Tretter (4):
> > >   soc: xilinx: move PM_INIT_FINALIZE to zynqmp_pm_domains driver
> > >   soc: xilinx: cleanup debug and error messages
> > >   soc: xilinx: use a properly named field instead of flags
> > >   soc: xilinx: add a to_zynqmp_pm_domain macro
> > >
> > >  drivers/soc/xilinx/zynqmp_pm_domains.c | 79 +++++++++++++-------------
> > >  drivers/soc/xilinx/zynqmp_power.c      |  1 -
> > >  2 files changed, 38 insertions(+), 42 deletions(-)
> > >
> > > --
> > > 2.29.2

From will at kernel.org  Mon Apr 19 13:33:19 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 19 Apr 2021 13:33:19 +0100
Subject: [PATCH V6 1/4] arch_topology: Rename freq_scale as arch_freq_scale
In-Reply-To: <2dd2c60c0268550f566c3c83d06b651b4f0e9e4e.1615351622.git.viresh.kumar@linaro.org>
References: <cover.1615351622.git.viresh.kumar@linaro.org>
 <2dd2c60c0268550f566c3c83d06b651b4f0e9e4e.1615351622.git.viresh.kumar@linaro.org>
Message-ID: <20210419123318.GA30124@willie-the-truck>

On Wed, Mar 10, 2021 at 10:53:23AM +0530, Viresh Kumar wrote:
> Rename freq_scale to a less generic name, as it will get exported soon
> for modules. Since x86 already names its own implementation of this as
> arch_freq_scale, lets stick to that.
> 
> Suggested-by: Will Deacon <will at kernel.org>
> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
> ---
>  arch/arm64/kernel/topology.c  | 6 +++---
>  drivers/base/arch_topology.c  | 4 ++--
>  include/linux/arch_topology.h | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From ulf.hansson at linaro.org  Mon Apr 19 13:59:45 2021
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 19 Apr 2021 14:59:45 +0200
Subject: [PATCH v1 1/6] mmc: core: Correct descriptions in mmc_of_parse()
In-Reply-To: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
References: <20210419112459.25241-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CAPDyKFoizAhKxfzMzTBdQe6J5rYPLTbBTbn5nM4WAB1QGn9VUw@mail.gmail.com>

On Mon, 19 Apr 2021 at 13:24, Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> Since it has been converted to use device property API, the function
> and field descriptions become outdated. Correct them.
>
> Fixes: 73a47a9bb3e2 ("mmc: core: Use device_property_read instead of of_property_read")
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Series applied for next, thanks!

Kind regards
Uffe

> ---
>  drivers/mmc/core/host.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> index 9b89a91b6b47..ce030c5aa53c 100644
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -209,8 +209,8 @@ mmc_of_parse_clk_phase(struct mmc_host *host, struct mmc_clk_phase_map *map)
>  EXPORT_SYMBOL(mmc_of_parse_clk_phase);
>
>  /**
> - *     mmc_of_parse() - parse host's device-tree node
> - *     @host: host whose node should be parsed.
> + * mmc_of_parse() - parse host's device properties
> + * @host: host whose properties should be parsed.
>   *
>   * To keep the rest of the MMC subsystem unaware of whether DT has been
>   * used to to instantiate and configure this host instance or not, we
> --
> 2.30.2
>


From o.rempel at pengutronix.de  Mon Apr 19 14:01:01 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:01 +0200
Subject: [PATCH net-next v3 1/6] net: phy: execute genphy_loopback() per
 default on all PHYs
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-2-o.rempel@pengutronix.de>

The generic loopback is really generic and is defined by the 802.3
standard, we should just mandate that drivers implement a custom
loopback if the generic one cannot work.

Suggested-by: Florian Fainelli <f.fainelli at gmail.com>
Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/phy/phy_device.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 73d29fd5e03d..320a3e5cd10a 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1777,6 +1777,9 @@ int phy_loopback(struct phy_device *phydev, bool enable)
 	struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
 	int ret = 0;
 
+	if (!phydrv)
+		return -ENODEV;
+
 	mutex_lock(&phydev->lock);
 
 	if (enable && phydev->loopback_enabled) {
@@ -1789,10 +1792,10 @@ int phy_loopback(struct phy_device *phydev, bool enable)
 		goto out;
 	}
 
-	if (phydev->drv && phydrv->set_loopback)
+	if (phydrv->set_loopback)
 		ret = phydrv->set_loopback(phydev, enable);
 	else
-		ret = -EOPNOTSUPP;
+		ret = genphy_loopback(phydev, enable);
 
 	if (ret)
 		goto out;
-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:05 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:05 +0200
Subject: [PATCH net-next v3 5/6] net: ag71xx: make use of generic
 NET_SELFTESTS library
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-6-o.rempel@pengutronix.de>

With this patch the ag71xx on Atheros AR9331 will able to run generic net
selftests.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/ethernet/atheros/Kconfig  |  1 +
 drivers/net/ethernet/atheros/ag71xx.c | 20 ++++++++++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/atheros/Kconfig b/drivers/net/ethernet/atheros/Kconfig
index fb803bf92ded..6842b74b0696 100644
--- a/drivers/net/ethernet/atheros/Kconfig
+++ b/drivers/net/ethernet/atheros/Kconfig
@@ -20,6 +20,7 @@ if NET_VENDOR_ATHEROS
 config AG71XX
 	tristate "Atheros AR7XXX/AR9XXX built-in ethernet mac support"
 	depends on ATH79
+	select NET_SELFTESTS
 	select PHYLINK
 	help
 	  If you wish to compile a kernel for AR7XXX/91XXX and enable
diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
index 7352f98123c7..eb067ce978ae 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -37,6 +37,7 @@
 #include <linux/reset.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <net/selftests.h>
 
 /* For our NAPI weight bigger does *NOT* mean better - it means more
  * D-cache misses and lots more wasted cycles than we'll ever
@@ -497,12 +498,17 @@ static int ag71xx_ethtool_set_pauseparam(struct net_device *ndev,
 static void ag71xx_ethtool_get_strings(struct net_device *netdev, u32 sset,
 				       u8 *data)
 {
-	if (sset == ETH_SS_STATS) {
-		int i;
+	int i;
 
+	switch (sset) {
+	case ETH_SS_STATS:
 		for (i = 0; i < ARRAY_SIZE(ag71xx_statistics); i++)
 			memcpy(data + i * ETH_GSTRING_LEN,
 			       ag71xx_statistics[i].name, ETH_GSTRING_LEN);
+		break;
+	case ETH_SS_TEST:
+		net_selftest_get_strings(data);
+		break;
 	}
 }
 
@@ -519,9 +525,14 @@ static void ag71xx_ethtool_get_stats(struct net_device *ndev,
 
 static int ag71xx_ethtool_get_sset_count(struct net_device *ndev, int sset)
 {
-	if (sset == ETH_SS_STATS)
+	switch (sset) {
+	case ETH_SS_STATS:
 		return ARRAY_SIZE(ag71xx_statistics);
-	return -EOPNOTSUPP;
+	case ETH_SS_TEST:
+		return net_selftest_get_count();
+	default:
+		return -EOPNOTSUPP;
+	}
 }
 
 static const struct ethtool_ops ag71xx_ethtool_ops = {
@@ -536,6 +547,7 @@ static const struct ethtool_ops ag71xx_ethtool_ops = {
 	.get_strings			= ag71xx_ethtool_get_strings,
 	.get_ethtool_stats		= ag71xx_ethtool_get_stats,
 	.get_sset_count			= ag71xx_ethtool_get_sset_count,
+	.self_test			= net_selftest,
 };
 
 static int ag71xx_mdio_wait_busy(struct ag71xx *ag)
-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:06 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:06 +0200
Subject: [PATCH net-next v3 6/6] net: dsa: enable selftest support for all
 switches by default
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-7-o.rempel@pengutronix.de>

Most of generic selftest should be able to work with probably all ethernet
controllers. The DSA switches are not exception, so enable it by default at
least for DSA.

This patch was tested with SJA1105 and AR9331.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 include/net/dsa.h |  2 ++
 net/dsa/Kconfig   |  1 +
 net/dsa/slave.c   | 21 +++++++++++++++++++++
 3 files changed, 24 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 57b2c49f72f4..b4f89522b545 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -577,6 +577,8 @@ struct dsa_switch_ops {
 					 int port, uint64_t *data);
 	void	(*get_stats64)(struct dsa_switch *ds, int port,
 				   struct rtnl_link_stats64 *s);
+	void	(*self_test)(struct dsa_switch *ds, int port,
+			     struct ethtool_test *etest, u64 *data);
 
 	/*
 	 * ethtool Wake-on-LAN
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 8746b07668ae..cbc2bd643ab2 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -9,6 +9,7 @@ menuconfig NET_DSA
 	select NET_SWITCHDEV
 	select PHYLINK
 	select NET_DEVLINK
+	select NET_SELFTESTS
 	help
 	  Say Y if you want to enable support for the hardware switches supported
 	  by the Distributed Switch Architecture.
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 995e0e16f295..e282b422f733 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -15,6 +15,7 @@
 #include <linux/mdio.h>
 #include <net/rtnetlink.h>
 #include <net/pkt_cls.h>
+#include <net/selftests.h>
 #include <net/tc_act/tc_mirred.h>
 #include <linux/if_bridge.h>
 #include <linux/if_hsr.h>
@@ -748,7 +749,10 @@ static void dsa_slave_get_strings(struct net_device *dev,
 		if (ds->ops->get_strings)
 			ds->ops->get_strings(ds, dp->index, stringset,
 					     data + 4 * len);
+	} else if (stringset ==  ETH_SS_TEST) {
+		net_selftest_get_strings(data);
 	}
+
 }
 
 static void dsa_slave_get_ethtool_stats(struct net_device *dev,
@@ -794,11 +798,27 @@ static int dsa_slave_get_sset_count(struct net_device *dev, int sset)
 			count += ds->ops->get_sset_count(ds, dp->index, sset);
 
 		return count;
+	} else if (sset ==  ETH_SS_TEST) {
+		return net_selftest_get_count();
 	}
 
 	return -EOPNOTSUPP;
 }
 
+static void dsa_slave_net_selftest(struct net_device *ndev,
+				   struct ethtool_test *etest, u64 *buf)
+{
+	struct dsa_port *dp = dsa_slave_to_port(ndev);
+	struct dsa_switch *ds = dp->ds;
+
+	if (ds->ops->self_test) {
+		ds->ops->self_test(ds, dp->index, etest, buf);
+		return;
+	}
+
+	net_selftest(ndev, etest, buf);
+}
+
 static void dsa_slave_get_wol(struct net_device *dev, struct ethtool_wolinfo *w)
 {
 	struct dsa_port *dp = dsa_slave_to_port(dev);
@@ -1630,6 +1650,7 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
 	.get_rxnfc		= dsa_slave_get_rxnfc,
 	.set_rxnfc		= dsa_slave_set_rxnfc,
 	.get_ts_info		= dsa_slave_get_ts_info,
+	.self_test		= dsa_slave_net_selftest,
 };
 
 /* legacy way, bypassing the bridge *****************************************/
-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:00 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:00 +0200
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
Message-ID: <20210419130106.6707-1-o.rempel@pengutronix.de>

changes v3:
- make more granular tests
- enable loopback for all PHYs by default
- fix allmodconfig build errors
- poll for link status update after switching to the loopback mode

changes v2:
- make generic selftests available for all networking devices.
- make use of net_selftest* on FEC, ag71xx and all DSA switches.
- add loopback support on more PHYs.

This patch set provides diagnostic capabilities for some iMX, ag71xx or
any DSA based devices. For proper functionality, PHY loopback support is
needed.
So far there is only initial infrastructure with basic tests. 

Oleksij Rempel (6):
  net: phy: execute genphy_loopback() per default on all PHYs
  net: phy: genphy_loopback: add link speed configuration
  net: add generic selftest support
  net: fec: make use of generic NET_SELFTESTS library
  net: ag71xx: make use of generic NET_SELFTESTS library
  net: dsa: enable selftest support for all switches by default

 drivers/net/ethernet/atheros/Kconfig      |   1 +
 drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
 drivers/net/ethernet/freescale/Kconfig    |   1 +
 drivers/net/ethernet/freescale/fec_main.c |   7 +
 drivers/net/phy/phy.c                     |   3 +-
 drivers/net/phy/phy_device.c              |  35 +-
 include/linux/phy.h                       |   1 +
 include/net/dsa.h                         |   2 +
 include/net/selftests.h                   |  12 +
 net/Kconfig                               |   4 +
 net/core/Makefile                         |   1 +
 net/core/selftests.c                      | 400 ++++++++++++++++++++++
 net/dsa/Kconfig                           |   1 +
 net/dsa/slave.c                           |  21 ++
 14 files changed, 500 insertions(+), 9 deletions(-)
 create mode 100644 include/net/selftests.h
 create mode 100644 net/core/selftests.c

-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:04 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:04 +0200
Subject: [PATCH net-next v3 4/6] net: fec: make use of generic NET_SELFTESTS
 library
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-5-o.rempel@pengutronix.de>

With this patch FEC on iMX will able to run generic net selftests

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/ethernet/freescale/Kconfig    | 1 +
 drivers/net/ethernet/freescale/fec_main.c | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3f9175bdce77..3d937b4650b2 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -26,6 +26,7 @@ config FEC
 		   ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
 	default ARCH_MXC || SOC_IMX28 if ARM
 	select CRC32
+	select NET_SELFTESTS
 	select PHYLIB
 	imply PTP_1588_CLOCK
 	help
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 70aea9c274fe..d51b2eb1de71 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -38,6 +38,7 @@
 #include <linux/in.h>
 #include <linux/ip.h>
 #include <net/ip.h>
+#include <net/selftests.h>
 #include <net/tso.h>
 #include <linux/tcp.h>
 #include <linux/udp.h>
@@ -2481,6 +2482,9 @@ static void fec_enet_get_strings(struct net_device *netdev,
 			memcpy(data + i * ETH_GSTRING_LEN,
 				fec_stats[i].name, ETH_GSTRING_LEN);
 		break;
+	case ETH_SS_TEST:
+		net_selftest_get_strings(data);
+		break;
 	}
 }
 
@@ -2489,6 +2493,8 @@ static int fec_enet_get_sset_count(struct net_device *dev, int sset)
 	switch (sset) {
 	case ETH_SS_STATS:
 		return ARRAY_SIZE(fec_stats);
+	case ETH_SS_TEST:
+		return net_selftest_get_count();
 	default:
 		return -EOPNOTSUPP;
 	}
@@ -2740,6 +2746,7 @@ static const struct ethtool_ops fec_enet_ethtool_ops = {
 	.set_wol		= fec_enet_set_wol,
 	.get_link_ksettings	= phy_ethtool_get_link_ksettings,
 	.set_link_ksettings	= phy_ethtool_set_link_ksettings,
+	.self_test		= net_selftest,
 };
 
 static int fec_enet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:02 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:02 +0200
Subject: [PATCH net-next v3 2/6] net: phy: genphy_loopback: add link speed
 configuration
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-3-o.rempel@pengutronix.de>

In case of loopback, in most cases we need to disable autoneg support
and force some speed configuration. Otherwise, depending on currently
active auto negotiated link speed, the loopback may or may not work.

This patch was tested with following PHYs: TJA1102, KSZ8081, KSZ9031,
AT8035, AR9331.

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/phy/phy.c        |  3 ++-
 drivers/net/phy/phy_device.c | 28 ++++++++++++++++++++++++++--
 include/linux/phy.h          |  1 +
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index fc2e7cb5b2e5..1f0512e39c65 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -701,7 +701,7 @@ int phy_start_cable_test_tdr(struct phy_device *phydev,
 }
 EXPORT_SYMBOL(phy_start_cable_test_tdr);
 
-static int phy_config_aneg(struct phy_device *phydev)
+int phy_config_aneg(struct phy_device *phydev)
 {
 	if (phydev->drv->config_aneg)
 		return phydev->drv->config_aneg(phydev);
@@ -714,6 +714,7 @@ static int phy_config_aneg(struct phy_device *phydev)
 
 	return genphy_config_aneg(phydev);
 }
+EXPORT_SYMBOL(phy_config_aneg);
 
 /**
  * phy_check_link_status - check link status and set state accordingly
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 320a3e5cd10a..0a2d8bedf73d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2565,8 +2565,32 @@ EXPORT_SYMBOL(genphy_resume);
 
 int genphy_loopback(struct phy_device *phydev, bool enable)
 {
-	return phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK,
-			  enable ? BMCR_LOOPBACK : 0);
+	if (enable) {
+		u16 val, ctl = BMCR_LOOPBACK;
+		int ret;
+
+		if (phydev->speed == SPEED_1000)
+			ctl |= BMCR_SPEED1000;
+		else if (phydev->speed == SPEED_100)
+			ctl |= BMCR_SPEED100;
+
+		if (phydev->duplex == DUPLEX_FULL)
+			ctl |= BMCR_FULLDPLX;
+
+		phy_modify(phydev, MII_BMCR, ~0, ctl);
+
+		ret = phy_read_poll_timeout(phydev, MII_BMSR, val,
+					    val & BMSR_LSTATUS,
+				    5000, 500000, true);
+		if (ret)
+			return ret;
+	} else {
+		phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK, 0);
+
+		phy_config_aneg(phydev);
+	}
+
+	return 0;
 }
 EXPORT_SYMBOL(genphy_loopback);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 98fb441dd72e..98e351bb0964 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1410,6 +1410,7 @@ void phy_disconnect(struct phy_device *phydev);
 void phy_detach(struct phy_device *phydev);
 void phy_start(struct phy_device *phydev);
 void phy_stop(struct phy_device *phydev);
+int phy_config_aneg(struct phy_device *phydev);
 int phy_start_aneg(struct phy_device *phydev);
 int phy_aneg_done(struct phy_device *phydev);
 int phy_speed_down(struct phy_device *phydev, bool sync);
-- 
2.29.2



From o.rempel at pengutronix.de  Mon Apr 19 14:01:03 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Mon, 19 Apr 2021 15:01:03 +0200
Subject: [PATCH net-next v3 3/6] net: add generic selftest support
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <20210419130106.6707-4-o.rempel@pengutronix.de>

Port some parts of the stmmac selftest and reuse it as basic generic selftest
library. This patch was tested with following combinations:
- iMX6DL FEC -> AT8035
- iMX6DL FEC -> SJA1105Q switch -> KSZ8081
- iMX6DL FEC -> SJA1105Q switch -> KSZ9031
- AR9331 ag71xx -> AR9331 PHY
- AR9331 ag71xx -> AR9331 switch -> AR9331 PHY

Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 include/net/selftests.h |  12 ++
 net/Kconfig             |   4 +
 net/core/Makefile       |   1 +
 net/core/selftests.c    | 400 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 417 insertions(+)
 create mode 100644 include/net/selftests.h
 create mode 100644 net/core/selftests.c

diff --git a/include/net/selftests.h b/include/net/selftests.h
new file mode 100644
index 000000000000..9993b9498cf3
--- /dev/null
+++ b/include/net/selftests.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _NET_SELFTESTS
+#define _NET_SELFTESTS
+
+#include <linux/ethtool.h>
+
+void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
+		  u64 *buf);
+int net_selftest_get_count(void);
+void net_selftest_get_strings(u8 *data);
+
+#endif /* _NET_SELFTESTS */
diff --git a/net/Kconfig b/net/Kconfig
index 9c456acc379e..8d955195c069 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -429,6 +429,10 @@ config GRO_CELLS
 config SOCK_VALIDATE_XMIT
 	bool
 
+config NET_SELFTESTS
+	def_tristate PHYLIB
+	depends on PHYLIB
+
 config NET_SOCK_MSG
 	bool
 	default n
diff --git a/net/core/Makefile b/net/core/Makefile
index 0c2233c826fd..1a6168d8f23b 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_NET_DEVLINK) += devlink.o
 obj-$(CONFIG_GRO_CELLS) += gro_cells.o
 obj-$(CONFIG_FAILOVER) += failover.o
 ifeq ($(CONFIG_INET),y)
+obj-$(CONFIG_NET_SELFTESTS) += selftests.o
 obj-$(CONFIG_NET_SOCK_MSG) += skmsg.o
 obj-$(CONFIG_BPF_SYSCALL) += sock_map.o
 endif
diff --git a/net/core/selftests.c b/net/core/selftests.c
new file mode 100644
index 000000000000..ba7b0171974c
--- /dev/null
+++ b/net/core/selftests.c
@@ -0,0 +1,400 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Synopsys, Inc. and/or its affiliates.
+ * stmmac Selftests Support
+ *
+ * Author: Jose Abreu <joabreu at synopsys.com>
+ *
+ * Ported from stmmac by:
+ * Copyright (C) 2021 Oleksij Rempel <o.rempel at pengutronix.de>
+ */
+
+#include <linux/phy.h>
+#include <net/selftests.h>
+#include <net/tcp.h>
+#include <net/udp.h>
+
+struct net_packet_attrs {
+	unsigned char *src;
+	unsigned char *dst;
+	u32 ip_src;
+	u32 ip_dst;
+	bool tcp;
+	u16 sport;
+	u16 dport;
+	int timeout;
+	int size;
+	int max_size;
+	u8 id;
+	u16 queue_mapping;
+};
+
+struct net_test_priv {
+	struct net_packet_attrs *packet;
+	struct packet_type pt;
+	struct completion comp;
+	int double_vlan;
+	int vlan_id;
+	int ok;
+};
+
+struct netsfhdr {
+	__be32 version;
+	__be64 magic;
+	u8 id;
+} __packed;
+
+static u8 net_test_next_id;
+
+#define NET_TEST_PKT_SIZE (sizeof(struct ethhdr) + sizeof(struct iphdr) + \
+			   sizeof(struct netsfhdr))
+#define NET_TEST_PKT_MAGIC	0xdeadcafecafedeadULL
+#define NET_LB_TIMEOUT		msecs_to_jiffies(200)
+
+static struct sk_buff *net_test_get_skb(struct net_device *ndev,
+					struct net_packet_attrs *attr)
+{
+	struct sk_buff *skb = NULL;
+	struct udphdr *uhdr = NULL;
+	struct tcphdr *thdr = NULL;
+	struct netsfhdr *shdr;
+	struct ethhdr *ehdr;
+	struct iphdr *ihdr;
+	int iplen, size;
+
+	size = attr->size + NET_TEST_PKT_SIZE;
+
+	if (attr->tcp)
+		size += sizeof(struct tcphdr);
+	else
+		size += sizeof(struct udphdr);
+
+	if (attr->max_size && attr->max_size > size)
+		size = attr->max_size;
+
+	skb = netdev_alloc_skb(ndev, size);
+	if (!skb)
+		return NULL;
+
+	prefetchw(skb->data);
+
+	ehdr = skb_push(skb, ETH_HLEN);
+	skb_reset_mac_header(skb);
+
+	skb_set_network_header(skb, skb->len);
+	ihdr = skb_put(skb, sizeof(*ihdr));
+
+	skb_set_transport_header(skb, skb->len);
+	if (attr->tcp)
+		thdr = skb_put(skb, sizeof(*thdr));
+	else
+		uhdr = skb_put(skb, sizeof(*uhdr));
+
+	eth_zero_addr(ehdr->h_dest);
+
+	if (attr->src)
+		ether_addr_copy(ehdr->h_source, attr->src);
+	if (attr->dst)
+		ether_addr_copy(ehdr->h_dest, attr->dst);
+
+	ehdr->h_proto = htons(ETH_P_IP);
+
+	if (attr->tcp) {
+		thdr->source = htons(attr->sport);
+		thdr->dest = htons(attr->dport);
+		thdr->doff = sizeof(struct tcphdr) / 4;
+		thdr->check = 0;
+	} else {
+		uhdr->source = htons(attr->sport);
+		uhdr->dest = htons(attr->dport);
+		uhdr->len = htons(sizeof(*shdr) + sizeof(*uhdr) + attr->size);
+		if (attr->max_size)
+			uhdr->len = htons(attr->max_size -
+					  (sizeof(*ihdr) + sizeof(*ehdr)));
+		uhdr->check = 0;
+	}
+
+	ihdr->ihl = 5;
+	ihdr->ttl = 32;
+	ihdr->version = 4;
+	if (attr->tcp)
+		ihdr->protocol = IPPROTO_TCP;
+	else
+		ihdr->protocol = IPPROTO_UDP;
+	iplen = sizeof(*ihdr) + sizeof(*shdr) + attr->size;
+	if (attr->tcp)
+		iplen += sizeof(*thdr);
+	else
+		iplen += sizeof(*uhdr);
+
+	if (attr->max_size)
+		iplen = attr->max_size - sizeof(*ehdr);
+
+	ihdr->tot_len = htons(iplen);
+	ihdr->frag_off = 0;
+	ihdr->saddr = htonl(attr->ip_src);
+	ihdr->daddr = htonl(attr->ip_dst);
+	ihdr->tos = 0;
+	ihdr->id = 0;
+	ip_send_check(ihdr);
+
+	shdr = skb_put(skb, sizeof(*shdr));
+	shdr->version = 0;
+	shdr->magic = cpu_to_be64(NET_TEST_PKT_MAGIC);
+	attr->id = net_test_next_id;
+	shdr->id = net_test_next_id++;
+
+	if (attr->size)
+		skb_put(skb, attr->size);
+	if (attr->max_size && attr->max_size > skb->len)
+		skb_put(skb, attr->max_size - skb->len);
+
+	skb->csum = 0;
+	skb->ip_summed = CHECKSUM_PARTIAL;
+	if (attr->tcp) {
+		thdr->check = ~tcp_v4_check(skb->len, ihdr->saddr,
+					    ihdr->daddr, 0);
+		skb->csum_start = skb_transport_header(skb) - skb->head;
+		skb->csum_offset = offsetof(struct tcphdr, check);
+	} else {
+		udp4_hwcsum(skb, ihdr->saddr, ihdr->daddr);
+	}
+
+	skb->protocol = htons(ETH_P_IP);
+	skb->pkt_type = PACKET_HOST;
+	skb->dev = ndev;
+
+	return skb;
+}
+
+static int net_test_loopback_validate(struct sk_buff *skb,
+				      struct net_device *ndev,
+				      struct packet_type *pt,
+				      struct net_device *orig_ndev)
+{
+	struct net_test_priv *tpriv = pt->af_packet_priv;
+	unsigned char *src = tpriv->packet->src;
+	unsigned char *dst = tpriv->packet->dst;
+	struct netsfhdr *shdr;
+	struct ethhdr *ehdr;
+	struct udphdr *uhdr;
+	struct tcphdr *thdr;
+	struct iphdr *ihdr;
+
+	skb = skb_unshare(skb, GFP_ATOMIC);
+	if (!skb)
+		goto out;
+
+	if (skb_linearize(skb))
+		goto out;
+	if (skb_headlen(skb) < (NET_TEST_PKT_SIZE - ETH_HLEN))
+		goto out;
+
+	ehdr = (struct ethhdr *)skb_mac_header(skb);
+	if (dst) {
+		if (!ether_addr_equal_unaligned(ehdr->h_dest, dst))
+			goto out;
+	}
+
+	if (src) {
+		if (!ether_addr_equal_unaligned(ehdr->h_source, src))
+			goto out;
+	}
+
+	ihdr = ip_hdr(skb);
+	if (tpriv->double_vlan)
+		ihdr = (struct iphdr *)(skb_network_header(skb) + 4);
+
+	if (tpriv->packet->tcp) {
+		if (ihdr->protocol != IPPROTO_TCP)
+			goto out;
+
+		thdr = (struct tcphdr *)((u8 *)ihdr + 4 * ihdr->ihl);
+		if (thdr->dest != htons(tpriv->packet->dport))
+			goto out;
+
+		shdr = (struct netsfhdr *)((u8 *)thdr + sizeof(*thdr));
+	} else {
+		if (ihdr->protocol != IPPROTO_UDP)
+			goto out;
+
+		uhdr = (struct udphdr *)((u8 *)ihdr + 4 * ihdr->ihl);
+		if (uhdr->dest != htons(tpriv->packet->dport))
+			goto out;
+
+		shdr = (struct netsfhdr *)((u8 *)uhdr + sizeof(*uhdr));
+	}
+
+	if (shdr->magic != cpu_to_be64(NET_TEST_PKT_MAGIC))
+		goto out;
+	if (tpriv->packet->id != shdr->id)
+		goto out;
+
+	tpriv->ok = true;
+	complete(&tpriv->comp);
+out:
+	kfree_skb(skb);
+	return 0;
+}
+
+static int __net_test_loopback(struct net_device *ndev,
+			       struct net_packet_attrs *attr)
+{
+	struct net_test_priv *tpriv;
+	struct sk_buff *skb = NULL;
+	int ret = 0;
+
+	tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
+	if (!tpriv)
+		return -ENOMEM;
+
+	tpriv->ok = false;
+	init_completion(&tpriv->comp);
+
+	tpriv->pt.type = htons(ETH_P_IP);
+	tpriv->pt.func = net_test_loopback_validate;
+	tpriv->pt.dev = ndev;
+	tpriv->pt.af_packet_priv = tpriv;
+	tpriv->packet = attr;
+	dev_add_pack(&tpriv->pt);
+
+	skb = net_test_get_skb(ndev, attr);
+	if (!skb) {
+		ret = -ENOMEM;
+		goto cleanup;
+	}
+
+	ret = dev_direct_xmit(skb, attr->queue_mapping);
+	if (ret < 0) {
+		goto cleanup;
+	} else if (ret > 0) {
+		ret = -ENETUNREACH;
+		goto cleanup;
+	}
+
+	if (!attr->timeout)
+		attr->timeout = NET_LB_TIMEOUT;
+
+	wait_for_completion_timeout(&tpriv->comp, attr->timeout);
+	ret = tpriv->ok ? 0 : -ETIMEDOUT;
+
+cleanup:
+	dev_remove_pack(&tpriv->pt);
+	kfree(tpriv);
+	return ret;
+}
+
+static int net_test_netif_carrier(struct net_device *ndev)
+{
+	return netif_carrier_ok(ndev) ? 0 : -ENOLINK;
+}
+
+static int net_test_phy_phydev(struct net_device *ndev)
+{
+	return ndev->phydev ? 0 : -EOPNOTSUPP;
+}
+
+static int net_test_phy_loopback_enable(struct net_device *ndev)
+{
+	if (!ndev->phydev)
+		return -EOPNOTSUPP;
+
+	return phy_loopback(ndev->phydev, true);
+}
+
+static int net_test_phy_loopback_disable(struct net_device *ndev)
+{
+	if (!ndev->phydev)
+		return -EOPNOTSUPP;
+
+	return phy_loopback(ndev->phydev, false);
+}
+
+static int net_test_phy_loopback_udp(struct net_device *ndev)
+{
+	struct net_packet_attrs attr = { };
+
+	attr.dst = ndev->dev_addr;
+	return __net_test_loopback(ndev, &attr);
+}
+
+static int net_test_phy_loopback_tcp(struct net_device *ndev)
+{
+	struct net_packet_attrs attr = { };
+
+	attr.dst = ndev->dev_addr;
+	attr.tcp = true;
+	return __net_test_loopback(ndev, &attr);
+}
+
+static const struct net_test {
+	char name[ETH_GSTRING_LEN];
+	int (*fn)(struct net_device *ndev);
+} net_selftests[] = {
+	{
+		.name = "Carrier                       ",
+		.fn = net_test_netif_carrier,
+	}, {
+		.name = "PHY dev is present            ",
+		.fn = net_test_phy_phydev,
+	}, {
+		/* This test should be done before all PHY loopback test */
+		.name = "PHY internal loopback, enable ",
+		.fn = net_test_phy_loopback_enable,
+	}, {
+		.name = "PHY internal loopback, UDP    ",
+		.fn = net_test_phy_loopback_udp,
+	}, {
+		.name = "PHY internal loopback, TCP    ",
+		.fn = net_test_phy_loopback_tcp,
+	}, {
+		/* This test should be done after all PHY loopback test */
+		.name = "PHY internal loopback, disable",
+		.fn = net_test_phy_loopback_disable,
+	},
+};
+
+void net_selftest(struct net_device *ndev, struct ethtool_test *etest, u64 *buf)
+{
+	int count = net_selftest_get_count();
+	int i;
+
+	memset(buf, 0, sizeof(*buf) * count);
+	net_test_next_id = 0;
+
+	if (etest->flags != ETH_TEST_FL_OFFLINE) {
+		netdev_err(ndev, "Only offline tests are supported\n");
+		etest->flags |= ETH_TEST_FL_FAILED;
+		return;
+	}
+
+
+	for (i = 0; i < count; i++) {
+		buf[i] = net_selftests[i].fn(ndev);
+		if (buf[i] && (buf[i] != -EOPNOTSUPP))
+			etest->flags |= ETH_TEST_FL_FAILED;
+	}
+}
+EXPORT_SYMBOL_GPL(net_selftest);
+
+int net_selftest_get_count(void)
+{
+	return ARRAY_SIZE(net_selftests);
+}
+EXPORT_SYMBOL_GPL(net_selftest_get_count);
+
+void net_selftest_get_strings(u8 *data)
+{
+	u8 *p = data;
+	int i;
+
+	for (i = 0; i < net_selftest_get_count(); i++) {
+		snprintf(p, ETH_GSTRING_LEN, "%2d. %s", i + 1,
+			 net_selftests[i].name);
+		p += ETH_GSTRING_LEN;
+	}
+}
+EXPORT_SYMBOL_GPL(net_selftest_get_strings);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Oleksij Rempel <o.rempel at pengutronix.de>");
-- 
2.29.2



From geert at linux-m68k.org  Mon Apr 19 14:02:35 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 19 Apr 2021 15:02:35 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
Message-ID: <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>

Hi Andy,

On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
>
> ...
>
> > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > >
> > > > > But why?
> > > >
> > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > >
> > > I'm not using it at all. Ask the author :-)
> > >
> > > But if we follow your logic, then we need to mark all the _platform_ drivers
> > > for x86 world as ACPI dependent? This sounds ugly.
> >
> > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > (2) no other way of instantiating their devices?
> > The first driver from the top of my memory I looked at is rtc-cmos:
> > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > from arch/x86/kernel/rtc.c.
> >
> > For drivers with only an .of_match_table(), and no legacy users
> > instantiating platform devices, we do have dependencies on OF.
>
> This is not true. Entire IIO subsystem is an example.

Do you care to elaborate?
Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
subject to the above.

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 yangyicong at hisilicon.com  Mon Apr 19 14:03:18 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Mon, 19 Apr 2021 21:03:18 +0800
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com>

On 2021/4/17 21:56, Alexander Shishkin wrote:
> Yicong Yang <yangyicong at hisilicon.com> writes:
> 
>> The reason for not using perf is because there is no current support
>> for uncore tracing in the perf facilities.
> 
> Not unless you count
> 
> $ perf list|grep -ic uncore
> 77
> 

these are uncore events probably do not support sampling.

I tried on x86:

# ./perf record -e uncore_imc_0/cas_count_read/
Error:
The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_imc_0/cas_count_read/).
/bin/dmesg | grep -i perf may provide additional information.

For HiSilicon uncore PMUs, we don't support uncore sampling:

'The current driver does not support sampling. So "perf record" is unsupported. ' [1]

and also in another PMU:

'PMU doesn't support process specific events and cannot be used in sampling mode.' [2]

[1] Documentation/admin-guide/perf/hisi-pmu.rst
[2] Documentation/admin-guide/perf/arm_dsu_pmu.rst

>> We have our own format
>> of data and don't need perf doing the parsing.
> 
> Perf has AUX buffers, which are used for all kinds of own formats.
> 

ok. we thought perf will break the data format but AUX buffers seems won't.
do we need to add full support for tracing as well as parsing or it's ok for
not parsing it through perf?

>> A similar approach for implementing this function is ETM, which use
>> sysfs for configuring and a character device for dumping data.
> 
> And also perf. One reason ETM has a sysfs interface is because the
> driver predates perf's AUX buffers. Can't say if it's the only
> reason. I'm assuming you're talking about Coresight ETM.
> 

got it. thanks.

>> Greg has some comments on our implementation and doesn't advocate
>> to build driver on debugfs [1]. So I resend this series to
>> collect more feedbacks on the implementation of this driver.
>>
>> Hi perf and ETM related experts, is it suggested to adapt this driver
>> to perf? Or is the debugfs approach acceptable? Otherwise use
> 
> Aside from the above, I don't think the use of debugfs for kernel ABIs
> is ever encouraged.
> 

ok. thanks for the suggestions.

Regards,
Yicong

> Regards,
> --
> Ale
> 
> .
> 



From yangyicong at hisilicon.com  Mon Apr 19 14:12:57 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Mon, 19 Apr 2021 21:12:57 +0800
Subject: [PATCH RESEND 3/4] docs: Add HiSilicon PTT device driver
 documentation
In-Reply-To: <20210419090750.g6aeyyrki7fiotxl@maple.lan>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <1618654631-42454-4-git-send-email-yangyicong@hisilicon.com>
 <20210419090750.g6aeyyrki7fiotxl@maple.lan>
Message-ID: <e884000f-3131-490b-eb0c-bc82ed642a85@hisilicon.com>

On 2021/4/19 17:07, Daniel Thompson wrote:
> On Sat, Apr 17, 2021 at 06:17:10PM +0800, Yicong Yang wrote:
>> Document the introduction and usage of HiSilicon PTT device driver.
>>
>> Signed-off-by: Yicong Yang <yangyicong at hisilicon.com>
>> ---
>>  Documentation/trace/hisi-ptt.rst | 326 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 326 insertions(+)
>>  create mode 100644 Documentation/trace/hisi-ptt.rst
>>
>> diff --git a/Documentation/trace/hisi-ptt.rst b/Documentation/trace/hisi-ptt.rst
>> new file mode 100644
>> index 0000000..f093846
>> --- /dev/null
>> +++ b/Documentation/trace/hisi-ptt.rst
>> @@ -0,0 +1,326 @@
>> [...]
>> +On Kunpeng 930 SoC, the PCIe Root Complex is composed of several
>> +PCIe cores. Each PCIe core includes several Root Ports and a PTT
>> +RCiEP, like below. The PTT device is capable of tuning and
>> +tracing the link of the PCIe core.
>> +::
>> +          +--------------Core 0-------+
>> +          |       |       [   PTT   ] |
>> +          |       |       [Root Port]---[Endpoint]
>> +          |       |       [Root Port]---[Endpoint]
>> +          |       |       [Root Port]---[Endpoint]
>> +    Root Complex  |------Core 1-------+
>> +          |       |       [   PTT   ] |
>> +          |       |       [Root Port]---[ Switch ]---[Endpoint]
>> +          |       |       [Root Port]---[Endpoint] `-[Endpoint]
>> +          |       |       [Root Port]---[Endpoint]
>> +          +---------------------------+
>> +
>> +The PTT device driver cannot be loaded if debugfs is not mounted.
> 
> This can't be right can it? Obviously debugfs must be enabled but why
> mounted?
> 

just mention the limit as I'm not sure it's always be mounted.

> 
>> +Each PTT device will be presented under /sys/kernel/debugfs/hisi_ptt
>> +as its root directory, with name of its BDF number.
>> +::
>> +
>> +    /sys/kernel/debug/hisi_ptt/<domain>:<bus>:<device>.<function>
>> +
>> +Tune
>> +====
>> +
>> +PTT tune is designed for monitoring and adjusting PCIe link parameters (events).
>> +Currently we support events in 4 classes. The scope of the events
>> +covers the PCIe core to which the PTT device belongs.
>> +
>> +Each event is presented as a file under $(PTT root dir)/$(BDF)/tune, and
>> +mostly a simple open/read/write/close cycle will be used to tune
>> +the event.
>> +::
>> +    $ cd /sys/kernel/debug/hisi_ptt/$(BDF)/tune
>> +    $ ls
>> +    qos_tx_cpl    qos_tx_np    qos_tx_p
>> +    tx_path_rx_req_alloc_buf_level
>> +    tx_path_tx_req_alloc_buf_level
>> +    $ cat qos_tx_dp
>> +    1
>> +    $ echo 2 > qos_tx_dp
>> +    $ cat qos_tx_dp
>> +    2
>> +
>> +Current value (numerical value) of the event can be simply read
>> +from the file, and the desired value written to the file to tune.
> 
> I saw that this RFC asks about whether debugfs is an appropriate
> interface for the *tracing* capability of the platform. Have similar
> questions been raised about the tuning interfaces?
> 

yes. as well.

> It looks to me like tuning could be handled entirely using sysfs
> attributes. I think trying to handle these mostly decoupled feature
> in the same place is likely to be a mistake.
> 

Tuning and tracing are two separate functions and it does make sense
to decouple them. Thanks for the advice, we can make tuning using
sysfs attributes as debugfs is not encouraged.

Regards,
Yicong

> 
> Daniel.
> 
> .
> 



From christophe.leroy at csgroup.eu  Mon Apr 19 14:14:21 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Mon, 19 Apr 2021 15:14:21 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
Message-ID: <627ee414-2f78-94e3-b77b-1013f52e77e3@csgroup.eu>



Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
> On 16/04/2021 11:38, Christophe Leroy wrote:
>>
>>
>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>
>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be using 
>>> it purely to find "holes" in the calls to note_page(), but I haven't worked out why such holes 
>>> would occur.
>>
>> I was indeed introduced for KASAN. We have a first commit 
>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is a 
>> KASAN like stuff.
>>
>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what the 
>> problem was exactly, something around the use of hugepages for kernel memory, came as part of the 
>> series 
>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
> 
> 
> Ah, that's useful context. So it looks like powerpc took a different route to reducing the KASAN 
> output to x86.
> 
> Given the generic ptdump code has handling for KASAN already it should be possible to drop that from 
> the powerpc arch code, which I think means we don't actually need to provide page size to 
> notepage(). Hopefully that means more code to delete ;)
> 

Looking at how the generic ptdump code handles KASAN, I'm a bit sceptic.

IIUC, it is checking that kasan_early_shadow_pte is in the same page as the pgtable referred by the 
PMD entry. But what happens if that PMD entry is referring another pgtable which is inside the same 
page as kasan_early_shadow_pte ?

Shouldn't the test be

	if (pmd_page_vaddr(val) == lm_alias(kasan_early_shadow_pte))
		return note_kasan_page_table(walk, addr);


Christophe


From colin.king at canonical.com  Mon Apr 19 14:20:32 2021
From: colin.king at canonical.com (Colin King)
Date: Mon, 19 Apr 2021 14:20:32 +0100
Subject: [PATCH][next] mt76: mt7615: Fix a dereference of pointer sta before
 it is null checked
Message-ID: <20210419132032.177788-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

Currently the assignment of idx dereferences pointer sta before
sta is null checked, leading to a potential null pointer dereference.
Fix this by assigning idx when it is required after the null check on
pointer sta.

Addresses-Coverity: ("Dereference before null check")
Fixes: a4a5a430b076 ("mt76: mt7615: fix TSF configuration")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/wireless/mediatek/mt76/mt7615/usb_sdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/usb_sdio.c b/drivers/net/wireless/mediatek/mt76/mt7615/usb_sdio.c
index 4a370b9f7a17..f8d3673c2cae 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/usb_sdio.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/usb_sdio.c
@@ -67,7 +67,7 @@ static int mt7663_usb_sdio_set_rates(struct mt7615_dev *dev,
 	struct mt7615_rate_desc *rate = &wrd->rate;
 	struct mt7615_sta *sta = wrd->sta;
 	u32 w5, w27, addr, val;
-	u16 idx = sta->vif->mt76.omac_idx;
+	u16 idx;
 
 	lockdep_assert_held(&dev->mt76.mutex);
 
@@ -119,6 +119,7 @@ static int mt7663_usb_sdio_set_rates(struct mt7615_dev *dev,
 
 	sta->rate_probe = sta->rateset[rate->rateset].probe_rate.idx != -1;
 
+	idx = sta->vif->mt76.omac_idx;
 	idx = idx > HW_BSSID_MAX ? HW_BSSID_0 : idx;
 	addr = idx > 1 ? MT_LPON_TCR2(idx): MT_LPON_TCR0(idx);
 
-- 
2.30.2



From yangyicong at hisilicon.com  Mon Apr 19 14:21:38 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Mon, 19 Apr 2021 21:21:38 +0800
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <529defac-cd67-3a7b-91d3-76eb0bb9dc6c@arm.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <529defac-cd67-3a7b-91d3-76eb0bb9dc6c@arm.com>
Message-ID: <fb4e70d9-e5c8-1cbf-ca21-adb701089fe0@hisilicon.com>

On 2021/4/19 19:17, Suzuki K Poulose wrote:
> On 17/04/2021 11:17, Yicong Yang wrote:
>> [RESEND with perf and coresight folks Cc'ed]
>>
>> HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
>> integrated Endpoint (RCiEP) device, providing the capability
>> to dynamically monitor and tune the PCIe traffic (tune),
>> and trace the TLP headers (trace).
>>
>> PTT tune is designed for monitoring and adjusting PCIe link parameters.
>> We provide several parameters of the PCIe link. Through the driver,
>> user can adjust the value of certain parameter to affect the PCIe link
>> for the purpose of enhancing the performance in certian situation.
> 
> ...
> 
>>
>> The reason for not using perf is because there is no current support
>> for uncore tracing in the perf facilities. We have our own format
>> of data and don't need perf doing the parsing. The setting through
>> perf tools doesn't seem to be friendly as well. For example,
>> we cannot count on perf to decode the usual format BDF number like
>> <domain>:<bus>:<dev>.<fn>, which user can use to filter the TLP
>> headers through the PTT device.
>>
>> A similar approach for implementing this function is ETM, which use
>> sysfs for configuring and a character device for dumping data.
>>
>> Greg has some comments on our implementation and doesn't advocate
>> to build driver on debugfs [1]. So I resend this series to
>> collect more feedbacks on the implementation of this driver.
>>
>> Hi perf and ETM related experts, is it suggested to adapt this driver
>> to perf? Or is the debugfs approach acceptable? Otherwise use
>> sysfs + character device like ETM and use perf tools for decoding it?
>> Any comments is welcomed.
> 
> Please use perf. Debugfs / sysfs is not the right place for these things.
> 

ok.

> Also, please move your driver to drivers/perf/
> 

Does it make sense as it's a tuning and tracing device, and doesn't have counters
nor do the sampling like usual PMU device under drivers/perf/.

> As Alex mentioned, the ETM drivers were initially developed when the AUX
> buffer was not available. The sysfs interface is there only for the backward compatibility and for bring up ( due to the nature of the
> connections between the CoreSight components and sometimes the missing engineering spec).
> 

got it. thanks for the explanation.

Regards,
Yicong

> Suzuki
> 
> .



From andy.shevchenko at gmail.com  Mon Apr 19 14:31:52 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 16:31:52 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
Message-ID: <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>

On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:

...

> > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > >
> > > > > > But why?
> > > > >
> > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > >
> > > > I'm not using it at all. Ask the author :-)
> > > >
> > > > But if we follow your logic, then we need to mark all the _platform_ drivers
> > > > for x86 world as ACPI dependent? This sounds ugly.
> > >
> > > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > > (2) no other way of instantiating their devices?
> > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > > from arch/x86/kernel/rtc.c.
> > >
> > > For drivers with only an .of_match_table(), and no legacy users
> > > instantiating platform devices, we do have dependencies on OF.
> >
> > This is not true. Entire IIO subsystem is an example.
>
> Do you care to elaborate?
> Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> subject to the above.

It seems I missed that you are talking about platform device drivers.
In any case it's not true. We have the platform drivers w/o legacy
users that are not dependent on OF.
They may _indirectly_ be dependent, but this is fine as I stated above
when suggested to move ACPI dependency on ARCH_xxx level.

-- 
With Best Regards,
Andy Shevchenko


From baolu.lu at linux.intel.com  Mon Apr 19 14:33:48 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Mon, 19 Apr 2021 21:33:48 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
 <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
Message-ID: <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>

Hi Keqian,

On 2021/4/19 17:32, Keqian Zhu wrote:
>>> +EXPORT_SYMBOL_GPL(iommu_split_block);
>> Do you really have any consumers of this interface other than the dirty
>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
>> interface.
>>
>> There is an implicit requirement for such interfaces. The
>> iommu_map/unmap(iova, size) shouldn't be called at the same time.
>> Currently there's no such sanity check in the iommu core. A poorly
>> written driver could mess up the kernel by misusing this interface.
> Yes, I don't think up a scenario except dirty tracking.
> 
> Indeed, we'd better not make them as a generic interface.
> 
> Do you have any suggestion that underlying iommu drivers can share these code but
> not make it as a generic iommu interface?
> 
> I have a not so good idea. Make the "split" interfaces as a static function, and
> transfer the function pointer to start_dirty_log. But it looks weird and inflexible.

I understand splitting/merging super pages is an optimization, but not a
functional requirement. So is it possible to let the vendor iommu driver
decide whether splitting super pages when starting dirty bit tracking
and the opposite operation during when stopping it? The requirement for
upper layer is that starting/stopping dirty bit tracking and
mapping/unmapping are mutually exclusive.

> 
> On the other hand, if a driver calls map/unmap with split/merge at the same time,
> it's a bug of driver, it should follow the rule.
> 

Best regards,
baolu


From nm at ti.com  Mon Apr 19 14:35:42 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 19 Apr 2021 08:35:42 -0500
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema
In-Reply-To: <20210417125127.vigq23mdoodje6b5@velcro>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-3-nm@ti.com>
 <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>
 <20210417125127.vigq23mdoodje6b5@velcro>
Message-ID: <20210419133542.ndgkmf7eq4oqse34@ladies>

Stephen,

On 07:51-20210417, Nishanth Menon wrote:
> On 16:55-20210416, Stephen Boyd wrote:
> > Quoting Nishanth Menon (2021-04-15 23:37:19)
> > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > new file mode 100644
> > > index 000000000000..72633651f0c7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > @@ -0,0 +1,52 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI-SCI clock controller node bindings
> > > +
> > > +maintainers:
> > > +  - Nishanth Menon <nm at ti.com>
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/clock/clock.yaml#
> > 
> > Is this needed?
> 
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> This standardizes provider properties like '#clock-cells' etc, allowing
> you to add more stricter checks or controls in the future if necessary.
> 
> while:
> 
> https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> is more a consumer node description.
> 
> Should I have picked a different yaml as base for a standard clock-controller
> base?
> 

Thinking again, I think your comment was to drop the clock.yaml
inclusion, and, as a result this schema can become more stringent..

Could you clarify?


> > 
> > > +
> > > +description: |
> > > +  Some TI SoCs contain a system controller (like the Power Management Micro
> > > +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > +  the state of the various hardware modules present on the SoC. Communication
> > > +  between the host processor running an OS and the system controller happens
> > > +  through a protocol called TI System Control Interface (TI-SCI protocol).
> > > +
> > > +  This clock controller node uses the TI SCI protocol to perform various clock
> > > +  management of various hardware modules (devices) present on the SoC. This
> > > +  node must be a child node of the associated TI-SCI system controller node.
> > > +
> > > +properties:
> > > +  $nodename:
> > > +    pattern: "^clock-controller$"
> > 
> > Is this nodename pattern check required?
> 
> I'd like the definition on rails and not subject to interpretation, and
> restrict the kind of subnodes under TISCI controller node.
> 
> > 
> > > +
> > > +  compatible:
> > > +    const: ti,k2g-sci-clk
> > 
> > I thought most things keyed off the compatible string.
> 
> Yes, they are. I am not sure I understand your question here. Did you
> mean to indicate that having $nodename and compatible both are
> redundant?
> 
> Redundancy was'nt the intent of this schema definition, rather, I'd like
> to make sure that it is not upto interpretation or debate as to what the
> node name should be: I believe clock-controller is the correct nodename
> (without @0x... since this does'nt use reg property) instead of using
> clocks, tisci-clock as the node names.
> 
> 
> Do you suggest something  different?
> 
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

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


From geert at linux-m68k.org  Mon Apr 19 14:54:10 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 19 Apr 2021 15:54:10 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
Message-ID: <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>

Hi Andy,

On Mon, Apr 19, 2021 at 3:35 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> > <andy.shevchenko at gmail.com> wrote:
> > > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
>
> ...
>
> > > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > > >
> > > > > > > But why?
> > > > > >
> > > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > > >
> > > > > I'm not using it at all. Ask the author :-)
> > > > >
> > > > > But if we follow your logic, then we need to mark all the _platform_ drivers
> > > > > for x86 world as ACPI dependent? This sounds ugly.
> > > >
> > > > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > > > (2) no other way of instantiating their devices?
> > > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > > > from arch/x86/kernel/rtc.c.
> > > >
> > > > For drivers with only an .of_match_table(), and no legacy users
> > > > instantiating platform devices, we do have dependencies on OF.
> > >
> > > This is not true. Entire IIO subsystem is an example.
> >
> > Do you care to elaborate?
> > Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> > subject to the above.
>
> It seems I missed that you are talking about platform device drivers.

OK.

> In any case it's not true. We have the platform drivers w/o legacy
> users that are not dependent on OF.

Example? ;-)

> They may _indirectly_ be dependent, but this is fine as I stated above
> when suggested to move ACPI dependency on ARCH_xxx level.

As per the response from the driver maintainer
https://lore.kernel.org/linux-arm-kernel/bd8db435-24e1-5ab3-6b35-1d4d8a292a7e at hisilicon.com/,
there is no dependency on ARCH_HISI, so moving the ACPI dependency
up won't help.

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 s-anna at ti.com  Mon Apr 19 14:55:37 2021
From: s-anna at ti.com (Suman Anna)
Date: Mon, 19 Apr 2021 08:55:37 -0500
Subject: [PATCH v2 1/2] dt-bindings: remoteproc: k3-r5f: Update bindings
 for AM64x SoCs
In-Reply-To: <20210327143117.1840-2-s-anna@ti.com>
References: <20210327143117.1840-1-s-anna@ti.com>
 <20210327143117.1840-2-s-anna@ti.com>
Message-ID: <8948a30c-1a2f-1fb0-05bb-37be9c02c5d5@ti.com>

Hi Rob,

On 3/27/21 9:31 AM, Suman Anna wrote:
> The K3 AM64x SoCs have two dual-core Arm R5F clusters/subsystems, with
> 2 R5F cores each, both in the MAIN voltage domain.
> 
> These clusters are a revised IP version compared to those present on
> J721E and J7200 SoCs, and supports a new "Single-CPU" mode instead of
> LockStep mode. Update the K3 R5F remoteproc bindings with the compatible
> info relevant to these R5F clusters/subsystems on K3 AM64x SoCs.
> 
> Signed-off-by: Suman Anna <s-anna at ti.com>
> ---
> v2: No changes
> 
>  .../bindings/remoteproc/ti,k3-r5f-rproc.yaml  | 31 ++++++++++++++++---

Looks like this patch has fallen through the cracks, can you please review and
give your ack for this patch so that Bjorn can pick up the series for 5.13?

regards
Suman

>  1 file changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
> index d905d614502b..130fbaacc4b1 100644
> --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
> @@ -14,8 +14,12 @@ description: |
>    processor subsystems/clusters (R5FSS). The dual core cluster can be used
>    either in a LockStep mode providing safety/fault tolerance features or in a
>    Split mode providing two individual compute cores for doubling the compute
> -  capacity. These are used together with other processors present on the SoC
> -  to achieve various system level goals.
> +  capacity on most SoCs. These are used together with other processors present
> +  on the SoC to achieve various system level goals.
> +
> +  AM64x SoCs do not support LockStep mode, but rather a new non-safety mode
> +  called "Single-CPU" mode, where only Core0 is used, but with ability to use
> +  Core1's TCMs as well.
>  
>    Each Dual-Core R5F sub-system is represented as a single DTS node
>    representing the cluster, with a pair of child DT nodes representing
> @@ -33,6 +37,7 @@ properties:
>        - ti,am654-r5fss
>        - ti,j721e-r5fss
>        - ti,j7200-r5fss
> +      - ti,am64-r5fss
>  
>    power-domains:
>      description: |
> @@ -56,11 +61,12 @@ properties:
>  
>    ti,cluster-mode:
>      $ref: /schemas/types.yaml#/definitions/uint32
> -    enum: [0, 1]
>      description: |
>        Configuration Mode for the Dual R5F cores within the R5F cluster.
> -      Should be either a value of 1 (LockStep mode) or 0 (Split mode),
> -      default is LockStep mode if omitted.
> +      Should be either a value of 1 (LockStep mode) or 0 (Split mode) on
> +      most SoCs (AM65x, J721E, J7200), default is LockStep mode if omitted;
> +      and should be either a value of 0 (Split mode) or 2 (Single-CPU mode)
> +      on AM64x SoCs, default is Split mode if omitted.
>  
>  # R5F Processor Child Nodes:
>  # ==========================
> @@ -97,6 +103,7 @@ patternProperties:
>            - ti,am654-r5f
>            - ti,j721e-r5f
>            - ti,j7200-r5f
> +          - ti,am64-r5f
>  
>        reg:
>          items:
> @@ -198,6 +205,20 @@ patternProperties:
>  
>      unevaluatedProperties: false
>  
> +if:
> +  properties:
> +    compatible:
> +      enum:
> +        - ti,am64-r5fss
> +then:
> +  properties:
> +    ti,cluster-mode:
> +      enum: [0, 2]
> +else:
> +  properties:
> +    ti,cluster-mode:
> +      enum: [0, 1]
> +
>  required:
>    - compatible
>    - power-domains
> 



From arnd at arndb.de  Mon Apr 19 14:57:10 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 19 Apr 2021 15:57:10 +0200
Subject: [PATCH 12/13] ARM: dts: stm32: fix DSI port node on STM32MP15
In-Reply-To: <96da49dc-f24d-aa12-e1d8-39b5a5b6fbc9@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-13-alexandre.torgue@foss.st.com>
 <ececc78c-4fca-bb93-ef62-5d107501d963@pengutronix.de>
 <96da49dc-f24d-aa12-e1d8-39b5a5b6fbc9@foss.st.com>
Message-ID: <CAK8P3a1bGAUbqTGqyz+PB=7fuVLkJce0awtx1Z9PE3uiX6uysQ@mail.gmail.com>

On Thu, Apr 15, 2021 at 2:23 PM Alexandre TORGUE
<alexandre.torgue at foss.st.com> wrote:
> On 4/15/21 12:43 PM, Ahmad Fatoum wrote:
> > On 15.04.21 12:10, Alexandre Torgue wrote:
> >> Running "make dtbs_check W=1", some warnings are reported concerning
> >> DSI. This patch reorder DSI nodes to avoid:
> >>
> >> soc/dsi at 5a000000: unnecessary #address-cells/#size-cells without
> >> "ranges" or child "reg" property
> >
> > This reverts parts of commit 9c32f980d9 ("ARM: dts: stm32: preset
> > stm32mp15x video #address- and #size-cells"):
> >
> >      The cell count for address and size is defined by the binding and not
> >      something a board would change. Avoid each board adding this
> >      boilerplate by having the cell size specification in the SoC DTSI.
> >
> >
> > The DSI can have child nodes with a unit address (e.g. a panel) and ones
> > without (ports { } container). ports is described in the dtsi, panels are
> > described in the dts if available.
> >
> > Apparently, the checker is fine with
> > ports {
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> > };
> >
> > I think my rationale for the patch above was sound, so I think the checker
> > taking offense at the DSI cells here should be considered a false positive.
>
> If it's a "false positive" warning then we need to find a way to not
> print it out. Else, it'll be difficult to distinguish which warnings are
> "normal" and which are not. This question could also be applied to patch[3].
>
> Arnd, Rob what is your feeling about this case ?

I don't have a strong opinion on this either way, but I would just
not apply this one for 5.13 in this case. Rob, Alexandre, please
let me know if I should apply the other patches before the
merge window, I usually don't mind taking bugfixes late before the
merge window, but I still want some level of confidence that they
are actually correct.

Ahmad, if you feel strongly about this particular issue, would you like
to suggest a patch for the checker?

        Arnd


From andy.shevchenko at gmail.com  Mon Apr 19 14:58:32 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 16:58:32 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
Message-ID: <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>

On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Mon, Apr 19, 2021 at 3:35 PM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> > On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> > > <andy.shevchenko at gmail.com> wrote:
> > > > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> >
> > ...
> >
> > > > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > > > >
> > > > > > > > But why?
> > > > > > >
> > > > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > > > >
> > > > > > I'm not using it at all. Ask the author :-)
> > > > > >
> > > > > > But if we follow your logic, then we need to mark all the _platform_ drivers
> > > > > > for x86 world as ACPI dependent? This sounds ugly.
> > > > >
> > > > > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > > > > (2) no other way of instantiating their devices?
> > > > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > > > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > > > > from arch/x86/kernel/rtc.c.
> > > > >
> > > > > For drivers with only an .of_match_table(), and no legacy users
> > > > > instantiating platform devices, we do have dependencies on OF.
> > > >
> > > > This is not true. Entire IIO subsystem is an example.
> > >
> > > Do you care to elaborate?
> > > Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> > > subject to the above.
> >
> > It seems I missed that you are talking about platform device drivers.
>
> OK.
>
> > In any case it's not true. We have the platform drivers w/o legacy
> > users that are not dependent on OF.
>
> Example? ;-)

i2c-owl.c

> > They may _indirectly_ be dependent, but this is fine as I stated above
> > when suggested to move ACPI dependency on ARCH_xxx level.
>
> As per the response from the driver maintainer
> https://lore.kernel.org/linux-arm-kernel/bd8db435-24e1-5ab3-6b35-1d4d8a292a7e at hisilicon.com/,
> there is no dependency on ARCH_HISI, so moving the ACPI dependency
> up won't help.

So, an ACPI dependency is simply not applicable here as it's a compile
dependency as well, which is not a limitation for this driver. Again,
talk to Masahiro how to handle this, but I don't see any good
justification to have ACPI (compile time) dependency here. So, again
NAK!

-- 
With Best Regards,
Andy Shevchenko


From steven.price at arm.com  Mon Apr 19 15:00:14 2021
From: steven.price at arm.com (Steven Price)
Date: Mon, 19 Apr 2021 15:00:14 +0100
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <627ee414-2f78-94e3-b77b-1013f52e77e3@csgroup.eu>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <627ee414-2f78-94e3-b77b-1013f52e77e3@csgroup.eu>
Message-ID: <4a76fbda-aa9d-867b-e2eb-a1951780aeec@arm.com>

On 19/04/2021 14:14, Christophe Leroy wrote:
> 
> 
> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>
>>>
>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>>
>>>> To be honest I don't fully understand why powerpc requires the 
>>>> page_size - it appears to be using it purely to find "holes" in the 
>>>> calls to note_page(), but I haven't worked out why such holes would 
>>>> occur.
>>>
>>> I was indeed introduced for KASAN. We have a first commit 
>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page 
>>> size to detect whether it is a KASAN like stuff.
>>>
>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a 
>>> fix. I can't remember what the problem was exactly, something around 
>>> the use of hugepages for kernel memory, came as part of the series 
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>
>>
>>
>> Ah, that's useful context. So it looks like powerpc took a different 
>> route to reducing the KASAN output to x86.
>>
>> Given the generic ptdump code has handling for KASAN already it should 
>> be possible to drop that from the powerpc arch code, which I think 
>> means we don't actually need to provide page size to notepage(). 
>> Hopefully that means more code to delete ;)
>>
> 
> Looking at how the generic ptdump code handles KASAN, I'm a bit sceptic.
> 
> IIUC, it is checking that kasan_early_shadow_pte is in the same page as 
> the pgtable referred by the PMD entry. But what happens if that PMD 
> entry is referring another pgtable which is inside the same page as 
> kasan_early_shadow_pte ?
> 
> Shouldn't the test be
> 
>  ????if (pmd_page_vaddr(val) == lm_alias(kasan_early_shadow_pte))
>  ??????? return note_kasan_page_table(walk, addr);

Now I come to look at this code again, I think you're right. On arm64 
this doesn't cause a problem - page tables are page sized and page 
aligned, so there couldn't be any non-KASAN pgtables sharing the page. 
Obviously that's not necessarily true of other architectures.

Feel free to add a patch to your series ;)

Steve


From alexandre.torgue at foss.st.com  Mon Apr 19 15:04:01 2021
From: alexandre.torgue at foss.st.com (Alexandre TORGUE)
Date: Mon, 19 Apr 2021 16:04:01 +0200
Subject: [PATCH 12/13] ARM: dts: stm32: fix DSI port node on STM32MP15
In-Reply-To: <CAK8P3a1bGAUbqTGqyz+PB=7fuVLkJce0awtx1Z9PE3uiX6uysQ@mail.gmail.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-13-alexandre.torgue@foss.st.com>
 <ececc78c-4fca-bb93-ef62-5d107501d963@pengutronix.de>
 <96da49dc-f24d-aa12-e1d8-39b5a5b6fbc9@foss.st.com>
 <CAK8P3a1bGAUbqTGqyz+PB=7fuVLkJce0awtx1Z9PE3uiX6uysQ@mail.gmail.com>
Message-ID: <f37abf6d-f82b-e253-d9f9-772df0b800d1@foss.st.com>



On 4/19/21 3:57 PM, Arnd Bergmann wrote:
> On Thu, Apr 15, 2021 at 2:23 PM Alexandre TORGUE
> <alexandre.torgue at foss.st.com> wrote:
>> On 4/15/21 12:43 PM, Ahmad Fatoum wrote:
>>> On 15.04.21 12:10, Alexandre Torgue wrote:
>>>> Running "make dtbs_check W=1", some warnings are reported concerning
>>>> DSI. This patch reorder DSI nodes to avoid:
>>>>
>>>> soc/dsi at 5a000000: unnecessary #address-cells/#size-cells without
>>>> "ranges" or child "reg" property
>>>
>>> This reverts parts of commit 9c32f980d9 ("ARM: dts: stm32: preset
>>> stm32mp15x video #address- and #size-cells"):
>>>
>>>       The cell count for address and size is defined by the binding and not
>>>       something a board would change. Avoid each board adding this
>>>       boilerplate by having the cell size specification in the SoC DTSI.
>>>
>>>
>>> The DSI can have child nodes with a unit address (e.g. a panel) and ones
>>> without (ports { } container). ports is described in the dtsi, panels are
>>> described in the dts if available.
>>>
>>> Apparently, the checker is fine with
>>> ports {
>>>        #address-cells = <1>;
>>>        #size-cells = <0>;
>>> };
>>>
>>> I think my rationale for the patch above was sound, so I think the checker
>>> taking offense at the DSI cells here should be considered a false positive.
>>
>> If it's a "false positive" warning then we need to find a way to not
>> print it out. Else, it'll be difficult to distinguish which warnings are
>> "normal" and which are not. This question could also be applied to patch[3].
>>
>> Arnd, Rob what is your feeling about this case ?
> 
> I don't have a strong opinion on this either way, but I would just
> not apply this one for 5.13 in this case. Rob, Alexandre, please
> let me know if I should apply the other patches before the
> merge window, I usually don't mind taking bugfixes late before the
> merge window, but I still want some level of confidence that they
> are actually correct.

For me, we can keep this series for the v5.14 cycle.

regards
alex

> 
> Ahmad, if you feel strongly about this particular issue, would you like
> to suggest a patch for the checker?
> 
>          Arnd
> 


From kernelfans at gmail.com  Mon Apr 19 15:10:57 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Mon, 19 Apr 2021 22:10:57 +0800
Subject: [RFC 8/8] arm64/head: convert idmap_pg_dir and init_pg_dir to
 __create_pgd_mapping()
In-Reply-To: <20210410095654.24102-9-kernelfans@gmail.com>
References: <20210410095654.24102-1-kernelfans@gmail.com>
 <20210410095654.24102-9-kernelfans@gmail.com>
Message-ID: <CAFgQCTt9PONoYVk_tXtt_ZU-FN1OfjA+Ga46aJ_mqfKhfQGTRQ@mail.gmail.com>

On Sat, Apr 10, 2021 at 5:57 PM Pingfan Liu <kernelfans at gmail.com> wrote:
>
[...]
>         /*
>          * Map the kernel image (starting with PHYS_OFFSET).
>          */
>         adrp    x0, init_pg_dir
> -       mov_q   x5, KIMAGE_VADDR                // compile time __va(_text)
> -       add     x5, x5, x23                     // add KASLR displacement
> -       mov     x4, PTRS_PER_PGD
> -       adrp    x6, _end                        // runtime __pa(_end)
> -       adrp    x3, _text                       // runtime __pa(_text)
> -       sub     x6, x6, x3                      // _end - _text
> -       add     x6, x6, x5                      // runtime __va(_end)
> +       adrp    x1, init_pg_end
> +       sub     x1, x1, x0
> +       bl      set_cur_mempool
>
> -       map_memory x0, x1, x5, x6, x7, x3, x4, x10, x11, x12, x13, x14
> +       mov     x1, PTRS_PER_PGD
> +       adrp    x3, _text                       // runtime __pa(_text)
> +       mov_q   x4, KIMAGE_VADDR                // compile time __va(_text)
> +       add     x4, x4, x23                     // add KASLR displacement
> +       adrp    x5, _end                        // runtime __pa(_end)
> +       sub     x5, x5, x3                      // _end - _text
> +
> +       ldr     x3, =PAGE_KERNEL_EXEC
> +       adr_l   x4, head_pgtable_alloc
> +       mov     x5, #0
> +       mov     x6, #NO_FIXMAP
> +
> +       bl      create_init_pgd_mapping

This calling convention is wrong, should be changed as the following (
will be updated in v2)
        adrp    x0, init_pg_dir
        adrp    x1, init_pg_end
        sub     x1, x1, x0
        bl      set_cur_mempool
        mov     x0, #0
        mov     x0, #0
        bl      head_pgtable_alloc              // x0 is init_pg_dir

        adrp    x1, _text                       // runtime __pa(_text)
        mov_q   x2, KIMAGE_VADDR                // compile time __va(_text)
        add     x2, x2, x23                     // add KASLR displacement
        adrp    x3, _end                        // runtime __pa(_end)
        sub     x3, x3, x1                      // _end - _text

        ldr     x4, =PAGE_KERNEL_EXEC
        adr_l   x5, head_pgtable_alloc
        mov     x6, #0
        mov     x7, #(NO_FIXMAP | NO_PRINTK | BOOT_HEAD)

        bl      create_init_pgd_mapping

Thanks,
Pingfan


From andy.shevchenko at gmail.com  Mon Apr 19 15:14:13 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 17:14:13 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
 <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
Message-ID: <CAHp75VdjnNywLF7rt_Q9tw+sJwtm8S-BMU57ve21WGVoADFtuA@mail.gmail.com>

On Mon, Apr 19, 2021 at 4:58 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:

> > > In any case it's not true. We have the platform drivers w/o legacy
> > > users that are not dependent on OF.
> >
> > Example? ;-)
>
> i2c-owl.c

In case you want more
sound/sparc/amd7930.c

And I believe I can find zillions of them.

-- 
With Best Regards,
Andy Shevchenko


From geert at linux-m68k.org  Mon Apr 19 15:15:36 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 19 Apr 2021 16:15:36 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
 <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
Message-ID: <CAMuHMdX1D+2iLPEDzG9BiR8bu-dEBmE-=w0nFMhF8ojD7rCfzg@mail.gmail.com>

Hi Andy,

On Mon, Apr 19, 2021 at 3:58 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > On Mon, Apr 19, 2021 at 3:35 PM Andy Shevchenko
> > <andy.shevchenko at gmail.com> wrote:
> > > On Mon, Apr 19, 2021 at 4:02 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > On Thu, Apr 15, 2021 at 10:50 AM Andy Shevchenko
> > > > <andy.shevchenko at gmail.com> wrote:
> > > > > On Thu, Apr 15, 2021 at 3:43 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > > > > > On Wed, Apr 14, 2021 at 9:14 PM Andy Shevchenko
> > > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > > On Wed, Apr 14, 2021 at 08:55:21PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > On Wed, Apr 14, 2021 at 8:18 PM Andy Shevchenko
> > > > > > > > <andriy.shevchenko at linux.intel.com> wrote:
> > > > > > > > > On Wed, Apr 14, 2021 at 08:06:18PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > On Wed, Apr 14, 2021 at 11:24 AM Yicong Yang <yangyicong at hisilicon.com> wrote:
> > >
> > > ...
> > >
> > > > > > > > > > I guess it's still fine to add a dependency on ACPI?
> > > > > > > > >
> > > > > > > > > But why?
> > > > > > > >
> > > > > > > > Please tell me how/when the driver is used when CONFIG_ACPI=n.
> > > > > > >
> > > > > > > I'm not using it at all. Ask the author :-)
> > > > > > >
> > > > > > > But if we follow your logic, then we need to mark all the _platform_ drivers
> > > > > > > for x86 world as ACPI dependent? This sounds ugly.
> > > > > >
> > > > > > Do all other x86 platform drivers have (1) an .acpi_match_table[] and
> > > > > > (2) no other way of instantiating their devices?
> > > > > > The first driver from the top of my memory I looked at is rtc-cmos:
> > > > > > it has no .acpi_match_table[], and the rtc-cmos device is instantiated
> > > > > > from arch/x86/kernel/rtc.c.
> > > > > >
> > > > > > For drivers with only an .of_match_table(), and no legacy users
> > > > > > instantiating platform devices, we do have dependencies on OF.
> > > > >
> > > > > This is not true. Entire IIO subsystem is an example.
> > > >
> > > > Do you care to elaborate?
> > > > Three quarters of the IIO drivers are I2C and SPI drivers, and thus not
> > > > subject to the above.
> > >
> > > It seems I missed that you are talking about platform device drivers.
> >
> > OK.
> >
> > > In any case it's not true. We have the platform drivers w/o legacy
> > > users that are not dependent on OF.
> >
> > Example? ;-)
>
> i2c-owl.c

I2C_OWL depends on ARCH_ACTIONS || COMPILE_TEST

(arm32) ARCH_ACTIONS depends on ARCH_MULTI_V7
                     depends on ARCH_MULTIPLATFORM
                     ARCH_MULTIPLATFORM selects USE_OF
                     USE_OF selects OF
ARCH_MULTI_V7 selects ARCH_MULTI_V6_V7

(arm64) ARM64 selects OF

so we do have a dependency on OF, unless we're compile-testing.

> > > They may _indirectly_ be dependent, but this is fine as I stated above
> > > when suggested to move ACPI dependency on ARCH_xxx level.
> >
> > As per the response from the driver maintainer
> > https://lore.kernel.org/linux-arm-kernel/bd8db435-24e1-5ab3-6b35-1d4d8a292a7e at hisilicon.com/,
> > there is no dependency on ARCH_HISI, so moving the ACPI dependency
> > up won't help.
>
> So, an ACPI dependency is simply not applicable here as it's a compile
> dependency as well, which is not a limitation for this driver. Again,
> talk to Masahiro how to handle this, but I don't see any good
> justification to have ACPI (compile time) dependency here. So, again
> NAK!

Please tell me how this driver will be probed when CONFIG_ACPI
is disabled (it cannot, as nothing instantiates platform devices of the
right type, so there is no reason to bother the user with a question about
this driver when configuring his kernel).

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  Mon Apr 19 15:18:28 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 19 Apr 2021 16:18:28 +0200
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAHp75VdjnNywLF7rt_Q9tw+sJwtm8S-BMU57ve21WGVoADFtuA@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
 <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
 <CAHp75VdjnNywLF7rt_Q9tw+sJwtm8S-BMU57ve21WGVoADFtuA@mail.gmail.com>
Message-ID: <CAMuHMdVwWLpS-N2fvihLcJ9RsAppzRMd5ZQhra-sz6EFavhy2g@mail.gmail.com>

Hi Andy,

On Mon, Apr 19, 2021 at 4:14 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Mon, Apr 19, 2021 at 4:58 PM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> > On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> > > > In any case it's not true. We have the platform drivers w/o legacy
> > > > users that are not dependent on OF.
> > >
> > > Example? ;-)
> >
> > i2c-owl.c
>
> In case you want more
> sound/sparc/amd7930.c

SND_SUN_AMD7930 depends on SND_SPARC && SBUS
SND_SPARC depends on SPARC
SPARC selects OF

Hence, SND_SUN_AMD7930 depends on OF.

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 andy.shevchenko at gmail.com  Mon Apr 19 15:27:47 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 17:27:47 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdVwWLpS-N2fvihLcJ9RsAppzRMd5ZQhra-sz6EFavhy2g@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
 <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
 <CAHp75VdjnNywLF7rt_Q9tw+sJwtm8S-BMU57ve21WGVoADFtuA@mail.gmail.com>
 <CAMuHMdVwWLpS-N2fvihLcJ9RsAppzRMd5ZQhra-sz6EFavhy2g@mail.gmail.com>
Message-ID: <CAHp75Vc5yGALSh2pxt6z_6bsyFweuu+vPH6dFKQtBMzXM-dY6Q@mail.gmail.com>

On Mon, Apr 19, 2021 at 5:18 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Mon, Apr 19, 2021 at 4:14 PM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> > On Mon, Apr 19, 2021 at 4:58 PM Andy Shevchenko
> > <andy.shevchenko at gmail.com> wrote:
> > > On Mon, Apr 19, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> >
> > > > > In any case it's not true. We have the platform drivers w/o legacy
> > > > > users that are not dependent on OF.
> > > >
> > > > Example? ;-)
> > >
> > > i2c-owl.c
> >
> > In case you want more
> > sound/sparc/amd7930.c
>
> SND_SUN_AMD7930 depends on SND_SPARC && SBUS
> SND_SPARC depends on SPARC
> SPARC selects OF
>
> Hence, SND_SUN_AMD7930 depends on OF.

Exactly my point. Read back what I wrote.

TL;DR: It's *fine* to have _indirect_ dependency like this.

-- 
With Best Regards,
Andy Shevchenko


From bjorn.andersson at linaro.org  Mon Apr 19 15:32:25 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 19 Apr 2021 09:32:25 -0500
Subject: [PATCH V3 2/4] soc: qcom: dcc:Add driver support for Data
 Capture and Compare unit(DCC)
In-Reply-To: <ffc2076e7145af0099bab8ef37611556@codeaurora.org>
References: <cover.1618387606.git.schowdhu@codeaurora.org>
 <59b2e83d5d0f435112f6ae266612ff91c85b120f.1618387606.git.schowdhu@codeaurora.org>
 <87k0p4njni.fsf@kernel.org>
 <ffc2076e7145af0099bab8ef37611556@codeaurora.org>
Message-ID: <20210419143225.GO1538589@yoga>

On Mon 19 Apr 05:32 CDT 2021, schowdhu at codeaurora.org wrote:

> On 2021-04-15 12:01, Felipe Balbi wrote:
> > Hi,
> > 
> > Souradeep Chowdhury <schowdhu at codeaurora.org> writes:
> > > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> > > index ad675a6..e7f0ccb 100644
> > > --- a/drivers/soc/qcom/Makefile
> > > +++ b/drivers/soc/qcom/Makefile
> > > @@ -1,19 +1,22 @@
> > >  # SPDX-License-Identifier: GPL-2.0
> > >  CFLAGS_rpmh-rsc.o := -I$(src)
> > >  obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
> > > -obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
> > > +obj-$(CONFIG_QCOM_APR) += apr.o
> > >  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> > >  obj-$(CONFIG_QCOM_CPR)		+= cpr.o
> > > +obj-$(CONFIG_QCOM_DCC) += dcc.o
> > > +obj-$(CONFIG_QCOM_GENI_SE) +=   qcom-geni-se.o
> > >  obj-$(CONFIG_QCOM_GSBI)	+=	qcom_gsbi.o
> > > +obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) += kryo-l2-accessors.o
> > > +obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
> > >  obj-$(CONFIG_QCOM_MDT_LOADER)	+= mdt_loader.o
> > >  obj-$(CONFIG_QCOM_OCMEM)	+= ocmem.o
> > >  obj-$(CONFIG_QCOM_PDR_HELPERS)	+= pdr_interface.o
> > >  obj-$(CONFIG_QCOM_QMI_HELPERS)	+= qmi_helpers.o
> > > -qmi_helpers-y	+= qmi_encdec.o qmi_interface.o
> > >  obj-$(CONFIG_QCOM_RMTFS_MEM)	+= rmtfs_mem.o
> > >  obj-$(CONFIG_QCOM_RPMH)		+= qcom_rpmh.o
> > > -qcom_rpmh-y			+= rpmh-rsc.o
> > > -qcom_rpmh-y			+= rpmh.o
> > > +obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
> > > +obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
> > >  obj-$(CONFIG_QCOM_SMD_RPM)	+= smd-rpm.o
> > >  obj-$(CONFIG_QCOM_SMEM) +=	smem.o
> > >  obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
> > > @@ -21,8 +24,6 @@ obj-$(CONFIG_QCOM_SMP2P)	+= smp2p.o
> > >  obj-$(CONFIG_QCOM_SMSM)	+= smsm.o
> > >  obj-$(CONFIG_QCOM_SOCINFO)	+= socinfo.o
> > >  obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
> > > -obj-$(CONFIG_QCOM_APR) += apr.o
> > > -obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
> > > -obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
> > > -obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
> > > -obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=	kryo-l2-accessors.o
> > > +qmi_helpers-y   += qmi_encdec.o qmi_interface.o
> > > +qcom_rpmh-y                     += rpmh-rsc.o
> > > +qcom_rpmh-y                     += rpmh.o
> > 
> > why so many changes?
> 
> This has been accidentally sorted based on the config names. Will be fixing
> this in next version of the patch.
> 
> > 
> > > diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> > > new file mode 100644
> > > index 0000000..fcd5580
> > > --- /dev/null
> > > +++ b/drivers/soc/qcom/dcc.c
> > > @@ -0,0 +1,1539 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) 2015-2021, The Linux Foundation. All rights
> > > reserved.
> > > + */
> > > +
> > > +#include <linux/bitfield.h>
> > > +#include <linux/bitops.h>
> > > +#include <linux/cdev.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/fs.h>
> > > +#include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/uaccess.h>
> > > +
> > > +
> > 
> > one blank line is enough
> 
> Ack
> 
> > 
> > > +#define TIMEOUT_US		100
> > > +
> > > +#define dcc_writel(drvdata, val, off)					\
> > > +	writel((val), drvdata->base + dcc_offset_conv(drvdata, off))
> > > +#define dcc_readl(drvdata, off)						\
> > > +	readl(drvdata->base + dcc_offset_conv(drvdata, off))
> > > +
> > > +#define dcc_sram_readl(drvdata, off)					\
> > > +	readl(drvdata->ram_base + off)
> > 
> > this would be probably be better as static inlines.
> 
> These are simple read and write operations used in the driver
> which just calls the generic writel and readl function.
> That's why macros have been used here to lesson the overhead
> of an extra function call.

The compiler will realize that your static dcc_sram_readl() is cheaper
to inline than call and do so for you. So you can expect that there's no
difference in the output from the compiler, and if there is then the
compiler knows something that you're overlooking.

Regards,
Bjorn


From bjorn.andersson at linaro.org  Mon Apr 19 15:38:02 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 19 Apr 2021 09:38:02 -0500
Subject: [PATCHv2 2/2] iommu/arm-smmu-qcom: Move the adreno smmu specific
 impl earlier
In-Reply-To: <c607d71eb0fe507c8b83cc0ea9b393777f22149a.1614332994.git.saiprakash.ranjan@codeaurora.org>
References: <cover.1614332994.git.saiprakash.ranjan@codeaurora.org>
 <c607d71eb0fe507c8b83cc0ea9b393777f22149a.1614332994.git.saiprakash.ranjan@codeaurora.org>
Message-ID: <20210419143802.GP1538589@yoga>

On Fri 26 Feb 03:55 CST 2021, Sai Prakash Ranjan wrote:

> Adreno(GPU) SMMU and APSS(Application Processor SubSystem) SMMU
> both implement "arm,mmu-500" in some QTI SoCs and to run through
> adreno smmu specific implementation such as enabling split pagetables
> support, we need to match the "qcom,adreno-smmu" compatible first
> before apss smmu or else we will be running apps smmu implementation
> for adreno smmu and the additional features for adreno smmu is never
> set. For ex: we have "qcom,sc7280-smmu-500" compatible for both apps
> and adreno smmu implementing "arm,mmu-500", so the adreno smmu
> implementation is never reached because the current sequence checks
> for apps smmu compatible(qcom,sc7280-smmu-500) first and runs that
> specific impl and we never reach adreno smmu specific implementation.
> 
> Suggested-by: Akhil P Oommen <akhilpo at codeaurora.org>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan at codeaurora.org>

Sorry for taking my time thinking about this.

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 12 +++++++++---
>  1 file changed, 9 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 bea3ee0dabc2..03f048aebb80 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -345,11 +345,17 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
>  {
>  	const struct device_node *np = smmu->dev->of_node;
>  
> -	if (of_match_node(qcom_smmu_impl_of_match, np))
> -		return qcom_smmu_create(smmu, &qcom_smmu_impl);
> -
> +	/*
> +	 * Do not change this order of implementation, i.e., first adreno
> +	 * smmu impl and then apss smmu since we can have both implementing
> +	 * arm,mmu-500 in which case we will miss setting adreno smmu specific
> +	 * features if the order is changed.
> +	 */
>  	if (of_device_is_compatible(np, "qcom,adreno-smmu"))
>  		return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
>  
> +	if (of_match_node(qcom_smmu_impl_of_match, np))
> +		return qcom_smmu_create(smmu, &qcom_smmu_impl);
> +
>  	return smmu;
>  }
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 


From andy.shevchenko at gmail.com  Mon Apr 19 15:39:23 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 19 Apr 2021 17:39:23 +0300
Subject: [PATCH] i2c: I2C_HISI should depend on ARCH_HISI && ACPI
In-Reply-To: <CAMuHMdX1D+2iLPEDzG9BiR8bu-dEBmE-=w0nFMhF8ojD7rCfzg@mail.gmail.com>
References: <26db9291095c1dfd81c73b0f5f1434f9b399b1f5.1618316565.git.geert+renesas@glider.be>
 <bd8db435-24e1-5ab3-6b35-1d4d8a292a7e@hisilicon.com>
 <CAMuHMdVouD+e4GpN_Dur8HSop4B8HVosGSYw7vfTpBEi_inMbw@mail.gmail.com>
 <YHcx+QPbkTA0bv9V@smile.fi.intel.com>
 <CAMuHMdUkDcdZk5YYnkMH+VD4JXFq4khR2dn8wBdSXs1GCT9UMQ@mail.gmail.com>
 <YHc+/MOWA6rO+1Wy@smile.fi.intel.com>
 <CAMuHMdWZz6QNQbN53Whjfi122PWesM4_+K0_m=np8L=E+=io6g@mail.gmail.com>
 <CAHp75VcFjRBO+0578jWam3+sc24KvKArTtQV+nRCCbV1E++Nsg@mail.gmail.com>
 <CAMuHMdVu4VRgJzfM=P8OBi55rsCMFB1vmSepTvSyv1DLjw9Vcw@mail.gmail.com>
 <CAHp75Vcye9HPSoAkqiqnzgQ+8_SZ-W9gURWmWXd5s-y_fji5Ug@mail.gmail.com>
 <CAMuHMdU5AVdq5fubt69u6cOBJR8gwi=LcmePf46yi9_1srtsGA@mail.gmail.com>
 <CAHp75VdbYSD=unX4bbiWFXYPJJbW5b_j0kUO7S-HbO2btDvipw@mail.gmail.com>
 <CAMuHMdX1D+2iLPEDzG9BiR8bu-dEBmE-=w0nFMhF8ojD7rCfzg@mail.gmail.com>
Message-ID: <CAHp75VfPsq+Bv=nbFtbLyU3=ihEdHhEWpZO+1SEutPz_ByELtw@mail.gmail.com>

On Mon, Apr 19, 2021 at 5:15 PM Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Mon, Apr 19, 2021 at 3:58 PM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:

> Please tell me how this driver will be probed when CONFIG_ACPI
> is disabled (it cannot, as nothing instantiates platform devices of the
> right type, so there is no reason to bother the user with a question about
> this driver when configuring his kernel).

Go ahead with it in v2. I'll not block you.

-- 
With Best Regards,
Andy Shevchenko


From arnd at arndb.de  Mon Apr 19 15:44:39 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 19 Apr 2021 16:44:39 +0200
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13, v2
In-Reply-To: <CACPK8Xeet50bqWAY0jG_GRkgvKvFn94XtGDaq1gaVYVkyV_JUQ@mail.gmail.com>
References: <CACPK8Xeet50bqWAY0jG_GRkgvKvFn94XtGDaq1gaVYVkyV_JUQ@mail.gmail.com>
Message-ID: <CAK8P3a1rG6qKjVvr86G=6cgkhReQUbsvQAkdxg7A2HsJ7n499A@mail.gmail.com>

On Fri, Apr 16, 2021 at 5:27 AM Joel Stanley <joel at jms.id.au> wrote:
>
> Hello Soc maintainers,
>
> Here are some fixes for the changes that have already been merged for v5.13.
>
> I also merged some changes that came in later. If you would prefer to
> not take them then I can send a pull with just the fixes.
>
> The following changes since commit f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:
>
> for you to fetch changes up to f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:

Hi Joel,

something about this pull request doesn't add up, and 'b4' refuses
to pull it since the 'since commit f0145db2' and 'up to f0145db2'
references refer to the same commit.

I assume this is just a copy-paste error on your end, but it would
be nice if you could double-check and resend the pull request
based on the ee33e2fb3d70 commit that I merged.

       Arnd


From s-anna at ti.com  Mon Apr 19 15:50:01 2021
From: s-anna at ti.com (Suman Anna)
Date: Mon, 19 Apr 2021 09:50:01 -0500
Subject: [PATCH] ARM: dts: keystone-k2g: Rename message-manager node
In-Reply-To: <20210414001926.20002-1-nm@ti.com>
References: <20210414001926.20002-1-nm@ti.com>
Message-ID: <e52fe654-a9b7-ca49-d501-1dd01159c787@ti.com>

On 4/13/21 7:19 PM, Nishanth Menon wrote:
> Rename message-manager instance node name to be better aligned with
> current style of device tree nodes for mailboxes.
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>

Acked-by: Suman Anna <s-anna at ti.com>

> ---
> 
> Santosh:
> - This is'nt critical to queue up for 5.13-rc1 window, but just getting
>   it out of the way. I noticed it as I was converting the binding to
>   yaml. (patch for yaml conversion for the node follows)
> 
>  arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
> index 05a75019275e..e5c813b5556d 100644
> --- a/arch/arm/boot/dts/keystone-k2g.dtsi
> +++ b/arch/arm/boot/dts/keystone-k2g.dtsi
> @@ -242,7 +242,7 @@ dsp0: dsp at 10800000 {
>  			status = "disabled";
>  		};
>  
> -		msgmgr: msgmgr at 2a00000 {
> +		msgmgr: mailbox at 2a00000 {
>  			compatible = "ti,k2g-message-manager";
>  			#mbox-cells = <2>;
>  			reg-names = "queue_proxy_region",
> 



From ilya.lipnitskiy at gmail.com  Mon Apr 19 16:04:10 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 08:04:10 -0700
Subject: [PATCH net-next 2/2] net: ethernet: mediatek: support custom GMAC
 label
In-Reply-To: <YH10UNuJZ5s7dfLh@lunn.ch>
References: <20210419040352.2452-1-ilya.lipnitskiy@gmail.com>
 <20210419040352.2452-3-ilya.lipnitskiy@gmail.com> <YH10UNuJZ5s7dfLh@lunn.ch>
Message-ID: <CALCv0x2SSGjiqKOBhK1GT2ksjc9J--Qm3Uq-0xc3sgHvDju5-A@mail.gmail.com>

On Mon, Apr 19, 2021 at 5:15 AM Andrew Lunn <andrew at lunn.ch> wrote:
>
> On Sun, Apr 18, 2021 at 09:03:52PM -0700, Ilya Lipnitskiy wrote:
> > The MAC device name can now be set within DTS file instead of always
> > being "ethX". This is helpful for DSA to clearly label the DSA master
> > device and distinguish it from DSA slave ports.
> >
> > For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> > ports labeled ethX. Labeling the master GMAC with a different prefix
> > than DSA ports helps with clarity.
> >
> > Suggested-by: Ren? van Dorst <opensource at vdorst.com>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > ---
> >  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > index 6b00c12c6c43..4c0ce4fb7735 100644
> > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
> >
> >  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >  {
> > +     const char *label = of_get_property(np, "label", NULL);
> >       const __be32 *_id = of_get_property(np, "reg", NULL);
> >       phy_interface_t phy_mode;
> >       struct phylink *phylink;
> > @@ -2940,6 +2941,9 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >       else
> >               eth->netdev[id]->max_mtu = MTK_MAX_RX_LENGTH_2K - MTK_RX_ETH_HLEN;
> >
> > +     if (label)
> > +             strscpy(eth->netdev[id]->name, label, IFNAMSIZ);
>
> It is better to use alloc_netdev_mqs() so you get validation the name
> is unique.
It doesn't look like the name validation happens until the netdev is
registered, and it does not get registered at alloc, right?

I do agree that it's better to use the correct name in the first place
instead of renaming, regardless, so using alloc_netdev_mqs() seems
like a better solution - I'll make the change.

Ilya


From bjorn.andersson at linaro.org  Mon Apr 19 16:09:56 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 19 Apr 2021 10:09:56 -0500
Subject: [GIT PULL] More Qualcomm DTS updates for 5.13
Message-ID: <20210419150956.860423-1-bjorn.andersson@linaro.org>

The following changes since commit 885aae6860fae1eed38f5cc1ac09a40e4896a38c:

  ARM: dts: qcom: msm8974-klte: Add bluetooth support (2021-04-06 11:53:16 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-dts-for-5.13-2

for you to fetch changes up to 06ad53efeb496d8841169ec0919ba6852c7852f6:

  ARM: dts: qcom: sdx55: add IPA information (2021-04-13 21:35:56 -0500)

----------------------------------------------------------------
More Qualcomm DTS updates for 5.13

This adds CPUfreq, interconnect providers, IPC, remoteproc and IPA to
the SDX55 platform and then adds board files for the Telit FN980 TLB and
Thundercomm TurboX T55.

----------------------------------------------------------------
Alex Elder (1):
      ARM: dts: qcom: sdx55: add IPA information

Manivannan Sadhasivam (14):
      ARM: dts: qcom: sdx55: Add support for A7 PLL clock
      ARM: dts: qcom: sdx55: Add support for APCS block
      ARM: dts: qcom: sdx55: Add CPUFreq support
      ARM: dts: qcom: sdx55: Add modem SMP2P node
      ARM: dts: qcom: sdx55: Add IMEM and PIL info region
      dt-bindings: firmware: scm: Add compatible for SDX55
      ARM: dts: qcom: sdx55: Add SCM node
      ARM: dts: qcom: sdx55: Add interconnect nodes
      ARM: dts: qcom: Fix node name for NAND controller node
      ARM: dts: qcom: sdx55: Add Modem remoteproc node
      dt-bindings: arm: qcom: Add binding for Telit FN980 TLB board
      ARM: dts: qcom: sdx55: Add basic devicetree support for Telit FN980 TLB
      dt-bindings: arm: qcom: Add binding for Thundercomm T55 kit
      ARM: dts: qcom: sdx55: Add basic devicetree support for Thundercomm T55

 Documentation/devicetree/bindings/arm/qcom.yaml    |   2 +
 .../devicetree/bindings/firmware/qcom,scm.txt      |   1 +
 arch/arm/boot/dts/Makefile                         |   4 +-
 arch/arm/boot/dts/qcom-ipq4019.dtsi                |   2 +-
 arch/arm/boot/dts/qcom-sdx55-t55.dts               | 281 ++++++++++++++++++++
 arch/arm/boot/dts/qcom-sdx55-telit-fn980-tlb.dts   | 282 +++++++++++++++++++++
 arch/arm/boot/dts/qcom-sdx55.dtsi                  | 207 ++++++++++++++-
 7 files changed, 776 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-sdx55-t55.dts
 create mode 100644 arch/arm/boot/dts/qcom-sdx55-telit-fn980-tlb.dts


From ilya.lipnitskiy at gmail.com  Mon Apr 19 16:12:18 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 08:12:18 -0700
Subject: [PATCH] dt-bindings: net: mediatek: support MT7621 SoC
In-Reply-To: <878s5e94hi.fsf@miraculix.mork.no>
References: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>
 <878s5e94hi.fsf@miraculix.mork.no>
Message-ID: <CALCv0x1Z2rXJtRTh9WQfPMBfVkfosg00kqEmo1uB6RJeNLptJw@mail.gmail.com>

On Sun, Apr 18, 2021 at 11:24 PM Bj?rn Mork <bjorn at mork.no> wrote:
>
> Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com> writes:
>
> > Add missing binding documentation for SoC support that has been in place
> > since v5.1
> >
> > Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware")
> > Cc: Bj?rn Mork <bjorn at mork.no>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > ---
> >  Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > index 72d03e07cf7c..950ef6af20b1 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> > +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > @@ -10,6 +10,7 @@ Required properties:
> >  - compatible: Should be
> >               "mediatek,mt2701-eth": for MT2701 SoC
> >               "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
> > +             "mediatek,mt7621-eth": for MT7621 SoC
> >               "mediatek,mt7622-eth": for MT7622 SoC
> >               "mediatek,mt7629-eth": for MT7629 SoC
> >               "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
>
>
> Thanks for taking care of this!
>
> Note, however, that this compatible value is defined in
> Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
Good point. I don't think there is a driver in-tree for that binding.
It looks like commit 663148e48a66 ("Documentation: DT: net: add docs
for ralink/mediatek SoC ethernet binding") should just be reverted and
the three documents (mediatek,mt7620-gsw.txt; ralink,rt2880-net.txt;
ralink,rt3050-esw.txt) removed. Any objections?

Ilya


From michal.simek at xilinx.com  Mon Apr 19 16:14:35 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 19 Apr 2021 17:14:35 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <5176e9bc-50a0-6952-0e5a-8e43095235eb@web.de>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
 <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
 <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>
 <2f2e3019-afdd-103f-b984-06e65b10fc50@xilinx.com>
 <5176e9bc-50a0-6952-0e5a-8e43095235eb@web.de>
Message-ID: <0c51ebbf-c17f-9418-f312-a6b0aaa5b8c1@xilinx.com>



On 4/19/21 1:48 PM, Jan Kiszka wrote:
> On 19.04.21 12:52, Michal Simek wrote:
>> Hi Jan,
>>
>> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>>> On 01.04.21 16:52, Jan Kiszka wrote:
>>>> On 01.04.21 13:42, Michal Simek wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>>
>>>>>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>>>>>> ---
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>>>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>> new file mode 100644
>>>>>>> index 0000000..9868ca1
>>>>>>> --- /dev/null
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>> @@ -0,0 +1,222 @@
>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>> +/*
>>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>>> + *
>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>> + *
>>>>>>> + * Michal Simek <michal.simek at xilinx.com>
>>>>>>> + */
>>>>>>> +
>>>>>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>>>>>> +/ {
>>>>>>> +	pss_ref_clk: pss_ref_clk {
>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>> +		compatible = "fixed-clock";
>>>>>>> +		#clock-cells = <0>;
>>>>>>> +		clock-frequency = <33333333>;
>>>>>>> +	};
>>>>>>> +
>>>>>>> +	video_clk: video_clk {
>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>> +		compatible = "fixed-clock";
>>>>>>> +		#clock-cells = <0>;
>>>>>>> +		clock-frequency = <27000000>;
>>>>>>> +	};
>>>>>>> +
>>>>>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>> +		compatible = "fixed-clock";
>>>>>>> +		#clock-cells = <0>;
>>>>>>> +		clock-frequency = <0>;
>>>>>>> +	};
>>>>>>> +
>>>>>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>> +		compatible = "fixed-clock";
>>>>>>> +		#clock-cells = <0>;
>>>>>>> +		clock-frequency = <108000000>;
>>>>>>> +	};
>>>>>>> +
>>>>>>> +	aux_ref_clk: aux_ref_clk {
>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>> +		compatible = "fixed-clock";
>>>>>>> +		#clock-cells = <0>;
>>>>>>> +		clock-frequency = <27000000>;
>>>>>>> +	};
>>>>>>> +};
>>>>>>> +
>>>>>>> +&can0 {
>>>>>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&can1 {
>>>>>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cpu0 {
>>>>>>> +	clocks = <&zynqmp_clk ACPU>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan1 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan2 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan3 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan4 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan5 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan6 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan7 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&fpd_dma_chan8 {
>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan1 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan2 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan3 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan4 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan5 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan6 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan7 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&lpd_dma_chan8 {
>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&gem0 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>>>>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&gem1 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>>>>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&gem2 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>>>>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&gem3 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>>>>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&gpio {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&i2c0 {
>>>>>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&i2c1 {
>>>>>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&pcie {
>>>>>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&sata {
>>>>>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&sdhci0 {
>>>>>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&sdhci1 {
>>>>>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&spi0 {
>>>>>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&spi1 {
>>>>>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&ttc0 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&ttc1 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&ttc2 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&ttc3 {
>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&uart0 {
>>>>>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&uart1 {
>>>>>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb0 {
>>>>>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb1 {
>>>>>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&watchdog0 {
>>>>>>> +	clocks = <&zynqmp_clk WDT>;
>>>>>>> +};
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>> index 0f7b4cf..2e05fa4 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZC1232
>>>>>>>   *
>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>
>>>>>>>  / {
>>>>>>>  	model = "ZynqMP ZC1232 RevA";
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>> index 9092828..3d0aaa0 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZC1254
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>
>>>>>>>  / {
>>>>>>>  	model = "ZynqMP ZC1254 RevA";
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>> index 4f404c5..1a8127d4 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>
>>>>>>>  / {
>>>>>>>  	model = "ZynqMP ZC1275 RevA";
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>> index 9a3e39d..fa7eb1b 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>>  / {
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>> index 2421ec7..4191dfa 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>>  / {
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>> index 7a49dee..3750690 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>>>>>   *
>>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>
>>>>>>>  / {
>>>>>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>> index 54c7b4f..2366cd9 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>
>>>>>>>  / {
>>>>>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>> index b8b5ff1..9a894e6 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>>  / {
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>> index e5699d0..3e39454 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>>>>>   *
>>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   * Nathalie Chan King Choy
>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>> index 2a3b665..f6e9558 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>>>>>   *
>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>> index 8f45614..f457f8a 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZCU104
>>>>>>>   *
>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>>  / {
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>> index 93ce7eb..f15b99a 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZCU106
>>>>>>>   *
>>>>>>> - * (C) Copyright 2016, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>> index 8bb0001..e27cd60 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP ZCU111
>>>>>>>   *
>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   */
>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>  /dts-v1/;
>>>>>>>
>>>>>>>  #include "zynqmp.dtsi"
>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>> index 9aa6734..59a547b 100644
>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>  /*
>>>>>>>   * dts file for Xilinx ZynqMP
>>>>>>>   *
>>>>>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>>>>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>>>>>   *
>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>   *
>>>>>>> @@ -124,6 +124,28 @@
>>>>>>>  			     <1 10 0xf08>;
>>>>>>>  	};
>>>>>>>
>>>>>>> +	firmware {
>>>>>>> +		zynqmp_firmware: zynqmp-firmware {
>>>>>>> +			compatible = "xlnx,zynqmp-firmware";
>>>>>>> +			method = "smc";
>>>>>>> +			zynqmp_clk: clock-controller {
>>>>>>> +				u-boot,dm-pre-reloc;
>>>>>>> +				#clock-cells = <1>;
>>>>>>> +				compatible = "xlnx,zynqmp-clk";
>>>>>>> +				clocks = <&pss_ref_clk>,
>>>>>>> +					 <&video_clk>,
>>>>>>> +					 <&pss_alt_ref_clk>,
>>>>>>> +					 <&aux_ref_clk>,
>>>>>>> +					 <&gt_crx_ref_clk>;
>>>>>>> +				clock-names = "pss_ref_clk",
>>>>>>> +					      "video_clk",
>>>>>>> +					      "pss_alt_ref_clk",
>>>>>>> +					      "aux_ref_clk",
>>>>>>> +					      "gt_crx_ref_clk";
>>>>>>> +			};
>>>>>>> +		};
>>>>>>> +	};
>>>>>>> +
>>>>>>>  	amba_apu: amba-apu at 0 {
>>>>>>>  		compatible = "simple-bus";
>>>>>>>  		#address-cells = <2>;
>>>>>>>
>>>>>>
>>>>>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>>>>>> Starting from this commit on, I'm no longer getting the kernel to boot
>>>>>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>>>>>> DTBs back before this commit, even a kernel from today's head is fine.
>>>>>>
>>>>>> Further versions of potential relevance:
>>>>>>  - PMUFW 2019.1 and 2020.2
>>>>>>  - TF-A 2.3
>>>>>>  - U-Boot 2020.10
>>>>>>
>>>>>> What's missing? I suspect someone forgot to document a subtle dependency
>>>>>> of this change.
>>>>>
>>>>> Does this fix your issue?
>>>>> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>>>>>
>>>>
>>>> Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
>>>> missing even more. If you have some reference, I'm happy to try. I
>>>> suspect that earlyprintk will also not reveal more without clocks (but I
>>>> didn't play with that yet).
>>>>
>>>> Meanwhile, I'm carrying a revert of this commit and a related cleanup.
>>>> That helps for now.
>>>>
>>>
>>> OK, dependencies resolved (unfortunately the hard way): It either
>>> requires TF-A master or latest release v2.4 + [1] and [2].
>>>
>>> Those TF-A commits were upstream about a year after the firmware-based
>>> clock control hit the kernel. A note would have been nice - or better
>>> sychronization between both upstreaming efforts.
>>
>> I wasn't responsible for TFA but I found this last year in Nov timeframe
>> that none really upstream this. Right now that development is working
>> like that. I am asking everybody to contribute upstream to have all the
>> time upstream heads to work together.
>> I haven't had a time to dig into this but unfortunatelly there is no
>> feature checking mechanism on zynqmp TFA side to check if this is there
>> or not but we are trying our best to check as much as possible but bugs
>> happen.
> 
> OK, I understand. Reminding of "upstream first" is part of my daily
> business as well. :)
> 
> And integration is generally more and more complicated with the growing
> number of firmware services and interfaces, not only on this SOC...
> 
>> And we are lacking space in OCM to be able to add more features to TFA
>> anyway.
> 
> Yeah, I know - I'm also overflowing it via the SDEI patch [1].


I have looked at this. How are you using it now? I haven't had a chance
to take a look at it. How do you use it and test it?

We should try to minimalize amount of code and try to fit to OCM.

Thanks,
Michal



From bjorn.andersson at linaro.org  Mon Apr 19 16:16:37 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 19 Apr 2021 10:16:37 -0500
Subject: [GIT PULL] Even more Qualcomm ARM64 updates for v5.13
Message-ID: <20210419151637.861409-1-bjorn.andersson@linaro.org>

The following changes since commit 7178d4cc0702bfe6a7e0f21e37d6e3dfe8e40f11:

  arm64: dts: qcom: update usb qmp phy clock-cells property (2021-04-08 10:23:25 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-for-5.13-3

for you to fetch changes up to 1b86cc7330895b11df0a7dc15fbbbef60be9f7bb:

  arm64: dts: qcom: sc7180: Update iommu property for simultaneous playback (2021-04-19 10:13:30 -0500)

----------------------------------------------------------------
Even more Qualcomm ARM64 updates for v5.13

This contains three audio related fixes for the sc7180 Trogdor devices.

----------------------------------------------------------------
Douglas Anderson (2):
      arm64: dts: qcom: sc7180: coachz: Add "dmic_clk_en"
      arm64: dts: qcom: sc7180: pompom: Add "dmic_clk_en" + sound model

V Sujith Kumar Reddy (1):
      arm64: dts: qcom: sc7180: Update iommu property for simultaneous playback

 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1.dts | 13 -------------
 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi   | 16 ++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi   |  7 +++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi                  |  3 ++-
 4 files changed, 25 insertions(+), 14 deletions(-)


From bjorn.andersson at linaro.org  Mon Apr 19 16:21:43 2021
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Mon, 19 Apr 2021 10:21:43 -0500
Subject: [GIT PULL] Qualcomm ARM defconfig updates for 5.13
Message-ID: <20210419152143.861934-1-bjorn.andersson@linaro.org>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-defconfig-for-5.13

for you to fetch changes up to 7de91b665600c96b1fc66c4c5a679db275c0c674:

  ARM: configs: qcom_defconfig: Reduce CMA size to 64MB (2021-04-13 21:21:22 -0500)

----------------------------------------------------------------
Qualcomm ARM defconfig updates for 5.13

This enables all the hardware support currently available for the
Qualcomm SDX55 platform in the qcom_defconfig. Due to (current) size
limitations these changes are not done in the multi-platform config.

----------------------------------------------------------------
Manivannan Sadhasivam (7):
      ARM: configs: qcom_defconfig: Enable APCS IPC mailbox driver
      ARM: configs: qcom_defconfig: Enable SDX55 A7 PLL and APCS clock driver
      ARM: configs: qcom_defconfig: Enable CPUFreq support
      ARM: configs: qcom_defconfig: Enable Q6V5_PAS remoteproc driver
      ARM: configs: qcom_defconfig: Enable SDX55 interconnect driver
      ARM: configs: qcom_defconfig: Enable GLINK SMEM driver
      ARM: configs: qcom_defconfig: Reduce CMA size to 64MB

 arch/arm/configs/qcom_defconfig | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)


From ilya.lipnitskiy at gmail.com  Mon Apr 19 16:46:58 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 08:46:58 -0700
Subject: [PATCH net-next v2 1/2] dt-bindings: net: mediatek: add optional GMAC
 labels
In-Reply-To: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210419154659.44096-2-ilya.lipnitskiy@gmail.com>

Document the mediatek ethernet driver change that adds support for
custom labels and provide an example.

Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 72d03e07cf7c..500bf9351010 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -51,6 +51,10 @@ Required properties:
 	is equal to 0 and the MAC uses fixed-link to connect
 	with internal switch such as MT7530.
 
+Optional properties:
+- label: overrides the default netdevice name. Useful when a custom name for the
+	DSA master interface is desired.
+
 Example:
 
 eth: ethernet at 1b100000 {
@@ -74,12 +78,14 @@ eth: ethernet at 1b100000 {
 
 	gmac1: mac at 0 {
 		compatible = "mediatek,eth-mac";
+		label = "gmac1";
 		reg = <0>;
 		phy-handle = <&phy0>;
 	};
 
 	gmac2: mac at 1 {
 		compatible = "mediatek,eth-mac";
+		label = "gmac2";
 		reg = <1>;
 		phy-handle = <&phy1>;
 	};
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Mon Apr 19 16:46:57 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 08:46:57 -0700
Subject: [PATCH net-next v2 0/2] net: ethernet: mediatek: support custom GMAC
 label
Message-ID: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>

Add support for specifying GMAC label via DTS. Useful when it is desired
to use a master DSA interface name that is different from the "eth%d"
pattern.

v2:
  - Use alloc_netdev instead of alloc_etherdev followed by rename

Ilya Lipnitskiy (2):
  dt-bindings: net: mediatek: add optional GMAC labels
  net: ethernet: mediatek: support custom GMAC label

 Documentation/devicetree/bindings/net/mediatek-net.txt | 6 ++++++
 drivers/net/ethernet/mediatek/mtk_eth_soc.c            | 6 ++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Mon Apr 19 16:46:59 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 08:46:59 -0700
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom GMAC
 label
In-Reply-To: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>

The MAC device name can now be set within DTS file instead of always
being "ethX". This is helpful for DSA to clearly label the DSA master
device and distinguish it from DSA slave ports.

For example, some devices, such as the Ubiquiti EdgeRouter X, may have
ports labeled ethX. Labeling the master GMAC with a different prefix
than DSA ports helps with clarity.

Suggested-by: Ren? van Dorst <opensource at vdorst.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6b00c12c6c43..df3cda63a8c5 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
 
 static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 {
+	const char *label = of_get_property(np, "label", NULL);
 	const __be32 *_id = of_get_property(np, "reg", NULL);
 	phy_interface_t phy_mode;
 	struct phylink *phylink;
@@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 		return -EINVAL;
 	}
 
-	eth->netdev[id] = alloc_etherdev(sizeof(*mac));
+	eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
+				       NET_NAME_UNKNOWN, ether_setup);
 	if (!eth->netdev[id]) {
-		dev_err(eth->dev, "alloc_etherdev failed\n");
+		dev_err(eth->dev, "alloc_netdev failed\n");
 		return -ENOMEM;
 	}
 	mac = netdev_priv(eth->netdev[id]);
-- 
2.31.1



From jan.kiszka at web.de  Mon Apr 19 17:10:02 2021
From: jan.kiszka at web.de (Jan Kiszka)
Date: Mon, 19 Apr 2021 18:10:02 +0200
Subject: [PATCH 1/3] arm64: dts: xilinx: Add the clock nodes for zynqmp
In-Reply-To: <0c51ebbf-c17f-9418-f312-a6b0aaa5b8c1@xilinx.com>
References: <1573119856-13548-1-git-send-email-rajan.vaja@xilinx.com>
 <1573119856-13548-2-git-send-email-rajan.vaja@xilinx.com>
 <8b039dac-06c4-6b33-f53b-44b8fa144495@web.de>
 <580bccb2-2e41-aec7-2612-99a2b231f2fc@xilinx.com>
 <09343e7d-fcd8-1a54-470f-c0d8741921b1@web.de>
 <7e8ee1fe-a02d-f6ac-337f-88b35736e1eb@web.de>
 <2f2e3019-afdd-103f-b984-06e65b10fc50@xilinx.com>
 <5176e9bc-50a0-6952-0e5a-8e43095235eb@web.de>
 <0c51ebbf-c17f-9418-f312-a6b0aaa5b8c1@xilinx.com>
Message-ID: <3e6bc055-9baa-7de8-84bf-47d2e8706e3d@web.de>

On 19.04.21 17:14, Michal Simek wrote:
>
>
> On 4/19/21 1:48 PM, Jan Kiszka wrote:
>> On 19.04.21 12:52, Michal Simek wrote:
>>> Hi Jan,
>>>
>>> On 4/18/21 2:12 PM, Jan Kiszka wrote:
>>>> On 01.04.21 16:52, Jan Kiszka wrote:
>>>>> On 01.04.21 13:42, Michal Simek wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 3/27/21 8:55 PM, Jan Kiszka wrote:
>>>>>>> On 07.11.19 10:44, Rajan Vaja wrote:
>>>>>>>> Add clock nodes for zynqmp based on CCF.
>>>>>>>>
>>>>>>>> Signed-off-by: Rajan Vaja <rajan.vaja at xilinx.com>
>>>>>>>> ---
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi     | 222 +++++++++++++++++++++
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts  |   2 +-
>>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts    |   4 +-
>>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts    |   4 +-
>>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts    |   4 +-
>>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts    |   4 +-
>>>>>>>>  .../boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts    |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts  |   4 +-
>>>>>>>>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |  24 ++-
>>>>>>>>  15 files changed, 270 insertions(+), 26 deletions(-)
>>>>>>>>  create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..9868ca1
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
>>>>>>>> @@ -0,0 +1,222 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0+
>>>>>>>> +/*
>>>>>>>> + * Clock specification for Xilinx ZynqMP
>>>>>>>> + *
>>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>> + *
>>>>>>>> + * Michal Simek <michal.simek at xilinx.com>
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
>>>>>>>> +/ {
>>>>>>>> +	pss_ref_clk: pss_ref_clk {
>>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>>> +		compatible = "fixed-clock";
>>>>>>>> +		#clock-cells = <0>;
>>>>>>>> +		clock-frequency = <33333333>;
>>>>>>>> +	};
>>>>>>>> +
>>>>>>>> +	video_clk: video_clk {
>>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>>> +		compatible = "fixed-clock";
>>>>>>>> +		#clock-cells = <0>;
>>>>>>>> +		clock-frequency = <27000000>;
>>>>>>>> +	};
>>>>>>>> +
>>>>>>>> +	pss_alt_ref_clk: pss_alt_ref_clk {
>>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>>> +		compatible = "fixed-clock";
>>>>>>>> +		#clock-cells = <0>;
>>>>>>>> +		clock-frequency = <0>;
>>>>>>>> +	};
>>>>>>>> +
>>>>>>>> +	gt_crx_ref_clk: gt_crx_ref_clk {
>>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>>> +		compatible = "fixed-clock";
>>>>>>>> +		#clock-cells = <0>;
>>>>>>>> +		clock-frequency = <108000000>;
>>>>>>>> +	};
>>>>>>>> +
>>>>>>>> +	aux_ref_clk: aux_ref_clk {
>>>>>>>> +		u-boot,dm-pre-reloc;
>>>>>>>> +		compatible = "fixed-clock";
>>>>>>>> +		#clock-cells = <0>;
>>>>>>>> +		clock-frequency = <27000000>;
>>>>>>>> +	};
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&can0 {
>>>>>>>> +	clocks = <&zynqmp_clk CAN0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&can1 {
>>>>>>>> +	clocks = <&zynqmp_clk CAN1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&cpu0 {
>>>>>>>> +	clocks = <&zynqmp_clk ACPU>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan1 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan2 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan3 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan4 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan5 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan6 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan7 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&fpd_dma_chan8 {
>>>>>>>> +	clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan1 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan2 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan3 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan4 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan5 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan6 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan7 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&lpd_dma_chan8 {
>>>>>>>> +	clocks = <&zynqmp_clk ADMA_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&gem0 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM0_REF>,
>>>>>>>> +		 <&zynqmp_clk GEM0_TX>, <&zynqmp_clk GEM0_RX>,
>>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&gem1 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
>>>>>>>> +		 <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
>>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&gem2 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM2_REF>,
>>>>>>>> +		 <&zynqmp_clk GEM2_TX>, <&zynqmp_clk GEM2_RX>,
>>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&gem3 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM3_REF>,
>>>>>>>> +		 <&zynqmp_clk GEM3_TX>, <&zynqmp_clk GEM3_RX>,
>>>>>>>> +		 <&zynqmp_clk GEM_TSU>;
>>>>>>>> +	clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&gpio {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&i2c0 {
>>>>>>>> +	clocks = <&zynqmp_clk I2C0_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&i2c1 {
>>>>>>>> +	clocks = <&zynqmp_clk I2C1_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&pcie {
>>>>>>>> +	clocks = <&zynqmp_clk PCIE_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&sata {
>>>>>>>> +	clocks = <&zynqmp_clk SATA_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&sdhci0 {
>>>>>>>> +	clocks = <&zynqmp_clk SDIO0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&sdhci1 {
>>>>>>>> +	clocks = <&zynqmp_clk SDIO1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&spi0 {
>>>>>>>> +	clocks = <&zynqmp_clk SPI0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&spi1 {
>>>>>>>> +	clocks = <&zynqmp_clk SPI1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&ttc0 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&ttc1 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&ttc2 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&ttc3 {
>>>>>>>> +	clocks = <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&uart0 {
>>>>>>>> +	clocks = <&zynqmp_clk UART0_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&uart1 {
>>>>>>>> +	clocks = <&zynqmp_clk UART1_REF>, <&zynqmp_clk LPD_LSBUS>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&usb0 {
>>>>>>>> +	clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&usb1 {
>>>>>>>> +	clocks = <&zynqmp_clk USB1_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&watchdog0 {
>>>>>>>> +	clocks = <&zynqmp_clk WDT>;
>>>>>>>> +};
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>>> index 0f7b4cf..2e05fa4 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1232-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZC1232
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>
>>>>>>>>  / {
>>>>>>>>  	model = "ZynqMP ZC1232 RevA";
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>>> index 9092828..3d0aaa0 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZC1254
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   * Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>
>>>>>>>>  / {
>>>>>>>>  	model = "ZynqMP ZC1254 RevA";
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>>> index 4f404c5..1a8127d4 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dts
>>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>
>>>>>>>>  / {
>>>>>>>>  	model = "ZynqMP ZC1275 RevA";
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>>> index 9a3e39d..fa7eb1b 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm015-dc1.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm015-dc1
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>>  / {
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>>> index 2421ec7..4191dfa 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm016-dc2.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm016-dc2
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>>  / {
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>>> index 7a49dee..3750690 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm017-dc3.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm017-dc3
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>
>>>>>>>>  / {
>>>>>>>>  	model = "ZynqMP zc1751-xm017-dc3 RevA";
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>>> index 54c7b4f..2366cd9 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm018-dc4.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm018-dc4
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>
>>>>>>>>  / {
>>>>>>>>  	model = "ZynqMP zc1751-xm018-dc4";
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>>> index b8b5ff1..9a894e6 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zc1751-xm019-dc5.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP zc1751-xm019-dc5
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Siva Durga Prasad <siva.durga.paladugu at xilinx.com>
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>>  / {
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>>> index e5699d0..3e39454 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZCU100 revC
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2016 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   * Nathalie Chan King Choy
>>>>>>>> @@ -11,7 +11,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>>> index 2a3b665..f6e9558 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZCU102 RevA
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2015 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2015 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>>> index 8f45614..f457f8a 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu104-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZCU104
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>>  / {
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>>> index 93ce7eb..f15b99a 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZCU106
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2016, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2016 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>>> index 8bb0001..e27cd60 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu111-revA.dts
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP ZCU111
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2017 - 2018, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   */
>>>>>>>> @@ -10,7 +10,7 @@
>>>>>>>>  /dts-v1/;
>>>>>>>>
>>>>>>>>  #include "zynqmp.dtsi"
>>>>>>>> -#include "zynqmp-clk.dtsi"
>>>>>>>> +#include "zynqmp-clk-ccf.dtsi"
>>>>>>>>  #include <dt-bindings/input/input.h>
>>>>>>>>  #include <dt-bindings/gpio/gpio.h>
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>>> index 9aa6734..59a547b 100644
>>>>>>>> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
>>>>>>>> @@ -2,7 +2,7 @@
>>>>>>>>  /*
>>>>>>>>   * dts file for Xilinx ZynqMP
>>>>>>>>   *
>>>>>>>> - * (C) Copyright 2014 - 2015, Xilinx, Inc.
>>>>>>>> + * (C) Copyright 2014 - 2019, Xilinx, Inc.
>>>>>>>>   *
>>>>>>>>   * Michal Simek <michal.simek at xilinx.com>
>>>>>>>>   *
>>>>>>>> @@ -124,6 +124,28 @@
>>>>>>>>  			     <1 10 0xf08>;
>>>>>>>>  	};
>>>>>>>>
>>>>>>>> +	firmware {
>>>>>>>> +		zynqmp_firmware: zynqmp-firmware {
>>>>>>>> +			compatible = "xlnx,zynqmp-firmware";
>>>>>>>> +			method = "smc";
>>>>>>>> +			zynqmp_clk: clock-controller {
>>>>>>>> +				u-boot,dm-pre-reloc;
>>>>>>>> +				#clock-cells = <1>;
>>>>>>>> +				compatible = "xlnx,zynqmp-clk";
>>>>>>>> +				clocks = <&pss_ref_clk>,
>>>>>>>> +					 <&video_clk>,
>>>>>>>> +					 <&pss_alt_ref_clk>,
>>>>>>>> +					 <&aux_ref_clk>,
>>>>>>>> +					 <&gt_crx_ref_clk>;
>>>>>>>> +				clock-names = "pss_ref_clk",
>>>>>>>> +					      "video_clk",
>>>>>>>> +					      "pss_alt_ref_clk",
>>>>>>>> +					      "aux_ref_clk",
>>>>>>>> +					      "gt_crx_ref_clk";
>>>>>>>> +			};
>>>>>>>> +		};
>>>>>>>> +	};
>>>>>>>> +
>>>>>>>>  	amba_apu: amba-apu at 0 {
>>>>>>>>  		compatible = "simple-bus";
>>>>>>>>  		#address-cells = <2>;
>>>>>>>>
>>>>>>>
>>>>>>> Updating my Ultra96 setups from 5.4 to 5.10, I ran into a blocker:
>>>>>>> Starting from this commit on, I'm no longer getting the kernel to boot
>>>>>>> on both revision 1 and 2 (arm64 defconfig as reference). If I switch the
>>>>>>> DTBs back before this commit, even a kernel from today's head is fine.
>>>>>>>
>>>>>>> Further versions of potential relevance:
>>>>>>>  - PMUFW 2019.1 and 2020.2
>>>>>>>  - TF-A 2.3
>>>>>>>  - U-Boot 2020.10
>>>>>>>
>>>>>>> What's missing? I suspect someone forgot to document a subtle dependency
>>>>>>> of this change.
>>>>>>
>>>>>> Does this fix your issue?
>>>>>> https://lore.kernel.org/linux-arm-kernel/20210316090540.973014-1-punit1.agrawal at toshiba.co.jp/
>>>>>>
>>>>>
>>>>> Nope, CONFIG_COMMON_CLK_ZYNQMP=y does not help. Maybe the defconfig is
>>>>> missing even more. If you have some reference, I'm happy to try. I
>>>>> suspect that earlyprintk will also not reveal more without clocks (but I
>>>>> didn't play with that yet).
>>>>>
>>>>> Meanwhile, I'm carrying a revert of this commit and a related cleanup.
>>>>> That helps for now.
>>>>>
>>>>
>>>> OK, dependencies resolved (unfortunately the hard way): It either
>>>> requires TF-A master or latest release v2.4 + [1] and [2].
>>>>
>>>> Those TF-A commits were upstream about a year after the firmware-based
>>>> clock control hit the kernel. A note would have been nice - or better
>>>> sychronization between both upstreaming efforts.
>>>
>>> I wasn't responsible for TFA but I found this last year in Nov timeframe
>>> that none really upstream this. Right now that development is working
>>> like that. I am asking everybody to contribute upstream to have all the
>>> time upstream heads to work together.
>>> I haven't had a time to dig into this but unfortunatelly there is no
>>> feature checking mechanism on zynqmp TFA side to check if this is there
>>> or not but we are trying our best to check as much as possible but bugs
>>> happen.
>>
>> OK, I understand. Reminding of "upstream first" is part of my daily
>> business as well. :)
>>
>> And integration is generally more and more complicated with the growing
>> number of firmware services and interfaces, not only on this SOC...
>>
>>> And we are lacking space in OCM to be able to add more features to TFA
>>> anyway.
>>
>> Yeah, I know - I'm also overflowing it via the SDEI patch [1].
>
>
> I have looked at this. How are you using it now? I haven't had a chance
> to take a look at it. How do you use it and test it?
>
> We should try to minimalize amount of code and try to fit to OCM.
>

Sure - but I think this is getting too much off-topic for this thread.
Should we move the SDEI discussion to the TF-A list?

Jan


From suzuki.poulose at arm.com  Mon Apr 19 17:11:46 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 19 Apr 2021 17:11:46 +0100
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <fb4e70d9-e5c8-1cbf-ca21-adb701089fe0@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <529defac-cd67-3a7b-91d3-76eb0bb9dc6c@arm.com>
 <fb4e70d9-e5c8-1cbf-ca21-adb701089fe0@hisilicon.com>
Message-ID: <e98fdb87-1834-c5eb-70be-4e739ff258bd@arm.com>

On 19/04/2021 14:21, Yicong Yang wrote:
> On 2021/4/19 19:17, Suzuki K Poulose wrote:
>> On 17/04/2021 11:17, Yicong Yang wrote:
>>> [RESEND with perf and coresight folks Cc'ed]
>>>
>>> HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
>>> integrated Endpoint (RCiEP) device, providing the capability
>>> to dynamically monitor and tune the PCIe traffic (tune),
>>> and trace the TLP headers (trace).
>>>
>>> PTT tune is designed for monitoring and adjusting PCIe link parameters.
>>> We provide several parameters of the PCIe link. Through the driver,
>>> user can adjust the value of certain parameter to affect the PCIe link
>>> for the purpose of enhancing the performance in certian situation.
>>
>> ...
>>
>>>
>>> The reason for not using perf is because there is no current support
>>> for uncore tracing in the perf facilities. We have our own format
>>> of data and don't need perf doing the parsing. The setting through
>>> perf tools doesn't seem to be friendly as well. For example,
>>> we cannot count on perf to decode the usual format BDF number like
>>> <domain>:<bus>:<dev>.<fn>, which user can use to filter the TLP
>>> headers through the PTT device.
>>>
>>> A similar approach for implementing this function is ETM, which use
>>> sysfs for configuring and a character device for dumping data.
>>>
>>> Greg has some comments on our implementation and doesn't advocate
>>> to build driver on debugfs [1]. So I resend this series to
>>> collect more feedbacks on the implementation of this driver.
>>>
>>> Hi perf and ETM related experts, is it suggested to adapt this driver
>>> to perf? Or is the debugfs approach acceptable? Otherwise use
>>> sysfs + character device like ETM and use perf tools for decoding it?
>>> Any comments is welcomed.
>>
>> Please use perf. Debugfs / sysfs is not the right place for these things.
>>
> 
> ok.
> 
>> Also, please move your driver to drivers/perf/
>>
> 
> Does it make sense as it's a tuning and tracing device, and doesn't have counters
> nor do the sampling like usual PMU device under drivers/perf/.

It doesn't matter. As long as you can drive it via the perf interface,
it can live there. The CoreSight was added way before there was kind
of a suitable place like the above. You could find other uncore PMUs
under drivers/perf.

Suzuki


From will at kernel.org  Mon Apr 19 17:14:29 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 19 Apr 2021 17:14:29 +0100
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <CAL_Jsq+H_asWWrHiCk-PBS8xDEGpBL1__dRyrPXdBYgRBBw2vA@mail.gmail.com>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
 <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
 <20210407124437.GA15622@willie-the-truck>
 <20210408110800.GA32792@C02TD0UTHF1T.local>
 <CAL_Jsq+H_asWWrHiCk-PBS8xDEGpBL1__dRyrPXdBYgRBBw2vA@mail.gmail.com>
Message-ID: <20210419161429.GA30998@willie-the-truck>

On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote:
> On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland <mark.rutland at arm.com> wrote:
> > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
> > > I guess I'm just worried about exposing the counters to userspace after
> > > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > > case we leak other events.
> >
> > IMO that's not practically different from the single-PMU case (i.e.
> > multi-PMU isn't material, either we have a concern with leaking or we
> > don't); more on that below.

Well, maybe. It looks the single-PMU case is exposed to the same issue,
but I think a solution needs to take into account the multi-PMU situation.

> > While it looks odd to place this on the mm, I don't think it's the end
> > of the world.
> >
> > > However, I'm not sure how this is supposed to work normally: what
> > > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > > event while a task has a counter with direct access -- can that task
> > > read the kernel event out of the PMU registers from userspace?
> >
> > Yes -- userspace could go read any counters even though it isn't
> > supposed to, and could potentially infer information from those. It
> > won't have access to the config registers or kernel data structures, so
> > it isn't guaranteed to know what the even is or when it is
> > context-switched/reprogrammed/etc.
> >
> > If we believe that's a problem, then it's difficult to do anything
> > robust other than denying userspace access entirely, since disabling
> > userspace access while in use would surprise applications, and denying
> > privileged events would need some global state that we consult at event
> > creation time (in addition to being an inversion of privilege).
> >
> > IIRC there was some fuss about this a while back on x86; I'll go dig and
> > see what I can find, unless Peter has a memory...
> 
> Maybe this one[1].
> 
> Rob
> 
> [1] https://lore.kernel.org/lkml/20200730123815.18518-1-kan.liang at linux.intel.com/

Going through the archives and talking to Peter, it looks like this is still
an active area of concern:

  - There are patches to clear "dirty" counters on context-switch. They were
    queued for 5.13 but broke -tip on Friday:

    https://lore.kernel.org/lkml/YHm%2FM4za2LpRYePw at hirez.programming.kicks-ass.net/

  - Per-cpu events cannot be protected in software:

    https://lore.kernel.org/lkml/CALCETrVVPzUd_hQ8xoomHn_wWRQJUvROeCt2do4_D4ROZoAVMg at mail.gmail.com/

    so without hardware support, we need a way to disable user access for
    people that care about this leakage

x86 has an "rdpmc" file exposed for the PMU device in sysfs which allows
access to be disabled. I don't think these patches add such a thing, and
that's where the fun with multi-PMU machines would come into play.

Will


From will at kernel.org  Mon Apr 19 17:31:03 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 19 Apr 2021 17:31:03 +0100
Subject: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format
In-Reply-To: <CAK8P3a11O7JVDv+4rfky13C1pZFD7eE_B_54zRN8UQVpBrQJcA@mail.gmail.com>
References: <20210328074009.95932-1-sven@svenpeter.dev>
 <20210328074009.95932-2-sven@svenpeter.dev>
 <20210407104425.GB15173@willie-the-truck>
 <e0d9af36-fc6c-4470-a87c-61b9161bdf8f@www.fastmail.com>
 <CAK8P3a11O7JVDv+4rfky13C1pZFD7eE_B_54zRN8UQVpBrQJcA@mail.gmail.com>
Message-ID: <20210419163102.GA31045@willie-the-truck>

On Fri, Apr 09, 2021 at 09:38:15PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 9, 2021 at 6:56 PM Sven Peter <sven at svenpeter.dev> wrote:
> > On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> > > On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> > >
> > > > +   cfg->pgsize_bitmap &= SZ_16K;
> > > > +   if (!cfg->pgsize_bitmap)
> > > > +           return NULL;
> > >
> > > This is worrying (and again, I don't think this belongs here). How is this
> > > thing supposed to work if the CPU is using 4k pages?
> >
> > This SoC is just full of fun surprises!
> > I didn't even think about that case since I've always been using 16k pages so far.
> >
> > I've checked again and wasn't able to find any way to configure the pagesize
> > of the IOMMU. There seem to be variants of this IP in older iPhones which
> > support a 4k pagesize but to the best of my knowledge this is hard wired
> > and not configurable in software.
> >
> > When booting with 4k pages I hit the BUG_ON in iova.c that ensures that the
> > iommu pagesize has to be <= the cpu page size.
> >
> > I see two options here and I'm not sure I like either of them:
> >
> > 1) Just don't support 4k CPU pages together with IOMMU translations and only
> >    allow full bypass mode there.
> >    This would however mean that PCIe (i.e. ethernet, usb ports on the Mac
> >    mini) and possibly Thunderbolt support would not be possible since these
> >    devices don't seem to like iommu bypass mode at all.
> 
> It should be possible to do a fake bypass mode by just programming a
> static page table for as much address space as you can, and then
> use swiotlb to address any memory beyond that. This won't perform
> well because it requires bounce buffers for any high memory, but it
> can be a last resort if a dart instance cannot do normal bypass mode.
> 
> > 2) I've had a brief discussion on IRC with Arnd about this [1] and he pointed
> >    out that the dma_map_sg API doesn't make any guarantees about the returned
> >    iovas and that it might be possible to make this work at least for devices
> >    that go through the normal DMA API.
> >
> >    I've then replaced the page size check with a WARN_ON in iova.c just to see
> >    what happens. At least normal devices that go through the DMA API seem to
> >    work with my configuration. iommu_dma_alloc took the iommu_dma_alloc_remap
> >    path which was called with the cpu page size but then used
> >    domain->pgsize_bitmap to increase that to 16k. So this kinda works out, but
> >    there are other functions in dma-iommu.c that I believe rely on the fact that
> >    the iommu can map single cpu pages. This feels very fragile right now and
> >    would probably require some rather invasive changes.
> 
> The other second-to-last resort here would be to duplicate the code from
> the dma-iommu code and implement the dma-mapping API directly on
> top of the dart hardware instead of the iommu layer. This would probably
> be much faster than the swiotlb on top of a bypass or a linear map,
> but it's a really awful abstraction that would require adding special cases
> into a lot of generic code.
> 
> >    Any driver that tries to use the iommu API directly could be trouble
> >    as well if they make similar assumptions.
> 
> I think pretty much all drivers using the iommu API directly already
> depends on having a matching page size.  I don't see any way to use
> e.g. PCI device assignment using vfio, or a GPU driver with per-process
> contexts when the iotlb page size is larger than the CPU's.
> 
> >    Is this something you would even want to support in the iommu subsytem
> >    and is it even possible to do this in a sane way?
> 
> I don't know how hard it is to do adjust the dma-iommu implementation
> to allow this, but as long as we can work out the DT binding to support
> both normal dma-iommu mode with 16KB pages and some kind of
> passthrough mode (emulated or not) with 4KB pages, it can be left
> as a possible optimization for later.

I think one of the main things to modify is the IOVA allocator
(drivers/iommu/iova.c). Once that is happy with pages bigger than the CPU
page size, then you could probably fake everything else in the DMA layer by
offsetting the returned DMA addresses into the 16K page which got mapped.

Will


From christophe.leroy at csgroup.eu  Mon Apr 19 17:41:16 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Mon, 19 Apr 2021 18:41:16 +0200
Subject: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
In-Reply-To: <4a76fbda-aa9d-867b-e2eb-a1951780aeec@arm.com>
References: <cover.1618506910.git.christophe.leroy@csgroup.eu>
 <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu>
 <41819925-3ee5-4771-e98b-0073e8f095cf@arm.com>
 <da53d2f2-b472-0c38-bdd5-99c5a098675d@csgroup.eu>
 <1102cda1-b00f-b6ef-6bf3-22068cc11510@arm.com>
 <627ee414-2f78-94e3-b77b-1013f52e77e3@csgroup.eu>
 <4a76fbda-aa9d-867b-e2eb-a1951780aeec@arm.com>
Message-ID: <4cdd8dc0-34d6-11a3-f3b2-d6eb58c435c7@csgroup.eu>



Le 19/04/2021 ? 16:00, Steven Price a ?crit?:
> On 19/04/2021 14:14, Christophe Leroy wrote:
>>
>>
>> Le 16/04/2021 ? 12:51, Steven Price a ?crit?:
>>> On 16/04/2021 11:38, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 16/04/2021 ? 11:28, Steven Price a ?crit?:
>>>>> On 15/04/2021 18:18, Christophe Leroy wrote:
>>>>>
>>>>> To be honest I don't fully understand why powerpc requires the page_size - it appears to be 
>>>>> using it purely to find "holes" in the calls to note_page(), but I haven't worked out why such 
>>>>> holes would occur.
>>>>
>>>> I was indeed introduced for KASAN. We have a first commit 
>>>> https://github.com/torvalds/linux/commit/cabe8138 which uses page size to detect whether it is a 
>>>> KASAN like stuff.
>>>>
>>>> Then came https://github.com/torvalds/linux/commit/b00ff6d8c as a fix. I can't remember what the 
>>>> problem was exactly, something around the use of hugepages for kernel memory, came as part of 
>>>> the series 
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1589866984.git.christophe.leroy at csgroup.eu/ 
>>>
>>>
>>>
>>>
>>> Ah, that's useful context. So it looks like powerpc took a different route to reducing the KASAN 
>>> output to x86.
>>>
>>> Given the generic ptdump code has handling for KASAN already it should be possible to drop that 
>>> from the powerpc arch code, which I think means we don't actually need to provide page size to 
>>> notepage(). Hopefully that means more code to delete ;)
>>>
>>
>> Looking at how the generic ptdump code handles KASAN, I'm a bit sceptic.
>>
>> IIUC, it is checking that kasan_early_shadow_pte is in the same page as the pgtable referred by 
>> the PMD entry. But what happens if that PMD entry is referring another pgtable which is inside the 
>> same page as kasan_early_shadow_pte ?
>>
>> Shouldn't the test be
>>
>> ?????if (pmd_page_vaddr(val) == lm_alias(kasan_early_shadow_pte))
>> ???????? return note_kasan_page_table(walk, addr);
> 
> Now I come to look at this code again, I think you're right. On arm64 this doesn't cause a problem - 
> page tables are page sized and page aligned, so there couldn't be any non-KASAN pgtables sharing the 
> page. Obviously that's not necessarily true of other architectures.
> 
> Feel free to add a patch to your series ;)
> 

Ok.

I'll leave that outside of the series, it is not a show stopper because early shadow page 
directories are all tagged __bss_page_aligned so we can't have two of them in the same page and it 
is really unlikely that we'll have any other statically defined page directory in the same pages either.

And for the special case of powerpc 8xx which is the only one for which we have both KASAN and 
HUGEPD at the time being, there are only two levels of page directories so no issue.

Christophe


From will at kernel.org  Mon Apr 19 18:03:32 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 19 Apr 2021 18:03:32 +0100
Subject: [PATCH v5] arm64: Enable perf events based hard lockup detector
In-Reply-To: <CAFA6WYPXu8biPPim5EoQ1pi+w3APKm65tzfOvH4OSORZdJ6+8Q@mail.gmail.com>
References: <20210330080615.21938-1-lecopzer.chen@mediatek.com>
 <20210330083218.22285-1-lecopzer.chen@mediatek.com>
 <CAFA6WYMqLMEG2s7OdNweQKkP0K2LZ575B1BVw-zfsg7_KBSM5Q@mail.gmail.com>
 <CAFA6WYPXu8biPPim5EoQ1pi+w3APKm65tzfOvH4OSORZdJ6+8Q@mail.gmail.com>
Message-ID: <20210419170331.GB31045@willie-the-truck>

On Mon, Apr 12, 2021 at 05:31:13PM +0530, Sumit Garg wrote:
> On Tue, 30 Mar 2021 at 18:00, Sumit Garg <sumit.garg at linaro.org> wrote:
> > On Tue, 30 Mar 2021 at 14:07, Lecopzer Chen <lecopzer.chen at mediatek.com> wrote:
> > > > > On Fri, 15 Jan 2021 at 17:32, Sumit Garg <sumit.garg at linaro.org> wrote:
> > > > > >
> > > > > > With the recent feature added to enable perf events to use pseudo NMIs
> > > > > > as interrupts on platforms which support GICv3 or later, its now been
> > > > > > possible to enable hard lockup detector (or NMI watchdog) on arm64
> > > > > > platforms. So enable corresponding support.
> > > > > >
> > > > > > One thing to note here is that normally lockup detector is initialized
> > > > > > just after the early initcalls but PMU on arm64 comes up much later as
> > > > > > device_initcall(). So we need to re-initialize lockup detection once
> > > > > > PMU has been initialized.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg <sumit.garg at linaro.org>
> > > > > > ---
> > > > > >
> > > > > > Changes in v5:
> > > > > > - Fix lockup_detector_init() invocation to be rather invoked from CPU
> > > > > >   binded context as it makes heavy use of per-cpu variables and shouldn't
> > > > > >   be invoked from preemptible context.
> > > > > >
> > > > >
> > > > > Do you have any further comments on this?
> > > > >
> 
> Since there aren't any further comments, can you re-pick this feature for 5.13?

I'd still like Mark's Ack on this, as the approach you have taken doesn't
really sit with what he was suggesting.

I also don't understand how all the CPUs get initialised with your patch,
since the PMU driver will be initialised after SMP is up and running.

Will


From acme at kernel.org  Mon Apr 19 18:13:14 2021
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Mon, 19 Apr 2021 14:13:14 -0300
Subject: [PATCH] perf arm64: Fix off-by-one directory paths.
In-Reply-To: <20210416214113.552252-1-irogers@google.com>
References: <20210416214113.552252-1-irogers@google.com>
Message-ID: <YH26KvbSPGA0I/zs@kernel.org>

Em Fri, Apr 16, 2021 at 02:41:13PM -0700, Ian Rogers escreveu:
> Relative path include works in the regular build due to -I paths but may
> break in other situations.

Thanks, applied.

- Arnaldo

 
> Signed-off-by: Ian Rogers <irogers at google.com>
> ---
>  tools/perf/arch/arm64/util/kvm-stat.c         | 4 ++--
>  tools/perf/arch/arm64/util/pmu.c              | 4 ++--
>  tools/perf/arch/arm64/util/unwind-libunwind.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/perf/arch/arm64/util/kvm-stat.c b/tools/perf/arch/arm64/util/kvm-stat.c
> index 50376b9062c1..2303256b7d05 100644
> --- a/tools/perf/arch/arm64/util/kvm-stat.c
> +++ b/tools/perf/arch/arm64/util/kvm-stat.c
> @@ -1,8 +1,8 @@
>  // SPDX-License-Identifier: GPL-2.0
>  #include <errno.h>
>  #include <memory.h>
> -#include "../../util/evsel.h"
> -#include "../../util/kvm-stat.h"
> +#include "../../../util/evsel.h"
> +#include "../../../util/kvm-stat.h"
>  #include "arm64_exception_types.h"
>  #include "debug.h"
>  
> diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
> index d3259d61ca75..2234fbd0a912 100644
> --- a/tools/perf/arch/arm64/util/pmu.c
> +++ b/tools/perf/arch/arm64/util/pmu.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  
> -#include "../../util/cpumap.h"
> -#include "../../util/pmu.h"
> +#include "../../../util/cpumap.h"
> +#include "../../../util/pmu.h"
>  
>  struct pmu_events_map *pmu_events_map__find(void)
>  {
> diff --git a/tools/perf/arch/arm64/util/unwind-libunwind.c b/tools/perf/arch/arm64/util/unwind-libunwind.c
> index 1495a9523a23..5aecf88e3de6 100644
> --- a/tools/perf/arch/arm64/util/unwind-libunwind.c
> +++ b/tools/perf/arch/arm64/util/unwind-libunwind.c
> @@ -4,9 +4,9 @@
>  #ifndef REMOTE_UNWIND_LIBUNWIND
>  #include <libunwind.h>
>  #include "perf_regs.h"
> -#include "../../util/unwind.h"
> +#include "../../../util/unwind.h"
>  #endif
> -#include "../../util/debug.h"
> +#include "../../../util/debug.h"
>  
>  int LIBUNWIND__ARCH_REG_ID(int regnum)
>  {
> -- 
> 2.31.1.368.gbe11c130af-goog
> 

-- 

- Arnaldo


From broonie at kernel.org  Mon Apr 19 18:33:45 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 19 Apr 2021 18:33:45 +0100
Subject: [PATCH 0/3] spi: stm32-qspi: Fix and update
In-Reply-To: <20210419121541.11617-1-patrice.chotard@foss.st.com>
References: <20210419121541.11617-1-patrice.chotard@foss.st.com>
Message-ID: <161885314932.4710.7975812733588849701.b4-ty@kernel.org>

On Mon, 19 Apr 2021 14:15:38 +0200, patrice.chotard at foss.st.com wrote:
> Christophe Kerello (1):
>   spi: stm32-qspi: fix pm_runtime usage_count counter
> 
> Patrice Chotard (2):
>   spi: stm32-qspi: Trigger DMA only if more than 4 bytes to transfer
>   spi: stm32-qspi: Add dirmap support
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/3] spi: stm32-qspi: fix pm_runtime usage_count counter
      commit: 102e9d1936569d43f55dd1ea89be355ad207143c
[2/3] spi: stm32-qspi: Trigger DMA only if more than 4 bytes to transfer
      commit: f3530f26f8e9869e6e8c3370cf6f61330774fe2b
[3/3] spi: stm32-qspi: Add dirmap support
      commit: 18674dee3cd651279eb3d9ba789fe483ddfe1137

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 festevam at gmail.com  Mon Apr 19 18:43:09 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 19 Apr 2021 14:43:09 -0300
Subject: [PATCH] imx-sc: remove .read_alarm
In-Reply-To: <20210417235205.994119-1-alexandre.belloni@bootlin.com>
References: <20210417235205.994119-1-alexandre.belloni@bootlin.com>
Message-ID: <CAOMZO5Be45yAxqKzfbCJ0yjCgfNSc4_dZj0j8yEBegOk1kp2jw@mail.gmail.com>

Hi Alexandre,

On Sat, Apr 17, 2021 at 8:52 PM Alexandre Belloni
<alexandre.belloni at bootlin.com> wrote:
>
> The RTC core properly handles RTC without .read_alarm and doesn't use it to
> set alarms. .read_alarm can be safely dropped.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni at bootlin.com>

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From madvenka at linux.microsoft.com  Mon Apr 19 19:16:57 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 19 Apr 2021 13:16:57 -0500
Subject: [RFC PATCH v2 0/1] arm64: Implement stack trace termination record
In-Reply-To: <20210402032404.47239-1-madvenka@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
Message-ID: <96b4deb8-c841-b0fd-f1f9-ad0b737ec8a7@linux.microsoft.com>

CCing Pavel Tatashin <pasha.tatashin at soleen.com> on request.

Pasha,

This is v2. v1 is here:

https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madvenka at linux.microsoft.com/

Thanks!
                       
Madhavan

On 4/1/21 10:24 PM, madvenka at linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
> 
> Reliable stacktracing requires that we identify when a stacktrace is
> terminated early. We can do this by ensuring all tasks have a final
> frame record at a known location on their task stack, and checking
> that this is the final frame record in the chain.
> 
> All tasks have a pt_regs structure right after the task stack in the stack
> page. The pt_regs structure contains a stackframe field. Make this stackframe
> field the final frame in the task stack so all stack traces end at a fixed
> stack offset.
> 
> For kernel tasks, this is simple to understand. For user tasks, there is
> some extra detail. User tasks get created via fork() et al. Once they return
> from fork, they enter the kernel only on an EL0 exception. In arm64,
> system calls are also EL0 exceptions.
> 
> The EL0 exception handler uses the task pt_regs mentioned above to save
> register state and call different exception functions. All stack traces
> from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe
> the final frame in the EL0 exception stack.
> 
> To summarize, task_pt_regs(task)->stackframe will always be the final frame
> in a stack trace.
> 
> Sample stack traces
> ===================
> 
> The final frame for the idle tasks is different from v1. The rest of the
> stack traces are the same.
> 
> Primary CPU's idle task (changed from v1)
> =======================
> 
> [    0.022365]   arch_stack_walk+0x0/0xd0
> [    0.022376]   callfd_stack+0x30/0x60
> [    0.022387]   rest_init+0xd8/0xf8
> [    0.022397]   arch_call_rest_init+0x18/0x24
> [    0.022411]   start_kernel+0x5b8/0x5f4
> [    0.022424]   __primary_switched+0xa8/0xac
> 
> Secondary CPU's idle task (changed from v1)
> =========================
> 
> [    0.022484]   arch_stack_walk+0x0/0xd0
> [    0.022494]   callfd_stack+0x30/0x60
> [    0.022502]   secondary_start_kernel+0x188/0x1e0
> [    0.022513]   __secondary_switched+0x80/0x84
> 
> ---
> Changelog:
> 
> v1
> 	- Set up task_pt_regs(current)->stackframe as the final frame
> 	  when a new task is initialized in copy_thread().
> 
> 	- Create pt_regs for the idle tasks and set up pt_regs->stackframe
> 	  as the final frame for the idle tasks.
> 
> 	- Set up task_pt_regs(current)->stackframe as the final frame in
> 	  the EL0 exception handler so the EL0 exception stack trace ends
> 	  there.
> 
> 	- Terminate the stack trace successfully in unwind_frame() when
> 	  the FP reaches task_pt_regs(current)->stackframe.
> 
> 	- The stack traces (above) in the kernel will terminate at the
> 	  correct place. Debuggers may show an extra record 0x0 at the end
> 	  for pt_regs->stackframe. That said, I did not see that extra frame
> 	  when I did stack traces using gdb.
> v2
> 	- Changed some wordings as suggested by Mark Rutland.
> 
> 	- Removed the synthetic return PC for idle tasks. Changed the
> 	  branches to start_kernel() and secondary_start_kernel() to
> 	  calls so that they will have a proper return PC.
> 
> Madhavan T. Venkataraman (1):
>   arm64: Implement stack trace termination record
> 
>  arch/arm64/kernel/entry.S      |  8 +++++---
>  arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
>  arch/arm64/kernel/process.c    |  5 +++++
>  arch/arm64/kernel/stacktrace.c | 10 +++++-----
>  4 files changed, 38 insertions(+), 14 deletions(-)
> 
> 
> base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
> 


From madvenka at linux.microsoft.com  Mon Apr 19 19:18:18 2021
From: madvenka at linux.microsoft.com (Madhavan T. Venkataraman)
Date: Mon, 19 Apr 2021 13:18:18 -0500
Subject: [RFC PATCH v2 0/1] arm64: Implement stack trace termination record
In-Reply-To: <96b4deb8-c841-b0fd-f1f9-ad0b737ec8a7@linux.microsoft.com>
References: <659f3d5cc025896ba4c49aea431aa8b1abc2b741>
 <20210402032404.47239-1-madvenka@linux.microsoft.com>
 <96b4deb8-c841-b0fd-f1f9-ad0b737ec8a7@linux.microsoft.com>
Message-ID: <7265bed3-c78b-b6a9-f97a-7d891400bf7b@linux.microsoft.com>

Sorry. Forgot to include link to v2. Here it is:

https://lore.kernel.org/linux-arm-kernel/20210402032404.47239-1-madvenka at linux.microsoft.com/

Thanks!

Madhavan

On 4/19/21 1:16 PM, Madhavan T. Venkataraman wrote:
> CCing Pavel Tatashin <pasha.tatashin at soleen.com> on request.
> 
> Pasha,
> 
> This is v2. v1 is here:
> 
> https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madvenka at linux.microsoft.com/
> 
> Thanks!
>                        
> Madhavan
> 
> On 4/1/21 10:24 PM, madvenka at linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
>>
>> Reliable stacktracing requires that we identify when a stacktrace is
>> terminated early. We can do this by ensuring all tasks have a final
>> frame record at a known location on their task stack, and checking
>> that this is the final frame record in the chain.
>>
>> All tasks have a pt_regs structure right after the task stack in the stack
>> page. The pt_regs structure contains a stackframe field. Make this stackframe
>> field the final frame in the task stack so all stack traces end at a fixed
>> stack offset.
>>
>> For kernel tasks, this is simple to understand. For user tasks, there is
>> some extra detail. User tasks get created via fork() et al. Once they return
>> from fork, they enter the kernel only on an EL0 exception. In arm64,
>> system calls are also EL0 exceptions.
>>
>> The EL0 exception handler uses the task pt_regs mentioned above to save
>> register state and call different exception functions. All stack traces
>> from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe
>> the final frame in the EL0 exception stack.
>>
>> To summarize, task_pt_regs(task)->stackframe will always be the final frame
>> in a stack trace.
>>
>> Sample stack traces
>> ===================
>>
>> The final frame for the idle tasks is different from v1. The rest of the
>> stack traces are the same.
>>
>> Primary CPU's idle task (changed from v1)
>> =======================
>>
>> [    0.022365]   arch_stack_walk+0x0/0xd0
>> [    0.022376]   callfd_stack+0x30/0x60
>> [    0.022387]   rest_init+0xd8/0xf8
>> [    0.022397]   arch_call_rest_init+0x18/0x24
>> [    0.022411]   start_kernel+0x5b8/0x5f4
>> [    0.022424]   __primary_switched+0xa8/0xac
>>
>> Secondary CPU's idle task (changed from v1)
>> =========================
>>
>> [    0.022484]   arch_stack_walk+0x0/0xd0
>> [    0.022494]   callfd_stack+0x30/0x60
>> [    0.022502]   secondary_start_kernel+0x188/0x1e0
>> [    0.022513]   __secondary_switched+0x80/0x84
>>
>> ---
>> Changelog:
>>
>> v1
>> 	- Set up task_pt_regs(current)->stackframe as the final frame
>> 	  when a new task is initialized in copy_thread().
>>
>> 	- Create pt_regs for the idle tasks and set up pt_regs->stackframe
>> 	  as the final frame for the idle tasks.
>>
>> 	- Set up task_pt_regs(current)->stackframe as the final frame in
>> 	  the EL0 exception handler so the EL0 exception stack trace ends
>> 	  there.
>>
>> 	- Terminate the stack trace successfully in unwind_frame() when
>> 	  the FP reaches task_pt_regs(current)->stackframe.
>>
>> 	- The stack traces (above) in the kernel will terminate at the
>> 	  correct place. Debuggers may show an extra record 0x0 at the end
>> 	  for pt_regs->stackframe. That said, I did not see that extra frame
>> 	  when I did stack traces using gdb.
>> v2
>> 	- Changed some wordings as suggested by Mark Rutland.
>>
>> 	- Removed the synthetic return PC for idle tasks. Changed the
>> 	  branches to start_kernel() and secondary_start_kernel() to
>> 	  calls so that they will have a proper return PC.
>>
>> Madhavan T. Venkataraman (1):
>>   arm64: Implement stack trace termination record
>>
>>  arch/arm64/kernel/entry.S      |  8 +++++---
>>  arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
>>  arch/arm64/kernel/process.c    |  5 +++++
>>  arch/arm64/kernel/stacktrace.c | 10 +++++-----
>>  4 files changed, 38 insertions(+), 14 deletions(-)
>>
>>
>> base-commit: 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b
>>


From khilman at baylibre.com  Mon Apr 19 19:21:53 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 19 Apr 2021 11:21:53 -0700
Subject: [PATCH] media: meson-ge2d: fix rotation parameters
In-Reply-To: <20210412134833.3467694-1-narmstrong@baylibre.com>
References: <20210412134833.3467694-1-narmstrong@baylibre.com>
Message-ID: <7hh7k2xhha.fsf@baylibre.com>

Neil Armstrong <narmstrong at baylibre.com> writes:

> With these settings, 90deg and 270deg rotation leads to inverted
> vertical, fix them to have correct rotation.
>
> Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit")
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>

Reviewed-by: Kevin Hilman <khilman at baylibre.com>

> ---
>  drivers/media/platform/meson/ge2d/ge2d.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/meson/ge2d/ge2d.c b/drivers/media/platform/meson/ge2d/ge2d.c
> index 153612ca96fc..a1393fefa8ae 100644
> --- a/drivers/media/platform/meson/ge2d/ge2d.c
> +++ b/drivers/media/platform/meson/ge2d/ge2d.c
> @@ -757,7 +757,7 @@ static int ge2d_s_ctrl(struct v4l2_ctrl *ctrl)
>  
>  		if (ctrl->val == 90) {
>  			ctx->hflip = 0;
> -			ctx->vflip = 0;
> +			ctx->vflip = 1;
>  			ctx->xy_swap = 1;
>  		} else if (ctrl->val == 180) {
>  			ctx->hflip = 1;
> @@ -765,7 +765,7 @@ static int ge2d_s_ctrl(struct v4l2_ctrl *ctrl)
>  			ctx->xy_swap = 0;
>  		} else if (ctrl->val == 270) {
>  			ctx->hflip = 1;
> -			ctx->vflip = 1;
> +			ctx->vflip = 0;
>  			ctx->xy_swap = 1;
>  		} else {
>  			ctx->hflip = 0;
> -- 
> 2.25.1


From rppt at kernel.org  Mon Apr 19 19:24:30 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 19 Apr 2021 21:24:30 +0300
Subject: [PATCH] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210419122156.GZ2531743@casper.infradead.org>
References: <20210419084218.7466-1-rppt@kernel.org>
 <20210419112302.GX2531743@casper.infradead.org>
 <YH1v4XVzfXC1dYND@kernel.org>
 <20210419122156.GZ2531743@casper.infradead.org>
Message-ID: <YH3K3sBFbNFOxTV+@kernel.org>

On Mon, Apr 19, 2021 at 01:21:56PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 19, 2021 at 02:56:17PM +0300, Mike Rapoport wrote:
> 
> > > With that fixed, you'll have a head page that you can use for testing,
> > > which means you don't need to test PageCompound() (because you know the
> > > page isn't PageTail), you can just test PageHead().
> > 
> > I can't say I follow you here. page_is_secretmem() is intended to be a
> > generic test, so I don't see how it will get PageHead() if it is called
> > from other places.
> 
> static inline bool head_is_secretmem(struct page *head)
> {
> 	if (PageHead(head))
> 		return false;
> 	...
> }
> 
> static inline bool page_is_secretmem(struct page *page)
> {
> 	if (PageTail(page))
> 		return false;
> 	return head_is_secretmem(page);
> }
> 
> (yes, calling it head is a misnomer, because it's not necessarily a head,
> it might be a base page, but until we have a name for pages which might
> be a head page or a base page, it'll have to do ...)

To me this looks less clean and readable and in the end we have an extra
check for PG_Head if that won't get optimized away.

Does not seem to me there would be a measurable difference, but if this is
important for future conversion to folio I don't mind using
{head,page}_is_secretmem.

-- 
Sincerely yours,
Mike.


From adrian.hunter at intel.com  Mon Apr 19 19:37:27 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Mon, 19 Apr 2021 21:37:27 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
Message-ID: <fdadd467-b613-d800-18c5-be064396fd10@intel.com>

On 16/04/21 10:49 pm, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes. This also registers a new scsi driver for rpmb wlun.
> This new driver is mostly used to clear rpmb uac.
> 
> Fixed smatch warnings:
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
> ---

I came across 3 issues while testing.  See comments below.

<SNIP>

> @@ -5753,12 +5797,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
>  
>  static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
>  {
> -	pm_runtime_get_sync(hba->dev);
> -	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
> +	ufshcd_rpm_get_sync(hba);

hba->sdev_ufs_device could be NULL.
Need to add a check for that in ufshcd_err_handling_should_stop()

> +	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
> +	    hba->is_sys_suspended) {
>  		enum ufs_pm_op pm_op;
>  
>  		/*
> -		 * Don't assume anything of pm_runtime_get_sync(), if
> +		 * Don't assume anything of resume, if
>  		 * resume fails, irq and clocks can be OFF, and powers
>  		 * can be OFF or in LPM.
>  		 */
> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>  	if (ufshcd_is_clkscaling_supported(hba))
>  		ufshcd_clk_scaling_suspend(hba, false);
>  	ufshcd_clear_ua_wluns(hba);

ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
if sdev_rpmb is suspended and sdev_ufs_device is suspending.
e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
is running, at which point sdev_rpmb has already suspended.

> -	pm_runtime_put(hba->dev);
> +	ufshcd_rpm_put(hba);
>  }

<SNIP>

> +void ufshcd_resume_complete(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	ufshcd_rpm_put(hba);
> +}
> +EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
> +
> +int ufshcd_suspend_prepare(struct device *dev)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +	struct device *ufs_dev = &hba->sdev_ufs_device->sdev_gendev;
> +	enum ufs_dev_pwr_mode spm_pwr_mode;
> +	enum uic_link_state spm_link_state;
> +	unsigned long flags;
> +	bool rpm_state_ok;
> +
> +	/*
> +	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
> +	 * are same. And it doesn't wake up the device for system-suspend
> +	 * if it's runtime suspended. But ufs doesn't follow that.
> +	 * The rpm-lvl and spm-lvl can be different in ufs.
> +	 * However, if the current_{pwr_mode, link_state} is same as the
> +	 * desired_{pwr_mode, link_state}, there's no need to rpm resume
> +	 * the device.
> +	 * Refer ufshcd_resume_complete()
> +	 */
> +	pm_runtime_get_noresume(ufs_dev);
> +
> +	spin_lock_irqsave(&ufs_dev->power.lock, flags);
> +
> +	spm_pwr_mode = ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl);
> +	spm_link_state = ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl);
> +
> +	rpm_state_ok = pm_runtime_suspended(ufs_dev) &&
> +		hba->curr_dev_pwr_mode == spm_pwr_mode &&
> +		hba->uic_link_state == spm_link_state &&
> +		!hba->dev_info.b_rpm_dev_flush_capable;
> +
> +	spin_unlock_irqrestore(&ufs_dev->power.lock, flags);
> +
> +	if (!rpm_state_ok) {
> +		int ret = pm_runtime_resume(ufs_dev);
> +
> +		if (ret < 0 && ret != -EACCES) {
> +			pm_runtime_put(ufs_dev);
> +			return ret;
> +		}
> +	}
> +	return 0;
> +}

Unfortunately this does not work because SCSI PM forcibly sets
the sdevs to runtime active after system resume.  Really we should
change SCSI PM to call the driver's .prepare / .complete then we could
use direct complete, but let's leave that for now and go back to
before, but allowing for errors and !hba->sdev_ufs_device. e.g.

void ufshcd_resume_complete(struct device *dev)
{
	struct ufs_hba *hba = dev_get_drvdata(dev);

	if (hba->complete_put) {
		hba->complete_put = false;
		ufshcd_rpm_put(hba);
	}
}
EXPORT_SYMBOL_GPL(ufshcd_resume_complete);

int ufshcd_suspend_prepare(struct device *dev)
{
	struct ufs_hba *hba = dev_get_drvdata(dev);
	int ret;

	if (!hba->sdev_ufs_device)
		return 0;

	ret = ufshcd_rpm_get_sync(hba);
	if (ret < 0 && ret != -EACCES) {
		ufshcd_rpm_put(hba);
		return ret;
	}
	hba->complete_put = true;
	return 0;
}
EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);



From robh at kernel.org  Mon Apr 19 20:00:17 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 14:00:17 -0500
Subject: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access
 for perf event
In-Reply-To: <20210419161429.GA30998@willie-the-truck>
References: <20210311000837.3630499-1-robh@kernel.org>
 <20210311000837.3630499-3-robh@kernel.org>
 <20210330153125.GC6567@willie-the-truck>
 <CAL_JsqKN4=T4tHofEoBoWVEZSQEj_m=561_kEdEEkz5szHszhQ@mail.gmail.com>
 <20210331160059.GD7815@willie-the-truck>
 <CAL_Jsq+ga_-5=UBTAn4eGhpL6j2aWFVh9CdxR4XSG7WpYfxNsA@mail.gmail.com>
 <20210407124437.GA15622@willie-the-truck>
 <20210408110800.GA32792@C02TD0UTHF1T.local>
 <CAL_Jsq+H_asWWrHiCk-PBS8xDEGpBL1__dRyrPXdBYgRBBw2vA@mail.gmail.com>
 <20210419161429.GA30998@willie-the-truck>
Message-ID: <CAL_JsqKV_m8tzKpBq=3w-LUksWLmU-1mO1GgQS1nB9sDJanEpQ@mail.gmail.com>

On Mon, Apr 19, 2021 at 11:14 AM Will Deacon <will at kernel.org> wrote:
>
> On Thu, Apr 08, 2021 at 01:38:17PM -0500, Rob Herring wrote:
> > On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland <mark.rutland at arm.com> wrote:
> > > On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > > > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon <will at kernel.org> wrote:
> > > > I guess I'm just worried about exposing the counters to userspace after
> > > > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > > > case we leak other events.
> > >
> > > IMO that's not practically different from the single-PMU case (i.e.
> > > multi-PMU isn't material, either we have a concern with leaking or we
> > > don't); more on that below.
>
> Well, maybe. It looks the single-PMU case is exposed to the same issue,
> but I think a solution needs to take into account the multi-PMU situation.
>
> > > While it looks odd to place this on the mm, I don't think it's the end
> > > of the world.
> > >
> > > > However, I'm not sure how this is supposed to work normally: what
> > > > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > > > event while a task has a counter with direct access -- can that task
> > > > read the kernel event out of the PMU registers from userspace?
> > >
> > > Yes -- userspace could go read any counters even though it isn't
> > > supposed to, and could potentially infer information from those. It
> > > won't have access to the config registers or kernel data structures, so
> > > it isn't guaranteed to know what the even is or when it is
> > > context-switched/reprogrammed/etc.
> > >
> > > If we believe that's a problem, then it's difficult to do anything
> > > robust other than denying userspace access entirely, since disabling
> > > userspace access while in use would surprise applications, and denying
> > > privileged events would need some global state that we consult at event
> > > creation time (in addition to being an inversion of privilege).
> > >
> > > IIRC there was some fuss about this a while back on x86; I'll go dig and
> > > see what I can find, unless Peter has a memory...
> >
> > Maybe this one[1].
> >
> > Rob
> >
> > [1] https://lore.kernel.org/lkml/20200730123815.18518-1-kan.liang at linux.intel.com/
>
> Going through the archives and talking to Peter, it looks like this is still
> an active area of concern:
>
>   - There are patches to clear "dirty" counters on context-switch. They were
>     queued for 5.13 but broke -tip on Friday:
>
>     https://lore.kernel.org/lkml/YHm%2FM4za2LpRYePw at hirez.programming.kicks-ass.net/

Yes, nice timing. I've reworked the arm64 support to do the same
things (minus the breakage). And it looks like we can simplify things
a bit by moving all the context switch handling into .sched_task() and
out of switch_mm. Unless there's some case where that wouldn't work
that I'm not aware of (entirely likely).

>   - Per-cpu events cannot be protected in software:
>
>     https://lore.kernel.org/lkml/CALCETrVVPzUd_hQ8xoomHn_wWRQJUvROeCt2do4_D4ROZoAVMg at mail.gmail.com/
>
>     so without hardware support, we need a way to disable user access for
>     people that care about this leakage
>
> x86 has an "rdpmc" file exposed for the PMU device in sysfs which allows
> access to be disabled. I don't think these patches add such a thing, and
> that's where the fun with multi-PMU machines would come into play.

The fun is because sysfs will end up with multiple 'rdpmc' files or
something else?

Rob


From jonathanh at nvidia.com  Mon Apr 19 20:19:55 2021
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 19 Apr 2021 20:19:55 +0100
Subject: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains
In-Reply-To: <20210330151145.997953-2-maz@kernel.org>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-2-maz@kernel.org>
Message-ID: <316e8be4-fa70-75e8-8483-ae38036306e0@nvidia.com>

Hi Marc,

On 30/03/2021 16:11, Marc Zyngier wrote:
> In anticipation of the removal of the msi_controller structure, convert
> the Tegra host controller driver to MSI domains.
> 
> We end-up with the usual two domain structure, the top one being a
> generic PCI/MSI domain, the bottom one being Tegra-specific and handling
> the actual HW interrupt allocation.
> 
> While at it, convert the normal interrupt handler to a chained handler,
> handle the controller's MSI IRQ edge triggered, support multiple MSIs
> per device and use the AFI_MSI_EN_VEC* registers to provide MSI masking.
> 
> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> [treding at nvidia.com: fix, clean up and address TODOs from Marc's draft]
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> Signed-off-by: Marc Zyngier <maz at kernel.org>


This change is breaking a suspend test that we are running on Tegra124
Jetson-TK1. The Tegra124 Jetson TK1 uses a PCI based ethernet device ...

$ lspci
00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

After resuming from suspend, networking is no longer working. The reason
why this breaks our suspend test is because that setup is using NFS for
the rootfs. I am looking into it, but if anyone has any thoughts please
let me know.

Jon

-- 
nvpublic


From u.kleine-koenig at pengutronix.de  Mon Apr 19 20:29:08 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 19 Apr 2021 21:29:08 +0200
Subject: [PATCH] pwm: atmel: Fix duty cycle calculation in .get_state()
In-Reply-To: <20210418205747.1488248-1-uwe@kleine-koenig.org>
References: <20210418205747.1488248-1-uwe@kleine-koenig.org>
Message-ID: <20210419192908.w2crmmiermdjenrf@pengutronix.de>

Hello,

On Sun, Apr 18, 2021 at 10:57:47PM +0200, Uwe Kleine-K?nig wrote:
> -		tmp = (u64)cdty * NSEC_PER_SEC;
> +		tmp = (u64)(cdty - cprd) * NSEC_PER_SEC;

This is wrong, it must be cprd - cdty. I will send a fixed patch
together with another patch that improves precision of _apply.

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/20210419/8d350d7d/attachment.sig>

From lkp at intel.com  Mon Apr 19 20:50:35 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 03:50:35 +0800
Subject: [xlnx:release-2020.2.2_k26 9559/10480]
 drivers/fpga/fpga-mgr.c:828:2: error: implicit declaration of function
 'set_dma_ops'
Message-ID: <202104200329.PAMcVPVm-lkp@intel.com>

Hi Nava,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx release-2020.2.2_k26
head:   4731ff5042ce76fc145bc2797faa2d91b090675e
commit: ed71785e2c3c3495e89c7b6c3a38699b59bf83d8 [9559/10480] fpga: support loading from a pre-allocated buffer
config: um-randconfig-r002-20210419 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/ed71785e2c3c3495e89c7b6c3a38699b59bf83d8
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx release-2020.2.2_k26
        git checkout ed71785e2c3c3495e89c7b6c3a38699b59bf83d8
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   In file included from include/linux/file.h:9,
                    from include/linux/dma-buf.h:16,
                    from drivers/fpga/fpga-mgr.c:11:
   include/asm-generic/fixmap.h: In function 'fix_to_virt':
   include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |                   ^~
   include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert'
     330 |   if (!(condition))     \
         |         ^~~~~~~~~
   include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
     350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
         |  ^~~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
         |                                     ^~~~~~~~~~~~~~~~~~
   include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
      50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
         |  ^~~~~~~~~~~~~~~~
   include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON'
      32 |  BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
         |  ^~~~~~~~~~~~
   drivers/fpga/fpga-mgr.c: In function 'fpga_mgr_create':
>> drivers/fpga/fpga-mgr.c:828:2: error: implicit declaration of function 'set_dma_ops' [-Werror=implicit-function-declaration]
     828 |  set_dma_ops(&mgr->dev, get_dma_ops(dev));
         |  ^~~~~~~~~~~
>> drivers/fpga/fpga-mgr.c:828:25: error: implicit declaration of function 'get_dma_ops'; did you mean 'get_dma_buf'? [-Werror=implicit-function-declaration]
     828 |  set_dma_ops(&mgr->dev, get_dma_ops(dev));
         |                         ^~~~~~~~~~~
         |                         get_dma_buf
   cc1: some warnings being treated as errors


vim +/set_dma_ops +828 drivers/fpga/fpga-mgr.c

   773	
   774	/**
   775	 * fpga_mgr_create - create and initialize a FPGA manager struct
   776	 * @dev:	fpga manager device from pdev
   777	 * @name:	fpga manager name
   778	 * @mops:	pointer to structure of fpga manager ops
   779	 * @priv:	fpga manager private data
   780	 *
   781	 * The caller of this function is responsible for freeing the struct with
   782	 * fpga_mgr_free().  Using devm_fpga_mgr_create() instead is recommended.
   783	 *
   784	 * Return: pointer to struct fpga_manager or NULL
   785	 */
   786	struct fpga_manager *fpga_mgr_create(struct device *dev, const char *name,
   787					     const struct fpga_manager_ops *mops,
   788					     void *priv)
   789	{
   790		struct fpga_manager *mgr;
   791		int id, ret;
   792	
   793		if (!mops || !mops->write_complete || !mops->state ||
   794		    !mops->write_init || (!mops->write && !mops->write_sg)) {
   795			dev_err(dev, "Attempt to register without fpga_manager_ops\n");
   796			return NULL;
   797		}
   798	
   799		if (!name || !strlen(name)) {
   800			dev_err(dev, "Attempt to register with no name!\n");
   801			return NULL;
   802		}
   803	
   804		mgr = kzalloc(sizeof(*mgr), GFP_KERNEL);
   805		if (!mgr)
   806			return NULL;
   807	
   808		id = ida_simple_get(&fpga_mgr_ida, 0, 0, GFP_KERNEL);
   809		if (id < 0) {
   810			ret = id;
   811			goto error_kfree;
   812		}
   813	
   814		mutex_init(&mgr->ref_mutex);
   815	
   816		mgr->name = name;
   817		mgr->mops = mops;
   818		mgr->priv = priv;
   819	
   820		device_initialize(&mgr->dev);
   821		mgr->dev.class = fpga_mgr_class;
   822		mgr->dev.groups = mops->groups;
   823		mgr->dev.parent = dev;
   824		mgr->dev.of_node = dev->of_node;
   825		mgr->dev.id = id;
   826	
   827		/* Make device dma capable by inheriting from parent's */
 > 828		set_dma_ops(&mgr->dev, get_dma_ops(dev));
   829		ret = dma_coerce_mask_and_coherent(&mgr->dev, dma_get_mask(dev));
   830		if (ret) {
   831			dev_warn(dev,
   832			"Failed to set DMA mask %llx. Trying to continue... %x\n",
   833			dma_get_mask(dev), ret);
   834		}
   835	
   836		ret = dev_set_name(&mgr->dev, "fpga%d", id);
   837		if (ret)
   838			goto error_device;
   839	
   840		mgr->miscdev.minor = MISC_DYNAMIC_MINOR;
   841		mgr->miscdev.name = kobject_name(&mgr->dev.kobj);
   842		mgr->miscdev.fops = &fpga_fops;
   843		ret = misc_register(&mgr->miscdev);
   844		if (ret) {
   845			pr_err("fpga: failed to register misc device.\n");
   846			goto error_device;
   847		}
   848	
   849		return mgr;
   850	
   851	error_device:
   852		ida_simple_remove(&fpga_mgr_ida, id);
   853	error_kfree:
   854		kfree(mgr);
   855	
   856		return NULL;
   857	}
   858	EXPORT_SYMBOL_GPL(fpga_mgr_create);
   859	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 10616 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/fe0cfc27/attachment-0001.gz>

From jonathanh at nvidia.com  Mon Apr 19 21:02:10 2021
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 19 Apr 2021 21:02:10 +0100
Subject: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains
In-Reply-To: <316e8be4-fa70-75e8-8483-ae38036306e0@nvidia.com>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-2-maz@kernel.org>
 <316e8be4-fa70-75e8-8483-ae38036306e0@nvidia.com>
Message-ID: <638a9996-c762-fa11-b740-6a41d4a83bcc@nvidia.com>


On 19/04/2021 20:19, Jon Hunter wrote:
> Hi Marc,
> 
> On 30/03/2021 16:11, Marc Zyngier wrote:
>> In anticipation of the removal of the msi_controller structure, convert
>> the Tegra host controller driver to MSI domains.
>>
>> We end-up with the usual two domain structure, the top one being a
>> generic PCI/MSI domain, the bottom one being Tegra-specific and handling
>> the actual HW interrupt allocation.
>>
>> While at it, convert the normal interrupt handler to a chained handler,
>> handle the controller's MSI IRQ edge triggered, support multiple MSIs
>> per device and use the AFI_MSI_EN_VEC* registers to provide MSI masking.
>>
>> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
>> [treding at nvidia.com: fix, clean up and address TODOs from Marc's draft]
>> Signed-off-by: Thierry Reding <treding at nvidia.com>
>> Signed-off-by: Marc Zyngier <maz at kernel.org>
> 
> 
> This change is breaking a suspend test that we are running on Tegra124
> Jetson-TK1. The Tegra124 Jetson TK1 uses a PCI based ethernet device ...
> 
> $ lspci
> 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1)
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
> 
> After resuming from suspend, networking is no longer working. The reason
> why this breaks our suspend test is because that setup is using NFS for
> the rootfs. I am looking into it, but if anyone has any thoughts please
> let me know.


So the following does appear to fix it ...

diff --git a/drivers/pci/controller/pci-tegra.c
b/drivers/pci/controller/pci-tegra.c
index eaba7b2fab4a..558f02e0693d 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -1802,13 +1802,17 @@ static void tegra_pcie_enable_msi(struct
tegra_pcie *pcie)
 {
        const struct tegra_pcie_soc *soc = pcie->soc;
        struct tegra_msi *msi = &pcie->msi;
-       u32 reg;
+       u32 i, reg;

        afi_writel(pcie, msi->phys >> soc->msi_base_shift,
AFI_MSI_FPCI_BAR_ST);
        afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);
        /* this register is in 4K increments */
        afi_writel(pcie, 1, AFI_MSI_BAR_SZ);

+       /* enable all MSI vectors */
+       for (i = 0; i < 8; i++)
+               afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC(i));
+
        /* and unmask the MSI interrupt */
        reg = afi_readl(pcie, AFI_INTR_MASK);
        reg |= AFI_INTR_MASK_MSI_MASK;
@@ -1837,13 +1841,17 @@ static void tegra_pcie_msi_teardown(struct
tegra_pcie *pcie)

 static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
 {
-       u32 value;
+       u32 i, value;

        /* mask the MSI interrupt */
        value = afi_readl(pcie, AFI_INTR_MASK);
        value &= ~AFI_INTR_MASK_MSI_MASK;
        afi_writel(pcie, value, AFI_INTR_MASK);

+       /* disable all MSI vectors */
+       for (i = 0; i < 8; i++)
+               afi_writel(pcie, 0, AFI_MSI_EN_VEC(i));
+
        return 0;
 }


Any reason why that code was removed?

Thanks
Jon

-- 
nvpublic


From lkp at intel.com  Mon Apr 19 21:35:35 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 04:35:35 +0800
Subject: [xlnx:release-2020.2.2_k26 207/241] drivers/pinctrl/core.c:1273:6:
 warning: 'ret' may be used uninitialized in this function
Message-ID: <202104200427.DwlF97x8-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx release-2020.2.2_k26
head:   4731ff5042ce76fc145bc2797faa2d91b090675e
commit: 11367d8e6e31164b198401335b9a19b5b7234ec0 [207/241] pinctrl: core: Handling pinmux and pinconf separately
config: um-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/11367d8e6e31164b198401335b9a19b5b7234ec0
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx release-2020.2.2_k26
        git checkout 11367d8e6e31164b198401335b9a19b5b7234ec0
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/pinctrl/core.c: In function 'pinctrl_commit_state':
>> drivers/pinctrl/core.c:1273:6: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
    1273 |   if (ret < 0)
         |      ^

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +/ret +1273 drivers/pinctrl/core.c

  1231	
  1232	/**
  1233	 * pinctrl_commit_state() - select/activate/program a pinctrl state to HW
  1234	 * @p: the pinctrl handle for the device that requests configuration
  1235	 * @state: the state handle to select/activate/program
  1236	 */
  1237	static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state)
  1238	{
  1239		struct pinctrl_setting *setting, *setting2;
  1240		struct pinctrl_state *old_state = p->state;
  1241		int ret;
  1242	
  1243		if (p->state) {
  1244			/*
  1245			 * For each pinmux setting in the old state, forget SW's record
  1246			 * of mux owner for that pingroup. Any pingroups which are
  1247			 * still owned by the new state will be re-acquired by the call
  1248			 * to pinmux_enable_setting() in the loop below.
  1249			 */
  1250			list_for_each_entry(setting, &p->state->settings, node) {
  1251				if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
  1252					continue;
  1253				pinmux_disable_setting(setting);
  1254			}
  1255		}
  1256	
  1257		p->state = NULL;
  1258	
  1259		/* Apply all the settings for the new state - pinmux first */
  1260		list_for_each_entry(setting, &state->settings, node) {
  1261			switch (setting->type) {
  1262			case PIN_MAP_TYPE_MUX_GROUP:
  1263				ret = pinmux_enable_setting(setting);
  1264				break;
  1265			case PIN_MAP_TYPE_CONFIGS_PIN:
  1266			case PIN_MAP_TYPE_CONFIGS_GROUP:
  1267				break;
  1268			default:
  1269				ret = -EINVAL;
  1270				break;
  1271			}
  1272	
> 1273			if (ret < 0)
  1274				goto unapply_new_state;
  1275	
  1276			/* Do not link hogs (circular dependency) */
  1277			if (p != setting->pctldev->p)
  1278				pinctrl_link_add(setting->pctldev, p->dev);
  1279		}
  1280	
  1281		/* Apply all the settings for the new state - pinconf after */
  1282		list_for_each_entry(setting, &state->settings, node) {
  1283			switch (setting->type) {
  1284			case PIN_MAP_TYPE_MUX_GROUP:
  1285				break;
  1286			case PIN_MAP_TYPE_CONFIGS_PIN:
  1287			case PIN_MAP_TYPE_CONFIGS_GROUP:
  1288				ret = pinconf_apply_setting(setting);
  1289				break;
  1290			default:
  1291				ret = -EINVAL;
  1292				break;
  1293			}
  1294	
  1295			if (ret < 0) {
  1296				goto unapply_new_state;
  1297			}
  1298	
  1299			/* Do not link hogs (circular dependency) */
  1300			if (p != setting->pctldev->p)
  1301				pinctrl_link_add(setting->pctldev, p->dev);
  1302		}
  1303	
  1304		p->state = state;
  1305	
  1306		return 0;
  1307	
  1308	unapply_new_state:
  1309		dev_err(p->dev, "Error applying setting, reverse things back\n");
  1310	
  1311		list_for_each_entry(setting2, &state->settings, node) {
  1312			if (&setting2->node == &setting->node)
  1313				break;
  1314			/*
  1315			 * All we can do here is pinmux_disable_setting.
  1316			 * That means that some pins are muxed differently now
  1317			 * than they were before applying the setting (We can't
  1318			 * "unmux a pin"!), but it's not a big deal since the pins
  1319			 * are free to be muxed by another apply_setting.
  1320			 */
  1321			if (setting2->type == PIN_MAP_TYPE_MUX_GROUP)
  1322				pinmux_disable_setting(setting2);
  1323		}
  1324	
  1325		/* There's no infinite recursive loop here because p->state is NULL */
  1326		if (old_state)
  1327			pinctrl_select_state(p, old_state);
  1328	
  1329		return ret;
  1330	}
  1331	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 21821 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/8916ef5d/attachment-0001.gz>

From sashal at kernel.org  Mon Apr 19 21:43:26 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:43:26 -0400
Subject: [PATCH AUTOSEL 5.11 07/23] dmaengine: xilinx: dpdma: Fix descriptor
 issuing on video group
In-Reply-To: <20210419204343.6134-1-sashal@kernel.org>
References: <20210419204343.6134-1-sashal@kernel.org>
Message-ID: <20210419204343.6134-7-sashal@kernel.org>

From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

[ Upstream commit 1cbd44666216278bbb6a55bcb6b9283702171c77 ]

When multiple channels are part of a video group, the transfer is
triggered only when all channels in the group are ready. The logic to do
so is incorrect, as it causes the descriptors for all channels but the
last one in a group to not being pushed to the hardware. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Link: https://lore.kernel.org/r/20210307040629.29308-2-laurent.pinchart at ideasonboard.com
Signed-off-by: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/dma/xilinx/xilinx_dpdma.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index 55df63dead8d..d504112c609e 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -839,6 +839,7 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 	struct xilinx_dpdma_tx_desc *desc;
 	struct virt_dma_desc *vdesc;
 	u32 reg, channels;
+	bool first_frame;
 
 	lockdep_assert_held(&chan->lock);
 
@@ -852,14 +853,6 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 		chan->running = true;
 	}
 
-	if (chan->video_group)
-		channels = xilinx_dpdma_chan_video_group_ready(chan);
-	else
-		channels = BIT(chan->id);
-
-	if (!channels)
-		return;
-
 	vdesc = vchan_next_desc(&chan->vchan);
 	if (!vdesc)
 		return;
@@ -884,13 +877,26 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 			    FIELD_PREP(XILINX_DPDMA_CH_DESC_START_ADDRE_MASK,
 				       upper_32_bits(sw_desc->dma_addr)));
 
-	if (chan->first_frame)
+	first_frame = chan->first_frame;
+	chan->first_frame = false;
+
+	if (chan->video_group) {
+		channels = xilinx_dpdma_chan_video_group_ready(chan);
+		/*
+		 * Trigger the transfer only when all channels in the group are
+		 * ready.
+		 */
+		if (!channels)
+			return;
+	} else {
+		channels = BIT(chan->id);
+	}
+
+	if (first_frame)
 		reg = XILINX_DPDMA_GBL_TRIG_MASK(channels);
 	else
 		reg = XILINX_DPDMA_GBL_RETRIG_MASK(channels);
 
-	chan->first_frame = false;
-
 	dpdma_write(xdev->reg, XILINX_DPDMA_GBL, reg);
 }
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 19 21:43:27 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:43:27 -0400
Subject: [PATCH AUTOSEL 5.11 08/23] dmaengine: xilinx: dpdma: Fix race
 condition in done IRQ
In-Reply-To: <20210419204343.6134-1-sashal@kernel.org>
References: <20210419204343.6134-1-sashal@kernel.org>
Message-ID: <20210419204343.6134-8-sashal@kernel.org>

From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

[ Upstream commit 868833fbffbe51c487df4f95d4de9194264a4b30 ]

The active descriptor pointer is accessed from different contexts,
including different interrupt handlers, and its access must be protected
by the channel's lock. This wasn't done in the done IRQ handler. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Link: https://lore.kernel.org/r/20210307040629.29308-3-laurent.pinchart at ideasonboard.com
Signed-off-by: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/dma/xilinx/xilinx_dpdma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index d504112c609e..70b29bd079c9 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -1048,13 +1048,14 @@ static int xilinx_dpdma_chan_stop(struct xilinx_dpdma_chan *chan)
  */
 static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan)
 {
-	struct xilinx_dpdma_tx_desc *active = chan->desc.active;
+	struct xilinx_dpdma_tx_desc *active;
 	unsigned long flags;
 
 	spin_lock_irqsave(&chan->lock, flags);
 
 	xilinx_dpdma_debugfs_desc_done_irq(chan);
 
+	active = chan->desc.active;
 	if (active)
 		vchan_cyclic_callback(&active->vdesc);
 	else
-- 
2.30.2



From sashal at kernel.org  Mon Apr 19 21:43:33 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:43:33 -0400
Subject: [PATCH AUTOSEL 5.11 14/23] arm64: kprobes: Restore local irqflag if
 kprobes is cancelled
In-Reply-To: <20210419204343.6134-1-sashal@kernel.org>
References: <20210419204343.6134-1-sashal@kernel.org>
Message-ID: <20210419204343.6134-14-sashal@kernel.org>

From: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

[ Upstream commit 738fa58ee1328481d1d7889e7c430b3401c571b9 ]

If instruction being single stepped caused a page fault, the kprobes
is cancelled to let the page fault handler continue as a normal page
fault. But the local irqflags are disabled so cpu will restore pstate
with DAIF masked. After pagefault is serviced, the kprobes is
triggerred again, we overwrite the saved_irqflag by calling
kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
irqflag. After kprobes is serviced, the cpu pstate is retored with
DAIF masked.

This patch is inspired by one patch for riscv from Liao Chang.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
Acked-by: Masami Hiramatsu <mhiramat at kernel.org>
Link: https://lore.kernel.org/r/20210412174101.6bfb0594 at xhacker.debian
Signed-off-by: Will Deacon <will at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/probes/kprobes.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 66aac2881ba8..85645b2b0c7a 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -267,10 +267,12 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
 		if (!instruction_pointer(regs))
 			BUG();
 
-		if (kcb->kprobe_status == KPROBE_REENTER)
+		if (kcb->kprobe_status == KPROBE_REENTER) {
 			restore_previous_kprobe(kcb);
-		else
+		} else {
+			kprobes_restore_local_irqflag(kcb, regs);
 			reset_current_kprobe();
+		}
 
 		break;
 	case KPROBE_HIT_ACTIVE:
-- 
2.30.2



From sashal at kernel.org  Mon Apr 19 21:44:04 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:44:04 -0400
Subject: [PATCH AUTOSEL 5.10 06/21] dmaengine: xilinx: dpdma: Fix descriptor
 issuing on video group
In-Reply-To: <20210419204420.6375-1-sashal@kernel.org>
References: <20210419204420.6375-1-sashal@kernel.org>
Message-ID: <20210419204420.6375-6-sashal@kernel.org>

From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

[ Upstream commit 1cbd44666216278bbb6a55bcb6b9283702171c77 ]

When multiple channels are part of a video group, the transfer is
triggered only when all channels in the group are ready. The logic to do
so is incorrect, as it causes the descriptors for all channels but the
last one in a group to not being pushed to the hardware. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Link: https://lore.kernel.org/r/20210307040629.29308-2-laurent.pinchart at ideasonboard.com
Signed-off-by: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/dma/xilinx/xilinx_dpdma.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index 55df63dead8d..d504112c609e 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -839,6 +839,7 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 	struct xilinx_dpdma_tx_desc *desc;
 	struct virt_dma_desc *vdesc;
 	u32 reg, channels;
+	bool first_frame;
 
 	lockdep_assert_held(&chan->lock);
 
@@ -852,14 +853,6 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 		chan->running = true;
 	}
 
-	if (chan->video_group)
-		channels = xilinx_dpdma_chan_video_group_ready(chan);
-	else
-		channels = BIT(chan->id);
-
-	if (!channels)
-		return;
-
 	vdesc = vchan_next_desc(&chan->vchan);
 	if (!vdesc)
 		return;
@@ -884,13 +877,26 @@ static void xilinx_dpdma_chan_queue_transfer(struct xilinx_dpdma_chan *chan)
 			    FIELD_PREP(XILINX_DPDMA_CH_DESC_START_ADDRE_MASK,
 				       upper_32_bits(sw_desc->dma_addr)));
 
-	if (chan->first_frame)
+	first_frame = chan->first_frame;
+	chan->first_frame = false;
+
+	if (chan->video_group) {
+		channels = xilinx_dpdma_chan_video_group_ready(chan);
+		/*
+		 * Trigger the transfer only when all channels in the group are
+		 * ready.
+		 */
+		if (!channels)
+			return;
+	} else {
+		channels = BIT(chan->id);
+	}
+
+	if (first_frame)
 		reg = XILINX_DPDMA_GBL_TRIG_MASK(channels);
 	else
 		reg = XILINX_DPDMA_GBL_RETRIG_MASK(channels);
 
-	chan->first_frame = false;
-
 	dpdma_write(xdev->reg, XILINX_DPDMA_GBL, reg);
 }
 
-- 
2.30.2



From sashal at kernel.org  Mon Apr 19 21:44:05 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:44:05 -0400
Subject: [PATCH AUTOSEL 5.10 07/21] dmaengine: xilinx: dpdma: Fix race
 condition in done IRQ
In-Reply-To: <20210419204420.6375-1-sashal@kernel.org>
References: <20210419204420.6375-1-sashal@kernel.org>
Message-ID: <20210419204420.6375-7-sashal@kernel.org>

From: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

[ Upstream commit 868833fbffbe51c487df4f95d4de9194264a4b30 ]

The active descriptor pointer is accessed from different contexts,
including different interrupt handlers, and its access must be protected
by the channel's lock. This wasn't done in the done IRQ handler. Fix it.

Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Link: https://lore.kernel.org/r/20210307040629.29308-3-laurent.pinchart at ideasonboard.com
Signed-off-by: Vinod Koul <vkoul at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 drivers/dma/xilinx/xilinx_dpdma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index d504112c609e..70b29bd079c9 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -1048,13 +1048,14 @@ static int xilinx_dpdma_chan_stop(struct xilinx_dpdma_chan *chan)
  */
 static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan)
 {
-	struct xilinx_dpdma_tx_desc *active = chan->desc.active;
+	struct xilinx_dpdma_tx_desc *active;
 	unsigned long flags;
 
 	spin_lock_irqsave(&chan->lock, flags);
 
 	xilinx_dpdma_debugfs_desc_done_irq(chan);
 
+	active = chan->desc.active;
 	if (active)
 		vchan_cyclic_callback(&active->vdesc);
 	else
-- 
2.30.2



From sashal at kernel.org  Mon Apr 19 21:44:10 2021
From: sashal at kernel.org (Sasha Levin)
Date: Mon, 19 Apr 2021 16:44:10 -0400
Subject: [PATCH AUTOSEL 5.10 12/21] arm64: kprobes: Restore local irqflag if
 kprobes is cancelled
In-Reply-To: <20210419204420.6375-1-sashal@kernel.org>
References: <20210419204420.6375-1-sashal@kernel.org>
Message-ID: <20210419204420.6375-12-sashal@kernel.org>

From: Jisheng Zhang <Jisheng.Zhang at synaptics.com>

[ Upstream commit 738fa58ee1328481d1d7889e7c430b3401c571b9 ]

If instruction being single stepped caused a page fault, the kprobes
is cancelled to let the page fault handler continue as a normal page
fault. But the local irqflags are disabled so cpu will restore pstate
with DAIF masked. After pagefault is serviced, the kprobes is
triggerred again, we overwrite the saved_irqflag by calling
kprobes_save_local_irqflag(). NOTE, DAIF is masked in this new saved
irqflag. After kprobes is serviced, the cpu pstate is retored with
DAIF masked.

This patch is inspired by one patch for riscv from Liao Chang.

Signed-off-by: Jisheng Zhang <Jisheng.Zhang at synaptics.com>
Acked-by: Masami Hiramatsu <mhiramat at kernel.org>
Link: https://lore.kernel.org/r/20210412174101.6bfb0594 at xhacker.debian
Signed-off-by: Will Deacon <will at kernel.org>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 arch/arm64/kernel/probes/kprobes.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index f11a1a1f7026..798c3e78b84b 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -286,10 +286,12 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
 		if (!instruction_pointer(regs))
 			BUG();
 
-		if (kcb->kprobe_status == KPROBE_REENTER)
+		if (kcb->kprobe_status == KPROBE_REENTER) {
 			restore_previous_kprobe(kcb);
-		else
+		} else {
+			kprobes_restore_local_irqflag(kcb, regs);
 			reset_current_kprobe();
+		}
 
 		break;
 	case KPROBE_HIT_ACTIVE:
-- 
2.30.2



From kuba at kernel.org  Mon Apr 19 22:04:42 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Mon, 19 Apr 2021 14:04:42 -0700
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <20210419140442.79dd0ce0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Sat, 17 Apr 2021 02:42:20 +0300 Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean at nxp.com>
> 
> This patch series contains logic for enabling the lossless mode on the
> RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> memory.
> 
> During testing it was found that, with the default FIFO configuration,
> a sender which isn't persuaded by our PAUSE frames and keeps sending
> will cause some MAC RX frame errors. To mitigate this, we need to ensure
> that the FIFO never runs completely full, so we need to fix up a setting
> that was supposed to be configured well out of reset. Unfortunately this
> requires the addition of a new mini-driver.

FWIW back in the day when I was working on more advanced devices than 
I deal with these days I was expecting to eventually run into this as
well and create some form of devlink umbrella. IMHO such "mini driver"
is a natural place for a devlink instance, and not the PFs/ports.
Is this your thinking as well? AFAICT enetc doesn't implement devlink
today so you start from whatever model works best without worrying
about backward compat.


From dietmar.eggemann at arm.com  Mon Apr 19 22:27:50 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Mon, 19 Apr 2021 23:27:50 +0200
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
 <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>
 <2a4efeea-cc70-ca0a-81fd-84d8b54586c0@arm.com>
 <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>
Message-ID: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com>

On 19/04/2021 04:55, Ruifeng Zhang wrote:
> Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?17??? ??1:00???
>>
>> On 16/04/2021 13:04, Ruifeng Zhang wrote:
>>> Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??6:39???
>>>>
>>>> On 16/04/2021 11:32, Valentin Schneider wrote:
>>>>> On 16/04/21 15:47, Ruifeng Zhang wrote:

[...]

>> I'm afraid that this is now a much weaker case to get this into
>> mainline.
> 
> But it's still a problem and it's not break the original logic ( parse
> topology from MPIDR or parse capacity ), only add the support for
> parse topology from DT.
> I think it should still be merged into the mainline. If don't, the
> DynamIQ SoC has some issue in sched and cpufreq.

IMHO, not necessarily. Your DynamIQ SoC is one cluster with 8 CPUs. It's
subdivided into 2 Frequency Domains (FDs).

CFS Energy-Aware-Scheduling (EAS, find_energy_efficient_cpu()) and
Capacity-Aware-Scheduling (CAS, select_idle_sibling() ->
select_idle_capacity()) work correctly even in case you only have an MC
sched domain (sd).
No matter which sd (MC, DIE) the sd_asym_cpucapacity is, we always
iterate over all CPUs. Per Performance Domains (i.e. FDs) in EAS and
over sched_domain_span(sd) in CAS.

CFS load-balancing (in case your system is `over-utilized`) might work
slightly different due to the missing DIE sd but not inevitably worse.

Do you have benchmarks or testcases in mind which convince you that
Phantom Domains is something you would need? BTW, they are called
Phantom since they let you use uarch and/or max CPU frequency domain to
fake real topology (like LLC) boundaries.

[...]

> Why do you keep the logic of topology_parse_cpu_capacity in arm
> get_coretype_capacity function? The capacity-dmips-mhz will be parsed
> by drivers/base/arch_topology.c as following:
> parse_dt_topology
>     parse_cluster
>         parse_core
>             get_cpu_for_node
>                 topology_parse_cpu_capacity

I think we still need it for systems out there w/o cpu-map in dt, like
my arm32 TC2 with mainline vexpress-v2p-ca15_a7.dts.

It's called twice on each CPU in case I add the cpu-map dt entry though.


From olteanv at gmail.com  Mon Apr 19 22:49:10 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 20 Apr 2021 00:49:10 +0300
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <20210419140442.79dd0ce0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
 <20210419140442.79dd0ce0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <20210419214910.hbwry2cnjn6d7crf@skbuf>

Hi Jakub,

On Mon, Apr 19, 2021 at 02:04:42PM -0700, Jakub Kicinski wrote:
> On Sat, 17 Apr 2021 02:42:20 +0300 Vladimir Oltean wrote:
> > From: Vladimir Oltean <vladimir.oltean at nxp.com>
> > 
> > This patch series contains logic for enabling the lossless mode on the
> > RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> > memory.
> > 
> > During testing it was found that, with the default FIFO configuration,
> > a sender which isn't persuaded by our PAUSE frames and keeps sending
> > will cause some MAC RX frame errors. To mitigate this, we need to ensure
> > that the FIFO never runs completely full, so we need to fix up a setting
> > that was supposed to be configured well out of reset. Unfortunately this
> > requires the addition of a new mini-driver.
> 
> FWIW back in the day when I was working on more advanced devices than 
> I deal with these days I was expecting to eventually run into this as
> well and create some form of devlink umbrella. IMHO such "mini driver"
> is a natural place for a devlink instance, and not the PFs/ports.
> Is this your thinking as well? AFAICT enetc doesn't implement devlink
> today so you start from whatever model works best without worrying
> about backward compat.

Sorry, but I am not sure if I understood the central idea of what you
were trying to transmit. What is 'a devlink instance and not the PFs'?
I am not aware of how a single devlink instance can be exposed for a
piece of hardware presenting itself as multiple PFs with multiple driver
instances running asynchronously and potentially being assigned to AMP
software execution environments (other cores running non-Linux, and most
probably Linux is not even the privileged execution environment which
has write access to the FIFO parameters).
Are you suggesting that the FIFO size and partitioning characteristics
be exposed through the devlink subsystem? Isn't that what devlink-sb is
for? Also, that would not help with what the IERB driver is trying to
achieve. There isn't anything we want the user to view or fiddle with,
the reality is simply that the FIFO parameters were supposed to be
one-size-fits-all-and-nobody-cares-about-them (the memory usage scheme
of this NIC is smart enough to allow for that, or so I think) but
nonetheless, the hardware defaults need to be touched up. If LS1028A was
a new SoC today we would have probably done this from U-Boot, from the
same logic that already passes the MAC addresses to the PFs through the
IERB, but the ship has kind of sailed for that, bootloaders are stable,
and 'Linux needs this feature' is not a good reason to update them.
So this is all that I would like the IERB driver to do, notice how it's
all writes of predefined values but no reads. For next generation SoCs
with ENETC we'll try our best to not need an IERB driver in Linux at
all. Another option would have been to do these fixups in the arch init
code as a sort of erratum workaround, but I didn't find a place similar
to arch/arm/mach-* for arm64, so I assumed that the arm64 port just
doesn't want to go that route. So here I am with a driver for some
memory writes.


From f.fainelli at gmail.com  Mon Apr 19 22:54:30 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 19 Apr 2021 14:54:30 -0700
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
 <20210409153309.wbebto3eufui35qs@e107158-lin>
 <be48adb2-c838-1a9b-37bc-da783f3d5dd3@nokia.com>
 <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com>
Message-ID: <b26651f2-a5ca-ff5d-23e4-05b7eb7d9583@gmail.com>



On 4/12/2021 4:08 AM, Qais Yousef wrote:
> Hi Alexander
> 
> Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in
> your future postings.
> 
> On 04/12/21 08:28, Alexander Sverdlin wrote:
>> Hi!
>>
>> On 09/04/2021 17:33, Qais Yousef wrote:
>>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't
>>> work out for you? I struggle to see how this is better and why it was hard to
>>> incorporate my suggestion.
>>>
>>> For example
>>>
>>> 	-       old = ftrace_call_replace(ip, adjust_address(rec, addr));
>>> 	+#ifdef CONFIG_ARM_MODULE_PLTS
>>> 	+       /* mod is only supplied during module loading */
>>> 	+       if (!mod)
>>> 	+               mod = rec->arch.mod;
>>> 	+       else
>>> 	+               rec->arch.mod = mod;
>>> 	+#endif
>>> 	+
>>> 	+       old = ftrace_call_replace(ip, aaddr,
>>> 	+                                 !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod);
>>> 	+#ifdef CONFIG_ARM_MODULE_PLTS
>>> 	+       if (!old && mod) {
>>> 	+               aaddr = get_module_plt(mod, ip, aaddr);
>>> 	+               old = ftrace_call_replace(ip, aaddr, true);
>>> 	+       }
>>> 	+#endif
>>> 	+
>>>
>>> There's an ifdef, followed by a code that embeds
>>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/
>>
>> No, it's actually two small ifdefed blocks added before and after an original call,
>> which parameters have been modified as well. The issue with arch.mod was explained
>> by Steven Rostedt, maybe you've missed his email.
> 
> If you're referring to arch.mod having to be protected by the ifdef I did
> address that. Please look at my patch.
> 
> My comment here refers to the ugliness of this ifdefery. Introducing 2 simple
> wrapper functions would address that as I've demonstrated in my
> suggestion/patch.

What is the plan to move forward with this patch series, should v8 be
submitted into RMK's patch tracker and improved upon from there, or do
you feel like your suggestion needs to be addressed right away?
-- 
Florian


From qais.yousef at arm.com  Mon Apr 19 23:34:48 2021
From: qais.yousef at arm.com (Qais Yousef)
Date: Mon, 19 Apr 2021 23:34:48 +0100
Subject: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
In-Reply-To: <b26651f2-a5ca-ff5d-23e4-05b7eb7d9583@gmail.com>
References: <20210330114035.18575-1-alexander.sverdlin@nokia.com>
 <20210409153309.wbebto3eufui35qs@e107158-lin>
 <be48adb2-c838-1a9b-37bc-da783f3d5dd3@nokia.com>
 <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com>
 <b26651f2-a5ca-ff5d-23e4-05b7eb7d9583@gmail.com>
Message-ID: <20210419223448.vummlz37nyc3a64i@e107158-lin.cambridge.arm.com>

On 04/19/21 14:54, Florian Fainelli wrote:
> 
> 
> On 4/12/2021 4:08 AM, Qais Yousef wrote:
> > Hi Alexander
> > 
> > Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in
> > your future postings.
> > 
> > On 04/12/21 08:28, Alexander Sverdlin wrote:
> >> Hi!
> >>
> >> On 09/04/2021 17:33, Qais Yousef wrote:
> >>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't
> >>> work out for you? I struggle to see how this is better and why it was hard to
> >>> incorporate my suggestion.
> >>>
> >>> For example
> >>>
> >>> 	-       old = ftrace_call_replace(ip, adjust_address(rec, addr));
> >>> 	+#ifdef CONFIG_ARM_MODULE_PLTS
> >>> 	+       /* mod is only supplied during module loading */
> >>> 	+       if (!mod)
> >>> 	+               mod = rec->arch.mod;
> >>> 	+       else
> >>> 	+               rec->arch.mod = mod;
> >>> 	+#endif
> >>> 	+
> >>> 	+       old = ftrace_call_replace(ip, aaddr,
> >>> 	+                                 !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod);
> >>> 	+#ifdef CONFIG_ARM_MODULE_PLTS
> >>> 	+       if (!old && mod) {
> >>> 	+               aaddr = get_module_plt(mod, ip, aaddr);
> >>> 	+               old = ftrace_call_replace(ip, aaddr, true);
> >>> 	+       }
> >>> 	+#endif
> >>> 	+
> >>>
> >>> There's an ifdef, followed by a code that embeds
> >>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/
> >>
> >> No, it's actually two small ifdefed blocks added before and after an original call,
> >> which parameters have been modified as well. The issue with arch.mod was explained
> >> by Steven Rostedt, maybe you've missed his email.
> > 
> > If you're referring to arch.mod having to be protected by the ifdef I did
> > address that. Please look at my patch.
> > 
> > My comment here refers to the ugliness of this ifdefery. Introducing 2 simple
> > wrapper functions would address that as I've demonstrated in my
> > suggestion/patch.
> 
> What is the plan to move forward with this patch series, should v8 be
> submitted into RMK's patch tracker and improved upon from there, or do
> you feel like your suggestion needs to be addressed right away?

There's no objection from my side to submitting this and improve later.

Thanks

--
Qais Yousef


From patchwork-bot+netdevbpf at kernel.org  Mon Apr 19 23:40:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Mon, 19 Apr 2021 22:40:10 +0000
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <161887201069.19818.8834514668475852756.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Sat, 17 Apr 2021 02:42:20 +0300 you wrote:
> From: Vladimir Oltean <vladimir.oltean at nxp.com>
> 
> This patch series contains logic for enabling the lossless mode on the
> RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> memory.
> 
> During testing it was found that, with the default FIFO configuration,
> a sender which isn't persuaded by our PAUSE frames and keeps sending
> will cause some MAC RX frame errors. To mitigate this, we need to ensure
> that the FIFO never runs completely full, so we need to fix up a setting
> that was supposed to be configured well out of reset. Unfortunately this
> requires the addition of a new mini-driver.
> 
> [...]

Here is the summary with links:
  - [net-next,1/5] net: enetc: create a common enetc_pf_to_port helper
    https://git.kernel.org/netdev/net-next/c/87614b931c24
  - [net-next,2/5] dt-bindings: net: fsl: enetc: add the IERB documentation
    https://git.kernel.org/netdev/net-next/c/4ac7acc67f29
  - [net-next,3/5] net: enetc: add a mini driver for the Integrated Endpoint Register Block
    https://git.kernel.org/netdev/net-next/c/e7d48e5fbf30
  - [net-next,4/5] arm64: dts: ls1028a: declare the Integrated Endpoint Register Block node
    https://git.kernel.org/netdev/net-next/c/b764dc6cc1ba
  - [net-next,5/5] net: enetc: add support for flow control
    https://git.kernel.org/netdev/net-next/c/a8648887880f

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From patchwork-bot+netdevbpf at kernel.org  Mon Apr 19 23:50:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Mon, 19 Apr 2021 22:50:10 +0000
Subject: [PATCH v2 net-next] net: ethernet: mediatek: fix a typo bug in
 flow offloading
In-Reply-To: <20210417072905.207032-1-dqfext@gmail.com>
References: <20210417072905.207032-1-dqfext@gmail.com>
Message-ID: <161887261000.25363.1625251709846918967.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Sat, 17 Apr 2021 15:29:04 +0800 you wrote:
> Issue was traffic problems after a while with increased ping times if
> flow offload is active. It turns out that key_offset with cookie is
> needed in rhashtable_params but was re-assigned to head_offset.
> Fix the assignment.
> 
> Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support")
> Signed-off-by: DENG Qingfang <dqfext at gmail.com>
> 
> [...]

Here is the summary with links:
  - [v2,net-next] net: ethernet: mediatek: fix a typo bug in flow offloading
    https://git.kernel.org/netdev/net-next/c/6ecaf81d4ac6

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From lyude at redhat.com  Mon Apr 19 23:55:10 2021
From: lyude at redhat.com (Lyude Paul)
Date: Mon, 19 Apr 2021 18:55:10 -0400
Subject: [PATCH v3 08/20] drm/dp: Pass drm_dp_aux to
 drm_dp_link_train_clock_recovery_delay()
In-Reply-To: <20210419225523.184856-1-lyude@redhat.com>
References: <20210419225523.184856-1-lyude@redhat.com>
Message-ID: <20210419225523.184856-9-lyude@redhat.com>

So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().

Signed-off-by: Lyude Paul <lyude at redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c              | 2 +-
 drivers/gpu/drm/drm_dp_helper.c                       | 3 ++-
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c                      | 2 +-
 drivers/gpu/drm/msm/edp/edp_ctrl.c                    | 2 +-
 drivers/gpu/drm/radeon/atombios_dp.c                  | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c                      | 2 +-
 include/drm/drm_dp_helper.h                           | 4 +++-
 8 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 14a097322238..b0eaeb6afd29 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -617,7 +617,7 @@ amdgpu_atombios_dp_link_train_cr(struct amdgpu_atombios_dp_link_train_info *dp_i
 	dp_info->tries = 0;
 	voltage = 0xff;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+		drm_dp_link_train_clock_recovery_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b197fdac2334..3a3c4cfb9ac6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
 
-void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+					    const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
 	unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 					 DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 591ddc4b876c..198ddb3c173a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
 							enum drm_dp_phy dp_phy)
 {
 	if (dp_phy == DP_PHY_DPRX)
-		drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+		drm_dp_link_train_clock_recovery_delay(&intel_dp->aux, intel_dp->dpcd);
 	else
 		drm_dp_lttpr_link_train_clock_recovery_delay();
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
 	tries = 0;
 	old_v_level = ctrl->link->phy_params.v_level;
 	for (tries = 0; tries < maximum_retries; tries++) {
-		drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+		drm_dp_link_train_clock_recovery_delay(ctrl->aux, ctrl->panel->dpcd);
 
 		ret = dp_ctrl_read_link_status(ctrl, link_status);
 		if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
 	tries = 0;
 	old_v_level = ctrl->v_level;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+		drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux, ctrl->dpcd);
 
 		rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
 		if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct radeon_dp_link_train_info *dp_info)
 	dp_info->tries = 0;
 	voltage = 0xff;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+		drm_dp_link_train_clock_recovery_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index e8efbab5ae69..6ef2d9b3884c 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -713,7 +713,7 @@ static int zynqmp_dp_link_train_cr(struct zynqmp_dp *dp)
 		if (ret)
 			return ret;
 
-		drm_dp_link_train_clock_recovery_delay(dp->dpcd);
+		drm_dp_link_train_clock_recovery_delay(&dp->aux, dp->dpcd);
 		ret = drm_dp_dpcd_read_link_status(&dp->aux, link_status);
 		if (ret < 0)
 			return ret;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 417b2c101a1e..9900c93e4f2c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -29,6 +29,7 @@
 #include <drm/drm_connector.h>
 
 struct drm_device;
+struct drm_dp_aux;
 
 /*
  * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
@@ -1482,7 +1483,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 #define DP_LTTPR_COMMON_CAP_SIZE	8
 #define DP_LTTPR_PHY_CAP_SIZE		3
 
-void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+					    const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_clock_recovery_delay(void);
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_channel_eq_delay(const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
-- 
2.30.2



From lyude at redhat.com  Mon Apr 19 23:55:11 2021
From: lyude at redhat.com (Lyude Paul)
Date: Mon, 19 Apr 2021 18:55:11 -0400
Subject: [PATCH v3 09/20] drm/dp: Pass drm_dp_aux to
 drm_dp*_link_train_channel_eq_delay()
In-Reply-To: <20210419225523.184856-1-lyude@redhat.com>
References: <20210419225523.184856-1-lyude@redhat.com>
Message-ID: <20210419225523.184856-10-lyude@redhat.com>

So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().

Signed-off-by: Lyude Paul <lyude at redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c           |  2 +-
 drivers/gpu/drm/drm_dp_helper.c                    | 14 +++++++++-----
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  4 ++--
 drivers/gpu/drm/msm/dp/dp_ctrl.c                   |  4 ++--
 drivers/gpu/drm/msm/edp/edp_ctrl.c                 |  4 ++--
 drivers/gpu/drm/radeon/atombios_dp.c               |  2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c                   |  2 +-
 include/drm/drm_dp_helper.h                        |  6 ++++--
 8 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index b0eaeb6afd29..9f0acee0a271 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -682,7 +682,7 @@ amdgpu_atombios_dp_link_train_ce(struct amdgpu_atombios_dp_link_train_info *dp_i
 	dp_info->tries = 0;
 	channel_eq = false;
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+		drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3a3c4cfb9ac6..eaafc676aa0c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+						 unsigned long rd_interval)
 {
 	if (rd_interval > 4)
 		DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
 	usleep_range(rd_interval, rd_interval * 2);
 }
 
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-	__drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+	__drm_dp_link_train_channel_eq_delay(aux,
+					     dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 					     DP_TRAINING_AUX_RD_MASK);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
 	return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
 }
 
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					      const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE])
 {
 	u8 interval = dp_lttpr_phy_cap(phy_cap,
 				       DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
 		      DP_TRAINING_AUX_RD_MASK;
 
-	__drm_dp_link_train_channel_eq_delay(interval);
+	__drm_dp_link_train_channel_eq_delay(aux, interval);
 }
 EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 198ddb3c173a..6bf6f1ec13ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct intel_dp *intel_dp,
 						  enum drm_dp_phy dp_phy)
 {
 	if (dp_phy == DP_PHY_DPRX) {
-		drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+		drm_dp_link_train_channel_eq_delay(&intel_dp->aux, intel_dp->dpcd);
 	} else {
 		const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
 
-		drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+		drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux, phy_caps);
 	}
 }
 
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct dp_ctrl_private *ctrl)
 static void dp_ctrl_clear_training_pattern(struct dp_ctrl_private *ctrl)
 {
 	dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_DISABLE);
-	drm_dp_link_train_channel_eq_delay(ctrl->panel->dpcd);
+	drm_dp_link_train_channel_eq_delay(ctrl->aux, ctrl->panel->dpcd);
 }
 
 static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
@@ -1215,7 +1215,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
 	dp_ctrl_train_pattern_set(ctrl, pattern | DP_RECOVERED_CLOCK_OUT_EN);
 
 	for (tries = 0; tries <= maximum_retries; tries++) {
-		drm_dp_link_train_channel_eq_delay(ctrl->panel->dpcd);
+		drm_dp_link_train_channel_eq_delay(ctrl->aux, ctrl->panel->dpcd);
 
 		ret = dp_ctrl_read_link_status(ctrl, link_status);
 		if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 6501598448b4..4fb397ee7c84 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -665,7 +665,7 @@ static int edp_start_link_train_2(struct edp_ctrl *ctrl)
 		return ret;
 
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(ctrl->dpcd);
+		drm_dp_link_train_channel_eq_delay(ctrl->drm_aux, ctrl->dpcd);
 
 		rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
 		if (rlen < DP_LINK_STATUS_SIZE) {
@@ -743,7 +743,7 @@ static int edp_clear_training_pattern(struct edp_ctrl *ctrl)
 
 	ret = edp_train_pattern_set_write(ctrl, 0);
 
-	drm_dp_link_train_channel_eq_delay(ctrl->dpcd);
+	drm_dp_link_train_channel_eq_delay(ctrl->drm_aux, ctrl->dpcd);
 
 	return ret;
 }
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 299b9d8da376..4c1e551d9714 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -743,7 +743,7 @@ static int radeon_dp_link_train_ce(struct radeon_dp_link_train_info *dp_info)
 	dp_info->tries = 0;
 	channel_eq = false;
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+		drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 6ef2d9b3884c..cc98ac009ecd 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -778,7 +778,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
 		if (ret)
 			return ret;
 
-		drm_dp_link_train_channel_eq_delay(dp->dpcd);
+		drm_dp_link_train_channel_eq_delay(&dp->aux, dp->dpcd);
 		ret = drm_dp_dpcd_read_link_status(&dp->aux, link_status);
 		if (ret < 0)
 			return ret;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9900c93e4f2c..b162aed6f1c8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1486,8 +1486,10 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
 					    const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_clock_recovery_delay(void);
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					      const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
 
 u8 drm_dp_link_rate_to_bw_code(int link_rate);
 int drm_dp_bw_code_to_link_rate(u8 link_bw);
-- 
2.30.2



From patchwork-bot+netdevbpf at kernel.org  Tue Apr 20 00:10:15 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Mon, 19 Apr 2021 23:10:15 +0000
Subject: [PATCH net-next 1/1] net: stmmac: fix memory leak during driver
 probe
In-Reply-To: <20210419112530.20395-1-vee.khee.wong@linux.intel.com>
References: <20210419112530.20395-1-vee.khee.wong@linux.intel.com>
Message-ID: <161887381539.661.5024854346370869109.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Mon, 19 Apr 2021 19:25:30 +0800 you wrote:
> On driver probe, kmemleak reported the following memory leak which was
> due to allocated bitmap that was not being freed in stmmac_dvr_probe().
> 
> unreferenced object 0xffff9276014b13c0 (size 8):
>   comm "systemd-udevd", pid 2143, jiffies 4294681112 (age 116.720s)
>   hex dump (first 8 bytes):
>     00 00 00 00 00 00 00 00                          ........
>   backtrace:
>     [<00000000c51e34b2>] stmmac_dvr_probe+0x1c0/0x440 [stmmac]
>     [<00000000b530eb41>] intel_eth_pci_probe.cold+0x2b/0x14e [dwmac_intel]
>     [<00000000b10f8929>] pci_device_probe+0xd2/0x150
>     [<00000000fb254c74>] really_probe+0xf8/0x410
>     [<0000000034128a59>] driver_probe_device+0x5d/0x150
>     [<00000000016104d5>] device_driver_attach+0x53/0x60
>     [<00000000cb18cd07>] __driver_attach+0x96/0x140
>     [<00000000da9ffd5c>] bus_for_each_dev+0x7a/0xc0
>     [<00000000af061a88>] bus_add_driver+0x184/0x1f0
>     [<000000008be5c1c5>] driver_register+0x6c/0xc0
>     [<0000000052b18a9e>] do_one_initcall+0x4d/0x210
>     [<00000000154d4f07>] do_init_module+0x5c/0x230
>     [<000000009b648d09>] load_module+0x2a5a/0x2d40
>     [<000000000d86b76d>] __do_sys_finit_module+0xb5/0x120
>     [<000000002b0cef95>] do_syscall_64+0x33/0x40
>     [<0000000067b45bbb>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> [...]

Here is the summary with links:
  - [net-next,1/1] net: stmmac: fix memory leak during driver probe
    https://git.kernel.org/netdev/net-next/c/d7f576dc9836

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From song.bao.hua at hisilicon.com  Tue Apr 20 01:18:40 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 20 Apr 2021 12:18:40 +1200
Subject: [RFC PATCH v6 0/4] scheduler: expose the topology of clusters and add
 cluster scheduler
Message-ID: <20210420001844.9116-1-song.bao.hua@hisilicon.com>

ARM64 server chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data while each cluster has
local L3 tag. On the other hand, each cluster will share some internal system
bus. This means cache is much more affine inside one cluster than across
clusters.

    +-----------------------------------+                          +---------+
    |  +------+    +------+            +---------------------------+         |
    |  | CPU0 |    | cpu1 |             |    +-----------+         |         |
    |  +------+    +------+             |    |           |         |         |
    |                                   +----+    L3     |         |         |
    |  +------+    +------+   cluster   |    |    tag    |         |         |
    |  | CPU2 |    | CPU3 |             |    |           |         |         |
    |  +------+    +------+             |    +-----------+         |         |
    |                                   |                          |         |
    +-----------------------------------+                          |         |
    +-----------------------------------+                          |         |
    |  +------+    +------+             +--------------------------+         |
    |  |      |    |      |             |    +-----------+         |         |
    |  +------+    +------+             |    |           |         |         |
    |                                   |    |    L3     |         |         |
    |  +------+    +------+             +----+    tag    |         |         |
    |  |      |    |      |             |    |           |         |         |
    |  +------+    +------+             |    +-----------+         |         |
    |                                   |                          |         |
    +-----------------------------------+                          |   L3    |
                                                                   |   data  |
    +-----------------------------------+                          |         |
    |  +------+    +------+             |    +-----------+         |         |
    |  |      |    |      |             |    |           |         |         |
    |  +------+    +------+             +----+    L3     |         |         |
    |                                   |    |    tag    |         |         |
    |  +------+    +------+             |    |           |         |         |
    |  |      |    |      |            ++    +-----------+         |         |
    |  +------+    +------+            |---------------------------+         |
    +-----------------------------------|                          |         |
    +-----------------------------------|                          |         |
    |  +------+    +------+            +---------------------------+         |
    |  |      |    |      |             |    +-----------+         |         |
    |  +------+    +------+             |    |           |         |         |
    |                                   +----+    L3     |         |         |
    |  +------+    +------+             |    |    tag    |         |         |
    |  |      |    |      |             |    |           |         |         |
    |  +------+    +------+             |    +-----------+         |         |
    |                                   |                          |         |
    +-----------------------------------+                          |         |
    +-----------------------------------+                          |         |
    |  +------+    +------+             +--------------------------+         |
    |  |      |    |      |             |   +-----------+          |         |
    |  +------+    +------+             |   |           |          |         |


There is a similar need for clustering in x86.  Some x86 cores could share L2 caches
that is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 clusters
of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing L3).  

Having a sched_domain for clusters will bring two aspects of improvement:
1. spreading unrelated tasks among clusters, which decreases the contention of resources
and improve the throughput.
unrelated tasks might be put randomly without cluster sched_domain:
+-------------------+            +-----------------+
| +----+   +----+   |            |                 |
| |task|   |task|   |            |                 |
| |1   |   |2   |   |            |                 |
| +----+   +----+   |            |                 |
|                   |            |                 |
|       cluster1    |            |     cluster2    |
+-------------------+            +-----------------+

but with cluster sched_domain, they are likely to spread due to LB:
+-------------------+            +-----------------+
| +----+            |            | +----+          |
| |task|            |            | |task|          |
| |1   |            |            | |2   |          |
| +----+            |            | +----+          |
|                   |            |                 |
|       cluster1    |            |     cluster2    |
+-------------------+            +-----------------+

2. gathering related tasks within a cluster, which improves the cache affinity of tasks
talking with each other.
Without cluster sched_domain, related tasks might be put randomly. In case task1-8 have
relationship as below:
Task1 talks with task5
Task2 talks with task6
Task3 talks with task7
Task4 talks with task8
With the tuning of select_idle_cpu() to scan local cluster first, those tasks might
get a chance to be gathered like:
+---------------------------+    +----------------------+
| +----+        +-----+     |    | +----+      +-----+  |
| |task|        |task |     |    | |task|      |task |  |
| |1   |        | 5   |     |    | |3   |      |7    |  |
| +----+        +-----+     |    | +----+      +-----+  |
|                           |    |                      |
|       cluster1            |    |     cluster2         |
|                           |    |                      |
|                           |    |                      |
| +-----+       +------+    |    | +-----+     +------+ |
| |task |       | task |    |    | |task |     |task  | |
| |2    |       |  6   |    |    | |4    |     |8     | |
| +-----+       +------+    |    | +-----+     +------+ |
+---------------------------+    +----------------------+
Otherwise, the result might be:
+---------------------------+    +----------------------+
| +----+        +-----+     |    | +----+      +-----+  |
| |task|        |task |     |    | |task|      |task |  |
| |1   |        | 2   |     |    | |5   |      |6    |  |
| +----+        +-----+     |    | +----+      +-----+  |
|                           |    |                      |
|       cluster1            |    |     cluster2         |
|                           |    |                      |
|                           |    |                      |
| +-----+       +------+    |    | +-----+     +------+ |
| |task |       | task |    |    | |task |     |task  | |
| |3    |       |  4   |    |    | |7    |     |8     | |
| +-----+       +------+    |    | +-----+     +------+ |
+---------------------------+    +----------------------+

-v6:
  * added topology_cluster_cpumask() for x86, code provided by Tim.

  * emulated a two-level spreading/packing heuristic by only scanning cluster
    in wake_affine path for tasks running in same LLC(also NUMA).

    This partially addressed Dietmar's comment in RFC v3:
    "In case we would like to further distinguish between llc-packing and
     even narrower (cluster or MC-L2)-packing, we would introduce a 2. level
     packing vs. spreading heuristic further down in sis().
   
     IMHO, Barry's current implementation doesn't do this right now. Instead
     he's trying to pack on cluster first and if not successful look further
     among the remaining llc CPUs for an idle CPU."

  * adjusted the hackbench parameter to make relatively low and high load.
    previous patchsets with "-f 10" ran under an extremely high load with
    hundreds of threads, which seems not real use cases.

    This also addressed Vincent's question in RFC v4:
    "In particular, I'm still not convinced that the modification of the wakeup
    path is the root of the hackbench improvement; especially with g=14 where
    there should not be much idle CPUs with 14*40 tasks on at most 32 CPUs."

-v5:
  * split "add scheduler level for clusters" into two patches to evaluate the
    impact of spreading and gathering separately;
  * add a tracepoint of select_idle_cpu for debug purpose; add bcc script in
    commit log;
  * add cluster_id = -1 in reset_cpu_topology()
  * rebased to tip/sched/core

-v4:
  * rebased to tip/sched/core with the latest unified code of select_idle_cpu
  * added Tim's patch for x86 Jacobsville
  * also added benchmark data of spreading unrelated tasks
  * avoided the iteration of sched_domain by moving to static_key(addressing
    Vincent's comment
  * used acpi_cpu_id for acpi_find_processor_node(addressing Masa's comment)

Barry Song (2):
  scheduler: add scheduler level for clusters
  scheduler: scan idle cpu in cluster for tasks within one LLC

Jonathan Cameron (1):
  topology: Represent clusters of CPUs within a die

Tim Chen (1):
  scheduler: Add cluster scheduler level for x86

 Documentation/admin-guide/cputopology.rst | 26 +++++++++++--
 arch/arm64/Kconfig                        |  7 ++++
 arch/arm64/kernel/topology.c              |  2 +
 arch/x86/Kconfig                          |  8 ++++
 arch/x86/include/asm/smp.h                |  7 ++++
 arch/x86/include/asm/topology.h           |  2 +
 arch/x86/kernel/cpu/cacheinfo.c           |  1 +
 arch/x86/kernel/cpu/common.c              |  3 ++
 arch/x86/kernel/smpboot.c                 | 43 ++++++++++++++++++++-
 block/blk-mq.c                            |  2 +-
 drivers/acpi/pptt.c                       | 63 +++++++++++++++++++++++++++++++
 drivers/base/arch_topology.c              | 15 ++++++++
 drivers/base/topology.c                   | 10 +++++
 include/linux/acpi.h                      |  5 +++
 include/linux/arch_topology.h             |  5 +++
 include/linux/sched/cluster.h             | 19 ++++++++++
 include/linux/sched/sd_flags.h            |  9 +++++
 include/linux/sched/topology.h            | 12 +++++-
 include/linux/topology.h                  | 13 +++++++
 kernel/sched/core.c                       | 29 ++++++++++++--
 kernel/sched/fair.c                       | 51 +++++++++++++++----------
 kernel/sched/sched.h                      |  4 ++
 kernel/sched/topology.c                   | 18 +++++++++
 23 files changed, 324 insertions(+), 30 deletions(-)
 create mode 100644 include/linux/sched/cluster.h

-- 
1.8.3.1



From song.bao.hua at hisilicon.com  Tue Apr 20 01:18:41 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 20 Apr 2021 12:18:41 +1200
Subject: [RFC PATCH v6 1/4] topology: Represent clusters of CPUs within a die
In-Reply-To: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
Message-ID: <20210420001844.9116-2-song.bao.hua@hisilicon.com>

From: Jonathan Cameron <Jonathan.Cameron at huawei.com>

Both ACPI and DT provide the ability to describe additional layers of
topology between that of individual cores and higher level constructs
such as the level at which the last level cache is shared.
In ACPI this can be represented in PPTT as a Processor Hierarchy
Node Structure [1] that is the parent of the CPU cores and in turn
has a parent Processor Hierarchy Nodes Structure representing
a higher level of topology.

For example Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus.

+-----------------------------------+                          +---------+
|  +------+    +------+            +---------------------------+         |
|  | CPU0 |    | cpu1 |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   +----+    L3     |         |         |
|  +------+    +------+   cluster   |    |    tag    |         |         |
|  | CPU2 |    | CPU3 |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   |    |    L3     |         |         |
|  +------+    +------+             +----+    tag    |         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |   L3    |
                                                               |   data  |
+-----------------------------------+                          |         |
|  +------+    +------+             |    +-----------+         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             +----+    L3     |         |         |
|                                   |    |    tag    |         |         |
|  +------+    +------+             |    |           |         |         |
|  |      |    |      |            ++    +-----------+         |         |
|  +------+    +------+            |---------------------------+         |
+-----------------------------------|                          |         |
+-----------------------------------|                          |         |
|  +------+    +------+            +---------------------------+         |
|  |      |    |      |             |    +-----------+         |         |
|  +------+    +------+             |    |           |         |         |
|                                   +----+    L3     |         |         |
|  +------+    +------+             |    |    tag    |         |         |
|  |      |    |      |             |    |           |         |         |
|  +------+    +------+             |    +-----------+         |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                          |         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |   +-----------+          |         |
|  +------+    +------+             |   |           |          |         |
|                                   |   |    L3     |          |         |
|  +------+    +------+             +---+    tag    |          |         |
|  |      |    |      |             |   |           |          |         |
|  +------+    +------+             |   +-----------+          |         |
|                                   |                          |         |
+-----------------------------------+                          |         |
+-----------------------------------+                         ++         |
|  +------+    +------+             +--------------------------+         |
|  |      |    |      |             |  +-----------+           |         |
|  +------+    +------+             |  |           |           |         |
|                                   |  |    L3     |           |         |
|  +------+    +------+             +--+    tag    |           |         |
|  |      |    |      |             |  |           |           |         |
|  +------+    +------+             |  +-----------+           |         |
|                                   |                          +---------+
+-----------------------------------+

That means the cost to transfer ownership of a cacheline between CPUs
within a cluster is lower than between CPUs in different clusters on
the same die. Hence, it can make sense to tell the scheduler to use
the cache affinity of the cluster to make better decision on thread
migration.

This patch simply exposes this information to userspace libraries
like hwloc by providing cluster_cpus and related sysfs attributes.
PoC of HWLOC support at [2].

Note this patch only handle the ACPI case.

Special consideration is needed for SMT processors, where it is
necessary to move 2 levels up the hierarchy from the leaf nodes
(thus skipping the processor core level).

Currently the ID provided is the offset of the Processor
Hierarchy Nodes Structure within PPTT.  Whilst this is unique
it is not terribly elegant so alternative suggestions welcome.

Note that arm64 / ACPI does not provide any means of identifying
a die level in the topology but that may be unrelate to the cluster
level.

[1] ACPI Specification 6.3 - section 5.2.29.1 processor hierarchy node
    structure (Type 0)
[2] https://github.com/hisilicon/hwloc/tree/linux-cluster

Signed-off-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 -v6:
 * the topology ABI documents required by Greg is not completed yet.
   will have a separate patch for that.

 Documentation/admin-guide/cputopology.rst | 26 +++++++++++--
 arch/arm64/kernel/topology.c              |  2 +
 drivers/acpi/pptt.c                       | 63 +++++++++++++++++++++++++++++++
 drivers/base/arch_topology.c              | 15 ++++++++
 drivers/base/topology.c                   | 10 +++++
 include/linux/acpi.h                      |  5 +++
 include/linux/arch_topology.h             |  5 +++
 include/linux/topology.h                  |  6 +++
 8 files changed, 128 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst
index b90dafc..f9d3745 100644
--- a/Documentation/admin-guide/cputopology.rst
+++ b/Documentation/admin-guide/cputopology.rst
@@ -24,6 +24,12 @@ core_id:
 	identifier (rather than the kernel's).  The actual value is
 	architecture and platform dependent.
 
+cluster_id:
+
+	the Cluster ID of cpuX.  Typically it is the hardware platform's
+	identifier (rather than the kernel's).  The actual value is
+	architecture and platform dependent.
+
 book_id:
 
 	the book ID of cpuX. Typically it is the hardware platform's
@@ -56,6 +62,14 @@ package_cpus_list:
 	human-readable list of CPUs sharing the same physical_package_id.
 	(deprecated name: "core_siblings_list")
 
+cluster_cpus:
+
+	internal kernel map of CPUs within the same cluster.
+
+cluster_cpus_list:
+
+	human-readable list of CPUs within the same cluster.
+
 die_cpus:
 
 	internal kernel map of CPUs within the same die.
@@ -96,11 +110,13 @@ these macros in include/asm-XXX/topology.h::
 
 	#define topology_physical_package_id(cpu)
 	#define topology_die_id(cpu)
+	#define topology_cluster_id(cpu)
 	#define topology_core_id(cpu)
 	#define topology_book_id(cpu)
 	#define topology_drawer_id(cpu)
 	#define topology_sibling_cpumask(cpu)
 	#define topology_core_cpumask(cpu)
+	#define topology_cluster_cpumask(cpu)
 	#define topology_die_cpumask(cpu)
 	#define topology_book_cpumask(cpu)
 	#define topology_drawer_cpumask(cpu)
@@ -116,10 +132,12 @@ not defined by include/asm-XXX/topology.h:
 
 1) topology_physical_package_id: -1
 2) topology_die_id: -1
-3) topology_core_id: 0
-4) topology_sibling_cpumask: just the given CPU
-5) topology_core_cpumask: just the given CPU
-6) topology_die_cpumask: just the given CPU
+3) topology_cluster_id: -1
+4) topology_core_id: 0
+5) topology_sibling_cpumask: just the given CPU
+6) topology_core_cpumask: just the given CPU
+7) topology_cluster_cpumask: just the given CPU
+8) topology_die_cpumask: just the given CPU
 
 For architectures that don't support books (CONFIG_SCHED_BOOK) there are no
 default definitions for topology_book_id() and topology_book_cpumask().
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index e08a412..d72eb8d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -103,6 +103,8 @@ int __init parse_acpi_topology(void)
 			cpu_topology[cpu].thread_id  = -1;
 			cpu_topology[cpu].core_id    = topology_id;
 		}
+		topology_id = find_acpi_cpu_topology_cluster(cpu);
+		cpu_topology[cpu].cluster_id = topology_id;
 		topology_id = find_acpi_cpu_topology_package(cpu);
 		cpu_topology[cpu].package_id = topology_id;
 
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
index 4ae9335..11f8b02 100644
--- a/drivers/acpi/pptt.c
+++ b/drivers/acpi/pptt.c
@@ -737,6 +737,69 @@ int find_acpi_cpu_topology_package(unsigned int cpu)
 }
 
 /**
+ * find_acpi_cpu_topology_cluster() - Determine a unique CPU cluster value
+ * @cpu: Kernel logical CPU number
+ *
+ * Determine a topology unique cluster ID for the given CPU/thread.
+ * This ID can then be used to group peers, which will have matching ids.
+ *
+ * The cluster, if present is the level of topology above CPUs. In a
+ * multi-thread CPU, it will be the level above the CPU, not the thread.
+ * It may not exist in single CPU systems. In simple multi-CPU systems,
+ * it may be equal to the package topology level.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found
+ * or there is no toplogy level above the CPU..
+ * Otherwise returns a value which represents the package for this CPU.
+ */
+
+int find_acpi_cpu_topology_cluster(unsigned int cpu)
+{
+	struct acpi_table_header *table;
+	acpi_status status;
+	struct acpi_pptt_processor *cpu_node, *cluster_node;
+	u32 acpi_cpu_id;
+	int retval;
+	int is_thread;
+
+	status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+	if (ACPI_FAILURE(status)) {
+		acpi_pptt_warn_missing();
+		return -ENOENT;
+	}
+
+	acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+	cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+	if (cpu_node == NULL || !cpu_node->parent) {
+		retval = -ENOENT;
+		goto put_table;
+	}
+
+	is_thread = cpu_node->flags & ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD;
+	cluster_node = fetch_pptt_node(table, cpu_node->parent);
+	if (cluster_node == NULL) {
+		retval = -ENOENT;
+		goto put_table;
+	}
+	if (is_thread) {
+		if (!cluster_node->parent) {
+			retval = -ENOENT;
+			goto put_table;
+		}
+		cluster_node = fetch_pptt_node(table, cluster_node->parent);
+		if (cluster_node == NULL) {
+			retval = -ENOENT;
+			goto put_table;
+		}
+	}
+	retval = ACPI_PTR_DIFF(cluster_node, table);
+put_table:
+	acpi_put_table(table);
+
+	return retval;
+}
+
+/**
  * find_acpi_cpu_topology_hetero_id() - Get a core architecture tag
  * @cpu: Kernel logical CPU number
  *
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index de8587c..ca3b8c1 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -506,6 +506,11 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
 	return core_mask;
 }
 
+const struct cpumask *cpu_clustergroup_mask(int cpu)
+{
+	return &cpu_topology[cpu].cluster_sibling;
+}
+
 void update_siblings_masks(unsigned int cpuid)
 {
 	struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
@@ -523,6 +528,11 @@ void update_siblings_masks(unsigned int cpuid)
 		if (cpuid_topo->package_id != cpu_topo->package_id)
 			continue;
 
+		if (cpuid_topo->cluster_id == cpu_topo->cluster_id) {
+			cpumask_set_cpu(cpu, &cpuid_topo->cluster_sibling);
+			cpumask_set_cpu(cpuid, &cpu_topo->cluster_sibling);
+		}
+
 		cpumask_set_cpu(cpuid, &cpu_topo->core_sibling);
 		cpumask_set_cpu(cpu, &cpuid_topo->core_sibling);
 
@@ -541,6 +551,9 @@ static void clear_cpu_topology(int cpu)
 	cpumask_clear(&cpu_topo->llc_sibling);
 	cpumask_set_cpu(cpu, &cpu_topo->llc_sibling);
 
+	cpumask_clear(&cpu_topo->cluster_sibling);
+	cpumask_set_cpu(cpu, &cpu_topo->cluster_sibling);
+
 	cpumask_clear(&cpu_topo->core_sibling);
 	cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
 	cpumask_clear(&cpu_topo->thread_sibling);
@@ -556,6 +569,7 @@ void __init reset_cpu_topology(void)
 
 		cpu_topo->thread_id = -1;
 		cpu_topo->core_id = -1;
+		cpu_topo->cluster_id = -1;
 		cpu_topo->package_id = -1;
 		cpu_topo->llc_id = -1;
 
@@ -571,6 +585,7 @@ void remove_cpu_topology(unsigned int cpu)
 		cpumask_clear_cpu(cpu, topology_core_cpumask(sibling));
 	for_each_cpu(sibling, topology_sibling_cpumask(cpu))
 		cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
+
 	for_each_cpu(sibling, topology_llc_cpumask(cpu))
 		cpumask_clear_cpu(cpu, topology_llc_cpumask(sibling));
 
diff --git a/drivers/base/topology.c b/drivers/base/topology.c
index 4d254fc..7157ac0 100644
--- a/drivers/base/topology.c
+++ b/drivers/base/topology.c
@@ -46,6 +46,9 @@
 define_id_show_func(die_id);
 static DEVICE_ATTR_RO(die_id);
 
+define_id_show_func(cluster_id);
+static DEVICE_ATTR_RO(cluster_id);
+
 define_id_show_func(core_id);
 static DEVICE_ATTR_RO(core_id);
 
@@ -61,6 +64,10 @@
 static DEVICE_ATTR_RO(core_siblings);
 static DEVICE_ATTR_RO(core_siblings_list);
 
+define_siblings_show_func(cluster_cpus, cluster_cpumask);
+static DEVICE_ATTR_RO(cluster_cpus);
+static DEVICE_ATTR_RO(cluster_cpus_list);
+
 define_siblings_show_func(die_cpus, die_cpumask);
 static DEVICE_ATTR_RO(die_cpus);
 static DEVICE_ATTR_RO(die_cpus_list);
@@ -88,6 +95,7 @@
 static struct attribute *default_attrs[] = {
 	&dev_attr_physical_package_id.attr,
 	&dev_attr_die_id.attr,
+	&dev_attr_cluster_id.attr,
 	&dev_attr_core_id.attr,
 	&dev_attr_thread_siblings.attr,
 	&dev_attr_thread_siblings_list.attr,
@@ -95,6 +103,8 @@
 	&dev_attr_core_cpus_list.attr,
 	&dev_attr_core_siblings.attr,
 	&dev_attr_core_siblings_list.attr,
+	&dev_attr_cluster_cpus.attr,
+	&dev_attr_cluster_cpus_list.attr,
 	&dev_attr_die_cpus.attr,
 	&dev_attr_die_cpus_list.attr,
 	&dev_attr_package_cpus.attr,
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 9f43241..138b779 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1307,6 +1307,7 @@ static inline int lpit_read_residency_count_address(u64 *address)
 #ifdef CONFIG_ACPI_PPTT
 int acpi_pptt_cpu_is_thread(unsigned int cpu);
 int find_acpi_cpu_topology(unsigned int cpu, int level);
+int find_acpi_cpu_topology_cluster(unsigned int cpu);
 int find_acpi_cpu_topology_package(unsigned int cpu);
 int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
 int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
@@ -1319,6 +1320,10 @@ static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
 {
 	return -EINVAL;
 }
+static inline int find_acpi_cpu_topology_cluster(unsigned int cpu)
+{
+	return -EINVAL;
+}
 static inline int find_acpi_cpu_topology_package(unsigned int cpu)
 {
 	return -EINVAL;
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 0f6cd6b..987c7ea 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -49,10 +49,12 @@ void topology_set_thermal_pressure(const struct cpumask *cpus,
 struct cpu_topology {
 	int thread_id;
 	int core_id;
+	int cluster_id;
 	int package_id;
 	int llc_id;
 	cpumask_t thread_sibling;
 	cpumask_t core_sibling;
+	cpumask_t cluster_sibling;
 	cpumask_t llc_sibling;
 };
 
@@ -60,13 +62,16 @@ struct cpu_topology {
 extern struct cpu_topology cpu_topology[NR_CPUS];
 
 #define topology_physical_package_id(cpu)	(cpu_topology[cpu].package_id)
+#define topology_cluster_id(cpu)	(cpu_topology[cpu].cluster_id)
 #define topology_core_id(cpu)		(cpu_topology[cpu].core_id)
 #define topology_core_cpumask(cpu)	(&cpu_topology[cpu].core_sibling)
 #define topology_sibling_cpumask(cpu)	(&cpu_topology[cpu].thread_sibling)
+#define topology_cluster_cpumask(cpu)	(&cpu_topology[cpu].cluster_sibling)
 #define topology_llc_cpumask(cpu)	(&cpu_topology[cpu].llc_sibling)
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
+const struct cpumask *cpu_clustergroup_mask(int cpu);
 void update_siblings_masks(unsigned int cpu);
 void remove_cpu_topology(unsigned int cpuid);
 void reset_cpu_topology(void);
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 7634cd7..80d27d7 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -186,6 +186,9 @@ static inline int cpu_to_mem(int cpu)
 #ifndef topology_die_id
 #define topology_die_id(cpu)			((void)(cpu), -1)
 #endif
+#ifndef topology_cluster_id
+#define topology_cluster_id(cpu)		((void)(cpu), -1)
+#endif
 #ifndef topology_core_id
 #define topology_core_id(cpu)			((void)(cpu), 0)
 #endif
@@ -195,6 +198,9 @@ static inline int cpu_to_mem(int cpu)
 #ifndef topology_core_cpumask
 #define topology_core_cpumask(cpu)		cpumask_of(cpu)
 #endif
+#ifndef topology_cluster_cpumask
+#define topology_cluster_cpumask(cpu)		cpumask_of(cpu)
+#endif
 #ifndef topology_die_cpumask
 #define topology_die_cpumask(cpu)		cpumask_of(cpu)
 #endif
-- 
1.8.3.1



From song.bao.hua at hisilicon.com  Tue Apr 20 01:18:42 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 20 Apr 2021 12:18:42 +1200
Subject: [RFC PATCH v6 2/4] scheduler: add scheduler level for clusters
In-Reply-To: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
Message-ID: <20210420001844.9116-3-song.bao.hua@hisilicon.com>

ARM64 chip Kunpeng 920 has 6 or 8 clusters in each NUMA node, and each
cluster has 4 cpus. All clusters share L3 cache data, but each cluster
has local L3 tag. On the other hand, each clusters will share some
internal system bus. This means cache coherence overhead inside one
cluster is much less than the overhead across clusters.

This patch adds the sched_domain for clusters. On kunpeng 920, without
this patch, domain0 of cpu0 would be MC with cpu0~cpu23 with ; with this
patch, MC becomes domain1, a new domain0 "CLS" including cpu0-cpu3.

This will help spread unrelated tasks among clusters, thus decrease the
contention and improve the throughput, for example, stream benchmark can
improve 20%+ while parallelism is 6 and improve around 5% while paralle-
lism is 12:

(1) -P <parallelism> 6
$ numactl -N 0 /usr/lib/lmbench/bin/stream -P 6 -M 1024M -N 5

w/o patch:
STREAM copy latency: 2.46 nanoseconds
STREAM copy bandwidth: 39096.28 MB/sec
STREAM scale latency: 2.46 nanoseconds
STREAM scale bandwidth: 38970.26 MB/sec
STREAM add latency: 4.45 nanoseconds
STREAM add bandwidth: 32332.04 MB/sec
STREAM triad latency: 4.07 nanoseconds
STREAM triad bandwidth: 35387.69 MB/sec

w/ patch:
STREAM copy latency: 2.02 nanoseconds
STREAM copy bandwidth: 47604.47 MB/sec   +21.7%
STREAM scale latency: 2.04 nanoseconds
STREAM scale bandwidth: 47066.84 MB/sec  +20.8%
STREAM add latency: 3.35 nanoseconds
STREAM add bandwidth: 42942.15 MB/sec    +32.8%
STREAM triad latency: 3.16 nanoseconds
STREAM triad bandwidth: 45619.18 MB/sec  +28.9%

On the other hand,stream result could change significantly during different
tests without the patch, eg:
a.
STREAM copy latency: 2.16 nanoseconds
STREAM copy bandwidth: 44448.45 MB/sec
STREAM scale latency: 2.17 nanoseconds
STREAM scale bandwidth: 44320.77 MB/sec
STREAM add latency: 3.77 nanoseconds
STREAM add bandwidth: 38230.54 MB/sec
STREAM triad latency: 3.88 nanoseconds
STREAM triad bandwidth: 37072.10 MB/sec

b.
STREAM copy latency: 2.16 nanoseconds
STREAM copy bandwidth: 44403.22 MB/sec
STREAM scale latency: 2.39 nanoseconds
STREAM scale bandwidth: 40173.69 MB/sec
STREAM add latency: 3.77 nanoseconds
STREAM add bandwidth: 38232.56 MB/sec
STREAM triad latency: 3.38 nanoseconds
STREAM triad bandwidth: 42592.04 MB/sec

Obviously it is because the 6 threads are put randomly in 6 cores. Sometimes
they are packed in clusters, sometimes they are spread widely.

(2) -P <parallelism> 12
$ numactl -N 0 /usr/lib/lmbench/bin/stream -P 12 -M 1024M -N 5

w/o patch:
STREAM copy latency: 3.37 nanoseconds
STREAM copy bandwidth: 57008.80 MB/sec
STREAM scale latency: 3.38 nanoseconds
STREAM scale bandwidth: 56848.47 MB/sec
STREAM add latency: 5.50 nanoseconds
STREAM add bandwidth: 52398.62 MB/sec
STREAM triad latency: 5.09 nanoseconds
STREAM triad bandwidth: 56591.60 MB/sec

w/ patch:
STREAM copy latency: 3.24 nanoseconds
STREAM copy bandwidth: 59338.60 MB/sec  +4.1%
STREAM scale latency: 3.25 nanoseconds
STREAM scale bandwidth: 58993.23 MB/sec +3.7%
STREAM add latency: 5.19 nanoseconds
STREAM add bandwidth: 55517.45 MB/sec   +5.9%
STREAM triad latency: 4.86 nanoseconds
STREAM triad bandwidth: 59245.34 MB/sec +4.7%

Obviously the load balance between clusters help improve the parallelism
of unrelated tasks.

To evaluate the performance impact to related tasks talking with each
other, we run the below hackbench with different -g parameter from 6
to 32 in a NUMA node with 24 cores, for each different g, we run the
command 20 times and get the average time:
$ numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g $1
As -f is set to 1, this means all threads are talking with each other
monogamously.

hackbench will report the time which is needed to complete a certain number
of messages transmissions between a certain number of tasks, for example:
$ numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g 6
Running in threaded mode with 6 groups using 2 file descriptors each (== 12 tasks)
Each sender will pass 1000000 messages of 100 bytes

The below is the result of hackbench w/ and w/o the patch:
g=    6       12    18      24    28     32
w/o: 1.2474 1.5635 1.5133 1.4796 1.6177 1.7898
w/ : 1.1458 1.3309 1.3416 1.4990 1.9212 2.3411

It seems this patch benefits hackbench when the load is relatively low,
while it hurts hackbench much when the load is relatively high(56 and
64 threads in 24 cores).

Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 arch/arm64/Kconfig             |  7 +++++++
 include/linux/sched/cluster.h  | 19 +++++++++++++++++++
 include/linux/sched/sd_flags.h |  9 +++++++++
 include/linux/sched/topology.h |  7 +++++++
 include/linux/topology.h       |  7 +++++++
 kernel/sched/core.c            | 20 ++++++++++++++++++++
 kernel/sched/fair.c            |  4 ++++
 kernel/sched/sched.h           |  1 +
 kernel/sched/topology.c        |  6 ++++++
 9 files changed, 80 insertions(+)
 create mode 100644 include/linux/sched/cluster.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1f212b4..9432a30 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -977,6 +977,13 @@ config SCHED_MC
 	  making when dealing with multi-core CPU chips at a cost of slightly
 	  increased overhead in some places. If unsure say N here.
 
+config SCHED_CLUSTER
+	bool "Cluster scheduler support"
+	help
+	  Cluster scheduler support improves the CPU scheduler's decision
+	  making when dealing with machines that have clusters(sharing internal
+	  bus or sharing LLC cache tag). If unsure say N here.
+
 config SCHED_SMT
 	bool "SMT scheduler support"
 	help
diff --git a/include/linux/sched/cluster.h b/include/linux/sched/cluster.h
new file mode 100644
index 0000000..ea6c475
--- /dev/null
+++ b/include/linux/sched/cluster.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_SCHED_CLUSTER_H
+#define _LINUX_SCHED_CLUSTER_H
+
+#include <linux/static_key.h>
+
+#ifdef CONFIG_SCHED_CLUSTER
+extern struct static_key_false sched_cluster_present;
+
+static __always_inline bool sched_cluster_active(void)
+{
+	return static_branch_likely(&sched_cluster_present);
+}
+#else
+static inline bool sched_cluster_active(void) { return false; }
+
+#endif
+
+#endif
diff --git a/include/linux/sched/sd_flags.h b/include/linux/sched/sd_flags.h
index 34b21e9..fc3c894 100644
--- a/include/linux/sched/sd_flags.h
+++ b/include/linux/sched/sd_flags.h
@@ -100,6 +100,15 @@
 SD_FLAG(SD_SHARE_CPUCAPACITY, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS)
 
 /*
+ * Domain members share CPU cluster resources (i.e. llc cache tags)
+ *
+ * SHARED_CHILD: Set from the base domain up until spanned CPUs no longer share
+ *               the cluster resouces (such as llc tags and internal bus)
+ * NEEDS_GROUPS: Caches are shared between groups.
+ */
+SD_FLAG(SD_SHARE_CLS_RESOURCES, SDF_SHARED_CHILD | SDF_NEEDS_GROUPS)
+
+/*
  * Domain members share CPU package resources (i.e. caches)
  *
  * SHARED_CHILD: Set from the base domain up until spanned CPUs no longer share
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index 8f0f778..846fcac 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -42,6 +42,13 @@ static inline int cpu_smt_flags(void)
 }
 #endif
 
+#ifdef CONFIG_SCHED_CLUSTER
+static inline int cpu_cluster_flags(void)
+{
+	return SD_SHARE_CLS_RESOURCES | SD_SHARE_PKG_RESOURCES;
+}
+#endif
+
 #ifdef CONFIG_SCHED_MC
 static inline int cpu_core_flags(void)
 {
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 80d27d7..0b3704a 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -212,6 +212,13 @@ static inline const struct cpumask *cpu_smt_mask(int cpu)
 }
 #endif
 
+#if defined(CONFIG_SCHED_CLUSTER) && !defined(cpu_cluster_mask)
+static inline const struct cpumask *cpu_cluster_mask(int cpu)
+{
+	return topology_cluster_cpumask(cpu);
+}
+#endif
+
 static inline const struct cpumask *cpu_cpu_mask(int cpu)
 {
 	return cpumask_of_node(cpu_to_node(cpu));
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 95bd6ab..30c300c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7840,6 +7840,17 @@ int sched_cpu_activate(unsigned int cpu)
 	if (cpumask_weight(cpu_smt_mask(cpu)) == 2)
 		static_branch_inc_cpuslocked(&sched_smt_present);
 #endif
+
+#ifdef CONFIG_SCHED_CLUSTER
+	/*
+	 * When going up, increment the number of cluster cpus with
+	 * cluster present.
+	 */
+	if (cpumask_weight(cpu_cluster_mask(cpu)) > cpumask_weight(cpu_smt_mask(cpu)) &&
+	    cpumask_weight(cpu_cluster_mask(cpu)) < cpumask_weight(cpu_coregroup_mask(cpu)))
+		static_branch_inc_cpuslocked(&sched_cluster_present);
+#endif
+
 	set_cpu_active(cpu, true);
 
 	if (sched_smp_initialized) {
@@ -7916,6 +7927,15 @@ int sched_cpu_deactivate(unsigned int cpu)
 		static_branch_dec_cpuslocked(&sched_smt_present);
 #endif
 
+#ifdef CONFIG_SCHED_CLUSTER
+	/*
+	 * When going down, decrement the number of cpus with cluster present.
+	 */
+	if (cpumask_weight(cpu_cluster_mask(cpu)) > cpumask_weight(cpu_smt_mask(cpu)) &&
+	    cpumask_weight(cpu_cluster_mask(cpu)) < cpumask_weight(cpu_coregroup_mask(cpu)))
+		static_branch_dec_cpuslocked(&sched_cluster_present);
+#endif
+
 	if (!sched_smp_initialized)
 		return 0;
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6d73bdb..a327746 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6021,6 +6021,10 @@ static inline int __select_idle_cpu(int cpu)
 	return -1;
 }
 
+#ifdef CONFIG_SCHED_CLUSTER
+DEFINE_STATIC_KEY_FALSE(sched_cluster_present);
+#endif
+
 #ifdef CONFIG_SCHED_SMT
 DEFINE_STATIC_KEY_FALSE(sched_smt_present);
 EXPORT_SYMBOL_GPL(sched_smt_present);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index cbb0b01..4e938ba 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -6,6 +6,7 @@
 
 #include <linux/sched/autogroup.h>
 #include <linux/sched/clock.h>
+#include <linux/sched/cluster.h>
 #include <linux/sched/coredump.h>
 #include <linux/sched/cpufreq.h>
 #include <linux/sched/cputime.h>
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index d1aec24..829ac9d 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1392,6 +1392,7 @@ static void claim_allocations(int cpu, struct sched_domain *sd)
  */
 #define TOPOLOGY_SD_FLAGS		\
 	(SD_SHARE_CPUCAPACITY	|	\
+	 SD_SHARE_CLS_RESOURCES	|	\
 	 SD_SHARE_PKG_RESOURCES |	\
 	 SD_NUMA		|	\
 	 SD_ASYM_PACKING)
@@ -1511,6 +1512,11 @@ static void claim_allocations(int cpu, struct sched_domain *sd)
 #ifdef CONFIG_SCHED_SMT
 	{ cpu_smt_mask, cpu_smt_flags, SD_INIT_NAME(SMT) },
 #endif
+
+#ifdef CONFIG_SCHED_CLUSTER
+       { cpu_clustergroup_mask, cpu_cluster_flags, SD_INIT_NAME(CLS) },
+#endif
+
 #ifdef CONFIG_SCHED_MC
 	{ cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },
 #endif
-- 
1.8.3.1



From song.bao.hua at hisilicon.com  Tue Apr 20 01:18:43 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 20 Apr 2021 12:18:43 +1200
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
Message-ID: <20210420001844.9116-4-song.bao.hua@hisilicon.com>

On kunpeng920, cpus within one cluster can communicate wit each other
much faster than cpus across different clusters. A simple hackbench
can prove that.
hackbench running on 4 cpus in single one cluster and 4 cpus in
different clusters shows a large contrast:
(1) within a cluster:
root at ubuntu:~# taskset -c 0,1,2,3 hackbench -p -T -l 20000 -g 1
Running in threaded mode with 1 groups using 40 file descriptors each
(== 40 tasks)
Each sender will pass 20000 messages of 100 bytes
Time: 4.285

(2) across clusters:
root at ubuntu:~# taskset -c 0,4,8,12 hackbench -p -T -l 20000 -g 1
Running in threaded mode with 1 groups using 40 file descriptors each
(== 40 tasks)
Each sender will pass 20000 messages of 100 bytes
Time: 5.524

This inspires us to change the wake_affine path to scan cluster to pack
the related tasks. Ideally, a two-level packing vs. spreading heuristic
could be introduced to distinguish between llc-packing and even narrower
(cluster or MC-L2)-packing. But this way would be quite trivial. So this
patch begins from those tasks running in same LLC. This is actually quite
common in real use cases when tasks are bound in a NUMA.

If users use "numactl -N 0" to bind tasks, this patch will scan cluster
rather than llc to select idle cpu. A hackbench running with some groups
of monogamous sender-receiver model shows a major improvement.

To evaluate the performance impact to related tasks talking with each
other, we run the below hackbench with different -g parameter from 6
to 32 in a NUMA node with 24 cores, for each different g, we run the
command 20 times and get the average time:
$ numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g $1
As -f is set to 1, this means all threads are talking with each other
monogamously.

hackbench will report the time which is needed to complete a certain number
of messages transmissions between a certain number of tasks, for example:
$ numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g 6
Running in threaded mode with 6 groups using 2 file descriptors each (== 12 tasks)
Each sender will pass 1000000 messages of 100 bytes

The below is the result of hackbench:
g                =    6      12      18     24    28    32
w/o                 1.2474 1.5635 1.5133 1.4796 1.6177 1.7898
w/domain            1.1458 1.3309 1.3416 1.4990 1.9212 2.3411
w/domain+affine     0.9500 1.0728 1.1756 1.2201 1.4166 1.5464

w/o: without any change
w/domain: added cluster domain without changing wake_affine
w/domain+affine: added cluster domain, changed wake_affine

while g=6, if we use top -H to show the cpus which tasks are running on,
we can easily find couples are running in same CCL.

Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 -v6:
  * emulated a two-level spreading/packing heuristic by only scanning cluster
    in wake_affine path for tasks running in same LLC(also NUMA).

    This partially addressed Dietmar's comment in RFC v3:
    "In case we would like to further distinguish between llc-packing and
     even narrower (cluster or MC-L2)-packing, we would introduce a 2. level
     packing vs. spreading heuristic further down in sis().
   
     IMHO, Barry's current implementation doesn't do this right now. Instead
     he's trying to pack on cluster first and if not successful look further
     among the remaining llc CPUs for an idle CPU."

  * adjusted the hackbench parameter to make relatively low and high load.
    previous patchsets with "-f 10" ran under an extremely high load with
    hundreds of threads, which seems not real use cases.

    This also addressed Vincent's question in RFC v4:
    "In particular, I'm still not convinced that the modification of the wakeup
    path is the root of the hackbench improvement; especially with g=14 where
    there should not be much idle CPUs with 14*40 tasks on at most 32 CPUs."

 block/blk-mq.c                 |  2 +-
 include/linux/sched/topology.h |  5 +++--
 kernel/sched/core.c            |  9 +++++---
 kernel/sched/fair.c            | 47 +++++++++++++++++++++++++-----------------
 kernel/sched/sched.h           |  3 +++
 kernel/sched/topology.c        | 12 +++++++++++
 6 files changed, 53 insertions(+), 25 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index d4d7c1c..1418981 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -611,7 +611,7 @@ static inline bool blk_mq_complete_need_ipi(struct request *rq)
 	/* same CPU or cache domain?  Complete locally */
 	if (cpu == rq->mq_ctx->cpu ||
 	    (!test_bit(QUEUE_FLAG_SAME_FORCE, &rq->q->queue_flags) &&
-	     cpus_share_cache(cpu, rq->mq_ctx->cpu)))
+	     cpus_share_cache(cpu, rq->mq_ctx->cpu, 0)))
 		return false;
 
 	/* don't try to IPI to an offline CPU */
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index 846fcac..d63d6b8 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -176,7 +176,8 @@ extern void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
 cpumask_var_t *alloc_sched_domains(unsigned int ndoms);
 void free_sched_domains(cpumask_var_t doms[], unsigned int ndoms);
 
-bool cpus_share_cache(int this_cpu, int that_cpu);
+/* return true if cpus share cluster(while cluster=1) or llc cache */
+bool cpus_share_cache(int this_cpu, int that_cpu, int cluster);
 
 typedef const struct cpumask *(*sched_domain_mask_f)(int cpu);
 typedef int (*sched_domain_flags_f)(void);
@@ -225,7 +226,7 @@ struct sched_domain_topology_level {
 {
 }
 
-static inline bool cpus_share_cache(int this_cpu, int that_cpu)
+static inline bool cpus_share_cache(int this_cpu, int that_cpu, int cluster)
 {
 	return true;
 }
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 30c300c..c74812a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3126,9 +3126,12 @@ void wake_up_if_idle(int cpu)
 	rcu_read_unlock();
 }
 
-bool cpus_share_cache(int this_cpu, int that_cpu)
+bool cpus_share_cache(int this_cpu, int that_cpu, int cluster)
 {
-	return per_cpu(sd_llc_id, this_cpu) == per_cpu(sd_llc_id, that_cpu);
+	if (cluster)
+		return per_cpu(sd_cluster_id, this_cpu) == per_cpu(sd_cluster_id, that_cpu);
+	else
+		return per_cpu(sd_llc_id, this_cpu) == per_cpu(sd_llc_id, that_cpu);
 }
 
 static inline bool ttwu_queue_cond(int cpu, int wake_flags)
@@ -3144,7 +3147,7 @@ static inline bool ttwu_queue_cond(int cpu, int wake_flags)
 	 * If the CPU does not share cache, then queue the task on the
 	 * remote rqs wakelist to avoid accessing remote data.
 	 */
-	if (!cpus_share_cache(smp_processor_id(), cpu))
+	if (!cpus_share_cache(smp_processor_id(), cpu, 0))
 		return true;
 
 	/*
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a327746..69a1704 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -718,7 +718,7 @@ static u64 sched_vslice(struct cfs_rq *cfs_rq, struct sched_entity *se)
 #include "pelt.h"
 #ifdef CONFIG_SMP
 
-static int select_idle_sibling(struct task_struct *p, int prev_cpu, int cpu);
+static int select_idle_sibling(struct task_struct *p, int prev_cpu, int cpu, int cluster);
 static unsigned long task_h_load(struct task_struct *p);
 static unsigned long capacity_of(int cpu);
 
@@ -5786,11 +5786,12 @@ static void record_wakee(struct task_struct *p)
  * whatever is irrelevant, spread criteria is apparent partner count exceeds
  * socket size.
  */
-static int wake_wide(struct task_struct *p)
+static int wake_wide(struct task_struct *p, int cluster)
 {
 	unsigned int master = current->wakee_flips;
 	unsigned int slave = p->wakee_flips;
-	int factor = __this_cpu_read(sd_llc_size);
+	int factor = cluster ? __this_cpu_read(sd_cluster_size) :
+		__this_cpu_read(sd_llc_size);
 
 	if (master < slave)
 		swap(master, slave);
@@ -5812,7 +5813,7 @@ static int wake_wide(struct task_struct *p)
  *			  for the overloaded case.
  */
 static int
-wake_affine_idle(int this_cpu, int prev_cpu, int sync)
+wake_affine_idle(int this_cpu, int prev_cpu, int sync, int cluster)
 {
 	/*
 	 * If this_cpu is idle, it implies the wakeup is from interrupt
@@ -5826,7 +5827,7 @@ static int wake_wide(struct task_struct *p)
 	 * a cpufreq perspective, it's better to have higher utilisation
 	 * on one CPU.
 	 */
-	if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu))
+	if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu, cluster))
 		return available_idle_cpu(prev_cpu) ? prev_cpu : this_cpu;
 
 	if (sync && cpu_rq(this_cpu)->nr_running == 1)
@@ -5882,12 +5883,12 @@ static int wake_wide(struct task_struct *p)
 }
 
 static int wake_affine(struct sched_domain *sd, struct task_struct *p,
-		       int this_cpu, int prev_cpu, int sync)
+		       int this_cpu, int prev_cpu, int sync, int cluster)
 {
 	int target = nr_cpumask_bits;
 
 	if (sched_feat(WA_IDLE))
-		target = wake_affine_idle(this_cpu, prev_cpu, sync);
+		target = wake_affine_idle(this_cpu, prev_cpu, sync, cluster);
 
 	if (sched_feat(WA_WEIGHT) && target == nr_cpumask_bits)
 		target = wake_affine_weight(sd, p, this_cpu, prev_cpu, sync);
@@ -6139,7 +6140,8 @@ static inline int select_idle_core(struct task_struct *p, int core, struct cpuma
  * comparing the average scan cost (tracked in sd->avg_scan_cost) against the
  * average idle time for this rq (as found in rq->avg_idle).
  */
-static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int target)
+static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int target,
+	int cluster)
 {
 	struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
 	int i, cpu, idle_cpu = -1, nr = INT_MAX;
@@ -6154,7 +6156,8 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
 
 	cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
 
-	if (sched_feat(SIS_PROP) && !smt) {
+	/* cluster is usually quite small like 4, no need SIS_PROP */
+	if (sched_feat(SIS_PROP) && !smt && !cluster) {
 		u64 avg_cost, avg_idle, span_avg;
 
 		/*
@@ -6191,7 +6194,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
 	if (smt)
 		set_idle_cores(this, false);
 
-	if (sched_feat(SIS_PROP) && !smt) {
+	if (sched_feat(SIS_PROP) && !smt && !cluster) {
 		time = cpu_clock(this) - time;
 		update_avg(&this_sd->avg_scan_cost, time);
 	}
@@ -6244,7 +6247,7 @@ static inline bool asym_fits_capacity(int task_util, int cpu)
 /*
  * Try and locate an idle core/thread in the LLC cache domain.
  */
-static int select_idle_sibling(struct task_struct *p, int prev, int target)
+static int select_idle_sibling(struct task_struct *p, int prev, int target, int cluster)
 {
 	struct sched_domain *sd;
 	unsigned long task_util;
@@ -6266,7 +6269,7 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
 	/*
 	 * If the previous CPU is cache affine and idle, don't be stupid:
 	 */
-	if (prev != target && cpus_share_cache(prev, target) &&
+	if (prev != target && cpus_share_cache(prev, target, cluster) &&
 	    (available_idle_cpu(prev) || sched_idle_cpu(prev)) &&
 	    asym_fits_capacity(task_util, prev))
 		return prev;
@@ -6289,7 +6292,7 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
 	recent_used_cpu = p->recent_used_cpu;
 	if (recent_used_cpu != prev &&
 	    recent_used_cpu != target &&
-	    cpus_share_cache(recent_used_cpu, target) &&
+	    cpus_share_cache(recent_used_cpu, target, cluster) &&
 	    (available_idle_cpu(recent_used_cpu) || sched_idle_cpu(recent_used_cpu)) &&
 	    cpumask_test_cpu(p->recent_used_cpu, p->cpus_ptr) &&
 	    asym_fits_capacity(task_util, recent_used_cpu)) {
@@ -6321,11 +6324,11 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
 		}
 	}
 
-	sd = rcu_dereference(per_cpu(sd_llc, target));
+	sd = cluster ? rcu_dereference(per_cpu(sd_cluster, target)) :
+			rcu_dereference(per_cpu(sd_llc, target));
 	if (!sd)
 		return target;
-
-	i = select_idle_cpu(p, sd, target);
+	i = select_idle_cpu(p, sd, target, cluster);
 	if ((unsigned)i < nr_cpumask_bits)
 		return i;
 
@@ -6745,6 +6748,12 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 	int want_affine = 0;
 	/* SD_flags and WF_flags share the first nibble */
 	int sd_flag = wake_flags & 0xF;
+	/*
+	 * if cpu and prev_cpu share LLC, consider cluster sibling rather
+	 * than llc. this is typically true while tasks are bound within
+	 * one numa
+	 */
+	int cluster = sched_cluster_active() && cpus_share_cache(cpu, prev_cpu, 0);
 
 	if (wake_flags & WF_TTWU) {
 		record_wakee(p);
@@ -6756,7 +6765,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 			new_cpu = prev_cpu;
 		}
 
-		want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
+		want_affine = !wake_wide(p, cluster) && cpumask_test_cpu(cpu, p->cpus_ptr);
 	}
 
 	rcu_read_lock();
@@ -6768,7 +6777,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 		if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
 		    cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
 			if (cpu != prev_cpu)
-				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
+				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync, cluster);
 
 			sd = NULL; /* Prefer wake_affine over balance flags */
 			break;
@@ -6785,7 +6794,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 		new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
 	} else if (wake_flags & WF_TTWU) { /* XXX always ? */
 		/* Fast path */
-		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
+		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu, cluster);
 
 		if (want_affine)
 			current->recent_used_cpu = cpu;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4e938ba..b4b7d95 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1487,6 +1487,9 @@ static inline struct sched_domain *lowest_flag_domain(int cpu, int flag)
 DECLARE_PER_CPU(struct sched_domain __rcu *, sd_llc);
 DECLARE_PER_CPU(int, sd_llc_size);
 DECLARE_PER_CPU(int, sd_llc_id);
+DECLARE_PER_CPU(struct sched_domain __rcu *, sd_cluster);
+DECLARE_PER_CPU(int, sd_cluster_size);
+DECLARE_PER_CPU(int, sd_cluster_id);
 DECLARE_PER_CPU(struct sched_domain_shared __rcu *, sd_llc_shared);
 DECLARE_PER_CPU(struct sched_domain __rcu *, sd_numa);
 DECLARE_PER_CPU(struct sched_domain __rcu *, sd_asym_packing);
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 829ac9d..28a2032 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -644,6 +644,9 @@ static void destroy_sched_domains(struct sched_domain *sd)
 DEFINE_PER_CPU(struct sched_domain __rcu *, sd_llc);
 DEFINE_PER_CPU(int, sd_llc_size);
 DEFINE_PER_CPU(int, sd_llc_id);
+DEFINE_PER_CPU(struct sched_domain __rcu *, sd_cluster);
+DEFINE_PER_CPU(int, sd_cluster_size);
+DEFINE_PER_CPU(int, sd_cluster_id);
 DEFINE_PER_CPU(struct sched_domain_shared __rcu *, sd_llc_shared);
 DEFINE_PER_CPU(struct sched_domain __rcu *, sd_numa);
 DEFINE_PER_CPU(struct sched_domain __rcu *, sd_asym_packing);
@@ -657,6 +660,15 @@ static void update_top_cache_domain(int cpu)
 	int id = cpu;
 	int size = 1;
 
+	sd = highest_flag_domain(cpu, SD_SHARE_CLS_RESOURCES);
+	if (sd) {
+		id = cpumask_first(sched_domain_span(sd));
+		size = cpumask_weight(sched_domain_span(sd));
+	}
+	rcu_assign_pointer(per_cpu(sd_cluster, cpu), sd);
+	per_cpu(sd_cluster_size, cpu) = size;
+	per_cpu(sd_cluster_id, cpu) = id;
+
 	sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
 	if (sd) {
 		id = cpumask_first(sched_domain_span(sd));
-- 
1.8.3.1



From song.bao.hua at hisilicon.com  Tue Apr 20 01:18:44 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 20 Apr 2021 12:18:44 +1200
Subject: [RFC PATCH v6 4/4] scheduler: Add cluster scheduler level for x86
In-Reply-To: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
Message-ID: <20210420001844.9116-5-song.bao.hua@hisilicon.com>

From: Tim Chen <tim.c.chen at linux.intel.com>

There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
is shared among a cluster of cores instead of being exclusive
to one single core.

To prevent oversubscription of L2 cache, load should be
balanced between such L2 clusters, especially for tasks with
no shared data.

Also with cluster scheduling policy where tasks are woken up
in the same L2 cluster, we will benefit from keeping tasks
related to each other and likely sharing data in the same L2
cluster.

Add CPU masks of CPUs sharing the L2 cache so we can build such
L2 cluster scheduler domain.

Signed-off-by: Tim Chen <tim.c.chen at linux.intel.com>
Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 -v6:
  * added topology_cluster_cpumask() for x86, code provided by Tim.

 arch/x86/Kconfig                |  8 ++++++++
 arch/x86/include/asm/smp.h      |  7 +++++++
 arch/x86/include/asm/topology.h |  2 ++
 arch/x86/kernel/cpu/cacheinfo.c |  1 +
 arch/x86/kernel/cpu/common.c    |  3 +++
 arch/x86/kernel/smpboot.c       | 43 ++++++++++++++++++++++++++++++++++++++++-
 6 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879..d597de2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1002,6 +1002,14 @@ config NR_CPUS
 	  This is purely to save memory: each supported CPU adds about 8KB
 	  to the kernel image.
 
+config SCHED_CLUSTER
+	bool "Cluster scheduler support"
+	default n
+	help
+	 Cluster scheduler support improves the CPU scheduler's decision
+	 making when dealing with machines that have clusters of CPUs
+	 sharing L2 cache. If unsure say N here.
+
 config SCHED_SMT
 	def_bool y if SMP
 
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index c0538f8..9cbc4ae 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -16,7 +16,9 @@
 DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map);
 /* cpus sharing the last level cache: */
 DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
+DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map);
 DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id);
+DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id);
 DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
 
 static inline struct cpumask *cpu_llc_shared_mask(int cpu)
@@ -24,6 +26,11 @@ static inline struct cpumask *cpu_llc_shared_mask(int cpu)
 	return per_cpu(cpu_llc_shared_map, cpu);
 }
 
+static inline struct cpumask *cpu_l2c_shared_mask(int cpu)
+{
+	return per_cpu(cpu_l2c_shared_map, cpu);
+}
+
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid);
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid);
 DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid);
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 9239399..800fa48 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -103,6 +103,7 @@ static inline void setup_node_to_cpumask_map(void) { }
 #include <asm-generic/topology.h>
 
 extern const struct cpumask *cpu_coregroup_mask(int cpu);
+extern const struct cpumask *cpu_clustergroup_mask(int cpu);
 
 #define topology_logical_package_id(cpu)	(cpu_data(cpu).logical_proc_id)
 #define topology_physical_package_id(cpu)	(cpu_data(cpu).phys_proc_id)
@@ -114,6 +115,7 @@ static inline void setup_node_to_cpumask_map(void) { }
 
 #ifdef CONFIG_SMP
 #define topology_die_cpumask(cpu)		(per_cpu(cpu_die_map, cpu))
+#define topology_cluster_cpumask(cpu)		(cpu_clustergroup_mask(cpu))
 #define topology_core_cpumask(cpu)		(per_cpu(cpu_core_map, cpu))
 #define topology_sibling_cpumask(cpu)		(per_cpu(cpu_sibling_map, cpu))
 
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 3ca9be4..0d03a71 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -846,6 +846,7 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 		l2 = new_l2;
 #ifdef CONFIG_SMP
 		per_cpu(cpu_llc_id, cpu) = l2_id;
+		per_cpu(cpu_l2c_id, cpu) = l2_id;
 #endif
 	}
 
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index ab640ab..0ba282d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -78,6 +78,9 @@
 /* Last level cache ID of each logical CPU */
 DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id) = BAD_APICID;
 
+/* L2 cache ID of each logical CPU */
+DEFINE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id) = BAD_APICID;
+
 /* correctly size the local cpu masks */
 void __init setup_cpu_local_masks(void)
 {
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 02813a7..c85ffa8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -101,6 +101,8 @@
 
 DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map);
 
+DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_l2c_shared_map);
+
 /* Per CPU bogomips and other parameters */
 DEFINE_PER_CPU_READ_MOSTLY(struct cpuinfo_x86, cpu_info);
 EXPORT_PER_CPU_SYMBOL(cpu_info);
@@ -501,6 +503,21 @@ static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
 	return topology_sane(c, o, "llc");
 }
 
+static bool match_l2c(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
+{
+	int cpu1 = c->cpu_index, cpu2 = o->cpu_index;
+
+	/* Do not match if we do not have a valid APICID for cpu: */
+	if (per_cpu(cpu_l2c_id, cpu1) == BAD_APICID)
+		return false;
+
+	/* Do not match if L2 cache id does not match: */
+	if (per_cpu(cpu_l2c_id, cpu1) != per_cpu(cpu_l2c_id, cpu2))
+		return false;
+
+	return topology_sane(c, o, "l2c");
+}
+
 /*
  * Unlike the other levels, we do not enforce keeping a
  * multicore group inside a NUMA node.  If this happens, we will
@@ -522,7 +539,7 @@ static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
 }
 
 
-#if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_MC)
+#if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_CLUSTER) || defined(CONFIG_SCHED_MC)
 static inline int x86_sched_itmt_flags(void)
 {
 	return sysctl_sched_itmt_enabled ? SD_ASYM_PACKING : 0;
@@ -540,12 +557,21 @@ static int x86_smt_flags(void)
 	return cpu_smt_flags() | x86_sched_itmt_flags();
 }
 #endif
+#ifdef CONFIG_SCHED_CLUSTER
+static int x86_cluster_flags(void)
+{
+	return cpu_cluster_flags() | x86_sched_itmt_flags();
+}
+#endif
 #endif
 
 static struct sched_domain_topology_level x86_numa_in_package_topology[] = {
 #ifdef CONFIG_SCHED_SMT
 	{ cpu_smt_mask, x86_smt_flags, SD_INIT_NAME(SMT) },
 #endif
+#ifdef CONFIG_SCHED_CLUSTER
+	{ cpu_clustergroup_mask, x86_cluster_flags, SD_INIT_NAME(CLS) },
+#endif
 #ifdef CONFIG_SCHED_MC
 	{ cpu_coregroup_mask, x86_core_flags, SD_INIT_NAME(MC) },
 #endif
@@ -556,6 +582,9 @@ static int x86_smt_flags(void)
 #ifdef CONFIG_SCHED_SMT
 	{ cpu_smt_mask, x86_smt_flags, SD_INIT_NAME(SMT) },
 #endif
+#ifdef CONFIG_SCHED_CLUSTER
+	{ cpu_clustergroup_mask, x86_cluster_flags, SD_INIT_NAME(CLS) },
+#endif
 #ifdef CONFIG_SCHED_MC
 	{ cpu_coregroup_mask, x86_core_flags, SD_INIT_NAME(MC) },
 #endif
@@ -583,6 +612,7 @@ void set_cpu_sibling_map(int cpu)
 	if (!has_mp) {
 		cpumask_set_cpu(cpu, topology_sibling_cpumask(cpu));
 		cpumask_set_cpu(cpu, cpu_llc_shared_mask(cpu));
+		cpumask_set_cpu(cpu, cpu_l2c_shared_mask(cpu));
 		cpumask_set_cpu(cpu, topology_core_cpumask(cpu));
 		cpumask_set_cpu(cpu, topology_die_cpumask(cpu));
 		c->booted_cores = 1;
@@ -598,6 +628,8 @@ void set_cpu_sibling_map(int cpu)
 		if ((i == cpu) || (has_mp && match_llc(c, o)))
 			link_mask(cpu_llc_shared_mask, cpu, i);
 
+		if ((i == cpu) || (has_mp && match_l2c(c, o)))
+			link_mask(cpu_l2c_shared_mask, cpu, i);
 	}
 
 	/*
@@ -649,6 +681,11 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
 	return cpu_llc_shared_mask(cpu);
 }
 
+const struct cpumask *cpu_clustergroup_mask(int cpu)
+{
+	return cpu_l2c_shared_mask(cpu);
+}
+
 static void impress_friends(void)
 {
 	int cpu;
@@ -1332,6 +1369,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
 		zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL);
 		zalloc_cpumask_var(&per_cpu(cpu_die_map, i), GFP_KERNEL);
 		zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL);
+		zalloc_cpumask_var(&per_cpu(cpu_l2c_shared_map, i), GFP_KERNEL);
 	}
 
 	/*
@@ -1556,7 +1594,10 @@ static void remove_siblinginfo(int cpu)
 		cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
 	for_each_cpu(sibling, cpu_llc_shared_mask(cpu))
 		cpumask_clear_cpu(cpu, cpu_llc_shared_mask(sibling));
+	for_each_cpu(sibling, cpu_l2c_shared_mask(cpu))
+		cpumask_clear_cpu(cpu, cpu_l2c_shared_mask(sibling));
 	cpumask_clear(cpu_llc_shared_mask(cpu));
+	cpumask_clear(cpu_l2c_shared_mask(cpu));
 	cpumask_clear(topology_sibling_cpumask(cpu));
 	cpumask_clear(topology_core_cpumask(cpu));
 	cpumask_clear(topology_die_cpumask(cpu));
-- 
1.8.3.1



From andrew at lunn.ch  Tue Apr 20 02:22:13 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 20 Apr 2021 03:22:13 +0200
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom
 GMAC label
In-Reply-To: <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
Message-ID: <YH4sxUQBgzMqLYwk@lunn.ch>

On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
> 
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
> 
> Suggested-by: Ren? van Dorst <opensource at vdorst.com>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From zhukeqian1 at huawei.com  Tue Apr 20 02:25:53 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 20 Apr 2021 09:25:53 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
 <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
 <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>
Message-ID: <ac966fbc-7bc6-9d88-e53e-bcd92d536fdb@huawei.com>

Hi Baolu,

On 2021/4/19 21:33, Lu Baolu wrote:
> Hi Keqian,
> 
> On 2021/4/19 17:32, Keqian Zhu wrote:
>>>> +EXPORT_SYMBOL_GPL(iommu_split_block);
>>> Do you really have any consumers of this interface other than the dirty
>>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
>>> interface.
>>>
>>> There is an implicit requirement for such interfaces. The
>>> iommu_map/unmap(iova, size) shouldn't be called at the same time.
>>> Currently there's no such sanity check in the iommu core. A poorly
>>> written driver could mess up the kernel by misusing this interface.
>> Yes, I don't think up a scenario except dirty tracking.
>>
>> Indeed, we'd better not make them as a generic interface.
>>
>> Do you have any suggestion that underlying iommu drivers can share these code but
>> not make it as a generic iommu interface?
>>
>> I have a not so good idea. Make the "split" interfaces as a static function, and
>> transfer the function pointer to start_dirty_log. But it looks weird and inflexible.
> 
> I understand splitting/merging super pages is an optimization, but not a
> functional requirement. So is it possible to let the vendor iommu driver
> decide whether splitting super pages when starting dirty bit tracking
> and the opposite operation during when stopping it? The requirement for
Right. If I understand you correct, actually that is what this series does.
We realized split/merge in IOMMU core layer, but don't force vendor driver to use it.

The problem is that when we expose these interfaces to vendor IOMMU driver, will also
expose them to upper driver.

> upper layer is that starting/stopping dirty bit tracking and
> mapping/unmapping are mutually exclusive.
OK, I will explicitly add the hints. Thanks.

Thanks,
Keqian
> 
>>
>> On the other hand, if a driver calls map/unmap with split/merge at the same time,
>> it's a bug of driver, it should follow the rule.
>>
> 
> Best regards,
> baolu
> .
> 


From jianjun.wang at mediatek.com  Tue Apr 20 03:05:38 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 10:05:38 +0800
Subject: [v9,0/7] PCI: mediatek: Add new generation controller support
In-Reply-To: <20210419104432.GA2427@lpieralisi>
References: <20210324030510.29177-1-jianjun.wang@mediatek.com>
 <20210416192100.GA2745484@bjorn-Precision-5520>
 <20210419104432.GA2427@lpieralisi>
Message-ID: <1618884338.29460.3.camel@mhfsdcap03>

On Mon, 2021-04-19 at 11:44 +0100, Lorenzo Pieralisi wrote:
> On Fri, Apr 16, 2021 at 02:21:00PM -0500, Bjorn Helgaas wrote:
> > On Wed, Mar 24, 2021 at 11:05:03AM +0800, Jianjun Wang wrote:
> > > These series patches add pcie-mediatek-gen3.c and dt-bindings file to
> > > support new generation PCIe controller.
> > 
> > Incidental: b4 doesn't work on this thread, I suspect because the
> > usual subject line format is:
> > 
> >   [PATCH v9 9/7]
> > 
> > instead of:
> > 
> >   [v9,0/7]
> > 
> > For b4 info, see https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst
> 
> Jianjun will update the series accordingly (and please add to v10 the
> review tags you received.
> 
> Lorenzo

Yes, I will update this series in v10 to fix the subject line format and
use EXPORT_SYMBOL_GPL(), thanks for your comments.

Thanks.


From baolu.lu at linux.intel.com  Tue Apr 20 03:09:08 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Tue, 20 Apr 2021 10:09:08 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <ac966fbc-7bc6-9d88-e53e-bcd92d536fdb@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
 <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
 <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>
 <ac966fbc-7bc6-9d88-e53e-bcd92d536fdb@huawei.com>
Message-ID: <3c34baf1-6a57-5666-38a2-0c9d6188b8b8@linux.intel.com>

Hi Keqian,

On 4/20/21 9:25 AM, Keqian Zhu wrote:
> Hi Baolu,
> 
> On 2021/4/19 21:33, Lu Baolu wrote:
>> Hi Keqian,
>>
>> On 2021/4/19 17:32, Keqian Zhu wrote:
>>>>> +EXPORT_SYMBOL_GPL(iommu_split_block);
>>>> Do you really have any consumers of this interface other than the dirty
>>>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
>>>> interface.
>>>>
>>>> There is an implicit requirement for such interfaces. The
>>>> iommu_map/unmap(iova, size) shouldn't be called at the same time.
>>>> Currently there's no such sanity check in the iommu core. A poorly
>>>> written driver could mess up the kernel by misusing this interface.
>>> Yes, I don't think up a scenario except dirty tracking.
>>>
>>> Indeed, we'd better not make them as a generic interface.
>>>
>>> Do you have any suggestion that underlying iommu drivers can share these code but
>>> not make it as a generic iommu interface?
>>>
>>> I have a not so good idea. Make the "split" interfaces as a static function, and
>>> transfer the function pointer to start_dirty_log. But it looks weird and inflexible.
>>
>> I understand splitting/merging super pages is an optimization, but not a
>> functional requirement. So is it possible to let the vendor iommu driver
>> decide whether splitting super pages when starting dirty bit tracking
>> and the opposite operation during when stopping it? The requirement for
> Right. If I understand you correct, actually that is what this series does.

I mean to say no generic APIs, jut do it by the iommu subsystem itself.
It's totally transparent to the upper level, just like what map() does.
The upper layer doesn't care about either super page or small page is
in use when do a mapping, right?

If you want to consolidate some code, how about putting them in
start/stop_tracking()?

Best regards,
baolu

> We realized split/merge in IOMMU core layer, but don't force vendor driver to use it.
> 
> The problem is that when we expose these interfaces to vendor IOMMU driver, will also
> expose them to upper driver.
> 
>> upper layer is that starting/stopping dirty bit tracking and
>> mapping/unmapping are mutually exclusive.
> OK, I will explicitly add the hints. Thanks.
> 
> Thanks,
> Keqian
>>
>>>
>>> On the other hand, if a driver calls map/unmap with split/merge at the same time,
>>> it's a bug of driver, it should follow the rule.
>>>
>>
>> Best regards,
>> baolu
>> .
>>


From ilya.lipnitskiy at gmail.com  Tue Apr 20 03:42:22 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 19:42:22 -0700
Subject: [PATCH] dt-bindings: net: mediatek/ralink: remove unused bindings
Message-ID: <20210420024222.101615-1-ilya.lipnitskiy@gmail.com>

Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
ralink/mediatek SoC ethernet binding")

No in-tree drivers use the compatible strings present in these bindings,
and some have been superseded by DSA-capable mtk_eth_soc driver, so
remove these obsolete bindings.

Cc: John Crispin <john at phrozen.org>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 .../bindings/net/mediatek,mt7620-gsw.txt      | 24 --------
 .../bindings/net/ralink,rt2880-net.txt        | 59 -------------------
 .../bindings/net/ralink,rt3050-esw.txt        | 30 ----------
 3 files changed, 113 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
 delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
 delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt

diff --git a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt b/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
deleted file mode 100644
index 358fed2fab43..000000000000
--- a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek Gigabit Switch
-=======================
-
-The mediatek gigabit switch can be found on Mediatek SoCs (mt7620, mt7621).
-
-Required properties:
-- compatible: Should be "mediatek,mt7620-gsw" or "mediatek,mt7621-gsw"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the gigabit switches interrupt
-- resets: Should contain the gigabit switches resets
-- reset-names: Should contain the reset names "gsw"
-
-Example:
-
-gsw at 10110000 {
-	compatible = "ralink,mt7620-gsw";
-	reg = <0x10110000 8000>;
-
-	resets = <&rstctrl 23>;
-	reset-names = "gsw";
-
-	interrupt-parent = <&intc>;
-	interrupts = <17>;
-};
diff --git a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt b/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
deleted file mode 100644
index 9fe1a0a22e44..000000000000
--- a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Ralink Frame Engine Ethernet controller
-=======================================
-
-The Ralink frame engine ethernet controller can be found on Ralink and
-Mediatek SoCs (RT288x, RT3x5x, RT366x, RT388x, rt5350, mt7620, mt7621, mt76x8).
-
-Depending on the SoC, there is a number of ports connected to the CPU port
-directly and/or via a (gigabit-)switch.
-
-* Ethernet controller node
-
-Required properties:
-- compatible: Should be one of "ralink,rt2880-eth", "ralink,rt3050-eth",
-  "ralink,rt3050-eth", "ralink,rt3883-eth", "ralink,rt5350-eth",
-  "mediatek,mt7620-eth", "mediatek,mt7621-eth"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the frame engines interrupt
-- resets: Should contain the frame engines resets
-- reset-names: Should contain the reset names "fe". If a switch is present
-  "esw" is also required.
-
-
-* Ethernet port node
-
-Required properties:
-- compatible: Should be "ralink,eth-port"
-- reg: The number of the physical port
-- phy-handle: reference to the node describing the phy
-
-Example:
-
-mdio-bus {
-	...
-	phy0: ethernet-phy at 0 {
-		phy-mode = "mii";
-		reg = <0>;
-	};
-};
-
-ethernet at 400000 {
-	compatible = "ralink,rt2880-eth";
-	reg = <0x00400000 10000>;
-
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	resets = <&rstctrl 18>;
-	reset-names = "fe";
-
-	interrupt-parent = <&cpuintc>;
-	interrupts = <5>;
-
-	port at 0 {
-		compatible = "ralink,eth-port";
-		reg = <0>;
-		phy-handle = <&phy0>;
-	};
-
-};
diff --git a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt b/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
deleted file mode 100644
index 87e315856efa..000000000000
--- a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Ralink Fast Ethernet Embedded Switch
-====================================
-
-The ralink fast ethernet embedded switch can be found on Ralink and Mediatek
-SoCs (RT3x5x, RT5350, MT76x8).
-
-Required properties:
-- compatible: Should be "ralink,rt3050-esw"
-- reg: Address and length of the register set for the device
-- interrupts: Should contain the embedded switches interrupt
-- resets: Should contain the embedded switches resets
-- reset-names: Should contain the reset names "esw"
-
-Optional properties:
-- ralink,portmap: can be used to choose if the default switch setup is
-  llllw or wllll
-- ralink,led_polarity: override the active high/low settings of the leds
-
-Example:
-
-esw at 10110000 {
-	compatible = "ralink,rt3050-esw";
-	reg = <0x10110000 8000>;
-
-	resets = <&rstctrl 23>;
-	reset-names = "esw";
-
-	interrupt-parent = <&intc>;
-	interrupts = <17>;
-};
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Tue Apr 20 03:44:55 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Mon, 19 Apr 2021 19:44:55 -0700
Subject: [PATCH] dt-bindings: net: mediatek: support MT7621 SoC
In-Reply-To: <878s5e94hi.fsf@miraculix.mork.no>
References: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>
 <878s5e94hi.fsf@miraculix.mork.no>
Message-ID: <CALCv0x2CzL3PLw+r2f5rU_Uu04wn3kR3R-fn=kAfmksuAsjwLw@mail.gmail.com>

On Sun, Apr 18, 2021 at 11:24 PM Bj?rn Mork <bjorn at mork.no> wrote:
>
> Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com> writes:
>
> > Add missing binding documentation for SoC support that has been in place
> > since v5.1
> >
> > Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware")
> > Cc: Bj?rn Mork <bjorn at mork.no>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > ---
> >  Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > index 72d03e07cf7c..950ef6af20b1 100644
> > --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> > +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> > @@ -10,6 +10,7 @@ Required properties:
> >  - compatible: Should be
> >               "mediatek,mt2701-eth": for MT2701 SoC
> >               "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
> > +             "mediatek,mt7621-eth": for MT7621 SoC
> >               "mediatek,mt7622-eth": for MT7622 SoC
> >               "mediatek,mt7629-eth": for MT7629 SoC
> >               "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
>
>
> Thanks for taking care of this!
>
> Note, however, that this compatible value is defined in
> Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
>
> I believe that file should go away. These two files are both documenting
> the same compatible property AFAICS.
Removed along with two others in
https://lore.kernel.org/lkml/20210420024222.101615-1-ilya.lipnitskiy at gmail.com/T/#u

Ilya


From Vineet.Gupta1 at synopsys.com  Tue Apr 20 03:48:17 2021
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 20 Apr 2021 02:48:17 +0000
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417024522.GP2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
Message-ID: <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>

Hi Matthew,

On 4/16/21 7:45 PM, Matthew Wilcox wrote:
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: brouer at redhat.com
> Cc: linux-kernel at vger.kernel.org,
>      linux-mm at kvack.org,
>      netdev at vger.kernel.org,
>      linuxppc-dev at lists.ozlabs.org,
>      linux-arm-kernel at lists.infradead.org,
>      linux-mips at vger.kernel.org,
>      ilias.apalodimas at linaro.org,
>      mcroce at linux.microsoft.com,
>      grygorii.strashko at ti.com,
>      arnd at kernel.org,
>      hch at lst.de,
>      linux-snps-arc at lists.infradead.org,
>      mhocko at kernel.org,
>      mgorman at suse.de
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.

FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is 
only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND 
instructions.

> When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
>
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
>
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>   include/linux/mm_types.h |  4 ++--
>   include/net/page_pool.h  | 12 +++++++++++-
>   net/core/page_pool.c     | 12 +++++++-----
>   3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>   		};
>   		struct {	/* page_pool used by netstack */
>   			/**
> -			 * @dma_addr: might require a 64-bit value even on
> +			 * @dma_addr: might require a 64-bit value on
>   			 * 32-bit architectures.
>   			 */
> -			dma_addr_t dma_addr;
> +			unsigned long dma_addr[2];
>   		};
>   		struct {	/* slab, slob and slub */
>   			union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>   
>   static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>   {
> -	return page->dma_addr;
> +	dma_addr_t ret = page->dma_addr[0];
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> +	return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +	page->dma_addr[0] = addr;
> +	if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +		page->dma_addr[1] = addr >> 16 >> 16;
>   }
>   
>   static inline bool is_page_pool_compiled_in(void)
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index ad8b0707af04..f014fd8c19a6 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -174,8 +174,10 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool,
>   					  struct page *page,
>   					  unsigned int dma_sync_size)
>   {
> +	dma_addr_t dma_addr = page_pool_get_dma_addr(page);
> +
>   	dma_sync_size = min(dma_sync_size, pool->p.max_len);
> -	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
> +	dma_sync_single_range_for_device(pool->p.dev, dma_addr,
>   					 pool->p.offset, dma_sync_size,
>   					 pool->p.dma_dir);
>   }
> @@ -226,7 +228,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
>   		put_page(page);
>   		return NULL;
>   	}
> -	page->dma_addr = dma;
> +	page_pool_set_dma_addr(page, dma);
>   
>   	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
>   		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
> @@ -294,13 +296,13 @@ void page_pool_release_page(struct page_pool *pool, struct page *page)
>   		 */
>   		goto skip_dma_unmap;
>   
> -	dma = page->dma_addr;
> +	dma = page_pool_get_dma_addr(page);
>   
> -	/* When page is unmapped, it cannot be returned our pool */
> +	/* When page is unmapped, it cannot be returned to our pool */
>   	dma_unmap_page_attrs(pool->p.dev, dma,
>   			     PAGE_SIZE << pool->p.order, pool->p.dma_dir,
>   			     DMA_ATTR_SKIP_CPU_SYNC);
> -	page->dma_addr = 0;
> +	page_pool_set_dma_addr(page, 0);
>   skip_dma_unmap:
>   	/* This may be the last page returned, releasing the pool, so
>   	 * it is not safe to reference pool afterwards.


From lkp at intel.com  Tue Apr 20 03:51:11 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 10:51:11 +0800
Subject: [soc:drivers/memory-2] BUILD SUCCESS
 6ce2c05b21189eb17b3aa26720cc5841acf9dce8
Message-ID: <607e419f.xjYyFNSTz+VmpizJ%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git drivers/memory-2
branch HEAD: 6ce2c05b21189eb17b3aa26720cc5841acf9dce8  memory: mtk-smi: Add device-link between smi-larb and smi-common

elapsed time: 9340m

configs tested: 503
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm                              allyesconfig
arm                              allmodconfig
arm64                               defconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
mips                           ip28_defconfig
powerpc                     asp8347_defconfig
ia64                        generic_defconfig
arc                     nsimosci_hs_defconfig
arm                           corgi_defconfig
arm                       versatile_defconfig
m68k                          sun3x_defconfig
mips                    maltaup_xpa_defconfig
powerpc                     mpc83xx_defconfig
ia64                         bigsur_defconfig
arc                        vdk_hs38_defconfig
sparc                            alldefconfig
mips                         tb0219_defconfig
arm                             mxs_defconfig
parisc                generic-64bit_defconfig
arm                        mvebu_v5_defconfig
arm                         vf610m4_defconfig
powerpc                 mpc837x_mds_defconfig
mips                     loongson1c_defconfig
m68k                       m5275evb_defconfig
powerpc                 mpc837x_rdb_defconfig
powerpc                       ebony_defconfig
powerpc                     ksi8560_defconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
sh                          rsk7269_defconfig
sh                             sh03_defconfig
ia64                                defconfig
arc                          axs101_defconfig
mips                  cavium_octeon_defconfig
mips                        jmr3927_defconfig
xtensa                           alldefconfig
xtensa                  cadence_csp_defconfig
powerpc                       maple_defconfig
arm                          ep93xx_defconfig
mips                            e55_defconfig
ia64                      gensparse_defconfig
arm                    vt8500_v6_v7_defconfig
arm                        clps711x_defconfig
arm                         at91_dt_defconfig
arc                      axs103_smp_defconfig
mips                      maltaaprp_defconfig
arm                          imote2_defconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
arm                          pxa3xx_defconfig
openrisc                         alldefconfig
powerpc64                           defconfig
sh                        apsh4ad0a_defconfig
mips                         rt305x_defconfig
sh                                  defconfig
powerpc                     sbc8548_defconfig
arm                          lpd270_defconfig
arm                        oxnas_v6_defconfig
powerpc                      pcm030_defconfig
powerpc                      pasemi_defconfig
m68k                          amiga_defconfig
ia64                          tiger_defconfig
mips                  decstation_64_defconfig
powerpc                        icon_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
h8300                       h8s-sim_defconfig
sh                           se7206_defconfig
s390                             allmodconfig
riscv             nommu_k210_sdcard_defconfig
sh                           se7343_defconfig
mips                           gcw0_defconfig
sh                           se7724_defconfig
powerpc                      obs600_defconfig
arm                            mmp2_defconfig
arc                        nsim_700_defconfig
arm                          iop32x_defconfig
alpha                            allyesconfig
mips                           ip32_defconfig
sh                     sh7710voipgw_defconfig
mips                       lemote2f_defconfig
riscv                    nommu_k210_defconfig
um                               allmodconfig
powerpc                     tqm5200_defconfig
csky                                defconfig
mips                          rb532_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
arm                       imx_v6_v7_defconfig
m68k                       bvme6000_defconfig
arm                        cerfcube_defconfig
arm                       multi_v4t_defconfig
sh                          urquell_defconfig
arm                       cns3420vb_defconfig
powerpc                          g5_defconfig
arm                         palmz72_defconfig
m68k                             alldefconfig
arc                         haps_hs_defconfig
powerpc                      ppc64e_defconfig
powerpc                 mpc834x_mds_defconfig
powerpc                      makalu_defconfig
sh                         apsh4a3a_defconfig
powerpc                     taishan_defconfig
s390                             alldefconfig
arm                          pxa168_defconfig
mips                       capcella_defconfig
sh                        edosk7705_defconfig
powerpc64                        alldefconfig
mips                        bcm47xx_defconfig
sh                        sh7757lcr_defconfig
powerpc                 mpc8315_rdb_defconfig
mips                         tb0287_defconfig
sh                           se7722_defconfig
powerpc                     ep8248e_defconfig
h8300                     edosk2674_defconfig
powerpc                    klondike_defconfig
mips                     cu1000-neo_defconfig
powerpc               mpc834x_itxgp_defconfig
mips                          rm200_defconfig
sh                          r7785rp_defconfig
powerpc                 canyonlands_defconfig
sh                        dreamcast_defconfig
powerpc                      chrp32_defconfig
mips                         bigsur_defconfig
h8300                    h8300h-sim_defconfig
arc                        nsimosci_defconfig
arm                          collie_defconfig
nds32                            alldefconfig
arm                         socfpga_defconfig
sparc64                             defconfig
powerpc                        warp_defconfig
mips                        nlm_xlr_defconfig
s390                          debug_defconfig
powerpc                     tqm8555_defconfig
sh                          landisk_defconfig
openrisc                  or1klitex_defconfig
powerpc                          allyesconfig
arm                      footbridge_defconfig
arc                          axs103_defconfig
arm64                            alldefconfig
powerpc                        fsp2_defconfig
powerpc                     ppa8548_defconfig
powerpc                      cm5200_defconfig
sh                   secureedge5410_defconfig
ia64                             allmodconfig
powerpc                    adder875_defconfig
mips                      pistachio_defconfig
powerpc                    socrates_defconfig
powerpc                   lite5200b_defconfig
powerpc                      bamboo_defconfig
arm                            xcep_defconfig
mips                        nlm_xlp_defconfig
powerpc                  iss476-smp_defconfig
powerpc                      ppc6xx_defconfig
sh                        sh7785lcr_defconfig
arm                         shannon_defconfig
arm                         lpc32xx_defconfig
m68k                           sun3_defconfig
powerpc                      ppc44x_defconfig
arm                           stm32_defconfig
sh                           sh2007_defconfig
sh                          rsk7201_defconfig
arm                         lpc18xx_defconfig
mips                           ip27_defconfig
powerpc                 mpc8272_ads_defconfig
arm                        magician_defconfig
xtensa                       common_defconfig
sh                     magicpanelr2_defconfig
mips                         db1xxx_defconfig
sh                            titan_defconfig
m68k                         amcore_defconfig
arm                       netwinder_defconfig
m68k                        mvme147_defconfig
ia64                            zx1_defconfig
arm                           spitz_defconfig
arm                           sunxi_defconfig
sh                          rsk7264_defconfig
arm                        spear6xx_defconfig
mips                      bmips_stb_defconfig
mips                          malta_defconfig
powerpc                         ps3_defconfig
arm                          pcm027_defconfig
sh                   rts7751r2dplus_defconfig
xtensa                    smp_lx200_defconfig
sh                           se7750_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
arm                            zeus_defconfig
mips                     cu1830-neo_defconfig
arm                          gemini_defconfig
m68k                             allmodconfig
microblaze                          defconfig
riscv                          rv32_defconfig
sh                            shmin_defconfig
powerpc                     tqm8548_defconfig
powerpc                 mpc832x_rdb_defconfig
arm                           sama5_defconfig
mips                            ar7_defconfig
powerpc                     tqm8560_defconfig
powerpc                      arches_defconfig
arm                        vexpress_defconfig
powerpc                       eiger_defconfig
sh                            hp6xx_defconfig
arm                        trizeps4_defconfig
csky                             alldefconfig
arm                       spear13xx_defconfig
riscv                            alldefconfig
arm                          exynos_defconfig
xtensa                          iss_defconfig
um                                allnoconfig
powerpc                      ep88xc_defconfig
sparc                       sparc64_defconfig
m68k                            mac_defconfig
s390                             allyesconfig
arm                           h3600_defconfig
xtensa                              defconfig
arm                      jornada720_defconfig
powerpc                     redwood_defconfig
mips                           ci20_defconfig
sh                          lboxre2_defconfig
nios2                            allyesconfig
sh                ecovec24-romimage_defconfig
arm                          simpad_defconfig
arm                       imx_v4_v5_defconfig
sh                          sdk7780_defconfig
arm                       aspeed_g5_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                     stx_gp3_defconfig
m68k                        m5307c3_defconfig
mips                     decstation_defconfig
mips                           jazz_defconfig
arc                              allyesconfig
sh                           se7751_defconfig
arm                            pleb_defconfig
arm                        mini2440_defconfig
mips                           ip22_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
arc                     haps_hs_smp_defconfig
mips                        maltaup_defconfig
arm                        realview_defconfig
arm                     am200epdkit_defconfig
sh                           se7619_defconfig
m68k                          multi_defconfig
m68k                        m5407c3_defconfig
powerpc                 mpc836x_mds_defconfig
arm                              alldefconfig
mips                   sb1250_swarm_defconfig
powerpc                     powernv_defconfig
sh                           se7780_defconfig
powerpc                    sam440ep_defconfig
sh                          rsk7203_defconfig
powerpc                   currituck_defconfig
arm                         s3c6400_defconfig
arm                            mps2_defconfig
arm                          moxart_defconfig
riscv                    nommu_virt_defconfig
arm                           tegra_defconfig
arm                     eseries_pxa_defconfig
sparc                            allyesconfig
xtensa                  nommu_kc705_defconfig
h8300                            allyesconfig
sh                        edosk7760_defconfig
h8300                            alldefconfig
powerpc                       holly_defconfig
arm                        multi_v7_defconfig
arm                         hackkit_defconfig
arm                         s5pv210_defconfig
mips                             allyesconfig
arm                  colibri_pxa300_defconfig
mips                       bmips_be_defconfig
riscv                             allnoconfig
arm                         lubbock_defconfig
powerpc                      ppc40x_defconfig
mips                        omega2p_defconfig
arm                          ixp4xx_defconfig
arm                       mainstone_defconfig
arm                        neponset_defconfig
arm                      integrator_defconfig
m68k                         apollo_defconfig
mips                      fuloong2e_defconfig
arm                           h5000_defconfig
powerpc                     rainier_defconfig
mips                         tb0226_defconfig
sh                  sh7785lcr_32bit_defconfig
mips                        bcm63xx_defconfig
arm                      tct_hammer_defconfig
mips                      malta_kvm_defconfig
openrisc                    or1ksim_defconfig
powerpc                  mpc885_ads_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                         cm_x300_defconfig
arm                          pxa910_defconfig
powerpc                    gamecube_defconfig
powerpc                 mpc85xx_cds_defconfig
h8300                               defconfig
powerpc                 mpc8540_ads_defconfig
mips                        qi_lb60_defconfig
arm                            dove_defconfig
m68k                            q40_defconfig
mips                malta_qemu_32r6_defconfig
arm                       aspeed_g4_defconfig
sh                         microdev_defconfig
powerpc                     sequoia_defconfig
arm                        spear3xx_defconfig
arm                         axm55xx_defconfig
m68k                       m5475evb_defconfig
powerpc                 mpc834x_itx_defconfig
arm                          badge4_defconfig
arm                         bcm2835_defconfig
arc                           tb10x_defconfig
alpha                               defconfig
powerpc                   bluestone_defconfig
i386                                defconfig
powerpc                        cell_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
m68k                          hp300_defconfig
mips                     loongson1b_defconfig
powerpc                      acadia_defconfig
arm                        mvebu_v7_defconfig
mips                         mpc30x_defconfig
xtensa                generic_kc705_defconfig
sparc                               defconfig
powerpc                       ppc64_defconfig
powerpc                     kilauea_defconfig
powerpc                    amigaone_defconfig
m68k                       m5249evb_defconfig
arm                  colibri_pxa270_defconfig
um                            kunit_defconfig
mips                         cobalt_defconfig
ia64                             alldefconfig
i386                             alldefconfig
arm                        shmobile_defconfig
openrisc                            defconfig
arm                         s3c2410_defconfig
nios2                         3c120_defconfig
mips                       rbtx49xx_defconfig
powerpc                     mpc512x_defconfig
arm                             rpc_defconfig
arm                             pxa_defconfig
ia64                             allyesconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nds32                               defconfig
xtensa                           allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
parisc                           allyesconfig
s390                                defconfig
mips                             allmodconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210413
x86_64               randconfig-a002-20210413
x86_64               randconfig-a001-20210413
x86_64               randconfig-a005-20210413
x86_64               randconfig-a006-20210413
x86_64               randconfig-a004-20210413
x86_64               randconfig-a003-20210415
x86_64               randconfig-a002-20210415
x86_64               randconfig-a005-20210415
x86_64               randconfig-a001-20210415
x86_64               randconfig-a006-20210415
x86_64               randconfig-a004-20210415
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210413
i386                 randconfig-a001-20210413
i386                 randconfig-a006-20210413
i386                 randconfig-a005-20210413
i386                 randconfig-a004-20210413
i386                 randconfig-a002-20210413
i386                 randconfig-a003-20210414
i386                 randconfig-a006-20210414
i386                 randconfig-a001-20210414
i386                 randconfig-a005-20210414
i386                 randconfig-a004-20210414
i386                 randconfig-a002-20210414
i386                 randconfig-a003-20210416
i386                 randconfig-a006-20210416
i386                 randconfig-a001-20210416
i386                 randconfig-a005-20210416
i386                 randconfig-a004-20210416
i386                 randconfig-a002-20210416
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a003-20210415
i386                 randconfig-a006-20210415
i386                 randconfig-a001-20210415
i386                 randconfig-a005-20210415
i386                 randconfig-a004-20210415
i386                 randconfig-a002-20210415
x86_64               randconfig-a014-20210416
x86_64               randconfig-a015-20210416
x86_64               randconfig-a011-20210416
x86_64               randconfig-a013-20210416
x86_64               randconfig-a012-20210416
x86_64               randconfig-a016-20210416
x86_64               randconfig-a014-20210414
x86_64               randconfig-a015-20210414
x86_64               randconfig-a011-20210414
x86_64               randconfig-a013-20210414
x86_64               randconfig-a012-20210414
x86_64               randconfig-a016-20210414
i386                 randconfig-a015-20210414
i386                 randconfig-a014-20210414
i386                 randconfig-a013-20210414
i386                 randconfig-a012-20210414
i386                 randconfig-a016-20210414
i386                 randconfig-a011-20210414
i386                 randconfig-a015-20210415
i386                 randconfig-a014-20210415
i386                 randconfig-a013-20210415
i386                 randconfig-a012-20210415
i386                 randconfig-a016-20210415
i386                 randconfig-a011-20210415
i386                 randconfig-a015-20210416
i386                 randconfig-a014-20210416
i386                 randconfig-a013-20210416
i386                 randconfig-a012-20210416
i386                 randconfig-a016-20210416
i386                 randconfig-a011-20210416
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
i386                 randconfig-a015-20210413
i386                 randconfig-a014-20210413
i386                 randconfig-a013-20210413
i386                 randconfig-a012-20210413
i386                 randconfig-a016-20210413
i386                 randconfig-a011-20210413
riscv                               defconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210414
x86_64               randconfig-a002-20210414
x86_64               randconfig-a005-20210414
x86_64               randconfig-a001-20210414
x86_64               randconfig-a006-20210414
x86_64               randconfig-a004-20210414
x86_64               randconfig-a003-20210416
x86_64               randconfig-a002-20210416
x86_64               randconfig-a005-20210416
x86_64               randconfig-a001-20210416
x86_64               randconfig-a006-20210416
x86_64               randconfig-a004-20210416
x86_64               randconfig-a014-20210413
x86_64               randconfig-a015-20210413
x86_64               randconfig-a011-20210413
x86_64               randconfig-a013-20210413
x86_64               randconfig-a012-20210413
x86_64               randconfig-a016-20210413
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419
x86_64               randconfig-a014-20210415
x86_64               randconfig-a015-20210415
x86_64               randconfig-a011-20210415
x86_64               randconfig-a013-20210415
x86_64               randconfig-a012-20210415
x86_64               randconfig-a016-20210415

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From willy at infradead.org  Tue Apr 20 04:10:29 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Tue, 20 Apr 2021 04:10:29 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
Message-ID: <20210420031029.GI2531743@casper.infradead.org>

On Tue, Apr 20, 2021 at 02:48:17AM +0000, Vineet Gupta wrote:
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.
> 
> FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is 
> only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND 
> instructions.

Ah, like x86?  OK, great, I'll drop your arch from the list of
affected.  Thanks!


From robh at kernel.org  Tue Apr 20 04:15:02 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:02 -0500
Subject: [PATCH v7 0/9] arm64 userspace counter access support
Message-ID: <20210420031511.2348977-1-robh@kernel.org>

Hi all,

Another version of arm64 userspace counter access support. I sent out
the libperf bits separately and those are now applied (Thanks!), so this
is just the arm64 bits.


This originally resurrected Raphael's series[1] to enable userspace counter
access on arm64. My previous versions are here[2][3][4][5][6][7]. A git
branch is here[8].


Changes in v7:
 - Handling of dirty counter leakage and reworking of context switch and
   user access enabling. The .sched_task hook and undef instruction handler
   are now utilized. (Patch 3)
 - Add a userspace disable switch like x86. (Patch 5)

Changes in v6:
 - Reworking of the handling of 64-bit counters and user access. There's
   a new config1 flag to request user access. This takes priority over
   the 64-bit flag and the user will get the maximum size the h/w
   supports without chaining.
 - The libperf evsel mmap struct is stored in its own xyarray
 - New tests for user 64-bit and 32-bit counters
 - Rebase to v5.12-rc2

Changes in v5:
 - Limit enabling/disabling access to CPUs associated with the PMU
   (supported_cpus) and with the mm_struct matching current->active_mm.
   The x86 method of using mm_cpumask doesn't work for arm64 as it is not
   updated.
 - Only set cap_user_rdpmc if event is on current cpu. See patch 2.
 - Create an mmap for every event in an evsel. This results in some changes
   to the libperf mmap API from the last version.
 - Rebase to v5.11-rc2

Changes in v4:
 - Dropped 'arm64: pmu: Add hook to handle pmu-related undefined instructions'.
   The onus is on userspace to pin itself to a homogeneous subset of CPUs
   and avoid any aborts on heterogeneous systems, so the hook is not needed.
 - Make perf_evsel__mmap() take pages rather than bytes for size
 - Fix building arm64 heterogeneous test.

Changes in v3:
 - Dropped removing x86 rdpmc test until libperf tests can run via 'perf test'
 - Added verbose prints for tests
 - Split adding perf_evsel__mmap() to separate patch

The following changes to the arm64 support have been made compared to
Raphael's last version:

The major change is support for heterogeneous systems with some
restrictions. Specifically, userspace must pin itself to like CPUs, open
a specific PMU by type, and use h/w specific events. The tests have been
reworked to demonstrate this.

Chained events are not supported. The problem with supporting chained
events was there's no way to distinguish between a chained event and a
native 64-bit counter. We could add some flag, but do self monitoring
processes really need that? Native 64-bit counters are supported if the
PMU h/w has support. As there's already an explicit ABI to request 64-bit
counters, userspace can request 64-bit counters and if user
access is not enabled, then it must retry with 32-bit counters.

Prior versions broke the build on arm32 (surprisingly never caught by
0-day). As a result, event_mapped and event_unmapped implementations have
been moved into the arm64 code.

There was a bug in that pmc_width was not set in the user page. The tests
now check for this.

The documentation has been converted to rST. I've added sections on
chained events and heterogeneous.

The tests have been expanded to test the cycle counter access.

Rob

[1] https://lore.kernel.org/r/20190822144220.27860-1-raphael.gault at arm.com/
[2] https://lore.kernel.org/r/20200707205333.624938-1-robh at kernel.org/
[3] https://lore.kernel.org/r/20200828205614.3391252-1-robh at kernel.org/
[4] https://lore.kernel.org/r/20200911215118.2887710-1-robh at kernel.org/
[5] https://lore.kernel.org/r/20201001140116.651970-1-robh at kernel.org/
[6] https://lore.kernel.org/r/20210114020605.3943992-1-robh at kernel.org/
[7] https://lore.kernel.org/r/20210311000837.3630499-1-robh at kernel.org/
[8] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git user-perf-event-v7

Raphael Gault (4):
  arm64: Restrict undef hook for cpufeature registers
  arm64: pmu: Add function implementation to update event index in
    userpage
  arm64: perf: Enable PMU counter direct access for perf event
  Documentation: arm64: Document PMU counters access from userspace

Rob Herring (5):
  drivers/perf: arm_pmu: Export the per_cpu cpu_armpmu
  arm64: perf: Add userspace counter access disable switch
  libperf: Add arm64 support to perf_mmap__read_self()
  perf: arm64: Add test for userspace counter access on heterogeneous
    systems
  perf: arm64: Add tests for 32-bit and 64-bit counter size userspace
    access

 Documentation/arm64/perf.rst               |  67 +++++-
 arch/arm64/include/asm/mmu.h               |   5 +
 arch/arm64/kernel/cpufeature.c             |   4 +-
 arch/arm64/kernel/perf_event.c             | 254 ++++++++++++++++++++-
 drivers/perf/arm_pmu.c                     |   2 +-
 include/linux/perf/arm_pmu.h               |  14 +-
 tools/lib/perf/mmap.c                      |  98 ++++++++
 tools/lib/perf/tests/test-evsel.c          |   2 +-
 tools/perf/arch/arm64/include/arch-tests.h |  12 +
 tools/perf/arch/arm64/tests/Build          |   1 +
 tools/perf/arch/arm64/tests/arch-tests.c   |  12 +
 tools/perf/arch/arm64/tests/user-events.c  | 215 +++++++++++++++++
 12 files changed, 672 insertions(+), 14 deletions(-)
 create mode 100644 tools/perf/arch/arm64/tests/user-events.c

--
2.27.0


From robh at kernel.org  Tue Apr 20 04:15:03 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:03 -0500
Subject: [PATCH v7 1/9] arm64: Restrict undef hook for cpufeature registers
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-2-robh@kernel.org>

From: Raphael Gault <raphael.gault at arm.com>

This commit modifies the mask of the mrs_hook declared in
arch/arm64/kernel/cpufeatures.c which emulates only feature register
access. This is necessary because this hook's mask was too large and
thus masking any mrs instruction, even if not related to the emulated
registers which made the pmu emulation inefficient.

Signed-off-by: Raphael Gault <raphael.gault at arm.com>
Signed-off-by: Rob Herring <robh at kernel.org>
---
v7:
 - Split off from Raphael's original undef hook patch as this change stands
   on its own.
---
 arch/arm64/kernel/cpufeature.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 066030717a4c..aa0777690ab1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2888,8 +2888,8 @@ static int emulate_mrs(struct pt_regs *regs, u32 insn)
 }

 static struct undef_hook mrs_hook = {
-	.instr_mask = 0xfff00000,
-	.instr_val  = 0xd5300000,
+	.instr_mask = 0xffff0000,
+	.instr_val  = 0xd5380000,
 	.pstate_mask = PSR_AA32_MODE_MASK,
 	.pstate_val = PSR_MODE_EL0t,
 	.fn = emulate_mrs,
--
2.27.0


From robh at kernel.org  Tue Apr 20 04:15:04 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:04 -0500
Subject: [PATCH v7 2/9] arm64: pmu: Add function implementation to update
 event index in userpage
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-3-robh@kernel.org>

From: Raphael Gault <raphael.gault at arm.com>

In order to be able to access the counter directly for userspace,
we need to provide the index of the counter using the userpage.
We thus need to override the event_idx function to retrieve and
convert the perf_event index to armv8 hardware index.

Since the arm_pmu driver can be used by any implementation, even
if not armv8, two components play a role into making sure the
behaviour is correct and consistent with the PMU capabilities:

* the ARMPMU_EL0_RD_CNTR flag which denotes the capability to access
counter from userspace.
* the event_idx call back, which is implemented and initialized by
the PMU implementation: if no callback is provided, the default
behaviour applies, returning 0 as index value.

Signed-off-by: Raphael Gault <raphael.gault at arm.com>
Signed-off-by: Rob Herring <robh at kernel.org>
---
v7:
 - Add define ARMV8_IDX_CYCLE_COUNTER_USER for userspace index
   of cycle counter
---
 arch/arm64/kernel/perf_event.c | 20 +++++++++++++++++++-
 include/linux/perf/arm_pmu.h   |  2 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4658fcf88c2b..40cf59455ce8 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -332,7 +332,7 @@ static const struct attribute_group armv8_pmuv3_caps_attr_group = {
  */
 #define	ARMV8_IDX_CYCLE_COUNTER	0
 #define	ARMV8_IDX_COUNTER0	1
-
+#define	ARMV8_IDX_CYCLE_COUNTER_USER	32
 
 /*
  * We unconditionally enable ARMv8.5-PMU long event counter support
@@ -871,6 +871,22 @@ static void armv8pmu_clear_event_idx(struct pmu_hw_events *cpuc,
 		clear_bit(idx - 1, cpuc->used_mask);
 }
 
+static int armv8pmu_access_event_idx(struct perf_event *event)
+{
+	if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
+		return 0;
+
+	/*
+	 * We remap the cycle counter index to 32 to
+	 * match the offset applied to the rest of
+	 * the counter indices.
+	 */
+	if (event->hw.idx == ARMV8_IDX_CYCLE_COUNTER)
+		return ARMV8_IDX_CYCLE_COUNTER_USER;
+
+	return event->hw.idx;
+}
+
 /*
  * Add an event filter to a given event.
  */
@@ -1098,6 +1114,8 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
 	cpu_pmu->set_event_filter	= armv8pmu_set_event_filter;
 	cpu_pmu->filter_match		= armv8pmu_filter_match;
 
+	cpu_pmu->pmu.event_idx		= armv8pmu_access_event_idx;
+
 	cpu_pmu->name			= name;
 	cpu_pmu->map_event		= map_event;
 	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_EVENTS] = events ?
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 505480217cf1..d29aa981d989 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -26,6 +26,8 @@
  */
 /* Event uses a 64bit counter */
 #define ARMPMU_EVT_64BIT		1
+/* Allow access to hardware counter from userspace */
+#define ARMPMU_EL0_RD_CNTR		2
 
 #define HW_OP_UNSUPPORTED		0xFFFF
 #define C(_x)				PERF_COUNT_HW_CACHE_##_x
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:05 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:05 -0500
Subject: [PATCH v7 3/9] arm64: perf: Enable PMU counter direct access for perf
 event
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-4-robh@kernel.org>

From: Raphael Gault <raphael.gault at arm.com>

Keep track of event opened with direct access to the hardware counters
and modify permissions while they are open.

The strategy used here is the same which x86 uses: every time an event
is mapped, the permissions are set if required. The atomic field added
in the mm_context helps keep track of the different event opened and
de-activate the permissions when all are unmapped.
We also need to update the permissions in the context switch code so
that tasks keep the right permissions.

In order to enable 64-bit counters for userspace when available, a new
config1 bit is added for userspace to indicate it wants userspace counter
access. This bit allows the kernel to decide if chaining should be
disabled and chaining and userspace access are incompatible.
The modes for config1 are as follows:

config1 = 0 or 2 : user access enabled and always 32-bit
config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
config1 = 3 : user access enabled and counter size matches underlying counter.

User access is enabled with config1 == 0 so that we match x86 behavior
and don't need Arm specific code (outside the counter read).

Signed-off-by: Raphael Gault <raphael.gault at arm.com>
Signed-off-by: Rob Herring <robh at kernel.org>
---
Peter Z says (event->oncpu == smp_processor_id()) in the user page
update is always true, but my testing says otherwise[1].

v7:
 - Clear disabled counters when user access is enabled for a task to
   avoid leaking other tasks counter data.
 - Rework context switch handling utilizing sched_task callback
 - Add armv8pmu_event_can_chain() helper
 - Rework config1 flags handling structure
 - Use ARMV8_IDX_CYCLE_COUNTER_USER define for remapped user cycle
   counter index

v6:
 - Add new attr.config1 rdpmc bit for userspace to hint it wants
   userspace access when also requesting 64-bit counters.

v5:
 - Only set cap_user_rdpmc if event is on current cpu
 - Limit enabling/disabling access to CPUs associated with the PMU
   (supported_cpus) and with the mm_struct matching current->active_mm.

v2:
 - Move mapped/unmapped into arm64 code. Fixes arm32.
 - Rebase on cap_user_time_short changes

Changes from Raphael's v4:
  - Drop homogeneous check
  - Disable access for chained counters
  - Set pmc_width in user page

[1] https://lore.kernel.org/lkml/CAL_JsqK+eKef5NaVnBfARCjRE3MYhfBfe54F9YHKbsTnWqLmLw at mail.gmail.com/
---
 arch/arm64/include/asm/mmu.h   |   5 +
 arch/arm64/kernel/perf_event.c | 179 +++++++++++++++++++++++++++++++--
 include/linux/perf/arm_pmu.h   |   6 ++
 3 files changed, 183 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 75beffe2ee8a..ee08447455da 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -18,6 +18,11 @@
 
 typedef struct {
 	atomic64_t	id;
+	/*
+	 * non-zero if userspace have access to hardware
+	 * counters directly.
+	 */
+	atomic_t	pmu_direct_access;
 #ifdef CONFIG_COMPAT
 	void		*sigpage;
 #endif
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 40cf59455ce8..bfbb7f449aca 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -8,9 +8,11 @@
  * This code is based heavily on the ARMv7 perf event code.
  */
 
+#include <asm/cpu.h>
 #include <asm/irq_regs.h>
 #include <asm/perf_event.h>
 #include <asm/sysreg.h>
+#include <asm/traps.h>
 #include <asm/virt.h>
 
 #include <clocksource/arm_arch_timer.h>
@@ -288,15 +290,22 @@ static const struct attribute_group armv8_pmuv3_events_attr_group = {
 
 PMU_FORMAT_ATTR(event, "config:0-15");
 PMU_FORMAT_ATTR(long, "config1:0");
+PMU_FORMAT_ATTR(rdpmc, "config1:1");
 
 static inline 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)
+{
+	return event->attr.config1 & 0x2;
+}
+
 static struct attribute *armv8_pmuv3_format_attrs[] = {
 	&format_attr_event.attr,
 	&format_attr_long.attr,
+	&format_attr_rdpmc.attr,
 	NULL,
 };
 
@@ -344,6 +353,15 @@ static bool armv8pmu_has_long_event(struct arm_pmu *cpu_pmu)
 	return (cpu_pmu->pmuver >= ID_AA64DFR0_PMUVER_8_5);
 }
 
+static inline bool armv8pmu_event_can_chain(struct perf_event *event)
+{
+	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
+
+	return !armv8pmu_event_want_user_access(event) &&
+	       armv8pmu_event_is_64bit(event) &&
+	       !armv8pmu_has_long_event(cpu_pmu);
+}
+
 /*
  * We must chain two programmable counters for 64 bit events,
  * except when we have allocated the 64bit cycle counter (for CPU
@@ -353,11 +371,9 @@ static bool armv8pmu_has_long_event(struct arm_pmu *cpu_pmu)
 static inline bool armv8pmu_event_is_chained(struct perf_event *event)
 {
 	int idx = event->hw.idx;
-	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 
 	return !WARN_ON(idx < 0) &&
-	       armv8pmu_event_is_64bit(event) &&
-	       !armv8pmu_has_long_event(cpu_pmu) &&
+	       armv8pmu_event_can_chain(event) &&
 	       (idx != ARMV8_IDX_CYCLE_COUNTER);
 }
 
@@ -689,6 +705,17 @@ static inline u32 armv8pmu_getreset_flags(void)
 	return value;
 }
 
+static void armv8pmu_disable_user_access(void *mm)
+{
+	if (!mm || (mm == current->active_mm))
+		write_sysreg(0, pmuserenr_el0);
+}
+
+static void armv8pmu_enable_user_access(void)
+{
+	write_sysreg(ARMV8_PMU_USERENR_ER|ARMV8_PMU_USERENR_CR, pmuserenr_el0);
+}
+
 static void armv8pmu_enable_event(struct perf_event *event)
 {
 	/*
@@ -849,13 +876,16 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
 	if (evtype == ARMV8_PMUV3_PERFCTR_CPU_CYCLES) {
 		if (!test_and_set_bit(ARMV8_IDX_CYCLE_COUNTER, cpuc->used_mask))
 			return ARMV8_IDX_CYCLE_COUNTER;
+		else if (armv8pmu_event_is_64bit(event) &&
+			   armv8pmu_event_want_user_access(event) &&
+			   !armv8pmu_has_long_event(cpu_pmu))
+				return -EAGAIN;
 	}
 
 	/*
 	 * Otherwise use events counters
 	 */
-	if (armv8pmu_event_is_64bit(event) &&
-	    !armv8pmu_has_long_event(cpu_pmu))
+	if (armv8pmu_event_can_chain(event))
 		return	armv8pmu_get_chain_idx(cpuc, cpu_pmu);
 	else
 		return armv8pmu_get_single_idx(cpuc, cpu_pmu);
@@ -866,9 +896,12 @@ static void armv8pmu_clear_event_idx(struct pmu_hw_events *cpuc,
 {
 	int idx = event->hw.idx;
 
+	set_bit(idx, cpuc->dirty_mask);
 	clear_bit(idx, cpuc->used_mask);
-	if (armv8pmu_event_is_chained(event))
+	if (armv8pmu_event_is_chained(event)) {
+		set_bit(idx - 1, cpuc->dirty_mask);
 		clear_bit(idx - 1, cpuc->used_mask);
+	}
 }
 
 static int armv8pmu_access_event_idx(struct perf_event *event)
@@ -887,6 +920,86 @@ static int armv8pmu_access_event_idx(struct perf_event *event)
 	return event->hw.idx;
 }
 
+static void armv8pmu_clear_dirty_counters(struct arm_pmu *armpmu)
+{
+	struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
+	int i;
+
+	 /* Don't need to clear the assigned counter. */
+	for_each_set_bit(i, hw_events->used_mask, ARMPMU_MAX_HWEVENTS)
+		clear_bit(i, hw_events->dirty_mask);
+
+	if (bitmap_empty(hw_events->dirty_mask, ARMPMU_MAX_HWEVENTS))
+		return;
+
+	for_each_set_bit(i, hw_events->dirty_mask, ARMPMU_MAX_HWEVENTS) {
+		if (i == ARMV8_IDX_CYCLE_COUNTER)
+			write_sysreg(0, pmccntr_el0);
+		else
+			armv8pmu_write_evcntr(i, 0);
+	}
+
+	bitmap_zero(hw_events->dirty_mask, ARMPMU_MAX_HWEVENTS);
+}
+
+static void armv8pmu_sched_task(struct perf_event_context *ctx, bool sched_in)
+{
+	if (!sched_in)
+		return;
+	/*
+	 * If a new task has user access enabled, clear the dirty counters
+	 * to prevent the potential leak.
+	 */
+	if (ctx && current->mm && atomic_read(&current->mm->context.pmu_direct_access)) {
+		armv8pmu_enable_user_access();
+		armv8pmu_clear_dirty_counters(to_arm_pmu(ctx->pmu));
+	} else {
+		armv8pmu_disable_user_access(NULL);
+	}
+}
+
+static void armv8pmu_event_mapped(struct perf_event *event, struct mm_struct *mm)
+{
+	unsigned long flags;
+
+	if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
+		return;
+
+	if (atomic_inc_return(&mm->context.pmu_direct_access) != 1)
+		return;
+
+	/*
+	 * Enable sched_task() for the user access task,
+	 * and clear the existing dirty counters.
+	 */
+	local_irq_save(flags);
+
+	perf_sched_cb_inc(event->ctx->pmu);
+	if (event->hw.target)
+		armv8pmu_clear_dirty_counters(to_arm_pmu(event->pmu));
+	armv8pmu_enable_user_access();
+
+	local_irq_restore(flags);
+}
+
+static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
+{
+	unsigned long flags;
+	struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+
+	if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
+		return;
+
+	if (!atomic_dec_and_test(&mm->context.pmu_direct_access))
+		return;
+
+	local_irq_save(flags);
+	perf_sched_cb_dec(event->ctx->pmu);
+	local_irq_restore(flags);
+
+	on_each_cpu_mask(&armpmu->supported_cpus, armv8pmu_disable_user_access, mm, 1);
+}
+
 /*
  * Add an event filter to a given event.
  */
@@ -980,7 +1093,19 @@ static int __armv8_pmuv3_map_event(struct perf_event *event,
 				       &armv8_pmuv3_perf_cache_map,
 				       ARMV8_PMU_EVTYPE_EVENT);
 
-	if (armv8pmu_event_is_64bit(event))
+	if (armv8pmu_event_want_user_access(event) || !armv8pmu_event_is_64bit(event))
+		event->hw.flags |= ARMPMU_EL0_RD_CNTR;
+
+	/*
+	 * At this point, the counter is not assigned. If a 64-bit counter is
+	 * requested, we must make sure the h/w has 64-bit counters if we set
+	 * the event size to 64-bit because chaining is not supported with
+	 * userspace access. This may still fail later on if the CPU cycle
+	 * counter is in use.
+	 */
+	if (armv8pmu_event_is_64bit(event) &&
+	    (!armv8pmu_event_want_user_access(event) ||
+	     armv8pmu_has_long_event(armpmu) || (hw_event_id == ARMV8_PMUV3_PERFCTR_CPU_CYCLES)))
 		event->hw.flags |= ARMPMU_EVT_64BIT;
 
 	/* Only expose micro/arch events supported by this PMU */
@@ -1091,6 +1216,30 @@ static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)
 	return probe.present ? 0 : -ENODEV;
 }
 
+static int armv8pmu_undef_handler(struct pt_regs *regs, u32 insn)
+{
+	if (atomic_read(&current->mm->context.pmu_direct_access)) {
+		armv8pmu_enable_user_access();
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+/* This hook will only be triggered by mrs instructions on PMU registers. */
+static struct undef_hook pmu_hook = {
+	.instr_mask = 0xffff8800,
+	.instr_val  = 0xd53b8800,
+	.fn = armv8pmu_undef_handler,
+};
+
+static int __init enable_pmu_undef_hook(void)
+{
+	register_undef_hook(&pmu_hook);
+	return 0;
+}
+core_initcall(enable_pmu_undef_hook);
+
 static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
 			  int (*map_event)(struct perf_event *event),
 			  const struct attribute_group *events,
@@ -1115,6 +1264,9 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
 	cpu_pmu->filter_match		= armv8pmu_filter_match;
 
 	cpu_pmu->pmu.event_idx		= armv8pmu_access_event_idx;
+	cpu_pmu->pmu.event_mapped	= armv8pmu_event_mapped;
+	cpu_pmu->pmu.event_unmapped	= armv8pmu_event_unmapped;
+	cpu_pmu->pmu.sched_task		= armv8pmu_sched_task;
 
 	cpu_pmu->name			= name;
 	cpu_pmu->map_event		= map_event;
@@ -1290,6 +1442,19 @@ void arch_perf_update_userpage(struct perf_event *event,
 	userpg->cap_user_time = 0;
 	userpg->cap_user_time_zero = 0;
 	userpg->cap_user_time_short = 0;
+	userpg->cap_user_rdpmc = !!(event->hw.flags & ARMPMU_EL0_RD_CNTR) &&
+		(event->oncpu == smp_processor_id());
+
+	if (userpg->cap_user_rdpmc) {
+		struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
+
+		if (armv8pmu_event_is_64bit(event) &&
+		    (armv8pmu_has_long_event(cpu_pmu) ||
+		     (userpg->index == ARMV8_IDX_CYCLE_COUNTER_USER)))
+			userpg->pmc_width = 64;
+		else
+			userpg->pmc_width = 32;
+	}
 
 	do {
 		rd = sched_clock_read_begin(&seq);
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index d29aa981d989..63af052e3909 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -56,6 +56,12 @@ struct pmu_hw_events {
 	 */
 	DECLARE_BITMAP(used_mask, ARMPMU_MAX_HWEVENTS);
 
+	/*
+	 * A 1 bit for an index indicates that the counter was used for an
+	 * event and has not been cleared. A 0 means that the counter is cleared.
+	 */
+	DECLARE_BITMAP(dirty_mask, ARMPMU_MAX_HWEVENTS);
+
 	/*
 	 * Hardware lock to serialize accesses to PMU registers. Needed for the
 	 * read/modify/write sequences.
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:07 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:07 -0500
Subject: [PATCH v7 5/9] arm64: perf: Add userspace counter access disable
 switch
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-6-robh@kernel.org>

Like x86, some users may want to disable userspace PMU counter
altogether. Add a sysfs 'rdpmc' file to control userspace counter
access. The default is '1' which is enabled. Writing '0' disables
access.

In the case of multiple PMUs (i.e. big.LITTLE), the control is per PMU
and userspace must disable access on each PMU.

Note that x86 also supports writing '2' to globally enable user access.
As there's not existing userspace support to worry about, this shouldn't
be necessary for Arm. It could be added later if the need arises.

Signed-off-by: Rob Herring <robh at kernel.org>
---
 arch/arm64/kernel/perf_event.c | 61 ++++++++++++++++++++++++++++++++--
 include/linux/perf/arm_pmu.h   |  4 ++-
 2 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index bfbb7f449aca..1ab6308ca89c 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -336,6 +336,54 @@ static const struct attribute_group armv8_pmuv3_caps_attr_group = {
 	.attrs = armv8_pmuv3_caps_attrs,
 };
 
+static void armv8pmu_disable_user_access(void *mm);
+
+static ssize_t get_attr_rdpmc(struct device *dev,
+			      struct device_attribute *attr,
+			      char *buf)
+{
+	struct pmu *pmu = dev_get_drvdata(dev);
+	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
+
+	return snprintf(buf, 40, "%d\n", cpu_pmu->attr_rdpmc);
+}
+
+static ssize_t set_attr_rdpmc(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t count)
+{
+	struct pmu *pmu = dev_get_drvdata(dev);
+	struct arm_pmu *cpu_pmu = container_of(pmu, struct arm_pmu, pmu);
+	unsigned long val;
+	ssize_t ret;
+
+	ret = kstrtoul(buf, 0, &val);
+	if (ret)
+		return ret;
+
+	if (val > 1)
+		return -EINVAL;
+
+	if (val != cpu_pmu->attr_rdpmc) {
+		cpu_pmu->attr_rdpmc = !!val;
+		if (!val)
+			on_each_cpu_mask(&cpu_pmu->supported_cpus, armv8pmu_disable_user_access, NULL, 1);
+	}
+
+	return count;
+}
+
+static DEVICE_ATTR(rdpmc, S_IRUSR | S_IWUSR, get_attr_rdpmc, set_attr_rdpmc);
+
+static struct attribute *armv8_pmuv3_rdpmc_attrs[] = {
+	&dev_attr_rdpmc.attr,
+	NULL,
+};
+
+static const struct attribute_group armv8_pmuv3_rdpmc_attr_group = {
+	.attrs = armv8_pmuv3_rdpmc_attrs,
+};
+
 /*
  * Perf Events' indices
  */
@@ -950,7 +998,8 @@ static void armv8pmu_sched_task(struct perf_event_context *ctx, bool sched_in)
 	 * If a new task has user access enabled, clear the dirty counters
 	 * to prevent the potential leak.
 	 */
-	if (ctx && current->mm && atomic_read(&current->mm->context.pmu_direct_access)) {
+	if (ctx && to_arm_pmu(ctx->pmu)->attr_rdpmc &&
+	    current->mm && atomic_read(&current->mm->context.pmu_direct_access)) {
 		armv8pmu_enable_user_access();
 		armv8pmu_clear_dirty_counters(to_arm_pmu(ctx->pmu));
 	} else {
@@ -1093,7 +1142,8 @@ static int __armv8_pmuv3_map_event(struct perf_event *event,
 				       &armv8_pmuv3_perf_cache_map,
 				       ARMV8_PMU_EVTYPE_EVENT);
 
-	if (armv8pmu_event_want_user_access(event) || !armv8pmu_event_is_64bit(event))
+	if (armpmu->attr_rdpmc &&
+	    (armv8pmu_event_want_user_access(event) || !armv8pmu_event_is_64bit(event)))
 		event->hw.flags |= ARMPMU_EL0_RD_CNTR;
 
 	/*
@@ -1218,7 +1268,9 @@ static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)
 
 static int armv8pmu_undef_handler(struct pt_regs *regs, u32 insn)
 {
-	if (atomic_read(&current->mm->context.pmu_direct_access)) {
+	struct arm_pmu *armpmu = *this_cpu_ptr(&cpu_armpmu);
+
+	if (armpmu->attr_rdpmc && atomic_read(&current->mm->context.pmu_direct_access)) {
 		armv8pmu_enable_user_access();
 		return 0;
 	}
@@ -1277,6 +1329,9 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
 	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_CAPS] = caps ?
 			caps : &armv8_pmuv3_caps_attr_group;
 
+	cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_RDPMC] = &armv8_pmuv3_rdpmc_attr_group;
+	cpu_pmu->attr_rdpmc = true;
+
 	return 0;
 }
 
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 1daad3b2cce5..9303cd07ac57 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -82,6 +82,7 @@ enum armpmu_attr_groups {
 	ARMPMU_ATTR_GROUP_EVENTS,
 	ARMPMU_ATTR_GROUP_FORMATS,
 	ARMPMU_ATTR_GROUP_CAPS,
+	ARMPMU_ATTR_GROUP_RDPMC,
 	ARMPMU_NR_ATTR_GROUPS
 };
 
@@ -107,7 +108,8 @@ struct arm_pmu {
 	int		(*map_event)(struct perf_event *event);
 	int		(*filter_match)(struct perf_event *event);
 	int		num_events;
-	bool		secure_access; /* 32-bit ARM only */
+	bool		secure_access:1; /* 32-bit ARM only */
+	bool		attr_rdpmc:1;
 #define ARMV8_PMUV3_MAX_COMMON_EVENTS		0x40
 	DECLARE_BITMAP(pmceid_bitmap, ARMV8_PMUV3_MAX_COMMON_EVENTS);
 #define ARMV8_PMUV3_EXT_COMMON_EVENT_BASE	0x4000
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:06 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:06 -0500
Subject: [PATCH v7 4/9] drivers/perf: arm_pmu: Export the per_cpu cpu_armpmu
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-5-robh@kernel.org>

The arm64 PMU driver needs to retrieve the struct arm_pmu pointer for
the current CPU. As the common code already maintains this with the
percpu cpu_armpmu, let's make it global.

Signed-off-by: Rob Herring <robh at kernel.org>
---
 drivers/perf/arm_pmu.c       | 2 +-
 include/linux/perf/arm_pmu.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 2d10d84fb79c..6ac56280b9c7 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -99,7 +99,7 @@ static const struct pmu_irq_ops percpu_pmunmi_ops = {
 	.free_pmuirq = armpmu_free_percpu_pmunmi
 };
 
-static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
+DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
 static DEFINE_PER_CPU(int, cpu_irq);
 static DEFINE_PER_CPU(const struct pmu_irq_ops *, cpu_irq_ops);
 
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 63af052e3909..1daad3b2cce5 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -127,6 +127,8 @@ struct arm_pmu {
 
 #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
 
+DECLARE_PER_CPU(struct arm_pmu *, cpu_armpmu);
+
 u64 armpmu_event_update(struct perf_event *event);
 
 int armpmu_event_set_period(struct perf_event *event);
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:08 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:08 -0500
Subject: [PATCH v7 6/9] libperf: Add arm64 support to perf_mmap__read_self()
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-7-robh@kernel.org>

Add the arm64 variants for read_perf_counter() and read_timestamp().
Unfortunately the counter number is encoded into the instruction, so the
code is a bit verbose to enumerate all possible counters.

Signed-off-by: Rob Herring <robh at kernel.org>
---
v7:
 - Move enabling of libperf user read test for arm64 to this patch
---
 tools/lib/perf/mmap.c             | 98 +++++++++++++++++++++++++++++++
 tools/lib/perf/tests/test-evsel.c |  2 +-
 2 files changed, 99 insertions(+), 1 deletion(-)

diff --git a/tools/lib/perf/mmap.c b/tools/lib/perf/mmap.c
index 915469f00cf4..216e6c6212a2 100644
--- a/tools/lib/perf/mmap.c
+++ b/tools/lib/perf/mmap.c
@@ -13,6 +13,7 @@
 #include <internal/lib.h>
 #include <linux/kernel.h>
 #include <linux/math64.h>
+#include <linux/stringify.h>
 #include "internal.h"
 
 void perf_mmap__init(struct perf_mmap *map, struct perf_mmap *prev,
@@ -294,6 +295,103 @@ static u64 read_timestamp(void)
 
 	return low | ((u64)high) << 32;
 }
+#elif defined(__aarch64__)
+#define read_sysreg(r) ({						\
+	u64 __val;							\
+	asm volatile("mrs %0, " __stringify(r) : "=r" (__val));		\
+	__val;								\
+})
+
+static u64 read_pmccntr(void)
+{
+	return read_sysreg(pmccntr_el0);
+}
+
+#define PMEVCNTR_READ(idx)					\
+	static u64 read_pmevcntr_##idx(void) {			\
+		return read_sysreg(pmevcntr##idx##_el0);	\
+	}
+
+PMEVCNTR_READ(0);
+PMEVCNTR_READ(1);
+PMEVCNTR_READ(2);
+PMEVCNTR_READ(3);
+PMEVCNTR_READ(4);
+PMEVCNTR_READ(5);
+PMEVCNTR_READ(6);
+PMEVCNTR_READ(7);
+PMEVCNTR_READ(8);
+PMEVCNTR_READ(9);
+PMEVCNTR_READ(10);
+PMEVCNTR_READ(11);
+PMEVCNTR_READ(12);
+PMEVCNTR_READ(13);
+PMEVCNTR_READ(14);
+PMEVCNTR_READ(15);
+PMEVCNTR_READ(16);
+PMEVCNTR_READ(17);
+PMEVCNTR_READ(18);
+PMEVCNTR_READ(19);
+PMEVCNTR_READ(20);
+PMEVCNTR_READ(21);
+PMEVCNTR_READ(22);
+PMEVCNTR_READ(23);
+PMEVCNTR_READ(24);
+PMEVCNTR_READ(25);
+PMEVCNTR_READ(26);
+PMEVCNTR_READ(27);
+PMEVCNTR_READ(28);
+PMEVCNTR_READ(29);
+PMEVCNTR_READ(30);
+
+/*
+ * Read a value direct from PMEVCNTR<idx>
+ */
+static u64 read_perf_counter(unsigned int counter)
+{
+	static u64 (* const read_f[])(void) = {
+		read_pmevcntr_0,
+		read_pmevcntr_1,
+		read_pmevcntr_2,
+		read_pmevcntr_3,
+		read_pmevcntr_4,
+		read_pmevcntr_5,
+		read_pmevcntr_6,
+		read_pmevcntr_7,
+		read_pmevcntr_8,
+		read_pmevcntr_9,
+		read_pmevcntr_10,
+		read_pmevcntr_11,
+		read_pmevcntr_13,
+		read_pmevcntr_12,
+		read_pmevcntr_14,
+		read_pmevcntr_15,
+		read_pmevcntr_16,
+		read_pmevcntr_17,
+		read_pmevcntr_18,
+		read_pmevcntr_19,
+		read_pmevcntr_20,
+		read_pmevcntr_21,
+		read_pmevcntr_22,
+		read_pmevcntr_23,
+		read_pmevcntr_24,
+		read_pmevcntr_25,
+		read_pmevcntr_26,
+		read_pmevcntr_27,
+		read_pmevcntr_28,
+		read_pmevcntr_29,
+		read_pmevcntr_30,
+		read_pmccntr
+	};
+
+	if (counter < ARRAY_SIZE(read_f))
+		return (read_f[counter])();
+
+	return 0;
+}
+
+static u64 read_timestamp(void) { return read_sysreg(cntvct_el0); }
+
 #else
 static u64 read_perf_counter(unsigned int counter) { return 0; }
 static u64 read_timestamp(void) { return 0; }
diff --git a/tools/lib/perf/tests/test-evsel.c b/tools/lib/perf/tests/test-evsel.c
index 288b5feaefe2..670fcdb6d6af 100644
--- a/tools/lib/perf/tests/test-evsel.c
+++ b/tools/lib/perf/tests/test-evsel.c
@@ -148,7 +148,7 @@ static int test_stat_user_read(int event)
 
 	pc = perf_evsel__mmap_base(evsel, 0, 0);
 
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__i386__) || defined(__x86_64__) || __defined(__aarch64__)
 	__T("userspace counter access not supported", pc->cap_user_rdpmc);
 	__T("userspace counter access not enabled", pc->index);
 	__T("userspace counter width not set", pc->pmc_width >= 32);
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:10 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:10 -0500
Subject: [PATCH v7 8/9] perf: arm64: Add tests for 32-bit and 64-bit counter
 size userspace access
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-9-robh@kernel.org>

Add arm64 specific tests for 32-bit and 64-bit counter user access. On
arm64, counters default to 32-bit unless attr.config1:0 is set to 1. In
order to enable user access for 64-bit counters, attr.config1 must be set
to 3.

Signed-off-by: Rob Herring <robh at kernel.org>
---
v6:
 - New patch
---
 tools/perf/arch/arm64/include/arch-tests.h |  5 +++
 tools/perf/arch/arm64/tests/arch-tests.c   |  8 +++++
 tools/perf/arch/arm64/tests/user-events.c  | 38 ++++++++++++++++++++++
 3 files changed, 51 insertions(+)

diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
index 380ad34a3f09..ddfa7460e1e1 100644
--- a/tools/perf/arch/arm64/include/arch-tests.h
+++ b/tools/perf/arch/arm64/include/arch-tests.h
@@ -15,5 +15,10 @@ extern struct test arch_tests[];
 int test__rd_pinned(struct test __maybe_unused *test,
 		       int __maybe_unused subtest);
 
+int test__rd_64bit(struct test __maybe_unused *test,
+		   int __maybe_unused subtest);
+
+int test__rd_32bit(struct test __maybe_unused *test,
+		   int __maybe_unused subtest);
 
 #endif
diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
index 80ce7bd3c16d..bbdb81aa3229 100644
--- a/tools/perf/arch/arm64/tests/arch-tests.c
+++ b/tools/perf/arch/arm64/tests/arch-tests.c
@@ -14,6 +14,14 @@ struct test arch_tests[] = {
 		.desc = "Pinned CPU user counter access",
 		.func = test__rd_pinned,
 	},
+	{
+		.desc = "User 64-bit counter access",
+		.func = test__rd_64bit,
+	},
+	{
+		.desc = "User 32-bit counter access",
+		.func = test__rd_32bit,
+	},
 	{
 		.func = NULL,
 	},
diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
index c8efc6b369e6..546323b5242c 100644
--- a/tools/perf/arch/arm64/tests/user-events.c
+++ b/tools/perf/arch/arm64/tests/user-events.c
@@ -175,3 +175,41 @@ int test__rd_pinned(struct test __maybe_unused *test,
 	perf_evsel__delete(evsel);
 	return ret;
 }
+
+static int test__rd_counter_size(struct test __maybe_unused *test,
+				 int config1)
+{
+	int ret;
+	struct perf_evsel *evsel;
+	struct perf_event_attr attr = {
+		.type = PERF_TYPE_HARDWARE,
+		.config = PERF_COUNT_HW_INSTRUCTIONS,
+		.config1 = config1,
+		.exclude_kernel = 1,
+	};
+
+	if (!pmu_is_homogeneous())
+		return TEST_SKIP;
+
+	evsel = perf_init(&attr);
+	if (!evsel)
+		return -1;
+
+	ret = run_test(evsel);
+
+	perf_evsel__close(evsel);
+	perf_evsel__delete(evsel);
+	return ret;
+}
+
+int test__rd_64bit(struct test __maybe_unused *test,
+		   int __maybe_unused subtest)
+{
+	return test__rd_counter_size(test, 0x3);
+}
+
+int test__rd_32bit(struct test __maybe_unused *test,
+		   int __maybe_unused subtest)
+{
+	return test__rd_counter_size(test, 0x2);
+}
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:09 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:09 -0500
Subject: [PATCH v7 7/9] perf: arm64: Add test for userspace counter access on
 heterogeneous systems
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-8-robh@kernel.org>

Userspace counter access only works on heterogeneous systems with some
restrictions. The userspace process must be pinned to a homogeneous
subset of CPUs and must open the corresponding PMU for those CPUs. This
commit adds a test implementing these requirements.

Signed-off-by: Rob Herring <robh at kernel.org>
---
v6:
 - Add a check on cap_user_rdpmc
v5:
 - Adapt to libperf mmap API changes
v4:
 - Update perf_evsel__mmap params
v2:
 - Drop all but heterogeneous test as others covered by libperf tests
 - Rework to use libperf
---
 tools/perf/arch/arm64/include/arch-tests.h |   7 +
 tools/perf/arch/arm64/tests/Build          |   1 +
 tools/perf/arch/arm64/tests/arch-tests.c   |   4 +
 tools/perf/arch/arm64/tests/user-events.c  | 177 +++++++++++++++++++++
 4 files changed, 189 insertions(+)
 create mode 100644 tools/perf/arch/arm64/tests/user-events.c

diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
index 90ec4c8cb880..380ad34a3f09 100644
--- a/tools/perf/arch/arm64/include/arch-tests.h
+++ b/tools/perf/arch/arm64/include/arch-tests.h
@@ -2,11 +2,18 @@
 #ifndef ARCH_TESTS_H
 #define ARCH_TESTS_H
 
+#include <linux/compiler.h>
+
 #ifdef HAVE_DWARF_UNWIND_SUPPORT
 struct thread;
 struct perf_sample;
+int test__arch_unwind_sample(struct perf_sample *sample,
+			     struct thread *thread);
 #endif
 
 extern struct test arch_tests[];
+int test__rd_pinned(struct test __maybe_unused *test,
+		       int __maybe_unused subtest);
+
 
 #endif
diff --git a/tools/perf/arch/arm64/tests/Build b/tools/perf/arch/arm64/tests/Build
index a61c06bdb757..3f9a20c17fc6 100644
--- a/tools/perf/arch/arm64/tests/Build
+++ b/tools/perf/arch/arm64/tests/Build
@@ -1,4 +1,5 @@
 perf-y += regs_load.o
 perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
 
+perf-y += user-events.o
 perf-y += arch-tests.o
diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
index 5b1543c98022..80ce7bd3c16d 100644
--- a/tools/perf/arch/arm64/tests/arch-tests.c
+++ b/tools/perf/arch/arm64/tests/arch-tests.c
@@ -10,6 +10,10 @@ struct test arch_tests[] = {
 		.func = test__dwarf_unwind,
 	},
 #endif
+	{
+		.desc = "Pinned CPU user counter access",
+		.func = test__rd_pinned,
+	},
 	{
 		.func = NULL,
 	},
diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
new file mode 100644
index 000000000000..c8efc6b369e6
--- /dev/null
+++ b/tools/perf/arch/arm64/tests/user-events.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <unistd.h>
+#include <sched.h>
+#include <cpumap.h>
+
+#include <perf/core.h>
+#include <perf/threadmap.h>
+#include <perf/evsel.h>
+
+#include "pmu.h"
+#include "debug.h"
+#include "tests/tests.h"
+#include "arch-tests.h"
+
+static int run_test(struct perf_evsel *evsel)
+{
+	int n;
+	volatile int tmp = 0;
+	u64 delta, i, loops = 1000;
+	struct perf_counts_values counts = { .val = 0 };
+
+	for (n = 0; n < 6; n++) {
+		u64 stamp, now;
+
+		perf_evsel__read(evsel, 0, 0, &counts);
+		stamp = counts.val;
+
+		for (i = 0; i < loops; i++)
+			tmp++;
+
+		perf_evsel__read(evsel, 0, 0, &counts);
+		now = counts.val;
+		loops *= 10;
+
+		delta = now - stamp;
+		pr_debug("%14d: %14llu\n", n, (long long)delta);
+
+		if (!delta)
+			break;
+	}
+	return delta ? 0 : -1;
+}
+
+static struct perf_pmu *pmu_for_cpu(int cpu)
+{
+	int acpu, idx;
+	struct perf_pmu *pmu = NULL;
+
+	while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+		if (pmu->is_uncore)
+			continue;
+		perf_cpu_map__for_each_cpu(acpu, idx, pmu->cpus)
+			if (acpu == cpu)
+				return pmu;
+	}
+	return NULL;
+}
+
+static bool pmu_is_homogeneous(void)
+{
+	int core_cnt = 0;
+	struct perf_pmu *pmu = NULL;
+
+	while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+		if (!pmu->is_uncore && !perf_cpu_map__empty(pmu->cpus))
+			core_cnt++;
+	}
+	return core_cnt == 1;
+}
+
+static int libperf_print(enum libperf_print_level level,
+			 const char *fmt, va_list ap)
+{
+	(void)level;
+	return vfprintf(stderr, fmt, ap);
+}
+
+static struct perf_evsel *perf_init(struct perf_event_attr *attr)
+{
+	int err;
+	struct perf_thread_map *threads;
+	struct perf_evsel *evsel;
+	struct perf_event_mmap_page *pc;
+
+	libperf_init(libperf_print);
+
+	threads = perf_thread_map__new_dummy();
+	if (!threads) {
+		pr_err("failed to create threads\n");
+		return NULL;
+	}
+
+	perf_thread_map__set_pid(threads, 0, 0);
+
+	evsel = perf_evsel__new(attr);
+	if (!evsel) {
+		pr_err("failed to create evsel\n");
+		goto out_thread;
+	}
+
+	err = perf_evsel__open(evsel, NULL, threads);
+	if (err) {
+		pr_err("failed to open evsel\n");
+		goto out_open;
+	}
+
+	if (perf_evsel__mmap(evsel, 0)) {
+		pr_err("failed to mmap evsel\n");
+		goto out_mmap;
+	}
+
+	pc = perf_evsel__mmap_base(evsel, 0, 0);
+	if (!pc->cap_user_rdpmc) {
+		pr_err("userspace access not enabled\n");
+		goto out_mmap;
+	}
+
+	return evsel;
+
+out_mmap:
+	perf_evsel__close(evsel);
+out_open:
+	perf_evsel__delete(evsel);
+out_thread:
+	perf_thread_map__put(threads);
+	return NULL;
+}
+
+int test__rd_pinned(struct test __maybe_unused *test,
+		    int __maybe_unused subtest)
+{
+	int cpu, cputmp, ret = -1;
+	struct perf_evsel *evsel;
+	struct perf_event_attr attr = {
+		.config = 0x8, /* Instruction count */
+		.config1 = 0, /* 32-bit counter */
+		.exclude_kernel = 1,
+	};
+	cpu_set_t cpu_set;
+	struct perf_pmu *pmu;
+
+	if (pmu_is_homogeneous())
+		return TEST_SKIP;
+
+	cpu = sched_getcpu();
+	pmu = pmu_for_cpu(cpu);
+	if (!pmu)
+		return -1;
+	attr.type = pmu->type;
+
+	CPU_ZERO(&cpu_set);
+	perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus)
+		CPU_SET(cpu, &cpu_set);
+	if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
+		pr_err("Could not set affinity\n");
+
+	evsel = perf_init(&attr);
+	if (!evsel)
+		return -1;
+
+	perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus) {
+		CPU_ZERO(&cpu_set);
+		CPU_SET(cpu, &cpu_set);
+		if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
+			pr_err("Could not set affinity\n");
+
+		pr_debug("Running on CPU %d\n", cpu);
+
+		ret = run_test(evsel);
+		if (ret)
+			break;
+	}
+
+	perf_evsel__close(evsel);
+	perf_evsel__delete(evsel);
+	return ret;
+}
-- 
2.27.0



From robh at kernel.org  Tue Apr 20 04:15:11 2021
From: robh at kernel.org (Rob Herring)
Date: Mon, 19 Apr 2021 22:15:11 -0500
Subject: [PATCH v7 9/9] Documentation: arm64: Document PMU counters access
 from userspace
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <20210420031511.2348977-10-robh@kernel.org>

From: Raphael Gault <raphael.gault at arm.com>

Add documentation to describe the access to the pmu hardware counters from
userspace.

Signed-off-by: Raphael Gault <raphael.gault at arm.com>
Signed-off-by: Rob Herring <robh at kernel.org>
---
v7:
 - Merge into existing arm64 perf.rst
v6:
  - Update the chained event section with attr.config1 details
v2:
  - Update links to test examples

Changes from Raphael's v4:
  - Convert to rSt
  - Update chained event status
  - Add section for heterogeneous systems
---
 Documentation/arm64/perf.rst | 67 +++++++++++++++++++++++++++++++++++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/perf.rst b/Documentation/arm64/perf.rst
index b567f177d385..c40fc2adc451 100644
--- a/Documentation/arm64/perf.rst
+++ b/Documentation/arm64/perf.rst
@@ -2,7 +2,10 @@
 
 .. _perf_index:
 
-=====================
+====
+Perf
+====
+
 Perf Event Attributes
 =====================
 
@@ -88,3 +91,65 @@ exclude_host. However when using !exclude_hv there is a small blackout
 window at the guest entry/exit where host events are not captured.
 
 On VHE systems there are no blackout windows.
+
+Perf Userspace PMU Hardware Counter Access
+==========================================
+
+Overview
+--------
+The perf userspace tool relies on the PMU to monitor events. It offers an
+abstraction layer over the hardware counters since the underlying
+implementation is cpu-dependent.
+Arm64 allows userspace tools to have access to the registers storing the
+hardware counters' values directly.
+
+This targets specifically self-monitoring tasks in order to reduce the overhead
+by directly accessing the registers without having to go through the kernel.
+
+How-to
+------
+The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu
+registers is enabled and that the userspace has access to the relevant
+information in order to use them.
+
+In order to have access to the hardware counter it is necessary to open the event
+using the perf tool interface: the sys_perf_event_open syscall returns a fd which
+can subsequently be used with the mmap syscall in order to retrieve a page of
+memory containing information about the event.
+The PMU driver uses this page to expose to the user the hardware counter's
+index and other necessary data. Using this index enables the user to access the
+PMU registers using the `mrs` instruction.
+
+The userspace access is supported in libperf using the perf_evsel__mmap()
+and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for
+an example.
+
+About heterogeneous systems
+---------------------------
+On heterogeneous systems such as big.LITTLE, userspace PMU counter access can
+only be enabled when the tasks are pinned to a homogeneous subset of cores and
+the corresponding PMU instance is opened by specifying the 'type' attribute.
+The use of generic event types is not supported in this case.
+
+Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It
+can be run using the perf tool to check that the access to the registers works
+correctly from userspace:
+
+.. code-block:: sh
+
+  perf test -v user
+
+About chained events and 64-bit counters
+----------------------------------------
+Chained events are not supported in conjunction with userspace counter
+access. If a 64-bit counter is requested (attr.config1:0), then
+userspace access must also be requested with attr.config1:1 set. This
+will disable counter chaining. The 'pmc_width' in the user page will
+indicate the actual width of the counter which could be only 32-bits
+depending on event and PMU features.
+
+.. Links
+.. _tools/perf/arch/arm64/tests/user-events.c:
+   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
-- 
2.27.0



From song.bao.hua at hisilicon.com  Tue Apr 20 04:30:53 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Tue, 20 Apr 2021 03:30:53 +0000
Subject: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within a
 die
In-Reply-To: <YFR2kwakbcGiI37w@kroah.com>
References: <20210319041618.14316-1-song.bao.hua@hisilicon.com>
 <20210319041618.14316-2-song.bao.hua@hisilicon.com>
 <YFRGIedW1fUlnmi+@kroah.com> <eb48302277f3436eb9899032e6b0bf1c@hisilicon.com>
 <20210319093616.00001879@Huawei.com> <YFR2kwakbcGiI37w@kroah.com>
Message-ID: <57660c1863194dd58e441fce9d5d1580@hisilicon.com>



> -----Original Message-----
> From: Greg KH [mailto:gregkh at linuxfoundation.org]
> Sent: Friday, March 19, 2021 11:02 PM
> To: Jonathan Cameron <jonathan.cameron at huawei.com>
> Cc: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> tim.c.chen at linux.intel.com; catalin.marinas at arm.com; will at kernel.org;
> rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org; peterz at infradead.org;
> dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> mgorman at suse.de; msys.mizuma at gmail.com; valentin.schneider at arm.com;
> juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com
> Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within
> a die
> 
> On Fri, Mar 19, 2021 at 09:36:16AM +0000, Jonathan Cameron wrote:
> > On Fri, 19 Mar 2021 06:57:08 +0000
> > "Song Bao Hua (Barry Song)" <song.bao.hua at hisilicon.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:gregkh at linuxfoundation.org]
> > > > Sent: Friday, March 19, 2021 7:35 PM
> > > > To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>
> > > > Cc: tim.c.chen at linux.intel.com; catalin.marinas at arm.com;
> will at kernel.org;
> > > > rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> > > > tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org;
> peterz at infradead.org;
> > > > dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> > > > mgorman at suse.de; msys.mizuma at gmail.com; valentin.schneider at arm.com;
> Jonathan
> > > > Cameron <jonathan.cameron at huawei.com>; juri.lelli at redhat.com;
> > > > mark.rutland at arm.com; sudeep.holla at arm.com; aubrey.li at linux.intel.com;
> > > > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > > linux-acpi at vger.kernel.org; x86 at kernel.org; xuwei (O)
> <xuwei5 at huawei.com>;
> > > > Zengtao (B) <prime.zeng at hisilicon.com>; guodong.xu at linaro.org;
> yangyicong
> > > > <yangyicong at huawei.com>; Liguozhu (Kenneth) <liguozhu at hisilicon.com>;
> > > > linuxarm at openeuler.org; hpa at zytor.com
> > > > Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within
> > > > a die
> > > >
> > > > On Fri, Mar 19, 2021 at 05:16:15PM +1300, Barry Song wrote:
> > > > > diff --git a/Documentation/admin-guide/cputopology.rst
> > > > b/Documentation/admin-guide/cputopology.rst
> > > > > index b90dafc..f9d3745 100644
> > > > > --- a/Documentation/admin-guide/cputopology.rst
> > > > > +++ b/Documentation/admin-guide/cputopology.rst
> > > > > @@ -24,6 +24,12 @@ core_id:
> > > > >  	identifier (rather than the kernel's).  The actual value is
> > > > >  	architecture and platform dependent.
> > > > >
> > > > > +cluster_id:
> > > > > +
> > > > > +	the Cluster ID of cpuX.  Typically it is the hardware platform's
> > > > > +	identifier (rather than the kernel's).  The actual value is
> > > > > +	architecture and platform dependent.
> > > > > +
> > > > >  book_id:
> > > > >
> > > > >  	the book ID of cpuX. Typically it is the hardware platform's
> > > > > @@ -56,6 +62,14 @@ package_cpus_list:
> > > > >  	human-readable list of CPUs sharing the same physical_package_id.
> > > > >  	(deprecated name: "core_siblings_list")
> > > > >
> > > > > +cluster_cpus:
> > > > > +
> > > > > +	internal kernel map of CPUs within the same cluster.
> > > > > +
> > > > > +cluster_cpus_list:
> > > > > +
> > > > > +	human-readable list of CPUs within the same cluster.
> > > > > +
> > > > >  die_cpus:
> > > > >
> > > > >  	internal kernel map of CPUs within the same die.
> > > >
> > > > Why are these sysfs files in this file, and not in a Documentation/ABI/
> > > > file which can be correctly parsed and shown to userspace?
> > >
> > > Well. Those ABIs have been there for much a long time. It is like:
> > >
> > > [root at ceph1 topology]# ls
> > > core_id  core_siblings  core_siblings_list  physical_package_id
> thread_siblings  thread_siblings_list
> > > [root at ceph1 topology]# pwd
> > > /sys/devices/system/cpu/cpu100/topology
> > > [root at ceph1 topology]# cat core_siblings_list
> > > 64-127
> > > [root at ceph1 topology]#
> > >
> > > >
> > > > Any chance you can fix that up here as well?
> > >
> > > Yes. we will send a separate patch to address this, which won't
> > > be in this patchset. This patchset will base on that one.
> > >
> > > >
> > > > Also note that "list" is not something that goes in sysfs, sysfs is "one
> > > > value per file", and a list is not "one value".  How do you prevent
> > > > overflowing the buffer of the sysfs file if you have a "list"?
> > > >
> > >
> > > At a glance, the list is using "-" rather than a real list
> > > [root at ceph1 topology]# cat core_siblings_list
> > > 64-127
> > >
> > > Anyway, I will take a look if it has any chance to overflow.
> >
> > It could in theory be alternate CPUs as comma separated list.
> > So it's would get interesting around 500-1000 cpus (guessing).
> >
> > Hopefully no one has that crazy a cpu numbering scheme but it's possible
> > (note that cluster is fine for this, but I guess it might eventually
> > happen for core-siblings list (cpus within a package).
> >
> > Shouldn't crash or anything like that but might terminate early.
> 
> We have a broken sysfs api already for listing LED numbers that has had
> to be worked around in the past, please do not create a new one with
> that same problem, we should learn from them :)

Another place I am seeing a cpu list is in numa topology:
/sys/devices/system/node/nodex/cpulist.

But the code has a BUILD_BUG_ON to guard the pagebuf:

static ssize_t node_read_cpumap(struct device *dev, bool list, char *buf)
{
	ssize_t n;
	cpumask_var_t mask;
	struct node *node_dev = to_node(dev);

	/* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
	BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));

	if (!alloc_cpumask_var(&mask, GFP_KERNEL))
		return 0;

	cpumask_and(mask, cpumask_of_node(node_dev->dev.id), cpu_online_mask);
	n = cpumap_print_to_pagebuf(list, buf, mask);
	free_cpumask_var(mask);

	return n;
}

For lists in cpu topology, I haven't seen this while I believe we need it.
Or am I missing something?

> 
> thanks,
> 
> greg k-h

Thanks
Barry



From lkp at intel.com  Tue Apr 20 04:30:25 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 11:30:25 +0800
Subject: [xlnx:master 20/33] drivers/usb/dwc3/core.h:1421:6: warning: no
 previous prototype for function 'dwc3_mask_phy_reset'
Message-ID: <202104201115.Rh19els6-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   5fd22595ae63ccd63022971d869da5cb90447a29
commit: 31d7800cc8d815f78d1bfa30655799f5733a4f59 [20/33] usb: dwc3: Add support for masking phy reset signal
config: x86_64-randconfig-r025-20210419 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 2b50f5a4343f8fb06acaa5c36355bcf58092c9cd)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/31d7800cc8d815f78d1bfa30655799f5733a4f59
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 31d7800cc8d815f78d1bfa30655799f5733a4f59
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/core.c:11:
   In file included from include/linux/clk.h:17:
   In file included from include/linux/notifier.h:15:
   In file included from include/linux/rwsem.h:16:
   In file included from include/linux/spinlock.h:51:
   In file included from include/linux/preempt.h:81:
   In file included from arch/x86/include/asm/preempt.h:7:
   In file included from include/linux/thread_info.h:38:
   In file included from arch/x86/include/asm/thread_info.h:53:
   arch/x86/include/asm/cpufeature.h:164:2: error: implicit declaration of function 'asm_volatile_goto' [-Werror,-Wimplicit-function-declaration]
           asm_volatile_goto("1: jmp 6f\n"
           ^
   arch/x86/include/asm/cpufeature.h:195:4: error: expected ')'
                    : : [feature]  "i" (bit),
                    ^
   arch/x86/include/asm/cpufeature.h:164:19: note: to match this '('
           asm_volatile_goto("1: jmp 6f\n"
                            ^
   In file included from drivers/usb/dwc3/core.c:36:
   drivers/usb/dwc3/core.h:1413:6: warning: no previous prototype for function 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
        ^
   drivers/usb/dwc3/core.h:1413:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
   drivers/usb/dwc3/core.h:1415:6: warning: no previous prototype for function 'dwc3_set_simple_data' [-Wmissing-prototypes]
   void dwc3_set_simple_data(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1415:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_set_simple_data(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1417:6: warning: no previous prototype for function 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1417:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1419:5: warning: no previous prototype for function 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
       ^
   drivers/usb/dwc3/core.h:1419:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
   ^
   static 
>> drivers/usb/dwc3/core.h:1421:6: warning: no previous prototype for function 'dwc3_mask_phy_reset' [-Wmissing-prototypes]
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
        ^
   drivers/usb/dwc3/core.h:1421:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
   ^
   static 
   5 warnings and 2 errors generated.
--
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/trace.h:17:
   In file included from include/linux/tracepoint.h:18:
   In file included from include/linux/srcu.h:33:
   In file included from include/linux/rcupdate.h:40:
   In file included from include/linux/preempt.h:81:
   In file included from arch/x86/include/asm/preempt.h:7:
   In file included from include/linux/thread_info.h:38:
   In file included from arch/x86/include/asm/thread_info.h:53:
   arch/x86/include/asm/cpufeature.h:164:2: error: implicit declaration of function 'asm_volatile_goto' [-Werror,-Wimplicit-function-declaration]
           asm_volatile_goto("1: jmp 6f\n"
           ^
   arch/x86/include/asm/cpufeature.h:195:4: error: expected ')'
                    : : [feature]  "i" (bit),
                    ^
   arch/x86/include/asm/cpufeature.h:164:19: note: to match this '('
           asm_volatile_goto("1: jmp 6f\n"
                            ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/trace.h:19:
   drivers/usb/dwc3/core.h:1413:6: warning: no previous prototype for function 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
        ^
   drivers/usb/dwc3/core.h:1413:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
   drivers/usb/dwc3/core.h:1415:6: warning: no previous prototype for function 'dwc3_set_simple_data' [-Wmissing-prototypes]
   void dwc3_set_simple_data(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1415:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_set_simple_data(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1417:6: warning: no previous prototype for function 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1417:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1419:5: warning: no previous prototype for function 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
       ^
   drivers/usb/dwc3/core.h:1419:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
   ^
   static 
>> drivers/usb/dwc3/core.h:1421:6: warning: no previous prototype for function 'dwc3_mask_phy_reset' [-Wmissing-prototypes]
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
        ^
   drivers/usb/dwc3/core.h:1421:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
   ^
   static 
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:83:11: warning: array index 3 is past the end of the array (which contains 1 element) [-Warray-bounds]
                   return (set->sig[3] | set->sig[2] |
                           ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:83:25: warning: array index 2 is past the end of the array (which contains 1 element) [-Warray-bounds]
                   return (set->sig[3] | set->sig[2] |
                                         ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:84:4: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
                           set->sig[1] | set->sig[0]) == 0;
                           ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:86:11: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
                   return (set->sig[1] | set->sig[0]) == 0;
                           ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:99:11: warning: array index 3 is past the end of the array (which contains 1 element) [-Warray-bounds]
                   return  (set1->sig[3] == set2->sig[3]) &&
                            ^         ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/trace.c:11:
   In file included from drivers/usb/dwc3/./trace.h:341:
   In file included from include/trace/define_trace.h:96:
   In file included from include/trace/trace_events.h:20:
   In file included from include/linux/trace_events.h:10:
   In file included from include/linux/perf_event.h:18:
   In file included from include/uapi/linux/bpf_perf_event.h:11:
   In file included from ./arch/x86/include/generated/uapi/asm/bpf_perf_event.h:1:
   In file included from include/uapi/asm-generic/bpf_perf_event.h:4:
--
   _SIG_SET_OP(signotset, _sig_not)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/signal.h:159:3: note: expanded from macro '_SIG_SET_OP'
                   set->sig[2] = op(set->sig[2]);                          \
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:169:1: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
   _SIG_SET_OP(signotset, _sig_not)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/signal.h:160:27: note: expanded from macro '_SIG_SET_OP'
           case 2: set->sig[1] = op(set->sig[1]);                          \
                                    ^        ~
   include/linux/signal.h:168:24: note: expanded from macro '_sig_not'
   #define _sig_not(x)     (~(x))
                              ^
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:169:1: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
   _SIG_SET_OP(signotset, _sig_not)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/signal.h:160:10: note: expanded from macro '_SIG_SET_OP'
           case 2: set->sig[1] = op(set->sig[1]);                          \
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:180:10: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
           case 2: set->sig[1] = 0;
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:192:10: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
           case 2: set->sig[1] = -1;
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:222:10: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
           case 2: set->sig[1] = 0;
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:13:
   In file included from include/linux/ptrace.h:7:
   In file included from include/linux/sched/signal.h:6:
   include/linux/signal.h:234:10: warning: array index 1 is past the end of the array (which contains 1 element) [-Warray-bounds]
           case 2: set->sig[1] = -1;
                   ^        ~
   arch/x86/include/asm/signal.h:24:2: note: array 'sig' declared here
           unsigned long sig[_NSIG_WORDS];
           ^
   In file included from drivers/usb/dwc3/debugfs.c:23:
   drivers/usb/dwc3/core.h:1413:6: warning: no previous prototype for function 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
        ^
   drivers/usb/dwc3/core.h:1413:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
   drivers/usb/dwc3/core.h:1415:6: warning: no previous prototype for function 'dwc3_set_simple_data' [-Wmissing-prototypes]
   void dwc3_set_simple_data(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1415:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_set_simple_data(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1417:6: warning: no previous prototype for function 'dwc3_simple_check_quirks' [-Wmissing-prototypes]
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
        ^
   drivers/usb/dwc3/core.h:1417:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_check_quirks(struct dwc3 *dwc)
   ^
   static 
   drivers/usb/dwc3/core.h:1419:5: warning: no previous prototype for function 'dwc3_set_usb_core_power' [-Wmissing-prototypes]
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
       ^
   drivers/usb/dwc3/core.h:1419:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
   ^
   static 
>> drivers/usb/dwc3/core.h:1421:6: warning: no previous prototype for function 'dwc3_mask_phy_reset' [-Wmissing-prototypes]
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
        ^
   drivers/usb/dwc3/core.h:1421:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_mask_phy_reset(struct device *dev, bool mask)
   ^
   static 
   54 warnings and 2 errors generated.


vim +/dwc3_mask_phy_reset +1421 drivers/usb/dwc3/core.h

  1402	
  1403	#if IS_ENABLED(CONFIG_USB_DWC3_OF_SIMPLE)
  1404	int dwc3_enable_hw_coherency(struct device *dev);
  1405	void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup);
  1406	void dwc3_set_simple_data(struct dwc3 *dwc);
  1407	void dwc3_simple_check_quirks(struct dwc3 *dwc);
  1408	int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on);
  1409	void dwc3_mask_phy_reset(struct device *dev, bool mask);
  1410	#else
  1411	static inline int dwc3_enable_hw_coherency(struct device *dev)
  1412	{ return 1; }
  1413	void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
  1414	{ ; }
  1415	void dwc3_set_simple_data(struct dwc3 *dwc)
  1416	{ ; }
  1417	void dwc3_simple_check_quirks(struct dwc3 *dwc)
  1418	{ ; }
> 1419	int dwc3_set_usb_core_power(struct dwc3 *dwc, bool on)
  1420	{ ; }
> 1421	void dwc3_mask_phy_reset(struct device *dev, bool mask)
  1422	{ ; }
  1423	#endif
  1424	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35940 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/56b48fe5/attachment-0001.gz>

From chuanjia.liu at mediatek.com  Tue Apr 20 04:42:01 2021
From: chuanjia.liu at mediatek.com (Chuanjia Liu)
Date: Tue, 20 Apr 2021 11:42:01 +0800
Subject: [PATCH v9 2/4] PCI: mediatek: Add new method to get shared
 pcie-cfg base address and parse node
In-Reply-To: <20210406034410.24381-3-chuanjia.liu@mediatek.com>
References: <20210406034410.24381-1-chuanjia.liu@mediatek.com>
 <20210406034410.24381-3-chuanjia.liu@mediatek.com>
Message-ID: <1618890121.31169.4.camel@mhfsdcap03>

Hi, Lorenzo, Bjorn,

Just a gentle ping. Please let me know your comments about this patch
set.

thanks

On Tue, 2021-04-06 at 11:44 +0800, Chuanjia Liu wrote:
> For the new dts format, add a new method to get
> shared pcie-cfg base address and parse node.
> 
> Signed-off-by: Chuanjia Liu <chuanjia.liu at mediatek.com>
> Acked-by: Ryder Lee <ryder.lee at mediatek.com>
> ---
>  drivers/pci/controller/pcie-mediatek.c | 52 +++++++++++++++++++-------
>  1 file changed, 39 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 23548b517e4b..65ebcdb8ab57 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -14,6 +14,7 @@
>  #include <linux/irqchip/chained_irq.h>
>  #include <linux/irqdomain.h>
>  #include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
>  #include <linux/msi.h>
>  #include <linux/module.h>
>  #include <linux/of_address.h>
> @@ -23,6 +24,7 @@
>  #include <linux/phy/phy.h>
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
>  #include <linux/reset.h>
>  
>  #include "../pci.h"
> @@ -205,6 +207,7 @@ struct mtk_pcie_port {
>   * struct mtk_pcie - PCIe host information
>   * @dev: pointer to PCIe device
>   * @base: IO mapped register base
> + * @cfg: IO mapped register map for PCIe config
>   * @free_ck: free-run reference clock
>   * @mem: non-prefetchable memory resource
>   * @ports: pointer to PCIe port information
> @@ -213,6 +216,7 @@ struct mtk_pcie_port {
>  struct mtk_pcie {
>  	struct device *dev;
>  	void __iomem *base;
> +	struct regmap *cfg;
>  	struct clk *free_ck;
>  
>  	struct list_head ports;
> @@ -648,7 +652,11 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
>  		return err;
>  	}
>  
> -	port->irq = platform_get_irq(pdev, port->slot);
> +	if (of_find_property(dev->of_node, "interrupt-names", NULL))
> +		port->irq = platform_get_irq_byname(pdev, "pcie_irq");
> +	else
> +		port->irq = platform_get_irq(pdev, port->slot);
> +
>  	if (port->irq < 0)
>  		return port->irq;
>  
> @@ -680,6 +688,10 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
>  		val |= PCIE_CSR_LTSSM_EN(port->slot) |
>  		       PCIE_CSR_ASPM_L1_EN(port->slot);
>  		writel(val, pcie->base + PCIE_SYS_CFG_V2);
> +	} else if (pcie->cfg) {
> +		val = PCIE_CSR_LTSSM_EN(port->slot) |
> +		      PCIE_CSR_ASPM_L1_EN(port->slot);
> +		regmap_update_bits(pcie->cfg, PCIE_SYS_CFG_V2, val, val);
>  	}
>  
>  	/* Assert all reset signals */
> @@ -983,6 +995,7 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
>  	struct device *dev = pcie->dev;
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct resource *regs;
> +	struct device_node *cfg_node;
>  	int err;
>  
>  	/* get shared registers, which are optional */
> @@ -995,6 +1008,14 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie)
>  		}
>  	}
>  
> +	cfg_node = of_find_compatible_node(NULL, NULL,
> +					   "mediatek,generic-pciecfg");
> +	if (cfg_node) {
> +		pcie->cfg = syscon_node_to_regmap(cfg_node);
> +		if (IS_ERR(pcie->cfg))
> +			return PTR_ERR(pcie->cfg);
> +	}
> +
>  	pcie->free_ck = devm_clk_get(dev, "free_ck");
>  	if (IS_ERR(pcie->free_ck)) {
>  		if (PTR_ERR(pcie->free_ck) == -EPROBE_DEFER)
> @@ -1027,22 +1048,27 @@ static int mtk_pcie_setup(struct mtk_pcie *pcie)
>  	struct device *dev = pcie->dev;
>  	struct device_node *node = dev->of_node, *child;
>  	struct mtk_pcie_port *port, *tmp;
> -	int err;
> +	int err, slot;
> +
> +	slot = of_get_pci_domain_nr(dev->of_node);
> +	if (slot < 0) {
> +		for_each_available_child_of_node(node, child) {
> +			err = of_pci_get_devfn(child);
> +			if (err < 0) {
> +				dev_err(dev, "failed to get devfn: %d\n", err);
> +				goto error_put_node;
> +			}
>  
> -	for_each_available_child_of_node(node, child) {
> -		int slot;
> +			slot = PCI_SLOT(err);
>  
> -		err = of_pci_get_devfn(child);
> -		if (err < 0) {
> -			dev_err(dev, "failed to parse devfn: %d\n", err);
> -			goto error_put_node;
> +			err = mtk_pcie_parse_port(pcie, child, slot);
> +			if (err)
> +				goto error_put_node;
>  		}
> -
> -		slot = PCI_SLOT(err);
> -
> -		err = mtk_pcie_parse_port(pcie, child, slot);
> +	} else {
> +		err = mtk_pcie_parse_port(pcie, node, slot);
>  		if (err)
> -			goto error_put_node;
> +			return err;
>  	}
>  
>  	err = mtk_pcie_subsys_powerup(pcie);


From sean.wang at kernel.org  Tue Apr 20 04:46:39 2021
From: sean.wang at kernel.org (Sean Wang)
Date: Mon, 19 Apr 2021 20:46:39 -0700
Subject: [PATCH v4 2/4] pinctrl: add pinctrl driver on mt8195
In-Reply-To: <20210413055702.27535-3-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <20210413055702.27535-3-zhiyong.tao@mediatek.com>
Message-ID: <CAGp9LzqiX1ZjcHr396=pq=wyo=C76dyMqjf6m_s5yU9Fo74tHQ@mail.gmail.com>

On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:
>
> This commit includes pinctrl driver for mt8195.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>

Acked-by: Sean Wang <sean.wang at kernel.org>

> ---
>  drivers/pinctrl/mediatek/Kconfig              |    6 +
>  drivers/pinctrl/mediatek/Makefile             |    1 +
>  drivers/pinctrl/mediatek/pinctrl-mt8195.c     |  828 ++++++++
>  drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h | 1669 +++++++++++++++++
>  4 files changed, 2504 insertions(+)
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8195.c
>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
> index eef17f228669..90f0c8255eaf 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -147,6 +147,12 @@ config PINCTRL_MT8192
>         default ARM64 && ARCH_MEDIATEK
>         select PINCTRL_MTK_PARIS
>
> +config PINCTRL_MT8195
> +       bool "Mediatek MT8195 pin control"
> +       depends on OF
> +       depends on ARM64 || COMPILE_TEST
> +       select PINCTRL_MTK_PARIS
> +
>  config PINCTRL_MT8516
>         bool "Mediatek MT8516 pin control"
>         depends on OF
> diff --git a/drivers/pinctrl/mediatek/Makefile b/drivers/pinctrl/mediatek/Makefile
> index 01218bf4dc30..06fde993ace2 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -21,5 +21,6 @@ obj-$(CONFIG_PINCTRL_MT8167)  += pinctrl-mt8167.o
>  obj-$(CONFIG_PINCTRL_MT8173)   += pinctrl-mt8173.o
>  obj-$(CONFIG_PINCTRL_MT8183)   += pinctrl-mt8183.o
>  obj-$(CONFIG_PINCTRL_MT8192)   += pinctrl-mt8192.o
> +obj-$(CONFIG_PINCTRL_MT8195)    += pinctrl-mt8195.o
>  obj-$(CONFIG_PINCTRL_MT8516)   += pinctrl-mt8516.o
>  obj-$(CONFIG_PINCTRL_MT6397)   += pinctrl-mt6397.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> new file mode 100644
> index 000000000000..063f164d7c9b
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> @@ -0,0 +1,828 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + *
> + * Author: Zhiyong Tao <zhiyong.tao at mediatek.com>
> + *
> + */
> +
> +#include "pinctrl-mtk-mt8195.h"
> +#include "pinctrl-paris.h"
> +
> +/* MT8195 have multiple bases to program pin configuration listed as the below:
> + * iocfg[0]:0x10005000, iocfg[1]:0x11d10000, iocfg[2]:0x11d30000,
> + * iocfg[3]:0x11d40000, iocfg[4]:0x11e20000, iocfg[5]:0x11eb0000,
> + * iocfg[6]:0x11f40000.
> + * _i_based could be used to indicate what base the pin should be mapped into.
> + */
> +
> +#define PIN_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits) \
> +       PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits, \
> +                      32, 0)
> +
> +#define PINS_FIELD_BASE(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits) \
> +       PIN_FIELD_CALC(s_pin, e_pin, i_base, s_addr, x_addrs, s_bit, x_bits,  \
> +                      32, 1)
> +
> +static const struct mtk_pin_field_calc mt8195_pin_mode_range[] = {
> +       PIN_FIELD(0, 144, 0x300, 0x10, 0, 4),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_dir_range[] = {
> +       PIN_FIELD(0, 144, 0x0, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_di_range[] = {
> +       PIN_FIELD(0, 144, 0x200, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_do_range[] = {
> +       PIN_FIELD(0, 144, 0x100, 0x10, 0, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_ies_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x040, 0x10, 0, 1),
> +       PIN_FIELD_BASE(1, 1, 4, 0x040, 0x10, 1, 1),
> +       PIN_FIELD_BASE(2, 2, 4, 0x040, 0x10, 2, 1),
> +       PIN_FIELD_BASE(3, 3, 4, 0x040, 0x10, 3, 1),
> +       PIN_FIELD_BASE(4, 4, 4, 0x040, 0x10, 4, 1),
> +       PIN_FIELD_BASE(5, 5, 4, 0x040, 0x10, 5, 1),
> +       PIN_FIELD_BASE(6, 6, 4, 0x040, 0x10, 6, 1),
> +       PIN_FIELD_BASE(7, 7, 4, 0x040, 0x10, 7, 1),
> +       PIN_FIELD_BASE(8, 8, 4, 0x040, 0x10, 13, 1),
> +       PIN_FIELD_BASE(9, 9, 4, 0x040, 0x10, 8, 1),
> +       PIN_FIELD_BASE(10, 10, 4, 0x040, 0x10, 14, 1),
> +       PIN_FIELD_BASE(11, 11, 4, 0x040, 0x10, 9, 1),
> +       PIN_FIELD_BASE(12, 12, 4, 0x040, 0x10, 15, 1),
> +       PIN_FIELD_BASE(13, 13, 4, 0x040, 0x10, 10, 1),
> +       PIN_FIELD_BASE(14, 14, 4, 0x040, 0x10, 16, 1),
> +       PIN_FIELD_BASE(15, 15, 4, 0x040, 0x10, 11, 1),
> +       PIN_FIELD_BASE(16, 16, 4, 0x040, 0x10, 17, 1),
> +       PIN_FIELD_BASE(17, 17, 4, 0x040, 0x10, 12, 1),
> +       PIN_FIELD_BASE(18, 18, 2, 0x040, 0x10, 5, 1),
> +       PIN_FIELD_BASE(19, 19, 2, 0x040, 0x10, 12, 1),
> +       PIN_FIELD_BASE(20, 20, 2, 0x040, 0x10, 11, 1),
> +       PIN_FIELD_BASE(21, 21, 2, 0x040, 0x10, 10, 1),
> +       PIN_FIELD_BASE(22, 22, 2, 0x040, 0x10, 0, 1),
> +       PIN_FIELD_BASE(23, 23, 2, 0x040, 0x10, 1, 1),
> +       PIN_FIELD_BASE(24, 24, 2, 0x040, 0x10, 2, 1),
> +       PIN_FIELD_BASE(25, 25, 2, 0x040, 0x10, 4, 1),
> +       PIN_FIELD_BASE(26, 26, 2, 0x040, 0x10, 3, 1),
> +       PIN_FIELD_BASE(27, 27, 2, 0x040, 0x10, 6, 1),
> +       PIN_FIELD_BASE(28, 28, 2, 0x040, 0x10, 7, 1),
> +       PIN_FIELD_BASE(29, 29, 2, 0x040, 0x10, 8, 1),
> +       PIN_FIELD_BASE(30, 30, 2, 0x040, 0x10, 9, 1),
> +       PIN_FIELD_BASE(31, 31, 1, 0x060, 0x10, 13, 1),
> +       PIN_FIELD_BASE(32, 32, 1, 0x060, 0x10, 12, 1),
> +       PIN_FIELD_BASE(33, 33, 1, 0x060, 0x10, 11, 1),
> +       PIN_FIELD_BASE(34, 34, 1, 0x060, 0x10, 14, 1),
> +       PIN_FIELD_BASE(35, 35, 1, 0x060, 0x10, 15, 1),
> +       PIN_FIELD_BASE(36, 36, 1, 0x070, 0x10, 3, 1),
> +       PIN_FIELD_BASE(37, 37, 1, 0x070, 0x10, 6, 1),
> +       PIN_FIELD_BASE(38, 38, 1, 0x070, 0x10, 4, 1),
> +       PIN_FIELD_BASE(39, 39, 1, 0x070, 0x10, 5, 1),
> +       PIN_FIELD_BASE(40, 40, 1, 0x070, 0x10, 8, 1),
> +       PIN_FIELD_BASE(41, 41, 1, 0x070, 0x10, 7, 1),
> +       PIN_FIELD_BASE(42, 42, 1, 0x070, 0x10, 10, 1),
> +       PIN_FIELD_BASE(43, 43, 1, 0x070, 0x10, 9, 1),
> +       PIN_FIELD_BASE(44, 44, 1, 0x070, 0x10, 20, 1),
> +       PIN_FIELD_BASE(45, 45, 1, 0x070, 0x10, 21, 1),
> +       PIN_FIELD_BASE(46, 46, 1, 0x060, 0x10, 18, 1),
> +       PIN_FIELD_BASE(47, 47, 1, 0x060, 0x10, 16, 1),
> +       PIN_FIELD_BASE(48, 48, 1, 0x060, 0x10, 19, 1),
> +       PIN_FIELD_BASE(49, 49, 1, 0x060, 0x10, 17, 1),
> +       PIN_FIELD_BASE(50, 50, 1, 0x060, 0x10, 25, 1),
> +       PIN_FIELD_BASE(51, 51, 1, 0x060, 0x10, 20, 1),
> +       PIN_FIELD_BASE(52, 52, 1, 0x060, 0x10, 26, 1),
> +       PIN_FIELD_BASE(53, 53, 1, 0x060, 0x10, 21, 1),
> +       PIN_FIELD_BASE(54, 54, 1, 0x060, 0x10, 22, 1),
> +       PIN_FIELD_BASE(55, 55, 1, 0x060, 0x10, 23, 1),
> +       PIN_FIELD_BASE(56, 56, 1, 0x060, 0x10, 24, 1),
> +       PIN_FIELD_BASE(57, 57, 1, 0x060, 0x10, 29, 1),
> +       PIN_FIELD_BASE(58, 58, 1, 0x060, 0x10, 27, 1),
> +       PIN_FIELD_BASE(59, 59, 1, 0x060, 0x10, 30, 1),
> +       PIN_FIELD_BASE(60, 60, 1, 0x060, 0x10, 28, 1),
> +       PIN_FIELD_BASE(61, 61, 1, 0x060, 0x10, 8, 1),
> +       PIN_FIELD_BASE(62, 62, 1, 0x060, 0x10, 7, 1),
> +       PIN_FIELD_BASE(63, 63, 1, 0x060, 0x10, 10, 1),
> +       PIN_FIELD_BASE(64, 64, 1, 0x060, 0x10, 9, 1),
> +       PIN_FIELD_BASE(65, 65, 1, 0x070, 0x10, 1, 1),
> +       PIN_FIELD_BASE(66, 66, 1, 0x060, 0x10, 31, 1),
> +       PIN_FIELD_BASE(67, 67, 1, 0x070, 0x10, 0, 1),
> +       PIN_FIELD_BASE(68, 68, 1, 0x070, 0x10, 2, 1),
> +       PIN_FIELD_BASE(69, 69, 1, 0x060, 0x10, 0, 1),
> +       PIN_FIELD_BASE(70, 70, 1, 0x060, 0x10, 6, 1),
> +       PIN_FIELD_BASE(71, 71, 1, 0x060, 0x10, 4, 1),
> +       PIN_FIELD_BASE(72, 72, 1, 0x060, 0x10, 5, 1),
> +       PIN_FIELD_BASE(73, 73, 1, 0x060, 0x10, 1, 1),
> +       PIN_FIELD_BASE(74, 74, 1, 0x060, 0x10, 2, 1),
> +       PIN_FIELD_BASE(75, 75, 1, 0x060, 0x10, 3, 1),
> +       PIN_FIELD_BASE(76, 76, 1, 0x070, 0x10, 11, 1),
> +       PIN_FIELD_BASE(77, 77, 3, 0x030, 0x10, 1, 1),
> +       PIN_FIELD_BASE(78, 78, 3, 0x030, 0x10, 2, 1),
> +       PIN_FIELD_BASE(79, 79, 3, 0x030, 0x10, 9, 1),
> +       PIN_FIELD_BASE(80, 80, 3, 0x030, 0x10, 10, 1),
> +       PIN_FIELD_BASE(81, 81, 3, 0x030, 0x10, 11, 1),
> +       PIN_FIELD_BASE(82, 82, 3, 0x030, 0x10, 12, 1),
> +       PIN_FIELD_BASE(83, 83, 3, 0x030, 0x10, 13, 1),
> +       PIN_FIELD_BASE(84, 84, 3, 0x030, 0x10, 14, 1),
> +       PIN_FIELD_BASE(85, 85, 3, 0x030, 0x10, 15, 1),
> +       PIN_FIELD_BASE(86, 86, 3, 0x030, 0x10, 16, 1),
> +       PIN_FIELD_BASE(87, 87, 3, 0x030, 0x10, 3, 1),
> +       PIN_FIELD_BASE(88, 88, 3, 0x030, 0x10, 4, 1),
> +       PIN_FIELD_BASE(89, 89, 3, 0x030, 0x10, 5, 1),
> +       PIN_FIELD_BASE(90, 90, 3, 0x030, 0x10, 6, 1),
> +       PIN_FIELD_BASE(91, 91, 3, 0x030, 0x10, 7, 1),
> +       PIN_FIELD_BASE(92, 92, 3, 0x030, 0x10, 8, 1),
> +       PIN_FIELD_BASE(93, 93, 3, 0x030, 0x10, 18, 1),
> +       PIN_FIELD_BASE(94, 94, 3, 0x030, 0x10, 19, 1),
> +       PIN_FIELD_BASE(95, 95, 3, 0x030, 0x10, 17, 1),
> +       PIN_FIELD_BASE(96, 96, 3, 0x030, 0x10, 0, 1),
> +       PIN_FIELD_BASE(97, 97, 3, 0x030, 0x10, 20, 1),
> +       PIN_FIELD_BASE(98, 98, 3, 0x030, 0x10, 28, 1),
> +       PIN_FIELD_BASE(99, 99, 3, 0x030, 0x10, 27, 1),
> +       PIN_FIELD_BASE(100, 100, 3, 0x030, 0x10, 30, 1),
> +       PIN_FIELD_BASE(101, 101, 3, 0x030, 0x10, 29, 1),
> +       PIN_FIELD_BASE(102, 102, 3, 0x040, 0x10, 0, 1),
> +       PIN_FIELD_BASE(103, 103, 3, 0x030, 0x10, 31, 1),
> +       PIN_FIELD_BASE(104, 104, 3, 0x030, 0x10, 25, 1),
> +       PIN_FIELD_BASE(105, 105, 3, 0x030, 0x10, 26, 1),
> +       PIN_FIELD_BASE(106, 106, 3, 0x030, 0x10, 23, 1),
> +       PIN_FIELD_BASE(107, 107, 3, 0x030, 0x10, 24, 1),
> +       PIN_FIELD_BASE(108, 108, 3, 0x030, 0x10, 22, 1),
> +       PIN_FIELD_BASE(109, 109, 3, 0x030, 0x10, 21, 1),
> +       PIN_FIELD_BASE(110, 110, 5, 0x010, 0x10, 1, 1),
> +       PIN_FIELD_BASE(111, 111, 5, 0x010, 0x10, 0, 1),
> +       PIN_FIELD_BASE(112, 112, 5, 0x010, 0x10, 2, 1),
> +       PIN_FIELD_BASE(113, 113, 5, 0x010, 0x10, 3, 1),
> +       PIN_FIELD_BASE(114, 114, 5, 0x010, 0x10, 4, 1),
> +       PIN_FIELD_BASE(115, 115, 5, 0x010, 0x10, 5, 1),
> +       PIN_FIELD_BASE(116, 116, 6, 0x030, 0x10, 9, 1),
> +       PIN_FIELD_BASE(117, 117, 6, 0x030, 0x10, 8, 1),
> +       PIN_FIELD_BASE(118, 118, 6, 0x030, 0x10, 7, 1),
> +       PIN_FIELD_BASE(119, 119, 6, 0x030, 0x10, 6, 1),
> +       PIN_FIELD_BASE(120, 120, 6, 0x030, 0x10, 11, 1),
> +       PIN_FIELD_BASE(121, 121, 6, 0x030, 0x10, 1, 1),
> +       PIN_FIELD_BASE(122, 122, 6, 0x030, 0x10, 0, 1),
> +       PIN_FIELD_BASE(123, 123, 6, 0x030, 0x10, 5, 1),
> +       PIN_FIELD_BASE(124, 124, 6, 0x030, 0x10, 4, 1),
> +       PIN_FIELD_BASE(125, 125, 6, 0x030, 0x10, 3, 1),
> +       PIN_FIELD_BASE(126, 126, 6, 0x030, 0x10, 2, 1),
> +       PIN_FIELD_BASE(127, 127, 6, 0x030, 0x10, 10, 1),
> +       PIN_FIELD_BASE(128, 128, 3, 0x040, 0x10, 3, 1),
> +       PIN_FIELD_BASE(129, 129, 3, 0x040, 0x10, 1, 1),
> +       PIN_FIELD_BASE(130, 130, 3, 0x040, 0x10, 4, 1),
> +       PIN_FIELD_BASE(131, 131, 3, 0x040, 0x10, 2, 1),
> +       PIN_FIELD_BASE(132, 132, 6, 0x030, 0x10, 13, 1),
> +       PIN_FIELD_BASE(133, 133, 6, 0x030, 0x10, 12, 1),
> +       PIN_FIELD_BASE(134, 134, 6, 0x030, 0x10, 15, 1),
> +       PIN_FIELD_BASE(135, 135, 6, 0x030, 0x10, 14, 1),
> +       PIN_FIELD_BASE(136, 136, 1, 0x070, 0x10, 13, 1),
> +       PIN_FIELD_BASE(137, 137, 1, 0x070, 0x10, 12, 1),
> +       PIN_FIELD_BASE(138, 138, 1, 0x070, 0x10, 15, 1),
> +       PIN_FIELD_BASE(139, 139, 1, 0x070, 0x10, 14, 1),
> +       PIN_FIELD_BASE(140, 140, 1, 0x070, 0x10, 17, 1),
> +       PIN_FIELD_BASE(141, 141, 1, 0x070, 0x10, 16, 1),
> +       PIN_FIELD_BASE(142, 142, 1, 0x070, 0x10, 19, 1),
> +       PIN_FIELD_BASE(143, 143, 1, 0x070, 0x10, 18, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_smt_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x0d0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(1, 1, 4, 0x0d0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(2, 2, 4, 0x0d0, 0x10, 2, 1),
> +       PIN_FIELD_BASE(3, 3, 4, 0x0d0, 0x10, 3, 1),
> +       PIN_FIELD_BASE(4, 4, 4, 0x0d0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(5, 5, 4, 0x0d0, 0x10, 5, 1),
> +       PINS_FIELD_BASE(6, 7, 4, 0x0d0, 0x10, 6, 1),
> +       PIN_FIELD_BASE(8, 8, 4, 0x0d0, 0x10, 12, 1),
> +       PIN_FIELD_BASE(9, 9, 4, 0x0d0, 0x10, 7, 1),
> +       PIN_FIELD_BASE(10, 10, 4, 0x0d0, 0x10, 13, 1),
> +       PIN_FIELD_BASE(11, 11, 4, 0x0d0, 0x10, 8, 1),
> +       PIN_FIELD_BASE(12, 12, 4, 0x0d0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(13, 13, 4, 0x0d0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(14, 14, 4, 0x0d0, 0x10, 15, 1),
> +       PIN_FIELD_BASE(15, 15, 4, 0x0d0, 0x10, 10, 1),
> +       PIN_FIELD_BASE(16, 16, 4, 0x0d0, 0x10, 16, 1),
> +       PIN_FIELD_BASE(17, 17, 4, 0x0d0, 0x10, 11, 1),
> +       PIN_FIELD_BASE(18, 18, 2, 0x090, 0x10, 11, 1),
> +       PIN_FIELD_BASE(19, 19, 2, 0x090, 0x10, 10, 1),
> +       PIN_FIELD_BASE(20, 20, 2, 0x090, 0x10, 9, 1),
> +       PIN_FIELD_BASE(21, 21, 2, 0x090, 0x10, 11, 1),
> +       PIN_FIELD_BASE(22, 22, 2, 0x090, 0x10, 0, 1),
> +       PIN_FIELD_BASE(23, 23, 2, 0x090, 0x10, 1, 1),
> +       PIN_FIELD_BASE(24, 24, 2, 0x090, 0x10, 2, 1),
> +       PIN_FIELD_BASE(25, 25, 2, 0x090, 0x10, 4, 1),
> +       PIN_FIELD_BASE(26, 26, 2, 0x090, 0x10, 3, 1),
> +       PIN_FIELD_BASE(27, 27, 2, 0x090, 0x10, 5, 1),
> +       PIN_FIELD_BASE(28, 28, 2, 0x090, 0x10, 6, 1),
> +       PIN_FIELD_BASE(29, 29, 2, 0x090, 0x10, 7, 1),
> +       PIN_FIELD_BASE(30, 30, 2, 0x090, 0x10, 8, 1),
> +       PINS_FIELD_BASE(31, 33, 1, 0x0f0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(34, 34, 1, 0x0f0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(35, 35, 1, 0x0f0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(36, 36, 1, 0x0f0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(37, 37, 1, 0x0f0, 0x10, 2, 1),
> +       PINS_FIELD_BASE(38, 39, 1, 0x0f0, 0x10, 5, 1),
> +       PIN_FIELD_BASE(40, 40, 1, 0x0f0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(41, 41, 1, 0x0f0, 0x10, 13, 1),
> +       PIN_FIELD_BASE(42, 42, 1, 0x0f0, 0x10, 16, 1),
> +       PIN_FIELD_BASE(43, 43, 1, 0x0f0, 0x10, 15, 1),
> +       PIN_FIELD_BASE(44, 44, 1, 0x0f0, 0x10, 25, 1),
> +       PIN_FIELD_BASE(45, 45, 1, 0x0f0, 0x10, 26, 1),
> +       PINS_FIELD_BASE(46, 47, 1, 0x0f0, 0x10, 5, 1),
> +       PINS_FIELD_BASE(48, 51, 1, 0x0f0, 0x10, 6, 1),
> +       PINS_FIELD_BASE(52, 55, 1, 0x0f0, 0x10, 7, 1),
> +       PINS_FIELD_BASE(56, 59, 1, 0x0f0, 0x10, 8, 1),
> +       PINS_FIELD_BASE(60, 63, 1, 0x0f0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(64, 64, 1, 0x0f0, 0x10, 10, 1),
> +       PINS_FIELD_BASE(65, 68, 1, 0x0f0, 0x10, 3, 1),
> +       PINS_FIELD_BASE(69, 71, 1, 0x0f0, 0x10, 10, 1),
> +       PINS_FIELD_BASE(72, 75, 1, 0x0f0, 0x10, 11, 1),
> +       PIN_FIELD_BASE(76, 76, 1, 0x0f0, 0x10, 12, 1),
> +       PIN_FIELD_BASE(77, 77, 3, 0x0e0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(78, 78, 3, 0x0e0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(79, 79, 3, 0x0e0, 0x10, 6, 1),
> +       PIN_FIELD_BASE(80, 80, 3, 0x0e0, 0x10, 7, 1),
> +       PIN_FIELD_BASE(81, 81, 3, 0x0e0, 0x10, 8, 1),
> +       PIN_FIELD_BASE(82, 82, 3, 0x0e0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(83, 83, 3, 0x0e0, 0x10, 10, 1),
> +       PIN_FIELD_BASE(84, 84, 3, 0x0e0, 0x10, 11, 1),
> +       PINS_FIELD_BASE(85, 88, 3, 0x0e0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(89, 89, 3, 0x0e0, 0x10, 2, 1),
> +       PIN_FIELD_BASE(90, 90, 3, 0x0e0, 0x10, 3, 1),
> +       PIN_FIELD_BASE(91, 91, 3, 0x0e0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(92, 92, 3, 0x0e0, 0x10, 5, 1),
> +       PIN_FIELD_BASE(93, 93, 3, 0x0e0, 0x10, 12, 1),
> +       PIN_FIELD_BASE(94, 94, 3, 0x0e0, 0x10, 13, 1),
> +       PINS_FIELD_BASE(95, 98, 3, 0x0e0, 0x10, 15, 1),
> +       PINS_FIELD_BASE(99, 102, 3, 0x0e0, 0x10, 16, 1),
> +       PINS_FIELD_BASE(103, 104, 3, 0x0e0, 0x10, 17, 1),
> +       PIN_FIELD_BASE(105, 105, 3, 0x0e0, 0x10, 18, 1),
> +       PINS_FIELD_BASE(106, 107, 3, 0x0e0, 0x10, 17, 1),
> +       PINS_FIELD_BASE(108, 109, 3, 0x0e0, 0x10, 18, 1),
> +       PIN_FIELD_BASE(110, 110, 5, 0x070, 0x10, 1, 1),
> +       PIN_FIELD_BASE(111, 111, 5, 0x070, 0x10, 0, 1),
> +       PIN_FIELD_BASE(112, 112, 5, 0x070, 0x10, 2, 1),
> +       PIN_FIELD_BASE(113, 113, 5, 0x070, 0x10, 3, 1),
> +       PIN_FIELD_BASE(114, 114, 5, 0x070, 0x10, 4, 1),
> +       PIN_FIELD_BASE(115, 115, 5, 0x070, 0x10, 5, 1),
> +       PIN_FIELD_BASE(116, 116, 6, 0x0c0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(117, 117, 6, 0x0c0, 0x10, 8, 1),
> +       PIN_FIELD_BASE(118, 118, 6, 0x0c0, 0x10, 7, 1),
> +       PIN_FIELD_BASE(119, 119, 6, 0x0c0, 0x10, 6, 1),
> +       PIN_FIELD_BASE(120, 120, 6, 0x0c0, 0x10, 11, 1),
> +       PIN_FIELD_BASE(121, 121, 6, 0x0c0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(122, 122, 6, 0x0c0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(123, 123, 6, 0x0c0, 0x10, 5, 1),
> +       PIN_FIELD_BASE(124, 124, 6, 0x0c0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(125, 125, 6, 0x0c0, 0x10, 3, 1),
> +       PIN_FIELD_BASE(126, 126, 6, 0x0c0, 0x10, 2, 1),
> +       PIN_FIELD_BASE(127, 127, 6, 0x0c0, 0x10, 10, 1),
> +       PIN_FIELD_BASE(128, 128, 3, 0x0e0, 0x10, 18, 1),
> +       PINS_FIELD_BASE(129, 131, 3, 0x0e0, 0x10, 19, 1),
> +       PIN_FIELD_BASE(132, 132, 6, 0x0c0, 0x10, 13, 1),
> +       PIN_FIELD_BASE(133, 133, 6, 0x0c0, 0x10, 12, 1),
> +       PIN_FIELD_BASE(134, 134, 6, 0x0c0, 0x10, 15, 1),
> +       PIN_FIELD_BASE(135, 135, 6, 0x0c0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(136, 136, 1, 0x0f0, 0x10, 18, 1),
> +       PIN_FIELD_BASE(137, 137, 1, 0x0f0, 0x10, 17, 1),
> +       PIN_FIELD_BASE(138, 138, 1, 0x0f0, 0x10, 20, 1),
> +       PIN_FIELD_BASE(139, 139, 1, 0x0f0, 0x10, 19, 1),
> +       PIN_FIELD_BASE(140, 140, 1, 0x0f0, 0x10, 22, 1),
> +       PIN_FIELD_BASE(141, 141, 1, 0x0f0, 0x10, 21, 1),
> +       PIN_FIELD_BASE(142, 142, 1, 0x0f0, 0x10, 24, 1),
> +       PIN_FIELD_BASE(143, 143, 1, 0x0f0, 0x10, 23, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_pu_range[] = {
> +       PIN_FIELD_BASE(6, 6, 4, 0x0070, 0x10, 0, 1),
> +       PIN_FIELD_BASE(7, 7, 4, 0x0070, 0x10, 1, 1),
> +       PIN_FIELD_BASE(8, 8, 4, 0x0070, 0x10, 7, 1),
> +       PIN_FIELD_BASE(9, 9, 4, 0x0070, 0x10, 2, 1),
> +       PIN_FIELD_BASE(10, 10, 4, 0x0070, 0x10, 8, 1),
> +       PIN_FIELD_BASE(11, 11, 4, 0x0070, 0x10, 3, 1),
> +       PIN_FIELD_BASE(12, 12, 4, 0x0070, 0x10, 9, 1),
> +       PIN_FIELD_BASE(13, 13, 4, 0x0070, 0x10, 4, 1),
> +       PIN_FIELD_BASE(14, 14, 4, 0x0070, 0x10, 10, 1),
> +       PIN_FIELD_BASE(15, 15, 4, 0x0070, 0x10, 5, 1),
> +       PIN_FIELD_BASE(16, 16, 4, 0x0070, 0x10, 11, 1),
> +       PIN_FIELD_BASE(17, 17, 4, 0x0070, 0x10, 6, 1),
> +       PIN_FIELD_BASE(18, 18, 2, 0x0060, 0x10, 5, 1),
> +       PIN_FIELD_BASE(19, 19, 2, 0x0060, 0x10, 12, 1),
> +       PIN_FIELD_BASE(20, 20, 2, 0x0060, 0x10, 11, 1),
> +       PIN_FIELD_BASE(21, 21, 2, 0x0060, 0x10, 10, 1),
> +       PIN_FIELD_BASE(22, 22, 2, 0x0060, 0x10, 0, 1),
> +       PIN_FIELD_BASE(23, 23, 2, 0x0060, 0x10, 1, 1),
> +       PIN_FIELD_BASE(24, 24, 2, 0x0060, 0x10, 2, 1),
> +       PIN_FIELD_BASE(25, 25, 2, 0x0060, 0x10, 4, 1),
> +       PIN_FIELD_BASE(26, 26, 2, 0x0060, 0x10, 3, 1),
> +       PIN_FIELD_BASE(27, 27, 2, 0x0060, 0x10, 6, 1),
> +       PIN_FIELD_BASE(28, 28, 2, 0x0060, 0x10, 7, 1),
> +       PIN_FIELD_BASE(29, 29, 2, 0x0060, 0x10, 8, 1),
> +       PIN_FIELD_BASE(30, 30, 2, 0x0060, 0x10, 9, 1),
> +       PIN_FIELD_BASE(31, 31, 1, 0x00a0, 0x10, 13, 1),
> +       PIN_FIELD_BASE(32, 32, 1, 0x00a0, 0x10, 12, 1),
> +       PIN_FIELD_BASE(33, 33, 1, 0x00a0, 0x10, 11, 1),
> +       PIN_FIELD_BASE(34, 34, 1, 0x00a0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(35, 35, 1, 0x00a0, 0x10, 15, 1),
> +       PIN_FIELD_BASE(36, 36, 1, 0x00b0, 0x10, 3, 1),
> +       PIN_FIELD_BASE(37, 37, 1, 0x00b0, 0x10, 6, 1),
> +       PIN_FIELD_BASE(38, 38, 1, 0x00b0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(39, 39, 1, 0x00b0, 0x10, 5, 1),
> +       PIN_FIELD_BASE(40, 40, 1, 0x00b0, 0x10, 8, 1),
> +       PIN_FIELD_BASE(41, 41, 1, 0x00b0, 0x10, 7, 1),
> +       PIN_FIELD_BASE(42, 42, 1, 0x00b0, 0x10, 10, 1),
> +       PIN_FIELD_BASE(43, 43, 1, 0x00b0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(44, 44, 1, 0x00b0, 0x10, 21, 1),
> +       PIN_FIELD_BASE(45, 45, 1, 0x00b0, 0x10, 22, 1),
> +       PIN_FIELD_BASE(46, 46, 1, 0x00a0, 0x10, 18, 1),
> +       PIN_FIELD_BASE(47, 47, 1, 0x00a0, 0x10, 16, 1),
> +       PIN_FIELD_BASE(48, 48, 1, 0x00a0, 0x10, 19, 1),
> +       PIN_FIELD_BASE(49, 49, 1, 0x00a0, 0x10, 17, 1),
> +       PIN_FIELD_BASE(50, 50, 1, 0x00a0, 0x10, 25, 1),
> +       PIN_FIELD_BASE(51, 51, 1, 0x00a0, 0x10, 20, 1),
> +       PIN_FIELD_BASE(52, 52, 1, 0x00a0, 0x10, 26, 1),
> +       PIN_FIELD_BASE(53, 53, 1, 0x00a0, 0x10, 21, 1),
> +       PIN_FIELD_BASE(54, 54, 1, 0x00a0, 0x10, 22, 1),
> +       PIN_FIELD_BASE(55, 55, 1, 0x00a0, 0x10, 23, 1),
> +       PIN_FIELD_BASE(56, 56, 1, 0x00a0, 0x10, 24, 1),
> +       PIN_FIELD_BASE(57, 57, 1, 0x00a0, 0x10, 29, 1),
> +       PIN_FIELD_BASE(58, 58, 1, 0x00a0, 0x10, 27, 1),
> +       PIN_FIELD_BASE(59, 59, 1, 0x00a0, 0x10, 30, 1),
> +       PIN_FIELD_BASE(60, 60, 1, 0x00a0, 0x10, 28, 1),
> +       PIN_FIELD_BASE(61, 61, 1, 0x00a0, 0x10, 8, 1),
> +       PIN_FIELD_BASE(62, 62, 1, 0x00a0, 0x10, 7, 1),
> +       PIN_FIELD_BASE(63, 63, 1, 0x00a0, 0x10, 10, 1),
> +       PIN_FIELD_BASE(64, 64, 1, 0x00a0, 0x10, 9, 1),
> +       PIN_FIELD_BASE(65, 65, 1, 0x00b0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(66, 66, 1, 0x00a0, 0x10, 31, 1),
> +       PIN_FIELD_BASE(67, 67, 1, 0x00b0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(68, 68, 1, 0x00b0, 0x10, 2, 1),
> +       PIN_FIELD_BASE(69, 69, 1, 0x00a0, 0x10, 0, 1),
> +       PIN_FIELD_BASE(70, 70, 1, 0x00a0, 0x10, 6, 1),
> +       PIN_FIELD_BASE(71, 71, 1, 0x00a0, 0x10, 4, 1),
> +       PIN_FIELD_BASE(72, 72, 1, 0x00a0, 0x10, 5, 1),
> +       PIN_FIELD_BASE(73, 73, 1, 0x00a0, 0x10, 1, 1),
> +       PIN_FIELD_BASE(74, 74, 1, 0x00a0, 0x10, 2, 1),
> +       PIN_FIELD_BASE(75, 75, 1, 0x00a0, 0x10, 3, 1),
> +       PIN_FIELD_BASE(76, 76, 1, 0x00b0, 0x10, 11, 1),
> +       PIN_FIELD_BASE(97, 97, 3, 0x0070, 0x10, 0, 1),
> +       PIN_FIELD_BASE(98, 98, 3, 0x0070, 0x10, 4, 1),
> +       PIN_FIELD_BASE(99, 99, 3, 0x0070, 0x10, 3, 1),
> +       PIN_FIELD_BASE(100, 100, 3, 0x0070, 0x10, 6, 1),
> +       PIN_FIELD_BASE(101, 101, 3, 0x0070, 0x10, 5, 1),
> +       PIN_FIELD_BASE(102, 102, 3, 0x0070, 0x10, 8, 1),
> +       PIN_FIELD_BASE(103, 103, 3, 0x0070, 0x10, 7, 1),
> +       PIN_FIELD_BASE(108, 108, 3, 0x0070, 0x10, 2, 1),
> +       PIN_FIELD_BASE(109, 109, 3, 0x0070, 0x10, 1, 1),
> +       PIN_FIELD_BASE(128, 128, 3, 0x0070, 0x10, 11, 1),
> +       PIN_FIELD_BASE(129, 129, 3, 0x0070, 0x10, 9, 1),
> +       PIN_FIELD_BASE(130, 130, 3, 0x0070, 0x10, 12, 1),
> +       PIN_FIELD_BASE(131, 131, 3, 0x0070, 0x10, 10, 1),
> +       PIN_FIELD_BASE(132, 132, 6, 0x0060, 0x10, 1, 1),
> +       PIN_FIELD_BASE(133, 133, 6, 0x0060, 0x10, 0, 1),
> +       PIN_FIELD_BASE(134, 134, 6, 0x0060, 0x10, 3, 1),
> +       PIN_FIELD_BASE(135, 135, 6, 0x0060, 0x10, 2, 1),
> +       PIN_FIELD_BASE(136, 136, 1, 0x00b0, 0x10, 14, 1),
> +       PIN_FIELD_BASE(137, 137, 1, 0x00b0, 0x10, 13, 1),
> +       PIN_FIELD_BASE(138, 138, 1, 0x00b0, 0x10, 16, 1),
> +       PIN_FIELD_BASE(139, 139, 1, 0x00b0, 0x10, 15, 1),
> +       PIN_FIELD_BASE(140, 140, 1, 0x00b0, 0x10, 18, 1),
> +       PIN_FIELD_BASE(141, 141, 1, 0x00b0, 0x10, 17, 1),
> +       PIN_FIELD_BASE(142, 142, 1, 0x00b0, 0x10, 20, 1),
> +       PIN_FIELD_BASE(143, 143, 1, 0x00b0, 0x10, 19, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_pd_range[] = {
> +       PIN_FIELD_BASE(6, 6, 4, 0x0050, 0x10, 0, 1),
> +       PIN_FIELD_BASE(7, 7, 4, 0x0050, 0x10, 1, 1),
> +       PIN_FIELD_BASE(8, 8, 4, 0x0050, 0x10, 7, 1),
> +       PIN_FIELD_BASE(9, 9, 4, 0x0050, 0x10, 2, 1),
> +       PIN_FIELD_BASE(10, 10, 4, 0x0050, 0x10, 8, 1),
> +       PIN_FIELD_BASE(11, 11, 4, 0x0050, 0x10, 3, 1),
> +       PIN_FIELD_BASE(12, 12, 4, 0x0050, 0x10, 9, 1),
> +       PIN_FIELD_BASE(13, 13, 4, 0x0050, 0x10, 4, 1),
> +       PIN_FIELD_BASE(14, 14, 4, 0x0050, 0x10, 10, 1),
> +       PIN_FIELD_BASE(15, 15, 4, 0x0050, 0x10, 5, 1),
> +       PIN_FIELD_BASE(16, 16, 4, 0x0050, 0x10, 11, 1),
> +       PIN_FIELD_BASE(17, 17, 4, 0x0050, 0x10, 6, 1),
> +       PIN_FIELD_BASE(18, 18, 2, 0x0050, 0x10, 5, 1),
> +       PIN_FIELD_BASE(19, 19, 2, 0x0050, 0x10, 12, 1),
> +       PIN_FIELD_BASE(20, 20, 2, 0x0050, 0x10, 11, 1),
> +       PIN_FIELD_BASE(21, 21, 2, 0x0050, 0x10, 10, 1),
> +       PIN_FIELD_BASE(22, 22, 2, 0x0050, 0x10, 0, 1),
> +       PIN_FIELD_BASE(23, 23, 2, 0x0050, 0x10, 1, 1),
> +       PIN_FIELD_BASE(24, 24, 2, 0x0050, 0x10, 2, 1),
> +       PIN_FIELD_BASE(25, 25, 2, 0x0050, 0x10, 4, 1),
> +       PIN_FIELD_BASE(26, 26, 2, 0x0050, 0x10, 3, 1),
> +       PIN_FIELD_BASE(27, 27, 2, 0x0050, 0x10, 6, 1),
> +       PIN_FIELD_BASE(28, 28, 2, 0x0050, 0x10, 7, 1),
> +       PIN_FIELD_BASE(29, 29, 2, 0x0050, 0x10, 8, 1),
> +       PIN_FIELD_BASE(30, 30, 2, 0x0050, 0x10, 9, 1),
> +       PIN_FIELD_BASE(31, 31, 1, 0x0080, 0x10, 13, 1),
> +       PIN_FIELD_BASE(32, 32, 1, 0x0080, 0x10, 12, 1),
> +       PIN_FIELD_BASE(33, 33, 1, 0x0080, 0x10, 11, 1),
> +       PIN_FIELD_BASE(34, 34, 1, 0x0080, 0x10, 14, 1),
> +       PIN_FIELD_BASE(35, 35, 1, 0x0080, 0x10, 15, 1),
> +       PIN_FIELD_BASE(36, 36, 1, 0x0090, 0x10, 3, 1),
> +       PIN_FIELD_BASE(37, 37, 1, 0x0090, 0x10, 6, 1),
> +       PIN_FIELD_BASE(38, 38, 1, 0x0090, 0x10, 4, 1),
> +       PIN_FIELD_BASE(39, 39, 1, 0x0090, 0x10, 5, 1),
> +       PIN_FIELD_BASE(40, 40, 1, 0x0090, 0x10, 8, 1),
> +       PIN_FIELD_BASE(41, 41, 1, 0x0090, 0x10, 7, 1),
> +       PIN_FIELD_BASE(42, 42, 1, 0x0090, 0x10, 10, 1),
> +       PIN_FIELD_BASE(43, 43, 1, 0x0090, 0x10, 9, 1),
> +       PIN_FIELD_BASE(44, 44, 1, 0x0090, 0x10, 21, 1),
> +       PIN_FIELD_BASE(45, 45, 1, 0x0090, 0x10, 22, 1),
> +       PIN_FIELD_BASE(46, 46, 1, 0x0080, 0x10, 18, 1),
> +       PIN_FIELD_BASE(47, 47, 1, 0x0080, 0x10, 16, 1),
> +       PIN_FIELD_BASE(48, 48, 1, 0x0080, 0x10, 19, 1),
> +       PIN_FIELD_BASE(49, 49, 1, 0x0080, 0x10, 17, 1),
> +       PIN_FIELD_BASE(50, 50, 1, 0x0080, 0x10, 25, 1),
> +       PIN_FIELD_BASE(51, 51, 1, 0x0080, 0x10, 20, 1),
> +       PIN_FIELD_BASE(52, 52, 1, 0x0080, 0x10, 26, 1),
> +       PIN_FIELD_BASE(53, 53, 1, 0x0080, 0x10, 21, 1),
> +       PIN_FIELD_BASE(54, 54, 1, 0x0080, 0x10, 22, 1),
> +       PIN_FIELD_BASE(55, 55, 1, 0x0080, 0x10, 23, 1),
> +       PIN_FIELD_BASE(56, 56, 1, 0x0080, 0x10, 24, 1),
> +       PIN_FIELD_BASE(57, 57, 1, 0x0080, 0x10, 29, 1),
> +       PIN_FIELD_BASE(58, 58, 1, 0x0080, 0x10, 27, 1),
> +       PIN_FIELD_BASE(59, 59, 1, 0x0080, 0x10, 30, 1),
> +       PIN_FIELD_BASE(60, 60, 1, 0x0080, 0x10, 28, 1),
> +       PIN_FIELD_BASE(61, 61, 1, 0x0080, 0x10, 8, 1),
> +       PIN_FIELD_BASE(62, 62, 1, 0x0080, 0x10, 7, 1),
> +       PIN_FIELD_BASE(63, 63, 1, 0x0080, 0x10, 10, 1),
> +       PIN_FIELD_BASE(64, 64, 1, 0x0080, 0x10, 9, 1),
> +       PIN_FIELD_BASE(65, 65, 1, 0x0090, 0x10, 1, 1),
> +       PIN_FIELD_BASE(66, 66, 1, 0x0080, 0x10, 31, 1),
> +       PIN_FIELD_BASE(67, 67, 1, 0x0090, 0x10, 0, 1),
> +       PIN_FIELD_BASE(68, 68, 1, 0x0090, 0x10, 2, 1),
> +       PIN_FIELD_BASE(69, 69, 1, 0x0080, 0x10, 0, 1),
> +       PIN_FIELD_BASE(70, 70, 1, 0x0080, 0x10, 6, 1),
> +       PIN_FIELD_BASE(71, 71, 1, 0x0080, 0x10, 4, 1),
> +       PIN_FIELD_BASE(72, 72, 1, 0x0080, 0x10, 5, 1),
> +       PIN_FIELD_BASE(73, 73, 1, 0x0080, 0x10, 1, 1),
> +       PIN_FIELD_BASE(74, 74, 1, 0x0080, 0x10, 2, 1),
> +       PIN_FIELD_BASE(75, 75, 1, 0x0080, 0x10, 3, 1),
> +       PIN_FIELD_BASE(76, 76, 1, 0x0090, 0x10, 11, 1),
> +       PIN_FIELD_BASE(97, 97, 3, 0x0050, 0x10, 0, 1),
> +       PIN_FIELD_BASE(98, 98, 3, 0x0050, 0x10, 4, 1),
> +       PIN_FIELD_BASE(99, 99, 3, 0x0050, 0x10, 3, 1),
> +       PIN_FIELD_BASE(100, 100, 3, 0x0050, 0x10, 6, 1),
> +       PIN_FIELD_BASE(101, 101, 3, 0x0050, 0x10, 5, 1),
> +       PIN_FIELD_BASE(102, 102, 3, 0x0050, 0x10, 8, 1),
> +       PIN_FIELD_BASE(103, 103, 3, 0x0050, 0x10, 7, 1),
> +       PIN_FIELD_BASE(108, 108, 3, 0x0050, 0x10, 2, 1),
> +       PIN_FIELD_BASE(109, 109, 3, 0x0050, 0x10, 1, 1),
> +       PIN_FIELD_BASE(128, 128, 3, 0x0050, 0x10, 11, 1),
> +       PIN_FIELD_BASE(129, 129, 3, 0x0050, 0x10, 9, 1),
> +       PIN_FIELD_BASE(130, 130, 3, 0x0050, 0x10, 12, 1),
> +       PIN_FIELD_BASE(131, 131, 3, 0x0050, 0x10, 10, 1),
> +       PIN_FIELD_BASE(132, 132, 6, 0x0040, 0x10, 1, 1),
> +       PIN_FIELD_BASE(133, 133, 6, 0x0040, 0x10, 0, 1),
> +       PIN_FIELD_BASE(134, 134, 6, 0x0040, 0x10, 3, 1),
> +       PIN_FIELD_BASE(135, 135, 6, 0x0040, 0x10, 2, 1),
> +       PIN_FIELD_BASE(136, 136, 1, 0x0090, 0x10, 14, 1),
> +       PIN_FIELD_BASE(137, 137, 1, 0x0090, 0x10, 13, 1),
> +       PIN_FIELD_BASE(138, 138, 1, 0x0090, 0x10, 16, 1),
> +       PIN_FIELD_BASE(139, 139, 1, 0x0090, 0x10, 15, 1),
> +       PIN_FIELD_BASE(140, 140, 1, 0x0090, 0x10, 18, 1),
> +       PIN_FIELD_BASE(141, 141, 1, 0x0090, 0x10, 17, 1),
> +       PIN_FIELD_BASE(142, 142, 1, 0x0090, 0x10, 20, 1),
> +       PIN_FIELD_BASE(143, 143, 1, 0x0090, 0x10, 19, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_pupd_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x0060, 0x10, 0, 1),
> +       PIN_FIELD_BASE(1, 1, 4, 0x0060, 0x10, 1, 1),
> +       PIN_FIELD_BASE(2, 2, 4, 0x0060, 0x10, 2, 1),
> +       PIN_FIELD_BASE(3, 3, 4, 0x0060, 0x10, 3, 1),
> +       PIN_FIELD_BASE(4, 4, 4, 0x0060, 0x10, 4, 1),
> +       PIN_FIELD_BASE(5, 5, 4, 0x0060, 0x10, 5, 1),
> +       PIN_FIELD_BASE(77, 77, 3, 0x0060, 0x10, 1, 1),
> +       PIN_FIELD_BASE(78, 78, 3, 0x0060, 0x10, 2, 1),
> +       PIN_FIELD_BASE(79, 79, 3, 0x0060, 0x10, 9, 1),
> +       PIN_FIELD_BASE(80, 80, 3, 0x0060, 0x10, 10, 1),
> +       PIN_FIELD_BASE(81, 81, 3, 0x0060, 0x10, 11, 1),
> +       PIN_FIELD_BASE(82, 82, 3, 0x0060, 0x10, 12, 1),
> +       PIN_FIELD_BASE(83, 83, 3, 0x0060, 0x10, 13, 1),
> +       PIN_FIELD_BASE(84, 84, 3, 0x0060, 0x10, 14, 1),
> +       PIN_FIELD_BASE(85, 85, 3, 0x0060, 0x10, 15, 1),
> +       PIN_FIELD_BASE(86, 86, 3, 0x0060, 0x10, 16, 1),
> +       PIN_FIELD_BASE(87, 87, 3, 0x0060, 0x10, 3, 1),
> +       PIN_FIELD_BASE(88, 88, 3, 0x0060, 0x10, 4, 1),
> +       PIN_FIELD_BASE(89, 89, 3, 0x0060, 0x10, 5, 1),
> +       PIN_FIELD_BASE(90, 90, 3, 0x0060, 0x10, 6, 1),
> +       PIN_FIELD_BASE(91, 91, 3, 0x0060, 0x10, 7, 1),
> +       PIN_FIELD_BASE(92, 92, 3, 0x0060, 0x10, 8, 1),
> +       PIN_FIELD_BASE(93, 93, 3, 0x0060, 0x10, 18, 1),
> +       PIN_FIELD_BASE(94, 94, 3, 0x0060, 0x10, 19, 1),
> +       PIN_FIELD_BASE(95, 95, 3, 0x0060, 0x10, 17, 1),
> +       PIN_FIELD_BASE(96, 96, 3, 0x0060, 0x10, 0, 1),
> +       PIN_FIELD_BASE(104, 104, 3, 0x0060, 0x10, 22, 1),
> +       PIN_FIELD_BASE(105, 105, 3, 0x0060, 0x10, 23, 1),
> +       PIN_FIELD_BASE(106, 106, 3, 0x0060, 0x10, 20, 1),
> +       PIN_FIELD_BASE(107, 107, 3, 0x0060, 0x10, 21, 1),
> +       PIN_FIELD_BASE(110, 110, 5, 0x0020, 0x10, 1, 1),
> +       PIN_FIELD_BASE(111, 111, 5, 0x0020, 0x10, 0, 1),
> +       PIN_FIELD_BASE(112, 112, 5, 0x0020, 0x10, 2, 1),
> +       PIN_FIELD_BASE(113, 113, 5, 0x0020, 0x10, 3, 1),
> +       PIN_FIELD_BASE(114, 114, 5, 0x0020, 0x10, 4, 1),
> +       PIN_FIELD_BASE(115, 115, 5, 0x0020, 0x10, 5, 1),
> +       PIN_FIELD_BASE(116, 116, 6, 0x0050, 0x10, 9, 1),
> +       PIN_FIELD_BASE(117, 117, 6, 0x0050, 0x10, 8, 1),
> +       PIN_FIELD_BASE(118, 118, 6, 0x0050, 0x10, 7, 1),
> +       PIN_FIELD_BASE(119, 119, 6, 0x0050, 0x10, 6, 1),
> +       PIN_FIELD_BASE(120, 120, 6, 0x0050, 0x10, 11, 1),
> +       PIN_FIELD_BASE(121, 121, 6, 0x0050, 0x10, 1, 1),
> +       PIN_FIELD_BASE(122, 122, 6, 0x0050, 0x10, 0, 1),
> +       PIN_FIELD_BASE(123, 123, 6, 0x0050, 0x10, 5, 1),
> +       PIN_FIELD_BASE(124, 124, 6, 0x0050, 0x10, 4, 1),
> +       PIN_FIELD_BASE(125, 125, 6, 0x0050, 0x10, 3, 1),
> +       PIN_FIELD_BASE(126, 126, 6, 0x0050, 0x10, 2, 1),
> +       PIN_FIELD_BASE(127, 127, 6, 0x0050, 0x10, 10, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_r0_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x0080, 0x10, 0, 1),
> +       PIN_FIELD_BASE(1, 1, 4, 0x0080, 0x10, 1, 1),
> +       PIN_FIELD_BASE(2, 2, 4, 0x0080, 0x10, 2, 1),
> +       PIN_FIELD_BASE(3, 3, 4, 0x0080, 0x10, 3, 1),
> +       PIN_FIELD_BASE(4, 4, 4, 0x0080, 0x10, 4, 1),
> +       PIN_FIELD_BASE(5, 5, 4, 0x0080, 0x10, 5, 1),
> +       PIN_FIELD_BASE(77, 77, 3, 0x0080, 0x10, 1, 1),
> +       PIN_FIELD_BASE(78, 78, 3, 0x0080, 0x10, 2, 1),
> +       PIN_FIELD_BASE(79, 79, 3, 0x0080, 0x10, 9, 1),
> +       PIN_FIELD_BASE(80, 80, 3, 0x0080, 0x10, 10, 1),
> +       PIN_FIELD_BASE(81, 81, 3, 0x0080, 0x10, 11, 1),
> +       PIN_FIELD_BASE(82, 82, 3, 0x0080, 0x10, 12, 1),
> +       PIN_FIELD_BASE(83, 83, 3, 0x0080, 0x10, 13, 1),
> +       PIN_FIELD_BASE(84, 84, 3, 0x0080, 0x10, 14, 1),
> +       PIN_FIELD_BASE(85, 85, 3, 0x0080, 0x10, 15, 1),
> +       PIN_FIELD_BASE(86, 86, 3, 0x0080, 0x10, 16, 1),
> +       PIN_FIELD_BASE(87, 87, 3, 0x0080, 0x10, 3, 1),
> +       PIN_FIELD_BASE(88, 88, 3, 0x0080, 0x10, 4, 1),
> +       PIN_FIELD_BASE(89, 89, 3, 0x0080, 0x10, 5, 1),
> +       PIN_FIELD_BASE(90, 90, 3, 0x0080, 0x10, 6, 1),
> +       PIN_FIELD_BASE(91, 91, 3, 0x0080, 0x10, 7, 1),
> +       PIN_FIELD_BASE(92, 92, 3, 0x0080, 0x10, 8, 1),
> +       PIN_FIELD_BASE(93, 93, 3, 0x0080, 0x10, 18, 1),
> +       PIN_FIELD_BASE(94, 94, 3, 0x0080, 0x10, 19, 1),
> +       PIN_FIELD_BASE(95, 95, 3, 0x0080, 0x10, 17, 1),
> +       PIN_FIELD_BASE(96, 96, 3, 0x0080, 0x10, 0, 1),
> +       PIN_FIELD_BASE(104, 104, 3, 0x0080, 0x10, 22, 1),
> +       PIN_FIELD_BASE(105, 105, 3, 0x0080, 0x10, 23, 1),
> +       PIN_FIELD_BASE(106, 106, 3, 0x0080, 0x10, 20, 1),
> +       PIN_FIELD_BASE(107, 107, 3, 0x0080, 0x10, 21, 1),
> +       PIN_FIELD_BASE(110, 110, 5, 0x0030, 0x10, 1, 1),
> +       PIN_FIELD_BASE(111, 111, 5, 0x0030, 0x10, 0, 1),
> +       PIN_FIELD_BASE(112, 112, 5, 0x0030, 0x10, 2, 1),
> +       PIN_FIELD_BASE(113, 113, 5, 0x0030, 0x10, 3, 1),
> +       PIN_FIELD_BASE(114, 114, 5, 0x0030, 0x10, 4, 1),
> +       PIN_FIELD_BASE(115, 115, 5, 0x0030, 0x10, 5, 1),
> +       PIN_FIELD_BASE(116, 116, 6, 0x0070, 0x10, 9, 1),
> +       PIN_FIELD_BASE(117, 117, 6, 0x0070, 0x10, 8, 1),
> +       PIN_FIELD_BASE(118, 118, 6, 0x0070, 0x10, 7, 1),
> +       PIN_FIELD_BASE(119, 119, 6, 0x0070, 0x10, 6, 1),
> +       PIN_FIELD_BASE(120, 120, 6, 0x0070, 0x10, 11, 1),
> +       PIN_FIELD_BASE(121, 121, 6, 0x0070, 0x10, 1, 1),
> +       PIN_FIELD_BASE(122, 122, 6, 0x0070, 0x10, 0, 1),
> +       PIN_FIELD_BASE(123, 123, 6, 0x0070, 0x10, 5, 1),
> +       PIN_FIELD_BASE(124, 124, 6, 0x0070, 0x10, 4, 1),
> +       PIN_FIELD_BASE(125, 125, 6, 0x0070, 0x10, 3, 1),
> +       PIN_FIELD_BASE(126, 126, 6, 0x0070, 0x10, 2, 1),
> +       PIN_FIELD_BASE(127, 127, 6, 0x0070, 0x10, 10, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_r1_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x0090, 0x10, 0, 1),
> +       PIN_FIELD_BASE(1, 1, 4, 0x0090, 0x10, 1, 1),
> +       PIN_FIELD_BASE(2, 2, 4, 0x0090, 0x10, 2, 1),
> +       PIN_FIELD_BASE(3, 3, 4, 0x0090, 0x10, 3, 1),
> +       PIN_FIELD_BASE(4, 4, 4, 0x0090, 0x10, 4, 1),
> +       PIN_FIELD_BASE(5, 5, 4, 0x0090, 0x10, 5, 1),
> +       PIN_FIELD_BASE(77, 77, 3, 0x0090, 0x10, 1, 1),
> +       PIN_FIELD_BASE(78, 78, 3, 0x0090, 0x10, 2, 1),
> +       PIN_FIELD_BASE(79, 79, 3, 0x0090, 0x10, 9, 1),
> +       PIN_FIELD_BASE(80, 80, 3, 0x0090, 0x10, 10, 1),
> +       PIN_FIELD_BASE(81, 81, 3, 0x0090, 0x10, 11, 1),
> +       PIN_FIELD_BASE(82, 82, 3, 0x0090, 0x10, 12, 1),
> +       PIN_FIELD_BASE(83, 83, 3, 0x0090, 0x10, 13, 1),
> +       PIN_FIELD_BASE(84, 84, 3, 0x0090, 0x10, 14, 1),
> +       PIN_FIELD_BASE(85, 85, 3, 0x0090, 0x10, 15, 1),
> +       PIN_FIELD_BASE(86, 86, 3, 0x0090, 0x10, 16, 1),
> +       PIN_FIELD_BASE(87, 87, 3, 0x0090, 0x10, 3, 1),
> +       PIN_FIELD_BASE(88, 88, 3, 0x0090, 0x10, 4, 1),
> +       PIN_FIELD_BASE(89, 89, 3, 0x0090, 0x10, 5, 1),
> +       PIN_FIELD_BASE(90, 90, 3, 0x0090, 0x10, 6, 1),
> +       PIN_FIELD_BASE(91, 91, 3, 0x0090, 0x10, 7, 1),
> +       PIN_FIELD_BASE(92, 92, 3, 0x0090, 0x10, 8, 1),
> +       PIN_FIELD_BASE(93, 93, 3, 0x0090, 0x10, 18, 1),
> +       PIN_FIELD_BASE(94, 94, 3, 0x0090, 0x10, 19, 1),
> +       PIN_FIELD_BASE(95, 95, 3, 0x0090, 0x10, 17, 1),
> +       PIN_FIELD_BASE(96, 96, 3, 0x0090, 0x10, 0, 1),
> +       PIN_FIELD_BASE(104, 104, 3, 0x0090, 0x10, 22, 1),
> +       PIN_FIELD_BASE(105, 105, 3, 0x0090, 0x10, 23, 1),
> +       PIN_FIELD_BASE(106, 106, 3, 0x0090, 0x10, 20, 1),
> +       PIN_FIELD_BASE(107, 107, 3, 0x0090, 0x10, 21, 1),
> +       PIN_FIELD_BASE(110, 110, 5, 0x0040, 0x10, 1, 1),
> +       PIN_FIELD_BASE(111, 111, 5, 0x0040, 0x10, 0, 1),
> +       PIN_FIELD_BASE(112, 112, 5, 0x0040, 0x10, 2, 1),
> +       PIN_FIELD_BASE(113, 113, 5, 0x0040, 0x10, 3, 1),
> +       PIN_FIELD_BASE(114, 114, 5, 0x0040, 0x10, 4, 1),
> +       PIN_FIELD_BASE(115, 115, 5, 0x0040, 0x10, 5, 1),
> +       PIN_FIELD_BASE(116, 116, 6, 0x0080, 0x10, 9, 1),
> +       PIN_FIELD_BASE(117, 117, 6, 0x0080, 0x10, 8, 1),
> +       PIN_FIELD_BASE(118, 118, 6, 0x0080, 0x10, 7, 1),
> +       PIN_FIELD_BASE(119, 119, 6, 0x0080, 0x10, 6, 1),
> +       PIN_FIELD_BASE(120, 120, 6, 0x0080, 0x10, 11, 1),
> +       PIN_FIELD_BASE(121, 121, 6, 0x0080, 0x10, 1, 1),
> +       PIN_FIELD_BASE(122, 122, 6, 0x0080, 0x10, 0, 1),
> +       PIN_FIELD_BASE(123, 123, 6, 0x0080, 0x10, 5, 1),
> +       PIN_FIELD_BASE(124, 124, 6, 0x0080, 0x10, 4, 1),
> +       PIN_FIELD_BASE(125, 125, 6, 0x0080, 0x10, 3, 1),
> +       PIN_FIELD_BASE(126, 126, 6, 0x0080, 0x10, 2, 1),
> +       PIN_FIELD_BASE(127, 127, 6, 0x0080, 0x10, 10, 1),
> +};
> +
> +static const struct mtk_pin_field_calc mt8195_pin_drv_range[] = {
> +       PIN_FIELD_BASE(0, 0, 4, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(1, 1, 4, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(2, 2, 4, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(3, 3, 4, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(4, 4, 4, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(5, 5, 4, 0x000, 0x10, 15, 3),
> +       PINS_FIELD_BASE(6, 7, 4, 0x000, 0x10, 18, 3),
> +       PIN_FIELD_BASE(8, 8, 4, 0x010, 0x10, 6, 3),
> +       PIN_FIELD_BASE(9, 9, 4, 0x000, 0x10, 21, 3),
> +       PIN_FIELD_BASE(10, 10, 4, 0x010, 0x10, 9, 3),
> +       PIN_FIELD_BASE(11, 11, 4, 0x000, 0x10, 24, 3),
> +       PIN_FIELD_BASE(12, 12, 4, 0x010, 0x10, 12, 3),
> +       PIN_FIELD_BASE(13, 13, 4, 0x010, 0x10, 27, 3),
> +       PIN_FIELD_BASE(14, 14, 4, 0x010, 0x10, 15, 3),
> +       PIN_FIELD_BASE(15, 15, 4, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(16, 16, 4, 0x010, 0x10, 18, 3),
> +       PIN_FIELD_BASE(17, 17, 4, 0x010, 0x10, 3, 3),
> +       PIN_FIELD_BASE(18, 18, 2, 0x010, 0x10, 6, 3),
> +       PIN_FIELD_BASE(19, 19, 2, 0x010, 0x10, 3, 3),
> +       PIN_FIELD_BASE(20, 20, 2, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(21, 21, 2, 0x000, 0x10, 27, 3),
> +       PIN_FIELD_BASE(22, 22, 2, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(23, 23, 2, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(24, 24, 2, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(25, 25, 2, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(26, 26, 2, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(27, 27, 2, 0x000, 0x10, 15, 3),
> +       PIN_FIELD_BASE(28, 28, 2, 0x000, 0x10, 18, 3),
> +       PIN_FIELD_BASE(29, 29, 2, 0x000, 0x10, 21, 3),
> +       PIN_FIELD_BASE(30, 30, 2, 0x000, 0x10, 24, 3),
> +       PINS_FIELD_BASE(31, 33, 1, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(34, 34, 1, 0x000, 0x10, 21, 3),
> +       PIN_FIELD_BASE(35, 35, 1, 0x000, 0x10, 24, 3),
> +       PIN_FIELD_BASE(36, 36, 1, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(37, 37, 1, 0x010, 0x10, 21, 3),
> +       PINS_FIELD_BASE(38, 39, 1, 0x010, 0x10, 3, 3),
> +       PIN_FIELD_BASE(40, 40, 1, 0x010, 0x10, 27, 3),
> +       PIN_FIELD_BASE(41, 41, 1, 0x010, 0x10, 24, 3),
> +       PIN_FIELD_BASE(42, 42, 1, 0x020, 0x10, 3, 3),
> +       PIN_FIELD_BASE(43, 43, 1, 0x020, 0x10, 0, 3),
> +       PIN_FIELD_BASE(44, 44, 1, 0x030, 0x10, 0, 3),
> +       PIN_FIELD_BASE(45, 45, 1, 0x030, 0x10, 3, 3),
> +       PINS_FIELD_BASE(46, 47, 1, 0x010, 0x10, 3, 3),
> +       PINS_FIELD_BASE(48, 51, 1, 0x010, 0x10, 6, 3),
> +       PINS_FIELD_BASE(52, 55, 1, 0x010, 0x10, 9, 3),
> +       PINS_FIELD_BASE(56, 59, 1, 0x010, 0x10, 12, 3),
> +       PINS_FIELD_BASE(60, 63, 1, 0x010, 0x10, 15, 3),
> +       PIN_FIELD_BASE(64, 64, 1, 0x010, 0x10, 18, 3),
> +       PINS_FIELD_BASE(65, 68, 1, 0x000, 0x10, 27, 3),
> +       PIN_FIELD_BASE(69, 69, 1, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(70, 70, 1, 0x000, 0x10, 18, 3),
> +       PIN_FIELD_BASE(71, 71, 1, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(72, 72, 1, 0x000, 0x10, 15, 3),
> +       PIN_FIELD_BASE(73, 73, 1, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(74, 74, 1, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(75, 75, 1, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(76, 76, 1, 0x010, 0x10, 18, 3),
> +       PIN_FIELD_BASE(77, 77, 3, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(78, 78, 3, 0x000, 0x10, 15, 3),
> +       PIN_FIELD_BASE(79, 79, 3, 0x000, 0x10, 18, 3),
> +       PIN_FIELD_BASE(80, 80, 3, 0x000, 0x10, 21, 3),
> +       PIN_FIELD_BASE(81, 81, 3, 0x000, 0x10, 28, 3),
> +       PIN_FIELD_BASE(82, 82, 3, 0x000, 0x10, 27, 3),
> +       PIN_FIELD_BASE(83, 83, 3, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(84, 84, 3, 0x010, 0x10, 3, 3),
> +       PINS_FIELD_BASE(85, 88, 3, 0x010, 0x10, 15, 3),
> +       PIN_FIELD_BASE(89, 89, 3, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(90, 90, 3, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(91, 91, 3, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(92, 92, 3, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(93, 93, 3, 0x010, 0x10, 6, 3),
> +       PIN_FIELD_BASE(94, 94, 3, 0x010, 0x10, 9, 3),
> +       PINS_FIELD_BASE(95, 98, 3, 0x010, 0x10, 18, 3),
> +       PINS_FIELD_BASE(99, 102, 3, 0x010, 0x10, 21, 3),
> +       PINS_FIELD_BASE(103, 104, 3, 0x010, 0x10, 24, 3),
> +       PIN_FIELD_BASE(105, 105, 3, 0x010, 0x10, 27, 3),
> +       PINS_FIELD_BASE(106, 107, 3, 0x010, 0x10, 24, 3),
> +       PINS_FIELD_BASE(108, 109, 3, 0x010, 0x10, 27, 3),
> +       PIN_FIELD_BASE(110, 110, 5, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(111, 111, 5, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(112, 112, 5, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(113, 113, 5, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(114, 114, 5, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(115, 115, 5, 0x000, 0x10, 15, 3),
> +       PIN_FIELD_BASE(116, 116, 6, 0x000, 0x10, 27, 3),
> +       PIN_FIELD_BASE(117, 117, 6, 0x000, 0x10, 24, 3),
> +       PIN_FIELD_BASE(118, 118, 6, 0x000, 0x10, 21, 3),
> +       PIN_FIELD_BASE(119, 119, 6, 0x000, 0x10, 18, 3),
> +       PIN_FIELD_BASE(120, 120, 6, 0x010, 0x10, 3, 3),
> +       PIN_FIELD_BASE(121, 121, 6, 0x000, 0x10, 3, 3),
> +       PIN_FIELD_BASE(122, 122, 6, 0x000, 0x10, 0, 3),
> +       PIN_FIELD_BASE(123, 123, 6, 0x000, 0x10, 15, 3),
> +       PIN_FIELD_BASE(124, 124, 6, 0x000, 0x10, 12, 3),
> +       PIN_FIELD_BASE(125, 125, 6, 0x000, 0x10, 9, 3),
> +       PIN_FIELD_BASE(126, 126, 6, 0x000, 0x10, 6, 3),
> +       PIN_FIELD_BASE(127, 127, 6, 0x010, 0x10, 0, 3),
> +       PIN_FIELD_BASE(128, 128, 3, 0x010, 0x10, 27, 3),
> +       PINS_FIELD_BASE(129, 130, 3, 0x020, 0x10, 0, 3),
> +       PINS_FIELD_BASE(131, 131, 3, 0x010, 0x10, 12, 3),
> +       PIN_FIELD_BASE(132, 132, 6, 0x010, 0x10, 9, 3),
> +       PIN_FIELD_BASE(133, 133, 6, 0x010, 0x10, 6, 3),
> +       PIN_FIELD_BASE(134, 134, 6, 0x010, 0x10, 15, 3),
> +       PIN_FIELD_BASE(135, 135, 6, 0x010, 0x10, 12, 3),
> +       PIN_FIELD_BASE(136, 136, 1, 0x020, 0x10, 9, 3),
> +       PIN_FIELD_BASE(137, 137, 1, 0x020, 0x10, 6, 3),
> +       PIN_FIELD_BASE(138, 138, 1, 0x020, 0x10, 15, 3),
> +       PIN_FIELD_BASE(139, 139, 1, 0x020, 0x10, 12, 3),
> +       PIN_FIELD_BASE(140, 140, 1, 0x020, 0x10, 21, 3),
> +       PIN_FIELD_BASE(141, 141, 1, 0x020, 0x10, 18, 3),
> +       PIN_FIELD_BASE(142, 142, 1, 0x020, 0x10, 27, 3),
> +       PIN_FIELD_BASE(143, 143, 1, 0x020, 0x10, 24, 3),
> +};
> +
> +static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
> +       [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
> +       [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
> +       [PINCTRL_PIN_REG_DI] = MTK_RANGE(mt8195_pin_di_range),
> +       [PINCTRL_PIN_REG_DO] = MTK_RANGE(mt8195_pin_do_range),
> +       [PINCTRL_PIN_REG_SMT] = MTK_RANGE(mt8195_pin_smt_range),
> +       [PINCTRL_PIN_REG_IES] = MTK_RANGE(mt8195_pin_ies_range),
> +       [PINCTRL_PIN_REG_PU] = MTK_RANGE(mt8195_pin_pu_range),
> +       [PINCTRL_PIN_REG_PD] = MTK_RANGE(mt8195_pin_pd_range),
> +       [PINCTRL_PIN_REG_DRV] = MTK_RANGE(mt8195_pin_drv_range),
> +       [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8195_pin_pupd_range),
> +       [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
> +       [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
> +};
> +
> +static const char * const mt8195_pinctrl_register_base_names[] = {
> +       "iocfg0", "iocfg_bm", "iocfg_bl", "iocfg_br", "iocfg_lm",
> +       "iocfg_rb", "iocfg_tl",
> +};
> +
> +static const struct mtk_eint_hw mt8195_eint_hw = {
> +       .port_mask = 0xf,
> +       .ports     = 7,
> +       .ap_num    = 225,
> +       .db_cnt    = 32,
> +};
> +
> +static const struct mtk_pin_soc mt8195_data = {
> +       .reg_cal = mt8195_reg_cals,
> +       .pins = mtk_pins_mt8195,
> +       .npins = ARRAY_SIZE(mtk_pins_mt8195),
> +       .ngrps = ARRAY_SIZE(mtk_pins_mt8195),
> +       .eint_hw = &mt8195_eint_hw,
> +       .nfuncs = 8,
> +       .gpio_m = 0,
> +       .base_names = mt8195_pinctrl_register_base_names,
> +       .nbase_names = ARRAY_SIZE(mt8195_pinctrl_register_base_names),
> +       .bias_set_combo = mtk_pinconf_bias_set_combo,
> +       .bias_get_combo = mtk_pinconf_bias_get_combo,
> +       .drive_set = mtk_pinconf_drive_set_rev1,
> +       .drive_get = mtk_pinconf_drive_get_rev1,
> +};
> +
> +static const struct of_device_id mt8195_pinctrl_of_match[] = {
> +       { .compatible = "mediatek,mt8195-pinctrl", },
> +       { }
> +};
> +
> +static int mt8195_pinctrl_probe(struct platform_device *pdev)
> +{
> +       return mtk_paris_pinctrl_probe(pdev, &mt8195_data);
> +}
> +
> +static struct platform_driver mt8195_pinctrl_driver = {
> +       .driver = {
> +               .name = "mt8195-pinctrl",
> +               .of_match_table = mt8195_pinctrl_of_match,
> +       },
> +       .probe = mt8195_pinctrl_probe,
> +};
> +
> +static int __init mt8195_pinctrl_init(void)
> +{
> +       return platform_driver_register(&mt8195_pinctrl_driver);
> +}
> +arch_initcall(mt8195_pinctrl_init);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
> new file mode 100644
> index 000000000000..de4a8a80bf1d
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt8195.h
> @@ -0,0 +1,1669 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2020 MediaTek Inc.
> + *
> + * Author: Zhiyong Tao <zhiyong.tao at mediatek.com>
> + *
> + */
> +
> +#ifndef __PINCTRL_MTK_MT8195_H
> +#define __PINCTRL_MTK_MT8195_H
> +
> +#include "pinctrl-paris.h"
> +
> +static const struct mtk_pin_desc mtk_pins_mt8195[] = {
> +       MTK_PIN(
> +               0, "GPIO0",
> +               MTK_EINT_FUNCTION(0, 0),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO0"),
> +               MTK_FUNCTION(1, "TP_GPIO0_AO"),
> +               MTK_FUNCTION(2, "MSDC2_CMD"),
> +               MTK_FUNCTION(3, "TDMIN_MCK"),
> +               MTK_FUNCTION(4, "CLKM0"),
> +               MTK_FUNCTION(5, "PERSTN_1"),
> +               MTK_FUNCTION(6, "IDDIG_1P"),
> +               MTK_FUNCTION(7, "DMIC4_CLK")
> +       ),
> +       MTK_PIN(
> +               1, "GPIO1",
> +               MTK_EINT_FUNCTION(0, 1),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO1"),
> +               MTK_FUNCTION(1, "TP_GPIO1_AO"),
> +               MTK_FUNCTION(2, "MSDC2_CLK"),
> +               MTK_FUNCTION(3, "TDMIN_DI"),
> +               MTK_FUNCTION(4, "CLKM1"),
> +               MTK_FUNCTION(5, "CLKREQN_1"),
> +               MTK_FUNCTION(6, "USB_DRVVBUS_1P"),
> +               MTK_FUNCTION(7, "DMIC4_DAT")
> +       ),
> +       MTK_PIN(
> +               2, "GPIO2",
> +               MTK_EINT_FUNCTION(0, 2),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO2"),
> +               MTK_FUNCTION(1, "TP_GPIO2_AO"),
> +               MTK_FUNCTION(2, "MSDC2_DAT3"),
> +               MTK_FUNCTION(3, "TDMIN_LRCK"),
> +               MTK_FUNCTION(4, "CLKM2"),
> +               MTK_FUNCTION(5, "WAKEN_1"),
> +               MTK_FUNCTION(7, "DMIC2_CLK")
> +       ),
> +       MTK_PIN(
> +               3, "GPIO3",
> +               MTK_EINT_FUNCTION(0, 3),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO3"),
> +               MTK_FUNCTION(1, "TP_GPIO3_AO"),
> +               MTK_FUNCTION(2, "MSDC2_DAT0"),
> +               MTK_FUNCTION(3, "TDMIN_BCK"),
> +               MTK_FUNCTION(4, "CLKM3"),
> +               MTK_FUNCTION(7, "DMIC2_DAT")
> +       ),
> +       MTK_PIN(
> +               4, "GPIO4",
> +               MTK_EINT_FUNCTION(0, 4),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO4"),
> +               MTK_FUNCTION(1, "TP_GPIO4_AO"),
> +               MTK_FUNCTION(2, "MSDC2_DAT2"),
> +               MTK_FUNCTION(3, "SPDIF_IN1"),
> +               MTK_FUNCTION(4, "UTXD3"),
> +               MTK_FUNCTION(5, "SDA2"),
> +               MTK_FUNCTION(7, "IDDIG_2P")
> +       ),
> +       MTK_PIN(
> +               5, "GPIO5",
> +               MTK_EINT_FUNCTION(0, 5),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO5"),
> +               MTK_FUNCTION(1, "TP_GPIO5_AO"),
> +               MTK_FUNCTION(2, "MSDC2_DAT1"),
> +               MTK_FUNCTION(3, "SPDIF_IN0"),
> +               MTK_FUNCTION(4, "URXD3"),
> +               MTK_FUNCTION(5, "SCL2"),
> +               MTK_FUNCTION(7, "USB_DRVVBUS_2P")
> +       ),
> +       MTK_PIN(
> +               6, "GPIO6",
> +               MTK_EINT_FUNCTION(0, 6),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO6"),
> +               MTK_FUNCTION(1, "TP_GPIO6_AO"),
> +               MTK_FUNCTION(2, "DP_TX_HPD"),
> +               MTK_FUNCTION(3, "I2SO1_D4"),
> +               MTK_FUNCTION(4, "UTXD4"),
> +               MTK_FUNCTION(5, "CMVREF3"),
> +               MTK_FUNCTION(7, "DMIC3_CLK")
> +       ),
> +       MTK_PIN(
> +               7, "GPIO7",
> +               MTK_EINT_FUNCTION(0, 7),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO7"),
> +               MTK_FUNCTION(1, "TP_GPIO7_AO"),
> +               MTK_FUNCTION(2, "EDP_TX_HPD"),
> +               MTK_FUNCTION(3, "I2SO1_D5"),
> +               MTK_FUNCTION(4, "URXD4"),
> +               MTK_FUNCTION(5, "CMVREF4"),
> +               MTK_FUNCTION(7, "DMIC3_DAT")
> +       ),
> +       MTK_PIN(
> +               8, "GPIO8",
> +               MTK_EINT_FUNCTION(0, 8),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO8"),
> +               MTK_FUNCTION(1, "SDA0"),
> +               MTK_FUNCTION(2, "PWM_0"),
> +               MTK_FUNCTION(4, "SPDIF_OUT"),
> +               MTK_FUNCTION(6, "LVTS_FOUT"),
> +               MTK_FUNCTION(7, "DBG_MON_A0")
> +       ),
> +       MTK_PIN(
> +               9, "GPIO9",
> +               MTK_EINT_FUNCTION(0, 9),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO9"),
> +               MTK_FUNCTION(1, "SCL0"),
> +               MTK_FUNCTION(2, "PWM_1"),
> +               MTK_FUNCTION(4, "IR_IN"),
> +               MTK_FUNCTION(6, "LVTS_SDO"),
> +               MTK_FUNCTION(7, "DBG_MON_A1")
> +       ),
> +       MTK_PIN(
> +               10, "GPIO10",
> +               MTK_EINT_FUNCTION(0, 10),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO10"),
> +               MTK_FUNCTION(1, "SDA1"),
> +               MTK_FUNCTION(2, "PWM_2"),
> +               MTK_FUNCTION(3, "ADSP_URXD0"),
> +               MTK_FUNCTION(4, "SPDIF_IN1"),
> +               MTK_FUNCTION(6, "LVTS_SCF"),
> +               MTK_FUNCTION(7, "DBG_MON_A2")
> +       ),
> +       MTK_PIN(
> +               11, "GPIO11",
> +               MTK_EINT_FUNCTION(0, 11),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO11"),
> +               MTK_FUNCTION(1, "SCL1"),
> +               MTK_FUNCTION(2, "PWM_3"),
> +               MTK_FUNCTION(3, "ADSP_UTXD0"),
> +               MTK_FUNCTION(4, "SPDIF_IN0"),
> +               MTK_FUNCTION(6, "LVTS_SCK"),
> +               MTK_FUNCTION(7, "DBG_MON_A3")
> +       ),
> +       MTK_PIN(
> +               12, "GPIO12",
> +               MTK_EINT_FUNCTION(0, 12),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO12"),
> +               MTK_FUNCTION(1, "SDA2"),
> +               MTK_FUNCTION(2, "DMIC3_DAT_R"),
> +               MTK_FUNCTION(3, "I2SO1_D6"),
> +               MTK_FUNCTION(6, "LVTS_SDI"),
> +               MTK_FUNCTION(7, "DBG_MON_A4")
> +       ),
> +       MTK_PIN(
> +               13, "GPIO13",
> +               MTK_EINT_FUNCTION(0, 13),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO13"),
> +               MTK_FUNCTION(1, "SCL2"),
> +               MTK_FUNCTION(2, "DMIC4_DAT_R"),
> +               MTK_FUNCTION(3, "I2SO1_D7"),
> +               MTK_FUNCTION(7, "DBG_MON_A5")
> +       ),
> +       MTK_PIN(
> +               14, "GPIO14",
> +               MTK_EINT_FUNCTION(0, 14),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO14"),
> +               MTK_FUNCTION(1, "SDA3"),
> +               MTK_FUNCTION(2, "DMIC3_DAT"),
> +               MTK_FUNCTION(3, "TDMIN_MCK"),
> +               MTK_FUNCTION(7, "DBG_MON_A6")
> +       ),
> +       MTK_PIN(
> +               15, "GPIO15",
> +               MTK_EINT_FUNCTION(0, 15),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO15"),
> +               MTK_FUNCTION(1, "SCL3"),
> +               MTK_FUNCTION(2, "DMIC3_CLK"),
> +               MTK_FUNCTION(3, "TDMIN_DI"),
> +               MTK_FUNCTION(7, "DBG_MON_A7")
> +       ),
> +       MTK_PIN(
> +               16, "GPIO16",
> +               MTK_EINT_FUNCTION(0, 16),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO16"),
> +               MTK_FUNCTION(1, "SDA4"),
> +               MTK_FUNCTION(2, "DMIC4_DAT"),
> +               MTK_FUNCTION(3, "TDMIN_LRCK"),
> +               MTK_FUNCTION(7, "DBG_MON_A8")
> +       ),
> +       MTK_PIN(
> +               17, "GPIO17",
> +               MTK_EINT_FUNCTION(0, 17),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO17"),
> +               MTK_FUNCTION(1, "SCL4"),
> +               MTK_FUNCTION(2, "DMIC4_CLK"),
> +               MTK_FUNCTION(3, "TDMIN_BCK"),
> +               MTK_FUNCTION(7, "DBG_MON_A9")
> +       ),
> +       MTK_PIN(
> +               18, "GPIO18",
> +               MTK_EINT_FUNCTION(0, 18),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO18"),
> +               MTK_FUNCTION(1, "DP_TX_HPD")
> +       ),
> +       MTK_PIN(
> +               19, "GPIO19",
> +               MTK_EINT_FUNCTION(0, 19),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO19"),
> +               MTK_FUNCTION(1, "WAKEN"),
> +               MTK_FUNCTION(2, "SCP_SDA1"),
> +               MTK_FUNCTION(3, "MD32_0_JTAG_TCK"),
> +               MTK_FUNCTION(4, "ADSP_JTAG0_TCK"),
> +               MTK_FUNCTION(5, "SDA6")
> +       ),
> +       MTK_PIN(
> +               20, "GPIO20",
> +               MTK_EINT_FUNCTION(0, 20),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO20"),
> +               MTK_FUNCTION(1, "PERSTN"),
> +               MTK_FUNCTION(2, "SCP_SCL1"),
> +               MTK_FUNCTION(3, "MD32_0_JTAG_TMS"),
> +               MTK_FUNCTION(4, "ADSP_JTAG0_TMS"),
> +               MTK_FUNCTION(5, "SCL6")
> +       ),
> +       MTK_PIN(
> +               21, "GPIO21",
> +               MTK_EINT_FUNCTION(0, 21),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO21"),
> +               MTK_FUNCTION(1, "CLKREQN"),
> +               MTK_FUNCTION(3, "MD32_0_JTAG_TDI"),
> +               MTK_FUNCTION(4, "ADSP_JTAG0_TDI"),
> +               MTK_FUNCTION(5, "SCP_SDA1")
> +       ),
> +       MTK_PIN(
> +               22, "GPIO22",
> +               MTK_EINT_FUNCTION(0, 22),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO22"),
> +               MTK_FUNCTION(1, "CMMCLK0"),
> +               MTK_FUNCTION(2, "PERSTN_1"),
> +               MTK_FUNCTION(5, "SCP_SCL1"),
> +               MTK_FUNCTION(7, "MD32_0_GPIO0")
> +       ),
> +       MTK_PIN(
> +               23, "GPIO23",
> +               MTK_EINT_FUNCTION(0, 23),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO23"),
> +               MTK_FUNCTION(1, "CMMCLK1"),
> +               MTK_FUNCTION(2, "CLKREQN_1"),
> +               MTK_FUNCTION(3, "SDA4"),
> +               MTK_FUNCTION(4, "DMIC1_CLK"),
> +               MTK_FUNCTION(5, "SCP_SDA0"),
> +               MTK_FUNCTION(7, "MD32_0_GPIO1")
> +       ),
> +       MTK_PIN(
> +               24, "GPIO24",
> +               MTK_EINT_FUNCTION(0, 24),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO24"),
> +               MTK_FUNCTION(1, "CMMCLK2"),
> +               MTK_FUNCTION(2, "WAKEN_1"),
> +               MTK_FUNCTION(3, "SCL4"),
> +               MTK_FUNCTION(4, "DMIC1_DAT"),
> +               MTK_FUNCTION(5, "SCP_SCL0"),
> +               MTK_FUNCTION(6, "LVTS_26M"),
> +               MTK_FUNCTION(7, "MD32_0_GPIO2")
> +       ),
> +       MTK_PIN(
> +               25, "GPIO25",
> +               MTK_EINT_FUNCTION(0, 25),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO25"),
> +               MTK_FUNCTION(1, "CMMRST"),
> +               MTK_FUNCTION(2, "CMMCLK3"),
> +               MTK_FUNCTION(3, "SPDIF_OUT"),
> +               MTK_FUNCTION(4, "SDA6"),
> +               MTK_FUNCTION(5, "ADSP_JTAG0_TRSTN"),
> +               MTK_FUNCTION(6, "MD32_0_JTAG_TRST")
> +       ),
> +       MTK_PIN(
> +               26, "GPIO26",
> +               MTK_EINT_FUNCTION(0, 26),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO26"),
> +               MTK_FUNCTION(1, "CMMPDN"),
> +               MTK_FUNCTION(2, "CMMCLK4"),
> +               MTK_FUNCTION(3, "IR_IN"),
> +               MTK_FUNCTION(4, "SCL6"),
> +               MTK_FUNCTION(5, "ADSP_JTAG0_TDO"),
> +               MTK_FUNCTION(6, "MD32_0_JTAG_TDO")
> +       ),
> +       MTK_PIN(
> +               27, "GPIO27",
> +               MTK_EINT_FUNCTION(0, 27),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO27"),
> +               MTK_FUNCTION(1, "HDMIRX20_HTPLG"),
> +               MTK_FUNCTION(2, "CMFLASH0"),
> +               MTK_FUNCTION(3, "MD32_0_TXD"),
> +               MTK_FUNCTION(4, "TP_UTXD2_AO"),
> +               MTK_FUNCTION(5, "SCL7"),
> +               MTK_FUNCTION(6, "UCTS2"),
> +               MTK_FUNCTION(7, "DBG_MON_A18")
> +       ),
> +       MTK_PIN(
> +               28, "GPIO28",
> +               MTK_EINT_FUNCTION(0, 28),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO28"),
> +               MTK_FUNCTION(1, "HDMIRX20_PWR5V"),
> +               MTK_FUNCTION(2, "CMFLASH1"),
> +               MTK_FUNCTION(3, "MD32_0_RXD"),
> +               MTK_FUNCTION(4, "TP_URXD2_AO"),
> +               MTK_FUNCTION(5, "SDA7"),
> +               MTK_FUNCTION(6, "URTS2"),
> +               MTK_FUNCTION(7, "DBG_MON_A19")
> +       ),
> +       MTK_PIN(
> +               29, "GPIO29",
> +               MTK_EINT_FUNCTION(0, 29),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO29"),
> +               MTK_FUNCTION(1, "HDMIRX20_SCL"),
> +               MTK_FUNCTION(2, "CMFLASH2"),
> +               MTK_FUNCTION(3, "SCL5"),
> +               MTK_FUNCTION(4, "TP_URTS2_AO"),
> +               MTK_FUNCTION(6, "UTXD2"),
> +               MTK_FUNCTION(7, "DBG_MON_A20")
> +       ),
> +       MTK_PIN(
> +               30, "GPIO30",
> +               MTK_EINT_FUNCTION(0, 30),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO30"),
> +               MTK_FUNCTION(1, "HDMIRX20_SDA"),
> +               MTK_FUNCTION(2, "CMFLASH3"),
> +               MTK_FUNCTION(3, "SDA5"),
> +               MTK_FUNCTION(4, "TP_UCTS2_AO"),
> +               MTK_FUNCTION(6, "URXD2"),
> +               MTK_FUNCTION(7, "DBG_MON_A21")
> +       ),
> +       MTK_PIN(
> +               31, "GPIO31",
> +               MTK_EINT_FUNCTION(0, 31),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO31"),
> +               MTK_FUNCTION(1, "HDMITX20_PWR5V"),
> +               MTK_FUNCTION(2, "DMIC1_DAT_R"),
> +               MTK_FUNCTION(3, "PERSTN"),
> +               MTK_FUNCTION(7, "DBG_MON_A22")
> +       ),
> +       MTK_PIN(
> +               32, "GPIO32",
> +               MTK_EINT_FUNCTION(0, 32),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO32"),
> +               MTK_FUNCTION(1, "HDMITX20_HTPLG"),
> +               MTK_FUNCTION(3, "CLKREQN"),
> +               MTK_FUNCTION(7, "DBG_MON_A23")
> +       ),
> +       MTK_PIN(
> +               33, "GPIO33",
> +               MTK_EINT_FUNCTION(0, 33),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO33"),
> +               MTK_FUNCTION(1, "HDMITX20_CEC"),
> +               MTK_FUNCTION(2, "CMVREF0"),
> +               MTK_FUNCTION(3, "WAKEN")
> +       ),
> +       MTK_PIN(
> +               34, "GPIO34",
> +               MTK_EINT_FUNCTION(0, 34),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO34"),
> +               MTK_FUNCTION(1, "HDMITX20_SCL"),
> +               MTK_FUNCTION(2, "CMVREF1"),
> +               MTK_FUNCTION(3, "SCL7"),
> +               MTK_FUNCTION(4, "SCL6"),
> +               MTK_FUNCTION(7, "DBG_MON_A24")
> +       ),
> +       MTK_PIN(
> +               35, "GPIO35",
> +               MTK_EINT_FUNCTION(0, 35),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO35"),
> +               MTK_FUNCTION(1, "HDMITX20_SDA"),
> +               MTK_FUNCTION(2, "CMVREF2"),
> +               MTK_FUNCTION(3, "SDA7"),
> +               MTK_FUNCTION(4, "SDA6"),
> +               MTK_FUNCTION(7, "DBG_MON_A25")
> +       ),
> +       MTK_PIN(
> +               36, "GPIO36",
> +               MTK_EINT_FUNCTION(0, 36),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO36"),
> +               MTK_FUNCTION(1, "RTC32K_CK"),
> +               MTK_FUNCTION(7, "DBG_MON_A27")
> +       ),
> +       MTK_PIN(
> +               37, "GPIO37",
> +               MTK_EINT_FUNCTION(0, 37),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO37"),
> +               MTK_FUNCTION(1, "WATCHDOG"),
> +               MTK_FUNCTION(7, "DBG_MON_A28")
> +       ),
> +       MTK_PIN(
> +               38, "GPIO38",
> +               MTK_EINT_FUNCTION(0, 38),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO38"),
> +               MTK_FUNCTION(1, "SRCLKENA0"),
> +               MTK_FUNCTION(7, "DBG_MON_A29")
> +       ),
> +       MTK_PIN(
> +               39, "GPIO39",
> +               MTK_EINT_FUNCTION(0, 39),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO39"),
> +               MTK_FUNCTION(1, "SRCLKENA1"),
> +               MTK_FUNCTION(2, "DMIC2_DAT_R"),
> +               MTK_FUNCTION(7, "DBG_MON_A30")
> +       ),
> +       MTK_PIN(
> +               40, "GPIO40",
> +               MTK_EINT_FUNCTION(0, 40),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO40"),
> +               MTK_FUNCTION(1, "PWRAP_SPI0_CSN"),
> +               MTK_FUNCTION(3, "SPIM3_CSB"),
> +               MTK_FUNCTION(7, "DBG_MON_A31")
> +       ),
> +       MTK_PIN(
> +               41, "GPIO41",
> +               MTK_EINT_FUNCTION(0, 41),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO41"),
> +               MTK_FUNCTION(1, "PWRAP_SPI0_CK"),
> +               MTK_FUNCTION(3, "SPIM3_CLK"),
> +               MTK_FUNCTION(7, "DBG_MON_A32")
> +       ),
> +       MTK_PIN(
> +               42, "GPIO42",
> +               MTK_EINT_FUNCTION(0, 42),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO42"),
> +               MTK_FUNCTION(1, "PWRAP_SPI0_MO"),
> +               MTK_FUNCTION(2, "PWRAP_SPI0_MI"),
> +               MTK_FUNCTION(3, "SPIM3_MO"),
> +               MTK_FUNCTION(7, "DBG_MON_B0")
> +       ),
> +       MTK_PIN(
> +               43, "GPIO43",
> +               MTK_EINT_FUNCTION(0, 43),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO43"),
> +               MTK_FUNCTION(1, "PWRAP_SPI0_MI"),
> +               MTK_FUNCTION(2, "PWRAP_SPI0_MO"),
> +               MTK_FUNCTION(3, "SPIM3_MI"),
> +               MTK_FUNCTION(7, "DBG_MON_B1")
> +       ),
> +       MTK_PIN(
> +               44, "GPIO44",
> +               MTK_EINT_FUNCTION(0, 44),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO44"),
> +               MTK_FUNCTION(1, "SPMI_M_SCL"),
> +               MTK_FUNCTION(2, "I2SI00_DATA1"),
> +               MTK_FUNCTION(3, "SCL5"),
> +               MTK_FUNCTION(4, "UTXD5"),
> +               MTK_FUNCTION(7, "DBG_MON_B2")
> +       ),
> +       MTK_PIN(
> +               45, "GPIO45",
> +               MTK_EINT_FUNCTION(0, 45),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO45"),
> +               MTK_FUNCTION(1, "SPMI_M_SDA"),
> +               MTK_FUNCTION(2, "I2SI00_DATA2"),
> +               MTK_FUNCTION(3, "SDA5"),
> +               MTK_FUNCTION(4, "URXD5"),
> +               MTK_FUNCTION(7, "DBG_MON_B3")
> +       ),
> +       MTK_PIN(
> +               46, "GPIO46",
> +               MTK_EINT_FUNCTION(0, 46),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO46"),
> +               MTK_FUNCTION(1, "I2SIN_MCK"),
> +               MTK_FUNCTION(2, "I2SI00_DATA3"),
> +               MTK_FUNCTION(3, "SPLIN_MCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B4")
> +       ),
> +       MTK_PIN(
> +               47, "GPIO47",
> +               MTK_EINT_FUNCTION(0, 47),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO47"),
> +               MTK_FUNCTION(1, "I2SIN_BCK"),
> +               MTK_FUNCTION(2, "I2SIN0_BCK"),
> +               MTK_FUNCTION(3, "SPLIN_LRCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B5")
> +       ),
> +       MTK_PIN(
> +               48, "GPIO48",
> +               MTK_EINT_FUNCTION(0, 48),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO48"),
> +               MTK_FUNCTION(1, "I2SIN_WS"),
> +               MTK_FUNCTION(2, "I2SIN0_LRCK"),
> +               MTK_FUNCTION(3, "SPLIN_BCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B6")
> +       ),
> +       MTK_PIN(
> +               49, "GPIO49",
> +               MTK_EINT_FUNCTION(0, 49),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO49"),
> +               MTK_FUNCTION(1, "I2SIN_D0"),
> +               MTK_FUNCTION(2, "I2SI00_DATA0"),
> +               MTK_FUNCTION(3, "SPLIN_D0"),
> +               MTK_FUNCTION(7, "DBG_MON_B7")
> +       ),
> +       MTK_PIN(
> +               50, "GPIO50",
> +               MTK_EINT_FUNCTION(0, 50),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO50"),
> +               MTK_FUNCTION(1, "I2SO1_MCK"),
> +               MTK_FUNCTION(2, "I2SI5_D0"),
> +               MTK_FUNCTION(4, "I2SO4_MCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B8")
> +       ),
> +       MTK_PIN(
> +               51, "GPIO51",
> +               MTK_EINT_FUNCTION(0, 51),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO51"),
> +               MTK_FUNCTION(1, "I2SO1_BCK"),
> +               MTK_FUNCTION(2, "I2SI5_BCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B9")
> +       ),
> +       MTK_PIN(
> +               52, "GPIO52",
> +               MTK_EINT_FUNCTION(0, 52),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO52"),
> +               MTK_FUNCTION(1, "I2SO1_WS"),
> +               MTK_FUNCTION(2, "I2SI5_WS"),
> +               MTK_FUNCTION(7, "DBG_MON_B10")
> +       ),
> +       MTK_PIN(
> +               53, "GPIO53",
> +               MTK_EINT_FUNCTION(0, 53),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO53"),
> +               MTK_FUNCTION(1, "I2SO1_D0"),
> +               MTK_FUNCTION(2, "I2SI5_MCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B11")
> +       ),
> +       MTK_PIN(
> +               54, "GPIO54",
> +               MTK_EINT_FUNCTION(0, 54),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO54"),
> +               MTK_FUNCTION(1, "I2SO1_D1"),
> +               MTK_FUNCTION(2, "I2SI01_DATA1"),
> +               MTK_FUNCTION(3, "SPLIN_D1"),
> +               MTK_FUNCTION(4, "I2SO4_BCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B12")
> +       ),
> +       MTK_PIN(
> +               55, "GPIO55",
> +               MTK_EINT_FUNCTION(0, 55),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO55"),
> +               MTK_FUNCTION(1, "I2SO1_D2"),
> +               MTK_FUNCTION(2, "I2SI01_DATA2"),
> +               MTK_FUNCTION(3, "SPLIN_D2"),
> +               MTK_FUNCTION(4, "I2SO4_WS"),
> +               MTK_FUNCTION(7, "DBG_MON_B13")
> +       ),
> +       MTK_PIN(
> +               56, "GPIO56",
> +               MTK_EINT_FUNCTION(0, 56),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO56"),
> +               MTK_FUNCTION(1, "I2SO1_D3"),
> +               MTK_FUNCTION(2, "I2SI01_DATA3"),
> +               MTK_FUNCTION(3, "SPLIN_D3"),
> +               MTK_FUNCTION(4, "I2SO4_D0"),
> +               MTK_FUNCTION(7, "DBG_MON_B14")
> +       ),
> +       MTK_PIN(
> +               57, "GPIO57",
> +               MTK_EINT_FUNCTION(0, 57),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO57"),
> +               MTK_FUNCTION(1, "I2SO2_MCK"),
> +               MTK_FUNCTION(2, "I2SO1_D12"),
> +               MTK_FUNCTION(3, "LCM1_RST"),
> +               MTK_FUNCTION(7, "DBG_MON_B15")
> +       ),
> +       MTK_PIN(
> +               58, "GPIO58",
> +               MTK_EINT_FUNCTION(0, 58),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO58"),
> +               MTK_FUNCTION(1, "I2SO2_BCK"),
> +               MTK_FUNCTION(2, "I2SO1_D13"),
> +               MTK_FUNCTION(3, "I2SIN1_BCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B16")
> +       ),
> +       MTK_PIN(
> +               59, "GPIO59",
> +               MTK_EINT_FUNCTION(0, 59),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO59"),
> +               MTK_FUNCTION(1, "I2SO2_WS"),
> +               MTK_FUNCTION(2, "I2SO1_D14"),
> +               MTK_FUNCTION(3, "I2SIN1_LRCK"),
> +               MTK_FUNCTION(7, "DBG_MON_B17")
> +       ),
> +       MTK_PIN(
> +               60, "GPIO60",
> +               MTK_EINT_FUNCTION(0, 60),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO60"),
> +               MTK_FUNCTION(1, "I2SO2_D0"),
> +               MTK_FUNCTION(2, "I2SO1_D15"),
> +               MTK_FUNCTION(3, "I2SI01_DATA0"),
> +               MTK_FUNCTION(7, "DBG_MON_B18")
> +       ),
> +       MTK_PIN(
> +               61, "GPIO61",
> +               MTK_EINT_FUNCTION(0, 61),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO61"),
> +               MTK_FUNCTION(1, "DMIC1_CLK"),
> +               MTK_FUNCTION(2, "I2SO2_BCK"),
> +               MTK_FUNCTION(3, "SCP_SPI2_CK"),
> +               MTK_FUNCTION(7, "DBG_MON_B19")
> +       ),
> +       MTK_PIN(
> +               62, "GPIO62",
> +               MTK_EINT_FUNCTION(0, 62),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO62"),
> +               MTK_FUNCTION(1, "DMIC1_DAT"),
> +               MTK_FUNCTION(2, "I2SO2_WS"),
> +               MTK_FUNCTION(3, "SCP_SPI2_MI"),
> +               MTK_FUNCTION(7, "DBG_MON_B20")
> +       ),
> +       MTK_PIN(
> +               63, "GPIO63",
> +               MTK_EINT_FUNCTION(0, 63),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO63"),
> +               MTK_FUNCTION(1, "DMIC2_CLK"),
> +               MTK_FUNCTION(2, "VBUSVALID"),
> +               MTK_FUNCTION(3, "SCP_SPI2_MO"),
> +               MTK_FUNCTION(4, "SCP_SCL2"),
> +               MTK_FUNCTION(5, "SCP_JTAG1_TDO"),
> +               MTK_FUNCTION(6, "JTDO_SEL1"),
> +               MTK_FUNCTION(7, "DBG_MON_B21")
> +       ),
> +       MTK_PIN(
> +               64, "GPIO64",
> +               MTK_EINT_FUNCTION(0, 64),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO64"),
> +               MTK_FUNCTION(1, "DMIC2_DAT"),
> +               MTK_FUNCTION(2, "VBUSVALID_1P"),
> +               MTK_FUNCTION(3, "SCP_SPI2_CS"),
> +               MTK_FUNCTION(4, "SCP_SDA2"),
> +               MTK_FUNCTION(7, "DBG_MON_B22")
> +       ),
> +       MTK_PIN(
> +               65, "GPIO65",
> +               MTK_EINT_FUNCTION(0, 65),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO65"),
> +               MTK_FUNCTION(1, "PCM_DO"),
> +               MTK_FUNCTION(2, "AUXIF_ST0"),
> +               MTK_FUNCTION(3, "UCTS2"),
> +               MTK_FUNCTION(5, "SCP_JTAG1_TMS"),
> +               MTK_FUNCTION(6, "JTMS_SEL1"),
> +               MTK_FUNCTION(7, "DBG_MON_B23")
> +       ),
> +       MTK_PIN(
> +               66, "GPIO66",
> +               MTK_EINT_FUNCTION(0, 66),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO66"),
> +               MTK_FUNCTION(1, "PCM_CLK"),
> +               MTK_FUNCTION(2, "AUXIF_CLK0"),
> +               MTK_FUNCTION(3, "URTS2"),
> +               MTK_FUNCTION(5, "SCP_JTAG1_TCK"),
> +               MTK_FUNCTION(6, "JTCK_SEL1"),
> +               MTK_FUNCTION(7, "DBG_MON_B24")
> +       ),
> +       MTK_PIN(
> +               67, "GPIO67",
> +               MTK_EINT_FUNCTION(0, 67),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO67"),
> +               MTK_FUNCTION(1, "PCM_DI"),
> +               MTK_FUNCTION(2, "AUXIF_ST1"),
> +               MTK_FUNCTION(3, "UTXD2"),
> +               MTK_FUNCTION(5, "SCP_JTAG1_TRSTN"),
> +               MTK_FUNCTION(6, "JTRSTn_SEL1"),
> +               MTK_FUNCTION(7, "DBG_MON_B25")
> +       ),
> +       MTK_PIN(
> +               68, "GPIO68",
> +               MTK_EINT_FUNCTION(0, 68),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO68"),
> +               MTK_FUNCTION(1, "PCM_SYNC"),
> +               MTK_FUNCTION(2, "AUXIF_CLK1"),
> +               MTK_FUNCTION(3, "URXD2"),
> +               MTK_FUNCTION(5, "SCP_JTAG1_TDI"),
> +               MTK_FUNCTION(6, "JTDI_SEL1"),
> +               MTK_FUNCTION(7, "DBG_MON_B26")
> +       ),
> +       MTK_PIN(
> +               69, "GPIO69",
> +               MTK_EINT_FUNCTION(0, 69),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO69"),
> +               MTK_FUNCTION(1, "AUD_CLK_MOSI"),
> +               MTK_FUNCTION(2, "I2SIN2_BCK"),
> +               MTK_FUNCTION(3, "PWM_0"),
> +               MTK_FUNCTION(4, "WAKEN"),
> +               MTK_FUNCTION(7, "DBG_MON_B27")
> +       ),
> +       MTK_PIN(
> +               70, "GPIO70",
> +               MTK_EINT_FUNCTION(0, 70),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO70"),
> +               MTK_FUNCTION(1, "AUD_SYNC_MOSI"),
> +               MTK_FUNCTION(2, "I2SIN2_LRCK"),
> +               MTK_FUNCTION(3, "PWM_1"),
> +               MTK_FUNCTION(4, "PERSTN"),
> +               MTK_FUNCTION(7, "DBG_MON_B28")
> +       ),
> +       MTK_PIN(
> +               71, "GPIO71",
> +               MTK_EINT_FUNCTION(0, 71),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO71"),
> +               MTK_FUNCTION(1, "AUD_DAT_MOSI0"),
> +               MTK_FUNCTION(2, "IDDIG_2P"),
> +               MTK_FUNCTION(3, "PWM_2"),
> +               MTK_FUNCTION(4, "CLKREQN"),
> +               MTK_FUNCTION(7, "DBG_MON_B29")
> +       ),
> +       MTK_PIN(
> +               72, "GPIO72",
> +               MTK_EINT_FUNCTION(0, 72),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO72"),
> +               MTK_FUNCTION(1, "AUD_DAT_MOSI1"),
> +               MTK_FUNCTION(2, "USB_DRVVBUS_2P"),
> +               MTK_FUNCTION(3, "PWM_3"),
> +               MTK_FUNCTION(4, "PERSTN_1"),
> +               MTK_FUNCTION(7, "DBG_MON_B30")
> +       ),
> +       MTK_PIN(
> +               73, "GPIO73",
> +               MTK_EINT_FUNCTION(0, 73),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO73"),
> +               MTK_FUNCTION(1, "AUD_DAT_MISO0"),
> +               MTK_FUNCTION(2, "I2SI02_DATA0"),
> +               MTK_FUNCTION(4, "CLKREQN_1"),
> +               MTK_FUNCTION(5, "VOW_DAT_MISO"),
> +               MTK_FUNCTION(7, "DBG_MON_B31")
> +       ),
> +       MTK_PIN(
> +               74, "GPIO74",
> +               MTK_EINT_FUNCTION(0, 74),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO74"),
> +               MTK_FUNCTION(1, "AUD_DAT_MISO1"),
> +               MTK_FUNCTION(2, "I2SI02_DATA1"),
> +               MTK_FUNCTION(4, "WAKEN_1"),
> +               MTK_FUNCTION(5, "VOW_CLK_MISO"),
> +               MTK_FUNCTION(7, "DBG_MON_B32")
> +       ),
> +       MTK_PIN(
> +               75, "GPIO75",
> +               MTK_EINT_FUNCTION(0, 75),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO75"),
> +               MTK_FUNCTION(1, "AUD_DAT_MISO2"),
> +               MTK_FUNCTION(2, "I2SI02_DATA2")
> +       ),
> +       MTK_PIN(
> +               76, "GPIO76",
> +               MTK_EINT_FUNCTION(0, 76),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO76"),
> +               MTK_FUNCTION(1, "SCP_VREQ_VAO"),
> +               MTK_FUNCTION(2, "I2SI02_DATA3"),
> +               MTK_FUNCTION(7, "DBG_MON_A26")
> +       ),
> +       MTK_PIN(
> +               77, "GPIO77",
> +               MTK_EINT_FUNCTION(0, 77),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO77"),
> +               MTK_FUNCTION(1, "DGI_D0"),
> +               MTK_FUNCTION(2, "DPI_D0"),
> +               MTK_FUNCTION(3, "I2SI4_MCK"),
> +               MTK_FUNCTION(4, "SPIM4_CLK"),
> +               MTK_FUNCTION(5, "GBE_TXD3"),
> +               MTK_FUNCTION(6, "SPM_JTAG_TCK")
> +       ),
> +       MTK_PIN(
> +               78, "GPIO78",
> +               MTK_EINT_FUNCTION(0, 78),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO78"),
> +               MTK_FUNCTION(1, "DGI_D1"),
> +               MTK_FUNCTION(2, "DPI_D1"),
> +               MTK_FUNCTION(3, "I2SI4_BCK"),
> +               MTK_FUNCTION(4, "SPIM4_MO"),
> +               MTK_FUNCTION(5, "GBE_TXD2"),
> +               MTK_FUNCTION(6, "SPM_JTAG_TMS")
> +       ),
> +       MTK_PIN(
> +               79, "GPIO79",
> +               MTK_EINT_FUNCTION(0, 79),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO79"),
> +               MTK_FUNCTION(1, "DGI_D2"),
> +               MTK_FUNCTION(2, "DPI_D2"),
> +               MTK_FUNCTION(3, "I2SI4_WS"),
> +               MTK_FUNCTION(4, "SPIM4_CSB"),
> +               MTK_FUNCTION(5, "GBE_TXD1"),
> +               MTK_FUNCTION(6, "SPM_JTAG_TDI")
> +       ),
> +       MTK_PIN(
> +               80, "GPIO80",
> +               MTK_EINT_FUNCTION(0, 80),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO80"),
> +               MTK_FUNCTION(1, "DGI_D3"),
> +               MTK_FUNCTION(2, "DPI_D3"),
> +               MTK_FUNCTION(3, "I2SI4_D0"),
> +               MTK_FUNCTION(4, "SPIM4_MI"),
> +               MTK_FUNCTION(5, "GBE_TXD0"),
> +               MTK_FUNCTION(6, "SPM_JTAG_TDO")
> +       ),
> +       MTK_PIN(
> +               81, "GPIO81",
> +               MTK_EINT_FUNCTION(0, 81),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO81"),
> +               MTK_FUNCTION(1, "DGI_D4"),
> +               MTK_FUNCTION(2, "DPI_D4"),
> +               MTK_FUNCTION(3, "I2SI5_MCK"),
> +               MTK_FUNCTION(4, "SPIM5_CLK"),
> +               MTK_FUNCTION(5, "GBE_RXD3"),
> +               MTK_FUNCTION(6, "SPM_JTAG_TRSTN")
> +       ),
> +       MTK_PIN(
> +               82, "GPIO82",
> +               MTK_EINT_FUNCTION(0, 82),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO82"),
> +               MTK_FUNCTION(1, "DGI_D5"),
> +               MTK_FUNCTION(2, "DPI_D5"),
> +               MTK_FUNCTION(3, "I2SI5_BCK"),
> +               MTK_FUNCTION(4, "SPIM5_MO"),
> +               MTK_FUNCTION(5, "GBE_RXD2"),
> +               MTK_FUNCTION(6, "MCUPM_JTAG_TDO")
> +       ),
> +       MTK_PIN(
> +               83, "GPIO83",
> +               MTK_EINT_FUNCTION(0, 83),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO83"),
> +               MTK_FUNCTION(1, "DGI_D6"),
> +               MTK_FUNCTION(2, "DPI_D6"),
> +               MTK_FUNCTION(3, "I2SI5_WS"),
> +               MTK_FUNCTION(4, "SPIM5_CSB"),
> +               MTK_FUNCTION(5, "GBE_RXD1"),
> +               MTK_FUNCTION(6, "MCUPM_JTAG_TMS")
> +       ),
> +       MTK_PIN(
> +               84, "GPIO84",
> +               MTK_EINT_FUNCTION(0, 84),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO84"),
> +               MTK_FUNCTION(1, "DGI_D7"),
> +               MTK_FUNCTION(2, "DPI_D7"),
> +               MTK_FUNCTION(3, "I2SI5_D0"),
> +               MTK_FUNCTION(4, "SPIM5_MI"),
> +               MTK_FUNCTION(5, "GBE_RXD0"),
> +               MTK_FUNCTION(6, "MCUPM_JTAG_TCK")
> +       ),
> +       MTK_PIN(
> +               85, "GPIO85",
> +               MTK_EINT_FUNCTION(0, 85),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO85"),
> +               MTK_FUNCTION(1, "DGI_D8"),
> +               MTK_FUNCTION(2, "DPI_D8"),
> +               MTK_FUNCTION(3, "I2SO4_MCK"),
> +               MTK_FUNCTION(4, "SCP_SPI1_B_CK"),
> +               MTK_FUNCTION(5, "GBE_TXC"),
> +               MTK_FUNCTION(6, "MCUPM_JTAG_TDI")
> +       ),
> +       MTK_PIN(
> +               86, "GPIO86",
> +               MTK_EINT_FUNCTION(0, 86),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO86"),
> +               MTK_FUNCTION(1, "DGI_D9"),
> +               MTK_FUNCTION(2, "DPI_D9"),
> +               MTK_FUNCTION(3, "I2SO4_BCK"),
> +               MTK_FUNCTION(4, "SCP_SPI1_B_MI"),
> +               MTK_FUNCTION(5, "GBE_RXC"),
> +               MTK_FUNCTION(6, "MCUPM_JTAG_TRSTN")
> +       ),
> +       MTK_PIN(
> +               87, "GPIO87",
> +               MTK_EINT_FUNCTION(0, 87),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO87"),
> +               MTK_FUNCTION(1, "DGI_D10"),
> +               MTK_FUNCTION(2, "DPI_D10"),
> +               MTK_FUNCTION(3, "I2SO4_WS"),
> +               MTK_FUNCTION(4, "SCP_SPI1_B_CS"),
> +               MTK_FUNCTION(5, "GBE_RXDV"),
> +               MTK_FUNCTION(6, "SSPM_JTAG_TDO")
> +       ),
> +       MTK_PIN(
> +               88, "GPIO88",
> +               MTK_EINT_FUNCTION(0, 88),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO88"),
> +               MTK_FUNCTION(1, "DGI_D11"),
> +               MTK_FUNCTION(2, "DPI_D11"),
> +               MTK_FUNCTION(3, "I2SO4_D0"),
> +               MTK_FUNCTION(4, "SCP_SPI1_B_MO"),
> +               MTK_FUNCTION(5, "GBE_TXEN"),
> +               MTK_FUNCTION(6, "SSPM_JTAG_TMS")
> +       ),
> +       MTK_PIN(
> +               89, "GPIO89",
> +               MTK_EINT_FUNCTION(0, 89),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO89"),
> +               MTK_FUNCTION(1, "DGI_D12"),
> +               MTK_FUNCTION(2, "DPI_D12"),
> +               MTK_FUNCTION(3, "MSDC2_CMD_A"),
> +               MTK_FUNCTION(4, "I2SO5_BCK"),
> +               MTK_FUNCTION(5, "GBE_MDC"),
> +               MTK_FUNCTION(6, "SSPM_JTAG_TCK")
> +       ),
> +       MTK_PIN(
> +               90, "GPIO90",
> +               MTK_EINT_FUNCTION(0, 90),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO90"),
> +               MTK_FUNCTION(1, "DGI_D13"),
> +               MTK_FUNCTION(2, "DPI_D13"),
> +               MTK_FUNCTION(3, "MSDC2_CLK_A"),
> +               MTK_FUNCTION(4, "I2SO5_WS"),
> +               MTK_FUNCTION(5, "GBE_MDIO"),
> +               MTK_FUNCTION(6, "SSPM_JTAG_TDI")
> +       ),
> +       MTK_PIN(
> +               91, "GPIO91",
> +               MTK_EINT_FUNCTION(0, 91),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO91"),
> +               MTK_FUNCTION(1, "DGI_D14"),
> +               MTK_FUNCTION(2, "DPI_D14"),
> +               MTK_FUNCTION(3, "MSDC2_DAT3_A"),
> +               MTK_FUNCTION(4, "I2SO5_D0"),
> +               MTK_FUNCTION(5, "GBE_TXER"),
> +               MTK_FUNCTION(6, "SSPM_JTAG_TRSTN")
> +       ),
> +       MTK_PIN(
> +               92, "GPIO92",
> +               MTK_EINT_FUNCTION(0, 92),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO92"),
> +               MTK_FUNCTION(1, "DGI_D15"),
> +               MTK_FUNCTION(2, "DPI_D15"),
> +               MTK_FUNCTION(3, "MSDC2_DAT0_A"),
> +               MTK_FUNCTION(4, "I2SO2_D1"),
> +               MTK_FUNCTION(5, "GBE_RXER"),
> +               MTK_FUNCTION(6, "CCU0_JTAG_TDO")
> +       ),
> +       MTK_PIN(
> +               93, "GPIO93",
> +               MTK_EINT_FUNCTION(0, 93),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO93"),
> +               MTK_FUNCTION(1, "DGI_HSYNC"),
> +               MTK_FUNCTION(2, "DPI_HSYNC"),
> +               MTK_FUNCTION(3, "MSDC2_DAT2_A"),
> +               MTK_FUNCTION(4, "I2SO2_D2"),
> +               MTK_FUNCTION(5, "GBE_COL"),
> +               MTK_FUNCTION(6, "CCU0_JTAG_TMS")
> +       ),
> +       MTK_PIN(
> +               94, "GPIO94",
> +               MTK_EINT_FUNCTION(0, 94),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO94"),
> +               MTK_FUNCTION(1, "DGI_VSYNC"),
> +               MTK_FUNCTION(2, "DPI_VSYNC"),
> +               MTK_FUNCTION(3, "MSDC2_DAT1_A"),
> +               MTK_FUNCTION(4, "I2SO2_D3"),
> +               MTK_FUNCTION(5, "GBE_INTR"),
> +               MTK_FUNCTION(6, "CCU0_JTAG_TDI")
> +       ),
> +       MTK_PIN(
> +               95, "GPIO95",
> +               MTK_EINT_FUNCTION(0, 95),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO95"),
> +               MTK_FUNCTION(1, "DGI_DE"),
> +               MTK_FUNCTION(2, "DPI_DE"),
> +               MTK_FUNCTION(3, "UTXD2"),
> +               MTK_FUNCTION(5, "I2SIN_D1"),
> +               MTK_FUNCTION(6, "CCU0_JTAG_TCK")
> +       ),
> +       MTK_PIN(
> +               96, "GPIO96",
> +               MTK_EINT_FUNCTION(0, 96),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO96"),
> +               MTK_FUNCTION(1, "DGI_CK"),
> +               MTK_FUNCTION(2, "DPI_CK"),
> +               MTK_FUNCTION(3, "URXD2"),
> +               MTK_FUNCTION(4, "I2SO5_MCK"),
> +               MTK_FUNCTION(5, "I2SIN_D2"),
> +               MTK_FUNCTION(6, "CCU0_JTAG_TRST")
> +       ),
> +       MTK_PIN(
> +               97, "GPIO97",
> +               MTK_EINT_FUNCTION(0, 97),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO97"),
> +               MTK_FUNCTION(1, "DISP_PWM0"),
> +               MTK_FUNCTION(2, "DVFSRC_EXT_REQ")
> +       ),
> +       MTK_PIN(
> +               98, "GPIO98",
> +               MTK_EINT_FUNCTION(0, 98),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO98"),
> +               MTK_FUNCTION(1, "UTXD0")
> +       ),
> +       MTK_PIN(
> +               99, "GPIO99",
> +               MTK_EINT_FUNCTION(0, 99),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO99"),
> +               MTK_FUNCTION(1, "URXD0")
> +       ),
> +       MTK_PIN(
> +               100, "GPIO100",
> +               MTK_EINT_FUNCTION(0, 100),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO100"),
> +               MTK_FUNCTION(1, "URTS1"),
> +               MTK_FUNCTION(2, "DSI_TE"),
> +               MTK_FUNCTION(3, "I2SO1_D8"),
> +               MTK_FUNCTION(4, "KPROW2"),
> +               MTK_FUNCTION(5, "PWM_0"),
> +               MTK_FUNCTION(6, "TP_URTS1_AO"),
> +               MTK_FUNCTION(7, "I2SIN_D0")
> +       ),
> +       MTK_PIN(
> +               101, "GPIO101",
> +               MTK_EINT_FUNCTION(0, 101),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO101"),
> +               MTK_FUNCTION(1, "UCTS1"),
> +               MTK_FUNCTION(2, "DSI1_TE"),
> +               MTK_FUNCTION(3, "I2SO1_D9"),
> +               MTK_FUNCTION(4, "KPCOL2"),
> +               MTK_FUNCTION(5, "PWM_1"),
> +               MTK_FUNCTION(6, "TP_UCTS1_AO"),
> +               MTK_FUNCTION(7, "I2SIN_D1")
> +       ),
> +       MTK_PIN(
> +               102, "GPIO102",
> +               MTK_EINT_FUNCTION(0, 102),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO102"),
> +               MTK_FUNCTION(1, "UTXD1"),
> +               MTK_FUNCTION(2, "VBUSVALID_2P"),
> +               MTK_FUNCTION(3, "I2SO1_D10"),
> +               MTK_FUNCTION(4, "SSPM_UTXD_AO"),
> +               MTK_FUNCTION(5, "TP_UTXD1_AO"),
> +               MTK_FUNCTION(6, "MD32_1_TXD"),
> +               MTK_FUNCTION(7, "I2SIN_D2")
> +       ),
> +       MTK_PIN(
> +               103, "GPIO103",
> +               MTK_EINT_FUNCTION(0, 103),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO103"),
> +               MTK_FUNCTION(1, "URXD1"),
> +               MTK_FUNCTION(2, "VBUSVALID_3P"),
> +               MTK_FUNCTION(3, "I2SO1_D11"),
> +               MTK_FUNCTION(4, "SSPM_URXD_AO"),
> +               MTK_FUNCTION(5, "TP_URXD1_AO"),
> +               MTK_FUNCTION(6, "MD32_1_RXD"),
> +               MTK_FUNCTION(7, "I2SIN_D3")
> +       ),
> +       MTK_PIN(
> +               104, "GPIO104",
> +               MTK_EINT_FUNCTION(0, 104),
> +               DRV_GRP4,
> +               MTK_FUNCTION(0, "GPIO104"),
> +


From sean.wang at kernel.org  Tue Apr 20 04:47:42 2021
From: sean.wang at kernel.org (Sean Wang)
Date: Mon, 19 Apr 2021 20:47:42 -0700
Subject: [PATCH v4 3/4] pinctrl: add drive for I2C related pins on MT8195
In-Reply-To: <20210413055702.27535-4-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <20210413055702.27535-4-zhiyong.tao@mediatek.com>
Message-ID: <CAGp9Lzr22hShK5F2qcPNH3yXxGZx=DUmoa0r8d6Fn=c-U2=j0g@mail.gmail.com>

On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:
>
> This patch provides the advanced drive raw data setting version
> for I2C used pins on MT8195.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>

Acked-by: Sean Wang <sean.wang at kernel.org>

> ---
>  drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
>  .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
>  .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  |  5 +++++
>  3 files changed, 41 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> index 063f164d7c9b..a7500e18bb1d 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> @@ -760,6 +760,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_range[] = {
>         PIN_FIELD_BASE(143, 143, 1, 0x020, 0x10, 24, 3),
>  };
>
> +static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
> +       PIN_FIELD_BASE(8, 8, 4, 0x020, 0x10, 15, 3),
> +       PIN_FIELD_BASE(9, 9, 4, 0x020, 0x10, 0, 3),
> +       PIN_FIELD_BASE(10, 10, 4, 0x020, 0x10, 18, 3),
> +       PIN_FIELD_BASE(11, 11, 4, 0x020, 0x10, 3, 3),
> +       PIN_FIELD_BASE(12, 12, 4, 0x020, 0x10, 21, 3),
> +       PIN_FIELD_BASE(13, 13, 4, 0x020, 0x10, 6, 3),
> +       PIN_FIELD_BASE(14, 14, 4, 0x020, 0x10, 24, 3),
> +       PIN_FIELD_BASE(15, 15, 4, 0x020, 0x10, 9, 3),
> +       PIN_FIELD_BASE(16, 16, 4, 0x020, 0x10, 27, 3),
> +       PIN_FIELD_BASE(17, 17, 4, 0x020, 0x10, 12, 3),
> +       PIN_FIELD_BASE(29, 29, 2, 0x020, 0x10, 0, 3),
> +       PIN_FIELD_BASE(30, 30, 2, 0x020, 0x10, 3, 3),
> +       PIN_FIELD_BASE(34, 34, 1, 0x040, 0x10, 0, 3),
> +       PIN_FIELD_BASE(35, 35, 1, 0x040, 0x10, 3, 3),
> +       PIN_FIELD_BASE(44, 44, 1, 0x040, 0x10, 6, 3),
> +       PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
> +};
> +
>  static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
>         [PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
>         [PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
> @@ -773,6 +792,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
>         [PINCTRL_PIN_REG_PUPD] = MTK_RANGE(mt8195_pin_pupd_range),
>         [PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
>         [PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
> +       [PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
>  };
>
>  static const char * const mt8195_pinctrl_register_base_names[] = {
> @@ -801,6 +821,8 @@ static const struct mtk_pin_soc mt8195_data = {
>         .bias_get_combo = mtk_pinconf_bias_get_combo,
>         .drive_set = mtk_pinconf_drive_set_rev1,
>         .drive_get = mtk_pinconf_drive_get_rev1,
> +       .adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> +       .adv_drive_set = mtk_pinconf_adv_drive_set_raw,
>  };
>
>  static const struct of_device_id mt8195_pinctrl_of_match[] = {
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 72f17f26acd8..2b51f4a9b860 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -1027,6 +1027,20 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
>  }
>  EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get);
>
> +int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
> +                                 const struct mtk_pin_desc *desc, u32 arg)
> +{
> +       return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, arg);
> +}
> +EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_set_raw);
> +
> +int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
> +                                 const struct mtk_pin_desc *desc, u32 *val)
> +{
> +       return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV_ADV, val);
> +}
> +EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
> +
>  MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
>  MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> index e2aae285b5fc..fd5ce9c5dcbd 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
> @@ -66,6 +66,7 @@ enum {
>         PINCTRL_PIN_REG_DRV_EN,
>         PINCTRL_PIN_REG_DRV_E0,
>         PINCTRL_PIN_REG_DRV_E1,
> +       PINCTRL_PIN_REG_DRV_ADV,
>         PINCTRL_PIN_REG_MAX,
>  };
>
> @@ -314,6 +315,10 @@ int mtk_pinconf_adv_drive_set(struct mtk_pinctrl *hw,
>                               const struct mtk_pin_desc *desc, u32 arg);
>  int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
>                               const struct mtk_pin_desc *desc, u32 *val);
> +int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
> +                                 const struct mtk_pin_desc *desc, u32 arg);
> +int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
> +                                 const struct mtk_pin_desc *desc, u32 *val);
>
>  bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
>  #endif /* __PINCTRL_MTK_COMMON_V2_H */
> --
> 2.18.0
>


From sean.wang at kernel.org  Tue Apr 20 04:50:15 2021
From: sean.wang at kernel.org (Sean Wang)
Date: Mon, 19 Apr 2021 20:50:15 -0700
Subject: [PATCH v4 4/4] pinctrl: add rsel setting on MT8195
In-Reply-To: <20210413055702.27535-5-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <20210413055702.27535-5-zhiyong.tao@mediatek.com>
Message-ID: <CAGp9LzoM=9v5mLxtAN9sQm_2f+66xc7G4YqfUF1Mwvr4K_wz5w@mail.gmail.com>

On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:

<snip>
> @@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
>                 else
>                         err = -ENOTSUPP;
>                 break;
> +       case MTK_PIN_CONFIG_RSEL:
> +               if (hw->soc->rsel_get)
> +                       err = hw->soc->rsel_get(hw, desc, &ret);
> +               else
> +                       err = -EOPNOTSUPP;

I think that should want to be -ENOTSUPP to align other occurrences.

> +               break;
>         default:
>                 err = -ENOTSUPP;
>         }
> @@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
>                 else
>                         err = -ENOTSUPP;
>                 break;
> +       case MTK_PIN_CONFIG_RSEL:
> +               if (hw->soc->rsel_set)
> +                       err = hw->soc->rsel_set(hw, desc, arg);
> +               else
> +                       err = -EOPNOTSUPP;

Ditto

> +               break;
>         default:
>                 err = -ENOTSUPP;
>         }
> --
> 2.18.0
>


From mpe at ellerman.id.au  Tue Apr 20 05:03:18 2021
From: mpe at ellerman.id.au (Michael Ellerman)
Date: Tue, 20 Apr 2021 14:03:18 +1000
Subject: [PATCH 0/2] Change struct page layout for page_pool
In-Reply-To: <20210416230724.2519198-1-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
Message-ID: <874kg1d2m1.fsf@mpe.ellerman.id.au>

"Matthew Wilcox (Oracle)" <willy at infradead.org> writes:
> The first patch here fixes two bugs on ppc32, and mips32.  It fixes one
> bug on arc and arm32 (in certain configurations).  It probably makes
> sense to get it in ASAP through the networking tree.  I'd like to see
> testing on those four architectures if possible?

Sorry I don't have easy access to any hardware that fits the bill. At
some point I'll be able to go to the office and setup a machine that (I
think) can test these paths, but I don't have an ETA on that.

You and others seem to have done lots of analysis on this though, so I
think you should merge the fixes without waiting on ppc32 testing.

cheers


>
> The second patch enables new functionality.  It is much less urgent.
> I'd really like to see Mel & Michal's thoughts on it.
>
> I have only compile-tested these patches.
>
> Matthew Wilcox (Oracle) (2):
>   mm: Fix struct page layout on 32-bit systems
>   mm: Indicate pfmemalloc pages in compound_head
>
>  include/linux/mm.h       | 12 +++++++-----
>  include/linux/mm_types.h |  9 ++++-----
>  include/net/page_pool.h  | 12 +++++++++++-
>  net/core/page_pool.c     | 12 +++++++-----
>  4 files changed, 29 insertions(+), 16 deletions(-)
>
> -- 
> 2.30.2


From adrian.hunter at intel.com  Tue Apr 20 05:15:24 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Tue, 20 Apr 2021 07:15:24 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
 <fdadd467-b613-d800-18c5-be064396fd10@intel.com>
 <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
Message-ID: <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>

On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>
>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>> ---
>>
>> I came across 3 issues while testing.? See comments below.
>>
> Hi Adrian
> Thanks for the comments.
>> <SNIP>
>>
>>> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>>> ????? if (ufshcd_is_clkscaling_supported(hba))
>>> ????????? ufshcd_clk_scaling_suspend(hba, false);
>>> ????? ufshcd_clear_ua_wluns(hba);
>>
>> ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
>> if sdev_rpmb is suspended and sdev_ufs_device is suspending.
>> e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
>> is running, at which point sdev_rpmb has already suspended.
>>
> Umm, I didn't understand this deadlock.
> When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
> sdev_ufs_device is suspending - this can't be runtime_suspending, while ufshcd_err_handling_unprepare is running.
> 
> If you've a call-stack of this deadlock, please can you share it with me. I'll also try to reproduce this.

Yes it is system suspend. sdev_rpmb has suspended, sdev_ufs_device is waiting on host_sem.
ufshcd_err_handler() holds host_sem. ufshcd_clear_ua_wlun(UFS_UPIU_RPMB_WLUN) gets stuck.
I will get some call-stacks.

> 
> I'll address the other comments in the next version.
> 
> 
> Thank you!
> 
>>> -??? pm_runtime_put(hba->dev);
>>> +??? ufshcd_rpm_put(hba);
>>> ? }
>>
>> <SNIP>
>>
>>> +void ufshcd_resume_complete(struct device *dev)
>>> +{
> 



From lkp at intel.com  Tue Apr 20 05:27:51 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:51 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 8c0bd213de32aa23bbdc930f2ac74731a32b8171
Message-ID: <607e5847.cPggjFT/Sms5ipF0%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: 8c0bd213de32aa23bbdc930f2ac74731a32b8171  Merge tag 'memory-controller-drv-5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers

elapsed time: 723m

configs tested: 155
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
powerpc                 xes_mpc85xx_defconfig
arm                       versatile_defconfig
s390                             alldefconfig
mips                      pistachio_defconfig
arm                        spear3xx_defconfig
powerpc                        fsp2_defconfig
sh                        dreamcast_defconfig
powerpc                     ppa8548_defconfig
xtensa                  cadence_csp_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
m68k                          hp300_defconfig
m68k                       m5275evb_defconfig
mips                          ath79_defconfig
mips                   sb1250_swarm_defconfig
openrisc                  or1klitex_defconfig
sh                         microdev_defconfig
arm                             rpc_defconfig
powerpc                     asp8347_defconfig
arm                        realview_defconfig
sh                   rts7751r2dplus_defconfig
xtensa                         virt_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
arm                         hackkit_defconfig
powerpc                      ep88xc_defconfig
powerpc                     ep8248e_defconfig
xtensa                       common_defconfig
h8300                               defconfig
arm                       multi_v4t_defconfig
ia64                      gensparse_defconfig
arm                        multi_v7_defconfig
arm                          imote2_defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
ia64                             allmodconfig
ia64                                defconfig
powerpc                    socrates_defconfig
arm64                            alldefconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
parisc                           alldefconfig
powerpc                       holly_defconfig
sh                        sh7785lcr_defconfig
m68k                          multi_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arc                    vdk_hs38_smp_defconfig
sh                           se7751_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
powerpc                          g5_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:56 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:56 +0800
Subject: [soc:arm/defconfig] BUILD SUCCESS
 028a1e968435383c9555fc9386d116688f31dfce
Message-ID: <607e584c.YNdwKvXpwiejpIpx%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/defconfig
branch HEAD: 028a1e968435383c9555fc9386d116688f31dfce  Merge tag 'qcom-defconfig-for-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig

elapsed time: 723m

configs tested: 149
configs skipped: 18

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
s390                             allmodconfig
arm                        vexpress_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
powerpc                          g5_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlr_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
mips                      fuloong2e_defconfig
parisc                generic-64bit_defconfig
mips                        maltaup_defconfig
arm                           h5000_defconfig
powerpc                     mpc83xx_defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
ia64                             allmodconfig
powerpc                 xes_mpc85xx_defconfig
ia64                                defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
powerpc                    socrates_defconfig
arm64                            alldefconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
parisc                           alldefconfig
powerpc                       holly_defconfig
i386                                defconfig
sh                        sh7785lcr_defconfig
m68k                          multi_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:47 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:47 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 a85a8d52bf5007b14cbe70f9197bda25c78cab53
Message-ID: <607e5843.lVsg6DiTo6zTkuhE%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: a85a8d52bf5007b14cbe70f9197bda25c78cab53  Merge tag 'qcom-arm64-for-5.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt

elapsed time: 722m

configs tested: 157
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
um                                allnoconfig
powerpc                      ep88xc_defconfig
powerpc                    socrates_defconfig
sparc                       sparc64_defconfig
arm                        magician_defconfig
m68k                            mac_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
powerpc                          g5_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlr_defconfig
openrisc                  or1klitex_defconfig
sh                         microdev_defconfig
arm                             rpc_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
arm                         hackkit_defconfig
powerpc                     ep8248e_defconfig
xtensa                       common_defconfig
h8300                               defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
ia64                             allmodconfig
powerpc                 xes_mpc85xx_defconfig
ia64                                defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
arm64                            alldefconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
parisc                           alldefconfig
powerpc                       holly_defconfig
i386                                defconfig
sh                        sh7785lcr_defconfig
m68k                          multi_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:52 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:52 +0800
Subject: [soc:qcom/dt-4] BUILD SUCCESS 1b86cc7330895b11df0a7dc15fbbbef60be9f7bb
Message-ID: <607e5848.jyyRYccNhJTFeVfh%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt-4
branch HEAD: 1b86cc7330895b11df0a7dc15fbbbef60be9f7bb  arm64: dts: qcom: sc7180: Update iommu property for simultaneous playback

elapsed time: 722m

configs tested: 169
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
arm64                            alldefconfig
powerpc                        fsp2_defconfig
riscv                    nommu_virt_defconfig
sh                        dreamcast_defconfig
powerpc                     ppa8548_defconfig
xtensa                  cadence_csp_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
um                                allnoconfig
powerpc                      ep88xc_defconfig
powerpc                    socrates_defconfig
sparc                       sparc64_defconfig
arm                        magician_defconfig
m68k                            mac_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
s390                             allmodconfig
arm                        vexpress_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
powerpc                          g5_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlr_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
mips                      fuloong2e_defconfig
parisc                generic-64bit_defconfig
mips                        maltaup_defconfig
arm                           h5000_defconfig
powerpc                     mpc83xx_defconfig
arm                         hackkit_defconfig
powerpc                     ep8248e_defconfig
xtensa                       common_defconfig
h8300                               defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
ia64                             allmodconfig
powerpc                 xes_mpc85xx_defconfig
ia64                                defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
sh                        sh7785lcr_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419
x86_64               randconfig-a004-20210420
x86_64               randconfig-a002-20210420
x86_64               randconfig-a001-20210420
x86_64               randconfig-a005-20210420
x86_64               randconfig-a006-20210420
x86_64               randconfig-a003-20210420

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:54 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:54 +0800
Subject: [soc:qcom/dt-3] BUILD SUCCESS 06ad53efeb496d8841169ec0919ba6852c7852f6
Message-ID: <607e584a.ERHY6Nf2kFpodfnu%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/dt-3
branch HEAD: 06ad53efeb496d8841169ec0919ba6852c7852f6  ARM: dts: qcom: sdx55: add IPA information

elapsed time: 722m

configs tested: 155
configs skipped: 5

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
um                                allnoconfig
powerpc                      ep88xc_defconfig
powerpc                    socrates_defconfig
sparc                       sparc64_defconfig
arm                        magician_defconfig
m68k                            mac_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
s390                             allmodconfig
arm                        vexpress_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
powerpc                          g5_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlr_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
mips                      fuloong2e_defconfig
parisc                generic-64bit_defconfig
mips                        maltaup_defconfig
arm                           h5000_defconfig
powerpc                     mpc83xx_defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
ia64                             allmodconfig
powerpc                 xes_mpc85xx_defconfig
ia64                                defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
arm64                            alldefconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
sh                        sh7785lcr_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:45 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:45 +0800
Subject: [soc:qcom/defconfig-2] BUILD SUCCESS
 7de91b665600c96b1fc66c4c5a679db275c0c674
Message-ID: <607e5841.FM+e0RgDJOmBAN5M%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git qcom/defconfig-2
branch HEAD: 7de91b665600c96b1fc66c4c5a679db275c0c674  ARM: configs: qcom_defconfig: Reduce CMA size to 64MB

elapsed time: 722m

configs tested: 159
configs skipped: 18

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
nds32                             allnoconfig
mips                      pic32mzda_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
powerpc                  mpc866_ads_defconfig
sh                          r7780mp_defconfig
powerpc                       ebony_defconfig
powerpc                     rainier_defconfig
arm64                            alldefconfig
powerpc                        fsp2_defconfig
riscv                    nommu_virt_defconfig
sh                        dreamcast_defconfig
powerpc                     ppa8548_defconfig
xtensa                  cadence_csp_defconfig
sh                          rsk7203_defconfig
powerpc                 mpc8272_ads_defconfig
mips                          rb532_defconfig
sh                        edosk7705_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
s390                             allmodconfig
arm                        vexpress_defconfig
alpha                            alldefconfig
arm                            lart_defconfig
powerpc                          g5_defconfig
powerpc                      bamboo_defconfig
mips                        nlm_xlr_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
mips                      fuloong2e_defconfig
parisc                generic-64bit_defconfig
mips                        maltaup_defconfig
arm                           h5000_defconfig
powerpc                     mpc83xx_defconfig
sh                           se7705_defconfig
powerpc                     redwood_defconfig
ia64                             allmodconfig
powerpc                 xes_mpc85xx_defconfig
ia64                                defconfig
powerpc                      katmai_defconfig
sh                         ecovec24_defconfig
sh                          rsk7201_defconfig
powerpc                    socrates_defconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
parisc                           alldefconfig
powerpc                       holly_defconfig
i386                                defconfig
sh                        sh7785lcr_defconfig
m68k                          multi_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419
x86_64               randconfig-a004-20210420
x86_64               randconfig-a002-20210420
x86_64               randconfig-a001-20210420
x86_64               randconfig-a005-20210420
x86_64               randconfig-a006-20210420
x86_64               randconfig-a003-20210420

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 05:27:58 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 12:27:58 +0800
Subject: [soc:for-next] BUILD SUCCESS 68738a74f4c7f60fd78012af6540e77ec0f60e94
Message-ID: <607e584e.o1TxuJO/dKJXLSV3%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 68738a74f4c7f60fd78012af6540e77ec0f60e94  soc: document merges

elapsed time: 722m

configs tested: 121
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
m68k                        mvme16x_defconfig
powerpc                 mpc832x_mds_defconfig
mips                           xway_defconfig
sh                             espt_defconfig
sparc64                          alldefconfig
powerpc                   motionpro_defconfig
sh                         ap325rxa_defconfig
mips                      pic32mzda_defconfig
openrisc                  or1klitex_defconfig
sh                         microdev_defconfig
arm                             rpc_defconfig
xtensa                         virt_defconfig
sh                 kfr2r09-romimage_defconfig
arm                        trizeps4_defconfig
powerpc                      ppc44x_defconfig
powerpc                 mpc836x_mds_defconfig
arm                         hackkit_defconfig
powerpc                      ep88xc_defconfig
powerpc                     ep8248e_defconfig
xtensa                       common_defconfig
h8300                               defconfig
powerpc                    socrates_defconfig
arm64                            alldefconfig
mips                          malta_defconfig
powerpc                mpc7448_hpc2_defconfig
arm                          pxa910_defconfig
sh                         ecovec24_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
arc                    vdk_hs38_smp_defconfig
sparc                       sparc32_defconfig
arm                          imote2_defconfig
sh                           se7751_defconfig
m68k                       m5275evb_defconfig
sh                        sh7785lcr_defconfig
powerpc                        icon_defconfig
arm                       omap2plus_defconfig
sh                   sh7724_generic_defconfig
mips                     loongson1b_defconfig
powerpc                          g5_defconfig
arm                      footbridge_defconfig
powerpc                     sequoia_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210419
i386                 randconfig-a001-20210419
i386                 randconfig-a006-20210419
i386                 randconfig-a005-20210419
i386                 randconfig-a004-20210419
i386                 randconfig-a002-20210419
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From leoyang.li at nxp.com  Tue Apr 20 05:33:58 2021
From: leoyang.li at nxp.com (Li Yang)
Date: Mon, 19 Apr 2021 23:33:58 -0500
Subject: [PATCH] arm64: dts: ls1028a-rdb: enable optee node
In-Reply-To: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
References: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
Message-ID: <CADRPPNSdDU-G-sLe8j27Rmd923jSWKirRdYS9qzZMHotsMuKCQ@mail.gmail.com>

On Tue, Mar 30, 2021 at 9:53 AM Sahil Malhotra
<sahil.malhotra at oss.nxp.com> wrote:
>
> From: Sahil Malhotra <sahil.malhotra at nxp.com>
>
> optee node was disabled by default, enabling it for ls1028a-rdb.
>
> Signed-off-by: Michael Walle <michael at walle.cc>
> Signed-off-by: Sahil Malhotra <sahil.malhotra at nxp.com>

Acked-by: Li Yang <leoyang.li at nxp.com>

> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 4 ++++
>  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi    | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index 41ae6e7675ba..1bdf0104d492 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -274,6 +274,10 @@
>         status = "okay";
>  };
>
> +&optee {
> +       status = "okay";
> +};
> +
>  &sai4 {
>         status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 262fbad8f0ec..fb155ac192b1 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -92,7 +92,7 @@
>         };
>
>         firmware {
> -               optee {
> +               optee: optee  {
>                         compatible = "linaro,optee-tz";
>                         method = "smc";
>                         status = "disabled";
> --
> 2.17.1
>


From chenxiang66 at hisilicon.com  Tue Apr 20 06:59:17 2021
From: chenxiang66 at hisilicon.com (chenxiang (M))
Date: Tue, 20 Apr 2021 13:59:17 +0800
Subject: [RFC PATCH v5 11/15] iommu/io-pgtable-arm: Implement
 arm_lpae_map_pages()
In-Reply-To: <20210408171402.12607-12-isaacm@codeaurora.org>
References: <20210408171402.12607-1-isaacm@codeaurora.org>
 <20210408171402.12607-12-isaacm@codeaurora.org>
Message-ID: <ab7e8274-b679-a8da-405d-ad880f189316@hisilicon.com>

Hi Isaac,


? 2021/4/9 1:13, Isaac J. Manjarres ??:
> Implement the map_pages() callback for the ARM LPAE io-pgtable
> format.
>
> Signed-off-by: Isaac J. Manjarres <isaacm at codeaurora.org>
> ---
>   drivers/iommu/io-pgtable-arm.c | 42 ++++++++++++++++++++++++++--------
>   1 file changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 1b690911995a..92978dd9c885 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -344,20 +344,30 @@ static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
>   }
>   
>   static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova,
> -			  phys_addr_t paddr, size_t size, arm_lpae_iopte prot,
> -			  int lvl, arm_lpae_iopte *ptep, gfp_t gfp)
> +			  phys_addr_t paddr, size_t size, size_t pgcount,
> +			  arm_lpae_iopte prot, int lvl, arm_lpae_iopte *ptep,
> +			  gfp_t gfp, size_t *mapped)
>   {
>   	arm_lpae_iopte *cptep, pte;
>   	size_t block_size = ARM_LPAE_BLOCK_SIZE(lvl, data);
>   	size_t tblsz = ARM_LPAE_GRANULE(data);
>   	struct io_pgtable_cfg *cfg = &data->iop.cfg;
> +	int ret = 0, num_entries, max_entries, map_idx_start;
>   
>   	/* Find our entry at the current level */
> -	ptep += ARM_LPAE_LVL_IDX(iova, lvl, data);
> +	map_idx_start = ARM_LPAE_LVL_IDX(iova, lvl, data);
> +	ptep += map_idx_start;
>   
>   	/* If we can install a leaf entry at this level, then do so */
> -	if (size == block_size)
> -		return arm_lpae_init_pte(data, iova, paddr, prot, lvl, 1, ptep);
> +	if (size == block_size) {
> +		max_entries = ARM_LPAE_PTES_PER_TABLE(data) - map_idx_start;
> +		num_entries = min_t(int, pgcount, max_entries);
> +		ret = arm_lpae_init_pte(data, iova, paddr, prot, lvl, num_entries, ptep);
> +		if (!ret && mapped)
> +			*mapped += num_entries * size;
> +
> +		return ret;
> +	}
>   
>   	/* We can't allocate tables at the final level */
>   	if (WARN_ON(lvl >= ARM_LPAE_MAX_LEVELS - 1))
> @@ -386,7 +396,8 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, unsigned long iova,
>   	}
>   
>   	/* Rinse, repeat */
> -	return __arm_lpae_map(data, iova, paddr, size, prot, lvl + 1, cptep, gfp);
> +	return __arm_lpae_map(data, iova, paddr, size, pgcount, prot, lvl + 1,
> +			      cptep, gfp, mapped);
>   }
>   
>   static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
> @@ -453,8 +464,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
>   	return pte;
>   }
>   
> -static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> -			phys_addr_t paddr, size_t size, int iommu_prot, gfp_t gfp)
> +static int arm_lpae_map_pages(struct io_pgtable_ops *ops, unsigned long iova,
> +			      phys_addr_t paddr, size_t pgsize, size_t pgcount,
> +			      int iommu_prot, gfp_t gfp, size_t *mapped)
>   {
>   	struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
>   	struct io_pgtable_cfg *cfg = &data->iop.cfg;
> @@ -463,7 +475,7 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>   	arm_lpae_iopte prot;
>   	long iaext = (s64)iova >> cfg->ias;
>   
> -	if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size))
> +	if (WARN_ON(!pgsize || (pgsize & cfg->pgsize_bitmap) != pgsize))
>   		return -EINVAL;
>   
>   	if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1)
> @@ -476,7 +488,8 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>   		return 0;
>   
>   	prot = arm_lpae_prot_to_pte(data, iommu_prot);
> -	ret = __arm_lpae_map(data, iova, paddr, size, prot, lvl, ptep, gfp);
> +	ret = __arm_lpae_map(data, iova, paddr, pgsize, pgcount, prot, lvl,
> +			     ptep, gfp, NULL);

The last input parameter should be mapped instead of NULL.

>   	/*
>   	 * Synchronise all PTE updates for the new mapping before there's
>   	 * a chance for anything to kick off a table walk for the new iova.
> @@ -486,6 +499,14 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>   	return ret;
>   }
>   
> +
> +static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> +			phys_addr_t paddr, size_t size, int iommu_prot, gfp_t gfp)
> +{
> +	return arm_lpae_map_pages(ops, iova, paddr, size, 1, iommu_prot, gfp,
> +				  NULL);
> +}
> +
>   static void __arm_lpae_free_pgtable(struct arm_lpae_io_pgtable *data, int lvl,
>   				    arm_lpae_iopte *ptep)
>   {
> @@ -782,6 +803,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
>   
>   	data->iop.ops = (struct io_pgtable_ops) {
>   		.map		= arm_lpae_map,
> +		.map_pages	= arm_lpae_map_pages,
>   		.unmap		= arm_lpae_unmap,
>   		.unmap_pages	= arm_lpae_unmap_pages,
>   		.iova_to_phys	= arm_lpae_iova_to_phys,




From jianjun.wang at mediatek.com  Tue Apr 20 07:17:16 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:16 +0800
Subject: [PATCH v10 0/7] PCI: mediatek: Add new generation controller support
Message-ID: <20210420061723.989-1-jianjun.wang@mediatek.com>

From: mtk15901 <jianjun.wang at mediatek.com>

These series patches add pcie-mediatek-gen3.c and dt-bindings file to
support new generation PCIe controller.

Changes in v10:
1. Fix the subject line format in commit message;
2. Use EXPORT_SYMBOL_GPL() to export pci_pio_to_address().

Changes in v9:
1. Use mtk_pcie_parse_port() to get the hw resources;
2. Remove unnecessary logs;
3. Add local IRQ enable status save/restore instead of
   the enable/disable callbacks;
4. Fix typos.

Changes in v8:
1. Add irq_clock to protect IRQ register access;
2. Mask all INTx interrupt when startup port;
3. Remove activate/deactivate callbacks from bottom_domain_ops;
4. Add unmask/mask callbacks in mtk_msi_bottom_irq_chip;
5. Add property information for reg-names.

Changes in v7:
1. Split the driver patch to core PCIe, INTx, MSI and PM patches;
2. Reshape MSI init and handle flow,
   use msi_bottom_domain to cover all sets;
3. Replace readl/writel with their relaxed version;
4. Add MSI description in binding document;
5. Add pl_250m clock in binding document.

Changes in v6:
1. Export pci_pio_to_address() to support compiling as kernel module;
2. Replace usleep_range(100 * 1000, 120 * 1000) with msleep(100);
3. Replace dev_notice with dev_err;
4. Fix MSI get hwirq flow;
5. Fix warning for possible recursive locking in mtk_pcie_set_affinity.

Changes in v5:
1. Remove unused macros
2. Modify the config read/write callbacks, set the config byte field
   in TLP header and use pci_generic_config_read32/write32
   to access the config space
3. Fix the settings of translation window, both MEM and IO regions
   works properly
4. Fix typos

Changes in v4:
1. Fix PCIe power up/down flow
2. Use "mac" and "phy" for reset names
3. Add clock names
4. Fix the variables type

Changes in v3:
1. Remove standard property in binding document
2. Return error number when get_optional* API throws an error
3. Use the bulk clk APIs

Changes in v2:
1. Fix the typo of dt-bindings patch
2. Remove the unnecessary properties in binding document
3. dispos the irq mappings of msi top domain when irq teardown

Jianjun Wang (7):
  dt-bindings: PCI: mediatek-gen3: Add YAML schema
  PCI: Export pci_pio_to_address() for module use
  PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
  PCI: mediatek-gen3: Add INTx support
  PCI: mediatek-gen3: Add MSI support
  PCI: mediatek-gen3: Add system PM support
  MAINTAINERS: Add Jianjun Wang as MediaTek PCI co-maintainer

 .../bindings/pci/mediatek-pcie-gen3.yaml      |  181 +++
 MAINTAINERS                                   |    1 +
 drivers/pci/controller/Kconfig                |   13 +
 drivers/pci/controller/Makefile               |    1 +
 drivers/pci/controller/pcie-mediatek-gen3.c   | 1025 +++++++++++++++++
 drivers/pci/pci.c                             |    1 +
 6 files changed, 1222 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
 create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c

-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:19 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:19 +0800
Subject: [PATCH v10 3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for
 MT8192
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-4-jianjun.wang@mediatek.com>

MediaTek's PCIe host controller has three generation HWs, the new
generation HW is an individual bridge, it supports Gen3 speed and
compatible with Gen2, Gen1 speed.

Add support for new Gen3 controller which can be found on MT8192.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
---
 drivers/pci/controller/Kconfig              |  13 +
 drivers/pci/controller/Makefile             |   1 +
 drivers/pci/controller/pcie-mediatek-gen3.c | 464 ++++++++++++++++++++
 3 files changed, 478 insertions(+)
 create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 5aa8977d7b0f..1e925ac47279 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -233,6 +233,19 @@ config PCIE_MEDIATEK
 	  Say Y here if you want to enable PCIe controller support on
 	  MediaTek SoCs.
 
+config PCIE_MEDIATEK_GEN3
+	tristate "MediaTek Gen3 PCIe controller"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on PCI_MSI_IRQ_DOMAIN
+	help
+	  Adds support for PCIe Gen3 MAC controller for MediaTek SoCs.
+	  This PCIe controller is compatible with Gen3, Gen2 and Gen1 speed,
+	  and support up to 256 MSI interrupt numbers for
+	  multi-function devices.
+
+	  Say Y here if you want to enable Gen3 PCIe controller support on
+	  MediaTek SoCs.
+
 config VMD
 	depends on PCI_MSI && X86_64 && SRCU
 	tristate "Intel Volume Management Device Driver"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index e4559f2182f2..579973327815 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
 obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
 obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
 obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
+obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o
 obj-$(CONFIG_PCIE_MICROCHIP_HOST) += pcie-microchip-host.o
 obj-$(CONFIG_VMD) += vmd.o
 obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
new file mode 100644
index 000000000000..3546e53b3c85
--- /dev/null
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -0,0 +1,464 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek PCIe host controller driver.
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Jianjun Wang <jianjun.wang at mediatek.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+
+#include "../pci.h"
+
+#define PCIE_SETTING_REG		0x80
+#define PCIE_PCI_IDS_1			0x9c
+#define PCI_CLASS(class)		(class << 8)
+#define PCIE_RC_MODE			BIT(0)
+
+#define PCIE_CFGNUM_REG			0x140
+#define PCIE_CFG_DEVFN(devfn)		((devfn) & GENMASK(7, 0))
+#define PCIE_CFG_BUS(bus)		(((bus) << 8) & GENMASK(15, 8))
+#define PCIE_CFG_BYTE_EN(bytes)		(((bytes) << 16) & GENMASK(19, 16))
+#define PCIE_CFG_FORCE_BYTE_EN		BIT(20)
+#define PCIE_CFG_OFFSET_ADDR		0x1000
+#define PCIE_CFG_HEADER(bus, devfn) \
+	(PCIE_CFG_BUS(bus) | PCIE_CFG_DEVFN(devfn))
+
+#define PCIE_RST_CTRL_REG		0x148
+#define PCIE_MAC_RSTB			BIT(0)
+#define PCIE_PHY_RSTB			BIT(1)
+#define PCIE_BRG_RSTB			BIT(2)
+#define PCIE_PE_RSTB			BIT(3)
+
+#define PCIE_LTSSM_STATUS_REG		0x150
+
+#define PCIE_LINK_STATUS_REG		0x154
+#define PCIE_PORT_LINKUP		BIT(8)
+
+#define PCIE_TRANS_TABLE_BASE_REG	0x800
+#define PCIE_ATR_SRC_ADDR_MSB_OFFSET	0x4
+#define PCIE_ATR_TRSL_ADDR_LSB_OFFSET	0x8
+#define PCIE_ATR_TRSL_ADDR_MSB_OFFSET	0xc
+#define PCIE_ATR_TRSL_PARAM_OFFSET	0x10
+#define PCIE_ATR_TLB_SET_OFFSET		0x20
+
+#define PCIE_MAX_TRANS_TABLES		8
+#define PCIE_ATR_EN			BIT(0)
+#define PCIE_ATR_SIZE(size) \
+	(((((size) - 1) << 1) & GENMASK(6, 1)) | PCIE_ATR_EN)
+#define PCIE_ATR_ID(id)			((id) & GENMASK(3, 0))
+#define PCIE_ATR_TYPE_MEM		PCIE_ATR_ID(0)
+#define PCIE_ATR_TYPE_IO		PCIE_ATR_ID(1)
+#define PCIE_ATR_TLP_TYPE(type)		(((type) << 16) & GENMASK(18, 16))
+#define PCIE_ATR_TLP_TYPE_MEM		PCIE_ATR_TLP_TYPE(0)
+#define PCIE_ATR_TLP_TYPE_IO		PCIE_ATR_TLP_TYPE(2)
+
+/**
+ * struct mtk_pcie_port - 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
+ * @clks: PCIe clocks
+ * @num_clks: PCIe clocks count for this port
+ */
+struct mtk_pcie_port {
+	struct device *dev;
+	void __iomem *base;
+	phys_addr_t reg_base;
+	struct reset_control *mac_reset;
+	struct reset_control *phy_reset;
+	struct phy *phy;
+	struct clk_bulk_data *clks;
+	int num_clks;
+};
+
+/**
+ * mtk_pcie_config_tlp_header() - Configure a configuration TLP header
+ * @bus: PCI bus to query
+ * @devfn: device/function number
+ * @where: offset in config space
+ * @size: data size in TLP header
+ *
+ * Set byte enable field and device information in configuration TLP header.
+ */
+static void mtk_pcie_config_tlp_header(struct pci_bus *bus, unsigned int devfn,
+					int where, int size)
+{
+	struct mtk_pcie_port *port = bus->sysdata;
+	int bytes;
+	u32 val;
+
+	bytes = (GENMASK(size - 1, 0) & 0xf) << (where & 0x3);
+
+	val = PCIE_CFG_FORCE_BYTE_EN | PCIE_CFG_BYTE_EN(bytes) |
+	      PCIE_CFG_HEADER(bus->number, devfn);
+
+	writel_relaxed(val, port->base + PCIE_CFGNUM_REG);
+}
+
+static void __iomem *mtk_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
+				      int where)
+{
+	struct mtk_pcie_port *port = bus->sysdata;
+
+	return port->base + PCIE_CFG_OFFSET_ADDR + where;
+}
+
+static int mtk_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+				int where, int size, u32 *val)
+{
+	mtk_pcie_config_tlp_header(bus, devfn, where, size);
+
+	return pci_generic_config_read32(bus, devfn, where, size, val);
+}
+
+static int mtk_pcie_config_write(struct pci_bus *bus, unsigned int devfn,
+				 int where, int size, u32 val)
+{
+	mtk_pcie_config_tlp_header(bus, devfn, where, size);
+
+	if (size <= 2)
+		val <<= (where & 0x3) * 8;
+
+	return pci_generic_config_write32(bus, devfn, where, 4, val);
+}
+
+static struct pci_ops mtk_pcie_ops = {
+	.map_bus = mtk_pcie_map_bus,
+	.read  = mtk_pcie_config_read,
+	.write = mtk_pcie_config_write,
+};
+
+static int mtk_pcie_set_trans_table(struct mtk_pcie_port *port,
+				    resource_size_t cpu_addr,
+				    resource_size_t pci_addr,
+				    resource_size_t size,
+				    unsigned long type, int num)
+{
+	void __iomem *table;
+	u32 val;
+
+	if (num >= PCIE_MAX_TRANS_TABLES) {
+		dev_err(port->dev, "not enough translate table for addr: %#llx, limited to [%d]\n",
+			(unsigned long long)cpu_addr, PCIE_MAX_TRANS_TABLES);
+		return -ENODEV;
+	}
+
+	table = port->base + PCIE_TRANS_TABLE_BASE_REG +
+		num * PCIE_ATR_TLB_SET_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;
+	else
+		val = PCIE_ATR_TYPE_MEM | PCIE_ATR_TLP_TYPE_MEM;
+
+	writel_relaxed(val, table + PCIE_ATR_TRSL_PARAM_OFFSET);
+
+	return 0;
+}
+
+static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
+{
+	struct resource_entry *entry;
+	struct pci_host_bridge *host = pci_host_bridge_from_priv(port);
+	unsigned int table_index = 0;
+	int err;
+	u32 val;
+
+	/* Set as RC mode */
+	val = readl_relaxed(port->base + PCIE_SETTING_REG);
+	val |= PCIE_RC_MODE;
+	writel_relaxed(val, port->base + PCIE_SETTING_REG);
+
+	/* Set class code */
+	val = readl_relaxed(port->base + PCIE_PCI_IDS_1);
+	val &= ~GENMASK(31, 8);
+	val |= PCI_CLASS(PCI_CLASS_BRIDGE_PCI << 8);
+	writel_relaxed(val, port->base + PCIE_PCI_IDS_1);
+
+	/* Assert all reset signals */
+	val = readl_relaxed(port->base + PCIE_RST_CTRL_REG);
+	val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
+	writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
+
+	/*
+	 * Described in PCIe CEM specification setctions 2.2 (PERST# Signal)
+	 * and 2.2.1 (Initial Power-Up (G3 to S0)).
+	 * The deassertion of PERST# should be delayed 100ms (TPVPERL)
+	 * for the power and clock to become stable.
+	 */
+	msleep(100);
+
+	/* De-assert reset signals */
+	val &= ~(PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB);
+	writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
+
+	/* Check if the link is up or not */
+	err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_REG, val,
+				 !!(val & PCIE_PORT_LINKUP), 20,
+				 PCI_PM_D3COLD_WAIT * USEC_PER_MSEC);
+	if (err) {
+		val = readl_relaxed(port->base + PCIE_LTSSM_STATUS_REG);
+		dev_err(port->dev, "PCIe link down, ltssm reg val: %#x\n", val);
+		return err;
+	}
+
+	/* Set PCIe translation windows */
+	resource_list_for_each_entry(entry, &host->windows) {
+		struct resource *res = entry->res;
+		unsigned long type = resource_type(res);
+		resource_size_t cpu_addr;
+		resource_size_t pci_addr;
+		resource_size_t size;
+		const char *range_type;
+
+		if (type == IORESOURCE_IO) {
+			cpu_addr = pci_pio_to_address(res->start);
+			range_type = "IO";
+		} else if (type == IORESOURCE_MEM) {
+			cpu_addr = res->start;
+			range_type = "MEM";
+		} else {
+			continue;
+		}
+
+		pci_addr = res->start - entry->offset;
+		size = resource_size(res);
+		err = mtk_pcie_set_trans_table(port, cpu_addr, pci_addr, size,
+					       type, table_index);
+		if (err)
+			return err;
+
+		dev_dbg(port->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;
+}
+
+static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
+{
+	struct device *dev = port->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	struct resource *regs;
+	int ret;
+
+	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
+	port->base = devm_ioremap_resource(dev, regs);
+	if (IS_ERR(port->base)) {
+		dev_err(dev, "failed to map register base\n");
+		return PTR_ERR(port->base);
+	}
+
+	port->reg_base = regs->start;
+
+	port->phy_reset = devm_reset_control_get_optional_exclusive(dev, "phy");
+	if (IS_ERR(port->phy_reset)) {
+		ret = PTR_ERR(port->phy_reset);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get PHY reset\n");
+
+		return ret;
+	}
+
+	port->mac_reset = devm_reset_control_get_optional_exclusive(dev, "mac");
+	if (IS_ERR(port->mac_reset)) {
+		ret = PTR_ERR(port->mac_reset);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get MAC reset\n");
+
+		return ret;
+	}
+
+	port->phy = devm_phy_optional_get(dev, "pcie-phy");
+	if (IS_ERR(port->phy)) {
+		ret = PTR_ERR(port->phy);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get PHY\n");
+
+		return ret;
+	}
+
+	port->num_clks = devm_clk_bulk_get_all(dev, &port->clks);
+	if (port->num_clks < 0) {
+		dev_err(dev, "failed to get clocks\n");
+		return port->num_clks;
+	}
+
+	return 0;
+}
+
+static int mtk_pcie_power_up(struct mtk_pcie_port *port)
+{
+	struct device *dev = port->dev;
+	int err;
+
+	/* PHY power on and enable pipe clock */
+	reset_control_deassert(port->phy_reset);
+
+	err = phy_init(port->phy);
+	if (err) {
+		dev_err(dev, "failed to initialize PHY\n");
+		goto err_phy_init;
+	}
+
+	err = phy_power_on(port->phy);
+	if (err) {
+		dev_err(dev, "failed to power on PHY\n");
+		goto err_phy_on;
+	}
+
+	/* MAC power on and enable transaction layer clocks */
+	reset_control_deassert(port->mac_reset);
+
+	pm_runtime_enable(dev);
+	pm_runtime_get_sync(dev);
+
+	err = clk_bulk_prepare_enable(port->num_clks, port->clks);
+	if (err) {
+		dev_err(dev, "failed to enable clocks\n");
+		goto err_clk_init;
+	}
+
+	return 0;
+
+err_clk_init:
+	pm_runtime_put_sync(dev);
+	pm_runtime_disable(dev);
+	reset_control_assert(port->mac_reset);
+	phy_power_off(port->phy);
+err_phy_on:
+	phy_exit(port->phy);
+err_phy_init:
+	reset_control_assert(port->phy_reset);
+
+	return err;
+}
+
+static void mtk_pcie_power_down(struct mtk_pcie_port *port)
+{
+	clk_bulk_disable_unprepare(port->num_clks, port->clks);
+
+	pm_runtime_put_sync(port->dev);
+	pm_runtime_disable(port->dev);
+	reset_control_assert(port->mac_reset);
+
+	phy_power_off(port->phy);
+	phy_exit(port->phy);
+	reset_control_assert(port->phy_reset);
+}
+
+static int mtk_pcie_setup(struct mtk_pcie_port *port)
+{
+	int err;
+
+	err = mtk_pcie_parse_port(port);
+	if (err)
+		return err;
+
+	/* Don't touch the hardware registers before power up */
+	err = mtk_pcie_power_up(port);
+	if (err)
+		return err;
+
+	/* Try link up */
+	err = mtk_pcie_startup_port(port);
+	if (err)
+		goto err_setup;
+
+	return 0;
+
+err_setup:
+	mtk_pcie_power_down(port);
+
+	return err;
+}
+
+static int mtk_pcie_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_pcie_port *port;
+	struct pci_host_bridge *host;
+	int err;
+
+	host = devm_pci_alloc_host_bridge(dev, sizeof(*port));
+	if (!host)
+		return -ENOMEM;
+
+	port = pci_host_bridge_priv(host);
+
+	port->dev = dev;
+	platform_set_drvdata(pdev, port);
+
+	err = mtk_pcie_setup(port);
+	if (err)
+		return err;
+
+	host->ops = &mtk_pcie_ops;
+	host->sysdata = port;
+
+	err = pci_host_probe(host);
+	if (err) {
+		mtk_pcie_power_down(port);
+		return err;
+	}
+
+	return 0;
+}
+
+static int mtk_pcie_remove(struct platform_device *pdev)
+{
+	struct mtk_pcie_port *port = platform_get_drvdata(pdev);
+	struct pci_host_bridge *host = pci_host_bridge_from_priv(port);
+
+	pci_lock_rescan_remove();
+	pci_stop_root_bus(host->bus);
+	pci_remove_root_bus(host->bus);
+	pci_unlock_rescan_remove();
+
+	mtk_pcie_power_down(port);
+
+	return 0;
+}
+
+static const struct of_device_id mtk_pcie_of_match[] = {
+	{ .compatible = "mediatek,mt8192-pcie" },
+	{},
+};
+
+static struct platform_driver mtk_pcie_driver = {
+	.probe = mtk_pcie_probe,
+	.remove = mtk_pcie_remove,
+	.driver = {
+		.name = "mtk-pcie",
+		.of_match_table = mtk_pcie_of_match,
+	},
+};
+
+module_platform_driver(mtk_pcie_driver);
+MODULE_LICENSE("GPL v2");
-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:21 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:21 +0800
Subject: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-6-jianjun.wang@mediatek.com>

Add MSI support for MediaTek Gen3 PCIe controller.

This PCIe controller supports up to 256 MSI vectors, the MSI hardware
block diagram is as follows:

                  +-----+
                  | GIC |
                  +-----+
                     ^
                     |
                 port->irq
                     |
             +-+-+-+-+-+-+-+-+
             |0|1|2|3|4|5|6|7| (PCIe intc)
             +-+-+-+-+-+-+-+-+
              ^ ^           ^
              | |    ...    |
      +-------+ +------+    +-----------+
      |                |                |
+-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
|0|1|...|30|31|  |0|1|...|30|31|  |0|1|...|30|31| (MSI sets)
+-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
 ^ ^      ^  ^    ^ ^      ^  ^    ^ ^      ^  ^
 | |      |  |    | |      |  |    | |      |  |  (MSI vectors)
 | |      |  |    | |      |  |    | |      |  |

  (MSI SET0)       (MSI SET1)  ...   (MSI SET7)

With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
each set has its own address for MSI message, and supports 32 MSI vectors
to generate interrupt.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
Reviewed-by: Marc Zyngier <maz at kernel.org>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 276 ++++++++++++++++++++
 1 file changed, 276 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index ff91ad587461..ee1b51207d11 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -14,6 +14,7 @@
 #include <linux/irqdomain.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/msi.h>
 #include <linux/pci.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
@@ -48,12 +49,29 @@
 #define PCIE_LINK_STATUS_REG		0x154
 #define PCIE_PORT_LINKUP		BIT(8)
 
+#define PCIE_MSI_SET_NUM		8
+#define PCIE_MSI_IRQS_PER_SET		32
+#define PCIE_MSI_IRQS_NUM \
+	(PCIE_MSI_IRQS_PER_SET * PCIE_MSI_SET_NUM)
+
 #define PCIE_INT_ENABLE_REG		0x180
+#define PCIE_MSI_ENABLE			GENMASK(PCIE_MSI_SET_NUM + 8 - 1, 8)
+#define PCIE_MSI_SHIFT			8
 #define PCIE_INTX_SHIFT			24
 #define PCIE_INTX_ENABLE \
 	GENMASK(PCIE_INTX_SHIFT + PCI_NUM_INTX - 1, PCIE_INTX_SHIFT)
 
 #define PCIE_INT_STATUS_REG		0x184
+#define PCIE_MSI_SET_ENABLE_REG		0x190
+#define PCIE_MSI_SET_ENABLE		GENMASK(PCIE_MSI_SET_NUM - 1, 0)
+
+#define PCIE_MSI_SET_BASE_REG		0xc00
+#define PCIE_MSI_SET_OFFSET		0x10
+#define PCIE_MSI_SET_STATUS_OFFSET	0x04
+#define PCIE_MSI_SET_ENABLE_OFFSET	0x08
+
+#define PCIE_MSI_SET_ADDR_HI_BASE	0xc80
+#define PCIE_MSI_SET_ADDR_HI_OFFSET	0x04
 
 #define PCIE_TRANS_TABLE_BASE_REG	0x800
 #define PCIE_ATR_SRC_ADDR_MSB_OFFSET	0x4
@@ -73,6 +91,16 @@
 #define PCIE_ATR_TLP_TYPE_MEM		PCIE_ATR_TLP_TYPE(0)
 #define PCIE_ATR_TLP_TYPE_IO		PCIE_ATR_TLP_TYPE(2)
 
+/**
+ * struct mtk_msi_set - MSI information for each set
+ * @base: IO mapped register base
+ * @msg_addr: MSI message address
+ */
+struct mtk_msi_set {
+	void __iomem *base;
+	phys_addr_t msg_addr;
+};
+
 /**
  * struct mtk_pcie_port - PCIe port information
  * @dev: pointer to PCIe device
@@ -86,6 +114,11 @@
  * @irq: PCIe controller interrupt number
  * @irq_lock: lock protecting IRQ register access
  * @intx_domain: legacy INTx IRQ domain
+ * @msi_domain: MSI IRQ domain
+ * @msi_bottom_domain: MSI IRQ bottom domain
+ * @msi_sets: MSI sets information
+ * @lock: lock protecting IRQ bit map
+ * @msi_irq_in_use: bit map for assigned MSI IRQ
  */
 struct mtk_pcie_port {
 	struct device *dev;
@@ -100,6 +133,11 @@ struct mtk_pcie_port {
 	int irq;
 	raw_spinlock_t irq_lock;
 	struct irq_domain *intx_domain;
+	struct irq_domain *msi_domain;
+	struct irq_domain *msi_bottom_domain;
+	struct mtk_msi_set msi_sets[PCIE_MSI_SET_NUM];
+	struct mutex lock;
+	DECLARE_BITMAP(msi_irq_in_use, PCIE_MSI_IRQS_NUM);
 };
 
 /**
@@ -196,6 +234,35 @@ static int mtk_pcie_set_trans_table(struct mtk_pcie_port *port,
 	return 0;
 }
 
+static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
+{
+	int i;
+	u32 val;
+
+	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
+		struct mtk_msi_set *msi_set = &port->msi_sets[i];
+
+		msi_set->base = port->base + PCIE_MSI_SET_BASE_REG +
+				i * PCIE_MSI_SET_OFFSET;
+		msi_set->msg_addr = port->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),
+			       port->base + PCIE_MSI_SET_ADDR_HI_BASE +
+			       i * PCIE_MSI_SET_ADDR_HI_OFFSET);
+	}
+
+	val = readl_relaxed(port->base + PCIE_MSI_SET_ENABLE_REG);
+	val |= PCIE_MSI_SET_ENABLE;
+	writel_relaxed(val, port->base + PCIE_MSI_SET_ENABLE_REG);
+
+	val = readl_relaxed(port->base + PCIE_INT_ENABLE_REG);
+	val |= PCIE_MSI_ENABLE;
+	writel_relaxed(val, port->base + PCIE_INT_ENABLE_REG);
+}
+
 static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
 {
 	struct resource_entry *entry;
@@ -247,6 +314,8 @@ static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
 		return err;
 	}
 
+	mtk_pcie_enable_msi(port);
+
 	/* Set PCIe translation windows */
 	resource_list_for_each_entry(entry, &host->windows) {
 		struct resource *res = entry->res;
@@ -289,6 +358,147 @@ static int mtk_pcie_set_affinity(struct irq_data *data,
 	return -EINVAL;
 }
 
+static void mtk_pcie_msi_irq_mask(struct irq_data *data)
+{
+	pci_msi_mask_irq(data);
+	irq_chip_mask_parent(data);
+}
+
+static void mtk_pcie_msi_irq_unmask(struct irq_data *data)
+{
+	pci_msi_unmask_irq(data);
+	irq_chip_unmask_parent(data);
+}
+
+static struct irq_chip mtk_msi_irq_chip = {
+	.irq_ack = irq_chip_ack_parent,
+	.irq_mask = mtk_pcie_msi_irq_mask,
+	.irq_unmask = mtk_pcie_msi_irq_unmask,
+	.name = "MSI",
+};
+
+static struct msi_domain_info mtk_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+		   MSI_FLAG_PCI_MSIX | MSI_FLAG_MULTI_PCI_MSI),
+	.chip	= &mtk_msi_irq_chip,
+};
+
+static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
+	struct mtk_pcie_port *port = data->domain->host_data;
+	unsigned long hwirq;
+
+	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
+
+	msg->address_hi = upper_32_bits(msi_set->msg_addr);
+	msg->address_lo = lower_32_bits(msi_set->msg_addr);
+	msg->data = hwirq;
+	dev_dbg(port->dev, "msi#%#lx address_hi %#x address_lo %#x data %d\n",
+		hwirq, msg->address_hi, msg->address_lo, msg->data);
+}
+
+static void mtk_msi_bottom_irq_ack(struct irq_data *data)
+{
+	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
+	unsigned long hwirq;
+
+	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
+
+	writel_relaxed(BIT(hwirq), msi_set->base + PCIE_MSI_SET_STATUS_OFFSET);
+}
+
+static void mtk_msi_bottom_irq_mask(struct irq_data *data)
+{
+	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
+	struct mtk_pcie_port *port = data->domain->host_data;
+	unsigned long hwirq, flags;
+	u32 val;
+
+	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
+
+	raw_spin_lock_irqsave(&port->irq_lock, flags);
+	val = readl_relaxed(msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+	val &= ~BIT(hwirq);
+	writel_relaxed(val, msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+	raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static void mtk_msi_bottom_irq_unmask(struct irq_data *data)
+{
+	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
+	struct mtk_pcie_port *port = data->domain->host_data;
+	unsigned long hwirq, flags;
+	u32 val;
+
+	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
+
+	raw_spin_lock_irqsave(&port->irq_lock, flags);
+	val = readl_relaxed(msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+	val |= BIT(hwirq);
+	writel_relaxed(val, msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+	raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static struct irq_chip mtk_msi_bottom_irq_chip = {
+	.irq_ack		= mtk_msi_bottom_irq_ack,
+	.irq_mask		= mtk_msi_bottom_irq_mask,
+	.irq_unmask		= mtk_msi_bottom_irq_unmask,
+	.irq_compose_msi_msg	= mtk_compose_msi_msg,
+	.irq_set_affinity	= mtk_pcie_set_affinity,
+	.name			= "MSI",
+};
+
+static int mtk_msi_bottom_domain_alloc(struct irq_domain *domain,
+				       unsigned int virq, unsigned int nr_irqs,
+				       void *arg)
+{
+	struct mtk_pcie_port *port = domain->host_data;
+	struct mtk_msi_set *msi_set;
+	int i, hwirq, set_idx;
+
+	mutex_lock(&port->lock);
+
+	hwirq = bitmap_find_free_region(port->msi_irq_in_use, PCIE_MSI_IRQS_NUM,
+					order_base_2(nr_irqs));
+
+	mutex_unlock(&port->lock);
+
+	if (hwirq < 0)
+		return -ENOSPC;
+
+	set_idx = hwirq / PCIE_MSI_IRQS_PER_SET;
+	msi_set = &port->msi_sets[set_idx];
+
+	for (i = 0; i < nr_irqs; i++)
+		irq_domain_set_info(domain, virq + i, hwirq + i,
+				    &mtk_msi_bottom_irq_chip, msi_set,
+				    handle_edge_irq, NULL, NULL);
+
+	return 0;
+}
+
+static void mtk_msi_bottom_domain_free(struct irq_domain *domain,
+				       unsigned int virq, unsigned int nr_irqs)
+{
+	struct mtk_pcie_port *port = domain->host_data;
+	struct irq_data *data = irq_domain_get_irq_data(domain, virq);
+
+	mutex_lock(&port->lock);
+
+	bitmap_release_region(port->msi_irq_in_use, data->hwirq,
+			      order_base_2(nr_irqs));
+
+	mutex_unlock(&port->lock);
+
+	irq_domain_free_irqs_common(domain, virq, nr_irqs);
+}
+
+static const struct irq_domain_ops mtk_msi_bottom_domain_ops = {
+	.alloc = mtk_msi_bottom_domain_alloc,
+	.free = mtk_msi_bottom_domain_free,
+};
+
 static void mtk_intx_mask(struct irq_data *data)
 {
 	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
@@ -357,6 +567,7 @@ static int mtk_pcie_init_irq_domains(struct mtk_pcie_port *port)
 {
 	struct device *dev = port->dev;
 	struct device_node *intc_node, *node = dev->of_node;
+	int ret;
 
 	raw_spin_lock_init(&port->irq_lock);
 
@@ -374,7 +585,34 @@ static int mtk_pcie_init_irq_domains(struct mtk_pcie_port *port)
 		return -ENODEV;
 	}
 
+	/* Setup MSI */
+	mutex_init(&port->lock);
+
+	port->msi_bottom_domain = irq_domain_add_linear(node, PCIE_MSI_IRQS_NUM,
+				  &mtk_msi_bottom_domain_ops, port);
+	if (!port->msi_bottom_domain) {
+		dev_err(dev, "failed to create MSI bottom domain\n");
+		ret = -ENODEV;
+		goto err_msi_bottom_domain;
+	}
+
+	port->msi_domain = pci_msi_create_irq_domain(dev->fwnode,
+						     &mtk_msi_domain_info,
+						     port->msi_bottom_domain);
+	if (!port->msi_domain) {
+		dev_err(dev, "failed to create MSI domain\n");
+		ret = -ENODEV;
+		goto err_msi_domain;
+	}
+
 	return 0;
+
+err_msi_domain:
+	irq_domain_remove(port->msi_bottom_domain);
+err_msi_bottom_domain:
+	irq_domain_remove(port->intx_domain);
+
+	return ret;
 }
 
 static void mtk_pcie_irq_teardown(struct mtk_pcie_port *port)
@@ -384,9 +622,39 @@ static void mtk_pcie_irq_teardown(struct mtk_pcie_port *port)
 	if (port->intx_domain)
 		irq_domain_remove(port->intx_domain);
 
+	if (port->msi_domain)
+		irq_domain_remove(port->msi_domain);
+
+	if (port->msi_bottom_domain)
+		irq_domain_remove(port->msi_bottom_domain);
+
 	irq_dispose_mapping(port->irq);
 }
 
+static void mtk_pcie_msi_handler(struct mtk_pcie_port *port, int set_idx)
+{
+	struct mtk_msi_set *msi_set = &port->msi_sets[set_idx];
+	unsigned long msi_enable, msi_status;
+	unsigned int virq;
+	irq_hw_number_t bit, hwirq;
+
+	msi_enable = readl_relaxed(msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+
+	do {
+		msi_status = readl_relaxed(msi_set->base +
+					   PCIE_MSI_SET_STATUS_OFFSET);
+		msi_status &= msi_enable;
+		if (!msi_status)
+			break;
+
+		for_each_set_bit(bit, &msi_status, PCIE_MSI_IRQS_PER_SET) {
+			hwirq = bit + set_idx * PCIE_MSI_IRQS_PER_SET;
+			virq = irq_find_mapping(port->msi_bottom_domain, hwirq);
+			generic_handle_irq(virq);
+		}
+	} while (true);
+}
+
 static void mtk_pcie_irq_handler(struct irq_desc *desc)
 {
 	struct mtk_pcie_port *port = irq_desc_get_handler_data(desc);
@@ -405,6 +673,14 @@ static void mtk_pcie_irq_handler(struct irq_desc *desc)
 		generic_handle_irq(virq);
 	}
 
+	irq_bit = PCIE_MSI_SHIFT;
+	for_each_set_bit_from(irq_bit, &status, PCIE_MSI_SET_NUM +
+			      PCIE_MSI_SHIFT) {
+		mtk_pcie_msi_handler(port, irq_bit - PCIE_MSI_SHIFT);
+
+		writel_relaxed(BIT(irq_bit), port->base + PCIE_INT_STATUS_REG);
+	}
+
 	chained_irq_exit(irqchip, desc);
 }
 
-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:22 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:22 +0800
Subject: [PATCH v10 6/7] PCI: mediatek-gen3: Add system PM support
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-7-jianjun.wang@mediatek.com>

Add suspend_noirq and resume_noirq callback functions to implement PM
system suspend and resume hooks for the MediaTek Gen3 PCIe controller.

When the system suspends, trigger the PCIe link to enter the L2 state
and pull down the PERST# pin, gating the clocks of the MAC layer, and
then power-off the physical layer to provide power-saving.

When the system resumes, the PCIe link should be re-established and the
related control register values should be restored.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 113 ++++++++++++++++++++
 1 file changed, 113 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index ee1b51207d11..20165e4a75b2 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -45,6 +45,9 @@
 #define PCIE_PE_RSTB			BIT(3)
 
 #define PCIE_LTSSM_STATUS_REG		0x150
+#define PCIE_LTSSM_STATE_MASK		GENMASK(28, 24)
+#define PCIE_LTSSM_STATE(val)		((val & PCIE_LTSSM_STATE_MASK) >> 24)
+#define PCIE_LTSSM_STATE_L2_IDLE	0x14
 
 #define PCIE_LINK_STATUS_REG		0x154
 #define PCIE_PORT_LINKUP		BIT(8)
@@ -73,6 +76,9 @@
 #define PCIE_MSI_SET_ADDR_HI_BASE	0xc80
 #define PCIE_MSI_SET_ADDR_HI_OFFSET	0x04
 
+#define PCIE_ICMD_PM_REG		0x198
+#define PCIE_TURN_OFF_LINK		BIT(4)
+
 #define PCIE_TRANS_TABLE_BASE_REG	0x800
 #define PCIE_ATR_SRC_ADDR_MSB_OFFSET	0x4
 #define PCIE_ATR_TRSL_ADDR_LSB_OFFSET	0x8
@@ -95,10 +101,12 @@
  * struct mtk_msi_set - MSI information for each set
  * @base: IO mapped register base
  * @msg_addr: MSI message address
+ * @saved_irq_state: IRQ enable state saved at suspend time
  */
 struct mtk_msi_set {
 	void __iomem *base;
 	phys_addr_t msg_addr;
+	u32 saved_irq_state;
 };
 
 /**
@@ -112,6 +120,7 @@ struct mtk_msi_set {
  * @clks: PCIe clocks
  * @num_clks: PCIe clocks count for this port
  * @irq: PCIe controller interrupt number
+ * @saved_irq_state: IRQ enable state saved at suspend time
  * @irq_lock: lock protecting IRQ register access
  * @intx_domain: legacy INTx IRQ domain
  * @msi_domain: MSI IRQ domain
@@ -131,6 +140,7 @@ struct mtk_pcie_port {
 	int num_clks;
 
 	int irq;
+	u32 saved_irq_state;
 	raw_spinlock_t irq_lock;
 	struct irq_domain *intx_domain;
 	struct irq_domain *msi_domain;
@@ -894,6 +904,108 @@ static int mtk_pcie_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static void __maybe_unused mtk_pcie_irq_save(struct mtk_pcie_port *port)
+{
+	int i;
+
+	raw_spin_lock(&port->irq_lock);
+
+	port->saved_irq_state = readl_relaxed(port->base + PCIE_INT_ENABLE_REG);
+
+	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
+		struct mtk_msi_set *msi_set = &port->msi_sets[i];
+
+		msi_set->saved_irq_state = readl_relaxed(msi_set->base +
+					   PCIE_MSI_SET_ENABLE_OFFSET);
+	}
+
+	raw_spin_unlock(&port->irq_lock);
+}
+
+static void __maybe_unused mtk_pcie_irq_restore(struct mtk_pcie_port *port)
+{
+	int i;
+
+	raw_spin_lock(&port->irq_lock);
+
+	writel_relaxed(port->saved_irq_state, port->base + PCIE_INT_ENABLE_REG);
+
+	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
+		struct mtk_msi_set *msi_set = &port->msi_sets[i];
+
+		writel_relaxed(msi_set->saved_irq_state,
+			       msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
+	}
+
+	raw_spin_unlock(&port->irq_lock);
+}
+
+static int __maybe_unused mtk_pcie_turn_off_link(struct mtk_pcie_port *port)
+{
+	u32 val;
+
+	val = readl_relaxed(port->base + PCIE_ICMD_PM_REG);
+	val |= PCIE_TURN_OFF_LINK;
+	writel_relaxed(val, port->base + PCIE_ICMD_PM_REG);
+
+	/* Check the link is L2 */
+	return readl_poll_timeout(port->base + PCIE_LTSSM_STATUS_REG, val,
+				  (PCIE_LTSSM_STATE(val) ==
+				   PCIE_LTSSM_STATE_L2_IDLE), 20,
+				   50 * USEC_PER_MSEC);
+}
+
+static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
+{
+	struct mtk_pcie_port *port = dev_get_drvdata(dev);
+	int err;
+	u32 val;
+
+	/* Trigger link to L2 state */
+	err = mtk_pcie_turn_off_link(port);
+	if (err) {
+		dev_err(port->dev, "cannot enter L2 state\n");
+		return err;
+	}
+
+	/* Pull down the PERST# pin */
+	val = readl_relaxed(port->base + PCIE_RST_CTRL_REG);
+	val |= PCIE_PE_RSTB;
+	writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
+
+	dev_dbg(port->dev, "entered L2 states successfully");
+
+	mtk_pcie_irq_save(port);
+	mtk_pcie_power_down(port);
+
+	return 0;
+}
+
+static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
+{
+	struct mtk_pcie_port *port = dev_get_drvdata(dev);
+	int err;
+
+	err = mtk_pcie_power_up(port);
+	if (err)
+		return err;
+
+	err = mtk_pcie_startup_port(port);
+	if (err) {
+		mtk_pcie_power_down(port);
+		return err;
+	}
+
+	mtk_pcie_irq_restore(port);
+
+	return 0;
+}
+
+static const struct dev_pm_ops mtk_pcie_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_pcie_suspend_noirq,
+				      mtk_pcie_resume_noirq)
+};
+
 static const struct of_device_id mtk_pcie_of_match[] = {
 	{ .compatible = "mediatek,mt8192-pcie" },
 	{},
@@ -905,6 +1017,7 @@ static struct platform_driver mtk_pcie_driver = {
 	.driver = {
 		.name = "mtk-pcie",
 		.of_match_table = mtk_pcie_of_match,
+		.pm = &mtk_pcie_pm_ops,
 	},
 };
 
-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:23 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:23 +0800
Subject: [PATCH v10 7/7] MAINTAINERS: Add Jianjun Wang as MediaTek PCI
 co-maintainer
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-8-jianjun.wang@mediatek.com>

Update entry for MediaTek PCIe controller, add Jianjun Wang
as MediaTek PCI co-maintainer.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..8050c14e6a7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13919,6 +13919,7 @@ F:	drivers/pci/controller/dwc/pcie-histb.c
 
 PCIE DRIVER FOR MEDIATEK
 M:	Ryder Lee <ryder.lee at mediatek.com>
+M:	Jianjun Wang <jianjun.wang at mediatek.com>
 L:	linux-pci at vger.kernel.org
 L:	linux-mediatek at lists.infradead.org
 S:	Supported
-- 
2.25.1

From inki.dae at samsung.com  Tue Apr 20 07:31:27 2021
From: inki.dae at samsung.com (Inki Dae)
Date: Tue, 20 Apr 2021 15:31:27 +0900
Subject: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210413094904.3736372-3-daniel.vetter@ffwll.ch>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <CGME20210413094922epcas1p47e75ce008a78971af7a923aadc0b9d3b@epcas1p4.samsung.com>
 <20210413094904.3736372-3-daniel.vetter@ffwll.ch>
Message-ID: <df4acc12-27da-3a81-6e2b-eee197107341@samsung.com>



21. 4. 13. ?? 6:48? Daniel Vetter ?(?) ? ?:
> Since
> 
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> Date:   Fri Jan 4 09:56:10 2019 +0100
> 
>     drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> 
> this is done automatically as part of plane init, if drivers set the
> modifier list correctly. Which is the case here.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>

Acked-by: Inki Dae <inki.dae at samsung.com>

Thanks,
Inki Dae

> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> Cc: Kyungmin Park <kyungmin.park at samsung.com>
> Cc: Krzysztof Kozlowski <krzk at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 64370b634cca..79fa3649185c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
>  	dev->mode_config.funcs = &exynos_drm_mode_config_funcs;
>  	dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
>  
> -	dev->mode_config.allow_fb_modifiers = true;
> -
>  	dev->mode_config.normalize_zpos = true;
>  }
> 


From jianjun.wang at mediatek.com  Tue Apr 20 07:17:18 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:18 +0800
Subject: [PATCH v10 2/7] PCI: Export pci_pio_to_address() for module use
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-3-jianjun.wang@mediatek.com>

This interface will be used by PCI host drivers for PIO translation,
export it to support compiling those drivers as kernel modules.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 16a17215f633..09f1714e23be 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4052,6 +4052,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
 
 	return address;
 }
+EXPORT_SYMBOL_GPL(pci_pio_to_address);
 
 unsigned long __weak pci_address_to_pio(phys_addr_t address)
 {
-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:17 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:17 +0800
Subject: [PATCH v10 1/7] dt-bindings: PCI: mediatek-gen3: Add YAML schema
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-2-jianjun.wang@mediatek.com>

Add YAML schemas documentation for Gen3 PCIe controller on
MediaTek SoCs.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pci/mediatek-pcie-gen3.yaml      | 181 ++++++++++++++++++
 1 file changed, 181 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
new file mode 100644
index 000000000000..e7b1f9892da4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mediatek-pcie-gen3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gen3 PCIe controller on MediaTek SoCs
+
+maintainers:
+  - Jianjun Wang <jianjun.wang at mediatek.com>
+
+description: |+
+  PCIe Gen3 MAC controller for MediaTek SoCs, it supports Gen3 speed
+  and compatible with Gen2, Gen1 speed.
+
+  This PCIe controller supports up to 256 MSI vectors, the MSI hardware
+  block diagram is as follows:
+
+                    +-----+
+                    | GIC |
+                    +-----+
+                       ^
+                       |
+                   port->irq
+                       |
+               +-+-+-+-+-+-+-+-+
+               |0|1|2|3|4|5|6|7| (PCIe intc)
+               +-+-+-+-+-+-+-+-+
+                ^ ^           ^
+                | |    ...    |
+        +-------+ +------+    +-----------+
+        |                |                |
+  +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
+  |0|1|...|30|31|  |0|1|...|30|31|  |0|1|...|30|31| (MSI sets)
+  +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
+   ^ ^      ^  ^    ^ ^      ^  ^    ^ ^      ^  ^
+   | |      |  |    | |      |  |    | |      |  |  (MSI vectors)
+   | |      |  |    | |      |  |    | |      |  |
+
+    (MSI SET0)       (MSI SET1)  ...   (MSI SET7)
+
+  With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
+  each set has its own address for MSI message, and supports 32 MSI vectors
+  to generate interrupt.
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+    const: mediatek,mt8192-pcie
+
+  reg:
+    maxItems: 1
+
+  reg-names:
+    items:
+      - const: pcie-mac
+
+  interrupts:
+    maxItems: 1
+
+  ranges:
+    minItems: 1
+    maxItems: 8
+
+  resets:
+    minItems: 1
+    maxItems: 2
+
+  reset-names:
+    minItems: 1
+    maxItems: 2
+    items:
+      - const: phy
+      - const: mac
+
+  clocks:
+    maxItems: 6
+
+  clock-names:
+    items:
+      - const: pl_250m
+      - const: tl_26m
+      - const: tl_96m
+      - const: tl_32k
+      - const: peri_26m
+      - const: top_133m
+
+  assigned-clocks:
+    maxItems: 1
+
+  assigned-clock-parents:
+    maxItems: 1
+
+  phys:
+    maxItems: 1
+
+  '#interrupt-cells':
+    const: 1
+
+  interrupt-controller:
+    description: Interrupt controller node for handling legacy PCI interrupts.
+    type: object
+    properties:
+      '#address-cells':
+        const: 0
+      '#interrupt-cells':
+        const: 1
+      interrupt-controller: true
+
+    required:
+      - '#address-cells'
+      - '#interrupt-cells'
+      - interrupt-controller
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - ranges
+  - clocks
+  - '#interrupt-cells'
+  - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        pcie: pcie at 11230000 {
+            compatible = "mediatek,mt8192-pcie";
+            device_type = "pci";
+            #address-cells = <3>;
+            #size-cells = <2>;
+            reg = <0x00 0x11230000 0x00 0x4000>;
+            reg-names = "pcie-mac";
+            interrupts = <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH 0>;
+            bus-range = <0x00 0xff>;
+            ranges = <0x82000000 0x00 0x12000000 0x00
+                      0x12000000 0x00 0x1000000>;
+            clocks = <&infracfg 44>,
+                     <&infracfg 40>,
+                     <&infracfg 43>,
+                     <&infracfg 97>,
+                     <&infracfg 99>,
+                     <&infracfg 111>;
+            clock-names = "pl_250m", "tl_26m", "tl_96m",
+                          "tl_32k", "peri_26m", "top_133m";
+            assigned-clocks = <&topckgen 50>;
+            assigned-clock-parents = <&topckgen 91>;
+
+            phys = <&pciephy>;
+            phy-names = "pcie-phy";
+
+            resets = <&infracfg_rst 2>,
+                     <&infracfg_rst 3>;
+            reset-names = "phy", "mac";
+
+            #interrupt-cells = <1>;
+            interrupt-map-mask = <0 0 0 0x7>;
+            interrupt-map = <0 0 0 1 &pcie_intc 0>,
+                            <0 0 0 2 &pcie_intc 1>,
+                            <0 0 0 3 &pcie_intc 2>,
+                            <0 0 0 4 &pcie_intc 3>;
+            pcie_intc: interrupt-controller {
+                      #address-cells = <0>;
+                      #interrupt-cells = <1>;
+                      interrupt-controller;
+            };
+        };
+    };
-- 
2.25.1

From jianjun.wang at mediatek.com  Tue Apr 20 07:17:20 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Tue, 20 Apr 2021 14:17:20 +0800
Subject: [PATCH v10 4/7] PCI: mediatek-gen3: Add INTx support
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <20210420061723.989-5-jianjun.wang@mediatek.com>

Add INTx support for MediaTek Gen3 PCIe controller.

Signed-off-by: Jianjun Wang <jianjun.wang at mediatek.com>
Acked-by: Ryder Lee <ryder.lee at mediatek.com>
Reviewed-by: Marc Zyngier <maz at kernel.org>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 172 ++++++++++++++++++++
 1 file changed, 172 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index 3546e53b3c85..ff91ad587461 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -9,6 +9,9 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/iopoll.h>
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/pci.h>
@@ -45,6 +48,13 @@
 #define PCIE_LINK_STATUS_REG		0x154
 #define PCIE_PORT_LINKUP		BIT(8)
 
+#define PCIE_INT_ENABLE_REG		0x180
+#define PCIE_INTX_SHIFT			24
+#define PCIE_INTX_ENABLE \
+	GENMASK(PCIE_INTX_SHIFT + PCI_NUM_INTX - 1, PCIE_INTX_SHIFT)
+
+#define PCIE_INT_STATUS_REG		0x184
+
 #define PCIE_TRANS_TABLE_BASE_REG	0x800
 #define PCIE_ATR_SRC_ADDR_MSB_OFFSET	0x4
 #define PCIE_ATR_TRSL_ADDR_LSB_OFFSET	0x8
@@ -73,6 +83,9 @@
  * @phy: PHY controller block
  * @clks: PCIe clocks
  * @num_clks: PCIe clocks count for this port
+ * @irq: PCIe controller interrupt number
+ * @irq_lock: lock protecting IRQ register access
+ * @intx_domain: legacy INTx IRQ domain
  */
 struct mtk_pcie_port {
 	struct device *dev;
@@ -83,6 +96,10 @@ struct mtk_pcie_port {
 	struct phy *phy;
 	struct clk_bulk_data *clks;
 	int num_clks;
+
+	int irq;
+	raw_spinlock_t irq_lock;
+	struct irq_domain *intx_domain;
 };
 
 /**
@@ -198,6 +215,11 @@ static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
 	val |= PCI_CLASS(PCI_CLASS_BRIDGE_PCI << 8);
 	writel_relaxed(val, port->base + PCIE_PCI_IDS_1);
 
+	/* Mask all INTx interrupts */
+	val = readl_relaxed(port->base + PCIE_INT_ENABLE_REG);
+	val &= ~PCIE_INTX_ENABLE;
+	writel_relaxed(val, port->base + PCIE_INT_ENABLE_REG);
+
 	/* Assert all reset signals */
 	val = readl_relaxed(port->base + PCIE_RST_CTRL_REG);
 	val |= PCIE_MAC_RSTB | PCIE_PHY_RSTB | PCIE_BRG_RSTB | PCIE_PE_RSTB;
@@ -261,6 +283,150 @@ static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
 	return 0;
 }
 
+static int mtk_pcie_set_affinity(struct irq_data *data,
+				 const struct cpumask *mask, bool force)
+{
+	return -EINVAL;
+}
+
+static void mtk_intx_mask(struct irq_data *data)
+{
+	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
+	unsigned long flags;
+	u32 val;
+
+	raw_spin_lock_irqsave(&port->irq_lock, flags);
+	val = readl_relaxed(port->base + PCIE_INT_ENABLE_REG);
+	val &= ~BIT(data->hwirq + PCIE_INTX_SHIFT);
+	writel_relaxed(val, port->base + PCIE_INT_ENABLE_REG);
+	raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+static void mtk_intx_unmask(struct irq_data *data)
+{
+	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
+	unsigned long flags;
+	u32 val;
+
+	raw_spin_lock_irqsave(&port->irq_lock, flags);
+	val = readl_relaxed(port->base + PCIE_INT_ENABLE_REG);
+	val |= BIT(data->hwirq + PCIE_INTX_SHIFT);
+	writel_relaxed(val, port->base + PCIE_INT_ENABLE_REG);
+	raw_spin_unlock_irqrestore(&port->irq_lock, flags);
+}
+
+/**
+ * mtk_intx_eoi() - Clear INTx IRQ status at the end of interrupt
+ * @data: pointer to chip specific data
+ *
+ * As an emulated level IRQ, its interrupt status will remain
+ * until the corresponding de-assert message is received; hence that
+ * the status can only be cleared when the interrupt has been serviced.
+ */
+static void mtk_intx_eoi(struct irq_data *data)
+{
+	struct mtk_pcie_port *port = irq_data_get_irq_chip_data(data);
+	unsigned long hwirq;
+
+	hwirq = data->hwirq + PCIE_INTX_SHIFT;
+	writel_relaxed(BIT(hwirq), port->base + PCIE_INT_STATUS_REG);
+}
+
+static struct irq_chip mtk_intx_irq_chip = {
+	.irq_mask		= mtk_intx_mask,
+	.irq_unmask		= mtk_intx_unmask,
+	.irq_eoi		= mtk_intx_eoi,
+	.irq_set_affinity	= mtk_pcie_set_affinity,
+	.name			= "INTx",
+};
+
+static int mtk_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
+			     irq_hw_number_t hwirq)
+{
+	irq_set_chip_data(irq, domain->host_data);
+	irq_set_chip_and_handler_name(irq, &mtk_intx_irq_chip,
+				      handle_fasteoi_irq, "INTx");
+	return 0;
+}
+
+static const struct irq_domain_ops intx_domain_ops = {
+	.map = mtk_pcie_intx_map,
+};
+
+static int mtk_pcie_init_irq_domains(struct mtk_pcie_port *port)
+{
+	struct device *dev = port->dev;
+	struct device_node *intc_node, *node = dev->of_node;
+
+	raw_spin_lock_init(&port->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;
+	}
+
+	port->intx_domain = irq_domain_add_linear(intc_node, PCI_NUM_INTX,
+						  &intx_domain_ops, port);
+	if (!port->intx_domain) {
+		dev_err(dev, "failed to create INTx IRQ domain\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static void mtk_pcie_irq_teardown(struct mtk_pcie_port *port)
+{
+	irq_set_chained_handler_and_data(port->irq, NULL, NULL);
+
+	if (port->intx_domain)
+		irq_domain_remove(port->intx_domain);
+
+	irq_dispose_mapping(port->irq);
+}
+
+static void mtk_pcie_irq_handler(struct irq_desc *desc)
+{
+	struct mtk_pcie_port *port = irq_desc_get_handler_data(desc);
+	struct irq_chip *irqchip = irq_desc_get_chip(desc);
+	unsigned long status;
+	unsigned int virq;
+	irq_hw_number_t irq_bit = PCIE_INTX_SHIFT;
+
+	chained_irq_enter(irqchip, desc);
+
+	status = readl_relaxed(port->base + PCIE_INT_STATUS_REG);
+	for_each_set_bit_from(irq_bit, &status, PCI_NUM_INTX +
+			      PCIE_INTX_SHIFT) {
+		virq = irq_find_mapping(port->intx_domain,
+					irq_bit - PCIE_INTX_SHIFT);
+		generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(irqchip, desc);
+}
+
+static int mtk_pcie_setup_irq(struct mtk_pcie_port *port)
+{
+	struct device *dev = port->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	int err;
+
+	err = mtk_pcie_init_irq_domains(port);
+	if (err)
+		return err;
+
+	port->irq = platform_get_irq(pdev, 0);
+	if (port->irq < 0)
+		return port->irq;
+
+	irq_set_chained_handler_and_data(port->irq, mtk_pcie_irq_handler, port);
+
+	return 0;
+}
+
 static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
 {
 	struct device *dev = port->dev;
@@ -391,6 +557,10 @@ static int mtk_pcie_setup(struct mtk_pcie_port *port)
 	if (err)
 		goto err_setup;
 
+	err = mtk_pcie_setup_irq(port);
+	if (err)
+		goto err_setup;
+
 	return 0;
 
 err_setup:
@@ -424,6 +594,7 @@ static int mtk_pcie_probe(struct platform_device *pdev)
 
 	err = pci_host_probe(host);
 	if (err) {
+		mtk_pcie_irq_teardown(port);
 		mtk_pcie_power_down(port);
 		return err;
 	}
@@ -441,6 +612,7 @@ static int mtk_pcie_remove(struct platform_device *pdev)
 	pci_remove_root_bus(host->bus);
 	pci_unlock_rescan_remove();
 
+	mtk_pcie_irq_teardown(port);
 	mtk_pcie_power_down(port);
 
 	return 0;
-- 
2.25.1

From dillon.minfei at gmail.com  Tue Apr 20 07:43:08 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Tue, 20 Apr 2021 14:43:08 +0800
Subject: [PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC
 board support
In-Reply-To: <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>
Message-ID: <CAL9mu0LJCa3OXYdTj2e3pMcC=-S=EQN4UqkgnWOFsRsBGxQhLw@mail.gmail.com>

Hi?

Just a gentle ping, hope some expert could take a look, thanks.

Best regards.
Dillon

On Thu, Apr 15, 2021 at 12:05 PM <dillon.minfei at gmail.com> wrote:
>
> From: dillon min <dillon.minfei at gmail.com>
>
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v3: move imx6q-ds.dtb after imx6q-dms-ba16.dtb to follow the alphabetical order
>
>  arch/arm/boot/dts/Makefile        |   1 +
>  arch/arm/boot/dts/imx6q-ds.dts    |  17 ++
>  arch/arm/boot/dts/imx6qdl-ds.dtsi | 465 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 483 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a19c5ab9df84..425fe17ef7c1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -510,6 +510,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>         imx6q-display5-tianma-tm070-1280x768.dtb \
>         imx6q-dmo-edmqmx6.dtb \
>         imx6q-dms-ba16.dtb \
> +       imx6q-ds.dtb \
>         imx6q-emcon-avari.dtb \
>         imx6q-evi.dtb \
>         imx6q-gk802.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
> new file mode 100644
> index 000000000000..b0a63a133977
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-ds.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
> +//
> +// Based on imx6qdl-sabresd.dtsi which is:
> +// Copyright 2012 Freescale Semiconductor, Inc.
> +// Copyright 2011 Linaro Ltd.
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-ds.dtsi"
> +
> +/ {
> +       model = "DaSheng i.MX6 Quad Com-9xx Board";
> +       compatible = "ds,imx6q-sbc", "fsl,imx6q";
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
> new file mode 100644
> index 000000000000..d28e065349cd
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
> @@ -0,0 +1,465 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
> +//
> +// Based on imx6qdl-sabresd.dtsi which is:
> +// Copyright 2012 Freescale Semiconductor, Inc.
> +// Copyright 2011 Linaro Ltd.
> +
> +#include <dt-bindings/clock/imx6qdl-clock.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +       chosen {
> +               stdout-path = &uart1;
> +       };
> +
> +       memory at 10000000 {
> +               device_type = "memory";
> +               reg = <0x10000000 0x80000000>;
> +       };
> +
> +       reg_usb_otg_vbus: regulator-usb-otg-vbus {
> +               compatible = "regulator-fixed";
> +               regulator-name = "usb_otg_vbus";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               regulator-always-on;
> +       };
> +
> +       reg_usb_h1_vbus: regulator-usb-h1-vbus {
> +               compatible = "regulator-fixed";
> +               regulator-name = "usb_h1_vbus";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               regulator-always-on;
> +       };
> +
> +       leds {
> +               compatible = "gpio-leds";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> +               green {
> +                       gpios = <&gpio4 8 0>;
> +                       default-state = "on";
> +                       linux,default-trigger = "heartbeat";
> +               };
> +       };
> +};
> +
> +&ipu1_csi0_from_ipu1_csi0_mux {
> +       bus-width = <8>;
> +       data-shift = <12>; /* Lines 19:12 used */
> +       hsync-active = <1>;
> +       vsync-active = <1>;
> +};
> +
> +&ipu1_csi0_mux_from_parallel_sensor {
> +       remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
> +};
> +
> +&ipu1_csi0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ipu1_csi0>;
> +       status = "okay";
> +};
> +
> +&clks {
> +       assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> +                         <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> +       assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> +                                <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
> +
> +&ecspi1 {
> +       cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ecspi1>;
> +       status = "okay";
> +
> +       flash: m25p80 at 0 {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               compatible = "st,m25p80", "jedec,spi-nor";
> +               spi-max-frequency = <20000000>;
> +               reg = <0>;
> +       };
> +};
> +
> +&fec {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_enet>;
> +       phy-mode = "rgmii-id";
> +       phy-handle = <&phy>;
> +       fsl,magic-packet;
> +       status = "okay";
> +
> +       mdio {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               phy: ethernet-phy at 1 {
> +                       reg = <1>;
> +                       qca,clk-out-frequency = <125000000>;
> +                       reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
> +                       reset-assert-us = <10000>;
> +               };
> +       };
> +};
> +
> +&hdmi {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_hdmi_cec>;
> +       ddc-i2c-bus = <&i2c3>;
> +       status = "okay";
> +};
> +
> +&i2c2 {
> +       clock-frequency = <100000>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_i2c2>;
> +       status = "okay";
> +
> +       pmic: pfuze100 at 8 {
> +               compatible = "fsl,pfuze100";
> +               reg = <0x08>;
> +
> +               regulators {
> +                       sw1a_reg: sw1ab {
> +                               regulator-min-microvolt = <300000>;
> +                               regulator-max-microvolt = <1875000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw1c_reg: sw1c {
> +                               regulator-min-microvolt = <300000>;
> +                               regulator-max-microvolt = <1875000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw2_reg: sw2 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw3a_reg: sw3a {
> +                               regulator-min-microvolt = <400000>;
> +                               regulator-max-microvolt = <1975000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       sw3b_reg: sw3b {
> +                               regulator-min-microvolt = <400000>;
> +                               regulator-max-microvolt = <1975000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       sw4_reg: sw4 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       swbst_reg: swbst {
> +                               regulator-min-microvolt = <5000000>;
> +                               regulator-max-microvolt = <5150000>;
> +                       };
> +
> +                       snvs_reg: vsnvs {
> +                               regulator-min-microvolt = <1000000>;
> +                               regulator-max-microvolt = <3000000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       vref_reg: vrefddr {
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen1_reg: vgen1 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <1550000>;
> +                       };
> +
> +                       vgen2_reg: vgen2 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <1550000>;
> +                       };
> +
> +                       vgen3_reg: vgen3 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                       };
> +
> +                       vgen4_reg: vgen4 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen5_reg: vgen5 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen6_reg: vgen6 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +               };
> +       };
> +};
> +
> +&i2c3 {
> +       clock-frequency = <100000>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_i2c3>;
> +       status = "okay";
> +
> +       ov2659: camera at 30 {
> +               compatible = "ovti,ov2659";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_ov2659>;
> +               clocks = <&clks IMX6QDL_CLK_CKO>;
> +               clock-names = "xvclk";
> +               reg = <0x30>;
> +               powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
> +               reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
> +               status = "okay";
> +
> +               port {
> +                       ov2659_to_ipu1_csi0_mux: endpoint {
> +                               remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> +                               link-frequencies = /bits/ 64 <70000000>;
> +                               bus-width = <8>;
> +                               hsync-active = <1>;
> +                               vsync-active = <1>;
> +                       };
> +               };
> +       };
> +};
> +
> +&iomuxc {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_hog>;
> +
> +       imx6qdl-ds {
> +               pinctrl_hog: hoggrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> +                               MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> +                               MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
> +                               MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
> +                               MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> +                       >;
> +               };
> +
> +               pinctrl_ecspi1: ecspi1grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
> +                               MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
> +                               MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
> +                               MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
> +                               MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
> +                       >;
> +               };
> +
> +               pinctrl_enet: enetgrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_ENET_MDIO__ENET_MDIO         0x1b0b0
> +                               MX6QDL_PAD_ENET_MDC__ENET_MDC           0x1b0b0
> +                               MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b030
> +                               MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b030
> +                               MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b030
> +                               MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b030
> +                               MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b030
> +                               MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b030
> +                               MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x1b0b0
> +                               MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b030
> +                               MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b030
> +                               MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b030
> +                               MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b030
> +                               MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b030
> +                               MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
> +                       >;
> +               };
> +
> +               pinctrl_hdmi_cec: hdmicecgrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE    0x1f8b0
> +                       >;
> +               };
> +
> +               pinctrl_i2c2: i2c2grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_EIM_EB2__I2C2_SCL            0x4001b8b1
> +                               MX6QDL_PAD_KEY_ROW3__I2C2_SDA           0x4001b8b1
> +                       >;
> +               };
> +
> +               pinctrl_i2c3: i2c3grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_GPIO_5__I2C3_SCL             0x4001b8b1
> +                               MX6QDL_PAD_GPIO_6__I2C3_SDA             0x4001b8b1
> +                       >;
> +               };
> +
> +               pinctrl_ipu1_csi0: ipu1csi0grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
> +                               MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
> +                               MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
> +                               MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
> +                               MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
> +                       >;
> +               };
> +
> +               pinctrl_ov2659: ov2659grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x1b0b0
> +                               MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
> +                       >;
> +               };
> +
> +               pinctrl_uart4: uart4grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_KEY_COL0__UART4_TX_DATA      0x1b0b1
> +                               MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA      0x1b0b1
> +                       >;
> +               };
> +
> +               pinctrl_usbotg: usbotggrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID       0x17059
> +                       >;
> +               };
> +
> +               pinctrl_usdhc1: usdhc1grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_SD1_CMD__SD1_CMD             0x17059
> +                               MX6QDL_PAD_SD1_CLK__SD1_CLK             0x10059
> +                               MX6QDL_PAD_SD1_DAT0__SD1_DATA0          0x17059
> +                               MX6QDL_PAD_SD1_DAT1__SD1_DATA1          0x17059
> +                               MX6QDL_PAD_SD1_DAT2__SD1_DATA2          0x17059
> +                               MX6QDL_PAD_SD1_DAT3__SD1_DATA3          0x17059
> +                               MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28       0x1b0b0
> +                       >;
> +               };
> +
> +               pinctrl_usdhc2: usdhc2grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_SD2_CMD__SD2_CMD             0x17059
> +                               MX6QDL_PAD_SD2_CLK__SD2_CLK             0x10059
> +                               MX6QDL_PAD_SD2_DAT0__SD2_DATA0          0x17059
> +                               MX6QDL_PAD_SD2_DAT1__SD2_DATA1          0x17059
> +                               MX6QDL_PAD_SD2_DAT2__SD2_DATA2          0x17059
> +                               MX6QDL_PAD_SD2_DAT3__SD2_DATA3          0x17059
> +                       >;
> +               };
> +
> +               pinctrl_usdhc3: usdhc3grp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_SD3_CMD__SD3_CMD             0x17059
> +                               MX6QDL_PAD_SD3_CLK__SD3_CLK             0x10059
> +                               MX6QDL_PAD_SD3_DAT0__SD3_DATA0          0x17059
> +                               MX6QDL_PAD_SD3_DAT1__SD3_DATA1          0x17059
> +                               MX6QDL_PAD_SD3_DAT2__SD3_DATA2          0x17059
> +                               MX6QDL_PAD_SD3_DAT3__SD3_DATA3          0x17059
> +                               MX6QDL_PAD_SD3_DAT4__SD3_DATA4          0x17059
> +                               MX6QDL_PAD_SD3_DAT5__SD3_DATA5          0x17059
> +                               MX6QDL_PAD_SD3_DAT6__SD3_DATA6          0x17059
> +                               MX6QDL_PAD_SD3_DAT7__SD3_DATA7          0x17059
> +                       >;
> +               };
> +
> +               pinctrl_wdog: wdoggrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_GPIO_1__WDOG2_B              0x1b0b0
> +                       >;
> +               };
> +       };
> +
> +       gpio_leds {
> +               pinctrl_gpio_leds: gpioledsgrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
> +                       >;
> +               };
> +       };
> +};
> +
> +&uart4 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_uart4>;
> +       status = "okay";
> +};
> +
> +&usbh1 {
> +       vbus-supply = <&reg_usb_h1_vbus>;
> +       status = "okay";
> +};
> +
> +&usbotg {
> +       vbus-supply = <&reg_usb_otg_vbus>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usbotg>;
> +       disable-over-current;
> +       status = "okay";
> +};
> +
> +&usdhc1 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc1>;
> +       bus-width = <4>;
> +       cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
> +       status = "okay";
> +};
> +
> +&usdhc2 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc2>;
> +       bus-width = <4>;
> +       cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
> +       wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +       status = "disabled";
> +};
> +
> +&usdhc3 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc3>;
> +       bus-width = <8>;
> +       non-removable;
> +       no-1-8-v;
> +       status = "okay";
> +};
> +
> +&wdog1 {
> +       status = "okay";
> +};
> +
> +&wdog2 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_wdog>;
> +       fsl,ext-reset-output;
> +       status = "disabled";
> +};
> --
> 2.7.4
>


From dillon.minfei at gmail.com  Tue Apr 20 07:45:47 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Tue, 20 Apr 2021 14:45:47 +0800
Subject: [PATCH v3 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <1618459535-8141-5-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-5-git-send-email-dillon.minfei@gmail.com>
Message-ID: <CAL9mu0LmZO38CvmRfBMvgJm6310eMY64tgTRw8kWKCPuGJReoA@mail.gmail.com>

Hi All,

Just a gentle ping, hope some expert could take a look, thanks.

Best regards.
Dillon

On Thu, Apr 15, 2021 at 12:06 PM <dillon.minfei at gmail.com> wrote:
>
> From: dillon min <dillon.minfei at gmail.com>
>
> On some platform(imx6q), xvclk might not switch on in advance,
> also for power save purpose, xvclk should not be always on.
> so, add clk_prepare_enable(), clk_disable_unprepare() in driver
> side to set xvclk on/off at proper stage.
>
> Add following changes:
> - add 'struct clk *clk;' in 'struct ov2659 {}'
> - enable xvclk in ov2659_power_on()
> - disable xvclk in ov2659_power_off()
>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v3: optimize commit message
>
>  drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index 42f64175a6df..fb78a1cedc03 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -204,6 +204,7 @@ struct ov2659 {
>         struct i2c_client *client;
>         struct v4l2_ctrl_handler ctrls;
>         struct v4l2_ctrl *link_frequency;
> +       struct clk *clk;
>         const struct ov2659_framesize *frame_size;
>         struct sensor_register *format_ctrl_regs;
>         struct ov2659_pll_ctrl pll;
> @@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
>
>         gpiod_set_value(ov2659->pwdn_gpio, 1);
>
> +       clk_disable_unprepare(ov2659->clk);
> +
>         return 0;
>  }
>
> @@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
>         struct i2c_client *client = to_i2c_client(dev);
>         struct v4l2_subdev *sd = i2c_get_clientdata(client);
>         struct ov2659 *ov2659 = to_ov2659(sd);
> +       int ret;
>
>         dev_dbg(&client->dev, "%s:\n", __func__);
>
> +       ret = clk_prepare_enable(ov2659->clk);
> +       if (ret) {
> +               dev_err(&client->dev, "%s: failed to enable clock\n",
> +                       __func__);
> +               return ret;
> +       }
> +
>         gpiod_set_value(ov2659->pwdn_gpio, 0);
>
>         if (ov2659->resetb_gpio) {
> @@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
>         const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
>         struct v4l2_subdev *sd;
>         struct ov2659 *ov2659;
> -       struct clk *clk;
>         int ret;
>
>         if (!pdata) {
> @@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
>         ov2659->pdata = pdata;
>         ov2659->client = client;
>
> -       clk = devm_clk_get(&client->dev, "xvclk");
> -       if (IS_ERR(clk))
> -               return PTR_ERR(clk);
> +       ov2659->clk = devm_clk_get(&client->dev, "xvclk");
> +       if (IS_ERR(ov2659->clk))
> +               return PTR_ERR(ov2659->clk);
>
> -       ov2659->xvclk_frequency = clk_get_rate(clk);
> +       ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
>         if (ov2659->xvclk_frequency < 6000000 ||
>             ov2659->xvclk_frequency > 27000000)
>                 return -EINVAL;
> @@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
>         ov2659->frame_size = &ov2659_framesizes[2];
>         ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
>
> -       ov2659_power_on(&client->dev);
> +       ret = ov2659_power_on(&client->dev);
> +       if (ret < 0)
> +               goto error;
>
>         ret = ov2659_detect(sd);
>         if (ret < 0)
> --
> 2.7.4
>


From krzysztof.kozlowski at canonical.com  Tue Apr 20 07:52:06 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 08:52:06 +0200
Subject: [PATCH v3 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <CAL9mu0LmZO38CvmRfBMvgJm6310eMY64tgTRw8kWKCPuGJReoA@mail.gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-5-git-send-email-dillon.minfei@gmail.com>
 <CAL9mu0LmZO38CvmRfBMvgJm6310eMY64tgTRw8kWKCPuGJReoA@mail.gmail.com>
Message-ID: <CA+Eumj4M5k50Vv+5tzsY943yp2CVvXFxnf-W0nBf=Bj5M-1AQg@mail.gmail.com>

On Tue, 20 Apr 2021 at 08:46, dillon min <dillon.minfei at gmail.com> wrote:
>
> Hi All,
>
> Just a gentle ping, hope some expert could take a look, thanks.

Don't ping people after 5 days. It's not gentle.

Best regards,
Krzysztof


From dillon.minfei at gmail.com  Tue Apr 20 08:02:37 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Tue, 20 Apr 2021 15:02:37 +0800
Subject: [PATCH v3 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <CA+Eumj4M5k50Vv+5tzsY943yp2CVvXFxnf-W0nBf=Bj5M-1AQg@mail.gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-5-git-send-email-dillon.minfei@gmail.com>
 <CAL9mu0LmZO38CvmRfBMvgJm6310eMY64tgTRw8kWKCPuGJReoA@mail.gmail.com>
 <CA+Eumj4M5k50Vv+5tzsY943yp2CVvXFxnf-W0nBf=Bj5M-1AQg@mail.gmail.com>
Message-ID: <CAL9mu0+8RekaDTBEaJaK4ZFAbpcZfd3gJQ3=fmmY05n-SkEvPg@mail.gmail.com>

On Tue, Apr 20, 2021 at 2:52 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> On Tue, 20 Apr 2021 at 08:46, dillon min <dillon.minfei at gmail.com> wrote:
> >
> > Hi All,
> >
> > Just a gentle ping, hope some expert could take a look, thanks.
>
> Don't ping people after 5 days. It's not gentle.
Got it, thanks for reminding me.

Best regards,
Dillon
>
> Best regards,
> Krzysztof


From arnd at kernel.org  Tue Apr 20 08:07:55 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 20 Apr 2021 09:07:55 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210420031029.GI2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
Message-ID: <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>

On Tue, Apr 20, 2021 at 5:10 AM Matthew Wilcox <willy at infradead.org> wrote:
>
> On Tue, Apr 20, 2021 at 02:48:17AM +0000, Vineet Gupta wrote:
> > > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > > page inadvertently expanded in 2019.
> >
> > FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is
> > only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND
> > instructions.
>
> Ah, like x86?  OK, great, I'll drop your arch from the list of
> affected.  Thanks!

I mistakenly assumed that i386 and m68k were the only supported
architectures with 32-bit alignment on u64. I checked it now and found

$ for i in /home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/*-gcc ; do
echo `echo 'int a = __alignof__(long long);' | $i -xc - -Wall -S -o- |
grep -A1 a: | tail -n 1 | cut -f 3 -d\   `
${i#/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/} ; done
8 aarch64-linux-gcc
8 alpha-linux-gcc
4 arc-linux-gcc
8 arm-linux-gnueabi-gcc
8 c6x-elf-gcc
4 csky-linux-gcc
4 h8300-linux-gcc
8 hppa-linux-gcc
8 hppa64-linux-gcc
8 i386-linux-gcc
8 ia64-linux-gcc
2 m68k-linux-gcc
4 microblaze-linux-gcc
8 mips-linux-gcc
8 mips64-linux-gcc
8 nds32le-linux-gcc
4 nios2-linux-gcc
4 or1k-linux-gcc
8 powerpc-linux-gcc
8 powerpc64-linux-gcc
8 riscv32-linux-gcc
8 riscv64-linux-gcc
8 s390-linux-gcc
4 sh2-linux-gcc
4 sh4-linux-gcc
8 sparc-linux-gcc
8 sparc64-linux-gcc
8 x86_64-linux-gcc
8 xtensa-linux-gcc

which means that half the 32-bit architectures do this. This may
cause more problems when arc and/or microblaze want to support
64-bit kernels and compat mode in the future on their latest hardware,
as that means duplicating the x86 specific hacks we have for compat.

What is alignof(u64) on 64-bit arc?

      Arnd


From joel at jms.id.au  Tue Apr 20 08:11:01 2021
From: joel at jms.id.au (Joel Stanley)
Date: Tue, 20 Apr 2021 07:11:01 +0000
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13, v2
In-Reply-To: <CAK8P3a1rG6qKjVvr86G=6cgkhReQUbsvQAkdxg7A2HsJ7n499A@mail.gmail.com>
References: <CACPK8Xeet50bqWAY0jG_GRkgvKvFn94XtGDaq1gaVYVkyV_JUQ@mail.gmail.com>
 <CAK8P3a1rG6qKjVvr86G=6cgkhReQUbsvQAkdxg7A2HsJ7n499A@mail.gmail.com>
Message-ID: <CACPK8XfkSQpMz9J+8xN7DP9Wabv=+DAgmX6NGL9742Ss3HsehA@mail.gmail.com>

On Mon, 19 Apr 2021 at 14:44, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Fri, Apr 16, 2021 at 5:27 AM Joel Stanley <joel at jms.id.au> wrote:
> >
> > Hello Soc maintainers,
> >
> > Here are some fixes for the changes that have already been merged for v5.13.
> >
> > I also merged some changes that came in later. If you would prefer to
> > not take them then I can send a pull with just the fixes.
> >
> > The following changes since commit f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:
> >
> > for you to fetch changes up to f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:
>
> Hi Joel,
>
> something about this pull request doesn't add up, and 'b4' refuses
> to pull it since the 'since commit f0145db2' and 'up to f0145db2'
> references refer to the same commit.
>
> I assume this is just a copy-paste error on your end, but it would
> be nice if you could double-check and resend the pull request
> based on the ee33e2fb3d70 commit that I merged.

Nice catch. It looks I've generated pull requests incorrectly from
v5.5 onwards, and this is the first time we've noticed. My bash
history shows I started generating them like this:

 git request-pull tag url tag

v5.4 was the first time I'd sent a second PR for the same branch, so
when it came to generating the next one ctrl+R'd myself into the wrong
syntax and continued doing so ever since.

I'll try sending this one again now.

Cheers,

Joel


From joel at jms.id.au  Tue Apr 20 08:14:07 2021
From: joel at jms.id.au (Joel Stanley)
Date: Tue, 20 Apr 2021 07:14:07 +0000
Subject: [RESEND GIT PULL] ARM: bmc: devicetree changes for 5.13, v2
Message-ID: <CACPK8XeJdHmxyJn43Ju5hmxJ7+rJgHmx=ANFaL17YUmp+gOtJg@mail.gmail.com>

Hello Arnd,

Here we go! The second try at a second set of changes for v5.13. I
think I've sorted out the gremlins, thank you for your patience.

The following changes since commit ee33e2fb3d70267de00f7c0b09e7e3b309a686df:

  ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree (2021-04-08 11:21:05 +0930)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc.git
tags/bmc-5.13-devicetree-2

for you to fetch changes up to f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:

  ARM: dts: aspeed: tiogapass: add hotplug controller (2021-04-16
12:28:38 +0930)

----------------------------------------------------------------
BMC device tree updates for 5.13, round two

 - Fixes to the first pull request for Rainier

 - Small changes for Rainier, EthanolX and Tiogapass

----------------------------------------------------------------
Eddie James (4):
      ARM: dts: aspeed: Rainier: Fix PCA9552 on bus 8
      ARM: dts: aspeed: Rainier: Fix humidity sensor bus address
      ARM: dts: aspeed: Rainier 1S4U: Fix fan nodes
      ARM: dts: aspeed: Rainier: Update to pass 2 hardware

Konstantin Aladyshev (1):
      ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses

Paul Fertser (1):
      ARM: dts: aspeed: tiogapass: add hotplug controller

 arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts      |  30 ++
 .../arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts |   5 +
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier-1s4u.dts  |   2 +-
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts       | 306 +++++++++++----------
 4 files changed, 201 insertions(+), 142 deletions(-)


From linux at rasmusvillemoes.dk  Tue Apr 20 08:21:22 2021
From: linux at rasmusvillemoes.dk (Rasmus Villemoes)
Date: Tue, 20 Apr 2021 09:21:22 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210416230724.2519198-2-willy@infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
Message-ID: <d0c32751-0a12-1f7f-4f6a-b1f6535a6b6e@rasmusvillemoes.dk>

On 17/04/2021 01.07, Matthew Wilcox (Oracle) wrote:
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
> 
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
> 
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>  include/linux/mm_types.h |  4 ++--
>  include/net/page_pool.h  | 12 +++++++++++-
>  net/core/page_pool.c     | 12 +++++++-----
>  3 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 6613b26a8894..5aacc1c10a45 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>  		};
>  		struct {	/* page_pool used by netstack */
>  			/**
> -			 * @dma_addr: might require a 64-bit value even on
> +			 * @dma_addr: might require a 64-bit value on
>  			 * 32-bit architectures.
>  			 */
> -			dma_addr_t dma_addr;
> +			unsigned long dma_addr[2];

Shouldn't that member get another name (_dma_addr?) to be sure the
buildbots catch every possible (ab)user and get them turned into the new
accessors? Sure, page->dma_addr is now "pointer to unsigned long"
instead of "dma_addr_t", but who knows if there's a
"(long)page->dma_addr" somewhere?

Rasmus


From jaxson.han at arm.com  Tue Apr 20 08:24:34 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:34 +0800
Subject: [boot-wrapper PATCH 1/5] Decouple V2M_SYS config by auto-detect dtb
 node
In-Reply-To: <20210420072438.183086-1-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
Message-ID: <20210420072438.183086-2-jaxson.han@arm.com>

An auto-detect switch is added to make it an option to enable/disable
'arm,vexpress-sysreg', because not all platforms support this feature.

Signed-off-by: Jaxson Han <jaxson.han at arm.com>
---
 Makefile.am | 2 +-
 platform.c  | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index af694b7..e131207 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,7 +19,7 @@ NR_CPUS         := $(shell echo $(CPU_IDS) | tr ',' ' ' | wc -w)
 DEFINES		= -DCNTFRQ=$(CNTFRQ)
 DEFINES		+= -DCPU_IDS=$(CPU_IDS)
 DEFINES		+= -DNR_CPUS=$(NR_CPUS)
-DEFINES		+= -DSYSREGS_BASE=$(SYSREGS_BASE)
+DEFINES		+= $(if $(SYSREGS_BASE), -DSYSREGS_BASE=$(SYSREGS_BASE), )
 DEFINES		+= -DUART_BASE=$(UART_BASE)
 DEFINES		+= -DSTACK_SIZE=256
 
diff --git a/platform.c b/platform.c
index a528a55..d11f568 100644
--- a/platform.c
+++ b/platform.c
@@ -23,10 +23,12 @@
 
 #define PL011(reg)	((void *)UART_BASE + PL011_##reg)
 
+#ifdef SYSREGS_BASE
 #define V2M_SYS_CFGDATA		0xa0
 #define V2M_SYS_CFGCTRL		0xa4
 
 #define V2M_SYS(reg)	((void *)SYSREGS_BASE + V2M_SYS_##reg)
+#endif
 
 static void print_string(const char *str)
 {
@@ -59,6 +61,7 @@ void init_platform(void)
 
 	print_string("Boot-wrapper v0.2\r\n\r\n");
 
+#ifdef SYSREGS_BASE
 	/*
 	 * CLCD output site MB
 	 */
@@ -66,4 +69,5 @@ void init_platform(void)
 	/* START | WRITE | MUXFPGA | SITE_MB */
 	raw_writel((1 << 31) | (1 << 30) | (7 << 20) | (0 << 16),
 				V2M_SYS(CFGCTRL));
+#endif
 }
-- 
2.25.1



From jaxson.han at arm.com  Tue Apr 20 08:24:33 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:33 +0800
Subject: [boot-wrapper PATCH 0/5] Add Armv8-R AArch64 support
Message-ID: <20210420072438.183086-1-jaxson.han@arm.com>

Currently, we cannot boot Linux with boot-wrapper on Armv8-R AArch64:
1. The Armv8-R AArch64 profile does not support the EL3.
2. The Armv8-R AArch64 EL2 only supports a PMSA, which Linux does not 
support. So it's necessary to drop into EL1 before entering the kernel.
3. There is no EL2 booting code for Armv8-R AArch64 and no
configuration for dropping to EL1 in boot-wrapper.

These patches enable boot-wrapper booting Linux with Armv8-R AArch64:
Patch 1 allows boot-wrapper to boot on more platforms.
Patch 2 renames some labels as preparations for booting from lower EL.
Patch 3 prepares for GICv3 initialization with EL2.
Patch 4 adds necessary EL2 registers.
Patch 5 adds auto-detection for Armv8-R AArch64 to drop into EL1
before entering the kernel.

Refs: Arm Architecture Reference Manual Supplement - Armv8, for
Armv8-R AArch64 architecture profile
[https://developer.arm.com/documentation/ddi0600/latest/]

Jaxson Han (5):
  Decouple V2M_SYS config by auto-detect dtb node
  aarch64: Rename labels and prepare for lower EL booting
  gic-v3: Prepare for gicv3 with EL2
  aarch64: Prepare for booting with EL2
  aarch64: Introduce EL2 boot code for Armv8-R AArch64

 Makefile.am                       |   2 +-
 arch/aarch32/include/asm/gic-v3.h |   7 ++
 arch/aarch64/boot.S               | 105 ++++++++++++++++++++++++++----
 arch/aarch64/include/asm/cpu.h    |   3 +
 arch/aarch64/include/asm/gic-v3.h |  38 ++++++++++-
 arch/aarch64/psci.S               |  13 ++--
 arch/aarch64/spin.S               |   8 +--
 arch/aarch64/utils.S              |  10 ++-
 gic-v3.c                          |   2 +-
 platform.c                        |   4 ++
 10 files changed, 162 insertions(+), 30 deletions(-)

-- 
2.25.1



From jaxson.han at arm.com  Tue Apr 20 08:24:37 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:37 +0800
Subject: [boot-wrapper PATCH 4/5] aarch64: Prepare for booting with EL2
In-Reply-To: <20210420072438.183086-1-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
Message-ID: <20210420072438.183086-5-jaxson.han@arm.com>

Prepare for allowing boot-wrapper to be entered in EL2.

Signed-off-by: Jaxson Han <jaxson.han at arm.com>
---
 arch/aarch64/utils.S | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/aarch64/utils.S b/arch/aarch64/utils.S
index ae22ea7..94e9931 100644
--- a/arch/aarch64/utils.S
+++ b/arch/aarch64/utils.S
@@ -37,10 +37,18 @@ find_logical_id:
 	ret
 
 /*
- * Setup EL3 vectors
+ * Setup EL3/EL2 vectors
  * x0: vector address
  */
 setup_vector:
+	mrs	x1, CurrentEL
+	cmp	x1, #CURRENTEL_EL2
+	b.eq	1f
+
 	msr	VBAR_EL3, x0
 	isb
 	ret
+
+1:	msr	VBAR_EL2, x0
+	isb
+	ret
-- 
2.25.1



From jaxson.han at arm.com  Tue Apr 20 08:24:35 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:35 +0800
Subject: [boot-wrapper PATCH 2/5] aarch64: Rename labels and prepare for lower
 EL booting
In-Reply-To: <20210420072438.183086-1-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
Message-ID: <20210420072438.183086-3-jaxson.han@arm.com>

Prepare for booting from lower EL. Rename *_el3 relavant labels with
*_el_max and *_no_el3 with *_keep_el. Since the original _no_el3 means
"We neither do init sequence at this highest EL nor drop to lower EL
when entering to kernel", we rename it with _keep_el to make it more
clear for lower EL initialisation.
Also in jump_kernel, skip sctlr_el2 initialisation when CurrentEL < EL2.

Signed-off-by: Jaxson Han <jaxson.han at arm.com>
---
 arch/aarch64/boot.S            | 54 +++++++++++++++++++++++++---------
 arch/aarch64/include/asm/cpu.h |  3 ++
 arch/aarch64/psci.S            | 13 ++++----
 arch/aarch64/spin.S            |  8 ++---
 4 files changed, 54 insertions(+), 24 deletions(-)

diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
index e47cf59..f7dbf3f 100644
--- a/arch/aarch64/boot.S
+++ b/arch/aarch64/boot.S
@@ -12,7 +12,7 @@
 	.section .init
 
 	.globl	_start
-	.globl jump_kernel
+	.globl	jump_kernel
 
 _start:
 	cpuid	x0, x1
@@ -22,20 +22,30 @@ _start:
 	bl	setup_stack
 
 	/*
-	 * EL3 initialisation
+	 * Boot sequence
+	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
+	 *   lower EL before entering the kernel.
+	 * Else, no initialisation and keep the current EL before
+	 *   entering the kernel.
 	 */
 	mrs	x0, CurrentEL
 	cmp	x0, #CURRENTEL_EL3
-	b.eq	1f
+	beq	el3_init
 
+	/*
+	 * We stay in the current EL for entering the kernel
+	 */
 	mov	w0, #1
-	ldr	x1, =flag_no_el3
+	ldr	x1, =flag_keep_el
 	str	w0, [x1]
 
-	bl	setup_stack
-	b	start_no_el3
+	b	start_keep_el
 
-1:	mov	x0, #0x30			// RES1
+	/*
+	 * EL3 initialisation
+	 */
+el3_init:
+	mov	x0, #0x30			// RES1
 	orr	x0, x0, #(1 << 0)		// Non-secure EL1
 	orr	x0, x0, #(1 << 8)		// HVC enable
 
@@ -93,13 +103,23 @@ _start:
 	mov	x0, #ZCR_EL3_LEN_MASK		// SVE: Enable full vector len
 	msr	ZCR_EL3, x0			// for EL2.
 
-1:
+	/*
+	 * Save SPSR_KERNEL into spsr_to_elx.
+	 * The jump_kernel will load spsr_to_elx into spsr_el3
+	 */
+1:	mov	w0, #SPSR_KERNEL
+	ldr	x1, =spsr_to_elx
+	str	w0, [x1]
+	b	el_max_init
+
+el_max_init:
 	ldr	x0, =CNTFRQ
 	msr	cntfrq_el0, x0
+	isb
 
 	bl	gic_secure_init
 
-	b	start_el3
+	b	start_el_max
 
 err_invalid_id:
 	b	.
@@ -119,14 +139,18 @@ jump_kernel:
 	ldr	x0, =SCTLR_EL1_RESET
 	msr	sctlr_el1, x0
 
+	mrs	x0, CurrentEL
+	cmp	x0, #CURRENTEL_EL2
+	b.lt	1f
+
 	ldr	x0, =SCTLR_EL2_RESET
 	msr	sctlr_el2, x0
 
-	cpuid	x0, x1
+1:	cpuid	x0, x1
 	bl	find_logical_id
 	bl	setup_stack		// Reset stack pointer
 
-	ldr	w0, flag_no_el3
+	ldr	w0, flag_keep_el
 	cmp	w0, #0			// Prepare Z flag
 
 	mov	x0, x20
@@ -135,9 +159,9 @@ jump_kernel:
 	mov	x3, x23
 
 	b.eq	1f
-	br	x19			// No EL3
+	br	x19			// Keep current EL
 
-1:	mov	x4, #SPSR_KERNEL
+1:	ldr	w4, spsr_to_elx
 
 	/*
 	 * If bit 0 of the kernel address is set, we're entering in AArch32
@@ -153,5 +177,7 @@ jump_kernel:
 
 	.data
 	.align 3
-flag_no_el3:
+flag_keep_el:
+	.long 0
+spsr_to_elx:
 	.long 0
diff --git a/arch/aarch64/include/asm/cpu.h b/arch/aarch64/include/asm/cpu.h
index ccb5397..2b3a0a4 100644
--- a/arch/aarch64/include/asm/cpu.h
+++ b/arch/aarch64/include/asm/cpu.h
@@ -11,6 +11,7 @@
 
 #define MPIDR_ID_BITS		0xff00ffffff
 
+#define CURRENTEL_EL2		(2 << 2)
 #define CURRENTEL_EL3		(3 << 2)
 
 /*
@@ -24,6 +25,7 @@
 #define SPSR_I			(1 << 7)	/* IRQ masked */
 #define SPSR_F			(1 << 6)	/* FIQ masked */
 #define SPSR_T			(1 << 5)	/* Thumb */
+#define SPSR_EL1H		(5 << 0)	/* EL1 Handler mode */
 #define SPSR_EL2H		(9 << 0)	/* EL2 Handler mode */
 #define SPSR_HYP		(0x1a << 0)	/* M[3:0] = hyp, M[4] = AArch32 */
 
@@ -42,6 +44,7 @@
 #else
 #define SCTLR_EL1_RESET		SCTLR_EL1_RES1
 #define SPSR_KERNEL		(SPSR_A | SPSR_D | SPSR_I | SPSR_F | SPSR_EL2H)
+#define SPSR_KERNEL_EL1		(SPSR_A | SPSR_D | SPSR_I | SPSR_F | SPSR_EL1H)
 #endif
 
 #ifndef __ASSEMBLY__
diff --git a/arch/aarch64/psci.S b/arch/aarch64/psci.S
index 01ebe7d..ae02fd6 100644
--- a/arch/aarch64/psci.S
+++ b/arch/aarch64/psci.S
@@ -45,8 +45,8 @@ vector:
 
 	.text
 
-	.globl start_no_el3
-	.globl start_el3
+	.globl start_keep_el
+	.globl start_el_max
 
 err_exception:
 	b err_exception
@@ -101,7 +101,7 @@ smc_exit:
 	eret
 
 
-start_el3:
+start_el_max:
 	ldr	x0, =vector
 	bl	setup_vector
 
@@ -111,10 +111,11 @@ start_el3:
 	b	psci_first_spin
 
 /*
- * This PSCI implementation requires EL3. Without EL3 we'll only boot the
- * primary cpu, all others will be trapped in an infinite loop.
+ * This PSCI implementation requires the highest EL(EL3 or Armv8-R EL2).
+ * Without the highest EL, we'll only boot the primary cpu, all others
+ * will be trapped in an infinite loop.
  */
-start_no_el3:
+start_keep_el:
 	cpuid	x0, x1
 	bl	find_logical_id
 	cbz	x0, psci_first_spin
diff --git a/arch/aarch64/spin.S b/arch/aarch64/spin.S
index 72603cf..533177c 100644
--- a/arch/aarch64/spin.S
+++ b/arch/aarch64/spin.S
@@ -11,11 +11,11 @@
 
 	.text
 
-	.globl start_no_el3
-	.globl start_el3
+	.globl start_keep_el
+	.globl start_el_max
 
-start_el3:
-start_no_el3:
+start_el_max:
+start_keep_el:
 	cpuid	x0, x1
 	bl	find_logical_id
 
-- 
2.25.1



From jaxson.han at arm.com  Tue Apr 20 08:24:38 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:38 +0800
Subject: [boot-wrapper PATCH 5/5] aarch64: Introduce EL2 boot code for Armv8-R
 AArch64
In-Reply-To: <20210420072438.183086-1-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
Message-ID: <20210420072438.183086-6-jaxson.han@arm.com>

The Armv8-R AArch64 profile does not support the EL3 exception level.
The Armv8-R AArch64 profile allows for an (optional) VMSAv8-64 MMU
at EL1, which allows to run off-the-shelf Linux. However EL2 only
supports a PMSA, which is not supported by Linux, so we need to drop
into EL1 before entering the kernel.

The boot sequence is:
If CurrentEL == EL3, then goto EL3 initialisation and drop to lower EL
  before entering the kernel.
If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf (Armv8-R aarch64),
  then goto Armv8-R AArch64 initialisation and drop to EL1 before
  entering the kernel.
Else, no initialisation and keep the current EL before entering the
  kernel.

Signed-off-by: Jaxson Han <jaxson.han at arm.com>
---
 arch/aarch64/boot.S | 51 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
index f7dbf3f..6961a2a 100644
--- a/arch/aarch64/boot.S
+++ b/arch/aarch64/boot.S
@@ -25,16 +25,22 @@ _start:
 	 * Boot sequence
 	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
 	 *   lower EL before entering the kernel.
+	 * If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf, then goto
+	 *   Armv8-R AArch64 initialisation and drop to EL1 before
+	 *   entering the kernel.
 	 * Else, no initialisation and keep the current EL before
 	 *   entering the kernel.
 	 */
 	mrs	x0, CurrentEL
 	cmp	x0, #CURRENTEL_EL3
 	beq	el3_init
+	cmp	x0, #CURRENTEL_EL2
+	beq	el2_init
 
 	/*
 	 * We stay in the current EL for entering the kernel
 	 */
+keep_el:
 	mov	w0, #1
 	ldr	x1, =flag_keep_el
 	str	w0, [x1]
@@ -112,6 +118,43 @@ el3_init:
 	str	w0, [x1]
 	b	el_max_init
 
+	/*
+	 * EL2 Armv8-R AArch64 initialisation
+	 */
+el2_init:
+	/* Detect Armv8-R AArch64 */
+	mrs	x1, id_aa64mmfr0_el1
+	ubfx	x1, x1, #48, #4			// MSA
+	/* 0xf means Armv8-R AArch64 */
+	cmp	x1, 0xf
+	bne	keep_el
+
+	mrs	x0, midr_el1
+	msr	vpidr_el2, x0
+
+	mrs	x0, mpidr_el1
+	msr	vmpidr_el2, x0
+
+	mov	x0, #(1 << 31)			// VTCR_MSA: VMSAv8-64 support
+	msr	vtcr_el2, x0
+
+	/* Enable pointer authentication if present */
+	mrs	x1, id_aa64isar1_el1
+	ldr	x2, =(((0xff) << 24) | (0xff << 4))
+	and	x1, x1, x2
+	cbz	x1, 1f
+
+	mrs	x0, hcr_el2
+	orr	x0, x0, #(1 << 40)		// AP key enable
+	orr	x0, x0, #(1 << 41)		// AP insn enable
+	msr	hcr_el2, x0
+
+1:	isb
+	mov	w0, #SPSR_KERNEL_EL1
+	ldr	x1, =spsr_to_elx
+	str	w0, [x1]
+	b	el_max_init
+
 el_max_init:
 	ldr	x0, =CNTFRQ
 	msr	cntfrq_el0, x0
@@ -169,10 +212,18 @@ jump_kernel:
 	 */
 	bfi	x4, x19, #5, #1
 
+	mrs	x5, CurrentEL
+	cmp	x5, #CURRENTEL_EL2
+	b.eq	1f
+
 	msr	elr_el3, x19
 	msr	spsr_el3, x4
 	eret
 
+1:	msr	elr_el2, x19
+	msr	spsr_el2, x4
+	eret
+
 	.ltorg
 
 	.data
-- 
2.25.1



From jaxson.han at arm.com  Tue Apr 20 08:24:36 2021
From: jaxson.han at arm.com (Jaxson Han)
Date: Tue, 20 Apr 2021 15:24:36 +0800
Subject: [boot-wrapper PATCH 3/5] gic-v3: Prepare for gicv3 with EL2
In-Reply-To: <20210420072438.183086-1-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
Message-ID: <20210420072438.183086-4-jaxson.han@arm.com>

This is a preparation for allowing boot-wrapper configuring the gicv3
with EL2.

Signed-off-by: Jaxson Han <jaxson.han at arm.com>
---
 arch/aarch32/include/asm/gic-v3.h |  7 ++++++
 arch/aarch64/include/asm/gic-v3.h | 38 ++++++++++++++++++++++++++++---
 gic-v3.c                          |  2 +-
 3 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/arch/aarch32/include/asm/gic-v3.h b/arch/aarch32/include/asm/gic-v3.h
index ec9a327..86abe09 100644
--- a/arch/aarch32/include/asm/gic-v3.h
+++ b/arch/aarch32/include/asm/gic-v3.h
@@ -9,6 +9,8 @@
 #ifndef __ASM_AARCH32_GICV3_H
 #define __ASM_AARCH32_GICV3_H
 
+#define ICC_CTLR_RESET	(0UL)
+
 static inline uint32_t gic_read_icc_sre(void)
 {
 	uint32_t val;
@@ -26,4 +28,9 @@ static inline void gic_write_icc_ctlr(uint32_t val)
 	asm volatile ("mcr p15, 6, %0, c12, c12, 4" : : "r" (val));
 }
 
+static inline void gic_init_icc_ctlr()
+{
+	gic_write_icc_ctlr(ICC_CTLR_RESET);
+}
+
 #endif
diff --git a/arch/aarch64/include/asm/gic-v3.h b/arch/aarch64/include/asm/gic-v3.h
index e743c02..b3dfbd3 100644
--- a/arch/aarch64/include/asm/gic-v3.h
+++ b/arch/aarch64/include/asm/gic-v3.h
@@ -15,21 +15,53 @@
 #define ICC_CTLR_EL3	"S3_6_C12_C12_4"
 #define ICC_PMR_EL1	"S3_0_C4_C6_0"
 
+#define ICC_CTLR_EL3_RESET	(0UL)
+#define ICC_CTLR_EL1_RESET	(0UL)
+
+static inline uint32_t current_el(void)
+{
+	uint32_t val;
+
+	asm volatile ("mrs %0, CurrentEL" : "=r" (val));
+	return val;
+}
+
 static inline uint32_t gic_read_icc_sre(void)
 {
 	uint32_t val;
-	asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
+
+	if(current_el() == CURRENTEL_EL3)
+		asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
+	else
+		asm volatile ("mrs %0, " ICC_SRE_EL2 : "=r" (val));
+
 	return val;
 }
 
 static inline void gic_write_icc_sre(uint32_t val)
 {
-	asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
+	if(current_el() == CURRENTEL_EL3)
+		asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
+	else
+		asm volatile ("msr " ICC_SRE_EL2 ", %0" : : "r" (val));
 }
 
-static inline void gic_write_icc_ctlr(uint32_t val)
+static inline void gic_write_icc_ctlr_el3(uint32_t val)
 {
 	asm volatile ("msr " ICC_CTLR_EL3 ", %0" : : "r" (val));
 }
 
+static inline void gic_write_icc_ctlr_el1(uint32_t val)
+{
+	asm volatile ("msr " ICC_CTLR_EL1 ", %0" : : "r" (val));
+}
+
+static inline void gic_init_icc_ctlr()
+{
+	if(current_el() == CURRENTEL_EL3)
+		gic_write_icc_ctlr_el3(ICC_CTLR_EL3_RESET);
+	else
+		gic_write_icc_ctlr_el1(ICC_CTLR_EL1_RESET);
+}
+
 #endif
diff --git a/gic-v3.c b/gic-v3.c
index ae2d2bc..4850572 100644
--- a/gic-v3.c
+++ b/gic-v3.c
@@ -121,6 +121,6 @@ void gic_secure_init(void)
 	gic_write_icc_sre(sre);
 	isb();
 
-	gic_write_icc_ctlr(0);
+	gic_init_icc_ctlr();
 	isb();
 }
-- 
2.25.1



From zhukeqian1 at huawei.com  Tue Apr 20 08:32:25 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Tue, 20 Apr 2021 15:32:25 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <3c34baf1-6a57-5666-38a2-0c9d6188b8b8@linux.intel.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
 <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
 <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>
 <ac966fbc-7bc6-9d88-e53e-bcd92d536fdb@huawei.com>
 <3c34baf1-6a57-5666-38a2-0c9d6188b8b8@linux.intel.com>
Message-ID: <a09830f8-b08f-9b80-8f75-17f13088ff6d@huawei.com>

Hi Baolu,

Cheers for the your quick reply.

On 2021/4/20 10:09, Lu Baolu wrote:
> Hi Keqian,
> 
> On 4/20/21 9:25 AM, Keqian Zhu wrote:
>> Hi Baolu,
>>
>> On 2021/4/19 21:33, Lu Baolu wrote:
>>> Hi Keqian,
>>>
>>> On 2021/4/19 17:32, Keqian Zhu wrote:
>>>>>> +EXPORT_SYMBOL_GPL(iommu_split_block);
>>>>> Do you really have any consumers of this interface other than the dirty
>>>>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
>>>>> interface.
>>>>>
>>>>> There is an implicit requirement for such interfaces. The
>>>>> iommu_map/unmap(iova, size) shouldn't be called at the same time.
>>>>> Currently there's no such sanity check in the iommu core. A poorly
>>>>> written driver could mess up the kernel by misusing this interface.
>>>> Yes, I don't think up a scenario except dirty tracking.
>>>>
>>>> Indeed, we'd better not make them as a generic interface.
>>>>
>>>> Do you have any suggestion that underlying iommu drivers can share these code but
>>>> not make it as a generic iommu interface?
>>>>
>>>> I have a not so good idea. Make the "split" interfaces as a static function, and
>>>> transfer the function pointer to start_dirty_log. But it looks weird and inflexible.
>>>
>>> I understand splitting/merging super pages is an optimization, but not a
>>> functional requirement. So is it possible to let the vendor iommu driver
>>> decide whether splitting super pages when starting dirty bit tracking
>>> and the opposite operation during when stopping it? The requirement for
>> Right. If I understand you correct, actually that is what this series does.
> 
> I mean to say no generic APIs, jut do it by the iommu subsystem itself.
> It's totally transparent to the upper level, just like what map() does.
> The upper layer doesn't care about either super page or small page is
> in use when do a mapping, right?
> 
> If you want to consolidate some code, how about putting them in
> start/stop_tracking()?

Yep, this reminds me. What we want to reuse is the logic of "chunk by chunk" in split().
We can implement switch_dirty_log to be "chunk by chunk" too (just the same as sync/clear),
then the vendor iommu driver can invoke it's own private implementation of split().
So we can completely remove split() in the IOMMU core layer.

example code logic

iommu.c:
switch_dirty_log(big range) {
    for_each_iommu_page(big range) {
          ops->switch_dirty_log(iommu_pgsize)
    }
}

vendor iommu driver:
switch_dirty_log(iommu_pgsize) {

    if (enable) {
        ops->split_block(iommu_pgsize)
        /* And other actions, such as enable hardware capability */
    } else {
        for_each_continuous_physical_address(iommu_pgsize)
            ops->merge_page()
    }
}

Besides, vendor iommu driver can invoke split() in clear_dirty_log instead of in switch_dirty_log.
The benefit is that we usually clear dirty log gradually during dirty tracking, then we can split
large page mapping gradually, which speedup start_dirty_log and make less side effect on DMA performance.

Does it looks good for you?

Thanks,
Keqian


From geert at linux-m68k.org  Tue Apr 20 08:39:54 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 20 Apr 2021 09:39:54 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <20210417024522.GP2531743@casper.infradead.org>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
Message-ID: <CAMuHMdXm1Zg=Wm-=tn5jUJwqVGUvCi5yDaW0PXWC2DEDYGcy5A@mail.gmail.com>

Hi Willy,

On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox <willy at infradead.org> wrote:
> Replacement patch to fix compiler warning.
>
> From: "Matthew Wilcox (Oracle)" <willy at infradead.org>
> Date: Fri, 16 Apr 2021 16:34:55 -0400
> Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
> To: brouer at redhat.com
> Cc: linux-kernel at vger.kernel.org,
>     linux-mm at kvack.org,
>     netdev at vger.kernel.org,
>     linuxppc-dev at lists.ozlabs.org,
>     linux-arm-kernel at lists.infradead.org,
>     linux-mips at vger.kernel.org,
>     ilias.apalodimas at linaro.org,
>     mcroce at linux.microsoft.com,
>     grygorii.strashko at ti.com,
>     arnd at kernel.org,
>     hch at lst.de,
>     linux-snps-arc at lists.infradead.org,
>     mhocko at kernel.org,
>     mgorman at suse.de
>
> 32-bit architectures which expect 8-byte alignment for 8-byte integers
> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> page inadvertently expanded in 2019.  When the dma_addr_t was added,
> it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> gap between 'flags' and the union.
>
> Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> This restores the alignment to that of an unsigned long, and also fixes a
> potential problem where (on a big endian platform), the bit used to denote
> PageTail could inadvertently get set, and a racing get_user_pages_fast()
> could dereference a bogus compound_head().
>
> Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>

Thanks for your patch!

> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -97,10 +97,10 @@ struct page {
>                 };
>                 struct {        /* page_pool used by netstack */
>                         /**
> -                        * @dma_addr: might require a 64-bit value even on
> +                        * @dma_addr: might require a 64-bit value on
>                          * 32-bit architectures.
>                          */
> -                       dma_addr_t dma_addr;
> +                       unsigned long dma_addr[2];

So we get two 64-bit words on 64-bit platforms, while only one is
needed?

Would

    unsigned long _dma_addr[sizeof(dma_addr_t) / sizeof(unsigned long)];

work?

Or will the compiler become too overzealous, and warn about the use
of ...[1] below, even when unreachable?
I wouldn't mind an #ifdef instead of an if () in the code below, though.

>                 };
>                 struct {        /* slab, slob and slub */
>                         union {
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b5b195305346..ad6154dc206c 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -198,7 +198,17 @@ static inline void page_pool_recycle_direct(struct page_pool *pool,
>
>  static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
>  {
> -       return page->dma_addr;
> +       dma_addr_t ret = page->dma_addr[0];
> +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +               ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;

We don't seem to have a handy macro for a 32-bit left shift yet...

But you can also avoid the warning using

    ret |= (u64)page->dma_addr[1] << 32;

> +       return ret;
> +}
> +
> +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t addr)
> +{
> +       page->dma_addr[0] = addr;
> +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> +               page->dma_addr[1] = addr >> 16 >> 16;

... but we do have upper_32_bits() for a 32-bit right shift.

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 adrian.hunter at intel.com  Tue Apr 20 08:42:09 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Tue, 20 Apr 2021 10:42:09 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
 <fdadd467-b613-d800-18c5-be064396fd10@intel.com>
 <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
 <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>
Message-ID: <1bc4a73e-b22a-6bad-2583-3a0ffa979414@intel.com>

On 20/04/21 7:15 am, Adrian Hunter wrote:
> On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
>> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>>
>>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>>> ---
>>>
>>> I came across 3 issues while testing.? See comments below.
>>>
>> Hi Adrian
>> Thanks for the comments.
>>> <SNIP>
>>>
>>>> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>>>> ????? if (ufshcd_is_clkscaling_supported(hba))
>>>> ????????? ufshcd_clk_scaling_suspend(hba, false);
>>>> ????? ufshcd_clear_ua_wluns(hba);
>>>
>>> ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
>>> if sdev_rpmb is suspended and sdev_ufs_device is suspending.
>>> e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
>>> is running, at which point sdev_rpmb has already suspended.
>>>
>> Umm, I didn't understand this deadlock.
>> When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
>> sdev_ufs_device is suspending - this can't be runtime_suspending, while ufshcd_err_handling_unprepare is running.
>>
>> If you've a call-stack of this deadlock, please can you share it with me. I'll also try to reproduce this.
> 
> Yes it is system suspend. sdev_rpmb has suspended, sdev_ufs_device is waiting on host_sem.
> ufshcd_err_handler() holds host_sem. ufshcd_clear_ua_wlun(UFS_UPIU_RPMB_WLUN) gets stuck.
> I will get some call-stacks.

Here are the call stacks

[   34.094321] Workqueue: ufs_eh_wq_0 ufshcd_err_handler
[   34.094788] Call Trace:
[   34.095281]  __schedule+0x275/0x6c0
[   34.095743]  schedule+0x41/0xa0
[   34.096240]  blk_queue_enter+0x10d/0x230
[   34.096693]  ? wait_woken+0x70/0x70
[   34.097167]  blk_mq_alloc_request+0x53/0xc0
[   34.097610]  blk_get_request+0x1e/0x60
[   34.098053]  __scsi_execute+0x3c/0x260
[   34.098529]  ufshcd_clear_ua_wlun.cold+0xa6/0x14b
[   34.098977]  ufshcd_clear_ua_wluns.part.0+0x4d/0x92
[   34.099456]  ufshcd_err_handler+0x97a/0x9ff
[   34.099902]  process_one_work+0x1cc/0x360
[   34.100384]  worker_thread+0x45/0x3b0
[   34.100851]  ? process_one_work+0x360/0x360
[   34.101308]  kthread+0xf6/0x130
[   34.101728]  ? kthread_park+0x80/0x80
[   34.102186]  ret_from_fork+0x1f/0x30

[   34.640751] task:kworker/u10:9   state:D stack:14528 pid:  255 ppid:     2 flags:0x00004000
[   34.641253] Workqueue: events_unbound async_run_entry_fn
[   34.641722] Call Trace:
[   34.642217]  __schedule+0x275/0x6c0
[   34.642683]  schedule+0x41/0xa0
[   34.643179]  schedule_timeout+0x18b/0x290
[   34.643645]  ? del_timer_sync+0x30/0x30
[   34.644131]  __down_timeout+0x6b/0xc0
[   34.644568]  ? ufshcd_clkscale_enable_show+0x20/0x20
[   34.645014]  ? async_schedule_node_domain+0x17d/0x190
[   34.645496]  down_timeout+0x42/0x50
[   34.645947]  ufshcd_wl_suspend+0x79/0xa0
[   34.646432]  ? scmd_printk+0x100/0x100
[   34.646917]  scsi_bus_suspend_common+0x56/0xc0
[   34.647405]  ? scsi_bus_freeze+0x10/0x10
[   34.647858]  dpm_run_callback+0x45/0x110
[   34.648347]  __device_suspend+0x117/0x460
[   34.648788]  async_suspend+0x16/0x90
[   34.649251]  async_run_entry_fn+0x26/0x110
[   34.649676]  process_one_work+0x1cc/0x360
[   34.650137]  worker_thread+0x45/0x3b0
[   34.650563]  ? process_one_work+0x360/0x360
[   34.650994]  kthread+0xf6/0x130
[   34.651455]  ? kthread_park+0x80/0x80
[   34.651882]  ret_from_fork+0x1f/0x30



> 
>>
>> I'll address the other comments in the next version.
>>
>>
>> Thank you!
>>
>>>> -??? pm_runtime_put(hba->dev);
>>>> +??? ufshcd_rpm_put(hba);
>>>> ? }
>>>
>>> <SNIP>
>>>
>>>> +void ufshcd_resume_complete(struct device *dev)
>>>> +{
>>
> 



From naresh.kamboju at linaro.org  Tue Apr 20 09:00:10 2021
From: naresh.kamboju at linaro.org (Naresh Kamboju)
Date: Tue, 20 Apr 2021 13:30:10 +0530
Subject: [stable-rc 5.4] thp04: page allocation failure: order:0,
 mode:0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null)
Message-ID: <CA+G9fYtujdEqdGE_3dDpAecLMAmUfwZEm5EmPEGTNdLQgXtYYw@mail.gmail.com>

The following kernel crash reported on arm64 hikey device running stable-rc
 5.4.114-rc1 kernel and testing LTP thp04 test case.

Reported-by: Naresh Kamboju <naresh.kamboju at linaro.org>

I have tried to reproduce this crash but was not successful after
multiple attempts.
Could not bisect this problem because it is not reproducible.

step to reproduce:
-------------------------
 - Boot 5.4.114-rc1 kernel on arm64 hikey device.
 - run ltp cve test case
 - cd /opt/ltp
 - ./runltp -f cve
 -  ./runltp -s thp04

Test crash log:
--------------------
../../../../include/tst_fuzzy_sync.h:507: TINFO: Minimum sampling period ended
../../../../include/tst_fuzzy_sync.h:331: TINFO: loop = 1024, delay_bias = 0
../../../../include/tst_fuzzy_sync.h:320: TINFO: start_a - start_b: {
avg =   -43ns, avg_dev =   104ns, dev_ratio = 2.44 }
../../../../include/tst_fuzzy_sync.h:320: TINFO: end_a - start_a  : {
avg = 1373611ns, avg_dev = 90431ns, dev_ratio = 0.07 }
../../../../include/tst_fuzzy_sync.h:320: TINFO: end_b - start_b  : {
avg = 968943ns, avg_dev = 11299ns, dev_ratio = 0.01 }
../../../../include/tst_fuzzy_sync.h:320: TINFO: end_a - end_b    : {
avg = 404625ns, avg_dev = 80082ns, dev_ratio = 0.20 }
../../../../include/tst_fuzzy_sync.h:320: TINFO: spins            : {
avg = 38993  , avg_dev =  7743  , dev_ratio = 0.20 }
[ 1303.074490] wlcore: down
[ 1303.081180] thp04: page allocation failure: order:0,
mode:0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null)
[ 1303.081189] Unable to handle kernel paging request at virtual
address 0000000000001540
[ 1303.081191] ,cpuset=/,mems_allowed=0
[ 1303.081302] Unable to handle kernel paging request at virtual
address 0000000000001540
[ 1303.081313] Mem abort info:
[ 1303.081322]   ESR = 0x96000004
[ 1303.081331]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1303.081340]   SET = 0, FnV = 0
[ 1303.081348]   EA = 0, S1PTW = 0
[ 1303.081355] Data abort info:
[ 1303.081363]   ISV = 0, ISS = 0x00000004
[ 1303.081371]   CM = 0, WnR = 0
[ 1303.081393] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000074f30000
[ 1303.081402] [0000000000001540] pgd=0000000000000000
[ 1303.081417] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1303.081424] Modules linked in: algif_hash wl18xx wlcore mac80211
cfg80211 hci_uart snd_soc_hdmi_codec btbcm snd_soc_audio_graph_card
adv7511 snd_soc_simple_card_utils crct10dif_ce wlcore_sdio bluetooth
cec kirin_drm drm_kms_helper dw_drm_dsi rfkill drm fuse
[ 1303.081483] CPU: 0 PID: 210 Comm: kworker/0:2 Not tainted 5.4.114-rc1 #1
[ 1303.081487] Hardware name: HiKey Development Board (DT)
[ 1303.081506] Workqueue: events vmstat_shepherd
[ 1303.081514] pstate: a0000005 (NzCv daif -PAN -UAO)
[ 1303.081523] pc : next_online_pgdat+0x24/0x78
[ 1303.081530] lr : next_zone+0x40/0x50
[ 1303.081534] sp : ffff8000129f3d10
[ 1303.081537] x29: ffff8000129f3d10 x28: ffff800011fe7000
[ 1303.081544] x27: ffff000077af1b30 x26: ffff000077af1ae0
[ 1303.081551] x25: 0000000000000000 x24: ffff000077b4cd38
[ 1303.081557] x23: ffff800011fe9000 x22: ffff800011fe9920
[ 1303.081564] x21: 0000000000000003 x20: ffff000077b531d8
[ 1303.081570] x19: 0000000000000000 x18: 0000000000000000
[ 1303.081577] x17: 0000000000000000 x16: 0000000000000000
[ 1303.081583] x15: 0000000000000000 x14: 0000000000000000
[ 1303.081589] x13: 0000000000000000 x12: 0000000000000000
[ 1303.081596] x11: 0000000000000000 x10: 0000000000000040
[ 1303.081603] x9 : 0000002a141f0a9e x8 : 0000000000000002
[ 1303.081609] x7 : ffff000077b30c10 x6 : ffff800011fea000
[ 1303.081616] x5 : ffff800011fea968 x4 : ffff000077b53226
[ 1303.081623] x3 : 0000000000000000 x2 : 000000000000000c
[ 1303.081629] x1 : 0000000000000004 x0 : ffff800011fea000
[ 1303.081637] Call trace:
[ 1303.081645]  next_online_pgdat+0x24/0x78
[ 1303.081654]  next_zone+0x40/0x50
[ 1303.081661]  need_update+0x7c/0xb0
[ 1303.081667]  vmstat_shepherd+0x7c/0x100
[ 1303.081676]  process_one_work+0x1c4/0x480
[ 1303.081682]  worker_thread+0x54/0x430
[ 1303.081690]  kthread+0x11c/0x150
[ 1303.081700]  ret_from_fork+0x10/0x1c
[ 1303.081710] Code: aa1e03e0 d503201f d2800081 9000eb20 (b9554262)
[ 1303.081718] ---[ end trace cd32e7e2c7ee8919 ]---
[ 1303.081820] Unable to handle kernel paging request at virtual
address 0000000000001540
[ 1303.081830] Mem abort info:
[ 1303.081838]   ESR = 0x96000004
[ 1303.081849]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1303.081858]   SET = 0, FnV = 0
[ 1303.081866]   EA = 0, S1PTW = 0
[ 1303.081873] Data abort info:
[ 1303.081881]   ISV = 0, ISS = 0x00000004
[ 1303.081889]   CM = 0, WnR = 0
[ 1303.081899] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000001b98000
[ 1303.081907] [0000000000001540] pgd=0000000000000000
[ 1303.081921] Internal error: Oops: 96000004 [#2] PREEMPT SMP
[ 1303.081926] Modules linked in: algif_hash wl18xx wlcore mac80211
cfg80211 hci_uart snd_soc_hdmi_codec btbcm snd_soc_audio_graph_card
adv7511 snd_soc_simple_card_utils crct10dif_ce wlcore_sdio bluetooth
cec kirin_drm drm_kms_helper dw_drm_dsi rfkill drm fuse
[ 1303.081967] CPU: 2 PID: 51 Comm: kworker/2:1 Tainted: G      D
     5.4.114-rc1 #1
[ 1303.081971] Hardware name: HiKey Development Board (DT)
[ 1303.081982] Workqueue: mm_percpu_wq vmstat_update
[ 1303.081989] pstate: a0000005 (NzCv daif -PAN -UAO)
[ 1303.081997] pc : next_online_pgdat+0x24/0x78
[ 1303.082004] lr : next_zone+0x40/0x50
[ 1303.082007] sp : ffff8000124d3be0
[ 1303.082012] x29: ffff8000124d3be0 x28: 0000000000000000
[ 1303.082019] x27: 0000000000000006 x26: ffff000074e00000
[ 1303.082026] x25: 0000000000000000 x24: ffff8000119f0218
[ 1303.082033] x23: ffff8000119f01d8 x22: 0000000000000000
[ 1303.082043] x21: ffff8000124d3cc0 x20: ffff8000124d3cd8
[ 1303.082050] x19: 0000000000000000 x18: 0000000000000000
[ 1303.082057] x17: 0000000000000000 x16: 0000000000000000
[ 1303.082064] x15: 0000000000000000 x14: 0000000000000000
[ 1303.082070] x13: 0000000000000000 x12: 0000000000000000
[ 1303.082077] x11: 0000000000000000 x10: 0000000000000000
[ 1303.082084] x9 : 0000000000000000 x8 : ffff000077bdbe20
[ 1303.082090] x7 : ffff8000119f0218 x6 : ffff8000119f0226
[ 1303.082097] x5 : 0000000000000000 x4 : 0000000000000000
[ 1303.082104] x3 : ffff8000119f01d8 x2 : ffff800066144000
[ 1303.082111] x1 : 0000000000000004 x0 : ffff800011fea000
[ 1303.082117] Call trace:
[ 1303.082125]  next_online_pgdat+0x24/0x78
[ 1303.082131]  next_zone+0x40/0x50
[ 1303.082139]  refresh_cpu_vm_stats+0xbc/0x3f8
[ 1303.082146]  vmstat_update+0x1c/0x88
[ 1303.082153]  process_one_work+0x1c4/0x480
[ 1303.082158]  worker_thread+0x54/0x430
[ 1303.082165]  kthread+0x11c/0x150
[ 1303.082172]  ret_from_fork+0x10/0x1c
[ 1303.082181] Code: aa1e03e0 d503201f d2800081 9000eb20 (b9554262)
[ 1303.082187] ---[ end trace cd32e7e2c7ee891a ]---
[ 1303.085351] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085362]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085372]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.085502] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085510]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085517]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.085618] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085626]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085633]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.085713] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085721]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085728]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.085822] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085829]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085836]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.085916] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.085923]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.085931]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.086023] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.086030]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.086037]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.086117] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.086124]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.086131]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.086223] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.086231]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.086238]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.086317] SLUB: Unable to allocate memory on node -1,
gfp=0x400cc0(GFP_KERNEL_ACCOUNT)
[ 1303.086324]   cache: skbuff_head_cache, object size: 216, buffer
size: 256, default order: 1, min order: 0
[ 1303.086331]   node 0: slabs: 53, objs: 1696, free: 0
[ 1303.091806] Mem abort info:
[ 1303.091810]   ESR = 0x96000006
[ 1303.091815]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1303.091819]   SET = 0, FnV = 0
[ 1303.091823]   EA = 0, S1PTW = 0
[ 1303.091826] Data abort info:
[ 1303.091830]   ISV = 0, ISS = 0x00000006
[ 1303.091834]   CM = 0, WnR = 0
[ 1303.091840] user pgtable: 4k pages, 48-bit VAs, pgdp=000000006ab4d000
[ 1303.091844] [0000000000001540] pgd=000000006dded003,
pud=000000006a870003, pmd=0000000000000000
[ 1303.091858] Internal error: Oops: 96000006 [#3] PREEMPT SMP
[ 1303.092766] socket: no more sockets
[ 1303.092883] socket: no more sockets
[ 1303.092913] socket: no more sockets
[ 1303.092942] socket: no more sockets
[ 1303.092971] socket: no more sockets
[ 1303.092999] socket: no more sockets
[ 1303.093027] socket: no more sockets
[ 1303.093056] socket: no more sockets
[ 1303.093078] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093085] socket: no more sockets
[ 1303.093113] socket: no more sockets
[ 1303.093246] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093331] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093488] NetworkManager invoked oom-killer: gfp_mask=0x0(),
order=0, oom_score_adj=0
[ 1303.093505] CPU: 4 PID: 354 Comm: NetworkManager Tainted: G      D
         5.4.114-rc1 #1
[ 1303.093510] Hardware name: HiKey Development Board (DT)
[ 1303.093516] Call trace:
[ 1303.093530]  dump_backtrace+0x0/0x178
[ 1303.093533] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093538]  show_stack+0x28/0x38
[ 1303.093548]  dump_stack+0xe0/0x160
[ 1303.093559]  dump_header+0x4c/0x1f8
[ 1303.093568]  oom_kill_process+0x1cc/0x1d0
[ 1303.093576]  out_of_memory+0x178/0x4f0
[ 1303.093584]  pagefault_out_of_memory+0x8c/0x298
[ 1303.093593]  do_page_fault+0x484/0x4c8
[ 1303.093602]  do_translation_fault+0xb4/0xd0
[ 1303.093609]  do_mem_abort+0x54/0xb0
[ 1303.093616]  el0_da+0x1c/0x20
[ 1303.093620] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093625] Mem-Info:
[ 1303.093648] Unable to handle kernel paging request at virtual
address 0000000000001540
[ 1303.093656] Mem abort info:
[ 1303.093664]   ESR = 0x96000006
[ 1303.093673]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1303.093681]   SET = 0, FnV = 0
[ 1303.093689]   EA = 0, S1PTW = 0
[ 1303.093697] Data abort info:
[ 1303.093705]   ISV = 0, ISS = 0x00000006
[ 1303.093713]   CM = 0, WnR = 0
[ 1303.093722] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000072aa1000
[ 1303.093730] [0000000000001540] pgd=0000000074f43003,
pud=000000006f64c003, pmd=0000000000000000
[ 1303.093776] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.093859] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.094013] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.094095] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.094248] systemd-journald[246]: Failed to open system journal:
Cannot allocate memory
[ 1303.100042] CPU: 1 PID: 18028 Comm: thp04 Tainted: G      D
  5.4.114-rc1 #1
[ 1303.103634] Modules linked in: algif_hash wl18xx wlcore mac80211
cfg80211 hci_uart snd_soc_hdmi_codec btbcm snd_soc_audio_graph_card
adv7511 snd_soc_simple_card_utils crct10dif_ce wlcore_sdio bluetooth
cec kirin_drm drm_kms_helper dw_drm_dsi rfkill drm fuse
[ 1303.111730] Hardware name: HiKey Development Board (DT)
[ 1303.114592] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G      D
  5.4.114-rc1 #1
[ 1303.117710] Call trace:
[ 1303.123139] Hardware name: HiKey Development Board (DT)
[ 1303.126270]  dump_backtrace+0x0/0x178
[ 1303.129474] pstate: a0000085 (NzCv daIf -PAN -UAO)
[ 1303.132417]  show_stack+0x28/0x38
[ 1303.136341] pc : next_online_pgdat+0x24/0x78
[ 1303.139369]  dump_stack+0xe0/0x160
[ 1303.145953] lr : next_zone+0x40/0x50
[ 1303.150939]  warn_alloc+0x100/0x170
[ 1303.156632] sp : ffff80001238bd20
[ 1303.179898]  __alloc_pages_slowpath+0xbc4/0xbf0
[ 1303.186741] x29: ffff80001238bd20 x28: 0000000000000000
[ 1303.192082]  __alloc_pages_nodemask+0x2ec/0x360
[ 1303.196535] x27: 0000000000000006 x26: ffff0000389e8000
[ 1303.201434]  alloc_pages_current+0x90/0x100
[ 1303.205791] x25: 0000000000000000 x24: ffff8000119f0218
[ 1303.209450]  do_huge_pmd_anonymous_page+0x3b0/0x818
[ 1303.212830] x23: ffff8000119f01d8 x22: 0000000000000000
[ 1303.218261]  __handle_mm_fault+0x83c/0x10a8
[ 1303.223684] x21: ffff80001238be00 x20: ffff80001238be18
[ 1303.229113]  handle_mm_fault+0x110/0x1f8
[ 1303.234536] x19: 0000000000000000 x18: 0000000000000000
[ 1303.239968]  do_page_fault+0x14c/0x4c8
[ 1303.245390] x17: 0000000000000000 x16: 0000000000000000
[ 1303.250821]  do_translation_fault+0xb4/0xd0
[ 1303.256245] x15: 0000000000000000 x14: 0000000000000000
[ 1303.261673]  do_mem_abort+0x54/0xb0
[ 1303.267097] x13: 0000000000000000 x12: 0000000000000000
[ 1303.272526]  el0_da+0x1c/0x20
[ 1303.277951] x11: 0000000000000000 x10: 0000000000000000
[ 1303.291214] Mem-Info:
[ 1303.304193] x9 : 0000000000000000 x8 : ffff000077bdbe20
[ 1303.304201] x7 : ffff8000119f0218 x6 : ffff8000119f0226
[ 1303.304208] x5 : 0000000000000000 x4 : ffff8000661c0000
[ 1303.304215] x3 : ffff800011feaff0 x2 : ffff8000661c0000
[ 1303.317358] Unable to handle kernel paging request at virtual
address 0000000000001540
[ 1303.327384] x1 : 0000000000000004 x0 : ffff800011fea000
[ 1303.327393] Call trace:
[ 1303.327406]  next_online_pgdat+0x24/0x78
[ 1303.327412]  next_zone+0x40/0x50
[ 1303.327420]  refresh_cpu_vm_stats+0xbc/0x3f8
[ 1303.327427]  quiet_vmstat+0x64/0x488
[ 1303.327441]  tick_nohz_idle_stop_tick+0xc4/0x2f0
[ 1303.338935] Mem abort info:
[ 1303.349349]  do_idle+0x1e0/0x2a0
[ 1303.349358]  cpu_startup_entry+0x30/0x90
[ 1303.349367]  secondary_start_kernel+0x16c/0x198
[ 1303.349380] Code: aa1e03e0 d503201f d2800081 9000eb20 (b9554262)
[ 1303.349392] ---[ end trace cd32e7e2c7ee891b ]---

Full test log link,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.113-74-gc509b45704fd/testrun/4393633/suite/linux-log-parser/test/check-kernel-oops-2551234/log
and
https://lkft.validation.linaro.org/scheduler/job/2551234#L10291

metadata:
  git branch: linux-5.4.y
  git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
  git commit: c509b45704fd663fc59405e98d29d7f06eaae4b5
  git describe: v5.4.113-74-gc509b45704fd
  make_kernelversion: 5.4.114-rc1
  kernel-config: https://builds.tuxbuild.com/1rOEzHLegEbudzQQdiifqEuFVur/config

--
Linaro LKFT
https://lkft.linaro.org


From baolu.lu at linux.intel.com  Tue Apr 20 08:53:42 2021
From: baolu.lu at linux.intel.com (Lu Baolu)
Date: Tue, 20 Apr 2021 15:53:42 +0800
Subject: [PATCH v3 02/12] iommu: Add iommu_split_block interface
In-Reply-To: <a09830f8-b08f-9b80-8f75-17f13088ff6d@huawei.com>
References: <20210413085457.25400-1-zhukeqian1@huawei.com>
 <20210413085457.25400-3-zhukeqian1@huawei.com>
 <fb350f27-be8b-80bf-1ce8-e7e8aba26f02@linux.intel.com>
 <491da550-dc54-42e6-ac91-13d411575fad@huawei.com>
 <bc2da48b-f4f7-5a46-2696-2c412a83d190@linux.intel.com>
 <ac966fbc-7bc6-9d88-e53e-bcd92d536fdb@huawei.com>
 <3c34baf1-6a57-5666-38a2-0c9d6188b8b8@linux.intel.com>
 <a09830f8-b08f-9b80-8f75-17f13088ff6d@huawei.com>
Message-ID: <8a25f78b-9153-d21b-013d-d7f64ab48c54@linux.intel.com>

On 4/20/21 3:32 PM, Keqian Zhu wrote:
> Hi Baolu,
> 
> Cheers for the your quick reply.
> 
> On 2021/4/20 10:09, Lu Baolu wrote:
>> Hi Keqian,
>>
>> On 4/20/21 9:25 AM, Keqian Zhu wrote:
>>> Hi Baolu,
>>>
>>> On 2021/4/19 21:33, Lu Baolu wrote:
>>>> Hi Keqian,
>>>>
>>>> On 2021/4/19 17:32, Keqian Zhu wrote:
>>>>>>> +EXPORT_SYMBOL_GPL(iommu_split_block);
>>>>>> Do you really have any consumers of this interface other than the dirty
>>>>>> bit tracking? If not, I don't suggest to make this as a generic IOMMU
>>>>>> interface.
>>>>>>
>>>>>> There is an implicit requirement for such interfaces. The
>>>>>> iommu_map/unmap(iova, size) shouldn't be called at the same time.
>>>>>> Currently there's no such sanity check in the iommu core. A poorly
>>>>>> written driver could mess up the kernel by misusing this interface.
>>>>> Yes, I don't think up a scenario except dirty tracking.
>>>>>
>>>>> Indeed, we'd better not make them as a generic interface.
>>>>>
>>>>> Do you have any suggestion that underlying iommu drivers can share these code but
>>>>> not make it as a generic iommu interface?
>>>>>
>>>>> I have a not so good idea. Make the "split" interfaces as a static function, and
>>>>> transfer the function pointer to start_dirty_log. But it looks weird and inflexible.
>>>>
>>>> I understand splitting/merging super pages is an optimization, but not a
>>>> functional requirement. So is it possible to let the vendor iommu driver
>>>> decide whether splitting super pages when starting dirty bit tracking
>>>> and the opposite operation during when stopping it? The requirement for
>>> Right. If I understand you correct, actually that is what this series does.
>>
>> I mean to say no generic APIs, jut do it by the iommu subsystem itself.
>> It's totally transparent to the upper level, just like what map() does.
>> The upper layer doesn't care about either super page or small page is
>> in use when do a mapping, right?
>>
>> If you want to consolidate some code, how about putting them in
>> start/stop_tracking()?
> 
> Yep, this reminds me. What we want to reuse is the logic of "chunk by chunk" in split().
> We can implement switch_dirty_log to be "chunk by chunk" too (just the same as sync/clear),
> then the vendor iommu driver can invoke it's own private implementation of split().
> So we can completely remove split() in the IOMMU core layer.
> 
> example code logic
> 
> iommu.c:
> switch_dirty_log(big range) {
>      for_each_iommu_page(big range) {
>            ops->switch_dirty_log(iommu_pgsize)
>      }
> }
> 
> vendor iommu driver:
> switch_dirty_log(iommu_pgsize) {
> 
>      if (enable) {
>          ops->split_block(iommu_pgsize)
>          /* And other actions, such as enable hardware capability */
>      } else {
>          for_each_continuous_physical_address(iommu_pgsize)
>              ops->merge_page()
>      }
> }
> 
> Besides, vendor iommu driver can invoke split() in clear_dirty_log instead of in switch_dirty_log.
> The benefit is that we usually clear dirty log gradually during dirty tracking, then we can split
> large page mapping gradually, which speedup start_dirty_log and make less side effect on DMA performance.
> 
> Does it looks good for you?

Yes. It's clearer now.

> 
> Thanks,
> Keqian
> 

Best regards,
baolu


From nava.manne at xilinx.com  Tue Apr 20 09:11:48 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:48 +0530
Subject: [PATCH 0/5]misc: Add afi config drivers support.
Message-ID: <20210420081153.17020-1-nava.manne@xilinx.com>

Xilinx SoC platforms (Zynq and ZynqMP) connect the PS to the
programmable logic (PL) through the AXI port.This AXI port helps
to establish the data path between the PS and PL. In-order to
establish to proper communication data path between PS and PL
the AXI port data path should be configured with the proper
Bus-width values

This patch series Adds afi config drivers support to handle the
PS-PL AXI port bus-width configurations.

Nava kishore Manne (5):
  misc: doc: Add binding doc for the afi config driver
  misc: zynq: Add afi config driver
  firmware: xilinx: Add afi ioctl support
  misc: doc: Add binding doc for the zynqmp afi config driver
  misc: zynqmp: Add afi config driver

 .../bindings/misc/xlnx,zynq-afi-fpga.yaml     |  47 ++++++
 .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
 drivers/firmware/xilinx/zynqmp.c              |  13 ++
 drivers/misc/Kconfig                          |  22 +++
 drivers/misc/Makefile                         |   2 +
 drivers/misc/zynq-afi.c                       |  81 +++++++++++
 drivers/misc/zynqmp-afi.c                     |  83 +++++++++++
 include/linux/firmware/xlnx-zynqmp.h          |   7 +
 8 files changed, 391 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynq-afi-fpga.yaml
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
 create mode 100644 drivers/misc/zynq-afi.c
 create mode 100644 drivers/misc/zynqmp-afi.c

-- 
2.18.0



From nava.manne at xilinx.com  Tue Apr 20 09:11:49 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:49 +0530
Subject: [PATCH 1/5] misc: doc: Add binding doc for the afi config driver
In-Reply-To: <20210420081153.17020-1-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
Message-ID: <20210420081153.17020-2-nava.manne@xilinx.com>

This patch adds the binding document for the afi config
driver.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 .../bindings/misc/xlnx,zynq-afi-fpga.yaml     | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynq-afi-fpga.yaml

diff --git a/Documentation/devicetree/bindings/misc/xlnx,zynq-afi-fpga.yaml b/Documentation/devicetree/bindings/misc/xlnx,zynq-afi-fpga.yaml
new file mode 100644
index 000000000000..9c20a192d6a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,zynq-afi-fpga.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,zynq-afi-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Zynq AFI interface Manager.
+
+maintainers:
+  - Nava kishore Manne <nava.manne at xilinx.com>
+
+description: |
+  The Zynq Processing System core provides access from PL masters to PS
+  internal peripherals, and memory through AXI FIFO interface(AFI)
+  interfaces.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - xlnx,zynq-afi-fpga
+  reg:
+    maxItems: 1
+
+  xlnx,afi-buswidth:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+            Size of the afi bus width.
+            0 - 64-bit AXI data width.
+            1 - 32-bit AXI data width.
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - xlnx,afi-buswidth
+
+additionalProperties: false
+
+examples:
+  - |
+    afi0: afi at f8008000 {
+        compatible = "xlnx,zynq-afi-fpga";
+        reg = <0xf8008000 0x1000>;
+        xlnx,afi-buswidth = <1>;
+    };
+...
-- 
2.18.0



From nava.manne at xilinx.com  Tue Apr 20 09:11:51 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:51 +0530
Subject: [PATCH 3/5] firmware: xilinx: Add afi ioctl support
In-Reply-To: <20210420081153.17020-1-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
Message-ID: <20210420081153.17020-4-nava.manne@xilinx.com>

This patch adds afi ioctl to support dynamic PS-PL
bus width settings.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 13 +++++++++++++
 include/linux/firmware/xlnx-zynqmp.h |  7 +++++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 7eb9958662dd..ada9eb9e26e3 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -713,6 +713,19 @@ int zynqmp_pm_read_pggs(u32 index, u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_read_pggs);
 
+/**
+ * zynqmp_pm_afi()  - PM API for setting the PS-PL bus width
+ * @index:	Register index value
+ * @value:	value to be written into the register
+ *
+ * Return:      Returns status, either success or error+reason
+ */
+int zynqmp_pm_afi(u32 index, u32 value)
+{
+	return zynqmp_pm_invoke_fn(PM_IOCTL, 0, IOCTL_AFI, index, value, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_afi);
+
 /**
  * zynqmp_pm_set_boot_health_status() - PM API for setting healthy boot status
  * @value:	Status value to be written
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 71177b17eee5..792fb4f5d86f 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -113,6 +113,7 @@ enum pm_ioctl_id {
 	IOCTL_READ_PGGS = 15,
 	/* Set healthy bit value */
 	IOCTL_SET_BOOT_HEALTH_STATUS = 17,
+	IOCTL_AFI = 18,
 };
 
 enum pm_query_id {
@@ -353,6 +354,7 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_afi(u32 index, u32 value);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -537,6 +539,11 @@ static inline int zynqmp_pm_set_boot_health_status(u32 value)
 {
 	return -ENODEV;
 }
+
+static inline int zynqmp_pm_afi(u32 index, u32 value)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.18.0



From nava.manne at xilinx.com  Tue Apr 20 09:11:50 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:50 +0530
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <20210420081153.17020-1-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
Message-ID: <20210420081153.17020-3-nava.manne@xilinx.com>

This patch adds zynq afi config driver. This is useful for
the configuration of the PS-PL interface on zynq platform.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/misc/Kconfig    | 11 ++++++
 drivers/misc/Makefile   |  1 +
 drivers/misc/zynq-afi.c | 81 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 93 insertions(+)
 create mode 100644 drivers/misc/zynq-afi.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f532c59bb59b..877b43b3377d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -445,6 +445,17 @@ config HISI_HIKEY_USB
 	  switching between the dual-role USB-C port and the USB-A host ports
 	  using only one USB controller.
 
+config ZYNQ_AFI
+	tristate "Xilinx ZYNQ AFI support"
+	help
+	  Zynq AFI driver support for writing to the AFI registers
+	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
+	  the PS to the programmable logic (PL) through the AXI port.
+	  This AXI port helps to establish the data path between the
+	  PS and PL.In-order to establish the proper communication path
+	  between PS and PL, the AXI port data path should be configured
+	  with the proper Bus-width values
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 99b6f15a3c70..e9b03843100f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI)		+= habanalabs/
 obj-$(CONFIG_UACCE)		+= uacce/
 obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
 obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
+obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
diff --git a/drivers/misc/zynq-afi.c b/drivers/misc/zynq-afi.c
new file mode 100644
index 000000000000..04317d1bdb98
--- /dev/null
+++ b/drivers/misc/zynq-afi.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx ZYNQ AFI driver.
+ * Copyright (c) 2018-2021 Xilinx Inc.
+ */
+
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+/* Registers and special values for doing register-based operations */
+#define AFI_RDCHAN_CTRL_OFFSET	0x00
+#define AFI_WRCHAN_CTRL_OFFSET	0x14
+
+#define AFI_BUSWIDTH_MASK	0x01
+
+/**
+ * struct afi_fpga - AFI register description
+ * @membase:	pointer to register struct
+ * @afi_width:	AFI bus width to be written
+ */
+struct zynq_afi_fpga {
+	void __iomem	*membase;
+	u32		afi_width;
+};
+
+static int zynq_afi_fpga_probe(struct platform_device *pdev)
+{
+	struct zynq_afi_fpga *afi_fpga;
+	struct resource *res;
+	u32 reg_val;
+	u32 val;
+
+	afi_fpga = devm_kzalloc(&pdev->dev, sizeof(*afi_fpga), GFP_KERNEL);
+	if (!afi_fpga)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	afi_fpga->membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(afi_fpga->membase))
+		return PTR_ERR(afi_fpga->membase);
+
+	val = device_property_read_u32(&pdev->dev, "xlnx,afi-width",
+				       &afi_fpga->afi_width);
+	if (val) {
+		dev_err(&pdev->dev, "failed to get the afi bus width\n");
+		return -EINVAL;
+	}
+
+	reg_val = readl(afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
+	reg_val &= ~AFI_BUSWIDTH_MASK;
+	writel(reg_val | afi_fpga->afi_width,
+	       afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
+	reg_val = readl(afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
+	reg_val &= ~AFI_BUSWIDTH_MASK;
+	writel(reg_val | afi_fpga->afi_width,
+	       afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
+
+	return 0;
+}
+
+static const struct of_device_id zynq_afi_fpga_ids[] = {
+	{ .compatible = "xlnx,zynq-afi-fpga" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, zynq_afi_fpga_ids);
+
+static struct platform_driver zynq_afi_fpga_driver = {
+	.driver = {
+		.name = "zynq-afi-fpga",
+		.of_match_table = zynq_afi_fpga_ids,
+	},
+	.probe = zynq_afi_fpga_probe,
+};
+module_platform_driver(zynq_afi_fpga_driver);
+
+MODULE_DESCRIPTION("ZYNQ FPGA AFI module");
+MODULE_AUTHOR("Nava kishore Manne <nava.manne at xilinx.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0



From nava.manne at xilinx.com  Tue Apr 20 09:11:52 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:52 +0530
Subject: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
 driver
In-Reply-To: <20210420081153.17020-1-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
Message-ID: <20210420081153.17020-5-nava.manne@xilinx.com>

This patch adds the binding document for the zynqmp afi
config driver.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml

diff --git a/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
new file mode 100644
index 000000000000..3ae22096b22a
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/xlnx,zynqmp-afi-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP AFI interface Manager.
+
+maintainers:
+  - Nava kishore Manne <nava.manne at xilinx.com>
+
+description: |
+  The Zynq UltraScale+ MPSoC Processing System core provides access from PL
+  masters to PS internal peripherals, and memory through AXI FIFO interface(AFI)
+  interfaces.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - xlnx,zynqmp-afi-fpga
+
+  config-afi:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description: |
+      Pairs of  <regid value >
+      The possible values of regid and values are
+      regid - Regids of the register to be written possible values
+        0- AFIFM0_RDCTRL
+        1- AFIFM0_WRCTRL
+        2- AFIFM1_RDCTRL
+        3- AFIFM1_WRCTRL
+        4- AFIFM2_RDCTRL
+        5- AFIFM2_WRCTRL
+        6- AFIFM3_RDCTRL
+        7- AFIFM3_WRCTRL
+        8- AFIFM4_RDCTRL
+        9- AFIFM4_WRCTRL
+        10- AFIFM5_RDCTRL
+        11- AFIFM5_WRCTRL
+        12- AFIFM6_RDCTRL
+        13- AFIFM6_WRCTRL
+        14- AFIFS
+        15- AFIFS_SS2
+      value - Array of values to be written.
+        for FM0_RDCTRL(0) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM0_WRCTRL(1) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM1_RDCTRL(2) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM1_WRCTRL(3) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM2_RDCTRL(4) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM2_WRCTRL(5) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM3_RDCTRL(6) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM3_WRCTRL(7) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM4_RDCTRL(8) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM4_WRCTRL(9) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM5_RDCTRL(10) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM5_WRCTRL(11) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM6_RDCTRL(12) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for FM6_WRCTRL(13) the valid values-fabric width
+          2 - 32-bit
+          1 - 64-bit
+          0 - 128-bit
+        for AFI_FA(14)
+          dw_ss1_sel      bits (11:10)
+          dw_ss0_sel      bits (9:8)
+            0x0 - 32-bit AXI data width
+            0x1 - 64-bit AXI data width
+            0x2 - 128-bit AXI data width
+            All other bits are 0 write ignored.
+
+        for AFI_FA(15)  selects for ss2AXI data width valid values
+          0x000 - 32-bit AXI data width
+          0x100 - 64-bit AXI data width
+          0x200 - 128-bit AXI data width
+    minItems: 1
+    maxItems: 15
+
+required:
+  - compatible
+  - config-afi
+
+additionalProperties: false
+
+examples:
+  - |
+    firmware {
+      zynqmp_firmware: zynqmp-firmware {
+        compatible = "xlnx,zynqmp-firmware";
+        method = "smc";
+        afi0: afi {
+          compatible = "xlnx,afi-fpga";
+          config-afi = <0 2>, <1 1>, <2 1>;
+        };
+      };
+    };
+
+...
-- 
2.18.0



From nava.manne at xilinx.com  Tue Apr 20 09:11:53 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:41:53 +0530
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <20210420081153.17020-1-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
Message-ID: <20210420081153.17020-6-nava.manne@xilinx.com>

This patch adds zynqmp afi config driver.This is useful for
the configuration of the PS-PL interface on Zynq US+ MPSoC
platform.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
 drivers/misc/Kconfig      | 11 ++++++
 drivers/misc/Makefile     |  1 +
 drivers/misc/zynqmp-afi.c | 83 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/misc/zynqmp-afi.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 877b43b3377d..d1ea1eeb3ac1 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -456,6 +456,17 @@ config ZYNQ_AFI
 	  between PS and PL, the AXI port data path should be configured
 	  with the proper Bus-width values
 
+config ZYNQMP_AFI
+        tristate "Xilinx ZYNQMP AFI support"
+        help
+	  ZynqMP AFI driver support for writing to the AFI registers for
+	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
+	  PS to the programmable logic (PL) through the AXI port. This AXI
+	  port helps to establish the data path between the PS and PL.
+	  In-order to establish the proper communication path between
+	  PS and PL, the AXI port data path should be configured with
+	  the proper Bus-width values
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e9b03843100f..54bd0edc511e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
 obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
 obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
 obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
+obj-$(CONFIG_ZYNQMP_AFI)	+= zynqmp-afi.o
diff --git a/drivers/misc/zynqmp-afi.c b/drivers/misc/zynqmp-afi.c
new file mode 100644
index 000000000000..a318652576d2
--- /dev/null
+++ b/drivers/misc/zynqmp-afi.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx FPGA AFI bridge.
+ * Copyright (c) 2018-2021 Xilinx Inc.
+ */
+
+#include <linux/err.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/**
+ * struct zynqmp_afi_fpga - AFI register description
+ * @value: value to be written to the register
+ * @regid: Register id for the register to be written
+ */
+struct zynqmp_afi_fpga {
+	u32 value;
+	u32 regid;
+};
+
+static int zynqmp_afi_fpga_probe(struct platform_device *pdev)
+{
+	struct zynqmp_afi_fpga *zynqmp_afi_fpga;
+	struct device_node *np = pdev->dev.of_node;
+	int i, entries, ret;
+	u32 reg, val;
+
+	zynqmp_afi_fpga = devm_kzalloc(&pdev->dev,
+				       sizeof(*zynqmp_afi_fpga), GFP_KERNEL);
+	if (!zynqmp_afi_fpga)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, zynqmp_afi_fpga);
+
+	entries = of_property_count_u32_elems(np, "config-afi");
+	if (!entries || (entries % 2)) {
+		dev_err(&pdev->dev, "Invalid number of registers\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < entries / 2; i++) {
+		ret = of_property_read_u32_index(np, "config-afi", i * 2, &reg);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to read register\n");
+			return -EINVAL;
+		}
+		ret = of_property_read_u32_index(np, "config-afi", i * 2 + 1,
+						 &val);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to read value\n");
+			return -EINVAL;
+		}
+		ret = zynqmp_pm_afi(reg, val);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "AFI register write error %d\n",
+				ret);
+			return ret;
+		}
+	}
+	return 0;
+}
+
+static const struct of_device_id zynqmp_afi_fpga_ids[] = {
+	{ .compatible = "xlnx,zynqmp-afi-fpga" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, zynqmp_afi_fpga_ids);
+
+static struct platform_driver zynqmp_afi_fpga_driver = {
+	.driver = {
+		.name = "zynqmp-afi-fpga",
+		.of_match_table = zynqmp_afi_fpga_ids,
+	},
+	.probe = zynqmp_afi_fpga_probe,
+};
+module_platform_driver(zynqmp_afi_fpga_driver);
+
+MODULE_DESCRIPTION("ZYNQMP FPGA afi module");
+MODULE_AUTHOR("Nava kishore Manne <nava.manne at xilinx.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0



From patrice.chotard at foss.st.com  Tue Apr 20 09:21:03 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Tue, 20 Apr 2021 10:21:03 +0200
Subject: spi: stm32-qspi: Fix compilation warning in ARM64
Message-ID: <20210420082103.1693-1-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

This fixes warnings detected when compiling in ARM64.
Introduced by 'commit 18674dee3cd6 ("spi: stm32-qspi: Add dirmap support")'

Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/spi/spi-stm32-qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index e2a99f054551..02691c1603d9 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -478,7 +478,7 @@ static ssize_t stm32_qspi_dirmap_read(struct spi_mem_dirmap_desc *desc,
 	 * all needed transfer information into struct spi_mem_op
 	 */
 	memcpy(&op, &desc->info.op_tmpl, sizeof(struct spi_mem_op));
-	dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
+	dev_dbg(qspi->dev, "%s len = 0x%lx offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
 
 	op.data.nbytes = len;
 	op.addr.val = desc->info.offset + offs;
-- 
2.17.1



From jens.wiklander at linaro.org  Tue Apr 20 09:32:37 2021
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Tue, 20 Apr 2021 10:32:37 +0200
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to
 json schema
In-Reply-To: <20210416222518.15801-1-nm@ti.com>
References: <20210416222518.15801-1-nm@ti.com>
Message-ID: <CAHUa44GZenrwVWRZW6BKB8cktfXvktJ4OCF0AgPKanYGV01m5g@mail.gmail.com>

On Sat, Apr 17, 2021 at 12:25 AM Nishanth Menon <nm at ti.com> wrote:
>
> Convert linaro,optee-tz to json schema format for better documentation
> and error checks.
>
> NOTE:
> 1. This change does introduce a stricter naming convention for
>    optee nodes.
> 2. We do have false positive checkpatch warning with this patch:
>    "DT binding docs and includes should be a separate patch"
>
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ----------
>  .../arm/firmware/linaro,optee-tz.yaml         | 62 +++++++++++++++++++
>  2 files changed, 62 insertions(+), 31 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> deleted file mode 100644
> index d38834c67dff..000000000000
> --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -OP-TEE Device Tree Bindings
> -
> -OP-TEE is a piece of software using hardware features to provide a Trusted
> -Execution Environment. The security can be provided with ARM TrustZone, but
> -also by virtualization or a separate chip.
> -
> -We're using "linaro" as the first part of the compatible property for
> -the reference implementation maintained by Linaro.
> -
> -* OP-TEE based on ARM TrustZone required properties:
> -
> -- compatible     : should contain "linaro,optee-tz"
> -
> -- method         : The method of calling the OP-TEE Trusted OS. Permitted
> -                   values are:
> -
> -                   "smc" : SMC #0, with the register assignments specified
> -                          in drivers/tee/optee/optee_smc.h
> -
> -                   "hvc" : HVC #0, with the register assignments specified
> -                          in drivers/tee/optee/optee_smc.h
> -
> -
> -
> -Example:
> -       firmware {
> -               optee {
> -                       compatible = "linaro,optee-tz";
> -                       method = "smc";
> -               };
> -       };
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> new file mode 100644
> index 000000000000..6513b5ac8b2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#

Are these links supposed to work?

Thanks,
Jens


> +
> +title: OP-TEE Device Tree Bindings
> +
> +maintainers:
> +  - Jens Wiklander <jens.wiklander at linaro.org>
> +
> +description: |
> +  OP-TEE is a piece of software using hardware features to provide a Trusted
> +  Execution Environment. The security can be provided with ARM TrustZone, but
> +  also by virtualization or a separate chip.
> +
> +  We're using "linaro" as the first part of the compatible property for
> +  the reference implementation maintained by Linaro.
> +
> +properties:
> +  $nodename:
> +    const: 'optee'
> +
> +  compatible:
> +    const: linaro,optee-tz
> +
> +  method:
> +    description: The method of calling the OP-TEE Trusted OS.
> +    oneOf:
> +      - description: |
> +          SMC #0, with the register assignments specified
> +          in drivers/tee/optee/optee_smc.h
> +        items:
> +          - const: smc
> +      - description: |
> +          HVC #0, with the register assignments specified
> +          in drivers/tee/optee/optee_smc.h
> +        items:
> +          - const: hvc
> +
> +required:
> +  - compatible
> +  - method
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    firmware  {
> +        optee  {
> +            compatible = "linaro,optee-tz";
> +            method = "smc";
> +        };
> +    };
> +
> +  - |
> +    firmware  {
> +        optee  {
> +            compatible = "linaro,optee-tz";
> +            method = "hvc";
> +        };
> +    };
> --
> 2.31.0
>


From joe.burmeister at devtank.co.uk  Tue Apr 20 09:34:02 2021
From: joe.burmeister at devtank.co.uk (Joe Burmeister)
Date: Tue, 20 Apr 2021 09:34:02 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go beyond
 limit.
Message-ID: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>

It was previoulsy possible to have a device tree with more chips than
the driver supports and go off the end of CS arrays.

This patches inforces CS limit but sets that limit to the max of the
default limit and what is in the device tree when driver is loaded.

Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>
---
 drivers/spi/spi-bcm2835.c | 77 +++++++++++++++++++++++++++++----------
 1 file changed, 58 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index aab6c7e5c114..cee761bfffe4 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -28,6 +28,7 @@
 #include <linux/gpio/consumer.h>
 #include <linux/gpio/machine.h> /* FIXME: using chip internals */
 #include <linux/gpio/driver.h> /* FIXME: using chip internals */
+#include <linux/of_gpio.h>
 #include <linux/of_irq.h>
 #include <linux/spi/spi.h>
 
@@ -134,7 +135,7 @@ struct bcm2835_spi {
 	int tx_prologue;
 	int rx_prologue;
 	unsigned int tx_spillover;
-	u32 prepare_cs[BCM2835_SPI_NUM_CS];
+	u32 *prepare_cs;
 
 	struct dentry *debugfs_dir;
 	u64 count_transfer_polling;
@@ -147,9 +148,9 @@ struct bcm2835_spi {
 	unsigned int rx_dma_active;
 	struct dma_async_tx_descriptor *fill_tx_desc;
 	dma_addr_t fill_tx_addr;
-	struct dma_async_tx_descriptor *clear_rx_desc[BCM2835_SPI_NUM_CS];
+	struct dma_async_tx_descriptor **clear_rx_desc;
 	dma_addr_t clear_rx_addr;
-	u32 clear_rx_cs[BCM2835_SPI_NUM_CS] ____cacheline_aligned;
+	u32 *clear_rx_cs;
 };
 
 #if defined(CONFIG_DEBUG_FS)
@@ -875,14 +876,14 @@ static void bcm2835_dma_release(struct spi_controller *ctlr,
 	if (ctlr->dma_rx) {
 		dmaengine_terminate_sync(ctlr->dma_rx);
 
-		for (i = 0; i < BCM2835_SPI_NUM_CS; i++)
+		for (i = 0; i < ctlr->num_chipselect; i++)
 			if (bs->clear_rx_desc[i])
 				dmaengine_desc_free(bs->clear_rx_desc[i]);
 
 		if (bs->clear_rx_addr)
 			dma_unmap_single(ctlr->dma_rx->device->dev,
 					 bs->clear_rx_addr,
-					 sizeof(bs->clear_rx_cs),
+					 sizeof(u32) * ctlr->num_chipselect,
 					 DMA_TO_DEVICE);
 
 		dma_release_channel(ctlr->dma_rx);
@@ -978,7 +979,7 @@ static int bcm2835_dma_init(struct spi_controller *ctlr, struct device *dev,
 
 	bs->clear_rx_addr = dma_map_single(ctlr->dma_rx->device->dev,
 					   bs->clear_rx_cs,
-					   sizeof(bs->clear_rx_cs),
+					   sizeof(u32) * ctlr->num_chipselect,
 					   DMA_TO_DEVICE);
 	if (dma_mapping_error(ctlr->dma_rx->device->dev, bs->clear_rx_addr)) {
 		dev_err(dev, "cannot map clear_rx_cs - not using DMA mode\n");
@@ -987,7 +988,7 @@ static int bcm2835_dma_init(struct spi_controller *ctlr, struct device *dev,
 		goto err_release;
 	}
 
-	for (i = 0; i < BCM2835_SPI_NUM_CS; i++) {
+	for (i = 0; i < ctlr->num_chipselect; i++) {
 		bs->clear_rx_desc[i] = dmaengine_prep_dma_cyclic(ctlr->dma_rx,
 					   bs->clear_rx_addr + i * sizeof(u32),
 					   sizeof(u32), 0,
@@ -1209,6 +1210,12 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 	struct gpio_chip *chip;
 	u32 cs;
 
+	if (spi->chip_select >= ctlr->num_chipselect) {
+		dev_err(&spi->dev, "cs%d >= max %d\n", spi->chip_select,
+			ctlr->num_chipselect);
+		return -EINVAL;
+	}
+
 	/*
 	 * Precalculate SPI slave's CS register value for ->prepare_message():
 	 * The driver always uses software-controlled GPIO chip select, hence
@@ -1233,7 +1240,7 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 						    BCM2835_SPI_CS_CLEAR_RX;
 		dma_sync_single_for_device(ctlr->dma_rx->device->dev,
 					   bs->clear_rx_addr,
-					   sizeof(bs->clear_rx_cs),
+					   sizeof(u32) * ctlr->num_chipselect,
 					   DMA_TO_DEVICE);
 	}
 
@@ -1286,39 +1293,71 @@ static int bcm2835_spi_setup(struct spi_device *spi)
 	return 0;
 }
 
+
+#ifdef CONFIG_OF
+static int bcm2835_spi_get_num_chipselect(struct platform_device *pdev)
+{
+	return max_t(int, of_gpio_named_count(pdev->dev.of_node, "cs-gpios"),
+		BCM2835_SPI_NUM_CS);
+}
+#else
+static int bcm2835_spi_get_num_chipselect(struct platform_device *pdev)
+{
+	return BCM2835_SPI_NUM_CS;
+}
+#endif
+
+
 static int bcm2835_spi_probe(struct platform_device *pdev)
 {
+	struct device *dev = &pdev->dev;
 	struct spi_controller *ctlr;
 	struct bcm2835_spi *bs;
+	int num_chipselect;
 	int err;
 
-	ctlr = devm_spi_alloc_master(&pdev->dev, ALIGN(sizeof(*bs),
+	ctlr = devm_spi_alloc_master(dev, ALIGN(sizeof(*bs),
 						  dma_get_cache_alignment()));
 	if (!ctlr)
 		return -ENOMEM;
 
+	num_chipselect = bcm2835_spi_get_num_chipselect(pdev);
+
 	platform_set_drvdata(pdev, ctlr);
 
 	ctlr->use_gpio_descriptors = true;
 	ctlr->mode_bits = BCM2835_SPI_MODE_BITS;
 	ctlr->bits_per_word_mask = SPI_BPW_MASK(8);
-	ctlr->num_chipselect = BCM2835_SPI_NUM_CS;
+	ctlr->num_chipselect = num_chipselect;
 	ctlr->setup = bcm2835_spi_setup;
 	ctlr->transfer_one = bcm2835_spi_transfer_one;
 	ctlr->handle_err = bcm2835_spi_handle_err;
 	ctlr->prepare_message = bcm2835_spi_prepare_message;
-	ctlr->dev.of_node = pdev->dev.of_node;
+	ctlr->dev.of_node = dev->of_node;
 
 	bs = spi_controller_get_devdata(ctlr);
 	bs->ctlr = ctlr;
 
+	bs->prepare_cs = devm_kmalloc(dev, num_chipselect * sizeof(u32), GFP_KERNEL);
+	if (!bs->prepare_cs)
+		return -ENOMEM;
+
+	bs->clear_rx_desc = devm_kmalloc(dev, num_chipselect *
+		sizeof(struct dma_async_tx_descriptor *), GFP_KERNEL);
+	if (!bs->clear_rx_desc)
+		return -ENOMEM;
+
+	bs->clear_rx_cs = devm_kmalloc(dev, num_chipselect * sizeof(u32), GFP_DMA);
+	if (!bs->clear_rx_cs)
+		return -ENOMEM;
+
 	bs->regs = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(bs->regs))
 		return PTR_ERR(bs->regs);
 
-	bs->clk = devm_clk_get(&pdev->dev, NULL);
+	bs->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(bs->clk))
-		return dev_err_probe(&pdev->dev, PTR_ERR(bs->clk),
+		return dev_err_probe(dev, PTR_ERR(bs->clk),
 				     "could not get clk\n");
 
 	bs->irq = platform_get_irq(pdev, 0);
@@ -1327,7 +1366,7 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
 
 	clk_prepare_enable(bs->clk);
 
-	err = bcm2835_dma_init(ctlr, &pdev->dev, bs);
+	err = bcm2835_dma_init(ctlr, dev, bs);
 	if (err)
 		goto out_clk_disable;
 
@@ -1335,22 +1374,22 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
 	bcm2835_wr(bs, BCM2835_SPI_CS,
 		   BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
 
-	err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt,
+	err = devm_request_irq(dev, bs->irq, bcm2835_spi_interrupt,
 			       IRQF_SHARED,
-			       dev_name(&pdev->dev), bs);
+			       dev_name(dev), bs);
 	if (err) {
-		dev_err(&pdev->dev, "could not request IRQ: %d\n", err);
+		dev_err(dev, "could not request IRQ: %d\n", err);
 		goto out_dma_release;
 	}
 
 	err = spi_register_controller(ctlr);
 	if (err) {
-		dev_err(&pdev->dev, "could not register SPI controller: %d\n",
+		dev_err(dev, "could not register SPI controller: %d\n",
 			err);
 		goto out_dma_release;
 	}
 
-	bcm2835_debugfs_create(bs, dev_name(&pdev->dev));
+	bcm2835_debugfs_create(bs, dev_name(dev));
 
 	return 0;
 
-- 
2.30.2



From ck.hu at mediatek.com  Tue Apr 20 09:31:11 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Tue, 20 Apr 2021 16:31:11 +0800
Subject: [SPAM]Re: [SPAM][v2,PATCH 3/3] drm/mediatek: dpi: add bus
 format negotiation
In-Reply-To: <1618467298.4349.3.camel@mtksdccf07>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>
 <1618448968.29238.1.camel@mtksdaap41> <1618467298.4349.3.camel@mtksdccf07>
Message-ID: <1618907471.11505.2.camel@mtksdaap41>

Hi, Rex:

On Thu, 2021-04-15 at 14:14 +0800, Rex-BC Chen wrote:
> On Thu, 2021-04-15 at 09:09 +0800, CK Hu wrote:
> Hello CK,
> > Hi, Rex:
> > 
> > On Wed, 2021-04-14 at 21:35 +0800, Rex-BC Chen wrote:
> > > Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
> > > the possible output and input formats for the current mode and monitor,
> > > and use the negotiated formats in a basic atomic_check callback.
> > > 
> > > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dpi.c | 89 ++++++++++++++++++++++++++++--
> > >  1 file changed, 84 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > index 76431fe849b8..b4e9c6c8d706 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > @@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
> > >  	return 0;
> > >  }
> > >  
> > > +#define MAX_OUTPUT_SEL_FORMATS	2
> > > +
> > > +static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
> > > +					struct drm_bridge_state *bridge_state,
> > > +					struct drm_crtc_state *crtc_state,
> > > +					struct drm_connector_state *conn_state,
> > > +					unsigned int *num_output_fmts)
> > > +{
> > > +	struct drm_display_mode *mode = &crtc_state->mode;
> > > +	u32 *output_fmts;
> > > +	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > > +
> > > +	*num_output_fmts = 0;
> > > +
> > > +	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
> > > +			      GFP_KERNEL);
> > > +	if (!output_fmts)
> > > +		return NULL;
> > > +
> > > +	/* Default 8bit RGB fallback */
> > > +	if (dpi->conf->dual_edge) {
> > > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
> > > +		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
> > 
> > MT8183 does not support MEDIA_BUS_FMT_RGB888_1X24?
> > 
> > Regards,
> > CK
> > 
> Yes, MT8183 only support MEDIA_BUS_FMT_RGB888_1X24

I'm confused with this answer. dpi->conf->dual_edge is true only in
mt8183, but you say 'MT8183 only support MEDIA_BUS_FMT_RGB888_1X24',
your answer looks conflict with these code.

Regards,
CK

> 
> BRs,
> Rex-BC
> > > +		*num_output_fmts = 2;
> > > +	} else {
> > > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
> > > +		*num_output_fmts = 1;
> > > +	}
> > > +
> > > +	return output_fmts;
> > > +}
> > > +
> > > +#define MAX_INPUT_SEL_FORMATS	1
> > > +
> > > +static u32 *mtk_dpi_bridge_atomic_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)
> > > +{
> > > +	u32 *input_fmts;
> > > +
> > > +	*num_input_fmts = 0;
> > > +
> > > +	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> > > +			     GFP_KERNEL);
> > > +	if (!input_fmts)
> > > +		return NULL;
> > > +
> > > +	*num_input_fmts = 1;
> > > +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> > > +
> > > +	return input_fmts;
> > > +}
> > > +
> > > +static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
> > > +				       struct drm_bridge_state *bridge_state,
> > > +				       struct drm_crtc_state *crtc_state,
> > > +				       struct drm_connector_state *conn_state)
> > > +{
> > > +	struct mtk_dpi *dpi = bridge->driver_private;
> > > +	unsigned int out_bus_format;
> > > +
> > > +	out_bus_format = bridge_state->output_bus_cfg.format;
> > > +
> > > +	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
> > > +		bridge_state->input_bus_cfg.format,
> > > +		bridge_state->output_bus_cfg.format);
> > > +
> > > +	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
> > > +		 		true : false;
> > > +
> > > +	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > > +	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > > +	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > > +	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> > >  				 enum drm_bridge_attach_flags flags)
> > >  {
> > > @@ -574,6 +655,9 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> > >  	.mode_set = mtk_dpi_bridge_mode_set,
> > >  	.disable = mtk_dpi_bridge_disable,
> > >  	.enable = mtk_dpi_bridge_enable,
> > > +	.atomic_check = mtk_dpi_bridge_atomic_check,
> > > +	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
> > > +	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_get_input_bus_fmts,
> > >  };
> > >  
> > >  void mtk_dpi_start(struct device *dev)
> > > @@ -620,11 +704,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
> > >  	}
> > >  	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
> > >  
> > > -	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > > -	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > > -	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > > -	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > > -
> > >  	return 0;
> > >  
> > >  err_cleanup:
> > 
> > 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!wSbSRrRV87zBpi29W3qMJC0hPE5QwMj2oVUgPcq4538Poo-n0KFyM14woxJZbA$ 


From zhe.he at windriver.com  Tue Apr 20 09:38:35 2021
From: zhe.he at windriver.com (He Zhe)
Date: Tue, 20 Apr 2021 16:38:35 +0800
Subject: [PATCH 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210416094324.GA1962@redhat.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416075533.7720-2-zhe.he@windriver.com>
 <20210416094324.GA1962@redhat.com>
Message-ID: <1e55d2b5-4b6e-7fa2-4851-06cac7defb50@windriver.com>



On 4/16/21 5:43 PM, Oleg Nesterov wrote:
> On 04/16, He Zhe wrote:
>> --- a/arch/arm64/include/asm/syscall.h
>> +++ b/arch/arm64/include/asm/syscall.h
>> @@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct *task,
>>  static inline long syscall_get_return_value(struct task_struct *task,
>>  					    struct pt_regs *regs)
>>  {
>> -	return regs->regs[0];
>> +	long val = regs->regs[0];
>> +
>> +	if (is_compat_thread(task_thread_info(task)))
>> +		val = sign_extend64(val, 31);
>> +
>> +	return val;
>>  }
> I can't really review these arm-specific patches, but with this change both
> syscall_get_error() and is_syscall_success() can use syscall_get_return_value()
> to avoid the code duplication.

Thanks. I'll improve this if v2 is needed.

Regards,
Zhe

>
> Oleg.
>



From maz at kernel.org  Tue Apr 20 09:39:25 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 09:39:25 +0100
Subject: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains
In-Reply-To: <638a9996-c762-fa11-b740-6a41d4a83bcc@nvidia.com>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-2-maz@kernel.org>
 <316e8be4-fa70-75e8-8483-ae38036306e0@nvidia.com>
 <638a9996-c762-fa11-b740-6a41d4a83bcc@nvidia.com>
Message-ID: <87fszlqria.wl-maz@kernel.org>

Hi Jon,

On Mon, 19 Apr 2021 21:02:10 +0100,
Jon Hunter <jonathanh at nvidia.com> wrote:
> 
> 
> On 19/04/2021 20:19, Jon Hunter wrote:
> > Hi Marc,
> > 
> > On 30/03/2021 16:11, Marc Zyngier wrote:
> >> In anticipation of the removal of the msi_controller structure, convert
> >> the Tegra host controller driver to MSI domains.
> >>
> >> We end-up with the usual two domain structure, the top one being a
> >> generic PCI/MSI domain, the bottom one being Tegra-specific and handling
> >> the actual HW interrupt allocation.
> >>
> >> While at it, convert the normal interrupt handler to a chained handler,
> >> handle the controller's MSI IRQ edge triggered, support multiple MSIs
> >> per device and use the AFI_MSI_EN_VEC* registers to provide MSI masking.
> >>
> >> Acked-by: Bjorn Helgaas <bhelgaas at google.com>
> >> [treding at nvidia.com: fix, clean up and address TODOs from Marc's draft]
> >> Signed-off-by: Thierry Reding <treding at nvidia.com>
> >> Signed-off-by: Marc Zyngier <maz at kernel.org>
> > 
> > 
> > This change is breaking a suspend test that we are running on Tegra124
> > Jetson-TK1. The Tegra124 Jetson TK1 uses a PCI based ethernet device ...
> > 
> > $ lspci
> > 00:02.0 PCI bridge: NVIDIA Corporation TegraK1 PCIe x1 Bridge (rev a1)
> > 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
> > 
> > After resuming from suspend, networking is no longer working. The reason
> > why this breaks our suspend test is because that setup is using NFS for
> > the rootfs. I am looking into it, but if anyone has any thoughts please
> > let me know.
> 
> 
> So the following does appear to fix it ...
> 
> diff --git a/drivers/pci/controller/pci-tegra.c
> b/drivers/pci/controller/pci-tegra.c
> index eaba7b2fab4a..558f02e0693d 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -1802,13 +1802,17 @@ static void tegra_pcie_enable_msi(struct
> tegra_pcie *pcie)
>  {
>         const struct tegra_pcie_soc *soc = pcie->soc;
>         struct tegra_msi *msi = &pcie->msi;
> -       u32 reg;
> +       u32 i, reg;
> 
>         afi_writel(pcie, msi->phys >> soc->msi_base_shift,
> AFI_MSI_FPCI_BAR_ST);
>         afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);
>         /* this register is in 4K increments */
>         afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
> 
> +       /* enable all MSI vectors */
> +       for (i = 0; i < 8; i++)
> +               afi_writel(pcie, 0xffffffff, AFI_MSI_EN_VEC(i));
> +
>         /* and unmask the MSI interrupt */
>         reg = afi_readl(pcie, AFI_INTR_MASK);
>         reg |= AFI_INTR_MASK_MSI_MASK;
> @@ -1837,13 +1841,17 @@ static void tegra_pcie_msi_teardown(struct
> tegra_pcie *pcie)
> 
>  static int tegra_pcie_disable_msi(struct tegra_pcie *pcie)
>  {
> -       u32 value;
> +       u32 i, value;
> 
>         /* mask the MSI interrupt */
>         value = afi_readl(pcie, AFI_INTR_MASK);
>         value &= ~AFI_INTR_MASK_MSI_MASK;
>         afi_writel(pcie, value, AFI_INTR_MASK);
> 
> +       /* disable all MSI vectors */
> +       for (i = 0; i < 8; i++)
> +               afi_writel(pcie, 0, AFI_MSI_EN_VEC(i));
> +
>         return 0;
>  }
> 
> 
> Any reason why that code was removed?

Two reasons spring to mind: it obviously wasn't tested enough, and
part of the above code isn't quite right. You can't just blindly
enable all MSIs, irrespective of what has been actually enabled.

The following should hopefully cure it (compile tested only). Please
let me know.

	M.

diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
index eaba7b2fab4a..507b23d43ad1 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -1802,13 +1802,19 @@ static void tegra_pcie_enable_msi(struct tegra_pcie *pcie)
 {
 	const struct tegra_pcie_soc *soc = pcie->soc;
 	struct tegra_msi *msi = &pcie->msi;
-	u32 reg;
+	u32 reg, msi_state[INT_PCI_MSI_NR / 32];
+	int i;
 
 	afi_writel(pcie, msi->phys >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
 	afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);
 	/* this register is in 4K increments */
 	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
 
+	/* Restore the MSI allocation state */
+	bitmap_to_arr32(msi_state, msi->used, INT_PCI_MSI_NR);
+	for (i = 0; i < ARRAY_SIZE(msi_state); i++)
+		afi_writel(pcie, msi_state[i], AFI_MSI_EN_VEC(i));
+
 	/* and unmask the MSI interrupt */
 	reg = afi_readl(pcie, AFI_INTR_MASK);
 	reg |= AFI_INTR_MASK_MSI_MASK;

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


From David.Laight at ACULAB.COM  Tue Apr 20 09:39:51 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Tue, 20 Apr 2021 08:39:51 +0000
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAMuHMdXm1Zg=Wm-=tn5jUJwqVGUvCi5yDaW0PXWC2DEDYGcy5A@mail.gmail.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <CAMuHMdXm1Zg=Wm-=tn5jUJwqVGUvCi5yDaW0PXWC2DEDYGcy5A@mail.gmail.com>
Message-ID: <bb8805a33371468892a7271dbe321e1f@AcuMS.aculab.com>

From: Geert Uytterhoeven
> Sent: 20 April 2021 08:40
> 
> Hi Willy,
> 
> On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox <willy at infradead.org> wrote:
> > Replacement patch to fix compiler warning.
> >
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.  When the dma_addr_t was added,
> > it forced the alignment of the union to 8 bytes, which inserted a 4 byte
> > gap between 'flags' and the union.
> >
> > Fix this by storing the dma_addr_t in one or two adjacent unsigned longs.
> > This restores the alignment to that of an unsigned long, and also fixes a
> > potential problem where (on a big endian platform), the bit used to denote
> > PageTail could inadvertently get set, and a racing get_user_pages_fast()
> > could dereference a bogus compound_head().
> >
> > Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
> > Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> 
> Thanks for your patch!
> 
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -97,10 +97,10 @@ struct page {
> >                 };
> >                 struct {        /* page_pool used by netstack */
> >                         /**
> > -                        * @dma_addr: might require a 64-bit value even on
> > +                        * @dma_addr: might require a 64-bit value on
> >                          * 32-bit architectures.
> >                          */
> > -                       dma_addr_t dma_addr;
> > +                       unsigned long dma_addr[2];
> 
> So we get two 64-bit words on 64-bit platforms, while only one is
> needed?
> 
> Would
> 
>     unsigned long _dma_addr[sizeof(dma_addr_t) / sizeof(unsigned long)];
> 
> work?
> 
> Or will the compiler become too overzealous, and warn about the use
> of ...[1] below, even when unreachable?
> I wouldn't mind an #ifdef instead of an if () in the code below, though.

You could use [ARRAY_SIZE()-1] instead of [1].
Or, since IIRC it is the last member of that specific struct, define as:
		unsigned long dma_addr[];

...
> > -       return page->dma_addr;
> > +       dma_addr_t ret = page->dma_addr[0];
> > +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > +               ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> 
> We don't seem to have a handy macro for a 32-bit left shift yet...
> 
> But you can also avoid the warning using
> 
>     ret |= (u64)page->dma_addr[1] << 32;

Or:
	ret |= page->dma_addr[1] + 0ull << 32;

Which relies in integer promotion rather than a cast.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From daniel at ffwll.ch  Tue Apr 20 09:41:38 2021
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 20 Apr 2021 10:41:38 +0200
Subject: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly
In-Reply-To: <df4acc12-27da-3a81-6e2b-eee197107341@samsung.com>
References: <20210413094904.3736372-1-daniel.vetter@ffwll.ch>
 <CGME20210413094922epcas1p47e75ce008a78971af7a923aadc0b9d3b@epcas1p4.samsung.com>
 <20210413094904.3736372-3-daniel.vetter@ffwll.ch>
 <df4acc12-27da-3a81-6e2b-eee197107341@samsung.com>
Message-ID: <YH6TwgrVIUlQwH2g@phenom.ffwll.local>

On Tue, Apr 20, 2021 at 03:31:27PM +0900, Inki Dae wrote:
> 
> 
> 21. 4. 13. ?? 6:48? Daniel Vetter ?(?) ? ?:
> > Since
> > 
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
> > Date:   Fri Jan 4 09:56:10 2019 +0100
> > 
> >     drm: Auto-set allow_fb_modifiers when given modifiers at plane init
> > 
> > this is done automatically as part of plane init, if drivers set the
> > modifier list correctly. Which is the case here.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> 
> Acked-by: Inki Dae <inki.dae at samsung.com>

Thanks for taking a look, pushed to drm-misc-next.
-Daniel

> 
> Thanks,
> Inki Dae
> 
> > Cc: Inki Dae <inki.dae at samsung.com>
> > Cc: Joonyoung Shim <jy0922.shim at samsung.com>
> > Cc: Seung-Woo Kim <sw0312.kim at samsung.com>
> > Cc: Kyungmin Park <kyungmin.park at samsung.com>
> > Cc: Krzysztof Kozlowski <krzk at kernel.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-samsung-soc at vger.kernel.org
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > index 64370b634cca..79fa3649185c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> > @@ -177,7 +177,5 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
> >  	dev->mode_config.funcs = &exynos_drm_mode_config_funcs;
> >  	dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
> >  
> > -	dev->mode_config.allow_fb_modifiers = true;
> > -
> >  	dev->mode_config.normalize_zpos = true;
> >  }
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From zhe.he at windriver.com  Tue Apr 20 09:42:53 2021
From: zhe.he at windriver.com (He Zhe)
Date: Tue, 20 Apr 2021 16:42:53 +0800
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210416123322.GA23184@arm.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
Message-ID: <9b5b340b-66ad-41c9-865e-32724e33a5b8@windriver.com>



On 4/16/21 8:33 PM, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
>> The general version of is_syscall_success does not handle 32-bit
>> compatible case, which would cause 32-bit negative return code to be
>> recoganized as a positive number later and seen as a "success".
>>
>> Since is_compat_thread is defined in compat.h, implementing
>> is_syscall_success in ptrace.h would introduce build failure due to
>> recursive inclusion of some basic headers like mutex.h. We put the
>> implementation to ptrace.c
>>
>> Signed-off-by: He Zhe <zhe.he at windriver.com>
>> ---
>>  arch/arm64/include/asm/ptrace.h |  3 +++
>>  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
>> index e58bca832dff..3c415e9e5d85 100644
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
>>  	regs->regs[0] = rc;
>>  }
>>  
>> +extern inline int is_syscall_success(struct pt_regs *regs);
>> +#define is_syscall_success(regs) is_syscall_success(regs)
>> +
>>  /**
>>   * regs_get_kernel_argument() - get Nth function argument in kernel
>>   * @regs:	pt_regs of that context
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index 170f42fd6101..3266201f8c60 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
>>  	else
>>  		return valid_native_regs(regs);
>>  }
>> +
>> +inline int is_syscall_success(struct pt_regs *regs)
>> +{
>> +	unsigned long val = regs->regs[0];
>> +
>> +	if (is_compat_thread(task_thread_info(current)))
>> +		val = sign_extend64(val, 31);
>> +
>> +	return !IS_ERR_VALUE(val);
>> +}
> It's better to use compat_user_mode(regs) here instead of
> is_compat_thread(). It saves us from worrying whether regs are for the
> current context.

Thanks. I'll use this for v2.

>
> I think we should change regs_return_value() instead. This function
> seems to be called from several other places and it has the same
> potential problems if called on compat pt_regs.

IMHO, now that we have had specific function, syscall_get_return_value, to get
syscall return code, we might as well use it. regs_return_value may be left for
where we want internal return code. I found such places below and haven't found
other places that syscall sign extension is concerned about.

kernel/test_kprobes.c
kernel/trace/trace_kprobe.c
samples/kprobes/kretprobe_example.c


Regards,
Zhe

>



From gregkh at linuxfoundation.org  Tue Apr 20 09:46:52 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 20 Apr 2021 10:46:52 +0200
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <20210420081153.17020-3-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-3-nava.manne@xilinx.com>
Message-ID: <YH6U/L4SEtJajusW@kroah.com>

On Tue, Apr 20, 2021 at 01:41:50PM +0530, Nava kishore Manne wrote:
> This patch adds zynq afi config driver. This is useful for
> the configuration of the PS-PL interface on zynq platform.

What is "PS-PL"?  Can you describe it better please?

> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  drivers/misc/Kconfig    | 11 ++++++
>  drivers/misc/Makefile   |  1 +
>  drivers/misc/zynq-afi.c | 81 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 93 insertions(+)
>  create mode 100644 drivers/misc/zynq-afi.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index f532c59bb59b..877b43b3377d 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -445,6 +445,17 @@ config HISI_HIKEY_USB
>  	  switching between the dual-role USB-C port and the USB-A host ports
>  	  using only one USB controller.
>  
> +config ZYNQ_AFI
> +	tristate "Xilinx ZYNQ AFI support"
> +	help
> +	  Zynq AFI driver support for writing to the AFI registers
> +	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
> +	  the PS to the programmable logic (PL) through the AXI port.
> +	  This AXI port helps to establish the data path between the
> +	  PS and PL.In-order to establish the proper communication path
> +	  between PS and PL, the AXI port data path should be configured
> +	  with the proper Bus-width values
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 99b6f15a3c70..e9b03843100f 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI)		+= habanalabs/
>  obj-$(CONFIG_UACCE)		+= uacce/
>  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
>  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> +obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> diff --git a/drivers/misc/zynq-afi.c b/drivers/misc/zynq-afi.c
> new file mode 100644
> index 000000000000..04317d1bdb98
> --- /dev/null
> +++ b/drivers/misc/zynq-afi.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx ZYNQ AFI driver.
> + * Copyright (c) 2018-2021 Xilinx Inc.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +/* Registers and special values for doing register-based operations */
> +#define AFI_RDCHAN_CTRL_OFFSET	0x00
> +#define AFI_WRCHAN_CTRL_OFFSET	0x14
> +
> +#define AFI_BUSWIDTH_MASK	0x01
> +
> +/**
> + * struct afi_fpga - AFI register description
> + * @membase:	pointer to register struct
> + * @afi_width:	AFI bus width to be written
> + */
> +struct zynq_afi_fpga {
> +	void __iomem	*membase;
> +	u32		afi_width;
> +};
> +
> +static int zynq_afi_fpga_probe(struct platform_device *pdev)
> +{
> +	struct zynq_afi_fpga *afi_fpga;
> +	struct resource *res;
> +	u32 reg_val;
> +	u32 val;
> +
> +	afi_fpga = devm_kzalloc(&pdev->dev, sizeof(*afi_fpga), GFP_KERNEL);
> +	if (!afi_fpga)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	afi_fpga->membase = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(afi_fpga->membase))
> +		return PTR_ERR(afi_fpga->membase);
> +
> +	val = device_property_read_u32(&pdev->dev, "xlnx,afi-width",
> +				       &afi_fpga->afi_width);
> +	if (val) {
> +		dev_err(&pdev->dev, "failed to get the afi bus width\n");
> +		return -EINVAL;
> +	}
> +
> +	reg_val = readl(afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> +	reg_val &= ~AFI_BUSWIDTH_MASK;
> +	writel(reg_val | afi_fpga->afi_width,
> +	       afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> +	reg_val = readl(afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> +	reg_val &= ~AFI_BUSWIDTH_MASK;
> +	writel(reg_val | afi_fpga->afi_width,
> +	       afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> +
> +	return 0;
> +}

I do not understand, why is this driver needed at all?  Why can't you do
the above from userspace?

All this does is write some values to the hardware at probe time, who
needs this?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Tue Apr 20 09:47:58 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 20 Apr 2021 10:47:58 +0200
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <20210420081153.17020-6-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com>
Message-ID: <YH6VPt6qfxdFhFEB@kroah.com>

On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> This patch adds zynqmp afi config driver.This is useful for
> the configuration of the PS-PL interface on Zynq US+ MPSoC
> platform.

Again, please spell out what those terms mean, as I have no idea :(

> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  drivers/misc/Kconfig      | 11 ++++++
>  drivers/misc/Makefile     |  1 +
>  drivers/misc/zynqmp-afi.c | 83 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 drivers/misc/zynqmp-afi.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 877b43b3377d..d1ea1eeb3ac1 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -456,6 +456,17 @@ config ZYNQ_AFI
>  	  between PS and PL, the AXI port data path should be configured
>  	  with the proper Bus-width values
>  
> +config ZYNQMP_AFI
> +        tristate "Xilinx ZYNQMP AFI support"
> +        help
> +	  ZynqMP AFI driver support for writing to the AFI registers for
> +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> +	  PS to the programmable logic (PL) through the AXI port. This AXI
> +	  port helps to establish the data path between the PS and PL.
> +	  In-order to establish the proper communication path between
> +	  PS and PL, the AXI port data path should be configured with
> +	  the proper Bus-width values

Please use tabs properly, you mix them above, checkpatch should have
caught that.

thanks,

greg k-h


From gregkh at linuxfoundation.org  Tue Apr 20 09:51:00 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 20 Apr 2021 10:51:00 +0200
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <20210420081153.17020-6-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com>
Message-ID: <YH6V9Im3L/gJJ/CP@kroah.com>

On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> This patch adds zynqmp afi config driver.This is useful for
> the configuration of the PS-PL interface on Zynq US+ MPSoC
> platform.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  drivers/misc/Kconfig      | 11 ++++++
>  drivers/misc/Makefile     |  1 +
>  drivers/misc/zynqmp-afi.c | 83 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 drivers/misc/zynqmp-afi.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 877b43b3377d..d1ea1eeb3ac1 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -456,6 +456,17 @@ config ZYNQ_AFI
>  	  between PS and PL, the AXI port data path should be configured
>  	  with the proper Bus-width values
>  
> +config ZYNQMP_AFI
> +        tristate "Xilinx ZYNQMP AFI support"
> +        help
> +	  ZynqMP AFI driver support for writing to the AFI registers for
> +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> +	  PS to the programmable logic (PL) through the AXI port. This AXI
> +	  port helps to establish the data path between the PS and PL.
> +	  In-order to establish the proper communication path between
> +	  PS and PL, the AXI port data path should be configured with
> +	  the proper Bus-width values
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index e9b03843100f..54bd0edc511e 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -57,3 +57,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
>  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
>  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
>  obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> +obj-$(CONFIG_ZYNQMP_AFI)	+= zynqmp-afi.o
> diff --git a/drivers/misc/zynqmp-afi.c b/drivers/misc/zynqmp-afi.c
> new file mode 100644
> index 000000000000..a318652576d2
> --- /dev/null
> +++ b/drivers/misc/zynqmp-afi.c
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Xilinx FPGA AFI bridge.
> + * Copyright (c) 2018-2021 Xilinx Inc.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/firmware/xlnx-zynqmp.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +/**
> + * struct zynqmp_afi_fpga - AFI register description
> + * @value: value to be written to the register
> + * @regid: Register id for the register to be written
> + */
> +struct zynqmp_afi_fpga {
> +	u32 value;
> +	u32 regid;
> +};
> +
> +static int zynqmp_afi_fpga_probe(struct platform_device *pdev)
> +{
> +	struct zynqmp_afi_fpga *zynqmp_afi_fpga;
> +	struct device_node *np = pdev->dev.of_node;
> +	int i, entries, ret;
> +	u32 reg, val;
> +
> +	zynqmp_afi_fpga = devm_kzalloc(&pdev->dev,
> +				       sizeof(*zynqmp_afi_fpga), GFP_KERNEL);
> +	if (!zynqmp_afi_fpga)
> +		return -ENOMEM;
> +	platform_set_drvdata(pdev, zynqmp_afi_fpga);
> +
> +	entries = of_property_count_u32_elems(np, "config-afi");
> +	if (!entries || (entries % 2)) {
> +		dev_err(&pdev->dev, "Invalid number of registers\n");
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < entries / 2; i++) {
> +		ret = of_property_read_u32_index(np, "config-afi", i * 2, &reg);
> +		if (ret) {
> +			dev_err(&pdev->dev, "failed to read register\n");
> +			return -EINVAL;
> +		}
> +		ret = of_property_read_u32_index(np, "config-afi", i * 2 + 1,
> +						 &val);
> +		if (ret) {
> +			dev_err(&pdev->dev, "failed to read value\n");
> +			return -EINVAL;
> +		}
> +		ret = zynqmp_pm_afi(reg, val);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "AFI register write error %d\n",
> +				ret);
> +			return ret;
> +		}
> +	}
> +	return 0;
> +}

Again, why does this have to be in the kernel?  All it does is make a
single call to the hardware based on some values read from the device
tree.  Can't you do this from userspace?

thanks,

greg k-h


From zhe.he at windriver.com  Tue Apr 20 09:54:22 2021
From: zhe.he at windriver.com (He Zhe)
Date: Tue, 20 Apr 2021 16:54:22 +0800
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210419121932.GA30004@willie-the-truck>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com> <20210416133431.GA2303@C02TD0UTHF1T.local>
 <20210419121932.GA30004@willie-the-truck>
Message-ID: <1e13b428-1dbd-55ff-ed2f-5ac7f6562689@windriver.com>



On 4/19/21 8:19 PM, Will Deacon wrote:
> On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
>> On Fri, Apr 16, 2021 at 01:33:22PM +0100, Catalin Marinas wrote:
>>> On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
>>>> The general version of is_syscall_success does not handle 32-bit
>>>> compatible case, which would cause 32-bit negative return code to be
>>>> recoganized as a positive number later and seen as a "success".
>>>>
>>>> Since is_compat_thread is defined in compat.h, implementing
>>>> is_syscall_success in ptrace.h would introduce build failure due to
>>>> recursive inclusion of some basic headers like mutex.h. We put the
>>>> implementation to ptrace.c
>>>>
>>>> Signed-off-by: He Zhe <zhe.he at windriver.com>
>>>> ---
>>>>  arch/arm64/include/asm/ptrace.h |  3 +++
>>>>  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
>>>>  2 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
>>>> index e58bca832dff..3c415e9e5d85 100644
>>>> --- a/arch/arm64/include/asm/ptrace.h
>>>> +++ b/arch/arm64/include/asm/ptrace.h
>>>> @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
>>>>  	regs->regs[0] = rc;
>>>>  }
>>>>  
>>>> +extern inline int is_syscall_success(struct pt_regs *regs);
>>>> +#define is_syscall_success(regs) is_syscall_success(regs)
>>>> +
>>>>  /**
>>>>   * regs_get_kernel_argument() - get Nth function argument in kernel
>>>>   * @regs:	pt_regs of that context
>>>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>>>> index 170f42fd6101..3266201f8c60 100644
>>>> --- a/arch/arm64/kernel/ptrace.c
>>>> +++ b/arch/arm64/kernel/ptrace.c
>>>> @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
>>>>  	else
>>>>  		return valid_native_regs(regs);
>>>>  }
>>>> +
>>>> +inline int is_syscall_success(struct pt_regs *regs)
>>>> +{
>>>> +	unsigned long val = regs->regs[0];
>>>> +
>>>> +	if (is_compat_thread(task_thread_info(current)))
>>>> +		val = sign_extend64(val, 31);
>>>> +
>>>> +	return !IS_ERR_VALUE(val);
>>>> +}
>>> It's better to use compat_user_mode(regs) here instead of
>>> is_compat_thread(). It saves us from worrying whether regs are for the
>>> current context.
>>>
>>> I think we should change regs_return_value() instead. This function
>>> seems to be called from several other places and it has the same
>>> potential problems if called on compat pt_regs.
>> I think this is a problem we created for ourselves back in commit:
>>
>>   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
>>
>> AFAICT, the perf regs samples are the only place this matters, since for
>> ptrace the compat regs are implicitly truncated to compat_ulong_t, and
>> audit expects the non-truncated return value. Other architectures don't
>> truncate here, so I think we're setting ourselves up for a game of
>> whack-a-mole to truncate and extend wherever we need to.
>>
>> Given that, I suspect it'd be better to do something like the below.
>>
>> Will, thoughts?
> I think perf is one example, but this is also visible to userspace via the
> native ptrace interface and I distinctly remember needing this for some
> versions of arm64 strace to work correctly when tracing compat tasks.
>
> So I do think that clearing the upper bits on the return path is the right
> approach, but it sounds like we need some more work to handle syscall(-1)
> and audit (what exactly is the problem here after these patches have been
> applied?)

IIUC, IS_ERR_VALUE could handle -1, did I miss something? Thanks.

Regards,
Zhe

>
> Will



From hsinyi at chromium.org  Tue Apr 20 10:05:06 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 20 Apr 2021 17:05:06 +0800
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
In-Reply-To: <20210409045314.3420733-1-hsinyi@chromium.org>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
Message-ID: <CAJMQK-gFk8WV0W2TTP7=OTsBqgWmy_eKSd42Xa5dJzvUFDTAXQ@mail.gmail.com>

On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning. So set panel orientation in dsi before drm_dev_register() is
> called.
>
> [    4.480976] ------------[ cut here ]------------
> [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> <snip>
> [    4.609772] Call trace:
> [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> [    4.616466]  drm_mode_object_add+0x20/0x2c
> [    4.620552]  drm_property_create+0xdc/0x174
> [    4.624723]  drm_property_create_enum+0x34/0x98
> [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [    4.634716]  boe_panel_get_modes+0x88/0xd8
> [    4.638802]  drm_panel_get_modes+0x2c/0x48
> [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [    4.662699]  drm_ioctl_kernel+0xac/0x128
> [    4.666611]  drm_ioctl+0x268/0x410
> [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.678436]  el0_svc_common+0xf4/0x1c0
> [    4.682174]  do_el0_svc_compat+0x28/0x3c
> [    4.686088]  el0_svc_compat+0x10/0x1c
> [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [    4.694171]  el0_sync_compat+0x178/0x180
> [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [    4.702721] ------------[ cut here ]------------
> [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> <snip>
> [    4.833830] Call trace:
> [    4.836266]  drm_object_attach_property+0x48/0xb8
> [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [    4.846432]  boe_panel_get_modes+0x88/0xd8
> [    4.850516]  drm_panel_get_modes+0x2c/0x48
> [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [    4.874410]  drm_ioctl_kernel+0xac/0x128
> [    4.878320]  drm_ioctl+0x268/0x410
> [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.890142]  el0_svc_common+0xf4/0x1c0
> [    4.893879]  do_el0_svc_compat+0x28/0x3c
> [    4.897791]  el0_svc_compat+0x10/0x1c
> [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [    4.905873]  el0_sync_compat+0x178/0x180
> [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

ping on the thread, thanks.

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ae403c67cbd9..45a702ee09f3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -205,6 +205,7 @@ struct mtk_dsi {
>         u32 irq_data;
>         wait_queue_head_t irq_wait_queue;
>         const struct mtk_dsi_driver_data *driver_data;
> +       enum drm_panel_orientation orientation;
>  };
>
>  static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> @@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>         }
>         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>
> +       drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
> +
>         return 0;
>
>  err_cleanup_encoder:
> @@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>                         ret = PTR_ERR(dsi->next_bridge);
>                         goto err_unregister_host;
>                 }
> +
> +               ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
> +               if (ret) {
> +                       dev_err(dev, "failed to get panel orientation %d\n", ret);
> +                       return ret;
> +               }
>         }
>
>         dsi->driver_data = of_device_get_match_data(dev);
> --
> 2.31.1.295.g9ea45b61b8-goog
>


From rppt at kernel.org  Tue Apr 20 10:09:21 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 12:09:21 +0300
Subject: [PATCH v1 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Message-ID: <20210420090925.7457-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1. 

The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.

With this the core mm will be able to cope with the fact that it cannot use
NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
will be treated correctly even without the need for pfn_valid_within.

The patches are only boot tested on qemu-system-aarch64 so I'd really
appreciate memory stress tests on real hardware.

If this actually works we'll be one step closer to drop custom pfn_valid()
on arm64 altogether.

Changes since RFC
Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt at kernel.org

* Add comment about the semantics of pfn_valid() as Anshuman suggested
* Extend comments about MEMBLOCK_NOMAP, per Anshuman
* Use pfn_is_map_memory() name for the exported wrapper for
  memblock_is_map_memory(). It is still local to arch/arm64 in the end
  because of header dependency issues.

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 10 ++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 54 insertions(+), 13 deletions(-)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.28.0



From benjamin.gaignard at collabora.com  Tue Apr 20 10:10:07 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 11:10:07 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
 <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
 <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>
Message-ID: <36008691-d075-203d-0cac-2a012773ea34@collabora.com>


Le 16/04/2021 ? 17:14, Lucas Stach a ?crit?:
> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>> Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
>>> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>>>> In order to be able to share the control hardware block between
>>>> VPUs use a syscon instead a ioremap it in the driver.
>>>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>>>> phandle is not found look at 'ctrl' reg-name.
>>>> With the method it becomes useless to provide a list of register
>>>> names so remove it.
>>> Sorry for putting a spoke in the wheel after many iterations of the
>>> series.
>>>
>>> We just discussed a way forward on how to handle the clocks and resets
>>> provided by the blkctl block on i.MX8MM and later and it seems there is
>>> a consensus on trying to provide virtual power domains from a blkctl
>>> driver, controlling clocks and resets for the devices in the power
>>> domain. I would like to avoid introducing yet another way of handling
>>> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
>>> what we are planning to do on the later chip generations.
>>>
>>> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
>>> virtual power domain thing a shot.
>> That could replace the 3 first patches and Dt patche of this series
>> but that will not impact the hevc part, so I wonder if pure hevc patches
>> could be merged anyway ?
>> They are reviewed and don't depend of how the ctrl block is managed.
> I'm not really in a position to give any informed opinion about that
> hvec patches, as I only skimmed them, but I don't see any reason to
> delay patches 04-11 from this series until the i.MX8M platform issues
> are sorted. AFAICS those things are totally orthogonal.

Hi Hans,
What do you think about this proposal to split this series ?
Get hevc part merged could allow me to continue to add features
like scaling lists, compressed reference buffers and 10-bit supports.

Regards,
Benjamin

>
> Regards,
> Lucas
>
>>> Regards,
>>> Lucas
>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
>>>> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
>>>> ---
>>>> version 9:
>>>>  ??- Corrections in commit message
>>>>
>>>> version 7:
>>>>  ??- Add Philipp reviewed-by tag.
>>>>  ??- Change syscon phandle name.
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> version 5:
>>>>  ??- use syscon instead of VPU reset driver.
>>>>  ??- if DT doesn't provide syscon keep backward compatibilty by using
>>>>  ????'ctrl' reg-name.
>>>>
>>>>  ??drivers/staging/media/hantro/hantro.h       |  5 +-
>>>>  ??drivers/staging/media/hantro/imx8m_vpu_hw.c | 52 ++++++++++++---------
>>>>  ??2 files changed, 34 insertions(+), 23 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
>>>> index 6c1b888abe75..37b9ce04bd4e 100644
>>>> --- a/drivers/staging/media/hantro/hantro.h
>>>> +++ b/drivers/staging/media/hantro/hantro.h
>>>> @@ -13,6 +13,7 @@
>>>>  ??#define HANTRO_H_
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??#include <linux/platform_device.h>
>>>> +#include <linux/regmap.h>
>>>>  ??#include <linux/videodev2.h>
>>>>  ??#include <linux/wait.h>
>>>>  ??#include <linux/clk.h>
>>>> @@ -167,7 +168,7 @@ hantro_vdev_to_func(struct video_device *vdev)
>>>>  ???* @reg_bases:		Mapped addresses of VPU registers.
>>>>  ???* @enc_base:		Mapped address of VPU encoder register for convenience.
>>>>  ???* @dec_base:		Mapped address of VPU decoder register for convenience.
>>>> - * @ctrl_base:		Mapped address of VPU control block.
>>>> + * @ctrl_base:		Regmap of VPU control block.
>>>>  ???* @vpu_mutex:		Mutex to synchronize V4L2 calls.
>>>>  ???* @irqlock:		Spinlock to synchronize access to data structures
>>>>  ???*			shared with interrupt handlers.
>>>> @@ -186,7 +187,7 @@ struct hantro_dev {
>>>>  ??	void __iomem **reg_bases;
>>>>  ??	void __iomem *enc_base;
>>>>  ??	void __iomem *dec_base;
>>>> -	void __iomem *ctrl_base;
>>>> +	struct regmap *ctrl_base;
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	struct mutex vpu_mutex;	/* video_device lock */
>>>>  ??	spinlock_t irqlock;
>>>> diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
>>>> index c222de075ef4..8d0c3425234b 100644
>>>> --- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
>>>> +++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
>>>> @@ -7,6 +7,7 @@
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??#include <linux/clk.h>
>>>>  ??#include <linux/delay.h>
>>>> +#include <linux/mfd/syscon.h>
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??#include "hantro.h"
>>>>  ??#include "hantro_jpeg.h"
>>>> @@ -24,30 +25,28 @@
>>>>  ??#define CTRL_G1_PP_FUSE		0x0c
>>>>  ??#define CTRL_G2_DEC_FUSE	0x10
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> +static const struct regmap_config ctrl_regmap_ctrl = {
>>>> +	.reg_bits = 32,
>>>> +	.val_bits = 32,
>>>> +	.reg_stride = 0x14,
>>>> +};
>>>> +
>>>>  ??static void imx8m_soft_reset(struct hantro_dev *vpu, u32 reset_bits)
>>>>  ??{
>>>> -	u32 val;
>>>> -
>>>>  ??	/* Assert */
>>>> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
>>>> -	val &= ~reset_bits;
>>>> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
>>>> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET, reset_bits, 0);
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	udelay(2);
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	/* Release */
>>>> -	val = readl(vpu->ctrl_base + CTRL_SOFT_RESET);
>>>> -	val |= reset_bits;
>>>> -	writel(val, vpu->ctrl_base + CTRL_SOFT_RESET);
>>>> +	regmap_update_bits(vpu->ctrl_base, CTRL_SOFT_RESET,
>>>> +			   reset_bits, reset_bits);
>>>>  ??}
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??static void imx8m_clk_enable(struct hantro_dev *vpu, u32 clock_bits)
>>>>  ??{
>>>> -	u32 val;
>>>> -
>>>> -	val = readl(vpu->ctrl_base + CTRL_CLOCK_ENABLE);
>>>> -	val |= clock_bits;
>>>> -	writel(val, vpu->ctrl_base + CTRL_CLOCK_ENABLE);
>>>> +	regmap_update_bits(vpu->ctrl_base, CTRL_CLOCK_ENABLE,
>>>> +			   clock_bits, clock_bits);
>>>>  ??}
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??static int imx8mq_runtime_resume(struct hantro_dev *vpu)
>>>> @@ -64,9 +63,9 @@ static int imx8mq_runtime_resume(struct hantro_dev *vpu)
>>>>  ??	imx8m_clk_enable(vpu, CLOCK_G1 | CLOCK_G2);
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	/* Set values of the fuse registers */
>>>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_DEC_FUSE);
>>>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G1_PP_FUSE);
>>>> -	writel(0xffffffff, vpu->ctrl_base + CTRL_G2_DEC_FUSE);
>>>> +	regmap_write(vpu->ctrl_base, CTRL_G1_DEC_FUSE, 0xffffffff);
>>>> +	regmap_write(vpu->ctrl_base, CTRL_G1_PP_FUSE, 0xffffffff);
>>>> +	regmap_write(vpu->ctrl_base, CTRL_G2_DEC_FUSE, 0xffffffff);
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	clk_bulk_disable_unprepare(vpu->variant->num_clocks, vpu->clocks);
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> @@ -150,8 +149,22 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
>>>>  ??{
>>>> -	vpu->dec_base = vpu->reg_bases[0];
>>>> -	vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
>>>> +	struct device_node *np = vpu->dev->of_node;
>>>> +
>>>> +	vpu->ctrl_base = syscon_regmap_lookup_by_phandle(np, "nxp,imx8m-vpu-ctrl");
>>>> +	if (IS_ERR(vpu->ctrl_base)) {
>>>> +		struct resource *res;
>>>> +		void __iomem *ctrl;
>>>> +
>>>> +		res = platform_get_resource_byname(vpu->pdev, IORESOURCE_MEM, "ctrl");
>>>> +		ctrl = devm_ioremap_resource(vpu->dev, res);
>>>> +		if (IS_ERR(ctrl))
>>>> +			return PTR_ERR(ctrl);
>>>> +
>>>> +		vpu->ctrl_base = devm_regmap_init_mmio(vpu->dev, ctrl, &ctrl_regmap_ctrl);
>>>> +		if (IS_ERR(vpu->ctrl_base))
>>>> +			return PTR_ERR(vpu->ctrl_base);
>>>> +	}
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??	return 0;
>>>>  ??}
>>>> @@ -198,7 +211,6 @@ static const struct hantro_irq imx8mq_irqs[] = {
>>>>  ??};
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
>>>> -static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
>>>>    
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  ??const struct hantro_variant imx8mq_vpu_variant = {
>>>>  ??	.dec_fmts = imx8m_vpu_dec_fmts,
>>>> @@ -215,6 +227,4 @@ const struct hantro_variant imx8mq_vpu_variant = {
>>>>  ??	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
>>>>  ??	.clk_names = imx8mq_clk_names,
>>>>  ??	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
>>>> -	.reg_names = imx8mq_reg_names,
>>>> -	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
>>>>  ??};
>>>
>
>


From lorenzo.pieralisi at arm.com  Tue Apr 20 10:12:43 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 20 Apr 2021 10:12:43 +0100
Subject: [PATCH v10 0/7] PCI: mediatek: Add new generation controller
 support
In-Reply-To: <20210420061723.989-1-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
Message-ID: <161890993967.14131.8304781872037527456.b4-ty@arm.com>

On Tue, 20 Apr 2021 14:17:16 +0800, Jianjun Wang wrote:
> These series patches add pcie-mediatek-gen3.c and dt-bindings file to
> support new generation PCIe controller.
> 
> Changes in v10:
> 1. Fix the subject line format in commit message;
> 2. Use EXPORT_SYMBOL_GPL() to export pci_pio_to_address().
> 
> [...]

Applied to pci/mediatek, thanks!

[1/7] dt-bindings: PCI: mediatek-gen3: Add YAML schema
      https://git.kernel.org/lpieralisi/pci/c/07ca255e3d
[2/7] PCI: Export pci_pio_to_address() for module use
      https://git.kernel.org/lpieralisi/pci/c/9cc742078c
[3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
      https://git.kernel.org/lpieralisi/pci/c/441903d9e8
[4/7] PCI: mediatek-gen3: Add INTx support
      https://git.kernel.org/lpieralisi/pci/c/c58148e657
[5/7] PCI: mediatek-gen3: Add MSI support
      https://git.kernel.org/lpieralisi/pci/c/e0282a61f4
[6/7] PCI: mediatek-gen3: Add system PM support
      https://git.kernel.org/lpieralisi/pci/c/a7583c42f4
[7/7] MAINTAINERS: Add Jianjun Wang as MediaTek PCI co-maintainer
      https://git.kernel.org/lpieralisi/pci/c/fcf132f196

Thanks,
Lorenzo


From rppt at kernel.org  Tue Apr 20 10:09:22 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 12:09:22 +0300
Subject: [PATCH v1 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <20210420090925.7457-1-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
Message-ID: <20210420090925.7457-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.

The most "generic" version of pfn_valid() used by the configurations with
SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
suitable place for documentation about semantics of pfn_valid().

Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/mmzone.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 47946cec7584..961f0eeefb62 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
 #endif
 
 #ifndef CONFIG_HAVE_ARCH_PFN_VALID
+/**
+ * pfn_valid - check if there is a valid memory map entry for a PFN
+ * @pfn: the page frame number to check
+ *
+ * Check if there is a valid memory map entry aka struct page for the @pfn.
+ * Note, that availability of the memory map entry does not imply that
+ * there is actual usable memory at that @pfn. The struct page may
+ * represent a hole or an unusable page frame.
+ *
+ * Return: 1 for PFNs that have memory map entries and 0 otherwise
+ */
 static inline int pfn_valid(unsigned long pfn)
 {
 	struct mem_section *ms;
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 10:09:23 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 12:09:23 +0300
Subject: [PATCH v1 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210420090925.7457-1-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
Message-ID: <20210420090925.7457-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.

The struct pages for MEMBLOCK_NOMAP regions are kept with the default
values set by the memory map initialization which makes it necessary to
have a special treatment for such pages in pfn_valid() and
pfn_valid_within().

Split out initialization of the reserved pages to a function with a
meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
reserved regions and mark struct pages for the NOMAP regions as
PageReserved.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/memblock.h |  4 +++-
 mm/memblock.c            | 28 ++++++++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5984fff3f175..634c1a578db8 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
  * @MEMBLOCK_NONE: no special request
  * @MEMBLOCK_HOTPLUG: hotpluggable region
  * @MEMBLOCK_MIRROR: mirrored region
- * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
+ * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
+ * reserved in the memory map; refer to memblock_mark_nomap() description
+ * for futher details
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..3abf2c3fea7f 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
  * @base: the base phys addr of the region
  * @size: the size of the region
  *
+ * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
+ * direct mapping of the physical memory. These regions will still be
+ * covered by the memory map. The struct page representing NOMAP memory
+ * frames in the memory map will be PageReserved()
+ *
  * Return: 0 on success, -errno on failure.
  */
 int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
@@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	return end_pfn - start_pfn;
 }
 
+static void __init memmap_init_reserved_pages(void)
+{
+	struct memblock_region *region;
+	phys_addr_t start, end;
+	u64 i;
+
+	/* initialize struct pages for the reserved regions */
+	for_each_reserved_mem_range(i, &start, &end)
+		reserve_bootmem_region(start, end);
+
+	/* and also treat struct pages for the NOMAP regions as PageReserved */
+	for_each_mem_region(region) {
+		if (memblock_is_nomap(region)) {
+			start = region->base;
+			end = start + region->size;
+			reserve_bootmem_region(start, end);
+		}
+	}
+}
+
 static unsigned long __init free_low_memory_core_early(void)
 {
 	unsigned long count = 0;
@@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memblock_clear_hotplug(0, -1);
 
-	for_each_reserved_mem_range(i, &start, &end)
-		reserve_bootmem_region(start, end);
+	memmap_init_reserved_pages();
 
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 10:09:24 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 12:09:24 +0300
Subject: [PATCH v1 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210420090925.7457-1-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
Message-ID: <20210420090925.7457-4-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.

Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.

Introduce a dedicated pfn_is_map_memory() wrapper for
memblock_is_map_memory() to perform such check and use it where
appropriate.

Using a wrapper allows to avoid cyclic include dependencies.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/include/asm/memory.h | 2 +-
 arch/arm64/include/asm/page.h   | 1 +
 arch/arm64/kvm/mmu.c            | 2 +-
 arch/arm64/mm/init.c            | 6 ++++++
 arch/arm64/mm/ioremap.c         | 4 ++--
 arch/arm64/mm/mmu.c             | 2 +-
 6 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..194f9f993d30 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
-	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
+	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
 })
 
 void dump_mem_limit(void);
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..99a6da91f870 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
 typedef struct page *pgtable_t;
 
 extern int pfn_valid(unsigned long);
+extern int pfn_is_map_memory(unsigned long);
 
 #include <asm/memory.h>
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..23dd99e29b23 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 
 static bool kvm_is_device_pfn(unsigned long pfn)
 {
-	return !pfn_valid(pfn);
+	return !pfn_is_map_memory(pfn);
 }
 
 /*
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..c54e329aca15 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
 }
 EXPORT_SYMBOL(pfn_valid);
 
+int pfn_is_map_memory(unsigned long pfn)
+{
+	return memblock_is_map_memory(PFN_PHYS(pfn));
+}
+EXPORT_SYMBOL(pfn_is_map_memory);
+
 static phys_addr_t memory_limit = PHYS_ADDR_MAX;
 
 /*
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b5e83c46b23e..b7c81dacabf0 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
 	/*
 	 * Don't allow RAM to be mapped.
 	 */
-	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
 void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
 {
 	/* For normal memory we already have a cacheable mapping. */
-	if (pfn_valid(__phys_to_pfn(phys_addr)))
+	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
 		return (void __iomem *)__phys_to_virt(phys_addr);
 
 	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..26045e9adbd7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
-	if (!pfn_valid(pfn))
+	if (!pfn_is_map_memory(pfn))
 		return pgprot_noncached(vma_prot);
 	else if (file->f_flags & O_SYNC)
 		return pgprot_writecombine(vma_prot);
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 10:09:25 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 12:09:25 +0300
Subject: [PATCH v1 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
In-Reply-To: <20210420090925.7457-1-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
Message-ID: <20210420090925.7457-5-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The arm64's version of pfn_valid() differs from the generic because of two
reasons:

* Parts of the memory map are freed during boot. This makes it necessary to
  verify that there is actual physical memory that corresponds to a pfn
  which is done by querying memblock.

* There are NOMAP memory regions. These regions are not mapped in the
  linear map and until the previous commit the struct pages representing
  these areas had default values.

As the consequence of absence of the special treatment of NOMAP regions in
the memory map it was necessary to use memblock_is_map_memory() in
pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
generic mm functionality would not treat a NOMAP page as a normal page.

Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
the rest of core mm will treat them as unusable memory and thus
pfn_valid_within() is no longer required at all and can be disabled by
removing CONFIG_HOLES_IN_ZONE on arm64.

pfn_valid() can be slightly simplified by replacing
memblock_is_map_memory() with memblock_is_memory().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/Kconfig   | 3 ---
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..58e439046d05 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA
 
-config HOLES_IN_ZONE
-	def_bool y
-
 source "kernel/Kconfig.hz"
 
 config ARCH_SPARSEMEM_ENABLE
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index c54e329aca15..370f33765b64 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
 
 	/*
 	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_map_memory() check for ZONE_DEVICE based
+	 * memblock_is_memory() check for ZONE_DEVICE based
 	 * addresses will always fail. Even the normal hotplugged
 	 * memory will never have MEMBLOCK_NOMAP flag set in their
 	 * memblock entries. Skip memblock search for all non early
@@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
 		return pfn_section_valid(ms, pfn);
 }
 #endif
-	return memblock_is_map_memory(addr);
+	return memblock_is_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
 
-- 
2.28.0



From hverkuil-cisco at xs4all.nl  Tue Apr 20 10:16:35 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 20 Apr 2021 11:16:35 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <36008691-d075-203d-0cac-2a012773ea34@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
 <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
 <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>
 <36008691-d075-203d-0cac-2a012773ea34@collabora.com>
Message-ID: <43a767f8-77f5-7937-c484-753a3123f6a2@xs4all.nl>

On 20/04/2021 11:10, Benjamin Gaignard wrote:
> 
> Le 16/04/2021 ? 17:14, Lucas Stach a ?crit?:
>> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>>> Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
>>>> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>>>>> In order to be able to share the control hardware block between
>>>>> VPUs use a syscon instead a ioremap it in the driver.
>>>>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>>>>> phandle is not found look at 'ctrl' reg-name.
>>>>> With the method it becomes useless to provide a list of register
>>>>> names so remove it.
>>>> Sorry for putting a spoke in the wheel after many iterations of the
>>>> series.
>>>>
>>>> We just discussed a way forward on how to handle the clocks and resets
>>>> provided by the blkctl block on i.MX8MM and later and it seems there is
>>>> a consensus on trying to provide virtual power domains from a blkctl
>>>> driver, controlling clocks and resets for the devices in the power
>>>> domain. I would like to avoid introducing yet another way of handling
>>>> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
>>>> what we are planning to do on the later chip generations.
>>>>
>>>> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
>>>> virtual power domain thing a shot.
>>> That could replace the 3 first patches and Dt patche of this series
>>> but that will not impact the hevc part, so I wonder if pure hevc patches
>>> could be merged anyway ?
>>> They are reviewed and don't depend of how the ctrl block is managed.
>> I'm not really in a position to give any informed opinion about that
>> hvec patches, as I only skimmed them, but I don't see any reason to
>> delay patches 04-11 from this series until the i.MX8M platform issues
>> are sorted. AFAICS those things are totally orthogonal.
> 
> Hi Hans,
> What do you think about this proposal to split this series ?
> Get hevc part merged could allow me to continue to add features
> like scaling lists, compressed reference buffers and 10-bit supports.

Makes sense to me!

Regards,

	Hans


From david at redhat.com  Tue Apr 20 10:22:53 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 11:22:53 +0200
Subject: [PATCH v1 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <20210420090925.7457-2-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-2-rppt@kernel.org>
Message-ID: <f900f889-f059-7d48-dfc7-145c8cd54cf6@redhat.com>

On 20.04.21 11:09, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> Add comment describing the semantics of pfn_valid() that clarifies that
> pfn_valid() only checks for availability of a memory map entry (i.e. struct
> page) for a PFN rather than availability of usable memory backing that PFN.
> 
> The most "generic" version of pfn_valid() used by the configurations with
> SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
> suitable place for documentation about semantics of pfn_valid().
> 
> Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   include/linux/mmzone.h | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 47946cec7584..961f0eeefb62 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>   #endif
>   
>   #ifndef CONFIG_HAVE_ARCH_PFN_VALID
> +/**
> + * pfn_valid - check if there is a valid memory map entry for a PFN
> + * @pfn: the page frame number to check
> + *
> + * Check if there is a valid memory map entry aka struct page for the @pfn.
> + * Note, that availability of the memory map entry does not imply that
> + * there is actual usable memory at that @pfn. The struct page may
> + * represent a hole or an unusable page frame.
> + *
> + * Return: 1 for PFNs that have memory map entries and 0 otherwise
> + */
>   static inline int pfn_valid(unsigned long pfn)
>   {
>   	struct mem_section *ms;
> 

I'd rephrase all "there is a valid memory map" to "there is a memory 
map" and add "pfn_valid() does to indicate whether the memory map as 
actually initialized -- see pfn_to_online_page()."

pfn_valid() means that we can do a pfn_to_page() and don't get a fault 
when accessing the "struct page". It doesn't state anything about the 
content.

-- 
Thanks,

David / dhildenb



From dan.carpenter at oracle.com  Tue Apr 20 10:23:25 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Tue, 20 Apr 2021 12:23:25 +0300
Subject: [kbuild] [xlnx:release-2020.2.2_k26 207/241]
 drivers/pinctrl/core.c:1273 pinctrl_commit_state() error: uninitialized
 symbol 'ret'.
Message-ID: <20210420092325.GG1959@kadam>

tree:   https://github.com/Xilinx/linux-xlnx  release-2020.2.2_k26
head:   4731ff5042ce76fc145bc2797faa2d91b090675e
commit: 11367d8e6e31164b198401335b9a19b5b7234ec0 [207/241] pinctrl: core: Handling pinmux and pinconf separately
config: i386-randconfig-m021-20210419 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

New smatch warnings:
drivers/pinctrl/core.c:1273 pinctrl_commit_state() error: uninitialized symbol 'ret'.

vim +/ret +1273 drivers/pinctrl/core.c

981ed1bfbc6c46 Florian Fainelli  2017-03-01  1237  static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state)
befe5bdfbb698b Linus Walleij     2012-02-09  1238  {
6e5e959dde0d92 Stephen Warren    2012-03-02  1239  	struct pinctrl_setting *setting, *setting2;
50cf7c8ab324de Richard Genoud    2013-03-25  1240  	struct pinctrl_state *old_state = p->state;
6e5e959dde0d92 Stephen Warren    2012-03-02  1241  	int ret;
7ecdb16fe63e5b Stephen Warren    2012-03-02  1242  
6e5e959dde0d92 Stephen Warren    2012-03-02  1243  	if (p->state) {
6e5e959dde0d92 Stephen Warren    2012-03-02  1244  		/*
2243a87d90b42e Fan Wu            2014-06-09  1245  		 * For each pinmux setting in the old state, forget SW's record
2243a87d90b42e Fan Wu            2014-06-09  1246  		 * of mux owner for that pingroup. Any pingroups which are
2243a87d90b42e Fan Wu            2014-06-09  1247  		 * still owned by the new state will be re-acquired by the call
2243a87d90b42e Fan Wu            2014-06-09  1248  		 * to pinmux_enable_setting() in the loop below.
6e5e959dde0d92 Stephen Warren    2012-03-02  1249  		 */
6e5e959dde0d92 Stephen Warren    2012-03-02  1250  		list_for_each_entry(setting, &p->state->settings, node) {
1e2082b5207217 Stephen Warren    2012-03-02  1251  			if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
1e2082b5207217 Stephen Warren    2012-03-02  1252  				continue;
7ecdb16fe63e5b Stephen Warren    2012-03-02  1253  			pinmux_disable_setting(setting);
befe5bdfbb698b Linus Walleij     2012-02-09  1254  		}
57b676f9c1b7cd Stephen Warren    2012-03-02  1255  	}
57b676f9c1b7cd Stephen Warren    2012-03-02  1256  
3102a76cfbf9ac Richard Genoud    2013-03-25  1257  	p->state = NULL;
6e5e959dde0d92 Stephen Warren    2012-03-02  1258  
11367d8e6e3116 Michal Simek      2021-03-10  1259  	/* Apply all the settings for the new state - pinmux first */
6e5e959dde0d92 Stephen Warren    2012-03-02  1260  	list_for_each_entry(setting, &state->settings, node) {
1e2082b5207217 Stephen Warren    2012-03-02  1261  		switch (setting->type) {
1e2082b5207217 Stephen Warren    2012-03-02  1262  		case PIN_MAP_TYPE_MUX_GROUP:
6e5e959dde0d92 Stephen Warren    2012-03-02  1263  			ret = pinmux_enable_setting(setting);
1e2082b5207217 Stephen Warren    2012-03-02  1264  			break;
1e2082b5207217 Stephen Warren    2012-03-02  1265  		case PIN_MAP_TYPE_CONFIGS_PIN:
11367d8e6e3116 Michal Simek      2021-03-10  1266  		case PIN_MAP_TYPE_CONFIGS_GROUP:
11367d8e6e3116 Michal Simek      2021-03-10  1267  			break;

"ret" not set for these cases.

11367d8e6e3116 Michal Simek      2021-03-10  1268  		default:
11367d8e6e3116 Michal Simek      2021-03-10  1269  			ret = -EINVAL;
11367d8e6e3116 Michal Simek      2021-03-10  1270  			break;
11367d8e6e3116 Michal Simek      2021-03-10  1271  		}
11367d8e6e3116 Michal Simek      2021-03-10  1272  
11367d8e6e3116 Michal Simek      2021-03-10 @1273  		if (ret < 0)
11367d8e6e3116 Michal Simek      2021-03-10  1274  			goto unapply_new_state;
11367d8e6e3116 Michal Simek      2021-03-10  1275  
11367d8e6e3116 Michal Simek      2021-03-10  1276  		/* Do not link hogs (circular dependency) */
11367d8e6e3116 Michal Simek      2021-03-10  1277  		if (p != setting->pctldev->p)
11367d8e6e3116 Michal Simek      2021-03-10  1278  			pinctrl_link_add(setting->pctldev, p->dev);
11367d8e6e3116 Michal Simek      2021-03-10  1279  	}
11367d8e6e3116 Michal Simek      2021-03-10  1280  
11367d8e6e3116 Michal Simek      2021-03-10  1281  	/* Apply all the settings for the new state - pinconf after */
11367d8e6e3116 Michal Simek      2021-03-10  1282  	list_for_each_entry(setting, &state->settings, node) {
11367d8e6e3116 Michal Simek      2021-03-10  1283  		switch (setting->type) {
11367d8e6e3116 Michal Simek      2021-03-10  1284  		case PIN_MAP_TYPE_MUX_GROUP:
11367d8e6e3116 Michal Simek      2021-03-10  1285  			break;

Same.  We probably just want to initialize it in the declaration.

11367d8e6e3116 Michal Simek      2021-03-10  1286  		case PIN_MAP_TYPE_CONFIGS_PIN:
1e2082b5207217 Stephen Warren    2012-03-02  1287  		case PIN_MAP_TYPE_CONFIGS_GROUP:
1e2082b5207217 Stephen Warren    2012-03-02  1288  			ret = pinconf_apply_setting(setting);
1e2082b5207217 Stephen Warren    2012-03-02  1289  			break;
1e2082b5207217 Stephen Warren    2012-03-02  1290  		default:
1e2082b5207217 Stephen Warren    2012-03-02  1291  			ret = -EINVAL;
1e2082b5207217 Stephen Warren    2012-03-02  1292  			break;
1e2082b5207217 Stephen Warren    2012-03-02  1293  		}
3102a76cfbf9ac Richard Genoud    2013-03-25  1294  
42fed7ba44e4e8 Patrice Chotard   2013-04-11  1295  		if (ret < 0) {
3102a76cfbf9ac Richard Genoud    2013-03-25  1296  			goto unapply_new_state;
6e5e959dde0d92 Stephen Warren    2012-03-02  1297  		}
036f394dd77f81 Benjamin Gaignard 2019-05-22  1298  
b672a87ae5ab07 Linus Walleij     2019-05-24  1299  		/* Do not link hogs (circular dependency) */
b672a87ae5ab07 Linus Walleij     2019-05-24  1300  		if (p != setting->pctldev->p)
036f394dd77f81 Benjamin Gaignard 2019-05-22  1301  			pinctrl_link_add(setting->pctldev, p->dev);
42fed7ba44e4e8 Patrice Chotard   2013-04-11  1302  	}
6e5e959dde0d92 Stephen Warren    2012-03-02  1303  
3102a76cfbf9ac Richard Genoud    2013-03-25  1304  	p->state = state;
3102a76cfbf9ac Richard Genoud    2013-03-25  1305  
6e5e959dde0d92 Stephen Warren    2012-03-02  1306  	return 0;
3102a76cfbf9ac Richard Genoud    2013-03-25  1307  
3102a76cfbf9ac Richard Genoud    2013-03-25  1308  unapply_new_state:
da58751ca2490d Richard Genoud    2013-03-28  1309  	dev_err(p->dev, "Error applying setting, reverse things back\n");
3102a76cfbf9ac Richard Genoud    2013-03-25  1310  
3102a76cfbf9ac Richard Genoud    2013-03-25  1311  	list_for_each_entry(setting2, &state->settings, node) {
3102a76cfbf9ac Richard Genoud    2013-03-25  1312  		if (&setting2->node == &setting->node)
3102a76cfbf9ac Richard Genoud    2013-03-25  1313  			break;
af606177713163 Richard Genoud    2013-03-29  1314  		/*
af606177713163 Richard Genoud    2013-03-29  1315  		 * All we can do here is pinmux_disable_setting.
af606177713163 Richard Genoud    2013-03-29  1316  		 * That means that some pins are muxed differently now
af606177713163 Richard Genoud    2013-03-29  1317  		 * than they were before applying the setting (We can't
af606177713163 Richard Genoud    2013-03-29  1318  		 * "unmux a pin"!), but it's not a big deal since the pins
af606177713163 Richard Genoud    2013-03-29  1319  		 * are free to be muxed by another apply_setting.
af606177713163 Richard Genoud    2013-03-29  1320  		 */
af606177713163 Richard Genoud    2013-03-29  1321  		if (setting2->type == PIN_MAP_TYPE_MUX_GROUP)
af606177713163 Richard Genoud    2013-03-29  1322  			pinmux_disable_setting(setting2);
3102a76cfbf9ac Richard Genoud    2013-03-25  1323  	}
8009d5ff00df6a Richard Genoud    2013-03-28  1324  
385d94246b05f7 Richard Genoud    2013-03-29  1325  	/* There's no infinite recursive loop here because p->state is NULL */
385d94246b05f7 Richard Genoud    2013-03-29  1326  	if (old_state)
42fed7ba44e4e8 Patrice Chotard   2013-04-11  1327  		pinctrl_select_state(p, old_state);
6e5e959dde0d92 Stephen Warren    2012-03-02  1328  
6e5e959dde0d92 Stephen Warren    2012-03-02  1329  	return ret;
befe5bdfbb698b Linus Walleij     2012-02-09  1330  }

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/ad278d5b/attachment-0001.gz>
-------------- next part --------------
_______________________________________________
kbuild mailing list -- kbuild at lists.01.org
To unsubscribe send an email to kbuild-leave at lists.01.org

From dafna.hirschfeld at collabora.com  Tue Apr 20 10:24:07 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Tue, 20 Apr 2021 11:24:07 +0200
Subject: [PATCH] media: rkisp1: rksip1-capture.c: Improve comments and fix
 typos
In-Reply-To: <20210418103425.45525-1-sebastian.fricke@posteo.net>
References: <20210418103425.45525-1-sebastian.fricke@posteo.net>
Message-ID: <0b5feeb7-44e6-f25d-cc03-37aba628be14@collabora.com>

Hi,
Thanks for the fixes

On 18.04.21 12:34, Sebastian Fricke wrote:
> Improve the wording of the function description to increase readability.
> 
> Fix three typos:
> s/during processing a frame/while processing a frame/
> s/it also update/it also updates/
> s/there's not buf in shadow/there's no buffer in a shadow register/
> 
> Replace the abbreviation 'buf' with the full word buffer, the
> abbreviation 'config' with the verb configure, and 'regs' with registers.
> The goal of this change is to ease the reading flow of the comment.
> 
> Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>
> ---
> Side-note:
> I also believe there should be a description for the abbreviation FE, as
> it is not described anywhere. I think it means frame end, right?.

yes, this is Frame End. You can send a patch replacing "FE" with frame end if you like.

Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld at collabora.com>

> ---
>   .../platform/rockchip/rkisp1/rkisp1-capture.c    | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index 5f6c9d1623e4..9643bdd05b7b 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -830,8 +830,8 @@ static void rkisp1_return_all_buffers(struct rkisp1_capture *cap,
>   }
>   
>   /*
> - * Most of registers inside rockchip ISP1 have shadow register since
> - * they must be not be changed during processing a frame.
> + * Most registers inside the rockchip ISP1 have shadow register since
> + * they must not be changed while processing a frame.
>    * Usually, each sub-module updates its shadow register after
>    * processing the last pixel of a frame.
>    */
> @@ -847,14 +847,14 @@ static void rkisp1_cap_stream_enable(struct rkisp1_capture *cap)
>   	spin_lock_irq(&cap->buf.lock);
>   	rkisp1_set_next_buf(cap);
>   	cap->ops->enable(cap);
> -	/* It's safe to config ACTIVE and SHADOW regs for the
> +	/* It's safe to configure ACTIVE and SHADOW registers for the
>   	 * first stream. While when the second is starting, do NOT
> -	 * force update because it also update the first one.
> +	 * force update because it also updates the first one.
>   	 *
> -	 * The latter case would drop one more buf(that is 2) since
> -	 * there's not buf in shadow when the second FE received. This's
> -	 * also required because the second FE maybe corrupt especially
> -	 * when run at 120fps.
> +	 * The latter case would drop one more buffer(that is 2) since
> +	 * there's no buffer in a shadow register when the second FE received.
> +	 * This's also required because the second FE maybe corrupt
> +	 * especially when run at 120fps.
>   	 */
>   	if (!other->is_streaming) {
>   		/* force cfg update */
> 


From dafna.hirschfeld at collabora.com  Tue Apr 20 10:26:25 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Tue, 20 Apr 2021 11:26:25 +0200
Subject: [PATCH] media: rkisp1: rkisp1-params.c: Fix typos
In-Reply-To: <20210419060224.44353-1-sebastian.fricke@posteo.net>
References: <20210419060224.44353-1-sebastian.fricke@posteo.net>
Message-ID: <02425403-5b44-62f8-4cab-a677fe317dbe@collabora.com>

Hi,


On 19.04.21 08:02, Sebastian Fricke wrote:
> s/when the camera active/when the camera is active/
> s/thus not isr protection/thus no ISR protection/
> 
> Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>
> ---
>   drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> index b6beddd988d0..ead948a2d01e 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> @@ -1258,7 +1258,7 @@ void rkisp1_params_configure(struct rkisp1_params *params,
>   	rkisp1_params_config_parameter(params);
>   }
>   
> -/* Not called when the camera active, thus not isr protection. */
> +/* Not called when the camera is active, thus no ISR protection. */

I think it would better to write

/* Not called when the camera is active, therefore there is no need to acquire a lock */

Thanks,
Dafna

>   void rkisp1_params_disable(struct rkisp1_params *params)
>   {
>   	rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPCC_MODE,
> 


From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:41 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:41 +0200
Subject: [PATCH v3 00/10] ACPI/IORT: Support for IORT RMR node
Message-ID: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>

Hi,

RFC v2 --> v3
 -Dropped RFC tag as the ACPICA header changes are now ready to be
  part of 5.13[0]. But this series still has a dependency on that patch.
 -Added IORT E.b related changes(node flags, _DSM function 5 checks for
  PCIe).
 -Changed RMR to stream id mapping from M:N to M:1 as per the spec and
  discussion here[1].
 -Last two patches add support for SMMUv2(Thanks to Jon Nettleton!) 

Sanity tested on a HiSilicon D06. Further testing and feedback is greatly
appreciated.

The whole series can be found here,
https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc8-rmr-v3

Thanks,
Shameer

[0] https://lore.kernel.org/linux-acpi/20210406213028.718796-22-erik.kaneda at intel.com/
[1] https://op-lists.linaro.org/pipermail/linaro-open-discussions/2021-April/000150.html

RFC v1 --> v2:
?- Added a generic interface for IOMMU drivers to retrieve all the 
? ?RMR info associated with a given IOMMU.
?- SMMUv3 driver gets the RMR list during probe() and installs
?? bypass STEs for all the SIDs in the RMR list. This is to keep
 ? the ongoing traffic alive(if any) during SMMUv3 reset. This is
   based on the suggestions received for v1 to take care of the
   EFI framebuffer use case. Only sanity tested for now.
?- During the probe/attach device, SMMUv3 driver reserves any
? ?RMR region associated with the device such that there is a unity
? ?mapping for them in SMMU.
---? ??

>From RFC v1:
-------------
The series adds support to IORT RMR nodes specified in IORT
Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
ranges that are used by endpoints and require a unity mapping
in SMMU.

We have faced issues with 3408iMR RAID controller cards which
fail to boot when SMMU is enabled. This is because these controllers
make use of host memory for various caching related purposes and when
SMMU is enabled the iMR firmware fails to access these memory regions
as there is no mapping for them. IORT RMR provides a way for UEFI to
describe and report these memory regions so that the kernel can make
a unity mapping for these in SMMU.

Tests:

With a UEFI, that reports the RMR for the dev,
....
[16F0h 5872   1]                         Type : 06
[16F1h 5873   2]                       Length : 007C
[16F3h 5875   1]                     Revision : 00
[1038h 0056   2]                     Reserved : 00000000
[1038h 0056   2]                   Identifier : 00000000
[16F8h 5880   4]                Mapping Count : 00000001
[16FCh 5884   4]               Mapping Offset : 00000040

[1700h 5888   4]    Number of RMR Descriptors : 00000002
[1704h 5892   4]        RMR Descriptor Offset : 00000018

[1708h 5896   8]          Base Address of RMR : 0000E6400000
[1710h 5904   8]                Length of RMR : 000000100000
[1718h 5912   4]                     Reserved : 00000000

[171Ch 5916   8]          Base Address of RMR : 0000000027B00000
[1724h 5924   8]                Length of RMR : 0000000000C00000
[172Ch 5932   4]                     Reserved : 00000000

[1730h 5936   4]                   Input base : 00000000
[1734h 5940   4]                     ID Count : 00000001
[1738h 5944   4]                  Output Base : 00000003
[173Ch 5948   4]             Output Reference : 00000064
[1740h 5952   4]        Flags (decoded below) : 00000001
                               Single Mapping : 1
...

Without the series the RAID controller initialization fails as
below,

...
[   12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache        : Yes   
[   12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
[   18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0                                                                         
[   23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state 
[  106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready                                    
[  106.695186] megaraid_sas 0000:03:00.0: System Register set:                  
[  106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.                                                                   
[  106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407      
estuary:/$

With the series, now the kernel has direct mapping for the dev as
below,

estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions                      
0x0000000008000000 0x00000000080fffff msi                                       
0x0000000027b00000 0x00000000286fffff direct                                    
0x00000000e6400000 0x00000000e64fffff direct                                    
estuary:/$

....
[   12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009                                                   
[   12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0      max_lds: 32                                                                      
[   12.746628] megaraid_sas 0000:03:00.0: controller type       : iMR(0MB)      
[   12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR)  : Enabled                                                                               
[   12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support   : Yes           
[   12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes           
[   12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs                                                                 
[   12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support     : Yes   
[   12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support    : No    
[   12.819179] megaraid_sas 0000:03:00.0: NVME page size        : (4096)        
[   12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000                                                    
[   12.835199] megaraid_sas 0000:03:00.0: INIT adapter done                     
[   12.873932] megaraid_sas 0000:03:00.0: pci id                : (0x1000)/(0x0017)/(0x19e5)/(0xd213)                                                           
[   12.881644] megaraid_sas 0000:03:00.0: unevenspan support    : no            
[   12.887451] megaraid_sas 0000:03:00.0: firmware crash dump   : no            
[   12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map     : enabled       

RAID controller init is now success and can detect the drives
attached as well.


Jon Nettleton (2):
  iommu/arm-smmu: Get associated RMR info and install bypass SMR
  iommu/arm-smmu: Reserve any RMR regions associated with a dev

Shameer Kolothum (8):
  ACPI/IORT: Add support for RMR node parsing
  iommu/dma: Introduce generic helper to retrieve RMR info
  ACPI/IORT: Add a helper to retrieve RMR memory regions
  iommu/dma: Add a helper function to reserve RMRs for IOMMU drivers
  iommu/arm-smmu-v3: Introduce strtab init helper
  iommu/arm-smmu-v3: Add bypass flag to?arm_smmu_write_strtab_ent()
  iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
  iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev

 drivers/acpi/arm64/iort.c                   | 144 +++++++++++++++++++-
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  98 +++++++++++--
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |   2 +
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |  75 ++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu.h       |   2 +
 drivers/iommu/dma-iommu.c                   |  71 ++++++++++
 include/linux/acpi_iort.h                   |   7 +
 include/linux/dma-iommu.h                   |  15 ++
 include/linux/iommu.h                       |  19 +++
 9 files changed, 417 insertions(+), 16 deletions(-)

-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:42 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:42 +0200
Subject: [PATCH v3 01/10] ACPI/IORT: Add support for RMR node parsing
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-2-shameerali.kolothum.thodi@huawei.com>

Add support for parsing RMR node information from ACPI.
Find associated stream id and smmu node info from the
RMR node and populate a linked list with RMR memory
descriptors.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/acpi/arm64/iort.c | 104 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 2494138a6905..bd96c5e3b36e 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -40,6 +40,19 @@ struct iort_fwnode {
 static LIST_HEAD(iort_fwnode_list);
 static DEFINE_SPINLOCK(iort_fwnode_lock);
 
+/*
+ * One entry for IORT RMR.
+ */
+struct iort_rmr_entry {
+	struct list_head list;
+	u32 sid;
+	struct acpi_iort_node *smmu;
+	struct acpi_iort_rmr_desc *rmr_desc;
+	u32 flags;
+};
+
+static LIST_HEAD(iort_rmr_list);         /* list of RMR regions from ACPI */
+
 /**
  * iort_set_fwnode() - Create iort_fwnode and use it to register
  *		       iommu data in the iort_fwnode_list
@@ -393,7 +406,8 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
 		if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
 		    node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX ||
 		    node->type == ACPI_IORT_NODE_SMMU_V3 ||
-		    node->type == ACPI_IORT_NODE_PMCG) {
+		    node->type == ACPI_IORT_NODE_PMCG ||
+		    node->type == ACPI_IORT_NODE_RMR) {
 			*id_out = map->output_base;
 			return parent;
 		}
@@ -1659,6 +1673,91 @@ static void __init iort_enable_acs(struct acpi_iort_node *iort_node)
 #else
 static inline void iort_enable_acs(struct acpi_iort_node *iort_node) { }
 #endif
+static int iort_rmr_desc_valid(struct acpi_iort_rmr_desc *desc, u32 count)
+{
+	int i, j;
+
+	for (i = 0; i < count; i++) {
+		u64 end, start = desc[i].base_address, length = desc[i].length;
+
+		if (!IS_ALIGNED(start, SZ_64K) || !IS_ALIGNED(length, SZ_64K))
+			return -EINVAL;
+
+		end = start + length - 1;
+
+		/* Check for address overlap */
+		for (j = i + 1; j < count; j++) {
+			u64 e_start = desc[j].base_address;
+			u64 e_end = e_start + desc[j].length - 1;
+
+			if (start <= e_end && end >= e_start)
+				return -EINVAL;
+		}
+	}
+
+	return 0;
+}
+
+static int __init iort_parse_rmr(struct acpi_iort_node *iort_node)
+{
+	struct acpi_iort_node *smmu;
+	struct iort_rmr_entry *e;
+	struct acpi_iort_rmr *rmr;
+	struct acpi_iort_rmr_desc *rmr_desc;
+	u32 map_count = iort_node->mapping_count;
+	u32  sid;
+	int i, ret = 0;
+
+	if (iort_node->type != ACPI_IORT_NODE_RMR)
+		return 0;
+
+	if (!iort_node->mapping_offset || map_count != 1) {
+		pr_err(FW_BUG "Invalid ID mapping, skipping RMR node %p\n",
+		       iort_node);
+		return -EINVAL;
+	}
+
+	/* Retrieve associated smmu and stream id */
+	smmu = iort_node_get_id(iort_node, &sid, 0);
+	if (!smmu) {
+		pr_err(FW_BUG "Invalid SMMU reference, skipping RMR node %p\n",
+		       iort_node);
+		return -EINVAL;
+	}
+
+	/* Retrieve RMR data */
+	rmr = (struct acpi_iort_rmr *)iort_node->node_data;
+	if (!rmr->rmr_offset || !rmr->rmr_count) {
+		pr_err(FW_BUG "Invalid RMR descriptor array, skipping RMR node %p\n",
+		       iort_node);
+		return -EINVAL;
+	}
+
+	rmr_desc = ACPI_ADD_PTR(struct acpi_iort_rmr_desc, iort_node,
+				rmr->rmr_offset);
+
+	ret = iort_rmr_desc_valid(rmr_desc, rmr->rmr_count);
+	if (ret) {
+		pr_err(FW_BUG "Invalid RMR descriptor[%d] for node %p, skipping...\n",
+		       i, iort_node);
+		return ret;
+	}
+
+	for (i = 0; i < rmr->rmr_count; i++, rmr_desc++) {
+		e = kmalloc(sizeof(*e), GFP_KERNEL);
+		if (!e)
+			return -ENOMEM;
+
+		e->sid = sid;
+		e->smmu = smmu;
+		e->rmr_desc = rmr_desc;
+		e->flags = rmr->flags;
+
+		list_add_tail(&e->list, &iort_rmr_list);
+	}
+
+	return 0;
+}
 
 static void __init iort_init_platform_devices(void)
 {
@@ -1688,6 +1787,9 @@ static void __init iort_init_platform_devices(void)
 
 		iort_enable_acs(iort_node);
 
+		if (iort_table->revision == 3)
+			iort_parse_rmr(iort_node);
+
 		ops = iort_get_dev_cfg(iort_node);
 		if (ops) {
 			fwnode = acpi_alloc_fwnode_static();
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:43 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:43 +0200
Subject: [PATCH v3 02/10] iommu/dma: Introduce generic helper to retrieve RMR
 info
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>

Reserved Memory Regions(RMR) associated with an IOMMU may be
described either through ACPI tables or DT in systems with
devices that require a unity mapping or bypass for those
regions in IOMMU drivers.

Introduce a generic interface so that IOMMU drivers can retrieve
and set up necessary mappings.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/dma-iommu.c | 33 +++++++++++++++++++++++++++++++++
 include/linux/dma-iommu.h |  8 ++++++++
 include/linux/iommu.h     | 19 +++++++++++++++++++
 3 files changed, 60 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index af765c813cc8..86a1e48b1fe8 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -191,6 +191,39 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_rmrs - Retrieve Reserved Memory Regions(RMRs) associated
+ *                      with a given IOMMU
+ * @iommu_fwnode: fwnode associated with IOMMU
+ * @list: RMR list to be populated
+ *
+ */
+int iommu_dma_get_rmrs(struct fwnode_handle *iommu_fwnode,
+		       struct list_head *list)
+{
+	return 0;
+}
+EXPORT_SYMBOL(iommu_dma_get_rmrs);
+
+struct iommu_rmr *iommu_dma_alloc_rmr(u64 base, u64 length, u32 sid,
+				      u32 flags)
+{
+	struct iommu_rmr *rmr;
+
+	rmr = kzalloc(sizeof(*rmr), GFP_KERNEL);
+	if (!rmr)
+		return NULL;
+
+	INIT_LIST_HEAD(&rmr->list);
+	rmr->base_address = base;
+	rmr->length = length;
+	rmr->sid = sid;
+	rmr->flags = flags;
+
+	return rmr;
+}
+EXPORT_SYMBOL(iommu_dma_alloc_rmr);
+
 static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
 		phys_addr_t start, phys_addr_t end)
 {
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 706b68d1359b..beb84c4fe5b1 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -40,6 +40,9 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
 		struct iommu_domain *domain);
 
+int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
+struct iommu_rmr *iommu_dma_alloc_rmr(u64 base, u64 length, u32 sid, u32 flags);
+
 #else /* CONFIG_IOMMU_DMA */
 
 struct iommu_domain;
@@ -86,5 +89,10 @@ static inline void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
 {
 }
 
+int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
+{
+	return 0;
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __DMA_IOMMU_H */
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 5e7fe519430a..fb8820c40144 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -595,6 +595,25 @@ struct iommu_sva {
 	struct device			*dev;
 };
 
+/**
+ * struct iommu_rmr - Reserved Memory Region details per IOMMU
+ * @list: Linked list pointers to hold RMR region info
+ * @base_address: base address of Reserved Memory Region
+ * @length: length of memory region
+ * @sid: associated stream id
+ * @flags: flags that apply to the RMR node
+ */
+struct iommu_rmr {
+	struct list_head	list;
+	phys_addr_t		base_address;
+	u64			length;
+	u32			sid;
+	u32			flags;
+};
+
+/* RMR Remap permitted */
+#define IOMMU_RMR_REMAP_PERMITTED	(1 << 0)
+
 int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
 		      const struct iommu_ops *ops);
 void iommu_fwspec_free(struct device *dev);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:44 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:44 +0200
Subject: [PATCH v3 03/10] ACPI/IORT: Add a helper to retrieve RMR memory
 regions
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-4-shameerali.kolothum.thodi@huawei.com>

Add a helper function that retrieves RMR memory descriptors
associated with a given IOMMU. This will be used by IOMMU
drivers to setup necessary mappings.

Now that we have this, invoke this from the generic helper
interface.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/acpi/arm64/iort.c | 40 +++++++++++++++++++++++++++++++++++++++
 drivers/iommu/dma-iommu.c |  3 +++
 include/linux/acpi_iort.h |  7 +++++++
 3 files changed, 50 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index bd96c5e3b36e..66e314b15692 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -12,6 +12,7 @@
 
 #include <linux/acpi_iort.h>
 #include <linux/bitfield.h>
+#include <linux/dma-iommu.h>
 #include <linux/iommu.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
@@ -837,6 +838,43 @@ static inline int iort_add_device_replay(struct device *dev)
 	return err;
 }
 
+/**
+ * iort_iommu_get_rmrs - Helper to retrieve RMR info associated with IOMMU
+ * @iommu: fwnode for the IOMMU
+ * @head: RMR list head to be populated
+ *
+ * Returns: 0 on success, <0 failure
+ */
+int iort_iommu_get_rmrs(struct fwnode_handle *iommu_fwnode,
+			struct list_head *head)
+{
+	struct iort_rmr_entry *e;
+	struct acpi_iort_node *iommu;
+
+	iommu = iort_get_iort_node(iommu_fwnode);
+	if (!iommu)
+		return 0;
+
+	list_for_each_entry(e, &iort_rmr_list, list) {
+		struct acpi_iort_rmr_desc *rmr_desc;
+		struct iommu_rmr *rmr;
+
+		if (e->smmu != iommu)
+			continue;
+
+		rmr_desc = e->rmr_desc;
+		rmr = iommu_dma_alloc_rmr(rmr_desc->base_address,
+					  rmr_desc->length, e->sid,
+					  e->flags);
+		if (!rmr)
+			return -ENOMEM;
+
+		list_add_tail(&rmr->list, head);
+	}
+
+	return 0;
+}
+
 /**
  * iort_iommu_msi_get_resv_regions - Reserved region driver helper
  * @dev: Device from iommu_get_resv_regions()
@@ -1107,6 +1145,8 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 						const u32 *input_id)
 { return NULL; }
+int iort_iommu_get_rmrs(struct fwnode_handle *fwnode, struct list_head *head)
+{ return 0; }
 #endif
 
 static int nc_dma_get_range(struct device *dev, u64 *size)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 86a1e48b1fe8..a942cc04eee1 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -201,6 +201,9 @@ EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 int iommu_dma_get_rmrs(struct fwnode_handle *iommu_fwnode,
 		       struct list_head *list)
 {
+	if (!is_of_node(iommu_fwnode))
+		return iort_iommu_get_rmrs(iommu_fwnode, list);
+
 	return 0;
 }
 EXPORT_SYMBOL(iommu_dma_get_rmrs);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 1a12baa58e40..e9f3bc2f4842 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,6 +39,8 @@ const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 						const u32 *id_in);
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 phys_addr_t acpi_iort_dma_get_max_cpu_address(void);
+int iort_iommu_get_rmrs(struct fwnode_handle *iommu_fwnode,
+			struct list_head *list);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_id(struct device *dev, u32 id)
@@ -59,6 +61,11 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 
 static inline phys_addr_t acpi_iort_dma_get_max_cpu_address(void)
 { return PHYS_ADDR_MAX; }
+
+static inline
+int iort_iommu_get_rmrs(struct fwnode_handle *iommu_fwnode,
+			struct list_head *list)
+{ return 0; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:45 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:45 +0200
Subject: [PATCH v3 04/10] iommu/dma: Add a helper function to reserve RMRs for
 IOMMU drivers
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-5-shameerali.kolothum.thodi@huawei.com>

IOMMU drivers can use this to implement their .get_resv_regions callback
for any RMR address regions specific to a device.

As per ACPI IORT E.b spec, a check is added to make sure OS has preserved
the PCIe configuration done by boot firmware.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/dma-iommu.c | 35 +++++++++++++++++++++++++++++++++++
 include/linux/dma-iommu.h |  7 +++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a942cc04eee1..c624000bf230 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -191,6 +191,41 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
+				    struct list_head *list)
+{
+	int prot = IOMMU_READ | IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	struct iommu_resv_region *region;
+	enum iommu_resv_type type;
+
+	/*
+	 * For ACPI, please make sure the OS has preserved the PCIe configuration
+	 * performed by the boot firmware(See IORT revision E.b).
+	 */
+	if (!is_of_node(dev_iommu_fwspec_get(dev)->iommu_fwnode) &&
+	    dev_is_pci(dev)) {
+		struct pci_dev *pdev = to_pci_dev(dev);
+		struct pci_host_bridge *host = pci_find_host_bridge(pdev->bus);
+
+		if (!host->preserve_config)
+			return;
+	}
+
+	if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED)
+		type = IOMMU_RESV_DIRECT_RELAXABLE;
+	else
+		type = IOMMU_RESV_DIRECT;
+
+	region = iommu_alloc_resv_region(rmr->base_address,
+					 rmr->length, prot,
+					 type);
+	if (!region)
+		return;
+
+	list_add_tail(&region->list, list);
+}
+EXPORT_SYMBOL(iommu_dma_get_rmr_resv_regions);
+
 /**
  * iommu_dma_get_rmrs - Retrieve Reserved Memory Regions(RMRs) associated
  *                      with a given IOMMU
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index beb84c4fe5b1..dbad5073c9e0 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -40,6 +40,8 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
 		struct iommu_domain *domain);
 
+void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
+				    struct list_head *list);
 int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
 struct iommu_rmr *iommu_dma_alloc_rmr(u64 base, u64 length, u32 sid, u32 flags);
 
@@ -89,6 +91,11 @@ static inline void iommu_dma_free_cpu_cached_iovas(unsigned int cpu,
 {
 }
 
+static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
+					   struct list_head *list)
+{
+}
+
 int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
 {
 	return 0;
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:46 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:46 +0200
Subject: [PATCH v3 05/10] iommu/arm-smmu-v3: Introduce strtab init helper
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-6-shameerali.kolothum.thodi@huawei.com>

Introduce a helper to check the sid range and to init the l2 strtab
entries(bypass). This will be useful when we have to initialize the
l2 strtab with bypass for RMR SIDs.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 ++++++++++++---------
 1 file changed, 15 insertions(+), 11 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 8594b4a83043..29da3b681621 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2347,6 +2347,19 @@ static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
 
 static struct iommu_ops arm_smmu_ops;
 
+static int arm_smmu_init_sid_strtab(struct arm_smmu_device *smmu, u32 sid)
+{
+	/* Check the SIDs are in range of the SMMU and our stream table */
+	if (!arm_smmu_sid_in_range(smmu, sid))
+		return -ERANGE;
+
+	/* Ensure l2 strtab is initialised */
+	if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
+		return arm_smmu_init_l2_strtab(smmu, sid);
+
+	return 0;
+}
+
 static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 {
 	int i, ret;
@@ -2375,21 +2388,12 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
 	INIT_LIST_HEAD(&master->bonds);
 	dev_iommu_priv_set(dev, master);
 
-	/* Check the SIDs are in range of the SMMU and our stream table */
 	for (i = 0; i < master->num_sids; i++) {
 		u32 sid = master->sids[i];
 
-		if (!arm_smmu_sid_in_range(smmu, sid)) {
-			ret = -ERANGE;
+		ret = arm_smmu_init_sid_strtab(smmu, sid);
+		if (ret)
 			goto err_free_master;
-		}
-
-		/* Ensure l2 strtab is initialised */
-		if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
-			ret = arm_smmu_init_l2_strtab(smmu, sid);
-			if (ret)
-				goto err_free_master;
-		}
 	}
 
 	master->ssid_bits = min(smmu->ssid_bits, fwspec->num_pasid_bits);
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:47 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:47 +0200
Subject: [PATCH v3 06/10] =?UTF-8?q?iommu/arm-smmu-v3:=20Add=20bypass=20fl?=
 =?UTF-8?q?ag=20to=C2=A0arm=5Fsmmu=5Fwrite=5Fstrtab=5Fent()?=
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-7-shameerali.kolothum.thodi@huawei.com>

By default,?disable_bypass is set and any dev without an iommu domain
installs STE with CFG_ABORT during?arm_smmu_init_bypass_stes(). Introduce
a "bypass" flag to?arm_smmu_write_strtab_ent() so that we can force it to
install?CFG_BYPASS STE for specific SIDs. This will be?useful?for RMR
related SIDs.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 8 ++++----
 1 file changed, 4 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 29da3b681621..190285812182 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1176,7 +1176,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)
+				      __le64 *dst, bool bypass)
 {
 	/*
 	 * This is hideously complicated, but we only really care about
@@ -1247,7 +1247,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
 
 	/* Bypass/fault */
 	if (!smmu_domain || !(s1_cfg || s2_cfg)) {
-		if (!smmu_domain && disable_bypass)
+		if (!smmu_domain && disable_bypass && !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);
@@ -1322,7 +1322,7 @@ static void arm_smmu_init_bypass_stes(__le64 *strtab, unsigned int nent)
 	unsigned int i;
 
 	for (i = 0; i < nent; ++i) {
-		arm_smmu_write_strtab_ent(NULL, -1, strtab);
+		arm_smmu_write_strtab_ent(NULL, -1, strtab, false);
 		strtab += STRTAB_STE_DWORDS;
 	}
 }
@@ -2076,7 +2076,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_strtab_ent(master, sid, step, false);
 	}
 }
 
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:48 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:48 +0200
Subject: [PATCH v3 07/10] iommu/arm-smmu-v3: Get associated RMR info and
 install bypass STE
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-8-shameerali.kolothum.thodi@huawei.com>

Check if there is any RMR info associated?with the devices behind
the SMMUv3 and if any, install bypass STEs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMUv3 during probe().

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 35 +++++++++++++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  2 ++
 2 files changed, 37 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 190285812182..14e9c7034c04 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3530,6 +3530,37 @@ static void __iomem *arm_smmu_ioremap(struct device *dev, resource_size_t start,
 	return devm_ioremap_resource(dev, &res);
 }
 
+static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
+{
+	struct iommu_rmr *e;
+	int ret;
+
+	/*
+	 * Since, we don't have a mechanism to differentiate the RMR
+	 * SIDs that has an ongoing live stream, install bypass STEs
+	 * for all the reported ones.?
+	 */
+	list_for_each_entry(e, &smmu->rmr_list, list) {
+		__le64 *step;
+
+		ret = arm_smmu_init_sid_strtab(smmu, e->sid);
+		if (ret) {
+			dev_err(smmu->dev, "RMR bypass(0x%x) failed\n",
+				e->sid);
+			continue;
+		}
+
+		step = arm_smmu_get_step_for_sid(smmu, e->sid);
+		arm_smmu_write_strtab_ent(NULL, e->sid, step, true);
+	}
+}
+
+static int arm_smmu_get_rmr(struct arm_smmu_device *smmu)
+{
+	INIT_LIST_HEAD(&smmu->rmr_list);
+	return iommu_dma_get_rmrs(dev_fwnode(smmu->dev), &smmu->rmr_list);
+}
+
 static int arm_smmu_device_probe(struct platform_device *pdev)
 {
 	int irq, ret;
@@ -3613,6 +3644,10 @@ 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 */
+	if (!arm_smmu_get_rmr(smmu))
+		arm_smmu_rmr_install_bypass_ste(smmu);
+
 	/* Reset the device */
 	ret = arm_smmu_device_reset(smmu, bypass);
 	if (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 f985817c967a..e210fa81538a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -639,6 +639,8 @@ struct arm_smmu_device {
 
 	/* IOMMU core code handle */
 	struct iommu_device		iommu;
+
+	struct list_head		rmr_list;
 };
 
 /* SMMU private data for each master */
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:49 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:49 +0200
Subject: [PATCH v3 08/10] iommu/arm-smmu-v3: Reserve any RMR regions
 associated with a dev
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-9-shameerali.kolothum.thodi@huawei.com>

Get RMR regions associated with a dev?reserved so that there is
a unity mapping for them in?SMMU.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29 +++++++++++++++++++++
 1 file changed, 29 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 14e9c7034c04..8bacedf7bb34 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2531,6 +2531,34 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 	return iommu_fwspec_add_ids(dev, args->args, 1);
 }
 
+static bool arm_smmu_dev_has_rmr(struct arm_smmu_master *master,
+				 struct iommu_rmr *e)
+{
+	int i;
+
+	for (i = 0; i < master->num_sids; i++) {
+		if (e->sid == master->sids[i])
+			return true;
+	}
+
+	return false;
+}
+
+static void arm_smmu_rmr_get_resv_regions(struct device *dev,
+					  struct list_head *head)
+{
+	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
+	struct arm_smmu_device *smmu = master->smmu;
+	struct iommu_rmr *rmr;
+
+	list_for_each_entry(rmr, &smmu->rmr_list, list) {
+		if (!arm_smmu_dev_has_rmr(master, rmr))
+			continue;
+
+		iommu_dma_get_rmr_resv_regions(dev, rmr, head);
+	}
+}
+
 static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
@@ -2545,6 +2573,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 	list_add_tail(&region->list, head);
 
 	iommu_dma_get_resv_regions(dev, head);
+	arm_smmu_rmr_get_resv_regions(dev, head);
 }
 
 static bool arm_smmu_dev_has_feature(struct device *dev,
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:50 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:50 +0200
Subject: [PATCH v3 09/10] iommu/arm-smmu: Get associated RMR info and install
 bypass SMR
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-10-shameerali.kolothum.thodi@huawei.com>

From: Jon Nettleton <jon at solid-run.com>

Check if there is any RMR info associated?with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMU during probe().

Signed-off-by: Jon Nettleton <jon at solid-run.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 42 +++++++++++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index d8c6bfde6a61..4d2f91626d87 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -2102,6 +2102,43 @@ err_reset_platform_ops: __maybe_unused;
 	return err;
 }
 
+static void arm_smmu_rmr_install_bypass_smr(struct arm_smmu_device *smmu)
+{
+	struct iommu_rmr *e;
+	int i, cnt = 0;
+	u32 smr;
+
+	for (i = 0; i < smmu->num_mapping_groups; i++) {
+		smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
+		if (!FIELD_GET(ARM_SMMU_SMR_VALID, smr))
+			continue;
+
+		list_for_each_entry(e, &smmu->rmr_list, list) {
+			if (FIELD_GET(ARM_SMMU_SMR_ID, smr) != e->sid)
+				continue;
+
+			smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
+			smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
+			smmu->smrs[i].valid = true;
+
+			smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+			smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+			smmu->s2crs[i].cbndx = 0xff;
+
+			cnt++;
+		}
+	}
+
+	dev_notice(smmu->dev, "\tpreserved %d boot mapping%s\n", cnt,
+		   cnt == 1 ? "" : "s");
+}
+
+static int arm_smmu_get_rmr(struct arm_smmu_device *smmu)
+{
+	INIT_LIST_HEAD(&smmu->rmr_list);
+	return iommu_dma_get_rmrs(dev_fwnode(smmu->dev), &smmu->rmr_list);
+}
+
 static int arm_smmu_device_probe(struct platform_device *pdev)
 {
 	struct resource *res;
@@ -2231,6 +2268,11 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
 	}
 
 	platform_set_drvdata(pdev, smmu);
+
+	/* Check for RMRs and install bypass SMRs if any */
+	if (!arm_smmu_get_rmr(smmu))
+		arm_smmu_rmr_install_bypass_smr(smmu);
+
 	arm_smmu_device_reset(smmu);
 	arm_smmu_test_smr_masks(smmu);
 
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index d2a2d1bc58ba..ca9559eb8733 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -326,6 +326,8 @@ struct arm_smmu_device {
 
 	/* IOMMU core code handle */
 	struct iommu_device		iommu;
+
+	struct list_head		rmr_list;
 };
 
 enum arm_smmu_context_fmt {
-- 
2.17.1



From shameerali.kolothum.thodi at huawei.com  Tue Apr 20 09:27:51 2021
From: shameerali.kolothum.thodi at huawei.com (Shameer Kolothum)
Date: Tue, 20 Apr 2021 10:27:51 +0200
Subject: [PATCH v3 10/10] iommu/arm-smmu: Reserve any RMR regions associated
 with a dev
In-Reply-To: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210420082751.1829-11-shameerali.kolothum.thodi@huawei.com>

From: Jon Nettleton <jon at solid-run.com>

Get RMR regions associated with a dev?reserved so that there is
a unity mapping for them in?SMMU.

Signed-off-by: Jon Nettleton <jon at solid-run.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi at huawei.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 33 +++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 4d2f91626d87..8cbe8b98e8f0 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1591,6 +1591,38 @@ static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
 	return iommu_fwspec_add_ids(dev, &fwid, 1);
 }
 
+static bool arm_smmu_dev_has_rmr(struct arm_smmu_master_cfg *cfg,
+				 struct iommu_fwspec *fwspec,
+				 struct iommu_rmr *e)
+{
+	struct arm_smmu_device *smmu = cfg->smmu;
+	struct arm_smmu_smr *smrs = smmu->smrs;
+	int i, idx;
+
+	for_each_cfg_sme(cfg, fwspec, i, idx) {
+		if (e->sid == smrs[idx].id)
+			return true;
+	}
+
+	return false;
+}
+
+static void arm_smmu_rmr_get_resv_regions(struct device *dev,
+					  struct list_head *head)
+{
+	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 = cfg->smmu;
+	struct iommu_rmr *rmr;
+
+	list_for_each_entry(rmr, &smmu->rmr_list, list) {
+		if (!arm_smmu_dev_has_rmr(cfg, fwspec, rmr))
+			continue;
+
+		iommu_dma_get_rmr_resv_regions(dev, rmr, head);
+	}
+}
+
 static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
@@ -1605,6 +1637,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 	list_add_tail(&region->list, head);
 
 	iommu_dma_get_resv_regions(dev, head);
+	arm_smmu_rmr_get_resv_regions(dev, head);
 }
 
 static int arm_smmu_def_domain_type(struct device *dev)
-- 
2.17.1



From benjamin.gaignard at collabora.com  Tue Apr 20 10:31:16 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 11:31:16 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <43a767f8-77f5-7937-c484-753a3123f6a2@xs4all.nl>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
 <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
 <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>
 <36008691-d075-203d-0cac-2a012773ea34@collabora.com>
 <43a767f8-77f5-7937-c484-753a3123f6a2@xs4all.nl>
Message-ID: <e7064bb1-69e6-4214-380d-c464b7832da5@collabora.com>


Le 20/04/2021 ? 11:16, Hans Verkuil a ?crit?:
> On 20/04/2021 11:10, Benjamin Gaignard wrote:
>> Le 16/04/2021 ? 17:14, Lucas Stach a ?crit?:
>>> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>>>> Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
>>>>> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>>>>>> In order to be able to share the control hardware block between
>>>>>> VPUs use a syscon instead a ioremap it in the driver.
>>>>>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>>>>>> phandle is not found look at 'ctrl' reg-name.
>>>>>> With the method it becomes useless to provide a list of register
>>>>>> names so remove it.
>>>>> Sorry for putting a spoke in the wheel after many iterations of the
>>>>> series.
>>>>>
>>>>> We just discussed a way forward on how to handle the clocks and resets
>>>>> provided by the blkctl block on i.MX8MM and later and it seems there is
>>>>> a consensus on trying to provide virtual power domains from a blkctl
>>>>> driver, controlling clocks and resets for the devices in the power
>>>>> domain. I would like to avoid introducing yet another way of handling
>>>>> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
>>>>> what we are planning to do on the later chip generations.
>>>>>
>>>>> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
>>>>> virtual power domain thing a shot.
>>>> That could replace the 3 first patches and Dt patche of this series
>>>> but that will not impact the hevc part, so I wonder if pure hevc patches
>>>> could be merged anyway ?
>>>> They are reviewed and don't depend of how the ctrl block is managed.
>>> I'm not really in a position to give any informed opinion about that
>>> hvec patches, as I only skimmed them, but I don't see any reason to
>>> delay patches 04-11 from this series until the i.MX8M platform issues
>>> are sorted. AFAICS those things are totally orthogonal.
>> Hi Hans,
>> What do you think about this proposal to split this series ?
>> Get hevc part merged could allow me to continue to add features
>> like scaling lists, compressed reference buffers and 10-bit supports.
> Makes sense to me!

Great !
If the latest version match your expectations how would you like to processed ?
Can you merged patches 4 to 12 ? or should I resend them in a new shorted series ?

Regards,
Benjamin

>
> Regards,
>
> 	Hans
>


From catalin.marinas at arm.com  Tue Apr 20 10:35:59 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 20 Apr 2021 10:35:59 +0100
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory management
 model
Message-ID: <20210420093559.23168-1-catalin.marinas@arm.com>

Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
does not seem to boot in certain configurations (guest under KVM with
Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
pages) or 29 (64K page), there's little argument against the memory
wasted by the mem_map array with SPARSEMEM.

Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
remove the corresponding #ifdefs under arch/arm64/.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
---

If there are any concerns, please shout (but show numbers as well to
back it up).

 arch/arm64/Kconfig                      | 10 +---------
 arch/arm64/include/asm/kernel-pgtable.h |  2 +-
 arch/arm64/include/asm/memory.h         |  4 ++--
 arch/arm64/include/asm/sparsemem.h      |  3 ---
 arch/arm64/mm/init.c                    |  8 ++------
 arch/arm64/mm/mmu.c                     |  2 --
 arch/arm64/mm/ptdump.c                  |  2 --
 7 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9b4d629f7628..01c294035928 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,15 +1040,7 @@ source "kernel/Kconfig.hz"
 config ARCH_SPARSEMEM_ENABLE
 	def_bool y
 	select SPARSEMEM_VMEMMAP_ENABLE
-
-config ARCH_SPARSEMEM_DEFAULT
-	def_bool ARCH_SPARSEMEM_ENABLE
-
-config ARCH_SELECT_MEMORY_MODEL
-	def_bool ARCH_SPARSEMEM_ENABLE
-
-config ARCH_FLATMEM_ENABLE
-	def_bool !NUMA
+	select SPARSEMEM_VMEMMAP
 
 config HW_PERF_EVENTS
 	def_bool y
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index 587c504a4c8b..d44df9d62fc9 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -136,7 +136,7 @@
  * has a direct correspondence, and needs to appear sufficiently aligned
  * in the virtual address space.
  */
-#if defined(CONFIG_SPARSEMEM_VMEMMAP) && ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
+#if ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
 #define ARM64_MEMSTART_ALIGN	(1UL << SECTION_SIZE_BITS)
 #else
 #define ARM64_MEMSTART_ALIGN	(1UL << ARM64_MEMSTART_SHIFT)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b943879c1c24..15018dc59554 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -329,7 +329,7 @@ static inline void *phys_to_virt(phys_addr_t x)
  */
 #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
 
-#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
+#if defined(CONFIG_DEBUG_VIRTUAL)
 #define page_to_virt(x)	({						\
 	__typeof__(x) __page = x;					\
 	void *__addr = __va(page_to_phys(__page));			\
@@ -349,7 +349,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 	u64 __addr = VMEMMAP_START + (__idx * sizeof(struct page));	\
 	(struct page *)__addr;						\
 })
-#endif /* !CONFIG_SPARSEMEM_VMEMMAP || CONFIG_DEBUG_VIRTUAL */
+#endif /* CONFIG_DEBUG_VIRTUAL */
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h
index eb4a75d720ed..4b73463423c3 100644
--- a/arch/arm64/include/asm/sparsemem.h
+++ b/arch/arm64/include/asm/sparsemem.h
@@ -5,7 +5,6 @@
 #ifndef __ASM_SPARSEMEM_H
 #define __ASM_SPARSEMEM_H
 
-#ifdef CONFIG_SPARSEMEM
 #define MAX_PHYSMEM_BITS	CONFIG_ARM64_PA_BITS
 
 /*
@@ -27,6 +26,4 @@
 #define SECTION_SIZE_BITS 27
 #endif /* CONFIG_ARM64_64K_PAGES */
 
-#endif /* CONFIG_SPARSEMEM*/
-
 #endif
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..a205538aa1d5 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -220,6 +220,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
 int pfn_valid(unsigned long pfn)
 {
 	phys_addr_t addr = PFN_PHYS(pfn);
+	struct mem_section *ms;
 
 	/*
 	 * Ensure the upper PAGE_SHIFT bits are clear in the
@@ -230,10 +231,6 @@ int pfn_valid(unsigned long pfn)
 	if (PHYS_PFN(addr) != pfn)
 		return 0;
 
-#ifdef CONFIG_SPARSEMEM
-{
-	struct mem_section *ms;
-
 	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
 		return 0;
 
@@ -252,8 +249,7 @@ int pfn_valid(unsigned long pfn)
 	 */
 	if (!early_section(ms))
 		return pfn_section_valid(ms, pfn);
-}
-#endif
+
 	return memblock_is_map_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index fac957ff5187..af0ebcad3e1f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1113,7 +1113,6 @@ static void free_empty_tables(unsigned long addr, unsigned long end,
 }
 #endif
 
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
 #if !ARM64_SWAPPER_USES_SECTION_MAPS
 int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 		struct vmem_altmap *altmap)
@@ -1177,7 +1176,6 @@ void vmemmap_free(unsigned long start, unsigned long end,
 	free_empty_tables(start, end, VMEMMAP_START, VMEMMAP_END);
 #endif
 }
-#endif	/* CONFIG_SPARSEMEM_VMEMMAP */
 
 static inline pud_t *fixmap_pud(unsigned long addr)
 {
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index a50e92ea1878..a1937dfff31c 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -51,10 +51,8 @@ static struct addr_marker address_markers[] = {
 	{ FIXADDR_TOP,			"Fixmap end" },
 	{ PCI_IO_START,			"PCI I/O start" },
 	{ PCI_IO_END,			"PCI I/O end" },
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
 	{ VMEMMAP_START,		"vmemmap start" },
 	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
-#endif
 	{ -1,				NULL },
 };
 


From pali at kernel.org  Tue Apr 20 10:44:02 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Tue, 20 Apr 2021 11:44:02 +0200
Subject: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
In-Reply-To: <20210420061723.989-6-jianjun.wang@mediatek.com>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
 <20210420061723.989-6-jianjun.wang@mediatek.com>
Message-ID: <20210420094402.hwdkbspl5wu4rtex@pali>

Hello!

On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote:
> +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> +{
> +	int i;
> +	u32 val;
> +
> +	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
> +		struct mtk_msi_set *msi_set = &port->msi_sets[i];
> +
> +		msi_set->base = port->base + PCIE_MSI_SET_BASE_REG +
> +				i * PCIE_MSI_SET_OFFSET;
> +		msi_set->msg_addr = port->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),
> +			       port->base + PCIE_MSI_SET_ADDR_HI_BASE +
> +			       i * PCIE_MSI_SET_ADDR_HI_OFFSET);

This looks like as setting MSI doorbell address to MSI doorbell address.

> +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> +	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
> +	struct mtk_pcie_port *port = data->domain->host_data;
> +	unsigned long hwirq;
> +
> +	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
> +
> +	msg->address_hi = upper_32_bits(msi_set->msg_addr);
> +	msg->address_lo = lower_32_bits(msi_set->msg_addr);
> +	msg->data = hwirq;
> +	dev_dbg(port->dev, "msi#%#lx address_hi %#x address_lo %#x data %d\n",
> +		hwirq, msg->address_hi, msg->address_lo, msg->data);

... which is later used in compose_msi_msg().

Marc in some other patches for other pci controller drivers changed this
address to just main "port" structure. It simplified implementations and
also avoided need to declare additional member "msg_addr".

Marc, would it be possible to simplify it also for this driver and just
set msg_addr to virt_to_phys(port)?


From john.garry at huawei.com  Tue Apr 20 10:45:46 2021
From: john.garry at huawei.com (John Garry)
Date: Tue, 20 Apr 2021 10:45:46 +0100
Subject: [PATCH v3 2/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <1618490885-44612-3-git-send-email-liuqi115@huawei.com>
References: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
 <1618490885-44612-3-git-send-email-liuqi115@huawei.com>
Message-ID: <778f067e-9ad1-a84f-807d-09fc6f143032@huawei.com>

On 15/04/2021 13:48, Qi Liu wrote:
> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
> to sample bandwidth, latency, buffer occupation etc.
> 
> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
> registered as a PMU in /sys/bus/event_source/devices, so users can
> select target PMU, and use filter to do further sets.
> 
> Filtering options contains:
> event        - select the event.
> subevent     - select the subevent.
> port         - select target Root Ports. Information of Root Ports
>                 are shown under sysfs.
> bdf          - select requester_id of target EP device.
> trig_len     - set trigger condition for starting event statistics.
> trigger_mode - set trigger mode. 0 means starting to statistic when
>                 bigger than trigger condition, and 1 means smaller.
> thr_len      - set threshold for statistics.
> thr_mode     - set threshold mode. 0 means count when bigger than
>                 threshold, and 1 means smaller.
> 
> Signed-off-by: Qi Liu <liuqi115 at huawei.com>

Some minor items and nits with coding style below, but generally looks ok:

Reviewed-by: John Garry <john.garry at huawei.com>

> ---
>   MAINTAINERS                                |    6 +
>   drivers/perf/Kconfig                       |    2 +
>   drivers/perf/Makefile                      |    1 +
>   drivers/perf/pci/Kconfig                   |   16 +
>   drivers/perf/pci/Makefile                  |    2 +
>   drivers/perf/pci/hisilicon/Makefile        |    3 +
>   drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1014 ++++++++++++++++++++++++++++
>   include/linux/cpuhotplug.h                 |    1 +
>   8 files changed, 1045 insertions(+)
>   create mode 100644 drivers/perf/pci/Kconfig
>   create mode 100644 drivers/perf/pci/Makefile
>   create mode 100644 drivers/perf/pci/hisilicon/Makefile
>   create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7fdc513..efe06cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8084,6 +8084,12 @@ W:	http://www.hisilicon.com
>   F:	Documentation/admin-guide/perf/hisi-pmu.rst
>   F:	drivers/perf/hisilicon
>   
> +HISILICON PCIE PMU DRIVER
> +M:	Qi Liu <liuqi115 at huawei.com>
> +S:	Maintained
> +F:	Documentation/admin-guide/perf/hisi-pcie-pmu.rst
> +F:	drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> +
>   HISILICON QM AND ZIP Controller DRIVER
>   M:	Zhou Wang <wangzhou1 at hisilicon.com>
>   L:	linux-crypto at vger.kernel.org
> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> index 77522e5..ddd82fa 100644
> --- a/drivers/perf/Kconfig
> +++ b/drivers/perf/Kconfig
> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>   
>   source "drivers/perf/hisilicon/Kconfig"
>   
> +source "drivers/perf/pci/Kconfig"
> +
>   endmenu
> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> index 5260b11..1208c08 100644
> --- a/drivers/perf/Makefile
> +++ b/drivers/perf/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>   obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>   obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>   obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
> +obj-y += pci/
> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
> new file mode 100644
> index 0000000..9f30291
> --- /dev/null
> +++ b/drivers/perf/pci/Kconfig
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# PCIe Performance Monitor Drivers
> +#
> +menu "PCIe Performance Monitor"
> +
> +config HISI_PCIE_PMU
> +	tristate "HiSilicon PCIE PERF PMU"
> +	depends on (ARM64 && PCI) || COMPILE_TEST
> +	help
> +	  Provide support for HiSilicon PCIe performance monitoring unit (PMU)
> +	  RCiEP devices.
> +	  Adds the PCIe PMU into perf events system for monitoring latency,
> +	  bandwidth etc.
> +
> +endmenu
> diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
> new file mode 100644
> index 0000000..a56b1a9
> --- /dev/null
> +++ b/drivers/perf/pci/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y += hisilicon/
> diff --git a/drivers/perf/pci/hisilicon/Makefile b/drivers/perf/pci/hisilicon/Makefile
> new file mode 100644
> index 0000000..65b0bd7
> --- /dev/null
> +++ b/drivers/perf/pci/hisilicon/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
> diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> new file mode 100644
> index 0000000..415bf39
> --- /dev/null
> +++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
> @@ -0,0 +1,1014 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * This driver adds support for PCIe PMU RCiEP device. Related
> + * perf events are bandwidth, bandwidth utilization, latency
> + * etc.
> + *
> + * Copyright (C) 2021 HiSilicon Limited
> + * Author: Qi Liu<liuqi115 at huawei.com>
> + */
> +#include <linux/bitfield.h>
> +#include <linux/bitmap.h>
> +#include <linux/bug.h>
> +#include <linux/cpuhotplug.h>
> +#include <linux/cpumask.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/perf_event.h>
> +
> +/* Define registers */
> +#define HISI_PCIE_GLOBAL_CTRL		0x00
> +#define HISI_PCIE_EVENT_CTRL		0x010
> +#define HISI_PCIE_CNT			0x090
> +#define HISI_PCIE_EXT_CNT		0x110
> +#define HISI_PCIE_INT_STAT		0x150
> +#define HISI_PCIE_INT_MASK		0x154
> +#define HISI_PCIE_REG_BDF		0xfe0
> +#define HISI_PCIE_REG_VERSION		0xfe4
> +#define HISI_PCIE_REG_INFO		0xfe8
> +#define HISI_PCIE_REG_FREQ		0xfec
> +
> +/* Define PCIE CTRL CMD */
> +#define HISI_PCIE_GLOBAL_EN		0x01
> +#define HISI_PCIE_GLOBAL_NONE		0
> +#define HISI_PCIE_EVENT_EN		BIT(20)
> +#define HISI_PCIE_RESET_CNT		BIT(22)
> +#define HISI_PCIE_DEFAULT_SET		BIT(34)
> +#define HISI_PCIE_THR_EN		BIT(26)
> +#define HISI_PCIE_TARGET_EN		BIT(32)
> +#define HISI_PCIE_TRIG_EN		BIT(52)
> +
> +/* Define offsets in event ctrl regesiter */
> +#define HISI_PCIE_EVENT_M		GENMASK_ULL(7, 0)
> +#define HISI_PCIE_SUBEVENT_M		GENMASK_ULL(15, 8)
> +#define HISI_PCIE_THR_MODE_M		GENMASK_ULL(27, 27)
> +#define HISI_PCIE_THR_M			GENMASK_ULL(31, 28)
> +#define HISI_PCIE_TARGET_M		GENMASK_ULL(52, 36)
> +#define HISI_PCIE_TRIG_MODE_M		GENMASK_ULL(53, 53)
> +#define HISI_PCIE_TRIG_M		GENMASK_ULL(59, 56)
> +
> +#define HISI_PCIE_MAX_COUNTERS		8
> +#define HISI_PCIE_REG_STEP		8
> +#define HISI_PCIE_EVENT_MAX		0xa2
> +#define HISI_PCIE_SUBEVENT_MAX		0x20
> +#define HISI_PCIE_THR_MAX_VAL		10
> +#define HISI_PCIE_TRIG_MAX_VAL		10
> +#define HISI_PCIE_COUNTER_BITS		64
> +#define HISI_PCIE_MAX_PERIOD		BIT_ULL(63)
> +
> +struct hisi_pcie_pmu {
> +	struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
> +	struct hlist_node node;
> +	struct pci_dev *pdev;
> +	struct pmu pmu;
> +	void __iomem *base;
> +	int irq;
> +	u32 identifier;
> +	/* Minimum and maximum bdf of root ports monitored by PMU */
> +	u16 bdf_min;
> +	u16 bdf_max;
> +	int on_cpu;
> +};
> +
> +#define to_pcie_pmu(p)  (container_of((p), struct hisi_pcie_pmu, pmu))
> +#define GET_PCI_DEVFN(bdf)  ((bdf) & 0xff)
> +
> +#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)		  \
> +	static u64 hisi_pcie_get_##_name(struct perf_event *event)	  \
> +	{								  \
> +		return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
> +	}								  \
> +
> +HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
> +HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
> +HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
> +HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
> +HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
> +HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
> +
> +#define HISI_PCIE_BUILD_EVENTS(name)				     	\
> +	static bool is_##name##_event(u32 idx)				\
> +	{								\
> +		return (idx >= name##_events_list[0] &&			\
> +			idx <= name##_events_list[1]) ||		\
> +			idx == name##_events_list[2]; 			\
> +	}								\
> +
> +/*
> + * The first element of event list is minimum index of TL-layer events
> + * and the second element is maximum index. The third element is index
> + * of a DL-layer event.
> + */
> +static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
> +static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
> +static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
> +static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
> +
> +HISI_PCIE_BUILD_EVENTS(bw);
> +HISI_PCIE_BUILD_EVENTS(latency);
> +HISI_PCIE_BUILD_EVENTS(bus_util);
> +HISI_PCIE_BUILD_EVENTS(buf_util);
> +
> +static ssize_t hisi_pcie_format_sysfs_show(struct device *dev,
> +				    struct device_attribute *attr, char *buf)
> +{
> +	struct dev_ext_attribute *eattr;
> +
> +	eattr = container_of(attr, struct dev_ext_attribute, attr);
> +
> +	return sysfs_emit(buf, "%s\n", (char *)eattr->var);
> +}
> +
> +static ssize_t hisi_pcie_event_sysfs_show(struct device *dev,
> +				   struct device_attribute *attr, char *buf)
> +{
> +	struct dev_ext_attribute *eattr;
> +
> +	eattr = container_of(attr, struct dev_ext_attribute, attr);
> +
> +	return sysfs_emit(buf, "config=0x%lx\n", (unsigned long)eattr->var);
> +}

As before, I hope that we can have common versions of these function for 
all drivers in future

> +
> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +
> +	event->cpu = pcie_pmu->on_cpu;
> +
> +	if (event->attr.type != event->pmu->type)
> +		return -ENOENT;
> +
> +	/* Sampling is not supported. */
> +	if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> +		return -EOPNOTSUPP;
> +
> +	if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
> +		pci_err(pcie_pmu->pdev, "Invalid filter!\n");
> +		return -EINVAL;
> +	}
> +
> +	if (!hisi_pcie_pmu_validate_event_group(event))
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +

again, if this is generic, then can factor out later

> +/*
> + * The bandwidth, latency, bus utilization and buffer occupancy features are
> + * calculated from data in HISI_PCIE_CNT and extern data in HISI_PCIE_EXT_CNT.

extern data? or extended data?

> + * Other features are obtained only by HISI_PCIE_CNT.
> + * So data and data_ext are processed in this function to get performanace
> + * value like, bandwidth, latency, etc.
> + */
> +static u64 hisi_pcie_pmu_get_performance(struct perf_event *event, u64 data,
> +					 u64 data_ext)
> +{
> +#define CONVERT_DW_TO_BYTE(x)	(sizeof(u32) * (x))
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
> +	u32 idx = hisi_pcie_get_event(event);
> +
> +	if (!data_ext)
> +		return 0;
> +
> +	/* Process data to set unit of bandwidth as "Byte/ms". */
> +	if (is_bw_event(idx)) {

ideally we could use a switch statement here, but with how macro 
is_bw_event is defined, doesn't seem possible

> +		if (!data_ext / 1000)
> +			return 0;
> +
> +		return (CONVERT_DW_TO_BYTE(data)) / (data_ext / 1000);
> +	}
> +
> +	/* Process data to set unit of latency as "us". */
> +	if (is_latency_event(idx))
> +		return (data * us_per_cycle) / data_ext;
> +
> +	if (is_bus_util_event(idx))
> +		return (data * us_per_cycle) / data_ext;
> +
> +	if (is_buf_util_event(idx))
> +		return data / (data_ext * us_per_cycle);
> +
> +	return data;
> +}
> +
> +static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 *cnt,
> +				       u64 *cnt_ext)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u32 idx = event->hw.idx;
> +
> +	*cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
> +	*cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
> +}
> +
> +static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 val,
> +					u64 val_ext)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
> +	u32 idx = event->hw.idx;
> +
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
> +	hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
> +}
> +
> +static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	int idx;
> +
> +	for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
> +		if (!pcie_pmu->hw_events[idx])
> +			return idx;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static void hisi_pcie_pmu_event_update(struct perf_event *event)
> +{
> +	struct hw_perf_event *hwc = &event->hw;
> +	struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
> +	u64 new_cnt_ext, prev_cnt_ext;
> +	u64 new_cnt, prev_cnt, delta;
> +
> +	hwc_ext = &hwc->extra_reg;
> +	do {
> +		prev_cnt = local64_read(&hwc->prev_count);
> +		prev_cnt_ext = hwc_ext->config;
> +		hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
> +	} while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
> +				 new_cnt) != prev_cnt);
> +
> +	hwc_ext->config = new_cnt_ext;
> +
> +	delta = hisi_pcie_pmu_get_performance(event, new_cnt - prev_cnt,
> +					      new_cnt_ext - prev_cnt_ext);
> +	local64_add(delta, &event->count);
> +}

...

> +
> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct hlist_node *node)
> +{
> +	struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
> +					 struct hisi_pcie_pmu, node);
> +	unsigned int target;
> +
> +	/* Nothing to do if this CPU doesn't own the PMU */
> +	if (pcie_pmu->on_cpu != cpu)
> +		return 0;
> +
> +	/* Choose a new CPU from all online cpus. */
> +	target = cpumask_any_but(cpu_online_mask, cpu);

I don't think cpu would ever be involved in cpu_online_mask at this 
point. Not sure.

> +	if (target >= nr_cpu_ids)
> +		return 0;

might be worth an error message if this fails ...

> +
> +	perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
> +	/* Use this CPU for event counting */
> +	pcie_pmu->on_cpu = target;
> +	WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
> +
> +	return 0;
> +}
> +
> +/*
> + * Events with the "dl" suffix in their names count performance in DL layer,
> + * otherswise, events count performance in TL layer.
> + */
> +static struct attribute *hisi_pcie_pmu_events_attr[] = {
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
> +	HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
> +	HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
> +	HISI_PCIE_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
> +	HISI_PCIE_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
> +	HISI_PCIE_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_events_group = {
> +	.name = "events",
> +	.attrs = hisi_pcie_pmu_events_attr,
> +};
> +
> +static struct attribute *hisi_pcie_pmu_format_attr[] = {
> +	HISI_PCIE_PMU_FORMAT_ATTR(event, "config:0-7"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(subevent, "config:8-15"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(port, "config2:0-15"),
> +	HISI_PCIE_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_format_group = {
> +	.name = "format",
> +	.attrs = hisi_pcie_pmu_format_attr,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_bus_attr =
> +	__ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
> +	&hisi_pcie_pmu_bus_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
> +	.attrs = hisi_pcie_pmu_bus_attrs,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_cpumask_attr =
> +	__ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
> +	&hisi_pcie_pmu_cpumask_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
> +	.attrs = hisi_pcie_pmu_cpumask_attrs,
> +};
> +
> +static struct device_attribute hisi_pcie_pmu_identifier_attr =
> +	__ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
> +
> +static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
> +	&hisi_pcie_pmu_identifier_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
> +	.attrs = hisi_pcie_pmu_identifier_attrs,
> +};
> +
> +static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
> +	&hisi_pcie_pmu_events_group,
> +	&hisi_pcie_pmu_format_group,
> +	&hisi_pcie_pmu_bus_attr_group,
> +	&hisi_pcie_pmu_cpumask_attr_group,
> +	&hisi_pcie_pmu_identifier_attr_group,
> +	NULL
> +};
> +
> +static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
> +			     struct hisi_pcie_pmu *pcie_pmu)
> +{
> +	u16 sicl_id, device_id;
> +	char *name;
> +
> +	pcie_pmu->base = pci_ioremap_bar(pdev, 2);
> +	if (!pcie_pmu->base) {
> +		pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
> +		return -ENOMEM;
> +	}

nit: this does not seem related to "alloc" functionality

> +
> +	hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_BDF,
> +				  &pcie_pmu->bdf_min, &pcie_pmu->bdf_max);
> +	hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
> +				  &sicl_id);
> +	name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
> +			      "hisi_pcie%u_%u", sicl_id, device_id);
> +	if (!name)
> +		return -ENOMEM;
> +
> +	pcie_pmu->pdev = pdev;
> +	pcie_pmu->on_cpu = -1;
> +	pcie_pmu->identifier = readl(pcie_pmu->base + HISI_PCIE_REG_VERSION);
> +	pcie_pmu->pmu = (struct pmu) {
> +		.name		= name,
> +		.module		= THIS_MODULE,
> +		.event_init	= hisi_pcie_pmu_event_init,
> +		.pmu_enable	= hisi_pcie_pmu_enable,
> +		.pmu_disable	= hisi_pcie_pmu_disable,
> +		.add		= hisi_pcie_pmu_add,
> +		.del		= hisi_pcie_pmu_del,
> +		.start		= hisi_pcie_pmu_start,
> +		.stop		= hisi_pcie_pmu_stop,
> +		.read		= hisi_pcie_pmu_read,
> +		.task_ctx_nr	= perf_invalid_context,
> +		.attr_groups	= hisi_pcie_pmu_attr_groups,
> +		.capabilities	= PERF_PMU_CAP_NO_EXCLUDE,
> +	};
> +
> +	return 0;
> +}
> +



From u.kleine-koenig at pengutronix.de  Tue Apr 20 10:51:18 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 20 Apr 2021 11:51:18 +0200
Subject: [PATCH 2/2] pwm: atmel: Improve duty cycle calculation in .apply()
In-Reply-To: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210420095118.1571344-2-u.kleine-koenig@pengutronix.de>

In the calculation of the register value determining the duty cycle the
requested period is used instead of the actually implemented period which
results in suboptimal settings.

The following example assumes an input clock of 133333333 Hz on one of
the SoCs with 16 bit period.

When the following state is to be applied:

        .period = 414727681
        .duty_cycle = 652806

the following register values used to be  calculated:

        PRES = 10
        CPRD = 54000
        CDTY = 53916

which yields an actual duty cycle of a bit more than 645120 ns.

The setting

        PRES = 10
        CPRD = 54000
        CDTY = 53915

however yields a duty of 652800 ns which is between the current result
and the requested value and so is a better approximation.

The reason for this error is that for the calculation of CDTY the
requested period was used instead of the actually implemented one.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index ebaeb50dcfde..29b5ad03f715 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -124,6 +124,7 @@ static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
 }
 
 static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
+					     unsigned long clkrate,
 					     const struct pwm_state *state,
 					     unsigned long *cprd, u32 *pres)
 {
@@ -132,7 +133,7 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
 	int shift;
 
 	/* Calculate the period cycles and prescale value */
-	cycles *= clk_get_rate(atmel_pwm->clk);
+	cycles *= clkrate;
 	do_div(cycles, NSEC_PER_SEC);
 
 	/*
@@ -158,12 +159,14 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
 }
 
 static void atmel_pwm_calculate_cdty(const struct pwm_state *state,
-				     unsigned long cprd, unsigned long *cdty)
+				     unsigned long clkrate, unsigned long cprd,
+				     u32 pres, unsigned long *cdty)
 {
 	unsigned long long cycles = state->duty_cycle;
 
-	cycles *= cprd;
-	do_div(cycles, state->period);
+	cycles *= clkrate;
+	do_div(cycles, NSEC_PER_SEC);
+	cycles >>= pres;
 	*cdty = cprd - cycles;
 }
 
@@ -244,17 +247,23 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	pwm_get_state(pwm, &cstate);
 
 	if (state->enabled) {
+		unsigned long clkrate = clk_get_rate(atmel_pwm->clk);
+
 		if (cstate.enabled &&
 		    cstate.polarity == state->polarity &&
 		    cstate.period == state->period) {
+			u32 cmr = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, PWM_CMR);
+
 			cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
 						  atmel_pwm->data->regs.period);
-			atmel_pwm_calculate_cdty(state, cprd, &cdty);
+			pres = cmr & PWM_CMR_CPRE_MSK;
+
+			atmel_pwm_calculate_cdty(state, clkrate, cprd, pres, &cdty);
 			atmel_pwm_update_cdty(chip, pwm, cdty);
 			return 0;
 		}
 
-		ret = atmel_pwm_calculate_cprd_and_pres(chip, state, &cprd,
+		ret = atmel_pwm_calculate_cprd_and_pres(chip, clkrate, state, &cprd,
 							&pres);
 		if (ret) {
 			dev_err(chip->dev,
@@ -262,7 +271,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			return ret;
 		}
 
-		atmel_pwm_calculate_cdty(state, cprd, &cdty);
+		atmel_pwm_calculate_cdty(state, clkrate, cprd, pres, &cdty);
 
 		if (cstate.enabled) {
 			atmel_pwm_disable(chip, pwm, false);
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Tue Apr 20 10:51:17 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue, 20 Apr 2021 11:51:17 +0200
Subject: [PATCH 1/2] pwm: atmel: Fix duty cycle calculation in .get_state()
Message-ID: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>

The CDTY register contains the number of inactive cycles. .apply() does
this correctly, however .get_state() got this wrong.

Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()")
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index d49da708337f..ebaeb50dcfde 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -319,7 +319,7 @@ static void atmel_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
 
 		cdty = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
 					  atmel_pwm->data->regs.duty);
-		tmp = (u64)cdty * NSEC_PER_SEC;
+		tmp = (u64)(cprd - cdty) * NSEC_PER_SEC;
 		tmp <<= pres;
 		state->duty_cycle = DIV64_U64_ROUND_UP(tmp, rate);
 
-- 
2.30.2



From arnd at arndb.de  Tue Apr 20 11:18:14 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 20 Apr 2021 12:18:14 +0200
Subject: [GIT PULL] ARM: bmc: devicetree changes for 5.13, v2
In-Reply-To: <CACPK8XfkSQpMz9J+8xN7DP9Wabv=+DAgmX6NGL9742Ss3HsehA@mail.gmail.com>
References: <CACPK8Xeet50bqWAY0jG_GRkgvKvFn94XtGDaq1gaVYVkyV_JUQ@mail.gmail.com>
 <CAK8P3a1rG6qKjVvr86G=6cgkhReQUbsvQAkdxg7A2HsJ7n499A@mail.gmail.com>
 <CACPK8XfkSQpMz9J+8xN7DP9Wabv=+DAgmX6NGL9742Ss3HsehA@mail.gmail.com>
Message-ID: <CAK8P3a0OJhjF4R1zCm0jD_MUiS8TeDR2x9wTsTC5Apr5Mq_fSg@mail.gmail.com>

On Tue, Apr 20, 2021 at 9:11 AM Joel Stanley <joel at jms.id.au> wrote:
>
> On Mon, 19 Apr 2021 at 14:44, Arnd Bergmann <arnd at arndb.de> wrote:
> >
> > On Fri, Apr 16, 2021 at 5:27 AM Joel Stanley <joel at jms.id.au> wrote:
> > >
> > > Hello Soc maintainers,
> > >
> > > Here are some fixes for the changes that have already been merged for v5.13.
> > >
> > > I also merged some changes that came in later. If you would prefer to
> > > not take them then I can send a pull with just the fixes.
> > >
> > > The following changes since commit f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:
> > >
> > > for you to fetch changes up to f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2:
> >
> > Hi Joel,
> >
> > something about this pull request doesn't add up, and 'b4' refuses
> > to pull it since the 'since commit f0145db2' and 'up to f0145db2'
> > references refer to the same commit.
> >
> > I assume this is just a copy-paste error on your end, but it would
> > be nice if you could double-check and resend the pull request
> > based on the ee33e2fb3d70 commit that I merged.
>
> Nice catch. It looks I've generated pull requests incorrectly from
> v5.5 onwards, and this is the first time we've noticed. My bash
> history shows I started generating them like this:
>
>  git request-pull tag url tag

Ah right. I'm surprised this resulted in the correct shortlog
and diffstat, but that clearly explains it.

> I'll try sending this one again now.

I only started using b4 recently, so I wouldn't have caught it in the past,
as I wasn't paying close attention to the commit hashes. I usually
tried to ensure that the contents match up with the description, and
that worked fine. I've had sporadic problems in the past with b4 and
it's possible that I just papered over it with a manual merge thinking
that I did something wrong instead of b4 pointing out an actual
problem.

      Arnd


From will at kernel.org  Tue Apr 20 11:19:48 2021
From: will at kernel.org (Will Deacon)
Date: Tue, 20 Apr 2021 11:19:48 +0100
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420093559.23168-1-catalin.marinas@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
Message-ID: <20210420101947.GA31723@willie-the-truck>

On Tue, Apr 20, 2021 at 10:35:59AM +0100, Catalin Marinas wrote:
> Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> does not seem to boot in certain configurations (guest under KVM with
> Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> pages) or 29 (64K page), there's little argument against the memory
> wasted by the mem_map array with SPARSEMEM.
> 
> Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
> remove the corresponding #ifdefs under arch/arm64/.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> ---
> 
> If there are any concerns, please shout (but show numbers as well to
> back it up).
> 
>  arch/arm64/Kconfig                      | 10 +---------
>  arch/arm64/include/asm/kernel-pgtable.h |  2 +-
>  arch/arm64/include/asm/memory.h         |  4 ++--
>  arch/arm64/include/asm/sparsemem.h      |  3 ---
>  arch/arm64/mm/init.c                    |  8 ++------
>  arch/arm64/mm/mmu.c                     |  2 --
>  arch/arm64/mm/ptdump.c                  |  2 --
>  7 files changed, 6 insertions(+), 25 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From ardb at kernel.org  Tue Apr 20 11:28:57 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 20 Apr 2021 12:28:57 +0200
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420101947.GA31723@willie-the-truck>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
 <20210420101947.GA31723@willie-the-truck>
Message-ID: <CAMj1kXGXwzDo45TYp7y7OnHYwH9CJMyUWd+PA0YZ5tk6GoKs8Q@mail.gmail.com>

On Tue, 20 Apr 2021 at 12:19, Will Deacon <will at kernel.org> wrote:
>
> On Tue, Apr 20, 2021 at 10:35:59AM +0100, Catalin Marinas wrote:
> > Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> > SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> > does not seem to boot in certain configurations (guest under KVM with
> > Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> > pages) or 29 (64K page), there's little argument against the memory
> > wasted by the mem_map array with SPARSEMEM.
> >
> > Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
> > remove the corresponding #ifdefs under arch/arm64/.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > ---
> >
> > If there are any concerns, please shout (but show numbers as well to
> > back it up).
> >
> >  arch/arm64/Kconfig                      | 10 +---------
> >  arch/arm64/include/asm/kernel-pgtable.h |  2 +-
> >  arch/arm64/include/asm/memory.h         |  4 ++--
> >  arch/arm64/include/asm/sparsemem.h      |  3 ---
> >  arch/arm64/mm/init.c                    |  8 ++------
> >  arch/arm64/mm/mmu.c                     |  2 --
> >  arch/arm64/mm/ptdump.c                  |  2 --
> >  7 files changed, 6 insertions(+), 25 deletions(-)
>
> Acked-by: Will Deacon <will at kernel.org>
>

Acked-by: Ard Biesheuvel <ardb at kernel.org>


From vkoul at kernel.org  Tue Apr 20 11:32:27 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Tue, 20 Apr 2021 16:02:27 +0530
Subject: [PATCH v2 -next] dmaengine: at_xdmac: Remove unused inline
 function at_xdmac_csize()
In-Reply-To: <20210407132543.23652-1-yuehaibing@huawei.com>
References: <20210407132543.23652-1-yuehaibing@huawei.com>
Message-ID: <YH6tu6hF5Vo1Ofh+@vkoul-mobl.Dlink>

On 07-04-21, 21:25, YueHaibing wrote:
> commit 765c37d87669 ("dmaengine: at_xdmac: rework slave configuration part")
> left behind this, so can remove it.

Applied, thanks

-- 
~Vinod


From maz at kernel.org  Tue Apr 20 11:47:31 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 11:47:31 +0100
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420093559.23168-1-catalin.marinas@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
Message-ID: <87czupqlks.wl-maz@kernel.org>

On Tue, 20 Apr 2021 10:35:59 +0100,
Catalin Marinas <catalin.marinas at arm.com> wrote:
> 
> Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> does not seem to boot in certain configurations (guest under KVM with
> Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> pages) or 29 (64K page), there's little argument against the memory
> wasted by the mem_map array with SPARSEMEM.
> 
> Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
> remove the corresponding #ifdefs under arch/arm64/.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Acked-by: Marc Zyngier <maz at kernel.org>

	M.

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


From grygorii.strashko at ti.com  Tue Apr 20 11:50:30 2021
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Tue, 20 Apr 2021 13:50:30 +0300
Subject: [PATCHv2] gpio: omap: Save and restore sysconfig
In-Reply-To: <20210417083839.46985-1-tony@atomide.com>
References: <20210417083839.46985-1-tony@atomide.com>
Message-ID: <7679127b-3642-bca2-2c6c-86b60779d815@ti.com>

hi Tony,

On 17/04/2021 11:38, Tony Lindgren wrote:
> As we are using cpu_pm to save and restore context, we must also save and
> restore the GPIO sysconfig register. This is needed because we are not
> calling PM runtime functions at all with cpu_pm.
> 
> We need to save the sysconfig on idle as it's value can get reconfigured by
> PM runtime and can be different from the init time value. Device specific
> flags like "ti,no-idle-on-init" can affect the init value.
> 
> Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
> Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
> Cc: Adam Ford <aford173 at gmail.com>
> Cc: Andreas Kemnade <andreas at kemnade.info>
> Cc: Grygorii Strashko <grygorii.strashko at ti.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>   drivers/gpio/gpio-omap.c                | 9 +++++++++
>   include/linux/platform_data/gpio-omap.h | 3 +++
>   2 files changed, 12 insertions(+)
> 

Thank you.
Acked-by: Grygorii Strashko <grygorii.strashko at ti.com>

-- 
Best regards,
grygorii


From maz at kernel.org  Tue Apr 20 12:01:10 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 12:01:10 +0100
Subject: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
In-Reply-To: <20210420094402.hwdkbspl5wu4rtex@pali>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
 <20210420061723.989-6-jianjun.wang@mediatek.com>
 <20210420094402.hwdkbspl5wu4rtex@pali>
Message-ID: <87bla9qky1.wl-maz@kernel.org>

On Tue, 20 Apr 2021 10:44:02 +0100,
Pali Roh?r <pali at kernel.org> wrote:
> 
> Hello!
> 
> On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote:
> > +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> > +{
> > +	int i;
> > +	u32 val;
> > +
> > +	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
> > +		struct mtk_msi_set *msi_set = &port->msi_sets[i];
> > +
> > +		msi_set->base = port->base + PCIE_MSI_SET_BASE_REG +
> > +				i * PCIE_MSI_SET_OFFSET;
> > +		msi_set->msg_addr = port->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),
> > +			       port->base + PCIE_MSI_SET_ADDR_HI_BASE +
> > +			       i * PCIE_MSI_SET_ADDR_HI_OFFSET);
> 
> This looks like as setting MSI doorbell address to MSI doorbell address.
> 
> > +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > +{
> > +	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
> > +	struct mtk_pcie_port *port = data->domain->host_data;
> > +	unsigned long hwirq;
> > +
> > +	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
> > +
> > +	msg->address_hi = upper_32_bits(msi_set->msg_addr);
> > +	msg->address_lo = lower_32_bits(msi_set->msg_addr);
> > +	msg->data = hwirq;
> > +	dev_dbg(port->dev, "msi#%#lx address_hi %#x address_lo %#x data %d\n",
> > +		hwirq, msg->address_hi, msg->address_lo, msg->data);
> 
> ... which is later used in compose_msi_msg().
> 
> Marc in some other patches for other pci controller drivers changed this
> address to just main "port" structure. It simplified implementations and
> also avoided need to declare additional member "msg_addr".
> 
> Marc, would it be possible to simplify it also for this driver and just
> set msg_addr to virt_to_phys(port)?

Maybe. It really depends on what range the HW accepts, and the sole
requirement is to use an address that the endpoint cannot DMA
to. Here, the driver seems to be using something based on the port
base address, which is good enough as far as I am concerned (the thing
I usually object to is the allocation of memory just for the sake of
getting a capture address).

If you want to further simplify it, you could simply use port.reg_base
as the MSI address for all sets, as I don't think they have to be
distinct. But someone with access to the TRM for this should go and
check it.

I don't believe this should gate the merging od this driver though.

	M.

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


From pali at kernel.org  Tue Apr 20 12:08:32 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Tue, 20 Apr 2021 13:08:32 +0200
Subject: [PATCH v10 5/7] PCI: mediatek-gen3: Add MSI support
In-Reply-To: <87bla9qky1.wl-maz@kernel.org>
References: <20210420061723.989-1-jianjun.wang@mediatek.com>
 <20210420061723.989-6-jianjun.wang@mediatek.com>
 <20210420094402.hwdkbspl5wu4rtex@pali>
 <87bla9qky1.wl-maz@kernel.org>
Message-ID: <20210420110832.iyjck2m2s5jlit26@pali>

On Tuesday 20 April 2021 12:01:10 Marc Zyngier wrote:
> On Tue, 20 Apr 2021 10:44:02 +0100,
> Pali Roh?r <pali at kernel.org> wrote:
> > 
> > Hello!
> > 
> > On Tuesday 20 April 2021 14:17:21 Jianjun Wang wrote:
> > > +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> > > +{
> > > +	int i;
> > > +	u32 val;
> > > +
> > > +	for (i = 0; i < PCIE_MSI_SET_NUM; i++) {
> > > +		struct mtk_msi_set *msi_set = &port->msi_sets[i];
> > > +
> > > +		msi_set->base = port->base + PCIE_MSI_SET_BASE_REG +
> > > +				i * PCIE_MSI_SET_OFFSET;
> > > +		msi_set->msg_addr = port->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),
> > > +			       port->base + PCIE_MSI_SET_ADDR_HI_BASE +
> > > +			       i * PCIE_MSI_SET_ADDR_HI_OFFSET);
> > 
> > This looks like as setting MSI doorbell address to MSI doorbell address.
> > 
> > > +static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > > +{
> > > +	struct mtk_msi_set *msi_set = irq_data_get_irq_chip_data(data);
> > > +	struct mtk_pcie_port *port = data->domain->host_data;
> > > +	unsigned long hwirq;
> > > +
> > > +	hwirq =	data->hwirq % PCIE_MSI_IRQS_PER_SET;
> > > +
> > > +	msg->address_hi = upper_32_bits(msi_set->msg_addr);
> > > +	msg->address_lo = lower_32_bits(msi_set->msg_addr);
> > > +	msg->data = hwirq;
> > > +	dev_dbg(port->dev, "msi#%#lx address_hi %#x address_lo %#x data %d\n",
> > > +		hwirq, msg->address_hi, msg->address_lo, msg->data);
> > 
> > ... which is later used in compose_msi_msg().
> > 
> > Marc in some other patches for other pci controller drivers changed this
> > address to just main "port" structure. It simplified implementations and
> > also avoided need to declare additional member "msg_addr".
> > 
> > Marc, would it be possible to simplify it also for this driver and just
> > set msg_addr to virt_to_phys(port)?
> 
> Maybe. It really depends on what range the HW accepts, and the sole
> requirement is to use an address that the endpoint cannot DMA
> to. Here, the driver seems to be using something based on the port
> base address, which is good enough as far as I am concerned (the thing
> I usually object to is the allocation of memory just for the sake of
> getting a capture address).
> 
> If you want to further simplify it, you could simply use port.reg_base
> as the MSI address for all sets, as I don't think they have to be
> distinct. But someone with access to the TRM for this should go and
> check it.
> 
> I don't believe this should gate the merging od this driver though.

Of course! I'm just asking details to understand best practises and how
it works. So thanks for information!

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


From baruch at tkos.co.il  Tue Apr 20 12:21:35 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:35 +0300
Subject: [PATCH 0/5] arm64: IPQ6018 PCIe support
Message-ID: <cover.1618916235.git.baruch@tkos.co.il>

This series adds support for the single PCIe lane on IPQ6018 SoCs. The code is 
ported from downstream Codeaurora v5.4 kernel. The main difference from 
downstream code is the split of PCIe registers configuration from .init to 
.post_init, since it requires phy_power_on().

Tested on IPQ6010 based hardware.

Baruch Siach (2):
  dt-bindings: phy: qcom,qmp: Add IPQ60xx PCIe PHY bindings
  dt-bindings: pci: qcom: Document PCIe bindings for IPQ6018 SoC

Selvam Sathappan Periakaruppan (3):
  PCI: qcom: add support for IPQ60xx PCIe controller
  phy: qcom-qmp: add QMP V2 PCIe PHY support for ipq60xx
  arm64: dts: ipq6018: Add pcie support

 .../devicetree/bindings/pci/qcom,pcie.txt     |  24 ++
 .../devicetree/bindings/phy/qcom,qmp-phy.yaml |  25 ++
 arch/arm64/boot/dts/qcom/ipq6018.dtsi         | 109 +++++++
 drivers/pci/controller/dwc/pcie-qcom.c        | 279 ++++++++++++++++++
 drivers/phy/qualcomm/phy-qcom-qmp.c           | 147 +++++++++
 drivers/phy/qualcomm/phy-qcom-qmp.h           | 132 +++++++++
 6 files changed, 716 insertions(+)

-- 
2.30.2



From baruch at tkos.co.il  Tue Apr 20 12:21:38 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:38 +0300
Subject: [PATCH 3/5] arm64: dts: ipq6018: Add pcie support
In-Reply-To: <cover.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
Message-ID: <2a4f45170a820b007b4890e684412511a40dbc74.1618916235.git.baruch@tkos.co.il>

From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>

ipq6018 has 1 pcie gen3 port. This patch adds the support for the same.

The GICv2m reg property value is a guess based on similar SoCs
description in downstream Codeaurora kernel. It appears to work.

Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
[baruch: adjust #address-cells/#size-cells; drop unsupported property;
 use v2m msi interrupts parent; increase parf registers size]
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 arch/arm64/boot/dts/qcom/ipq6018.dtsi | 109 ++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 9fa5b028e4f3..a5b03b0d564b 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -375,6 +375,8 @@ qpic_nand: nand at 79b0000 {
 
 		intc: interrupt-controller at b000000 {
 			compatible = "qcom,msm-qgic2";
+			#address-cells = <1>;
+			#size-cells = <1>;
 			interrupt-controller;
 			#interrupt-cells = <0x3>;
 			reg =   <0x0 0x0b000000 0x0 0x1000>,  /*GICD*/
@@ -382,6 +384,113 @@ intc: interrupt-controller at b000000 {
 				<0x0 0x0b001000 0x0 0x1000>,  /*GICH*/
 				<0x0 0x0b004000 0x0 0x1000>;  /*GICV*/
 			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			ranges = <0x0 0x0 0xb00a000 0xffd>;
+
+			v2m0: v2m at 0 {
+				compatible = "arm,gic-v2m-frame";
+				msi-controller;
+				reg = <0x0 0xffd>;
+			};
+		};
+
+		pcie_phy: phy at 84000 {
+			compatible = "qcom,ipq6018-qmp-pcie-phy";
+			reg = <0x0 0x84000 0x0 0x1bc>; /* Serdes PLL */
+			status = "disabled";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			clocks = <&gcc GCC_PCIE0_AUX_CLK>,
+				<&gcc GCC_PCIE0_AHB_CLK>;
+			clock-names = "aux", "cfg_ahb";
+
+			resets = <&gcc GCC_PCIE0_PHY_BCR>,
+				<&gcc GCC_PCIE0PHY_PHY_BCR>;
+			reset-names = "phy",
+				      "common";
+
+			pcie_phy0: lane at 84200 {
+				reg = <0x0 0x84200 0x0 0x16c>, /* Serdes Tx */
+				      <0x0 0x84400 0x0 0x200>, /* Serdes Rx */
+				      <0x0 0x84800 0x0 0x4f4>; /* PCS: Lane0, COM, PCIE */
+				#phy-cells = <0>;
+
+				clocks = <&gcc GCC_PCIE0_PIPE_CLK>;
+				clock-names = "pipe0";
+				clock-output-names = "gcc_pcie0_pipe_clk_src";
+				#clock-cells = <0>;
+			};
+		};
+
+		pcie0: pci at 20000000 {
+			compatible = "qcom,pcie-ipq6018";
+			reg = <0x0 0x20000000 0x0 0xf1d>,
+			      <0x0 0x20000f20 0x0 0xa8>,
+			      <0x0 0x20001000 0x0 0x1000>,
+			      <0x0 0x80000 0x0 0x4000>,
+			      <0x0 0x20100000 0x0 0x1000>;
+			reg-names = "dbi", "elbi", "atu", "parf", "config";
+
+			device_type = "pci";
+			linux,pci-domain = <0>;
+			bus-range = <0x00 0xff>;
+			num-lanes = <1>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			phys = <&pcie_phy0>;
+			phy-names = "pciephy";
+
+			ranges = <0x81000000 0 0x20200000 0 0x20200000
+				  0 0x10000>, /* downstream I/O */
+				 <0x82000000 0 0x20220000 0 0x20220000
+				  0 0xfde0000>; /* non-prefetchable memory */
+
+			interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "msi";
+			msi-parent = <&v2m0>;
+
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 0x7>;
+			interrupt-map = <0 0 0 1 &intc 0 75
+					 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+					<0 0 0 2 &intc 0 78
+					 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+					<0 0 0 3 &intc 0 79
+					 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+					<0 0 0 4 &intc 0 83
+					 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+			clocks = <&gcc GCC_SYS_NOC_PCIE0_AXI_CLK>,
+				 <&gcc GCC_PCIE0_AXI_M_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_CLK>,
+				 <&gcc GCC_PCIE0_AXI_S_BRIDGE_CLK>,
+				 <&gcc PCIE0_RCHNG_CLK>;
+			clock-names = "iface",
+				      "axi_m",
+				      "axi_s",
+				      "axi_bridge",
+				      "rchng";
+
+			resets = <&gcc GCC_PCIE0_PIPE_ARES>,
+				 <&gcc GCC_PCIE0_SLEEP_ARES>,
+				 <&gcc GCC_PCIE0_CORE_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_ARES>,
+				 <&gcc GCC_PCIE0_AHB_ARES>,
+				 <&gcc GCC_PCIE0_AXI_MASTER_STICKY_ARES>,
+				 <&gcc GCC_PCIE0_AXI_SLAVE_STICKY_ARES>;
+			reset-names = "pipe",
+				      "sleep",
+				      "sticky",
+				      "axi_m",
+				      "axi_s",
+				      "ahb",
+				      "axi_m_sticky",
+				      "axi_s_sticky";
+
+			status = "disabled";
 		};
 
 		watchdog at b017000 {
-- 
2.30.2



From baruch at tkos.co.il  Tue Apr 20 12:21:39 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:39 +0300
Subject: [PATCH 4/5] dt-bindings: phy: qcom, qmp: Add IPQ60xx PCIe PHY bindings
In-Reply-To: <cover.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
Message-ID: <f787ca496eae2a0d5ff4f17655eaff9f39a14321.1618916235.git.baruch@tkos.co.il>

Add ipq6018 qmp phy device for the single PCIe serdes lane on IPQ60xx
SoCs.

Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 .../devicetree/bindings/phy/qcom,qmp-phy.yaml | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
index 626447fee092..cb2eb7ac6d28 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
@@ -17,6 +17,7 @@ description:
 properties:
   compatible:
     enum:
+      - qcom,ipq6018-qmp-pcie-phy
       - qcom,ipq8074-qmp-pcie-phy
       - qcom,ipq8074-qmp-usb3-phy
       - qcom,msm8996-qmp-pcie-phy
@@ -294,6 +295,30 @@ allOf:
           items:
             - const: phy
             - const: common
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,ipq6018-qmp-pcie-phy
+    then:
+      properties:
+        clocks:
+          items:
+            - description: Phy aux clock.
+            - description: Phy config clock.
+        clock-names:
+          items:
+            - const: aux
+            - const: cfg_ahb
+        resets:
+          items:
+            - description: reset of phy block.
+            - description: phy common block reset.
+        reset-names:
+          items:
+            - const: phy
+            - const: common
   - if:
       properties:
         compatible:
-- 
2.30.2



From baruch at tkos.co.il  Tue Apr 20 12:21:36 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:36 +0300
Subject: [PATCH 1/5] PCI: qcom: add support for IPQ60xx PCIe controller
In-Reply-To: <cover.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
Message-ID: <c6ff03d1377ea9b5ff40ab283c884aeff6254dd9.1618916235.git.baruch@tkos.co.il>

From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>

IPQ60xx series of SoCs have one port of PCIe gen 3. Add support for that
platform.

The code is based on downstream Codeaurora kernel v5.4. Split out the
registers access part from .init into .post_init. Registers are only
accessible after phy_power_on().

Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 279 +++++++++++++++++++++++++
 1 file changed, 279 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 8a7a300163e5..3e27de744738 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -41,6 +41,31 @@
 #define L23_CLK_RMV_DIS				BIT(2)
 #define L1_CLK_RMV_DIS				BIT(1)
 
+#define PCIE_ATU_CR1_OUTBOUND_6_GEN3		0xC00
+#define PCIE_ATU_CR2_OUTBOUND_6_GEN3		0xC04
+#define PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3	0xC08
+#define PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3	0xC0C
+#define PCIE_ATU_LIMIT_OUTBOUND_6_GEN3		0xC10
+#define PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3	0xC14
+#define PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3	0xC18
+
+#define PCIE_ATU_CR1_OUTBOUND_7_GEN3		0xE00
+#define PCIE_ATU_CR2_OUTBOUND_7_GEN3		0xE04
+#define PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3	0xE08
+#define PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3	0xE0C
+#define PCIE_ATU_LIMIT_OUTBOUND_7_GEN3		0xE10
+#define PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3	0xE14
+#define PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3 	0xE18
+
+#define PCIE20_COMMAND_STATUS			0x04
+#define BUS_MASTER_EN				0x7
+#define PCIE20_DEVICE_CONTROL2_STATUS2		0x98
+#define PCIE_CAP_CPL_TIMEOUT_DISABLE		0x10
+#define PCIE30_GEN3_RELATED_OFF			0x890
+
+#define RXEQ_RGRDLESS_RXTS			BIT(13)
+#define GEN3_ZRXDC_NONCOMPL			BIT(0)
+
 #define PCIE20_PARF_PHY_CTRL			0x40
 #define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK	GENMASK(20, 16)
 #define PHY_CTRL_PHY_TX0_TERM_OFFSET(x)		((x) << 16)
@@ -52,6 +77,10 @@
 #define PCIE20_PARF_DBI_BASE_ADDR		0x168
 #define PCIE20_PARF_SLV_ADDR_SPACE_SIZE		0x16C
 #define PCIE20_PARF_MHI_CLOCK_RESET_CTRL	0x174
+#define AHB_CLK_EN				BIT(0)
+#define MSTR_AXI_CLK_EN				BIT(1)
+#define BYPASS					BIT(4)
+
 #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT	0x178
 #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2	0x1A8
 #define PCIE20_PARF_LTSSM			0x1B0
@@ -94,6 +123,12 @@
 #define SLV_ADDR_SPACE_SZ			0x10000000
 
 #define PCIE20_LNK_CONTROL2_LINK_STATUS2	0xa0
+#define PCIE_CAP_CURR_DEEMPHASIS		BIT(16)
+#define SPEED_GEN1				0x1
+#define SPEED_GEN2				0x2
+#define SPEED_GEN3				0x3
+#define AXI_CLK_RATE				200000000
+#define RCHNG_CLK_RATE				100000000
 
 #define DEVICE_TYPE_RC				0x4
 
@@ -168,6 +203,15 @@ struct qcom_pcie_resources_2_7_0 {
 	struct clk *pipe_clk;
 };
 
+struct qcom_pcie_resources_2_9_0 {
+	struct clk *iface;
+	struct clk *axi_m_clk;
+	struct clk *axi_s_clk;
+	struct clk *axi_bridge_clk;
+	struct clk *rchng_clk;
+	struct reset_control *rst[8];
+};
+
 union qcom_pcie_resources {
 	struct qcom_pcie_resources_1_0_0 v1_0_0;
 	struct qcom_pcie_resources_2_1_0 v2_1_0;
@@ -175,6 +219,7 @@ union qcom_pcie_resources {
 	struct qcom_pcie_resources_2_3_3 v2_3_3;
 	struct qcom_pcie_resources_2_4_0 v2_4_0;
 	struct qcom_pcie_resources_2_7_0 v2_7_0;
+	struct qcom_pcie_resources_2_9_0 v2_9_0;
 };
 
 struct qcom_pcie;
@@ -1266,6 +1311,225 @@ static void qcom_pcie_post_deinit_2_7_0(struct qcom_pcie *pcie)
 	clk_disable_unprepare(res->pipe_clk);
 }
 
+static int qcom_pcie_get_resources_2_9_0(struct qcom_pcie *pcie)
+{
+	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
+	struct dw_pcie *pci = pcie->pci;
+	struct device *dev = pci->dev;
+	int i;
+	const char *rst_names[] = { "pipe", "sleep", "sticky",
+				    "axi_m", "axi_s", "ahb",
+				    "axi_m_sticky", "axi_s_sticky", };
+
+	res->iface = devm_clk_get(dev, "iface");
+	if (IS_ERR(res->iface))
+		return PTR_ERR(res->iface);
+
+	res->axi_m_clk = devm_clk_get(dev, "axi_m");
+	if (IS_ERR(res->axi_m_clk))
+		return PTR_ERR(res->axi_m_clk);
+
+	res->axi_s_clk = devm_clk_get(dev, "axi_s");
+	if (IS_ERR(res->axi_s_clk))
+		return PTR_ERR(res->axi_s_clk);
+
+	res->axi_bridge_clk = devm_clk_get(dev, "axi_bridge");
+	if (IS_ERR(res->axi_bridge_clk))
+		return PTR_ERR(res->axi_bridge_clk);
+
+	res->rchng_clk = devm_clk_get(dev, "rchng");
+	if (IS_ERR(res->rchng_clk))
+		return PTR_ERR(res->rchng_clk);
+
+	for (i = 0; i < ARRAY_SIZE(rst_names); i++) {
+		res->rst[i] = devm_reset_control_get(dev, rst_names[i]);
+		if (IS_ERR(res->rst[i])) {
+			return PTR_ERR(res->rst[i]);
+		}
+	}
+
+	return 0;
+}
+
+static void qcom_pcie_deinit_2_9_0(struct qcom_pcie *pcie)
+{
+	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
+
+	clk_disable_unprepare(res->axi_m_clk);
+	clk_disable_unprepare(res->axi_s_clk);
+	clk_disable_unprepare(res->axi_bridge_clk);
+	clk_disable_unprepare(res->rchng_clk);
+	clk_disable_unprepare(res->iface);
+}
+
+static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie)
+{
+	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
+	struct device *dev = pcie->pci->dev;
+	int i, ret;
+
+	for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
+		ret = reset_control_assert(res->rst[i]);
+		if (ret) {
+			dev_err(dev, "reset #%d assert failed (%d)\n", i, ret);
+			return ret;
+		}
+	}
+
+	usleep_range(2000, 2500);
+
+	for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
+		ret = reset_control_deassert(res->rst[i]);
+		if (ret) {
+			dev_err(dev, "reset #%d deassert failed (%d)\n", i,
+				ret);
+			return ret;
+		}
+	}
+
+	/*
+	 * Don't have a way to see if the reset has completed.
+	 * Wait for some time.
+	 */
+	usleep_range(2000, 2500);
+
+	ret = clk_prepare_enable(res->iface);
+	if (ret) {
+		dev_err(dev, "cannot prepare/enable core clock\n");
+		goto err_clk_iface;
+	}
+
+	ret = clk_prepare_enable(res->axi_m_clk);
+	if (ret) {
+		dev_err(dev, "cannot prepare/enable core clock\n");
+		goto err_clk_axi_m;
+	}
+
+	ret = clk_set_rate(res->axi_m_clk, AXI_CLK_RATE);
+	if (ret) {
+		dev_err(dev, "MClk rate set failed (%d)\n", ret);
+		goto err_clk_axi_m;
+	}
+
+	ret = clk_prepare_enable(res->axi_s_clk);
+	if (ret) {
+		dev_err(dev, "cannot prepare/enable axi slave clock\n");
+		goto err_clk_axi_s;
+	}
+
+	ret = clk_set_rate(res->axi_s_clk, AXI_CLK_RATE);
+	if (ret) {
+		dev_err(dev, "SClk rate set failed (%d)\n", ret);
+		goto err_clk_axi_s;
+	}
+
+	ret = clk_prepare_enable(res->axi_bridge_clk);
+	if (ret) {
+		dev_err(dev, "cannot prepare/enable axi bridge clock\n");
+		goto err_clk_axi_bridge;
+	}
+
+	ret = clk_prepare_enable(res->rchng_clk);
+	if (ret) {
+		dev_err(dev, "cannot prepare/enable rchng clock\n");
+		goto err_clk_rchng;
+	}
+
+	ret = clk_set_rate(res->rchng_clk, RCHNG_CLK_RATE);
+	if (ret) {
+		dev_err(dev, "rchng_clk rate set failed (%d)\n", ret);
+		goto err_clk_rchng;
+	}
+
+	return 0;
+
+err_clk_rchng:
+	clk_disable_unprepare(res->rchng_clk);
+err_clk_axi_bridge:
+	clk_disable_unprepare(res->axi_bridge_clk);
+err_clk_axi_s:
+	clk_disable_unprepare(res->axi_s_clk);
+err_clk_axi_m:
+	clk_disable_unprepare(res->axi_m_clk);
+err_clk_iface:
+	clk_disable_unprepare(res->iface);
+	/*
+	 * Not checking for failure, will anyway return
+	 * the original failure in 'ret'.
+	 */
+	for (i = 0; i < ARRAY_SIZE(res->rst); i++)
+		reset_control_assert(res->rst[i]);
+
+	return ret;
+}
+
+static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie)
+{
+	struct dw_pcie *pci = pcie->pci;
+	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+	u32 val;
+	int i;
+
+	writel(SLV_ADDR_SPACE_SZ,
+		pcie->parf + PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE);
+
+	val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
+	val &= ~BIT(0);
+	writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
+
+	writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
+
+	writel(DEVICE_TYPE_RC, pcie->parf + PCIE20_PARF_DEVICE_TYPE);
+	writel(BYPASS | MSTR_AXI_CLK_EN | AHB_CLK_EN,
+		pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+	writel(RXEQ_RGRDLESS_RXTS | GEN3_ZRXDC_NONCOMPL,
+		pci->dbi_base + PCIE30_GEN3_RELATED_OFF);
+
+	writel(MST_WAKEUP_EN | SLV_WAKEUP_EN | MSTR_ACLK_CGC_DIS
+		| SLV_ACLK_CGC_DIS | CORE_CLK_CGC_DIS |
+		AUX_PWR_DET | L23_CLK_RMV_DIS | L1_CLK_RMV_DIS,
+		pcie->parf + PCIE20_PARF_SYS_CTRL);
+
+	writel(0, pcie->parf + PCIE20_PARF_Q2A_FLUSH);
+
+	writel(BUS_MASTER_EN, pci->dbi_base + PCIE20_COMMAND_STATUS);
+
+	writel(DBI_RO_WR_EN, pci->dbi_base + PCIE20_MISC_CONTROL_1_REG);
+	writel(PCIE_CAP_LINK1_VAL, pci->dbi_base + offset + PCI_EXP_SLTCAP);
+
+	/* Configure PCIe link capabilities for ASPM */
+	val = readl(pci->dbi_base + offset + PCI_EXP_LNKCAP);
+	val &= ~PCI_EXP_LNKCAP_ASPMS;
+	writel(val, pci->dbi_base + offset + PCI_EXP_LNKCAP);
+
+	writel(PCIE_CAP_CPL_TIMEOUT_DISABLE, pci->dbi_base +
+		PCIE20_DEVICE_CONTROL2_STATUS2);
+
+	writel(PCIE_CAP_CURR_DEEMPHASIS | SPEED_GEN3,
+			pci->dbi_base + offset + PCI_EXP_DEVCTL2);
+
+	for (i = 0;i < 256;i++)
+		writel(0x0, pcie->parf + PCIE20_PARF_BDF_TO_SID_TABLE_N
+				+ (4 * i));
+
+	writel(0x4, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_6_GEN3);
+	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_6_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3);
+	writel(0x00107FFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_6_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3);
+	writel(0x5, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_7_GEN3);
+	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_7_GEN3);
+	writel(0x200000, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3);
+	writel(0x7FFFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_7_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3);
+	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3);
+
+	return 0;
+}
+
 static int qcom_pcie_link_up(struct dw_pcie *pci)
 {
 	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
@@ -1456,6 +1720,15 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
 	.config_sid = qcom_pcie_config_sid_sm8250,
 };
 
+/* Qcom IP rev.: 2.9.0  Synopsys IP rev.: 5.00a */
+static const struct qcom_pcie_ops ops_2_9_0 = {
+	.get_resources = qcom_pcie_get_resources_2_9_0,
+	.init = qcom_pcie_init_2_9_0,
+	.post_init = qcom_pcie_post_init_2_9_0,
+	.deinit = qcom_pcie_deinit_2_9_0,
+	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
+};
+
 static const struct dw_pcie_ops dw_pcie_ops = {
 	.link_up = qcom_pcie_link_up,
 	.start_link = qcom_pcie_start_link,
@@ -1508,6 +1781,11 @@ static int qcom_pcie_probe(struct platform_device *pdev)
 		goto err_pm_runtime_put;
 	}
 
+	/* We need ATU for .post_init */
+	pci->atu_base = devm_platform_ioremap_resource_byname(pdev, "atu");
+	if (IS_ERR(pci->atu_base))
+		pci->atu_base = NULL;
+
 	pcie->phy = devm_phy_optional_get(dev, "pciephy");
 	if (IS_ERR(pcie->phy)) {
 		ret = PTR_ERR(pcie->phy);
@@ -1555,6 +1833,7 @@ static const struct of_device_id qcom_pcie_match[] = {
 	{ .compatible = "qcom,pcie-qcs404", .data = &ops_2_4_0 },
 	{ .compatible = "qcom,pcie-sdm845", .data = &ops_2_7_0 },
 	{ .compatible = "qcom,pcie-sm8250", .data = &ops_1_9_0 },
+	{ .compatible = "qcom,pcie-ipq6018", .data = &ops_2_9_0 },
 	{ }
 };
 
-- 
2.30.2



From baruch at tkos.co.il  Tue Apr 20 12:21:37 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:37 +0300
Subject: [PATCH 2/5] phy: qcom-qmp: add QMP V2 PCIe PHY support for ipq60xx
In-Reply-To: <cover.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
Message-ID: <5ce70de9f11706664dc64ecb5bd4a757a0808d3a.1618916235.git.baruch@tkos.co.il>

From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>

Based on code from downstream Codeaurora tree. The ipq60xx has one gen3
PCIe port.

Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 147 ++++++++++++++++++++++++++++
 drivers/phy/qualcomm/phy-qcom-qmp.h | 132 +++++++++++++++++++++++++
 2 files changed, 279 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 9cdebe7f26cb..9f3148136789 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -143,6 +143,13 @@ static const unsigned int msm8996_ufsphy_regs_layout[QPHY_LAYOUT_SIZE] = {
 	[QPHY_PCS_READY_STATUS]		= 0x168,
 };
 
+static const unsigned int ipq_pciephy_gen3_regs_layout[QPHY_LAYOUT_SIZE] = {
+	[QPHY_SW_RESET]				= 0x00,
+	[QPHY_START_CTRL]			= 0x44,
+	[QPHY_PCS_STATUS]			= 0x14,
+	[QPHY_PCS_POWER_DOWN_CONTROL]		= 0x40,
+};
+
 static const unsigned int pciephy_regs_layout[QPHY_LAYOUT_SIZE] = {
 	[QPHY_COM_SW_RESET]		= 0x400,
 	[QPHY_COM_POWER_DOWN_CONTROL]	= 0x404,
@@ -614,6 +621,113 @@ static const struct qmp_phy_init_tbl msm8996_usb3_pcs_tbl[] = {
 	QMP_PHY_INIT_CFG(QPHY_POWER_STATE_CONFIG2, 0x08),
 };
 
+static const struct qmp_phy_init_tbl ipq6018_pcie_serdes_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_PER1, 0x7d),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_PER2, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE1_MODE0, 0x0a),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE2_MODE0, 0x05),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE1_MODE1, 0x08),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SSC_STEP_SIZE2_MODE1, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_ENABLE1, 0x90),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYS_CLK_CTRL, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_BUF_ENABLE, 0x07),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_IVCO, 0x0f),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE0, 0xd4),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE0, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE1, 0xaa),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE1, 0x29),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TRIM, 0x0f),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE0, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE1, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE0, 0x16),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE1, 0x16),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE0, 0x28),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE1, 0x28),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x08),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_RESETSM_CNTRL, 0x20),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP_EN, 0x42),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE0, 0x68),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE1, 0x53),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START1_MODE0, 0xab),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START2_MODE0, 0xaa),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START3_MODE0, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START1_MODE1, 0x55),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START2_MODE1, 0x55),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_DIV_FRAC_START3_MODE1, 0x05),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE0, 0xa0),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE1, 0xa0),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE0, 0x24),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE0, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE1, 0xb4),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE1, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CLK_SELECT, 0x32),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CMN_CONFIG, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05),
+	QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV_MODE1, 0x08),
+};
+
+static const struct qmp_phy_init_tbl ipq6018_pcie_tx_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_TX0_RES_CODE_LANE_OFFSET_TX, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_TX0_LANE_MODE_1, 0x06),
+	QMP_PHY_INIT_CFG(QSERDES_TX0_RCV_DETECT_LVL_2, 0x12),
+};
+
+static const struct qmp_phy_init_tbl ipq6018_pcie_rx_tbl[] = {
+	QMP_PHY_INIT_CFG(QSERDES_RX0_UCDR_FO_GAIN, 0x0c),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_UCDR_SO_GAIN, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_UCDR_PI_CONTROLS, 0x70),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL2, 0x61),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL4, 0x1e),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_IDAC_TSETTLE_LOW, 0xc0),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_IDAC_TSETTLE_HIGH, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x73),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_SIGDET_ENABLES, 0x1c),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_SIGDET_CNTRL, 0x03),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_SIGDET_DEGLITCH_CNTRL, 0x14),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_00_LOW, 0xf0),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_00_HIGH, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_00_HIGH2, 0x2f),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_00_HIGH3, 0xd3),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_00_HIGH4, 0x40),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_01_LOW, 0x01),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_01_HIGH, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_01_HIGH2, 0xc8),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_01_HIGH3, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_01_HIGH4, 0xb1),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_10_LOW, 0x00),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_10_HIGH, 0x02),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_10_HIGH2, 0xc8),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_10_HIGH3, 0x09),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_RX_MODE_10_HIGH4, 0xb1),
+	QMP_PHY_INIT_CFG(QSERDES_RX0_DFE_EN_TIMER, 0x04),
+};
+
+static const struct qmp_phy_init_tbl ipq6018_pcie_pcs_tbl[] = {
+	QMP_PHY_INIT_CFG(PCS_COM_FLL_CNTRL1, 0x01),
+	QMP_PHY_INIT_CFG(PCS_COM_REFGEN_REQ_CONFIG1, 0x0d),
+	QMP_PHY_INIT_CFG(PCS_COM_G12S1_TXDEEMPH_M3P5DB, 0x10),
+	QMP_PHY_INIT_CFG(PCS_COM_RX_SIGDET_LVL, 0xaa),
+	QMP_PHY_INIT_CFG(PCS_COM_P2U3_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(PCS_COM_RX_DCC_CAL_CONFIG, 0x01),
+	QMP_PHY_INIT_CFG(PCS_COM_EQ_CONFIG5, 0x01),
+	QMP_PHY_INIT_CFG(PCS_PCIE_POWER_STATE_CONFIG2, 0x0d),
+	QMP_PHY_INIT_CFG(PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
+	QMP_PHY_INIT_CFG(PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
+	QMP_PHY_INIT_CFG(PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+	QMP_PHY_INIT_CFG(PCS_PCIE_OSC_DTCT_ACTIONS, 0x00),
+	QMP_PHY_INIT_CFG(PCS_PCIE_EQ_CONFIG1, 0x11),
+	QMP_PHY_INIT_CFG(PCS_PCIE_PRESET_P10_PRE, 0x00),
+	QMP_PHY_INIT_CFG(PCS_PCIE_PRESET_P10_POST, 0x58),
+};
+
 static const struct qmp_phy_init_tbl ipq8074_pcie_serdes_tbl[] = {
 	QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x18),
 	QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -2646,6 +2760,36 @@ static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
 	.pwrdn_delay_max	= 1005,		/* us */
 };
 
+static const struct qmp_phy_cfg ipq6018_pciephy_cfg = {
+	.type			= PHY_TYPE_PCIE,
+	.nlanes			= 1,
+
+	.serdes_tbl		= ipq6018_pcie_serdes_tbl,
+	.serdes_tbl_num		= ARRAY_SIZE(ipq6018_pcie_serdes_tbl),
+	.tx_tbl			= ipq6018_pcie_tx_tbl,
+	.tx_tbl_num		= ARRAY_SIZE(ipq6018_pcie_tx_tbl),
+	.rx_tbl			= ipq6018_pcie_rx_tbl,
+	.rx_tbl_num		= ARRAY_SIZE(ipq6018_pcie_rx_tbl),
+	.pcs_tbl		= ipq6018_pcie_pcs_tbl,
+	.pcs_tbl_num		= ARRAY_SIZE(ipq6018_pcie_pcs_tbl),
+	.clk_list		= ipq8074_pciephy_clk_l,
+	.num_clks		= ARRAY_SIZE(ipq8074_pciephy_clk_l),
+	.reset_list		= ipq8074_pciephy_reset_l,
+	.num_resets		= ARRAY_SIZE(ipq8074_pciephy_reset_l),
+	.vreg_list		= NULL,
+	.num_vregs		= 0,
+	.regs			= ipq_pciephy_gen3_regs_layout,
+
+	.start_ctrl		= SERDES_START | PCS_START,
+	.pwrdn_ctrl		= SW_PWRDN | REFCLK_DRV_DSBL,
+
+	.has_phy_com_ctrl	= false,
+	.has_lane_rst		= false,
+	.has_pwrdn_delay	= true,
+	.pwrdn_delay_min	= 995,		/* us */
+	.pwrdn_delay_max	= 1005,		/* us */
+};
+
 static const struct qmp_phy_cfg sdm845_qmp_pciephy_cfg = {
 	.type = PHY_TYPE_PCIE,
 	.nlanes = 1,
@@ -4532,6 +4676,9 @@ static const struct of_device_id qcom_qmp_phy_of_match_table[] = {
 	}, {
 		.compatible = "qcom,ipq8074-qmp-pcie-phy",
 		.data = &ipq8074_pciephy_cfg,
+	}, {
+		.compatible = "qcom,ipq6018-qmp-pcie-phy",
+		.data = &ipq6018_pciephy_cfg,
 	}, {
 		.compatible = "qcom,sc7180-qmp-usb3-phy",
 		.data = &sc7180_usb3phy_cfg,
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.h b/drivers/phy/qualcomm/phy-qcom-qmp.h
index 71ce3aa174ae..bd8f9637b4d0 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.h
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.h
@@ -6,6 +6,138 @@
 #ifndef QCOM_PHY_QMP_H_
 #define QCOM_PHY_QMP_H_
 
+/* QMP V2 PHY for PCIE gen3 ports - QSERDES PLL registers */
+
+#define QSERDES_PLL_BG_TIMER				0x00c
+#define QSERDES_PLL_SSC_PER1				0x01c
+#define QSERDES_PLL_SSC_PER2				0x020
+#define QSERDES_PLL_SSC_STEP_SIZE1_MODE0		0x024
+#define QSERDES_PLL_SSC_STEP_SIZE2_MODE0		0x028
+#define QSERDES_PLL_SSC_STEP_SIZE1_MODE1		0x02c
+#define QSERDES_PLL_SSC_STEP_SIZE2_MODE1		0x030
+#define QSERDES_PLL_BIAS_EN_CLKBUFLR_EN			0x03c
+#define QSERDES_PLL_CLK_ENABLE1				0x040
+#define QSERDES_PLL_SYS_CLK_CTRL			0x044
+#define QSERDES_PLL_SYSCLK_BUF_ENABLE			0x048
+#define QSERDES_PLL_PLL_IVCO				0x050
+#define QSERDES_PLL_LOCK_CMP1_MODE0			0x054
+#define QSERDES_PLL_LOCK_CMP2_MODE0			0x058
+#define QSERDES_PLL_LOCK_CMP1_MODE1			0x060
+#define QSERDES_PLL_LOCK_CMP2_MODE1			0x064
+#define QSERDES_PLL_BG_TRIM				0x074
+#define QSERDES_PLL_CLK_EP_DIV_MODE0			0x078
+#define QSERDES_PLL_CLK_EP_DIV_MODE1			0x07c
+#define QSERDES_PLL_CP_CTRL_MODE0			0x080
+#define QSERDES_PLL_CP_CTRL_MODE1			0x084
+#define QSERDES_PLL_PLL_RCTRL_MODE0			0x088
+#define QSERDES_PLL_PLL_RCTRL_MODE1			0x08C
+#define QSERDES_PLL_PLL_CCTRL_MODE0			0x090
+#define QSERDES_PLL_PLL_CCTRL_MODE1			0x094
+#define QSERDES_PLL_BIAS_EN_CTRL_BY_PSM			0x0a4
+#define QSERDES_PLL_SYSCLK_EN_SEL			0x0a8
+#define QSERDES_PLL_RESETSM_CNTRL			0x0b0
+#define QSERDES_PLL_LOCK_CMP_EN				0x0c4
+#define QSERDES_PLL_DEC_START_MODE0			0x0cc
+#define QSERDES_PLL_DEC_START_MODE1			0x0d0
+#define QSERDES_PLL_DIV_FRAC_START1_MODE0		0x0d8
+#define QSERDES_PLL_DIV_FRAC_START2_MODE0		0x0dc
+#define QSERDES_PLL_DIV_FRAC_START3_MODE0		0x0e0
+#define QSERDES_PLL_DIV_FRAC_START1_MODE1		0x0e4
+#define QSERDES_PLL_DIV_FRAC_START2_MODE1		0x0e8
+#define QSERDES_PLL_DIV_FRAC_START3_MODE1		0x0eC
+#define QSERDES_PLL_INTEGLOOP_GAIN0_MODE0		0x100
+#define QSERDES_PLL_INTEGLOOP_GAIN1_MODE0		0x104
+#define QSERDES_PLL_INTEGLOOP_GAIN0_MODE1		0x108
+#define QSERDES_PLL_INTEGLOOP_GAIN1_MODE1		0x10c
+#define QSERDES_PLL_VCO_TUNE_MAP			0x120
+#define QSERDES_PLL_VCO_TUNE1_MODE0			0x124
+#define QSERDES_PLL_VCO_TUNE2_MODE0			0x128
+#define QSERDES_PLL_VCO_TUNE1_MODE1			0x12c
+#define QSERDES_PLL_VCO_TUNE2_MODE1			0x130
+#define QSERDES_PLL_VCO_TUNE_TIMER1			0x13c
+#define QSERDES_PLL_VCO_TUNE_TIMER2			0x140
+#define QSERDES_PLL_CLK_SELECT				0x16c
+#define QSERDES_PLL_HSCLK_SEL				0x170
+#define QSERDES_PLL_CORECLK_DIV				0x17c
+#define QSERDES_PLL_CORE_CLK_EN				0x184
+#define QSERDES_PLL_CMN_CONFIG				0x18c
+#define QSERDES_PLL_SVS_MODE_CLK_SEL			0x194
+#define QSERDES_PLL_CORECLK_DIV_MODE1			0x1b4
+
+/* QMP V2 PHY for PCIE gen3 ports - QSERDES TX registers */
+
+#define QSERDES_TX0_RES_CODE_LANE_OFFSET_TX		0x03c
+#define QSERDES_TX0_HIGHZ_DRVR_EN			0x058
+#define QSERDES_TX0_LANE_MODE_1				0x084
+#define QSERDES_TX0_RCV_DETECT_LVL_2			0x09c
+
+/* QMP V2 PHY for PCIE gen3 ports - QSERDES RX registers */
+
+#define QSERDES_RX0_UCDR_FO_GAIN			0x008
+#define QSERDES_RX0_UCDR_SO_GAIN			0x014
+#define QSERDES_RX0_UCDR_SO_SATURATION_AND_ENABLE	0x034
+#define QSERDES_RX0_UCDR_PI_CONTROLS			0x044
+#define QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL2		0x0ec
+#define QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL3		0x0f0
+#define QSERDES_RX0_RX_EQU_ADAPTOR_CNTRL4		0x0f4
+#define QSERDES_RX0_RX_IDAC_TSETTLE_LOW			0x0f8
+#define QSERDES_RX0_RX_IDAC_TSETTLE_HIGH		0x0fc
+#define QSERDES_RX0_RX_EQ_OFFSET_ADAPTOR_CNTRL1		0x110
+#define QSERDES_RX0_RX_OFFSET_ADAPTOR_CNTRL2		0x114
+#define QSERDES_RX0_SIGDET_ENABLES			0x118
+#define QSERDES_RX0_SIGDET_CNTRL			0x11c
+#define QSERDES_RX0_SIGDET_DEGLITCH_CNTRL		0x124
+#define QSERDES_RX0_RX_MODE_00_LOW			0x170
+#define QSERDES_RX0_RX_MODE_00_HIGH			0x174
+#define QSERDES_RX0_RX_MODE_00_HIGH2			0x178
+#define QSERDES_RX0_RX_MODE_00_HIGH3			0x17c
+#define QSERDES_RX0_RX_MODE_00_HIGH4			0x180
+#define QSERDES_RX0_RX_MODE_01_LOW			0x184
+#define QSERDES_RX0_RX_MODE_01_HIGH			0x188
+#define QSERDES_RX0_RX_MODE_01_HIGH2			0x18c
+#define QSERDES_RX0_RX_MODE_01_HIGH3			0x190
+#define QSERDES_RX0_RX_MODE_01_HIGH4			0x194
+#define QSERDES_RX0_RX_MODE_10_LOW			0x198
+#define QSERDES_RX0_RX_MODE_10_HIGH			0x19c
+#define QSERDES_RX0_RX_MODE_10_HIGH2			0x1a0
+#define QSERDES_RX0_RX_MODE_10_HIGH3			0x1a4
+#define QSERDES_RX0_RX_MODE_10_HIGH4			0x1a8
+#define QSERDES_RX0_DFE_EN_TIMER			0x1b4
+
+/* QMP V2 PHY for PCIE gen3 ports - PCS registers */
+
+#define PCS_COM_FLL_CNTRL1				0x098
+#define PCS_COM_FLL_CNTRL2				0x09c
+#define PCS_COM_FLL_CNT_VAL_L				0x0a0
+#define PCS_COM_FLL_CNT_VAL_H_TOL			0x0a4
+#define PCS_COM_FLL_MAN_CODE				0x0a8
+#define PCS_COM_REFGEN_REQ_CONFIG1			0x0dc
+#define PCS_COM_G12S1_TXDEEMPH_M3P5DB			0x16c
+#define PCS_COM_RX_SIGDET_LVL				0x188
+#define PCS_COM_P2U3_WAKEUP_DLY_TIME_AUXCLK_L		0x1a4
+#define PCS_COM_P2U3_WAKEUP_DLY_TIME_AUXCLK_H		0x1a8
+#define PCS_COM_RX_DCC_CAL_CONFIG			0x1d8
+#define PCS_COM_EQ_CONFIG5				0x1ec
+
+/* QMP V2 PHY for PCIE gen3 ports - PCS Misc registers */
+
+#define PCS_PCIE_POWER_STATE_CONFIG2			0x40c
+#define PCS_PCIE_POWER_STATE_CONFIG4			0x414
+#define PCS_PCIE_ENDPOINT_REFCLK_DRIVE			0x41c
+#define PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L		0x440
+#define PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_H		0x444
+#define PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L		0x448
+#define PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_H		0x44c
+#define PCS_PCIE_OSC_DTCT_CONFIG2			0x45c
+#define PCS_PCIE_OSC_DTCT_MODE2_CONFIG2			0x478
+#define PCS_PCIE_OSC_DTCT_MODE2_CONFIG4			0x480
+#define PCS_PCIE_OSC_DTCT_MODE2_CONFIG5			0x484
+#define PCS_PCIE_OSC_DTCT_ACTIONS			0x490
+#define PCS_PCIE_EQ_CONFIG1				0x4a0
+#define PCS_PCIE_EQ_CONFIG2				0x4a4
+#define PCS_PCIE_PRESET_P10_PRE				0x4bc
+#define PCS_PCIE_PRESET_P10_POST			0x4e0
+
 /* Only for QMP V2 PHY - QSERDES COM registers */
 #define QSERDES_COM_BG_TIMER				0x00c
 #define QSERDES_COM_SSC_EN_CENTER			0x010
-- 
2.30.2



From baruch at tkos.co.il  Tue Apr 20 12:21:40 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Tue, 20 Apr 2021 14:21:40 +0300
Subject: [PATCH 5/5] dt-bindings: pci: qcom: Document PCIe bindings for
 IPQ6018 SoC
In-Reply-To: <cover.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
Message-ID: <e285d5041b8c19d4a7fab4d1a3ce9dd2b487cbad.1618916235.git.baruch@tkos.co.il>

Document qcom,pcie-ipq6018. This is similar to the ipq8074 with a few
different clock sources, and one additional reset.

Signed-off-by: Baruch Siach <baruch at tkos.co.il>
---
 .../devicetree/bindings/pci/qcom,pcie.txt     | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 0da458a051b6..25f4def468bf 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -14,6 +14,7 @@
 			- "qcom,pcie-qcs404" for qcs404
 			- "qcom,pcie-sdm845" for sdm845
 			- "qcom,pcie-sm8250" for sm8250
+			- "qcom,pcie-ipq6018" for ipq6018
 
 - reg:
 	Usage: required
@@ -123,6 +124,16 @@
 			- "ahb"		AHB clock
 			- "aux"		Auxiliary clock
 
+- clock-names:
+	Usage: required for ipq6018
+	Value type: <stringlist>
+	Definition: Should contain the following entries
+			- "iface"	PCIe to SysNOC BIU clock
+			- "axi_m"	AXI Master clock
+			- "axi_s"	AXI Slave clock
+			- "axi_bridge"	AXI bridge clock
+			- "rchng"
+
 - clock-names:
 	Usage: required for qcs404
 	Value type: <stringlist>
@@ -209,6 +220,19 @@
 			- "ahb"			AHB Reset
 			- "axi_m_sticky"	AXI Master Sticky reset
 
+- reset-names:
+	Usage: required for ipq6018
+	Value type: <stringlist>
+	Definition: Should contain the following entries
+			- "pipe"		PIPE reset
+			- "sleep"		Sleep reset
+			- "sticky"		Core Sticky reset
+			- "axi_m"		AXI Master reset
+			- "axi_s"		AXI Slave reset
+			- "ahb"			AHB Reset
+			- "axi_m_sticky"	AXI Master Sticky reset
+			- "axi_s_sticky"	AXI Slave Sticky reset
+
 - reset-names:
 	Usage: required for qcs404
 	Value type: <stringlist>
-- 
2.30.2



From willy at infradead.org  Tue Apr 20 12:32:16 2021
From: willy at infradead.org (Matthew Wilcox)
Date: Tue, 20 Apr 2021 12:32:16 +0100
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAMuHMdXm1Zg=Wm-=tn5jUJwqVGUvCi5yDaW0PXWC2DEDYGcy5A@mail.gmail.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <CAMuHMdXm1Zg=Wm-=tn5jUJwqVGUvCi5yDaW0PXWC2DEDYGcy5A@mail.gmail.com>
Message-ID: <20210420113216.GA3596236@casper.infradead.org>

On Tue, Apr 20, 2021 at 09:39:54AM +0200, Geert Uytterhoeven wrote:
> > +++ b/include/linux/mm_types.h
> > @@ -97,10 +97,10 @@ struct page {
> >                 };
> >                 struct {        /* page_pool used by netstack */
> >                         /**
> > -                        * @dma_addr: might require a 64-bit value even on
> > +                        * @dma_addr: might require a 64-bit value on
> >                          * 32-bit architectures.
> >                          */
> > -                       dma_addr_t dma_addr;
> > +                       unsigned long dma_addr[2];
> 
> So we get two 64-bit words on 64-bit platforms, while only one is
> needed?

Not really.  This is part of the 5-word union in struct page, so the space
ends up being reserved anyway, event if it's not "assigned" to dma_addr.

> > +       dma_addr_t ret = page->dma_addr[0];
> > +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > +               ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16;
> 
> We don't seem to have a handy macro for a 32-bit left shift yet...
> 
> But you can also avoid the warning using
> 
>     ret |= (u64)page->dma_addr[1] << 32;

Sure.  It doesn't really matter which way we eliminate the warning;
the code is unreachable.

> > +{
> > +       page->dma_addr[0] = addr;
> > +       if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > +               page->dma_addr[1] = addr >> 16 >> 16;
> 
> ... but we do have upper_32_bits() for a 32-bit right shift.

Yep, that's what my current tree looks like.


From hverkuil-cisco at xs4all.nl  Tue Apr 20 12:35:50 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Tue, 20 Apr 2021 13:35:50 +0200
Subject: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl'
 register
In-Reply-To: <e7064bb1-69e6-4214-380d-c464b7832da5@collabora.com>
References: <20210407073534.376722-1-benjamin.gaignard@collabora.com>
 <20210407073534.376722-4-benjamin.gaignard@collabora.com>
 <7bcbb787d82f21d42563d8fb7e3c2e7d40123932.camel@pengutronix.de>
 <ffe9b3f5-94f5-453e-73f0-4b42d0454b63@collabora.com>
 <529b61b1b1e6030c92a7944c4864246521b2ccdd.camel@pengutronix.de>
 <36008691-d075-203d-0cac-2a012773ea34@collabora.com>
 <43a767f8-77f5-7937-c484-753a3123f6a2@xs4all.nl>
 <e7064bb1-69e6-4214-380d-c464b7832da5@collabora.com>
Message-ID: <0f23d42e-b858-c57d-3bf7-32b511e919d1@xs4all.nl>

On 20/04/2021 11:31, Benjamin Gaignard wrote:
> 
> Le 20/04/2021 ? 11:16, Hans Verkuil a ?crit?:
>> On 20/04/2021 11:10, Benjamin Gaignard wrote:
>>> Le 16/04/2021 ? 17:14, Lucas Stach a ?crit?:
>>>> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>>>>> Le 16/04/2021 ? 12:54, Lucas Stach a ?crit?:
>>>>>> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>>>>>>> In order to be able to share the control hardware block between
>>>>>>> VPUs use a syscon instead a ioremap it in the driver.
>>>>>>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>>>>>>> phandle is not found look at 'ctrl' reg-name.
>>>>>>> With the method it becomes useless to provide a list of register
>>>>>>> names so remove it.
>>>>>> Sorry for putting a spoke in the wheel after many iterations of the
>>>>>> series.
>>>>>>
>>>>>> We just discussed a way forward on how to handle the clocks and resets
>>>>>> provided by the blkctl block on i.MX8MM and later and it seems there is
>>>>>> a consensus on trying to provide virtual power domains from a blkctl
>>>>>> driver, controlling clocks and resets for the devices in the power
>>>>>> domain. I would like to avoid introducing yet another way of handling
>>>>>> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
>>>>>> what we are planning to do on the later chip generations.
>>>>>>
>>>>>> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
>>>>>> virtual power domain thing a shot.
>>>>> That could replace the 3 first patches and Dt patche of this series
>>>>> but that will not impact the hevc part, so I wonder if pure hevc patches
>>>>> could be merged anyway ?
>>>>> They are reviewed and don't depend of how the ctrl block is managed.
>>>> I'm not really in a position to give any informed opinion about that
>>>> hvec patches, as I only skimmed them, but I don't see any reason to
>>>> delay patches 04-11 from this series until the i.MX8M platform issues
>>>> are sorted. AFAICS those things are totally orthogonal.
>>> Hi Hans,
>>> What do you think about this proposal to split this series ?
>>> Get hevc part merged could allow me to continue to add features
>>> like scaling lists, compressed reference buffers and 10-bit supports.
>> Makes sense to me!
> 
> Great !
> If the latest version match your expectations how would you like to processed ?
> Can you merged patches 4 to 12 ? or should I resend them in a new shorted series ?

A separate patch series would be easier for me.

Regards,

	Hans

> 
> Regards,
> Benjamin
> 
>>
>> Regards,
>>
>> 	Hans
>>



From lkp at intel.com  Tue Apr 20 13:04:42 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 20:04:42 +0800
Subject: [PATCH v3 02/10] iommu/dma: Introduce generic helper to retrieve
 RMR info
In-Reply-To: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104201938.H3tHN9nd-lkp@intel.com>

Hi Shameer,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pm/linux-next]
[also build test WARNING on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/c68d4ba37ecc2173a2dc418799e23a184685d681
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout c68d4ba37ecc2173a2dc418799e23a184685d681
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/exynos/exynos_drm_dma.c:7:
>> include/linux/dma-iommu.h:92:31: warning: 'struct fwnode_handle' declared inside parameter list will not be visible outside of this definition or declaration
      92 | int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
         |                               ^~~~~~~~~~~~~
   include/linux/dma-iommu.h:93:1: error: expected identifier or '(' before '{' token
      93 | {
         | ^


vim +92 include/linux/dma-iommu.h

    91	
  > 92	int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
    93	{
    94		return 0;
    95	}
    96	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67483 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/c2558963/attachment-0001.gz>

From daniel.lezcano at linaro.org  Tue Apr 20 13:07:13 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 20 Apr 2021 14:07:13 +0200
Subject: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <20210320080646.49615-1-linux@fw-web.de>
References: <20210320080646.49615-1-linux@fw-web.de>
Message-ID: <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>

On 20/03/2021 09:06, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w at public-files.de>
> 
> add HWMON-support to mediateks thermanl driver to allow lm-sensors
> userspace tools read soc temperature
> 
> Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> ---
>  drivers/thermal/mtk_thermal.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 149c6d7fd5a0..e22d77d57458 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -23,6 +23,8 @@
>  #include <linux/reset.h>
>  #include <linux/types.h>
>  
> +#include "thermal_hwmon.h"
> +
>  /* AUXADC Registers */
>  #define AUXADC_CON1_SET_V	0x008
>  #define AUXADC_CON1_CLR_V	0x00c
> @@ -983,6 +985,13 @@ static void mtk_thermal_release_periodic_ts(struct mtk_thermal *mt,
>  	writel((tmp & (~0x10e)), mt->thermal_base + TEMP_MSRCTL1);
>  }
>  
> +static void mtk_thermal_hwmon_action(void *data)
> +{
> +	struct thermal_zone_device *zone = data;
> +
> +	thermal_remove_hwmon_sysfs(zone);
> +}
> +
>  static int mtk_thermal_probe(struct platform_device *pdev)
>  {
>  	int ret, i, ctrl_id;
> @@ -1087,6 +1096,19 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  		goto err_disable_clk_peri_therm;
>  	}
>  
> +#ifdef CONFIG_THERMAL_HWMON

No #ifdef in C file.

> +	tzdev->tzp->no_hwmon = false;
> +	ret = thermal_add_hwmon_sysfs(tzdev);
> +	if (ret)
> +		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
> +
> +	ret = devm_add_action(&pdev->dev, mtk_thermal_hwmon_action, tzdev);

devm_thermal_add_hwmon_sysfs() ?

> +	if (ret) {
> +		dev_err(&pdev->dev, "error in devm_add_action");
> +		mtk_thermal_hwmon_action(tzdev);
> +	}
> +#endif
> +
>  	return 0;
>  
>  err_disable_clk_peri_therm:
> 


-- 
<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 lkp at intel.com  Tue Apr 20 13:07:08 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 20:07:08 +0800
Subject: [PATCH v3 04/10] iommu/dma: Add a helper function to reserve
 RMRs for IOMMU drivers
In-Reply-To: <20210420082751.1829-5-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-5-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104201931.G85ORgKj-lkp@intel.com>

Hi Shameer,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pm/linux-next]
[also build test WARNING on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: m68k-randconfig-m031-20210420 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/2501962e423895e2e4f126ff5998b226f4803186
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout 2501962e423895e2e4f126ff5998b226f4803186
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/iommu/rockchip-iommu.c:13:
>> include/linux/dma-iommu.h:94:71: warning: 'struct iommu_rmr' declared inside parameter list will not be visible outside of this definition or declaration
      94 | static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
         |                                                                       ^~~~~~~~~
   include/linux/dma-iommu.h:100:1: error: expected identifier or '(' before '{' token
     100 | {
         | ^
   In file included from drivers/iommu/rockchip-iommu.c:13:
   include/linux/dma-iommu.h:94:13: warning: 'iommu_dma_get_rmr_resv_regions' defined but not used [-Wunused-function]
      94 | static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for ADI_AXI_ADC
   Depends on IIO && HAS_IOMEM && OF
   Selected by
   - AD9467 && IIO && SPI


vim +94 include/linux/dma-iommu.h

    93	
  > 94	static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
    95						   struct list_head *list)
    96	{
    97	}
    98	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25978 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/0737c720/attachment-0001.gz>

From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:38 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:38 +0200
Subject: [PATCH v10 1/9] media: hevc: Add fields and flags for hevc PPS
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-2-benjamin.gaignard@collabora.com>

Add fields and flags as they are defined in
7.4.3.3.1 "General picture parameter set RBSP semantics of the
H.265 ITU specification.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 .../userspace-api/media/v4l/ext-ctrls-codec.rst    | 14 ++++++++++++++
 include/media/hevc-ctrls.h                         |  4 ++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index b0de4e6e7ebd..aabcb0e63a5e 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3000,6 +3000,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``num_extra_slice_header_bits``
       -
+    * - __u8
+      - ``num_ref_idx_l0_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l0_active_minus1
+    * - __u8
+      - ``num_ref_idx_l1_default_active_minus1``
+      - Specifies the inferred value of num_ref_idx_l1_active_minus1
     * - __s8
       - ``init_qp_minus26``
       -
@@ -3110,6 +3116,14 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT``
       - 0x00040000
       -
+    * - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
+      - 0x00080000
+      - Specifies the presence of deblocking filter control syntax elements in
+        the PPS
+    * - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING``
+      - 0x00100000
+      - Specifies that tile column boundaries and likewise tile row boundaries
+        are distributed uniformly across the picture
 
 .. raw:: latex
 
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index b4cb2ef02f17..003f819ecb26 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -100,10 +100,14 @@ struct v4l2_ctrl_hevc_sps {
 #define V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER	(1ULL << 16)
 #define V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT		(1ULL << 17)
 #define V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT (1ULL << 18)
+#define V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT	(1ULL << 19)
+#define V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING			(1ULL << 20)
 
 struct v4l2_ctrl_hevc_pps {
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture parameter set */
 	__u8	num_extra_slice_header_bits;
+	__u8	num_ref_idx_l0_default_active_minus1;
+	__u8	num_ref_idx_l1_default_active_minus1;
 	__s8	init_qp_minus26;
 	__u8	diff_cu_qp_delta_depth;
 	__s8	pps_cb_qp_offset;
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:37 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:37 +0200
Subject: [PATCH v10 0/9] Add HANTRO G2/HEVC decoder support for IMX8MQ
Message-ID: <20210420121046.181889-1-benjamin.gaignard@collabora.com>

The IMX8MQ got two VPUs but until now only G1 has been enabled.
This series aim to add the second VPU (aka G2) and provide basic 
HEVC decoding support.

To be able to decode HEVC it is needed to add/update some of the
structures in the uapi. In addition of them one HANTRO dedicated
control is required to inform the driver of the number of bits to skip
at the beginning of the slice header.
The hardware require to allocate few auxiliary buffers to store the
references frame or tile size data.

The driver has been tested with fluster test suite stream.
For example with this command: ./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0

version 10:
 - Shorter version of the previous series without ctrl block patches
   and no DT modifications.
   The scope of this series is limited to HEVC support.

version 9:
 - Corrections in commits messages.
 - Define the dedicated control in hevc-controls.h
 - Add note in documentation.
 - Change max value of the dedicated control.
 - Rebased on media_tree/master branch.

version 8:
 - Add reviewed-by and ack-by tags 
 - Fix the warnings reported by kernel test robot
 - Only patch 9 (adding dedicated control), patch 11 (HEVC support) and
   patch 13 (DT changes) are still missing of review/ack tag.

version 7:
 - Remove 'q' from syscon phandle name to make usable for iMX8MM too.
   Update the bindings documentation.
 - Add review/ack tags.
 - Rebase on top of media_tree/master
 - Be more accurate when computing the size of the memory needed motion
   vectors.
 - Explain why the all clocks need to set in the both DT node.

version 6:
 - fix the errors reported by kernel test robot

version 5:
 - use syscon instead of VPU reset driver.
 - Do not break kernel/DT backward compatibility.
 - Add documentation for dedicated Hantro control.
 - Fix the remarks done by Ezequeil (typo, comments, unused function)
 - Run v4l2-compliance without errors (see below).
 - Do not add field to distinguish version, check postproc reg instead

version 4:
- Split the changes in hevc controls in 2 commits to make them easier to
  review.
- Change hantro_codec_ops run() prototype to return errors   
- Hantro v4l2 dedicated control is now only an integer
- rebase on top of VPU reset changes posted here:
  https://www.spinics.net/lists/arm-kernel/msg878440.html
- Various fix from previous remarks
- Limit the modifications in API to what the driver needs

version 3:
- Fix typo in Hantro v4l2 dedicated control
- Add documentation for the new structures and fields
- Rebased on top of media_tree for-linus-5.12-rc1 tag

version 2:
- remove all change related to scaling
- squash commits to a coherent split
- be more verbose about the added fields
- fix the comments done by Ezequiel about dma_alloc_coherent usage
- fix Dan's comments about control copy, reverse the test logic
in tile_buffer_reallocate, rework some goto and return cases.
- be more verbose about why I change the bindings
- remove all sign-off expect mime since it is confusing
- remove useless clocks in VPUs nodes

Benjamin Gaignard (9):
  media: hevc: Add fields and flags for hevc PPS
  media: hevc: Add decode params control
  media: hantro: change hantro_codec_ops run prototype to return errors
  media: hantro: Define HEVC codec profiles and supported features
  media: hantro: Only use postproc when post processed formats are
    defined
  media: uapi: Add a control for HANTRO driver
  media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
  media: hantro: Introduce G2/HEVC decoder
  media: hantro: IMX8M: add variant for G2/HEVC codec

 .../userspace-api/media/drivers/hantro.rst    |  19 +
 .../userspace-api/media/drivers/index.rst     |   1 +
 .../media/v4l/ext-ctrls-codec.rst             | 108 +++-
 .../media/v4l/vidioc-queryctrl.rst            |   6 +
 drivers/media/v4l2-core/v4l2-ctrls.c          |  28 +-
 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |  13 +-
 drivers/staging/media/hantro/hantro_drv.c     |  99 ++-
 .../staging/media/hantro/hantro_g1_h264_dec.c |  10 +-
 .../media/hantro/hantro_g1_mpeg2_dec.c        |   4 +-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |   6 +-
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |   4 +-
 drivers/staging/media/hantro/hantro_hevc.c    | 327 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  69 +-
 .../staging/media/hantro/hantro_postproc.c    |  14 +
 drivers/staging/media/hantro/hantro_v4l2.c    |   5 +-
 drivers/staging/media/hantro/imx8m_vpu_hw.c   |  74 ++-
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |   4 +-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |   4 +-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |   6 +-
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   6 +
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |   2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  |  12 +-
 include/media/hevc-ctrls.h                    |  46 +-
 27 files changed, 1586 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:40 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:40 +0200
Subject: [PATCH v10 3/9] media: hantro: change hantro_codec_ops run prototype
 to return errors
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-4-benjamin.gaignard@collabora.com>

Change hantro_codec_ops run prototype from 'void' to 'int'.
This allows the driver to cancel the job if an error occurs while configuring
the hardware.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/hantro_drv.c     |  4 +++-
 .../staging/media/hantro/hantro_g1_h264_dec.c | 10 +++++++---
 .../media/hantro/hantro_g1_mpeg2_dec.c        |  4 +++-
 .../staging/media/hantro/hantro_g1_vp8_dec.c  |  6 ++++--
 .../staging/media/hantro/hantro_h1_jpeg_enc.c |  4 +++-
 drivers/staging/media/hantro/hantro_hw.h      | 19 ++++++++++---------
 .../media/hantro/rk3399_vpu_hw_jpeg_enc.c     |  4 +++-
 .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c    |  4 +++-
 .../media/hantro/rk3399_vpu_hw_vp8_dec.c      |  6 ++++--
 9 files changed, 40 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 595e82a82728..02c5c2f1a88b 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -161,7 +161,9 @@ static void device_run(void *priv)
 
 	v4l2_m2m_buf_copy_metadata(src, dst, true);
 
-	ctx->codec_ops->run(ctx);
+	if (ctx->codec_ops->run(ctx))
+		goto err_cancel_job;
+
 	return;
 
 err_cancel_job:
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 845bef73d218..5c792b7bcb79 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -273,13 +273,15 @@ static void set_buffers(struct hantro_ctx *ctx)
 	vdpu_write_relaxed(vpu, ctx->h264_dec.priv.dma, G1_REG_ADDR_QTABLE);
 }
 
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
+	int ret;
 
 	/* Prepare the H264 decoder context. */
-	if (hantro_h264_dec_prepare_run(ctx))
-		return;
+	ret = hantro_h264_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
 
 	/* Configure hardware registers. */
 	set_params(ctx);
@@ -301,4 +303,6 @@ void hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
 			   G1_REG_CONFIG_DEC_CLK_GATE_E,
 			   G1_REG_CONFIG);
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
index 6386a3989bfe..5e8943d31dc5 100644
--- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
@@ -155,7 +155,7 @@ hantro_g1_mpeg2_dec_set_buffers(struct hantro_dev *vpu, struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, backward_addr, G1_REG_REFER3_BASE);
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -248,4 +248,6 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = G1_REG_DEC_E(1);
 	vdpu_write(vpu, reg, G1_SWREG(1));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 57002ba70176..96622a7f8279 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -425,7 +425,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, G1_REG_ADDR_DST);
 }
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -438,7 +438,7 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -498,4 +498,6 @@ void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
index b88dc4ed06db..56cf261a8e95 100644
--- a/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
+++ b/drivers/staging/media/hantro/hantro_h1_jpeg_enc.c
@@ -88,7 +88,7 @@ hantro_h1_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -136,6 +136,8 @@ void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	vepu_write(vpu, reg, H1_REG_ENC_CTRL);
+
+	return 0;
 }
 
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx)
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 83b3e42b63a3..6a34ddfa34b7 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -133,14 +133,15 @@ struct hantro_postproc_ctx {
  *		Optional and called from process context.
  * @run:	Start single {en,de)coding job. Called from atomic context
  *		to indicate that a pair of buffers is ready and the hardware
- *		should be programmed and started.
+ *		should be programmed and started. Returns zero if OK, a
+ *		negative value in error cases.
  * @done:	Read back processing results and additional data from hardware.
  * @reset:	Reset the hardware in case of a timeout.
  */
 struct hantro_codec_ops {
 	int (*init)(struct hantro_ctx *ctx);
 	void (*exit)(struct hantro_ctx *ctx);
-	void (*run)(struct hantro_ctx *ctx);
+	int (*run)(struct hantro_ctx *ctx);
 	void (*done)(struct hantro_ctx *ctx);
 	void (*reset)(struct hantro_ctx *ctx);
 };
@@ -176,8 +177,8 @@ void hantro_irq_done(struct hantro_dev *vpu,
 void hantro_start_prepare_run(struct hantro_ctx *ctx);
 void hantro_end_prepare_run(struct hantro_ctx *ctx);
 
-void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
+int hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
 int hantro_jpeg_enc_init(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_exit(struct hantro_ctx *ctx);
 void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
@@ -185,7 +186,7 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
 dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
 				   unsigned int dpb_idx);
 int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
-void hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
@@ -216,15 +217,15 @@ hantro_h264_mv_size(unsigned int width, unsigned int height)
 	return 64 * MB_WIDTH(width) * MB_WIDTH(height) + 32;
 }
 
-void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_copy_qtable(u8 *qtable,
 	const struct v4l2_ctrl_mpeg2_quantization *ctrl);
 int hantro_mpeg2_dec_init(struct hantro_ctx *ctx);
 void hantro_mpeg2_dec_exit(struct hantro_ctx *ctx);
 
-void hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
+int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx);
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx);
 int hantro_vp8_dec_init(struct hantro_ctx *ctx);
 void hantro_vp8_dec_exit(struct hantro_ctx *ctx);
 void hantro_vp8_prob_update(struct hantro_ctx *ctx,
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
index 3498e6124acd..3a27ebef4f38 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_jpeg_enc.c
@@ -118,7 +118,7 @@ rk3399_vpu_jpeg_enc_set_qtable(struct hantro_dev *vpu,
 	}
 }
 
-void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
+int rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -168,4 +168,6 @@ void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx)
 	/* Kick the watchdog and start encoding */
 	hantro_end_prepare_run(ctx);
 	vepu_write(vpu, reg, VEPU_REG_ENCODE_START);
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
index f610fa5b4335..4bd3080abbc1 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
@@ -157,7 +157,7 @@ rk3399_vpu_mpeg2_dec_set_buffers(struct hantro_dev *vpu,
 	vdpu_write_relaxed(vpu, backward_addr, VDPU_REG_REFER3_BASE);
 }
 
-void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
 	struct vb2_v4l2_buffer *src_buf, *dst_buf;
@@ -254,4 +254,6 @@ void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx)
 
 	reg = vdpu_read(vpu, VDPU_SWREG(57)) | VDPU_REG_DEC_E(1);
 	vdpu_write(vpu, reg, VDPU_SWREG(57));
+
+	return 0;
 }
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
index 8661a3cc1e6b..e5d20fe5b007 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_vp8_dec.c
@@ -503,7 +503,7 @@ static void cfg_buffers(struct hantro_ctx *ctx,
 	vdpu_write_relaxed(vpu, dst_dma, VDPU_REG_ADDR_DST);
 }
 
-void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
+int rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 {
 	const struct v4l2_ctrl_vp8_frame *hdr;
 	struct hantro_dev *vpu = ctx->dev;
@@ -516,7 +516,7 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 
 	hdr = hantro_get_ctrl(ctx, V4L2_CID_STATELESS_VP8_FRAME);
 	if (WARN_ON(!hdr))
-		return;
+		return -EINVAL;
 
 	/* Reset segment_map buffer in keyframe */
 	if (V4L2_VP8_FRAME_IS_KEY_FRAME(hdr) && ctx->vp8_dec.segment_map.cpu)
@@ -589,4 +589,6 @@ void rk3399_vpu_vp8_dec_run(struct hantro_ctx *ctx)
 	hantro_end_prepare_run(ctx);
 
 	hantro_reg_write(vpu, &vp8_dec_start_dec, 1);
+
+	return 0;
 }
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:39 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:39 +0200
Subject: [PATCH v10 2/9] media: hevc: Add decode params control
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-3-benjamin.gaignard@collabora.com>

Add decode params control and the associated structure to group
all the information that are needed to decode a reference frame as
is described in ITU-T Rec. H.265 section "8.3.2 Decoding process
for reference picture set".

Adapt Cedrus driver to these changes.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 .../media/v4l/ext-ctrls-codec.rst             | 94 +++++++++++++++----
 .../media/v4l/vidioc-queryctrl.rst            |  6 ++
 drivers/media/v4l2-core/v4l2-ctrls.c          | 28 ++++--
 drivers/staging/media/sunxi/cedrus/cedrus.c   |  6 ++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  1 +
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_h265.c  | 12 ++-
 include/media/hevc-ctrls.h                    | 29 ++++--
 8 files changed, 138 insertions(+), 40 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index aabcb0e63a5e..7b90cb939e9d 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3214,9 +3214,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - __u8
       - ``pic_struct``
       -
-    * - __u8
-      - ``num_active_dpb_entries``
-      - The number of entries in ``dpb``.
     * - __u8
       - ``ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L0 reference elements as indices in the DPB.
@@ -3224,22 +3221,8 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
       - ``ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
       - The list of L1 reference elements as indices in the DPB.
     * - __u8
-      - ``num_rps_poc_st_curr_before``
-      - The number of reference pictures in the short-term set that come before
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_st_curr_after``
-      - The number of reference pictures in the short-term set that come after
-        the current frame.
-    * - __u8
-      - ``num_rps_poc_lt_curr``
-      - The number of reference pictures in the long-term set.
-    * - __u8
-      - ``padding[7]``
+      - ``padding``
       - Applications and drivers must set this to zero.
-    * - struct :c:type:`v4l2_hevc_dpb_entry`
-      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
-      - The decoded picture buffer, for meta-data about reference frames.
     * - struct :c:type:`v4l2_hevc_pred_weight_table`
       - ``pred_weight_table``
       - The prediction weight coefficients for inter-picture prediction.
@@ -3492,3 +3475,78 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     encoding the next frame queued after setting this control.
     This provides a bitmask which consists of bits [0, LTR_COUNT-1].
     This is applicable to the H264 and HEVC encoders.
+
+``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS (struct)``
+    Specifies various decode parameters, especially the references picture order
+    count (POC) for all the lists (short, long, before, current, after) and the
+    number of entries for each of them.
+    These parameters are defined according to :ref:`hevc`.
+    They are described in section 8.3 "Slice decoding process" of the
+    specification.
+
+.. c:type:: v4l2_ctrl_hevc_decode_params
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_hevc_decode_params
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - __s32
+      - ``pic_order_cnt_val``
+      - PicOrderCntVal as described in section 8.3.1 "Decoding process
+        for picture order count" of the specification.
+    * - __u8
+      - ``num_active_dpb_entries``
+      - The number of entries in ``dpb``.
+    * - struct :c:type:`v4l2_hevc_dpb_entry`
+      - ``dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - The decoded picture buffer, for meta-data about reference frames.
+    * - __u8
+      - ``num_poc_st_curr_before``
+      - The number of reference pictures in the short-term set that come before
+        the current frame.
+    * - __u8
+      - ``num_poc_st_curr_after``
+      - The number of reference pictures in the short-term set that come after
+        the current frame.
+    * - __u8
+      - ``num_poc_lt_curr``
+      - The number of reference pictures in the long-term set.
+    * - __u8
+      - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u8
+      - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]``
+      - PocLtCurr as described in section 8.3.2 "Decoding process for reference
+        picture set.
+    * - __u64
+      - ``flags``
+      - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>`
+
+.. _hevc_decode_params_flags:
+
+``Decode Parameters Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 2
+
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC``
+      - 0x00000001
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC``
+      - 0x00000002
+      -
+    * - ``V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR``
+      - 0x00000004
+      -
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index 8a285daedc6a..cf8f94693c39 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -495,6 +495,12 @@ See also the examples in :ref:`control`.
       - n/a
       - A struct :c:type:`v4l2_ctrl_vp8_frame`, containing VP8
 	frame parameters for stateless video decoders.
+    * - ``V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS``
+      - n/a
+      - n/a
+      - n/a
+      - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC
+	decoding parameters for stateless video decoders.
 
 .. raw:: latex
 
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 0d7fe1bd975a..0993072ee5c3 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MPEG_VIDEO_HEVC_SPS:			return "HEVC Sequence Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_PPS:			return "HEVC Picture Parameter Set";
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:		return "HEVC Slice Parameters";
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:		return "HEVC Decode Parameters";
 	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE:		return "HEVC Decode Mode";
 	case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE:		return "HEVC Start Code";
 
@@ -1526,6 +1527,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
 		*type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
 		break;
+	case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
+		*type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
+		break;
 	case V4L2_CID_UNIT_CELL_SIZE:
 		*type = V4L2_CTRL_TYPE_AREA;
 		*flags |= V4L2_CTRL_FLAG_READ_ONLY;
@@ -1895,6 +1899,7 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 	struct v4l2_ctrl_hevc_pps *p_hevc_pps;
 	struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
 	struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;
+	struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;
 	struct v4l2_area *area;
 	void *p = ptr.p + idx * ctrl->elem_size;
 	unsigned int i;
@@ -2170,24 +2175,21 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 		zero_padding(*p_hevc_pps);
 		break;
 
-	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
-		p_hevc_slice_params = p;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		p_hevc_decode_params = p;
 
-		if (p_hevc_slice_params->num_active_dpb_entries >
+		if (p_hevc_decode_params->num_active_dpb_entries >
 		    V4L2_HEVC_DPB_ENTRIES_NUM_MAX)
 			return -EINVAL;
 
-		zero_padding(p_hevc_slice_params->pred_weight_table);
-
-		for (i = 0; i < p_hevc_slice_params->num_active_dpb_entries;
+		for (i = 0; i < p_hevc_decode_params->num_active_dpb_entries;
 		     i++) {
 			struct v4l2_hevc_dpb_entry *dpb_entry =
-				&p_hevc_slice_params->dpb[i];
+				&p_hevc_decode_params->dpb[i];
 
 			zero_padding(*dpb_entry);
 		}
 
-		zero_padding(*p_hevc_slice_params);
 		break;
 
 	case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
@@ -2237,6 +2239,13 @@ static int std_validate_compound(const struct v4l2_ctrl *ctrl, u32 idx,
 
 		break;
 
+	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
+		p_hevc_slice_params = p;
+
+		zero_padding(p_hevc_slice_params->pred_weight_table);
+		zero_padding(*p_hevc_slice_params);
+		break;
+
 	case V4L2_CTRL_TYPE_AREA:
 		area = p;
 		if (!area->width || !area->height)
@@ -2947,6 +2956,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
 	case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
 		elem_size = sizeof(struct v4l2_ctrl_hevc_slice_params);
 		break;
+	case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
+		elem_size = sizeof(struct v4l2_ctrl_hevc_decode_params);
+		break;
 	case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
 		elem_size = sizeof(struct v4l2_ctrl_hdr10_cll_info);
 		break;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 92812d1a39d4..6f095ae53818 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -151,6 +151,12 @@ static const struct cedrus_control cedrus_controls[] = {
 		},
 		.codec		= CEDRUS_CODEC_VP8,
 	},
+	{
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
+		.codec		= CEDRUS_CODEC_H265,
+	},
 };
 
 #define CEDRUS_CONTROLS_COUNT	ARRAY_SIZE(cedrus_controls)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 15f147dad4cb..930922bd4e46 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -76,6 +76,7 @@ struct cedrus_h265_run {
 	const struct v4l2_ctrl_hevc_sps			*sps;
 	const struct v4l2_ctrl_hevc_pps			*pps;
 	const struct v4l2_ctrl_hevc_slice_params	*slice_params;
+	const struct v4l2_ctrl_hevc_decode_params	*decode_params;
 };
 
 struct cedrus_vp8_run {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index d696b3ec70c0..8a7e44f92812 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -68,6 +68,8 @@ void cedrus_device_run(void *priv)
 			V4L2_CID_MPEG_VIDEO_HEVC_PPS);
 		run.h265.slice_params = cedrus_find_control_data(ctx,
 			V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS);
+		run.h265.decode_params = cedrus_find_control_data(ctx,
+			V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
 		break;
 
 	case V4L2_PIX_FMT_VP8_FRAME:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
index ce497d0197df..397a4ba5df4c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
@@ -245,6 +245,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	const struct v4l2_ctrl_hevc_sps *sps;
 	const struct v4l2_ctrl_hevc_pps *pps;
 	const struct v4l2_ctrl_hevc_slice_params *slice_params;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
 	const struct v4l2_hevc_pred_weight_table *pred_weight_table;
 	dma_addr_t src_buf_addr;
 	dma_addr_t src_buf_end_addr;
@@ -256,6 +257,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	sps = run->h265.sps;
 	pps = run->h265.pps;
 	slice_params = run->h265.slice_params;
+	decode_params = run->h265.decode_params;
 	pred_weight_table = &slice_params->pred_weight_table;
 
 	/* MV column buffer size and allocation. */
@@ -487,7 +489,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	reg = VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_TC_OFFSET_DIV2(slice_params->slice_tc_offset_div2) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_BETA_OFFSET_DIV2(slice_params->slice_beta_offset_div2) |
-	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(slice_params->num_rps_poc_st_curr_after == 0) |
+	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_POC_BIGEST_IN_RPS_ST(decode_params->num_poc_st_curr_after == 0) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CR_QP_OFFSET(slice_params->slice_cr_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_CB_QP_OFFSET(slice_params->slice_cb_qp_offset) |
 	      VE_DEC_H265_DEC_SLICE_HDR_INFO1_SLICE_QP_DELTA(slice_params->slice_qp_delta);
@@ -527,8 +529,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 	cedrus_write(dev, VE_DEC_H265_NEIGHBOR_INFO_ADDR, reg);
 
 	/* Write decoded picture buffer in pic list. */
-	cedrus_h265_frame_info_write_dpb(ctx, slice_params->dpb,
-					 slice_params->num_active_dpb_entries);
+	cedrus_h265_frame_info_write_dpb(ctx, decode_params->dpb,
+					 decode_params->num_active_dpb_entries);
 
 	/* Output frame. */
 
@@ -545,7 +547,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 0 (for P/B frames). */
 	if (slice_params->slice_type != V4L2_HEVC_SLICE_TYPE_I) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l0,
 					       slice_params->num_ref_idx_l0_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST0);
@@ -564,7 +566,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 
 	/* Reference picture list 1 (for B frames). */
 	if (slice_params->slice_type == V4L2_HEVC_SLICE_TYPE_B) {
-		cedrus_h265_ref_pic_list_write(dev, slice_params->dpb,
+		cedrus_h265_ref_pic_list_write(dev, decode_params->dpb,
 					       slice_params->ref_idx_l1,
 					       slice_params->num_ref_idx_l1_active_minus1 + 1,
 					       VE_DEC_H265_SRAM_OFFSET_REF_PIC_LIST1);
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 003f819ecb26..8e0109eea454 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -19,6 +19,7 @@
 #define V4L2_CID_MPEG_VIDEO_HEVC_SPS		(V4L2_CID_CODEC_BASE + 1008)
 #define V4L2_CID_MPEG_VIDEO_HEVC_PPS		(V4L2_CID_CODEC_BASE + 1009)
 #define V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS	(V4L2_CID_CODEC_BASE + 1010)
+#define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS	(V4L2_CID_CODEC_BASE + 1012)
 #define V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE	(V4L2_CID_CODEC_BASE + 1015)
 #define V4L2_CID_MPEG_VIDEO_HEVC_START_CODE	(V4L2_CID_CODEC_BASE + 1016)
 
@@ -26,6 +27,7 @@
 #define V4L2_CTRL_TYPE_HEVC_SPS 0x0120
 #define V4L2_CTRL_TYPE_HEVC_PPS 0x0121
 #define V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS 0x0122
+#define V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS 0x0124
 
 enum v4l2_mpeg_video_hevc_decode_mode {
 	V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_SLICE_BASED,
@@ -194,18 +196,10 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u8	pic_struct;
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	__u8	num_active_dpb_entries;
 	__u8	ref_idx_l0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 	__u8	ref_idx_l1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
 
-	__u8	num_rps_poc_st_curr_before;
-	__u8	num_rps_poc_st_curr_after;
-	__u8	num_rps_poc_lt_curr;
-
-	__u8	padding;
-
-	/* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */
-	struct v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	padding[5];
 
 	/* ISO/IEC 23008-2, ITU-T Rec. H.265: Weighted prediction parameter */
 	struct v4l2_hevc_pred_weight_table pred_weight_table;
@@ -213,4 +207,21 @@ struct v4l2_ctrl_hevc_slice_params {
 	__u64	flags;
 };
 
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC		0x1
+#define V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC		0x2
+#define V4L2_HEVC_DECODE_PARAM_FLAG_NO_OUTPUT_OF_PRIOR  0x4
+
+struct v4l2_ctrl_hevc_decode_params {
+	__s32	pic_order_cnt_val;
+	__u8	num_active_dpb_entries;
+	struct	v4l2_hevc_dpb_entry dpb[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	num_poc_st_curr_before;
+	__u8	num_poc_st_curr_after;
+	__u8	num_poc_lt_curr;
+	__u8	poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u8	poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX];
+	__u64	flags;
+};
+
 #endif
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:41 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:41 +0200
Subject: [PATCH v10 4/9] media: hantro: Define HEVC codec profiles and
 supported features
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-5-benjamin.gaignard@collabora.com>

Define which HEVC profiles (up to level 5.1) and features
(no scaling, no 10 bits) are supported by the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/hantro.h     |  3 ++
 drivers/staging/media/hantro/hantro_drv.c | 58 +++++++++++++++++++++++
 2 files changed, 61 insertions(+)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 6c1b888abe75..4368c0962768 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -34,6 +34,7 @@ struct hantro_codec_ops;
 #define HANTRO_MPEG2_DECODER	BIT(16)
 #define HANTRO_VP8_DECODER	BIT(17)
 #define HANTRO_H264_DECODER	BIT(18)
+#define HANTRO_HEVC_DECODER	BIT(19)
 #define HANTRO_DECODERS		0xffff0000
 
 /**
@@ -99,6 +100,7 @@ struct hantro_variant {
  * @HANTRO_MODE_H264_DEC: H264 decoder.
  * @HANTRO_MODE_MPEG2_DEC: MPEG-2 decoder.
  * @HANTRO_MODE_VP8_DEC: VP8 decoder.
+ * @HANTRO_MODE_HEVC_DEC: HEVC decoder.
  */
 enum hantro_codec_mode {
 	HANTRO_MODE_NONE = -1,
@@ -106,6 +108,7 @@ enum hantro_codec_mode {
 	HANTRO_MODE_H264_DEC,
 	HANTRO_MODE_MPEG2_DEC,
 	HANTRO_MODE_VP8_DEC,
+	HANTRO_MODE_HEVC_DEC,
 };
 
 /*
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 02c5c2f1a88b..d9a3a5ef9330 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -245,6 +245,18 @@ static int hantro_try_ctrl(struct v4l2_ctrl *ctrl)
 		if (sps->bit_depth_luma_minus8 != 0)
 			/* Only 8-bit is supported */
 			return -EINVAL;
+	} else if (ctrl->id == V4L2_CID_MPEG_VIDEO_HEVC_SPS) {
+		const struct v4l2_ctrl_hevc_sps *sps = ctrl->p_new.p_hevc_sps;
+
+		if (sps->bit_depth_luma_minus8 != sps->bit_depth_chroma_minus8)
+			/* Luma and chroma bit depth mismatch */
+			return -EINVAL;
+		if (sps->bit_depth_luma_minus8 != 0)
+			/* Only 8-bit is supported */
+			return -EINVAL;
+		if (sps->flags & V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED)
+			/* No scaling support */
+			return -EINVAL;
 	}
 	return 0;
 }
@@ -351,6 +363,52 @@ static const struct hantro_ctrl controls[] = {
 			.def = V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
 		}
 	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.max = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+			.def = V4L2_MPEG_VIDEO_HEVC_DECODE_MODE_FRAME_BASED,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_START_CODE,
+			.min = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.max = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+			.def = V4L2_MPEG_VIDEO_HEVC_START_CODE_ANNEX_B,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
+			.min = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+			.max = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
+			.def = V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
+			.min = V4L2_MPEG_VIDEO_HEVC_LEVEL_1,
+			.max = V4L2_MPEG_VIDEO_HEVC_LEVEL_5_1,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
+			.ops = &hantro_ctrl_ops,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_PPS,
+		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
+		},
 	},
 };
 
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:43 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:43 +0200
Subject: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-7-benjamin.gaignard@collabora.com>

The HEVC HANTRO driver needs to know the number of bits to skip at
the beginning of the slice header.
That is a hardware specific requirement so create a dedicated control
for this purpose.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 .../userspace-api/media/drivers/hantro.rst    | 19 +++++++++++++++++++
 .../userspace-api/media/drivers/index.rst     |  1 +
 include/media/hevc-ctrls.h                    | 13 +++++++++++++
 3 files changed, 33 insertions(+)
 create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst

diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst
new file mode 100644
index 000000000000..cd9754b4e005
--- /dev/null
+++ b/Documentation/userspace-api/media/drivers/hantro.rst
@@ -0,0 +1,19 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Hantro video decoder driver
+===========================
+
+The Hantro video decoder driver implements the following driver-specific controls:
+
+``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
+    Specifies to Hantro HEVC video decoder driver the number of data (in bits) to
+    skip in the slice segment header.
+    If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+    to before syntax element "slice_temporal_mvp_enabled_flag".
+    If IDR, the skipped bits are just "pic_output_flag"
+    (separate_colour_plane_flag is not supported).
+
+.. note::
+
+        This control is not yet part of the public kernel API and
+        it is expected to change.
diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
index 1a9038f5f9fa..12e3c512d718 100644
--- a/Documentation/userspace-api/media/drivers/index.rst
+++ b/Documentation/userspace-api/media/drivers/index.rst
@@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux.
 
 	ccs
 	cx2341x-uapi
+        hantro
 	imx-uapi
 	max2175
 	meye-uapi
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index 8e0109eea454..b713eeed1915 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -224,4 +224,17 @@ struct v4l2_ctrl_hevc_decode_params {
 	__u64	flags;
 };
 
+/*  MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */
+#define V4L2_CID_CODEC_HANTRO_BASE				(V4L2_CTRL_CLASS_CODEC | 0x1200)
+/*
+ * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
+ * the number of data (in bits) to skip in the
+ * slice segment header.
+ * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
+ * to before syntax element "slice_temporal_mvp_enabled_flag".
+ * If IDR, the skipped bits are just "pic_output_flag"
+ * (separate_colour_plane_flag is not supported).
+ */
+#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP	(V4L2_CID_CODEC_HANTRO_BASE + 0)
+
 #endif
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:44 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:44 +0200
Subject: [PATCH v10 7/9] media: hantro: handle V4L2_PIX_FMT_HEVC_SLICE control
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-8-benjamin.gaignard@collabora.com>

Make sure that V4L2_PIX_FMT_HEVC_SLICE is correctly handled by the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/hantro_v4l2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 77d7fe62ce81..0655324fd0d4 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -392,6 +392,7 @@ hantro_update_requires_request(struct hantro_ctx *ctx, u32 fourcc)
 	case V4L2_PIX_FMT_MPEG2_SLICE:
 	case V4L2_PIX_FMT_VP8_FRAME:
 	case V4L2_PIX_FMT_H264_SLICE:
+	case V4L2_PIX_FMT_HEVC_SLICE:
 		ctx->fh.m2m_ctx->out_q_ctx.q.requires_requests = true;
 		break;
 	default:
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:42 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:42 +0200
Subject: [PATCH v10 5/9] media: hantro: Only use postproc when post processed
 formats are defined
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-6-benjamin.gaignard@collabora.com>

If the variant doesn't support postprocessed formats make sure it will
be ok.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/hantro.h          |  8 ++------
 drivers/staging/media/hantro/hantro_postproc.c | 14 ++++++++++++++
 drivers/staging/media/hantro/hantro_v4l2.c     |  4 +++-
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index 4368c0962768..e50d39b51902 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -413,12 +413,8 @@ hantro_get_dst_buf(struct hantro_ctx *ctx)
 	return v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 }
 
-static inline bool
-hantro_needs_postproc(const struct hantro_ctx *ctx,
-		      const struct hantro_fmt *fmt)
-{
-	return !ctx->is_encoder && fmt->fourcc != V4L2_PIX_FMT_NV12;
-}
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt);
 
 static inline dma_addr_t
 hantro_get_dec_buf_addr(struct hantro_ctx *ctx, struct vb2_buffer *vb)
diff --git a/drivers/staging/media/hantro/hantro_postproc.c b/drivers/staging/media/hantro/hantro_postproc.c
index 6d2a8f2a8f0b..ed8916c950a4 100644
--- a/drivers/staging/media/hantro/hantro_postproc.c
+++ b/drivers/staging/media/hantro/hantro_postproc.c
@@ -50,6 +50,20 @@ const struct hantro_postproc_regs hantro_g1_postproc_regs = {
 	.display_width = {G1_REG_PP_DISPLAY_WIDTH, 0, 0xfff},
 };
 
+bool hantro_needs_postproc(const struct hantro_ctx *ctx,
+			   const struct hantro_fmt *fmt)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder)
+		return false;
+
+	if (!vpu->variant->postproc_fmts)
+		return false;
+
+	return fmt->fourcc != V4L2_PIX_FMT_NV12;
+}
+
 void hantro_postproc_enable(struct hantro_ctx *ctx)
 {
 	struct hantro_dev *vpu = ctx->dev;
diff --git a/drivers/staging/media/hantro/hantro_v4l2.c b/drivers/staging/media/hantro/hantro_v4l2.c
index 1bc118e375a1..77d7fe62ce81 100644
--- a/drivers/staging/media/hantro/hantro_v4l2.c
+++ b/drivers/staging/media/hantro/hantro_v4l2.c
@@ -55,7 +55,9 @@ static const struct hantro_fmt *
 hantro_get_postproc_formats(const struct hantro_ctx *ctx,
 			    unsigned int *num_fmts)
 {
-	if (ctx->is_encoder) {
+	struct hantro_dev *vpu = ctx->dev;
+
+	if (ctx->is_encoder || !vpu->variant->postproc_fmts) {
 		*num_fmts = 0;
 		return NULL;
 	}
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:46 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:46 +0200
Subject: [PATCH v10 9/9] media: hantro: IMX8M: add variant for G2/HEVC codec
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-10-benjamin.gaignard@collabora.com>

Add variant to IMX8M to enable G2/HEVC codec.
Define the capabilities for the hardware up to 3840x2160.
G2 doesn't have a postprocessor, uses the same clocks and has it
own interrupt.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/hantro_drv.c   |  1 +
 drivers/staging/media/hantro/hantro_hw.h    |  1 +
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 74 ++++++++++++++++++++-
 3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index 905a69758b37..d6f4958f6292 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -574,6 +574,7 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_IMX8M
 	{ .compatible = "nxp,imx8mq-vpu", .data = &imx8mq_vpu_variant, },
+	{ .compatible = "nxp,imx8mq-vpu-g2", .data = &imx8mq_vpu_g2_variant },
 #endif
 	{ /* sentinel */ }
 };
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 41f3d5b92357..682fea1fe914 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -205,6 +205,7 @@ extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant imx8mq_vpu_g2_variant;
 
 extern const struct hantro_postproc_regs hantro_g1_postproc_regs;
 
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index c222de075ef4..2a6ac5248f6e 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -11,6 +11,7 @@
 #include "hantro.h"
 #include "hantro_jpeg.h"
 #include "hantro_g1_regs.h"
+#include "hantro_g2_regs.h"
 
 #define CTRL_SOFT_RESET		0x00
 #define RESET_G1		BIT(1)
@@ -130,6 +131,26 @@ static const struct hantro_fmt imx8m_vpu_dec_fmts[] = {
 	},
 };
 
+static const struct hantro_fmt imx8m_vpu_g2_dec_fmts[] = {
+	{
+		.fourcc = V4L2_PIX_FMT_NV12,
+		.codec_mode = HANTRO_MODE_NONE,
+	},
+	{
+		.fourcc = V4L2_PIX_FMT_HEVC_SLICE,
+		.codec_mode = HANTRO_MODE_HEVC_DEC,
+		.max_depth = 2,
+		.frmsize = {
+			.min_width = 48,
+			.max_width = 3840,
+			.step_width = MB_DIM,
+			.min_height = 48,
+			.max_height = 2160,
+			.step_height = MB_DIM,
+		},
+	},
+};
+
 static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 {
 	struct hantro_dev *vpu = dev_id;
@@ -148,6 +169,24 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static irqreturn_t imx8m_vpu_g2_irq(int irq, void *dev_id)
+{
+	struct hantro_dev *vpu = dev_id;
+	enum vb2_buffer_state state;
+	u32 status;
+
+	status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+	state = (status & HEVC_REG_INTERRUPT_DEC_RDY_INT) ?
+		 VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+	vdpu_write(vpu, 0, HEVC_REG_INTERRUPT);
+	vdpu_write(vpu, HEVC_REG_CONFIG_DEC_CLK_GATE_E, HEVC_REG_CONFIG);
+
+	hantro_irq_done(vpu, state);
+
+	return IRQ_HANDLED;
+}
+
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
 	vpu->dec_base = vpu->reg_bases[0];
@@ -163,6 +202,13 @@ static void imx8m_vpu_g1_reset(struct hantro_ctx *ctx)
 	imx8m_soft_reset(vpu, RESET_G1);
 }
 
+static void imx8m_vpu_g2_reset(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+
+	imx8m_soft_reset(vpu, RESET_G2);
+}
+
 /*
  * Supported codec ops.
  */
@@ -188,13 +234,25 @@ static const struct hantro_codec_ops imx8mq_vpu_codec_ops[] = {
 	},
 };
 
+static const struct hantro_codec_ops imx8mq_vpu_g2_codec_ops[] = {
+	[HANTRO_MODE_HEVC_DEC] = {
+		.run = hantro_g2_hevc_dec_run,
+		.reset = imx8m_vpu_g2_reset,
+		.init = hantro_hevc_dec_init,
+		.exit = hantro_hevc_dec_exit,
+	},
+};
+
 /*
  * VPU variants.
  */
 
 static const struct hantro_irq imx8mq_irqs[] = {
 	{ "g1", imx8m_vpu_g1_irq },
-	{ "g2", NULL /* TODO: imx8m_vpu_g2_irq */ },
+};
+
+static const struct hantro_irq imx8mq_g2_irqs[] = {
+	{ "g2", imx8m_vpu_g2_irq },
 };
 
 static const char * const imx8mq_clk_names[] = { "g1", "g2", "bus" };
@@ -218,3 +276,17 @@ const struct hantro_variant imx8mq_vpu_variant = {
 	.reg_names = imx8mq_reg_names,
 	.num_regs = ARRAY_SIZE(imx8mq_reg_names)
 };
+
+const struct hantro_variant imx8mq_vpu_g2_variant = {
+	.dec_offset = 0x0,
+	.dec_fmts = imx8m_vpu_g2_dec_fmts,
+	.num_dec_fmts = ARRAY_SIZE(imx8m_vpu_g2_dec_fmts),
+	.codec = HANTRO_HEVC_DECODER,
+	.codec_ops = imx8mq_vpu_g2_codec_ops,
+	.init = imx8mq_vpu_hw_init,
+	.runtime_resume = imx8mq_runtime_resume,
+	.irqs = imx8mq_g2_irqs,
+	.num_irqs = ARRAY_SIZE(imx8mq_g2_irqs),
+	.clk_names = imx8mq_clk_names,
+	.num_clocks = ARRAY_SIZE(imx8mq_clk_names),
+};
-- 
2.25.1



From benjamin.gaignard at collabora.com  Tue Apr 20 13:10:45 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Tue, 20 Apr 2021 14:10:45 +0200
Subject: [PATCH v10 8/9] media: hantro: Introduce G2/HEVC decoder
In-Reply-To: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
Message-ID: <20210420121046.181889-9-benjamin.gaignard@collabora.com>

Implement all the logic to get G2 hardware decoding HEVC frames.
It supports up level 5.1 HEVC stream.
It doesn't support yet 10 bits formats or the scaling feature.

Add HANTRO HEVC dedicated control to skip some bits at the beginning
of the slice header. That is very specific to this hardware so can't
go into uapi structures. Computing the needed value is complex and requires
information from the stream that only the userland knows so let it
provide the correct value to the driver.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
Co-developed-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Signed-off-by: Adrian Ratiu <adrian.ratiu at collabora.com>
Co-developed-by: Ezequiel Garcia <ezequiel at collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel at collabora.com>
---
 drivers/staging/media/hantro/Makefile         |   2 +
 drivers/staging/media/hantro/hantro.h         |   2 +
 drivers/staging/media/hantro/hantro_drv.c     |  36 ++
 .../staging/media/hantro/hantro_g2_hevc_dec.c | 587 ++++++++++++++++++
 drivers/staging/media/hantro/hantro_g2_regs.h | 198 ++++++
 drivers/staging/media/hantro/hantro_hevc.c    | 327 ++++++++++
 drivers/staging/media/hantro/hantro_hw.h      |  49 ++
 7 files changed, 1201 insertions(+)
 create mode 100644 drivers/staging/media/hantro/hantro_g2_hevc_dec.c
 create mode 100644 drivers/staging/media/hantro/hantro_g2_regs.h
 create mode 100644 drivers/staging/media/hantro/hantro_hevc.c

diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile
index 743ce08eb184..0357f1772267 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -9,12 +9,14 @@ hantro-vpu-y += \
 		hantro_h1_jpeg_enc.o \
 		hantro_g1_h264_dec.o \
 		hantro_g1_mpeg2_dec.o \
+		hantro_g2_hevc_dec.o \
 		hantro_g1_vp8_dec.o \
 		rk3399_vpu_hw_jpeg_enc.o \
 		rk3399_vpu_hw_mpeg2_dec.o \
 		rk3399_vpu_hw_vp8_dec.o \
 		hantro_jpeg.o \
 		hantro_h264.o \
+		hantro_hevc.o \
 		hantro_mpeg2.o \
 		hantro_vp8.o
 
diff --git a/drivers/staging/media/hantro/hantro.h b/drivers/staging/media/hantro/hantro.h
index e50d39b51902..a70c386de6f1 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -221,6 +221,7 @@ struct hantro_dev {
  * @jpeg_enc:		JPEG-encoding context.
  * @mpeg2_dec:		MPEG-2-decoding context.
  * @vp8_dec:		VP8-decoding context.
+ * @hevc_dec:		HEVC-decoding context.
  */
 struct hantro_ctx {
 	struct hantro_dev *dev;
@@ -247,6 +248,7 @@ struct hantro_ctx {
 		struct hantro_jpeg_enc_hw_ctx jpeg_enc;
 		struct hantro_mpeg2_dec_hw_ctx mpeg2_dec;
 		struct hantro_vp8_dec_hw_ctx vp8_dec;
+		struct hantro_hevc_dec_hw_ctx hevc_dec;
 	};
 };
 
diff --git a/drivers/staging/media/hantro/hantro_drv.c b/drivers/staging/media/hantro/hantro_drv.c
index d9a3a5ef9330..905a69758b37 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -281,6 +281,26 @@ static int hantro_jpeg_s_ctrl(struct v4l2_ctrl *ctrl)
 	return 0;
 }
 
+static int hantro_hevc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+	struct hantro_ctx *ctx;
+
+	ctx = container_of(ctrl->handler,
+			   struct hantro_ctx, ctrl_handler);
+
+	vpu_debug(1, "s_ctrl: id = %d, val = %d\n", ctrl->id, ctrl->val);
+
+	switch (ctrl->id) {
+	case V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP:
+		ctx->hevc_dec.ctrls.hevc_hdr_skip_length = ctrl->val;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static const struct v4l2_ctrl_ops hantro_ctrl_ops = {
 	.try_ctrl = hantro_try_ctrl,
 };
@@ -289,6 +309,10 @@ static const struct v4l2_ctrl_ops hantro_jpeg_ctrl_ops = {
 	.s_ctrl = hantro_jpeg_s_ctrl,
 };
 
+static const struct v4l2_ctrl_ops hantro_hevc_ctrl_ops = {
+	.s_ctrl = hantro_hevc_s_ctrl,
+};
+
 static const struct hantro_ctrl controls[] = {
 	{
 		.codec = HANTRO_JPEG_ENCODER,
@@ -409,6 +433,18 @@ static const struct hantro_ctrl controls[] = {
 		.cfg = {
 			.id = V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS,
 		},
+	}, {
+		.codec = HANTRO_HEVC_DECODER,
+		.cfg = {
+			.id = V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP,
+			.name = "Hantro HEVC slice header skip bytes",
+			.type = V4L2_CTRL_TYPE_INTEGER,
+			.min = 0,
+			.def = 0,
+			.max = 0x100,
+			.step = 1,
+			.ops = &hantro_hevc_ctrl_ops,
+		},
 	},
 };
 
diff --git a/drivers/staging/media/hantro/hantro_g2_hevc_dec.c b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
new file mode 100644
index 000000000000..03a193a50c09
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_hevc_dec.c
@@ -0,0 +1,587 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include "hantro_hw.h"
+#include "hantro_g2_regs.h"
+
+#define HEVC_DEC_MODE	0xC
+
+#define BUS_WIDTH_32		0
+#define BUS_WIDTH_64		1
+#define BUS_WIDTH_128		2
+#define BUS_WIDTH_256		3
+
+static inline void hantro_write_addr(struct hantro_dev *vpu,
+				     unsigned long offset,
+				     dma_addr_t addr)
+{
+	vdpu_write(vpu, addr & 0xffffffff, offset);
+}
+
+static void prepare_tile_info_buffer(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	u16 *p = (u16 *)((u8 *)ctx->hevc_dec.tile_sizes.cpu);
+	unsigned int num_tile_rows = pps->num_tile_rows_minus1 + 1;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int pic_width_in_ctbs, pic_height_in_ctbs;
+	unsigned int max_log2_ctb_size, ctb_size;
+	bool tiles_enabled, uniform_spacing;
+	u32 no_chroma = 0;
+
+	tiles_enabled = !!(pps->flags & V4L2_HEVC_PPS_FLAG_TILES_ENABLED);
+	uniform_spacing = !!(pps->flags & V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING);
+
+	hantro_reg_write(vpu, hevc_tile_e, tiles_enabled);
+
+	max_log2_ctb_size = sps->log2_min_luma_coding_block_size_minus3 + 3 +
+			    sps->log2_diff_max_min_luma_coding_block_size;
+	pic_width_in_ctbs = (sps->pic_width_in_luma_samples +
+			    (1 << max_log2_ctb_size) - 1) >> max_log2_ctb_size;
+	pic_height_in_ctbs = (sps->pic_height_in_luma_samples + (1 << max_log2_ctb_size) - 1)
+			     >> max_log2_ctb_size;
+	ctb_size = 1 << max_log2_ctb_size;
+
+	vpu_debug(1, "Preparing tile sizes buffer for %dx%d CTBs (CTB size %d)\n",
+		  pic_width_in_ctbs, pic_height_in_ctbs, ctb_size);
+
+	if (tiles_enabled) {
+		unsigned int i, j, h;
+
+		vpu_debug(1, "Tiles enabled! %dx%d\n", num_tile_cols, num_tile_rows);
+
+		hantro_reg_write(vpu, hevc_num_tile_rows, num_tile_rows);
+		hantro_reg_write(vpu, hevc_num_tile_cols, num_tile_cols);
+
+		/* write width + height for each tile in pic */
+		if (!uniform_spacing) {
+			u32 tmp_w = 0, tmp_h = 0;
+
+			for (i = 0; i < num_tile_rows; i++) {
+				if (i == num_tile_rows - 1)
+					h = pic_height_in_ctbs - tmp_h;
+				else
+					h = pps->row_height_minus1[i] + 1;
+				tmp_h += h;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, tmp_w = 0; j < num_tile_cols - 1; j++) {
+					tmp_w += pps->column_width_minus1[j] + 1;
+					*p++ = pps->column_width_minus1[j + 1];
+					*p++ = h;
+					if (i == 0 && h == 1 && ctb_size == 16)
+						no_chroma = 1;
+				}
+				/* last column */
+				*p++ = pic_width_in_ctbs - tmp_w;
+				*p++ = h;
+			}
+		} else { /* uniform spacing */
+			u32 tmp, prev_h, prev_w;
+
+			for (i = 0, prev_h = 0; i < num_tile_rows; i++) {
+				tmp = (i + 1) * pic_height_in_ctbs / num_tile_rows;
+				h = tmp - prev_h;
+				prev_h = tmp;
+				if (i == 0 && h == 1 && ctb_size == 16)
+					no_chroma = 1;
+				for (j = 0, prev_w = 0; j < num_tile_cols; j++) {
+					tmp = (j + 1) * pic_width_in_ctbs / num_tile_cols;
+					*p++ = tmp - prev_w;
+					*p++ = h;
+					if (j == 0 &&
+					    (pps->column_width_minus1[0] + 1) == 1 &&
+					    ctb_size == 16)
+						no_chroma = 1;
+					prev_w = tmp;
+				}
+			}
+		}
+	} else {
+		hantro_reg_write(vpu, hevc_num_tile_rows, 1);
+		hantro_reg_write(vpu, hevc_num_tile_cols, 1);
+
+		/* There's one tile, with dimensions equal to pic size. */
+		p[0] = pic_width_in_ctbs;
+		p[1] = pic_height_in_ctbs;
+	}
+
+	if (no_chroma)
+		vpu_debug(1, "%s: no chroma!\n", __func__);
+}
+
+static void set_params(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	struct hantro_dev *vpu = ctx->dev;
+	u32 min_log2_cb_size, max_log2_ctb_size, min_cb_size, max_ctb_size;
+	u32 pic_width_in_min_cbs, pic_height_in_min_cbs;
+	u32 pic_width_aligned, pic_height_aligned;
+	u32 partial_ctb_x, partial_ctb_y;
+
+	hantro_reg_write(vpu, hevc_bit_depth_y_minus8, sps->bit_depth_luma_minus8);
+	hantro_reg_write(vpu, hevc_bit_depth_c_minus8, sps->bit_depth_chroma_minus8);
+
+	hantro_reg_write(vpu, hevc_output_8_bits, 0);
+
+	hantro_reg_write(vpu, hevc_hdr_skip_length, ctrls->hevc_hdr_skip_length);
+
+	min_log2_cb_size = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	max_log2_ctb_size = min_log2_cb_size + sps->log2_diff_max_min_luma_coding_block_size;
+
+	hantro_reg_write(vpu, hevc_min_cb_size, min_log2_cb_size);
+	hantro_reg_write(vpu, hevc_max_cb_size, max_log2_ctb_size);
+
+	min_cb_size = 1 << min_log2_cb_size;
+	max_ctb_size = 1 << max_log2_ctb_size;
+
+	pic_width_in_min_cbs = sps->pic_width_in_luma_samples / min_cb_size;
+	pic_height_in_min_cbs = sps->pic_height_in_luma_samples / min_cb_size;
+	pic_width_aligned = ALIGN(sps->pic_width_in_luma_samples, max_ctb_size);
+	pic_height_aligned = ALIGN(sps->pic_height_in_luma_samples, max_ctb_size);
+
+	partial_ctb_x = !!(sps->pic_width_in_luma_samples != pic_width_aligned);
+	partial_ctb_y = !!(sps->pic_height_in_luma_samples != pic_height_aligned);
+
+	hantro_reg_write(vpu, hevc_partial_ctb_x, partial_ctb_x);
+	hantro_reg_write(vpu, hevc_partial_ctb_y, partial_ctb_y);
+
+	hantro_reg_write(vpu, hevc_pic_width_in_cbs, pic_width_in_min_cbs);
+	hantro_reg_write(vpu, hevc_pic_height_in_cbs, pic_height_in_min_cbs);
+
+	hantro_reg_write(vpu, hevc_pic_width_4x4,
+			 (pic_width_in_min_cbs * min_cb_size) / 4);
+	hantro_reg_write(vpu, hevc_pic_height_4x4,
+			 (pic_height_in_min_cbs * min_cb_size) / 4);
+
+	hantro_reg_write(vpu, hevc_max_inter_hierdepth,
+			 sps->max_transform_hierarchy_depth_inter);
+	hantro_reg_write(vpu, hevc_max_intra_hierdepth,
+			 sps->max_transform_hierarchy_depth_intra);
+	hantro_reg_write(vpu, hevc_min_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2);
+	hantro_reg_write(vpu, hevc_max_trb_size,
+			 sps->log2_min_luma_transform_block_size_minus2 + 2 +
+			 sps->log2_diff_max_min_luma_transform_block_size);
+
+	hantro_reg_write(vpu, hevc_tempor_mvp_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SPS_TEMPORAL_MVP_ENABLED) &&
+			 !(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IDR_PIC));
+	hantro_reg_write(vpu, hevc_strong_smooth_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_STRONG_INTRA_SMOOTHING_ENABLED));
+	hantro_reg_write(vpu, hevc_asym_pred_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_AMP_ENABLED));
+	hantro_reg_write(vpu, hevc_sao_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_SAMPLE_ADAPTIVE_OFFSET));
+	hantro_reg_write(vpu, hevc_sign_data_hide,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED));
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_CU_QP_DELTA_ENABLED) {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 1);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, pps->diff_cu_qp_delta_depth);
+	} else {
+		hantro_reg_write(vpu, hevc_cu_qpd_e, 0);
+		hantro_reg_write(vpu, hevc_max_cu_qpd_depth, 0);
+	}
+
+	if (pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT) {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, pps->pps_cb_qp_offset);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, pps->pps_cr_qp_offset);
+	} else {
+		hantro_reg_write(vpu, hevc_cb_qp_offset, 0);
+		hantro_reg_write(vpu, hevc_cr_qp_offset, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_filt_offset_beta, pps->pps_beta_offset_div2);
+	hantro_reg_write(vpu, hevc_filt_offset_tc, pps->pps_tc_offset_div2);
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT));
+	hantro_reg_write(vpu, hevc_slice_hdr_ext_bits, pps->num_extra_slice_header_bits);
+	hantro_reg_write(vpu, hevc_slice_chqp_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_SLICE_CHROMA_QP_OFFSETS_PRESENT));
+	hantro_reg_write(vpu, hevc_weight_bipr_idc,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_BIPRED));
+	hantro_reg_write(vpu, hevc_transq_bypass,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSQUANT_BYPASS_ENABLED));
+	hantro_reg_write(vpu, hevc_list_mod_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LISTS_MODIFICATION_PRESENT));
+	hantro_reg_write(vpu, hevc_entropy_sync_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_ENTROPY_CODING_SYNC_ENABLED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_idr_pic_e,
+			 !!(decode_params->flags & V4L2_HEVC_DECODE_PARAM_FLAG_IRAP_PIC));
+	hantro_reg_write(vpu, hevc_parallel_merge,
+			 pps->log2_parallel_merge_level_minus2 + 2);
+	hantro_reg_write(vpu, hevc_pcm_filt_d,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_LOOP_FILTER_DISABLED));
+	hantro_reg_write(vpu, hevc_pcm_e,
+			 !!(sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED));
+	if (sps->flags & V4L2_HEVC_SPS_FLAG_PCM_ENABLED) {
+		hantro_reg_write(vpu, hevc_max_pcm_size,
+				 sps->log2_diff_max_min_pcm_luma_coding_block_size +
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_min_pcm_size,
+				 sps->log2_min_pcm_luma_coding_block_size_minus3 + 3);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y,
+				 sps->pcm_sample_bit_depth_luma_minus1 + 1);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c,
+				 sps->pcm_sample_bit_depth_chroma_minus1 + 1);
+	} else {
+		hantro_reg_write(vpu, hevc_max_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_min_pcm_size, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_y, 0);
+		hantro_reg_write(vpu, hevc_bit_depth_pcm_c, 0);
+	}
+
+	hantro_reg_write(vpu, hevc_start_code_e, 1);
+	hantro_reg_write(vpu, hevc_init_qp, pps->init_qp_minus26 + 26);
+	hantro_reg_write(vpu, hevc_weight_pred_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_WEIGHTED_PRED));
+	hantro_reg_write(vpu, hevc_cabac_init_present,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT));
+	hantro_reg_write(vpu, hevc_const_intra_e,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_CONSTRAINED_INTRA_PRED));
+	hantro_reg_write(vpu, hevc_transform_skip,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_TRANSFORM_SKIP_ENABLED));
+	hantro_reg_write(vpu, hevc_out_filtering_dis,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_DISABLE_DEBLOCKING_FILTER));
+	hantro_reg_write(vpu, hevc_filt_ctrl_pres,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT));
+	hantro_reg_write(vpu, hevc_dependent_slice,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT));
+	hantro_reg_write(vpu, hevc_filter_override,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_OVERRIDE_ENABLED));
+	hantro_reg_write(vpu, hevc_refidx0_active,
+			 pps->num_ref_idx_l0_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_refidx1_active,
+			 pps->num_ref_idx_l1_default_active_minus1 + 1);
+	hantro_reg_write(vpu, hevc_apf_threshold, 8);
+}
+
+static int find_ref_pic_index(const struct v4l2_hevc_dpb_entry *dpb, int pic_order_cnt)
+{
+	int i;
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		if (dpb[i].pic_order_cnt[0] == pic_order_cnt)
+			return i;
+	}
+
+	return 0x0;
+}
+
+static void set_ref_pic_list(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	u32 list0[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	u32 list1[V4L2_HEVC_DPB_ENTRIES_NUM_MAX] = {0};
+	const struct hantro_reg *ref_pic_regs0[] = {
+		hevc_rlist_f0,
+		hevc_rlist_f1,
+		hevc_rlist_f2,
+		hevc_rlist_f3,
+		hevc_rlist_f4,
+		hevc_rlist_f5,
+		hevc_rlist_f6,
+		hevc_rlist_f7,
+		hevc_rlist_f8,
+		hevc_rlist_f9,
+		hevc_rlist_f10,
+		hevc_rlist_f11,
+		hevc_rlist_f12,
+		hevc_rlist_f13,
+		hevc_rlist_f14,
+		hevc_rlist_f15,
+	};
+	const struct hantro_reg *ref_pic_regs1[] = {
+		hevc_rlist_b0,
+		hevc_rlist_b1,
+		hevc_rlist_b2,
+		hevc_rlist_b3,
+		hevc_rlist_b4,
+		hevc_rlist_b5,
+		hevc_rlist_b6,
+		hevc_rlist_b7,
+		hevc_rlist_b8,
+		hevc_rlist_b9,
+		hevc_rlist_b10,
+		hevc_rlist_b11,
+		hevc_rlist_b12,
+		hevc_rlist_b13,
+		hevc_rlist_b14,
+		hevc_rlist_b15,
+	};
+	unsigned int i, j;
+
+	/* List 0 contains: short term before, short term after and long term */
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list0); i++)
+		list0[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	/* Fill the list, copying over and over */
+	i = 0;
+	while (j < ARRAY_SIZE(list0))
+		list0[j++] = list0[i++];
+
+	j = 0;
+	for (i = 0; i < decode_params->num_poc_st_curr_after && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_after[i]);
+	for (i = 0; i < decode_params->num_poc_st_curr_before && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_st_curr_before[i]);
+	for (i = 0; i < decode_params->num_poc_lt_curr && j < ARRAY_SIZE(list1); i++)
+		list1[j++] = find_ref_pic_index(dpb, decode_params->poc_lt_curr[i]);
+
+	i = 0;
+	while (j < ARRAY_SIZE(list1))
+		list1[j++] = list1[i++];
+
+	for (i = 0; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_reg_write(vpu, ref_pic_regs0[i], list0[i]);
+		hantro_reg_write(vpu, ref_pic_regs1[i], list1[i]);
+	}
+}
+
+static int set_ref(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls->decode_params;
+	const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
+	dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
+	struct hantro_dev *vpu = ctx->dev;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	size_t mv_offset = hantro_hevc_motion_vectors_offset(sps);
+	u32 max_ref_frames;
+	u16 dpb_longterm_e;
+
+	const struct hantro_reg *cur_poc[] = {
+		hevc_cur_poc_00,
+		hevc_cur_poc_01,
+		hevc_cur_poc_02,
+		hevc_cur_poc_03,
+		hevc_cur_poc_04,
+		hevc_cur_poc_05,
+		hevc_cur_poc_06,
+		hevc_cur_poc_07,
+		hevc_cur_poc_08,
+		hevc_cur_poc_09,
+		hevc_cur_poc_10,
+		hevc_cur_poc_11,
+		hevc_cur_poc_12,
+		hevc_cur_poc_13,
+		hevc_cur_poc_14,
+		hevc_cur_poc_15,
+	};
+	unsigned int i;
+
+	max_ref_frames = decode_params->num_poc_lt_curr +
+		decode_params->num_poc_st_curr_before +
+		decode_params->num_poc_st_curr_after;
+	/*
+	 * Set max_ref_frames to non-zero to avoid HW hang when decoding
+	 * badly marked I-frames.
+	 */
+	max_ref_frames = max_ref_frames ? max_ref_frames : 1;
+	hantro_reg_write(vpu, hevc_num_ref_frames, max_ref_frames);
+	hantro_reg_write(vpu, hevc_filter_over_slices,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_PPS_LOOP_FILTER_ACROSS_SLICES_ENABLED));
+	hantro_reg_write(vpu, hevc_filter_over_tiles,
+			 !!(pps->flags & V4L2_HEVC_PPS_FLAG_LOOP_FILTER_ACROSS_TILES_ENABLED));
+
+	/*
+	 * Write POC count diff from current pic. For frame decoding only compute
+	 * pic_order_cnt[0] and ignore pic_order_cnt[1] used in field-coding.
+	 */
+	for (i = 0; i < decode_params->num_active_dpb_entries && i < ARRAY_SIZE(cur_poc); i++) {
+		char poc_diff = decode_params->pic_order_cnt_val - dpb[i].pic_order_cnt[0];
+
+		hantro_reg_write(vpu, cur_poc[i], poc_diff);
+	}
+
+	if (i < ARRAY_SIZE(cur_poc)) {
+		/*
+		 * After the references, fill one entry pointing to itself,
+		 * i.e. difference is zero.
+		 */
+		hantro_reg_write(vpu, cur_poc[i], 0);
+		i++;
+	}
+
+	/* Fill the rest with the current picture */
+	for (; i < ARRAY_SIZE(cur_poc); i++)
+		hantro_reg_write(vpu, cur_poc[i], decode_params->pic_order_cnt_val);
+
+	set_ref_pic_list(ctx);
+
+	/* We will only keep the references picture that are still used */
+	ctx->hevc_dec.ref_bufs_used = 0;
+
+	/* Set up addresses of DPB buffers */
+	dpb_longterm_e = 0;
+	for (i = 0; i < decode_params->num_active_dpb_entries &&
+	     i < (V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1); i++) {
+		luma_addr = hantro_hevc_get_ref_buf(ctx, dpb[i].pic_order_cnt[0]);
+		if (!luma_addr)
+			return -ENOMEM;
+
+		chroma_addr = luma_addr + cr_offset;
+		mv_addr = luma_addr + mv_offset;
+
+		if (dpb[i].rps == V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR)
+			dpb_longterm_e |= BIT(V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1 - i);
+
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), mv_addr);
+	}
+
+	luma_addr = hantro_hevc_get_ref_buf(ctx, decode_params->pic_order_cnt_val);
+	if (!luma_addr)
+		return -ENOMEM;
+
+	chroma_addr = luma_addr + cr_offset;
+	mv_addr = luma_addr + mv_offset;
+
+	hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), luma_addr);
+	hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), chroma_addr);
+	hantro_write_addr(vpu, HEVC_REG_DMV_REF(i++), mv_addr);
+
+	hantro_write_addr(vpu, HEVC_ADDR_DST, luma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_CHR, chroma_addr);
+	hantro_write_addr(vpu, HEVC_ADDR_DST_MV, mv_addr);
+
+	hantro_hevc_ref_remove_unused(ctx);
+
+	for (; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
+		hantro_write_addr(vpu, HEVC_REG_ADDR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_CHR_REF(i), 0);
+		hantro_write_addr(vpu, HEVC_REG_DMV_REF(i), 0);
+	}
+
+	hantro_reg_write(vpu, hevc_refer_lterm_e, dpb_longterm_e);
+
+	return 0;
+}
+
+static void set_buffers(struct hantro_ctx *ctx)
+{
+	struct vb2_v4l2_buffer *src_buf, *dst_buf;
+	struct hantro_dev *vpu = ctx->dev;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+	dma_addr_t src_dma, dst_dma;
+	u32 src_len, src_buf_len;
+
+	src_buf = hantro_get_src_buf(ctx);
+	dst_buf = hantro_get_dst_buf(ctx);
+
+	/* Source (stream) buffer. */
+	src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
+	src_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+	src_buf_len = vb2_plane_size(&src_buf->vb2_buf, 0);
+
+	hantro_write_addr(vpu, HEVC_ADDR_STR, src_dma);
+	hantro_reg_write(vpu, hevc_stream_len, src_len);
+	hantro_reg_write(vpu, hevc_strm_buffer_len, src_buf_len);
+	hantro_reg_write(vpu, hevc_strm_start_offset, 0);
+	hantro_reg_write(vpu, hevc_write_mvs_e, 1);
+
+	/* Destination (decoded frame) buffer. */
+	dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
+
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN, dst_dma);
+	hantro_write_addr(vpu, HEVC_RASTER_SCAN_CHR, dst_dma + cr_offset);
+	hantro_write_addr(vpu, HEVC_ADDR_TILE_SIZE, ctx->hevc_dec.tile_sizes.dma);
+	hantro_write_addr(vpu, HEVC_TILE_FILTER, ctx->hevc_dec.tile_filter.dma);
+	hantro_write_addr(vpu, HEVC_TILE_SAO, ctx->hevc_dec.tile_sao.dma);
+	hantro_write_addr(vpu, HEVC_TILE_BSD, ctx->hevc_dec.tile_bsd.dma);
+}
+
+static void hantro_g2_check_idle(struct hantro_dev *vpu)
+{
+	int i;
+
+	for (i = 0; i < 3; i++) {
+		u32 status;
+
+		/* Make sure the VPU is idle */
+		status = vdpu_read(vpu, HEVC_REG_INTERRUPT);
+		if (status & HEVC_REG_INTERRUPT_DEC_E) {
+			dev_warn(vpu->dev, "device still running, aborting");
+			status |= HEVC_REG_INTERRUPT_DEC_ABORT_E | HEVC_REG_INTERRUPT_DEC_IRQ_DIS;
+			vdpu_write(vpu, status, HEVC_REG_INTERRUPT);
+		}
+	}
+}
+
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	int ret;
+
+	hantro_g2_check_idle(vpu);
+
+	/* Prepare HEVC decoder context. */
+	ret = hantro_hevc_dec_prepare_run(ctx);
+	if (ret)
+		return ret;
+
+	/* Configure hardware registers. */
+	set_params(ctx);
+
+	/* set reference pictures */
+	ret = set_ref(ctx);
+	if (ret)
+		return ret;
+
+	set_buffers(ctx);
+	prepare_tile_info_buffer(ctx);
+
+	hantro_end_prepare_run(ctx);
+
+	hantro_reg_write(vpu, hevc_mode, HEVC_DEC_MODE);
+	hantro_reg_write(vpu, hevc_clk_gate_e, 1);
+
+	/* Don't disable output */
+	hantro_reg_write(vpu, hevc_out_dis, 0);
+
+	/* Don't compress buffers */
+	hantro_reg_write(vpu, hevc_ref_compress_bypass, 1);
+
+	/* use NV12 as output format */
+	hantro_reg_write(vpu, hevc_out_rs_e, 1);
+
+	/* Bus width and max burst */
+	hantro_reg_write(vpu, hevc_buswidth, BUS_WIDTH_128);
+	hantro_reg_write(vpu, hevc_max_burst, 16);
+
+	/* Swap */
+	hantro_reg_write(vpu, hevc_strm_swap, 0xf);
+	hantro_reg_write(vpu, hevc_dirmv_swap, 0xf);
+	hantro_reg_write(vpu, hevc_compress_swap, 0xf);
+
+	/* Start decoding! */
+	vdpu_write(vpu, HEVC_REG_INTERRUPT_DEC_E, HEVC_REG_INTERRUPT);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_g2_regs.h b/drivers/staging/media/hantro/hantro_g2_regs.h
new file mode 100644
index 000000000000..a361c9ba911d
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g2_regs.h
@@ -0,0 +1,198 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2021, Collabora
+ *
+ * Author: Benjamin Gaignard <benjamin.gaignard at collabora.com>
+ */
+
+#ifndef HANTRO_G2_REGS_H_
+#define HANTRO_G2_REGS_H_
+
+#include "hantro.h"
+
+#define G2_SWREG(nr)	((nr) * 4)
+
+#define HEVC_DEC_REG(name, base, shift, mask) \
+	static const struct hantro_reg _hevc_##name[] = { \
+		{ G2_SWREG(base), (shift), (mask) } \
+	}; \
+	static const struct hantro_reg __maybe_unused *hevc_##name = &_hevc_##name[0];
+
+#define HEVC_REG_VERSION		G2_SWREG(0)
+
+#define HEVC_REG_INTERRUPT		G2_SWREG(1)
+#define HEVC_REG_INTERRUPT_DEC_RDY_INT	BIT(12)
+#define HEVC_REG_INTERRUPT_DEC_ABORT_E	BIT(5)
+#define HEVC_REG_INTERRUPT_DEC_IRQ_DIS	BIT(4)
+#define HEVC_REG_INTERRUPT_DEC_E	BIT(0)
+
+HEVC_DEC_REG(strm_swap,		2, 28,	0xf)
+HEVC_DEC_REG(dirmv_swap,	2, 20,	0xf)
+
+HEVC_DEC_REG(mode,		  3, 27, 0x1f)
+HEVC_DEC_REG(compress_swap,	  3, 20, 0xf)
+HEVC_DEC_REG(ref_compress_bypass, 3, 17, 0x1)
+HEVC_DEC_REG(out_rs_e,		  3, 16, 0x1)
+HEVC_DEC_REG(out_dis,		  3, 15, 0x1)
+HEVC_DEC_REG(out_filtering_dis,   3, 14, 0x1)
+HEVC_DEC_REG(write_mvs_e,	  3, 12, 0x1)
+
+HEVC_DEC_REG(pic_width_in_cbs,	4, 19,	0x1ff)
+HEVC_DEC_REG(pic_height_in_cbs,	4, 6,	0x1ff)
+HEVC_DEC_REG(num_ref_frames,	4, 0,	0x1f)
+
+HEVC_DEC_REG(scaling_list_e,	5, 24,	0x1)
+HEVC_DEC_REG(cb_qp_offset,	5, 19,	0x1f)
+HEVC_DEC_REG(cr_qp_offset,	5, 14,	0x1f)
+HEVC_DEC_REG(sign_data_hide,	5, 12,	0x1)
+HEVC_DEC_REG(tempor_mvp_e,	5, 11,	0x1)
+HEVC_DEC_REG(max_cu_qpd_depth,	5, 5,	0x3f)
+HEVC_DEC_REG(cu_qpd_e,		5, 4,	0x1)
+
+HEVC_DEC_REG(stream_len,	6, 0,	0xffffffff)
+
+HEVC_DEC_REG(cabac_init_present, 7, 31, 0x1)
+HEVC_DEC_REG(weight_pred_e,	 7, 28, 0x1)
+HEVC_DEC_REG(weight_bipr_idc,	 7, 26, 0x3)
+HEVC_DEC_REG(filter_over_slices, 7, 25, 0x1)
+HEVC_DEC_REG(filter_over_tiles,  7, 24, 0x1)
+HEVC_DEC_REG(asym_pred_e,	 7, 23, 0x1)
+HEVC_DEC_REG(sao_e,		 7, 22, 0x1)
+HEVC_DEC_REG(pcm_filt_d,	 7, 21, 0x1)
+HEVC_DEC_REG(slice_chqp_present, 7, 20, 0x1)
+HEVC_DEC_REG(dependent_slice,	 7, 19, 0x1)
+HEVC_DEC_REG(filter_override,	 7, 18, 0x1)
+HEVC_DEC_REG(strong_smooth_e,	 7, 17, 0x1)
+HEVC_DEC_REG(filt_offset_beta,	 7, 12, 0x1f)
+HEVC_DEC_REG(filt_offset_tc,	 7, 7,  0x1f)
+HEVC_DEC_REG(slice_hdr_ext_e,	 7, 6,	0x1)
+HEVC_DEC_REG(slice_hdr_ext_bits, 7, 3,	0x7)
+
+HEVC_DEC_REG(const_intra_e,	 8, 31, 0x1)
+HEVC_DEC_REG(filt_ctrl_pres,	 8, 30, 0x1)
+HEVC_DEC_REG(idr_pic_e,		 8, 16, 0x1)
+HEVC_DEC_REG(bit_depth_pcm_y,	 8, 12, 0xf)
+HEVC_DEC_REG(bit_depth_pcm_c,	 8, 8,  0xf)
+HEVC_DEC_REG(bit_depth_y_minus8, 8, 6,  0x3)
+HEVC_DEC_REG(bit_depth_c_minus8, 8, 4,  0x3)
+HEVC_DEC_REG(output_8_bits,	 8, 3,  0x1)
+
+HEVC_DEC_REG(refidx1_active,	9, 19,	0x1f)
+HEVC_DEC_REG(refidx0_active,	9, 14,	0x1f)
+HEVC_DEC_REG(hdr_skip_length,	9, 0,	0x3fff)
+
+HEVC_DEC_REG(start_code_e,	10, 31, 0x1)
+HEVC_DEC_REG(init_qp,		10, 24, 0x3f)
+HEVC_DEC_REG(num_tile_cols,	10, 19, 0x1f)
+HEVC_DEC_REG(num_tile_rows,	10, 14, 0x1f)
+HEVC_DEC_REG(tile_e,		10, 1,	0x1)
+HEVC_DEC_REG(entropy_sync_e,	10, 0,	0x1)
+
+HEVC_DEC_REG(refer_lterm_e,	12, 16, 0xffff)
+HEVC_DEC_REG(min_cb_size,	12, 13, 0x7)
+HEVC_DEC_REG(max_cb_size,	12, 10, 0x7)
+HEVC_DEC_REG(min_pcm_size,	12, 7,  0x7)
+HEVC_DEC_REG(max_pcm_size,	12, 4,  0x7)
+HEVC_DEC_REG(pcm_e,		12, 3,  0x1)
+HEVC_DEC_REG(transform_skip,	12, 2,	0x1)
+HEVC_DEC_REG(transq_bypass,	12, 1,	0x1)
+HEVC_DEC_REG(list_mod_e,	12, 0,	0x1)
+
+HEVC_DEC_REG(min_trb_size,	  13, 13, 0x7)
+HEVC_DEC_REG(max_trb_size,	  13, 10, 0x7)
+HEVC_DEC_REG(max_intra_hierdepth, 13, 7,  0x7)
+HEVC_DEC_REG(max_inter_hierdepth, 13, 4,  0x7)
+HEVC_DEC_REG(parallel_merge,	  13, 0,  0xf)
+
+HEVC_DEC_REG(rlist_f0,		14, 0,	0x1f)
+HEVC_DEC_REG(rlist_f1,		14, 10,	0x1f)
+HEVC_DEC_REG(rlist_f2,		14, 20,	0x1f)
+HEVC_DEC_REG(rlist_b0,		14, 5,	0x1f)
+HEVC_DEC_REG(rlist_b1,		14, 15, 0x1f)
+HEVC_DEC_REG(rlist_b2,		14, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f3,		15, 0,	0x1f)
+HEVC_DEC_REG(rlist_f4,		15, 10, 0x1f)
+HEVC_DEC_REG(rlist_f5,		15, 20, 0x1f)
+HEVC_DEC_REG(rlist_b3,		15, 5,	0x1f)
+HEVC_DEC_REG(rlist_b4,		15, 15, 0x1f)
+HEVC_DEC_REG(rlist_b5,		15, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f6,		16, 0,	0x1f)
+HEVC_DEC_REG(rlist_f7,		16, 10, 0x1f)
+HEVC_DEC_REG(rlist_f8,		16, 20, 0x1f)
+HEVC_DEC_REG(rlist_b6,		16, 5,	0x1f)
+HEVC_DEC_REG(rlist_b7,		16, 15, 0x1f)
+HEVC_DEC_REG(rlist_b8,		16, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f9,		17, 0,	0x1f)
+HEVC_DEC_REG(rlist_f10,		17, 10, 0x1f)
+HEVC_DEC_REG(rlist_f11,		17, 20, 0x1f)
+HEVC_DEC_REG(rlist_b9,		17, 5,	0x1f)
+HEVC_DEC_REG(rlist_b10,		17, 15, 0x1f)
+HEVC_DEC_REG(rlist_b11,		17, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f12,		18, 0,	0x1f)
+HEVC_DEC_REG(rlist_f13,		18, 10, 0x1f)
+HEVC_DEC_REG(rlist_f14,		18, 20, 0x1f)
+HEVC_DEC_REG(rlist_b12,		18, 5,	0x1f)
+HEVC_DEC_REG(rlist_b13,		18, 15, 0x1f)
+HEVC_DEC_REG(rlist_b14,		18, 25, 0x1f)
+
+HEVC_DEC_REG(rlist_f15,		19, 0,	0x1f)
+HEVC_DEC_REG(rlist_b15,		19, 5,	0x1f)
+
+HEVC_DEC_REG(partial_ctb_x,	20, 31, 0x1)
+HEVC_DEC_REG(partial_ctb_y,	20, 30, 0x1)
+HEVC_DEC_REG(pic_width_4x4,	20, 16, 0xfff)
+HEVC_DEC_REG(pic_height_4x4,	20, 0,  0xfff)
+
+HEVC_DEC_REG(cur_poc_00,	46, 24,	0xff)
+HEVC_DEC_REG(cur_poc_01,	46, 16,	0xff)
+HEVC_DEC_REG(cur_poc_02,	46, 8,	0xff)
+HEVC_DEC_REG(cur_poc_03,	46, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_04,	47, 24,	0xff)
+HEVC_DEC_REG(cur_poc_05,	47, 16,	0xff)
+HEVC_DEC_REG(cur_poc_06,	47, 8,	0xff)
+HEVC_DEC_REG(cur_poc_07,	47, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_08,	48, 24,	0xff)
+HEVC_DEC_REG(cur_poc_09,	48, 16,	0xff)
+HEVC_DEC_REG(cur_poc_10,	48, 8,	0xff)
+HEVC_DEC_REG(cur_poc_11,	48, 0,	0xff)
+
+HEVC_DEC_REG(cur_poc_12,	49, 24, 0xff)
+HEVC_DEC_REG(cur_poc_13,	49, 16, 0xff)
+HEVC_DEC_REG(cur_poc_14,	49, 8,	0xff)
+HEVC_DEC_REG(cur_poc_15,	49, 0,	0xff)
+
+HEVC_DEC_REG(apf_threshold,	55, 0,	0xffff)
+
+HEVC_DEC_REG(clk_gate_e,	58, 16,	0x1)
+HEVC_DEC_REG(buswidth,		58, 8,	0x7)
+HEVC_DEC_REG(max_burst,		58, 0,	0xff)
+
+#define HEVC_REG_CONFIG				G2_SWREG(58)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_E		BIT(16)
+#define HEVC_REG_CONFIG_DEC_CLK_GATE_IDLE_E	BIT(17)
+
+#define HEVC_ADDR_DST		(G2_SWREG(65))
+#define HEVC_REG_ADDR_REF(i)	(G2_SWREG(67)  + ((i) * 0x8))
+#define HEVC_ADDR_DST_CHR	(G2_SWREG(99))
+#define HEVC_REG_CHR_REF(i)	(G2_SWREG(101) + ((i) * 0x8))
+#define HEVC_ADDR_DST_MV	(G2_SWREG(133))
+#define HEVC_REG_DMV_REF(i)	(G2_SWREG(135) + ((i) * 0x8))
+#define HEVC_ADDR_TILE_SIZE	(G2_SWREG(167))
+#define HEVC_ADDR_STR		(G2_SWREG(169))
+#define HEVC_SCALING_LIST	(G2_SWREG(171))
+#define HEVC_RASTER_SCAN	(G2_SWREG(175))
+#define HEVC_RASTER_SCAN_CHR	(G2_SWREG(177))
+#define HEVC_TILE_FILTER	(G2_SWREG(179))
+#define HEVC_TILE_SAO		(G2_SWREG(181))
+#define HEVC_TILE_BSD		(G2_SWREG(183))
+
+HEVC_DEC_REG(strm_buffer_len,	258, 0,	0xffffffff)
+HEVC_DEC_REG(strm_start_offset,	259, 0,	0xffffffff)
+
+#endif
diff --git a/drivers/staging/media/hantro/hantro_hevc.c b/drivers/staging/media/hantro/hantro_hevc.c
new file mode 100644
index 000000000000..015197797591
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_hevc.c
@@ -0,0 +1,327 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU HEVC codec driver
+ *
+ * Copyright (C) 2020 Safran Passenger Innovations LLC
+ */
+
+#include <linux/types.h>
+#include <media/v4l2-mem2mem.h>
+
+#include "hantro.h"
+#include "hantro_hw.h"
+
+#define VERT_FILTER_RAM_SIZE 8 /* bytes per pixel row */
+/*
+ * BSD control data of current picture at tile border
+ * 128 bits per 4x4 tile = 128/(8*4) bytes per row
+ */
+#define BSD_CTRL_RAM_SIZE 4 /* bytes per pixel row */
+/* tile border coefficients of filter */
+#define VERT_SAO_RAM_SIZE 48 /* bytes per pixel */
+
+#define MAX_TILE_COLS 20
+#define MAX_TILE_ROWS 22
+
+#define UNUSED_REF	-1
+
+#define G2_ALIGN		16
+
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	int bytes_per_pixel = sps->bit_depth_luma_minus8 == 0 ? 1 : 2;
+
+	return sps->pic_width_in_luma_samples *
+	       sps->pic_height_in_luma_samples * bytes_per_pixel;
+}
+
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	size_t cr_offset = hantro_hevc_chroma_offset(sps);
+
+	return ALIGN((cr_offset * 3) / 2, G2_ALIGN);
+}
+
+static size_t hantro_hevc_mv_size(const struct v4l2_ctrl_hevc_sps *sps)
+{
+	u32 min_cb_log2_size_y = sps->log2_min_luma_coding_block_size_minus3 + 3;
+	u32 ctb_log2_size_y = min_cb_log2_size_y + sps->log2_diff_max_min_luma_coding_block_size;
+	u32 pic_width_in_ctbs_y = (sps->pic_width_in_luma_samples + (1 << ctb_log2_size_y) - 1)
+				  >> ctb_log2_size_y;
+	u32 pic_height_in_ctbs_y = (sps->pic_height_in_luma_samples + (1 << ctb_log2_size_y) - 1)
+				   >> ctb_log2_size_y;
+	size_t mv_size;
+
+	mv_size = pic_width_in_ctbs_y * pic_height_in_ctbs_y *
+		  (1 << (2 * (ctb_log2_size_y - 4))) * 16;
+
+	vpu_debug(4, "%dx%d (CTBs) %zu MV bytes\n",
+		  pic_width_in_ctbs_y, pic_height_in_ctbs_y, mv_size);
+
+	return mv_size;
+}
+
+static size_t hantro_hevc_ref_size(struct hantro_ctx *ctx)
+{
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+
+	return hantro_hevc_motion_vectors_offset(sps) + hantro_hevc_mv_size(sps);
+}
+
+static void hantro_hevc_ref_free(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	struct hantro_dev *vpu = ctx->dev;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs[i].cpu)
+			dma_free_coherent(vpu->dev, hevc_dec->ref_bufs[i].size,
+					  hevc_dec->ref_bufs[i].cpu,
+					  hevc_dec->ref_bufs[i].dma);
+	}
+}
+
+static void hantro_hevc_ref_init(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	for (i = 0;  i < NUM_REF_PICTURES; i++)
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+}
+
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
+				   int poc)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Find the reference buffer in already know ones */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == poc) {
+			hevc_dec->ref_bufs_used |= 1 << i;
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	/* Allocate a new reference buffer */
+	for (i = 0; i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF) {
+			if (!hevc_dec->ref_bufs[i].cpu) {
+				struct hantro_dev *vpu = ctx->dev;
+
+				/*
+				 * Allocate the space needed for the raw data +
+				 * motion vector data. Optimizations could be to
+				 * allocate raw data in non coherent memory and only
+				 * clear the motion vector data.
+				 */
+				hevc_dec->ref_bufs[i].cpu =
+					dma_alloc_coherent(vpu->dev,
+							   hantro_hevc_ref_size(ctx),
+							   &hevc_dec->ref_bufs[i].dma,
+							   GFP_KERNEL);
+				if (!hevc_dec->ref_bufs[i].cpu)
+					return 0;
+
+				hevc_dec->ref_bufs[i].size = hantro_hevc_ref_size(ctx);
+			}
+			hevc_dec->ref_bufs_used |= 1 << i;
+			memset(hevc_dec->ref_bufs[i].cpu, 0, hantro_hevc_ref_size(ctx));
+			hevc_dec->ref_bufs_poc[i] = poc;
+
+			return hevc_dec->ref_bufs[i].dma;
+		}
+	}
+
+	return 0;
+}
+
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	int i;
+
+	/* Just tag buffer as unused, do not free them */
+	for (i = 0;  i < NUM_REF_PICTURES; i++) {
+		if (hevc_dec->ref_bufs_poc[i] == UNUSED_REF)
+			continue;
+
+		if (hevc_dec->ref_bufs_used & (1 << i))
+			continue;
+
+		hevc_dec->ref_bufs_poc[i] = UNUSED_REF;
+	}
+}
+
+static int tile_buffer_reallocate(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
+	const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
+	const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
+	unsigned int num_tile_cols = pps->num_tile_columns_minus1 + 1;
+	unsigned int height64 = (sps->pic_height_in_luma_samples + 63) & ~63;
+	unsigned int size;
+
+	if (num_tile_cols <= 1 ||
+	    num_tile_cols <= hevc_dec->num_tile_cols_allocated)
+		return 0;
+
+	/* Need to reallocate due to tiles passed via PPS */
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+
+	size = VERT_FILTER_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_filter.cpu = dma_alloc_coherent(vpu->dev, size,
+						       &hevc_dec->tile_filter.dma,
+						       GFP_KERNEL);
+	if (!hevc_dec->tile_filter.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_filter.size = size;
+
+	size = VERT_SAO_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_sao.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_sao.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_sao.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_sao.size = size;
+
+	size = BSD_CTRL_RAM_SIZE * height64 * (num_tile_cols - 1);
+	hevc_dec->tile_bsd.cpu = dma_alloc_coherent(vpu->dev, size,
+						    &hevc_dec->tile_bsd.dma,
+						    GFP_KERNEL);
+	if (!hevc_dec->tile_bsd.cpu)
+		goto err_free_tile_buffers;
+	hevc_dec->tile_bsd.size = size;
+
+	hevc_dec->num_tile_cols_allocated = num_tile_cols;
+
+	return 0;
+
+err_free_tile_buffers:
+	if (hevc_dec->tile_filter.size)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	return -ENOMEM;
+}
+
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx)
+{
+	struct hantro_hevc_dec_hw_ctx *hevc_ctx = &ctx->hevc_dec;
+	struct hantro_hevc_dec_ctrls *ctrls = &hevc_ctx->ctrls;
+	int ret;
+
+	hantro_start_prepare_run(ctx);
+
+	ctrls->decode_params =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS);
+	if (WARN_ON(!ctrls->decode_params))
+		return -EINVAL;
+
+	ctrls->sps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_SPS);
+	if (WARN_ON(!ctrls->sps))
+		return -EINVAL;
+
+	ctrls->pps =
+		hantro_get_ctrl(ctx, V4L2_CID_MPEG_VIDEO_HEVC_PPS);
+	if (WARN_ON(!ctrls->pps))
+		return -EINVAL;
+
+	ret = tile_buffer_reallocate(ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+
+	if (hevc_dec->tile_sizes.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sizes.size,
+				  hevc_dec->tile_sizes.cpu,
+				  hevc_dec->tile_sizes.dma);
+	hevc_dec->tile_sizes.cpu = NULL;
+
+	if (hevc_dec->tile_filter.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_filter.size,
+				  hevc_dec->tile_filter.cpu,
+				  hevc_dec->tile_filter.dma);
+	hevc_dec->tile_filter.cpu = NULL;
+
+	if (hevc_dec->tile_sao.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_sao.size,
+				  hevc_dec->tile_sao.cpu,
+				  hevc_dec->tile_sao.dma);
+	hevc_dec->tile_sao.cpu = NULL;
+
+	if (hevc_dec->tile_bsd.cpu)
+		dma_free_coherent(vpu->dev, hevc_dec->tile_bsd.size,
+				  hevc_dec->tile_bsd.cpu,
+				  hevc_dec->tile_bsd.dma);
+	hevc_dec->tile_bsd.cpu = NULL;
+
+	hantro_hevc_ref_free(ctx);
+}
+
+int hantro_hevc_dec_init(struct hantro_ctx *ctx)
+{
+	struct hantro_dev *vpu = ctx->dev;
+	struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
+	unsigned int size;
+
+	memset(hevc_dec, 0, sizeof(*hevc_dec));
+
+	/*
+	 * Maximum number of tiles times width and height (2 bytes each),
+	 * rounding up to next 16 bytes boundary + one extra 16 byte
+	 * chunk (HW guys wanted to have this).
+	 */
+	size = round_up(MAX_TILE_COLS * MAX_TILE_ROWS * 4 * sizeof(u16) + 16, 16);
+	hevc_dec->tile_sizes.cpu = dma_alloc_coherent(vpu->dev, size,
+						      &hevc_dec->tile_sizes.dma,
+						      GFP_KERNEL);
+	if (!hevc_dec->tile_sizes.cpu)
+		return -ENOMEM;
+
+	hevc_dec->tile_sizes.size = size;
+
+	hantro_hevc_ref_init(ctx);
+
+	return 0;
+}
diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h
index 6a34ddfa34b7..41f3d5b92357 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -20,6 +20,8 @@
 #define MB_WIDTH(w)		DIV_ROUND_UP(w, MB_DIM)
 #define MB_HEIGHT(h)		DIV_ROUND_UP(h, MB_DIM)
 
+#define NUM_REF_PICTURES	(V4L2_HEVC_DPB_ENTRIES_NUM_MAX + 1)
+
 struct hantro_dev;
 struct hantro_ctx;
 struct hantro_buf;
@@ -95,6 +97,44 @@ struct hantro_h264_dec_hw_ctx {
 	struct hantro_h264_dec_ctrls ctrls;
 };
 
+/**
+ * struct hantro_hevc_dec_ctrls
+ * @decode_params: Decode params
+ * @sps:	SPS info
+ * @pps:	PPS info
+ * @hevc_hdr_skip_length: the number of data (in bits) to skip in the
+ *			  slice segment header syntax after 'slice type'
+ *			  token
+ */
+struct hantro_hevc_dec_ctrls {
+	const struct v4l2_ctrl_hevc_decode_params *decode_params;
+	const struct v4l2_ctrl_hevc_sps *sps;
+	const struct v4l2_ctrl_hevc_pps *pps;
+	u32 hevc_hdr_skip_length;
+};
+
+/**
+ * struct hantro_hevc_dec_hw_ctx
+ * @tile_sizes:		Tile sizes buffer
+ * @tile_filter:	Tile vertical filter buffer
+ * @tile_sao:		Tile SAO buffer
+ * @tile_bsd:		Tile BSD control buffer
+ * @dpb:	DPB
+ * @reflists:	P/B0/B1 reflists
+ * @ctrls:	V4L2 controls attached to a run
+ */
+struct hantro_hevc_dec_hw_ctx {
+	struct hantro_aux_buf tile_sizes;
+	struct hantro_aux_buf tile_filter;
+	struct hantro_aux_buf tile_sao;
+	struct hantro_aux_buf tile_bsd;
+	struct hantro_aux_buf ref_bufs[NUM_REF_PICTURES];
+	int ref_bufs_poc[NUM_REF_PICTURES];
+	u32 ref_bufs_used;
+	struct hantro_hevc_dec_ctrls ctrls;
+	unsigned int num_tile_cols_allocated;
+};
+
 /**
  * struct hantro_mpeg2_dec_hw_ctx
  *
@@ -190,6 +230,15 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
 int hantro_h264_dec_init(struct hantro_ctx *ctx);
 void hantro_h264_dec_exit(struct hantro_ctx *ctx);
 
+int hantro_hevc_dec_init(struct hantro_ctx *ctx);
+void hantro_hevc_dec_exit(struct hantro_ctx *ctx);
+int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx);
+int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx);
+dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, int poc);
+void hantro_hevc_ref_remove_unused(struct hantro_ctx *ctx);
+size_t hantro_hevc_chroma_offset(const struct v4l2_ctrl_hevc_sps *sps);
+size_t hantro_hevc_motion_vectors_offset(const struct v4l2_ctrl_hevc_sps *sps);
+
 static inline size_t
 hantro_h264_mv_size(unsigned int width, unsigned int height)
 {
-- 
2.25.1



From lkp at intel.com  Tue Apr 20 13:32:40 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 20:32:40 +0800
Subject: [PATCH v3 02/10] iommu/dma: Introduce generic helper to retrieve
 RMR info
In-Reply-To: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104202050.6sLwjRkh-lkp@intel.com>

Hi Shameer,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on pm/linux-next]
[also build test ERROR on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm-randconfig-r023-20210420 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project ca8eef7e3da8f750d7c7aa004fe426d1d34787ea)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/c68d4ba37ecc2173a2dc418799e23a184685d681
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout c68d4ba37ecc2173a2dc418799e23a184685d681
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from drivers/iommu/arm/arm-smmu/arm-smmu.c:24:
>> include/linux/dma-iommu.h:93:1: error: expected identifier or '('
   {
   ^
   1 error generated.


vim +93 include/linux/dma-iommu.h

    91	
    92	int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
  > 93	{
    94		return 0;
    95	}
    96	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25176 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/fdb82063/attachment-0001.gz>

From jonathanh at nvidia.com  Tue Apr 20 13:45:55 2021
From: jonathanh at nvidia.com (Jon Hunter)
Date: Tue, 20 Apr 2021 13:45:55 +0100
Subject: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains
In-Reply-To: <87fszlqria.wl-maz@kernel.org>
References: <20210330151145.997953-1-maz@kernel.org>
 <20210330151145.997953-2-maz@kernel.org>
 <316e8be4-fa70-75e8-8483-ae38036306e0@nvidia.com>
 <638a9996-c762-fa11-b740-6a41d4a83bcc@nvidia.com>
 <87fszlqria.wl-maz@kernel.org>
Message-ID: <67ecea13-3036-0d2d-fa89-46f896a06693@nvidia.com>

Hi Marc,

On 20/04/2021 09:39, Marc Zyngier wrote:

...

> The following should hopefully cure it (compile tested only). Please
> let me know.
> 
> 	M.
> 
> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
> index eaba7b2fab4a..507b23d43ad1 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -1802,13 +1802,19 @@ static void tegra_pcie_enable_msi(struct tegra_pcie *pcie)
>  {
>  	const struct tegra_pcie_soc *soc = pcie->soc;
>  	struct tegra_msi *msi = &pcie->msi;
> -	u32 reg;
> +	u32 reg, msi_state[INT_PCI_MSI_NR / 32];
> +	int i;
>  
>  	afi_writel(pcie, msi->phys >> soc->msi_base_shift, AFI_MSI_FPCI_BAR_ST);
>  	afi_writel(pcie, msi->phys, AFI_MSI_AXI_BAR_ST);
>  	/* this register is in 4K increments */
>  	afi_writel(pcie, 1, AFI_MSI_BAR_SZ);
>  
> +	/* Restore the MSI allocation state */
> +	bitmap_to_arr32(msi_state, msi->used, INT_PCI_MSI_NR);
> +	for (i = 0; i < ARRAY_SIZE(msi_state); i++)
> +		afi_writel(pcie, msi_state[i], AFI_MSI_EN_VEC(i));
> +
>  	/* and unmask the MSI interrupt */
>  	reg = afi_readl(pcie, AFI_INTR_MASK);
>  	reg |= AFI_INTR_MASK_MSI_MASK;
> 


Thanks, that does fix it indeed!

Tested-by: Jon Hunter <jonathanh at nvidia.com>

Cheers
Jon

-- 
nvpublic


From Steen.Hegelund at microchip.com  Tue Apr 20 13:54:14 2021
From: Steen.Hegelund at microchip.com (Steen.Hegelund at microchip.com)
Date: Tue, 20 Apr 2021 12:54:14 +0000
Subject: [PATCH net-next 03/10] net: sparx5: add hostmode with phylink
 support
In-Reply-To: <20210416142244.244656a8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
 <20210416131657.3151464-4-steen.hegelund@microchip.com>
 <20210416142244.244656a8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <e443bf58c73cb382ea5f84eda9da1ea00ebf44c0.camel@microchip.com>

Hi Jacub,


On Fri, 2021-04-16 at 14:22 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, 16 Apr 2021 15:16:50 +0200 Steen Hegelund wrote:
> > +static int sparx5_set_mac_address(struct net_device *dev, void *p)
> > +{
> > +     const struct sockaddr *addr = p;
> > +
> > +     /* Record the address */
> > +     ether_addr_copy(dev->dev_addr, addr->sa_data);
> 
> I think you need to validate that add is a valid ethernet address.
> is_valid_ether_addr()

I will add validation.

> 
> > +struct net_device *sparx5_create_netdev(struct sparx5 *sparx5, u32 portno)
> > +{
> > +     struct sparx5_port *spx5_port;
> > +     struct net_device *ndev;
> > +     u64 val;
> > +
> > +     ndev = devm_alloc_etherdev(sparx5->dev, sizeof(struct sparx5_port));
> > +     if (!ndev)
> > +             return ERR_PTR(-ENOMEM);
> > +
> > +     SET_NETDEV_DEV(ndev, sparx5->dev);
> > +     spx5_port = netdev_priv(ndev);
> > +     spx5_port->ndev = ndev;
> > +     spx5_port->sparx5 = sparx5;
> > +     spx5_port->portno = portno;
> > +     sparx5_set_port_ifh(spx5_port->ifh, portno);
> > +     snprintf(ndev->name, IFNAMSIZ, "eth%d", portno);
> 
> Please don't try to name interfaces in the kernel.

OK.  I will remove that.

Thanks for your comments.

BR
Steen


From Steen.Hegelund at microchip.com  Tue Apr 20 13:54:15 2021
From: Steen.Hegelund at microchip.com (Steen.Hegelund at microchip.com)
Date: Tue, 20 Apr 2021 12:54:15 +0000
Subject: [PATCH net-next 09/10] net: sparx5: add ethtool configuration and
 statistics support
In-Reply-To: <20210416142613.7307cbc0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
 <20210416131657.3151464-10-steen.hegelund@microchip.com>
 <20210416142613.7307cbc0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <d5369c9e40e5eabcb8c2f8a133b50746c31f73bc.camel@microchip.com>

Hi Jacub,

On Fri, 2021-04-16 at 14:26 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, 16 Apr 2021 15:16:56 +0200 Steen Hegelund wrote:
> > +     "rx_in_bytes",
> > +     "rx_symbol_err",
> > +     "rx_pause",
> > +     "rx_unsup_opcode",
> > +     "rx_ok_bytes",
> > +     "rx_bad_bytes",
> > +     "rx_unicast",
> > +     "rx_multicast",
> > +     "rx_broadcast",
> > +     "rx_crc_err",
> > +     "rx_undersize",
> > +     "rx_fragments",
> > +     "rx_inrangelen_err",
> > +     "rx_outofrangelen_err",
> > +     "rx_oversize",
> > +     "rx_jabbers",
> > +     "rx_size64",
> > +     "rx_size65_127",
> > +     "rx_size128_255",
> > +     "rx_size256_511",
> > +     "rx_size512_1023",
> > +     "rx_size1024_1518",
> > +     "rx_size1519_max",
> > +     "pmac_rx_symbol_err",
> > +     "pmac_rx_pause",
> > +     "pmac_rx_unsup_opcode",
> > +     "pmac_rx_ok_bytes",
> > +     "pmac_rx_bad_bytes",
> > +     "pmac_rx_unicast",
> > +     "pmac_rx_multicast",
> > +     "pmac_rx_broadcast",
> > +     "pmac_rx_crc_err",
> > +     "pmac_rx_undersize",
> > +     "pmac_rx_fragments",
> > +     "pmac_rx_inrangelen_err",
> > +     "pmac_rx_outofrangelen_err",
> > +     "pmac_rx_oversize",
> > +     "pmac_rx_jabbers",
> > +     "pmac_rx_size64",
> > +     "pmac_rx_size65_127",
> > +     "pmac_rx_size128_255",
> > +     "pmac_rx_size256_511",
> > +     "pmac_rx_size512_1023",
> > +     "pmac_rx_size1024_1518",
> > +     "pmac_rx_size1519_max",
> > +     "rx_local_drop",
> > +     "rx_port_policer_drop",
> > +     "tx_out_bytes",
> > +     "tx_pause",
> > +     "tx_ok_bytes",
> > +     "tx_unicast",
> > +     "tx_multicast",
> > +     "tx_broadcast",
> > +     "tx_size64",
> > +     "tx_size65_127",
> > +     "tx_size128_255",
> > +     "tx_size256_511",
> > +     "tx_size512_1023",
> > +     "tx_size1024_1518",
> > +     "tx_size1519_max",
> > +     "tx_multi_coll",
> > +     "tx_late_coll",
> > +     "tx_xcoll",
> > +     "tx_defer",
> > +     "tx_xdefer",
> > +     "tx_backoff1",
> > +     "pmac_tx_pause",
> > +     "pmac_tx_ok_bytes",
> > +     "pmac_tx_unicast",
> > +     "pmac_tx_multicast",
> > +     "pmac_tx_broadcast",
> > +     "pmac_tx_size64",
> > +     "pmac_tx_size65_127",
> > +     "pmac_tx_size128_255",
> > +     "pmac_tx_size256_511",
> > +     "pmac_tx_size512_1023",
> > +     "pmac_tx_size1024_1518",
> > +     "pmac_tx_size1519_max",
> 
> Please see
> 
> https://patchwork.kernel.org/project/netdevbpf/list/?series=468795
> 
> (hopefully to be merged by the end of the week) and earlier patches for
> pause and FEC stats. Anything that has a standardized interface is off
> limits for the random ethtool -S grab bag.

OK.  I was not aware of that.

Thanks for your comments.

Best Regards
Steen


From rppt at kernel.org  Tue Apr 20 13:57:52 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 15:57:52 +0300
Subject: [PATCH v1 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <f900f889-f059-7d48-dfc7-145c8cd54cf6@redhat.com>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-2-rppt@kernel.org>
 <f900f889-f059-7d48-dfc7-145c8cd54cf6@redhat.com>
Message-ID: <YH7P0J4+1erJK7v5@kernel.org>

On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > Add comment describing the semantics of pfn_valid() that clarifies that
> > pfn_valid() only checks for availability of a memory map entry (i.e. struct
> > page) for a PFN rather than availability of usable memory backing that PFN.
> > 
> > The most "generic" version of pfn_valid() used by the configurations with
> > SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
> > suitable place for documentation about semantics of pfn_valid().
> > 
> > Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   include/linux/mmzone.h | 11 +++++++++++
> >   1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 47946cec7584..961f0eeefb62 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
> >   #endif
> >   #ifndef CONFIG_HAVE_ARCH_PFN_VALID
> > +/**
> > + * pfn_valid - check if there is a valid memory map entry for a PFN
> > + * @pfn: the page frame number to check
> > + *
> > + * Check if there is a valid memory map entry aka struct page for the @pfn.
> > + * Note, that availability of the memory map entry does not imply that
> > + * there is actual usable memory at that @pfn. The struct page may
> > + * represent a hole or an unusable page frame.
> > + *
> > + * Return: 1 for PFNs that have memory map entries and 0 otherwise
> > + */
> >   static inline int pfn_valid(unsigned long pfn)
> >   {
> >   	struct mem_section *ms;
> > 
> 
> I'd rephrase all "there is a valid memory map" to "there is a memory map"
> and add "pfn_valid() does to indicate whether the memory map as actually
> initialized -- see pfn_to_online_page()."
> 
> pfn_valid() means that we can do a pfn_to_page() and don't get a fault when
> accessing the "struct page". It doesn't state anything about the content.

Well, I mean valid in the sense you can access the struct page :)
How about:

/**
 * pfn_valid - check if there is a memory map entry for a PFN
 * @pfn: the page frame number to check
 *
 * Check if there is a memory map entry aka struct page for the @pfn and it
 * is safe to access that struct page; the struct page state may be
 * uninitialized -- see pfn_to_online_page().
 *
 * Note, that availability of the memory map entry does not imply that
 * there is actual usable memory at that @pfn. The struct page may
 * represent a hole or an unusable page frame.
 *
 * Return: 1 for PFNs that have memory map entries and 0 otherwise.
 */

-- 
Sincerely yours,
Mike.


From robh at kernel.org  Tue Apr 20 13:58:12 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 07:58:12 -0500
Subject: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek
 MT8183
In-Reply-To: <CANMq1KAshVgWPp=4KpjkwfAD=N4ZOw0xBCZHkfGob-TY0RCGew@mail.gmail.com>
References: <20210126011759.1605641-1-drinkcat@chromium.org>
 <20210126091747.v11.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
 <20210205175543.GA3363048@robh.at.kernel.org>
 <CANMq1KAshVgWPp=4KpjkwfAD=N4ZOw0xBCZHkfGob-TY0RCGew@mail.gmail.com>
Message-ID: <CAL_JsqKSSfuy0b9x70rd2u7Af=FDRY8S39PW8y+fS-Q4pevVig@mail.gmail.com>

On Fri, Feb 5, 2021 at 9:02 PM Nicolas Boichat <drinkcat at chromium.org> wrote:
>
> On Sat, Feb 6, 2021 at 1:55 AM Rob Herring <robh at kernel.org> wrote:
> >
> > On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote:
> > > Define a compatible string for the Mali Bifrost GPU found in
> > > Mediatek's MT8183 SoCs.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> > > ---
> > >
> > > Changes in v11:
> > >  - binding: power-domain-names not power-domainS-names
> > >
> > > Changes in v10:
> > >  - Fix the binding to make sure sram-supply property can be provided.
> > >
> > > Changes in v9: None
> > > Changes in v8: None
> > > Changes in v7: None
> > > Changes in v6:
> > >  - Rebased, actually tested with recent mesa driver.
> > >
> > > Changes in v5:
> > >  - Rename "2d" power domain to "core2"
> > >
> > > Changes in v4:
> > >  - Add power-domain-names description
> > >    (kept Alyssa's reviewed-by as the change is minor)
> > >
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > >  .../bindings/gpu/arm,mali-bifrost.yaml        | 28 +++++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > >
> >
> >
> > Please add Acked-by/Reviewed-by tags when posting new versions. However,
> > there's no need to repost patches *only* to add the tags. The upstream
> > maintainer will do that for acks received on the version they apply.
> >
> > If a tag was not added on purpose, please state why and what changed.
>
> There were changes in v11, I thought you'd want to review again?

Looked like a minor change from the changelog, so it would have been
appropriate to keep. However, I see another issue.

Rob


From david at redhat.com  Tue Apr 20 13:58:54 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 14:58:54 +0200
Subject: [PATCH v1 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <YH7P0J4+1erJK7v5@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-2-rppt@kernel.org>
 <f900f889-f059-7d48-dfc7-145c8cd54cf6@redhat.com>
 <YH7P0J4+1erJK7v5@kernel.org>
Message-ID: <07216f89-369f-0dcc-7bc0-97c204981396@redhat.com>

On 20.04.21 14:57, Mike Rapoport wrote:
> On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
>> On 20.04.21 11:09, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> Add comment describing the semantics of pfn_valid() that clarifies that
>>> pfn_valid() only checks for availability of a memory map entry (i.e. struct
>>> page) for a PFN rather than availability of usable memory backing that PFN.
>>>
>>> The most "generic" version of pfn_valid() used by the configurations with
>>> SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
>>> suitable place for documentation about semantics of pfn_valid().
>>>
>>> Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>> ---
>>>    include/linux/mmzone.h | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index 47946cec7584..961f0eeefb62 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>>>    #endif
>>>    #ifndef CONFIG_HAVE_ARCH_PFN_VALID
>>> +/**
>>> + * pfn_valid - check if there is a valid memory map entry for a PFN
>>> + * @pfn: the page frame number to check
>>> + *
>>> + * Check if there is a valid memory map entry aka struct page for the @pfn.
>>> + * Note, that availability of the memory map entry does not imply that
>>> + * there is actual usable memory at that @pfn. The struct page may
>>> + * represent a hole or an unusable page frame.
>>> + *
>>> + * Return: 1 for PFNs that have memory map entries and 0 otherwise
>>> + */
>>>    static inline int pfn_valid(unsigned long pfn)
>>>    {
>>>    	struct mem_section *ms;
>>>
>>
>> I'd rephrase all "there is a valid memory map" to "there is a memory map"
>> and add "pfn_valid() does to indicate whether the memory map as actually
>> initialized -- see pfn_to_online_page()."
>>
>> pfn_valid() means that we can do a pfn_to_page() and don't get a fault when
>> accessing the "struct page". It doesn't state anything about the content.
> 
> Well, I mean valid in the sense you can access the struct page :)
> How about:
> 
> /**
>   * pfn_valid - check if there is a memory map entry for a PFN
>   * @pfn: the page frame number to check
>   *
>   * Check if there is a memory map entry aka struct page for the @pfn and it
>   * is safe to access that struct page; the struct page state may be
>   * uninitialized -- see pfn_to_online_page().
>   *
>   * Note, that availability of the memory map entry does not imply that
>   * there is actual usable memory at that @pfn. The struct page may
>   * represent a hole or an unusable page frame.
>   *
>   * Return: 1 for PFNs that have memory map entries and 0 otherwise.
>   */
> 

Sounds good to me -- thanks!

Reviewed-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From lkp at intel.com  Tue Apr 20 13:59:29 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 20:59:29 +0800
Subject: [PATCH v3 02/10] iommu/dma: Introduce generic helper to retrieve
 RMR info
In-Reply-To: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-3-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104202046.BhsTW0nD-lkp@intel.com>

Hi Shameer,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pm/linux-next]
[also build test WARNING on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: x86_64-randconfig-a002-20210420 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project ca8eef7e3da8f750d7c7aa004fe426d1d34787ea)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/0day-ci/linux/commit/c68d4ba37ecc2173a2dc418799e23a184685d681
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout c68d4ba37ecc2173a2dc418799e23a184685d681
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/iommu/arm/arm-smmu/qcom_iommu.c:13:
>> include/linux/dma-iommu.h:92:31: warning: declaration of 'struct fwnode_handle' will not be visible outside of this function [-Wvisibility]
   int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
                                 ^
   include/linux/dma-iommu.h:93:1: error: expected identifier or '('
   {
   ^
   1 warning and 1 error generated.


vim +92 include/linux/dma-iommu.h

    91	
  > 92	int iommu_dma_get_rmrs(struct fwnode_handle *iommu, struct list_head *list);
    93	{
    94		return 0;
    95	}
    96	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 42003 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/7a2a8c73/attachment-0001.gz>

From robh at kernel.org  Tue Apr 20 14:01:13 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 08:01:13 -0500
Subject: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek
 MT8183
In-Reply-To: <20210126091747.v11.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
References: <20210126011759.1605641-1-drinkcat@chromium.org>
 <20210126091747.v11.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
Message-ID: <CAL_Jsq+gWm+94zF1XN2KiRYgAZewiDkCk5B5bhLB=M+-HbD=fA@mail.gmail.com>

On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat <drinkcat at chromium.org> wrote:
>
> Define a compatible string for the Mali Bifrost GPU found in
> Mediatek's MT8183 SoCs.
>
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> ---
>
> Changes in v11:
>  - binding: power-domain-names not power-domainS-names
>
> Changes in v10:
>  - Fix the binding to make sure sram-supply property can be provided.
>
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
>  - Rebased, actually tested with recent mesa driver.
>
> Changes in v5:
>  - Rename "2d" power domain to "core2"
>
> Changes in v4:
>  - Add power-domain-names description
>    (kept Alyssa's reviewed-by as the change is minor)
>
> Changes in v3: None
> Changes in v2: None
>
>  .../bindings/gpu/arm,mali-bifrost.yaml        | 28 +++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> index 184492162e7e..3e758f88e2cd 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> @@ -17,6 +17,7 @@ properties:
>      items:
>        - enum:
>            - amlogic,meson-g12a-mali
> +          - mediatek,mt8183-mali
>            - realtek,rtd1619-mali
>            - rockchip,px30-mali
>        - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
> @@ -41,6 +42,8 @@ properties:
>
>    mali-supply: true
>
> +  sram-supply: true
> +
>    operating-points-v2: true
>
>    power-domains:
> @@ -87,6 +90,31 @@ allOf:
>      then:
>        required:
>          - resets
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: mediatek,mt8183-mali
> +    then:
> +      properties:
> +        power-domains:
> +          description:
> +            List of phandle and PM domain specifier as documented in
> +            Documentation/devicetree/bindings/power/power_domain.txt
> +          minItems: 3
> +          maxItems: 3

This won't work because the top level schema restricts this to 1. The
top level needs to say:

power-domains:
  minItems: 1
  maxItems: 3

And you need just 'minItems: 3' here and 'maxItems: 1' in the else clause.

And drop the description. That's every 'power-domains' property.

> +        power-domain-names:
> +          items:
> +            - const: core0
> +            - const: core1
> +            - const: core2

Blank line

> +      required:
> +        - sram-supply
> +        - power-domains
> +        - power-domain-names
> +    else:
> +      properties:
> +        sram-supply: false
>
>  examples:
>    - |
> --
> 2.30.0.280.ga3ce27912f-goog
>


From yoan.picchi at arm.com  Tue Apr 20 14:08:22 2021
From: yoan.picchi at arm.com (Yoan Picchi)
Date: Tue, 20 Apr 2021 14:08:22 +0100
Subject: [PATCH v2 0/3] KVM: arm64: add more event counters for kvm_stat
Message-ID: <20210420130825.15585-1-yoan.picchi@arm.com>

Hi all,

Considering the feedback on my first version https://lore.kernel.org/linux-arm-kernel/20210319161711.24972-1-yoan.picchi at arm.com/
I started from scratch and focussed only on stage 2 page fault.

For the context, as mentioned in the KVM forum talk from 2019 
(https://kvmforum2019.sched.com/event/Tmwf/kvmstat-and-beyond-past-present-and-future-of-performance-monitoring-christian-borntrager-ibm page 10),
there are few event counters for kvm_stat in the arm64 version of kvm when
you compare it to something like the x86 version.
Those counters are used in kvm_stat by kernel/driver developers to
have a rough idea of the impact of their patches on the general performance.

In this patchset I introduce 3 counters to use in kvm stat. They aim to help
a kernel/driver dev troubleshot performance issues by letting them know how
much exits comes from stage 2 table faults, and thus, see if their changes
added a lot. Between the existing mmio_user_exit and the added page_mapped,
the main reasons for a stage 2 page fault should be covered and thus give
some finer granularity when looking for the source of exits.


Yoan Picchi (3):
  KVM: arm64: Add a stage2 page fault counter for kvm_stat
  KVM: arm64: Add two page mapping counters for kvm_stat
  KVM: arm64: Add irq_exit counter for kvm_stat

 arch/arm64/include/asm/kvm_host.h | 4 ++++
 arch/arm64/kvm/guest.c            | 4 ++++
 arch/arm64/kvm/handle_exit.c      | 1 +
 arch/arm64/kvm/hyp/pgtable.c      | 5 +++++
 arch/arm64/kvm/mmu.c              | 2 ++
 5 files changed, 16 insertions(+)

-- 
2.17.1



From yoan.picchi at arm.com  Tue Apr 20 14:08:23 2021
From: yoan.picchi at arm.com (Yoan Picchi)
Date: Tue, 20 Apr 2021 14:08:23 +0100
Subject: [PATCH v2 1/3] KVM: arm64: Add a stage2 page fault counter for
 kvm_stat
In-Reply-To: <20210420130825.15585-1-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
Message-ID: <20210420130825.15585-2-yoan.picchi@arm.com>

This counter is meant to detect stage 2 page fault exits. This is meant to
measure how much those page fault influence the performance (by comparing
this number of exits to some other exit causes).
For now this counter is generic, but some more granularity is planned in
the next commits so that one know how much of the page fault are for memory
allocation, or for mmio for instance. The idea being that one using this
counter can get a better idea of what is trigerring those exits to try to
fix it.

Signed-off-by: Yoan Picchi <yoan.picchi at arm.com>
---
 arch/arm64/include/asm/kvm_host.h | 1 +
 arch/arm64/kvm/guest.c            | 1 +
 arch/arm64/kvm/mmu.c              | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527..02891ce94 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -561,6 +561,7 @@ struct kvm_vcpu_stat {
 	u64 wfi_exit_stat;
 	u64 mmio_exit_user;
 	u64 mmio_exit_kernel;
+	u64 stage2_abort_exit;
 	u64 exits;
 };
 
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 9bbd30e62..82a4b6275 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -38,6 +38,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	VCPU_STAT("wfi_exit_stat", wfi_exit_stat),
 	VCPU_STAT("mmio_exit_user", mmio_exit_user),
 	VCPU_STAT("mmio_exit_kernel", mmio_exit_kernel),
+	VCPU_STAT("stage2_abort_exit", stage2_abort_exit),
 	VCPU_STAT("exits", exits),
 	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
 	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f..c3527ccf6 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -966,6 +966,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
 	fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
 	is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
 
+
 	/* Synchronous External Abort? */
 	if (kvm_vcpu_abt_issea(vcpu)) {
 		/*
@@ -980,6 +981,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
 
 	trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
 			      kvm_vcpu_get_hfar(vcpu), fault_ipa);
+	vcpu->stat.stage2_abort_exit++;
 
 	/* Check the stage-2 fault is trans. fault or write fault */
 	if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
-- 
2.17.1



From yoan.picchi at arm.com  Tue Apr 20 14:08:24 2021
From: yoan.picchi at arm.com (Yoan Picchi)
Date: Tue, 20 Apr 2021 14:08:24 +0100
Subject: [PATCH v2 2/3] KVM: arm64: Add two page mapping counters for kvm_stat
In-Reply-To: <20210420130825.15585-1-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
Message-ID: <20210420130825.15585-3-yoan.picchi@arm.com>

This patch adds regular_page_mapped and huge_page_mapped.
regular_page_mapped is increased when a page of the smallest granularity
is mapped. This is usually a 4k, 16k or 64k page.
huge_page_mapped is increased when a huge page of any size other than the
smallest granularity is mapped.
Those counters only count pages allocated for the data and doesn't count
the pages/blocks allocated to the page tables as I don't see where those
might be needed to be recorded

I can see two usecases for those counters :
	We can detect memory pressure in the host when the guest gets
regular pages instead of huge ones.
	May help detecting an abnormal memory usage like some recurring
allocs past the kernel and a few program starts.
With the previous patch about stage2_abort_exit, it have the added
benefit of specifying the second main cause of stage 2 page fault (the
other being mmio access)

To test this patch I did start a guest VM and monitor the page allocation.
By default it only allocate huge pages. Then I tried to disable the huge
pages with : echo never > /sys/kernel/mm/transparent_hugepage/enabled
Starting the VM, it no longer allocate any huge page, but only regular
pages.

I can't log into the guess because it doesn't recognize my keyboard. To
circumvent that I added some command to the init script that need some
memory : cat /dev/zero | head -c 1000m | tail
This take 1GiB of memory before finishing.
>From memory, it allocate 525 or so huge table which is around what I would
expect with 2MB pages.

I did check the relation between stage 2 exits, mmio exits and
allocation. The mmio + allocation account for almost all the stage 2 exit
as expected. There was only about 20 exits that was neither a mmio or an
alloc during the kernel boot. I did not look what they are, but it can be
a memory permission relaxation, or resizing a page.

My main concern here is about the case where we replace a page/block by
another/resize a block. I don't fully understand the mechanism yet and
so don't know if it should be counted as an allocation or not. For now I
don't account it.

Signed-off-by: Yoan Picchi <yoan.picchi at arm.com>
---
 arch/arm64/include/asm/kvm_host.h | 2 ++
 arch/arm64/kvm/guest.c            | 2 ++
 arch/arm64/kvm/hyp/pgtable.c      | 5 +++++
 3 files changed, 9 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 02891ce94..8f9d27571 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -547,6 +547,8 @@ static inline bool __vcpu_write_sys_reg_to_cpu(u64 val, int reg)
 
 struct kvm_vm_stat {
 	ulong remote_tlb_flush;
+	ulong regular_page_mapped;
+	ulong huge_page_mapped;
 };
 
 struct kvm_vcpu_stat {
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 82a4b6275..41316b30e 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -42,6 +42,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	VCPU_STAT("exits", exits),
 	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
 	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
+	VM_STAT("regular_page_mapped", regular_page_mapped),
+	VM_STAT("huge_page_mapped", huge_page_mapped),
 	{ NULL }
 };
 
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 4d177ce1d..2aba2b636 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -498,6 +498,11 @@ static int stage2_map_walker_try_leaf(u64 addr, u64 end, u32 level,
 	smp_store_release(ptep, new);
 	get_page(page);
 	data->phys += granule;
+	if (level == KVM_PGTABLE_MAX_LEVELS - 1)
+		data->mmu->kvm->stat.regular_page_mapped++;
+	else
+		data->mmu->kvm->stat.huge_page_mapped++;
+
 	return 0;
 }
 
-- 
2.17.1



From yoan.picchi at arm.com  Tue Apr 20 14:08:25 2021
From: yoan.picchi at arm.com (Yoan Picchi)
Date: Tue, 20 Apr 2021 14:08:25 +0100
Subject: [PATCH v2 3/3] KVM: arm64: Add irq_exit counter for kvm_stat
In-Reply-To: <20210420130825.15585-1-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
Message-ID: <20210420130825.15585-4-yoan.picchi@arm.com>

This counter is meant to detect when the guest vm exits due to an
interrupt. Those interrupts might be unrelated to the guest VM (say, some
network packet arrived, and such) but they still trigger an exit which is
recorded by the "exit" counter. The main purpose of this counter is to
give some more granularity to this base exit counter so that one can have
a rough idea of where those exits comes from and so, if those general
exits happen because of the host or of the guest.

Signed-off-by: Yoan Picchi <yoan.picchi at arm.com>
---
 arch/arm64/include/asm/kvm_host.h | 1 +
 arch/arm64/kvm/guest.c            | 1 +
 arch/arm64/kvm/handle_exit.c      | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8f9d27571..185e707fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -565,6 +565,7 @@ struct kvm_vcpu_stat {
 	u64 mmio_exit_kernel;
 	u64 stage2_abort_exit;
 	u64 exits;
+	u64 irq_exits;
 };
 
 int kvm_vcpu_preferred_target(struct kvm_vcpu_init *init);
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 41316b30e..eb4c24b7a 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -42,6 +42,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	VCPU_STAT("exits", exits),
 	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
 	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
+	VCPU_STAT("irq_exits", irq_exits),
 	VM_STAT("regular_page_mapped", regular_page_mapped),
 	VM_STAT("huge_page_mapped", huge_page_mapped),
 	{ NULL }
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index cebe39f3b..7e5dbc5ff 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -244,6 +244,7 @@ int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
 
 	switch (exception_index) {
 	case ARM_EXCEPTION_IRQ:
+		vcpu->stat.irq_exits++;
 		return 1;
 	case ARM_EXCEPTION_EL1_SERROR:
 		return 1;
-- 
2.17.1



From robh at kernel.org  Tue Apr 20 14:13:36 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 08:13:36 -0500
Subject: [PATCH 1/6] dt-bindings: PCI: ti,am65: Add PCIe host mode
 dt-bindings for TI's AM65 SoC
In-Reply-To: <985bd950-7bdf-d9b5-0a89-c05a56739c68@ti.com>
References: <20210325090026.8843-1-kishon@ti.com>
 <20210325090026.8843-2-kishon@ti.com>
 <20210325233812.GA1943834@robh.at.kernel.org>
 <985bd950-7bdf-d9b5-0a89-c05a56739c68@ti.com>
Message-ID: <CAL_JsqJ+LLLxOgb_cXNKSzYToWArnPESHDRKjaezn1bh2yBMFA@mail.gmail.com>

On Tue, Mar 30, 2021 at 4:29 AM Kishon Vijay Abraham I <kishon at ti.com> wrote:
>
> Hi Rob,
>
> On 26/03/21 5:08 am, Rob Herring wrote:
> > On Thu, Mar 25, 2021 at 02:30:21PM +0530, Kishon Vijay Abraham I wrote:
> >> Add PCIe host mode dt-bindings for TI's AM65 SoC.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> >> ---
> >>  .../bindings/pci/ti,am65-pci-host.yaml        | 111 ++++++++++++++++++
> >>  1 file changed, 111 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
> >> new file mode 100644
> >> index 000000000000..b77e492886fa
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
> >> @@ -0,0 +1,111 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/
> >> +%YAML 1.2
> >> +---
> >> +$id: "http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#"
> >> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> >> +
> >> +title: TI AM65 PCI Host
> >> +
> >> +maintainers:
> >> +  - Kishon Vijay Abraham I <kishon at ti.com>
> >> +
> >> +allOf:
> >> +  - $ref: /schemas/pci/pci-bus.yaml#
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - ti,am654-pcie-rc
> >> +
> >> +  reg:
> >> +    maxItems: 4
> >> +
> >> +  reg-names:
> >> +    items:
> >> +      - const: app
> >> +      - const: dbics
> >
> > Please use 'dbi' like everyone else if this isn't shared with the other
> > TI DW PCI bindings.
>
> I'm just converting existing binding in pci-keystone.txt to yaml.
> Documentation/devicetree/bindings/pci/pci-keystone.txt
>
> Device tree for AM65 is also already in the upstream kernel.
>
> I can try to remove the am65 specific part from pci-keystone.txt

Can you remove pci-keystone.txt entirely. That's what 'converting' means.

Rob


From rppt at kernel.org  Tue Apr 20 14:16:07 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:16:07 +0300
Subject: [PATCH v2 0/2] secretmem: optimize page_is_secretmem()
Message-ID: <20210420131611.8259-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.

@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.

v2:
* move the check for secretmem page in gup_pte_range after we get a
  reference to the page, per Matthew.

Mike Rapoport (2):
  secretmem/gup: don't check if page is secretmem without reference
  secretmem: optimize page_is_secretmem()

 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/gup.c                  |  6 +++---
 mm/secretmem.c            | 12 +-----------
 3 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 14:16:08 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:16:08 +0300
Subject: [PATCH v2 1/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <20210420131611.8259-1-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
Message-ID: <20210420131611.8259-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.

To avoid potential race move the check after try_grab_compound_head().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 mm/gup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index c3a17b189064..4b58c016e949 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2080,13 +2080,13 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
 		page = pte_page(pte);
 
-		if (page_is_secretmem(page))
-			goto pte_unmap;
-
 		head = try_grab_compound_head(page, 1, flags);
 		if (!head)
 			goto pte_unmap;
 
+		if (page_is_secretmem(page))
+			goto pte_unmap;
+
 		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
 			put_compound_head(head, 1, flags);
 			goto pte_unmap;
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 14:16:09 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:16:09 +0300
Subject: [PATCH v2 1/2] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210420131611.8259-1-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
Message-ID: <20210420131611.8259-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".

The perf profile of the test indicated that the regression is caused by
page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):

 27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
  0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
  0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem

Further analysis showed that the slow down happens because neither
page_is_secretmem() nor page_mapping() are not inline and moreover,
multiple page flags checks in page_mapping() involve calling
compound_head() several times for the same page.

Make page_is_secretmem() inline and replace page_mapping() with page flag
checks that do not imply page-to-head conversion.

Reported-by: kernel test robot <oliver.sang at intel.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/secretmem.c            | 12 +-----------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 907a6734059c..b842b38cbeb1 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -4,8 +4,32 @@
 
 #ifdef CONFIG_SECRETMEM
 
+extern const struct address_space_operations secretmem_aops;
+
+static inline bool page_is_secretmem(struct page *page)
+{
+	struct address_space *mapping;
+
+	/*
+	 * Using page_mapping() is quite slow because of the actual call
+	 * instruction and repeated compound_head(page) inside the
+	 * page_mapping() function.
+	 * We know that secretmem pages are not compound and LRU so we can
+	 * save a couple of cycles here.
+	 */
+	if (PageCompound(page) || !PageLRU(page))
+		return false;
+
+	mapping = (struct address_space *)
+		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
+
+	if (mapping != page->mapping)
+		return false;
+
+	return page->mapping->a_ops == &secretmem_aops;
+}
+
 bool vma_is_secretmem(struct vm_area_struct *vma);
-bool page_is_secretmem(struct page *page);
 bool secretmem_active(void);
 
 #else
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 3b1ba3991964..0bcd15e1b549 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -151,22 +151,12 @@ static void secretmem_freepage(struct page *page)
 	clear_highpage(page);
 }
 
-static const struct address_space_operations secretmem_aops = {
+const struct address_space_operations secretmem_aops = {
 	.freepage	= secretmem_freepage,
 	.migratepage	= secretmem_migratepage,
 	.isolate_page	= secretmem_isolate_page,
 };
 
-bool page_is_secretmem(struct page *page)
-{
-	struct address_space *mapping = page_mapping(page);
-
-	if (!mapping)
-		return false;
-
-	return mapping->a_ops == &secretmem_aops;
-}
-
 static struct vfsmount *secretmem_mnt;
 
 static struct file *secretmem_file_create(unsigned long flags)
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 14:16:10 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:16:10 +0300
Subject: [PATCH v2 2/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <20210420131611.8259-1-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
Message-ID: <20210420131611.8259-4-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.

To avoid potential race move the check after try_grab_compound_head().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 mm/gup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index c3a17b189064..4b58c016e949 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2080,13 +2080,13 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
 		page = pte_page(pte);
 
-		if (page_is_secretmem(page))
-			goto pte_unmap;
-
 		head = try_grab_compound_head(page, 1, flags);
 		if (!head)
 			goto pte_unmap;
 
+		if (page_is_secretmem(page))
+			goto pte_unmap;
+
 		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
 			put_compound_head(head, 1, flags);
 			goto pte_unmap;
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 14:16:11 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:16:11 +0300
Subject: [PATCH v2 2/2] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210420131611.8259-1-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
Message-ID: <20210420131611.8259-5-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".

The perf profile of the test indicated that the regression is caused by
page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):

 27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
  0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
  0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem

Further analysis showed that the slow down happens because neither
page_is_secretmem() nor page_mapping() are not inline and moreover,
multiple page flags checks in page_mapping() involve calling
compound_head() several times for the same page.

Make page_is_secretmem() inline and replace page_mapping() with page flag
checks that do not imply page-to-head conversion.

Reported-by: kernel test robot <oliver.sang at intel.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/secretmem.c            | 12 +-----------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 907a6734059c..b842b38cbeb1 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -4,8 +4,32 @@
 
 #ifdef CONFIG_SECRETMEM
 
+extern const struct address_space_operations secretmem_aops;
+
+static inline bool page_is_secretmem(struct page *page)
+{
+	struct address_space *mapping;
+
+	/*
+	 * Using page_mapping() is quite slow because of the actual call
+	 * instruction and repeated compound_head(page) inside the
+	 * page_mapping() function.
+	 * We know that secretmem pages are not compound and LRU so we can
+	 * save a couple of cycles here.
+	 */
+	if (PageCompound(page) || !PageLRU(page))
+		return false;
+
+	mapping = (struct address_space *)
+		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
+
+	if (mapping != page->mapping)
+		return false;
+
+	return page->mapping->a_ops == &secretmem_aops;
+}
+
 bool vma_is_secretmem(struct vm_area_struct *vma);
-bool page_is_secretmem(struct page *page);
 bool secretmem_active(void);
 
 #else
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 3b1ba3991964..0bcd15e1b549 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -151,22 +151,12 @@ static void secretmem_freepage(struct page *page)
 	clear_highpage(page);
 }
 
-static const struct address_space_operations secretmem_aops = {
+const struct address_space_operations secretmem_aops = {
 	.freepage	= secretmem_freepage,
 	.migratepage	= secretmem_migratepage,
 	.isolate_page	= secretmem_isolate_page,
 };
 
-bool page_is_secretmem(struct page *page)
-{
-	struct address_space *mapping = page_mapping(page);
-
-	if (!mapping)
-		return false;
-
-	return mapping->a_ops == &secretmem_aops;
-}
-
 static struct vfsmount *secretmem_mnt;
 
 static struct file *secretmem_file_create(unsigned long flags)
-- 
2.28.0



From david at redhat.com  Tue Apr 20 14:19:56 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 15:19:56 +0200
Subject: [PATCH v2 1/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <20210420131611.8259-2-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
 <20210420131611.8259-2-rppt@kernel.org>
Message-ID: <95b7fa81-f72e-c63f-0456-4c25dee8a5eb@redhat.com>

On 20.04.21 15:16, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The check in gup_pte_range() whether a page belongs to a secretmem mapping
> is performed before grabbing the page reference.
> 
> To avoid potential race move the check after try_grab_compound_head().
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   mm/gup.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index c3a17b189064..4b58c016e949 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2080,13 +2080,13 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>   		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
>   		page = pte_page(pte);
>   
> -		if (page_is_secretmem(page))
> -			goto pte_unmap;
> -
>   		head = try_grab_compound_head(page, 1, flags);
>   		if (!head)
>   			goto pte_unmap;
>   
> +		if (page_is_secretmem(page))
> +			goto pte_unmap;
> +

Looking at the hunk below, I wonder if you're missing a put_compound_head().

(also, I'd do if unlikely(page_is_secretmem()) but that's a different 
discussion)

>   		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
>   			put_compound_head(head, 1, flags);
>   			goto pte_unmap;
> 


-- 
Thanks,

David / dhildenb



From jitao.shi at mediatek.com  Tue Apr 20 14:26:10 2021
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 20 Apr 2021 21:26:10 +0800
Subject: [PATCH 1/4] drm/panel: seperate panel power control from panel
 prepare/unprepare
Message-ID: <20210420132614.150242-1-jitao.shi@mediatek.com>

Some dsi panels require the dsi lanes keeping low before panel power
on. So seperate the panel power control and the communication with panel.

And put the power control in drm_panel_prepare_power and
drm_panel_unprepare_power. Put the communication with panel in
drm_panel_prepare and drm_panel_unprepare.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/gpu/drm/bridge/panel.c | 17 +++++++++++++++
 drivers/gpu/drm/drm_panel.c    | 38 ++++++++++++++++++++++++++++++++++
 include/drm/drm_bridge.h       |  2 ++
 include/drm/drm_panel.h        | 17 +++++++++++++++
 4 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 0ddc37551194..a19c96e710fc 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -125,6 +125,23 @@ static int panel_bridge_get_modes(struct drm_bridge *bridge,
 	return drm_panel_get_modes(panel_bridge->panel, connector);
 }
 
+int panel_bridge_prepare_power(struct drm_bridge *bridge)
+{
+	struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+
+	return drm_panel_prepare_power(panel_bridge->panel);
+}
+EXPORT_SYMBOL(panel_bridge_prepare_power);
+
+int panel_bridge_unprepare_power(struct drm_bridge *bridge)
+{
+        struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+
+        return drm_panel_unprepare_power(panel_bridge->panel);
+}
+EXPORT_SYMBOL(panel_bridge_unprepare_power);
+
+
 static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
 	.attach = panel_bridge_attach,
 	.detach = panel_bridge_detach,
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index f634371c717a..7bb5185db17d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -115,6 +115,24 @@ int drm_panel_prepare(struct drm_panel *panel)
 }
 EXPORT_SYMBOL(drm_panel_prepare);
 
+/**
+ * drm_panel_prepare_power - power on a panel's power
+ * @panel: DRM panel
+ *
+ * Calling this function will enable power and deassert any reset signals to
+ * the panel.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_prepare_power(struct drm_panel *panel)
+{
+	if (panel && panel->funcs && panel->funcs->prepare_power)
+		return panel->funcs->prepare_power(panel);
+
+	return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_prepare_power);
+
 /**
  * drm_panel_unprepare - power off a panel
  * @panel: DRM panel
@@ -138,6 +156,26 @@ int drm_panel_unprepare(struct drm_panel *panel)
 }
 EXPORT_SYMBOL(drm_panel_unprepare);
 
+/**
+ * drm_panel_unprepare_power - power off a panel
+ * @panel: DRM panel
+ *
+ * Calling this function will completely power off a panel (assert the panel's
+ * reset, turn off power supplies, ...). After this function has completed, it
+ * is usually no longer possible to communicate with the panel until another
+ * call to drm_panel_prepare_power and drm_panel_prepare().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_unprepare_power(struct drm_panel *panel)
+{
+	if (panel && panel->funcs && panel->funcs->unprepare_power)
+		return panel->funcs->unprepare_power(panel);
+
+	return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_unprepare_power);
+
 /**
  * drm_panel_enable - enable a panel
  * @panel: DRM panel
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 2195daa289d2..cc94c9da47d8 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -892,6 +892,8 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev,
 						   struct drm_panel *panel,
 						   u32 connector_type);
 struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
+int panel_bridge_prepare_power(struct drm_bridge *bridge);
+int panel_bridge_unprepare_power(struct drm_bridge *bridge);
 #endif
 
 #endif
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 33605c3f0eba..48e83712ad44 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -68,6 +68,13 @@ enum drm_panel_orientation;
  * functionality to enable/disable backlight.
  */
 struct drm_panel_funcs {
+	/**
+	 * @prepare_power:
+	 *
+	 * Turn on panel power.
+	 */
+	int (*prepare_power)(struct drm_panel *panel);
+
 	/**
 	 * @prepare:
 	 *
@@ -115,6 +122,13 @@ struct drm_panel_funcs {
 	int (*get_modes)(struct drm_panel *panel,
 			 struct drm_connector *connector);
 
+	/**
+	 * @unprepare_power:
+	 *
+	 * Turn off panel_power.
+	 */
+	int (*unprepare_power)(struct drm_panel *panel);
+
 	/**
 	 * @get_timings:
 	 *
@@ -180,6 +194,9 @@ void drm_panel_init(struct drm_panel *panel, struct device *dev,
 void drm_panel_add(struct drm_panel *panel);
 void drm_panel_remove(struct drm_panel *panel);
 
+int drm_panel_prepare_power(struct drm_panel *panel);
+int drm_panel_unprepare_power(struct drm_panel *panel);
+
 int drm_panel_prepare(struct drm_panel *panel);
 int drm_panel_unprepare(struct drm_panel *panel);
 
-- 
2.25.1

From jitao.shi at mediatek.com  Tue Apr 20 14:26:11 2021
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 20 Apr 2021 21:26:11 +0800
Subject: [PATCH 2/4] drm/panel: boe-tv101wum-n16 seperate the panel power
 control
In-Reply-To: <20210420132614.150242-1-jitao.shi@mediatek.com>
References: <20210420132614.150242-1-jitao.shi@mediatek.com>
Message-ID: <20210420132614.150242-2-jitao.shi@mediatek.com>

Seperate the panel power control from prepare/unprepare.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 .../gpu/drm/panel/panel-boe-tv101wum-nl6.c    | 72 +++++++++++++------
 1 file changed, 50 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index db9d0b86d542..dc49079a74d1 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -50,6 +50,7 @@ struct boe_panel {
 	struct regulator *avdd;
 	struct gpio_desc *enable_gpio;
 
+	bool prepared_power;
 	bool prepared;
 };
 
@@ -488,22 +489,13 @@ static int boe_panel_enter_sleep_mode(struct boe_panel *boe)
 	return 0;
 }
 
-static int boe_panel_unprepare(struct drm_panel *panel)
+static int boe_panel_unprepare_power(struct drm_panel *panel)
 {
 	struct boe_panel *boe = to_boe_panel(panel);
-	int ret;
 
-	if (!boe->prepared)
+	if (!boe->prepared_power)
 		return 0;
 
-	ret = boe_panel_enter_sleep_mode(boe);
-	if (ret < 0) {
-		dev_err(panel->dev, "failed to set panel off: %d\n", ret);
-		return ret;
-	}
-
-	msleep(150);
-
 	if (boe->desc->discharge_on_disable) {
 		regulator_disable(boe->avee);
 		regulator_disable(boe->avdd);
@@ -512,6 +504,7 @@ static int boe_panel_unprepare(struct drm_panel *panel)
 		usleep_range(5000, 7000);
 		regulator_disable(boe->pp1800);
 	} else {
+		msleep(150);
 		gpiod_set_value(boe->enable_gpio, 0);
 		usleep_range(500, 1000);
 		regulator_disable(boe->avee);
@@ -520,17 +513,39 @@ static int boe_panel_unprepare(struct drm_panel *panel)
 		regulator_disable(boe->pp1800);
 	}
 
+	boe->prepared_power = false;
+
+	return 0;
+}
+
+static int boe_panel_unprepare(struct drm_panel *panel)
+{
+	struct boe_panel *boe = to_boe_panel(panel);
+	int ret;
+
+	if (!boe->prepared)
+		return 0;
+
+	if (!boe->desc->discharge_on_disable) {
+		ret = boe_panel_enter_sleep_mode(boe);
+		if (ret < 0) {
+			dev_err(panel->dev, "failed to set panel off: %d\n",
+				ret);
+			return ret;
+		}
+	}
+
 	boe->prepared = false;
 
 	return 0;
 }
 
-static int boe_panel_prepare(struct drm_panel *panel)
+static int boe_panel_prepare_power(struct drm_panel *panel)
 {
 	struct boe_panel *boe = to_boe_panel(panel);
 	int ret;
 
-	if (boe->prepared)
+	if (boe->prepared_power)
 		return 0;
 
 	gpiod_set_value(boe->enable_gpio, 0);
@@ -558,18 +573,10 @@ static int boe_panel_prepare(struct drm_panel *panel)
 	gpiod_set_value(boe->enable_gpio, 1);
 	usleep_range(6000, 10000);
 
-	ret = boe_panel_init_dcs_cmd(boe);
-	if (ret < 0) {
-		dev_err(panel->dev, "failed to init panel: %d\n", ret);
-		goto poweroff;
-	}
-
-	boe->prepared = true;
+	boe->prepared_power = true;
 
 	return 0;
 
-poweroff:
-	regulator_disable(boe->avee);
 poweroffavdd:
 	regulator_disable(boe->avdd);
 poweroff1v8:
@@ -580,6 +587,25 @@ static int boe_panel_prepare(struct drm_panel *panel)
 	return ret;
 }
 
+static int boe_panel_prepare(struct drm_panel *panel)
+{
+	struct boe_panel *boe = to_boe_panel(panel);
+	int ret;
+
+	if (boe->prepared)
+		return 0;
+
+	ret = boe_panel_init_dcs_cmd(boe);
+	if (ret < 0) {
+		dev_err(panel->dev, "failed to init panel: %d\n", ret);
+		return ret;
+	}
+
+	boe->prepared = true;
+
+	return 0;
+}
+
 static int boe_panel_enable(struct drm_panel *panel)
 {
 	msleep(130);
@@ -749,7 +775,9 @@ static int boe_panel_get_modes(struct drm_panel *panel,
 
 static const struct drm_panel_funcs boe_panel_funcs = {
 	.unprepare = boe_panel_unprepare,
+	.unprepare_power = boe_panel_unprepare_power,
 	.prepare = boe_panel_prepare,
+	.prepare_power = boe_panel_prepare_power,
 	.enable = boe_panel_enable,
 	.get_modes = boe_panel_get_modes,
 };
-- 
2.25.1

From jitao.shi at mediatek.com  Tue Apr 20 14:26:13 2021
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 20 Apr 2021 21:26:13 +0800
Subject: [PATCH 4/4] drm/mediatek: add dsi module reset driver
In-Reply-To: <20210420132614.150242-1-jitao.shi@mediatek.com>
References: <20210420132614.150242-1-jitao.shi@mediatek.com>
Message-ID: <20210420132614.150242-4-jitao.shi@mediatek.com>

Reset dsi HW to default when power on. Prevent the setting differet
between bootloader and kernel.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 36 +++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 455fe582c6b5..113438ddd4cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -7,10 +7,12 @@
 #include <linux/component.h>
 #include <linux/iopoll.h>
 #include <linux/irq.h>
+#include <linux/mfd/syscon.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
+#include <linux/regmap.h>
 
 #include <video/mipi_display.h>
 #include <video/videomode.h>
@@ -143,6 +145,8 @@
 #define DATA_0				(0xff << 16)
 #define DATA_1				(0xff << 24)
 
+#define MMSYS_SW_RST_DSI_B BIT(25)
+
 #define NS_TO_CYCLE(n, c)    ((n) / (c) + (((n) % (c)) ? 1 : 0))
 
 #define MTK_DSI_HOST_IS_READ(type) \
@@ -186,7 +190,8 @@ struct mtk_dsi {
 	struct drm_bridge *next_bridge;
 	struct drm_connector *connector;
 	struct phy *phy;
-
+	struct regmap *mmsys_sw_rst_b;
+	u32 sw_rst_b;
 	void __iomem *regs;
 
 	struct clk *engine_clk;
@@ -272,6 +277,16 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
 	mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
 }
 
+static void mtk_dsi_reset_all(struct mtk_dsi *dsi)
+{
+	regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
+			   MMSYS_SW_RST_DSI_B, 0);
+	usleep_range(1000, 1100);
+
+	regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
+			   MMSYS_SW_RST_DSI_B, MMSYS_SW_RST_DSI_B);
+}
+
 static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
 {
 	mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
@@ -985,6 +1000,8 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
 
 	ret = mtk_dsi_encoder_init(drm, dsi);
 
+	mtk_dsi_reset_all(dsi);
+
 	return ret;
 }
 
@@ -1007,6 +1024,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct drm_panel *panel;
 	struct resource *regs;
+	struct regmap *regmap;
 	int irq_num;
 	int ret;
 
@@ -1022,6 +1040,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	regmap = syscon_regmap_lookup_by_phandle(dev->of_node,
+						 "mediatek,syscon-dsi");
+	ret = of_property_read_u32_index(dev->of_node, "mediatek,syscon-dsi", 1,
+					 &dsi->sw_rst_b);
+
+	if (IS_ERR(regmap))
+		ret = PTR_ERR(regmap);
+
+	if (ret) {
+		ret = PTR_ERR(regmap);
+		dev_err(dev, "Failed to get mmsys registers: %d\n", ret);
+		return ret;
+	}
+
+	dsi->mmsys_sw_rst_b = regmap;
+
 	ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
 					  &panel, &dsi->next_bridge);
 	if (ret)
-- 
2.25.1

From jitao.shi at mediatek.com  Tue Apr 20 14:26:12 2021
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 20 Apr 2021 21:26:12 +0800
Subject: [PATCH 3/4] drm/mediatek: fine tune the dsi panel's power sequence
In-Reply-To: <20210420132614.150242-1-jitao.shi@mediatek.com>
References: <20210420132614.150242-1-jitao.shi@mediatek.com>
Message-ID: <20210420132614.150242-3-jitao.shi@mediatek.com>

Add the drm_panel_prepare_power and drm_panel_unprepare_power control.
Turn on panel power(drm_panel_prepare_power) and control before dsi
enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last
turn on backlight.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index a1ff152ef468..455fe582c6b5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -615,10 +615,13 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 	dsi->data_rate = DIV_ROUND_UP_ULL(dsi->vm.pixelclock * bit_per_pixel,
 					  dsi->lanes);
 
+	if (panel_bridge_prepare_power(dsi->next_bridge))
+		DRM_INFO("can't prepare power the panel\n");
+
 	ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
 	if (ret < 0) {
 		dev_err(dev, "Failed to set data rate: %d\n", ret);
-		goto err_refcount;
+		goto err_prepare_power;
 	}
 
 	phy_power_on(dsi->phy);
@@ -661,7 +664,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 	clk_disable_unprepare(dsi->engine_clk);
 err_phy_power_off:
 	phy_power_off(dsi->phy);
-err_refcount:
+err_prepare_power:
+	if (panel_bridge_unprepare_power(dsi->next_bridge))
+		DRM_INFO("Can't unprepare power the panel\n");
 	dsi->refcount--;
 	return ret;
 }
@@ -694,6 +699,9 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
 	clk_disable_unprepare(dsi->digital_clk);
 
 	phy_power_off(dsi->phy);
+
+	if (panel_bridge_unprepare_power(dsi->next_bridge))
+		DRM_INFO("Can't unprepare power the panel\n");
 }
 
 static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
-- 
2.25.1

From maz at kernel.org  Tue Apr 20 14:26:52 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 14:26:52 +0100
Subject: [PATCH v2 3/3] KVM: arm64: Add irq_exit counter for kvm_stat
In-Reply-To: <20210420130825.15585-4-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
 <20210420130825.15585-4-yoan.picchi@arm.com>
Message-ID: <878s5dqe77.wl-maz@kernel.org>

On Tue, 20 Apr 2021 14:08:25 +0100,
Yoan Picchi <yoan.picchi at arm.com> wrote:
> 
> This counter is meant to detect when the guest vm exits due to an
> interrupt. Those interrupts might be unrelated to the guest VM (say, some
> network packet arrived, and such) but they still trigger an exit which is
> recorded by the "exit" counter. The main purpose of this counter is to
> give some more granularity to this base exit counter so that one can have
> a rough idea of where those exits comes from and so, if those general
> exits happen because of the host or of the guest.

I don't think this makes much sense. Why should we account interrupts
for the guest when the interrupts don't have anything to do with it?
And guess what, they almost *never* do. The only interrupt that could
be accountable to the vcpu is the vPE doorbell, and that one can never
causes an exit, by definition.

The kernel already provides quite a lot around interrupt accounting
already, and I don't think we need to do add more for the guest. If
this made any sense, it should be applicable to any userspace task,
not just vcpus.

Thanks,

	M.

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


From michael at walle.cc  Tue Apr 20 14:27:24 2021
From: michael at walle.cc (Michael Walle)
Date: Tue, 20 Apr 2021 15:27:24 +0200
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <20210416234225.3715819-1-olteanv@gmail.com>
References: <20210416234225.3715819-1-olteanv@gmail.com>
Message-ID: <fa2347b25d25e71f891e50f6f789e421@walle.cc>

Hi Vladimir,

Am 2021-04-17 01:42, schrieb Vladimir Oltean:
> From: Vladimir Oltean <vladimir.oltean at nxp.com>
> 
> This patch series contains logic for enabling the lossless mode on the
> RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> memory.
> 
> During testing it was found that, with the default FIFO configuration,
> a sender which isn't persuaded by our PAUSE frames and keeps sending
> will cause some MAC RX frame errors. To mitigate this, we need to 
> ensure
> that the FIFO never runs completely full, so we need to fix up a 
> setting
> that was supposed to be configured well out of reset. Unfortunately 
> this
> requires the addition of a new mini-driver.

What happens if the mini driver is not enabled? Then the fixes aren't
applied and bad things happen (now with the addition of flow control),
right?

I'm asking because, if you have the arm64 defconfig its not enabled.

shouldn't it be something like:

diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig 
b/drivers/net/ethernet/freescale/enetc/Kconfig
index d88f60c2bb82..cdc0ff89388a 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -2,7 +2,7 @@
  config FSL_ENETC
         tristate "ENETC PF driver"
         depends on PCI && PCI_MSI
-       depends on FSL_ENETC_IERB || FSL_ENETC_IERB=n
+       select FSL_ENETC_IERB
         select FSL_ENETC_MDIO
         select PHYLINK
         select PCS_LYNX

-michael


From rppt at linux.ibm.com  Tue Apr 20 14:27:56 2021
From: rppt at linux.ibm.com (Mike Rapoport)
Date: Tue, 20 Apr 2021 16:27:56 +0300
Subject: [PATCH v2 1/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <95b7fa81-f72e-c63f-0456-4c25dee8a5eb@redhat.com>
References: <20210420131611.8259-1-rppt@kernel.org>
 <20210420131611.8259-2-rppt@kernel.org>
 <95b7fa81-f72e-c63f-0456-4c25dee8a5eb@redhat.com>
Message-ID: <YH7W3MBR+XdyxlA7@linux.ibm.com>

On Tue, Apr 20, 2021 at 03:19:56PM +0200, David Hildenbrand wrote:
> On 20.04.21 15:16, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The check in gup_pte_range() whether a page belongs to a secretmem mapping
> > is performed before grabbing the page reference.
> > 
> > To avoid potential race move the check after try_grab_compound_head().
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   mm/gup.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/mm/gup.c b/mm/gup.c
> > index c3a17b189064..4b58c016e949 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -2080,13 +2080,13 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
> >   		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
> >   		page = pte_page(pte);
> > -		if (page_is_secretmem(page))
> > -			goto pte_unmap;
> > -
> >   		head = try_grab_compound_head(page, 1, flags);
> >   		if (!head)
> >   			goto pte_unmap;
> > +		if (page_is_secretmem(page))
> > +			goto pte_unmap;
> > +
> 
> Looking at the hunk below, I wonder if you're missing a put_compound_head().

Hmm, yes.
 
> (also, I'd do if unlikely(page_is_secretmem()) but that's a different
> discussion)

I don't mind, actually. I don't think there would be massive secretmem
usage soon.

> >   		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
> >   			put_compound_head(head, 1, flags);
> >   			goto pte_unmap;
> > 
> 
> 
> -- 
> Thanks,
> 
> David / dhildenb
> 

-- 
Sincerely yours,
Mike.


From maz at kernel.org  Tue Apr 20 14:31:05 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 14:31:05 +0100
Subject: [PATCH v2 1/3] KVM: arm64: Add a stage2 page fault counter for
 kvm_stat
In-Reply-To: <20210420130825.15585-2-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
 <20210420130825.15585-2-yoan.picchi@arm.com>
Message-ID: <877dkxqe06.wl-maz@kernel.org>

On Tue, 20 Apr 2021 14:08:23 +0100,
Yoan Picchi <yoan.picchi at arm.com> wrote:
> 
> This counter is meant to detect stage 2 page fault exits. This is meant to
> measure how much those page fault influence the performance (by comparing
> this number of exits to some other exit causes).
> For now this counter is generic, but some more granularity is planned in
> the next commits so that one know how much of the page fault are for memory
> allocation, or for mmio for instance. The idea being that one using this
> counter can get a better idea of what is trigerring those exits to try to
> fix it.
> 
> Signed-off-by: Yoan Picchi <yoan.picchi at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h | 1 +
>  arch/arm64/kvm/guest.c            | 1 +
>  arch/arm64/kvm/mmu.c              | 2 ++
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 3d10e6527..02891ce94 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -561,6 +561,7 @@ struct kvm_vcpu_stat {
>  	u64 wfi_exit_stat;
>  	u64 mmio_exit_user;
>  	u64 mmio_exit_kernel;
> +	u64 stage2_abort_exit;
>  	u64 exits;
>  };
>  
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 9bbd30e62..82a4b6275 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -38,6 +38,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>  	VCPU_STAT("wfi_exit_stat", wfi_exit_stat),
>  	VCPU_STAT("mmio_exit_user", mmio_exit_user),
>  	VCPU_STAT("mmio_exit_kernel", mmio_exit_kernel),
> +	VCPU_STAT("stage2_abort_exit", stage2_abort_exit),
>  	VCPU_STAT("exits", exits),
>  	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
>  	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 77cb2d28f..c3527ccf6 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -966,6 +966,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>  	fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
>  	is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
>  
> +

Please proofread your patches, and don't add spurious blank lines.

>  	/* Synchronous External Abort? */
>  	if (kvm_vcpu_abt_issea(vcpu)) {
>  		/*
> @@ -980,6 +981,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>  
>  	trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
>  			      kvm_vcpu_get_hfar(vcpu), fault_ipa);
> +	vcpu->stat.stage2_abort_exit++;

What is the benefit of this counter over, say, the tracepoint that is
already in place? This tracepoint allows you to count these exits, and
to actually find *why* you are exiting.

If the purpose of this patch is to identify exit reasons, I'd say that
the tracepoint is vastly superior in that respect.

	M.

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


From lkp at intel.com  Tue Apr 20 14:32:29 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 21:32:29 +0800
Subject: [PATCH v3 04/10] iommu/dma: Add a helper function to reserve
 RMRs for IOMMU drivers
In-Reply-To: <20210420082751.1829-5-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-5-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104202144.kAXc2ZHR-lkp@intel.com>

Hi Shameer,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pm/linux-next]
[also build test WARNING on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm-randconfig-r023-20210420 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project ca8eef7e3da8f750d7c7aa004fe426d1d34787ea)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/2501962e423895e2e4f126ff5998b226f4803186
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout 2501962e423895e2e4f126ff5998b226f4803186
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/iommu/arm/arm-smmu/arm-smmu.c:24:
>> include/linux/dma-iommu.h:94:71: warning: declaration of 'struct iommu_rmr' will not be visible outside of this function [-Wvisibility]
   static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
                                                                         ^
   include/linux/dma-iommu.h:100:1: error: expected identifier or '('
   {
   ^
   1 warning and 1 error generated.


vim +94 include/linux/dma-iommu.h

    93	
  > 94	static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
    95						   struct list_head *list)
    96	{
    97	}
    98	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25176 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/bac42ba1/attachment-0001.gz>

From hsinyi at chromium.org  Tue Apr 20 14:33:25 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 20 Apr 2021 21:33:25 +0800
Subject: [PATCH v19 4/6] misc: eeprom: at24: check suspend status before
 disable regulator
In-Reply-To: <CAMpxmJUGxUPYC9NEnJDHYq7Nu=akP5GTpU0ts9htf1vELhK15Q@mail.gmail.com>
References: <20210414172916.2689361-1-hsinyi@chromium.org>
 <20210414172916.2689361-5-hsinyi@chromium.org>
 <CAMpxmJUGxUPYC9NEnJDHYq7Nu=akP5GTpU0ts9htf1vELhK15Q@mail.gmail.com>
Message-ID: <CAJMQK-huKTYepZ+xCZDG01RBGB5Tu4ic=Hs03=remLii0WBTaQ@mail.gmail.com>

On Fri, Apr 16, 2021 at 10:09 PM Bartosz Golaszewski
<bgolaszewski at baylibre.com> wrote:
>
> On Wed, Apr 14, 2021 at 7:29 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> >
> > cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
> > regulator in runtime suspend. If runtime suspend is called before
> > regulator disable, it will results in regulator unbalanced disabling.
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
>
> Please add the Fixes tag.
>

Hi,

I resend the patch with the fix tag separately since other patches in
this series are not changed.

https://patchwork.ozlabs.org/project/linux-i2c/patch/20210420133050.377209-1-hsinyi at chromium.org/

Thanks

> > ---
> >  drivers/misc/eeprom/at24.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> > index 926408b41270..7a6f01ace78a 100644
> > --- a/drivers/misc/eeprom/at24.c
> > +++ b/drivers/misc/eeprom/at24.c
> > @@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client *client)
> >         at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
> >         if (IS_ERR(at24->nvmem)) {
> >                 pm_runtime_disable(dev);
> > -               regulator_disable(at24->vcc_reg);
> > +               if (!pm_runtime_status_suspended(dev))
> > +                       regulator_disable(at24->vcc_reg);
> >                 return PTR_ERR(at24->nvmem);
> >         }
> >
> > @@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client *client)
> >         err = at24_read(at24, 0, &test_byte, 1);
> >         if (err) {
> >                 pm_runtime_disable(dev);
> > -               regulator_disable(at24->vcc_reg);
> > +               if (!pm_runtime_status_suspended(dev))
> > +                       regulator_disable(at24->vcc_reg);
> >                 return -ENODEV;
> >         }
> >
> > --
> > 2.31.1.295.g9ea45b61b8-goog
> >
>
> Acked-by: Bartosz Golaszewski <bgolaszewski at baylibre.com>


From navam at xilinx.com  Tue Apr 20 14:36:51 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:36:51 +0000
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <YH6U/L4SEtJajusW@kroah.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-3-nava.manne@xilinx.com> <YH6U/L4SEtJajusW@kroah.com>
Message-ID: <MWHPR02MB2623DED0785A05A9C55C20FBC2489@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Greg,

	Please find my response inline.

> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Tuesday, April 20, 2021 2:17 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 2/5] misc: zynq: Add afi config driver
> 
> On Tue, Apr 20, 2021 at 01:41:50PM +0530, Nava kishore Manne wrote:
> > This patch adds zynq afi config driver. This is useful for the
> > configuration of the PS-PL interface on zynq platform.
> 
> What is "PS-PL"?  Can you describe it better please?
> 
PS-PL interface is nothing but the interface between processing system(PS)  that contains arm cores and Programmable Logic(PL) i.e FPGA.
Will update the description in v2.

> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  drivers/misc/Kconfig    | 11 ++++++
> >  drivers/misc/Makefile   |  1 +
> >  drivers/misc/zynq-afi.c | 81
> > +++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 93 insertions(+)
> >  create mode 100644 drivers/misc/zynq-afi.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > f532c59bb59b..877b43b3377d 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -445,6 +445,17 @@ config HISI_HIKEY_USB
> >  	  switching between the dual-role USB-C port and the USB-A host
> ports
> >  	  using only one USB controller.
> >
> > +config ZYNQ_AFI
> > +	tristate "Xilinx ZYNQ AFI support"
> > +	help
> > +	  Zynq AFI driver support for writing to the AFI registers
> > +	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
> > +	  the PS to the programmable logic (PL) through the AXI port.
> > +	  This AXI port helps to establish the data path between the
> > +	  PS and PL.In-order to establish the proper communication path
> > +	  between PS and PL, the AXI port data path should be configured
> > +	  with the proper Bus-width values
> > +
> >  source "drivers/misc/c2port/Kconfig"
> >  source "drivers/misc/eeprom/Kconfig"
> >  source "drivers/misc/cb710/Kconfig"
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > 99b6f15a3c70..e9b03843100f 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI)		+=
> habanalabs/
> >  obj-$(CONFIG_UACCE)		+= uacce/
> >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> > +obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > diff --git a/drivers/misc/zynq-afi.c b/drivers/misc/zynq-afi.c new
> > file mode 100644 index 000000000000..04317d1bdb98
> > --- /dev/null
> > +++ b/drivers/misc/zynq-afi.c
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx ZYNQ AFI driver.
> > + * Copyright (c) 2018-2021 Xilinx Inc.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +
> > +/* Registers and special values for doing register-based operations */
> > +#define AFI_RDCHAN_CTRL_OFFSET	0x00
> > +#define AFI_WRCHAN_CTRL_OFFSET	0x14
> > +
> > +#define AFI_BUSWIDTH_MASK	0x01
> > +
> > +/**
> > + * struct afi_fpga - AFI register description
> > + * @membase:	pointer to register struct
> > + * @afi_width:	AFI bus width to be written
> > + */
> > +struct zynq_afi_fpga {
> > +	void __iomem	*membase;
> > +	u32		afi_width;
> > +};
> > +
> > +static int zynq_afi_fpga_probe(struct platform_device *pdev) {
> > +	struct zynq_afi_fpga *afi_fpga;
> > +	struct resource *res;
> > +	u32 reg_val;
> > +	u32 val;
> > +
> > +	afi_fpga = devm_kzalloc(&pdev->dev, sizeof(*afi_fpga),
> GFP_KERNEL);
> > +	if (!afi_fpga)
> > +		return -ENOMEM;
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	afi_fpga->membase = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(afi_fpga->membase))
> > +		return PTR_ERR(afi_fpga->membase);
> > +
> > +	val = device_property_read_u32(&pdev->dev, "xlnx,afi-width",
> > +				       &afi_fpga->afi_width);
> > +	if (val) {
> > +		dev_err(&pdev->dev, "failed to get the afi bus width\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	reg_val = readl(afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > +	writel(reg_val | afi_fpga->afi_width,
> > +	       afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > +	reg_val = readl(afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > +	writel(reg_val | afi_fpga->afi_width,
> > +	       afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > +
> > +	return 0;
> > +}
> 
> I do not understand, why is this driver needed at all?  Why can't you do the
> above from userspace?
> 
> All this does is write some values to the hardware at probe time, who needs
> this?

This driver will be used by the overlay framework for configuring the interface after programming the FPGA and before probing the drivers that are present in the PL.

Regards,
Navakishore.


From navam at xilinx.com  Tue Apr 20 14:45:08 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:45:08 +0000
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <YH6VPt6qfxdFhFEB@kroah.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com> <YH6VPt6qfxdFhFEB@kroah.com>
Message-ID: <MWHPR02MB2623C9BAFBA0CB47449E8724C2489@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Greg,

	Please find my response inline.

> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Tuesday, April 20, 2021 2:18 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 5/5] misc: zynqmp: Add afi config driver
> 
> On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> > This patch adds zynqmp afi config driver.This is useful for the
> > configuration of the PS-PL interface on Zynq US+ MPSoC platform.
> 
> Again, please spell out what those terms mean, as I have no idea :(
> 

Will fix in v2

> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  drivers/misc/Kconfig      | 11 ++++++
> >  drivers/misc/Makefile     |  1 +
> >  drivers/misc/zynqmp-afi.c | 83
> > +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 95 insertions(+)
> >  create mode 100644 drivers/misc/zynqmp-afi.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > 877b43b3377d..d1ea1eeb3ac1 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -456,6 +456,17 @@ config ZYNQ_AFI
> >  	  between PS and PL, the AXI port data path should be configured
> >  	  with the proper Bus-width values
> >
> > +config ZYNQMP_AFI
> > +        tristate "Xilinx ZYNQMP AFI support"
> > +        help
> > +	  ZynqMP AFI driver support for writing to the AFI registers for
> > +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> > +	  PS to the programmable logic (PL) through the AXI port. This AXI
> > +	  port helps to establish the data path between the PS and PL.
> > +	  In-order to establish the proper communication path between
> > +	  PS and PL, the AXI port data path should be configured with
> > +	  the proper Bus-width values
> 
> Please use tabs properly, you mix them above, checkpatch should have
> caught that.
> 
Yes, Ideally check patch should report this issue but it's failed to report.
Will fix this issue in v2.

Regards,
Navakishore.


From navam at xilinx.com  Tue Apr 20 14:47:17 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Tue, 20 Apr 2021 13:47:17 +0000
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <YH6V9Im3L/gJJ/CP@kroah.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com> <YH6V9Im3L/gJJ/CP@kroah.com>
Message-ID: <MWHPR02MB26233345F140ACA18E55BC15C2489@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Greg,

	Please find my response inline.

> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Tuesday, April 20, 2021 2:21 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 5/5] misc: zynqmp: Add afi config driver
> 
> On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> > This patch adds zynqmp afi config driver.This is useful for the
> > configuration of the PS-PL interface on Zynq US+ MPSoC platform.
> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  drivers/misc/Kconfig      | 11 ++++++
> >  drivers/misc/Makefile     |  1 +
> >  drivers/misc/zynqmp-afi.c | 83
> > +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 95 insertions(+)
> >  create mode 100644 drivers/misc/zynqmp-afi.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > 877b43b3377d..d1ea1eeb3ac1 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -456,6 +456,17 @@ config ZYNQ_AFI
> >  	  between PS and PL, the AXI port data path should be configured
> >  	  with the proper Bus-width values
> >
> > +config ZYNQMP_AFI
> > +        tristate "Xilinx ZYNQMP AFI support"
> > +        help
> > +	  ZynqMP AFI driver support for writing to the AFI registers for
> > +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> > +	  PS to the programmable logic (PL) through the AXI port. This AXI
> > +	  port helps to establish the data path between the PS and PL.
> > +	  In-order to establish the proper communication path between
> > +	  PS and PL, the AXI port data path should be configured with
> > +	  the proper Bus-width values
> > +
> >  source "drivers/misc/c2port/Kconfig"
> >  source "drivers/misc/eeprom/Kconfig"
> >  source "drivers/misc/cb710/Kconfig"
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > e9b03843100f..54bd0edc511e 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -57,3 +57,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
> >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> >  obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > +obj-$(CONFIG_ZYNQMP_AFI)	+= zynqmp-afi.o
> > diff --git a/drivers/misc/zynqmp-afi.c b/drivers/misc/zynqmp-afi.c new
> > file mode 100644 index 000000000000..a318652576d2
> > --- /dev/null
> > +++ b/drivers/misc/zynqmp-afi.c
> > @@ -0,0 +1,83 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx FPGA AFI bridge.
> > + * Copyright (c) 2018-2021 Xilinx Inc.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/firmware/xlnx-zynqmp.h> #include <linux/io.h>
> > +#include <linux/module.h> #include <linux/of.h> #include
> > +<linux/platform_device.h> #include <linux/slab.h>
> > +
> > +/**
> > + * struct zynqmp_afi_fpga - AFI register description
> > + * @value: value to be written to the register
> > + * @regid: Register id for the register to be written
> > + */
> > +struct zynqmp_afi_fpga {
> > +	u32 value;
> > +	u32 regid;
> > +};
> > +
> > +static int zynqmp_afi_fpga_probe(struct platform_device *pdev)
> > +{
> > +	struct zynqmp_afi_fpga *zynqmp_afi_fpga;
> > +	struct device_node *np = pdev->dev.of_node;
> > +	int i, entries, ret;
> > +	u32 reg, val;
> > +
> > +	zynqmp_afi_fpga = devm_kzalloc(&pdev->dev,
> > +				       sizeof(*zynqmp_afi_fpga), GFP_KERNEL);
> > +	if (!zynqmp_afi_fpga)
> > +		return -ENOMEM;
> > +	platform_set_drvdata(pdev, zynqmp_afi_fpga);
> > +
> > +	entries = of_property_count_u32_elems(np, "config-afi");
> > +	if (!entries || (entries % 2)) {
> > +		dev_err(&pdev->dev, "Invalid number of registers\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	for (i = 0; i < entries / 2; i++) {
> > +		ret = of_property_read_u32_index(np, "config-afi", i * 2,
> &reg);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "failed to read register\n");
> > +			return -EINVAL;
> > +		}
> > +		ret = of_property_read_u32_index(np, "config-afi", i * 2 + 1,
> > +						 &val);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "failed to read value\n");
> > +			return -EINVAL;
> > +		}
> > +		ret = zynqmp_pm_afi(reg, val);
> > +		if (ret < 0) {
> > +			dev_err(&pdev->dev, "AFI register write error %d\n",
> > +				ret);
> > +			return ret;
> > +		}
> > +	}
> > +	return 0;
> > +}
> 
> Again, why does this have to be in the kernel?  All it does is make a
> single call to the hardware based on some values read from the device
> tree.  Can't you do this from userspace?
> 
For every PL design has its own PS-PL configuration.
This driver will be used by the overlay framework for configuring the interface after programming the FPGA and before probing the drivers that are present in the PL.

Regards,
Navakishore.


From yibin.gong at nxp.com  Tue Apr 20 14:47:25 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Tue, 20 Apr 2021 13:47:25 +0000
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
Message-ID: <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>

On 2021/04/19 17:46 Lucas Stach <l.stach at pengutronix.de> wrote:
> Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> > Hi Lucas,
> >
> > On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > Hi Robin,
> > >
> > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > > > > Hi
> > > > > >
> > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > > <l.stach at pengutronix.de>
> > > > > wrote:
> > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > > > > > There are two requirements that we need to move the
> > > > > > > > request of dma channel from probe to open.
> > > > > > >
> > > > > > > How do you handle -EPROBE_DEFER return code from the channel
> > > > > > > request if you don't do it in probe?
> > > > > >
> > > > > > I use the dma_request_slave_channel or dma_request_channel
> > > > > > instead of dmaengine_pcm_request_chan_of. so there should be
> > > > > > not -EPROBE_DEFER return code.
> > > > >
> > > > > This is a pretty weak argument. The dmaengine device might probe
> > > > > after you try to get the channel. Using a function to request
> > > > > the channel that doesn't allow you to handle probe deferral is
> > > > > IMHO a bug and should be fixed, instead of building even more
> > > > > assumptions on top
> > > of it.
> > > > >
> > > > > > > > - When dma device binds with power-domains, the power will
> > > > > > > > be enabled when we request dma channel. If the request of
> > > > > > > > dma channel happen on probe, then the power-domains will
> > > > > > > > be always enabled after kernel boot up,  which is not good
> > > > > > > > for power saving,  so we need to move the request of dma
> > > > > > > > channel to .open();
> > > > > > >
> > > > > > > This is certainly something which could be fixed in the
> > > > > > > dmaengine driver.
> > > > > >
> > > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > > device_alloc_chan_resources, the device_alloc_chan_resources
> > > > > > is called when channel is requested. so power is enabled on
> > > > > > channel
> > > request.
> > > > >
> > > > > So why can't you fix the dmaengine driver to do that RPM call at
> > > > > a later time when the channel is actually going to be used? This
> > > > > will allow further power savings with other slave devices than the audio
> PCM.
> > > > Hi Lucas,
> > > > ??Thanks for your suggestion. I have tried to implement runtime
> > > > autosuspend in fsl-edma driver on i.mx8qm/qxp with delay time (2
> > > > sec) for this feature as below (or you can refer to
> > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > > pm_runtime_put_autosuspend in all dmaengine driver interface like
> > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_c
> > > > ycli
> > > > c/
> > > > device_tx_status...
> > > >
> > > >
> > > > ????????????????pm_runtime_use_autosuspend(fsl_chan->dev);
> > > > ????????????????pm_runtime_set_autosuspend_delay(fsl_chan->
> dev,
> > > 2000);
> > > >
> > > > That could resolve this audio case since the autosuspend could
> > > > suspend runtime after
> > > > 2 seconds if there is no further dma transfer but only channel
> > > request(device_alloc_chan_resources).
> > > > But unfortunately, it cause another issue. As you know, on our
> > > > i.mx8qm/qxp, power domain done by scfw
> > > > (drivers/firmware/imx/scu-pd.c)
> > > over mailbox:
> > > > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > > > imx_scu_ipc_write()->mbox_send_message()
> > > > which means have to 'waits for completion', meanwhile, some driver
> > > > like tty will call dmaengine interfaces in non-atomic case as
> > > > below,
> > > >
> > > > static int uart_write(struct tty_struct *tty, const unsigned char
> > > > *buf, int count) {
> > > > ???.......
> > > > 	    port = uart_port_lock(state, flags);
> > > > ???......
> > > > ????????__uart_start(tty);  //call
> start_tx()->dmaengine_prep_slave_sg...
> > > > ????????uart_port_unlock(port, flags);
> > > > ????????return ret;
> > > > }
> > > >
> > > > Thus dma runtime resume may happen in that timing window and cause
> > > kernel alarm.
> > > > I'm not sure whether there are similar limitations on other driver
> > > > subsystem. But for me, It looks like the only way to resolve the
> > > > contradiction between tty and scu-pd (hardware limitation on
> > > > i.mx8qm/qxp) is to give up autosuspend and keep
> > > > pm_runtime_get_sync
> > > only in device_alloc_chan_resources because request channel is a
> > > safe non-atomic phase.
> > > > Do you have any idea? Thanks in advance.
> > >
> > > If you look closely at the driver you used as an example (hidma.c)
> > > it looks like there is already something in there, which looks very
> > > much like what you need
> > > here:
> > >
> > > In hidma_issue_pending() the driver tries to get the device to runtime
> resume.
> > > If this doesn't work, maybe due to the power domain code not being
> > > able to be called in atomic context, the actual work of waking up
> > > the dma hardware and issuing the descriptor is shunted to a tasklet.
> > >
> > > If I'm reading this right, this is exactly what you need here to be
> > > able to call the dmaengine code from atomic context: try the rpm get
> > > and issue immediately when possible, otherwise shunt the work to a
> > > non- atomic context where you can deal with the requirements of scu-pd.
> > Yes, I can schedule_work to worker to runtime resume edma channel by
> calling scu-pd.
> > But that means all dmaengine interfaces should be taken care, not only
> > issue_pending() but also
> > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> > dmaengine_tx_status(). Not sure why hidma only take care
> > issue_pending. Maybe their user case is just for memcpy/memset so that
> > no further complicate case as ALSA or TTY.
> > Besides, for autosuspend in cyclic, we have to add pm_runtime_get_sync
> > into interrupt handler as qcom/bam_dma.c. but how could resolve the
> > scu-pd's non-atmoic limitation in interrupt handler?
> 
> Sure, this all needs some careful analysis on how those functions are called
> and what to do about atomic callers, but it should be doable. I don't see any
> fundamental issues here.
> 
> I don't see why you would ever need to wake the hardware in an interrupt
> handler. Surely the hardware is already awake, as it wouldn't signal an
> interrupt otherwise. And for the issue with scu-pd you only care about the
> state transition of suspended->running. If the hardware is already
> running/awake, the runtime pm state handling is nothing more than bumping
> a refcount, which is atomic safe. Putting the HW in suspend is already handled
> asynchronously in a worker, so this is also atomic safe.
But with autosuspend used, in corner case, may runtime suspended before falling 
Into edma interrupt handler if timeout happen with the delay value of
pm_runtime_set_autosuspend_delay(). Thus, can't touch any edma interrupt
status register unless runtime resume edma in interrupt handler while runtime
resume function based on scu-pd's power domain may block or sleep.
I have a simple workaround that disable runtime suspend in issue_pending worker
by calling pm_runtime_forbid() and then enable runtime auto suspend in 
dmaengine_terminate_all so that we could easily regard that edma channel is always
in runtime resume between issue_pending and channel terminated and ignore the above
interrupt handler/scu-pd limitation.




From nm at ti.com  Tue Apr 20 14:49:44 2021
From: nm at ti.com (Nishanth Menon)
Date: Tue, 20 Apr 2021 08:49:44 -0500
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to
 json schema
In-Reply-To: <CAHUa44GZenrwVWRZW6BKB8cktfXvktJ4OCF0AgPKanYGV01m5g@mail.gmail.com>
References: <20210416222518.15801-1-nm@ti.com>
 <CAHUa44GZenrwVWRZW6BKB8cktfXvktJ4OCF0AgPKanYGV01m5g@mail.gmail.com>
Message-ID: <20210420134944.g6isz36xonsclg5g@reburial>

On 10:32-20210420, Jens Wiklander wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> > new file mode 100644
> > index 000000000000..6513b5ac8b2c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> > @@ -0,0 +1,62 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> 
> Are these links supposed to work?

I have'nt seen any of them work.. and I think it was intentional. I am
guessing that someday, eventually it might, typically the path beyond
devicetree.org is either in [1] or [2].

[1] https://github.com/devicetree-org/dt-schema
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings
[...]
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From maz at kernel.org  Tue Apr 20 14:52:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 14:52:07 +0100
Subject: [PATCH v2 2/3] KVM: arm64: Add two page mapping counters for
 kvm_stat
In-Reply-To: <20210420130825.15585-3-yoan.picchi@arm.com>
References: <20210420130825.15585-1-yoan.picchi@arm.com>
 <20210420130825.15585-3-yoan.picchi@arm.com>
Message-ID: <875z0hqd14.wl-maz@kernel.org>

On Tue, 20 Apr 2021 14:08:24 +0100,
Yoan Picchi <yoan.picchi at arm.com> wrote:
> 
> This patch adds regular_page_mapped and huge_page_mapped.
> regular_page_mapped is increased when a page of the smallest granularity
> is mapped. This is usually a 4k, 16k or 64k page.
> huge_page_mapped is increased when a huge page of any size other than the
> smallest granularity is mapped.
> Those counters only count pages allocated for the data and doesn't count
> the pages/blocks allocated to the page tables as I don't see where those
> might be needed to be recorded
> 
> I can see two usecases for those counters :
> 	We can detect memory pressure in the host when the guest gets
> regular pages instead of huge ones.
> 	May help detecting an abnormal memory usage like some recurring
> allocs past the kernel and a few program starts.
> With the previous patch about stage2_abort_exit, it have the added
> benefit of specifying the second main cause of stage 2 page fault (the
> other being mmio access)
> 
> To test this patch I did start a guest VM and monitor the page allocation.
> By default it only allocate huge pages. Then I tried to disable the huge
> pages with : echo never > /sys/kernel/mm/transparent_hugepage/enabled
> Starting the VM, it no longer allocate any huge page, but only regular
> pages.
> 
> I can't log into the guess because it doesn't recognize my keyboard.

Maybe you should consider having a look at what is going wrong
here. If your guest isn't working correctly, trying to account for
page allocation is a bit... irrelevant.

> To
> circumvent that I added some command to the init script that need some
> memory : cat /dev/zero | head -c 1000m | tail
> This take 1GiB of memory before finishing.
> From memory, it allocate 525 or so huge table which is around what I would
> expect with 2MB pages.
> 
> I did check the relation between stage 2 exits, mmio exits and
> allocation. The mmio + allocation account for almost all the stage 2 exit
> as expected. There was only about 20 exits that was neither a mmio or an
> alloc during the kernel boot. I did not look what they are, but it can be
> a memory permission relaxation, or resizing a page.
> 
> My main concern here is about the case where we replace a page/block by
> another/resize a block. I don't fully understand the mechanism yet and
> so don't know if it should be counted as an allocation or not. For now I
> don't account it.

None of this discussion belongs to a commit message.

> 
> Signed-off-by: Yoan Picchi <yoan.picchi at arm.com>
> ---
>  arch/arm64/include/asm/kvm_host.h | 2 ++
>  arch/arm64/kvm/guest.c            | 2 ++
>  arch/arm64/kvm/hyp/pgtable.c      | 5 +++++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 02891ce94..8f9d27571 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -547,6 +547,8 @@ static inline bool __vcpu_write_sys_reg_to_cpu(u64 val, int reg)
>  
>  struct kvm_vm_stat {
>  	ulong remote_tlb_flush;
> +	ulong regular_page_mapped;
> +	ulong huge_page_mapped;
>  };
>  
>  struct kvm_vcpu_stat {
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index 82a4b6275..41316b30e 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -42,6 +42,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>  	VCPU_STAT("exits", exits),
>  	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
>  	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
> +	VM_STAT("regular_page_mapped", regular_page_mapped),
> +	VM_STAT("huge_page_mapped", huge_page_mapped),

As pointed out in the previous review, two sizes don't quite fit
all. There is a continuum of page, contiguous pages and block mappings
of various sizes (although KVM doesn't support the contiguous hint at
S2 yet).

For this information to be useful, you'd have to at least distinguish
between 2M and 1G mappings when operating with a 4k base granule
size. Because if I have enough memory to get contiguous 1G chunks, I
surely don't want them to show up as 2M mappings because I messed up
the userspace alignment requirements, and this counter can't
distinguish between these cases.

Thanks,

	M.

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


From david at redhat.com  Tue Apr 20 14:56:28 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 15:56:28 +0200
Subject: [PATCH v1 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210420090925.7457-3-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-3-rppt@kernel.org>
Message-ID: <ed8f10a0-9b68-1d12-0305-90fd378af6b9@redhat.com>

On 20.04.21 11:09, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().

Just a general question while thinking about it:

Would we right now initialize the memmap of these pages already via 
memmap_init_zone()->memmap_init_range()? (IOW, not marking the 
PageReserved?)

-- 
Thanks,

David / dhildenb



From robh at kernel.org  Tue Apr 20 14:58:41 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 08:58:41 -0500
Subject: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
 driver
In-Reply-To: <20210420081153.17020-5-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-5-nava.manne@xilinx.com>
Message-ID: <1618927121.480164.3235334.nullmailer@robh.at.kernel.org>

On Tue, 20 Apr 2021 13:41:52 +0530, Nava kishore Manne wrote:
> This patch adds the binding document for the zynqmp afi
> config driver.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
>  1 file changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.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/misc/xlnx,zynqmp-afi-fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware: failed to match any schema with compatible: ['xlnx,zynqmp-firmware']
Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware/afi: failed to match any schema with compatible: ['xlnx,afi-fpga']

See https://patchwork.ozlabs.org/patch/1468230

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From l.stach at pengutronix.de  Tue Apr 20 15:00:56 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Tue, 20 Apr 2021 16:00:56 +0200
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
 <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
Message-ID: <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>

Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong:
> On 2021/04/19 17:46 Lucas Stach <l.stach at pengutronix.de> wrote:
> > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> > > Hi Lucas,
> > > 
> > > On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > Hi Robin,
> > > > 
> > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > > > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> > > > > > > Hi
> > > > > > > 
> > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > > > <l.stach at pengutronix.de>
> > > > > > wrote:
> > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > > > > > > > There are two requirements that we need to move the
> > > > > > > > > request of dma channel from probe to open.
> > > > > > > > 
> > > > > > > > How do you handle -EPROBE_DEFER return code from the channel
> > > > > > > > request if you don't do it in probe?
> > > > > > > 
> > > > > > > I use the dma_request_slave_channel or dma_request_channel
> > > > > > > instead of dmaengine_pcm_request_chan_of. so there should be
> > > > > > > not -EPROBE_DEFER return code.
> > > > > > 
> > > > > > This is a pretty weak argument. The dmaengine device might probe
> > > > > > after you try to get the channel. Using a function to request
> > > > > > the channel that doesn't allow you to handle probe deferral is
> > > > > > IMHO a bug and should be fixed, instead of building even more
> > > > > > assumptions on top
> > > > of it.
> > > > > > 
> > > > > > > > > - When dma device binds with power-domains, the power will
> > > > > > > > > be enabled when we request dma channel. If the request of
> > > > > > > > > dma channel happen on probe, then the power-domains will
> > > > > > > > > be always enabled after kernel boot up,  which is not good
> > > > > > > > > for power saving,  so we need to move the request of dma
> > > > > > > > > channel to .open();
> > > > > > > > 
> > > > > > > > This is certainly something which could be fixed in the
> > > > > > > > dmaengine driver.
> > > > > > > 
> > > > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > > > device_alloc_chan_resources, the device_alloc_chan_resources
> > > > > > > is called when channel is requested. so power is enabled on
> > > > > > > channel
> > > > request.
> > > > > > 
> > > > > > So why can't you fix the dmaengine driver to do that RPM call at
> > > > > > a later time when the channel is actually going to be used? This
> > > > > > will allow further power savings with other slave devices than the audio
> > PCM.
> > > > > Hi Lucas,
> > > > > ??Thanks for your suggestion. I have tried to implement runtime
> > > > > autosuspend in fsl-edma driver on i.mx8qm/qxp with delay time (2
> > > > > sec) for this feature as below (or you can refer to
> > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > > > pm_runtime_put_autosuspend in all dmaengine driver interface like
> > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_dma_c
> > > > > ycli
> > > > > c/
> > > > > device_tx_status...
> > > > > 
> > > > > 
> > > > > ????????????????pm_runtime_use_autosuspend(fsl_chan->dev);
> > > > > ????????????????pm_runtime_set_autosuspend_delay(fsl_chan->
> > dev,
> > > > 2000);
> > > > > 
> > > > > That could resolve this audio case since the autosuspend could
> > > > > suspend runtime after
> > > > > 2 seconds if there is no further dma transfer but only channel
> > > > request(device_alloc_chan_resources).
> > > > > But unfortunately, it cause another issue. As you know, on our
> > > > > i.mx8qm/qxp, power domain done by scfw
> > > > > (drivers/firmware/imx/scu-pd.c)
> > > > over mailbox:
> > > > > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > > > > imx_scu_ipc_write()->mbox_send_message()
> > > > > which means have to 'waits for completion', meanwhile, some driver
> > > > > like tty will call dmaengine interfaces in non-atomic case as
> > > > > below,
> > > > > 
> > > > > static int uart_write(struct tty_struct *tty, const unsigned char
> > > > > *buf, int count) {
> > > > > ???.......
> > > > > 	    port = uart_port_lock(state, flags);
> > > > > ???......
> > > > > ????????__uart_start(tty);  //call
> > start_tx()->dmaengine_prep_slave_sg...
> > > > > ????????uart_port_unlock(port, flags);
> > > > > ????????return ret;
> > > > > }
> > > > > 
> > > > > Thus dma runtime resume may happen in that timing window and cause
> > > > kernel alarm.
> > > > > I'm not sure whether there are similar limitations on other driver
> > > > > subsystem. But for me, It looks like the only way to resolve the
> > > > > contradiction between tty and scu-pd (hardware limitation on
> > > > > i.mx8qm/qxp) is to give up autosuspend and keep
> > > > > pm_runtime_get_sync
> > > > only in device_alloc_chan_resources because request channel is a
> > > > safe non-atomic phase.
> > > > > Do you have any idea? Thanks in advance.
> > > > 
> > > > If you look closely at the driver you used as an example (hidma.c)
> > > > it looks like there is already something in there, which looks very
> > > > much like what you need
> > > > here:
> > > > 
> > > > In hidma_issue_pending() the driver tries to get the device to runtime
> > resume.
> > > > If this doesn't work, maybe due to the power domain code not being
> > > > able to be called in atomic context, the actual work of waking up
> > > > the dma hardware and issuing the descriptor is shunted to a tasklet.
> > > > 
> > > > If I'm reading this right, this is exactly what you need here to be
> > > > able to call the dmaengine code from atomic context: try the rpm get
> > > > and issue immediately when possible, otherwise shunt the work to a
> > > > non- atomic context where you can deal with the requirements of scu-pd.
> > > Yes, I can schedule_work to worker to runtime resume edma channel by
> > calling scu-pd.
> > > But that means all dmaengine interfaces should be taken care, not only
> > > issue_pending() but also
> > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> > > dmaengine_tx_status(). Not sure why hidma only take care
> > > issue_pending. Maybe their user case is just for memcpy/memset so that
> > > no further complicate case as ALSA or TTY.
> > > Besides, for autosuspend in cyclic, we have to add pm_runtime_get_sync
> > > into interrupt handler as qcom/bam_dma.c. but how could resolve the
> > > scu-pd's non-atmoic limitation in interrupt handler?
> > 
> > Sure, this all needs some careful analysis on how those functions are called
> > and what to do about atomic callers, but it should be doable. I don't see any
> > fundamental issues here.
> > 
> > I don't see why you would ever need to wake the hardware in an interrupt
> > handler. Surely the hardware is already awake, as it wouldn't signal an
> > interrupt otherwise. And for the issue with scu-pd you only care about the
> > state transition of suspended->running. If the hardware is already
> > running/awake, the runtime pm state handling is nothing more than bumping
> > a refcount, which is atomic safe. Putting the HW in suspend is already handled
> > asynchronously in a worker, so this is also atomic safe.
> But with autosuspend used, in corner case, may runtime suspended before falling 
> Into edma interrupt handler if timeout happen with the delay value of
> pm_runtime_set_autosuspend_delay(). Thus, can't touch any edma interrupt
> status register unless runtime resume edma in interrupt handler while runtime
> resume function based on scu-pd's power domain may block or sleep.
> I have a simple workaround that disable runtime suspend in issue_pending worker
> by calling pm_runtime_forbid() and then enable runtime auto suspend in 
> dmaengine_terminate_all so that we could easily regard that edma channel is always
> in runtime resume between issue_pending and channel terminated and ignore the above
> interrupt handler/scu-pd limitation.

The IRQ handler is the point where you are informed by the hardware
that a specific operation is complete. I don't see any use-case where
it would be valid to drop the rpm refcount to 0 before the IRQ is
handled. Surely the hardware needs to stay awake until the currently
queued operations are complete and if the IRQ handler is the completion
point the IRQ handler is the first point in time where your autosuspend
timer should start to run. There should never be a situation where the
timer expiry can get between IRQ signaling and the handler code
running.

Regards,
Lucas



From olteanv at gmail.com  Tue Apr 20 15:04:33 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 20 Apr 2021 17:04:33 +0300
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <fa2347b25d25e71f891e50f6f789e421@walle.cc>
References: <20210416234225.3715819-1-olteanv@gmail.com>
 <fa2347b25d25e71f891e50f6f789e421@walle.cc>
Message-ID: <20210420140433.hajuvfiz4humhhkt@skbuf>

Hi Michael,

On Tue, Apr 20, 2021 at 03:27:24PM +0200, Michael Walle wrote:
> Hi Vladimir,
> 
> Am 2021-04-17 01:42, schrieb Vladimir Oltean:
> > From: Vladimir Oltean <vladimir.oltean at nxp.com>
> > 
> > This patch series contains logic for enabling the lossless mode on the
> > RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> > memory.
> > 
> > During testing it was found that, with the default FIFO configuration,
> > a sender which isn't persuaded by our PAUSE frames and keeps sending
> > will cause some MAC RX frame errors. To mitigate this, we need to ensure
> > that the FIFO never runs completely full, so we need to fix up a setting
> > that was supposed to be configured well out of reset. Unfortunately this
> > requires the addition of a new mini-driver.
> 
> What happens if the mini driver is not enabled? Then the fixes aren't
> applied and bad things happen (now with the addition of flow control),
> right?
> 
> I'm asking because, if you have the arm64 defconfig its not enabled.
> 
> shouldn't it be something like:
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
> b/drivers/net/ethernet/freescale/enetc/Kconfig
> index d88f60c2bb82..cdc0ff89388a 100644
> --- a/drivers/net/ethernet/freescale/enetc/Kconfig
> +++ b/drivers/net/ethernet/freescale/enetc/Kconfig
> @@ -2,7 +2,7 @@
>  config FSL_ENETC
>         tristate "ENETC PF driver"
>         depends on PCI && PCI_MSI
> -       depends on FSL_ENETC_IERB || FSL_ENETC_IERB=n
> +       select FSL_ENETC_IERB
>         select FSL_ENETC_MDIO
>         select PHYLINK
>         select PCS_LYNX

Yes, ideally the IERB driver and the ENETC PF driver should be built in
the same way, or the IERB driver can be built-in and the PF driver can
be module. I don't know how to express this using Kconfig, sorry.


From michael at walle.cc  Tue Apr 20 15:10:34 2021
From: michael at walle.cc (Michael Walle)
Date: Tue, 20 Apr 2021 16:10:34 +0200
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <20210420140433.hajuvfiz4humhhkt@skbuf>
References: <20210416234225.3715819-1-olteanv@gmail.com>
 <fa2347b25d25e71f891e50f6f789e421@walle.cc>
 <20210420140433.hajuvfiz4humhhkt@skbuf>
Message-ID: <0bf4aa61dea7be0723fda2d8597644ad@walle.cc>

Hi Vladimir,

Am 2021-04-20 16:04, schrieb Vladimir Oltean:
> On Tue, Apr 20, 2021 at 03:27:24PM +0200, Michael Walle wrote:
>> Hi Vladimir,
>> 
>> Am 2021-04-17 01:42, schrieb Vladimir Oltean:
>> > From: Vladimir Oltean <vladimir.oltean at nxp.com>
>> >
>> > This patch series contains logic for enabling the lossless mode on the
>> > RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
>> > memory.
>> >
>> > During testing it was found that, with the default FIFO configuration,
>> > a sender which isn't persuaded by our PAUSE frames and keeps sending
>> > will cause some MAC RX frame errors. To mitigate this, we need to ensure
>> > that the FIFO never runs completely full, so we need to fix up a setting
>> > that was supposed to be configured well out of reset. Unfortunately this
>> > requires the addition of a new mini-driver.
>> 
>> What happens if the mini driver is not enabled? Then the fixes aren't
>> applied and bad things happen (now with the addition of flow control),
>> right?
>> 
>> I'm asking because, if you have the arm64 defconfig its not enabled.
>> 
>> shouldn't it be something like:
>> 
>> diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
>> b/drivers/net/ethernet/freescale/enetc/Kconfig
>> index d88f60c2bb82..cdc0ff89388a 100644
>> --- a/drivers/net/ethernet/freescale/enetc/Kconfig
>> +++ b/drivers/net/ethernet/freescale/enetc/Kconfig
>> @@ -2,7 +2,7 @@
>>  config FSL_ENETC
>>         tristate "ENETC PF driver"
>>         depends on PCI && PCI_MSI
>> -       depends on FSL_ENETC_IERB || FSL_ENETC_IERB=n
>> +       select FSL_ENETC_IERB
>>         select FSL_ENETC_MDIO
>>         select PHYLINK
>>         select PCS_LYNX
> 
> Yes, ideally the IERB driver and the ENETC PF driver should be built in
> the same way, or the IERB driver can be built-in and the PF driver can
> be module. I don't know how to express this using Kconfig, sorry.

With the small patch above it is:
  FSL_ENETC=m -> FSL_ENETC_IERB = m or y
  FSL_ENETC=y -> FSL_ENETC_IERB = y
  FSL_ENETC=n -> FSL_ENETC_IERB = m,y or n

Will you fix it? Should I prepare a patch?

-michael


From robh at kernel.org  Tue Apr 20 15:15:04 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 09:15:04 -0500
Subject: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
 driver
In-Reply-To: <20210420081153.17020-5-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-5-nava.manne@xilinx.com>
Message-ID: <20210420141504.GA3250182@robh.at.kernel.org>

On Tue, Apr 20, 2021 at 01:41:52PM +0530, Nava kishore Manne wrote:
> This patch adds the binding document for the zynqmp afi
> config driver.

Bindings are for h/w blocks, not drivers.

> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
>  .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
>  1 file changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> 
> diff --git a/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> new file mode 100644
> index 000000000000..3ae22096b22a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/xlnx,zynqmp-afi-fpga.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx ZynqMP AFI interface Manager.
> +
> +maintainers:
> +  - Nava kishore Manne <nava.manne at xilinx.com>
> +
> +description: |
> +  The Zynq UltraScale+ MPSoC Processing System core provides access from PL
> +  masters to PS internal peripherals, and memory through AXI FIFO interface(AFI)
> +  interfaces.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - xlnx,zynqmp-afi-fpga
> +
> +  config-afi:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description: |
> +      Pairs of  <regid value >
> +      The possible values of regid and values are
> +      regid - Regids of the register to be written possible values

If we wanted sequences of register accesses in DT, we'd have a 
generic mechanism to do so.

> +        0- AFIFM0_RDCTRL
> +        1- AFIFM0_WRCTRL
> +        2- AFIFM1_RDCTRL
> +        3- AFIFM1_WRCTRL
> +        4- AFIFM2_RDCTRL
> +        5- AFIFM2_WRCTRL
> +        6- AFIFM3_RDCTRL
> +        7- AFIFM3_WRCTRL
> +        8- AFIFM4_RDCTRL
> +        9- AFIFM4_WRCTRL
> +        10- AFIFM5_RDCTRL
> +        11- AFIFM5_WRCTRL
> +        12- AFIFM6_RDCTRL
> +        13- AFIFM6_WRCTRL
> +        14- AFIFS
> +        15- AFIFS_SS2
> +      value - Array of values to be written.
> +        for FM0_RDCTRL(0) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM0_WRCTRL(1) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM1_RDCTRL(2) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM1_WRCTRL(3) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM2_RDCTRL(4) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM2_WRCTRL(5) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM3_RDCTRL(6) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM3_WRCTRL(7) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM4_RDCTRL(8) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM4_WRCTRL(9) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM5_RDCTRL(10) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM5_WRCTRL(11) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM6_RDCTRL(12) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for FM6_WRCTRL(13) the valid values-fabric width
> +          2 - 32-bit
> +          1 - 64-bit
> +          0 - 128-bit
> +        for AFI_FA(14)
> +          dw_ss1_sel      bits (11:10)
> +          dw_ss0_sel      bits (9:8)
> +            0x0 - 32-bit AXI data width
> +            0x1 - 64-bit AXI data width
> +            0x2 - 128-bit AXI data width
> +            All other bits are 0 write ignored.
> +
> +        for AFI_FA(15)  selects for ss2AXI data width valid values
> +          0x000 - 32-bit AXI data width
> +          0x100 - 64-bit AXI data width
> +          0x200 - 128-bit AXI data width
> +    minItems: 1
> +    maxItems: 15
> +
> +required:
> +  - compatible
> +  - config-afi
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    firmware {
> +      zynqmp_firmware: zynqmp-firmware {
> +        compatible = "xlnx,zynqmp-firmware";
> +        method = "smc";
> +        afi0: afi {
> +          compatible = "xlnx,afi-fpga";
> +          config-afi = <0 2>, <1 1>, <2 1>;
> +        };
> +      };
> +    };
> +
> +...
> -- 
> 2.18.0
> 


From olteanv at gmail.com  Tue Apr 20 15:16:50 2021
From: olteanv at gmail.com (Vladimir Oltean)
Date: Tue, 20 Apr 2021 17:16:50 +0300
Subject: [PATCH net-next 0/5] Flow control for NXP ENETC
In-Reply-To: <0bf4aa61dea7be0723fda2d8597644ad@walle.cc>
References: <20210416234225.3715819-1-olteanv@gmail.com>
 <fa2347b25d25e71f891e50f6f789e421@walle.cc>
 <20210420140433.hajuvfiz4humhhkt@skbuf>
 <0bf4aa61dea7be0723fda2d8597644ad@walle.cc>
Message-ID: <20210420141650.hiu6feeaj7zrdmco@skbuf>

On Tue, Apr 20, 2021 at 04:10:34PM +0200, Michael Walle wrote:
> Hi Vladimir,
> 
> Am 2021-04-20 16:04, schrieb Vladimir Oltean:
> > On Tue, Apr 20, 2021 at 03:27:24PM +0200, Michael Walle wrote:
> > > Hi Vladimir,
> > > 
> > > Am 2021-04-17 01:42, schrieb Vladimir Oltean:
> > > > From: Vladimir Oltean <vladimir.oltean at nxp.com>
> > > >
> > > > This patch series contains logic for enabling the lossless mode on the
> > > > RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO
> > > > memory.
> > > >
> > > > During testing it was found that, with the default FIFO configuration,
> > > > a sender which isn't persuaded by our PAUSE frames and keeps sending
> > > > will cause some MAC RX frame errors. To mitigate this, we need to ensure
> > > > that the FIFO never runs completely full, so we need to fix up a setting
> > > > that was supposed to be configured well out of reset. Unfortunately this
> > > > requires the addition of a new mini-driver.
> > > 
> > > What happens if the mini driver is not enabled? Then the fixes aren't
> > > applied and bad things happen (now with the addition of flow control),
> > > right?
> > > 
> > > I'm asking because, if you have the arm64 defconfig its not enabled.
> > > 
> > > shouldn't it be something like:
> > > 
> > > diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig
> > > b/drivers/net/ethernet/freescale/enetc/Kconfig
> > > index d88f60c2bb82..cdc0ff89388a 100644
> > > --- a/drivers/net/ethernet/freescale/enetc/Kconfig
> > > +++ b/drivers/net/ethernet/freescale/enetc/Kconfig
> > > @@ -2,7 +2,7 @@
> > >  config FSL_ENETC
> > >         tristate "ENETC PF driver"
> > >         depends on PCI && PCI_MSI
> > > -       depends on FSL_ENETC_IERB || FSL_ENETC_IERB=n
> > > +       select FSL_ENETC_IERB
> > >         select FSL_ENETC_MDIO
> > >         select PHYLINK
> > >         select PCS_LYNX
> > 
> > Yes, ideally the IERB driver and the ENETC PF driver should be built in
> > the same way, or the IERB driver can be built-in and the PF driver can
> > be module. I don't know how to express this using Kconfig, sorry.
> 
> With the small patch above it is:
>  FSL_ENETC=m -> FSL_ENETC_IERB = m or y
>  FSL_ENETC=y -> FSL_ENETC_IERB = y
>  FSL_ENETC=n -> FSL_ENETC_IERB = m,y or n
> 
> Will you fix it? Should I prepare a patch?

Could you please send the patch? Thanks.


From sudeep.holla at arm.com  Tue Apr 20 15:18:47 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 20 Apr 2021 15:18:47 +0100
Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
 PM_INIT_FINALIZE
In-Reply-To: <20210419073239.GA12636@pengutronix.de>
References: <20210317160410.2097178-1-m.tretter@pengutronix.de>
 <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>
 <20210419073239.GA12636@pengutronix.de>
Message-ID: <20210420141847.blcjrrvekjt6llck@bogus>

On Mon, Apr 19, 2021 at 09:32:39AM +0200, Michael Tretter wrote:

Sorry for chiming in randomly. I always though the way PM_INIT_FINALIZE
is designed has issues(e.g. racy). I was involved in discussion with
Xilinx when we will designing more generic version of EEMI - SCMI
which is now supported in upstream. EEMI was in production already when
we started on SCMI 3-4 years back and wanted to get feedback.

[...]

>
> What is the reason why all devices have to be requested before calling
> zynqmp_pm_init_finalize()?
>

Yes that is wrong assumption/expectation from the firmware.

> I was expecting that calling PM_INIT_FINALIZE only would tell the PMU_FW that
> Linux is using the PM API and the PMU_FW should power down/up PM slaves as
> requested by Linux. It is somewhat surprising that this isn't the case and all
> PM slaves have to be powered up before calling PM_INIT_FINALIZE.
>

Agreed that was my understanding too.

> What would happen if some driver is built as a module? In that case, the
> module would be loaded and request the pm node only after PM_INIT_FINALIZE was
> called. Do we have to avoid/disallow such cases?
>

I was told it will work. But it will be always racy if there are multiple
channels to talk to firmware.

My argument firmware can turn off all the devices before giving control
to OS and no need for that. But there is some boot time optimisation
possible I am told which I could well be. But this interface for too
racy IMO, just happens to be fine with limited configurations it operates
in.

--
Regards,
Sudeep


From lkp at intel.com  Tue Apr 20 15:18:28 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 20 Apr 2021 22:18:28 +0800
Subject: [PATCH v3 10/10] iommu/arm-smmu: Reserve any RMR regions
 associated with a dev
In-Reply-To: <20210420082751.1829-11-shameerali.kolothum.thodi@huawei.com>
References: <20210420082751.1829-11-shameerali.kolothum.thodi@huawei.com>
Message-ID: <202104202234.oz3LNQtv-lkp@intel.com>

Hi Shameer,

I love your patch! Yet something to improve:

[auto build test ERROR on pm/linux-next]
[also build test ERROR on arm/for-next soc/for-next arm64/for-next/core linus/master v5.12-rc8]
[cannot apply to iommu/next xlnx/master next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: arm-randconfig-r023-20210420 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project ca8eef7e3da8f750d7c7aa004fe426d1d34787ea)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/ea2019c2969e4e8f6ec2b0dc2d492f0d05f36cd9
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Shameer-Kolothum/ACPI-IORT-Support-for-IORT-RMR-node/20210420-173125
        git checkout ea2019c2969e4e8f6ec2b0dc2d492f0d05f36cd9
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from drivers/iommu/arm/arm-smmu/arm-smmu.c:24:
   include/linux/dma-iommu.h:94:71: warning: declaration of 'struct iommu_rmr' will not be visible outside of this function [-Wvisibility]
   static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
                                                                         ^
   include/linux/dma-iommu.h:100:1: error: expected identifier or '('
   {
   ^
>> drivers/iommu/arm/arm-smmu/arm-smmu.c:1622:39: error: incompatible pointer types passing 'struct iommu_rmr *' to parameter of type 'struct iommu_rmr *' [-Werror,-Wincompatible-pointer-types]
                   iommu_dma_get_rmr_resv_regions(dev, rmr, head);
                                                       ^~~
   include/linux/dma-iommu.h:94:82: note: passing argument to parameter 'rmr' here
   static void iommu_dma_get_rmr_resv_regions(struct device *dev, struct iommu_rmr *rmr,
                                                                                    ^
   1 warning and 2 errors generated.


vim +1622 drivers/iommu/arm/arm-smmu/arm-smmu.c

  1609	
  1610	static void arm_smmu_rmr_get_resv_regions(struct device *dev,
  1611						  struct list_head *head)
  1612	{
  1613		struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
  1614		struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
  1615		struct arm_smmu_device *smmu = cfg->smmu;
  1616		struct iommu_rmr *rmr;
  1617	
  1618		list_for_each_entry(rmr, &smmu->rmr_list, list) {
  1619			if (!arm_smmu_dev_has_rmr(cfg, fwspec, rmr))
  1620				continue;
  1621	
> 1622			iommu_dma_get_rmr_resv_regions(dev, rmr, head);
  1623		}
  1624	}
  1625	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25176 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210420/04d86f4d/attachment-0001.gz>

From festevam at gmail.com  Tue Apr 20 15:27:05 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 20 Apr 2021 11:27:05 -0300
Subject: [PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC
 board support
In-Reply-To: <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>
Message-ID: <CAOMZO5CcoKDZhj5rQ0_0wkHgk5Mf2RtAHy94EAzjwVgXvvmNeg@mail.gmail.com>

Hi Dillon,

On Thu, Apr 15, 2021 at 1:05 AM <dillon.minfei at gmail.com> wrote:

> +               green {
> +                       gpios = <&gpio4 8 0>;

Please use GPIO_ACTIVE_HIGH label instead:
gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;

> +&clks {
> +       assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> +                         <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> +       assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> +                                <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};

You are setting the LDB clock parent, but you don't use LDB in this
devicetree. You could simply remove this.

> +&ecspi1 {
> +       cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ecspi1>;
> +       status = "okay";
> +
> +       flash: m25p80 at 0 {

Node names should be generic:

m25p80: flash at 0

> +&iomuxc {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_hog>;
> +
> +       imx6qdl-ds {
> +               pinctrl_hog: hoggrp {
> +                       fsl,pins = <
> +                               MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> +                               MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> +                               MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0

This could be part of the pinctrl_ov2659 group as it provides the
clock for the camera.

Please try to keep in the hoggrp only the pins that cannot be
controlled by any other node.

> +&wdog1 {
> +       status = "okay";
> +};
> +
> +&wdog2 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_wdog>;
> +       fsl,ext-reset-output;
> +       status = "disabled";

Wouldn't it be better to enable wdog2 and disable wdog1 instead? wdog2
provides a POR, which is preferred.


From rppt at linux.ibm.com  Tue Apr 20 15:38:38 2021
From: rppt at linux.ibm.com (Mike Rapoport)
Date: Tue, 20 Apr 2021 17:38:38 +0300
Subject: [PATCH v2 0/2] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210420131611.8259-1-rppt@kernel.org>
References: <20210420131611.8259-1-rppt@kernel.org>
Message-ID: <YH7nbrF1/AAYl83C@linux.ibm.com>

It seems I've messed this posting entirely :(

Please ignore it, sorry for the noise.

On Tue, Apr 20, 2021 at 04:16:07PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> Hi,
> 
> This is an updated version of page_is_secretmem() changes.
> This is based on v5.12-rc7-mmots-2021-04-15-16-28.
> 
> @Andrew, please let me know if you'd like me to rebase it differently or
> resend the entire set.
> 
> v2:
> * move the check for secretmem page in gup_pte_range after we get a
>   reference to the page, per Matthew.
> 
> Mike Rapoport (2):
>   secretmem/gup: don't check if page is secretmem without reference
>   secretmem: optimize page_is_secretmem()
> 
>  include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
>  mm/gup.c                  |  6 +++---
>  mm/secretmem.c            | 12 +-----------
>  3 files changed, 29 insertions(+), 15 deletions(-)
> 
> -- 
> 2.28.0
> 

-- 
Sincerely yours,
Mike.


From frank-w at public-files.de  Tue Apr 20 15:59:30 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Tue, 20 Apr 2021 16:59:30 +0200
Subject: Aw: Re: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>
References: <20210320080646.49615-1-linux@fw-web.de>
 <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>
Message-ID: <trinity-4a3f024e-c01d-44e4-a884-530135853d33-1618930770250@3c-app-gmx-bs72>

Hi,

> Gesendet: Dienstag, 20. April 2021 um 14:07 Uhr
> Von: "Daniel Lezcano" <daniel.lezcano at linaro.org>

> No #ifdef in C file.
...

> devm_thermal_add_hwmon_sysfs() ?

based on your comments this should be enough/right?

#if IS_ENABLED(CONFIG_THERMAL_HWMON)
    tzdev->tzp->no_hwmon = false;
    ret = devm_thermal_add_hwmon_sysfs(tzdev);
    if (ret)
        dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
#endif

if yes i send out v2, at least it works on my device

regards Frank




From rppt at kernel.org  Tue Apr 20 16:00:47 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 18:00:47 +0300
Subject: [PATCH v3 0/2]  secretmem: optimize page_is_secretmem()
Message-ID: <20210420150049.14031-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

This is an updated version of page_is_secretmem() changes.
This is based on v5.12-rc7-mmots-2021-04-15-16-28.

@Andrew, please let me know if you'd like me to rebase it differently or
resend the entire set.

v3:
* add missing put_compound_head() if we are to return NULL from
  gup_page_range(), thanks David.
* add unlikely() to test for page_is_secretmem.

v2:
* move the check for secretmem page in gup_pte_range after we get a
  reference to the page, per Matthew.

Mike Rapoport (2):
  secretmem/gup: don't check if page is secretmem without reference
  secretmem: optimize page_is_secretmem()

 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/gup.c                  |  6 +++---
 mm/secretmem.c            | 12 +-----------
 3 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.28.0


Mike Rapoport (2):
  secretmem/gup: don't check if page is secretmem without reference
  secretmem: optimize page_is_secretmem()

 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/gup.c                  |  8 +++++---
 mm/secretmem.c            | 12 +-----------
 3 files changed, 31 insertions(+), 15 deletions(-)

-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 16:00:48 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 18:00:48 +0300
Subject: [PATCH v3 1/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <20210420150049.14031-1-rppt@kernel.org>
References: <20210420150049.14031-1-rppt@kernel.org>
Message-ID: <20210420150049.14031-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The check in gup_pte_range() whether a page belongs to a secretmem mapping
is performed before grabbing the page reference.

To avoid potential race move the check after try_grab_compound_head().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 mm/gup.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index c3a17b189064..6515f82b0f32 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2080,13 +2080,15 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
 		page = pte_page(pte);
 
-		if (page_is_secretmem(page))
-			goto pte_unmap;
-
 		head = try_grab_compound_head(page, 1, flags);
 		if (!head)
 			goto pte_unmap;
 
+		if (unlikely(page_is_secretmem(page))) {
+			put_compound_head(head, 1, flags);
+			goto pte_unmap;
+		}
+
 		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
 			put_compound_head(head, 1, flags);
 			goto pte_unmap;
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 16:00:49 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 18:00:49 +0300
Subject: [PATCH v3 2/2] secretmem: optimize page_is_secretmem()
In-Reply-To: <20210420150049.14031-1-rppt@kernel.org>
References: <20210420150049.14031-1-rppt@kernel.org>
Message-ID: <20210420150049.14031-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Kernel test robot reported -4.2% regression of will-it-scale.per_thread_ops
due to commit "mm: introduce memfd_secret system call to create "secret"
memory areas".

The perf profile of the test indicated that the regression is caused by
page_is_secretmem() called from gup_pte_range() (inlined by gup_pgd_range):

 27.76  +2.5  30.23       perf-profile.children.cycles-pp.gup_pgd_range
  0.00  +3.2   3.19 ? 2%  perf-profile.children.cycles-pp.page_mapping
  0.00  +3.7   3.66 ? 2%  perf-profile.children.cycles-pp.page_is_secretmem

Further analysis showed that the slow down happens because neither
page_is_secretmem() nor page_mapping() are not inline and moreover,
multiple page flags checks in page_mapping() involve calling
compound_head() several times for the same page.

Make page_is_secretmem() inline and replace page_mapping() with page flag
checks that do not imply page-to-head conversion.

Reported-by: kernel test robot <oliver.sang at intel.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/secretmem.h | 26 +++++++++++++++++++++++++-
 mm/secretmem.c            | 12 +-----------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
index 907a6734059c..b842b38cbeb1 100644
--- a/include/linux/secretmem.h
+++ b/include/linux/secretmem.h
@@ -4,8 +4,32 @@
 
 #ifdef CONFIG_SECRETMEM
 
+extern const struct address_space_operations secretmem_aops;
+
+static inline bool page_is_secretmem(struct page *page)
+{
+	struct address_space *mapping;
+
+	/*
+	 * Using page_mapping() is quite slow because of the actual call
+	 * instruction and repeated compound_head(page) inside the
+	 * page_mapping() function.
+	 * We know that secretmem pages are not compound and LRU so we can
+	 * save a couple of cycles here.
+	 */
+	if (PageCompound(page) || !PageLRU(page))
+		return false;
+
+	mapping = (struct address_space *)
+		((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS);
+
+	if (mapping != page->mapping)
+		return false;
+
+	return page->mapping->a_ops == &secretmem_aops;
+}
+
 bool vma_is_secretmem(struct vm_area_struct *vma);
-bool page_is_secretmem(struct page *page);
 bool secretmem_active(void);
 
 #else
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 3b1ba3991964..0bcd15e1b549 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -151,22 +151,12 @@ static void secretmem_freepage(struct page *page)
 	clear_highpage(page);
 }
 
-static const struct address_space_operations secretmem_aops = {
+const struct address_space_operations secretmem_aops = {
 	.freepage	= secretmem_freepage,
 	.migratepage	= secretmem_migratepage,
 	.isolate_page	= secretmem_isolate_page,
 };
 
-bool page_is_secretmem(struct page *page)
-{
-	struct address_space *mapping = page_mapping(page);
-
-	if (!mapping)
-		return false;
-
-	return mapping->a_ops == &secretmem_aops;
-}
-
 static struct vfsmount *secretmem_mnt;
 
 static struct file *secretmem_file_create(unsigned long flags)
-- 
2.28.0



From rppt at kernel.org  Tue Apr 20 16:03:11 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 18:03:11 +0300
Subject: [PATCH v1 2/4] memblock: update initialization of reserved pages
In-Reply-To: <ed8f10a0-9b68-1d12-0305-90fd378af6b9@redhat.com>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-3-rppt@kernel.org>
 <ed8f10a0-9b68-1d12-0305-90fd378af6b9@redhat.com>
Message-ID: <YH7tL77Z9UzTAFca@kernel.org>

On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> > reserved region just before the memory is freed from memblock to the buddy
> > page allocator.
> > 
> > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > values set by the memory map initialization which makes it necessary to
> > have a special treatment for such pages in pfn_valid() and
> > pfn_valid_within().
> 
> Just a general question while thinking about it:
> 
> Would we right now initialize the memmap of these pages already via
> memmap_init_zone()->memmap_init_range()? (IOW, not marking the
> PageReserved?)

Yep. These pages are part of memblock.memory so they are initialized in
memmap_init_zone()->memmap_init_range() to the default values.

-- 
Sincerely yours,
Mike.


From robh at kernel.org  Tue Apr 20 16:05:43 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 10:05:43 -0500
Subject: [PATCH v9 13/15] dt-bindings: power: rockchip: Convert to
 json-schema
In-Reply-To: <20210417112952.8516-14-jbx6244@gmail.com>
References: <20210417112952.8516-1-jbx6244@gmail.com>
 <20210417112952.8516-14-jbx6244@gmail.com>
Message-ID: <20210420150543.GA3327645@robh.at.kernel.org>

On Sat, 17 Apr 2021 13:29:50 +0200, Johan Jonker wrote:
> From: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> 
> Convert the soc/rockchip/power_domain.txt binding document to
> json-schema and move to the power bindings directory.
> 
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Note for rob+dt:
> A tag was not added on purpose, because:
>   Add "rockchip," prefix to the qos compatible name
>   in example.
>   Changed maintainers.
>   Size reg description is reduced.
>   Little style changes '' to ""
>   Restyle patternProperties
> Please have a look at it again.
> 
> For some SoC nodes this patch serie generates notifications
> for undocumented "assigned-clocks" and "assigned-clock-parents"
> properties till there is consensus of what to do with it.
> ---
> Changed V9:
>   Rename definitions to $defs
>   Restyle patternProperties
> Changed V8:
>   Add pd-node ref schema
> Changed V7:
>   Fix commit message and author format
>   Changed SPDX-License-Identifier back to GPL-2.0
>   Remove "clocks", "assigned-clocks" and "assigned-clock-parents"
>   Fix indent example
> Changed V6:
>   Changed author
> Changed V5:
>   Change SPDX-License-Identifier to  GPL-2.0-only OR BSD-2-Clause
>   Remove a maintainer
>   Changed patternProperties to power-domain
>   Add "clocks", "assigned-clocks" and "assigned-clock-parents"
> Changed V4:
>   Remove new compatible string
>   Style changes '' to ""
> Changed V3:
>   Use Enric's conversion with rk3399 example
> Changed V2:
>   Convert power_domain.txt to YAML with rk3568 example
> ---
>  .../bindings/power/rockchip,power-controller.yaml  | 246 +++++++++++++++++++++
>  .../bindings/soc/rockchip/power_domain.txt         | 136 ------------
>  2 files changed, 246 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From broonie at kernel.org  Tue Apr 20 16:06:37 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 20 Apr 2021 16:06:37 +0100
Subject: spi: stm32-qspi: Fix compilation warning in ARM64
In-Reply-To: <20210420082103.1693-1-patrice.chotard@foss.st.com>
References: <20210420082103.1693-1-patrice.chotard@foss.st.com>
Message-ID: <161893071088.55669.5165788447992164184.b4-ty@kernel.org>

On Tue, 20 Apr 2021 10:21:03 +0200, patrice.chotard at foss.st.com wrote:
> This fixes warnings detected when compiling in ARM64.
> Introduced by 'commit 18674dee3cd6 ("spi: stm32-qspi: Add dirmap support")'

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: stm32-qspi: Fix compilation warning in ARM64
      commit: 1b8a7d4282c038b3846f2485d86cb990c55c38d9

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 hverkuil at xs4all.nl  Tue Apr 20 16:13:15 2021
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Tue, 20 Apr 2021 17:13:15 +0200
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
 <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
 <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
Message-ID: <cbea511c-5d5c-8c59-f91f-fedc8eec1e39@xs4all.nl>

On 16/04/2021 13:38, Neil Armstrong wrote:
> On 16/04/2021 11:58, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>> This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
>>>
>>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
>>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
>>
>> If we can't trust the CEC config bit, would it be better to not use it
>> at all, and instead let each platform glue logic tell whether to enable
>> CEC or not ?
> 
> Actually, the CEC config bit is right, the HW exists and should be functional, but
> this bit doesn't tell if the CEC signal is connected to something.
> 
> This lies in the IP integration, like other bits under the "amlogic,meson-*-dw-hdmi"
> umbrella.
> 
> The first attempt was by Hans using DT, but adding a property in DT for a vendor
> specific compatible doesn't make sense. Another idea would be to describe the
> CEC signal endpoint like we do for video signal, but I think this is out of scope and
> this solution is much simpler and straightforward, and it's more an exception than
> a general use case to solve.

While a DT property might not make sense in this particular case, I still
believe that it is a perfectly valid approach in general: whether or not
the CEC pin is connected is at the hardware level decision, it is not
something that software can detect. If the designer of the board didn't
connect it, then the only place you can define that is in the device tree.

Anyway, for meson I am fine with this solution. At least it prevents creating
a non-functioning cec device. So for this series:

Acked-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>

Regards,

	Hans

> 
> Neil
> 
>>
>>> Jernej Skrabec (1):
>>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>>>     driver
>>>
>>> Neil Armstrong (1):
>>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>>
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
>>>  include/drm/bridge/dw_hdmi.h              | 2 ++
>>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 



From david at redhat.com  Tue Apr 20 16:17:58 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 17:17:58 +0200
Subject: [PATCH v3 1/2] secretmem/gup: don't check if page is secretmem
 without reference
In-Reply-To: <20210420150049.14031-2-rppt@kernel.org>
References: <20210420150049.14031-1-rppt@kernel.org>
 <20210420150049.14031-2-rppt@kernel.org>
Message-ID: <f906a634-ee25-5a8b-6cdf-3651832dbe99@redhat.com>

On 20.04.21 17:00, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The check in gup_pte_range() whether a page belongs to a secretmem mapping
> is performed before grabbing the page reference.
> 
> To avoid potential race move the check after try_grab_compound_head().
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   mm/gup.c | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index c3a17b189064..6515f82b0f32 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2080,13 +2080,15 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>   		VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
>   		page = pte_page(pte);
>   
> -		if (page_is_secretmem(page))
> -			goto pte_unmap;
> -
>   		head = try_grab_compound_head(page, 1, flags);
>   		if (!head)
>   			goto pte_unmap;
>   
> +		if (unlikely(page_is_secretmem(page))) {
> +			put_compound_head(head, 1, flags);
> +			goto pte_unmap;
> +		}
> +
>   		if (unlikely(pte_val(pte) != pte_val(*ptep))) {
>   			put_compound_head(head, 1, flags);
>   			goto pte_unmap;
> 

Reviewed-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From daniel.lezcano at linaro.org  Tue Apr 20 16:18:32 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 20 Apr 2021 17:18:32 +0200
Subject: Aw: Re: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <trinity-4a3f024e-c01d-44e4-a884-530135853d33-1618930770250@3c-app-gmx-bs72>
References: <20210320080646.49615-1-linux@fw-web.de>
 <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>
 <trinity-4a3f024e-c01d-44e4-a884-530135853d33-1618930770250@3c-app-gmx-bs72>
Message-ID: <b38c3539-c864-67b3-95e8-9b652cf6fcbf@linaro.org>


Hi Frank,

On 20/04/2021 16:59, Frank Wunderlich wrote:
> Hi,
> 
>> Gesendet: Dienstag, 20. April 2021 um 14:07 Uhr
>> Von: "Daniel Lezcano" <daniel.lezcano at linaro.org>
> 
>> No #ifdef in C file.
> ...
> 
>> devm_thermal_add_hwmon_sysfs() ?
> 
> based on your comments this should be enough/right?
> 
> #if IS_ENABLED(CONFIG_THERMAL_HWMON)
>     tzdev->tzp->no_hwmon = false;>     ret = devm_thermal_add_hwmon_sysfs(tzdev);
>     if (ret)
>         dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
> #endif
> 
> if yes i send out v2, at least it works on my device

just the following lines should work:

	ret = devm_thermal_add_hwmon_sysfs(tzdev);
	if (ret)
		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");


The no_hwmon usage is a bit fuzzy in the thermal core code.


-- 
<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 david at redhat.com  Tue Apr 20 16:18:55 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 17:18:55 +0200
Subject: [PATCH v1 2/4] memblock: update initialization of reserved pages
In-Reply-To: <YH7tL77Z9UzTAFca@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-3-rppt@kernel.org>
 <ed8f10a0-9b68-1d12-0305-90fd378af6b9@redhat.com>
 <YH7tL77Z9UzTAFca@kernel.org>
Message-ID: <45a7e13d-3e44-3b94-a253-2df72649a83d@redhat.com>

On 20.04.21 17:03, Mike Rapoport wrote:
> On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
>> On 20.04.21 11:09, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> The struct pages representing a reserved memory region are initialized
>>> using reserve_bootmem_range() function. This function is called for each
>>> reserved region just before the memory is freed from memblock to the buddy
>>> page allocator.
>>>
>>> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
>>> values set by the memory map initialization which makes it necessary to
>>> have a special treatment for such pages in pfn_valid() and
>>> pfn_valid_within().
>>
>> Just a general question while thinking about it:
>>
>> Would we right now initialize the memmap of these pages already via
>> memmap_init_zone()->memmap_init_range()? (IOW, not marking the
>> PageReserved?)
> 
> Yep. These pages are part of memblock.memory so they are initialized in
> memmap_init_zone()->memmap_init_range() to the default values.
> 

So instead of fully initializing them again, we mostly would only have 
to set PageReserved(). Not sure how big that memory usually is -- IOW, 
if we really care about optimizing the double-init.

-- 
Thanks,

David / dhildenb



From narmstrong at baylibre.com  Tue Apr 20 16:19:52 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Tue, 20 Apr 2021 17:19:52 +0200
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <cbea511c-5d5c-8c59-f91f-fedc8eec1e39@xs4all.nl>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
 <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
 <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
 <cbea511c-5d5c-8c59-f91f-fedc8eec1e39@xs4all.nl>
Message-ID: <0821533b-9e6a-237e-3845-741e82de4ed9@baylibre.com>

On 20/04/2021 17:13, Hans Verkuil wrote:
> On 16/04/2021 13:38, Neil Armstrong wrote:
>> On 16/04/2021 11:58, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>>> This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
>>>>
>>>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
>>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
>>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
>>>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
>>>
>>> If we can't trust the CEC config bit, would it be better to not use it
>>> at all, and instead let each platform glue logic tell whether to enable
>>> CEC or not ?
>>
>> Actually, the CEC config bit is right, the HW exists and should be functional, but
>> this bit doesn't tell if the CEC signal is connected to something.
>>
>> This lies in the IP integration, like other bits under the "amlogic,meson-*-dw-hdmi"
>> umbrella.
>>
>> The first attempt was by Hans using DT, but adding a property in DT for a vendor
>> specific compatible doesn't make sense. Another idea would be to describe the
>> CEC signal endpoint like we do for video signal, but I think this is out of scope and
>> this solution is much simpler and straightforward, and it's more an exception than
>> a general use case to solve.
> 
> While a DT property might not make sense in this particular case, I still
> believe that it is a perfectly valid approach in general: whether or not
> the CEC pin is connected is at the hardware level decision, it is not
> something that software can detect. If the designer of the board didn't
> connect it, then the only place you can define that is in the device tree.

Agreed, we need to define a smart way to declare CEC bus relationship in DT, the side
effect would be to handle this particular case.

> 
> Anyway, for meson I am fine with this solution. At least it prevents creating
> a non-functioning cec device. So for this series:
> 
> Acked-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>

Thanks,

Applying this serie to drm-misc-next

Neil

> 
> Regards,
> 
> 	Hans
> 
>>
>> Neil
>>
>>>
>>>> Jernej Skrabec (1):
>>>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>>>>     driver
>>>>
>>>> Neil Armstrong (1):
>>>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>>>
>>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
>>>>  include/drm/bridge/dw_hdmi.h              | 2 ++
>>>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 



From frank-w at public-files.de  Tue Apr 20 16:24:11 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Tue, 20 Apr 2021 17:24:11 +0200
Subject: Aw: Re: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <b38c3539-c864-67b3-95e8-9b652cf6fcbf@linaro.org>
References: <20210320080646.49615-1-linux@fw-web.de>
 <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>
 <trinity-4a3f024e-c01d-44e4-a884-530135853d33-1618930770250@3c-app-gmx-bs72>
 <b38c3539-c864-67b3-95e8-9b652cf6fcbf@linaro.org>
Message-ID: <846366E9-5029-4C6A-B2EC-F70D901DC379@public-files.de>

Am 20. April 2021 17:18:32 MESZ schrieb Daniel Lezcano <daniel.lezcano at linaro.org>:
>
>Hi Frank,

>The no_hwmon usage is a bit fuzzy in the thermal core code.

Maybe add depency in Kconfig? Else we can get undefined symbols on linking

regards Frank


From rppt at kernel.org  Tue Apr 20 16:25:01 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 20 Apr 2021 18:25:01 +0300
Subject: [PATCH v1 2/4] memblock: update initialization of reserved pages
In-Reply-To: <45a7e13d-3e44-3b94-a253-2df72649a83d@redhat.com>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-3-rppt@kernel.org>
 <ed8f10a0-9b68-1d12-0305-90fd378af6b9@redhat.com>
 <YH7tL77Z9UzTAFca@kernel.org>
 <45a7e13d-3e44-3b94-a253-2df72649a83d@redhat.com>
Message-ID: <YH7yTahcTVy31Uxk@kernel.org>

On Tue, Apr 20, 2021 at 05:18:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 17:03, Mike Rapoport wrote:
> > On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> > > On 20.04.21 11:09, Mike Rapoport wrote:
> > > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > > 
> > > > The struct pages representing a reserved memory region are initialized
> > > > using reserve_bootmem_range() function. This function is called for each
> > > > reserved region just before the memory is freed from memblock to the buddy
> > > > page allocator.
> > > > 
> > > > The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> > > > values set by the memory map initialization which makes it necessary to
> > > > have a special treatment for such pages in pfn_valid() and
> > > > pfn_valid_within().
> > > 
> > > Just a general question while thinking about it:
> > > 
> > > Would we right now initialize the memmap of these pages already via
> > > memmap_init_zone()->memmap_init_range()? (IOW, not marking the
> > > PageReserved?)
> > 
> > Yep. These pages are part of memblock.memory so they are initialized in
> > memmap_init_zone()->memmap_init_range() to the default values.
> > 
> 
> So instead of fully initializing them again, we mostly would only have to
> set PageReserved(). Not sure how big that memory usually is -- IOW, if we
> really care about optimizing the double-init.

IIUC, these are small areas reserved by the firmware, like e.g. ACPI
tables.

@Ard, am I right?

-- 
Sincerely yours,
Mike.


From daniel.lezcano at linaro.org  Tue Apr 20 16:27:16 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 20 Apr 2021 17:27:16 +0200
Subject: Aw: Re: [PATCH] thermal: mediatek: add sensors-support
In-Reply-To: <846366E9-5029-4C6A-B2EC-F70D901DC379@public-files.de>
References: <20210320080646.49615-1-linux@fw-web.de>
 <f4329b1a-02e0-aad5-55bd-82d30a38fc55@linaro.org>
 <trinity-4a3f024e-c01d-44e4-a884-530135853d33-1618930770250@3c-app-gmx-bs72>
 <b38c3539-c864-67b3-95e8-9b652cf6fcbf@linaro.org>
 <846366E9-5029-4C6A-B2EC-F70D901DC379@public-files.de>
Message-ID: <39eddcac-a86f-9259-6a1f-d3e39d872bb8@linaro.org>

On 20/04/2021 17:24, Frank Wunderlich wrote:
> Am 20. April 2021 17:18:32 MESZ schrieb Daniel Lezcano <daniel.lezcano at linaro.org>:
>>
>> Hi Frank,
> 
>> The no_hwmon usage is a bit fuzzy in the thermal core code.
> 
> Maybe add depency in Kconfig? Else we can get undefined symbols on linking
> 
> regards Frank

Nope, there are the stubs in thermal_hwmon.h



-- 
<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 gregkh at linuxfoundation.org  Tue Apr 20 16:27:16 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 20 Apr 2021 17:27:16 +0200
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <MWHPR02MB2623DED0785A05A9C55C20FBC2489@MWHPR02MB2623.namprd02.prod.outlook.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-3-nava.manne@xilinx.com>
 <YH6U/L4SEtJajusW@kroah.com>
 <MWHPR02MB2623DED0785A05A9C55C20FBC2489@MWHPR02MB2623.namprd02.prod.outlook.com>
Message-ID: <YH7y1Em4bp505DaV@kroah.com>

On Tue, Apr 20, 2021 at 01:36:51PM +0000, Nava kishore Manne wrote:
> Hi Greg,
> 
> 	Please find my response inline.
> 
> > -----Original Message-----
> > From: Greg KH <gregkh at linuxfoundation.org>
> > Sent: Tuesday, April 20, 2021 2:17 PM
> > To: Nava kishore Manne <navam at xilinx.com>
> > Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> > <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> > arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> > <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> > Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > chinnikishore369 at gmail.com; git <git at xilinx.com>
> > Subject: Re: [PATCH 2/5] misc: zynq: Add afi config driver
> > 
> > On Tue, Apr 20, 2021 at 01:41:50PM +0530, Nava kishore Manne wrote:
> > > This patch adds zynq afi config driver. This is useful for the
> > > configuration of the PS-PL interface on zynq platform.
> > 
> > What is "PS-PL"?  Can you describe it better please?
> > 
> PS-PL interface is nothing but the interface between processing system(PS)  that contains arm cores and Programmable Logic(PL) i.e FPGA.
> Will update the description in v2.
> 
> > >
> > > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > > ---
> > >  drivers/misc/Kconfig    | 11 ++++++
> > >  drivers/misc/Makefile   |  1 +
> > >  drivers/misc/zynq-afi.c | 81
> > > +++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 93 insertions(+)
> > >  create mode 100644 drivers/misc/zynq-afi.c
> > >
> > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > > f532c59bb59b..877b43b3377d 100644
> > > --- a/drivers/misc/Kconfig
> > > +++ b/drivers/misc/Kconfig
> > > @@ -445,6 +445,17 @@ config HISI_HIKEY_USB
> > >  	  switching between the dual-role USB-C port and the USB-A host
> > ports
> > >  	  using only one USB controller.
> > >
> > > +config ZYNQ_AFI
> > > +	tristate "Xilinx ZYNQ AFI support"
> > > +	help
> > > +	  Zynq AFI driver support for writing to the AFI registers
> > > +	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
> > > +	  the PS to the programmable logic (PL) through the AXI port.
> > > +	  This AXI port helps to establish the data path between the
> > > +	  PS and PL.In-order to establish the proper communication path
> > > +	  between PS and PL, the AXI port data path should be configured
> > > +	  with the proper Bus-width values
> > > +
> > >  source "drivers/misc/c2port/Kconfig"
> > >  source "drivers/misc/eeprom/Kconfig"
> > >  source "drivers/misc/cb710/Kconfig"
> > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > > 99b6f15a3c70..e9b03843100f 100644
> > > --- a/drivers/misc/Makefile
> > > +++ b/drivers/misc/Makefile
> > > @@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI)		+=
> > habanalabs/
> > >  obj-$(CONFIG_UACCE)		+= uacce/
> > >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> > >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> > > +obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > > diff --git a/drivers/misc/zynq-afi.c b/drivers/misc/zynq-afi.c new
> > > file mode 100644 index 000000000000..04317d1bdb98
> > > --- /dev/null
> > > +++ b/drivers/misc/zynq-afi.c
> > > @@ -0,0 +1,81 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Xilinx ZYNQ AFI driver.
> > > + * Copyright (c) 2018-2021 Xilinx Inc.
> > > + */
> > > +
> > > +#include <linux/err.h>
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/platform_device.h>
> > > +
> > > +/* Registers and special values for doing register-based operations */
> > > +#define AFI_RDCHAN_CTRL_OFFSET	0x00
> > > +#define AFI_WRCHAN_CTRL_OFFSET	0x14
> > > +
> > > +#define AFI_BUSWIDTH_MASK	0x01
> > > +
> > > +/**
> > > + * struct afi_fpga - AFI register description
> > > + * @membase:	pointer to register struct
> > > + * @afi_width:	AFI bus width to be written
> > > + */
> > > +struct zynq_afi_fpga {
> > > +	void __iomem	*membase;
> > > +	u32		afi_width;
> > > +};
> > > +
> > > +static int zynq_afi_fpga_probe(struct platform_device *pdev) {
> > > +	struct zynq_afi_fpga *afi_fpga;
> > > +	struct resource *res;
> > > +	u32 reg_val;
> > > +	u32 val;
> > > +
> > > +	afi_fpga = devm_kzalloc(&pdev->dev, sizeof(*afi_fpga),
> > GFP_KERNEL);
> > > +	if (!afi_fpga)
> > > +		return -ENOMEM;
> > > +
> > > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > +	afi_fpga->membase = devm_ioremap_resource(&pdev->dev, res);
> > > +	if (IS_ERR(afi_fpga->membase))
> > > +		return PTR_ERR(afi_fpga->membase);
> > > +
> > > +	val = device_property_read_u32(&pdev->dev, "xlnx,afi-width",
> > > +				       &afi_fpga->afi_width);
> > > +	if (val) {
> > > +		dev_err(&pdev->dev, "failed to get the afi bus width\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	reg_val = readl(afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > > +	writel(reg_val | afi_fpga->afi_width,
> > > +	       afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > > +	reg_val = readl(afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > > +	writel(reg_val | afi_fpga->afi_width,
> > > +	       afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > > +
> > > +	return 0;
> > > +}
> > 
> > I do not understand, why is this driver needed at all?  Why can't you do the
> > above from userspace?
> > 
> > All this does is write some values to the hardware at probe time, who needs
> > this?
> 
> This driver will be used by the overlay framework for configuring the interface after programming the FPGA and before probing the drivers that are present in the PL.

What is a "overlay framework"?  And why does the kernel have to do this?
Why can't you write these hardware values from userspace?

confused,

greg k-h


From gregkh at linuxfoundation.org  Tue Apr 20 16:28:25 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 20 Apr 2021 17:28:25 +0200
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <MWHPR02MB26233345F140ACA18E55BC15C2489@MWHPR02MB2623.namprd02.prod.outlook.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com>
 <YH6V9Im3L/gJJ/CP@kroah.com>
 <MWHPR02MB26233345F140ACA18E55BC15C2489@MWHPR02MB2623.namprd02.prod.outlook.com>
Message-ID: <YH7zGf3/NrXmMN8/@kroah.com>

On Tue, Apr 20, 2021 at 01:47:17PM +0000, Nava kishore Manne wrote:
> Hi Greg,
> 
> 	Please find my response inline.
> 
> > -----Original Message-----
> > From: Greg KH <gregkh at linuxfoundation.org>
> > Sent: Tuesday, April 20, 2021 2:21 PM
> > To: Nava kishore Manne <navam at xilinx.com>
> > Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> > <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> > arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> > <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> > Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > chinnikishore369 at gmail.com; git <git at xilinx.com>
> > Subject: Re: [PATCH 5/5] misc: zynqmp: Add afi config driver
> > 
> > On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> > > This patch adds zynqmp afi config driver.This is useful for the
> > > configuration of the PS-PL interface on Zynq US+ MPSoC platform.
> > >
> > > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > > ---
> > >  drivers/misc/Kconfig      | 11 ++++++
> > >  drivers/misc/Makefile     |  1 +
> > >  drivers/misc/zynqmp-afi.c | 83
> > > +++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 95 insertions(+)
> > >  create mode 100644 drivers/misc/zynqmp-afi.c
> > >
> > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > > 877b43b3377d..d1ea1eeb3ac1 100644
> > > --- a/drivers/misc/Kconfig
> > > +++ b/drivers/misc/Kconfig
> > > @@ -456,6 +456,17 @@ config ZYNQ_AFI
> > >  	  between PS and PL, the AXI port data path should be configured
> > >  	  with the proper Bus-width values
> > >
> > > +config ZYNQMP_AFI
> > > +        tristate "Xilinx ZYNQMP AFI support"
> > > +        help
> > > +	  ZynqMP AFI driver support for writing to the AFI registers for
> > > +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> > > +	  PS to the programmable logic (PL) through the AXI port. This AXI
> > > +	  port helps to establish the data path between the PS and PL.
> > > +	  In-order to establish the proper communication path between
> > > +	  PS and PL, the AXI port data path should be configured with
> > > +	  the proper Bus-width values
> > > +
> > >  source "drivers/misc/c2port/Kconfig"
> > >  source "drivers/misc/eeprom/Kconfig"
> > >  source "drivers/misc/cb710/Kconfig"
> > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > > e9b03843100f..54bd0edc511e 100644
> > > --- a/drivers/misc/Makefile
> > > +++ b/drivers/misc/Makefile
> > > @@ -57,3 +57,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
> > >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> > >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> > >  obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > > +obj-$(CONFIG_ZYNQMP_AFI)	+= zynqmp-afi.o
> > > diff --git a/drivers/misc/zynqmp-afi.c b/drivers/misc/zynqmp-afi.c new
> > > file mode 100644 index 000000000000..a318652576d2
> > > --- /dev/null
> > > +++ b/drivers/misc/zynqmp-afi.c
> > > @@ -0,0 +1,83 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Xilinx FPGA AFI bridge.
> > > + * Copyright (c) 2018-2021 Xilinx Inc.
> > > + */
> > > +
> > > +#include <linux/err.h>
> > > +#include <linux/firmware/xlnx-zynqmp.h> #include <linux/io.h>
> > > +#include <linux/module.h> #include <linux/of.h> #include
> > > +<linux/platform_device.h> #include <linux/slab.h>
> > > +
> > > +/**
> > > + * struct zynqmp_afi_fpga - AFI register description
> > > + * @value: value to be written to the register
> > > + * @regid: Register id for the register to be written
> > > + */
> > > +struct zynqmp_afi_fpga {
> > > +	u32 value;
> > > +	u32 regid;
> > > +};
> > > +
> > > +static int zynqmp_afi_fpga_probe(struct platform_device *pdev)
> > > +{
> > > +	struct zynqmp_afi_fpga *zynqmp_afi_fpga;
> > > +	struct device_node *np = pdev->dev.of_node;
> > > +	int i, entries, ret;
> > > +	u32 reg, val;
> > > +
> > > +	zynqmp_afi_fpga = devm_kzalloc(&pdev->dev,
> > > +				       sizeof(*zynqmp_afi_fpga), GFP_KERNEL);
> > > +	if (!zynqmp_afi_fpga)
> > > +		return -ENOMEM;
> > > +	platform_set_drvdata(pdev, zynqmp_afi_fpga);
> > > +
> > > +	entries = of_property_count_u32_elems(np, "config-afi");
> > > +	if (!entries || (entries % 2)) {
> > > +		dev_err(&pdev->dev, "Invalid number of registers\n");
> > > +		return -EINVAL;
> > > +	}
> > > +
> > > +	for (i = 0; i < entries / 2; i++) {
> > > +		ret = of_property_read_u32_index(np, "config-afi", i * 2,
> > &reg);
> > > +		if (ret) {
> > > +			dev_err(&pdev->dev, "failed to read register\n");
> > > +			return -EINVAL;
> > > +		}
> > > +		ret = of_property_read_u32_index(np, "config-afi", i * 2 + 1,
> > > +						 &val);
> > > +		if (ret) {
> > > +			dev_err(&pdev->dev, "failed to read value\n");
> > > +			return -EINVAL;
> > > +		}
> > > +		ret = zynqmp_pm_afi(reg, val);
> > > +		if (ret < 0) {
> > > +			dev_err(&pdev->dev, "AFI register write error %d\n",
> > > +				ret);
> > > +			return ret;
> > > +		}
> > > +	}
> > > +	return 0;
> > > +}
> > 
> > Again, why does this have to be in the kernel?  All it does is make a
> > single call to the hardware based on some values read from the device
> > tree.  Can't you do this from userspace?
> > 
> For every PL design has its own PS-PL configuration.

What is a "PL design", and what is a "PS-PL configuration"?  :)

> This driver will be used by the overlay framework for configuring the interface after programming the FPGA and before probing the drivers that are present in the PL.

Again, I have no idea what this means at all.

And again, why does this have to be done in the kernel?  All you are
doing is sending some random values read in DT down to a hardware
device.   What requires a kernel driver for this?

thanks,

greg k-h


From narmstrong at baylibre.com  Tue Apr 20 16:33:52 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Tue, 20 Apr 2021 17:33:52 +0200
Subject: [PATCH v11 2/4] arm64: dts: mt8183: Add node for the Mali GPU
In-Reply-To: <20210126091747.v11.2.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid>
References: <20210126011759.1605641-1-drinkcat@chromium.org>
 <20210126091747.v11.2.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid>
Message-ID: <1a37f9be-8ec8-893a-e2fc-f0739948f71f@baylibre.com>

On 26/01/2021 02:17, Nicolas Boichat wrote:
> Add a basic GPU node for mt8183.
> 
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> ---
> The binding we use with out-of-tree Mali drivers includes more
> clocks, this is used for devfreq: the out-of-tree driver switches
> clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
> switches clk_mux back to clk_main_parent:
> (see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
> clocks =
>         <&topckgen CLK_TOP_MFGPLL_CK>,
>         <&topckgen CLK_TOP_MUX_MFG>,
>         <&clk26m>,
>         <&mfgcfg CLK_MFG_BG3D>;
> clock-names =
>         "clk_main_parent",
>         "clk_mux",
>         "clk_sub_parent",
>         "subsys_mfg_cg";
> (based on discussions, this probably belongs in the clock core)
> 
> This only matters for devfreq, that is disabled anyway as we don't
> have platform-specific code to handle >1 supplies.
> 
> Changes in v11:
>  - mt8183*.dts: remove incorrect supply-names
> 
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
>  - Add gpu regulators to kukui dtsi as well.
>  - Power domains are now attached to spm, not scpsys
>  - Drop R-B.
> 
> Changes in v5:
>  - Rename "2d" power domain to "core2" (keep R-B again).
> 
> Changes in v4:
>  - Add power-domain-names to describe the 3 domains.
>    (kept Alyssa's reviewed-by as the change is minor)
> 
> Changes in v3: None
> Changes in v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu at .
> 
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
>  3 files changed, 115 insertions(+)
> 

If you re-spin, you can also add the same changes to mt8183-pumpkin.dts :
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index eb6e595c2975..cc23e5df391e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -68,6 +68,11 @@ &auxadc {
        status = "okay";
 };

+&gpu {
+       mali-supply = <&mt6358_vgpu_reg>;
+       sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c_pins_0>;

I did a boot-test of the platform with panfrost and drm-misc-next and it worked fine.

Thanks,
Neil

> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> index cba2d8933e79..1cfbea5a0101 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -42,6 +42,11 @@ &auxadc {
>  	status = "okay";
>  };
>  
> +&gpu {
> +	mali-supply = <&mt6358_vgpu_reg>;
> +	sram-supply = <&mt6358_vsram_gpu_reg>;
> +};
> +
>  &i2c0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&i2c_pins_0>;
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index bf2ad1294dd3..a38315b604df 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -249,6 +249,11 @@ &cpu7 {
>  	proc-supply = <&mt6358_vproc11_reg>;
>  };
>  
> +&gpu {
> +	mali-supply = <&mt6358_vgpu_reg>;
> +	sram-supply = <&mt6358_vsram_gpu_reg>;
> +};
> +
>  &i2c0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&i2c0_pins>;
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7..5430e05e18a0 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -964,6 +964,111 @@ mfgcfg: syscon at 13000000 {
>  			#clock-cells = <1>;
>  		};
>  
> +		gpu: gpu at 13040000 {
> +			compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
> +			reg = <0 0x13040000 0 0x4000>;
> +			interrupts =
> +				<GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> +				<GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> +				<GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> +			interrupt-names = "job", "mmu", "gpu";
> +
> +			clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> +
> +			power-domains =
> +				<&spm MT8183_POWER_DOMAIN_MFG_CORE0>,
> +				<&spm MT8183_POWER_DOMAIN_MFG_CORE1>,
> +				<&spm MT8183_POWER_DOMAIN_MFG_2D>;
> +			power-domain-names = "core0", "core1", "core2";
> +
> +			operating-points-v2 = <&gpu_opp_table>;
> +		};
> +
> +		gpu_opp_table: opp_table0 {
> +			compatible = "operating-points-v2";
> +			opp-shared;
> +
> +			opp-300000000 {
> +				opp-hz = /bits/ 64 <300000000>;
> +				opp-microvolt = <625000>, <850000>;
> +			};
> +
> +			opp-320000000 {
> +				opp-hz = /bits/ 64 <320000000>;
> +				opp-microvolt = <631250>, <850000>;
> +			};
> +
> +			opp-340000000 {
> +				opp-hz = /bits/ 64 <340000000>;
> +				opp-microvolt = <637500>, <850000>;
> +			};
> +
> +			opp-360000000 {
> +				opp-hz = /bits/ 64 <360000000>;
> +				opp-microvolt = <643750>, <850000>;
> +			};
> +
> +			opp-380000000 {
> +				opp-hz = /bits/ 64 <380000000>;
> +				opp-microvolt = <650000>, <850000>;
> +			};
> +
> +			opp-400000000 {
> +				opp-hz = /bits/ 64 <400000000>;
> +				opp-microvolt = <656250>, <850000>;
> +			};
> +
> +			opp-420000000 {
> +				opp-hz = /bits/ 64 <420000000>;
> +				opp-microvolt = <662500>, <850000>;
> +			};
> +
> +			opp-460000000 {
> +				opp-hz = /bits/ 64 <460000000>;
> +				opp-microvolt = <675000>, <850000>;
> +			};
> +
> +			opp-500000000 {
> +				opp-hz = /bits/ 64 <500000000>;
> +				opp-microvolt = <687500>, <850000>;
> +			};
> +
> +			opp-540000000 {
> +				opp-hz = /bits/ 64 <540000000>;
> +				opp-microvolt = <700000>, <850000>;
> +			};
> +
> +			opp-580000000 {
> +				opp-hz = /bits/ 64 <580000000>;
> +				opp-microvolt = <712500>, <850000>;
> +			};
> +
> +			opp-620000000 {
> +				opp-hz = /bits/ 64 <620000000>;
> +				opp-microvolt = <725000>, <850000>;
> +			};
> +
> +			opp-653000000 {
> +				opp-hz = /bits/ 64 <653000000>;
> +				opp-microvolt = <743750>, <850000>;
> +			};
> +
> +			opp-698000000 {
> +				opp-hz = /bits/ 64 <698000000>;
> +				opp-microvolt = <768750>, <868750>;
> +			};
> +
> +			opp-743000000 {
> +				opp-hz = /bits/ 64 <743000000>;
> +				opp-microvolt = <793750>, <893750>;
> +			};
> +
> +			opp-800000000 {
> +				opp-hz = /bits/ 64 <800000000>;
> +				opp-microvolt = <825000>, <925000>;
> +			};
> +		};
> +
>  		mmsys: syscon at 14000000 {
>  			compatible = "mediatek,mt8183-mmsys", "syscon";
>  			reg = <0 0x14000000 0 0x1000>;
> 



From linux at fw-web.de  Tue Apr 20 16:54:10 2021
From: linux at fw-web.de (Frank Wunderlich)
Date: Tue, 20 Apr 2021 17:54:10 +0200
Subject: [PATCH v2] thermal: mediatek: add sensors-support
Message-ID: <20210420155410.132141-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w at public-files.de>

add HWMON-support to mediateks thermal driver to allow lm-sensors
userspace tools read soc temperature

Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
---
v2: drop ifdef and used devm_thermal_add_hwmon_sysfs
---
 drivers/thermal/mtk_thermal.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 149c6d7fd5a0..32be8a715c7d 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -23,6 +23,8 @@
 #include <linux/reset.h>
 #include <linux/types.h>
 
+#include "thermal_hwmon.h"
+
 /* AUXADC Registers */
 #define AUXADC_CON1_SET_V	0x008
 #define AUXADC_CON1_CLR_V	0x00c
@@ -1087,6 +1089,11 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 		goto err_disable_clk_peri_therm;
 	}
 
+	tzdev->tzp->no_hwmon = false;
+	ret = devm_thermal_add_hwmon_sysfs(tzdev);
+	if (ret)
+		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
+
 	return 0;
 
 err_disable_clk_peri_therm:
-- 
2.25.1



From robh+dt at kernel.org  Tue Apr 20 16:54:36 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 10:54:36 -0500
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
Message-ID: <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>

On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
<alexandre.torgue at foss.st.com> wrote:
>
>
>
> On 4/20/21 4:45 PM, Rob Herring wrote:
> > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > <alexandre.torgue at foss.st.com> wrote:
> >>
> >> Hi,
> >
> > Greg or Sasha won't know what to do with this. Not sure who follows
> > the stable list either. Quentin sent the patch, but is not the author.
> > Given the patch in question is about consistency between EFI memory
> > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > help (Ard B for starters).
>
> Ok thanks for the tips. I add Ard in the loop.

Sigh. If it was only Ard I was suggesting I would have done that
myself. Now everyone on the patch in question and relevant lists are
Cc'ed.

>
> Ard, let me know if other people have to be directly added or if I have
> to resend to another mailing list.
>
> thanks
> alex
>
> >
> >>
> >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> >> reserved-memory regions are no more "reserved" and make part of the
> >> kernel System RAM. This causes allocation failure for devices which try
> >> to take a reserved-memory region.
> >>
> >> It has been introduced by the following path:
> >>
> >> "fdt: Properly handle "no-map" field in the memory region
> >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> >>
> >> Reverting this patch it's fine.
> >>
> >> I add part of my DT (something is maybe wrong inside):
> >>
> >> memory at c0000000 {
> >>          reg = <0xc0000000 0x20000000>;
> >> };
> >>
> >> reserved-memory {
> >>          #address-cells = <1>;
> >>          #size-cells = <1>;
> >>          ranges;
> >>
> >>          gpu_reserved: gpu at d4000000 {
> >>                  reg = <0xd4000000 0x4000000>;
> >>                  no-map;
> >>          };
> >> };
> >>
> >> Sorry if this issue has already been raised and discussed.
> >>
> >> Thanks
> >> alex


From david at redhat.com  Tue Apr 20 16:57:57 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 17:57:57 +0200
Subject: [PATCH v1 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210420090925.7457-4-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-4-rppt@kernel.org>
Message-ID: <29b51a80-1543-fcec-6f5b-5ae21b78e1e9@redhat.com>

On 20.04.21 11:09, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
> 
> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> linear map vs those that require ioremap() to access them.
> 
> Introduce a dedicated pfn_is_map_memory() wrapper for
> memblock_is_map_memory() to perform such check and use it where
> appropriate.
> 
> Using a wrapper allows to avoid cyclic include dependencies.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   arch/arm64/include/asm/memory.h | 2 +-
>   arch/arm64/include/asm/page.h   | 1 +
>   arch/arm64/kvm/mmu.c            | 2 +-
>   arch/arm64/mm/init.c            | 6 ++++++
>   arch/arm64/mm/ioremap.c         | 4 ++--
>   arch/arm64/mm/mmu.c             | 2 +-
>   6 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..194f9f993d30 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>   
>   #define virt_addr_valid(addr)	({					\
>   	__typeof__(addr) __addr = __tag_reset(addr);			\
> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>   })
>   
>   void dump_mem_limit(void);
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 012cffc574e8..99a6da91f870 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>   typedef struct page *pgtable_t;
>   
>   extern int pfn_valid(unsigned long);
> +extern int pfn_is_map_memory(unsigned long);
>   
>   #include <asm/memory.h>
>   
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..23dd99e29b23 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>   
>   static bool kvm_is_device_pfn(unsigned long pfn)
>   {
> -	return !pfn_valid(pfn);
> +	return !pfn_is_map_memory(pfn);
>   }
>   
>   /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..c54e329aca15 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> +int pfn_is_map_memory(unsigned long pfn)
> +{

I think you might have to add (see pfn_valid())

if (PHYS_PFN(PFN_PHYS(pfn)) != pfn)
	return 0;

to catch false positives.

> +	return memblock_is_map_memory(PFN_PHYS(pfn));
> +}
> +EXPORT_SYMBOL(pfn_is_map_memory);
> +
>   static phys_addr_t memory_limit = PHYS_ADDR_MAX;
>   
>   /*
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index b5e83c46b23e..b7c81dacabf0 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
>   	/*
>   	 * Don't allow RAM to be mapped.
>   	 */
> -	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> +	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
>   		return NULL;
>   
>   	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> @@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
>   void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
>   {
>   	/* For normal memory we already have a cacheable mapping. */
> -	if (pfn_valid(__phys_to_pfn(phys_addr)))
> +	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
>   		return (void __iomem *)__phys_to_virt(phys_addr);
>   
>   	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 5d9550fdb9cf..26045e9adbd7 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
>   pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>   			      unsigned long size, pgprot_t vma_prot)
>   {
> -	if (!pfn_valid(pfn))
> +	if (!pfn_is_map_memory(pfn))
>   		return pgprot_noncached(vma_prot);
>   	else if (file->f_flags & O_SYNC)
>   		return pgprot_writecombine(vma_prot);
> 

As discussed, in the future it would be nice if we could just rely on 
the memmap state. There are cases where pfn_is_map_memory() will now be 
slower than pfn_valid() -- e.g., we don't check for valid_section() in 
case of CONFIG_SPARSEMEM. This would apply where pfn_valid() would have 
returned "0".

As we're not creating the direct map, kern_addr_valid() shouldn't need 
love. It'd be some kind of ugly if some generic code used by arm64 would 
be relying in case of arm64 on pfn_valid() to return the expected 
result; I doubt it.

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From david at redhat.com  Tue Apr 20 17:00:55 2021
From: david at redhat.com (David Hildenbrand)
Date: Tue, 20 Apr 2021 18:00:55 +0200
Subject: [PATCH v1 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210420090925.7457-5-rppt@kernel.org>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-5-rppt@kernel.org>
Message-ID: <8e7171e7-a85c-6066-4ab6-d2bc98ec103b@redhat.com>

On 20.04.21 11:09, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>    verify that there is actual physical memory that corresponds to a pfn
>    which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>    linear map and until the previous commit the struct pages representing
>    these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   arch/arm64/Kconfig   | 3 ---
>   arch/arm64/mm/init.c | 4 ++--
>   2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>   	def_bool y
>   	depends on NUMA
>   
> -config HOLES_IN_ZONE
> -	def_bool y
> -
>   source "kernel/Kconfig.hz"
>   
>   config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index c54e329aca15..370f33765b64 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>   
>   	/*
>   	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>   	 * addresses will always fail. Even the normal hotplugged
>   	 * memory will never have MEMBLOCK_NOMAP flag set in their
>   	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>   		return pfn_section_valid(ms, pfn);
>   }
>   #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> 

What are the steps needed to get rid of custom pfn_valid() completely?

I'd assume we would have to stop freeing parts of the mem map during 
boot. How relevant is that for arm64 nowadays, especially with reduced 
section sizes?

-- 
Thanks,

David / dhildenb



From christophe.leroy at csgroup.eu  Tue Apr 20 17:05:44 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Tue, 20 Apr 2021 18:05:44 +0200
Subject: [PATCH v4 19/20] mips: Convert to GENERIC_CMDLINE
In-Reply-To: <20210409012349.GG3981976@zorba>
References: <cover.1617375802.git.christophe.leroy@csgroup.eu>
 <a01b6cdbae01fff77e26f7a5c40ee5260e1952b5.1617375802.git.christophe.leroy@csgroup.eu>
 <20210406173836.GW2469518@zorba>
 <20210408190408.GA1724284@robh.at.kernel.org>
 <20210409012349.GG3981976@zorba>
Message-ID: <d92f99bf-20b7-a4b6-3d86-5b859e42cad8@csgroup.eu>



Le 09/04/2021 ? 03:23, Daniel Walker a ?crit?:
> On Thu, Apr 08, 2021 at 02:04:08PM -0500, Rob Herring wrote:
>> On Tue, Apr 06, 2021 at 10:38:36AM -0700, Daniel Walker wrote:
>>> On Fri, Apr 02, 2021 at 03:18:21PM +0000, Christophe Leroy wrote:
>>>> -config CMDLINE_BOOL
>>>> -	bool "Built-in kernel command line"
>>>> -	help
>>>> -	  For most systems, it is firmware or second stage bootloader that
>>>> -	  by default specifies the kernel command line options.  However,
>>>> -	  it might be necessary or advantageous to either override the
>>>> -	  default kernel command line or add a few extra options to it.
>>>> -	  For such cases, this option allows you to hardcode your own
>>>> -	  command line options directly into the kernel.  For that, you
>>>> -	  should choose 'Y' here, and fill in the extra boot arguments
>>>> -	  in CONFIG_CMDLINE.
>>>> -
>>>> -	  The built-in options will be concatenated to the default command
>>>> -	  line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
>>>> -	  command line will be ignored and replaced by the built-in string.
>>>> -
>>>> -	  Most MIPS systems will normally expect 'N' here and rely upon
>>>> -	  the command line from the firmware or the second-stage bootloader.
>>>> -
>>>
>>>
>>> See how you complained that I have CMDLINE_BOOL in my changed, and you think it
>>> shouldn't exist.
>>>
>>> Yet here mips has it, and you just deleted it with no feature parity in your
>>> changes for this.
>>
>> AFAICT, CMDLINE_BOOL equates to a non-empty or empty CONFIG_CMDLINE. You
>> seem to need it just because you have CMDLINE_PREPEND and
>> CMDLINE_APPEND. If that's not it, what feature is missing? CMDLINE_BOOL
>> is not a feature, but an implementation detail.
> 
> Not true.
> 
> It makes it easier to turn it all off inside the Kconfig , so it's for usability
> and multiple architecture have it even with just CMDLINE as I was commenting
> here.
> 

Among the 13 architectures having CONFIG_CMDLINE, todayb only 6 have a CONFIG_CMDLINE_BOOL in addition:

arch/arm/Kconfig:config CMDLINE
arch/arm64/Kconfig:config CMDLINE
arch/hexagon/Kconfig:config CMDLINE
arch/microblaze/Kconfig:config CMDLINE
arch/mips/Kconfig.debug:config CMDLINE
arch/nios2/Kconfig:config CMDLINE
arch/openrisc/Kconfig:config CMDLINE
arch/powerpc/Kconfig:config CMDLINE
arch/riscv/Kconfig:config CMDLINE
arch/sh/Kconfig:config CMDLINE
arch/sparc/Kconfig:config CMDLINE
arch/x86/Kconfig:config CMDLINE
arch/xtensa/Kconfig:config CMDLINE

arch/microblaze/Kconfig:config CMDLINE_BOOL
arch/mips/Kconfig.debug:config CMDLINE_BOOL
arch/nios2/Kconfig:config CMDLINE_BOOL
arch/sparc/Kconfig:config CMDLINE_BOOL
arch/x86/Kconfig:config CMDLINE_BOOL
arch/xtensa/Kconfig:config CMDLINE_BOOL


In the begining I hesitated about the CMDLINE_BOOL, at the end I decided to go the same way as what 
is done today in the kernel for initramfs with CONFIG_INITRAMFS_SOURCE.

The problem I see within adding CONFIG_CMDLINE_BOOL for every architecture which don't have it today 
is that when doing a "make oldconfig" on their custom configs, thousands of users will loose their 
CMDLINE without notice.

When we do the other way round, removing CONFIG_CMDLINE_BOOL on the 6 architectures that have it 
today will have no impact on existing config.

Also, in order to avoid tons of #ifdefs in the code as mandated by Kernel Codying Style ?21, we have 
to have CONFIG_CMDLINE defined at all time, so at the end CONFIG_CMDLINE_BOOL is really redundant 
with an empty CONFIG_CMDLINE.

Unlike you, the approach I took for my series is to minimise the impact on existing implementation 
and existing configurations as much as possible.

I know you have a different approach where you break every existing config anyway.

https://www.kernel.org/doc/html/latest/process/coding-style.html#conditional-compilation

Christophe


From ardb at kernel.org  Tue Apr 20 17:10:27 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Tue, 20 Apr 2021 18:10:27 +0200
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
Message-ID: <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>

On Tue, 20 Apr 2021 at 17:54, Rob Herring <robh+dt at kernel.org> wrote:
>
> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
> <alexandre.torgue at foss.st.com> wrote:
> >
> >
> >
> > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > > <alexandre.torgue at foss.st.com> wrote:
> > >>
> > >> Hi,
> > >
> > > Greg or Sasha won't know what to do with this. Not sure who follows
> > > the stable list either. Quentin sent the patch, but is not the author.
> > > Given the patch in question is about consistency between EFI memory
> > > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > > help (Ard B for starters).
> >
> > Ok thanks for the tips. I add Ard in the loop.
>
> Sigh. If it was only Ard I was suggesting I would have done that
> myself. Now everyone on the patch in question and relevant lists are
> Cc'ed.
>

Thanks for the cc.

> >
> > Ard, let me know if other people have to be directly added or if I have
> > to resend to another mailing list.
> >
> > thanks
> > alex
> >
> > >
> > >>
> > >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> > >> reserved-memory regions are no more "reserved" and make part of the
> > >> kernel System RAM. This causes allocation failure for devices which try
> > >> to take a reserved-memory region.
> > >>
> > >> It has been introduced by the following path:
> > >>
> > >> "fdt: Properly handle "no-map" field in the memory region
> > >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> > >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> > >>

Why was this backported? It doesn't look like a bugfix to me.

> > >> Reverting this patch it's fine.
> > >>
> > >> I add part of my DT (something is maybe wrong inside):
> > >>
> > >> memory at c0000000 {
> > >>          reg = <0xc0000000 0x20000000>;
> > >> };
> > >>
> > >> reserved-memory {
> > >>          #address-cells = <1>;
> > >>          #size-cells = <1>;
> > >>          ranges;
> > >>
> > >>          gpu_reserved: gpu at d4000000 {
> > >>                  reg = <0xd4000000 0x4000000>;
> > >>                  no-map;
> > >>          };
> > >> };
> > >>
> > >> Sorry if this issue has already been raised and discussed.
> > >>

Could you explain why it fails? The region is clearly part of system
memory, and tagged as no-map, so the patch in itself is not
unreasonable. However, we obviously have code that relies on how the
region is represented in /proc/iomem, so it would be helpful to get
some insight into why this is the case.

In any case, the mere fact that this causes a regression should be
sufficient justification to revert/withdraw it from v5.4, as I don't
see a reason why it was merged there in the first place. (It has no
fixes tag or cc:stable)


From robh at kernel.org  Tue Apr 20 17:18:55 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 11:18:55 -0500
Subject: [PATCH 1/5] PCI: qcom: add support for IPQ60xx PCIe controller
In-Reply-To: <c6ff03d1377ea9b5ff40ab283c884aeff6254dd9.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
 <c6ff03d1377ea9b5ff40ab283c884aeff6254dd9.1618916235.git.baruch@tkos.co.il>
Message-ID: <20210420161855.GA3402221@robh.at.kernel.org>

On Tue, Apr 20, 2021 at 02:21:36PM +0300, Baruch Siach wrote:
> From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
> 
> IPQ60xx series of SoCs have one port of PCIe gen 3. Add support for that
> platform.
> 
> The code is based on downstream Codeaurora kernel v5.4. Split out the
> registers access part from .init into .post_init. Registers are only
> accessible after phy_power_on().
> 
> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 279 +++++++++++++++++++++++++
>  1 file changed, 279 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 8a7a300163e5..3e27de744738 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -41,6 +41,31 @@
>  #define L23_CLK_RMV_DIS				BIT(2)
>  #define L1_CLK_RMV_DIS				BIT(1)
>  
> +#define PCIE_ATU_CR1_OUTBOUND_6_GEN3		0xC00
> +#define PCIE_ATU_CR2_OUTBOUND_6_GEN3		0xC04
> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3	0xC08
> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3	0xC0C
> +#define PCIE_ATU_LIMIT_OUTBOUND_6_GEN3		0xC10
> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3	0xC14
> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3	0xC18
> +
> +#define PCIE_ATU_CR1_OUTBOUND_7_GEN3		0xE00
> +#define PCIE_ATU_CR2_OUTBOUND_7_GEN3		0xE04
> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3	0xE08
> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3	0xE0C
> +#define PCIE_ATU_LIMIT_OUTBOUND_7_GEN3		0xE10
> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3	0xE14
> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3 	0xE18

ATU registers are standard DWC registers. Plus upstream now dynamically 
detects how many ATU regions there are.

> +
> +#define PCIE20_COMMAND_STATUS			0x04
> +#define BUS_MASTER_EN				0x7
> +#define PCIE20_DEVICE_CONTROL2_STATUS2		0x98
> +#define PCIE_CAP_CPL_TIMEOUT_DISABLE		0x10

All PCI standard registers.

> +#define PCIE30_GEN3_RELATED_OFF			0x890

Looks like a DWC port logic register. The define at a minimum goes in 
the common code. We probably already have one. Code touching the 
register should ideally be there too (hint: look at the other drivers). 

> +
> +#define RXEQ_RGRDLESS_RXTS			BIT(13)
> +#define GEN3_ZRXDC_NONCOMPL			BIT(0)
> +
>  #define PCIE20_PARF_PHY_CTRL			0x40
>  #define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK	GENMASK(20, 16)
>  #define PHY_CTRL_PHY_TX0_TERM_OFFSET(x)		((x) << 16)
> @@ -52,6 +77,10 @@
>  #define PCIE20_PARF_DBI_BASE_ADDR		0x168
>  #define PCIE20_PARF_SLV_ADDR_SPACE_SIZE		0x16C
>  #define PCIE20_PARF_MHI_CLOCK_RESET_CTRL	0x174
> +#define AHB_CLK_EN				BIT(0)
> +#define MSTR_AXI_CLK_EN				BIT(1)
> +#define BYPASS					BIT(4)
> +
>  #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT	0x178
>  #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2	0x1A8
>  #define PCIE20_PARF_LTSSM			0x1B0
> @@ -94,6 +123,12 @@
>  #define SLV_ADDR_SPACE_SZ			0x10000000
>  
>  #define PCIE20_LNK_CONTROL2_LINK_STATUS2	0xa0
> +#define PCIE_CAP_CURR_DEEMPHASIS		BIT(16)
> +#define SPEED_GEN1				0x1
> +#define SPEED_GEN2				0x2
> +#define SPEED_GEN3				0x3
> +#define AXI_CLK_RATE				200000000
> +#define RCHNG_CLK_RATE				100000000
>  
>  #define DEVICE_TYPE_RC				0x4
>  
> @@ -168,6 +203,15 @@ struct qcom_pcie_resources_2_7_0 {
>  	struct clk *pipe_clk;
>  };
>  
> +struct qcom_pcie_resources_2_9_0 {
> +	struct clk *iface;
> +	struct clk *axi_m_clk;
> +	struct clk *axi_s_clk;
> +	struct clk *axi_bridge_clk;
> +	struct clk *rchng_clk;
> +	struct reset_control *rst[8];
> +};
> +
>  union qcom_pcie_resources {
>  	struct qcom_pcie_resources_1_0_0 v1_0_0;
>  	struct qcom_pcie_resources_2_1_0 v2_1_0;
> @@ -175,6 +219,7 @@ union qcom_pcie_resources {
>  	struct qcom_pcie_resources_2_3_3 v2_3_3;
>  	struct qcom_pcie_resources_2_4_0 v2_4_0;
>  	struct qcom_pcie_resources_2_7_0 v2_7_0;
> +	struct qcom_pcie_resources_2_9_0 v2_9_0;
>  };
>  
>  struct qcom_pcie;
> @@ -1266,6 +1311,225 @@ static void qcom_pcie_post_deinit_2_7_0(struct qcom_pcie *pcie)
>  	clk_disable_unprepare(res->pipe_clk);
>  }
>  
> +static int qcom_pcie_get_resources_2_9_0(struct qcom_pcie *pcie)
> +{
> +	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
> +	struct dw_pcie *pci = pcie->pci;
> +	struct device *dev = pci->dev;
> +	int i;
> +	const char *rst_names[] = { "pipe", "sleep", "sticky",
> +				    "axi_m", "axi_s", "ahb",
> +				    "axi_m_sticky", "axi_s_sticky", };
> +
> +	res->iface = devm_clk_get(dev, "iface");
> +	if (IS_ERR(res->iface))
> +		return PTR_ERR(res->iface);
> +
> +	res->axi_m_clk = devm_clk_get(dev, "axi_m");
> +	if (IS_ERR(res->axi_m_clk))
> +		return PTR_ERR(res->axi_m_clk);
> +
> +	res->axi_s_clk = devm_clk_get(dev, "axi_s");
> +	if (IS_ERR(res->axi_s_clk))
> +		return PTR_ERR(res->axi_s_clk);
> +
> +	res->axi_bridge_clk = devm_clk_get(dev, "axi_bridge");
> +	if (IS_ERR(res->axi_bridge_clk))
> +		return PTR_ERR(res->axi_bridge_clk);
> +
> +	res->rchng_clk = devm_clk_get(dev, "rchng");
> +	if (IS_ERR(res->rchng_clk))
> +		return PTR_ERR(res->rchng_clk);
> +
> +	for (i = 0; i < ARRAY_SIZE(rst_names); i++) {
> +		res->rst[i] = devm_reset_control_get(dev, rst_names[i]);

Don't we have a bulk api for this? Clocks too.

> +		if (IS_ERR(res->rst[i])) {
> +			return PTR_ERR(res->rst[i]);
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static void qcom_pcie_deinit_2_9_0(struct qcom_pcie *pcie)
> +{
> +	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
> +
> +	clk_disable_unprepare(res->axi_m_clk);
> +	clk_disable_unprepare(res->axi_s_clk);
> +	clk_disable_unprepare(res->axi_bridge_clk);
> +	clk_disable_unprepare(res->rchng_clk);
> +	clk_disable_unprepare(res->iface);
> +}
> +
> +static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie)
> +{
> +	struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0;
> +	struct device *dev = pcie->pci->dev;
> +	int i, ret;
> +
> +	for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
> +		ret = reset_control_assert(res->rst[i]);
> +		if (ret) {
> +			dev_err(dev, "reset #%d assert failed (%d)\n", i, ret);
> +			return ret;
> +		}
> +	}
> +
> +	usleep_range(2000, 2500);
> +
> +	for (i = 0; i < ARRAY_SIZE(res->rst); i++) {
> +		ret = reset_control_deassert(res->rst[i]);
> +		if (ret) {
> +			dev_err(dev, "reset #%d deassert failed (%d)\n", i,
> +				ret);
> +			return ret;
> +		}
> +	}
> +
> +	/*
> +	 * Don't have a way to see if the reset has completed.
> +	 * Wait for some time.
> +	 */
> +	usleep_range(2000, 2500);
> +
> +	ret = clk_prepare_enable(res->iface);
> +	if (ret) {
> +		dev_err(dev, "cannot prepare/enable core clock\n");
> +		goto err_clk_iface;
> +	}
> +
> +	ret = clk_prepare_enable(res->axi_m_clk);
> +	if (ret) {
> +		dev_err(dev, "cannot prepare/enable core clock\n");
> +		goto err_clk_axi_m;
> +	}
> +
> +	ret = clk_set_rate(res->axi_m_clk, AXI_CLK_RATE);
> +	if (ret) {
> +		dev_err(dev, "MClk rate set failed (%d)\n", ret);
> +		goto err_clk_axi_m;
> +	}
> +
> +	ret = clk_prepare_enable(res->axi_s_clk);
> +	if (ret) {
> +		dev_err(dev, "cannot prepare/enable axi slave clock\n");
> +		goto err_clk_axi_s;
> +	}
> +
> +	ret = clk_set_rate(res->axi_s_clk, AXI_CLK_RATE);
> +	if (ret) {
> +		dev_err(dev, "SClk rate set failed (%d)\n", ret);
> +		goto err_clk_axi_s;
> +	}
> +
> +	ret = clk_prepare_enable(res->axi_bridge_clk);
> +	if (ret) {
> +		dev_err(dev, "cannot prepare/enable axi bridge clock\n");
> +		goto err_clk_axi_bridge;
> +	}
> +
> +	ret = clk_prepare_enable(res->rchng_clk);
> +	if (ret) {
> +		dev_err(dev, "cannot prepare/enable rchng clock\n");
> +		goto err_clk_rchng;
> +	}
> +
> +	ret = clk_set_rate(res->rchng_clk, RCHNG_CLK_RATE);
> +	if (ret) {
> +		dev_err(dev, "rchng_clk rate set failed (%d)\n", ret);
> +		goto err_clk_rchng;
> +	}
> +
> +	return 0;
> +
> +err_clk_rchng:
> +	clk_disable_unprepare(res->rchng_clk);
> +err_clk_axi_bridge:
> +	clk_disable_unprepare(res->axi_bridge_clk);
> +err_clk_axi_s:
> +	clk_disable_unprepare(res->axi_s_clk);
> +err_clk_axi_m:
> +	clk_disable_unprepare(res->axi_m_clk);
> +err_clk_iface:
> +	clk_disable_unprepare(res->iface);
> +	/*
> +	 * Not checking for failure, will anyway return
> +	 * the original failure in 'ret'.
> +	 */
> +	for (i = 0; i < ARRAY_SIZE(res->rst); i++)
> +		reset_control_assert(res->rst[i]);
> +
> +	return ret;
> +}
> +
> +static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie)
> +{
> +	struct dw_pcie *pci = pcie->pci;
> +	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> +	u32 val;
> +	int i;
> +
> +	writel(SLV_ADDR_SPACE_SZ,
> +		pcie->parf + PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE);
> +
> +	val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> +	val &= ~BIT(0);

What's BIT(0)?

> +	writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> +
> +	writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
> +
> +	writel(DEVICE_TYPE_RC, pcie->parf + PCIE20_PARF_DEVICE_TYPE);
> +	writel(BYPASS | MSTR_AXI_CLK_EN | AHB_CLK_EN,
> +		pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> +	writel(RXEQ_RGRDLESS_RXTS | GEN3_ZRXDC_NONCOMPL,
> +		pci->dbi_base + PCIE30_GEN3_RELATED_OFF);
> +
> +	writel(MST_WAKEUP_EN | SLV_WAKEUP_EN | MSTR_ACLK_CGC_DIS
> +		| SLV_ACLK_CGC_DIS | CORE_CLK_CGC_DIS |
> +		AUX_PWR_DET | L23_CLK_RMV_DIS | L1_CLK_RMV_DIS,
> +		pcie->parf + PCIE20_PARF_SYS_CTRL);
> +
> +	writel(0, pcie->parf + PCIE20_PARF_Q2A_FLUSH);
> +
> +	writel(BUS_MASTER_EN, pci->dbi_base + PCIE20_COMMAND_STATUS);

Pretty sure the DWC core or PCI core does this already.

> +
> +	writel(DBI_RO_WR_EN, pci->dbi_base + PCIE20_MISC_CONTROL_1_REG);
> +	writel(PCIE_CAP_LINK1_VAL, pci->dbi_base + offset + PCI_EXP_SLTCAP);
> +
> +	/* Configure PCIe link capabilities for ASPM */
> +	val = readl(pci->dbi_base + offset + PCI_EXP_LNKCAP);
> +	val &= ~PCI_EXP_LNKCAP_ASPMS;
> +	writel(val, pci->dbi_base + offset + PCI_EXP_LNKCAP);
> +
> +	writel(PCIE_CAP_CPL_TIMEOUT_DISABLE, pci->dbi_base +
> +		PCIE20_DEVICE_CONTROL2_STATUS2);
> +
> +	writel(PCIE_CAP_CURR_DEEMPHASIS | SPEED_GEN3,
> +			pci->dbi_base + offset + PCI_EXP_DEVCTL2);

This all looks like stuff that should be in the DWC core code. Maybe we 
need an ASPM disable quirk or something? That's probably somewhat 
common.

> +
> +	for (i = 0;i < 256;i++)
> +		writel(0x0, pcie->parf + PCIE20_PARF_BDF_TO_SID_TABLE_N
> +				+ (4 * i));
> +

> +	writel(0x4, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_6_GEN3);
> +	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_6_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3);
> +	writel(0x00107FFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_6_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3);
> +	writel(0x5, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_7_GEN3);
> +	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_7_GEN3);
> +	writel(0x200000, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3);
> +	writel(0x7FFFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_7_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3);
> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3);

This should all be coming from 'ranges' in the DT. If not, why not?

If you haven't caught the theme yet, everything outside of PARF register 
accesses had better have a good explanation why they can't be in common 
code.

> +
> +	return 0;
> +}
> +
>  static int qcom_pcie_link_up(struct dw_pcie *pci)
>  {
>  	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> @@ -1456,6 +1720,15 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
>  	.config_sid = qcom_pcie_config_sid_sm8250,
>  };
>  
> +/* Qcom IP rev.: 2.9.0  Synopsys IP rev.: 5.00a */
> +static const struct qcom_pcie_ops ops_2_9_0 = {
> +	.get_resources = qcom_pcie_get_resources_2_9_0,
> +	.init = qcom_pcie_init_2_9_0,
> +	.post_init = qcom_pcie_post_init_2_9_0,
> +	.deinit = qcom_pcie_deinit_2_9_0,
> +	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
> +};
> +
>  static const struct dw_pcie_ops dw_pcie_ops = {
>  	.link_up = qcom_pcie_link_up,
>  	.start_link = qcom_pcie_start_link,
> @@ -1508,6 +1781,11 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>  		goto err_pm_runtime_put;
>  	}
>  
> +	/* We need ATU for .post_init */
> +	pci->atu_base = devm_platform_ioremap_resource_byname(pdev, "atu");

The DWC core handles this now.

> +	if (IS_ERR(pci->atu_base))
> +		pci->atu_base = NULL;
> +
>  	pcie->phy = devm_phy_optional_get(dev, "pciephy");
>  	if (IS_ERR(pcie->phy)) {
>  		ret = PTR_ERR(pcie->phy);
> @@ -1555,6 +1833,7 @@ static const struct of_device_id qcom_pcie_match[] = {
>  	{ .compatible = "qcom,pcie-qcs404", .data = &ops_2_4_0 },
>  	{ .compatible = "qcom,pcie-sdm845", .data = &ops_2_7_0 },
>  	{ .compatible = "qcom,pcie-sm8250", .data = &ops_1_9_0 },
> +	{ .compatible = "qcom,pcie-ipq6018", .data = &ops_2_9_0 },
>  	{ }
>  };
>  
> -- 
> 2.30.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From maz at kernel.org  Tue Apr 20 17:19:50 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 20 Apr 2021 17:19:50 +0100
Subject: [PATCH] KVM: arm64: Fix Function ID typo for PTP_KVM service
In-Reply-To: <20210417113804.1992-1-yuzenghui@huawei.com>
References: <20210417113804.1992-1-yuzenghui@huawei.com>
Message-ID: <161893556835.531653.5778639003429203651.b4-ty@kernel.org>

On Sat, 17 Apr 2021 19:38:04 +0800, Zenghui Yu wrote:
> Per include/linux/arm-smccc.h, the Function ID of PTP_KVM service is
> defined as ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID. Fix the typo in
> documentation to keep the git grep consistent.

Applied to kvm-arm64/ptp, thanks!

[1/1] KVM: arm64: Fix Function ID typo for PTP_KVM service
      commit: 182a71a3653c4324672fd87e4384fae2fbd63269

Cheers,

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




From robh at kernel.org  Tue Apr 20 17:24:55 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 11:24:55 -0500
Subject: [PATCH v3 1/5] dt-bindings: display: mediatek, hdmi: Convert to
 use graph schema
In-Reply-To: <20210419073244.2678688-2-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
 <20210419073244.2678688-2-narmstrong@baylibre.com>
Message-ID: <20210420162455.GA3431175@robh.at.kernel.org>

On Mon, 19 Apr 2021 09:32:40 +0200, Neil Armstrong wrote:
> Update the mediatek,dpi binding to use the graph schema.
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  .../display/mediatek/mediatek,cec.yaml        |  51 +++++++
>  .../display/mediatek/mediatek,hdmi-ddc.yaml   |  57 ++++++++
>  .../display/mediatek/mediatek,hdmi.txt        | 136 ------------------
>  .../display/mediatek/mediatek,hdmi.yaml       | 132 +++++++++++++++++
>  4 files changed, 240 insertions(+), 136 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml
>  delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
>  create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 17:25:10 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 11:25:10 -0500
Subject: [PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi,
 hdmi-ddc and cec bindings
In-Reply-To: <20210419073244.2678688-3-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
 <20210419073244.2678688-3-narmstrong@baylibre.com>
Message-ID: <20210420162510.GA3431608@robh.at.kernel.org>

On Mon, 19 Apr 2021 09:32:41 +0200, Neil Armstrong wrote:
> Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings.
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,cec.yaml       | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml  | 1 +
>  .../devicetree/bindings/display/mediatek/mediatek,hdmi.yaml      | 1 +
>  3 files changed, 3 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 17:25:37 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 11:25:37 -0500
Subject: [PATCH v3 10/11] dt-bindings: clock: stm32mp1 new compatible for
 secure rcc
In-Reply-To: <20210419093852.14978-11-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
 <20210419093852.14978-11-gabriel.fernandez@foss.st.com>
Message-ID: <20210420162537.GA3432298@robh.at.kernel.org>

On Mon, 19 Apr 2021 11:38:51 +0200, gabriel.fernandez at foss.st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> Introduce new compatible string "st,stm32mp1-rcc-secure" for
> stm32mp1 clock driver when the device is configured with RCC
> security support hardened.
> 
> Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---
>  .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml          | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From f.fainelli at gmail.com  Tue Apr 20 17:33:56 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 20 Apr 2021 09:33:56 -0700
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
Message-ID: <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>



On 4/20/2021 9:10 AM, Ard Biesheuvel wrote:
> On Tue, 20 Apr 2021 at 17:54, Rob Herring <robh+dt at kernel.org> wrote:
>>
>> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
>> <alexandre.torgue at foss.st.com> wrote:
>>>
>>>
>>>
>>> On 4/20/21 4:45 PM, Rob Herring wrote:
>>>> On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
>>>> <alexandre.torgue at foss.st.com> wrote:
>>>>>
>>>>> Hi,
>>>>
>>>> Greg or Sasha won't know what to do with this. Not sure who follows
>>>> the stable list either. Quentin sent the patch, but is not the author.
>>>> Given the patch in question is about consistency between EFI memory
>>>> map boot and DT memory map boot, copying EFI knowledgeable folks would
>>>> help (Ard B for starters).
>>>
>>> Ok thanks for the tips. I add Ard in the loop.
>>
>> Sigh. If it was only Ard I was suggesting I would have done that
>> myself. Now everyone on the patch in question and relevant lists are
>> Cc'ed.
>>
> 
> Thanks for the cc.
> 
>>>
>>> Ard, let me know if other people have to be directly added or if I have
>>> to resend to another mailing list.
>>>
>>> thanks
>>> alex
>>>
>>>>
>>>>>
>>>>> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
>>>>> reserved-memory regions are no more "reserved" and make part of the
>>>>> kernel System RAM. This causes allocation failure for devices which try
>>>>> to take a reserved-memory region.
>>>>>
>>>>> It has been introduced by the following path:
>>>>>
>>>>> "fdt: Properly handle "no-map" field in the memory region
>>>>> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
>>>>> which replace memblock_remove by memblock_mark_nomap in no-map case.
>>>>>
> 
> Why was this backported? It doesn't look like a bugfix to me.
> 
>>>>> Reverting this patch it's fine.
>>>>>
>>>>> I add part of my DT (something is maybe wrong inside):
>>>>>
>>>>> memory at c0000000 {
>>>>>          reg = <0xc0000000 0x20000000>;
>>>>> };
>>>>>
>>>>> reserved-memory {
>>>>>          #address-cells = <1>;
>>>>>          #size-cells = <1>;
>>>>>          ranges;
>>>>>
>>>>>          gpu_reserved: gpu at d4000000 {
>>>>>                  reg = <0xd4000000 0x4000000>;
>>>>>                  no-map;
>>>>>          };
>>>>> };
>>>>>
>>>>> Sorry if this issue has already been raised and discussed.
>>>>>
> 
> Could you explain why it fails? The region is clearly part of system
> memory, and tagged as no-map, so the patch in itself is not
> unreasonable. However, we obviously have code that relies on how the
> region is represented in /proc/iomem, so it would be helpful to get
> some insight into why this is the case.

I do wonder as well, we have a 32MB "no-map" reserved memory region on
our platforms located at 0xfe000000. Without the offending commit,
/proc/iomem looks like this:

40000000-fdffefff : System RAM
  40008000-40ffffff : Kernel code
  41e00000-41ef1d77 : Kernel data
100000000-13fffffff : System RAM

and with the patch applied, we have this:

40000000-fdffefff : System RAM
  40008000-40ffffff : Kernel code
  41e00000-41ef3db7 : Kernel data
fdfff000-ffffffff : System RAM
100000000-13fffffff : System RAM

so we can now see that the region 0xfe000000 - 0xfffffff is also cobbled
up with the preceding region which is a mailbox between Linux and the
secure monitor at 0xfdfff000 and of size 4KB. It seems like there is

The memblock=debug outputs is also different:

[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0xfdfff000 reserved size = 0x7ce4d20d
[    0.000000]  memory.cnt  = 0x2
[    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
0xbdfff000 bytes flags: 0x0
[    0.000000]  memory[0x1]     [0x00000100000000-0x0000013fffffff],
0x40000000 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
0xb495 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef1d77],
0x1cf1d78 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
0x100000 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
0x50000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x000000c2c00000-0x000000fdbfffff],
0x3b000000 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
0x40000000 bytes flags: 0x0

[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x100000000 reserved size = 0x7ca4f24d
[    0.000000]  memory.cnt  = 0x3
[    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
0xbdfff000 bytes flags: 0x0
[    0.000000]  memory[0x1]     [0x000000fdfff000-0x000000ffffffff],
0x2001000 bytes flags: 0x4
[    0.000000]  memory[0x2]     [0x00000100000000-0x0000013fffffff],
0x40000000 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
0xb495 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef3db7],
0x1cf3db8 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
0x100000 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
0x50000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x000000c3000000-0x000000fdbfffff],
0x3ac00000 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
0x40000000 bytes flags: 0x0

in the second case we can clearly see that the 32MB no-map region is now
considered as usable RAM.

Hope this helps.

> 
> In any case, the mere fact that this causes a regression should be
> sufficient justification to revert/withdraw it from v5.4, as I don't
> see a reason why it was merged there in the first place. (It has no
> fixes tag or cc:stable)

Agreed, however that means we still need to find out whether a more
recent kernel is also broken, I should be able to tell you that a little
later.
-- 
Florian


From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:33 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:33 +0200
Subject: [PATCH 01/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Itop Core
Message-ID: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>

The RTC on S5M8767 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
index 4583d342af39..b3726d4d7d93 100644
--- a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -163,6 +163,7 @@ s5m8767: pmic at 66 {
 						 <1025000>, <950000>,
 						 <918750>, <900000>,
 						 <875000>, <831250>;
+		wakeup-source;
 
 		regulators {
 			ldo1_reg: LDO1 {
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:34 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:34 +0200
Subject: [PATCH 02/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Origen4412
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-2-krzysztof.kozlowski@canonical.com>

The RTC on S5M8767 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos4412-origen.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412-origen.dts b/arch/arm/boot/dts/exynos4412-origen.dts
index e1f6de53e20e..5479ef09f9f3 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -144,6 +144,7 @@ pmic at 66 {
 						 <1200000>, <1200000>,
 						 <1200000>, <1200000>,
 						 <1200000>, <1200000>;
+		wakeup-source;
 
 		s5m8767_osc: clocks {
 			compatible = "samsung,s5m8767-clk";
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:35 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:35 +0200
Subject: [PATCH 03/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Arndale
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-3-krzysztof.kozlowski@canonical.com>

The RTC on S5M8767 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos5250-arndale.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index a161f6237c7f..a771542e28b8 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -218,6 +218,7 @@ pmic at 66 {
 		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&s5m8767_irq>;
+		wakeup-source;
 
 		vinb1-supply = <&main_dc_reg>;
 		vinb2-supply = <&main_dc_reg>;
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:36 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:36 +0200
Subject: [PATCH 04/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Odroid XU
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-4-krzysztof.kozlowski@canonical.com>

The RTC on Maxim max77802 PMIC can wakeup the system from suspend to
RAM.  Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos5410-odroidxu.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts b/arch/arm/boot/dts/exynos5410-odroidxu.dts
index 949c0721cdb4..884fef55836c 100644
--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
+++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
@@ -190,6 +190,7 @@ max77802: pmic at 9 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&max77802_irq>, <&pmic_dvs_1>, <&pmic_dvs_2>,
 			    <&pmic_dvs_3>;
+		wakeup-source;
 		#clock-cells = <1>;
 
 		inl1-supply = <&buck5_reg>;
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:37 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:37 +0200
Subject: [PATCH 05/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Midas
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-5-krzysztof.kozlowski@canonical.com>

The RTC on Maxim max77686 PMIC can wakeup the system from suspend to
RAM.  Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos4412-midas.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412-midas.dtsi b/arch/arm/boot/dts/exynos4412-midas.dtsi
index fc77c1bfd844..968c7943653e 100644
--- a/arch/arm/boot/dts/exynos4412-midas.dtsi
+++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
@@ -668,6 +668,7 @@ max77686: pmic at 9 {
 		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-0 = <&max77686_irq>;
 		pinctrl-names = "default";
+		wakeup-source;
 		reg = <0x09>;
 		#clock-cells = <1>;
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:38 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:38 +0200
Subject: [PATCH 06/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Odroid X/U3
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-6-krzysztof.kozlowski@canonical.com>

The RTC on Maxim max77686 PMIC can wakeup the system from suspend to
RAM.  Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 5bd05866d7a3..5b1d4591b35c 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -282,6 +282,7 @@ max77686: pmic at 9 {
 		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&max77686_irq>;
+		wakeup-source;
 		reg = <0x09>;
 		#clock-cells = <1>;
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:39 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:39 +0200
Subject: [PATCH 07/11] ARM: dts: exynos: enable PMIC wakeup from suspend on P4
 Note
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-7-krzysztof.kozlowski@canonical.com>

The RTC on Maxim max77686 PMIC can wakeup the system from suspend to
RAM.  Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos4412-p4note.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412-p4note.dtsi b/arch/arm/boot/dts/exynos4412-p4note.dtsi
index 9e750890edb8..22c3086e0076 100644
--- a/arch/arm/boot/dts/exynos4412-p4note.dtsi
+++ b/arch/arm/boot/dts/exynos4412-p4note.dtsi
@@ -325,6 +325,7 @@ max77686: pmic at 9 {
 		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-0 = <&max77686_irq>;
 		pinctrl-names = "default";
+		wakeup-source;
 		reg = <0x09>;
 		#clock-cells = <1>;
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:40 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:40 +0200
Subject: [PATCH 08/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Arndale Octa
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-8-krzysztof.kozlowski@canonical.com>

The RTC on S2MPS11 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos5420-arndale-octa.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 1aad4859c5f1..dfc7f14f5772 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -352,6 +352,7 @@ pmic at 66 {
 		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&s2mps11_irq>;
+		wakeup-source;
 
 		s2mps11_osc: clocks {
 			compatible = "samsung,s2mps11-clk";
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:41 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:41 +0200
Subject: [PATCH 09/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 SMDK5420
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-9-krzysztof.kozlowski@canonical.com>

The RTC on S2MPS11 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index d506da9fa661..a4f0e3ffedbd 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -132,6 +132,7 @@ &hsi2c_4 {
 	pmic at 66 {
 		compatible = "samsung,s2mps11-pmic";
 		reg = <0x66>;
+		wakeup-source;
 
 		s2mps11_osc: clocks {
 			compatible = "samsung,s2mps11-clk";
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:42 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:42 +0200
Subject: [PATCH 10/11] ARM: dts: exynos: enable PMIC wakeup from suspend on
 Odroid XU3/XU4 family
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-10-krzysztof.kozlowski@canonical.com>

The RTC on S2MPS11 PMIC on Odroid XU3/XU4 family of boards can wakeup
the system from suspend to RAM.  Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index 6d690b1db099..e7958dbecfd2 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -512,6 +512,7 @@ pmic at 66 {
 		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&s2mps11_irq>;
+		wakeup-source;
 
 		s2mps11_osc: clocks {
 			compatible = "samsung,s2mps11-clk";
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Tue Apr 20 17:49:43 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Tue, 20 Apr 2021 18:49:43 +0200
Subject: [PATCH 11/11] arm64: dts: exynos: enable PMIC wakeup from suspend on
 TM2
In-Reply-To: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
References: <20210420164943.11152-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210420164943.11152-11-krzysztof.kozlowski@canonical.com>

The RTC on S2MPS13 PMIC can wakeup the system from suspend to RAM.
Add a generic property for this.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 773d9abe3a44..cbcc01a66aab 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -391,6 +391,7 @@ pmic at 66 {
 		interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
 		reg = <0x66>;
 		samsung,s2mps11-wrstbi-ground;
+		wakeup-source;
 
 		s2mps13_osc: clocks {
 			compatible = "samsung,s2mps13-clk";
-- 
2.25.1



From liam.howlett at oracle.com  Tue Apr 20 17:50:13 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Tue, 20 Apr 2021 16:50:13 +0000
Subject: [PATCH 3/3] arch/arm64/kernel/traps: Use find_vma_intersection() in
 traps for setting si_code
In-Reply-To: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
Message-ID: <20210420165001.3790670-3-Liam.Howlett@Oracle.com>

find_vma() will continue to search upwards until the end of the virtual
memory space.  This means the si_code would almost never be set to
SEGV_MAPERR even when the address falls outside of any VMA.  The result
is that the si_code is not reliable as it may or may not be set to the
correct result, depending on where the address falls in the address
space.

Using find_vma_intersection() allows for what is intended by only
returning a VMA if it falls within the range provided, in this case a
window of 1.

Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---
 arch/arm64/kernel/traps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index a05d34f0e82a..a44007904a64 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
 void arm64_notify_segfault(unsigned long addr)
 {
 	int code;
+	unsigned long ut_addr = untagged_addr(addr);
 
 	mmap_read_lock(current->mm);
-	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
+	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
 		code = SEGV_MAPERR;
 	else
 		code = SEGV_ACCERR;
-- 
2.30.2


From liam.howlett at oracle.com  Tue Apr 20 17:50:13 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Tue, 20 Apr 2021 16:50:13 +0000
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn() sometime
 returns the wrong signals
In-Reply-To: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
Message-ID: <20210420165001.3790670-2-Liam.Howlett@Oracle.com>

arm64_notify_segfault() was used to force a SIGSEGV in all error cases
in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
There is now a better sig handler to use which does not search the VMA
address space and return a slightly incorrect error code.  Restore the
older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
the case of !access_ok(), simply return SIGSEGV with si_code
SEGV_ACCERR.

This change requires exporting arm64_notfiy_die() to the arm64 traps.h

Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
failing to deliver signal)
Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---
 arch/arm64/include/asm/traps.h |  2 ++
 arch/arm64/kernel/signal.c     |  8 ++++++--
 arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
index 54f32a0675df..9b76144fcba6 100644
--- a/arch/arm64/include/asm/traps.h
+++ b/arch/arm64/include/asm/traps.h
@@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
 void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
 void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
 void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
+void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
+		      int sicode, unsigned long far, int err);
 
 /*
  * Move regs->pc to next instruction and do necessary setup before it
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 6237486ff6bb..9fde6dc760c3 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
 	frame = (struct rt_sigframe __user *)regs->sp;
 
 	if (!access_ok(frame, sizeof (*frame)))
-		goto badframe;
+		goto e_access;
 
 	if (restore_sigframe(regs, frame))
 		goto badframe;
@@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
 	return regs->regs[0];
 
 badframe:
-	arm64_notify_segfault(regs->sp);
+	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
+	return 0;
+
+e_access:
+	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
 	return 0;
 }
 
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 2f507f565c48..af8b6c0eb8aa 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -248,7 +248,7 @@ COMPAT_SYSCALL_DEFINE0(sigreturn)
 	frame = (struct compat_sigframe __user *)regs->compat_sp;
 
 	if (!access_ok(frame, sizeof (*frame)))
-		goto badframe;
+		goto e_access;
 
 	if (compat_restore_sigframe(regs, frame))
 		goto badframe;
@@ -256,7 +256,12 @@ COMPAT_SYSCALL_DEFINE0(sigreturn)
 	return regs->regs[0];
 
 badframe:
-	arm64_notify_segfault(regs->compat_sp);
+	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL,
+			 regs->compat_sp, 0);
+	return 0;
+
+e_access:
+	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->compat_sp, 0);
 	return 0;
 }
 
@@ -279,7 +284,7 @@ COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 	frame = (struct compat_rt_sigframe __user *)regs->compat_sp;
 
 	if (!access_ok(frame, sizeof (*frame)))
-		goto badframe;
+		goto e_access;
 
 	if (compat_restore_sigframe(regs, &frame->sig))
 		goto badframe;
@@ -290,7 +295,12 @@ COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 	return regs->regs[0];
 
 badframe:
-	arm64_notify_segfault(regs->compat_sp);
+	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL,
+			 regs->compat_sp, 0);
+	return 0;
+
+e_access:
+	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->compat_sp, 0);
 	return 0;
 }
 
-- 
2.30.2


From liam.howlett at oracle.com  Tue Apr 20 17:50:12 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Tue, 20 Apr 2021 16:50:12 +0000
Subject: [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal
 generation
Message-ID: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>

arm64_notify_segfault() was written to decide on the si_code from the
assembly emulation of the swp_handler(), but was also used for the
signal generation from failed access_ok() and unaligned instructions.

When access_ok() fails, there is no need to search for the offending
address in the VMA space.  Instead, simply set the error to SIGSEGV with
si_code SEGV_ACCERR.

Change the return code from emulate_swpX() when there is an unaligned
pointer so the caller can differentiate from the EFAULT.  It is
unnecessary to search the VMAs in the case of an unaligned pointer.
This change uses SIGSEGV and SEGV_ACCERR instead of SIGBUS to keep with
what was returned before.

Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
---
 arch/arm64/kernel/armv8_deprecated.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index 0e86e8b9cedd..f424082b3455 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -324,7 +324,7 @@ static int emulate_swpX(unsigned int address, unsigned int *data,
 	if ((type != TYPE_SWPB) && (address & 0x3)) {
 		/* SWP to unaligned address not permitted */
 		pr_debug("SWP instruction on unaligned pointer!\n");
-		return -EFAULT;
+		return -ENXIO;
 	}
 
 	while (1) {
@@ -406,15 +406,17 @@ static int swp_handler(struct pt_regs *regs, u32 instr)
 	user_ptr = (const void __user *)(unsigned long)(address & ~3);
 	if (!access_ok(user_ptr, 4)) {
 		pr_debug("SWP{B} emulation: access to 0x%08x not allowed!\n",
-			address);
-		goto fault;
+			 address);
+		goto e_access;
 	}
 
 	res = emulate_swpX(address, &data, type);
-	if (res == -EFAULT)
-		goto fault;
-	else if (res == 0)
+	if (!res)
 		regs->user_regs.regs[destreg] = data;
+	else if (res == -EFAULT)
+		goto e_fault;
+	else if (res = -ENXIO) /* Unaligned pointer */
+		goto e_align;
 
 ret:
 	if (type == TYPE_SWPB)
@@ -428,10 +430,14 @@ static int swp_handler(struct pt_regs *regs, u32 instr)
 	arm64_skip_faulting_instruction(regs, 4);
 	return 0;
 
-fault:
+e_fault:
 	pr_debug("SWP{B} emulation: access caused memory abort!\n");
 	arm64_notify_segfault(address);
+	return 0;
 
+e_align:
+e_access:
+	force_signal_inject(SIGSEGV, SEGV_ACCERR, address, 0);
 	return 0;
 }
 
-- 
2.30.2


From thierry.reding at gmail.com  Tue Apr 20 17:52:28 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:28 +0200
Subject: [PATCH 00/10] memory: tegra: Driver unification
Message-ID: <20210420165237.3523732-1-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Hi,

this set of patches converges the feature sets of the pre-Tegra186 and
the post-Tegra186 memory controller drivers such that newer chips can
take advantage of some features that were previously only implemented
on earlier chips.

Note that this looks a bit daunting from a diffstat point of view but
the bulk of this is in the first two patches that basically shuffle
around where some of the per-memory-client register definitions are
located, hence the big number of changed lines.

I haven't done any exhaustive testing on the series yet, but wanted to
get some feedback on the general idea. I'll queue up this up for our
automated testing in the coming days.

Thierry

Thierry Reding (10):
  memory: tegra: Consolidate register fields
  memory: tegra: Unify struct tegra_mc across SoC generations
  memory: tegra: Push suspend/resume into SoC drivers
  memory: tegra: Make per-SoC setup more generic
  memory: tegra: Extract setup code into callback
  memory: tegra: Parameterize interrupt handler
  memory: tegra: Only initialize reset controller if available
  memory: tegra: Unify drivers
  memory: tegra: Add memory client IDs to tables
  memory: tegra: Split Tegra194 data into separate file

 drivers/iommu/tegra-smmu.c      |   16 +-
 drivers/memory/tegra/Makefile   |    6 +-
 drivers/memory/tegra/mc.c       |  324 +++----
 drivers/memory/tegra/mc.h       |   26 +
 drivers/memory/tegra/tegra114.c | 1245 +++++++++++++-----------
 drivers/memory/tegra/tegra124.c | 1306 ++++++++++++++-----------
 drivers/memory/tegra/tegra186.c | 1609 ++++++++-----------------------
 drivers/memory/tegra/tegra194.c | 1353 ++++++++++++++++++++++++++
 drivers/memory/tegra/tegra20.c  |  110 ++-
 drivers/memory/tegra/tegra210.c | 1433 ++++++++++++++-------------
 drivers/memory/tegra/tegra30.c  | 1292 ++++++++++++++-----------
 include/soc/tegra/mc.h          |   58 +-
 12 files changed, 4991 insertions(+), 3787 deletions(-)
 create mode 100644 drivers/memory/tegra/tegra194.c

-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:30 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:30 +0200
Subject: [PATCH 02/10] memory: tegra: Unify struct tegra_mc across SoC
 generations
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-3-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

As another step towards unifying both the Tegra210 (and earlier) and
Tegra186 (and later) memory controller drivers, unify the structures
that are used to represent them.

Note that this comes at a slight space penalty since some fields are
not used on all generations, but the benefits of unifying the driver
outweigh the downsides.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/tegra186.c | 1281 ++++++++++++++++++++-----------
 include/soc/tegra/mc.h          |   18 +-
 2 files changed, 852 insertions(+), 447 deletions(-)

diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index e25c954dde2e..8e77567d1378 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -9,6 +9,8 @@
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 
+#include <soc/tegra/mc.h>
+
 #if defined(CONFIG_ARCH_TEGRA_186_SOC)
 #include <dt-bindings/memory/tegra186-mc.h>
 #endif
@@ -17,47 +19,26 @@
 #include <dt-bindings/memory/tegra194-mc.h>
 #endif
 
-struct tegra186_mc_client {
-	const char *name;
-	unsigned int sid;
-	struct {
-		unsigned int override;
-		unsigned int security;
-	} regs;
-};
-
-struct tegra186_mc_soc {
-	const struct tegra186_mc_client *clients;
-	unsigned int num_clients;
-};
-
-struct tegra186_mc {
-	struct device *dev;
-	void __iomem *regs;
-
-	const struct tegra186_mc_soc *soc;
-};
-
-static void tegra186_mc_program_sid(struct tegra186_mc *mc)
+static void tegra186_mc_program_sid(struct tegra_mc *mc)
 {
 	unsigned int i;
 
 	for (i = 0; i < mc->soc->num_clients; i++) {
-		const struct tegra186_mc_client *client = &mc->soc->clients[i];
+		const struct tegra_mc_client *client = &mc->soc->clients[i];
 		u32 override, security;
 
-		override = readl(mc->regs + client->regs.override);
-		security = readl(mc->regs + client->regs.security);
+		override = readl(mc->regs + client->regs.sid.override);
+		security = readl(mc->regs + client->regs.sid.security);
 
 		dev_dbg(mc->dev, "client %s: override: %x security: %x\n",
 			client->name, override, security);
 
 		dev_dbg(mc->dev, "setting SID %u for %s\n", client->sid,
 			client->name);
-		writel(client->sid, mc->regs + client->regs.override);
+		writel(client->sid, mc->regs + client->regs.sid.override);
 
-		override = readl(mc->regs + client->regs.override);
-		security = readl(mc->regs + client->regs.security);
+		override = readl(mc->regs + client->regs.sid.override);
+		security = readl(mc->regs + client->regs.sid.security);
 
 		dev_dbg(mc->dev, "client %s: override: %x security: %x\n",
 			client->name, override, security);
@@ -65,1457 +46,1867 @@ static void tegra186_mc_program_sid(struct tegra186_mc *mc)
 }
 
 #if defined(CONFIG_ARCH_TEGRA_186_SOC)
-static const struct tegra186_mc_client tegra186_mc_clients[] = {
+static const struct tegra_mc_client tegra186_mc_clients[] = {
 	{
 		.name = "ptcr",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x000,
-			.security = 0x004,
+			.sid = {
+				.override = 0x000,
+				.security = 0x004,
+			},
 		},
 	}, {
 		.name = "afir",
 		.sid = TEGRA186_SID_AFI,
 		.regs = {
-			.override = 0x070,
-			.security = 0x074,
+			.sid = {
+				.override = 0x070,
+				.security = 0x074,
+			},
 		},
 	}, {
 		.name = "hdar",
 		.sid = TEGRA186_SID_HDA,
 		.regs = {
-			.override = 0x0a8,
-			.security = 0x0ac,
+			.sid = {
+				.override = 0x0a8,
+				.security = 0x0ac,
+			},
 		},
 	}, {
 		.name = "host1xdmar",
 		.sid = TEGRA186_SID_HOST1X,
 		.regs = {
-			.override = 0x0b0,
-			.security = 0x0b4,
+			.sid = {
+				.override = 0x0b0,
+				.security = 0x0b4,
+			},
 		},
 	}, {
 		.name = "nvencsrd",
 		.sid = TEGRA186_SID_NVENC,
 		.regs = {
-			.override = 0x0e0,
-			.security = 0x0e4,
+			.sid = {
+				.override = 0x0e0,
+				.security = 0x0e4,
+			},
 		},
 	}, {
 		.name = "satar",
 		.sid = TEGRA186_SID_SATA,
 		.regs = {
-			.override = 0x0f8,
-			.security = 0x0fc,
+			.sid = {
+				.override = 0x0f8,
+				.security = 0x0fc,
+			},
 		},
 	}, {
 		.name = "mpcorer",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x138,
-			.security = 0x13c,
+			.sid = {
+				.override = 0x138,
+				.security = 0x13c,
+			},
 		},
 	}, {
 		.name = "nvencswr",
 		.sid = TEGRA186_SID_NVENC,
 		.regs = {
-			.override = 0x158,
-			.security = 0x15c,
+			.sid = {
+				.override = 0x158,
+				.security = 0x15c,
+			},
 		},
 	}, {
 		.name = "afiw",
 		.sid = TEGRA186_SID_AFI,
 		.regs = {
-			.override = 0x188,
-			.security = 0x18c,
+			.sid = {
+				.override = 0x188,
+				.security = 0x18c,
+			},
 		},
 	}, {
 		.name = "hdaw",
 		.sid = TEGRA186_SID_HDA,
 		.regs = {
-			.override = 0x1a8,
-			.security = 0x1ac,
+			.sid = {
+				.override = 0x1a8,
+				.security = 0x1ac,
+			},
 		},
 	}, {
 		.name = "mpcorew",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x1c8,
-			.security = 0x1cc,
+			.sid = {
+				.override = 0x1c8,
+				.security = 0x1cc,
+			},
 		},
 	}, {
 		.name = "sataw",
 		.sid = TEGRA186_SID_SATA,
 		.regs = {
-			.override = 0x1e8,
-			.security = 0x1ec,
+			.sid = {
+				.override = 0x1e8,
+				.security = 0x1ec,
+			},
 		},
 	}, {
 		.name = "ispra",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
-			.override = 0x220,
-			.security = 0x224,
+			.sid = {
+				.override = 0x220,
+				.security = 0x224,
+			},
 		},
 	}, {
 		.name = "ispwa",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
-			.override = 0x230,
-			.security = 0x234,
+			.sid = {
+				.override = 0x230,
+				.security = 0x234,
+			},
 		},
 	}, {
 		.name = "ispwb",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
-			.override = 0x238,
-			.security = 0x23c,
+			.sid = {
+				.override = 0x238,
+				.security = 0x23c,
+			},
 		},
 	}, {
 		.name = "xusb_hostr",
 		.sid = TEGRA186_SID_XUSB_HOST,
 		.regs = {
-			.override = 0x250,
-			.security = 0x254,
+			.sid = {
+				.override = 0x250,
+				.security = 0x254,
+			},
 		},
 	}, {
 		.name = "xusb_hostw",
 		.sid = TEGRA186_SID_XUSB_HOST,
 		.regs = {
-			.override = 0x258,
-			.security = 0x25c,
+			.sid = {
+				.override = 0x258,
+				.security = 0x25c,
+			},
 		},
 	}, {
 		.name = "xusb_devr",
 		.sid = TEGRA186_SID_XUSB_DEV,
 		.regs = {
-			.override = 0x260,
-			.security = 0x264,
+			.sid = {
+				.override = 0x260,
+				.security = 0x264,
+			},
 		},
 	}, {
 		.name = "xusb_devw",
 		.sid = TEGRA186_SID_XUSB_DEV,
 		.regs = {
-			.override = 0x268,
-			.security = 0x26c,
+			.sid = {
+				.override = 0x268,
+				.security = 0x26c,
+			},
 		},
 	}, {
 		.name = "tsecsrd",
 		.sid = TEGRA186_SID_TSEC,
 		.regs = {
-			.override = 0x2a0,
-			.security = 0x2a4,
+			.sid = {
+				.override = 0x2a0,
+				.security = 0x2a4,
+			},
 		},
 	}, {
 		.name = "tsecswr",
 		.sid = TEGRA186_SID_TSEC,
 		.regs = {
-			.override = 0x2a8,
-			.security = 0x2ac,
+			.sid = {
+				.override = 0x2a8,
+				.security = 0x2ac,
+			},
 		},
 	}, {
 		.name = "gpusrd",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
-			.override = 0x2c0,
-			.security = 0x2c4,
+			.sid = {
+				.override = 0x2c0,
+				.security = 0x2c4,
+			},
 		},
 	}, {
 		.name = "gpuswr",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
-			.override = 0x2c8,
-			.security = 0x2cc,
+			.sid = {
+				.override = 0x2c8,
+				.security = 0x2cc,
+			},
 		},
 	}, {
 		.name = "sdmmcra",
 		.sid = TEGRA186_SID_SDMMC1,
 		.regs = {
-			.override = 0x300,
-			.security = 0x304,
+			.sid = {
+				.override = 0x300,
+				.security = 0x304,
+			},
 		},
 	}, {
 		.name = "sdmmcraa",
 		.sid = TEGRA186_SID_SDMMC2,
 		.regs = {
-			.override = 0x308,
-			.security = 0x30c,
+			.sid = {
+				.override = 0x308,
+				.security = 0x30c,
+			},
 		},
 	}, {
 		.name = "sdmmcr",
 		.sid = TEGRA186_SID_SDMMC3,
 		.regs = {
-			.override = 0x310,
-			.security = 0x314,
+			.sid = {
+				.override = 0x310,
+				.security = 0x314,
+			},
 		},
 	}, {
 		.name = "sdmmcrab",
 		.sid = TEGRA186_SID_SDMMC4,
 		.regs = {
-			.override = 0x318,
-			.security = 0x31c,
+			.sid = {
+				.override = 0x318,
+				.security = 0x31c,
+			},
 		},
 	}, {
 		.name = "sdmmcwa",
 		.sid = TEGRA186_SID_SDMMC1,
 		.regs = {
-			.override = 0x320,
-			.security = 0x324,
+			.sid = {
+				.override = 0x320,
+				.security = 0x324,
+			},
 		},
 	}, {
 		.name = "sdmmcwaa",
 		.sid = TEGRA186_SID_SDMMC2,
 		.regs = {
-			.override = 0x328,
-			.security = 0x32c,
+			.sid = {
+				.override = 0x328,
+				.security = 0x32c,
+			},
 		},
 	}, {
 		.name = "sdmmcw",
 		.sid = TEGRA186_SID_SDMMC3,
 		.regs = {
-			.override = 0x330,
-			.security = 0x334,
+			.sid = {
+				.override = 0x330,
+				.security = 0x334,
+			},
 		},
 	}, {
 		.name = "sdmmcwab",
 		.sid = TEGRA186_SID_SDMMC4,
 		.regs = {
-			.override = 0x338,
-			.security = 0x33c,
+			.sid = {
+				.override = 0x338,
+				.security = 0x33c,
+			},
 		},
 	}, {
 		.name = "vicsrd",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
-			.override = 0x360,
-			.security = 0x364,
+			.sid = {
+				.override = 0x360,
+				.security = 0x364,
+			},
 		},
 	}, {
 		.name = "vicswr",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
-			.override = 0x368,
-			.security = 0x36c,
+			.sid = {
+				.override = 0x368,
+				.security = 0x36c,
+			},
 		},
 	}, {
 		.name = "viw",
 		.sid = TEGRA186_SID_VI,
 		.regs = {
-			.override = 0x390,
-			.security = 0x394,
+			.sid = {
+				.override = 0x390,
+				.security = 0x394,
+			},
 		},
 	}, {
 		.name = "nvdecsrd",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
-			.override = 0x3c0,
-			.security = 0x3c4,
+			.sid = {
+				.override = 0x3c0,
+				.security = 0x3c4,
+			},
 		},
 	}, {
 		.name = "nvdecswr",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
-			.override = 0x3c8,
-			.security = 0x3cc,
+			.sid = {
+				.override = 0x3c8,
+				.security = 0x3cc,
+			},
 		},
 	}, {
 		.name = "aper",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
-			.override = 0x3d0,
-			.security = 0x3d4,
+			.sid = {
+				.override = 0x3d0,
+				.security = 0x3d4,
+			},
 		},
 	}, {
 		.name = "apew",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
-			.override = 0x3d8,
-			.security = 0x3dc,
+			.sid = {
+				.override = 0x3d8,
+				.security = 0x3dc,
+			},
 		},
 	}, {
 		.name = "nvjpgsrd",
 		.sid = TEGRA186_SID_NVJPG,
 		.regs = {
-			.override = 0x3f0,
-			.security = 0x3f4,
+			.sid = {
+				.override = 0x3f0,
+				.security = 0x3f4,
+			},
 		},
 	}, {
 		.name = "nvjpgswr",
 		.sid = TEGRA186_SID_NVJPG,
 		.regs = {
-			.override = 0x3f8,
-			.security = 0x3fc,
+			.sid = {
+				.override = 0x3f8,
+				.security = 0x3fc,
+			},
 		},
 	}, {
 		.name = "sesrd",
 		.sid = TEGRA186_SID_SE,
 		.regs = {
-			.override = 0x400,
-			.security = 0x404,
+			.sid = {
+				.override = 0x400,
+				.security = 0x404,
+			},
 		},
 	}, {
 		.name = "seswr",
 		.sid = TEGRA186_SID_SE,
 		.regs = {
-			.override = 0x408,
-			.security = 0x40c,
+			.sid = {
+				.override = 0x408,
+				.security = 0x40c,
+			},
 		},
 	}, {
 		.name = "etrr",
 		.sid = TEGRA186_SID_ETR,
 		.regs = {
-			.override = 0x420,
-			.security = 0x424,
+			.sid = {
+				.override = 0x420,
+				.security = 0x424,
+			},
 		},
 	}, {
 		.name = "etrw",
 		.sid = TEGRA186_SID_ETR,
 		.regs = {
-			.override = 0x428,
-			.security = 0x42c,
+			.sid = {
+				.override = 0x428,
+				.security = 0x42c,
+			},
 		},
 	}, {
 		.name = "tsecsrdb",
 		.sid = TEGRA186_SID_TSECB,
 		.regs = {
-			.override = 0x430,
-			.security = 0x434,
+			.sid = {
+				.override = 0x430,
+				.security = 0x434,
+			},
 		},
 	}, {
 		.name = "tsecswrb",
 		.sid = TEGRA186_SID_TSECB,
 		.regs = {
-			.override = 0x438,
-			.security = 0x43c,
+			.sid = {
+				.override = 0x438,
+				.security = 0x43c,
+			},
 		},
 	}, {
 		.name = "gpusrd2",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
-			.override = 0x440,
-			.security = 0x444,
+			.sid = {
+				.override = 0x440,
+				.security = 0x444,
+			},
 		},
 	}, {
 		.name = "gpuswr2",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
-			.override = 0x448,
-			.security = 0x44c,
+			.sid = {
+				.override = 0x448,
+				.security = 0x44c,
+			},
 		},
 	}, {
 		.name = "axisr",
 		.sid = TEGRA186_SID_GPCDMA_0,
 		.regs = {
-			.override = 0x460,
-			.security = 0x464,
+			.sid = {
+				.override = 0x460,
+				.security = 0x464,
+			},
 		},
 	}, {
 		.name = "axisw",
 		.sid = TEGRA186_SID_GPCDMA_0,
 		.regs = {
-			.override = 0x468,
-			.security = 0x46c,
+			.sid = {
+				.override = 0x468,
+				.security = 0x46c,
+			},
 		},
 	}, {
 		.name = "eqosr",
 		.sid = TEGRA186_SID_EQOS,
 		.regs = {
-			.override = 0x470,
-			.security = 0x474,
+			.sid = {
+				.override = 0x470,
+				.security = 0x474,
+			},
 		},
 	}, {
 		.name = "eqosw",
 		.sid = TEGRA186_SID_EQOS,
 		.regs = {
-			.override = 0x478,
-			.security = 0x47c,
+			.sid = {
+				.override = 0x478,
+				.security = 0x47c,
+			},
 		},
 	}, {
 		.name = "ufshcr",
 		.sid = TEGRA186_SID_UFSHC,
 		.regs = {
-			.override = 0x480,
-			.security = 0x484,
+			.sid = {
+				.override = 0x480,
+				.security = 0x484,
+			},
 		},
 	}, {
 		.name = "ufshcw",
 		.sid = TEGRA186_SID_UFSHC,
 		.regs = {
-			.override = 0x488,
-			.security = 0x48c,
+			.sid = {
+				.override = 0x488,
+				.security = 0x48c,
+			},
 		},
 	}, {
 		.name = "nvdisplayr",
 		.sid = TEGRA186_SID_NVDISPLAY,
 		.regs = {
-			.override = 0x490,
-			.security = 0x494,
+			.sid = {
+				.override = 0x490,
+				.security = 0x494,
+			},
 		},
 	}, {
 		.name = "bpmpr",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
-			.override = 0x498,
-			.security = 0x49c,
+			.sid = {
+				.override = 0x498,
+				.security = 0x49c,
+			},
 		},
 	}, {
 		.name = "bpmpw",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
-			.override = 0x4a0,
-			.security = 0x4a4,
+			.sid = {
+				.override = 0x4a0,
+				.security = 0x4a4,
+			},
 		},
 	}, {
 		.name = "bpmpdmar",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
-			.override = 0x4a8,
-			.security = 0x4ac,
+			.sid = {
+				.override = 0x4a8,
+				.security = 0x4ac,
+			},
 		},
 	}, {
 		.name = "bpmpdmaw",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
-			.override = 0x4b0,
-			.security = 0x4b4,
+			.sid = {
+				.override = 0x4b0,
+				.security = 0x4b4,
+			},
 		},
 	}, {
 		.name = "aonr",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
-			.override = 0x4b8,
-			.security = 0x4bc,
+			.sid = {
+				.override = 0x4b8,
+				.security = 0x4bc,
+			},
 		},
 	}, {
 		.name = "aonw",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
-			.override = 0x4c0,
-			.security = 0x4c4,
+			.sid = {
+				.override = 0x4c0,
+				.security = 0x4c4,
+			},
 		},
 	}, {
 		.name = "aondmar",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
-			.override = 0x4c8,
-			.security = 0x4cc,
+			.sid = {
+				.override = 0x4c8,
+				.security = 0x4cc,
+			},
 		},
 	}, {
 		.name = "aondmaw",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
-			.override = 0x4d0,
-			.security = 0x4d4,
+			.sid = {
+				.override = 0x4d0,
+				.security = 0x4d4,
+			},
 		},
 	}, {
 		.name = "scer",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
-			.override = 0x4d8,
-			.security = 0x4dc,
+			.sid = {
+				.override = 0x4d8,
+				.security = 0x4dc,
+			},
 		},
 	}, {
 		.name = "scew",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
-			.override = 0x4e0,
-			.security = 0x4e4,
+			.sid = {
+				.override = 0x4e0,
+				.security = 0x4e4,
+			},
 		},
 	}, {
 		.name = "scedmar",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
-			.override = 0x4e8,
-			.security = 0x4ec,
+			.sid = {
+				.override = 0x4e8,
+				.security = 0x4ec,
+			},
 		},
 	}, {
 		.name = "scedmaw",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
-			.override = 0x4f0,
-			.security = 0x4f4,
+			.sid = {
+				.override = 0x4f0,
+				.security = 0x4f4,
+			},
 		},
 	}, {
 		.name = "apedmar",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
-			.override = 0x4f8,
-			.security = 0x4fc,
+			.sid = {
+				.override = 0x4f8,
+				.security = 0x4fc,
+			},
 		},
 	}, {
 		.name = "apedmaw",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
-			.override = 0x500,
-			.security = 0x504,
+			.sid = {
+				.override = 0x500,
+				.security = 0x504,
+			},
 		},
 	}, {
 		.name = "nvdisplayr1",
 		.sid = TEGRA186_SID_NVDISPLAY,
 		.regs = {
-			.override = 0x508,
-			.security = 0x50c,
+			.sid = {
+				.override = 0x508,
+				.security = 0x50c,
+			},
 		},
 	}, {
 		.name = "vicsrd1",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
-			.override = 0x510,
-			.security = 0x514,
+			.sid = {
+				.override = 0x510,
+				.security = 0x514,
+			},
 		},
 	}, {
 		.name = "nvdecsrd1",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
-			.override = 0x518,
-			.security = 0x51c,
+			.sid = {
+				.override = 0x518,
+				.security = 0x51c,
+			},
 		},
 	},
 };
 
-static const struct tegra186_mc_soc tegra186_mc_soc = {
+static const struct tegra_mc_soc tegra186_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra186_mc_clients),
 	.clients = tegra186_mc_clients,
 };
 #endif
 
 #if defined(CONFIG_ARCH_TEGRA_194_SOC)
-static const struct tegra186_mc_client tegra194_mc_clients[] = {
+static const struct tegra_mc_client tegra194_mc_clients[] = {
 	{
 		.name = "ptcr",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x000,
-			.security = 0x004,
+			.sid = {
+				.override = 0x000,
+				.security = 0x004,
+			},
 		},
 	}, {
 		.name = "miu7r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x008,
-			.security = 0x00c,
+			.sid = {
+				.override = 0x008,
+				.security = 0x00c,
+			},
 		},
 	}, {
 		.name = "miu7w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x010,
-			.security = 0x014,
+			.sid = {
+				.override = 0x010,
+				.security = 0x014,
+			},
 		},
 	}, {
 		.name = "hdar",
 		.sid = TEGRA194_SID_HDA,
 		.regs = {
-			.override = 0x0a8,
-			.security = 0x0ac,
+			.sid = {
+				.override = 0x0a8,
+				.security = 0x0ac,
+			},
 		},
 	}, {
 		.name = "host1xdmar",
 		.sid = TEGRA194_SID_HOST1X,
 		.regs = {
-			.override = 0x0b0,
-			.security = 0x0b4,
+			.sid = {
+				.override = 0x0b0,
+				.security = 0x0b4,
+			},
 		},
 	}, {
 		.name = "nvencsrd",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
-			.override = 0x0e0,
-			.security = 0x0e4,
+			.sid = {
+				.override = 0x0e0,
+				.security = 0x0e4,
+			},
 		},
 	}, {
 		.name = "satar",
 		.sid = TEGRA194_SID_SATA,
 		.regs = {
-			.override = 0x0f8,
-			.security = 0x0fc,
+			.sid = {
+				.override = 0x0f8,
+				.security = 0x0fc,
+			},
 		},
 	}, {
 		.name = "mpcorer",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x138,
-			.security = 0x13c,
+			.sid = {
+				.override = 0x138,
+				.security = 0x13c,
+			},
 		},
 	}, {
 		.name = "nvencswr",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
-			.override = 0x158,
-			.security = 0x15c,
+			.sid = {
+				.override = 0x158,
+				.security = 0x15c,
+			},
 		},
 	}, {
 		.name = "hdaw",
 		.sid = TEGRA194_SID_HDA,
 		.regs = {
-			.override = 0x1a8,
-			.security = 0x1ac,
+			.sid = {
+				.override = 0x1a8,
+				.security = 0x1ac,
+			},
 		},
 	}, {
 		.name = "mpcorew",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x1c8,
-			.security = 0x1cc,
+			.sid = {
+				.override = 0x1c8,
+				.security = 0x1cc,
+			},
 		},
 	}, {
 		.name = "sataw",
 		.sid = TEGRA194_SID_SATA,
 		.regs = {
-			.override = 0x1e8,
-			.security = 0x1ec,
+			.sid = {
+				.override = 0x1e8,
+				.security = 0x1ec,
+			},
 		},
 	}, {
 		.name = "ispra",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
-			.override = 0x220,
-			.security = 0x224,
+			.sid = {
+				.override = 0x220,
+				.security = 0x224,
+			},
 		},
 	}, {
 		.name = "ispfalr",
 		.sid = TEGRA194_SID_ISP_FALCON,
 		.regs = {
-			.override = 0x228,
-			.security = 0x22c,
+			.sid = {
+				.override = 0x228,
+				.security = 0x22c,
+			},
 		},
 	}, {
 		.name = "ispwa",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
-			.override = 0x230,
-			.security = 0x234,
+			.sid = {
+				.override = 0x230,
+				.security = 0x234,
+			},
 		},
 	}, {
 		.name = "ispwb",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
-			.override = 0x238,
-			.security = 0x23c,
+			.sid = {
+				.override = 0x238,
+				.security = 0x23c,
+			},
 		},
 	}, {
 		.name = "xusb_hostr",
 		.sid = TEGRA194_SID_XUSB_HOST,
 		.regs = {
-			.override = 0x250,
-			.security = 0x254,
+			.sid = {
+				.override = 0x250,
+				.security = 0x254,
+			},
 		},
 	}, {
 		.name = "xusb_hostw",
 		.sid = TEGRA194_SID_XUSB_HOST,
 		.regs = {
-			.override = 0x258,
-			.security = 0x25c,
+			.sid = {
+				.override = 0x258,
+				.security = 0x25c,
+			},
 		},
 	}, {
 		.name = "xusb_devr",
 		.sid = TEGRA194_SID_XUSB_DEV,
 		.regs = {
-			.override = 0x260,
-			.security = 0x264,
+			.sid = {
+				.override = 0x260,
+				.security = 0x264,
+			},
 		},
 	}, {
 		.name = "xusb_devw",
 		.sid = TEGRA194_SID_XUSB_DEV,
 		.regs = {
-			.override = 0x268,
-			.security = 0x26c,
+			.sid = {
+				.override = 0x268,
+				.security = 0x26c,
+			},
 		},
 	}, {
 		.name = "sdmmcra",
 		.sid = TEGRA194_SID_SDMMC1,
 		.regs = {
-			.override = 0x300,
-			.security = 0x304,
+			.sid = {
+				.override = 0x300,
+				.security = 0x304,
+			},
 		},
 	}, {
 		.name = "sdmmcr",
 		.sid = TEGRA194_SID_SDMMC3,
 		.regs = {
-			.override = 0x310,
-			.security = 0x314,
+			.sid = {
+				.override = 0x310,
+				.security = 0x314,
+			},
 		},
 	}, {
 		.name = "sdmmcrab",
 		.sid = TEGRA194_SID_SDMMC4,
 		.regs = {
-			.override = 0x318,
-			.security = 0x31c,
+			.sid = {
+				.override = 0x318,
+				.security = 0x31c,
+			},
 		},
 	}, {
 		.name = "sdmmcwa",
 		.sid = TEGRA194_SID_SDMMC1,
 		.regs = {
-			.override = 0x320,
-			.security = 0x324,
+			.sid = {
+				.override = 0x320,
+				.security = 0x324,
+			},
 		},
 	}, {
 		.name = "sdmmcw",
 		.sid = TEGRA194_SID_SDMMC3,
 		.regs = {
-			.override = 0x330,
-			.security = 0x334,
+			.sid = {
+				.override = 0x330,
+				.security = 0x334,
+			},
 		},
 	}, {
 		.name = "sdmmcwab",
 		.sid = TEGRA194_SID_SDMMC4,
 		.regs = {
-			.override = 0x338,
-			.security = 0x33c,
+			.sid = {
+				.override = 0x338,
+				.security = 0x33c,
+			},
 		},
 	}, {
 		.name = "vicsrd",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
-			.override = 0x360,
-			.security = 0x364,
+			.sid = {
+				.override = 0x360,
+				.security = 0x364,
+			},
 		},
 	}, {
 		.name = "vicswr",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
-			.override = 0x368,
-			.security = 0x36c,
+			.sid = {
+				.override = 0x368,
+				.security = 0x36c,
+			},
 		},
 	}, {
 		.name = "viw",
 		.sid = TEGRA194_SID_VI,
 		.regs = {
-			.override = 0x390,
-			.security = 0x394,
+			.sid = {
+				.override = 0x390,
+				.security = 0x394,
+			},
 		},
 	}, {
 		.name = "nvdecsrd",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
-			.override = 0x3c0,
-			.security = 0x3c4,
+			.sid = {
+				.override = 0x3c0,
+				.security = 0x3c4,
+			},
 		},
 	}, {
 		.name = "nvdecswr",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
-			.override = 0x3c8,
-			.security = 0x3cc,
+			.sid = {
+				.override = 0x3c8,
+				.security = 0x3cc,
+			},
 		},
 	}, {
 		.name = "aper",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
-			.override = 0x3c0,
-			.security = 0x3c4,
+			.sid = {
+				.override = 0x3c0,
+				.security = 0x3c4,
+			},
 		},
 	}, {
 		.name = "apew",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
-			.override = 0x3d0,
-			.security = 0x3d4,
+			.sid = {
+				.override = 0x3d0,
+				.security = 0x3d4,
+			},
 		},
 	}, {
 		.name = "nvjpgsrd",
 		.sid = TEGRA194_SID_NVJPG,
 		.regs = {
-			.override = 0x3f0,
-			.security = 0x3f4,
+			.sid = {
+				.override = 0x3f0,
+				.security = 0x3f4,
+			},
 		},
 	}, {
 		.name = "nvjpgswr",
 		.sid = TEGRA194_SID_NVJPG,
 		.regs = {
-			.override = 0x3f0,
-			.security = 0x3f4,
+			.sid = {
+				.override = 0x3f0,
+				.security = 0x3f4,
+			},
 		},
 	}, {
 		.name = "axiapr",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x410,
-			.security = 0x414,
+			.sid = {
+				.override = 0x410,
+				.security = 0x414,
+			},
 		},
 	}, {
 		.name = "axiapw",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x418,
-			.security = 0x41c,
+			.sid = {
+				.override = 0x418,
+				.security = 0x41c,
+			},
 		},
 	}, {
 		.name = "etrr",
 		.sid = TEGRA194_SID_ETR,
 		.regs = {
-			.override = 0x420,
-			.security = 0x424,
+			.sid = {
+				.override = 0x420,
+				.security = 0x424,
+			},
 		},
 	}, {
 		.name = "etrw",
 		.sid = TEGRA194_SID_ETR,
 		.regs = {
-			.override = 0x428,
-			.security = 0x42c,
+			.sid = {
+				.override = 0x428,
+				.security = 0x42c,
+			},
 		},
 	}, {
 		.name = "axisr",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x460,
-			.security = 0x464,
+			.sid = {
+				.override = 0x460,
+				.security = 0x464,
+			},
 		},
 	}, {
 		.name = "axisw",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x468,
-			.security = 0x46c,
+			.sid = {
+				.override = 0x468,
+				.security = 0x46c,
+			},
 		},
 	}, {
 		.name = "eqosr",
 		.sid = TEGRA194_SID_EQOS,
 		.regs = {
-			.override = 0x470,
-			.security = 0x474,
+			.sid = {
+				.override = 0x470,
+				.security = 0x474,
+			},
 		},
 	}, {
 		.name = "eqosw",
 		.sid = TEGRA194_SID_EQOS,
 		.regs = {
-			.override = 0x478,
-			.security = 0x47c,
+			.sid = {
+				.override = 0x478,
+				.security = 0x47c,
+			},
 		},
 	}, {
 		.name = "ufshcr",
 		.sid = TEGRA194_SID_UFSHC,
 		.regs = {
-			.override = 0x480,
-			.security = 0x484,
+			.sid = {
+				.override = 0x480,
+				.security = 0x484,
+			},
 		},
 	}, {
 		.name = "ufshcw",
 		.sid = TEGRA194_SID_UFSHC,
 		.regs = {
-			.override = 0x488,
-			.security = 0x48c,
+			.sid = {
+				.override = 0x488,
+				.security = 0x48c,
+			},
 		},
 	}, {
 		.name = "nvdisplayr",
 		.sid = TEGRA194_SID_NVDISPLAY,
 		.regs = {
-			.override = 0x490,
-			.security = 0x494,
+			.sid = {
+				.override = 0x490,
+				.security = 0x494,
+			},
 		},
 	}, {
 		.name = "bpmpr",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
-			.override = 0x498,
-			.security = 0x49c,
+			.sid = {
+				.override = 0x498,
+				.security = 0x49c,
+			},
 		},
 	}, {
 		.name = "bpmpw",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
-			.override = 0x4a0,
-			.security = 0x4a4,
+			.sid = {
+				.override = 0x4a0,
+				.security = 0x4a4,
+			},
 		},
 	}, {
 		.name = "bpmpdmar",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
-			.override = 0x4a8,
-			.security = 0x4ac,
+			.sid = {
+				.override = 0x4a8,
+				.security = 0x4ac,
+			},
 		},
 	}, {
 		.name = "bpmpdmaw",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
-			.override = 0x4b0,
-			.security = 0x4b4,
+			.sid = {
+				.override = 0x4b0,
+				.security = 0x4b4,
+			},
 		},
 	}, {
 		.name = "aonr",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
-			.override = 0x4b8,
-			.security = 0x4bc,
+			.sid = {
+				.override = 0x4b8,
+				.security = 0x4bc,
+			},
 		},
 	}, {
 		.name = "aonw",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
-			.override = 0x4c0,
-			.security = 0x4c4,
+			.sid = {
+				.override = 0x4c0,
+				.security = 0x4c4,
+			},
 		},
 	}, {
 		.name = "aondmar",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
-			.override = 0x4c8,
-			.security = 0x4cc,
+			.sid = {
+				.override = 0x4c8,
+				.security = 0x4cc,
+			},
 		},
 	}, {
 		.name = "aondmaw",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
-			.override = 0x4d0,
-			.security = 0x4d4,
+			.sid = {
+				.override = 0x4d0,
+				.security = 0x4d4,
+			},
 		},
 	}, {
 		.name = "scer",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
-			.override = 0x4d8,
-			.security = 0x4dc,
+			.sid = {
+				.override = 0x4d8,
+				.security = 0x4dc,
+			},
 		},
 	}, {
 		.name = "scew",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
-			.override = 0x4e0,
-			.security = 0x4e4,
+			.sid = {
+				.override = 0x4e0,
+				.security = 0x4e4,
+			},
 		},
 	}, {
 		.name = "scedmar",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
-			.override = 0x4e8,
-			.security = 0x4ec,
+			.sid = {
+				.override = 0x4e8,
+				.security = 0x4ec,
+			},
 		},
 	}, {
 		.name = "scedmaw",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
-			.override = 0x4f0,
-			.security = 0x4f4,
+			.sid = {
+				.override = 0x4f0,
+				.security = 0x4f4,
+			},
 		},
 	}, {
 		.name = "apedmar",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
-			.override = 0x4f8,
-			.security = 0x4fc,
+			.sid = {
+				.override = 0x4f8,
+				.security = 0x4fc,
+			},
 		},
 	}, {
 		.name = "apedmaw",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
-			.override = 0x500,
-			.security = 0x504,
+			.sid = {
+				.override = 0x500,
+				.security = 0x504,
+			},
 		},
 	}, {
 		.name = "nvdisplayr1",
 		.sid = TEGRA194_SID_NVDISPLAY,
 		.regs = {
-			.override = 0x508,
-			.security = 0x50c,
+			.sid = {
+				.override = 0x508,
+				.security = 0x50c,
+			},
 		},
 	}, {
 		.name = "vicsrd1",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
-			.override = 0x510,
-			.security = 0x514,
+			.sid = {
+				.override = 0x510,
+				.security = 0x514,
+			},
 		},
 	}, {
 		.name = "nvdecsrd1",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
-			.override = 0x518,
-			.security = 0x51c,
+			.sid = {
+				.override = 0x518,
+				.security = 0x51c,
+			},
 		},
 	}, {
 		.name = "miu0r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x530,
-			.security = 0x534,
+			.sid = {
+				.override = 0x530,
+				.security = 0x534,
+			},
 		},
 	}, {
 		.name = "miu0w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x538,
-			.security = 0x53c,
+			.sid = {
+				.override = 0x538,
+				.security = 0x53c,
+			},
 		},
 	}, {
 		.name = "miu1r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x540,
-			.security = 0x544,
+			.sid = {
+				.override = 0x540,
+				.security = 0x544,
+			},
 		},
 	}, {
 		.name = "miu1w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x548,
-			.security = 0x54c,
+			.sid = {
+				.override = 0x548,
+				.security = 0x54c,
+			},
 		},
 	}, {
 		.name = "miu2r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x570,
-			.security = 0x574,
+			.sid = {
+				.override = 0x570,
+				.security = 0x574,
+			},
 		},
 	}, {
 		.name = "miu2w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x578,
-			.security = 0x57c,
+			.sid = {
+				.override = 0x578,
+				.security = 0x57c,
+			},
 		},
 	}, {
 		.name = "miu3r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x580,
-			.security = 0x584,
+			.sid = {
+				.override = 0x580,
+				.security = 0x584,
+			},
 		},
 	}, {
 		.name = "miu3w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x588,
-			.security = 0x58c,
+			.sid = {
+				.override = 0x588,
+				.security = 0x58c,
+			},
 		},
 	}, {
 		.name = "miu4r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x590,
-			.security = 0x594,
+			.sid = {
+				.override = 0x590,
+				.security = 0x594,
+			},
 		},
 	}, {
 		.name = "miu4w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x598,
-			.security = 0x59c,
+			.sid = {
+				.override = 0x598,
+				.security = 0x59c,
+			},
 		},
 	}, {
 		.name = "dpmur",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
-			.override = 0x598,
-			.security = 0x59c,
+			.sid = {
+				.override = 0x598,
+				.security = 0x59c,
+			},
 		},
 	}, {
 		.name = "vifalr",
 		.sid = TEGRA194_SID_VI_FALCON,
 		.regs = {
-			.override = 0x5e0,
-			.security = 0x5e4,
+			.sid = {
+				.override = 0x5e0,
+				.security = 0x5e4,
+			},
 		},
 	}, {
 		.name = "vifalw",
 		.sid = TEGRA194_SID_VI_FALCON,
 		.regs = {
-			.override = 0x5e8,
-			.security = 0x5ec,
+			.sid = {
+				.override = 0x5e8,
+				.security = 0x5ec,
+			},
 		},
 	}, {
 		.name = "dla0rda",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
-			.override = 0x5f0,
-			.security = 0x5f4,
+			.sid = {
+				.override = 0x5f0,
+				.security = 0x5f4,
+			},
 		},
 	}, {
 		.name = "dla0falrdb",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
-			.override = 0x5f8,
-			.security = 0x5fc,
+			.sid = {
+				.override = 0x5f8,
+				.security = 0x5fc,
+			},
 		},
 	}, {
 		.name = "dla0wra",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
-			.override = 0x600,
-			.security = 0x604,
+			.sid = {
+				.override = 0x600,
+				.security = 0x604,
+			},
 		},
 	}, {
 		.name = "dla0falwrb",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
-			.override = 0x608,
-			.security = 0x60c,
+			.sid = {
+				.override = 0x608,
+				.security = 0x60c,
+			},
 		},
 	}, {
 		.name = "dla1rda",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
-			.override = 0x610,
-			.security = 0x614,
+			.sid = {
+				.override = 0x610,
+				.security = 0x614,
+			},
 		},
 	}, {
 		.name = "dla1falrdb",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
-			.override = 0x618,
-			.security = 0x61c,
+			.sid = {
+				.override = 0x618,
+				.security = 0x61c,
+			},
 		},
 	}, {
 		.name = "dla1wra",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
-			.override = 0x620,
-			.security = 0x624,
+			.sid = {
+				.override = 0x620,
+				.security = 0x624,
+			},
 		},
 	}, {
 		.name = "dla1falwrb",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
-			.override = 0x628,
-			.security = 0x62c,
+			.sid = {
+				.override = 0x628,
+				.security = 0x62c,
+			},
 		},
 	}, {
 		.name = "pva0rda",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x630,
-			.security = 0x634,
+			.sid = {
+				.override = 0x630,
+				.security = 0x634,
+			},
 		},
 	}, {
 		.name = "pva0rdb",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x638,
-			.security = 0x63c,
+			.sid = {
+				.override = 0x638,
+				.security = 0x63c,
+			},
 		},
 	}, {
 		.name = "pva0rdc",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x640,
-			.security = 0x644,
+			.sid = {
+				.override = 0x640,
+				.security = 0x644,
+			},
 		},
 	}, {
 		.name = "pva0wra",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x648,
-			.security = 0x64c,
+			.sid = {
+				.override = 0x648,
+				.security = 0x64c,
+			},
 		},
 	}, {
 		.name = "pva0wrb",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x650,
-			.security = 0x654,
+			.sid = {
+				.override = 0x650,
+				.security = 0x654,
+			},
 		},
 	}, {
 		.name = "pva0wrc",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x658,
-			.security = 0x65c,
+			.sid = {
+				.override = 0x658,
+				.security = 0x65c,
+			},
 		},
 	}, {
 		.name = "pva1rda",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x660,
-			.security = 0x664,
+			.sid = {
+				.override = 0x660,
+				.security = 0x664,
+			},
 		},
 	}, {
 		.name = "pva1rdb",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x668,
-			.security = 0x66c,
+			.sid = {
+				.override = 0x668,
+				.security = 0x66c,
+			},
 		},
 	}, {
 		.name = "pva1rdc",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x670,
-			.security = 0x674,
+			.sid = {
+				.override = 0x670,
+				.security = 0x674,
+			},
 		},
 	}, {
 		.name = "pva1wra",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x678,
-			.security = 0x67c,
+			.sid = {
+				.override = 0x678,
+				.security = 0x67c,
+			},
 		},
 	}, {
 		.name = "pva1wrb",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x680,
-			.security = 0x684,
+			.sid = {
+				.override = 0x680,
+				.security = 0x684,
+			},
 		},
 	}, {
 		.name = "pva1wrc",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x688,
-			.security = 0x68c,
+			.sid = {
+				.override = 0x688,
+				.security = 0x68c,
+			},
 		},
 	}, {
 		.name = "rcer",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
-			.override = 0x690,
-			.security = 0x694,
+			.sid = {
+				.override = 0x690,
+				.security = 0x694,
+			},
 		},
 	}, {
 		.name = "rcew",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
-			.override = 0x698,
-			.security = 0x69c,
+			.sid = {
+				.override = 0x698,
+				.security = 0x69c,
+			},
 		},
 	}, {
 		.name = "rcedmar",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
-			.override = 0x6a0,
-			.security = 0x6a4,
+			.sid = {
+				.override = 0x6a0,
+				.security = 0x6a4,
+			},
 		},
 	}, {
 		.name = "rcedmaw",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
-			.override = 0x6a8,
-			.security = 0x6ac,
+			.sid = {
+				.override = 0x6a8,
+				.security = 0x6ac,
+			},
 		},
 	}, {
 		.name = "nvenc1srd",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
-			.override = 0x6b0,
-			.security = 0x6b4,
+			.sid = {
+				.override = 0x6b0,
+				.security = 0x6b4,
+			},
 		},
 	}, {
 		.name = "nvenc1swr",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
-			.override = 0x6b8,
-			.security = 0x6bc,
+			.sid = {
+				.override = 0x6b8,
+				.security = 0x6bc,
+			},
 		},
 	}, {
 		.name = "pcie0r",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
-			.override = 0x6c0,
-			.security = 0x6c4,
+			.sid = {
+				.override = 0x6c0,
+				.security = 0x6c4,
+			},
 		},
 	}, {
 		.name = "pcie0w",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
-			.override = 0x6c8,
-			.security = 0x6cc,
+			.sid = {
+				.override = 0x6c8,
+				.security = 0x6cc,
+			},
 		},
 	}, {
 		.name = "pcie1r",
 		.sid = TEGRA194_SID_PCIE1,
 		.regs = {
-			.override = 0x6d0,
-			.security = 0x6d4,
+			.sid = {
+				.override = 0x6d0,
+				.security = 0x6d4,
+			},
 		},
 	}, {
 		.name = "pcie1w",
 		.sid = TEGRA194_SID_PCIE1,
 		.regs = {
-			.override = 0x6d8,
-			.security = 0x6dc,
+			.sid = {
+				.override = 0x6d8,
+				.security = 0x6dc,
+			},
 		},
 	}, {
 		.name = "pcie2ar",
 		.sid = TEGRA194_SID_PCIE2,
 		.regs = {
-			.override = 0x6e0,
-			.security = 0x6e4,
+			.sid = {
+				.override = 0x6e0,
+				.security = 0x6e4,
+			},
 		},
 	}, {
 		.name = "pcie2aw",
 		.sid = TEGRA194_SID_PCIE2,
 		.regs = {
-			.override = 0x6e8,
-			.security = 0x6ec,
+			.sid = {
+				.override = 0x6e8,
+				.security = 0x6ec,
+			},
 		},
 	}, {
 		.name = "pcie3r",
 		.sid = TEGRA194_SID_PCIE3,
 		.regs = {
-			.override = 0x6f0,
-			.security = 0x6f4,
+			.sid = {
+				.override = 0x6f0,
+				.security = 0x6f4,
+			},
 		},
 	}, {
 		.name = "pcie3w",
 		.sid = TEGRA194_SID_PCIE3,
 		.regs = {
-			.override = 0x6f8,
-			.security = 0x6fc,
+			.sid = {
+				.override = 0x6f8,
+				.security = 0x6fc,
+			},
 		},
 	}, {
 		.name = "pcie4r",
 		.sid = TEGRA194_SID_PCIE4,
 		.regs = {
-			.override = 0x700,
-			.security = 0x704,
+			.sid = {
+				.override = 0x700,
+				.security = 0x704,
+			},
 		},
 	}, {
 		.name = "pcie4w",
 		.sid = TEGRA194_SID_PCIE4,
 		.regs = {
-			.override = 0x708,
-			.security = 0x70c,
+			.sid = {
+				.override = 0x708,
+				.security = 0x70c,
+			},
 		},
 	}, {
 		.name = "pcie5r",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
-			.override = 0x710,
-			.security = 0x714,
+			.sid = {
+				.override = 0x710,
+				.security = 0x714,
+			},
 		},
 	}, {
 		.name = "pcie5w",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
-			.override = 0x718,
-			.security = 0x71c,
+			.sid = {
+				.override = 0x718,
+				.security = 0x71c,
+			},
 		},
 	}, {
 		.name = "ispfalw",
 		.sid = TEGRA194_SID_ISP_FALCON,
 		.regs = {
-			.override = 0x720,
-			.security = 0x724,
+			.sid = {
+				.override = 0x720,
+				.security = 0x724,
+			},
 		},
 	}, {
 		.name = "dla0rda1",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
-			.override = 0x748,
-			.security = 0x74c,
+			.sid = {
+				.override = 0x748,
+				.security = 0x74c,
+			},
 		},
 	}, {
 		.name = "dla1rda1",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
-			.override = 0x750,
-			.security = 0x754,
+			.sid = {
+				.override = 0x750,
+				.security = 0x754,
+			},
 		},
 	}, {
 		.name = "pva0rda1",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x758,
-			.security = 0x75c,
+			.sid = {
+				.override = 0x758,
+				.security = 0x75c,
+			},
 		},
 	}, {
 		.name = "pva0rdb1",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
-			.override = 0x760,
-			.security = 0x764,
+			.sid = {
+				.override = 0x760,
+				.security = 0x764,
+			},
 		},
 	}, {
 		.name = "pva1rda1",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x768,
-			.security = 0x76c,
+			.sid = {
+				.override = 0x768,
+				.security = 0x76c,
+			},
 		},
 	}, {
 		.name = "pva1rdb1",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
-			.override = 0x770,
-			.security = 0x774,
+			.sid = {
+				.override = 0x770,
+				.security = 0x774,
+			},
 		},
 	}, {
 		.name = "pcie5r1",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
-			.override = 0x778,
-			.security = 0x77c,
+			.sid = {
+				.override = 0x778,
+				.security = 0x77c,
+			},
 		},
 	}, {
 		.name = "nvencsrd1",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
-			.override = 0x780,
-			.security = 0x784,
+			.sid = {
+				.override = 0x780,
+				.security = 0x784,
+			},
 		},
 	}, {
 		.name = "nvenc1srd1",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
-			.override = 0x788,
-			.security = 0x78c,
+			.sid = {
+				.override = 0x788,
+				.security = 0x78c,
+			},
 		},
 	}, {
 		.name = "ispra1",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
-			.override = 0x790,
-			.security = 0x794,
+			.sid = {
+				.override = 0x790,
+				.security = 0x794,
+			},
 		},
 	}, {
 		.name = "pcie0r1",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
-			.override = 0x798,
-			.security = 0x79c,
+			.sid = {
+				.override = 0x798,
+				.security = 0x79c,
+			},
 		},
 	}, {
 		.name = "nvdec1srd",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
-			.override = 0x7c8,
-			.security = 0x7cc,
+			.sid = {
+				.override = 0x7c8,
+				.security = 0x7cc,
+			},
 		},
 	}, {
 		.name = "nvdec1srd1",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
-			.override = 0x7d0,
-			.security = 0x7d4,
+			.sid = {
+				.override = 0x7d0,
+				.security = 0x7d4,
+			},
 		},
 	}, {
 		.name = "nvdec1swr",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
-			.override = 0x7d8,
-			.security = 0x7dc,
+			.sid = {
+				.override = 0x7d8,
+				.security = 0x7dc,
+			},
 		},
 	}, {
 		.name = "miu5r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x7e0,
-			.security = 0x7e4,
+			.sid = {
+				.override = 0x7e0,
+				.security = 0x7e4,
+			},
 		},
 	}, {
 		.name = "miu5w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x7e8,
-			.security = 0x7ec,
+			.sid = {
+				.override = 0x7e8,
+				.security = 0x7ec,
+			},
 		},
 	}, {
 		.name = "miu6r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x7f0,
-			.security = 0x7f4,
+			.sid = {
+				.override = 0x7f0,
+				.security = 0x7f4,
+			},
 		},
 	}, {
 		.name = "miu6w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-			.override = 0x7f8,
-			.security = 0x7fc,
+			.sid = {
+				.override = 0x7f8,
+				.security = 0x7fc,
+			},
 		},
 	},
 };
 
-static const struct tegra186_mc_soc tegra194_mc_soc = {
+static const struct tegra_mc_soc tegra194_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra194_mc_clients),
 	.clients = tegra194_mc_clients,
 };
@@ -1523,8 +1914,8 @@ static const struct tegra186_mc_soc tegra194_mc_soc = {
 
 static int tegra186_mc_probe(struct platform_device *pdev)
 {
-	struct tegra186_mc *mc;
 	struct resource *res;
+	struct tegra_mc *mc;
 	int err;
 
 	mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
@@ -1552,7 +1943,7 @@ static int tegra186_mc_probe(struct platform_device *pdev)
 
 static int tegra186_mc_remove(struct platform_device *pdev)
 {
-	struct tegra186_mc *mc = platform_get_drvdata(pdev);
+	struct tegra_mc *mc = platform_get_drvdata(pdev);
 
 	of_platform_depopulate(mc->dev);
 
@@ -1577,7 +1968,7 @@ static int __maybe_unused tegra186_mc_suspend(struct device *dev)
 
 static int __maybe_unused tegra186_mc_resume(struct device *dev)
 {
-	struct tegra186_mc *mc = dev_get_drvdata(dev);
+	struct tegra_mc *mc = dev_get_drvdata(dev);
 
 	tegra186_mc_program_sid(mc);
 
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index dd26505464c2..9da4ef52ce30 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -26,12 +26,20 @@ struct tegra_mc_timing {
 struct tegra_mc_client {
 	unsigned int id;
 	const char *name;
-	unsigned int swgroup;
+	/*
+	 * For Tegra210 and earlier, this is the SWGROUP ID used for IOVA translations in the
+	 * Tegra SMMU, whereas on Tegra186 and later this is the ID used to override the ARM SMMU
+	 * stream ID used for IOVA translations for the given memory client.
+	 */
+	union {
+		unsigned int swgroup;
+		unsigned int sid;
+	};
 
 	unsigned int fifo_size;
 
 	struct {
-		/* Tegra SMMU enable */
+		/* Tegra SMMU enable (Tegra210 and earlier) */
 		struct {
 			unsigned int reg;
 			unsigned int bit;
@@ -44,6 +52,12 @@ struct tegra_mc_client {
 			unsigned int mask;
 			unsigned int def;
 		} la;
+
+		/* stream ID overrides (Tegra186 and later) */
+		struct {
+			unsigned int override;
+			unsigned int security;
+		} sid;
 	} regs;
 };
 
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:32 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:32 +0200
Subject: [PATCH 04/10] memory: tegra: Make per-SoC setup more generic
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-5-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The current per-SoC setup code runs at a fairly arbitrary point during
probe, thereby making it less flexible for other SoC generations. Move
the call around slightly, which will allow it to be used for other
implementations.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c      | 17 ++++++++---------
 drivers/memory/tegra/tegra20.c |  4 ++--
 include/soc/tegra/mc.h         |  2 +-
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 2b21131d779c..a800982f4a94 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -784,6 +784,14 @@ static int tegra_mc_probe(struct platform_device *pdev)
 		return PTR_ERR(mc->clk);
 	}
 
+	mc->debugfs.root = debugfs_create_dir("mc", NULL);
+
+	if (mc->soc->ops && mc->soc->ops->probe) {
+		err = mc->soc->ops->probe(mc);
+		if (err < 0)
+			return err;
+	}
+
 #ifdef CONFIG_ARCH_TEGRA_2x_SOC
 	if (mc->soc == &tegra20_mc_soc) {
 		isr = tegra20_mc_irq;
@@ -827,15 +835,6 @@ static int tegra_mc_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	mc->debugfs.root = debugfs_create_dir("mc", NULL);
-
-	if (mc->soc->ops && mc->soc->ops->init) {
-		err = mc->soc->ops->init(mc);
-		if (err < 0)
-			dev_err(&pdev->dev, "failed to initialize SoC driver: %d\n",
-				err);
-	}
-
 	err = tegra_mc_reset_setup(mc);
 	if (err < 0)
 		dev_err(&pdev->dev, "failed to register reset controller: %d\n",
diff --git a/drivers/memory/tegra/tegra20.c b/drivers/memory/tegra/tegra20.c
index a3335ad20f4d..2c86c0d70d59 100644
--- a/drivers/memory/tegra/tegra20.c
+++ b/drivers/memory/tegra/tegra20.c
@@ -679,7 +679,7 @@ static int tegra20_mc_stats_show(struct seq_file *s, void *unused)
 	return 0;
 }
 
-static int tegra20_mc_init(struct tegra_mc *mc)
+static int tegra20_mc_probe(struct tegra_mc *mc)
 {
 	debugfs_create_devm_seqfile(mc->dev, "stats", mc->debugfs.root,
 				    tegra20_mc_stats_show);
@@ -714,7 +714,7 @@ static int tegra20_mc_resume(struct tegra_mc *mc)
 }
 
 static const struct tegra_mc_ops tegra20_mc_ops = {
-	.init = tegra20_mc_init,
+	.probe = tegra20_mc_probe,
 	.suspend = tegra20_mc_suspend,
 	.resume = tegra20_mc_resume,
 };
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index 7c49f75087c3..fd19df3eb529 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -170,7 +170,7 @@ struct tegra_mc_icc_ops {
 };
 
 struct tegra_mc_ops {
-	int (*init)(struct tegra_mc *mc);
+	int (*probe)(struct tegra_mc *mc);
 	int (*suspend)(struct tegra_mc *mc);
 	int (*resume)(struct tegra_mc *mc);
 };
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:31 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:31 +0200
Subject: [PATCH 03/10] memory: tegra: Push suspend/resume into SoC drivers
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-4-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Continuing the scheme of unification, push suspend/resume callbacks into
per-SoC driver so that they can be properly parameterized.

While at it, also move the ->init() callback into the new tegra_mc_ops
structure to keep things clean.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c       | 24 ++++++++---------------
 drivers/memory/tegra/tegra186.c | 27 ++++++++++++++++++++++----
 drivers/memory/tegra/tegra20.c  | 34 ++++++++++++++++++++++++++++++++-
 include/soc/tegra/mc.h          |  9 +++++++--
 4 files changed, 71 insertions(+), 23 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index b7e104bf6614..2b21131d779c 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -829,8 +829,8 @@ static int tegra_mc_probe(struct platform_device *pdev)
 
 	mc->debugfs.root = debugfs_create_dir("mc", NULL);
 
-	if (mc->soc->init) {
-		err = mc->soc->init(mc);
+	if (mc->soc->ops && mc->soc->ops->init) {
+		err = mc->soc->ops->init(mc);
 		if (err < 0)
 			dev_err(&pdev->dev, "failed to initialize SoC driver: %d\n",
 				err);
@@ -867,30 +867,22 @@ static int tegra_mc_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int tegra_mc_suspend(struct device *dev)
+static int __maybe_unused tegra_mc_suspend(struct device *dev)
 {
 	struct tegra_mc *mc = dev_get_drvdata(dev);
-	int err;
 
-	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
-		err = tegra_gart_suspend(mc->gart);
-		if (err)
-			return err;
-	}
+	if (mc->soc->ops && mc->soc->ops->suspend)
+		return mc->soc->ops->suspend(mc);
 
 	return 0;
 }
 
-static int tegra_mc_resume(struct device *dev)
+static int __maybe_unused tegra_mc_resume(struct device *dev)
 {
 	struct tegra_mc *mc = dev_get_drvdata(dev);
-	int err;
 
-	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
-		err = tegra_gart_resume(mc->gart);
-		if (err)
-			return err;
-	}
+	if (mc->soc->ops && mc->soc->ops->resume)
+		return mc->soc->ops->resume(mc);
 
 	return 0;
 }
diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index 8e77567d1378..9d3fdb609d55 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -45,6 +45,17 @@ static void tegra186_mc_program_sid(struct tegra_mc *mc)
 	}
 }
 
+static int tegra186_mc_resume(struct tegra_mc *mc)
+{
+	tegra186_mc_program_sid(mc);
+
+	return 0;
+}
+
+static const struct tegra_mc_ops tegra186_mc_ops = {
+	.resume = tegra186_mc_resume,
+};
+
 #if defined(CONFIG_ARCH_TEGRA_186_SOC)
 static const struct tegra_mc_client tegra186_mc_clients[] = {
 	{
@@ -701,6 +712,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 static const struct tegra_mc_soc tegra186_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra186_mc_clients),
 	.clients = tegra186_mc_clients,
+	.ops = &tegra186_mc_ops,
 };
 #endif
 
@@ -1909,6 +1921,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 static const struct tegra_mc_soc tegra194_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra194_mc_clients),
 	.clients = tegra194_mc_clients,
+	.ops = &tegra186_mc_ops,
 };
 #endif
 
@@ -1961,22 +1974,28 @@ static const struct of_device_id tegra186_mc_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, tegra186_mc_of_match);
 
-static int __maybe_unused tegra186_mc_suspend(struct device *dev)
+static int __maybe_unused tegra_mc_suspend(struct device *dev)
 {
+	struct tegra_mc *mc = dev_get_drvdata(dev);
+
+	if (mc->soc->ops && mc->soc->ops->suspend)
+		return mc->soc->ops->suspend(mc);
+
 	return 0;
 }
 
-static int __maybe_unused tegra186_mc_resume(struct device *dev)
+static int __maybe_unused tegra_mc_resume(struct device *dev)
 {
 	struct tegra_mc *mc = dev_get_drvdata(dev);
 
-	tegra186_mc_program_sid(mc);
+	if (mc->soc->ops && mc->soc->ops->resume)
+		return mc->soc->ops->resume(mc);
 
 	return 0;
 }
 
 static const struct dev_pm_ops tegra186_mc_pm_ops = {
-	SET_SYSTEM_SLEEP_PM_OPS(tegra186_mc_suspend, tegra186_mc_resume)
+	SET_SYSTEM_SLEEP_PM_OPS(tegra_mc_suspend, tegra_mc_resume)
 };
 
 static struct platform_driver tegra186_mc_driver = {
diff --git a/drivers/memory/tegra/tegra20.c b/drivers/memory/tegra/tegra20.c
index 2db68a913b7a..a3335ad20f4d 100644
--- a/drivers/memory/tegra/tegra20.c
+++ b/drivers/memory/tegra/tegra20.c
@@ -687,6 +687,38 @@ static int tegra20_mc_init(struct tegra_mc *mc)
 	return 0;
 }
 
+static int tegra20_mc_suspend(struct tegra_mc *mc)
+{
+	int err;
+
+	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
+		err = tegra_gart_suspend(mc->gart);
+		if (err < 0)
+			return err;
+	}
+
+	return 0;
+}
+
+static int tegra20_mc_resume(struct tegra_mc *mc)
+{
+	int err;
+
+	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
+		err = tegra_gart_resume(mc->gart);
+		if (err < 0)
+			return err;
+	}
+
+	return 0;
+}
+
+static const struct tegra_mc_ops tegra20_mc_ops = {
+	.init = tegra20_mc_init,
+	.suspend = tegra20_mc_suspend,
+	.resume = tegra20_mc_resume,
+};
+
 const struct tegra_mc_soc tegra20_mc_soc = {
 	.clients = tegra20_mc_clients,
 	.num_clients = ARRAY_SIZE(tegra20_mc_clients),
@@ -698,5 +730,5 @@ const struct tegra_mc_soc tegra20_mc_soc = {
 	.resets = tegra20_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra20_mc_resets),
 	.icc_ops = &tegra20_mc_icc_ops,
-	.init = tegra20_mc_init,
+	.ops = &tegra20_mc_ops,
 };
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index 9da4ef52ce30..7c49f75087c3 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -169,6 +169,12 @@ struct tegra_mc_icc_ops {
 						void *data);
 };
 
+struct tegra_mc_ops {
+	int (*init)(struct tegra_mc *mc);
+	int (*suspend)(struct tegra_mc *mc);
+	int (*resume)(struct tegra_mc *mc);
+};
+
 struct tegra_mc_soc {
 	const struct tegra_mc_client *clients;
 	unsigned int num_clients;
@@ -190,8 +196,7 @@ struct tegra_mc_soc {
 	unsigned int num_resets;
 
 	const struct tegra_mc_icc_ops *icc_ops;
-
-	int (*init)(struct tegra_mc *mc);
+	const struct tegra_mc_ops *ops;
 };
 
 struct tegra_mc {
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:33 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:33 +0200
Subject: [PATCH 05/10] memory: tegra: Extract setup code into callback
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-6-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Separate the setup code for Tegra30 and later into a ->setup() callback
and set it for all applicable chips.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c       | 127 ++++++++++++++++++--------------
 drivers/memory/tegra/mc.h       |   9 +++
 drivers/memory/tegra/tegra114.c |   1 +
 drivers/memory/tegra/tegra124.c |   2 +
 drivers/memory/tegra/tegra210.c |   1 +
 drivers/memory/tegra/tegra30.c  |   1 +
 6 files changed, 84 insertions(+), 57 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index a800982f4a94..36eac0a0df3c 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -299,38 +299,6 @@ static int tegra_mc_reset_setup(struct tegra_mc *mc)
 	return 0;
 }
 
-static int tegra_mc_setup_latency_allowance(struct tegra_mc *mc)
-{
-	unsigned long long tick;
-	unsigned int i;
-	u32 value;
-
-	/* compute the number of MC clock cycles per tick */
-	tick = (unsigned long long)mc->tick * clk_get_rate(mc->clk);
-	do_div(tick, NSEC_PER_SEC);
-
-	value = mc_readl(mc, MC_EMEM_ARB_CFG);
-	value &= ~MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE_MASK;
-	value |= MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE(tick);
-	mc_writel(mc, value, MC_EMEM_ARB_CFG);
-
-	/* write latency allowance defaults */
-	for (i = 0; i < mc->soc->num_clients; i++) {
-		const struct tegra_mc_client *client = &mc->soc->clients[i];
-		u32 value;
-
-		value = mc_readl(mc, client->regs.la.reg);
-		value &= ~(client->regs.la.mask << client->regs.la.shift);
-		value |= (client->regs.la.def & client->regs.la.mask) << client->regs.la.shift;
-		mc_writel(mc, value, client->regs.la.reg);
-	}
-
-	/* latch new values */
-	mc_writel(mc, MC_TIMING_UPDATE, MC_TIMING_CONTROL);
-
-	return 0;
-}
-
 int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long rate)
 {
 	unsigned int i;
@@ -368,6 +336,43 @@ unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc)
 }
 EXPORT_SYMBOL_GPL(tegra_mc_get_emem_device_count);
 
+#if defined(CONFIG_ARCH_TEGRA_3x_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_114_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_124_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_132_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_210_SOC)
+static int tegra_mc_setup_latency_allowance(struct tegra_mc *mc)
+{
+	unsigned long long tick;
+	unsigned int i;
+	u32 value;
+
+	/* compute the number of MC clock cycles per tick */
+	tick = (unsigned long long)mc->tick * clk_get_rate(mc->clk);
+	do_div(tick, NSEC_PER_SEC);
+
+	value = mc_readl(mc, MC_EMEM_ARB_CFG);
+	value &= ~MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE_MASK;
+	value |= MC_EMEM_ARB_CFG_CYCLES_PER_UPDATE(tick);
+	mc_writel(mc, value, MC_EMEM_ARB_CFG);
+
+	/* write latency allowance defaults */
+	for (i = 0; i < mc->soc->num_clients; i++) {
+		const struct tegra_mc_client *client = &mc->soc->clients[i];
+		u32 value;
+
+		value = mc_readl(mc, client->regs.la.reg);
+		value &= ~(client->regs.la.mask << client->regs.la.shift);
+		value |= (client->regs.la.def & client->regs.la.mask) << client->regs.la.shift;
+		mc_writel(mc, value, client->regs.la.reg);
+	}
+
+	/* latch new values */
+	mc_writel(mc, MC_TIMING_UPDATE, MC_TIMING_CONTROL);
+
+	return 0;
+}
+
 static int load_one_timing(struct tegra_mc *mc,
 			   struct tegra_mc_timing *timing,
 			   struct device_node *node)
@@ -459,6 +464,39 @@ static int tegra_mc_setup_timings(struct tegra_mc *mc)
 	return 0;
 }
 
+int tegra30_mc_probe(struct tegra_mc *mc)
+{
+	int err;
+
+	mc->clk = devm_clk_get_optional(mc->dev, "mc");
+	if (IS_ERR(mc->clk)) {
+		dev_err(mc->dev, "failed to get MC clock: %ld\n", PTR_ERR(mc->clk));
+		return PTR_ERR(mc->clk);
+	}
+
+	/* ensure that debug features are disabled */
+	mc_writel(mc, 0x00000000, MC_TIMING_CONTROL_DBG);
+
+	err = tegra_mc_setup_latency_allowance(mc);
+	if (err < 0) {
+		dev_err(mc->dev, "failed to setup latency allowance: %d\n", err);
+		return err;
+	}
+
+	err = tegra_mc_setup_timings(mc);
+	if (err < 0) {
+		dev_err(mc->dev, "failed to setup timings: %d\n", err);
+		return err;
+	}
+
+	return 0;
+}
+
+const struct tegra_mc_ops tegra30_mc_ops = {
+	.probe = tegra30_mc_probe,
+};
+#endif
+
 static const char *const status_names[32] = {
 	[ 1] = "External interrupt",
 	[ 6] = "EMEM address decode error",
@@ -777,13 +815,6 @@ static int tegra_mc_probe(struct platform_device *pdev)
 	if (IS_ERR(mc->regs))
 		return PTR_ERR(mc->regs);
 
-	mc->clk = devm_clk_get(&pdev->dev, "mc");
-	if (IS_ERR(mc->clk)) {
-		dev_err(&pdev->dev, "failed to get MC clock: %ld\n",
-			PTR_ERR(mc->clk));
-		return PTR_ERR(mc->clk);
-	}
-
 	mc->debugfs.root = debugfs_create_dir("mc", NULL);
 
 	if (mc->soc->ops && mc->soc->ops->probe) {
@@ -798,25 +829,7 @@ static int tegra_mc_probe(struct platform_device *pdev)
 	} else
 #endif
 	{
-		/* ensure that debug features are disabled */
-		mc_writel(mc, 0x00000000, MC_TIMING_CONTROL_DBG);
-
-		err = tegra_mc_setup_latency_allowance(mc);
-		if (err < 0) {
-			dev_err(&pdev->dev,
-				"failed to setup latency allowance: %d\n",
-				err);
-			return err;
-		}
-
 		isr = tegra_mc_irq;
-
-		err = tegra_mc_setup_timings(mc);
-		if (err < 0) {
-			dev_err(&pdev->dev, "failed to setup timings: %d\n",
-				err);
-			return err;
-		}
 	}
 
 	mc->irq = platform_get_irq(pdev, 0);
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 1ee34f0da4f7..731896169cf3 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -129,6 +129,15 @@ extern const struct tegra_mc_soc tegra132_mc_soc;
 extern const struct tegra_mc_soc tegra210_mc_soc;
 #endif
 
+#if defined(CONFIG_ARCH_TEGRA_3x_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_114_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_124_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_132_SOC) || \
+    defined(CONFIG_ARCH_TEGRA_210_SOC)
+int tegra30_mc_probe(struct tegra_mc *mc);
+extern const struct tegra_mc_ops tegra30_mc_ops;
+#endif
+
 /*
  * These IDs are for internal use of Tegra ICC drivers. The ID numbers are
  * chosen such that they don't conflict with the device-tree ICC node IDs.
diff --git a/drivers/memory/tegra/tegra114.c b/drivers/memory/tegra/tegra114.c
index 1f2054d34bf5..41350570c815 100644
--- a/drivers/memory/tegra/tegra114.c
+++ b/drivers/memory/tegra/tegra114.c
@@ -1113,4 +1113,5 @@ const struct tegra_mc_soc tegra114_mc_soc = {
 	.reset_ops = &tegra_mc_reset_ops_common,
 	.resets = tegra114_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra114_mc_resets),
+	.ops = &tegra30_mc_ops,
 };
diff --git a/drivers/memory/tegra/tegra124.c b/drivers/memory/tegra/tegra124.c
index 8a8485ceb789..d780a84241fe 100644
--- a/drivers/memory/tegra/tegra124.c
+++ b/drivers/memory/tegra/tegra124.c
@@ -1274,6 +1274,7 @@ const struct tegra_mc_soc tegra124_mc_soc = {
 	.resets = tegra124_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra124_mc_resets),
 	.icc_ops = &tegra124_mc_icc_ops,
+	.ops = &tegra30_mc_ops,
 };
 #endif /* CONFIG_ARCH_TEGRA_124_SOC */
 
@@ -1305,5 +1306,6 @@ const struct tegra_mc_soc tegra132_mc_soc = {
 	.resets = tegra124_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra124_mc_resets),
 	.icc_ops = &tegra124_mc_icc_ops,
+	.ops = &tegra30_mc_ops,
 };
 #endif /* CONFIG_ARCH_TEGRA_132_SOC */
diff --git a/drivers/memory/tegra/tegra210.c b/drivers/memory/tegra/tegra210.c
index 08f3a08cd743..8ab6498dbe7d 100644
--- a/drivers/memory/tegra/tegra210.c
+++ b/drivers/memory/tegra/tegra210.c
@@ -1286,4 +1286,5 @@ const struct tegra_mc_soc tegra210_mc_soc = {
 	.reset_ops = &tegra_mc_reset_ops_common,
 	.resets = tegra210_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra210_mc_resets),
+	.ops = &tegra30_mc_ops,
 };
diff --git a/drivers/memory/tegra/tegra30.c b/drivers/memory/tegra/tegra30.c
index 1922ab64e686..84316357513d 100644
--- a/drivers/memory/tegra/tegra30.c
+++ b/drivers/memory/tegra/tegra30.c
@@ -1399,4 +1399,5 @@ const struct tegra_mc_soc tegra30_mc_soc = {
 	.resets = tegra30_mc_resets,
 	.num_resets = ARRAY_SIZE(tegra30_mc_resets),
 	.icc_ops = &tegra30_mc_icc_ops,
+	.ops = &tegra30_mc_ops,
 };
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:35 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:35 +0200
Subject: [PATCH 07/10] memory: tegra: Only initialize reset controller if
 available
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-8-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The memory controller hot resets are implemented in the BPMP on Tegra186
and later, so there's no need to provide an implementation via the
memory controller driver. Conditionally register the reset controller
only if needed.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 515ffd948a37..23b7728623cb 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -768,10 +768,11 @@ static int tegra_mc_probe(struct platform_device *pdev)
 		}
 	}
 
-	err = tegra_mc_reset_setup(mc);
-	if (err < 0)
-		dev_err(&pdev->dev, "failed to register reset controller: %d\n",
-			err);
+	if (mc->soc->reset_ops) {
+		err = tegra_mc_reset_setup(mc);
+		if (err < 0)
+			dev_err(&pdev->dev, "failed to register reset controller: %d\n", err);
+	}
 
 	err = tegra_mc_interconnect_setup(mc);
 	if (err < 0)
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:34 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:34 +0200
Subject: [PATCH 06/10] memory: tegra: Parameterize interrupt handler
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-7-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Tegra20 requires a slightly different interrupt handler than Tegra30 and
later, so parameterize the handler, so that each SoC implementation can
provide its own.

While at it, also make IRQ support optional, which will help unify the
Tegra186 memory controller driver with this one.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c      | 154 ++++++++-------------------------
 drivers/memory/tegra/mc.h      |   4 +
 drivers/memory/tegra/tegra20.c |  74 ++++++++++++++++
 include/soc/tegra/mc.h         |   2 +
 4 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 36eac0a0df3c..515ffd948a37 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -492,32 +492,7 @@ int tegra30_mc_probe(struct tegra_mc *mc)
 	return 0;
 }
 
-const struct tegra_mc_ops tegra30_mc_ops = {
-	.probe = tegra30_mc_probe,
-};
-#endif
-
-static const char *const status_names[32] = {
-	[ 1] = "External interrupt",
-	[ 6] = "EMEM address decode error",
-	[ 7] = "GART page fault",
-	[ 8] = "Security violation",
-	[ 9] = "EMEM arbitration error",
-	[10] = "Page fault",
-	[11] = "Invalid APB ASID update",
-	[12] = "VPR violation",
-	[13] = "Secure carveout violation",
-	[16] = "MTS carveout violation",
-};
-
-static const char *const error_names[8] = {
-	[2] = "EMEM decode error",
-	[3] = "TrustZone violation",
-	[4] = "Carveout violation",
-	[6] = "SMMU translation error",
-};
-
-static irqreturn_t tegra_mc_irq(int irq, void *data)
+irqreturn_t tegra30_mc_handle_irq(int irq, void *data)
 {
 	struct tegra_mc *mc = data;
 	unsigned long status;
@@ -614,78 +589,31 @@ static irqreturn_t tegra_mc_irq(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
-static __maybe_unused irqreturn_t tegra20_mc_irq(int irq, void *data)
-{
-	struct tegra_mc *mc = data;
-	unsigned long status;
-	unsigned int bit;
-
-	/* mask all interrupts to avoid flooding */
-	status = mc_readl(mc, MC_INTSTATUS) & mc->soc->intmask;
-	if (!status)
-		return IRQ_NONE;
-
-	for_each_set_bit(bit, &status, 32) {
-		const char *direction = "read", *secure = "";
-		const char *error = status_names[bit];
-		const char *client, *desc;
-		phys_addr_t addr;
-		u32 value, reg;
-		u8 id, type;
-
-		switch (BIT(bit)) {
-		case MC_INT_DECERR_EMEM:
-			reg = MC_DECERR_EMEM_OTHERS_STATUS;
-			value = mc_readl(mc, reg);
-
-			id = value & mc->soc->client_id_mask;
-			desc = error_names[2];
-
-			if (value & BIT(31))
-				direction = "write";
-			break;
-
-		case MC_INT_INVALID_GART_PAGE:
-			reg = MC_GART_ERROR_REQ;
-			value = mc_readl(mc, reg);
-
-			id = (value >> 1) & mc->soc->client_id_mask;
-			desc = error_names[2];
-
-			if (value & BIT(0))
-				direction = "write";
-			break;
-
-		case MC_INT_SECURITY_VIOLATION:
-			reg = MC_SECURITY_VIOLATION_STATUS;
-			value = mc_readl(mc, reg);
-
-			id = value & mc->soc->client_id_mask;
-			type = (value & BIT(30)) ? 4 : 3;
-			desc = error_names[type];
-			secure = "secure ";
-
-			if (value & BIT(31))
-				direction = "write";
-			break;
-
-		default:
-			continue;
-		}
-
-		client = mc->soc->clients[id].name;
-		addr = mc_readl(mc, reg + sizeof(u32));
-
-		dev_err_ratelimited(mc->dev, "%s: %s%s @%pa: %s (%s)\n",
-				    client, secure, direction, &addr, error,
-				    desc);
-	}
+const struct tegra_mc_ops tegra30_mc_ops = {
+	.probe = tegra30_mc_probe,
+	.handle_irq = tegra30_mc_handle_irq,
+};
+#endif
 
-	/* clear interrupts */
-	mc_writel(mc, status, MC_INTSTATUS);
+const char *const status_names[32] = {
+	[ 1] = "External interrupt",
+	[ 6] = "EMEM address decode error",
+	[ 7] = "GART page fault",
+	[ 8] = "Security violation",
+	[ 9] = "EMEM arbitration error",
+	[10] = "Page fault",
+	[11] = "Invalid APB ASID update",
+	[12] = "VPR violation",
+	[13] = "Secure carveout violation",
+	[16] = "MTS carveout violation",
+};
 
-	return IRQ_HANDLED;
-}
+const char *const error_names[8] = {
+	[2] = "EMEM decode error",
+	[3] = "TrustZone violation",
+	[4] = "Carveout violation",
+	[6] = "SMMU translation error",
+};
 
 /*
  * Memory Controller (MC) has few Memory Clients that are issuing memory
@@ -786,7 +714,6 @@ static int tegra_mc_probe(struct platform_device *pdev)
 {
 	struct resource *res;
 	struct tegra_mc *mc;
-	void *isr;
 	u64 mask;
 	int err;
 
@@ -823,29 +750,22 @@ static int tegra_mc_probe(struct platform_device *pdev)
 			return err;
 	}
 
-#ifdef CONFIG_ARCH_TEGRA_2x_SOC
-	if (mc->soc == &tegra20_mc_soc) {
-		isr = tegra20_mc_irq;
-	} else
-#endif
-	{
-		isr = tegra_mc_irq;
-	}
-
-	mc->irq = platform_get_irq(pdev, 0);
-	if (mc->irq < 0)
-		return mc->irq;
+	if (mc->soc->ops && mc->soc->ops->handle_irq) {
+		mc->irq = platform_get_irq(pdev, 0);
+		if (mc->irq < 0)
+			return mc->irq;
 
-	WARN(!mc->soc->client_id_mask, "missing client ID mask for this SoC\n");
+		WARN(!mc->soc->client_id_mask, "missing client ID mask for this SoC\n");
 
-	mc_writel(mc, mc->soc->intmask, MC_INTMASK);
+		mc_writel(mc, mc->soc->intmask, MC_INTMASK);
 
-	err = devm_request_irq(&pdev->dev, mc->irq, isr, 0,
-			       dev_name(&pdev->dev), mc);
-	if (err < 0) {
-		dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n", mc->irq,
-			err);
-		return err;
+		err = devm_request_irq(&pdev->dev, mc->irq, mc->soc->ops->handle_irq, 0,
+				       dev_name(&pdev->dev), mc);
+		if (err < 0) {
+			dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n", mc->irq,
+				err);
+			return err;
+		}
 	}
 
 	err = tegra_mc_reset_setup(mc);
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 731896169cf3..5459018541e1 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -135,9 +135,13 @@ extern const struct tegra_mc_soc tegra210_mc_soc;
     defined(CONFIG_ARCH_TEGRA_132_SOC) || \
     defined(CONFIG_ARCH_TEGRA_210_SOC)
 int tegra30_mc_probe(struct tegra_mc *mc);
+irqreturn_t tegra30_mc_handle_irq(int irq, void *data);
 extern const struct tegra_mc_ops tegra30_mc_ops;
 #endif
 
+extern const char * const status_names[32];
+extern const char * const error_names[8];
+
 /*
  * These IDs are for internal use of Tegra ICC drivers. The ID numbers are
  * chosen such that they don't conflict with the device-tree ICC node IDs.
diff --git a/drivers/memory/tegra/tegra20.c b/drivers/memory/tegra/tegra20.c
index 2c86c0d70d59..300f99dd0077 100644
--- a/drivers/memory/tegra/tegra20.c
+++ b/drivers/memory/tegra/tegra20.c
@@ -713,10 +713,84 @@ static int tegra20_mc_resume(struct tegra_mc *mc)
 	return 0;
 }
 
+static irqreturn_t tegra20_mc_handle_irq(int irq, void *data)
+{
+	struct tegra_mc *mc = data;
+	unsigned long status;
+	unsigned int bit;
+
+	/* mask all interrupts to avoid flooding */
+	status = mc_readl(mc, MC_INTSTATUS) & mc->soc->intmask;
+	if (!status)
+		return IRQ_NONE;
+
+	for_each_set_bit(bit, &status, 32) {
+		const char *direction = "read", *secure = "";
+		const char *error = status_names[bit];
+		const char *client, *desc;
+		phys_addr_t addr;
+		u32 value, reg;
+		u8 id, type;
+
+		switch (BIT(bit)) {
+		case MC_INT_DECERR_EMEM:
+			reg = MC_DECERR_EMEM_OTHERS_STATUS;
+			value = mc_readl(mc, reg);
+
+			id = value & mc->soc->client_id_mask;
+			desc = error_names[2];
+
+			if (value & BIT(31))
+				direction = "write";
+			break;
+
+		case MC_INT_INVALID_GART_PAGE:
+			reg = MC_GART_ERROR_REQ;
+			value = mc_readl(mc, reg);
+
+			id = (value >> 1) & mc->soc->client_id_mask;
+			desc = error_names[2];
+
+			if (value & BIT(0))
+				direction = "write";
+			break;
+
+		case MC_INT_SECURITY_VIOLATION:
+			reg = MC_SECURITY_VIOLATION_STATUS;
+			value = mc_readl(mc, reg);
+
+			id = value & mc->soc->client_id_mask;
+			type = (value & BIT(30)) ? 4 : 3;
+			desc = error_names[type];
+			secure = "secure ";
+
+			if (value & BIT(31))
+				direction = "write";
+			break;
+
+		default:
+			continue;
+		}
+
+		client = mc->soc->clients[id].name;
+		addr = mc_readl(mc, reg + sizeof(u32));
+
+		dev_err_ratelimited(mc->dev, "%s: %s%s @%pa: %s (%s)\n",
+				    client, secure, direction, &addr, error,
+				    desc);
+	}
+
+	/* clear interrupts */
+	mc_writel(mc, status, MC_INTSTATUS);
+
+	return IRQ_HANDLED;
+}
+
 static const struct tegra_mc_ops tegra20_mc_ops = {
 	.probe = tegra20_mc_probe,
 	.suspend = tegra20_mc_suspend,
 	.resume = tegra20_mc_resume,
+	.handle_irq = tegra20_mc_handle_irq,
 };
 
 const struct tegra_mc_soc tegra20_mc_soc = {
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index fd19df3eb529..ce3cdcc7b596 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -10,6 +10,7 @@
 #include <linux/debugfs.h>
 #include <linux/err.h>
 #include <linux/interconnect-provider.h>
+#include <linux/irq.h>
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 
@@ -173,6 +174,7 @@ struct tegra_mc_ops {
 	int (*probe)(struct tegra_mc *mc);
 	int (*suspend)(struct tegra_mc *mc);
 	int (*resume)(struct tegra_mc *mc);
+	irqreturn_t (*handle_irq)(int irq, void *data);
 };
 
 struct tegra_mc_soc {
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:36 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:36 +0200
Subject: [PATCH 08/10] memory: tegra: Unify drivers
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-9-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The Tegra210 (and earlier) driver now supports all the functionality
that the Tegra186 (and later) driver does, so they can be unified.

Note that previously the Tegra186 (and later) driver could be unloaded,
even if that was perhaps not very useful. Older chips don't support that
yet, but once they do this code can be reenabled.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/Makefile   |   6 +-
 drivers/memory/tegra/mc.c       |  27 +++++++-
 drivers/memory/tegra/mc.h       |   8 +++
 drivers/memory/tegra/tegra186.c | 117 +++++++-------------------------
 include/soc/tegra/mc.h          |   1 +
 5 files changed, 64 insertions(+), 95 deletions(-)

diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 6c1a2ecc6628..1af0fefacdda 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -7,6 +7,8 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114.o
 tegra-mc-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124.o
 tegra-mc-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124.o
 tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
+tegra-mc-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
+tegra-mc-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra186.o
 
 obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
 
@@ -15,7 +17,7 @@ obj-$(CONFIG_TEGRA30_EMC)  += tegra30-emc.o
 obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
 obj-$(CONFIG_TEGRA210_EMC_TABLE) += tegra210-emc-table.o
 obj-$(CONFIG_TEGRA210_EMC) += tegra210-emc.o
-obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o tegra186-emc.o
-obj-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra186.o tegra186-emc.o
+obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-emc.o
+obj-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra186-emc.o
 
 tegra210-emc-y := tegra210-emc-core.o tegra210-emc-cc-r21021.o
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 23b7728623cb..c854639cf30c 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -39,7 +39,13 @@ static const struct of_device_id tegra_mc_of_match[] = {
 #ifdef CONFIG_ARCH_TEGRA_210_SOC
 	{ .compatible = "nvidia,tegra210-mc", .data = &tegra210_mc_soc },
 #endif
-	{ }
+#ifdef CONFIG_ARCH_TEGRA_186_SOC
+	{ .compatible = "nvidia,tegra186-mc", .data = &tegra186_mc_soc },
+#endif
+#ifdef CONFIG_ARCH_TEGRA_194_SOC
+	{ .compatible = "nvidia,tegra194-mc", .data = &tegra194_mc_soc },
+#endif
+	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
 
@@ -800,6 +806,22 @@ static int tegra_mc_probe(struct platform_device *pdev)
 	return 0;
 }
 
+/*
+ * XXX The Tegra186 memory controller driver used to be able to do this. Once
+ * removing the driver is supported on all chips, this can be uncommented.
+ */
+/*
+static int tegra_mc_remove(struct platform_device *pdev)
+{
+	struct tegra_mc *mc = platform_get_drvdata(pdev);
+
+	if (mc->soc->ops && mc->soc->ops->remove)
+		mc->soc->ops->remove(mc);
+
+	return 0;
+}
+*/
+
 static int __maybe_unused tegra_mc_suspend(struct device *dev)
 {
 	struct tegra_mc *mc = dev_get_drvdata(dev);
@@ -834,6 +856,9 @@ static struct platform_driver tegra_mc_driver = {
 	},
 	.prevent_deferred_probe = true,
 	.probe = tegra_mc_probe,
+	/*
+	.remove = tegra_mc_remove,
+	*/
 };
 
 static int tegra_mc_init(void)
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index 5459018541e1..d6c22870517a 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -129,6 +129,14 @@ extern const struct tegra_mc_soc tegra132_mc_soc;
 extern const struct tegra_mc_soc tegra210_mc_soc;
 #endif
 
+#ifdef CONFIG_ARCH_TEGRA_186_SOC
+extern const struct tegra_mc_soc tegra186_mc_soc;
+#endif
+
+#ifdef CONFIG_ARCH_TEGRA_194_SOC
+extern const struct tegra_mc_soc tegra194_mc_soc;
+#endif
+
 #if defined(CONFIG_ARCH_TEGRA_3x_SOC) || \
     defined(CONFIG_ARCH_TEGRA_114_SOC) || \
     defined(CONFIG_ARCH_TEGRA_124_SOC) || \
diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index 9d3fdb609d55..20efbbea587b 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Copyright (C) 2017 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2017-2021 NVIDIA CORPORATION.  All rights reserved.
  */
 
 #include <linux/io.h>
@@ -45,6 +45,24 @@ static void tegra186_mc_program_sid(struct tegra_mc *mc)
 	}
 }
 
+static int tegra186_mc_probe(struct tegra_mc *mc)
+{
+	int err;
+
+	err = of_platform_populate(mc->dev->of_node, NULL, NULL, mc->dev);
+	if (err < 0)
+		return err;
+
+	tegra186_mc_program_sid(mc);
+
+	return 0;
+}
+
+static void tegra186_mc_remove(struct tegra_mc *mc)
+{
+	of_platform_depopulate(mc->dev);
+}
+
 static int tegra186_mc_resume(struct tegra_mc *mc)
 {
 	tegra186_mc_program_sid(mc);
@@ -53,6 +71,8 @@ static int tegra186_mc_resume(struct tegra_mc *mc)
 }
 
 static const struct tegra_mc_ops tegra186_mc_ops = {
+	.probe = tegra186_mc_probe,
+	.remove = tegra186_mc_remove,
 	.resume = tegra186_mc_resume,
 };
 
@@ -709,9 +729,10 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 	},
 };
 
-static const struct tegra_mc_soc tegra186_mc_soc = {
+const struct tegra_mc_soc tegra186_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra186_mc_clients),
 	.clients = tegra186_mc_clients,
+	.num_address_bits = 40,
 	.ops = &tegra186_mc_ops,
 };
 #endif
@@ -1918,98 +1939,10 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 	},
 };
 
-static const struct tegra_mc_soc tegra194_mc_soc = {
+const struct tegra_mc_soc tegra194_mc_soc = {
 	.num_clients = ARRAY_SIZE(tegra194_mc_clients),
 	.clients = tegra194_mc_clients,
+	.num_address_bits = 40,
 	.ops = &tegra186_mc_ops,
 };
 #endif
-
-static int tegra186_mc_probe(struct platform_device *pdev)
-{
-	struct resource *res;
-	struct tegra_mc *mc;
-	int err;
-
-	mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL);
-	if (!mc)
-		return -ENOMEM;
-
-	mc->soc = of_device_get_match_data(&pdev->dev);
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	mc->regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(mc->regs))
-		return PTR_ERR(mc->regs);
-
-	mc->dev = &pdev->dev;
-
-	err = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
-	if (err < 0)
-		return err;
-
-	platform_set_drvdata(pdev, mc);
-	tegra186_mc_program_sid(mc);
-
-	return 0;
-}
-
-static int tegra186_mc_remove(struct platform_device *pdev)
-{
-	struct tegra_mc *mc = platform_get_drvdata(pdev);
-
-	of_platform_depopulate(mc->dev);
-
-	return 0;
-}
-
-static const struct of_device_id tegra186_mc_of_match[] = {
-#if defined(CONFIG_ARCH_TEGRA_186_SOC)
-	{ .compatible = "nvidia,tegra186-mc", .data = &tegra186_mc_soc },
-#endif
-#if defined(CONFIG_ARCH_TEGRA_194_SOC)
-	{ .compatible = "nvidia,tegra194-mc", .data = &tegra194_mc_soc },
-#endif
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, tegra186_mc_of_match);
-
-static int __maybe_unused tegra_mc_suspend(struct device *dev)
-{
-	struct tegra_mc *mc = dev_get_drvdata(dev);
-
-	if (mc->soc->ops && mc->soc->ops->suspend)
-		return mc->soc->ops->suspend(mc);
-
-	return 0;
-}
-
-static int __maybe_unused tegra_mc_resume(struct device *dev)
-{
-	struct tegra_mc *mc = dev_get_drvdata(dev);
-
-	if (mc->soc->ops && mc->soc->ops->resume)
-		return mc->soc->ops->resume(mc);
-
-	return 0;
-}
-
-static const struct dev_pm_ops tegra186_mc_pm_ops = {
-	SET_SYSTEM_SLEEP_PM_OPS(tegra_mc_suspend, tegra_mc_resume)
-};
-
-static struct platform_driver tegra186_mc_driver = {
-	.driver = {
-		.name = "tegra186-mc",
-		.of_match_table = tegra186_mc_of_match,
-		.pm = &tegra186_mc_pm_ops,
-		.suppress_bind_attrs = true,
-	},
-	.probe = tegra186_mc_probe,
-	.remove = tegra186_mc_remove,
-};
-module_platform_driver(tegra186_mc_driver);
-
-MODULE_AUTHOR("Thierry Reding <treding at nvidia.com>");
-MODULE_DESCRIPTION("NVIDIA Tegra186 Memory Controller driver");
-MODULE_LICENSE("GPL v2");
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index ce3cdcc7b596..1387747d574b 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -172,6 +172,7 @@ struct tegra_mc_icc_ops {
 
 struct tegra_mc_ops {
 	int (*probe)(struct tegra_mc *mc);
+	void (*remove)(struct tegra_mc *mc);
 	int (*suspend)(struct tegra_mc *mc);
 	int (*resume)(struct tegra_mc *mc);
 	irqreturn_t (*handle_irq)(int irq, void *data);
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 17:52:37 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 18:52:37 +0200
Subject: [PATCH 09/10] memory: tegra: Add memory client IDs to tables
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <20210420165237.3523732-10-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The memory client IDs will subsequently be used to program override SIDs
for the given clients depending on the device tree configuration.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/tegra186.c | 205 ++++++++++++++++++++++++++++++++
 1 file changed, 205 insertions(+)

diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index 20efbbea587b..2f6ef46c33a4 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -79,6 +79,7 @@ static const struct tegra_mc_ops tegra186_mc_ops = {
 #if defined(CONFIG_ARCH_TEGRA_186_SOC)
 static const struct tegra_mc_client tegra186_mc_clients[] = {
 	{
+		.id = TEGRA186_MEMORY_CLIENT_PTCR,
 		.name = "ptcr",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
@@ -88,6 +89,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AFIR,
 		.name = "afir",
 		.sid = TEGRA186_SID_AFI,
 		.regs = {
@@ -97,6 +99,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_HDAR,
 		.name = "hdar",
 		.sid = TEGRA186_SID_HDA,
 		.regs = {
@@ -106,6 +109,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_HOST1XDMAR,
 		.name = "host1xdmar",
 		.sid = TEGRA186_SID_HOST1X,
 		.regs = {
@@ -115,6 +119,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVENCSRD,
 		.name = "nvencsrd",
 		.sid = TEGRA186_SID_NVENC,
 		.regs = {
@@ -124,6 +129,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SATAR,
 		.name = "satar",
 		.sid = TEGRA186_SID_SATA,
 		.regs = {
@@ -133,6 +139,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_MPCORER,
 		.name = "mpcorer",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
@@ -142,6 +149,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVENCSWR,
 		.name = "nvencswr",
 		.sid = TEGRA186_SID_NVENC,
 		.regs = {
@@ -151,6 +159,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AFIW,
 		.name = "afiw",
 		.sid = TEGRA186_SID_AFI,
 		.regs = {
@@ -160,6 +169,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_HDAW,
 		.name = "hdaw",
 		.sid = TEGRA186_SID_HDA,
 		.regs = {
@@ -169,6 +179,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_MPCOREW,
 		.name = "mpcorew",
 		.sid = TEGRA186_SID_PASSTHROUGH,
 		.regs = {
@@ -178,6 +189,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SATAW,
 		.name = "sataw",
 		.sid = TEGRA186_SID_SATA,
 		.regs = {
@@ -187,6 +199,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_ISPRA,
 		.name = "ispra",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
@@ -196,6 +209,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_ISPWA,
 		.name = "ispwa",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
@@ -205,6 +219,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_ISPWB,
 		.name = "ispwb",
 		.sid = TEGRA186_SID_ISP,
 		.regs = {
@@ -214,6 +229,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_XUSB_HOSTR,
 		.name = "xusb_hostr",
 		.sid = TEGRA186_SID_XUSB_HOST,
 		.regs = {
@@ -223,6 +239,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_XUSB_HOSTW,
 		.name = "xusb_hostw",
 		.sid = TEGRA186_SID_XUSB_HOST,
 		.regs = {
@@ -232,6 +249,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_XUSB_DEVR,
 		.name = "xusb_devr",
 		.sid = TEGRA186_SID_XUSB_DEV,
 		.regs = {
@@ -241,6 +259,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_XUSB_DEVW,
 		.name = "xusb_devw",
 		.sid = TEGRA186_SID_XUSB_DEV,
 		.regs = {
@@ -250,6 +269,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_TSECSRD,
 		.name = "tsecsrd",
 		.sid = TEGRA186_SID_TSEC,
 		.regs = {
@@ -259,6 +279,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_TSECSWR,
 		.name = "tsecswr",
 		.sid = TEGRA186_SID_TSEC,
 		.regs = {
@@ -268,6 +289,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_GPUSRD,
 		.name = "gpusrd",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
@@ -277,6 +299,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_GPUSWR,
 		.name = "gpuswr",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
@@ -286,6 +309,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCRA,
 		.name = "sdmmcra",
 		.sid = TEGRA186_SID_SDMMC1,
 		.regs = {
@@ -295,6 +319,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCRAA,
 		.name = "sdmmcraa",
 		.sid = TEGRA186_SID_SDMMC2,
 		.regs = {
@@ -304,6 +329,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCR,
 		.name = "sdmmcr",
 		.sid = TEGRA186_SID_SDMMC3,
 		.regs = {
@@ -313,6 +339,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCRAB,
 		.name = "sdmmcrab",
 		.sid = TEGRA186_SID_SDMMC4,
 		.regs = {
@@ -322,6 +349,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCWA,
 		.name = "sdmmcwa",
 		.sid = TEGRA186_SID_SDMMC1,
 		.regs = {
@@ -331,6 +359,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCWAA,
 		.name = "sdmmcwaa",
 		.sid = TEGRA186_SID_SDMMC2,
 		.regs = {
@@ -340,6 +369,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCW,
 		.name = "sdmmcw",
 		.sid = TEGRA186_SID_SDMMC3,
 		.regs = {
@@ -349,6 +379,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SDMMCWAB,
 		.name = "sdmmcwab",
 		.sid = TEGRA186_SID_SDMMC4,
 		.regs = {
@@ -358,6 +389,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_VICSRD,
 		.name = "vicsrd",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
@@ -367,6 +399,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_VICSWR,
 		.name = "vicswr",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
@@ -376,6 +409,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_VIW,
 		.name = "viw",
 		.sid = TEGRA186_SID_VI,
 		.regs = {
@@ -385,6 +419,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVDECSRD,
 		.name = "nvdecsrd",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
@@ -394,6 +429,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVDECSWR,
 		.name = "nvdecswr",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
@@ -403,6 +439,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_APER,
 		.name = "aper",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
@@ -412,6 +449,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_APEW,
 		.name = "apew",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
@@ -421,6 +459,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVJPGSRD,
 		.name = "nvjpgsrd",
 		.sid = TEGRA186_SID_NVJPG,
 		.regs = {
@@ -430,6 +469,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVJPGSWR,
 		.name = "nvjpgswr",
 		.sid = TEGRA186_SID_NVJPG,
 		.regs = {
@@ -439,6 +479,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SESRD,
 		.name = "sesrd",
 		.sid = TEGRA186_SID_SE,
 		.regs = {
@@ -448,6 +489,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SESWR,
 		.name = "seswr",
 		.sid = TEGRA186_SID_SE,
 		.regs = {
@@ -457,6 +499,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_ETRR,
 		.name = "etrr",
 		.sid = TEGRA186_SID_ETR,
 		.regs = {
@@ -466,6 +509,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_ETRW,
 		.name = "etrw",
 		.sid = TEGRA186_SID_ETR,
 		.regs = {
@@ -475,6 +519,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_TSECSRDB,
 		.name = "tsecsrdb",
 		.sid = TEGRA186_SID_TSECB,
 		.regs = {
@@ -484,6 +529,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_TSECSWRB,
 		.name = "tsecswrb",
 		.sid = TEGRA186_SID_TSECB,
 		.regs = {
@@ -493,6 +539,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_GPUSRD2,
 		.name = "gpusrd2",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
@@ -502,6 +549,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_GPUSWR2,
 		.name = "gpuswr2",
 		.sid = TEGRA186_SID_GPU,
 		.regs = {
@@ -511,6 +559,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AXISR,
 		.name = "axisr",
 		.sid = TEGRA186_SID_GPCDMA_0,
 		.regs = {
@@ -520,6 +569,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AXISW,
 		.name = "axisw",
 		.sid = TEGRA186_SID_GPCDMA_0,
 		.regs = {
@@ -529,6 +579,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_EQOSR,
 		.name = "eqosr",
 		.sid = TEGRA186_SID_EQOS,
 		.regs = {
@@ -538,6 +589,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_EQOSW,
 		.name = "eqosw",
 		.sid = TEGRA186_SID_EQOS,
 		.regs = {
@@ -547,6 +599,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_UFSHCR,
 		.name = "ufshcr",
 		.sid = TEGRA186_SID_UFSHC,
 		.regs = {
@@ -556,6 +609,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_UFSHCW,
 		.name = "ufshcw",
 		.sid = TEGRA186_SID_UFSHC,
 		.regs = {
@@ -565,6 +619,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVDISPLAYR,
 		.name = "nvdisplayr",
 		.sid = TEGRA186_SID_NVDISPLAY,
 		.regs = {
@@ -574,6 +629,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_BPMPR,
 		.name = "bpmpr",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
@@ -583,6 +639,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_BPMPW,
 		.name = "bpmpw",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
@@ -592,6 +649,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_BPMPDMAR,
 		.name = "bpmpdmar",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
@@ -601,6 +659,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_BPMPDMAW,
 		.name = "bpmpdmaw",
 		.sid = TEGRA186_SID_BPMP,
 		.regs = {
@@ -610,6 +669,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AONR,
 		.name = "aonr",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
@@ -619,6 +679,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AONW,
 		.name = "aonw",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
@@ -628,6 +689,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AONDMAR,
 		.name = "aondmar",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
@@ -637,6 +699,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_AONDMAW,
 		.name = "aondmaw",
 		.sid = TEGRA186_SID_AON,
 		.regs = {
@@ -646,6 +709,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SCER,
 		.name = "scer",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
@@ -655,6 +719,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SCEW,
 		.name = "scew",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
@@ -664,6 +729,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SCEDMAR,
 		.name = "scedmar",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
@@ -673,6 +739,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_SCEDMAW,
 		.name = "scedmaw",
 		.sid = TEGRA186_SID_SCE,
 		.regs = {
@@ -682,6 +749,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_APEDMAR,
 		.name = "apedmar",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
@@ -691,6 +759,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_APEDMAW,
 		.name = "apedmaw",
 		.sid = TEGRA186_SID_APE,
 		.regs = {
@@ -700,6 +769,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVDISPLAYR1,
 		.name = "nvdisplayr1",
 		.sid = TEGRA186_SID_NVDISPLAY,
 		.regs = {
@@ -709,6 +779,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_VICSRD1,
 		.name = "vicsrd1",
 		.sid = TEGRA186_SID_VIC,
 		.regs = {
@@ -718,6 +789,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA186_MEMORY_CLIENT_NVDECSRD1,
 		.name = "nvdecsrd1",
 		.sid = TEGRA186_SID_NVDEC,
 		.regs = {
@@ -740,6 +812,7 @@ const struct tegra_mc_soc tegra186_mc_soc = {
 #if defined(CONFIG_ARCH_TEGRA_194_SOC)
 static const struct tegra_mc_client tegra194_mc_clients[] = {
 	{
+		.id = TEGRA194_MEMORY_CLIENT_PTCR,
 		.name = "ptcr",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -749,6 +822,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU7R,
 		.name = "miu7r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -758,6 +832,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU7W,
 		.name = "miu7w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -767,6 +842,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_HDAR,
 		.name = "hdar",
 		.sid = TEGRA194_SID_HDA,
 		.regs = {
@@ -776,6 +852,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_HOST1XDMAR,
 		.name = "host1xdmar",
 		.sid = TEGRA194_SID_HOST1X,
 		.regs = {
@@ -785,6 +862,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENCSRD,
 		.name = "nvencsrd",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
@@ -794,6 +872,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SATAR,
 		.name = "satar",
 		.sid = TEGRA194_SID_SATA,
 		.regs = {
@@ -803,6 +882,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MPCORER,
 		.name = "mpcorer",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -812,6 +892,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENCSWR,
 		.name = "nvencswr",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
@@ -821,6 +902,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_HDAW,
 		.name = "hdaw",
 		.sid = TEGRA194_SID_HDA,
 		.regs = {
@@ -830,6 +912,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MPCOREW,
 		.name = "mpcorew",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -839,6 +922,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SATAW,
 		.name = "sataw",
 		.sid = TEGRA194_SID_SATA,
 		.regs = {
@@ -848,6 +932,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPRA,
 		.name = "ispra",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
@@ -857,6 +942,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPFALR,
 		.name = "ispfalr",
 		.sid = TEGRA194_SID_ISP_FALCON,
 		.regs = {
@@ -866,6 +952,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPWA,
 		.name = "ispwa",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
@@ -875,6 +962,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPWB,
 		.name = "ispwb",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
@@ -884,6 +972,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_XUSB_HOSTR,
 		.name = "xusb_hostr",
 		.sid = TEGRA194_SID_XUSB_HOST,
 		.regs = {
@@ -893,6 +982,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_XUSB_HOSTW,
 		.name = "xusb_hostw",
 		.sid = TEGRA194_SID_XUSB_HOST,
 		.regs = {
@@ -902,6 +992,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_XUSB_DEVR,
 		.name = "xusb_devr",
 		.sid = TEGRA194_SID_XUSB_DEV,
 		.regs = {
@@ -911,6 +1002,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_XUSB_DEVW,
 		.name = "xusb_devw",
 		.sid = TEGRA194_SID_XUSB_DEV,
 		.regs = {
@@ -920,6 +1012,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCRA,
 		.name = "sdmmcra",
 		.sid = TEGRA194_SID_SDMMC1,
 		.regs = {
@@ -929,6 +1022,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCR,
 		.name = "sdmmcr",
 		.sid = TEGRA194_SID_SDMMC3,
 		.regs = {
@@ -938,6 +1032,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCRAB,
 		.name = "sdmmcrab",
 		.sid = TEGRA194_SID_SDMMC4,
 		.regs = {
@@ -947,6 +1042,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCWA,
 		.name = "sdmmcwa",
 		.sid = TEGRA194_SID_SDMMC1,
 		.regs = {
@@ -956,6 +1052,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCW,
 		.name = "sdmmcw",
 		.sid = TEGRA194_SID_SDMMC3,
 		.regs = {
@@ -965,6 +1062,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SDMMCWAB,
 		.name = "sdmmcwab",
 		.sid = TEGRA194_SID_SDMMC4,
 		.regs = {
@@ -974,6 +1072,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VICSRD,
 		.name = "vicsrd",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
@@ -983,6 +1082,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VICSWR,
 		.name = "vicswr",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
@@ -992,6 +1092,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VIW,
 		.name = "viw",
 		.sid = TEGRA194_SID_VI,
 		.regs = {
@@ -1001,6 +1102,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDECSRD,
 		.name = "nvdecsrd",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
@@ -1010,6 +1112,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDECSWR,
 		.name = "nvdecswr",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
@@ -1019,6 +1122,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_APER,
 		.name = "aper",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
@@ -1028,6 +1132,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_APEW,
 		.name = "apew",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
@@ -1037,6 +1142,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVJPGSRD,
 		.name = "nvjpgsrd",
 		.sid = TEGRA194_SID_NVJPG,
 		.regs = {
@@ -1046,6 +1152,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVJPGSWR,
 		.name = "nvjpgswr",
 		.sid = TEGRA194_SID_NVJPG,
 		.regs = {
@@ -1056,6 +1163,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 		},
 	}, {
 		.name = "axiapr",
+		.id = TEGRA194_MEMORY_CLIENT_AXIAPR,
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
 			.sid = {
@@ -1064,6 +1172,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AXIAPW,
 		.name = "axiapw",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -1073,6 +1182,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ETRR,
 		.name = "etrr",
 		.sid = TEGRA194_SID_ETR,
 		.regs = {
@@ -1082,6 +1192,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ETRW,
 		.name = "etrw",
 		.sid = TEGRA194_SID_ETR,
 		.regs = {
@@ -1091,6 +1202,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AXISR,
 		.name = "axisr",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -1100,6 +1212,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AXISW,
 		.name = "axisw",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -1109,6 +1222,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_EQOSR,
 		.name = "eqosr",
 		.sid = TEGRA194_SID_EQOS,
 		.regs = {
@@ -1119,6 +1233,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 		},
 	}, {
 		.name = "eqosw",
+		.id = TEGRA194_MEMORY_CLIENT_EQOSW,
 		.sid = TEGRA194_SID_EQOS,
 		.regs = {
 			.sid = {
@@ -1127,6 +1242,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_UFSHCR,
 		.name = "ufshcr",
 		.sid = TEGRA194_SID_UFSHC,
 		.regs = {
@@ -1136,6 +1252,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_UFSHCW,
 		.name = "ufshcw",
 		.sid = TEGRA194_SID_UFSHC,
 		.regs = {
@@ -1145,6 +1262,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDISPLAYR,
 		.name = "nvdisplayr",
 		.sid = TEGRA194_SID_NVDISPLAY,
 		.regs = {
@@ -1154,6 +1272,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_BPMPR,
 		.name = "bpmpr",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
@@ -1163,6 +1282,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_BPMPW,
 		.name = "bpmpw",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
@@ -1172,6 +1292,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_BPMPDMAR,
 		.name = "bpmpdmar",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
@@ -1181,6 +1302,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_BPMPDMAW,
 		.name = "bpmpdmaw",
 		.sid = TEGRA194_SID_BPMP,
 		.regs = {
@@ -1190,6 +1312,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AONR,
 		.name = "aonr",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
@@ -1199,6 +1322,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AONW,
 		.name = "aonw",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
@@ -1208,6 +1332,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AONDMAR,
 		.name = "aondmar",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
@@ -1217,6 +1342,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_AONDMAW,
 		.name = "aondmaw",
 		.sid = TEGRA194_SID_AON,
 		.regs = {
@@ -1226,6 +1352,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SCER,
 		.name = "scer",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
@@ -1235,6 +1362,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SCEW,
 		.name = "scew",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
@@ -1244,6 +1372,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SCEDMAR,
 		.name = "scedmar",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
@@ -1253,6 +1382,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_SCEDMAW,
 		.name = "scedmaw",
 		.sid = TEGRA194_SID_SCE,
 		.regs = {
@@ -1262,6 +1392,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_APEDMAR,
 		.name = "apedmar",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
@@ -1271,6 +1402,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_APEDMAW,
 		.name = "apedmaw",
 		.sid = TEGRA194_SID_APE,
 		.regs = {
@@ -1280,6 +1412,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDISPLAYR1,
 		.name = "nvdisplayr1",
 		.sid = TEGRA194_SID_NVDISPLAY,
 		.regs = {
@@ -1289,6 +1422,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VICSRD1,
 		.name = "vicsrd1",
 		.sid = TEGRA194_SID_VIC,
 		.regs = {
@@ -1298,6 +1432,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDECSRD1,
 		.name = "nvdecsrd1",
 		.sid = TEGRA194_SID_NVDEC,
 		.regs = {
@@ -1307,6 +1442,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU0R,
 		.name = "miu0r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1317,6 +1453,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 		},
 	}, {
 		.name = "miu0w",
+		.id = TEGRA194_MEMORY_CLIENT_MIU0W,
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
 			.sid = {
@@ -1325,6 +1462,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU1R,
 		.name = "miu1r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1334,6 +1472,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU1W,
 		.name = "miu1w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1343,6 +1482,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU2R,
 		.name = "miu2r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1352,6 +1492,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU2W,
 		.name = "miu2w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1361,6 +1502,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU3R,
 		.name = "miu3r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1370,6 +1512,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU3W,
 		.name = "miu3w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1379,6 +1522,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU4R,
 		.name = "miu4r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1388,6 +1532,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU4W,
 		.name = "miu4w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1397,6 +1542,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DPMUR,
 		.name = "dpmur",
 		.sid = TEGRA194_SID_PASSTHROUGH,
 		.regs = {
@@ -1406,6 +1552,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VIFALR,
 		.name = "vifalr",
 		.sid = TEGRA194_SID_VI_FALCON,
 		.regs = {
@@ -1415,6 +1562,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_VIFALW,
 		.name = "vifalw",
 		.sid = TEGRA194_SID_VI_FALCON,
 		.regs = {
@@ -1424,6 +1572,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA0RDA,
 		.name = "dla0rda",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
@@ -1433,6 +1582,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA0FALRDB,
 		.name = "dla0falrdb",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
@@ -1442,6 +1592,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA0WRA,
 		.name = "dla0wra",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
@@ -1451,6 +1602,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA0FALWRB,
 		.name = "dla0falwrb",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
@@ -1460,6 +1612,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA1RDA,
 		.name = "dla1rda",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
@@ -1469,6 +1622,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA1FALRDB,
 		.name = "dla1falrdb",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
@@ -1478,6 +1632,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA1WRA,
 		.name = "dla1wra",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
@@ -1487,6 +1642,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA1FALWRB,
 		.name = "dla1falwrb",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
@@ -1496,6 +1652,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0RDA,
 		.name = "pva0rda",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1505,6 +1662,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0RDB,
 		.name = "pva0rdb",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1514,6 +1672,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0RDC,
 		.name = "pva0rdc",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1523,6 +1682,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0WRA,
 		.name = "pva0wra",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1532,6 +1692,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0WRB,
 		.name = "pva0wrb",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1541,6 +1702,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0WRC,
 		.name = "pva0wrc",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1550,6 +1712,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1RDA,
 		.name = "pva1rda",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1559,6 +1722,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1RDB,
 		.name = "pva1rdb",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1568,6 +1732,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1RDC,
 		.name = "pva1rdc",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1577,6 +1742,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1WRA,
 		.name = "pva1wra",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1586,6 +1752,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1WRB,
 		.name = "pva1wrb",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1595,6 +1762,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1WRC,
 		.name = "pva1wrc",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1604,6 +1772,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_RCER,
 		.name = "rcer",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
@@ -1613,6 +1782,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_RCEW,
 		.name = "rcew",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
@@ -1622,6 +1792,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_RCEDMAR,
 		.name = "rcedmar",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
@@ -1631,6 +1802,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_RCEDMAW,
 		.name = "rcedmaw",
 		.sid = TEGRA194_SID_RCE,
 		.regs = {
@@ -1640,6 +1812,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENC1SRD,
 		.name = "nvenc1srd",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
@@ -1649,6 +1822,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENC1SWR,
 		.name = "nvenc1swr",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
@@ -1658,6 +1832,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE0R,
 		.name = "pcie0r",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
@@ -1667,6 +1842,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE0W,
 		.name = "pcie0w",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
@@ -1676,6 +1852,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE1R,
 		.name = "pcie1r",
 		.sid = TEGRA194_SID_PCIE1,
 		.regs = {
@@ -1685,6 +1862,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE1W,
 		.name = "pcie1w",
 		.sid = TEGRA194_SID_PCIE1,
 		.regs = {
@@ -1694,6 +1872,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE2AR,
 		.name = "pcie2ar",
 		.sid = TEGRA194_SID_PCIE2,
 		.regs = {
@@ -1703,6 +1882,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE2AW,
 		.name = "pcie2aw",
 		.sid = TEGRA194_SID_PCIE2,
 		.regs = {
@@ -1712,6 +1892,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE3R,
 		.name = "pcie3r",
 		.sid = TEGRA194_SID_PCIE3,
 		.regs = {
@@ -1721,6 +1902,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE3W,
 		.name = "pcie3w",
 		.sid = TEGRA194_SID_PCIE3,
 		.regs = {
@@ -1730,6 +1912,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE4R,
 		.name = "pcie4r",
 		.sid = TEGRA194_SID_PCIE4,
 		.regs = {
@@ -1739,6 +1922,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE4W,
 		.name = "pcie4w",
 		.sid = TEGRA194_SID_PCIE4,
 		.regs = {
@@ -1748,6 +1932,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE5R,
 		.name = "pcie5r",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
@@ -1757,6 +1942,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE5W,
 		.name = "pcie5w",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
@@ -1766,6 +1952,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPFALW,
 		.name = "ispfalw",
 		.sid = TEGRA194_SID_ISP_FALCON,
 		.regs = {
@@ -1775,6 +1962,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA0RDA1,
 		.name = "dla0rda1",
 		.sid = TEGRA194_SID_NVDLA0,
 		.regs = {
@@ -1784,6 +1972,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_DLA1RDA1,
 		.name = "dla1rda1",
 		.sid = TEGRA194_SID_NVDLA1,
 		.regs = {
@@ -1793,6 +1982,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0RDA1,
 		.name = "pva0rda1",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1802,6 +1992,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA0RDB1,
 		.name = "pva0rdb1",
 		.sid = TEGRA194_SID_PVA0,
 		.regs = {
@@ -1811,6 +2002,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1RDA1,
 		.name = "pva1rda1",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1820,6 +2012,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PVA1RDB1,
 		.name = "pva1rdb1",
 		.sid = TEGRA194_SID_PVA1,
 		.regs = {
@@ -1829,6 +2022,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE5R1,
 		.name = "pcie5r1",
 		.sid = TEGRA194_SID_PCIE5,
 		.regs = {
@@ -1838,6 +2032,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENCSRD1,
 		.name = "nvencsrd1",
 		.sid = TEGRA194_SID_NVENC,
 		.regs = {
@@ -1847,6 +2042,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVENC1SRD1,
 		.name = "nvenc1srd1",
 		.sid = TEGRA194_SID_NVENC1,
 		.regs = {
@@ -1856,6 +2052,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_ISPRA1,
 		.name = "ispra1",
 		.sid = TEGRA194_SID_ISP,
 		.regs = {
@@ -1865,6 +2062,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_PCIE0R1,
 		.name = "pcie0r1",
 		.sid = TEGRA194_SID_PCIE0,
 		.regs = {
@@ -1874,6 +2072,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDEC1SRD,
 		.name = "nvdec1srd",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
@@ -1883,6 +2082,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDEC1SRD1,
 		.name = "nvdec1srd1",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
@@ -1892,6 +2092,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_NVDEC1SWR,
 		.name = "nvdec1swr",
 		.sid = TEGRA194_SID_NVDEC1,
 		.regs = {
@@ -1901,6 +2102,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU5R,
 		.name = "miu5r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1910,6 +2112,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU5W,
 		.name = "miu5w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1919,6 +2122,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU6R,
 		.name = "miu6r",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
@@ -1928,6 +2132,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
 			},
 		},
 	}, {
+		.id = TEGRA194_MEMORY_CLIENT_MIU6W,
 		.name = "miu6w",
 		.sid = TEGRA194_SID_MIU,
 		.regs = {
-- 
2.30.2



From daniel.lezcano at linaro.org  Tue Apr 20 18:11:49 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 20 Apr 2021 19:11:49 +0200
Subject: [PATCH v2] thermal: mediatek: add sensors-support
In-Reply-To: <20210420155410.132141-1-linux@fw-web.de>
References: <20210420155410.132141-1-linux@fw-web.de>
Message-ID: <34942537-79f4-bfab-43cc-7af100d0a433@linaro.org>

On 20/04/2021 17:54, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w at public-files.de>
> 
> add HWMON-support to mediateks thermal driver to allow lm-sensors
> userspace tools read soc temperature
> 
> Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> ---
> v2: drop ifdef and used devm_thermal_add_hwmon_sysfs
> ---
>  drivers/thermal/mtk_thermal.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 149c6d7fd5a0..32be8a715c7d 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -23,6 +23,8 @@
>  #include <linux/reset.h>
>  #include <linux/types.h>
>  
> +#include "thermal_hwmon.h"
> +
>  /* AUXADC Registers */
>  #define AUXADC_CON1_SET_V	0x008
>  #define AUXADC_CON1_CLR_V	0x00c
> @@ -1087,6 +1089,11 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>  		goto err_disable_clk_peri_therm;
>  	}
>  
> +	tzdev->tzp->no_hwmon = false;

	^^^^^^ you can drop this line

> +	ret = devm_thermal_add_hwmon_sysfs(tzdev);
> +	if (ret)
> +		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
> +
>  	return 0;
>  
>  err_disable_clk_peri_therm:
> 


-- 
<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 linux at fw-web.de  Tue Apr 20 18:16:25 2021
From: linux at fw-web.de (Frank Wunderlich)
Date: Tue, 20 Apr 2021 19:16:25 +0200
Subject: [PATCH v3] thermal: mediatek: add sensors-support
Message-ID: <20210420171625.133860-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w at public-files.de>

add HWMON-support to mediateks thermal driver to allow lm-sensors
userspace tools read soc temperature

Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
---
v3: drop no_hwmon
v2: drop ifdef and used devm_thermal_add_hwmon_sysfs
---
 drivers/thermal/mtk_thermal.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 149c6d7fd5a0..32be8a715c7d 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -23,6 +23,8 @@
 #include <linux/reset.h>
 #include <linux/types.h>
 
+#include "thermal_hwmon.h"
+
 /* AUXADC Registers */
 #define AUXADC_CON1_SET_V	0x008
 #define AUXADC_CON1_CLR_V	0x00c
@@ -1087,6 +1089,11 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 		goto err_disable_clk_peri_therm;
 	}
 
+	tzdev->tzp->no_hwmon = false;
+	ret = devm_thermal_add_hwmon_sysfs(tzdev);
+	if (ret)
+		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
+
 	return 0;
 
 err_disable_clk_peri_therm:
-- 
2.25.1



From linux at fw-web.de  Tue Apr 20 18:23:08 2021
From: linux at fw-web.de (Frank Wunderlich)
Date: Tue, 20 Apr 2021 19:23:08 +0200
Subject: [PATCH v3] thermal: mediatek: add sensors-support
Message-ID: <20210420172308.134685-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w at public-files.de>

add HWMON-support to mediateks thermal driver to allow lm-sensors
userspace tools read soc temperature

Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
---
v3: drop no_hwmon - now really, sorry
v2: drop ifdef and used devm_thermal_add_hwmon_sysfs
---
 drivers/thermal/mtk_thermal.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 149c6d7fd5a0..85964988684b 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -23,6 +23,8 @@
 #include <linux/reset.h>
 #include <linux/types.h>
 
+#include "thermal_hwmon.h"
+
 /* AUXADC Registers */
 #define AUXADC_CON1_SET_V	0x008
 #define AUXADC_CON1_CLR_V	0x00c
@@ -1087,6 +1089,10 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 		goto err_disable_clk_peri_therm;
 	}
 
+	ret = devm_thermal_add_hwmon_sysfs(tzdev);
+	if (ret)
+		dev_err(&pdev->dev, "error in thermal_add_hwmon_sysfs");
+
 	return 0;
 
 err_disable_clk_peri_therm:
-- 
2.25.1



From willy at infradead.org  Tue Apr 20 18:22:45 2021
From: willy at infradead.org (Matthew Wilcox (Oracle))
Date: Tue, 20 Apr 2021 18:22:45 +0100
Subject: [PATCH] arm64: Show three registers per line
Message-ID: <20210420172245.3679077-1-willy@infradead.org>

Displaying two registers per line takes 15 lines.  That improves to just
10 lines if we display three registers per line, which reduces the amount
of information lost when oopses are cut off.  It stays within 80 columns
and matches x86-64.

Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
---
 arch/arm64/kernel/process.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6e60aa3b5ea9..aff5a2c12297 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -294,13 +294,10 @@ void __show_regs(struct pt_regs *regs)
 	i = top_reg;
 
 	while (i >= 0) {
-		printk("x%-2d: %016llx ", i, regs->regs[i]);
-		i--;
+		printk("x%-2d: %016llx", i, regs->regs[i]);
 
-		if (i % 2 == 0) {
-			pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
-			i--;
-		}
+		while (i-- % 3)
+			pr_cont(" x%-2d: %016llx", i, regs->regs[i]);
 
 		pr_cont("\n");
 	}
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:09 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:09 +0200
Subject: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults
Message-ID: <20210420172619.3782831-1-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Hi,

this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.

The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappings to when devices are attached
to the SMMU. This works by making the SMMU driver coordinate with the
memory controller driver on when to start enforcing SMMU translations.
This makes Tegra behave in a more standard way and pushes the code to
deal with the Tegra-specific programming into the NVIDIA SMMU
implementation.

Compared to the original version of these patches, I've split the
preparatory work into a separate patch series because it became very
large and will be mostly uninteresting for this audience.

Patch 1 provides a mechanism to program SID overrides at runtime. Patch
2 updates the ARM SMMU device tree bindings to include the Tegra186
compatible string as suggested by Robin during review.

Patches 3 and 4 create the fundamentals in the SMMU driver to support
this and also make this functionality available on Tegra186. Patch 5
hooks the ARM SMMU up to the memory controller so that the memory client
stream ID overrides can be programmed at the right time.

Patch 6 extends this mechanism to Tegra186 and patches 7-9 enable all of
this through device tree updates. Patch 10 is included here to show how
SMMU will be enabled for display controllers. However, it cannot be
applied yet because the code to create identity mappings for potentially
live framebuffers hasn't been merged yet.

The end result is that various peripherals will have SMMU enabled, while
the display controllers will keep using passthrough, as initially set up
by firmware. Once the device tree bindings have been accepted and the
SMMU driver has been updated to create identity mappings for the display
controllers, they can be hooked up to the SMMU and the code in this
series will automatically program the SID overrides to enable SMMU
translations at the right time.

Note that the series creates a compile time dependency between the
memory controller and IOMMU trees. If it helps I can provide a branch
for each tree, modelling the dependency, once the series has been
reviewed.

Changes in v2:
- split off the preparatory work into a separate series (that needs to
  be applied first)
- address review comments by Robin

Thierry

Thierry Reding (10):
  memory: tegra: Implement SID override programming
  dt-bindings: arm-smmu: Add Tegra186 compatible string
  iommu/arm-smmu: Implement ->probe_finalize()
  iommu/arm-smmu: tegra: Detect number of instances at runtime
  iommu/arm-smmu: tegra: Implement SID override programming
  iommu/arm-smmu: Use Tegra implementation on Tegra186
  arm64: tegra: Use correct compatible string for Tegra186 SMMU
  arm64: tegra: Hook up memory controller to SMMU on Tegra186
  arm64: tegra: Enable SMMU support on Tegra194
  arm64: tegra: Enable SMMU support for display on Tegra194

 .../devicetree/bindings/iommu/arm,smmu.yaml   |  11 +-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi      |   4 +-
 arch/arm64/boot/dts/nvidia/tegra194.dtsi      | 166 ++++++++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c    |   3 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c  |  90 ++++++++--
 drivers/iommu/arm/arm-smmu/arm-smmu.c         |  13 ++
 drivers/iommu/arm/arm-smmu/arm-smmu.h         |   1 +
 drivers/memory/tegra/mc.c                     |   9 +
 drivers/memory/tegra/tegra186.c               |  72 ++++++++
 include/soc/tegra/mc.h                        |   3 +
 10 files changed, 349 insertions(+), 23 deletions(-)

-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:10 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:10 +0200
Subject: [PATCH v2 01/10] memory: tegra: Implement SID override programming
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-2-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and programs the SID specified in device tree, which corresponds
to the SID used for the SMMU context banks for the device.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/memory/tegra/mc.c       |  9 +++++
 drivers/memory/tegra/tegra186.c | 72 +++++++++++++++++++++++++++++++++
 include/soc/tegra/mc.h          |  3 ++
 3 files changed, 84 insertions(+)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index c854639cf30c..bace5ecfe770 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -97,6 +97,15 @@ struct tegra_mc *devm_tegra_memory_controller_get(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(devm_tegra_memory_controller_get);
 
+int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
+{
+	if (mc->soc->ops && mc->soc->ops->probe_device)
+		return mc->soc->ops->probe_device(mc, dev);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tegra_mc_probe_device);
+
 static int tegra_mc_block_dma_common(struct tegra_mc *mc,
 				     const struct tegra_mc_reset *rst)
 {
diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index 1f87915ccd62..e65eac5764d4 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -4,6 +4,7 @@
  */
 
 #include <linux/io.h>
+#include <linux/iommu.h>
 #include <linux/module.h>
 #include <linux/mod_devicetable.h>
 #include <linux/of_device.h>
@@ -15,6 +16,10 @@
 #include <dt-bindings/memory/tegra186-mc.h>
 #endif
 
+#define MC_SID_STREAMID_OVERRIDE_MASK GENMASK(7, 0)
+#define MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED BIT(16)
+#define MC_SID_STREAMID_SECURITY_OVERRIDE BIT(8)
+
 static void tegra186_mc_program_sid(struct tegra_mc *mc)
 {
 	unsigned int i;
@@ -66,10 +71,77 @@ static int tegra186_mc_resume(struct tegra_mc *mc)
 	return 0;
 }
 
+static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
+					    const struct tegra_mc_client *client,
+					    unsigned int sid)
+{
+	u32 value, old;
+
+	value = readl(mc->regs + client->regs.sid.security);
+	if ((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0) {
+		/*
+		 * If the secure firmware has locked this down the override
+		 * for this memory client, there's nothing we can do here.
+		 */
+		if (value & MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED)
+			return;
+
+		/*
+		 * Otherwise, try to set the override itself. Typically the
+		 * secure firmware will never have set this configuration.
+		 * Instead, it will either have disabled write access to
+		 * this field, or it will already have set an explicit
+		 * override itself.
+		 */
+		WARN_ON((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0);
+
+		value |= MC_SID_STREAMID_SECURITY_OVERRIDE;
+		writel(value, mc->regs + client->regs.sid.security);
+	}
+
+	value = readl(mc->regs + client->regs.sid.override);
+	old = value & MC_SID_STREAMID_OVERRIDE_MASK;
+
+	if (old != sid) {
+		dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
+			client->name, sid);
+		writel(sid, mc->regs + client->regs.sid.override);
+	}
+}
+
+static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
+{
+#if IS_ENABLED(CONFIG_IOMMU_API)
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct of_phandle_args args;
+	unsigned int i, index = 0;
+
+	while (!of_parse_phandle_with_args(dev->of_node, "interconnects", "#interconnect-cells",
+					   index, &args)) {
+		if (args.np == mc->dev->of_node && args.args_count != 0) {
+			for (i = 0; i < mc->soc->num_clients; i++) {
+				const struct tegra_mc_client *client = &mc->soc->clients[i];
+
+				if (client->id == args.args[0]) {
+					u32 sid = fwspec->ids[0] & MC_SID_STREAMID_OVERRIDE_MASK;
+
+					tegra186_mc_client_sid_override(mc, client, sid);
+				}
+			}
+		}
+
+		index++;
+	}
+#endif
+
+	return 0;
+}
+
 const struct tegra_mc_ops tegra186_mc_ops = {
 	.probe = tegra186_mc_probe,
 	.remove = tegra186_mc_remove,
 	.resume = tegra186_mc_resume,
+	.probe_device = tegra186_mc_probe_device,
 };
 
 #if defined(CONFIG_ARCH_TEGRA_186_SOC)
diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
index 1387747d574b..bbad6330008b 100644
--- a/include/soc/tegra/mc.h
+++ b/include/soc/tegra/mc.h
@@ -176,6 +176,7 @@ struct tegra_mc_ops {
 	int (*suspend)(struct tegra_mc *mc);
 	int (*resume)(struct tegra_mc *mc);
 	irqreturn_t (*handle_irq)(int irq, void *data);
+	int (*probe_device)(struct tegra_mc *mc, struct device *dev);
 };
 
 struct tegra_mc_soc {
@@ -240,4 +241,6 @@ devm_tegra_memory_controller_get(struct device *dev)
 }
 #endif
 
+int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
+
 #endif /* __SOC_TEGRA_MC_H__ */
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:11 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:11 +0200
Subject: [PATCH v2 02/10] dt-bindings: arm-smmu: Add Tegra186 compatible string
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-3-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.

Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this, they have to be
programmed identically so that the memory controller can interleave
memory accesses between them.

Add the Tegra186 compatible string to make sure the interoperation
with the memory controller can be enabled on that SoC generation.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 9d27aa5111d4..1181b590db71 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -54,8 +54,14 @@ properties:
           - const: arm,mmu-500
       - description: NVIDIA SoCs that program two ARM MMU-500s identically
         items:
+      - description: NVIDIA SoCs that require memory controller interaction
+          and may program multiple ARM MMU-500s identically with the memory
+          controller interleaving translations between multiple instances
+          for improved performance.
+        items:
           - enum:
-              - nvidia,tegra194-smmu
+              - const: nvidia,tegra194-smmu
+              - const: nvidia,tegra186-smmu
           - const: nvidia,smmu-500
       - items:
           - const: arm,mmu-500
@@ -165,10 +171,11 @@ allOf:
           contains:
             enum:
               - nvidia,tegra194-smmu
+              - nvidia,tegra186-smmu
     then:
       properties:
         reg:
-          minItems: 2
+          minItems: 1
           maxItems: 2
     else:
       properties:
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:12 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:12 +0200
Subject: [PATCH v2 03/10] iommu/arm-smmu: Implement ->probe_finalize()
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-4-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
-remove unnecessarily paranoid check
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 +++++++++++++
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 6f72c4d208ca..d20ce4d57df2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1450,6 +1450,18 @@ static void arm_smmu_release_device(struct device *dev)
 	iommu_fwspec_free(dev);
 }
 
+static void arm_smmu_probe_finalize(struct device *dev)
+{
+	struct arm_smmu_master_cfg *cfg;
+	struct arm_smmu_device *smmu;
+
+	cfg = dev_iommu_priv_get(dev);
+	smmu = cfg->smmu;
+
+	if (smmu->impl->probe_finalize)
+		smmu->impl->probe_finalize(smmu, dev);
+}
+
 static struct iommu_group *arm_smmu_device_group(struct device *dev)
 {
 	struct arm_smmu_master_cfg *cfg = dev_iommu_priv_get(dev);
@@ -1569,6 +1581,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.iova_to_phys		= arm_smmu_iova_to_phys,
 	.probe_device		= arm_smmu_probe_device,
 	.release_device		= arm_smmu_release_device,
+	.probe_finalize		= arm_smmu_probe_finalize,
 	.device_group		= arm_smmu_device_group,
 	.enable_nesting		= arm_smmu_enable_nesting,
 	.set_pgtable_quirks	= arm_smmu_set_pgtable_quirks,
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index c31a59d35c64..147c95e7c59c 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -439,6 +439,7 @@ struct arm_smmu_impl {
 				  struct device *dev, int start);
 	void (*write_s2cr)(struct arm_smmu_device *smmu, int idx);
 	void (*write_sctlr)(struct arm_smmu_device *smmu, int idx, u32 reg);
+	void (*probe_finalize)(struct arm_smmu_device *smmu, struct device *dev);
 };
 
 #define INVALID_SMENDX			-1
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:13 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:13 +0200
Subject: [PATCH v2 04/10] iommu/arm-smmu: tegra: Detect number of instances at
 runtime
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-5-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Parse the reg property in device tree and detect the number of instances
represented by a device tree node. This is subsequently needed in order
to support single-instance SMMUs with the Tegra implementation because
additional programming is needed to properly configure the SID override
registers in the memory controller.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- provide a separate implementation to simplify single instances
---
 drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 58 ++++++++++++++------
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
index 29117444e5a0..0e547b29143d 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
@@ -20,13 +20,19 @@
  * The third instance usage is through standard arm-smmu driver itself and
  * is out of scope of this implementation.
  */
-#define NUM_SMMU_INSTANCES 2
+#define MAX_SMMU_INSTANCES 2
 
 struct nvidia_smmu {
-	struct arm_smmu_device	smmu;
-	void __iomem		*bases[NUM_SMMU_INSTANCES];
+	struct arm_smmu_device smmu;
+	void __iomem *bases[MAX_SMMU_INSTANCES];
+	unsigned int num_instances;
 };
 
+static inline struct nvidia_smmu *to_nvidia_smmu(struct arm_smmu_device *smmu)
+{
+	return container_of(smmu, struct nvidia_smmu, smmu);
+}
+
 static inline void __iomem *nvidia_smmu_page(struct arm_smmu_device *smmu,
 					     unsigned int inst, int page)
 {
@@ -47,9 +53,10 @@ static u32 nvidia_smmu_read_reg(struct arm_smmu_device *smmu,
 static void nvidia_smmu_write_reg(struct arm_smmu_device *smmu,
 				  int page, int offset, u32 val)
 {
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
 	unsigned int i;
 
-	for (i = 0; i < NUM_SMMU_INSTANCES; i++) {
+	for (i = 0; i < nvidia->num_instances; i++) {
 		void __iomem *reg = nvidia_smmu_page(smmu, i, page) + offset;
 
 		writel_relaxed(val, reg);
@@ -67,9 +74,10 @@ static u64 nvidia_smmu_read_reg64(struct arm_smmu_device *smmu,
 static void nvidia_smmu_write_reg64(struct arm_smmu_device *smmu,
 				    int page, int offset, u64 val)
 {
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
 	unsigned int i;
 
-	for (i = 0; i < NUM_SMMU_INSTANCES; i++) {
+	for (i = 0; i < nvidia->num_instances; i++) {
 		void __iomem *reg = nvidia_smmu_page(smmu, i, page) + offset;
 
 		writeq_relaxed(val, reg);
@@ -79,6 +87,7 @@ static void nvidia_smmu_write_reg64(struct arm_smmu_device *smmu,
 static void nvidia_smmu_tlb_sync(struct arm_smmu_device *smmu, int page,
 				 int sync, int status)
 {
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
 	unsigned int delay;
 
 	arm_smmu_writel(smmu, page, sync, 0);
@@ -90,7 +99,7 @@ static void nvidia_smmu_tlb_sync(struct arm_smmu_device *smmu, int page,
 			u32 val = 0;
 			unsigned int i;
 
-			for (i = 0; i < NUM_SMMU_INSTANCES; i++) {
+			for (i = 0; i < nvidia->num_instances; i++) {
 				void __iomem *reg;
 
 				reg = nvidia_smmu_page(smmu, i, page) + status;
@@ -112,9 +121,10 @@ static void nvidia_smmu_tlb_sync(struct arm_smmu_device *smmu, int page,
 
 static int nvidia_smmu_reset(struct arm_smmu_device *smmu)
 {
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
 	unsigned int i;
 
-	for (i = 0; i < NUM_SMMU_INSTANCES; i++) {
+	for (i = 0; i < nvidia->num_instances; i++) {
 		u32 val;
 		void __iomem *reg = nvidia_smmu_page(smmu, i, ARM_SMMU_GR0) +
 				    ARM_SMMU_GR0_sGFSR;
@@ -157,8 +167,9 @@ static irqreturn_t nvidia_smmu_global_fault(int irq, void *dev)
 	unsigned int inst;
 	irqreturn_t ret = IRQ_NONE;
 	struct arm_smmu_device *smmu = dev;
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
 
-	for (inst = 0; inst < NUM_SMMU_INSTANCES; inst++) {
+	for (inst = 0; inst < nvidia->num_instances; inst++) {
 		irqreturn_t irq_ret;
 
 		irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
@@ -202,11 +213,13 @@ static irqreturn_t nvidia_smmu_context_fault(int irq, void *dev)
 	struct arm_smmu_device *smmu;
 	struct iommu_domain *domain = dev;
 	struct arm_smmu_domain *smmu_domain;
+	struct nvidia_smmu *nvidia;
 
 	smmu_domain = container_of(domain, struct arm_smmu_domain, domain);
 	smmu = smmu_domain->smmu;
+	nvidia = to_nvidia_smmu(smmu);
 
-	for (inst = 0; inst < NUM_SMMU_INSTANCES; inst++) {
+	for (inst = 0; inst < nvidia->num_instances; inst++) {
 		irqreturn_t irq_ret;
 
 		/*
@@ -235,12 +248,17 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
 	.context_fault = nvidia_smmu_context_fault,
 };
 
+static const struct arm_smmu_impl nvidia_smmu_single_impl = {
+	.probe_finalize = nvidia_smmu_probe_finalize,
+};
+
 struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
 {
 	struct resource *res;
 	struct device *dev = smmu->dev;
 	struct nvidia_smmu *nvidia_smmu;
 	struct platform_device *pdev = to_platform_device(dev);
+	unsigned int i;
 
 	nvidia_smmu = devm_krealloc(dev, smmu, sizeof(*nvidia_smmu), GFP_KERNEL);
 	if (!nvidia_smmu)
@@ -248,16 +266,24 @@ struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
 
 	/* Instance 0 is ioremapped by arm-smmu.c. */
 	nvidia_smmu->bases[0] = smmu->base;
+	nvidia_smmu->num_instances++;
 
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-	if (!res)
-		return ERR_PTR(-ENODEV);
+	for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
+		res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+		if (!res)
+			break;
 
-	nvidia_smmu->bases[1] = devm_ioremap_resource(dev, res);
-	if (IS_ERR(nvidia_smmu->bases[1]))
-		return ERR_CAST(nvidia_smmu->bases[1]);
+		nvidia_smmu->bases[i] = devm_ioremap_resource(dev, res);
+		if (IS_ERR(nvidia_smmu->bases[i]))
+			return ERR_CAST(nvidia_smmu->bases[i]);
+
+		nvidia_smmu->num_instances++;
+	}
 
-	nvidia_smmu->smmu.impl = &nvidia_smmu_impl;
+	if (nvidia_smmu->num_instances == 1)
+		nvidia_smmu->smmu.impl = &nvidia_smmu_single_impl;
+	else
+		nvidia_smmu->smmu.impl = &nvidia_smmu_impl;
 
 	return &nvidia_smmu->smmu;
 }
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:14 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:14 +0200
Subject: [PATCH v2 05/10] iommu/arm-smmu: tegra: Implement SID override
 programming
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-6-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The secure firmware keeps some SID override registers set as passthrough
in order to allow devices such as the display controller to operate with
no knowledge of SMMU translations until an operating system driver takes
over. This is needed in order to seamlessly transition from the firmware
framebuffer to the OS framebuffer.

Upon successfully attaching a device to the SMMU and in the process
creating identity mappings for memory regions that are being accessed,
the Tegra implementation will call into the memory controller driver to
program the override SIDs appropriately.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 32 ++++++++++++++++++--
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
index 0e547b29143d..01e9b50b10a1 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
@@ -7,6 +7,8 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
+#include <soc/tegra/mc.h>
+
 #include "arm-smmu.h"
 
 /*
@@ -15,10 +17,17 @@
  * interleaved IOVA accesses across them and translates accesses from
  * non-isochronous HW devices.
  * Third one is used for translating accesses from isochronous HW devices.
+ *
+ * In addition, the SMMU driver needs to coordinate with the memory controller
+ * driver to ensure that the right SID override is programmed for any given
+ * memory client. This is necessary to allow for use-case such as seamlessly
+ * handing over the display controller configuration from the firmware to the
+ * kernel.
+ *
  * This implementation supports programming of the two instances that must
- * be programmed identically.
- * The third instance usage is through standard arm-smmu driver itself and
- * is out of scope of this implementation.
+ * be programmed identically and takes care of invoking the memory controller
+ * driver for SID override programming after devices have been attached to an
+ * SMMU instance.
  */
 #define MAX_SMMU_INSTANCES 2
 
@@ -26,6 +35,7 @@ struct nvidia_smmu {
 	struct arm_smmu_device smmu;
 	void __iomem *bases[MAX_SMMU_INSTANCES];
 	unsigned int num_instances;
+	struct tegra_mc *mc;
 };
 
 static inline struct nvidia_smmu *to_nvidia_smmu(struct arm_smmu_device *smmu)
@@ -237,6 +247,17 @@ static irqreturn_t nvidia_smmu_context_fault(int irq, void *dev)
 	return ret;
 }
 
+static void nvidia_smmu_probe_finalize(struct arm_smmu_device *smmu, struct device *dev)
+{
+	struct nvidia_smmu *nvidia = to_nvidia_smmu(smmu);
+	int err;
+
+	err = tegra_mc_probe_device(nvidia->mc, dev);
+	if (err < 0)
+		dev_err(smmu->dev, "memory controller probe failed for %s: %d\n",
+			dev_name(dev), err);
+}
+
 static const struct arm_smmu_impl nvidia_smmu_impl = {
 	.read_reg = nvidia_smmu_read_reg,
 	.write_reg = nvidia_smmu_write_reg,
@@ -246,6 +267,7 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
 	.tlb_sync = nvidia_smmu_tlb_sync,
 	.global_fault = nvidia_smmu_global_fault,
 	.context_fault = nvidia_smmu_context_fault,
+	.probe_finalize = nvidia_smmu_probe_finalize,
 };
 
 static const struct arm_smmu_impl nvidia_smmu_single_impl = {
@@ -264,6 +286,10 @@ struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
 	if (!nvidia_smmu)
 		return ERR_PTR(-ENOMEM);
 
+	nvidia_smmu->mc = devm_tegra_memory_controller_get(dev);
+	if (IS_ERR(nvidia_smmu->mc))
+		return ERR_CAST(nvidia_smmu->mc);
+
 	/* Instance 0 is ioremapped by arm-smmu.c. */
 	nvidia_smmu->bases[0] = smmu->base;
 	nvidia_smmu->num_instances++;
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:16 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:16 +0200
Subject: [PATCH v2 07/10] arm64: tegra: Use correct compatible string for
 Tegra186 SMMU
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-8-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The SMMU found on Tegra186 requires interoperation with the memory
controller in order to program stream ID overrides. The generic ARM SMMU
500 compatible is therefore inaccurate. Replace it with a more correct,
SoC-specific compatible string.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 9f75bbf00cf7..a173f40256ae 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1082,7 +1082,7 @@ pci at 3,0 {
 	};
 
 	smmu: iommu at 12000000 {
-		compatible = "arm,mmu-500";
+		compatible = "nvidia,tegra186-smmu", "nvidia,smmu-500";
 		reg = <0 0x12000000 0 0x800000>;
 		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:15 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:15 +0200
Subject: [PATCH v2 06/10] iommu/arm-smmu: Use Tegra implementation on Tegra186
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-7-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Tegra186 requires the same SID override programming as Tegra194 in order
to seamlessly transition from the firmware framebuffer to the Linux
framebuffer, so the Tegra implementation needs to be used on Tegra186
devices as well.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 136872e77195..9f465e146799 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -211,7 +211,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
 	if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
 		smmu->impl = &calxeda_impl;
 
-	if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
+	if (of_device_is_compatible(np, "nvidia,tegra194-smmu") ||
+	    of_device_is_compatible(np, "nvidia,tegra186-smmu"))
 		return nvidia_smmu_impl_init(smmu);
 
 	smmu = qcom_smmu_impl_init(smmu);
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:17 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:17 +0200
Subject: [PATCH v2 08/10] arm64: tegra: Hook up memory controller to SMMU on
 Tegra186
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-9-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

On Tegra186 and later, the memory controller needs to be programmed in
coordination with any of the ARM SMMU instances to configure the stream
ID used for each memory client.

To support this, add a phandle reference to the memory controller to the
SMMU device tree node.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index a173f40256ae..d02f6bf3e2ca 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1152,6 +1152,8 @@ smmu: iommu at 12000000 {
 		stream-match-mask = <0x7f80>;
 		#global-interrupts = <1>;
 		#iommu-cells = <1>;
+
+		nvidia,memory-controller = <&mc>;
 	};
 
 	host1x at 13e00000 {
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:18 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:18 +0200
Subject: [PATCH v2 09/10] arm64: tegra: Enable SMMU support on Tegra194
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-10-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Add the device tree node for the dual-SMMU found on Tegra194 and hook up
peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86 ++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 4d37ee0ea4d1..6ed296e27158 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -62,6 +62,7 @@ ethernet at 2490000 {
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_EQOSR &emc>,
 					<&mc TEGRA194_MEMORY_CLIENT_EQOSW &emc>;
 			interconnect-names = "dma-mem", "write";
+			iommus = <&smmu TEGRA194_SID_EQOS>;
 			status = "disabled";
 
 			snps,write-requests = <1>;
@@ -733,6 +734,7 @@ sdmmc1: mmc at 3400000 {
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_SDMMCRA &emc>,
 					<&mc TEGRA194_MEMORY_CLIENT_SDMMCWA &emc>;
 			interconnect-names = "dma-mem", "write";
+			iommus = <&smmu TEGRA194_SID_SDMMC1>;
 			nvidia,pad-autocal-pull-up-offset-3v3-timeout =
 									<0x07>;
 			nvidia,pad-autocal-pull-down-offset-3v3-timeout =
@@ -759,6 +761,7 @@ sdmmc3: mmc at 3440000 {
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_SDMMCR &emc>,
 					<&mc TEGRA194_MEMORY_CLIENT_SDMMCW &emc>;
 			interconnect-names = "dma-mem", "write";
+			iommus = <&smmu TEGRA194_SID_SDMMC3>;
 			nvidia,pad-autocal-pull-up-offset-1v8 = <0x00>;
 			nvidia,pad-autocal-pull-down-offset-1v8 = <0x7a>;
 			nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x07>;
@@ -790,6 +793,7 @@ sdmmc4: mmc at 3460000 {
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_SDMMCRAB &emc>,
 					<&mc TEGRA194_MEMORY_CLIENT_SDMMCWAB &emc>;
 			interconnect-names = "dma-mem", "write";
+			iommus = <&smmu TEGRA194_SID_SDMMC4>;
 			nvidia,pad-autocal-pull-up-offset-hs400 = <0x00>;
 			nvidia,pad-autocal-pull-down-offset-hs400 = <0x00>;
 			nvidia,pad-autocal-pull-up-offset-1v8-timeout = <0x0a>;
@@ -821,6 +825,7 @@ hda at 3510000 {
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_HDAR &emc>,
 					<&mc TEGRA194_MEMORY_CLIENT_HDAW &emc>;
 			interconnect-names = "dma-mem", "write";
+			iommus = <&smmu TEGRA194_SID_HDA>;
 			status = "disabled";
 		};
 
@@ -1300,6 +1305,84 @@ pmc: pmc at c360000 {
 			interrupt-controller;
 		};
 
+		smmu: iommu at 12000000 {
+			compatible = "nvidia,tegra194-smmu", "nvidia,smmu-500";
+			reg = <0x12000000 0x800000>,
+			      <0x11000000 0x800000>;
+			interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
+			stream-match-mask = <0x7f80>;
+			#global-interrupts = <2>;
+			#iommu-cells = <1>;
+
+			nvidia,memory-controller = <&mc>;
+			status = "okay";
+		};
+
 		host1x at 13e00000 {
 			compatible = "nvidia,tegra194-host1x";
 			reg = <0x13e00000 0x10000>,
@@ -1319,6 +1402,7 @@ host1x at 13e00000 {
 			ranges = <0x15000000 0x15000000 0x01000000>;
 			interconnects = <&mc TEGRA194_MEMORY_CLIENT_HOST1XDMAR &emc>;
 			interconnect-names = "dma-mem";
+			iommus = <&smmu TEGRA194_SID_HOST1X>;
 
 			display-hub at 15200000 {
 				compatible = "nvidia,tegra194-display";
@@ -1430,6 +1514,7 @@ vic at 15340000 {
 				interconnects = <&mc TEGRA194_MEMORY_CLIENT_VICSRD &emc>,
 						<&mc TEGRA194_MEMORY_CLIENT_VICSWR &emc>;
 				interconnect-names = "dma-mem", "write";
+				iommus = <&smmu TEGRA194_SID_VIC>;
 			};
 
 			dpaux0: dpaux at 155c0000 {
@@ -2136,6 +2221,7 @@ bpmp: bpmp {
 				<&mc TEGRA194_MEMORY_CLIENT_BPMPDMAR &emc>,
 				<&mc TEGRA194_MEMORY_CLIENT_BPMPDMAW &emc>;
 		interconnect-names = "read", "write", "dma-mem", "dma-write";
+		iommus = <&smmu TEGRA194_SID_BPMP>;
 
 		bpmp_i2c: i2c {
 			compatible = "nvidia,tegra186-bpmp-i2c";
-- 
2.30.2



From thierry.reding at gmail.com  Tue Apr 20 18:26:19 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 20 Apr 2021 19:26:19 +0200
Subject: [PATCH v2 10/10] arm64: tegra: Enable SMMU support for display on
 Tegra194
In-Reply-To: <20210420172619.3782831-1-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
Message-ID: <20210420172619.3782831-11-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

The display controllers are attached to a separate ARM SMMU instance
that is dedicated to servicing isochronous memory clients. Add this ISO
instance of the ARM SMMU to device tree and attach all four display
controllers to it.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 80 ++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 6ed296e27158..00f8248f216e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1305,6 +1305,82 @@ pmc: pmc at c360000 {
 			interrupt-controller;
 		};
 
+		smmu_iso: iommu at 10000000 {
+			compatible = "nvidia,tegra194-smmu", "nvidia,smmu-500";
+			reg = <0x10000000 0x800000>;
+			interrupts = <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
+			stream-match-mask = <0x7f80>;
+			#global-interrupts = <1>;
+			#iommu-cells = <1>;
+
+			nvidia,memory-controller = <&mc>;
+			status = "okay";
+		};
+
 		smmu: iommu at 12000000 {
 			compatible = "nvidia,tegra194-smmu", "nvidia,smmu-500";
 			reg = <0x12000000 0x800000>,
@@ -1441,6 +1517,7 @@ display at 15200000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <0>;
@@ -1459,6 +1536,7 @@ display at 15210000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <1>;
@@ -1477,6 +1555,7 @@ display at 15220000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <2>;
@@ -1495,6 +1574,7 @@ display at 15230000 {
 					interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR &emc>,
 							<&mc TEGRA194_MEMORY_CLIENT_NVDISPLAYR1 &emc>;
 					interconnect-names = "dma-mem", "read-1";
+					iommus = <&smmu_iso TEGRA194_SID_NVDISPLAY>;
 
 					nvidia,outputs = <&sor0 &sor1 &sor2 &sor3>;
 					nvidia,head = <3>;
-- 
2.30.2



From ndesaulniers at google.com  Tue Apr 20 18:44:25 2021
From: ndesaulniers at google.com (Nick Desaulniers)
Date: Tue, 20 Apr 2021 10:44:25 -0700
Subject: [PATCH v3] arm64: vdso32: drop -no-integrated-as flag
Message-ID: <20210420174427.230228-1-ndesaulniers@google.com>

Clang can assemble these files just fine; this is a relic from the top
level Makefile conditionally adding this. We no longer need --prefix,
--gcc-toolchain, or -Qunused-arguments flags either with this change, so
remove those too.

To test building:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
  CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
  defconfig arch/arm64/kernel/vdso32/

Suggested-by: Nathan Chancellor <nathan at kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
Reviewed-by: Nathan Chancellor <nathan at kernel.org>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
Changes V2 -> V3:
* Pick up reviewed by tags.

Changes V1 -> V2:
* Remove --prefix, --gcc-toolchain, COMPAT_GCC_TOOLCHAIN, and
  COMPAT_GCC_TOOLCHAIN_DIR as per Nathan.
* Credit Nathan with Suggested-by tag.
* Remove -Qunused-arguments.
* Update commit message.

 arch/arm64/kernel/vdso32/Makefile | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 789ad420f16b..3dba0c4f8f42 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -10,15 +10,7 @@ include $(srctree)/lib/vdso/Makefile
 
 # Same as cc-*option, but using CC_COMPAT instead of CC
 ifeq ($(CONFIG_CC_IS_CLANG), y)
-COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE_COMPAT)elfedit))
-COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
-
 CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
-CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE_COMPAT))
-CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
-ifneq ($(COMPAT_GCC_TOOLCHAIN),)
-CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
-endif
 
 CC_COMPAT ?= $(CC)
 CC_COMPAT += $(CC_COMPAT_CLANG_FLAGS)
-- 
2.31.1.368.gbe11c130af-goog



From sebastian.fricke at posteo.net  Tue Apr 20 18:45:22 2021
From: sebastian.fricke at posteo.net (Sebastian Fricke)
Date: Tue, 20 Apr 2021 17:45:22 +0000
Subject: [PATCH v2] media: rkisp1: rkisp1-params.c: Fix typos
Message-ID: <20210420174522.9618-1-sebastian.fricke@posteo.net>

s/when the camera active/when the camera is active/
s/thus not isr protection/therefore there is no need to acquire a lock/

Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
index b6beddd988d0..529c6e21815f 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
@@ -1258,7 +1258,10 @@ void rkisp1_params_configure(struct rkisp1_params *params,
 	rkisp1_params_config_parameter(params);
 }
 
-/* Not called when the camera active, thus not isr protection. */
+/*
+ * Not called when the camera is active, therefore there is no need to acquire
+ * a lock.
+ */
 void rkisp1_params_disable(struct rkisp1_params *params)
 {
 	rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPCC_MODE,
-- 
2.25.1



From rdunlap at infradead.org  Tue Apr 20 19:15:12 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Tue, 20 Apr 2021 11:15:12 -0700
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <20210420081153.17020-6-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com>
Message-ID: <c16bb43d-a4e6-cece-85f0-beef3797ee8f@infradead.org>

On 4/20/21 1:11 AM, Nava kishore Manne wrote:
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 877b43b3377d..d1ea1eeb3ac1 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -456,6 +456,17 @@ config ZYNQ_AFI
>  	  between PS and PL, the AXI port data path should be configured
>  	  with the proper Bus-width values
>  
> +config ZYNQMP_AFI
> +        tristate "Xilinx ZYNQMP AFI support"
> +        help
> +	  ZynqMP AFI driver support for writing to the AFI registers for
> +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> +	  PS to the programmable logic (PL) through the AXI port. This AXI
> +	  port helps to establish the data path between the PS and PL.
> +	  In-order to establish the proper communication path between
> +	  PS and PL, the AXI port data path should be configured with
> +	  the proper Bus-width values
> +
>  source "drivers/misc/c2port/Kconfig"
>  source "drivers/misc/eeprom/Kconfig"
>  source "drivers/misc/cb710/Kconfig"

Hi,
from my notabot:

Please follow coding-style for Kconfig files:

from Documentation/process/coding-style.rst, section 10):

For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different.  Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces.


thanks.
-- 
~Randy



From rdunlap at infradead.org  Tue Apr 20 19:17:00 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Tue, 20 Apr 2021 11:17:00 -0700
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <20210420081153.17020-3-nava.manne@xilinx.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-3-nava.manne@xilinx.com>
Message-ID: <c6047330-8683-09f8-3a7b-e615c6cc312f@infradead.org>

On 4/20/21 1:11 AM, Nava kishore Manne wrote:
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index f532c59bb59b..877b43b3377d 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -445,6 +445,17 @@ config HISI_HIKEY_USB
>  	  switching between the dual-role USB-C port and the USB-A host ports
>  	  using only one USB controller.
>  
> +config ZYNQ_AFI
> +	tristate "Xilinx ZYNQ AFI support"
> +	help
> +	  Zynq AFI driver support for writing to the AFI registers
> +	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
> +	  the PS to the programmable logic (PL) through the AXI port.
> +	  This AXI port helps to establish the data path between the
> +	  PS and PL.In-order to establish the proper communication path
> +	  between PS and PL, the AXI port data path should be configured
> +	  with the proper Bus-width values

End that last sentence with a period ('.').

thanks.
-- 
~Randy



From robh at kernel.org  Tue Apr 20 19:29:06 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 13:29:06 -0500
Subject: [PATCH v2 1/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kappa
In-Reply-To: <20210416164055.3223088-1-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
Message-ID: <20210420182906.GA3595334@robh.at.kernel.org>

On Sat, 17 Apr 2021 00:40:48 +0800, Hsin-Yi Wang wrote:
> Kappa is known as HP Chromebook 11a.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 19:29:25 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 13:29:25 -0500
Subject: [PATCH v2 2/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-willow
In-Reply-To: <20210416164055.3223088-2-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
 <20210416164055.3223088-2-hsinyi@chromium.org>
Message-ID: <20210420182925.GA3595853@robh.at.kernel.org>

On Sat, 17 Apr 2021 00:40:49 +0800, Hsin-Yi Wang wrote:
> Willow is known as Acer Chromebook 311 (C722/C722T).
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 19:29:52 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 13:29:52 -0500
Subject: [PATCH v2 3/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-burnet
In-Reply-To: <20210416164055.3223088-3-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
 <20210416164055.3223088-3-hsinyi@chromium.org>
Message-ID: <20210420182952.GA3596569@robh.at.kernel.org>

On Sat, 17 Apr 2021 00:40:50 +0800, Hsin-Yi Wang wrote:
> Burnet is known as HP Chromebook x360 11MK G3 EE.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 19:30:20 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 13:30:20 -0500
Subject: [PATCH v2 4/8] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210416164055.3223088-4-hsinyi@chromium.org>
References: <20210416164055.3223088-1-hsinyi@chromium.org>
 <20210416164055.3223088-4-hsinyi@chromium.org>
Message-ID: <20210420183020.GA3597276@robh.at.kernel.org>

On Sat, 17 Apr 2021 00:40:51 +0800, Hsin-Yi Wang wrote:
> Kenzo is known as Acer Chromebook 311.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From marex at denx.de  Tue Apr 20 19:30:20 2021
From: marex at denx.de (Marek Vasut)
Date: Tue, 20 Apr 2021 20:30:20 +0200
Subject: [PATCH v3 10/11] dt-bindings: clock: stm32mp1 new compatible for
 secure rcc
In-Reply-To: <20210419093852.14978-11-gabriel.fernandez@foss.st.com>
References: <20210419093852.14978-1-gabriel.fernandez@foss.st.com>
 <20210419093852.14978-11-gabriel.fernandez@foss.st.com>
Message-ID: <36aafe68-d313-692a-a551-4ff4147e584c@denx.de>

On 4/19/21 11:38 AM, gabriel.fernandez at foss.st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> 
> Introduce new compatible string "st,stm32mp1-rcc-secure" for
> stm32mp1 clock driver when the device is configured with RCC
> security support hardened.
> 
> Signed-off-by: Etienne Carriere <etienne.carriere at foss.st.com>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez at foss.st.com>
> ---
>   .../devicetree/bindings/clock/st,stm32mp1-rcc.yaml          | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
> index 4e385508f516..8b1ecb2ecdd5 100644
> --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
> @@ -54,7 +54,9 @@ properties:
>   
>     compatible:
>       items:
> -      - const: st,stm32mp1-rcc
> +      - enum:
> +          - st,stm32mp1-rcc-secure
> +          - st,stm32mp1-rcc

It is still the same IP and same SoC silicon, so shouldn't the 
configuration be discerned via DT property instead of compatible string ?


From tim.c.chen at linux.intel.com  Tue Apr 20 19:31:38 2021
From: tim.c.chen at linux.intel.com (Tim Chen)
Date: Tue, 20 Apr 2021 11:31:38 -0700
Subject: [RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86
In-Reply-To: <67cc380019fd40d88d7a493b6cbc0852@hisilicon.com>
References: <20210319041618.14316-1-song.bao.hua@hisilicon.com>
 <20210319041618.14316-5-song.bao.hua@hisilicon.com>
 <110234d1-22ce-8a9a-eabb-c15ac29a5dcd@linux.intel.com>
 <67cc380019fd40d88d7a493b6cbc0852@hisilicon.com>
Message-ID: <422b5d06-ec0e-f064-32fe-15df5b2957dd@linux.intel.com>



On 3/23/21 4:21 PM, Song Bao Hua (Barry Song) wrote:

>>
>> On 3/18/21 9:16 PM, Barry Song wrote:
>>> From: Tim Chen <tim.c.chen at linux.intel.com>
>>>
>>> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
>>> is shared among a cluster of cores instead of being exclusive
>>> to one single core.
>>>
>>> To prevent oversubscription of L2 cache, load should be
>>> balanced between such L2 clusters, especially for tasks with
>>> no shared data.
>>>
>>> Also with cluster scheduling policy where tasks are woken up
>>> in the same L2 cluster, we will benefit from keeping tasks
>>> related to each other and likely sharing data in the same L2
>>> cluster.
>>>
>>> Add CPU masks of CPUs sharing the L2 cache so we can build such
>>> L2 cluster scheduler domain.
>>>
>>> Signed-off-by: Tim Chen <tim.c.chen at linux.intel.com>
>>> Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
>>
>>
>> Barry,
>>
>> Can you also add this chunk to the patch.
>> Thanks.
> 
> Sure, Tim, Thanks. I'll put that into patch 4/4 in v6.
> 

Barry,

This chunk will also need to be added to return cluster id for x86.
Please add it in your next rev.

Thanks.

Tim

---

diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 800fa48c9fcd..2548d824f103 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -109,6 +109,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu);
 #define topology_physical_package_id(cpu)	(cpu_data(cpu).phys_proc_id)
 #define topology_logical_die_id(cpu)		(cpu_data(cpu).logical_die_id)
 #define topology_die_id(cpu)			(cpu_data(cpu).cpu_die_id)
+#define topology_cluster_id(cpu)		(per_cpu(cpu_l2c_id, cpu))
 #define topology_core_id(cpu)			(cpu_data(cpu).cpu_core_id)
 
 extern unsigned int __max_die_per_package;


From madvenka at linux.microsoft.com  Tue Apr 20 19:44:46 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Tue, 20 Apr 2021 13:44:46 -0500
Subject: [PATCH v3 0/1] arm64: Implement stack trace termination record
In-Reply-To: <80cac661608c8d3623328b37b9b1696f63f45968>
References: <80cac661608c8d3623328b37b9b1696f63f45968>
Message-ID: <20210420184447.16306-1-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Reliable stacktracing requires that we identify when a stacktrace is
terminated early. We can do this by ensuring all tasks have a final
frame record at a known location on their task stack, and checking
that this is the final frame record in the chain.

All tasks have a pt_regs structure right after the task stack in the stack
page. The pt_regs structure contains a stackframe field. Make this stackframe
field the final frame in the task stack so all stack traces end at a fixed
stack offset.

For kernel tasks, this is simple to understand. For user tasks, there is
some extra detail. User tasks get created via fork() et al. Once they return
from fork, they enter the kernel only on an EL0 exception. In arm64,
system calls are also EL0 exceptions.

The EL0 exception handler uses the task pt_regs mentioned above to save
register state and call different exception functions. All stack traces
from EL0 exception code must end at the pt_regs. So, make pt_regs->stackframe
the final frame in the EL0 exception stack.

To summarize, task_pt_regs(task)->stackframe will always be the final frame
in a stack trace.

Sample stack traces
===================

Showing just the last couple of frames in each stack trace to show how the
stack trace ends.

Primary CPU idle task
=====================

		 ...
[    0.077109]   rest_init+0x108/0x144
[    0.077188]   arch_call_rest_init+0x18/0x24
[    0.077220]   start_kernel+0x3ac/0x3e4
[    0.077293]   __primary_switched+0xac/0xb0

Secondary CPU idle task
=======================

		...
[    0.077264]   secondary_start_kernel+0x228/0x388
[    0.077326]   __secondary_switched+0x80/0x84

Sample kernel thread
====================

		 ...
[   24.543250]   kernel_init+0xa4/0x164
[   24.561850]   ret_from_fork+0x10/0x18

Write system call (EL0 exception)
=================

(using a test driver called callfd)

[ 1160.628723]   callfd_stack+0x3c/0x70
[ 1160.628768]   callfd_op+0x35c/0x3a8
[ 1160.628791]   callfd_write+0x5c/0xc8
[ 1160.628813]   vfs_write+0x104/0x3b8
[ 1160.628837]   ksys_write+0xd0/0x188
[ 1160.628859]   __arm64_sys_write+0x4c/0x60
[ 1160.628883]   el0_svc_common.constprop.0+0xa8/0x240
[ 1160.628904]   do_el0_svc+0x40/0xa8
[ 1160.628921]   el0_svc+0x2c/0x78
[ 1160.628942]   el0_sync_handler+0xb0/0xb8
[ 1160.628962]   el0_sync+0x17c/0x180

NULL pointer dereference exception (EL1 exception)
==================================

[ 1160.637984]   callfd_stack+0x3c/0x70
[ 1160.638015]   die_kernel_fault+0x80/0x108
[ 1160.638042]   do_page_fault+0x520/0x600
[ 1160.638075]   do_translation_fault+0xa8/0xdc
[ 1160.638102]   do_mem_abort+0x68/0x100
[ 1160.638120]   el1_abort+0x40/0x60
[ 1160.638138]   el1_sync_handler+0xac/0xc8
[ 1160.638157]   el1_sync+0x74/0x100
[ 1160.638174]   0x0                           <=== NULL pointer dereference
[ 1160.638189]   callfd_write+0x5c/0xc8
[ 1160.638211]   vfs_write+0x104/0x3b8
[ 1160.638234]   ksys_write+0xd0/0x188
[ 1160.638278]   __arm64_sys_write+0x4c/0x60
[ 1160.638325]   el0_svc_common.constprop.0+0xa8/0x240
[ 1160.638358]   do_el0_svc+0x40/0xa8
[ 1160.638379]   el0_svc+0x2c/0x78
[ 1160.638409]   el0_sync_handler+0xb0/0xb8
[ 1160.638452]   el0_sync+0x17c/0x180

Timer interrupt (EL1 exception)
===============

Secondary CPU idle task interrupted by the timer interrupt:

[ 1160.702949] callfd_callback:
[ 1160.703006]   callfd_stack+0x3c/0x70
[ 1160.703060]   callfd_callback+0x30/0x40
[ 1160.703087]   call_timer_fn+0x48/0x220
[ 1160.703113]   run_timer_softirq+0x7cc/0xc70
[ 1160.703144]   __do_softirq+0x1ec/0x608
[ 1160.703166]   irq_exit+0x138/0x180
[ 1160.703193]   __handle_domain_irq+0x8c/0xf0
[ 1160.703218]   gic_handle_irq+0xec/0x410
[ 1160.703253]   el1_irq+0xc0/0x180
[ 1160.703278]   arch_local_irq_enable+0xc/0x28
[ 1160.703329]   default_idle_call+0x54/0x1d8
[ 1160.703355]   do_idle+0x2d8/0x350
[ 1160.703388]   cpu_startup_entry+0x2c/0x98
[ 1160.703412]   secondary_start_kernel+0x238/0x388
[ 1160.703446]   __secondary_switched+0x80/0x84
---
Changelog:

v3:
	- Added Reviewed-by: Mark Brown <broonie at kernel.org>.
	- Fixed an extra space after a cast reported by checkpatch --strict.
	- Synced with mainline tip.

v2:
	- Changed some wordings as suggested by Mark Rutland.
	- Removed the synthetic return PC for idle tasks. Changed the
	  branches to start_kernel() and secondary_start_kernel() to
	  calls so that they will have a proper return PC.

v1:
	- Set up task_pt_regs(current)->stackframe as the final frame
	  when a new task is initialized in copy_thread().
	- Create pt_regs for the idle tasks and set up pt_regs->stackframe
	  as the final frame for the idle tasks.
	- Set up task_pt_regs(current)->stackframe as the final frame in
	  the EL0 exception handler so the EL0 exception stack trace ends
	  there.
	- Terminate the stack trace successfully in unwind_frame() when
	  the FP reaches task_pt_regs(current)->stackframe.
	- The stack traces (above) in the kernel will terminate at the
	  correct place. Debuggers may show an extra record 0x0 at the end
	  for pt_regs->stackframe. That said, I did not see that extra frame
	  when I did stack traces using gdb.

Testing:
	- Functional validation on a ThunderX system.

Previous versions and discussion
================================

v2: https://lore.kernel.org/linux-arm-kernel/20210402032404.47239-1-madvenka at linux.microsoft.com/
v1: https://lore.kernel.org/linux-arm-kernel/20210324184607.120948-1-madvenka at linux.microsoft.com/

Madhavan T. Venkataraman (1):
  arm64: Implement stack trace termination record

 arch/arm64/kernel/entry.S      |  8 +++++---
 arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
 arch/arm64/kernel/process.c    |  5 +++++
 arch/arm64/kernel/stacktrace.c | 10 +++++-----
 4 files changed, 38 insertions(+), 14 deletions(-)


base-commit: bf05bf16c76bb44ab5156223e1e58e26dfe30a88
-- 
2.25.1



From madvenka at linux.microsoft.com  Tue Apr 20 19:44:47 2021
From: madvenka at linux.microsoft.com (madvenka at linux.microsoft.com)
Date: Tue, 20 Apr 2021 13:44:47 -0500
Subject: [PATCH v3 1/1] arm64: Implement stack trace termination record
In-Reply-To: <20210420184447.16306-1-madvenka@linux.microsoft.com>
References: <80cac661608c8d3623328b37b9b1696f63f45968>
 <20210420184447.16306-1-madvenka@linux.microsoft.com>
Message-ID: <20210420184447.16306-2-madvenka@linux.microsoft.com>

From: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Reliable stacktracing requires that we identify when a stacktrace is
terminated early. We can do this by ensuring all tasks have a final
frame record at a known location on their task stack, and checking
that this is the final frame record in the chain.

Kernel Tasks
============

All tasks except the idle task have a pt_regs structure right after the
task stack. This is called the task pt_regs. The pt_regs structure has a
special stackframe field. Make this stackframe field the final frame in the
task stack. This needs to be done in copy_thread() which initializes a new
task's pt_regs and initial CPU context.

For the idle task, there is no task pt_regs. For our purpose, we need one.
So, create a pt_regs just like other kernel tasks and make
pt_regs->stackframe the final frame in the idle task stack. This needs to be
done at two places:

	- On the primary CPU, the boot task runs. It calls start_kernel()
	  and eventually becomes the idle task for the primary CPU. Just
	  before start_kernel() is called, set up the final frame.

	- On each secondary CPU, a startup task runs that calls
	  secondary_startup_kernel() and eventually becomes the idle task
	  on the secondary CPU. Just before secondary_start_kernel() is
	  called, set up the final frame.

User Tasks
==========

User tasks are initially set up like kernel tasks when they are created.
Then, they return to userland after fork via ret_from_fork(). After that,
they enter the kernel only on an EL0 exception. (In arm64, system calls are
also EL0 exceptions). The EL0 exception handler stores state in the task
pt_regs and calls different functions based on the type of exception. The
stack trace for an EL0 exception must end at the task pt_regs. So, make
task pt_regs->stackframe as the final frame in the EL0 exception stack.

In summary, task pt_regs->stackframe is where a successful stack trace ends.

Stack trace termination
=======================

In the unwinder, terminate the stack trace successfully when
task_pt_regs(task)->stackframe is reached. For stack traces in the kernel,
this will correctly terminate the stack trace at the right place.

However, debuggers may terminate the stack trace when FP == 0. In the
pt_regs->stackframe, the PC is 0 as well. So, stack traces taken in the
debugger may print an extra record 0x0 at the end. While this is not
pretty, this does not do any harm. This is a small price to pay for
having reliable stack trace termination in the kernel. That said, gdb
does not show the extra record probably because it uses DWARF and not
frame pointers for stack traces.

Reviewed-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Madhavan T. Venkataraman <madvenka at linux.microsoft.com>
---
 arch/arm64/kernel/entry.S      |  8 +++++---
 arch/arm64/kernel/head.S       | 29 +++++++++++++++++++++++------
 arch/arm64/kernel/process.c    |  5 +++++
 arch/arm64/kernel/stacktrace.c | 10 +++++-----
 4 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 6acfc5e6b5e0..e677b9a2b8f8 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -263,16 +263,18 @@ alternative_else_nop_endif
 	stp	lr, x21, [sp, #S_LR]
 
 	/*
-	 * For exceptions from EL0, terminate the callchain here.
+	 * For exceptions from EL0, terminate the callchain here at
+	 * task_pt_regs(current)->stackframe.
+	 *
 	 * For exceptions from EL1, create a synthetic frame record so the
 	 * interrupted code shows up in the backtrace.
 	 */
 	.if \el == 0
-	mov	x29, xzr
+	stp	xzr, xzr, [sp, #S_STACKFRAME]
 	.else
 	stp	x29, x22, [sp, #S_STACKFRAME]
-	add	x29, sp, #S_STACKFRAME
 	.endif
+	add	x29, sp, #S_STACKFRAME
 
 #ifdef CONFIG_ARM64_SW_TTBR0_PAN
 alternative_if_not ARM64_HAS_PAN
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 840bda1869e9..743c019a42c7 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -393,6 +393,23 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	ret	x28
 SYM_FUNC_END(__create_page_tables)
 
+	/*
+	 * The boot task becomes the idle task for the primary CPU. The
+	 * CPU startup task on each secondary CPU becomes the idle task
+	 * for the secondary CPU.
+	 *
+	 * The idle task does not require pt_regs. But create a dummy
+	 * pt_regs so that task_pt_regs(idle_task)->stackframe can be
+	 * set up to be the final frame on the idle task stack just like
+	 * all the other kernel tasks. This helps the unwinder to
+	 * terminate the stack trace at a well-known stack offset.
+	 */
+	.macro setup_final_frame
+	sub	sp, sp, #PT_REGS_SIZE
+	stp	xzr, xzr, [sp, #S_STACKFRAME]
+	add	x29, sp, #S_STACKFRAME
+	.endm
+
 /*
  * The following fragment of code is executed with the MMU enabled.
  *
@@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
 #endif
 	bl	switch_to_vhe			// Prefer VHE if possible
 	add	sp, sp, #16
-	mov	x29, #0
-	mov	x30, #0
-	b	start_kernel
+	setup_final_frame
+	bl	start_kernel
+	nop
 SYM_FUNC_END(__primary_switched)
 
 	.pushsection ".rodata", "a"
@@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
 	cbz	x2, __secondary_too_slow
 	msr	sp_el0, x2
 	scs_load x2, x3
-	mov	x29, #0
-	mov	x30, #0
+	setup_final_frame
 
 #ifdef CONFIG_ARM64_PTR_AUTH
 	ptrauth_keys_init_cpu x2, x3, x4, x5
 #endif
 
-	b	secondary_start_kernel
+	bl	secondary_start_kernel
+	nop
 SYM_FUNC_END(__secondary_switched)
 
 SYM_FUNC_START_LOCAL(__secondary_too_slow)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6e60aa3b5ea9..999711c55274 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -439,6 +439,11 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	}
 	p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
 	p->thread.cpu_context.sp = (unsigned long)childregs;
+	/*
+	 * For the benefit of the unwinder, set up childregs->stackframe
+	 * as the final frame for the new task.
+	 */
+	p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
 
 	ptrace_hw_copy_thread(p);
 
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d55bdfb7789c..774d9af2f0b6 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 	unsigned long fp = frame->fp;
 	struct stack_info info;
 
-	/* Terminal record; nothing to unwind */
-	if (!fp)
+	if (!tsk)
+		tsk = current;
+
+	/* Final frame; nothing to unwind */
+	if (fp == (unsigned long)task_pt_regs(tsk)->stackframe)
 		return -ENOENT;
 
 	if (fp & 0xf)
 		return -EINVAL;
 
-	if (!tsk)
-		tsk = current;
-
 	if (!on_accessible_stack(tsk, fp, &info))
 		return -EINVAL;
 
-- 
2.25.1



From keescook at chromium.org  Tue Apr 20 19:57:33 2021
From: keescook at chromium.org (Kees Cook)
Date: Tue, 20 Apr 2021 11:57:33 -0700
Subject: [PATCH] arm64: Show three registers per line
In-Reply-To: <20210420172245.3679077-1-willy@infradead.org>
References: <20210420172245.3679077-1-willy@infradead.org>
Message-ID: <202104201157.71854FD6@keescook>

On Tue, Apr 20, 2021 at 06:22:45PM +0100, Matthew Wilcox (Oracle) wrote:
> Displaying two registers per line takes 15 lines.  That improves to just
> 10 lines if we display three registers per line, which reduces the amount
> of information lost when oopses are cut off.  It stays within 80 columns
> and matches x86-64.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>

Reviewed-by: Kees Cook <keescook at chromium.org>

-- 
Kees Cook


From swboyd at chromium.org  Tue Apr 20 20:10:42 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Tue, 20 Apr 2021 12:10:42 -0700
Subject: [PATCH v3] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210420174427.230228-1-ndesaulniers@google.com>
References: <20210420174427.230228-1-ndesaulniers@google.com>
Message-ID: <161894584244.46595.3366888884991252865@swboyd.mtv.corp.google.com>

Quoting Nick Desaulniers (2021-04-20 10:44:25)
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this. We no longer need --prefix,
> --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> remove those too.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/
> 
> Suggested-by: Nathan Chancellor <nathan at kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
> Reviewed-by: Nathan Chancellor <nathan at kernel.org>
> Reviewed-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> ---

It boots for me and compat vDSO seems to work properly per
tools/testing/selftests/vDSO/, userspace programs aren't crashing right
and left, must be good:

Tested-by: Stephen Boyd <swboyd at chromium.org>


From robh at kernel.org  Tue Apr 20 20:51:32 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 14:51:32 -0500
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom
 GMAC label
In-Reply-To: <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
Message-ID: <20210420195132.GA3686955@robh.at.kernel.org>

On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> The MAC device name can now be set within DTS file instead of always
> being "ethX". This is helpful for DSA to clearly label the DSA master
> device and distinguish it from DSA slave ports.
> 
> For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> ports labeled ethX. Labeling the master GMAC with a different prefix
> than DSA ports helps with clarity.
> 
> Suggested-by: Ren? van Dorst <opensource at vdorst.com>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 6b00c12c6c43..df3cda63a8c5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
>  
>  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
>  {
> +	const char *label = of_get_property(np, "label", NULL);
>  	const __be32 *_id = of_get_property(np, "reg", NULL);
>  	phy_interface_t phy_mode;
>  	struct phylink *phylink;
> @@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
>  		return -EINVAL;
>  	}
>  
> -	eth->netdev[id] = alloc_etherdev(sizeof(*mac));
> +	eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
> +				       NET_NAME_UNKNOWN, ether_setup);

'label' is generally supposed to correspond to the sticker for the 
device connector for a human to id. I can't really tell if that's the 
case here. I don't see how 'gmacX' vs. 'ethX' maps to DSA master vs. 
slave.

I don't think this should be handled within a specific driver either. If 
we're going to have a way to name things, then fix it in 
alloc_etherdev().

It can also be argued that device naming for userspace is a userspace 
(udev) problem. 

Rob


From ilya.lipnitskiy at gmail.com  Tue Apr 20 20:57:43 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Tue, 20 Apr 2021 12:57:43 -0700
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support custom
 GMAC label
In-Reply-To: <20210420195132.GA3686955@robh.at.kernel.org>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
 <20210420195132.GA3686955@robh.at.kernel.org>
Message-ID: <CALCv0x2SG=0kBRnxfSPxi+FvaBK=QGPHQkHWHvTXOw64KawPUQ@mail.gmail.com>

On Tue, Apr 20, 2021 at 12:51 PM Rob Herring <robh at kernel.org> wrote:
>
> On Mon, Apr 19, 2021 at 08:46:59AM -0700, Ilya Lipnitskiy wrote:
> > The MAC device name can now be set within DTS file instead of always
> > being "ethX". This is helpful for DSA to clearly label the DSA master
> > device and distinguish it from DSA slave ports.
> >
> > For example, some devices, such as the Ubiquiti EdgeRouter X, may have
> > ports labeled ethX. Labeling the master GMAC with a different prefix
> > than DSA ports helps with clarity.
> >
> > Suggested-by: Ren? van Dorst <opensource at vdorst.com>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > ---
> >  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > index 6b00c12c6c43..df3cda63a8c5 100644
> > --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > @@ -2845,6 +2845,7 @@ static const struct net_device_ops mtk_netdev_ops = {
> >
> >  static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >  {
> > +     const char *label = of_get_property(np, "label", NULL);
> >       const __be32 *_id = of_get_property(np, "reg", NULL);
> >       phy_interface_t phy_mode;
> >       struct phylink *phylink;
> > @@ -2867,9 +2868,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
> >               return -EINVAL;
> >       }
> >
> > -     eth->netdev[id] = alloc_etherdev(sizeof(*mac));
> > +     eth->netdev[id] = alloc_netdev(sizeof(*mac), label ? label : "eth%d",
> > +                                    NET_NAME_UNKNOWN, ether_setup);
>
> 'label' is generally supposed to correspond to the sticker for the
> device connector for a human to id. I can't really tell if that's the
> case here. I don't see how 'gmacX' vs. 'ethX' maps to DSA master vs.
> slave.
The ports on devices such as Ubiquiti ER-X are named eth0 through
eth4, all of them DSA slaves. The gmac (DSA master) is hard-coded to
eth0 without this change.
>
> I don't think this should be handled within a specific driver either. If
> we're going to have a way to name things, then fix it in
> alloc_etherdev().
>
> It can also be argued that device naming for userspace is a userspace
> (udev) problem.
Yeah, that is a valid argument. We can drop this changeset if the
agreement is that it doesn't belong in the specific driver or the
kernel-space at all.
Some discussion (and device picture) here if you are interested:
https://github.com/openwrt/openwrt/pull/3971

Ilya


From robh at kernel.org  Tue Apr 20 21:00:45 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 15:00:45 -0500
Subject: [PATCH robh dt/next] dt-bindings: mfd: add Broadcom CRU
In-Reply-To: <20210415062839.11713-1-zajec5@gmail.com>
References: <20210415062839.11713-1-zajec5@gmail.com>
Message-ID: <20210420200045.GA3710852@robh.at.kernel.org>

On Thu, Apr 15, 2021 at 08:28:39AM +0200, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal at milecki.pl>
> 
> CRU is a block used in e.g. Northstar devices. It can be seen in the
> bcm5301x.dtsi and this binding documents its proper usage.
> 
> Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
> ---
> This is reworked version of the
> [PATCH robh next] dt-bindings: bus: add Broadcom CRU
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210309142241.16259-1-zajec5 at gmail.com/
> ---
>  .../devicetree/bindings/mfd/brcm,cru.yaml     | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/brcm,cru.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
> new file mode 100644
> index 000000000000..f5bce6453c33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/brcm,cru.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom CRU
> +
> +maintainers:
> +  - Rafa? Mi?ecki <rafal at milecki.pl>
> +
> +description: |
> +  Broadcom CRU ("Clock and Reset Unit" or "Central Resource Unit") is a hardware
> +  block grouping smaller blocks. On Broadcom Northstar platform it contains e.g.
> +  clocks, pinctrl, USB PHY and thermal.

As I said before, this needs to be a complete binding.

> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - brcm,ns-cru
> +      - const: simple-mfd

As of now, it is not a 'simple-mfd' because there are no defined 
children.

> +
> +  reg:
> +    description: CRU registers
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 1
> +
> +additionalProperties: true

This needs to be 'false' (and then any child nodes defined).

> +
> +required:
> +  - reg
> +
> +examples:
> +  - |
> +    cru-bus at 1800c100 {
> +      compatible = "brcm,ns-cru", "simple-mfd";
> +      reg = <0x1800c100 0x1d0>;
> +      ranges;
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +    };
> -- 
> 2.26.2
> 


From robh at kernel.org  Tue Apr 20 21:04:40 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 15:04:40 -0500
Subject: [PATCH 04/13] dt-bindings: mfd: stm32-timers: remove
 #address/size cells from required properties
In-Reply-To: <20210415101037.1465-5-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-5-alexandre.torgue@foss.st.com>
Message-ID: <20210420200440.GA3722536@robh.at.kernel.org>

On Thu, 15 Apr 2021 12:10:28 +0200, Alexandre Torgue wrote:
> address-cells and size-cells can't be declared as "required" properties
> as they are not needed if subnodes don't have a "reg" entry.
> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Apr 20 21:05:16 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 15:05:16 -0500
Subject: [PATCH 08/13] dt-bindings: net: document ptp_ref clk in dwmac
In-Reply-To: <20210415101037.1465-9-alexandre.torgue@foss.st.com>
References: <20210415101037.1465-1-alexandre.torgue@foss.st.com>
 <20210415101037.1465-9-alexandre.torgue@foss.st.com>
Message-ID: <20210420200516.GA3723455@robh.at.kernel.org>

On Thu, 15 Apr 2021 12:10:32 +0200, Alexandre Torgue wrote:
> ptp_ref clk has been added in DT but not documented which makes yaml
> validation failed:
> 
> ethernet at 5800a000: clocks: [[6, 105], [6, 103], [6, 104], [6, 123],
> [6, 169], [6, 112]] is too long
> ethernet at 5800a000: clock-names: ['stmmaceth', 'mac-clk-tx', 'mac-clk-rx',
> 'eth-ck', 'ptp_ref', 'ethstp'] is too long
> 
> Signed-off-by: Alexandre Torgue <alexandre.torgue at foss.st.com>
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From dann.frazier at canonical.com  Tue Apr 20 21:37:10 2021
From: dann.frazier at canonical.com (dann frazier)
Date: Tue, 20 Apr 2021 14:37:10 -0600
Subject: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts
In-Reply-To: <20200519161755.209565-9-maz@kernel.org>
References: <20200519161755.209565-1-maz@kernel.org>
 <20200519161755.209565-9-maz@kernel.org>
Message-ID: <YH87dtTfwYgavusz@xps13.dannf>

On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> Change the way we deal with GIC SGIs by turning them into proper
> IRQs, and calling into the arch code to register the interrupt range
> instead of a callback.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>

hey Marc,

  I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
CN88XX) down to this commit, but only when running in ACPI mode. See below:


EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
[    0.000000] Linux version 5.11.0-13-generic (buildd at bos02-arm64-067) (gcc (Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 5.11.0-13.14-generic 5.11.7)
[    0.000000] Machine model: Cavium ThunderX CN88XX board
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb0000 ACPI 2.0=0xffc870000 MEMRESERVE=0xffa9b8e98 
[    0.000000] secureboot: Secure boot disabled
[    0.000000] esrt: Reserving ESRT space from 0x0000000ffce0ff18 to 0x0000000ffce0ff50.
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x0000000FFC870000 000024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 0x0000000FFC870028 00008C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x0000000FFC8700B8 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x0000000FFC8701D0 00220B (v02 CAVIUM THUNDERX 00000001 INTL 20130517)
[    0.000000] ACPI: SPMI 0x0000000FFC8723E0 000041 (v05 ALASKA A M I    00000000 AMI. 00000000)
[    0.000000] ACPI: FIDT 0x0000000FFC872428 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: APIC 0x0000000FFC8724C8 000F68 (v03 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: DBG2 0x0000000FFC873430 000067 (v01 CAVIUM CN88XDBG 00000000 INTL 20150619)
[    0.000000] ACPI: GTDT 0x0000000FFC873498 0000E0 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: IORT 0x0000000FFC873578 0013D4 (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: MCFG 0x0000000FFC874950 00006C (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SSDT 0x0000000FFC8749C0 00089C (v02 CAVIUM NETWORK  00000001 INTL 20150619)
[    0.000000] ACPI: OEM1 0x0000000FFC875260 0001E8 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SLIT 0x0000000FFC875448 000030 (v01 CAVIUM TEMPLATE 00000001 INTL 20150619)
[    0.000000] ACPI: SPCR 0x0000000FFC875478 000050 (v02 A M I  APTIO V  01072009 AMI. 0005000B)
[    0.000000] ACPI: BGRT 0x0000000FFC8754C8 000038 (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: SPCR: console: pl011,mmio32,0x87e024000000,115200
[    0.000000] efi_bgrt: Ignoring BGRT: Incorrect BMP magic number 0x3707 (expected 0x4d42)
[    0.000000] ACPI: NUMA: Failed to initialise from firmware
[    0.000000] NUMA: Faking a node at [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000] NUMA: NODE_DATA [mem 0xff67d40c0-0xff67d8fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000500000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x0000000fff0fffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000500000-0x0000000000dfffff]
[    0.000000]   node   0: [mem 0x0000000000e00000-0x000000000fffffff]
[    0.000000]   node   0: [mem 0x0000000010000000-0x00000000102fffff]
[    0.000000]   node   0: [mem 0x0000000010300000-0x00000000fff9ffff]
[    0.000000]   node   0: [mem 0x00000000fffa0000-0x00000000ffffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x0000000fee69ffff]
[    0.000000]   node   0: [mem 0x0000000fee6a0000-0x0000000fee6bffff]
[    0.000000]   node   0: [mem 0x0000000fee6c0000-0x0000000ffa98ffff]
[    0.000000]   node   0: [mem 0x0000000ffa990000-0x0000000ffa9affff]
[    0.000000]   node   0: [mem 0x0000000ffa9b0000-0x0000000ffac1ffff]
[    0.000000]   node   0: [mem 0x0000000ffac20000-0x0000000ffb09ffff]
[    0.000000]   node   0: [mem 0x0000000ffb0a0000-0x0000000ffc8affff]
[    0.000000]   node   0: [mem 0x0000000ffc8b0000-0x0000000ffc90ffff]
[    0.000000]   node   0: [mem 0x0000000ffc910000-0x0000000ffca2ffff]
[    0.000000]   node   0: [mem 0x0000000ffca30000-0x0000000ffca3ffff]
[    0.000000]   node   0: [mem 0x0000000ffca40000-0x0000000ffcdbffff]
[    0.000000]   node   0: [mem 0x0000000ffcdc0000-0x0000000ffd12ffff]
[    0.000000]   node   0: [mem 0x0000000ffd130000-0x0000000ffecbffff]
[    0.000000]   node   0: [mem 0x0000000ffecc0000-0x0000000ffed1ffff]
[    0.000000]   node   0: [mem 0x0000000ffed20000-0x0000000fff0fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000]   Normal zone: 256 pages in unavailable ranges
[    0.000000] cma: Reserved 32 MiB at 0x00000000fd000000
[    0.000000] psci: probing for conduit method from ACPI.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS resident on physical CPU 0x0
[    0.000000] ACPI: SRAT not present
[    0.000000] percpu: Embedded 33 pages/cpu s97176 r8192 d29800 u135168
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: Software prefetching using PRFM
[    0.000000] CPU features: detected: Cavium erratum 27456
[    0.000000] CPU features: detected: Cavium erratum 30115
[    0.000000] CPU features: kernel page table isolation forced OFF by ARM64_WORKAROUND_CAVIUM_27456
[    0.000000] CPU features: detected: Spectre-v2
[    0.000000] CPU features: detected: Spectre-v4
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16510032
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=(http,10.229.32.21:5248)/images/ubuntu/arm64/ga-21.04/hirsute/stable/boot-kernel nomodeset ro root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-21.04/hirsute/stable/squashfs ip=::::seidel:BOOTIF ip6=off overlayroot=tmpfs overlayroot_cfgdisk=disabled cc:{datasource_list: [MAAS]}end_cc cloud-config-url=http://10.229.32.21:5248/MAAS/metadata/latest/by-id/sb3xy8/?op=get_preseed apparmor=0 log_host=10.229.32.21 log_port=5247 --- acpi=force BOOTIF=01-1c:1b:0d:0d:52:d7
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 192512 bytes
[    0.000000] printk: log_buf_len min size: 262144 bytes
[    0.000000] printk: log_buf_len: 524288 bytes
[    0.000000] printk: early log buf free: 255416(97%)
[    0.000000] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
[    0.000000] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x00000000f9000000-0x00000000fd000000] (64MB)
[    0.000000] Memory: 65534308K/67088384K available (16064K kernel code, 3570K rwdata, 11876K rodata, 7680K init, 1152K bss, 1521308K reserved, 32768K cma-reserved)
[    0.000000] random: get_random_u64 called from kmem_cache_open+0x34/0x280 with crng_init=0
[    0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=48, Nodes=1
[    0.000000] ftrace: allocating 54554 entries in 214 pages
[    0.000000] ftrace: allocated 214 pages with 5 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=48.
[    0.000000]  Rude variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=48
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GIC: enabling workaround for GICv3: Cavium erratum 38539
[    0.000000] GICv3: 128 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000801080000000
[    0.000000] ACPI: SRAT not present
[    0.000000] ITS [mem 0x801000020000-0x80100003ffff]
[    0.000000] ITS at 0x0000801000020000: allocated 2097152 Devices @102000000 (flat, esz 8, psz 64K, shr 1)
[    0.000000] GICv3: using LPI property table @0x0000000100280000
[    0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000100290000
[    0.000000] arch_timer: Failed to initialize memory-mapped timer.
[    0.000000] arch_timer: cp15 timer(s) running at 100.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000000] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps every 4398046511100ns
[    0.000164] Console: colour dummy device 80x25
[    0.000255] ACPI: Core revision 20201113
[    0.000481] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.000492] pid_max: default: 49152 minimum: 384
[    0.000609] LSM: Security Framework initializing
[    0.000627] Yama: becoming mindful.
[    0.000801] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000866] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.001701] ACPI PPTT: No PPTT table found, CPU and cache topology may be inaccurate
[    0.002306] rcu: Hierarchical SRCU implementation.
[    0.003082] Platform MSI: ITS at 0x801000020000 domain created
[    0.003097] PCI/MSI: ITS at 0x801000020000 domain created
[    0.003107] fsl-mc MSI: ITS at 0x801000020000 domain created
[    0.003128] Remapping and enabling EFI services.
[    0.005245] smp: Bringing up secondary CPUs ...
[    0.005739] Detected VIPT I-cache on CPU1
[    0.005754] GICv3: CPU1: found redistributor 1 region 0:0x0000801080020000
[    0.005781] GICv3: CPU1: using allocated LPI pending table @0x00000001002a0000
[    0.005803] CPU1: Booted secondary processor 0x0000000001 [0x431f0a11]
[    0.006364] Detected VIPT I-cache on CPU2
[    0.006374] GICv3: CPU2: found redistributor 2 region 0:0x0000801080040000
[    0.006399] GICv3: CPU2: using allocated LPI pending table @0x00000001002b0000
[    0.006418] CPU2: Booted secondary processor 0x0000000002 [0x431f0a11]
[    0.006962] Detected VIPT I-cache on CPU3
[    0.006973] GICv3: CPU3: found redistributor 3 region 0:0x0000801080060000
[    0.006997] GICv3: CPU3: using allocated LPI pending table @0x00000001002c0000
[    0.007017] CPU3: Booted secondary processor 0x0000000003 [0x431f0a11]
[    0.008363] Detected VIPT I-cache on CPU4
[    0.008374] GICv3: CPU4: found redistributor 4 region 0:0x0000801080080000
[    0.008399] GICv3: CPU4: using allocated LPI pending table @0x00000001002d0000
[    0.008419] CPU4: Booted secondary processor 0x0000000004 [0x431f0a11]
[    0.008968] Detected VIPT I-cache on CPU5
[    0.008979] GICv3: CPU5: found redistributor 5 region 0:0x00008010800a0000
[    0.009004] GICv3: CPU5: using allocated LPI pending table @0x00000001002e0000
[    0.009025] CPU5: Booted secondary processor 0x0000000005 [0x431f0a11]
[    0.009566] Detected VIPT I-cache on CPU6
[    0.009577] GICv3: CPU6: found redistributor 6 region 0:0x00008010800c0000
[    0.009602] GICv3: CPU6: using allocated LPI pending table @0x00000001002f0000
[    0.009623] CPU6: Booted secondary processor 0x0000000006 [0x431f0a11]
[    0.010169] Detected VIPT I-cache on CPU7
[    0.010180] GICv3: CPU7: found redistributor 7 region 0:0x00008010800e0000
[    0.010206] GICv3: CPU7: using allocated LPI pending table @0x0000000100300000
[    0.010227] CPU7: Booted secondary processor 0x0000000007 [0x431f0a11]
[    0.010771] Detected VIPT I-cache on CPU8
[    0.010783] GICv3: CPU8: found redistributor 8 region 0:0x0000801080100000
[    0.010809] GICv3: CPU8: using allocated LPI pending table @0x0000000100310000
[    0.010830] CPU8: Booted secondary processor 0x0000000008 [0x431f0a11]
[    0.011382] Detected VIPT I-cache on CPU9
[    0.011394] GICv3: CPU9: found redistributor 9 region 0:0x0000801080120000
[    0.011419] GICv3: CPU9: using allocated LPI pending table @0x0000000100320000
[    0.011CPU10: using allocated LPI pending table @0x0000000100330000
[    0.012048] CPU10: Booted secondary processor 0x000000000a [0x431f0a11]
[    0.012613] Detected VIPT I-cache on CPU11
[    0.012626] GICv3: CPU11: found redistributor b region 0:0x0000801080160000
[    0.012651] GICv3: CPU11: using allocated LPI pending table @0x0000000100340000
[    0.012673] CPU11: Booted secondary processor 0x000000000b [0x431f0a11]
[    0.013215] Detected VIPT I-cache on CPU12
[    0.013227] GICv3: CPU12: found redistributor c region 0:0x0000801080180000
[    0.013253] GICv3: CPU12: using allocated LPI pending table @0x0000000100350000
[    0.013275] CPU12: Booted secondary processor 0x000000000c [0x431f0a11]
[    0.013837] Detected VIPT I-cache on CPU13
[    0.013850] GICv3: CPU13: found redistributor d region 0:0x00008010801a0000
[    0.013877] GICv3: CPU13: using allocated LPI pending table @0x0000000100360000
[    0.013899] CPU13: Booted secondary processor 0x000000000d [0x431f0a11]
[    0.014444] Detected VIPT I-cache on CPU14
[    0.014457] GICv3: CPU14: found redistributor e region 0:0x00008010801c0000
[    0.014483] GICv3: CPU14: using allocated LPI pending table @0x0000000100370000
[    0.014506] CPU14: Booted secondary processor 0x000000000e [0x431f0a11]
[    0.015064] Detected VIPT I-cache on CPU15
[    0.015077] GICv3: CPU15: found redistributor f region 0:0x00008010801e0000
[    0.015107] GICv3: CPU15: using allocated LPI pending table @0x0000000100380000
[    0.015130] CPU15: Booted secondary processor 0x000000000f [0x431f0a11]
[    0.015679] Detected VIPT I-cache on CPU16
[    0.015692] GICv3: CPU16: found redistributor 100 region 0:0x0000801080200000
[    0.015719] GICv3: CPU16: using allocated LPI pending table @0x0000000100390000
[    0.015741] CPU16: Booted secondary processor 0x0000000100 [0x431f0a11]
[    0.016300] Detected VIPT I-cache on CPU17
[    0.016314] GICv3: CPU17: found redistributor 101 region 0:0x0000801080220000
[    0.016341] GICv3: CPU17: using allocated LPI pending table @0x00000001003a0000
[    0.016364] CPU17: Booted secondary processor 0x0000000101 [0x431f0a11]
[    0.016932] Detected VIPT I-cache on CPU18
[    0.016945] GICv3: CPU18: found redistributor 102 region 0:0x0000801080240000
[    0.016973] GICv3: CPU18: using allocated LPI pending table @0x00000001003b0000
[    0.016996] CPU18: Booted secondary processor 0x0000000102 [0x431f0a11]
[    0.017548] Detected VIPT I-cache on CPU19
[    0.017563] GICv3: CPU19: found redistributor 103 region 0:0x0000801080260000
[    0.017591] GICv3: CPU19: using allocated LPI pending table @0x00000001003c0000
[    0.017614] CPU19: Booted secondary processor 0x0000000103 [0x431f0a11]
[    0.018172] Detected VIPT I-cache on CPU20
[    0.018186] GICv3: CPU20: found redistributor 104 region 0:0x0000801080280000
[    0.018213] GICv3: CPU20: using allocated LPI pending table @0x00000001003d0000
[    0.018237] CPU20: Booted secondary processor 0x0000000104 [0x431f0a11]
[    0.018783] Detected VIPT I-cache on CPU21
[    0.018797] GICv3: CPU21: found redistributor 105 region 0:0x00008010802a0000
[    0.018825] GICv3: CPU21: using allocated LPI pending table @0x00000001003e0000
[    0.018849] CPU21: Booted secondary processor 0x0000000105 [0x431f0a11]
[    0.019408] Detected VIPT I-cache on CPU22
[    0.019422] GICv3: CPU22: found redistributor 106 region 0:0x00008010802c0000
[    0.019450] GICv3: CPU22: using allocated LPI pending table @0x00000001003f0000
[    0.019474] CPU22: Booted secondary processor 0x0000000106 [0x431f0a11]
[    0.020034] Detected VIPT I-cache on CPU23
[    0.020049] GICv3: CPU23: found redistributor 107 region 0:0x00008010802e0000
[    0.020077] GICv3: CPU23: using allocated LPI pending table @0x0000000100400000
[    0.020102] CPU23: Booted secondary processor 0x0000000107 [0x431f0a11]
[    0.020675] Detected VIPT I-cache on CPU24
[    0.020690] GICv3: CPU24: found redistributor 108 region 0:0x0000801080300000
[    0.020717] GICv3: CPU24: using allocated LPI pending table @0x0000000100410000
[    0.020743] CPU24: Booted secondary processor 0x0000000108 [0x431f0a11]
[    0.021312] Detected VIPT I-cache on CPU25
[    0.021327] GICv3: CPU25: found redistributor 109 region 0:0x0000801080320000
[    0.021356] GICv3: CPU25: using allocated LPI pending table @0x0000000100420000
[    0.021381] CPU25: Booted secondary processor 0x0000000109 [0x431f0a11]
[    0.021936] Detected VIPT I-cache on CPU26
[    0.021951] GICv3: CPU26: found redistributor 10a region 0:0x0000801080340000
[    0.021980] GICv3: CPU26: using allocated LPI pending table @0x0000000100430000
[    0.022005] CPU26: Booted secondary processor 0x000000010a [0x431f0a11]
[    0.022571] Detected VIPT I-cache on CPU27
[    0.022587] GICv3: CPU27: found redistributor 10b region 0:0x0000801080360000
[    0.022615] GICv3: CPU27: using allocated LPI pending table @0x0000000100440000
[    0.022641] CPU27: Booted secondary processor 0x000000010b [0x431f0a11]
[    0.023198] Detected VIPT I-cache on CPU28
[    0.023213] GICv3: CPU28: found redistributor 10c region 0:0x0000801080380000
[    0.023242] GICv3: CPU28: using allocated LPI pending table @0x0000000100450000
[    0.023268] CPU28: Booted secondary processor 0x000000010c [0x431f0a11]
[    0.023833] Detected VIPT I-cache on CPU29
[    0.023848] GICv3: CPU29: found redistributor 10d region 0:0x00008010803a0000
[    0.023878] GICv3: CPU29: using allocated LPI pending table @0x0000000100460000
[    0.023905] CPU29: Booted secondary processor 0x000000010d [0x431f0a11]
[    0.024490] Detected VIPT I-cache on CPU30
[    0.024505] GICv3: CPU30: found redistributor 10e region 0:0x00008010803c0000
[    0.024534] GICv3: CPU30: using allocated LPI pending table @0x0000000100470000
[    0.024561] CPU30: Booted secondary processor 0x000000010e [0x431f0a11]
[    0.025127] Detected VIPT I-cache on CPU31
[    0.025143] GICv3: CPU31: found redistributor 10f region 0:0x00008010803e0000
[    0.025173] GICv3: CPU31: using allocated LPI pending table @0x0000000100480000
[    0.025200] CPU31: Booted secondary processor 0x000000010f [0x431f0a11]
[    0.025766] Detected VIPT I-cache on CPU32
[    0.025781] GICv3: CPU32: found redistributor 200 region 0:0x0000801080400000
[    0.025811] GICv3: CPU32: using allocated LPI pending table @0x0000000100490000
[    0.025838] CPU32: Booted secondary processor 0x0000000200 [0x431f0a11]
[    0.026417] Detected VIPT I-cache on CPU33
[    0.026434] GICv3: CPU33: found redistributor 201 region 0:0x0000801080420000
[    0.026463] GICv3: CPU33: using allocated LPI pending table @0x00000001004a0000
[    0.026490] CPU33: Booted secondary processor 0x0000000201 [0x431f0a11]
[    0.027062] Detected VIPT I-cache on CPU34
[    0.027078] GICv3: CPU34: found redistributor 202 region 0:0x0000801080440000
[    0.027108] GICv3: CPU34: using allocated LPI pending table @0x00000001004b0000
[    0.027135] CPU34: Booted secondary processor 0x0000000202 [0x431f0a11]
[    0.027705] Detected VIPT I-cache on CPU35
[    0.027722] GICv3: CPU35: found redistributor 203 region 0:0x0000801080460000
[    0.027752] GICv3: CPU35: using allocated LPI pending table @0x00000001004c0000
[    0.027780] CPU35: Booted secondary processor 0x0000000203 [0x431f0a11]
[    0.028354] Detected VIPT I-cache on CPU36
[    0.028371] GICv3: CPU36: found redistributor 204 region 0:0x0000801080480000
[    0.028401] GICv3: CPU36: using allocated LPI pending table @0x00000001004d0000
[    0.028430] CPU36: Booted secondary processor 0x0000000204 [0x431f0a11]
[    0.028997] Detected VIPT I-cache on CPU37
[    0.029014] GICv3: CPU37: found redistributor 205 region 0:0x00008010804a0000
[    0.029044] GICv3: CPU37: using allocated LPI pending table @0x00000001004e0000
[    0.029073] CPU37: Booted secondary processor 0x0000000205 [0x431f0a11]
[    0.029658] Detected VIPT I-cache on CPU38
[    0.029675] GICv3: CPU38: found redistributor 206 region 0:0x00008010804c0000
[    0.029705] GICv3: CPU38: using allocated LPI pending table @0x00000001004f0000
[    0.029734] CPU38: Booted secondary processor 0x0000000206 [0x431f0a11]
[    0.030298] Detected VIPT I-cache on CPU39
[    0.030315] GICv3: CPU39: found redistributor 207 region 0:0x00008010804e0000
[    0.030346] GICv3: CPU39: using allocated LPI pending table @0x0000000100500000
[    0.030375] CPU39: Booted secondary processor 0x0000000207 [0x431f0a11]
[    0.030951] Detected VIPT I-cache on CPU40
[    0.030969] GICv3: CPU40: found redistributor 208 region 0:0x0000801080500000
[    0.030999] GICv3: CPU40: using allocated LPI pending table @0x0000000100510000
[    0.031029] CPU40: Booted secondary processor 0x0000000208 [0x431f0a11]
[    0.031605] Detected VIPT I-cache on CPU41
[    0.031623] GICv3: CPU41: found redistributor 209 region 0:0x0000801080520000
[    0.031654] GICv3: CPU41: using allocated LPI pending table @0x0000000100520000
[    0.031683] CPU41: Booted secondary processor 0x0000000209 [0x431f0a11]
[    0.032260] Detected VIPT I-cache on CPU42
[    0.032278] GICv3: CPU42: found redistributor 20a region 0:0x0000801080540000
[    0.032308] GICv3: CPU42: using allocated LPI pending table @0x0000000100530000
[    0.032338] CPU42: Booted secondary processor 0x000000020a [0x431f0a11]
[    0.032913] Detected VIPT I-cache on CPU43
[    0.032931] GICv3: CPU43: found redistributor 20b region 0:0x0000801080560000
[    0.032962] GICv3: CPU43: using allocated LPI pending table @0x0000000100540000
[    0.032992] CPU43: Booted secondary processor 0x000000020b [0x431f0a11]
[    0.033571] Detected VIPT I-cache on CPU44
[    0.033589] GICv3: CPU44: found redistributor 20c region 0:0x0000801080580000
[    0.033620] GICv3: CPU44: using allocated LPI pending table @0x0000000100550000
[    0.033650] CPU44: Booted secondary processor 0x000000020c [0x431f0a11]
[    0.034235] Detected VIPT I-cache on CPU45
[    0.034254] GICv3: CPU45: found redistributor 20d region 0:0x00008010805a0000
[    0.034285] GICv3: CPU45: using allocated LPI pending table @0x0000000100560000
[    0.034316] CPU45: Booted secondary processor 0x000000020d [0x431f0a11]
[    0.034893] Detected VIPT I-cache on CPU46
[    0.034912] GICv3: CPU46: found redistributor 20e region 0:0x00008010805c0000
[    0.034944] GICv3: CPU46: using allocated LPI pending table @0x0000000100570000
[    0.034974] CPU46: Booted secondary processor 0x000000020e [0x431f0a11]
[    0.035553] Detected VIPT I-cache on CPU47
[    0.035573] GICv3: CPU47: found redistributor 20f region 0:0x00008010805e0000
[    0.035604] GICv3: CPU47: using allocated LPI pending table @0x0000000100580000
[    0.035635] CPU47: Booted secondary processor 0x000000020f [0x431f0a11]
[    0.035745] smp: Brought up 1 node, 48 CPUs
[    0.036015] SMP: Total of 48 processors activated.
[    0.036022] CPU features: detected: Data cache clean to the PoU not required for I/D coherence
[    0.036027] CPU features: detected: CRC32 instructions
[    0.036265] CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
[    0.044965] CPU: All CPU(s) started at EL2
[    0.045123] alternatives: patching kernel code
[    0.058571] devtmpfs: initialized
[    0.061951] Registered cp15_barrier emulation handler
[    0.061976] Registered setend emulation handler
[    0.061984] KASLR disabled due to lack of seed
[    0.062154] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.062224] futex hash table entries: 16384 (order: 8, 1048576 bytes, linear)
[    0.063592] pinctrl core: initialized pinctrl subsystem
[    0.064122] SMBIOS 3.0.0 present.
[    0.064136] DMI: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    0.064654] NET: Registered protocol family 16
[    0.068677] DMA: preallocated 8192 KiB GFP_KERNEL pool for atomic allocations
[    0.069902] DMA: preallocated 8192 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.072709] DMA: preallocated 8192 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.072766] audit: initializing netlink subsys (disabled)
[    0.072987] audit: type=2000 audit(0.072:1): state=initialized audit_enabled=0 res=1
[    0.073545] thermal_sys: Registered thermal governor 'fair_share'
[    0.073551] thermal_sys: Registered thermal governor 'bang_bang'
[    0.073556] thermal_sys: Registered thermal governor 'step_wise'
[    0.073561] thermal_sys: Registered thermal governor 'user_space'
[    0.073565] thermal_sys: Registered thermal governor 'power_allocator'
[    0.073753] cpuidle: using governor ladder
[    0.074029] cpuidle: using governor menu
[    0.074319] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.075056] ASID allocator initialised with 65536 entries
[    0.075356] ACPI: bus type PCI registered
[    0.075364] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.075614] Serial: AMBA PL011 UART driver
[    0.084001] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.084009] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.084015] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.084020] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.089191] ACPI: Added _OSI(Module Device)
[    0.089199] ACPI: Added _OSI(Processor Device)
[    0.089203] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.089208] ACPI: Added _OSI(Processor Aggregator Device)
[    0.089214] ACPI: Added _OSI(Linux-Dell-Video)
[    0.089219] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.089224] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.093110] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.095000] ACPI: Interpreter enabled
[    0.095006] ACPI: Using GIC for interrupt routing
[    0.095035] ACPI: MCFG table detected, 4 entries
[    0.118740] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-1f])
[    0.118758] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    0.118904] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    0.119032] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability]
[    0.119502] acpi PNP0A08:00: ECAM area [mem 0x848000000000-0x848001ffffff] reserved by CAVA02C:00
[    0.119521] acpi PNP0A08:00: ECAM at [mem 0x848000000000-0x848001ffffff] for [bus 00-1f]
[    0.119665] PCI host bridge to bus 0000:00
[    0.119673] pci_bus 0000:00: root bus resource [mem 0x801000000000-0x807fffffffff window]
[    0.119681] pci_bus 0000:00: root bus resource [mem 0x838000000000-0x841fffffffff window]
[    0.119687] pci_bus 0000:00: root bus resource [mem 0x846000000000-0x847fffffffff window]
[    0.119694] pci_bus 0000:00: root bus resource [mem 0x868000000000-0x87e023ffffff window]
[    0.119700] pci_bus 0000:00: root bus resource [mem 0x87e026000000-0x87e0bfffffff window]
[    0.119707] pci_bus 0000:00: root bus resource [mem 0x87e0c6000000-0x87ffffffffff window]
[    0.119714] pci_bus 0000:00: root bus resource [bus 00-1f]
[    0.119743] pci 0000:00:01.0: [177d:a002] type 01 class 0x060400
[    0.119915] pci 0000:00:09.0: [177d:a018] type 00 class 0x120000
[    0.119952] pci 0000:00:09.0: BAR 0: [mem 0x87e040000000-0x87e0400fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    0.119962] pci 0000:00:09.0: VF BAR 0: [mem 0x840000800000-0x8400008fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.153606] pci 0000:00:09.0: VF(n) BAR0 space: [mem 0x840000800000-0x8400008fffff 64bit] (contains BAR0 for 1 VFs)
[    1.153757] pci 0000:00:10.0: [177d:a01b] type 00 class 0x0c0330
[    1.153798] pci 0000:00:10.0: BAR 0: [mem 0x868000000000-0x8680001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153808] pci 0000:00:10.0: BAR 4: [mem 0x868000200000-0x8680002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153936] pci 0000:00:11.0: [177d:a01b] type 00 class 0x0c0330
[    1.153972] pci 0000:00:11.0: BAR 0: [mem 0x869000000000-0x8690001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153982] pci 0000:00:11.0: BAR 4: [mem 0x869000200000-0x8690002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154109] pci 0000:00:14.0: [177d:a002] type 01 class 0x060400
[    1.154312] pci 0000:01:00.0: [177d:a001] type 00 class 0x088000
[    1.154349] pci 0000:01:00.0: BAR 0: [mem 0x87e0fc000000-0x87e0fc0fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154358] pci 0000:01:00.0: BAR 4: [mem 0x87e0fcf00000-0x87e0fcffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154484] pci 0000:01:00.1: [177d:a00e] type 00 class 0x088000
[    1.154522] pci 0000:01:00.1: BAR 0: [mem 0x87e006000000-0x87e0067fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154531] pci 0000:01:00.1: BAR 4: [mem 0x87e006f00000-0x87e006ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154651] pci 0000:01:01.3: [177d:a02b] type 00 class 0x0c8000
[    1.154687] pci 0000:01:01.3: BAR 0: [mem 0x87e005000000-0x87e0057fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154805] pci 0000:01:01.4: [177d:a010] type 00 class 0x058000
[    1.154841] pci 0000:01:01.4: BAR 0: [mem 0x87e009000000-0x87e0097fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154850] pci 0000:01:01.4: BAR 4: [mem 0x87e009f00000-0x87e009ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154971] pci 0000:01:06.0: [177d:a02e] type 00 class 0x058000
[    1.155012] pci 0000:01:06.0: BAR 0: [mem 0x87e050000000-0x87e0507fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155021] pci 0000:01:06.0: BAR 4: [mem 0x87e050f00000-0x87e050ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155149] pci 0000:01:06.1: [177d:a02e] type 00 class 0x058000
[    1.155186] pci 0000:01:06.1: BAR 0: [mem 0x87e051000000-0x87e0517fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155196] pci 0000:01:06.1: BAR 4: [mem 0x87e051f00000-0x87e051ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155316] pci 0000:01:06.2: [177d:a02e] type 00 class 0x058000
[    1.155354] pci 0000:01:06.2: BAR 0: [mem 0x87e052000000-0x87e0527fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155363] pci 0000:01:06.2: BAR 4: [mem 0x87e052f00000-0x87e052ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155485] pci 0000:01:06.3: [177d:a02e] type 00 class 0x058000
[    1.155522] pci 0000:01:06.3: BAR 0: [mem 0x87e053000000-0x87e0537fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155531] pci 0000:01:06.3: BAR 4: [mem 0x87e053f00000-0x87e053ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155651] pci 0000:01:06.4: [177d:a02e] type 00 class 0x058000
[    1.155687] pci 0000:01:06.4: BAR 0: [mem 0x87e054000000-0x87e0547fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155697] pci 0000:01:06.4: BAR 4: [mem 0x87e054f00000-0x87e054ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155817] pci 0000:01:06.5: [177d:a02e] type 00 class 0x058000
[    1.155854] pci 0000:01:06.5: BAR 0: [mem 0x87e055000000-0x87e0557fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155863] pci 0000:01:06.5: BAR 4: [mem 0x87e055f00000-0x87e055ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155986] pci 0000:01:06.6: [177d:a02e] type 00 class 0x058000
[    1.156023] pci 0000:01:06.6: BAR 0: [mem 0x87e056000000-0x87e0567fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156032] pci 0000:01:06.6: BAR 4: [mem 0x87e056f00000-0x87e056ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156152] pci 0000:01:06.7: [177d:a02e] type 00 class 0x058000
[    1.156188] pci 0000:01:06.7: BAR 0: [mem 0x87e057000000-0x87e0577fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156198] pci 0000:01:06.7: BAR 4: [mem 0x87e057f00000-0x87e057ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156318] pci 0000:01:07.0: [177d:a02f] type 00 class 0x058000
[    1.156358] pci 0000:01:07.0: BAR 0: [mem 0x87e058000000-0x87e0587fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156367] pci 0000:01:07.0: BAR 4: [mem 0x87e058f00000-0x87e058ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156496] pci 0000:01:07.1: [177d:a02f] type 00 class 0x058000
[    1.156534] pci 0000:01:07.1: BAR 0: [mem 0x87e059000000-0x87e0597fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156543] pci 0000:01:07.1: BAR 4: [mem 0x87e059f00000-0x87e059ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156664] pci 0000:01:07.2: [177d:a02f] type 00 class 0x058000
[    1.156701] pci 0000:01:07.2: BAR 0: [mem 0x87e05a000000-0x87e05a7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156710] pci 0000:01:07.2: BAR 4: [mem 0x87e05af00000-0x87e05affffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156831] pci 0000:01:07.3: [177d:a02f] type 00 class 0x058000
[    1.156868] pci 0000:01:07.3: BAR 0: [mem 0x87e05b000000-0x87e05b7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156877] pci 0000:01:07.3: BAR 4: [mem 0x87e05bf00000-0x87e05bffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157000] pci 0000:01:07.4: [177d:a030] type 00 class 0x058000
[    1.157037] pci 0000:01:07.4: BAR 0: [mem 0x87e05c000000-0x87e05c7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157046] pci 0000:01:07.4: BAR 4: [mem 0x87e05cf00000-0x87e05cffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157166] pci 0000:01:07.5: [177d:a030] type 00 class 0x058000
[    1.157203] pci 0000:01:07.5: BAR 0: [mem 0x87e05d000000-0x87e05d7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157212] pci 0000:01:07.5: BAR 4: [mem 0x87e05df00000-0x87e05dffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157341] pci 0000:01:07.6: [177d:a030] type 00 class 0x058000
[    1.157378] pci 0000:01:07.6: BAR 0: [mem 0x87e05e000000-0x87e05e7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157388] pci 0000:01:07.6: BAR 4: [mem 0x87e05ef00000-0x87e05effffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157509] pci 0000:01:07.7: [177d:a030] type 00 class 0x058000
[    1.157546] pci 0000:01:07.7: BAR 0: [mem 0x87e05f000000-0x87e05f7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157555] pci 0000:01:07.7: BAR 4: [mem 0x87e05ff00000-0x87e05fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157688] pci 0000:01:09.2: [177d:a012] type 00 class 0x0c8000
[    1.157730] pci 0000:01:09.2: BAR 0: [mem 0x87e0d2000000-0x87e0d27fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157739] pci 0000:01:09.2: BAR 4: [mem 0x87e0d2f00000-0x87e0d2ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157866] pci 0000:01:09.4: [177d:a012] type 00 class 0x0c8000
[    1.157903] pci 0000:01:09.4: BAR 0: [mem 0x87e0d4000000-0x87e0d47fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157912] pci 0000:01:09.4: BAR 4: [mem 0x87e0d4f00000-0x87e0d4ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158042] pci 0000:01:0a.0: [177d:a022] type 00 class 0x058000
[    1.158079] pci 0000:01:0a.0: BAR 0: [mem 0x87e088000000-0x87e0887fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158088] pci 0000:01:0a.0: BAR 4: [mem 0x87e088f00000-0x87e088ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158211] pci 0000:01:0a.1: [177d:a022] type 00 class 0x058000
[    1.158248] pci 0000:01:0a.1: BAR 0: [mem 0x87e089000000-0x87e0897fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158257] pci 0000:01:0a.1: BAR 4: [mem 0x87e089f00000-0x87e089ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158380] pci 0000:01:10.0: [177d:a026] type 00 class 0x028000
[    1.158416] pci 0000:01:10.0: BAR 0: [mem 0x87e0e0000000-0x87e0e03fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158425] pci 0000:01:10.0: BAR 4: [mem 0x87e0e0400000-0x87e0e07fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158548] pci 0000:01:10.1: [177d:a026] type 00 class 0x028000
[    1.158584] pci 0000:01:10.1: BAR 0: [mem 0x87e0e1000000-0x87e0e13fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158593] pci 0000:01:10.1: BAR 4: [mem 0x87e0e1400000-0x87e0e17fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158704] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.158871] pci 0000:02:00.0: [177d:a01d] type 00 class 0x010400
[    1.158908] pci 0000:02:00.0: BAR 0: [mem 0x870000000000-0x8700007fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158917] pci 0000:02:00.0: BAR 4: [mem 0x870000f00000-0x870000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.159031] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.159109] pci 0000:00:01.0: PCI bridge to [bus 01]
[    1.159123] pci 0000:00:14.0: PCI bridge to [bus 02]
[    1.159131] pci_bus 0000:00: resource 4 [mem 0x801000000000-0x807fffffffff window]
[    1.159138] pci_bus 0000:00: resource 5 [mem 0x838000000000-0x841fffffffff window]
[    1.159144] pci_bus 0000:00: resource 6 [mem 0x846000000000-0x847fffffffff window]
[    1.159150] pci_bus 0000:00: resource 7 [mem 0x868000000000-0x87e023ffffff window]
[    1.159157] pci_bus 0000:00: resource 8 [mem 0x87e026000000-0x87e0bfffffff window]
[    1.159163] pci_bus 0000:00: resource 9 [mem 0x87e0c6000000-0x87ffffffffff window]
[    1.159327] ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-1f])
[    1.159340] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.159482] acpi PNP0A08:01: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.159611] acpi PNP0A08:01: _OSC: OS now controls [PCIeCapability]
[    1.160089] acpi PNP0A08:01: ECAM area [mem 0x849000000000-0x849001ffffff] reserved by CAVA02C:01
[    1.160105] acpi PNP0A08:01: ECAM at [mem 0x849000000000-0x849001ffffff] for [bus 00-1f]
[    1.160233] PCI host bridge to bus 0001:00
[    1.160241] pci_bus 0001:00: root bus resource [mem 0x810000000000-0x817fffffffff window]
[    1.160249] pci_bus 0001:00: root bus resource [bus 00-1f]
[    1.160277] pci 0001:00:08.0: [177d:a01c] type 00 class 0x010601
[    1.160310] pci 0001:00:08.0: BAR 0: [mem 0x814000000000-0x8140001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160319] pci 0001:00:08.0: BAR 4: [mem 0x814000200000-0x8140002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160447] pci 0001:00:09.0: [177d:a01c] type 00 class 0x010601
[    1.160483] pci 0001:00:09.0: BAR 0: [mem 0x815000000000-0x8150001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160492] pci 0001:00:09.0: BAR 4: [mem 0x815000200000-0x8150002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160621] pci 0001:00:0a.0: [177d:a01c] type 00 class 0x010601
[    1.160660] pci 0001:00:0a.0: BAR 0: [mem 0x816000000000-0x8160001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160669] pci 0001:00:0a.0: BAR 4: [mem 0x816000200000-0x8160002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160797] pci 0001:00:0b.0: [177d:a01c] type 00 class 0x010601
[    1.160833] pci 0001:00:0b.0: BAR 0: [mem 0x817000000000-0x8170001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160842] pci 0001:00:0b.0: BAR 4: [mem 0x817000200000-0x8170002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160976] pci_bus 0001:00: resource 4 [mem 0x810000000000-0x817fffffffff window]
[    1.161088] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
[    1.161101] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.161242] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.161371] acpi PNP0A08:02: _OSC: OS now controls [PCIeCapability]
[    1.161879] acpi PNP0A08:02: ECAM area [mem 0x84a000000000-0x84a001ffffff] reserved by CAVA02C:02
[    1.161895] acpi PNP0A08:02: ECAM at [mem 0x84a000000000-0x84a001ffffff] for [bus 00-1f]
[    1.162028] PCI host bridge to bus 0002:00
[    1.162035] pci_bus 0002:00: root bus resource [mem 0x842000000000-0x843fffffffff window]
[    1.162043] pci_bus 0002:00: root bus resource [bus 00-1f]
[    1.162067] pci 0002:00:02.0: [177d:a002] type 01 class 0x060400
[    1.162214] pci 0002:00:03.0: [177d:a01f] type 00 class 0x028000
[    1.162251] pci 0002:00:03.0: BAR 0: [mem 0x842000000000-0x84200000ffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162260] pci 0002:00:03.0: BAR 2: [mem 0x842040000000-0x84207fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162269] pci 0002:00:03.0: BAR 4: [mem 0x842000f00000-0x842000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162462] pci 0002:01:00.0: [177d:a01e] type 00 class 0x020000
[    1.162499] pci 0002:01:00.0: BAR 0: [mem 0x843000000000-0x84303fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162509] pci 0002:01:00.0: BAR 4: [mem 0x843060000000-0x8430600fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162517] pci 0002:01:00.0: VF BAR 0: [mem 0x8430a0000000-0x8430a01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.162526] pci 0002:01:00.0: VF BAR 4: [mem 0x8430e0000000-0x8430e01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    2.178227] pci 0002:01:00.0: VF(n) BAR0 space: [mem 0x8430a0000000-0x8430afffffff 64bit] (contains BAR0 for 128 VFs)
[    2.178242] pci 0002:01:00.0: VF(n) BAR4 space: [mem 0x8430e0000000-0x8430efffffff 64bit] (contains BAR4 for 128 VFs)
[    2.178455] pci 0002:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.178481] pci 0002:00:02.0: PCI bridge to [bus 01]
[    2.178490] pci_bus 0002:00: resource 4 [mem 0x842000000000-0x843fffffffff window]
[    2.178603] ACPI: PCI Root Bridge [PCI3] (domain 0003 [bus 00-1f])
[    2.178616] acpi PNP0A08:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.178758] acpi PNP0A08:03: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.178887] acpi PNP0A08:03: _OSC: OS now controls [PCIeCapability]
[    2.179408] acpi PNP0A08:03: ECAM area [mem 0x84b000000000-0x84b001ffffff] reserved by CAVA02C:03
[    2.179425] acpi PNP0A08:03: ECAM at [mem 0x84b000000000-0x84b001ffffff] for [bus 00-1f]
[    2.179557] PCI host bridge to bus 0003:00
[    2.179564] pci_bus 0003:00: root bus resource [mem 0x818000000000-0x81ffffffffff window]
[    2.179572] pci_bus 0003:00: root bus resource [bus 00-1f]
[    2.179607] pci_bus 0003:00: resource 4 [mem 0x818000000000-0x81ffffffffff window]
[    2.179717] ACPI: PCI Root Bridge [PEM0] (domain 0004 [bus 1f-57])
[    2.179730] acpi PNP0A08:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.179870] acpi PNP0A08:04: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.180000] acpi PNP0A08:04: _OSC: OS now controls [PCIeCapability]
[    2.180009] acpi PNP0A08:04: MCFG quirk: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57] with thunder_pem_ecam_ops
[    2.180563] acpi PNP0A08:04: ECAM area [mem 0x88001f000000-0x880057ffffff] reserved by CAVA02B:00
[    2.181159] acpi PNP0A08:04: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57]
[    2.181195] Remapped I/O 0x0000883000000000 to [io  0x0000-0xffff window]
[    2.181331] PCI host bridge to bus 0004:1f
[    2.181339] pci_bus 0004:1f: root bus resource [io  0x0000-0xffff window]
[    2.181347] pci_bus 0004:1f: root bus resource [mem 0x881010000000-0x881fffffffff window] (bus address [0x10000000-0xfffffffff])
[    2.181355] pci_bus 0004:1f: root bus resource [mem 0x882000000000-0x882fffffffff pref window] (bus address [0x1000000000-0x1fffffffff])
[    2.181362] pci_bus 0004:1f: root bus resource [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.181369] pci_bus 0004:1f: root bus resource [bus 1f-57]
[    2.181395] pci 0004:1f:00.0: [177d:a100] type 01 class 0x060400
[    2.181411] pci 0004:1f:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit pref]
[    2.181421] pci 0004:1f:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    2.181436] pci 0004:1f:00.0: enabling Extended Tags
[    2.181461] pci 0004:1f:00.0: BAR 0: [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    2.181635] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.181732] pci 0004:20:00.0: [1a03:1150] type 01 class 0x060400
[    2.181783] pci 0004:20:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)
[    2.181792] pci 0004:20:00.0: Max Payload Size set to 128 (was 128, max 128)
[    2.181801] pci 0004:20:00.0: enabling Extended Tags
[    2.181888] pci 0004:20:00.0: supports D1 D2
[    2.181894] pci 0004:20:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.182063] pci 0004:20:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.182130] pci_bus 0004:21: extended config space not accessible
[    2.182191] pci 0004:21:00.0: [1a03:2000] type 00 class 0x030000
[    2.182211] pci 0004:21:00.0: reg 0x10: [mem 0x881010000000-0x881010ffffff]
[    2.182235] pci 0004:21:00.0: reg 0x14: [mem 0x881011000000-0x88101101ffff]
[    2.182247] pci 0004:21:00.0: reg 0x18: [io  0x0000-0x007f]
[    2.182292] pci 0004:21:00.0: BAR 0: assigned to efifb
[    2.182341] pci 0004:21:00.0: supports D1 D2
[    2.182347] pci 0004:21:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.182542] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.182560] pci 0004:1f:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.182569] pci 0004:1f:00.0: BAR 6: assigned [mem 0x881011800000-0x88101180ffff pref]
[    2.182576] pci 0004:1f:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.182585] pci 0004:20:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.182592] pci 0004:20:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.182600] pci 0004:21:00.0: BAR 0: assigned [mem 0x881010000000-0x881010ffffff]
[    2.182609] pci 0004:21:00.0: BAR 1: assigned [mem 0x881011000000-0x88101101ffff]
[    2.182618] pci 0004:21:00.0: BAR 2: assigned [io  0x1000-0x107f]
[    2.182626] pci 0004:20:00.0: PCIbridge to [bus 20-21]
[    2.182653] pci 0004:1f:00.0:   bridge window [io  0x1000-0x1fff]
[    2.182660] pci 0004:1f:00.0:   bridge window [mem 0x881010000000-0x8810117fffff]
[    2.182668] pci_bus 0004:1f: resource 4 [io  0x0000-0xffff window]
[    2.182674] pci_bus 0004:1f: resource 5 [mem 0x881010000000-0x881fffffffff window]
[    2.182680] pci_bus 0004:1f: resource 6 [mem 0x882000000000-0x882fffffffff pref window]
[    2.182687] pci_bus 0004:1f: resource 7 [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.182693] pci_bus 0004:20: resource 0 [io  0x1000-0x1fff]
[    2.182699] pci_bus 0004:20: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.182706] pci_bus 0004:21: resource 0 [io  0x1000-0x1fff]
[    2.182712] pci_bus 0004:21: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.182830] ACPI: PCI Interrupt Link [LN0A] (IRQs *48)
[    2.182882] ACPI: PCI Interrupt Link [LN0B] (IRQs *49)
[    2.182929] ACPI: PCI Interrupt Link [LN0C] (IRQs *50)
[    2.182976] ACPI: PCI Interrupt Link [LN0D] (IRQs *51)
[    2.183270] ARMH0011:00: ttyAMA0 at MMIO 0x87e024000000 (irq = 21, base_baud = 0) is a SBSA
[    6.410105] printk: console [ttyAMA0] enabled
[    6.417695] ARMH0011:01: ttyAMA1 at MMIO 0x87e025000000 (irq = 22, base_baud = 0) is a SBSA
[    6.432839] iommu: Default domain type: Translated 
[    6.438451] SCSI subsystem initialized
[    6.442472] pci 0004:21:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
[    6.450830] pci 0004:21:00.0: vgaarb: bridge control possible
[    6.456570] pci 0004:21:00.0: vgaarb: setting as boot device (VGA legacy resources not available)
[    6.465432] vgaarb: loaded
[    6.468188] ACPI: bus type USB registered
[    6.472245] usbcore: registered new interface driver usbfs
[    6.477756] usbcore: registered new interface driver hub
[    6.483112] usbcore: registered new device driver usb
[    6.488250] pps_core: LinuxPPS API ver. 1 registered
[    6.493212] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
[    6.502346] PTP clock support registered
[    6.506465] EDAC MC: Ver: 3.0.0
[    6.510054] Registered efivars operations
[    6.515854] NetLabel: Initializing
[    6.519257] NetLabel:  domain hash size = 128
[    6.523605] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    6.529294] NetLabel:  unlabeled traffic allowed by default
[    6.535499] clocksource: Switched to clocksource arch_sys_counter
[    6.581508] VFS: Disk quotas dquot_6.6.0
[    6.585491] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    6.592632] pnp: PnP ACPI init
[    6.596310] system 00:00: [mem 0x848000000000-0x848001ffffff] could not be reserved
[    6.604162] system 00:01: [mem 0x849000000000-0x849001ffffff] could not be reserved
[    6.612012] system 00:02: [mem 0x84a000000000-0x84a001ffffff] could not be reserved
[    6.619856] system 00:03: [mem 0x84b000000000-0x84b001ffffff] could not be reserved
[    6.627713] system 00:04: [mem 0x87e0c0000000-0x87e0c0ffffff] could not be reserved
[    6.635374] system 00:04: [mem 0x88001f000000-0x880057ffffff] could not be reserved
[    6.645259] pnp: PnP ACPI: found 5 devices
[    6.655213] NET: Registered protocol family 2
[    6.660206] tcp_listen_portaddr_hash hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    6.669442] TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    6.679300] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
[    6.687069] TCP: Hash tables configured (established 524288 bind 65536)
[    6.694018] MPTCP token hash table entries: 65536 (order: 8, 1572864 bytes, linear)
[    6.702227] UDP hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.709784] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.717920] NET: Registered protocol family 1
[    6.722293] NET: Registered protocol family 44
[    6.726930] PCI: CLS 0 bytes, default 64
[    6.730959] Trying to unpack rootfs image as initramfs...
[    8.239745] Freeing initrd memory: 106132K
[    8.247176] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available
[    8.255210] kvm [1]: IPA Size Limit: 48 bits
[    8.261136] kvm [1]: GICv3: no GICV resource entry
[    8.265933] kvm [1]: disabling GICv2 emulation
[    8.270367] kvm [1]: GICv3 sysreg trapping enabled ([G0G1], reduced performance)
[    8.277767] kvm [1]: GIC system register CPU interface enabled
[    8.284738] kvm [1]: vgic interrupt IRQ9
[    8.289892] kvm [1]: Hyp mode initialized successfully
[    8.297815] Initialise system trusted keyrings
[    8.302285] Key type blacklist registered
[    8.306483] workingset: timestamp_bits=40 max_order=24 bucket_order=0
[    8.317158] zbud: loaded
[    8.320884] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    8.327253] fuse: init (API version 7.33)
[    8.331648] integrity: Platform Keyring initialized
[    8.359114] Key type asymmetric registered
[    8.363210] Asymmetric key parser 'x509' registered
[    8.368099] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 242)
[    8.375627] io scheduler mq-deadline registered
[    8.383525] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    8.391174] efifb: probing for efifb
[    8.394782] efifb: No BGRT, not showing boot graphics
[    8.399826] efifb: framebuffer at 0x881010000000, using 3072k, total 3072k
[    8.406692] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    8.412690] efifb: scrolling: redraw
[    8.416256] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    8.421952] fbcon: Deferring console take-over
[    8.426403] fb0: EFI VGA frame buffer device
[    8.431351] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    8.439771] ACPI: Power Button [PWRB]
[    8.444895] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
[    8.455456] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
[    8.464493] Mem abort info:
[    8.467274]   ESR = 0x96000004
[    8.470317]   EC = 0x25: DABT (current EL), IL = 32 bits
[    8.475618]   SET = 0, FnV = 0
[    8.478661]   EA = 0, S1PTW = 0
[    8.481790] Data abort info:
[    8.484659]   ISV = 0, ISS = 0x00000004
[    8.488482]   CM = 0, WnR = 0
[    8.491439] [0000000000000028] user address but active_mm is swapper
[    8.497782] Internal error: Oops: 96000004 [#1] SMP
[    8.502649] Modules linked in:
[    8.505698] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.11.0-13-generic #14-Ubuntu
[    8.513256] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    8.520119] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[    8.526115] pc : __ipi_send_mask+0x60/0x114
[    8.530296] lr : smp_cross_call+0x3c/0xdc
[    8.534299] sp : ffff80001279bc90
[    8.537602] x29: ffff80001279bc90 x28: 000000000000000a 
[    8.542907] x27: ffff8000114eb2d8 x26: ffff8000122e5108 
[    8.548211] x25: 0000000000000001 x24: 0000000000000000 
[    8.553515] x23: ffff8000122ee000 x22: ffff8000123f8448 
[    8.558820] x21: ffff800010fd9a28 x20: ffff800010fd9a28 
[    8.564124] x19: ffff000100157c60 x18: 0000000000000020 
[    8.569428] x17: 0000000001f80e3b x16: 000000005628f43e 
[    8.574732] x15: ffffffffffffffff x14: 0000000000000000 
[    8.580036] x13: 003d090000000000 x12: 00003d0900000000 
[    8.585341] x11: 0000000000000000 x10: 00003d0900000000 
[    8.590645] x9 : ffff800010028c40 x8 : 0000000000000001 
[    8.595949] x7 : 00000000ffffffff x6 : ffff000ff61d0318 
[    8.601253] x5 : ffff80001161f2a0 x4 : ffff80001161f370 
[    8.606557] x3 : ffff800010fd99e8 x2 : 0000000000000000 
[    8.611861] x1 : ffff800010fd9a28 x0 : 0000000000000000 
[    8.617166] Call trace:
[    8.619602]  __ipi_send_mask+0x60/0x114
[    8.623428]  smp_cross_call+0x3c/0xdc
[    8.627081]  smp_send_reschedule+0x3c/0x50
[    8.631169]  resched_curr+0x5c/0xb0
[    8.634649]  check_preempt_curr+0x58/0x90
[    8.638649]  ttwu_do_wakeup+0x2c/0x1a0
[    8.642389]  ttwu_do_activate+0x7c/0x114
[    8.646301]  try_to_wake_up+0x2cc/0x5b0
[    8.650128]  wake_up_process+0x24/0x30
[    8.653867]  swake_up_one+0x48/0x9c
[    8.657346]  rcu_gp_kthread_wake+0x68/0x8c
[    8.661433]  rcu_accelerate_cbs_unlocked+0xb4/0xf0
[    8.666214]  rcu_core+0x208/0x230
[    8.669520]  rcu_core_si+0x1c/0x30
[    8.672911]  __do_softirq+0x128/0x3a4
[    8.676563]  irq_exit+0xc4/0xec
[    8.679695]  __handle_domain_irq+0x8c/0xec
[    8.683783]  gic_handle_irq+0x84/0xfc
[    8.687435]  el1_irq+0xc0/0x180
[    8.690566]  ww_mutex_lock+0x320/0x540
[    8.694306]  kobject_uevent_env+0x324/0x4c4
[    8.698481]  kobject_uevent+0x14/0x20
[    8.702133]  driver_register+0xc0/0x140
[    8.705961]  __platform_driver_register+0x34/0x40
[    8.710656]  scpsys_drv_init+0x28/0x34
[    8.714398]  do_one_initcall+0x50/0x290
[    8.718224]  do_initcalls+0x104/0x144
[    8.721881]  kernel_init_freeable+0x174/0x1c0
[    8.726228]  kernel_init+0x20/0x134
[    8.729708]  ret_from_fork+0x10/0x18
[    8.733278] Code: a90363f7 aa0103f5 b0010db7 f9401260 (b9402800) 
[    8.739394] ---[ end trace 4c5c8d7f98c860a1 ]---
[    8.744001] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[    8.750883] SMP: stopping secondary CPUs
[    9.798801] SMP: failed to stop secondary CPUs 2,8
[    9.803583] Kernel Offset: disabled
[    9.807059] CPU features: 0x00040002,69101108
[    9.811405] Memory Limit: none
[    9.814467] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---


From robh+dt at kernel.org  Tue Apr 20 22:05:59 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Tue, 20 Apr 2021 16:05:59 -0500
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
Message-ID: <CAL_JsqJVUq2D9B5SwNc6VFOQFS_Qkry4ATwTYGRJE6qkpaFM+A@mail.gmail.com>

On Tue, Apr 20, 2021 at 11:10 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Tue, 20 Apr 2021 at 17:54, Rob Herring <robh+dt at kernel.org> wrote:
> >
> > On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
> > <alexandre.torgue at foss.st.com> wrote:
> > >
> > >
> > >
> > > On 4/20/21 4:45 PM, Rob Herring wrote:
> > > > On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
> > > > <alexandre.torgue at foss.st.com> wrote:
> > > >>
> > > >> Hi,
> > > >
> > > > Greg or Sasha won't know what to do with this. Not sure who follows
> > > > the stable list either. Quentin sent the patch, but is not the author.
> > > > Given the patch in question is about consistency between EFI memory
> > > > map boot and DT memory map boot, copying EFI knowledgeable folks would
> > > > help (Ard B for starters).
> > >
> > > Ok thanks for the tips. I add Ard in the loop.
> >
> > Sigh. If it was only Ard I was suggesting I would have done that
> > myself. Now everyone on the patch in question and relevant lists are
> > Cc'ed.
> >
>
> Thanks for the cc.
>
> > >
> > > Ard, let me know if other people have to be directly added or if I have
> > > to resend to another mailing list.
> > >
> > > thanks
> > > alex
> > >
> > > >
> > > >>
> > > >> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> > > >> reserved-memory regions are no more "reserved" and make part of the
> > > >> kernel System RAM. This causes allocation failure for devices which try
> > > >> to take a reserved-memory region.
> > > >>
> > > >> It has been introduced by the following path:
> > > >>
> > > >> "fdt: Properly handle "no-map" field in the memory region
> > > >> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> > > >> which replace memblock_remove by memblock_mark_nomap in no-map case.
> > > >>
>
> Why was this backported? It doesn't look like a bugfix to me.

Probably because of commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map
does not remove already reserved regions") which was in the same
series.

'Properly handle' implies before it was 'improperly handled', so
sounds like a fix.

Rob


From Vineet.Gupta1 at synopsys.com  Tue Apr 20 22:14:12 2021
From: Vineet.Gupta1 at synopsys.com (Vineet Gupta)
Date: Tue, 20 Apr 2021 21:14:12 +0000
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
 <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
Message-ID: <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>

On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> On Tue, Apr 20, 2021 at 5:10 AM Matthew Wilcox <willy at infradead.org> wrote:
>> On Tue, Apr 20, 2021 at 02:48:17AM +0000, Vineet Gupta wrote:
>>>> 32-bit architectures which expect 8-byte alignment for 8-byte integers
>>>> and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
>>>> page inadvertently expanded in 2019.
>>> FWIW, ARC doesn't require 8 byte alignment for 8 byte integers. This is
>>> only needed for 8-byte atomics due to the requirements of LLOCKD/SCOND
>>> instructions.
>> Ah, like x86?  OK, great, I'll drop your arch from the list of
>> affected.  Thanks!
> I mistakenly assumed that i386 and m68k were the only supported
> architectures with 32-bit alignment on u64. I checked it now and found
>
> $ for i in /home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/*-gcc ; do
> echo `echo 'int a = __alignof__(long long);' | $i -xc - -Wall -S -o- |
> grep -A1 a: | tail -n 1 | cut -f 3 -d\   `
> ${i#/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/*/bin/} ; done
> 8 aarch64-linux-gcc
> 8 alpha-linux-gcc
> 4 arc-linux-gcc
> 8 arm-linux-gnueabi-gcc
> 8 c6x-elf-gcc
> 4 csky-linux-gcc
> 4 h8300-linux-gcc
> 8 hppa-linux-gcc
> 8 hppa64-linux-gcc
> 8 i386-linux-gcc
> 8 ia64-linux-gcc
> 2 m68k-linux-gcc
> 4 microblaze-linux-gcc
> 8 mips-linux-gcc
> 8 mips64-linux-gcc
> 8 nds32le-linux-gcc
> 4 nios2-linux-gcc
> 4 or1k-linux-gcc
> 8 powerpc-linux-gcc
> 8 powerpc64-linux-gcc
> 8 riscv32-linux-gcc
> 8 riscv64-linux-gcc
> 8 s390-linux-gcc
> 4 sh2-linux-gcc
> 4 sh4-linux-gcc
> 8 sparc-linux-gcc
> 8 sparc64-linux-gcc
> 8 x86_64-linux-gcc
> 8 xtensa-linux-gcc
>
> which means that half the 32-bit architectures do this. This may
> cause more problems when arc and/or microblaze want to support
> 64-bit kernels and compat mode in the future on their latest hardware,
> as that means duplicating the x86 specific hacks we have for compat.
>
> What is alignof(u64) on 64-bit arc?

$ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc - 
-Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
8

Yeah ARCv2 alignment of 4 for 64-bit data was a bit of surprise finding 
for me as well. When 64-bit load/stores were initially targeted by the 
internal Metaware compiler (llvm based) they decided to keep alignment 
to 4 still (granted hardware allowed this) and then gcc guys decided to 
follow the same ABI. I only found this by accident :-)

Can you point me to some specifics on the compat issue. For better of 
worse, arc64 does''t have a compat 32-bit mode, so everything is 
64-on-64 or 32-on-32 (ARC32 flavor of ARCv3)

Thx,
-Vineet

From arnd at kernel.org  Tue Apr 20 22:20:19 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 20 Apr 2021 23:20:19 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
 <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
 <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>
Message-ID: <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>

On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta
<Vineet.Gupta1 at synopsys.com> wrote:
> On 4/20/21 12:07 AM, Arnd Bergmann wrote:

> >
> > which means that half the 32-bit architectures do this. This may
> > cause more problems when arc and/or microblaze want to support
> > 64-bit kernels and compat mode in the future on their latest hardware,
> > as that means duplicating the x86 specific hacks we have for compat.
> >
> > What is alignof(u64) on 64-bit arc?
>
> $ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc -
> -Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
> 8

Ok, good.

> Yeah ARCv2 alignment of 4 for 64-bit data was a bit of surprise finding
> for me as well. When 64-bit load/stores were initially targeted by the
> internal Metaware compiler (llvm based) they decided to keep alignment
> to 4 still (granted hardware allowed this) and then gcc guys decided to
> follow the same ABI. I only found this by accident :-)
>
> Can you point me to some specifics on the compat issue. For better of
> worse, arc64 does''t have a compat 32-bit mode, so everything is
> 64-on-64 or 32-on-32 (ARC32 flavor of ARCv3)

In that case, there should be no problem for you.

The main issue is with system calls and ioctls that contain a misaligned
struct member like

struct s {
       u32 a;
       u64 b;
};

Passing this structure by reference from a 32-bit user space application
to a 64-bit kernel with different alignment constraints means that the
kernel has to convert the structure layout. See
compat_ioctl_preallocate() in fs/ioctl.c for one such example.

       Arnd


From daniel.lezcano at linaro.org  Tue Apr 20 22:22:40 2021
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 20 Apr 2021 23:22:40 +0200
Subject: [v3,1/3] thermal: mediatek: Relocate driver to mediatek folder
In-Reply-To: <20210312034018.17437-2-michael.kao@mediatek.com>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-2-michael.kao@mediatek.com>
Message-ID: <836581c1-0738-8e42-b168-b54d0bd078a5@linaro.org>

On 12/03/2021 04:40, Michael Kao wrote:
> Add Mediatek proprietary folder to upstream more thermal zone and cooler
> drivers. Relocate the original thermal controller driver to it and rename
> as soc_temp.c to show its purpose more clearly.

We already know the purpose :)

soc_temp gives no additional information.

Either keep the name or give the hardware sensor name. It is a driver
directory.

> Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> ---
>  drivers/thermal/Kconfig                       | 14 ++++-------
>  drivers/thermal/Makefile                      |  2 +-
>  drivers/thermal/mediatek/Kconfig              | 23 +++++++++++++++++++
>  drivers/thermal/mediatek/Makefile             |  1 +
>  .../{mtk_thermal.c => mediatek/soc_temp.c}    |  0

[ ... ]

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv


> +config MTK_THERMAL
> +	tristate "Mediatek thermal drivers"
> +	depends on THERMAL_OF
> +	help
> +	  This is the option for Mediatek thermal software
> +	  solutions. Please enable corresponding options to
> +	  get temperature information from thermal sensors or
> +	  turn on throttle mechaisms for thermal mitigation.
> +
> +if MTK_THERMAL


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

All the above not needed.

> +config MTK_SOC_THERMAL
> +	tristate "Temperature sensor driver for mediatek SoCs"
> +	depends on HAS_IOMEM
> +	depends on NVMEM
> +	depends on RESET_CONTROLLER
> +	help
> +	  Enable this option if you want to get SoC temperature
> +	  information for Mediatek platforms. This driver
> +	  configures thermal controllers to collect temperature
> +	  via AUXADC interface.
> +
> +endif
> diff --git a/drivers/thermal/mediatek/Makefile b/drivers/thermal/mediatek/Makefile
> new file mode 100644
> index 000000000000..f75313ddce5e
> --- /dev/null
> +++ b/drivers/thermal/mediatek/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_MTK_SOC_THERMAL)	+= soc_temp.o
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mediatek/soc_temp.c
> similarity index 100%
> rename from drivers/thermal/mtk_thermal.c
> rename to drivers/thermal/mediatek/soc_temp.c



-- 
<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 dann.frazier at canonical.com  Tue Apr 20 22:25:51 2021
From: dann.frazier at canonical.com (dann frazier)
Date: Tue, 20 Apr 2021 15:25:51 -0600
Subject: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts
In-Reply-To: <YH87dtTfwYgavusz@xps13.dannf>
References: <20200519161755.209565-1-maz@kernel.org>
 <20200519161755.209565-9-maz@kernel.org>
 <YH87dtTfwYgavusz@xps13.dannf>
Message-ID: <YH9G3+aDUWpcLCpD@xps13.dannf>

On Tue, Apr 20, 2021 at 02:37:10PM -0600, dann frazier wrote:
> On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> > Change the way we deal with GIC SGIs by turning them into proper
> > IRQs, and calling into the arch code to register the interrupt range
> > instead of a callback.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> 
> hey Marc,
> 
>   I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
> CN88XX) down to this commit, but only when running in ACPI mode. See below:
> 
> 
> EFI stub: Booting Linux Kernel...
> EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
> [    0.000000] Linux version 5.11.0-13-generic (buildd at bos02-arm64-067) (gcc (Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 5.11.0-13.14-generic 5.11.7)

Sorry, realized I posted a log from an Ubuntu kernel. Here's an
upstream one:

EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
[    0.000000] Linux version 5.12.0-rc8 (ubuntu at seidel) (gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #19 SMP Tue Apr 20 21:09:04 UTC 2021
[    0.000000] Machine model: Cavium ThunderX CN88XX board
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb0000 ACPI 2.0=0xffec60000 MEMRESERVE=0xffc889d98 
[    0.000000] esrt: Reserving ESRT space from 0x0000000ffce0ff18 to 0x0000000ffce0ff50.
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x0000000FFEC60000 000024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 0x0000000FFEC60028 00008C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x0000000FFEC600B8 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x0000000FFEC601D0 00220B (v02 CAVIUM THUNDERX 00000001 INTL 20130517)
[    0.000000] ACPI: SPMI 0x0000000FFEC623E0 000041 (v05 ALASKA A M I    00000000 AMI. 00000000)
[    0.000000] ACPI: FIDT 0x0000000FFEC62428 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: APIC 0x0000000FFEC624C8 000F68 (v03 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: DBG2 0x0000000FFEC63430 000067 (v01 CAVIUM CN88XDBG 00000000 INTL 20150619)
[    0.000000] ACPI: GTDT 0x0000000FFEC63498 0000E0 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: IORT 0x0000000FFEC63578 0013D4 (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: MCFG 0x0000000FFEC64950 00006C (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SSDT 0x0000000FFEC649C0 00089C (v02 CAVIUM NETWORK  00000001 INTL 20150619)
[    0.000000] ACPI: OEM1 0x0000000FFEC65260 0001E8 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SLIT 0x0000000FFEC65448 000030 (v01 CAVIUM TEMPLATE 00000001 INTL 20150619)
[    0.000000] ACPI: SPCR 0x0000000FFEC65478 000050 (v02 A M I  APTIO V  01072009 AMI. 0005000B)
[    0.000000] ACPI: BGRT 0x0000000FFEC654C8 000038 (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: SPCR: console: pl011,mmio32,0x87e024000000,115200
[    0.000000] efi_bgrt: Ignoring BGRT: Incorrect BMP magic number 0x3707 (expected 0x4d42)
[    0.000000] NUMA: Failed to initialise from firmware
[    0.000000] NUMA: Faking a node at [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000] NUMA: NODE_DATA [mem 0xff677c480-0xff6780fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000500000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x0000000fff0fffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000500000-0x0000000000dfffff]
[    0.000000]   node   0: [mem 0x0000000000e00000-0x000000000fffffff]
[    0.000000]   node   0: [mem 0x0000000010000000-0x00000000102fffff]
[    0.000000]   node   0: [mem 0x0000000010300000-0x00000000fff9ffff]
[    0.000000]   node   0: [mem 0x00000000fffa0000-0x00000000ffffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x0000000fee6affff]
[    0.000000]   node   0: [mem 0x0000000fee6b0000-0x0000000fee6cffff]
[    0.000000]   node   0: [mem 0x0000000fee6d0000-0x0000000ffac2ffff]
[    0.000000]   node   0: [mem 0x0000000ffac30000-0x0000000ffb0affff]
[    0.000000]   node   0: [mem 0x0000000ffb0b0000-0x0000000ffc8bffff]
[    0.000000]   node   0: [mem 0x0000000ffc8c0000-0x0000000ffc91ffff]
[    0.000000]   node   0: [mem 0x0000000ffc920000-0x0000000ffca3ffff]
[    0.000000]   node   0: [mem 0x0000000ffca40000-0x0000000ffca4ffff]
[    0.000000]   node   0: [mem 0x0000000ffca50000-0x0000000ffcdbffff]
[    0.000000]   node   0: [mem 0x0000000ffcdc0000-0x0000000ffd12ffff]
[    0.000000]   node   0: [mem 0x0000000ffd130000-0x0000000ffec2ffff]
[    0.000000]   node   0: [mem 0x0000000ffec30000-0x0000000ffec5ffff]
[    0.000000]   node   0: [mem 0x0000000ffec60000-0x0000000ffec6ffff]
[    0.000000]   node   0: [mem 0x0000000ffec70000-0x0000000ffed1ffff]
[    0.000000]   node   0: [mem 0x0000000ffed20000-0x0000000fff0fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000]   Normal zone: 256 pages in unavailable ranges
[    0.000000] cma: Reserved 32 MiB at 0x00000000fdc00000
[    0.000000] psci: probing for conduit method from ACPI.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS resident on physical CPU 0x0
[    0.000000] ACPI: SRAT not present
[    0.000000] percpu: Embedded 33 pages/cpu s98072 r8192 d28904 u135168
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: Software prefetching using PRFM
[    0.000000] CPU features: detected: Cavium erratum 27456
[    0.000000] CPU features: detected: Cavium erratum 30115
[    0.000000] CPU features: kernel page table isolation forced OFF by ARM64_WORKAROUND_CAVIUM_27456
[    0.000000] CPU features: detected: Spectre-v2
[    0.000000] CPU features: detected: Spectre-v4
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16510032
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-dannf root=UUID=76e81d96-78e4-4432-a490-bb852f6111e8 ro sysrq_always_enabled acpi=force
[    0.000000] sysrq: sysrq always enabled.
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 192512 bytes
[    0.000000] printk: log_buf_len min size: 262144 bytes
[    0.000000] printk: log_buf_len: 524288 bytes
[    0.000000] printk: early log buf free: 255872(97%)
[    0.000000] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
[    0.000000] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x00000000f9c00000-0x00000000fdc00000] (64MB)
[    0.000000] Memory: 65572072K/67088384K available (15616K kernel code, 3626K rwdata, 11808K rodata, 7616K init, 1157K bss, 1483544K reserved, 32768K cma-reserved)
[    0.000000] random: get_random_u64 called from __kmem_cache_create+0x38/0x5b4 with crng_init=0
[    0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=48, Nodes=1
[    0.000000] ftrace: allocating 49728 entries in 195 pages
[    0.000000] ftrace: allocated 195 pages with 4 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=48.
[    0.000000]  Rude variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=48
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GIC: enabling workaround for GICv3: Cavium erratum 38539
[    0.000000] GICv3: 128 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000801080000000
[    0.000000] ACPI: SRAT not present
[    0.000000] ITS [mem 0x801000020000-0x80100003ffff]
[    0.000000] ITS at 0x0000801000020000: Devices Table too large, reduce ids 21->19
[    0.000000] ITS at 0x0000801000020000: allocated 524288 Devices @100800000 (flat, esz 8, psz 64K, shr 1)
[    0.000000] GICv3: using LPI property table @0x0000000100270000
[    0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000100280000
[    0.000000] arch_timer: Failed to initialize memory-mapped timer.
[    0.000000] arch_timer: cp15 timer(s) running at 100.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000000] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps every 4398046511100ns
[    0.000149] Console: colour dummy device 80x25
[    0.000230] ACPI: Core revision 20210105
[    0.000451] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.000462] pid_max: default: 49152 minimum: 384
[    0.000575] LSM: Security Framework initializing
[    0.000590] Yama: becoming mindful.
[    0.000648] AppArmor: AppArmor initialized
[    0.000801] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000866] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.001656] ACPI PPTT: No PPTT table found, CPU and cache topology may be inaccurate
[    0.002242] rcu: Hierarchical SRCU implementation.
[    0.002993] Platform MSI: ITS at 0x801000020000 domain created
[    0.003007] PCI/MSI: ITS at 0x801000020000 domain created
[    0.003019] fsl-mc MSI: ITS at 0x801000020000 domain created
[    0.003036] Remapping and enabling EFI services.
[    0.005145] smp: Bringing up secondary CPUs ...
[    0.005629] Detected VIPT I-cache on CPU1
[    0.005644] GICv3: CPU1: found redistributor 1 region 0:0x0000801080020000
[    0.005669] GICv3: CPU1: using allocated LPI pending table @0x0000000100290000
[    0.005690] CPU1: Booted secondary processor 0x0000000001 [0x431f0a11]
[    0.006245] Detected VIPT I-cache on CPU2
[    0.006255] GICv3: CPU2: found redistributor 2 region 0:0x0000801080040000
[    0.006279] GICv3: CPU2: using allocated LPI pending table @0x00000001002a0000
[    0.006298] CPU2: Booted secondary processor 0x0000000002 [0x431f0a11]
[    0.006840] Detected VIPT I-cache on CPU3
[    0.006851] GICv3: CPU3: found redistributor 3 region 0:0x0000801080060000
[    0.006876] GICv3: CPU3: using allocated LPI pending table @0x00000001002b0000
[    0.006896] CPU3: Booted secondary processor 0x0000000003 [0x431f0a11]
[    0.007435] Detected VIPT I-cache on CPU4
[    0.007446] GICv3: CPU4: found redistributor 4 region 0:0x0000801080080000
[    0.007470] GICv3: CPU4: using allocated LPI pending table @0x00000001002c0000
[    0.007490] CPU4: Booted secondary processor 0x0000000004 [0x431f0a11]
[    0.008034] Detected VIPT I-cache on CPU5
[    0.008045] GICv3: CPU5: found redistributor 5 region 0:0x00008010800a0000
[    0.008069] GICv3: CPU5: using allocated LPI pending table @0x00000001002d0000
[    0.008089] CPU5: Booted secondary processor 0x0000000005 [0x431f0a11]
[    0.008626] Detected VIPT I-cache on CPU6
[    0.008637] GICv3: CPU6: found redistributor 6 region 0:0x00008010800c0000
[    0.008664] GICv3: CPU6: using allocated LPI pending table @0x00000001002e0000
[    0.008685] CPU6: Booted secondary processor 0x0000000006 [0x431f0a11]
[    0.009228] Detected VIPT I-cache on CPU7
[    0.009239] GICv3: CPU7: found redistributor 7 region 0:0x00008010800e0000
[    0.009265] GICv3: CPU7: using allocated LPI pending table @0x00000001002f0000
[    0.009286] CPU7: Booted secondary processor 0x0000000007 [0x431f0a11]
[    0.009825] Detected VIPT I-cache on CPU8
[    0.009837] GICv3: CPU8: found redistributor 8 region 0:0x0000801080100000
[    0.009862] GICv3: CPU8: using allocated LPI pending table @0x0000000100300000
[    0.009883] CPU8: Booted secondary processor 0x0000000008 [0x431f0a11]
[    0.010436] Detected VIPT I-cache on CPU9
[    0.010447] GICv3: CPU9: found redistributor 9 region 0:0x0000801080120000
[    0.010473] GICv3: CPU9: using allocated LPI pending table @0x0000000100310000
[    0.010494] CPU9: Booted secondary processor 0x0000000009 [0x431f0a11]
[    0.011040] Detected VIPT I-cache on CPU10
[    0.011052] GICv3: CPU10: found redistributor a region 0:0x0000801080140000
[    0.011078] GICv3: CPU10: using allocated LPI pending table @0x0000000100320000
[    0.011099] CPU10: Booted secondary processor 0x000000000a [0x431f0a11]
[    0.011647] Detected VIPT I-cache on CPU11
[    0.011659] GICv3: CPU11: found redistributor b region 0:0x0000801080160000
[    0.011686] GICv3: CPU11: using allocated LPI pending table @0x0000000100330000
[    0.011707] CPU11: Booted secondary processor 0x000000000b [0x431f0a11]
[    0.012266] Detected VIPT I-cache on CPU12
[    0.012278] GICv3: CPU12: found redistributor c region 0:0x0000801080180000
[    0.012304] GICv3: CPU12: using allocated LPI pending table @0x0000000100340000
[    0.012326] CPU12: Booted secondary processor 0x000000000c [0x431f0a11]
[    0.012889] Detected VIPT I-cache on CPU13
[    0.012901] GICv3: CPU13: found redistributor d region 0:0x00008010801a0000
[    0.012928] GICv3: CPU13: using allocated LPI pending table @0x0000000100350000
[    0.012950] CPU13: Booted secondary processor 0x000000000d [0x431f0a11]
[    0.013498] Detected VIPT I-cache on CPU14
[    0.013511] GICv3: CPU14: found redistributor e region 0:0x00008010801c0000
[    0.013537] GICv3: CPU14: using allocated LPI pending table @0x0000000100360000
[    0.013560] CPU14: Booted secondary processor 0x000000000e [0x431f0a11]
[    0.014110] Detected VIPT I-cache on CPU15
[    0.014124] GICv3: CPU15: found redistributor f region 0:0x00008010801e0000
[    0.014152] GICv3: CPU15: using allocated LPI pending table @0x0000000100370000
[    0.014175] CPU15: Booted secondary processor 0x000000000f [0x431f0a11]
[    0.014719] Detected VIPT I-cache on CPU16
[    0.014732] GICv3: CPU16: found redistributor 100 region 0:0x0000801080200000
[    0.014759] GICv3: CPU16: using allocated LPI pending table @0x0000000100380000
[    0.014782] CPU16: Booted secondary processor 0x0000000100 [0x431f0a11]
[    0.015323] Detected VIPT I-cache on CPU17
[    0.015337] GICv3: CPU17: found redistributor 101 region 0:0x0000801080220000
[    0.015363] GICv3: CPU17: using allocated LPI pending table @0x0000000100390000
[    0.015386] CPU17: Booted secondary processor 0x0000000101 [0x431f0a11]
[    0.015955] Detected VIPT I-cache on CPU18
[    0.015969] GICv3: CPU18: found redistributor 102 region 0:0x0000801080240000
[    0.015996] GICv3: CPU18: using allocated LPI pending table @0x00000001003a0000
[    0.016019] CPU18: Booted secondary processor 0x0000000102 [0x431f0a11]
[    0.016582] Detected VIPT I-cache on CPU19
[    0.016595] GICv3: CPU19: found redistributor 103 region 0:0x0000801080260000
[    0.016623] GICv3: CPU19: using allocated LPI pending table @0x00000001003b0000
[    0.016647] CPU19: Booted secondary processor 0x0000000103 [0x431f0a11]
[   0.017266] CPU20: Booted secondary processor 0x0000000104 [0x431f0a11]
[    0.017811] Detected VIPT I-cache on CPU21
[    0.017826] GICv3: CPU21: found redistributor 105 region 0:0x00008010802a0000
[    0.017853] GICv3: CPU21: using allocated LPI pending table @0x00000001003d0000
[    0.017877] CPU21: Booted secondary processor 0x0000000105 [0x431f0a11]
[    0.018439] Detected VIPT I-cache on CPU22
[    0.018453] GICv3: CPU22: found redistributor 106 region 0:0x00008010802c0000
[    0.018481] GICv3: CPU22: using allocated LPI pending table @0x00000001003e0000
[    0.018505] CPU22: Booted secondary processor 0x0000000106 [0x431f0a11]
[    0.019068] Detected VIPT I-cache on CPU23
[    0.019083] GICv3: CPU23: found redistributor 107 region 0:0x00008010802e0000
[    0.019111] GICv3: CPU23: using allocated LPI pending table @0x00000001003f0000
[    0.019135] CPU23: Booted secondary processor 0x0000000107 [0x431f0a11]
[    0.019684] Detected VIPT I-cache on CPU24
[    0.019698] GICv3: CPU24: found redistributor 108 region 0:0x0000801080300000
[    0.019726] GICv3: CPU24: using allocated LPI pending table @0x0000000100c00000
[    0.019751] CPU24: Booted secondary processor 0x0000000108 [0x431f0a11]
[    0.020328] Detected VIPT I-cache on CPU25
[    0.020343] GICv3: CPU25: found redistributor 109 region 0:0x0000801080320000
[    0.020372] GICv3: CPU25: using allocated LPI pending table @0x0000000100c10000
[    0.020396] CPU25: Booted secondary processor 0x0000000109 [0x431f0a11]
[    0.020948] Detected VIPT I-cache on CPU26
[    0.020963] GICv3: CPU26: found redistributor 10a region 0:0x0000801080340000
[    0.020992] GICv3: CPU26: using allocated LPI pending table @0x0000000100c20000
[    0.021017] CPU26: Booted secondary processor 0x000000010a [0x431f0a11]
[    0.021585] Detected VIPT I-cache on CPU27
[    0.021601] GICv3: CPU27: found redistributor 10b region 0:0x0000801080360000
[    0.021629] GICv3: CPU27: using allocated LPI pending table @0x0000000100c30000
[    0.021655] CPU27: Booted secondary processor 0x000000010b [0x431f0a11]
[    0.022205] Detected VIPT I-cache on CPU28
[    0.022220] GICv3: CPU28: found redistributor 10c region 0:0x0000801080380000
[    0.022248] GICv3: CPU28: using allocated LPI pending table @0x0000000100c40000
[    0.022274] CPU28: Booted secondary processor 0x000000010c [0x431f0a11]
[    0.022835] Detected VIPT I-cache on CPU29
[    0.022851] GICv3: CPU29: found redistributor 10d region 0:0x00008010803a0000
[    0.022880] GICv3: CPU29: using allocated LPI pending table @0x0000000100c50000
[    0.022906] CPU29: Booted secondary processor 0x000000010d [0x431f0a11]
[    0.023469] Detected VIPT I-cache on CPU30
[    0.023484] GICv3: CPU30: found redistributor 10e region 0:0x00008010803c0000
[    0.023513] GICv3: CPU30: using allocated LPI pending table @0x0000000100c60000
[    0.023539] CPU30: Booted secondary processor 0x000000010e [0x431f0a11]
[    0.024102] Detected VIPT I-cache on CPU31
[    0.024118] GICv3: CPU31: found redistributor 10f region 0:0x00008010803e0000
[    0.024147] GICv3: CPU31: using allocated LPI pending table @0x0000000100c70000
[    0.024174] CPU31: Booted secondary processor 0x000000010f [0x431f0a11]
[    0.024748] Detected VIPT I-cache on CPU32
[    0.024764] GICv3: CPU32: found redistributor 200 region 0:0x0000801080400000
[    0.024793] GICv3: CPU32: using allocated LPI pending table @0x0000000100c80000
[    0.024820] CPU32: Booted secondary processor 0x0000000200 [0x431f0a11]
[    0.025388] Detected VIPT I-cache on CPU33
[    0.025405] GICv3: CPU33: found redistributor 201 region 0:0x0000801080420000
[    0.025434] GICv3: CPU33: using allocated LPI pending table @0x0000000100c90000
[    0.025461] CPU33: Booted secondary processor 0x0000000201 [0x431f0a11]
[    0.026028] Detected VIPT I-cache on CPU34
[    0.026044] GICv3: CPU34: found redistributor 202 region 0:0x0000801080440000
[    0.026074] GICv3: CPU34: using allocated LPI pending table @0x0000000100ca0000
[    0.026101] CPU34: Booted secondary processor 0x0000000202 [0x431f0a11]
[    0.026670] Detected VIPT I-cache on CPU35
[    0.026687] GICv3: CPU35: found redistributor 203 region 0:0x0000801080460000
[    0.026716] GICv3: CPU35: using allocated LPI pending table @0x0000000100cb0000
[    0.026744] CPU35: Booted secondary processor 0x0000000203 [0x431f0a11]
[    0.027305] Detected VIPT I-cache on CPU36
[    0.027322] GICv3: CPU36: found redistributor 204 region 0:0x0000801080480000
[    0.027352] GICv3: CPU36: using allocated LPI pending table @0x0000000100cc0000
[    0.027380] CPU36: Booted secondary processor 0x0000000204 [0x431f0a11]
[    0.027942] Detected VIPT I-cache on CPU37
[    0.027959] GICv3: CPU37: found redistributor 205 region 0:0x00008010804a0000
[    0.027989] GICv3: CPU37: using allocated LPI pending table @0x0000000100cd0000
[    0.028018] CPU37: Booted secondary processor 0x0000000205 [0x431f0a11]
[    0.028597] Detected VIPT I-cache on CPU38
[    0.028614] GICv3: CPU38: found redistributor 206 region 0:0x00008010804c0000
[    0.028644] GICv3: CPU38: using allocated LPI pending table @0x0000000100ce0000
[    0.028672] CPU38: Booted secondary processor 0x0000000206 [0x431f0a11]
[    0.029233] Detected VIPT I-cache on CPU39
[    0.029251] GICv3: CPU39: found redistributor 207 region 0:0x00008010804e0000
[    0.029282] GICv3: CPU39: using allocated LPI pending table @0x0000000100cf0000
[    0.029310] CPU39: Booted secondary processor 0x0000000207 [0x431f0a11]
[    0.029885] Detected VIPT I-cache on CPU40
[    0.029902] GICv3: CPU40: found redistributor 208 region 0:0x0000801080500000
[    0.029932] GICv3: CPU40: using allocated LPI pending table @0x0000000100d00000
[    0.029961] CPU40: Booted secondary processor 0x0000000208 [0x431f0a11]
[    0.030544] Detected VIPT I-cache on CPU41
[    0.030562] GICv3: CPU41: found redistributor 209 region 0:0x0000801080520000
[    0.030592] GICv3: CPU41: using allocated LPI pending table @0x0000000100d10000
[    0.030622] CPU41: Booted secondary processor 0x0000000209 [0x431f0a11]
[    0.031188] Detected VIPT I-cache on CPU42
[    0.031205] GICv3: CPU42: found redistributor 20a region 0:0x0000801080540000
[    0.031236] GICv3: CPU42: using allocated LPI pending table @0x0000000100d20000
[    0.031266] CPU42: Booted secondary processor 0x000000020a [0x431f0a11]
[    0.031845] Detected VIPT I-cache on CPU43
[    0.031863] GICv3: CPU43: found redistributor 20b region 0:0x0000801080560000
[    0.031896] GICv3: CPU43: using allocated LPI pending table @0x0000000100d30000
[    0.031925] CPU43: Booted secondary processor 0x000000020b [0x431f0a11]
[    0.032520] Detected VIPT I-cache on CPU44
[    0.032538] GICv3: CPU44: found redistributor 20c region 0:0x0000801080580000
[    0.032569] GICv3: CPU44: using allocated LPI pending table @0x0000000100d40000
[    0.032599] CPU44: Booted secondary processor 0x000000020c [0x431f0a11]
[    0.033181] Detected VIPT I-cache on CPU45
[    0.033200] GICv3: CPU45: found redistributor 20d region 0:0x00008010805a0000
[    0.033231] GICv3: CPU45: using allocated LPI pending table @0x0000000100d50000
[    0.033261] CPU45: Booted secondary processor 0x000000020d [0x431f0a11]
[    0.033833] Detected VIPT I-cache on CPU46
[    0.033852] GICv3: CPU46: found redistributor 20e region 0:0x00008010805c0000
[    0.033883] GICv3: CPU46: using allocated LPI pending table @0x0000000100d60000
[    0.033913] CPU46: Booted secondary processor 0x000000020e [0x431f0a11]
[    0.035252] Detected VIPT I-cache on CPU47
[    0.035271] GICv3: CPU47: found redistributor 20f region 0:0x00008010805e0000
[    0.035303] GICv3: CPU47: using allocated LPI pending table @0x0000000100d70000
[    0.035334] CPU47: Booted secondary processor 0x000000020f [0x431f0a11]
[    0.035443] smp: Brought up 1 node, 48 CPUs
[    0.035708] SMP: Total of 48 processors activated.
[    0.035715] CPU features: detected: Data cache clean to the PoU not required for I/D coherence
[    0.035720] CPU features: detected: CRC32 instructions
[    0.035948] CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
[    0.044445] CPU: All CPU(s) started at EL2
[    0.044603] alternatives: patching kernel code
[    0.058479] devtmpfs: initialized
[    0.078107] Registered cp15_barrier emulation handler
[    0.078132] Registered setend emulation handler
[    0.078139] KASLR disabled due to lack of seed
[    0.078309] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.078378] futex hash table entries: 16384 (order: 8, 1048576 bytes, linear)
[    0.079795] pinctrl core: initialized pinctrl subsystem
[    0.080358] SMBIOS 3.0.0 present.
[    0.080372] DMI: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    0.080861] NET: Registered protocol family 16
[    0.082637] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations
[    0.083107] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.083586] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.083620] audit: initializing netlink subsys (disabled)
[    0.083779] audit: type=2000 audit(0.080:1): state=initialized audit_enabled=0 res=1
[    0.084319] thermal_sys: Registered thermal governor 'fair_share'
[    0.084325] thermal_sys: Registered thermal governor 'bang_bang'
[    0.084330] thermal_sys: Registered thermal governor 'step_wise'
[    0.084335] thermal_sys: Registered thermal governor 'user_space'
[    0.084339] thermal_sys: Registered thermal governor 'power_allocator'
[    0.084521] cpuidle: using governor ladder
[    0.084784] cpuidle: using governor menu
[    0.084931] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.085512] ASID allocator initialised with 65536 entries
[    0.085808] ACPI: bus type PCI registered
[    0.085815] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.086052] Serial: AMBA PL011 UART driver
[    0.096807] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.096815] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.096821] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.096826] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.101895] ACPI: Added _OSI(Module Device)
[    0.101903] ACPI: Added _OSI(Processor Device)
[    0.101907] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.101912] ACPI: Added _OSI(Processor Aggregator Device)
[    0.101917] ACPI: Added _OSI(Linux-Dell-Video)
[    0.101923] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.101928] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.105849] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.107742] ACPI: Interpreter enabled
[    0.107749] ACPI: Using GIC for interrupt routing
[    0.107778] ACPI: MCFG table detected, 4 entries
[    0.131437] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-1f])
[    0.131454] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    0.131603] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    0.131732] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability]
[    0.132192] acpi PNP0A08:00: ECAM area [mem 0x848000000000-0x848001ffffff] reserved by CAVA02C:00
[    0.132210] acpi PNP0A08:00: ECAM at [mem 0x848000000000-0x848001ffffff] for [bus 00-1f]
[    0.132366] PCI host bridge to bus 0000:00
[    0.132374] pci_bus 0000:00: root bus resource [mem 0x801000000000-0x807fffffffff window]
[    0.132381] pci_bus 0000:00: root bus resource [mem 0x838000000000-0x841fffffffff window]
[    0.132388] pci_bus 0000:00: root bus resource [mem 0x846000000000-0x847fffffffff window]
[    0.132394] pci_bus 0000:00: root bus resource [mem 0x868000000000-0x87e023ffffff window]
[    0.132400] pci_bus 0000:00: root bus resource [mem 0x87e026000000-0x87e0bfffffff window]
[    0.132407] pci_bus 0000:00: root bus resource [mem 0x87e0c6000000-0x87ffffffffff window]
[    0.132414] pci_bus 0000:00: root bus resource [bus 00-1f]
[    0.132444] pci 0000:00:01.0: [177d:a002] type 01 class 0x060400
[    0.132615] pci 0000:00:09.0: [177d:a018] type 00 class 0x120000
[    0.132651] pci 0000:00:09.0: BAR 0: [mem 0x87e040000000-0x87e0400fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    0.132660] pci 0000:00:09.0: VF BAR 0: [mem 0x840000800000-0x8400008fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.153436] pci 0000:00:09.0: VF(n) BAR0 space: [mem 0x840000800000-0x8400008fffff 64bit] (contains BAR0 for 1 VFs)
[    1.153589] pci 0000:00:10.0: [177d:a01b] type 00 class 0x0c0330
[    1.153625] pci 0000:00:10.0: BAR 0: [mem 0x868000000000-0x8680001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153634] pci 0000:00:10.0: BAR 4: [mem 0x868000200000-0x8680002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153761] pci 0000:00:11.0: [177d:a01b] type 00 class 0x0c0330
[    1.153797] pci 0000:00:11.0: BAR 0: [mem 0x869000000000-0x8690001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153806] pci 0000:00:11.0: BAR 4: [mem 0x869000200000-0x8690002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153931] pci 0000:00:14.0: [177d:a002] type 01 class 0x060400
[    1.154132] pci 0000:01:00.0: [177d:a001] type 00 class 0x088000
[    1.154167] pci 0000:01:00.0: BAR 0: [mem 0x87e0fc000000-0x87e0fc0fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154177] pci 0000:01:00.0: BAR 4: [mem 0x87e0fcf00000-0x87e0fcffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154302] pci 0000:01:00.1: [177d:a00e] type 00 class 0x088000
[    1.154338] pci 0000:01:00.1: BAR 0: [mem 0x87e006000000-0x87e0067fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154347] pci 0000:01:00.1: BAR 4: [mem 0x87e006f00000-0x87e006ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154467] pci 0000:01:01.3: [177d:a02b] type 00 class 0x0c8000
[    1.154501] pci 0000:01:01.3: BAR 0: [mem 0x87e005000000-0x87e0057fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154619] pci 0000:01:01.4: [177d:a010] type 00 class 0x058000
[    1.154659] pci 0000:01:01.4: BAR 0: [mem 0x87e009000000-0x87e0097fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154668] pci 0000:01:01.4: BAR 4: [mem 0x87e009f00000-0x87e009ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154790] pci 0000:01:06.0: [177d:a02e] type 00 class 0x058000
[    1.154826] pci 0000:01:06.0: BAR 0: [mem 0x87e050000000-0x87e0507fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154836] pci 0000:01:06.0: BAR 4: [mem 0x87e050f00000-0x87e050ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154961] pci 0000:01:06.1: [177d:a02e] type 00 class 0x058000
[    1.154997] pci 0000:01:06.1: BAR 0: [mem 0x87e051000000-0x87e0517fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155006] pci 0000:01:06.1: BAR 4: [mem 0x87e051f00000-0x87e051ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155127] pci 0000:01:06.2: [177d:a02e] type 00 class 0x058000
[    1.155163] pci 0000:01:06.2: BAR 0: [mem 0x87e052000000-0x87e0527fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155172] pci 0000:01:06.2: BAR 4: [mem 0x87e052f00000-0x87e052ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155291] pci 0000:01:06.3: [177d:a02e] type 00 class 0x058000
[    1.155326] pci 0000:01:06.3: BAR 0: [mem 0x87e053000000-0x87e0537fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155335] pci 0000:01:06.3: BAR 4: [mem 0x87e053f00000-0x87e053ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155455] pci 0000:01:06.4: [177d:a02e] type 00 class 0x058000
[    1.155491] pci 0000:01:06.4: BAR 0: [mem 0x87e054000000-0x87e0547fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155500] pci 0000:01:06.4: BAR 4: [mem 0x87e054f00000-0x87e054ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155621] pci 0000:01:06.5: [177d:a02e] type 00 class 0x058000
[    1.155657] pci 0000:01:06.5: BAR 0: [mem 0x87e055000000-0x87e0557fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155666] pci 0000:01:06.5: BAR 4: [mem 0x87e055f00000-0x87e055ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155785] pci 0000:01:06.6: [177d:a02e] type 00 class 0x058000
[    1.155821] pci 0000:01:06.6: BAR 0: [mem 0x87e056000000-0x87e0567fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155830] pci 0000:01:06.6: BAR 4: [mem 0x87e056f00000-0x87e056ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155950] pci 0000:01:06.7: [177d:a02e] type 00 class 0x058000
[    1.155989] pci 0000:01:06.7: BAR 0: [mem 0x87e057000000-0x87e0577fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155998] pci 0000:01:06.7: BAR 4: [mem 0x87e057f00000-0x87e057ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156120] pci 0000:01:07.0: [177d:a02f] type 00 class 0x058000
[    1.156156] pci 0000:01:07.0: BAR 0: [mem 0x87e058000000-0x87e0587fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156165] pci 0000:01:07.0: BAR 4: [mem 0x87e058f00000-0x87e058ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156291] pci 0000:01:07.1: [177d:a02f] type 00 class 0x058000
[    1.156327] pci 0000:01:07.1: BAR 0: [mem 0x87e059000000-0x87e0597fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156336] pci 0000:01:07.1: BAR 4: [mem 0x87e059f00000-0x87e059ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156456] pci 0000:01:07.2: [177d:a02f] type 00 class 0x058000
[    1.156492] pci 0000:01:07.2: BAR 0: [mem 0x87e05a000000-0x87e05a7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156501] pci 0000:01:07.2: BAR 4: [mem 0x87e05af00000-0x87e05affffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156623] pci 0000:01:07.3: [177d:a02f] type 00 class 0x058000
[    1.156659] pci 0000:01:07.3: BAR 0: [mem 0x87e05b000000-0x87e05b7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156668] pci 0000:01:07.3: BAR 4: [mem 0x87e05bf00000-0x87e05bffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156787] pci 0000:01:07.4: [177d:a030] type 00 class 0x058000
[    1.156822] pci 0000:01:07.4: BAR 0: [mem 0x87e05c000000-0x87e05c7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156831] pci 0000:01:07.4: BAR 4: [mem 0x87e05cf00000-0x87e05cffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156951] pci 0000:01:07.5: [177d:a030] type 00 class 0x058000
[    1.156986] pci 0000:01:07.5: BAR 0: [mem 0x87e05d000000-0x87e05d7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156995] pci 0000:01:07.5: BAR 4: [mem 0x87e05df00000-0x87e05dffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157118] pci 0000:01:07.6: [177d:a030] type 00 class 0x058000
[    1.157153] pci 0000:01:07.6: BAR 0: [mem 0x87e05e000000-0x87e05e7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157162] pci 0000:01:07.6: BAR 4: [mem 0x87e05ef00000-0x87e05effffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157286] pci 0000:01:07.7: [177d:a030] type 00 class 0x058000
[    1.157334] pci 0000:01:07.7: BAR 0: [mem 0x87e05f000000-0x87e05f7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157343] pci 0000:01:07.7: BAR 4: [mem 0x87e05ff00000-0x87e05fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157476] pci 0000:01:09.2: [177d:a012] type 00 class 0x0c8000
[    1.157513] pci 0000:01:09.2: BAR 0: [mem 0x87e0d2000000-0x87e0d27fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157522] pci 0000:01:09.2: BAR 4: [mem 0x87e0d2f00000-0x87e0d2ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157649] pci 0000:01:09.4: [177d:a012] type 00 class 0x0c8000
[    1.157685] pci 0000:01:09.4: BAR 0: [mem 0x87e0d4000000-0x87e0d47fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157694] pci 0000:01:09.4: BAR 4: [mem 0x87e0d4f00000-0x87e0d4ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157815] pci 0000:01:0a.0: [177d:a022] type 00 class 0x058000
[    1.157851] pci 0000:01:0a.0: BAR 0: [mem 0x87e088000000-0x87e0887fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157860] pci 0000:01:0a.0: BAR 4: [mem 0x87e088f00000-0x87e088ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157983] pci 0000:01:0a.1: [177d:a022] type 00 class 0x058000
[    1.158018] pci 0000:01:0a.1: BAR 0: [mem 0x87e089000000-0x87e0897fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158027] pci 0000:01:0a.1: BAR 4: [mem 0x87e089f00000-0x87e089ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158150] pci 0000:01:10.0: [177d:a026] type 00 class 0x028000
[    1.158185] pci 0000:01:10.0: BAR 0: [mem 0x87e0e0000000-0x87e0e03fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158194] pci 0000:01:10.0: BAR 4: [mem 0x87e0e0400000-0x87e0e07fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158316] pci 0000:01:10.1: [177d:a026] type 00 class 0x028000
[    1.158351] pci 0000:01:10.1: BAR 0: [mem 0x87e0e1000000-0x87e0e13fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158360] pci 0000:01:10.1: BAR 4: [mem 0x87e0e1400000-0x87e0e17fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158471] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.158637] pci 0000:02:00.0: [177d:a01d] type 00 class 0x010400
[    1.158676] pci 0000:02:00.0: BAR 0: [mem 0x870000000000-0x8700007fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158685] pci 0000:02:00.0: BAR 4: [mem 0x870000f00000-0x870000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158800] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.158875] pci 0000:00:01.0: PCI bridge to [bus 01]
[    1.158889] pci 0000:00:14.0: PCI bridge to [bus 02]
[    1.158897] pci_bus 0000:00: resource 4 [mem 0x801000000000-0x807fffffffff window]
[    1.158903] pci_bus 0000:00: resource 5 [mem 0x838000000000-0x841fffffffff window]
[    1.158910] pci_bus 0000:00: resource 6 [mem 0x846000000000-0x847fffffffff window]
[    1.158916] pci_bus 0000:00: resource 7 [mem 0x868000000000-0x87e023ffffff window]
[    1.158922] pci_bus 0000:00: resource 8 [mem 0x87e026000000-0x87e0bfffffff window]
[    1.158929] pci_bus 0000:00: resource 9 [mem 0x87e0c6000000-0x87ffffffffff window]
[    1.159085] ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-1f])
[    1.159098] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.159240] acpi PNP0A08:01: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.159369] acpi PNP0A08:01: _OSC: OS now controls [PCIeCapability]
[    1.159842] acpi PNP0A08:01: ECAM area [mem 0x849000000000-0x849001ffffff] reserved by CAVA02C:01
[    1.159858] acpi PNP0A08:01: ECAM at [mem 0x849000000000-0x849001ffffff] for [bus 00-1f]
[    1.159988] PCI host bridge to bus 0001:00
[    1.159995] pci_bus 0001:00: root bus resource [mem 0x810000000000-0x817fffffffff window]
[    1.160003] pci_bus 0001:00: root bus resource [bus 00-1f]
[    1.160031] pci 0001:00:08.0: [177d:a01c] type 00 class 0x010601
[    1.160063] pci 0001:00:08.0: BAR 0: [mem 0x814000000000-0x8140001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160072] pci 0001:00:08.0: BAR 4: [mem 0x814000200000-0x8140002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160200] pci 0001:00:09.0: [177d:a01c] type 00 class 0x010601
[    1.160239] pci 0001:00:09.0: BAR 0: [mem 0x815000000000-0x8150001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160248] pci 0001:00:09.0: BAR 4: [mem 0x815000200000-0x8150002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160378] pci 0001:00:0a.0: [177d:a01c] type 00 class 0x010601
[    1.160413] pci 0001:00:0a.0: BAR 0: [mem 0x816000000000-0x8160001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160422] pci 0001:00:0a.0: BAR 4: [mem 0x816000200000-0x8160002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160548] pci 0001:00:0b.0: [177d:a01c] type 00 class 0x010601
[    1.160583] pci 0001:00:0b.0: BAR 0: [mem 0x817000000000-0x8170001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160592] pci 0001:00:0b.0: BAR 4: [mem 0x817000200000-0x8170002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160724] pci_bus 0001:00: resource 4 [mem 0x810000000000-0x817fffffffff window]
[    1.160832] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
[    1.160845] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.160985] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.161113] acpi PNP0A08:02: _OSC: OS now controls [PCIeCapability]
[    1.161617] acpi PNP0A08:02: ECAM area [mem 0x84a000000000-0x84a001ffffff] reserved by CAVA02C:02
[    1.161632] acpi PNP0A08:02: ECAM at [mem 0x84a000000000-0x84a001ffffff] for [bus 00-1f]
[    1.161765] PCI host bridge to bus 0002:00
[    1.161773] pci_bus 0002:00: root bus resource [mem 0x842000000000-0x843fffffffff window]
[    1.161780] pci_bus 0002:00: root bus resource [bus 00-1f]
[    1.161804] pci 0002:00:02.0: [177d:a002] type 01 class 0x060400
[    1.161952] pci 0002:00:03.0: [177d:a01f] type 00 class 0x028000
[    1.161986] pci 0002:00:03.0: BAR 0: [mem 0x842000000000-0x84200000ffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.161995] pci 0002:00:03.0: BAR 2: [mem 0x842040000000-0x84207fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162004] pci 0002:00:03.0: BAR 4: [mem 0x842000f00000-0x842000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162195] pci 0002:01:00.0: [177d:a01e] type 00 class 0x020000
[    1.162231] pci 0002:01:00.0: BAR 0: [mem 0x843000000000-0x84303fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162240] pci 0002:01:00.0: BAR 4: [mem 0x843060000000-0x8430600fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162249] pci 0002:01:00.0: VF BAR 0: [mem 0x8430a0000000-0x8430a01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.162257] pci 0002:01:00.0: VF BAR 4: [mem 0x8430e0000000-0x8430e01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    2.178767] pci 0002:01:00.0: VF(n) BAR0 space: [mem 0x8430a0000000-0x8430afffffff 64bit] (contains BAR0 for 128 VFs)
[    2.178782] pci 0002:01:00.0: VF(n) BAR4 space: [mem 0x8430e0000000-0x8430efffffff 64bit] (contains BAR4 for 128 VFs)
[    2.178990] pci 0002:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.179016] pci 0002:00:02.0: PCI bridge to [bus 01]
[    2.179025] pci_bus 0002:00: resource 4 [mem 0x842000000000-0x843fffffffff window]
[    2.179134] ACPI: PCI Root Bridge [PCI3] (domain 0003 [bus 00-1f])
[    2.179147] acpi PNP0A08:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.179291] acpi PNP0A08:03: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.179421] acpi PNP0A08:03: _OSC: OS now controls [PCIeCapability]
[    2.179941] acpi PNP0A08:03: ECAM area [mem 0x84b000000000-0x84b001ffffff] reserved by CAVA02C:03
[    2.179957] acpi PNP0A08:03: ECAM at [mem 0x84b000000000-0x84b001ffffff] for [bus 00-1f]
[    2.180087] PCI host bridge to bus 0003:00
[    2.180094] pci_bus 0003:00: root bus resource [mem 0x818000000000-0x81ffffffffff window]
[    2.180102] pci_bus 0003:00: root bus resource [bus 00-1f]
[    2.180136] pci_bus 0003:00: resource 4 [mem 0x818000000000-0x81ffffffffff window]
[    2.180243] ACPI: PCI Root Bridge [PEM0] (domain 0004 [bus 1f-57])
[    2.180255] acpi PNP0A08:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.180395] acpi PNP0A08:04: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.180525] acpi PNP0A08:04: _OSC: OS now controls [PCIeCapability]
[    2.180534] acpi PNP0A08:04: MCFG quirk: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57] with thunder_pem_ecam_ops
[    2.181084] acpi PNP0A08:04: ECAM area [mem 0x88001f000000-0x880057ffffff] reserved by CAVA02B:00
[    2.181680] acpi PNP0A08:04: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57]
[    2.181715] Remapped I/O 0x0000883000000000 to [io  0x0000-0xffff window]
[    2.181851] PCI host bridge to bus 0004:1f
[    2.181858] pci_bus 0004:1f: root bus resource [io  0x0000-0xffff window]
[    2.181866] pci_bus 0004:1f: root bus resource [mem 0x881010000000-0x881fffffffff window] (bus address [0x10000000-0xfffffffff])
[    2.181874] pci_bus 0004:1f: root bus resource [mem 0x882000000000-0x882fffffffff pref window] (bus address [0x1000000000-0x1fffffffff])
[    2.181881] pci_bus 0004:1f: root bus resource [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.181888] pci_bus 0004:1f: root bus resource [bus 1f-57]
[    2.181914] pci 0004:1f:00.0: [177d:a100] type 01 class 0x060400
[    2.181928] pci 0004:1f:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit pref]
[    2.181938] pci 0004:1f:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    2.181953] pci 0004:1f:00.0: enabling Extended Tags
[    2.181977] pci 0004:1f:00.0: BAR 0: [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    2.182150] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.182244] pci 0004:20:00.0: [1a03:1150] type 01 class 0x060400
[    2.182294] pci 0004:20:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)
[    2.182303] pci 0004:20:00.0: Max Payload Size set to 128 (was 128, max 128)
[    2.182312] pci 0004:20:00.0: enabling Extended Tags
[    2.182398] pci 0004:20:00.0: supports D1 D2
[    2.182404] pci 0004:20:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.182575] pci 0004:20:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.182640] pci_bus 0004:21: extended config space not accessible
[    2.182701] pci 0004:21:00.0: [1a03:2000] type 00 class 0x030000
[    2.182721] pci 0004:21:00.0: reg 0x10: [mem 0x881010000000-0x881010ffffff]
[    2.182734] pci 0004:21:00.0: reg 0x14: [mem 0x881011000000-0x88101101ffff]
[    2.182746] pci 0004:21:00.0: reg 0x18: [io  0x0000-0x007f]
[    2.182806] pci 0004:21:00.0: BAR 0: assigned to efifb
[    2.182855] pci 0004:21:00.0: supports D1 D2
[    2.182861] pci 0004:21:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.183056] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.183074] pci 0004:1f:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.183082] pci 0004:1f:00.0: BAR 6: assigned [mem 0x881011800000-0x88101180ffff pref]
[    2.183090] pci 0004:1f:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.183098] pci 0004:20:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.183105] pci 0004:20:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.183113] pci 0004:21:00.0: BAR 0: assigned [mem 0x881010000000-0x881010ffffff]
[    2.183122] pci 0004:21:00.0: BAR 1: assigned [mem 0x881011000000-0x88101101ffff]
[    2.183131] pci 0004:21:00.0: BAR 2: assigned [io  0x1000-0x107f]
[    2.183140] pci 0004:20:00.0: PCI bridge to [bus 21]
[    2.183147] pci 0004:20:00.0:   bridge window [io  0x1000-0x1fff]
[    2.183153] pci 0004:20:00.0:   bridge window [mem 0x881010000000-0x8810117fffff]
[    2.183160] pci 0004:1f:00.0: PCI bridge to [bus 20-21]
[    2.183166] pci 0004:1f:00.0:   bridge window [io  0x1000-0x1fff]
[    2.183173] pci 0004:1f:00.0:   bridge window [mem 0x881010000000-0x8810117fffff]
[    2.183180] pci_bus 0004:1f: resource 4 [io  0x0000-0xffff window]
[    2.183186] pci_bus 0004:1f: resource 5 [mem 0x881010000000-0x881fffffffff window]
[    2.183193] pci_bus 0004:1f: resource 6 [mem 0x882000000000-0x882fffffffff pref window]
[    2.183199] pci_bus 0004:1f: resource 7 [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.183206] pci_bus 0004:20: resource 0 [io  0x1000-0x1fff]
[    2.183212] pci_bus 0004:20: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.183218] pci_bus 0004:21: resource 0 [io  0x1000-0x1fff]
[    2.183224] pci_bus 0004:21: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.183336] ACPI: PCI Interrupt Link [LN0A] (IRQs *48)
[    2.183387] ACPI: PCI Interrupt Link [LN0B] (IRQs *49)
[    2.183434] ACPI: PCI Interrupt Link [LN0C] (IRQs *50)
[    2.183480] ACPI: PCI Interrupt Link [LN0D] (IRQs *51)
[    2.183772] ARMH0011:00: ttyAMA0 at MMIO 0x87e024000000 (irq = 21, base_baud = 0) is a SBSA
[    6.382848] printk: console [ttyAMA0] enabled
[    6.390414] ARMH0011:01: ttyAMA1 at MMIO 0x87e025000000 (irq = 22, base_baud = 0) is a SBSA
[    6.404767] iommu: Default domain type: Translated 
[    6.409783] pci 0004:21:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
[    6.418137] pci 0004:21:00.0: vgaarb: bridge control possible
[    6.423876] pci 0004:21:00.0: vgaarb: setting as boot device (VGA legacy resources not available)
[    6.432738] vgaarb: loaded
[    6.436158] SCSI subsystem initialized
[    6.440133] ACPI: bus type USB registered
[    6.444193] usbcore: registered new interface driver usbfs
[    6.449703] usbcore: registered new interface driver hub
[    6.455057] usbcore: registered new device driver usb
[    6.460202] pps_core: LinuxPPS API ver. 1 registered
[    6.465165] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
[    6.474295] PTP clock support registered
[    6.478411] EDAC MC: Ver: 3.0.0
[    6.481993] Registered efivars operations
[    6.487793] NetLabel: Initializing
[    6.491196] NetLabel:  domain hash size = 128
[    6.495544] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    6.501233] NetLabel:  unlabeled traffic allowed by default
[    6.507333] clocksource: Switched to clocksource arch_sys_counter
[    6.553602] VFS: Disk quotas dquot_6.6.0
[    6.557582] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    6.564907] AppArmor: AppArmor Filesystem Enabled
[    6.569703] pnp: PnP ACPI init
[    6.573376] system 00:00: [mem 0x848000000000-0x848001ffffff] could not be reserved
[    6.581230] system 00:01: [mem 0x849000000000-0x849001ffffff] could not be reserved
[    6.589075] system 00:02: [mem 0x84a000000000-0x84a001ffffff] could not be reserved
[    6.596921] system 00:03: [mem 0x84b000000000-0x84b001ffffff] could not be reserved
[    6.604770] system 00:04: [mem 0x87e0c0000000-0x87e0c0ffffff] could not be reserved
[    6.612431] system 00:04: [mem 0x88001f000000-0x880057ffffff] could not be reserved
[    6.622306] pnp: PnP ACPI: found 5 devices
[    6.632232] NET: Registered protocol family 2
[    6.637376] tcp_listen_portaddr_hash hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    6.646603] TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    6.656465] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
[    6.664233] TCP: Hash tables configured (established 524288 bind 65536)
[    6.671254] MPTCP token hash table entries: 65536 (order: 8, 1572864 bytes, linear)
[    6.679469] UDP hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.687022] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.695198] NET: Registered protocol family 1
[    6.699568] NET: Registered protocol family 44
[    6.704208] PCI: CLS 0 bytes, default 64
[    6.708237] Trying to unpack rootfs image as initramfs...
[    7.713965] Freeing initrd memory: 68180K
[    7.721067] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available
[    7.729104] kvm [1]: IPA Size Limit: 48 bits
[    7.734986] kvm [1]: GICv3: no GICV resource entry
[    7.739781] kvm [1]: disabling GICv2 emulation
[    7.744217] kvm [1]: GICv3 sysreg trapping enabled ([G0G1], reduced performance)
[    7.751617] kvm [1]: GIC system register CPU interface enabled
[    7.758605] kvm [1]: vgic interrupt IRQ9
[    7.763776] kvm [1]: Hyp mode initialized successfully
[    7.771680] Initialise system trusted keyrings
[    7.776151] Key type blacklist registered
[    7.780323] workingset: timestamp_bits=40 max_order=24 bucket_order=0
[    7.791059] zbud: loaded
[    7.794771] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.801149] fuse: init (API version 7.33)
[    7.805555] integrity: Platform Keyring initialized
[    7.833189] Key type asymmetric registered
[    7.837286] Asymmetric key parser 'x509' registered
[    7.842174] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.849699] io scheduler mq-deadline registered
[    7.857591] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    7.865127] efifb: probing for efifb
[    7.868738] efifb: No BGRT, not showing boot graphics
[    7.873783] efifb: framebuffer at 0x881010000000, using 3072k, total 3072k
[    7.880649] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    7.886647] efifb: scrolling: redraw
[    7.890212] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    7.895905] fbcon: Deferring console take-over
[    7.900350] fb0: EFI VGA frame buffer device
[    7.905289] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    7.913714] ACPI: button: Power Button [PWRB]
[    7.919549] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
[    7.927289] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
[    7.936326] Mem abort info:
[    7.939108]   ESR = 0x96000004
[    7.942151]   EC = 0x25: DABT (current EL), IL = 32 bits
[    7.947451]   SET = 0, FnV = 0
[    7.950494]   EA = 0, S1PTW = 0
[    7.953624] Data abort info:
[    7.956492]   ISV = 0, ISS = 0x00000004
[    7.960316]   CM = 0, WnR = 0
[    7.963273] [0000000000000028] user address but active_mm is swapper
[    7.969616] Internal error: Oops: 96000004 [#1] SMP
[    7.974483] Modules linked in:
[    7.977531] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8 #19
[    7.983874] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    7.990737] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[    7.996732] pc : __ipi_send_mask+0x60/0x114
[    8.000910] lr : smp_cross_call+0x40/0xcc
[    8.004913] sp : ffff800012753c10
[    8.008216] x29: ffff800012753c10 x28: ffff000100de5d00 
[    8.013521] x27: 000000000000000a x26: ffff80001225da20 
[    8.018825] x25: 0000000000000000 x24: ffff000ff62719b0 
[    8.024129] x23: ffff80001225d000 x22: ffff800012368108 
[    8.029433] x21: ffff800010f69a20 x20: 0000000000000000 
[    8.034737] x19: ffff000100143c60 x18: 0000000000000020 
[    8.040041] x17: 000000008e74252f x16: 00000000bf0ab2ad 
[    8.045345] x15: ffffffffffffffff x14: 0000000000000000 
[    8.050649] x13: 003d090000000000 x12: 00003d0900000000 
[    8.055953] x11: 0000000000000000 x10: 00003d0900000000 
[    8.061257] x9 : ffff800010027f14 x8 : 0000000000000000 
[    8.066561] x7 : 00000000ffffffff x6 : ffff000ff6148698 
[    8.071865] x5 : ffff80001159d040 x4 : ffff80001159d110 
[    8.077169] x3 : ffff800010f69a00 x2 : 0000000000000000 
[    8.082473] x1 : ffff800010f69a20 x0 : 0000000000000000 
[    8.087777] Call trace:
[    8.090213]  __ipi_send_mask+0x60/0x114
[    8.094038]  smp_cross_call+0x40/0xcc
[    8.097691]  smp_send_reschedule+0x3c/0x50
[    8.101778]  resched_curr+0x5c/0xb0
[    8.105258]  check_preempt_curr+0x58/0x90
[    8.109258]  ttwu_do_wakeup+0x2c/0x190
[    8.112996]  ttwu_do_activate+0x7c/0x114
[    8.116909]  try_to_wake_up+0x388/0x670
[    8.120735]  wake_up_process+0x24/0x30
[    8.124474]  swake_up_one+0x48/0x9c
[    8.127953]  rcu_gp_kthread_wake+0x68/0x8c
[    8.132041]  rcu_accelerate_cbs_unlocked+0xb4/0xf0
[    8.136822]  rcu_core+0x520/0x694
[    8.140128]  rcu_core_si+0x1c/0x2c
[    8.143520]  __do_softirq+0x128/0x388
[    8.147172]  irq_exit+0xc4/0xec
[    8.150304]  __handle_domain_irq+0x8c/0xec
[    8.154394]  gic_handle_irq+0xd8/0x2f0
[    8.158132]  el1_irq+0xc0/0x180
[    8.161262]  __pi_strcmp+0x20/0x158
[    8.164742]  driver_register+0x68/0x140
[    8.168571]  __platform_driver_register+0x34/0x40
[    8.173265]  imx8mp_clk_driver_init+0x28/0x34
[    8.177614]  do_one_initcall+0x50/0x260
[    8.181440]  kernel_init_freeable+0x24c/0x2d4
[    8.185790]  kernel_init+0x20/0x134
[    8.189271]  ret_from_fork+0x10/0x18
[    8.192840] Code: a90363f7 aa0103f5 d0010957 f9401260 (b9402800) 
[    8.198955] ---[ end trace c24172add816c1f0 ]---
[    8.203562] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[    8.210442] SMP: stopping secondary CPUs
[    9.258360] SMP: failed to stop secondary CPUs 0,9
[    9.263141] Kernel Offset: disabled
[    9.266617] CPU features: 0x00040002,69101108
[    9.270963] Memory Limit: none
[    9.274024] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---


From swboyd at chromium.org  Tue Apr 20 22:49:50 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Tue, 20 Apr 2021 14:49:50 -0700
Subject: [PATCH v5 00/13] Add build ID to stacktraces
Message-ID: <20210420215003.3510247-1-swboyd@chromium.org>

This series adds the kernel's build ID[1] to the stacktrace header printed
in oops messages, warnings, etc. and the build ID for any module that
appears in the stacktrace after the module name. The goal is to make the
stacktrace more self-contained and descriptive by including the relevant
build IDs in the kernel logs when something goes wrong. This can be used
by post processing tools like script/decode_stacktrace.sh and kernel
developers to easily locate the debug info associated with a kernel
crash and line up what line and file things started falling apart at.

To show how this can be used I've included a patch to
decode_stacktrace.sh that downloads the debuginfo from a debuginfod
server.

This also includes some patches to make the buildid.c file use more
const arguments and consolidate logic into buildid.c from kdump. These
are left to the end as they were mostly cleanup patches. I don't know
who exactly maintains this so I guess Andrew is the best option to merge
all this code.

Here's an example lkdtm stacktrace on arm64.

 WARNING: CPU: 4 PID: 3255 at drivers/misc/lkdtm/bugs.c:83 lkdtm_WARNING+0x28/0x30 [lkdtm]
 Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE
 CPU: 4 PID: 3255 Comm: bash Not tainted 5.11 #3 aa23f7a1231c229de205662d5a9e0d4c580f19a1
 Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
 pstate: 00400009 (nzcv daif +PAN -UAO -TCO BTYPE=--)
 pc : lkdtm_WARNING+0x28/0x30 [lkdtm]
 lr : lkdtm_do_action+0x24/0x40 [lkdtm]
 sp : ffffffc0134fbca0
 x29: ffffffc0134fbca0 x28: ffffff92d53ba240
 x27: 0000000000000000 x26: 0000000000000000
 x25: 0000000000000000 x24: ffffffe3622352c0
 x23: 0000000000000020 x22: ffffffe362233366
 x21: ffffffe3622352e0 x20: ffffffc0134fbde0
 x19: 0000000000000008 x18: 0000000000000000
 x17: ffffff929b6536fc x16: 0000000000000000
 x15: 0000000000000000 x14: 0000000000000012
 x13: ffffffe380ed892c x12: ffffffe381d05068
 x11: 0000000000000000 x10: 0000000000000000
 x9 : 0000000000000001 x8 : ffffffe362237000
 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000
 x5 : 0000000000000000 x4 : 0000000000000001
 x3 : 0000000000000008 x2 : ffffff93fef25a70
 x1 : ffffff93fef15788 x0 : ffffffe3622352e0
 Call trace:
  lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e]
  direct_entry+0x16c/0x1b4 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e]
  full_proxy_write+0x74/0xa4
  vfs_write+0xec/0x2e8
  ksys_write+0x84/0xf0
  __arm64_sys_write+0x24/0x30
  el0_svc_common+0xf4/0x1c0
  do_el0_svc_compat+0x28/0x3c
  el0_svc_compat+0x10/0x1c
  el0_sync_compat_handler+0xa8/0xcc
  el0_sync_compat+0x178/0x180
 ---[ end trace 3d95032303e59e68 ]---

Changes from v4 (https://lore.kernel.org/r/20210410015300.3764485-1-swboyd at chromium.org):
 * Stubbed out more code when CONFIG_STACKTRACE_BUILD_ID=n
 * Use static_assert instead of BUILD_BUG_ON()
 * Dropped bad printk change to IP on x86

Changes from v3 (https://lore.kernel.org/r/20210331030520.3816265-1-swboyd at chromium.org):
 * Fixed compilation warnings due to config changes
 * Fixed kernel-doc on init_vmlinx_build_id()
 * Totally removed add_build_id_vmcoreinfo()
 * Added another printk format %pBb to help x86 print backtraces
 * Some BUILD_BUG_ON() checks to make sure the buildid doesn't get bigger or smaller

Changes from v2 (https://lore.kernel.org/r/20210324020443.1815557-1-swboyd at chromium.org):
 * Renamed symbol printing function to indicate build IDness
 * Put build ID information behind Kconfig knob
 * Build ID for vmlinux is calculated in early init instead of on demand
 * printk format is %pS[R]b

Changes from v1 (https://lore.kernel.org/r/20210301174749.1269154-1-swboyd at chromium.org):
 * New printk format %pSb and %pSr
 * Return binary format instead of hex format string from build ID APIs
 * Some new patches to cleanup buildid/decode_stacktrace.sh
 * A new patch to decode_stacktrace.sh to parse output

[1] https://fedoraproject.org/wiki/Releases/FeatureBuildId

Cc: Alexei Starovoitov <ast at kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Baoquan He <bhe at redhat.com>
Cc: Borislav Petkov <bp at alien8.de>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Dave Young <dyoung at redhat.com>
Cc: Evan Green <evgreen at chromium.org>
Cc: Hsin-Yi Wang <hsinyi at chromium.org>
Cc: Ingo Molnar <mingo at redhat.com>
Cc: Jessica Yu <jeyu at kernel.org>
Cc: Jiri Olsa <jolsa at kernel.org>
Cc: <kexec at lists.infradead.org>
Cc: Konstantin Khlebnikov <khlebnikov at yandex-team.ru>
Cc: <linux-arm-kernel at lists.infradead.org>
Cc: <linux-doc at vger.kernel.org>
Cc: <linux-kernel at vger.kernel.org>
Cc: Matthew Wilcox <willy at infradead.org>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Rasmus Villemoes <linux at rasmusvillemoes.dk>
Cc: Sasha Levin <sashal at kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky at gmail.com>
Cc: Steven Rostedt <rostedt at goodmis.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Vivek Goyal <vgoyal at redhat.com>
Cc: Will Deacon <will at kernel.org>
Cc: <x86 at kernel.org>
Cc: Christoph Hellwig <hch at infradead.org>
Cc: peter enderborg <peter.
Stephen Boyd (13):
  buildid: Only consider GNU notes for build ID parsing
  buildid: Add API to parse build ID out of buffer
  buildid: Stash away kernels build ID on init
  dump_stack: Add vmlinux build ID to stack traces
  module: Add printk formats to add module build ID to stacktraces
  arm64: stacktrace: Use %pSb for backtrace printing
  x86/dumpstack: Use %pSb/%pBb for backtrace printing
  scripts/decode_stacktrace.sh: Support debuginfod
  scripts/decode_stacktrace.sh: Silence stderr messages from
    addr2line/nm
  scripts/decode_stacktrace.sh: Indicate 'auto' can be used for base
    path
  buildid: Mark some arguments const
  buildid: Fix kernel-doc notation
  kdump: Use vmlinux_build_id to simplify

 Documentation/core-api/printk-formats.rst |  11 +++
 arch/arm64/kernel/stacktrace.c            |   2 +-
 arch/x86/kernel/dumpstack.c               |   2 +-
 include/linux/buildid.h                   |   8 ++
 include/linux/crash_core.h                |  12 +--
 include/linux/kallsyms.h                  |  20 ++++-
 include/linux/module.h                    |   8 +-
 init/main.c                               |   1 +
 kernel/crash_core.c                       |  50 +----------
 kernel/kallsyms.c                         | 101 +++++++++++++++++-----
 kernel/module.c                           |  31 ++++++-
 lib/Kconfig.debug                         |  11 +++
 lib/buildid.c                             |  74 ++++++++++++----
 lib/dump_stack.c                          |  13 ++-
 lib/vsprintf.c                            |   8 +-
 scripts/decode_stacktrace.sh              |  89 +++++++++++++++----
 16 files changed, 327 insertions(+), 114 deletions(-)


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
-- 
https://chromeos.dev



From swboyd at chromium.org  Tue Apr 20 22:49:56 2021
From: swboyd at chromium.org (Stephen Boyd)
Date: Tue, 20 Apr 2021 14:49:56 -0700
Subject: [PATCH v5 06/13] arm64: stacktrace: Use %pSb for backtrace printing
In-Reply-To: <20210420215003.3510247-1-swboyd@chromium.org>
References: <20210420215003.3510247-1-swboyd@chromium.org>
Message-ID: <20210420215003.3510247-7-swboyd@chromium.org>

Let's use the new printk format to print the stacktrace entry when
printing a backtrace to the kernel logs. This will include any module's
build ID[1] in it so that offline/crash debugging can easily locate the
debuginfo for a module via something like debuginfod[2].

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: <linux-arm-kernel at lists.infradead.org>
Cc: Jiri Olsa <jolsa at kernel.org>
Cc: Alexei Starovoitov <ast at kernel.org>
Cc: Jessica Yu <jeyu at kernel.org>
Cc: Evan Green <evgreen at chromium.org>
Cc: Hsin-Yi Wang <hsinyi at chromium.org>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Steven Rostedt <rostedt at goodmis.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Matthew Wilcox <willy at infradead.org>
Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
Link: https://sourceware.org/elfutils/Debuginfod.html [2]
Signed-off-by: Stephen Boyd <swboyd at chromium.org>
---
 arch/arm64/kernel/stacktrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index ad20981dfda4..9d38da01ff98 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -129,7 +129,7 @@ NOKPROBE_SYMBOL(walk_stackframe);
 
 static void dump_backtrace_entry(unsigned long where, const char *loglvl)
 {
-	printk("%s %pS\n", loglvl, (void *)where);
+	printk("%s %pSb\n", loglvl, (void *)where);
 }
 
 void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
-- 
https://chromeos.dev



From lkp at intel.com  Tue Apr 20 22:56:13 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 05:56:13 +0800
Subject: [soc:for-next] BUILD SUCCESS 35a77f812374a2b7393593f08c5eccdad9c622bf
Message-ID: <607f4dfd.SBOy6oN93WRXA+cN%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 35a77f812374a2b7393593f08c5eccdad9c622bf  soc: document merges

elapsed time: 727m

configs tested: 110
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
arm                       imx_v4_v5_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                      bamboo_defconfig
arm                        magician_defconfig
xtensa                       common_defconfig
um                            kunit_defconfig
powerpc                    ge_imp3a_defconfig
sh                                  defconfig
m68k                            mac_defconfig
powerpc                      makalu_defconfig
powerpc                   motionpro_defconfig
um                                allnoconfig
sh                          rsk7203_defconfig
powerpc64                           defconfig
mips                      pic32mzda_defconfig
sh                           se7780_defconfig
openrisc                  or1klitex_defconfig
mips                     decstation_defconfig
riscv                          rv32_defconfig
powerpc                       maple_defconfig
um                           x86_64_defconfig
sh                          r7780mp_defconfig
mips                     loongson1b_defconfig
sh                  sh7785lcr_32bit_defconfig
nios2                            alldefconfig
powerpc                      mgcoge_defconfig
sh                           se7724_defconfig
sh                          sdk7786_defconfig
arm                            dove_defconfig
powerpc                     ppa8548_defconfig
powerpc                  mpc885_ads_defconfig
arm                       aspeed_g4_defconfig
arm                         s3c2410_defconfig
sh                            hp6xx_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a005-20210420
i386                 randconfig-a002-20210420
i386                 randconfig-a001-20210420
i386                 randconfig-a006-20210420
i386                 randconfig-a004-20210420
i386                 randconfig-a003-20210420
x86_64               randconfig-a015-20210420
x86_64               randconfig-a016-20210420
x86_64               randconfig-a011-20210420
x86_64               randconfig-a014-20210420
x86_64               randconfig-a013-20210420
x86_64               randconfig-a012-20210420
i386                 randconfig-a012-20210420
i386                 randconfig-a014-20210420
i386                 randconfig-a011-20210420
i386                 randconfig-a013-20210420
i386                 randconfig-a015-20210420
i386                 randconfig-a016-20210420
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210420
x86_64               randconfig-a002-20210420
x86_64               randconfig-a001-20210420
x86_64               randconfig-a005-20210420
x86_64               randconfig-a006-20210420
x86_64               randconfig-a003-20210420

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 22:56:06 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 05:56:06 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 d028b508c112b0414ec60163c2cca0ca3a478709
Message-ID: <607f4df6.j8M+kogaM2MrdjYE%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: d028b508c112b0414ec60163c2cca0ca3a478709  Merge tag 'bmc-5.13-devicetree-2' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt

elapsed time: 727m

configs tested: 109
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
i386                             allyesconfig
arm                       imx_v4_v5_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                      bamboo_defconfig
arm                        magician_defconfig
xtensa                       common_defconfig
um                            kunit_defconfig
nios2                         10m50_defconfig
sh                            titan_defconfig
arm                        mvebu_v7_defconfig
mips                        bcm47xx_defconfig
arm                        oxnas_v6_defconfig
mips                        bcm63xx_defconfig
powerpc                    ge_imp3a_defconfig
sh                                  defconfig
m68k                            mac_defconfig
powerpc                      makalu_defconfig
powerpc                   motionpro_defconfig
um                                allnoconfig
sh                          rsk7203_defconfig
powerpc64                           defconfig
mips                      pic32mzda_defconfig
sh                           se7780_defconfig
openrisc                  or1klitex_defconfig
mips                     decstation_defconfig
riscv                          rv32_defconfig
mips                malta_qemu_32r6_defconfig
openrisc                            defconfig
sparc                       sparc64_defconfig
mips                             allmodconfig
h8300                    h8300h-sim_defconfig
powerpc                  mpc885_ads_defconfig
arm                       aspeed_g4_defconfig
arm                         s3c2410_defconfig
sh                            hp6xx_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a005-20210420
i386                 randconfig-a002-20210420
i386                 randconfig-a001-20210420
i386                 randconfig-a006-20210420
i386                 randconfig-a004-20210420
i386                 randconfig-a003-20210420
x86_64               randconfig-a015-20210420
x86_64               randconfig-a016-20210420
x86_64               randconfig-a011-20210420
x86_64               randconfig-a014-20210420
x86_64               randconfig-a013-20210420
x86_64               randconfig-a012-20210420
i386                 randconfig-a012-20210420
i386                 randconfig-a014-20210420
i386                 randconfig-a011-20210420
i386                 randconfig-a013-20210420
i386                 randconfig-a015-20210420
i386                 randconfig-a016-20210420
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a004-20210420
x86_64               randconfig-a002-20210420
x86_64               randconfig-a001-20210420
x86_64               randconfig-a005-20210420
x86_64               randconfig-a006-20210420
x86_64               randconfig-a003-20210420

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Tue Apr 20 22:56:08 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 05:56:08 +0800
Subject: [soc:bcm/dt-2] BUILD SUCCESS f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2
Message-ID: <607f4df8.hTW8i105Y9vZXMqF%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git bcm/dt-2
branch HEAD: f0145db24e65f6cf13347a90ffb86e5ef2ff2ca2  ARM: dts: aspeed: tiogapass: add hotplug controller

elapsed time: 6789m

configs tested: 286
configs skipped: 124

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
arm                         lpc18xx_defconfig
i386                                defconfig
arm                      jornada720_defconfig
arm                    vt8500_v6_v7_defconfig
riscv                    nommu_k210_defconfig
mips                      pic32mzda_defconfig
microblaze                      mmu_defconfig
xtensa                  nommu_kc705_defconfig
mips                         tb0219_defconfig
arm                             mxs_defconfig
parisc                generic-64bit_defconfig
arm                        mvebu_v5_defconfig
arm                         vf610m4_defconfig
powerpc                 mpc837x_mds_defconfig
sh                           se7705_defconfig
powerpc                     tqm8541_defconfig
m68k                        m5307c3_defconfig
powerpc                     rainier_defconfig
powerpc                  storcenter_defconfig
mips                          ath79_defconfig
arm                           corgi_defconfig
powerpc                     taishan_defconfig
mips                  decstation_64_defconfig
powerpc                       ebony_defconfig
powerpc                     ksi8560_defconfig
powerpc                     mpc5200_defconfig
m68k                          atari_defconfig
arc                    vdk_hs38_smp_defconfig
powerpc                     kmeter1_defconfig
openrisc                 simple_smp_defconfig
arm                       imx_v4_v5_defconfig
powerpc                 xes_mpc85xx_defconfig
powerpc                      bamboo_defconfig
arm                        magician_defconfig
xtensa                       common_defconfig
um                            kunit_defconfig
xtensa                           allyesconfig
sh                          urquell_defconfig
arc                     haps_hs_smp_defconfig
sh                      rts7751r2d1_defconfig
xtensa                         virt_defconfig
arm                            mmp2_defconfig
arm                           omap1_defconfig
arm                        multi_v5_defconfig
powerpc                     tqm8540_defconfig
nios2                         10m50_defconfig
sh                            titan_defconfig
arm                        mvebu_v7_defconfig
mips                        bcm47xx_defconfig
arm                        oxnas_v6_defconfig
mips                        bcm63xx_defconfig
arm                         cm_x300_defconfig
m68k                          hp300_defconfig
sh                           se7722_defconfig
m68k                             alldefconfig
arm                         lubbock_defconfig
sh                   rts7751r2dplus_defconfig
arm                       aspeed_g5_defconfig
sh                           se7712_defconfig
mips                        jmr3927_defconfig
arm                        trizeps4_defconfig
mips                           ip28_defconfig
ia64                             allmodconfig
powerpc                    adder875_defconfig
mips                      pistachio_defconfig
mips                           ip27_defconfig
powerpc                 mpc8272_ads_defconfig
sh                     magicpanelr2_defconfig
xtensa                    xip_kc705_defconfig
powerpc                 mpc8560_ads_defconfig
arm64                            alldefconfig
powerpc                      acadia_defconfig
sh                           se7750_defconfig
sh                         apsh4a3a_defconfig
sparc                       sparc32_defconfig
um                               alldefconfig
m68k                        m5272c3_defconfig
openrisc                         alldefconfig
arc                            hsdk_defconfig
mips                    maltaup_xpa_defconfig
powerpc                        warp_defconfig
arm                          pxa910_defconfig
arm                          imote2_defconfig
um                                allnoconfig
powerpc                      ep88xc_defconfig
powerpc                    socrates_defconfig
sparc                       sparc64_defconfig
m68k                            mac_defconfig
powerpc                      tqm8xx_defconfig
arm                          moxart_defconfig
m68k                       m5208evb_defconfig
arm                            mps2_defconfig
powerpc                      pcm030_defconfig
sh                          sdk7780_defconfig
m68k                        mvme147_defconfig
powerpc                 linkstation_defconfig
sh                          sdk7786_defconfig
s390                             allmodconfig
arm                        vexpress_defconfig
h8300                       h8s-sim_defconfig
arm                     davinci_all_defconfig
m68k                            q40_defconfig
mips                          malta_defconfig
powerpc                   motionpro_defconfig
sh                          rsk7203_defconfig
powerpc64                           defconfig
sh                           se7780_defconfig
mips                          rm200_defconfig
xtensa                              defconfig
powerpc                     stx_gp3_defconfig
openrisc                  or1klitex_defconfig
mips                     decstation_defconfig
riscv                          rv32_defconfig
mips                     cu1830-neo_defconfig
powerpc                      cm5200_defconfig
arm                      pxa255-idp_defconfig
s390                             alldefconfig
arm                         socfpga_defconfig
sh                ecovec24-romimage_defconfig
powerpc                          allmodconfig
arm                         shannon_defconfig
sparc64                             defconfig
sh                   sh7770_generic_defconfig
xtensa                          iss_defconfig
mips                           gcw0_defconfig
powerpc                 mpc8315_rdb_defconfig
sh                           se7721_defconfig
mips                      fuloong2e_defconfig
mips                        maltaup_defconfig
arm                           h5000_defconfig
powerpc                     mpc83xx_defconfig
arm                            zeus_defconfig
arm                       omap2plus_defconfig
mips                      loongson3_defconfig
arm                         hackkit_defconfig
powerpc                     ep8248e_defconfig
h8300                               defconfig
powerpc                       ppc64_defconfig
arm                       multi_v4t_defconfig
arc                         haps_hs_defconfig
nios2                            alldefconfig
powerpc                      mgcoge_defconfig
sh                           se7724_defconfig
arm                            dove_defconfig
powerpc                     ppa8548_defconfig
sh                        sh7757lcr_defconfig
arm                              alldefconfig
arm                       aspeed_g4_defconfig
h8300                     edosk2674_defconfig
openrisc                            defconfig
powerpc                    ge_imp3a_defconfig
powerpc                     powernv_defconfig
sh                             espt_defconfig
arm                          iop32x_defconfig
powerpc                        cell_defconfig
m68k                         apollo_defconfig
ia64                         bigsur_defconfig
h8300                            alldefconfig
parisc                           alldefconfig
powerpc                       holly_defconfig
sh                        sh7785lcr_defconfig
m68k                          multi_defconfig
sh                        sh7763rdp_defconfig
powerpc                      pmac32_defconfig
mips                           ip22_defconfig
arm                            qcom_defconfig
powerpc                    klondike_defconfig
sh                         microdev_defconfig
nios2                         3c120_defconfig
sh                          landisk_defconfig
arm                          pcm027_defconfig
powerpc                  mpc885_ads_defconfig
arm                         s3c2410_defconfig
sh                            hp6xx_defconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                           allnoconfig
x86_64               randconfig-a003-20210419
x86_64               randconfig-a001-20210419
x86_64               randconfig-a005-20210419
x86_64               randconfig-a002-20210419
x86_64               randconfig-a006-20210419
x86_64               randconfig-a004-20210419
i386                 randconfig-a003-20210416
i386                 randconfig-a006-20210416
i386                 randconfig-a001-20210416
i386                 randconfig-a005-20210416
i386                 randconfig-a004-20210416
i386                 randconfig-a002-20210416
i386                 randconfig-a005-20210420
i386                 randconfig-a002-20210420
i386                 randconfig-a001-20210420
i386                 randconfig-a006-20210420
i386                 randconfig-a004-20210420
i386                 randconfig-a003-20210420
x86_64               randconfig-a015-20210420
x86_64               randconfig-a016-20210420
x86_64               randconfig-a011-20210420
x86_64               randconfig-a014-20210420
x86_64               randconfig-a013-20210420
x86_64               randconfig-a012-20210420
x86_64               randconfig-a014-20210416
x86_64               randconfig-a015-20210416
x86_64               randconfig-a011-20210416
x86_64               randconfig-a013-20210416
x86_64               randconfig-a012-20210416
x86_64               randconfig-a016-20210416
i386                 randconfig-a012-20210420
i386                 randconfig-a014-20210420
i386                 randconfig-a011-20210420
i386                 randconfig-a013-20210420
i386                 randconfig-a015-20210420
i386                 randconfig-a016-20210420
i386                 randconfig-a015-20210416
i386                 randconfig-a014-20210416
i386                 randconfig-a013-20210416
i386                 randconfig-a012-20210416
i386                 randconfig-a016-20210416
i386                 randconfig-a011-20210416
i386                 randconfig-a015-20210419
i386                 randconfig-a013-20210419
i386                 randconfig-a014-20210419
i386                 randconfig-a016-20210419
i386                 randconfig-a012-20210419
i386                 randconfig-a011-20210419
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
um                               allmodconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a003-20210416
x86_64               randconfig-a002-20210416
x86_64               randconfig-a005-20210416
x86_64               randconfig-a001-20210416
x86_64               randconfig-a006-20210416
x86_64               randconfig-a004-20210416
x86_64               randconfig-a004-20210420
x86_64               randconfig-a002-20210420
x86_64               randconfig-a001-20210420
x86_64               randconfig-a005-20210420
x86_64               randconfig-a006-20210420
x86_64               randconfig-a003-20210420
x86_64               randconfig-a014-20210419
x86_64               randconfig-a015-20210419
x86_64               randconfig-a013-20210419
x86_64               randconfig-a011-20210419
x86_64               randconfig-a012-20210419
x86_64               randconfig-a016-20210419

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From vdumpa at nvidia.com  Tue Apr 20 23:06:25 2021
From: vdumpa at nvidia.com (Krishna Reddy)
Date: Tue, 20 Apr 2021 22:06:25 +0000
Subject: [PATCH v2 04/10] iommu/arm-smmu: tegra: Detect number of
 instances at runtime
In-Reply-To: <20210420172619.3782831-5-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
 <20210420172619.3782831-5-thierry.reding@gmail.com>
Message-ID: <BY5PR12MB3764DA150606275026E7596EB3489@BY5PR12MB3764.namprd12.prod.outlook.com>

>+static const struct arm_smmu_impl nvidia_smmu_single_impl = {
>+       .probe_finalize = nvidia_smmu_probe_finalize,
>+};

nvidia_smmu_probe_finalize is used before it is defined. It is defined in patch 5.

-KR


From song.bao.hua at hisilicon.com  Tue Apr 20 23:31:36 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Tue, 20 Apr 2021 22:31:36 +0000
Subject: [RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86
In-Reply-To: <422b5d06-ec0e-f064-32fe-15df5b2957dd@linux.intel.com>
References: <20210319041618.14316-1-song.bao.hua@hisilicon.com>
 <20210319041618.14316-5-song.bao.hua@hisilicon.com>
 <110234d1-22ce-8a9a-eabb-c15ac29a5dcd@linux.intel.com>
 <67cc380019fd40d88d7a493b6cbc0852@hisilicon.com>
 <422b5d06-ec0e-f064-32fe-15df5b2957dd@linux.intel.com>
Message-ID: <28ce8c4b8fc347ed9565a2ccac44a39b@hisilicon.com>



> -----Original Message-----
> From: Tim Chen [mailto:tim.c.chen at linux.intel.com]
> Sent: Wednesday, April 21, 2021 6:32 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> catalin.marinas at arm.com; will at kernel.org; rjw at rjwysocki.net;
> vincent.guittot at linaro.org; bp at alien8.de; tglx at linutronix.de;
> mingo at redhat.com; lenb at kernel.org; peterz at infradead.org;
> dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> mgorman at suse.de
> Cc: msys.mizuma at gmail.com; valentin.schneider at arm.com;
> gregkh at linuxfoundation.org; Jonathan Cameron <jonathan.cameron at huawei.com>;
> juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com
> Subject: Re: [RFC PATCH v5 4/4] scheduler: Add cluster scheduler level for x86
> 
> 
> 
> On 3/23/21 4:21 PM, Song Bao Hua (Barry Song) wrote:
> 
> >>
> >> On 3/18/21 9:16 PM, Barry Song wrote:
> >>> From: Tim Chen <tim.c.chen at linux.intel.com>
> >>>
> >>> There are x86 CPU architectures (e.g. Jacobsville) where L2 cahce
> >>> is shared among a cluster of cores instead of being exclusive
> >>> to one single core.
> >>>
> >>> To prevent oversubscription of L2 cache, load should be
> >>> balanced between such L2 clusters, especially for tasks with
> >>> no shared data.
> >>>
> >>> Also with cluster scheduling policy where tasks are woken up
> >>> in the same L2 cluster, we will benefit from keeping tasks
> >>> related to each other and likely sharing data in the same L2
> >>> cluster.
> >>>
> >>> Add CPU masks of CPUs sharing the L2 cache so we can build such
> >>> L2 cluster scheduler domain.
> >>>
> >>> Signed-off-by: Tim Chen <tim.c.chen at linux.intel.com>
> >>> Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
> >>
> >>
> >> Barry,
> >>
> >> Can you also add this chunk to the patch.
> >> Thanks.
> >
> > Sure, Tim, Thanks. I'll put that into patch 4/4 in v6.
> >
> 
> Barry,
> 
> This chunk will also need to be added to return cluster id for x86.
> Please add it in your next rev.

Yes. Thanks. I'll put this in either RFC v7 or Patch v1.

For spreading path, things are much easier, though packing path is 
quite tricky. But It seems RFC v6 has been quite close to what we want
to achieve to pack related tasks by scanning cluster for tasks within
same NUMA:
https://lore.kernel.org/lkml/20210420001844.9116-1-song.bao.hua at hisilicon.com/

If couples have been already in same LLC(numa), scanning clusters will
gather them further. If they are running in different NUMA nodes, the
original scanning LLC will move them to the same node, after that,
scanning cluster might put them closer to each other.

it seems it is kind of the two-level packing Dietmar has suggested.

So perhaps we won't have RFC v7, I will probably send patch v1 afterwards.

> 
> Thanks.
> 
> Tim
> 
> ---
> 
> diff --git a/arch/x86/include/asm/topology.h
> b/arch/x86/include/asm/topology.h
> index 800fa48c9fcd..2548d824f103 100644
> --- a/arch/x86/include/asm/topology.h
> +++ b/arch/x86/include/asm/topology.h
> @@ -109,6 +109,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu);
>  #define topology_physical_package_id(cpu)	(cpu_data(cpu).phys_proc_id)
>  #define topology_logical_die_id(cpu)		(cpu_data(cpu).logical_die_id)
>  #define topology_die_id(cpu)			(cpu_data(cpu).cpu_die_id)
> +#define topology_cluster_id(cpu)		(per_cpu(cpu_l2c_id, cpu))
>  #define topology_core_id(cpu)			(cpu_data(cpu).cpu_core_id)
> 
>  extern unsigned int __max_die_per_package;

Thanks
Barry


From laurent.pinchart at ideasonboard.com  Tue Apr 20 23:49:36 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Wed, 21 Apr 2021 01:49:36 +0300
Subject: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC
 sub-driver
In-Reply-To: <0821533b-9e6a-237e-3845-741e82de4ed9@baylibre.com>
References: <20210416092737.1971876-1-narmstrong@baylibre.com>
 <YHlfqJIlUh7eytty@pendragon.ideasonboard.com>
 <96b9e144-0791-4c19-3e3c-b0e9efb86138@baylibre.com>
 <cbea511c-5d5c-8c59-f91f-fedc8eec1e39@xs4all.nl>
 <0821533b-9e6a-237e-3845-741e82de4ed9@baylibre.com>
Message-ID: <YH9agHwLhEL27TA1@pendragon.ideasonboard.com>

On Tue, Apr 20, 2021 at 05:19:52PM +0200, Neil Armstrong wrote:
> On 20/04/2021 17:13, Hans Verkuil wrote:
> > On 16/04/2021 13:38, Neil Armstrong wrote:
> >> On 16/04/2021 11:58, Laurent Pinchart wrote:
> >>> Hi Neil,
> >>>
> >>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> >>>> This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
> >>>>
> >>>> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
> >>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
> >>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to some
> >>>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
> >>>
> >>> If we can't trust the CEC config bit, would it be better to not use it
> >>> at all, and instead let each platform glue logic tell whether to enable
> >>> CEC or not ?
> >>
> >> Actually, the CEC config bit is right, the HW exists and should be functional, but
> >> this bit doesn't tell if the CEC signal is connected to something.
> >>
> >> This lies in the IP integration, like other bits under the "amlogic,meson-*-dw-hdmi"
> >> umbrella.
> >>
> >> The first attempt was by Hans using DT, but adding a property in DT for a vendor
> >> specific compatible doesn't make sense. Another idea would be to describe the
> >> CEC signal endpoint like we do for video signal, but I think this is out of scope and
> >> this solution is much simpler and straightforward, and it's more an exception than
> >> a general use case to solve.
> > 
> > While a DT property might not make sense in this particular case, I still
> > believe that it is a perfectly valid approach in general: whether or not
> > the CEC pin is connected is at the hardware level decision, it is not
> > something that software can detect. If the designer of the board didn't
> > connect it, then the only place you can define that is in the device tree.
> 
> Agreed, we need to define a smart way to declare CEC bus relationship in DT, the side
> effect would be to handle this particular case.

I wonder if it would make sense to use the OF graph bindings to describe
the connection between the CEC controller and the CEC "device" (which I
assume in most cases will be a DT node for a physical connector). Or is
this overkill ?

> > Anyway, for meson I am fine with this solution. At least it prevents creating
> > a non-functioning cec device. So for this series:
> > 
> > Acked-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
> 
> Thanks,
> 
> Applying this serie to drm-misc-next
> 
> >>>> Jernej Skrabec (1):
> >>>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
> >>>>     driver
> >>>>
> >>>> Neil Armstrong (1):
> >>>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
> >>>>
> >>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> >>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c     | 1 +
> >>>>  include/drm/bridge/dw_hdmi.h              | 2 ++
> >>>>  3 files changed, 4 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart


From jejb at linux.ibm.com  Wed Apr 21 00:16:56 2021
From: jejb at linux.ibm.com (James Bottomley)
Date: Tue, 20 Apr 2021 16:16:56 -0700
Subject: [PATCH v9 1/4] KEYS: trusted: Add generic trusted keys framework
In-Reply-To: <20210301131127.793707-2-sumit.garg@linaro.org>
References: <20210301131127.793707-1-sumit.garg@linaro.org>
 <20210301131127.793707-2-sumit.garg@linaro.org>
Message-ID: <65dcc9fa28833e6beb1eadf98b0ed3402404d693.camel@linux.ibm.com>

On Mon, 2021-03-01 at 18:41 +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device
> as an underlying implementation which makes it difficult for
> implementations like Trusted Execution Environment (TEE) etc. to
> provide trusted keys support in case platform doesn't posses a TPM
> device.
> 
> Add a generic trusted keys framework where underlying implementations
> can be easily plugged in. Create struct trusted_key_ops to achieve
> this, which contains necessary functions of a backend.
> 
> Also, define a module parameter in order to select a particular trust
> source in case a platform support multiple trust sources. In case its
> not specified then implementation itetrates through trust sources
> list starting with TPM and assign the first trust source as a backend
> which has initiazed successfully during iteration.
> 
> Note that current implementation only supports a single trust source
> at runtime which is either selectable at compile time or during boot
> via aforementioned module parameter.

You never actually tested this, did you?  I'm now getting EINVAL from
all the trusted TPM key operations because of this patch.

The reason is quite simple:  this function:

> index 000000000000..0db86b44605d
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_core.c
[...]
> +static int datablob_parse(char *datablob, struct trusted_key_payload
> *p)
> +{
> +	substring_t args[MAX_OPT_ARGS];
> +	long keylen;
> +	int ret = -EINVAL;
> +	int key_cmd;
> +	char *c;
> +
> +	/* main command */
> +	c = strsep(&datablob, " \t");

Modifies its argument to consume tokens and separates them with NULL.

so the arguments for

keyctl add trusted kmk "new 34 keyhandle=0x81000001"

Go into this function as

datablob="new 34 keyhandle=0x81000001"

After we leave it, it looks like

datablob="new\034\0keyhandle=0x81000001"

However here:

> +static int trusted_instantiate(struct key *key,
> +			       struct key_preparsed_payload *prep)
> +{
> +	struct trusted_key_payload *payload = NULL;
> +	size_t datalen = prep->datalen;
> +	char *datablob;
> +	int ret = 0;
> +	int key_cmd;
> +	size_t key_len;
> +
> +	if (datalen <= 0 || datalen > 32767 || !prep->data)
> +		return -EINVAL;
> +
> +	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +	if (!datablob)
> +		return -ENOMEM;
> +	memcpy(datablob, prep->data, datalen);
> +	datablob[datalen] = '\0';
> +
> +	payload = trusted_payload_alloc(key);
> +	if (!payload) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	key_cmd = datablob_parse(datablob, payload);
> +	if (key_cmd < 0) {
> +		ret = key_cmd;
> +		goto out;
> +	}
> +
> +	dump_payload(payload);
> +
> +	switch (key_cmd) {
> +	case Opt_load:
> +		ret = static_call(trusted_key_unseal)(payload,
> datablob);

We're passing the unmodified

datablob="new\034\0keyhandle=0x81000001"

Into the tpm trusted_key_unseal function.  However, it only sees "new"
and promply gives EINVAL because you've removed the ability to process
the new option from it.  What should have happened is you should have
moved data blob up to passed the consumed tokens, so it actually reads

datablob="keyhandle=0x81000001"

However, to do that you'd have to have the updated pointer passed out
of your datablob_parse() above.

There's also a lost !tpm2 in the check for options->keyhandle, but I
suspect Jarkko lost that merging the two patches.  I think what's below
fixes all of this, so if you can test it for trusted_tee, I'll package
it up as two separate patches fixing all of this.

James

---

diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index ec3a066a4b42..7c636212429b 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -62,7 +62,7 @@ static const match_table_t key_tokens = {
  *
  * On success returns 0, otherwise -EINVAL.
  */
-static int datablob_parse(char *datablob, struct trusted_key_payload *p)
+static int datablob_parse(char **datablob, struct trusted_key_payload *p)
 {
 	substring_t args[MAX_OPT_ARGS];
 	long keylen;
@@ -71,14 +71,14 @@ static int datablob_parse(char *datablob, struct trusted_key_payload *p)
 	char *c;
 
 	/* main command */
-	c = strsep(&datablob, " \t");
+	c = strsep(datablob, " \t");
 	if (!c)
 		return -EINVAL;
 	key_cmd = match_token(c, key_tokens, args);
 	switch (key_cmd) {
 	case Opt_new:
 		/* first argument is key size */
-		c = strsep(&datablob, " \t");
+		c = strsep(datablob, " \t");
 		if (!c)
 			return -EINVAL;
 		ret = kstrtol(c, 10, &keylen);
@@ -89,7 +89,7 @@ static int datablob_parse(char *datablob, struct trusted_key_payload *p)
 		break;
 	case Opt_load:
 		/* first argument is sealed blob */
-		c = strsep(&datablob, " \t");
+		c = strsep(datablob, " \t");
 		if (!c)
 			return -EINVAL;
 		p->blob_len = strlen(c) / 2;
@@ -138,7 +138,7 @@ static int trusted_instantiate(struct key *key,
 {
 	struct trusted_key_payload *payload = NULL;
 	size_t datalen = prep->datalen;
-	char *datablob;
+	char *datablob, *orig_datablob;
 	int ret = 0;
 	int key_cmd;
 	size_t key_len;
@@ -146,7 +146,7 @@ static int trusted_instantiate(struct key *key,
 	if (datalen <= 0 || datalen > 32767 || !prep->data)
 		return -EINVAL;
 
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	orig_datablob = datablob = kmalloc(datalen + 1, GFP_KERNEL);
 	if (!datablob)
 		return -ENOMEM;
 	memcpy(datablob, prep->data, datalen);
@@ -158,7 +158,7 @@ static int trusted_instantiate(struct key *key,
 		goto out;
 	}
 
-	key_cmd = datablob_parse(datablob, payload);
+	key_cmd = datablob_parse(&datablob, payload);
 	if (key_cmd < 0) {
 		ret = key_cmd;
 		goto out;
@@ -194,7 +194,7 @@ static int trusted_instantiate(struct key *key,
 		ret = -EINVAL;
 	}
 out:
-	kfree_sensitive(datablob);
+	kfree_sensitive(orig_datablob);
 	if (!ret)
 		rcu_assign_keypointer(key, payload);
 	else
@@ -218,7 +218,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 	struct trusted_key_payload *p;
 	struct trusted_key_payload *new_p;
 	size_t datalen = prep->datalen;
-	char *datablob;
+	char *datablob, *orig_datablob;
 	int ret = 0;
 
 	if (key_is_negative(key))
@@ -229,7 +229,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 	if (datalen <= 0 || datalen > 32767 || !prep->data)
 		return -EINVAL;
 
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	orig_datablob = datablob = kmalloc(datalen + 1, GFP_KERNEL);
 	if (!datablob)
 		return -ENOMEM;
 
@@ -241,7 +241,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 
 	memcpy(datablob, prep->data, datalen);
 	datablob[datalen] = '\0';
-	ret = datablob_parse(datablob, new_p);
+	ret = datablob_parse(&datablob, new_p);
 	if (ret != Opt_update) {
 		ret = -EINVAL;
 		kfree_sensitive(new_p);
@@ -265,7 +265,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
 	rcu_assign_keypointer(key, new_p);
 	call_rcu(&p->rcu, trusted_rcu_free);
 out:
-	kfree_sensitive(datablob);
+	kfree_sensitive(orig_datablob);
 	return ret;
 }
 
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 4e5c50138f92..bc702ba0a596 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -747,6 +747,9 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
 
 	opt->hash = tpm2 ? HASH_ALGO_SHA256 : HASH_ALGO_SHA1;
 
+	if (!c)
+		return 0;
+
 	while ((p = strsep(&c, " \t"))) {
 		if (*p == '\0' || *p == ' ' || *p == '\t')
 			continue;
@@ -944,7 +947,7 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
 		goto out;
 	dump_options(options);
 
-	if (!options->keyhandle) {
+	if (!options->keyhandle && !tpm2) {
 		ret = -EINVAL;
 		goto out;
 	}




From chunkuang.hu at kernel.org  Wed Apr 21 00:46:52 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Wed, 21 Apr 2021 07:46:52 +0800
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
In-Reply-To: <CAJMQK-gFk8WV0W2TTP7=OTsBqgWmy_eKSd42Xa5dJzvUFDTAXQ@mail.gmail.com>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
 <CAJMQK-gFk8WV0W2TTP7=OTsBqgWmy_eKSd42Xa5dJzvUFDTAXQ@mail.gmail.com>
Message-ID: <CAAOTY_9pJ=H4gQKsC1VeHo6Z4qsHFzOe267QVu6p_Jid0AXsKQ@mail.gmail.com>

Hi, Hsin-Yi:

Hsin-Yi Wang <hsinyi at chromium.org> ? 2021?4?20? ?? ??5:05???
>
> On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning. So set panel orientation in dsi before drm_dev_register() is
> > called.

All connector would have this problem, so I would like to fix this in
common code.
In drm_connector_init(), you could add "panel orientation" property
with value DRM_MODE_PANEL_ORIENTATION_UNKNOWN, so it would not add new
object when get modes.

Regards,
Chun-Kuang.

> >
> > [    4.480976] ------------[ cut here ]------------
> > [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> > <snip>
> > [    4.609772] Call trace:
> > [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> > [    4.616466]  drm_mode_object_add+0x20/0x2c
> > [    4.620552]  drm_property_create+0xdc/0x174
> > [    4.624723]  drm_property_create_enum+0x34/0x98
> > [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> > [    4.634716]  boe_panel_get_modes+0x88/0xd8
> > [    4.638802]  drm_panel_get_modes+0x2c/0x48
> > [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> > [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.662699]  drm_ioctl_kernel+0xac/0x128
> > [    4.666611]  drm_ioctl+0x268/0x410
> > [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> > [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.678436]  el0_svc_common+0xf4/0x1c0
> > [    4.682174]  do_el0_svc_compat+0x28/0x3c
> > [    4.686088]  el0_svc_compat+0x10/0x1c
> > [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.694171]  el0_sync_compat+0x178/0x180
> > [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> > [    4.702721] ------------[ cut here ]------------
> > [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> > <snip>
> > [    4.833830] Call trace:
> > [    4.836266]  drm_object_attach_property+0x48/0xb8
> > [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> > [    4.846432]  boe_panel_get_modes+0x88/0xd8
> > [    4.850516]  drm_panel_get_modes+0x2c/0x48
> > [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> > [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.874410]  drm_ioctl_kernel+0xac/0x128
> > [    4.878320]  drm_ioctl+0x268/0x410
> > [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> > [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.890142]  el0_svc_common+0xf4/0x1c0
> > [    4.893879]  do_el0_svc_compat+0x28/0x3c
> > [    4.897791]  el0_svc_compat+0x10/0x1c
> > [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.905873]  el0_sync_compat+0x178/0x180
> > [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
>
> ping on the thread, thanks.
>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index ae403c67cbd9..45a702ee09f3 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -205,6 +205,7 @@ struct mtk_dsi {
> >         u32 irq_data;
> >         wait_queue_head_t irq_wait_queue;
> >         const struct mtk_dsi_driver_data *driver_data;
> > +       enum drm_panel_orientation orientation;
> >  };
> >
> >  static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> > @@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> >         }
> >         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> >
> > +       drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
> > +
> >         return 0;
> >
> >  err_cleanup_encoder:
> > @@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> >                         ret = PTR_ERR(dsi->next_bridge);
> >                         goto err_unregister_host;
> >                 }
> > +
> > +               ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
> > +               if (ret) {
> > +                       dev_err(dev, "failed to get panel orientation %d\n", ret);
> > +                       return ret;
> > +               }
> >         }
> >
> >         dsi->driver_data = of_device_get_match_data(dev);
> > --
> > 2.31.1.295.g9ea45b61b8-goog
> >


From drinkcat at chromium.org  Wed Apr 21 01:03:10 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:03:10 +0800
Subject: [PATCH v11 2/4] arm64: dts: mt8183: Add node for the Mali GPU
In-Reply-To: <1a37f9be-8ec8-893a-e2fc-f0739948f71f@baylibre.com>
References: <20210126011759.1605641-1-drinkcat@chromium.org>
 <20210126091747.v11.2.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid>
 <1a37f9be-8ec8-893a-e2fc-f0739948f71f@baylibre.com>
Message-ID: <CANMq1KBMXyYsjmaoVa+qb1TiSTm5ZqViqno36hJk0hNAUr4pmA@mail.gmail.com>

On Tue, Apr 20, 2021 at 11:33 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
>
> On 26/01/2021 02:17, Nicolas Boichat wrote:
> > Add a basic GPU node for mt8183.
> >
> > Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> > ---
> > The binding we use with out-of-tree Mali drivers includes more
> > clocks, this is used for devfreq: the out-of-tree driver switches
> > clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
> > switches clk_mux back to clk_main_parent:
> > (see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
> > clocks =
> >         <&topckgen CLK_TOP_MFGPLL_CK>,
> >         <&topckgen CLK_TOP_MUX_MFG>,
> >         <&clk26m>,
> >         <&mfgcfg CLK_MFG_BG3D>;
> > clock-names =
> >         "clk_main_parent",
> >         "clk_mux",
> >         "clk_sub_parent",
> >         "subsys_mfg_cg";
> > (based on discussions, this probably belongs in the clock core)
> >
> > This only matters for devfreq, that is disabled anyway as we don't
> > have platform-specific code to handle >1 supplies.
> >
> > Changes in v11:
> >  - mt8183*.dts: remove incorrect supply-names
> >
> > Changes in v10: None
> > Changes in v9: None
> > Changes in v8: None
> > Changes in v7: None
> > Changes in v6:
> >  - Add gpu regulators to kukui dtsi as well.
> >  - Power domains are now attached to spm, not scpsys
> >  - Drop R-B.
> >
> > Changes in v5:
> >  - Rename "2d" power domain to "core2" (keep R-B again).
> >
> > Changes in v4:
> >  - Add power-domain-names to describe the 3 domains.
> >    (kept Alyssa's reviewed-by as the change is minor)
> >
> > Changes in v3: None
> > Changes in v2:
> >  - Use sram instead of mali_sram as SRAM supply name.
> >  - Rename mali@ to gpu at .
> >
> >  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
> >  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
> >  arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
> >  3 files changed, 115 insertions(+)
> >
>
> If you re-spin, you can also add the same changes to mt8183-pumpkin.dts :

Will do in v12.

> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> index eb6e595c2975..cc23e5df391e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> @@ -68,6 +68,11 @@ &auxadc {
>         status = "okay";
>  };
>
> +&gpu {
> +       mali-supply = <&mt6358_vgpu_reg>;
> +       sram-supply = <&mt6358_vsram_gpu_reg>;
> +};
> +
>  &i2c0 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&i2c_pins_0>;
>
> I did a boot-test of the platform with panfrost and drm-misc-next and it worked fine.

Great news thanks!

>
> Thanks,
> Neil
>
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > index cba2d8933e79..1cfbea5a0101 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> > @@ -42,6 +42,11 @@ &auxadc {
> >       status = "okay";
> >  };
> >
> > +&gpu {
> > +     mali-supply = <&mt6358_vgpu_reg>;
> > +     sram-supply = <&mt6358_vsram_gpu_reg>;
> > +};
> > +
> >  &i2c0 {
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&i2c_pins_0>;
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > index bf2ad1294dd3..a38315b604df 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > @@ -249,6 +249,11 @@ &cpu7 {
> >       proc-supply = <&mt6358_vproc11_reg>;
> >  };
> >
> > +&gpu {
> > +     mali-supply = <&mt6358_vgpu_reg>;
> > +     sram-supply = <&mt6358_vsram_gpu_reg>;
> > +};
> > +
> >  &i2c0 {
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&i2c0_pins>;
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index 5b782a4769e7..5430e05e18a0 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -964,6 +964,111 @@ mfgcfg: syscon at 13000000 {
> >                       #clock-cells = <1>;
> >               };
> >
> > +             gpu: gpu at 13040000 {
> > +                     compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
> > +                     reg = <0 0x13040000 0 0x4000>;
> > +                     interrupts =
> > +                             <GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
> > +                             <GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
> > +                             <GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
> > +                     interrupt-names = "job", "mmu", "gpu";
> > +
> > +                     clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
> > +
> > +                     power-domains =
> > +                             <&spm MT8183_POWER_DOMAIN_MFG_CORE0>,
> > +                             <&spm MT8183_POWER_DOMAIN_MFG_CORE1>,
> > +                             <&spm MT8183_POWER_DOMAIN_MFG_2D>;
> > +                     power-domain-names = "core0", "core1", "core2";
> > +
> > +                     operating-points-v2 = <&gpu_opp_table>;
> > +             };
> > +
> > +             gpu_opp_table: opp_table0 {
> > +                     compatible = "operating-points-v2";
> > +                     opp-shared;
> > +
> > +                     opp-300000000 {
> > +                             opp-hz = /bits/ 64 <300000000>;
> > +                             opp-microvolt = <625000>, <850000>;
> > +                     };
> > +
> > +                     opp-320000000 {
> > +                             opp-hz = /bits/ 64 <320000000>;
> > +                             opp-microvolt = <631250>, <850000>;
> > +                     };
> > +
> > +                     opp-340000000 {
> > +                             opp-hz = /bits/ 64 <340000000>;
> > +                             opp-microvolt = <637500>, <850000>;
> > +                     };
> > +
> > +                     opp-360000000 {
> > +                             opp-hz = /bits/ 64 <360000000>;
> > +                             opp-microvolt = <643750>, <850000>;
> > +                     };
> > +
> > +                     opp-380000000 {
> > +                             opp-hz = /bits/ 64 <380000000>;
> > +                             opp-microvolt = <650000>, <850000>;
> > +                     };
> > +
> > +                     opp-400000000 {
> > +                             opp-hz = /bits/ 64 <400000000>;
> > +                             opp-microvolt = <656250>, <850000>;
> > +                     };
> > +
> > +                     opp-420000000 {
> > +                             opp-hz = /bits/ 64 <420000000>;
> > +                             opp-microvolt = <662500>, <850000>;
> > +                     };
> > +
> > +                     opp-460000000 {
> > +                             opp-hz = /bits/ 64 <460000000>;
> > +                             opp-microvolt = <675000>, <850000>;
> > +                     };
> > +
> > +                     opp-500000000 {
> > +                             opp-hz = /bits/ 64 <500000000>;
> > +                             opp-microvolt = <687500>, <850000>;
> > +                     };
> > +
> > +                     opp-540000000 {
> > +                             opp-hz = /bits/ 64 <540000000>;
> > +                             opp-microvolt = <700000>, <850000>;
> > +                     };
> > +
> > +                     opp-580000000 {
> > +                             opp-hz = /bits/ 64 <580000000>;
> > +                             opp-microvolt = <712500>, <850000>;
> > +                     };
> > +
> > +                     opp-620000000 {
> > +                             opp-hz = /bits/ 64 <620000000>;
> > +                             opp-microvolt = <725000>, <850000>;
> > +                     };
> > +
> > +                     opp-653000000 {
> > +                             opp-hz = /bits/ 64 <653000000>;
> > +                             opp-microvolt = <743750>, <850000>;
> > +                     };
> > +
> > +                     opp-698000000 {
> > +                             opp-hz = /bits/ 64 <698000000>;
> > +                             opp-microvolt = <768750>, <868750>;
> > +                     };
> > +
> > +                     opp-743000000 {
> > +                             opp-hz = /bits/ 64 <743000000>;
> > +                             opp-microvolt = <793750>, <893750>;
> > +                     };
> > +
> > +                     opp-800000000 {
> > +                             opp-hz = /bits/ 64 <800000000>;
> > +                             opp-microvolt = <825000>, <925000>;
> > +                     };
> > +             };
> > +
> >               mmsys: syscon at 14000000 {
> >                       compatible = "mediatek,mt8183-mmsys", "syscon";
> >                       reg = <0 0x14000000 0 0x1000>;
> >
>


From drinkcat at chromium.org  Wed Apr 21 01:11:24 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:11:24 +0800
Subject: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek
 MT8183
In-Reply-To: <CAL_Jsq+gWm+94zF1XN2KiRYgAZewiDkCk5B5bhLB=M+-HbD=fA@mail.gmail.com>
References: <20210126011759.1605641-1-drinkcat@chromium.org>
 <20210126091747.v11.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
 <CAL_Jsq+gWm+94zF1XN2KiRYgAZewiDkCk5B5bhLB=M+-HbD=fA@mail.gmail.com>
Message-ID: <CANMq1KCNMx4hS02ZFd0NSOwvw3Xaqm13v8aHO6UMP5Nn3_uX-Q@mail.gmail.com>

On Tue, Apr 20, 2021 at 9:01 PM Rob Herring <robh at kernel.org> wrote:
>
> On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat <drinkcat at chromium.org> wrote:
> >
> > Define a compatible string for the Mali Bifrost GPU found in
> > Mediatek's MT8183 SoCs.
> >
> > Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> > ---
> >
> > Changes in v11:
> >  - binding: power-domain-names not power-domainS-names
> >
> > Changes in v10:
> >  - Fix the binding to make sure sram-supply property can be provided.
> >
> > Changes in v9: None
> > Changes in v8: None
> > Changes in v7: None
> > Changes in v6:
> >  - Rebased, actually tested with recent mesa driver.
> >
> > Changes in v5:
> >  - Rename "2d" power domain to "core2"
> >
> > Changes in v4:
> >  - Add power-domain-names description
> >    (kept Alyssa's reviewed-by as the change is minor)
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> >  .../bindings/gpu/arm,mali-bifrost.yaml        | 28 +++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > index 184492162e7e..3e758f88e2cd 100644
> > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > @@ -17,6 +17,7 @@ properties:
> >      items:
> >        - enum:
> >            - amlogic,meson-g12a-mali
> > +          - mediatek,mt8183-mali
> >            - realtek,rtd1619-mali
> >            - rockchip,px30-mali
> >        - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
> > @@ -41,6 +42,8 @@ properties:
> >
> >    mali-supply: true
> >
> > +  sram-supply: true
> > +
> >    operating-points-v2: true
> >
> >    power-domains:
> > @@ -87,6 +90,31 @@ allOf:
> >      then:
> >        required:
> >          - resets
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: mediatek,mt8183-mali
> > +    then:
> > +      properties:
> > +        power-domains:
> > +          description:
> > +            List of phandle and PM domain specifier as documented in
> > +            Documentation/devicetree/bindings/power/power_domain.txt
> > +          minItems: 3
> > +          maxItems: 3
>
> This won't work because the top level schema restricts this to 1. The
> top level needs to say:
>
> power-domains:
>   minItems: 1
>   maxItems: 3
>
> And you need just 'minItems: 3' here and 'maxItems: 1' in the else clause.
>
> And drop the description. That's every 'power-domains' property.
>
> > +        power-domain-names:
> > +          items:
> > +            - const: core0
> > +            - const: core1
> > +            - const: core2
>
> Blank line

Thanks, hopefully all fixed in v12.

> > +      required:
> > +        - sram-supply
> > +        - power-domains
> > +        - power-domain-names
> > +    else:
> > +      properties:
> > +        sram-supply: false
> >
> >  examples:
> >    - |
> > --
> > 2.30.0.280.ga3ce27912f-goog
> >


From drinkcat at chromium.org  Wed Apr 21 01:19:04 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:19:04 +0800
Subject: [PATCH v12 0/4] drm/panfrost: Add support for mt8183 GPU
Message-ID: <20210421001908.813625-1-drinkcat@chromium.org>

Hi!

This is just a rebase of the v11, untested (but it seems like
Neil Armstrong recently tested it), with small changes in
binding and dts. v11 cover follows:

Follow-up on the v5 [1], things have gotten significantly
better in the last year, thanks to the efforts on Bifrost
support by the Collabora team (and probably others I'm not
aware of).

I've been testing this series on a MT8183/kukui device, with a
chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
mesa 20.3.2 (lots of artifacts though).

devfreq is currently not supported, as we'll need:
 - Clock core support for switching the GPU core clock (see 2/4).
 - Platform-specific handling of the 2-regulator (see 3/4).

Since the latter is easy to detect, patch 3/4 just disables
devfreq if the more than one regulator is specified in the
compatible matching table.

[1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drinkcat at chromium.org/
[2] https://crrev.com/c/2608070

Changes in v12:
 - binding: Fix min/maxItems logic (Rob Herring)
 - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).

Changes in v11:
 - binding: power-domain-names not power-domainS-names
 - mt8183*.dts: remove incorrect supply-names

Changes in v10:
 - Fix the binding to make sure sram-supply property can be provided.

Changes in v9:
 - Explain why devfreq needs to be disabled for GPUs with >1
   regulators.

Changes in v8:
 - Use DRM_DEV_INFO instead of ERROR

Changes in v7:
 - Fix GPU ID in commit message
 - Fix GPU ID in commit message

Changes in v6:
 - Rebased, actually tested with recent mesa driver.
 - Add gpu regulators to kukui dtsi as well.
 - Power domains are now attached to spm, not scpsys
 - Drop R-B.
 - devfreq: New change
 - Context conflicts, reflow the code.
 - Use ARRAY_SIZE for power domains too.

Changes in v5:
 - Rename "2d" power domain to "core2"
 - Rename "2d" power domain to "core2" (keep R-B again).
 - Change power domain name from 2d to core2.

Changes in v4:
 - Add power-domain-names description
   (kept Alyssa's reviewed-by as the change is minor)
 - Add power-domain-names to describe the 3 domains.
   (kept Alyssa's reviewed-by as the change is minor)
 - Add power domain names.

Changes in v3:
 - Match mt8183-mali instead of bifrost, as we require special
   handling for the 2 regulators and 3 power domains.

Changes in v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu at .

Nicolas Boichat (4):
  dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
  arm64: dts: mt8183: Add node for the Mali GPU
  drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
  drm/panfrost: Add mt8183-mali compatible string

 .../bindings/gpu/arm,mali-bifrost.yaml        |  30 ++++-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
 .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
 .../boot/dts/mediatek/mt8183-pumpkin.dts      |   5 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
 drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  16 ++-
 drivers/gpu/drm/panfrost/panfrost_drv.c       |  10 ++
 7 files changed, 172 insertions(+), 4 deletions(-)

-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 01:19:05 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:19:05 +0800
Subject: [PATCH v12 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
In-Reply-To: <20210421001908.813625-1-drinkcat@chromium.org>
References: <20210421001908.813625-1-drinkcat@chromium.org>
Message-ID: <20210421081831.v12.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>

Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
---

Changes in v12:
 - binding: Fix min/maxItems logic (Rob Herring)

Changes in v11:
 - binding: power-domain-names not power-domainS-names

Changes in v10:
 - Fix the binding to make sure sram-supply property can be provided.

Changes in v6:
 - Rebased, actually tested with recent mesa driver.

Changes in v5:
 - Rename "2d" power domain to "core2"

Changes in v4:
 - Add power-domain-names description
   (kept Alyssa's reviewed-by as the change is minor)

 .../bindings/gpu/arm,mali-bifrost.yaml        | 30 ++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 184492162e7e..b22cd8f1b015 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -17,6 +17,7 @@ properties:
     items:
       - enum:
           - amlogic,meson-g12a-mali
+          - mediatek,mt8183-mali
           - realtek,rtd1619-mali
           - rockchip,px30-mali
       - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
@@ -41,10 +42,13 @@ properties:
 
   mali-supply: true
 
+  sram-supply: true
+
   operating-points-v2: true
 
   power-domains:
-    maxItems: 1
+    minItems: 1
+    maxItems: 3
 
   resets:
     maxItems: 2
@@ -87,6 +91,30 @@ allOf:
     then:
       required:
         - resets
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8183-mali
+    then:
+      properties:
+        power-domains:
+          minItems: 3
+        power-domain-names:
+          items:
+            - const: core0
+            - const: core1
+            - const: core2
+
+      required:
+        - sram-supply
+        - power-domains
+        - power-domain-names
+    else:
+      properties:
+        power-domains:
+          maxItems: 1
+        sram-supply: false
 
 examples:
   - |
-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 01:19:06 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:19:06 +0800
Subject: [PATCH v12 2/4] arm64: dts: mt8183: Add node for the Mali GPU
In-Reply-To: <20210421001908.813625-1-drinkcat@chromium.org>
References: <20210421001908.813625-1-drinkcat@chromium.org>
Message-ID: <20210421081831.v12.2.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid>

Add a basic GPU node for mt8183.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
---
The binding we use with out-of-tree Mali drivers includes more
clocks, this is used for devfreq: the out-of-tree driver switches
clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
switches clk_mux back to clk_main_parent:
(see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
clocks =
        <&topckgen CLK_TOP_MFGPLL_CK>,
        <&topckgen CLK_TOP_MUX_MFG>,
        <&clk26m>,
        <&mfgcfg CLK_MFG_BG3D>;
clock-names =
        "clk_main_parent",
        "clk_mux",
        "clk_sub_parent",
        "subsys_mfg_cg";
(based on discussions, this probably belongs in the clock core)

This only matters for devfreq, that is disabled anyway as we don't
have platform-specific code to handle >1 supplies.

Changes in v12:
 - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).

Changes in v11:
 - mt8183*.dts: remove incorrect supply-names

Changes in v6:
 - Add gpu regulators to kukui dtsi as well.
 - Power domains are now attached to spm, not scpsys
 - Drop R-B.

Changes in v5:
 - Rename "2d" power domain to "core2" (keep R-B again).

Changes in v4:
 - Add power-domain-names to describe the 3 domains.
   (kept Alyssa's reviewed-by as the change is minor)

Changes in v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu at .

 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
 .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
 .../boot/dts/mediatek/mt8183-pumpkin.dts      |   5 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
 4 files changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index edff1e03e6fe..7bc0a6a7fadf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -42,6 +42,11 @@ &auxadc {
 	status = "okay";
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index ff56bcfa3370..e4e54be1c2b2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -279,6 +279,11 @@ dsi_out: endpoint {
 	};
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index 0aff5eb52e88..ee912825cfc6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -68,6 +68,11 @@ &auxadc {
 	status = "okay";
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c5e822b6b77a..c75fdeea8aa4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1118,6 +1118,111 @@ mfgcfg: syscon at 13000000 {
 			#clock-cells = <1>;
 		};
 
+		gpu: gpu at 13040000 {
+			compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+			reg = <0 0x13040000 0 0x4000>;
+			interrupts =
+				<GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-names = "job", "mmu", "gpu";
+
+			clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
+
+			power-domains =
+				<&spm MT8183_POWER_DOMAIN_MFG_CORE0>,
+				<&spm MT8183_POWER_DOMAIN_MFG_CORE1>,
+				<&spm MT8183_POWER_DOMAIN_MFG_2D>;
+			power-domain-names = "core0", "core1", "core2";
+
+			operating-points-v2 = <&gpu_opp_table>;
+		};
+
+		gpu_opp_table: opp_table0 {
+			compatible = "operating-points-v2";
+			opp-shared;
+
+			opp-300000000 {
+				opp-hz = /bits/ 64 <300000000>;
+				opp-microvolt = <625000>, <850000>;
+			};
+
+			opp-320000000 {
+				opp-hz = /bits/ 64 <320000000>;
+				opp-microvolt = <631250>, <850000>;
+			};
+
+			opp-340000000 {
+				opp-hz = /bits/ 64 <340000000>;
+				opp-microvolt = <637500>, <850000>;
+			};
+
+			opp-360000000 {
+				opp-hz = /bits/ 64 <360000000>;
+				opp-microvolt = <643750>, <850000>;
+			};
+
+			opp-380000000 {
+				opp-hz = /bits/ 64 <380000000>;
+				opp-microvolt = <650000>, <850000>;
+			};
+
+			opp-400000000 {
+				opp-hz = /bits/ 64 <400000000>;
+				opp-microvolt = <656250>, <850000>;
+			};
+
+			opp-420000000 {
+				opp-hz = /bits/ 64 <420000000>;
+				opp-microvolt = <662500>, <850000>;
+			};
+
+			opp-460000000 {
+				opp-hz = /bits/ 64 <460000000>;
+				opp-microvolt = <675000>, <850000>;
+			};
+
+			opp-500000000 {
+				opp-hz = /bits/ 64 <500000000>;
+				opp-microvolt = <687500>, <850000>;
+			};
+
+			opp-540000000 {
+				opp-hz = /bits/ 64 <540000000>;
+				opp-microvolt = <700000>, <850000>;
+			};
+
+			opp-580000000 {
+				opp-hz = /bits/ 64 <580000000>;
+				opp-microvolt = <712500>, <850000>;
+			};
+
+			opp-620000000 {
+				opp-hz = /bits/ 64 <620000000>;
+				opp-microvolt = <725000>, <850000>;
+			};
+
+			opp-653000000 {
+				opp-hz = /bits/ 64 <653000000>;
+				opp-microvolt = <743750>, <850000>;
+			};
+
+			opp-698000000 {
+				opp-hz = /bits/ 64 <698000000>;
+				opp-microvolt = <768750>, <868750>;
+			};
+
+			opp-743000000 {
+				opp-hz = /bits/ 64 <743000000>;
+				opp-microvolt = <793750>, <893750>;
+			};
+
+			opp-800000000 {
+				opp-hz = /bits/ 64 <800000000>;
+				opp-microvolt = <825000>, <925000>;
+			};
+		};
+
 		mmsys: syscon at 14000000 {
 			compatible = "mediatek,mt8183-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 01:19:08 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 08:19:08 +0800
Subject: [PATCH v12 4/4] drm/panfrost: Add mt8183-mali compatible string
In-Reply-To: <20210421001908.813625-1-drinkcat@chromium.org>
References: <20210421001908.813625-1-drinkcat@chromium.org>
Message-ID: <20210421081831.v12.4.I5f6b04431828ec9c3e41e65f3337cec6a127480d@changeid>

Add support for MT8183's G72 Bifrost.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
Reviewed-by: Steven Price <steven.price at arm.com>
---

(no changes since v7)

Changes in v7:
 - Fix GPU ID in commit message

Changes in v6:
 - Context conflicts, reflow the code.
 - Use ARRAY_SIZE for power domains too.

Changes in v5:
 - Change power domain name from 2d to core2.

Changes in v4:
 - Add power domain names.

Changes in v3:
 - Match mt8183-mali instead of bifrost, as we require special
   handling for the 2 regulators and 3 power domains.

 drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
 	.vendor_quirk = panfrost_gpu_amlogic_quirk,
 };
 
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" };
+static const struct panfrost_compatible mediatek_mt8183_data = {
+	.num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+	.supply_names = mediatek_mt8183_supplies,
+	.num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+	.pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
 static const struct of_device_id dt_match[] = {
 	/* Set first to probe before the generic compatibles */
 	{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
 	{ .compatible = "arm,mali-t860", .data = &default_data, },
 	{ .compatible = "arm,mali-t880", .data = &default_data, },
 	{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+	{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
2.31.1.368.gbe11c130af-goog



From hsinyi at chromium.org  Wed Apr 21 02:56:07 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 09:56:07 +0800
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
In-Reply-To: <CAAOTY_9pJ=H4gQKsC1VeHo6Z4qsHFzOe267QVu6p_Jid0AXsKQ@mail.gmail.com>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
 <CAJMQK-gFk8WV0W2TTP7=OTsBqgWmy_eKSd42Xa5dJzvUFDTAXQ@mail.gmail.com>
 <CAAOTY_9pJ=H4gQKsC1VeHo6Z4qsHFzOe267QVu6p_Jid0AXsKQ@mail.gmail.com>
Message-ID: <CAJMQK-i8aZWmKyJ=7Gf8Wee3MynnqVvpijTOxqKp9M0vyECcPQ@mail.gmail.com>

On Wed, Apr 21, 2021 at 7:47 AM Chun-Kuang Hu <chunkuang.hu at kernel.org> wrote:
>
> Hi, Hsin-Yi:
>
> Hsin-Yi Wang <hsinyi at chromium.org> ? 2021?4?20? ?? ??5:05???
> >
> > On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> > >
> > > drm_dev_register() sets connector->registration_state to
> > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > > drm_connector_set_panel_orientation() is first called after
> > > drm_dev_register(), it will fail several checks and results in following
> > > warning. So set panel orientation in dsi before drm_dev_register() is
> > > called.
>
> All connector would have this problem, so I would like to fix this in
> common code.
> In drm_connector_init(), you could add "panel orientation" property
> with value DRM_MODE_PANEL_ORIENTATION_UNKNOWN, so it would not add new
> object when get modes.

Hi CK,

Calling drm_connector_set_panel_orientation() with
DRM_MODE_PANEL_ORIENTATION_UNKNOWN will be a no-op. And once the
orientation is set, the 2nd call to this is also no-op.
https://elixir.bootlin.com/linux/v5.12-rc8/source/drivers/gpu/drm/drm_connector.c#L2182

The 1st time call to drm_connector_set_panel_orientation() has to be
prior than drm_dev_register().

Orientation is an optional property, and different dsi has different
ways to read and handle this. Eg. vlv_dsi[1], intel_dp[2], so I think
it's better to let each connector decide how to handle orientation.

[1] https://elixir.bootlin.com/linux/v5.12-rc8/source/drivers/gpu/drm/i915/display/vlv_dsi.c#L1632
[2] https://elixir.bootlin.com/linux/v5.12-rc8/source/drivers/gpu/drm/i915/display/intel_dp.c#L6488

Thanks
>
> Regards,
> Chun-Kuang.
>
> > >
> > > [    4.480976] ------------[ cut here ]------------
> > > [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> > > <snip>
> > > [    4.609772] Call trace:
> > > [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> > > [    4.616466]  drm_mode_object_add+0x20/0x2c
> > > [    4.620552]  drm_property_create+0xdc/0x174
> > > [    4.624723]  drm_property_create_enum+0x34/0x98
> > > [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> > > [    4.634716]  boe_panel_get_modes+0x88/0xd8
> > > [    4.638802]  drm_panel_get_modes+0x2c/0x48
> > > [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> > > [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> > > [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> > > [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> > > [    4.662699]  drm_ioctl_kernel+0xac/0x128
> > > [    4.666611]  drm_ioctl+0x268/0x410
> > > [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> > > [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> > > [    4.678436]  el0_svc_common+0xf4/0x1c0
> > > [    4.682174]  do_el0_svc_compat+0x28/0x3c
> > > [    4.686088]  el0_svc_compat+0x10/0x1c
> > > [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> > > [    4.694171]  el0_sync_compat+0x178/0x180
> > > [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> > > [    4.702721] ------------[ cut here ]------------
> > > [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> > > <snip>
> > > [    4.833830] Call trace:
> > > [    4.836266]  drm_object_attach_property+0x48/0xb8
> > > [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> > > [    4.846432]  boe_panel_get_modes+0x88/0xd8
> > > [    4.850516]  drm_panel_get_modes+0x2c/0x48
> > > [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> > > [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> > > [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> > > [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> > > [    4.874410]  drm_ioctl_kernel+0xac/0x128
> > > [    4.878320]  drm_ioctl+0x268/0x410
> > > [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> > > [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> > > [    4.890142]  el0_svc_common+0xf4/0x1c0
> > > [    4.893879]  do_el0_svc_compat+0x28/0x3c
> > > [    4.897791]  el0_svc_compat+0x10/0x1c
> > > [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> > > [    4.905873]  el0_sync_compat+0x178/0x180
> > > [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
> > >
> > > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> >
> > ping on the thread, thanks.
> >
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > index ae403c67cbd9..45a702ee09f3 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > @@ -205,6 +205,7 @@ struct mtk_dsi {
> > >         u32 irq_data;
> > >         wait_queue_head_t irq_wait_queue;
> > >         const struct mtk_dsi_driver_data *driver_data;
> > > +       enum drm_panel_orientation orientation;
> > >  };
> > >
> > >  static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> > > @@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> > >         }
> > >         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> > >
> > > +       drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
> > > +
> > >         return 0;
> > >
> > >  err_cleanup_encoder:
> > > @@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> > >                         ret = PTR_ERR(dsi->next_bridge);
> > >                         goto err_unregister_host;
> > >                 }
> > > +
> > > +               ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
> > > +               if (ret) {
> > > +                       dev_err(dev, "failed to get panel orientation %d\n", ret);
> > > +                       return ret;
> > > +               }
> > >         }
> > >
> > >         dsi->driver_data = of_device_get_match_data(dev);
> > > --
> > > 2.31.1.295.g9ea45b61b8-goog
> > >


From jiapeng.chong at linux.alibaba.com  Wed Apr 21 03:06:43 2021
From: jiapeng.chong at linux.alibaba.com (=?UTF-8?B?56eN5ZiJ6bmP?=)
Date: Wed, 21 Apr 2021 10:06:43 +0800
Subject: [PATCH] usb: gadget: aspeed: Remove unnecessary version.h includes
In-Reply-To: <YGvxAmHIgnRMcyuq@kroah.com>
References: <1617681598-28165-1-git-send-email-jiapeng.chong@linux.alibaba.com>
 <YGvxAmHIgnRMcyuq@kroah.com>
Message-ID: <971ce789-9633-1799-6c55-50b79f2f179e@linux.alibaba.com>

On 2021/4/6 13:26, Greg KH wrote:
> On Tue, Apr 06, 2021 at 11:59:58AM +0800, Jiapeng Chong wrote:
>> "make versioncheck" shows:
>>
>> ./drivers/usb/gadget/udc/aspeed-vhub/hub.c: 33 linux/version.h not
>> needed.
> 
> Then you need to fix the tool, and always test-build patches before you
> send them out, as this is obviously wrong :(
> 
Sorry for the noise. We'll do more test-build towards patches next time.



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:14 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:14 +0800
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
Message-ID: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

V5:
 Add R-b tag
 Move the change in detect mode of patch 5 to patch 7 Per Mathieu's
 comments

V4:
 Typo fix
 patch 4: take state as a check condition
 patch 5: move regmap lookup/attach to imx_rproc_detect_mode
 patch 6: add imx_rproc_clk_enable for optional clk
 patch 8: use switch/case in imx_rproc_detect_mode
V3:
 Add A-b tag for Patch 1/2
 Fix the checkpatch warning for Patch 6,8

V2:
 Patch 1/8, use fsl as vendor, typo fix
 Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that
 change.

This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
parse fsl,auto-boot

Peng Fan (8):
  dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
  dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
  dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
  remoteproc: imx_rproc: parse fsl,auto-boot
  remoteproc: imx_rproc: initial support for mutilple start/stop method
  remoteproc: imx_rproc: make clk optional
  remoteproc: imx_rproc: support i.MX7ULP
  remoteproc: imx_rproc: support i.MX8MN/P

 .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
 drivers/remoteproc/imx_rproc.c                | 196 +++++++++++++++---
 2 files changed, 173 insertions(+), 34 deletions(-)

-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:15 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:15 +0800
Subject: [PATCH V5 1/8] dt-bindings: remoteproc: imx_rproc: add fsl,
 auto-boot property
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-2-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add an optional property "fsl,auto-boot" to indicate remote processor
auto boot.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml       | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 208a628f8d6c..b13bf8d70488 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -49,6 +49,12 @@ properties:
     minItems: 1
     maxItems: 32
 
+  fsl,auto-boot:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      Indicate whether need to load the default firmware and start the remote
+      processor automatically.
+
 required:
   - compatible
   - clocks
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:16 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:16 +0800
Subject: [PATCH V5 2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
 support
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-3-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX7ULP compatible.

We use i.MX7ULP dual mode and in which case i.MX7ULP A7 core runs under
control of M4 core, M4 core starts by ROM and powers most services used
by A7 core, so A7 core has no power to start and stop M4 core. So
clocks and syscon are not required.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml          | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index b13bf8d70488..58bc2a23f97b 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -18,6 +18,7 @@ properties:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
       - fsl,imx7d-cm4
+      - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
 
   clocks:
@@ -57,8 +58,6 @@ properties:
 
 required:
   - compatible
-  - clocks
-  - syscon
 
 additionalProperties: false
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:17 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:17 +0800
Subject: [PATCH V5 3/8] dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-4-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) compatible string

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index 58bc2a23f97b..1dc34cf5a4ea 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -17,6 +17,8 @@ properties:
     enum:
       - fsl,imx8mq-cm4
       - fsl,imx8mm-cm4
+      - fsl,imx8mn-cm7
+      - fsl,imx8mp-cm7
       - fsl,imx7d-cm4
       - fsl,imx7ulp-cm4
       - fsl,imx6sx-cm4
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:18 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:18 +0800
Subject: [PATCH V5 4/8] remoteproc: imx_rproc: parse fsl,auto-boot
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-5-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Parse fsl,auto-boot to indicate whether need remoteproc framework
auto boot or not.

When remote processor is booted before Linux Kernel up, do not parse
fsl,auto-boot, so only need to parse the property when rproc state is
RPROC_DETACHED.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/remoteproc/imx_rproc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d6338872c6db..06dac92e98e6 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -654,6 +654,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 
 	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
 
+	if (rproc->state != RPROC_DETACHED)
+		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "rproc_add failed\n");
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:19 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:19 +0800
Subject: [PATCH V5 5/8] remoteproc: imx_rproc: initial support for mutilple
 start/stop method
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-6-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add three methods IMX_RPROC_NONE(no need start/stop), IMX_RPROC_MMIO
(start/stop through mmio) and IMX_RPROC_SMC(start/stop through ARM SMCCC).

The current SoCs supported are all using IMX_RPROC_MMIO.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 06dac92e98e6..6289aeae95b6 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -74,6 +74,15 @@ struct imx_rproc_att {
 	int flags;
 };
 
+/* Remote core start/stop method */
+enum imx_rproc_method {
+	IMX_RPROC_NONE,
+	/* Through syscon regmap */
+	IMX_RPROC_MMIO,
+	/* Through ARM SMCCC */
+	IMX_RPROC_SMC,
+};
+
 struct imx_rproc_dcfg {
 	u32				src_reg;
 	u32				src_mask;
@@ -81,6 +90,7 @@ struct imx_rproc_dcfg {
 	u32				src_stop;
 	const struct imx_rproc_att	*att;
 	size_t				att_size;
+	enum imx_rproc_method		method;
 };
 
 struct imx_rproc {
@@ -183,6 +193,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx8mq,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mq),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
@@ -192,6 +203,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_stop	= IMX7D_M4_STOP,
 	.att		= imx_rproc_att_imx7d,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7d),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
@@ -201,6 +213,7 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx6sx = {
 	.src_stop	= IMX6SX_M4_STOP,
 	.att		= imx_rproc_att_imx6sx,
 	.att_size	= ARRAY_SIZE(imx_rproc_att_imx6sx),
+	.method		= IMX_RPROC_MMIO,
 };
 
 static int imx_rproc_start(struct rproc *rproc)
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:20 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:20 +0800
Subject: [PATCH V5 6/8] remoteproc: imx_rproc: make clk optional
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-7-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

To i.MX7ULP, M4 is the master to control everything, no need to provide
clk from Linux side. So make clk optional when method is IMX_RPROC_NONE.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/remoteproc/imx_rproc.c | 46 +++++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6289aeae95b6..e9d9860e4fce 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -590,6 +590,35 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	return 0;
 }
 
+static int imx_rproc_clk_enable(struct imx_rproc *priv)
+{
+	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+	struct device *dev = priv->dev;
+	int ret;
+
+	/* Remote core is not under control of Linux */
+	if (dcfg->method == IMX_RPROC_NONE)
+		return 0;
+
+	priv->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(priv->clk)) {
+		dev_err(dev, "Failed to get clock\n");
+		return PTR_ERR(priv->clk);
+	}
+
+	/*
+	 * clk for M4 block including memory. Should be
+	 * enabled before .start for FW transfer.
+	 */
+	ret = clk_prepare_enable(priv->clk);
+	if (ret) {
+		dev_err(dev, "Failed to enable clock\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -648,22 +677,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_put_mbox;
 
-	priv->clk = devm_clk_get(dev, NULL);
-	if (IS_ERR(priv->clk)) {
-		dev_err(dev, "Failed to get clock\n");
-		ret = PTR_ERR(priv->clk);
-		goto err_put_mbox;
-	}
-
-	/*
-	 * clk for M4 block including memory. Should be
-	 * enabled before .start for FW transfer.
-	 */
-	ret = clk_prepare_enable(priv->clk);
-	if (ret) {
-		dev_err(&rproc->dev, "Failed to enable clock\n");
+	ret = imx_rproc_clk_enable(priv);
+	if (ret)
 		goto err_put_mbox;
-	}
 
 	INIT_WORK(&priv->rproc_work, imx_rproc_vq_work);
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:21 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:21 +0800
Subject: [PATCH V5 7/8] remoteproc: imx_rproc: support i.MX7ULP
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-8-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX7ULP A7 core runs under control of M4 core, M4 core starts by ROM
and powers most serivces used by A7 core, so A7 core has no power to
start and stop M4 core. And the M4 core's state is default RPROC_DETACHED
and remoteproc framework not able to stop the M4 core.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 49 ++++++++++++++++++++++++++--------
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index e9d9860e4fce..d26254609a52 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -136,6 +136,14 @@ static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	{ 0x40000000, 0x40000000, 0x80000000, 0 },
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx7ulp[] = {
+	{0x1FFD0000, 0x1FFD0000, 0x30000, ATT_OWN},
+	{0x20000000, 0x20000000, 0x10000, ATT_OWN},
+	{0x2F000000, 0x2F000000, 0x20000, ATT_OWN},
+	{0x2F020000, 0x2F020000, 0x20000, ATT_OWN},
+	{0x60000000, 0x60000000, 0x40000000, 0}
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* OCRAM_S (M4 Boot code) - alias */
@@ -196,6 +204,12 @@ static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.method		= IMX_RPROC_MMIO,
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx7ulp = {
+	.att		= imx_rproc_att_imx7ulp,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx7ulp),
+	.method		= IMX_RPROC_NONE,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -238,6 +252,9 @@ static int imx_rproc_stop(struct rproc *rproc)
 	struct device *dev = priv->dev;
 	int ret;
 
+	if (dcfg->method == IMX_RPROC_NONE)
+		return -EOPNOTSUPP;
+
 	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
 				 dcfg->src_mask, dcfg->src_stop);
 	if (ret)
@@ -573,12 +590,31 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
 
 static int imx_rproc_detect_mode(struct imx_rproc *priv)
 {
+	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct regmap *regmap;
 	int ret;
 	u32 val;
 
-	ret = regmap_read(priv->regmap, dcfg->src_reg, &val);
+	switch (dcfg->method) {
+	case IMX_RPROC_NONE:
+		priv->rproc->state = RPROC_DETACHED;
+		return 0;
+	default:
+		break;
+	}
+
+	regmap = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+	if (IS_ERR(regmap)) {
+		dev_err(dev, "failed to find syscon\n");
+		return PTR_ERR(regmap);
+	}
+
+	priv->regmap = regmap;
+	regmap_attach_dev(dev, regmap, &config);
+
+	ret = regmap_read(regmap, dcfg->src_reg, &val);
 	if (ret) {
 		dev_err(dev, "Failed to read src\n");
 		return ret;
@@ -625,18 +661,9 @@ static int imx_rproc_probe(struct platform_device *pdev)
 	struct device_node *np = dev->of_node;
 	struct imx_rproc *priv;
 	struct rproc *rproc;
-	struct regmap_config config = { .name = "imx-rproc" };
 	const struct imx_rproc_dcfg *dcfg;
-	struct regmap *regmap;
 	int ret;
 
-	regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
-	if (IS_ERR(regmap)) {
-		dev_err(dev, "failed to find syscon\n");
-		return PTR_ERR(regmap);
-	}
-	regmap_attach_dev(dev, regmap, &config);
-
 	/* set some other name then imx */
 	rproc = rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
 			    NULL, sizeof(*priv));
@@ -651,7 +678,6 @@ static int imx_rproc_probe(struct platform_device *pdev)
 
 	priv = rproc->priv;
 	priv->rproc = rproc;
-	priv->regmap = regmap;
 	priv->dcfg = dcfg;
 	priv->dev = dev;
 
@@ -720,6 +746,7 @@ static int imx_rproc_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id imx_rproc_of_match[] = {
+	{ .compatible = "fsl,imx7ulp-cm4", .data = &imx_rproc_cfg_imx7ulp },
 	{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
-- 
2.30.0



From peng.fan at oss.nxp.com  Wed Apr 21 03:20:22 2021
From: peng.fan at oss.nxp.com (peng.fan at oss.nxp.com)
Date: Wed, 21 Apr 2021 10:20:22 +0800
Subject: [PATCH V5 8/8] remoteproc: imx_rproc: support i.MX8MN/P
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <1618971622-30539-9-git-send-email-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Add i.MX8MN/P remote processor(Cortex-M7) support, we are using ARM
SMCCC to start/stop M core, not using regmap interface.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/remoteproc/imx_rproc.c | 87 +++++++++++++++++++++++++++++++---
 1 file changed, 80 insertions(+), 7 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d26254609a52..3cb901c87a7d 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2017 Pengutronix, Oleksij Rempel <kernel at pengutronix.de>
  */
 
+#include <linux/arm-smccc.h>
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
@@ -50,6 +51,11 @@
 
 #define IMX_RPROC_MEM_MAX		32
 
+#define IMX_SIP_RPROC			0xC2000005
+#define IMX_SIP_RPROC_START		0x00
+#define IMX_SIP_RPROC_STARTED		0x01
+#define IMX_SIP_RPROC_STOP		0x02
+
 /**
  * struct imx_rproc_mem - slim internal memory structure
  * @cpu_addr: MPU virtual address of the memory region
@@ -108,6 +114,36 @@ struct imx_rproc {
 	void __iomem			*rsc_table;
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx8mn[] = {
+	/* dev addr , sys addr  , size	    , flags */
+	/* ITCM   */
+	{ 0x00000000, 0x007E0000, 0x00020000, ATT_OWN },
+	/* OCRAM_S */
+	{ 0x00180000, 0x00180000, 0x00009000, 0 },
+	/* OCRAM */
+	{ 0x00900000, 0x00900000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00920000, 0x00920000, 0x00020000, 0 },
+	/* OCRAM */
+	{ 0x00940000, 0x00940000, 0x00050000, 0 },
+	/* QSPI Code - alias */
+	{ 0x08000000, 0x08000000, 0x08000000, 0 },
+	/* DDR (Code) - alias */
+	{ 0x10000000, 0x40000000, 0x0FFE0000, 0 },
+	/* DTCM */
+	{ 0x20000000, 0x00800000, 0x00020000, ATT_OWN },
+	/* OCRAM_S - alias */
+	{ 0x20180000, 0x00180000, 0x00008000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20200000, 0x00900000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20220000, 0x00920000, 0x00020000, ATT_OWN },
+	/* OCRAM */
+	{ 0x20240000, 0x00940000, 0x00040000, ATT_OWN },
+	/* DDR (Data) */
+	{ 0x40000000, 0x40000000, 0x80000000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
 	/* dev addr , sys addr  , size	    , flags */
 	/* TCML - alias */
@@ -194,6 +230,12 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = {
 	{ 0x80000000, 0x80000000, 0x60000000, 0 },
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mn = {
+	.att		= imx_rproc_att_imx8mn,
+	.att_size	= ARRAY_SIZE(imx_rproc_att_imx8mn),
+	.method		= IMX_RPROC_SMC,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
 	.src_reg	= IMX7D_SRC_SCR,
 	.src_mask	= IMX7D_M4_RST_MASK,
@@ -235,12 +277,24 @@ static int imx_rproc_start(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_start);
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_start);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_START, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		break;
+	default:
+		return -EOPNOTSUPP;
+	}
+
 	if (ret)
-		dev_err(dev, "Failed to enable M4!\n");
+		dev_err(dev, "Failed to enable remote cores!\n");
 
 	return ret;
 }
@@ -250,15 +304,26 @@ static int imx_rproc_stop(struct rproc *rproc)
 	struct imx_rproc *priv = rproc->priv;
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
+	struct arm_smccc_res res;
 	int ret;
 
-	if (dcfg->method == IMX_RPROC_NONE)
+	switch (dcfg->method) {
+	case IMX_RPROC_MMIO:
+		ret = regmap_update_bits(priv->regmap, dcfg->src_reg, dcfg->src_mask,
+					 dcfg->src_stop);
+		break;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STOP, 0, 0, 0, 0, 0, 0, &res);
+		ret = res.a0;
+		if (res.a1)
+			dev_info(dev, "Not in wfi, force stopped\n");
+		break;
+	default:
 		return -EOPNOTSUPP;
+	}
 
-	ret = regmap_update_bits(priv->regmap, dcfg->src_reg,
-				 dcfg->src_mask, dcfg->src_stop);
 	if (ret)
-		dev_err(dev, "Failed to stop M4!\n");
+		dev_err(dev, "Failed to stop remote cores\n");
 
 	return ret;
 }
@@ -594,6 +659,7 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	const struct imx_rproc_dcfg *dcfg = priv->dcfg;
 	struct device *dev = priv->dev;
 	struct regmap *regmap;
+	struct arm_smccc_res res;
 	int ret;
 	u32 val;
 
@@ -601,6 +667,11 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
 	case IMX_RPROC_NONE:
 		priv->rproc->state = RPROC_DETACHED;
 		return 0;
+	case IMX_RPROC_SMC:
+		arm_smccc_smc(IMX_SIP_RPROC, IMX_SIP_RPROC_STARTED, 0, 0, 0, 0, 0, 0, &res);
+		if (res.a0)
+			priv->rproc->state = RPROC_DETACHED;
+		return 0;
 	default:
 		break;
 	}
@@ -751,6 +822,8 @@ static const struct of_device_id imx_rproc_of_match[] = {
 	{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
 	{ .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
 	{ .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
+	{ .compatible = "fsl,imx8mn-cm7", .data = &imx_rproc_cfg_imx8mn },
+	{ .compatible = "fsl,imx8mp-cm7", .data = &imx_rproc_cfg_imx8mn },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
-- 
2.30.0



From zhukeqian1 at huawei.com  Wed Apr 21 03:59:12 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 21 Apr 2021 10:59:12 +0800
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
Message-ID: <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>

Hi Santosh,

On 2020/10/22 0:16, Santosh Shukla wrote:
> The Commit:6d674e28 introduces a notion to detect and handle the
> device mapping. The commit checks for the VM_PFNMAP flag is set
> in vma->flags and if set then marks force_pte to true such that
> if force_pte is true then ignore the THP function check
> (/transparent_hugepage_adjust()).
> 
> There could be an issue with the VM_PFNMAP flag setting and checking.
> For example consider a case where the mdev vendor driver register's
> the vma_fault handler named vma_mmio_fault(), which maps the
> host MMIO region in-turn calls remap_pfn_range() and maps
> the MMIO's vma space. Where, remap_pfn_range implicitly sets
> the VM_PFNMAP flag into vma->flags.
Could you give the name of the mdev vendor driver that triggers this issue?
I failed to find one according to your description. Thanks.


BRs,
Keqian


> 
> Now lets assume a mmio fault handing flow where guest first access
> the MMIO region whose 2nd stage translation is not present.
> So that results to arm64-kvm hypervisor executing guest abort handler,
> like below:
> 
> kvm_handle_guest_abort() -->
>  user_mem_abort()--> {
> 
>     ...
>     0. checks the vma->flags for the VM_PFNMAP.
>     1. Since VM_PFNMAP flag is not yet set so force_pte _is_ false;
>     2. gfn_to_pfn_prot() -->
>         __gfn_to_pfn_memslot() -->
>             fixup_user_fault() -->
>                 handle_mm_fault()-->
>                     __do_fault() -->
>                        vma_mmio_fault() --> // vendor's mdev fault handler
>                         remap_pfn_range()--> // Here sets the VM_PFNMAP
> 						flag into vma->flags.
>     3. Now that force_pte is set to false in step-2),
>        will execute transparent_hugepage_adjust() func and
>        that lead to Oops [4].
>  }
> 
> The proposition is to check is_iomap flag before executing the THP
> function transparent_hugepage_adjust().
> 
> [4] THP Oops:
>> pc: kvm_is_transparent_hugepage+0x18/0xb0
>> ...
>> ...
>> user_mem_abort+0x340/0x9b8
>> kvm_handle_guest_abort+0x248/0x468
>> handle_exit+0x150/0x1b0
>> kvm_arch_vcpu_ioctl_run+0x4d4/0x778
>> kvm_vcpu_ioctl+0x3c0/0x858
>> ksys_ioctl+0x84/0xb8
>> __arm64_sys_ioctl+0x28/0x38
> 
> Tested on Huawei Kunpeng Taishan-200 arm64 server, Using VFIO-mdev device.
> Linux tip: 583090b1
> 
> Fixes: 6d674e28 ("KVM: arm/arm64: Properly handle faulting of device mappings")
> Signed-off-by: Santosh Shukla <sashukla at nvidia.com>
> ---
>  arch/arm64/kvm/mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 3d26b47..ff15357 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1947,7 +1947,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	 * If we are not forced to use page mapping, check if we are
>  	 * backed by a THP and thus use block mapping if possible.
>  	 */
> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> +	if (vma_pagesize == PAGE_SIZE && !force_pte && !is_iomap(flags))
>  		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>  							   &pfn, &fault_ipa);
>  	if (writable)
> 


From dillon.minfei at gmail.com  Wed Apr 21 04:40:26 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Wed, 21 Apr 2021 11:40:26 +0800
Subject: [PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC
 board support
In-Reply-To: <CAOMZO5CcoKDZhj5rQ0_0wkHgk5Mf2RtAHy94EAzjwVgXvvmNeg@mail.gmail.com>
References: <1618459535-8141-1-git-send-email-dillon.minfei@gmail.com>
 <1618459535-8141-4-git-send-email-dillon.minfei@gmail.com>
 <CAOMZO5CcoKDZhj5rQ0_0wkHgk5Mf2RtAHy94EAzjwVgXvvmNeg@mail.gmail.com>
Message-ID: <CAL9mu0+nvkywRffOaXTNJwY7S0wxqNNz2h6pnmV3PhRZG0+_hA@mail.gmail.com>

Hi Fabio,

Thanks for quick reply.

On Tue, Apr 20, 2021 at 10:27 PM Fabio Estevam <festevam at gmail.com> wrote:
>
> Hi Dillon,
>
> On Thu, Apr 15, 2021 at 1:05 AM <dillon.minfei at gmail.com> wrote:
>
> > +               green {
> > +                       gpios = <&gpio4 8 0>;
>
> Please use GPIO_ACTIVE_HIGH label instead:
> gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
>
> > +&clks {
> > +       assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> > +                         <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> > +       assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> > +                                <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> > +};
>
> You are setting the LDB clock parent, but you don't use LDB in this
> devicetree. You could simply remove this.
Agree, thanks.
>
> > +&ecspi1 {
> > +       cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&pinctrl_ecspi1>;
> > +       status = "okay";
> > +
> > +       flash: m25p80 at 0 {
>
> Node names should be generic:
>
> m25p80: flash at 0
Agree, thanks.
>
> > +&iomuxc {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&pinctrl_hog>;
> > +
> > +       imx6qdl-ds {
> > +               pinctrl_hog: hoggrp {
> > +                       fsl,pins = <
> > +                               MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b0
> > +                               MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> > +                               MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
>
> This could be part of the pinctrl_ov2659 group as it provides the
> clock for the camera.
>
> Please try to keep in the hoggrp only the pins that cannot be
> controlled by any other node.
Agree, after moving these pinctrl to corresponding component's group,
the hoggrp is useless.
so, I removed it in v4.
>
> > +&wdog1 {
> > +       status = "okay";
> > +};
> > +
> > +&wdog2 {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&pinctrl_wdog>;
> > +       fsl,ext-reset-output;
> > +       status = "disabled";
>
> Wouldn't it be better to enable wdog2 and disable wdog1 instead? wdog2
> provides a POR, which is preferred.
Agree, thanks.


From dillon.minfei at gmail.com  Wed Apr 21 04:48:54 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 21 Apr 2021 11:48:54 +0800
Subject: [PATCH v4 0/4] arm: imx: Add i.mx6q DaSheng COM-9XX SBC board support
Message-ID: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

This patchset aims to add kernel support on DaSheng COM-8XX SBC board
optimize ov2659 driver to handle xvclk on/off at proper stage to save power

changes based on linux master branch, since commit id:
89698becf06d341a700913c3d89ce2a914af69a2

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

---
v4:
all changes are on '[PATCH v3 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX
SBC board support'
- change 'green' to 'led-0', fix dtbs_check warrning
- change 'pmic: pfuze100 at 8' to 'pfuze100: pmic at 8', fix dtbs_check warrning
- use GPIO_ACTIVE_HIGH instead of 0, from Fabio's suggestion, thanks
- change 'flash: m25p80 at 0' to 'm25p80: flash at 0'
- move 'MX6QDL_PAD_GPIO_0__CCM_CLKO1' to pinctrl_ov2659{}
- move 'MX6QDL_PAD_NANDF_D0__GPIO2_IO00, MX6QDL_PAD_NANDF_D1__GPIO2_IO01'
  to pinctrl_usdhc2_gpioio{}
- remove unused hoggrp
- use wdog2, instead of wdog1 for external reset
- v3 link:
https://lore.kernel.org/lkml/1618459535-8141-1-git-send-email-dillon.minfei at gmail.com/

v3:
- optimize commit message for patch v3 ov2659 part
- move 'imx6q-ds.dtb' after 'imx6q-dms-ba16.dtb' to follow the alphabetical
  order(arch/arm/boot/dts/Makefile)
- move 'ds,imx6q-sbc' after 'dmo,imx6q-edmqmx6' to follow the alphabetical
  order. (Documentation/devicetree/bindings/arm/fsl.yaml)
- move v2 patch 4 to v3 patch 1
- add 'Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>'
  for [PATCH v3 1/4]

- v2 link:
https://lore.kernel.org/lkml/1618383117-17179-1-git-send-email-dillon.minfei at gmail.com/

v2:
- add "[PATCH v2 4/4] dt-bindings: add dasheng vendor prefix" to fix
  checkpatch.pl warning.

dillon min (4):
  dt-bindings: add dasheng vendor prefix
  dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
  arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board support
  media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to
    set xvclk on/off

 Documentation/devicetree/bindings/arm/fsl.yaml     |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/imx6q-ds.dts                     |  17 +
 arch/arm/boot/dts/imx6qdl-ds.dtsi                  | 460 +++++++++++++++++++++
 drivers/media/i2c/ov2659.c                         |  24 +-
 6 files changed, 499 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 21 04:48:55 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 21 Apr 2021 11:48:55 +0800
Subject: [PATCH v4 1/4] dt-bindings: add dasheng vendor prefix
In-Reply-To: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618976938-20834-2-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

Add vendor prefix for DaSheng, Inc.

Signed-off-by: dillon min <dillon.minfei at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
Acked-by: Rob Herring <robh at kernel.org>
---
v4: add Reviewed-by, Acked-by

 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 f6064d84a424..4ec28488c963 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -309,6 +309,8 @@ patternProperties:
     description: DPTechnics
   "^dragino,.*":
     description: Dragino Technology Co., Limited
+  "^ds,.*":
+    description: DaSheng, Inc.
   "^dserve,.*":
     description: dServe Technology B.V.
   "^dynaimage,.*":
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 21 04:48:56 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 21 Apr 2021 11:48:56 +0800
Subject: [PATCH v4 2/4] dt-bindings: arm: imx: Add i.mx6q DaSheng COM-9XX SBC
In-Reply-To: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618976938-20834-3-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
Acked-by: Rob Herring <robh at kernel.org>
---
v4: add Reviewed-by, Acked-by

 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 297c87f45db8..598fb44c1bb8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -197,6 +197,7 @@ properties:
               - boundary,imx6q-nitrogen6x
               - compulab,cm-fx6           # CompuLab CM-FX6
               - dmo,imx6q-edmqmx6         # Data Modul eDM-QMX6 Board
+              - ds,imx6q-sbc              # Da Sheng COM-9XX Modules
               - embest,imx6q-marsboard    # Embest MarS Board i.MX6Dual
               - emtrion,emcon-mx6         # emCON-MX6D or emCON-MX6Q SoM
               - emtrion,emcon-mx6-avari   # emCON-MX6D or emCON-MX6Q SoM on Avari Base
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 21 04:48:57 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 21 Apr 2021 11:48:57 +0800
Subject: [PATCH v4 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC board
 support
In-Reply-To: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618976938-20834-4-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

The DaSheng Com-9xx is and ARM based signle board computer (SBC)
featuring:
- i.MX6Q
- 2GiB LPDDR3 DRAM
- 8GiB eMMC 5.0 FLASH
- 4MiB SPI Flash
- USB 2.0 Host/Device
- Multiple multi-protocol RS232/RS485 Serial ports
- microSD socket
- 5V DC power input
- HDMI1.4a,1080p at 60
- RGMIIx1 Gigabit Ethernet
- CSI0x1, connect with ov2659

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v4:
- change 'green' to 'led-0', fix dtbs_check warrning
- change 'pmic: pfuze100 at 8' to 'pfuze100: pmic at 8', fix dtbs_check warrning
- use GPIO_ACTIVE_HIGH instead of 0, from Fabio's suggestion, thanks
- change 'flash: m25p80 at 0' to 'm25p80: flash at 0'
- move 'MX6QDL_PAD_GPIO_0__CCM_CLKO1' to pinctrl_ov2659{}
- move 'MX6QDL_PAD_NANDF_D0__GPIO2_IO00, MX6QDL_PAD_NANDF_D1__GPIO2_IO01'
  to pinctrl_usdhc2_gpioio{}
- remove unused hoggrp
- use wdog2, instead of wdog1 for external reset

 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/imx6q-ds.dts    |  17 ++
 arch/arm/boot/dts/imx6qdl-ds.dtsi | 460 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 478 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a19c5ab9df84..425fe17ef7c1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -510,6 +510,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-display5-tianma-tm070-1280x768.dtb \
 	imx6q-dmo-edmqmx6.dtb \
 	imx6q-dms-ba16.dtb \
+	imx6q-ds.dtb \
 	imx6q-emcon-avari.dtb \
 	imx6q-evi.dtb \
 	imx6q-gk802.dtb \
diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
new file mode 100644
index 000000000000..b0a63a133977
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ds.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-ds.dtsi"
+
+/ {
+	model = "DaSheng i.MX6 Quad Com-9xx Board";
+	compatible = "ds,imx6q-sbc", "fsl,imx6q";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
new file mode 100644
index 000000000000..a2069caf4ea7
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
@@ -0,0 +1,460 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
+//
+// Based on imx6qdl-sabresd.dtsi which is:
+// Copyright 2012 Freescale Semiconductor, Inc.
+// Copyright 2011 Linaro Ltd.
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	chosen {
+		stdout-path = &uart4;
+	};
+
+	memory at 10000000 {
+		device_type = "memory";
+		reg = <0x10000000 0x80000000>;
+	};
+
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	reg_usb_h1_vbus: regulator-usb-h1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_h1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_leds>;
+
+		led-0 {
+			gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+};
+
+&ipu1_csi0_from_ipu1_csi0_mux {
+	bus-width = <8>;
+	data-shift = <12>; /* Lines 19:12 used */
+	hsync-active = <1>;
+	vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+	remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ipu1_csi0>;
+	status = "okay";
+};
+
+&ecspi1 {
+	cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>, <&pinctrl_ecspi1_gpio>;
+	status = "okay";
+
+	m25p80: flash at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,m25p80", "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&phy>;
+	fsl,magic-packet;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy: ethernet-phy at 1 {
+			reg = <1>;
+			qca,clk-out-frequency = <125000000>;
+			reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+		};
+	};
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hdmi_cec>;
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	pfuze100: pmic at 8 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3b_reg: sw3b {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw4_reg: sw4 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vgen1 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen2_reg: vgen2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+			};
+
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	ov2659: camera at 30 {
+		compatible = "ovti,ov2659";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_ov2659>;
+		clocks = <&clks IMX6QDL_CLK_CKO>;
+		clock-names = "xvclk";
+		reg = <0x30>;
+		powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+		status = "okay";
+
+		port {
+			ov2659_to_ipu1_csi0_mux: endpoint {
+				remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+				link-frequencies = /bits/ 64 <70000000>;
+				bus-width = <8>;
+				hsync-active = <1>;
+				vsync-active = <1>;
+			};
+		};
+	};
+};
+
+&iomuxc {
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D16__ECSPI1_SCLK		0x100b1
+			MX6QDL_PAD_EIM_D18__ECSPI1_MOSI		0x100b1
+			MX6QDL_PAD_EIM_D17__ECSPI1_MISO		0x100b1
+		>;
+	};
+
+	pinctrl_ecspi1_gpio: ecspi1grpgpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW1__GPIO4_IO09		0x1b0b0
+			MX6QDL_PAD_ENET_RXD0__GPIO1_IO27	0x1b0b0
+		>;
+	};
+
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x1b030
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x1b030
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x1b030
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x1b030
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x1b030
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x1b030
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x1b0b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b030
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b030
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b030
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b030
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b030
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b030
+			MX6QDL_PAD_KEY_COL2__GPIO4_IO10         0x1b0b0
+		>;
+	};
+
+	pinctrl_hdmi_cec: hdmicecgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE	0x1f8b0
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_EB2__I2C2_SCL		0x4001b8b1
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA		0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_5__I2C3_SCL		0x4001b8b1
+			MX6QDL_PAD_GPIO_6__I2C3_SDA		0x4001b8b1
+		>;
+	};
+
+	pinctrl_ipu1_csi0: ipu1csi0grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
+			MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
+			MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
+			MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
+			MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
+		>;
+	};
+
+	pinctrl_ov2659: ov2659grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_16__GPIO7_IO11		0x1b0b0
+			MX6QDL_PAD_GPIO_7__GPIO1_IO07		0x1b0b0
+			MX6QDL_PAD_GPIO_0__CCM_CLKO1		0x130b0
+		>;
+	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL0__UART4_TX_DATA	0x1b0b1
+			MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA	0x1b0b1
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID	0x17059
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_CMD__SD1_CMD		0x17059
+			MX6QDL_PAD_SD1_CLK__SD1_CLK		0x10059
+			MX6QDL_PAD_SD1_DAT0__SD1_DATA0		0x17059
+			MX6QDL_PAD_SD1_DAT1__SD1_DATA1		0x17059
+			MX6QDL_PAD_SD1_DAT2__SD1_DATA2		0x17059
+			MX6QDL_PAD_SD1_DAT3__SD1_DATA3		0x17059
+		>;
+	};
+
+	pinctrl_usdhc1_gpio: usdhc1grpgpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28	0x1b0b0
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+			MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10059
+			MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+			MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+			MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+			MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+		>;
+	};
+
+	pinctrl_usdhc2_gpio: usdhc2grpgpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_D0__GPIO2_IO00		0x1b0b0
+			MX6QDL_PAD_NANDF_D1__GPIO2_IO01		0x1b0b0
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+			MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10059
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+		>;
+	};
+
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__WDOG2_B		0x1b0b0
+		>;
+	};
+
+	pinctrl_gpio_leds: gpioledsgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
+		>;
+	};
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usb_h1_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_usdhc1_gpio>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+	bus-width = <4>;
+	cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	bus-width = <8>;
+	non-removable;
+	no-1-8-v;
+	status = "okay";
+};
+
+&wdog1 {
+	status = "disabled";
+};
+
+&wdog2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+	status = "okay";
+};
-- 
2.7.4



From dillon.minfei at gmail.com  Wed Apr 21 04:48:58 2021
From: dillon.minfei at gmail.com (dillon.minfei at gmail.com)
Date: Wed, 21 Apr 2021 11:48:58 +0800
Subject: [PATCH v4 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
Message-ID: <1618976938-20834-5-git-send-email-dillon.minfei@gmail.com>

From: dillon min <dillon.minfei at gmail.com>

On some platform(imx6q), xvclk might not switch on in advance,
also for power save purpose, xvclk should not be always on.
so, add clk_prepare_enable(), clk_disable_unprepare() in driver
side to set xvclk on/off at proper stage.

Add following changes:
- add 'struct clk *clk;' in 'struct ov2659 {}'
- enable xvclk in ov2659_power_on()
- disable xvclk in ov2659_power_off()

Signed-off-by: dillon min <dillon.minfei at gmail.com>
---
v4: no changes

 drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 42f64175a6df..fb78a1cedc03 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -204,6 +204,7 @@ struct ov2659 {
 	struct i2c_client *client;
 	struct v4l2_ctrl_handler ctrls;
 	struct v4l2_ctrl *link_frequency;
+	struct clk *clk;
 	const struct ov2659_framesize *frame_size;
 	struct sensor_register *format_ctrl_regs;
 	struct ov2659_pll_ctrl pll;
@@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
 
 	gpiod_set_value(ov2659->pwdn_gpio, 1);
 
+	clk_disable_unprepare(ov2659->clk);
+
 	return 0;
 }
 
@@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
 	struct i2c_client *client = to_i2c_client(dev);
 	struct v4l2_subdev *sd = i2c_get_clientdata(client);
 	struct ov2659 *ov2659 = to_ov2659(sd);
+	int ret;
 
 	dev_dbg(&client->dev, "%s:\n", __func__);
 
+	ret = clk_prepare_enable(ov2659->clk);
+	if (ret) {
+		dev_err(&client->dev, "%s: failed to enable clock\n",
+			__func__);
+		return ret;
+	}
+
 	gpiod_set_value(ov2659->pwdn_gpio, 0);
 
 	if (ov2659->resetb_gpio) {
@@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
 	const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
 	struct v4l2_subdev *sd;
 	struct ov2659 *ov2659;
-	struct clk *clk;
 	int ret;
 
 	if (!pdata) {
@@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->pdata = pdata;
 	ov2659->client = client;
 
-	clk = devm_clk_get(&client->dev, "xvclk");
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
+	ov2659->clk = devm_clk_get(&client->dev, "xvclk");
+	if (IS_ERR(ov2659->clk))
+		return PTR_ERR(ov2659->clk);
 
-	ov2659->xvclk_frequency = clk_get_rate(clk);
+	ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
 	if (ov2659->xvclk_frequency < 6000000 ||
 	    ov2659->xvclk_frequency > 27000000)
 		return -EINVAL;
@@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
 	ov2659->frame_size = &ov2659_framesizes[2];
 	ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
 
-	ov2659_power_on(&client->dev);
+	ret = ov2659_power_on(&client->dev);
+	if (ret < 0)
+		goto error;
 
 	ret = ov2659_detect(sd);
 	if (ret < 0)
-- 
2.7.4



From song.bao.hua at hisilicon.com  Wed Apr 21 05:06:03 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Wed, 21 Apr 2021 04:06:03 +0000
Subject: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within a
 die
References: <20210319041618.14316-1-song.bao.hua@hisilicon.com>
 <20210319041618.14316-2-song.bao.hua@hisilicon.com>
 <YFRGIedW1fUlnmi+@kroah.com> <eb48302277f3436eb9899032e6b0bf1c@hisilicon.com>
 <20210319093616.00001879@Huawei.com> <YFR2kwakbcGiI37w@kroah.com> 
Message-ID: <be2755fd4f1447cb97c4de04eb378a0b@hisilicon.com>



> -----Original Message-----
> From: Song Bao Hua (Barry Song)
> Sent: Tuesday, April 20, 2021 3:24 PM
> To: 'Greg KH' <gregkh at linuxfoundation.org>; Jonathan Cameron
> <jonathan.cameron at huawei.com>
> Cc: tim.c.chen at linux.intel.com; catalin.marinas at arm.com; will at kernel.org;
> rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org; peterz at infradead.org;
> dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> mgorman at suse.de; msys.mizuma at gmail.com; valentin.schneider at arm.com;
> juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com; tiantao (H)
> <tiantao6 at hisilicon.com>
> Subject: RE: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within
> a die
> 
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh at linuxfoundation.org]
> > Sent: Friday, March 19, 2021 11:02 PM
> > To: Jonathan Cameron <jonathan.cameron at huawei.com>
> > Cc: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> > tim.c.chen at linux.intel.com; catalin.marinas at arm.com; will at kernel.org;
> > rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> > tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org;
> peterz at infradead.org;
> > dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> > mgorman at suse.de; msys.mizuma at gmail.com; valentin.schneider at arm.com;
> > juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> > aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> > xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> > guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu
> (Kenneth)
> > <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com
> > Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs within
> > a die
> >
> > On Fri, Mar 19, 2021 at 09:36:16AM +0000, Jonathan Cameron wrote:
> > > On Fri, 19 Mar 2021 06:57:08 +0000
> > > "Song Bao Hua (Barry Song)" <song.bao.hua at hisilicon.com> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:gregkh at linuxfoundation.org]
> > > > > Sent: Friday, March 19, 2021 7:35 PM
> > > > > To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>
> > > > > Cc: tim.c.chen at linux.intel.com; catalin.marinas at arm.com;
> > will at kernel.org;
> > > > > rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> > > > > tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org;
> > peterz at infradead.org;
> > > > > dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> > > > > mgorman at suse.de; msys.mizuma at gmail.com; valentin.schneider at arm.com;
> > Jonathan
> > > > > Cameron <jonathan.cameron at huawei.com>; juri.lelli at redhat.com;
> > > > > mark.rutland at arm.com; sudeep.holla at arm.com; aubrey.li at linux.intel.com;
> > > > > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > > > linux-acpi at vger.kernel.org; x86 at kernel.org; xuwei (O)
> > <xuwei5 at huawei.com>;
> > > > > Zengtao (B) <prime.zeng at hisilicon.com>; guodong.xu at linaro.org;
> > yangyicong
> > > > > <yangyicong at huawei.com>; Liguozhu (Kenneth) <liguozhu at hisilicon.com>;
> > > > > linuxarm at openeuler.org; hpa at zytor.com
> > > > > Subject: Re: [RFC PATCH v5 1/4] topology: Represent clusters of CPUs
> within
> > > > > a die
> > > > >
> > > > > On Fri, Mar 19, 2021 at 05:16:15PM +1300, Barry Song wrote:
> > > > > > diff --git a/Documentation/admin-guide/cputopology.rst
> > > > > b/Documentation/admin-guide/cputopology.rst
> > > > > > index b90dafc..f9d3745 100644
> > > > > > --- a/Documentation/admin-guide/cputopology.rst
> > > > > > +++ b/Documentation/admin-guide/cputopology.rst
> > > > > > @@ -24,6 +24,12 @@ core_id:
> > > > > >  	identifier (rather than the kernel's).  The actual value is
> > > > > >  	architecture and platform dependent.
> > > > > >
> > > > > > +cluster_id:
> > > > > > +
> > > > > > +	the Cluster ID of cpuX.  Typically it is the hardware platform's
> > > > > > +	identifier (rather than the kernel's).  The actual value is
> > > > > > +	architecture and platform dependent.
> > > > > > +
> > > > > >  book_id:
> > > > > >
> > > > > >  	the book ID of cpuX. Typically it is the hardware platform's
> > > > > > @@ -56,6 +62,14 @@ package_cpus_list:
> > > > > >  	human-readable list of CPUs sharing the same physical_package_id.
> > > > > >  	(deprecated name: "core_siblings_list")
> > > > > >
> > > > > > +cluster_cpus:
> > > > > > +
> > > > > > +	internal kernel map of CPUs within the same cluster.
> > > > > > +
> > > > > > +cluster_cpus_list:
> > > > > > +
> > > > > > +	human-readable list of CPUs within the same cluster.
> > > > > > +
> > > > > >  die_cpus:
> > > > > >
> > > > > >  	internal kernel map of CPUs within the same die.
> > > > >
> > > > > Why are these sysfs files in this file, and not in a Documentation/ABI/
> > > > > file which can be correctly parsed and shown to userspace?
> > > >
> > > > Well. Those ABIs have been there for much a long time. It is like:
> > > >
> > > > [root at ceph1 topology]# ls
> > > > core_id  core_siblings  core_siblings_list  physical_package_id
> > thread_siblings  thread_siblings_list
> > > > [root at ceph1 topology]# pwd
> > > > /sys/devices/system/cpu/cpu100/topology
> > > > [root at ceph1 topology]# cat core_siblings_list
> > > > 64-127
> > > > [root at ceph1 topology]#
> > > >
> > > > >
> > > > > Any chance you can fix that up here as well?
> > > >
> > > > Yes. we will send a separate patch to address this, which won't
> > > > be in this patchset. This patchset will base on that one.
> > > >
> > > > >
> > > > > Also note that "list" is not something that goes in sysfs, sysfs is
> "one
> > > > > value per file", and a list is not "one value".  How do you prevent
> > > > > overflowing the buffer of the sysfs file if you have a "list"?
> > > > >
> > > >
> > > > At a glance, the list is using "-" rather than a real list
> > > > [root at ceph1 topology]# cat core_siblings_list
> > > > 64-127
> > > >
> > > > Anyway, I will take a look if it has any chance to overflow.
> > >
> > > It could in theory be alternate CPUs as comma separated list.
> > > So it's would get interesting around 500-1000 cpus (guessing).
> > >
> > > Hopefully no one has that crazy a cpu numbering scheme but it's possible
> > > (note that cluster is fine for this, but I guess it might eventually
> > > happen for core-siblings list (cpus within a package).
> > >
> > > Shouldn't crash or anything like that but might terminate early.
> >
> > We have a broken sysfs api already for listing LED numbers that has had
> > to be worked around in the past, please do not create a new one with
> > that same problem, we should learn from them :)
> 
> Another place I am seeing a cpu list is in numa topology:
> /sys/devices/system/node/nodex/cpulist.
> 
> But the code has a BUILD_BUG_ON to guard the pagebuf:
> 
> static ssize_t node_read_cpumap(struct device *dev, bool list, char *buf)
> {
> 	ssize_t n;
> 	cpumask_var_t mask;
> 	struct node *node_dev = to_node(dev);
> 
> 	/* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
> 	BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
> 
> 	if (!alloc_cpumask_var(&mask, GFP_KERNEL))
> 		return 0;
> 
> 	cpumask_and(mask, cpumask_of_node(node_dev->dev.id), cpu_online_mask);
> 	n = cpumap_print_to_pagebuf(list, buf, mask);
> 	free_cpumask_var(mask);
> 
> 	return n;
> }
> 
> For lists in cpu topology, I haven't seen this while I believe we need it.
> Or am I missing something?

I would prefer we send two patches as a series
"clarify and cleanup CPU and NUMA topology ABIs" with a cover
letter and the below one as 1/2. 2/2 would be the patch moving
the place of cpu topology ABI doc.

>From b32c0c00a187d4fe4c49d54d30650b0cacb2c351 Mon Sep 17 00:00:00 2001
From: Tian Tao <tiantao6 at hisilicon.com>
Date: Wed, 21 Apr 2021 14:36:11 +1200
Subject: [PATCH 1/2] CPU, NUMA topology ABIs: clarify the overflow issue of sysfs
 pagebuf

Both numa node and cpu use cpu bitmap like 3,ffffffff to expose hardware
topology. When cpu number is large, the page buffer of sysfs will over-
flow. This doesn't really happen nowadays as the maximum NR_CPUS is 8196
for X86_64 and 4096 for ARM64 since 8196 * 9 / 32 = 2305 is still smaller
than 4KB page size.
So the existing BUILD_BUG_ON() in drivers/base/node.c is pretty much
preventing future problems similar with Y2K when hardware gets more
and more CPUs.
On the other hand, it should be more sensible to move the guard to common
code which can protect both cpu and numa:
/sys/devices/system/cpu/cpu0/topology/die_cpus etc.
/sys/devices/system/node/node0/cpumap etc.

Topology bitmap mask strings shouldn't be larger than PAGE_SIZE as
lstopo and numactl depend on them. But other ABIs exposing cpu lists
are not really used by common applications, so this patch also marks
those lists could be trimmed as there is no any guarantee those lists
are always less than PAGE_SIZE especially a list could be like this:
0, 3, 5, 7, 9, 11... etc.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 Documentation/ABI/stable/sysfs-devices-node |  5 ++++-
 Documentation/admin-guide/cputopology.rst   | 15 +++++++++++++++
 drivers/base/node.c                         |  3 ---
 include/linux/cpumask.h                     |  6 ++++++
 4 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
index 484fc04bcc25..9832a17b2b15 100644
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -47,7 +47,10 @@ What:		/sys/devices/system/node/nodeX/cpulist
 Date:		October 2002
 Contact:	Linux Memory Management list <linux-mm at kvack.org>
 Description:
-		The CPUs associated to the node.
+		The CPUs associated to the node. The format is like 0-3,
+		8-11, 12-13. The maximum size is PAGE_SIZE, so the tail
+		of the string will be trimmed while its size is larger
+		than PAGE_SIZE.
 
 What:		/sys/devices/system/node/nodeX/meminfo
 Date:		October 2002
diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst
index b90dafcc8237..8fac776a5ffa 100644
--- a/Documentation/admin-guide/cputopology.rst
+++ b/Documentation/admin-guide/cputopology.rst
@@ -44,6 +44,9 @@ core_cpus:
 core_cpus_list:
 
 	human-readable list of CPUs within the same core.
+	The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE,
+	so the tail of the string will be trimmed while its size is larger
+	than PAGE_SIZE.
 	(deprecated name: "thread_siblings_list");
 
 package_cpus:
@@ -54,6 +57,9 @@ package_cpus:
 package_cpus_list:
 
 	human-readable list of CPUs sharing the same physical_package_id.
+	The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE,
+	so the tail of the string will be trimmed while its size is larger
+	than PAGE_SIZE.
 	(deprecated name: "core_siblings_list")
 
 die_cpus:
@@ -63,6 +69,9 @@ die_cpus:
 die_cpus_list:
 
 	human-readable list of CPUs within the same die.
+	The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE,
+	so the tail of the string will be trimmed while its size is larger
+	than PAGE_SIZE.
 
 book_siblings:
 
@@ -73,6 +82,9 @@ book_siblings_list:
 
 	human-readable list of cpuX's hardware threads within the same
 	book_id.
+	The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE,
+	so the tail of the string will be trimmed while its size is larger
+	than PAGE_SIZE.
 
 drawer_siblings:
 
@@ -83,6 +95,9 @@ drawer_siblings_list:
 
 	human-readable list of cpuX's hardware threads within the same
 	drawer_id.
+	The format is like 0-3, 8-11, 12-13. The maximum size is PAGE_SIZE,
+	so the tail of the string will be trimmed while its size is larger
+	than PAGE_SIZE.
 
 Architecture-neutral, drivers/base/topology.c, exports these attributes.
 However, the book and drawer related sysfs files will only be created if
diff --git a/drivers/base/node.c b/drivers/base/node.c
index f449dbb2c746..50324d06bcd5 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -33,9 +33,6 @@ static ssize_t node_read_cpumap(struct device *dev, bool list, char *buf)
 	cpumask_var_t mask;
 	struct node *node_dev = to_node(dev);
 
-	/* 2008/04/07: buf currently PAGE_SIZE, need 9 chars per 32 bits. */
-	BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
-
 	if (!alloc_cpumask_var(&mask, GFP_KERNEL))
 		return 0;
 
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 383684e30f12..81f145e0c742 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -12,6 +12,7 @@
 #include <linux/bitmap.h>
 #include <linux/atomic.h>
 #include <linux/bug.h>
+#include <asm/page.h>
 
 /* Don't assign or return these: may not be this big! */
 typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;
@@ -924,6 +925,11 @@ static inline const struct cpumask *get_cpu_mask(unsigned int cpu)
 static inline ssize_t
 cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
 {
+	/*
+	 * 32bits requires 9bytes: "ff,ffffffff", thus, too many CPUs will
+	 * cause the overflow of sysfs pagebuf
+	 */
+	BUILD_BUG_ON((NR_CPUS/32 * 9) > (PAGE_SIZE-1));
 	return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
 				      nr_cpu_ids);
 }
-- 
2.25.1

Thanks
Barry


From gshan at redhat.com  Wed Apr 21 07:20:12 2021
From: gshan at redhat.com (Gavin Shan)
Date: Wed, 21 Apr 2021 16:20:12 +1000
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
Message-ID: <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>

Hi Keqian and Santosh,

On 4/21/21 12:59 PM, Keqian Zhu wrote:
> On 2020/10/22 0:16, Santosh Shukla wrote:
>> The Commit:6d674e28 introduces a notion to detect and handle the
>> device mapping. The commit checks for the VM_PFNMAP flag is set
>> in vma->flags and if set then marks force_pte to true such that
>> if force_pte is true then ignore the THP function check
>> (/transparent_hugepage_adjust()).
>>
>> There could be an issue with the VM_PFNMAP flag setting and checking.
>> For example consider a case where the mdev vendor driver register's
>> the vma_fault handler named vma_mmio_fault(), which maps the
>> host MMIO region in-turn calls remap_pfn_range() and maps
>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>> the VM_PFNMAP flag into vma->flags.
> Could you give the name of the mdev vendor driver that triggers this issue?
> I failed to find one according to your description. Thanks.
> 

I think it would be fixed in driver side to set VM_PFNMAP in
its mmap() callback (call_mmap()), like vfio PCI driver does.
It means it won't be delayed until page fault is issued and
remap_pfn_range() is called. It's determined from the beginning
that the vma associated the mdev vendor driver is serving as
PFN remapping purpose. So the vma should be populated completely,
including the VM_PFNMAP flag before it becomes visible to user
space.

The example can be found from vfio driver in drivers/vfio/pci/vfio_pci.c:
     vfio_pci_mmap:       VM_PFNMAP is set for the vma
     vfio_pci_mmap_fault: remap_pfn_range() is called

Thanks,
Gavin

>>
>> Now lets assume a mmio fault handing flow where guest first access
>> the MMIO region whose 2nd stage translation is not present.
>> So that results to arm64-kvm hypervisor executing guest abort handler,
>> like below:
>>
>> kvm_handle_guest_abort() -->
>>   user_mem_abort()--> {
>>
>>      ...
>>      0. checks the vma->flags for the VM_PFNMAP.
>>      1. Since VM_PFNMAP flag is not yet set so force_pte _is_ false;
>>      2. gfn_to_pfn_prot() -->
>>          __gfn_to_pfn_memslot() -->
>>              fixup_user_fault() -->
>>                  handle_mm_fault()-->
>>                      __do_fault() -->
>>                         vma_mmio_fault() --> // vendor's mdev fault handler
>>                          remap_pfn_range()--> // Here sets the VM_PFNMAP
>> 						flag into vma->flags.
>>      3. Now that force_pte is set to false in step-2),
>>         will execute transparent_hugepage_adjust() func and
>>         that lead to Oops [4].
>>   }
>>
>> The proposition is to check is_iomap flag before executing the THP
>> function transparent_hugepage_adjust().
>>
>> [4] THP Oops:
>>> pc: kvm_is_transparent_hugepage+0x18/0xb0
>>> ...
>>> ...
>>> user_mem_abort+0x340/0x9b8
>>> kvm_handle_guest_abort+0x248/0x468
>>> handle_exit+0x150/0x1b0
>>> kvm_arch_vcpu_ioctl_run+0x4d4/0x778
>>> kvm_vcpu_ioctl+0x3c0/0x858
>>> ksys_ioctl+0x84/0xb8
>>> __arm64_sys_ioctl+0x28/0x38
>>
>> Tested on Huawei Kunpeng Taishan-200 arm64 server, Using VFIO-mdev device.
>> Linux tip: 583090b1
>>
>> Fixes: 6d674e28 ("KVM: arm/arm64: Properly handle faulting of device mappings")
>> Signed-off-by: Santosh Shukla <sashukla at nvidia.com>
>> ---
>>   arch/arm64/kvm/mmu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 3d26b47..ff15357 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -1947,7 +1947,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	 * If we are not forced to use page mapping, check if we are
>>   	 * backed by a THP and thus use block mapping if possible.
>>   	 */
>> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
>> +	if (vma_pagesize == PAGE_SIZE && !force_pte && !is_iomap(flags))
>>   		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>>   							   &pfn, &fault_ipa);
>>   	if (writable)
>>
> 



From samuel at sholland.org  Wed Apr 21 05:28:33 2021
From: samuel at sholland.org (Samuel Holland)
Date: Tue, 20 Apr 2021 23:28:33 -0500
Subject: [PATCH 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3 glue
In-Reply-To: <20210421042834.27309-1-samuel@sholland.org>
References: <20210421042834.27309-1-samuel@sholland.org>
Message-ID: <20210421042834.27309-2-samuel@sholland.org>

The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
Represent this by attaching the reset line to a glue layer device.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
new file mode 100644
index 000000000000..86efd6d21ab4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/allwinner,sun50i-h6-dwc3#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner H6 DWC3 USB controller
+
+maintainers:
+  - Chen-Yu Tsai <wens at csie.org>
+  - Maxime Ripard <mripard at kernel.org>
+
+properties:
+  compatible:
+    const: allwinner,sun50i-h6-dwc3
+
+  "#address-cells": true
+
+  "#size-cells": true
+
+  ranges: true
+
+  resets:
+    maxItems: 1
+
+# Required child node:
+
+patternProperties:
+  "^phy@[0-9a-f]+$":
+    $ref: allwinner,sun50i-h6-usb3-phy.yaml#
+
+  "^usb@[0-9a-f]+$":
+    $ref: snps,dwc3.yaml#
+
+required:
+  - compatible
+  - ranges
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/sun50i-h6-ccu.h>
+    #include <dt-bindings/reset/sun50i-h6-ccu.h>
+
+    usb3: usb at 5200000 {
+        compatible = "allwinner,sun50i-h6-dwc3";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        resets = <&ccu RST_BUS_XHCI>;
+
+        dwc3: usb at 5200000 {
+            compatible = "snps,dwc3";
+            reg = <0x05200000 0x10000>;
+            interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&ccu CLK_BUS_XHCI>,
+                     <&ccu CLK_BUS_XHCI>,
+                     <&rtc 0>;
+            clock-names = "ref", "bus_early", "suspend";
+            dr_mode = "host";
+            phys = <&usb3phy>;
+            phy-names = "usb3-phy";
+        };
+
+        usb3phy: phy at 5210000 {
+            compatible = "allwinner,sun50i-h6-usb3-phy";
+            reg = <0x5210000 0x10000>;
+            clocks = <&ccu CLK_USB_PHY1>;
+            resets = <&ccu RST_USB_PHY1>;
+            #phy-cells = <0>;
+        };
+    };
-- 
2.26.3



From samuel at sholland.org  Wed Apr 21 05:28:34 2021
From: samuel at sholland.org (Samuel Holland)
Date: Tue, 20 Apr 2021 23:28:34 -0500
Subject: [PATCH 2/2] arm64: dts: allwinner: h6: Wrap DWC3 and PHY in glue layer
In-Reply-To: <20210421042834.27309-1-samuel@sholland.org>
References: <20210421042834.27309-1-samuel@sholland.org>
Message-ID: <20210421042834.27309-3-samuel@sholland.org>

The USB3 IP in the H6 is organized such that the reset line affects both
the DWC3 core and the PHY. To model that, following the example of
several other platforms, wrap those nodes in a glue layer node.

The inner nodes no longer need to be disabled, since the glue layer is
disabled by default to keep it in reset.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |  6 +-
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    |  6 +-
 .../boot/dts/allwinner/sun50i-h6-pine-h64.dts |  9 ++-
 .../dts/allwinner/sun50i-h6-tanix-tx6.dts     |  6 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 60 ++++++++++---------
 5 files changed, 40 insertions(+), 47 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dde972324e7..5bab12d81468 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -86,10 +86,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -333,6 +329,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
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 38c48130f079..baff16caedb5 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -111,10 +111,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -388,6 +384,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index 647669511381..fe4d74ade6e0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -94,10 +94,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -362,7 +358,10 @@ &usb2phy {
 	status = "okay";
 };
 
+&usb3 {
+	status = "okay";
+};
+
 &usb3phy {
 	phy-supply = <&reg_usb_vbus>;
-	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
index be81330db14f..8cb06df231ab 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
@@ -55,10 +55,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -119,6 +115,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 15b14ed566dc..c5eea8b50ef8 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -797,36 +797,42 @@ ohci0: usb at 5101400 {
 			status = "disabled";
 		};
 
-		dwc3: usb at 5200000 {
-			compatible = "snps,dwc3";
-			reg = <0x05200000 0x10000>;
-			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_XHCI>,
-				 <&ccu CLK_BUS_XHCI>,
-				 <&rtc 0>;
-			clock-names = "ref", "bus_early", "suspend";
+		usb3: usb at 5200000 {
+			compatible = "allwinner,sun50i-h6-dwc3";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
 			resets = <&ccu RST_BUS_XHCI>;
-			/*
-			 * The datasheet of the chip doesn't declare the
-			 * peripheral function, and there's no boards known
-			 * to have a USB Type-B port routed to the port.
-			 * In addition, no one has tested the peripheral
-			 * function yet.
-			 * So set the dr_mode to "host" in the DTSI file.
-			 */
-			dr_mode = "host";
-			phys = <&usb3phy>;
-			phy-names = "usb3-phy";
 			status = "disabled";
-		};
 
-		usb3phy: phy at 5210000 {
-			compatible = "allwinner,sun50i-h6-usb3-phy";
-			reg = <0x5210000 0x10000>;
-			clocks = <&ccu CLK_USB_PHY1>;
-			resets = <&ccu RST_USB_PHY1>;
-			#phy-cells = <0>;
-			status = "disabled";
+			dwc3: usb at 5200000 {
+				compatible = "snps,dwc3";
+				reg = <0x05200000 0x10000>;
+				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ccu CLK_BUS_XHCI>,
+					 <&ccu CLK_BUS_XHCI>,
+					 <&rtc 0>;
+				clock-names = "ref", "bus_early", "suspend";
+				/*
+				 * The datasheet of the chip doesn't declare the
+				 * peripheral function, and there's no boards known
+				 * to have a USB Type-B port routed to the port.
+				 * In addition, no one has tested the peripheral
+				 * function yet.
+				 * So set the dr_mode to "host" in the DTSI file.
+				 */
+				dr_mode = "host";
+				phys = <&usb3phy>;
+				phy-names = "usb3-phy";
+			};
+
+			usb3phy: phy at 5210000 {
+				compatible = "allwinner,sun50i-h6-usb3-phy";
+				reg = <0x5210000 0x10000>;
+				clocks = <&ccu CLK_USB_PHY1>;
+				resets = <&ccu RST_USB_PHY1>;
+				#phy-cells = <0>;
+			};
 		};
 
 		ehci3: usb at 5311000 {
-- 
2.26.3



From samuel at sholland.org  Wed Apr 21 05:28:32 2021
From: samuel at sholland.org (Samuel Holland)
Date: Tue, 20 Apr 2021 23:28:32 -0500
Subject: [PATCH 0/2] Allwinner H6 USB3 device tree updates
Message-ID: <20210421042834.27309-1-samuel@sholland.org>

While implementing support for this USB controller in U-Boot, I noticed
that the reset line alsp affects they PHY. It looks like most platforms
use a separate glue node to represent this, and in fact there is already
a compatible for the H6 listed in drivers/usb/dwc3/dwc3-of-simple.c.

Since this layout matches the usual way of modeling this hardware, it
allows using the existing drivers without adding platform-specific code.

Samuel Holland (2):
  dt-bindings: usb: Document the Allwinner H6 DWC3 glue
  arm64: dts: allwinner: h6: Wrap DWC3 and PHY in glue layer

 .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |  6 +-
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    |  6 +-
 .../boot/dts/allwinner/sun50i-h6-pine-h64.dts |  9 +--
 .../dts/allwinner/sun50i-h6-tanix-tx6.dts     |  6 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 60 ++++++++-------
 6 files changed, 115 insertions(+), 47 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml

-- 
2.26.3



From gshan at redhat.com  Wed Apr 21 07:38:28 2021
From: gshan at redhat.com (Gavin Shan)
Date: Wed, 21 Apr 2021 16:38:28 +1000
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <20210415140328.24200-2-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
Message-ID: <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>

Hi Keqian,

On 4/16/21 12:03 AM, Keqian Zhu wrote:
> The MMIO regions may be unmapped for many reasons and can be remapped
> by stage2 fault path. Map MMIO regions at creation time becomes a
> minor optimization and makes these two mapping path hard to sync.
> 
> Remove the mapping code while keep the useful sanity check.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>   arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
>   1 file changed, 3 insertions(+), 35 deletions(-)
> 

After removing the logic to create stage2 mapping for VM_PFNMAP region,
I think the "do { } while" loop becomes unnecessary and can be dropped
completely. It means the only sanity check is to see if the memory slot
overflows IPA space or not. In that case, KVM_MR_FLAGS_ONLY can be
ignored because the memory slot's base address and length aren't changed
when we have KVM_MR_FLAGS_ONLY.

It seems the patch isn't based on "next" branch because find_vma() was
replaced by find_vma_intersection() by one of my patches :)

Thanks,
Gavin

> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..c59af5ca01b0 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   {
>   	hva_t hva = mem->userspace_addr;
>   	hva_t reg_end = hva + mem->memory_size;
> -	bool writable = !(mem->flags & KVM_MEM_READONLY);
>   	int ret = 0;
>   
>   	if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
> @@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   	mmap_read_lock(current->mm);
>   	/*
>   	 * A memory region could potentially cover multiple VMAs, and any holes
> -	 * between them, so iterate over all of them to find out if we can map
> -	 * any of them right now.
> +	 * between them, so iterate over all of them.
>   	 *
>   	 *     +--------------------------------------------+
>   	 * +---------------+----------------+   +----------------+
> @@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   	 */
>   	do {
>   		struct vm_area_struct *vma = find_vma(current->mm, hva);
> -		hva_t vm_start, vm_end;
>   
>   		if (!vma || vma->vm_start >= reg_end)
>   			break;
>   
> -		/*
> -		 * Take the intersection of this VMA with the memory region
> -		 */
> -		vm_start = max(hva, vma->vm_start);
> -		vm_end = min(reg_end, vma->vm_end);
> -
>   		if (vma->vm_flags & VM_PFNMAP) {
> -			gpa_t gpa = mem->guest_phys_addr +
> -				    (vm_start - mem->userspace_addr);
> -			phys_addr_t pa;
> -
> -			pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
> -			pa += vm_start - vma->vm_start;
> -
>   			/* IO region dirty page logging not allowed */
>   			if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
>   				ret = -EINVAL;
> -				goto out;
> -			}
> -
> -			ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
> -						    vm_end - vm_start,
> -						    writable);
> -			if (ret)
>   				break;
> +			}
>   		}
> -		hva = vm_end;
> +		hva = min(reg_end, vma->vm_end);
>   	} while (hva < reg_end);
>   
> -	if (change == KVM_MR_FLAGS_ONLY)
> -		goto out;
> -
> -	spin_lock(&kvm->mmu_lock);
> -	if (ret)
> -		unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
> -	else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
> -		stage2_flush_memslot(kvm, memslot);
> -	spin_unlock(&kvm->mmu_lock);
> -out:
>   	mmap_read_unlock(current->mm);
>   	return ret;
>   }
> 



From baruch at tkos.co.il  Wed Apr 21 05:45:01 2021
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 21 Apr 2021 07:45:01 +0300
Subject: [PATCH 1/5] PCI: qcom: add support for IPQ60xx PCIe controller
In-Reply-To: <20210420161855.GA3402221@robh.at.kernel.org>
References: <cover.1618916235.git.baruch@tkos.co.il>
 <c6ff03d1377ea9b5ff40ab283c884aeff6254dd9.1618916235.git.baruch@tkos.co.il>
 <20210420161855.GA3402221@robh.at.kernel.org>
Message-ID: <87r1j4kzzm.fsf@tarshish>

Hi Rob,

Thanks for your review.

I have a few comments below.

On Tue, Apr 20 2021, Rob Herring wrote:
> On Tue, Apr 20, 2021 at 02:21:36PM +0300, Baruch Siach wrote:
>> From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
>> 
>> IPQ60xx series of SoCs have one port of PCIe gen 3. Add support for that
>> platform.
>> 
>> The code is based on downstream Codeaurora kernel v5.4. Split out the
>> registers access part from .init into .post_init. Registers are only
>> accessible after phy_power_on().
>> 
>> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
>> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
>> ---
>>  drivers/pci/controller/dwc/pcie-qcom.c | 279 +++++++++++++++++++++++++
>>  1 file changed, 279 insertions(+)
>> 
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index 8a7a300163e5..3e27de744738 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -41,6 +41,31 @@
>>  #define L23_CLK_RMV_DIS				BIT(2)
>>  #define L1_CLK_RMV_DIS				BIT(1)
>>  
>> +#define PCIE_ATU_CR1_OUTBOUND_6_GEN3		0xC00
>> +#define PCIE_ATU_CR2_OUTBOUND_6_GEN3		0xC04
>> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3	0xC08
>> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3	0xC0C
>> +#define PCIE_ATU_LIMIT_OUTBOUND_6_GEN3		0xC10
>> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3	0xC14
>> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3	0xC18
>> +
>> +#define PCIE_ATU_CR1_OUTBOUND_7_GEN3		0xE00
>> +#define PCIE_ATU_CR2_OUTBOUND_7_GEN3		0xE04
>> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3	0xE08
>> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3	0xE0C
>> +#define PCIE_ATU_LIMIT_OUTBOUND_7_GEN3		0xE10
>> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3	0xE14
>> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3 	0xE18
>
> ATU registers are standard DWC registers. Plus upstream now dynamically 
> detects how many ATU regions there are.
>
>> +#define PCIE20_COMMAND_STATUS			0x04
>> +#define BUS_MASTER_EN				0x7
>> +#define PCIE20_DEVICE_CONTROL2_STATUS2		0x98
>> +#define PCIE_CAP_CPL_TIMEOUT_DISABLE		0x10
>
> All PCI standard registers.

PCIE20_COMMAND_STATUS is indeed the common PCI_COMMAND. I could not find
anything that matches PCIE20_DEVICE_CONTROL2_STATUS2. Where should I
look?

>
>> +#define PCIE30_GEN3_RELATED_OFF			0x890
>
> Looks like a DWC port logic register. The define at a minimum goes in 
> the common code. We probably already have one. Code touching the 
> register should ideally be there too (hint: look at the other drivers). 

pcie-tegra194.c uses the equivalent GEN3_RELATED_OFF. So I can move the
definition to a common header. As for the code, I don't know. The tegra
configuration sequence involves other registers as well.

[snip]

>> +static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie)
>> +{
>> +	struct dw_pcie *pci = pcie->pci;
>> +	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
>> +	u32 val;
>> +	int i;
>> +
>> +	writel(SLV_ADDR_SPACE_SZ,
>> +		pcie->parf + PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE);
>> +
>> +	val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
>> +	val &= ~BIT(0);
>
> What's BIT(0)?

I have no idea. I have no access to hardware documentation. I'm just
porting working code from the Codeaurora tree.

>
>> +	writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
>> +
>> +	writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
>> +
>> +	writel(DEVICE_TYPE_RC, pcie->parf + PCIE20_PARF_DEVICE_TYPE);
>> +	writel(BYPASS | MSTR_AXI_CLK_EN | AHB_CLK_EN,
>> +		pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
>> +	writel(RXEQ_RGRDLESS_RXTS | GEN3_ZRXDC_NONCOMPL,
>> +		pci->dbi_base + PCIE30_GEN3_RELATED_OFF);
>> +
>> +	writel(MST_WAKEUP_EN | SLV_WAKEUP_EN | MSTR_ACLK_CGC_DIS
>> +		| SLV_ACLK_CGC_DIS | CORE_CLK_CGC_DIS |
>> +		AUX_PWR_DET | L23_CLK_RMV_DIS | L1_CLK_RMV_DIS,
>> +		pcie->parf + PCIE20_PARF_SYS_CTRL);
>> +
>> +	writel(0, pcie->parf + PCIE20_PARF_Q2A_FLUSH);
>> +
>> +	writel(BUS_MASTER_EN, pci->dbi_base + PCIE20_COMMAND_STATUS);
>
> Pretty sure the DWC core or PCI core does this already.
>
>> +
>> +	writel(DBI_RO_WR_EN, pci->dbi_base + PCIE20_MISC_CONTROL_1_REG);
>> +	writel(PCIE_CAP_LINK1_VAL, pci->dbi_base + offset + PCI_EXP_SLTCAP);
>> +
>> +	/* Configure PCIe link capabilities for ASPM */
>> +	val = readl(pci->dbi_base + offset + PCI_EXP_LNKCAP);
>> +	val &= ~PCI_EXP_LNKCAP_ASPMS;
>> +	writel(val, pci->dbi_base + offset + PCI_EXP_LNKCAP);
>> +
>> +	writel(PCIE_CAP_CPL_TIMEOUT_DISABLE, pci->dbi_base +
>> +		PCIE20_DEVICE_CONTROL2_STATUS2);
>> +
>> +	writel(PCIE_CAP_CURR_DEEMPHASIS | SPEED_GEN3,
>> +			pci->dbi_base + offset + PCI_EXP_DEVCTL2);
>
> This all looks like stuff that should be in the DWC core code. Maybe we 
> need an ASPM disable quirk or something? That's probably somewhat 
> common.

Where in common code should that be? Which part is quirky?

>> +
>> +	for (i = 0;i < 256;i++)
>> +		writel(0x0, pcie->parf + PCIE20_PARF_BDF_TO_SID_TABLE_N
>> +				+ (4 * i));
>> +
>
>> +	writel(0x4, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_6_GEN3);
>> +	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_6_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3);
>> +	writel(0x00107FFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_6_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3);
>> +	writel(0x5, pci->atu_base + PCIE_ATU_CR1_OUTBOUND_7_GEN3);
>> +	writel(0x90000000, pci->atu_base + PCIE_ATU_CR2_OUTBOUND_7_GEN3);
>> +	writel(0x200000, pci->atu_base + PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3);
>> +	writel(0x7FFFFF, pci->atu_base + PCIE_ATU_LIMIT_OUTBOUND_7_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3);
>> +	writel(0x0, pci->atu_base + PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3);
>
> This should all be coming from 'ranges' in the DT. If not, why not?

I'll try to drop it and see if it works. I see that common code
overwrites this area anyway.

>
> If you haven't caught the theme yet, everything outside of PARF register 
> accesses had better have a good explanation why they can't be in common 
> code.
>
>> +
>> +	return 0;
>> +}
>> +
>>  static int qcom_pcie_link_up(struct dw_pcie *pci)
>>  {
>>  	u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
>> @@ -1456,6 +1720,15 @@ static const struct qcom_pcie_ops ops_1_9_0 = {
>>  	.config_sid = qcom_pcie_config_sid_sm8250,
>>  };
>>  
>> +/* Qcom IP rev.: 2.9.0  Synopsys IP rev.: 5.00a */
>> +static const struct qcom_pcie_ops ops_2_9_0 = {
>> +	.get_resources = qcom_pcie_get_resources_2_9_0,
>> +	.init = qcom_pcie_init_2_9_0,
>> +	.post_init = qcom_pcie_post_init_2_9_0,
>> +	.deinit = qcom_pcie_deinit_2_9_0,
>> +	.ltssm_enable = qcom_pcie_2_3_2_ltssm_enable,
>> +};
>> +
>>  static const struct dw_pcie_ops dw_pcie_ops = {
>>  	.link_up = qcom_pcie_link_up,
>>  	.start_link = qcom_pcie_start_link,
>> @@ -1508,6 +1781,11 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>>  		goto err_pm_runtime_put;
>>  	}
>>  
>> +	/* We need ATU for .post_init */
>> +	pci->atu_base = devm_platform_ioremap_resource_byname(pdev, "atu");
>
> The DWC core handles this now.

With ATU code in .post_init gone, we can remove this as well.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


From anshuman.khandual at arm.com  Wed Apr 21 05:48:56 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 10:18:56 +0530
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420093559.23168-1-catalin.marinas@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
Message-ID: <fe4bb655-80bb-d142-f352-89e9c52a90c5@arm.com>



On 4/20/21 3:05 PM, Catalin Marinas wrote:
> Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> does not seem to boot in certain configurations (guest under KVM with
> Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> pages) or 29 (64K page), there's little argument against the memory
> wasted by the mem_map array with SPARSEMEM.
> 
> Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
> remove the corresponding #ifdefs under arch/arm64/.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> ---
> 
> If there are any concerns, please shout (but show numbers as well to
> back it up).
> 
>  arch/arm64/Kconfig                      | 10 +---------
>  arch/arm64/include/asm/kernel-pgtable.h |  2 +-
>  arch/arm64/include/asm/memory.h         |  4 ++--
>  arch/arm64/include/asm/sparsemem.h      |  3 ---
>  arch/arm64/mm/init.c                    |  8 ++------
>  arch/arm64/mm/mmu.c                     |  2 --
>  arch/arm64/mm/ptdump.c                  |  2 --
>  7 files changed, 6 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9b4d629f7628..01c294035928 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,15 +1040,7 @@ source "kernel/Kconfig.hz"
>  config ARCH_SPARSEMEM_ENABLE
>  	def_bool y
>  	select SPARSEMEM_VMEMMAP_ENABLE
> -
> -config ARCH_SPARSEMEM_DEFAULT
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -
> -config ARCH_SELECT_MEMORY_MODEL
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -
> -config ARCH_FLATMEM_ENABLE
> -	def_bool !NUMA
> +	select SPARSEMEM_VMEMMAP
>  
>  config HW_PERF_EVENTS
>  	def_bool y
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index 587c504a4c8b..d44df9d62fc9 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -136,7 +136,7 @@
>   * has a direct correspondence, and needs to appear sufficiently aligned
>   * in the virtual address space.
>   */
> -#if defined(CONFIG_SPARSEMEM_VMEMMAP) && ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
> +#if ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
>  #define ARM64_MEMSTART_ALIGN	(1UL << SECTION_SIZE_BITS)
>  #else
>  #define ARM64_MEMSTART_ALIGN	(1UL << ARM64_MEMSTART_SHIFT)
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b943879c1c24..15018dc59554 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -329,7 +329,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>   */
>  #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
>  
> -#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
> +#if defined(CONFIG_DEBUG_VIRTUAL)

A small nit. Should this be #ifdef CONFIG_DEBUG_VIRTUAL instead ? This is
an user selectable config and the conditional check here does not have an
#elseif part either. But then there are similar such instances else where
on arm64 platform as well.

>  #define page_to_virt(x)	({						\
>  	__typeof__(x) __page = x;					\
>  	void *__addr = __va(page_to_phys(__page));			\
> @@ -349,7 +349,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>  	u64 __addr = VMEMMAP_START + (__idx * sizeof(struct page));	\
>  	(struct page *)__addr;						\
>  })
> -#endif /* !CONFIG_SPARSEMEM_VMEMMAP || CONFIG_DEBUG_VIRTUAL */
> +#endif /* CONFIG_DEBUG_VIRTUAL */
>  
>  #define virt_addr_valid(addr)	({					\
>  	__typeof__(addr) __addr = __tag_reset(addr);			\
> diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h
> index eb4a75d720ed..4b73463423c3 100644
> --- a/arch/arm64/include/asm/sparsemem.h
> +++ b/arch/arm64/include/asm/sparsemem.h
> @@ -5,7 +5,6 @@
>  #ifndef __ASM_SPARSEMEM_H
>  #define __ASM_SPARSEMEM_H
>  
> -#ifdef CONFIG_SPARSEMEM
>  #define MAX_PHYSMEM_BITS	CONFIG_ARM64_PA_BITS
>  
>  /*
> @@ -27,6 +26,4 @@
>  #define SECTION_SIZE_BITS 27
>  #endif /* CONFIG_ARM64_64K_PAGES */
>  
> -#endif /* CONFIG_SPARSEMEM*/
> -
>  #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..a205538aa1d5 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -220,6 +220,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>  int pfn_valid(unsigned long pfn)
>  {
>  	phys_addr_t addr = PFN_PHYS(pfn);
> +	struct mem_section *ms;
>  
>  	/*
>  	 * Ensure the upper PAGE_SHIFT bits are clear in the
> @@ -230,10 +231,6 @@ int pfn_valid(unsigned long pfn)
>  	if (PHYS_PFN(addr) != pfn)
>  		return 0;
>  
> -#ifdef CONFIG_SPARSEMEM
> -{
> -	struct mem_section *ms;
> -
>  	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>  		return 0;
>  
> @@ -252,8 +249,7 @@ int pfn_valid(unsigned long pfn)
>  	 */
>  	if (!early_section(ms))
>  		return pfn_section_valid(ms, pfn);
> -}
> -#endif
> +
>  	return memblock_is_map_memory(addr);
>  }
>  EXPORT_SYMBOL(pfn_valid);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index fac957ff5187..af0ebcad3e1f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1113,7 +1113,6 @@ static void free_empty_tables(unsigned long addr, unsigned long end,
>  }
>  #endif
>  
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>  #if !ARM64_SWAPPER_USES_SECTION_MAPS
>  int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>  		struct vmem_altmap *altmap)
> @@ -1177,7 +1176,6 @@ void vmemmap_free(unsigned long start, unsigned long end,
>  	free_empty_tables(start, end, VMEMMAP_START, VMEMMAP_END);
>  #endif
>  }
> -#endif	/* CONFIG_SPARSEMEM_VMEMMAP */
>  
>  static inline pud_t *fixmap_pud(unsigned long addr)
>  {
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index a50e92ea1878..a1937dfff31c 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -51,10 +51,8 @@ static struct addr_marker address_markers[] = {
>  	{ FIXADDR_TOP,			"Fixmap end" },
>  	{ PCI_IO_START,			"PCI I/O start" },
>  	{ PCI_IO_END,			"PCI I/O end" },
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>  	{ VMEMMAP_START,		"vmemmap start" },
>  	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
> -#endif
>  	{ -1,				NULL },
>  };
>  
> 

Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>


From drinkcat at chromium.org  Wed Apr 21 06:28:51 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 13:28:51 +0800
Subject: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
Message-ID: <20210421052855.1279713-1-drinkcat@chromium.org>

Hi!

This is just a rebase of the v11, untested (but it seems like
Neil Armstrong recently tested it), with small changes in
binding and dts. v11 cover follows:

Follow-up on the v5 [1], things have gotten significantly
better in the last year, thanks to the efforts on Bifrost
support by the Collabora team (and probably others I'm not
aware of).

I've been testing this series on a MT8183/kukui device, with a
chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
mesa 20.3.2 (lots of artifacts though).

devfreq is currently not supported, as we'll need:
 - Clock core support for switching the GPU core clock (see 2/4).
 - Platform-specific handling of the 2-regulator (see 3/4).

Since the latter is easy to detect, patch 3/4 just disables
devfreq if the more than one regulator is specified in the
compatible matching table.

[1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drinkcat at chromium.org/
[2] https://crrev.com/c/2608070

Changes in v13:
 - devfreq: Fix conflict resolution mistake when rebasing, didn't
   even compile. Oops.

Changes in v12:
 - binding: Fix min/maxItems logic (Rob Herring)
 - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).

Changes in v11:
 - binding: power-domain-names not power-domainS-names
 - mt8183*.dts: remove incorrect supply-names

Changes in v10:
 - Fix the binding to make sure sram-supply property can be provided.

Changes in v9:
 - Explain why devfreq needs to be disabled for GPUs with >1
   regulators.

Changes in v8:
 - Use DRM_DEV_INFO instead of ERROR

Changes in v7:
 - Fix GPU ID in commit message
 - Fix GPU ID in commit message

Changes in v6:
 - Rebased, actually tested with recent mesa driver.
 - Add gpu regulators to kukui dtsi as well.
 - Power domains are now attached to spm, not scpsys
 - Drop R-B.
 - devfreq: New change
 - Context conflicts, reflow the code.
 - Use ARRAY_SIZE for power domains too.

Changes in v5:
 - Rename "2d" power domain to "core2"
 - Rename "2d" power domain to "core2" (keep R-B again).
 - Change power domain name from 2d to core2.

Changes in v4:
 - Add power-domain-names description
   (kept Alyssa's reviewed-by as the change is minor)
 - Add power-domain-names to describe the 3 domains.
   (kept Alyssa's reviewed-by as the change is minor)
 - Add power domain names.

Changes in v3:
 - Match mt8183-mali instead of bifrost, as we require special
   handling for the 2 regulators and 3 power domains.

Changes in v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu at .

Nicolas Boichat (4):
  dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
  arm64: dts: mt8183: Add node for the Mali GPU
  drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
  drm/panfrost: Add mt8183-mali compatible string

 .../bindings/gpu/arm,mali-bifrost.yaml        |  30 ++++-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
 .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
 .../boot/dts/mediatek/mt8183-pumpkin.dts      |   5 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
 drivers/gpu/drm/panfrost/panfrost_devfreq.c   |   9 ++
 drivers/gpu/drm/panfrost/panfrost_drv.c       |  10 ++
 7 files changed, 168 insertions(+), 1 deletion(-)

-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 06:28:52 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 13:28:52 +0800
Subject: [PATCH v13 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
In-Reply-To: <20210421052855.1279713-1-drinkcat@chromium.org>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
Message-ID: <20210421132841.v13.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>

Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
---

(no changes since v12)

Changes in v12:
 - binding: Fix min/maxItems logic (Rob Herring)

Changes in v11:
 - binding: power-domain-names not power-domainS-names

Changes in v10:
 - Fix the binding to make sure sram-supply property can be provided.

Changes in v6:
 - Rebased, actually tested with recent mesa driver.

Changes in v5:
 - Rename "2d" power domain to "core2"

Changes in v4:
 - Add power-domain-names description
   (kept Alyssa's reviewed-by as the change is minor)

 .../bindings/gpu/arm,mali-bifrost.yaml        | 30 ++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 184492162e7e..b22cd8f1b015 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -17,6 +17,7 @@ properties:
     items:
       - enum:
           - amlogic,meson-g12a-mali
+          - mediatek,mt8183-mali
           - realtek,rtd1619-mali
           - rockchip,px30-mali
       - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable
@@ -41,10 +42,13 @@ properties:
 
   mali-supply: true
 
+  sram-supply: true
+
   operating-points-v2: true
 
   power-domains:
-    maxItems: 1
+    minItems: 1
+    maxItems: 3
 
   resets:
     maxItems: 2
@@ -87,6 +91,30 @@ allOf:
     then:
       required:
         - resets
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt8183-mali
+    then:
+      properties:
+        power-domains:
+          minItems: 3
+        power-domain-names:
+          items:
+            - const: core0
+            - const: core1
+            - const: core2
+
+      required:
+        - sram-supply
+        - power-domains
+        - power-domain-names
+    else:
+      properties:
+        power-domains:
+          maxItems: 1
+        sram-supply: false
 
 examples:
   - |
-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 06:28:53 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 13:28:53 +0800
Subject: [PATCH v13 2/4] arm64: dts: mt8183: Add node for the Mali GPU
In-Reply-To: <20210421052855.1279713-1-drinkcat@chromium.org>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
Message-ID: <20210421132841.v13.2.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid>

Add a basic GPU node for mt8183.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
---
The binding we use with out-of-tree Mali drivers includes more
clocks, this is used for devfreq: the out-of-tree driver switches
clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
switches clk_mux back to clk_main_parent:
(see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
clocks =
        <&topckgen CLK_TOP_MFGPLL_CK>,
        <&topckgen CLK_TOP_MUX_MFG>,
        <&clk26m>,
        <&mfgcfg CLK_MFG_BG3D>;
clock-names =
        "clk_main_parent",
        "clk_mux",
        "clk_sub_parent",
        "subsys_mfg_cg";
(based on discussions, this probably belongs in the clock core)

This only matters for devfreq, that is disabled anyway as we don't
have platform-specific code to handle >1 supplies.

(no changes since v12)

Changes in v12:
 - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).

Changes in v11:
 - mt8183*.dts: remove incorrect supply-names

Changes in v6:
 - Add gpu regulators to kukui dtsi as well.
 - Power domains are now attached to spm, not scpsys
 - Drop R-B.

Changes in v5:
 - Rename "2d" power domain to "core2" (keep R-B again).

Changes in v4:
 - Add power-domain-names to describe the 3 domains.
   (kept Alyssa's reviewed-by as the change is minor)

Changes in v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu at .

 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
 .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
 .../boot/dts/mediatek/mt8183-pumpkin.dts      |   5 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
 4 files changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index edff1e03e6fe..7bc0a6a7fadf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -42,6 +42,11 @@ &auxadc {
 	status = "okay";
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index ff56bcfa3370..e4e54be1c2b2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -279,6 +279,11 @@ dsi_out: endpoint {
 	};
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c0_pins>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
index 0aff5eb52e88..ee912825cfc6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
@@ -68,6 +68,11 @@ &auxadc {
 	status = "okay";
 };
 
+&gpu {
+	mali-supply = <&mt6358_vgpu_reg>;
+	sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
 &i2c0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c5e822b6b77a..c75fdeea8aa4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1118,6 +1118,111 @@ mfgcfg: syscon at 13000000 {
 			#clock-cells = <1>;
 		};
 
+		gpu: gpu at 13040000 {
+			compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+			reg = <0 0x13040000 0 0x4000>;
+			interrupts =
+				<GIC_SPI 280 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_SPI 279 IRQ_TYPE_LEVEL_LOW>,
+				<GIC_SPI 278 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-names = "job", "mmu", "gpu";
+
+			clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
+
+			power-domains =
+				<&spm MT8183_POWER_DOMAIN_MFG_CORE0>,
+				<&spm MT8183_POWER_DOMAIN_MFG_CORE1>,
+				<&spm MT8183_POWER_DOMAIN_MFG_2D>;
+			power-domain-names = "core0", "core1", "core2";
+
+			operating-points-v2 = <&gpu_opp_table>;
+		};
+
+		gpu_opp_table: opp_table0 {
+			compatible = "operating-points-v2";
+			opp-shared;
+
+			opp-300000000 {
+				opp-hz = /bits/ 64 <300000000>;
+				opp-microvolt = <625000>, <850000>;
+			};
+
+			opp-320000000 {
+				opp-hz = /bits/ 64 <320000000>;
+				opp-microvolt = <631250>, <850000>;
+			};
+
+			opp-340000000 {
+				opp-hz = /bits/ 64 <340000000>;
+				opp-microvolt = <637500>, <850000>;
+			};
+
+			opp-360000000 {
+				opp-hz = /bits/ 64 <360000000>;
+				opp-microvolt = <643750>, <850000>;
+			};
+
+			opp-380000000 {
+				opp-hz = /bits/ 64 <380000000>;
+				opp-microvolt = <650000>, <850000>;
+			};
+
+			opp-400000000 {
+				opp-hz = /bits/ 64 <400000000>;
+				opp-microvolt = <656250>, <850000>;
+			};
+
+			opp-420000000 {
+				opp-hz = /bits/ 64 <420000000>;
+				opp-microvolt = <662500>, <850000>;
+			};
+
+			opp-460000000 {
+				opp-hz = /bits/ 64 <460000000>;
+				opp-microvolt = <675000>, <850000>;
+			};
+
+			opp-500000000 {
+				opp-hz = /bits/ 64 <500000000>;
+				opp-microvolt = <687500>, <850000>;
+			};
+
+			opp-540000000 {
+				opp-hz = /bits/ 64 <540000000>;
+				opp-microvolt = <700000>, <850000>;
+			};
+
+			opp-580000000 {
+				opp-hz = /bits/ 64 <580000000>;
+				opp-microvolt = <712500>, <850000>;
+			};
+
+			opp-620000000 {
+				opp-hz = /bits/ 64 <620000000>;
+				opp-microvolt = <725000>, <850000>;
+			};
+
+			opp-653000000 {
+				opp-hz = /bits/ 64 <653000000>;
+				opp-microvolt = <743750>, <850000>;
+			};
+
+			opp-698000000 {
+				opp-hz = /bits/ 64 <698000000>;
+				opp-microvolt = <768750>, <868750>;
+			};
+
+			opp-743000000 {
+				opp-hz = /bits/ 64 <743000000>;
+				opp-microvolt = <793750>, <893750>;
+			};
+
+			opp-800000000 {
+				opp-hz = /bits/ 64 <800000000>;
+				opp-microvolt = <825000>, <925000>;
+			};
+		};
+
 		mmsys: syscon at 14000000 {
 			compatible = "mediatek,mt8183-mmsys", "syscon";
 			reg = <0 0x14000000 0 0x1000>;
-- 
2.31.1.368.gbe11c130af-goog



From drinkcat at chromium.org  Wed Apr 21 06:28:55 2021
From: drinkcat at chromium.org (Nicolas Boichat)
Date: Wed, 21 Apr 2021 13:28:55 +0800
Subject: [PATCH v13 4/4] drm/panfrost: Add mt8183-mali compatible string
In-Reply-To: <20210421052855.1279713-1-drinkcat@chromium.org>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
Message-ID: <20210421132841.v13.4.I5f6b04431828ec9c3e41e65f3337cec6a127480d@changeid>

Add support for MT8183's G72 Bifrost.

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
Reviewed-by: Steven Price <steven.price at arm.com>
---

(no changes since v7)

Changes in v7:
 - Fix GPU ID in commit message

Changes in v6:
 - Context conflicts, reflow the code.
 - Use ARRAY_SIZE for power domains too.

Changes in v5:
 - Change power domain name from 2d to core2.

Changes in v4:
 - Add power domain names.

Changes in v3:
 - Match mt8183-mali instead of bifrost, as we require special
   handling for the 2 regulators and 3 power domains.

 drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
 	.vendor_quirk = panfrost_gpu_amlogic_quirk,
 };
 
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" };
+static const struct panfrost_compatible mediatek_mt8183_data = {
+	.num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+	.supply_names = mediatek_mt8183_supplies,
+	.num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+	.pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
 static const struct of_device_id dt_match[] = {
 	/* Set first to probe before the generic compatibles */
 	{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
 	{ .compatible = "arm,mali-t860", .data = &default_data, },
 	{ .compatible = "arm,mali-t880", .data = &default_data, },
 	{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+	{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
 	{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
2.31.1.368.gbe11c130af-goog



From rppt at kernel.org  Wed Apr 21 06:32:55 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 08:32:55 +0300
Subject: [PATCH v1 3/4] arm64: decouple check whether pfn is in linear
 map from pfn_valid()
In-Reply-To: <29b51a80-1543-fcec-6f5b-5ae21b78e1e9@redhat.com>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-4-rppt@kernel.org>
 <29b51a80-1543-fcec-6f5b-5ae21b78e1e9@redhat.com>
Message-ID: <YH+5ByJUSSXY3kU5@kernel.org>

On Tue, Apr 20, 2021 at 05:57:57PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing else.
> > 
> > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > linear map vs those that require ioremap() to access them.
> > 
> > Introduce a dedicated pfn_is_map_memory() wrapper for
> > memblock_is_map_memory() to perform such check and use it where
> > appropriate.
> > 
> > Using a wrapper allows to avoid cyclic include dependencies.
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   arch/arm64/include/asm/memory.h | 2 +-
> >   arch/arm64/include/asm/page.h   | 1 +
> >   arch/arm64/kvm/mmu.c            | 2 +-
> >   arch/arm64/mm/init.c            | 6 ++++++
> >   arch/arm64/mm/ioremap.c         | 4 ++--
> >   arch/arm64/mm/mmu.c             | 2 +-
> >   6 files changed, 12 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 0aabc3be9a75..194f9f993d30 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >   #define virt_addr_valid(addr)	({					\
> >   	__typeof__(addr) __addr = __tag_reset(addr);			\
> > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
> >   })
> >   void dump_mem_limit(void);
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 012cffc574e8..99a6da91f870 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> >   typedef struct page *pgtable_t;
> >   extern int pfn_valid(unsigned long);
> > +extern int pfn_is_map_memory(unsigned long);
> >   #include <asm/memory.h>
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 8711894db8c2..23dd99e29b23 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> >   static bool kvm_is_device_pfn(unsigned long pfn)
> >   {
> > -	return !pfn_valid(pfn);
> > +	return !pfn_is_map_memory(pfn);
> >   }
> >   /*
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 3685e12aba9b..c54e329aca15 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
> >   }
> >   EXPORT_SYMBOL(pfn_valid);
> > +int pfn_is_map_memory(unsigned long pfn)
> > +{
> 
> I think you might have to add (see pfn_valid())
> 
> if (PHYS_PFN(PFN_PHYS(pfn)) != pfn)
> 	return 0;
> 
> to catch false positives.
 
Yeah, makes sense. 

> > +	return memblock_is_map_memory(PFN_PHYS(pfn));
> > +}
> > +EXPORT_SYMBOL(pfn_is_map_memory);
> > +
> >   static phys_addr_t memory_limit = PHYS_ADDR_MAX;
> >   /*
> > diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> > index b5e83c46b23e..b7c81dacabf0 100644
> > --- a/arch/arm64/mm/ioremap.c
> > +++ b/arch/arm64/mm/ioremap.c
> > @@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
> >   	/*
> >   	 * Don't allow RAM to be mapped.
> >   	 */
> > -	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> > +	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
> >   		return NULL;
> >   	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> > @@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
> >   void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
> >   {
> >   	/* For normal memory we already have a cacheable mapping. */
> > -	if (pfn_valid(__phys_to_pfn(phys_addr)))
> > +	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
> >   		return (void __iomem *)__phys_to_virt(phys_addr);
> >   	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 5d9550fdb9cf..26045e9adbd7 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
> >   pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> >   			      unsigned long size, pgprot_t vma_prot)
> >   {
> > -	if (!pfn_valid(pfn))
> > +	if (!pfn_is_map_memory(pfn))
> >   		return pgprot_noncached(vma_prot);
> >   	else if (file->f_flags & O_SYNC)
> >   		return pgprot_writecombine(vma_prot);
> > 
> 
> As discussed, in the future it would be nice if we could just rely on the
> memmap state. There are cases where pfn_is_map_memory() will now be slower
> than pfn_valid() -- e.g., we don't check for valid_section() in case of
> CONFIG_SPARSEMEM. This would apply where pfn_valid() would have returned
> "0".
>
> As we're not creating the direct map, kern_addr_valid() shouldn't need love.
> It'd be some kind of ugly if some generic code used by arm64 would be
> relying in case of arm64 on pfn_valid() to return the expected result; I
> doubt it.

No doubt there is a room for further improvement in this area.
 
> Acked-by: David Hildenbrand <david at redhat.com>

Thanks!

-- 
Sincerely yours,
Mike.


From hch at lst.de  Wed Apr 21 06:50:28 2021
From: hch at lst.de (hch at lst.de)
Date: Wed, 21 Apr 2021 07:50:28 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
 <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
 <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>
 <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
Message-ID: <20210421055028.GA28910@lst.de>

On Tue, Apr 20, 2021 at 11:20:19PM +0200, Arnd Bergmann wrote:
> In that case, there should be no problem for you.
> 
> The main issue is with system calls and ioctls that contain a misaligned
> struct member like
> 
> struct s {
>        u32 a;
>        u64 b;
> };
> 
> Passing this structure by reference from a 32-bit user space application
> to a 64-bit kernel with different alignment constraints means that the
> kernel has to convert the structure layout. See
> compat_ioctl_preallocate() in fs/ioctl.c for one such example.

We've also had this problem with some on-disk structures in the past,
but hopefully people desining those have learnt the lesson by now.


From rppt at kernel.org  Wed Apr 21 06:52:29 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 08:52:29 +0300
Subject: [PATCH v1 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <8e7171e7-a85c-6066-4ab6-d2bc98ec103b@redhat.com>
References: <20210420090925.7457-1-rppt@kernel.org>
 <20210420090925.7457-5-rppt@kernel.org>
 <8e7171e7-a85c-6066-4ab6-d2bc98ec103b@redhat.com>
Message-ID: <YH+9nbDkPyVav3xn@kernel.org>

On Tue, Apr 20, 2021 at 06:00:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> > 
> > * Parts of the memory map are freed during boot. This makes it necessary to
> >    verify that there is actual physical memory that corresponds to a pfn
> >    which is done by querying memblock.
> > 
> > * There are NOMAP memory regions. These regions are not mapped in the
> >    linear map and until the previous commit the struct pages representing
> >    these areas had default values.
> > 
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> > 
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
> > 
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >   arch/arm64/Kconfig   | 3 ---
> >   arch/arm64/mm/init.c | 4 ++--
> >   2 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> >   	def_bool y
> >   	depends on NUMA
> > -config HOLES_IN_ZONE
> > -	def_bool y
> > -
> >   source "kernel/Kconfig.hz"
> >   config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index c54e329aca15..370f33765b64 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >   	/*
> >   	 * ZONE_DEVICE memory does not have the memblock entries.
> > -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> > +	 * memblock_is_memory() check for ZONE_DEVICE based
> >   	 * addresses will always fail. Even the normal hotplugged
> >   	 * memory will never have MEMBLOCK_NOMAP flag set in their
> >   	 * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> >   		return pfn_section_valid(ms, pfn);
> >   }
> >   #endif
> > -	return memblock_is_map_memory(addr);
> > +	return memblock_is_memory(addr);
> >   }
> >   EXPORT_SYMBOL(pfn_valid);
> > 
> 
> What are the steps needed to get rid of custom pfn_valid() completely?
> 
> I'd assume we would have to stop freeing parts of the mem map during boot.
> How relevant is that for arm64 nowadays, especially with reduced section
> sizes?

Yes, for arm64 to use the generic pfn_valid() it'd need to stop freeing
parts of the memory map.

Presuming struct page is 64 bytes, the memory map takes 2M per section in
the worst case (128M per section, 4k pages). 

So for systems that have less than 128M populated in each section freeing
unused memory map would mean significant savings.

But nowadays when a clock has at least 1G of RAM I doubt this is relevant
to many systems if at all.

-- 
Sincerely yours,
Mike.


From gshan at redhat.com  Wed Apr 21 08:52:58 2021
From: gshan at redhat.com (Gavin Shan)
Date: Wed, 21 Apr 2021 17:52:58 +1000
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <20210415140328.24200-3-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
Message-ID: <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>

Hi Keqian,

On 4/16/21 12:03 AM, Keqian Zhu wrote:
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
> 
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
> 
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
> 
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
> 
> This adds get_vma_page_shift() to get page shift for both normal
> memory and device MMIO region, and check these two points when
> selecting block mapping size for MMIO region.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>   arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>   1 file changed, 51 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..5a1cc7751e6d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>   	return PAGE_SIZE;
>   }
>   
> +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> +{
> +	unsigned long pa;
> +
> +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> +		return huge_page_shift(hstate_vma(vma));
> +
> +	if (!(vma->vm_flags & VM_PFNMAP))
> +		return PAGE_SHIFT;
> +
> +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> +

I don't understand how VM_PFNMAP is set for hugetlbfs related vma.
I think they are exclusive, meaning the flag is never set for
hugetlbfs vma. If it's true, VM_PFNMAP needn't be checked on hugetlbfs
vma and the VM_BUG_ON() becomes unnecessary.

> +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +

There is "switch(...)" fallback mechanism in user_mem_abort(). PUD_SIZE/PMD_SIZE
can be downgraded accordingly if the addresses fails in the alignment check
by fault_supports_stage2_huge_mapping(). I think it would make user_mem_abort()
simplified if the logic can be moved to get_vma_page_shift().

Another question if we need the check from fault_supports_stage2_huge_mapping()
if VM_PFNMAP area is going to be covered by block mapping. If so, the "switch(...)"
fallback mechanism needs to be part of get_vma_page_shift().

>   static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   			  struct kvm_memory_slot *memslot, unsigned long hva,
>   			  unsigned long fault_status)
> @@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   	}
>   
> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> +	/*
> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> +	 * get block mapping for device MMIO region.
> +	 */
>   	mmap_read_lock(current->mm);
>   	vma = find_vma_intersection(current->mm, hva, hva + 1);
>   	if (unlikely(!vma)) {
> @@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   	}
>   
> -	if (is_vm_hugetlb_page(vma))
> -		vma_shift = huge_page_shift(hstate_vma(vma));
> -	else
> -		vma_shift = PAGE_SHIFT;
> -
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	/*
> +	 * logging_active is guaranteed to never be true for VM_PFNMAP
> +	 * memslots.
> +	 */
> +	if (logging_active) {
>   		force_pte = true;
>   		vma_shift = PAGE_SHIFT;
> +	} else {
> +		vma_shift = get_vma_page_shift(vma, hva);
>   	}
>   
>   	switch (vma_shift) {
> @@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   
>   	if (kvm_is_device_pfn(pfn)) {
> +		/*
> +		 * If the page was identified as device early by looking at
> +		 * the VMA flags, vma_pagesize is already representing the
> +		 * largest quantity we can map.  If instead it was mapped
> +		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> +		 * and must not be upgraded.
> +		 *
> +		 * In both cases, we don't let transparent_hugepage_adjust()
> +		 * change things at the last minute.
> +		 */
>   		device = true;
> -		force_pte = true;
>   	} else if (logging_active && !write_fault) {
>   		/*
>   		 * Only actually map the page as writable if this was a write
> @@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   	 * If we are not forced to use page mapping, check if we are
>   	 * backed by a THP and thus use block mapping if possible.
>   	 */
> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> +	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
>   		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>   							   &pfn, &fault_ipa);
>   	if (writable)
> 

Thanks,
Gavin



From zhukeqian1 at huawei.com  Wed Apr 21 07:17:44 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 21 Apr 2021 14:17:44 +0800
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
Message-ID: <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>

Hi Gavin,

On 2021/4/21 14:20, Gavin Shan wrote:
> Hi Keqian and Santosh,
> 
> On 4/21/21 12:59 PM, Keqian Zhu wrote:
>> On 2020/10/22 0:16, Santosh Shukla wrote:
>>> The Commit:6d674e28 introduces a notion to detect and handle the
>>> device mapping. The commit checks for the VM_PFNMAP flag is set
>>> in vma->flags and if set then marks force_pte to true such that
>>> if force_pte is true then ignore the THP function check
>>> (/transparent_hugepage_adjust()).
>>>
>>> There could be an issue with the VM_PFNMAP flag setting and checking.
>>> For example consider a case where the mdev vendor driver register's
>>> the vma_fault handler named vma_mmio_fault(), which maps the
>>> host MMIO region in-turn calls remap_pfn_range() and maps
>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>>> the VM_PFNMAP flag into vma->flags.
>> Could you give the name of the mdev vendor driver that triggers this issue?
>> I failed to find one according to your description. Thanks.
>>
> 
> I think it would be fixed in driver side to set VM_PFNMAP in
> its mmap() callback (call_mmap()), like vfio PCI driver does.
> It means it won't be delayed until page fault is issued and
> remap_pfn_range() is called. It's determined from the beginning
> that the vma associated the mdev vendor driver is serving as
> PFN remapping purpose. So the vma should be populated completely,
> including the VM_PFNMAP flag before it becomes visible to user
> space.
> 
> The example can be found from vfio driver in drivers/vfio/pci/vfio_pci.c:
>     vfio_pci_mmap:       VM_PFNMAP is set for the vma
>     vfio_pci_mmap_fault: remap_pfn_range() is called
Right. I have discussed the above with Marc. I want to find the driver
to fix it. However, AFAICS, there is no driver matches the description...

Thanks,
Keqian

> 
> Thanks,
> Gavin
> 
>>>
>>> Now lets assume a mmio fault handing flow where guest first access
>>> the MMIO region whose 2nd stage translation is not present.
>>> So that results to arm64-kvm hypervisor executing guest abort handler,
>>> like below:
>>>
>>> kvm_handle_guest_abort() -->
>>>   user_mem_abort()--> {
>>>
>>>      ...
>>>      0. checks the vma->flags for the VM_PFNMAP.
>>>      1. Since VM_PFNMAP flag is not yet set so force_pte _is_ false;
>>>      2. gfn_to_pfn_prot() -->
>>>          __gfn_to_pfn_memslot() -->
>>>              fixup_user_fault() -->
>>>                  handle_mm_fault()-->
>>>                      __do_fault() -->
>>>                         vma_mmio_fault() --> // vendor's mdev fault handler
>>>                          remap_pfn_range()--> // Here sets the VM_PFNMAP
>>>                         flag into vma->flags.
>>>      3. Now that force_pte is set to false in step-2),
>>>         will execute transparent_hugepage_adjust() func and
>>>         that lead to Oops [4].
>>>   }
>>>
>>> The proposition is to check is_iomap flag before executing the THP
>>> function transparent_hugepage_adjust().
>>>
>>> [4] THP Oops:
>>>> pc: kvm_is_transparent_hugepage+0x18/0xb0
>>>> ...
>>>> ...
>>>> user_mem_abort+0x340/0x9b8
>>>> kvm_handle_guest_abort+0x248/0x468
>>>> handle_exit+0x150/0x1b0
>>>> kvm_arch_vcpu_ioctl_run+0x4d4/0x778
>>>> kvm_vcpu_ioctl+0x3c0/0x858
>>>> ksys_ioctl+0x84/0xb8
>>>> __arm64_sys_ioctl+0x28/0x38
>>>
>>> Tested on Huawei Kunpeng Taishan-200 arm64 server, Using VFIO-mdev device.
>>> Linux tip: 583090b1
>>>
>>> Fixes: 6d674e28 ("KVM: arm/arm64: Properly handle faulting of device mappings")
>>> Signed-off-by: Santosh Shukla <sashukla at nvidia.com>
>>> ---
>>>   arch/arm64/kvm/mmu.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 3d26b47..ff15357 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -1947,7 +1947,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>>        * If we are not forced to use page mapping, check if we are
>>>        * backed by a THP and thus use block mapping if possible.
>>>        */
>>> -    if (vma_pagesize == PAGE_SIZE && !force_pte)
>>> +    if (vma_pagesize == PAGE_SIZE && !force_pte && !is_iomap(flags))
>>>           vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>>>                                  &pfn, &fault_ipa);
>>>       if (writable)
>>>
>>
> 
> .
> 


From zhukeqian1 at huawei.com  Wed Apr 21 07:28:07 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 21 Apr 2021 14:28:07 +0800
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
 <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
Message-ID: <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>

Hi Gavin,

On 2021/4/21 14:38, Gavin Shan wrote:
> Hi Keqian,
> 
> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>> The MMIO regions may be unmapped for many reasons and can be remapped
>> by stage2 fault path. Map MMIO regions at creation time becomes a
>> minor optimization and makes these two mapping path hard to sync.
>>
>> Remove the mapping code while keep the useful sanity check.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> ---
>>   arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
>>   1 file changed, 3 insertions(+), 35 deletions(-)
>>
> 
> After removing the logic to create stage2 mapping for VM_PFNMAP region,
> I think the "do { } while" loop becomes unnecessary and can be dropped
> completely. It means the only sanity check is to see if the memory slot
> overflows IPA space or not. In that case, KVM_MR_FLAGS_ONLY can be
> ignored because the memory slot's base address and length aren't changed
> when we have KVM_MR_FLAGS_ONLY.
Maybe not exactly. Here we do an important sanity check that we shouldn't
log dirty for memslots with VM_PFNMAP.


> 
> It seems the patch isn't based on "next" branch because find_vma() was
> replaced by find_vma_intersection() by one of my patches :)
Yep, I remember it. I will replace it at next merge window...

Thanks,
Keqian

> 
> Thanks,
> Gavin
> 
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 8711894db8c2..c59af5ca01b0 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>   {
>>       hva_t hva = mem->userspace_addr;
>>       hva_t reg_end = hva + mem->memory_size;
>> -    bool writable = !(mem->flags & KVM_MEM_READONLY);
>>       int ret = 0;
>>         if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
>> @@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>       mmap_read_lock(current->mm);
>>       /*
>>        * A memory region could potentially cover multiple VMAs, and any holes
>> -     * between them, so iterate over all of them to find out if we can map
>> -     * any of them right now.
>> +     * between them, so iterate over all of them.
>>        *
>>        *     +--------------------------------------------+
>>        * +---------------+----------------+   +----------------+
>> @@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>        */
>>       do {
>>           struct vm_area_struct *vma = find_vma(current->mm, hva);
>> -        hva_t vm_start, vm_end;
>>             if (!vma || vma->vm_start >= reg_end)
>>               break;
>>   -        /*
>> -         * Take the intersection of this VMA with the memory region
>> -         */
>> -        vm_start = max(hva, vma->vm_start);
>> -        vm_end = min(reg_end, vma->vm_end);
>> -
>>           if (vma->vm_flags & VM_PFNMAP) {
>> -            gpa_t gpa = mem->guest_phys_addr +
>> -                    (vm_start - mem->userspace_addr);
>> -            phys_addr_t pa;
>> -
>> -            pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
>> -            pa += vm_start - vma->vm_start;
>> -
>>               /* IO region dirty page logging not allowed */
>>               if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
>>                   ret = -EINVAL;
>> -                goto out;
>> -            }
>> -
>> -            ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
>> -                            vm_end - vm_start,
>> -                            writable);
>> -            if (ret)
>>                   break;
>> +            }
>>           }
>> -        hva = vm_end;
>> +        hva = min(reg_end, vma->vm_end);
>>       } while (hva < reg_end);
>>   -    if (change == KVM_MR_FLAGS_ONLY)
>> -        goto out;
>> -
>> -    spin_lock(&kvm->mmu_lock);
>> -    if (ret)
>> -        unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
>> -    else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
>> -        stage2_flush_memslot(kvm, memslot);
>> -    spin_unlock(&kvm->mmu_lock);
>> -out:
>>       mmap_read_unlock(current->mm);
>>       return ret;
>>   }
>>
> 
> .
> 


From zhukeqian1 at huawei.com  Wed Apr 21 07:36:55 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Wed, 21 Apr 2021 14:36:55 +0800
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>
Message-ID: <105a403a-e48b-15bc-44ff-0ff34f7d2194@huawei.com>



On 2021/4/21 15:52, Gavin Shan wrote:
> Hi Keqian,
> 
> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>> The MMIO region of a device maybe huge (GB level), try to use
>> block mapping in stage2 to speedup both map and unmap.
>>
>> Compared to normal memory mapping, we should consider two more
>> points when try block mapping for MMIO region:
>>
>> 1. For normal memory mapping, the PA(host physical address) and
>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>> the HVA to request hugepage, so we don't need to consider PA
>> alignment when verifing block mapping. But for device memory
>> mapping, the PA and HVA may have different alignment.
>>
>> 2. For normal memory mapping, we are sure hugepage size properly
>> fit into vma, so we don't check whether the mapping size exceeds
>> the boundary of vma. But for device memory mapping, we should pay
>> attention to this.
>>
>> This adds get_vma_page_shift() to get page shift for both normal
>> memory and device MMIO region, and check these two points when
>> selecting block mapping size for MMIO region.
>>
>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>> ---
>>   arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>>   1 file changed, 51 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index c59af5ca01b0..5a1cc7751e6d 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>>       return PAGE_SIZE;
>>   }
>>   +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
>> +{
>> +    unsigned long pa;
>> +
>> +    if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
>> +        return huge_page_shift(hstate_vma(vma));
>> +
>> +    if (!(vma->vm_flags & VM_PFNMAP))
>> +        return PAGE_SHIFT;
>> +
>> +    VM_BUG_ON(is_vm_hugetlb_page(vma));
>> +
> 
> I don't understand how VM_PFNMAP is set for hugetlbfs related vma.
> I think they are exclusive, meaning the flag is never set for
> hugetlbfs vma. If it's true, VM_PFNMAP needn't be checked on hugetlbfs
> vma and the VM_BUG_ON() becomes unnecessary.
Yes, but we're not sure all drivers follow this rule. Add a BUG_ON() is
a way to catch issue.

> 
>> +    pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>> +
>> +#ifndef __PAGETABLE_PMD_FOLDED
>> +    if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>> +        ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
>> +        ALIGN(hva, PUD_SIZE) <= vma->vm_end)
>> +        return PUD_SHIFT;
>> +#endif
>> +
>> +    if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>> +        ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
>> +        ALIGN(hva, PMD_SIZE) <= vma->vm_end)
>> +        return PMD_SHIFT;
>> +
>> +    return PAGE_SHIFT;
>> +}
>> +
> 
> There is "switch(...)" fallback mechanism in user_mem_abort(). PUD_SIZE/PMD_SIZE
> can be downgraded accordingly if the addresses fails in the alignment check
> by fault_supports_stage2_huge_mapping(). I think it would make user_mem_abort()
> simplified if the logic can be moved to get_vma_page_shift().
> 
> Another question if we need the check from fault_supports_stage2_huge_mapping()
> if VM_PFNMAP area is going to be covered by block mapping. If so, the "switch(...)"
> fallback mechanism needs to be part of get_vma_page_shift().
Yes, Good suggestion. My idea is that we can keep this series simpler and do further
optimization in another patch series. Do you mind to send a patch?

Thanks,
Keqian


From rppt at kernel.org  Wed Apr 21 07:51:04 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 09:51:04 +0300
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Message-ID: <20210421065108.1987-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1. 

The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.

With this the core mm will be able to cope with the fact that it cannot use
NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
will be treated correctly even without the need for pfn_valid_within.

The patches are only boot tested on qemu-system-aarch64 so I'd really
appreciate memory stress tests on real hardware.

If this actually works we'll be one step closer to drop custom pfn_valid()
on arm64 altogether.

v2:
* Add check for PFN overflow in pfn_is_map_memory()
* Add Acked-by and Reviewed-by tags, thanks David.

v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt at kernel.org
* Add comment about the semantics of pfn_valid() as Anshuman suggested
* Extend comments about MEMBLOCK_NOMAP, per Anshuman
* Use pfn_is_map_memory() name for the exported wrapper for
  memblock_is_map_memory(). It is still local to arch/arm64 in the end
  because of header dependency issues.

rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt at kernel.org

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 10 ++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 54 insertions(+), 13 deletions(-)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.28.0

*** BLURB HERE ***

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 15 +++++++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 59 insertions(+), 13 deletions(-)

-- 
2.28.0



From rppt at kernel.org  Wed Apr 21 07:51:05 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 09:51:05 +0300
Subject: [PATCH v2 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <20210421065108.1987-1-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
Message-ID: <20210421065108.1987-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.

The most "generic" version of pfn_valid() used by the configurations with
SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
suitable place for documentation about semantics of pfn_valid().

Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/mmzone.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 47946cec7584..961f0eeefb62 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
 #endif
 
 #ifndef CONFIG_HAVE_ARCH_PFN_VALID
+/**
+ * pfn_valid - check if there is a valid memory map entry for a PFN
+ * @pfn: the page frame number to check
+ *
+ * Check if there is a valid memory map entry aka struct page for the @pfn.
+ * Note, that availability of the memory map entry does not imply that
+ * there is actual usable memory at that @pfn. The struct page may
+ * represent a hole or an unusable page frame.
+ *
+ * Return: 1 for PFNs that have memory map entries and 0 otherwise
+ */
 static inline int pfn_valid(unsigned long pfn)
 {
 	struct mem_section *ms;
-- 
2.28.0



From rppt at kernel.org  Wed Apr 21 07:51:06 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 09:51:06 +0300
Subject: [PATCH v2 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210421065108.1987-1-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
Message-ID: <20210421065108.1987-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.

The struct pages for MEMBLOCK_NOMAP regions are kept with the default
values set by the memory map initialization which makes it necessary to
have a special treatment for such pages in pfn_valid() and
pfn_valid_within().

Split out initialization of the reserved pages to a function with a
meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
reserved regions and mark struct pages for the NOMAP regions as
PageReserved.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 include/linux/memblock.h |  4 +++-
 mm/memblock.c            | 28 ++++++++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5984fff3f175..634c1a578db8 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
  * @MEMBLOCK_NONE: no special request
  * @MEMBLOCK_HOTPLUG: hotpluggable region
  * @MEMBLOCK_MIRROR: mirrored region
- * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
+ * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
+ * reserved in the memory map; refer to memblock_mark_nomap() description
+ * for futher details
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..3abf2c3fea7f 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
  * @base: the base phys addr of the region
  * @size: the size of the region
  *
+ * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
+ * direct mapping of the physical memory. These regions will still be
+ * covered by the memory map. The struct page representing NOMAP memory
+ * frames in the memory map will be PageReserved()
+ *
  * Return: 0 on success, -errno on failure.
  */
 int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
@@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	return end_pfn - start_pfn;
 }
 
+static void __init memmap_init_reserved_pages(void)
+{
+	struct memblock_region *region;
+	phys_addr_t start, end;
+	u64 i;
+
+	/* initialize struct pages for the reserved regions */
+	for_each_reserved_mem_range(i, &start, &end)
+		reserve_bootmem_region(start, end);
+
+	/* and also treat struct pages for the NOMAP regions as PageReserved */
+	for_each_mem_region(region) {
+		if (memblock_is_nomap(region)) {
+			start = region->base;
+			end = start + region->size;
+			reserve_bootmem_region(start, end);
+		}
+	}
+}
+
 static unsigned long __init free_low_memory_core_early(void)
 {
 	unsigned long count = 0;
@@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memblock_clear_hotplug(0, -1);
 
-	for_each_reserved_mem_range(i, &start, &end)
-		reserve_bootmem_region(start, end);
+	memmap_init_reserved_pages();
 
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
-- 
2.28.0



From rppt at kernel.org  Wed Apr 21 07:51:07 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 09:51:07 +0300
Subject: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210421065108.1987-1-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
Message-ID: <20210421065108.1987-4-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.

Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.

Introduce a dedicated pfn_is_map_memory() wrapper for
memblock_is_map_memory() to perform such check and use it where
appropriate.

Using a wrapper allows to avoid cyclic include dependencies.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  1 +
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 11 +++++++++++
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 6 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..194f9f993d30 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
-	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
+	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
 })
 
 void dump_mem_limit(void);
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..99a6da91f870 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
 typedef struct page *pgtable_t;
 
 extern int pfn_valid(unsigned long);
+extern int pfn_is_map_memory(unsigned long);
 
 #include <asm/memory.h>
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..23dd99e29b23 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 
 static bool kvm_is_device_pfn(unsigned long pfn)
 {
-	return !pfn_valid(pfn);
+	return !pfn_is_map_memory(pfn);
 }
 
 /*
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..dc03bdc12c0f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
 }
 EXPORT_SYMBOL(pfn_valid);
 
+int pfn_is_map_memory(unsigned long pfn)
+{
+	phys_addr_t addr = PFN_PHYS(pfn);
+
+	if (PHYS_PFN(addr) != pfn)
+		return 0;
+	
+	return memblock_is_map_memory(addr);
+}
+EXPORT_SYMBOL(pfn_is_map_memory);
+
 static phys_addr_t memory_limit = PHYS_ADDR_MAX;
 
 /*
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b5e83c46b23e..b7c81dacabf0 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
 	/*
 	 * Don't allow RAM to be mapped.
 	 */
-	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
 void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
 {
 	/* For normal memory we already have a cacheable mapping. */
-	if (pfn_valid(__phys_to_pfn(phys_addr)))
+	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
 		return (void __iomem *)__phys_to_virt(phys_addr);
 
 	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..26045e9adbd7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
-	if (!pfn_valid(pfn))
+	if (!pfn_is_map_memory(pfn))
 		return pgprot_noncached(vma_prot);
 	else if (file->f_flags & O_SYNC)
 		return pgprot_writecombine(vma_prot);
-- 
2.28.0



From rppt at kernel.org  Wed Apr 21 07:51:08 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 09:51:08 +0300
Subject: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
In-Reply-To: <20210421065108.1987-1-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
Message-ID: <20210421065108.1987-5-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The arm64's version of pfn_valid() differs from the generic because of two
reasons:

* Parts of the memory map are freed during boot. This makes it necessary to
  verify that there is actual physical memory that corresponds to a pfn
  which is done by querying memblock.

* There are NOMAP memory regions. These regions are not mapped in the
  linear map and until the previous commit the struct pages representing
  these areas had default values.

As the consequence of absence of the special treatment of NOMAP regions in
the memory map it was necessary to use memblock_is_map_memory() in
pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
generic mm functionality would not treat a NOMAP page as a normal page.

Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
the rest of core mm will treat them as unusable memory and thus
pfn_valid_within() is no longer required at all and can be disabled by
removing CONFIG_HOLES_IN_ZONE on arm64.

pfn_valid() can be slightly simplified by replacing
memblock_is_map_memory() with memblock_is_memory().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/Kconfig   | 3 ---
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..58e439046d05 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA
 
-config HOLES_IN_ZONE
-	def_bool y
-
 source "kernel/Kconfig.hz"
 
 config ARCH_SPARSEMEM_ENABLE
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index dc03bdc12c0f..eb3f56fb8c7c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
 
 	/*
 	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_map_memory() check for ZONE_DEVICE based
+	 * memblock_is_memory() check for ZONE_DEVICE based
 	 * addresses will always fail. Even the normal hotplugged
 	 * memory will never have MEMBLOCK_NOMAP flag set in their
 	 * memblock entries. Skip memblock search for all non early
@@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
 		return pfn_section_valid(ms, pfn);
 }
 #endif
-	return memblock_is_map_memory(addr);
+	return memblock_is_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
 
-- 
2.28.0



From cl at rock-chips.com  Wed Apr 21 07:59:17 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 14:59:17 +0800
Subject: [PATCH v1 1/5] dt-bindings: i2c: i2c-rk3x: add description for rk3568
In-Reply-To: <20210421065921.23917-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
Message-ID: <20210421065921.23917-2-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on
a rk3568 platform to i2c-rk3x.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
index 7f254d79558c..5339dd4fc370 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -36,6 +36,7 @@ properties:
               - rockchip,px30-i2c
               - rockchip,rk3308-i2c
               - rockchip,rk3328-i2c
+              - rockchip,rk3568-i2c
           - const: rockchip,rk3399-i2c
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 21 07:59:18 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 14:59:18 +0800
Subject: [PATCH v1 2/5] dt-bindings: serial: snps-dw-apb-uart: add description
 for rk3568
In-Reply-To: <20210421065921.23917-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
Message-ID: <20210421065921.23917-3-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
a rk3568 platform to snps-dw-apb-uart.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 87ef1e218152..9bbe4afc26a4 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -30,6 +30,7 @@ properties:
               - rockchip,rk3308-uart
               - rockchip,rk3328-uart
               - rockchip,rk3368-uart
+              - rockchip,rk3568-uart
               - rockchip,rk3399-uart
               - rockchip,rv1108-uart
           - const: snps,dw-apb-uart
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 21 07:59:16 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 14:59:16 +0800
Subject: [PATCH v1 0/5] arm64: dts: rockchip: add basic dtsi/dts files for
 RK3568 SoC
Message-ID: <20210421065921.23917-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

1. add some dt-bindings for RK3568 devices.
2. add core dtsi for RK3568 SoC.
3. add basic dts for RK3568 EVB

Liang Chen (5):
  dt-bindings: i2c: i2c-rk3x: add description for rk3568
  dt-bindings: serial: snps-dw-apb-uart: add description for rk3568
  dt-bindings: mmc: rockchip-dw-mshc: add description for rk3568
  arm64: dts: rockchip: add core dtsi for RK3568 SoC
  arm64: dts: rockchip: add basic dts for RK3568 EVB

 .../devicetree/bindings/arm/rockchip.yaml     |    5 +
 .../devicetree/bindings/i2c/i2c-rk3x.yaml     |    1 +
 .../bindings/mmc/rockchip-dw-mshc.yaml        |    4 +
 .../bindings/serial/snps-dw-apb-uart.yaml     |    1 +
 arch/arm64/boot/dts/rockchip/Makefile         |    1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     |  382 +++
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 2789 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  795 +++++
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  346 ++
 9 files changed, 4324 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

-- 
2.17.1





From cl at rock-chips.com  Wed Apr 21 07:59:19 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 14:59:19 +0800
Subject: [PATCH v1 3/5] dt-bindings: mmc: rockchip-dw-mshc: add description
 for rk3568
In-Reply-To: <20210421065921.23917-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
Message-ID: <20210421065921.23917-4-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci" for mmc nodes on
a rk3568 platform to rockchip-dw-mshc.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index 3762f1c8de96..2a6c1cee4887 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -27,6 +27,8 @@ properties:
       - const: rockchip,rk2928-dw-mshc
       # for Rockchip RK3288
       - const: rockchip,rk3288-dw-mshc
+      # for Rockchip RK3568
+      - const: rockchip,rk3568-dwcmshc
       - items:
           - enum:
             # for Rockchip PX30
@@ -41,6 +43,8 @@ properties:
               - rockchip,rk3328-dw-mshc
             # for Rockchip RK3368
               - rockchip,rk3368-dw-mshc
+            # for Rockchip RK3568
+              - rockchip,rk3568-dw-mshc
             # for Rockchip RK3399
               - rockchip,rk3399-dw-mshc
             # for Rockchip RV1108
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 21 07:59:20 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 14:59:20 +0800
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210421065921.23917-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
Message-ID: <20210421065921.23917-5-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

RK3568 is a high-performance and low power quad-core application processor
designed for personal mobile internet device and AIoT equipments.

This patch add basic core dtsi file for it.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 2789 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  795 +++++
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  346 ++
 3 files changed, 3930 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
new file mode 100644
index 000000000000..92b315763dc0
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
@@ -0,0 +1,2789 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+&pinctrl {
+	acodec {
+		/omit-if-no-ref/
+		acodec_pins: acodec-pins {
+			rockchip,pins =
+				/* acodec_adc_sync */
+				<1 RK_PB1 5 &pcfg_pull_none>,
+				/* acodec_adcclk */
+				<1 RK_PA1 5 &pcfg_pull_none>,
+				/* acodec_adcdata */
+				<1 RK_PA0 5 &pcfg_pull_none>,
+				/* acodec_dac_datal */
+				<1 RK_PA7 5 &pcfg_pull_none>,
+				/* acodec_dac_datar */
+				<1 RK_PB0 5 &pcfg_pull_none>,
+				/* acodec_dacclk */
+				<1 RK_PA3 5 &pcfg_pull_none>,
+				/* acodec_dacsync */
+				<1 RK_PA5 5 &pcfg_pull_none>;
+		};
+	};
+	audiopwm {
+		/omit-if-no-ref/
+		audiopwm_lout: audiopwm-lout {
+			rockchip,pins =
+				/* audiopwm_lout */
+				<1 RK_PA0 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		audiopwm_loutn: audiopwm-loutn {
+			rockchip,pins =
+				/* audiopwm_loutn */
+				<1 RK_PA1 6 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		audiopwm_loutp: audiopwm-loutp {
+			rockchip,pins =
+				/* audiopwm_loutp */
+				<1 RK_PA0 6 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		audiopwm_rout: audiopwm-rout {
+			rockchip,pins =
+				/* audiopwm_rout */
+				<1 RK_PA1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		audiopwm_routn: audiopwm-routn {
+			rockchip,pins =
+				/* audiopwm_routn */
+				<1 RK_PA7 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		audiopwm_routp: audiopwm-routp {
+			rockchip,pins =
+				/* audiopwm_routp */
+				<1 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+	bt656 {
+		/omit-if-no-ref/
+		bt656m0_pins: bt656m0-pins {
+			rockchip,pins =
+				/* bt656_clkm0 */
+				<3 RK_PA0 2 &pcfg_pull_none>,
+				/* bt656_d0m0 */
+				<2 RK_PD0 2 &pcfg_pull_none>,
+				/* bt656_d1m0 */
+				<2 RK_PD1 2 &pcfg_pull_none>,
+				/* bt656_d2m0 */
+				<2 RK_PD2 2 &pcfg_pull_none>,
+				/* bt656_d3m0 */
+				<2 RK_PD3 2 &pcfg_pull_none>,
+				/* bt656_d4m0 */
+				<2 RK_PD4 2 &pcfg_pull_none>,
+				/* bt656_d5m0 */
+				<2 RK_PD5 2 &pcfg_pull_none>,
+				/* bt656_d6m0 */
+				<2 RK_PD6 2 &pcfg_pull_none>,
+				/* bt656_d7m0 */
+				<2 RK_PD7 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		bt656m1_pins: bt656m1-pins {
+			rockchip,pins =
+				/* bt656_clkm1 */
+				<4 RK_PB4 5 &pcfg_pull_none>,
+				/* bt656_d0m1 */
+				<3 RK_PC6 5 &pcfg_pull_none>,
+				/* bt656_d1m1 */
+				<3 RK_PC7 5 &pcfg_pull_none>,
+				/* bt656_d2m1 */
+				<3 RK_PD0 5 &pcfg_pull_none>,
+				/* bt656_d3m1 */
+				<3 RK_PD1 5 &pcfg_pull_none>,
+				/* bt656_d4m1 */
+				<3 RK_PD2 5 &pcfg_pull_none>,
+				/* bt656_d5m1 */
+				<3 RK_PD3 5 &pcfg_pull_none>,
+				/* bt656_d6m1 */
+				<3 RK_PD4 5 &pcfg_pull_none>,
+				/* bt656_d7m1 */
+				<3 RK_PD5 5 &pcfg_pull_none>;
+		};
+	};
+	bt1120 {
+		/omit-if-no-ref/
+		bt1120_pins: bt1120-pins {
+			rockchip,pins =
+				/* bt1120_clk */
+				<3 RK_PA6 2 &pcfg_pull_none>,
+				/* bt1120_d0 */
+				<3 RK_PA1 2 &pcfg_pull_none>,
+				/* bt1120_d1 */
+				<3 RK_PA2 2 &pcfg_pull_none>,
+				/* bt1120_d2 */
+				<3 RK_PA3 2 &pcfg_pull_none>,
+				/* bt1120_d3 */
+				<3 RK_PA4 2 &pcfg_pull_none>,
+				/* bt1120_d4 */
+				<3 RK_PA5 2 &pcfg_pull_none>,
+				/* bt1120_d5 */
+				<3 RK_PA7 2 &pcfg_pull_none>,
+				/* bt1120_d6 */
+				<3 RK_PB0 2 &pcfg_pull_none>,
+				/* bt1120_d7 */
+				<3 RK_PB1 2 &pcfg_pull_none>,
+				/* bt1120_d8 */
+				<3 RK_PB2 2 &pcfg_pull_none>,
+				/* bt1120_d9 */
+				<3 RK_PB3 2 &pcfg_pull_none>,
+				/* bt1120_d10 */
+				<3 RK_PB4 2 &pcfg_pull_none>,
+				/* bt1120_d11 */
+				<3 RK_PB5 2 &pcfg_pull_none>,
+				/* bt1120_d12 */
+				<3 RK_PB6 2 &pcfg_pull_none>,
+				/* bt1120_d13 */
+				<3 RK_PC1 2 &pcfg_pull_none>,
+				/* bt1120_d14 */
+				<3 RK_PC2 2 &pcfg_pull_none>,
+				/* bt1120_d15 */
+				<3 RK_PC3 2 &pcfg_pull_none>;
+		};
+	};
+	cam {
+		/omit-if-no-ref/
+		cam_clkout0: cam-clkout0 {
+			rockchip,pins =
+				/* cam_clkout0 */
+				<4 RK_PA7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		cam_clkout1: cam-clkout1 {
+			rockchip,pins =
+				/* cam_clkout1 */
+				<4 RK_PB0 1 &pcfg_pull_none>;
+		};
+	};
+	can0 {
+		/omit-if-no-ref/
+		can0m0_pins: can0m0-pins {
+			rockchip,pins =
+				/* can0_rxm0 */
+				<0 RK_PB4 2 &pcfg_pull_none>,
+				/* can0_txm0 */
+				<0 RK_PB3 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		can0m1_pins: can0m1-pins {
+			rockchip,pins =
+				/* can0_rxm1 */
+				<2 RK_PA2 4 &pcfg_pull_none>,
+				/* can0_txm1 */
+				<2 RK_PA1 4 &pcfg_pull_none>;
+		};
+	};
+	can1 {
+		/omit-if-no-ref/
+		can1m0_pins: can1m0-pins {
+			rockchip,pins =
+				/* can1_rxm0 */
+				<1 RK_PA0 3 &pcfg_pull_none>,
+				/* can1_txm0 */
+				<1 RK_PA1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		can1m1_pins: can1m1-pins {
+			rockchip,pins =
+				/* can1_rxm1 */
+				<4 RK_PC2 3 &pcfg_pull_none>,
+				/* can1_txm1 */
+				<4 RK_PC3 3 &pcfg_pull_none>;
+		};
+	};
+	can2 {
+		/omit-if-no-ref/
+		can2m0_pins: can2m0-pins {
+			rockchip,pins =
+				/* can2_rxm0 */
+				<4 RK_PB4 3 &pcfg_pull_none>,
+				/* can2_txm0 */
+				<4 RK_PB5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		can2m1_pins: can2m1-pins {
+			rockchip,pins =
+				/* can2_rxm1 */
+				<2 RK_PB1 4 &pcfg_pull_none>,
+				/* can2_txm1 */
+				<2 RK_PB2 4 &pcfg_pull_none>;
+		};
+	};
+	cif {
+		/omit-if-no-ref/
+		cif_clk: cif-clk {
+			rockchip,pins =
+				/* cif_clkout */
+				<4 RK_PC0 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		cif_dvp_clk: cif-dvp-clk {
+			rockchip,pins =
+				/* cif_clkin */
+				<4 RK_PC1 1 &pcfg_pull_none>,
+				/* cif_href */
+				<4 RK_PB6 1 &pcfg_pull_none>,
+				/* cif_vsync */
+				<4 RK_PB7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		cif_dvp_bus16: cif-dvp-bus16 {
+			rockchip,pins =
+				/* cif_d8 */
+				<3 RK_PD6 1 &pcfg_pull_none>,
+				/* cif_d9 */
+				<3 RK_PD7 1 &pcfg_pull_none>,
+				/* cif_d10 */
+				<4 RK_PA0 1 &pcfg_pull_none>,
+				/* cif_d11 */
+				<4 RK_PA1 1 &pcfg_pull_none>,
+				/* cif_d12 */
+				<4 RK_PA2 1 &pcfg_pull_none>,
+				/* cif_d13 */
+				<4 RK_PA3 1 &pcfg_pull_none>,
+				/* cif_d14 */
+				<4 RK_PA4 1 &pcfg_pull_none>,
+				/* cif_d15 */
+				<4 RK_PA5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		cif_dvp_bus8: cif-dvp-bus8 {
+			rockchip,pins =
+				/* cif_d0 */
+				<3 RK_PC6 1 &pcfg_pull_none>,
+				/* cif_d1 */
+				<3 RK_PC7 1 &pcfg_pull_none>,
+				/* cif_d2 */
+				<3 RK_PD0 1 &pcfg_pull_none>,
+				/* cif_d3 */
+				<3 RK_PD1 1 &pcfg_pull_none>,
+				/* cif_d4 */
+				<3 RK_PD2 1 &pcfg_pull_none>,
+				/* cif_d5 */
+				<3 RK_PD3 1 &pcfg_pull_none>,
+				/* cif_d6 */
+				<3 RK_PD4 1 &pcfg_pull_none>,
+				/* cif_d7 */
+				<3 RK_PD5 1 &pcfg_pull_none>;
+		};
+	};
+	clk32k {
+		/omit-if-no-ref/
+		clk32k_in: clk32k-in {
+			rockchip,pins =
+				/* clk32k_in */
+				<0 RK_PB0 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		clk32k_out0: clk32k-out0 {
+			rockchip,pins =
+				/* clk32k_out0 */
+				<0 RK_PB0 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		clk32k_out1: clk32k-out1 {
+			rockchip,pins =
+				/* clk32k_out1 */
+				<2 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+	cpu {
+		/omit-if-no-ref/
+		cpu_pins: cpu-pins {
+			rockchip,pins =
+				/* cpu_avs */
+				<0 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+	ebc {
+		/omit-if-no-ref/
+		ebc_extern: ebc-extern {
+			rockchip,pins =
+				/* ebc_sdce1 */
+				<4 RK_PA7 2 &pcfg_pull_none>,
+				/* ebc_sdce2 */
+				<4 RK_PB0 2 &pcfg_pull_none>,
+				/* ebc_sdce3 */
+				<4 RK_PB1 2 &pcfg_pull_none>,
+				/* ebc_sdshr */
+				<4 RK_PB5 2 &pcfg_pull_none>,
+				/* ebc_vcom */
+				<4 RK_PB2 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		ebc_pins: ebc-pins {
+			rockchip,pins =
+				/* ebc_gdclk */
+				<4 RK_PC0 2 &pcfg_pull_none>,
+				/* ebc_gdoe */
+				<4 RK_PB3 2 &pcfg_pull_none>,
+				/* ebc_gdsp */
+				<4 RK_PB4 2 &pcfg_pull_none>,
+				/* ebc_sdce0 */
+				<4 RK_PA6 2 &pcfg_pull_none>,
+				/* ebc_sdclk */
+				<4 RK_PC1 2 &pcfg_pull_none>,
+				/* ebc_sddo0 */
+				<3 RK_PC6 2 &pcfg_pull_none>,
+				/* ebc_sddo1 */
+				<3 RK_PC7 2 &pcfg_pull_none>,
+				/* ebc_sddo2 */
+				<3 RK_PD0 2 &pcfg_pull_none>,
+				/* ebc_sddo3 */
+				<3 RK_PD1 2 &pcfg_pull_none>,
+				/* ebc_sddo4 */
+				<3 RK_PD2 2 &pcfg_pull_none>,
+				/* ebc_sddo5 */
+				<3 RK_PD3 2 &pcfg_pull_none>,
+				/* ebc_sddo6 */
+				<3 RK_PD4 2 &pcfg_pull_none>,
+				/* ebc_sddo7 */
+				<3 RK_PD5 2 &pcfg_pull_none>,
+				/* ebc_sddo8 */
+				<3 RK_PD6 2 &pcfg_pull_none>,
+				/* ebc_sddo9 */
+				<3 RK_PD7 2 &pcfg_pull_none>,
+				/* ebc_sddo10 */
+				<4 RK_PA0 2 &pcfg_pull_none>,
+				/* ebc_sddo11 */
+				<4 RK_PA1 2 &pcfg_pull_none>,
+				/* ebc_sddo12 */
+				<4 RK_PA2 2 &pcfg_pull_none>,
+				/* ebc_sddo13 */
+				<4 RK_PA3 2 &pcfg_pull_none>,
+				/* ebc_sddo14 */
+				<4 RK_PA4 2 &pcfg_pull_none>,
+				/* ebc_sddo15 */
+				<4 RK_PA5 2 &pcfg_pull_none>,
+				/* ebc_sdle */
+				<4 RK_PB6 2 &pcfg_pull_none>,
+				/* ebc_sdoe */
+				<4 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+	edpdp {
+		/omit-if-no-ref/
+		edpdpm0_pins: edpdpm0-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm0 */
+				<4 RK_PC4 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		edpdpm1_pins: edpdpm1-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm1 */
+				<0 RK_PC2 2 &pcfg_pull_none>;
+		};
+	};
+	emmc {
+		/omit-if-no-ref/
+		emmc_rstnout: emmc-rstnout {
+			rockchip,pins =
+				/* emmc_rstn */
+				<1 RK_PC7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		emmc_bus8: emmc-bus8 {
+			rockchip,pins =
+				/* emmc_d0 */
+				<1 RK_PB4 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d1 */
+				<1 RK_PB5 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d2 */
+				<1 RK_PB6 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d3 */
+				<1 RK_PB7 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d4 */
+				<1 RK_PC0 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d5 */
+				<1 RK_PC1 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d6 */
+				<1 RK_PC2 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d7 */
+				<1 RK_PC3 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		emmc_clk: emmc-clk {
+			rockchip,pins =
+				/* emmc_clkout */
+				<1 RK_PC5 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		emmc_cmd: emmc-cmd {
+			rockchip,pins =
+				/* emmc_cmd */
+				<1 RK_PC4 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		emmc_datastrobe: emmc-datastrobe {
+			rockchip,pins =
+				/* emmc_datastrobe */
+				<1 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+	eth0 {
+		/omit-if-no-ref/
+		eth0_pins: eth0-pins {
+			rockchip,pins =
+				/* eth0_refclko25m */
+				<2 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+	eth1 {
+		/omit-if-no-ref/
+		eth1m0_pins: eth1m0-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm0 */
+				<3 RK_PB0 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		eth1m1_pins: eth1m1-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm1 */
+				<4 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+	flash {
+		/omit-if-no-ref/
+		flash_pins: flash-pins {
+			rockchip,pins =
+				/* flash_ale */
+				<1 RK_PD0 2 &pcfg_pull_none>,
+				/* flash_cle */
+				<1 RK_PC6 3 &pcfg_pull_none>,
+				/* flash_cs0n */
+				<1 RK_PD3 2 &pcfg_pull_none>,
+				/* flash_cs1n */
+				<1 RK_PD4 2 &pcfg_pull_none>,
+				/* flash_d0 */
+				<1 RK_PB4 2 &pcfg_pull_none>,
+				/* flash_d1 */
+				<1 RK_PB5 2 &pcfg_pull_none>,
+				/* flash_d2 */
+				<1 RK_PB6 2 &pcfg_pull_none>,
+				/* flash_d3 */
+				<1 RK_PB7 2 &pcfg_pull_none>,
+				/* flash_d4 */
+				<1 RK_PC0 2 &pcfg_pull_none>,
+				/* flash_d5 */
+				<1 RK_PC1 2 &pcfg_pull_none>,
+				/* flash_d6 */
+				<1 RK_PC2 2 &pcfg_pull_none>,
+				/* flash_d7 */
+				<1 RK_PC3 2 &pcfg_pull_none>,
+				/* flash_dqs */
+				<1 RK_PC5 2 &pcfg_pull_none>,
+				/* flash_rdn */
+				<1 RK_PD2 2 &pcfg_pull_none>,
+				/* flash_rdy */
+				<1 RK_PD1 2 &pcfg_pull_none>,
+				/* flash_volsel */
+				<0 RK_PA7 1 &pcfg_pull_none>,
+				/* flash_wpn */
+				<1 RK_PC7 3 &pcfg_pull_none>,
+				/* flash_wrn */
+				<1 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+	fspi {
+		/omit-if-no-ref/
+		fspi_pins: fspi-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>,
+				/* fspi_d2 */
+				<1 RK_PC7 2 &pcfg_pull_none>,
+				/* fspi_d3 */
+				<1 RK_PD4 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		fspi_cs1: fspi-cs1 {
+			rockchip,pins =
+				/* fspi_cs1n */
+				<1 RK_PC6 2 &pcfg_pull_up>;
+		};
+	};
+	gmac0 {
+		/omit-if-no-ref/
+		gmac0_miim: gmac0-miim {
+			rockchip,pins =
+				/* gmac0_mdc */
+				<2 RK_PC3 2 &pcfg_pull_none>,
+				/* gmac0_mdio */
+				<2 RK_PC4 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_clkinout: gmac0-clkinout {
+			rockchip,pins =
+				/* gmac0_mclkinout */
+				<2 RK_PC2 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_rx_er: gmac0-rx-er {
+			rockchip,pins =
+				/* gmac0_rxer */
+				<2 RK_PC5 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_rx_bus2: gmac0-rx-bus2 {
+			rockchip,pins =
+				/* gmac0_rxd0 */
+				<2 RK_PB6 1 &pcfg_pull_none>,
+				/* gmac0_rxd1 */
+				<2 RK_PB7 2 &pcfg_pull_none>,
+				/* gmac0_rxdvcrs */
+				<2 RK_PC0 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_tx_bus2: gmac0-tx-bus2 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_rgmii_clk: gmac0-rgmii-clk {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		gmac0_rgmii_bus: gmac0-rgmii-bus {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+	gmac1 {
+		/omit-if-no-ref/
+		gmac1m0_miim: gmac1m0-miim {
+			rockchip,pins =
+				/* gmac1_mdcm0 */
+				<3 RK_PC4 3 &pcfg_pull_none>,
+				/* gmac1_mdiom0 */
+				<3 RK_PC5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_clkinout: gmac1m0-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm0 */
+				<3 RK_PC0 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rx_er: gmac1m0-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm0 */
+				<3 RK_PB4 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rx_bus2: gmac1m0-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m0 */
+				<3 RK_PB1 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m0 */
+				<3 RK_PB2 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm0 */
+				<3 RK_PB3 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2: gmac1m0-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk: gmac1m0-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus: gmac1m0-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_miim: gmac1m1-miim {
+			rockchip,pins =
+				/* gmac1_mdcm1 */
+				<4 RK_PB6 3 &pcfg_pull_none>,
+				/* gmac1_mdiom1 */
+				<4 RK_PB7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_clkinout: gmac1m1-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm1 */
+				<4 RK_PC1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rx_er: gmac1m1-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm1 */
+				<4 RK_PB2 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rx_bus2: gmac1m1-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m1 */
+				<4 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m1 */
+				<4 RK_PB0 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm1 */
+				<4 RK_PB1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2: gmac1m1-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk: gmac1m1-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus: gmac1m1-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+	gpu {
+		/omit-if-no-ref/
+		gpu_pins: gpu-pins {
+			rockchip,pins =
+				/* gpu_avs */
+				<0 RK_PC0 2 &pcfg_pull_none>,
+				/* gpu_pwren */
+				<0 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+	hdmitx {
+		/omit-if-no-ref/
+		hdmitxm0_cec: hdmitxm0-cec {
+			rockchip,pins =
+				/* hdmitxm0_cec */
+				<4 RK_PD1 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		hdmitxm1_cec: hdmitxm1-cec {
+			rockchip,pins =
+				/* hdmitxm1_cec */
+				<0 RK_PC7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		hdmitx_scl: hdmitx-scl {
+			rockchip,pins =
+				/* hdmitx_scl */
+				<4 RK_PC7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		hdmitx_sda: hdmitx-sda {
+			rockchip,pins =
+				/* hdmitx_sda */
+				<4 RK_PD0 1 &pcfg_pull_none>;
+		};
+	};
+	i2c0 {
+		/omit-if-no-ref/
+		i2c0_xfer: i2c0-xfer {
+			rockchip,pins =
+				/* i2c0_scl */
+				<0 RK_PB1 1 &pcfg_pull_none_smt>,
+				/* i2c0_sda */
+				<0 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+	};
+	i2c1 {
+		/omit-if-no-ref/
+		i2c1_xfer: i2c1-xfer {
+			rockchip,pins =
+				/* i2c1_scl */
+				<0 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c1_sda */
+				<0 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+	i2c2 {
+		/omit-if-no-ref/
+		i2c2m0_xfer: i2c2m0-xfer {
+			rockchip,pins =
+				/* i2c2_sclm0 */
+				<0 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam0 */
+				<0 RK_PB6 1 &pcfg_pull_none_smt>;
+		};
+		/omit-if-no-ref/
+		i2c2m1_xfer: i2c2m1-xfer {
+			rockchip,pins =
+				/* i2c2_sclm1 */
+				<4 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam1 */
+				<4 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+	i2c3 {
+		/omit-if-no-ref/
+		i2c3m0_xfer: i2c3m0-xfer {
+			rockchip,pins =
+				/* i2c3_sclm0 */
+				<1 RK_PA1 1 &pcfg_pull_none_smt>,
+				/* i2c3_sdam0 */
+				<1 RK_PA0 1 &pcfg_pull_none_smt>;
+		};
+		/omit-if-no-ref/
+		i2c3m1_xfer: i2c3m1-xfer {
+			rockchip,pins =
+				/* i2c3_sclm1 */
+				<3 RK_PB5 4 &pcfg_pull_none_smt>,
+				/* i2c3_sdam1 */
+				<3 RK_PB6 4 &pcfg_pull_none_smt>;
+		};
+	};
+	i2c4 {
+		/omit-if-no-ref/
+		i2c4m0_xfer: i2c4m0-xfer {
+			rockchip,pins =
+				/* i2c4_sclm0 */
+				<4 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c4_sdam0 */
+				<4 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+		/omit-if-no-ref/
+		i2c4m1_xfer: i2c4m1-xfer {
+			rockchip,pins =
+				/* i2c4_sclm1 */
+				<2 RK_PB2 2 &pcfg_pull_none_smt>,
+				/* i2c4_sdam1 */
+				<2 RK_PB1 2 &pcfg_pull_none_smt>;
+		};
+	};
+	i2c5 {
+		/omit-if-no-ref/
+		i2c5m0_xfer: i2c5m0-xfer {
+			rockchip,pins =
+				/* i2c5_sclm0 */
+				<3 RK_PB3 4 &pcfg_pull_none_smt>,
+				/* i2c5_sdam0 */
+				<3 RK_PB4 4 &pcfg_pull_none_smt>;
+		};
+		/omit-if-no-ref/
+		i2c5m1_xfer: i2c5m1-xfer {
+			rockchip,pins =
+				/* i2c5_sclm1 */
+				<4 RK_PC7 2 &pcfg_pull_none_smt>,
+				/* i2c5_sdam1 */
+				<4 RK_PD0 2 &pcfg_pull_none_smt>;
+		};
+	};
+	i2s1 {
+		/omit-if-no-ref/
+		i2s1m0_lrckrx: i2s1m0-lrckrx {
+			rockchip,pins =
+				/* i2s1m0_lrckrx */
+				<1 RK_PA6 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_lrcktx: i2s1m0-lrcktx {
+			rockchip,pins =
+				/* i2s1m0_lrcktx */
+				<1 RK_PA5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_mclk: i2s1m0-mclk {
+			rockchip,pins =
+				/* i2s1m0_mclk */
+				<1 RK_PA2 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sclkrx: i2s1m0-sclkrx {
+			rockchip,pins =
+				/* i2s1m0_sclkrx */
+				<1 RK_PA4 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sclktx: i2s1m0-sclktx {
+			rockchip,pins =
+				/* i2s1m0_sclktx */
+				<1 RK_PA3 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdi0: i2s1m0-sdi0 {
+			rockchip,pins =
+				/* i2s1m0_sdi0 */
+				<1 RK_PB3 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdi1: i2s1m0-sdi1 {
+			rockchip,pins =
+				/* i2s1m0_sdi1 */
+				<1 RK_PB2 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdi2: i2s1m0-sdi2 {
+			rockchip,pins =
+				/* i2s1m0_sdi2 */
+				<1 RK_PB1 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdi3: i2s1m0-sdi3 {
+			rockchip,pins =
+				/* i2s1m0_sdi3 */
+				<1 RK_PB0 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdo0: i2s1m0-sdo0 {
+			rockchip,pins =
+				/* i2s1m0_sdo0 */
+				<1 RK_PA7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdo1: i2s1m0-sdo1 {
+			rockchip,pins =
+				/* i2s1m0_sdo1 */
+				<1 RK_PB0 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdo2: i2s1m0-sdo2 {
+			rockchip,pins =
+				/* i2s1m0_sdo2 */
+				<1 RK_PB1 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m0_sdo3: i2s1m0-sdo3 {
+			rockchip,pins =
+				/* i2s1m0_sdo3 */
+				<1 RK_PB2 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_lrckrx: i2s1m1-lrckrx {
+			rockchip,pins =
+				/* i2s1m1_lrckrx */
+				<4 RK_PA7 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_lrcktx: i2s1m1-lrcktx {
+			rockchip,pins =
+				/* i2s1m1_lrcktx */
+				<3 RK_PD0 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_mclk: i2s1m1-mclk {
+			rockchip,pins =
+				/* i2s1m1_mclk */
+				<3 RK_PC6 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sclkrx: i2s1m1-sclkrx {
+			rockchip,pins =
+				/* i2s1m1_sclkrx */
+				<4 RK_PA6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sclktx: i2s1m1-sclktx {
+			rockchip,pins =
+				/* i2s1m1_sclktx */
+				<3 RK_PC7 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdi0: i2s1m1-sdi0 {
+			rockchip,pins =
+				/* i2s1m1_sdi0 */
+				<3 RK_PD2 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdi1: i2s1m1-sdi1 {
+			rockchip,pins =
+				/* i2s1m1_sdi1 */
+				<3 RK_PD3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdi2: i2s1m1-sdi2 {
+			rockchip,pins =
+				/* i2s1m1_sdi2 */
+				<3 RK_PD4 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdi3: i2s1m1-sdi3 {
+			rockchip,pins =
+				/* i2s1m1_sdi3 */
+				<3 RK_PD5 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdo0: i2s1m1-sdo0 {
+			rockchip,pins =
+				/* i2s1m1_sdo0 */
+				<3 RK_PD1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdo1: i2s1m1-sdo1 {
+			rockchip,pins =
+				/* i2s1m1_sdo1 */
+				<4 RK_PB0 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdo2: i2s1m1-sdo2 {
+			rockchip,pins =
+				/* i2s1m1_sdo2 */
+				<4 RK_PB1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m1_sdo3: i2s1m1-sdo3 {
+			rockchip,pins =
+				/* i2s1m1_sdo3 */
+				<4 RK_PB5 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_lrckrx: i2s1m2-lrckrx {
+			rockchip,pins =
+				/* i2s1m2_lrckrx */
+				<3 RK_PC5 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_lrcktx: i2s1m2-lrcktx {
+			rockchip,pins =
+				/* i2s1m2_lrcktx */
+				<2 RK_PD2 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_mclk: i2s1m2-mclk {
+			rockchip,pins =
+				/* i2s1m2_mclk */
+				<2 RK_PD0 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sclkrx: i2s1m2-sclkrx {
+			rockchip,pins =
+				/* i2s1m2_sclkrx */
+				<3 RK_PC3 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sclktx: i2s1m2-sclktx {
+			rockchip,pins =
+				/* i2s1m2_sclktx */
+				<2 RK_PD1 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdi0: i2s1m2-sdi0 {
+			rockchip,pins =
+				/* i2s1m2_sdi0 */
+				<2 RK_PD3 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdi1: i2s1m2-sdi1 {
+			rockchip,pins =
+				/* i2s1m2_sdi1 */
+				<2 RK_PD4 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdi2: i2s1m2-sdi2 {
+			rockchip,pins =
+				/* i2s1m2_sdi2 */
+				<2 RK_PD5 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdi3: i2s1m2-sdi3 {
+			rockchip,pins =
+				/* i2s1m2_sdi3 */
+				<2 RK_PD6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdo0: i2s1m2-sdo0 {
+			rockchip,pins =
+				/* i2s1m2_sdo0 */
+				<2 RK_PD7 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdo1: i2s1m2-sdo1 {
+			rockchip,pins =
+				/* i2s1m2_sdo1 */
+				<3 RK_PA0 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdo2: i2s1m2-sdo2 {
+			rockchip,pins =
+				/* i2s1m2_sdo2 */
+				<3 RK_PC1 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s1m2_sdo3: i2s1m2-sdo3 {
+			rockchip,pins =
+				/* i2s1m2_sdo3 */
+				<3 RK_PC2 5 &pcfg_pull_none>;
+		};
+	};
+	i2s2 {
+		/omit-if-no-ref/
+		i2s2m0_lrckrx: i2s2m0-lrckrx {
+			rockchip,pins =
+				/* i2s2m0_lrckrx */
+				<2 RK_PC0 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_lrcktx: i2s2m0-lrcktx {
+			rockchip,pins =
+				/* i2s2m0_lrcktx */
+				<2 RK_PC3 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_mclk: i2s2m0-mclk {
+			rockchip,pins =
+				/* i2s2m0_mclk */
+				<2 RK_PC1 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_sclkrx: i2s2m0-sclkrx {
+			rockchip,pins =
+				/* i2s2m0_sclkrx */
+				<2 RK_PB7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_sclktx: i2s2m0-sclktx {
+			rockchip,pins =
+				/* i2s2m0_sclktx */
+				<2 RK_PC2 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_sdi: i2s2m0-sdi {
+			rockchip,pins =
+				/* i2s2m0_sdi */
+				<2 RK_PC5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m0_sdo: i2s2m0-sdo {
+			rockchip,pins =
+				/* i2s2m0_sdo */
+				<2 RK_PC4 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_lrckrx: i2s2m1-lrckrx {
+			rockchip,pins =
+				/* i2s2m1_lrckrx */
+				<4 RK_PA5 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_lrcktx: i2s2m1-lrcktx {
+			rockchip,pins =
+				/* i2s2m1_lrcktx */
+				<4 RK_PA4 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_mclk: i2s2m1-mclk {
+			rockchip,pins =
+				/* i2s2m1_mclk */
+				<4 RK_PB6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_sclkrx: i2s2m1-sclkrx {
+			rockchip,pins =
+				/* i2s2m1_sclkrx */
+				<4 RK_PC1 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_sclktx: i2s2m1-sclktx {
+			rockchip,pins =
+				/* i2s2m1_sclktx */
+				<4 RK_PB7 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_sdi: i2s2m1-sdi {
+			rockchip,pins =
+				/* i2s2m1_sdi */
+				<4 RK_PB2 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s2m1_sdo: i2s2m1-sdo {
+			rockchip,pins =
+				/* i2s2m1_sdo */
+				<4 RK_PB3 5 &pcfg_pull_none>;
+		};
+	};
+	i2s3 {
+		/omit-if-no-ref/
+		i2s3m0_lrck: i2s3m0-lrck {
+			rockchip,pins =
+				/* i2s3m0_lrck */
+				<3 RK_PA4 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m0_mclk: i2s3m0-mclk {
+			rockchip,pins =
+				/* i2s3m0_mclk */
+				<3 RK_PA2 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m0_sclk: i2s3m0-sclk {
+			rockchip,pins =
+				/* i2s3m0_sclk */
+				<3 RK_PA3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m0_sdi: i2s3m0-sdi {
+			rockchip,pins =
+				/* i2s3m0_sdi */
+				<3 RK_PA6 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m0_sdo: i2s3m0-sdo {
+			rockchip,pins =
+				/* i2s3m0_sdo */
+				<3 RK_PA5 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m1_lrck: i2s3m1-lrck {
+			rockchip,pins =
+				/* i2s3m1_lrck */
+				<4 RK_PC4 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m1_mclk: i2s3m1-mclk {
+			rockchip,pins =
+				/* i2s3m1_mclk */
+				<4 RK_PC2 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m1_sclk: i2s3m1-sclk {
+			rockchip,pins =
+				/* i2s3m1_sclk */
+				<4 RK_PC3 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m1_sdi: i2s3m1-sdi {
+			rockchip,pins =
+				/* i2s3m1_sdi */
+				<4 RK_PC6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		i2s3m1_sdo: i2s3m1-sdo {
+			rockchip,pins =
+				/* i2s3m1_sdo */
+				<4 RK_PC5 5 &pcfg_pull_none>;
+		};
+	};
+	isp {
+		/omit-if-no-ref/
+		isp_pins: isp-pins {
+			rockchip,pins =
+				/* isp_flashtrigin */
+				<4 RK_PB4 4 &pcfg_pull_none>,
+				/* isp_flashtrigout */
+				<4 RK_PA6 1 &pcfg_pull_none>,
+				/* isp_prelighttrig */
+				<4 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+	jtag {
+		/omit-if-no-ref/
+		jtag_pins: jtag-pins {
+			rockchip,pins =
+				/* jtag_tck */
+				<1 RK_PD7 2 &pcfg_pull_none>,
+				/* jtag_tms */
+				<2 RK_PA0 2 &pcfg_pull_none>;
+		};
+	};
+	lcdc {
+		/omit-if-no-ref/
+		lcdc_ctl: lcdc-ctl {
+			rockchip,pins =
+				/* lcdc_clk */
+				<3 RK_PA0 1 &pcfg_pull_none>,
+				/* lcdc_d0 */
+				<2 RK_PD0 1 &pcfg_pull_none>,
+				/* lcdc_d1 */
+				<2 RK_PD1 1 &pcfg_pull_none>,
+				/* lcdc_d2 */
+				<2 RK_PD2 1 &pcfg_pull_none>,
+				/* lcdc_d3 */
+				<2 RK_PD3 1 &pcfg_pull_none>,
+				/* lcdc_d4 */
+				<2 RK_PD4 1 &pcfg_pull_none>,
+				/* lcdc_d5 */
+				<2 RK_PD5 1 &pcfg_pull_none>,
+				/* lcdc_d6 */
+				<2 RK_PD6 1 &pcfg_pull_none>,
+				/* lcdc_d7 */
+				<2 RK_PD7 1 &pcfg_pull_none>,
+				/* lcdc_d8 */
+				<3 RK_PA1 1 &pcfg_pull_none>,
+				/* lcdc_d9 */
+				<3 RK_PA2 1 &pcfg_pull_none>,
+				/* lcdc_d10 */
+				<3 RK_PA3 1 &pcfg_pull_none>,
+				/* lcdc_d11 */
+				<3 RK_PA4 1 &pcfg_pull_none>,
+				/* lcdc_d12 */
+				<3 RK_PA5 1 &pcfg_pull_none>,
+				/* lcdc_d13 */
+				<3 RK_PA6 1 &pcfg_pull_none>,
+				/* lcdc_d14 */
+				<3 RK_PA7 1 &pcfg_pull_none>,
+				/* lcdc_d15 */
+				<3 RK_PB0 1 &pcfg_pull_none>,
+				/* lcdc_d16 */
+				<3 RK_PB1 1 &pcfg_pull_none>,
+				/* lcdc_d17 */
+				<3 RK_PB2 1 &pcfg_pull_none>,
+				/* lcdc_d18 */
+				<3 RK_PB3 1 &pcfg_pull_none>,
+				/* lcdc_d19 */
+				<3 RK_PB4 1 &pcfg_pull_none>,
+				/* lcdc_d20 */
+				<3 RK_PB5 1 &pcfg_pull_none>,
+				/* lcdc_d21 */
+				<3 RK_PB6 1 &pcfg_pull_none>,
+				/* lcdc_d22 */
+				<3 RK_PB7 1 &pcfg_pull_none>,
+				/* lcdc_d23 */
+				<3 RK_PC0 1 &pcfg_pull_none>,
+				/* lcdc_den */
+				<3 RK_PC3 1 &pcfg_pull_none>,
+				/* lcdc_hsync */
+				<3 RK_PC1 1 &pcfg_pull_none>,
+				/* lcdc_vsync */
+				<3 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+	mcu {
+		/omit-if-no-ref/
+		mcu_pins: mcu-pins {
+			rockchip,pins =
+				/* mcu_jtagtck */
+				<0 RK_PB4 4 &pcfg_pull_none>,
+				/* mcu_jtagtdi */
+				<0 RK_PC1 4 &pcfg_pull_none>,
+				/* mcu_jtagtdo */
+				<0 RK_PB3 4 &pcfg_pull_none>,
+				/* mcu_jtagtms */
+				<0 RK_PC2 4 &pcfg_pull_none>,
+				/* mcu_jtagtrstn */
+				<0 RK_PC3 4 &pcfg_pull_none>;
+		};
+	};
+	npu {
+		/omit-if-no-ref/
+		npu_pins: npu-pins {
+			rockchip,pins =
+				/* npu_avs */
+				<0 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+	pcie20 {
+		/omit-if-no-ref/
+		pcie20m0_pins: pcie20m0-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm0 */
+				<0 RK_PA5 3 &pcfg_pull_none>,
+				/* pcie20_perstnm0 */
+				<0 RK_PB6 3 &pcfg_pull_none>,
+				/* pcie20_wakenm0 */
+				<0 RK_PB5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie20m1_pins: pcie20m1-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm1 */
+				<2 RK_PD0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm1 */
+				<3 RK_PC1 4 &pcfg_pull_none>,
+				/* pcie20_wakenm1 */
+				<2 RK_PD1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie20m2_pins: pcie20m2-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm2 */
+				<1 RK_PB0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm2 */
+				<1 RK_PB2 4 &pcfg_pull_none>,
+				/* pcie20_wakenm2 */
+				<1 RK_PB1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie20_buttonrstn: pcie20-buttonrstn {
+			rockchip,pins =
+				/* pcie20_buttonrstn */
+				<0 RK_PB4 3 &pcfg_pull_none>;
+		};
+	};
+	pcie30x1 {
+		/omit-if-no-ref/
+		pcie30x1m0_pins: pcie30x1m0-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm0 */
+				<0 RK_PA4 3 &pcfg_pull_none>,
+				/* pcie30x1_perstnm0 */
+				<0 RK_PC3 3 &pcfg_pull_none>,
+				/* pcie30x1_wakenm0 */
+				<0 RK_PC2 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x1m1_pins: pcie30x1m1-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm1 */
+				<2 RK_PD2 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm1 */
+				<3 RK_PA1 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm1 */
+				<2 RK_PD3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x1m2_pins: pcie30x1m2-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm2 */
+				<1 RK_PA5 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm2 */
+				<1 RK_PA2 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm2 */
+				<1 RK_PA3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x1_buttonrstn: pcie30x1-buttonrstn {
+			rockchip,pins =
+				/* pcie30x1_buttonrstn */
+				<0 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+	pcie30x2 {
+		/omit-if-no-ref/
+		pcie30x2m0_pins: pcie30x2m0-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm0 */
+				<0 RK_PA6 2 &pcfg_pull_none>,
+				/* pcie30x2_perstnm0 */
+				<0 RK_PC6 3 &pcfg_pull_none>,
+				/* pcie30x2_wakenm0 */
+				<0 RK_PC5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x2m1_pins: pcie30x2m1-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm1 */
+				<2 RK_PD4 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm1 */
+				<2 RK_PD6 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm1 */
+				<2 RK_PD5 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x2m2_pins: pcie30x2m2-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm2 */
+				<4 RK_PC2 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm2 */
+				<4 RK_PC4 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm2 */
+				<4 RK_PC3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pcie30x2_buttonrstn: pcie30x2-buttonrstn {
+			rockchip,pins =
+				/* pcie30x2_buttonrstn */
+				<0 RK_PB0 3 &pcfg_pull_none>;
+		};
+	};
+	pdm {
+		/omit-if-no-ref/
+		pdmm0_clk: pdmm0-clk {
+			rockchip,pins =
+				/* pdm_clk0m0 */
+				<1 RK_PA6 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm0_clk1: pdmm0-clk1 {
+			rockchip,pins =
+				/* pdmm0_clk1 */
+				<1 RK_PA4 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm0_sdi0: pdmm0-sdi0 {
+			rockchip,pins =
+				/* pdmm0_sdi0 */
+				<1 RK_PB3 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm0_sdi1: pdmm0-sdi1 {
+			rockchip,pins =
+				/* pdmm0_sdi1 */
+				<1 RK_PB2 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm0_sdi2: pdmm0-sdi2 {
+			rockchip,pins =
+				/* pdmm0_sdi2 */
+				<1 RK_PB1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm0_sdi3: pdmm0-sdi3 {
+			rockchip,pins =
+				/* pdmm0_sdi3 */
+				<1 RK_PB0 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_clk: pdmm1-clk {
+			rockchip,pins =
+				/* pdm_clk0m1 */
+				<3 RK_PD6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_clk1: pdmm1-clk1 {
+			rockchip,pins =
+				/* pdmm1_clk1 */
+				<4 RK_PA0 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_sdi0: pdmm1-sdi0 {
+			rockchip,pins =
+				/* pdmm1_sdi0 */
+				<3 RK_PD7 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_sdi1: pdmm1-sdi1 {
+			rockchip,pins =
+				/* pdmm1_sdi1 */
+				<4 RK_PA1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_sdi2: pdmm1-sdi2 {
+			rockchip,pins =
+				/* pdmm1_sdi2 */
+				<4 RK_PA2 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm1_sdi3: pdmm1-sdi3 {
+			rockchip,pins =
+				/* pdmm1_sdi3 */
+				<4 RK_PA3 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm2_clk1: pdmm2-clk1 {
+			rockchip,pins =
+				/* pdmm2_clk1 */
+				<3 RK_PC4 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm2_sdi0: pdmm2-sdi0 {
+			rockchip,pins =
+				/* pdmm2_sdi0 */
+				<3 RK_PB3 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm2_sdi1: pdmm2-sdi1 {
+			rockchip,pins =
+				/* pdmm2_sdi1 */
+				<3 RK_PB4 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm2_sdi2: pdmm2-sdi2 {
+			rockchip,pins =
+				/* pdmm2_sdi2 */
+				<3 RK_PB7 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pdmm2_sdi3: pdmm2-sdi3 {
+			rockchip,pins =
+				/* pdmm2_sdi3 */
+				<3 RK_PC0 5 &pcfg_pull_none>;
+		};
+	};
+	pmic {
+		/omit-if-no-ref/
+		pmic_pins: pmic-pins {
+			rockchip,pins =
+				/* pmic_sleep */
+				<0 RK_PA2 1 &pcfg_pull_none>;
+		};
+	};
+	pmu {
+		/omit-if-no-ref/
+		pmu_pins: pmu-pins {
+			rockchip,pins =
+				/* pmu_debug0 */
+				<0 RK_PA5 4 &pcfg_pull_none>,
+				/* pmu_debug1 */
+				<0 RK_PA6 3 &pcfg_pull_none>,
+				/* pmu_debug2 */
+				<0 RK_PC4 4 &pcfg_pull_none>,
+				/* pmu_debug3 */
+				<0 RK_PC5 4 &pcfg_pull_none>,
+				/* pmu_debug4 */
+				<0 RK_PC6 4 &pcfg_pull_none>,
+				/* pmu_debug5 */
+				<0 RK_PC7 4 &pcfg_pull_none>;
+		};
+	};
+	pwm0 {
+		/omit-if-no-ref/
+		pwm0m0_pins: pwm0m0-pins {
+			rockchip,pins =
+				/* pwm0_m0 */
+				<0 RK_PB7 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm0m1_pins: pwm0m1-pins {
+			rockchip,pins =
+				/* pwm0_m1 */
+				<0 RK_PC7 2 &pcfg_pull_none>;
+		};
+	};
+	pwm1 {
+		/omit-if-no-ref/
+		pwm1m0_pins: pwm1m0-pins {
+			rockchip,pins =
+				/* pwm1_m0 */
+				<0 RK_PC0 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm1m1_pins: pwm1m1-pins {
+			rockchip,pins =
+				/* pwm1_m1 */
+				<0 RK_PB5 4 &pcfg_pull_none>;
+		};
+	};
+	pwm2 {
+		/omit-if-no-ref/
+		pwm2m0_pins: pwm2m0-pins {
+			rockchip,pins =
+				/* pwm2_m0 */
+				<0 RK_PC1 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm2m1_pins: pwm2m1-pins {
+			rockchip,pins =
+				/* pwm2_m1 */
+				<0 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+	pwm3 {
+		/omit-if-no-ref/
+		pwm3_pins: pwm3-pins {
+			rockchip,pins =
+				/* pwm3_ir */
+				<0 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+	pwm4 {
+		/omit-if-no-ref/
+		pwm4_pins: pwm4-pins {
+			rockchip,pins =
+				/* pwm4 */
+				<0 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+	pwm5 {
+		/omit-if-no-ref/
+		pwm5_pins: pwm5-pins {
+			rockchip,pins =
+				/* pwm5 */
+				<0 RK_PC4 1 &pcfg_pull_none>;
+		};
+	};
+	pwm6 {
+		/omit-if-no-ref/
+		pwm6_pins: pwm6-pins {
+			rockchip,pins =
+				/* pwm6 */
+				<0 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+	pwm7 {
+		/omit-if-no-ref/
+		pwm7_pins: pwm7-pins {
+			rockchip,pins =
+				/* pwm7_ir */
+				<0 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+	pwm8 {
+		/omit-if-no-ref/
+		pwm8m0_pins: pwm8m0-pins {
+			rockchip,pins =
+				/* pwm8_m0 */
+				<3 RK_PB1 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm8m1_pins: pwm8m1-pins {
+			rockchip,pins =
+				/* pwm8_m1 */
+				<1 RK_PD5 4 &pcfg_pull_none>;
+		};
+	};
+	pwm9 {
+		/omit-if-no-ref/
+		pwm9m0_pins: pwm9m0-pins {
+			rockchip,pins =
+				/* pwm9_m0 */
+				<3 RK_PB2 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm9m1_pins: pwm9m1-pins {
+			rockchip,pins =
+				/* pwm9_m1 */
+				<1 RK_PD6 4 &pcfg_pull_none>;
+		};
+	};
+	pwm10 {
+		/omit-if-no-ref/
+		pwm10m0_pins: pwm10m0-pins {
+			rockchip,pins =
+				/* pwm10_m0 */
+				<3 RK_PB5 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm10m1_pins: pwm10m1-pins {
+			rockchip,pins =
+				/* pwm10_m1 */
+				<2 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+	pwm11 {
+		/omit-if-no-ref/
+		pwm11m0_pins: pwm11m0-pins {
+			rockchip,pins =
+				/* pwm11_irm0 */
+				<3 RK_PB6 5 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm11m1_pins: pwm11m1-pins {
+			rockchip,pins =
+				/* pwm11_irm1 */
+				<4 RK_PC0 3 &pcfg_pull_none>;
+		};
+	};
+	pwm12 {
+		/omit-if-no-ref/
+		pwm12m0_pins: pwm12m0-pins {
+			rockchip,pins =
+				/* pwm12_m0 */
+				<3 RK_PB7 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm12m1_pins: pwm12m1-pins {
+			rockchip,pins =
+				/* pwm12_m1 */
+				<4 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+	pwm13 {
+		/omit-if-no-ref/
+		pwm13m0_pins: pwm13m0-pins {
+			rockchip,pins =
+				/* pwm13_m0 */
+				<3 RK_PC0 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm13m1_pins: pwm13m1-pins {
+			rockchip,pins =
+				/* pwm13_m1 */
+				<4 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+	pwm14 {
+		/omit-if-no-ref/
+		pwm14m0_pins: pwm14m0-pins {
+			rockchip,pins =
+				/* pwm14_m0 */
+				<3 RK_PC4 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm14m1_pins: pwm14m1-pins {
+			rockchip,pins =
+				/* pwm14_m1 */
+				<4 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+	pwm15 {
+		/omit-if-no-ref/
+		pwm15m0_pins: pwm15m0-pins {
+			rockchip,pins =
+				/* pwm15_irm0 */
+				<3 RK_PC5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		pwm15m1_pins: pwm15m1-pins {
+			rockchip,pins =
+				/* pwm15_irm1 */
+				<4 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+	refclk {
+		/omit-if-no-ref/
+		refclk_pins: refclk-pins {
+			rockchip,pins =
+				/* refclk_ou */
+				<0 RK_PA0 1 &pcfg_pull_none>;
+		};
+	};
+	sata {
+		/omit-if-no-ref/
+		sata_pins: sata-pins {
+			rockchip,pins =
+				/* sata_cpdet */
+				<0 RK_PA4 2 &pcfg_pull_none>,
+				/* sata_cppod */
+				<0 RK_PA6 1 &pcfg_pull_none>,
+				/* sata_mpswitch */
+				<0 RK_PA5 2 &pcfg_pull_none>;
+		};
+	};
+	sata0 {
+		/omit-if-no-ref/
+		sata0_pins: sata0-pins {
+			rockchip,pins =
+				/* sata0_actled */
+				<4 RK_PC6 3 &pcfg_pull_none>;
+		};
+	};
+	sata1 {
+		/omit-if-no-ref/
+		sata1_pins: sata1-pins {
+			rockchip,pins =
+				/* sata1_actled */
+				<4 RK_PC5 3 &pcfg_pull_none>;
+		};
+	};
+	sata2 {
+		/omit-if-no-ref/
+		sata2_pins: sata2-pins {
+			rockchip,pins =
+				/* sata2_actled */
+				<4 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+	scr {
+		/omit-if-no-ref/
+		scr_pins: scr-pins {
+			rockchip,pins =
+				/* scr_clk */
+				<1 RK_PA2 3 &pcfg_pull_none>,
+				/* scr_det */
+				<1 RK_PA7 3 &pcfg_pull_up>,
+				/* scr_io */
+				<1 RK_PA3 3 &pcfg_pull_up>,
+				/* scr_rst */
+				<1 RK_PA5 3 &pcfg_pull_none>;
+		};
+	};
+	sdmmc0 {
+		/omit-if-no-ref/
+		sdmmc0_bus4: sdmmc0-bus4 {
+			rockchip,pins =
+				/* sdmmc0_d0 */
+				<1 RK_PD5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d1 */
+				<1 RK_PD6 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d2 */
+				<1 RK_PD7 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d3 */
+				<2 RK_PA0 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc0_clk: sdmmc0-clk {
+			rockchip,pins =
+				/* sdmmc0_clk */
+				<2 RK_PA2 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc0_cmd: sdmmc0-cmd {
+			rockchip,pins =
+				/* sdmmc0_cmd */
+				<2 RK_PA1 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc0_det: sdmmc0-det {
+			rockchip,pins =
+				/* sdmmc0_det */
+				<0 RK_PA4 1 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		sdmmc0_pwren: sdmmc0-pwren {
+			rockchip,pins =
+				/* sdmmc0_pwren */
+				<0 RK_PA5 1 &pcfg_pull_none>;
+		};
+	};
+	sdmmc1 {
+		/omit-if-no-ref/
+		sdmmc1_bus4: sdmmc1-bus4 {
+			rockchip,pins =
+				/* sdmmc1_d0 */
+				<2 RK_PA3 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d1 */
+				<2 RK_PA4 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d2 */
+				<2 RK_PA5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d3 */
+				<2 RK_PA6 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc1_clk: sdmmc1-clk {
+			rockchip,pins =
+				/* sdmmc1_clk */
+				<2 RK_PB0 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc1_cmd: sdmmc1-cmd {
+			rockchip,pins =
+				/* sdmmc1_cmd */
+				<2 RK_PA7 1 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc1_det: sdmmc1-det {
+			rockchip,pins =
+				/* sdmmc1_det */
+				<2 RK_PB2 1 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		sdmmc1_pwren: sdmmc1-pwren {
+			rockchip,pins =
+				/* sdmmc1_pwren */
+				<2 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+	sdmmc2 {
+		/omit-if-no-ref/
+		sdmmc2m0_bus4: sdmmc2m0-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m0 */
+				<3 RK_PC6 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m0 */
+				<3 RK_PC7 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m0 */
+				<3 RK_PD0 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m0 */
+				<3 RK_PD1 3 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m0_clk: sdmmc2m0-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm0 */
+				<3 RK_PD3 3 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m0_cmd: sdmmc2m0-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm0 */
+				<3 RK_PD2 3 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m0_det: sdmmc2m0-det {
+			rockchip,pins =
+				/* sdmmc2_detm0 */
+				<3 RK_PD4 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m0_pwren: sdmmc2m0-pwren {
+			rockchip,pins =
+				/* sdmmc2m0_pwren */
+				<3 RK_PD5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m1_bus4: sdmmc2m1-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m1 */
+				<3 RK_PA1 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m1 */
+				<3 RK_PA2 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m1 */
+				<3 RK_PA3 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m1 */
+				<3 RK_PA4 5 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m1_clk: sdmmc2m1-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm1 */
+				<3 RK_PA6 5 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m1_cmd: sdmmc2m1-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm1 */
+				<3 RK_PA5 5 &pcfg_pull_up_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m1_det: sdmmc2m1-det {
+			rockchip,pins =
+				/* sdmmc2_detm1 */
+				<3 RK_PA7 4 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		sdmmc2m1_pwren: sdmmc2m1-pwren {
+			rockchip,pins =
+				/* sdmmc2m1_pwren */
+				<3 RK_PB0 4 &pcfg_pull_none>;
+		};
+	};
+	spdif {
+		/omit-if-no-ref/
+		spdifm0_tx: spdifm0-tx {
+			rockchip,pins =
+				/* spdifm0_tx */
+				<1 RK_PA4 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spdifm1_tx: spdifm1-tx {
+			rockchip,pins =
+				/* spdifm1_tx */
+				<3 RK_PC5 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spdifm2_tx: spdifm2-tx {
+			rockchip,pins =
+				/* spdifm2_tx */
+				<4 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+	spi0 {
+		/omit-if-no-ref/
+		spi0m0_pins: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_none>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_none>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi0m0_cs0: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi0m0_cs1: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi0m1_pins: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_none>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_none>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi0m1_cs0: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_none>;
+		};
+	};
+	spi1 {
+		/omit-if-no-ref/
+		spi1m0_pins: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_none>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_none>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi1m0_cs0: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi1m0_cs1: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi1m1_pins: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_none>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_none>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi1m1_cs0: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_none>;
+		};
+	};
+	spi2 {
+		/omit-if-no-ref/
+		spi2m0_pins: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_none>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_none>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi2m0_cs0: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi2m0_cs1: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi2m1_pins: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_none>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_none>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi2m1_cs0: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi2m1_cs1: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_none>;
+		};
+	};
+	spi3 {
+		/omit-if-no-ref/
+		spi3m0_pins: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_none>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_none>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi3m0_cs0: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi3m0_cs1: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi3m1_pins: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_none>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_none>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi3m1_cs0: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		spi3m1_cs1: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_none>;
+		};
+	};
+	tsadc {
+		/omit-if-no-ref/
+		tsadcm0_shut: tsadcm0-shut {
+			rockchip,pins =
+				/* tsadcm0_shut */
+				<0 RK_PA1 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		tsadcm1_shut: tsadcm1-shut {
+			rockchip,pins =
+				/* tsadcm1_shut */
+				<0 RK_PA2 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		tsadc_shutorg: tsadc-shutorg {
+			rockchip,pins =
+				/* tsadc_shutorg */
+				<0 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+	uart0 {
+		/omit-if-no-ref/
+		uart0_xfer: uart0-xfer {
+			rockchip,pins =
+				/* uart0_rx */
+				<0 RK_PC0 3 &pcfg_pull_up>,
+				/* uart0_tx */
+				<0 RK_PC1 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart0_ctsn: uart0-ctsn {
+			rockchip,pins =
+				/* uart0_ctsn */
+				<0 RK_PC7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart0_rtsn: uart0-rtsn {
+			rockchip,pins =
+				/* uart0_rtsn */
+				<0 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+	uart1 {
+		/omit-if-no-ref/
+		uart1m0_xfer: uart1m0-xfer {
+			rockchip,pins =
+				/* uart1_rxm0 */
+				<2 RK_PB3 2 &pcfg_pull_up>,
+				/* uart1_txm0 */
+				<2 RK_PB4 2 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart1m0_ctsn: uart1m0-ctsn {
+			rockchip,pins =
+				/* uart1m0_ctsn */
+				<2 RK_PB6 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart1m0_rtsn: uart1m0-rtsn {
+			rockchip,pins =
+				/* uart1m0_rtsn */
+				<2 RK_PB5 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart1m1_xfer: uart1m1-xfer {
+			rockchip,pins =
+				/* uart1_rxm1 */
+				<3 RK_PD7 4 &pcfg_pull_up>,
+				/* uart1_txm1 */
+				<3 RK_PD6 4 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart1m1_ctsn: uart1m1-ctsn {
+			rockchip,pins =
+				/* uart1m1_ctsn */
+				<4 RK_PC1 4 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart1m1_rtsn: uart1m1-rtsn {
+			rockchip,pins =
+				/* uart1m1_rtsn */
+				<4 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+	uart2 {
+		/omit-if-no-ref/
+		uart2m0_xfer: uart2m0-xfer {
+			rockchip,pins =
+				/* uart2_rxm0 */
+				<0 RK_PD0 1 &pcfg_pull_up>,
+				/* uart2_txm0 */
+				<0 RK_PD1 1 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart2m1_xfer: uart2m1-xfer {
+			rockchip,pins =
+				/* uart2_rxm1 */
+				<1 RK_PD6 2 &pcfg_pull_up>,
+				/* uart2_txm1 */
+				<1 RK_PD5 2 &pcfg_pull_up>;
+		};
+	};
+	uart3 {
+		/omit-if-no-ref/
+		uart3m0_xfer: uart3m0-xfer {
+			rockchip,pins =
+				/* uart3_rxm0 */
+				<1 RK_PA0 2 &pcfg_pull_up>,
+				/* uart3_txm0 */
+				<1 RK_PA1 2 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart3m0_ctsn: uart3m0-ctsn {
+			rockchip,pins =
+				/* uart3m0_ctsn */
+				<1 RK_PA3 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart3m0_rtsn: uart3m0-rtsn {
+			rockchip,pins =
+				/* uart3m0_rtsn */
+				<1 RK_PA2 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart3m1_xfer: uart3m1-xfer {
+			rockchip,pins =
+				/* uart3_rxm1 */
+				<3 RK_PC0 4 &pcfg_pull_up>,
+				/* uart3_txm1 */
+				<3 RK_PB7 4 &pcfg_pull_up>;
+		};
+	};
+	uart4 {
+		/omit-if-no-ref/
+		uart4m0_xfer: uart4m0-xfer {
+			rockchip,pins =
+				/* uart4_rxm0 */
+				<1 RK_PA4 2 &pcfg_pull_up>,
+				/* uart4_txm0 */
+				<1 RK_PA6 2 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart4m0_ctsn: uart4m0-ctsn {
+			rockchip,pins =
+				/* uart4m0_ctsn */
+				<1 RK_PA7 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart4m0_rtsn: uart4m0-rtsn {
+			rockchip,pins =
+				/* uart4m0_rtsn */
+				<1 RK_PA5 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart4m1_xfer: uart4m1-xfer {
+			rockchip,pins =
+				/* uart4_rxm1 */
+				<3 RK_PB1 4 &pcfg_pull_up>,
+				/* uart4_txm1 */
+				<3 RK_PB2 4 &pcfg_pull_up>;
+		};
+	};
+	uart5 {
+		/omit-if-no-ref/
+		uart5m0_xfer: uart5m0-xfer {
+			rockchip,pins =
+				/* uart5_rxm0 */
+				<2 RK_PA1 3 &pcfg_pull_up>,
+				/* uart5_txm0 */
+				<2 RK_PA2 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart5m0_ctsn: uart5m0-ctsn {
+			rockchip,pins =
+				/* uart5m0_ctsn */
+				<1 RK_PD7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart5m0_rtsn: uart5m0-rtsn {
+			rockchip,pins =
+				/* uart5m0_rtsn */
+				<2 RK_PA0 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart5m1_xfer: uart5m1-xfer {
+			rockchip,pins =
+				/* uart5_rxm1 */
+				<3 RK_PC3 4 &pcfg_pull_up>,
+				/* uart5_txm1 */
+				<3 RK_PC2 4 &pcfg_pull_up>;
+		};
+	};
+	uart6 {
+		/omit-if-no-ref/
+		uart6m0_xfer: uart6m0-xfer {
+			rockchip,pins =
+				/* uart6_rxm0 */
+				<2 RK_PA3 3 &pcfg_pull_up>,
+				/* uart6_txm0 */
+				<2 RK_PA4 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart6m0_ctsn: uart6m0-ctsn {
+			rockchip,pins =
+				/* uart6m0_ctsn */
+				<2 RK_PC0 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart6m0_rtsn: uart6m0-rtsn {
+			rockchip,pins =
+				/* uart6m0_rtsn */
+				<2 RK_PB7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart6m1_xfer: uart6m1-xfer {
+			rockchip,pins =
+				/* uart6_rxm1 */
+				<1 RK_PD6 3 &pcfg_pull_up>,
+				/* uart6_txm1 */
+				<1 RK_PD5 3 &pcfg_pull_up>;
+		};
+	};
+	uart7 {
+		/omit-if-no-ref/
+		uart7m0_xfer: uart7m0-xfer {
+			rockchip,pins =
+				/* uart7_rxm0 */
+				<2 RK_PA5 3 &pcfg_pull_up>,
+				/* uart7_txm0 */
+				<2 RK_PA6 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart7m0_ctsn: uart7m0-ctsn {
+			rockchip,pins =
+				/* uart7m0_ctsn */
+				<2 RK_PC2 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart7m0_rtsn: uart7m0-rtsn {
+			rockchip,pins =
+				/* uart7m0_rtsn */
+				<2 RK_PC1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart7m1_xfer: uart7m1-xfer {
+			rockchip,pins =
+				/* uart7_rxm1 */
+				<3 RK_PC5 4 &pcfg_pull_up>,
+				/* uart7_txm1 */
+				<3 RK_PC4 4 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart7m2_xfer: uart7m2-xfer {
+			rockchip,pins =
+				/* uart7_rxm2 */
+				<4 RK_PA3 4 &pcfg_pull_up>,
+				/* uart7_txm2 */
+				<4 RK_PA2 4 &pcfg_pull_up>;
+		};
+	};
+	uart8 {
+		/omit-if-no-ref/
+		uart8m0_xfer: uart8m0-xfer {
+			rockchip,pins =
+				/* uart8_rxm0 */
+				<2 RK_PC6 2 &pcfg_pull_up>,
+				/* uart8_txm0 */
+				<2 RK_PC5 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart8m0_ctsn: uart8m0-ctsn {
+			rockchip,pins =
+				/* uart8m0_ctsn */
+				<2 RK_PB2 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart8m0_rtsn: uart8m0-rtsn {
+			rockchip,pins =
+				/* uart8m0_rtsn */
+				<2 RK_PB1 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart8m1_xfer: uart8m1-xfer {
+			rockchip,pins =
+				/* uart8_rxm1 */
+				<3 RK_PA0 4 &pcfg_pull_up>,
+				/* uart8_txm1 */
+				<2 RK_PD7 4 &pcfg_pull_up>;
+		};
+	};
+	uart9 {
+		/omit-if-no-ref/
+		uart9m0_xfer: uart9m0-xfer {
+			rockchip,pins =
+				/* uart9_rxm0 */
+				<2 RK_PA7 3 &pcfg_pull_up>,
+				/* uart9_txm0 */
+				<2 RK_PB0 3 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart9m0_ctsn: uart9m0-ctsn {
+			rockchip,pins =
+				/* uart9m0_ctsn */
+				<2 RK_PC4 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart9m0_rtsn: uart9m0-rtsn {
+			rockchip,pins =
+				/* uart9m0_rtsn */
+				<2 RK_PC3 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		uart9m1_xfer: uart9m1-xfer {
+			rockchip,pins =
+				/* uart9_rxm1 */
+				<4 RK_PC6 4 &pcfg_pull_up>,
+				/* uart9_txm1 */
+				<4 RK_PC5 4 &pcfg_pull_up>;
+		};
+		/omit-if-no-ref/
+		uart9m2_xfer: uart9m2-xfer {
+			rockchip,pins =
+				/* uart9_rxm2 */
+				<4 RK_PA5 4 &pcfg_pull_up>,
+				/* uart9_txm2 */
+				<4 RK_PA4 4 &pcfg_pull_up>;
+		};
+	};
+	vop {
+		/omit-if-no-ref/
+		vopm0_pins: vopm0-pins {
+			rockchip,pins =
+				/* vop_pwmm0 */
+				<0 RK_PC3 2 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		vopm1_pins: vopm1-pins {
+			rockchip,pins =
+				/* vop_pwmm1 */
+				<3 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+};
+
+/*
+ * This part is edited handly.
+ */
+&pinctrl {
+	spi0-hs {
+		/omit-if-no-ref/
+		spi0m0_pins_hs: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi0m0_cs0_hs: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi0m0_cs1_hs: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi0m1_pins_hs: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi0m1_cs0_hs: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+	spi1-hs {
+		/omit-if-no-ref/
+		spi1m0_pins_hs: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi1m0_cs0_hs: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi1m0_cs1_hs: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi1m1_pins_hs: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi1m1_cs0_hs: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+	spi2-hs {
+		/omit-if-no-ref/
+		spi2m0_pins_hs: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi2m0_cs0_hs: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi2m0_cs1_hs: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi2m1_pins_hs: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi2m1_cs0_hs: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi2m1_cs1_hs: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+	spi3-hs {
+		/omit-if-no-ref/
+		spi3m0_pins_hs: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi3m0_cs0_hs: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi3m0_cs1_hs: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi3m1_pins_hs: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi3m1_cs0_hs: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+		/omit-if-no-ref/
+		spi3m1_cs1_hs: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+	gmac-txd-level3 {
+		/omit-if-no-ref/
+		gmac0_tx_bus2_level3: gmac0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac0_rgmii_bus_level3: gmac0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_3>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2_level3: gmac1m0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus_level3: gmac1m0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_3>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2_level3: gmac1m1-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus_level3: gmac1m1-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_3>;
+		};
+	};
+	gmac-txc-level2 {
+		/omit-if-no-ref/
+		gmac0_rgmii_clk_level2: gmac0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk_level2: gmac1m0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_2>;
+		};
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk_level2: gmac1m1-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+	gpio {
+		/omit-if-no-ref/
+		tsadc_gpio: tsadc-gpio {
+			rockchip,pins =
+				<0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
new file mode 100644
index 000000000000..ac8db2f54f2b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -0,0 +1,795 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/clock/rk3568-cru.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,boot-mode.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+	compatible = "rockchip,rk3568";
+
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial2 = &uart2;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+			clocks = <&scmi_clk 0>;
+			operating-points-v2 = <&cpu0_opp_table>;
+			#cooling-cells = <2>;
+		};
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x300>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+	};
+
+	cpu0_opp_table: cpu0-opp-table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <825000 825000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <825000 825000 1150000>;
+		};
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <825000 825000 1150000>;
+			opp-suspend;
+		};
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <825000 825000 1150000>;
+		};
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <975000 975000 1150000>;
+		};
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1050000 1050000 1150000>;
+		};
+		opp-1992000000 {
+			opp-hz = /bits/ 64 <1992000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+		};
+	};
+
+	arm-pmu {
+		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	firmware {
+		scmi: scmi {
+			compatible = "arm,scmi-smc";
+			shmem = <&scmi_shmem>;
+			arm,smc-id = <0x82000010>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			scmi_clk: protocol at 14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+		};
+
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		arm,no-tick-in-suspend;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	xin32k: xin32k {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		clock-output-names = "xin32k";
+		#clock-cells = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&clk32k_out0>;
+	};
+
+	scmi_shmem: scmi-shmem at 10f000 {
+		compatible = "arm,scmi-shmem";
+		reg = <0x0 0x0010f000 0x0 0x100>;
+	};
+
+	gic: interrupt-controller at fd400000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
+		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	pmugrf: syscon at fdc20000 {
+		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc20000 0x0 0x10000>;
+
+		reboot_mode: reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x200>;
+			mode-bootloader = <BOOT_BL_DOWNLOAD>;
+			mode-loader = <BOOT_BL_DOWNLOAD>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+		};
+	};
+
+	grf: syscon at fdc60000 {
+		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc60000 0x0 0x10000>;
+	};
+
+	pmucru: clock-controller at fdd00000 {
+		compatible = "rockchip,rk3568-pmucru";
+		reg = <0x0 0xfdd00000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		rockchip,pmugrf = <&pmugrf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at fdd20000 {
+		compatible = "rockchip,rk3568-cru";
+		reg = <0x0 0xfdd20000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+
+		assigned-clocks =
+			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
+			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
+			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
+			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
+			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
+			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
+			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
+			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
+			<&cru ACLK_VOP>;
+		assigned-clock-rates =
+			<32768>, <200000000>,
+			<100000000>, <1000000000>,
+			<1188000000>, <150000000>,
+			<100000000>, <500000000>,
+			<400000000>, <150000000>,
+			<100000000>, <300000000>,
+			<150000000>, <1200000000>,
+			<400000000>, <100000000>,
+			<500000000>;
+		assigned-clock-parents =
+			<&pmucru CLK_RTC32K_FRAC>;
+	};
+
+	i2c0: i2c at fdd40000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfdd40000 0x0 0x1000>;
+		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c0_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart0: serial at fdd50000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfdd50000 0x0 0x100>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 0>, <&dmac0 1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart0_xfer>;
+		status = "disabled";
+	};
+
+	pwm0: pwm at fdd70000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70000 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm0m0_pins>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm1: pwm at fdd70010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70010 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm1m0_pins>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm2: pwm at fdd70020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70020 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm2m0_pins>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm3: pwm at fdd70030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70030 0x0 0x10>;
+		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm3_pins>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	sdmmc2: dwmmc at fe000000 {
+		compatible = "rockchip,rk3568-dw-mshc",
+			     "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe000000 0x0 0x4000>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		max-frequency = <150000000>;
+		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
+			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		resets = <&cru SRST_SDMMC2>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc0: dwmmc at fe2b0000 {
+		compatible = "rockchip,rk3568-dw-mshc",
+			     "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2b0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		max-frequency = <150000000>;
+		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
+			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		resets = <&cru SRST_SDMMC0>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc1: dwmmc at fe2c0000 {
+		compatible = "rockchip,rk3568-dw-mshc",
+			     "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2c0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		max-frequency = <150000000>;
+		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
+			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		resets = <&cru SRST_SDMMC1>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdhci: sdhci at fe310000 {
+		compatible = "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci";
+		reg = <0x0 0xfe310000 0x0 0x10000>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
+		assigned-clock-rates = <200000000>, <24000000>;
+		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
+			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
+			 <&cru TCLK_EMMC>;
+		clock-names = "core", "bus", "axi", "block", "timer";
+		status = "disabled";
+	};
+
+	dmac0: dmac at fe530000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe530000 0x0 0x4000>;
+		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+		arm,pl330-periph-burst;
+	};
+
+	dmac1: dmac at fe550000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe550000 0x0 0x4000>;
+		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+		arm,pl330-periph-burst;
+	};
+
+	i2c1: i2c at fe5a0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5a0000 0x0 0x1000>;
+		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c1_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at fe5b0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5b0000 0x0 0x1000>;
+		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c2m0_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at fe5c0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5c0000 0x0 0x1000>;
+		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c3m0_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at fe5d0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5d0000 0x0 0x1000>;
+		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c4m0_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at fe5e0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5e0000 0x0 0x1000>;
+		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+		clock-names = "i2c", "pclk";
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c5m0_xfer>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	wdt: watchdog at fe600000 {
+		compatible = "snps,dw-wdt";
+		reg = <0x0 0xfe600000 0x0 0x100>;
+		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
+		clock-names = "tclk", "pclk";
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+		status = "okay";
+	};
+
+	uart1: serial at fe650000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe650000 0x0 0x100>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 2>, <&dmac0 3>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart1m0_xfer>;
+		status = "disabled";
+	};
+
+	uart2: serial at fe660000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe660000 0x0 0x100>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 4>, <&dmac0 5>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart2m0_xfer>;
+		status = "disabled";
+	};
+
+	uart3: serial at fe670000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe670000 0x0 0x100>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 6>, <&dmac0 7>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart3m0_xfer>;
+		status = "disabled";
+	};
+
+	uart4: serial at fe680000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe680000 0x0 0x100>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 8>, <&dmac0 9>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart4m0_xfer>;
+		status = "disabled";
+	};
+
+	uart5: serial at fe690000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe690000 0x0 0x100>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 10>, <&dmac0 11>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart5m0_xfer>;
+		status = "disabled";
+	};
+
+	uart6: serial at fe6a0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6a0000 0x0 0x100>;
+		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 12>, <&dmac0 13>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart6m0_xfer>;
+		status = "disabled";
+	};
+
+	uart7: serial at fe6b0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6b0000 0x0 0x100>;
+		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 14>, <&dmac0 15>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart7m0_xfer>;
+		status = "disabled";
+	};
+
+	uart8: serial at fe6c0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6c0000 0x0 0x100>;
+		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 16>, <&dmac0 17>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart8m0_xfer>;
+		status = "disabled";
+	};
+
+	uart9: serial at fe6d0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6d0000 0x0 0x100>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
+		clock-names = "baudclk", "apb_pclk";
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		dmas = <&dmac0 18>, <&dmac0 19>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&uart9m0_xfer>;
+		status = "disabled";
+	};
+
+	pwm4: pwm at fe6e0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0000 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm4_pins>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm5: pwm at fe6e0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0010 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm5_pins>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm6: pwm at fe6e0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0020 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm6_pins>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm7: pwm at fe6e0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0030 0x0 0x10>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm7_pins>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm8: pwm at fe6f0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0000 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm8m0_pins>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm9: pwm at fe6f0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0010 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm9m0_pins>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm10: pwm at fe6f0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0020 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm10m0_pins>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm11: pwm at fe6f0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0030 0x0 0x10>;
+		interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm11m0_pins>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm12: pwm at fe700000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700000 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm12m0_pins>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm13: pwm at fe700010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700010 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm13m0_pins>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm14: pwm at fe700020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700020 0x0 0x10>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm14m0_pins>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pwm15: pwm at fe700030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700030 0x0 0x10>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+		#pwm-cells = <3>;
+		pinctrl-names = "active";
+		pinctrl-0 = <&pwm15m0_pins>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3568-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gpio0: gpio0 at fdd60000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfdd60000 0x0 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio1: gpio1 at fe740000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe740000 0x0 0x100>;
+			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio2: gpio2 at fe750000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe750000 0x0 0x100>;
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio3: gpio3 at fe760000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe760000 0x0 0x100>;
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio4: gpio4 at fe770000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe770000 0x0 0x100>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
+
+#include "rk3568-pinctrl.dtsi"
diff --git a/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
new file mode 100644
index 000000000000..0c292ef8a87a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+&pinctrl {
+
+	/omit-if-no-ref/
+	pcfg_pull_up: pcfg-pull-up {
+		bias-pull-up;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down: pcfg-pull-down {
+		bias-pull-down;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none: pcfg-pull-none {
+		bias-disable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0: pcfg-pull-none-drv-level-0 {
+		bias-disable;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_1: pcfg-pull-none-drv-level-1 {
+		bias-disable;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_2: pcfg-pull-none-drv-level-2 {
+		bias-disable;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_3: pcfg-pull-none-drv-level-3 {
+		bias-disable;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_4: pcfg-pull-none-drv-level-4 {
+		bias-disable;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_5: pcfg-pull-none-drv-level-5 {
+		bias-disable;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_6: pcfg-pull-none-drv-level-6 {
+		bias-disable;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_7: pcfg-pull-none-drv-level-7 {
+		bias-disable;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_8: pcfg-pull-none-drv-level-8 {
+		bias-disable;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_9: pcfg-pull-none-drv-level-9 {
+		bias-disable;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_10: pcfg-pull-none-drv-level-10 {
+		bias-disable;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_11: pcfg-pull-none-drv-level-11 {
+		bias-disable;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_12: pcfg-pull-none-drv-level-12 {
+		bias-disable;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_13: pcfg-pull-none-drv-level-13 {
+		bias-disable;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_14: pcfg-pull-none-drv-level-14 {
+		bias-disable;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_15: pcfg-pull-none-drv-level-15 {
+		bias-disable;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_0: pcfg-pull-up-drv-level-0 {
+		bias-pull-up;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_1: pcfg-pull-up-drv-level-1 {
+		bias-pull-up;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_2: pcfg-pull-up-drv-level-2 {
+		bias-pull-up;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_3: pcfg-pull-up-drv-level-3 {
+		bias-pull-up;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_4: pcfg-pull-up-drv-level-4 {
+		bias-pull-up;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_5: pcfg-pull-up-drv-level-5 {
+		bias-pull-up;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_6: pcfg-pull-up-drv-level-6 {
+		bias-pull-up;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_7: pcfg-pull-up-drv-level-7 {
+		bias-pull-up;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_8: pcfg-pull-up-drv-level-8 {
+		bias-pull-up;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_9: pcfg-pull-up-drv-level-9 {
+		bias-pull-up;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_10: pcfg-pull-up-drv-level-10 {
+		bias-pull-up;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_11: pcfg-pull-up-drv-level-11 {
+		bias-pull-up;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_12: pcfg-pull-up-drv-level-12 {
+		bias-pull-up;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_13: pcfg-pull-up-drv-level-13 {
+		bias-pull-up;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_14: pcfg-pull-up-drv-level-14 {
+		bias-pull-up;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_15: pcfg-pull-up-drv-level-15 {
+		bias-pull-up;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_0: pcfg-pull-down-drv-level-0 {
+		bias-pull-down;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_1: pcfg-pull-down-drv-level-1 {
+		bias-pull-down;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_2: pcfg-pull-down-drv-level-2 {
+		bias-pull-down;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_3: pcfg-pull-down-drv-level-3 {
+		bias-pull-down;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_4: pcfg-pull-down-drv-level-4 {
+		bias-pull-down;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_5: pcfg-pull-down-drv-level-5 {
+		bias-pull-down;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_6: pcfg-pull-down-drv-level-6 {
+		bias-pull-down;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_7: pcfg-pull-down-drv-level-7 {
+		bias-pull-down;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_8: pcfg-pull-down-drv-level-8 {
+		bias-pull-down;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_9: pcfg-pull-down-drv-level-9 {
+		bias-pull-down;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_10: pcfg-pull-down-drv-level-10 {
+		bias-pull-down;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_11: pcfg-pull-down-drv-level-11 {
+		bias-pull-down;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_12: pcfg-pull-down-drv-level-12 {
+		bias-pull-down;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_13: pcfg-pull-down-drv-level-13 {
+		bias-pull-down;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_14: pcfg-pull-down-drv-level-14 {
+		bias-pull-down;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_15: pcfg-pull-down-drv-level-15 {
+		bias-pull-down;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_smt: pcfg-pull-up-smt {
+		bias-pull-up;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_smt: pcfg-pull-down-smt {
+		bias-pull-down;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_smt: pcfg-pull-none-smt {
+		bias-disable;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0_smt: pcfg-pull-none-drv-level-0-smt {
+		bias-disable;
+		drive-strength = <0>;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_low: pcfg-output-low {
+		output-low;
+	};
+};
+
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 21 08:01:15 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 21 Apr 2021 15:01:15 +0800
Subject: [PATCH v1 5/5] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210421065921.23917-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
Message-ID: <20210421070115.24000-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
add uart/emmc/i2c/rk809 node for basic function.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/arm/rockchip.yaml     |   5 +
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 382 ++++++++++++++++++
 3 files changed, 388 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4a6f772c1043..d26b062a9f0e 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -560,6 +560,11 @@ properties:
           - const: rockchip,rk3368-evb-act8846
           - const: rockchip,rk3368
 
+      - description: Rockchip RK3568 Evaluation board
+        items:
+          - const: rockchip,rk3568-evb1-v10
+          - const: rockchip,rk3568
+
       - description: Rockchip RK3399 Evaluation board
         items:
           - const: rockchip,rk3399-evb
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index c3e00c0e2db7..7fdb41de01ec 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -51,3 +51,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
new file mode 100644
index 000000000000..be8aae2e8c67
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3568.dtsi"
+
+/ {
+	model = "Rockchip RK3568 EVB1 DDR4 V10 Board";
+	compatible = "rockchip,rk3568-evb1-v10", "rockchip,rk3568";
+
+	chosen: chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		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_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+	};
+
+	vcc5v0_otg: vcc5v0-otg-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_otg_en>;
+		regulator-name = "vcc5v0_otg";
+	};
+
+	vcc3v3_lcd0_n: vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_lcd1_n: vcc3v3-lcd1-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd1_n";
+		regulator-boot-on;
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c0 {
+	status = "okay";
+
+	rk809: pmic at 20 {
+		compatible = "rockchip,rk809";
+		reg = <0x20>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+		pinctrl-names = "default", "pmic-sleep",
+				"pmic-power-off", "pmic-reset";
+		pinctrl-0 = <&pmic_int>;
+		pinctrl-1 = <&soc_slppin_slp>, <&rk817_slppin_slp>;
+		pinctrl-2 = <&soc_slppin_gpio>, <&rk817_slppin_pwrdn>;
+		pinctrl-3 = <&soc_slppin_gpio>, <&rk817_slppin_rst>;
+
+		rockchip,system-power-controller;
+		wakeup-source;
+		#clock-cells = <1>;
+		clock-output-names = "rk808-clkout1", "rk808-clkout2";
+		//fb-inner-reg-idxs = <2>;
+		/* 1: rst regs (default in codes), 0: rst the pmic */
+		pmic-reset-func = <0>;
+
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc5-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+
+		pwrkey {
+			status = "okay";
+		};
+
+		pinctrl_rk8xx: pinctrl_rk8xx {
+			gpio-controller;
+			#gpio-cells = <2>;
+
+			rk817_slppin_null: rk817_slppin_null {
+				pins = "gpio_slp";
+				function = "pin_fun0";
+			};
+
+			rk817_slppin_slp: rk817_slppin_slp {
+				pins = "gpio_slp";
+				function = "pin_fun1";
+			};
+
+			rk817_slppin_pwrdn: rk817_slppin_pwrdn {
+				pins = "gpio_slp";
+				function = "pin_fun2";
+			};
+
+			rk817_slppin_rst: rk817_slppin_rst {
+				pins = "gpio_slp";
+				function = "pin_fun3";
+			};
+		};
+
+		regulators {
+			vdd_logic: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-init-microvolt = <900000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_logic";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_gpu: DCDC_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-init-microvolt = <900000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_gpu";
+				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;
+				};
+			};
+
+			vdd_npu: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-init-microvolt = <900000>;
+				regulator-ramp-delay = <6001>;
+				regulator-initial-mode = <0x2>;
+				regulator-name = "vdd_npu";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda0v9_image: LDO_REG1 {
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda0v9_image";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdda_0v9: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-name = "vdda_0v9";
+				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;
+					regulator-suspend-microvolt = <900000>;
+				};
+			};
+
+			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;
+					regulator-suspend-microvolt = <3300000>;
+				};
+			};
+
+			vcca_1v8: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca_1v8";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca1v8_pmu: LDO_REG8 {
+				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;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcca1v8_image: LDO_REG9 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_image";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG5 {
+				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;
+				};
+			};
+
+			vcc_3v3: SWITCH_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_3v3";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_sd: SWITCH_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc3v3_sd";
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+
+&pinctrl {
+	pmic {
+		pmic_int: pmic_int {
+			rockchip,pins =
+				<0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		soc_slppin_gpio: soc_slppin_gpio {
+			rockchip,pins =
+				<0 RK_PA2 RK_FUNC_GPIO &pcfg_output_low>;
+		};
+
+		soc_slppin_slp: soc_slppin_slp {
+			rockchip,pins =
+				<0 RK_PA2 1 &pcfg_pull_none>;
+		};
+
+		soc_slppin_rst: soc_slppin_rst {
+			rockchip,pins =
+				<0 RK_PA2 2 &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		vcc5v0_otg_en: vcc5v0-otg-en {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	non-removable;
+	rockchip,txclk-tapnum = <0x8>;
+	max-frequency = <200000000>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
-- 
2.17.1





From david at redhat.com  Wed Apr 21 08:49:01 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 21 Apr 2021 09:49:01 +0200
Subject: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210421065108.1987-5-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-5-rppt@kernel.org>
Message-ID: <24edab0c-226c-7ff6-2151-7a8b218c7c44@redhat.com>

On 21.04.21 08:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>    verify that there is actual physical memory that corresponds to a pfn
>    which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>    linear map and until the previous commit the struct pages representing
>    these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   arch/arm64/Kconfig   | 3 ---
>   arch/arm64/mm/init.c | 4 ++--
>   2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>   	def_bool y
>   	depends on NUMA
>   
> -config HOLES_IN_ZONE
> -	def_bool y
> -
>   source "kernel/Kconfig.hz"
>   
>   config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index dc03bdc12c0f..eb3f56fb8c7c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>   
>   	/*
>   	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>   	 * addresses will always fail. Even the normal hotplugged
>   	 * memory will never have MEMBLOCK_NOMAP flag set in their
>   	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>   		return pfn_section_valid(ms, pfn);
>   }
>   #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> 

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From david at redhat.com  Wed Apr 21 08:49:24 2021
From: david at redhat.com (David Hildenbrand)
Date: Wed, 21 Apr 2021 09:49:24 +0200
Subject: [PATCH v2 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210421065108.1987-3-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-3-rppt@kernel.org>
Message-ID: <752fd822-6479-53f1-81fb-24b55500e963@redhat.com>

On 21.04.21 08:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().
> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   include/linux/memblock.h |  4 +++-
>   mm/memblock.c            | 28 ++++++++++++++++++++++++++--
>   2 files changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5984fff3f175..634c1a578db8 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
>    * @MEMBLOCK_NONE: no special request
>    * @MEMBLOCK_HOTPLUG: hotpluggable region
>    * @MEMBLOCK_MIRROR: mirrored region
> - * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> + * reserved in the memory map; refer to memblock_mark_nomap() description
> + * for futher details
>    */
>   enum memblock_flags {
>   	MEMBLOCK_NONE		= 0x0,	/* No special request */
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..3abf2c3fea7f 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
>    * @base: the base phys addr of the region
>    * @size: the size of the region
>    *
> + * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
> + * direct mapping of the physical memory. These regions will still be
> + * covered by the memory map. The struct page representing NOMAP memory
> + * frames in the memory map will be PageReserved()
> + *
>    * Return: 0 on success, -errno on failure.
>    */
>   int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
> @@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>   	return end_pfn - start_pfn;
>   }
>   
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}
> +}
> +
>   static unsigned long __init free_low_memory_core_early(void)
>   {
>   	unsigned long count = 0;
> @@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
>   
>   	memblock_clear_hotplug(0, -1);
>   
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>   
>   	/*
>   	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 

Reviewed-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From jiapeng.chong at linux.alibaba.com  Wed Apr 21 08:56:09 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Wed, 21 Apr 2021 15:56:09 +0800
Subject: [PATCH] soc: fsl: qe: remove unused function
In-Reply-To: <76468b5b-0eb0-8772-b7b5-21bb708aa053@csgroup.eu>
References: <1618475663-100748-1-git-send-email-jiapeng.chong@linux.alibaba.com>
 <87blaeg1ig.fsf@linkitivity.dja.id.au>
 <76468b5b-0eb0-8772-b7b5-21bb708aa053@csgroup.eu>
Message-ID: <fafbfcb2-e9d7-4992-a104-1523039807f9@linux.alibaba.com>

On 2021/4/16 15:06, Christophe Leroy wrote:
> 
> 
> Le 16/04/2021 ? 08:57, Daniel Axtens a ?crit?:
>> Hi Jiapeng,
>>
>>> Fix the following clang warning:
> 
> You are not fixing a warning, you are removing a function in order to 
> fix a warning ...
> 
>>>
>>> drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
>>> 'qe_ic_from_irq' [-Wunused-function].
> 
> Would be wise to tell that the last users of the function where removed 
> by commit d7c2878cfcfa ("soc: fsl: qe: remove unused qe_ic_set_* 
> functions")
> 
> https://github.com/torvalds/linux/commit/d7c2878cfcfa
> 
>>>
>>> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
>>> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
>>> ---
>>> ? drivers/soc/fsl/qe/qe_ic.c | 5 -----
>>> ? 1 file changed, 5 deletions(-)
>>>
>>> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
>>> index 0390af9..b573712 100644
>>> --- a/drivers/soc/fsl/qe/qe_ic.c
>>> +++ b/drivers/soc/fsl/qe/qe_ic.c
>>> @@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32? __iomem 
>>> *base, unsigned int reg,
>>> ????? qe_iowrite32be(value, base + (reg >> 2));
>>> ? }
>>> -static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
>>> -{
>>> -??? return irq_get_chip_data(virq);
>>> -}
>>
>> This seems good to me.
>>
>> ? * We know that this function can't be called directly from outside the
>> ?? file, because it is static.
>>
>> ? * The function address isn't used as a function pointer anywhere, so
>> ??? that means it can't be called from outside the file that way (also
>> ??? it's inline, which would make using a function pointer unwise!)
>>
>> ? * There's no obvious macros in that file that might construct the name
>> ??? of the function in a way that is hidden from grep.
>>
>> All in all, I am fairly confident that the function is indeed not used.
>>
>> Reviewed-by: Daniel Axtens <dja at axtens.net>
>>
>> Kind regards,
>> Daniel
>>
>>> -
>>> ? static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
>>> ? {
>>> ????? return irq_data_get_irq_chip_data(d);
>>> -- 
>>> 1.8.3.1
Hi,
I will follow the advice and send V2 later.


From wangqing at vivo.com  Wed Apr 21 09:05:04 2021
From: wangqing at vivo.com (Wang Qing)
Date: Wed, 21 Apr 2021 16:05:04 +0800
Subject: [PATCH V5] watchdog: mtk: support dual mode when the bark irq is
 available
Message-ID: <1618992304-18903-1-git-send-email-wangqing@vivo.com>

Support using irq handling wdt bark first instead of directly resetting.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The dual mode is disabled by default.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 36 ++++++++++++++++++++++++++++++++----
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..40122f8
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -57,6 +58,7 @@
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 static unsigned int timeout;
+static bool dual_mode;
 
 struct mtk_wdt_dev {
 	struct watchdog_device wdt_dev;
@@ -239,13 +241,23 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (dual_mode)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	panic("wdt bark!\n");
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -267,7 +279,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,6 +291,19 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
+	if (dual_mode) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq > 0) {
+			err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+						&mtk_wdt->wdt_dev);
+			if (err)
+				return err;
+		} else {
+			dual_mode = 0;
+			dev_info(&pdev->dev, "couldn't get wdt irq, set dual_mode = 0\n");
+		}
+	}
+
 	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
@@ -299,8 +324,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (unlikely(err))
 		return err;
 
-	dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)\n",
-		 mtk_wdt->wdt_dev.timeout, nowayout);
+	dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
+		 dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
 
 	wdt_data = of_device_get_match_data(dev);
 	if (wdt_data) {
@@ -368,6 +393,9 @@ module_param(nowayout, bool, 0);
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
 			__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
+module_param(dual_mode, bool, 0);
+MODULE_PARM_DESC(dual_mode, "Dual mode triggers irq before reset (default=0)");
+
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Matthias Brugger <matthias.bgg at gmail.com>");
 MODULE_DESCRIPTION("Mediatek WatchDog Timer Driver");
-- 
2.7.4



From liuqi115 at huawei.com  Wed Apr 21 09:22:49 2021
From: liuqi115 at huawei.com (liuqi (BA))
Date: Wed, 21 Apr 2021 16:22:49 +0800
Subject: [PATCH v3 2/2] drivers/perf: hisi: Add driver for HiSilicon PCIe
 PMU
In-Reply-To: <778f067e-9ad1-a84f-807d-09fc6f143032@huawei.com>
References: <1618490885-44612-1-git-send-email-liuqi115@huawei.com>
 <1618490885-44612-3-git-send-email-liuqi115@huawei.com>
 <778f067e-9ad1-a84f-807d-09fc6f143032@huawei.com>
Message-ID: <9fe957b3-2502-86ea-e427-9946771344bc@huawei.com>

Hi John,

On 2021/4/20 17:45, John Garry wrote:
> On 15/04/2021 13:48, Qi Liu wrote:
>> PCIe PMU Root Complex Integrated End Point(RCiEP) device is supported
>> to sample bandwidth, latency, buffer occupation etc.
>>
>> Each PMU RCiEP device monitors multiple Root Ports, and each RCiEP is
>> registered as a PMU in /sys/bus/event_source/devices, so users can
>> select target PMU, and use filter to do further sets.
>>
>> Filtering options contains:
>> event??????? - select the event.
>> subevent???? - select the subevent.
>> port???????? - select target Root Ports. Information of Root Ports
>> ??????????????? are shown under sysfs.
>> bdf????????? - select requester_id of target EP device.
>> trig_len???? - set trigger condition for starting event statistics.
>> trigger_mode - set trigger mode. 0 means starting to statistic when
>> ??????????????? bigger than trigger condition, and 1 means smaller.
>> thr_len????? - set threshold for statistics.
>> thr_mode???? - set threshold mode. 0 means count when bigger than
>> ??????????????? threshold, and 1 means smaller.
>>
>> Signed-off-by: Qi Liu <liuqi115 at huawei.com>
> 
> Some minor items and nits with coding style below, but generally looks ok:
> 
> Reviewed-by: John Garry <john.garry at huawei.com>
> 
>> ---
>> ? MAINTAINERS??????????????????????????????? |??? 6 +
>> ? drivers/perf/Kconfig?????????????????????? |??? 2 +
>> ? drivers/perf/Makefile????????????????????? |??? 1 +
>> ? drivers/perf/pci/Kconfig?????????????????? |?? 16 +
>> ? drivers/perf/pci/Makefile????????????????? |??? 2 +
>> ? drivers/perf/pci/hisilicon/Makefile??????? |??? 3 +
>> ? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c | 1014 
>> ++++++++++++++++++++++++++++
>> ? include/linux/cpuhotplug.h???????????????? |??? 1 +
>> ? 8 files changed, 1045 insertions(+)
>> ? create mode 100644 drivers/perf/pci/Kconfig
>> ? create mode 100644 drivers/perf/pci/Makefile
>> ? create mode 100644 drivers/perf/pci/hisilicon/Makefile
>> ? create mode 100644 drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7fdc513..efe06cd 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8084,6 +8084,12 @@ W:??? http://www.hisilicon.com
>> ? F:??? Documentation/admin-guide/perf/hisi-pmu.rst
>> ? F:??? drivers/perf/hisilicon
>> +HISILICON PCIE PMU DRIVER
>> +M:??? Qi Liu <liuqi115 at huawei.com>
>> +S:??? Maintained
>> +F:??? Documentation/admin-guide/perf/hisi-pcie-pmu.rst
>> +F:??? drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> +
>> ? HISILICON QM AND ZIP Controller DRIVER
>> ? M:??? Zhou Wang <wangzhou1 at hisilicon.com>
>> ? L:??? linux-crypto at vger.kernel.org
>> diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
>> index 77522e5..ddd82fa 100644
>> --- a/drivers/perf/Kconfig
>> +++ b/drivers/perf/Kconfig
>> @@ -139,4 +139,6 @@ config ARM_DMC620_PMU
>> ? source "drivers/perf/hisilicon/Kconfig"
>> +source "drivers/perf/pci/Kconfig"
>> +
>> ? endmenu
>> diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
>> index 5260b11..1208c08 100644
>> --- a/drivers/perf/Makefile
>> +++ b/drivers/perf/Makefile
>> @@ -14,3 +14,4 @@ obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
>> ? obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
>> ? obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
>> ? obj-$(CONFIG_ARM_DMC620_PMU) += arm_dmc620_pmu.o
>> +obj-y += pci/
>> diff --git a/drivers/perf/pci/Kconfig b/drivers/perf/pci/Kconfig
>> new file mode 100644
>> index 0000000..9f30291
>> --- /dev/null
>> +++ b/drivers/perf/pci/Kconfig
>> @@ -0,0 +1,16 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +#
>> +# PCIe Performance Monitor Drivers
>> +#
>> +menu "PCIe Performance Monitor"
>> +
>> +config HISI_PCIE_PMU
>> +??? tristate "HiSilicon PCIE PERF PMU"
>> +??? depends on (ARM64 && PCI) || COMPILE_TEST
>> +??? help
>> +????? Provide support for HiSilicon PCIe performance monitoring unit 
>> (PMU)
>> +????? RCiEP devices.
>> +????? Adds the PCIe PMU into perf events system for monitoring latency,
>> +????? bandwidth etc.
>> +
>> +endmenu
>> diff --git a/drivers/perf/pci/Makefile b/drivers/perf/pci/Makefile
>> new file mode 100644
>> index 0000000..a56b1a9
>> --- /dev/null
>> +++ b/drivers/perf/pci/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +obj-y += hisilicon/
>> diff --git a/drivers/perf/pci/hisilicon/Makefile 
>> b/drivers/perf/pci/hisilicon/Makefile
>> new file mode 100644
>> index 0000000..65b0bd7
>> --- /dev/null
>> +++ b/drivers/perf/pci/hisilicon/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +obj-$(CONFIG_HISI_PCIE_PMU) += hisi_pcie_pmu.o
>> diff --git a/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c 
>> b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> new file mode 100644
>> index 0000000..415bf39
>> --- /dev/null
>> +++ b/drivers/perf/pci/hisilicon/hisi_pcie_pmu.c
>> @@ -0,0 +1,1014 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * This driver adds support for PCIe PMU RCiEP device. Related
>> + * perf events are bandwidth, bandwidth utilization, latency
>> + * etc.
>> + *
>> + * Copyright (C) 2021 HiSilicon Limited
>> + * Author: Qi Liu<liuqi115 at huawei.com>
>> + */
>> +#include <linux/bitfield.h>
>> +#include <linux/bitmap.h>
>> +#include <linux/bug.h>
>> +#include <linux/cpuhotplug.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/irq.h>
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/pci.h>
>> +#include <linux/perf_event.h>
>> +
>> +/* Define registers */
>> +#define HISI_PCIE_GLOBAL_CTRL??????? 0x00
>> +#define HISI_PCIE_EVENT_CTRL??????? 0x010
>> +#define HISI_PCIE_CNT??????????? 0x090
>> +#define HISI_PCIE_EXT_CNT??????? 0x110
>> +#define HISI_PCIE_INT_STAT??????? 0x150
>> +#define HISI_PCIE_INT_MASK??????? 0x154
>> +#define HISI_PCIE_REG_BDF??????? 0xfe0
>> +#define HISI_PCIE_REG_VERSION??????? 0xfe4
>> +#define HISI_PCIE_REG_INFO??????? 0xfe8
>> +#define HISI_PCIE_REG_FREQ??????? 0xfec
>> +
>> +/* Define PCIE CTRL CMD */
>> +#define HISI_PCIE_GLOBAL_EN??????? 0x01
>> +#define HISI_PCIE_GLOBAL_NONE??????? 0
>> +#define HISI_PCIE_EVENT_EN??????? BIT(20)
>> +#define HISI_PCIE_RESET_CNT??????? BIT(22)
>> +#define HISI_PCIE_DEFAULT_SET??????? BIT(34)
>> +#define HISI_PCIE_THR_EN??????? BIT(26)
>> +#define HISI_PCIE_TARGET_EN??????? BIT(32)
>> +#define HISI_PCIE_TRIG_EN??????? BIT(52)
>> +
>> +/* Define offsets in event ctrl regesiter */
>> +#define HISI_PCIE_EVENT_M??????? GENMASK_ULL(7, 0)
>> +#define HISI_PCIE_SUBEVENT_M??????? GENMASK_ULL(15, 8)
>> +#define HISI_PCIE_THR_MODE_M??????? GENMASK_ULL(27, 27)
>> +#define HISI_PCIE_THR_M??????????? GENMASK_ULL(31, 28)
>> +#define HISI_PCIE_TARGET_M??????? GENMASK_ULL(52, 36)
>> +#define HISI_PCIE_TRIG_MODE_M??????? GENMASK_ULL(53, 53)
>> +#define HISI_PCIE_TRIG_M??????? GENMASK_ULL(59, 56)
>> +
>> +#define HISI_PCIE_MAX_COUNTERS??????? 8
>> +#define HISI_PCIE_REG_STEP??????? 8
>> +#define HISI_PCIE_EVENT_MAX??????? 0xa2
>> +#define HISI_PCIE_SUBEVENT_MAX??????? 0x20
>> +#define HISI_PCIE_THR_MAX_VAL??????? 10
>> +#define HISI_PCIE_TRIG_MAX_VAL??????? 10
>> +#define HISI_PCIE_COUNTER_BITS??????? 64
>> +#define HISI_PCIE_MAX_PERIOD??????? BIT_ULL(63)
>> +
>> +struct hisi_pcie_pmu {
>> +??? struct perf_event *hw_events[HISI_PCIE_MAX_COUNTERS];
>> +??? struct hlist_node node;
>> +??? struct pci_dev *pdev;
>> +??? struct pmu pmu;
>> +??? void __iomem *base;
>> +??? int irq;
>> +??? u32 identifier;
>> +??? /* Minimum and maximum bdf of root ports monitored by PMU */
>> +??? u16 bdf_min;
>> +??? u16 bdf_max;
>> +??? int on_cpu;
>> +};
>> +
>> +#define to_pcie_pmu(p)? (container_of((p), struct hisi_pcie_pmu, pmu))
>> +#define GET_PCI_DEVFN(bdf)? ((bdf) & 0xff)
>> +
>> +#define HISI_PCIE_PMU_FILTER_ATTR(_name, _config, _hi, _lo)????????? \
>> +??? static u64 hisi_pcie_get_##_name(struct perf_event *event)????? \
>> +??? {????????????????????????????????? \
>> +??????? return FIELD_GET(GENMASK(_hi, _lo), event->attr._config); \
>> +??? }????????????????????????????????? \
>> +
>> +HISI_PCIE_PMU_FILTER_ATTR(event, config, 7, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(subevent, config, 15, 8);
>> +HISI_PCIE_PMU_FILTER_ATTR(thr_len, config1, 3, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(thr_mode, config1, 4, 4);
>> +HISI_PCIE_PMU_FILTER_ATTR(trig_len, config1, 8, 5);
>> +HISI_PCIE_PMU_FILTER_ATTR(trig_mode, config1, 9, 9);
>> +HISI_PCIE_PMU_FILTER_ATTR(port, config2, 15, 0);
>> +HISI_PCIE_PMU_FILTER_ATTR(bdf, config2, 31, 16);
>> +
>> +#define HISI_PCIE_BUILD_EVENTS(name)???????????????????????? \
>> +??? static bool is_##name##_event(u32 idx)??????????????? \
>> +??? {??????????????????????????????? \
>> +??????? return (idx >= name##_events_list[0] &&??????????? \
>> +??????????? idx <= name##_events_list[1]) ||??????? \
>> +??????????? idx == name##_events_list[2];???????????? \
>> +??? }??????????????????????????????? \
>> +
>> +/*
>> + * The first element of event list is minimum index of TL-layer events
>> + * and the second element is maximum index. The third element is index
>> + * of a DL-layer event.
>> + */
>> +static const u32 bw_events_list[] = {0x04, 0x08, 0x84};
>> +static const u32 latency_events_list[] = {0x10, 0x15, 0x85};
>> +static const u32 bus_util_events_list[] = {0x20, 0x24, 0x09};
>> +static const u32 buf_util_events_list[] = {0x28, 0x2a, 0x33};
>> +
>> +HISI_PCIE_BUILD_EVENTS(bw);
>> +HISI_PCIE_BUILD_EVENTS(latency);
>> +HISI_PCIE_BUILD_EVENTS(bus_util);
>> +HISI_PCIE_BUILD_EVENTS(buf_util);
>> +
>> +static ssize_t hisi_pcie_format_sysfs_show(struct device *dev,
>> +??????????????????? struct device_attribute *attr, char *buf)
>> +{
>> +??? struct dev_ext_attribute *eattr;
>> +
>> +??? eattr = container_of(attr, struct dev_ext_attribute, attr);
>> +
>> +??? return sysfs_emit(buf, "%s\n", (char *)eattr->var);
>> +}
>> +
>> +static ssize_t hisi_pcie_event_sysfs_show(struct device *dev,
>> +?????????????????? struct device_attribute *attr, char *buf)
>> +{
>> +??? struct dev_ext_attribute *eattr;
>> +
>> +??? eattr = container_of(attr, struct dev_ext_attribute, attr);
>> +
>> +??? return sysfs_emit(buf, "config=0x%lx\n", (unsigned long)eattr->var);
>> +}
> 
> As before, I hope that we can have common versions of these function for 
> all drivers in future
> 
got it, will do this latter.
>> +
>> +static int hisi_pcie_pmu_event_init(struct perf_event *event)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +
>> +??? event->cpu = pcie_pmu->on_cpu;
>> +
>> +??? if (event->attr.type != event->pmu->type)
>> +??????? return -ENOENT;
>> +
>> +??? /* Sampling is not supported. */
>> +??? if (is_sampling_event(event) || event->attach_state & 
>> PERF_ATTACH_TASK)
>> +??????? return -EOPNOTSUPP;
>> +
>> +??? if (!hisi_pcie_pmu_valid_filter(event, pcie_pmu)) {
>> +??????? pci_err(pcie_pmu->pdev, "Invalid filter!\n");
>> +??????? return -EINVAL;
>> +??? }
>> +
>> +??? if (!hisi_pcie_pmu_validate_event_group(event))
>> +??????? return -EINVAL;
>> +
>> +??? return 0;
>> +}
>> +
> 
> again, if this is generic, then can factor out later
got it.
> 
>> +/*
>> + * The bandwidth, latency, bus utilization and buffer occupancy 
>> features are
>> + * calculated from data in HISI_PCIE_CNT and extern data in 
>> HISI_PCIE_EXT_CNT.
> 
> extern data? or extended data?
It should be "extended data" here, I'll fix this in next version. Thanks.
> 
>> + * Other features are obtained only by HISI_PCIE_CNT.
>> + * So data and data_ext are processed in this function to get 
>> performanace
>> + * value like, bandwidth, latency, etc.
>> + */
>> +static u64 hisi_pcie_pmu_get_performance(struct perf_event *event, 
>> u64 data,
>> +???????????????????? u64 data_ext)
>> +{
>> +#define CONVERT_DW_TO_BYTE(x)??? (sizeof(u32) * (x))
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u64 us_per_cycle = readl(pcie_pmu->base + HISI_PCIE_REG_FREQ);
>> +??? u32 idx = hisi_pcie_get_event(event);
>> +
>> +??? if (!data_ext)
>> +??????? return 0;
>> +
>> +??? /* Process data to set unit of bandwidth as "Byte/ms". */
>> +??? if (is_bw_event(idx)) {
> 
> ideally we could use a switch statement here, but with how macro 
> is_bw_event is defined, doesn't seem possible
> 
>> +??????? if (!data_ext / 1000)
>> +??????????? return 0;
>> +
>> +??????? return (CONVERT_DW_TO_BYTE(data)) / (data_ext / 1000);
>> +??? }
>> +
>> +??? /* Process data to set unit of latency as "us". */
>> +??? if (is_latency_event(idx))
>> +??????? return (data * us_per_cycle) / data_ext;
>> +
>> +??? if (is_bus_util_event(idx))
>> +??????? return (data * us_per_cycle) / data_ext;
>> +
>> +??? if (is_buf_util_event(idx))
>> +??????? return data / (data_ext * us_per_cycle);
>> +
>> +??? return data;
>> +}
>> +
>> +static void hisi_pcie_pmu_read_counter(struct perf_event *event, u64 
>> *cnt,
>> +?????????????????????? u64 *cnt_ext)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u32 idx = event->hw.idx;
>> +
>> +??? *cnt = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_CNT, idx);
>> +??? *cnt_ext = hisi_pcie_pmu_readq(pcie_pmu, HISI_PCIE_EXT_CNT, idx);
>> +}
>> +
>> +static void hisi_pcie_pmu_write_counter(struct perf_event *event, u64 
>> val,
>> +??????????????????? u64 val_ext)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = to_pcie_pmu(event->pmu);
>> +??? u32 idx = event->hw.idx;
>> +
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_CNT, idx, val);
>> +??? hisi_pcie_pmu_writeq(pcie_pmu, HISI_PCIE_EXT_CNT, idx, val_ext);
>> +}
>> +
>> +static int hisi_pcie_pmu_get_event_idx(struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? int idx;
>> +
>> +??? for (idx = 0; idx < HISI_PCIE_MAX_COUNTERS; idx++) {
>> +??????? if (!pcie_pmu->hw_events[idx])
>> +??????????? return idx;
>> +??? }
>> +
>> +??? return -EINVAL;
>> +}
>> +
>> +static void hisi_pcie_pmu_event_update(struct perf_event *event)
>> +{
>> +??? struct hw_perf_event *hwc = &event->hw;
>> +??? struct hw_perf_event_extra *hwc_ext = &hwc->extra_reg;
>> +??? u64 new_cnt_ext, prev_cnt_ext;
>> +??? u64 new_cnt, prev_cnt, delta;
>> +
>> +??? hwc_ext = &hwc->extra_reg;
>> +??? do {
>> +??????? prev_cnt = local64_read(&hwc->prev_count);
>> +??????? prev_cnt_ext = hwc_ext->config;
>> +??????? hisi_pcie_pmu_read_counter(event, &new_cnt, &new_cnt_ext);
>> +??? } while (local64_cmpxchg(&hwc->prev_count, prev_cnt,
>> +???????????????? new_cnt) != prev_cnt);
>> +
>> +??? hwc_ext->config = new_cnt_ext;
>> +
>> +??? delta = hisi_pcie_pmu_get_performance(event, new_cnt - prev_cnt,
>> +????????????????????????? new_cnt_ext - prev_cnt_ext);
>> +??? local64_add(delta, &event->count);
>> +}
> 
> ...
> 
>> +
>> +static int hisi_pcie_pmu_offline_cpu(unsigned int cpu, struct 
>> hlist_node *node)
>> +{
>> +??? struct hisi_pcie_pmu *pcie_pmu = hlist_entry_safe(node,
>> +???????????????????? struct hisi_pcie_pmu, node);
>> +??? unsigned int target;
>> +
>> +??? /* Nothing to do if this CPU doesn't own the PMU */
>> +??? if (pcie_pmu->on_cpu != cpu)
>> +??????? return 0;
>> +
>> +??? /* Choose a new CPU from all online cpus. */
>> +??? target = cpumask_any_but(cpu_online_mask, cpu);
> 
> I don't think cpu would ever be involved in cpu_online_mask at this 
> point. Not sure.
> 
You are righ, may be cpumask_first(cpu_online_mask) is enough
>> +??? if (target >= nr_cpu_ids)
>> +??????? return 0;
> 
> might be worth an error message if this fails ...
ok, will add one in next version.
> 
>> +
>> +??? perf_pmu_migrate_context(&pcie_pmu->pmu, cpu, target);
>> +??? /* Use this CPU for event counting */
>> +??? pcie_pmu->on_cpu = target;
>> +??? WARN_ON(irq_set_affinity_hint(pcie_pmu->irq, cpumask_of(target)));
>> +
>> +??? return 0;
>> +}
>> +
>> +/*
>> + * Events with the "dl" suffix in their names count performance in DL 
>> layer,
>> + * otherswise, events count performance in TL layer.
>> + */
>> +static struct attribute *hisi_pcie_pmu_events_attr[] = {
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mwr, 0x0104),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_rx_mrd, 0x1005),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mwr, 0x0105),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_tx_mrd, 0x2004),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mwr, 0x0010),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(lat_rx_mrd, 0x0210),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(lat_tx_mrd, 0x0011),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(lat_tx_cfg, 0x0111),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_rx_dl, 0x0184),
>> +??? HISI_PCIE_PMU_EVENT_ATTR(bw_tx_dl, 0x0384),
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_events_group = {
>> +??? .name = "events",
>> +??? .attrs = hisi_pcie_pmu_events_attr,
>> +};
>> +
>> +static struct attribute *hisi_pcie_pmu_format_attr[] = {
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(event, "config:0-7"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(subevent, "config:8-15"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(thr_len, "config1:0-3"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(thr_mode, "config1:4"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(trig_len, "config1:5-8"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(trig_mode, "config1:9"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(port, "config2:0-15"),
>> +??? HISI_PCIE_PMU_FORMAT_ATTR(bdf, "config2:16-31"),
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_format_group = {
>> +??? .name = "format",
>> +??? .attrs = hisi_pcie_pmu_format_attr,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_bus_attr =
>> +??? __ATTR(bus, 0444, hisi_pcie_bus_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_bus_attrs[] = {
>> +??? &hisi_pcie_pmu_bus_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_bus_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_bus_attrs,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_cpumask_attr =
>> +??? __ATTR(cpumask, 0444, hisi_pcie_cpumask_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_cpumask_attrs[] = {
>> +??? &hisi_pcie_pmu_cpumask_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_cpumask_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_cpumask_attrs,
>> +};
>> +
>> +static struct device_attribute hisi_pcie_pmu_identifier_attr =
>> +??? __ATTR(identifier, 0444, hisi_pcie_identifier_show, NULL);
>> +
>> +static struct attribute *hisi_pcie_pmu_identifier_attrs[] = {
>> +??? &hisi_pcie_pmu_identifier_attr.attr,
>> +??? NULL
>> +};
>> +
>> +static struct attribute_group hisi_pcie_pmu_identifier_attr_group = {
>> +??? .attrs = hisi_pcie_pmu_identifier_attrs,
>> +};
>> +
>> +static const struct attribute_group *hisi_pcie_pmu_attr_groups[] = {
>> +??? &hisi_pcie_pmu_events_group,
>> +??? &hisi_pcie_pmu_format_group,
>> +??? &hisi_pcie_pmu_bus_attr_group,
>> +??? &hisi_pcie_pmu_cpumask_attr_group,
>> +??? &hisi_pcie_pmu_identifier_attr_group,
>> +??? NULL
>> +};
>> +
>> +static int hisi_pcie_alloc_pmu(struct pci_dev *pdev,
>> +???????????????? struct hisi_pcie_pmu *pcie_pmu)
>> +{
>> +??? u16 sicl_id, device_id;
>> +??? char *name;
>> +
>> +??? pcie_pmu->base = pci_ioremap_bar(pdev, 2);
>> +??? if (!pcie_pmu->base) {
>> +??????? pci_err(pdev, "Ioremap failed for pcie_pmu resource.\n");
>> +??????? return -ENOMEM;
>> +??? }
> 
> nit: this does not seem related to "alloc" functionality
> 
ok, I'll move this pcie_pmu->base to hisi_pcie_init_pmu() function.

Thanks,
Qi
>> +
>> +??? hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_BDF,
>> +????????????????? &pcie_pmu->bdf_min, &pcie_pmu->bdf_max);
>> +??? hisi_pcie_parse_reg_value(pcie_pmu, HISI_PCIE_REG_INFO, &device_id,
>> +????????????????? &sicl_id);
>> +??? name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +????????????????? "hisi_pcie%u_%u", sicl_id, device_id);
>> +??? if (!name)
>> +??????? return -ENOMEM;
>> +
>> +??? pcie_pmu->pdev = pdev;
>> +??? pcie_pmu->on_cpu = -1;
>> +??? pcie_pmu->identifier = readl(pcie_pmu->base + 
>> HISI_PCIE_REG_VERSION);
>> +??? pcie_pmu->pmu = (struct pmu) {
>> +??????? .name??????? = name,
>> +??????? .module??????? = THIS_MODULE,
>> +??????? .event_init??? = hisi_pcie_pmu_event_init,
>> +??????? .pmu_enable??? = hisi_pcie_pmu_enable,
>> +??????? .pmu_disable??? = hisi_pcie_pmu_disable,
>> +??????? .add??????? = hisi_pcie_pmu_add,
>> +??????? .del??????? = hisi_pcie_pmu_del,
>> +??????? .start??????? = hisi_pcie_pmu_start,
>> +??????? .stop??????? = hisi_pcie_pmu_stop,
>> +??????? .read??????? = hisi_pcie_pmu_read,
>> +??????? .task_ctx_nr??? = perf_invalid_context,
>> +??????? .attr_groups??? = hisi_pcie_pmu_attr_groups,
>> +??????? .capabilities??? = PERF_PMU_CAP_NO_EXCLUDE,
>> +??? };
>> +
>> +??? return 0;
>> +}
>> +
> 
> .



From qperret at google.com  Wed Apr 21 09:31:00 2021
From: qperret at google.com (Quentin Perret)
Date: Wed, 21 Apr 2021 08:31:00 +0000
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
Message-ID: <YH/ixPnHMxNo08mJ@google.com>

On Tuesday 20 Apr 2021 at 09:33:56 (-0700), Florian Fainelli wrote:
> I do wonder as well, we have a 32MB "no-map" reserved memory region on
> our platforms located at 0xfe000000. Without the offending commit,
> /proc/iomem looks like this:
> 
> 40000000-fdffefff : System RAM
>   40008000-40ffffff : Kernel code
>   41e00000-41ef1d77 : Kernel data
> 100000000-13fffffff : System RAM
> 
> and with the patch applied, we have this:
> 
> 40000000-fdffefff : System RAM
>   40008000-40ffffff : Kernel code
>   41e00000-41ef3db7 : Kernel data
> fdfff000-ffffffff : System RAM
> 100000000-13fffffff : System RAM
> 
> so we can now see that the region 0xfe000000 - 0xfffffff is also cobbled
> up with the preceding region which is a mailbox between Linux and the
> secure monitor at 0xfdfff000 and of size 4KB. It seems like there is
> 
> The memblock=debug outputs is also different:
> 
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0xfdfff000 reserved size = 0x7ce4d20d
> [    0.000000]  memory.cnt  = 0x2
> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
> 0xbdfff000 bytes flags: 0x0
> [    0.000000]  memory[0x1]     [0x00000100000000-0x0000013fffffff],
> 0x40000000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0x6
> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
> 0xb495 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef1d77],
> 0x1cf1d78 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
> 0x100000 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
> 0x50000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x000000c2c00000-0x000000fdbfffff],
> 0x3b000000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
> 0x40000000 bytes flags: 0x0
> 
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0x100000000 reserved size = 0x7ca4f24d
> [    0.000000]  memory.cnt  = 0x3
> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
> 0xbdfff000 bytes flags: 0x0
> [    0.000000]  memory[0x1]     [0x000000fdfff000-0x000000ffffffff],
> 0x2001000 bytes flags: 0x4
> [    0.000000]  memory[0x2]     [0x00000100000000-0x0000013fffffff],
> 0x40000000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0x6
> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
> 0xb495 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef3db7],
> 0x1cf3db8 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
> 0x100000 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
> 0x50000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x000000c3000000-0x000000fdbfffff],
> 0x3ac00000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
> 0x40000000 bytes flags: 0x0
> 
> in the second case we can clearly see that the 32MB no-map region is now
> considered as usable RAM.
> 
> Hope this helps.
> 
> > 
> > In any case, the mere fact that this causes a regression should be
> > sufficient justification to revert/withdraw it from v5.4, as I don't
> > see a reason why it was merged there in the first place. (It has no
> > fixes tag or cc:stable)
> 
> Agreed, however that means we still need to find out whether a more
> recent kernel is also broken, I should be able to tell you that a little
> later.

FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
no-map region at 0x80000000, I have the following:

40000000-7fffffff : System RAM
  40210000-417fffff : Kernel code
  41800000-41daffff : reserved
  41db0000-4210ffff : Kernel data
  48000000-48008fff : reserved
80000000-800fffff : reserved
80100000-13fffffff : System RAM
  fa000000-ffffffff : reserved
  13b000000-13f5fffff : reserved
  13f6de000-13f77dfff : reserved
  13f77e000-13f77efff : reserved
  13f77f000-13f7dafff : reserved
  13f7dd000-13f7defff : reserved
  13f7df000-13f7dffff : reserved
  13f7e0000-13f7f3fff : reserved
  13f7f4000-13f7fdfff : reserved
  13f7fe000-13fffffff : reserved

If I remove the 'no-map' qualifier from DT, I get this:

40000000-13fffffff : System RAM
  40210000-417fffff : Kernel code
  41800000-41daffff : reserved
  41db0000-4210ffff : Kernel data
  48000000-48008fff : reserved
  80000000-800fffff : reserved
  fa000000-ffffffff : reserved
  13b000000-13f5fffff : reserved
  13f6de000-13f77dfff : reserved
  13f77e000-13f77efff : reserved
  13f77f000-13f7dafff : reserved
  13f7dd000-13f7defff : reserved
  13f7df000-13f7dffff : reserved
  13f7e0000-13f7f3fff : reserved
  13f7f4000-13f7fdfff : reserved
  13f7fe000-13fffffff : reserved

So this does seem to be working fine on my setup. I'll try again with
5.4 to see if I can repro.

Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
reserved regions") looks more likely to cause the issue observed here,
but that shouldn't be silent. I get the following error message in dmesg
if I if place the no-map region on top of the kernel image:

OF: fdt: Reserved memory: failed to reserve memory for node 'foobar at 40210000': base 0x0000000040210000, size 1 MiB

Is that triggering on your end?

Thanks,
Quentin


From David.Laight at ACULAB.COM  Wed Apr 21 09:31:32 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 21 Apr 2021 08:31:32 +0000
Subject: [PATCH] arm64: Show three registers per line
In-Reply-To: <20210420172245.3679077-1-willy@infradead.org>
References: <20210420172245.3679077-1-willy@infradead.org>
Message-ID: <c3ef59f1c06b42ecaa05a84beb7321b3@AcuMS.aculab.com>

From: Matthew Wilcox
> Sent: 20 April 2021 18:23
>
> Displaying two registers per line takes 15 lines.  That improves to just
> 10 lines if we display three registers per line, which reduces the amount
> of information lost when oopses are cut off.  It stays within 80 columns
> and matches x86-64.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>  arch/arm64/kernel/process.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 6e60aa3b5ea9..aff5a2c12297 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -294,13 +294,10 @@ void __show_regs(struct pt_regs *regs)
>  	i = top_reg;
> 
>  	while (i >= 0) {
> -		printk("x%-2d: %016llx ", i, regs->regs[i]);
> -		i--;
> +		printk("x%-2d: %016llx", i, regs->regs[i]);
> 
> -		if (i % 2 == 0) {
> -			pr_cont("x%-2d: %016llx ", i, regs->regs[i]);
> -			i--;
> -		}
> +		while (i-- % 3)
> +			pr_cont(" x%-2d: %016llx", i, regs->regs[i]);
> 
>  		pr_cont("\n");
>  	}

I think I'd avoid pr_cont() to avoid 'mishaps' during concurrent oops.
This probably needs something like:
	for (; i >= 0; i -= 3) {
		switch (i) {
		case 0:
			printk("x%-2d: %016llx\n", i, regs->regs[i]);
			break;
		case 1:
			printk("x%-2d: %016llx x%-2d: %016llx\n",
			       i, regs->regs[i], i - 1, regs->regs[i - 1]);
			break;
		default:
			printk("x%-2d: %016llx x%-2d: %016llx x%-2d: %016llx\n",
			       i, regs->regs[i], i - 1, regs->regs[i - 1],
				 i - 2, regs->regs[i - 2]);
			continue;
		}
		break;
	}

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From tan.shaopeng at fujitsu.com  Wed Apr 21 09:37:10 2021
From: tan.shaopeng at fujitsu.com (tan.shaopeng at fujitsu.com)
Date: Wed, 21 Apr 2021 08:37:10 +0000
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
Message-ID: <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>

Hi,

Ping... any comments&advice about add an A64FX cache control function into resctrl?

Best regards
Tan Shaopeng

> Hello
> 
> 
> I'm Tan Shaopeng from Fujitsu Limited.
> 
> I?m trying to implement Fujitsu A64FX?s cache related features.
> It is a cache partitioning function we called sector cache function that using
> the value of the tag that is upper 8 bits of the 64bit address and the value of the
> sector cache register to control virtual cache capacity of the L1D&L2 cache.
> 
> A few days ago, when I sent a driver that realizes this function to
> ARM64 kernel community, Will Deacon and Arnd Bergmann suggested an idea
> to add the sector cache function of A64FX into resctrl.
> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5Oc
> Z=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/
> 
> Based on my study, I think the sector cache function of A64FX can be added
> into the allocation features of resctrl after James' resctrl rework has finished.
> But, in order to implement this function, more interfaces for resctrl are need.
> The details are as follow, and could you give me some advice?
> 
> [Sector cache function]
> The sector cache function split cache into multiple sectors and control them
> separately. It is implemented on the L1D cache and
> L2 cache in the A64FX processor and can be controlled individually for L1D
> cache and L2 cache. A64FX has no L3 cache. Each L1D cache and L2 cache
> has 4 sectors. Which L1D sector is used is specified by the value of [57:56] bits
> of address, how many ways of sector are specified by the value of register
> (IMP_SCCR_L1_EL0).
> Which L2 sector is used is specified by the value of [56] bits of address, and
> how many ways of sector are specified by value of register
> (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
> IMP_SCCR_SET1_L2_EL1).
> 
> For more details of sector cache function, see A64FX HPC extension
> specification (1.2. Sector cache) in https://github.com/fujitsu/A64FX
> 
> [Difference between resctrl(CAT) and this sector cache function]
> L2/L3 CAT (Cache Allocation Technology) enables the user to specify some
> physical partition of cache space that an application can fill.
> A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function enables
> a user to specify number of ways each sector uses.
> Therefore, for CAT it is enough to specify a cache portion for each cache_id
> (socket). On the other hand, sector cache needs to specify cache portion of
> each sector for each cache_id, and following extension to resctrl interface is
> needed to support sector cache.
> 
> [Idear for A64FX sector cache function control interface (schemata file
> details)]
> L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cw
> bm>,<cwbm>,<cwbm>,<cwbm>;?
> L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=
> <cwbm>,<cwbm>,<cwbm>,<cwbm>;?
> 
> ?L1: Add a new interface to control the L1D cache.
> ?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for each
> sector.
> ?cwbm?Specify the number of ways in each sector as a bitmap (percentage),
>   but the bitmap does not indicate the location of the cache.
> * In the sector cache function, L2 sector cache way setting register is
>   shared among PEs (Processor Element) in shared domain. If two PEs
>   which share L2 cache belongs to different resource groups, one resource
>   group's L2 setting will affect to other resource group's L2 setting.
> * Since A64FX does not support MPAM, it is not necessary to consider
>   how to switch between MPAM and sector cache function now.
> 
> Some questions:
> 1.I'm still studying about RDT, could you tell me whether RDT has
>   the similar mechanism with sector cache function?
> 2.In RDT, L3 cache is shared among cores in socket. If two cores which
>   share L3 cache belongs to different resource groups, one resource
>   group's L3 setting will affect to other resource group's L3 setting?
> 3.Is this approach acceptable? could you give me some advice?
> 
> 
> Best regards
> Tan Shaopeng



From boon.leong.ong at intel.com  Wed Apr 21 09:46:06 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Wed, 21 Apr 2021 16:46:06 +0800
Subject: [PATCH net-next 1/1] stmmac: intel: set TSO/TBS TX Queues default
 settings
Message-ID: <20210421084606.20851-1-boon.leong.ong@intel.com>

TSO and TBS cannot coexist, for now we set Intel mGbE controller to use
below TX Queue mapping: TxQ0 uses TSO and the rest of TXQs supports TBS.

Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index ec140fc4a0f5..844332a2c2e0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -446,6 +446,9 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 
 		/* Disable Priority config by default */
 		plat->tx_queues_cfg[i].use_prio = false;
+		/* Default TX Q0 to use TSO and rest TXQ for TBS */
+		if (i > 0)
+			plat->tx_queues_cfg[i].tbs_en = 1;
 	}
 
 	/* FIFO size is 4096 bytes for 1 tx/rx queue */
-- 
2.25.1



From David.Laight at ACULAB.COM  Wed Apr 21 09:43:01 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 21 Apr 2021 08:43:01 +0000
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
 <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
 <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>
 <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
Message-ID: <5c41d562589b497ca3c1047e0e18b3a1@AcuMS.aculab.com>

From: Arnd Bergmann
> Sent: 20 April 2021 22:20
> 
> On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta
> <Vineet.Gupta1 at synopsys.com> wrote:
> > On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> 
> > >
> > > which means that half the 32-bit architectures do this. This may
> > > cause more problems when arc and/or microblaze want to support
> > > 64-bit kernels and compat mode in the future on their latest hardware,
> > > as that means duplicating the x86 specific hacks we have for compat.
> > >
> > > What is alignof(u64) on 64-bit arc?
> >
> > $ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc -
> > -Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
> > 8
> 
> Ok, good.

That test doesn't prove anything.
Try running on x86:
$ echo 'int a = __alignof__(long long);' | gcc -xc - -Wall -S -o - -m32
        .file   ""
        .globl  a
        .data
        .align 4
        .type   a, @object
        .size   a, 4
a:
        .long   8
        .ident  "GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609"
        .section        .note.GNU-stack,"", at progbits

Using '__alignof__(struct {long long x;})' does give the expected 4.

__alignof__() returns the preferred alignment, not the enforced
alignmnet - go figure.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From qperret at google.com  Wed Apr 21 09:45:42 2021
From: qperret at google.com (Quentin Perret)
Date: Wed, 21 Apr 2021 08:45:42 +0000
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <YH/ixPnHMxNo08mJ@google.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
 <YH/ixPnHMxNo08mJ@google.com>
Message-ID: <YH/mNosARuC1KiuY@google.com>

On Wednesday 21 Apr 2021 at 08:31:00 (+0000), Quentin Perret wrote:
> FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
> no-map region at 0x80000000, I have the following:
> 
> 40000000-7fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
> 80000000-800fffff : reserved
> 80100000-13fffffff : System RAM
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> If I remove the 'no-map' qualifier from DT, I get this:
> 
> 40000000-13fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
>   80000000-800fffff : reserved
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> So this does seem to be working fine on my setup. I'll try again with
> 5.4 to see if I can repro.

I just ran the same experiment on v5.4.102 which is where the
regression was reported, and I'm seeing the same correct result...

> Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
> reserved regions") looks more likely to cause the issue observed here,
> but that shouldn't be silent. I get the following error message in dmesg
> if I if place the no-map region on top of the kernel image:
> 
> OF: fdt: Reserved memory: failed to reserve memory for node 'foobar at 40210000': base 0x0000000040210000, size 1 MiB
> 
> Is that triggering on your end?

So that really sounds like the cause of the issue here, though arguably
this should be indicative a something funny in the DT.

Thanks,
Quentin


From arnd at kernel.org  Wed Apr 21 09:58:18 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 10:58:18 +0200
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
In-Reply-To: <5c41d562589b497ca3c1047e0e18b3a1@AcuMS.aculab.com>
References: <20210416230724.2519198-1-willy@infradead.org>
 <20210416230724.2519198-2-willy@infradead.org>
 <20210417024522.GP2531743@casper.infradead.org>
 <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com>
 <20210420031029.GI2531743@casper.infradead.org>
 <CAK8P3a0KUwf1Z0bHiUaHC2nHztevkxg5_FBSzHddNeSsBayWUA@mail.gmail.com>
 <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com>
 <CAK8P3a3rzz1gfNLoGC8aZJiAC-tgZYD6P8pQsoEfgCAmQK=FAw@mail.gmail.com>
 <5c41d562589b497ca3c1047e0e18b3a1@AcuMS.aculab.com>
Message-ID: <CAK8P3a2GN9HVwSjfsXaYVO29zeUNB1hQENRw1K0DXCLdt-M-qA@mail.gmail.com>

On Wed, Apr 21, 2021 at 10:43 AM David Laight <David.Laight at aculab.com> wrote:
> From: Arnd Bergmann Sent: 20 April 2021 22:20
> > On Tue, Apr 20, 2021 at 11:14 PM Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
> > > On 4/20/21 12:07 AM, Arnd Bergmann wrote:
> >
> > > >
> > > > which means that half the 32-bit architectures do this. This may
> > > > cause more problems when arc and/or microblaze want to support
> > > > 64-bit kernels and compat mode in the future on their latest hardware,
> > > > as that means duplicating the x86 specific hacks we have for compat.
> > > >
> > > > What is alignof(u64) on 64-bit arc?
> > >
> > > $ echo 'int a = __alignof__(long long);' | arc64-linux-gnu-gcc -xc -
> > > -Wall -S -o - | grep -A1 a: | tail -n 1 | cut -f 3
> > > 8
> >
> > Ok, good.
>
> That test doesn't prove anything.
> Try running on x86:
> $ echo 'int a = __alignof__(long long);' | gcc -xc - -Wall -S -o - -m32
> a:
>         .long   8

Right, I had wondered about that one after I sent the email.

> Using '__alignof__(struct {long long x;})' does give the expected 4.
>
> __alignof__() returns the preferred alignment, not the enforced
> alignmnet - go figure.

I checked the others as well now, and i386 is the only one that
changed here: m68k still has '2', while arc/csky/h8300/microblaze/
nios2/or1k/sh/i386 all have '4' and the rest have '8'.

     Arnd


From zajec5 at gmail.com  Wed Apr 21 10:00:06 2021
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Wed, 21 Apr 2021 11:00:06 +0200
Subject: [PATCH] ARM: dts: BCM5301X: Fix pinmux subnodes names
Message-ID: <20210421090006.28228-1-zajec5@gmail.com>

From: Rafa? Mi?ecki <rafal at milecki.pl>

This matches pinmux-node.yaml requirements.

Signed-off-by: Rafa? Mi?ecki <rafal at milecki.pl>
---
 arch/arm/boot/dts/bcm47094.dtsi | 2 +-
 arch/arm/boot/dts/bcm5301x.dtsi | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index 2a8f7312d1be..6282363313e1 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -11,7 +11,7 @@ / {
 &pinctrl {
 	compatible = "brcm,bcm4709-pinmux";
 
-	pinmux_mdio: mdio {
+	pinmux_mdio: mdio-pins {
 		groups = "mdio_grp";
 		function = "mdio";
 	};
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 092ec525c01c..5b9723a10bd6 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -458,18 +458,18 @@ spi-pins {
 					function = "spi";
 				};
 
-				pinmux_i2c: i2c {
+				pinmux_i2c: i2c-pins {
 					groups = "i2c_grp";
 					function = "i2c";
 				};
 
-				pinmux_pwm: pwm {
+				pinmux_pwm: pwm-pins {
 					groups = "pwm0_grp", "pwm1_grp",
 						 "pwm2_grp", "pwm3_grp";
 					function = "pwm";
 				};
 
-				pinmux_uart1: uart1 {
+				pinmux_uart1: uart1-pins {
 					groups = "uart1_grp";
 					function = "uart1";
 				};
-- 
2.26.2



From hsinyi at chromium.org  Wed Apr 21 10:05:54 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:54 +0800
Subject: [PATCH v3 03/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-burnet
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-4-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 96c401597bd8..0870490aa350 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -122,6 +122,10 @@ properties:
           - enum:
               - 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:
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:51 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:51 +0800
Subject: [PATCH v3 00/10] Add several jacuzzi boards
Message-ID: <20210421090601.730744-1-hsinyi@chromium.org>

Add several jacuzzi follower devices: kappa, willo, burnet, kenzo, and
fennel.

Change log:
v2 -> v3:
 - remove unused property in i2c2 in willow and burnet.
 - add fennel.

Hsin-Yi Wang (10):
  dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kappa
  dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-willow
  dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-burnet
  dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kenzo
  dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-fennel
  arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
  arm64: dts: mt8183: Add kukui-jacuzzi-willow board
  arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
  arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
  arm64: dts: mt8183: Add kukui-jacuzzi-fennel board

 .../devicetree/bindings/arm/mediatek.yaml     | 29 +++++++++++-
 arch/arm64/boot/dts/mediatek/Makefile         |  8 ++++
 .../mediatek/mt8183-kukui-jacuzzi-burnet.dts  | 30 +++++++++++++
 .../mt8183-kukui-jacuzzi-fennel-sku1.dts      | 44 +++++++++++++++++++
 .../mt8183-kukui-jacuzzi-fennel-sku6.dts      | 32 ++++++++++++++
 .../mediatek/mt8183-kukui-jacuzzi-fennel.dtsi | 27 ++++++++++++
 .../mt8183-kukui-jacuzzi-fennel14.dts         | 16 +++++++
 .../mediatek/mt8183-kukui-jacuzzi-kappa.dts   | 16 +++++++
 .../mediatek/mt8183-kukui-jacuzzi-kenzo.dts   | 12 +++++
 .../mt8183-kukui-jacuzzi-willow-sku0.dts      | 13 ++++++
 .../mt8183-kukui-jacuzzi-willow-sku1.dts      | 12 +++++
 .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 26 +++++++++++
 .../dts/mediatek/mt8183-kukui-jacuzzi.dtsi    |  8 ++++
 13 files changed, 271 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi

-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:57 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:57 +0800
Subject: [PATCH v3 06/10] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-7-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile            |  1 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts  | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index a1c50adc98fa..df70674949ce 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
new file mode 100644
index 000000000000..b3f46c16e5d7
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google kappa board";
+	compatible = "google,kappa", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:52 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:52 +0800
Subject: [PATCH v3 01/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kappa
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-2-hsinyi@chromium.org>

Kappa is known as HP Chromebook 11a.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index aff57a8c8c30..81b86b189a8d 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -144,6 +144,10 @@ properties:
           - const: google,kakadu-rev2
           - const: google,kakadu
           - const: mediatek,mt8183
+      - description: Google Kappa (HP Chromebook 11a)
+        items:
+          - const: google,kappa
+          - const: mediatek,mt8183
       - description: Google Kodama (Lenovo 10e Chromebook Tablet)
         items:
           - enum:
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:55 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:55 +0800
Subject: [PATCH v3 04/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-kenzo
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-5-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 0870490aa350..7afd01aad964 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -137,9 +137,11 @@ properties:
         items:
           - const: google,damu
           - const: mediatek,mt8183
-      - description: Google Juniper (Acer Chromebook Spin 311)
+      - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311)
         items:
-          - const: google,juniper-sku16
+          - enum:
+              - google,juniper-sku16
+              - google,juniper-sku17
           - const: google,juniper
           - const: mediatek,mt8183
       - description: Google Kakadu (ASUS Chromebook Detachable CM3)
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:53 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:53 +0800
Subject: [PATCH v3 02/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-willow
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-3-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T).

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 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 81b86b189a8d..96c401597bd8 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -157,6 +157,13 @@ properties:
               - google,kodama-sku32
           - const: google,kodama
           - const: mediatek,mt8183
+      - description: Google Willow (Acer Chromebook 311 C722/C722T)
+        items:
+          - enum:
+              - google,willow-sku0
+              - google,willow-sku1
+          - const: google,willow
+          - const: mediatek,mt8183
       - items:
           - enum:
               - mediatek,mt8183-pumpkin
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:58 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:58 +0800
Subject: [PATCH v3 07/10] arm64: dts: mt8183: Add kukui-jacuzzi-willow board
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-8-hsinyi@chromium.org>

Willow is known as Acer Chromebook 311 (C722/C722T)

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  2 ++
 .../mt8183-kukui-jacuzzi-willow-sku0.dts      | 13 ++++++++++
 .../mt8183-kukui-jacuzzi-willow-sku1.dts      | 12 +++++++++
 .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 26 +++++++++++++++++++
 4 files changed, 53 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index df70674949ce..5f43bbc2ea72 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -16,6 +16,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
new file mode 100644
index 000000000000..281265f082db
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku0";
+	compatible = "google,willow-sku0", "google,willow", "mediatek,mt8183";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
new file mode 100644
index 000000000000..22e56bdc1ee3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-willow.dtsi"
+
+/ {
+	model = "Google willow board sku1";
+	compatible = "google,willow-sku1", "google,willow", "mediatek,mt8183";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
new file mode 100644
index 000000000000..76d33540166f
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+&i2c2 {
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_pins>;
+
+		interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
+
+		wakeup-source;
+	};
+};
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_JUNIPER";
+};
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:59 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:59 +0800
Subject: [PATCH v3 08/10] arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-9-hsinyi@chromium.org>

Burnet is known as HP Chromebook x360 11MK G3 EE

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  1 +
 .../mediatek/mt8183-kukui-jacuzzi-burnet.dts  | 30 +++++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 5f43bbc2ea72..b33d0bc58021 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
new file mode 100644
index 000000000000..a8d6f32ade8d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+/ {
+	model = "Google burnet board";
+	compatible = "google,burnet", "mediatek,mt8183";
+};
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
+
+&i2c0 {
+	touchscreen at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touchscreen_pins>;
+		interrupts-extended = <&pio 155 IRQ_TYPE_LEVEL_LOW>;
+
+		post-power-on-delay-ms = <200>;
+		hid-descr-addr = <0x0020>;
+	};
+};
+
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:05:56 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:05:56 +0800
Subject: [PATCH v3 05/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-fennel
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-6-hsinyi@chromium.org>

Fennel is known as Lenovo IdeaPad Flex 3 Chromebook.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 Documentation/devicetree/bindings/arm/mediatek.yaml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 7afd01aad964..80a05f6fee85 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -137,6 +137,14 @@ properties:
         items:
           - const: google,damu
           - const: mediatek,mt8183
+      - description: Google Fennel (Lenovo IdeaPad 3 Chromebook)
+        items:
+          - enum:
+              - google,fennel-sku0
+              - google,fennel-sku1
+              - google,fennel-sku6
+          - const: google,fennel
+          - const: mediatek,mt8183
       - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311)
         items:
           - enum:
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:06:00 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:06:00 +0800
Subject: [PATCH v3 09/10] arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-10-hsinyi@chromium.org>

Kenzo is known as Acer Chromebook 311.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---
 arch/arm64/boot/dts/mediatek/Makefile                |  1 +
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12 ++++++++++++
 2 files changed, 13 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index b33d0bc58021..25770d83059d 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
new file mode 100644
index 000000000000..6f1aa692753a
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-juniper.dtsi"
+
+/ {
+	model = "Google kenzo sku17 board";
+	compatible = "google,juniper-sku17", "google,juniper", "mediatek,mt8183";
+};
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 21 10:06:01 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 21 Apr 2021 17:06:01 +0800
Subject: [PATCH v3 10/10] arm64: dts: mt8183: Add kukui-jacuzzi-fennel board
In-Reply-To: <20210421090601.730744-1-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
Message-ID: <20210421090601.730744-11-hsinyi@chromium.org>

Fennel is known as Lenovo IdeaPad Flex 3 Chromebook.
Fennel14 is known as Lenovo IdeaPad 3 Chromebook.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/Makefile         |  3 ++
 .../mt8183-kukui-jacuzzi-fennel-sku1.dts      | 44 +++++++++++++++++++
 .../mt8183-kukui-jacuzzi-fennel-sku6.dts      | 32 ++++++++++++++
 .../mediatek/mt8183-kukui-jacuzzi-fennel.dtsi | 27 ++++++++++++
 .../mt8183-kukui-jacuzzi-fennel14.dts         | 16 +++++++
 .../dts/mediatek/mt8183-kukui-jacuzzi.dtsi    |  8 ++++
 6 files changed, 130 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 25770d83059d..4f68ebed2e31 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -15,6 +15,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-fennel-sku1.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-fennel-sku6.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-fennel14.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts
new file mode 100644
index 000000000000..ef6257c9a2d2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku1.dts
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-fennel.dtsi"
+
+/ {
+	model = "Google fennel sku1 board";
+	compatible = "google,fennel-sku1", "google,fennel", "mediatek,mt8183";
+
+	pwmleds {
+		compatible = "pwm-leds";
+		keyboard_backlight: keyboard-backlight {
+			label = "cros_ec::kbd_backlight";
+			pwms = <&cros_ec_pwm 0>;
+			max-brightness = <1023>;
+		};
+	};
+};
+
+&cros_ec_pwm {
+	status = "okay";
+};
+
+&touchscreen {
+	status = "okay";
+
+	compatible = "hid-over-i2c";
+	reg = <0x10>;
+	interrupt-parent = <&pio>;
+	interrupts = <155 IRQ_TYPE_LEVEL_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&touchscreen_pins>;
+
+	post-power-on-delay-ms = <10>;
+	hid-descr-addr = <0x0001>;
+};
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_FENNEL";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts
new file mode 100644
index 000000000000..899c2e42385c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel-sku6.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-fennel.dtsi"
+
+/ {
+	model = "Google fennel sku6 board";
+	compatible = "google,fennel-sku6", "google,fennel", "mediatek,mt8183";
+};
+
+&touchscreen {
+	status = "okay";
+
+	compatible = "hid-over-i2c";
+	reg = <0x10>;
+	interrupt-parent = <&pio>;
+	interrupts = <155 IRQ_TYPE_LEVEL_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&touchscreen_pins>;
+
+	post-power-on-delay-ms = <10>;
+	hid-descr-addr = <0x0001>;
+};
+
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_FENNEL";
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel.dtsi
new file mode 100644
index 000000000000..bbe6c338f465
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi.dtsi"
+
+&mt6358codec {
+	mediatek,dmic-mode = <1>; /* one-wire */
+};
+
+&i2c2 {
+	trackpad at 2c {
+		compatible = "hid-over-i2c";
+		reg = <0x2c>;
+		hid-descr-addr = <0x20>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_pins>;
+
+		interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
+
+		wakeup-source;
+	};
+};
+
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dts b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dts
new file mode 100644
index 000000000000..e8c41f6b4b0d
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-fennel14.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+#include "mt8183-kukui-jacuzzi-fennel.dtsi"
+
+/ {
+	model = "Google fennel14 sku0 board";
+	compatible = "google,fennel-sku0", "google,fennel", "mediatek,mt8183";
+};
+
+&qca_wifi {
+	qcom,ath10k-calibration-variant = "GO_FENNEL14";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
index 4049dff8464b..d8826c82bcda 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
@@ -92,6 +92,14 @@ volume_up {
 	};
 };
 
+&cros_ec {
+	cros_ec_pwm: ec-pwm {
+		compatible = "google,cros-ec-pwm";
+		#pwm-cells = <1>;
+		status = "disabled";
+	};
+};
+
 &dsi0 {
 	status = "okay";
 	/delete-node/panel at 0;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From boon.leong.ong at intel.com  Wed Apr 21 10:11:49 2021
From: boon.leong.ong at intel.com (Ong Boon Leong)
Date: Wed, 21 Apr 2021 17:11:49 +0800
Subject: [PATCH net 1/1] net: stmmac: fix TSO and TBS feature enabling during
 driver open
Message-ID: <20210421091149.5035-1-boon.leong.ong@intel.com>

TSO and TBS cannot co-exist and current implementation requires two
fixes:

 1) stmmac_open() does not need to call stmmac_enable_tbs() because
    the MAC is reset in stmmac_init_dma_engine() anyway.
 2) Inside stmmac_hw_setup(), we should call stmmac_enable_tso() for
    TX Q that is _not_ configured for TBS.

Fixes: 579a25a854d4 ("net: stmmac: Initial support for TBS")
Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4749bd0af160..c6f24abf6432 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2757,8 +2757,15 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
 
 	/* Enable TSO */
 	if (priv->tso) {
-		for (chan = 0; chan < tx_cnt; chan++)
+		for (chan = 0; chan < tx_cnt; chan++) {
+			struct stmmac_tx_queue *tx_q = &priv->tx_queue[chan];
+
+			/* TSO and TBS cannot co-exist */
+			if (tx_q->tbs & STMMAC_TBS_AVAIL)
+				continue;
+
 			stmmac_enable_tso(priv, priv->ioaddr, 1, chan);
+		}
 	}
 
 	/* Enable Split Header */
@@ -2850,9 +2857,8 @@ static int stmmac_open(struct net_device *dev)
 		struct stmmac_tx_queue *tx_q = &priv->tx_queue[chan];
 		int tbs_en = priv->plat->tx_queues_cfg[chan].tbs_en;
 
+		/* Setup per-TXQ tbs flag before TX descriptor alloc */
 		tx_q->tbs |= tbs_en ? STMMAC_TBS_AVAIL : 0;
-		if (stmmac_enable_tbs(priv, priv->ioaddr, tbs_en, chan))
-			tx_q->tbs &= ~STMMAC_TBS_AVAIL;
 	}
 
 	ret = alloc_dma_desc_resources(priv);
-- 
2.25.1



From dafna.hirschfeld at collabora.com  Wed Apr 21 10:09:01 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Wed, 21 Apr 2021 11:09:01 +0200
Subject: [PATCH v2] media: rkisp1: rkisp1-params.c: Fix typos
In-Reply-To: <20210420174522.9618-1-sebastian.fricke@posteo.net>
References: <20210420174522.9618-1-sebastian.fricke@posteo.net>
Message-ID: <a0c52c66-6930-7ace-e1ac-9608a7e72bfa@collabora.com>

Hi,
Thanks for the fix,

On 20.04.21 19:45, Sebastian Fricke wrote:
> s/when the camera active/when the camera is active/
> s/thus not isr protection/therefore there is no need to acquire a lock/
> 
> Signed-off-by: Sebastian Fricke <sebastian.fricke at posteo.net>

Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld at collabora.com>

> ---
>   drivers/media/platform/rockchip/rkisp1/rkisp1-params.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> index b6beddd988d0..529c6e21815f 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> @@ -1258,7 +1258,10 @@ void rkisp1_params_configure(struct rkisp1_params *params,
>   	rkisp1_params_config_parameter(params);
>   }
>   
> -/* Not called when the camera active, thus not isr protection. */
> +/*
> + * Not called when the camera is active, therefore there is no need to acquire
> + * a lock.
> + */
>   void rkisp1_params_disable(struct rkisp1_params *params)
>   {
>   	rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPCC_MODE,
> 


From jbx6244 at gmail.com  Wed Apr 21 10:11:21 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 21 Apr 2021 11:11:21 +0200
Subject: [PATCH v1 2/5] dt-bindings: serial: snps-dw-apb-uart: add
 description for rk3568
In-Reply-To: <20210421065921.23917-3-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-3-cl@rock-chips.com>
Message-ID: <b5e0b661-7dfd-1456-f8a9-0f23539fbae1@gmail.com>

On 4/21/21 8:59 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
> a rk3568 platform to snps-dw-apb-uart.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> index 87ef1e218152..9bbe4afc26a4 100644
> --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> @@ -30,6 +30,7 @@ properties:
>                - rockchip,rk3308-uart
>                - rockchip,rk3328-uart
>                - rockchip,rk3368-uart

> +              - rockchip,rk3568-uart

Sort this below rockchip,rk3399-uart

>                - rockchip,rk3399-uart
>                - rockchip,rv1108-uart
>            - const: snps,dw-apb-uart
> 



From heiko at sntech.de  Wed Apr 21 10:13:11 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Wed, 21 Apr 2021 11:13:11 +0200
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210421065921.23917-5-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com>
Message-ID: <11131098.F0gNSz5aLb@diego>

Hi Liang,

Am Mittwoch, 21. April 2021, 08:59:20 CEST schrieb cl at rock-chips.com:
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipments.
> 
> This patch add basic core dtsi file for it.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>

this is a first round of basic stuff :-) .

First of all, I really like the move of moving the pretty standardized
pinconfig entries to the rockchip-pinconf.dtsi .

(1) But please move this into a separate patch to make that more visible
and maybe even convert _some_ or all arm64 Rockchip socs to use that
as well

"arm64: dts: rockchip: add generic pinconfig settings used by most Rockchip socs

The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
so move them to a shared dtsi to be included, instead of redefining them
for each soc"

(2) I also like the external rk3568-pinctrl approach with the dtsi getting
auto-generated. This will probably help us in keeping pinctrl settings
synchronous between mainline and the vendor kernel.

(3) From my basic understanding the rk3568 is basically a rk3566 + more
peripherals, so ideally they would share the basic ones in a rk3566.dtsi
which the rk3568.dtsi then could include and extend with its additional
peripherals.

With at least the pine64 boards being based on the rk3566, there probably
will be quite a mainline use of it as well.

Or is there something that would prevent this?


More below:

> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 2789 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  795 +++++
>  .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  346 ++
>  3 files changed, 3930 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> new file mode 100644
> index 000000000000..92b315763dc0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> @@ -0,0 +1,2789 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include "rockchip-pinconf.dtsi"
> +
> +/*
> + * This file is auto generated by pin2dts tool, please keep these code
> + * by adding changes at end of this file.
> + */
> +&pinctrl {
> +	acodec {
> +		/omit-if-no-ref/
> +		acodec_pins: acodec-pins {
> +			rockchip,pins =
> +				/* acodec_adc_sync */
> +				<1 RK_PB1 5 &pcfg_pull_none>,
> +				/* acodec_adcclk */
> +				<1 RK_PA1 5 &pcfg_pull_none>,
> +				/* acodec_adcdata */
> +				<1 RK_PA0 5 &pcfg_pull_none>,
> +				/* acodec_dac_datal */
> +				<1 RK_PA7 5 &pcfg_pull_none>,
> +				/* acodec_dac_datar */
> +				<1 RK_PB0 5 &pcfg_pull_none>,
> +				/* acodec_dacclk */
> +				<1 RK_PA3 5 &pcfg_pull_none>,
> +				/* acodec_dacsync */
> +				<1 RK_PA5 5 &pcfg_pull_none>;
> +		};
> +	};

can you adapt your pin2dts tool to insert a blank line here please?

> +	audiopwm {
> +		/omit-if-no-ref/
> +		audiopwm_lout: audiopwm-lout {
> +			rockchip,pins =
> +				/* audiopwm_lout */
> +				<1 RK_PA0 4 &pcfg_pull_none>;
> +		};

same here and of course below.

I.e. in a list of subnodes it would be really nice if you could add a blank
line above every subnode - except the first of course ;-)

So,
+	audiopwm {
+		/omit-if-no-ref/
+		audiopwm_lout: audiopwm-lout {

does not get a blank line before audiopwm-lout, but between audiopwn-lout
and the next sub node.


> +		/omit-if-no-ref/
> +		audiopwm_loutn: audiopwm-loutn {
> +			rockchip,pins =
> +				/* audiopwm_loutn */
> +				<1 RK_PA1 6 &pcfg_pull_none>;
> +		};

[...]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..ac8db2f54f2b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,795 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <dt-bindings/clock/rk3568-cru.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,boot-mode.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {
> +	compatible = "rockchip,rk3568";
> +
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial2 = &uart2;
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x0>;
> +			enable-method = "psci";
> +			clocks = <&scmi_clk 0>;

what is <&scmi_clk 0>.

I see the rk3568 clk-driver defining our standard ARMCLK, so I'd ask for
an explanation (in the commit message maybe) what makes the scmi clk
different and especially what firmware-dependencies arise.

Also it would be very cool if Rockchip could upstream rk3568-support to
mainline TF-A, so that people don't need binary blobs for this.


> +			operating-points-v2 = <&cpu0_opp_table>;
> +			#cooling-cells = <2>;
> +		};

blank lines between nodes in the same hierarchy level

> +		cpu1: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x100>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +		cpu2: cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x200>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +		cpu3: cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x300>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +	};
> +
> +	cpu0_opp_table: cpu0-opp-table {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-408000000 {
> +			opp-hz = /bits/ 64 <408000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			clock-latency-ns = <40000>;
> +		};
> +		opp-600000000 {
> +			opp-hz = /bits/ 64 <600000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			opp-suspend;
> +		};
> +		opp-1104000000 {
> +			opp-hz = /bits/ 64 <1104000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-1416000000 {
> +			opp-hz = /bits/ 64 <1416000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +		opp-1608000000 {
> +			opp-hz = /bits/ 64 <1608000000>;
> +			opp-microvolt = <975000 975000 1150000>;
> +		};
> +		opp-1800000000 {
> +			opp-hz = /bits/ 64 <1800000000>;
> +			opp-microvolt = <1050000 1050000 1150000>;
> +		};
> +		opp-1992000000 {
> +			opp-hz = /bits/ 64 <1992000000>;
> +			opp-microvolt = <1150000 1150000 1150000>;
> +		};
> +	};
> +
> +	arm-pmu {
> +		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
> +		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> +	};
> +
> +	firmware {
> +		scmi: scmi {
> +			compatible = "arm,scmi-smc";
> +			shmem = <&scmi_shmem>;
> +			arm,smc-id = <0x82000010>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			scmi_clk: protocol at 14 {
> +				reg = <0x14>;
> +				#clock-cells = <1>;
> +			};
> +		};
> +
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +		arm,no-tick-in-suspend;
> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		#clock-cells = <0>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&clk32k_out0>;
> +	};
> +
> +	scmi_shmem: scmi-shmem at 10f000 {
> +		compatible = "arm,scmi-shmem";
> +		reg = <0x0 0x0010f000 0x0 0x100>;

are you sure this works in mainline?

I.e. looking at Documentation/devicetree/bindings/arm/arm,scmi.txt
it talks about arm,scmi-shmem being part of a defined sram area
while the node above seems to be in main memory?


> +	};
> +
> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";

reg + interrupts up here below compatible please (+rest alphabetically sorted)


> +		#interrupt-cells = <3>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		interrupt-controller;
> +
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +	};

> diff --git a/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
> new file mode 100644
> index 000000000000..0c292ef8a87a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +&pinctrl {

no blank line here please ;-)

The other blank lines below are correct though

And as said at the top, please move into a separate patch and
maybe convert some other Rockchip arm64 socs to it as well ;-) .


> +
> +	/omit-if-no-ref/
> +	pcfg_pull_up: pcfg-pull-up {
> +		bias-pull-up;
> +	};
> +
> +	/omit-if-no-ref/
> +	pcfg_pull_down: pcfg-pull-down {
> +		bias-pull-down;
> +	};
> +
> +	/omit-if-no-ref/
> +	pcfg_pull_none: pcfg-pull-none {
> +		bias-disable;
> +	};
> +


Thanks
Heiko




From heying24 at huawei.com  Wed Apr 21 10:13:40 2021
From: heying24 at huawei.com (He Ying)
Date: Wed, 21 Apr 2021 17:13:40 +0800
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
References: <20210416062217.25157-1-heying24@huawei.com>
 <87y2dis4d7.wl-maz@kernel.org>
 <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
Message-ID: <0bdfe2c8-1ebe-1f6c-3522-da821398d820@huawei.com>

Hello Marc,


Any ideas?


Thanks.


? 2021/4/17 10:01, He Ying ??:
> Hello Marc,
>
>
> ? 2021/4/16 22:15, Marc Zyngier ??:
>> [+ Mark]
>>
>> On Fri, 16 Apr 2021 07:22:17 +0100,
>> He Ying <heying24 at huawei.com> wrote:
>>> We found this problem in our kernel src tree:
>>>
>>> [?? 14.816231] ------------[ cut here ]------------
>>> [?? 14.816231] kernel BUG at irq.c:99!
>>> [?? 14.816232] Internal error: Oops - BUG: 0 [#1] SMP
>>> [?? 14.816232] Process swapper/0 (pid: 0, stack limit = 
>>> 0x(____ptrval____))
>>> [?? 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G?????????? 
>>> O????? 4.19.95-1.h1.AOS2.0.aarch64 #14
>>> [?? 14.816233] Hardware name: evb (DT)
>>> [?? 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
>>> [?? 14.816234] pc : asm_nmi_enter+0x94/0x98
>>> [?? 14.816235] lr : asm_nmi_enter+0x18/0x98
>>> [?? 14.816235] sp : ffff000008003c50
>>> [?? 14.816235] pmr_save: 00000070
>>> [?? 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
>>> [?? 14.816238] x27: 0000000000000000 x26: ffff000008004000
>>> [?? 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
>>> [?? 14.816240] x23: 0000000020400005 x22: ffff0000080817cc
>>> [?? 14.816241] x21: ffff000008003da0 x20: 0000000000000060
>>> [?? 14.816242] x19: 00000000000003ff x18: ffffffffffffffff
>>> [?? 14.816243] x17: 0000000000000008 x16: 003d090000000000
>>> [?? 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
>>> [?? 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
>>> [?? 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
>>> [?? 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
>>> [?? 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
>>> [?? 14.816248] x5 : 0000000000000000 x4 : 0000000080000000
>>> [?? 14.816249] x3 : 0000000000000000 x2 : 0000000080000000
>>> [?? 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
>>> [?? 14.816251] Call trace:
>>> [?? 14.816251]? asm_nmi_enter+0x94/0x98
>>> [?? 14.816251]? el1_irq+0x8c/0x180
>>> [?? 14.816252]? gic_handle_irq+0xbc/0x2e4
>>> [?? 14.816252]? el1_irq+0xcc/0x180
>>> [?? 14.816253]? arch_timer_handler_virt+0x38/0x58
>>> [?? 14.816253]? handle_percpu_devid_irq+0x90/0x240
>>> [?? 14.816253]? generic_handle_irq+0x34/0x50
>>> [?? 14.816254]? __handle_domain_irq+0x68/0xc0
>>> [?? 14.816254]? gic_handle_irq+0xf8/0x2e4
>>> [?? 14.816255]? el1_irq+0xcc/0x180
>>> [?? 14.816255]? arch_cpu_idle+0x34/0x1c8
>>> [?? 14.816255]? default_idle_call+0x24/0x44
>>> [?? 14.816256]? do_idle+0x1d0/0x2c8
>>> [?? 14.816256]? cpu_startup_entry+0x28/0x30
>>> [?? 14.816256]? rest_init+0xb8/0xc8
>>> [?? 14.816257]? start_kernel+0x4c8/0x4f4
>>> [?? 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
>>> [?? 14.816258] Modules linked in: start_dp(O) smeth(O)
>>> [?? 15.103092] ---[ end trace 701753956cb14aa8 ]---
>>> [?? 15.103093] Kernel panic - not syncing: Fatal exception in interrupt
>>> [?? 15.103099] SMP: stopping secondary CPUs
>>> [?? 15.103100] Kernel Offset: disabled
>>> [?? 15.103100] CPU features: 0x36,a2400218
>>> [?? 15.103100] Memory Limit: none
>> Urgh...
>>
>>> Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
>>> patches but doesn't support nested NMI. Its top relative commit is
>>> commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence 
>>> of NMIs").
>> Can you please reproduce it with mainline and without any backport?
>> It is hard to reason about something that isn't a vanilla kernel.
>
> I think our kernel is quite like v5.3 mainline. Reproducing it in v5.3 
> mainline may
>
> be a little difficult for us because our product needs some more self 
> developed
>
> patches to work.
>
>>
>>> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
>>> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
>>> means an interrupt preempts the other one and the new one is an NMI.
>>> Furthermore, by adding some prints, we find the first irq also calls
>>> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq 
>>> number
>>> is 1023. It enables irq by calling gic_arch_enable_irqs() in
>>> gic_handle_irq(). At this moment, the second irq preempts the first irq
>>> and it's an NMI but current context is already in nmi. So that may be
>>> the problem.
>> I'm not sure I get it. From the stack trace, I see this:
>>
>> [?? 14.816251]? asm_nmi_enter+0x94/0x98
>> [?? 14.816251]? el1_irq+0x8c/0x180??????????? (C)
>> [?? 14.816252]? gic_handle_irq+0xbc/0x2e4
>> [?? 14.816252]? el1_irq+0xcc/0x180??????????? (B)
>> [?? 14.816253]? arch_timer_handler_virt+0x38/0x58
>> [?? 14.816253]? handle_percpu_devid_irq+0x90/0x240
>> [?? 14.816253]? generic_handle_irq+0x34/0x50
>> [?? 14.816254]? __handle_domain_irq+0x68/0xc0
>> [?? 14.816254]? gic_handle_irq+0xf8/0x2e4
>> [?? 14.816255]? el1_irq+0xcc/0x180??????????? (A)
>>
>> which indicates that we preempted a timer interrupt (A) with another
>> IRQ (B), itself immediately preempted by another IRQ (C)? That's
>> indeed at least one too many.
>>
>> Can you please describe for each of (A), (B) and (C) whether they are
>> spurious or not, what their priorities are if they aren't spurious?
>
> Yes. I ignored interrupt (A). (B) is spurious and its priority is 0xa0 
> and PMR is 0x70.
>
> (C) is an NMI and its priority is 0x20. Note that GIC_PRIO_IRQON is 0xe0,
>
> GIC_PRIO_IRQOFF is 0x60, GICD_INT_DEF_PRI is 0xa0 and GICD_INT_NMI_PRI is
>
> 0x20 in our kernel.
>
>>> In my opinion, when handling spurious interrupts, we shouldn't 
>>> enable irqs.
>>> My reason is that for spurious interrupts we may enter nmi context in
>>> el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
>>> at this time, another NMI may happen and preempt this spurious 
>>> interrupt
>>> but the context is already in nmi. That causes a bug on if nested 
>>> NMI is
>>> not supported. Even for nested nmi, I think it's not a normal scenario.
>> I would tend to agree that this isn't great. Actually, I'd probably
>> move the check for a spurious interrupt right after the read of
>> ICC_IAR1_EL1, because there is no real need to do anything else at
>> that point.
>
> So, we don't need to check NMI for spurious interrupts? Do you mean 
> that spurious
>
> interrupts' can't be NMIs? Or even spurious interrups are NMIs, we 
> shouldn't do
>
> anything for them? If so, I will move the check after the read of 
> ICC_IAR1_EL1 and
>
> send a V2.
>
>>
>> However, upstream is quite different from 4.19 in that respect, and
>> I'm not sure if what I am looking at is what you are seeing with your
>> older kernel.
>
> I know that. And I look into all patches about arm64 pseudo NMIs. As I 
> said before,
>
> our kernel is very quite like v5.3 mainline. I think we are talking 
> about the same thing.
>
>
> In my opinion, since commit 17ce302f3117 ("arm64: Fix interrupt 
> tracing in the presence of NMIs"),
>
> spurious interrups can enter nmi context in interrupt entry because 
> PMR can be GIC_PRIO_IRQOFF
>
> for spurious interrupts. That means test_irqs_unmasked is not 0 and 
> asm_nmi_enter is called.
>
> ?? (some el1_irq entry code from v5.3)
>
> ?? test_irqs_unmasked? res=x0, pmr=x20
>
> ?? cbz x0, 1f
>
> ?? bl asm_nmi_enter
>
>
> And it then calls gic_handle_irq(). It doesn't call gic_handle_nmi() 
> because its priority is not GICD_INT_NMI_PRI.
>
> Then it enables irqs. If at that point another NMI comes and preempts 
> it, which means NMI occurs in nmi
>
> context. That may cause a bug on if nested NMI is not supported.
>
> ?? (some gic_handle_irq code from v5.3)
>
> ?? irqnr = gic_read_iar();
>
> ?? if (gic_supports_nmi() &&
> ? ? ?? unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
> ?????????? gic_handle_nmi(irqnr, 
> regs);?????????????????????????????????? (C)
> ?????????? return;
> ?? }
>
> ?? if (gic_prio_masking_enabled()) {
> ???????? gic_pmr_mask_irqs();
> gic_arch_enable_irqs(); (D)
> ?? }
>
>>
>> Thanks,
>>
>> ????M.
>>
>>> Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence 
>>> of NMIs")
>>> Signed-off-by: He Ying <heying24 at huawei.com>
>>> ---
>>> ? drivers/irqchip/irq-gic-v3.c | 8 ++++----
>>> ? 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3.c 
>>> b/drivers/irqchip/irq-gic-v3.c
>>> index 94b89258d045..d3b52734a2c5 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -654,15 +654,15 @@ static asmlinkage void __exception_irq_entry 
>>> gic_handle_irq(struct pt_regs *regs
>>> ????????? return;
>>> ????? }
>>> ? +??? /* Check for special IDs first */
>>> +??? if ((irqnr >= 1020 && irqnr <= 1023))
>>> +??????? return;
>>> +
>>> ????? if (gic_prio_masking_enabled()) {
>>> ????????? gic_pmr_mask_irqs();
>>> ????????? gic_arch_enable_irqs();
>>> ????? }
>>> ? -??? /* Check for special IDs first */
>>> -??? if ((irqnr >= 1020 && irqnr <= 1023))
>>> -??????? return;
>>> -
>>> ????? if (static_branch_likely(&supports_deactivate_key))
>>> ????????? gic_write_eoir(irqnr);
>>> ????? else
>>> -- 
>>> 2.17.1
>>>
>>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jbx6244 at gmail.com  Wed Apr 21 10:26:58 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 21 Apr 2021 11:26:58 +0200
Subject: [PATCH v1 3/5] dt-bindings: mmc: rockchip-dw-mshc: add
 description for rk3568
In-Reply-To: <20210421065921.23917-4-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-4-cl@rock-chips.com>
Message-ID: <7dde9617-9d71-9fdd-6f91-3fc327fa9bc1@gmail.com>

On 4/21/21 8:59 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci" for mmc nodes on
> a rk3568 platform to rockchip-dw-mshc.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> index 3762f1c8de96..2a6c1cee4887 100644
> --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> @@ -27,6 +27,8 @@ properties:
>        - const: rockchip,rk2928-dw-mshc
>        # for Rockchip RK3288
>        - const: rockchip,rk3288-dw-mshc

> +      # for Rockchip RK3568
> +      - const: rockchip,rk3568-dwcmshc

Remove.
This would create two descriptions.
"rockchip,rk3568-dwcmshc"
"rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci"

>        - items:
>            - enum:

>              # for Rockchip PX30

Remove comments.

> @@ -41,6 +43,8 @@ properties:
>                - rockchip,rk3328-dw-mshc

>              # for Rockchip RK3368

Remove comments.

>                - rockchip,rk3368-dw-mshc

> +            # for Rockchip RK3568

Maybe remove the "#" comments in this enum part too.
This was one of the first Rockchip documents that was converted, but is
not really needed, as it both mentions the soc name.

> +              - rockchip,rk3568-dw-mshc

Sort this below rockchip,rk3399-dw-mshc

>              # for Rockchip RK3399

Remove comments.
>                - rockchip,rk3399-dw-mshc

>              # for Rockchip RV1108

Remove comments.

> 



From u.kleine-koenig at pengutronix.de  Wed Apr 21 10:26:08 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Wed, 21 Apr 2021 11:26:08 +0200
Subject: [PATCH] pwm: atmel: rework tracking updates pending in hardware
In-Reply-To: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210421092606.1634092-1-u.kleine-koenig@pengutronix.de>

This improves the driver's behavior in several ways:

 - The lock is held for shorter periods and so a channel that is currently
   waited for doesn't block disabling another channel.

 - It's easier to understand because the procedure is split into more
   semantic units and documentation is improved

 - A channel is only set to pending when such an event is actually
   scheduled in hardware (by writing the CUPD register).

 - Also wait in .get_state() to report the last configured state instead
   of (maybe) the previous one. This fixes the read back duty cycle and so
   prevents a warning being emitted when PWM_DEBUG is on.

Tested on an AriettaG25.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
Hello,

I tested this patch on top of the series I sent for this driver
yesterday. (I set In-Reply-To accordingly.)

With these three patches PWM_DEBUG is now happy. (At least I couldn't
trigger a warning any more. I think there are still a few problems with
integer overflows.)

Best regards
Uwe

 drivers/pwm/pwm-atmel.c | 101 +++++++++++++++++++++++++++++++---------
 1 file changed, 78 insertions(+), 23 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 29b5ad03f715..38d86340201c 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -84,9 +84,19 @@ struct atmel_pwm_chip {
 	void __iomem *base;
 	const struct atmel_pwm_data *data;
 
-	unsigned int updated_pwms;
-	/* ISR is cleared when read, ensure only one thread does that */
-	struct mutex isr_lock;
+	/*
+	 * The hardware supports a mechanism to update a channel's duty cycle at
+	 * the end of the currently running period. When such an update is
+	 * pending we delay disabling the PWM until the new configuration is
+	 * active because otherwise pmw_config(duty_cycle=0); pwm_disable();
+	 * might not result in an inactive output.
+	 * This bitmask tracks for which channels an update is pending in
+	 * hardware.
+	 */
+	u32 update_pending;
+
+	/* Protects .update_pending */
+	spinlock_t lock;
 };
 
 static inline struct atmel_pwm_chip *to_atmel_pwm_chip(struct pwm_chip *chip)
@@ -123,6 +133,63 @@ static inline void atmel_pwm_ch_writel(struct atmel_pwm_chip *chip,
 	atmel_pwm_writel(chip, base + offset, val);
 }
 
+static void atmel_pwm_update_pending(struct atmel_pwm_chip *chip)
+{
+	/*
+	 * Each channel that has its bit in ISR set started a new period since
+	 * ISR was cleared and so there is no more update pending.  Note that
+	 * reading ISR clears it, so this needs to handle all channels to not
+	 * loose information.
+	 */
+	u32 isr = atmel_pwm_readl(chip, PWM_ISR);
+	chip->update_pending &= ~isr;
+}
+
+static void atmel_pwm_set_pending(struct atmel_pwm_chip *chip, unsigned int ch)
+{
+	spin_lock(&chip->lock);
+
+	/*
+	 * Clear pending flags in hardware because otherwise there might still
+	 * be a stale flag in ISR.
+	 */
+	atmel_pwm_update_pending(chip);
+
+	chip->update_pending |= (1 << ch);
+
+	spin_unlock(&chip->lock);
+}
+
+static int atmel_pwm_test_pending(struct atmel_pwm_chip *chip, unsigned int ch)
+{
+	int ret = 0;
+
+	spin_lock(&chip->lock);
+
+	if (chip->update_pending & (1 << ch)) {
+		atmel_pwm_update_pending(chip);
+
+		if (chip->update_pending & (1 << ch))
+			ret = 1;
+	}
+
+	spin_unlock(&chip->lock);
+
+	return ret;
+}
+
+static int atmel_pwm_wait_nonpending(struct atmel_pwm_chip *chip, unsigned int ch)
+{
+	unsigned long timeout = jiffies + 2 * HZ;
+	int ret;
+
+	while ((ret = atmel_pwm_test_pending(chip, ch)) &&
+	       time_before(jiffies, timeout))
+		usleep_range(10, 100);
+
+	return ret ? -ETIMEDOUT : 0;
+}
+
 static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
 					     unsigned long clkrate,
 					     const struct pwm_state *state,
@@ -185,6 +252,7 @@ static void atmel_pwm_update_cdty(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
 			    atmel_pwm->data->regs.duty_upd, cdty);
+	atmel_pwm_set_pending(atmel_pwm, pwm->hwpwm);
 }
 
 static void atmel_pwm_set_cprd_cdty(struct pwm_chip *chip,
@@ -205,20 +273,8 @@ static void atmel_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm,
 	struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
 	unsigned long timeout = jiffies + 2 * HZ;
 
-	/*
-	 * Wait for at least a complete period to have passed before disabling a
-	 * channel to be sure that CDTY has been updated
-	 */
-	mutex_lock(&atmel_pwm->isr_lock);
-	atmel_pwm->updated_pwms |= atmel_pwm_readl(atmel_pwm, PWM_ISR);
-
-	while (!(atmel_pwm->updated_pwms & (1 << pwm->hwpwm)) &&
-	       time_before(jiffies, timeout)) {
-		usleep_range(10, 100);
-		atmel_pwm->updated_pwms |= atmel_pwm_readl(atmel_pwm, PWM_ISR);
-	}
+	atmel_pwm_wait_nonpending(atmel_pwm, pwm->hwpwm);
 
-	mutex_unlock(&atmel_pwm->isr_lock);
 	atmel_pwm_writel(atmel_pwm, PWM_DIS, 1 << pwm->hwpwm);
 
 	/*
@@ -292,10 +348,6 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 			val |= PWM_CMR_CPOL;
 		atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
 		atmel_pwm_set_cprd_cdty(chip, pwm, cprd, cdty);
-		mutex_lock(&atmel_pwm->isr_lock);
-		atmel_pwm->updated_pwms |= atmel_pwm_readl(atmel_pwm, PWM_ISR);
-		atmel_pwm->updated_pwms &= ~(1 << pwm->hwpwm);
-		mutex_unlock(&atmel_pwm->isr_lock);
 		atmel_pwm_writel(atmel_pwm, PWM_ENA, 1 << pwm->hwpwm);
 	} else if (cstate.enabled) {
 		atmel_pwm_disable(chip, pwm, true);
@@ -326,6 +378,9 @@ static void atmel_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
 		tmp <<= pres;
 		state->period = DIV64_U64_ROUND_UP(tmp, rate);
 
+		/* Wait for an updated duty_cycle queued in hardware */
+		atmel_pwm_wait_nonpending(atmel_pwm, pwm->hwpwm);
+
 		cdty = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
 					  atmel_pwm->data->regs.duty);
 		tmp = (u64)(cprd - cdty) * NSEC_PER_SEC;
@@ -416,9 +471,10 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	if (!atmel_pwm)
 		return -ENOMEM;
 
-	mutex_init(&atmel_pwm->isr_lock);
 	atmel_pwm->data = of_device_get_match_data(&pdev->dev);
-	atmel_pwm->updated_pwms = 0;
+
+	atmel_pwm->update_pending = 0;
+	spin_lock_init(&atmel_pwm->lock);
 
 	atmel_pwm->base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(atmel_pwm->base))
@@ -462,7 +518,6 @@ static int atmel_pwm_remove(struct platform_device *pdev)
 	pwmchip_remove(&atmel_pwm->chip);
 
 	clk_unprepare(atmel_pwm->clk);
-	mutex_destroy(&atmel_pwm->isr_lock);
 
 	return 0;
 }
-- 
2.30.2



From maxime at cerno.tech  Wed Apr 21 10:27:25 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Wed, 21 Apr 2021 11:27:25 +0200
Subject: [PATCH 0/2] Allwinner H6 USB3 device tree updates
In-Reply-To: <20210421042834.27309-1-samuel@sholland.org>
References: <20210421042834.27309-1-samuel@sholland.org>
Message-ID: <20210421092725.qacp3446hiyf73ov@gilmour>

Hi,

On Tue, Apr 20, 2021 at 11:28:32PM -0500, Samuel Holland wrote:
> While implementing support for this USB controller in U-Boot, I noticed
> that the reset line alsp affects they PHY. It looks like most platforms
> use a separate glue node to represent this, and in fact there is already
> a compatible for the H6 listed in drivers/usb/dwc3/dwc3-of-simple.c.
> 
> Since this layout matches the usual way of modeling this hardware, it
> allows using the existing drivers without adding platform-specific code.

I'm not sure which branch you based this on, but the Pine H64 seems to
be missing the USB3 support in the first place. I've applied the rest of
the changes though, 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/20210421/3155bd53/attachment.sig>

From catalin.marinas at arm.com  Wed Apr 21 10:58:25 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 21 Apr 2021 10:58:25 +0100
Subject: [PATCH v5 06/13] arm64: stacktrace: Use %pSb for backtrace
 printing
In-Reply-To: <20210420215003.3510247-7-swboyd@chromium.org>
References: <20210420215003.3510247-1-swboyd@chromium.org>
 <20210420215003.3510247-7-swboyd@chromium.org>
Message-ID: <20210421095825.GB18635@arm.com>

On Tue, Apr 20, 2021 at 02:49:56PM -0700, Stephen Boyd wrote:
> Let's use the new printk format to print the stacktrace entry when
> printing a backtrace to the kernel logs. This will include any module's
> build ID[1] in it so that offline/crash debugging can easily locate the
> debuginfo for a module via something like debuginfod[2].
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: <linux-arm-kernel at lists.infradead.org>
> Cc: Jiri Olsa <jolsa at kernel.org>
> Cc: Alexei Starovoitov <ast at kernel.org>
> Cc: Jessica Yu <jeyu at kernel.org>
> Cc: Evan Green <evgreen at chromium.org>
> Cc: Hsin-Yi Wang <hsinyi at chromium.org>
> Cc: Petr Mladek <pmladek at suse.com>
> Cc: Steven Rostedt <rostedt at goodmis.org>
> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Matthew Wilcox <willy at infradead.org>
> Link: https://fedoraproject.org/wiki/Releases/FeatureBuildId [1]
> Link: https://sourceware.org/elfutils/Debuginfod.html [2]
> Signed-off-by: Stephen Boyd <swboyd at chromium.org>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From fengquan.chen at mediatek.com  Wed Apr 21 11:07:52 2021
From: fengquan.chen at mediatek.com (Fengquan Chen)
Date: Wed, 21 Apr 2021 18:07:52 +0800
Subject: [PATCH] clocksource/drivers/timer-mediatek: optimize systimer
 irq clear flow on Mediatek Socs
In-Reply-To: <c91e9afc-8b04-f35b-bcf9-1fcf9a6f425f@linaro.org>
References: <1614670085-26229-1-git-send-email-Fengquan.Chen@mediatek.com>
 <1614670085-26229-2-git-send-email-Fengquan.Chen@mediatek.com>
 <c91e9afc-8b04-f35b-bcf9-1fcf9a6f425f@linaro.org>
Message-ID: <1618999672.25707.13.camel@mhfsdcap03>

On Mon, 2021-03-22 at 11:10 +0100, Daniel Lezcano wrote:
> On 02/03/2021 08:28, Fengquan Chen wrote:
> > 1)ensure systimer is enabled before clear and disable interrupt, which only
> > for systimer in Mediatek Socs.
> >
> > 2)clear any pending timer-irq when shutdown to keep suspend flow clean,
> > when use systimer as tick-broadcast timer
> > 
> > Change-Id: Ia3eda83324af2fdaf5cbb3569a9bf020a11f8009
> 
> Remove the above.
> 
> Add a Fixes tag.

Thanks for review, has been fixed in V4:
https://patchwork.kernel.org/project/linux-mediatek/patch/1617960162-1988-2-git-send-email-Fengquan.Chen at mediatek.com/

> 
> > Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>
> > ---
> >  drivers/clocksource/timer-mediatek.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> > index 9318edc..9f1f095dc 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -75,6 +75,7 @@
> >  static void mtk_syst_ack_irq(struct timer_of *to)
> >  {
> >  	/* Clear and disable interrupt */
> > +	writel(SYST_CON_EN, SYST_CON_REG(to));
> 
> 	SYST_CON_EN is set below, why do you have to do it before?
> 
> Is that a hw bug ?
> 
> It is confusing what the description of the SYST_CON_EN says:
> 
> /*
>  * SYST_CON_EN: Clock enable. Shall be set to
>  *   - Start timer countdown.
>  *   - Allow timeout ticks being updated.
>  *   - Allow changing interrupt functions.
> 
> What means "interrupt functions" ?
> 
> Does writing writel(SYST_CON_EN, SYST_CON_REG(to)) before
> SYST_CON_IRQ_CLR allows to clear the interrupt flag?
> 
> Can you explain how the timer works regarding this part?
> 
> It sounds to me a bit strange.
> 
>  *
>  * SYST_CON_IRQ_EN: Set to allow interrupt.
>  *
>  * SYST_CON_IRQ_CLR: Set to clear interrupt.
>  */
> 

Thanks for review, descriptions about
SYST_CON_IRQ_CLR/SYST_CON_EN/SYST_CON_IRQ_EN have been updated in v4.

And for systimer, there's a hw limitation that before clearing pending
irqs, we must enable timer first. so we added a SYST_CON_EN write before
SYST_CON_IRQ_CLR write to ensure irq clear successfully.

Also, we cannot only write SYST_CON_IRQ_CLR without SYST_CON_EN bit,
because EN bit is also timer clock enable bit. 

this is a hardward design limitation but not a bug.

> 
> >  	writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
> >  }
> >  
> > @@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
> >  
> >  static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
> >  {
> > +	/* Clear any irq */
> > +	mtk_syst_ack_irq(to_timer_of(clkevt));
> > +
> >  	/* Disable timer */
> >  	writel(0, SYST_CON_REG(to_timer_of(clkevt)));
> >  
> > 
> 
> 


From aisheng.dong at nxp.com  Wed Apr 21 11:12:20 2021
From: aisheng.dong at nxp.com (Aisheng Dong)
Date: Wed, 21 Apr 2021 10:12:20 +0000
Subject: [PATCH v10] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes
In-Reply-To: <20210406172740.13904-1-mirela.rabulea@oss.nxp.com>
References: <20210406172740.13904-1-mirela.rabulea@oss.nxp.com>
Message-ID: <AM6PR04MB496668C16DBDC3D46A2A018080479@AM6PR04MB4966.eurprd04.prod.outlook.com>

+ linux-arm-kernel at lists.infradead.org

> From: Mirela Rabulea (OSS) <mirela.rabulea at oss.nxp.com>
> Sent: Wednesday, April 7, 2021 1:28 AM
> 
> Add dts for imaging subsytem, include jpeg nodes here.
> Tested on imx8qxp only, should work on imx8qm, but it was not tested.
> 
> Signed-off-by: Mirela Rabulea <mirela.rabulea at nxp.com>
> ---
> This was patch #7 in the initial patch set that added mxc-jpeg driver
> 
> Changes in v10:
>   Addressed feedback from Aisheng Dong:
>     -Add jpeg clocks in the jpeg dts nodes.
>     -Adapt to the recent split of the dts into subsystems:
>      add the imaging subsystem, and place jpeg nodes there.
> 
>  .../arm64/boot/dts/freescale/imx8-ss-img.dtsi | 89 +++++++++++++++++++
>  arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |  1 +
>  2 files changed, 90 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> new file mode 100644
> index 000000000000..1457d219a658
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019-2021 NXP
> + * Zhou Guoniu <guoniu.zhou at nxp.com>
> + */
> +img_subsys: bus at 58000000 {
> +	compatible = "simple-bus";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	ranges = <0x58000000 0x0 0x58000000 0x1000000>;
> +
> +	img_ipg_clk: clock-img-ipg {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <200000000>;
> +		clock-output-names = "img_ipg_clk";
> +	};
> +
> +	img_jpeg_dec_clk: clock-controller at 585d0000 {

s/clk/lpcg

> +		compatible = "fsl,imx8qxp-lpcg";
> +		reg = <0x585d0000 0x10000>;
> +		#clock-cells = <1>;
> +		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
> +		clock-indices = <IMX_LPCG_CLK_0>,
> +				<IMX_LPCG_CLK_4>;
> +		clock-output-names = "img_jpeg_dec_clk",
> +				     "img_jpeg_dec_ipg_clk";
> +		power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>;
> +	};
> +
> +	img_jpeg_enc_clk: clock-controller at 585f0000 {

s/clk/lpcg

> +		compatible = "fsl,imx8qxp-lpcg";
> +		reg = <0x585f0000 0x10000>;
> +		#clock-cells = <1>;
> +		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
> +		clock-indices = <IMX_LPCG_CLK_0>,
> +				<IMX_LPCG_CLK_4>;
> +		clock-output-names = "img_jpeg_enc_clk",
> +				     "img_jpeg_enc_ipg_clk";
> +		power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>;
> +	};
> +
> +	cameradev: camera {

Is this node necessary?

> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		jpegdec: jpegdec at 58400000 {
> +			compatible = "nxp,imx8qxp-jpgdec";

Is this compatible string upstreamed already?

> +			reg = <0x58400000 0x00050000 >;
> +			interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&img_jpeg_dec_clk 0>,
> +				 <&img_jpeg_dec_clk 1>;

Is the index correct here?

> +			clock-names = "per", "ipg";
> +			assigned-clocks = <&img_jpeg_dec_clk 0>,
> +					  <&img_jpeg_dec_clk 1>;
> +			assigned-clock-rates = <200000000>;

Mismatch with assigned-clocks

> +			power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>,
> +					<&pd IMX_SC_R_MJPEG_DEC_S0>,
> +					<&pd IMX_SC_R_MJPEG_DEC_S1>,
> +					<&pd IMX_SC_R_MJPEG_DEC_S2>,
> +					<&pd IMX_SC_R_MJPEG_DEC_S3>;
> +		};
> +
> +		jpegenc: jpegenc at 58450000 {
> +			compatible = "nxp,imx8qxp-jpgenc";
> +			reg = <0x58450000 0x00050000 >;
> +			interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&img_jpeg_enc_clk 0>,
> +				 <&img_jpeg_enc_clk 1>;

Ditto

> +			clock-names = "per", "ipg";
> +			assigned-clocks = <&img_jpeg_enc_clk 0>,
> +					  <&img_jpeg_enc_clk 1>;
> +			assigned-clock-rates = <200000000>;

Ditto

> +			power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>,
> +					<&pd IMX_SC_R_MJPEG_ENC_S0>,
> +					<&pd IMX_SC_R_MJPEG_ENC_S1>,
> +					<&pd IMX_SC_R_MJPEG_ENC_S2>,
> +					<&pd IMX_SC_R_MJPEG_ENC_S3>;
> +		};
> +	};
> +};

Regards
Aisheng

> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 1e6b4995091e..2d9589309bd0 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -258,6 +258,7 @@
>  	};
> 
>  	/* sorted in register address */
> +	#include "imx8-ss-img.dtsi"
>  	#include "imx8-ss-adma.dtsi"
>  	#include "imx8-ss-conn.dtsi"
>  	#include "imx8-ss-ddr.dtsi"
> --
> 2.17.1


From aisheng.dong at nxp.com  Wed Apr 21 11:14:30 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Wed, 21 Apr 2021 18:14:30 +0800
Subject: [PATCH 1/3] firmware: imx: pd: fix img-jpegdec pd names
Message-ID: <20210421101432.2043310-1-aisheng.dong@nxp.com>

Changed as follows to align with HW better:
img-jpegdec-s00 -> img-jpegdec-s0
img-jpegdec-s01 -> img-jpegdec-s1

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/firmware/imx/scu-pd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index ff6569c4a53b..a7589cc5ac23 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -198,9 +198,9 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 
 	/* IMAGE SS */
 	{ "img-jpegdec-mp", IMX_SC_R_MJPEG_DEC_MP, 1, false, 0 },
-	{ "img-jpegdec-s0", IMX_SC_R_MJPEG_DEC_S0, 4, true, 0 },
+	{ "img-jpegdec-s", IMX_SC_R_MJPEG_DEC_S0, 4, true, 0 },
 	{ "img-jpegenc-mp", IMX_SC_R_MJPEG_ENC_MP, 1, false, 0 },
-	{ "img-jpegenc-s0", IMX_SC_R_MJPEG_ENC_S0, 4, true, 0 },
+	{ "img-jpegenc-s", IMX_SC_R_MJPEG_ENC_S0, 4, true, 0 },
 };
 
 static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
-- 
2.25.1



From aisheng.dong at nxp.com  Wed Apr 21 11:14:31 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Wed, 21 Apr 2021 18:14:31 +0800
Subject: [PATCH 2/3] firmware: imx: pd: add missing power domains
In-Reply-To: <20210421101432.2043310-1-aisheng.dong@nxp.com>
References: <20210421101432.2043310-1-aisheng.dong@nxp.com>
Message-ID: <20210421101432.2043310-2-aisheng.dong@nxp.com>

A few power domains supported by SCFW are missing.
Add them for driver users.

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/firmware/imx/scu-pd.c | 69 +++++++++++++++++++++++++++++++++--
 1 file changed, 66 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index a7589cc5ac23..446a4f9f0ec9 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -120,12 +120,17 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 	{ "audio-pll1", IMX_SC_R_AUDIO_PLL_1, 1, false, 0 },
 	{ "audio-clk-0", IMX_SC_R_AUDIO_CLK_0, 1, false, 0 },
 	{ "audio-clk-1", IMX_SC_R_AUDIO_CLK_1, 1, false, 0 },
-	{ "dma0-ch", IMX_SC_R_DMA_0_CH0, 16, true, 0 },
+	{ "dma0-ch", IMX_SC_R_DMA_0_CH0, 32, true, 0 },
 	{ "dma1-ch", IMX_SC_R_DMA_1_CH0, 16, true, 0 },
 	{ "dma2-ch", IMX_SC_R_DMA_2_CH0, 5, true, 0 },
+	{ "dma2-ch", IMX_SC_R_DMA_2_CH5, 27, true, 5 },
+	{ "dma3-ch", IMX_SC_R_DMA_3_CH0, 32, true, 0 },
 	{ "asrc0", IMX_SC_R_ASRC_0, 1, false, 0 },
 	{ "asrc1", IMX_SC_R_ASRC_1, 1, false, 0 },
 	{ "esai0", IMX_SC_R_ESAI_0, 1, false, 0 },
+	{ "esai1", IMX_SC_R_ESAI_1, 1, false, 0 },
+	{ "mclk-out-0", IMX_SC_R_MCLK_OUT_0, 1, false, 0 },
+	{ "mclk-out-1", IMX_SC_R_MCLK_OUT_1, 1, false, 0 },
 	{ "spdif0", IMX_SC_R_SPDIF_0, 1, false, 0 },
 	{ "spdif1", IMX_SC_R_SPDIF_1, 1, false, 0 },
 	{ "sai", IMX_SC_R_SAI_0, 3, true, 0 },
@@ -142,11 +147,13 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 	/* DMA SS */
 	{ "can", IMX_SC_R_CAN_0, 3, true, 0 },
 	{ "ftm", IMX_SC_R_FTM_0, 2, true, 0 },
-	{ "lpi2c", IMX_SC_R_I2C_0, 4, true, 0 },
+	{ "lpi2c", IMX_SC_R_I2C_0, 5, true, 0 },
 	{ "adc", IMX_SC_R_ADC_0, 2, true, 0 },
 	{ "lcd", IMX_SC_R_LCD_0, 1, true, 0 },
+	{ "lcd-pll", IMX_SC_R_ELCDIF_PLL, 1, true, 0 },
 	{ "lcd0-pwm", IMX_SC_R_LCD_0_PWM_0, 1, true, 0 },
-	{ "lpuart", IMX_SC_R_UART_0, 4, true, 0 },
+	{ "lpuart", IMX_SC_R_UART_0, 5, true, 0 },
+	{ "sim", IMX_SC_R_EMVSIM_0, 2, true, 0 },
 	{ "lpspi", IMX_SC_R_SPI_0, 4, true, 0 },
 	{ "irqstr_dsp", IMX_SC_R_IRQSTR_DSP, 1, false, 0 },
 
@@ -155,13 +162,21 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 	{ "vpu-pid", IMX_SC_R_VPU_PID0, 8, true, 0 },
 	{ "vpu-dec0", IMX_SC_R_VPU_DEC_0, 1, false, 0 },
 	{ "vpu-enc0", IMX_SC_R_VPU_ENC_0, 1, false, 0 },
+	{ "vpu-enc1", IMX_SC_R_VPU_ENC_1, 1, false, 0 },
+	{ "vpu-mu0", IMX_SC_R_VPU_MU_0, 1, false, 0 },
+	{ "vpu-mu1", IMX_SC_R_VPU_MU_1, 1, false, 0 },
+	{ "vpu-mu2", IMX_SC_R_VPU_MU_2, 1, false, 0 },
 
 	/* GPU SS */
 	{ "gpu0-pid", IMX_SC_R_GPU_0_PID0, 4, true, 0 },
+	{ "gpu1-pid", IMX_SC_R_GPU_1_PID0, 4, true, 0 },
 
 	/* HSIO SS */
+	{ "pcie-a", IMX_SC_R_PCIE_A, 1, false, 0 },
+	{ "serdes-0", IMX_SC_R_SERDES_0, 1, false, 0 },
 	{ "pcie-b", IMX_SC_R_PCIE_B, 1, false, 0 },
 	{ "serdes-1", IMX_SC_R_SERDES_1, 1, false, 0 },
+	{ "sata-0", IMX_SC_R_SATA_0, 1, false, 0 },
 	{ "hsio-gpio", IMX_SC_R_HSIO_GPIO, 1, false, 0 },
 
 	/* MIPI SS */
@@ -175,13 +190,21 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 
 	/* LVDS SS */
 	{ "lvds0", IMX_SC_R_LVDS_0, 1, false, 0 },
+	{ "lvds0-pwm", IMX_SC_R_LVDS_0_PWM_0, 1, false, 0 },
+	{ "lvds0-lpi2c", IMX_SC_R_LVDS_0_I2C_0, 2, true, 0 },
 	{ "lvds1", IMX_SC_R_LVDS_1, 1, false, 0 },
+	{ "lvds1-pwm", IMX_SC_R_LVDS_1_PWM_0, 1, false, 0 },
+	{ "lvds1-lpi2c", IMX_SC_R_LVDS_1_I2C_0, 2, true, 0 },
 
 	/* DC SS */
 	{ "dc0", IMX_SC_R_DC_0, 1, false, 0 },
 	{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
 	{ "dc0-video", IMX_SC_R_DC_0_VIDEO0, 2, true, 0 },
 
+	{ "dc1", IMX_SC_R_DC_1, 1, false, 0 },
+	{ "dc1-pll", IMX_SC_R_DC_1_PLL_0, 2, true, 0 },
+	{ "dc1-video", IMX_SC_R_DC_1_VIDEO0, 2, true, 0 },
+
 	/* CM40 SS */
 	{ "cm40-i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
 	{ "cm40-intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
@@ -196,11 +219,51 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 	{ "cm41-mu-a1", IMX_SC_R_M4_1_MU_1A, 1, false, 0},
 	{ "cm41-lpuart", IMX_SC_R_M4_1_UART, 1, false, 0},
 
+	/* CM41 SS */
+	{ "cm41_i2c", IMX_SC_R_M4_1_I2C, 1, false, 0 },
+	{ "cm41_intmux", IMX_SC_R_M4_1_INTMUX, 1, false, 0 },
+
+	/* DB SS */
+	{ "perf", IMX_SC_R_PERF, 1, false, 0},
+
 	/* IMAGE SS */
 	{ "img-jpegdec-mp", IMX_SC_R_MJPEG_DEC_MP, 1, false, 0 },
 	{ "img-jpegdec-s", IMX_SC_R_MJPEG_DEC_S0, 4, true, 0 },
 	{ "img-jpegenc-mp", IMX_SC_R_MJPEG_ENC_MP, 1, false, 0 },
 	{ "img-jpegenc-s", IMX_SC_R_MJPEG_ENC_S0, 4, true, 0 },
+	{ "img-pdma", IMX_SC_R_ISI_CH0, 8, true, 0 },
+	{ "img-csi0", IMX_SC_R_CSI_0, 1, false, 0 },
+	{ "img-csi0-i2c0", IMX_SC_R_CSI_0_I2C_0, 1, false, 0 },
+	{ "img-csi0-pwm0", IMX_SC_R_CSI_0_PWM_0, 1, false, 0 },
+	{ "img-csi1", IMX_SC_R_CSI_1, 1, false, 0 },
+	{ "img-csi1-i2c0", IMX_SC_R_CSI_1_I2C_0, 1, false, 0 },
+	{ "img-csi1-pwm0", IMX_SC_R_CSI_1_PWM_0, 1, false, 0 },
+	{ "img-parallel", IMX_SC_R_PI_0, 1, false, 0 },
+	{ "img-parallel-i2c0", IMX_SC_R_PI_0_I2C_0, 1, false, 0 },
+	{ "img-parallel-pwm", IMX_SC_R_PI_0_PWM_0, 2, true, 0 },
+	{ "img-parallel-pll", IMX_SC_R_PI_0_PLL, 1, false, 0 },
+
+	/* SECO SS */
+	{ "seco_mu", IMX_SC_R_SECO_MU_2, 3, true, 2},
+
+	/* HDMI TX SS */
+	{ "hdmi-tx", IMX_SC_R_HDMI, 1, false, 0},
+	{ "hdmi-tx-i2s", IMX_SC_R_HDMI_I2S, 1, false, 0},
+	{ "hdmi-tx-i2c0", IMX_SC_R_HDMI_I2C_0, 1, false, 0},
+	{ "hdmi-tx-pll0", IMX_SC_R_HDMI_PLL_0, 1, false, 0},
+	{ "hdmi-tx-pll1", IMX_SC_R_HDMI_PLL_1, 1, false, 0},
+
+	/* HDMI RX SS */
+	{ "hdmi-rx", IMX_SC_R_HDMI_RX, 1, false, 0},
+	{ "hdmi-rx-pwm0", IMX_SC_R_HDMI_RX_PWM_0, 1, false, 0},
+	{ "hdmi-rx-i2c0", IMX_SC_R_HDMI_RX_I2C_0, 1, false, 0},
+	{ "hdmi-rx-bypass", IMX_SC_R_HDMI_RX_BYPASS, 1, false, 0},
+
+	/* SECURITY SS */
+	{ "sec-jr", IMX_SC_R_CAAM_JR2, 2, true, 2},
+
+	/* BOARD SS */
+	{ "board", IMX_SC_R_BOARD_R0, 8, true, 0},
 };
 
 static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
-- 
2.25.1



From aisheng.dong at nxp.com  Wed Apr 21 11:14:32 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Wed, 21 Apr 2021 18:14:32 +0800
Subject: [PATCH 3/3] firmware: imx: pd: make driver look more generic
In-Reply-To: <20210421101432.2043310-1-aisheng.dong@nxp.com>
References: <20210421101432.2043310-1-aisheng.dong@nxp.com>
Message-ID: <20210421101432.2043310-3-aisheng.dong@nxp.com>

The SCU protocal is platform independent, so make the driver
code as it is by dropping the soc prefix for structures.

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/firmware/imx/scu-pd.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index 446a4f9f0ec9..bdf88aed6dca 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -95,7 +95,7 @@ struct imx_sc_pd_soc {
 
 static int imx_con_rsrc;
 
-static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
+static const struct imx_sc_pd_range scu_pd_ranges[] = {
 	/* LSIO SS */
 	{ "pwm", IMX_SC_R_PWM_0, 8, true, 0 },
 	{ "gpio", IMX_SC_R_GPIO_0, 8, true, 0 },
@@ -266,9 +266,9 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
 	{ "board", IMX_SC_R_BOARD_R0, 8, true, 0},
 };
 
-static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
-	.pd_ranges = imx8qxp_scu_pd_ranges,
-	.num_ranges = ARRAY_SIZE(imx8qxp_scu_pd_ranges),
+static const struct imx_sc_pd_soc scu_pd = {
+	.pd_ranges = scu_pd_ranges,
+	.num_ranges = ARRAY_SIZE(scu_pd_ranges),
 };
 
 static struct imx_sc_ipc *pm_ipc_handle;
@@ -463,8 +463,7 @@ static int imx_sc_pd_probe(struct platform_device *pdev)
 }
 
 static const struct of_device_id imx_sc_pd_match[] = {
-	{ .compatible = "fsl,imx8qxp-scu-pd", &imx8qxp_scu_pd},
-	{ .compatible = "fsl,scu-pd", &imx8qxp_scu_pd},
+	{ .compatible = "fsl,scu-pd", &scu_pd},
 	{ /* sentinel */ }
 };
 
-- 
2.25.1



From fengquan.chen at mediatek.com  Wed Apr 21 11:17:07 2021
From: fengquan.chen at mediatek.com (Fengquan Chen)
Date: Wed, 21 Apr 2021 18:17:07 +0800
Subject: [PATCH] clocksource/drivers/timer-mediatek: optimize systimer
 irq clear flow on Mediatek Socs
In-Reply-To: <CAKz_xw2abQyS9Vvx7DUppGGd-AaDQAfdAOwi46fB9yLPJWJeUA@mail.gmail.com>
References: <1614670085-26229-1-git-send-email-Fengquan.Chen@mediatek.com>
 <1614670085-26229-2-git-send-email-Fengquan.Chen@mediatek.com>
 <CAKz_xw2abQyS9Vvx7DUppGGd-AaDQAfdAOwi46fB9yLPJWJeUA@mail.gmail.com>
Message-ID: <1619000227.25707.20.camel@mhfsdcap03>

On Tue, 2021-03-23 at 11:48 +1100, Evan Benn wrote:
> On Thu, Mar 4, 2021 at 11:07 AM Fengquan Chen
> <Fengquan.Chen at mediatek.com> wrote:
> >
> > 1)ensure systimer is enabled before clear and disable interrupt, which only
> > for systimer in Mediatek Socs.
> 
> Why does the timer need to be enabled before the interrupt can be
> disabled? The datasheet I have does not suggest that this is required.
> 

Thanks for review. For systimer, you must enable timer before clear
irq,it's a hw limitation that would be easily neglected.

> >
> > 2)clear any pending timer-irq when shutdown to keep suspend flow clean,
> > when use systimer as tick-broadcast timer
> >
> > Change-Id: Ia3eda83324af2fdaf5cbb3569a9bf020a11f8009
> > Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>
> > ---
> >  drivers/clocksource/timer-mediatek.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> > index 9318edc..9f1f095dc 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -75,6 +75,7 @@
> >  static void mtk_syst_ack_irq(struct timer_of *to)
> 
> This function seems to be mis-named. It does more than just ack the irq.
> 
> >  {
> >         /* Clear and disable interrupt */
> > +       writel(SYST_CON_EN, SYST_CON_REG(to));
> 
> This line seems to enable the timer and disable the interrupt.
> 
> >         writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
> 
> This line acks the interrupt and enables the timer and disables the interrupt.
> Are these lines both necessary?
> Maybe this function should just ack the interrupt without changing the
> other bits.

Thanks for review. 

it's necessary.

As described above,we must enable timer before clear
irq, so here is just want to ensure irq clear successfully.

We always disable irq here, and will be re-enable in
mtk_syst_clkevt_next_event.

> 
> >  }
> >
> > @@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
> >
> >  static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
> >  {
> > +       /* Clear any irq */
> > +       mtk_syst_ack_irq(to_timer_of(clkevt));
> > +
> >         /* Disable timer */
> >         writel(0, SYST_CON_REG(to_timer_of(clkevt)));
> 
> This is a third write to the same register, I believe all 3 writes can
> be combined into 1. Is that possible?

Thanks for review. 

there's a hw limitation here, we can not clear irq while timer is
disabled, and SYST_CON_EN&SYST_CON_IRQ_CLR bit must be write at the same
time or can not  write SYST_CON_IRQ_CLR bit seperately.


> 
> >
> > --
> > 1.8.1.1.dirty
> >


From fengquan.chen at mediatek.com  Wed Apr 21 11:27:28 2021
From: fengquan.chen at mediatek.com (Fengquan Chen)
Date: Wed, 21 Apr 2021 18:27:28 +0800
Subject: [PATCH] [v4, 1/1] clocksource/drivers/timer-mediatek: optimize
 systimer irq clear flow on shutdown
In-Reply-To: <4d3b342c-a14f-f4ac-6860-9f6a88a24501@linaro.org>
References: <1617960162-1988-1-git-send-email-Fengquan.Chen@mediatek.com>
 <1617960162-1988-2-git-send-email-Fengquan.Chen@mediatek.com>
 <4d3b342c-a14f-f4ac-6860-9f6a88a24501@linaro.org>
Message-ID: <1619000848.25707.27.camel@mhfsdcap03>

On Mon, 2021-04-19 at 10:44 +0200, Daniel Lezcano wrote:
> On 09/04/2021 11:22, Fengquan Chen wrote:
> > mtk_syst_clkevt_shutdown is called after irq disabled in suspend flow,
> > clear any pending systimer irq when shutdown to avoid suspend aborted
> > due to timer irq pending
> > 
> > Also as for systimer in mediatek socs, there must be firstly enable
> > timer before clear systimer irq
> > 
> > Fixes: e3af677607d9("clocksource/drivers/timer-mediatek: Add support for system timer")
> > Signed-off-by: Fengquan Chen <fengquan.chen at mediatek.com>
> > 
> > ---
> >  drivers/clocksource/timer-mediatek.c | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
> > index 9318edc..6461fd3 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -60,9 +60,9 @@
> >   * SYST_CON_EN: Clock enable. Shall be set to
> >   *   - Start timer countdown.
> >   *   - Allow timeout ticks being updated.
> > - *   - Allow changing interrupt functions.
> > + *   - Allow changing interrupt status,like clear irq pending.
> >   *
> > - * SYST_CON_IRQ_EN: Set to allow interrupt.
> > + * SYST_CON_IRQ_EN: Set to enable interrupt.
> >   *
> >   * SYST_CON_IRQ_CLR: Set to clear interrupt.
> >   */
> > @@ -75,6 +75,7 @@
> >  static void mtk_syst_ack_irq(struct timer_of *to)
> >  {
> >  	/* Clear and disable interrupt */
> > +	writel(SYST_CON_EN, SYST_CON_REG(to));
> >  	writel(SYST_CON_IRQ_CLR | SYST_CON_EN, SYST_CON_REG(to));
> >  }
> 
> IIRC, there is a hardware issue here. If it is the case, please describe
> it and refer to an errata if any.

Thanks for review.
here is just a hw config flow limitation, not a bug.

> 
> Also Evan Benn commented your code and asked a couple of questions [1],
> please answer before reposting a new version.
> 
> Comments ignored == patch ignored

Thanks. i have answered by mail before, but it didn't uploaded to the
list. has been uploaded ok now.

> 
> > @@ -111,6 +112,9 @@ static int mtk_syst_clkevt_next_event(unsigned long ticks,
> >  
> >  static int mtk_syst_clkevt_shutdown(struct clock_event_device *clkevt)
> >  {
> > +	/* Clear any irq */
> > +	mtk_syst_ack_irq(to_timer_of(clkevt));
> > +
> >  	/* Disable timer */
> >  	writel(0, SYST_CON_REG(to_timer_of(clkevt)));
> 
> Please check out the patch sent by Evan Benn [2], if you agree, ack it.
> 

Thanks

agree

> Thanks
> 
>   -- Daniel
> 
> [1] https://patchwork.kernel.org/comment/24059277/
> [2]
> https://lore.kernel.org/linux-arm-kernel/20210412132200.v3.1.I1d9917047de06715da16e1620759f703fcfdcbcb at changeid/
> 


From jbx6244 at gmail.com  Wed Apr 21 11:38:07 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 21 Apr 2021 12:38:07 +0200
Subject: [PATCH v1 5/5] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210421070115.24000-1-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421070115.24000-1-cl@rock-chips.com>
Message-ID: <cfc45d41-d16b-a643-4d13-5ff898739f02@gmail.com>

Hi Liang,

Add and convert a few more documents.

> cat rk3568.dtsi | grep compatible | sort -u
> 		compatible = "arm,armv8-timer";
> 			compatible = "arm,cortex-a55";
> 		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
> 		compatible = "arm,gic-v3";
> 		compatible = "arm,pl330", "arm,primecell";
> 		compatible = "arm,psci-1.0";
> 		compatible = "arm,scmi-shmem";
> 			compatible = "arm,scmi-smc";
> 		compatible = "fixed-clock";
> 		compatible = "operating-points-v2";

> 			compatible = "rockchip,gpio-bank";

pending

> 	compatible = "rockchip,rk3568";
> 		compatible = "rockchip,rk3568-cru";

pending

> 		compatible = "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci";
> 		compatible = "rockchip,rk3568-dw-mshc",

Keep string in one line for sdmmcX.

> 		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
> 		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";

> 		compatible = "rockchip,rk3568-pinctrl";

pending

> 		compatible = "rockchip,rk3568-pmucru";
> 		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
> 		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> 		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";

> 		compatible = "snps,dw-wdt";

Change this to:
              "rockchip,rk3568-wdt", "snps,dw-wdt"

Compatible strings should be SoC orientated.

> 			compatible = "syscon-reboot-mode";


On 4/21/21 9:01 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
> add uart/emmc/i2c/rk809 node for basic function.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/arm/rockchip.yaml     |   5 +
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 382 ++++++++++++++++++
>  3 files changed, 388 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 4a6f772c1043..d26b062a9f0e 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -560,6 +560,11 @@ properties:
>            - const: rockchip,rk3368-evb-act8846
>            - const: rockchip,rk3368
>  

> +      - description: Rockchip RK3568 Evaluation board
> +        items:
> +          - const: rockchip,rk3568-evb1-v10
> +          - const: rockchip,rk3568
> +

Move this below rockchip,rk3399-evb board.

>        - description: Rockchip RK3399 Evaluation board
>          items:
>            - const: rockchip,rk3399-evb
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index c3e00c0e2db7..7fdb41de01ec 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -51,3 +51,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> new file mode 100644
> index 000000000000..be8aae2e8c67
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> @@ -0,0 +1,382 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include "rk3568.dtsi"
> +
> +/ {
> +	model = "Rockchip RK3568 EVB1 DDR4 V10 Board";
> +	compatible = "rockchip,rk3568-evb1-v10", "rockchip,rk3568";
> +
> +	chosen: chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	dc_12v: dc-12v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "dc_12v";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +	};
> +
> +	vcc3v3_sys: vcc3v3-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&dc_12v>;
> +	};
> +
> +	vcc5v0_sys: vcc5v0-sys {
> +		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_host: vcc5v0-host-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_host_en>;
> +		regulator-name = "vcc5v0_host";
> +		regulator-always-on;
> +	};
> +
> +	vcc5v0_otg: vcc5v0-otg-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_otg_en>;
> +		regulator-name = "vcc5v0_otg";
> +	};
> +
> +	vcc3v3_lcd0_n: vcc3v3-lcd0-n {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_lcd0_n";
> +		regulator-boot-on;

Add empty line between a node.
Change all of them.

> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vcc3v3_lcd1_n: vcc3v3-lcd1-n {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_lcd1_n";
> +		regulator-boot-on;

dito

> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c0 {
> +	status = "okay";
> +
> +	rk809: pmic at 20 {
> +		compatible = "rockchip,rk809";
> +		reg = <0x20>;
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> +		pinctrl-names = "default", "pmic-sleep",
> +				"pmic-power-off", "pmic-reset";
> +		pinctrl-0 = <&pmic_int>;
> +		pinctrl-1 = <&soc_slppin_slp>, <&rk817_slppin_slp>;
> +		pinctrl-2 = <&soc_slppin_gpio>, <&rk817_slppin_pwrdn>;
> +		pinctrl-3 = <&soc_slppin_gpio>, <&rk817_slppin_rst>;
> +
> +		rockchip,system-power-controller;
> +		wakeup-source;
> +		#clock-cells = <1>;
> +		clock-output-names = "rk808-clkout1", "rk808-clkout2";

> +		//fb-inner-reg-idxs = <2>;
> +		/* 1: rst regs (default in codes), 0: rst the pmic */

Where is documented?

> +		pmic-reset-func = <0>;

Where is documented?

> +
> +		vcc1-supply = <&vcc3v3_sys>;
> +		vcc2-supply = <&vcc3v3_sys>;
> +		vcc3-supply = <&vcc3v3_sys>;
> +		vcc4-supply = <&vcc3v3_sys>;
> +		vcc5-supply = <&vcc3v3_sys>;
> +		vcc6-supply = <&vcc3v3_sys>;
> +		vcc7-supply = <&vcc3v3_sys>;
> +		vcc8-supply = <&vcc3v3_sys>;
> +		vcc9-supply = <&vcc3v3_sys>;
> +

> +		pwrkey {
> +			status = "okay";
> +		};
> +

Where is documented?

> +		pinctrl_rk8xx: pinctrl_rk8xx {
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +
> +			rk817_slppin_null: rk817_slppin_null {
> +				pins = "gpio_slp";
> +				function = "pin_fun0";
> +			};
> +
> +			rk817_slppin_slp: rk817_slppin_slp {
> +				pins = "gpio_slp";
> +				function = "pin_fun1";
> +			};
> +
> +			rk817_slppin_pwrdn: rk817_slppin_pwrdn {
> +				pins = "gpio_slp";
> +				function = "pin_fun2";
> +			};
> +
> +			rk817_slppin_rst: rk817_slppin_rst {
> +				pins = "gpio_slp";
> +				function = "pin_fun3";
> +			};
> +		};


Where is documented?

> +
> +		regulators {
> +			vdd_logic: DCDC_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-init-microvolt = <900000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;

> +				regulator-name = "vdd_logic";

regulator-name above all other regulator properties.
Change all of them.

> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_gpu: DCDC_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-init-microvolt = <900000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_gpu";
> +				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;
> +				};
> +			};
> +
> +			vdd_npu: DCDC_REG4 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <500000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-init-microvolt = <900000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-initial-mode = <0x2>;
> +				regulator-name = "vdd_npu";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdda0v9_image: LDO_REG1 {
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda0v9_image";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdda_0v9: LDO_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <900000>;
> +				regulator-max-microvolt = <900000>;
> +				regulator-name = "vdda_0v9";
> +				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;
> +					regulator-suspend-microvolt = <900000>;
> +				};
> +			};
> +
> +			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;
> +					regulator-suspend-microvolt = <3300000>;
> +				};
> +			};
> +
> +			vcca_1v8: LDO_REG7 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcca_1v8";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcca1v8_pmu: LDO_REG8 {
> +				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;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcca1v8_image: LDO_REG9 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-name = "vcca1v8_image";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: DCDC_REG5 {
> +				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;
> +				};
> +			};
> +
> +			vcc_3v3: SWITCH_REG1 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vcc_3v3";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_sd: SWITCH_REG2 {
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-name = "vcc3v3_sd";
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +
> +&pinctrl {
> +	pmic {
> +		pmic_int: pmic_int {
> +			rockchip,pins =
> +				<0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +
> +		soc_slppin_gpio: soc_slppin_gpio {
> +			rockchip,pins =
> +				<0 RK_PA2 RK_FUNC_GPIO &pcfg_output_low>;
> +		};
> +
> +		soc_slppin_slp: soc_slppin_slp {
> +			rockchip,pins =
> +				<0 RK_PA2 1 &pcfg_pull_none>;
> +		};
> +
> +		soc_slppin_rst: soc_slppin_rst {
> +			rockchip,pins =
> +				<0 RK_PA2 2 &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {

> +		vcc5v0_host_en: vcc5v0-host-en {
> +			rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		vcc5v0_otg_en: vcc5v0-otg-en {
> +			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;


Keep the same indent as in pmic and rk3568.dtsi for rockchip,pins

> +		};
> +	};
> +};
> +
> +&sdhci {
> +	bus-width = <8>;

> +	non-removable;
> +	rockchip,txclk-tapnum = <0x8>;
> +	max-frequency = <200000000>;

sort

> +	status = "okay";
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> 



From anshuman.khandual at arm.com  Wed Apr 21 11:49:15 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 16:19:15 +0530
Subject: [PATCH v2 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <20210421065108.1987-2-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-2-rppt@kernel.org>
Message-ID: <d31ff896-ea1c-d47c-0d11-34fdcd3b7ad8@arm.com>

On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> Add comment describing the semantics of pfn_valid() that clarifies that
> pfn_valid() only checks for availability of a memory map entry (i.e. struct
> page) for a PFN rather than availability of usable memory backing that PFN.
> 
> The most "generic" version of pfn_valid() used by the configurations with
> SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
> suitable place for documentation about semantics of pfn_valid().
> 
> Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>

Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>

> ---
>  include/linux/mmzone.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 47946cec7584..961f0eeefb62 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>  #endif
>  
>  #ifndef CONFIG_HAVE_ARCH_PFN_VALID
> +/**
> + * pfn_valid - check if there is a valid memory map entry for a PFN
> + * @pfn: the page frame number to check
> + *
> + * Check if there is a valid memory map entry aka struct page for the @pfn.
> + * Note, that availability of the memory map entry does not imply that
> + * there is actual usable memory at that @pfn. The struct page may
> + * represent a hole or an unusable page frame.
> + *
> + * Return: 1 for PFNs that have memory map entries and 0 otherwise
> + */
>  static inline int pfn_valid(unsigned long pfn)
>  {
>  	struct mem_section *ms;
> 


From anshuman.khandual at arm.com  Wed Apr 21 11:51:55 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 16:21:55 +0530
Subject: [PATCH v2 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210421065108.1987-3-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-3-rppt@kernel.org>
Message-ID: <4d3844f1-3cb2-32cb-5222-ed023843970e@arm.com>


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
> page allocator.
> 
> The struct pages for MEMBLOCK_NOMAP regions are kept with the default
> values set by the memory map initialization which makes it necessary to
> have a special treatment for such pages in pfn_valid() and
> pfn_valid_within().
> 
> Split out initialization of the reserved pages to a function with a
> meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
> reserved regions and mark struct pages for the NOMAP regions as
> PageReserved.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  include/linux/memblock.h |  4 +++-
>  mm/memblock.c            | 28 ++++++++++++++++++++++++++--
>  2 files changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5984fff3f175..634c1a578db8 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
>   * @MEMBLOCK_NONE: no special request
>   * @MEMBLOCK_HOTPLUG: hotpluggable region
>   * @MEMBLOCK_MIRROR: mirrored region
> - * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
> + * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
> + * reserved in the memory map; refer to memblock_mark_nomap() description
> + * for futher details

Small nit - s/futher/further

>   */
>  enum memblock_flags {
>  	MEMBLOCK_NONE		= 0x0,	/* No special request */
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..3abf2c3fea7f 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
>   * @base: the base phys addr of the region
>   * @size: the size of the region
>   *
> + * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
> + * direct mapping of the physical memory. These regions will still be
> + * covered by the memory map. The struct page representing NOMAP memory
> + * frames in the memory map will be PageReserved()
> + *
>   * Return: 0 on success, -errno on failure.
>   */
>  int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
> @@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>  	return end_pfn - start_pfn;
>  }
>  
> +static void __init memmap_init_reserved_pages(void)
> +{
> +	struct memblock_region *region;
> +	phys_addr_t start, end;
> +	u64 i;
> +
> +	/* initialize struct pages for the reserved regions */
> +	for_each_reserved_mem_range(i, &start, &end)
> +		reserve_bootmem_region(start, end);
> +
> +	/* and also treat struct pages for the NOMAP regions as PageReserved */
> +	for_each_mem_region(region) {
> +		if (memblock_is_nomap(region)) {
> +			start = region->base;
> +			end = start + region->size;
> +			reserve_bootmem_region(start, end);
> +		}
> +	}

I guess there is no possible method to unify both these loops.

> +}
> +
>  static unsigned long __init free_low_memory_core_early(void)
>  {
>  	unsigned long count = 0;
> @@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
>  
>  	memblock_clear_hotplug(0, -1);
>  
> -	for_each_reserved_mem_range(i, &start, &end)
> -		reserve_bootmem_region(start, end);
> +	memmap_init_reserved_pages();
>  
>  	/*
>  	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
> 


Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>


From jiapeng.chong at linux.alibaba.com  Wed Apr 21 11:56:53 2021
From: jiapeng.chong at linux.alibaba.com (Jiapeng Chong)
Date: Wed, 21 Apr 2021 18:56:53 +0800
Subject: [PATCH v2] soc: fsl: qe: Remove unused function
Message-ID: <1619002613-18216-1-git-send-email-jiapeng.chong@linux.alibaba.com>

The last callers of this function were removed by commit d7c2878cfcfa
("soc: fsl: qe: remove unused qe_ic_set_* functions"):
https://github.com/torvalds/linux/commit/d7c2878cfcfa

Fix the following clang warning:

drivers/soc/fsl/qe/qe_ic.c:234:29: warning: unused function
'qe_ic_from_irq' [-Wunused-function].

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
---
Changes in v2:
  - Modified submission information.

 drivers/soc/fsl/qe/qe_ic.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 0390af9..b573712 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -231,11 +231,6 @@ static inline void qe_ic_write(__be32  __iomem *base, unsigned int reg,
 	qe_iowrite32be(value, base + (reg >> 2));
 }
 
-static inline struct qe_ic *qe_ic_from_irq(unsigned int virq)
-{
-	return irq_get_chip_data(virq);
-}
-
 static inline struct qe_ic *qe_ic_from_irq_data(struct irq_data *d)
 {
 	return irq_data_get_irq_chip_data(d);
-- 
1.8.3.1



From maz at kernel.org  Wed Apr 21 11:58:40 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 11:58:40 +0100
Subject: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts
In-Reply-To: <YH9G3+aDUWpcLCpD@xps13.dannf>
References: <20200519161755.209565-1-maz@kernel.org>
 <20200519161755.209565-9-maz@kernel.org>
 <YH87dtTfwYgavusz@xps13.dannf> <YH9G3+aDUWpcLCpD@xps13.dannf>
Message-ID: <8735vjrjj3.wl-maz@kernel.org>

Hi Dan,n

On Tue, 20 Apr 2021 22:25:51 +0100,
dann frazier <dann.frazier at canonical.com> wrote:
> 
> On Tue, Apr 20, 2021 at 02:37:10PM -0600, dann frazier wrote:
> > On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> > > Change the way we deal with GIC SGIs by turning them into proper
> > > IRQs, and calling into the arch code to register the interrupt range
> > > instead of a callback.
> > > 
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > 
> > hey Marc,
> > 
> >   I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
> > CN88XX) down to this commit, but only when running in ACPI mode. See below:
> > 
> > 
> > EFI stub: Booting Linux Kernel...
> > EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
> > [    0.000000] Linux version 5.11.0-13-generic (buildd at bos02-arm64-067) (gcc (Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 5.11.0-13.14-generic 5.11.7)
> 
> Sorry, realized I posted a log from an Ubuntu kernel. Here's an
> upstream one:

[...]

> 
> [    7.842174] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
> [    7.849699] io scheduler mq-deadline registered
> [    7.857591] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> [    7.865127] efifb: probing for efifb
> [    7.868738] efifb: No BGRT, not showing boot graphics
> [    7.873783] efifb: framebuffer at 0x881010000000, using 3072k, total 3072k
> [    7.880649] efifb: mode is 1024x768x32, linelength=4096, pages=1
> [    7.886647] efifb: scrolling: redraw
> [    7.890212] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [    7.895905] fbcon: Deferring console take-over
> [    7.900350] fb0: EFI VGA frame buffer device
> [    7.905289] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
> [    7.913714] ACPI: button: Power Button [PWRB]
> [    7.919549] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
> [    7.927289] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
> [    7.936326] Mem abort info:
> [    7.939108]   ESR = 0x96000004
> [    7.942151]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    7.947451]   SET = 0, FnV = 0
> [    7.950494]   EA = 0, S1PTW = 0
> [    7.953624] Data abort info:
> [    7.956492]   ISV = 0, ISS = 0x00000004
> [    7.960316]   CM = 0, WnR = 0
> [    7.963273] [0000000000000028] user address but active_mm is swapper
> [    7.969616] Internal error: Oops: 96000004 [#1] SMP
> [    7.974483] Modules linked in:
> [    7.977531] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8 #19
> [    7.983874] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
> [    7.990737] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
> [    7.996732] pc : __ipi_send_mask+0x60/0x114
> [    8.000910] lr : smp_cross_call+0x40/0xcc
> [    8.004913] sp : ffff800012753c10
> [    8.008216] x29: ffff800012753c10 x28: ffff000100de5d00 
> [    8.013521] x27: 000000000000000a x26: ffff80001225da20 
> [    8.018825] x25: 0000000000000000 x24: ffff000ff62719b0 
> [    8.024129] x23: ffff80001225d000 x22: ffff800012368108 
> [    8.029433] x21: ffff800010f69a20 x20: 0000000000000000 
> [    8.034737] x19: ffff000100143c60 x18: 0000000000000020 
> [    8.040041] x17: 000000008e74252f x16: 00000000bf0ab2ad 
> [    8.045345] x15: ffffffffffffffff x14: 0000000000000000 
> [    8.050649] x13: 003d090000000000 x12: 00003d0900000000 
> [    8.055953] x11: 0000000000000000 x10: 00003d0900000000 
> [    8.061257] x9 : ffff800010027f14 x8 : 0000000000000000 
> [    8.066561] x7 : 00000000ffffffff x6 : ffff000ff6148698 
> [    8.071865] x5 : ffff80001159d040 x4 : ffff80001159d110 
> [    8.077169] x3 : ffff800010f69a00 x2 : 0000000000000000 
> [    8.082473] x1 : ffff800010f69a20 x0 : 0000000000000000 
> [    8.087777] Call trace:
> [    8.090213]  __ipi_send_mask+0x60/0x114
> [    8.094038]  smp_cross_call+0x40/0xcc
> [    8.097691]  smp_send_reschedule+0x3c/0x50
> [    8.101778]  resched_curr+0x5c/0xb0
> [    8.105258]  check_preempt_curr+0x58/0x90
> [    8.109258]  ttwu_do_wakeup+0x2c/0x190
> [    8.112996]  ttwu_do_activate+0x7c/0x114
> [    8.116909]  try_to_wake_up+0x388/0x670
> [    8.120735]  wake_up_process+0x24/0x30
> [    8.124474]  swake_up_one+0x48/0x9c
> [    8.127953]  rcu_gp_kthread_wake+0x68/0x8c
> [    8.132041]  rcu_accelerate_cbs_unlocked+0xb4/0xf0
> [    8.136822]  rcu_core+0x520/0x694
> [    8.140128]  rcu_core_si+0x1c/0x2c
> [    8.143520]  __do_softirq+0x128/0x388
> [    8.147172]  irq_exit+0xc4/0xec
> [    8.150304]  __handle_domain_irq+0x8c/0xec
> [    8.154394]  gic_handle_irq+0xd8/0x2f0
> [    8.158132]  el1_irq+0xc0/0x180
> [    8.161262]  __pi_strcmp+0x20/0x158
> [    8.164742]  driver_register+0x68/0x140
> [    8.168571]  __platform_driver_register+0x34/0x40
> [    8.173265]  imx8mp_clk_driver_init+0x28/0x34
> [    8.177614]  do_one_initcall+0x50/0x260
> [    8.181440]  kernel_init_freeable+0x24c/0x2d4
> [    8.185790]  kernel_init+0x20/0x134
> [    8.189271]  ret_from_fork+0x10/0x18
> [    8.192840] Code: a90363f7 aa0103f5 d0010957 f9401260 (b9402800) 
> [    8.198955] ---[ end trace c24172add816c1f0 ]---
> [    8.203562] Kernel panic - not syncing: Oops: Fatal exception in interrupt
> [    8.210442] SMP: stopping secondary CPUs
> [    9.258360] SMP: failed to stop secondary CPUs 0,9
> [    9.263141] Kernel Offset: disabled
> [    9.266617] CPU features: 0x00040002,69101108
> [    9.270963] Memory Limit: none
> [    9.274024] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Please feed this stacktrace to scripts/decode_stacktrace.sh so that I
can get an idea about what is going wrong. I bet something is playing
ungodly games with the one of the IPIs, and things go horribly wrong.

Now, here's a hunch: in the fine TX1 tradition, the firmware is broken
and the GTDT table looks unusable. Amusingly, the crash happens right
after the SBSA watchdog fails to probe.

And looking at the code that implements that driver, it looks dodgy as
hell, as it unmaps an interrupt it doesn't even know is valid. And it
does that right when the driver fails the way you experienced it. If,
by any chance, the interrupt field is 0 in the firmware table, this
results in SGI0 being unmapped. Given that this is the rescheduling
interrupt, fireworks happen.

Can you have a go with the patchlet below, and let me know if that
helps?

Thanks,

	M.

diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index f2d0e5915dab..0a0a982f9c28 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -329,7 +329,7 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 					int index)
 {
 	struct platform_device *pdev;
-	int irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+	int irq;
 
 	/*
 	 * According to SBSA specification the size of refresh and control
@@ -338,7 +338,7 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 	struct resource res[] = {
 		DEFINE_RES_MEM(wd->control_frame_address, SZ_4K),
 		DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K),
-		DEFINE_RES_IRQ(irq),
+		{},
 	};
 	int nr_res = ARRAY_SIZE(res);
 
@@ -348,10 +348,11 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 
 	if (!(wd->refresh_frame_address && wd->control_frame_address)) {
 		pr_err(FW_BUG "failed to get the Watchdog base address.\n");
-		acpi_unregister_gsi(wd->timer_interrupt);
 		return -EINVAL;
 	}
 
+	irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+	res[2] = (struct resource)DEFINE_RES_IRQ(irq);
 	if (irq <= 0) {
 		pr_warn("failed to map the Watchdog interrupt.\n");
 		nr_res--;
@@ -364,7 +365,8 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 	 */
 	pdev = platform_device_register_simple("sbsa-gwdt", index, res, nr_res);
 	if (IS_ERR(pdev)) {
-		acpi_unregister_gsi(wd->timer_interrupt);
+		if (irq > 0)
+			acpi_unregister_gsi(wd->timer_interrupt);
 		return PTR_ERR(pdev);
 	}
 

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


From anshuman.khandual at arm.com  Wed Apr 21 11:59:48 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 16:29:48 +0530
Subject: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210421065108.1987-4-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-4-rppt@kernel.org>
Message-ID: <0a7cc0d4-5d3d-7d6d-f4c3-bb2965b810e6@arm.com>


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
> 
> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> linear map vs those that require ioremap() to access them.
> 
> Introduce a dedicated pfn_is_map_memory() wrapper for
> memblock_is_map_memory() to perform such check and use it where
> appropriate.
> 
> Using a wrapper allows to avoid cyclic include dependencies.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  arch/arm64/include/asm/memory.h |  2 +-
>  arch/arm64/include/asm/page.h   |  1 +
>  arch/arm64/kvm/mmu.c            |  2 +-
>  arch/arm64/mm/init.c            | 11 +++++++++++
>  arch/arm64/mm/ioremap.c         |  4 ++--
>  arch/arm64/mm/mmu.c             |  2 +-
>  6 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..194f9f993d30 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>  
>  #define virt_addr_valid(addr)	({					\
>  	__typeof__(addr) __addr = __tag_reset(addr);			\
> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>  })
>  
>  void dump_mem_limit(void);
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 012cffc574e8..99a6da91f870 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>  typedef struct page *pgtable_t;
>  
>  extern int pfn_valid(unsigned long);
> +extern int pfn_is_map_memory(unsigned long);

Check patch is complaining about this.

WARNING: function definition argument 'unsigned long' should also have an identifier name
#50: FILE: arch/arm64/include/asm/page.h:41:
+extern int pfn_is_map_memory(unsigned long);


>  
>  #include <asm/memory.h>
>  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..23dd99e29b23 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>  
>  static bool kvm_is_device_pfn(unsigned long pfn)
>  {
> -	return !pfn_valid(pfn);
> +	return !pfn_is_map_memory(pfn);
>  }
>  
>  /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..dc03bdc12c0f 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> +int pfn_is_map_memory(unsigned long pfn)
> +{
> +	phys_addr_t addr = PFN_PHYS(pfn);
> +

Should also bring with it, the comment regarding upper bits in
the pfn from arm64 pfn_valid().

> +	if (PHYS_PFN(addr) != pfn)
> +		return 0;
> +	

 ^^^^^ trailing spaces here.

ERROR: trailing whitespace
#81: FILE: arch/arm64/mm/init.c:263:
+^I$

> +	return memblock_is_map_memory(addr);
> +}
> +EXPORT_SYMBOL(pfn_is_map_memory);
> +

Is the EXPORT_SYMBOL() required to build drivers which will use
pfn_is_map_memory() but currently use pfn_valid() ?


From anshuman.khandual at arm.com  Wed Apr 21 12:06:46 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 16:36:46 +0530
Subject: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210421065108.1987-5-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-5-rppt@kernel.org>
Message-ID: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>


On 4/21/21 12:21 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
> 
> * Parts of the memory map are freed during boot. This makes it necessary to
>   verify that there is actual physical memory that corresponds to a pfn
>   which is done by querying memblock.
> 
> * There are NOMAP memory regions. These regions are not mapped in the
>   linear map and until the previous commit the struct pages representing
>   these areas had default values.
> 
> As the consequence of absence of the special treatment of NOMAP regions in
> the memory map it was necessary to use memblock_is_map_memory() in
> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> generic mm functionality would not treat a NOMAP page as a normal page.
> 
> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> the rest of core mm will treat them as unusable memory and thus
> pfn_valid_within() is no longer required at all and can be disabled by
> removing CONFIG_HOLES_IN_ZONE on arm64.

This makes sense.

> 
> pfn_valid() can be slightly simplified by replacing
> memblock_is_map_memory() with memblock_is_memory().
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>  arch/arm64/Kconfig   | 3 ---
>  arch/arm64/mm/init.c | 4 ++--
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e4e1b6550115..58e439046d05 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>  	def_bool y
>  	depends on NUMA
>  
> -config HOLES_IN_ZONE
> -	def_bool y
> -

Right.

>  source "kernel/Kconfig.hz"
>  
>  config ARCH_SPARSEMEM_ENABLE
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index dc03bdc12c0f..eb3f56fb8c7c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>  
>  	/*
>  	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> +	 * memblock_is_memory() check for ZONE_DEVICE based
>  	 * addresses will always fail. Even the normal hotplugged
>  	 * memory will never have MEMBLOCK_NOMAP flag set in their
>  	 * memblock entries. Skip memblock search for all non early
> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>  		return pfn_section_valid(ms, pfn);
>  }
>  #endif
> -	return memblock_is_map_memory(addr);
> +	return memblock_is_memory(addr);

Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
memory pfns for page table walking purpose but with PageReserved(),
why memblock_is_memory() is still required ? At this point, should
not we just return valid for early_section() memory. As pfn_valid()
now just implies that pfn has a struct page backing which has been
already verified with valid_section() etc.

>  }
>  EXPORT_SYMBOL(pfn_valid);
>  
> 


From sumit.garg at linaro.org  Wed Apr 21 12:08:13 2021
From: sumit.garg at linaro.org (Sumit Garg)
Date: Wed, 21 Apr 2021 16:38:13 +0530
Subject: [PATCH v9 1/4] KEYS: trusted: Add generic trusted keys framework
In-Reply-To: <65dcc9fa28833e6beb1eadf98b0ed3402404d693.camel@linux.ibm.com>
References: <20210301131127.793707-1-sumit.garg@linaro.org>
 <20210301131127.793707-2-sumit.garg@linaro.org>
 <65dcc9fa28833e6beb1eadf98b0ed3402404d693.camel@linux.ibm.com>
Message-ID: <CAFA6WYOzD-qhHrcnzvd9P7iFvEqWwf0NCKXrgrEgvnB5i_-SxQ@mail.gmail.com>

Hi James,

On Wed, 21 Apr 2021 at 04:47, James Bottomley <jejb at linux.ibm.com> wrote:
>
> On Mon, 2021-03-01 at 18:41 +0530, Sumit Garg wrote:
> > Current trusted keys framework is tightly coupled to use TPM device
> > as an underlying implementation which makes it difficult for
> > implementations like Trusted Execution Environment (TEE) etc. to
> > provide trusted keys support in case platform doesn't posses a TPM
> > device.
> >
> > Add a generic trusted keys framework where underlying implementations
> > can be easily plugged in. Create struct trusted_key_ops to achieve
> > this, which contains necessary functions of a backend.
> >
> > Also, define a module parameter in order to select a particular trust
> > source in case a platform support multiple trust sources. In case its
> > not specified then implementation itetrates through trust sources
> > list starting with TPM and assign the first trust source as a backend
> > which has initiazed successfully during iteration.
> >
> > Note that current implementation only supports a single trust source
> > at runtime which is either selectable at compile time or during boot
> > via aforementioned module parameter.
>
> You never actually tested this, did you?  I'm now getting EINVAL from
> all the trusted TPM key operations because of this patch.
>

Unfortunately, I don't possess a development machine with a TPM
device. So mine testing was entirely based on TEE as a backend which
doesn't support any optional parameters. And that being the reason I
didn't catch this issue at first instance.

Is there any TPM emulation environment available that I can use for testing?

> The reason is quite simple:  this function:
>
> > index 000000000000..0db86b44605d
> > --- /dev/null
> > +++ b/security/keys/trusted-keys/trusted_core.c
> [...]
> > +static int datablob_parse(char *datablob, struct trusted_key_payload
> > *p)
> > +{
> > +     substring_t args[MAX_OPT_ARGS];
> > +     long keylen;
> > +     int ret = -EINVAL;
> > +     int key_cmd;
> > +     char *c;
> > +
> > +     /* main command */
> > +     c = strsep(&datablob, " \t");
>
> Modifies its argument to consume tokens and separates them with NULL.
>
> so the arguments for
>
> keyctl add trusted kmk "new 34 keyhandle=0x81000001"
>
> Go into this function as
>
> datablob="new 34 keyhandle=0x81000001"
>
> After we leave it, it looks like
>
> datablob="new\034\0keyhandle=0x81000001"
>
> However here:
>
> > +static int trusted_instantiate(struct key *key,
> > +                            struct key_preparsed_payload *prep)
> > +{
> > +     struct trusted_key_payload *payload = NULL;
> > +     size_t datalen = prep->datalen;
> > +     char *datablob;
> > +     int ret = 0;
> > +     int key_cmd;
> > +     size_t key_len;
> > +
> > +     if (datalen <= 0 || datalen > 32767 || !prep->data)
> > +             return -EINVAL;
> > +
> > +     datablob = kmalloc(datalen + 1, GFP_KERNEL);
> > +     if (!datablob)
> > +             return -ENOMEM;
> > +     memcpy(datablob, prep->data, datalen);
> > +     datablob[datalen] = '\0';
> > +
> > +     payload = trusted_payload_alloc(key);
> > +     if (!payload) {
> > +             ret = -ENOMEM;
> > +             goto out;
> > +     }
> > +
> > +     key_cmd = datablob_parse(datablob, payload);
> > +     if (key_cmd < 0) {
> > +             ret = key_cmd;
> > +             goto out;
> > +     }
> > +
> > +     dump_payload(payload);
> > +
> > +     switch (key_cmd) {
> > +     case Opt_load:
> > +             ret = static_call(trusted_key_unseal)(payload,
> > datablob);
>
> We're passing the unmodified
>
> datablob="new\034\0keyhandle=0x81000001"
>
> Into the tpm trusted_key_unseal function.  However, it only sees "new"
> and promply gives EINVAL because you've removed the ability to process
> the new option from it.  What should have happened is you should have
> moved data blob up to passed the consumed tokens, so it actually reads
>
> datablob="keyhandle=0x81000001"
>
> However, to do that you'd have to have the updated pointer passed out
> of your datablob_parse() above.

Thanks for the detailed explanation.

>
> There's also a lost !tpm2 in the check for options->keyhandle, but I
> suspect Jarkko lost that merging the two patches.  I think what's below
> fixes all of this, so if you can test it for trusted_tee, I'll package
> it up as two separate patches fixing all of this.
>

Below fixes look good to me and I have tested them using TEE as a
backend too. So feel free to add:

Tested-by: Sumit Garg <sumit.garg at linaro.org>

-Sumit

> James
>
> ---
>
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index ec3a066a4b42..7c636212429b 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -62,7 +62,7 @@ static const match_table_t key_tokens = {
>   *
>   * On success returns 0, otherwise -EINVAL.
>   */
> -static int datablob_parse(char *datablob, struct trusted_key_payload *p)
> +static int datablob_parse(char **datablob, struct trusted_key_payload *p)
>  {
>         substring_t args[MAX_OPT_ARGS];
>         long keylen;
> @@ -71,14 +71,14 @@ static int datablob_parse(char *datablob, struct trusted_key_payload *p)
>         char *c;
>
>         /* main command */
> -       c = strsep(&datablob, " \t");
> +       c = strsep(datablob, " \t");
>         if (!c)
>                 return -EINVAL;
>         key_cmd = match_token(c, key_tokens, args);
>         switch (key_cmd) {
>         case Opt_new:
>                 /* first argument is key size */
> -               c = strsep(&datablob, " \t");
> +               c = strsep(datablob, " \t");
>                 if (!c)
>                         return -EINVAL;
>                 ret = kstrtol(c, 10, &keylen);
> @@ -89,7 +89,7 @@ static int datablob_parse(char *datablob, struct trusted_key_payload *p)
>                 break;
>         case Opt_load:
>                 /* first argument is sealed blob */
> -               c = strsep(&datablob, " \t");
> +               c = strsep(datablob, " \t");
>                 if (!c)
>                         return -EINVAL;
>                 p->blob_len = strlen(c) / 2;
> @@ -138,7 +138,7 @@ static int trusted_instantiate(struct key *key,
>  {
>         struct trusted_key_payload *payload = NULL;
>         size_t datalen = prep->datalen;
> -       char *datablob;
> +       char *datablob, *orig_datablob;
>         int ret = 0;
>         int key_cmd;
>         size_t key_len;
> @@ -146,7 +146,7 @@ static int trusted_instantiate(struct key *key,
>         if (datalen <= 0 || datalen > 32767 || !prep->data)
>                 return -EINVAL;
>
> -       datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +       orig_datablob = datablob = kmalloc(datalen + 1, GFP_KERNEL);
>         if (!datablob)
>                 return -ENOMEM;
>         memcpy(datablob, prep->data, datalen);
> @@ -158,7 +158,7 @@ static int trusted_instantiate(struct key *key,
>                 goto out;
>         }
>
> -       key_cmd = datablob_parse(datablob, payload);
> +       key_cmd = datablob_parse(&datablob, payload);
>         if (key_cmd < 0) {
>                 ret = key_cmd;
>                 goto out;
> @@ -194,7 +194,7 @@ static int trusted_instantiate(struct key *key,
>                 ret = -EINVAL;
>         }
>  out:
> -       kfree_sensitive(datablob);
> +       kfree_sensitive(orig_datablob);
>         if (!ret)
>                 rcu_assign_keypointer(key, payload);
>         else
> @@ -218,7 +218,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
>         struct trusted_key_payload *p;
>         struct trusted_key_payload *new_p;
>         size_t datalen = prep->datalen;
> -       char *datablob;
> +       char *datablob, *orig_datablob;
>         int ret = 0;
>
>         if (key_is_negative(key))
> @@ -229,7 +229,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
>         if (datalen <= 0 || datalen > 32767 || !prep->data)
>                 return -EINVAL;
>
> -       datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +       orig_datablob = datablob = kmalloc(datalen + 1, GFP_KERNEL);
>         if (!datablob)
>                 return -ENOMEM;
>
> @@ -241,7 +241,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
>
>         memcpy(datablob, prep->data, datalen);
>         datablob[datalen] = '\0';
> -       ret = datablob_parse(datablob, new_p);
> +       ret = datablob_parse(&datablob, new_p);
>         if (ret != Opt_update) {
>                 ret = -EINVAL;
>                 kfree_sensitive(new_p);
> @@ -265,7 +265,7 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
>         rcu_assign_keypointer(key, new_p);
>         call_rcu(&p->rcu, trusted_rcu_free);
>  out:
> -       kfree_sensitive(datablob);
> +       kfree_sensitive(orig_datablob);
>         return ret;
>  }
>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 4e5c50138f92..bc702ba0a596 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -747,6 +747,9 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
>
>         opt->hash = tpm2 ? HASH_ALGO_SHA256 : HASH_ALGO_SHA1;
>
> +       if (!c)
> +               return 0;
> +
>         while ((p = strsep(&c, " \t"))) {
>                 if (*p == '\0' || *p == ' ' || *p == '\t')
>                         continue;
> @@ -944,7 +947,7 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
>                 goto out;
>         dump_options(options);
>
> -       if (!options->keyhandle) {
> +       if (!options->keyhandle && !tpm2) {
>                 ret = -EINVAL;
>                 goto out;
>         }
>
>


From laurentiu.palcu at oss.nxp.com  Wed Apr 21 12:15:24 2021
From: laurentiu.palcu at oss.nxp.com (Laurentiu Palcu)
Date: Wed, 21 Apr 2021 14:15:24 +0300
Subject: [PATCH v9 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM
 driver
In-Reply-To: <1616997446-8783-7-git-send-email-victor.liu@nxp.com>
References: <1616997446-8783-1-git-send-email-victor.liu@nxp.com>
 <1616997446-8783-7-git-send-email-victor.liu@nxp.com>
Message-ID: <20210421111524.74ylexgsgkojfwwf@fsr-ub1864-141>

Hi,

On Mon, Mar 29, 2021 at 01:57:26PM +0800, Liu Ying wrote:
> Add myself as the maintainer of the i.MX8qxp DPU DRM driver.
> 
> Signed-off-by: Liu Ying <victor.liu at nxp.com>

Acked-by: Laurentiu Palcu <laurentiu.palcu at oss.nxp.com>

Thanks,
laurentiu

> ---
> v8->v9:
> * No change.
> 
> v7->v8:
> * No change.
> 
> v6->v7:
> * No change.
> 
> v5->v6:
> * No change.
> 
> v4->v5:
> * No change.
> 
> v3->v4:
> * No change.
> 
> v2->v3:
> * No change.
> 
> v1->v2:
> * No change.
> 
>  MAINTAINERS | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a247285..ec82d42 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5946,6 +5946,15 @@ F:	Documentation/devicetree/bindings/display/imx/
>  F:	drivers/gpu/drm/imx/
>  F:	drivers/gpu/ipu-v3/
>  
> +DRM DRIVERS FOR FREESCALE i.MX8QXP
> +M:	Liu Ying <victor.liu at nxp.com>
> +L:	dri-devel at lists.freedesktop.org
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
> +F:	Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml
> +F:	Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
> +F:	drivers/gpu/drm/imx/dpu/
> +
>  DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
>  M:	Patrik Jakobsson <patrik.r.jakobsson at gmail.com>
>  L:	dri-devel at lists.freedesktop.org
> -- 
> 2.7.4
> 


From jwboyer at kernel.org  Wed Apr 21 12:18:46 2021
From: jwboyer at kernel.org (Josh Boyer)
Date: Wed, 21 Apr 2021 07:18:46 -0400
Subject: Request to update venus-5.10 FW files
In-Reply-To: <8885c6fbfcc91043a5406cf6e528e0b9@codeaurora.org>
References: <8885c6fbfcc91043a5406cf6e528e0b9@codeaurora.org>
Message-ID: <CA+5PVA7pbgVRpwkM71ToxRwBKfH=j51GrZcz+8Q5H2MpmmL-_w@mail.gmail.com>

On Wed, Apr 21, 2021 at 2:59 AM <smagar at codeaurora.org> wrote:
>
> Hello Team,
>
> Please include updated firmware bins for venus-5.10.
>
> Snapshot of pull request is as below, let me know if anything is
> missing.
>
>
>
> The following changes since commit
> 5c893c65b862906a627cea238ae8c2d099027dee:
>
>    Updated Venus firmware files for v5.10 (2021-04-20 11:48:28 +0530)
>
> are available in the git repository at:
>
>    https://github.com/suraj714/linux-firmware-venus.git master
>
> for you to fetch changes up to 2565c9d2576ce1275206483e106d6fb627ace042:
>
>    qcom :venus_v5.10: updated venus firmware files for v5.10 (2021-04-21
> 12:04:59 +0530)
>
> ----------------------------------------------------------------
> smagar (1):
>        qcom :venus_v5.10: updated venus firmware files for v5.10
>
>   qcom/sc7280/vpu20_1v.b00          | Bin 0 -> 692 bytes
>   qcom/sc7280/vpu20_1v.b01          | Bin 0 -> 7376 bytes
>   qcom/sc7280/vpu20_1v.b02          | Bin 0 -> 300 bytes
>   qcom/sc7280/vpu20_1v.b03          | Bin 0 -> 20 bytes
>   qcom/sc7280/vpu20_1v.b04          | Bin 0 -> 20 bytes
>   qcom/sc7280/vpu20_1v.b05          | Bin 0 -> 20 bytes
>   qcom/sc7280/vpu20_1v.b06          | Bin 0 -> 20 bytes
>   qcom/sc7280/vpu20_1v.b07          | Bin 0 -> 24 bytes
>   qcom/sc7280/vpu20_1v.b08          | Bin 0 -> 16 bytes
>   qcom/sc7280/vpu20_1v.b09          | Bin 0 -> 939184 bytes
>   qcom/sc7280/vpu20_1v.b10          | Bin 0 -> 42976 bytes
>   qcom/sc7280/vpu20_1v.b11          |   0
>   qcom/sc7280/vpu20_1v.b12          |   0
>   qcom/sc7280/vpu20_1v.b13          |   0
>   qcom/sc7280/vpu20_1v.b14          |   0
>   qcom/sc7280/vpu20_1v.b15          |   0
>   qcom/sc7280/vpu20_1v.b16          |   0
>   qcom/sc7280/vpu20_1v.b17          |   0
>   qcom/sc7280/vpu20_1v.b18          |   0
>   qcom/sc7280/vpu20_1v.b19          |   1 +
>   qcom/sc7280/vpu20_1v.mbn          | Bin 0 -> 2031188 bytes
>   qcom/sc7280/vpu20_1v.mdt          | Bin 0 -> 8068 bytes
>   qcom/sc7280/vpu20_1v_unsigned.mbn | Bin 0 -> 2031188 bytes

This looks weird.  You're adding 23 new files, none of which are
mentioned in WHENCE.  Also, why do you have a bunch of 0 byte files?

Is this correct?

josh

>   23 files changed, 1 insertion(+)
>   create mode 100644 qcom/sc7280/vpu20_1v.b00
>   create mode 100644 qcom/sc7280/vpu20_1v.b01
>   create mode 100644 qcom/sc7280/vpu20_1v.b02
>   create mode 100644 qcom/sc7280/vpu20_1v.b03
>   create mode 100644 qcom/sc7280/vpu20_1v.b04
>   create mode 100644 qcom/sc7280/vpu20_1v.b05
>   create mode 100644 qcom/sc7280/vpu20_1v.b06
>   create mode 100644 qcom/sc7280/vpu20_1v.b07
>   create mode 100644 qcom/sc7280/vpu20_1v.b08
>   create mode 100644 qcom/sc7280/vpu20_1v.b09
>   create mode 100644 qcom/sc7280/vpu20_1v.b10
>   create mode 100644 qcom/sc7280/vpu20_1v.b11
>   create mode 100644 qcom/sc7280/vpu20_1v.b12
>   create mode 100644 qcom/sc7280/vpu20_1v.b13
>   create mode 100644 qcom/sc7280/vpu20_1v.b14
>   create mode 100644 qcom/sc7280/vpu20_1v.b15
>   create mode 100644 qcom/sc7280/vpu20_1v.b16
>   create mode 100644 qcom/sc7280/vpu20_1v.b17
>   create mode 100644 qcom/sc7280/vpu20_1v.b18
>   create mode 100644 qcom/sc7280/vpu20_1v.b19
>   create mode 100644 qcom/sc7280/vpu20_1v.mbn
>   create mode 100644 qcom/sc7280/vpu20_1v.mdt
>   create mode 100644 qcom/sc7280/vpu20_1v_unsigned.mbn
>
> Regards,
> Suraj Magar


From jwboyer at kernel.org  Wed Apr 21 12:20:00 2021
From: jwboyer at kernel.org (Josh Boyer)
Date: Wed, 21 Apr 2021 07:20:00 -0400
Subject: Request to update venus-5.4 FW files
In-Reply-To: <f90802a86e80b6d9cc96ea8dd6aef4d8@codeaurora.org>
References: <f90802a86e80b6d9cc96ea8dd6aef4d8@codeaurora.org>
Message-ID: <CA+5PVA4wcjrNvBKabAW9BDDLKtZsjHRbyAYG+bqv8sMOu7gr-Q@mail.gmail.com>

On Wed, Apr 21, 2021 at 1:58 AM <smagar at codeaurora.org> wrote:
>
> Hello Team,
>
> Please include updated firmware bins for venus-5.4.
>
> Snapshot of pull request is as below, let me know if anything is
> missing.
>
>
> The following changes since commit
> 85286184d9df1b03bb76049edcfd87c39ce46e94:
>
>    Merge branch 'for-upstream' of
> git://git.chelsio.net/pub/git/linux-firmware into main (2021-04-19
> 11:34:11 -0400)
>
> are available in the git repository at:
>
>    https://github.com/suraj714/linux-firmware-venus.git master
>
> for you to fetch changes up to 5c893c65b862906a627cea238ae8c2d099027dee:
>
>    Updated Venus firmware files for v5.10 (2021-04-20 11:48:28 +0530)
>
> ----------------------------------------------------------------
> smagar (1):
>        Updated Venus firmware files for v5.10
>
>   qcom/venus-5.4/venus.b00 | Bin 212 -> 212 bytes
>   qcom/venus-5.4/venus.b01 | Bin 6808 -> 6808 bytes
>   qcom/venus-5.4/venus.b02 | Bin 873680 -> 873596 bytes
>   qcom/venus-5.4/venus.b03 | Bin 33792 -> 33792 bytes
>   qcom/venus-5.4/venus.mbn | Bin 919792 -> 919708 bytes
>   qcom/venus-5.4/venus.mdt | Bin 7020 -> 7020 bytes
>   6 files changed, 0 insertions(+), 0 deletions(-)

This commit looks reasonable, but it's in the same tree and branch as
the other weird PR I just replied to.  I'm going to wait for a bit on
this one.

josh


From andre.przywara at arm.com  Wed Apr 21 12:33:54 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 21 Apr 2021 12:33:54 +0100
Subject: [PATCH v2] arm64: dts: allwinner: Revert SD card CD GPIO for
 Pine64-LTS
In-Reply-To: <YHc11xC1vT1Yr+a1@weiser.dinsnail.net>
References: <20210414104740.31497-1-andre.przywara@arm.com>
 <YHc11xC1vT1Yr+a1@weiser.dinsnail.net>
Message-ID: <20210421123354.0a7209a1@slackpad.fritz.box>

On Wed, 14 Apr 2021 20:35:03 +0200
Michael Weiser <michael.weiser at gmx.de> wrote:

Maxime, Chen-Yu:

can you please try to push this patch into 5.12, still?
The Pine64-LTS' SD card is broken otherwise, on both versions of the
board. The incriminating patch was introduced in 5.12-rc1 (my bad!), so
it qualifies as a regression fix.

Many thanks!
Andre

> On Wed, Apr 14, 2021 at 11:47:40AM +0100, Andre Przywara wrote:
> 
> > Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
> > SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
> > along the way with the Pine64-LTS, which share the same base .dtsi.  
> 
> > This was based on the observation that the Pine64-LTS has as "push-push"
> > SD card socket, and that the schematic mentions the card detect GPIO.  
> 
> > After having received two reports about failing SD card access with that
> > patch, some more research and polls on that subject revealed that there
> > are at least two different versions of the Pine64-LTS out there:
> > - On some boards (including mine) the card detect pin is "stuck" at
> >   high, regardless of an microSD card being inserted or not.
> > - On other boards the card-detect is working, but is active-high, by
> >   virtue of an explicit inverter circuit, as shown in the schematic.  
> 
> > To cover all versions of the board out there, and don't take any chances,
> > let's revert the introduction of the active-low CD GPIO, but let's use
> > the broken-cd property for the Pine64-LTS this time. That should avoid
> > regressions and should work for everyone, even allowing SD card changes
> > now.
> > The SOPine card detect has proven to be working, so let's keep that
> > GPIO in place.  
> 
> I can confirm that this change works on my Pine64 LTS boards (with
> working high-active card detect) when applied to today's linux-next (which
> already includes your previous change to change the card detect GPIO
> from low- to high-active in sun50i-a64-sopine.dtsi).
> 
> > Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
> > Reported-by: Michael Weiser <michael.weiser at gmx.de>
> > Reported-by: Daniel Kulesz <kuleszdl at posteo.org>
> > Suggested-by: Chen-Yu Tsai <wens at csie.org>
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>  
> 
> Tested-by: Michael Weiser <michael.weiser at gmx.de>
> 
> Thanks!
> Michael
> 
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)  
> 
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > index e79ce49e7e6a..596a25907432 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
> > @@ -21,5 +21,5 @@
> >  };  
> 
> >  &mmc0 {
> > -	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 push-push switch */
> > +	broken-cd;		/* card detect is broken on *some* boards */
> >  };  
> 



From digetx at gmail.com  Wed Apr 21 12:46:24 2021
From: digetx at gmail.com (Dmitry Osipenko)
Date: Wed, 21 Apr 2021 14:46:24 +0300
Subject: [PATCH 08/10] memory: tegra: Unify drivers
In-Reply-To: <20210420165237.3523732-9-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-9-thierry.reding@gmail.com>
Message-ID: <a4d73dca-92a3-d5e5-677f-498f84aa0457@gmail.com>

20.04.2021 19:52, Thierry Reding ?????:
> +/*
> + * XXX The Tegra186 memory controller driver used to be able to do this. Once
> + * removing the driver is supported on all chips, this can be uncommented.
> + */
> +/*
> +static int tegra_mc_remove(struct platform_device *pdev)
> +{
> +	struct tegra_mc *mc = platform_get_drvdata(pdev);
> +
> +	if (mc->soc->ops && mc->soc->ops->remove)
> +		mc->soc->ops->remove(mc);
> +
> +	return 0;
> +}
> +*/
> +
>  static int __maybe_unused tegra_mc_suspend(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
> @@ -834,6 +856,9 @@ static struct platform_driver tegra_mc_driver = {
>  	},
>  	.prevent_deferred_probe = true,
>  	.probe = tegra_mc_probe,
> +	/*
> +	.remove = tegra_mc_remove,
> +	*/
>  };

The commented lines shouldn't be in the final version of the patch, IMO.
These lines either should be uncommented and the remove() callback
should return -EOPNOTSUPP or they should be removed for now.

The rest of the patches look good to me for now, I'll take another look
after testing the patches. Thank you.


From maz at kernel.org  Wed Apr 21 12:59:34 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 12:59:34 +0100
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
Message-ID: <871rb3rgpl.wl-maz@kernel.org>

On Wed, 21 Apr 2021 07:17:44 +0100,
Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> 
> Hi Gavin,
> 
> On 2021/4/21 14:20, Gavin Shan wrote:
> > Hi Keqian and Santosh,
> > 
> > On 4/21/21 12:59 PM, Keqian Zhu wrote:
> >> On 2020/10/22 0:16, Santosh Shukla wrote:
> >>> The Commit:6d674e28 introduces a notion to detect and handle the
> >>> device mapping. The commit checks for the VM_PFNMAP flag is set
> >>> in vma->flags and if set then marks force_pte to true such that
> >>> if force_pte is true then ignore the THP function check
> >>> (/transparent_hugepage_adjust()).
> >>>
> >>> There could be an issue with the VM_PFNMAP flag setting and checking.
> >>> For example consider a case where the mdev vendor driver register's
> >>> the vma_fault handler named vma_mmio_fault(), which maps the
> >>> host MMIO region in-turn calls remap_pfn_range() and maps
> >>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
> >>> the VM_PFNMAP flag into vma->flags.
> >> Could you give the name of the mdev vendor driver that triggers this issue?
> >> I failed to find one according to your description. Thanks.
> >>
> > 
> > I think it would be fixed in driver side to set VM_PFNMAP in
> > its mmap() callback (call_mmap()), like vfio PCI driver does.
> > It means it won't be delayed until page fault is issued and
> > remap_pfn_range() is called. It's determined from the beginning
> > that the vma associated the mdev vendor driver is serving as
> > PFN remapping purpose. So the vma should be populated completely,
> > including the VM_PFNMAP flag before it becomes visible to user
> > space.

Why should that be a requirement? Lazy populating of the VMA should be
perfectly acceptable if the fault can only happen on the CPU side.

> > 
> > The example can be found from vfio driver in drivers/vfio/pci/vfio_pci.c:
> >     vfio_pci_mmap:       VM_PFNMAP is set for the vma
> >     vfio_pci_mmap_fault: remap_pfn_range() is called
> Right. I have discussed the above with Marc. I want to find the driver
> to fix it. However, AFAICS, there is no driver matches the description...

I have the feeling this is an out-of-tree driver (and Santosh email
address is bouncing, so I guess we won't have much information from
him).

However, the simple fact that any odd driver can provide a fault
handler and populate it the VMA on demand makes me think that we need
to support this case.

	M.

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


From daniel.kiss at arm.com  Wed Apr 21 13:04:09 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Wed, 21 Apr 2021 14:04:09 +0200
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
Message-ID: <20210421120413.3110775-1-daniel.kiss@arm.com>

This series adds a feature to ETR-PERF that sync the ETR buffer to perf
periodically. This is really handy when the system wide trace is used
because in this case the perf won't sync during the trace. In a per-thread
setup the traced program might not go to the kernel frequvently enought
to collect trace. Polling helps in both usecases. Can be used with strobing.
Tuning polling period is challanging, I'm working on an additional patch
that adds some metrics to help tune the polling period.

Daniel Kiss (4):
  coresight: tmc-etr: Advance buffer pointer in sync buffer.
  coresight: tmc-etr: Track perf handler.
  coresight: etm-perf: Export etm_event_cpu_path.
  coresight: Add ETR-PERF polling.

 .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
 .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
 .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
 .../coresight/coresight-etr-perf-polling.h    |  42 +++
 .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
 .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
 drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
 9 files changed, 401 insertions(+), 4 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h

-- 
2.25.1



From daniel.kiss at arm.com  Wed Apr 21 13:04:10 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Wed, 21 Apr 2021 14:04:10 +0200
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync buffer.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <20210421120413.3110775-2-daniel.kiss@arm.com>

With polling the sync could called multiple times in a row. Without this
change the data will be overwritten at the beginning of the buffer.

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
---
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index ea5027e397d02..dd19d1d1c3b38 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1442,7 +1442,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
 {
 	long bytes;
 	long pg_idx, pg_offset;
-	unsigned long head = etr_perf->head;
+	unsigned long head;
 	char **dst_pages, *src_buf;
 	struct etr_buf *etr_buf = etr_perf->etr_buf;
 
@@ -1465,7 +1465,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
 		bytes = tmc_etr_buf_get_data(etr_buf, src_offset, to_copy,
 					     &src_buf);
 		if (WARN_ON_ONCE(bytes <= 0))
-			break;
+			return;
 		bytes = min(bytes, (long)(PAGE_SIZE - pg_offset));
 
 		memcpy(dst_pages[pg_idx] + pg_offset, src_buf, bytes);
@@ -1483,6 +1483,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
 		/* Move source pointers */
 		src_offset += bytes;
 	}
+	etr_perf->head = (pg_idx << PAGE_SHIFT) + pg_offset;
 }
 
 /*
-- 
2.25.1



From daniel.kiss at arm.com  Wed Apr 21 13:04:13 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Wed, 21 Apr 2021 14:04:13 +0200
Subject: [PATCH 4/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <20210421120413.3110775-5-daniel.kiss@arm.com>

ETR might fill up the buffer sooner than an event makes perf to trigger
the synchronisation especially in system wide trace. Polling runs
periodically to sync the ETR buffer. Period is configurable via sysfs,
disabled by default.

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
---
 .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
 drivers/hwtracing/coresight/Makefile          |   2 +-
 .../hwtracing/coresight/coresight-etm-perf.c  |   8 +
 .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
 .../coresight/coresight-etr-perf-polling.h    |  42 +++
 .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
 .../hwtracing/coresight/coresight-tmc-etr.c   |   9 +
 7 files changed, 386 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
index 6aa527296c710..4ca7af22a3686 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
@@ -91,3 +91,11 @@ Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
 Description:	(RW) Size of the trace buffer for TMC-ETR when used in SYSFS
 		mode. Writable only for TMC-ETR configurations. The value
 		should be aligned to the kernel pagesize.
+
+What:		/sys/bus/coresight/devices/<memory_map>.tmc/polling/period
+Date:		April 2021
+KernelVersion:	5.13
+Contact:	Daniel Kiss <daniel.kiss at arm.com>
+Description:	(RW) Time in milliseconds when the TMC-ETR is synced.
+		Default value is 0, means the feature is disabled.
+		Writable only for TMC-ETR configurations.
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index d60816509755c..4df90b71d98cd 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -4,7 +4,7 @@
 #
 obj-$(CONFIG_CORESIGHT) += coresight.o
 coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
-		coresight-sysfs.o
+		coresight-sysfs.o  coresight-etr-perf-polling.o
 obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
 coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
 		      coresight-tmc-etr.o
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 78a55fc2bcab5..910a99944eea8 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -19,6 +19,7 @@
 #include <linux/workqueue.h>
 
 #include "coresight-etm-perf.h"
+#include "coresight-etr-perf-polling.h"
 #include "coresight-priv.h"
 
 static struct pmu etm_pmu;
@@ -438,6 +439,8 @@ static void etm_event_start(struct perf_event *event, int flags)
 	/* Tell the perf core the event is alive */
 	event->hw.state = 0;
 
+	etr_perf_polling_event_start(event, event_data, handle);
+
 	/* Finally enable the tracer */
 	if (source_ops(csdev)->enable(csdev, event, CS_MODE_PERF))
 		goto fail_disable_path;
@@ -497,6 +500,8 @@ static void etm_event_stop(struct perf_event *event, int mode)
 	if (!sink)
 		return;
 
+	etr_perf_polling_event_stop(event, event_data);
+
 	/* stop tracer */
 	source_ops(csdev)->disable(csdev, event);
 
@@ -741,6 +746,8 @@ int __init etm_perf_init(void)
 	etm_pmu.addr_filters_validate	= etm_addr_filters_validate;
 	etm_pmu.nr_addr_filters		= ETM_ADDR_CMP_MAX;
 
+	etr_perf_polling_init();
+
 	ret = perf_pmu_register(&etm_pmu, CORESIGHT_ETM_PMU_NAME, -1);
 	if (ret == 0)
 		etm_perf_up = true;
@@ -750,5 +757,6 @@ int __init etm_perf_init(void)
 
 void __exit etm_perf_exit(void)
 {
+	etr_perf_polling_exit();
 	perf_pmu_unregister(&etm_pmu);
 }
diff --git a/drivers/hwtracing/coresight/coresight-etr-perf-polling.c b/drivers/hwtracing/coresight/coresight-etr-perf-polling.c
new file mode 100644
index 0000000000000..aa0352908873a
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etr-perf-polling.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(C) 2021 Arm Limited. All rights reserved.
+ * Author: Daniel Kiss <daniel.kiss at arm.com>
+ */
+
+#include <linux/coresight.h>
+#include <linux/coresight-pmu.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/percpu-defs.h>
+#include <linux/perf_event.h>
+#include <linux/slab.h>
+#include <linux/stringhash.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+#include "coresight-etr-perf-polling.h"
+#include "coresight-priv.h"
+#include "coresight-tmc.h"
+
+#if defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) || \
+    defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC_MODULE)
+
+struct polling_event_list {
+	struct perf_event *perf_event;
+	struct etm_event_data *etm_event_data;
+	struct perf_output_handle *ctx_handle;
+	void (*tmc_etr_reset_hw)(struct tmc_drvdata *);
+	struct list_head list;
+};
+
+struct polling {
+	int cpu;
+	struct list_head polled_events;
+	struct delayed_work delayed_work;
+};
+
+static atomic_t period;
+static spinlock_t spinlock_re;
+static struct list_head registered_events;
+
+static DEFINE_PER_CPU(struct polling, polling);
+
+static ssize_t period_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	int temp;
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
+		return -EPERM;
+
+	temp = atomic_read(&period);
+	return sprintf(buf, "%i\n", temp);
+}
+
+static ssize_t period_store(struct device *dev, struct device_attribute *attr,
+			    const char *buf, size_t count)
+{
+	int temp = 0;
+	struct tmc_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
+		return -EPERM;
+
+	if ((1 == sscanf(buf, "%i", &temp)) && (temp >= 0))
+		atomic_set(&period, temp);
+	return count;
+}
+
+static DEVICE_ATTR_RW(period);
+
+static struct attribute *coresight_tmc_polling_attrs[] = {
+	&dev_attr_period.attr,
+	NULL,
+};
+const struct attribute_group coresight_tmc_polling_group = {
+	.attrs = coresight_tmc_polling_attrs,
+	.name = "polling",
+};
+EXPORT_SYMBOL_GPL(coresight_tmc_polling_group);
+
+static inline void polling_sched_worker(struct polling *p)
+{
+	int tickrate = atomic_read(&period);
+	if (!list_empty(&p->polled_events) && (tickrate > 0))
+		schedule_delayed_work_on(p->cpu, &p->delayed_work,
+					 msecs_to_jiffies(tickrate));
+}
+
+static inline bool is_etr_related(struct etm_event_data *etm_event_data, int cpu)
+{
+	struct list_head *path;
+	struct coresight_device *sink;
+	struct tmc_drvdata *drvdata;
+	path = etm_event_cpu_path(etm_event_data, cpu);
+	if (WARN_ON(!path))
+		return false;
+	sink = coresight_get_sink(path);
+	if (WARN_ON(!sink))
+		return false;
+	drvdata = dev_get_drvdata(sink->dev.parent);
+	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
+		return false;
+	return true;
+}
+
+/*
+ * Adds the event to the polled events list.
+ */
+void etr_perf_polling_event_start(struct perf_event *event,
+				  struct etm_event_data *etm_event_data,
+				  struct perf_output_handle *ctx_handle)
+{
+	int cpu = smp_processor_id();
+	struct polling *p = per_cpu_ptr(&polling, cpu);
+	struct polling_event_list *element;
+	struct list_head *i, *tmp;
+
+	if (!is_etr_related(etm_event_data, cpu))
+		return;
+
+	spin_lock(&spinlock_re);
+	list_for_each_safe (i, tmp, &registered_events) {
+		element = list_entry(i, struct polling_event_list, list);
+		if (element->ctx_handle == ctx_handle) {
+			element->perf_event = event;
+			element->etm_event_data = etm_event_data;
+			list_del(&element->list);
+			spin_unlock(&spinlock_re);
+			list_add(&element->list, &p->polled_events);
+			polling_sched_worker(p);
+			return;
+		}
+	}
+	spin_unlock(&spinlock_re);
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_event_start);
+
+/*
+ * Removes the event from the to be polled events list.
+ */
+void etr_perf_polling_event_stop(struct perf_event *event,
+				 struct etm_event_data *etm_event_data)
+{
+	int cpu = smp_processor_id();
+	struct list_head *i, *tmp;
+	struct polling *p = per_cpu_ptr(&polling, cpu);
+
+	if (!is_etr_related(etm_event_data, cpu))
+		return;
+
+	list_for_each_safe (i, tmp, &p->polled_events) {
+		struct polling_event_list *element =
+			list_entry(i, struct polling_event_list, list);
+		if (element->perf_event == event) {
+			list_del(&element->list);
+			element->perf_event = NULL;
+			element->etm_event_data = NULL;
+			spin_lock(&spinlock_re);
+			list_add(&element->list, &registered_events);
+			spin_unlock(&spinlock_re);
+			if (list_empty(&p->polled_events)) {
+				cancel_delayed_work(&p->delayed_work);
+			}
+			return;
+		}
+	}
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_event_stop);
+
+/*
+ * The polling worker is a workqueue job which is periodically
+ * woken up to update the perf aux buffer from the etr shrink.
+ */
+static void etr_perf_polling_worker(struct work_struct *work)
+{
+	unsigned long flags;
+	int cpu = smp_processor_id();
+	struct polling *p = per_cpu_ptr(&polling, cpu);
+	struct list_head *i, *tmp;
+
+	if (!atomic_read(&period))
+		return;
+
+	/*
+	 * Scheduling would do the same from the perf hooks,
+	 * this should be done in one go.
+	 */
+	local_irq_save(flags);
+	preempt_disable();
+	/* Perf requires rcu lock. */
+	rcu_read_lock();
+
+	polling_sched_worker(p);
+
+	list_for_each_safe (i, tmp, &p->polled_events) {
+		struct list_head *path;
+		struct coresight_device *sink;
+		struct polling_event_list *element =
+			list_entry(i, struct polling_event_list, list);
+
+		path = etm_event_cpu_path(element->etm_event_data, cpu);
+		if (WARN_ON(!path))
+			continue;
+		sink = coresight_get_sink(path);
+		if (WARN_ON(!sink))
+			continue;
+		if (sink_ops(sink)->update_buffer) {
+			int size, refcnt;
+			struct tmc_drvdata *drvdata = dev_get_drvdata(sink->dev.parent);
+
+			/*
+			 * Act as now we are the only users of the sink. Due to the locks
+			 * we are safe.
+			 */
+			refcnt = atomic_xchg(sink->refcnt, 1);
+			size = sink_ops(sink)->update_buffer(
+				sink, element->ctx_handle,
+				element->etm_event_data->snk_config);
+			refcnt = atomic_xchg(sink->refcnt, refcnt);
+			/*
+			 * Restart the trace.
+			 */
+			if (element->tmc_etr_reset_hw)
+				element->tmc_etr_reset_hw(drvdata);
+
+			WARN_ON(size < 0);
+			if (size > 0) {
+				struct etm_event_data *new_event_data;
+
+				perf_aux_output_end(element->ctx_handle, size);
+				new_event_data = perf_aux_output_begin(
+					element->ctx_handle,
+					element->perf_event);
+				if (WARN_ON(new_event_data == NULL))
+					continue;
+				element->etm_event_data = new_event_data;
+				WARN_ON(new_event_data->snk_config !=
+					element->etm_event_data->snk_config);
+			}
+		}
+	}
+
+	rcu_read_unlock();
+	preempt_enable();
+	local_irq_restore(flags);
+}
+
+void etr_perf_polling_handle_register(struct perf_output_handle *handle,
+				      void (*tmc_etr_reset_hw)(struct tmc_drvdata *drvdata))
+{
+	struct polling_event_list *element;
+
+	element = kmalloc(sizeof(*element), GFP_KERNEL);
+	if (WARN_ON(!element))
+		return;
+	memset(element, 0, sizeof(*element));
+	element->ctx_handle = handle;
+	element->tmc_etr_reset_hw = tmc_etr_reset_hw;
+	spin_lock(&spinlock_re);
+	list_add(&element->list, &registered_events);
+	spin_unlock(&spinlock_re);
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_handle_register);
+
+void etr_perf_polling_handle_deregister(struct perf_output_handle *handle)
+{
+	struct list_head *i, *tmp;
+
+	spin_lock(&spinlock_re);
+	list_for_each_safe (i, tmp, &registered_events) {
+		struct polling_event_list *element =
+			list_entry(i, struct polling_event_list, list);
+		if (element->ctx_handle == handle) {
+			list_del(&element->list);
+			spin_unlock(&spinlock_re);
+			kfree(element);
+			return;
+		}
+	}
+	spin_unlock(&spinlock_re);
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_handle_deregister);
+
+void etr_perf_polling_init(void)
+{
+	int cpu;
+	spin_lock_init(&spinlock_re);
+	INIT_LIST_HEAD(&registered_events);
+	atomic_set(&period, 0);
+	for_each_possible_cpu (cpu) {
+		struct polling *p = per_cpu_ptr(&polling, cpu);
+		p->cpu = cpu;
+		INIT_LIST_HEAD(&p->polled_events);
+		INIT_DELAYED_WORK(&p->delayed_work, etr_perf_polling_worker);
+	}
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_init);
+
+void etr_perf_polling_exit(void)
+{
+	int cpu;
+	for_each_possible_cpu (cpu) {
+		struct polling *p = per_cpu_ptr(&polling, cpu);
+		cancel_delayed_work_sync(&p->delayed_work);
+		WARN_ON(!list_empty(&p->polled_events));
+	}
+	WARN_ON(!list_empty(&registered_events));
+}
+EXPORT_SYMBOL_GPL(etr_perf_polling_exit);
+
+#endif
diff --git a/drivers/hwtracing/coresight/coresight-etr-perf-polling.h b/drivers/hwtracing/coresight/coresight-etr-perf-polling.h
new file mode 100644
index 0000000000000..5917e1fa408bb
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etr-perf-polling.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright(C) 2021 Arm Limited. All rights reserved.
+ * Author: Daniel Kiss <daniel.kiss at arm.com>
+ */
+
+#ifndef _CORESIGHT_ETM_PERF_POLLING_H
+#define _CORESIGHT_ETM_PERF_POLLING_H
+
+#include <linux/coresight.h>
+#include <linux/perf_event.h>
+#include "coresight-etm-perf.h"
+#include "coresight-tmc.h"
+
+#if defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) || \
+    defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC_MODULE)
+
+void etr_perf_polling_init(void);
+void etr_perf_polling_exit(void);
+void etr_perf_polling_handle_register(struct perf_output_handle *handle,
+				      void (*tmc_etr_reset_hw)(struct tmc_drvdata *drvdata));
+void etr_perf_polling_handle_deregister(struct perf_output_handle *handle);
+void etr_perf_polling_event_start(struct perf_event *event,
+				  struct etm_event_data *etm_event_data,
+				  struct perf_output_handle *ctx_handle);
+void etr_perf_polling_event_stop(struct perf_event *event,
+				 struct etm_event_data *etm_event_data);
+
+extern const struct attribute_group coresight_tmc_polling_group;
+#define CORESIGHT_TMP_POLLING_GROUP &coresight_tmc_polling_group,
+
+#else /* !CONFIG_CORESIGHT_LINK_AND_SINK_TMC */
+#define etr_perf_polling_init()
+#define etr_perf_polling_exit()
+#define etr_perf_polling_handle_register(...)
+#define etr_perf_polling_handle_deregister(...)
+#define etr_perf_polling_event_start(...)
+#define etr_perf_polling_event_stop(...)
+#define CORESIGHT_TMP_POLLING_GROUP
+#endif
+
+#endif
diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
index 74c6323d4d6ab..51e705ef3ffa3 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-core.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
@@ -26,6 +26,7 @@
 
 #include "coresight-priv.h"
 #include "coresight-tmc.h"
+#include "coresight-etr-perf-polling.h"
 
 DEFINE_CORESIGHT_DEVLIST(etb_devs, "tmc_etb");
 DEFINE_CORESIGHT_DEVLIST(etf_devs, "tmc_etf");
@@ -365,6 +366,7 @@ static const struct attribute_group coresight_tmc_mgmt_group = {
 static const struct attribute_group *coresight_tmc_groups[] = {
 	&coresight_tmc_group,
 	&coresight_tmc_mgmt_group,
+	CORESIGHT_TMP_POLLING_GROUP
 	NULL,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index bf9f6311d8663..021b594e38e71 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -16,6 +16,7 @@
 #include <linux/vmalloc.h>
 #include "coresight-catu.h"
 #include "coresight-etm-perf.h"
+#include "coresight-etr-perf-polling.h"
 #include "coresight-priv.h"
 #include "coresight-tmc.h"
 
@@ -1139,6 +1140,12 @@ void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
 	drvdata->etr_buf = NULL;
 }
 
+static void tmc_etr_reset_hw(struct tmc_drvdata *drvdata)
+{
+	__tmc_etr_disable_hw(drvdata);
+	__tmc_etr_enable_hw(drvdata);
+}
+
 static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
 {
 	int ret = 0;
@@ -1630,6 +1637,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 		drvdata->mode = CS_MODE_PERF;
 		drvdata->perf_buf = etr_perf->etr_buf;
 		drvdata->perf_handle = handle;
+		etr_perf_polling_handle_register(handle, tmc_etr_reset_hw);
 		atomic_inc(csdev->refcnt);
 	}
 
@@ -1677,6 +1685,7 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
 	drvdata->mode = CS_MODE_DISABLED;
 	/* Reset perf specific data */
 	drvdata->perf_buf = NULL;
+	etr_perf_polling_handle_deregister(drvdata->perf_handle);
 	drvdata->perf_handle = NULL;
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-- 
2.25.1



From daniel.kiss at arm.com  Wed Apr 21 13:04:12 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Wed, 21 Apr 2021 14:04:12 +0200
Subject: [PATCH 3/4] coresight: etm-perf: Export etm_event_cpu_path.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <20210421120413.3110775-4-daniel.kiss@arm.com>

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +-
 drivers/hwtracing/coresight/coresight-etm-perf.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f123c26b9f549..78a55fc2bcab5 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -117,7 +117,7 @@ etm_event_cpu_path_ptr(struct etm_event_data *data, int cpu)
 	return per_cpu_ptr(data->path, cpu);
 }
 
-static inline struct list_head *
+struct list_head *
 etm_event_cpu_path(struct etm_event_data *data, int cpu)
 {
 	return *etm_event_cpu_path_ptr(data, cpu);
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 3e4f2ad5e193d..6d02abbad1b0f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -69,6 +69,7 @@ static inline void *etm_perf_sink_config(struct perf_output_handle *handle)
 		return data->snk_config;
 	return NULL;
 }
+struct list_head *etm_event_cpu_path(struct etm_event_data *data, int cpu);
 #else
 static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
 { return -EINVAL; }
-- 
2.25.1



From daniel.kiss at arm.com  Wed Apr 21 13:04:11 2021
From: daniel.kiss at arm.com (Daniel Kiss)
Date: Wed, 21 Apr 2021 14:04:11 +0200
Subject: [PATCH 2/4] coresight: tmc-etr: Track perf handler.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <20210421120413.3110775-3-daniel.kiss@arm.com>

Keep track of the perf handler that is registred by the first tracer.
This will be used by the update call from polling.

Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
---
 drivers/hwtracing/coresight/coresight-tmc-etr.c | 8 ++++++++
 drivers/hwtracing/coresight/coresight-tmc.h     | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index dd19d1d1c3b38..bf9f6311d8663 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1511,6 +1511,12 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
 		goto out;
 	}
 
+	/* Serve only the tracer with the right handler */
+	if (drvdata->perf_handle != handle) {
+		spin_unlock_irqrestore(&drvdata->spinlock, flags);
+		goto out;
+	}
+
 	if (WARN_ON(drvdata->perf_buf != etr_buf)) {
 		lost = true;
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
@@ -1623,6 +1629,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
 		drvdata->pid = pid;
 		drvdata->mode = CS_MODE_PERF;
 		drvdata->perf_buf = etr_perf->etr_buf;
+		drvdata->perf_handle = handle;
 		atomic_inc(csdev->refcnt);
 	}
 
@@ -1670,6 +1677,7 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
 	drvdata->mode = CS_MODE_DISABLED;
 	/* Reset perf specific data */
 	drvdata->perf_buf = NULL;
+	drvdata->perf_handle = NULL;
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
index b91ec7dde7bc9..81583ffb973dc 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.h
+++ b/drivers/hwtracing/coresight/coresight-tmc.h
@@ -184,6 +184,7 @@ struct etr_buf {
  * @idr_mutex:	Access serialisation for idr.
  * @sysfs_buf:	SYSFS buffer for ETR.
  * @perf_buf:	PERF buffer for ETR.
+ * @perf_handle: PERF handle for ETR.
  */
 struct tmc_drvdata {
 	void __iomem		*base;
@@ -207,6 +208,7 @@ struct tmc_drvdata {
 	struct mutex		idr_mutex;
 	struct etr_buf		*sysfs_buf;
 	struct etr_buf		*perf_buf;
+	struct perf_output_handle *perf_handle;
 };
 
 struct etr_buf_operations {
-- 
2.25.1



From rppt at kernel.org  Wed Apr 21 13:19:45 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 15:19:45 +0300
Subject: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear
 map from pfn_valid()
In-Reply-To: <0a7cc0d4-5d3d-7d6d-f4c3-bb2965b810e6@arm.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-4-rppt@kernel.org>
 <0a7cc0d4-5d3d-7d6d-f4c3-bb2965b810e6@arm.com>
Message-ID: <YIAYYcWtuwszHMux@kernel.org>

On Wed, Apr 21, 2021 at 04:29:48PM +0530, Anshuman Khandual wrote:
> 
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing else.
> > 
> > Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> > linear map vs those that require ioremap() to access them.
> > 
> > Introduce a dedicated pfn_is_map_memory() wrapper for
> > memblock_is_map_memory() to perform such check and use it where
> > appropriate.
> > 
> > Using a wrapper allows to avoid cyclic include dependencies.
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >  arch/arm64/include/asm/memory.h |  2 +-
> >  arch/arm64/include/asm/page.h   |  1 +
> >  arch/arm64/kvm/mmu.c            |  2 +-
> >  arch/arm64/mm/init.c            | 11 +++++++++++
> >  arch/arm64/mm/ioremap.c         |  4 ++--
> >  arch/arm64/mm/mmu.c             |  2 +-
> >  6 files changed, 17 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index 0aabc3be9a75..194f9f993d30 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >  
> >  #define virt_addr_valid(addr)	({					\
> >  	__typeof__(addr) __addr = __tag_reset(addr);			\
> > -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> > +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
> >  })
> >  
> >  void dump_mem_limit(void);
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 012cffc574e8..99a6da91f870 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
> >  typedef struct page *pgtable_t;
> >  
> >  extern int pfn_valid(unsigned long);
> > +extern int pfn_is_map_memory(unsigned long);
> 
> Check patch is complaining about this.
> 
> WARNING: function definition argument 'unsigned long' should also have an identifier name
> #50: FILE: arch/arm64/include/asm/page.h:41:
> +extern int pfn_is_map_memory(unsigned long);
> 
> 
> >  
> >  #include <asm/memory.h>
> >  
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 8711894db8c2..23dd99e29b23 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> >  
> >  static bool kvm_is_device_pfn(unsigned long pfn)
> >  {
> > -	return !pfn_valid(pfn);
> > +	return !pfn_is_map_memory(pfn);
> >  }
> >  
> >  /*
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 3685e12aba9b..dc03bdc12c0f 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > +int pfn_is_map_memory(unsigned long pfn)
> > +{
> > +	phys_addr_t addr = PFN_PHYS(pfn);
> > +
> 
> Should also bring with it, the comment regarding upper bits in
> the pfn from arm64 pfn_valid().

I think a reference to the comment in pfn_valid() will suffice.

BTW, I wonder how is that other architectures do not need this check?
 
> > +	if (PHYS_PFN(addr) != pfn)
> > +		return 0;
> > +	
> 
>  ^^^^^ trailing spaces here.
> 
> ERROR: trailing whitespace
> #81: FILE: arch/arm64/mm/init.c:263:
> +^I$

Oops :)
 
> > +	return memblock_is_map_memory(addr);
> > +}
> > +EXPORT_SYMBOL(pfn_is_map_memory);
> > +
> 
> Is the EXPORT_SYMBOL() required to build drivers which will use
> pfn_is_map_memory() but currently use pfn_valid() ?

Yes, this is required for virt_addr_valid() that is used by modules.

-- 
Sincerely yours,
Mike.


From rppt at kernel.org  Wed Apr 21 13:24:01 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 21 Apr 2021 15:24:01 +0300
Subject: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-5-rppt@kernel.org>
 <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com>
Message-ID: <YIAZYVI/HZWBr7BI@kernel.org>

On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
> 
> On 4/21/21 12:21 PM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> > 
> > * Parts of the memory map are freed during boot. This makes it necessary to
> >   verify that there is actual physical memory that corresponds to a pfn
> >   which is done by querying memblock.
> > 
> > * There are NOMAP memory regions. These regions are not mapped in the
> >   linear map and until the previous commit the struct pages representing
> >   these areas had default values.
> > 
> > As the consequence of absence of the special treatment of NOMAP regions in
> > the memory map it was necessary to use memblock_is_map_memory() in
> > pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
> > generic mm functionality would not treat a NOMAP page as a normal page.
> > 
> > Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
> > the rest of core mm will treat them as unusable memory and thus
> > pfn_valid_within() is no longer required at all and can be disabled by
> > removing CONFIG_HOLES_IN_ZONE on arm64.
> 
> This makes sense.
> 
> > 
> > pfn_valid() can be slightly simplified by replacing
> > memblock_is_map_memory() with memblock_is_memory().
> > 
> > Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> > ---
> >  arch/arm64/Kconfig   | 3 ---
> >  arch/arm64/mm/init.c | 4 ++--
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index e4e1b6550115..58e439046d05 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> >  	def_bool y
> >  	depends on NUMA
> >  
> > -config HOLES_IN_ZONE
> > -	def_bool y
> > -
> 
> Right.
> 
> >  source "kernel/Kconfig.hz"
> >  
> >  config ARCH_SPARSEMEM_ENABLE
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index dc03bdc12c0f..eb3f56fb8c7c 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
> >  
> >  	/*
> >  	 * ZONE_DEVICE memory does not have the memblock entries.
> > -	 * memblock_is_map_memory() check for ZONE_DEVICE based
> > +	 * memblock_is_memory() check for ZONE_DEVICE based
> >  	 * addresses will always fail. Even the normal hotplugged
> >  	 * memory will never have MEMBLOCK_NOMAP flag set in their
> >  	 * memblock entries. Skip memblock search for all non early
> > @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
> >  		return pfn_section_valid(ms, pfn);
> >  }
> >  #endif
> > -	return memblock_is_map_memory(addr);
> > +	return memblock_is_memory(addr);
> 
> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
> memory pfns for page table walking purpose but with PageReserved(),
> why memblock_is_memory() is still required ? At this point, should
> not we just return valid for early_section() memory. As pfn_valid()
> now just implies that pfn has a struct page backing which has been
> already verified with valid_section() etc.

memblock_is_memory() is required because arm64 frees unused parts of the
memory map. So, for instance, if we have 64M out of 128M populated in a
section the section based calculation would return 1 for a pfn in the
second half of the section, but there would be no memory map there.


> >  }
> >  EXPORT_SYMBOL(pfn_valid);
> >  
> > 

-- 
Sincerely yours,
Mike.


From lkp at intel.com  Wed Apr 21 13:45:19 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 20:45:19 +0800
Subject: [PATCH V5] watchdog: mtk: support dual mode when the bark irq is
 available
In-Reply-To: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
References: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
Message-ID: <202104212002.DRkrO28J-lkp@intel.com>

Hi Wang,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on hwmon/hwmon-next]
[also build test WARNING on soc/for-next linus/master v5.12-rc8 next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
base:   https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bb28c4d8391120b54c691e2407dae46761ef69af
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
        git checkout bb28c4d8391120b54c691e2407dae46761ef69af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/watchdog/mtk_wdt.c: In function 'mtk_wdt_probe':
>> drivers/watchdog/mtk_wdt.c:327:16: warning: missing terminating " character
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |                ^
   In file included from include/linux/device.h:15,
                    from include/linux/node.h:18,
                    from include/linux/cpu.h:17,
                    from include/linux/of_device.h:5,
                    from drivers/watchdog/mtk_wdt.c:23:
   drivers/watchdog/mtk_wdt.c:327:16: error: missing terminating " character
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
      19 | #define dev_fmt(fmt) fmt
         |                      ^~~
   drivers/watchdog/mtk_wdt.c:327:2: note: in expansion of macro 'dev_info'
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |  ^~~~~~~~
   drivers/watchdog/mtk_wdt.c:328:14: error: expected expression before '%' token
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |              ^
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
      19 | #define dev_fmt(fmt) fmt
         |                      ^~~
   drivers/watchdog/mtk_wdt.c:327:2: note: in expansion of macro 'dev_info'
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |  ^~~~~~~~
   drivers/watchdog/mtk_wdt.c:328:17: error: stray '\' in program
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                 ^
   drivers/watchdog/mtk_wdt.c:328:18: error: expected ';' before 'n'
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                  ^
   drivers/watchdog/mtk_wdt.c:328:19: warning: missing terminating " character
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                   ^
   drivers/watchdog/mtk_wdt.c:328:19: error: missing terminating " character
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +327 drivers/watchdog/mtk_wdt.c

   276	
   277	static int mtk_wdt_probe(struct platform_device *pdev)
   278	{
   279		struct device *dev = &pdev->dev;
   280		struct mtk_wdt_dev *mtk_wdt;
   281		const struct mtk_wdt_data *wdt_data;
   282		int err, irq;
   283	
   284		mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
   285		if (!mtk_wdt)
   286			return -ENOMEM;
   287	
   288		platform_set_drvdata(pdev, mtk_wdt);
   289	
   290		mtk_wdt->wdt_base = devm_platform_ioremap_resource(pdev, 0);
   291		if (IS_ERR(mtk_wdt->wdt_base))
   292			return PTR_ERR(mtk_wdt->wdt_base);
   293	
   294		if (dual_mode) {
   295			irq = platform_get_irq(pdev, 0);
   296			if (irq > 0) {
   297				err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
   298							&mtk_wdt->wdt_dev);
   299				if (err)
   300					return err;
   301			} else {
   302				dual_mode = 0;
   303				dev_info(&pdev->dev, "couldn't get wdt irq, set dual_mode = 0\n");
   304			}
   305		}
   306	
   307		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
   308		mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
   309		mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
   310		mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
   311		mtk_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
   312		mtk_wdt->wdt_dev.parent = dev;
   313	
   314		watchdog_init_timeout(&mtk_wdt->wdt_dev, timeout, dev);
   315		watchdog_set_nowayout(&mtk_wdt->wdt_dev, nowayout);
   316		watchdog_set_restart_priority(&mtk_wdt->wdt_dev, 128);
   317	
   318		watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
   319	
   320		mtk_wdt_init(&mtk_wdt->wdt_dev);
   321	
   322		watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
   323		err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
   324		if (unlikely(err))
   325			return err;
   326	
 > 327		dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
   328			 dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
   329	
   330		wdt_data = of_device_get_match_data(dev);
   331		if (wdt_data) {
   332			err = toprgu_register_reset_controller(pdev,
   333							       wdt_data->toprgu_sw_rst_num);
   334			if (err)
   335				return err;
   336		}
   337		return 0;
   338	}
   339	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 67500 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210421/5b780e1d/attachment-0001.gz>

From lkp at intel.com  Wed Apr 21 13:45:15 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 20:45:15 +0800
Subject: [PATCH V5] watchdog: mtk: support dual mode when the bark irq is
 available
In-Reply-To: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
References: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
Message-ID: <202104212029.VKA6lt7t-lkp@intel.com>

Hi Wang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on soc/for-next linus/master v5.12-rc8 next-20210420]
[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]

url:    https://github.com/0day-ci/linux/commits/Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
base:   https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next
config: mips-randconfig-r031-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install mips cross compiling tool for clang build
        # apt-get install binutils-mips-linux-gnu
        # https://github.com/0day-ci/linux/commit/bb28c4d8391120b54c691e2407dae46761ef69af
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
        git checkout bb28c4d8391120b54c691e2407dae46761ef69af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

>> drivers/watchdog/mtk_wdt.c:327:16: warning: missing terminating '"' character [-Winvalid-pp-token]
           dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
                         ^
>> drivers/watchdog/mtk_wdt.c:327:16: error: expected expression
   drivers/watchdog/mtk_wdt.c:328:19: warning: missing terminating '"' character [-Winvalid-pp-token]
                    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
                                   ^
   2 warnings and 1 error generated.


vim +327 drivers/watchdog/mtk_wdt.c

   276	
   277	static int mtk_wdt_probe(struct platform_device *pdev)
   278	{
   279		struct device *dev = &pdev->dev;
   280		struct mtk_wdt_dev *mtk_wdt;
   281		const struct mtk_wdt_data *wdt_data;
   282		int err, irq;
   283	
   284		mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
   285		if (!mtk_wdt)
   286			return -ENOMEM;
   287	
   288		platform_set_drvdata(pdev, mtk_wdt);
   289	
   290		mtk_wdt->wdt_base = devm_platform_ioremap_resource(pdev, 0);
   291		if (IS_ERR(mtk_wdt->wdt_base))
   292			return PTR_ERR(mtk_wdt->wdt_base);
   293	
   294		if (dual_mode) {
   295			irq = platform_get_irq(pdev, 0);
   296			if (irq > 0) {
   297				err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
   298							&mtk_wdt->wdt_dev);
   299				if (err)
   300					return err;
   301			} else {
   302				dual_mode = 0;
   303				dev_info(&pdev->dev, "couldn't get wdt irq, set dual_mode = 0\n");
   304			}
   305		}
   306	
   307		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
   308		mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
   309		mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
   310		mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
   311		mtk_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
   312		mtk_wdt->wdt_dev.parent = dev;
   313	
   314		watchdog_init_timeout(&mtk_wdt->wdt_dev, timeout, dev);
   315		watchdog_set_nowayout(&mtk_wdt->wdt_dev, nowayout);
   316		watchdog_set_restart_priority(&mtk_wdt->wdt_dev, 128);
   317	
   318		watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
   319	
   320		mtk_wdt_init(&mtk_wdt->wdt_dev);
   321	
   322		watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
   323		err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
   324		if (unlikely(err))
   325			return err;
   326	
 > 327		dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
   328			 dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
   329	
   330		wdt_data = of_device_get_match_data(dev);
   331		if (wdt_data) {
   332			err = toprgu_register_reset_controller(pdev,
   333							       wdt_data->toprgu_sw_rst_num);
   334			if (err)
   335				return err;
   336		}
   337		return 0;
   338	}
   339	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 39092 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210421/72420edf/attachment-0001.gz>

From robh at kernel.org  Wed Apr 21 13:51:48 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 07:51:48 -0500
Subject: [PATCH 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3 glue
In-Reply-To: <20210421042834.27309-2-samuel@sholland.org>
References: <20210421042834.27309-1-samuel@sholland.org>
 <20210421042834.27309-2-samuel@sholland.org>
Message-ID: <1619009508.513542.967209.nullmailer@robh.at.kernel.org>

On Tue, 20 Apr 2021 23:28:33 -0500, Samuel Holland wrote:
> The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
> USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
> Represent this by attaching the reset line to a glue layer device.
> 
> Signed-off-by: Samuel Holland <samuel at sholland.org>
> ---
>  .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
>  1 file changed, 75 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.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/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml: $id: 'http://devicetree.org/schemas/usb/allwinner,sun50i-h6-dwc3#' does not match 'http://devicetree.org/schemas/.*\\.yaml#'
Unknown file referenced: [Errno 2] No such file or directory: '/usr/local/lib/python3.8/dist-packages/dtschema/schemas/usb/allwinner,sun50i-h6-usb3-phy.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml: ignoring, error in schema: $id
warning: no schema found in file: ./Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.example.dts:23.27-50.11: Warning (unit_address_vs_reg): /example-0/usb at 5200000: node has a unit name, but no reg or ranges property
Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.example.dt.yaml:0:0: /example-0/usb at 5200000: failed to match any schema with compatible: ['allwinner,sun50i-h6-dwc3']
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.example.dt.yaml: usb at 5200000: phy-names:0: 'usb2-phy' was expected
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml

See https://patchwork.ozlabs.org/patch/1468558

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From catalin.marinas at arm.com  Wed Apr 21 14:02:37 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 21 Apr 2021 14:02:37 +0100
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <fe4bb655-80bb-d142-f352-89e9c52a90c5@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
 <fe4bb655-80bb-d142-f352-89e9c52a90c5@arm.com>
Message-ID: <20210421130235.GC18635@arm.com>

On Wed, Apr 21, 2021 at 10:18:56AM +0530, Anshuman Khandual wrote:
> On 4/20/21 3:05 PM, Catalin Marinas wrote:
> > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> > index b943879c1c24..15018dc59554 100644
> > --- a/arch/arm64/include/asm/memory.h
> > +++ b/arch/arm64/include/asm/memory.h
> > @@ -329,7 +329,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> >   */
> >  #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
> >  
> > -#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
> > +#if defined(CONFIG_DEBUG_VIRTUAL)
> 
> A small nit. Should this be #ifdef CONFIG_DEBUG_VIRTUAL instead ?

Yeah, for consistency I changed it to #ifdef.

> This is
> an user selectable config and the conditional check here does not have an
> #elseif part either. But then there are similar such instances else where
> on arm64 platform as well.

I'm not sure I get it. What would an #elseif need to check? We already
have an #else block for this #ifdef.

-- 
Catalin


From anshuman.khandual at arm.com  Wed Apr 21 14:13:28 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 18:43:28 +0530
Subject: [PATCH v2 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <YIAYYcWtuwszHMux@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-4-rppt@kernel.org>
 <0a7cc0d4-5d3d-7d6d-f4c3-bb2965b810e6@arm.com> <YIAYYcWtuwszHMux@kernel.org>
Message-ID: <2f9fb38c-0125-feca-4e15-3d443f3635e4@arm.com>

On 4/21/21 5:49 PM, Mike Rapoport wrote:
> On Wed, Apr 21, 2021 at 04:29:48PM +0530, Anshuman Khandual wrote:
>>
>> On 4/21/21 12:21 PM, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> The intended semantics of pfn_valid() is to verify whether there is a
>>> struct page for the pfn in question and nothing else.
>>>
>>> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
>>> linear map vs those that require ioremap() to access them.
>>>
>>> Introduce a dedicated pfn_is_map_memory() wrapper for
>>> memblock_is_map_memory() to perform such check and use it where
>>> appropriate.
>>>
>>> Using a wrapper allows to avoid cyclic include dependencies.
>>>
>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>> ---
>>>  arch/arm64/include/asm/memory.h |  2 +-
>>>  arch/arm64/include/asm/page.h   |  1 +
>>>  arch/arm64/kvm/mmu.c            |  2 +-
>>>  arch/arm64/mm/init.c            | 11 +++++++++++
>>>  arch/arm64/mm/ioremap.c         |  4 ++--
>>>  arch/arm64/mm/mmu.c             |  2 +-
>>>  6 files changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>> index 0aabc3be9a75..194f9f993d30 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>>  
>>>  #define virt_addr_valid(addr)	({					\
>>>  	__typeof__(addr) __addr = __tag_reset(addr);			\
>>> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
>>> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>>>  })
>>>  
>>>  void dump_mem_limit(void);
>>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>>> index 012cffc574e8..99a6da91f870 100644
>>> --- a/arch/arm64/include/asm/page.h
>>> +++ b/arch/arm64/include/asm/page.h
>>> @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page *from);
>>>  typedef struct page *pgtable_t;
>>>  
>>>  extern int pfn_valid(unsigned long);
>>> +extern int pfn_is_map_memory(unsigned long);
>>
>> Check patch is complaining about this.
>>
>> WARNING: function definition argument 'unsigned long' should also have an identifier name
>> #50: FILE: arch/arm64/include/asm/page.h:41:
>> +extern int pfn_is_map_memory(unsigned long);
>>
>>
>>>  
>>>  #include <asm/memory.h>
>>>  
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 8711894db8c2..23dd99e29b23 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>>>  
>>>  static bool kvm_is_device_pfn(unsigned long pfn)
>>>  {
>>> -	return !pfn_valid(pfn);
>>> +	return !pfn_is_map_memory(pfn);
>>>  }
>>>  
>>>  /*
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 3685e12aba9b..dc03bdc12c0f 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -258,6 +258,17 @@ int pfn_valid(unsigned long pfn)
>>>  }
>>>  EXPORT_SYMBOL(pfn_valid);
>>>  
>>> +int pfn_is_map_memory(unsigned long pfn)
>>> +{
>>> +	phys_addr_t addr = PFN_PHYS(pfn);
>>> +
>>
>> Should also bring with it, the comment regarding upper bits in
>> the pfn from arm64 pfn_valid().
> 
> I think a reference to the comment in pfn_valid() will suffice.

Okay.

> 
> BTW, I wonder how is that other architectures do not need this check?

Trying to move that into generic pfn_valid() in mmzone.h, will resend
the RFC patch after this series.

https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/

>  
>>> +	if (PHYS_PFN(addr) != pfn)
>>> +		return 0;
>>> +	
>>
>>  ^^^^^ trailing spaces here.
>>
>> ERROR: trailing whitespace
>> #81: FILE: arch/arm64/mm/init.c:263:
>> +^I$
> 
> Oops :)
>  
>>> +	return memblock_is_map_memory(addr);
>>> +}
>>> +EXPORT_SYMBOL(pfn_is_map_memory);
>>> +
>>
>> Is the EXPORT_SYMBOL() required to build drivers which will use
>> pfn_is_map_memory() but currently use pfn_valid() ?
> 
> Yes, this is required for virt_addr_valid() that is used by modules.
> 

There will be two adjacent EXPORT_SYMBOLS(), one for pfn_valid() and
one for pfn_is_map_memory(). But its okay I guess, cant help it.


From anshuman.khandual at arm.com  Wed Apr 21 14:15:50 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Wed, 21 Apr 2021 18:45:50 +0530
Subject: [PATCH v2 4/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <YIAZYVI/HZWBr7BI@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <20210421065108.1987-5-rppt@kernel.org>
 <66d50afe-77e6-70ee-6b51-5db28a086c68@arm.com> <YIAZYVI/HZWBr7BI@kernel.org>
Message-ID: <c9c4c4cc-fd4d-8bba-dd14-fa5d52161f9d@arm.com>



On 4/21/21 5:54 PM, Mike Rapoport wrote:
> On Wed, Apr 21, 2021 at 04:36:46PM +0530, Anshuman Khandual wrote:
>>
>> On 4/21/21 12:21 PM, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> The arm64's version of pfn_valid() differs from the generic because of two
>>> reasons:
>>>
>>> * Parts of the memory map are freed during boot. This makes it necessary to
>>>   verify that there is actual physical memory that corresponds to a pfn
>>>   which is done by querying memblock.
>>>
>>> * There are NOMAP memory regions. These regions are not mapped in the
>>>   linear map and until the previous commit the struct pages representing
>>>   these areas had default values.
>>>
>>> As the consequence of absence of the special treatment of NOMAP regions in
>>> the memory map it was necessary to use memblock_is_map_memory() in
>>> pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
>>> generic mm functionality would not treat a NOMAP page as a normal page.
>>>
>>> Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
>>> the rest of core mm will treat them as unusable memory and thus
>>> pfn_valid_within() is no longer required at all and can be disabled by
>>> removing CONFIG_HOLES_IN_ZONE on arm64.
>>
>> This makes sense.
>>
>>>
>>> pfn_valid() can be slightly simplified by replacing
>>> memblock_is_map_memory() with memblock_is_memory().
>>>
>>> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
>>> ---
>>>  arch/arm64/Kconfig   | 3 ---
>>>  arch/arm64/mm/init.c | 4 ++--
>>>  2 files changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index e4e1b6550115..58e439046d05 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
>>>  	def_bool y
>>>  	depends on NUMA
>>>  
>>> -config HOLES_IN_ZONE
>>> -	def_bool y
>>> -
>>
>> Right.
>>
>>>  source "kernel/Kconfig.hz"
>>>  
>>>  config ARCH_SPARSEMEM_ENABLE
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index dc03bdc12c0f..eb3f56fb8c7c 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
>>>  
>>>  	/*
>>>  	 * ZONE_DEVICE memory does not have the memblock entries.
>>> -	 * memblock_is_map_memory() check for ZONE_DEVICE based
>>> +	 * memblock_is_memory() check for ZONE_DEVICE based
>>>  	 * addresses will always fail. Even the normal hotplugged
>>>  	 * memory will never have MEMBLOCK_NOMAP flag set in their
>>>  	 * memblock entries. Skip memblock search for all non early
>>> @@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
>>>  		return pfn_section_valid(ms, pfn);
>>>  }
>>>  #endif
>>> -	return memblock_is_map_memory(addr);
>>> +	return memblock_is_memory(addr);
>>
>> Wondering if MEMBLOCK_NOMAP is now being treated similarly to other
>> memory pfns for page table walking purpose but with PageReserved(),
>> why memblock_is_memory() is still required ? At this point, should
>> not we just return valid for early_section() memory. As pfn_valid()
>> now just implies that pfn has a struct page backing which has been
>> already verified with valid_section() etc.
> 
> memblock_is_memory() is required because arm64 frees unused parts of the
> memory map. So, for instance, if we have 64M out of 128M populated in a
> section the section based calculation would return 1 for a pfn in the
> second half of the section, but there would be no memory map there.

Understood.


From alyssa at collabora.com  Wed Apr 21 14:17:04 2021
From: alyssa at collabora.com (Alyssa Rosenzweig)
Date: Wed, 21 Apr 2021 09:17:04 -0400
Subject: [PATCH v13 4/4] drm/panfrost: Add mt8183-mali compatible string
In-Reply-To: <20210421132841.v13.4.I5f6b04431828ec9c3e41e65f3337cec6a127480d@changeid>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
 <20210421132841.v13.4.I5f6b04431828ec9c3e41e65f3337cec6a127480d@changeid>
Message-ID: <YIAl0HRoAKD58C0R@maud>

Not that you need it but this patch is Reviewed-by: Alyssa Rosenzweig
<alyssa.rosenzweig at collabora.com>

On Wed, Apr 21, 2021 at 01:28:55PM +0800, Nicolas Boichat wrote:
> Add support for MT8183's G72 Bifrost.
> 
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> Reviewed-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> Reviewed-by: Steven Price <steven.price at arm.com>
> ---
> 
> (no changes since v7)
> 
> Changes in v7:
>  - Fix GPU ID in commit message
> 
> Changes in v6:
>  - Context conflicts, reflow the code.
>  - Use ARRAY_SIZE for power domains too.
> 
> Changes in v5:
>  - Change power domain name from 2d to core2.
> 
> Changes in v4:
>  - Add power domain names.
> 
> Changes in v3:
>  - Match mt8183-mali instead of bifrost, as we require special
>    handling for the 2 regulators and 3 power domains.
> 
>  drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 83a461bdeea8..ca07098a6141 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
>  	.vendor_quirk = panfrost_gpu_amlogic_quirk,
>  };
>  
> +const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
> +const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" };
> +static const struct panfrost_compatible mediatek_mt8183_data = {
> +	.num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
> +	.supply_names = mediatek_mt8183_supplies,
> +	.num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
> +	.pm_domain_names = mediatek_mt8183_pm_domains,
> +};
> +
>  static const struct of_device_id dt_match[] = {
>  	/* Set first to probe before the generic compatibles */
>  	{ .compatible = "amlogic,meson-gxm-mali",
> @@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
>  	{ .compatible = "arm,mali-t860", .data = &default_data, },
>  	{ .compatible = "arm,mali-t880", .data = &default_data, },
>  	{ .compatible = "arm,mali-bifrost", .data = &default_data, },
> +	{ .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, dt_match);
> -- 
> 2.31.1.368.gbe11c130af-goog
> 


From krzk at kernel.org  Wed Apr 21 14:28:42 2021
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 21 Apr 2021 15:28:42 +0200
Subject: [PATCH] media: mtk-jpeg: Fix a reference count leak.
In-Reply-To: <19432e4d-dcc4-5056-17ef-a6d2dd7b6fb4@xs4all.nl>
References: <20200613230843.14109-1-wu000273@umn.edu>
 <19432e4d-dcc4-5056-17ef-a6d2dd7b6fb4@xs4all.nl>
Message-ID: <CAJKOXPeQZWZpeStxwEhOGoFuPQzRxNHkanEZ=8nrfg7DUccoEQ@mail.gmail.com>

On Thu, 17 Sept 2020 at 13:48, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>
> On 14/06/2020 01:08, wu000273 at umn.edu wrote:
> > From: Qiushi Wu <wu000273 at umn.edu>
> >
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code. Thus call pm_runtime_put_noidle()
> > if pm_runtime_get_sync() fails.
> >
> > Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver")
> > Signed-off-by: Qiushi Wu <wu000273 at umn.edu>
> > ---
> >  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > index f82a81a3bdee..097f0b050f67 100644
> > --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> > @@ -710,8 +710,10 @@ static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
> >       int ret = 0;
> >
> >       ret = pm_runtime_get_sync(ctx->jpeg->dev);
> > -     if (ret < 0)
> > +     if (ret < 0) {
> > +             pm_runtime_put_noidle(ctx->jpeg->dev);
> >               goto err;
> > +     }
> >
> >       return 0;
> >  err:
> >
>
> This patch no longer applies, can you rebase this?

This patch might be harmful, might be not. Probably should be skipped
due to uncertain intentions:
https://lore.kernel.org/linux-nfs/YH+7ZydHv4+Y1hlx at kroah.com/

Best regards,
Krzysztof


From maz at kernel.org  Wed Apr 21 14:36:10 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 14:36:10 +0100
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210421065921.23917-5-cl@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com>
Message-ID: <87zgxrpxo5.wl-maz@kernel.org>

On Wed, 21 Apr 2021 07:59:20 +0100,
<cl at rock-chips.com> wrote:
> 
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipments.
> 
> This patch add basic core dtsi file for it.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 2789 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  795 +++++
>  .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  346 ++
>  3 files changed, 3930 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
>

[...]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..ac8db2f54f2b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,795 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <dt-bindings/clock/rk3568-cru.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,boot-mode.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {
> +	compatible = "rockchip,rk3568";
> +
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial2 = &uart2;
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x0>;
> +			enable-method = "psci";
> +			clocks = <&scmi_clk 0>;
> +			operating-points-v2 = <&cpu0_opp_table>;
> +			#cooling-cells = <2>;
> +		};
> +		cpu1: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x100>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +		cpu2: cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x200>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +		cpu3: cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x300>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +	};
> +
> +	cpu0_opp_table: cpu0-opp-table {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-408000000 {
> +			opp-hz = /bits/ 64 <408000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			clock-latency-ns = <40000>;
> +		};
> +		opp-600000000 {
> +			opp-hz = /bits/ 64 <600000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			opp-suspend;
> +		};
> +		opp-1104000000 {
> +			opp-hz = /bits/ 64 <1104000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-1416000000 {
> +			opp-hz = /bits/ 64 <1416000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +		opp-1608000000 {
> +			opp-hz = /bits/ 64 <1608000000>;
> +			opp-microvolt = <975000 975000 1150000>;
> +		};
> +		opp-1800000000 {
> +			opp-hz = /bits/ 64 <1800000000>;
> +			opp-microvolt = <1050000 1050000 1150000>;
> +		};
> +		opp-1992000000 {
> +			opp-hz = /bits/ 64 <1992000000>;
> +			opp-microvolt = <1150000 1150000 1150000>;
> +		};
> +	};
> +
> +	arm-pmu {
> +		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
> +		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> +	};
> +
> +	firmware {
> +		scmi: scmi {
> +			compatible = "arm,scmi-smc";
> +			shmem = <&scmi_shmem>;
> +			arm,smc-id = <0x82000010>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			scmi_clk: protocol at 14 {
> +				reg = <0x14>;
> +				#clock-cells = <1>;
> +			};
> +		};
> +
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;

This doesn't match the GICv3 binding for PPIs.

> +		arm,no-tick-in-suspend;

Oh, really? :-(

> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		#clock-cells = <0>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&clk32k_out0>;
> +	};
> +
> +	scmi_shmem: scmi-shmem at 10f000 {
> +		compatible = "arm,scmi-shmem";
> +		reg = <0x0 0x0010f000 0x0 0x100>;
> +	};
> +
> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";
> +		#interrupt-cells = <3>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		interrupt-controller;
> +
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;

Please add the 'mbi-alias' property, which should map onto the GICA
range that GIC600 provides. At least this could be useful to have MSIs
despite the lack of a working ITS. We can work out the usable ranges
on a per-board basis.

Thanks,

	M.

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


From arnd at kernel.org  Wed Apr 21 14:47:29 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 15:47:29 +0200
Subject: [PATCH] [net-next] net: stmmac: fix gcc-10 -Wrestrict warning
Message-ID: <20210421134743.3260921-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

gcc-10 and later warn about a theoretical array overrun when
accessing priv->int_name_rx_irq[i] with an out of bounds value
of 'i':

drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_request_irq_multi_msi':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3528:17: error: 'snprintf' argument 4 may overlap destination object 'dev' [-Werror=restrict]
 3528 |                 snprintf(int_name, int_name_len, "%s:%s-%d", dev->name, "tx", i);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3404:60: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
 3404 | static int stmmac_request_irq_multi_msi(struct net_device *dev)
      |                                         ~~~~~~~~~~~~~~~~~~~^~~

The warning is a bit strange since it's not actually about the array
bounds but rather about possible string operations with overlapping
arguments, but it's not technically wrong.

Avoid the warning by adding an extra bounds check.

Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d1ca07c846e6..aadac783687b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3498,6 +3498,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 
 	/* Request Rx MSI irq */
 	for (i = 0; i < priv->plat->rx_queues_to_use; i++) {
+		if (i > MTL_MAX_RX_QUEUES)
+			break;
 		if (priv->rx_irq[i] == 0)
 			continue;
 
@@ -3521,6 +3523,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
 
 	/* Request Tx MSI irq */
 	for (i = 0; i < priv->plat->tx_queues_to_use; i++) {
+		if (i > MTL_MAX_TX_QUEUES)
+			break;
 		if (priv->tx_irq[i] == 0)
 			continue;
 
-- 
2.29.2



From u.kleine-koenig at pengutronix.de  Wed Apr 21 14:48:25 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 21 Apr 2021 15:48:25 +0200
Subject: overflow and wrong timeout errors in pwm-atmel
In-Reply-To: <20210421110336.bd5s6e2kjxqilddi@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
 <20210421092606.1634092-1-u.kleine-koenig@pengutronix.de>
 <20210421110336.bd5s6e2kjxqilddi@pengutronix.de>
Message-ID: <20210421134825.powx5tvqvce32fho@pengutronix.de>

On Wed, Apr 21, 2021 at 01:03:36PM +0200, Uwe Kleine-K?nig wrote:
> On Wed, Apr 21, 2021 at 11:26:08AM +0200, Uwe Kleine-K?nig wrote:
> > With these three patches PWM_DEBUG is now happy. (At least I couldn't
> > trigger a warning any more. I think there are still a few problems with
> > integer overflows.)
> 
> BTW, setting the period to 138350580899 (with a clock rate of 133333333
> Hz) results in setting period=0 because
> 
> 	state->period * clkrate =
> 	138350580899 * 133333333 =
> 	40254751 (discarded from 18446744073749806367).

As a first remedy the following could be done:

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 38d86340201c..02d69fa5f7d2 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -199,6 +199,11 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
 	unsigned long long cycles = state->period;
 	int shift;
 
+	if (fls(cycles) + fls(clkrate) > 64) {
+		dev_err(chip->dev, "period to big to calculate HW parameters\n");
+		return -EINVAL;
+	}
+
 	/* Calculate the period cycles and prescale value */
 	cycles *= clkrate;
 	do_div(cycles, NSEC_PER_SEC);

Is this sensible? (Actually I'd prefer to just continue with

	period = (ULL(1) << (64 - fls(clkrate))) - 1

according to the motto to yield the highest possible period, but this
function has another error path that returns -EINVAL so this would be
inconsistent.)

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/20210421/b1814cb8/attachment-0001.sig>

From arnd at kernel.org  Wed Apr 21 14:48:36 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 15:48:36 +0200
Subject: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE
Message-ID: <20210421134844.3297838-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

When the firmware code is disabled, the incomplete error handling
in the clk driver causes compile-time warnings:

drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized]
  147 |         rate =  parent_rate * fbdiv;
      |                 ~~~~~~~~~~~~^~~~~~~
In function 'zynqmp_pll_get_mode',
    inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6:
drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized]
   61 |         return ret_payload[1];
      |                ~~~~~~~~~~~^~~
drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here
   53 |         u32 ret_payload[PAYLOAD_ARG_CNT];
      |             ^~~~~~~~~~~
drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent':
drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized]
   57 |         return val;
      |                ^~~

As it was apparently intentional to support this for compile testing
purposes, change the code to have just enough error handling for the
compiler to not notice the remaining bugs.

Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/clk/zynqmp/clk-mux-zynqmp.c | 4 +++-
 drivers/clk/zynqmp/pll.c            | 8 ++++++--
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/zynqmp/clk-mux-zynqmp.c b/drivers/clk/zynqmp/clk-mux-zynqmp.c
index 06194149be83..2afded3c7c11 100644
--- a/drivers/clk/zynqmp/clk-mux-zynqmp.c
+++ b/drivers/clk/zynqmp/clk-mux-zynqmp.c
@@ -50,9 +50,11 @@ static u8 zynqmp_clk_mux_get_parent(struct clk_hw *hw)
 
 	ret = zynqmp_pm_clock_getparent(clk_id, &val);
 
-	if (ret)
+	if (ret) {
 		pr_warn_once("%s() getparent failed for clock: %s, ret = %d\n",
 			     __func__, clk_name, ret);
+		return ret;
+	}
 
 	return val;
 }
diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
index abe6afbf3407..67d2a2d260c1 100644
--- a/drivers/clk/zynqmp/pll.c
+++ b/drivers/clk/zynqmp/pll.c
@@ -54,9 +54,11 @@ static inline enum pll_mode zynqmp_pll_get_mode(struct clk_hw *hw)
 	int ret;
 
 	ret = zynqmp_pm_get_pll_frac_mode(clk_id, ret_payload);
-	if (ret)
+	if (ret) {
 		pr_warn_once("%s() PLL get frac mode failed for %s, ret = %d\n",
 			     __func__, clk_name, ret);
+		return ret;
+	}
 
 	return ret_payload[1];
 }
@@ -140,9 +142,11 @@ static unsigned long zynqmp_pll_recalc_rate(struct clk_hw *hw,
 	int ret;
 
 	ret = zynqmp_pm_clock_getdivider(clk_id, &fbdiv);
-	if (ret)
+	if (ret) {
 		pr_warn_once("%s() get divider failed for %s, ret = %d\n",
 			     __func__, clk_name, ret);
+		return -1ul;
+	}
 
 	rate =  parent_rate * fbdiv;
 	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
-- 
2.29.2



From arnd at kernel.org  Wed Apr 21 14:49:01 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 15:49:01 +0200
Subject: [PATCH] KVM: arm64: build perf support only when enabled
Message-ID: <20210421134922.3309033-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

The perf_num_counters() function is only defined when CONFIG_PERF_EVENTS
is enabled:

arch/arm64/kvm/perf.c: In function 'kvm_perf_init':
arch/arm64/kvm/perf.c:58:43: error: implicit declaration of function 'perf_num_counters'; did you mean 'dec_mm_counter'? [-Werror=implicit-function-declaration]
   58 |         if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0
      |                                           ^~~~~~~~~~~~~~~~~

Use conditional compilation to disable this feature entirely when
CONFIG_PERF_EVENTS is disabled in the host.

Fixes: 6b5b368fccd7 ("KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Not sure if this is the correct symbol to check for, but this is
one way to avoid the build failure.
---
 arch/arm64/kvm/Makefile | 4 +++-
 arch/arm64/kvm/arm.c    | 8 +++++---
 include/kvm/arm_pmu.h   | 7 +++++++
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 589921392cb1..9adf12ba5047 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_KVM) += hyp/
 
 kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
 	 $(KVM)/vfio.o $(KVM)/irqchip.o \
-	 arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \
+	 arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
 	 inject_fault.o va_layout.o handle_exit.o \
 	 guest.o debug.o reset.o sys_regs.o \
 	 vgic-sys-reg-v3.o fpsimd.o pmu.o \
@@ -24,4 +24,6 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \
 	 vgic/vgic-mmio-v3.o vgic/vgic-kvm-device.o \
 	 vgic/vgic-its.o vgic/vgic-debug.o
 
+kvm-$(CONFIG_PERF_EVENTS) += perf.o
+
 kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 4808aca8c87c..720e075c70f9 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1694,7 +1694,8 @@ static int init_subsystems(void)
 	if (err)
 		goto out;
 
-	kvm_perf_init();
+	if (IS_ENABLED(CONFIG_PERF_EVENTS))
+		kvm_perf_init();
 	kvm_sys_reg_table_init();
 
 out:
@@ -1899,7 +1900,8 @@ static int init_hyp_mode(void)
 	return 0;
 
 out_err:
-	teardown_hyp_mode();
+	if (IS_ENABLED(CONFIG_PERF_EVENTS))
+		teardown_hyp_mode();
 	kvm_err("error initializing Hyp mode: %d\n", err);
 	return err;
 }
@@ -2101,7 +2103,7 @@ int kvm_arch_init(void *opaque)
 
 out_hyp:
 	hyp_cpu_pm_exit();
-	if (!in_hyp_mode)
+	if (!IS_ENABLED(CONFIG_PERF_EVENTS) && in_hyp_mode)
 		teardown_hyp_mode();
 out_err:
 	return err;
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 6fd3cda608e4..d84307a1ebd5 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -13,12 +13,19 @@
 #define ARMV8_PMU_CYCLE_IDX		(ARMV8_PMU_MAX_COUNTERS - 1)
 #define ARMV8_PMU_MAX_COUNTER_PAIRS	((ARMV8_PMU_MAX_COUNTERS + 1) >> 1)
 
+#ifdef CONFIG_PERF_EVENTS
 DECLARE_STATIC_KEY_FALSE(kvm_arm_pmu_available);
 
 static __always_inline bool kvm_arm_support_pmu_v3(void)
 {
 	return static_branch_likely(&kvm_arm_pmu_available);
 }
+#else
+static __always_inline bool kvm_arm_support_pmu_v3(void)
+{
+	return 0;
+}
+#endif
 
 #ifdef CONFIG_HW_PERF_EVENTS
 
-- 
2.29.2



From arnd at kernel.org  Wed Apr 21 14:54:53 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 15:54:53 +0200
Subject: [PATCH] EDAC/aspeed: use proper format string for printing resource
Message-ID: <20210421135500.3518661-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

On ARMv7, resource_size_t can be 64-bit, which breaks printing
it as %x:

drivers/edac/aspeed_edac.c: In function 'init_csrows':
drivers/edac/aspeed_edac.c:257:28: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=]
  257 |         dev_dbg(mci->pdev, "dt: /memory node resources: first page r.start=0x%x, resource_size=0x%x, PAGE_SHIFT macro=0x%x\n",

Use the special %pR format string to pretty-print the entire
resource instead.

Fixes: edfc2d73ca45 ("EDAC/aspeed: Add support for AST2400 and AST2600")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/edac/aspeed_edac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
index a46da56d6d54..6bd5f8815919 100644
--- a/drivers/edac/aspeed_edac.c
+++ b/drivers/edac/aspeed_edac.c
@@ -254,8 +254,8 @@ static int init_csrows(struct mem_ctl_info *mci)
 		return rc;
 	}
 
-	dev_dbg(mci->pdev, "dt: /memory node resources: first page r.start=0x%x, resource_size=0x%x, PAGE_SHIFT macro=0x%x\n",
-		r.start, resource_size(&r), PAGE_SHIFT);
+	dev_dbg(mci->pdev, "dt: /memory node resources: first page %pR, PAGE_SHIFT macro=0x%x\n",
+		&r, PAGE_SHIFT);
 
 	csrow->first_page = r.start >> PAGE_SHIFT;
 	nr_pages = resource_size(&r) >> PAGE_SHIFT;
-- 
2.29.2



From maz at kernel.org  Wed Apr 21 14:56:16 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 14:56:16 +0100
Subject: [PATCH] KVM: arm64: build perf support only when enabled
In-Reply-To: <20210421134922.3309033-1-arnd@kernel.org>
References: <20210421134922.3309033-1-arnd@kernel.org>
Message-ID: <87y2dbpwqn.wl-maz@kernel.org>

On Wed, 21 Apr 2021 14:49:01 +0100,
Arnd Bergmann <arnd at kernel.org> wrote:
> 
> From: Arnd Bergmann <arnd at arndb.de>
> 
> The perf_num_counters() function is only defined when CONFIG_PERF_EVENTS
> is enabled:
> 
> arch/arm64/kvm/perf.c: In function 'kvm_perf_init':
> arch/arm64/kvm/perf.c:58:43: error: implicit declaration of function 'perf_num_counters'; did you mean 'dec_mm_counter'? [-Werror=implicit-function-declaration]
>    58 |         if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0
>       |                                           ^~~~~~~~~~~~~~~~~
> 
> Use conditional compilation to disable this feature entirely when
> CONFIG_PERF_EVENTS is disabled in the host.
> 
> Fixes: 6b5b368fccd7 ("KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> Not sure if this is the correct symbol to check for, but this is
> one way to avoid the build failure.

I think a better way is to get rid of perf_num_counters() entirely,
see [1]. If someone acks the second and last patches, I'll even take
the whole series in (nudge nudge...).

Thanks,

	M.

[1] https://lore.kernel.org/r/20210414134409.1266357-1-maz at kernel.org

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


From arnd at kernel.org  Wed Apr 21 15:00:40 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 16:00:40 +0200
Subject: [PATCH] remoteproc: stm32: fix phys_addr_t format string
Message-ID: <20210421140053.3727528-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

A phys_addr_t may be wider than an int or pointer:

drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_da_to_pa':
drivers/remoteproc/stm32_rproc.c:583:30: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'phys_addr_t' {aka 'long long unsigned int'} [-Werror=format=]
  583 |                 dev_dbg(dev, "da %llx to pa %#x\n", da, *pa);

Print it by reference using the special %pap format string.

Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops")
igned-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/remoteproc/stm32_rproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 7353f9e7e7af..32595c950569 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -580,7 +580,7 @@ static int stm32_rproc_da_to_pa(struct rproc *rproc,
 			continue;
 
 		*pa = da - p_mem->dev_addr + p_mem->bus_addr;
-		dev_dbg(dev, "da %llx to pa %#x\n", da, *pa);
+		dev_dbg(dev, "da %llx to pa %pap\n", da, pa);
 
 		return 0;
 	}
-- 
2.29.2



From frank-w at public-files.de  Wed Apr 21 15:04:34 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Wed, 21 Apr 2021 16:04:34 +0200
Subject: Aw: Re: [PATCH net-next v2 2/2] net: ethernet: mediatek: support
 custom GMAC label
In-Reply-To: <CALCv0x2SG=0kBRnxfSPxi+FvaBK=QGPHQkHWHvTXOw64KawPUQ@mail.gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
 <20210420195132.GA3686955@robh.at.kernel.org>
 <CALCv0x2SG=0kBRnxfSPxi+FvaBK=QGPHQkHWHvTXOw64KawPUQ@mail.gmail.com>
Message-ID: <trinity-47c2d588-093d-4054-a16f-81d76aa667e0-1619013874284@3c-app-gmx-bs34>

Hi,

for dsa slave-ports there is already a property "label", but not for master/cpu-ports

https://elixir.bootlin.com/linux/v5.12-rc8/source/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts#L163

handled here:

https://elixir.bootlin.com/linux/v5.12-rc8/source/net/dsa/dsa2.c#L1113

@ilya maybe you can rename slave-ports instead of master-port without code change?

i also prefer a more generic way to name interfaces in dts, not only in the mtk-driver, but the udev-approach is a way too, but this needs to be configured on each system manually...a preset by kernel/dts will be nice (at least to distinguish master/cpu- and user-ports).

regards Frank


From arnd at kernel.org  Wed Apr 21 15:06:48 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 16:06:48 +0200
Subject: [PATCH] spi: stm32-qspi: fix debug format string
Message-ID: <20210421140653.3964725-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

Printing size_t needs a special %zd format modifier to avoid a
warning like:

drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here
  481 |         dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);

Fixes: 18674dee3cd6 ("spi: stm32-qspi: Add dirmap support")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/spi/spi-stm32-qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index e2a99f054551..7e640ccc7e77 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -478,7 +478,7 @@ static ssize_t stm32_qspi_dirmap_read(struct spi_mem_dirmap_desc *desc,
 	 * all needed transfer information into struct spi_mem_op
 	 */
 	memcpy(&op, &desc->info.op_tmpl, sizeof(struct spi_mem_op));
-	dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
+	dev_dbg(qspi->dev, "%s len = 0x%zx offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
 
 	op.data.nbytes = len;
 	op.addr.val = desc->info.offset + offs;
-- 
2.29.2



From linux at roeck-us.net  Wed Apr 21 15:11:26 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 21 Apr 2021 07:11:26 -0700
Subject: [PATCH V5] watchdog: mtk: support dual mode when the bark irq is
 available
In-Reply-To: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
References: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
Message-ID: <65b0c4d4-7b01-eb4c-3b1e-0d1427e85c3e@roeck-us.net>

On 4/21/21 1:05 AM, Wang Qing wrote:
> Support using irq handling wdt bark first instead of directly resetting.
> 
> When the watchdog timer expires in dual mode, an interrupt will be
> triggered first, then the timing restarts. The reset signal will be
> initiated when the timer expires again.
> 
> The dual mode is disabled by default.
> 

This means the real timeout is now timeout * 2. This is not what
is supposed to happen. The hard watchdog timeout needs to happen at
'timeout'.

If you want to do this, it needs to be done using pre-timeout,
only the pre-timeout time (and thus the watchdog timeout written
into the chip) must be limited to timeout / 2. Pre-timeout must
by default be disabled and only be supported if an interrupt was
provided.

I don't see a need for an additional module parameter. Providing
an interrupt implies that pre-timeout support is wanted. This needs
to be documented accordingly.

I am not lot looking at the errors reported by 0-day. Please address those.

Guenter

> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> 
> V3:
> - Modify the pretimeout behavior, manually reset after the pretimeout
> - is processed and wait until timeout.
> 
> V4:
> - Remove pretimeout related processing. 
> - Add dual mode control separately.
> 
> V5:
> - Fix some formatting and printing problems.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 36 ++++++++++++++++++++++++++++++++----
>  1 file changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..40122f8
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -57,6 +58,7 @@
>  
>  static bool nowayout = WATCHDOG_NOWAYOUT;
>  static unsigned int timeout;
> +static bool dual_mode;
>  
>  struct mtk_wdt_dev {
>  	struct watchdog_device wdt_dev;
> @@ -239,13 +241,23 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	if (dual_mode)
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	else
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	panic("wdt bark!\n");
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -267,7 +279,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,6 +291,19 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> +	if (dual_mode) {
> +		irq = platform_get_irq(pdev, 0);
> +		if (irq > 0) {
> +			err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +						&mtk_wdt->wdt_dev);
> +			if (err)
> +				return err;
> +		} else {
> +			dual_mode = 0;
> +			dev_info(&pdev->dev, "couldn't get wdt irq, set dual_mode = 0\n");
> +		}
> +	}
> +
>  	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
> @@ -299,8 +324,8 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (unlikely(err))
>  		return err;
>  
> -	dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d)\n",
> -		 mtk_wdt->wdt_dev.timeout, nowayout);
> +	dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
> +		 dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
>  
>  	wdt_data = of_device_get_match_data(dev);
>  	if (wdt_data) {
> @@ -368,6 +393,9 @@ module_param(nowayout, bool, 0);
>  MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
>  			__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>  
> +module_param(dual_mode, bool, 0);
> +MODULE_PARM_DESC(dual_mode, "Dual mode triggers irq before reset (default=0)");
> +
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Matthias Brugger <matthias.bgg at gmail.com>");
>  MODULE_DESCRIPTION("Mediatek WatchDog Timer Driver");
> 



From alexandre.belloni at bootlin.com  Wed Apr 21 15:18:37 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Wed, 21 Apr 2021 16:18:37 +0200
Subject: overflow and wrong timeout errors in pwm-atmel
In-Reply-To: <20210421134825.powx5tvqvce32fho@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
 <20210421092606.1634092-1-u.kleine-koenig@pengutronix.de>
 <20210421110336.bd5s6e2kjxqilddi@pengutronix.de>
 <20210421134825.powx5tvqvce32fho@pengutronix.de>
Message-ID: <YIA0PXR+oxxpkrzL@piout.net>

On 21/04/2021 15:48:25+0200, Uwe Kleine-K?nig wrote:
> On Wed, Apr 21, 2021 at 01:03:36PM +0200, Uwe Kleine-K?nig wrote:
> > On Wed, Apr 21, 2021 at 11:26:08AM +0200, Uwe Kleine-K?nig wrote:
> > > With these three patches PWM_DEBUG is now happy. (At least I couldn't
> > > trigger a warning any more. I think there are still a few problems with
> > > integer overflows.)
> > 
> > BTW, setting the period to 138350580899 (with a clock rate of 133333333
> > Hz) results in setting period=0 because
> > 
> > 	state->period * clkrate =
> > 	138350580899 * 133333333 =
> > 	40254751 (discarded from 18446744073749806367).
> 
> As a first remedy the following could be done:
> 
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index 38d86340201c..02d69fa5f7d2 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -199,6 +199,11 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
>  	unsigned long long cycles = state->period;
>  	int shift;
>  
> +	if (fls(cycles) + fls(clkrate) > 64) {
> +		dev_err(chip->dev, "period to big to calculate HW parameters\n");
> +		return -EINVAL;
> +	}
> +
>  	/* Calculate the period cycles and prescale value */
>  	cycles *= clkrate;
>  	do_div(cycles, NSEC_PER_SEC);
> 
> Is this sensible? (Actually I'd prefer to just continue with
> 
> 	period = (ULL(1) << (64 - fls(clkrate))) - 1
> 
> according to the motto to yield the highest possible period, but this
> function has another error path that returns -EINVAL so this would be
> inconsistent.)

Shouldn't that be -ERANGE? I do think it is better to return an error
and let userspace decide what is the policy instead of having the policy
in the driver.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From arnd at kernel.org  Wed Apr 21 15:28:12 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 16:28:12 +0200
Subject: [PATCH] KVM: arm64: build perf support only when enabled
In-Reply-To: <87y2dbpwqn.wl-maz@kernel.org>
References: <20210421134922.3309033-1-arnd@kernel.org>
 <87y2dbpwqn.wl-maz@kernel.org>
Message-ID: <CAK8P3a26F1+9XJqHtqO5S0dwTjBhV8Z+0J1r_D69y9h84qyY7g@mail.gmail.com>

On Wed, Apr 21, 2021 at 3:56 PM Marc Zyngier <maz at kernel.org> wrote:
> On Wed, 21 Apr 2021 14:49:01 +0100, Arnd Bergmann <arnd at kernel.org> wrote:
>
> I think a better way is to get rid of perf_num_counters() entirely,
> see [1]. If someone acks the second and last patches, I'll even take
> the whole series in (nudge nudge...).

Makes sense. I like your diffstat, too.

       Arnd


From f.fainelli at gmail.com  Wed Apr 21 15:33:52 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 21 Apr 2021 07:33:52 -0700
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <YH/ixPnHMxNo08mJ@google.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
 <YH/ixPnHMxNo08mJ@google.com>
Message-ID: <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>



On 4/21/2021 1:31 AM, Quentin Perret wrote:
> On Tuesday 20 Apr 2021 at 09:33:56 (-0700), Florian Fainelli wrote:
>> I do wonder as well, we have a 32MB "no-map" reserved memory region on
>> our platforms located at 0xfe000000. Without the offending commit,
>> /proc/iomem looks like this:
>>
>> 40000000-fdffefff : System RAM
>>   40008000-40ffffff : Kernel code
>>   41e00000-41ef1d77 : Kernel data
>> 100000000-13fffffff : System RAM
>>
>> and with the patch applied, we have this:
>>
>> 40000000-fdffefff : System RAM
>>   40008000-40ffffff : Kernel code
>>   41e00000-41ef3db7 : Kernel data
>> fdfff000-ffffffff : System RAM
>> 100000000-13fffffff : System RAM
>>
>> so we can now see that the region 0xfe000000 - 0xfffffff is also cobbled
>> up with the preceding region which is a mailbox between Linux and the
>> secure monitor at 0xfdfff000 and of size 4KB. It seems like there is
>>
>> The memblock=debug outputs is also different:
>>
>> [    0.000000] MEMBLOCK configuration:
>> [    0.000000]  memory size = 0xfdfff000 reserved size = 0x7ce4d20d
>> [    0.000000]  memory.cnt  = 0x2
>> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
>> 0xbdfff000 bytes flags: 0x0
>> [    0.000000]  memory[0x1]     [0x00000100000000-0x0000013fffffff],
>> 0x40000000 bytes flags: 0x0
>> [    0.000000]  reserved.cnt  = 0x6
>> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
>> 0xb495 bytes flags: 0x0
>> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef1d77],
>> 0x1cf1d78 bytes flags: 0x0
>> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
>> 0x100000 bytes flags: 0x0
>> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
>> 0x50000 bytes flags: 0x0
>> [    0.000000]  reserved[0x4]   [0x000000c2c00000-0x000000fdbfffff],
>> 0x3b000000 bytes flags: 0x0
>> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
>> 0x40000000 bytes flags: 0x0
>>
>> [    0.000000] MEMBLOCK configuration:
>> [    0.000000]  memory size = 0x100000000 reserved size = 0x7ca4f24d
>> [    0.000000]  memory.cnt  = 0x3
>> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
>> 0xbdfff000 bytes flags: 0x0
>> [    0.000000]  memory[0x1]     [0x000000fdfff000-0x000000ffffffff],
>> 0x2001000 bytes flags: 0x4
>> [    0.000000]  memory[0x2]     [0x00000100000000-0x0000013fffffff],
>> 0x40000000 bytes flags: 0x0
>> [    0.000000]  reserved.cnt  = 0x6
>> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
>> 0xb495 bytes flags: 0x0
>> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef3db7],
>> 0x1cf3db8 bytes flags: 0x0
>> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
>> 0x100000 bytes flags: 0x0
>> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
>> 0x50000 bytes flags: 0x0
>> [    0.000000]  reserved[0x4]   [0x000000c3000000-0x000000fdbfffff],
>> 0x3ac00000 bytes flags: 0x0
>> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
>> 0x40000000 bytes flags: 0x0
>>
>> in the second case we can clearly see that the 32MB no-map region is now
>> considered as usable RAM.
>>
>> Hope this helps.
>>
>>>
>>> In any case, the mere fact that this causes a regression should be
>>> sufficient justification to revert/withdraw it from v5.4, as I don't
>>> see a reason why it was merged there in the first place. (It has no
>>> fixes tag or cc:stable)
>>
>> Agreed, however that means we still need to find out whether a more
>> recent kernel is also broken, I should be able to tell you that a little
>> later.
> 
> FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
> no-map region at 0x80000000, I have the following:
> 
> 40000000-7fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
> 80000000-800fffff : reserved
> 80100000-13fffffff : System RAM
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> If I remove the 'no-map' qualifier from DT, I get this:
> 
> 40000000-13fffffff : System RAM
>   40210000-417fffff : Kernel code
>   41800000-41daffff : reserved
>   41db0000-4210ffff : Kernel data
>   48000000-48008fff : reserved
>   80000000-800fffff : reserved
>   fa000000-ffffffff : reserved
>   13b000000-13f5fffff : reserved
>   13f6de000-13f77dfff : reserved
>   13f77e000-13f77efff : reserved
>   13f77f000-13f7dafff : reserved
>   13f7dd000-13f7defff : reserved
>   13f7df000-13f7dffff : reserved
>   13f7e0000-13f7f3fff : reserved
>   13f7f4000-13f7fdfff : reserved
>   13f7fe000-13fffffff : reserved
> 
> So this does seem to be working fine on my setup. I'll try again with
> 5.4 to see if I can repro.
> 
> Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
> reserved regions") looks more likely to cause the issue observed here,
> but that shouldn't be silent. I get the following error message in dmesg
> if I if place the no-map region on top of the kernel image:
> 
> OF: fdt: Reserved memory: failed to reserve memory for node 'foobar at 40210000': base 0x0000000040210000, size 1 MiB
> 
> Is that triggering on your end?

It is not, otherwise I would have noticed earlier, can you try the same
thing that happens on my platform with a reserved region (without
no-map) adjacent to a reserved region with 'no-map'? I will test
different and newer kernels than 5.4 today to find out if this is still
a problem with upstream. I could confirm that v4.9.259 also have this
problem now.
-- 
Florian


From David.Laight at ACULAB.COM  Wed Apr 21 15:38:27 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Wed, 21 Apr 2021 14:38:27 +0000
Subject: [PATCH] [net-next] net: stmmac: fix gcc-10 -Wrestrict warning
In-Reply-To: <20210421134743.3260921-1-arnd@kernel.org>
References: <20210421134743.3260921-1-arnd@kernel.org>
Message-ID: <caa29114659049e584b9fa7fbb6226c8@AcuMS.aculab.com>

From: Arnd Bergmann
> Sent: 21 April 2021 14:47
> 
> From: Arnd Bergmann <arnd at arndb.de>
> 
> gcc-10 and later warn about a theoretical array overrun when
> accessing priv->int_name_rx_irq[i] with an out of bounds value
> of 'i':
> 
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_request_irq_multi_msi':
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3528:17: error: 'snprintf' argument 4 may overlap
> destination object 'dev' [-Werror=restrict]
>  3528 |                 snprintf(int_name, int_name_len, "%s:%s-%d", dev->name, "tx", i);
>       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3404:60: note: destination object referenced by
> 'restrict'-qualified argument 1 was declared here
>  3404 | static int stmmac_request_irq_multi_msi(struct net_device *dev)
>       |                                         ~~~~~~~~~~~~~~~~~~~^~~
> 
> The warning is a bit strange since it's not actually about the array
> bounds but rather about possible string operations with overlapping
> arguments, but it's not technically wrong.
> 
> Avoid the warning by adding an extra bounds check.
> 
> Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d1ca07c846e6..aadac783687b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3498,6 +3498,8 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
> 
>  	/* Request Rx MSI irq */
>  	for (i = 0; i < priv->plat->rx_queues_to_use; i++) {
> +		if (i > MTL_MAX_RX_QUEUES)
> +			break;
>  		if (priv->rx_irq[i] == 0)
>  			continue;

It might be best to do:
	num_queues = min(priv->plat->rx_queues_to_use, MTL_MAX_RX_QUEUES);
	if (i = 0; i < num_queues; i++) {
		...

Or just give up - if rx_queues_to_use is too big it's all
gone horribly wrong already.

The compile must be smoking weed again.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From brgl at bgdev.pl  Wed Apr 21 15:44:20 2021
From: brgl at bgdev.pl (Bartosz Golaszewski)
Date: Wed, 21 Apr 2021 16:44:20 +0200
Subject: [PATCHv2] gpio: omap: Save and restore sysconfig
In-Reply-To: <20210417083839.46985-1-tony@atomide.com>
References: <20210417083839.46985-1-tony@atomide.com>
Message-ID: <CAMRc=McY+D-Ev95+nZ5mvwg=YxwJtC65a+5BY2Rvm9g8ec_d7w@mail.gmail.com>

On Sat, Apr 17, 2021 at 10:38 AM Tony Lindgren <tony at atomide.com> wrote:
>
> As we are using cpu_pm to save and restore context, we must also save and
> restore the GPIO sysconfig register. This is needed because we are not
> calling PM runtime functions at all with cpu_pm.
>
> We need to save the sysconfig on idle as it's value can get reconfigured by
> PM runtime and can be different from the init time value. Device specific
> flags like "ti,no-idle-on-init" can affect the init value.
>
> Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
> Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
> Cc: Adam Ford <aford173 at gmail.com>
> Cc: Andreas Kemnade <andreas at kemnade.info>
> Cc: Grygorii Strashko <grygorii.strashko at ti.com>
> Cc: Peter Ujfalusi <peter.ujfalusi at gmail.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>  drivers/gpio/gpio-omap.c                | 9 +++++++++
>  include/linux/platform_data/gpio-omap.h | 3 +++
>  2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -29,6 +29,7 @@
>  #define OMAP4_GPIO_DEBOUNCINGTIME_MASK 0xFF
>
>  struct gpio_regs {
> +       u32 sysconfig;
>         u32 irqenable1;
>         u32 irqenable2;
>         u32 wake_en;
> @@ -1069,6 +1070,7 @@ static void omap_gpio_init_context(struct gpio_bank *p)
>         const struct omap_gpio_reg_offs *regs = p->regs;
>         void __iomem *base = p->base;
>
> +       p->context.sysconfig    = readl_relaxed(base + regs->sysconfig);
>         p->context.ctrl         = readl_relaxed(base + regs->ctrl);
>         p->context.oe           = readl_relaxed(base + regs->direction);
>         p->context.wake_en      = readl_relaxed(base + regs->wkup_en);
> @@ -1088,6 +1090,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
>         const struct omap_gpio_reg_offs *regs = bank->regs;
>         void __iomem *base = bank->base;
>
> +       writel_relaxed(bank->context.sysconfig, base + regs->sysconfig);
>         writel_relaxed(bank->context.wake_en, base + regs->wkup_en);
>         writel_relaxed(bank->context.ctrl, base + regs->ctrl);
>         writel_relaxed(bank->context.leveldetect0, base + regs->leveldetect0);
> @@ -1115,6 +1118,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
>
>         bank->saved_datain = readl_relaxed(base + bank->regs->datain);
>
> +       /* Save syconfig, it's runtime value can be different from init value */
> +       if (bank->loses_context)
> +               bank->context.sysconfig = readl_relaxed(base + bank->regs->sysconfig);
> +
>         if (!bank->enabled_non_wakeup_gpios)
>                 goto update_gpio_context_count;
>
> @@ -1279,6 +1286,7 @@ static int gpio_omap_cpu_notifier(struct notifier_block *nb,
>
>  static const struct omap_gpio_reg_offs omap2_gpio_regs = {
>         .revision =             OMAP24XX_GPIO_REVISION,
> +       .sysconfig =            OMAP24XX_GPIO_SYSCONFIG,
>         .direction =            OMAP24XX_GPIO_OE,
>         .datain =               OMAP24XX_GPIO_DATAIN,
>         .dataout =              OMAP24XX_GPIO_DATAOUT,
> @@ -1302,6 +1310,7 @@ static const struct omap_gpio_reg_offs omap2_gpio_regs = {
>
>  static const struct omap_gpio_reg_offs omap4_gpio_regs = {
>         .revision =             OMAP4_GPIO_REVISION,
> +       .sysconfig =            OMAP4_GPIO_SYSCONFIG,
>         .direction =            OMAP4_GPIO_OE,
>         .datain =               OMAP4_GPIO_DATAIN,
>         .dataout =              OMAP4_GPIO_DATAOUT,
> diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h
> --- a/include/linux/platform_data/gpio-omap.h
> +++ b/include/linux/platform_data/gpio-omap.h
> @@ -85,6 +85,7 @@
>   * omap2+ specific GPIO registers
>   */
>  #define OMAP24XX_GPIO_REVISION         0x0000
> +#define OMAP24XX_GPIO_SYSCONFIG                0x0010
>  #define OMAP24XX_GPIO_IRQSTATUS1       0x0018
>  #define OMAP24XX_GPIO_IRQSTATUS2       0x0028
>  #define OMAP24XX_GPIO_IRQENABLE2       0x002c
> @@ -108,6 +109,7 @@
>  #define OMAP24XX_GPIO_SETDATAOUT       0x0094
>
>  #define OMAP4_GPIO_REVISION            0x0000
> +#define OMAP4_GPIO_SYSCONFIG           0x0010
>  #define OMAP4_GPIO_EOI                 0x0020
>  #define OMAP4_GPIO_IRQSTATUSRAW0       0x0024
>  #define OMAP4_GPIO_IRQSTATUSRAW1       0x0028
> @@ -148,6 +150,7 @@
>  #ifndef __ASSEMBLER__
>  struct omap_gpio_reg_offs {
>         u16 revision;
> +       u16 sysconfig;
>         u16 direction;
>         u16 datain;
>         u16 dataout;
> --
> 2.31.1

Applied for fixes, thanks!

Bartosz


From dann.frazier at canonical.com  Wed Apr 21 15:52:52 2021
From: dann.frazier at canonical.com (dann frazier)
Date: Wed, 21 Apr 2021 08:52:52 -0600
Subject: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts
In-Reply-To: <8735vjrjj3.wl-maz@kernel.org>
References: <20200519161755.209565-1-maz@kernel.org>
 <20200519161755.209565-9-maz@kernel.org>
 <YH87dtTfwYgavusz@xps13.dannf> <YH9G3+aDUWpcLCpD@xps13.dannf>
 <8735vjrjj3.wl-maz@kernel.org>
Message-ID: <YIA8RCjoI+9nChN6@xps13.dannf>

[ + Fu Wei ]
On Wed, Apr 21, 2021 at 11:58:40AM +0100, Marc Zyngier wrote:
> Hi Dan,n
> 
> On Tue, 20 Apr 2021 22:25:51 +0100,
> dann frazier <dann.frazier at canonical.com> wrote:
> > 
> > On Tue, Apr 20, 2021 at 02:37:10PM -0600, dann frazier wrote:
> > > On Tue, May 19, 2020 at 05:17:52PM +0100, Marc Zyngier wrote:
> > > > Change the way we deal with GIC SGIs by turning them into proper
> > > > IRQs, and calling into the arch code to register the interrupt range
> > > > instead of a callback.
> > > > 
> > > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > 
> > > hey Marc,
> > > 
> > >   I bisected a boot failure on our Gigabyte R120-T33 systems (ThunderX
> > > CN88XX) down to this commit, but only when running in ACPI mode. See below:
> > > 
> > > 
> > > EFI stub: Booting Linux Kernel...
> > > EFI stub: EFI_RNG_PROTOCOL unavailable, KASLR will be disabled
> > > EFI stub: Using DTB from configuration table
> > > EFI stub: Exiting boot services and installing virtual address map...
> > > [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
> > > [    0.000000] Linux version 5.11.0-13-generic (buildd at bos02-arm64-067) (gcc (Ubuntu 10.2.1-23ubuntu1) 10.2.1 20210312, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #14-Ubuntu SMP Fri Mar 19 16:57:35 UTC 2021 (Ubuntu 5.11.0-13.14-generic 5.11.7)
> > 
> > Sorry, realized I posted a log from an Ubuntu kernel. Here's an
> > upstream one:
> 
> [...]
> 
> > 
> > [    7.842174] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
> > [    7.849699] io scheduler mq-deadline registered
> > [    7.857591] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> > [    7.865127] efifb: probing for efifb
> > [    7.868738] efifb: No BGRT, not showing boot graphics
> > [    7.873783] efifb: framebuffer at 0x881010000000, using 3072k, total 3072k
> > [    7.880649] efifb: mode is 1024x768x32, linelength=4096, pages=1
> > [    7.886647] efifb: scrolling: redraw
> > [    7.890212] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> > [    7.895905] fbcon: Deferring console take-over
> > [    7.900350] fb0: EFI VGA frame buffer device
> > [    7.905289] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
> > [    7.913714] ACPI: button: Power Button [PWRB]
> > [    7.919549] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
> > [    7.927289] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
> > [    7.936326] Mem abort info:
> > [    7.939108]   ESR = 0x96000004
> > [    7.942151]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [    7.947451]   SET = 0, FnV = 0
> > [    7.950494]   EA = 0, S1PTW = 0
> > [    7.953624] Data abort info:
> > [    7.956492]   ISV = 0, ISS = 0x00000004
> > [    7.960316]   CM = 0, WnR = 0
> > [    7.963273] [0000000000000028] user address but active_mm is swapper
> > [    7.969616] Internal error: Oops: 96000004 [#1] SMP
> > [    7.974483] Modules linked in:
> > [    7.977531] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8 #19
> > [    7.983874] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
> > [    7.990737] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
> > [    7.996732] pc : __ipi_send_mask+0x60/0x114
> > [    8.000910] lr : smp_cross_call+0x40/0xcc
> > [    8.004913] sp : ffff800012753c10
> > [    8.008216] x29: ffff800012753c10 x28: ffff000100de5d00 
> > [    8.013521] x27: 000000000000000a x26: ffff80001225da20 
> > [    8.018825] x25: 0000000000000000 x24: ffff000ff62719b0 
> > [    8.024129] x23: ffff80001225d000 x22: ffff800012368108 
> > [    8.029433] x21: ffff800010f69a20 x20: 0000000000000000 
> > [    8.034737] x19: ffff000100143c60 x18: 0000000000000020 
> > [    8.040041] x17: 000000008e74252f x16: 00000000bf0ab2ad 
> > [    8.045345] x15: ffffffffffffffff x14: 0000000000000000 
> > [    8.050649] x13: 003d090000000000 x12: 00003d0900000000 
> > [    8.055953] x11: 0000000000000000 x10: 00003d0900000000 
> > [    8.061257] x9 : ffff800010027f14 x8 : 0000000000000000 
> > [    8.066561] x7 : 00000000ffffffff x6 : ffff000ff6148698 
> > [    8.071865] x5 : ffff80001159d040 x4 : ffff80001159d110 
> > [    8.077169] x3 : ffff800010f69a00 x2 : 0000000000000000 
> > [    8.082473] x1 : ffff800010f69a20 x0 : 0000000000000000 
> > [    8.087777] Call trace:
> > [    8.090213]  __ipi_send_mask+0x60/0x114
> > [    8.094038]  smp_cross_call+0x40/0xcc
> > [    8.097691]  smp_send_reschedule+0x3c/0x50
> > [    8.101778]  resched_curr+0x5c/0xb0
> > [    8.105258]  check_preempt_curr+0x58/0x90
> > [    8.109258]  ttwu_do_wakeup+0x2c/0x190
> > [    8.112996]  ttwu_do_activate+0x7c/0x114
> > [    8.116909]  try_to_wake_up+0x388/0x670
> > [    8.120735]  wake_up_process+0x24/0x30
> > [    8.124474]  swake_up_one+0x48/0x9c
> > [    8.127953]  rcu_gp_kthread_wake+0x68/0x8c
> > [    8.132041]  rcu_accelerate_cbs_unlocked+0xb4/0xf0
> > [    8.136822]  rcu_core+0x520/0x694
> > [    8.140128]  rcu_core_si+0x1c/0x2c
> > [    8.143520]  __do_softirq+0x128/0x388
> > [    8.147172]  irq_exit+0xc4/0xec
> > [    8.150304]  __handle_domain_irq+0x8c/0xec
> > [    8.154394]  gic_handle_irq+0xd8/0x2f0
> > [    8.158132]  el1_irq+0xc0/0x180
> > [    8.161262]  __pi_strcmp+0x20/0x158
> > [    8.164742]  driver_register+0x68/0x140
> > [    8.168571]  __platform_driver_register+0x34/0x40
> > [    8.173265]  imx8mp_clk_driver_init+0x28/0x34
> > [    8.177614]  do_one_initcall+0x50/0x260
> > [    8.181440]  kernel_init_freeable+0x24c/0x2d4
> > [    8.185790]  kernel_init+0x20/0x134
> > [    8.189271]  ret_from_fork+0x10/0x18
> > [    8.192840] Code: a90363f7 aa0103f5 d0010957 f9401260 (b9402800) 
> > [    8.198955] ---[ end trace c24172add816c1f0 ]---
> > [    8.203562] Kernel panic - not syncing: Oops: Fatal exception in interrupt
> > [    8.210442] SMP: stopping secondary CPUs
> > [    9.258360] SMP: failed to stop secondary CPUs 0,9
> > [    9.263141] Kernel Offset: disabled
> > [    9.266617] CPU features: 0x00040002,69101108
> > [    9.270963] Memory Limit: none
> > [    9.274024] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
> 
> Please feed this stacktrace to scripts/decode_stacktrace.sh so that I
> can get an idea about what is going wrong. I bet something is playing
> ungodly games with the one of the IPIs, and things go horribly wrong.

hey Marc,
  Sure:

[    7.927289] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
[    7.936326] Mem abort info:
[    7.939108]   ESR = 0x96000004
[    7.942151]   EC = 0x25: DABT (current EL), IL = 32 bits
[    7.947451]   SET = 0, FnV = 0
[    7.950494]   EA = 0, S1PTW = 0
[    7.953624] Data abort info:
[    7.956492]   ISV = 0, ISS = 0x00000004
[    7.960316]   CM = 0, WnR = 0
[    7.963273] [0000000000000028] user address but active_mm is swapper
[    7.969616] Internal error: Oops: 96000004 [#1] SMP
[    7.974483] Modules linked in:
[    7.977531] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8 #19
[    7.983874] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    7.990737] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
[    7.996732] pc : __ipi_send_mask (/home/ubuntu/linux/./include/linux/irqdomain.h:537 /home/ubuntu/linux/kernel/irq/ipi.c:283) 
[    8.000910] lr : smp_cross_call (/home/ubuntu/linux/arch/arm64/kernel/smp.c:958) 
[    8.004913] sp : ffff800012753c10
[    8.008216] x29: ffff800012753c10 x28: ffff000100de5d00
[    8.013521] x27: 000000000000000a x26: ffff80001225da20
[    8.018825] x25: 0000000000000000 x24: ffff000ff62719b0
[    8.024129] x23: ffff80001225d000 x22: ffff800012368108
[    8.029433] x21: ffff800010f69a20 x20: 0000000000000000
[    8.034737] x19: ffff000100143c60 x18: 0000000000000020
[    8.040041] x17: 000000008e74252f x16: 00000000bf0ab2ad
[    8.045345] x15: ffffffffffffffff x14: 0000000000000000
[    8.050649] x13: 003d090000000000 x12: 00003d0900000000
[    8.055953] x11: 0000000000000000 x10: 00003d0900000000
[    8.061257] x9 : ffff800010027f14 x8 : 0000000000000000
[    8.066561] x7 : 00000000ffffffff x6 : ffff000ff6148698
[    8.071865] x5 : ffff80001159d040 x4 : ffff80001159d110
[    8.077169] x3 : ffff800010f69a00 x2 : 0000000000000000
[    8.082473] x1 : ffff800010f69a20 x0 : 0000000000000000
[    8.087777] Call trace:
[    8.090213] __ipi_send_mask (/home/ubuntu/linux/./include/linux/irqdomain.h:537 /home/ubuntu/linux/kernel/irq/ipi.c:283) 
[    8.094038] smp_cross_call (/home/ubuntu/linux/arch/arm64/kernel/smp.c:958) 
[    8.097691] smp_send_reschedule (/home/ubuntu/linux/arch/arm64/kernel/smp.c:1011) 
[    8.101778] resched_curr (/home/ubuntu/linux/kernel/sched/core.c:621) 
[    8.105258] check_preempt_curr (/home/ubuntu/linux/kernel/sched/core.c:1715) 
[    8.109258] ttwu_do_wakeup (/home/ubuntu/linux/kernel/sched/core.c:2940) 
[    8.112996] ttwu_do_activate (/home/ubuntu/linux/kernel/sched/core.c:2991) 
[    8.116909] try_to_wake_up (/home/ubuntu/linux/kernel/sched/sched.h:1258 /home/ubuntu/linux/kernel/sched/sched.h:1353 /home/ubuntu/linux/kernel/sched/core.c:3187 /home/ubuntu/linux/kernel/sched/core.c:3464) 
[    8.120735] wake_up_process (/home/ubuntu/linux/kernel/sched/core.c:3534) 
[    8.124474] swake_up_one (/home/ubuntu/linux/./include/linux/list.h:135 /home/ubuntu/linux/./include/linux/list.h:204 /home/ubuntu/linux/kernel/sched/swait.c:31 /home/ubuntu/linux/kernel/sched/swait.c:22 /home/ubuntu/linux/kernel/sched/swait.c:53) 
[    8.127953] rcu_gp_kthread_wake (/home/ubuntu/linux/kernel/rcu/tree.c:1528) 
[    8.132041] rcu_accelerate_cbs_unlocked (/home/ubuntu/linux/kernel/rcu/tree.c:1606) 
[    8.136822] rcu_core (/home/ubuntu/linux/kernel/rcu/tree_plugin.h:2801 /home/ubuntu/linux/kernel/rcu/tree.c:2786) 
[    8.140128] rcu_core_si (/home/ubuntu/linux/kernel/rcu/tree.c:2808) 
[    8.143520] __do_softirq (/home/ubuntu/linux/./arch/arm64/include/asm/jump_label.h:21 /home/ubuntu/linux/./include/linux/jump_label.h:200 /home/ubuntu/linux/./include/trace/events/irq.h:142 /home/ubuntu/linux/kernel/softirq.c:346) 
[    8.147172] irq_exit (/home/ubuntu/linux/./arch/arm64/include/asm/percpu.h:43 /home/ubuntu/linux/kernel/softirq.c:402 /home/ubuntu/linux/kernel/softirq.c:424 /home/ubuntu/linux/kernel/softirq.c:446) 
[    8.150304] __handle_domain_irq (/home/ubuntu/linux/./include/asm-generic/irq_regs.h:29 /home/ubuntu/linux/kernel/irq/irqdesc.c:693) 
[    8.154394] gic_handle_irq (/home/ubuntu/linux/./arch/arm64/include/asm/arch_gicv3.h:45 /home/ubuntu/linux/drivers/irqchip/irq-gic-v3.c:222 /home/ubuntu/linux/drivers/irqchip/irq-gic-v3.c:649) 
[    8.158132] el1_irq (/home/ubuntu/linux/arch/arm64/kernel/entry.S:671) 
[    8.161262] __pi_strcmp (/home/ubuntu/linux/arch/arm64/lib/strcmp.S:66) 
[    8.164742] driver_register (/home/ubuntu/linux/drivers/base/driver.c:216 /home/ubuntu/linux/drivers/base/driver.c:164) 
[    8.168571] __platform_driver_register (/home/ubuntu/linux/drivers/base/platform.c:896) 
[    8.173265] imx8mp_clk_driver_init (/home/ubuntu/linux/drivers/clk/imx/clk-imx8mp.c:769) 
[    8.177614] do_one_initcall (/home/ubuntu/linux/init/main.c:1226) 
[    8.181440] kernel_init_freeable (/home/ubuntu/linux/init/main.c:1298 /home/ubuntu/linux/init/main.c:1315 /home/ubuntu/linux/init/main.c:1335 /home/ubuntu/linux/init/main.c:1537) 
[    8.185790] kernel_init (/home/ubuntu/linux/init/main.c:1426) 
[    8.189271] ret_from_fork (/home/ubuntu/linux/arch/arm64/kernel/entry.S:961) 
[ 8.192840] Code: a90363f7 aa0103f5 d0010957 f9401260 (b9402800)
All code
========
   0:	a90363f7 	stp	x23, x24, [sp, #48]
   4:	aa0103f5 	mov	x21, x1
   8:	d0010957 	adrp	x23, 0x212a000
   c:	f9401260 	ldr	x0, [x19, #32]
  10:*	b9402800 	ldr	w0, [x0, #40]		<-- trapping instruction

Code starting with the faulting instruction
===========================================
   0:	b9402800 	ldr	w0, [x0, #40]
[    8.198955] ---[ end trace c24172add816c1f0 ]---
[    8.203562] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[    8.210442] SMP: stopping secondary CPUs
[    9.258360] SMP: failed to stop secondary CPUs 0,9
[    9.263141] Kernel Offset: disabled
[    9.266617] CPU features: 0x00040002,69101108
[    9.270963] Memory Limit: none
[    9.274024] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---


> Now, here's a hunch: in the fine TX1 tradition, the firmware is broken
> and the GTDT table looks unusable. Amusingly, the crash happens right
> after the SBSA watchdog fails to probe.

Yeah, I noticed that, but didn't highlight it as I didn't see it in
the backtrace...

> And looking at the code that implements that driver, it looks dodgy as
> hell, as it unmaps an interrupt it doesn't even know is valid. And it
> does that right when the driver fails the way you experienced it. If,
> by any chance, the interrupt field is 0 in the firmware table, this
> results in SGI0 being unmapped. Given that this is the rescheduling
> interrupt, fireworks happen.

... and that explains why. I wouldn't have gotten there, but wish I'd
thought to test w/ the watchdog compiled out :(

> Can you have a go with the patchlet below, and let me know if that
> helps?

It does!

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x431f0a11]
[    0.000000] Linux version 5.12.0-rc8+ (ubuntu at seidel) (gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0, GNU ld (GNU Binutils for Ubuntu) 2.36.1) #20 SMP Wed Apr 21 14:22:16 UTC 2021
[    0.000000] Machine model: Cavium ThunderX CN88XX board
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi: ESRT=0xffce0ff18 SMBIOS 3.0=0xfffb0000 ACPI 2.0=0xffec60000 MEMRESERVE=0xffc889d98 
[    0.000000] esrt: Reserving ESRT space from 0x0000000ffce0ff18 to 0x0000000ffce0ff50.
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x0000000FFEC60000 000024 (v02 ALASKA)
[    0.000000] ACPI: XSDT 0x0000000FFEC60028 00008C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x0000000FFEC600B8 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x0000000FFEC601D0 00220B (v02 CAVIUM THUNDERX 00000001 INTL 20130517)
[    0.000000] ACPI: SPMI 0x0000000FFEC623E0 000041 (v05 ALASKA A M I    00000000 AMI. 00000000)
[    0.000000] ACPI: FIDT 0x0000000FFEC62428 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: APIC 0x0000000FFEC624C8 000F68 (v03 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: DBG2 0x0000000FFEC63430 000067 (v01 CAVIUM CN88XDBG 00000000 INTL 20150619)
[    0.000000] ACPI: GTDT 0x0000000FFEC63498 0000E0 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: IORT 0x0000000FFEC63578 0013D4 (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: MCFG 0x0000000FFEC64950 00006C (v01 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SSDT 0x0000000FFEC649C0 00089C (v02 CAVIUM NETWORK  00000001 INTL 20150619)
[    0.000000] ACPI: OEM1 0x0000000FFEC65260 0001E8 (v02 CAVIUM THUNDERX 00000001 INTL 20150619)
[    0.000000] ACPI: SLIT 0x0000000FFEC65448 000030 (v01 CAVIUM TEMPLATE 00000001 INTL 20150619)
[    0.000000] ACPI: SPCR 0x0000000FFEC65478 000050 (v02 A M I  APTIO V  01072009 AMI. 0005000B)
[    0.000000] ACPI: BGRT 0x0000000FFEC654C8 000038 (v01 ALASKA A M I    01072009 AMI  00010013)
[    0.000000] ACPI: SPCR: console: pl011,mmio32,0x87e024000000,115200
[    0.000000] efi_bgrt: Ignoring BGRT: Incorrect BMP magic number 0x3707 (expected 0x4d42)
[    0.000000] NUMA: Failed to initialise from firmware
[    0.000000] NUMA: Faking a node at [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000] NUMA: NODE_DATA [mem 0xff677c480-0xff6780fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000500000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000000100000000-0x0000000fff0fffff]
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000500000-0x0000000000dfffff]
[    0.000000]   node   0: [mem 0x0000000000e00000-0x000000000fffffff]
[    0.000000]   node   0: [mem 0x0000000010000000-0x00000000102fffff]
[    0.000000]   node   0: [mem 0x0000000010300000-0x00000000fff9ffff]
[    0.000000]   node   0: [mem 0x00000000fffa0000-0x00000000ffffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x0000000fee6affff]
[    0.000000]   node   0: [mem 0x0000000fee6b0000-0x0000000fee6cffff]
[    0.000000]   node   0: [mem 0x0000000fee6d0000-0x0000000ffac2ffff]
[    0.000000]   node   0: [mem 0x0000000ffac30000-0x0000000ffb0affff]
[    0.000000]   node   0: [mem 0x0000000ffb0b0000-0x0000000ffc8bffff]
[    0.000000]   node   0: [mem 0x0000000ffc8c0000-0x0000000ffc91ffff]
[    0.000000]   node   0: [mem 0x0000000ffc920000-0x0000000ffca3ffff]
[    0.000000]   node   0: [mem 0x0000000ffca40000-0x0000000ffca4ffff]
[    0.000000]   node   0: [mem 0x0000000ffca50000-0x0000000ffcdbffff]
[    0.000000]   node   0: [mem 0x0000000ffcdc0000-0x0000000ffd12ffff]
[    0.000000]   node   0: [mem 0x0000000ffd130000-0x0000000ffec2ffff]
[    0.000000]   node   0: [mem 0x0000000ffec30000-0x0000000ffec5ffff]
[    0.000000]   node   0: [mem 0x0000000ffec60000-0x0000000ffec6ffff]
[    0.000000]   node   0: [mem 0x0000000ffec70000-0x0000000ffed1ffff]
[    0.000000]   node   0: [mem 0x0000000ffed20000-0x0000000fff0fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000500000-0x0000000fff0fffff]
[    0.000000] On node 0 totalpages: 16772096
[    0.000000]   DMA zone: 16364 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 1047296 pages, LIFO batch:63
[    0.000000]   Normal zone: 245700 pages used for memmap
[    0.000000]   Normal zone: 15724800 pages, LIFO batch:63
[    0.000000]   Normal zone: 256 pages in unavailable ranges
[    0.000000] cma: Reserved 32 MiB at 0x00000000fdc00000
[    0.000000] psci: probing for conduit method from ACPI.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS resident on physical CPU 0x0
[    0.000000] ACPI: SRAT not present
[    0.000000] percpu: Embedded 33 pages/cpu s98072 r8192 d28904 u135168
[    0.000000] pcpu-alloc: s98072 r8192 d28904 u135168 alloc=33*4096
[    0.000000] pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 
[    0.000000] pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15 
[    0.000000] pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23 
[    0.000000] pcpu-alloc: [0] 24 [0] 25 [0] 26 [0] 27 [0] 28 [0] 29 [0] 30 [0] 31 
[    0.000000] pcpu-alloc: [0] 32 [0] 33 [0] 34 [0] 35 [0] 36 [0] 37 [0] 38 [0] 39 
[    0.000000] pcpu-alloc: [0] 40 [0] 41 [0] 42 [0] 43 [0] 44 [0] 45 [0] 46 [0] 47 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: GIC system register CPU interface
[    0.000000] CPU features: detected: Software prefetching using PRFM
[    0.000000] CPU features: detected: Cavium erratum 27456
[    0.000000] CPU features: detected: Cavium erratum 30115
[    0.000000] CPU features: kernel page table isolation forced OFF by ARM64_WORKAROUND_CAVIUM_27456
[    0.000000] CPU features: detected: Spectre-v2
[    0.000000] CPU features: detected: Spectre-v4
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16510032
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-dannf root=UUID=76e81d96-78e4-4432-a490-bb852f6111e8 ro sysrq_always_enabled acpi=force
[    0.000000] sysrq: sysrq always enabled.
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 192512 bytes
[    0.000000] printk: log_buf_len min size: 262144 bytes
[    0.000000] printk: log_buf_len: 524288 bytes
[    0.000000] printk: early log buf free: 255872(97%)
[    0.000000] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
[    0.000000] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x00000000f9c00000-0x00000000fdc00000] (64MB)
[    0.000000] Memory: 65572072K/67088384K available (15616K kernel code, 3626K rwdata, 11808K rodata, 7616K init, 1157K bss, 1483544K reserved, 32768K cma-reserved)
[    0.000000] random: get_random_u64 called from __kmem_cache_create+0x38/0x5b4 with crng_init=0
[    0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=48, Nodes=1
[    0.000000] ftrace: allocating 49728 entries in 195 pages
[    0.000000] ftrace: allocated 195 pages with 4 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=48.
[    0.000000] 	Rude variant of Tasks RCU enabled.
[    0.000000] 	Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=48
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
[    0.000000] GIC: enabling workaround for GICv3: Cavium erratum 38539
[    0.000000] GICv3: 128 SPIs implemented
[    0.000000] GICv3: 0 Extended SPIs implemented
[    0.000000] GICv3: Distributor has no Range Selector support
[    0.000000] GICv3: 16 PPIs implemented
[    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000801080000000
[    0.000000] ACPI: SRAT not present
[    0.000000] ITS [mem 0x801000020000-0x80100003ffff]
[    0.000000] ITS at 0x0000801000020000: Devices Table too large, reduce ids 21->19
[    0.000000] ITS at 0x0000801000020000: allocated 524288 Devices @100800000 (flat, esz 8, psz 64K, shr 1)
[    0.000000] GICv3: using LPI property table @0x0000000100270000
[    0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000100280000
[    0.000000] arch_timer: Failed to initialize memory-mapped timer.
[    0.000000] arch_timer: cp15 timer(s) running at 100.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[    0.000000] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps every 4398046511100ns
[    0.000150] Console: colour dummy device 80x25
[    0.000232] ACPI: Core revision 20210105
[    0.000452] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=400000)
[    0.000462] pid_max: default: 49152 minimum: 384
[    0.000575] LSM: Security Framework initializing
[    0.000590] Yama: becoming mindful.
[    0.000650] AppArmor: AppArmor initialized
[    0.000804] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000869] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.001661] ACPI PPTT: No PPTT table found, CPU and cache topology may be inaccurate
[    0.002248] rcu: Hierarchical SRCU implementation.
[    0.002999] Platform MSI: ITS at 0x801000020000 domain created
[    0.003014] PCI/MSI: ITS at 0x801000020000 domain created
[    0.003024] fsl-mc MSI: ITS at 0x801000020000 domain created
[    0.003041] Remapping and enabling EFI services.
[    0.005152] smp: Bringing up secondary CPUs ...
[    0.005634] Detected VIPT I-cache on CPU1
[    0.005649] GICv3: CPU1: found redistributor 1 region 0:0x0000801080020000
[    0.005674] GICv3: CPU1: using allocated LPI pending table @0x0000000100290000
[    0.005694] CPU1: Booted secondary processor 0x0000000001 [0x431f0a11]
[    0.006251] Detected VIPT I-cache on CPU2
[    0.006262] GICv3: CPU2: found redistributor 2 region 0:0x0000801080040000
[    0.006286] GICv3: CPU2: using allocated LPI pending table @0x00000001002a0000
[    0.006305] CPU2: Booted secondary processor 0x0000000002 [0x431f0a11]
[    0.006848] Detected VIPT I-cache on CPU3
[    0.006858] GICv3: CPU3: found redistributor 3 region 0:0x0000801080060000
[    0.006884] GICv3: CPU3: using allocated LPI pending table @0x00000001002b0000
[    0.006903] CPU3: Booted secondary processor 0x0000000003 [0x431f0a11]
[    0.007444] Detected VIPT I-cache on CPU4
[    0.007455] GICv3: CPU4: found redistributor 4 region 0:0x0000801080080000
[    0.007480] GICv3: CPU4: using allocated LPI pending table @0x00000001002c0000
[    0.007500] CPU4: Booted secondary processor 0x0000000004 [0x431f0a11]
[    0.008046] Detected VIPT I-cache on CPU5
[    0.008057] GICv3: CPU5: found redistributor 5 region 0:0x00008010800a0000
[    0.008082] GICv3: CPU5: using allocated LPI pending table @0x00000001002d0000
[    0.008102] CPU5: Booted secondary processor 0x0000000005 [0x431f0a11]
[    0.008639] Detected VIPT I-cache on CPU6
[    0.008650] GICv3: CPU6: found redistributor 6 region 0:0x00008010800c0000
[    0.008677] GICv3: CPU6: using allocated LPI pending table @0x00000001002e0000
[    0.008697] CPU6: Booted secondary processor 0x0000000006 [0x431f0a11]
[    0.009242] Detected VIPT I-cache on CPU7
[    0.009253] GICv3: CPU7: found redistributor 7 region 0:0x00008010800e0000
[    0.009279] GICv3: CPU7: using allocated LPI pending table @0x00000001002f0000
[    0.009299] CPU7: Booted secondary processor 0x0000000007 [0x431f0a11]
[    0.009839] Detected VIPT I-cache on CPU8
[    0.009851] GICv3: CPU8: found redistributor 8 region 0:0x0000801080100000
[    0.009876] GICv3: CPU8: using allocated LPI pending table @0x0000000100300000
[    0.009897] CPU8: Booted secondary processor 0x0000000008 [0x431f0a11]
[    0.010450] Detected VIPT I-cache on CPU9
[    0.010462] GICv3: CPU9: found redistributor 9 region 0:0x0000801080120000
[    0.010487] GICv3: CPU9: using allocated LPI pending table @0x0000000100310000
[    0.010508] CPU9: Booted secondary processor 0x0000000009 [0x431f0a11]
[    0.011054] Detected VIPT I-cache on CPU10
[    0.011066] GICv3: CPU10: found redistributor a region 0:0x0000801080140000
[    0.011091] GICv3: CPU10: using allocated LPI pending table @0x0000000100320000
[    0.011113] CPU10: Booted secondary processor 0x000000000a [0x431f0a11]
[    0.011661] Detected VIPT I-cache on CPU11
[    0.011673] GICv3: CPU11: found redistributor b region 0:0x0000801080160000
[    0.011699] GICv3: CPU11: using allocated LPI pending table @0x0000000100330000
[    0.011721] CPU11: Booted secondary processor 0x000000000b [0x431f0a11]
[    0.012279] Detected VIPT I-cache on CPU12
[    0.012291] GICv3: CPU12: found redistributor c region 0:0x0000801080180000
[    0.012316] GICv3: CPU12: using allocated LPI pending table @0x0000000100340000
[    0.012338] CPU12: Booted secondary processor 0x000000000c [0x431f0a11]
[    0.012901] Detected VIPT I-cache on CPU13
[    0.012914] GICv3: CPU13: found redistributor d region 0:0x00008010801a0000
[    0.012941] GICv3: CPU13: using allocated LPI pending table @0x0000000100350000
[    0.012963] CPU13: Booted secondary processor 0x000000000d [0x431f0a11]
[    0.013511] Detected VIPT I-cache on CPU14
[    0.013524] GICv3: CPU14: found redistributor e region 0:0x00008010801c0000
[    0.013551] GICv3: CPU14: using allocated LPI pending table @0x0000000100360000
[    0.013573] CPU14: Booted secondary processor 0x000000000e [0x431f0a11]
[    0.014123] Detected VIPT I-cache on CPU15
[    0.014136] GICv3: CPU15: found redistributor f region 0:0x00008010801e0000
[    0.014165] GICv3: CPU15: using allocated LPI pending table @0x0000000100370000
[    0.014188] CPU15: Booted secondary processor 0x000000000f [0x431f0a11]
[    0.014732] Detected VIPT I-cache on CPU16
[    0.014745] GICv3: CPU16: found redistributor 100 region 0:0x0000801080200000
[    0.014772] GICv3: CPU16: using allocated LPI pending table @0x0000000100380000
[    0.014795] CPU16: Booted secondary processor 0x0000000100 [0x431f0a11]
[    0.015335] Detected VIPT I-cache on CPU17
[    0.015348] GICv3: CPU17: found redistributor 101 region 0:0x0000801080220000
[    0.015375] GICv3: CPU17: using allocated LPI pending table @0x0000000100390000
[    0.015398] CPU17: Booted secondary processor 0x0000000101 [0x431f0a11]
[    0.015967] Detected VIPT I-cache on CPU18
[    0.015980] GICv3: CPU18: found redistributor 102 region 0:0x0000801080240000
[    0.016007] GICv3: CPU18: using allocated LPI pending table @0x00000001003a0000
[    0.016030] CPU18: Booted secondary processor 0x0000000102 [0x431f0a11]
[    0.016592] Detected VIPT I-cache on CPU19
[    0.016606] GICv3: CPU19: found redistributor 103 region 0:0x0000801080260000
[    0.016634] GICv3: CPU19: using allocated LPI pending table @0x00000001003b0000
[    0.016658] CPU19: Booted secondary processor 0x0000000103 [0x431f0a11]
[    0.017210] Detected VIPT I-cache on CPU20
[    0.017224] GICv3: CPU20: found redistributor 104 region 0:0x0000801080280000
[    0.017252] GICv3: CPU20: using allocated LPI pending table @0x00000001003c0000
[    0.017276] CPU20: Booted secondary processor 0x0000000104 [0x431f0a11]
[    0.017823] Detected VIPT I-cache on CPU21
[    0.017837] GICv3: CPU21: found redistributor 105 region 0:0x00008010802a0000
[    0.017864] GICv3: CPU21: using allocated LPI pending table @0x00000001003d0000
[    0.017889] CPU21: Booted secondary processor 0x0000000105 [0x431f0a11]
[    0.018451] Detected VIPT I-cache on CPU22
[    0.018465] GICv3: CPU22: found redistributor 106 region 0:0x00008010802c0000
[    0.018493] GICv3: CPU22: using allocated LPI pending table @0x00000001003e0000
[    0.018517] CPU22: Booted secondary processor 0x0000000106 [0x431f0a11]
[    0.019081] Detected VIPT I-cache on CPU23
[    0.019095] GICv3: CPU23: found redistributor 107 region 0:0x00008010802e0000
[    0.019124] GICv3: CPU23: using allocated LPI pending table @0x00000001003f0000
[    0.019148] CPU23: Booted secondary processor 0x0000000107 [0x431f0a11]
[    0.019699] Detected VIPT I-cache on CPU24
[    0.019714] GICv3: CPU24: found redistributor 108 region 0:0x0000801080300000
[    0.019741] GICv3: CPU24: using allocated LPI pending table @0x0000000100c00000
[    0.019766] CPU24: Booted secondary processor 0x0000000108 [0x431f0a11]
[    0.020343] Detected VIPT I-cache on CPU25
[    0.020358] GICv3: CPU25: found redistributor 109 region 0:0x0000801080320000
[    0.020386] GICv3: CPU25: using allocated LPI pending table @0x0000000100c10000
[    0.020411] CPU25: Booted secondary processor 0x0000000109 [0x431f0a11]
[    0.020962] Detected VIPT I-cache on CPU26
[    0.020977] GICv3: CPU26: found redistributor 10a region 0:0x0000801080340000
[    0.021005] GICv3: CPU26: using allocated LPI pending table @0x0000000100c20000
[    0.021030] CPU26: Booted secondary processor 0x000000010a [0x431f0a11]
[    0.021598] Detected VIPT I-cache on CPU27
[    0.021613] GICv3: CPU27: found redistributor 10b region 0:0x0000801080360000
[    0.021641] GICv3: CPU27: using allocated LPI pending table @0x0000000100c30000
[    0.021667] CPU27: Booted secondary processor 0x000000010b [0x431f0a11]
[    0.022219] Detected VIPT I-cache on CPU28
[    0.022234] GICv3: CPU28: found redistributor 10c region 0:0x0000801080380000
[    0.022263] GICv3: CPU28: using allocated LPI pending table @0x0000000100c40000
[    0.022288] CPU28: Booted secondary processor 0x000000010c [0x431f0a11]
[    0.022850] Detected VIPT I-cache on CPU29
[    0.022865] GICv3: CPU29: found redistributor 10d region 0:0x00008010803a0000
[    0.022895] GICv3: CPU29: using allocated LPI pending table @0x0000000100c50000
[    0.022921] CPU29: Booted secondary processor 0x000000010d [0x431f0a11]
[    0.023482] Detected VIPT I-cache on CPU30
[    0.023498] GICv3: CPU30: found redistributor 10e region 0:0x00008010803c0000
[    0.023527] GICv3: CPU30: using allocated LPI pending table @0x0000000100c60000
[    0.023553] CPU30: Booted secondary processor 0x000000010e [0x431f0a11]
[    0.024116] Detected VIPT I-cache on CPU31
[    0.024132] GICv3: CPU31: found redistributor 10f region 0:0x00008010803e0000
[    0.024161] GICv3: CPU31: using allocated LPI pending table @0x0000000100c70000
[    0.024188] CPU31: Booted secondary processor 0x000000010f [0x431f0a11]
[    0.024762] Detected VIPT I-cache on CPU32
[    0.024778] GICv3: CPU32: found redistributor 200 region 0:0x0000801080400000
[    0.024806] GICv3: CPU32: using allocated LPI pending table @0x0000000100c80000
[    0.024833] CPU32: Booted secondary processor 0x0000000200 [0x431f0a11]
[    0.025402] Detected VIPT I-cache on CPU33
[    0.025418] GICv3: CPU33: found redistributor 201 region 0:0x0000801080420000
[    0.025447] GICv3: CPU33: using allocated LPI pending table @0x0000000100c90000
[    0.025475] CPU33: Booted secondary processor 0x0000000201 [0x431f0a11]
[    0.026040] Detected VIPT I-cache on CPU34
[    0.026056] GICv3: CPU34: found redistributor 202 region 0:0x0000801080440000
[    0.026086] GICv3: CPU34: using allocated LPI pending table @0x0000000100ca0000
[    0.026113] CPU34: Booted secondary processor 0x0000000202 [0x431f0a11]
[    0.026681] Detected VIPT I-cache on CPU35
[    0.026698] GICv3: CPU35: found redistributor 203 region 0:0x0000801080460000
[    0.026727] GICv3: CPU35: using allocated LPI pending table @0x0000000100cb0000
[    0.026755] CPU35: Booted secondary processor 0x0000000203 [0x431f0a11]
[    0.027317] Detected VIPT I-cache on CPU36
[    0.027334] GICv3: CPU36: found redistributor 204 region 0:0x0000801080480000
[    0.027364] GICv3: CPU36: using allocated LPI pending table @0x0000000100cc0000
[    0.027392] CPU36: Booted secondary processor 0x0000000204 [0x431f0a11]
[    0.027955] Detected VIPT I-cache on CPU37
[    0.027972] GICv3: CPU37: found redistributor 205 region 0:0x00008010804a0000
[    0.028002] GICv3: CPU37: using allocated LPI pending table @0x0000000100cd0000
[    0.028030] CPU37: Booted secondary processor 0x0000000205 [0x431f0a11]
[    0.028609] Detected VIPT I-cache on CPU38
[    0.028626] GICv3: CPU38: found redistributor 206 region 0:0x00008010804c0000
[    0.028656] GICv3: CPU38: using allocated LPI pending table @0x0000000100ce0000
[    0.028684] CPU38: Booted secondary processor 0x0000000206 [0x431f0a11]
[    0.029243] Detected VIPT I-cache on CPU39
[    0.029261] GICv3: CPU39: found redistributor 207 region 0:0x00008010804e0000
[    0.029291] GICv3: CPU39: using allocated LPI pending table @0x0000000100cf0000
[    0.029320] CPU39: Booted secondary processor 0x0000000207 [0x431f0a11]
[    0.029895] Detected VIPT I-cache on CPU40
[    0.029912] GICv3: CPU40: found redistributor 208 region 0:0x0000801080500000
[    0.029942] GICv3: CPU40: using allocated LPI pending table @0x0000000100d00000
[    0.029971] CPU40: Booted secondary processor 0x0000000208 [0x431f0a11]
[    0.030554] Detected VIPT I-cache on CPU41
[    0.030572] GICv3: CPU41: found redistributor 209 region 0:0x0000801080520000
[    0.030603] GICv3: CPU41: using allocated LPI pending table @0x0000000100d10000
[    0.030632] CPU41: Booted secondary processor 0x0000000209 [0x431f0a11]
[    0.031197] Detected VIPT I-cache on CPU42
[    0.031214] GICv3: CPU42: found redistributor 20a region 0:0x0000801080540000
[    0.031245] GICv3: CPU42: using allocated LPI pending table @0x0000000100d20000
[    0.031275] CPU42: Booted secondary processor 0x000000020a [0x431f0a11]
[    0.031853] Detected VIPT I-cache on CPU43
[    0.031871] GICv3: CPU43: found redistributor 20b region 0:0x0000801080560000
[    0.031904] GICv3: CPU43: using allocated LPI pending table @0x0000000100d30000
[    0.031933] CPU43: Booted secondary processor 0x000000020b [0x431f0a11]
[    0.032528] Detected VIPT I-cache on CPU44
[    0.032546] GICv3: CPU44: found redistributor 20c region 0:0x0000801080580000
[    0.032578] GICv3: CPU44: using allocated LPI pending table @0x0000000100d40000
[    0.032607] CPU44: Booted secondary processor 0x000000020c [0x431f0a11]
[    0.033191] Detected VIPT I-cache on CPU45
[    0.033210] GICv3: CPU45: found redistributor 20d region 0:0x00008010805a0000
[    0.033241] GICv3: CPU45: using allocated LPI pending table @0x0000000100d50000
[    0.033271] CPU45: Booted secondary processor 0x000000020d [0x431f0a11]
[    0.033843] Detected VIPT I-cache on CPU46
[    0.033861] GICv3: CPU46: found redistributor 20e region 0:0x00008010805c0000
[    0.033893] GICv3: CPU46: using allocated LPI pending table @0x0000000100d60000
[    0.033924] CPU46: Booted secondary processor 0x000000020e [0x431f0a11]
[    0.034503] Detected VIPT I-cache on CPU47
[    0.034522] GICv3: CPU47: found redistributor 20f region 0:0x00008010805e0000
[    0.034554] GICv3: CPU47: using allocated LPI pending table @0x0000000100d70000
[    0.034584] CPU47: Booted secondary processor 0x000000020f [0x431f0a11]
[    0.034694] smp: Brought up 1 node, 48 CPUs
[    0.034960] SMP: Total of 48 processors activated.
[    0.034966] CPU features: detected: Data cache clean to the PoU not required for I/D coherence
[    0.034971] CPU features: detected: CRC32 instructions
[    0.035202] CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching
[    0.044471] CPU: All CPU(s) started at EL2
[    0.044630] alternatives: patching kernel code
[    0.058585] devtmpfs: initialized
[    0.078235] Registered cp15_barrier emulation handler
[    0.078260] Registered setend emulation handler
[    0.078268] KASLR disabled due to lack of seed
[    0.078435] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.078504] futex hash table entries: 16384 (order: 8, 1048576 bytes, linear)
[    0.079924] pinctrl core: initialized pinctrl subsystem
[    0.080485] SMBIOS 3.0.0 present.
[    0.080500] DMI: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
[    0.080988] NET: Registered protocol family 16
[    0.082760] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations
[    0.083231] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.083710] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.083743] audit: initializing netlink subsys (disabled)
[    0.083898] audit: type=2000 audit(0.080:1): state=initialized audit_enabled=0 res=1
[    0.084439] thermal_sys: Registered thermal governor 'fair_share'
[    0.084445] thermal_sys: Registered thermal governor 'bang_bang'
[    0.084450] thermal_sys: Registered thermal governor 'step_wise'
[    0.084454] thermal_sys: Registered thermal governor 'user_space'
[    0.084459] thermal_sys: Registered thermal governor 'power_allocator'
[    0.084640] cpuidle: using governor ladder
[    0.084902] cpuidle: using governor menu
[    0.085048] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.085632] ASID allocator initialised with 65536 entries
[    0.085922] ACPI: bus type PCI registered
[    0.085930] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.086167] Serial: AMBA PL011 UART driver
[    0.096900] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.096908] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.096914] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.096919] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.101966] ACPI: Added _OSI(Module Device)
[    0.101973] ACPI: Added _OSI(Processor Device)
[    0.101978] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.101983] ACPI: Added _OSI(Processor Aggregator Device)
[    0.101988] ACPI: Added _OSI(Linux-Dell-Video)
[    0.101993] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.101998] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.105918] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.107812] ACPI: Interpreter enabled
[    0.107820] ACPI: Using GIC for interrupt routing
[    0.107848] ACPI: MCFG table detected, 4 entries
[    0.131510] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-1f])
[    0.131526] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    0.131675] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    0.131804] acpi PNP0A08:00: _OSC: OS now controls [PCIeCapability]
[    0.132264] acpi PNP0A08:00: ECAM area [mem 0x848000000000-0x848001ffffff] reserved by CAVA02C:00
[    0.132282] acpi PNP0A08:00: ECAM at [mem 0x848000000000-0x848001ffffff] for [bus 00-1f]
[    0.132438] PCI host bridge to bus 0000:00
[    0.132446] pci_bus 0000:00: root bus resource [mem 0x801000000000-0x807fffffffff window]
[    0.132453] pci_bus 0000:00: root bus resource [mem 0x838000000000-0x841fffffffff window]
[    0.132460] pci_bus 0000:00: root bus resource [mem 0x846000000000-0x847fffffffff window]
[    0.132466] pci_bus 0000:00: root bus resource [mem 0x868000000000-0x87e023ffffff window]
[    0.132472] pci_bus 0000:00: root bus resource [mem 0x87e026000000-0x87e0bfffffff window]
[    0.132479] pci_bus 0000:00: root bus resource [mem 0x87e0c6000000-0x87ffffffffff window]
[    0.132486] pci_bus 0000:00: root bus resource [bus 00-1f]
[    0.132516] pci 0000:00:01.0: [177d:a002] type 01 class 0x060400
[    0.132688] pci 0000:00:09.0: [177d:a018] type 00 class 0x120000
[    0.132723] pci 0000:00:09.0: BAR 0: [mem 0x87e040000000-0x87e0400fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    0.132733] pci 0000:00:09.0: VF BAR 0: [mem 0x840000800000-0x8400008fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.153628] pci 0000:00:09.0: VF(n) BAR0 space: [mem 0x840000800000-0x8400008fffff 64bit] (contains BAR0 for 1 VFs)
[    1.153780] pci 0000:00:10.0: [177d:a01b] type 00 class 0x0c0330
[    1.153817] pci 0000:00:10.0: BAR 0: [mem 0x868000000000-0x8680001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153826] pci 0000:00:10.0: BAR 4: [mem 0x868000200000-0x8680002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153953] pci 0000:00:11.0: [177d:a01b] type 00 class 0x0c0330
[    1.153989] pci 0000:00:11.0: BAR 0: [mem 0x869000000000-0x8690001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.153998] pci 0000:00:11.0: BAR 4: [mem 0x869000200000-0x8690002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154123] pci 0000:00:14.0: [177d:a002] type 01 class 0x060400
[    1.154325] pci 0000:01:00.0: [177d:a001] type 00 class 0x088000
[    1.154361] pci 0000:01:00.0: BAR 0: [mem 0x87e0fc000000-0x87e0fc0fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154370] pci 0000:01:00.0: BAR 4: [mem 0x87e0fcf00000-0x87e0fcffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154497] pci 0000:01:00.1: [177d:a00e] type 00 class 0x088000
[    1.154532] pci 0000:01:00.1: BAR 0: [mem 0x87e006000000-0x87e0067fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154541] pci 0000:01:00.1: BAR 4: [mem 0x87e006f00000-0x87e006ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154661] pci 0000:01:01.3: [177d:a02b] type 00 class 0x0c8000
[    1.154696] pci 0000:01:01.3: BAR 0: [mem 0x87e005000000-0x87e0057fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154814] pci 0000:01:01.4: [177d:a010] type 00 class 0x058000
[    1.154853] pci 0000:01:01.4: BAR 0: [mem 0x87e009000000-0x87e0097fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154862] pci 0000:01:01.4: BAR 4: [mem 0x87e009f00000-0x87e009ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.154983] pci 0000:01:06.0: [177d:a02e] type 00 class 0x058000
[    1.155020] pci 0000:01:06.0: BAR 0: [mem 0x87e050000000-0x87e0507fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155029] pci 0000:01:06.0: BAR 4: [mem 0x87e050f00000-0x87e050ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155155] pci 0000:01:06.1: [177d:a02e] type 00 class 0x058000
[    1.155191] pci 0000:01:06.1: BAR 0: [mem 0x87e051000000-0x87e0517fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155200] pci 0000:01:06.1: BAR 4: [mem 0x87e051f00000-0x87e051ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155322] pci 0000:01:06.2: [177d:a02e] type 00 class 0x058000
[    1.155357] pci 0000:01:06.2: BAR 0: [mem 0x87e052000000-0x87e0527fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155366] pci 0000:01:06.2: BAR 4: [mem 0x87e052f00000-0x87e052ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155485] pci 0000:01:06.3: [177d:a02e] type 00 class 0x058000
[    1.155521] pci 0000:01:06.3: BAR 0: [mem 0x87e053000000-0x87e0537fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155530] pci 0000:01:06.3: BAR 4: [mem 0x87e053f00000-0x87e053ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155649] pci 0000:01:06.4: [177d:a02e] type 00 class 0x058000
[    1.155685] pci 0000:01:06.4: BAR 0: [mem 0x87e054000000-0x87e0547fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155694] pci 0000:01:06.4: BAR 4: [mem 0x87e054f00000-0x87e054ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155816] pci 0000:01:06.5: [177d:a02e] type 00 class 0x058000
[    1.155852] pci 0000:01:06.5: BAR 0: [mem 0x87e055000000-0x87e0557fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155861] pci 0000:01:06.5: BAR 4: [mem 0x87e055f00000-0x87e055ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.155981] pci 0000:01:06.6: [177d:a02e] type 00 class 0x058000
[    1.156016] pci 0000:01:06.6: BAR 0: [mem 0x87e056000000-0x87e0567fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156025] pci 0000:01:06.6: BAR 4: [mem 0x87e056f00000-0x87e056ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156145] pci 0000:01:06.7: [177d:a02e] type 00 class 0x058000
[    1.156184] pci 0000:01:06.7: BAR 0: [mem 0x87e057000000-0x87e0577fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156193] pci 0000:01:06.7: BAR 4: [mem 0x87e057f00000-0x87e057ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156316] pci 0000:01:07.0: [177d:a02f] type 00 class 0x058000
[    1.156352] pci 0000:01:07.0: BAR 0: [mem 0x87e058000000-0x87e0587fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156361] pci 0000:01:07.0: BAR 4: [mem 0x87e058f00000-0x87e058ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156488] pci 0000:01:07.1: [177d:a02f] type 00 class 0x058000
[    1.156524] pci 0000:01:07.1: BAR 0: [mem 0x87e059000000-0x87e0597fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156533] pci 0000:01:07.1: BAR 4: [mem 0x87e059f00000-0x87e059ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156654] pci 0000:01:07.2: [177d:a02f] type 00 class 0x058000
[    1.156689] pci 0000:01:07.2: BAR 0: [mem 0x87e05a000000-0x87e05a7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156698] pci 0000:01:07.2: BAR 4: [mem 0x87e05af00000-0x87e05affffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156821] pci 0000:01:07.3: [177d:a02f] type 00 class 0x058000
[    1.156856] pci 0000:01:07.3: BAR 0: [mem 0x87e05b000000-0x87e05b7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156865] pci 0000:01:07.3: BAR 4: [mem 0x87e05bf00000-0x87e05bffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.156985] pci 0000:01:07.4: [177d:a030] type 00 class 0x058000
[    1.157020] pci 0000:01:07.4: BAR 0: [mem 0x87e05c000000-0x87e05c7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157029] pci 0000:01:07.4: BAR 4: [mem 0x87e05cf00000-0x87e05cffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157149] pci 0000:01:07.5: [177d:a030] type 00 class 0x058000
[    1.157185] pci 0000:01:07.5: BAR 0: [mem 0x87e05d000000-0x87e05d7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157194] pci 0000:01:07.5: BAR 4: [mem 0x87e05df00000-0x87e05dffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157316] pci 0000:01:07.6: [177d:a030] type 00 class 0x058000
[    1.157352] pci 0000:01:07.6: BAR 0: [mem 0x87e05e000000-0x87e05e7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157361] pci 0000:01:07.6: BAR 4: [mem 0x87e05ef00000-0x87e05effffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157484] pci 0000:01:07.7: [177d:a030] type 00 class 0x058000
[    1.157532] pci 0000:01:07.7: BAR 0: [mem 0x87e05f000000-0x87e05f7fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157542] pci 0000:01:07.7: BAR 4: [mem 0x87e05ff00000-0x87e05fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157677] pci 0000:01:09.2: [177d:a012] type 00 class 0x0c8000
[    1.157714] pci 0000:01:09.2: BAR 0: [mem 0x87e0d2000000-0x87e0d27fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157723] pci 0000:01:09.2: BAR 4: [mem 0x87e0d2f00000-0x87e0d2ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157851] pci 0000:01:09.4: [177d:a012] type 00 class 0x0c8000
[    1.157887] pci 0000:01:09.4: BAR 0: [mem 0x87e0d4000000-0x87e0d47fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.157896] pci 0000:01:09.4: BAR 4: [mem 0x87e0d4f00000-0x87e0d4ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158018] pci 0000:01:0a.0: [177d:a022] type 00 class 0x058000
[    1.158055] pci 0000:01:0a.0: BAR 0: [mem 0x87e088000000-0x87e0887fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158064] pci 0000:01:0a.0: BAR 4: [mem 0x87e088f00000-0x87e088ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158186] pci 0000:01:0a.1: [177d:a022] type 00 class 0x058000
[    1.158222] pci 0000:01:0a.1: BAR 0: [mem 0x87e089000000-0x87e0897fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158231] pci 0000:01:0a.1: BAR 4: [mem 0x87e089f00000-0x87e089ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158354] pci 0000:01:10.0: [177d:a026] type 00 class 0x028000
[    1.158389] pci 0000:01:10.0: BAR 0: [mem 0x87e0e0000000-0x87e0e03fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158398] pci 0000:01:10.0: BAR 4: [mem 0x87e0e0400000-0x87e0e07fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158520] pci 0000:01:10.1: [177d:a026] type 00 class 0x028000
[    1.158555] pci 0000:01:10.1: BAR 0: [mem 0x87e0e1000000-0x87e0e13fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158564] pci 0000:01:10.1: BAR 4: [mem 0x87e0e1400000-0x87e0e17fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158675] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.158842] pci 0000:02:00.0: [177d:a01d] type 00 class 0x010400
[    1.158880] pci 0000:02:00.0: BAR 0: [mem 0x870000000000-0x8700007fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.158890] pci 0000:02:00.0: BAR 4: [mem 0x870000f00000-0x870000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.159004] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    1.159080] pci 0000:00:01.0: PCI bridge to [bus 01]
[    1.159093] pci 0000:00:14.0: PCI bridge to [bus 02]
[    1.159101] pci_bus 0000:00: resource 4 [mem 0x801000000000-0x807fffffffff window]
[    1.159107] pci_bus 0000:00: resource 5 [mem 0x838000000000-0x841fffffffff window]
[    1.159114] pci_bus 0000:00: resource 6 [mem 0x846000000000-0x847fffffffff window]
[    1.159120] pci_bus 0000:00: resource 7 [mem 0x868000000000-0x87e023ffffff window]
[    1.159127] pci_bus 0000:00: resource 8 [mem 0x87e026000000-0x87e0bfffffff window]
[    1.159133] pci_bus 0000:00: resource 9 [mem 0x87e0c6000000-0x87ffffffffff window]
[    1.159289] ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-1f])
[    1.159302] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.159444] acpi PNP0A08:01: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.159573] acpi PNP0A08:01: _OSC: OS now controls [PCIeCapability]
[    1.160046] acpi PNP0A08:01: ECAM area [mem 0x849000000000-0x849001ffffff] reserved by CAVA02C:01
[    1.160063] acpi PNP0A08:01: ECAM at [mem 0x849000000000-0x849001ffffff] for [bus 00-1f]
[    1.160192] PCI host bridge to bus 0001:00
[    1.160199] pci_bus 0001:00: root bus resource [mem 0x810000000000-0x817fffffffff window]
[    1.160207] pci_bus 0001:00: root bus resource [bus 00-1f]
[    1.160235] pci 0001:00:08.0: [177d:a01c] type 00 class 0x010601
[    1.160268] pci 0001:00:08.0: BAR 0: [mem 0x814000000000-0x8140001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160276] pci 0001:00:08.0: BAR 4: [mem 0x814000200000-0x8140002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160404] pci 0001:00:09.0: [177d:a01c] type 00 class 0x010601
[    1.160443] pci 0001:00:09.0: BAR 0: [mem 0x815000000000-0x8150001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160453] pci 0001:00:09.0: BAR 4: [mem 0x815000200000-0x8150002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160583] pci 0001:00:0a.0: [177d:a01c] type 00 class 0x010601
[    1.160618] pci 0001:00:0a.0: BAR 0: [mem 0x816000000000-0x8160001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160627] pci 0001:00:0a.0: BAR 4: [mem 0x816000200000-0x8160002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160752] pci 0001:00:0b.0: [177d:a01c] type 00 class 0x010601
[    1.160787] pci 0001:00:0b.0: BAR 0: [mem 0x817000000000-0x8170001fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160796] pci 0001:00:0b.0: BAR 4: [mem 0x817000200000-0x8170002fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.160928] pci_bus 0001:00: resource 4 [mem 0x810000000000-0x817fffffffff window]
[    1.161037] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
[    1.161049] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    1.161189] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    1.161317] acpi PNP0A08:02: _OSC: OS now controls [PCIeCapability]
[    1.161821] acpi PNP0A08:02: ECAM area [mem 0x84a000000000-0x84a001ffffff] reserved by CAVA02C:02
[    1.161837] acpi PNP0A08:02: ECAM at [mem 0x84a000000000-0x84a001ffffff] for [bus 00-1f]
[    1.161970] PCI host bridge to bus 0002:00
[    1.161977] pci_bus 0002:00: root bus resource [mem 0x842000000000-0x843fffffffff window]
[    1.161985] pci_bus 0002:00: root bus resource [bus 00-1f]
[    1.162008] pci 0002:00:02.0: [177d:a002] type 01 class 0x060400
[    1.162156] pci 0002:00:03.0: [177d:a01f] type 00 class 0x028000
[    1.162191] pci 0002:00:03.0: BAR 0: [mem 0x842000000000-0x84200000ffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162200] pci 0002:00:03.0: BAR 2: [mem 0x842040000000-0x84207fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162208] pci 0002:00:03.0: BAR 4: [mem 0x842000f00000-0x842000ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162399] pci 0002:01:00.0: [177d:a01e] type 00 class 0x020000
[    1.162436] pci 0002:01:00.0: BAR 0: [mem 0x843000000000-0x84303fffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162445] pci 0002:01:00.0: BAR 4: [mem 0x843060000000-0x8430600fffff 64bit] (from Enhanced Allocation, properties 0x0)
[    1.162453] pci 0002:01:00.0: VF BAR 0: [mem 0x8430a0000000-0x8430a01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    1.162462] pci 0002:01:00.0: VF BAR 4: [mem 0x8430e0000000-0x8430e01fffff 64bit] (from Enhanced Allocation, properties 0x4)
[    2.178959] pci 0002:01:00.0: VF(n) BAR0 space: [mem 0x8430a0000000-0x8430afffffff 64bit] (contains BAR0 for 128 VFs)
[    2.178973] pci 0002:01:00.0: VF(n) BAR4 space: [mem 0x8430e0000000-0x8430efffffff 64bit] (contains BAR4 for 128 VFs)
[    2.179182] pci 0002:01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.179208] pci 0002:00:02.0: PCI bridge to [bus 01]
[    2.179217] pci_bus 0002:00: resource 4 [mem 0x842000000000-0x843fffffffff window]
[    2.179326] ACPI: PCI Root Bridge [PCI3] (domain 0003 [bus 00-1f])
[    2.179339] acpi PNP0A08:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.179483] acpi PNP0A08:03: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.179614] acpi PNP0A08:03: _OSC: OS now controls [PCIeCapability]
[    2.180134] acpi PNP0A08:03: ECAM area [mem 0x84b000000000-0x84b001ffffff] reserved by CAVA02C:03
[    2.180150] acpi PNP0A08:03: ECAM at [mem 0x84b000000000-0x84b001ffffff] for [bus 00-1f]
[    2.180280] PCI host bridge to bus 0003:00
[    2.180287] pci_bus 0003:00: root bus resource [mem 0x818000000000-0x81ffffffffff window]
[    2.180295] pci_bus 0003:00: root bus resource [bus 00-1f]
[    2.180329] pci_bus 0003:00: resource 4 [mem 0x818000000000-0x81ffffffffff window]
[    2.180436] ACPI: PCI Root Bridge [PEM0] (domain 0004 [bus 1f-57])
[    2.180448] acpi PNP0A08:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    2.180588] acpi PNP0A08:04: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME AER LTR]
[    2.180717] acpi PNP0A08:04: _OSC: OS now controls [PCIeCapability]
[    2.180726] acpi PNP0A08:04: MCFG quirk: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57] with thunder_pem_ecam_ops
[    2.181277] acpi PNP0A08:04: ECAM area [mem 0x88001f000000-0x880057ffffff] reserved by CAVA02B:00
[    2.181874] acpi PNP0A08:04: ECAM at [mem 0x88001f000000-0x880057ffffff] for [bus 1f-57]
[    2.181909] Remapped I/O 0x0000883000000000 to [io  0x0000-0xffff window]
[    2.182046] PCI host bridge to bus 0004:1f
[    2.182053] pci_bus 0004:1f: root bus resource [io  0x0000-0xffff window]
[    2.182061] pci_bus 0004:1f: root bus resource [mem 0x881010000000-0x881fffffffff window] (bus address [0x10000000-0xfffffffff])
[    2.182069] pci_bus 0004:1f: root bus resource [mem 0x882000000000-0x882fffffffff pref window] (bus address [0x1000000000-0x1fffffffff])
[    2.182076] pci_bus 0004:1f: root bus resource [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.182083] pci_bus 0004:1f: root bus resource [bus 1f-57]
[    2.182108] pci 0004:1f:00.0: [177d:a100] type 01 class 0x060400
[    2.182123] pci 0004:1f:00.0: reg 0x10: [mem 0x00000000-0x00007fff 64bit pref]
[    2.182133] pci 0004:1f:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    2.182148] pci 0004:1f:00.0: enabling Extended Tags
[    2.182172] pci 0004:1f:00.0: BAR 0: [mem 0x87e0c0f00000-0x87e0c0ffffff 64bit] (from Enhanced Allocation, properties 0x0)
[    2.182344] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.182439] pci 0004:20:00.0: [1a03:1150] type 01 class 0x060400
[    2.182488] pci 0004:20:00.0: Upstream bridge's Max Payload Size set to 128 (was 256, max 256)
[    2.182498] pci 0004:20:00.0: Max Payload Size set to 128 (was 128, max 128)
[    2.182507] pci 0004:20:00.0: enabling Extended Tags
[    2.182592] pci 0004:20:00.0: supports D1 D2
[    2.182597] pci 0004:20:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.182768] pci 0004:20:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    2.182834] pci_bus 0004:21: extended config space not accessible
[    2.182894] pci 0004:21:00.0: [1a03:2000] type 00 class 0x030000
[    2.182915] pci 0004:21:00.0: reg 0x10: [mem 0x881010000000-0x881010ffffff]
[    2.182928] pci 0004:21:00.0: reg 0x14: [mem 0x881011000000-0x88101101ffff]
[    2.182940] pci 0004:21:00.0: reg 0x18: [io  0x0000-0x007f]
[    2.182999] pci 0004:21:00.0: BAR 0: assigned to efifb
[    2.183049] pci 0004:21:00.0: supports D1 D2
[    2.183054] pci 0004:21:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    2.183249] pci 0004:1f:00.0: Primary bus is hard wired to 0
[    2.183267] pci 0004:1f:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.183275] pci 0004:1f:00.0: BAR 6: assigned [mem 0x881011800000-0x88101180ffff pref]
[    2.183283] pci 0004:1f:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.183292] pci 0004:20:00.0: BAR 14: assigned [mem 0x881010000000-0x8810117fffff]
[    2.183298] pci 0004:20:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    2.183306] pci 0004:21:00.0: BAR 0: assigned [mem 0x881010000000-0x881010ffffff]
[    2.183315] pci 0004:21:00.0: BAR 1: assigned [mem 0x881011000000-0x88101101ffff]
[    2.183324] pci 0004:21:00.0: BAR 2: assigned [io  0x1000-0x107f]
[    2.183333] pci 0004:20:00.0: PCI bridge to [bus 21]
[    2.183340] pci 0004:20:00.0:   bridge window [io  0x1000-0x1fff]
[    2.183346] pci 0004:20:00.0:   bridge window [mem 0x881010000000-0x8810117fffff]
[    2.183353] pci 0004:1f:00.0: PCI bridge to [bus 20-21]
[    2.183360] pci 0004:1f:00.0:   bridge window [io  0x1000-0x1fff]
[    2.183366] pci 0004:1f:00.0:   bridge window [mem 0x881010000000-0x8810117fffff]
[    2.183374] pci_bus 0004:1f: resource 4 [io  0x0000-0xffff window]
[    2.183380] pci_bus 0004:1f: resource 5 [mem 0x881010000000-0x881fffffffff window]
[    2.183386] pci_bus 0004:1f: resource 6 [mem 0x882000000000-0x882fffffffff pref window]
[    2.183392] pci_bus 0004:1f: resource 7 [mem 0x87e0c0000000-0x87e0c0ffffff window]
[    2.183399] pci_bus 0004:20: resource 0 [io  0x1000-0x1fff]
[    2.183405] pci_bus 0004:20: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.183411] pci_bus 0004:21: resource 0 [io  0x1000-0x1fff]
[    2.183417] pci_bus 0004:21: resource 1 [mem 0x881010000000-0x8810117fffff]
[    2.183529] ACPI: PCI Interrupt Link [LN0A] (IRQs *48)
[    2.183581] ACPI: PCI Interrupt Link [LN0B] (IRQs *49)
[    2.183627] ACPI: PCI Interrupt Link [LN0C] (IRQs *50)
[    2.183674] ACPI: PCI Interrupt Link [LN0D] (IRQs *51)
[    2.183964] ARMH0011:00: ttyAMA0 at MMIO 0x87e024000000 (irq = 21, base_baud = 0) is a SBSA
[    6.381459] printk: console [ttyAMA0] enabled
[    6.389031] ARMH0011:01: ttyAMA1 at MMIO 0x87e025000000 (irq = 22, base_baud = 0) is a SBSA
[    6.403390] iommu: Default domain type: Translated 
[    6.408406] pci 0004:21:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none
[    6.416759] pci 0004:21:00.0: vgaarb: bridge control possible
[    6.422498] pci 0004:21:00.0: vgaarb: setting as boot device (VGA legacy resources not available)
[    6.431360] vgaarb: loaded
[    6.434782] SCSI subsystem initialized
[    6.438664] libata version 3.00 loaded.
[    6.438725] ACPI: bus type USB registered
[    6.442785] usbcore: registered new interface driver usbfs
[    6.448294] usbcore: registered new interface driver hub
[    6.453646] usbcore: registered new device driver usb
[    6.458787] pps_core: LinuxPPS API ver. 1 registered
[    6.463750] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
[    6.472880] PTP clock support registered
[    6.477015] EDAC MC: Ver: 3.0.0
[    6.480631] Registered efivars operations
[    6.486471] NetLabel: Initializing
[    6.489874] NetLabel:  domain hash size = 128
[    6.494221] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    6.499910] NetLabel:  unlabeled traffic allowed by default
[    6.506019] clocksource: Switched to clocksource arch_sys_counter
[    6.552176] VFS: Disk quotas dquot_6.6.0
[    6.556156] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    6.563484] AppArmor: AppArmor Filesystem Enabled
[    6.568273] pnp: PnP ACPI init
[    6.571957] system 00:00: [mem 0x848000000000-0x848001ffffff] could not be reserved
[    6.579633] system 00:00: Plug and Play ACPI device, IDs CAVa02c PNP0c02 (active)
[    6.579813] system 00:01: [mem 0x849000000000-0x849001ffffff] could not be reserved
[    6.587483] system 00:01: Plug and Play ACPI device, IDs CAVa02c PNP0c02 (active)
[    6.587663] system 00:02: [mem 0x84a000000000-0x84a001ffffff] could not be reserved
[    6.595333] system 00:02: Plug and Play ACPI device, IDs CAVa02c PNP0c02 (active)
[    6.595513] system 00:03: [mem 0x84b000000000-0x84b001ffffff] could not be reserved
[    6.603185] system 00:03: Plug and Play ACPI device, IDs CAVa02c PNP0c02 (active)
[    6.603373] system 00:04: [mem 0x87e0c0000000-0x87e0c0ffffff] could not be reserved
[    6.611034] system 00:04: [mem 0x88001f000000-0x880057ffffff] could not be reserved
[    6.618694] system 00:04: Plug and Play ACPI device, IDs CAVa02b PNP0c02 (active)
[    6.620919] pnp: PnP ACPI: found 5 devices
[    6.630876] NET: Registered protocol family 2
[    6.636036] tcp_listen_portaddr_hash hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    6.645263] TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    6.655124] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear)
[    6.662890] TCP: Hash tables configured (established 524288 bind 65536)
[    6.669909] MPTCP token hash table entries: 65536 (order: 8, 1572864 bytes, linear)
[    6.678126] UDP hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.685679] UDP-Lite hash table entries: 32768 (order: 8, 1048576 bytes, linear)
[    6.693858] NET: Registered protocol family 1
[    6.698228] NET: Registered protocol family 44
[    6.702864] PCI: CLS 0 bytes, default 64
[    6.706894] Trying to unpack rootfs image as initramfs...
[    7.711420] Freeing initrd memory: 68180K
[    7.718497] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 7 counters available
[    7.726530] kvm [1]: IPA Size Limit: 48 bits
[    7.732420] kvm [1]: GICv3: no GICV resource entry
[    7.737213] kvm [1]: disabling GICv2 emulation
[    7.741649] kvm [1]: GICv3 sysreg trapping enabled ([G0G1], reduced performance)
[    7.749050] kvm [1]: GIC system register CPU interface enabled
[    7.756017] kvm [1]: vgic interrupt IRQ9
[    7.761141] kvm [1]: Hyp mode initialized successfully
[    7.769051] Initialise system trusted keyrings
[    7.773521] Key type blacklist registered
[    7.777691] workingset: timestamp_bits=40 max_order=24 bucket_order=0
[    7.788417] zbud: loaded
[    7.792124] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    7.798498] fuse: init (API version 7.33)
[    7.802906] integrity: Platform Keyring initialized
[    7.830790] Key type asymmetric registered
[    7.834887] Asymmetric key parser 'x509' registered
[    7.839775] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
[    7.847300] io scheduler mq-deadline registered
[    7.855218] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    7.862764] efifb: probing for efifb
[    7.866372] efifb: No BGRT, not showing boot graphics
[    7.871416] efifb: framebuffer at 0x881010000000, using 3072k, total 3072k
[    7.878282] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    7.884280] efifb: scrolling: redraw
[    7.887845] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    7.893537] fbcon: Deferring console take-over
[    7.897981] fb0: EFI VGA frame buffer device
[    7.902922] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    7.911343] ACPI: button: Power Button [PWRB]
[    7.917165] ACPI GTDT: [Firmware Bug]: failed to get the Watchdog base address.
[    7.928506] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[    7.941108] msm_serial: driver initialized
[    7.946004] arm-smmu arm-smmu.0.auto: probing hardware configuration...
[    7.952620] arm-smmu arm-smmu.0.auto: SMMUv2 with:
[    7.957404] arm-smmu arm-smmu.0.auto: 	stage 1 translation
[    7.962880] arm-smmu arm-smmu.0.auto: 	stage 2 translation
[    7.968357] arm-smmu arm-smmu.0.auto: 	nested translation
[    7.973747] arm-smmu arm-smmu.0.auto: 	non-coherent table walk
[    7.979571] arm-smmu arm-smmu.0.auto: 	(IDR0.CTTW overridden by FW configuration)
[    7.987044] arm-smmu arm-smmu.0.auto: 	stream matching with 128 register groups
[    7.994346] arm-smmu arm-smmu.0.auto: 	128 context banks (0 stage-2 only)
[    8.001129] arm-smmu arm-smmu.0.auto: 	enabling workaround for Cavium erratum 27704
[    8.008777] arm-smmu arm-smmu.0.auto: 	Supported page sizes: 0x62215000
[    8.015384] arm-smmu arm-smmu.0.auto: 	Stage-1: 48-bit VA -> 48-bit IPA
[    8.021991] arm-smmu arm-smmu.0.auto: 	Stage-2: 48-bit IPA -> 48-bit PA
[    8.028829] arm-smmu arm-smmu.1.auto: probing hardware configuration...
[    8.035443] arm-smmu arm-smmu.1.auto: SMMUv2 with:
[    8.040228] arm-smmu arm-smmu.1.auto: 	stage 1 translation
[    8.045704] arm-smmu arm-smmu.1.auto: 	stage 2 translation
[    8.051180] arm-smmu arm-smmu.1.auto: 	nested translation
[    8.056571] arm-smmu arm-smmu.1.auto: 	non-coherent table walk
[    8.062396] arm-smmu arm-smmu.1.auto: 	(IDR0.CTTW overridden by FW configuration)
[    8.069871] arm-smmu arm-smmu.1.auto: 	stream matching with 128 register groups
[    8.077181] arm-smmu arm-smmu.1.auto: 	128 context banks (0 stage-2 only)
[    8.083968] arm-smmu arm-smmu.1.auto: 	enabling workaround for Cavium erratum 27704
[    8.091616] arm-smmu arm-smmu.1.auto: 	Supported page sizes: 0x62215000
[    8.098222] arm-smmu arm-smmu.1.auto: 	Stage-1: 48-bit VA -> 48-bit IPA
[    8.104830] arm-smmu arm-smmu.1.auto: 	Stage-2: 48-bit IPA -> 48-bit PA
[    8.111616] arm-smmu arm-smmu.2.auto: probing hardware configuration...
[    8.118232] arm-smmu arm-smmu.2.auto: SMMUv2 with:
[    8.123015] arm-smmu arm-smmu.2.auto: 	stage 1 translation
[    8.128492] arm-smmu arm-smmu.2.auto: 	stage 2 translation
[    8.133969] arm-smmu arm-smmu.2.auto: 	nested translation
[    8.139361] arm-smmu arm-smmu.2.auto: 	non-coherent table walk
[    8.145186] arm-smmu arm-smmu.2.auto: 	(IDR0.CTTW overridden by FW configuration)
[    8.152660] arm-smmu arm-smmu.2.auto: 	stream matching with 128 register groups
[    8.159962] arm-smmu arm-smmu.2.auto: 	128 context banks (0 stage-2 only)
[    8.166748] arm-smmu arm-smmu.2.auto: 	enabling workaround for Cavium erratum 27704
[    8.174398] arm-smmu arm-smmu.2.auto: 	Supported page sizes: 0x62215000
[    8.181004] arm-smmu arm-smmu.2.auto: 	Stage-1: 48-bit VA -> 48-bit IPA
[    8.187610] arm-smmu arm-smmu.2.auto: 	Stage-2: 48-bit IPA -> 48-bit PA
[    8.194389] arm-smmu arm-smmu.3.auto: probing hardware configuration...
[    8.201006] arm-smmu arm-smmu.3.auto: SMMUv2 with:
[    8.205789] arm-smmu arm-smmu.3.auto: 	stage 1 translation
[    8.211268] arm-smmu arm-smmu.3.auto: 	stage 2 translation
[    8.216745] arm-smmu arm-smmu.3.auto: 	nested translation
[    8.222136] arm-smmu arm-smmu.3.auto: 	non-coherent table walk
[    8.227960] arm-smmu arm-smmu.3.auto: 	(IDR0.CTTW overridden by FW configuration)
[    8.235435] arm-smmu arm-smmu.3.auto: 	stream matching with 128 register groups
[    8.242737] arm-smmu arm-smmu.3.auto: 	128 context banks (0 stage-2 only)
[    8.249518] arm-smmu arm-smmu.3.auto: 	enabling workaround for Cavium erratum 27704
[    8.257166] arm-smmu arm-smmu.3.auto: 	Supported page sizes: 0x62215000
[    8.263772] arm-smmu arm-smmu.3.auto: 	Stage-1: 48-bit VA -> 48-bit IPA
[    8.270378] arm-smmu arm-smmu.3.auto: 	Stage-2: 48-bit IPA -> 48-bit PA
[    8.278228] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    8.300471] loop: module loaded
[    8.304862] libphy: Fixed MDIO Bus: probed
[    8.309004] tun: Universal TUN/TAP device driver, 1.6
[    8.314446] PPP generic driver version 2.4.2
[    8.318858] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    8.325395] ehci-pci: EHCI PCI platform driver
[    8.329877] ehci-orion: EHCI orion driver
[    8.333922] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.340103] ohci-pci: OHCI PCI platform driver
[    8.344581] uhci_hcd: USB Universal Host Controller Interface driver
[    8.351159] mousedev: PS/2 mouse device common for all mice
[    8.557146] rtc-efi rtc-efi.0: registered as rtc0
[    8.661912] rtc-efi rtc-efi.0: setting system clock to 2021-04-21T14:37:38 UTC (1619015858)
[    8.670456] i2c /dev entries driver
[    8.674560] device-mapper: uevent: version 1.0.3
[    8.679352] device-mapper: ioctl: 4.44.0-ioctl (2021-02-01) initialised: dm-devel at redhat.com
[    8.689096] ledtrig-cpu: registered to indicate activity on CPUs
[    8.696877] pstore: Registered efi as persistent store backend
[    8.703575] drop_monitor: Initializing network drop monitor service
[    8.710343] NET: Registered protocol family 10
[    8.737123] Segment Routing with IPv6
[    8.740837] NET: Registered protocol family 17
[    8.745394] Key type dns_resolver registered
[    8.749897] registered taskstats version 1
[    8.754046] Loading compiled-in X.509 certificates
[    8.760576] Loaded X.509 cert 'Build time autogenerated kernel key: b2705ab2481bcbdfae85dcbf8e7e0248227cf5e0'
[    8.772791] zswap: loaded using pool lzo/zbud
[    8.777549] Key type ._fscrypt registered
[    8.781562] Key type .fscrypt registered
[    8.785479] Key type fscrypt-provisioning registered
[    8.790614] pstore: Using crash dump compression: deflate
[    8.806123] Key type encrypted registered
[    8.810138] AppArmor: AppArmor sha1 policy hashing enabled
[    8.816085] ima: No TPM chip found, activating TPM-bypass!
[    8.821581] ima: Allocated hash algorithm: sha1
[    8.826128] ima: No architecture policies found
[    8.830690] evm: Initialising EVM extended attributes:
[    8.835822] evm: security.selinux
[    8.839129] evm: security.SMACK64
[    8.842434] evm: security.SMACK64EXEC
[    8.846087] evm: security.SMACK64TRANSMUTE
[    8.850173] evm: security.SMACK64MMAP
[    8.853823] evm: security.apparmor
[    8.857215] evm: security.ima
[    8.860173] evm: security.capability
[    8.863739] evm: HMAC attrs: 0x1
[    8.867907] pcieport 0000:00:01.0: Adding to iommu group 0
[    8.873929] pcieport 0000:00:14.0: Adding to iommu group 1
[    8.879884] pcieport 0002:00:02.0: Adding to iommu group 2
[    8.885864] pcieport 0004:1f:00.0: Adding to iommu group 3
[    8.891806] PCI Interrupt Link [LN0A] enabled at IRQ 48
[    8.897695] pcieport 0004:20:00.0: Adding to iommu group 4
[    8.909838] Freeing unused kernel memory: 7616K

  -dann


From yibin.gong at nxp.com  Wed Apr 21 15:54:47 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Wed, 21 Apr 2021 14:54:47 +0000
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
 <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>
Message-ID: <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>

On 20201/04/20 22:01 Lucas Stach <l.stach at pengutronix.de> wrote:
> Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong:
> > On 2021/04/19 17:46 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> > > > Hi Lucas,
> > > >
> > > > On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > Hi Robin,
> > > > >
> > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > > > > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu
> Wang:
> > > > > > > > Hi
> > > > > > > >
> > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > > > > <l.stach at pengutronix.de>
> > > > > > > wrote:
> > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu
> Wang:
> > > > > > > > > > There are two requirements that we need to move the
> > > > > > > > > > request of dma channel from probe to open.
> > > > > > > > >
> > > > > > > > > How do you handle -EPROBE_DEFER return code from the
> > > > > > > > > channel request if you don't do it in probe?
> > > > > > > >
> > > > > > > > I use the dma_request_slave_channel or dma_request_channel
> > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should
> > > > > > > > be not -EPROBE_DEFER return code.
> > > > > > >
> > > > > > > This is a pretty weak argument. The dmaengine device might
> > > > > > > probe after you try to get the channel. Using a function to
> > > > > > > request the channel that doesn't allow you to handle probe
> > > > > > > deferral is IMHO a bug and should be fixed, instead of
> > > > > > > building even more assumptions on top
> > > > > of it.
> > > > > > >
> > > > > > > > > > - When dma device binds with power-domains, the power
> > > > > > > > > > will be enabled when we request dma channel. If the
> > > > > > > > > > request of dma channel happen on probe, then the
> > > > > > > > > > power-domains will be always enabled after kernel boot
> > > > > > > > > > up,  which is not good for power saving,  so we need
> > > > > > > > > > to move the request of dma channel to .open();
> > > > > > > > >
> > > > > > > > > This is certainly something which could be fixed in the
> > > > > > > > > dmaengine driver.
> > > > > > > >
> > > > > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > > > > device_alloc_chan_resources, the
> > > > > > > > device_alloc_chan_resources is called when channel is
> > > > > > > > requested. so power is enabled on channel
> > > > > request.
> > > > > > >
> > > > > > > So why can't you fix the dmaengine driver to do that RPM
> > > > > > > call at a later time when the channel is actually going to
> > > > > > > be used? This will allow further power savings with other
> > > > > > > slave devices than the audio
> > > PCM.
> > > > > > Hi Lucas,
> > > > > > ??Thanks for your suggestion. I have tried to implement
> > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with
> > > > > > delay time (2
> > > > > > sec) for this feature as below (or you can refer to
> > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface
> > > > > > like
> > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d
> > > > > > ma_c
> > > > > > ycli
> > > > > > c/
> > > > > > device_tx_status...
> > > > > >
> > > > > >
> > > > > > ????????????????pm_runtime_use_autosuspend(fsl_chan->de
> v);
> > > > > > ????????????????pm_runtime_set_autosuspend_delay(fsl_cha
> n->
> > > dev,
> > > > > 2000);
> > > > > >
> > > > > > That could resolve this audio case since the autosuspend could
> > > > > > suspend runtime after
> > > > > > 2 seconds if there is no further dma transfer but only channel
> > > > > request(device_alloc_chan_resources).
> > > > > > But unfortunately, it cause another issue. As you know, on our
> > > > > > i.mx8qm/qxp, power domain done by scfw
> > > > > > (drivers/firmware/imx/scu-pd.c)
> > > > > over mailbox:
> > > > > > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > > > > > imx_scu_ipc_write()->mbox_send_message()
> > > > > > which means have to 'waits for completion', meanwhile, some
> > > > > > driver like tty will call dmaengine interfaces in non-atomic
> > > > > > case as below,
> > > > > >
> > > > > > static int uart_write(struct tty_struct *tty, const unsigned
> > > > > > char *buf, int count) {
> > > > > > ???.......
> > > > > > 	    port = uart_port_lock(state, flags);
> > > > > > ???......
> > > > > > ????????__uart_start(tty);  //call
> > > start_tx()->dmaengine_prep_slave_sg...
> > > > > > ????????uart_port_unlock(port, flags);
> > > > > > ????????return ret;
> > > > > > }
> > > > > >
> > > > > > Thus dma runtime resume may happen in that timing window and
> > > > > > cause
> > > > > kernel alarm.
> > > > > > I'm not sure whether there are similar limitations on other
> > > > > > driver subsystem. But for me, It looks like the only way to
> > > > > > resolve the contradiction between tty and scu-pd (hardware
> > > > > > limitation on
> > > > > > i.mx8qm/qxp) is to give up autosuspend and keep
> > > > > > pm_runtime_get_sync
> > > > > only in device_alloc_chan_resources because request channel is a
> > > > > safe non-atomic phase.
> > > > > > Do you have any idea? Thanks in advance.
> > > > >
> > > > > If you look closely at the driver you used as an example
> > > > > (hidma.c) it looks like there is already something in there,
> > > > > which looks very much like what you need
> > > > > here:
> > > > >
> > > > > In hidma_issue_pending() the driver tries to get the device to
> > > > > runtime
> > > resume.
> > > > > If this doesn't work, maybe due to the power domain code not
> > > > > being able to be called in atomic context, the actual work of
> > > > > waking up the dma hardware and issuing the descriptor is shunted to a
> tasklet.
> > > > >
> > > > > If I'm reading this right, this is exactly what you need here to
> > > > > be able to call the dmaengine code from atomic context: try the
> > > > > rpm get and issue immediately when possible, otherwise shunt the
> > > > > work to a
> > > > > non- atomic context where you can deal with the requirements of
> scu-pd.
> > > > Yes, I can schedule_work to worker to runtime resume edma channel
> > > > by
> > > calling scu-pd.
> > > > But that means all dmaengine interfaces should be taken care, not
> > > > only
> > > > issue_pending() but also
> > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> > > > dmaengine_tx_status(). Not sure why hidma only take care
> > > > issue_pending. Maybe their user case is just for memcpy/memset so
> > > > that no further complicate case as ALSA or TTY.
> > > > Besides, for autosuspend in cyclic, we have to add
> > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but
> > > > how could resolve the scu-pd's non-atmoic limitation in interrupt
> handler?
> > >
> > > Sure, this all needs some careful analysis on how those functions
> > > are called and what to do about atomic callers, but it should be
> > > doable. I don't see any fundamental issues here.
> > >
> > > I don't see why you would ever need to wake the hardware in an
> > > interrupt handler. Surely the hardware is already awake, as it
> > > wouldn't signal an interrupt otherwise. And for the issue with
> > > scu-pd you only care about the state transition of
> > > suspended->running. If the hardware is already running/awake, the
> > > runtime pm state handling is nothing more than bumping a refcount,
> > > which is atomic safe. Putting the HW in suspend is already handled
> asynchronously in a worker, so this is also atomic safe.
> > But with autosuspend used, in corner case, may runtime suspended
> > before falling Into edma interrupt handler if timeout happen with the
> > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch
> > any edma interrupt status register unless runtime resume edma in
> > interrupt handler while runtime resume function based on scu-pd's power
> domain may block or sleep.
> > I have a simple workaround that disable runtime suspend in
> > issue_pending worker by calling pm_runtime_forbid() and then enable
> > runtime auto suspend in dmaengine_terminate_all so that we could
> > easily regard that edma channel is always in runtime resume between
> > issue_pending and channel terminated and ignore the above interrupt
> handler/scu-pd limitation.
> 
> The IRQ handler is the point where you are informed by the hardware that a
> specific operation is complete. I don't see any use-case where it would be valid
> to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware
> needs to stay awake until the currently queued operations are complete and if
> the IRQ handler is the completion point the IRQ handler is the first point in
> time where your autosuspend timer should start to run. There should never be
> a situation where the timer expiry can get between IRQ signaling and the
> handler code running.
But the timer of runtime_auto_suspend decide when enter runtime suspend rather
than hardware, while transfer data size and transfer rate on IP bus decide when the
dma interrupt happen.  Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend
timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic
and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer
100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile
the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent
by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start
to run after runtime suspend. 


From lkp at intel.com  Wed Apr 21 16:04:30 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 21 Apr 2021 23:04:30 +0800
Subject: [PATCH V5] watchdog: mtk: support dual mode when the bark irq is
 available
In-Reply-To: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
References: <1618992304-18903-1-git-send-email-wangqing@vivo.com>
Message-ID: <202104212258.slAwb4tX-lkp@intel.com>

Hi Wang,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on hwmon/hwmon-next]
[also build test ERROR on soc/for-next linus/master v5.12-rc8 next-20210421]
[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]

url:    https://github.com/0day-ci/linux/commits/Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
base:   https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next
config: nds32-randconfig-r021-20210421 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/bb28c4d8391120b54c691e2407dae46761ef69af
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Wang-Qing/watchdog-mtk-support-dual-mode-when-the-bark-irq-is-available/20210421-160730
        git checkout bb28c4d8391120b54c691e2407dae46761ef69af
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nds32 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/sched.h:12,
                    from include/linux/ptrace.h:6,
                    from include/uapi/asm-generic/bpf_perf_event.h:4,
                    from ./arch/nds32/include/generated/uapi/asm/bpf_perf_event.h:1,
                    from include/uapi/linux/bpf_perf_event.h:11,
                    from include/linux/perf_event.h:18,
                    from arch/nds32/kernel/perf_event_cpu.c:9:
   arch/nds32/kernel/perf_event_cpu.c: In function 'unwind_frame_kernel':
>> arch/nds32/include/asm/current.h:10:13: error: '$r25' undeclared (first use in this function)
      10 | #define tsk $r25
         |             ^~~~
   arch/nds32/kernel/perf_event_cpu.c:1255:8: note: in expansion of macro 'tsk'
    1255 |       (tsk, &graph, frame->lp, NULL);
         |        ^~~
   arch/nds32/include/asm/current.h:10:13: note: each undeclared identifier is reported only once for each function it appears in
      10 | #define tsk $r25
         |             ^~~~
   arch/nds32/kernel/perf_event_cpu.c:1255:8: note: in expansion of macro 'tsk'
    1255 |       (tsk, &graph, frame->lp, NULL);
         |        ^~~
   arch/nds32/kernel/perf_event_cpu.c:1257:13: warning: assignment to 'long unsigned int' from 'long unsigned int *' makes integer from pointer without a cast [-Wint-conversion]
    1257 |   frame->sp = ((unsigned long *)frame->sp) + 1;
         |             ^
--
   drivers/watchdog/mtk_wdt.c: In function 'mtk_wdt_probe':
   drivers/watchdog/mtk_wdt.c:327:16: warning: missing terminating " character
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |                ^
   In file included from include/linux/device.h:15,
                    from include/linux/node.h:18,
                    from include/linux/cpu.h:17,
                    from include/linux/of_device.h:5,
                    from drivers/watchdog/mtk_wdt.c:23:
>> drivers/watchdog/mtk_wdt.c:327:16: error: missing terminating " character
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
      19 | #define dev_fmt(fmt) fmt
         |                      ^~~
   drivers/watchdog/mtk_wdt.c:327:2: note: in expansion of macro 'dev_info'
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |  ^~~~~~~~
>> drivers/watchdog/mtk_wdt.c:328:14: error: expected expression before '%' token
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |              ^
   include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
      19 | #define dev_fmt(fmt) fmt
         |                      ^~~
   drivers/watchdog/mtk_wdt.c:327:2: note: in expansion of macro 'dev_info'
     327 |  dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
         |  ^~~~~~~~
   drivers/watchdog/mtk_wdt.c:328:17: error: stray '\' in program
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                 ^
>> drivers/watchdog/mtk_wdt.c:328:18: error: expected ';' before 'n'
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                  ^
   drivers/watchdog/mtk_wdt.c:328:19: warning: missing terminating " character
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                   ^
   drivers/watchdog/mtk_wdt.c:328:19: error: missing terminating " character
     328 |    dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
         |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +327 drivers/watchdog/mtk_wdt.c

   276	
   277	static int mtk_wdt_probe(struct platform_device *pdev)
   278	{
   279		struct device *dev = &pdev->dev;
   280		struct mtk_wdt_dev *mtk_wdt;
   281		const struct mtk_wdt_data *wdt_data;
   282		int err, irq;
   283	
   284		mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
   285		if (!mtk_wdt)
   286			return -ENOMEM;
   287	
   288		platform_set_drvdata(pdev, mtk_wdt);
   289	
   290		mtk_wdt->wdt_base = devm_platform_ioremap_resource(pdev, 0);
   291		if (IS_ERR(mtk_wdt->wdt_base))
   292			return PTR_ERR(mtk_wdt->wdt_base);
   293	
   294		if (dual_mode) {
   295			irq = platform_get_irq(pdev, 0);
   296			if (irq > 0) {
   297				err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
   298							&mtk_wdt->wdt_dev);
   299				if (err)
   300					return err;
   301			} else {
   302				dual_mode = 0;
   303				dev_info(&pdev->dev, "couldn't get wdt irq, set dual_mode = 0\n");
   304			}
   305		}
   306	
   307		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
   308		mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
   309		mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
   310		mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
   311		mtk_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
   312		mtk_wdt->wdt_dev.parent = dev;
   313	
   314		watchdog_init_timeout(&mtk_wdt->wdt_dev, timeout, dev);
   315		watchdog_set_nowayout(&mtk_wdt->wdt_dev, nowayout);
   316		watchdog_set_restart_priority(&mtk_wdt->wdt_dev, 128);
   317	
   318		watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
   319	
   320		mtk_wdt_init(&mtk_wdt->wdt_dev);
   321	
   322		watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
   323		err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
   324		if (unlikely(err))
   325			return err;
   326	
 > 327		dev_info(dev, "Watchdog enabled (timeout=%d sec, nowayout=%d,
 > 328			 dual_mode=%d)\n", mtk_wdt->wdt_dev.timeout, nowayout, dual_mode);
   329	
   330		wdt_data = of_device_get_match_data(dev);
   331		if (wdt_data) {
   332			err = toprgu_register_reset_controller(pdev,
   333							       wdt_data->toprgu_sw_rst_num);
   334			if (err)
   335				return err;
   336		}
   337		return 0;
   338	}
   339	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33906 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210421/03ff1634/attachment-0001.gz>

From broonie at kernel.org  Wed Apr 21 16:05:10 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 21 Apr 2021 16:05:10 +0100
Subject: [PATCH] spi: stm32-qspi: fix debug format string
In-Reply-To: <20210421140653.3964725-1-arnd@kernel.org>
References: <20210421140653.3964725-1-arnd@kernel.org>
Message-ID: <20210421150510.GA36785@sirena.org.uk>

On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> Printing size_t needs a special %zd format modifier to avoid a
> warning like:

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/20210421/6571163e/attachment.sig>

From elver at google.com  Wed Apr 21 16:11:57 2021
From: elver at google.com (Marco Elver)
Date: Wed, 21 Apr 2021 17:11:57 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
References: <20210408103605.1676875-1-elver@google.com>
 <CGME20210420212618eucas1p102b427d1af9c682217dfe093f3eac3e8@eucas1p1.samsung.com>
 <20210408103605.1676875-6-elver@google.com>
 <1fbf3429-42e5-0959-9a5c-91de80f02b6a@samsung.com>
 <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
Message-ID: <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>

+Cc linux-arm-kernel

On Wed, 21 Apr 2021 at 15:19, Marek Szyprowski <m.szyprowski at samsung.com> wrote:
>
> Hi Marco,
>
> On 21.04.2021 13:03, Marco Elver wrote:
> > On Wed, 21 Apr 2021 at 12:57, Marek Szyprowski <m.szyprowski at samsung.com> wrote:
> >> On 21.04.2021 11:35, Marek Szyprowski wrote:
> >>> On 21.04.2021 10:11, Marco Elver wrote:
> >>>> On Wed, 21 Apr 2021 at 09:35, Marek Szyprowski
> >>>> <m.szyprowski at samsung.com> wrote:
> >>>>> On 21.04.2021 08:21, Marek Szyprowski wrote:
> >>>>>> On 21.04.2021 00:42, Marco Elver wrote:
> >>>>>>> On Tue, 20 Apr 2021 at 23:26, Marek Szyprowski
> >>>>>>> <m.szyprowski at samsung.com> wrote:
> >>>>>>>> On 08.04.2021 12:36, Marco Elver wrote:
> >>>>>>>>> Introduces the TRAP_PERF si_code, and associated siginfo_t field
> >>>>>>>>> si_perf. These will be used by the perf event subsystem to send
> >>>>>>>>> signals
> >>>>>>>>> (if requested) to the task where an event occurred.
> >>>>>>>>>
> >>>>>>>>> Acked-by: Geert Uytterhoeven <geert at linux-m68k.org> # m68k
> >>>>>>>>> Acked-by: Arnd Bergmann <arnd at arndb.de> # asm-generic
> >>>>>>>>> Signed-off-by: Marco Elver <elver at google.com>
> >>>>>>>> This patch landed in linux-next as commit fb6cc127e0b6 ("signal:
> >>>>>>>> Introduce TRAP_PERF si_code and si_perf to siginfo"). It causes
> >>>>>>>> regression on my test systems (arm 32bit and 64bit). Most systems
> >>>>>>>> fails
> >>>>>>>> to boot in the given time frame. I've observed that there is a
> >>>>>>>> timeout
> >>>>>>>> waiting for udev to populate /dev and then also during the network
> >>>>>>>> interfaces configuration. Reverting this commit, together with
> >>>>>>>> 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") to
> >>>>>>>> let it
> >>>>>>>> compile, on top of next-20210420 fixes the issue.
> >>>>>>> Thanks, this is weird for sure and nothing in particular stands out.
> >>>>>>>
> >>>>>>> I have questions:
> >>>>>>> -- Can you please share your config?
> >>>>>> This happens with standard multi_v7_defconfig (arm) or just defconfig
> >>>>>> for arm64.
> >>>>>>
> >>>>>>> -- Also, can you share how you run this? Can it be reproduced in
> >>>>>>> qemu?
> >>>>>> Nothing special. I just boot my test systems and see that they are
> >>>>>> waiting lots of time during the udev populating /dev and network
> >>>>>> interfaces configuration. I didn't try with qemu yet.
> >>>>>>> -- How did you derive this patch to be at fault? Why not just
> >>>>>>> 97ba62b27867, given you also need to revert it?
> >>>>>> Well, I've just run my boot tests with automated 'git bisect' and that
> >>>>>> was its result. It was a bit late in the evening, so I didn't analyze
> >>>>>> it further, I've just posted a report about the issue I've found. It
> >>>>>> looks that bisecting pointed to a wrong commit somehow.
> >>>>>>> If you are unsure which patch exactly it is, can you try just
> >>>>>>> reverting 97ba62b27867 and see what happens?
> >>>>>> Indeed, this is a real faulty commit. Initially I've decided to revert
> >>>>>> it to let kernel compile (it uses some symbols introduced by this
> >>>>>> commit). Reverting only it on top of linux-next 20210420 also fixes
> >>>>>> the issue. I'm sorry for the noise in this thread. I hope we will find
> >>>>>> what really causes the issue.
> >>>>> This was a premature conclusion. It looks that during the test I've did
> >>>>> while writing that reply, the modules were not deployed properly and a
> >>>>> test board (RPi4) booted without modules. In that case the board booted
> >>>>> fine and there was no udev timeout. After deploying kernel modules, the
> >>>>> udev timeout is back.
> >>>> I'm confused now. Can you confirm that the problem is due to your
> >>>> kernel modules, or do you think it's still due to 97ba62b27867? Or
> >>>> fb6cc127e0b6 (this patch)?
> >>> I don't use any custom kernel modules. I just deploy all modules that
> >>> are being built from the given kernel defconfig (arm
> >>> multi_v7_defconfig or arm64 default) and they are automatically loaded
> >>> during the boot by udev. I've checked again and bisect was right. The
> >>> kernel built from fb6cc127e0b6 suffers from the described issue, while
> >>> the one build from the previous commit (2e498d0a74e5) works fine.
> >> I've managed to reproduce this issue with qemu. I've compiled the kernel
> >> for arm 32bit with multi_v7_defconfig and used some older Debian rootfs
> >> image. The log and qemu parameters are here:
> >> https://protect2.fireeye.com/v1/url?k=7cfc23a2-23671aa9-7cfda8ed-002590f5b904-dab7e2ec39dae1f9&q=1&e=36a5ed13-6ad5-430c-8f44-e95c4f0af5c3&u=https%3A%2F%2Fpaste.debian.net%2F1194526%2F
> >>
> >> Check the timestamp for the 'EXT4-fs (vda): re-mounted' message and
> >> 'done (timeout)' status for the 'Waiting for /dev to be fully populated'
> >> message. This happens only when kernel modules build from the
> >> multi_v7_defconfig are deployed on the rootfs.
> > Still hard to say what is going on and what is at fault. But being
> > able to repro this in qemu helps debug quicker -- would you also be
> > able to share the precise rootfs.img, i.e. upload it somewhere I can
> > fetch it? And just to be sure, please also share your .config, as it
> > might have compiler-version dependent configuration that might help
> > repro (unlikely, but you never know).
>
> I've managed to reproduce this issue with a public Raspberry Pi OS Lite
> rootfs image, even without deploying kernel modules:
>
> https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-03-25/2021-03-04-raspios-buster-armhf-lite.zip
>
> # qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon
> console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none
> -monitor null -device virtio-blk-device,drive=virtio-blk -drive
> file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw
> -netdev user,id=user -device virtio-net-device,netdev=user
>
> The above one doesn't boot if zImage z compiled from commit fb6cc127e0b6
> and boots if compiled from 2e498d0a74e5. In both cases I've used default
> arm/multi_v7_defconfig and
> gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.

Yup, I've narrowed it down to the addition of "__u64 _perf" to
siginfo_t. My guess is the __u64 causes a different alignment for a
bunch of adjacent fields. It seems that x86 and m68k are the only ones
that have compile-time tests for the offsets. Arm should probably add
those -- I have added a bucket of static_assert() in
arch/arm/kernel/signal.c and see that something's off.

I'll hopefully have a fix in a day or so.

Thanks,
-- Marco


From bgolaszewski at baylibre.com  Wed Apr 21 16:13:41 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Wed, 21 Apr 2021 17:13:41 +0200
Subject: [PATCH v2 1/3] dt-bindings: gpio: add YAML description for
 rockchip, gpio-bank
In-Reply-To: <20210412223617.8634-1-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
Message-ID: <CAMpxmJX7=A++ubOr3xQ3_Taau2G1-k0q5Xj3k8Hd14tH_762Fg@mail.gmail.com>

On Tue, Apr 13, 2021 at 12:36 AM Johan Jonker <jbx6244 at gmail.com> wrote:
>
> Current dts files with "rockchip,gpio-bank" subnodes
> are manually verified. In order to automate this process
> the text that describes the compatible in rockchip,pinctrl.txt
> is removed and converted to YAML in rockchip,gpio-bank.yaml.
>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> Changed V2:
>   changed example gpio nodename
> ---
>  .../bindings/gpio/rockchip,gpio-bank.yaml          | 82 ++++++++++++++++++++++
>  .../bindings/pinctrl/rockchip,pinctrl.txt          | 58 +--------------
>  2 files changed, 83 insertions(+), 57 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> new file mode 100644
> index 000000000..d993e002c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/rockchip,gpio-bank.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip GPIO bank
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - rockchip,gpio-bank
> +      - rockchip,rk3188-gpio-bank0
> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  gpio-controller: true
> +
> +  "#gpio-cells":
> +    const: 2
> +
> +  interrupt-controller: true
> +
> +  "#interrupt-cells":
> +    const: 2
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - gpio-controller
> +  - "#gpio-cells"
> +  - interrupt-controller
> +  - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    pinctrl: pinctrl {
> +      #address-cells = <1>;
> +      #size-cells = <1>;
> +      ranges;
> +
> +      gpio0: gpio at 2000a000 {
> +        compatible = "rockchip,rk3188-gpio-bank0";
> +        reg = <0x2000a000 0x100>;
> +        interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk_gates8 9>;
> +
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +
> +        interrupt-controller;
> +        #interrupt-cells = <2>;
> +      };
> +
> +      gpio1: gpio at 2003c000 {
> +        compatible = "rockchip,gpio-bank";
> +        reg = <0x2003c000 0x100>;
> +        interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> +        clocks = <&clk_gates8 10>;
> +
> +        gpio-controller;
> +        #gpio-cells = <2>;
> +
> +        interrupt-controller;
> +        #interrupt-cells = <2>;
> +      };
> +    };
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> index d3eae61a3..4719a6a07 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -50,23 +50,7 @@ Deprecated properties for iomux controller:
>          Use rockchip,grf and rockchip,pmu described above instead.
>
>  Required properties for gpio sub nodes:
> -  - compatible: "rockchip,gpio-bank"
> -  - reg: register of the gpio bank (different than the iomux registerset)
> -  - interrupts: base interrupt of the gpio bank in the interrupt controller
> -  - clocks: clock that drives this bank
> -  - gpio-controller: identifies the node as a gpio controller and pin bank.
> -  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
> -    binding is used, the amount of cells must be specified as 2. See generic
> -    GPIO binding documentation for description of particular cells.
> -  - interrupt-controller: identifies the controller node as interrupt-parent.
> -  - #interrupt-cells: the value of this property should be 2 and the interrupt
> -    cells should use the standard two-cell scheme described in
> -    bindings/interrupt-controller/interrupts.txt
> -
> -Deprecated properties for gpio sub nodes:
> -  - compatible: "rockchip,rk3188-gpio-bank0"
> -  - reg: second element: separate pull register for rk3188 bank0, use
> -        rockchip,pmu described above instead
> +See rockchip,gpio-bank.yaml
>
>  Required properties for pin configuration node:
>    - rockchip,pins: 3 integers array, represents a group of pins mux and config
> @@ -127,43 +111,3 @@ uart2: serial at 20064000 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart2_xfer>;
>  };
> -
> -Example for rk3188:
> -
> -       pinctrl at 20008000 {
> -               compatible = "rockchip,rk3188-pinctrl";
> -               rockchip,grf = <&grf>;
> -               rockchip,pmu = <&pmu>;
> -               #address-cells = <1>;
> -               #size-cells = <1>;
> -               ranges;
> -
> -               gpio0: gpio0 at 2000a000 {
> -                       compatible = "rockchip,rk3188-gpio-bank0";
> -                       reg = <0x2000a000 0x100>;
> -                       interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> -                       clocks = <&clk_gates8 9>;
> -
> -                       gpio-controller;
> -                       #gpio-cells = <2>;
> -
> -                       interrupt-controller;
> -                       #interrupt-cells = <2>;
> -               };
> -
> -               gpio1: gpio1 at 2003c000 {
> -                       compatible = "rockchip,gpio-bank";
> -                       reg = <0x2003c000 0x100>;
> -                       interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> -                       clocks = <&clk_gates8 10>;
> -
> -                       gpio-controller;
> -                       #gpio-cells = <2>;
> -
> -                       interrupt-controller;
> -                       #interrupt-cells = <2>;
> -               };
> -
> -               ...
> -
> -       };
> --
> 2.11.0
>

Applied, thanks!

Bartosz


From f.fainelli at gmail.com  Wed Apr 21 16:17:28 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 21 Apr 2021 08:17:28 -0700
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
 <YH/ixPnHMxNo08mJ@google.com>
 <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>
Message-ID: <498b8759-1a70-d80f-3a4d-39042b4f608e@gmail.com>



On 4/21/2021 7:33 AM, Florian Fainelli wrote:
> 
> 
> On 4/21/2021 1:31 AM, Quentin Perret wrote:
>> On Tuesday 20 Apr 2021 at 09:33:56 (-0700), Florian Fainelli wrote:
>>> I do wonder as well, we have a 32MB "no-map" reserved memory region on
>>> our platforms located at 0xfe000000. Without the offending commit,
>>> /proc/iomem looks like this:
>>>
>>> 40000000-fdffefff : System RAM
>>>   40008000-40ffffff : Kernel code
>>>   41e00000-41ef1d77 : Kernel data
>>> 100000000-13fffffff : System RAM
>>>
>>> and with the patch applied, we have this:
>>>
>>> 40000000-fdffefff : System RAM
>>>   40008000-40ffffff : Kernel code
>>>   41e00000-41ef3db7 : Kernel data
>>> fdfff000-ffffffff : System RAM
>>> 100000000-13fffffff : System RAM
>>>
>>> so we can now see that the region 0xfe000000 - 0xfffffff is also cobbled
>>> up with the preceding region which is a mailbox between Linux and the
>>> secure monitor at 0xfdfff000 and of size 4KB. It seems like there is
>>>
>>> The memblock=debug outputs is also different:
>>>
>>> [    0.000000] MEMBLOCK configuration:
>>> [    0.000000]  memory size = 0xfdfff000 reserved size = 0x7ce4d20d
>>> [    0.000000]  memory.cnt  = 0x2
>>> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
>>> 0xbdfff000 bytes flags: 0x0
>>> [    0.000000]  memory[0x1]     [0x00000100000000-0x0000013fffffff],
>>> 0x40000000 bytes flags: 0x0
>>> [    0.000000]  reserved.cnt  = 0x6
>>> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
>>> 0xb495 bytes flags: 0x0
>>> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef1d77],
>>> 0x1cf1d78 bytes flags: 0x0
>>> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
>>> 0x100000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
>>> 0x50000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x4]   [0x000000c2c00000-0x000000fdbfffff],
>>> 0x3b000000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
>>> 0x40000000 bytes flags: 0x0
>>>
>>> [    0.000000] MEMBLOCK configuration:
>>> [    0.000000]  memory size = 0x100000000 reserved size = 0x7ca4f24d
>>> [    0.000000]  memory.cnt  = 0x3
>>> [    0.000000]  memory[0x0]     [0x00000040000000-0x000000fdffefff],
>>> 0xbdfff000 bytes flags: 0x0
>>> [    0.000000]  memory[0x1]     [0x000000fdfff000-0x000000ffffffff],
>>> 0x2001000 bytes flags: 0x4
>>> [    0.000000]  memory[0x2]     [0x00000100000000-0x0000013fffffff],
>>> 0x40000000 bytes flags: 0x0
>>> [    0.000000]  reserved.cnt  = 0x6
>>> [    0.000000]  reserved[0x0]   [0x00000040003000-0x0000004000e494],
>>> 0xb495 bytes flags: 0x0
>>> [    0.000000]  reserved[0x1]   [0x00000040200000-0x00000041ef3db7],
>>> 0x1cf3db8 bytes flags: 0x0
>>> [    0.000000]  reserved[0x2]   [0x00000045000000-0x000000450fffff],
>>> 0x100000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x3]   [0x00000047000000-0x0000004704ffff],
>>> 0x50000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x4]   [0x000000c3000000-0x000000fdbfffff],
>>> 0x3ac00000 bytes flags: 0x0
>>> [    0.000000]  reserved[0x5]   [0x00000100000000-0x0000013fffffff],
>>> 0x40000000 bytes flags: 0x0
>>>
>>> in the second case we can clearly see that the 32MB no-map region is now
>>> considered as usable RAM.
>>>
>>> Hope this helps.
>>>
>>>>
>>>> In any case, the mere fact that this causes a regression should be
>>>> sufficient justification to revert/withdraw it from v5.4, as I don't
>>>> see a reason why it was merged there in the first place. (It has no
>>>> fixes tag or cc:stable)
>>>
>>> Agreed, however that means we still need to find out whether a more
>>> recent kernel is also broken, I should be able to tell you that a little
>>> later.
>>
>> FWIW I did test this on Qemu before posting. With 5.12-rc8 and a 1MiB
>> no-map region at 0x80000000, I have the following:
>>
>> 40000000-7fffffff : System RAM
>>   40210000-417fffff : Kernel code
>>   41800000-41daffff : reserved
>>   41db0000-4210ffff : Kernel data
>>   48000000-48008fff : reserved
>> 80000000-800fffff : reserved
>> 80100000-13fffffff : System RAM
>>   fa000000-ffffffff : reserved
>>   13b000000-13f5fffff : reserved
>>   13f6de000-13f77dfff : reserved
>>   13f77e000-13f77efff : reserved
>>   13f77f000-13f7dafff : reserved
>>   13f7dd000-13f7defff : reserved
>>   13f7df000-13f7dffff : reserved
>>   13f7e0000-13f7f3fff : reserved
>>   13f7f4000-13f7fdfff : reserved
>>   13f7fe000-13fffffff : reserved
>>
>> If I remove the 'no-map' qualifier from DT, I get this:
>>
>> 40000000-13fffffff : System RAM
>>   40210000-417fffff : Kernel code
>>   41800000-41daffff : reserved
>>   41db0000-4210ffff : Kernel data
>>   48000000-48008fff : reserved
>>   80000000-800fffff : reserved
>>   fa000000-ffffffff : reserved
>>   13b000000-13f5fffff : reserved
>>   13f6de000-13f77dfff : reserved
>>   13f77e000-13f77efff : reserved
>>   13f77f000-13f7dafff : reserved
>>   13f7dd000-13f7defff : reserved
>>   13f7df000-13f7dffff : reserved
>>   13f7e0000-13f7f3fff : reserved
>>   13f7f4000-13f7fdfff : reserved
>>   13f7fe000-13fffffff : reserved
>>
>> So this does seem to be working fine on my setup. I'll try again with
>> 5.4 to see if I can repro.
>>
>> Also, 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already
>> reserved regions") looks more likely to cause the issue observed here,
>> but that shouldn't be silent. I get the following error message in dmesg
>> if I if place the no-map region on top of the kernel image:
>>
>> OF: fdt: Reserved memory: failed to reserve memory for node 'foobar at 40210000': base 0x0000000040210000, size 1 MiB
>>
>> Is that triggering on your end?
> 
> It is not, otherwise I would have noticed earlier, can you try the same
> thing that happens on my platform with a reserved region (without
> no-map) adjacent to a reserved region with 'no-map'? I will test
> different and newer kernels than 5.4 today to find out if this is still
> a problem with upstream. I could confirm that v4.9.259 also have this
> problem now.

5.10.31 works correctly and shows the following for my platform:

40000000-fdffefff : System RAM
  40200000-40eaffff : Kernel code
  40eb0000-4237ffff : reserved
  42380000-425affff : Kernel data
  45000000-450fffff : reserved
  47000000-4704ffff : reserved
  4761e000-47624fff : reserved
  f8c00000-fdbfffff : reserved
fdfff000-ffffffff : reserved
100000000-13fffffff : System RAM
  13b000000-13effffff : reserved
  13f114000-13f173fff : reserved
  13f174000-13f774fff : reserved
  13f775000-13f7e8fff : reserved
  13f7eb000-13f7ecfff : reserved
  13f7ed000-13f7effff : reserved
  13f7f0000-13fffffff : reserved
-- 
Florian


From arnd at kernel.org  Wed Apr 21 16:22:08 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 21 Apr 2021 17:22:08 +0200
Subject: [PATCH] spi: stm32-qspi: fix debug format string
In-Reply-To: <20210421150510.GA36785@sirena.org.uk>
References: <20210421140653.3964725-1-arnd@kernel.org>
 <20210421150510.GA36785@sirena.org.uk>
Message-ID: <CAK8P3a0CWp_H-tm2QcZyH1FDXwzMgxY_9dc1Y8pA28MQKT-q=A@mail.gmail.com>

On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd at arndb.de>
> >
> > Printing size_t needs a special %zd format modifier to avoid a
> > warning like:
>
> This doesn't apply against current code, please check and resend.

It appears that you just applied 1b8a7d4282c0 ("spi: stm32-qspi:
Fix compilation warning in ARM64") after today's linux-next was
cut.

I suspect Patrice's patch now causes a warning on all architectures
on which size_t is defined as 'unsigned int'.

       Arnd


From u.kleine-koenig at pengutronix.de  Wed Apr 21 16:26:18 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 21 Apr 2021 17:26:18 +0200
Subject: overflow and wrong timeout errors in pwm-atmel
In-Reply-To: <YIA0PXR+oxxpkrzL@piout.net>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
 <20210421092606.1634092-1-u.kleine-koenig@pengutronix.de>
 <20210421110336.bd5s6e2kjxqilddi@pengutronix.de>
 <20210421134825.powx5tvqvce32fho@pengutronix.de>
 <YIA0PXR+oxxpkrzL@piout.net>
Message-ID: <20210421152618.x3wtxdyup7cnvfh5@pengutronix.de>

Hello Alexandre,

On Wed, Apr 21, 2021 at 04:18:37PM +0200, Alexandre Belloni wrote:
> On 21/04/2021 15:48:25+0200, Uwe Kleine-K?nig wrote:
> > On Wed, Apr 21, 2021 at 01:03:36PM +0200, Uwe Kleine-K?nig wrote:
> > > On Wed, Apr 21, 2021 at 11:26:08AM +0200, Uwe Kleine-K?nig wrote:
> > > > With these three patches PWM_DEBUG is now happy. (At least I couldn't
> > > > trigger a warning any more. I think there are still a few problems with
> > > > integer overflows.)
> > > 
> > > BTW, setting the period to 138350580899 (with a clock rate of 133333333
> > > Hz) results in setting period=0 because
> > > 
> > > 	state->period * clkrate =
> > > 	138350580899 * 133333333 =
> > > 	40254751 (discarded from 18446744073749806367).
> > 
> > As a first remedy the following could be done:
> > 
> > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > index 38d86340201c..02d69fa5f7d2 100644
> > --- a/drivers/pwm/pwm-atmel.c
> > +++ b/drivers/pwm/pwm-atmel.c
> > @@ -199,6 +199,11 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
> >  	unsigned long long cycles = state->period;
> >  	int shift;
> >  
> > +	if (fls(cycles) + fls(clkrate) > 64) {
> > +		dev_err(chip->dev, "period to big to calculate HW parameters\n");
> > +		return -EINVAL;
> > +	}
> > +
> >  	/* Calculate the period cycles and prescale value */
> >  	cycles *= clkrate;
> >  	do_div(cycles, NSEC_PER_SEC);
> > 
> > Is this sensible? (Actually I'd prefer to just continue with
> > 
> > 	period = (ULL(1) << (64 - fls(clkrate))) - 1
> > 
> > according to the motto to yield the highest possible period, but this
> > function has another error path that returns -EINVAL so this would be
> > inconsistent.)
> 
> Shouldn't that be -ERANGE?

The other exit point a few lines down also uses -EINVAL so I sticked to
that.

> I do think it is better to return an error and let userspace decide
> what is the policy instead of having the policy in the driver.

I agree that the consumer (userspace is just one of them) should have
the choice what happens. IMHO the only sane way to implement this is
using a round_state function that tells the consumer what they can
expect when a certain state is passed to apply. (Otherwise the consumer
might already be unhappy if they request a period of say 652799 ns and
the driver implements 645120 ns (which is BTW what happens with the
pwm-atmel driver when feed by a 133333333 Hz clk).)

And another critical detail of this round_state function is that it
should expose the same behaviour for all lowlevel drivers. I think
first rounding down period and then duty_cycle is a good strategy that
can be worked with. With that in place the next (IMHO) obvious
conclusion is that .apply() should behave in the same way for
consistency and also to keep the drivers simple.

If then a consumer prefers a different rounding strategy (e.g. for the
pwm-ir-tx driver rounding to the nearest values is better), this can be
(more or less) easily and (more important) generically implemented in a
single place.

Does this make sense in your eyes?

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/20210421/ac92d339/attachment.sig>

From liam.howlett at oracle.com  Wed Apr 21 16:47:21 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Wed, 21 Apr 2021 15:47:21 +0000
Subject: [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal
 generation
In-Reply-To: <202104210515.VoF3YT1J-lkp@intel.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <202104210515.VoF3YT1J-lkp@intel.com>
Message-ID: <20210421154716.z65ergzd3pylpbvl@revolver>

* kernel test robot <lkp at intel.com> [210420 17:22]:
> Hi Liam,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on arm64/for-next/core]
> [also build test WARNING on arm-perf/for-next/perf xlnx/master arm/for-next soc/for-next kvmarm/next linus/master v5.12-rc8 next-20210420]
> [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]
> 
> url:    https://github.com/0day-ci/linux/commits/Liam-Howlett/arm64-armv8_deprecated-Fix-swp_handler-signal-generation/20210421-005252
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> config: arm64-allyesconfig (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://github.com/0day-ci/linux/commit/96a011695861072d32851ba3a104b19106955869
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Liam-Howlett/arm64-armv8_deprecated-Fix-swp_handler-signal-generation/20210421-005252
>         git checkout 96a011695861072d32851ba3a104b19106955869
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arm64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
>    arch/arm64/kernel/armv8_deprecated.c: In function 'swp_handler':
> >> arch/arm64/kernel/armv8_deprecated.c:418:11: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
>      418 |  else if (res = -ENXIO) /* Unaligned pointer */
>          |           ^~~
> 

Ah, I hadn't had the correct config enabled for this code to be
compiled.  I will wait for any other comments then I'll send out a v2
with this fix.

Thanks,
Liam


From maz at kernel.org  Wed Apr 21 16:49:03 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 16:49:03 +0100
Subject: [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts
In-Reply-To: <YIA8RCjoI+9nChN6@xps13.dannf>
References: <20200519161755.209565-1-maz@kernel.org>
 <20200519161755.209565-9-maz@kernel.org>
 <YH87dtTfwYgavusz@xps13.dannf> <YH9G3+aDUWpcLCpD@xps13.dannf>
 <8735vjrjj3.wl-maz@kernel.org> <YIA8RCjoI+9nChN6@xps13.dannf>
Message-ID: <87wnsvprio.wl-maz@kernel.org>

On Wed, 21 Apr 2021 15:52:52 +0100,
dann frazier <dann.frazier at canonical.com> wrote:
> 
> [ + Fu Wei ]

[...]

> >
> > Please feed this stacktrace to scripts/decode_stacktrace.sh so that I
> > can get an idea about what is going wrong. I bet something is playing
> > ungodly games with the one of the IPIs, and things go horribly wrong.
> 
> hey Marc,
>   Sure:
> 
> [    7.927289] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028
> [    7.936326] Mem abort info:
> [    7.939108]   ESR = 0x96000004
> [    7.942151]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    7.947451]   SET = 0, FnV = 0
> [    7.950494]   EA = 0, S1PTW = 0
> [    7.953624] Data abort info:
> [    7.956492]   ISV = 0, ISS = 0x00000004
> [    7.960316]   CM = 0, WnR = 0
> [    7.963273] [0000000000000028] user address but active_mm is swapper
> [    7.969616] Internal error: Oops: 96000004 [#1] SMP
> [    7.974483] Modules linked in:
> [    7.977531] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc8 #19
> [    7.983874] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS F02 08/06/2019
> [    7.990737] pstate: 40400085 (nZcv daIf +PAN -UAO -TCO BTYPE=--)
> [    7.996732] pc : __ipi_send_mask (/home/ubuntu/linux/./include/linux/irqdomain.h:537 /home/ubuntu/linux/kernel/irq/ipi.c:283) 
> [    8.000910] lr : smp_cross_call (/home/ubuntu/linux/arch/arm64/kernel/smp.c:958) 
> [    8.004913] sp : ffff800012753c10
> [    8.008216] x29: ffff800012753c10 x28: ffff000100de5d00
> [    8.013521] x27: 000000000000000a x26: ffff80001225da20
> [    8.018825] x25: 0000000000000000 x24: ffff000ff62719b0
> [    8.024129] x23: ffff80001225d000 x22: ffff800012368108
> [    8.029433] x21: ffff800010f69a20 x20: 0000000000000000
> [    8.034737] x19: ffff000100143c60 x18: 0000000000000020
> [    8.040041] x17: 000000008e74252f x16: 00000000bf0ab2ad
> [    8.045345] x15: ffffffffffffffff x14: 0000000000000000
> [    8.050649] x13: 003d090000000000 x12: 00003d0900000000
> [    8.055953] x11: 0000000000000000 x10: 00003d0900000000
> [    8.061257] x9 : ffff800010027f14 x8 : 0000000000000000
> [    8.066561] x7 : 00000000ffffffff x6 : ffff000ff6148698
> [    8.071865] x5 : ffff80001159d040 x4 : ffff80001159d110
> [    8.077169] x3 : ffff800010f69a00 x2 : 0000000000000000
> [    8.082473] x1 : ffff800010f69a20 x0 : 0000000000000000
> [    8.087777] Call trace:
> [    8.090213] __ipi_send_mask (/home/ubuntu/linux/./include/linux/irqdomain.h:537 /home/ubuntu/linux/kernel/irq/ipi.c:283) 

Thanks for that. This resolves to:

	if (irq_domain_is_ipi_per_cpu(data->domain)) {

data->domain is NULL, and we probably are using freed memory...

> > Now, here's a hunch: in the fine TX1 tradition, the firmware is broken
> > and the GTDT table looks unusable. Amusingly, the crash happens right
> > after the SBSA watchdog fails to probe.
> 
> Yeah, I noticed that, but didn't highlight it as I didn't see it in
> the backtrace...
> 
> > And looking at the code that implements that driver, it looks dodgy as
> > hell, as it unmaps an interrupt it doesn't even know is valid. And it
> > does that right when the driver fails the way you experienced it. If,
> > by any chance, the interrupt field is 0 in the firmware table, this
> > results in SGI0 being unmapped. Given that this is the rescheduling
> > interrupt, fireworks happen.
> 
> ... and that explains why. I wouldn't have gotten there, but wish I'd
> thought to test w/ the watchdog compiled out :(

No worries. This IRQ series has uncovered a number of terrible driver
behaviours since I merged it, and these bugs are worth every penny.

> > Can you have a go with the patchlet below, and let me know if that
> > helps?
> 
> It does!

Awesome. I'll Cc you on the actual patch, feel free to respond with a
Tested-by: if you want.

Thanks,

	M.

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


From robh at kernel.org  Wed Apr 21 17:12:41 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 11:12:41 -0500
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support
 custom GMAC label
In-Reply-To: <trinity-47c2d588-093d-4054-a16f-81d76aa667e0-1619013874284@3c-app-gmx-bs34>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
 <20210420195132.GA3686955@robh.at.kernel.org>
 <CALCv0x2SG=0kBRnxfSPxi+FvaBK=QGPHQkHWHvTXOw64KawPUQ@mail.gmail.com>
 <trinity-47c2d588-093d-4054-a16f-81d76aa667e0-1619013874284@3c-app-gmx-bs34>
Message-ID: <CAL_JsqKne=ASOyd0E9GakVvDvaXDauHOOU5NgxU8X8ySvyrAcw@mail.gmail.com>

On Wed, Apr 21, 2021 at 9:05 AM Frank Wunderlich
<frank-w at public-files.de> wrote:
>
> Hi,
>
> for dsa slave-ports there is already a property "label", but not for master/cpu-ports

Is that because slave ports are external and master are not? If so,
that makes sense.

> https://elixir.bootlin.com/linux/v5.12-rc8/source/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts#L163
>
> handled here:
>
> https://elixir.bootlin.com/linux/v5.12-rc8/source/net/dsa/dsa2.c#L1113
>
> @ilya maybe you can rename slave-ports instead of master-port without code change?
>
> i also prefer a more generic way to name interfaces in dts, not only in the mtk-driver, but the udev-approach is a way too, but this needs to be configured on each system manually...a preset by kernel/dts will be nice (at least to distinguish master/cpu- and user-ports).


Seems like it could be possible to want to distinguish port types for
reasons other than just what to name the device. Better to describe
that difference in DT and then base the device name off of that.

If you just want fixed numbering, then 'aliases' node is generally how
that is done (either because it sneaks in or fatigue from arguing
fixed /dev nodes are an anti-feature). There's already 'ethernetN'
which u-boot uses, but the kernel so far does not.

Rob


From elver at google.com  Wed Apr 21 17:27:47 2021
From: elver at google.com (Marco Elver)
Date: Wed, 21 Apr 2021 18:27:47 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
References: <1fbf3429-42e5-0959-9a5c-91de80f02b6a@samsung.com>
 <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
 <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
Message-ID: <YIBSg7Vi+U383dT7@elver.google.com>

On Wed, Apr 21, 2021 at 05:11PM +0200, Marco Elver wrote:
> +Cc linux-arm-kernel
> 
[...]
> >
> > I've managed to reproduce this issue with a public Raspberry Pi OS Lite
> > rootfs image, even without deploying kernel modules:
> >
> > https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-03-25/2021-03-04-raspios-buster-armhf-lite.zip
> >
> > # qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon
> > console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none
> > -monitor null -device virtio-blk-device,drive=virtio-blk -drive
> > file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw
> > -netdev user,id=user -device virtio-net-device,netdev=user
> >
> > The above one doesn't boot if zImage z compiled from commit fb6cc127e0b6
> > and boots if compiled from 2e498d0a74e5. In both cases I've used default
> > arm/multi_v7_defconfig and
> > gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.
> 
> Yup, I've narrowed it down to the addition of "__u64 _perf" to
> siginfo_t. My guess is the __u64 causes a different alignment for a
> bunch of adjacent fields. It seems that x86 and m68k are the only ones
> that have compile-time tests for the offsets. Arm should probably add
> those -- I have added a bucket of static_assert() in
> arch/arm/kernel/signal.c and see that something's off.
> 
> I'll hopefully have a fix in a day or so.

Arm and compiler folks: are there some special alignment requirement for
__u64 on arm 32-bit? (And if there is for arm64, please shout as well.)

With the static-asserts below, the only thing that I can do to fix it is
to completely remove the __u64. Padding it before or after with __u32
just does not work. It seems that the use of __u64 shifts everything
in __sifields by 4 bytes.

diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index d0bb9125c853..b02a4ac55938 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -92,7 +92,10 @@ union __sifields {
 				__u32 _pkey;
 			} _addr_pkey;
 			/* used when si_code=TRAP_PERF */
-			__u64 _perf;
+			struct {
+				__u32 _perf1;
+				__u32 _perf2;
+			} _perf;
 		};
 	} _sigfault;

^^ works, but I'd hate to have to split this into 2 __u32 because it
makes the whole design worse.

What alignment trick do we have to do here to fix it for __u64?


------ >8 ------

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index a3a38d0a4c85..6c558dc314c3 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -725,3 +725,41 @@ asmlinkage void do_rseq_syscall(struct pt_regs *regs)
 	rseq_syscall(regs);
 }
 #endif
+
+/*
+ * Compile-time tests for siginfo_t offsets. Changes to NSIG* likely come with
+ * new fields; new fields should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(siginfo_t, si_pid)	== 0x0c);
+#if 0
+static_assert(offsetof(siginfo_t, si_uid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_tid)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_overrun)	== 0x10);
+static_assert(offsetof(siginfo_t, si_status)	== 0x14);
+static_assert(offsetof(siginfo_t, si_utime)	== 0x18);
+static_assert(offsetof(siginfo_t, si_stime)	== 0x1c);
+static_assert(offsetof(siginfo_t, si_value)	== 0x14);
+static_assert(offsetof(siginfo_t, si_int)	== 0x14);
+static_assert(offsetof(siginfo_t, si_ptr)	== 0x14);
+static_assert(offsetof(siginfo_t, si_addr)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_addr_lsb)	== 0x10);
+static_assert(offsetof(siginfo_t, si_lower)	== 0x14);
+static_assert(offsetof(siginfo_t, si_upper)	== 0x18);
+static_assert(offsetof(siginfo_t, si_pkey)	== 0x14);
+static_assert(offsetof(siginfo_t, si_perf)	== 0x10);
+static_assert(offsetof(siginfo_t, si_band)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_fd)	== 0x10);
+static_assert(offsetof(siginfo_t, si_call_addr)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_syscall)	== 0x10);
+static_assert(offsetof(siginfo_t, si_arch)	== 0x14);
+#endif



From reinette.chatre at intel.com  Wed Apr 21 17:39:43 2021
From: reinette.chatre at intel.com (Reinette Chatre)
Date: Wed, 21 Apr 2021 09:39:43 -0700
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
Message-ID: <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>

Hi Tan Shaopeng,

On 4/21/2021 1:37 AM, tan.shaopeng at fujitsu.com wrote:
> Hi,
> 
> Ping... any comments&advice about add an A64FX cache control function into resctrl?

My apologies for the delay.

> 
> Best regards
> Tan Shaopeng
> 
>> Hello
>>
>>
>> I'm Tan Shaopeng from Fujitsu Limited.
>>
>> I?m trying to implement Fujitsu A64FX?s cache related features.
>> It is a cache partitioning function we called sector cache function that using
>> the value of the tag that is upper 8 bits of the 64bit address and the value of the
>> sector cache register to control virtual cache capacity of the L1D&L2 cache.
>>
>> A few days ago, when I sent a driver that realizes this function to
>> ARM64 kernel community, Will Deacon and Arnd Bergmann suggested an idea
>> to add the sector cache function of A64FX into resctrl.
>> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5Oc
>> Z=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/
>>
>> Based on my study, I think the sector cache function of A64FX can be added
>> into the allocation features of resctrl after James' resctrl rework has finished.
>> But, in order to implement this function, more interfaces for resctrl are need.
>> The details are as follow, and could you give me some advice?
>>
>> [Sector cache function]
>> The sector cache function split cache into multiple sectors and control them
>> separately. It is implemented on the L1D cache and
>> L2 cache in the A64FX processor and can be controlled individually for L1D
>> cache and L2 cache. A64FX has no L3 cache. Each L1D cache and L2 cache
>> has 4 sectors. Which L1D sector is used is specified by the value of [57:56] bits
>> of address, how many ways of sector are specified by the value of register
>> (IMP_SCCR_L1_EL0).
>> Which L2 sector is used is specified by the value of [56] bits of address, and
>> how many ways of sector are specified by value of register
>> (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
>> IMP_SCCR_SET1_L2_EL1).
>>
>> For more details of sector cache function, see A64FX HPC extension
>> specification (1.2. Sector cache) in https://github.com/fujitsu/A64FX

The overview in section 12 was informative but very high level.
I was not able to find any instance of "IMP_SCCR" in this document to  
explore how this cache allocation works.

Are these cache sectors exposed to the OS in any way? For example, when  
the OS discovers the cache, does it learn about these sectors and expose  
the details to user space (/sys/devices/system/cpuX/cache)?

The overview of Sector Cache in that document provides details of how  
the size of the sector itself is dynamically adjusted to usage. That  
description is quite cryptic but it seems like a sector, since the  
number of ways associated with it can dynamically change, is more  
equivalent to a class of service or resource group in the resctrl  
environment.

I really may be interpreting things wrong here, could you perhaps point  
me to where I can obtain more details?


>> [Difference between resctrl(CAT) and this sector cache function]
>> L2/L3 CAT (Cache Allocation Technology) enables the user to specify some
>> physical partition of cache space that an application can fill.
>> A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function enables
>> a user to specify number of ways each sector uses.
>> Therefore, for CAT it is enough to specify a cache portion for each cache_id
>> (socket). On the other hand, sector cache needs to specify cache portion of
>> each sector for each cache_id, and following extension to resctrl interface is
>> needed to support sector cache.
>>
>> [Idear for A64FX sector cache function control interface (schemata file
>> details)]
>> L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cw
>> bm>,<cwbm>,<cwbm>,<cwbm>;?
>> L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=
>> <cwbm>,<cwbm>,<cwbm>,<cwbm>;?
>>
>> ?L1: Add a new interface to control the L1D cache.
>> ?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for each
>> sector.
>> ?cwbm?Specify the number of ways in each sector as a bitmap (percentage),
>>    but the bitmap does not indicate the location of the cache.
>> * In the sector cache function, L2 sector cache way setting register is
>>    shared among PEs (Processor Element) in shared domain. If two PEs
>>    which share L2 cache belongs to different resource groups, one resource
>>    group's L2 setting will affect to other resource group's L2 setting.

In resctrl a "resource group" can be viewed as a class of service.

>> * Since A64FX does not support MPAM, it is not necessary to consider
>>    how to switch between MPAM and sector cache function now.
>>
>> Some questions:
>> 1.I'm still studying about RDT, could you tell me whether RDT has
>>    the similar mechanism with sector cache function?

This is not clear to me yet. One thing to keep in mind is that a bit in  
the capacity bitmask could correspond to some number of ways in a cache,  
but it does not have to. It is essentially a hint to hardware on how  
much cache space needs to be allocated while also indicating overlap and  
isolation from other allocations.

resctrl already supports the bitmask being interpreted differently  
between architectures and with the MPAM support there will be even more  
support for different interpretations.

>> 2.In RDT, L3 cache is shared among cores in socket. If two cores which
>>    share L3 cache belongs to different resource groups, one resource
>>    group's L3 setting will affect to other resource group's L3 setting?

This question is not entirely clear to me. Are you referring to the  
hardware layout or configuration changes via the resctrl "cpus" file?

Each resource group is a class of service (CLOS) that is supported by  
all cache instances. By default each resource group would thus contain  
all cache instances on the system (even if some cache instances do not  
support the same number of CLOS resctrl would only support the CLOS  
supported by all resources).

Reinette


From maz at kernel.org  Wed Apr 21 17:43:15 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 17:43:15 +0100
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
Message-ID: <20210421164317.1718831-1-maz@kernel.org>

Dann recently reported that his ThunderX machine failed to boot since
64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
interrupts"), with a not so pretty crash while trying to send an IPI.

It turned out to be caused by a mix of broken firmware and a buggy
GTDT watchdog driver. Both have forever been buggy, but the above
commit revealed that the error handling path of the driver was
probably the worse part of it all.

Anyway, this short series has two goals:
- handle broken firmware in a less broken way
- make sure that the route cause of the problem can be identified
  quickly

Thanks,

	M.

Marc Zyngier (2):
  ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
  ACPI: irq: Prevent unregistering of GIC SGIs

 drivers/acpi/arm64/gtdt.c | 10 ++++++----
 drivers/acpi/irq.c        |  6 +++++-
 2 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.29.2


From maz at kernel.org  Wed Apr 21 17:43:16 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 17:43:16 +0100
Subject: [PATCH 1/2] ACPI: GTDT: Don't corrupt interrupt mappings on watchdow
 probe failure
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <20210421164317.1718831-2-maz@kernel.org>

When failing the driver probe because of invalid firmware properties,
the GTDT driver unmaps the interrupt that it mapped earlier.

However, it never checks whether the mapping of the interrupt actially
succeeded. Even more, should the firmware report an illegal interrupt
number that overlaps with the GIC SGI range, this can result in an
IPI being unmapped, and subsequent fireworks (as reported by Dann
Frazier).

Rework the driver to have a slightly saner behaviour and actually
check whether the interrupt has been mapped before unmapping things.

Reported-by: dann frazier <dann.frazier at canonical.com>
Fixes: ca9ae5ec4ef0 ("acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver")
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/YH87dtTfwYgavusz at xps13.dannf
Cc: stable at vgerlkernel.org
Cc: Fu Wei <wefu at redhat.com>
---
 drivers/acpi/arm64/gtdt.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index f2d0e5915dab..0a0a982f9c28 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -329,7 +329,7 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 					int index)
 {
 	struct platform_device *pdev;
-	int irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+	int irq;
 
 	/*
 	 * According to SBSA specification the size of refresh and control
@@ -338,7 +338,7 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 	struct resource res[] = {
 		DEFINE_RES_MEM(wd->control_frame_address, SZ_4K),
 		DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K),
-		DEFINE_RES_IRQ(irq),
+		{},
 	};
 	int nr_res = ARRAY_SIZE(res);
 
@@ -348,10 +348,11 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 
 	if (!(wd->refresh_frame_address && wd->control_frame_address)) {
 		pr_err(FW_BUG "failed to get the Watchdog base address.\n");
-		acpi_unregister_gsi(wd->timer_interrupt);
 		return -EINVAL;
 	}
 
+	irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+	res[2] = (struct resource)DEFINE_RES_IRQ(irq);
 	if (irq <= 0) {
 		pr_warn("failed to map the Watchdog interrupt.\n");
 		nr_res--;
@@ -364,7 +365,8 @@ static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
 	 */
 	pdev = platform_device_register_simple("sbsa-gwdt", index, res, nr_res);
 	if (IS_ERR(pdev)) {
-		acpi_unregister_gsi(wd->timer_interrupt);
+		if (irq > 0)
+			acpi_unregister_gsi(wd->timer_interrupt);
 		return PTR_ERR(pdev);
 	}
 
-- 
2.29.2



From maz at kernel.org  Wed Apr 21 17:43:17 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 17:43:17 +0100
Subject: [PATCH 2/2] ACPI: irq: Prevent unregistering of GIC SGIs
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <20210421164317.1718831-3-maz@kernel.org>

When using ACPI on arm64, which implies the GIC IRQ model, no
table should ever provide a GSI number in the range [0:15],
as these are reserved for IPIs.

However, drivers tend to call acpi_unregister_gsi() with any
random GSI number provided by half baked tables, which results
in an exploding kernel when its IPIs have been unconfigured.

In order to catch this, check for the silly case early, warn
that something is going wrong and avoid the above disaster.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/acpi/irq.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
index e209081d644b..c68e694fca26 100644
--- a/drivers/acpi/irq.c
+++ b/drivers/acpi/irq.c
@@ -75,8 +75,12 @@ void acpi_unregister_gsi(u32 gsi)
 {
 	struct irq_domain *d = irq_find_matching_fwnode(acpi_gsi_domain_id,
 							DOMAIN_BUS_ANY);
-	int irq = irq_find_mapping(d, gsi);
+	int irq;
 
+	if (WARN_ON(acpi_irq_model == ACPI_IRQ_MODEL_GIC && gsi < 16))
+		return;
+
+	irq = irq_find_mapping(d, gsi);
 	irq_dispose_mapping(irq);
 }
 EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
-- 
2.29.2



From frank-w at public-files.de  Wed Apr 21 17:48:28 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Wed, 21 Apr 2021 18:48:28 +0200
Subject: [PATCH net-next v2 2/2] net: ethernet: mediatek: support
 custom GMAC label
In-Reply-To: <CAL_JsqKne=ASOyd0E9GakVvDvaXDauHOOU5NgxU8X8ySvyrAcw@mail.gmail.com>
References: <20210419154659.44096-1-ilya.lipnitskiy@gmail.com>
 <20210419154659.44096-3-ilya.lipnitskiy@gmail.com>
 <20210420195132.GA3686955@robh.at.kernel.org>
 <CALCv0x2SG=0kBRnxfSPxi+FvaBK=QGPHQkHWHvTXOw64KawPUQ@mail.gmail.com>
 <trinity-47c2d588-093d-4054-a16f-81d76aa667e0-1619013874284@3c-app-gmx-bs34>
 <CAL_JsqKne=ASOyd0E9GakVvDvaXDauHOOU5NgxU8X8ySvyrAcw@mail.gmail.com>
Message-ID: <278445B7-727F-444D-8F5F-986CAD38BA57@public-files.de>

Am 21. April 2021 18:12:41 MESZ schrieb Rob Herring <robh at kernel.org>:
>On Wed, Apr 21, 2021 at 9:05 AM Frank Wunderlich
><frank-w at public-files.de> wrote:
>>
>> Hi,
>>
>> for dsa slave-ports there is already a property "label", but not for
>master/cpu-ports
>
>Is that because slave ports are external and master are not? If so,
>that makes sense.

In my case gmac is internal,yes...i don't know if ilyas device is similar.

But in a previous kernel-version the gmac of bpi-r2 can be passed through mt7530 switch and gets available external while bypassing dsa core. Here i wanted renaming of this port (gmac1=eth1 mapped as wan-port,while gmac0=eth0 was splitted by dsa switch driver to lan0-lan3)

>Seems like it could be possible to want to distinguish port types for
>reasons other than just what to name the device. Better to describe
>that difference in DT and then base the device name off of that.

Interface names should be not only numbering as they can have different meaning (wan vs. lan).

>If you just want fixed numbering, then 'aliases' node is generally how
>that is done (either because it sneaks in or fatigue from arguing
>fixed /dev nodes are an anti-feature). There's already 'ethernetN'
>which u-boot uses, but the kernel so far does not.

Aliases are not yet used as interface name...do you want this way (use alias name as ifname)? imho we can define multiple aliases to one dt node which is imho not the best way as interface can have only one name, and interface is created feom target node from where the alias needs to be found.

regards Frank


From robh at kernel.org  Wed Apr 21 17:59:51 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 11:59:51 -0500
Subject: [PATCH v13 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek
 MT8183
In-Reply-To: <20210421132841.v13.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
 <20210421132841.v13.1.Ie74d3355761aab202d4825ac6f66d990bba0130e@changeid>
Message-ID: <20210421165951.GA1292095@robh.at.kernel.org>

On Wed, 21 Apr 2021 13:28:52 +0800, Nicolas Boichat wrote:
> Define a compatible string for the Mali Bifrost GPU found in
> Mediatek's MT8183 SoCs.
> 
> Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
> ---
> 
> (no changes since v12)
> 
> Changes in v12:
>  - binding: Fix min/maxItems logic (Rob Herring)
> 
> Changes in v11:
>  - binding: power-domain-names not power-domainS-names
> 
> Changes in v10:
>  - Fix the binding to make sure sram-supply property can be provided.
> 
> Changes in v6:
>  - Rebased, actually tested with recent mesa driver.
> 
> Changes in v5:
>  - Rename "2d" power domain to "core2"
> 
> Changes in v4:
>  - Add power-domain-names description
>    (kept Alyssa's reviewed-by as the change is minor)
> 
>  .../bindings/gpu/arm,mali-bifrost.yaml        | 30 ++++++++++++++++++-
>  1 file changed, 29 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Wed Apr 21 18:05:30 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 12:05:30 -0500
Subject: [PATCH v3 05/10] dt-bindings: arm64: dts: mediatek: Add
 mt8183-kukui-jacuzzi-fennel
In-Reply-To: <20210421090601.730744-6-hsinyi@chromium.org>
References: <20210421090601.730744-1-hsinyi@chromium.org>
 <20210421090601.730744-6-hsinyi@chromium.org>
Message-ID: <20210421170530.GA1299957@robh.at.kernel.org>

On Wed, 21 Apr 2021 17:05:56 +0800, Hsin-Yi Wang wrote:
> Fennel is known as Lenovo IdeaPad Flex 3 Chromebook.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Wed Apr 21 18:05:30 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 01:05:30 +0800
Subject: [xlnx:master 11230/12130] drivers/remoteproc/ingenic_rproc.c:144:14:
 error: initialization of 'void * (*)(struct rproc *, u64,
 int)' {aka 'void
 * (*)(struct rproc *, long long unsigned int,  int)'} from incompatible
 pointer type 'void * (*)(struct rproc *, u64,  size_t)' {aka 'vo...
Message-ID: <202104220128.Lh7SQ0x5-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: a324889a971b8e827c53deaffe630b420bde4067 [11230/12130] remoteproc: Add support for peek from remote and acking kick from remote
config: sparc-randconfig-r016-20210421 (attached as .config)
compiler: sparc-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/a324889a971b8e827c53deaffe630b420bde4067
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout a324889a971b8e827c53deaffe630b420bde4067
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=sparc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/remoteproc/ingenic_rproc.c:144:14: error: initialization of 'void * (*)(struct rproc *, u64,  int)' {aka 'void * (*)(struct rproc *, long long unsigned int,  int)'} from incompatible pointer type 'void * (*)(struct rproc *, u64,  size_t)' {aka 'void * (*)(struct rproc *, long long unsigned int,  unsigned int)'} [-Werror=incompatible-pointer-types]
     144 |  .da_to_va = ingenic_rproc_da_to_va,
         |              ^~~~~~~~~~~~~~~~~~~~~~
   drivers/remoteproc/ingenic_rproc.c:144:14: note: (near initialization for 'ingenic_rproc_ops.da_to_va')
   cc1: some warnings being treated as errors
--
>> drivers/remoteproc/mtk_scp.c:463:14: error: initialization of 'void * (*)(struct rproc *, u64,  int)' {aka 'void * (*)(struct rproc *, long long unsigned int,  int)'} from incompatible pointer type 'void * (*)(struct rproc *, u64,  size_t)' {aka 'void * (*)(struct rproc *, long long unsigned int,  unsigned int)'} [-Werror=incompatible-pointer-types]
     463 |  .da_to_va = scp_da_to_va,
         |              ^~~~~~~~~~~~
   drivers/remoteproc/mtk_scp.c:463:14: note: (near initialization for 'scp_ops.da_to_va')
   cc1: some warnings being treated as errors


vim +144 drivers/remoteproc/ingenic_rproc.c

48f0a1bbb7586c Paul Cercueil   2020-05-15  137  
48f0a1bbb7586c Paul Cercueil   2020-05-15  138  static struct rproc_ops ingenic_rproc_ops = {
4605ad8f458198 Mathieu Poirier 2020-06-30  139  	.prepare = ingenic_rproc_prepare,
4605ad8f458198 Mathieu Poirier 2020-06-30  140  	.unprepare = ingenic_rproc_unprepare,
48f0a1bbb7586c Paul Cercueil   2020-05-15  141  	.start = ingenic_rproc_start,
48f0a1bbb7586c Paul Cercueil   2020-05-15  142  	.stop = ingenic_rproc_stop,
48f0a1bbb7586c Paul Cercueil   2020-05-15  143  	.kick = ingenic_rproc_kick,
48f0a1bbb7586c Paul Cercueil   2020-05-15 @144  	.da_to_va = ingenic_rproc_da_to_va,
48f0a1bbb7586c Paul Cercueil   2020-05-15  145  };
48f0a1bbb7586c Paul Cercueil   2020-05-15  146  

:::::: The code at line 144 was first introduced by commit
:::::: 48f0a1bbb7586c94e0f15116b06f8179df2fd60f remoteproc: ingenic: Added remoteproc driver

:::::: TO: Paul Cercueil <paul at crapouillou.net>
:::::: CC: Bjorn Andersson <bjorn.andersson at linaro.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 27013 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/42214cf3/attachment-0001.gz>

From kasong at redhat.com  Wed Apr 21 17:34:38 2021
From: kasong at redhat.com (Kairui Song)
Date: Thu, 22 Apr 2021 00:34:38 +0800
Subject: [PATCH] ARM: mark free_initrd_mem as __init
Message-ID: <20210421163438.1719964-1-kasong@redhat.com>

free_initrd_mem is only called from __init functions, and only used
during boot, so mark it __init.

Signed-off-by: Kairui Song <kasong at redhat.com>
---
 arch/arm/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 828a2561b229..6db5c0d37d95 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -528,7 +528,7 @@ void free_initmem(void)
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
-void free_initrd_mem(unsigned long start, unsigned long end)
+void __init free_initrd_mem(unsigned long start, unsigned long end)
 {
 	if (start == initrd_start)
 		start = round_down(start, PAGE_SIZE);
-- 
2.30.2



From mark.rutland at arm.com  Wed Apr 21 18:10:05 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 21 Apr 2021 18:10:05 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210419121932.GA30004@willie-the-truck>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <20210416133431.GA2303@C02TD0UTHF1T.local>
 <20210419121932.GA30004@willie-the-truck>
Message-ID: <20210421171005.GA46949@C02TD0UTHF1T.local>

On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote:
> On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> > I think this is a problem we created for ourselves back in commit:
> > 
> >   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
> > 
> > AFAICT, the perf regs samples are the only place this matters, since for
> > ptrace the compat regs are implicitly truncated to compat_ulong_t, and
> > audit expects the non-truncated return value. Other architectures don't
> > truncate here, so I think we're setting ourselves up for a game of
> > whack-a-mole to truncate and extend wherever we need to.
> > 
> > Given that, I suspect it'd be better to do something like the below.
> > 
> > Will, thoughts?
> 
> I think perf is one example, but this is also visible to userspace via the
> native ptrace interface and I distinctly remember needing this for some
> versions of arm64 strace to work correctly when tracing compat tasks.

FWIW, you've convinced me on your approach (more on that below), but
when I went digging here this didn't seem to be exposed via ptrace --
for any task tracing a compat task, the GPRs are exposed via
compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving
the lower 32 bits. See task_user_regset_view() for where we get the
regset.

Am I missing something, or are you thinking of another issue you fixed
at the same time?

> So I do think that clearing the upper bits on the return path is the right
> approach, but it sounds like we need some more work to handle syscall(-1)
> and audit (what exactly is the problem here after these patches have been
> applied?)

>From digging a bit more, I think I agree, and I think these patches are
sufficient for audit. I have some comments I'll leave separately.

The remaining issues are wherever we assign a signed value to a compat
GPR without explicit truncation. That'll leak via perf sampling the user
regs, but I haven't managed to convince myself whether that causes any
functional change in behaviour for audit, seccomp, or syscall tracing.

Since we mostly use compat_ulong_t for intermediate values in compat
code, it does look like this is only an issue for x0 where we assign an
error value, e.g. the -ENOSYS case in el0_svc_common. I'll go see if I
can find any more.

With those fixed up we can remove the x0 truncation from entry.S,
which'd be nice too.

Thanks,
Mark.


From sudeep.holla at arm.com  Wed Apr 21 18:14:49 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 21 Apr 2021 18:14:49 +0100
Subject: [PATCH 1/2] ACPI: GTDT: Don't corrupt interrupt mappings on
 watchdow probe failure
In-Reply-To: <20210421164317.1718831-2-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210421164317.1718831-2-maz@kernel.org>
Message-ID: <20210421171449.pukjblgxfp7hcok6@bogus>

On Wed, Apr 21, 2021 at 05:43:16PM +0100, Marc Zyngier wrote:
> When failing the driver probe because of invalid firmware properties,
> the GTDT driver unmaps the interrupt that it mapped earlier.
> 
> However, it never checks whether the mapping of the interrupt actially
> succeeded. Even more, should the firmware report an illegal interrupt
> number that overlaps with the GIC SGI range, this can result in an
> IPI being unmapped, and subsequent fireworks (as reported by Dann
> Frazier).
> 
> Rework the driver to have a slightly saner behaviour and actually
> check whether the interrupt has been mapped before unmapping things.
>

Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Wed Apr 21 18:15:16 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 21 Apr 2021 18:15:16 +0100
Subject: [PATCH 2/2] ACPI: irq: Prevent unregistering of GIC SGIs
In-Reply-To: <20210421164317.1718831-3-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210421164317.1718831-3-maz@kernel.org>
Message-ID: <20210421171516.hg3ex7jqigqjqa6i@bogus>

On Wed, Apr 21, 2021 at 05:43:17PM +0100, Marc Zyngier wrote:
> When using ACPI on arm64, which implies the GIC IRQ model, no
> table should ever provide a GSI number in the range [0:15],
> as these are reserved for IPIs.
>
> However, drivers tend to call acpi_unregister_gsi() with any
> random GSI number provided by half baked tables, which results
> in an exploding kernel when its IPIs have been unconfigured.
>
> In order to catch this, check for the silly case early, warn
> that something is going wrong and avoid the above disaster.
>

Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>

Just curious if this is just precaution or do we have a platform doing
something stupid like this ?

--
Regards,
Sudeep


From mark.rutland at arm.com  Wed Apr 21 18:17:15 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 21 Apr 2021 18:17:15 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <9b5b340b-66ad-41c9-865e-32724e33a5b8@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <9b5b340b-66ad-41c9-865e-32724e33a5b8@windriver.com>
Message-ID: <20210421171715.GA52940@C02TD0UTHF1T.local>

On Tue, Apr 20, 2021 at 04:42:53PM +0800, He Zhe wrote:
> On 4/16/21 8:33 PM, Catalin Marinas wrote:
> > On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
> >> The general version of is_syscall_success does not handle 32-bit
> >> compatible case, which would cause 32-bit negative return code to be
> >> recoganized as a positive number later and seen as a "success".
> >>
> >> Since is_compat_thread is defined in compat.h, implementing
> >> is_syscall_success in ptrace.h would introduce build failure due to
> >> recursive inclusion of some basic headers like mutex.h. We put the
> >> implementation to ptrace.c
> >>
> >> Signed-off-by: He Zhe <zhe.he at windriver.com>
> >> ---
> >>  arch/arm64/include/asm/ptrace.h |  3 +++
> >>  arch/arm64/kernel/ptrace.c      | 10 ++++++++++
> >>  2 files changed, 13 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> >> index e58bca832dff..3c415e9e5d85 100644
> >> --- a/arch/arm64/include/asm/ptrace.h
> >> +++ b/arch/arm64/include/asm/ptrace.h
> >> @@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> >>  	regs->regs[0] = rc;
> >>  }
> >>  
> >> +extern inline int is_syscall_success(struct pt_regs *regs);
> >> +#define is_syscall_success(regs) is_syscall_success(regs)
> >> +
> >>  /**
> >>   * regs_get_kernel_argument() - get Nth function argument in kernel
> >>   * @regs:	pt_regs of that context
> >> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> >> index 170f42fd6101..3266201f8c60 100644
> >> --- a/arch/arm64/kernel/ptrace.c
> >> +++ b/arch/arm64/kernel/ptrace.c
> >> @@ -1909,3 +1909,13 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> >>  	else
> >>  		return valid_native_regs(regs);
> >>  }
> >> +
> >> +inline int is_syscall_success(struct pt_regs *regs)
> >> +{
> >> +	unsigned long val = regs->regs[0];
> >> +
> >> +	if (is_compat_thread(task_thread_info(current)))
> >> +		val = sign_extend64(val, 31);
> >> +
> >> +	return !IS_ERR_VALUE(val);
> >> +}
> > It's better to use compat_user_mode(regs) here instead of
> > is_compat_thread(). It saves us from worrying whether regs are for the
> > current context.
> 
> Thanks. I'll use this for v2.
> 
> >
> > I think we should change regs_return_value() instead. This function
> > seems to be called from several other places and it has the same
> > potential problems if called on compat pt_regs.
> 
> IMHO, now that we have had specific function, syscall_get_return_value, to get
> syscall return code, we might as well use it. regs_return_value may be left for
> where we want internal return code. I found such places below and haven't found
> other places that syscall sign extension is concerned about.
> 
> kernel/test_kprobes.c
> kernel/trace/trace_kprobe.c
> samples/kprobes/kretprobe_example.c

FWIW, I agree that we should use syscall_get_return_value(). If we make
the common implementation of is_syscall_success() use
syscall_get_return_value(), we shouldn't need to write our own
implementation, so I'd prefer if we could do that if possible.

IIUC regs_get_return_value() was originally meant to be used for kernel
regs, and is trying to do something quite different, so having the core
code use syscall_get_return_value() makes sense to allow architectures
to handle those cases differently.

Thanks,
Mark.


From sudeep.holla at arm.com  Wed Apr 21 18:20:56 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 21 Apr 2021 18:20:56 +0100
Subject: [PATCH 1/2] ACPI: GTDT: Don't corrupt interrupt mappings on
 watchdow probe failure
In-Reply-To: <20210421164317.1718831-2-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210421164317.1718831-2-maz@kernel.org>
Message-ID: <20210421172056.n2yoggo5epqwdhtc@bogus>

(with stable email fixed, but may need separate posting anyways)

On Wed, Apr 21, 2021 at 05:43:16PM +0100, Marc Zyngier wrote:
> When failing the driver probe because of invalid firmware properties,
> the GTDT driver unmaps the interrupt that it mapped earlier.
> 
> However, it never checks whether the mapping of the interrupt actially
> succeeded. Even more, should the firmware report an illegal interrupt
> number that overlaps with the GIC SGI range, this can result in an
> IPI being unmapped, and subsequent fireworks (as reported by Dann
> Frazier).
> 
> Rework the driver to have a slightly saner behaviour and actually
> check whether the interrupt has been mapped before unmapping things.
> 
> Reported-by: dann frazier <dann.frazier at canonical.com>
> Fixes: ca9ae5ec4ef0 ("acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver")
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> Link: https://lore.kernel.org/r/YH87dtTfwYgavusz at xps13.dannf
> Cc: stable at vgerlkernel.org
                ^^^

I thought I messed up while replying with my fat fingers, but here is the
culprit. I got mail delivery failure to my reply, thought I will let you
know as it may be difficult to notice this when using git send-email.

-- 
Regards,
Sudeep


From jejb at linux.ibm.com  Wed Apr 21 18:20:59 2021
From: jejb at linux.ibm.com (James Bottomley)
Date: Wed, 21 Apr 2021 10:20:59 -0700
Subject: [PATCH v9 1/4] KEYS: trusted: Add generic trusted keys framework
In-Reply-To: <CAFA6WYOzD-qhHrcnzvd9P7iFvEqWwf0NCKXrgrEgvnB5i_-SxQ@mail.gmail.com>
References: <20210301131127.793707-1-sumit.garg@linaro.org>
 <20210301131127.793707-2-sumit.garg@linaro.org>
 <65dcc9fa28833e6beb1eadf98b0ed3402404d693.camel@linux.ibm.com>
 <CAFA6WYOzD-qhHrcnzvd9P7iFvEqWwf0NCKXrgrEgvnB5i_-SxQ@mail.gmail.com>
Message-ID: <e7a91c8c09722afe1fb1ec3aa7b6544e713183af.camel@linux.ibm.com>

On Wed, 2021-04-21 at 16:38 +0530, Sumit Garg wrote:
> Hi James,
> 
> On Wed, 21 Apr 2021 at 04:47, James Bottomley <jejb at linux.ibm.com>
> wrote:
> > On Mon, 2021-03-01 at 18:41 +0530, Sumit Garg wrote:
> > > Current trusted keys framework is tightly coupled to use TPM
> > > device as an underlying implementation which makes it difficult
> > > for implementations like Trusted Execution Environment (TEE) etc.
> > > to provide trusted keys support in case platform doesn't posses a
> > > TPM device.
> > > 
> > > Add a generic trusted keys framework where underlying
> > > implementations can be easily plugged in. Create struct
> > > trusted_key_ops to achieve this, which contains necessary
> > > functions of a backend.
> > > 
> > > Also, define a module parameter in order to select a particular
> > > trust source in case a platform support multiple trust sources.
> > > In case its not specified then implementation itetrates through
> > > trust sources list starting with TPM and assign the first trust
> > > source as a backend which has initiazed successfully during
> > > iteration.
> > > 
> > > Note that current implementation only supports a single trust
> > > source at runtime which is either selectable at compile time or
> > > during boot via aforementioned module parameter.
> > 
> > You never actually tested this, did you?  I'm now getting EINVAL
> > from all the trusted TPM key operations because of this patch.
> > 
> 
> Unfortunately, I don't possess a development machine with a TPM
> device. So mine testing was entirely based on TEE as a backend which
> doesn't support any optional parameters. And that being the reason I
> didn't catch this issue at first instance.
> 
> Is there any TPM emulation environment available that I can use for
> testing?

Well use the same as we all use: A software TPM running in the host
coupled with a virtual machine guest for the kernel:

https://en.opensuse.org/Software_TPM_Emulator_For_QEMU

It doesn't catch interface issues (like TIS timeouts) but it does catch
TPM operations problems like this patch had.

James




From mark.rutland at arm.com  Wed Apr 21 18:41:05 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 21 Apr 2021 18:41:05 +0100
Subject: [PATCH 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210416075533.7720-2-zhe.he@windriver.com>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416075533.7720-2-zhe.he@windriver.com>
Message-ID: <20210421174105.GB52940@C02TD0UTHF1T.local>

On Fri, Apr 16, 2021 at 03:55:32PM +0800, He Zhe wrote:
> Add sign extension handling in syscall_get_return_value so that it can
> handle 32-bit compatible case and can be used by for example audit, just
> like what syscall_get_error does.

If a compat syscall can ever legitimately return a non-error value with
bit 31 set, and this sign-extends it, is that ever going to reach
userspace as a 64-bit value?

IIUC things like mmap() can return pointers above 2GiB for a compat
task, so I'm a bit uneasy that we'd handle those wrong. I can't see a
way of preventing that unless we keep the upper 32 bits for errors.

Mark.

> 
> Signed-off-by: He Zhe <zhe.he at windriver.com>
> ---
>  arch/arm64/include/asm/syscall.h | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
> index cfc0672013f6..cd7a22787aeb 100644
> --- a/arch/arm64/include/asm/syscall.h
> +++ b/arch/arm64/include/asm/syscall.h
> @@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct *task,
>  static inline long syscall_get_return_value(struct task_struct *task,
>  					    struct pt_regs *regs)
>  {
> -	return regs->regs[0];
> +	long val = regs->regs[0];
> +
> +	if (is_compat_thread(task_thread_info(task)))
> +		val = sign_extend64(val, 31);
> +
> +	return val;
>  }
>  
>  static inline void syscall_set_return_value(struct task_struct *task,
> -- 
> 2.17.1
> 


From l.stach at pengutronix.de  Wed Apr 21 18:43:18 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Wed, 21 Apr 2021 19:43:18 +0200
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
 <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>
 <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>
Message-ID: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>

Am Mittwoch, dem 21.04.2021 um 14:54 +0000 schrieb Robin Gong:
> On 20201/04/20 22:01 Lucas Stach <l.stach at pengutronix.de> wrote:
> > Am Dienstag, dem 20.04.2021 um 13:47 +0000 schrieb Robin Gong:
> > > On 2021/04/19 17:46 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > Am Montag, dem 19.04.2021 um 07:17 +0000 schrieb Robin Gong:
> > > > > Hi Lucas,
> > > > > 
> > > > > On 2021/04/14 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > > Hi Robin,
> > > > > > 
> > > > > > Am Mittwoch, dem 14.04.2021 um 14:33 +0000 schrieb Robin Gong:
> > > > > > > On 2020/05/20 17:43 Lucas Stach <l.stach at pengutronix.de> wrote:
> > > > > > > > Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu
> > Wang:
> > > > > > > > > Hi
> > > > > > > > > 
> > > > > > > > > On Tue, May 19, 2020 at 6:04 PM Lucas Stach
> > > > > > > > > <l.stach at pengutronix.de>
> > > > > > > > wrote:
> > > > > > > > > > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu
> > Wang:
> > > > > > > > > > > There are two requirements that we need to move the
> > > > > > > > > > > request of dma channel from probe to open.
> > > > > > > > > > 
> > > > > > > > > > How do you handle -EPROBE_DEFER return code from the
> > > > > > > > > > channel request if you don't do it in probe?
> > > > > > > > > 
> > > > > > > > > I use the dma_request_slave_channel or dma_request_channel
> > > > > > > > > instead of dmaengine_pcm_request_chan_of. so there should
> > > > > > > > > be not -EPROBE_DEFER return code.
> > > > > > > > 
> > > > > > > > This is a pretty weak argument. The dmaengine device might
> > > > > > > > probe after you try to get the channel. Using a function to
> > > > > > > > request the channel that doesn't allow you to handle probe
> > > > > > > > deferral is IMHO a bug and should be fixed, instead of
> > > > > > > > building even more assumptions on top
> > > > > > of it.
> > > > > > > > 
> > > > > > > > > > > - When dma device binds with power-domains, the power
> > > > > > > > > > > will be enabled when we request dma channel. If the
> > > > > > > > > > > request of dma channel happen on probe, then the
> > > > > > > > > > > power-domains will be always enabled after kernel boot
> > > > > > > > > > > up,  which is not good for power saving,  so we need
> > > > > > > > > > > to move the request of dma channel to .open();
> > > > > > > > > > 
> > > > > > > > > > This is certainly something which could be fixed in the
> > > > > > > > > > dmaengine driver.
> > > > > > > > > 
> > > > > > > > > Dma driver always call the pm_runtime_get_sync in
> > > > > > > > > device_alloc_chan_resources, the
> > > > > > > > > device_alloc_chan_resources is called when channel is
> > > > > > > > > requested. so power is enabled on channel
> > > > > > request.
> > > > > > > > 
> > > > > > > > So why can't you fix the dmaengine driver to do that RPM
> > > > > > > > call at a later time when the channel is actually going to
> > > > > > > > be used? This will allow further power savings with other
> > > > > > > > slave devices than the audio
> > > > PCM.
> > > > > > > Hi Lucas,
> > > > > > > ??Thanks for your suggestion. I have tried to implement
> > > > > > > runtime autosuspend in fsl-edma driver on i.mx8qm/qxp with
> > > > > > > delay time (2
> > > > > > > sec) for this feature as below (or you can refer to
> > > > > > > drivers/dma/qcom/hidma.c), and pm_runtime_get_sync/
> > > > > > > pm_runtime_put_autosuspend in all dmaengine driver interface
> > > > > > > like
> > > > > > > device_alloc_chan_resources/device_prep_slave_sg/device_prep_d
> > > > > > > ma_c
> > > > > > > ycli
> > > > > > > c/
> > > > > > > device_tx_status...
> > > > > > > 
> > > > > > > 
> > > > > > > ????????????????pm_runtime_use_autosuspend(fsl_chan->de
> > v);
> > > > > > > ????????????????pm_runtime_set_autosuspend_delay(fsl_cha
> > n->
> > > > dev,
> > > > > > 2000);
> > > > > > > 
> > > > > > > That could resolve this audio case since the autosuspend could
> > > > > > > suspend runtime after
> > > > > > > 2 seconds if there is no further dma transfer but only channel
> > > > > > request(device_alloc_chan_resources).
> > > > > > > But unfortunately, it cause another issue. As you know, on our
> > > > > > > i.mx8qm/qxp, power domain done by scfw
> > > > > > > (drivers/firmware/imx/scu-pd.c)
> > > > > > over mailbox:
> > > > > > > ?imx_sc_pd_power()->imx_scu_call_rpc()->
> > > > > > > imx_scu_ipc_write()->mbox_send_message()
> > > > > > > which means have to 'waits for completion', meanwhile, some
> > > > > > > driver like tty will call dmaengine interfaces in non-atomic
> > > > > > > case as below,
> > > > > > > 
> > > > > > > static int uart_write(struct tty_struct *tty, const unsigned
> > > > > > > char *buf, int count) {
> > > > > > > ???.......
> > > > > > > 	    port = uart_port_lock(state, flags);
> > > > > > > ???......
> > > > > > > ????????__uart_start(tty);  //call
> > > > start_tx()->dmaengine_prep_slave_sg...
> > > > > > > ????????uart_port_unlock(port, flags);
> > > > > > > ????????return ret;
> > > > > > > }
> > > > > > > 
> > > > > > > Thus dma runtime resume may happen in that timing window and
> > > > > > > cause
> > > > > > kernel alarm.
> > > > > > > I'm not sure whether there are similar limitations on other
> > > > > > > driver subsystem. But for me, It looks like the only way to
> > > > > > > resolve the contradiction between tty and scu-pd (hardware
> > > > > > > limitation on
> > > > > > > i.mx8qm/qxp) is to give up autosuspend and keep
> > > > > > > pm_runtime_get_sync
> > > > > > only in device_alloc_chan_resources because request channel is a
> > > > > > safe non-atomic phase.
> > > > > > > Do you have any idea? Thanks in advance.
> > > > > > 
> > > > > > If you look closely at the driver you used as an example
> > > > > > (hidma.c) it looks like there is already something in there,
> > > > > > which looks very much like what you need
> > > > > > here:
> > > > > > 
> > > > > > In hidma_issue_pending() the driver tries to get the device to
> > > > > > runtime
> > > > resume.
> > > > > > If this doesn't work, maybe due to the power domain code not
> > > > > > being able to be called in atomic context, the actual work of
> > > > > > waking up the dma hardware and issuing the descriptor is shunted to a
> > tasklet.
> > > > > > 
> > > > > > If I'm reading this right, this is exactly what you need here to
> > > > > > be able to call the dmaengine code from atomic context: try the
> > > > > > rpm get and issue immediately when possible, otherwise shunt the
> > > > > > work to a
> > > > > > non- atomic context where you can deal with the requirements of
> > scu-pd.
> > > > > Yes, I can schedule_work to worker to runtime resume edma channel
> > > > > by
> > > > calling scu-pd.
> > > > > But that means all dmaengine interfaces should be taken care, not
> > > > > only
> > > > > issue_pending() but also
> > > > > dmaengine_terminate_all()/dmaengine_pause()/dmaengine_resume()/
> > > > > dmaengine_tx_status(). Not sure why hidma only take care
> > > > > issue_pending. Maybe their user case is just for memcpy/memset so
> > > > > that no further complicate case as ALSA or TTY.
> > > > > Besides, for autosuspend in cyclic, we have to add
> > > > > pm_runtime_get_sync into interrupt handler as qcom/bam_dma.c. but
> > > > > how could resolve the scu-pd's non-atmoic limitation in interrupt
> > handler?
> > > > 
> > > > Sure, this all needs some careful analysis on how those functions
> > > > are called and what to do about atomic callers, but it should be
> > > > doable. I don't see any fundamental issues here.
> > > > 
> > > > I don't see why you would ever need to wake the hardware in an
> > > > interrupt handler. Surely the hardware is already awake, as it
> > > > wouldn't signal an interrupt otherwise. And for the issue with
> > > > scu-pd you only care about the state transition of
> > > > suspended->running. If the hardware is already running/awake, the
> > > > runtime pm state handling is nothing more than bumping a refcount,
> > > > which is atomic safe. Putting the HW in suspend is already handled
> > asynchronously in a worker, so this is also atomic safe.
> > > But with autosuspend used, in corner case, may runtime suspended
> > > before falling Into edma interrupt handler if timeout happen with the
> > > delay value of pm_runtime_set_autosuspend_delay(). Thus, can't touch
> > > any edma interrupt status register unless runtime resume edma in
> > > interrupt handler while runtime resume function based on scu-pd's power
> > domain may block or sleep.
> > > I have a simple workaround that disable runtime suspend in
> > > issue_pending worker by calling pm_runtime_forbid() and then enable
> > > runtime auto suspend in dmaengine_terminate_all so that we could
> > > easily regard that edma channel is always in runtime resume between
> > > issue_pending and channel terminated and ignore the above interrupt
> > handler/scu-pd limitation.
> > 
> > The IRQ handler is the point where you are informed by the hardware that a
> > specific operation is complete. I don't see any use-case where it would be valid
> > to drop the rpm refcount to 0 before the IRQ is handled. Surely the hardware
> > needs to stay awake until the currently queued operations are complete and if
> > the IRQ handler is the completion point the IRQ handler is the first point in
> > time where your autosuspend timer should start to run. There should never be
> > a situation where the timer expiry can get between IRQ signaling and the
> > handler code running.
> But the timer of runtime_auto_suspend decide when enter runtime suspend rather
> than hardware, while transfer data size and transfer rate on IP bus decide when the
> dma interrupt happen.?
> 
But it isn't the hardware that decides to drop the rpm refcount to 0
and starting the autosuspend timer, it's the driver.

>  Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
> pm_runtime_mark_last_busy in interrupt handler to hope the runtime_auto_suspend
> timer expiry later than interrupt coming, but if the transfer data size is larger in cyclic
> and transfer rate is very slow like 115200 or lower on uart, the fix autosuspend timer
> 100ms/200ms maybe not enough, hence, runtime suspend may execute meanwhile
> the dma interrupt maybe triggered and caught by GIC(but interrupt handler prevent
> by spin_lock_irqsave in pm_suspend_timer_fn() ), and then interrupt handler start
> to run after runtime suspend. 

If your driver code drops the rpm refcount to 0 and starts the
autosuspend timer while a cyclic transfer is still in flight this is
clearly a bug. Autosuspend is not there to paper over driver bugs, but
to amortize cost of actually suspending and resuming the hardware. Your
driver code must still work even if the timeout is 0, i.e. the hardware
is immediately suspended after you drop the rpm refcount to 0.

If you still have transfers queued/in-flight the driver code must keep
a rpm reference.

Regards,
Lucas



From broonie at kernel.org  Wed Apr 21 18:46:29 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 21 Apr 2021 18:46:29 +0100
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
References: <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
 <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>
 <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>
 <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
Message-ID: <20210421174629.GD4617@sirena.org.uk>

On Wed, Apr 21, 2021 at 07:43:18PM +0200, Lucas Stach wrote:

> If your driver code drops the rpm refcount to 0 and starts the
> autosuspend timer while a cyclic transfer is still in flight this is
> clearly a bug. Autosuspend is not there to paper over driver bugs, but
> to amortize cost of actually suspending and resuming the hardware. Your
> driver code must still work even if the timeout is 0, i.e. the hardware
> is immediately suspended after you drop the rpm refcount to 0.

> If you still have transfers queued/in-flight the driver code must keep
> a rpm reference.

Right, failing to do that is a clear bug.

Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
-------------- 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/20210421/c1e6ed30/attachment.sig>

From maz at kernel.org  Wed Apr 21 18:56:07 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 18:56:07 +0100
Subject: [PATCH 2/2] ACPI: irq: Prevent unregistering of GIC SGIs
In-Reply-To: <20210421171516.hg3ex7jqigqjqa6i@bogus>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210421164317.1718831-3-maz@kernel.org>
 <20210421171516.hg3ex7jqigqjqa6i@bogus>
Message-ID: <87tunzsers.wl-maz@kernel.org>

On Wed, 21 Apr 2021 18:15:16 +0100,
Sudeep Holla <sudeep.holla at arm.com> wrote:
> 
> On Wed, Apr 21, 2021 at 05:43:17PM +0100, Marc Zyngier wrote:
> > When using ACPI on arm64, which implies the GIC IRQ model, no
> > table should ever provide a GSI number in the range [0:15],
> > as these are reserved for IPIs.
> >
> > However, drivers tend to call acpi_unregister_gsi() with any
> > random GSI number provided by half baked tables, which results
> > in an exploding kernel when its IPIs have been unconfigured.
> >
> > In order to catch this, check for the silly case early, warn
> > that something is going wrong and avoid the above disaster.
> >
> 
> Reviewed-by: Sudeep Holla <sudeep.holla at arm.com>
> 
> Just curious if this is just precaution or do we have a platform doing
> something stupid like this ?

Without this, it could be really hard to pinpoint which driver messes
with IPIs. Having this in place would have caught the GTDT bug much
earlier (several years ago actually).

The only reason I managed to track it down in a short amount of time
is that the driver actually printed an error message before the kernel
exploded while probing a completely unrelated driver. Without this
message, I'd still be scratching my head.

The WARN_ON() would definitely point at the guilty party, and keep the
kernel running.

Thanks,

	M.

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


From maz at kernel.org  Wed Apr 21 18:57:34 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 21 Apr 2021 18:57:34 +0100
Subject: [PATCH 1/2] ACPI: GTDT: Don't corrupt interrupt mappings on
 watchdow probe failure
In-Reply-To: <20210421172056.n2yoggo5epqwdhtc@bogus>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210421164317.1718831-2-maz@kernel.org>
 <20210421172056.n2yoggo5epqwdhtc@bogus>
Message-ID: <87sg3jsepd.wl-maz@kernel.org>

On Wed, 21 Apr 2021 18:20:56 +0100,
Sudeep Holla <sudeep.holla at arm.com> wrote:
> 
> (with stable email fixed, but may need separate posting anyways)
> 
> On Wed, Apr 21, 2021 at 05:43:16PM +0100, Marc Zyngier wrote:
> > When failing the driver probe because of invalid firmware properties,
> > the GTDT driver unmaps the interrupt that it mapped earlier.
> > 
> > However, it never checks whether the mapping of the interrupt actially
> > succeeded. Even more, should the firmware report an illegal interrupt
> > number that overlaps with the GIC SGI range, this can result in an
> > IPI being unmapped, and subsequent fireworks (as reported by Dann
> > Frazier).
> > 
> > Rework the driver to have a slightly saner behaviour and actually
> > check whether the interrupt has been mapped before unmapping things.
> > 
> > Reported-by: dann frazier <dann.frazier at canonical.com>
> > Fixes: ca9ae5ec4ef0 ("acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver")
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > Link: https://lore.kernel.org/r/YH87dtTfwYgavusz at xps13.dannf
> > Cc: stable at vgerlkernel.org
>                 ^^^
> 
> I thought I messed up while replying with my fat fingers, but here is the
> culprit. I got mail delivery failure to my reply, thought I will let you
> know as it may be difficult to notice this when using git send-email.

I'm definitely the one with very fat fingers. I'll fix the patch in my
tree.

Thanks for the heads up,

	M.

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


From patchwork-bot+netdevbpf at kernel.org  Wed Apr 21 19:00:09 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 21 Apr 2021 18:00:09 +0000
Subject: [PATCH net 1/1] net: stmmac: fix TSO and TBS feature enabling
 during driver open
In-Reply-To: <20210421091149.5035-1-boon.leong.ong@intel.com>
References: <20210421091149.5035-1-boon.leong.ong@intel.com>
Message-ID: <161902800954.24373.14896291622755574691.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Wed, 21 Apr 2021 17:11:49 +0800 you wrote:
> TSO and TBS cannot co-exist and current implementation requires two
> fixes:
> 
>  1) stmmac_open() does not need to call stmmac_enable_tbs() because
>     the MAC is reset in stmmac_init_dma_engine() anyway.
>  2) Inside stmmac_hw_setup(), we should call stmmac_enable_tso() for
>     TX Q that is _not_ configured for TBS.
> 
> [...]

Here is the summary with links:
  - [net,1/1] net: stmmac: fix TSO and TBS feature enabling during driver open
    https://git.kernel.org/netdev/net/c/5e6038b88a57

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From patchwork-bot+netdevbpf at kernel.org  Wed Apr 21 19:00:09 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 21 Apr 2021 18:00:09 +0000
Subject: [PATCH net-next 1/1] stmmac: intel: set TSO/TBS TX Queues default
 settings
In-Reply-To: <20210421084606.20851-1-boon.leong.ong@intel.com>
References: <20210421084606.20851-1-boon.leong.ong@intel.com>
Message-ID: <161902800988.24373.17521808313438955421.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Wed, 21 Apr 2021 16:46:06 +0800 you wrote:
> TSO and TBS cannot coexist, for now we set Intel mGbE controller to use
> below TX Queue mapping: TxQ0 uses TSO and the rest of TXQs supports TBS.
> 
> Signed-off-by: Ong Boon Leong <boon.leong.ong at intel.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 3 +++
>  1 file changed, 3 insertions(+)

Here is the summary with links:
  - [net-next,1/1] stmmac: intel: set TSO/TBS TX Queues default settings
    https://git.kernel.org/netdev/net-next/c/17cb00704c21

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From dann.frazier at canonical.com  Wed Apr 21 19:09:44 2021
From: dann.frazier at canonical.com (dann frazier)
Date: Wed, 21 Apr 2021 12:09:44 -0600
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <YIBqaPiLCrqc9f/c@xps13.dannf>

On Wed, Apr 21, 2021 at 05:43:15PM +0100, Marc Zyngier wrote:
> Dann recently reported that his ThunderX machine failed to boot since
> 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
> interrupts"), with a not so pretty crash while trying to send an IPI.
> 
> It turned out to be caused by a mix of broken firmware and a buggy
> GTDT watchdog driver. Both have forever been buggy, but the above
> commit revealed that the error handling path of the driver was
> probably the worse part of it all.
> 
> Anyway, this short series has two goals:
> - handle broken firmware in a less broken way
> - make sure that the route cause of the problem can be identified
>   quickly
> 
> Thanks,
> 
> 	M.
> 
> Marc Zyngier (2):
>   ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
>   ACPI: irq: Prevent unregistering of GIC SGIs
> 
>  drivers/acpi/arm64/gtdt.c | 10 ++++++----
>  drivers/acpi/irq.c        |  6 +++++-
>  2 files changed, 11 insertions(+), 5 deletions(-)

For the series:

Tested-by: dann frazier <dann.frazier at canonical.com>


From elver at google.com  Wed Apr 21 19:23:43 2021
From: elver at google.com (Marco Elver)
Date: Wed, 21 Apr 2021 20:23:43 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <YIBSg7Vi+U383dT7@elver.google.com>
References: <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
 <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
 <YIBSg7Vi+U383dT7@elver.google.com>
Message-ID: <YIBtr2w/8KhOoiUA@elver.google.com>

On Wed, Apr 21, 2021 at 06:27PM +0200, Marco Elver wrote:
> On Wed, Apr 21, 2021 at 05:11PM +0200, Marco Elver wrote:
> > +Cc linux-arm-kernel
> > 
> [...]
> > >
> > > I've managed to reproduce this issue with a public Raspberry Pi OS Lite
> > > rootfs image, even without deploying kernel modules:
> > >
> > > https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-03-25/2021-03-04-raspios-buster-armhf-lite.zip
> > >
> > > # qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon
> > > console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none
> > > -monitor null -device virtio-blk-device,drive=virtio-blk -drive
> > > file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw
> > > -netdev user,id=user -device virtio-net-device,netdev=user
> > >
> > > The above one doesn't boot if zImage z compiled from commit fb6cc127e0b6
> > > and boots if compiled from 2e498d0a74e5. In both cases I've used default
> > > arm/multi_v7_defconfig and
> > > gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.
> > 
> > Yup, I've narrowed it down to the addition of "__u64 _perf" to
> > siginfo_t. My guess is the __u64 causes a different alignment for a
> > bunch of adjacent fields. It seems that x86 and m68k are the only ones
> > that have compile-time tests for the offsets. Arm should probably add
> > those -- I have added a bucket of static_assert() in
> > arch/arm/kernel/signal.c and see that something's off.
> > 
> > I'll hopefully have a fix in a day or so.
> 
> Arm and compiler folks: are there some special alignment requirement for
> __u64 on arm 32-bit? (And if there is for arm64, please shout as well.)
> 
> With the static-asserts below, the only thing that I can do to fix it is
> to completely remove the __u64. Padding it before or after with __u32
> just does not work. It seems that the use of __u64 shifts everything
> in __sifields by 4 bytes.
> 
> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> index d0bb9125c853..b02a4ac55938 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -92,7 +92,10 @@ union __sifields {
>  				__u32 _pkey;
>  			} _addr_pkey;
>  			/* used when si_code=TRAP_PERF */
> -			__u64 _perf;
> +			struct {
> +				__u32 _perf1;
> +				__u32 _perf2;
> +			} _perf;
>  		};
>  	} _sigfault;
> 
> ^^ works, but I'd hate to have to split this into 2 __u32 because it
> makes the whole design worse.
> 
> What alignment trick do we have to do here to fix it for __u64?

So I think we just have to settle on 'unsigned long' here. On many
architectures, like 32-bit Arm, the alignment of a structure is that of
its largest member. This means that there is no portable way to add
64-bit integers to siginfo_t on 32-bit architectures.

In the case of the si_perf field, word size is sufficient since the data
it contains is user-defined. On 32-bit architectures, any excess bits of
perf_event_attr::sig_data will therefore be truncated when copying into
si_perf.

Feel free to test the below if you have time, but the below lets me boot
32-bit arm which previously timed out. It also passes all the
static_asserts() I added (will send those as separate patches).

Once I'm convinced this passes all others tests too, I'll send a patch.

Thanks,
-- Marco


diff --git a/include/linux/compat.h b/include/linux/compat.h
index c8821d966812..f0d2dd35d408 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -237,7 +237,7 @@ typedef struct compat_siginfo {
 					u32 _pkey;
 				} _addr_pkey;
 				/* used when si_code=TRAP_PERF */
-				compat_u64 _perf;
+				compat_ulong_t _perf;
 			};
 		} _sigfault;
 
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index d0bb9125c853..03d6f6d2c1fe 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -92,7 +92,7 @@ union __sifields {
 				__u32 _pkey;
 			} _addr_pkey;
 			/* used when si_code=TRAP_PERF */
-			__u64 _perf;
+			unsigned long _perf;
 		};
 	} _sigfault;
 


From robh at kernel.org  Wed Apr 21 19:45:26 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 13:45:26 -0500
Subject: [PATCH 1/5] PCI: qcom: add support for IPQ60xx PCIe controller
In-Reply-To: <87r1j4kzzm.fsf@tarshish>
References: <cover.1618916235.git.baruch@tkos.co.il>
 <c6ff03d1377ea9b5ff40ab283c884aeff6254dd9.1618916235.git.baruch@tkos.co.il>
 <20210420161855.GA3402221@robh.at.kernel.org> <87r1j4kzzm.fsf@tarshish>
Message-ID: <CAL_JsqKP1hZ6UGEuevjcMC_ZLbojemZ7-X-koyaxViRHQOoN4g@mail.gmail.com>

On Tue, Apr 20, 2021 at 11:45 PM Baruch Siach <baruch at tkos.co.il> wrote:
>
> Hi Rob,
>
> Thanks for your review.
>
> I have a few comments below.
>
> On Tue, Apr 20 2021, Rob Herring wrote:
> > On Tue, Apr 20, 2021 at 02:21:36PM +0300, Baruch Siach wrote:
> >> From: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
> >>
> >> IPQ60xx series of SoCs have one port of PCIe gen 3. Add support for that
> >> platform.
> >>
> >> The code is based on downstream Codeaurora kernel v5.4. Split out the
> >> registers access part from .init into .post_init. Registers are only
> >> accessible after phy_power_on().
> >>
> >> Signed-off-by: Selvam Sathappan Periakaruppan <speriaka at codeaurora.org>
> >> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> >> ---
> >>  drivers/pci/controller/dwc/pcie-qcom.c | 279 +++++++++++++++++++++++++
> >>  1 file changed, 279 insertions(+)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> >> index 8a7a300163e5..3e27de744738 100644
> >> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> >> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> >> @@ -41,6 +41,31 @@
> >>  #define L23_CLK_RMV_DIS                             BIT(2)
> >>  #define L1_CLK_RMV_DIS                              BIT(1)
> >>
> >> +#define PCIE_ATU_CR1_OUTBOUND_6_GEN3                0xC00
> >> +#define PCIE_ATU_CR2_OUTBOUND_6_GEN3                0xC04
> >> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_6_GEN3 0xC08
> >> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_6_GEN3 0xC0C
> >> +#define PCIE_ATU_LIMIT_OUTBOUND_6_GEN3              0xC10
> >> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_6_GEN3       0xC14
> >> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_6_GEN3       0xC18
> >> +
> >> +#define PCIE_ATU_CR1_OUTBOUND_7_GEN3                0xE00
> >> +#define PCIE_ATU_CR2_OUTBOUND_7_GEN3                0xE04
> >> +#define PCIE_ATU_LOWER_BASE_OUTBOUND_7_GEN3 0xE08
> >> +#define PCIE_ATU_UPPER_BASE_OUTBOUND_7_GEN3 0xE0C
> >> +#define PCIE_ATU_LIMIT_OUTBOUND_7_GEN3              0xE10
> >> +#define PCIE_ATU_LOWER_TARGET_OUTBOUND_7_GEN3       0xE14
> >> +#define PCIE_ATU_UPPER_TARGET_OUTBOUND_7_GEN3       0xE18
> >
> > ATU registers are standard DWC registers. Plus upstream now dynamically
> > detects how many ATU regions there are.
> >
> >> +#define PCIE20_COMMAND_STATUS                       0x04
> >> +#define BUS_MASTER_EN                               0x7
> >> +#define PCIE20_DEVICE_CONTROL2_STATUS2              0x98
> >> +#define PCIE_CAP_CPL_TIMEOUT_DISABLE                0x10
> >
> > All PCI standard registers.
>
> PCIE20_COMMAND_STATUS is indeed the common PCI_COMMAND. I could not find
> anything that matches PCIE20_DEVICE_CONTROL2_STATUS2. Where should I
> look?

Looks like PCI_EXP_DEVCTL2 and PCI_EXP_DEVSTA2 to me. The register bit
looks like PCI_EXP_DEVCTL2_COMP_TMOUT_DIS. Those are extended config
registers so their offset is variable.

>
> >
> >> +#define PCIE30_GEN3_RELATED_OFF                     0x890
> >
> > Looks like a DWC port logic register. The define at a minimum goes in
> > the common code. We probably already have one. Code touching the
> > register should ideally be there too (hint: look at the other drivers).
>
> pcie-tegra194.c uses the equivalent GEN3_RELATED_OFF. So I can move the
> definition to a common header. As for the code, I don't know. The tegra
> configuration sequence involves other registers as well.

I'm sure the Tegra folks will be happy to tell you if anything breaks.

>
> [snip]
>
> >> +static int qcom_pcie_post_init_2_9_0(struct qcom_pcie *pcie)
> >> +{
> >> +    struct dw_pcie *pci = pcie->pci;
> >> +    u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> >> +    u32 val;
> >> +    int i;
> >> +
> >> +    writel(SLV_ADDR_SPACE_SZ,
> >> +            pcie->parf + PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE);
> >> +
> >> +    val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> >> +    val &= ~BIT(0);
> >
> > What's BIT(0)?
>
> I have no idea. I have no access to hardware documentation. I'm just
> porting working code from the Codeaurora tree.

Based on the 7 other existing modifications to that bit, it's 'enable
PCIe clocks and resets'. Looks like we need some refactoring at least
so there's not yet another copy.

> >> +    writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> >> +
> >> +    writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
> >> +
> >> +    writel(DEVICE_TYPE_RC, pcie->parf + PCIE20_PARF_DEVICE_TYPE);
> >> +    writel(BYPASS | MSTR_AXI_CLK_EN | AHB_CLK_EN,
> >> +            pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
> >> +    writel(RXEQ_RGRDLESS_RXTS | GEN3_ZRXDC_NONCOMPL,
> >> +            pci->dbi_base + PCIE30_GEN3_RELATED_OFF);
> >> +
> >> +    writel(MST_WAKEUP_EN | SLV_WAKEUP_EN | MSTR_ACLK_CGC_DIS
> >> +            | SLV_ACLK_CGC_DIS | CORE_CLK_CGC_DIS |
> >> +            AUX_PWR_DET | L23_CLK_RMV_DIS | L1_CLK_RMV_DIS,
> >> +            pcie->parf + PCIE20_PARF_SYS_CTRL);
> >> +
> >> +    writel(0, pcie->parf + PCIE20_PARF_Q2A_FLUSH);
> >> +
> >> +    writel(BUS_MASTER_EN, pci->dbi_base + PCIE20_COMMAND_STATUS);
> >
> > Pretty sure the DWC core or PCI core does this already.
> >
> >> +
> >> +    writel(DBI_RO_WR_EN, pci->dbi_base + PCIE20_MISC_CONTROL_1_REG);
> >> +    writel(PCIE_CAP_LINK1_VAL, pci->dbi_base + offset + PCI_EXP_SLTCAP);

I have to wonder if all the bits being set here are really true.
Hotplug is really supported? There's an attention button? Power
indicator? If anything, that's all board specific and would need to
come from firmware (DT).

> >> +
> >> +    /* Configure PCIe link capabilities for ASPM */
> >> +    val = readl(pci->dbi_base + offset + PCI_EXP_LNKCAP);
> >> +    val &= ~PCI_EXP_LNKCAP_ASPMS;
> >> +    writel(val, pci->dbi_base + offset + PCI_EXP_LNKCAP);
> >> +
> >> +    writel(PCIE_CAP_CPL_TIMEOUT_DISABLE, pci->dbi_base +
> >> +            PCIE20_DEVICE_CONTROL2_STATUS2);
> >> +
> >> +    writel(PCIE_CAP_CURR_DEEMPHASIS | SPEED_GEN3,

SPEED_GEN3 does not look right for PCI_EXP_DEVCTL2.

> >> +                    pci->dbi_base + offset + PCI_EXP_DEVCTL2);
> >
> > This all looks like stuff that should be in the DWC core code. Maybe we
> > need an ASPM disable quirk or something? That's probably somewhat
> > common.
>
> Where in common code should that be?

If these registers are initialized elsewhere, in the same place.
Otherwise, probably in dw_pcie_setup_rc().

> Which part is quirky?

Disabling ASPM. It's a bit strange that some of this is needed at all
considering no other platform using the same IP needs it.

Rob


From amanieu at gmail.com  Wed Apr 21 20:02:00 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:00 +0100
Subject: [RFC PATCH v3 1/8] mm: Add arch_get_mmap_base_topdown macro
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-2-amanieu@gmail.com>

This allows architectures to customize the mmap base to use depending on
the direction of allocation.

The base argument is also removed from arch_get_mmap_base[_topdown] in
prepartion for future changes.

arm64 is currently the only user of the arch_get_mmap_* macros and is
adjusted accordingly. Specifically it only needs to limit the upper
bound of VM allocations and therefore only needs to customize
arch_get_mmap_base_topdown but not arch_get_mmap_base.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/processor.h |  7 ++++---
 mm/mmap.c                          | 14 +++++++++-----
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index efc10e9041a0..f47528aae321 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -88,9 +88,10 @@
 #define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
 				DEFAULT_MAP_WINDOW)
 
-#define arch_get_mmap_base(addr, base) ((addr > DEFAULT_MAP_WINDOW) ? \
-					base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
-					base)
+#define arch_get_mmap_base_topdown(addr) \
+	((addr > DEFAULT_MAP_WINDOW) ? \
+	current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
+	current->mm->mmap_base)
 #endif /* CONFIG_ARM64_FORCE_52BIT */
 
 extern phys_addr_t arm64_dma_phys_limit;
diff --git a/mm/mmap.c b/mm/mmap.c
index 3f287599a7a3..4937b34085cb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2139,11 +2139,15 @@ unsigned long vm_unmapped_area(struct vm_unmapped_area_info *info)
 }
 
 #ifndef arch_get_mmap_end
-#define arch_get_mmap_end(addr)	(TASK_SIZE)
+#define arch_get_mmap_end(addr)			(TASK_SIZE)
 #endif
 
 #ifndef arch_get_mmap_base
-#define arch_get_mmap_base(addr, base) (base)
+#define arch_get_mmap_base(addr)		(current->mm->mmap_base)
+#endif
+
+#ifndef arch_get_mmap_base_topdown
+#define arch_get_mmap_base_topdown(addr)	(current->mm->mmap_base)
 #endif
 
 /* Get an address range which is currently unmapped.
@@ -2184,7 +2188,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
 	info.flags = 0;
 	info.length = len;
-	info.low_limit = mm->mmap_base;
+	info.low_limit = arch_get_mmap_base(addr);
 	info.high_limit = mmap_end;
 	info.align_mask = 0;
 	info.align_offset = 0;
@@ -2227,7 +2231,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
 	info.low_limit = max(PAGE_SIZE, mmap_min_addr);
-	info.high_limit = arch_get_mmap_base(addr, mm->mmap_base);
+	info.high_limit = arch_get_mmap_base_topdown(addr);
 	info.align_mask = 0;
 	info.align_offset = 0;
 	addr = vm_unmapped_area(&info);
@@ -2241,7 +2245,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
 	if (offset_in_page(addr)) {
 		VM_BUG_ON(addr != -ENOMEM);
 		info.flags = 0;
-		info.low_limit = TASK_UNMAPPED_BASE;
+		info.low_limit = arch_get_mmap_base(addr);
 		info.high_limit = mmap_end;
 		addr = vm_unmapped_area(&info);
 	}
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:01:59 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:01:59 +0100
Subject: [RFC PATCH v3 0/8] arm64: Allow 64-bit tasks to invoke compat syscalls
Message-ID: <20210421190207.1803139-1-amanieu@gmail.com>

This series allows AArch64 tasks to perform 32-bit syscalls by setting
the top bit of x8 and using AArch32 compat syscall numbers:

    syscall(0x80000000 | __ARM_NR_write, 1, "foo\n", 4);

Internally, setting this bit does the following:
- The remainder of x8 is treated as a compat syscall number and is used
  to index the compat syscall table.
- in_compat_syscall will return true for the duration of the syscall.
- VM allocations performed by the syscall will be located in the lower
  4G of the address space. A separate compat_mmap_base is used so that
  these allocations are still properly randomized.
- Interrupted compat syscalls are properly restarted as compat syscalls.
- Seccomp will treats the syscall as having AUDIT_ARCH_ARM instead of
  AUDIT_ARCH_AARCH64. This affects the arch value seen by seccomp
  filters and reported by SIGSYS.
- PTRACE_GET_SYSCALL_INFO also treats the syscall as having
  AUDIT_ARCH_ARM. Recent versions of strace will correctly report the
  syscall name and parameters when an AArch64 task mixes 32-bit and
  64-bit syscalls.

This feature is intended for use in software compatibility layers which
emulate a 32-bit program on AArch64. This patch has been tested on two
such emulators:
- Tango [1], which enables AArch32 binaries to run on AArch64 CPUs which
  do not have hardware support for AArch32. Tango is used to run virtual
  Android devices on AArch64 servers.
- FEX [2], an emulator for running x86 and x86_64 binaries on AArch64.
  FEX can already run many x86_64 programs including 3D games, but
  requires kernel support for running running 32-bit x86 binaries.

Both FEX and Tango have previously attempted to translate 32-bit
syscalls purely in user mode like QEMU does for its user mode
emulation. While this works for simple programs, there are many
limitations which cannot be solved without kernel support, for example:
- There are a huge number of ioctls which behave differently in 32-bit
  mode. It is impractical and error prone to manually emulate them all
  in user mode. Specifically, the kernel already has a well-tested and
  reliable compatibility layer and it makes sense to reuse this. QEMU
  supports emulating some ioctls in userspace but this still does not
  cover devices like GPUs which are needed for accelerated rendering.
- The 64-bit set_robust_list is not compatible with the 32-bit ABI. The
  compat version of set_robust_list must be used. Emulating this in user
  mode is not reliable since SIGKILL cannot be caught.
- io_uring uses iovec structures as part of its API, which have
  different sizes on 32-bit and 64-bit.
- ext4 represents positions in directories as 64-bit hashes, which break
  if they are truncated to 32 bits. There is special support for 32-bit
  off_t in the ext4 driver but this is only used when in_compat_syscall
  is true: https://bugzilla.kernel.org/show_bug.cgi?id=205957
- The io_setup syscall allocates a VM area for the AIO context and
  returns it. But there is no way to control where this context is
  allocated so it will almost always end up above the 4GB limit.
- Some ioctls will also perform VM allocations, with the same issues as
  io_setup. Search for "vm_mmap" in drivers/.
- Some file descriptors have alignment requirements which are not known
  to userspace. For example, a hugetlbfs file can only be mmaped at a
  huge page alignment but there is no way for userspace to know this
  when it needs to manually select an address below 4GB for the mapping.

All of these issues are solved in FEX and Tango by invoking compat
syscalls directly. In the case of FEX, there remain some differences
between the arm and x86 ABIs due to alignment issues, but these are few
enough to be individually handled in userspace.

There is a precedent for exposing this functionality to userspace:
x86_64 has 2 ways to invoke 32-bit syscalls. The first is to use int
0x80 with a 32-bit syscall number and the second is to use
__X32_SYSCALL_BIT with a 64-bit syscall number. As such, the generic
kernel code is already able to properly handle tasks that invoke both
32-bit and 64-bit syscalls.

[1] https://www.amanieusystems.com/
[2] https://github.com/FEX-Emu/FEX

Changelog since v2:
- Complete rewrite, based on the patch that was previously posted as:
  [PATCH v2] [RFC] arm64: Exposes support for 32-bit syscalls

Amanieu d'Antras (8):
  mm: Add arch_get_mmap_base_topdown macro
  hugetlbfs: Use arch_get_mmap_* macros
  mm: Support mmap_compat_base with the generic layout
  arm64: Separate in_compat_syscall from is_compat_task
  arm64: mm: Use HAVE_ARCH_COMPAT_MMAP_BASES
  arm64: Add a compat syscall flag to thread_info
  arm64: Forbid calling compat sigreturn from 64-bit tasks
  arm64: Allow 64-bit tasks to invoke compat syscalls

 arch/arm64/Kconfig                   |  1 +
 arch/arm64/include/asm/compat.h      | 25 ++++++++++++---
 arch/arm64/include/asm/elf.h         | 21 ++++++++++---
 arch/arm64/include/asm/ftrace.h      |  2 +-
 arch/arm64/include/asm/processor.h   | 32 +++++++++++--------
 arch/arm64/include/asm/syscall.h     |  6 ++--
 arch/arm64/include/asm/thread_info.h |  3 ++
 arch/arm64/include/uapi/asm/unistd.h |  2 ++
 arch/arm64/kernel/ptrace.c           |  2 +-
 arch/arm64/kernel/signal.c           |  5 +++
 arch/arm64/kernel/signal32.c         |  8 +++++
 arch/arm64/kernel/syscall.c          | 23 ++++++++++++--
 arch/arm64/mm/mmap.c                 | 33 ++++++++++++++++++++
 fs/hugetlbfs/inode.c                 | 22 ++++++++++---
 mm/mmap.c                            | 14 ++++++---
 mm/util.c                            | 46 +++++++++++++++++++++++-----
 16 files changed, 200 insertions(+), 45 deletions(-)

-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:01 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:01 +0100
Subject: [RFC PATCH v3 2/8] hugetlbfs: Use arch_get_mmap_* macros
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-3-amanieu@gmail.com>

hugetlb_get_unmapped_area should obey the same arch-specific constraints
as mmap when selecting an address.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 fs/hugetlbfs/inode.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 701c82c36138..526ccb524329 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -191,6 +191,18 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
  */
 
 #ifndef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
+#ifndef arch_get_mmap_end
+#define arch_get_mmap_end(addr)			(TASK_SIZE)
+#endif
+
+#ifndef arch_get_mmap_base
+#define arch_get_mmap_base(addr)		(current->mm->mmap_base)
+#endif
+
+#ifndef arch_get_mmap_base_topdown
+#define arch_get_mmap_base_topdown(addr)	(current->mm->mmap_base)
+#endif
+
 static unsigned long
 hugetlb_get_unmapped_area_bottomup(struct file *file, unsigned long addr,
 		unsigned long len, unsigned long pgoff, unsigned long flags)
@@ -200,8 +212,8 @@ hugetlb_get_unmapped_area_bottomup(struct file *file, unsigned long addr,
 
 	info.flags = 0;
 	info.length = len;
-	info.low_limit = current->mm->mmap_base;
-	info.high_limit = TASK_SIZE;
+	info.low_limit = arch_get_mmap_base(addr);
+	info.high_limit = arch_get_mmap_end(addr);
 	info.align_mask = PAGE_MASK & ~huge_page_mask(h);
 	info.align_offset = 0;
 	return vm_unmapped_area(&info);
@@ -217,7 +229,7 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr,
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
 	info.low_limit = max(PAGE_SIZE, mmap_min_addr);
-	info.high_limit = current->mm->mmap_base;
+	info.high_limit = arch_get_mmap_base_topdown(addr);
 	info.align_mask = PAGE_MASK & ~huge_page_mask(h);
 	info.align_offset = 0;
 	addr = vm_unmapped_area(&info);
@@ -231,8 +243,8 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr,
 	if (unlikely(offset_in_page(addr))) {
 		VM_BUG_ON(addr != -ENOMEM);
 		info.flags = 0;
-		info.low_limit = current->mm->mmap_base;
-		info.high_limit = TASK_SIZE;
+		info.low_limit = arch_get_mmap_base(addr);
+		info.high_limit = arch_get_mmap_end(addr);
 		addr = vm_unmapped_area(&info);
 	}
 
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:03 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:03 +0100
Subject: [RFC PATCH v3 4/8] arm64: Separate in_compat_syscall from
 is_compat_task
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-5-amanieu@gmail.com>

This is preliminary work for allowing 64-bit processes to invoke compat
syscalls.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/compat.h  | 24 ++++++++++++++++++++----
 arch/arm64/include/asm/ftrace.h  |  2 +-
 arch/arm64/include/asm/syscall.h |  6 +++---
 arch/arm64/kernel/ptrace.c       |  2 +-
 arch/arm64/kernel/syscall.c      |  2 +-
 5 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 23a9fb73c04f..a2f5001f7793 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -178,21 +178,37 @@ struct compat_shmid64_ds {
 	compat_ulong_t __unused5;
 };
 
-static inline int is_compat_task(void)
+static inline bool is_compat_task(void)
 {
 	return test_thread_flag(TIF_32BIT);
 }
 
-static inline int is_compat_thread(struct thread_info *thread)
+static inline bool is_compat_thread(struct thread_info *thread)
 {
 	return test_ti_thread_flag(thread, TIF_32BIT);
 }
 
+static inline bool in_compat_syscall(void)
+{
+	return is_compat_task();
+}
+#define in_compat_syscall in_compat_syscall	/* override the generic impl */
+
+static inline bool thread_in_compat_syscall(struct thread_info *thread)
+{
+	return is_compat_thread(thread);
+}
+
 #else /* !CONFIG_COMPAT */
 
-static inline int is_compat_thread(struct thread_info *thread)
+static inline bool is_compat_thread(struct thread_info *thread)
+{
+	return false;
+}
+
+static inline bool thread_in_compat_syscall(struct thread_info *thread)
 {
-	return 0;
+	return false;
 }
 
 #endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 91fa4baa1a93..f41aad92c67a 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -88,7 +88,7 @@ int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec);
 #define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
 static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
 {
-	return is_compat_task();
+	return in_compat_syscall();
 }
 
 #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index cfc0672013f6..0dfc01ea386c 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -35,7 +35,7 @@ static inline long syscall_get_error(struct task_struct *task,
 {
 	unsigned long error = regs->regs[0];
 
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		error = sign_extend64(error, 31);
 
 	return IS_ERR_VALUE(error) ? error : 0;
@@ -54,7 +54,7 @@ static inline void syscall_set_return_value(struct task_struct *task,
 	if (error)
 		val = error;
 
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		val = lower_32_bits(val);
 
 	regs->regs[0] = val;
@@ -88,7 +88,7 @@ static inline void syscall_set_arguments(struct task_struct *task,
  */
 static inline int syscall_get_arch(struct task_struct *task)
 {
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		return AUDIT_ARCH_ARM;
 
 	return AUDIT_ARCH_AARCH64;
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 170f42fd6101..017a82b24f49 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1721,7 +1721,7 @@ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 	 * 32-bit children use an extended user_aarch32_ptrace_view to allow
 	 * access to the TLS register.
 	 */
-	if (is_compat_task())
+	if (in_compat_syscall())
 		return &user_aarch32_view;
 	else if (is_compat_thread(task_thread_info(task)))
 		return &user_aarch32_ptrace_view;
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index b9cf12b271d7..e0e9d54de0a2 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -51,7 +51,7 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
 		ret = do_ni_syscall(regs, scno);
 	}
 
-	if (is_compat_task())
+	if (in_compat_syscall())
 		ret = lower_32_bits(ret);
 
 	regs->regs[0] = ret;
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:02 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:02 +0100
Subject: [RFC PATCH v3 3/8] mm: Support mmap_compat_base with the generic
 layout
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-4-amanieu@gmail.com>

This enables architectures using the generic mmap layout to support
32-bit mmap calls from 64-bit processes and vice-versa.

Architectures using this must define separate 32-bit and 64-bit versions
of STACK_TOP, TASK_UNMAPPED_BASE and STACK_RND_MASK.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 mm/util.c | 46 ++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/mm/util.c b/mm/util.c
index 54870226cea6..37bd764174b5 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -353,12 +353,12 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 	return randomize_page(mm->brk, SZ_1G);
 }
 
-unsigned long arch_mmap_rnd(void)
+static unsigned long mmap_rnd(bool compat)
 {
 	unsigned long rnd;
 
 #ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
-	if (is_compat_task())
+	if (compat)
 		rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
 	else
 #endif /* CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS */
@@ -367,6 +367,11 @@ unsigned long arch_mmap_rnd(void)
 	return rnd << PAGE_SHIFT;
 }
 
+unsigned long arch_mmap_rnd(void)
+{
+	return mmap_rnd(is_compat_task());
+}
+
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
 	if (current->personality & ADDR_COMPAT_LAYOUT)
@@ -383,16 +388,17 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
  * the face of randomisation.
  */
 #define MIN_GAP		(SZ_128M)
-#define MAX_GAP		(STACK_TOP / 6 * 5)
+#define MAX_GAP		(stack_top / 6 * 5)
 
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
+static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack,
+	unsigned long stack_top, unsigned long stack_rnd_mask)
 {
 	unsigned long gap = rlim_stack->rlim_cur;
 	unsigned long pad = stack_guard_gap;
 
 	/* Account for stack randomization if necessary */
 	if (current->flags & PF_RANDOMIZE)
-		pad += (STACK_RND_MASK << PAGE_SHIFT);
+		pad += (stack_rnd_mask << PAGE_SHIFT);
 
 	/* Values close to RLIM_INFINITY can overflow. */
 	if (gap + pad > gap)
@@ -403,21 +409,45 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 	else if (gap > MAX_GAP)
 		gap = MAX_GAP;
 
-	return PAGE_ALIGN(STACK_TOP - gap - rnd);
+	return PAGE_ALIGN(stack_top - gap - rnd);
 }
 
 void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
 {
 	unsigned long random_factor = 0UL;
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+	unsigned long compat_random_factor = 0UL;
+#endif
 
-	if (current->flags & PF_RANDOMIZE)
+	if (current->flags & PF_RANDOMIZE) {
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		random_factor = mmap_rnd(false);
+		compat_random_factor = mmap_rnd(true);
+#else
 		random_factor = arch_mmap_rnd();
+#endif
+	}
 
 	if (mmap_is_legacy(rlim_stack)) {
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		mm->mmap_base = TASK_UNMAPPED_BASE_64 + random_factor;
+		mm->mmap_compat_base =
+			TASK_UNMAPPED_BASE_32 + compat_random_factor;
+#else
 		mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
+#endif
 		mm->get_unmapped_area = arch_get_unmapped_area;
 	} else {
-		mm->mmap_base = mmap_base(random_factor, rlim_stack);
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		mm->mmap_base = mmap_base(random_factor, rlim_stack,
+					  STACK_TOP_64, STACK_RND_MASK_64);
+		mm->mmap_compat_base = mmap_base(compat_random_factor,
+						 rlim_stack, STACK_TOP_32,
+						 STACK_RND_MASK_32);
+#else
+		mm->mmap_base = mmap_base(random_factor, rlim_stack, STACK_TOP,
+					  STACK_RND_MASK);
+#endif
 		mm->get_unmapped_area = arch_get_unmapped_area_topdown;
 	}
 }
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:04 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:04 +0100
Subject: [RFC PATCH v3 5/8] arm64: mm: Use HAVE_ARCH_COMPAT_MMAP_BASES
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-6-amanieu@gmail.com>

This patch switches arm64 to use separate mmap_base for 32-bit and
64-bit mmaps. This is needed to ensure that compat syscalls
invoked by 64-bit tasks perform VM allocations in the low 4G of the
address space.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/Kconfig                 |  1 +
 arch/arm64/include/asm/elf.h       |  8 +++++---
 arch/arm64/include/asm/processor.h | 33 ++++++++++++++++++------------
 arch/arm64/mm/mmap.c               | 33 ++++++++++++++++++++++++++++++
 4 files changed, 59 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dfdc3e0af5e1..d57b7bcbd758 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -133,6 +133,7 @@ config ARM64
 	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
+	select HAVE_ARCH_COMPAT_MMAP_BASES if COMPAT
 	select HAVE_ARCH_COMPILER_H
 	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 8d1c8dcb87fd..e21964898d06 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -187,12 +187,14 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 				       int uses_interp);
 
 /* 1GB of VA */
+#define STACK_RND_MASK_64		(0x3ffff >> (PAGE_SHIFT - 12))
 #ifdef CONFIG_COMPAT
+#define STACK_RND_MASK_32		(0x7ff >> (PAGE_SHIFT - 12))
 #define STACK_RND_MASK			(test_thread_flag(TIF_32BIT) ? \
-						0x7ff >> (PAGE_SHIFT - 12) : \
-						0x3ffff >> (PAGE_SHIFT - 12))
+						STACK_RND_MASK_32 : \
+						STACK_RND_MASK_64)
 #else
-#define STACK_RND_MASK			(0x3ffff >> (PAGE_SHIFT - 12))
+#define STACK_RND_MASK			STACK_RND_MASK_64
 #endif
 
 #ifdef __AARCH64EB__
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index f47528aae321..f8309f8d0ece 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -70,29 +70,36 @@
 
 #ifdef CONFIG_ARM64_FORCE_52BIT
 #define STACK_TOP_MAX		TASK_SIZE_64
-#define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
+#define TASK_UNMAPPED_BASE_64	(PAGE_ALIGN(TASK_SIZE_64 / 4))
 #else
 #define STACK_TOP_MAX		DEFAULT_MAP_WINDOW_64
-#define TASK_UNMAPPED_BASE	(PAGE_ALIGN(DEFAULT_MAP_WINDOW / 4))
+#define TASK_UNMAPPED_BASE_64	(PAGE_ALIGN(DEFAULT_MAP_WINDOW_64 / 4))
 #endif /* CONFIG_ARM64_FORCE_52BIT */
 
+#ifdef CONFIG_COMPAT
+#define TASK_UNMAPPED_BASE_32	(PAGE_ALIGN(TASK_SIZE_32 / 4))
+#define TASK_UNMAPPED_BASE	(test_thread_flag(TIF_32BIT) ? \
+				TASK_UNMAPPED_BASE_32 : TASK_UNMAPPED_BASE_64)
+#else
+#define TASK_UNMAPPED_BASE	TASK_UNMAPPED_BASE_64
+#endif /* CONFIG_COMPAT */
+
+#define STACK_TOP_64		STACK_TOP_MAX
 #ifdef CONFIG_COMPAT
 #define AARCH32_VECTORS_BASE	0xffff0000
+#define STACK_TOP_32		AARCH32_VECTORS_BASE
 #define STACK_TOP		(test_thread_flag(TIF_32BIT) ? \
-				AARCH32_VECTORS_BASE : STACK_TOP_MAX)
+				STACK_TOP_32 : STACK_TOP_64)
 #else
-#define STACK_TOP		STACK_TOP_MAX
+#define STACK_TOP		STACK_TOP_64
 #endif /* CONFIG_COMPAT */
 
-#ifndef CONFIG_ARM64_FORCE_52BIT
-#define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
-				DEFAULT_MAP_WINDOW)
-
-#define arch_get_mmap_base_topdown(addr) \
-	((addr > DEFAULT_MAP_WINDOW) ? \
-	current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
-	current->mm->mmap_base)
-#endif /* CONFIG_ARM64_FORCE_52BIT */
+#define arch_get_mmap_end arch_get_mmap_end
+#define arch_get_mmap_base arch_get_mmap_base
+#define arch_get_mmap_base_topdown arch_get_mmap_base_topdown
+unsigned long arch_get_mmap_end(unsigned long addr);
+unsigned long arch_get_mmap_base(unsigned long addr);
+unsigned long arch_get_mmap_base_topdown(unsigned long addr);
 
 extern phys_addr_t arm64_dma_phys_limit;
 #define ARCH_LOW_ADDRESS_LIMIT	(arm64_dma_phys_limit - 1)
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index a38f54cd638c..956cab3ade11 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -38,3 +38,36 @@ int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
 {
 	return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);
 }
+
+unsigned long arch_get_mmap_end(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return TASK_SIZE_32;
+#endif /* CONFIG_COMPAT */
+#ifndef CONFIG_ARM64_FORCE_52BIT
+	if (addr > DEFAULT_MAP_WINDOW_64)
+		return TASK_SIZE_64;
+#endif /* CONFIG_ARM64_FORCE_52BIT */
+	return DEFAULT_MAP_WINDOW_64;
+}
+unsigned long arch_get_mmap_base(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return current->mm->mmap_compat_base;
+#endif /* CONFIG_COMPAT */
+	return current->mm->mmap_base;
+}
+unsigned long arch_get_mmap_base_topdown(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return current->mm->mmap_compat_base;
+#endif /* CONFIG_COMPAT */
+#ifndef CONFIG_ARM64_FORCE_52BIT
+	if (addr > DEFAULT_MAP_WINDOW_64)
+		return current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW_64;
+#endif /* CONFIG_ARM64_FORCE_52BIT */
+	return current->mm->mmap_base;
+}
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:05 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:05 +0100
Subject: [RFC PATCH v3 6/8] arm64: Add a compat syscall flag to thread_info
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-7-amanieu@gmail.com>

This flag is used by in_compat_syscall to handle compat syscalls coming
from 64-bit tasks.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/compat.h      |  5 +++--
 arch/arm64/include/asm/elf.h         | 13 ++++++++++++-
 arch/arm64/include/asm/thread_info.h |  3 +++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index a2f5001f7793..71de0ba8b160 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -190,13 +190,14 @@ static inline bool is_compat_thread(struct thread_info *thread)
 
 static inline bool in_compat_syscall(void)
 {
-	return is_compat_task();
+	return is_compat_task() ||
+		current_thread_info()->aarch64_compat_syscall;
 }
 #define in_compat_syscall in_compat_syscall	/* override the generic impl */
 
 static inline bool thread_in_compat_syscall(struct thread_info *thread)
 {
-	return is_compat_thread(thread);
+	return is_compat_thread(thread) || thread->aarch64_compat_syscall;
 }
 
 #else /* !CONFIG_COMPAT */
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index e21964898d06..f4f4ffe37ee5 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -158,10 +158,20 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 #define ELF_PLAT_INIT(_r, load_addr)	(_r)->regs[0] = 0
 
+#ifdef CONFIG_COMPAT
+#define CLEAR_AARCH64_COMPAT_SYSCALL()				\
+({								\
+	current_thread_info()->aarch64_compat_syscall = false;	\
+})
+#else
+#define CLEAR_AARCH64_COMPAT_SYSCALL()	((void)0)
+#endif
+
 #define SET_PERSONALITY(ex)						\
 ({									\
 	clear_thread_flag(TIF_32BIT);					\
 	current->personality &= ~READ_IMPLIES_EXEC;			\
+	CLEAR_AARCH64_COMPAT_SYSCALL();					\
 })
 
 /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
@@ -228,7 +238,8 @@ typedef compat_elf_greg_t		compat_elf_gregset_t[COMPAT_ELF_NGREG];
 #define COMPAT_SET_PERSONALITY(ex)					\
 ({									\
 	set_thread_flag(TIF_32BIT);					\
- })
+	CLEAR_AARCH64_COMPAT_SYSCALL();					\
+})
 #ifdef CONFIG_COMPAT_VDSO
 #define COMPAT_ARCH_DLINFO						\
 do {									\
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 6623c99f0984..756e977fc37a 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -42,6 +42,9 @@ struct thread_info {
 	void			*scs_base;
 	void			*scs_sp;
 #endif
+#ifdef CONFIG_COMPAT
+	bool			aarch64_compat_syscall;
+#endif
 };
 
 #define thread_saved_pc(tsk)	\
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:06 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:06 +0100
Subject: [RFC PATCH v3 7/8] arm64: Forbid calling compat sigreturn from 64-bit
 tasks
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-8-amanieu@gmail.com>

It's impossible for this syscall to do anything sensible in this
context.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/kernel/signal32.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 2f507f565c48..e2bdd1eaefd8 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -237,6 +237,10 @@ COMPAT_SYSCALL_DEFINE0(sigreturn)
 	/* Always make any pending restarted system calls return -EINTR */
 	current->restart_block.fn = do_no_restart_syscall;
 
+	/* Reject attempts to call this from a 64-bit process. */
+	if (!is_compat_task())
+		goto badframe;
+
 	/*
 	 * Since we stacked the signal on a 64-bit boundary,
 	 * then 'sp' should be word aligned here.  If it's
@@ -268,6 +272,10 @@ COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 	/* Always make any pending restarted system calls return -EINTR */
 	current->restart_block.fn = do_no_restart_syscall;
 
+	/* Reject attempts to call this from a 64-bit process. */
+	if (!is_compat_task())
+		goto badframe;
+
 	/*
 	 * Since we stacked the signal on a 64-bit boundary,
 	 * then 'sp' should be word aligned here.  If it's
-- 
2.31.1



From amanieu at gmail.com  Wed Apr 21 20:02:07 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Wed, 21 Apr 2021 20:02:07 +0100
Subject: [RFC PATCH v3 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls
In-Reply-To: <20210421190207.1803139-1-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
Message-ID: <20210421190207.1803139-9-amanieu@gmail.com>

Setting bit 31 in x8 when performing a syscall will do the following:
- The remainder of x8 is treated as a compat syscall number and is used
  to index the compat syscall table.
- in_compat_syscall will return true for the duration of the syscall.
- VM allocations performed by the syscall will be located in the lower
  4G of the address space.
- Interrupted syscalls are properly restarted as compat syscalls.
- Seccomp will treats the syscall as having AUDIT_ARCH_ARM instead of
  AUDIT_ARCH_AARCH64. This affects the arch value seen by seccomp
  filters and reported by SIGSYS.
- PTRACE_GET_SYSCALL_INFO also treats the syscall as having
  AUDIT_ARCH_ARM. Recent versions of strace will correctly report the
  system call name and parameters when an AArch64 task mixes 32-bit and
  64-bit syscalls.

Previously, setting bit 31 of the syscall number would always cause the
sygscall to return ENOSYS. This allows user programs to reliably detect
kernel support for compat syscall by trying a simple syscall such as
getpid.

The AArch32-private compat syscalls (__ARM_NR_compat_*) are not exposed
through this interface. These syscalls do not make sense in the context
of an AArch64 task.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/uapi/asm/unistd.h |  2 ++
 arch/arm64/kernel/signal.c           |  5 +++++
 arch/arm64/kernel/syscall.c          | 21 ++++++++++++++++++++-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h
index f83a70e07df8..5574bc6ab0a3 100644
--- a/arch/arm64/include/uapi/asm/unistd.h
+++ b/arch/arm64/include/uapi/asm/unistd.h
@@ -15,6 +15,8 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#define __ARM64_COMPAT_SYSCALL_BIT 0x80000000
+
 #define __ARCH_WANT_RENAMEAT
 #define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SET_GET_RLIMIT
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 6237486ff6bb..e02f62bc1580 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -795,6 +795,11 @@ static void setup_restart_syscall(struct pt_regs *regs)
 {
 	if (is_compat_task())
 		compat_setup_restart_syscall(regs);
+#ifdef COMPAT
+	else if (current_thread_info()->aarch64_compat_syscall)
+		regs->regs[8] = __ARM64_COMPAT_SYSCALL_BIT |
+				__NR_compat_restart_syscall;
+#endif
 	else
 		regs->regs[8] = __NR_restart_syscall;
 }
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index e0e9d54de0a2..6e930d47900f 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -118,6 +118,11 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
 		 * user-issued syscall(-1). However, requesting a skip and not
 		 * setting the return value is unlikely to do anything sensible
 		 * anyway.
+		 *
+		 * This edge case goes away with CONFIG_COMPAT since a
+		 * user-issued syscall(-1) is interpreted as a
+		 * compat_syscall(0x7fffffff) which still ends up returning
+		 * -ENOSYS in x0.
 		 */
 		if (scno == NO_SYSCALL)
 			regs->regs[0] = -ENOSYS;
@@ -165,7 +170,21 @@ static inline void sve_user_discard(void)
 void do_el0_svc(struct pt_regs *regs)
 {
 	sve_user_discard();
-	el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
+
+#ifdef CONFIG_COMPAT
+	/*
+	 * Setting bit 31 of x8 allows a 64-bit processe to perform compat
+	 * syscalls.
+	 */
+	if (regs->regs[8] & __ARM64_COMPAT_SYSCALL_BIT) {
+		current_thread_info()->aarch64_compat_syscall = true;
+		el0_svc_common(regs,
+			       regs->regs[8] & ~__ARM64_COMPAT_SYSCALL_BIT,
+			       __NR_compat_syscalls, compat_sys_call_table);
+		current_thread_info()->aarch64_compat_syscall = false;
+	} else
+#endif
+		el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
 }
 
 #ifdef CONFIG_COMPAT
-- 
2.31.1



From lkp at intel.com  Wed Apr 21 20:44:44 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 03:44:44 +0800
Subject: [xlnx:master 11230/12130]
 drivers/remoteproc/ti_k3_r5_remoteproc.c:627:14: error: incompatible
 function pointer types initializing 'void *(*)(struct rproc *, u64, int)'
 (aka 'void *(*)(struct rproc *, unsigned long long, int)') with an
 expression of type 'void *(struct rproc *, u6...
Message-ID: <202104220338.9GORhAok-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: a324889a971b8e827c53deaffe630b420bde4067 [11230/12130] remoteproc: Add support for peek from remote and acking kick from remote
config: arm64-randconfig-r022-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/a324889a971b8e827c53deaffe630b420bde4067
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout a324889a971b8e827c53deaffe630b420bde4067
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/remoteproc/ti_k3_r5_remoteproc.c:627:14: error: incompatible function pointer types initializing 'void *(*)(struct rproc *, u64, int)' (aka 'void *(*)(struct rproc *, unsigned long long, int)') with an expression of type 'void *(struct rproc *, u64, size_t)' (aka 'void *(struct rproc *, unsigned long long, unsigned long)') [-Werror,-Wincompatible-function-pointer-types]
           .da_to_va       = k3_r5_rproc_da_to_va,
                             ^~~~~~~~~~~~~~~~~~~~
   1 error generated.


vim +627 drivers/remoteproc/ti_k3_r5_remoteproc.c

6dedbd1d544389 Suman Anna 2020-10-02  620  
6dedbd1d544389 Suman Anna 2020-10-02  621  static const struct rproc_ops k3_r5_rproc_ops = {
6dedbd1d544389 Suman Anna 2020-10-02  622  	.prepare	= k3_r5_rproc_prepare,
6dedbd1d544389 Suman Anna 2020-10-02  623  	.unprepare	= k3_r5_rproc_unprepare,
6dedbd1d544389 Suman Anna 2020-10-02  624  	.start		= k3_r5_rproc_start,
6dedbd1d544389 Suman Anna 2020-10-02  625  	.stop		= k3_r5_rproc_stop,
6dedbd1d544389 Suman Anna 2020-10-02  626  	.kick		= k3_r5_rproc_kick,
6dedbd1d544389 Suman Anna 2020-10-02 @627  	.da_to_va	= k3_r5_rproc_da_to_va,
6dedbd1d544389 Suman Anna 2020-10-02  628  };
6dedbd1d544389 Suman Anna 2020-10-02  629  

:::::: The code at line 627 was first introduced by commit
:::::: 6dedbd1d544389d6ab1727423348572a11e9df5d remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem

:::::: TO: Suman Anna <s-anna at ti.com>
:::::: CC: Bjorn Andersson <bjorn.andersson at linaro.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32914 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/ec3e2faf/attachment-0001.gz>

From lkp at intel.com  Wed Apr 21 20:55:57 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 03:55:57 +0800
Subject: [xlnx:master 11230/12130] drivers/remoteproc/st_slim_rproc.c:203:20:
 error: initialization of 'void * (*)(struct rproc *, u64,
 int)' {aka 'void
 * (*)(struct rproc *, long long unsigned int,  int)'} from incompatible
 pointer type 'void * (*)(struct rproc *, u64,  size_t)' {aka 'vo...
Message-ID: <202104220344.4yJKjKRa-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: a324889a971b8e827c53deaffe630b420bde4067 [11230/12130] remoteproc: Add support for peek from remote and acking kick from remote
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/a324889a971b8e827c53deaffe630b420bde4067
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout a324889a971b8e827c53deaffe630b420bde4067
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/remoteproc/st_slim_rproc.c:203:20: error: initialization of 'void * (*)(struct rproc *, u64,  int)' {aka 'void * (*)(struct rproc *, long long unsigned int,  int)'} from incompatible pointer type 'void * (*)(struct rproc *, u64,  size_t)' {aka 'void * (*)(struct rproc *, long long unsigned int,  unsigned int)'} [-Werror=incompatible-pointer-types]
     203 |  .da_to_va       = slim_rproc_da_to_va,
         |                    ^~~~~~~~~~~~~~~~~~~
   drivers/remoteproc/st_slim_rproc.c:203:20: note: (near initialization for 'slim_rproc_ops.da_to_va')
   cc1: some warnings being treated as errors


vim +203 drivers/remoteproc/st_slim_rproc.c

bb6869b2147817 Peter Griffin   2016-10-18  199  
0f21f9cc9d8687 Bjorn Andersson 2018-01-05  200  static const struct rproc_ops slim_rproc_ops = {
0f21f9cc9d8687 Bjorn Andersson 2018-01-05  201  	.start		= slim_rproc_start,
0f21f9cc9d8687 Bjorn Andersson 2018-01-05  202  	.stop		= slim_rproc_stop,
0f21f9cc9d8687 Bjorn Andersson 2018-01-05 @203  	.da_to_va       = slim_rproc_da_to_va,
0f21f9cc9d8687 Bjorn Andersson 2018-01-05  204  	.get_boot_addr	= rproc_elf_get_boot_addr,
0f21f9cc9d8687 Bjorn Andersson 2018-01-05  205  	.load		= rproc_elf_load_segments,
e29ff72b779426 Clement Leger   2020-04-22  206  	.sanity_check	= rproc_elf_sanity_check,
bb6869b2147817 Peter Griffin   2016-10-18  207  };
bb6869b2147817 Peter Griffin   2016-10-18  208  

:::::: The code at line 203 was first introduced by commit
:::::: 0f21f9cc9d868784c7564edc0cfeddd25ca9621a remoteproc: Merge rproc_ops and rproc_fw_ops

:::::: TO: Bjorn Andersson <bjorn.andersson at linaro.org>
:::::: CC: Bjorn Andersson <bjorn.andersson at linaro.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 53822 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/bf8ee2fb/attachment-0001.gz>

From tjoseph at cadence.com  Wed Apr 21 21:15:20 2021
From: tjoseph at cadence.com (Tom Joseph)
Date: Wed, 21 Apr 2021 20:15:20 +0000
Subject: [PATCH v5 5/7] PCI: cadence: Add support to configure virtual
 functions
In-Reply-To: <20210419083401.31628-6-kishon@ti.com>
References: <20210419083401.31628-1-kishon@ti.com>
 <20210419083401.31628-6-kishon@ti.com>
Message-ID: <MN2PR07MB6208290615344DF297E2E277A1479@MN2PR07MB6208.namprd07.prod.outlook.com>

> -----Original Message-----
> From: Kishon Vijay Abraham I <kishon at ti.com>
> Sent: 19 April 2021 09:34
> Subject: [PATCH v5 5/7] PCI: cadence: Add support to configure virtual
> functions
> 
> Now that support for SR-IOV is added in PCIe endpoint core, add support
> to configure virtual functions in the Cadence PCIe EP driver.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  .../pci/controller/cadence/pcie-cadence-ep.c  | 241 +++++++++++++++---
>  drivers/pci/controller/cadence/pcie-cadence.h |   7 +
>  2 files changed, 217 insertions(+), 31 deletions(-)
> 
Acked-by: Tom Joseph <tjoseph at cadence.com>


From lkp at intel.com  Wed Apr 21 21:33:30 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 04:33:30 +0800
Subject: [xlnx:master 11923/12130] drivers/mtd/spi-nor/core.c:454:2: warning:
 ISO C90 forbids mixed declarations and code
Message-ID: <202104220426.62lxJ2pl-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: 26d248f9f56a753db263a6adde4a04f0c6265374 [11923/12130] mtd: spi-nor: Added EAR support for Zynq qspi driver
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/26d248f9f56a753db263a6adde4a04f0c6265374
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 26d248f9f56a753db263a6adde4a04f0c6265374
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/mtd/spi-nor/core.c: In function 'spi_nor_write_ear':
>> drivers/mtd/spi-nor/core.c:454:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
     454 |  u32 ear;
         |  ^~~


vim +454 drivers/mtd/spi-nor/core.c

   443	
   444	/**
   445	 * spi_nor_write_ear() - Write Extended Address Register.
   446	 * @nor:	pointer to 'struct spi_nor'.
   447	 * @ear:	value to write to the Extended Address Register.
   448	 *
   449	 * Return: 0 on success, -errno otherwise.
   450	 */
   451	int spi_nor_write_ear(struct spi_nor *nor, u32 addr)
   452	{
   453		u8 code = SPINOR_OP_WREAR;;
 > 454		u32 ear;
   455		int ret;
   456		struct mtd_info *mtd = &nor->mtd;
   457	
   458		/* Wait until finished previous write command. */
   459		if (spi_nor_wait_till_ready(nor))
   460			return 1;
   461	
   462		if (mtd->size <= (0x1000000) << nor->shift)
   463			return 0;
   464	
   465		addr = addr % (u32)mtd->size;
   466		ear = addr >> 24;
   467	
   468		if (!nor->isstacked && ear == nor->curbank)
   469			return 0;
   470	
   471		if (nor->isstacked && mtd->size <= 0x2000000)
   472			return 0;
   473	
   474		if (nor->jedec_id == CFI_MFR_AMD)
   475			code = SPINOR_OP_BRWR;
   476		if (nor->jedec_id == CFI_MFR_ST ||
   477		    nor->jedec_id == CFI_MFR_MACRONIX ||
   478		    nor->jedec_id == CFI_MFR_PMC) {
   479			spi_nor_write_enable(nor);
   480			code = SPINOR_OP_WREAR;
   481		}
   482		nor->bouncebuf[0] = ear;
   483	
   484		if (nor->spimem) {
   485			struct spi_mem_op op =
   486				SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
   487					   SPI_MEM_OP_NO_ADDR,
   488					   SPI_MEM_OP_NO_DUMMY,
   489					   SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
   490	
   491			ret = spi_mem_exec_op(nor->spimem, &op);
   492		} else {
   493			ret = nor->controller_ops->write_reg(nor, code, nor->bouncebuf, 1);
   494			if (ret < 0)
   495				return ret;
   496		}
   497	
   498		nor->curbank = ear;
   499	
   500		return ret;
   501	}
   502	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 66884 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/57bf0fe7/attachment-0001.gz>

From lkp at intel.com  Wed Apr 21 21:52:42 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 04:52:42 +0800
Subject: [xlnx:master 11923/12130] drivers/mtd/spi-nor/core.c:454:6: warning:
 ISO C90 forbids mixing declarations and code
Message-ID: <202104220436.udw7MgW5-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: 26d248f9f56a753db263a6adde4a04f0c6265374 [11923/12130] mtd: spi-nor: Added EAR support for Zynq qspi driver
config: x86_64-randconfig-a015-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/26d248f9f56a753db263a6adde4a04f0c6265374
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 26d248f9f56a753db263a6adde4a04f0c6265374
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/mtd/spi-nor/core.c:454:6: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement]
           u32 ear;
               ^
   drivers/mtd/spi-nor/core.c:3538:6: warning: unused variable 'is_dual' [-Wunused-variable]
           u32 is_dual;
               ^
   drivers/mtd/spi-nor/core.c:3537:22: warning: unused variable 'np_spi' [-Wunused-variable]
           struct device_node *np_spi;
                               ^
   drivers/mtd/spi-nor/core.c:542:12: warning: unused function 'read_ear' [-Wunused-function]
   static int read_ear(struct spi_nor *nor, struct flash_info *info)
              ^
   4 warnings generated.


vim +454 drivers/mtd/spi-nor/core.c

   443	
   444	/**
   445	 * spi_nor_write_ear() - Write Extended Address Register.
   446	 * @nor:	pointer to 'struct spi_nor'.
   447	 * @ear:	value to write to the Extended Address Register.
   448	 *
   449	 * Return: 0 on success, -errno otherwise.
   450	 */
   451	int spi_nor_write_ear(struct spi_nor *nor, u32 addr)
   452	{
   453		u8 code = SPINOR_OP_WREAR;;
 > 454		u32 ear;
   455		int ret;
   456		struct mtd_info *mtd = &nor->mtd;
   457	
   458		/* Wait until finished previous write command. */
   459		if (spi_nor_wait_till_ready(nor))
   460			return 1;
   461	
   462		if (mtd->size <= (0x1000000) << nor->shift)
   463			return 0;
   464	
   465		addr = addr % (u32)mtd->size;
   466		ear = addr >> 24;
   467	
   468		if (!nor->isstacked && ear == nor->curbank)
   469			return 0;
   470	
   471		if (nor->isstacked && mtd->size <= 0x2000000)
   472			return 0;
   473	
   474		if (nor->jedec_id == CFI_MFR_AMD)
   475			code = SPINOR_OP_BRWR;
   476		if (nor->jedec_id == CFI_MFR_ST ||
   477		    nor->jedec_id == CFI_MFR_MACRONIX ||
   478		    nor->jedec_id == CFI_MFR_PMC) {
   479			spi_nor_write_enable(nor);
   480			code = SPINOR_OP_WREAR;
   481		}
   482		nor->bouncebuf[0] = ear;
   483	
   484		if (nor->spimem) {
   485			struct spi_mem_op op =
   486				SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
   487					   SPI_MEM_OP_NO_ADDR,
   488					   SPI_MEM_OP_NO_DUMMY,
   489					   SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
   490	
   491			ret = spi_mem_exec_op(nor->spimem, &op);
   492		} else {
   493			ret = nor->controller_ops->write_reg(nor, code, nor->bouncebuf, 1);
   494			if (ret < 0)
   495				return ret;
   496		}
   497	
   498		nor->curbank = ear;
   499	
   500		return ret;
   501	}
   502	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37988 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/fb76379c/attachment-0001.gz>

From robh at kernel.org  Wed Apr 21 22:19:17 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 16:19:17 -0500
Subject: [PATCH] dt-bindings: net: mediatek: support MT7621 SoC
In-Reply-To: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>
References: <20210419034253.21322-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210421211917.GA1637579@robh.at.kernel.org>

On Sun, 18 Apr 2021 20:42:53 -0700, Ilya Lipnitskiy wrote:
> Add missing binding documentation for SoC support that has been in place
> since v5.1
> 
> Fixes: 889bcbdeee57 ("net: ethernet: mediatek: support MT7621 SoC ethernet hardware")
> Cc: Bj?rn Mork <bjorn at mork.no>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From lkp at intel.com  Wed Apr 21 22:25:49 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 05:25:49 +0800
Subject: [xlnx:master 11924/12130] include/linux/mtd/cfi.h:62:2: warning: No
 CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
Message-ID: <202104220531.QAq5IbPX-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: 581b2657c262a341cf5daebea9e1a55e0289a08b [11924/12130] spi: spi-zynq-qspi: Add dual parallal and stacked support
config: arm64-randconfig-r022-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm64 cross compiling tool for clang build
        # apt-get install binutils-aarch64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/581b2657c262a341cf5daebea9e1a55e0289a08b
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 581b2657c262a341cf5daebea9e1a55e0289a08b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=arm64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/spi/spi-mem.c:10:
   In file included from include/linux/mtd/spi-nor.h:10:
>> include/linux/mtd/cfi.h:62:2: warning: No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work. [-W#warnings]
   #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
    ^
   1 warning generated.


vim +62 include/linux/mtd/cfi.h

^1da177e4c3f41 Linus Torvalds  2005-04-16  60  
241651d04d672f David Woodhouse 2007-09-06  61  #ifndef cfi_interleave
241651d04d672f David Woodhouse 2007-09-06 @62  #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
241651d04d672f David Woodhouse 2007-09-06  63  static inline int cfi_interleave(void *cfi)
241651d04d672f David Woodhouse 2007-09-06  64  {
241651d04d672f David Woodhouse 2007-09-06  65  	BUG();
241651d04d672f David Woodhouse 2007-09-06  66  	return 0;
241651d04d672f David Woodhouse 2007-09-06  67  }
241651d04d672f David Woodhouse 2007-09-06  68  #endif
241651d04d672f David Woodhouse 2007-09-06  69  

:::::: The code at line 62 was first introduced by commit
:::::: 241651d04d672fb685b2874707016cbbf95931e5 [MTD] Fix CFI build error when no map width or interleave supported

:::::: TO: David Woodhouse <dwmw2 at infradead.org>
:::::: CC: David Woodhouse <dwmw2 at infradead.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33010 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/8c9cfd48/attachment-0001.gz>

From robh at kernel.org  Wed Apr 21 23:03:02 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:03:02 -0500
Subject: [PATCH] dt-bindings: net: mediatek/ralink: remove unused bindings
In-Reply-To: <20210420024222.101615-1-ilya.lipnitskiy@gmail.com>
References: <20210420024222.101615-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210421220302.GA1637795@robh.at.kernel.org>

On Mon, Apr 19, 2021 at 07:42:22PM -0700, Ilya Lipnitskiy wrote:
> Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
> ralink/mediatek SoC ethernet binding")
> 
> No in-tree drivers use the compatible strings present in these bindings,
> and some have been superseded by DSA-capable mtk_eth_soc driver, so
> remove these obsolete bindings.

Looks like maybe OpenWRT folks are using these. If so, you can't revert 
them.

> 
> Cc: John Crispin <john at phrozen.org>
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  .../bindings/net/mediatek,mt7620-gsw.txt      | 24 --------
>  .../bindings/net/ralink,rt2880-net.txt        | 59 -------------------
>  .../bindings/net/ralink,rt3050-esw.txt        | 30 ----------
>  3 files changed, 113 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
>  delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
>  delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt b/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
> deleted file mode 100644
> index 358fed2fab43..000000000000
> --- a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -Mediatek Gigabit Switch
> -=======================
> -
> -The mediatek gigabit switch can be found on Mediatek SoCs (mt7620, mt7621).
> -
> -Required properties:
> -- compatible: Should be "mediatek,mt7620-gsw" or "mediatek,mt7621-gsw"
> -- reg: Address and length of the register set for the device
> -- interrupts: Should contain the gigabit switches interrupt
> -- resets: Should contain the gigabit switches resets
> -- reset-names: Should contain the reset names "gsw"
> -
> -Example:
> -
> -gsw at 10110000 {
> -	compatible = "ralink,mt7620-gsw";
> -	reg = <0x10110000 8000>;
> -
> -	resets = <&rstctrl 23>;
> -	reset-names = "gsw";
> -
> -	interrupt-parent = <&intc>;
> -	interrupts = <17>;
> -};
> diff --git a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt b/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
> deleted file mode 100644
> index 9fe1a0a22e44..000000000000
> --- a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
> +++ /dev/null
> @@ -1,59 +0,0 @@
> -Ralink Frame Engine Ethernet controller
> -=======================================
> -
> -The Ralink frame engine ethernet controller can be found on Ralink and
> -Mediatek SoCs (RT288x, RT3x5x, RT366x, RT388x, rt5350, mt7620, mt7621, mt76x8).
> -
> -Depending on the SoC, there is a number of ports connected to the CPU port
> -directly and/or via a (gigabit-)switch.
> -
> -* Ethernet controller node
> -
> -Required properties:
> -- compatible: Should be one of "ralink,rt2880-eth", "ralink,rt3050-eth",
> -  "ralink,rt3050-eth", "ralink,rt3883-eth", "ralink,rt5350-eth",
> -  "mediatek,mt7620-eth", "mediatek,mt7621-eth"
> -- reg: Address and length of the register set for the device
> -- interrupts: Should contain the frame engines interrupt
> -- resets: Should contain the frame engines resets
> -- reset-names: Should contain the reset names "fe". If a switch is present
> -  "esw" is also required.
> -
> -
> -* Ethernet port node
> -
> -Required properties:
> -- compatible: Should be "ralink,eth-port"
> -- reg: The number of the physical port
> -- phy-handle: reference to the node describing the phy
> -
> -Example:
> -
> -mdio-bus {
> -	...
> -	phy0: ethernet-phy at 0 {
> -		phy-mode = "mii";
> -		reg = <0>;
> -	};
> -};
> -
> -ethernet at 400000 {
> -	compatible = "ralink,rt2880-eth";
> -	reg = <0x00400000 10000>;
> -
> -	#address-cells = <1>;
> -	#size-cells = <0>;
> -
> -	resets = <&rstctrl 18>;
> -	reset-names = "fe";
> -
> -	interrupt-parent = <&cpuintc>;
> -	interrupts = <5>;
> -
> -	port at 0 {
> -		compatible = "ralink,eth-port";
> -		reg = <0>;
> -		phy-handle = <&phy0>;
> -	};
> -
> -};
> diff --git a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt b/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> deleted file mode 100644
> index 87e315856efa..000000000000
> --- a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -Ralink Fast Ethernet Embedded Switch
> -====================================
> -
> -The ralink fast ethernet embedded switch can be found on Ralink and Mediatek
> -SoCs (RT3x5x, RT5350, MT76x8).
> -
> -Required properties:
> -- compatible: Should be "ralink,rt3050-esw"
> -- reg: Address and length of the register set for the device
> -- interrupts: Should contain the embedded switches interrupt
> -- resets: Should contain the embedded switches resets
> -- reset-names: Should contain the reset names "esw"
> -
> -Optional properties:
> -- ralink,portmap: can be used to choose if the default switch setup is
> -  llllw or wllll
> -- ralink,led_polarity: override the active high/low settings of the leds
> -
> -Example:
> -
> -esw at 10110000 {
> -	compatible = "ralink,rt3050-esw";
> -	reg = <0x10110000 8000>;
> -
> -	resets = <&rstctrl 23>;
> -	reset-names = "esw";
> -
> -	interrupt-parent = <&intc>;
> -	interrupts = <17>;
> -};
> -- 
> 2.31.1
> 


From ilya.lipnitskiy at gmail.com  Wed Apr 21 23:04:59 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 15:04:59 -0700
Subject: [PATCH] dt-bindings: net: mediatek/ralink: remove unused bindings
In-Reply-To: <20210421220302.GA1637795@robh.at.kernel.org>
References: <20210420024222.101615-1-ilya.lipnitskiy@gmail.com>
 <20210421220302.GA1637795@robh.at.kernel.org>
Message-ID: <CALCv0x2oSXBT-6LteYtr9J5XmmDuer_=sbCgB5CBXWe_cKk2sA@mail.gmail.com>

Hi Rob,

On Wed, Apr 21, 2021 at 3:03 PM Rob Herring <robh at kernel.org> wrote:
>
> On Mon, Apr 19, 2021 at 07:42:22PM -0700, Ilya Lipnitskiy wrote:
> > Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
> > ralink/mediatek SoC ethernet binding")
> >
> > No in-tree drivers use the compatible strings present in these bindings,
> > and some have been superseded by DSA-capable mtk_eth_soc driver, so
> > remove these obsolete bindings.
>
> Looks like maybe OpenWRT folks are using these. If so, you can't revert
> them.
Indeed, there are out of tree drivers for some of these. I wasn't sure
what the dt-binding policy was for such use cases - can you point me
to a definitive reference?

Ilya
>
> >
> > Cc: John Crispin <john at phrozen.org>
> > Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> > ---
> >  .../bindings/net/mediatek,mt7620-gsw.txt      | 24 --------
> >  .../bindings/net/ralink,rt2880-net.txt        | 59 -------------------
> >  .../bindings/net/ralink,rt3050-esw.txt        | 30 ----------
> >  3 files changed, 113 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
> >  delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
> >  delete mode 100644 Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt b/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
> > deleted file mode 100644
> > index 358fed2fab43..000000000000
> > --- a/Documentation/devicetree/bindings/net/mediatek,mt7620-gsw.txt
> > +++ /dev/null
> > @@ -1,24 +0,0 @@
> > -Mediatek Gigabit Switch
> > -=======================
> > -
> > -The mediatek gigabit switch can be found on Mediatek SoCs (mt7620, mt7621).
> > -
> > -Required properties:
> > -- compatible: Should be "mediatek,mt7620-gsw" or "mediatek,mt7621-gsw"
> > -- reg: Address and length of the register set for the device
> > -- interrupts: Should contain the gigabit switches interrupt
> > -- resets: Should contain the gigabit switches resets
> > -- reset-names: Should contain the reset names "gsw"
> > -
> > -Example:
> > -
> > -gsw at 10110000 {
> > -     compatible = "ralink,mt7620-gsw";
> > -     reg = <0x10110000 8000>;
> > -
> > -     resets = <&rstctrl 23>;
> > -     reset-names = "gsw";
> > -
> > -     interrupt-parent = <&intc>;
> > -     interrupts = <17>;
> > -};
> > diff --git a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt b/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
> > deleted file mode 100644
> > index 9fe1a0a22e44..000000000000
> > --- a/Documentation/devicetree/bindings/net/ralink,rt2880-net.txt
> > +++ /dev/null
> > @@ -1,59 +0,0 @@
> > -Ralink Frame Engine Ethernet controller
> > -=======================================
> > -
> > -The Ralink frame engine ethernet controller can be found on Ralink and
> > -Mediatek SoCs (RT288x, RT3x5x, RT366x, RT388x, rt5350, mt7620, mt7621, mt76x8).
> > -
> > -Depending on the SoC, there is a number of ports connected to the CPU port
> > -directly and/or via a (gigabit-)switch.
> > -
> > -* Ethernet controller node
> > -
> > -Required properties:
> > -- compatible: Should be one of "ralink,rt2880-eth", "ralink,rt3050-eth",
> > -  "ralink,rt3050-eth", "ralink,rt3883-eth", "ralink,rt5350-eth",
> > -  "mediatek,mt7620-eth", "mediatek,mt7621-eth"
> > -- reg: Address and length of the register set for the device
> > -- interrupts: Should contain the frame engines interrupt
> > -- resets: Should contain the frame engines resets
> > -- reset-names: Should contain the reset names "fe". If a switch is present
> > -  "esw" is also required.
> > -
> > -
> > -* Ethernet port node
> > -
> > -Required properties:
> > -- compatible: Should be "ralink,eth-port"
> > -- reg: The number of the physical port
> > -- phy-handle: reference to the node describing the phy
> > -
> > -Example:
> > -
> > -mdio-bus {
> > -     ...
> > -     phy0: ethernet-phy at 0 {
> > -             phy-mode = "mii";
> > -             reg = <0>;
> > -     };
> > -};
> > -
> > -ethernet at 400000 {
> > -     compatible = "ralink,rt2880-eth";
> > -     reg = <0x00400000 10000>;
> > -
> > -     #address-cells = <1>;
> > -     #size-cells = <0>;
> > -
> > -     resets = <&rstctrl 18>;
> > -     reset-names = "fe";
> > -
> > -     interrupt-parent = <&cpuintc>;
> > -     interrupts = <5>;
> > -
> > -     port at 0 {
> > -             compatible = "ralink,eth-port";
> > -             reg = <0>;
> > -             phy-handle = <&phy0>;
> > -     };
> > -
> > -};
> > diff --git a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt b/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> > deleted file mode 100644
> > index 87e315856efa..000000000000
> > --- a/Documentation/devicetree/bindings/net/ralink,rt3050-esw.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -Ralink Fast Ethernet Embedded Switch
> > -====================================
> > -
> > -The ralink fast ethernet embedded switch can be found on Ralink and Mediatek
> > -SoCs (RT3x5x, RT5350, MT76x8).
> > -
> > -Required properties:
> > -- compatible: Should be "ralink,rt3050-esw"
> > -- reg: Address and length of the register set for the device
> > -- interrupts: Should contain the embedded switches interrupt
> > -- resets: Should contain the embedded switches resets
> > -- reset-names: Should contain the reset names "esw"
> > -
> > -Optional properties:
> > -- ralink,portmap: can be used to choose if the default switch setup is
> > -  llllw or wllll
> > -- ralink,led_polarity: override the active high/low settings of the leds
> > -
> > -Example:
> > -
> > -esw at 10110000 {
> > -     compatible = "ralink,rt3050-esw";
> > -     reg = <0x10110000 8000>;
> > -
> > -     resets = <&rstctrl 23>;
> > -     reset-names = "esw";
> > -
> > -     interrupt-parent = <&intc>;
> > -     interrupts = <17>;
> > -};
> > --
> > 2.31.1
> >


From ameynarkhede03 at gmail.com  Wed Apr 21 23:10:30 2021
From: ameynarkhede03 at gmail.com (Amey Narkhede)
Date: Thu, 22 Apr 2021 03:40:30 +0530
Subject: [PATCH] iommu/qcom: Cleanup resources in case of probe error path
Message-ID: <20210421221030.70647-1-ameynarkhede03@gmail.com>

If device registration fails, remove sysfs attribute
and if setting bus callbacks fails, unregister the device
and cleanup the sysfs attribute.

Signed-off-by: Amey Narkhede <ameynarkhede03 at gmail.com>
---
 drivers/iommu/arm/arm-smmu/qcom_iommu.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 4294abe389b2..5fa128a1f7f0 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -850,10 +850,12 @@ static int qcom_iommu_device_probe(struct platform_device *pdev)
 	ret = iommu_device_register(&qcom_iommu->iommu, &qcom_iommu_ops, dev);
 	if (ret) {
 		dev_err(dev, "Failed to register iommu\n");
-		return ret;
+		goto err_sysfs_remove;
 	}

-	bus_set_iommu(&platform_bus_type, &qcom_iommu_ops);
+	ret = bus_set_iommu(&platform_bus_type, &qcom_iommu_ops);
+	if (ret)
+		goto err_unregister_device;

 	if (qcom_iommu->local_base) {
 		pm_runtime_get_sync(dev);
@@ -862,6 +864,14 @@ static int qcom_iommu_device_probe(struct platform_device *pdev)
 	}

 	return 0;
+
+err_unregister_device:
+	iommu_device_unregister(&qcom_iommu->iommu);
+
+err_sysfs_remove:
+	iommu_device_sysfs_remove(&qcom_iommu->iommu);
+
+	return ret;
 }

 static int qcom_iommu_device_remove(struct platform_device *pdev)
--
2.31.1

I assume its ok to leave pm_runtime_enable in case of error.


From robh at kernel.org  Wed Apr 21 23:12:33 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:12:33 -0500
Subject: [PATCH 0/4] dt-bindings: soc/arm: Convert pending ti,sci*
 bindings to json format
In-Reply-To: <20210416063721.20538-1-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
Message-ID: <20210421221233.GA1705110@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 01:37:17AM -0500, Nishanth Menon wrote:
> Hi,
> 
> I understand that the following series belong to various maintainers,
> but, it is a bit better reviewed as a single series for
> cohesiveness.

They need to go in together as patch 4 depends on the others.

> 
> There are also dts fixups that this series exposes, which is good, but
> I chose to hold them back for now pending binding review at least. The
> complete series is available in [1] if folks are curious.
> 
> Nishanth Menon (4):
>   dt-bindings: reset: Convert ti,sci-reset to json schema
>   dt-bindings: clock: Convert ti,sci-clk to json schema
>   dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
>   dt-bindings: arm: keystone: Convert ti,sci to json schema
> 
>  .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
>  .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
>  .../devicetree/bindings/clock/ti,sci-clk.txt  |  36 -----
>  .../devicetree/bindings/clock/ti,sci-clk.yaml |  52 +++++++
>  .../bindings/reset/ti,sci-reset.txt           |  62 ---------
>  .../bindings/reset/ti,sci-reset.yaml          |  51 +++++++
>  .../bindings/soc/ti/sci-pm-domain.txt         |  65 ---------
>  .../bindings/soc/ti/sci-pm-domain.yaml        |  59 ++++++++
>  8 files changed, 291 insertions(+), 249 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
>  delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
>  delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>  create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
>  delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
> 
> [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci
> 
> Regards,
> Nishanth Menon
> -- 
> 2.31.0
> 


From lkp at intel.com  Wed Apr 21 23:13:55 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 06:13:55 +0800
Subject: [xlnx:master 11850/12130]
 drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of
 function 'regulator_lock'
Message-ID: <202104220647.r927DLi5-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: a6aea4afc0f41390d36b593f455902b6fdd75685 [11850/12130] regulator: da9121: Use core regulator lock
config: powerpc-randconfig-r011-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc cross compiling tool for clang build
        # apt-get install binutils-powerpc-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/a6aea4afc0f41390d36b593f455902b6fdd75685
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout a6aea4afc0f41390d36b593f455902b6fdd75685
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of function 'regulator_lock' [-Werror,-Wimplicit-function-declaration]
                   regulator_lock(rdev);
                   ^
>> drivers/regulator/da9121-regulator.c:750:3: error: implicit declaration of function 'regulator_unlock' [-Werror,-Wimplicit-function-declaration]
                   regulator_unlock(rdev);
                   ^
   drivers/regulator/da9121-regulator.c:750:3: note: did you mean 'regulator_lock'?
   drivers/regulator/da9121-regulator.c:748:3: note: 'regulator_lock' declared here
                   regulator_lock(rdev);
                   ^
   2 errors generated.


vim +/regulator_lock +748 drivers/regulator/da9121-regulator.c

   676	
   677	static inline int da9121_handle_notifier(
   678			struct da9121 *chip, struct regulator_dev *rdev,
   679			unsigned int event_bank, unsigned int event, unsigned int ebit)
   680	{
   681		enum { R0 = 0, R1, R2, REG_MAX_NUM };
   682		unsigned long notification = 0;
   683		int ret = 0;
   684	
   685		if (event & ebit) {
   686			switch (event_bank) {
   687			case DA9121_REG_SYS_EVENT_0:
   688				switch (event & ebit) {
   689				case DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT:
   690					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT;
   691					notification |= REGULATOR_EVENT_OVER_TEMP |
   692							REGULATOR_EVENT_DISABLE;
   693					break;
   694				case DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN:
   695					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN;
   696					notification |= REGULATOR_EVENT_OVER_TEMP;
   697					break;
   698				default:
   699					dev_warn(chip->dev,
   700						 "Unhandled event in bank0 0x%02x\n",
   701						 event & ebit);
   702					ret = -EINVAL;
   703					break;
   704				}
   705				break;
   706			case DA9121_REG_SYS_EVENT_1:
   707				switch (event & ebit) {
   708				case DA9121_MASK_SYS_EVENT_1_E_OV1:
   709					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OV1;
   710					notification |= REGULATOR_EVENT_REGULATION_OUT;
   711					break;
   712				case DA9121_MASK_SYS_EVENT_1_E_UV1:
   713					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_UV1;
   714					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   715					break;
   716				case DA9121_MASK_SYS_EVENT_1_E_OC1:
   717					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OC1;
   718					notification |= REGULATOR_EVENT_OVER_CURRENT;
   719					break;
   720				case DA9xxx_MASK_SYS_EVENT_1_E_OV2:
   721					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OV2;
   722					notification |= REGULATOR_EVENT_REGULATION_OUT;
   723					break;
   724				case DA9xxx_MASK_SYS_EVENT_1_E_UV2:
   725					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_UV2;
   726					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   727					break;
   728				case DA9xxx_MASK_SYS_EVENT_1_E_OC2:
   729					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OC2;
   730					notification |= REGULATOR_EVENT_OVER_CURRENT;
   731					break;
   732				default:
   733					dev_warn(chip->dev,
   734						 "Unhandled event in bank1 0x%02x\n",
   735						 event & ebit);
   736					ret = -EINVAL;
   737					break;
   738				}
   739				break;
   740			default:
   741				dev_warn(chip->dev,
   742					 "Unhandled event bank 0x%02x\n", event_bank);
   743				ret = -EINVAL;
   744				goto error;
   745				break;
   746			}
   747	
 > 748			regulator_lock(rdev);
   749			regulator_notifier_call_chain(rdev, notification, NULL);
 > 750			regulator_unlock(rdev);
   751		}
   752	
   753	error:
   754		return ret;
   755	}
   756	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29666 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/63e515b1/attachment-0001.gz>

From robh at kernel.org  Wed Apr 21 23:31:45 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:31:45 -0500
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema
In-Reply-To: <20210417125127.vigq23mdoodje6b5@velcro>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-3-nm@ti.com>
 <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>
 <20210417125127.vigq23mdoodje6b5@velcro>
Message-ID: <20210421223145.GB1705110@robh.at.kernel.org>

On Sat, Apr 17, 2021 at 07:51:27AM -0500, Nishanth Menon wrote:
> On 16:55-20210416, Stephen Boyd wrote:
> > Quoting Nishanth Menon (2021-04-15 23:37:19)
> > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > new file mode 100644
> > > index 000000000000..72633651f0c7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > @@ -0,0 +1,52 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI-SCI clock controller node bindings
> > > +
> > > +maintainers:
> > > +  - Nishanth Menon <nm at ti.com>
> > > +
> > > +allOf:
> > > +  - $ref: /schemas/clock/clock.yaml#
> > 
> > Is this needed?

No. It is already applied to every node.

> https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> This standardizes provider properties like '#clock-cells' etc, allowing
> you to add more stricter checks or controls in the future if necessary.
> 
> while:
> 
> https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> is more a consumer node description.

No, the meta-schema is what checks the schemas just as the schemas check 
dts files.

> Should I have picked a different yaml as base for a standard clock-controller
> base?
> 
> > 
> > > +
> > > +description: |
> > > +  Some TI SoCs contain a system controller (like the Power Management Micro
> > > +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > +  the state of the various hardware modules present on the SoC. Communication
> > > +  between the host processor running an OS and the system controller happens
> > > +  through a protocol called TI System Control Interface (TI-SCI protocol).
> > > +
> > > +  This clock controller node uses the TI SCI protocol to perform various clock
> > > +  management of various hardware modules (devices) present on the SoC. This
> > > +  node must be a child node of the associated TI-SCI system controller node.
> > > +
> > > +properties:
> > > +  $nodename:
> > > +    pattern: "^clock-controller$"
> > 
> > Is this nodename pattern check required?
> 
> I'd like the definition on rails and not subject to interpretation, and
> restrict the kind of subnodes under TISCI controller node.

If this schema was standalone and not defined as part of another, then 
yes it would be required. In your case, you can enforce the node name 
from the parent schema. For consistency though, it would be better to 
just always require $nodename. 

Actually, this schema will be applied twice. On it's own matching the 
compatible string and by the parent schema. You can prevent that with 
'select: false'. I don't mind the double validation as if the parent 
node had a compatible typo you'd get zero validation.

> 
> > 
> > > +
> > > +  compatible:
> > > +    const: ti,k2g-sci-clk
> > 
> > I thought most things keyed off the compatible string.
> 
> Yes, they are. I am not sure I understand your question here. Did you
> mean to indicate that having $nodename and compatible both are
> redundant?
> 
> Redundancy was'nt the intent of this schema definition, rather, I'd like
> to make sure that it is not upto interpretation or debate as to what the
> node name should be: I believe clock-controller is the correct nodename
> (without @0x... since this does'nt use reg property) instead of using
> clocks, tisci-clock as the node names.
> 
> 
> Do you suggest something  different?
> 
> -- 
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D


From robh at kernel.org  Wed Apr 21 23:32:54 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:32:54 -0500
Subject: [PATCH 1/4] dt-bindings: reset: Convert ti,sci-reset to json
 schema
In-Reply-To: <20210416063721.20538-2-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-2-nm@ti.com>
Message-ID: <20210421223254.GA1734415@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 01:37:18AM -0500, Nishanth Menon wrote:
> Convert the ti,sci-reset to json schema for better checks and documentation.
> 
> Differences being:
>  - Drop consumer example as they are documented in the corresponding
>    bindings themselves.
>  - Drop phandle description for reset consumer or cell definition as it is
>    redundant.
> 
> NOTE: we do have false positive checkpatch warning with this patch:
> "DT binding docs and includes should be a separate patch"
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/reset/ti,sci-reset.txt           | 62 -------------------
>  .../bindings/reset/ti,sci-reset.yaml          | 51 +++++++++++++++
>  2 files changed, 51 insertions(+), 62 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>  create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml

Reviewed-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Wed Apr 21 23:36:27 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:36:27 -0500
Subject: [PATCH 3/4] dt-bindings: soc: ti: Convert ti, sci-pm-domain to
 json schema
In-Reply-To: <20210416063721.20538-4-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-4-nm@ti.com>
Message-ID: <20210421223627.GA1740013@robh.at.kernel.org>

On Fri, 16 Apr 2021 01:37:20 -0500, Nishanth Menon wrote:
> Convert the ti,sci-pm-domain to json schema for better checks and
> documentation.
> 
> Differences being:
>  - Drop consumer example as they are documented in the corresponding
>    bindings themselves.
>  - Drop phandle description for reset consumer or cell definition as it
>    is redundant.
> 
> NOTE: we do have false positive checkpatch warning with this patch:
> "DT binding docs and includes should be a separate patch"
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/soc/ti/sci-pm-domain.txt         | 65 -------------------
>  .../bindings/soc/ti/sci-pm-domain.yaml        | 59 +++++++++++++++++
>  2 files changed, 59 insertions(+), 65 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Wed Apr 21 23:40:41 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:40:41 -0500
Subject: [PATCH 4/4] dt-bindings: arm: keystone: Convert ti,sci to json
 schema
In-Reply-To: <20210416063721.20538-5-nm@ti.com>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-5-nm@ti.com>
Message-ID: <20210421224041.GA1740292@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 01:37:21AM -0500, Nishanth Menon wrote:
> Convert the ti,sci to json schema for better checks and documentation.
> 
> NOTE: This change does introduce a stricter naming convention for
> TI-SCI controller nodes.
> 
> NOTE: we do have false positive checkpatch warning with this patch:
> "DT binding docs and includes should be a separate patch"
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
>  .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
>  2 files changed, 129 insertions(+), 86 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> deleted file mode 100644
> index 6f0cd31c1520..000000000000
> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +++ /dev/null
> @@ -1,86 +0,0 @@
> -Texas Instruments System Control Interface (TI-SCI) Message Protocol
> ---------------------------------------------------------------------
> -
> -Texas Instrument's processors including those belonging to Keystone generation
> -of processors have separate hardware entity which is now responsible for the
> -management of the System on Chip (SoC) system. These include various system
> -level functions as well.
> -
> -An example of such an SoC is K2G, which contains the system control hardware
> -block called Power Management Micro Controller (PMMC). This hardware block is
> -initialized early into boot process and provides services to Operating Systems
> -on multiple processors including ones running Linux.
> -
> -See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
> -
> -TI-SCI controller Device Node:
> -=============================
> -
> -The TI-SCI node describes the Texas Instrument's System Controller entity node.
> -This parent node may optionally have additional children nodes which describe
> -specific functionality such as clocks, power domain, reset or additional
> -functionality as may be required for the SoC. This hierarchy also describes the
> -relationship between the TI-SCI parent node to the child node.
> -
> -Required properties:
> --------------------
> -- compatible:	should be "ti,k2g-sci" for TI 66AK2G SoC
> -		should be "ti,am654-sci" for for TI AM654 SoC
> -- mbox-names:
> -	"rx" - Mailbox corresponding to receive path
> -	"tx" - Mailbox corresponding to transmit path
> -
> -- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
> -	  property should contain a phandle to the mailbox controller device
> -	  node and an args specifier that will be the phandle to the intended
> -	  sub-mailbox child node to be used for communication.
> -
> -See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
> -about the generic mailbox controller and client driver bindings. Also see
> -Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
> -controller that is used to communicate with this System controllers.
> -
> -Optional Properties:
> --------------------
> -- reg-names:
> -	debug_messages - Map the Debug message region
> -- reg:  register space corresponding to the debug_messages
> -- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
> -- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
> -	for identification of host processing entities such as virtual
> -	machines
> -
> -Example (K2G):
> --------------
> -	pmmc: pmmc {
> -		compatible = "ti,k2g-sci";
> -		ti,host-id = <2>;
> -		mbox-names = "rx", "tx";
> -		mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
> -			<&msgmgr &msgmgr_proxy_pmmc_tx>;
> -		reg-names = "debug_messages";
> -		reg = <0x02921800 0x800>;
> -	};
> -
> -
> -TI-SCI Client Device Node:
> -=========================
> -
> -Client nodes are maintained as children of the relevant TI-SCI device node.
> -
> -Example (K2G):
> --------------
> -	pmmc: pmmc {
> -		compatible = "ti,k2g-sci";
> -		...
> -
> -		my_clk_node: clk_node {
> -			...
> -			...
> -		};
> -
> -		my_pd_node: pd_node {
> -			...
> -			...
> -		};
> -	};
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> new file mode 100644
> index 000000000000..3e835ad84dc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI-SCI controller device node bindings
> +
> +maintainers:
> +  - Nishanth Menon <nm at ti.com>
> +
> +allOf:
> +  - $ref: /schemas/mbox/mbox-consumer.yaml#

Drop.

> +
> +description: |
> +  Texas Instrument's processors including those belonging to Keystone generation
> +  of processors have separate hardware entity which is now responsible for the
> +  management of the System on Chip (SoC) system. These include various system
> +  level functions as well.
> +
> +  An example of such an SoC is K2G, which contains the system control hardware
> +  block called Power Management Micro Controller (PMMC). This hardware block is
> +  initialized early into boot process and provides services to Operating Systems
> +  on multiple processors including ones running Linux.
> +
> +  See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
> +
> +  The TI-SCI node describes the Texas Instrument's System Controller entity node.
> +  This parent node may optionally have additional children nodes which describe
> +  specific functionality such as clocks, power domain, reset or additional
> +  functionality as may be required for the SoC. This hierarchy also describes the
> +  relationship between the TI-SCI parent node to the child node.
> +
> +properties:
> +  $nodename:
> +    pattern: "^system-controller@[0-9a-f]+$"
> +
> +  compatible:
> +    oneOf:
> +      - description: System controller on TI 66AK2G SoC and other K3 SoCs
> +        items:
> +          - const: ti,k2g-sci
> +      - description: System controller on TI AM654 SoC
> +        items:
> +          - const: ti,am654-sci
> +
> +  reg-names:
> +    description: |
> +      Specifies the debug messages memory mapped region that is optionally
> +      made available from TI-SCI controller.
> +      - const: debug_messages

Drop the '-' and fix the indent so it's an actual schema.

> +
> +  reg:
> +    minItems: 1
> +
> +  mbox-names:
> +    description: |
> +      Specifies the mailboxes used to communicate with TI-SCI Controller
> +      made available from TI-SCI controller.
> +    items:
> +      - const: rx
> +      - const: tx
> +
> +  mboxes:
> +    minItems: 2
> +
> +  ti,system-reboot-controller:
> +    description: Determines If system reboot can be triggered by SoC reboot
> +    type: boolean
> +
> +  ti,host-id:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: |
> +      Value corresponding to the host ID assigned by Firmware
> +      for identification of host processing entities such as virtual machines.
> +
> +required:
> +  - compatible
> +  - mbox-names
> +  - mboxes
> +
> +additionalProperties: false
> +
> +patternProperties:
> +  # All other properties should be a power, clock or reset controller
> +  "^(power-controller|clock-controller|reset-controller)$":
> +    type: object
> +    oneOf:
> +      - $ref: /schemas/soc/ti/sci-pm-domain.yaml#
> +      - $ref: /schemas/clock/ti,sci-clk.yaml#
> +      - $ref: /schemas/reset/ti,sci-reset.yaml#

I'd prefer you separate these with a property for each node.

> +
> +examples:
> +  - |
> +    pmmc: system-controller at 2921800 {
> +      compatible = "ti,k2g-sci";
> +      ti,system-reboot-controller;
> +      mbox-names = "rx", "tx";
> +      mboxes= <&msgmgr 5 2>,
> +              <&msgmgr 0 0>;
> +      reg-names = "debug_messages";
> +      reg = <0x02921800 0x800>;
> +    };
> +
> +  - |
> +    dmsc: system-controller at 44083000 {
> +      compatible = "ti,k2g-sci";
> +      ti,host-id = <12>;
> +      mbox-names = "rx", "tx";
> +      mboxes= <&secure_proxy_main 11>,
> +              <&secure_proxy_main 13>;
> +      reg-names = "debug_messages";
> +      reg = <0x44083000 0x1000>;
> +
> +      k3_pds: power-controller {
> +        compatible = "ti,sci-pm-domain";
> +        #power-domain-cells = <2>;
> +      };
> +
> +      k3_clks: clock-controller {
> +        compatible = "ti,k2g-sci-clk";
> +        #clock-cells = <2>;
> +      };
> +
> +      k3_reset: reset-controller {
> +        compatible = "ti,sci-reset";
> +        #reset-cells = <2>;
> +      };
> +    };
> -- 
> 2.31.0
> 


From robh at kernel.org  Wed Apr 21 23:44:11 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:44:11 -0500
Subject: [PATCH net-next 01/10] dt-bindings: net: sparx5: Add
 sparx5-switch bindings
In-Reply-To: <20210416131657.3151464-2-steen.hegelund@microchip.com>
References: <20210416131657.3151464-1-steen.hegelund@microchip.com>
 <20210416131657.3151464-2-steen.hegelund@microchip.com>
Message-ID: <20210421224411.GA1746146@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 03:16:48PM +0200, Steen Hegelund wrote:
> Document the Sparx5 switch device driver bindings
> 
> Signed-off-by: Steen Hegelund <steen.hegelund at microchip.com>
> Signed-off-by: Lars Povlsen <lars.povlsen at microchip.com>
> Signed-off-by: Bjarni Jonasson <bjarni.jonasson at microchip.com>
> ---
>  .../bindings/net/microchip,sparx5-switch.yaml | 227 ++++++++++++++++++
>  1 file changed, 227 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> 
> diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> new file mode 100644
> index 000000000000..2eeb5230d8c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
> @@ -0,0 +1,227 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip Sparx5 Ethernet switch controller
> +
> +maintainers:
> +  - Steen Hegelund <steen.hegelund at microchip.com>
> +  - Lars Povlsen <lars.povlsen at microchip.com>
> +
> +description: |
> +  The SparX-5 Enterprise Ethernet switch family provides a rich set of
> +  Enterprise switching features such as advanced TCAM-based VLAN and
> +  QoS processing enabling delivery of differentiated services, and
> +  security through TCAM-based frame processing using versatile content
> +  aware processor (VCAP).
> +
> +  IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported
> +  with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K
> +  IPv6 (S,G) multicast groups.
> +
> +  L3 security features include source guard and reverse path
> +  forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and
> +  IP tunnels (IP over GRE/IP).
> +
> +  The SparX-5 switch family targets managed Layer 2 and Layer 3
> +  equipment in SMB, SME, and Enterprise where high port count
> +  1G/2.5G/5G/10G switching with 10G/25G aggregation links is required.
> +
> +properties:
> +  $nodename:
> +    pattern: "^switch@[0-9a-f]+$"
> +
> +  compatible:
> +    const: microchip,sparx5-switch
> +
> +  reg:
> +    minItems: 3

Drop, that's the default implied by 'items' length.

Otherwise,

Reviewed-by: Rob Herring <robh at kernel.org>

> +    items:
> +      - description: cpu target
> +      - description: devices target
> +      - description: general control block target
> +
> +  reg-names:
> +    items:
> +      - const: cpu
> +      - const: devices
> +      - const: gcb
> +
> +  interrupts:
> +    minItems: 1
> +    items:
> +      - description: register based extraction
> +      - description: frame dma based extraction
> +
> +  interrupt-names:
> +    minItems: 1
> +    items:
> +      - const: xtr
> +      - const: fdma
> +
> +  resets:
> +    items:
> +      - description: Reset controller used for switch core reset (soft reset)
> +
> +  reset-names:
> +    items:
> +      - const: switch
> +
> +  mac-address: true
> +
> +  ethernet-ports:
> +    type: object
> +    patternProperties:
> +      "^port@[0-9a-f]+$":
> +        type: object
> +
> +        properties:
> +          '#address-cells':
> +            const: 1
> +          '#size-cells':
> +            const: 0
> +
> +          reg:
> +            description: Switch port number
> +
> +          phys:
> +            maxItems: 1
> +            description:
> +              phandle of a Ethernet SerDes PHY.  This defines which SerDes
> +              instance will handle the Ethernet traffic.
> +
> +          phy-mode:
> +            description:
> +              This specifies the interface used by the Ethernet SerDes towards
> +              the PHY or SFP.
> +
> +          microchip,bandwidth:
> +            description: Specifies bandwidth in Mbit/s allocated to the port.
> +            $ref: "/schemas/types.yaml#/definitions/uint32"
> +            maximum: 25000
> +
> +          phy-handle:
> +            description:
> +              phandle of a Ethernet PHY.  This is optional and if provided it
> +              points to the cuPHY used by the Ethernet SerDes.
> +
> +          sfp:
> +            description:
> +              phandle of an SFP.  This is optional and used when not specifying
> +              a cuPHY.  It points to the SFP node that describes the SFP used by
> +              the Ethernet SerDes.
> +
> +          managed: true
> +
> +          microchip,sd-sgpio:
> +            description:
> +              Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs
> +              This is optional, and only needed if the default used index is
> +              is not correct.
> +            $ref: "/schemas/types.yaml#/definitions/uint32"
> +            minimum: 0
> +            maximum: 383
> +
> +        required:
> +          - reg
> +          - phys
> +          - phy-mode
> +          - microchip,bandwidth
> +
> +        oneOf:
> +          - required:
> +              - phy-handle
> +          - required:
> +              - sfp
> +              - managed
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - interrupts
> +  - interrupt-names
> +  - resets
> +  - reset-names
> +  - ethernet-ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    switch: switch at 600000000 {
> +      compatible = "microchip,sparx5-switch";
> +      reg =  <0 0x401000>,
> +             <0x10004000 0x7fc000>,
> +             <0x11010000 0xaf0000>;
> +      reg-names = "cpu", "devices", "gcb";
> +      interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
> +      interrupt-names = "xtr";
> +      resets = <&reset 0>;
> +      reset-names = "switch";
> +      ethernet-ports {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        port0: port at 0 {
> +          reg = <0>;
> +          microchip,bandwidth = <1000>;
> +          phys = <&serdes 13>;
> +          phy-handle = <&phy0>;
> +          phy-mode = "qsgmii";
> +        };
> +        /* ... */
> +        /* Then the 25G interfaces */
> +        port60: port at 60 {
> +          reg = <60>;
> +          microchip,bandwidth = <25000>;
> +          phys = <&serdes 29>;
> +          phy-mode = "10gbase-r";
> +          sfp = <&sfp_eth60>;
> +          managed = "in-band-status";
> +          microchip,sd-sgpio = <365>;
> +        };
> +        port61: port at 61 {
> +          reg = <61>;
> +          microchip,bandwidth = <25000>;
> +          phys = <&serdes 30>;
> +          phy-mode = "10gbase-r";
> +          sfp = <&sfp_eth61>;
> +          managed = "in-band-status";
> +          microchip,sd-sgpio = <369>;
> +        };
> +        port62: port at 62 {
> +          reg = <62>;
> +          microchip,bandwidth = <25000>;
> +          phys = <&serdes 31>;
> +          phy-mode = "10gbase-r";
> +          sfp = <&sfp_eth62>;
> +          managed = "in-band-status";
> +          microchip,sd-sgpio = <373>;
> +        };
> +        port63: port at 63 {
> +          reg = <63>;
> +          microchip,bandwidth = <25000>;
> +          phys = <&serdes 32>;
> +          phy-mode = "10gbase-r";
> +          sfp = <&sfp_eth63>;
> +          managed = "in-band-status";
> +          microchip,sd-sgpio = <377>;
> +        };
> +        /* Finally the Management interface */
> +        port64: port at 64 {
> +          reg = <64>;
> +          microchip,bandwidth = <1000>;
> +          phys = <&serdes 0>;
> +          phy-handle = <&phy64>;
> +          phy-mode = "sgmii";
> +          mac-address = [ 00 00 00 01 02 03 ];
> +        };
> +      };
> +    };
> +
> +...
> +#  vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml :
> -- 
> 2.31.1
> 


From robh at kernel.org  Wed Apr 21 23:48:59 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:48:59 -0500
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to
 json schema
In-Reply-To: <CAHUa44GZenrwVWRZW6BKB8cktfXvktJ4OCF0AgPKanYGV01m5g@mail.gmail.com>
References: <20210416222518.15801-1-nm@ti.com>
 <CAHUa44GZenrwVWRZW6BKB8cktfXvktJ4OCF0AgPKanYGV01m5g@mail.gmail.com>
Message-ID: <20210421224859.GA1750844@robh.at.kernel.org>

On Tue, Apr 20, 2021 at 10:32:37AM +0200, Jens Wiklander wrote:
> On Sat, Apr 17, 2021 at 12:25 AM Nishanth Menon <nm at ti.com> wrote:
> >
> > Convert linaro,optee-tz to json schema format for better documentation
> > and error checks.
> >
> > NOTE:
> > 1. This change does introduce a stricter naming convention for
> >    optee nodes.
> > 2. We do have false positive checkpatch warning with this patch:
> >    "DT binding docs and includes should be a separate patch"
> >
> > Signed-off-by: Nishanth Menon <nm at ti.com>
> > ---
> >  .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ----------
> >  .../arm/firmware/linaro,optee-tz.yaml         | 62 +++++++++++++++++++
> >  2 files changed, 62 insertions(+), 31 deletions(-)
> >  delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> >  create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > deleted file mode 100644
> > index d38834c67dff..000000000000
> > --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > +++ /dev/null
> > @@ -1,31 +0,0 @@
> > -OP-TEE Device Tree Bindings
> > -
> > -OP-TEE is a piece of software using hardware features to provide a Trusted
> > -Execution Environment. The security can be provided with ARM TrustZone, but
> > -also by virtualization or a separate chip.
> > -
> > -We're using "linaro" as the first part of the compatible property for
> > -the reference implementation maintained by Linaro.
> > -
> > -* OP-TEE based on ARM TrustZone required properties:
> > -
> > -- compatible     : should contain "linaro,optee-tz"
> > -
> > -- method         : The method of calling the OP-TEE Trusted OS. Permitted
> > -                   values are:
> > -
> > -                   "smc" : SMC #0, with the register assignments specified
> > -                          in drivers/tee/optee/optee_smc.h
> > -
> > -                   "hvc" : HVC #0, with the register assignments specified
> > -                          in drivers/tee/optee/optee_smc.h
> > -
> > -
> > -
> > -Example:
> > -       firmware {
> > -               optee {
> > -                       compatible = "linaro,optee-tz";
> > -                       method = "smc";
> > -               };
> > -       };
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> > new file mode 100644
> > index 000000000000..6513b5ac8b2c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> > @@ -0,0 +1,62 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> 
> Are these links supposed to work?

Could possibly some day, but no. Just convention for json-schema.

Rob


From robh at kernel.org  Wed Apr 21 23:52:12 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 21 Apr 2021 17:52:12 -0500
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to
 json schema
In-Reply-To: <20210416222518.15801-1-nm@ti.com>
References: <20210416222518.15801-1-nm@ti.com>
Message-ID: <20210421225212.GB1750844@robh.at.kernel.org>

On Fri, Apr 16, 2021 at 05:25:18PM -0500, Nishanth Menon wrote:
> Convert linaro,optee-tz to json schema format for better documentation
> and error checks.
> 
> NOTE:
> 1. This change does introduce a stricter naming convention for
>    optee nodes.
> 2. We do have false positive checkpatch warning with this patch:
>    "DT binding docs and includes should be a separate patch"

Not really something that needs to be in the commit msg. I'm aware of 
the issue, just haven't gotten around to fixing it.

> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ----------
>  .../arm/firmware/linaro,optee-tz.yaml         | 62 +++++++++++++++++++
>  2 files changed, 62 insertions(+), 31 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> deleted file mode 100644
> index d38834c67dff..000000000000
> --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -OP-TEE Device Tree Bindings
> -
> -OP-TEE is a piece of software using hardware features to provide a Trusted
> -Execution Environment. The security can be provided with ARM TrustZone, but
> -also by virtualization or a separate chip.
> -
> -We're using "linaro" as the first part of the compatible property for
> -the reference implementation maintained by Linaro.
> -
> -* OP-TEE based on ARM TrustZone required properties:
> -
> -- compatible     : should contain "linaro,optee-tz"
> -
> -- method         : The method of calling the OP-TEE Trusted OS. Permitted
> -                   values are:
> -
> -                   "smc" : SMC #0, with the register assignments specified
> -		           in drivers/tee/optee/optee_smc.h
> -
> -                   "hvc" : HVC #0, with the register assignments specified
> -		           in drivers/tee/optee/optee_smc.h
> -
> -
> -
> -Example:
> -	firmware {
> -		optee {
> -			compatible = "linaro,optee-tz";
> -			method = "smc";
> -		};
> -	};
> diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> new file mode 100644
> index 000000000000..6513b5ac8b2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OP-TEE Device Tree Bindings
> +
> +maintainers:
> +  - Jens Wiklander <jens.wiklander at linaro.org>
> +
> +description: |
> +  OP-TEE is a piece of software using hardware features to provide a Trusted
> +  Execution Environment. The security can be provided with ARM TrustZone, but
> +  also by virtualization or a separate chip.
> +
> +  We're using "linaro" as the first part of the compatible property for
> +  the reference implementation maintained by Linaro.
> +
> +properties:
> +  $nodename:
> +    const: 'optee'

Don't need quotes.

> +
> +  compatible:
> +    const: linaro,optee-tz
> +
> +  method:
> +    description: The method of calling the OP-TEE Trusted OS.
> +    oneOf:
> +      - description: |
> +          SMC #0, with the register assignments specified
> +          in drivers/tee/optee/optee_smc.h
> +        items:
> +          - const: smc
> +      - description: |
> +          HVC #0, with the register assignments specified
> +          in drivers/tee/optee/optee_smc.h
> +        items:
> +          - const: hvc

Please just do 'enum: [ smc, hvc ]' and rework to a single description.

> +
> +required:
> +  - compatible
> +  - method
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    firmware  {
> +        optee  {
> +            compatible = "linaro,optee-tz";
> +            method = "smc";
> +        };
> +    };
> +
> +  - |
> +    firmware  {
> +        optee  {
> +            compatible = "linaro,optee-tz";
> +            method = "hvc";
> +        };
> +    };
> -- 
> 2.31.0
> 


From linus.walleij at linaro.org  Thu Apr 22 00:12:35 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 01:12:35 +0200
Subject: [PATCH] pinctrl: mediatek: use spin lock in mtk_rmw
In-Reply-To: <20210406144540.3467756-1-tzungbi@google.com>
References: <20210406144540.3467756-1-tzungbi@google.com>
Message-ID: <CACRpkdb6KM-smFQ9BdVQgWCNOu-4_t=g8k3_NUZ8HH0Pjr=LGg@mail.gmail.com>

On Tue, Apr 6, 2021 at 4:46 PM Tzung-Bi Shih <tzungbi at google.com> wrote:

> Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
> mutex lock in mtk_rmw.  However the function is possible called from
> atomic context.
>
> For example call trace:
>   mutex_lock+0x28/0x64
>   mtk_rmw+0x38/0x80
>   mtk_hw_set_value+0x100/0x138
>   mtk_gpio_set+0x48/0x58
>   gpiod_set_raw_value_commit+0xf4/0x110
>   gpiod_set_value_nocheck+0x4c/0x80
>   gpiod_set_value+0x4c/0x6c
>   max98357a_daiops_trigger+0x8c/0x9c
>   soc_pcm_trigger+0x5c/0x10c
>
> The max98357a_daiops_trigger() could run in either atomic or non-atomic
> context.  As a result, dmesg shows some similar messages: "BUG: sleeping
> function called from invalid context at kernel/locking/mutex.c:254".
>
> Uses spin lock in mtk_rmw instead.
>
> Fixes: 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.")
> Signed-off-by: Tzung-Bi Shih <tzungbi at google.com>

Patch applied.

Yours,
Linus Walleij


From lkp at intel.com  Thu Apr 22 00:22:39 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 07:22:39 +0800
Subject: [xlnx:master 11970/12130] drivers/i2c/busses/i2c-xiic.c:1134:39:
 warning: unused variable 'xiic_2_00'
Message-ID: <202104220733.vryZ63ES-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: 744f0aee09df06bac9b5c440da65697b2278b9ee [11970/12130] i2c: xiic: Switch to Xiic standard mode for i2c-read
config: x86_64-randconfig-a015-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/744f0aee09df06bac9b5c440da65697b2278b9ee
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 744f0aee09df06bac9b5c440da65697b2278b9ee
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/i2c/busses/i2c-xiic.c:1134:39: warning: unused variable 'xiic_2_00' [-Wunused-const-variable]
   static const struct xiic_version_data xiic_2_00 = {
                                         ^
   1 warning generated.


vim +/xiic_2_00 +1134 drivers/i2c/busses/i2c-xiic.c

  1133	
> 1134	static const struct xiic_version_data xiic_2_00 = {
  1135		.quirks = DYNAMIC_MODE_READ_BROKEN_BIT,
  1136	};
  1137	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37984 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/1d38edee/attachment-0001.gz>

From digetx at gmail.com  Thu Apr 22 00:33:25 2021
From: digetx at gmail.com (Dmitry Osipenko)
Date: Thu, 22 Apr 2021 02:33:25 +0300
Subject: [PATCH 06/10] memory: tegra: Parameterize interrupt handler
In-Reply-To: <20210420165237.3523732-7-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-7-thierry.reding@gmail.com>
Message-ID: <c0f7359c-4633-986e-be2e-63d47384df11@gmail.com>

20.04.2021 19:52, Thierry Reding ?????:
> +const char *const status_names[32] = {
> +	[ 1] = "External interrupt",
> +	[ 6] = "EMEM address decode error",
> +	[ 7] = "GART page fault",
> +	[ 8] = "Security violation",
> +	[ 9] = "EMEM arbitration error",
> +	[10] = "Page fault",
> +	[11] = "Invalid APB ASID update",
> +	[12] = "VPR violation",
> +	[13] = "Secure carveout violation",
> +	[16] = "MTS carveout violation",
> +};
>  
> -	return IRQ_HANDLED;
> -}
> +const char *const error_names[8] = {
> +	[2] = "EMEM decode error",
> +	[3] = "TrustZone violation",
> +	[4] = "Carveout violation",
> +	[6] = "SMMU translation error",
> +};
>  

These struct names are too generic for a global names, what about
prefixing them with tegra_mc_ ?


From linus.walleij at linaro.org  Thu Apr 22 00:51:46 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 01:51:46 +0200
Subject: [PATCH v4 0/4] Mediatek pinctrl patch on mt8195
In-Reply-To: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
Message-ID: <CACRpkdYtjG3LbcMiHmODggWRecSWGSm34vpEtti9x9SKdV9_BA@mail.gmail.com>

On Tue, Apr 13, 2021 at 7:57 AM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:

> This series includes 4 patches:
> 1.add pinctrl file and inding document on mt8195.
> 2.add pinctrl driver on MT8195.
> 3.add pinctrl drive for I2C related pins on MT8195.
> 4.add pinctrl rsel setting on MT8195.
>
> Changes in patch v4:

Patches 1, 2 & 3 applied!

Now you only need to resend patch 4.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 22 00:54:03 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 01:54:03 +0200
Subject: [PATCH v2] pinctrl: mediatek: use spin lock in mtk_rmw
In-Reply-To: <20210419093449.3125704-1-tzungbi@google.com>
References: <20210419093449.3125704-1-tzungbi@google.com>
Message-ID: <CACRpkdbhTbskkxkVo4Jw2=KDapytqw=QJ4kmRtqk=bHhgKUpGg@mail.gmail.com>

On Mon, Apr 19, 2021 at 11:35 AM Tzung-Bi Shih <tzungbi at google.com> wrote:

> Commit 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.") uses
> mutex lock in mtk_rmw.  However the function is possible called from
> atomic context.
>
> For example call trace:
>   mutex_lock+0x28/0x64
>   mtk_rmw+0x38/0x80
>   [snip]
>   max98357a_daiops_trigger+0x8c/0x9c
>   soc_pcm_trigger+0x5c/0x10c
>
> The max98357a_daiops_trigger() could run in either atomic or non-atomic
> context.  As a result, dmesg shows some similar messages: "BUG: sleeping
> function called from invalid context at kernel/locking/mutex.c:254".
>
> Uses spin lock in mtk_rmw instead.
>
> Fixes: 42a46434e9b1 ("pinctrl: add lock in mtk_rmw function.")
> Signed-off-by: Tzung-Bi Shih <tzungbi at google.com>

Pulled out v1 and applied this v2 instead, thanks!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 22 01:00:34 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 02:00:34 +0200
Subject: [PATCH v5 0/3] Add ZynqMP pinctrl driver
In-Reply-To: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1618485193-5403-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <CACRpkdZie6KTqhRJTr14R5KA7hUXUqjiwgO2Am5-gZHN+Je-Gw@mail.gmail.com>

On Thu, Apr 15, 2021 at 1:15 PM Sai Krishna Potthuri
<lakshmi.sai.krishna.potthuri at xilinx.com> wrote:

> Add support for Xilinx ZynqMP pinctrl driver and also update
> the Xilinx firmware driver to support pinctrl functionality.
> This driver queries the pin information from the firmware and
> allow configuring the pins as per the request.
>
> changes in v5:

v5 looks fine but does not apply to my tree, I applied patch 2
(the DT binding) as that is pretty much stand-alone though,
why not.

Please rebase the code on my "devel" branch in the pinctrl
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel
and resend.

Yours,
Linus Walleij


From gshan at redhat.com  Thu Apr 22 03:02:00 2021
From: gshan at redhat.com (Gavin Shan)
Date: Thu, 22 Apr 2021 12:02:00 +1000
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <871rb3rgpl.wl-maz@kernel.org>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
Message-ID: <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>

Hi Marc,

On 4/21/21 9:59 PM, Marc Zyngier wrote:
> On Wed, 21 Apr 2021 07:17:44 +0100,
> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>> On 2021/4/21 14:20, Gavin Shan wrote:
>>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
>>>> On 2020/10/22 0:16, Santosh Shukla wrote:
>>>>> The Commit:6d674e28 introduces a notion to detect and handle the
>>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
>>>>> in vma->flags and if set then marks force_pte to true such that
>>>>> if force_pte is true then ignore the THP function check
>>>>> (/transparent_hugepage_adjust()).
>>>>>
>>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
>>>>> For example consider a case where the mdev vendor driver register's
>>>>> the vma_fault handler named vma_mmio_fault(), which maps the
>>>>> host MMIO region in-turn calls remap_pfn_range() and maps
>>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>>>>> the VM_PFNMAP flag into vma->flags.
>>>> Could you give the name of the mdev vendor driver that triggers this issue?
>>>> I failed to find one according to your description. Thanks.
>>>>
>>>
>>> I think it would be fixed in driver side to set VM_PFNMAP in
>>> its mmap() callback (call_mmap()), like vfio PCI driver does.
>>> It means it won't be delayed until page fault is issued and
>>> remap_pfn_range() is called. It's determined from the beginning
>>> that the vma associated the mdev vendor driver is serving as
>>> PFN remapping purpose. So the vma should be populated completely,
>>> including the VM_PFNMAP flag before it becomes visible to user
>>> space.
> 
> Why should that be a requirement? Lazy populating of the VMA should be
> perfectly acceptable if the fault can only happen on the CPU side.
> 

It isn't a requirement and the drivers needn't follow strictly. I checked
several drivers before looking into the patch and found almost all the
drivers have VM_PFNMAP set at mmap() time. In drivers/vfio/vfio-pci.c,
there is a comment as below, but it doesn't reveal too much about why
we can't set VM_PFNMAP at fault time.

static int vfio_pci_mmap(void *device_data, 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.
          */
         vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
         vma->vm_ops = &vfio_pci_mmap_ops;

         return 0;
}

To set these flags in advance does have advantages. For example, VM_DONTEXPAND
prevents the vma to be merged with another one. VM_DONTDUMP make this vma
isn't eligible for coredump. Otherwise, the address space, which is associated
with the vma is accessed and unnecessary page faults are triggered on coredump.
VM_IO and VM_PFNMAP avoids to walk the page frames associated with the vma since
we don't have valid PFN in the mapping.

>>>
>>> The example can be found from vfio driver in drivers/vfio/pci/vfio_pci.c:
>>>      vfio_pci_mmap:       VM_PFNMAP is set for the vma
>>>      vfio_pci_mmap_fault: remap_pfn_range() is called
>> Right. I have discussed the above with Marc. I want to find the driver
>> to fix it. However, AFAICS, there is no driver matches the description...
> 
> I have the feeling this is an out-of-tree driver (and Santosh email
> address is bouncing, so I guess we won't have much information from
> him).
> 
> However, the simple fact that any odd driver can provide a fault
> handler and populate it the VMA on demand makes me think that we need
> to support this case.
> 

Yeah, Santosh's email isn't reachable. I think the VM_PFNMAP need to be
rechecked after gup if we're going to support this case.

Thanks,
Gavin



From linus.walleij at linaro.org  Thu Apr 22 01:03:37 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 02:03:37 +0200
Subject: [PATCH v1 1/3] pinctrl: Keep enum pin_config_param ordered by name
In-Reply-To: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
References: <20210412140741.39946-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CACRpkdbGsnkFa13O2pPSQaSR3aCZa=iXC19MNgv8is4-Wc3BxA@mail.gmail.com>

On Mon, Apr 12, 2021 at 4:07 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:

> It seems the ordering is by name. Keep it that way.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

Patches applied, nice spring cleaning so why not!

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Apr 22 01:04:31 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 02:04:31 +0200
Subject: [PATCH v2 2/3] ARM: dts: rockchip: change gpio nodenames
In-Reply-To: <20210412223617.8634-2-jbx6244@gmail.com>
References: <20210412223617.8634-1-jbx6244@gmail.com>
 <20210412223617.8634-2-jbx6244@gmail.com>
Message-ID: <CACRpkdYv2vmFgFaEbQhRUGJ60oGYMdy+Zsbkg+0CQKonRp=7Ew@mail.gmail.com>

On Tue, Apr 13, 2021 at 12:36 AM Johan Jonker <jbx6244 at gmail.com> wrote:

> Currently all gpio nodenames are sort of identical to there label.
> Nodenames should be of a generic type, so change them all.
>
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From digetx at gmail.com  Thu Apr 22 01:06:18 2021
From: digetx at gmail.com (Dmitry Osipenko)
Date: Thu, 22 Apr 2021 03:06:18 +0300
Subject: [PATCH 03/10] memory: tegra: Push suspend/resume into SoC drivers
In-Reply-To: <20210420165237.3523732-4-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-4-thierry.reding@gmail.com>
Message-ID: <2a45a732-ff93-84f0-edf2-f9aa2e1504e6@gmail.com>

20.04.2021 19:52, Thierry Reding ?????:
> -static int tegra_mc_suspend(struct device *dev)
> +static int __maybe_unused tegra_mc_suspend(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
> -	int err;
>  
> -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> -		err = tegra_gart_suspend(mc->gart);
> -		if (err)
> -			return err;
> -	}
> +	if (mc->soc->ops && mc->soc->ops->suspend)
> +		return mc->soc->ops->suspend(mc);
>  
>  	return 0;
>  }
>  
> -static int tegra_mc_resume(struct device *dev)
> +static int __maybe_unused tegra_mc_resume(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
> -	int err;
>  
> -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> -		err = tegra_gart_resume(mc->gart);
> -		if (err)
> -			return err;
> -	}
> +	if (mc->soc->ops && mc->soc->ops->resume)
> +		return mc->soc->ops->resume(mc);
>  
>  	return 0;
>  }

You added __maybe_unused, but haven't changed tegra_mc_pm_ops to use
SET_SYSTEM_SLEEP_PM_OPS(), so the functions are always used.


From gshan at redhat.com  Thu Apr 22 03:12:10 2021
From: gshan at redhat.com (Gavin Shan)
Date: Thu, 22 Apr 2021 12:12:10 +1000
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
 <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
 <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>
Message-ID: <f13bfc39-bee6-4562-fefc-76051bbf9735@redhat.com>

Hi Keqian,

On 4/21/21 4:28 PM, Keqian Zhu wrote:
> On 2021/4/21 14:38, Gavin Shan wrote:
>> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>>> The MMIO regions may be unmapped for many reasons and can be remapped
>>> by stage2 fault path. Map MMIO regions at creation time becomes a
>>> minor optimization and makes these two mapping path hard to sync.
>>>
>>> Remove the mapping code while keep the useful sanity check.
>>>
>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>> ---
>>>    arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
>>>    1 file changed, 3 insertions(+), 35 deletions(-)
>>>
>>
>> After removing the logic to create stage2 mapping for VM_PFNMAP region,
>> I think the "do { } while" loop becomes unnecessary and can be dropped
>> completely. It means the only sanity check is to see if the memory slot
>> overflows IPA space or not. In that case, KVM_MR_FLAGS_ONLY can be
>> ignored because the memory slot's base address and length aren't changed
>> when we have KVM_MR_FLAGS_ONLY.
> Maybe not exactly. Here we do an important sanity check that we shouldn't
> log dirty for memslots with VM_PFNMAP.
> 

Yeah, Sorry that I missed that part. Something associated with Santosh's
patch. The flag can be not existing until the page fault happened on
the vma. In this case, the check could be not working properly.

   [PATCH] KVM: arm64: Correctly handle the mmio faulting

[...]

Thanks,
Gavin

>>
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 8711894db8c2..c59af5ca01b0 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>>    {
>>>        hva_t hva = mem->userspace_addr;
>>>        hva_t reg_end = hva + mem->memory_size;
>>> -    bool writable = !(mem->flags & KVM_MEM_READONLY);
>>>        int ret = 0;
>>>          if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
>>> @@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>>        mmap_read_lock(current->mm);
>>>        /*
>>>         * A memory region could potentially cover multiple VMAs, and any holes
>>> -     * between them, so iterate over all of them to find out if we can map
>>> -     * any of them right now.
>>> +     * between them, so iterate over all of them.
>>>         *
>>>         *     +--------------------------------------------+
>>>         * +---------------+----------------+   +----------------+
>>> @@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>>>         */
>>>        do {
>>>            struct vm_area_struct *vma = find_vma(current->mm, hva);
>>> -        hva_t vm_start, vm_end;
>>>              if (!vma || vma->vm_start >= reg_end)
>>>                break;
>>>    -        /*
>>> -         * Take the intersection of this VMA with the memory region
>>> -         */
>>> -        vm_start = max(hva, vma->vm_start);
>>> -        vm_end = min(reg_end, vma->vm_end);
>>> -
>>>            if (vma->vm_flags & VM_PFNMAP) {
>>> -            gpa_t gpa = mem->guest_phys_addr +
>>> -                    (vm_start - mem->userspace_addr);
>>> -            phys_addr_t pa;
>>> -
>>> -            pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
>>> -            pa += vm_start - vma->vm_start;
>>> -
>>>                /* IO region dirty page logging not allowed */
>>>                if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
>>>                    ret = -EINVAL;
>>> -                goto out;
>>> -            }
>>> -
>>> -            ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
>>> -                            vm_end - vm_start,
>>> -                            writable);
>>> -            if (ret)
>>>                    break;
>>> +            }
>>>            }
>>> -        hva = vm_end;
>>> +        hva = min(reg_end, vma->vm_end);
>>>        } while (hva < reg_end);
>>>    -    if (change == KVM_MR_FLAGS_ONLY)
>>> -        goto out;
>>> -
>>> -    spin_lock(&kvm->mmu_lock);
>>> -    if (ret)
>>> -        unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
>>> -    else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
>>> -        stage2_flush_memslot(kvm, memslot);
>>> -    spin_unlock(&kvm->mmu_lock);
>>> -out:
>>>        mmap_read_unlock(current->mm);
>>>        return ret;
>>>    }
>>>
>>
>> .
>>
> 



From gshan at redhat.com  Thu Apr 22 03:25:23 2021
From: gshan at redhat.com (Gavin Shan)
Date: Thu, 22 Apr 2021 12:25:23 +1000
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <105a403a-e48b-15bc-44ff-0ff34f7d2194@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>
 <105a403a-e48b-15bc-44ff-0ff34f7d2194@huawei.com>
Message-ID: <46606f3e-ef41-6520-6647-88c0f76a83e0@redhat.com>

Hi Keqian,

On 4/21/21 4:36 PM, Keqian Zhu wrote:
> On 2021/4/21 15:52, Gavin Shan wrote:
>> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>>> The MMIO region of a device maybe huge (GB level), try to use
>>> block mapping in stage2 to speedup both map and unmap.
>>>
>>> Compared to normal memory mapping, we should consider two more
>>> points when try block mapping for MMIO region:
>>>
>>> 1. For normal memory mapping, the PA(host physical address) and
>>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>>> the HVA to request hugepage, so we don't need to consider PA
>>> alignment when verifing block mapping. But for device memory
>>> mapping, the PA and HVA may have different alignment.
>>>
>>> 2. For normal memory mapping, we are sure hugepage size properly
>>> fit into vma, so we don't check whether the mapping size exceeds
>>> the boundary of vma. But for device memory mapping, we should pay
>>> attention to this.
>>>
>>> This adds get_vma_page_shift() to get page shift for both normal
>>> memory and device MMIO region, and check these two points when
>>> selecting block mapping size for MMIO region.
>>>
>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>> ---
>>>    arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>>>    1 file changed, 51 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index c59af5ca01b0..5a1cc7751e6d 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>>>        return PAGE_SIZE;
>>>    }
>>>    +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
>>> +{
>>> +    unsigned long pa;
>>> +
>>> +    if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
>>> +        return huge_page_shift(hstate_vma(vma));
>>> +
>>> +    if (!(vma->vm_flags & VM_PFNMAP))
>>> +        return PAGE_SHIFT;
>>> +
>>> +    VM_BUG_ON(is_vm_hugetlb_page(vma));
>>> +
>>
>> I don't understand how VM_PFNMAP is set for hugetlbfs related vma.
>> I think they are exclusive, meaning the flag is never set for
>> hugetlbfs vma. If it's true, VM_PFNMAP needn't be checked on hugetlbfs
>> vma and the VM_BUG_ON() becomes unnecessary.
> Yes, but we're not sure all drivers follow this rule. Add a BUG_ON() is
> a way to catch issue.
> 

I think I didn't make things clear. What I meant is VM_PFNMAP can't
be set for hugetlbfs VMAs. So the checks here can be simplified as
below if you agree:

     if (is_vm_hugetlb_page(vma))
         return huge_page_shift(hstate_vma(vma));

     if (!(vma->vm_flags & VM_PFNMAP))
         return PAGE_SHIFT;

     VM_BUG_ON(is_vm_hugetlb_page(vma));       /* Can be dropped */

>>
>>> +    pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>>> +
>>> +#ifndef __PAGETABLE_PMD_FOLDED
>>> +    if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>>> +        ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
>>> +        ALIGN(hva, PUD_SIZE) <= vma->vm_end)
>>> +        return PUD_SHIFT;
>>> +#endif
>>> +
>>> +    if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>>> +        ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
>>> +        ALIGN(hva, PMD_SIZE) <= vma->vm_end)
>>> +        return PMD_SHIFT;
>>> +
>>> +    return PAGE_SHIFT;
>>> +}
>>> +
>>
>> There is "switch(...)" fallback mechanism in user_mem_abort(). PUD_SIZE/PMD_SIZE
>> can be downgraded accordingly if the addresses fails in the alignment check
>> by fault_supports_stage2_huge_mapping(). I think it would make user_mem_abort()
>> simplified if the logic can be moved to get_vma_page_shift().
>>
>> Another question if we need the check from fault_supports_stage2_huge_mapping()
>> if VM_PFNMAP area is going to be covered by block mapping. If so, the "switch(...)"
>> fallback mechanism needs to be part of get_vma_page_shift().
> Yes, Good suggestion. My idea is that we can keep this series simpler and do further
> optimization in another patch series. Do you mind to send a patch?
> 

Yeah, It's fine to keep this series as of being. There are 3 checks applied
here for MMIO region: hva/hpa/ipa and they're distributed in two functions,
making the code a bit hard to follow. I can post patch to simplify it after
your series gets merged :)

Thanks,
Gavin



From lkp at intel.com  Thu Apr 22 02:31:28 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 09:31:28 +0800
Subject: [xlnx:master 10656/12130] drivers/misc/xilinx_flex_pm.c:235:10:
 error: too many arguments to function 'zynqmp_pm_probe_counter_write'
Message-ID: <202104220923.fVZmHV2p-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: 4700c4290e778cd3547e1240e1e9562e8197a2fc [10656/12130] misc: xilinx_flex: Add support for the flex noc Performance Monitor
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/4700c4290e778cd3547e1240e1e9562e8197a2fc
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 4700c4290e778cd3547e1240e1e9562e8197a2fc
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/misc/xilinx_flex_pm.c: In function 'xflex_sysfs_cmd':
>> drivers/misc/xilinx_flex_pm.c:235:10: error: too many arguments to function 'zynqmp_pm_probe_counter_write'
     235 |    ret = zynqmp_pm_probe_counter_write(domain, reg, val);
         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   In file included from drivers/misc/xilinx_flex_pm.c:7:
   include/linux/firmware/xlnx-zynqmp.h:914:19: note: declared here
     914 | static inline int zynqmp_pm_probe_counter_write(u32 reg, u32 value)
         |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/misc/xilinx_flex_pm.c:252:10: error: too many arguments to function 'zynqmp_pm_probe_counter_write'
     252 |    ret = zynqmp_pm_probe_counter_write(domain, reg, val);
         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   In file included from drivers/misc/xilinx_flex_pm.c:7:
   include/linux/firmware/xlnx-zynqmp.h:914:19: note: declared here
     914 | static inline int zynqmp_pm_probe_counter_write(u32 reg, u32 value)
         |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for MFD_CORE
   Depends on HAS_IOMEM
   Selected by
   - MFD_HI6421_SPMI && STAGING && OF && SPMI


vim +/zynqmp_pm_probe_counter_write +235 drivers/misc/xilinx_flex_pm.c

   152	
   153	/**
   154	 * xflex_sysfs_cmd - Implements sysfs operations
   155	 * @dev: Device structure
   156	 * @buf: Value to write
   157	 * @cmd: sysfs cmd
   158	 *
   159	 * Return: value read from the sysfs cmd on success and negative error code
   160	 *		otherwise.
   161	 */
   162	static int xflex_sysfs_cmd(struct device *dev, const char *buf,
   163				   enum xflex_sysfs_cmd_codes cmd)
   164	{
   165		struct xflex_dev_info *flexpm = to_xflex_dev_info(dev);
   166		u32 domain, src, offset, reg, val, counter;
   167		int ret;
   168		u32 pm_api_ret[4] = {0, 0, 0, 0};
   169	
   170		mutex_lock(&flexpm->mutex);
   171	
   172		switch (cmd) {
   173		case XFLEX_GET_COUNTER_LPD_WRRSP:
   174			reg = flexpm->counterid_lpd | FPM_WRRSP_L | FPM_VAL;
   175			domain = FPM_LPD;
   176	
   177			break;
   178	
   179		case XFLEX_GET_COUNTER_LPD_WRREQ:
   180			reg = flexpm->counterid_lpd | FPM_WRRSP_L | FPM_VAL;
   181			domain = FPM_LPD;
   182	
   183			break;
   184	
   185		case XFLEX_GET_COUNTER_LPD_RDRSP:
   186			reg = flexpm->counterid_lpd | FPM_RDRSP_L | FPM_VAL;
   187			domain = FPM_LPD;
   188	
   189			break;
   190	
   191		case XFLEX_GET_COUNTER_LPD_RDREQ:
   192			reg = flexpm->counterid_lpd | FPM_RDREQ_L | FPM_VAL;
   193			domain = FPM_LPD;
   194	
   195			break;
   196	
   197		case XFLEX_SET_COUNTER_LPD:
   198			ret = kstrtou32(buf, 0, &val);
   199			if (ret < 0)
   200				goto exit_unlock;
   201	
   202			flexpm->counterid_lpd = val;
   203			reset_default(dev, val, FPM_LPD);
   204			break;
   205	
   206		case XFLEX_SET_PORT_COUNTER_FPD:
   207			ret = kstrtou32(buf, 0, &val);
   208			if (ret < 0)
   209				goto exit_unlock;
   210	
   211			counter = flexpm->counterid_fpd * FPM_COUNTER_OFFSET;
   212			offset = FPM_PORT_SEL_OFFSET + counter * FPM_COUNTER_OFFSET;
   213			fpm_reg(flexpm->basefpd, val, offset);
   214			break;
   215	
   216		case XFLEX_SET_PORT_COUNTER_LPD:
   217			ret = kstrtou32(buf, 0, &val);
   218			if (ret < 0)
   219				goto exit_unlock;
   220	
   221			counter = flexpm->counterid_lpd * FPM_COUNTER_OFFSET;
   222			offset = FPM_PORT_SEL_OFFSET + counter * FPM_COUNTER_OFFSET;
   223			fpm_reg(flexpm->baselpd, val, offset);
   224			break;
   225	
   226		case XFLEX_SET_SRC_COUNTER_LPD:
   227			reg = flexpm->counterid_lpd;
   228			domain = FPM_LPD;
   229			ret = kstrtou32(buf, 0, &val);
   230			if (ret < 0)
   231				goto exit_unlock;
   232	
   233			for (src = 0; src < FPM_NUM_COUNTERS; src++) {
   234				reg = reg | FPM_SRC | (src << FPM_PROBE_SHIFT);
 > 235				ret = zynqmp_pm_probe_counter_write(domain, reg, val);
   236				if (ret < 0) {
   237					dev_err(dev, "Counter write error %d\n", ret);
   238					goto exit_unlock;
   239				}
   240			}
   241			break;
   242	
   243		case XFLEX_SET_SRC_COUNTER_FPD:
   244			reg = flexpm->counterid_fpd;
   245			domain = FPM_FPD;
   246			ret = kstrtou32(buf, 0, &val);
   247			if (ret < 0)
   248				goto exit_unlock;
   249	
   250			for (src = 0; src < FPM_NUM_COUNTERS; src++) {
   251				reg = reg | FPM_SRC | (src << FPM_PROBE_SHIFT);
   252				ret = zynqmp_pm_probe_counter_write(domain, reg, val);
   253				if (ret < 0) {
   254					dev_err(dev, "Counter write error %d\n", ret);
   255					goto exit_unlock;
   256				}
   257			}
   258			break;
   259	
   260		case XFLEX_SET_COUNTER_FPD:
   261			ret = kstrtou32(buf, 0, &val);
   262			if (ret < 0)
   263				goto exit_unlock;
   264	
   265			flexpm->counterid_fpd = val;
   266			reset_default(dev, val, FPM_FPD);
   267			break;
   268	
   269		case XFLEX_GET_COUNTER_FPD_WRRSP:
   270			reg = flexpm->counterid_fpd | FPM_WRRSP_L | FPM_VAL;
   271			domain = FPM_FPD;
   272	
   273			break;
   274	
   275		case XFLEX_GET_COUNTER_FPD_WRREQ:
   276			reg = flexpm->counterid_fpd | FPM_WRREQ_L | FPM_VAL;
   277			domain = FPM_FPD;
   278	
   279			break;
   280	
   281		case XFLEX_GET_COUNTER_FPD_RDRSP:
   282			reg = flexpm->counterid_fpd | FPM_RDRSP_L | FPM_VAL;
   283			domain = FPM_FPD;
   284	
   285			break;
   286	
   287		case XFLEX_GET_COUNTER_FPD_RDREQ:
   288			reg = flexpm->counterid_fpd | FPM_RDREQ_L | FPM_VAL;
   289			domain = FPM_FPD;
   290	
   291			break;
   292	
   293		default:
   294			dev_err(dev, "Invalid option\n");
   295			break;
   296		}
   297	
   298		ret = zynqmp_pm_probe_counter_read(domain, reg, &pm_api_ret[0]);
   299	
   300		if (ret < 0) {
   301			dev_err(dev, "Counter read error %d\n", ret);
   302			return ret;
   303		}
   304		mutex_unlock(&flexpm->mutex);
   305		return pm_api_ret[1];
   306	
   307	exit_unlock:
   308		mutex_unlock(&flexpm->mutex);
   309		return ret;
   310	}
   311	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23475 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/9522a9d0/attachment-0001.gz>

From zhiyong.tao at mediatek.com  Thu Apr 22 02:37:39 2021
From: zhiyong.tao at mediatek.com (zhiyong tao)
Date: Thu, 22 Apr 2021 09:37:39 +0800
Subject: [PATCH v4 0/4] Mediatek pinctrl patch on mt8195
In-Reply-To: <CACRpkdYtjG3LbcMiHmODggWRecSWGSm34vpEtti9x9SKdV9_BA@mail.gmail.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <CACRpkdYtjG3LbcMiHmODggWRecSWGSm34vpEtti9x9SKdV9_BA@mail.gmail.com>
Message-ID: <1619055459.27999.0.camel@mhfsdcap03>

On Thu, 2021-04-22 at 01:51 +0200, Linus Walleij wrote:
> On Tue, Apr 13, 2021 at 7:57 AM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:
> 
> > This series includes 4 patches:
> > 1.add pinctrl file and inding document on mt8195.
> > 2.add pinctrl driver on MT8195.
> > 3.add pinctrl drive for I2C related pins on MT8195.
> > 4.add pinctrl rsel setting on MT8195.
> >
> > Changes in patch v4:
> 
> Patches 1, 2 & 3 applied!
> 
> Now you only need to resend patch 4.
> 
> Yours,
> Linus Walleij

==>Thanks for your comment. we will send only patch 4 in next version.



From zhiyong.tao at mediatek.com  Thu Apr 22 03:10:46 2021
From: zhiyong.tao at mediatek.com (zhiyong tao)
Date: Thu, 22 Apr 2021 10:10:46 +0800
Subject: [PATCH v4 4/4] pinctrl: add rsel setting on MT8195
In-Reply-To: <CAGp9LzoM=9v5mLxtAN9sQm_2f+66xc7G4YqfUF1Mwvr4K_wz5w@mail.gmail.com>
References: <20210413055702.27535-1-zhiyong.tao@mediatek.com>
 <20210413055702.27535-5-zhiyong.tao@mediatek.com>
 <CAGp9LzoM=9v5mLxtAN9sQm_2f+66xc7G4YqfUF1Mwvr4K_wz5w@mail.gmail.com>
Message-ID: <1619057446.27999.2.camel@mhfsdcap03>

On Tue, 2021-04-20 at 11:50 +0800, Sean Wang wrote:
> On Mon, Apr 12, 2021 at 10:57 PM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:
> 
> <snip>
> > @@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
> >                 else
> >                         err = -ENOTSUPP;
> >                 break;
> > +       case MTK_PIN_CONFIG_RSEL:
> > +               if (hw->soc->rsel_get)
> > +                       err = hw->soc->rsel_get(hw, desc, &ret);
> > +               else
> > +                       err = -EOPNOTSUPP;
> 
> I think that should want to be -ENOTSUPP to align other occurrences.
==>Hi sean,
Can you give me some suggestion? -ENOPARAM or -EBADTYPE?

Thanks.
> 
> > +               break;
> >         default:
> >                 err = -ENOTSUPP;
> >         }
> > @@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
> >                 else
> >                         err = -ENOTSUPP;
> >                 break;
> > +       case MTK_PIN_CONFIG_RSEL:
> > +               if (hw->soc->rsel_set)
> > +                       err = hw->soc->rsel_set(hw, desc, arg);
> > +               else
> > +                       err = -EOPNOTSUPP;
> 
> Ditto
> 
> > +               break;
> >         default:
> >                 err = -ENOTSUPP;
> >         }
> > --
> > 2.18.0
> >


From wangqing at vivo.com  Thu Apr 22 03:45:31 2021
From: wangqing at vivo.com (Wang Qing)
Date: Thu, 22 Apr 2021 10:45:31 +0800
Subject: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
References: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619059532-17805-2-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The pretimeout notification shall occur at timeout-sec/2.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

V6:
- Realize pretimeout processing through dualmode.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..ebc648b
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
 {
 	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	unsigned int timeout_interval;
 	u32 reg;
 
-	wdt_dev->timeout = timeout;
+	timeout_interval = wdt_dev->timeout = timeout;
+	/*
+	 * In dual mode, irq will be triggered at timeout/2
+	 * the real timeout occurs at timeout
+	 */
+	if (wdt_dev->pretimeout)
+		timeout_interval = wdt_dev->pretimeout = timeout/2;
 
 	/*
 	 * One bit is the value of 512 ticks
 	 * The clock has 32 KHz
 	 */
-	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
 	iowrite32(reg, wdt_base + WDT_LENGTH);
 
 	mtk_wdt_ping(wdt_dev);
@@ -239,13 +247,25 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,6 +273,14 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
@@ -267,7 +295,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +307,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+							&mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT/2;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From wangqing at vivo.com  Thu Apr 22 03:45:32 2021
From: wangqing at vivo.com (Wang Qing)
Date: Thu, 22 Apr 2021 10:45:32 +0800
Subject: [PATCH V6 2/2] doc: mtk-wdt: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
References: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619059532-17805-3-git-send-email-wangqing@vivo.com>

Add description of pre-timeout in mtk-wdt.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index e36ba60..ae57d6c
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -1,5 +1,8 @@
 Mediatek SoCs Watchdog timer
 
+The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
+before the expiry.
+
 Required properties:
 
 - compatible should contain:
-- 
2.7.4



From wangqing at vivo.com  Thu Apr 22 03:45:30 2021
From: wangqing at vivo.com (Wang Qing)
Date: Thu, 22 Apr 2021 10:45:30 +0800
Subject: [PATCH V6 0/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
Message-ID: <1619059532-17805-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.
The pretimeout notification shall occur at timeout-sec/2.

Wang Qing (2):
  watchdog: mtk: support pre-timeout when the bark irq is available
  doc: mtk-wdt: support pre-timeout when the bark irq is available

 .../devicetree/bindings/watchdog/mtk-wdt.txt       |  3 ++
 drivers/watchdog/mtk_wdt.c                         | 53 ++++++++++++++++++++--
 2 files changed, 51 insertions(+), 5 deletions(-)

-- 
2.7.4



From anshuman.khandual at arm.com  Thu Apr 22 04:04:10 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 22 Apr 2021 08:34:10 +0530
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210421130235.GC18635@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
 <fe4bb655-80bb-d142-f352-89e9c52a90c5@arm.com>
 <20210421130235.GC18635@arm.com>
Message-ID: <e7527ad1-893a-c04d-8982-f902c47fe34f@arm.com>


On 4/21/21 6:32 PM, Catalin Marinas wrote:
> On Wed, Apr 21, 2021 at 10:18:56AM +0530, Anshuman Khandual wrote:
>> On 4/20/21 3:05 PM, Catalin Marinas wrote:
>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>> index b943879c1c24..15018dc59554 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -329,7 +329,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>>>   */
>>>  #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
>>>  
>>> -#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
>>> +#if defined(CONFIG_DEBUG_VIRTUAL)
>>
>> A small nit. Should this be #ifdef CONFIG_DEBUG_VIRTUAL instead ?
> 
> Yeah, for consistency I changed it to #ifdef.
> 
>> This is
>> an user selectable config and the conditional check here does not have an
>> #elseif part either. But then there are similar such instances else where
>> on arm64 platform as well.
> 
> I'm not sure I get it. What would an #elseif need to check? We already
> have an #else block for this #ifdef.

IIUC #elif always requires a defined() construct. In such cases #if defined()
might be preferable, in order to match the subsequent #elif. The point being,
in this particular case there is no #elif which would have probably justified
a preceding #if defined() construct though #ifdef is preferred.


From linux at roeck-us.net  Thu Apr 22 04:31:21 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 21 Apr 2021 20:31:21 -0700
Subject: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <1619059532-17805-2-git-send-email-wangqing@vivo.com>
References: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
 <1619059532-17805-2-git-send-email-wangqing@vivo.com>
Message-ID: <740481ed-97e0-3439-1af2-bc54cdb28536@roeck-us.net>

On 4/21/21 7:45 PM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> When the watchdog timer expires in dual mode, an interrupt will be
> triggered first, then the timing restarts. The reset signal will be
> initiated when the timer expires again.
> 
> The pretimeout notification shall occur at timeout-sec/2.
> 
> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> 
> V3:
> - Modify the pretimeout behavior, manually reset after the pretimeout
> - is processed and wait until timeout.
> 
> V4:
> - Remove pretimeout related processing. 
> - Add dual mode control separately.
> 
> V5:
> - Fix some formatting and printing problems.
> 
> V6:
> - Realize pretimeout processing through dualmode.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 48 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..ebc648b
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>  {
>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
> +	unsigned int timeout_interval;
>  	u32 reg;
>  
> -	wdt_dev->timeout = timeout;
> +	timeout_interval = wdt_dev->timeout = timeout;
> +	/*
> +	 * In dual mode, irq will be triggered at timeout/2
> +	 * the real timeout occurs at timeout
> +	 */
> +	if (wdt_dev->pretimeout)
> +		timeout_interval = wdt_dev->pretimeout = timeout/2;

Please run checkpatch --strict and fix what it reports.
Also, there should be a set_pretimeout function to set the
pretimeout. It is ok to update it here, but it should be set
in its own function to make sure that the actual value
is reported back to userspace.

Thanks,
Guenter

>  
>  	/*
>  	 * One bit is the value of 512 ticks
>  	 * The clock has 32 KHz
>  	 */
> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>  
>  	mtk_wdt_ping(wdt_dev);
> @@ -239,13 +247,25 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	if (wdt_dev->pretimeout)
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	else
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +
> +	watchdog_notify_pretimeout(wdd);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,6 +273,14 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
> @@ -267,7 +295,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +307,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +							&mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT/2;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> 



From linux at roeck-us.net  Thu Apr 22 04:32:24 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 21 Apr 2021 20:32:24 -0700
Subject: [PATCH V6 2/2] doc: mtk-wdt: support pre-timeout when the bark
 irq is available
In-Reply-To: <1619059532-17805-3-git-send-email-wangqing@vivo.com>
References: <1619059532-17805-1-git-send-email-wangqing@vivo.com>
 <1619059532-17805-3-git-send-email-wangqing@vivo.com>
Message-ID: <c7ec61dc-ae04-6c09-ab26-d432f1d5f13a@roeck-us.net>

On 4/21/21 7:45 PM, Wang Qing wrote:
> Add description of pre-timeout in mtk-wdt.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
> index e36ba60..ae57d6c
> --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
> @@ -1,5 +1,8 @@
>  Mediatek SoCs Watchdog timer
>  
> +The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
> +before the expiry.
> +

Seems to me the interrupt should be listed as optional property.

Guenter

>  Required properties:
>  
>  - compatible should contain:
> 



From yibin.gong at nxp.com  Thu Apr 22 04:33:32 2021
From: yibin.gong at nxp.com (Robin Gong)
Date: Thu, 22 Apr 2021 03:33:32 +0000
Subject: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
In-Reply-To: <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
References: <1589881301-4143-1-git-send-email-shengjiu.wang@nxp.com>
 <0866cd8cdb0c22f0b2a6814c4dafa29202aad5f3.camel@pengutronix.de>
 <CAA+D8APhHvA39wmCayeCsAEKmOJ0n7qOQiT1tZmFHr4+yASgTw@mail.gmail.com>
 <53258cd99caaf1199036737f8fad6cc097939567.camel@pengutronix.de>
 <VE1PR04MB66387217EDE5133FD2D8F793894E9@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <50ef17a2d57b022c48bbca71fd4e074cc3ca9be5.camel@pengutronix.de>
 <VE1PR04MB6638EE85485768351755557B89499@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <97262466d537402ad4032098ef277d6d47734f1f.camel@pengutronix.de>
 <VE1PR04MB6638659EC8557D01861042B189489@VE1PR04MB6638.eurprd04.prod.outlook.com>
 <d8d084aa7ff183e2f78128a46a0ce5241f357c9a.camel@pengutronix.de>
 <VE1PR04MB66887C731E32BDBB340B044C89479@VE1PR04MB6688.eurprd04.prod.outlook.com>
 <18fbdc4bf0574a722134400ad9e4510d3cbcb767.camel@pengutronix.de>
Message-ID: <VE1PR04MB6688F1C65295C1A0D689C5A289469@VE1PR04MB6688.eurprd04.prod.outlook.com>

On 2021/04/22 Lucas Stach <l.stach at pengutronix.de> wrote:
> > But the timer of runtime_auto_suspend decide when enter runtime
> > suspend rather than hardware, while transfer data size and transfer
> > rate on IP bus decide when the dma interrupt happen.
> >
> But it isn't the hardware that decides to drop the rpm refcount to 0 and
> starting the autosuspend timer, it's the driver.
Yes, driver should keep rpm refcount never to 0 in such case. But I think that case
Is a common case in dma cyclic with runtime_auto_suspend, so some dma driver
also add pm_runtime_get_sync/ pm_runtime_put_autosuspend in interrupt handler
like qcom/bam_dma.c for safe rather than only pm_runtime_mark_last_busy().

> 
> >  Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/
> > pm_runtime_mark_last_busy in interrupt handler to hope the
> > runtime_auto_suspend timer expiry later than interrupt coming, but if
> > the transfer data size is larger in cyclic and transfer rate is very
> > slow like 115200 or lower on uart, the fix autosuspend timer
> > 100ms/200ms maybe not enough, hence, runtime suspend may execute
> > meanwhile the dma interrupt maybe triggered and caught by GIC(but
> > interrupt handler prevent by spin_lock_irqsave in pm_suspend_timer_fn() ),
> and then interrupt handler start to run after runtime suspend.
> 
> If your driver code drops the rpm refcount to 0 and starts the autosuspend
> timer while a cyclic transfer is still in flight this is clearly a bug. Autosuspend is
> not there to paper over driver bugs, but to amortize cost of actually
> suspending and resuming the hardware. Your driver code must still work even
> if the timeout is 0, i.e. the hardware is immediately suspended after you drop
> the rpm refcount to 0.
> 
> If you still have transfers queued/in-flight the driver code must keep a rpm
> reference.
Yes, that's what I said for fix before as below.
'I have a simple workaround that disable runtime suspend in issue_pending worker by
calling pm_runtime_forbid() and then enable runtime auto suspend in dmaengine_terminate_all
so that we could easily regard that edma channel is always in runtime resume between
issue_pending and channel terminated and ignore the above interrupt handler/scu-pd limitation' 





From zhiyong.tao at mediatek.com  Thu Apr 22 04:35:58 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Thu, 22 Apr 2021 11:35:58 +0800
Subject: [PATCH v5 0/1] Mediatek pinctrl patch on mt8195 
Message-ID: <20210422033559.29700-1-zhiyong.tao@mediatek.com>

This series includes 1 patches:
1.add pinctrl rsel setting on MT8195.

Changes in patch v5:
1)document and driver patches are applied.
2)change '-EOPNOTSUPP' to '-ENOTSUPP'

Changes in patch v4:
1)fix pinctrl-mt8195.yaml warning error.
2)remove pinctrl device node patch which is based on "mt8195.dtsi".

Changes in patch v3:
1)change '^pins' to '-pins$'.
2)change 'state_0_node_a' to 'gpio_pin' which is defined in dts.
3)change 'state_0_node_b' to 'i2c0_pin' which is defined in dts.
4)reorder this series patches. change pinctrl file and binding document
together in one patch.

There are no changes in v1 & v2.

Zhiyong Tao (1):
  pinctrl: add rsel setting on MT8195

 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

--
2.18.0


From zhiyong.tao at mediatek.com  Thu Apr 22 04:35:59 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Thu, 22 Apr 2021 11:35:59 +0800
Subject: [PATCH v5] pinctrl: add rsel setting on MT8195
In-Reply-To: <20210422033559.29700-1-zhiyong.tao@mediatek.com>
References: <20210422033559.29700-1-zhiyong.tao@mediatek.com>
Message-ID: <20210422033559.29700-2-zhiyong.tao@mediatek.com>

This patch provides rsel setting on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index a7500e18bb1d..66608b8d346a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
 	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_rsel_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x0c0, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x0c0, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x0c0, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x0c0, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x0c0, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x0c0, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x0c0, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x0c0, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x0c0, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x0c0, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x080, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x080, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x0e0, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x0e0, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x0e0, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x0e0, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -793,6 +812,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
 	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
+	[PINCTRL_PIN_REG_RSEL] = MTK_RANGE(mt8195_pin_rsel_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -823,6 +843,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.drive_get = mtk_pinconf_drive_get_rev1,
 	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
 	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
+	.rsel_set = mtk_pinconf_rsel_set,
+	.rsel_get = mtk_pinconf_rsel_get,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 2b51f4a9b860..d1526d0c6248 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1041,6 +1041,20 @@ int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_RSEL, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_set);
+
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_RSEL, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_get);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fd5ce9c5dcbd..570e8da7bf38 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -67,6 +67,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
 	PINCTRL_PIN_REG_DRV_ADV,
+	PINCTRL_PIN_REG_RSEL,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -237,6 +238,10 @@ struct mtk_pin_soc {
 			     const struct mtk_pin_desc *desc, u32 arg);
 	int (*adv_drive_get)(struct mtk_pinctrl *hw,
 			     const struct mtk_pin_desc *desc, u32 *val);
+	int (*rsel_set)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 arg);
+	int (*rsel_get)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 *val);
 
 	/* Specific driver data */
 	void				*driver_data;
@@ -320,5 +325,10 @@ int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
 int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 				  const struct mtk_pin_desc *desc, u32 *val);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val);
+
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..392fdfcb5b87 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -22,6 +22,8 @@
 #define MTK_PIN_CONFIG_PU_ADV	(PIN_CONFIG_END + 3)
 #define MTK_PIN_CONFIG_PD_ADV	(PIN_CONFIG_END + 4)
 #define MTK_PIN_CONFIG_DRV_ADV	(PIN_CONFIG_END + 5)
+#define MTK_PIN_CONFIG_RSEL	(PIN_CONFIG_END + 6)
+
 
 static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,tdsel",	MTK_PIN_CONFIG_TDSEL,		0},
@@ -29,6 +31,7 @@ static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,pull-up-adv", MTK_PIN_CONFIG_PU_ADV,		1},
 	{"mediatek,pull-down-adv", MTK_PIN_CONFIG_PD_ADV,	1},
 	{"mediatek,drive-strength-adv", MTK_PIN_CONFIG_DRV_ADV,	2},
+	{"mediatek,rsel",		MTK_PIN_CONFIG_RSEL,	2},
 };
 
 #ifdef CONFIG_DEBUG_FS
@@ -38,6 +41,7 @@ static const struct pin_config_item mtk_conf_items[] = {
 	PCONFDUMP(MTK_PIN_CONFIG_PU_ADV, "pu-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_PD_ADV, "pd-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_DRV_ADV, "drive-strength-adv", NULL, true),
+	PCONFDUMP(MTK_PIN_CONFIG_RSEL, "rsel", NULL, true),
 };
 #endif
 
@@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_get)
+			err = hw->soc->rsel_get(hw, desc, &ret);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
@@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_set)
+			err = hw->soc->rsel_set(hw, desc, arg);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
-- 
2.18.0

From wangqing at vivo.com  Thu Apr 22 04:46:18 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Thu, 22 Apr 2021 11:46:18 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSCBWNiAxLzJdIHdhdGNoZG9nOiBtdGs6IHN1cHBvcnQgcHJlLXRpbWVvdXQgd2hlbiB0aGUgYmFyayBpcnEgaXMgYXZhaWxhYmxl?=
In-Reply-To: <740481ed-97e0-3439-1af2-bc54cdb28536@roeck-us.net>
Message-ID: <AJYA1QBSDhatYsq-n3vbqqrl.3.1619063178146.Hmail.wangqing@vivo.com>


>On 4/21/21 7:45 PM, Wang Qing wrote:
>> Use the bark interrupt as the pretimeout notifier if available.
>> 
>> When the watchdog timer expires in dual mode, an interrupt will be
>> triggered first, then the timing restarts. The reset signal will be
>> initiated when the timer expires again.
>> 
>> The pretimeout notification shall occur at timeout-sec/2.
>> 
>> V2:
>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>> 
>> V3:
>> - Modify the pretimeout behavior, manually reset after the pretimeout
>> - is processed and wait until timeout.
>> 
>> V4:
>> - Remove pretimeout related processing. 
>> - Add dual mode control separately.
>> 
>> V5:
>> - Fix some formatting and printing problems.
>> 
>> V6:
>> - Realize pretimeout processing through dualmode.
>> 
>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>> ---
>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 48 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>> index 97ca993..ebc648b
>> --- a/drivers/watchdog/mtk_wdt.c
>> +++ b/drivers/watchdog/mtk_wdt.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/reset-controller.h>
>>  #include <linux/types.h>
>>  #include <linux/watchdog.h>
>> +#include <linux/interrupt.h>
>>  
>>  #define WDT_MAX_TIMEOUT		31
>>  #define WDT_MIN_TIMEOUT		1
>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>  {
>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>> +	unsigned int timeout_interval;
>>  	u32 reg;
>>  
>> -	wdt_dev->timeout = timeout;
>> +	timeout_interval = wdt_dev->timeout = timeout;
>> +	/*
>> +	 * In dual mode, irq will be triggered at timeout/2
>> +	 * the real timeout occurs at timeout
>> +	 */
>> +	if (wdt_dev->pretimeout)
>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>
>Please run checkpatch --strict and fix what it reports.
>Also, there should be a set_pretimeout function to set the
>pretimeout. It is ok to update it here, but it should be set
>in its own function to make sure that the actual value
>is reported back to userspace.
>
>Thanks,
>Guenter

The reason why the set_pretimeout interface is not provided is 
because the pretimeout is fixed after the timeout is set,  we need
to modify timeout after setting pretimeout, which is puzzling.

I will point out this behavior in the doc and comments,
or implement the set_pretimeout interface only as a print prompt.
What do you think of it?

Thanks,
Qing
>
>>  
>>  	/*
>>  	 * One bit is the value of 512 ticks
>>  	 * The clock has 32 KHz
>>  	 */
>> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
>> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>>  
>>  	mtk_wdt_ping(wdt_dev);
>> @@ -239,13 +247,25 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>  		return ret;
>>  
>>  	reg = ioread32(wdt_base + WDT_MODE);
>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	if (wdt_dev->pretimeout)
>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	else
>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>>  	iowrite32(reg, wdt_base + WDT_MODE);
>>  
>>  	return 0;
>>  }
>>  
>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
>> +{
>> +	struct watchdog_device *wdd = arg;
>> +
>> +	watchdog_notify_pretimeout(wdd);
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
>>  static const struct watchdog_info mtk_wdt_info = {
>>  	.identity	= DRV_NAME,
>>  	.options	= WDIOF_SETTIMEOUT |
>> @@ -253,6 +273,14 @@ static const struct watchdog_info mtk_wdt_info = {
>>  			  WDIOF_MAGICCLOSE,
>>  };
>>  
>> +static const struct watchdog_info mtk_wdt_pt_info = {
>> +	.identity	= DRV_NAME,
>> +	.options	= WDIOF_SETTIMEOUT |
>> +			  WDIOF_PRETIMEOUT |
>> +			  WDIOF_KEEPALIVEPING |
>> +			  WDIOF_MAGICCLOSE,
>> +};
>> +
>>  static const struct watchdog_ops mtk_wdt_ops = {
>>  	.owner		= THIS_MODULE,
>>  	.start		= mtk_wdt_start,
>> @@ -267,7 +295,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>  	struct device *dev = &pdev->dev;
>>  	struct mtk_wdt_dev *mtk_wdt;
>>  	const struct mtk_wdt_data *wdt_data;
>> -	int err;
>> +	int err, irq;
>>  
>>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>>  	if (!mtk_wdt)
>> @@ -279,7 +307,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>  	if (IS_ERR(mtk_wdt->wdt_base))
>>  		return PTR_ERR(mtk_wdt->wdt_base);
>>  
>> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>> +	irq = platform_get_irq(pdev, 0);
>> +	if (irq > 0) {
>> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
>> +							&mtk_wdt->wdt_dev);
>> +		if (err)
>> +			return err;
>> +
>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
>> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT/2;
>> +	} else {
>> +		if (irq == -EPROBE_DEFER)
>> +			return -EPROBE_DEFER;
>> +
>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>> +	}
>> +
>>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
>> 
>



From leo.yan at linaro.org  Thu Apr 22 04:49:29 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 22 Apr 2021 11:49:29 +0800
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com>
 <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com>
Message-ID: <20210422034929.GA13004@leoy-ThinkPad-X240s>

On Mon, Apr 19, 2021 at 09:03:18PM +0800, Yicong Yang wrote:
> On 2021/4/17 21:56, Alexander Shishkin wrote:
> > Yicong Yang <yangyicong at hisilicon.com> writes:
> > 
> >> The reason for not using perf is because there is no current support
> >> for uncore tracing in the perf facilities.
> > 
> > Not unless you count
> > 
> > $ perf list|grep -ic uncore
> > 77
> > 
> 
> these are uncore events probably do not support sampling.
> 
> I tried on x86:
> 
> # ./perf record -e uncore_imc_0/cas_count_read/
> Error:
> The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_imc_0/cas_count_read/).
> /bin/dmesg | grep -i perf may provide additional information.
> 
> For HiSilicon uncore PMUs, we don't support uncore sampling:
> 
> 'The current driver does not support sampling. So "perf record" is unsupported. ' [1]
> 
> and also in another PMU:
> 
> 'PMU doesn't support process specific events and cannot be used in sampling mode.' [2]
> 
> [1] Documentation/admin-guide/perf/hisi-pmu.rst
> [2] Documentation/admin-guide/perf/arm_dsu_pmu.rst

I did some debugging for this, and yes, it's related with the event
doesn't support sampling for these x86 uncore events.

So I can use below commands for the uncore event
'uncore_imc/data_reads/' in my experiment:

  # perf record -e 'uncore_imc/data_reads/' --no-samples -- ls
  # perf stat -e 'uncore_imc/data_reads/' -- ls

For your case, I think you need to write the callback
pmu::event_init(), it should not forbid any tracing even if set
sampling, just like other perf event drive for support AUX tracing.

> >> We have our own format
> >> of data and don't need perf doing the parsing.
> > 
> > Perf has AUX buffers, which are used for all kinds of own formats.
> > 
> 
> ok. we thought perf will break the data format but AUX buffers seems won't.
> do we need to add full support for tracing as well as parsing or it's ok for
> not parsing it through perf?

IMHO, this could divide into two parts.  The first part is to enable
perf drive with support AUX tracing, and perf tool can capture the trace
data.  The second part is to add the decoder in the perf tool so that
the developers can *consume* the trace data; for the decoder, you
could refer the codes:

  tools/perf/util/intel-pt-decoder/
  tools/perf/util/cs-etm-decoder/

Or Arm SPE case:

  tools/perf/util/arm-spe-decoder/

> >> A similar approach for implementing this function is ETM, which use
> >> sysfs for configuring and a character device for dumping data.
> > 
> > And also perf. One reason ETM has a sysfs interface is because the
> > driver predates perf's AUX buffers. Can't say if it's the only
> > reason. I'm assuming you're talking about Coresight ETM.

I am not the best person to give background for this.  Mathieu or Mike
could give more info for this.  From my undersanding, Sysfs nodes can
be used as knobs for configuration, but it's difficult for profiling.

Let's think about for the profiling, if one developer uses the Sysfs
for the setting and read out the trace data, these informations are
discrete.  If another developer wants to review the profiling result,
then all these info need to be shared together.

So we can benefit much from the perf tool for the usage, since all the
profiling context will be gathered (DSOs, hardware configuration which
can be saved into metadata), so the final profiling file can be easily
shared and more friendly for reviewing.

Thanks,
Leo


From linux at roeck-us.net  Thu Apr 22 05:02:02 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 21 Apr 2021 21:02:02 -0700
Subject: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <AJYA1QBSDhatYsq-n3vbqqrl.3.1619063178146.Hmail.wangqing@vivo.com>
References: <AJYA1QBSDhatYsq-n3vbqqrl.3.1619063178146.Hmail.wangqing@vivo.com>
Message-ID: <26bed2e5-6ec8-72ae-ff2c-c707c00d5125@roeck-us.net>

On 4/21/21 8:46 PM, ?? wrote:
> 
>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>> Use the bark interrupt as the pretimeout notifier if available.
>>>
>>> When the watchdog timer expires in dual mode, an interrupt will be
>>> triggered first, then the timing restarts. The reset signal will be
>>> initiated when the timer expires again.
>>>
>>> The pretimeout notification shall occur at timeout-sec/2.
>>>
>>> V2:
>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>
>>> V3:
>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>> - is processed and wait until timeout.
>>>
>>> V4:
>>> - Remove pretimeout related processing. 
>>> - Add dual mode control separately.
>>>
>>> V5:
>>> - Fix some formatting and printing problems.
>>>
>>> V6:
>>> - Realize pretimeout processing through dualmode.
>>>
>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>> ---
>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>> index 97ca993..ebc648b
>>> --- a/drivers/watchdog/mtk_wdt.c
>>> +++ b/drivers/watchdog/mtk_wdt.c
>>> @@ -25,6 +25,7 @@
>>>  #include <linux/reset-controller.h>
>>>  #include <linux/types.h>
>>>  #include <linux/watchdog.h>
>>> +#include <linux/interrupt.h>
>>>  
>>>  #define WDT_MAX_TIMEOUT		31
>>>  #define WDT_MIN_TIMEOUT		1
>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>  {
>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>> +	unsigned int timeout_interval;
>>>  	u32 reg;
>>>  
>>> -	wdt_dev->timeout = timeout;
>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>> +	/*
>>> +	 * In dual mode, irq will be triggered at timeout/2
>>> +	 * the real timeout occurs at timeout
>>> +	 */
>>> +	if (wdt_dev->pretimeout)
>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>
>> Please run checkpatch --strict and fix what it reports.
>> Also, there should be a set_pretimeout function to set the
>> pretimeout. It is ok to update it here, but it should be set
>> in its own function to make sure that the actual value
>> is reported back to userspace.
>>
>> Thanks,
>> Guenter
> 
> The reason why the set_pretimeout interface is not provided is 
> because the pretimeout is fixed after the timeout is set,  we need
> to modify timeout after setting pretimeout, which is puzzling.
> 

What you need to do is to set pretimeout = timeout / 2 if a pretimeout
is set to a value != 0. Just like we adjust timeout to valid values
when set, we adjust pretimeout as well. I don't see a problem with that.

Guenter


From lkp at intel.com  Thu Apr 22 05:04:37 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 12:04:37 +0800
Subject: [xlnx:master 11461/12130] rtc-zynqmp.c:undefined reference to
 `__divdi3'
Message-ID: <202104221230.dndVKGVb-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: c424825283f87a55e74ae2d761b5da2c8af5158b [11461/12130] rtc: zynqmp: Add calibration set and get support
config: i386-randconfig-c004-20210421 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/c424825283f87a55e74ae2d761b5da2c8af5158b
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout c424825283f87a55e74ae2d761b5da2c8af5158b
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_read_offset':
>> rtc-zynqmp.c:(.text+0x19): undefined reference to `__divdi3'
   ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_set_offset':
   rtc-zynqmp.c:(.text+0x1ad): undefined reference to `__divdi3'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47509 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/daf46c85/attachment-0001.gz>

From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:00 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:00 -0700
Subject: [PATCH net-next 00/14] mtk_eth_soc: fixes and performance improvements
Message-ID: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>

Most of these changes come from OpenWrt where they have been present and
tested for months.

First three patches are bug fixes. The rest are performance
improvements. The last patch is a cleanup to use the iopoll.h macro for
busy-waiting instead of a custom loop.

Source: 770-*.patch at https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=target/linux/generic/pending-5.10;hb=HEAD

Felix Fietkau (12):
  net: ethernet: mtk_eth_soc: fix RX VLAN offload
  net: ethernet: mtk_eth_soc: unmap RX data before calling build_skb
  net: ethernet: mtk_eth_soc: use napi_consume_skb
  net: ethernet: mtk_eth_soc: reduce MDIO bus access latency
  net: ethernet: mtk_eth_soc: remove unnecessary TX queue stops
  net: ethernet: mtk_eth_soc: use larger burst size for QDMA TX
  net: ethernet: mtk_eth_soc: increase DMA ring sizes
  net: ethernet: mtk_eth_soc: implement dynamic interrupt moderation
  net: ethernet: mtk_eth_soc: cache HW pointer of last freed TX
    descriptor
  net: ethernet: mtk_eth_soc: only read the full RX descriptor if DMA is
    done
  net: ethernet: mtk_eth_soc: reduce unnecessary interrupts
  net: ethernet: mtk_eth_soc: set PPE flow hash as skb hash if present

Ilya Lipnitskiy (2):
  net: ethernet: mtk_eth_soc: fix build_skb cleanup
  net: ethernet: mtk_eth_soc: use iopoll.h macro for DMA init

 drivers/net/ethernet/mediatek/Kconfig       |   1 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 228 ++++++++++++++------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  52 ++++-
 3 files changed, 199 insertions(+), 82 deletions(-)

-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:01 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:01 -0700
Subject: [PATCH net-next 01/14] net: ethernet: mtk_eth_soc: fix RX VLAN offload
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-2-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is
set. Fixes frames wrongly marked with VLAN tags.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: fix commit message]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6b00c12c6c43..b2175ec451ab 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1319,7 +1319,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb->protocol = eth_type_trans(skb, netdev);
 
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
-		    RX_DMA_VID(trxd.rxd3))
+		    (trxd.rxd2 & RX_DMA_VTAG))
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
 					       RX_DMA_VID(trxd.rxd3));
 		skb_record_rx_queue(skb, 0);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 1a6750c08bb9..875e67b41561 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -301,6 +301,7 @@
 #define RX_DMA_LSO		BIT(30)
 #define RX_DMA_PLEN0(_x)	(((_x) & 0x3fff) << 16)
 #define RX_DMA_GET_PLEN0(_x)	(((_x) >> 16) & 0x3fff)
+#define RX_DMA_VTAG		BIT(15)
 
 /* QDMA descriptor rxd3 */
 #define RX_DMA_VID(_x)		((_x) & 0xfff)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:03 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:03 -0700
Subject: [PATCH net-next 03/14] net: ethernet: mtk_eth_soc: fix build_skb
 cleanup
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-4-ilya.lipnitskiy@gmail.com>

In case build_skb fails, call skb_free_frag on the correct pointer. Also
update the DMA structures with the new mapping before exiting, because
the mapping was successful

Suggested-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 540003f3fcb8..07daa5de8bec 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1304,9 +1304,9 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		/* receive data */
 		skb = build_skb(data, ring->frag_size);
 		if (unlikely(!skb)) {
-			skb_free_frag(new_data);
+			skb_free_frag(data);
 			netdev->stats.rx_dropped++;
-			goto release_desc;
+			goto skip_rx;
 		}
 		skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
 
@@ -1326,6 +1326,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb_record_rx_queue(skb, 0);
 		napi_gro_receive(napi, skb);
 
+skip_rx:
 		ring->data[idx] = new_data;
 		rxd->rxd1 = (unsigned int)dma_addr;
 
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:02 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:02 -0700
Subject: [PATCH net-next 02/14] net: ethernet: mtk_eth_soc: unmap RX data
 before calling build_skb
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-3-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Since build_skb accesses the data area (for initializing shinfo), dma unmap
needs to happen before that call

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: split build_skb cleanup fix into a separate commit]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b2175ec451ab..540003f3fcb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1298,6 +1298,9 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 			goto release_desc;
 		}
 
+		dma_unmap_single(eth->dev, trxd.rxd1,
+				 ring->buf_size, DMA_FROM_DEVICE);
+
 		/* receive data */
 		skb = build_skb(data, ring->frag_size);
 		if (unlikely(!skb)) {
@@ -1307,8 +1310,6 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		}
 		skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
 
-		dma_unmap_single(eth->dev, trxd.rxd1,
-				 ring->buf_size, DMA_FROM_DEVICE);
 		pktlen = RX_DMA_GET_PLEN0(trxd.rxd2);
 		skb->dev = netdev;
 		skb_put(skb, pktlen);
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:04 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:04 -0700
Subject: [PATCH net-next 04/14] net: ethernet: mtk_eth_soc: use
 napi_consume_skb
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-5-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Should improve performance, since it can use bulk free

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 07daa5de8bec..5cf64de3ddf8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -858,7 +858,8 @@ static int txd_to_idx(struct mtk_tx_ring *ring, struct mtk_tx_dma *dma)
 	return ((void *)dma - (void *)ring->dma) / sizeof(*dma);
 }
 
-static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf)
+static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf,
+			 bool napi)
 {
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
 		if (tx_buf->flags & MTK_TX_FLAGS_SINGLE0) {
@@ -890,8 +891,12 @@ static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf)
 
 	tx_buf->flags = 0;
 	if (tx_buf->skb &&
-	    (tx_buf->skb != (struct sk_buff *)MTK_DMA_DUMMY_DESC))
-		dev_kfree_skb_any(tx_buf->skb);
+	    (tx_buf->skb != (struct sk_buff *)MTK_DMA_DUMMY_DESC)) {
+		if (napi)
+			napi_consume_skb(tx_buf->skb, napi);
+		else
+			dev_kfree_skb_any(tx_buf->skb);
+	}
 	tx_buf->skb = NULL;
 }
 
@@ -1069,7 +1074,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
 		tx_buf = mtk_desc_to_tx_buf(ring, itxd);
 
 		/* unmap dma */
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, false);
 
 		itxd->txd3 = TX_DMA_LS0 | TX_DMA_OWNER_CPU;
 		if (!MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
@@ -1388,7 +1393,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 			done[mac]++;
 			budget--;
 		}
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, true);
 
 		ring->last_free = desc;
 		atomic_inc(&ring->free_count);
@@ -1425,7 +1430,7 @@ static int mtk_poll_tx_pdma(struct mtk_eth *eth, int budget,
 			budget--;
 		}
 
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, true);
 
 		desc = &ring->dma[cpu];
 		ring->last_free = desc;
@@ -1627,7 +1632,7 @@ static void mtk_tx_clean(struct mtk_eth *eth)
 
 	if (ring->buf) {
 		for (i = 0; i < MTK_DMA_SIZE; i++)
-			mtk_tx_unmap(eth, &ring->buf[i]);
+			mtk_tx_unmap(eth, &ring->buf[i], false);
 		kfree(ring->buf);
 		ring->buf = NULL;
 	}
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:07 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:07 -0700
Subject: [PATCH net-next 07/14] net: ethernet: mtk_eth_soc: use larger burst
 size for QDMA TX
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-8-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Improves tx performance

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 223131645a37..5a67bbe9bd90 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2191,7 +2191,7 @@ static int mtk_start_dma(struct mtk_eth *eth)
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
 		mtk_w32(eth,
 			MTK_TX_WB_DDONE | MTK_TX_DMA_EN |
-			MTK_DMA_SIZE_16DWORDS | MTK_NDP_CO_PRO |
+			MTK_TX_BT_32DWORDS | MTK_NDP_CO_PRO |
 			MTK_RX_DMA_EN | MTK_RX_2B_OFFSET |
 			MTK_RX_BT_32DWORDS,
 			MTK_QDMA_GLO_CFG);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 989342a7ae4a..039c39d750e0 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -203,7 +203,7 @@
 #define MTK_RX_BT_32DWORDS	(3 << 11)
 #define MTK_NDP_CO_PRO		BIT(10)
 #define MTK_TX_WB_DDONE		BIT(6)
-#define MTK_DMA_SIZE_16DWORDS	(2 << 4)
+#define MTK_TX_BT_32DWORDS	(3 << 4)
 #define MTK_RX_DMA_BUSY		BIT(3)
 #define MTK_TX_DMA_BUSY		BIT(1)
 #define MTK_RX_DMA_EN		BIT(2)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:05 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:05 -0700
Subject: [PATCH net-next 05/14] net: ethernet: mtk_eth_soc: reduce MDIO bus
 access latency
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

usleep_range often ends up sleeping much longer than the 10-20us provided
as a range here. This causes significant latency in mdio bus acceses,
which easily adds multiple seconds to the boot time on MT7621 when polling
DSA slave ports.

Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
take much time

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: use readx_poll_timeout_atomic instead of cond_resched]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 18 ++++++++----------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  2 +-
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5cf64de3ddf8..a3958e99a29f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -79,18 +79,16 @@ static u32 mtk_m32(struct mtk_eth *eth, u32 mask, u32 set, unsigned reg)
 
 static int mtk_mdio_busy_wait(struct mtk_eth *eth)
 {
-	unsigned long t_start = jiffies;
+	int ret;
+	u32 val;
 
-	while (1) {
-		if (!(mtk_r32(eth, MTK_PHY_IAC) & PHY_IAC_ACCESS))
-			return 0;
-		if (time_after(jiffies, t_start + PHY_IAC_TIMEOUT))
-			break;
-		usleep_range(10, 20);
-	}
+	ret = readx_poll_timeout_atomic(__raw_readl, eth->base + MTK_PHY_IAC,
+					val, !(val & PHY_IAC_ACCESS),
+					5, PHY_IAC_TIMEOUT_US);
+	if (ret)
+		dev_err(eth->dev, "mdio: MDIO timeout\n");
 
-	dev_err(eth->dev, "mdio: MDIO timeout\n");
-	return -1;
+	return ret;
 }
 
 static u32 _mtk_mdio_write(struct mtk_eth *eth, u32 phy_addr,
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 875e67b41561..989342a7ae4a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -327,7 +327,7 @@
 #define PHY_IAC_START		BIT(16)
 #define PHY_IAC_ADDR_SHIFT	20
 #define PHY_IAC_REG_SHIFT	25
-#define PHY_IAC_TIMEOUT		HZ
+#define PHY_IAC_TIMEOUT_US	1000000
 
 #define MTK_MAC_MISC		0x1000c
 #define MTK_MUX_TO_ESW		BIT(0)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:06 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:06 -0700
Subject: [PATCH net-next 06/14] net: ethernet: mtk_eth_soc: remove unnecessary
 TX queue stops
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-7-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

When running short on descriptors, only stop the queue for the netdev that
tx was attempted for. By the time something tries to send on the other
netdev, the ring might have some more room already.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a3958e99a29f..223131645a37 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1129,17 +1129,6 @@ static void mtk_wake_queue(struct mtk_eth *eth)
 	}
 }
 
-static void mtk_stop_queue(struct mtk_eth *eth)
-{
-	int i;
-
-	for (i = 0; i < MTK_MAC_COUNT; i++) {
-		if (!eth->netdev[i])
-			continue;
-		netif_stop_queue(eth->netdev[i]);
-	}
-}
-
 static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct mtk_mac *mac = netdev_priv(dev);
@@ -1160,7 +1149,7 @@ static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	tx_num = mtk_cal_txd_req(skb);
 	if (unlikely(atomic_read(&ring->free_count) <= tx_num)) {
-		mtk_stop_queue(eth);
+		netif_stop_queue(dev);
 		netif_err(eth, tx_queued, dev,
 			  "Tx Ring full when queue awake!\n");
 		spin_unlock(&eth->page_lock);
@@ -1186,7 +1175,7 @@ static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	if (unlikely(atomic_read(&ring->free_count) <= ring->thresh))
-		mtk_stop_queue(eth);
+		netif_stop_queue(dev);
 
 	spin_unlock(&eth->page_lock);
 
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:10 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:10 -0700
Subject: [PATCH net-next 10/14] net: ethernet: mtk_eth_soc: cache HW pointer
 of last freed TX descriptor
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-11-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

The value is only updated by the CPU, so it is cheaper to access from the
ring data structure than from a hardware register.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++++----
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 043ab5446524..01ad10c76d53 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1362,7 +1362,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 	struct mtk_tx_buf *tx_buf;
 	u32 cpu, dma;
 
-	cpu = mtk_r32(eth, MTK_QTX_CRX_PTR);
+	cpu = ring->last_free_ptr;
 	dma = mtk_r32(eth, MTK_QTX_DRX_PTR);
 
 	desc = mtk_qdma_phys_to_virt(ring, cpu);
@@ -1396,6 +1396,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 		cpu = next_cpu;
 	}
 
+	ring->last_free_ptr = cpu;
 	mtk_w32(eth, cpu, MTK_QTX_CRX_PTR);
 
 	return budget;
@@ -1596,6 +1597,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
 	atomic_set(&ring->free_count, MTK_DMA_SIZE - 2);
 	ring->next_free = &ring->dma[0];
 	ring->last_free = &ring->dma[MTK_DMA_SIZE - 1];
+	ring->last_free_ptr = (u32)(ring->phys + ((MTK_DMA_SIZE - 1) * sz));
 	ring->thresh = MAX_SKB_FRAGS;
 
 	/* make sure that all changes to the dma ring are flushed before we
@@ -1609,9 +1611,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
 		mtk_w32(eth,
 			ring->phys + ((MTK_DMA_SIZE - 1) * sz),
 			MTK_QTX_CRX_PTR);
-		mtk_w32(eth,
-			ring->phys + ((MTK_DMA_SIZE - 1) * sz),
-			MTK_QTX_DRX_PTR);
+		mtk_w32(eth, ring->last_free_ptr, MTK_QTX_DRX_PTR);
 		mtk_w32(eth, (QDMA_RES_THRES << 8) | QDMA_RES_THRES,
 			MTK_QTX_CFG(0));
 	} else {
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index a8d388b02558..214da569e869 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -642,6 +642,7 @@ struct mtk_tx_buf {
  * @phys:		The physical addr of tx_buf
  * @next_free:		Pointer to the next free descriptor
  * @last_free:		Pointer to the last free descriptor
+ * @last_free_ptr:	Hardware pointer value of the last free descriptor
  * @thresh:		The threshold of minimum amount of free descriptors
  * @free_count:		QDMA uses a linked list. Track how many free descriptors
  *			are present
@@ -652,6 +653,7 @@ struct mtk_tx_ring {
 	dma_addr_t phys;
 	struct mtk_tx_dma *next_free;
 	struct mtk_tx_dma *last_free;
+	u32 last_free_ptr;
 	u16 thresh;
 	atomic_t free_count;
 	int dma_size;
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:09 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:09 -0700
Subject: [PATCH net-next 09/14] net: ethernet: mtk_eth_soc: implement dynamic
 interrupt moderation
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-10-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Reduces the number of interrupts under load

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: add documentation for new struct fields]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/Kconfig       |  1 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 96 +++++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 41 +++++++--
 3 files changed, 124 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
index 08c2e446d3d5..c357c193378e 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -11,6 +11,7 @@ config NET_MEDIATEK_SOC
 	tristate "MediaTek SoC Gigabit Ethernet support"
 	depends on NET_DSA || !NET_DSA
 	select PHYLINK
+	select DIMLIB
 	help
 	  This driver supports the gigabit ethernet MACs in the
 	  MediaTek SoC family.
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5a67bbe9bd90..043ab5446524 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1231,12 +1231,13 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
 static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		       struct mtk_eth *eth)
 {
+	struct dim_sample dim_sample = {};
 	struct mtk_rx_ring *ring;
 	int idx;
 	struct sk_buff *skb;
 	u8 *data, *new_data;
 	struct mtk_rx_dma *rxd, trxd;
-	int done = 0;
+	int done = 0, bytes = 0;
 
 	while (done < budget) {
 		struct net_device *netdev;
@@ -1310,6 +1311,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		else
 			skb_checksum_none_assert(skb);
 		skb->protocol = eth_type_trans(skb, netdev);
+		bytes += pktlen;
 
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
 		    (trxd.rxd2 & RX_DMA_VTAG))
@@ -1342,6 +1344,12 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		mtk_update_rx_cpu_idx(eth);
 	}
 
+	eth->rx_packets += done;
+	eth->rx_bytes += bytes;
+	dim_update_sample(eth->rx_events, eth->rx_packets, eth->rx_bytes,
+			  &dim_sample);
+	net_dim(&eth->rx_dim, dim_sample);
+
 	return done;
 }
 
@@ -1434,6 +1442,7 @@ static int mtk_poll_tx_pdma(struct mtk_eth *eth, int budget,
 static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 {
 	struct mtk_tx_ring *ring = &eth->tx_ring;
+	struct dim_sample dim_sample = {};
 	unsigned int done[MTK_MAX_DEVS];
 	unsigned int bytes[MTK_MAX_DEVS];
 	int total = 0, i;
@@ -1451,8 +1460,14 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 			continue;
 		netdev_completed_queue(eth->netdev[i], done[i], bytes[i]);
 		total += done[i];
+		eth->tx_packets += done[i];
+		eth->tx_bytes += bytes[i];
 	}
 
+	dim_update_sample(eth->tx_events, eth->tx_packets, eth->tx_bytes,
+			  &dim_sample);
+	net_dim(&eth->tx_dim, dim_sample);
+
 	if (mtk_queue_stopped(eth) &&
 	    (atomic_read(&ring->free_count) > ring->thresh))
 		mtk_wake_queue(eth);
@@ -2127,6 +2142,7 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
 {
 	struct mtk_eth *eth = _eth;
 
+	eth->rx_events++;
 	if (likely(napi_schedule_prep(&eth->rx_napi))) {
 		__napi_schedule(&eth->rx_napi);
 		mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
@@ -2139,6 +2155,7 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
 {
 	struct mtk_eth *eth = _eth;
 
+	eth->tx_events++;
 	if (likely(napi_schedule_prep(&eth->tx_napi))) {
 		__napi_schedule(&eth->tx_napi);
 		mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
@@ -2323,6 +2340,9 @@ static int mtk_stop(struct net_device *dev)
 	napi_disable(&eth->tx_napi);
 	napi_disable(&eth->rx_napi);
 
+	cancel_work_sync(&eth->rx_dim.work);
+	cancel_work_sync(&eth->tx_dim.work);
+
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
 		mtk_stop_dma(eth, MTK_QDMA_GLO_CFG);
 	mtk_stop_dma(eth, MTK_PDMA_GLO_CFG);
@@ -2375,6 +2395,64 @@ static int mtk_clk_enable(struct mtk_eth *eth)
 	return ret;
 }
 
+static void mtk_dim_rx(struct work_struct *work)
+{
+	struct dim *dim = container_of(work, struct dim, work);
+	struct mtk_eth *eth = container_of(dim, struct mtk_eth, rx_dim);
+	struct dim_cq_moder cur_profile;
+	u32 val, cur;
+
+	cur_profile = net_dim_get_rx_moderation(eth->rx_dim.mode,
+						dim->profile_ix);
+	spin_lock_bh(&eth->dim_lock);
+
+	val = mtk_r32(eth, MTK_PDMA_DELAY_INT);
+	val &= MTK_PDMA_DELAY_TX_MASK;
+	val |= MTK_PDMA_DELAY_RX_EN;
+
+	cur = min_t(u32, DIV_ROUND_UP(cur_profile.usec, 20), MTK_PDMA_DELAY_PTIME_MASK);
+	val |= cur << MTK_PDMA_DELAY_RX_PTIME_SHIFT;
+
+	cur = min_t(u32, cur_profile.pkts, MTK_PDMA_DELAY_PINT_MASK);
+	val |= cur << MTK_PDMA_DELAY_RX_PINT_SHIFT;
+
+	mtk_w32(eth, val, MTK_PDMA_DELAY_INT);
+	mtk_w32(eth, val, MTK_QDMA_DELAY_INT);
+
+	spin_unlock_bh(&eth->dim_lock);
+
+	dim->state = DIM_START_MEASURE;
+}
+
+static void mtk_dim_tx(struct work_struct *work)
+{
+	struct dim *dim = container_of(work, struct dim, work);
+	struct mtk_eth *eth = container_of(dim, struct mtk_eth, tx_dim);
+	struct dim_cq_moder cur_profile;
+	u32 val, cur;
+
+	cur_profile = net_dim_get_tx_moderation(eth->tx_dim.mode,
+						dim->profile_ix);
+	spin_lock_bh(&eth->dim_lock);
+
+	val = mtk_r32(eth, MTK_PDMA_DELAY_INT);
+	val &= MTK_PDMA_DELAY_RX_MASK;
+	val |= MTK_PDMA_DELAY_TX_EN;
+
+	cur = min_t(u32, DIV_ROUND_UP(cur_profile.usec, 20), MTK_PDMA_DELAY_PTIME_MASK);
+	val |= cur << MTK_PDMA_DELAY_TX_PTIME_SHIFT;
+
+	cur = min_t(u32, cur_profile.pkts, MTK_PDMA_DELAY_PINT_MASK);
+	val |= cur << MTK_PDMA_DELAY_TX_PINT_SHIFT;
+
+	mtk_w32(eth, val, MTK_PDMA_DELAY_INT);
+	mtk_w32(eth, val, MTK_QDMA_DELAY_INT);
+
+	spin_unlock_bh(&eth->dim_lock);
+
+	dim->state = DIM_START_MEASURE;
+}
+
 static int mtk_hw_init(struct mtk_eth *eth)
 {
 	int i, val, ret;
@@ -2396,9 +2474,6 @@ static int mtk_hw_init(struct mtk_eth *eth)
 			goto err_disable_pm;
 		}
 
-		/* enable interrupt delay for RX */
-		mtk_w32(eth, MTK_PDMA_DELAY_RX_DELAY, MTK_PDMA_DELAY_INT);
-
 		/* disable delay and normal interrupt */
 		mtk_tx_irq_disable(eth, ~0);
 		mtk_rx_irq_disable(eth, ~0);
@@ -2437,11 +2512,11 @@ static int mtk_hw_init(struct mtk_eth *eth)
 	/* Enable RX VLan Offloading */
 	mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
 
-	/* enable interrupt delay for RX */
-	mtk_w32(eth, MTK_PDMA_DELAY_RX_DELAY, MTK_PDMA_DELAY_INT);
+	/* set interrupt delays based on current Net DIM sample */
+	mtk_dim_rx(&eth->rx_dim.work);
+	mtk_dim_tx(&eth->tx_dim.work);
 
 	/* disable delay and normal interrupt */
-	mtk_w32(eth, 0, MTK_QDMA_DELAY_INT);
 	mtk_tx_irq_disable(eth, ~0);
 	mtk_rx_irq_disable(eth, ~0);
 
@@ -2976,6 +3051,13 @@ static int mtk_probe(struct platform_device *pdev)
 	spin_lock_init(&eth->page_lock);
 	spin_lock_init(&eth->tx_irq_lock);
 	spin_lock_init(&eth->rx_irq_lock);
+	spin_lock_init(&eth->dim_lock);
+
+	eth->rx_dim.mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+	INIT_WORK(&eth->rx_dim.work, mtk_dim_rx);
+
+	eth->tx_dim.mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+	INIT_WORK(&eth->tx_dim.work, mtk_dim_tx);
 
 	if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
 		eth->ethsys = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 4999f8123180..a8d388b02558 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -16,6 +16,7 @@
 #include <linux/refcount.h>
 #include <linux/phylink.h>
 #include <linux/rhashtable.h>
+#include <linux/dim.h>
 #include "mtk_ppe.h"
 
 #define MTK_QDMA_PAGE_SIZE	2048
@@ -137,13 +138,18 @@
 
 /* PDMA Delay Interrupt Register */
 #define MTK_PDMA_DELAY_INT		0xa0c
+#define MTK_PDMA_DELAY_RX_MASK		GENMASK(15, 0)
 #define MTK_PDMA_DELAY_RX_EN		BIT(15)
-#define MTK_PDMA_DELAY_RX_PINT		4
 #define MTK_PDMA_DELAY_RX_PINT_SHIFT	8
-#define MTK_PDMA_DELAY_RX_PTIME		4
-#define MTK_PDMA_DELAY_RX_DELAY		\
-	(MTK_PDMA_DELAY_RX_EN | MTK_PDMA_DELAY_RX_PTIME | \
-	(MTK_PDMA_DELAY_RX_PINT << MTK_PDMA_DELAY_RX_PINT_SHIFT))
+#define MTK_PDMA_DELAY_RX_PTIME_SHIFT	0
+
+#define MTK_PDMA_DELAY_TX_MASK		GENMASK(31, 16)
+#define MTK_PDMA_DELAY_TX_EN		BIT(31)
+#define MTK_PDMA_DELAY_TX_PINT_SHIFT	24
+#define MTK_PDMA_DELAY_TX_PTIME_SHIFT	16
+
+#define MTK_PDMA_DELAY_PINT_MASK	0x7f
+#define MTK_PDMA_DELAY_PTIME_MASK	0xff
 
 /* PDMA Interrupt Status Register */
 #define MTK_PDMA_INT_STATUS	0xa20
@@ -225,6 +231,7 @@
 /* QDMA Interrupt Status Register */
 #define MTK_QDMA_INT_STATUS	0x1A18
 #define MTK_RX_DONE_DLY		BIT(30)
+#define MTK_TX_DONE_DLY		BIT(28)
 #define MTK_RX_DONE_INT3	BIT(19)
 #define MTK_RX_DONE_INT2	BIT(18)
 #define MTK_RX_DONE_INT1	BIT(17)
@@ -234,8 +241,7 @@
 #define MTK_TX_DONE_INT1	BIT(1)
 #define MTK_TX_DONE_INT0	BIT(0)
 #define MTK_RX_DONE_INT		MTK_RX_DONE_DLY
-#define MTK_TX_DONE_INT		(MTK_TX_DONE_INT0 | MTK_TX_DONE_INT1 | \
-				 MTK_TX_DONE_INT2 | MTK_TX_DONE_INT3)
+#define MTK_TX_DONE_INT		MTK_TX_DONE_DLY
 
 /* QDMA Interrupt grouping registers */
 #define MTK_QDMA_INT_GRP1	0x1a20
@@ -849,6 +855,7 @@ struct mtk_sgmii {
  * @page_lock:		Make sure that register operations are atomic
  * @tx_irq__lock:	Make sure that IRQ register operations are atomic
  * @rx_irq__lock:	Make sure that IRQ register operations are atomic
+ * @dim_lock:		Make sure that Net DIM operations are atomic
  * @dummy_dev:		we run 2 netdevs on 1 physical DMA ring and need a
  *			dummy for NAPI to work
  * @netdev:		The netdev instances
@@ -867,6 +874,14 @@ struct mtk_sgmii {
  * @rx_ring_qdma:	Pointer to the memory holding info about the QDMA RX ring
  * @tx_napi:		The TX NAPI struct
  * @rx_napi:		The RX NAPI struct
+ * @rx_events:		Net DIM RX event counter
+ * @rx_packets:		Net DIM RX packet counter
+ * @rx_bytes:		Net DIM RX byte counter
+ * @rx_dim:		Net DIM RX context
+ * @tx_events:		Net DIM TX event counter
+ * @tx_packets:		Net DIM TX packet counter
+ * @tx_bytes:		Net DIM TX byte counter
+ * @tx_dim:		Net DIM TX context
  * @scratch_ring:	Newer SoCs need memory for a second HW managed TX ring
  * @phy_scratch_ring:	physical address of scratch_ring
  * @scratch_head:	The scratch memory that scratch_ring points to.
@@ -911,6 +926,18 @@ struct mtk_eth {
 
 	const struct mtk_soc_data	*soc;
 
+	spinlock_t			dim_lock;
+
+	u32				rx_events;
+	u32				rx_packets;
+	u32				rx_bytes;
+	struct dim			rx_dim;
+
+	u32				tx_events;
+	u32				tx_packets;
+	u32				tx_bytes;
+	struct dim			tx_dim;
+
 	u32				tx_int_mask_reg;
 	u32				tx_int_status_reg;
 	u32				rx_dma_l4_valid;
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:11 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:11 -0700
Subject: [PATCH net-next 11/14] net: ethernet: mtk_eth_soc: only read the full
 RX descriptor if DMA is done
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-12-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Uncached memory access is expensive, and there is no need to access all
descriptor words if we can't process them anyway

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 01ad10c76d53..5a531bb83348 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -775,13 +775,18 @@ static inline int mtk_max_buf_size(int frag_size)
 	return buf_size;
 }
 
-static inline void mtk_rx_get_desc(struct mtk_rx_dma *rxd,
+static inline bool mtk_rx_get_desc(struct mtk_rx_dma *rxd,
 				   struct mtk_rx_dma *dma_rxd)
 {
-	rxd->rxd1 = READ_ONCE(dma_rxd->rxd1);
 	rxd->rxd2 = READ_ONCE(dma_rxd->rxd2);
+	if (!(rxd->rxd2 & RX_DMA_DONE))
+		return false;
+
+	rxd->rxd1 = READ_ONCE(dma_rxd->rxd1);
 	rxd->rxd3 = READ_ONCE(dma_rxd->rxd3);
 	rxd->rxd4 = READ_ONCE(dma_rxd->rxd4);
+
+	return true;
 }
 
 /* the qdma core needs scratch memory to be setup */
@@ -1253,8 +1258,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		rxd = &ring->dma[idx];
 		data = ring->data[idx];
 
-		mtk_rx_get_desc(&trxd, rxd);
-		if (!(trxd.rxd2 & RX_DMA_DONE))
+		if (!mtk_rx_get_desc(&trxd, rxd))
 			break;
 
 		/* find out which mac the packet come from. values start at 1 */
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:12 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:12 -0700
Subject: [PATCH net-next 12/14] net: ethernet: mtk_eth_soc: reduce unnecessary
 interrupts
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-13-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Avoid rearming interrupt if napi_complete returns false

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5a531bb83348..88a437f478fd 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1517,8 +1517,8 @@ static int mtk_napi_tx(struct napi_struct *napi, int budget)
 	if (status & MTK_TX_DONE_INT)
 		return budget;
 
-	napi_complete(napi);
-	mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
+	if (napi_complete(napi))
+		mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
 
 	return tx_done;
 }
@@ -1551,8 +1551,9 @@ static int mtk_napi_rx(struct napi_struct *napi, int budget)
 		remain_budget -= rx_done;
 		goto poll_again;
 	}
-	napi_complete(napi);
-	mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
+
+	if (napi_complete(napi))
+		mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
 
 	return rx_done + budget - remain_budget;
 }
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:13 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:13 -0700
Subject: [PATCH net-next 13/14] net: ethernet: mtk_eth_soc: set PPE flow hash
 as skb hash if present
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-14-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

This improves GRO performance

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: Use MTK_RXD4_FOE_ENTRY instead of GENMASK(13, 0)]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 88a437f478fd..8c863322587e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/pinctrl/devinfo.h>
 #include <linux/phylink.h>
+#include <linux/jhash.h>
 #include <net/dsa.h>
 
 #include "mtk_eth_soc.h"
@@ -1248,6 +1249,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		struct net_device *netdev;
 		unsigned int pktlen;
 		dma_addr_t dma_addr;
+		u32 hash;
 		int mac;
 
 		ring = mtk_get_rx_ring(eth);
@@ -1317,6 +1319,12 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb->protocol = eth_type_trans(skb, netdev);
 		bytes += pktlen;
 
+		hash = trxd.rxd4 & MTK_RXD4_FOE_ENTRY;
+		if (hash != MTK_RXD4_FOE_ENTRY) {
+			hash = jhash_1word(hash, 0);
+			skb_set_hash(skb, hash, PKT_HASH_TYPE_L4);
+		}
+
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
 		    (trxd.rxd2 & RX_DMA_VTAG))
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:14 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:14 -0700
Subject: [PATCH net-next 14/14] net: ethernet: mtk_eth_soc: use iopoll.h macro
 for DMA init
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-15-ilya.lipnitskiy@gmail.com>

Replace a tight busy-wait loop without a pause with a standard
readx_poll_timeout_atomic routine with a 5 us poll period.

Tested by booting a MT7621 device to ensure the driver initializes
properly.

Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++------------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  2 +-
 2 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8c863322587e..720d73d0c007 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2037,25 +2037,22 @@ static int mtk_set_features(struct net_device *dev, netdev_features_t features)
 /* wait for DMA to finish whatever it is doing before we start using it again */
 static int mtk_dma_busy_wait(struct mtk_eth *eth)
 {
-	unsigned long t_start = jiffies;
+	u32 val;
+	int ret;
+	unsigned int reg;
 
-	while (1) {
-		if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
-			if (!(mtk_r32(eth, MTK_QDMA_GLO_CFG) &
-			      (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)))
-				return 0;
-		} else {
-			if (!(mtk_r32(eth, MTK_PDMA_GLO_CFG) &
-			      (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)))
-				return 0;
-		}
+	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
+		reg = MTK_QDMA_GLO_CFG;
+	else
+		reg = MTK_PDMA_GLO_CFG;
 
-		if (time_after(jiffies, t_start + MTK_DMA_BUSY_TIMEOUT))
-			break;
-	}
+	ret = readx_poll_timeout_atomic(__raw_readl, eth->base + reg, val,
+					!(val & (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)),
+					5, MTK_DMA_BUSY_TIMEOUT_US);
+	if (ret)
+		dev_err(eth->dev, "DMA init timeout\n");
 
-	dev_err(eth->dev, "DMA init timeout\n");
-	return -1;
+	return ret;
 }
 
 static int mtk_dma_init(struct mtk_eth *eth)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 214da569e869..2e4356ccf778 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -214,7 +214,7 @@
 #define MTK_TX_DMA_BUSY		BIT(1)
 #define MTK_RX_DMA_EN		BIT(2)
 #define MTK_TX_DMA_EN		BIT(0)
-#define MTK_DMA_BUSY_TIMEOUT	HZ
+#define MTK_DMA_BUSY_TIMEOUT_US	1000000
 
 /* QDMA Reset Index Register */
 #define MTK_QDMA_RST_IDX	0x1A08
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Thu Apr 22 05:09:08 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Wed, 21 Apr 2021 21:09:08 -0700
Subject: [PATCH net-next 08/14] net: ethernet: mtk_eth_soc: increase DMA ring
 sizes
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422040914.47788-9-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

256 descriptors is not enough for multi-gigabit traffic under load on
MT7622. Bump it to 512 to improve performance.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 039c39d750e0..4999f8123180 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -22,7 +22,7 @@
 #define MTK_MAX_RX_LENGTH	1536
 #define MTK_MAX_RX_LENGTH_2K	2048
 #define MTK_TX_DMA_BUF_LEN	0x3fff
-#define MTK_DMA_SIZE		256
+#define MTK_DMA_SIZE		512
 #define MTK_NAPI_WEIGHT		64
 #define MTK_MAC_COUNT		2
 #define MTK_RX_ETH_HLEN		(ETH_HLEN + ETH_FCS_LEN)
-- 
2.31.1



From sumit.garg at linaro.org  Thu Apr 22 05:47:02 2021
From: sumit.garg at linaro.org (Sumit Garg)
Date: Thu, 22 Apr 2021 10:17:02 +0530
Subject: [PATCH v9 1/4] KEYS: trusted: Add generic trusted keys framework
In-Reply-To: <e7a91c8c09722afe1fb1ec3aa7b6544e713183af.camel@linux.ibm.com>
References: <20210301131127.793707-1-sumit.garg@linaro.org>
 <20210301131127.793707-2-sumit.garg@linaro.org>
 <65dcc9fa28833e6beb1eadf98b0ed3402404d693.camel@linux.ibm.com>
 <CAFA6WYOzD-qhHrcnzvd9P7iFvEqWwf0NCKXrgrEgvnB5i_-SxQ@mail.gmail.com>
 <e7a91c8c09722afe1fb1ec3aa7b6544e713183af.camel@linux.ibm.com>
Message-ID: <CAFA6WYOSVVhk91XxwbmqGkvpcUF5pkro4M7fay480Enocoj+=g@mail.gmail.com>

On Wed, 21 Apr 2021 at 22:51, James Bottomley <jejb at linux.ibm.com> wrote:
>
> On Wed, 2021-04-21 at 16:38 +0530, Sumit Garg wrote:
> > Hi James,
> >
> > On Wed, 21 Apr 2021 at 04:47, James Bottomley <jejb at linux.ibm.com>
> > wrote:
> > > On Mon, 2021-03-01 at 18:41 +0530, Sumit Garg wrote:
> > > > Current trusted keys framework is tightly coupled to use TPM
> > > > device as an underlying implementation which makes it difficult
> > > > for implementations like Trusted Execution Environment (TEE) etc.
> > > > to provide trusted keys support in case platform doesn't posses a
> > > > TPM device.
> > > >
> > > > Add a generic trusted keys framework where underlying
> > > > implementations can be easily plugged in. Create struct
> > > > trusted_key_ops to achieve this, which contains necessary
> > > > functions of a backend.
> > > >
> > > > Also, define a module parameter in order to select a particular
> > > > trust source in case a platform support multiple trust sources.
> > > > In case its not specified then implementation itetrates through
> > > > trust sources list starting with TPM and assign the first trust
> > > > source as a backend which has initiazed successfully during
> > > > iteration.
> > > >
> > > > Note that current implementation only supports a single trust
> > > > source at runtime which is either selectable at compile time or
> > > > during boot via aforementioned module parameter.
> > >
> > > You never actually tested this, did you?  I'm now getting EINVAL
> > > from all the trusted TPM key operations because of this patch.
> > >
> >
> > Unfortunately, I don't possess a development machine with a TPM
> > device. So mine testing was entirely based on TEE as a backend which
> > doesn't support any optional parameters. And that being the reason I
> > didn't catch this issue at first instance.
> >
> > Is there any TPM emulation environment available that I can use for
> > testing?
>
> Well use the same as we all use: A software TPM running in the host
> coupled with a virtual machine guest for the kernel:
>
> https://en.opensuse.org/Software_TPM_Emulator_For_QEMU
>
> It doesn't catch interface issues (like TIS timeouts) but it does catch
> TPM operations problems like this patch had.
>

Thanks for the pointer. I will use it for future testing.

-Sumit

> James
>
>


From chang.seok.bae at intel.com  Thu Apr 22 05:48:51 2021
From: chang.seok.bae at intel.com (Chang S. Bae)
Date: Wed, 21 Apr 2021 21:48:51 -0700
Subject: [PATCH v8 1/6] uapi: Define the aux vector AT_MINSIGSTKSZ
In-Reply-To: <20210422044856.27250-1-chang.seok.bae@intel.com>
References: <20210422044856.27250-1-chang.seok.bae@intel.com>
Message-ID: <20210422044856.27250-2-chang.seok.bae@intel.com>

Define the AT_MINSIGSTKSZ in generic Linux. It is already used as generic
ABI in glibc's generic elf.h, and this define will prevent future namespace
conflicts. In particular, x86 is also using this generic definition.

Signed-off-by: Chang S. Bae <chang.seok.bae at intel.com>
Reviewed-by: Len Brown <len.brown at intel.com>
Cc: Carlos O'Donell <carlos at redhat.com>
Cc: Dave Martin <Dave.Martin at arm.com>
Cc: libc-alpha at sourceware.org
Cc: linux-arch at vger.kernel.org
Cc: linux-api at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
Change from v6:
* Revised the comment. (Borislav Petkov)

Change from v5:
* Reverted the arm64 change. (Dave Martin and Will Deacon)
* Massaged the changelog.

Change from v4:
* Added as a new patch (Carlos O'Donell)
---
 include/uapi/linux/auxvec.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index abe5f2b6581b..c7e502bf5a6f 100644
--- a/include/uapi/linux/auxvec.h
+++ b/include/uapi/linux/auxvec.h
@@ -33,5 +33,8 @@
 
 #define AT_EXECFN  31	/* filename of program */
 
+#ifndef AT_MINSIGSTKSZ
+#define AT_MINSIGSTKSZ	51	/* minimal stack size for signal delivery */
+#endif
 
 #endif /* _UAPI_LINUX_AUXVEC_H */
-- 
2.17.1



From punit1.agrawal at toshiba.co.jp  Thu Apr 22 06:48:18 2021
From: punit1.agrawal at toshiba.co.jp (Punit Agrawal)
Date: Thu, 22 Apr 2021 14:48:18 +0900
Subject: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE
In-Reply-To: <20210421134844.3297838-1-arnd@kernel.org> (Arnd Bergmann's
 message of "Wed, 21 Apr 2021 15:48:36 +0200")
References: <20210421134844.3297838-1-arnd@kernel.org>
Message-ID: <871rb2swd9.fsf@kokedama.swc.toshiba.co.jp>

Hi Arnd,

Thanks for the fix.

Arnd Bergmann <arnd at kernel.org> writes:

> From: Arnd Bergmann <arnd at arndb.de>
>
> When the firmware code is disabled, the incomplete error handling
> in the clk driver causes compile-time warnings:
>
> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
> drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized]
>   147 |         rate =  parent_rate * fbdiv;
>       |                 ~~~~~~~~~~~~^~~~~~~
> In function 'zynqmp_pll_get_mode',
>     inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6:
> drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized]
>    61 |         return ret_payload[1];
>       |                ~~~~~~~~~~~^~~
> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
> drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here
>    53 |         u32 ret_payload[PAYLOAD_ARG_CNT];
>       |             ^~~~~~~~~~~
> drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent':
> drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized]
>    57 |         return val;
>       |                ^~~


Not sure what I am missing but I couldn't reproduce these warnings. I
tried a few different ways to toggle CONFIG_ZYNQMP_FIRMWARE.

Regardless...

> As it was apparently intentional to support this for compile testing
> purposes, change the code to have just enough error handling for the
> compiler to not notice the remaining bugs.
>
> Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/clk/zynqmp/clk-mux-zynqmp.c | 4 +++-
>  drivers/clk/zynqmp/pll.c            | 8 ++++++--
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/zynqmp/clk-mux-zynqmp.c b/drivers/clk/zynqmp/clk-mux-zynqmp.c
> index 06194149be83..2afded3c7c11 100644
> --- a/drivers/clk/zynqmp/clk-mux-zynqmp.c
> +++ b/drivers/clk/zynqmp/clk-mux-zynqmp.c
> @@ -50,9 +50,11 @@ static u8 zynqmp_clk_mux_get_parent(struct clk_hw *hw)
>  
>  	ret = zynqmp_pm_clock_getparent(clk_id, &val);
>  
> -	if (ret)
> +	if (ret) {
>  		pr_warn_once("%s() getparent failed for clock: %s, ret = %d\n",
>  			     __func__, clk_name, ret);
> +		return ret;
> +	}
>  
>  	return val;
>  }
> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
> index abe6afbf3407..67d2a2d260c1 100644
> --- a/drivers/clk/zynqmp/pll.c
> +++ b/drivers/clk/zynqmp/pll.c
> @@ -54,9 +54,11 @@ static inline enum pll_mode zynqmp_pll_get_mode(struct clk_hw *hw)
>  	int ret;
>  
>  	ret = zynqmp_pm_get_pll_frac_mode(clk_id, ret_payload);
> -	if (ret)
> +	if (ret) {
>  		pr_warn_once("%s() PLL get frac mode failed for %s, ret = %d\n",
>  			     __func__, clk_name, ret);
> +		return ret;
> +	}
>  
>  	return ret_payload[1];
>  }
> @@ -140,9 +142,11 @@ static unsigned long zynqmp_pll_recalc_rate(struct clk_hw *hw,
>  	int ret;
>  
>  	ret = zynqmp_pm_clock_getdivider(clk_id, &fbdiv);
> -	if (ret)
> +	if (ret) {
>  		pr_warn_once("%s() get divider failed for %s, ret = %d\n",
>  			     __func__, clk_name, ret);
> +		return -1ul;
> +	}
>  
>  	rate =  parent_rate * fbdiv;
>  	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {

The changes make sense in that the functions error out sensibly when the
zynqmp firmware driver is not enabled.

Acked-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>

Punit


From m.szyprowski at samsung.com  Thu Apr 22 07:12:54 2021
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 22 Apr 2021 08:12:54 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and
 si_perf to siginfo
In-Reply-To: <YIBtr2w/8KhOoiUA@elver.google.com>
References: <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
 <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
 <YIBSg7Vi+U383dT7@elver.google.com>
 <CGME20210421182355eucas1p23b419002936ab5f1ffc25652135cc152@eucas1p2.samsung.com>
 <YIBtr2w/8KhOoiUA@elver.google.com>
Message-ID: <dd99b921-3d79-a21f-8942-40fa5bf53190@samsung.com>

Hi Marco,

On 21.04.2021 20:23, Marco Elver wrote:
> On Wed, Apr 21, 2021 at 06:27PM +0200, Marco Elver wrote:
>> On Wed, Apr 21, 2021 at 05:11PM +0200, Marco Elver wrote:
>>> +Cc linux-arm-kernel
>>>
>> [...]
>>>> I've managed to reproduce this issue with a public Raspberry Pi OS Lite
>>>> rootfs image, even without deploying kernel modules:
>>>>
>>>> https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-03-25/2021-03-04-raspios-buster-armhf-lite.zip
>>>>
>>>> # qemu-system-arm -M virt -smp 2 -m 512 -kernel zImage -append "earlycon
>>>> console=ttyAMA0 root=/dev/vda2 rw rootwait" -serial stdio -display none
>>>> -monitor null -device virtio-blk-device,drive=virtio-blk -drive
>>>> file=/tmp/2021-03-04-raspios-buster-armhf-lite.img,id=virtio-blk,if=none,format=raw
>>>> -netdev user,id=user -device virtio-net-device,netdev=user
>>>>
>>>> The above one doesn't boot if zImage z compiled from commit fb6cc127e0b6
>>>> and boots if compiled from 2e498d0a74e5. In both cases I've used default
>>>> arm/multi_v7_defconfig and
>>>> gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabi toolchain.
>>> Yup, I've narrowed it down to the addition of "__u64 _perf" to
>>> siginfo_t. My guess is the __u64 causes a different alignment for a
>>> bunch of adjacent fields. It seems that x86 and m68k are the only ones
>>> that have compile-time tests for the offsets. Arm should probably add
>>> those -- I have added a bucket of static_assert() in
>>> arch/arm/kernel/signal.c and see that something's off.
>>>
>>> I'll hopefully have a fix in a day or so.
>> Arm and compiler folks: are there some special alignment requirement for
>> __u64 on arm 32-bit? (And if there is for arm64, please shout as well.)
>>
>> With the static-asserts below, the only thing that I can do to fix it is
>> to completely remove the __u64. Padding it before or after with __u32
>> just does not work. It seems that the use of __u64 shifts everything
>> in __sifields by 4 bytes.
>>
>> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
>> index d0bb9125c853..b02a4ac55938 100644
>> --- a/include/uapi/asm-generic/siginfo.h
>> +++ b/include/uapi/asm-generic/siginfo.h
>> @@ -92,7 +92,10 @@ union __sifields {
>>   				__u32 _pkey;
>>   			} _addr_pkey;
>>   			/* used when si_code=TRAP_PERF */
>> -			__u64 _perf;
>> +			struct {
>> +				__u32 _perf1;
>> +				__u32 _perf2;
>> +			} _perf;
>>   		};
>>   	} _sigfault;
>>
>> ^^ works, but I'd hate to have to split this into 2 __u32 because it
>> makes the whole design worse.
>>
>> What alignment trick do we have to do here to fix it for __u64?
> So I think we just have to settle on 'unsigned long' here. On many
> architectures, like 32-bit Arm, the alignment of a structure is that of
> its largest member. This means that there is no portable way to add
> 64-bit integers to siginfo_t on 32-bit architectures.
>
> In the case of the si_perf field, word size is sufficient since the data
> it contains is user-defined. On 32-bit architectures, any excess bits of
> perf_event_attr::sig_data will therefore be truncated when copying into
> si_perf.
>
> Feel free to test the below if you have time, but the below lets me boot
> 32-bit arm which previously timed out. It also passes all the
> static_asserts() I added (will send those as separate patches).
>
> Once I'm convinced this passes all others tests too, I'll send a patch.

This fixes the issue I've observed on my test systems. Feel free to add:

Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>

Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>


> Thanks,
> -- Marco
>
>
> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index c8821d966812..f0d2dd35d408 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -237,7 +237,7 @@ typedef struct compat_siginfo {
>   					u32 _pkey;
>   				} _addr_pkey;
>   				/* used when si_code=TRAP_PERF */
> -				compat_u64 _perf;
> +				compat_ulong_t _perf;
>   			};
>   		} _sigfault;
>   
> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> index d0bb9125c853..03d6f6d2c1fe 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -92,7 +92,7 @@ union __sifields {
>   				__u32 _pkey;
>   			} _addr_pkey;
>   			/* used when si_code=TRAP_PERF */
> -			__u64 _perf;
> +			unsigned long _perf;
>   		};
>   	} _sigfault;
>   
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From rppt at kernel.org  Thu Apr 22 07:18:58 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 09:18:58 +0300
Subject: [PATCH v3 0/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
Message-ID: <20210422061902.21614-1-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Hi,

These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1. 

The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.

With this the core mm will be able to cope with the fact that it cannot use
NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
will be treated correctly even without the need for pfn_valid_within.

The patches are only boot tested on qemu-system-aarch64 so I'd really
appreciate memory stress tests on real hardware.

If this actually works we'll be one step closer to drop custom pfn_valid()
on arm64 altogether.

v3:
* Fix minor issues found by Anshuman
* Freshen up the declaration of pfn_valid() to make it consistent with
  pfn_is_map_memory()
* Add more Acked-by and Reviewed-by tags, thanks Anshuman and David

v2: Link: https://lore.kernel.org/lkml/20210421065108.1987-1-rppt at kernel.org
* Add check for PFN overflow in pfn_is_map_memory()
* Add Acked-by and Reviewed-by tags, thanks David.

v1: Link: https://lore.kernel.org/lkml/20210420090925.7457-1-rppt at kernel.org
* Add comment about the semantics of pfn_valid() as Anshuman suggested
* Extend comments about MEMBLOCK_NOMAP, per Anshuman
* Use pfn_is_map_memory() name for the exported wrapper for
  memblock_is_map_memory(). It is still local to arch/arm64 in the end
  because of header dependency issues.

rfc: Link: https://lore.kernel.org/lkml/20210407172607.8812-1-rppt at kernel.org

Mike Rapoport (4):
  include/linux/mmzone.h: add documentation for pfn_valid()
  memblock: update initialization of reserved pages
  arm64: decouple check whether pfn is in linear map from pfn_valid()
  arm64: drop pfn_valid_within() and simplify pfn_valid()

 arch/arm64/Kconfig              |  3 ---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  3 ++-
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 16 ++++++++++++++--
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 include/linux/memblock.h        |  4 +++-
 include/linux/mmzone.h          | 11 +++++++++++
 mm/memblock.c                   | 28 ++++++++++++++++++++++++++--
 10 files changed, 61 insertions(+), 14 deletions(-)

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.28.0



From rppt at kernel.org  Thu Apr 22 07:18:59 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 09:18:59 +0300
Subject: [PATCH v3 1/4] include/linux/mmzone.h: add documentation for
 pfn_valid()
In-Reply-To: <20210422061902.21614-1-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
Message-ID: <20210422061902.21614-2-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.

The most "generic" version of pfn_valid() used by the configurations with
SPARSEMEM enabled resides in include/linux/mmzone.h so this is the most
suitable place for documentation about semantics of pfn_valid().

Suggested-by: Anshuman Khandual <anshuman.khandual at arm.com>
Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 include/linux/mmzone.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 47946cec7584..961f0eeefb62 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1410,6 +1410,17 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
 #endif
 
 #ifndef CONFIG_HAVE_ARCH_PFN_VALID
+/**
+ * pfn_valid - check if there is a valid memory map entry for a PFN
+ * @pfn: the page frame number to check
+ *
+ * Check if there is a valid memory map entry aka struct page for the @pfn.
+ * Note, that availability of the memory map entry does not imply that
+ * there is actual usable memory at that @pfn. The struct page may
+ * represent a hole or an unusable page frame.
+ *
+ * Return: 1 for PFNs that have memory map entries and 0 otherwise
+ */
 static inline int pfn_valid(unsigned long pfn)
 {
 	struct mem_section *ms;
-- 
2.28.0



From rppt at kernel.org  Thu Apr 22 07:19:00 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 09:19:00 +0300
Subject: [PATCH v3 2/4] memblock: update initialization of reserved pages
In-Reply-To: <20210422061902.21614-1-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
Message-ID: <20210422061902.21614-3-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.

The struct pages for MEMBLOCK_NOMAP regions are kept with the default
values set by the memory map initialization which makes it necessary to
have a special treatment for such pages in pfn_valid() and
pfn_valid_within().

Split out initialization of the reserved pages to a function with a
meaningful name and treat the MEMBLOCK_NOMAP regions the same way as the
reserved regions and mark struct pages for the NOMAP regions as
PageReserved.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
Reviewed-by: David Hildenbrand <david at redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
 include/linux/memblock.h |  4 +++-
 mm/memblock.c            | 28 ++++++++++++++++++++++++++--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5984fff3f175..1b4c97c151ae 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -30,7 +30,9 @@ extern unsigned long long max_possible_pfn;
  * @MEMBLOCK_NONE: no special request
  * @MEMBLOCK_HOTPLUG: hotpluggable region
  * @MEMBLOCK_MIRROR: mirrored region
- * @MEMBLOCK_NOMAP: don't add to kernel direct mapping
+ * @MEMBLOCK_NOMAP: don't add to kernel direct mapping and treat as
+ * reserved in the memory map; refer to memblock_mark_nomap() description
+ * for further details
  */
 enum memblock_flags {
 	MEMBLOCK_NONE		= 0x0,	/* No special request */
diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..3abf2c3fea7f 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -906,6 +906,11 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size)
  * @base: the base phys addr of the region
  * @size: the size of the region
  *
+ * The memory regions marked with %MEMBLOCK_NOMAP will not be added to the
+ * direct mapping of the physical memory. These regions will still be
+ * covered by the memory map. The struct page representing NOMAP memory
+ * frames in the memory map will be PageReserved()
+ *
  * Return: 0 on success, -errno on failure.
  */
 int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
@@ -2002,6 +2007,26 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	return end_pfn - start_pfn;
 }
 
+static void __init memmap_init_reserved_pages(void)
+{
+	struct memblock_region *region;
+	phys_addr_t start, end;
+	u64 i;
+
+	/* initialize struct pages for the reserved regions */
+	for_each_reserved_mem_range(i, &start, &end)
+		reserve_bootmem_region(start, end);
+
+	/* and also treat struct pages for the NOMAP regions as PageReserved */
+	for_each_mem_region(region) {
+		if (memblock_is_nomap(region)) {
+			start = region->base;
+			end = start + region->size;
+			reserve_bootmem_region(start, end);
+		}
+	}
+}
+
 static unsigned long __init free_low_memory_core_early(void)
 {
 	unsigned long count = 0;
@@ -2010,8 +2035,7 @@ static unsigned long __init free_low_memory_core_early(void)
 
 	memblock_clear_hotplug(0, -1);
 
-	for_each_reserved_mem_range(i, &start, &end)
-		reserve_bootmem_region(start, end);
+	memmap_init_reserved_pages();
 
 	/*
 	 * We need to use NUMA_NO_NODE instead of NODE_DATA(0)->node_id
-- 
2.28.0



From rppt at kernel.org  Thu Apr 22 07:19:01 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 09:19:01 +0300
Subject: [PATCH v3 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210422061902.21614-1-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
Message-ID: <20210422061902.21614-4-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.

Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.

Introduce a dedicated pfn_is_map_memory() wrapper for
memblock_is_map_memory() to perform such check and use it where
appropriate.

Using a wrapper allows to avoid cyclic include dependencies.

While here also update style of pfn_valid() so that both pfn_valid() and
pfn_is_map_memory() declarations will be consistent.

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
---
 arch/arm64/include/asm/memory.h |  2 +-
 arch/arm64/include/asm/page.h   |  3 ++-
 arch/arm64/kvm/mmu.c            |  2 +-
 arch/arm64/mm/init.c            | 12 ++++++++++++
 arch/arm64/mm/ioremap.c         |  4 ++--
 arch/arm64/mm/mmu.c             |  2 +-
 6 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..194f9f993d30 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
 
 #define virt_addr_valid(addr)	({					\
 	__typeof__(addr) __addr = __tag_reset(addr);			\
-	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
+	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
 })
 
 void dump_mem_limit(void);
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 012cffc574e8..75ddfe671393 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -37,7 +37,8 @@ void copy_highpage(struct page *to, struct page *from);
 
 typedef struct page *pgtable_t;
 
-extern int pfn_valid(unsigned long);
+int pfn_valid(unsigned long pfn);
+int pfn_is_map_memory(unsigned long pfn);
 
 #include <asm/memory.h>
 
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..23dd99e29b23 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
 
 static bool kvm_is_device_pfn(unsigned long pfn)
 {
-	return !pfn_valid(pfn);
+	return !pfn_is_map_memory(pfn);
 }
 
 /*
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3685e12aba9b..966a7a18d528 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -258,6 +258,18 @@ int pfn_valid(unsigned long pfn)
 }
 EXPORT_SYMBOL(pfn_valid);
 
+int pfn_is_map_memory(unsigned long pfn)
+{
+	phys_addr_t addr = PFN_PHYS(pfn);
+
+	/* avoid false positives for bogus PFNs, see comment in pfn_valid() */
+	if (PHYS_PFN(addr) != pfn)
+		return 0;
+
+	return memblock_is_map_memory(addr);
+}
+EXPORT_SYMBOL(pfn_is_map_memory);
+
 static phys_addr_t memory_limit = PHYS_ADDR_MAX;
 
 /*
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index b5e83c46b23e..b7c81dacabf0 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
 	/*
 	 * Don't allow RAM to be mapped.
 	 */
-	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
 void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
 {
 	/* For normal memory we already have a cacheable mapping. */
-	if (pfn_valid(__phys_to_pfn(phys_addr)))
+	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
 		return (void __iomem *)__phys_to_virt(phys_addr);
 
 	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..26045e9adbd7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
-	if (!pfn_valid(pfn))
+	if (!pfn_is_map_memory(pfn))
 		return pgprot_noncached(vma_prot);
 	else if (file->f_flags & O_SYNC)
 		return pgprot_writecombine(vma_prot);
-- 
2.28.0



From rppt at kernel.org  Thu Apr 22 07:19:02 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 09:19:02 +0300
Subject: [PATCH v3 4/4] arm64: drop pfn_valid_within() and simplify pfn_valid()
In-Reply-To: <20210422061902.21614-1-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
Message-ID: <20210422061902.21614-5-rppt@kernel.org>

From: Mike Rapoport <rppt at linux.ibm.com>

The arm64's version of pfn_valid() differs from the generic because of two
reasons:

* Parts of the memory map are freed during boot. This makes it necessary to
  verify that there is actual physical memory that corresponds to a pfn
  which is done by querying memblock.

* There are NOMAP memory regions. These regions are not mapped in the
  linear map and until the previous commit the struct pages representing
  these areas had default values.

As the consequence of absence of the special treatment of NOMAP regions in
the memory map it was necessary to use memblock_is_map_memory() in
pfn_valid() and to have pfn_valid_within() aliased to pfn_valid() so that
generic mm functionality would not treat a NOMAP page as a normal page.

Since the NOMAP regions are now marked as PageReserved(), pfn walkers and
the rest of core mm will treat them as unusable memory and thus
pfn_valid_within() is no longer required at all and can be disabled by
removing CONFIG_HOLES_IN_ZONE on arm64.

pfn_valid() can be slightly simplified by replacing
memblock_is_map_memory() with memblock_is_memory().

Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
Acked-by: David Hildenbrand <david at redhat.com>
---
 arch/arm64/Kconfig   | 3 ---
 arch/arm64/mm/init.c | 4 ++--
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..58e439046d05 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1040,9 +1040,6 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA
 
-config HOLES_IN_ZONE
-	def_bool y
-
 source "kernel/Kconfig.hz"
 
 config ARCH_SPARSEMEM_ENABLE
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 966a7a18d528..f431b38d0837 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -243,7 +243,7 @@ int pfn_valid(unsigned long pfn)
 
 	/*
 	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_map_memory() check for ZONE_DEVICE based
+	 * memblock_is_memory() check for ZONE_DEVICE based
 	 * addresses will always fail. Even the normal hotplugged
 	 * memory will never have MEMBLOCK_NOMAP flag set in their
 	 * memblock entries. Skip memblock search for all non early
@@ -254,7 +254,7 @@ int pfn_valid(unsigned long pfn)
 		return pfn_section_valid(ms, pfn);
 }
 #endif
-	return memblock_is_map_memory(addr);
+	return memblock_is_memory(addr);
 }
 EXPORT_SYMBOL(pfn_valid);
 
-- 
2.28.0



From lkp at intel.com  Thu Apr 22 07:20:52 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 14:20:52 +0800
Subject: [xlnx:master 11850/12130]
 drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of
 function 'regulator_lock'; did you mean 'regulator_put'?
Message-ID: <202104221445.ydH4CWmQ-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: a6aea4afc0f41390d36b593f455902b6fdd75685 [11850/12130] regulator: da9121: Use core regulator lock
config: nds32-randconfig-r021-20210421 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/a6aea4afc0f41390d36b593f455902b6fdd75685
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout a6aea4afc0f41390d36b593f455902b6fdd75685
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nds32 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/regulator/da9121-regulator.c: In function 'da9121_handle_notifier':
>> drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of function 'regulator_lock'; did you mean 'regulator_put'? [-Werror=implicit-function-declaration]
     748 |   regulator_lock(rdev);
         |   ^~~~~~~~~~~~~~
         |   regulator_put
>> drivers/regulator/da9121-regulator.c:750:3: error: implicit declaration of function 'regulator_unlock'; did you mean 'regulator_enable'? [-Werror=implicit-function-declaration]
     750 |   regulator_unlock(rdev);
         |   ^~~~~~~~~~~~~~~~
         |   regulator_enable
   cc1: some warnings being treated as errors


vim +748 drivers/regulator/da9121-regulator.c

   676	
   677	static inline int da9121_handle_notifier(
   678			struct da9121 *chip, struct regulator_dev *rdev,
   679			unsigned int event_bank, unsigned int event, unsigned int ebit)
   680	{
   681		enum { R0 = 0, R1, R2, REG_MAX_NUM };
   682		unsigned long notification = 0;
   683		int ret = 0;
   684	
   685		if (event & ebit) {
   686			switch (event_bank) {
   687			case DA9121_REG_SYS_EVENT_0:
   688				switch (event & ebit) {
   689				case DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT:
   690					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT;
   691					notification |= REGULATOR_EVENT_OVER_TEMP |
   692							REGULATOR_EVENT_DISABLE;
   693					break;
   694				case DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN:
   695					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN;
   696					notification |= REGULATOR_EVENT_OVER_TEMP;
   697					break;
   698				default:
   699					dev_warn(chip->dev,
   700						 "Unhandled event in bank0 0x%02x\n",
   701						 event & ebit);
   702					ret = -EINVAL;
   703					break;
   704				}
   705				break;
   706			case DA9121_REG_SYS_EVENT_1:
   707				switch (event & ebit) {
   708				case DA9121_MASK_SYS_EVENT_1_E_OV1:
   709					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OV1;
   710					notification |= REGULATOR_EVENT_REGULATION_OUT;
   711					break;
   712				case DA9121_MASK_SYS_EVENT_1_E_UV1:
   713					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_UV1;
   714					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   715					break;
   716				case DA9121_MASK_SYS_EVENT_1_E_OC1:
   717					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OC1;
   718					notification |= REGULATOR_EVENT_OVER_CURRENT;
   719					break;
   720				case DA9xxx_MASK_SYS_EVENT_1_E_OV2:
   721					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OV2;
   722					notification |= REGULATOR_EVENT_REGULATION_OUT;
   723					break;
   724				case DA9xxx_MASK_SYS_EVENT_1_E_UV2:
   725					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_UV2;
   726					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   727					break;
   728				case DA9xxx_MASK_SYS_EVENT_1_E_OC2:
   729					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OC2;
   730					notification |= REGULATOR_EVENT_OVER_CURRENT;
   731					break;
   732				default:
   733					dev_warn(chip->dev,
   734						 "Unhandled event in bank1 0x%02x\n",
   735						 event & ebit);
   736					ret = -EINVAL;
   737					break;
   738				}
   739				break;
   740			default:
   741				dev_warn(chip->dev,
   742					 "Unhandled event bank 0x%02x\n", event_bank);
   743				ret = -EINVAL;
   744				goto error;
   745				break;
   746			}
   747	
 > 748			regulator_lock(rdev);
   749			regulator_notifier_call_chain(rdev, notification, NULL);
 > 750			regulator_unlock(rdev);
   751		}
   752	
   753	error:
   754		return ret;
   755	}
   756	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33483 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/370f4671/attachment-0001.gz>

From alexander.shishkin at linux.intel.com  Thu Apr 22 07:34:55 2021
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Thu, 22 Apr 2021 09:34:55 +0300
Subject: [PATCH] stm class: initialize static variable in declaration
In-Reply-To: <20210407125358.4135345-1-yukuai3@huawei.com>
References: <20210407125358.4135345-1-yukuai3@huawei.com>
Message-ID: <87o8e6esj4.fsf@ashishki-desk.ger.corp.intel.com>

Yu Kuai <yukuai3 at huawei.com> writes:

> mutex lock can be initialized automatically with DEFINE_MUTEX()
> rather than explicitly calling mutex_init().
>
> list head can be initialized automatically with LIST_HEAD() rather
> than explicitly calling INIT_LIST_HEAD().
>
> srcu_struct can be initialized automatically with DEFINE_STATIC_SRCU()
> rather than explicitly calling init_srcu_struct().

What's missing is the "why". We can do these or we can keep them as they
are. Each choice has impact on .text/.data, for instance. Why is one
preferred over the other?

Each patch should contain some form of analysis that shows that the
author thought about why they made the patch in the first
place.

And please learn not to spam the STMicro people with patches for System
Trace Module. Sometimes the same acronym can mean multiple different
things. This is another sign that the patch author spent zero time
getting to know the code that they are patching.

Regards,
--
Alex


From lkp at intel.com  Thu Apr 22 07:37:05 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 14:37:05 +0800
Subject: [xlnx:master 11279/12130]
 drivers/usb/gadget/function/f_tcm.c:2262:12: error: redefinition of
 'tcm_get_alt'
Message-ID: <202104221457.rxVLmK26-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   0605a36e057480f3a83ae401e7ff59739da78e82
commit: c327a8947017ebe78c31d8018092a91b540dab8c [11279/12130] usb: function: f_tcm: Add support for getting alt interface number
config: x86_64-randconfig-r023-20210421 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d87b9b81ccb95217181ce75515c6c68bbb408ca4)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/c327a8947017ebe78c31d8018092a91b540dab8c
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout c327a8947017ebe78c31d8018092a91b540dab8c
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/usb/gadget/function/f_tcm.c:342:12: warning: address of array 'fu->cmd' will always evaluate to 'true' [-Wpointer-bool-conversion]
                   if (!fu->cmd)
                       ~~~~~^~~
>> drivers/usb/gadget/function/f_tcm.c:2262:12: error: redefinition of 'tcm_get_alt'
   static int tcm_get_alt(struct usb_function *f, unsigned int intf)
              ^
   drivers/usb/gadget/function/f_tcm.c:2233:12: note: previous definition is here
   static int tcm_get_alt(struct usb_function *f, unsigned intf)
              ^
   1 warning and 1 error generated.


vim +/tcm_get_alt +2262 drivers/usb/gadget/function/f_tcm.c

  2261	
> 2262	static int tcm_get_alt(struct usb_function *f, unsigned int intf)
  2263	{
  2264		struct f_uas *fu = to_f_uas(f);
  2265	
  2266		return fu->flags & USBG_IS_UAS ? 1 : 0;
  2267	}
  2268	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36260 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/d0f8101c/attachment-0001.gz>

From elver at google.com  Thu Apr 22 07:44:36 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 08:44:36 +0200
Subject: [PATCH tip 1/2] signal,
 perf: Fix siginfo_t by avoiding u64 on 32-bit architectures
Message-ID: <20210422064437.3577327-1-elver@google.com>

On some architectures, like Arm, the alignment of a structure is that of
its largest member.

This means that there is no portable way to add 64-bit integers to
siginfo_t on 32-bit architectures, because siginfo_t does not contain
any 64-bit integers on 32-bit architectures.

In the case of the si_perf field, word size is sufficient since there is
no exact requirement on size, given the data it contains is user-defined
via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
of perf_event_attr::sig_data will therefore be truncated when copying
into si_perf.

Since this field is intended to disambiguate events (e.g. encoding
relevant information if there are more events of the same type), 32 bits
should provide enough entropy to do so on 32-bit architectures.

For 64-bit architectures, no change is intended.

Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
Reported-by: Jon Hunter <jonathanh at nvidia.com>
Signed-off-by: Marco Elver <elver at google.com>
---

Note: I added static_assert()s to verify the siginfo_t layout to
arch/arm and arch/arm64, which caught the problem. I'll send them
separately to arm&arm64 maintainers respectively.
---
 include/linux/compat.h                                | 2 +-
 include/uapi/asm-generic/siginfo.h                    | 2 +-
 tools/testing/selftests/perf_events/sigtrap_threads.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/compat.h b/include/linux/compat.h
index c8821d966812..f0d2dd35d408 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -237,7 +237,7 @@ typedef struct compat_siginfo {
 					u32 _pkey;
 				} _addr_pkey;
 				/* used when si_code=TRAP_PERF */
-				compat_u64 _perf;
+				compat_ulong_t _perf;
 			};
 		} _sigfault;
 
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index d0bb9125c853..03d6f6d2c1fe 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -92,7 +92,7 @@ union __sifields {
 				__u32 _pkey;
 			} _addr_pkey;
 			/* used when si_code=TRAP_PERF */
-			__u64 _perf;
+			unsigned long _perf;
 		};
 	} _sigfault;
 
diff --git a/tools/testing/selftests/perf_events/sigtrap_threads.c b/tools/testing/selftests/perf_events/sigtrap_threads.c
index 9c0fd442da60..78ddf5e11625 100644
--- a/tools/testing/selftests/perf_events/sigtrap_threads.c
+++ b/tools/testing/selftests/perf_events/sigtrap_threads.c
@@ -44,7 +44,7 @@ static struct {
 } ctx;
 
 /* Unique value to check si_perf is correctly set from perf_event_attr::sig_data. */
-#define TEST_SIG_DATA(addr) (~(uint64_t)(addr))
+#define TEST_SIG_DATA(addr) (~(unsigned long)(addr))
 
 static struct perf_event_attr make_event_attr(bool enabled, volatile void *addr)
 {
-- 
2.31.1.498.g6c1eba8ee3d-goog



From elver at google.com  Thu Apr 22 07:44:37 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 08:44:37 +0200
Subject: [PATCH tip 2/2] signal,
 perf: Add missing TRAP_PERF case in siginfo_layout()
In-Reply-To: <20210422064437.3577327-1-elver@google.com>
References: <20210422064437.3577327-1-elver@google.com>
Message-ID: <20210422064437.3577327-2-elver@google.com>

Add the missing TRAP_PERF case in siginfo_layout() for interpreting the
layout correctly as SIL_PERF_EVENT instead of just SIL_FAULT. This
ensures the si_perf field is copied and not just the si_addr field.

This was caught and tested by running the perf_events/sigtrap_threads
kselftest as a 32-bit binary with a 64-bit kernel.

Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
Signed-off-by: Marco Elver <elver at google.com>
---
 kernel/signal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9ed81ee4ff17..b354655a0e57 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3251,6 +3251,8 @@ enum siginfo_layout siginfo_layout(unsigned sig, int si_code)
 			else if ((sig == SIGSEGV) && (si_code == SEGV_PKUERR))
 				layout = SIL_FAULT_PKUERR;
 #endif
+			else if ((sig == SIGTRAP) && (si_code == TRAP_PERF))
+				layout = SIL_PERF_EVENT;
 		}
 		else if (si_code <= NSIGPOLL)
 			layout = SIL_POLL;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From elver at google.com  Thu Apr 22 07:47:13 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 08:47:13 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <dd99b921-3d79-a21f-8942-40fa5bf53190@samsung.com>
References: <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
 <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
 <YIBSg7Vi+U383dT7@elver.google.com>
 <CGME20210421182355eucas1p23b419002936ab5f1ffc25652135cc152@eucas1p2.samsung.com>
 <YIBtr2w/8KhOoiUA@elver.google.com>
 <dd99b921-3d79-a21f-8942-40fa5bf53190@samsung.com>
Message-ID: <CANpmjNPbMOUd_Wh5aHGdH8WLrYpyBFUpwx6g3Kj2D6eevvaU8w@mail.gmail.com>

On Thu, 22 Apr 2021 at 08:12, Marek Szyprowski <m.szyprowski at samsung.com> wrote:
[...]
> > So I think we just have to settle on 'unsigned long' here. On many
> > architectures, like 32-bit Arm, the alignment of a structure is that of
> > its largest member. This means that there is no portable way to add
> > 64-bit integers to siginfo_t on 32-bit architectures.
> >
> > In the case of the si_perf field, word size is sufficient since the data
> > it contains is user-defined. On 32-bit architectures, any excess bits of
> > perf_event_attr::sig_data will therefore be truncated when copying into
> > si_perf.
> >
> > Feel free to test the below if you have time, but the below lets me boot
> > 32-bit arm which previously timed out. It also passes all the
> > static_asserts() I added (will send those as separate patches).
> >
> > Once I'm convinced this passes all others tests too, I'll send a patch.
>
> This fixes the issue I've observed on my test systems. Feel free to add:
>
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
>
> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>

Thank you for testing! It's been sent:
https://lkml.kernel.org/r/20210422064437.3577327-1-elver at google.com

Thanks,
-- Marco


From maz at kernel.org  Thu Apr 22 07:50:02 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 22 Apr 2021 07:50:02 +0100
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
 <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
Message-ID: <87v98eq0dh.wl-maz@kernel.org>

On Thu, 22 Apr 2021 03:02:00 +0100,
Gavin Shan <gshan at redhat.com> wrote:
> 
> Hi Marc,
> 
> On 4/21/21 9:59 PM, Marc Zyngier wrote:
> > On Wed, 21 Apr 2021 07:17:44 +0100,
> > Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >> On 2021/4/21 14:20, Gavin Shan wrote:
> >>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
> >>>> On 2020/10/22 0:16, Santosh Shukla wrote:
> >>>>> The Commit:6d674e28 introduces a notion to detect and handle the
> >>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
> >>>>> in vma->flags and if set then marks force_pte to true such that
> >>>>> if force_pte is true then ignore the THP function check
> >>>>> (/transparent_hugepage_adjust()).
> >>>>> 
> >>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
> >>>>> For example consider a case where the mdev vendor driver register's
> >>>>> the vma_fault handler named vma_mmio_fault(), which maps the
> >>>>> host MMIO region in-turn calls remap_pfn_range() and maps
> >>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
> >>>>> the VM_PFNMAP flag into vma->flags.
> >>>> Could you give the name of the mdev vendor driver that triggers this issue?
> >>>> I failed to find one according to your description. Thanks.
> >>>> 
> >>> 
> >>> I think it would be fixed in driver side to set VM_PFNMAP in
> >>> its mmap() callback (call_mmap()), like vfio PCI driver does.
> >>> It means it won't be delayed until page fault is issued and
> >>> remap_pfn_range() is called. It's determined from the beginning
> >>> that the vma associated the mdev vendor driver is serving as
> >>> PFN remapping purpose. So the vma should be populated completely,
> >>> including the VM_PFNMAP flag before it becomes visible to user
> >>> space.
> > 
> > Why should that be a requirement? Lazy populating of the VMA should be
> > perfectly acceptable if the fault can only happen on the CPU side.
> > 
> 
> It isn't a requirement and the drivers needn't follow strictly. I checked
> several drivers before looking into the patch and found almost all the
> drivers have VM_PFNMAP set at mmap() time. In drivers/vfio/vfio-pci.c,
> there is a comment as below, but it doesn't reveal too much about why
> we can't set VM_PFNMAP at fault time.
> 
> static int vfio_pci_mmap(void *device_data, 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.
>          */
>         vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
>         vma->vm_ops = &vfio_pci_mmap_ops;
> 
>         return 0;
> }
> 
> To set these flags in advance does have advantages. For example,
> VM_DONTEXPAND prevents the vma to be merged with another
> one. VM_DONTDUMP make this vma isn't eligible for
> coredump. Otherwise, the address space, which is associated with the
> vma is accessed and unnecessary page faults are triggered on
> coredump.  VM_IO and VM_PFNMAP avoids to walk the page frames
> associated with the vma since we don't have valid PFN in the
> mapping.

But PCI clearly isn't the case we are dealing with here, and not
everything is VFIO either. I can *today* create a driver that
implements a mmap+fault handler, call mmap() on it, pass the result to
a memslot, and get to the exact same result Santosh describes.

No PCI, no VFIO, just a random driver. We are *required* to handle
that.

	M.

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


From maz at kernel.org  Thu Apr 22 07:51:36 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 22 Apr 2021 07:51:36 +0100
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <46606f3e-ef41-6520-6647-88c0f76a83e0@redhat.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>
 <105a403a-e48b-15bc-44ff-0ff34f7d2194@huawei.com>
 <46606f3e-ef41-6520-6647-88c0f76a83e0@redhat.com>
Message-ID: <87tunyq0av.wl-maz@kernel.org>

On Thu, 22 Apr 2021 03:25:23 +0100,
Gavin Shan <gshan at redhat.com> wrote:
> 
> Hi Keqian,
> 
> On 4/21/21 4:36 PM, Keqian Zhu wrote:
> > On 2021/4/21 15:52, Gavin Shan wrote:
> >> On 4/16/21 12:03 AM, Keqian Zhu wrote:
> >>> The MMIO region of a device maybe huge (GB level), try to use
> >>> block mapping in stage2 to speedup both map and unmap.
> >>> 
> >>> Compared to normal memory mapping, we should consider two more
> >>> points when try block mapping for MMIO region:
> >>> 
> >>> 1. For normal memory mapping, the PA(host physical address) and
> >>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> >>> the HVA to request hugepage, so we don't need to consider PA
> >>> alignment when verifing block mapping. But for device memory
> >>> mapping, the PA and HVA may have different alignment.
> >>> 
> >>> 2. For normal memory mapping, we are sure hugepage size properly
> >>> fit into vma, so we don't check whether the mapping size exceeds
> >>> the boundary of vma. But for device memory mapping, we should pay
> >>> attention to this.
> >>> 
> >>> This adds get_vma_page_shift() to get page shift for both normal
> >>> memory and device MMIO region, and check these two points when
> >>> selecting block mapping size for MMIO region.
> >>> 
> >>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> >>> ---
> >>>    arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
> >>>    1 file changed, 51 insertions(+), 10 deletions(-)
> >>> 
> >>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> >>> index c59af5ca01b0..5a1cc7751e6d 100644
> >>> --- a/arch/arm64/kvm/mmu.c
> >>> +++ b/arch/arm64/kvm/mmu.c
> >>> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
> >>>        return PAGE_SIZE;
> >>>    }
> >>>    +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> >>> +{
> >>> +    unsigned long pa;
> >>> +
> >>> +    if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> >>> +        return huge_page_shift(hstate_vma(vma));
> >>> +
> >>> +    if (!(vma->vm_flags & VM_PFNMAP))
> >>> +        return PAGE_SHIFT;
> >>> +
> >>> +    VM_BUG_ON(is_vm_hugetlb_page(vma));
> >>> +
> >> 
> >> I don't understand how VM_PFNMAP is set for hugetlbfs related vma.
> >> I think they are exclusive, meaning the flag is never set for
> >> hugetlbfs vma. If it's true, VM_PFNMAP needn't be checked on hugetlbfs
> >> vma and the VM_BUG_ON() becomes unnecessary.
> > Yes, but we're not sure all drivers follow this rule. Add a BUG_ON() is
> > a way to catch issue.
> > 
> 
> I think I didn't make things clear. What I meant is VM_PFNMAP can't
> be set for hugetlbfs VMAs. So the checks here can be simplified as
> below if you agree:
> 
>     if (is_vm_hugetlb_page(vma))
>         return huge_page_shift(hstate_vma(vma));
> 
>     if (!(vma->vm_flags & VM_PFNMAP))
>         return PAGE_SHIFT;
> 
>     VM_BUG_ON(is_vm_hugetlb_page(vma));       /* Can be dropped */

No. If this case happens, I want to see it. I have explicitly asked
for it, and this check stays.

	M.

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


From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:20 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:20 +0200
Subject: [PATCH v5 0/6] clk: provide new devm helpers for prepared and enabled
 clocks
Message-ID: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>

Hello,

the only change since v5 is that the fixed i2c patch is now properly
part of this series.

Can I please get a feedback by the clock maintainers? The series got
positive feedback by several people now and is still unreplied by by the
clk maintainers since October. Should I resend regularly, say once per
two weeks? How many digits do I have to consider for the resend counter?
At what point can I ask the maintainers further up in the chain to merge
my series? Does a pull request help?

Best regards
Uwe

Uwe Kleine-K?nig (6):
  clk: generalize devm_clk_get() a bit
  clk: Provide new devm_clk_helpers for prepared and enabled clocks
  pwm: atmel: Simplify using devm_clk_get_prepared()
  rtc: at91sma9: Simplify using devm_clk_get_enabled()
  i2c: imx: Simplify using devm_clk_get_enableded()
  spi: davinci: Simplify using devm_clk_get_enabled()

 drivers/clk/clk-devres.c     | 96 ++++++++++++++++++++++++++++++------
 drivers/i2c/busses/i2c-imx.c | 12 +----
 drivers/pwm/pwm-atmel.c      | 15 +-----
 drivers/rtc/rtc-at91sam9.c   | 22 ++-------
 drivers/spi/spi-davinci.c    | 11 +----
 include/linux/clk.h          | 87 +++++++++++++++++++++++++++++++-
 6 files changed, 176 insertions(+), 67 deletions(-)


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:25 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:25 +0200
Subject: [PATCH v5 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-6-u.kleine-koenig@pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>
Acked-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/i2c/busses/i2c-imx.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b80fdc1f0092..d6594358cf83 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1405,16 +1405,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
 
 	/* Get I2C clock */
-	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
+	i2c_imx->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(i2c_imx->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
-				     "can't get I2C clock\n");
-
-	ret = clk_prepare_enable(i2c_imx->clk);
-	if (ret) {
-		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
-		return ret;
-	}
+				     "can't get prepared I2C clock\n");
 
 	/* Init queue */
 	init_waitqueue_head(&i2c_imx->queue);
@@ -1487,7 +1481,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-	clk_disable_unprepare(i2c_imx->clk);
 	return ret;
 }
 
@@ -1517,7 +1510,6 @@ static int i2c_imx_remove(struct platform_device *pdev)
 	irq = platform_get_irq(pdev, 0);
 	if (irq >= 0)
 		free_irq(irq, i2c_imx);
-	clk_disable_unprepare(i2c_imx->clk);
 
 	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:21 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:21 +0200
Subject: [PATCH v5 1/6] clk: generalize devm_clk_get() a bit
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-2-u.kleine-koenig@pengutronix.de>

Allow to add an exit hook to devm managed clocks. Also use
clk_get_optional() in devm_clk_get_optional instead of open coding it.
The generalisation will be used in the next commit to add some more
devm_clk helpers.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk-devres.c | 67 ++++++++++++++++++++++++++++++----------
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index be160764911b..91c995815b57 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -4,39 +4,72 @@
 #include <linux/export.h>
 #include <linux/gfp.h>
 
+struct devm_clk_state {
+	struct clk *clk;
+	void (*exit)(struct clk *clk);
+};
+
 static void devm_clk_release(struct device *dev, void *res)
 {
-	clk_put(*(struct clk **)res);
+	struct devm_clk_state *state = *(struct devm_clk_state **)res;
+
+	if (state->exit)
+		state->exit(state->clk);
+
+	clk_put(state->clk);
 }
 
-struct clk *devm_clk_get(struct device *dev, const char *id)
+static struct clk *__devm_clk_get(struct device *dev, const char *id,
+				  struct clk *(*get)(struct device *dev, const char *id),
+				  int (*init)(struct clk *clk),
+				  void (*exit)(struct clk *clk))
 {
-	struct clk **ptr, *clk;
+	struct devm_clk_state *state;
+	struct clk *clk;
+	int ret;
 
-	ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
-	if (!ptr)
+	state = devres_alloc(devm_clk_release, sizeof(*state), GFP_KERNEL);
+	if (!state)
 		return ERR_PTR(-ENOMEM);
 
-	clk = clk_get(dev, id);
-	if (!IS_ERR(clk)) {
-		*ptr = clk;
-		devres_add(dev, ptr);
-	} else {
-		devres_free(ptr);
+	clk = get(dev, id);
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		goto err_clk_get;
 	}
 
+	if (init) {
+		ret = init(clk);
+		if (ret)
+			goto err_clk_init;
+	}
+
+	state->clk = clk;
+	state->exit = exit;
+
+	devres_add(dev, state);
+
 	return clk;
+
+err_clk_init:
+
+	clk_put(clk);
+err_clk_get:
+
+	devres_free(state);
+	return ERR_PTR(ret);
 }
-EXPORT_SYMBOL(devm_clk_get);
 
-struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+struct clk *devm_clk_get(struct device *dev, const char *id)
 {
-	struct clk *clk = devm_clk_get(dev, id);
+	return __devm_clk_get(dev, id, clk_get, NULL, NULL);
 
-	if (clk == ERR_PTR(-ENOENT))
-		return NULL;
+}
+EXPORT_SYMBOL(devm_clk_get);
 
-	return clk;
+struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
 }
 EXPORT_SYMBOL(devm_clk_get_optional);
 
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:22 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:22 +0200
Subject: [PATCH v5 2/6] clk: Provide new devm_clk_helpers for prepared and
 enabled clocks
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-3-u.kleine-koenig@pengutronix.de>

When a driver keeps a clock prepared (or enabled) during the whole
lifetime of the driver, these helpers allow to simplify the drivers.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk-devres.c | 31 ++++++++++++++
 include/linux/clk.h      | 87 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 91c995815b57..b54f7f0f2a35 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -67,12 +67,43 @@ struct clk *devm_clk_get(struct device *dev, const char *id)
 }
 EXPORT_SYMBOL(devm_clk_get);
 
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get, clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_prepared);
+
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get,
+			      clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_enabled);
+
 struct clk *devm_clk_get_optional(struct device *dev, const char *id)
 {
 	return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
 }
 EXPORT_SYMBOL(devm_clk_get_optional);
 
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional,
+			      clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_prepared);
+
+struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional,
+			      clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_enabled);
+
 struct clk_bulk_devres {
 	struct clk_bulk_data *clks;
 	int num_clks;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 266e8de3cb51..b3c5da388b08 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -449,7 +449,7 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
  * the clock producer.  (IOW, @id may be identical strings, but
  * clk_get may return different clock producers depending on @dev.)
  *
- * Drivers must assume that the clock source is not enabled.
+ * Drivers must assume that the clock source is neither prepared nor enabled.
  *
  * devm_clk_get should not be called from within interrupt context.
  *
@@ -458,6 +458,47 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
  */
 struct clk *devm_clk_get(struct device *dev, const char *id);
 
+/**
+ * devm_clk_get_prepared - devm_clk_get() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer.  (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared. Drivers must however assume that the
+ * clock is not enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id);
+
+/**
+ * devm_clk_get_enabled - devm_clk_get() + clk_prepare_enable()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer.  (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared and enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be disabled, unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id);
+
 /**
  * devm_clk_get_optional - lookup and obtain a managed reference to an optional
  *			   clock producer.
@@ -469,6 +510,26 @@ struct clk *devm_clk_get(struct device *dev, const char *id);
  */
 struct clk *devm_clk_get_optional(struct device *dev, const char *id);
 
+/**
+ * devm_clk_get_optional_prepared - devm_clk_get_optional() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Behaves the same as devm_clk_get_prepared() except where there is no clock producer.
+ * In this case, instead of returning -ENOENT, the function returns NULL.
+ */
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const char *id);
+
+/**
+ * devm_clk_get_optional_enabled - devm_clk_get_optional() + clk_prepare_enable()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Behaves the same as devm_clk_get_enabled() except where there is no clock producer.
+ * In this case, instead of returning -ENOENT, the function returns NULL.
+ */
+struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id);
+
 /**
  * devm_get_clk_from_child - lookup and obtain a managed reference to a
  *			     clock producer from child node.
@@ -813,12 +874,36 @@ static inline struct clk *devm_clk_get(struct device *dev, const char *id)
 	return NULL;
 }
 
+static inline struct clk *devm_clk_get_prepared(struct device *dev,
+						const char *id)
+{
+	return NULL;
+}
+
+static inline struct clk *devm_clk_get_enabled(struct device *dev,
+					       const char *id)
+{
+	return NULL;
+}
+
 static inline struct clk *devm_clk_get_optional(struct device *dev,
 						const char *id)
 {
 	return NULL;
 }
 
+static inline struct clk *devm_clk_get_optional_prepared(struct device *dev,
+							 const char *id)
+{
+	return NULL;
+}
+
+static inline struct clk *devm_clk_get_optional_enabled(struct device *dev,
+							const char *id)
+{
+	return NULL;
+}
+
 static inline int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
 						 struct clk_bulk_data *clks)
 {
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:26 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:26 +0200
Subject: [PATCH v5 6/6] spi: davinci: Simplify using devm_clk_get_enabled()
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-7-u.kleine-koenig@pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Acked-by: Mark Brown <broonie at kernel.org>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/spi/spi-davinci.c | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 7453a1dbbc06..63ee918ecdb0 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -936,14 +936,11 @@ static int davinci_spi_probe(struct platform_device *pdev)
 
 	dspi->bitbang.master = master;
 
-	dspi->clk = devm_clk_get(&pdev->dev, NULL);
+	dspi->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(dspi->clk)) {
 		ret = -ENODEV;
 		goto free_master;
 	}
-	ret = clk_prepare_enable(dspi->clk);
-	if (ret)
-		goto free_master;
 
 	master->use_gpio_descriptors = true;
 	master->dev.of_node = pdev->dev.of_node;
@@ -968,7 +965,7 @@ static int davinci_spi_probe(struct platform_device *pdev)
 
 	ret = davinci_spi_request_dma(dspi);
 	if (ret == -EPROBE_DEFER) {
-		goto free_clk;
+		goto free_master;
 	} else if (ret) {
 		dev_info(&pdev->dev, "DMA is not supported (%d)\n", ret);
 		dspi->dma_rx = NULL;
@@ -1012,8 +1009,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
 		dma_release_channel(dspi->dma_rx);
 		dma_release_channel(dspi->dma_tx);
 	}
-free_clk:
-	clk_disable_unprepare(dspi->clk);
 free_master:
 	spi_master_put(master);
 err:
@@ -1039,8 +1034,6 @@ static int davinci_spi_remove(struct platform_device *pdev)
 
 	spi_bitbang_stop(&dspi->bitbang);
 
-	clk_disable_unprepare(dspi->clk);
-
 	if (dspi->dma_rx) {
 		dma_release_channel(dspi->dma_rx);
 		dma_release_channel(dspi->dma_tx);
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:24 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:24 +0200
Subject: [PATCH v5 4/6] rtc: at91sma9: Simplify using devm_clk_get_enabled()
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-5-u.kleine-koenig@pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/rtc/rtc-at91sam9.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index 2216be429ab7..b52e7bd26303 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -374,21 +374,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	rtc->sclk = devm_clk_get(&pdev->dev, NULL);
+	rtc->sclk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(rtc->sclk))
 		return PTR_ERR(rtc->sclk);
 
-	ret = clk_prepare_enable(rtc->sclk);
-	if (ret) {
-		dev_err(&pdev->dev, "Could not enable slow clock\n");
-		return ret;
-	}
-
 	sclk_rate = clk_get_rate(rtc->sclk);
 	if (!sclk_rate || sclk_rate > AT91_RTT_RTPRES) {
 		dev_err(&pdev->dev, "Invalid slow clock rate\n");
-		ret = -EINVAL;
-		goto err_clk;
+		return -EINVAL;
 	}
 
 	mr = rtt_readl(rtc, MR);
@@ -406,7 +399,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
 	rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
 	if (IS_ERR(rtc->rtcdev)) {
 		ret = PTR_ERR(rtc->rtcdev);
-		goto err_clk;
+		return ret;
 	}
 
 	rtc->rtcdev->ops = &at91_rtc_ops;
@@ -418,7 +411,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
 			       dev_name(&rtc->rtcdev->dev), rtc);
 	if (ret) {
 		dev_dbg(&pdev->dev, "can't share IRQ %d?\n", rtc->irq);
-		goto err_clk;
+		return ret;
 	}
 
 	/* NOTE:  sam9260 rev A silicon has a ROM bug which resets the
@@ -432,11 +425,6 @@ static int at91_rtc_probe(struct platform_device *pdev)
 			 dev_name(&rtc->rtcdev->dev));
 
 	return devm_rtc_register_device(rtc->rtcdev);
-
-err_clk:
-	clk_disable_unprepare(rtc->sclk);
-
-	return ret;
 }
 
 /*
@@ -450,8 +438,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
 	/* disable all interrupts */
 	rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
 
-	clk_disable_unprepare(rtc->sclk);
-
 	return 0;
 }
 
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Thu Apr 22 07:57:23 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 08:57:23 +0200
Subject: [PATCH v5 3/6] pwm: atmel: Simplify using devm_clk_get_prepared()
In-Reply-To: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422065726.1646742-4-u.kleine-koenig@pengutronix.de>

With devm_clk_get_prepared() caring to unprepare the clock the error
path and remove callback can be simplified accordingly.

Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pwm/pwm-atmel.c | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 5813339b597b..d65e23da2582 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -415,16 +415,10 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(atmel_pwm->base))
 		return PTR_ERR(atmel_pwm->base);
 
-	atmel_pwm->clk = devm_clk_get(&pdev->dev, NULL);
+	atmel_pwm->clk = devm_clk_get_prepared(&pdev->dev, NULL);
 	if (IS_ERR(atmel_pwm->clk))
 		return PTR_ERR(atmel_pwm->clk);
 
-	ret = clk_prepare(atmel_pwm->clk);
-	if (ret) {
-		dev_err(&pdev->dev, "failed to prepare PWM clock\n");
-		return ret;
-	}
-
 	atmel_pwm->chip.dev = &pdev->dev;
 	atmel_pwm->chip.ops = &atmel_pwm_ops;
 	atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
@@ -435,23 +429,18 @@ static int atmel_pwm_probe(struct platform_device *pdev)
 	ret = pwmchip_add(&atmel_pwm->chip);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "failed to add PWM chip %d\n", ret);
-		goto unprepare_clk;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, atmel_pwm);
 
 	return ret;
-
-unprepare_clk:
-	clk_unprepare(atmel_pwm->clk);
-	return ret;
 }
 
 static int atmel_pwm_remove(struct platform_device *pdev)
 {
 	struct atmel_pwm_chip *atmel_pwm = platform_get_drvdata(pdev);
 
-	clk_unprepare(atmel_pwm->clk);
 	mutex_destroy(&atmel_pwm->isr_lock);
 
 	return pwmchip_remove(&atmel_pwm->chip);
-- 
2.30.2



From wangkefeng.wang at huawei.com  Thu Apr 22 08:00:20 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Thu, 22 Apr 2021 15:00:20 +0800
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <20210421065108.1987-1-rppt@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
Message-ID: <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>


On 2021/4/21 14:51, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
>
> Hi,
>
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1.
>
> The idea is to mark NOMAP pages as reserved in the memory map and restore
> the intended semantics of pfn_valid() to designate availability of struct
> page for a pfn.
>
> With this the core mm will be able to cope with the fact that it cannot use
> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> will be treated correctly even without the need for pfn_valid_within.
>
> The patches are only boot tested on qemu-system-aarch64 so I'd really
> appreciate memory stress tests on real hardware.
>
> If this actually works we'll be one step closer to drop custom pfn_valid()
> on arm64 altogether.

Hi Mike?I have a question, without HOLES_IN_ZONE, the pfn_valid_within() 
in move_freepages_block()->move_freepages()
will be optimized, if there are holes in zone, the 'struce page'(memory 
map) for pfn range of hole will be free by
free_memmap(), and then the page traverse in the zone(with holes) from 
move_freepages() will meet the wrong page?
then it could panic at PageLRU(page) test, check link[1],

"The idea is to mark NOMAP pages as reserved in the memory map", I see 
the patch2 check memblock_is_nomap() in memory region
of memblock, but it seems that memblock_mark_nomap() is not called(maybe 
I missed), then memmap_init_reserved_pages() won't
work, so should the HOLES_IN_ZONE still be needed for generic mm code?

[1] 
https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047 at arm.com/



From wangqing at vivo.com  Thu Apr 22 08:05:49 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Thu, 22 Apr 2021 15:05:49 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSCBWNiAxLzJdIHdhdGNoZG9nOiBtdGs6IHN1cHBvcnQgcHJlLXRpbWVvdXQgd2hlbiB0aGUgYmFyayBpcnEgaXMgYXZhaWxhYmxl?=
In-Reply-To: <26bed2e5-6ec8-72ae-ff2c-c707c00d5125@roeck-us.net>
Message-ID: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com>


>On 4/21/21 8:46 PM, ?? wrote:
>> 
>>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>> triggered first, then the timing restarts. The reset signal will be
>>>> initiated when the timer expires again.
>>>>
>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>
>>>> V2:
>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>
>>>> V3:
>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>> - is processed and wait until timeout.
>>>>
>>>> V4:
>>>> - Remove pretimeout related processing. 
>>>> - Add dual mode control separately.
>>>>
>>>> V5:
>>>> - Fix some formatting and printing problems.
>>>>
>>>> V6:
>>>> - Realize pretimeout processing through dualmode.
>>>>
>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..ebc648b
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>  {
>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	unsigned int timeout_interval;
>>>>  	u32 reg;
>>>>  
>>>> -	wdt_dev->timeout = timeout;
>>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>>> +	/*
>>>> +	 * In dual mode, irq will be triggered at timeout/2
>>>> +	 * the real timeout occurs at timeout
>>>> +	 */
>>>> +	if (wdt_dev->pretimeout)
>>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>>
>>> Please run checkpatch --strict and fix what it reports.
>>> Also, there should be a set_pretimeout function to set the
>>> pretimeout. It is ok to update it here, but it should be set
>>> in its own function to make sure that the actual value
>>> is reported back to userspace.
>>>
>>> Thanks,
>>> Guenter
>> 
>> The reason why the set_pretimeout interface is not provided is 
>> because the pretimeout is fixed after the timeout is set,  we need
>> to modify timeout after setting pretimeout, which is puzzling.
>> 
>
>What you need to do is to set pretimeout = timeout / 2 if a pretimeout
>is set to a value != 0. Just like we adjust timeout to valid values
>when set, we adjust pretimeout as well. I don't see a problem with that.
>
>Guenter

Thanks, Guenter. But this will complicate the situation:
First, set_pretimeout will become an interface for dynamically enable and
disable the pre-timeout func, instead of adjusting the pretimeout time. 

Secondly, when the irq is not registered, the user cannot be allowed to set
the pretimeout to non-zero. When irq is registered, it doesn't make any sense
to turn off pre-timeout func. 

Because of the particularity of dual mode, I still insist on enabling the
pretimeout or not through devicetree. And looking forward to your suggestions.

Thanks,
Qing



From benjamin.gaignard at collabora.com  Thu Apr 22 08:24:39 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 09:24:39 +0200
Subject: [PATCH 0/3] IOMMU: Add driver for rk356x
Message-ID: <20210422072442.111070-1-benjamin.gaignard@collabora.com>

This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of 
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.

Benjamin

Benjamin Gaignard (2):
  dt-bindings: iommu: rockchip: Convert IOMMU to DT schema
  dt-bindings: iommu: rockchip: Add compatible for v2

Simon Xue (1):
  iommu: rockchip: Add support iommu v2

 .../bindings/iommu/rockchip,iommu.txt         |  38 --
 .../bindings/iommu/rockchip,iommu.yaml        |  78 ++++
 drivers/iommu/rockchip-iommu.c                | 422 +++++++++++++++++-
 3 files changed, 484 insertions(+), 54 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 08:24:40 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 09:24:40 +0200
Subject: [PATCH 1/3] dt-bindings: iommu: rockchip: Convert IOMMU to DT schema
In-Reply-To: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
References: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422072442.111070-2-benjamin.gaignard@collabora.com>

Convert Rockchip IOMMU to DT schema

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 .../bindings/iommu/rockchip,iommu.txt         | 38 ----------
 .../bindings/iommu/rockchip,iommu.yaml        | 76 +++++++++++++++++++
 2 files changed, 76 insertions(+), 38 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
deleted file mode 100644
index 6ecefea1c6f9..000000000000
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Rockchip IOMMU
-==============
-
-A Rockchip DRM iommu translates io virtual addresses to physical addresses for
-its master device.  Each slave device is bound to a single master device, and
-shares its clocks, power domain and irq.
-
-Required properties:
-- compatible      : Should be "rockchip,iommu"
-- reg             : Address space for the configuration registers
-- interrupts      : Interrupt specifier for the IOMMU instance
-- interrupt-names : Interrupt name for the IOMMU instance
-- #iommu-cells    : Should be <0>.  This indicates the iommu is a
-                    "single-master" device, and needs no additional information
-                    to associate with its master device.  See:
-                    Documentation/devicetree/bindings/iommu/iommu.txt
-- clocks          : A list of clocks required for the IOMMU to be accessible by
-                    the host CPU.
-- clock-names     : Should contain the following:
-	"iface" - Main peripheral bus clock (PCLK/HCL) (required)
-	"aclk"  - AXI bus clock (required)
-
-Optional properties:
-- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
-			       Some mmu instances may produce unexpected results
-			       when the reset operation is used.
-
-Example:
-
-	vopl_mmu: iommu at ff940300 {
-		compatible = "rockchip,iommu";
-		reg = <0xff940300 0x100>;
-		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "vopl_mmu";
-		clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
-		clock-names = "aclk", "iface";
-		#iommu-cells = <0>;
-	};
diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
new file mode 100644
index 000000000000..ab128f8e4c73
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip IOMMU
+
+maintainers:
+  - Simon Xue <xxm at rock-chips.com>
+
+description: |+
+  A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+  its master device. Each slave device is bound to a single master device, and
+  shares its clocks, power domain and irq.
+
+  For information on assigning IOMMU controller to its peripheral devices,
+  see generic IOMMU bindings.
+
+properties:
+  compatible:
+    const: rockchip,iommu
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  interrupt-names:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: Core clock
+      - description: Interface clock
+
+  clock-names:
+    items:
+      - const: aclk
+      - const: iface
+
+  "#iommu-cells":
+    const: 0
+
+  rockchip,disable-mmu-reset:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description: |
+      Don't use the mmu reset operation.
+      Some mmu instances may produce unexpected results
+      when the reset operation is used.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3399-cru.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    vopl_mmu: iommu at ff940300 {
+      compatible = "rockchip,iommu";
+      reg = <0xff940300 0x100>;
+      interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+      interrupt-names = "vopl_mmu";
+      clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
+      clock-names = "aclk", "iface";
+      #iommu-cells = <0>;
+    };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 08:24:41 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 09:24:41 +0200
Subject: [PATCH 2/3] dt-bindings: iommu: rockchip: Add compatible for v2
In-Reply-To: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
References: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422072442.111070-3-benjamin.gaignard@collabora.com>

Add compatible for the second version of IOMMU hardware block.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index ab128f8e4c73..76710dcdc3e4 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -19,7 +19,9 @@ description: |+
 
 properties:
   compatible:
-    const: rockchip,iommu
+    enum:
+      - rockchip,iommu
+      - rockchip,iommu-v2
 
   reg:
     maxItems: 1
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 08:24:42 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 09:24:42 +0200
Subject: [PATCH 3/3] iommu: rockchip: Add support iommu v2
In-Reply-To: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
References: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422072442.111070-4-benjamin.gaignard@collabora.com>

From: Simon Xue <xxm at rock-chips.com>

RK356x SoC got new IOMMU hardware block (version 2).
Add a compatible to distinguish it from the first version.

Signed-off-by: Simon Xue <xxm at rock-chips.com>
[Benjamin]
- port driver from kernel 4.19 to 5.12
- change functions prototype.
- squash all fixes in this commit.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 drivers/iommu/rockchip-iommu.c | 422 +++++++++++++++++++++++++++++++--
 1 file changed, 406 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index e5d86b7177de..0d345d0f44fc 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -19,6 +19,7 @@
 #include <linux/iopoll.h>
 #include <linux/list.h>
 #include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/of_iommu.h>
@@ -81,6 +82,30 @@
   */
 #define RK_IOMMU_PGSIZE_BITMAP 0x007ff000
 
+#define DT_LO_MASK 0xfffff000
+#define DT_HI_MASK GENMASK_ULL(39, 32)
+#define DT_SHIFT   28
+
+#define DTE_BASE_HI_MASK GENMASK(11, 4)
+
+#define PAGE_DESC_LO_MASK   0xfffff000
+#define PAGE_DESC_HI1_LOWER 32
+#define PAGE_DESC_HI1_UPPER 35
+#define PAGE_DESC_HI2_LOWER 36
+#define PAGE_DESC_HI2_UPPER 39
+#define PAGE_DESC_HI_MASK1  GENMASK_ULL(PAGE_DESC_HI1_UPPER, PAGE_DESC_HI1_LOWER)
+#define PAGE_DESC_HI_MASK2  GENMASK_ULL(PAGE_DESC_HI2_UPPER, PAGE_DESC_HI2_LOWER)
+
+#define DTE_HI1_LOWER 8
+#define DTE_HI1_UPPER 11
+#define DTE_HI2_LOWER 4
+#define DTE_HI2_UPPER 7
+#define DTE_HI_MASK1  GENMASK(DTE_HI1_UPPER, DTE_HI1_LOWER)
+#define DTE_HI_MASK2  GENMASK(DTE_HI2_UPPER, DTE_HI2_LOWER)
+
+#define PAGE_DESC_HI_SHIFT1 (PAGE_DESC_HI1_LOWER - DTE_HI1_LOWER)
+#define PAGE_DESC_HI_SHIFT2 (PAGE_DESC_HI2_LOWER - DTE_HI2_LOWER)
+
 struct rk_iommu_domain {
 	struct list_head iommus;
 	u32 *dt; /* page directory table */
@@ -91,6 +116,10 @@ struct rk_iommu_domain {
 	struct iommu_domain domain;
 };
 
+struct rockchip_iommu_data {
+	u32 version;
+};
+
 /* list of clocks required by IOMMU */
 static const char * const rk_iommu_clocks[] = {
 	"aclk", "iface",
@@ -108,6 +137,7 @@ struct rk_iommu {
 	struct list_head node; /* entry in rk_iommu_domain.iommus */
 	struct iommu_domain *domain; /* domain to which iommu is attached */
 	struct iommu_group *group;
+	u32 version;
 };
 
 struct rk_iommudata {
@@ -174,11 +204,32 @@ static struct rk_iommu_domain *to_rk_domain(struct iommu_domain *dom)
 #define RK_DTE_PT_ADDRESS_MASK    0xfffff000
 #define RK_DTE_PT_VALID           BIT(0)
 
+/*
+ * In v2:
+ * 31:12 - PT address bit 31:0
+ * 11: 8 - PT address bit 35:32
+ *  7: 4 - PT address bit 39:36
+ *  3: 1 - Reserved
+ *     0 - 1 if PT @ PT address is valid
+ */
+#define RK_DTE_PT_ADDRESS_MASK_V2 0xfffffff0
+
 static inline phys_addr_t rk_dte_pt_address(u32 dte)
 {
 	return (phys_addr_t)dte & RK_DTE_PT_ADDRESS_MASK;
 }
 
+static inline phys_addr_t rk_dte_pt_address_v2(u32 dte)
+{
+	u64 dte_v2 = dte;
+
+	dte_v2 = ((dte_v2 & DTE_HI_MASK2) << PAGE_DESC_HI_SHIFT2) |
+		 ((dte_v2 & DTE_HI_MASK1) << PAGE_DESC_HI_SHIFT1) |
+		 (dte_v2 & PAGE_DESC_LO_MASK);
+
+	return (phys_addr_t)dte_v2;
+}
+
 static inline bool rk_dte_is_pt_valid(u32 dte)
 {
 	return dte & RK_DTE_PT_VALID;
@@ -189,6 +240,15 @@ static inline u32 rk_mk_dte(dma_addr_t pt_dma)
 	return (pt_dma & RK_DTE_PT_ADDRESS_MASK) | RK_DTE_PT_VALID;
 }
 
+static inline u32 rk_mk_dte_v2(dma_addr_t pt_dma)
+{
+	pt_dma = (pt_dma & PAGE_DESC_LO_MASK) |
+		 ((pt_dma & PAGE_DESC_HI_MASK1) >> PAGE_DESC_HI_SHIFT1) |
+		 (pt_dma & PAGE_DESC_HI_MASK2) >> PAGE_DESC_HI_SHIFT2;
+
+	return (pt_dma & RK_DTE_PT_ADDRESS_MASK_V2) | RK_DTE_PT_VALID;
+}
+
 /*
  * Each PTE has a Page address, some flags and a valid bit:
  * +---------------------+---+-------+-+
@@ -215,11 +275,37 @@ static inline u32 rk_mk_dte(dma_addr_t pt_dma)
 #define RK_PTE_PAGE_READABLE      BIT(1)
 #define RK_PTE_PAGE_VALID         BIT(0)
 
+/*
+ * In v2:
+ * 31:12 - Page address bit 31:0
+ *  11:9 - Page address bit 34:32
+ *   8:4 - Page address bit 39:35
+ *     3 - Security
+ *     2 - Readable
+ *     1 - Writable
+ *     0 - 1 if Page @ Page address is valid
+ */
+#define RK_PTE_PAGE_ADDRESS_MASK_V2  0xfffffff0
+#define RK_PTE_PAGE_FLAGS_MASK_V2    0x0000000e
+#define RK_PTE_PAGE_READABLE_V2      BIT(2)
+#define RK_PTE_PAGE_WRITABLE_V2      BIT(1)
+
 static inline phys_addr_t rk_pte_page_address(u32 pte)
 {
 	return (phys_addr_t)pte & RK_PTE_PAGE_ADDRESS_MASK;
 }
 
+static inline phys_addr_t rk_pte_page_address_v2(u32 pte)
+{
+	u64 pte_v2 = pte;
+
+	pte_v2 = ((pte_v2 & DTE_HI_MASK2) << PAGE_DESC_HI_SHIFT2) |
+		 ((pte_v2 & DTE_HI_MASK1) << PAGE_DESC_HI_SHIFT1) |
+		 (pte_v2 & PAGE_DESC_LO_MASK);
+
+	return (phys_addr_t)pte_v2;
+}
+
 static inline bool rk_pte_is_page_valid(u32 pte)
 {
 	return pte & RK_PTE_PAGE_VALID;
@@ -229,12 +315,26 @@ static inline bool rk_pte_is_page_valid(u32 pte)
 static u32 rk_mk_pte(phys_addr_t page, int prot)
 {
 	u32 flags = 0;
+
 	flags |= (prot & IOMMU_READ) ? RK_PTE_PAGE_READABLE : 0;
 	flags |= (prot & IOMMU_WRITE) ? RK_PTE_PAGE_WRITABLE : 0;
 	page &= RK_PTE_PAGE_ADDRESS_MASK;
 	return page | flags | RK_PTE_PAGE_VALID;
 }
 
+static u32 rk_mk_pte_v2(phys_addr_t page, int prot)
+{
+	u32 flags = 0;
+
+	flags |= (prot & IOMMU_READ) ? RK_PTE_PAGE_READABLE_V2 : 0;
+	flags |= (prot & IOMMU_WRITE) ? RK_PTE_PAGE_WRITABLE_V2 : 0;
+	page = (page & PAGE_DESC_LO_MASK) |
+	       ((page & PAGE_DESC_HI_MASK1) >> PAGE_DESC_HI_SHIFT1) |
+	       (page & PAGE_DESC_HI_MASK2) >> PAGE_DESC_HI_SHIFT2;
+	page &= RK_PTE_PAGE_ADDRESS_MASK_V2;
+	return page | flags | RK_PTE_PAGE_VALID;
+}
+
 static u32 rk_mk_pte_invalid(u32 pte)
 {
 	return pte & ~RK_PTE_PAGE_VALID;
@@ -439,6 +539,7 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 	int ret, i;
 	u32 dte_addr;
 	bool val;
+	u32 address_mask;
 
 	if (iommu->reset_disabled)
 		return 0;
@@ -447,11 +548,19 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 	 * Check if register DTE_ADDR is working by writing DTE_ADDR_DUMMY
 	 * and verifying that upper 5 nybbles are read back.
 	 */
+
+	/*
+	 * In v2: upper 7 nybbles are read back.
+	 */
 	for (i = 0; i < iommu->num_mmu; i++) {
 		rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, DTE_ADDR_DUMMY);
 
+		if (iommu->version >= 0x2)
+			address_mask = RK_DTE_PT_ADDRESS_MASK_V2;
+		else
+			address_mask = RK_DTE_PT_ADDRESS_MASK;
 		dte_addr = rk_iommu_read(iommu->bases[i], RK_MMU_DTE_ADDR);
-		if (dte_addr != (DTE_ADDR_DUMMY & RK_DTE_PT_ADDRESS_MASK)) {
+		if (dte_addr != (DTE_ADDR_DUMMY & address_mask)) {
 			dev_err(iommu->dev, "Error during raw reset. MMU_DTE_ADDR is not functioning\n");
 			return -EFAULT;
 		}
@@ -490,6 +599,10 @@ static void log_iova(struct rk_iommu *iommu, int index, dma_addr_t iova)
 
 	mmu_dte_addr = rk_iommu_read(base, RK_MMU_DTE_ADDR);
 	mmu_dte_addr_phys = (phys_addr_t)mmu_dte_addr;
+	if (iommu->version >= 0x2) {
+		mmu_dte_addr_phys = (mmu_dte_addr_phys & DT_LO_MASK) |
+				    ((mmu_dte_addr_phys & DTE_BASE_HI_MASK) << DT_SHIFT);
+	}
 
 	dte_addr_phys = mmu_dte_addr_phys + (4 * dte_index);
 	dte_addr = phys_to_virt(dte_addr_phys);
@@ -498,14 +611,20 @@ static void log_iova(struct rk_iommu *iommu, int index, dma_addr_t iova)
 	if (!rk_dte_is_pt_valid(dte))
 		goto print_it;
 
-	pte_addr_phys = rk_dte_pt_address(dte) + (pte_index * 4);
+	if (iommu->version >= 0x2)
+		pte_addr_phys = rk_dte_pt_address_v2(dte) + (pte_index * 4);
+	else
+		pte_addr_phys = rk_dte_pt_address(dte) + (pte_index * 4);
 	pte_addr = phys_to_virt(pte_addr_phys);
 	pte = *pte_addr;
 
 	if (!rk_pte_is_page_valid(pte))
 		goto print_it;
 
-	page_addr_phys = rk_pte_page_address(pte) + page_offset;
+	if (iommu->version >= 0x2)
+		page_addr_phys = rk_pte_page_address_v2(pte) + page_offset;
+	else
+		page_addr_phys = rk_pte_page_address(pte) + page_offset;
 	page_flags = pte & RK_PTE_PAGE_FLAGS_MASK;
 
 print_it:
@@ -522,6 +641,7 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
 	struct rk_iommu *iommu = dev_id;
 	u32 status;
 	u32 int_status;
+	u32 int_mask;
 	dma_addr_t iova;
 	irqreturn_t ret = IRQ_NONE;
 	int i, err;
@@ -566,7 +686,15 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
 				dev_err(iommu->dev, "Page fault while iommu not attached to domain?\n");
 
 			rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
-			rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_PAGE_FAULT_DONE);
+
+			/*
+			 * Master may clear the int_mask to prevent iommu
+			 * re-enter interrupt when mapping. So we postpone
+			 * sending PAGE_FAULT_DONE command to mapping finished.
+			 */
+			int_mask = rk_iommu_read(iommu->bases[i], RK_MMU_INT_MASK);
+			if (int_mask != 0x0)
+				rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_PAGE_FAULT_DONE);
 		}
 
 		if (int_status & RK_MMU_IRQ_BUS_ERROR)
@@ -614,6 +742,34 @@ static phys_addr_t rk_iommu_iova_to_phys(struct iommu_domain *domain,
 	return phys;
 }
 
+static phys_addr_t rk_iommu_iova_to_phys_v2(struct iommu_domain *domain,
+					    dma_addr_t iova)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	phys_addr_t pt_phys, phys = 0;
+	u32 dte, pte;
+	u32 *page_table;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	if (!rk_dte_is_pt_valid(dte))
+		goto out;
+
+	pt_phys = rk_dte_pt_address_v2(dte);
+	page_table = (u32 *)phys_to_virt(pt_phys);
+	pte = page_table[rk_iova_pte_index(iova)];
+	if (!rk_pte_is_page_valid(pte))
+		goto out;
+
+	phys = rk_pte_page_address_v2(pte) + rk_iova_page_offset(iova);
+out:
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	return phys;
+}
+
 static void rk_iommu_zap_iova(struct rk_iommu_domain *rk_domain,
 			      dma_addr_t iova, size_t size)
 {
@@ -690,6 +846,44 @@ static u32 *rk_dte_get_page_table(struct rk_iommu_domain *rk_domain,
 	return (u32 *)phys_to_virt(pt_phys);
 }
 
+static u32 *rk_dte_get_page_table_v2(struct rk_iommu_domain *rk_domain,
+				     dma_addr_t iova)
+{
+	u32 *page_table, *dte_addr;
+	u32 dte_index, dte;
+	phys_addr_t pt_phys;
+	dma_addr_t pt_dma;
+
+	assert_spin_locked(&rk_domain->dt_lock);
+
+	dte_index = rk_iova_dte_index(iova);
+	dte_addr = &rk_domain->dt[dte_index];
+	dte = *dte_addr;
+	if (rk_dte_is_pt_valid(dte))
+		goto done;
+
+	page_table = (u32 *)get_zeroed_page(GFP_ATOMIC | GFP_DMA32);
+	if (!page_table)
+		return ERR_PTR(-ENOMEM);
+
+	pt_dma = dma_map_single(dma_dev, page_table, SPAGE_SIZE, DMA_TO_DEVICE);
+	if (dma_mapping_error(dma_dev, pt_dma)) {
+		dev_err(dma_dev, "DMA mapping error while allocating page table\n");
+		free_page((unsigned long)page_table);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	dte = rk_mk_dte_v2(pt_dma);
+	*dte_addr = dte;
+
+	rk_table_flush(rk_domain, pt_dma, NUM_PT_ENTRIES);
+	rk_table_flush(rk_domain,
+		       rk_domain->dt_dma + dte_index * sizeof(u32), 1);
+done:
+	pt_phys = rk_dte_pt_address_v2(dte);
+	return (u32 *)phys_to_virt(pt_phys);
+}
+
 static size_t rk_iommu_unmap_iova(struct rk_iommu_domain *rk_domain,
 				  u32 *pte_addr, dma_addr_t pte_dma,
 				  size_t size)
@@ -757,6 +951,45 @@ static int rk_iommu_map_iova(struct rk_iommu_domain *rk_domain, u32 *pte_addr,
 	return -EADDRINUSE;
 }
 
+static int rk_iommu_map_iova_v2(struct rk_iommu_domain *rk_domain, u32 *pte_addr,
+				dma_addr_t pte_dma, dma_addr_t iova,
+				phys_addr_t paddr, size_t size, int prot)
+{
+	unsigned int pte_count;
+	unsigned int pte_total = size / SPAGE_SIZE;
+	phys_addr_t page_phys;
+
+	assert_spin_locked(&rk_domain->dt_lock);
+
+	for (pte_count = 0; pte_count < pte_total; pte_count++) {
+		u32 pte = pte_addr[pte_count];
+
+		if (rk_pte_is_page_valid(pte))
+			goto unwind;
+
+		pte_addr[pte_count] = rk_mk_pte_v2(paddr, prot);
+
+		paddr += SPAGE_SIZE;
+	}
+
+	rk_table_flush(rk_domain, pte_dma, pte_total);
+
+	rk_iommu_zap_iova_first_last(rk_domain, iova, size);
+
+	return 0;
+unwind:
+	/* Unmap the range of iovas that we just mapped */
+	rk_iommu_unmap_iova(rk_domain, pte_addr, pte_dma,
+			    pte_count * SPAGE_SIZE);
+
+	iova += pte_count * SPAGE_SIZE;
+	page_phys = rk_pte_page_address_v2(pte_addr[pte_count]);
+	pr_err("iova: %pad already mapped to %pa cannot remap to phys: %pa prot: %#x\n",
+	       &iova, &page_phys, &paddr, prot);
+
+	return -EADDRINUSE;
+}
+
 static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 			phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
 {
@@ -764,7 +997,7 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 	unsigned long flags;
 	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
 	u32 *page_table, *pte_addr;
-	u32 dte_index, pte_index;
+	u32 dte, pte_index;
 	int ret;
 
 	spin_lock_irqsave(&rk_domain->dt_lock, flags);
@@ -782,10 +1015,10 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 		return PTR_ERR(page_table);
 	}
 
-	dte_index = rk_domain->dt[rk_iova_dte_index(iova)];
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
 	pte_index = rk_iova_pte_index(iova);
 	pte_addr = &page_table[pte_index];
-	pte_dma = rk_dte_pt_address(dte_index) + pte_index * sizeof(u32);
+	pte_dma = rk_dte_pt_address(dte) + pte_index * sizeof(u32);
 	ret = rk_iommu_map_iova(rk_domain, pte_addr, pte_dma, iova,
 				paddr, size, prot);
 
@@ -794,6 +1027,43 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 	return ret;
 }
 
+static int rk_iommu_map_v2(struct iommu_domain *domain, unsigned long _iova,
+			   phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
+	u32 *page_table, *pte_addr;
+	u32 dte, pte_index;
+	int ret;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	/*
+	 * pgsize_bitmap specifies iova sizes that fit in one page table
+	 * (1024 4-KiB pages = 4 MiB).
+	 * So, size will always be 4096 <= size <= 4194304.
+	 * Since iommu_map() guarantees that both iova and size will be
+	 * aligned, we will always only be mapping from a single dte here.
+	 */
+	page_table = rk_dte_get_page_table_v2(rk_domain, iova);
+	if (IS_ERR(page_table)) {
+		spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+		return PTR_ERR(page_table);
+	}
+
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	pte_index = rk_iova_pte_index(iova);
+	pte_addr = &page_table[pte_index];
+	pte_dma = rk_dte_pt_address_v2(dte) + pte_index * sizeof(u32);
+	ret = rk_iommu_map_iova_v2(rk_domain, pte_addr, pte_dma, iova,
+				   paddr, size, prot);
+
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	return ret;
+}
+
 static size_t rk_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
 			     size_t size, struct iommu_iotlb_gather *gather)
 {
@@ -834,6 +1104,46 @@ static size_t rk_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
 	return unmap_size;
 }
 
+static size_t rk_iommu_unmap_v2(struct iommu_domain *domain, unsigned long _iova,
+				size_t size, struct iommu_iotlb_gather *gather)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
+	phys_addr_t pt_phys;
+	u32 dte;
+	u32 *pte_addr;
+	size_t unmap_size;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	/*
+	 * pgsize_bitmap specifies iova sizes that fit in one page table
+	 * (1024 4-KiB pages = 4 MiB).
+	 * So, size will always be 4096 <= size <= 4194304.
+	 * Since iommu_unmap() guarantees that both iova and size will be
+	 * aligned, we will always only be unmapping from a single dte here.
+	 */
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	/* Just return 0 if iova is unmapped */
+	if (!rk_dte_is_pt_valid(dte)) {
+		spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+		return 0;
+	}
+
+	pt_phys = rk_dte_pt_address_v2(dte);
+	pte_addr = (u32 *)phys_to_virt(pt_phys) + rk_iova_pte_index(iova);
+	pte_dma = pt_phys + rk_iova_pte_index(iova) * sizeof(u32);
+	unmap_size = rk_iommu_unmap_iova(rk_domain, pte_addr, pte_dma, size);
+
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	/* Shootdown iotlb entries for iova range that was just unmapped */
+	rk_iommu_zap_iova(rk_domain, iova, unmap_size);
+
+	return unmap_size;
+}
+
 static struct rk_iommu *rk_iommu_from_dev(struct device *dev)
 {
 	struct rk_iommudata *data = dev_iommu_priv_get(dev);
@@ -864,6 +1174,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
 	struct iommu_domain *domain = iommu->domain;
 	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
 	int ret, i;
+	u32 dt_v2;
 
 	ret = clk_bulk_enable(iommu->num_clocks, iommu->clocks);
 	if (ret)
@@ -878,8 +1189,14 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
 		goto out_disable_stall;
 
 	for (i = 0; i < iommu->num_mmu; i++) {
-		rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
-			       rk_domain->dt_dma);
+		if (iommu->version >= 0x2) {
+			dt_v2 = (rk_domain->dt_dma & DT_LO_MASK) |
+				((rk_domain->dt_dma & DT_HI_MASK) >> DT_SHIFT);
+			rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, dt_v2);
+		} else {
+			rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
+				       rk_domain->dt_dma);
+		}
 		rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
 		rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
 	}
@@ -1054,6 +1371,34 @@ static void rk_iommu_domain_free(struct iommu_domain *domain)
 	kfree(rk_domain);
 }
 
+static void rk_iommu_domain_free_v2(struct iommu_domain *domain)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	int i;
+
+	WARN_ON(!list_empty(&rk_domain->iommus));
+
+	for (i = 0; i < NUM_DT_ENTRIES; i++) {
+		u32 dte = rk_domain->dt[i];
+
+		if (rk_dte_is_pt_valid(dte)) {
+			phys_addr_t pt_phys = rk_dte_pt_address_v2(dte);
+			u32 *page_table = phys_to_virt(pt_phys);
+
+			dma_unmap_single(dma_dev, pt_phys,
+					 SPAGE_SIZE, DMA_TO_DEVICE);
+			free_page((unsigned long)page_table);
+		}
+	}
+	dma_unmap_single(dma_dev, rk_domain->dt_dma,
+			 SPAGE_SIZE, DMA_TO_DEVICE);
+	free_page((unsigned long)rk_domain->dt);
+
+	if (domain->type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(&rk_domain->domain);
+	kfree(rk_domain);
+}
+
 static struct iommu_device *rk_iommu_probe_device(struct device *dev)
 {
 	struct rk_iommudata *data;
@@ -1122,6 +1467,40 @@ static const struct iommu_ops rk_iommu_ops = {
 	.of_xlate = rk_iommu_of_xlate,
 };
 
+static const struct iommu_ops rk_iommu_ops_v2 = {
+	.domain_alloc = rk_iommu_domain_alloc,
+	.domain_free = rk_iommu_domain_free_v2,
+	.attach_dev = rk_iommu_attach_device,
+	.detach_dev = rk_iommu_detach_device,
+	.map = rk_iommu_map_v2,
+	.unmap = rk_iommu_unmap_v2,
+	.probe_device = rk_iommu_probe_device,
+	.release_device = rk_iommu_release_device,
+	.iova_to_phys = rk_iommu_iova_to_phys_v2,
+	.device_group = rk_iommu_device_group,
+	.pgsize_bitmap = RK_IOMMU_PGSIZE_BITMAP,
+	.of_xlate = rk_iommu_of_xlate,
+};
+
+static const struct rockchip_iommu_data iommu_data_v1 = {
+	.version = 0x1,
+};
+
+static const struct rockchip_iommu_data iommu_data_v2 = {
+	.version = 0x2,
+};
+
+static const struct of_device_id rk_iommu_dt_ids[] = {
+	{	.compatible = "rockchip,iommu",
+		.data = &iommu_data_v1,
+	}, {
+		.compatible = "rockchip,iommu-v2",
+		.data = &iommu_data_v2,
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rk_iommu_dt_ids);
+
 static int rk_iommu_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1129,11 +1508,21 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	struct resource *res;
 	int num_res = pdev->num_resources;
 	int err, i;
+	const struct of_device_id *match;
+	struct rockchip_iommu_data *data;
 
 	iommu = devm_kzalloc(dev, sizeof(*iommu), GFP_KERNEL);
 	if (!iommu)
 		return -ENOMEM;
 
+	match = of_match_device(rk_iommu_dt_ids, dev);
+	if (!match)
+		return -EINVAL;
+
+	data = (struct rockchip_iommu_data *)match->data;
+	iommu->version = data->version;
+	dev_info(dev, "version = %x\n", iommu->version);
+
 	platform_set_drvdata(pdev, iommu);
 	iommu->dev = dev;
 	iommu->num_mmu = 0;
@@ -1196,7 +1585,10 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	if (err)
 		goto err_put_group;
 
-	iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops);
+	if (iommu->version >= 0x2)
+		iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops_v2);
+	else
+		iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops);
 	iommu_device_set_fwnode(&iommu->iommu, &dev->of_node->fwnode);
 
 	err = iommu_device_register(&iommu->iommu);
@@ -1211,7 +1603,10 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	if (!dma_dev)
 		dma_dev = &pdev->dev;
 
-	bus_set_iommu(&platform_bus_type, &rk_iommu_ops);
+	if (iommu->version >= 0x2)
+		bus_set_iommu(&platform_bus_type, &rk_iommu_ops_v2);
+	else
+		bus_set_iommu(&platform_bus_type, &rk_iommu_ops);
 
 	pm_runtime_enable(dev);
 
@@ -1280,11 +1675,6 @@ static const struct dev_pm_ops rk_iommu_pm_ops = {
 				pm_runtime_force_resume)
 };
 
-static const struct of_device_id rk_iommu_dt_ids[] = {
-	{ .compatible = "rockchip,iommu" },
-	{ /* sentinel */ }
-};
-
 static struct platform_driver rk_iommu_driver = {
 	.probe = rk_iommu_probe,
 	.shutdown = rk_iommu_shutdown,
-- 
2.25.1



From rppt at kernel.org  Thu Apr 22 08:29:53 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 10:29:53 +0300
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
Message-ID: <YIEl8aKr8Ly0Zd3O@kernel.org>

On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/21 14:51, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt at linux.ibm.com>
> > 
> > Hi,
> > 
> > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> > pfn_valid_within() to 1.
> > 
> > The idea is to mark NOMAP pages as reserved in the memory map and restore
> > the intended semantics of pfn_valid() to designate availability of struct
> > page for a pfn.
> > 
> > With this the core mm will be able to cope with the fact that it cannot use
> > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> > will be treated correctly even without the need for pfn_valid_within.
> > 
> > The patches are only boot tested on qemu-system-aarch64 so I'd really
> > appreciate memory stress tests on real hardware.
> > 
> > If this actually works we'll be one step closer to drop custom pfn_valid()
> > on arm64 altogether.
> 
> Hi Mike?I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
> move_freepages_block()->move_freepages()
> will be optimized, if there are holes in zone, the 'struce page'(memory map)
> for pfn range of hole will be free by
> free_memmap(), and then the page traverse in the zone(with holes) from
> move_freepages() will meet the wrong page?
> then it could panic at PageLRU(page) test, check link[1],

First, HOLES_IN_ZONE name us hugely misleading, this configuration option
has nothing to to with memory holes, but rather it is there to deal with
holes or undefined struct pages in the memory map, when these holes can be
inside a MAX_ORDER_NR_PAGES region.

In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
accessing *missing* struct pages, like those that are freed at
free_memmap(). But on arm64 these tests also filter out the nomap entries
because their struct pages are not initialized.

The panic you refer to happened because there was an uninitialized struct
page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
nomap memory.

With these changes I make sure that such pages will be properly initialized
as PageReserved and the pfn walkers will be able to rely on the memory map.

Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
boundaries, so there will be no missing parts in the memory map within a
MAX_ORDER_NR_PAGES region.
 
> "The idea is to mark NOMAP pages as reserved in the memory map", I see the
> patch2 check memblock_is_nomap() in memory region
> of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
> missed), then memmap_init_reserved_pages() won't
> work, so should the HOLES_IN_ZONE still be needed for generic mm code?
> 
> [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047 at arm.com/
> 

-- 
Sincerely yours,
Mike.


From patrice.chotard at foss.st.com  Thu Apr 22 08:30:16 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Thu, 22 Apr 2021 09:30:16 +0200
Subject: [PATCH] spi: stm32-qspi: fix debug format string
In-Reply-To: <CAK8P3a0CWp_H-tm2QcZyH1FDXwzMgxY_9dc1Y8pA28MQKT-q=A@mail.gmail.com>
References: <20210421140653.3964725-1-arnd@kernel.org>
 <20210421150510.GA36785@sirena.org.uk>
 <CAK8P3a0CWp_H-tm2QcZyH1FDXwzMgxY_9dc1Y8pA28MQKT-q=A@mail.gmail.com>
Message-ID: <b970a557-b869-c867-3825-370a36feef68@foss.st.com>

Hi Mark, Arnd

Regarding this issue, how do you prefer to proceed ? 

Patrice

On 4/21/21 5:22 PM, Arnd Bergmann wrote:
> On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie at kernel.org> wrote:
>>
>> On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd at arndb.de>
>>>
>>> Printing size_t needs a special %zd format modifier to avoid a
>>> warning like:
>>
>> This doesn't apply against current code, please check and resend.
> 
> It appears that you just applied 1b8a7d4282c0 ("spi: stm32-qspi:
> Fix compilation warning in ARM64") after today's linux-next was
> cut.
> 
> I suspect Patrice's patch now causes a warning on all architectures
> on which size_t is defined as 'unsigned int'.
> 
>        Arnd
> 


From targupta at nvidia.com  Thu Apr 22 08:36:13 2021
From: targupta at nvidia.com (Tarun Gupta (SW-GPU))
Date: Thu, 22 Apr 2021 13:06:13 +0530
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <87v98eq0dh.wl-maz@kernel.org>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
 <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
 <87v98eq0dh.wl-maz@kernel.org>
Message-ID: <bf782ec1-71da-5a8e-f250-20ed88677b8c@nvidia.com>



On 4/22/2021 12:20 PM, Marc Zyngier wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Thu, 22 Apr 2021 03:02:00 +0100,
> Gavin Shan <gshan at redhat.com> wrote:
>>
>> Hi Marc,
>>
>> On 4/21/21 9:59 PM, Marc Zyngier wrote:
>>> On Wed, 21 Apr 2021 07:17:44 +0100,
>>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>>> On 2021/4/21 14:20, Gavin Shan wrote:
>>>>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
>>>>>> On 2020/10/22 0:16, Santosh Shukla wrote:
>>>>>>> The Commit:6d674e28 introduces a notion to detect and handle the
>>>>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
>>>>>>> in vma->flags and if set then marks force_pte to true such that
>>>>>>> if force_pte is true then ignore the THP function check
>>>>>>> (/transparent_hugepage_adjust()).
>>>>>>>
>>>>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
>>>>>>> For example consider a case where the mdev vendor driver register's
>>>>>>> the vma_fault handler named vma_mmio_fault(), which maps the
>>>>>>> host MMIO region in-turn calls remap_pfn_range() and maps
>>>>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>>>>>>> the VM_PFNMAP flag into vma->flags.
>>>>>> Could you give the name of the mdev vendor driver that triggers this issue?
>>>>>> I failed to find one according to your description. Thanks.
>>>>>>
>>>>>
>>>>> I think it would be fixed in driver side to set VM_PFNMAP in
>>>>> its mmap() callback (call_mmap()), like vfio PCI driver does.
>>>>> It means it won't be delayed until page fault is issued and
>>>>> remap_pfn_range() is called. It's determined from the beginning
>>>>> that the vma associated the mdev vendor driver is serving as
>>>>> PFN remapping purpose. So the vma should be populated completely,
>>>>> including the VM_PFNMAP flag before it becomes visible to user
>>>>> space.
>>>
>>> Why should that be a requirement? Lazy populating of the VMA should be
>>> perfectly acceptable if the fault can only happen on the CPU side.
>>>
>>
>> It isn't a requirement and the drivers needn't follow strictly. I checked
>> several drivers before looking into the patch and found almost all the
>> drivers have VM_PFNMAP set at mmap() time. In drivers/vfio/vfio-pci.c,
>> there is a comment as below, but it doesn't reveal too much about why
>> we can't set VM_PFNMAP at fault time.
>>
>> static int vfio_pci_mmap(void *device_data, 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.
>>           */
>>          vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
>>          vma->vm_ops = &vfio_pci_mmap_ops;
>>
>>          return 0;
>> }
>>
>> To set these flags in advance does have advantages. For example,
>> VM_DONTEXPAND prevents the vma to be merged with another
>> one. VM_DONTDUMP make this vma isn't eligible for
>> coredump. Otherwise, the address space, which is associated with the
>> vma is accessed and unnecessary page faults are triggered on
>> coredump.  VM_IO and VM_PFNMAP avoids to walk the page frames
>> associated with the vma since we don't have valid PFN in the
>> mapping.
> 
> But PCI clearly isn't the case we are dealing with here, and not
> everything is VFIO either. I can *today* create a driver that
> implements a mmap+fault handler, call mmap() on it, pass the result to
> a memslot, and get to the exact same result Santosh describes.
> 
> No PCI, no VFIO, just a random driver. We are *required* to handle
> that.

Agree with Marc here, that kernel should be able to handle it without 
VM_PFNMAP flag set in driver.

For driver reference, you could check the V2 version of this patch that 
got accepted upstream and has details as-to how this can be reproduced 
using vfio-pci: https://www.spinics.net/lists/arm-kernel/msg848491.html

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


From zhukeqian1 at huawei.com  Thu Apr 22 08:41:34 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Thu, 22 Apr 2021 15:41:34 +0800
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <f13bfc39-bee6-4562-fefc-76051bbf9735@redhat.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
 <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
 <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>
 <f13bfc39-bee6-4562-fefc-76051bbf9735@redhat.com>
Message-ID: <9eb47a6c-3c5c-cb4a-d1de-1a3ce1b60a87@huawei.com>

Hi Gavin,

On 2021/4/22 10:12, Gavin Shan wrote:
> Hi Keqian,
> 
> On 4/21/21 4:28 PM, Keqian Zhu wrote:
>> On 2021/4/21 14:38, Gavin Shan wrote:
>>> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>>>> The MMIO regions may be unmapped for many reasons and can be remapped
>>>> by stage2 fault path. Map MMIO regions at creation time becomes a
>>>> minor optimization and makes these two mapping path hard to sync.
>>>>
>>>> Remove the mapping code while keep the useful sanity check.
>>>>
>>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>>> ---
>>>>    arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
>>>>    1 file changed, 3 insertions(+), 35 deletions(-)
>>>>
>>>
>>> After removing the logic to create stage2 mapping for VM_PFNMAP region,
>>> I think the "do { } while" loop becomes unnecessary and can be dropped
>>> completely. It means the only sanity check is to see if the memory slot
>>> overflows IPA space or not. In that case, KVM_MR_FLAGS_ONLY can be
>>> ignored because the memory slot's base address and length aren't changed
>>> when we have KVM_MR_FLAGS_ONLY.
>> Maybe not exactly. Here we do an important sanity check that we shouldn't
>> log dirty for memslots with VM_PFNMAP.
>>
> 
> Yeah, Sorry that I missed that part. Something associated with Santosh's
> patch. The flag can be not existing until the page fault happened on
> the vma. In this case, the check could be not working properly.
> 
>   [PATCH] KVM: arm64: Correctly handle the mmio faulting
Yeah, you are right.

If that happens, we won't try to use block mapping for memslot with VM_PFNMAP.
But it keeps a same logic with old code.

1. When without dirty-logging, we won't try block mapping for it, and we'll
finally know that it's device, so won't try to do adjust THP (Transparent Huge Page)
for it.
2. If userspace wrongly enables dirty logging for this memslot, we'll force_pte for it.

Thanks,
Keqian


From maxime at cerno.tech  Thu Apr 22 08:42:40 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 22 Apr 2021 09:42:40 +0200
Subject: [PATCH 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3 glue
In-Reply-To: <1619009508.513542.967209.nullmailer@robh.at.kernel.org>
References: <20210421042834.27309-1-samuel@sholland.org>
 <20210421042834.27309-2-samuel@sholland.org>
 <1619009508.513542.967209.nullmailer@robh.at.kernel.org>
Message-ID: <20210422074240.c6gw7uckmceplksw@gilmour>

On Wed, Apr 21, 2021 at 07:51:48AM -0500, Rob Herring wrote:
> On Tue, 20 Apr 2021 23:28:33 -0500, Samuel Holland wrote:
> > The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
> > USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
> > Represent this by attaching the reset line to a glue layer device.
> > 
> > Signed-off-by: Samuel Holland <samuel at sholland.org>
> > ---
> >  .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
> >  1 file changed, 75 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.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):

I dropped these patches then

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/20210422/d08404ff/attachment.sig>

From mripard at kernel.org  Thu Apr 22 08:46:26 2021
From: mripard at kernel.org (Maxime Ripard)
Date: Thu, 22 Apr 2021 09:46:26 +0200
Subject: [GIT PULL] Allwinner Fixes for 5.12, Take 2
Message-ID: <45fc5e4d-ef48-4729-a869-79a8f288bb83.lettre@localhost>

Hi Arnd, Olof,

Here's a late fix for 5.12.

Please pull the following changes for the current release.

Thanks!
Maxime

The following changes since commit 7a2f6e69e9c1060a7a09c1f8322ccb8d942b3078:

  arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference (2021-04-07 13:41:47 +0200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-fixes-for-5.12-2

for you to fetch changes up to 4d09ccc4a81e7de6b002482af554d8b5626f5041:

  arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS (2021-04-22 09:43:15 +0200)

----------------------------------------------------------------
One fix for the MMC card detect on the Pine H64 board

----------------------------------------------------------------
Andre Przywara (1):
      arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS


 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


-------------- 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/20210422/47c7f9e5/attachment.sig>

From maxime at cerno.tech  Thu Apr 22 08:46:39 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Thu, 22 Apr 2021 09:46:39 +0200
Subject: [PATCH v2] arm64: dts: allwinner: Revert SD card CD GPIO for
 Pine64-LTS
In-Reply-To: <20210421123354.0a7209a1@slackpad.fritz.box>
References: <20210414104740.31497-1-andre.przywara@arm.com>
 <YHc11xC1vT1Yr+a1@weiser.dinsnail.net>
 <20210421123354.0a7209a1@slackpad.fritz.box>
Message-ID: <20210422074639.46imznubua2yhj4n@gilmour>

On Wed, Apr 21, 2021 at 12:33:54PM +0100, Andre Przywara wrote:
> On Wed, 14 Apr 2021 20:35:03 +0200
> Michael Weiser <michael.weiser at gmx.de> wrote:
> 
> Maxime, Chen-Yu:
> 
> can you please try to push this patch into 5.12, still?
> The Pine64-LTS' SD card is broken otherwise, on both versions of the
> board. The incriminating patch was introduced in 5.12-rc1 (my bad!), so
> it qualifies as a regression fix.

I just sent a PR for it, 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/20210422/fa91dcc7/attachment.sig>

From anshuman.khandual at arm.com  Thu Apr 22 08:50:23 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 22 Apr 2021 13:20:23 +0530
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections with
 memmap holes
In-Reply-To: <20210422061902.21614-1-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
Message-ID: <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>

Platforms like arm and arm64 have redefined pfn_valid() because their early
memory sections might have contained memmap holes after freeing parts of it
during boot, which should be skipped while validating a pfn for struct page
backing. This scenario on certain platforms where memmap is not continuous,
could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
Then the generic pfn_valid() can be improved to accommodate such platforms.
This reduces overall code footprint and also improves maintainability.

free_unused_memmap() and pfn_to_online_page() have been updated to include
such cases. This also exports memblock_is_memory() for all drivers that use
pfn_valid() but lack required visibility. After the new config is in place,
drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: David Hildenbrand <david at redhat.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-mm at kvack.org
Suggested-by: David Hildenbrand <david at redhat.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
---
This patch applies on the latest mainline kernel after Mike's series
regarding arm64 based pfn_valid().

https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t

Changes in RFC V2:

- Dropped support for arm (32 bit)
- Replaced memblock_is_map_memory() check with memblock_is_memory()
- MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
- Updated pfn_to_online_page() per David
- Updated free_unused_memmap() to preserve existing semantics per Mike
- Exported memblock_is_memory() instead of memblock_is_map_memory()

Changes in RFC V1:

- https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/

 arch/arm64/Kconfig            |  2 +-
 arch/arm64/include/asm/page.h |  1 -
 arch/arm64/mm/init.c          | 41 -----------------------------------
 include/linux/mmzone.h        | 18 ++++++++++++++-
 mm/Kconfig                    |  9 ++++++++
 mm/memblock.c                 |  8 +++++--
 mm/memory_hotplug.c           |  5 +++++
 7 files changed, 38 insertions(+), 46 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b4a9b493ce72..4cdc3570ffa9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,7 +144,6 @@ config ARM64
 	select HAVE_ARCH_KGDB
 	select HAVE_ARCH_MMAP_RND_BITS
 	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
-	select HAVE_ARCH_PFN_VALID
 	select HAVE_ARCH_PREL32_RELOCATIONS
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_ARCH_STACKLEAK
@@ -167,6 +166,7 @@ config ARM64
 		if $(cc-option,-fpatchable-function-entry=2)
 	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
 		if DYNAMIC_FTRACE_WITH_REGS
+	select HAVE_EARLY_SECTION_MEMMAP_HOLES
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
 	select HAVE_FAST_GUP
 	select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 75ddfe671393..fcbef3eec4b2 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
 
 typedef struct page *pgtable_t;
 
-int pfn_valid(unsigned long pfn);
 int pfn_is_map_memory(unsigned long pfn);
 
 #include <asm/memory.h>
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f431b38d0837..5731a11550d8 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
 	free_area_init(max_zone_pfns);
 }
 
-int pfn_valid(unsigned long pfn)
-{
-	phys_addr_t addr = PFN_PHYS(pfn);
-
-	/*
-	 * Ensure the upper PAGE_SHIFT bits are clear in the
-	 * pfn. Else it might lead to false positives when
-	 * some of the upper bits are set, but the lower bits
-	 * match a valid pfn.
-	 */
-	if (PHYS_PFN(addr) != pfn)
-		return 0;
-
-#ifdef CONFIG_SPARSEMEM
-{
-	struct mem_section *ms;
-
-	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
-		return 0;
-
-	ms = __pfn_to_section(pfn);
-	if (!valid_section(ms))
-		return 0;
-
-	/*
-	 * ZONE_DEVICE memory does not have the memblock entries.
-	 * memblock_is_memory() check for ZONE_DEVICE based
-	 * addresses will always fail. Even the normal hotplugged
-	 * memory will never have MEMBLOCK_NOMAP flag set in their
-	 * memblock entries. Skip memblock search for all non early
-	 * memory sections covering all of hotplug memory including
-	 * both normal and ZONE_DEVICE based.
-	 */
-	if (!early_section(ms))
-		return pfn_section_valid(ms, pfn);
-}
-#endif
-	return memblock_is_memory(addr);
-}
-EXPORT_SYMBOL(pfn_valid);
-
 int pfn_is_map_memory(unsigned long pfn)
 {
 	phys_addr_t addr = PFN_PHYS(pfn);
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 961f0eeefb62..18bf71665211 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
  *
  * Return: 1 for PFNs that have memory map entries and 0 otherwise
  */
+bool memblock_is_memory(phys_addr_t addr);
+
 static inline int pfn_valid(unsigned long pfn)
 {
+	phys_addr_t addr = PFN_PHYS(pfn);
 	struct mem_section *ms;
 
+	/*
+	 * Ensure the upper PAGE_SHIFT bits are clear in the
+	 * pfn. Else it might lead to false positives when
+	 * some of the upper bits are set, but the lower bits
+	 * match a valid pfn.
+	 */
+	if (PHYS_PFN(addr) != pfn)
+		return 0;
+
 	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
 		return 0;
 	ms = __nr_to_section(pfn_to_section_nr(pfn));
@@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
 	 * Traditionally early sections always returned pfn_valid() for
 	 * the entire section-sized span.
 	 */
-	return early_section(ms) || pfn_section_valid(ms, pfn);
+	if (early_section(ms))
+		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
+			memblock_is_memory(pfn << PAGE_SHIFT) : 1;
+
+	return pfn_section_valid(ms, pfn);
 }
 #endif
 
diff --git a/mm/Kconfig b/mm/Kconfig
index 24c045b24b95..db7128111874 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -135,6 +135,15 @@ config HAVE_FAST_GUP
 config ARCH_KEEP_MEMBLOCK
 	bool
 
+config HAVE_EARLY_SECTION_MEMMAP_HOLES
+	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
+	def_bool n
+	help
+	  Early sections on certain platforms might have some memory ranges that
+	  are not backed with struct page mappings. When subscribed, this option
+	  enables special handling for those memory ranges in certain situations
+	  such as pfn_valid().
+
 # Keep arch NUMA mapping infrastructure post-init.
 config NUMA_KEEP_MEMINFO
 	bool
diff --git a/mm/memblock.c b/mm/memblock.c
index 3abf2c3fea7f..93f8a9c8428d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
 {
 	return memblock_search(&memblock.memory, addr) != -1;
 }
+EXPORT_SYMBOL(memblock_is_memory);
 
 bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
 {
@@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
 	unsigned long start, end, prev_end = 0;
 	int i;
 
-	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
-	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
+	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
+		return;
+
+	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
+	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
 		return;
 
 	/*
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0cdbbfbc5757..8c78b6a3d888 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -309,6 +309,11 @@ struct page *pfn_to_online_page(unsigned long pfn)
 	 * Save some code text when online_section() +
 	 * pfn_section_valid() are sufficient.
 	 */
+	if (IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES)) {
+		if (early_section(ms) && !memblock_is_memory(PFN_PHYS(pfn)))
+			return NULL;
+	}
+
 	if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) && !pfn_valid(pfn))
 		return NULL;
 
-- 
2.20.1



From santosh.shukla1982 at gmail.com  Thu Apr 22 09:00:13 2021
From: santosh.shukla1982 at gmail.com (Santosh Shukla)
Date: Thu, 22 Apr 2021 13:30:13 +0530
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <bf782ec1-71da-5a8e-f250-20ed88677b8c@nvidia.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
 <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
 <87v98eq0dh.wl-maz@kernel.org>
 <bf782ec1-71da-5a8e-f250-20ed88677b8c@nvidia.com>
Message-ID: <CACpj22xhXHMgsZHrL_2AbEzy=zzz=jXz0s6pRb0=zpJUai1ufg@mail.gmail.com>

On Thu, Apr 22, 2021 at 1:07 PM Tarun Gupta (SW-GPU)
<targupta at nvidia.com> wrote:
>
>
>
> On 4/22/2021 12:20 PM, Marc Zyngier wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, 22 Apr 2021 03:02:00 +0100,
> > Gavin Shan <gshan at redhat.com> wrote:
> >>
> >> Hi Marc,
> >>
> >> On 4/21/21 9:59 PM, Marc Zyngier wrote:
> >>> On Wed, 21 Apr 2021 07:17:44 +0100,
> >>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
> >>>> On 2021/4/21 14:20, Gavin Shan wrote:
> >>>>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
> >>>>>> On 2020/10/22 0:16, Santosh Shukla wrote:
> >>>>>>> The Commit:6d674e28 introduces a notion to detect and handle the
> >>>>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
> >>>>>>> in vma->flags and if set then marks force_pte to true such that
> >>>>>>> if force_pte is true then ignore the THP function check
> >>>>>>> (/transparent_hugepage_adjust()).
> >>>>>>>
> >>>>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
> >>>>>>> For example consider a case where the mdev vendor driver register's
> >>>>>>> the vma_fault handler named vma_mmio_fault(), which maps the
> >>>>>>> host MMIO region in-turn calls remap_pfn_range() and maps
> >>>>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
> >>>>>>> the VM_PFNMAP flag into vma->flags.
> >>>>>> Could you give the name of the mdev vendor driver that triggers this issue?
> >>>>>> I failed to find one according to your description. Thanks.
> >>>>>>
> >>>>>
> >>>>> I think it would be fixed in driver side to set VM_PFNMAP in
> >>>>> its mmap() callback (call_mmap()), like vfio PCI driver does.
> >>>>> It means it won't be delayed until page fault is issued and
> >>>>> remap_pfn_range() is called. It's determined from the beginning
> >>>>> that the vma associated the mdev vendor driver is serving as
> >>>>> PFN remapping purpose. So the vma should be populated completely,
> >>>>> including the VM_PFNMAP flag before it becomes visible to user
> >>>>> space.
> >>>
> >>> Why should that be a requirement? Lazy populating of the VMA should be
> >>> perfectly acceptable if the fault can only happen on the CPU side.
> >>>

Right.
Hi keqian,
You can refer to case
http://lkml.iu.edu/hypermail/linux/kernel/2010.3/00952.html

(Sorry Guys, I am not with nvidia, but My quick input.)

> >>
> >> It isn't a requirement and the drivers needn't follow strictly. I checked
> >> several drivers before looking into the patch and found almost all the
> >> drivers have VM_PFNMAP set at mmap() time. In drivers/vfio/vfio-pci.c,
> >> there is a comment as below, but it doesn't reveal too much about why
> >> we can't set VM_PFNMAP at fault time.
> >>
> >> static int vfio_pci_mmap(void *device_data, 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.
> >>           */
> >>          vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> >>          vma->vm_ops = &vfio_pci_mmap_ops;
> >>
> >>          return 0;
> >> }
> >>
> >> To set these flags in advance does have advantages. For example,
> >> VM_DONTEXPAND prevents the vma to be merged with another
> >> one. VM_DONTDUMP make this vma isn't eligible for
> >> coredump. Otherwise, the address space, which is associated with the
> >> vma is accessed and unnecessary page faults are triggered on
> >> coredump.  VM_IO and VM_PFNMAP avoids to walk the page frames
> >> associated with the vma since we don't have valid PFN in the
> >> mapping.
> >
> > But PCI clearly isn't the case we are dealing with here, and not
> > everything is VFIO either. I can *today* create a driver that
> > implements a mmap+fault handler, call mmap() on it, pass the result to
> > a memslot, and get to the exact same result Santosh describes.
> >
> > No PCI, no VFIO, just a random driver. We are *required* to handle
> > that.
>
> Agree with Marc here, that kernel should be able to handle it without
> VM_PFNMAP flag set in driver.
>
> For driver reference, you could check the V2 version of this patch that
> got accepted upstream and has details as-to how this can be reproduced
> using vfio-pci: https://www.spinics.net/lists/arm-kernel/msg848491.html
>
> >
> >          M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
> >


From ada at thorsis.com  Thu Apr 22 09:01:25 2021
From: ada at thorsis.com (Alexander Dahl)
Date: Thu, 22 Apr 2021 10:01:25 +0200
Subject: [PATCH v5 4/6] rtc: at91sma9: Simplify using
 devm_clk_get_enabled()
In-Reply-To: <20210422065726.1646742-5-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
 <20210422065726.1646742-5-u.kleine-koenig@pengutronix.de>
Message-ID: <YIEtVVE8ZdwbTTgM@ada-deb-carambola.ifak-system.com>

Hello Uwe,

I think there's a typo in the subject.  It should be sam9 instead of
sma9, right?

Greets
Alex

Am Thu, Apr 22, 2021 at 08:57:24AM +0200 schrieb Uwe Kleine-K?nig:
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/rtc/rtc-at91sam9.c | 22 ++++------------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
> index 2216be429ab7..b52e7bd26303 100644
> --- a/drivers/rtc/rtc-at91sam9.c
> +++ b/drivers/rtc/rtc-at91sam9.c
> @@ -374,21 +374,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> -	rtc->sclk = devm_clk_get(&pdev->dev, NULL);
> +	rtc->sclk = devm_clk_get_enabled(&pdev->dev, NULL);
>  	if (IS_ERR(rtc->sclk))
>  		return PTR_ERR(rtc->sclk);
>  
> -	ret = clk_prepare_enable(rtc->sclk);
> -	if (ret) {
> -		dev_err(&pdev->dev, "Could not enable slow clock\n");
> -		return ret;
> -	}
> -
>  	sclk_rate = clk_get_rate(rtc->sclk);
>  	if (!sclk_rate || sclk_rate > AT91_RTT_RTPRES) {
>  		dev_err(&pdev->dev, "Invalid slow clock rate\n");
> -		ret = -EINVAL;
> -		goto err_clk;
> +		return -EINVAL;
>  	}
>  
>  	mr = rtt_readl(rtc, MR);
> @@ -406,7 +399,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  	rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
>  	if (IS_ERR(rtc->rtcdev)) {
>  		ret = PTR_ERR(rtc->rtcdev);
> -		goto err_clk;
> +		return ret;
>  	}
>  
>  	rtc->rtcdev->ops = &at91_rtc_ops;
> @@ -418,7 +411,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  			       dev_name(&rtc->rtcdev->dev), rtc);
>  	if (ret) {
>  		dev_dbg(&pdev->dev, "can't share IRQ %d?\n", rtc->irq);
> -		goto err_clk;
> +		return ret;
>  	}
>  
>  	/* NOTE:  sam9260 rev A silicon has a ROM bug which resets the
> @@ -432,11 +425,6 @@ static int at91_rtc_probe(struct platform_device *pdev)
>  			 dev_name(&rtc->rtcdev->dev));
>  
>  	return devm_rtc_register_device(rtc->rtcdev);
> -
> -err_clk:
> -	clk_disable_unprepare(rtc->sclk);
> -
> -	return ret;
>  }
>  
>  /*
> @@ -450,8 +438,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
>  	/* disable all interrupts */
>  	rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
>  
> -	clk_disable_unprepare(rtc->sclk);
> -
>  	return 0;
>  }
>  
> -- 
> 2.30.2
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jonathanh at nvidia.com  Thu Apr 22 09:15:30 2021
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 22 Apr 2021 09:15:30 +0100
Subject: [PATCH tip 1/2] signal, perf: Fix siginfo_t by avoiding u64 on
 32-bit architectures
In-Reply-To: <20210422064437.3577327-1-elver@google.com>
References: <20210422064437.3577327-1-elver@google.com>
Message-ID: <0734b0e8-b4c0-05bb-b90c-de89edb61b5d@nvidia.com>


On 22/04/2021 07:44, Marco Elver wrote:
> On some architectures, like Arm, the alignment of a structure is that of
> its largest member.
> 
> This means that there is no portable way to add 64-bit integers to
> siginfo_t on 32-bit architectures, because siginfo_t does not contain
> any 64-bit integers on 32-bit architectures.
> 
> In the case of the si_perf field, word size is sufficient since there is
> no exact requirement on size, given the data it contains is user-defined
> via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
> of perf_event_attr::sig_data will therefore be truncated when copying
> into si_perf.
> 
> Since this field is intended to disambiguate events (e.g. encoding
> relevant information if there are more events of the same type), 32 bits
> should provide enough entropy to do so on 32-bit architectures.
> 
> For 64-bit architectures, no change is intended.
> 
> Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Reported-by: Jon Hunter <jonathanh at nvidia.com>
> Signed-off-by: Marco Elver <elver at google.com>


Thanks for fixing!

Tested-by: Jon Hunter <jonathanh at nvidia.com>

Cheers
Jon

-- 
nvpublic


From jonathanh at nvidia.com  Thu Apr 22 09:16:43 2021
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 22 Apr 2021 09:16:43 +0100
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <CANpmjNPbMOUd_Wh5aHGdH8WLrYpyBFUpwx6g3Kj2D6eevvaU8w@mail.gmail.com>
References: <CANpmjNM8wEJngK=J8Lt9npkZgrSWoRsqkdajErWEoY_=M1GW5A@mail.gmail.com>
 <43f8a3bf-34c5-0fc9-c335-7f92eaf23022@samsung.com>
 <dccaa337-f3e5-08e4-fe40-a603811bb13e@samsung.com>
 <CANpmjNP6-yKpxHqYFiA8Up-ujBQaeP7xyq1BrsV-NqMjJ-uHAQ@mail.gmail.com>
 <740077ce-efe1-b171-f807-bc5fd95a32ba@samsung.com>
 <f114ff4a-6612-0935-12ac-0e2ac18d896c@samsung.com>
 <CANpmjNM6bQpc49teN-9qQhCXoJXaek5stFGR2kPwDroSFBc0fw@mail.gmail.com>
 <cf6ed5cd-3202-65ce-86bc-6f1eba1b7d17@samsung.com>
 <CANpmjNPr_JtRC762ap8PQVmsFNY5YhHvOk0wNcPHq=ZQt-qxYg@mail.gmail.com>
 <YIBSg7Vi+U383dT7@elver.google.com>
 <CGME20210421182355eucas1p23b419002936ab5f1ffc25652135cc152@eucas1p2.samsung.com>
 <YIBtr2w/8KhOoiUA@elver.google.com>
 <dd99b921-3d79-a21f-8942-40fa5bf53190@samsung.com>
 <CANpmjNPbMOUd_Wh5aHGdH8WLrYpyBFUpwx6g3Kj2D6eevvaU8w@mail.gmail.com>
Message-ID: <e590c4f6-ad6a-26a4-4f5f-9e6e63bfb15a@nvidia.com>


On 22/04/2021 07:47, Marco Elver wrote:
> On Thu, 22 Apr 2021 at 08:12, Marek Szyprowski <m.szyprowski at samsung.com> wrote:
> [...]
>>> So I think we just have to settle on 'unsigned long' here. On many
>>> architectures, like 32-bit Arm, the alignment of a structure is that of
>>> its largest member. This means that there is no portable way to add
>>> 64-bit integers to siginfo_t on 32-bit architectures.
>>>
>>> In the case of the si_perf field, word size is sufficient since the data
>>> it contains is user-defined. On 32-bit architectures, any excess bits of
>>> perf_event_attr::sig_data will therefore be truncated when copying into
>>> si_perf.
>>>
>>> Feel free to test the below if you have time, but the below lets me boot
>>> 32-bit arm which previously timed out. It also passes all the
>>> static_asserts() I added (will send those as separate patches).
>>>
>>> Once I'm convinced this passes all others tests too, I'll send a patch.
>>
>> This fixes the issue I've observed on my test systems. Feel free to add:
>>
>> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
>>
>> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> 
> Thank you for testing! It's been sent:
> https://lkml.kernel.org/r/20210422064437.3577327-1-elver at google.com


Thanks! This fixes the problem for Tegra as well. I have responded to
the above patch with my tested-by.

Cheers
Jon

-- 
nvpublic


From rppt at kernel.org  Thu Apr 22 09:27:21 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 11:27:21 +0300
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <YIEzaQF8fVtNgU0E@kernel.org>

On Thu, Apr 22, 2021 at 01:20:23PM +0530, Anshuman Khandual wrote:
> Platforms like arm and arm64 have redefined pfn_valid() because their early
> memory sections might have contained memmap holes after freeing parts of it
> during boot, which should be skipped while validating a pfn for struct page
> backing. This scenario on certain platforms where memmap is not continuous,
> could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
> Then the generic pfn_valid() can be improved to accommodate such platforms.
> This reduces overall code footprint and also improves maintainability.
> 
> free_unused_memmap() and pfn_to_online_page() have been updated to include
> such cases. This also exports memblock_is_memory() for all drivers that use
> pfn_valid() but lack required visibility. After the new config is in place,
> drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: David Hildenbrand <david at redhat.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-mm at kvack.org
> Suggested-by: David Hildenbrand <david at redhat.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
> This patch applies on the latest mainline kernel after Mike's series
> regarding arm64 based pfn_valid().
> 
> https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t
> 
> Changes in RFC V2:
> 
> - Dropped support for arm (32 bit)
> - Replaced memblock_is_map_memory() check with memblock_is_memory()
> - MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
> - Updated pfn_to_online_page() per David
> - Updated free_unused_memmap() to preserve existing semantics per Mike
> - Exported memblock_is_memory() instead of memblock_is_map_memory()
> 
> Changes in RFC V1:
> 
> - https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/
> 
>  arch/arm64/Kconfig            |  2 +-
>  arch/arm64/include/asm/page.h |  1 -
>  arch/arm64/mm/init.c          | 41 -----------------------------------
>  include/linux/mmzone.h        | 18 ++++++++++++++-
>  mm/Kconfig                    |  9 ++++++++
>  mm/memblock.c                 |  8 +++++--
>  mm/memory_hotplug.c           |  5 +++++
>  7 files changed, 38 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b4a9b493ce72..4cdc3570ffa9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -144,7 +144,6 @@ config ARM64
>  	select HAVE_ARCH_KGDB
>  	select HAVE_ARCH_MMAP_RND_BITS
>  	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> -	select HAVE_ARCH_PFN_VALID
>  	select HAVE_ARCH_PREL32_RELOCATIONS
>  	select HAVE_ARCH_SECCOMP_FILTER
>  	select HAVE_ARCH_STACKLEAK
> @@ -167,6 +166,7 @@ config ARM64
>  		if $(cc-option,-fpatchable-function-entry=2)
>  	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
>  		if DYNAMIC_FTRACE_WITH_REGS
> +	select HAVE_EARLY_SECTION_MEMMAP_HOLES
>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>  	select HAVE_FAST_GUP
>  	select HAVE_FTRACE_MCOUNT_RECORD
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 75ddfe671393..fcbef3eec4b2 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
>  
>  typedef struct page *pgtable_t;
>  
> -int pfn_valid(unsigned long pfn);
>  int pfn_is_map_memory(unsigned long pfn);
>  
>  #include <asm/memory.h>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f431b38d0837..5731a11550d8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>  	free_area_init(max_zone_pfns);
>  }
>  
> -int pfn_valid(unsigned long pfn)
> -{
> -	phys_addr_t addr = PFN_PHYS(pfn);
> -
> -	/*
> -	 * Ensure the upper PAGE_SHIFT bits are clear in the
> -	 * pfn. Else it might lead to false positives when
> -	 * some of the upper bits are set, but the lower bits
> -	 * match a valid pfn.
> -	 */
> -	if (PHYS_PFN(addr) != pfn)
> -		return 0;
> -
> -#ifdef CONFIG_SPARSEMEM
> -{
> -	struct mem_section *ms;
> -
> -	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> -		return 0;
> -
> -	ms = __pfn_to_section(pfn);
> -	if (!valid_section(ms))
> -		return 0;
> -
> -	/*
> -	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_memory() check for ZONE_DEVICE based
> -	 * addresses will always fail. Even the normal hotplugged
> -	 * memory will never have MEMBLOCK_NOMAP flag set in their
> -	 * memblock entries. Skip memblock search for all non early
> -	 * memory sections covering all of hotplug memory including
> -	 * both normal and ZONE_DEVICE based.
> -	 */
> -	if (!early_section(ms))
> -		return pfn_section_valid(ms, pfn);
> -}
> -#endif
> -	return memblock_is_memory(addr);
> -}
> -EXPORT_SYMBOL(pfn_valid);
> -
>  int pfn_is_map_memory(unsigned long pfn)
>  {
>  	phys_addr_t addr = PFN_PHYS(pfn);
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 961f0eeefb62..18bf71665211 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>   *
>   * Return: 1 for PFNs that have memory map entries and 0 otherwise
>   */
> +bool memblock_is_memory(phys_addr_t addr);
> +
>  static inline int pfn_valid(unsigned long pfn)
>  {
> +	phys_addr_t addr = PFN_PHYS(pfn);
>  	struct mem_section *ms;
>  
> +	/*
> +	 * Ensure the upper PAGE_SHIFT bits are clear in the
> +	 * pfn. Else it might lead to false positives when
> +	 * some of the upper bits are set, but the lower bits
> +	 * match a valid pfn.
> +	 */
> +	if (PHYS_PFN(addr) != pfn)
> +		return 0;
> +
>  	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>  		return 0;
>  	ms = __nr_to_section(pfn_to_section_nr(pfn));
> @@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
>  	 * Traditionally early sections always returned pfn_valid() for
>  	 * the entire section-sized span.
>  	 */
> -	return early_section(ms) || pfn_section_valid(ms, pfn);
> +	if (early_section(ms))
> +		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
> +			memblock_is_memory(pfn << PAGE_SHIFT) : 1;

Nit: we already did 

	addr = PFN_PHYS(pfn);

a few lines above :)

> +
> +	return pfn_section_valid(ms, pfn);
>  }
>  #endif
>  
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 24c045b24b95..db7128111874 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -135,6 +135,15 @@ config HAVE_FAST_GUP
>  config ARCH_KEEP_MEMBLOCK
>  	bool
>  
> +config HAVE_EARLY_SECTION_MEMMAP_HOLES
> +	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
> +	def_bool n
> +	help
> +	  Early sections on certain platforms might have some memory ranges that
> +	  are not backed with struct page mappings. When subscribed, this option
> +	  enables special handling for those memory ranges in certain situations
> +	  such as pfn_valid().
> +
>  # Keep arch NUMA mapping infrastructure post-init.
>  config NUMA_KEEP_MEMINFO
>  	bool
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 3abf2c3fea7f..93f8a9c8428d 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
>  {
>  	return memblock_search(&memblock.memory, addr) != -1;
>  }
> +EXPORT_SYMBOL(memblock_is_memory);

Please make it inside #ifdef CONFIG_ARCH_MEMBLOCK
  
>  bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
>  {
> @@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
>  	unsigned long start, end, prev_end = 0;
>  	int i;
>  
> -	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
> -	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> +	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> +		return;
> +
> +	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
> +	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
>  		return;

Can you please add a comment that says that architecture should provide a
way to detect holes in the memory map to be able to free its part?  

>  	/*
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 0cdbbfbc5757..8c78b6a3d888 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -309,6 +309,11 @@ struct page *pfn_to_online_page(unsigned long pfn)
>  	 * Save some code text when online_section() +
>  	 * pfn_section_valid() are sufficient.
>  	 */
> +	if (IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES)) {
> +		if (early_section(ms) && !memblock_is_memory(PFN_PHYS(pfn)))
> +			return NULL;
> +	}
> +
>  	if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) && !pfn_valid(pfn))
>  		return NULL;
>  
> -- 
> 2.20.1
> 

-- 
Sincerely yours,
Mike.


From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 22 09:29:59 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 22 Apr 2021 13:59:59 +0530
Subject: [PATCH v6 0/3] Add ZynqMP pinctrl driver
Message-ID: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Add support for Xilinx ZynqMP pinctrl driver and also update
the Xilinx firmware driver to support pinctrl functionality.
This driver queries the pin information from the firmware and
allow configuring the pins as per the request.

Note:
Patch#2 is already applied but sending in this series for
completeness.

changes in v6:
- Rebased the patche series on 'devel' branch in pinctrl tree and no
functional changes.
 
changes in v5:
- Used generic property 'power-source' instead of driver specific for
configuring the IO voltages, updated the same in dt-binding.
- Added support to build driver as a module.
- Used error codes returned by the Xilinx firmware instead of shadowing the
error codes in the driver.
- Fixed comments from Andy related to spell checks, NULL checks, explicit
typecast, header inclusion ordering, removing kernel docs for the
obvious ones.

changes in v4:
- Added comment for ignoring the return value for GET_FUNCTION_NAME qid.
- Updated the zynqmp_pinctrl_get_function_name() API prototype to void as
it always returns zero.

changes in v3:
- Fixed binding doc comments from Rob.
- Used 'maxItems' for groups and pins properties.
- Updated commit subject and description to have present tense statements.

changes in v2:
- Use pattern for pin names in yaml file.
- Updated to support multiple groups and pins.
- Added type ref for the vendor specific properties.
- Removed 'schmitt-cmos', instead used common properties.
- Removed macros for drive-strength property.

Sai Krishna Potthuri (3):
  firmware: xilinx: Add pinctrl support
  dt-bindings: pinctrl: Add binding for ZynqMP pinctrl driver
  pinctrl: Add Xilinx ZynqMP pinctrl driver support

 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 +++++++
 drivers/firmware/xilinx/zynqmp.c              | 114 +++
 drivers/pinctrl/Kconfig                       |  14 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c              | 906 ++++++++++++++++++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 include/linux/firmware/xlnx-zynqmp.h          |  90 ++
 7 files changed, 1480 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 22 09:30:00 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 22 Apr 2021 14:00:00 +0530
Subject: [PATCH v6 1/3] firmware: xilinx: Add pinctrl support
In-Reply-To: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1619080202-31924-2-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding pinctrl support to query platform specific information (pins)
from firmware.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
Acked-by: Michal Simek <michal.simek at xilinx.com>
---
 drivers/firmware/xilinx/zynqmp.c     | 114 +++++++++++++++++++++++++++
 include/linux/firmware/xlnx-zynqmp.h |  90 +++++++++++++++++++++
 2 files changed, 204 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 7eb9958662dd..fc01a3632815 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -811,6 +811,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
 
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+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, pin, 0,
+				  0, 0, ret_payload);
+	*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
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+				   0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+				 u32 *value)
+{
+	u32 ret_payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	if (!value)
+		return -EINVAL;
+
+	ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+				  0, 0, ret_payload);
+	*value = ret_payload[1];
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+				 u32 value)
+{
+	return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+				   param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
 /**
  * zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
  *			       master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 71177b17eee5..8285a4bcfc2d 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -72,6 +72,12 @@ enum pm_api_id {
 	PM_FPGA_LOAD = 22,
 	PM_FPGA_GET_STATUS = 23,
 	PM_GET_CHIPID = 24,
+	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,
 	PM_IOCTL = 34,
 	PM_QUERY_DATA = 35,
 	PM_CLOCK_ENABLE = 36,
@@ -122,6 +128,12 @@ enum pm_query_id {
 	PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS = 3,
 	PM_QID_CLOCK_GET_PARENTS = 4,
 	PM_QID_CLOCK_GET_ATTRIBUTES = 5,
+	PM_QID_PINCTRL_GET_NUM_PINS = 6,
+	PM_QID_PINCTRL_GET_NUM_FUNCTIONS = 7,
+	PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS = 8,
+	PM_QID_PINCTRL_GET_FUNCTION_NAME = 9,
+	PM_QID_PINCTRL_GET_FUNCTION_GROUPS = 10,
+	PM_QID_PINCTRL_GET_PIN_GROUPS = 11,
 	PM_QID_CLOCK_GET_NUM_CLOCKS = 12,
 	PM_QID_CLOCK_GET_MAX_DIVISOR = 13,
 };
@@ -285,6 +297,44 @@ enum dll_reset_type {
 	PM_DLL_RESET_PULSE = 2,
 };
 
+enum pm_pinctrl_config_param {
+	PM_PINCTRL_CONFIG_SLEW_RATE = 0,
+	PM_PINCTRL_CONFIG_BIAS_STATUS = 1,
+	PM_PINCTRL_CONFIG_PULL_CTRL = 2,
+	PM_PINCTRL_CONFIG_SCHMITT_CMOS = 3,
+	PM_PINCTRL_CONFIG_DRIVE_STRENGTH = 4,
+	PM_PINCTRL_CONFIG_VOLTAGE_STATUS = 5,
+	PM_PINCTRL_CONFIG_TRI_STATE = 6,
+	PM_PINCTRL_CONFIG_MAX = 7,
+};
+
+enum pm_pinctrl_slew_rate {
+	PM_PINCTRL_SLEW_RATE_FAST = 0,
+	PM_PINCTRL_SLEW_RATE_SLOW = 1,
+};
+
+enum pm_pinctrl_bias_status {
+	PM_PINCTRL_BIAS_DISABLE = 0,
+	PM_PINCTRL_BIAS_ENABLE = 1,
+};
+
+enum pm_pinctrl_pull_ctrl {
+	PM_PINCTRL_BIAS_PULL_DOWN = 0,
+	PM_PINCTRL_BIAS_PULL_UP = 1,
+};
+
+enum pm_pinctrl_schmitt_cmos {
+	PM_PINCTRL_INPUT_TYPE_CMOS = 0,
+	PM_PINCTRL_INPUT_TYPE_SCHMITT = 1,
+};
+
+enum pm_pinctrl_drive_strength {
+	PM_PINCTRL_DRIVE_STRENGTH_2MA = 0,
+	PM_PINCTRL_DRIVE_STRENGTH_4MA = 1,
+	PM_PINCTRL_DRIVE_STRENGTH_8MA = 2,
+	PM_PINCTRL_DRIVE_STRENGTH_12MA = 3,
+};
+
 enum zynqmp_pm_shutdown_type {
 	ZYNQMP_PM_SHUTDOWN_TYPE_SHUTDOWN = 0,
 	ZYNQMP_PM_SHUTDOWN_TYPE_RESET = 1,
@@ -353,6 +403,14 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 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);
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+				 u32 value);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -537,6 +595,38 @@ static inline int zynqmp_pm_set_boot_health_status(u32 value)
 {
 	return -ENODEV;
 }
+
+static inline int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+	return -ENODEV;
+}
+
+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_pinctrl_set_function(const u32 pin, const u32 id)
+{
+	return -ENODEV;
+}
+
+static inline int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+					       u32 *value)
+{
+	return -ENODEV;
+}
+
+static inline int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+					       u32 value)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 22 09:30:01 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 22 Apr 2021 14:00:01 +0530
Subject: [PATCH v6 2/3] dt-bindings: pinctrl: Add binding for ZynqMP pinctrl
 driver
In-Reply-To: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1619080202-31924-3-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding documentation and dt-bindings file which contains MIO pin
configuration defines for Xilinx ZynqMP pinctrl driver.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Link: https://lore.kernel.org/r/1618485193-5403-3-git-send-email-lakshmi.sai.krishna.potthuri at xilinx.com
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 336 ++++++++++++++++++
 include/dt-bindings/pinctrl/pinctrl-zynqmp.h  |  19 +
 2 files changed, 355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
new file mode 100644
index 000000000000..8ef0d07d35fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml
@@ -0,0 +1,336 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx ZynqMP Pinctrl
+
+maintainers:
+  - Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
+  - Rajan Vaja <rajan.vaja at xilinx.com>
+
+description: |
+  Please refer to pinctrl-bindings.txt in this directory for details of the
+  common pinctrl bindings used by client devices, including the meaning of the
+  phrase "pin configuration node".
+
+  ZynqMP's pin configuration nodes act as a container for an arbitrary number of
+  subnodes. Each of these subnodes represents some desired configuration for a
+  pin, a group, or a list of pins or groups. This configuration can include the
+  mux function to select on those pin(s)/group(s), and various pin configuration
+  parameters, such as pull-up, slew rate, etc.
+
+  Each configuration node can consist of multiple nodes describing the pinmux and
+  pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+  The name of each subnode is not important; all subnodes should be enumerated
+  and processed purely based on their content.
+
+properties:
+  compatible:
+    const: xlnx,zynqmp-pinctrl
+
+patternProperties:
+  '^(.*-)?(default|gpio)$':
+    type: object
+    patternProperties:
+      '^mux':
+        type: object
+        description:
+          Pinctrl node's client devices use subnodes for pin muxes,
+          which in turn use below standard properties.
+        $ref: pinmux-node.yaml#
+
+        properties:
+          groups:
+            description:
+              List of groups to select (either this or "pins" must be
+              specified), available groups for this subnode.
+            items:
+              enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp,
+                     ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp,
+                     gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp,
+                     mdio1_1_grp, mdio2_0_grp, mdio3_0_grp,
+                     qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp,
+                     spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp,
+                     spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp,
+                     spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp,
+                     spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp,
+                     spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp,
+                     spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp,
+                     spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp,
+                     spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp,
+                     spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp,
+                     spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp,
+                     spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp,
+                     spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp,
+                     spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp,
+                     spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp,
+                     spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp,
+                     spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp,
+                     sdio0_0_grp, sdio0_1_grp, sdio0_2_grp,
+                     sdio0_3_grp, sdio0_4_grp, sdio0_5_grp,
+                     sdio0_6_grp, sdio0_7_grp, sdio0_8_grp,
+                     sdio0_9_grp, sdio0_10_grp, sdio0_11_grp,
+                     sdio0_12_grp, sdio0_13_grp, sdio0_14_grp,
+                     sdio0_15_grp, sdio0_16_grp, sdio0_17_grp,
+                     sdio0_18_grp, sdio0_19_grp, sdio0_20_grp,
+                     sdio0_21_grp, sdio0_22_grp, sdio0_23_grp,
+                     sdio0_24_grp, sdio0_25_grp, sdio0_26_grp,
+                     sdio0_27_grp, sdio0_28_grp, sdio0_29_grp,
+                     sdio0_30_grp, sdio0_31_grp, sdio0_32_grp,
+                     sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp,
+                     sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp,
+                     sdio0_pc_2_grp, sdio0_cd_2_grp, sdio0_wp_2_grp,
+                     sdio1_0_grp, sdio1_1_grp, sdio1_2_grp,
+                     sdio1_3_grp, sdio1_4_grp, sdio1_5_grp,
+                     sdio1_6_grp, sdio1_7_grp, sdio1_8_grp,
+                     sdio1_9_grp, sdio1_10_grp, sdio1_11_grp,
+                     sdio1_12_grp, sdio1_13_grp, sdio1_14_grp,
+                     sdio1_15_grp, sdio1_pc_0_grp, sdio1_cd_0_grp,
+                     sdio1_wp_0_grp, sdio1_pc_1_grp, sdio1_cd_1_grp,
+                     sdio1_wp_1_grp, nand0_0_grp, nand0_ce_0_grp,
+                     nand0_rb_0_grp, nand0_dqs_0_grp, nand0_ce_1_grp,
+                     nand0_rb_1_grp, nand0_dqs_1_grp, can0_0_grp,
+                     can0_1_grp, can0_2_grp, can0_3_grp,
+                     can0_4_grp, can0_5_grp, can0_6_grp,
+                     can0_7_grp, can0_8_grp, can0_9_grp,
+                     can0_10_grp, can0_11_grp, can0_12_grp,
+                     can0_13_grp, can0_14_grp, can0_15_grp,
+                     can0_16_grp, can0_17_grp, can0_18_grp,
+                     can1_0_grp, can1_1_grp, can1_2_grp,
+                     can1_3_grp, can1_4_grp, can1_5_grp,
+                     can1_6_grp, can1_7_grp, can1_8_grp,
+                     can1_9_grp, can1_10_grp, can1_11_grp,
+                     can1_12_grp, can1_13_grp, can1_14_grp,
+                     can1_15_grp, can1_16_grp, can1_17_grp,
+                     can1_18_grp, can1_19_grp, uart0_0_grp,
+                     uart0_1_grp, uart0_2_grp, uart0_3_grp,
+                     uart0_4_grp, uart0_5_grp, uart0_6_grp,
+                     uart0_7_grp, uart0_8_grp, uart0_9_grp,
+                     uart0_10_grp, uart0_11_grp, uart0_12_grp,
+                     uart0_13_grp, uart0_14_grp, uart0_15_grp,
+                     uart0_16_grp, uart0_17_grp, uart0_18_grp,
+                     uart1_0_grp, uart1_1_grp, uart1_2_grp,
+                     uart1_3_grp, uart1_4_grp, uart1_5_grp,
+                     uart1_6_grp, uart1_7_grp, uart1_8_grp,
+                     uart1_9_grp, uart1_10_grp, uart1_11_grp,
+                     uart1_12_grp, uart1_13_grp, uart1_14_grp,
+                     uart1_15_grp, uart1_16_grp, uart1_17_grp,
+                     uart1_18_grp, i2c0_0_grp, i2c0_1_grp,
+                     i2c0_2_grp, i2c0_3_grp, i2c0_4_grp,
+                     i2c0_5_grp, i2c0_6_grp, i2c0_7_grp,
+                     i2c0_8_grp, i2c0_9_grp, i2c0_10_grp,
+                     i2c0_11_grp, i2c0_12_grp, i2c0_13_grp,
+                     i2c0_14_grp, i2c0_15_grp, i2c0_16_grp,
+                     i2c0_17_grp, i2c0_18_grp, i2c1_0_grp,
+                     i2c1_1_grp, i2c1_2_grp, i2c1_3_grp,
+                     i2c1_4_grp, i2c1_5_grp, i2c1_6_grp,
+                     i2c1_7_grp, i2c1_8_grp, i2c1_9_grp,
+                     i2c1_10_grp, i2c1_11_grp, i2c1_12_grp,
+                     i2c1_13_grp, i2c1_14_grp, i2c1_15_grp,
+                     i2c1_16_grp, i2c1_17_grp, i2c1_18_grp,
+                     i2c1_19_grp, ttc0_clk_0_grp, ttc0_wav_0_grp,
+                     ttc0_clk_1_grp, ttc0_wav_1_grp, ttc0_clk_2_grp,
+                     ttc0_wav_2_grp, ttc0_clk_3_grp, ttc0_wav_3_grp,
+                     ttc0_clk_4_grp, ttc0_wav_4_grp, ttc0_clk_5_grp,
+                     ttc0_wav_5_grp, ttc0_clk_6_grp, ttc0_wav_6_grp,
+                     ttc0_clk_7_grp, ttc0_wav_7_grp, ttc0_clk_8_grp,
+                     ttc0_wav_8_grp, ttc1_clk_0_grp, ttc1_wav_0_grp,
+                     ttc1_clk_1_grp, ttc1_wav_1_grp, ttc1_clk_2_grp,
+                     ttc1_wav_2_grp, ttc1_clk_3_grp, ttc1_wav_3_grp,
+                     ttc1_clk_4_grp, ttc1_wav_4_grp, ttc1_clk_5_grp,
+                     ttc1_wav_5_grp, ttc1_clk_6_grp, ttc1_wav_6_grp,
+                     ttc1_clk_7_grp, ttc1_wav_7_grp, ttc1_clk_8_grp,
+                     ttc1_wav_8_grp, ttc2_clk_0_grp, ttc2_wav_0_grp,
+                     ttc2_clk_1_grp, ttc2_wav_1_grp, ttc2_clk_2_grp,
+                     ttc2_wav_2_grp, ttc2_clk_3_grp, ttc2_wav_3_grp,
+                     ttc2_clk_4_grp, ttc2_wav_4_grp, ttc2_clk_5_grp,
+                     ttc2_wav_5_grp, ttc2_clk_6_grp, ttc2_wav_6_grp,
+                     ttc2_clk_7_grp, ttc2_wav_7_grp, ttc2_clk_8_grp,
+                     ttc2_wav_8_grp, ttc3_clk_0_grp, ttc3_wav_0_grp,
+                     ttc3_clk_1_grp, ttc3_wav_1_grp, ttc3_clk_2_grp,
+                     ttc3_wav_2_grp, ttc3_clk_3_grp, ttc3_wav_3_grp,
+                     ttc3_clk_4_grp, ttc3_wav_4_grp, ttc3_clk_5_grp,
+                     ttc3_wav_5_grp, ttc3_clk_6_grp, ttc3_wav_6_grp,
+                     ttc3_clk_7_grp, ttc3_wav_7_grp, ttc3_clk_8_grp,
+                     ttc3_wav_8_grp, swdt0_clk_0_grp, swdt0_rst_0_grp,
+                     swdt0_clk_1_grp, swdt0_rst_1_grp, swdt0_clk_2_grp,
+                     swdt0_rst_2_grp, swdt0_clk_3_grp, swdt0_rst_3_grp,
+                     swdt0_clk_4_grp, swdt0_rst_4_grp, swdt0_clk_5_grp,
+                     swdt0_rst_5_grp, swdt0_clk_6_grp, swdt0_rst_6_grp,
+                     swdt0_clk_7_grp, swdt0_rst_7_grp, swdt0_clk_8_grp,
+                     swdt0_rst_8_grp, swdt0_clk_9_grp, swdt0_rst_9_grp,
+                     swdt0_clk_10_grp, swdt0_rst_10_grp, swdt0_clk_11_grp,
+                     swdt0_rst_11_grp, swdt0_clk_12_grp, swdt0_rst_12_grp,
+                     swdt1_clk_0_grp, swdt1_rst_0_grp, swdt1_clk_1_grp,
+                     swdt1_rst_1_grp, swdt1_clk_2_grp, swdt1_rst_2_grp,
+                     swdt1_clk_3_grp, swdt1_rst_3_grp, swdt1_clk_4_grp,
+                     swdt1_rst_4_grp, swdt1_clk_5_grp, swdt1_rst_5_grp,
+                     swdt1_clk_6_grp, swdt1_rst_6_grp, swdt1_clk_7_grp,
+                     swdt1_rst_7_grp, swdt1_clk_8_grp, swdt1_rst_8_grp,
+                     swdt1_clk_9_grp, swdt1_rst_9_grp, swdt1_clk_10_grp,
+                     swdt1_rst_10_grp, swdt1_clk_11_grp, swdt1_rst_11_grp,
+                     swdt1_clk_12_grp, swdt1_rst_12_grp, gpio0_0_grp,
+                     gpio0_1_grp, gpio0_2_grp, gpio0_3_grp,
+                     gpio0_4_grp, gpio0_5_grp, gpio0_6_grp,
+                     gpio0_7_grp, gpio0_8_grp, gpio0_9_grp,
+                     gpio0_10_grp, gpio0_11_grp, gpio0_12_grp,
+                     gpio0_13_grp, gpio0_14_grp, gpio0_15_grp,
+                     gpio0_16_grp, gpio0_17_grp, gpio0_18_grp,
+                     gpio0_19_grp, gpio0_20_grp, gpio0_21_grp,
+                     gpio0_22_grp, gpio0_23_grp, gpio0_24_grp,
+                     gpio0_25_grp, gpio0_26_grp, gpio0_27_grp,
+                     gpio0_28_grp, gpio0_29_grp, gpio0_30_grp,
+                     gpio0_31_grp, gpio0_32_grp, gpio0_33_grp,
+                     gpio0_34_grp, gpio0_35_grp, gpio0_36_grp,
+                     gpio0_37_grp, gpio0_38_grp, gpio0_39_grp,
+                     gpio0_40_grp, gpio0_41_grp, gpio0_42_grp,
+                     gpio0_43_grp, gpio0_44_grp, gpio0_45_grp,
+                     gpio0_46_grp, gpio0_47_grp, gpio0_48_grp,
+                     gpio0_49_grp, gpio0_50_grp, gpio0_51_grp,
+                     gpio0_52_grp, gpio0_53_grp, gpio0_54_grp,
+                     gpio0_55_grp, gpio0_56_grp, gpio0_57_grp,
+                     gpio0_58_grp, gpio0_59_grp, gpio0_60_grp,
+                     gpio0_61_grp, gpio0_62_grp, gpio0_63_grp,
+                     gpio0_64_grp, gpio0_65_grp, gpio0_66_grp,
+                     gpio0_67_grp, gpio0_68_grp, gpio0_69_grp,
+                     gpio0_70_grp, gpio0_71_grp, gpio0_72_grp,
+                     gpio0_73_grp, gpio0_74_grp, gpio0_75_grp,
+                     gpio0_76_grp, gpio0_77_grp, usb0_0_grp,
+                     usb1_0_grp, pmu0_0_grp, pmu0_1_grp,
+                     pmu0_2_grp, pmu0_3_grp, pmu0_4_grp,
+                     pmu0_5_grp, pmu0_6_grp, pmu0_7_grp,
+                     pmu0_8_grp, pmu0_9_grp, pmu0_10_grp,
+                     pmu0_11_grp, pcie0_0_grp, pcie0_1_grp,
+                     pcie0_2_grp, pcie0_3_grp, pcie0_4_grp,
+                     pcie0_5_grp, pcie0_6_grp, pcie0_7_grp,
+                     csu0_0_grp, csu0_1_grp, csu0_2_grp,
+                     csu0_3_grp, csu0_4_grp, csu0_5_grp,
+                     csu0_6_grp, csu0_7_grp, csu0_8_grp,
+                     csu0_9_grp, csu0_10_grp, csu0_11_grp,
+                     dpaux0_0_grp, dpaux0_1_grp, dpaux0_2_grp,
+                     dpaux0_3_grp, pjtag0_0_grp, pjtag0_1_grp,
+                     pjtag0_2_grp, pjtag0_3_grp, pjtag0_4_grp,
+                     pjtag0_5_grp, trace0_0_grp, trace0_clk_0_grp,
+                     trace0_1_grp, trace0_clk_1_grp, trace0_2_grp,
+                     trace0_clk_2_grp, testscan0_0_grp]
+            maxItems: 78
+
+          function:
+            description:
+              Specify the alternative function to be configured for the
+              given pin groups.
+            enum: [ethernet0, ethernet1, ethernet2, ethernet3, gemtsu0, usb0, usb1, mdio0,
+                   mdio1, mdio2, mdio3, qspi0, qspi_fbclk, qspi_ss, spi0, spi1, spi0_ss,
+                   spi1_ss, sdio0, sdio0_pc, sdio0_wp, sdio0_cd, sdio1, sdio1_pc, sdio1_wp,
+                   sdio1_cd, nand0, nand0_ce, nand0_rb, nand0_dqs, can0, can1, uart0, uart1,
+                   i2c0, i2c1, ttc0_clk, ttc0_wav, ttc1_clk, ttc1_wav, ttc2_clk, ttc2_wav,
+                   ttc3_clk, ttc3_wav, swdt0_clk, swdt0_rst, swdt1_clk, swdt1_rst, gpio0, pmu0,
+                   pcie0, csu0, dpaux0, pjtag0, trace0, trace0_clk, testscan0]
+
+        required:
+          - groups
+          - function
+
+        additionalProperties: false
+
+      '^conf':
+        type: object
+        description:
+          Pinctrl node's client devices use subnodes for pin configurations,
+          which in turn use the standard properties below.
+        $ref: pincfg-node.yaml#
+
+        properties:
+          groups:
+            description:
+              List of pin groups as mentioned above.
+
+          pins:
+            description:
+              List of pin names to select in this subnode.
+            items:
+              pattern: '^MIO([0-9]|[1-6][0-9]|7[0-7])$'
+            maxItems: 78
+
+          bias-pull-up: true
+
+          bias-pull-down: true
+
+          bias-disable: true
+
+          input-schmitt-enable: true
+
+          input-schmitt-disable: true
+
+          bias-high-impedance: true
+
+          low-power-enable: true
+
+          low-power-disable: true
+
+          slew-rate:
+            enum: [0, 1]
+
+          drive-strength:
+            description:
+              Selects the drive strength for MIO pins, in mA.
+            enum: [2, 4, 8, 12]
+
+          power-source:
+            enum: [0, 1]
+
+        oneOf:
+          - required: [ groups ]
+          - required: [ pins ]
+
+        additionalProperties: false
+
+    additionalProperties: false
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+    zynqmp_firmware: zynqmp-firmware {
+        pinctrl0: pinctrl {
+          compatible = "xlnx,zynqmp-pinctrl";
+
+          pinctrl_uart1_default: uart1-default {
+             mux {
+                 groups = "uart0_4_grp", "uart0_5_grp";
+                 function = "uart0";
+             };
+
+             conf {
+                groups = "uart0_4_grp";
+                slew-rate = <SLEW_RATE_SLOW>;
+                power-source = <IO_STANDARD_LVCMOS18>;
+             };
+
+             conf-rx {
+                pins = "MIO18";
+                bias-pull-up;
+             };
+
+             conf-tx {
+                pins = "MIO19";
+                bias-disable;
+                input-schmitt-disable;
+             };
+          };
+        };
+    };
+
+    uart1 {
+         pinctrl-names = "default";
+         pinctrl-0 = <&pinctrl_uart1_default>;
+    };
+
+...
diff --git a/include/dt-bindings/pinctrl/pinctrl-zynqmp.h b/include/dt-bindings/pinctrl/pinctrl-zynqmp.h
new file mode 100644
index 000000000000..cdb215734bdf
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pinctrl-zynqmp.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * MIO pin configuration defines for Xilinx ZynqMP
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_ZYNQMP_H
+#define _DT_BINDINGS_PINCTRL_ZYNQMP_H
+
+/* Bit value for different voltage levels */
+#define IO_STANDARD_LVCMOS33	0
+#define IO_STANDARD_LVCMOS18	1
+
+/* Bit values for Slew Rates */
+#define SLEW_RATE_FAST		0
+#define SLEW_RATE_SLOW		1
+
+#endif /* _DT_BINDINGS_PINCTRL_ZYNQMP_H */
-- 
2.17.1



From lakshmi.sai.krishna.potthuri at xilinx.com  Thu Apr 22 09:30:02 2021
From: lakshmi.sai.krishna.potthuri at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 22 Apr 2021 14:00:02 +0530
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>

Adding pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.

Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
---
 drivers/pinctrl/Kconfig          |  14 +
 drivers/pinctrl/Makefile         |   1 +
 drivers/pinctrl/pinctrl-zynqmp.c | 906 +++++++++++++++++++++++++++++++
 3 files changed, 921 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 9502775afc11..c2c7e7963ed0 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -323,6 +323,20 @@ config PINCTRL_ZYNQ
 	help
 	  This selects the pinctrl driver for Xilinx Zynq.
 
+config PINCTRL_ZYNQMP
+	tristate "Pinctrl driver for Xilinx ZynqMP"
+	depends on ZYNQMP_FIRMWARE
+	select PINMUX
+	select GENERIC_PINCONF
+	default ZYNQMP_FIRMWARE
+	help
+	  This selects the pinctrl driver for Xilinx ZynqMP platform.
+	  This driver will query the pin information from the firmware
+	  and allow configuring the pins.
+	  Configuration can include the mux function to select on those
+	  pin(s)/group(s), and various pin configuration parameters
+	  such as pull-up, slew rate, etc.
+
 config PINCTRL_INGENIC
 	bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
 	default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 8bf459c32a76..5ef5334a797f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PINCTRL_TB10X)	+= pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_STMFX) 	+= pinctrl-stmfx.o
 obj-$(CONFIG_PINCTRL_ZYNQ)	+= pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)	+= pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_INGENIC)	+= pinctrl-ingenic.o
 obj-$(CONFIG_PINCTRL_RK805)	+= pinctrl-rk805.o
 obj-$(CONFIG_PINCTRL_OCELOT)	+= pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index 000000000000..d5497003ce71
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,906 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
+ * Rajan Vaja <rajan.vaja at xilinx.com>
+ */
+
+#include <dt-bindings/pinctrl/pinctrl-zynqmp.h>
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+
+#include <linux/pinctrl/pinmux.h>
+#include <linux/pinctrl/pinconf-generic.h>
+
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX			"MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN		16
+#define MAX_FUNC_NAME_LEN			16
+#define MAX_GROUP_PIN				50
+#define MAX_PIN_GROUPS				50
+#define END_OF_FUNCTIONS			"END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP			6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN	12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN		12
+#define NA_GROUP				0xFFFF
+#define RESERVED_GROUP				0xFFFE
+
+#define DRIVE_STRENGTH_2MA	2
+#define DRIVE_STRENGTH_4MA	4
+#define DRIVE_STRENGTH_8MA	8
+#define DRIVE_STRENGTH_12MA	12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name:	Name of the pin mux function
+ * @groups:	List of pin groups for this function
+ * @ngroups:	Number of entries in @groups
+ * @node:	Firmware node matching with the function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+	char name[MAX_FUNC_NAME_LEN];
+	const char * const *groups;
+	unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl:	Pin control device
+ * @groups:	Pin groups
+ * @ngroups:	Number of @groups
+ * @funcs:	Pin mux functions
+ * @nfuncs:	Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+	struct pinctrl_dev *pctrl;
+	const struct zynqmp_pctrl_group *groups;
+	unsigned int ngroups;
+	const struct zynqmp_pmux_function *funcs;
+	unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name:	Group name
+ * @pins:	Group pin numbers
+ * @npins:	Number of pins in the group
+ */
+struct zynqmp_pctrl_group {
+	const char *name;
+	unsigned int pins[MAX_GROUP_PIN];
+	unsigned int npins;
+};
+
+static struct pinctrl_desc zynqmp_desc;
+
+static int zynqmp_pctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->ngroups;
+}
+
+static const char *zynqmp_pctrl_get_group_name(struct pinctrl_dev *pctldev,
+					       unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->groups[selector].name;
+}
+
+static int zynqmp_pctrl_get_group_pins(struct pinctrl_dev *pctldev,
+				       unsigned int selector,
+				       const unsigned int **pins,
+				       unsigned int *npins)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = pctrl->groups[selector].pins;
+	*npins = pctrl->groups[selector].npins;
+
+	return 0;
+}
+
+static const struct pinctrl_ops zynqmp_pctrl_ops = {
+	.get_groups_count = zynqmp_pctrl_get_groups_count,
+	.get_group_name = zynqmp_pctrl_get_group_name,
+	.get_group_pins = zynqmp_pctrl_get_group_pins,
+	.dt_node_to_map = pinconf_generic_dt_node_to_map_all,
+	.dt_free_map = pinctrl_utils_free_map,
+};
+
+static int zynqmp_pinmux_request_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_request(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "request failed for pin %u\n", pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int zynqmp_pmux_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->nfuncs;
+}
+
+static const char *zynqmp_pmux_get_function_name(struct pinctrl_dev *pctldev,
+						 unsigned int selector)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctrl->funcs[selector].name;
+}
+
+/**
+ * zynqmp_pmux_get_function_groups() - Get groups for the function
+ * @pctldev:	Pincontrol device pointer.
+ * @selector:	Function ID
+ * @groups:	Group names.
+ * @num_groups:	Number of function groups.
+ *
+ * Get function's group count and group names.
+ */
+static int zynqmp_pmux_get_function_groups(struct pinctrl_dev *pctldev,
+					   unsigned int selector,
+					   const char * const **groups,
+					   unsigned * const num_groups)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+
+	*groups = pctrl->funcs[selector].groups;
+	*num_groups = pctrl->funcs[selector].ngroups;
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinmux_set_mux() - Set requested function for the group
+ * @pctldev:	Pincontrol device pointer.
+ * @function:	Function ID.
+ * @group:	Group ID.
+ *
+ * Loop through all pins of the group and call firmware API
+ * to set requested function for all pins in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinmux_set_mux(struct pinctrl_dev *pctldev,
+				 unsigned int function,
+				 unsigned int group)
+{
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[group];
+	int ret, i;
+
+	for (i = 0; i < pgrp->npins; i++) {
+		unsigned int pin = pgrp->pins[i];
+
+		ret = zynqmp_pm_pinctrl_set_function(pin, function);
+		if (ret) {
+			dev_err(pctldev->dev, "set mux failed for pin %u\n",
+				pin);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int zynqmp_pinmux_release_pin(struct pinctrl_dev *pctldev,
+				     unsigned int pin)
+{
+	int ret;
+
+	ret = zynqmp_pm_pinctrl_release(pin);
+	if (ret) {
+		dev_err(pctldev->dev, "free pin failed for pin %u\n",
+			pin);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinmux_ops zynqmp_pinmux_ops = {
+	.request = zynqmp_pinmux_request_pin,
+	.get_functions_count = zynqmp_pmux_get_functions_count,
+	.get_function_name = zynqmp_pmux_get_function_name,
+	.get_function_groups = zynqmp_pmux_get_function_groups,
+	.set_mux = zynqmp_pinmux_set_mux,
+	.free = zynqmp_pinmux_release_pin,
+};
+
+/**
+ * zynqmp_pinconf_cfg_get() - get config value for the pin
+ * @pctldev:	Pin control device pointer.
+ * @pin:	Pin number.
+ * @config:	Value of config param.
+ *
+ * Get value of the requested configuration parameter for the
+ * given pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
+				  unsigned int pin,
+				  unsigned long *config)
+{
+	unsigned int arg, param = pinconf_to_config_param(*config);
+	int ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	switch (param) {
+	case PIN_CONFIG_SLEW_RATE:
+		param = PM_PINCTRL_CONFIG_SLEW_RATE;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_UP)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		param = PM_PINCTRL_CONFIG_PULL_CTRL;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_BIAS_DISABLE:
+		param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		if (arg != PM_PINCTRL_BIAS_DISABLE)
+			return -EINVAL;
+
+		arg = 1;
+		break;
+	case PIN_CONFIG_POWER_SOURCE:
+		param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+		param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		break;
+	case PIN_CONFIG_DRIVE_STRENGTH:
+		param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+		ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
+		switch (arg) {
+		case PM_PINCTRL_DRIVE_STRENGTH_2MA:
+			arg = DRIVE_STRENGTH_2MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_4MA:
+			arg = DRIVE_STRENGTH_4MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_8MA:
+			arg = DRIVE_STRENGTH_8MA;
+			break;
+		case PM_PINCTRL_DRIVE_STRENGTH_12MA:
+			arg = DRIVE_STRENGTH_12MA;
+			break;
+		default:
+			/* Invalid drive strength */
+			dev_warn(pctldev->dev,
+				 "Invalid drive strength for pin %d\n",
+				 pin);
+			return -EINVAL;
+		}
+		break;
+	default:
+		ret = -EOPNOTSUPP;
+		break;
+	}
+
+	if (ret)
+		return ret;
+
+	param = pinconf_to_config_param(*config);
+	*config = pinconf_to_config_packed(param, arg);
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_cfg_set() - Set requested config for the pin
+ * @pctldev:		Pincontrol device pointer.
+ * @pin:		Pin number.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Loop through all configurations and call firmware API
+ * to set requested configurations for the pin.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_cfg_set(struct pinctrl_dev *pctldev,
+				  unsigned int pin, unsigned long *configs,
+				  unsigned int num_configs)
+{
+	int i, ret;
+
+	if (pin >= zynqmp_desc.npins)
+		return -EOPNOTSUPP;
+
+	for (i = 0; i < num_configs; i++) {
+		unsigned int param = pinconf_to_config_param(configs[i]);
+		unsigned int arg = pinconf_to_config_argument(configs[i]);
+		unsigned int value;
+
+		switch (param) {
+		case PIN_CONFIG_SLEW_RATE:
+			param = PM_PINCTRL_CONFIG_SLEW_RATE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_UP:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_UP;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_PULL_DOWN:
+			param = PM_PINCTRL_CONFIG_PULL_CTRL;
+			arg = PM_PINCTRL_BIAS_PULL_DOWN;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_BIAS_DISABLE:
+			param = PM_PINCTRL_CONFIG_BIAS_STATUS;
+			arg = PM_PINCTRL_BIAS_DISABLE;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+			param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, arg);
+			break;
+		case PIN_CONFIG_DRIVE_STRENGTH:
+			switch (arg) {
+			case DRIVE_STRENGTH_2MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_2MA;
+				break;
+			case DRIVE_STRENGTH_4MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_4MA;
+				break;
+			case DRIVE_STRENGTH_8MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_8MA;
+				break;
+			case DRIVE_STRENGTH_12MA:
+				value = PM_PINCTRL_DRIVE_STRENGTH_12MA;
+				break;
+			default:
+				/* Invalid drive strength */
+				dev_warn(pctldev->dev,
+					 "Invalid drive strength for pin %d\n",
+					 pin);
+				return -EINVAL;
+			}
+
+			param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
+			ret = zynqmp_pm_pinctrl_set_config(pin, param, value);
+			break;
+		case PIN_CONFIG_POWER_SOURCE:
+			param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
+			ret = zynqmp_pm_pinctrl_get_config(pin, param, &value);
+
+			if (arg != value)
+				dev_warn(pctldev->dev,
+					 "Invalid IO Standard requested for pin %d\n",
+					 pin);
+
+			break;
+		case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
+		case PIN_CONFIG_MODE_LOW_POWER:
+			/*
+			 * These cases are mentioned in dts but configurable
+			 * registers are unknown. So falling through to ignore
+			 * boot time warnings as of now.
+			 */
+			ret = 0;
+			break;
+		default:
+			dev_warn(pctldev->dev,
+				 "unsupported configuration parameter '%u'\n",
+				 param);
+			ret = -EOPNOTSUPP;
+			break;
+		}
+
+		param = pinconf_to_config_param(configs[i]);
+		arg = pinconf_to_config_argument(configs[i]);
+		if (ret)
+			dev_warn(pctldev->dev,
+				 "failed to set: pin %u param %u value %u\n",
+				 pin, param, arg);
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinconf_group_set() - Set requested config for the group
+ * @pctldev:		Pincontrol device pointer.
+ * @selector:		Group ID.
+ * @configs:		Configuration to set.
+ * @num_configs:	Number of configurations.
+ *
+ * Call function to set configs for each pin in the group.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinconf_group_set(struct pinctrl_dev *pctldev,
+				    unsigned int selector,
+				    unsigned long *configs,
+				    unsigned int num_configs)
+{
+	int i, ret;
+	struct zynqmp_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+	const struct zynqmp_pctrl_group *pgrp = &pctrl->groups[selector];
+
+	for (i = 0; i < pgrp->npins; i++) {
+		ret = zynqmp_pinconf_cfg_set(pctldev, pgrp->pins[i], configs,
+					     num_configs);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static const struct pinconf_ops zynqmp_pinconf_ops = {
+	.is_generic = true,
+	.pin_config_get = zynqmp_pinconf_cfg_get,
+	.pin_config_set = zynqmp_pinconf_cfg_set,
+	.pin_config_group_set = zynqmp_pinconf_group_set,
+};
+
+static struct pinctrl_desc zynqmp_desc = {
+	.name = "zynqmp_pinctrl",
+	.owner = THIS_MODULE,
+	.pctlops = &zynqmp_pctrl_ops,
+	.pmxops = &zynqmp_pinmux_ops,
+	.confops = &zynqmp_pinconf_ops,
+};
+
+static int zynqmp_pinctrl_get_function_groups(u32 fid, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_FUNC_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_func_num_groups(u32 fid, unsigned int *ngroups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTION_GROUPS;
+	qdata.arg1 = fid;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*ngroups = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_func_groups() - prepare function and groups data
+ * @dev:	Device pointer.
+ * @fid:	Function ID.
+ * @func:	Function data.
+ * @groups:	Groups data.
+ *
+ * Query firmware to get group IDs for each function. Firmware returns
+ * group IDs. Based on group index for the function, group names in
+ * the function are stored. For example, the first group in "eth0" function
+ * is named as "eth0_0" and second group as "eth0_1" and so on.
+ *
+ * Based on the group ID received from the firmware, function stores name of
+ * the group for that group ID. For example, if "eth0" first group ID
+ * is x, groups[x] name will be stored as "eth0_0".
+ *
+ * Once done for each function, each function would have its group names
+ * and each groups would also have their names.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_func_groups(struct device *dev, u32 fid,
+					      struct zynqmp_pmux_function *func,
+					      struct zynqmp_pctrl_group *groups)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	const char **fgroups;
+	int ret = 0, index, i;
+
+	fgroups = devm_kzalloc(dev, sizeof(*fgroups) * func->ngroups, GFP_KERNEL);
+	if (!fgroups)
+		return -ENOMEM;
+
+	for (index = 0; index < func->ngroups; index += NUM_GROUPS_PER_RESP) {
+		ret = zynqmp_pinctrl_get_function_groups(fid, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				goto done;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			fgroups[index + i] = devm_kasprintf(dev, GFP_KERNEL,
+							    "%s_%d_grp",
+							    func->name,
+							    index + i);
+			if (!fgroups[index + i])
+				return -ENOMEM;
+
+			groups[resp[i]].name = devm_kasprintf(dev, GFP_KERNEL,
+							      "%s_%d_grp",
+							      func->name,
+							      index + i);
+			if (!groups[resp[i]].name)
+				return -ENOMEM;
+		}
+	}
+done:
+	func->groups = fgroups;
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_get_function_name(u32 fid, char *name)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+
+	qdata.qid = PM_QID_PINCTRL_GET_FUNCTION_NAME;
+	qdata.arg1 = fid;
+
+	/*
+	 * Name of the function is maximum 16 bytes and cannot
+	 * accommodate the return value in SMC buffers, hence ignoring
+	 * the return value for this specific qid.
+	 */
+	zynqmp_pm_query_data(qdata, payload);
+	memcpy(name, payload, PINCTRL_GET_FUNC_NAME_RESP_LEN);
+}
+
+static int zynqmp_pinctrl_get_num_functions(unsigned int *nfuncs)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_FUNCTIONS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*nfuncs = payload[1];
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_pin_groups(u32 pin, u32 index, u16 *groups)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_PIN_GROUPS;
+	qdata.arg1 = pin;
+	qdata.arg2 = index;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	memcpy(groups, &payload[1], PINCTRL_GET_PIN_GROUPS_RESP_LEN);
+
+	return ret;
+}
+
+static void zynqmp_pinctrl_group_add_pin(struct zynqmp_pctrl_group *group,
+					 unsigned int pin)
+{
+	group->pins[group->npins++] = pin;
+}
+
+/**
+ * zynqmp_pinctrl_create_pin_groups() - assign pins to respective groups
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @pin:	Pin number.
+ *
+ * Query firmware to get groups available for the given pin.
+ * Based on the firmware response(group IDs for the pin), add
+ * pin number to the respective group's pin array.
+ *
+ * Once all pins are queries, each groups would have its number
+ * of pins and pin numbers data.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_create_pin_groups(struct device *dev,
+					    struct zynqmp_pctrl_group *groups,
+					    unsigned int pin)
+{
+	u16 resp[NUM_GROUPS_PER_RESP] = {0};
+	int ret, i, index = 0;
+
+	do {
+		ret = zynqmp_pinctrl_get_pin_groups(pin, index, resp);
+		if (ret)
+			return ret;
+
+		for (i = 0; i < NUM_GROUPS_PER_RESP; i++) {
+			if (resp[i] == NA_GROUP)
+				return ret;
+
+			if (resp[i] == RESERVED_GROUP)
+				continue;
+
+			zynqmp_pinctrl_group_add_pin(&groups[resp[i]], pin);
+		}
+		index += NUM_GROUPS_PER_RESP;
+	} while (index <= MAX_PIN_GROUPS);
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_group_pins() - prepare each group's pin data
+ * @dev:	Device pointer.
+ * @groups:	Groups data.
+ * @ngroups:	Number of groups.
+ *
+ * Prepare pin number and number of pins data for each pins.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_group_pins(struct device *dev,
+					     struct zynqmp_pctrl_group *groups,
+					     unsigned int ngroups)
+{
+	unsigned int pin;
+	int ret;
+
+	for (pin = 0; pin < zynqmp_desc.npins; pin++) {
+		ret = zynqmp_pinctrl_create_pin_groups(dev, groups, pin);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_function_info() - prepare function info
+ * @dev:	Device pointer.
+ * @pctrl:	Pin control driver data.
+ *
+ * Query firmware for functions, groups and pin information and
+ * prepare pin control driver data.
+ *
+ * Query number of functions and number of function groups (number
+ * of groups in given function) to allocate required memory buffers
+ * for functions and groups. Once buffers are allocated to store
+ * functions and groups data, query and store required information
+ * (number of groups and group names for each function, number of
+ * pins and pin numbers for each group).
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_function_info(struct device *dev,
+						struct zynqmp_pinctrl *pctrl)
+{
+	struct zynqmp_pmux_function *funcs;
+	struct zynqmp_pctrl_group *groups;
+	int ret, i;
+
+	ret = zynqmp_pinctrl_get_num_functions(&pctrl->nfuncs);
+	if (ret)
+		return ret;
+
+	funcs = devm_kzalloc(dev, sizeof(*funcs) * pctrl->nfuncs, GFP_KERNEL);
+	if (!funcs)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		zynqmp_pinctrl_get_function_name(i, funcs[i].name);
+
+		ret = zynqmp_pinctrl_get_func_num_groups(i, &funcs[i].ngroups);
+		if (ret)
+			return ret;
+
+		pctrl->ngroups += funcs[i].ngroups;
+	}
+
+	groups = devm_kzalloc(dev, sizeof(*groups) * pctrl->ngroups, GFP_KERNEL);
+	if (!groups)
+		return -ENOMEM;
+
+	for (i = 0; i < pctrl->nfuncs; i++) {
+		ret = zynqmp_pinctrl_prepare_func_groups(dev, i, &funcs[i],
+							 groups);
+		if (ret)
+			return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_group_pins(dev, groups, pctrl->ngroups);
+	if (ret)
+		return ret;
+
+	pctrl->funcs = funcs;
+	pctrl->groups = groups;
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_get_num_pins(unsigned int *npins)
+{
+	struct zynqmp_pm_query_data qdata = {0};
+	u32 payload[PAYLOAD_ARG_CNT];
+	int ret;
+
+	qdata.qid = PM_QID_PINCTRL_GET_NUM_PINS;
+
+	ret = zynqmp_pm_query_data(qdata, payload);
+	if (ret)
+		return ret;
+
+	*npins = payload[1];
+
+	return ret;
+}
+
+/**
+ * zynqmp_pinctrl_prepare_pin_desc() - prepare pin description info
+ * @dev:		Device pointer.
+ * @zynqmp_pins:	Pin information.
+ * @npins:		Number of pins.
+ *
+ * Query number of pins information from firmware and prepare pin
+ * description containing pin number and pin name.
+ *
+ * Return: 0 on success else error code.
+ */
+static int zynqmp_pinctrl_prepare_pin_desc(struct device *dev,
+					   const struct pinctrl_pin_desc
+					   **zynqmp_pins,
+					   unsigned int *npins)
+{
+	struct pinctrl_pin_desc *pins, *pin;
+	int ret;
+	int i;
+
+	ret = zynqmp_pinctrl_get_num_pins(npins);
+	if (ret)
+		return ret;
+
+	pins = devm_kzalloc(dev, sizeof(*pins) * *npins, GFP_KERNEL);
+	if (!pins)
+		return -ENOMEM;
+
+	for (i = 0; i < *npins; i++) {
+		pin = &pins[i];
+		pin->number = i;
+		pin->name = devm_kasprintf(dev, GFP_KERNEL, "%s%d",
+					   ZYNQMP_PIN_PREFIX, i);
+		if (!pin->name)
+			return -ENOMEM;
+	}
+
+	*zynqmp_pins = pins;
+
+	return 0;
+}
+
+static int zynqmp_pinctrl_probe(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl;
+	int ret;
+
+	pctrl = devm_kzalloc(&pdev->dev, sizeof(*pctrl), GFP_KERNEL);
+	if (!pctrl)
+		return -ENOMEM;
+
+	ret = zynqmp_pinctrl_prepare_pin_desc(&pdev->dev,
+					      &zynqmp_desc.pins,
+					      &zynqmp_desc.npins);
+	if (ret) {
+		dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	ret = zynqmp_pinctrl_prepare_function_info(&pdev->dev, pctrl);
+	if (ret) {
+		dev_err(&pdev->dev, "function info prepare fail with %d\n",
+			ret);
+		return ret;
+	}
+
+	pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);
+	if (IS_ERR(pctrl->pctrl))
+		return PTR_ERR(pctrl->pctrl);
+
+	platform_set_drvdata(pdev, pctrl);
+
+	return ret;
+}
+
+static int zynqmp_pinctrl_remove(struct platform_device *pdev)
+{
+	struct zynqmp_pinctrl *pctrl = platform_get_drvdata(pdev);
+
+	pinctrl_unregister(pctrl->pctrl);
+
+	return 0;
+}
+
+static const struct of_device_id zynqmp_pinctrl_of_match[] = {
+	{ .compatible = "xlnx,zynqmp-pinctrl" },
+	{ }
+};
+
+MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);
+
+static struct platform_driver zynqmp_pinctrl_driver = {
+	.driver = {
+		.name = "zynqmp-pinctrl",
+		.of_match_table = zynqmp_pinctrl_of_match,
+	},
+	.probe = zynqmp_pinctrl_probe,
+	.remove = zynqmp_pinctrl_remove,
+};
+
+module_platform_driver(zynqmp_pinctrl_driver);
+
+MODULE_AUTHOR("Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>");
+MODULE_DESCRIPTION("ZynqMP Pin Controller Driver");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1



From michael.kao at mediatek.com  Thu Apr 22 09:32:38 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Thu, 22 Apr 2021 16:32:38 +0800
Subject: [v3,1/3] thermal: mediatek: Relocate driver to mediatek folder
In-Reply-To: <836581c1-0738-8e42-b168-b54d0bd078a5@linaro.org>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-2-michael.kao@mediatek.com>
 <836581c1-0738-8e42-b168-b54d0bd078a5@linaro.org>
Message-ID: <8532c21e518530d06a37c25bbcbc08d97147769a.camel@mediatek.com>

On Tue, 2021-04-20 at 23:22 +0200, Daniel Lezcano wrote:
> On 12/03/2021 04:40, Michael Kao wrote:
> > Add Mediatek proprietary folder to upstream more thermal zone and
> > cooler
> > drivers. Relocate the original thermal controller driver to it and
> > rename
> > as soc_temp.c to show its purpose more clearly.
> 
> We already know the purpose :)
> 
> soc_temp gives no additional information.
> 
> Either keep the name or give the hardware sensor name. It is a driver
> directory.
> 
Dear Daniel,

We introduce the new thermal hardware design called lvts in the new
project. The new project will desgin with lvts will enable the
CONFIG_MTK_SOC_THERMAL_LVTS to build lvts driver[1].
The old project will use CONFIG_MTK_THERMAL to build soc_temp.c.

The new design use lvts device to access thermal sensors in the soc.
The original design access thermal sensors by auxadc.

[1] [v3,2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones


> > Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> > ---
> >  drivers/thermal/Kconfig                       | 14 ++++-------
> >  drivers/thermal/Makefile                      |  2 +-
> >  drivers/thermal/mediatek/Kconfig              | 23
> > +++++++++++++++++++
> >  drivers/thermal/mediatek/Makefile             |  1 +
> >  .../{mtk_thermal.c => mediatek/soc_temp.c}    |  0
> 
> [ ... ]
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> 
> 
> > +config MTK_THERMAL
> > +	tristate "Mediatek thermal drivers"
> > +	depends on THERMAL_OF
> > +	help
> > +	  This is the option for Mediatek thermal software
> > +	  solutions. Please enable corresponding options to
> > +	  get temperature information from thermal sensors or
> > +	  turn on throttle mechaisms for thermal mitigation.
> > +
> > +if MTK_THERMAL
> 
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> All the above not needed.
> 
> > +config MTK_SOC_THERMAL
> > +	tristate "Temperature sensor driver for mediatek SoCs"
> > +	depends on HAS_IOMEM
> > +	depends on NVMEM
> > +	depends on RESET_CONTROLLER
> > +	help
> > +	  Enable this option if you want to get SoC temperature
> > +	  information for Mediatek platforms. This driver
> > +	  configures thermal controllers to collect temperature
> > +	  via AUXADC interface.
> > +
> > +endif
> > diff --git a/drivers/thermal/mediatek/Makefile
> > b/drivers/thermal/mediatek/Makefile
> > new file mode 100644
> > index 000000000000..f75313ddce5e
> > --- /dev/null
> > +++ b/drivers/thermal/mediatek/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_MTK_SOC_THERMAL)	+= soc_temp.o
> > diff --git a/drivers/thermal/mtk_thermal.c
> > b/drivers/thermal/mediatek/soc_temp.c
> > similarity index 100%
> > rename from drivers/thermal/mtk_thermal.c
> > rename to drivers/thermal/mediatek/soc_temp.c
> 
> 
> 

From David.Laight at ACULAB.COM  Thu Apr 22 09:37:41 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 22 Apr 2021 08:37:41 +0000
Subject: [RFC PATCH v3 6/8] arm64: Add a compat syscall flag to thread_info
In-Reply-To: <20210421190207.1803139-7-amanieu@gmail.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
 <20210421190207.1803139-7-amanieu@gmail.com>
Message-ID: <859ad8a943484270b95bab5073a5c031@AcuMS.aculab.com>

From: Amanieu d'Antras
> Sent: 21 April 2021 20:02
> 
> This flag is used by in_compat_syscall to handle compat syscalls coming
> from 64-bit tasks.
> 
> Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
> Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
> Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
> ---
>  arch/arm64/include/asm/compat.h      |  5 +++--
>  arch/arm64/include/asm/elf.h         | 13 ++++++++++++-
>  arch/arm64/include/asm/thread_info.h |  3 +++
>  3 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
> index a2f5001f7793..71de0ba8b160 100644
> --- a/arch/arm64/include/asm/compat.h
> +++ b/arch/arm64/include/asm/compat.h
> @@ -190,13 +190,14 @@ static inline bool is_compat_thread(struct thread_info *thread)
> 
>  static inline bool in_compat_syscall(void)
>  {
> -	return is_compat_task();
> +	return is_compat_task() ||
> +		current_thread_info()->aarch64_compat_syscall;
>  }
...

Wouldn't it be better to ensure that a 'compat_task'
always has aarch64_compat_syscall set.

If you can't do that, just replacing the '||' with '|'
will generate better code for the usual case of both
flags being clear.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)



From gregkh at linuxfoundation.org  Thu Apr 22 09:46:07 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 22 Apr 2021 10:46:07 +0200
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <1617675492.22435.4.camel@mhfsdcap03>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03> <YGq2YfURFApdJLxb@kroah.com>
 <1617675492.22435.4.camel@mhfsdcap03>
Message-ID: <YIE3z7qYNtk7G/VB@kroah.com>

On Tue, Apr 06, 2021 at 10:18:12AM +0800, Chunfeng Yun wrote:
> On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > > cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> > > 
> > > I'll test it , thanks
> > 
> > Did you test this series and find any problems?  If not, I'll go queue
> > these up...
> Yes, found an issue on the start-split transaction, but not found the
> root cause yet :(

So you are objecting to these being merged at this point in time?  Can
you provide feedback to the author about what is wrong?

thanks,

greg k-h


From michael.kao at mediatek.com  Thu Apr 22 09:47:28 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Thu, 22 Apr 2021 16:47:28 +0800
Subject: [v3,1/3] thermal: mediatek: Relocate driver to mediatek folder
In-Reply-To: <836581c1-0738-8e42-b168-b54d0bd078a5@linaro.org>
References: <20210312034018.17437-1-michael.kao@mediatek.com>
 <20210312034018.17437-2-michael.kao@mediatek.com>
 <836581c1-0738-8e42-b168-b54d0bd078a5@linaro.org>
Message-ID: <6db776994f939cd5403addeffdc78fc82bc98e7a.camel@mediatek.com>

On Tue, 2021-04-20 at 23:22 +0200, Daniel Lezcano wrote:
> On 12/03/2021 04:40, Michael Kao wrote:
> > Add Mediatek proprietary folder to upstream more thermal zone and
> > cooler
> > drivers. Relocate the original thermal controller driver to it and
> > rename
> > as soc_temp.c to show its purpose more clearly.
> 
> We already know the purpose :)
> 
> soc_temp gives no additional information.
> 
> Either keep the name or give the hardware sensor name. It is a driver
> directory.
> 

Dear Daniel,
The new thermal hardware design called lvts (Low voltage thermal
sensor).
Instead of original one using auxadc, the lvts use lvts device to
access thermal senosrs.
It will save power and be more efficient.
We use the config CONFIG_MTK_THERMAL and CONFIG_MTK_SOC_THERMAL_LVTS[1]
to select the different hardware archtecture.

[1] [v3,2/3] thermal: mediatek: Add LVTS drivers for SoC theraml zones

https://patchwork.kernel.org/project/linux-mediatek/patch/20210312034018.17437-3-michael.kao at mediatek.com/

> > Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> > ---
> >  drivers/thermal/Kconfig                       | 14 ++++-------
> >  drivers/thermal/Makefile                      |  2 +-
> >  drivers/thermal/mediatek/Kconfig              | 23
> > +++++++++++++++++++
> >  drivers/thermal/mediatek/Makefile             |  1 +
> >  .../{mtk_thermal.c => mediatek/soc_temp.c}    |  0
> 
> [ ... ]
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> 
> 
> > +config MTK_THERMAL
> > +	tristate "Mediatek thermal drivers"
> > +	depends on THERMAL_OF
> > +	help
> > +	  This is the option for Mediatek thermal software
> > +	  solutions. Please enable corresponding options to
> > +	  get temperature information from thermal sensors or
> > +	  turn on throttle mechaisms for thermal mitigation.
> > +
> > +if MTK_THERMAL
> 
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> All the above not needed.
> 
> > +config MTK_SOC_THERMAL
> > +	tristate "Temperature sensor driver for mediatek SoCs"
> > +	depends on HAS_IOMEM
> > +	depends on NVMEM
> > +	depends on RESET_CONTROLLER
> > +	help
> > +	  Enable this option if you want to get SoC temperature
> > +	  information for Mediatek platforms. This driver
> > +	  configures thermal controllers to collect temperature
> > +	  via AUXADC interface.
> > +
> > +endif
> > diff --git a/drivers/thermal/mediatek/Makefile
> > b/drivers/thermal/mediatek/Makefile
> > new file mode 100644
> > index 000000000000..f75313ddce5e
> > --- /dev/null
> > +++ b/drivers/thermal/mediatek/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_MTK_SOC_THERMAL)	+= soc_temp.o
> > diff --git a/drivers/thermal/mtk_thermal.c
> > b/drivers/thermal/mediatek/soc_temp.c
> > similarity index 100%
> > rename from drivers/thermal/mtk_thermal.c
> > rename to drivers/thermal/mediatek/soc_temp.c
> 
> 
> 

From jason at os.amperecomputing.com  Thu Apr 22 09:49:44 2021
From: jason at os.amperecomputing.com (Jason Tian)
Date: Thu, 22 Apr 2021 16:49:44 +0800
Subject: [PATCH RESEND] ARM64: RAS: Update code to trace out more data for ARM
 processor
Message-ID: <20210422084944.3718-1-jason@os.amperecomputing.com>

The original arm_event trace code only traces out ARM processor error
information data. According to UEFI_2_8_A_Feb14 specification chapter
N2.4.4, the ARM processor error section includes several ARM processor
error information, several ARM processor context information and several
vendor specific error information structures.

Add code to trace out all ARM processor context information and vendor
specific error information with raw hex format.

Signed-off-by: Jason Tian <jason at os.amperecomputing.com>
---
 drivers/ras/ras.c       | 22 +++++++++++++++++++++-
 include/ras/ras_event.h | 41 +++++++++++++++++++++++++++++++++++------
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index 95540ea8dd9d..6f3269da9476 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -23,7 +23,27 @@ void log_non_standard_event(const guid_t *sec_type, const guid_t *fru_id,
 
 void log_arm_hw_error(struct cper_sec_proc_arm *err)
 {
-	trace_arm_event(err);
+	u32 pei_len;
+	u32 ctx_len;
+	u32 vsei_len;
+	u8 *pei_err;
+	u8 *ctx_err;
+	u8 *ven_err_data;
+
+	pei_len = sizeof(struct cper_arm_err_info) * err->err_info_num;
+	pei_err = (u8 *) err + sizeof(struct cper_sec_proc_arm);
+
+	ctx_len = sizeof(struct cper_arm_ctx_info) * err->context_info_num;
+	ctx_err = pei_err + sizeof(struct cper_arm_err_info) *
+		err->err_info_num;
+
+	vsei_len = err->section_length - (sizeof(struct cper_sec_proc_arm) +
+					  pei_len + ctx_len);
+	ven_err_data = ctx_err + sizeof(struct cper_arm_ctx_info) *
+					  err->context_info_num;
+
+	trace_arm_event(err, pei_err, pei_len, ctx_err, ctx_len,
+			ven_err_data, vsei_len);
 }
 
 static int __init ras_init(void)
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 0bdbc0d17d2f..fd9201214be8 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -168,11 +168,22 @@ TRACE_EVENT(mc_event,
  * This event is generated when hardware detects an ARM processor error
  * has occurred. UEFI 2.6 spec section N.2.4.4.
  */
+ #define APEIL "ARM Processor Err Info data len"
+ #define APEID "ARM Processor Err Info raw data"
+ #define APECIL "ARM Processor Err Context Info data len"
+ #define APECID "ARM Processor Err Context Info raw data"
+ #define VSEIL "Vendor Specific Err Info data len"
+ #define VSEID "Vendor Specific Err Info raw data"
 TRACE_EVENT(arm_event,
 
-	TP_PROTO(const struct cper_sec_proc_arm *proc),
+	TP_PROTO(const struct cper_sec_proc_arm *proc, const u8 *pei_err,
+		const u32 pei_len,
+		const u8 *ctx_err,
+		const u32 ctx_len,
+		const u8 *oem,
+		const u32 oem_len),
 
-	TP_ARGS(proc),
+	TP_ARGS(proc, pei_err, pei_len, ctx_err, ctx_len, oem, oem_len),
 
 	TP_STRUCT__entry(
 		__field(u64, mpidr)
@@ -180,6 +191,12 @@ TRACE_EVENT(arm_event,
 		__field(u32, running_state)
 		__field(u32, psci_state)
 		__field(u8, affinity)
+		__field(u32, pei_len)
+		__dynamic_array(u8, buf, pei_len)
+		__field(u32, ctx_len)
+		__dynamic_array(u8, buf1, ctx_len)
+		__field(u32, oem_len)
+		__dynamic_array(u8, buf2, oem_len)
 	),
 
 	TP_fast_assign(
@@ -199,12 +216,24 @@ TRACE_EVENT(arm_event,
 			__entry->running_state = ~0;
 			__entry->psci_state = ~0;
 		}
+		__entry->pei_len = pei_len;
+		memcpy(__get_dynamic_array(buf), pei_err, pei_len);
+		__entry->ctx_len = ctx_len;
+		memcpy(__get_dynamic_array(buf1), ctx_err, ctx_len);
+		__entry->oem_len = oem_len;
+		memcpy(__get_dynamic_array(buf2), oem, oem_len);
 	),
 
-	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
-		  "running state: %d; PSCI state: %d",
-		  __entry->affinity, __entry->mpidr, __entry->midr,
-		  __entry->running_state, __entry->psci_state)
+	TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; running state: %d; "
+		"PSCI state: %d; %s: %d; %s: %s; %s: %d; %s: %s; %s: %d; %s: %s",
+		__entry->affinity, __entry->mpidr, __entry->midr,
+		__entry->running_state, __entry->psci_state,
+		APEIL, __entry->pei_len, APEID,
+		__print_hex(__get_dynamic_array(buf), __entry->pei_len),
+		APECIL, __entry->ctx_len, APECID,
+		__print_hex(__get_dynamic_array(buf1), __entry->ctx_len),
+		VSEIL, __entry->oem_len, VSEID,
+		__print_hex(__get_dynamic_array(buf2), __entry->oem_len))
 );
 
 /*
-- 
2.25.1



From david at redhat.com  Thu Apr 22 09:57:34 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 22 Apr 2021 10:57:34 +0200
Subject: [PATCH v3 3/4] arm64: decouple check whether pfn is in linear map
 from pfn_valid()
In-Reply-To: <20210422061902.21614-4-rppt@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
 <20210422061902.21614-4-rppt@kernel.org>
Message-ID: <041411e9-0fba-f053-d901-10f1d7a8cc5e@redhat.com>

On 22.04.21 08:19, Mike Rapoport wrote:
> From: Mike Rapoport <rppt at linux.ibm.com>
> 
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
> 
> Yet, on arm64 it is used to distinguish memory areas that are mapped in the
> linear map vs those that require ioremap() to access them.
> 
> Introduce a dedicated pfn_is_map_memory() wrapper for
> memblock_is_map_memory() to perform such check and use it where
> appropriate.
> 
> Using a wrapper allows to avoid cyclic include dependencies.
> 
> While here also update style of pfn_valid() so that both pfn_valid() and
> pfn_is_map_memory() declarations will be consistent.
> 
> Signed-off-by: Mike Rapoport <rppt at linux.ibm.com>
> ---
>   arch/arm64/include/asm/memory.h |  2 +-
>   arch/arm64/include/asm/page.h   |  3 ++-
>   arch/arm64/kvm/mmu.c            |  2 +-
>   arch/arm64/mm/init.c            | 12 ++++++++++++
>   arch/arm64/mm/ioremap.c         |  4 ++--
>   arch/arm64/mm/mmu.c             |  2 +-
>   6 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0aabc3be9a75..194f9f993d30 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>   
>   #define virt_addr_valid(addr)	({					\
>   	__typeof__(addr) __addr = __tag_reset(addr);			\
> -	__is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));	\
> +	__is_lm_address(__addr) && pfn_is_map_memory(virt_to_pfn(__addr));	\
>   })
>   
>   void dump_mem_limit(void);
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 012cffc574e8..75ddfe671393 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -37,7 +37,8 @@ void copy_highpage(struct page *to, struct page *from);
>   
>   typedef struct page *pgtable_t;
>   
> -extern int pfn_valid(unsigned long);
> +int pfn_valid(unsigned long pfn);
> +int pfn_is_map_memory(unsigned long pfn);
>   
>   #include <asm/memory.h>
>   
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..23dd99e29b23 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
>   
>   static bool kvm_is_device_pfn(unsigned long pfn)
>   {
> -	return !pfn_valid(pfn);
> +	return !pfn_is_map_memory(pfn);
>   }
>   
>   /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..966a7a18d528 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -258,6 +258,18 @@ int pfn_valid(unsigned long pfn)
>   }
>   EXPORT_SYMBOL(pfn_valid);
>   
> +int pfn_is_map_memory(unsigned long pfn)
> +{
> +	phys_addr_t addr = PFN_PHYS(pfn);
> +
> +	/* avoid false positives for bogus PFNs, see comment in pfn_valid() */
> +	if (PHYS_PFN(addr) != pfn)
> +		return 0;
> +
> +	return memblock_is_map_memory(addr);
> +}
> +EXPORT_SYMBOL(pfn_is_map_memory);
> +
>   static phys_addr_t memory_limit = PHYS_ADDR_MAX;
>   
>   /*
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index b5e83c46b23e..b7c81dacabf0 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -43,7 +43,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
>   	/*
>   	 * Don't allow RAM to be mapped.
>   	 */
> -	if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> +	if (WARN_ON(pfn_is_map_memory(__phys_to_pfn(phys_addr))))
>   		return NULL;
>   
>   	area = get_vm_area_caller(size, VM_IOREMAP, caller);
> @@ -84,7 +84,7 @@ EXPORT_SYMBOL(iounmap);
>   void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
>   {
>   	/* For normal memory we already have a cacheable mapping. */
> -	if (pfn_valid(__phys_to_pfn(phys_addr)))
> +	if (pfn_is_map_memory(__phys_to_pfn(phys_addr)))
>   		return (void __iomem *)__phys_to_virt(phys_addr);
>   
>   	return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 5d9550fdb9cf..26045e9adbd7 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -81,7 +81,7 @@ void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
>   pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>   			      unsigned long size, pgprot_t vma_prot)
>   {
> -	if (!pfn_valid(pfn))
> +	if (!pfn_is_map_memory(pfn))
>   		return pgprot_noncached(vma_prot);
>   	else if (file->f_flags & O_SYNC)
>   		return pgprot_writecombine(vma_prot);
> 

Acked-by: David Hildenbrand <david at redhat.com>

-- 
Thanks,

David / dhildenb



From dan.carpenter at oracle.com  Thu Apr 22 10:02:29 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 22 Apr 2021 12:02:29 +0300
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
Message-ID: <YIE7pdqV/h10tEAK@mwanda>

How type promotion works in ternary expressions is a bit tricky.
The problem is that scpi_clk_get_val() returns longs, "ret" is a int
which holds a negative error code, and le32_to_cpu() is an unsigned int.
We want the negative error code to be cast to a negative long.  But
because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
becomes a high positive and then it is promoted to long and it is still
a high positive value.

Fix this by getting rid of the ternary.

Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
---
 drivers/firmware/arm_scpi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index d0dee37ad522..3bf61854121d 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
 
 	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
 				sizeof(le_clk_id), &rate, sizeof(rate));
+	if (ret)
+		return ret;
 
-	return ret ? ret : le32_to_cpu(rate);
+	return le32_to_cpu(rate);
 }
 
 static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
-- 
2.30.2



From david at redhat.com  Thu Apr 22 10:03:50 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 22 Apr 2021 11:03:50 +0200
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
Message-ID: <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>

On 22.04.21 09:50, Anshuman Khandual wrote:
> Platforms like arm and arm64 have redefined pfn_valid() because their early
> memory sections might have contained memmap holes after freeing parts of it
> during boot, which should be skipped while validating a pfn for struct page
> backing. This scenario on certain platforms where memmap is not continuous,
> could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
> Then the generic pfn_valid() can be improved to accommodate such platforms.
> This reduces overall code footprint and also improves maintainability.
> 
> free_unused_memmap() and pfn_to_online_page() have been updated to include
> such cases. This also exports memblock_is_memory() for all drivers that use
> pfn_valid() but lack required visibility. After the new config is in place,
> drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Mike Rapoport <rppt at kernel.org>
> Cc: David Hildenbrand <david at redhat.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-mm at kvack.org
> Suggested-by: David Hildenbrand <david at redhat.com>
> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> ---
> This patch applies on the latest mainline kernel after Mike's series
> regarding arm64 based pfn_valid().
> 
> https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t
> 
> Changes in RFC V2:
> 
> - Dropped support for arm (32 bit)
> - Replaced memblock_is_map_memory() check with memblock_is_memory()
> - MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
> - Updated pfn_to_online_page() per David
> - Updated free_unused_memmap() to preserve existing semantics per Mike
> - Exported memblock_is_memory() instead of memblock_is_map_memory()
> 
> Changes in RFC V1:
> 
> - https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/
> 
>   arch/arm64/Kconfig            |  2 +-
>   arch/arm64/include/asm/page.h |  1 -
>   arch/arm64/mm/init.c          | 41 -----------------------------------
>   include/linux/mmzone.h        | 18 ++++++++++++++-
>   mm/Kconfig                    |  9 ++++++++
>   mm/memblock.c                 |  8 +++++--
>   mm/memory_hotplug.c           |  5 +++++
>   7 files changed, 38 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b4a9b493ce72..4cdc3570ffa9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -144,7 +144,6 @@ config ARM64
>   	select HAVE_ARCH_KGDB
>   	select HAVE_ARCH_MMAP_RND_BITS
>   	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> -	select HAVE_ARCH_PFN_VALID
>   	select HAVE_ARCH_PREL32_RELOCATIONS
>   	select HAVE_ARCH_SECCOMP_FILTER
>   	select HAVE_ARCH_STACKLEAK
> @@ -167,6 +166,7 @@ config ARM64
>   		if $(cc-option,-fpatchable-function-entry=2)
>   	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
>   		if DYNAMIC_FTRACE_WITH_REGS
> +	select HAVE_EARLY_SECTION_MEMMAP_HOLES
>   	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>   	select HAVE_FAST_GUP
>   	select HAVE_FTRACE_MCOUNT_RECORD
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 75ddfe671393..fcbef3eec4b2 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
>   
>   typedef struct page *pgtable_t;
>   
> -int pfn_valid(unsigned long pfn);
>   int pfn_is_map_memory(unsigned long pfn);
>   
>   #include <asm/memory.h>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f431b38d0837..5731a11550d8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>   	free_area_init(max_zone_pfns);
>   }
>   
> -int pfn_valid(unsigned long pfn)
> -{
> -	phys_addr_t addr = PFN_PHYS(pfn);
> -
> -	/*
> -	 * Ensure the upper PAGE_SHIFT bits are clear in the
> -	 * pfn. Else it might lead to false positives when
> -	 * some of the upper bits are set, but the lower bits
> -	 * match a valid pfn.
> -	 */
> -	if (PHYS_PFN(addr) != pfn)
> -		return 0;
> -
> -#ifdef CONFIG_SPARSEMEM
> -{
> -	struct mem_section *ms;
> -
> -	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> -		return 0;
> -
> -	ms = __pfn_to_section(pfn);
> -	if (!valid_section(ms))
> -		return 0;
> -
> -	/*
> -	 * ZONE_DEVICE memory does not have the memblock entries.
> -	 * memblock_is_memory() check for ZONE_DEVICE based
> -	 * addresses will always fail. Even the normal hotplugged
> -	 * memory will never have MEMBLOCK_NOMAP flag set in their
> -	 * memblock entries. Skip memblock search for all non early
> -	 * memory sections covering all of hotplug memory including
> -	 * both normal and ZONE_DEVICE based.
> -	 */
> -	if (!early_section(ms))
> -		return pfn_section_valid(ms, pfn);
> -}
> -#endif
> -	return memblock_is_memory(addr);
> -}
> -EXPORT_SYMBOL(pfn_valid);
> -
>   int pfn_is_map_memory(unsigned long pfn)
>   {
>   	phys_addr_t addr = PFN_PHYS(pfn);
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 961f0eeefb62..18bf71665211 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>    *
>    * Return: 1 for PFNs that have memory map entries and 0 otherwise
>    */
> +bool memblock_is_memory(phys_addr_t addr);
> +
>   static inline int pfn_valid(unsigned long pfn)
>   {
> +	phys_addr_t addr = PFN_PHYS(pfn);
>   	struct mem_section *ms;
>   
> +	/*
> +	 * Ensure the upper PAGE_SHIFT bits are clear in the
> +	 * pfn. Else it might lead to false positives when
> +	 * some of the upper bits are set, but the lower bits
> +	 * match a valid pfn.
> +	 */
> +	if (PHYS_PFN(addr) != pfn)
> +		return 0;
> +
>   	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>   		return 0;
>   	ms = __nr_to_section(pfn_to_section_nr(pfn));
> @@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
>   	 * Traditionally early sections always returned pfn_valid() for
>   	 * the entire section-sized span.
>   	 */
> -	return early_section(ms) || pfn_section_valid(ms, pfn);
> +	if (early_section(ms))
> +		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
> +			memblock_is_memory(pfn << PAGE_SHIFT) : 1;
> +
> +	return pfn_section_valid(ms, pfn);
>   }
>   #endif
>   
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 24c045b24b95..db7128111874 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -135,6 +135,15 @@ config HAVE_FAST_GUP
>   config ARCH_KEEP_MEMBLOCK
>   	bool
>   
> +config HAVE_EARLY_SECTION_MEMMAP_HOLES
> +	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
> +	def_bool n
> +	help
> +	  Early sections on certain platforms might have some memory ranges that
> +	  are not backed with struct page mappings. When subscribed, this option
> +	  enables special handling for those memory ranges in certain situations
> +	  such as pfn_valid().
> +
>   # Keep arch NUMA mapping infrastructure post-init.
>   config NUMA_KEEP_MEMINFO
>   	bool
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 3abf2c3fea7f..93f8a9c8428d 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
>   {
>   	return memblock_search(&memblock.memory, addr) != -1;
>   }
> +EXPORT_SYMBOL(memblock_is_memory);
>   
>   bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
>   {
> @@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
>   	unsigned long start, end, prev_end = 0;
>   	int i;
>   
> -	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
> -	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> +	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> +		return;
> +
> +	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
> +	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
>   		return;
>   
>   	/*
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 0cdbbfbc5757..8c78b6a3d888 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -309,6 +309,11 @@ struct page *pfn_to_online_page(unsigned long pfn)
>   	 * Save some code text when online_section() +
>   	 * pfn_section_valid() are sufficient.
>   	 */
> +	if (IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES)) {
> +		if (early_section(ms) && !memblock_is_memory(PFN_PHYS(pfn)))
> +			return NULL;
> +	}
> +
>   	if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) && !pfn_valid(pfn))
>   		return NULL;
>   
> 

What about doing one step at a time and switching only over to generic 
pfn_valid() in case of CONFIG_SPARSEMEM? (meaning: freeing the memmap 
only with !CONFIG_SPARSEMEM)

IOW, avoiding having to adjust generic pfn_valid()/pfn_to_online_page() 
at all. Am i missing something or should that be possible?

-- 
Thanks,

David / dhildenb



From lkp at intel.com  Thu Apr 22 10:08:26 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 17:08:26 +0800
Subject: [xlnx:master 368/392]
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2650:5: warning: no
 previous prototype for 'axienet_ethtools_sset_count'
Message-ID: <202104221719.7EYuiqWy-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   bcd80b4c331c5d55de978ab0b2f6181a8aea3434
commit: 0605a36e057480f3a83ae401e7ff59739da78e82 [368/392] net: xilinx: Ethtool statistics support
config: nds32-randconfig-r021-20210421 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/0605a36e057480f3a83ae401e7ff59739da78e82
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 0605a36e057480f3a83ae401e7ff59739da78e82
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nds32 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2650:5: warning: no previous prototype for 'axienet_ethtools_sset_count' [-Wmissing-prototypes]
    2650 | int axienet_ethtools_sset_count(struct net_device *ndev, int sset)
         |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2673:6: warning: no previous prototype for 'axienet_ethtools_get_stats' [-Wmissing-prototypes]
    2673 | void axienet_ethtools_get_stats(struct net_device *ndev,
         |      ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:2700:6: warning: no previous prototype for 'axienet_ethtools_strings' [-Wmissing-prototypes]
    2700 | void axienet_ethtools_strings(struct net_device *ndev, u32 sset, u8 *data)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~


vim +/axienet_ethtools_sset_count +2650 drivers/net/ethernet/xilinx/xilinx_axienet_main.c

  2640	
  2641	/**
  2642	 * axienet_ethtools_sset_count - Get number of strings that
  2643	 *				 get_strings will write.
  2644	 * @ndev:	Pointer to net_device structure
  2645	 * @sset:	Get the set strings
  2646	 *
  2647	 * Return: number of strings, on success, Non-zero error value on
  2648	 *	   failure.
  2649	 */
> 2650	int axienet_ethtools_sset_count(struct net_device *ndev, int sset)
  2651	{
  2652		switch (sset) {
  2653		case ETH_SS_STATS:
  2654	#ifdef CONFIG_AXIENET_HAS_MCDMA
  2655			return axienet_sset_count(ndev, sset);
  2656	#else
  2657			return AXIENET_ETHTOOLS_SSTATS_LEN;
  2658	#endif
  2659		default:
  2660			return -EOPNOTSUPP;
  2661		}
  2662	}
  2663	
  2664	/**
  2665	 * axienet_ethtools_get_stats - Get the extended statistics
  2666	 *				about the device.
  2667	 * @ndev:	Pointer to net_device structure
  2668	 * @stats:	Pointer to ethtool_stats structure
  2669	 * @data:	To store the statistics values
  2670	 *
  2671	 * Return: None.
  2672	 */
> 2673	void axienet_ethtools_get_stats(struct net_device *ndev,
  2674					struct ethtool_stats *stats,
  2675					u64 *data)
  2676	{
  2677		unsigned int i = 0;
  2678	
  2679		data[i++] = ndev->stats.tx_packets;
  2680		data[i++] = ndev->stats.rx_packets;
  2681		data[i++] = ndev->stats.tx_bytes;
  2682		data[i++] = ndev->stats.rx_bytes;
  2683		data[i++] = ndev->stats.tx_errors;
  2684		data[i++] = ndev->stats.rx_missed_errors + ndev->stats.rx_frame_errors;
  2685	
  2686	#ifdef CONFIG_AXIENET_HAS_MCDMA
  2687		axienet_get_stats(ndev, stats, data);
  2688	#endif
  2689	}
  2690	
  2691	/**
  2692	 * axienet_ethtools_strings - Set of strings that describe
  2693	 *			 the requested objects.
  2694	 * @ndev:	Pointer to net_device structure
  2695	 * @sset:	Get the set strings
  2696	 * @data:	Data of Transmit and Receive statistics
  2697	 *
  2698	 * Return: None.
  2699	 */
> 2700	void axienet_ethtools_strings(struct net_device *ndev, u32 sset, u8 *data)
  2701	{
  2702		int i;
  2703	
  2704		for (i = 0; i < AXIENET_ETHTOOLS_SSTATS_LEN; i++) {
  2705			if (sset == ETH_SS_STATS)
  2706				memcpy(data + i * ETH_GSTRING_LEN,
  2707				       axienet_get_ethtools_strings_stats[i].name,
  2708				       ETH_GSTRING_LEN);
  2709		}
  2710	#ifdef CONFIG_AXIENET_HAS_MCDMA
  2711		axienet_strings(ndev, sset, data);
  2712	#endif
  2713	}
  2714	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/611d476b/attachment-0001.gz>

From thunder.leizhen at huawei.com  Thu Apr 22 10:08:57 2021
From: thunder.leizhen at huawei.com (Zhen Lei)
Date: Thu, 22 Apr 2021 17:08:57 +0800
Subject: [PATCH 1/1] dt-bindings: serial: 8250: Remove duplicated compatible
 strings
Message-ID: <20210422090857.583-1-thunder.leizhen@huawei.com>

The compatible strings "mediatek,*" appears two times, remove one of them.

Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema")
Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
---
 Documentation/devicetree/bindings/serial/8250.yaml | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index f54cae9ff7b2..d3f87f2bfdc2 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -93,11 +93,6 @@ properties:
               - mediatek,mt7622-btif
               - mediatek,mt7623-btif
           - const: mediatek,mtk-btif
-      - items:
-          - enum:
-              - mediatek,mt7622-btif
-              - mediatek,mt7623-btif
-          - const: mediatek,mtk-btif
       - items:
           - const: mrvl,mmp-uart
           - const: intel,xscale-uart
-- 
2.21.1




From linus.walleij at linaro.org  Thu Apr 22 10:13:50 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 22 Apr 2021 11:13:50 +0200
Subject: [PATCH v6 0/3] Add ZynqMP pinctrl driver
In-Reply-To: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <CACRpkdaDP+JnCP+go9hZAObnNgmJyJRDFypX2CZGp-UJBh5wNA@mail.gmail.com>

On Thu, Apr 22, 2021 at 10:30 AM Sai Krishna Potthuri
<lakshmi.sai.krishna.potthuri at xilinx.com> wrote:

> changes in v6:
> - Rebased the patche series on 'devel' branch in pinctrl tree and no
> functional changes.

Remaining patches applied! Thanks for working so hard on this!

Yours,
Linus Walleij


From rppt at kernel.org  Thu Apr 22 10:42:58 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 12:42:58 +0300
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>
Message-ID: <YIFFIiuy+z3WLHDi@kernel.org>

On Thu, Apr 22, 2021 at 11:03:50AM +0200, David Hildenbrand wrote:
> On 22.04.21 09:50, Anshuman Khandual wrote:
> > Platforms like arm and arm64 have redefined pfn_valid() because their early
> > memory sections might have contained memmap holes after freeing parts of it
> > during boot, which should be skipped while validating a pfn for struct page
> > backing. This scenario on certain platforms where memmap is not continuous,
> > could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
> > Then the generic pfn_valid() can be improved to accommodate such platforms.
> > This reduces overall code footprint and also improves maintainability.
> > 
> > free_unused_memmap() and pfn_to_online_page() have been updated to include
> > such cases. This also exports memblock_is_memory() for all drivers that use
> > pfn_valid() but lack required visibility. After the new config is in place,
> > drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.
> > 
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Cc: Andrew Morton <akpm at linux-foundation.org>
> > Cc: Mike Rapoport <rppt at kernel.org>
> > Cc: David Hildenbrand <david at redhat.com>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-mm at kvack.org
> > Suggested-by: David Hildenbrand <david at redhat.com>
> > Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
> > ---
> > This patch applies on the latest mainline kernel after Mike's series
> > regarding arm64 based pfn_valid().
> > 
> > https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t
> > 
> > Changes in RFC V2:
> > 
> > - Dropped support for arm (32 bit)
> > - Replaced memblock_is_map_memory() check with memblock_is_memory()
> > - MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
> > - Updated pfn_to_online_page() per David
> > - Updated free_unused_memmap() to preserve existing semantics per Mike
> > - Exported memblock_is_memory() instead of memblock_is_map_memory()
> > 
> > Changes in RFC V1:
> > 
> > - https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/
> > 
> >   arch/arm64/Kconfig            |  2 +-
> >   arch/arm64/include/asm/page.h |  1 -
> >   arch/arm64/mm/init.c          | 41 -----------------------------------
> >   include/linux/mmzone.h        | 18 ++++++++++++++-
> >   mm/Kconfig                    |  9 ++++++++
> >   mm/memblock.c                 |  8 +++++--
> >   mm/memory_hotplug.c           |  5 +++++
> >   7 files changed, 38 insertions(+), 46 deletions(-)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index b4a9b493ce72..4cdc3570ffa9 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -144,7 +144,6 @@ config ARM64
> >   	select HAVE_ARCH_KGDB
> >   	select HAVE_ARCH_MMAP_RND_BITS
> >   	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> > -	select HAVE_ARCH_PFN_VALID
> >   	select HAVE_ARCH_PREL32_RELOCATIONS
> >   	select HAVE_ARCH_SECCOMP_FILTER
> >   	select HAVE_ARCH_STACKLEAK
> > @@ -167,6 +166,7 @@ config ARM64
> >   		if $(cc-option,-fpatchable-function-entry=2)
> >   	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
> >   		if DYNAMIC_FTRACE_WITH_REGS
> > +	select HAVE_EARLY_SECTION_MEMMAP_HOLES
> >   	select HAVE_EFFICIENT_UNALIGNED_ACCESS
> >   	select HAVE_FAST_GUP
> >   	select HAVE_FTRACE_MCOUNT_RECORD
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 75ddfe671393..fcbef3eec4b2 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
> >   typedef struct page *pgtable_t;
> > -int pfn_valid(unsigned long pfn);
> >   int pfn_is_map_memory(unsigned long pfn);
> >   #include <asm/memory.h>
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index f431b38d0837..5731a11550d8 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
> >   	free_area_init(max_zone_pfns);
> >   }
> > -int pfn_valid(unsigned long pfn)
> > -{
> > -	phys_addr_t addr = PFN_PHYS(pfn);
> > -
> > -	/*
> > -	 * Ensure the upper PAGE_SHIFT bits are clear in the
> > -	 * pfn. Else it might lead to false positives when
> > -	 * some of the upper bits are set, but the lower bits
> > -	 * match a valid pfn.
> > -	 */
> > -	if (PHYS_PFN(addr) != pfn)
> > -		return 0;
> > -
> > -#ifdef CONFIG_SPARSEMEM
> > -{
> > -	struct mem_section *ms;
> > -
> > -	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> > -		return 0;
> > -
> > -	ms = __pfn_to_section(pfn);
> > -	if (!valid_section(ms))
> > -		return 0;
> > -
> > -	/*
> > -	 * ZONE_DEVICE memory does not have the memblock entries.
> > -	 * memblock_is_memory() check for ZONE_DEVICE based
> > -	 * addresses will always fail. Even the normal hotplugged
> > -	 * memory will never have MEMBLOCK_NOMAP flag set in their
> > -	 * memblock entries. Skip memblock search for all non early
> > -	 * memory sections covering all of hotplug memory including
> > -	 * both normal and ZONE_DEVICE based.
> > -	 */
> > -	if (!early_section(ms))
> > -		return pfn_section_valid(ms, pfn);
> > -}
> > -#endif
> > -	return memblock_is_memory(addr);
> > -}
> > -EXPORT_SYMBOL(pfn_valid);
> > -
> >   int pfn_is_map_memory(unsigned long pfn)
> >   {
> >   	phys_addr_t addr = PFN_PHYS(pfn);
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 961f0eeefb62..18bf71665211 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
> >    *
> >    * Return: 1 for PFNs that have memory map entries and 0 otherwise
> >    */
> > +bool memblock_is_memory(phys_addr_t addr);
> > +
> >   static inline int pfn_valid(unsigned long pfn)
> >   {
> > +	phys_addr_t addr = PFN_PHYS(pfn);
> >   	struct mem_section *ms;
> > +	/*
> > +	 * Ensure the upper PAGE_SHIFT bits are clear in the
> > +	 * pfn. Else it might lead to false positives when
> > +	 * some of the upper bits are set, but the lower bits
> > +	 * match a valid pfn.
> > +	 */
> > +	if (PHYS_PFN(addr) != pfn)
> > +		return 0;
> > +
> >   	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
> >   		return 0;
> >   	ms = __nr_to_section(pfn_to_section_nr(pfn));
> > @@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
> >   	 * Traditionally early sections always returned pfn_valid() for
> >   	 * the entire section-sized span.
> >   	 */
> > -	return early_section(ms) || pfn_section_valid(ms, pfn);
> > +	if (early_section(ms))
> > +		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
> > +			memblock_is_memory(pfn << PAGE_SHIFT) : 1;
> > +
> > +	return pfn_section_valid(ms, pfn);
> >   }
> >   #endif
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 24c045b24b95..db7128111874 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -135,6 +135,15 @@ config HAVE_FAST_GUP
> >   config ARCH_KEEP_MEMBLOCK
> >   	bool
> > +config HAVE_EARLY_SECTION_MEMMAP_HOLES
> > +	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
> > +	def_bool n
> > +	help
> > +	  Early sections on certain platforms might have some memory ranges that
> > +	  are not backed with struct page mappings. When subscribed, this option
> > +	  enables special handling for those memory ranges in certain situations
> > +	  such as pfn_valid().
> > +
> >   # Keep arch NUMA mapping infrastructure post-init.
> >   config NUMA_KEEP_MEMINFO
> >   	bool
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 3abf2c3fea7f..93f8a9c8428d 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
> >   {
> >   	return memblock_search(&memblock.memory, addr) != -1;
> >   }
> > +EXPORT_SYMBOL(memblock_is_memory);
> >   bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
> >   {
> > @@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
> >   	unsigned long start, end, prev_end = 0;
> >   	int i;
> > -	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
> > -	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> > +	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> > +		return;
> > +
> > +	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
> > +	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
> >   		return;
> >   	/*
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index 0cdbbfbc5757..8c78b6a3d888 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -309,6 +309,11 @@ struct page *pfn_to_online_page(unsigned long pfn)
> >   	 * Save some code text when online_section() +
> >   	 * pfn_section_valid() are sufficient.
> >   	 */
> > +	if (IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES)) {
> > +		if (early_section(ms) && !memblock_is_memory(PFN_PHYS(pfn)))
> > +			return NULL;
> > +	}
> > +
> >   	if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) && !pfn_valid(pfn))
> >   		return NULL;
> > 
> 
> What about doing one step at a time and switching only over to generic
> pfn_valid() in case of CONFIG_SPARSEMEM? (meaning: freeing the memmap only
> with !CONFIG_SPARSEMEM)

The "generic" pfn_valid() is only available with CONFIG_SPARSEMEM.
With FLATMEM it's wild west:

$ git grep -w "define pfn_valid" arch/*/include/asm/ | wc -l
22

This would actually mean that we still need arm64::pfn_valid() for the
FLATMEM case.

> IOW, avoiding having to adjust generic pfn_valid()/pfn_to_online_page() at
> all. Am i missing something or should that be possible?

We are back again to the question "should arm64 free its memmap". 
If the answer is no, we don't need arm64::pfn_valid() for SPARSEMEM at all.
If the answer is yes, Anshuman's patch is way better than a custom
pfn_valid().

-- 
Sincerely yours,
Mike.


From David.Laight at ACULAB.COM  Thu Apr 22 10:48:42 2021
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 22 Apr 2021 09:48:42 +0000
Subject: [PATCH tip 1/2] signal, perf: Fix siginfo_t by avoiding u64 on
 32-bit architectures
In-Reply-To: <20210422064437.3577327-1-elver@google.com>
References: <20210422064437.3577327-1-elver@google.com>
Message-ID: <d480a4f56d544fb98eb1cdd62f44ae91@AcuMS.aculab.com>

From: Marco Elver
> Sent: 22 April 2021 07:45
> 
> On some architectures, like Arm, the alignment of a structure is that of
> its largest member.

That is true everywhere.
(Apart from obscure ABI where structure have at least 4 byte alignment!)

> This means that there is no portable way to add 64-bit integers to
> siginfo_t on 32-bit architectures, because siginfo_t does not contain
> any 64-bit integers on 32-bit architectures.

Uh?

The actual problem is that adding a 64-bit aligned item to the union
forces the union to be 8 byte aligned and adds a 4 byte pad before it
(and possibly another one at the end of the structure).

> In the case of the si_perf field, word size is sufficient since there is
> no exact requirement on size, given the data it contains is user-defined
> via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
> of perf_event_attr::sig_data will therefore be truncated when copying
> into si_perf.

Is that right on BE architectures?

> Since this field is intended to disambiguate events (e.g. encoding
> relevant information if there are more events of the same type), 32 bits
> should provide enough entropy to do so on 32-bit architectures.

What is the size of the field used to supply the data?
The size of the returned item really ought to match.

Much as I hate __packed, you could add __packed to the
definition of the structure member _perf.
The compiler will remove the padding before it and will
assume it has the alignment of the previous item.

So it will never use byte accesses.

	David

> 
> For 64-bit architectures, no change is intended.
> 
> Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
> Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Reported-by: Jon Hunter <jonathanh at nvidia.com>
> Signed-off-by: Marco Elver <elver at google.com>
> ---
> 
> Note: I added static_assert()s to verify the siginfo_t layout to
> arch/arm and arch/arm64, which caught the problem. I'll send them
> separately to arm&arm64 maintainers respectively.
> ---
>  include/linux/compat.h                                | 2 +-
>  include/uapi/asm-generic/siginfo.h                    | 2 +-
>  tools/testing/selftests/perf_events/sigtrap_threads.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/compat.h b/include/linux/compat.h
> index c8821d966812..f0d2dd35d408 100644
> --- a/include/linux/compat.h
> +++ b/include/linux/compat.h
> @@ -237,7 +237,7 @@ typedef struct compat_siginfo {
>  					u32 _pkey;
>  				} _addr_pkey;
>  				/* used when si_code=TRAP_PERF */
> -				compat_u64 _perf;
> +				compat_ulong_t _perf;
>  			};
>  		} _sigfault;
> 
> diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> index d0bb9125c853..03d6f6d2c1fe 100644
> --- a/include/uapi/asm-generic/siginfo.h
> +++ b/include/uapi/asm-generic/siginfo.h
> @@ -92,7 +92,7 @@ union __sifields {
>  				__u32 _pkey;
>  			} _addr_pkey;
>  			/* used when si_code=TRAP_PERF */
> -			__u64 _perf;
> +			unsigned long _perf;
>  		};
>  	} _sigfault;
> 
> diff --git a/tools/testing/selftests/perf_events/sigtrap_threads.c
> b/tools/testing/selftests/perf_events/sigtrap_threads.c
> index 9c0fd442da60..78ddf5e11625 100644
> --- a/tools/testing/selftests/perf_events/sigtrap_threads.c
> +++ b/tools/testing/selftests/perf_events/sigtrap_threads.c
> @@ -44,7 +44,7 @@ static struct {
>  } ctx;
> 
>  /* Unique value to check si_perf is correctly set from perf_event_attr::sig_data. */
> -#define TEST_SIG_DATA(addr) (~(uint64_t)(addr))
> +#define TEST_SIG_DATA(addr) (~(unsigned long)(addr))
> 
>  static struct perf_event_attr make_event_attr(bool enabled, volatile void *addr)
>  {
> --
> 2.31.1.498.g6c1eba8ee3d-goog

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From david at redhat.com  Thu Apr 22 10:48:58 2021
From: david at redhat.com (David Hildenbrand)
Date: Thu, 22 Apr 2021 11:48:58 +0200
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <YIFFIiuy+z3WLHDi@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>
 <YIFFIiuy+z3WLHDi@kernel.org>
Message-ID: <61523566-f302-1051-9565-b1e129c6cac0@redhat.com>

On 22.04.21 11:42, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 11:03:50AM +0200, David Hildenbrand wrote:
>> On 22.04.21 09:50, Anshuman Khandual wrote:
>>> Platforms like arm and arm64 have redefined pfn_valid() because their early
>>> memory sections might have contained memmap holes after freeing parts of it
>>> during boot, which should be skipped while validating a pfn for struct page
>>> backing. This scenario on certain platforms where memmap is not continuous,
>>> could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
>>> Then the generic pfn_valid() can be improved to accommodate such platforms.
>>> This reduces overall code footprint and also improves maintainability.
>>>
>>> free_unused_memmap() and pfn_to_online_page() have been updated to include
>>> such cases. This also exports memblock_is_memory() for all drivers that use
>>> pfn_valid() but lack required visibility. After the new config is in place,
>>> drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.
>>>
>>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>>> Cc: Will Deacon <will at kernel.org>
>>> Cc: Andrew Morton <akpm at linux-foundation.org>
>>> Cc: Mike Rapoport <rppt at kernel.org>
>>> Cc: David Hildenbrand <david at redhat.com>
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Cc: linux-mm at kvack.org
>>> Suggested-by: David Hildenbrand <david at redhat.com>
>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>>> ---
>>> This patch applies on the latest mainline kernel after Mike's series
>>> regarding arm64 based pfn_valid().
>>>
>>> https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t
>>>
>>> Changes in RFC V2:
>>>
>>> - Dropped support for arm (32 bit)
>>> - Replaced memblock_is_map_memory() check with memblock_is_memory()
>>> - MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
>>> - Updated pfn_to_online_page() per David
>>> - Updated free_unused_memmap() to preserve existing semantics per Mike
>>> - Exported memblock_is_memory() instead of memblock_is_map_memory()
>>>
>>> Changes in RFC V1:
>>>
>>> - https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/
>>>
>>>    arch/arm64/Kconfig            |  2 +-
>>>    arch/arm64/include/asm/page.h |  1 -
>>>    arch/arm64/mm/init.c          | 41 -----------------------------------
>>>    include/linux/mmzone.h        | 18 ++++++++++++++-
>>>    mm/Kconfig                    |  9 ++++++++
>>>    mm/memblock.c                 |  8 +++++--
>>>    mm/memory_hotplug.c           |  5 +++++
>>>    7 files changed, 38 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index b4a9b493ce72..4cdc3570ffa9 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -144,7 +144,6 @@ config ARM64
>>>    	select HAVE_ARCH_KGDB
>>>    	select HAVE_ARCH_MMAP_RND_BITS
>>>    	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>> -	select HAVE_ARCH_PFN_VALID
>>>    	select HAVE_ARCH_PREL32_RELOCATIONS
>>>    	select HAVE_ARCH_SECCOMP_FILTER
>>>    	select HAVE_ARCH_STACKLEAK
>>> @@ -167,6 +166,7 @@ config ARM64
>>>    		if $(cc-option,-fpatchable-function-entry=2)
>>>    	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
>>>    		if DYNAMIC_FTRACE_WITH_REGS
>>> +	select HAVE_EARLY_SECTION_MEMMAP_HOLES
>>>    	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>>>    	select HAVE_FAST_GUP
>>>    	select HAVE_FTRACE_MCOUNT_RECORD
>>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>>> index 75ddfe671393..fcbef3eec4b2 100644
>>> --- a/arch/arm64/include/asm/page.h
>>> +++ b/arch/arm64/include/asm/page.h
>>> @@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
>>>    typedef struct page *pgtable_t;
>>> -int pfn_valid(unsigned long pfn);
>>>    int pfn_is_map_memory(unsigned long pfn);
>>>    #include <asm/memory.h>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index f431b38d0837..5731a11550d8 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>>>    	free_area_init(max_zone_pfns);
>>>    }
>>> -int pfn_valid(unsigned long pfn)
>>> -{
>>> -	phys_addr_t addr = PFN_PHYS(pfn);
>>> -
>>> -	/*
>>> -	 * Ensure the upper PAGE_SHIFT bits are clear in the
>>> -	 * pfn. Else it might lead to false positives when
>>> -	 * some of the upper bits are set, but the lower bits
>>> -	 * match a valid pfn.
>>> -	 */
>>> -	if (PHYS_PFN(addr) != pfn)
>>> -		return 0;
>>> -
>>> -#ifdef CONFIG_SPARSEMEM
>>> -{
>>> -	struct mem_section *ms;
>>> -
>>> -	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>>> -		return 0;
>>> -
>>> -	ms = __pfn_to_section(pfn);
>>> -	if (!valid_section(ms))
>>> -		return 0;
>>> -
>>> -	/*
>>> -	 * ZONE_DEVICE memory does not have the memblock entries.
>>> -	 * memblock_is_memory() check for ZONE_DEVICE based
>>> -	 * addresses will always fail. Even the normal hotplugged
>>> -	 * memory will never have MEMBLOCK_NOMAP flag set in their
>>> -	 * memblock entries. Skip memblock search for all non early
>>> -	 * memory sections covering all of hotplug memory including
>>> -	 * both normal and ZONE_DEVICE based.
>>> -	 */
>>> -	if (!early_section(ms))
>>> -		return pfn_section_valid(ms, pfn);
>>> -}
>>> -#endif
>>> -	return memblock_is_memory(addr);
>>> -}
>>> -EXPORT_SYMBOL(pfn_valid);
>>> -
>>>    int pfn_is_map_memory(unsigned long pfn)
>>>    {
>>>    	phys_addr_t addr = PFN_PHYS(pfn);
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index 961f0eeefb62..18bf71665211 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>>>     *
>>>     * Return: 1 for PFNs that have memory map entries and 0 otherwise
>>>     */
>>> +bool memblock_is_memory(phys_addr_t addr);
>>> +
>>>    static inline int pfn_valid(unsigned long pfn)
>>>    {
>>> +	phys_addr_t addr = PFN_PHYS(pfn);
>>>    	struct mem_section *ms;
>>> +	/*
>>> +	 * Ensure the upper PAGE_SHIFT bits are clear in the
>>> +	 * pfn. Else it might lead to false positives when
>>> +	 * some of the upper bits are set, but the lower bits
>>> +	 * match a valid pfn.
>>> +	 */
>>> +	if (PHYS_PFN(addr) != pfn)
>>> +		return 0;
>>> +
>>>    	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>>>    		return 0;
>>>    	ms = __nr_to_section(pfn_to_section_nr(pfn));
>>> @@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
>>>    	 * Traditionally early sections always returned pfn_valid() for
>>>    	 * the entire section-sized span.
>>>    	 */
>>> -	return early_section(ms) || pfn_section_valid(ms, pfn);
>>> +	if (early_section(ms))
>>> +		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
>>> +			memblock_is_memory(pfn << PAGE_SHIFT) : 1;
>>> +
>>> +	return pfn_section_valid(ms, pfn);
>>>    }
>>>    #endif
>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>> index 24c045b24b95..db7128111874 100644
>>> --- a/mm/Kconfig
>>> +++ b/mm/Kconfig
>>> @@ -135,6 +135,15 @@ config HAVE_FAST_GUP
>>>    config ARCH_KEEP_MEMBLOCK
>>>    	bool
>>> +config HAVE_EARLY_SECTION_MEMMAP_HOLES
>>> +	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
>>> +	def_bool n
>>> +	help
>>> +	  Early sections on certain platforms might have some memory ranges that
>>> +	  are not backed with struct page mappings. When subscribed, this option
>>> +	  enables special handling for those memory ranges in certain situations
>>> +	  such as pfn_valid().
>>> +
>>>    # Keep arch NUMA mapping infrastructure post-init.
>>>    config NUMA_KEEP_MEMINFO
>>>    	bool
>>> diff --git a/mm/memblock.c b/mm/memblock.c
>>> index 3abf2c3fea7f..93f8a9c8428d 100644
>>> --- a/mm/memblock.c
>>> +++ b/mm/memblock.c
>>> @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
>>>    {
>>>    	return memblock_search(&memblock.memory, addr) != -1;
>>>    }
>>> +EXPORT_SYMBOL(memblock_is_memory);
>>>    bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
>>>    {
>>> @@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
>>>    	unsigned long start, end, prev_end = 0;
>>>    	int i;
>>> -	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
>>> -	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
>>> +	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
>>> +		return;
>>> +
>>> +	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
>>> +	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
>>>    		return;
>>>    	/*
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 0cdbbfbc5757..8c78b6a3d888 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -309,6 +309,11 @@ struct page *pfn_to_online_page(unsigned long pfn)
>>>    	 * Save some code text when online_section() +
>>>    	 * pfn_section_valid() are sufficient.
>>>    	 */
>>> +	if (IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES)) {
>>> +		if (early_section(ms) && !memblock_is_memory(PFN_PHYS(pfn)))
>>> +			return NULL;
>>> +	}
>>> +
>>>    	if (IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) && !pfn_valid(pfn))
>>>    		return NULL;
>>>
>>
>> What about doing one step at a time and switching only over to generic
>> pfn_valid() in case of CONFIG_SPARSEMEM? (meaning: freeing the memmap only
>> with !CONFIG_SPARSEMEM)
> 
> The "generic" pfn_valid() is only available with CONFIG_SPARSEMEM.
> With FLATMEM it's wild west:
> 
> $ git grep -w "define pfn_valid" arch/*/include/asm/ | wc -l
> 22
> 
> This would actually mean that we still need arm64::pfn_valid() for the
> FLATMEM case.

Right, which is the case on x86 etc. as well. (I was assuming that this 
patch was missing something)

> 
>> IOW, avoiding having to adjust generic pfn_valid()/pfn_to_online_page() at
>> all. Am i missing something or should that be possible?
> 
> We are back again to the question "should arm64 free its memmap".
> If the answer is no, we don't need arm64::pfn_valid() for SPARSEMEM at all.
> If the answer is yes, Anshuman's patch is way better than a custom
> pfn_valid().

Well, I propose something in between: stop freeing with SPARSEMEM, 
continue freeing with FLATMEM.

-- 
Thanks,

David / dhildenb



From lkp at intel.com  Thu Apr 22 10:55:21 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 17:55:21 +0800
Subject: [xlnx:master 11997/12154]
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c:894:5: error: 'struct
 axienet_local' has no member named 'ptp_os_cf'
Message-ID: <202104221718.Zc1vaSxH-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   bcd80b4c331c5d55de978ab0b2f6181a8aea3434
commit: 8a885d4a28ef180a86c0228a93369903cbb8af7f [11997/12154] net: axienet: Add one step PDelay support
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/8a885d4a28ef180a86c0228a93369903cbb8af7f
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 8a885d4a28ef180a86c0228a93369903cbb8af7f
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

Note: the xlnx/master HEAD bcd80b4c331c5d55de978ab0b2f6181a8aea3434 builds fine.
      It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/err.h:5,
                    from include/linux/clk.h:12,
                    from drivers/net/ethernet/xilinx/xilinx_axienet_main.c:25:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of pointer with null pointer [-Wextra]
     169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory)
         |                                                 ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
      78 | # define unlikely(x) __builtin_expect(!!(x), 0)
         |                                          ^
   include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
     143 |  BUG_ON(!virt_addr_valid(buf));
         |  ^~~~~~
   include/linux/scatterlist.h:143:10: note: in expansion of macro 'virt_addr_valid'
     143 |  BUG_ON(!virt_addr_valid(buf));
         |          ^~~~~~~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c: In function 'axienet_rx_hwtstamp':
>> drivers/net/ethernet/xilinx/xilinx_axienet_main.c:894:5: error: 'struct axienet_local' has no member named 'ptp_os_cf'
     894 |   lp->ptp_os_cf = mul_u32_u32(sec, NSEC_PER_SEC);
         |     ^~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:895:5: error: 'struct axienet_local' has no member named 'ptp_os_cf'
     895 |   lp->ptp_os_cf += nsec;
         |     ^~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:896:5: error: 'struct axienet_local' has no member named 'ptp_os_cf'
     896 |   lp->ptp_os_cf = (lp->ptp_os_cf << 16);
         |     ^~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:896:22: error: 'struct axienet_local' has no member named 'ptp_os_cf'
     896 |   lp->ptp_os_cf = (lp->ptp_os_cf << 16);
         |                      ^~
   In file included from include/linux/string.h:20,
                    from include/linux/bitmap.h:9,
                    from include/linux/cpumask.h:12,
                    from include/linux/smp.h:13,
                    from include/linux/lockdep.h:14,
                    from include/linux/mutex.h:17,
                    from include/linux/notifier.h:14,
                    from include/linux/clk.h:14,
                    from drivers/net/ethernet/xilinx/xilinx_axienet_main.c:25:
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c: In function 'axienet_create_tsheader':
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1087:24: error: 'struct axienet_local' has no member named 'ptp_os_cf'
    1087 |     memcpy(&buf[8], &lp->ptp_os_cf, 8);
         |                        ^~
   arch/m68k/include/asm/string.h:72:45: note: in definition of macro 'memcpy'
      72 | #define memcpy(d, s, n) __builtin_memcpy(d, s, n)
         |                                             ^
   In file included from include/linux/kernel.h:15,
                    from include/linux/clk.h:13,
                    from drivers/net/ethernet/xilinx/xilinx_axienet_main.c:25:
   include/linux/typecheck.h:12:18: warning: comparison of distinct pointer types lacks a cast
      12 |  (void)(&__dummy == &__dummy2); \
         |                  ^~
   include/linux/spinlock.h:251:3: note: in expansion of macro 'typecheck'
     251 |   typecheck(unsigned long, flags); \
         |   ^~~~~~~~~
   include/linux/spinlock.h:384:2: note: in expansion of macro 'raw_spin_lock_irqsave'
     384 |  raw_spin_lock_irqsave(spinlock_check(lock), flags); \
         |  ^~~~~~~~~~~~~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1111:3: note: in expansion of macro 'spin_lock_irqsave'
    1111 |   spin_lock_irqsave(&lp->ptp_tx_lock, flags);
         |   ^~~~~~~~~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c: In function 'axienet_probe':
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:3148:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
    3148 |  bool slave = false;
         |  ^~~~
   At top level:
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1747:12: warning: 'axienet_open' defined but not used [-Wunused-function]
    1747 | static int axienet_open(struct net_device *ndev)
         |            ^~~~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_axienet_main.c:1435:12: warning: 'axienet_start_xmit' defined but not used [-Wunused-function]
    1435 | static int axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
         |            ^~~~~~~~~~~~~~~~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for NEED_MULTIPLE_NODES
   Depends on DISCONTIGMEM || NUMA
   Selected by
   - SINGLE_MEMORY_CHUNK && MMU


vim +894 drivers/net/ethernet/xilinx/xilinx_axienet_main.c

   848	
   849	/**
   850	 * axienet_rx_hwtstamp - Read rx timestamp from hw and update it to the skbuff
   851	 * @lp:		Pointer to axienet local structure
   852	 * @skb:	Pointer to the sk_buff structure
   853	 *
   854	 * Return:	None.
   855	 */
   856	static void axienet_rx_hwtstamp(struct axienet_local *lp,
   857					struct sk_buff *skb)
   858	{
   859		u32 sec = 0, nsec = 0, val;
   860		u64 time64;
   861		int err = 0;
   862		struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
   863	
   864		val = axienet_rxts_ior(lp, XAXIFIFO_TXTS_ISR);
   865		if (unlikely(!(val & XAXIFIFO_TXTS_INT_RC_MASK))) {
   866			dev_info(lp->dev, "Did't get FIFO rx interrupt %d\n", val);
   867			return;
   868		}
   869	
   870		val = axienet_rxts_ior(lp, XAXIFIFO_TXTS_RFO);
   871		if (!val)
   872			return;
   873	
   874		/* If FIFO is configured in cut through Mode we will get Rx complete
   875		 * interrupt even one byte is there in the fifo wait for the full packet
   876		 */
   877		err = readl_poll_timeout_atomic(lp->rx_ts_regs + XAXIFIFO_TXTS_RLR, val,
   878						((val & XAXIFIFO_TXTS_RXFD_MASK) >= 12),
   879						0, 1000000);
   880		if (err) {
   881			netdev_err(lp->ndev, "%s: Didn't get the full timestamp packet",
   882				   __func__);
   883			return;
   884		}
   885	
   886		nsec = axienet_rxts_ior(lp, XAXIFIFO_TXTS_RXFD);
   887		sec  = axienet_rxts_ior(lp, XAXIFIFO_TXTS_RXFD);
   888		val = axienet_rxts_ior(lp, XAXIFIFO_TXTS_RXFD);
   889	
   890		if (is_ptp_os_pdelay_req(skb, lp)) {
   891			/* Need to save PDelay resp RX time for HW 1 step
   892			 * timestamping on PDelay Response.
   893			 */
 > 894			lp->ptp_os_cf = mul_u32_u32(sec, NSEC_PER_SEC);
   895			lp->ptp_os_cf += nsec;
   896			lp->ptp_os_cf = (lp->ptp_os_cf << 16);
   897		}
   898	
   899		if (lp->tstamp_config.rx_filter == HWTSTAMP_FILTER_ALL) {
   900			time64 = sec * NS_PER_SEC + nsec;
   901			shhwtstamps->hwtstamp = ns_to_ktime(time64);
   902		}
   903	}
   904	#endif
   905	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59365 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/4230a27d/attachment-0001.gz>

From anshuman.khandual at arm.com  Thu Apr 22 10:59:10 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 22 Apr 2021 15:29:10 +0530
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <YIFFIiuy+z3WLHDi@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>
 <YIFFIiuy+z3WLHDi@kernel.org>
Message-ID: <d82ee03f-71da-e0ab-def0-306236b00e8d@arm.com>



On 4/22/21 3:12 PM, Mike Rapoport wrote:
> The "generic" pfn_valid() is only available with CONFIG_SPARSEMEM.
> With FLATMEM it's wild west:
> 
> $ git grep -w "define pfn_valid" arch/*/include/asm/ | wc -l
> 22
> 
> This would actually mean that we still need arm64::pfn_valid() for the
> FLATMEM case.

SPARSEMEM would be the only memory model going forward.

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210420093559.23168-1-catalin.marinas at arm.com/ 


From rppt at kernel.org  Thu Apr 22 11:03:58 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 13:03:58 +0300
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <61523566-f302-1051-9565-b1e129c6cac0@redhat.com>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <ce4f8045-2481-103f-f418-28cb43c7c7ff@redhat.com>
 <YIFFIiuy+z3WLHDi@kernel.org>
 <61523566-f302-1051-9565-b1e129c6cac0@redhat.com>
Message-ID: <YIFKDm0FMARKvP9B@kernel.org>

On Thu, Apr 22, 2021 at 11:48:58AM +0200, David Hildenbrand wrote:
> > 
> > > IOW, avoiding having to adjust generic pfn_valid()/pfn_to_online_page() at
> > > all. Am i missing something or should that be possible?
> > 
> > We are back again to the question "should arm64 free its memmap".
> > If the answer is no, we don't need arm64::pfn_valid() for SPARSEMEM at all.
> > If the answer is yes, Anshuman's patch is way better than a custom
> > pfn_valid().
> 
> Well, I propose something in between: stop freeing with SPARSEMEM, continue
> freeing with FLATMEM.

I'm all for it.

-- 
Sincerely yours,
Mike.


From lkp at intel.com  Thu Apr 22 11:04:15 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 18:04:15 +0800
Subject: [xlnx:master 11923/12154] drivers/mtd/spi-nor/core.c:454:2: warning:
 ISO C90 forbids mixed declarations and code
Message-ID: <202104221811.ezZkWntL-lkp@intel.com>

Hi Amit,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx master
head:   bcd80b4c331c5d55de978ab0b2f6181a8aea3434
commit: 26d248f9f56a753db263a6adde4a04f0c6265374 [11923/12154] mtd: spi-nor: Added EAR support for Zynq qspi driver
config: alpha-randconfig-r015-20210421 (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/26d248f9f56a753db263a6adde4a04f0c6265374
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 26d248f9f56a753db263a6adde4a04f0c6265374
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   drivers/mtd/spi-nor/core.c: In function 'spi_nor_write_ear':
>> drivers/mtd/spi-nor/core.c:454:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
     454 |  u32 ear;
         |  ^~~


vim +454 drivers/mtd/spi-nor/core.c

   443	
   444	/**
   445	 * spi_nor_write_ear() - Write Extended Address Register.
   446	 * @nor:	pointer to 'struct spi_nor'.
   447	 * @ear:	value to write to the Extended Address Register.
   448	 *
   449	 * Return: 0 on success, -errno otherwise.
   450	 */
   451	int spi_nor_write_ear(struct spi_nor *nor, u32 addr)
   452	{
   453		u8 code = SPINOR_OP_WREAR;;
 > 454		u32 ear;
   455		int ret;
   456		struct mtd_info *mtd = &nor->mtd;
   457	
   458		/* Wait until finished previous write command. */
   459		if (spi_nor_wait_till_ready(nor))
   460			return 1;
   461	
   462		if (mtd->size <= (0x1000000) << nor->shift)
   463			return 0;
   464	
   465		addr = addr % (u32)mtd->size;
   466		ear = addr >> 24;
   467	
   468		if (!nor->isstacked && ear == nor->curbank)
   469			return 0;
   470	
   471		if (nor->isstacked && mtd->size <= 0x2000000)
   472			return 0;
   473	
   474		if (nor->jedec_id == CFI_MFR_AMD)
   475			code = SPINOR_OP_BRWR;
   476		if (nor->jedec_id == CFI_MFR_ST ||
   477		    nor->jedec_id == CFI_MFR_MACRONIX ||
   478		    nor->jedec_id == CFI_MFR_PMC) {
   479			spi_nor_write_enable(nor);
   480			code = SPINOR_OP_WREAR;
   481		}
   482		nor->bouncebuf[0] = ear;
   483	
   484		if (nor->spimem) {
   485			struct spi_mem_op op =
   486				SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
   487					   SPI_MEM_OP_NO_ADDR,
   488					   SPI_MEM_OP_NO_DUMMY,
   489					   SPI_MEM_OP_DATA_OUT(1, nor->bouncebuf, 1));
   490	
   491			ret = spi_mem_exec_op(nor->spimem, &op);
   492		} else {
   493			ret = nor->controller_ops->write_reg(nor, code, nor->bouncebuf, 1);
   494			if (ret < 0)
   495				return ret;
   496		}
   497	
   498		nor->curbank = ear;
   499	
   500		return ret;
   501	}
   502	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 22869 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/5739ff8b/attachment-0001.gz>

From rppt at kernel.org  Thu Apr 22 11:08:06 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 13:08:06 +0300
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420093559.23168-1-catalin.marinas@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
Message-ID: <YIFLBkFiY7xzKxHS@kernel.org>

On Tue, Apr 20, 2021 at 10:35:59AM +0100, Catalin Marinas wrote:
> Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> does not seem to boot in certain configurations (guest under KVM with
> Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> pages) or 29 (64K page), there's little argument against the memory
> wasted by the mem_map array with SPARSEMEM.
> 
> Make SPARSEMEM_VMEMMAP the only available option, non-selectable, and
> remove the corresponding #ifdefs under arch/arm64/.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>

Acked-by: Mike Rapoport <rppt at linux.ibm.com>

> ---
> 
> If there are any concerns, please shout (but show numbers as well to
> back it up).
> 
>  arch/arm64/Kconfig                      | 10 +---------
>  arch/arm64/include/asm/kernel-pgtable.h |  2 +-
>  arch/arm64/include/asm/memory.h         |  4 ++--
>  arch/arm64/include/asm/sparsemem.h      |  3 ---
>  arch/arm64/mm/init.c                    |  8 ++------
>  arch/arm64/mm/mmu.c                     |  2 --
>  arch/arm64/mm/ptdump.c                  |  2 --
>  7 files changed, 6 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9b4d629f7628..01c294035928 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1040,15 +1040,7 @@ source "kernel/Kconfig.hz"
>  config ARCH_SPARSEMEM_ENABLE
>  	def_bool y
>  	select SPARSEMEM_VMEMMAP_ENABLE
> -
> -config ARCH_SPARSEMEM_DEFAULT
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -
> -config ARCH_SELECT_MEMORY_MODEL
> -	def_bool ARCH_SPARSEMEM_ENABLE
> -
> -config ARCH_FLATMEM_ENABLE
> -	def_bool !NUMA
> +	select SPARSEMEM_VMEMMAP
>  
>  config HW_PERF_EVENTS
>  	def_bool y
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index 587c504a4c8b..d44df9d62fc9 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -136,7 +136,7 @@
>   * has a direct correspondence, and needs to appear sufficiently aligned
>   * in the virtual address space.
>   */
> -#if defined(CONFIG_SPARSEMEM_VMEMMAP) && ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
> +#if ARM64_MEMSTART_SHIFT < SECTION_SIZE_BITS
>  #define ARM64_MEMSTART_ALIGN	(1UL << SECTION_SIZE_BITS)
>  #else
>  #define ARM64_MEMSTART_ALIGN	(1UL << ARM64_MEMSTART_SHIFT)
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b943879c1c24..15018dc59554 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -329,7 +329,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>   */
>  #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
>  
> -#if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL)
> +#if defined(CONFIG_DEBUG_VIRTUAL)
>  #define page_to_virt(x)	({						\
>  	__typeof__(x) __page = x;					\
>  	void *__addr = __va(page_to_phys(__page));			\
> @@ -349,7 +349,7 @@ static inline void *phys_to_virt(phys_addr_t x)
>  	u64 __addr = VMEMMAP_START + (__idx * sizeof(struct page));	\
>  	(struct page *)__addr;						\
>  })
> -#endif /* !CONFIG_SPARSEMEM_VMEMMAP || CONFIG_DEBUG_VIRTUAL */
> +#endif /* CONFIG_DEBUG_VIRTUAL */
>  
>  #define virt_addr_valid(addr)	({					\
>  	__typeof__(addr) __addr = __tag_reset(addr);			\
> diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h
> index eb4a75d720ed..4b73463423c3 100644
> --- a/arch/arm64/include/asm/sparsemem.h
> +++ b/arch/arm64/include/asm/sparsemem.h
> @@ -5,7 +5,6 @@
>  #ifndef __ASM_SPARSEMEM_H
>  #define __ASM_SPARSEMEM_H
>  
> -#ifdef CONFIG_SPARSEMEM
>  #define MAX_PHYSMEM_BITS	CONFIG_ARM64_PA_BITS
>  
>  /*
> @@ -27,6 +26,4 @@
>  #define SECTION_SIZE_BITS 27
>  #endif /* CONFIG_ARM64_64K_PAGES */
>  
> -#endif /* CONFIG_SPARSEMEM*/
> -
>  #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3685e12aba9b..a205538aa1d5 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -220,6 +220,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>  int pfn_valid(unsigned long pfn)
>  {
>  	phys_addr_t addr = PFN_PHYS(pfn);
> +	struct mem_section *ms;
>  
>  	/*
>  	 * Ensure the upper PAGE_SHIFT bits are clear in the
> @@ -230,10 +231,6 @@ int pfn_valid(unsigned long pfn)
>  	if (PHYS_PFN(addr) != pfn)
>  		return 0;
>  
> -#ifdef CONFIG_SPARSEMEM
> -{
> -	struct mem_section *ms;
> -
>  	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>  		return 0;
>  
> @@ -252,8 +249,7 @@ int pfn_valid(unsigned long pfn)
>  	 */
>  	if (!early_section(ms))
>  		return pfn_section_valid(ms, pfn);
> -}
> -#endif
> +
>  	return memblock_is_map_memory(addr);
>  }
>  EXPORT_SYMBOL(pfn_valid);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index fac957ff5187..af0ebcad3e1f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1113,7 +1113,6 @@ static void free_empty_tables(unsigned long addr, unsigned long end,
>  }
>  #endif
>  
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>  #if !ARM64_SWAPPER_USES_SECTION_MAPS
>  int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>  		struct vmem_altmap *altmap)
> @@ -1177,7 +1176,6 @@ void vmemmap_free(unsigned long start, unsigned long end,
>  	free_empty_tables(start, end, VMEMMAP_START, VMEMMAP_END);
>  #endif
>  }
> -#endif	/* CONFIG_SPARSEMEM_VMEMMAP */
>  
>  static inline pud_t *fixmap_pud(unsigned long addr)
>  {
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index a50e92ea1878..a1937dfff31c 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -51,10 +51,8 @@ static struct addr_marker address_markers[] = {
>  	{ FIXADDR_TOP,			"Fixmap end" },
>  	{ PCI_IO_START,			"PCI I/O start" },
>  	{ PCI_IO_END,			"PCI I/O end" },
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>  	{ VMEMMAP_START,		"vmemmap start" },
>  	{ VMEMMAP_START + VMEMMAP_SIZE,	"vmemmap end" },
> -#endif
>  	{ -1,				NULL },
>  };
>  
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Sincerely yours,
Mike.


From will at kernel.org  Thu Apr 22 11:12:37 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:12:37 +0100
Subject: [PATCH] KVM: arm64: build perf support only when enabled
In-Reply-To: <87y2dbpwqn.wl-maz@kernel.org>
References: <20210421134922.3309033-1-arnd@kernel.org>
 <87y2dbpwqn.wl-maz@kernel.org>
Message-ID: <20210422101236.GB1039@willie-the-truck>

On Wed, Apr 21, 2021 at 02:56:16PM +0100, Marc Zyngier wrote:
> On Wed, 21 Apr 2021 14:49:01 +0100,
> Arnd Bergmann <arnd at kernel.org> wrote:
> > 
> > From: Arnd Bergmann <arnd at arndb.de>
> > 
> > The perf_num_counters() function is only defined when CONFIG_PERF_EVENTS
> > is enabled:
> > 
> > arch/arm64/kvm/perf.c: In function 'kvm_perf_init':
> > arch/arm64/kvm/perf.c:58:43: error: implicit declaration of function 'perf_num_counters'; did you mean 'dec_mm_counter'? [-Werror=implicit-function-declaration]
> >    58 |         if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0
> >       |                                           ^~~~~~~~~~~~~~~~~
> > 
> > Use conditional compilation to disable this feature entirely when
> > CONFIG_PERF_EVENTS is disabled in the host.
> > 
> > Fixes: 6b5b368fccd7 ("KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key")
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> > Not sure if this is the correct symbol to check for, but this is
> > one way to avoid the build failure.
> 
> I think a better way is to get rid of perf_num_counters() entirely,
> see [1]. If someone acks the second and last patches, I'll even take
> the whole series in (nudge nudge...).

Sorry, behind at the moment! Will get to it today.

Will


From cristian.marussi at arm.com  Thu Apr 22 11:17:09 2021
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Thu, 22 Apr 2021 11:17:09 +0100
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
In-Reply-To: <YIE7pdqV/h10tEAK@mwanda>
References: <YIE7pdqV/h10tEAK@mwanda>
Message-ID: <20210422101709.GF43717@e120937-lin>

Hi,

On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote:
> How type promotion works in ternary expressions is a bit tricky.
> The problem is that scpi_clk_get_val() returns longs, "ret" is a int
> which holds a negative error code, and le32_to_cpu() is an unsigned int.
> We want the negative error code to be cast to a negative long.  But
> because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
> becomes a high positive and then it is promoted to long and it is still
> a high positive value.
> 
> Fix this by getting rid of the ternary.

I wonder how/if the callers up in the stack check/expect ever effectively for a
2-complement negative value inside the returned unsigned long...given that this
plugs finally into CLK framework struct clk_ops.recalc_rate via clk-scpi.c which
also expects unsigned long....but that's another story.

FWIW regarding this patch:

Reviewed-by: Cristian Marussi <cristian.marussi at arm.com>

Thanks

Cristian

> 
> Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
> Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
> ---
>  drivers/firmware/arm_scpi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index d0dee37ad522..3bf61854121d 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
>  
>  	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
>  				sizeof(le_clk_id), &rate, sizeof(rate));
> +	if (ret)
> +		return ret;
>  
> -	return ret ? ret : le32_to_cpu(rate);
> +	return le32_to_cpu(rate);
>  }
>  
>  static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
> -- 
> 2.30.2
> 


From elver at google.com  Thu Apr 22 11:17:20 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 12:17:20 +0200
Subject: [PATCH tip 1/2] signal, perf: Fix siginfo_t by avoiding u64 on
 32-bit architectures
In-Reply-To: <d480a4f56d544fb98eb1cdd62f44ae91@AcuMS.aculab.com>
References: <20210422064437.3577327-1-elver@google.com>
 <d480a4f56d544fb98eb1cdd62f44ae91@AcuMS.aculab.com>
Message-ID: <CANpmjNNjkQdziFZDkPy5EnwCF+VyBWKXEwCDgNpxHGZd+BLQag@mail.gmail.com>

On Thu, 22 Apr 2021 at 11:48, David Laight <David.Laight at aculab.com> wrote:
>
> From: Marco Elver
> > Sent: 22 April 2021 07:45
> >
> > On some architectures, like Arm, the alignment of a structure is that of
> > its largest member.
>
> That is true everywhere.
> (Apart from obscure ABI where structure have at least 4 byte alignment!)

For instance, x86 didn't complain, nor did m68k. Both of them have
compile-time checks for the layout (I'm adding those for Arm
elsewhere).

> > This means that there is no portable way to add 64-bit integers to
> > siginfo_t on 32-bit architectures, because siginfo_t does not contain
> > any 64-bit integers on 32-bit architectures.
>
> Uh?
>
> The actual problem is that adding a 64-bit aligned item to the union
> forces the union to be 8 byte aligned and adds a 4 byte pad before it
> (and possibly another one at the end of the structure).

Yes, which means there's no portable way (without starting to add
attributes that are outside the C std) to add 64-bit integers to
siginfo_t without breaking the ABI on 32-bit architectures.

> > In the case of the si_perf field, word size is sufficient since there is
> > no exact requirement on size, given the data it contains is user-defined
> > via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
> > of perf_event_attr::sig_data will therefore be truncated when copying
> > into si_perf.
>
> Is that right on BE architectures?

We effectively do

  u64 sig_data = ...;
  unsigned long si_perf = sig_data;

Since the user decides what to place into perf_event_attr::sig_data,
whatever ends up in si_perf is fully controllable by the user, who
knows which arch they're on. So I do not think this is a problem.

> > Since this field is intended to disambiguate events (e.g. encoding
> > relevant information if there are more events of the same type), 32 bits
> > should provide enough entropy to do so on 32-bit architectures.
>
> What is the size of the field used to supply the data?
> The size of the returned item really ought to match.

It's u64, but because perf_event_attr wants fixed size fields, this
can't change.

> Much as I hate __packed, you could add __packed to the
> definition of the structure member _perf.
> The compiler will remove the padding before it and will
> assume it has the alignment of the previous item.
>
> So it will never use byte accesses.

Sure __packed works for Arm. But I think there's no precedent using
this on siginfo_t, possibly for good reasons? I simply can't find
evidence that this is portable on *all* architectures and for *all*
possible definitions of siginfo_t, including those that live in things
like glibc.

Can we confirm that __packed is fine to add to siginfo_t on *all*
architectures for *all* possible definitions of siginfo_t? I currently
can't. And given it's outside the scope of the C standard (as of C11
we got _Alignas, but that doesn't help I think), I'd vote to not
venture too far for code that should be portable especially things as
important as siginfo_t, and has definitions *outside* the kernel (I
know we do lots of non-standard things, but others might not).

Thanks,
-- Marco

>         David
>
> >
> > For 64-bit architectures, no change is intended.
> >
> > Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
> > Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > Reported-by: Jon Hunter <jonathanh at nvidia.com>
> > Signed-off-by: Marco Elver <elver at google.com>
> > ---
> >
> > Note: I added static_assert()s to verify the siginfo_t layout to
> > arch/arm and arch/arm64, which caught the problem. I'll send them
> > separately to arm&arm64 maintainers respectively.
> > ---
> >  include/linux/compat.h                                | 2 +-
> >  include/uapi/asm-generic/siginfo.h                    | 2 +-
> >  tools/testing/selftests/perf_events/sigtrap_threads.c | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/compat.h b/include/linux/compat.h
> > index c8821d966812..f0d2dd35d408 100644
> > --- a/include/linux/compat.h
> > +++ b/include/linux/compat.h
> > @@ -237,7 +237,7 @@ typedef struct compat_siginfo {
> >                                       u32 _pkey;
> >                               } _addr_pkey;
> >                               /* used when si_code=TRAP_PERF */
> > -                             compat_u64 _perf;
> > +                             compat_ulong_t _perf;
> >                       };
> >               } _sigfault;
> >
> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
> > index d0bb9125c853..03d6f6d2c1fe 100644
> > --- a/include/uapi/asm-generic/siginfo.h
> > +++ b/include/uapi/asm-generic/siginfo.h
> > @@ -92,7 +92,7 @@ union __sifields {
> >                               __u32 _pkey;
> >                       } _addr_pkey;
> >                       /* used when si_code=TRAP_PERF */
> > -                     __u64 _perf;
> > +                     unsigned long _perf;
> >               };
> >       } _sigfault;
> >
> > diff --git a/tools/testing/selftests/perf_events/sigtrap_threads.c
> > b/tools/testing/selftests/perf_events/sigtrap_threads.c
> > index 9c0fd442da60..78ddf5e11625 100644
> > --- a/tools/testing/selftests/perf_events/sigtrap_threads.c
> > +++ b/tools/testing/selftests/perf_events/sigtrap_threads.c
> > @@ -44,7 +44,7 @@ static struct {
> >  } ctx;
> >
> >  /* Unique value to check si_perf is correctly set from perf_event_attr::sig_data. */
> > -#define TEST_SIG_DATA(addr) (~(uint64_t)(addr))
> > +#define TEST_SIG_DATA(addr) (~(unsigned long)(addr))
> >
> >  static struct perf_event_attr make_event_attr(bool enabled, volatile void *addr)
> >  {
> > --
> > 2.31.1.498.g6c1eba8ee3d-goog
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)


From l.stelmach at samsung.com  Thu Apr 22 11:17:05 2021
From: l.stelmach at samsung.com (=?UTF-8?q?=C5=81ukasz=20Stelmach?=)
Date: Thu, 22 Apr 2021 12:17:05 +0200
Subject: [PATCH] hwrng: exynos - Fix runtime PM imbalance on error
References: <CGME20210422101724eucas1p13e2f002b63fe94ef2aa5268383f3a207@eucas1p1.samsung.com>
Message-ID: <20210422101705.15617-1-l.stelmach@samsung.com>

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Change-Id: I028915fbee9e4a050a1313119872d6043696632d
Signed-off-by: ?ukasz Stelmach <l.stelmach at samsung.com>
---
 drivers/char/hw_random/exynos-trng.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8dd2d..9f455d952e87 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -142,13 +142,13 @@ static int exynos_trng_probe(struct platform_device *pdev)
 	if (IS_ERR(trng->clk)) {
 		ret = PTR_ERR(trng->clk);
 		dev_err(&pdev->dev, "Could not get clock.\n");
-		goto err_clock;
+		goto err_pm_get;
 	}
 
 	ret = clk_prepare_enable(trng->clk);
 	if (ret) {
 		dev_err(&pdev->dev, "Could not enable the clk.\n");
-		goto err_clock;
+		goto err_pm_get;
 	}
 
 	ret = devm_hwrng_register(&pdev->dev, &trng->rng);
@@ -164,10 +164,8 @@ static int exynos_trng_probe(struct platform_device *pdev)
 err_register:
 	clk_disable_unprepare(trng->clk);
 
-err_clock:
-	pm_runtime_put_sync(&pdev->dev);
-
 err_pm_get:
+	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	return ret;
-- 
2.26.2



From arnaud.pouliquen at foss.st.com  Thu Apr 22 11:22:23 2021
From: arnaud.pouliquen at foss.st.com (Arnaud POULIQUEN)
Date: Thu, 22 Apr 2021 12:22:23 +0200
Subject: [PATCH] remoteproc: stm32: fix phys_addr_t format string
In-Reply-To: <20210421140053.3727528-1-arnd@kernel.org>
References: <20210421140053.3727528-1-arnd@kernel.org>
Message-ID: <5c8724b8-ec88-de4d-26b9-b95620bff3d9@foss.st.com>

Hello Arnd,

On 4/21/21 4:00 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> A phys_addr_t may be wider than an int or pointer:
> 
> drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_da_to_pa':
> drivers/remoteproc/stm32_rproc.c:583:30: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'phys_addr_t' {aka 'long long unsigned int'} [-Werror=format=]
>   583 |                 dev_dbg(dev, "da %llx to pa %#x\n", da, *pa);
> 
> Print it by reference using the special %pap format string.
> 
> Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops")
> igned-off-by: Arnd Bergmann <arnd at arndb.de>

It seems that the 'S' has disappeared during the copy/past :)
It's strange that no bot has made a report...

Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen at foss.st.com>

Thanks for the fix!
Arnaud

> ---
>  drivers/remoteproc/stm32_rproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
> index 7353f9e7e7af..32595c950569 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -580,7 +580,7 @@ static int stm32_rproc_da_to_pa(struct rproc *rproc,
>  			continue;
>  
>  		*pa = da - p_mem->dev_addr + p_mem->bus_addr;
> -		dev_dbg(dev, "da %llx to pa %#x\n", da, *pa);
> +		dev_dbg(dev, "da %llx to pa %pap\n", da, pa);
>  
>  		return 0;
>  	}
> 


From will at kernel.org  Thu Apr 22 11:35:08 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:35:08 +0100
Subject: [PATCH] arm64: Show three registers per line
In-Reply-To: <20210420172245.3679077-1-willy@infradead.org>
References: <20210420172245.3679077-1-willy@infradead.org>
Message-ID: <20210422103508.GA1442@willie-the-truck>

On Tue, Apr 20, 2021 at 06:22:45PM +0100, Matthew Wilcox (Oracle) wrote:
> Displaying two registers per line takes 15 lines.  That improves to just
> 10 lines if we display three registers per line, which reduces the amount
> of information lost when oopses are cut off.  It stays within 80 columns
> and matches x86-64.
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy at infradead.org>
> ---
>  arch/arm64/kernel/process.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Thu Apr 22 11:36:03 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:36:03 +0100
Subject: [PATCH v3] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210420174427.230228-1-ndesaulniers@google.com>
References: <20210420174427.230228-1-ndesaulniers@google.com>
Message-ID: <20210422103603.GB1442@willie-the-truck>

On Tue, Apr 20, 2021 at 10:44:25AM -0700, Nick Desaulniers wrote:
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this. We no longer need --prefix,
> --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> remove those too.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/
> 
> Suggested-by: Nathan Chancellor <nathan at kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers at google.com>
> Reviewed-by: Nathan Chancellor <nathan at kernel.org>
> Reviewed-by: Vincenzo Frascino <vincenzo.frascino at arm.com>
> ---

Acked-by: Will Deacon <will at kernel.org>

Will


From l.stelmach at samsung.com  Thu Apr 22 11:41:41 2021
From: l.stelmach at samsung.com (=?UTF-8?q?=C5=81ukasz=20Stelmach?=)
Date: Thu, 22 Apr 2021 12:41:41 +0200
Subject: [PATCH v2] hwrng: exynos - Fix runtime PM imbalance on error
References: <CGME20210422104145eucas1p17f46c95b72f3568761a9f7911bf072e1@eucas1p1.samsung.com>
Message-ID: <20210422104141.17668-1-l.stelmach@samsung.com>

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: ?ukasz Stelmach <l.stelmach at samsung.com>
---
Changes in v2:
  - removed Change-Id from the commit message

 drivers/char/hw_random/exynos-trng.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8dd2d..9f455d952e87 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -142,13 +142,13 @@ static int exynos_trng_probe(struct platform_device *pdev)
 	if (IS_ERR(trng->clk)) {
 		ret = PTR_ERR(trng->clk);
 		dev_err(&pdev->dev, "Could not get clock.\n");
-		goto err_clock;
+		goto err_pm_get;
 	}
 
 	ret = clk_prepare_enable(trng->clk);
 	if (ret) {
 		dev_err(&pdev->dev, "Could not enable the clk.\n");
-		goto err_clock;
+		goto err_pm_get;
 	}
 
 	ret = devm_hwrng_register(&pdev->dev, &trng->rng);
@@ -164,10 +164,8 @@ static int exynos_trng_probe(struct platform_device *pdev)
 err_register:
 	clk_disable_unprepare(trng->clk);
 
-err_clock:
-	pm_runtime_put_sync(&pdev->dev);
-
 err_pm_get:
+	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	return ret;
-- 
2.26.2



From will at kernel.org  Thu Apr 22 11:43:27 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:43:27 +0100
Subject: [PATCH 1/5] KVM: arm64: Divorce the perf code from oprofile
 helpers
In-Reply-To: <20210414134409.1266357-2-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-2-maz@kernel.org>
Message-ID: <20210422104327.GC1442@willie-the-truck>

On Wed, Apr 14, 2021 at 02:44:05PM +0100, Marc Zyngier wrote:
> KVM/arm64 is the sole user of perf_num_counters(), and really
> could do without it. Stop using the obsolete API by relying on
> the existing probing code.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm64/kvm/perf.c     | 7 +------
>  arch/arm64/kvm/pmu-emul.c | 2 +-
>  include/kvm/arm_pmu.h     | 4 ++++
>  3 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/kvm/perf.c b/arch/arm64/kvm/perf.c
> index 739164324afe..b8b398670ef2 100644
> --- a/arch/arm64/kvm/perf.c
> +++ b/arch/arm64/kvm/perf.c
> @@ -50,12 +50,7 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
>  
>  int kvm_perf_init(void)
>  {
> -	/*
> -	 * Check if HW_PERF_EVENTS are supported by checking the number of
> -	 * hardware performance counters. This could ensure the presence of
> -	 * a physical PMU and CONFIG_PERF_EVENT is selected.
> -	 */
> -	if (IS_ENABLED(CONFIG_ARM_PMU) && perf_num_counters() > 0)
> +	if (kvm_pmu_probe_pmuver() != 0xf)

Took me a while to figure out that this returns 0xf if the hardware has a
PMUVer of 0x0, so it's all good:

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Thu Apr 22 11:45:46 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:45:46 +0100
Subject: [PATCH 2/5] arm64: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-3-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-3-maz@kernel.org>
Message-ID: <20210422104545.GD1442@willie-the-truck>

On Wed, Apr 14, 2021 at 02:44:06PM +0100, Marc Zyngier wrote:
> perf_pmu_name() and perf_num_counters() are now unused. Drop them.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  drivers/perf/arm_pmu.c | 30 ------------------------------
>  1 file changed, 30 deletions(-)

Nice! This was some of the first code I ever wrote in the kernel but I can't
say I miss it:

Acked-by: Will Deacon <will at kernel.org>

Will


From krzysztof.kozlowski at canonical.com  Thu Apr 22 11:46:42 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 22 Apr 2021 12:46:42 +0200
Subject: [PATCH v2] hwrng: exynos - Fix runtime PM imbalance on error
In-Reply-To: <20210422104141.17668-1-l.stelmach@samsung.com>
References: <CGME20210422104145eucas1p17f46c95b72f3568761a9f7911bf072e1@eucas1p1.samsung.com>
 <20210422104141.17668-1-l.stelmach@samsung.com>
Message-ID: <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com>

On 22/04/2021 12:41, ?ukasz Stelmach wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.

It's exactly the same as Dinghao's patch:
https://lore.kernel.org/linux-samsung-soc/20200522011659.26727-1-dinghao.liu at zju.edu.cn/
which you reviewed. It has even the same commit msg
(although it's difficult to be creative here).

I think it's better to resend his patch instead.



Best regards,
Krzysztof


From will at kernel.org  Thu Apr 22 11:47:00 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 11:47:00 +0100
Subject: [PATCH 5/5] perf: Get rid of oprofile leftovers
In-Reply-To: <20210414134409.1266357-6-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
 <20210414134409.1266357-6-maz@kernel.org>
Message-ID: <20210422104700.GE1442@willie-the-truck>

On Wed, Apr 14, 2021 at 02:44:09PM +0100, Marc Zyngier wrote:
> perf_pmu_name() and perf_num_counters() are unused. Drop them.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  include/linux/perf_event.h | 2 --
>  kernel/events/core.c       | 5 -----
>  2 files changed, 7 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From graeme at nuviainc.com  Thu Apr 22 11:49:54 2021
From: graeme at nuviainc.com (Graeme Gregory)
Date: Thu, 22 Apr 2021 11:49:54 +0100
Subject: [PATCH v2 2/3] drivers: char: ipmi: Add Aspeed SSIF BMC driver
In-Reply-To: <20210330141029.20412-3-quan@os.amperecomputing.com>
References: <20210330141029.20412-1-quan@os.amperecomputing.com>
 <20210330141029.20412-3-quan@os.amperecomputing.com>
Message-ID: <20210422104954.GB13153@ggregory-ubuntuvm>

On Tue, Mar 30, 2021 at 09:10:28PM +0700, Quan Nguyen wrote:
> The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
> in-band IPMI communication with their host in management (BMC) side.
> 
> This commits adds support specifically for Aspeed AST2500 which commonly
> used as Board Management Controllers.
> 
> Signed-off-by: Quan Nguyen <quan at os.amperecomputing.com>
> ---
>  drivers/char/ipmi/Kconfig           |  22 +
>  drivers/char/ipmi/Makefile          |   2 +
>  drivers/char/ipmi/ssif_bmc.c        | 645 ++++++++++++++++++++++++++++
>  drivers/char/ipmi/ssif_bmc.h        |  92 ++++
>  drivers/char/ipmi/ssif_bmc_aspeed.c | 132 ++++++
>  5 files changed, 893 insertions(+)
>  create mode 100644 drivers/char/ipmi/ssif_bmc.c
>  create mode 100644 drivers/char/ipmi/ssif_bmc.h
>  create mode 100644 drivers/char/ipmi/ssif_bmc_aspeed.c
> 
> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
> index 07847d9a459a..45be57023577 100644
> --- a/drivers/char/ipmi/Kconfig
> +++ b/drivers/char/ipmi/Kconfig
> @@ -133,6 +133,28 @@ config ASPEED_BT_IPMI_BMC
>  	  found on Aspeed SOCs (AST2400 and AST2500). The driver
>  	  implements the BMC side of the BT interface.
>  
> +config SSIF_IPMI_BMC
> +	tristate "SSIF IPMI BMC driver"
> +	select I2C
> +	select I2C_SLAVE
> +	help
> +	  This enables the IPMI SMBus system interface (SSIF) at the
> +	  management (BMC) side.
> +
> +	  The driver implements the BMC side of the SMBus system
> +	  interface (SSIF).
> +
> +config ASPEED_SSIF_IPMI_BMC
> +	depends on ARCH_ASPEED || COMPILE_TEST
> +	select SSIF_IPMI_BMC
> +	tristate "Aspeed SSIF IPMI BMC driver"
> +	help
> +	  Provides a driver for the SSIF IPMI interface found on
> +	  Aspeed AST2500 SoC.
> +
> +	  The driver implements the BMC side of the SMBus system
> +	  interface (SSIF), specific for Aspeed AST2500 SoC.
> +
>  config IPMB_DEVICE_INTERFACE
>  	tristate 'IPMB Interface handler'
>  	depends on I2C
> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
> index 0822adc2ec41..05b993f7335b 100644
> --- a/drivers/char/ipmi/Makefile
> +++ b/drivers/char/ipmi/Makefile
> @@ -27,3 +27,5 @@ obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>  obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
>  obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
>  obj-$(CONFIG_IPMB_DEVICE_INTERFACE) += ipmb_dev_int.o
> +obj-$(CONFIG_SSIF_IPMI_BMC) += ssif_bmc.o
> +obj-$(CONFIG_ASPEED_SSIF_IPMI_BMC) += ssif_bmc_aspeed.o
> diff --git a/drivers/char/ipmi/ssif_bmc.c b/drivers/char/ipmi/ssif_bmc.c
> new file mode 100644
> index 000000000000..ae6e8750c795
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc.c
> @@ -0,0 +1,645 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The driver for BMC side of SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/poll.h>
> +#include <linux/sched.h>
> +#include <linux/mutex.h>
> +#include <linux/spinlock.h>
> +
> +#include "ssif_bmc.h"
> +
> +/*
> + * Call in WRITE context
> + */
> +static int send_ssif_bmc_response(struct ssif_bmc_ctx *ssif_bmc, bool non_blocking)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	if (!non_blocking) {
> +retry:
> +		ret = wait_event_interruptible(ssif_bmc->wait_queue,
> +					       !ssif_bmc->response_in_progress);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (ssif_bmc->response_in_progress) {
> +		spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +		if (non_blocking)
> +			return -EAGAIN;
> +
> +		goto retry;
> +	}
> +
> +	/*
> +	 * Check the response data length from userspace to determine the type
> +	 * of the response message whether it is single-part or multi-part.
> +	 */
> +	ssif_bmc->is_singlepart_read =
> +		(ssif_msg_len(&ssif_bmc->response) <= (MAX_PAYLOAD_PER_TRANSACTION + 1)) ?
> +		true : false; /* 1: byte of length */
> +
> +	ssif_bmc->response_in_progress = true;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	return 0;
> +}
> +
> +/*
> + * Call in READ context
> + */
> +static int receive_ssif_bmc_request(struct ssif_bmc_ctx *ssif_bmc, bool non_blocking)
> +{
> +	unsigned long flags;
> +	int ret;
> +
> +	if (!non_blocking) {
> +retry:
> +		ret = wait_event_interruptible(ssif_bmc->wait_queue,
> +					       ssif_bmc->request_available);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (!ssif_bmc->request_available) {
> +		spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +		if (non_blocking)
> +			return -EAGAIN;
> +		goto retry;
> +	}
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	return 0;
> +}
> +
> +/* Handle SSIF message that will be sent to user */
> +static ssize_t ssif_bmc_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	struct ssif_msg msg;
> +	unsigned long flags;
> +	ssize_t ret;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);
> +
> +	ret = receive_ssif_bmc_request(ssif_bmc, file->f_flags & O_NONBLOCK);
> +	if (ret < 0)
> +		goto out;
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	count = min_t(ssize_t, count, ssif_msg_len(&ssif_bmc->request));
> +	memcpy(&msg, &ssif_bmc->request, count);
> +	ssif_bmc->request_available = false;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	ret = copy_to_user(buf, &msg, count);
> +out:
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +
> +	return (ret < 0) ? ret : count;
> +}
> +
> +/* Handle SSIF message that is written by user */
> +static ssize_t ssif_bmc_write(struct file *file, const char __user *buf, size_t count,
> +			      loff_t *ppos)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	struct ssif_msg msg;
> +	unsigned long flags;
> +	ssize_t ret;
> +
> +	if (count > sizeof(struct ssif_msg))
> +		return -EINVAL;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);
> +
> +	ret = copy_from_user(&msg, buf, count);
> +	if (ret)
> +		goto out;
> +
> +	spin_lock_irqsave(&ssif_bmc->lock, flags);
> +	if (count >= ssif_msg_len(&ssif_bmc->response))
> +		memcpy(&ssif_bmc->response, &msg, count);
> +	else
> +		ret = -EINVAL;
> +	spin_unlock_irqrestore(&ssif_bmc->lock, flags);
> +
> +	if (ret)
> +		goto out;
> +
> +	ret = send_ssif_bmc_response(ssif_bmc, file->f_flags & O_NONBLOCK);
> +	if (!ret && ssif_bmc->set_ssif_bmc_status)
> +		ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_READY);
> +out:
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +
> +	return (ret < 0) ? ret : count;
> +}
> +
> +static long ssif_bmc_ioctl(struct file *file, unsigned int cmd, unsigned long param)
> +{
> +	return 0;
> +}
> +
> +static unsigned int ssif_bmc_poll(struct file *file, poll_table *wait)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = to_ssif_bmc(file);
> +	unsigned int mask = 0;
> +
> +	mutex_lock(&ssif_bmc->file_mutex);
> +	poll_wait(file, &ssif_bmc->wait_queue, wait);
> +
> +	/*
> +	 * The request message is now available so userspace application can
> +	 * get the request
> +	 */
> +	if (ssif_bmc->request_available)
> +		mask |= POLLIN;
> +
> +	mutex_unlock(&ssif_bmc->file_mutex);
> +	return mask;
> +}
> +
> +/*
> + * System calls to device interface for user apps
> + */
> +static const struct file_operations ssif_bmc_fops = {
> +	.owner		= THIS_MODULE,
> +	.read		= ssif_bmc_read,
> +	.write		= ssif_bmc_write,
> +	.poll		= ssif_bmc_poll,
> +	.unlocked_ioctl	= ssif_bmc_ioctl,
> +};
> +
> +/* Called with ssif_bmc->lock held. */
> +static int handle_request(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	if (ssif_bmc->set_ssif_bmc_status)
> +		ssif_bmc->set_ssif_bmc_status(ssif_bmc, SSIF_BMC_BUSY);
> +
> +	/* Request message is available to process */
> +	ssif_bmc->request_available = true;
> +	/*
> +	 * This is the new READ request.
> +	 * Clear the response buffer of the previous transaction
> +	 */
> +	memset(&ssif_bmc->response, 0, sizeof(struct ssif_msg));
> +	wake_up_all(&ssif_bmc->wait_queue);
> +	return 0;
> +}
> +
> +/* Called with ssif_bmc->lock held. */
> +static int complete_response(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	/* Invalidate response in buffer to denote it having been sent. */
> +	ssif_bmc->response.len = 0;
> +	ssif_bmc->response_in_progress = false;
> +	ssif_bmc->nbytes_processed = 0;
> +	ssif_bmc->remain_len = 0;
> +	memset(&ssif_bmc->response_buf, 0, MAX_PAYLOAD_PER_TRANSACTION);
> +	wake_up_all(&ssif_bmc->wait_queue);
> +	return 0;
> +}
> +
> +static void set_multipart_response_buffer(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 response_len = 0;
> +	int idx = 0;
> +	u8 data_len;
> +
> +	data_len = ssif_bmc->response.len;
> +	switch (ssif_bmc->smbus_cmd) {
> +	case SSIF_IPMI_MULTIPART_READ_START:
> +		/*
> +		 * Read Start length is 32 bytes.
> +		 * Read Start transfer first 30 bytes of IPMI response
> +		 * and 2 special code 0x00, 0x01.
> +		 */
> +		*val = MAX_PAYLOAD_PER_TRANSACTION;
> +		ssif_bmc->remain_len = data_len - MAX_IPMI_DATA_PER_START_TRANSACTION;
> +		ssif_bmc->block_num = 0;
> +
> +		ssif_bmc->response_buf[idx++] = 0x00; /* Start Flag */
> +		ssif_bmc->response_buf[idx++] = 0x01; /* Start Flag */
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.netfn_lun;
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.cmd;
> +		ssif_bmc->response_buf[idx++] = ssif_bmc->response.payload[0];
> +
> +		response_len = MAX_PAYLOAD_PER_TRANSACTION - idx;
> +
> +		memcpy(&ssif_bmc->response_buf[idx], &ssif_bmc->response.payload[1],
> +		       response_len);
> +		break;
> +
> +	case SSIF_IPMI_MULTIPART_READ_MIDDLE:
> +		/*
> +		 * IPMI READ Middle or READ End messages can carry up to 31 bytes
> +		 * IPMI data plus block number byte.
> +		 */
> +		if (ssif_bmc->remain_len < MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION) {
> +			/*
> +			 * This is READ End message
> +			 *  Return length is the remaining response data length
> +			 *  plus block number
> +			 *  Block number 0xFF is to indicate this is last message
> +			 *
> +			 * Return length is: remain response plus block number
> +			 */
> +			*val = ssif_bmc->remain_len + 1;
> +			ssif_bmc->block_num = 0xFF;
> +			ssif_bmc->response_buf[idx++] = ssif_bmc->block_num;
> +			response_len = ssif_bmc->remain_len;
> +		} else {
> +			/*
> +			 * This is READ Middle message
> +			 *  Response length is the maximum SMBUS transfer length
> +			 *  Block number byte is incremented
> +			 * Return length is maximum SMBUS transfer length
> +			 */
> +			*val = MAX_PAYLOAD_PER_TRANSACTION;
> +			ssif_bmc->remain_len -= MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION;
> +			response_len = MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION;
> +			ssif_bmc->response_buf[idx++] = ssif_bmc->block_num;
> +			ssif_bmc->block_num++;
> +		}
> +
> +		memcpy(&ssif_bmc->response_buf[idx],
> +		       ssif_bmc->response.payload + 1 + ssif_bmc->nbytes_processed,
> +		       response_len);
> +		break;
> +
> +	default:
> +		/* Do not expect to go to this case */
> +		pr_err("Error: Unexpected SMBus command received 0x%x\n", ssif_bmc->smbus_cmd);
> +		break;
> +	}
> +
> +	ssif_bmc->nbytes_processed += response_len;
> +}
> +
> +static void set_singlepart_response_buffer(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf = (u8 *)&ssif_bmc->response;
> +
> +	/*
> +	 * Do not expect the IPMI response has data length 0.
> +	 * With some I2C SMBus controllers (Aspeed I2C), return 0 for
> +	 * the SMBus Read Request callback might cause bad state for
> +	 * the bus. So return 1 byte length so that master will
> +	 * resend the Read Request because the length of response is
> +	 * less than a normal IPMI response.
> +	 *
> +	 * Otherwise, return the length of IPMI response
> +	 */
> +	*val = (buf[ssif_bmc->msg_idx]) ? buf[ssif_bmc->msg_idx] : 0x1;
> +}
> +
> +/* Process the IPMI response that will be read by master */
> +static void handle_read_processed(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf;
> +	u8 pec_len, addr, len;
> +	u8 pec = 0;
> +
> +	pec_len = ssif_bmc->pec_support ? 1 : 0;
> +	/* PEC - Start Read Address */
> +	addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +	pec = i2c_smbus_pec(pec, &addr, 1);
> +	/* PEC - SSIF Command */
> +	pec = i2c_smbus_pec(pec, &ssif_bmc->smbus_cmd, 1);
> +	/* PEC - Restart Write Address */
> +	addr = addr | 0x01;
> +	pec = i2c_smbus_pec(pec, &addr, 1);
> +
> +	if (ssif_bmc->is_singlepart_read) {
> +		/* Single-part Read processing */
> +		buf = (u8 *)&ssif_bmc->response;
> +
> +		if (ssif_bmc->response.len && ssif_bmc->msg_idx < ssif_bmc->response.len) {
> +			ssif_bmc->msg_idx++;
> +			*val = buf[ssif_bmc->msg_idx];
> +		} else if (ssif_bmc->response.len &&
> +			   (ssif_bmc->msg_idx == ssif_bmc->response.len)) {
> +			ssif_bmc->msg_idx++;
> +			*val = i2c_smbus_pec(pec, buf, ssif_msg_len(&ssif_bmc->response));
> +		} else {
> +			*val = 0;
> +		}
> +		/* Invalidate response buffer to denote it is sent */
> +		if (ssif_bmc->msg_idx + 1 >= (ssif_msg_len(&ssif_bmc->response) + pec_len))
> +			complete_response(ssif_bmc);
> +	} else {
> +		/* Multi-part Read processing */
> +		switch (ssif_bmc->smbus_cmd) {
> +		case SSIF_IPMI_MULTIPART_READ_START:
> +		case SSIF_IPMI_MULTIPART_READ_MIDDLE:
> +			buf = (u8 *)&ssif_bmc->response_buf;
> +			*val = buf[ssif_bmc->msg_idx];
> +			ssif_bmc->msg_idx++;
> +			break;
> +		default:
> +			/* Do not expect to go to this case */
> +			pr_err("Error: Unexpected SMBus command received 0x%x\n",
> +			       ssif_bmc->smbus_cmd);
> +			break;
> +		}
> +		len = (ssif_bmc->block_num == 0xFF) ?
> +		       ssif_bmc->remain_len + 1 : MAX_PAYLOAD_PER_TRANSACTION;
> +		if (ssif_bmc->msg_idx == (len + 1)) {
> +			pec = i2c_smbus_pec(pec, &len, 1);
> +			*val = i2c_smbus_pec(pec, ssif_bmc->response_buf, len);
> +		}
> +		/* Invalidate response buffer to denote last response is sent */
> +		if (ssif_bmc->block_num == 0xFF &&
> +		    ssif_bmc->msg_idx > (ssif_bmc->remain_len + pec_len)) {
> +			complete_response(ssif_bmc);
> +		}
> +	}
> +}
> +
> +static void handle_write_received(struct ssif_bmc_ctx *ssif_bmc, u8 *val)
> +{
> +	u8 *buf;
> +	u8 smbus_cmd;
> +
> +	buf = (u8 *)&ssif_bmc->request;
> +	if (ssif_bmc->msg_idx >= sizeof(struct ssif_msg))
> +		return;
> +
> +	smbus_cmd = ssif_bmc->smbus_cmd;
> +	switch (smbus_cmd) {
> +	case SSIF_IPMI_SINGLEPART_WRITE:
> +		/* Single-part write */
> +		buf[ssif_bmc->msg_idx - 1] = *val;
> +		ssif_bmc->msg_idx++;
> +
> +		break;
> +	case SSIF_IPMI_MULTIPART_WRITE_START:
> +		/* Reset length to zero */
> +		if (ssif_bmc->msg_idx == 1)
> +			ssif_bmc->request.len = 0;
> +
> +		fallthrough;
> +	case SSIF_IPMI_MULTIPART_WRITE_MIDDLE:
> +	case SSIF_IPMI_MULTIPART_WRITE_END:
> +		/* Multi-part write, 2nd byte received is length */
> +		if (ssif_bmc->msg_idx == 1) {
> +			ssif_bmc->request.len += *val;
> +			ssif_bmc->recv_len = *val;
> +		} else {
> +			buf[ssif_bmc->msg_idx - 1 +
> +			    ssif_bmc->request.len - ssif_bmc->recv_len]	= *val;
> +		}
> +
> +		ssif_bmc->msg_idx++;
> +
> +		break;
> +	default:
> +		/* Do not expect to go to this case */
> +		pr_err("Error: Unexpected SMBus command received 0x%x\n", ssif_bmc->smbus_cmd);
> +		break;
> +	}
> +}
> +
> +static bool validate_pec(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	u8 rpec = 0, cpec = 0;
> +	bool ret = true;
> +	u8 addr, index;
> +	u8 *buf;
> +
> +	buf = (u8 *)&ssif_bmc->request;
> +	switch (ssif_bmc->smbus_cmd) {
> +	case SSIF_IPMI_SINGLEPART_WRITE:
> +		if ((ssif_bmc->msg_idx - 1) == ssif_msg_len(&ssif_bmc->request)) {
> +			/* PEC is not included */
> +			ssif_bmc->pec_support = false;
> +			return true;
> +		}
> +
> +		if ((ssif_bmc->msg_idx - 1) != (ssif_msg_len(&ssif_bmc->request) + 1))
> +			goto error;
> +
> +		/* PEC is included */
> +		ssif_bmc->pec_support = true;
> +		rpec = buf[ssif_bmc->msg_idx - 2];
> +		addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +		cpec = i2c_smbus_pec(cpec, &addr, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->smbus_cmd, 1);
> +		cpec = i2c_smbus_pec(cpec, buf, ssif_msg_len(&ssif_bmc->request));
> +		if (rpec != cpec) {
> +			pr_err("Bad PEC 0x%02x vs. 0x%02x\n", rpec, cpec);
> +			ret = false;
> +		}
> +
> +		break;
> +	case SSIF_IPMI_MULTIPART_WRITE_START:
> +	case SSIF_IPMI_MULTIPART_WRITE_MIDDLE:
> +	case SSIF_IPMI_MULTIPART_WRITE_END:
> +		index = ssif_bmc->request.len - ssif_bmc->recv_len;
> +		if ((ssif_bmc->msg_idx - 1 + index) == ssif_msg_len(&ssif_bmc->request)) {
> +			/* PEC is not included */
> +			ssif_bmc->pec_support = false;
> +			return true;
> +		}
> +
> +		if ((ssif_bmc->msg_idx - 1 + index) != (ssif_msg_len(&ssif_bmc->request) + 1))
> +			goto error;
> +
> +		/* PEC is included */
> +		ssif_bmc->pec_support = true;
> +		rpec = buf[ssif_bmc->msg_idx - 2 + index];
> +		addr = GET_8BIT_ADDR(ssif_bmc->client->addr);
> +		cpec = i2c_smbus_pec(cpec, &addr, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->smbus_cmd, 1);
> +		cpec = i2c_smbus_pec(cpec, &ssif_bmc->recv_len, 1);
> +		/* As SMBus specification does not allow the length
> +		 * (byte count) in the Write-Block protocol to be zero.
> +		 * Therefore, it is illegal to have the last Middle
> +		 * transaction in the sequence carry 32-bytes and have
> +		 * a length of ?0? in the End transaction.
> +		 * But some users may try to use this way and we should
> +		 * prevent ssif_bmc driver broken in this case.
> +		 */
> +		if (ssif_bmc->recv_len != 0)
> +			cpec = i2c_smbus_pec(cpec, buf + 1 + index, ssif_bmc->recv_len);
> +
> +		if (rpec != cpec) {
> +			pr_err("Bad PEC 0x%02x vs. 0x%02x\n", rpec, cpec);
> +			ret = false;
> +		}
> +
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return ret;
> +error:
> +	/* Do not expect to go to this case */
> +	pr_err("Error: Unexpected length received %d\n", ssif_msg_len(&ssif_bmc->request));
> +
> +	return false;
> +}
> +
> +static void complete_write_received(struct ssif_bmc_ctx *ssif_bmc)
> +{
> +	u8 cmd = ssif_bmc->smbus_cmd;
> +
> +	/* A BMC that receives an invalid PEC shall drop the data for the write
> +	 * transaction and any further transactions (read or write) until
> +	 * the next valid read or write Start transaction is received
> +	 */
> +	if (!validate_pec(ssif_bmc)) {
> +		pr_err("Received invalid PEC\n");
> +		return;
> +	}
> +
> +	if (cmd == SSIF_IPMI_SINGLEPART_WRITE || cmd == SSIF_IPMI_MULTIPART_WRITE_END)
> +		handle_request(ssif_bmc);
> +}
> +
> +/*
> + * Callback function to handle I2C slave events
> + */
> +static int ssif_bmc_cb(struct i2c_client *client, enum i2c_slave_event event, u8 *val)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = i2c_get_clientdata(client);
> +
> +	spin_lock(&ssif_bmc->lock);
> +
> +	/* I2C Event Handler:
> +	 *   I2C_SLAVE_READ_REQUESTED	0x0
> +	 *   I2C_SLAVE_WRITE_REQUESTED	0x1
> +	 *   I2C_SLAVE_READ_PROCESSED	0x2
> +	 *   I2C_SLAVE_WRITE_RECEIVED	0x3
> +	 *   I2C_SLAVE_STOP		0x4
> +	 */
> +	switch (event) {
> +	case I2C_SLAVE_READ_REQUESTED:
> +		ssif_bmc->msg_idx = 0;
> +		if (ssif_bmc->is_singlepart_read)
> +			set_singlepart_response_buffer(ssif_bmc, val);
> +		else
> +			set_multipart_response_buffer(ssif_bmc, val);
> +		break;
> +
> +	case I2C_SLAVE_WRITE_REQUESTED:
> +		ssif_bmc->msg_idx = 0;
> +		break;
> +
> +	case I2C_SLAVE_READ_PROCESSED:
> +		handle_read_processed(ssif_bmc, val);
> +		break;
> +
> +	case I2C_SLAVE_WRITE_RECEIVED:
> +		/*
> +		 * First byte is SMBUS command, not a part of SSIF message.
> +		 * SSIF request buffer starts with msg_idx 1 for the first
> +		 *  buffer byte.
> +		 */
> +		if (ssif_bmc->msg_idx == 0) {
> +			/* SMBUS command can vary (single or multi-part) */
> +			ssif_bmc->smbus_cmd = *val;
> +			ssif_bmc->msg_idx++;
> +		} else {
> +			handle_write_received(ssif_bmc, val);
> +		}
> +
> +		break;
> +
> +	case I2C_SLAVE_STOP:
> +		/*
> +		 * PEC byte is appended at the end of each transaction.
> +		 * Detect PEC is support or not after receiving write request
> +		 * completely.
> +		 */
> +		if (ssif_bmc->last_event == I2C_SLAVE_WRITE_RECEIVED)
> +			complete_write_received(ssif_bmc);
> +		/* Reset message index */
> +		ssif_bmc->msg_idx = 0;
> +		break;
> +
> +	default:
> +		break;
> +	}
> +	ssif_bmc->last_event = event;
> +	spin_unlock(&ssif_bmc->lock);
> +
> +	return 0;
> +}
> +
> +struct ssif_bmc_ctx *ssif_bmc_alloc(struct i2c_client *client, int sizeof_priv)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc;
> +	int ret;
> +
> +	ssif_bmc = devm_kzalloc(&client->dev, sizeof(*ssif_bmc) + sizeof_priv, GFP_KERNEL);
> +	if (!ssif_bmc)
> +		return ERR_PTR(-ENOMEM);
> +
> +	spin_lock_init(&ssif_bmc->lock);
> +
> +	init_waitqueue_head(&ssif_bmc->wait_queue);
> +	ssif_bmc->request_available = false;
> +	ssif_bmc->response_in_progress = false;
> +
> +	mutex_init(&ssif_bmc->file_mutex);
> +
> +	/* Register misc device interface */
> +	ssif_bmc->miscdev.minor = MISC_DYNAMIC_MINOR;
> +	ssif_bmc->miscdev.name = DEVICE_NAME;
> +	ssif_bmc->miscdev.fops = &ssif_bmc_fops;
> +	ssif_bmc->miscdev.parent = &client->dev;
> +	ret = misc_register(&ssif_bmc->miscdev);
> +	if (ret)
> +		goto out;
> +
> +	ssif_bmc->client = client;
> +	ssif_bmc->client->flags |= I2C_CLIENT_SLAVE;
> +
> +	/* Register I2C slave */
> +	i2c_set_clientdata(client, ssif_bmc);
> +	ret = i2c_slave_register(client, ssif_bmc_cb);
> +	if (ret) {
> +		misc_deregister(&ssif_bmc->miscdev);
> +		goto out;
> +	}
> +
> +	return ssif_bmc;
> +
> +out:
> +	devm_kfree(&client->dev, ssif_bmc);
> +	return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(ssif_bmc_alloc);
> +
> +MODULE_AUTHOR("Chuong Tran <chuong at os.amperecomputing.com>");
> +MODULE_AUTHOR("Quan Nguyen <quan at os.amperecomputing.com>");
> +MODULE_DESCRIPTION("Linux device driver of the BMC IPMI SSIF interface.");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/char/ipmi/ssif_bmc.h b/drivers/char/ipmi/ssif_bmc.h
> new file mode 100644
> index 000000000000..a2ee090572db
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * The driver for BMC side of SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +#ifndef __SSIF_BMC_H__
> +#define __SSIF_BMC_H__
> +
> +#define DEVICE_NAME				"ipmi-ssif-host"
> +
> +#define GET_8BIT_ADDR(addr_7bit)		(((addr_7bit) << 1) & 0xff)
> +
> +#define MSG_PAYLOAD_LEN_MAX			252
> +
> +/* A standard SMBus Transaction is limited to 32 data bytes */
> +#define MAX_PAYLOAD_PER_TRANSACTION		32
> +
> +#define MAX_IPMI_DATA_PER_START_TRANSACTION	30
> +#define MAX_IPMI_DATA_PER_MIDDLE_TRANSACTION	31
> +
> +#define SSIF_IPMI_SINGLEPART_WRITE		0x2
> +#define SSIF_IPMI_SINGLEPART_READ		0x3
> +#define SSIF_IPMI_MULTIPART_WRITE_START		0x6
> +#define SSIF_IPMI_MULTIPART_WRITE_MIDDLE	0x7
> +#define SSIF_IPMI_MULTIPART_WRITE_END		0x8
> +#define SSIF_IPMI_MULTIPART_READ_START		0x3
> +#define SSIF_IPMI_MULTIPART_READ_MIDDLE		0x9
> +
> +struct ssif_msg {
> +	u8 len;
> +	u8 netfn_lun;
> +	u8 cmd;
> +	u8 payload[MSG_PAYLOAD_LEN_MAX];
> +} __packed;
> +
> +static inline u32 ssif_msg_len(struct ssif_msg *ssif_msg)
> +{
> +	return ssif_msg->len + 1;
> +}
> +
> +#define SSIF_BMC_BUSY   0x01
> +#define SSIF_BMC_READY  0x02
> +
> +struct ssif_bmc_ctx {
> +	struct i2c_client	*client;
> +	struct miscdevice	miscdev;
> +	u8			smbus_cmd;
> +	struct ssif_msg		request;
> +	bool			request_available;
> +	struct ssif_msg		response;
> +	bool			response_in_progress;
> +	/* Response buffer for Multi-part Read Transaction */
> +	u8			response_buf[MAX_PAYLOAD_PER_TRANSACTION];
> +	/* Flag to identify a Multi-part Read Transaction */
> +	bool			is_singlepart_read;
> +	u8			nbytes_processed;
> +	u8			remain_len;
> +	u8			recv_len;
> +	/* Block Number of a Multi-part Read Transaction */
> +	u8			block_num;
> +	size_t			msg_idx;
> +	enum i2c_slave_event	last_event;
> +	bool			pec_support;
> +	spinlock_t		lock;
> +	wait_queue_head_t	wait_queue;
> +	struct mutex		file_mutex;
> +	void (*set_ssif_bmc_status)(struct ssif_bmc_ctx *ssif_bmc, unsigned int flags);
> +	void			*priv;
> +};
> +
> +static inline struct ssif_bmc_ctx *to_ssif_bmc(struct file *file)
> +{
> +	return container_of(file->private_data, struct ssif_bmc_ctx, miscdev);
> +}
> +
> +struct ssif_bmc_ctx *ssif_bmc_alloc(struct i2c_client *client, int sizeof_priv);
> +
> +#endif /* __SSIF_BMC_H__ */
> diff --git a/drivers/char/ipmi/ssif_bmc_aspeed.c b/drivers/char/ipmi/ssif_bmc_aspeed.c
> new file mode 100644
> index 000000000000..a563fcff5acc
> --- /dev/null
> +++ b/drivers/char/ipmi/ssif_bmc_aspeed.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The driver for BMC side of Aspeed SSIF interface
> + *
> + * Copyright (c) 2021, Ampere Computing LLC
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <https://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/poll.h>
> +#include <linux/iopoll.h>
> +
> +#include "ssif_bmc.h"
> +
> +struct aspeed_i2c_bus {
> +	struct i2c_adapter              adap;
> +	struct device                   *dev;
> +	void __iomem                    *base;
> +	struct reset_control            *rst;
> +	/* Synchronizes I/O mem access to base. */
> +	spinlock_t                      lock;
> +};
> +
> +#define ASPEED_I2C_INTR_CTRL_REG	0x0c
> +#define ASPEED_I2CD_INTR_SLAVE_MATCH	BIT(7)
> +#define ASPEED_I2CD_INTR_RX_DONE	BIT(2)
> +static void aspeed_i2c_enable_interrupt(struct aspeed_i2c_bus *bus, unsigned long mask)
> +{
> +	unsigned long current_mask;
> +
> +	current_mask = readl(bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +	writel(current_mask | mask, bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +}
> +
> +static void aspeed_i2c_disable_interrupt(struct aspeed_i2c_bus *bus, unsigned long mask)
> +{
> +	unsigned long current_mask;
> +
> +	current_mask = readl(bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +	writel(current_mask & ~mask, bus->base + ASPEED_I2C_INTR_CTRL_REG);
> +}
> +
> +static void aspeed_set_ssif_bmc_status(struct ssif_bmc_ctx *ssif_bmc, unsigned int status)
> +{
> +	struct aspeed_i2c_bus *bus;
> +	unsigned long flags;
> +
> +	bus = (struct aspeed_i2c_bus *)ssif_bmc->priv;
> +	if (!bus)
> +		return;
> +
> +	spin_lock_irqsave(&bus->lock, flags);

Trying to take this spinlock cannot succeed as its already taken by this
point.

The command sent over I2C to trigger this is

20 02 0C 2C 02 AE 00 00 00 00 00 00 00 00 00 46

CONFIG_SPINLOCK_DEBUG output below. Obviously this deadlocks the kernel.

root at nuviamachine1:~# [   38.790031] BUG: spinlock recursion on CPU#0,
swapper/0/0
[   38.796085]  lock: 0x8114c33c, .magic: dead4ead, .owner: swapper/0/0,
.owner_cpu: 0
[   38.804637] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.10.30-51e4d5a-dirty-601c30e-00164-g463ecaa957f0 #7
[   38.815410] Hardware name: Generic DT based system
[   38.820756] Backtrace: 
[   38.823502] [<808e9408>] (dump_backtrace) from [<808e9664>]
(show_stack+0x20/0x24)
[   38.831955]  r7:855362a0 r6:600f0193 r5:00000000 r4:80ca3590
[   38.838277] [<808e9644>] (show_stack) from [<808f45b4>]
(dump_stack+0xa0/0xb4)
[   38.846342] [<808f4514>] (dump_stack) from [<808ea418>]
(spin_dump+0x90/0x98)
[   38.854307]  r7:855362a0 r6:8114c33c r5:80c10400 r4:8114c33c
[   38.860627] [<808ea388>] (spin_dump) from [<80171044>]
(do_raw_spin_lock+0x12c/0x130)
[   38.869365]  r5:ffffe000 r4:8114c33c
[   38.873360] [<80170f18>] (do_raw_spin_lock) from [<808fb628>]
(_raw_spin_lock_irqsave+0x20/0x28)
[   38.883165]  r5:00000001 r4:a00f0193
[   38.887162] [<808fb608>] (_raw_spin_lock_irqsave) from [<80513648>]
(aspeed_set_ssif_bmc_status+0x30/0xbc)
[   38.897937]  r5:00000001 r4:8114c040
[   38.901931] [<80513618>] (aspeed_set_ssif_bmc_status) from
[<80512b00>] (ssif_bmc_cb+0x1c4/0x698)
[   38.911835]  r7:855362a0 r6:8553606c r5:00000004 r4:85536040
[   38.918158] [<8051293c>] (ssif_bmc_cb) from [<8067e648>]
(aspeed_i2c_slave_irq+0xb8/0x264)
[   38.927386]  r10:80c00000 r9:80c0a514 r8:00000010 r7:85545000
r6:00000010 r5:00000010
[   38.936122]  r4:8114c040
[   38.938952] [<8067e590>] (aspeed_i2c_slave_irq) from [<8067ed68>]
(aspeed_i2c_bus_irq+0xd0/0x154)
[   38.948855]  r7:8114c33c r6:00000010 r5:811e106c r4:8114c040
[   38.955175] [<8067ec98>] (aspeed_i2c_bus_irq) from [<8017ae3c>]
(__handle_irq_event_percpu+0x68/0x204)
[   38.965568]  r10:80c00000 r9:80c0a514 r8:00000030 r7:80c01e20
r6:00000000 r5:811e106c
[   38.974305]  r4:855468c0 r3:8067ec98
[   38.978299] [<8017add4>] (__handle_irq_event_percpu) from
[<8017b018>] (handle_irq_event_percpu+0x40/0xa0)
[   38.989077]  r10:10c5387d r9:80c00000 r8:81042800 r7:00000000
r6:811e106c r5:811e106c
[   38.997814]  r4:811e1000
[   39.000644] [<8017afd8>] (handle_irq_event_percpu) from [<8017b0c0>]
(handle_irq_event+0x48/0x6c)
[   39.010546]  r5:811e106c r4:811e1000
[   39.014539] [<8017b078>] (handle_irq_event) from [<80180030>]
(handle_fasteoi_irq+0xc8/0x170)
[   39.024056]  r7:00000000 r6:80c0ac14 r5:811e106c r4:811e1000
[   39.030376] [<8017ff68>] (handle_fasteoi_irq) from [<8017a428>]
(generic_handle_irq+0x40/0x54)
[   39.039989]  r7:00000000 r6:00000001 r5:00000000 r4:80b6c80c
[   39.046312] [<8017a3e8>] (generic_handle_irq) from [<8017a4a8>]
(__handle_domain_irq+0x6c/0xc0)
[   39.056028] [<8017a43c>] (__handle_domain_irq) from [<8010134c>]
(gic_handle_irq+0x7c/0x90)
[   39.065353]  r9:80c00000 r8:bf80200c r7:80b6bdcc r6:bf802000
r5:80c01ee0 r4:80c0ac14
[   39.073998] [<801012d0>] (gic_handle_irq) from [<80100b0c>]
(__irq_svc+0x6c/0x90)
[   39.082340] Exception stack(0x80c01ee0 to 0x80c01f28)
[   39.087981] 1ee0: 00000000 00009a14 bd7dc484 8011a740 80c00000
00000000 80c0a514 80c0a550
[   39.097111] 1f00: 80ca7f5b 80a0ea58 10c5387d 80c01f3c 80c01f40
80c01f30 8010907c 80109080
[   39.106237] 1f20: 600f0013 ffffffff
[   39.110130]  r9:80c00000 r8:80ca7f5b r7:80c01f14 r6:ffffffff
r5:600f0013 r4:80109080
[   39.118773] [<80109038>] (arch_cpu_idle) from [<808fb4c8>]
(default_idle_call+0x38/0x108)
[   39.127907] [<808fb490>] (default_idle_call) from [<80156128>]
(do_idle+0xe4/0x150)
[   39.136457] [<80156044>] (do_idle) from [<80156478>]
(cpu_startup_entry+0x28/0x2c)
[   39.144908]  r9:8ffff564 r8:80b3ba6c r7:00000000 r6:80cc7000
r5:00000001 r4:000000d8
[   39.153545] [<80156450>] (cpu_startup_entry) from [<808f4f10>]
(rest_init+0xbc/0xc4)
[   39.162192] [<808f4e54>] (rest_init) from [<80b00c94>]
(arch_call_rest_init+0x18/0x1c)
[   39.171027]  r5:00000001 r4:80cc7040
[   39.175017] [<80b00c7c>] (arch_call_rest_init) from [<80b0124c>]
(start_kernel+0x53c/0x584)
[   39.184330] [<80b00d10>] (start_kernel) from [<00000000>] (0x0)


> +
> +	if (status & SSIF_BMC_BUSY) {
> +		/* Ignore RX_DONE and SLAVE_MATCH when slave busy processing */
> +		aspeed_i2c_disable_interrupt(bus, ASPEED_I2CD_INTR_RX_DONE);
> +		aspeed_i2c_disable_interrupt(bus, ASPEED_I2CD_INTR_SLAVE_MATCH);
> +	} else if (status & SSIF_BMC_READY) {
> +		/* Enable RX_DONE and SLAVE_MATCH when slave ready */
> +		aspeed_i2c_enable_interrupt(bus, ASPEED_I2CD_INTR_RX_DONE);
> +		aspeed_i2c_enable_interrupt(bus, ASPEED_I2CD_INTR_SLAVE_MATCH);
> +	}
> +
> +	spin_unlock_irqrestore(&bus->lock, flags);
> +}
> +
> +static int ssif_bmc_probe(struct i2c_client *client, const struct i2c_device_id *id)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc;
> +
> +	ssif_bmc = ssif_bmc_alloc(client, sizeof(struct aspeed_i2c_bus));
> +	if (IS_ERR(ssif_bmc))
> +		return PTR_ERR(ssif_bmc);
> +
> +	ssif_bmc->priv = i2c_get_adapdata(client->adapter);
> +	ssif_bmc->set_ssif_bmc_status = aspeed_set_ssif_bmc_status;
> +
> +	return 0;
> +}
> +
> +static int ssif_bmc_remove(struct i2c_client *client)
> +{
> +	struct ssif_bmc_ctx *ssif_bmc = i2c_get_clientdata(client);
> +
> +	i2c_slave_unregister(client);
> +	misc_deregister(&ssif_bmc->miscdev);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id ssif_bmc_match[] = {
> +	{ .compatible = "aspeed,ast2500-ssif-bmc" },
> +	{ },
> +};
> +
> +static const struct i2c_device_id ssif_bmc_id[] = {
> +	{ DEVICE_NAME, 0 },
> +	{ },
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, ssif_bmc_id);
> +
> +static struct i2c_driver ssif_bmc_driver = {
> +	.driver		= {
> +		.name		= DEVICE_NAME,
> +		.of_match_table = ssif_bmc_match,
> +	},
> +	.probe		= ssif_bmc_probe,
> +	.remove		= ssif_bmc_remove,
> +	.id_table	= ssif_bmc_id,
> +};
> +
> +module_i2c_driver(ssif_bmc_driver);
> +
> +MODULE_AUTHOR("Chuong Tran <chuong at os.amperecomputing.com>");
> +MODULE_AUTHOR("Quan Nguyen <quan at os.amperecomputing.com>");
> +MODULE_DESCRIPTION("Linux device driver of Aspeed BMC IPMI SSIF interface.");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.28.0
> 


From michal.simek at xilinx.com  Thu Apr 22 11:54:00 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 22 Apr 2021 12:54:00 +0200
Subject: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE
In-Reply-To: <871rb2swd9.fsf@kokedama.swc.toshiba.co.jp>
References: <20210421134844.3297838-1-arnd@kernel.org>
 <871rb2swd9.fsf@kokedama.swc.toshiba.co.jp>
Message-ID: <01e78b64-8ad1-dfc8-9fc0-6afff4841492@xilinx.com>

Hi,

On 4/22/21 7:48 AM, Punit Agrawal wrote:
> Hi Arnd,
> 
> Thanks for the fix.
> 
> Arnd Bergmann <arnd at kernel.org> writes:
> 
>> From: Arnd Bergmann <arnd at arndb.de>
>>
>> When the firmware code is disabled, the incomplete error handling
>> in the clk driver causes compile-time warnings:
>>
>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>> drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized]
>>   147 |         rate =  parent_rate * fbdiv;
>>       |                 ~~~~~~~~~~~~^~~~~~~
>> In function 'zynqmp_pll_get_mode',
>>     inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6:
>> drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized]
>>    61 |         return ret_payload[1];
>>       |                ~~~~~~~~~~~^~~
>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>> drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here
>>    53 |         u32 ret_payload[PAYLOAD_ARG_CNT];
>>       |             ^~~~~~~~~~~
>> drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent':
>> drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized]
>>    57 |         return val;
>>       |                ^~~
> 
> 
> Not sure what I am missing but I couldn't reproduce these warnings. I
> tried a few different ways to toggle CONFIG_ZYNQMP_FIRMWARE.
> 
> Regardless...

Me too. Can you share your .config file?

> 
>> As it was apparently intentional to support this for compile testing
>> purposes, change the code to have just enough error handling for the
>> compiler to not notice the remaining bugs.
>>
>> Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP")
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> ---
>>  drivers/clk/zynqmp/clk-mux-zynqmp.c | 4 +++-
>>  drivers/clk/zynqmp/pll.c            | 8 ++++++--
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/zynqmp/clk-mux-zynqmp.c b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>> index 06194149be83..2afded3c7c11 100644
>> --- a/drivers/clk/zynqmp/clk-mux-zynqmp.c
>> +++ b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>> @@ -50,9 +50,11 @@ static u8 zynqmp_clk_mux_get_parent(struct clk_hw *hw)
>>  
>>  	ret = zynqmp_pm_clock_getparent(clk_id, &val);
>>  
>> -	if (ret)
>> +	if (ret) {
>>  		pr_warn_once("%s() getparent failed for clock: %s, ret = %d\n",
>>  			     __func__, clk_name, ret);
>> +		return ret;

return should be u8 and this can be negative value. That's why I think
this should be fixed differently and all users should be checked that it
is handled like that.


>> +	}
>>  
>>  	return val;
>>  }
>> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
>> index abe6afbf3407..67d2a2d260c1 100644
>> --- a/drivers/clk/zynqmp/pll.c
>> +++ b/drivers/clk/zynqmp/pll.c
>> @@ -54,9 +54,11 @@ static inline enum pll_mode zynqmp_pll_get_mode(struct clk_hw *hw)
>>  	int ret;
>>  
>>  	ret = zynqmp_pm_get_pll_frac_mode(clk_id, ret_payload);
>> -	if (ret)
>> +	if (ret) {
>>  		pr_warn_once("%s() PLL get frac mode failed for %s, ret = %d\n",
>>  			     __func__, clk_name, ret);
>> +		return ret;
>> +	}

Return should be enum pll_mode which is 0 or 1 which is likely not done
here.

>>  
>>  	return ret_payload[1];
>>  }
>> @@ -140,9 +142,11 @@ static unsigned long zynqmp_pll_recalc_rate(struct clk_hw *hw,
>>  	int ret;
>>  
>>  	ret = zynqmp_pm_clock_getdivider(clk_id, &fbdiv);
>> -	if (ret)
>> +	if (ret) {
>>  		pr_warn_once("%s() get divider failed for %s, ret = %d\n",
>>  			     __func__, clk_name, ret);
>> +		return -1ul;
>> +	}

Same here.


>>  
>>  	rate =  parent_rate * fbdiv;
>>  	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
> 
> The changes make sense in that the functions error out sensibly when the
> zynqmp firmware driver is not enabled.
> 
> Acked-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>

I think code should be checked that these error values are handled how
they should be handled.

Thanks,
Michal



From lkp at intel.com  Thu Apr 22 11:55:20 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 18:55:20 +0800
Subject: [xlnx:master 11884/12154] drivers/uio/uio_xilinx_ai_engine.c:39:6:
 warning: variable 'irq' set but not used
Message-ID: <202104221814.fACaMPao-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   bcd80b4c331c5d55de978ab0b2f6181a8aea3434
commit: 15d16835418c3d35e07f215d2934dcf9e6725cc6 [11884/12154] uio: Add the UIO driver for AI engine
config: um-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/15d16835418c3d35e07f215d2934dcf9e6725cc6
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 15d16835418c3d35e07f215d2934dcf9e6725cc6
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=um 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   cc1: warning: arch/um/include/uapi: No such file or directory [-Wmissing-include-dirs]
   drivers/uio/uio_xilinx_ai_engine.c: In function 'xilinx_ai_engine_debugfs_write':
>> drivers/uio/uio_xilinx_ai_engine.c:39:6: warning: variable 'irq' set but not used [-Wunused-but-set-variable]
      39 |  int irq, ret;
         |      ^~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for MFD_CORE
   Depends on HAS_IOMEM
   Selected by
   - MFD_HI6421_SPMI && STAGING && OF && SPMI
   WARNING: unmet direct dependencies detected for UIO_DMEM_GENIRQ
   Depends on UIO && HAS_DMA
   Selected by
   - UIO_XILINX_AI_ENGINE && UIO


vim +/irq +39 drivers/uio/uio_xilinx_ai_engine.c

    33	
    34	static ssize_t xilinx_ai_engine_debugfs_write(struct file *f,
    35						      const char __user *buf,
    36						      size_t size, loff_t *pos)
    37	{
    38		struct irq_domain *irq_sim_domain = file_inode(f)->i_private;
  > 39		int irq, ret;
    40	
    41		irq = irq_find_mapping(irq_sim_domain, 1);
    42		ret = irq_set_irqchip_state(1, IRQCHIP_STATE_PENDING, true);
    43		if (ret)
    44			return ret;
    45	
    46		return size;
    47	}
    48	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 23671 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/254ab2a7/attachment-0001.gz>

From hsinyi at chromium.org  Thu Apr 22 12:10:04 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 22 Apr 2021 19:10:04 +0800
Subject: [PATCH] drm/mediatek: clear pending flag when cmdq packet is done.
Message-ID: <20210422111004.1338867-1-hsinyi@chromium.org>

From: CK Hu <ck.hu at mediatek.com>

In cmdq mode, packet may be flushed before it is executed, so
the pending flag should be cleared after cmdq packet is done.

Signed-off-by: CK Hu <ck.hu at mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 56 +++++++++++++++++++++---
 include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 40df2c823187..051bf0eb00d3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -224,6 +224,45 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc,
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 static void ddp_cmdq_cb(struct cmdq_cb_data data)
 {
+	struct cmdq_pkt *pkt = (struct cmdq_pkt *)data.data;
+	struct mtk_drm_crtc *mtk_crtc = (struct mtk_drm_crtc *)pkt->crtc;
+	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
+	unsigned int i;
+
+	if (data.sta == CMDQ_CB_ERROR)
+		goto destroy_pkt;
+
+	if (state->pending_config) {
+		state->pending_config = false;
+	}
+
+	if (mtk_crtc->pending_planes) {
+		for (i = 0; i < mtk_crtc->layer_nr; i++) {
+			struct drm_plane *plane = &mtk_crtc->planes[i];
+			struct mtk_plane_state *plane_state;
+
+			plane_state = to_mtk_plane_state(plane->state);
+
+			if (plane_state->pending.config)
+				plane_state->pending.config = false;
+		}
+		mtk_crtc->pending_planes = false;
+	}
+
+	if (mtk_crtc->pending_async_planes) {
+		for (i = 0; i < mtk_crtc->layer_nr; i++) {
+			struct drm_plane *plane = &mtk_crtc->planes[i];
+			struct mtk_plane_state *plane_state;
+
+			plane_state = to_mtk_plane_state(plane->state);
+
+			if (plane_state->pending.async_config)
+				plane_state->pending.async_config = false;
+		}
+		mtk_crtc->pending_async_planes = false;
+	}
+
+destroy_pkt:
 	cmdq_pkt_destroy(data.data);
 }
 #endif
@@ -377,8 +416,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
 				    state->pending_height,
 				    state->pending_vrefresh, 0,
 				    cmdq_handle);
-
-		state->pending_config = false;
+		if (!cmdq_handle)
+			state->pending_config = false;
 	}
 
 	if (mtk_crtc->pending_planes) {
@@ -398,9 +437,11 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
 				mtk_ddp_comp_layer_config(comp, local_layer,
 							  plane_state,
 							  cmdq_handle);
-			plane_state->pending.config = false;
+			if (!cmdq_handle)
+				plane_state->pending.config = false;
 		}
-		mtk_crtc->pending_planes = false;
+		if (!cmdq_handle)
+			mtk_crtc->pending_planes = false;
 	}
 
 	if (mtk_crtc->pending_async_planes) {
@@ -420,9 +461,11 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
 				mtk_ddp_comp_layer_config(comp, local_layer,
 							  plane_state,
 							  cmdq_handle);
-			plane_state->pending.async_config = false;
+			if (!cmdq_handle)
+				plane_state->pending.async_config = false;
 		}
-		mtk_crtc->pending_async_planes = false;
+		if (!cmdq_handle)
+			mtk_crtc->pending_async_planes = false;
 	}
 }
 
@@ -475,6 +518,7 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
 		cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
 		mtk_crtc_ddp_config(crtc, cmdq_handle);
 		cmdq_pkt_finalize(cmdq_handle);
+		cmdq_handle->crtc = mtk_crtc;
 		cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
 	}
 #endif
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index d5a983d65f05..c06b14ec03e5 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -90,6 +90,7 @@ struct cmdq_pkt {
 	struct cmdq_task_cb	cb;
 	struct cmdq_task_cb	async_cb;
 	void			*cl;
+	void			*crtc;
 };
 
 u8 cmdq_get_shift_pa(struct mbox_chan *chan);
-- 
2.31.1.498.g6c1eba8ee3d-goog



From yang.lee at linux.alibaba.com  Thu Apr 22 12:16:52 2021
From: yang.lee at linux.alibaba.com (Yang Li)
Date: Thu, 22 Apr 2021 19:16:52 +0800
Subject: [PATCH v2] soc: ti: smartreflex after the relocation to maintain
 consistency
Message-ID: <1619090212-103038-1-git-send-email-yang.lee@linux.alibaba.com>

v2: According to Nishanth Menon's suggestion, the subject has been 
corrected.
https://lore.kernel.org/patchwork/patch/1383883/

Fix the following coccicheck warning:
./drivers/soc/ti/smartreflex.c:820:0-23: WARNING: pm_sr_fops should be
defined with DEFINE_DEBUGFS_ATTRIBUTE

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
Reviewed-by: Nishanth Menon <nm at ti.com>
---
 drivers/soc/ti/smartreflex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
index 5376f3d..b3c7460 100644
--- a/drivers/soc/ti/smartreflex.c
+++ b/drivers/soc/ti/smartreflex.c
@@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
 	return 0;
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
+DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
 			omap_sr_autocomp_store, "%llu\n");
 
 static int omap_sr_probe(struct platform_device *pdev)
-- 
1.8.3.1



From m.szyprowski at samsung.com  Thu Apr 22 12:19:46 2021
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 22 Apr 2021 13:19:46 +0200
Subject: [PATCH v2] hwrng: exynos - Fix runtime PM imbalance on error
In-Reply-To: <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com>
References: <CGME20210422104145eucas1p17f46c95b72f3568761a9f7911bf072e1@eucas1p1.samsung.com>
 <20210422104141.17668-1-l.stelmach@samsung.com>
 <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com>
Message-ID: <cdeb89aa-d876-f00d-529c-95456c5b2397@samsung.com>

On 22.04.2021 12:46, Krzysztof Kozlowski wrote:
> On 22/04/2021 12:41, ?ukasz Stelmach wrote:
>> pm_runtime_get_sync() increments the runtime PM usage counter even
>> the call returns an error code. Thus a pairing decrement is needed
>> on the error handling path to keep the counter balanced.
> It's exactly the same as Dinghao's patch:
> https://lore.kernel.org/linux-samsung-soc/20200522011659.26727-1-dinghao.liu at zju.edu.cn/
> which you reviewed. It has even the same commit msg
> (although it's difficult to be creative here).
>
> I think it's better to resend his patch instead.

Frankly speaking I would get rid of the pm_runtime_get_sync() calls in 
the drivers and replace them with pm_runtime_resume_and_get() to finish 
that never ending pm_runtime get/put misunderstanding soap opea...

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From l.stelmach at samsung.com  Thu Apr 22 12:22:15 2021
From: l.stelmach at samsung.com (=?utf-8?Q?=C5=81ukasz_Stelmach?=)
Date: Thu, 22 Apr 2021 13:22:15 +0200
Subject: [PATCH v2] hwrng: exynos - Fix runtime PM imbalance on error
In-Reply-To: <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com> (Krzysztof
 Kozlowski's message of "Thu, 22 Apr 2021 12:46:42 +0200")
References: <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com>
 <CGME20210422112224eucas1p283ca7aeaa25ab514b9743a11e63a76e0@eucas1p2.samsung.com>
Message-ID: <dleftj35vi7ee0.fsf%l.stelmach@samsung.com>

It was <2021-04-22 czw 12:46>, when Krzysztof Kozlowski wrote:
> On 22/04/2021 12:41, ?ukasz Stelmach wrote:
>> pm_runtime_get_sync() increments the runtime PM usage counter even
>> the call returns an error code. Thus a pairing decrement is needed
>> on the error handling path to keep the counter balanced.
>
> It's exactly the same as Dinghao's patch:
> https://lore.kernel.org/linux-samsung-soc/20200522011659.26727-1-dinghao.liu at zju.edu.cn/
> which you reviewed. It has even the same commit msg
> (although it's difficult to be creative here).
>
> I think it's better to resend his patch instead.

It isn't the same because it uses pm_runtime_put_noidle() as discussed
here[1], applied here[2] and advised here[2]. Dinghao didn't prepare
v3[4] for exynos.

[1] https://lore.kernel.org/lkml/20200528065519.GA26960 at gondor.apana.org.au/
[2] https://lore.kernel.org/lkml/20200528072106.5191-1-dinghao.liu at zju.edu.cn/
[3] https://lore.kernel.org/lkml/20200616073142.GA30519 at gondor.apana.org.au/
[4] https://lore.kernel.org/lkml/20200522011659.26727-1-dinghao.liu at zju.edu.cn/
-- 
?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/20210422/86bb7f8c/attachment-0001.sig>

From anshuman.khandual at arm.com  Thu Apr 22 12:23:36 2021
From: anshuman.khandual at arm.com (Anshuman Khandual)
Date: Thu, 22 Apr 2021 16:53:36 +0530
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <YIEzaQF8fVtNgU0E@kernel.org>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <YIEzaQF8fVtNgU0E@kernel.org>
Message-ID: <6096b004-aaeb-d814-87e4-92ec1b180f1d@arm.com>

On 4/22/21 1:57 PM, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 01:20:23PM +0530, Anshuman Khandual wrote:
>> Platforms like arm and arm64 have redefined pfn_valid() because their early
>> memory sections might have contained memmap holes after freeing parts of it
>> during boot, which should be skipped while validating a pfn for struct page
>> backing. This scenario on certain platforms where memmap is not continuous,
>> could be captured with a new option CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES.
>> Then the generic pfn_valid() can be improved to accommodate such platforms.
>> This reduces overall code footprint and also improves maintainability.
>>
>> free_unused_memmap() and pfn_to_online_page() have been updated to include
>> such cases. This also exports memblock_is_memory() for all drivers that use
>> pfn_valid() but lack required visibility. After the new config is in place,
>> drop CONFIG_HAVE_ARCH_PFN_VALID from arm64 platforms.
>>
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: Andrew Morton <akpm at linux-foundation.org>
>> Cc: Mike Rapoport <rppt at kernel.org>
>> Cc: David Hildenbrand <david at redhat.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: linux-mm at kvack.org
>> Suggested-by: David Hildenbrand <david at redhat.com>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual at arm.com>
>> ---
>> This patch applies on the latest mainline kernel after Mike's series
>> regarding arm64 based pfn_valid().
>>
>> https://lore.kernel.org/linux-mm/20210422061902.21614-1-rppt at kernel.org/T/#t
>>
>> Changes in RFC V2:
>>
>> - Dropped support for arm (32 bit)
>> - Replaced memblock_is_map_memory() check with memblock_is_memory()
>> - MEMBLOCK_NOMAP memory are no longer skipped for pfn_valid()
>> - Updated pfn_to_online_page() per David
>> - Updated free_unused_memmap() to preserve existing semantics per Mike
>> - Exported memblock_is_memory() instead of memblock_is_map_memory()
>>
>> Changes in RFC V1:
>>
>> - https://patchwork.kernel.org/project/linux-mm/patch/1615174073-10520-1-git-send-email-anshuman.khandual at arm.com/
>>
>>  arch/arm64/Kconfig            |  2 +-
>>  arch/arm64/include/asm/page.h |  1 -
>>  arch/arm64/mm/init.c          | 41 -----------------------------------
>>  include/linux/mmzone.h        | 18 ++++++++++++++-
>>  mm/Kconfig                    |  9 ++++++++
>>  mm/memblock.c                 |  8 +++++--
>>  mm/memory_hotplug.c           |  5 +++++
>>  7 files changed, 38 insertions(+), 46 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b4a9b493ce72..4cdc3570ffa9 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -144,7 +144,6 @@ config ARM64
>>  	select HAVE_ARCH_KGDB
>>  	select HAVE_ARCH_MMAP_RND_BITS
>>  	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>> -	select HAVE_ARCH_PFN_VALID
>>  	select HAVE_ARCH_PREL32_RELOCATIONS
>>  	select HAVE_ARCH_SECCOMP_FILTER
>>  	select HAVE_ARCH_STACKLEAK
>> @@ -167,6 +166,7 @@ config ARM64
>>  		if $(cc-option,-fpatchable-function-entry=2)
>>  	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
>>  		if DYNAMIC_FTRACE_WITH_REGS
>> +	select HAVE_EARLY_SECTION_MEMMAP_HOLES
>>  	select HAVE_EFFICIENT_UNALIGNED_ACCESS
>>  	select HAVE_FAST_GUP
>>  	select HAVE_FTRACE_MCOUNT_RECORD
>> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
>> index 75ddfe671393..fcbef3eec4b2 100644
>> --- a/arch/arm64/include/asm/page.h
>> +++ b/arch/arm64/include/asm/page.h
>> @@ -37,7 +37,6 @@ void copy_highpage(struct page *to, struct page *from);
>>  
>>  typedef struct page *pgtable_t;
>>  
>> -int pfn_valid(unsigned long pfn);
>>  int pfn_is_map_memory(unsigned long pfn);
>>  
>>  #include <asm/memory.h>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index f431b38d0837..5731a11550d8 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -217,47 +217,6 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>>  	free_area_init(max_zone_pfns);
>>  }
>>  
>> -int pfn_valid(unsigned long pfn)
>> -{
>> -	phys_addr_t addr = PFN_PHYS(pfn);
>> -
>> -	/*
>> -	 * Ensure the upper PAGE_SHIFT bits are clear in the
>> -	 * pfn. Else it might lead to false positives when
>> -	 * some of the upper bits are set, but the lower bits
>> -	 * match a valid pfn.
>> -	 */
>> -	if (PHYS_PFN(addr) != pfn)
>> -		return 0;
>> -
>> -#ifdef CONFIG_SPARSEMEM
>> -{
>> -	struct mem_section *ms;
>> -
>> -	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>> -		return 0;
>> -
>> -	ms = __pfn_to_section(pfn);
>> -	if (!valid_section(ms))
>> -		return 0;
>> -
>> -	/*
>> -	 * ZONE_DEVICE memory does not have the memblock entries.
>> -	 * memblock_is_memory() check for ZONE_DEVICE based
>> -	 * addresses will always fail. Even the normal hotplugged
>> -	 * memory will never have MEMBLOCK_NOMAP flag set in their
>> -	 * memblock entries. Skip memblock search for all non early
>> -	 * memory sections covering all of hotplug memory including
>> -	 * both normal and ZONE_DEVICE based.
>> -	 */
>> -	if (!early_section(ms))
>> -		return pfn_section_valid(ms, pfn);
>> -}
>> -#endif
>> -	return memblock_is_memory(addr);
>> -}
>> -EXPORT_SYMBOL(pfn_valid);
>> -
>>  int pfn_is_map_memory(unsigned long pfn)
>>  {
>>  	phys_addr_t addr = PFN_PHYS(pfn);
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 961f0eeefb62..18bf71665211 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -1421,10 +1421,22 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn)
>>   *
>>   * Return: 1 for PFNs that have memory map entries and 0 otherwise
>>   */
>> +bool memblock_is_memory(phys_addr_t addr);
>> +
>>  static inline int pfn_valid(unsigned long pfn)
>>  {
>> +	phys_addr_t addr = PFN_PHYS(pfn);
>>  	struct mem_section *ms;
>>  
>> +	/*
>> +	 * Ensure the upper PAGE_SHIFT bits are clear in the
>> +	 * pfn. Else it might lead to false positives when
>> +	 * some of the upper bits are set, but the lower bits
>> +	 * match a valid pfn.
>> +	 */
>> +	if (PHYS_PFN(addr) != pfn)
>> +		return 0;
>> +
>>  	if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
>>  		return 0;
>>  	ms = __nr_to_section(pfn_to_section_nr(pfn));
>> @@ -1434,7 +1446,11 @@ static inline int pfn_valid(unsigned long pfn)
>>  	 * Traditionally early sections always returned pfn_valid() for
>>  	 * the entire section-sized span.
>>  	 */
>> -	return early_section(ms) || pfn_section_valid(ms, pfn);
>> +	if (early_section(ms))
>> +		return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ?
>> +			memblock_is_memory(pfn << PAGE_SHIFT) : 1;
> 
> Nit: we already did 
> 
> 	addr = PFN_PHYS(pfn);
> 
> a few lines above :)

Yeah, will use the addr directly here.

> 
>> +
>> +	return pfn_section_valid(ms, pfn);
>>  }
>>  #endif
>>  
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 24c045b24b95..db7128111874 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -135,6 +135,15 @@ config HAVE_FAST_GUP
>>  config ARCH_KEEP_MEMBLOCK
>>  	bool
>>  
>> +config HAVE_EARLY_SECTION_MEMMAP_HOLES
>> +	depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP
>> +	def_bool n
>> +	help
>> +	  Early sections on certain platforms might have some memory ranges that
>> +	  are not backed with struct page mappings. When subscribed, this option
>> +	  enables special handling for those memory ranges in certain situations
>> +	  such as pfn_valid().
>> +
>>  # Keep arch NUMA mapping infrastructure post-init.
>>  config NUMA_KEEP_MEMINFO
>>  	bool
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index 3abf2c3fea7f..93f8a9c8428d 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
>>  {
>>  	return memblock_search(&memblock.memory, addr) != -1;
>>  }
>> +EXPORT_SYMBOL(memblock_is_memory);
> 
> Please make it inside #ifdef CONFIG_ARCH_MEMBLOCK
CONFIG_ARCH_KEEP_MEMBLOCK ? Wrap it around the EXPORT_SYMBOL() or the
entire function memblock_is_memory().

>   
>>  bool __init_memblock memblock_is_map_memory(phys_addr_t addr)
>>  {
>> @@ -1931,8 +1932,11 @@ static void __init free_unused_memmap(void)
>>  	unsigned long start, end, prev_end = 0;
>>  	int i;
>>  
>> -	if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) ||
>> -	    IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
>> +	if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
>> +		return;
>> +
>> +	if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) &&
>> +	    !IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID))
>>  		return;
> 
> Can you please add a comment that says that architecture should provide a
> way to detect holes in the memory map to be able to free its part?
I did not get that completely. If CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES is
not subscribed, then the platform must provide a method that identifies these
memmap holes and process them accordingly in pfn_valid() just to avoid null
pointer dereference ? Also the comment should be placed after the second
return statement, when its going to free unused memmap segments.


From broonie at kernel.org  Thu Apr 22 12:32:43 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 22 Apr 2021 12:32:43 +0100
Subject: [PATCH] spi: stm32-qspi: fix debug format string
In-Reply-To: <b970a557-b869-c867-3825-370a36feef68@foss.st.com>
References: <20210421140653.3964725-1-arnd@kernel.org>
 <20210421150510.GA36785@sirena.org.uk>
 <CAK8P3a0CWp_H-tm2QcZyH1FDXwzMgxY_9dc1Y8pA28MQKT-q=A@mail.gmail.com>
 <b970a557-b869-c867-3825-370a36feef68@foss.st.com>
Message-ID: <20210422113243.GA4572@sirena.org.uk>

On Thu, Apr 22, 2021 at 09:30:16AM +0200, Patrice CHOTARD wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> Regarding this issue, how do you prefer to proceed ? 

To repeat my original mail:

> > On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie at kernel.org> wrote:

> >> 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/20210422/3242b144/attachment.sig>

From cristian.marussi at arm.com  Thu Apr 22 12:34:52 2021
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Thu, 22 Apr 2021 12:34:52 +0100
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
In-Reply-To: <20210422101709.GF43717@e120937-lin>
References: <YIE7pdqV/h10tEAK@mwanda>
 <20210422101709.GF43717@e120937-lin>
Message-ID: <20210422113451.GG43717@e120937-lin>

On Thu, Apr 22, 2021 at 11:17:09AM +0100, Cristian Marussi wrote:
> Hi,
> 
> On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote:
> > How type promotion works in ternary expressions is a bit tricky.
> > The problem is that scpi_clk_get_val() returns longs, "ret" is a int
> > which holds a negative error code, and le32_to_cpu() is an unsigned int.
> > We want the negative error code to be cast to a negative long.  But
> > because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
> > becomes a high positive and then it is promoted to long and it is still
> > a high positive value.
> > 
> > Fix this by getting rid of the ternary.
> 
> I wonder how/if the callers up in the stack check/expect ever effectively for a
> 2-complement negative value inside the returned unsigned long...given that this
> plugs finally into CLK framework struct clk_ops.recalc_rate via clk-scpi.c which
> also expects unsigned long....but that's another story.
> 
> FWIW regarding this patch:
> 
> Reviewed-by: Cristian Marussi <cristian.marussi at arm.com>
> 
> Thanks
> 
> Cristian

@Sudeep, as a second though, looking at .recalc_rate() definition inside

include/linux/clk-provider.h:struct clk_ops 

which is the direct caller of this SCPI clk function, I wonder if, instead,
on error we should not return here just ZERO as the returned clock rate value
as in:

	if (ret)
		return 0;

given that the error code returned inside the unsigned long won't be ever
considerd as such apparently, so not sure if it'd be worst to return a
very big fake value or zero...

Thanks
Cristian


> > 
> > Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
> > Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
> > ---
> >  drivers/firmware/arm_scpi.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> > index d0dee37ad522..3bf61854121d 100644
> > --- a/drivers/firmware/arm_scpi.c
> > +++ b/drivers/firmware/arm_scpi.c
> > @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
> >  
> >  	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
> >  				sizeof(le_clk_id), &rate, sizeof(rate));
> > +	if (ret)
> > +		return ret;
> >  
> > -	return ret ? ret : le32_to_cpu(rate);
> > +	return le32_to_cpu(rate);
> >  }
> >  
> >  static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
> > -- 
> > 2.30.2
> > 


From colin.king at canonical.com  Thu Apr 22 13:04:12 2021
From: colin.king at canonical.com (Colin King)
Date: Thu, 22 Apr 2021 13:04:12 +0100
Subject: [PATCH] thermal: mtk_thermal: remove redundant initializations of
 several variables
Message-ID: <20210422120412.246291-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

Several variables are being initialized with values that is never
read and being updated later with a new value. The initializations
are redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/thermal/mtk_thermal.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 149c6d7fd5a0..97e8678ccf0e 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -573,12 +573,12 @@ static int raw_to_mcelsius_v1(struct mtk_thermal *mt, int sensno, s32 raw)
 
 static int raw_to_mcelsius_v2(struct mtk_thermal *mt, int sensno, s32 raw)
 {
-	s32 format_1 = 0;
-	s32 format_2 = 0;
-	s32 g_oe = 1;
-	s32 g_gain = 1;
-	s32 g_x_roomt = 0;
-	s32 tmp = 0;
+	s32 format_1;
+	s32 format_2;
+	s32 g_oe;
+	s32 g_gain;
+	s32 g_x_roomt;
+	s32 tmp;
 
 	if (raw == 0)
 		return 0;
-- 
2.30.2



From andrew at lunn.ch  Thu Apr 22 13:18:58 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 22 Apr 2021 14:18:58 +0200
Subject: [PATCH net-next 05/14] net: ethernet: mtk_eth_soc: reduce MDIO
 bus access latency
In-Reply-To: <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>
Message-ID: <YIFpsjiqhqEeVXNd@lunn.ch>

On Wed, Apr 21, 2021 at 09:09:05PM -0700, Ilya Lipnitskiy wrote:
> From: Felix Fietkau <nbd at nbd.name>
> 
> usleep_range often ends up sleeping much longer than the 10-20us provided
> as a range here. This causes significant latency in mdio bus acceses,

I found the same with the FEC driver, and make the same change.

> Signed-off-by: Felix Fietkau <nbd at nbd.name>
> [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>


Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From rppt at kernel.org  Thu Apr 22 13:19:53 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 22 Apr 2021 15:19:53 +0300
Subject: [RFC V2] mm: Enable generic pfn_valid() to handle early sections
 with memmap holes
In-Reply-To: <6096b004-aaeb-d814-87e4-92ec1b180f1d@arm.com>
References: <20210422061902.21614-1-rppt@kernel.org>
 <1619077823-3819-1-git-send-email-anshuman.khandual@arm.com>
 <YIEzaQF8fVtNgU0E@kernel.org>
 <6096b004-aaeb-d814-87e4-92ec1b180f1d@arm.com>
Message-ID: <YIFp6W/wgcZSxe1k@kernel.org>

On Thu, Apr 22, 2021 at 04:53:36PM +0530, Anshuman Khandual wrote:
> On 4/22/21 1:57 PM, Mike Rapoport wrote:

...

> >> diff --git a/mm/memblock.c b/mm/memblock.c
> >> index 3abf2c3fea7f..93f8a9c8428d 100644
> >> --- a/mm/memblock.c
> >> +++ b/mm/memblock.c
> >> @@ -1740,6 +1740,7 @@ bool __init_memblock memblock_is_memory(phys_addr_t addr)
> >>  {
> >>  	return memblock_search(&memblock.memory, addr) != -1;
> >>  }
> >> +EXPORT_SYMBOL(memblock_is_memory);
> > 
> > Please make it inside #ifdef CONFIG_ARCH_MEMBLOCK
> CONFIG_ARCH_KEEP_MEMBLOCK ?

Yeah, _KEEP went away somehow :)

> Wrap it around the EXPORT_SYMBOL() or the entire function
> memblock_is_memory().

EXPORT_SYMBOL(). Otherwise we'll have exported __init function.
 
-- 
Sincerely yours,
Mike.


From andrew at lunn.ch  Thu Apr 22 13:20:48 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 22 Apr 2021 14:20:48 +0200
Subject: [PATCH net-next 14/14] net: ethernet: mtk_eth_soc: use iopoll.h
 macro for DMA init
In-Reply-To: <20210422040914.47788-15-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-15-ilya.lipnitskiy@gmail.com>
Message-ID: <YIFqIJpAJKUrXQVS@lunn.ch>

On Wed, Apr 21, 2021 at 09:09:14PM -0700, Ilya Lipnitskiy wrote:
> Replace a tight busy-wait loop without a pause with a standard
> readx_poll_timeout_atomic routine with a 5 us poll period.
> 
> Tested by booting a MT7621 device to ensure the driver initializes
> properly.
> 
> Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++------------
>  drivers/net/ethernet/mediatek/mtk_eth_soc.h |  2 +-
>  2 files changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 8c863322587e..720d73d0c007 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2037,25 +2037,22 @@ static int mtk_set_features(struct net_device *dev, netdev_features_t features)
>  /* wait for DMA to finish whatever it is doing before we start using it again */
>  static int mtk_dma_busy_wait(struct mtk_eth *eth)
>  {
> -	unsigned long t_start = jiffies;
> +	u32 val;
> +	int ret;
> +	unsigned int reg;

Nit:

Reverse christmass tree.

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Andrew


From andrew at lunn.ch  Thu Apr 22 13:23:52 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 22 Apr 2021 14:23:52 +0200
Subject: [PATCH net-next 00/14] mtk_eth_soc: fixes and performance
 improvements
In-Reply-To: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
Message-ID: <YIFq2NIhdMWTDshX@lunn.ch>

On Wed, Apr 21, 2021 at 09:09:00PM -0700, Ilya Lipnitskiy wrote:
> Most of these changes come from OpenWrt where they have been present and
> tested for months.
> 
> First three patches are bug fixes. The rest are performance
> improvements. The last patch is a cleanup to use the iopoll.h macro for
> busy-waiting instead of a custom loop.

Do you have any benchmark numbers you can share?

   Andrew


From maz at kernel.org  Thu Apr 22 13:27:06 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 22 Apr 2021 13:27:06 +0100
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
References: <20210416062217.25157-1-heying24@huawei.com>
 <87y2dis4d7.wl-maz@kernel.org>
 <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
Message-ID: <875z0eijxh.wl-maz@kernel.org>

On Sat, 17 Apr 2021 03:01:54 +0100,
He Ying <heying24 at huawei.com> wrote:
> 
> Hello Marc,
> 
> 
> ? 2021/4/16 22:15, Marc Zyngier ??:
> > [+ Mark]
> > 
> > On Fri, 16 Apr 2021 07:22:17 +0100,
> > He Ying <heying24 at huawei.com> wrote:
> >> We found this problem in our kernel src tree:
> >> 
> >> [   14.816231] ------------[ cut here ]------------
> >> [   14.816231] kernel BUG at irq.c:99!
> >> [   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
> >> [   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
> >> [   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95-1.h1.AOS2.0.aarch64 #14
> >> [   14.816233] Hardware name: evb (DT)
> >> [   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
> >> [   14.816234] pc : asm_nmi_enter+0x94/0x98
> >> [   14.816235] lr : asm_nmi_enter+0x18/0x98
> >> [   14.816235] sp : ffff000008003c50
> >> [   14.816235] pmr_save: 00000070
> >> [   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
> >> [   14.816238] x27: 0000000000000000 x26: ffff000008004000
> >> [   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
> >> [   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
> >> [   14.816241] x21: ffff000008003da0 x20: 0000000000000060
> >> [   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
> >> [   14.816243] x17: 0000000000000008 x16: 003d090000000000
> >> [   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
> >> [   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
> >> [   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
> >> [   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
> >> [   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
> >> [   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
> >> [   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
> >> [   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
> >> [   14.816251] Call trace:
> >> [   14.816251]  asm_nmi_enter+0x94/0x98
> >> [   14.816251]  el1_irq+0x8c/0x180
> >> [   14.816252]  gic_handle_irq+0xbc/0x2e4
> >> [   14.816252]  el1_irq+0xcc/0x180
> >> [   14.816253]  arch_timer_handler_virt+0x38/0x58
> >> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> >> [   14.816253]  generic_handle_irq+0x34/0x50
> >> [   14.816254]  __handle_domain_irq+0x68/0xc0
> >> [   14.816254]  gic_handle_irq+0xf8/0x2e4
> >> [   14.816255]  el1_irq+0xcc/0x180
> >> [   14.816255]  arch_cpu_idle+0x34/0x1c8
> >> [   14.816255]  default_idle_call+0x24/0x44
> >> [   14.816256]  do_idle+0x1d0/0x2c8
> >> [   14.816256]  cpu_startup_entry+0x28/0x30
> >> [   14.816256]  rest_init+0xb8/0xc8
> >> [   14.816257]  start_kernel+0x4c8/0x4f4
> >> [   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
> >> [   14.816258] Modules linked in: start_dp(O) smeth(O)
> >> [   15.103092] ---[ end trace 701753956cb14aa8 ]---
> >> [   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
> >> [   15.103099] SMP: stopping secondary CPUs
> >> [   15.103100] Kernel Offset: disabled
> >> [   15.103100] CPU features: 0x36,a2400218
> >> [   15.103100] Memory Limit: none
> > Urgh...
> > 
> >> Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
> >> patches but doesn't support nested NMI. Its top relative commit is
> >> commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs").
> > Can you please reproduce it with mainline and without any backport?
> > It is hard to reason about something that isn't a vanilla kernel.
> 
> I think our kernel is quite like v5.3 mainline. Reproducing it in
> v5.3 mainline may be a little difficult for us because our product
> needs some more self developed patches to work.

I don't really care about 5.3. What I care about is the tip of the
tree, and anything we fix there can trickle down to the previous
stable releases.

> >> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
> >> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
> >> means an interrupt preempts the other one and the new one is an NMI.
> >> Furthermore, by adding some prints, we find the first irq also calls
> >> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
> >> is 1023. It enables irq by calling gic_arch_enable_irqs() in
> >> gic_handle_irq(). At this moment, the second irq preempts the first irq
> >> and it's an NMI but current context is already in nmi. So that may be
> >> the problem.
> > I'm not sure I get it. From the stack trace, I see this:
> > 
> > [   14.816251]  asm_nmi_enter+0x94/0x98
> > [   14.816251]  el1_irq+0x8c/0x180			(C)
> > [   14.816252]  gic_handle_irq+0xbc/0x2e4
> > [   14.816252]  el1_irq+0xcc/0x180			(B)
> > [   14.816253]  arch_timer_handler_virt+0x38/0x58
> > [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> > [   14.816253]  generic_handle_irq+0x34/0x50
> > [   14.816254]  __handle_domain_irq+0x68/0xc0
> > [   14.816254]  gic_handle_irq+0xf8/0x2e4
> > [   14.816255]  el1_irq+0xcc/0x180			(A)
> > 
> > which indicates that we preempted a timer interrupt (A) with another
> > IRQ (B), itself immediately preempted by another IRQ (C)? That's
> > indeed at least one too many.
> > 
> > Can you please describe for each of (A), (B) and (C) whether they are
> > spurious or not, what their priorities are if they aren't spurious?
> 
> Yes. I ignored interrupt (A). (B) is spurious and its priority is
> 0xa0 and PMR is 0x70. (C) is an NMI and its priority is 0x20. Note
> that GIC_PRIO_IRQON is 0xe0, GIC_PRIO_IRQOFF is 0x60,
> GICD_INT_DEF_PRI is 0xa0 and GICD_INT_NMI_PRI is 0x20 in our kernel.

If (B) is spurious (aka ICC_IAR1R_EL1 return 1023), then its
"priority" doesn't really exist, and I don't really get what you mean
by "its priority is 0xa0".  ICC_RPR_EL1 shouldn't change when Ack-ing
a spurious interrupt, because there is no change in GIC state at all.

And if PMR is 0x70 at the point where you get (B), then I really can't
see how you can get an interrupt of priority 0xa0 anyway.



> >> In my opinion, when handling spurious interrupts, we shouldn't enable irqs.
> >> My reason is that for spurious interrupts we may enter nmi context in
> >> el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
> >> at this time, another NMI may happen and preempt this spurious interrupt
> >> but the context is already in nmi. That causes a bug on if nested NMI is
> >> not supported. Even for nested nmi, I think it's not a normal scenario.
> > I would tend to agree that this isn't great. Actually, I'd probably
> > move the check for a spurious interrupt right after the read of
> > ICC_IAR1_EL1, because there is no real need to do anything else at
> > that point.
> 
> So, we don't need to check NMI for spurious interrupts? Do you mean
> that spurious interrupts' can't be NMIs? Or even spurious interrups
> are NMIs, we shouldn't do anything for them? If so, I will move the
> check after the read of ICC_IAR1_EL1 and send a V2.

Spurious interrupts are not interrupts at all. It is either a level
interrupt that has been retired before being handled, or some other
transient effect (like an interrupt being moved from one CPU to
another), or even flaky HW. So doing anything based on a spurious
interrupt is definitely a potential bug, and I suggest this:

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index eb0ee356a629..00404024d7cd 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -648,6 +648,10 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 
 	irqnr = gic_read_iar();
 
+	/* Check for special IDs first */
+	if ((irqnr >= 1020 && irqnr <= 1023))
+		return;
+
 	if (gic_supports_nmi() &&
 	    unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
 		gic_handle_nmi(irqnr, regs);
@@ -659,10 +663,6 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 		gic_arch_enable_irqs();
 	}
 
-	/* Check for special IDs first */
-	if ((irqnr >= 1020 && irqnr <= 1023))
-		return;
-
 	if (static_branch_likely(&supports_deactivate_key))
 		gic_write_eoir(irqnr);
 	else

[...]

> In my opinion, since commit 17ce302f3117 ("arm64: Fix interrupt
> tracing in the presence of NMIs"), spurious interrups can enter nmi
> context in interrupt entry because PMR can be GIC_PRIO_IRQOFF for
> spurious interrupts. That means test_irqs_unmasked is not 0 and
> asm_nmi_enter is called.
> 
> ?? (some el1_irq entry code from v5.3)
> ?? test_irqs_unmasked? res=x0, pmr=x20
> ?? cbz x0, 1f
> ?? bl asm_nmi_enter

That code has significantly changed upstream, and is now in C. I think
it still do the same thing though.

> 
> And it then calls gic_handle_irq(). It doesn't call gic_handle_nmi()
> because its priority is not GICD_INT_NMI_PRI.
> 
> Then it enables irqs. If at that point another NMI comes and
> preempts it, which means NMI occurs in nmi context. That may cause a
> bug on if nested NMI is not supported.
> 
> ?? (some gic_handle_irq code from v5.3)
> 
> ?? irqnr = gic_read_iar();
> 
> ?? if (gic_supports_nmi() &&
> ? ? ?? unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
> ?????????? gic_handle_nmi(irqnr,
> regs);?????????????????????????????????? (C)
> ?????????? return;
> ?? }
> 
> ?? if (gic_prio_masking_enabled()) {
> ???????? gic_pmr_mask_irqs();
> gic_arch_enable_irqs(); (D)
> ?? }

I believe the above patch would fix the spurious interrupt issue you
have experienced. Please let me know, and post a v2 if this works for
you.

Thanks,

	M.

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


From nbd at nbd.name  Thu Apr 22 13:33:31 2021
From: nbd at nbd.name (Felix Fietkau)
Date: Thu, 22 Apr 2021 14:33:31 +0200
Subject: [PATCH net-next 05/14] net: ethernet: mtk_eth_soc: reduce MDIO
 bus access latency
In-Reply-To: <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>
Message-ID: <d96206db-96e2-1eb7-6b19-47c9596ccfea@nbd.name>


On 2021-04-22 06:09, Ilya Lipnitskiy wrote:
> From: Felix Fietkau <nbd at nbd.name>
> 
> usleep_range often ends up sleeping much longer than the 10-20us provided
> as a range here. This causes significant latency in mdio bus acceses,
> which easily adds multiple seconds to the boot time on MT7621 when polling
> DSA slave ports.
> 
> Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
> take much time
> 
> Signed-off-by: Felix Fietkau <nbd at nbd.name>
> [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
I still prefer the cond_resched() variant. On a fully loaded system, I'd
prefer to let the MDIO access take longer instead of wasting cycles on
udelay.

- Felix


From maz at kernel.org  Thu Apr 22 13:48:03 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 22 Apr 2021 13:48:03 +0100
Subject: [PATCH 0/5] perf: oprofile spring cleanup
In-Reply-To: <20210414134409.1266357-1-maz@kernel.org>
References: <20210414134409.1266357-1-maz@kernel.org>
Message-ID: <161909565607.1722628.9529859651633898388.b4-ty@kernel.org>

On Wed, 14 Apr 2021 14:44:04 +0100, Marc Zyngier wrote:
> This small series builds on top of the work that was started with [1].
> 
> It recently became apparent that KVM/arm64 is the last bit of the
> kernel that still uses perf_num_counters().
> 
> As I went ahead to address this, it became obvious that all traces of
> oprofile had been eradicated from all architectures but arm64, s390
> and sh (plus a bit of cruft in the core perf code). With KVM fixed,
> perf_num_counters() and perf_pmu_name() are finally gone.
> 
> [...]

Applied to kvm-arm64/kill_oprofile_dependency, thanks!

[1/5] KVM: arm64: Divorce the perf code from oprofile helpers
      commit: 5421db1be3b11c5e469cce3760d5c8a013a90f2c
[2/5] arm64: Get rid of oprofile leftovers
      commit: e9c74a686a45e54b2e1c4586b14c84f3ee2f2014
[3/5] s390: Get rid of oprofile leftovers
      commit: 8c3f7913a106aa8b94d331cb59709c84a9a1d55b
[4/5] sh: Get rid of oprofile leftovers
      commit: ac21ecf5ad32b89909bee2b50161ce93d6462b7d
[5/5] perf: Get rid of oprofile leftovers
      commit: 7f318847a0f37b96d8927e8d30ae7b8f149b11f1

Cheers,

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




From will at kernel.org  Thu Apr 22 13:48:50 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 13:48:50 +0100
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
Message-ID: <20210422124849.GA1521@willie-the-truck>

[+Eric as he actually understands how this is supposed to work]

On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
> arm64_notify_segfault() was used to force a SIGSEGV in all error cases
> in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
> There is now a better sig handler to use which does not search the VMA
> address space and return a slightly incorrect error code.  Restore the
> older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
> the case of !access_ok(), simply return SIGSEGV with si_code
> SEGV_ACCERR.
> 
> This change requires exporting arm64_notfiy_die() to the arm64 traps.h
> 
> Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
> failing to deliver signal)
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
>  arch/arm64/include/asm/traps.h |  2 ++
>  arch/arm64/kernel/signal.c     |  8 ++++++--
>  arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
>  3 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> index 54f32a0675df..9b76144fcba6 100644
> --- a/arch/arm64/include/asm/traps.h
> +++ b/arch/arm64/include/asm/traps.h
> @@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
>  void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
>  void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
> +void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
> +		      int sicode, unsigned long far, int err);
>  
>  /*
>   * Move regs->pc to next instruction and do necessary setup before it
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 6237486ff6bb..9fde6dc760c3 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
>  	frame = (struct rt_sigframe __user *)regs->sp;
>  
>  	if (!access_ok(frame, sizeof (*frame)))
> -		goto badframe;
> +		goto e_access;
>  
>  	if (restore_sigframe(regs, frame))
>  		goto badframe;
> @@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
>  	return regs->regs[0];
>  
>  badframe:
> -	arm64_notify_segfault(regs->sp);
> +	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
> +	return 0;
> +
> +e_access:
> +	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
>  	return 0;

This seems really error-prone to me, but maybe I'm just missing some
context. What's the rule for reporting an si_code of SI_KERNEL vs
SEGV_ACCERR, and is the former actually valid for SIGSEGV?

With this change, pointing the (signal) stack to a kernel address will
result in SEGV_ACCERR but pointing it to something like a PROT_NONE user
address will give SI_KERNEL (well, assuming that we manage to deliver
the SEGV somehow). I'm having a hard time seeing why that's a useful
distinction to make..

If it's important to get this a particular way around, please can you
add some selftests?

Will


From will at kernel.org  Thu Apr 22 13:53:34 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 13:53:34 +0100
Subject: [PATCH 3/3] arch/arm64/kernel/traps: Use find_vma_intersection()
 in traps for setting si_code
In-Reply-To: <20210420165001.3790670-3-Liam.Howlett@Oracle.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-3-Liam.Howlett@Oracle.com>
Message-ID: <20210422125334.GB1521@willie-the-truck>

On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
> find_vma() will continue to search upwards until the end of the virtual
> memory space.  This means the si_code would almost never be set to
> SEGV_MAPERR even when the address falls outside of any VMA.  The result
> is that the si_code is not reliable as it may or may not be set to the
> correct result, depending on where the address falls in the address
> space.
> 
> Using find_vma_intersection() allows for what is intended by only
> returning a VMA if it falls within the range provided, in this case a
> window of 1.
> 
> Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
>  arch/arm64/kernel/traps.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index a05d34f0e82a..a44007904a64 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
>  void arm64_notify_segfault(unsigned long addr)
>  {
>  	int code;
> +	unsigned long ut_addr = untagged_addr(addr);
>  
>  	mmap_read_lock(current->mm);
> -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
>  		code = SEGV_MAPERR;
>  	else
>  		code = SEGV_ACCERR;

I'm not seeing how this addresses VM_GROWSDOWN as Catalin mentioned before.

Will


From yangyicong at hisilicon.com  Thu Apr 22 13:54:47 2021
From: yangyicong at hisilicon.com (Yicong Yang)
Date: Thu, 22 Apr 2021 20:54:47 +0800
Subject: [PATCH RESEND 0/4] Add support for HiSilicon PCIe Tune and Trace
 device
In-Reply-To: <20210422034929.GA13004@leoy-ThinkPad-X240s>
References: <1618654631-42454-1-git-send-email-yangyicong@hisilicon.com>
 <8735vpf20c.fsf@ashishki-desk.ger.corp.intel.com>
 <628f2f4a-03ce-a646-bf27-d6836baca425@hisilicon.com>
 <20210422034929.GA13004@leoy-ThinkPad-X240s>
Message-ID: <955f89c6-a330-fd64-f530-43435f5cafcb@hisilicon.com>

On 2021/4/22 11:49, Leo Yan wrote:
> On Mon, Apr 19, 2021 at 09:03:18PM +0800, Yicong Yang wrote:
>> On 2021/4/17 21:56, Alexander Shishkin wrote:
>>> Yicong Yang <yangyicong at hisilicon.com> writes:
>>>
>>>> The reason for not using perf is because there is no current support
>>>> for uncore tracing in the perf facilities.
>>>
>>> Not unless you count
>>>
>>> $ perf list|grep -ic uncore
>>> 77
>>>
>>
>> these are uncore events probably do not support sampling.
>>
>> I tried on x86:
>>
>> # ./perf record -e uncore_imc_0/cas_count_read/
>> Error:
>> The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (uncore_imc_0/cas_count_read/).
>> /bin/dmesg | grep -i perf may provide additional information.
>>
>> For HiSilicon uncore PMUs, we don't support uncore sampling:
>>
>> 'The current driver does not support sampling. So "perf record" is unsupported. ' [1]
>>
>> and also in another PMU:
>>
>> 'PMU doesn't support process specific events and cannot be used in sampling mode.' [2]
>>
>> [1] Documentation/admin-guide/perf/hisi-pmu.rst
>> [2] Documentation/admin-guide/perf/arm_dsu_pmu.rst
> 
> I did some debugging for this, and yes, it's related with the event
> doesn't support sampling for these x86 uncore events.
> 
> So I can use below commands for the uncore event
> 'uncore_imc/data_reads/' in my experiment:
> 
>   # perf record -e 'uncore_imc/data_reads/' --no-samples -- ls
>   # perf stat -e 'uncore_imc/data_reads/' -- ls
> 
> For your case, I think you need to write the callback
> pmu::event_init(), it should not forbid any tracing even if set
> sampling, just like other perf event drive for support AUX tracing.
> 

thanks for the hint! I didn't know much about perf so I only do
the basic test. will further investigate on this.

>>>> We have our own format
>>>> of data and don't need perf doing the parsing.
>>>
>>> Perf has AUX buffers, which are used for all kinds of own formats.
>>>
>>
>> ok. we thought perf will break the data format but AUX buffers seems won't.
>> do we need to add full support for tracing as well as parsing or it's ok for
>> not parsing it through perf?
> 
> IMHO, this could divide into two parts.  The first part is to enable
> perf drive with support AUX tracing, and perf tool can capture the trace
> data.  The second part is to add the decoder in the perf tool so that
> the developers can *consume* the trace data; for the decoder, you
> could refer the codes:
> 
>   tools/perf/util/intel-pt-decoder/
>   tools/perf/util/cs-etm-decoder/
> 
> Or Arm SPE case:
> 
>   tools/perf/util/arm-spe-decoder/
> 

will refer to these implementation to see how to add the decoder for our
traced data. very detailed guidance!

>>>> A similar approach for implementing this function is ETM, which use
>>>> sysfs for configuring and a character device for dumping data.
>>>
>>> And also perf. One reason ETM has a sysfs interface is because the
>>> driver predates perf's AUX buffers. Can't say if it's the only
>>> reason. I'm assuming you're talking about Coresight ETM.
> 
> I am not the best person to give background for this.  Mathieu or Mike
> could give more info for this.  From my undersanding, Sysfs nodes can
> be used as knobs for configuration, but it's difficult for profiling.
> 

as explained by the maintainers that there are some historical reasons for
having sysfs interfaces for ETM as there is no perf AUX buffers at
beginning. I thought sysfs interface as an option but perf AUX buffer
is better as suggested.

> Let's think about for the profiling, if one developer uses the Sysfs
> for the setting and read out the trace data, these informations are
> discrete.  If another developer wants to review the profiling result,
> then all these info need to be shared together.
> 

ok. make sense to me.

> So we can benefit much from the perf tool for the usage, since all the
> profiling context will be gathered (DSOs, hardware configuration which
> can be saved into metadata), so the final profiling file can be easily
> shared and more friendly for reviewing.
> 

ok. it will be beneficial if we use perf for both tracing and decoding,
as we'll also get addition information attached to the trace data.

Considering we have two functions: tracing and tuning. For tracing we
can make use of perf AUX buffer but for tuning, I still cannot see how to
make use of perf. So probably we can make tuning go through sysfs?
And Daniel suggested so.

Appreciate for the suggestion and guidance!

Regards,
Yicong

> Thanks,
> Leo
> 
> .
> 



From will at kernel.org  Thu Apr 22 13:59:04 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 13:59:04 +0100
Subject: [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal
 generation
In-Reply-To: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
Message-ID: <20210422125903.GD1521@willie-the-truck>

On Tue, Apr 20, 2021 at 04:50:12PM +0000, Liam Howlett wrote:
> arm64_notify_segfault() was written to decide on the si_code from the
> assembly emulation of the swp_handler(), but was also used for the
> signal generation from failed access_ok() and unaligned instructions.
> 
> When access_ok() fails, there is no need to search for the offending
> address in the VMA space.  Instead, simply set the error to SIGSEGV with
> si_code SEGV_ACCERR.
> 
> Change the return code from emulate_swpX() when there is an unaligned
> pointer so the caller can differentiate from the EFAULT.  It is
> unnecessary to search the VMAs in the case of an unaligned pointer.
> This change uses SIGSEGV and SEGV_ACCERR instead of SIGBUS to keep with
> what was returned before.
> 
> Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> ---
>  arch/arm64/kernel/armv8_deprecated.c | 20 +++++++++++++-------

Can you give an example of something that is fixed by this, please? At first
glance, it doesn't look like it changes the user-visible behaviour.

We should also be compatible with arch/arm/ here (see set_segfault()).

Will


From qperret at google.com  Thu Apr 22 13:59:30 2021
From: qperret at google.com (Quentin Perret)
Date: Thu, 22 Apr 2021 12:59:30 +0000
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
 <YH/ixPnHMxNo08mJ@google.com>
 <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>
Message-ID: <YIFzMkW+tXonTf0K@google.com>

On Wednesday 21 Apr 2021 at 07:33:52 (-0700), Florian Fainelli wrote:
> It is not, otherwise I would have noticed earlier, can you try the same
> thing that happens on my platform with a reserved region (without
> no-map) adjacent to a reserved region with 'no-map'?

I just tried, but still no luck. FTR, I tried to reproduce your setup
with the following DT:

        memory at 40000000 {
                reg = <0x00 0x40000000 0x01 0x00>;
                device_type = "memory";
        };

        reserved-memory {
                #address-cells = <2>;
                #size-cells = <2>;
                ranges;

                foo at fdfff000{
                        reg = <0x00 0xfdfff000 0x0 0x1000>;
                };
                bar at fe000000{
                        reg = <0x00 0xfe000000 0x0 0x2000000>;
                        no-map;
                };
        };

And with 5.4.102 and 5.10.31 I get the following in /proc/iomem

<...>
40000000-fdffffff : System RAM
  40080000-412cffff : Kernel code
  412d0000-417affff : reserved
  417b0000-419f8fff : Kernel data
  48000000-48008fff : reserved
  f7c00000-fdbfffff : reserved
  fdfff000-fdffffff : reserved
fe000000-ffffffff : reserved
100000000-13fffffff : System RAM
<...>

which looks about right. I'll keep trying a few other things.

Thanks,
Quentin


From will at kernel.org  Thu Apr 22 13:59:44 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 13:59:44 +0100
Subject: [PATCH] arm64: alternative: simplify passing alt_region
In-Reply-To: <20210416163032.10857-1-mark.rutland@arm.com>
References: <20210416163032.10857-1-mark.rutland@arm.com>
Message-ID: <20210422125944.GE1521@willie-the-truck>

On Fri, Apr 16, 2021 at 05:30:32PM +0100, Mark Rutland wrote:
> In __apply_alternatives() we take a pointer to void which we later
> assign to a pointer to struct alt_region. As all callers are passing a
> pointer to struct alt_region to begin with, it's simpler and more robust
> to take a pointer to struct alt region, so let's do so and avoid the
> need for a temporary variable.
> 
> 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/kernel/alternative.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From will at kernel.org  Thu Apr 22 14:01:05 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 14:01:05 +0100
Subject: [PATCH] arm64: remove HAVE_DEBUG_BUGVERBOSE
In-Reply-To: <20210418215231.563d4b72@xhacker>
References: <20210418215231.563d4b72@xhacker>
Message-ID: <20210422130105.GF1521@willie-the-truck>

On Sun, Apr 18, 2021 at 09:52:31PM +0800, Jisheng Zhang wrote:
> From: Jisheng Zhang <jszhang at kernel.org>
> 
> After commit 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic
> BUG traps"), arm64 has switched to generic BUG implementation, so
> there's no need to select HAVE_DEBUG_BUGVERBOSE.
> 
> Signed-off-by: Jisheng Zhang <jszhang at kernel.org>
> ---
>  arch/arm64/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Acked-by: Will Deacon <will at kernel.org>

Will


From qperret at google.com  Thu Apr 22 14:03:12 2021
From: qperret at google.com (Quentin Perret)
Date: Thu, 22 Apr 2021 13:03:12 +0000
Subject: [v5.4 stable] arm: stm32: Regression observed on "no-map"
 reserved memory region
In-Reply-To: <498b8759-1a70-d80f-3a4d-39042b4f608e@gmail.com>
References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com>
 <CAL_JsqKGG8E9Y53+az+5qAOOGiZRAA-aD-1tKB-hcOp+m3CJYw@mail.gmail.com>
 <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com>
 <CAL_Jsq+LUPZFhXd+j-xM67rZB=pvEvZM+1sfckip0Lqq02PkZQ@mail.gmail.com>
 <CAMj1kXE2Mgr9CsAMnKXff+96xhDaE5OLeNhypHvpN815vZGZhQ@mail.gmail.com>
 <d7f9607a-9fcb-7ba2-6e39-03030da2deb0@gmail.com>
 <YH/ixPnHMxNo08mJ@google.com>
 <cc8f96a4-6c85-b869-d3cf-5dc543982054@gmail.com>
 <498b8759-1a70-d80f-3a4d-39042b4f608e@gmail.com>
Message-ID: <YIF0EIXylUJzIsTS@google.com>

On Wednesday 21 Apr 2021 at 08:17:28 (-0700), Florian Fainelli wrote:
> 5.10.31 works correctly and shows the following for my platform:
> 
> 40000000-fdffefff : System RAM
>   40200000-40eaffff : Kernel code
>   40eb0000-4237ffff : reserved
>   42380000-425affff : Kernel data
>   45000000-450fffff : reserved
>   47000000-4704ffff : reserved
>   4761e000-47624fff : reserved
>   f8c00000-fdbfffff : reserved
> fdfff000-ffffffff : reserved
> 100000000-13fffffff : System RAM
>   13b000000-13effffff : reserved
>   13f114000-13f173fff : reserved
>   13f174000-13f774fff : reserved
>   13f775000-13f7e8fff : reserved
>   13f7eb000-13f7ecfff : reserved
>   13f7ed000-13f7effff : reserved
>   13f7f0000-13fffffff : reserved

OK, so if we're confident this works from 5.10 onwards, I would suggest
to follow Ard's original suggestion to revert this patch from older
LTSes as we're clearly missing something there.

Thanks,
Quentin


From lkp at intel.com  Thu Apr 22 14:04:46 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 22 Apr 2021 21:04:46 +0800
Subject: [xlnx:master 11930/12154] core.c:undefined reference to
 `dwc3_gadget_exit_hibernation'
Message-ID: <202104222140.QR1n940a-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   bcd80b4c331c5d55de978ab0b2f6181a8aea3434
commit: 719080ff0022e05bb4cb8043d62739feebcd8dbc [11930/12154] usb: dwc3: gadget: Add hibernation support when operating in gadget mode
config: i386-randconfig-c004-20210421 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/719080ff0022e05bb4cb8043d62739feebcd8dbc
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 719080ff0022e05bb4cb8043d62739feebcd8dbc
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   ld: drivers/usb/dwc3/core.o: in function `dwc3_suspend':
>> core.c:(.text+0x146b): undefined reference to `dwc3_gadget_exit_hibernation'
   ld: drivers/usb/dwc3/core.o: in function `dwc3_remove':
   core.c:(.text+0x152a): undefined reference to `dwc3_gadget_exit_hibernation'
   ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_read_offset':
   rtc-zynqmp.c:(.text+0x19): undefined reference to `__divdi3'
   ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_set_offset':
   rtc-zynqmp.c:(.text+0x1ad): undefined reference to `__divdi3'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47548 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210422/c60664c7/attachment-0001.gz>

From jbx6244 at gmail.com  Thu Apr 22 14:13:38 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Thu, 22 Apr 2021 15:13:38 +0200
Subject: [PATCH 1/3] dt-bindings: iommu: rockchip: Convert IOMMU to DT
 schema
In-Reply-To: <20210422072442.111070-2-benjamin.gaignard@collabora.com>
References: <20210422072442.111070-1-benjamin.gaignard@collabora.com>
 <20210422072442.111070-2-benjamin.gaignard@collabora.com>
Message-ID: <c2087946-0dfb-b66e-bcb9-5bba5fd098bf@gmail.com>

Hi Benjamin,

Please check robh/dtbs-check failed build log at

https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210422072442.111070-2-benjamin.gaignard at collabora.com/

make ARCH=arm64 dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml


make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

Test if all notifications are gone.

===

YAML also checks extra properties like "power-domains" not yet included
but needed for rk3568.
Add them in a separate patch.

===

rk3229-evb.dt.yaml: iommu at 20030480: 'iommu-cells' does not match any of
the regexes

Change a rk322x.dtsi property to #iommu-cells in a separate patch.

===

rk3229-xms6.dt.yaml: iommu at 20030480: reg: [[537068672, 64], [537068736,
64]] is too long

Change reg minItems maxItems.

===

Johan

On 4/22/21 9:24 AM, Benjamin Gaignard wrote:
> Convert Rockchip IOMMU to DT schema
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> ---
>  .../bindings/iommu/rockchip,iommu.txt         | 38 ----------
>  .../bindings/iommu/rockchip,iommu.yaml        | 76 +++++++++++++++++++
>  2 files changed, 76 insertions(+), 38 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>  create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> deleted file mode 100644
> index 6ecefea1c6f9..000000000000
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -Rockchip IOMMU
> -==============
> -
> -A Rockchip DRM iommu translates io virtual addresses to physical addresses for
> -its master device.  Each slave device is bound to a single master device, and
> -shares its clocks, power domain and irq.
> -
> -Required properties:
> -- compatible      : Should be "rockchip,iommu"
> -- reg             : Address space for the configuration registers
> -- interrupts      : Interrupt specifier for the IOMMU instance
> -- interrupt-names : Interrupt name for the IOMMU instance
> -- #iommu-cells    : Should be <0>.  This indicates the iommu is a
> -                    "single-master" device, and needs no additional information
> -                    to associate with its master device.  See:
> -                    Documentation/devicetree/bindings/iommu/iommu.txt
> -- clocks          : A list of clocks required for the IOMMU to be accessible by
> -                    the host CPU.
> -- clock-names     : Should contain the following:
> -	"iface" - Main peripheral bus clock (PCLK/HCL) (required)
> -	"aclk"  - AXI bus clock (required)
> -
> -Optional properties:
> -- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> -			       Some mmu instances may produce unexpected results
> -			       when the reset operation is used.
> -
> -Example:
> -
> -	vopl_mmu: iommu at ff940300 {
> -		compatible = "rockchip,iommu";
> -		reg = <0xff940300 0x100>;
> -		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> -		interrupt-names = "vopl_mmu";
> -		clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
> -		clock-names = "aclk", "iface";
> -		#iommu-cells = <0>;
> -	};
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> new file mode 100644
> index 000000000000..ab128f8e4c73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -0,0 +1,76 @@

> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

GPL-2.0
This is a conversion of an existing document.

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip IOMMU
> +
> +maintainers:
> +  - Simon Xue <xxm at rock-chips.com>

  - Heiko Stuebner <heiko at sntech.de>

Add someone that can respond in a short time in case rob+dt wants to
delete something.

> +
> +description: |+
> +  A Rockchip DRM iommu translates io virtual addresses to physical addresses for

> +  its master device. Each slave device is bound to a single master device, and

No comma "," before "and"

> +  shares its clocks, power domain and irq.
> +
> +  For information on assigning IOMMU controller to its peripheral devices,
> +  see generic IOMMU bindings.
> +
> +properties:
> +  compatible:
> +    const: rockchip,iommu
> +
> +  reg:

> +    maxItems: 1

minItems: 1
maxItems: 2


> +
> +  interrupts:
> +    maxItems: 1
> +
> +  interrupt-names:
> +    maxItems: 1
> +
> +  clocks:
> +    items:
> +      - description: Core clock
> +      - description: Interface clock
> +
> +  clock-names:
> +    items:
> +      - const: aclk
> +      - const: iface
> +
> +  "#iommu-cells":
> +    const: 0
> +

  power-domains:
    maxItems: 1

Add in separate patch for review by rob+bt

> +  rockchip,disable-mmu-reset:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description: |

> +      Don't use the mmu reset operation.

Do not use ....

The use of "'" in a YAML description gives problems in some text
highlighters. Try to avoid.

> +      Some mmu instances may produce unexpected results
> +      when the reset operation is used.
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - "#iommu-cells"
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rk3399-cru.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    vopl_mmu: iommu at ff940300 {
> +      compatible = "rockchip,iommu";
> +      reg = <0xff940300 0x100>;
> +      interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> +      interrupt-names = "vopl_mmu";
> +      clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
> +      clock-names = "aclk", "iface";
> +      #iommu-cells = <0>;
> +    };
> 



From amanieu at gmail.com  Thu Apr 22 14:14:30 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Thu, 22 Apr 2021 14:14:30 +0100
Subject: [RFC PATCH v3 6/8] arm64: Add a compat syscall flag to thread_info
In-Reply-To: <859ad8a943484270b95bab5073a5c031@AcuMS.aculab.com>
References: <20210421190207.1803139-1-amanieu@gmail.com>
 <20210421190207.1803139-7-amanieu@gmail.com>
 <859ad8a943484270b95bab5073a5c031@AcuMS.aculab.com>
Message-ID: <CA+y5pbTozq75wpqoO6iryiM+wJPzrn5CvwSxS+_Zc2xRzJzJwg@mail.gmail.com>

> Wouldn't it be better to ensure that a 'compat_task'
> always has aarch64_compat_syscall set.

Good point, I'll do that in the next version of the patch.


From andrew-sh.cheng at mediatek.com  Thu Apr 22 14:34:04 2021
From: andrew-sh.cheng at mediatek.com (andrew-sh.cheng)
Date: Thu, 22 Apr 2021 21:34:04 +0800
Subject: [PATCH V8 1/8] PM / devfreq: Add cpu based scaling support to
 passive_governor
In-Reply-To: <cfdd3973-e4a7-8c09-8a7e-57118a7a3b9b@samsung.com>
References: <1616499241-4906-1-git-send-email-andrew-sh.cheng@mediatek.com>
 <CGME20210323113411epcas1p3b4367563007ca91c30201d7fc225bb67@epcas1p3.samsung.com>
 <1616499241-4906-2-git-send-email-andrew-sh.cheng@mediatek.com>
 <233a3bd6-7ab1-5da2-9184-a745eb253d86@samsung.com>
 <1617177820.15067.1.camel@mtksdaap41>
 <2ae8604d-0da6-4243-1b92-81b3917d7d48@samsung.com>
 <cad52436-b291-05bf-236f-7b7cb1fdbbff@samsung.com>
 <1617195800.18432.3.camel@mtksdaap41>
 <fbb6c44b-eb77-14ce-9175-3f06030e6e0c@samsung.com>
 <cfdd3973-e4a7-8c09-8a7e-57118a7a3b9b@samsung.com>
Message-ID: <1619098444.4507.1.camel@mtksdaap41>

On Thu, 2021-04-08 at 11:47 +0900, Chanwoo Choi wrote:
> On 4/1/21 9:16 AM, Chanwoo Choi wrote:
> > On 3/31/21 10:03 PM, andrew-sh.cheng wrote:
> >> On Wed, 2021-03-31 at 17:35 +0900, Chanwoo Choi wrote:
> >>> On 3/31/21 5:27 PM, Chanwoo Choi wrote:
> >>>> Hi,
> >>>>
> >>>> On 3/31/21 5:03 PM, andrew-sh.cheng wrote:
> >>>>> On Thu, 2021-03-25 at 17:14 +0900, Chanwoo Choi wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> You are missing to add these patches to linux-pm mailing list.
> >>>>>> Need to send them to linu-pm ML.
> >>>>>>
> >>>>>> Also, before received this series, I tried to clean-up these patches
> >>>>>> on testing branch[1]. So that I add my comment with my clean-up case.
> >>>>>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!zIrzeDp9vPnm1_SDzVPuzqdHn3zWie9DnfBXaA-j9-CSrVc6aR9_rJQQiw81_CgAPh9XRRs$ 
> >>>>>>
> >>>>>> And 'Saravana Kannan <skannan at codeaurora.org>' is wrong email address.
> >>>>>> Please update the email or drop this email.
> >>>>>
> >>>>> Hi Chanwoo,
> >>>>>
> >>>>> Thank you for the advices.
> >>>>> I will resend patch v9 (add to linux-pm ML), remove this patch, and note
> >>>>> that my patch set base on
> >>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
> >>>>
> >>>> I has not yet test this patch[1] on devfreq-testing-passive-gov branch.
> >>>> So that if possible, I'd like you to test your patches with this patch[1] 
> >>>> and then if there is no problem, could you send the next patches with patch[1]?
> >>>>
> >>>> [1]https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-testing-passive-gov&id=39c80d11a8f42dd63ecea1e0df595a0ceb83b454__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJR2cQqZs$ 
> >>>
> >>>
> >>> Sorry for the confusion. I make the devfreq-testing-passive-gov[1]
> >>> branch based on latest devfreq-next branch.
> >>> [1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing-passive-gov__;!!CTRNKA9wMg0ARbw!yUlsuxrL5PcbF7o6A9DlCfvoA6w8V8VXKjYIybYyiJg3D0HM-lI2xRuxLUV6b3UJ8WFhg_g$ 
> >>>
> >>> First of all, if possible, I want to test them[1] with your patches in this series.
> >>> And then if there are no any problem, please let me know. After confirmed from you,
> >>> I'll send the patches of devfreq-testing-passive-gov[1] branch.
> >>> How about that?
> >>>
> >> Hi Chanwoo~
> >>
> >> We will use this on Google Chrome project.
> >> Google Hsin-Yi has test your patch + my patch set v8 [2~8]
> >>
> >>     make sure cci devfreqs runs with cpufreq.
> >>     suspend resume
> >>     speedometer2 benchmark
> >> It is okay.
> >>
> >> Please send the patches of devfreq-testing-passive-gov[1] branch.
> >>
> >> I will send patch v9 base on yours latter.
> > 
> > Thanks for your test. I'll send the patches today.
> 
> I'm sorry for delay because when I tested the patches
> for devfreq parent type on Odroid-xu3, there are some problem
> related to lazy linking of OPP. So I'm trying to analyze them.
> Unfortunately, we need to postpone these patches to next linux
> version.
> 
> 
Hi Chanwoo,
Sorry to bother you.
Do you work on this patch now?
Is there any thing that we can do?


> [snip]
> 


From guohanjun at huawei.com  Thu Apr 22 14:42:24 2021
From: guohanjun at huawei.com (Hanjun Guo)
Date: Thu, 22 Apr 2021 21:42:24 +0800
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <b20ed406-5ba4-337b-840d-fc805da642ad@huawei.com>

On 2021/4/22 0:43, Marc Zyngier wrote:
> Dann recently reported that his ThunderX machine failed to boot since
> 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
> interrupts"), with a not so pretty crash while trying to send an IPI.
> 
> It turned out to be caused by a mix of broken firmware and a buggy
> GTDT watchdog driver. Both have forever been buggy, but the above
> commit revealed that the error handling path of the driver was
> probably the worse part of it all.
> 
> Anyway, this short series has two goals:
> - handle broken firmware in a less broken way
> - make sure that the route cause of the problem can be identified
>    quickly

Tested on Kunpeng920 ARM64 server, didn't any issue after applying
this patch set,

Tested-by: Hanjun Guo <guohanjun at huawei.com>
Reviewed-by: Hanjun Guo <guohanjun at huawei.com>

Thanks
Hanjun


From arnd at kernel.org  Thu Apr 22 14:38:57 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 22 Apr 2021 15:38:57 +0200
Subject: [PATCH] [v2] spi: stm32-qspi: fix debug format string
Message-ID: <20210422134955.1988316-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

Printing size_t needs a special %zx format modifier to avoid a
warning like:

drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here
  481 |         dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);

Patrice already tried to fix this, but picked %lx instead of %zx,
which fixed some architectures but broke others in the same way.
Using %zx works everywhere.

Fixes: 18674dee3cd6 ("spi: stm32-qspi: Add dirmap support")
Fixes: 1b8a7d4282c0 ("spi: stm32-qspi: Fix compilation warning in ARM64")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/spi/spi-stm32-qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 02691c1603d9..7e640ccc7e77 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -478,7 +478,7 @@ static ssize_t stm32_qspi_dirmap_read(struct spi_mem_dirmap_desc *desc,
 	 * all needed transfer information into struct spi_mem_op
 	 */
 	memcpy(&op, &desc->info.op_tmpl, sizeof(struct spi_mem_op));
-	dev_dbg(qspi->dev, "%s len = 0x%lx offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
+	dev_dbg(qspi->dev, "%s len = 0x%zx offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
 
 	op.data.nbytes = len;
 	op.addr.val = desc->info.offset + offs;
-- 
2.29.2



From linux at roeck-us.net  Thu Apr 22 14:56:27 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 22 Apr 2021 06:56:27 -0700
Subject: [PATCH V6 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com>
References: <AHkAYwDkDhOuqx67*F9EB4r-.3.1619075149689.Hmail.wangqing@vivo.com>
Message-ID: <56f16371-5342-5c71-2393-41258cecb516@roeck-us.net>

On 4/22/21 12:05 AM, ?? wrote:
> 
>> On 4/21/21 8:46 PM, ?? wrote:
>>>
>>>> On 4/21/21 7:45 PM, Wang Qing wrote:
>>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>>
>>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>>> triggered first, then the timing restarts. The reset signal will be
>>>>> initiated when the timer expires again.
>>>>>
>>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>>
>>>>> V2:
>>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>>
>>>>> V3:
>>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>>> - is processed and wait until timeout.
>>>>>
>>>>> V4:
>>>>> - Remove pretimeout related processing. 
>>>>> - Add dual mode control separately.
>>>>>
>>>>> V5:
>>>>> - Fix some formatting and printing problems.
>>>>>
>>>>> V6:
>>>>> - Realize pretimeout processing through dualmode.
>>>>>
>>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>>> ---
>>>>>  drivers/watchdog/mtk_wdt.c | 53 +++++++++++++++++++++++++++++++++++++++++-----
>>>>>  1 file changed, 48 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>>> index 97ca993..ebc648b
>>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>>> @@ -25,6 +25,7 @@
>>>>>  #include <linux/reset-controller.h>
>>>>>  #include <linux/types.h>
>>>>>  #include <linux/watchdog.h>
>>>>> +#include <linux/interrupt.h>
>>>>>  
>>>>>  #define WDT_MAX_TIMEOUT		31
>>>>>  #define WDT_MIN_TIMEOUT		1
>>>>> @@ -184,15 +185,22 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>>  {
>>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>>> +	unsigned int timeout_interval;
>>>>>  	u32 reg;
>>>>>  
>>>>> -	wdt_dev->timeout = timeout;
>>>>> +	timeout_interval = wdt_dev->timeout = timeout;
>>>>> +	/*
>>>>> +	 * In dual mode, irq will be triggered at timeout/2
>>>>> +	 * the real timeout occurs at timeout
>>>>> +	 */
>>>>> +	if (wdt_dev->pretimeout)
>>>>> +		timeout_interval = wdt_dev->pretimeout = timeout/2;
>>>>
>>>> Please run checkpatch --strict and fix what it reports.
>>>> Also, there should be a set_pretimeout function to set the
>>>> pretimeout. It is ok to update it here, but it should be set
>>>> in its own function to make sure that the actual value
>>>> is reported back to userspace.
>>>>
>>>> Thanks,
>>>> Guenter
>>>
>>> The reason why the set_pretimeout interface is not provided is 
>>> because the pretimeout is fixed after the timeout is set,  we need
>>> to modify timeout after setting pretimeout, which is puzzling.
>>>
>>
>> What you need to do is to set pretimeout = timeout / 2 if a pretimeout
>> is set to a value != 0. Just like we adjust timeout to valid values
>> when set, we adjust pretimeout as well. I don't see a problem with that.
>>
>> Guenter
> 
> Thanks, Guenter. But this will complicate the situation:
> First, set_pretimeout will become an interface for dynamically enable and
> disable the pre-timeout func, instead of adjusting the pretimeout time. 
> 
Effectively yes. That is what it is, based on its limitations. That is
not a problem, and in true for every pretimeout function. Set it to 0,
and it is turned off. Set it to a value other than 0, and it is turned on.

> Secondly, when the irq is not registered, the user cannot be allowed to set
> the pretimeout to non-zero. When irq is registered, it doesn't make any sense
> to turn off pre-timeout func. 
> 

That is your opinion. It is still a user decision to turn it on or off,
just like it is a user decision to set the timeout to a specific value
or to enable the watchdog in the first place. There is no reason to
make it mandatory just because an interrupt has been provided
(or, rather, connected).

Also, if the interrupt is not provided, WDIOF_PRETIMEOUT is not set,
and trying to set the pretimeout would return -EOPNOTSUPP.

Guenter


From nm at ti.com  Thu Apr 22 15:09:35 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 22 Apr 2021 09:09:35 -0500
Subject: [PATCH 2/4] dt-bindings: clock: Convert ti, sci-clk to json schema
In-Reply-To: <20210421223145.GB1705110@robh.at.kernel.org>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-3-nm@ti.com>
 <161861731160.46595.786611690053722257@swboyd.mtv.corp.google.com>
 <20210417125127.vigq23mdoodje6b5@velcro>
 <20210421223145.GB1705110@robh.at.kernel.org>
Message-ID: <20210422140935.lzsp6s2ugyvi2icu@iodize>

On 17:31-20210421, Rob Herring wrote:
[...]

> > > > +allOf:
> > > > +  - $ref: /schemas/clock/clock.yaml#
> > > 
> > > Is this needed?
> 
> No. It is already applied to every node.
> 
> > https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> > This standardizes provider properties like '#clock-cells' etc, allowing
> > you to add more stricter checks or controls in the future if necessary.
> > 
> > while:
> > 
> > https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> > is more a consumer node description.
> 
> No, the meta-schema is what checks the schemas just as the schemas check 
> dts files.


I will drop and respin. thanks for explaining.

> 
> > Should I have picked a different yaml as base for a standard clock-controller
> > base?
> > 
> > > 
> > > > +
> > > > +description: |
> > > > +  Some TI SoCs contain a system controller (like the Power Management Micro
> > > > +  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > > +  the state of the various hardware modules present on the SoC. Communication
> > > > +  between the host processor running an OS and the system controller happens
> > > > +  through a protocol called TI System Control Interface (TI-SCI protocol).
> > > > +
> > > > +  This clock controller node uses the TI SCI protocol to perform various clock
> > > > +  management of various hardware modules (devices) present on the SoC. This
> > > > +  node must be a child node of the associated TI-SCI system controller node.
> > > > +
> > > > +properties:
> > > > +  $nodename:
> > > > +    pattern: "^clock-controller$"
> > > 
> > > Is this nodename pattern check required?
> > 
> > I'd like the definition on rails and not subject to interpretation, and
> > restrict the kind of subnodes under TISCI controller node.
> 
> If this schema was standalone and not defined as part of another, then 
> yes it would be required. In your case, you can enforce the node name 
> from the parent schema. For consistency though, it would be better to 
> just always require $nodename. 
> 
> Actually, this schema will be applied twice. On it's own matching the 
> compatible string and by the parent schema. You can prevent that with 
> 'select: false'. I don't mind the double validation as if the parent 
> node had a compatible typo you'd get zero validation.

Sure. I will keep nodename.

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


From daniel at 0x0f.com  Thu Apr 22 15:09:43 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Thu, 22 Apr 2021 23:09:43 +0900
Subject: [RFC PATCH 0/2] ARM: mstar: Internal bus madness
Message-ID: <20210422140945.4131092-1-daniel@0x0f.com>

The MStar/SigmaStar SoCs have some very weird internal
bus bridges called RIU and XIU. These seem to be a left
over from when the CPU core was 8051 or MIPS.

Basically they act as a bridge between the ARM CPU and the
lump of standard peripherals (ethernet, usb, sd host etc)
that has been used throughout all of their designs.

RIU has 16bit registers 32bits apart from the CPU view while
XIU has 32bit registers 64bits apart from the CPU view.
Older chips (MSC313) only have RIU, newer chips (MSC313E)
have both RIU and XIU with some IPs accessible via RIU with
the original address and via XIU with an additional address.
To make things really fun some IPs (memory mapped ethernet PHY)
have registers that are completely accessible via RIU but only
partially accessible via XIU.

The main issue is for non-MStar IPs connected to these bridges.
All of the MStar IPs seem to have 16bit registers but the
ethernet controller and usb controller are third party and
have 32bit registers.

The kernel drivers expect the registers to be at normal
offsets and not broken into two parts so they don't work
out of the box here.

I want to hide this stuff as much as possible so it seemed
like a good idea to hide it in a header and use the headers
in the unfortunate drivers.

RFC because maybe this isn't the right approach and I'm
sure the two readw()/writew()s for RIU need to be protected
somehow but I wasn't sure how.

Daniel Palmer (2):
  ARM: mstar: Add header with macros for RIU register access
  ARM: mstar: Add header with macros for XIU register access

 MAINTAINERS             |  1 +
 include/soc/mstar/riu.h | 28 ++++++++++++++++++++++++++++
 include/soc/mstar/xiu.h | 22 ++++++++++++++++++++++
 3 files changed, 51 insertions(+)
 create mode 100644 include/soc/mstar/riu.h
 create mode 100644 include/soc/mstar/xiu.h

-- 
2.31.0



From daniel at 0x0f.com  Thu Apr 22 15:09:44 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Thu, 22 Apr 2021 23:09:44 +0900
Subject: [RFC PATCH 1/2] ARM: mstar: Add header with macros for RIU register
 access
In-Reply-To: <20210422140945.4131092-1-daniel@0x0f.com>
References: <20210422140945.4131092-1-daniel@0x0f.com>
Message-ID: <20210422140945.4131092-2-daniel@0x0f.com>

Registers connected to the CPU via "RIU" (Maybe Register Interface
Unit) are 16bits wide with a 32bit stride.

For IPs that came from 3rd parties that have natively 32bit
registers they are annoyingly mapped with the 32bit register
split into two 16bit registers.

This means that any existing driver (i.e. the usb and ethernet)
cannot be used as is and needs to use a special readl()/writel()
to fix up the address of the register that needs to be accessed,
do two readw()/writel()s and stitch the values together.

To avoid having this code in every driver add a header with an
implementation of readl()/writel() that patches over the insanity.

Signed-off-by: Daniel Palmer <daniel at 0x0f.com>
---
 MAINTAINERS             |  1 +
 include/soc/mstar/riu.h | 28 ++++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 include/soc/mstar/riu.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 19dc2eb0d93b..9600291e73a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2155,6 +2155,7 @@ F:	drivers/gpio/gpio-msc313.c
 F:	drivers/pinctrl/pinctrl-msc313.c
 F:	include/dt-bindings/clock/mstar-*
 F:	include/dt-bindings/gpio/msc313-gpio.h
+F:	include/soc/mstar/
 
 ARM/NEC MOBILEPRO 900/c MACHINE SUPPORT
 M:	Michael Petchkovsky <mkpetch at internode.on.net>
diff --git a/include/soc/mstar/riu.h b/include/soc/mstar/riu.h
new file mode 100644
index 000000000000..5aeea9c1e7eb
--- /dev/null
+++ b/include/soc/mstar/riu.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef _SOC_MSTAR_RIU_H_
+#define _SOC_MSTAR_RIU_H_
+
+#include <linux/io.h>
+
+static inline u32 riu_readl(__iomem void *base, unsigned int offset)
+{
+	__iomem void *reg = base + (offset * 2);
+
+	return readw_relaxed(reg + 4) << 16 | readw_relaxed(reg);
+}
+
+static inline void riu_writel(__iomem void *base, unsigned int offset, u32 value)
+{
+	__iomem void *reg = base + (offset * 2);
+
+	/*
+	 * Do not change this order. For EMAC at least
+	 * the write order must be the lower half and then
+	 * the upper half otherwise it doesn't work.
+	 */
+	writew_relaxed(value, reg);
+	writew_relaxed(value >> 16, reg + 4);
+}
+
+#endif
-- 
2.31.0



From daniel at 0x0f.com  Thu Apr 22 15:09:45 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Thu, 22 Apr 2021 23:09:45 +0900
Subject: [RFC PATCH 2/2] ARM: mstar: Add header with macros for XIU register
 access
In-Reply-To: <20210422140945.4131092-1-daniel@0x0f.com>
References: <20210422140945.4131092-1-daniel@0x0f.com>
Message-ID: <20210422140945.4131092-3-daniel@0x0f.com>

Registers connected to the CPU via "XIU" (Maybe eXtended Interface
Unit) are 32bits wide with a 64bit stride.

Apparently someone realised that splitting 32bit registers into
two 16bit ones was silly but at the same time didn't want to
fix all of the register offsets used for "RIU" in their code.

This means that any existing driver (i.e. the usb and ethernet)
cannot be used as is and needs to use a special readl()/writel()
to fix up the address of the register that needs to be accessed.

To avoid having this code in every driver add a header with an
implementation of readl()/writel() that patches over the insanity.

Signed-off-by: Daniel Palmer <daniel at 0x0f.com>
---
 include/soc/mstar/xiu.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 include/soc/mstar/xiu.h

diff --git a/include/soc/mstar/xiu.h b/include/soc/mstar/xiu.h
new file mode 100644
index 000000000000..d658338b8006
--- /dev/null
+++ b/include/soc/mstar/xiu.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef _SOC_MSTAR_XIU_H_
+#define _SOC_MSTAR_XIU_H_
+
+#include <linux/io.h>
+
+static inline u32 xiu_readl(__iomem void *base, unsigned int offset)
+{
+	__iomem void *reg = base + (offset * 2);
+
+	return readl_relaxed(reg);
+}
+
+static inline void xiu_writel(__iomem void *base, unsigned int offset, u32 value)
+{
+	__iomem void *reg = base + (offset * 2);
+
+	writel_relaxed(value, reg);
+}
+
+#endif
-- 
2.31.0



From benjamin.gaignard at collabora.com  Thu Apr 22 15:16:00 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 16:16:00 +0200
Subject: [PATCH v2 2/4] dt-bindings: iommu: rockchip: Add compatible for v2
In-Reply-To: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422141602.350746-3-benjamin.gaignard@collabora.com>

Add compatible for the second version of IOMMU hardware block.
RK356x IOMMU can also be link to a power domain.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 2:
 - Add power-domains property

 .../devicetree/bindings/iommu/rockchip,iommu.yaml          | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
index 0db208cf724a..e54353ccd1ec 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -19,7 +19,9 @@ description: |+
 
 properties:
   compatible:
-    const: rockchip,iommu
+    enum:
+      - rockchip,iommu
+      - rockchip,iommu-v2
 
   reg:
     minItems: 1
@@ -46,6 +48,9 @@ properties:
   "#iommu-cells":
     const: 0
 
+  power-domains:
+    maxItems: 1
+
   rockchip,disable-mmu-reset:
     $ref: /schemas/types.yaml#/definitions/flag
     description: |
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 15:15:58 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 16:15:58 +0200
Subject: [PATCH v2 0/4] Add driver for rk356x
Message-ID: <20210422141602.350746-1-benjamin.gaignard@collabora.com>

This series adds the IOMMU driver for rk356x SoC.
Since a new compatible is needed to distinguish this second version of 
IOMMU hardware block from the first one, it is an opportunity to convert
the binding to DT schema.

version 2:
 - Fix iommu-cells typo in rk322x.dtsi
 - Change maintainer
 - Change reg maxItems
 - Add power-domains property

Benjamin Gaignard (3):
  dt-bindings: iommu: rockchip: Convert IOMMU to DT schema
  dt-bindings: iommu: rockchip: Add compatible for v2
  ARM: dts: rockchip: rk322x: Fix iommu-cells properties name

Simon Xue (1):
  iommu: rockchip: Add support iommu v2

 .../bindings/iommu/rockchip,iommu.txt         |  38 --
 .../bindings/iommu/rockchip,iommu.yaml        |  84 ++++
 arch/arm/boot/dts/rk322x.dtsi                 |   6 +-
 drivers/iommu/rockchip-iommu.c                | 422 +++++++++++++++++-
 4 files changed, 493 insertions(+), 57 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 15:16:01 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 16:16:01 +0200
Subject: [PATCH v2 3/4] ARM: dts: rockchip: rk322x: Fix iommu-cells properties
 name
In-Reply-To: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422141602.350746-4-benjamin.gaignard@collabora.com>

Add '#" to iommu-cells properties

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 arch/arm/boot/dts/rk322x.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index a4dd50aaf3fc..8af2e9288029 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -564,7 +564,7 @@ vpu_mmu: iommu at 20020800 {
 		interrupt-names = "vpu_mmu";
 		clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
 		clock-names = "aclk", "iface";
-		iommu-cells = <0>;
+		#iommu-cells = <0>;
 		status = "disabled";
 	};
 
@@ -575,7 +575,7 @@ vdec_mmu: iommu at 20030480 {
 		interrupt-names = "vdec_mmu";
 		clocks = <&cru ACLK_RKVDEC>, <&cru HCLK_RKVDEC>;
 		clock-names = "aclk", "iface";
-		iommu-cells = <0>;
+		#iommu-cells = <0>;
 		status = "disabled";
 	};
 
@@ -629,7 +629,7 @@ iep_mmu: iommu at 20070800 {
 		interrupt-names = "iep_mmu";
 		clocks = <&cru ACLK_IEP>, <&cru HCLK_IEP>;
 		clock-names = "aclk", "iface";
-		iommu-cells = <0>;
+		#iommu-cells = <0>;
 		status = "disabled";
 	};
 
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 15:15:59 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 16:15:59 +0200
Subject: [PATCH v2 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to DT
 schema
In-Reply-To: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422141602.350746-2-benjamin.gaignard@collabora.com>

Convert Rockchip IOMMU to DT schema

Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
version 2:
 - Change maintainer
 - Change reg maxItems
 - Change interrupt maxItems

 .../bindings/iommu/rockchip,iommu.txt         | 38 ---------
 .../bindings/iommu/rockchip,iommu.yaml        | 79 +++++++++++++++++++
 2 files changed, 79 insertions(+), 38 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
deleted file mode 100644
index 6ecefea1c6f9..000000000000
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Rockchip IOMMU
-==============
-
-A Rockchip DRM iommu translates io virtual addresses to physical addresses for
-its master device.  Each slave device is bound to a single master device, and
-shares its clocks, power domain and irq.
-
-Required properties:
-- compatible      : Should be "rockchip,iommu"
-- reg             : Address space for the configuration registers
-- interrupts      : Interrupt specifier for the IOMMU instance
-- interrupt-names : Interrupt name for the IOMMU instance
-- #iommu-cells    : Should be <0>.  This indicates the iommu is a
-                    "single-master" device, and needs no additional information
-                    to associate with its master device.  See:
-                    Documentation/devicetree/bindings/iommu/iommu.txt
-- clocks          : A list of clocks required for the IOMMU to be accessible by
-                    the host CPU.
-- clock-names     : Should contain the following:
-	"iface" - Main peripheral bus clock (PCLK/HCL) (required)
-	"aclk"  - AXI bus clock (required)
-
-Optional properties:
-- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
-			       Some mmu instances may produce unexpected results
-			       when the reset operation is used.
-
-Example:
-
-	vopl_mmu: iommu at ff940300 {
-		compatible = "rockchip,iommu";
-		reg = <0xff940300 0x100>;
-		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "vopl_mmu";
-		clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
-		clock-names = "aclk", "iface";
-		#iommu-cells = <0>;
-	};
diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
new file mode 100644
index 000000000000..0db208cf724a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip IOMMU
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+description: |+
+  A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+  its master device. Each slave device is bound to a single master device and
+  shares its clocks, power domain and irq.
+
+  For information on assigning IOMMU controller to its peripheral devices,
+  see generic IOMMU bindings.
+
+properties:
+  compatible:
+    const: rockchip,iommu
+
+  reg:
+    minItems: 1
+    maxItems: 2
+
+  interrupts:
+    minItems: 1
+    maxItems: 2
+
+  interrupt-names:
+    minItems: 1
+    maxItems: 2
+
+  clocks:
+    items:
+      - description: Core clock
+      - description: Interface clock
+
+  clock-names:
+    items:
+      - const: aclk
+      - const: iface
+
+  "#iommu-cells":
+    const: 0
+
+  rockchip,disable-mmu-reset:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description: |
+      Do not use the mmu reset operation.
+      Some mmu instances may produce unexpected results
+      when the reset operation is used.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - "#iommu-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3399-cru.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+    vopl_mmu: iommu at ff940300 {
+      compatible = "rockchip,iommu";
+      reg = <0xff940300 0x100>;
+      interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+      interrupt-names = "vopl_mmu";
+      clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
+      clock-names = "aclk", "iface";
+      #iommu-cells = <0>;
+    };
-- 
2.25.1



From benjamin.gaignard at collabora.com  Thu Apr 22 15:16:02 2021
From: benjamin.gaignard at collabora.com (Benjamin Gaignard)
Date: Thu, 22 Apr 2021 16:16:02 +0200
Subject: [PATCH v2 4/4] iommu: rockchip: Add support iommu v2
In-Reply-To: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
Message-ID: <20210422141602.350746-5-benjamin.gaignard@collabora.com>

From: Simon Xue <xxm at rock-chips.com>

RK356x SoC got new IOMMU hardware block (version 2).
Add a compatible to distinguish it from the first version.

Signed-off-by: Simon Xue <xxm at rock-chips.com>
[Benjamin]
- port driver from kernel 4.19 to 5.12
- change functions prototype.
- squash all fixes in this commit.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
---
 drivers/iommu/rockchip-iommu.c | 422 +++++++++++++++++++++++++++++++--
 1 file changed, 406 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index e5d86b7177de..0d345d0f44fc 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -19,6 +19,7 @@
 #include <linux/iopoll.h>
 #include <linux/list.h>
 #include <linux/mm.h>
+#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/of_iommu.h>
@@ -81,6 +82,30 @@
   */
 #define RK_IOMMU_PGSIZE_BITMAP 0x007ff000
 
+#define DT_LO_MASK 0xfffff000
+#define DT_HI_MASK GENMASK_ULL(39, 32)
+#define DT_SHIFT   28
+
+#define DTE_BASE_HI_MASK GENMASK(11, 4)
+
+#define PAGE_DESC_LO_MASK   0xfffff000
+#define PAGE_DESC_HI1_LOWER 32
+#define PAGE_DESC_HI1_UPPER 35
+#define PAGE_DESC_HI2_LOWER 36
+#define PAGE_DESC_HI2_UPPER 39
+#define PAGE_DESC_HI_MASK1  GENMASK_ULL(PAGE_DESC_HI1_UPPER, PAGE_DESC_HI1_LOWER)
+#define PAGE_DESC_HI_MASK2  GENMASK_ULL(PAGE_DESC_HI2_UPPER, PAGE_DESC_HI2_LOWER)
+
+#define DTE_HI1_LOWER 8
+#define DTE_HI1_UPPER 11
+#define DTE_HI2_LOWER 4
+#define DTE_HI2_UPPER 7
+#define DTE_HI_MASK1  GENMASK(DTE_HI1_UPPER, DTE_HI1_LOWER)
+#define DTE_HI_MASK2  GENMASK(DTE_HI2_UPPER, DTE_HI2_LOWER)
+
+#define PAGE_DESC_HI_SHIFT1 (PAGE_DESC_HI1_LOWER - DTE_HI1_LOWER)
+#define PAGE_DESC_HI_SHIFT2 (PAGE_DESC_HI2_LOWER - DTE_HI2_LOWER)
+
 struct rk_iommu_domain {
 	struct list_head iommus;
 	u32 *dt; /* page directory table */
@@ -91,6 +116,10 @@ struct rk_iommu_domain {
 	struct iommu_domain domain;
 };
 
+struct rockchip_iommu_data {
+	u32 version;
+};
+
 /* list of clocks required by IOMMU */
 static const char * const rk_iommu_clocks[] = {
 	"aclk", "iface",
@@ -108,6 +137,7 @@ struct rk_iommu {
 	struct list_head node; /* entry in rk_iommu_domain.iommus */
 	struct iommu_domain *domain; /* domain to which iommu is attached */
 	struct iommu_group *group;
+	u32 version;
 };
 
 struct rk_iommudata {
@@ -174,11 +204,32 @@ static struct rk_iommu_domain *to_rk_domain(struct iommu_domain *dom)
 #define RK_DTE_PT_ADDRESS_MASK    0xfffff000
 #define RK_DTE_PT_VALID           BIT(0)
 
+/*
+ * In v2:
+ * 31:12 - PT address bit 31:0
+ * 11: 8 - PT address bit 35:32
+ *  7: 4 - PT address bit 39:36
+ *  3: 1 - Reserved
+ *     0 - 1 if PT @ PT address is valid
+ */
+#define RK_DTE_PT_ADDRESS_MASK_V2 0xfffffff0
+
 static inline phys_addr_t rk_dte_pt_address(u32 dte)
 {
 	return (phys_addr_t)dte & RK_DTE_PT_ADDRESS_MASK;
 }
 
+static inline phys_addr_t rk_dte_pt_address_v2(u32 dte)
+{
+	u64 dte_v2 = dte;
+
+	dte_v2 = ((dte_v2 & DTE_HI_MASK2) << PAGE_DESC_HI_SHIFT2) |
+		 ((dte_v2 & DTE_HI_MASK1) << PAGE_DESC_HI_SHIFT1) |
+		 (dte_v2 & PAGE_DESC_LO_MASK);
+
+	return (phys_addr_t)dte_v2;
+}
+
 static inline bool rk_dte_is_pt_valid(u32 dte)
 {
 	return dte & RK_DTE_PT_VALID;
@@ -189,6 +240,15 @@ static inline u32 rk_mk_dte(dma_addr_t pt_dma)
 	return (pt_dma & RK_DTE_PT_ADDRESS_MASK) | RK_DTE_PT_VALID;
 }
 
+static inline u32 rk_mk_dte_v2(dma_addr_t pt_dma)
+{
+	pt_dma = (pt_dma & PAGE_DESC_LO_MASK) |
+		 ((pt_dma & PAGE_DESC_HI_MASK1) >> PAGE_DESC_HI_SHIFT1) |
+		 (pt_dma & PAGE_DESC_HI_MASK2) >> PAGE_DESC_HI_SHIFT2;
+
+	return (pt_dma & RK_DTE_PT_ADDRESS_MASK_V2) | RK_DTE_PT_VALID;
+}
+
 /*
  * Each PTE has a Page address, some flags and a valid bit:
  * +---------------------+---+-------+-+
@@ -215,11 +275,37 @@ static inline u32 rk_mk_dte(dma_addr_t pt_dma)
 #define RK_PTE_PAGE_READABLE      BIT(1)
 #define RK_PTE_PAGE_VALID         BIT(0)
 
+/*
+ * In v2:
+ * 31:12 - Page address bit 31:0
+ *  11:9 - Page address bit 34:32
+ *   8:4 - Page address bit 39:35
+ *     3 - Security
+ *     2 - Readable
+ *     1 - Writable
+ *     0 - 1 if Page @ Page address is valid
+ */
+#define RK_PTE_PAGE_ADDRESS_MASK_V2  0xfffffff0
+#define RK_PTE_PAGE_FLAGS_MASK_V2    0x0000000e
+#define RK_PTE_PAGE_READABLE_V2      BIT(2)
+#define RK_PTE_PAGE_WRITABLE_V2      BIT(1)
+
 static inline phys_addr_t rk_pte_page_address(u32 pte)
 {
 	return (phys_addr_t)pte & RK_PTE_PAGE_ADDRESS_MASK;
 }
 
+static inline phys_addr_t rk_pte_page_address_v2(u32 pte)
+{
+	u64 pte_v2 = pte;
+
+	pte_v2 = ((pte_v2 & DTE_HI_MASK2) << PAGE_DESC_HI_SHIFT2) |
+		 ((pte_v2 & DTE_HI_MASK1) << PAGE_DESC_HI_SHIFT1) |
+		 (pte_v2 & PAGE_DESC_LO_MASK);
+
+	return (phys_addr_t)pte_v2;
+}
+
 static inline bool rk_pte_is_page_valid(u32 pte)
 {
 	return pte & RK_PTE_PAGE_VALID;
@@ -229,12 +315,26 @@ static inline bool rk_pte_is_page_valid(u32 pte)
 static u32 rk_mk_pte(phys_addr_t page, int prot)
 {
 	u32 flags = 0;
+
 	flags |= (prot & IOMMU_READ) ? RK_PTE_PAGE_READABLE : 0;
 	flags |= (prot & IOMMU_WRITE) ? RK_PTE_PAGE_WRITABLE : 0;
 	page &= RK_PTE_PAGE_ADDRESS_MASK;
 	return page | flags | RK_PTE_PAGE_VALID;
 }
 
+static u32 rk_mk_pte_v2(phys_addr_t page, int prot)
+{
+	u32 flags = 0;
+
+	flags |= (prot & IOMMU_READ) ? RK_PTE_PAGE_READABLE_V2 : 0;
+	flags |= (prot & IOMMU_WRITE) ? RK_PTE_PAGE_WRITABLE_V2 : 0;
+	page = (page & PAGE_DESC_LO_MASK) |
+	       ((page & PAGE_DESC_HI_MASK1) >> PAGE_DESC_HI_SHIFT1) |
+	       (page & PAGE_DESC_HI_MASK2) >> PAGE_DESC_HI_SHIFT2;
+	page &= RK_PTE_PAGE_ADDRESS_MASK_V2;
+	return page | flags | RK_PTE_PAGE_VALID;
+}
+
 static u32 rk_mk_pte_invalid(u32 pte)
 {
 	return pte & ~RK_PTE_PAGE_VALID;
@@ -439,6 +539,7 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 	int ret, i;
 	u32 dte_addr;
 	bool val;
+	u32 address_mask;
 
 	if (iommu->reset_disabled)
 		return 0;
@@ -447,11 +548,19 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
 	 * Check if register DTE_ADDR is working by writing DTE_ADDR_DUMMY
 	 * and verifying that upper 5 nybbles are read back.
 	 */
+
+	/*
+	 * In v2: upper 7 nybbles are read back.
+	 */
 	for (i = 0; i < iommu->num_mmu; i++) {
 		rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, DTE_ADDR_DUMMY);
 
+		if (iommu->version >= 0x2)
+			address_mask = RK_DTE_PT_ADDRESS_MASK_V2;
+		else
+			address_mask = RK_DTE_PT_ADDRESS_MASK;
 		dte_addr = rk_iommu_read(iommu->bases[i], RK_MMU_DTE_ADDR);
-		if (dte_addr != (DTE_ADDR_DUMMY & RK_DTE_PT_ADDRESS_MASK)) {
+		if (dte_addr != (DTE_ADDR_DUMMY & address_mask)) {
 			dev_err(iommu->dev, "Error during raw reset. MMU_DTE_ADDR is not functioning\n");
 			return -EFAULT;
 		}
@@ -490,6 +599,10 @@ static void log_iova(struct rk_iommu *iommu, int index, dma_addr_t iova)
 
 	mmu_dte_addr = rk_iommu_read(base, RK_MMU_DTE_ADDR);
 	mmu_dte_addr_phys = (phys_addr_t)mmu_dte_addr;
+	if (iommu->version >= 0x2) {
+		mmu_dte_addr_phys = (mmu_dte_addr_phys & DT_LO_MASK) |
+				    ((mmu_dte_addr_phys & DTE_BASE_HI_MASK) << DT_SHIFT);
+	}
 
 	dte_addr_phys = mmu_dte_addr_phys + (4 * dte_index);
 	dte_addr = phys_to_virt(dte_addr_phys);
@@ -498,14 +611,20 @@ static void log_iova(struct rk_iommu *iommu, int index, dma_addr_t iova)
 	if (!rk_dte_is_pt_valid(dte))
 		goto print_it;
 
-	pte_addr_phys = rk_dte_pt_address(dte) + (pte_index * 4);
+	if (iommu->version >= 0x2)
+		pte_addr_phys = rk_dte_pt_address_v2(dte) + (pte_index * 4);
+	else
+		pte_addr_phys = rk_dte_pt_address(dte) + (pte_index * 4);
 	pte_addr = phys_to_virt(pte_addr_phys);
 	pte = *pte_addr;
 
 	if (!rk_pte_is_page_valid(pte))
 		goto print_it;
 
-	page_addr_phys = rk_pte_page_address(pte) + page_offset;
+	if (iommu->version >= 0x2)
+		page_addr_phys = rk_pte_page_address_v2(pte) + page_offset;
+	else
+		page_addr_phys = rk_pte_page_address(pte) + page_offset;
 	page_flags = pte & RK_PTE_PAGE_FLAGS_MASK;
 
 print_it:
@@ -522,6 +641,7 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
 	struct rk_iommu *iommu = dev_id;
 	u32 status;
 	u32 int_status;
+	u32 int_mask;
 	dma_addr_t iova;
 	irqreturn_t ret = IRQ_NONE;
 	int i, err;
@@ -566,7 +686,15 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
 				dev_err(iommu->dev, "Page fault while iommu not attached to domain?\n");
 
 			rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
-			rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_PAGE_FAULT_DONE);
+
+			/*
+			 * Master may clear the int_mask to prevent iommu
+			 * re-enter interrupt when mapping. So we postpone
+			 * sending PAGE_FAULT_DONE command to mapping finished.
+			 */
+			int_mask = rk_iommu_read(iommu->bases[i], RK_MMU_INT_MASK);
+			if (int_mask != 0x0)
+				rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_PAGE_FAULT_DONE);
 		}
 
 		if (int_status & RK_MMU_IRQ_BUS_ERROR)
@@ -614,6 +742,34 @@ static phys_addr_t rk_iommu_iova_to_phys(struct iommu_domain *domain,
 	return phys;
 }
 
+static phys_addr_t rk_iommu_iova_to_phys_v2(struct iommu_domain *domain,
+					    dma_addr_t iova)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	phys_addr_t pt_phys, phys = 0;
+	u32 dte, pte;
+	u32 *page_table;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	if (!rk_dte_is_pt_valid(dte))
+		goto out;
+
+	pt_phys = rk_dte_pt_address_v2(dte);
+	page_table = (u32 *)phys_to_virt(pt_phys);
+	pte = page_table[rk_iova_pte_index(iova)];
+	if (!rk_pte_is_page_valid(pte))
+		goto out;
+
+	phys = rk_pte_page_address_v2(pte) + rk_iova_page_offset(iova);
+out:
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	return phys;
+}
+
 static void rk_iommu_zap_iova(struct rk_iommu_domain *rk_domain,
 			      dma_addr_t iova, size_t size)
 {
@@ -690,6 +846,44 @@ static u32 *rk_dte_get_page_table(struct rk_iommu_domain *rk_domain,
 	return (u32 *)phys_to_virt(pt_phys);
 }
 
+static u32 *rk_dte_get_page_table_v2(struct rk_iommu_domain *rk_domain,
+				     dma_addr_t iova)
+{
+	u32 *page_table, *dte_addr;
+	u32 dte_index, dte;
+	phys_addr_t pt_phys;
+	dma_addr_t pt_dma;
+
+	assert_spin_locked(&rk_domain->dt_lock);
+
+	dte_index = rk_iova_dte_index(iova);
+	dte_addr = &rk_domain->dt[dte_index];
+	dte = *dte_addr;
+	if (rk_dte_is_pt_valid(dte))
+		goto done;
+
+	page_table = (u32 *)get_zeroed_page(GFP_ATOMIC | GFP_DMA32);
+	if (!page_table)
+		return ERR_PTR(-ENOMEM);
+
+	pt_dma = dma_map_single(dma_dev, page_table, SPAGE_SIZE, DMA_TO_DEVICE);
+	if (dma_mapping_error(dma_dev, pt_dma)) {
+		dev_err(dma_dev, "DMA mapping error while allocating page table\n");
+		free_page((unsigned long)page_table);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	dte = rk_mk_dte_v2(pt_dma);
+	*dte_addr = dte;
+
+	rk_table_flush(rk_domain, pt_dma, NUM_PT_ENTRIES);
+	rk_table_flush(rk_domain,
+		       rk_domain->dt_dma + dte_index * sizeof(u32), 1);
+done:
+	pt_phys = rk_dte_pt_address_v2(dte);
+	return (u32 *)phys_to_virt(pt_phys);
+}
+
 static size_t rk_iommu_unmap_iova(struct rk_iommu_domain *rk_domain,
 				  u32 *pte_addr, dma_addr_t pte_dma,
 				  size_t size)
@@ -757,6 +951,45 @@ static int rk_iommu_map_iova(struct rk_iommu_domain *rk_domain, u32 *pte_addr,
 	return -EADDRINUSE;
 }
 
+static int rk_iommu_map_iova_v2(struct rk_iommu_domain *rk_domain, u32 *pte_addr,
+				dma_addr_t pte_dma, dma_addr_t iova,
+				phys_addr_t paddr, size_t size, int prot)
+{
+	unsigned int pte_count;
+	unsigned int pte_total = size / SPAGE_SIZE;
+	phys_addr_t page_phys;
+
+	assert_spin_locked(&rk_domain->dt_lock);
+
+	for (pte_count = 0; pte_count < pte_total; pte_count++) {
+		u32 pte = pte_addr[pte_count];
+
+		if (rk_pte_is_page_valid(pte))
+			goto unwind;
+
+		pte_addr[pte_count] = rk_mk_pte_v2(paddr, prot);
+
+		paddr += SPAGE_SIZE;
+	}
+
+	rk_table_flush(rk_domain, pte_dma, pte_total);
+
+	rk_iommu_zap_iova_first_last(rk_domain, iova, size);
+
+	return 0;
+unwind:
+	/* Unmap the range of iovas that we just mapped */
+	rk_iommu_unmap_iova(rk_domain, pte_addr, pte_dma,
+			    pte_count * SPAGE_SIZE);
+
+	iova += pte_count * SPAGE_SIZE;
+	page_phys = rk_pte_page_address_v2(pte_addr[pte_count]);
+	pr_err("iova: %pad already mapped to %pa cannot remap to phys: %pa prot: %#x\n",
+	       &iova, &page_phys, &paddr, prot);
+
+	return -EADDRINUSE;
+}
+
 static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 			phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
 {
@@ -764,7 +997,7 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 	unsigned long flags;
 	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
 	u32 *page_table, *pte_addr;
-	u32 dte_index, pte_index;
+	u32 dte, pte_index;
 	int ret;
 
 	spin_lock_irqsave(&rk_domain->dt_lock, flags);
@@ -782,10 +1015,10 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 		return PTR_ERR(page_table);
 	}
 
-	dte_index = rk_domain->dt[rk_iova_dte_index(iova)];
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
 	pte_index = rk_iova_pte_index(iova);
 	pte_addr = &page_table[pte_index];
-	pte_dma = rk_dte_pt_address(dte_index) + pte_index * sizeof(u32);
+	pte_dma = rk_dte_pt_address(dte) + pte_index * sizeof(u32);
 	ret = rk_iommu_map_iova(rk_domain, pte_addr, pte_dma, iova,
 				paddr, size, prot);
 
@@ -794,6 +1027,43 @@ static int rk_iommu_map(struct iommu_domain *domain, unsigned long _iova,
 	return ret;
 }
 
+static int rk_iommu_map_v2(struct iommu_domain *domain, unsigned long _iova,
+			   phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
+	u32 *page_table, *pte_addr;
+	u32 dte, pte_index;
+	int ret;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	/*
+	 * pgsize_bitmap specifies iova sizes that fit in one page table
+	 * (1024 4-KiB pages = 4 MiB).
+	 * So, size will always be 4096 <= size <= 4194304.
+	 * Since iommu_map() guarantees that both iova and size will be
+	 * aligned, we will always only be mapping from a single dte here.
+	 */
+	page_table = rk_dte_get_page_table_v2(rk_domain, iova);
+	if (IS_ERR(page_table)) {
+		spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+		return PTR_ERR(page_table);
+	}
+
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	pte_index = rk_iova_pte_index(iova);
+	pte_addr = &page_table[pte_index];
+	pte_dma = rk_dte_pt_address_v2(dte) + pte_index * sizeof(u32);
+	ret = rk_iommu_map_iova_v2(rk_domain, pte_addr, pte_dma, iova,
+				   paddr, size, prot);
+
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	return ret;
+}
+
 static size_t rk_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
 			     size_t size, struct iommu_iotlb_gather *gather)
 {
@@ -834,6 +1104,46 @@ static size_t rk_iommu_unmap(struct iommu_domain *domain, unsigned long _iova,
 	return unmap_size;
 }
 
+static size_t rk_iommu_unmap_v2(struct iommu_domain *domain, unsigned long _iova,
+				size_t size, struct iommu_iotlb_gather *gather)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	unsigned long flags;
+	dma_addr_t pte_dma, iova = (dma_addr_t)_iova;
+	phys_addr_t pt_phys;
+	u32 dte;
+	u32 *pte_addr;
+	size_t unmap_size;
+
+	spin_lock_irqsave(&rk_domain->dt_lock, flags);
+
+	/*
+	 * pgsize_bitmap specifies iova sizes that fit in one page table
+	 * (1024 4-KiB pages = 4 MiB).
+	 * So, size will always be 4096 <= size <= 4194304.
+	 * Since iommu_unmap() guarantees that both iova and size will be
+	 * aligned, we will always only be unmapping from a single dte here.
+	 */
+	dte = rk_domain->dt[rk_iova_dte_index(iova)];
+	/* Just return 0 if iova is unmapped */
+	if (!rk_dte_is_pt_valid(dte)) {
+		spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+		return 0;
+	}
+
+	pt_phys = rk_dte_pt_address_v2(dte);
+	pte_addr = (u32 *)phys_to_virt(pt_phys) + rk_iova_pte_index(iova);
+	pte_dma = pt_phys + rk_iova_pte_index(iova) * sizeof(u32);
+	unmap_size = rk_iommu_unmap_iova(rk_domain, pte_addr, pte_dma, size);
+
+	spin_unlock_irqrestore(&rk_domain->dt_lock, flags);
+
+	/* Shootdown iotlb entries for iova range that was just unmapped */
+	rk_iommu_zap_iova(rk_domain, iova, unmap_size);
+
+	return unmap_size;
+}
+
 static struct rk_iommu *rk_iommu_from_dev(struct device *dev)
 {
 	struct rk_iommudata *data = dev_iommu_priv_get(dev);
@@ -864,6 +1174,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
 	struct iommu_domain *domain = iommu->domain;
 	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
 	int ret, i;
+	u32 dt_v2;
 
 	ret = clk_bulk_enable(iommu->num_clocks, iommu->clocks);
 	if (ret)
@@ -878,8 +1189,14 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
 		goto out_disable_stall;
 
 	for (i = 0; i < iommu->num_mmu; i++) {
-		rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
-			       rk_domain->dt_dma);
+		if (iommu->version >= 0x2) {
+			dt_v2 = (rk_domain->dt_dma & DT_LO_MASK) |
+				((rk_domain->dt_dma & DT_HI_MASK) >> DT_SHIFT);
+			rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, dt_v2);
+		} else {
+			rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
+				       rk_domain->dt_dma);
+		}
 		rk_iommu_base_command(iommu->bases[i], RK_MMU_CMD_ZAP_CACHE);
 		rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
 	}
@@ -1054,6 +1371,34 @@ static void rk_iommu_domain_free(struct iommu_domain *domain)
 	kfree(rk_domain);
 }
 
+static void rk_iommu_domain_free_v2(struct iommu_domain *domain)
+{
+	struct rk_iommu_domain *rk_domain = to_rk_domain(domain);
+	int i;
+
+	WARN_ON(!list_empty(&rk_domain->iommus));
+
+	for (i = 0; i < NUM_DT_ENTRIES; i++) {
+		u32 dte = rk_domain->dt[i];
+
+		if (rk_dte_is_pt_valid(dte)) {
+			phys_addr_t pt_phys = rk_dte_pt_address_v2(dte);
+			u32 *page_table = phys_to_virt(pt_phys);
+
+			dma_unmap_single(dma_dev, pt_phys,
+					 SPAGE_SIZE, DMA_TO_DEVICE);
+			free_page((unsigned long)page_table);
+		}
+	}
+	dma_unmap_single(dma_dev, rk_domain->dt_dma,
+			 SPAGE_SIZE, DMA_TO_DEVICE);
+	free_page((unsigned long)rk_domain->dt);
+
+	if (domain->type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(&rk_domain->domain);
+	kfree(rk_domain);
+}
+
 static struct iommu_device *rk_iommu_probe_device(struct device *dev)
 {
 	struct rk_iommudata *data;
@@ -1122,6 +1467,40 @@ static const struct iommu_ops rk_iommu_ops = {
 	.of_xlate = rk_iommu_of_xlate,
 };
 
+static const struct iommu_ops rk_iommu_ops_v2 = {
+	.domain_alloc = rk_iommu_domain_alloc,
+	.domain_free = rk_iommu_domain_free_v2,
+	.attach_dev = rk_iommu_attach_device,
+	.detach_dev = rk_iommu_detach_device,
+	.map = rk_iommu_map_v2,
+	.unmap = rk_iommu_unmap_v2,
+	.probe_device = rk_iommu_probe_device,
+	.release_device = rk_iommu_release_device,
+	.iova_to_phys = rk_iommu_iova_to_phys_v2,
+	.device_group = rk_iommu_device_group,
+	.pgsize_bitmap = RK_IOMMU_PGSIZE_BITMAP,
+	.of_xlate = rk_iommu_of_xlate,
+};
+
+static const struct rockchip_iommu_data iommu_data_v1 = {
+	.version = 0x1,
+};
+
+static const struct rockchip_iommu_data iommu_data_v2 = {
+	.version = 0x2,
+};
+
+static const struct of_device_id rk_iommu_dt_ids[] = {
+	{	.compatible = "rockchip,iommu",
+		.data = &iommu_data_v1,
+	}, {
+		.compatible = "rockchip,iommu-v2",
+		.data = &iommu_data_v2,
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, rk_iommu_dt_ids);
+
 static int rk_iommu_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1129,11 +1508,21 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	struct resource *res;
 	int num_res = pdev->num_resources;
 	int err, i;
+	const struct of_device_id *match;
+	struct rockchip_iommu_data *data;
 
 	iommu = devm_kzalloc(dev, sizeof(*iommu), GFP_KERNEL);
 	if (!iommu)
 		return -ENOMEM;
 
+	match = of_match_device(rk_iommu_dt_ids, dev);
+	if (!match)
+		return -EINVAL;
+
+	data = (struct rockchip_iommu_data *)match->data;
+	iommu->version = data->version;
+	dev_info(dev, "version = %x\n", iommu->version);
+
 	platform_set_drvdata(pdev, iommu);
 	iommu->dev = dev;
 	iommu->num_mmu = 0;
@@ -1196,7 +1585,10 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	if (err)
 		goto err_put_group;
 
-	iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops);
+	if (iommu->version >= 0x2)
+		iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops_v2);
+	else
+		iommu_device_set_ops(&iommu->iommu, &rk_iommu_ops);
 	iommu_device_set_fwnode(&iommu->iommu, &dev->of_node->fwnode);
 
 	err = iommu_device_register(&iommu->iommu);
@@ -1211,7 +1603,10 @@ static int rk_iommu_probe(struct platform_device *pdev)
 	if (!dma_dev)
 		dma_dev = &pdev->dev;
 
-	bus_set_iommu(&platform_bus_type, &rk_iommu_ops);
+	if (iommu->version >= 0x2)
+		bus_set_iommu(&platform_bus_type, &rk_iommu_ops_v2);
+	else
+		bus_set_iommu(&platform_bus_type, &rk_iommu_ops);
 
 	pm_runtime_enable(dev);
 
@@ -1280,11 +1675,6 @@ static const struct dev_pm_ops rk_iommu_pm_ops = {
 				pm_runtime_force_resume)
 };
 
-static const struct of_device_id rk_iommu_dt_ids[] = {
-	{ .compatible = "rockchip,iommu" },
-	{ /* sentinel */ }
-};
-
 static struct platform_driver rk_iommu_driver = {
 	.probe = rk_iommu_probe,
 	.shutdown = rk_iommu_shutdown,
-- 
2.25.1



From nm at ti.com  Thu Apr 22 15:17:44 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 22 Apr 2021 09:17:44 -0500
Subject: [PATCH 4/4] dt-bindings: arm: keystone: Convert ti,sci to json
 schema
In-Reply-To: <20210421224041.GA1740292@robh.at.kernel.org>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-5-nm@ti.com>
 <20210421224041.GA1740292@robh.at.kernel.org>
Message-ID: <20210422141744.2imrochbzzt26wx4@slush>

On 17:40-20210421, Rob Herring wrote:

[..]

> > +allOf:
> > +  - $ref: /schemas/mbox/mbox-consumer.yaml#
> 
> Drop.
> 

OK.

> > +  reg-names:
> > +    description: |
> > +      Specifies the debug messages memory mapped region that is optionally
> > +      made available from TI-SCI controller.
> > +      - const: debug_messages
> 
> Drop the '-' and fix the indent so it's an actual schema.

OK.

[..]
> > +patternProperties:
> > +  # All other properties should be a power, clock or reset controller
> > +  "^(power-controller|clock-controller|reset-controller)$":
> > +    type: object
> > +    oneOf:
> > +      - $ref: /schemas/soc/ti/sci-pm-domain.yaml#
> > +      - $ref: /schemas/clock/ti,sci-clk.yaml#
> > +      - $ref: /schemas/reset/ti,sci-reset.yaml#
> 
> I'd prefer you separate these with a property for each node.

Hmm... I am not sure I completely understand your comment here.
I assume we dont want to duplicate each of those node yamls, so,
did you mean something like:

ti,sci-clk as a bool property in the tisci node and if present, then
expect the node ti,sci-clk node?

Can you give me a hint of similar yaml usage elsewhere that I can refer
to?

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


From nm at ti.com  Thu Apr 22 15:20:12 2021
From: nm at ti.com (Nishanth Menon)
Date: Thu, 22 Apr 2021 09:20:12 -0500
Subject: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to
 json schema
In-Reply-To: <20210421225212.GB1750844@robh.at.kernel.org>
References: <20210416222518.15801-1-nm@ti.com>
 <20210421225212.GB1750844@robh.at.kernel.org>
Message-ID: <20210422142012.lcjiy2gaoqllzlna@nervy>

On 17:52-20210421, Rob Herring wrote:
> On Fri, Apr 16, 2021 at 05:25:18PM -0500, Nishanth Menon wrote:
> > Convert linaro,optee-tz to json schema format for better documentation
> > and error checks.
> > 
> > NOTE:
> > 1. This change does introduce a stricter naming convention for
> >    optee nodes.
> > 2. We do have false positive checkpatch warning with this patch:
> >    "DT binding docs and includes should be a separate patch"
> 
> Not really something that needs to be in the commit msg. I'm aware of 
> the issue, just haven't gotten around to fixing it.

sure, thanks..
In this patch and my previous patches as well, I will move them all
to diffstat comment.

> > +properties:
> > +  $nodename:
> > +    const: 'optee'
> 
> Don't need quotes.

aarrgh.. yes, ofcourse.
> 
> > +
> > +  compatible:
> > +    const: linaro,optee-tz
> > +
> > +  method:
> > +    description: The method of calling the OP-TEE Trusted OS.
> > +    oneOf:
> > +      - description: |
> > +          SMC #0, with the register assignments specified
> > +          in drivers/tee/optee/optee_smc.h
> > +        items:
> > +          - const: smc
> > +      - description: |
> > +          HVC #0, with the register assignments specified
> > +          in drivers/tee/optee/optee_smc.h
> > +        items:
> > +          - const: hvc
> 
> Please just do 'enum: [ smc, hvc ]' and rework to a single description.

Sure, will do. thanks for the comments.

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


From lorenzo.pieralisi at arm.com  Thu Apr 22 15:23:42 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 22 Apr 2021 15:23:42 +0100
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <20210422142334.GA24087@lpieralisi>

On Wed, Apr 21, 2021 at 05:43:15PM +0100, Marc Zyngier wrote:
> Dann recently reported that his ThunderX machine failed to boot since
> 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
> interrupts"), with a not so pretty crash while trying to send an IPI.
> 
> It turned out to be caused by a mix of broken firmware and a buggy
> GTDT watchdog driver. Both have forever been buggy, but the above
> commit revealed that the error handling path of the driver was
> probably the worse part of it all.
> 
> Anyway, this short series has two goals:
> - handle broken firmware in a less broken way
> - make sure that the route cause of the problem can be identified
>   quickly
> 
> Thanks,
> 
> 	M.
> 
> Marc Zyngier (2):
>   ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
>   ACPI: irq: Prevent unregistering of GIC SGIs
> 
>  drivers/acpi/arm64/gtdt.c | 10 ++++++----
>  drivers/acpi/irq.c        |  6 +++++-
>  2 files changed, 11 insertions(+), 5 deletions(-)

Patch(2) needs an ACK from Rafael - usually these patches go via
the ARM64 tree but I don't think it is compulsory for this series.

Thank you !

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>


From wangkefeng.wang at huawei.com  Thu Apr 22 16:28:24 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Thu, 22 Apr 2021 23:28:24 +0800
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <YIEl8aKr8Ly0Zd3O@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
Message-ID: <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>


On 2021/4/22 15:29, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
>> On 2021/4/21 14:51, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>
>>> Hi,
>>>
>>> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
>>> pfn_valid_within() to 1.
>>>
>>> The idea is to mark NOMAP pages as reserved in the memory map and restore
>>> the intended semantics of pfn_valid() to designate availability of struct
>>> page for a pfn.
>>>
>>> With this the core mm will be able to cope with the fact that it cannot use
>>> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
>>> will be treated correctly even without the need for pfn_valid_within.
>>>
>>> The patches are only boot tested on qemu-system-aarch64 so I'd really
>>> appreciate memory stress tests on real hardware.
>>>
>>> If this actually works we'll be one step closer to drop custom pfn_valid()
>>> on arm64 altogether.
>> Hi Mike?I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
>> move_freepages_block()->move_freepages()
>> will be optimized, if there are holes in zone, the 'struce page'(memory map)
>> for pfn range of hole will be free by
>> free_memmap(), and then the page traverse in the zone(with holes) from
>> move_freepages() will meet the wrong page?
>> then it could panic at PageLRU(page) test, check link[1],
> First, HOLES_IN_ZONE name us hugely misleading, this configuration option
> has nothing to to with memory holes, but rather it is there to deal with
> holes or undefined struct pages in the memory map, when these holes can be
> inside a MAX_ORDER_NR_PAGES region.
>
> In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
> accessing *missing* struct pages, like those that are freed at
> free_memmap(). But on arm64 these tests also filter out the nomap entries
> because their struct pages are not initialized.
>
> The panic you refer to happened because there was an uninitialized struct
> page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
> nomap memory.
>
> With these changes I make sure that such pages will be properly initialized
> as PageReserved and the pfn walkers will be able to rely on the memory map.
>
> Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
> boundaries, so there will be no missing parts in the memory map within a
> MAX_ORDER_NR_PAGES region.

Ok, thanks, we met a same panic like the link on arm32(without 
HOLES_IN_ZONE),

the scheme for arm64 could be suit for arm32, right?? I will try the 
patchset with

some changes on arm32 and give some feedback.

Again, the stupid question, where will mark the region of memblock with

MEMBLOCK_NOMAP flag ?


>   
>> "The idea is to mark NOMAP pages as reserved in the memory map", I see the
>> patch2 check memblock_is_nomap() in memory region
>> of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
>> missed), then memmap_init_reserved_pages() won't
>> work, so should the HOLES_IN_ZONE still be needed for generic mm code?
>>
>> [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047 at arm.com/
>>


From u.kleine-koenig at pengutronix.de  Thu Apr 22 16:39:41 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 17:39:41 +0200
Subject: [PATCH v5 4/6] rtc: at91sma9: Simplify using
 devm_clk_get_enabled()
In-Reply-To: <YIEtVVE8ZdwbTTgM@ada-deb-carambola.ifak-system.com>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
 <20210422065726.1646742-5-u.kleine-koenig@pengutronix.de>
 <YIEtVVE8ZdwbTTgM@ada-deb-carambola.ifak-system.com>
Message-ID: <20210422153941.og3j76krdfw4mcyr@pengutronix.de>

On Thu, Apr 22, 2021 at 10:01:25AM +0200, Alexander Dahl wrote:
> Hello Uwe,
> 
> I think there's a typo in the subject.  It should be sam9 instead of
> sma9, right?

Ah indeed, thanks for spotting this. Will fix this for the next round.

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/20210422/31f575f4/attachment.sig>

From will at kernel.org  Thu Apr 22 17:07:53 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 17:07:53 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210421171005.GA46949@C02TD0UTHF1T.local>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <20210416133431.GA2303@C02TD0UTHF1T.local>
 <20210419121932.GA30004@willie-the-truck>
 <20210421171005.GA46949@C02TD0UTHF1T.local>
Message-ID: <20210422160752.GA2214@willie-the-truck>

Hi Mark,

On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote:
> On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote:
> > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> > > I think this is a problem we created for ourselves back in commit:
> > > 
> > >   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
> > > 
> > > AFAICT, the perf regs samples are the only place this matters, since for
> > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and
> > > audit expects the non-truncated return value. Other architectures don't
> > > truncate here, so I think we're setting ourselves up for a game of
> > > whack-a-mole to truncate and extend wherever we need to.
> > > 
> > > Given that, I suspect it'd be better to do something like the below.
> > > 
> > > Will, thoughts?
> > 
> > I think perf is one example, but this is also visible to userspace via the
> > native ptrace interface and I distinctly remember needing this for some
> > versions of arm64 strace to work correctly when tracing compat tasks.
> 
> FWIW, you've convinced me on your approach (more on that below), but
> when I went digging here this didn't seem to be exposed via ptrace --
> for any task tracing a compat task, the GPRs are exposed via
> compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving
> the lower 32 bits. See task_user_regset_view() for where we get the
> regset.
> 
> Am I missing something, or are you thinking of another issue you fixed
> at the same time?

I think it may depend on whether strace pokes at the GPRs or instead issues
a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details,
unfortunately. I do remember seeing an issue though, and it was only last
year.

> > So I do think that clearing the upper bits on the return path is the right
> > approach, but it sounds like we need some more work to handle syscall(-1)
> > and audit (what exactly is the problem here after these patches have been
> > applied?)
> 
> From digging a bit more, I think I agree, and I think these patches are
> sufficient for audit. I have some comments I'll leave separately.
> 
> The remaining issues are wherever we assign a signed value to a compat
> GPR without explicit truncation. That'll leak via perf sampling the user
> regs, but I haven't managed to convince myself whether that causes any
> functional change in behaviour for audit, seccomp, or syscall tracing.
> 
> Since we mostly use compat_ulong_t for intermediate values in compat
> code, it does look like this is only an issue for x0 where we assign an
> error value, e.g. the -ENOSYS case in el0_svc_common. I'll go see if I
> can find any more.
> 
> With those fixed up we can remove the x0 truncation from entry.S,
> which'd be nice too.

If we remove that then we should probably have a (debug?) check on the
return-to-user path just to make sure.

Will


From will at kernel.org  Thu Apr 22 17:08:48 2021
From: will at kernel.org (Will Deacon)
Date: Thu, 22 Apr 2021 17:08:48 +0100
Subject: [PATCH v4 00/16] kvm/arm: Align the VMID allocation with the
 arm64 ASID one
In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
Message-ID: <20210422160846.GB2214@willie-the-truck>

On Wed, Apr 14, 2021 at 12:22:56PM +0100, Shameer Kolothum wrote:
> Hi,
> 
> This is an attempt to revive this series originally posted by
> Julien Grall[1]. The main motive to work on this now is because
> of the requirement to have Pinned KVM VMIDs and the RFC discussion
> for the same basically suggested[2] to have a common/better vmid
> allocator for KVM which this series provides.
>  
> Major Changes from v3:
> 
> -Changes related to Pinned ASID support.
> -Changes to take care KPTI related bits reservation.
> -Dropped support for 32 bit KVM.
> -Rebase to 5.12-rc7
> 
> Individual patches have change history for any major changes
> from v3.
> 
> Tests were performed on a HiSilicon D06 platform and so far not observed
> any regressions.
> 
> For ASID allocation,
> 
> Avg of 10 runs(hackbench -s 512 -l 200 -g 300 -f 25 -P),
> 5.12-rc7: Time:18.8119
> 5.12-rc7+v4: Time: 18.459
> 
> ~1.8% improvement.
> 
> For KVM VMID,
> 
> The measurement was made with maxcpus set to 8 and with the
> number of VMID limited to 4-bit. The test involves running
> concurrently 40 guests with 2 vCPUs. Each guest will then
> execute hackbench 5 times before exiting.
> 
> The performance difference between the current algo and the
> new one are(ag. of 10 runs):
>     - 1.9% less exit from the guest
>     - 0.7% faster
> 
> For complete series, please see,
>  https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4
> 
> Please take a look and let me know your feedback.

Although I think aligning the two algorithms makes sense, I'm not completely
sold on the need to abstract all this into a library and whether the
additional indirection is justified.

It would be great to compare this approach with one where portions of the
code are duplicated into a separate VMID allocator. Have you tried that to
see what it looks like? Doesn't need to be a proper patch set, but comparing
the end result might help to evaluate the proposal here.

Will


From robh at kernel.org  Thu Apr 22 17:12:54 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 22 Apr 2021 11:12:54 -0500
Subject: [PATCH 4/4] dt-bindings: arm: keystone: Convert ti,
 sci to json schema
In-Reply-To: <20210422141744.2imrochbzzt26wx4@slush>
References: <20210416063721.20538-1-nm@ti.com>
 <20210416063721.20538-5-nm@ti.com>
 <20210421224041.GA1740292@robh.at.kernel.org>
 <20210422141744.2imrochbzzt26wx4@slush>
Message-ID: <CAL_JsqJFRdrffKbuBqt6hKks4jQFAm5X9yTji9O6q3UKsOVO3g@mail.gmail.com>

On Thu, Apr 22, 2021 at 9:17 AM Nishanth Menon <nm at ti.com> wrote:
>
> On 17:40-20210421, Rob Herring wrote:
>
> [..]
>
> > > +allOf:
> > > +  - $ref: /schemas/mbox/mbox-consumer.yaml#
> >
> > Drop.
> >
>
> OK.
>
> > > +  reg-names:
> > > +    description: |
> > > +      Specifies the debug messages memory mapped region that is optionally
> > > +      made available from TI-SCI controller.
> > > +      - const: debug_messages
> >
> > Drop the '-' and fix the indent so it's an actual schema.
>
> OK.
>
> [..]
> > > +patternProperties:
> > > +  # All other properties should be a power, clock or reset controller
> > > +  "^(power-controller|clock-controller|reset-controller)$":
> > > +    type: object
> > > +    oneOf:
> > > +      - $ref: /schemas/soc/ti/sci-pm-domain.yaml#
> > > +      - $ref: /schemas/clock/ti,sci-clk.yaml#
> > > +      - $ref: /schemas/reset/ti,sci-reset.yaml#
> >
> > I'd prefer you separate these with a property for each node.
>
> Hmm... I am not sure I completely understand your comment here.
> I assume we dont want to duplicate each of those node yamls, so,
> did you mean something like:
>
> ti,sci-clk as a bool property in the tisci node and if present, then
> expect the node ti,sci-clk node?
>
> Can you give me a hint of similar yaml usage elsewhere that I can refer
> to?

Just do:

properties:
  power-controller:
    type: object
    $ref: /schemas/soc/ti/sci-pm-domain.yaml#

And so on for clock-controller and reset-controller.

Rob


From hayashi.kunihiko at socionext.com  Thu Apr 22 17:13:08 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 01:13:08 +0900
Subject: [PATCH v10 3/3] PCI: uniphier: Add misc interrupt handler to
 invoke PME and AER
In-Reply-To: <20210414194654.GA2526782@bjorn-Precision-5520>
References: <20210414194654.GA2526782@bjorn-Precision-5520>
Message-ID: <53a0792c-3bb8-723a-f5b0-7ef59533fad5@socionext.com>

Hi Bjorn,

On 2021/04/15 4:46, Bjorn Helgaas wrote:
> On Sat, Apr 10, 2021 at 01:22:18AM +0900, Kunihiko Hayashi wrote:
>> This patch adds misc interrupt handler to detect and invoke PME/AER event.
>>
>> In UniPhier PCIe controller, PME/AER signals are assigned to the same
>> signal as MSI by the internal logic. These signals should be detected by
>> the internal register, however, DWC MSI handler can't handle these signals.
>>
>> DWC MSI handler calls .msi_host_isr() callback function, that detects
>> PME/AER signals using the internal register and invokes the interrupt
>> with PME/AER vIRQ numbers.
>>
>> These vIRQ numbers is obtained by uniphier_pcie_port_get_irq() function,
>> that finds the device that matches PME/AER from the devices associated
>> with Root Port, and returns its vIRQ number.
> 
> Why do you use the term "vIRQ"?  What exactly is a vIRQ?  It seems no
> different than the simple "irq" as stored in pci_dev.irq or
> pcie_device.irq and passed to generic_handle_irq().  "virq" is also
> used in the patch, so if you change one, please change the other as
> well.
Indeed, I used "virq" in contrast to "hwirq", but that seems wrong.
This interrupt number is equivarent to pci_dev.irq, so I'll fix it.

Thank you,

---
Best Regards
Kunihiko Hayashi


From kuba at kernel.org  Thu Apr 22 17:26:08 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Thu, 22 Apr 2021 09:26:08 -0700
Subject: [PATCH net-next 12/14] net: ethernet: mtk_eth_soc: reduce
 unnecessary interrupts
In-Reply-To: <20210422040914.47788-13-ilya.lipnitskiy@gmail.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-13-ilya.lipnitskiy@gmail.com>
Message-ID: <20210422092608.6b8ed5ff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, 21 Apr 2021 21:09:12 -0700 Ilya Lipnitskiy wrote:
> @@ -1551,8 +1551,9 @@ static int mtk_napi_rx(struct napi_struct *napi, int budget)
>  		remain_budget -= rx_done;
>  		goto poll_again;
>  	}
> -	napi_complete(napi);
> -	mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
> +
> +	if (napi_complete(napi))
> +		mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);

Why not napi_complete_done(napi, rx_done + budget - remain_budget)?
(Modulo possible elimination of rx_done in this function.)


From krzysztof.kozlowski at canonical.com  Thu Apr 22 17:31:21 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Thu, 22 Apr 2021 18:31:21 +0200
Subject: [PATCH v2] hwrng: exynos - Fix runtime PM imbalance on error
In-Reply-To: <dleftj35vi7ee0.fsf%l.stelmach@samsung.com>
References: <bc20ae4c-3e62-7b07-506c-ce8d90f65754@canonical.com>
 <CGME20210422112224eucas1p283ca7aeaa25ab514b9743a11e63a76e0@eucas1p2.samsung.com>
 <dleftj35vi7ee0.fsf%l.stelmach@samsung.com>
Message-ID: <a8bdb9e0-cbe3-85d5-c9ac-619445471b41@canonical.com>

On 22/04/2021 13:22, ?ukasz Stelmach wrote:
> It was <2021-04-22 czw 12:46>, when Krzysztof Kozlowski wrote:
>> On 22/04/2021 12:41, ?ukasz Stelmach wrote:
>>> pm_runtime_get_sync() increments the runtime PM usage counter even
>>> the call returns an error code. Thus a pairing decrement is needed
>>> on the error handling path to keep the counter balanced.
>>
>> It's exactly the same as Dinghao's patch:
>> https://lore.kernel.org/linux-samsung-soc/20200522011659.26727-1-dinghao.liu at zju.edu.cn/
>> which you reviewed. It has even the same commit msg
>> (although it's difficult to be creative here).
>>
>> I think it's better to resend his patch instead.
> 
> It isn't the same because it uses pm_runtime_put_noidle() as discussed
> here[1], applied here[2] and advised here[2]. Dinghao didn't prepare
> v3[4] for exynos.

Thanks, makes sense but then I would prefer Marek's approach of
pm_runtime_resume_and_get().

Best regards,
Krzysztof


From u.kleine-koenig at pengutronix.de  Thu Apr 22 17:35:37 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 22 Apr 2021 18:35:37 +0200
Subject: [PATCH v5 5/6] i2c: imx: Simplify using devm_clk_get_enableded()
In-Reply-To: <20210422065726.1646742-6-u.kleine-koenig@pengutronix.de>
References: <20210422065726.1646742-1-u.kleine-koenig@pengutronix.de>
 <20210422065726.1646742-6-u.kleine-koenig@pengutronix.de>
Message-ID: <20210422163537.skhdsfafweel6sti@pengutronix.de>

On Thu, Apr 22, 2021 at 08:57:25AM +0200, Uwe Kleine-K?nig wrote:
> devm_clk_get_enabled() returns the clk already (prepared and) enabled
> and the automatically called cleanup cares for disabling (and
> unpreparing). So simplify .probe() and .remove() accordingly.
> 
> Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>
> Acked-by: Wolfram Sang <wsa at kernel.org>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

A propos typos: This patch needs $Subject ~= s/enableded/enabled/

Will fix this for the next submission round.

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/20210422/e60d5f51/attachment.sig>

From mark.rutland at arm.com  Thu Apr 22 17:42:28 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 22 Apr 2021 17:42:28 +0100
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210422160752.GA2214@willie-the-truck>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <20210416133431.GA2303@C02TD0UTHF1T.local>
 <20210419121932.GA30004@willie-the-truck>
 <20210421171005.GA46949@C02TD0UTHF1T.local>
 <20210422160752.GA2214@willie-the-truck>
Message-ID: <20210422164228.GD66392@C02TD0UTHF1T.local>

On Thu, Apr 22, 2021 at 05:07:53PM +0100, Will Deacon wrote:
> On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote:
> > On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote:
> > > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> > > > I think this is a problem we created for ourselves back in commit:
> > > > 
> > > >   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
> > > > 
> > > > AFAICT, the perf regs samples are the only place this matters, since for
> > > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and
> > > > audit expects the non-truncated return value. Other architectures don't
> > > > truncate here, so I think we're setting ourselves up for a game of
> > > > whack-a-mole to truncate and extend wherever we need to.
> > > > 
> > > > Given that, I suspect it'd be better to do something like the below.
> > > > 
> > > > Will, thoughts?
> > > 
> > > I think perf is one example, but this is also visible to userspace via the
> > > native ptrace interface and I distinctly remember needing this for some
> > > versions of arm64 strace to work correctly when tracing compat tasks.
> > 
> > FWIW, you've convinced me on your approach (more on that below), but
> > when I went digging here this didn't seem to be exposed via ptrace --
> > for any task tracing a compat task, the GPRs are exposed via
> > compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving
> > the lower 32 bits. See task_user_regset_view() for where we get the
> > regset.
> > 
> > Am I missing something, or are you thinking of another issue you fixed
> > at the same time?
> 
> I think it may depend on whether strace pokes at the GPRs or instead issues
> a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details,
> unfortunately. I do remember seeing an issue though, and it was only last
> year.

Ah; I hadn't spotted PTRACE_GET_SYSCALL_INFO, thanks for the pointer. I
see that gets at the regs via syscall_get_arguments(), which doesn't
truncate them.

That makes me wonder whether x86 and others do the right thing here...

> > > So I do think that clearing the upper bits on the return path is the right
> > > approach, but it sounds like we need some more work to handle syscall(-1)
> > > and audit (what exactly is the problem here after these patches have been
> > > applied?)
> > 
> > From digging a bit more, I think I agree, and I think these patches are
> > sufficient for audit. I have some comments I'll leave separately.
> > 
> > The remaining issues are wherever we assign a signed value to a compat
> > GPR without explicit truncation. That'll leak via perf sampling the user
> > regs, but I haven't managed to convince myself whether that causes any
> > functional change in behaviour for audit, seccomp, or syscall tracing.
> > 
> > Since we mostly use compat_ulong_t for intermediate values in compat
> > code, it does look like this is only an issue for x0 where we assign an
> > error value, e.g. the -ENOSYS case in el0_svc_common. I'll go see if I
> > can find any more.
> > 
> > With those fixed up we can remove the x0 truncation from entry.S,
> > which'd be nice too.
> 
> If we remove that then we should probably have a (debug?) check on the
> return-to-user path just to make sure.

I've hacked that up locally; I'd certainly like to run that along with
some other sanity checks (e.g. PSTATE) while fuzzing, but agree that's
probably not something to enable in any defconfig build.

I'm happy to add that later as and when I remove the bit from entry.S.

Thanks,
Mark.


From broonie at kernel.org  Thu Apr 22 17:42:23 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 22 Apr 2021 17:42:23 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
Message-ID: <20210422164223.GA36209@sirena.org.uk>

On Tue, Apr 20, 2021 at 09:34:02AM +0100, Joe Burmeister wrote:
> It was previoulsy possible to have a device tree with more chips than
> the driver supports and go off the end of CS arrays.
> 
> This patches inforces CS limit but sets that limit to the max of the
> default limit and what is in the device tree when driver is loaded.

This doesn't apply against current code, please check and resend.

Also s/previoulsy/previously/ and s/inforces/enforces/
-------------- 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/20210422/e4297be6/attachment.sig>

From broonie at kernel.org  Thu Apr 22 17:48:45 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 22 Apr 2021 17:48:45 +0100
Subject: [PATCH] [v2] spi: stm32-qspi: fix debug format string
In-Reply-To: <20210422134955.1988316-1-arnd@kernel.org>
References: <20210422134955.1988316-1-arnd@kernel.org>
Message-ID: <161911005747.37738.3439795331125402090.b4-ty@kernel.org>

On Thu, 22 Apr 2021 15:38:57 +0200, Arnd Bergmann wrote:
> Printing size_t needs a special %zx format modifier to avoid a
> warning like:
> 
> drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here
>   481 |         dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);
> 
> Patrice already tried to fix this, but picked %lx instead of %zx,
> which fixed some architectures but broke others in the same way.
> Using %zx works everywhere.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: stm32-qspi: fix debug format string
      commit: 14ef64ebdc2a4564893022780907747567452f6c

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 Apr 22 17:48:46 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 22 Apr 2021 17:48:46 +0100
Subject: [PATCH] spi: stm32-qspi: fix debug format string
In-Reply-To: <20210421140653.3964725-1-arnd@kernel.org>
References: <20210421140653.3964725-1-arnd@kernel.org>
Message-ID: <161911005747.37738.11400279333623304352.b4-ty@kernel.org>

On Wed, 21 Apr 2021 16:06:48 +0200, Arnd Bergmann wrote:
> Printing size_t needs a special %zd format modifier to avoid a
> warning like:
> 
> drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here
>   481 |         dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf);

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: stm32-qspi: fix debug format string
      commit: 14ef64ebdc2a4564893022780907747567452f6c

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 f.fainelli at gmail.com  Thu Apr 22 17:50:47 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 22 Apr 2021 09:50:47 -0700
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
Message-ID: <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>



On 4/20/2021 1:34 AM, Joe Burmeister wrote:
> It was previoulsy possible to have a device tree with more chips than
> the driver supports and go off the end of CS arrays.

Do you mind walking me through the code how that could have happened? We
have spi_register_controller() call of_spi_get_gpio_numbers() which has
the following:

ctlr->num_chipselect = max_t(int, nb, ctlr->num_chipselect);

such that what the controller has is the maximum between the number of
'cs-gpios' properties parsed and what was already populated in
ctrl->num_chipselect during bcm2835_spi_probe(), which for this driver
is BCM2835_SPI_NUM_CS (3).

> 
> This patches inforces CS limit but sets that limit to the max of the
> default limit and what is in the device tree when driver is loaded.
> 
> Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>

You have changed many more things that just enforcing a limit on
BCM2835_SPI_NUM_CS you have now made all chip-select related data
structuresd dynamically allocated and you have changed a number of
prints to use the shorthand "dev" instead of &pdev->dev.
-- 
Florian


From mark.rutland at arm.com  Thu Apr 22 17:55:45 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 22 Apr 2021 17:55:45 +0100
Subject: [PATCH 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210421174105.GB52940@C02TD0UTHF1T.local>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416075533.7720-2-zhe.he@windriver.com>
 <20210421174105.GB52940@C02TD0UTHF1T.local>
Message-ID: <20210422165545.GE66392@C02TD0UTHF1T.local>

On Wed, Apr 21, 2021 at 06:41:05PM +0100, Mark Rutland wrote:
> On Fri, Apr 16, 2021 at 03:55:32PM +0800, He Zhe wrote:
> > Add sign extension handling in syscall_get_return_value so that it can
> > handle 32-bit compatible case and can be used by for example audit, just
> > like what syscall_get_error does.
> 
> If a compat syscall can ever legitimately return a non-error value with
> bit 31 set, and this sign-extends it, is that ever going to reach
> userspace as a 64-bit value?
> 
> IIUC things like mmap() can return pointers above 2GiB for a compat
> task, so I'm a bit uneasy that we'd handle those wrong. I can't see a
> way of preventing that unless we keep the upper 32 bits for errors.

Looking at this with fresh eyes, I think we can more closely mirror
syscall_get_error(), and do something like:

static inline long syscall_get_return_value(struct task_struct *task,
					    struct pt_regs *regs)
{
	long val = regs->regs[0];
	long error = val;

	if (is_compat_thread(task_thread_info(task)))
		error = sign_extend64(error, 31);
	
	return IS_ERR_VALUE(error) ? error : val;
}

Thanks,
Mark.

> 
> Mark.
> 
> > 
> > Signed-off-by: He Zhe <zhe.he at windriver.com>
> > ---
> >  arch/arm64/include/asm/syscall.h | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
> > index cfc0672013f6..cd7a22787aeb 100644
> > --- a/arch/arm64/include/asm/syscall.h
> > +++ b/arch/arm64/include/asm/syscall.h
> > @@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct *task,
> >  static inline long syscall_get_return_value(struct task_struct *task,
> >  					    struct pt_regs *regs)
> >  {
> > -	return regs->regs[0];
> > +	long val = regs->regs[0];
> > +
> > +	if (is_compat_thread(task_thread_info(task)))
> > +		val = sign_extend64(val, 31);
> > +
> > +	return val;
> >  }
> >  
> >  static inline void syscall_set_return_value(struct task_struct *task,
> > -- 
> > 2.17.1
> > 


From mathieu.poirier at linaro.org  Thu Apr 22 17:56:34 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 22 Apr 2021 10:56:34 -0600
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
Message-ID: <20210422165634.GD1256950@xps15>

On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> V5:
>  Add R-b tag
>  Move the change in detect mode of patch 5 to patch 7 Per Mathieu's
>  comments
> 
> V4:
>  Typo fix
>  patch 4: take state as a check condition
>  patch 5: move regmap lookup/attach to imx_rproc_detect_mode
>  patch 6: add imx_rproc_clk_enable for optional clk
>  patch 8: use switch/case in imx_rproc_detect_mode
> V3:
>  Add A-b tag for Patch 1/2
>  Fix the checkpatch warning for Patch 6,8
> 
> V2:
>  Patch 1/8, use fsl as vendor, typo fix
>  Because patchset [1] has v2 version, patch 5,6,7,8 are adapted that
>  change.
> 
> This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
> parse fsl,auto-boot
> 

One of the request I had from the last revision was to explicitly list what
other patchset this work depends on and what branch it is based of, something I
can't find here.

As such I am dropping this set and won't look at another revision before May
22nd.

> Peng Fan (8):
>   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
>   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
>   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
>   remoteproc: imx_rproc: parse fsl,auto-boot
>   remoteproc: imx_rproc: initial support for mutilple start/stop method
>   remoteproc: imx_rproc: make clk optional
>   remoteproc: imx_rproc: support i.MX7ULP
>   remoteproc: imx_rproc: support i.MX8MN/P
> 
>  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
>  drivers/remoteproc/imx_rproc.c                | 196 +++++++++++++++---
>  2 files changed, 173 insertions(+), 34 deletions(-)
> 
> -- 
> 2.30.0
> 


From hayashi.kunihiko at socionext.com  Thu Apr 22 18:04:54 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:04:54 +0900
Subject: [PATCH v11 0/3] PCI: uniphier: Add PME/AER support for UniPhier PCIe
 host controller
Message-ID: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>

This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.

Changes since v10:
- Fix comment style in the header
- Fix "virq" and "vIRQ" in variable name and description to "irq" and "IRQ"

Changes since v9:
- Fix the description of pcie_prot_service_get_irq()

Changes since v8:
- Add uniphier_pcie_host_init_complete() that finds PME/AER IRQ number
  after calling dw_pcie_host_init()
- Add conditions to depend on CONFIG_PCIE_PME and CONFIG_PCIEAER instead
  of CONFIG_PCIEPORTBUS
- Add Acked-by: line to portdrv patch

Changes since v7:
- Add Reviewed-by: line to 1st and 3rd patches

Changes since v6:
- Separate patches for iATU and phy error from this series
- Add Reviewed-by: line to dwc patch

Changes since v5:
- Add pcie_port_service_get_irq() function to pcie/portdrv
- Call pcie_port_service_get_irq() to get IRQ interrupt number for PME/AER
- Rebase to the latest linux-next branch,
  and remove devm_platform_ioremap_resource_byname() replacement patch

Changes since v4:
- Add Acked-by: line to dwc patch

Changes since v3:
- Move msi_host_isr() call into dw_handle_msi_irq()
- Move uniphier_pcie_misc_isr() call into the guard of chained_irq
- Use a bool argument is_msi instead of pci_msi_enabled()
- Consolidate handler calls for the same interrupt
- Fix typos in commit messages

Changes since v2:
- Avoid printing phy error message in case of EPROBE_DEFER
- Fix iATU register mapping method
- dt-bindings: Add Acked-by: line
- Fix typos in commit messages
- Use devm_platform_ioremap_resource_byname()

Changes since v1:
- Add check if struct resource is NULL
- Fix warning in the type of dev_err() argument

Kunihiko Hayashi (3):
  PCI: portdrv: Add pcie_port_service_get_irq() function
  PCI: dwc: Add msi_host_isr() callback
  PCI: uniphier: Add misc interrupt handler to invoke PME and AER

 drivers/pci/controller/dwc/pcie-designware-host.c |   3 +
 drivers/pci/controller/dwc/pcie-designware.h      |   1 +
 drivers/pci/controller/dwc/pcie-uniphier.c        | 105 +++++++++++++++++++---
 drivers/pci/pcie/portdrv.h                        |   1 +
 drivers/pci/pcie/portdrv_core.c                   |  16 ++++
 5 files changed, 112 insertions(+), 14 deletions(-)

-- 
2.7.4



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:04:55 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:04:55 +0900
Subject: [PATCH v11 1/3] PCI: portdrv: Add pcie_port_service_get_irq() function
In-Reply-To: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1619111097-10232-2-git-send-email-hayashi.kunihiko@socionext.com>

Add pcie_port_service_get_irq() that returns the virtual IRQ number
for specified portdrv service.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/pcie/portdrv.h      |  1 +
 drivers/pci/pcie/portdrv_core.c | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
index 2ff5724..628a3de 100644
--- a/drivers/pci/pcie/portdrv.h
+++ b/drivers/pci/pcie/portdrv.h
@@ -144,4 +144,5 @@ static inline void pcie_pme_interrupt_enable(struct pci_dev *dev, bool en) {}
 #endif /* !CONFIG_PCIE_PME */
 
 struct device *pcie_port_find_device(struct pci_dev *dev, u32 service);
+int pcie_port_service_get_irq(struct pci_dev *dev, u32 service);
 #endif /* _PORTDRV_H_ */
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e1fed664..93027d3 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -478,6 +478,22 @@ struct device *pcie_port_find_device(struct pci_dev *dev,
 EXPORT_SYMBOL_GPL(pcie_port_find_device);
 
 /**
+ * pcie_port_service_get_irq - get irq of the service
+ * @dev: PCI Express port the service is associated with
+ * @service: For the service to find
+ *
+ * Get irq number associated with given service on a pci_dev
+ */
+int pcie_port_service_get_irq(struct pci_dev *dev, u32 service)
+{
+	struct pcie_device *pciedev;
+
+	pciedev = to_pcie_device(pcie_port_find_device(dev, service));
+
+	return pciedev->irq;
+}
+
+/**
  * pcie_port_device_remove - unregister PCI Express port service devices
  * @dev: PCI Express port the service devices to unregister are associated with
  *
-- 
2.7.4



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:04:56 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:04:56 +0900
Subject: [PATCH v11 2/3] PCI: dwc: Add msi_host_isr() callback
In-Reply-To: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1619111097-10232-3-git-send-email-hayashi.kunihiko@socionext.com>

This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.

For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Jingoo Han <jingoohan1 at gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 drivers/pci/controller/dwc/pcie-designware-host.c | 3 +++
 drivers/pci/controller/dwc/pcie-designware.h      | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 24192b4..2e5ad68 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -61,6 +61,9 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
 	irqreturn_t ret = IRQ_NONE;
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 
+	if (pp->ops->msi_host_isr)
+		pp->ops->msi_host_isr(pp);
+
 	num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
 
 	for (i = 0; i < num_ctrls; i++) {
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 7d6e9b75..c90960f 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -175,6 +175,7 @@ enum dw_pcie_device_mode {
 struct dw_pcie_host_ops {
 	int (*host_init)(struct pcie_port *pp);
 	int (*msi_host_init)(struct pcie_port *pp);
+	void (*msi_host_isr)(struct pcie_port *pp);
 };
 
 struct pcie_port {
-- 
2.7.4



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:04:57 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:04:57 +0900
Subject: [PATCH v11 3/3] PCI: uniphier: Add misc interrupt handler to invoke
 PME and AER
In-Reply-To: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619111097-10232-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1619111097-10232-4-git-send-email-hayashi.kunihiko@socionext.com>

This patch adds misc interrupt handler to detect and invoke PME/AER event.

In UniPhier PCIe controller, PME/AER signals are assigned to the same
signal as MSI by the internal logic. These signals should be detected by
the internal register, however, DWC MSI handler can't handle these signals.

DWC MSI handler calls .msi_host_isr() callback function, that detects
PME/AER signals using the internal register and invokes the interrupt
with PME/AER IRQ numbers.

These IRQ numbers is obtained by uniphier_pcie_port_get_irq() function,
that finds the device that matches PME/AER from the devices associated
with Root Port, and returns its IRQ number.

Cc: Marc Zyngier <maz at kernel.org>
Cc: Jingoo Han <jingoohan1 at gmail.com>
Cc: Gustavo Pimentel <gustavo.pimentel at synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 drivers/pci/controller/dwc/pcie-uniphier.c | 105 +++++++++++++++++++++++++----
 1 file changed, 91 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 7e8bad3..dcd8fa8 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -21,6 +21,7 @@
 #include <linux/reset.h>
 
 #include "pcie-designware.h"
+#include "../../pcie/portdrv.h"
 
 #define PCL_PINCTRL0			0x002c
 #define PCL_PERST_PLDN_REGEN		BIT(12)
@@ -44,7 +45,9 @@
 #define PCL_SYS_AUX_PWR_DET		BIT(8)
 
 #define PCL_RCV_INT			0x8108
+#define PCL_RCV_INT_ALL_INT_MASK	GENMASK(28, 25)
 #define PCL_RCV_INT_ALL_ENABLE		GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK	GENMASK(12, 9)
 #define PCL_CFG_BW_MGT_STATUS		BIT(4)
 #define PCL_CFG_LINK_AUTO_BW_STATUS	BIT(3)
 #define PCL_CFG_AER_RC_ERR_MSI_STATUS	BIT(2)
@@ -68,6 +71,8 @@ struct uniphier_pcie_priv {
 	struct reset_control *rst;
 	struct phy *phy;
 	struct irq_domain *legacy_irq_domain;
+	int aer_irq;
+	int pme_irq;
 };
 
 #define to_uniphier_pcie(x)	dev_get_drvdata((x)->dev)
@@ -164,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
 
 static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
 {
-	writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+	u32 val;
+
+	val = PCL_RCV_INT_ALL_ENABLE;
+	if (pci_msi_enabled())
+		val |= PCL_RCV_INT_ALL_INT_MASK;
+	else
+		val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+	writel(val, priv->base + PCL_RCV_INT);
 	writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
 }
 
@@ -228,28 +241,51 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
 	.map = uniphier_pcie_intx_map,
 };
 
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp, bool is_msi)
 {
-	struct pcie_port *pp = irq_desc_get_handler_data(desc);
 	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
-	struct irq_chip *chip = irq_desc_get_chip(desc);
-	unsigned long reg;
-	u32 val, bit, virq;
+	u32 val;
 
-	/* INT for debug */
 	val = readl(priv->base + PCL_RCV_INT);
 
 	if (val & PCL_CFG_BW_MGT_STATUS)
 		dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
 	if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
 		dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
-	if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
-		dev_dbg(pci->dev, "Root Error\n");
-	if (val & PCL_CFG_PME_MSI_STATUS)
-		dev_dbg(pci->dev, "PME Interrupt\n");
+
+	if (is_msi) {
+		if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
+			dev_dbg(pci->dev, "Root Error Status\n");
+			if (priv->aer_irq)
+				generic_handle_irq(priv->aer_irq);
+		}
+
+		if (val & PCL_CFG_PME_MSI_STATUS) {
+			dev_dbg(pci->dev, "PME Interrupt\n");
+			if (priv->pme_irq)
+				generic_handle_irq(priv->pme_irq);
+		}
+	}
 
 	writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_msi_host_isr(struct pcie_port *pp)
+{
+	uniphier_pcie_misc_isr(pp, true);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+	struct pcie_port *pp = irq_desc_get_handler_data(desc);
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+	struct irq_chip *chip = irq_desc_get_chip(desc);
+	unsigned long reg;
+	u32 val, bit, irq;
+
+	uniphier_pcie_misc_isr(pp, false);
 
 	/* INTx */
 	chained_irq_enter(chip, desc);
@@ -258,8 +294,8 @@ static void uniphier_pcie_irq_handler(struct irq_desc *desc)
 	reg = FIELD_GET(PCL_RCV_INTX_ALL_STATUS, val);
 
 	for_each_set_bit(bit, &reg, PCI_NUM_INTX) {
-		virq = irq_linear_revmap(priv->legacy_irq_domain, bit);
-		generic_handle_irq(virq);
+		irq = irq_linear_revmap(priv->legacy_irq_domain, bit);
+		generic_handle_irq(irq);
 	}
 
 	chained_irq_exit(chip, desc);
@@ -317,8 +353,45 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
 	return 0;
 }
 
+static int uniphier_pcie_port_get_irq(struct pcie_port *pp, u32 service)
+{
+	struct pci_dev *pcidev;
+	int irq = 0;
+
+	if (!IS_ENABLED(CONFIG_PCIEAER) && !IS_ENABLED(CONFIG_PCIE_PME))
+		return 0;
+
+	/*
+	 * Finds the device that matches 'service' from the devices
+	 * associated with Root Port, and returns its IRQ number.
+	 */
+	list_for_each_entry(pcidev, &pp->bridge->bus->devices, bus_list) {
+		irq = pcie_port_service_get_irq(pcidev, service);
+		if (irq)
+			break;
+	}
+
+	return irq;
+}
+
+static int uniphier_pcie_host_init_complete(struct pcie_port *pp)
+{
+	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+	struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+
+	if (IS_ENABLED(CONFIG_PCIE_PME))
+		priv->pme_irq =
+			uniphier_pcie_port_get_irq(pp, PCIE_PORT_SERVICE_PME);
+	if (IS_ENABLED(CONFIG_PCIEAER))
+		priv->aer_irq =
+			uniphier_pcie_port_get_irq(pp, PCIE_PORT_SERVICE_AER);
+
+	return 0;
+}
+
 static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
 	.host_init = uniphier_pcie_host_init,
+	.msi_host_isr = uniphier_pcie_msi_host_isr,
 };
 
 static int uniphier_pcie_host_enable(struct uniphier_pcie_priv *priv)
@@ -398,7 +471,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
 
 	priv->pci.pp.ops = &uniphier_pcie_host_ops;
 
-	return dw_pcie_host_init(&priv->pci.pp);
+	ret = dw_pcie_host_init(&priv->pci.pp);
+	if (ret)
+		return ret;
+
+	return uniphier_pcie_host_init_complete(&priv->pci.pp);
 }
 
 static const struct of_device_id uniphier_pcie_match[] = {
-- 
2.7.4



From ezequiel at collabora.com  Thu Apr 22 18:16:53 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Thu, 22 Apr 2021 14:16:53 -0300
Subject: [PATCH v2 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to
 DT schema
In-Reply-To: <20210422141602.350746-2-benjamin.gaignard@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
 <20210422141602.350746-2-benjamin.gaignard@collabora.com>
Message-ID: <7557bc8aaaa1924ad39676b32ba6a3f6474a3722.camel@collabora.com>

(Adding Kever)

Hi Benjamin,

Thanks a lot for working on this, it looks amazing. Together with the great work
that Rockchip is doing, it seems RK3566/RK3568 will have decent support very soon.

One comment here:

On Thu, 2021-04-22 at 16:15 +0200, Benjamin Gaignard wrote:
> Convert Rockchip IOMMU to DT schema
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> ---
> version 2:
> ?- Change maintainer
> ?- Change reg maxItems
> ?- Change interrupt maxItems
> 
> ?.../bindings/iommu/rockchip,iommu.txt???????? | 38 ---------
> ?.../bindings/iommu/rockchip,iommu.yaml??????? | 79 +++++++++++++++++++
> ?2 files changed, 79 insertions(+), 38 deletions(-)
> ?delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> ?create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> deleted file mode 100644
> index 6ecefea1c6f9..000000000000
> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -Rockchip IOMMU
> -==============
> -
> -A Rockchip DRM iommu translates io virtual addresses to physical addresses for
> -its master device.? Each slave device is bound to a single master device, and
> -shares its clocks, power domain and irq.
> -
> -Required properties:
> -- compatible????? : Should be "rockchip,iommu"
> -- reg???????????? : Address space for the configuration registers
> -- interrupts????? : Interrupt specifier for the IOMMU instance
> -- interrupt-names : Interrupt name for the IOMMU instance
> -- #iommu-cells??? : Should be <0>.? This indicates the iommu is a
> -??????????????????? "single-master" device, and needs no additional information
> -??????????????????? to associate with its master device.? See:
> -??????????????????? Documentation/devicetree/bindings/iommu/iommu.txt
> -- clocks????????? : A list of clocks required for the IOMMU to be accessible by
> -??????????????????? the host CPU.
> -- clock-names???? : Should contain the following:
> -???????"iface" - Main peripheral bus clock (PCLK/HCL) (required)
> -???????"aclk"? - AXI bus clock (required)
> -
> -Optional properties:
> -- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> -????????????????????????????? Some mmu instances may produce unexpected results
> -????????????????????????????? when the reset operation is used.
> -
> -Example:
> -
> -???????vopl_mmu: iommu at ff940300 {
> -???????????????compatible = "rockchip,iommu";
> -???????????????reg = <0xff940300 0x100>;
> -???????????????interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> -???????????????interrupt-names = "vopl_mmu";
> -???????????????clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
> -???????????????clock-names = "aclk", "iface";
> -???????????????#iommu-cells = <0>;
> -???????};
> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> new file mode 100644
> index 000000000000..0db208cf724a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip IOMMU
> +
> +maintainers:
> +? - Heiko Stuebner <heiko at sntech.de>
> +
> +description: |+
> +? A Rockchip DRM iommu translates io virtual addresses to physical addresses for
> +? its master device. Each slave device is bound to a single master device and
> +? shares its clocks, power domain and irq.
> +
> +? For information on assigning IOMMU controller to its peripheral devices,
> +? see generic IOMMU bindings.
> +
> +properties:
> +? compatible:
> +??? const: rockchip,iommu
> +
> +? reg:
> +??? minItems: 1
> +??? maxItems: 2
> +
> +? interrupts:
> +??? minItems: 1
> +??? maxItems: 2
> +
> +? interrupt-names:
> +??? minItems: 1
> +??? maxItems: 2
> +

AFAICS, the driver supports handling multiple MMUs, and there's one reg and
interrupt cell for each MMU. IOW, there's no requirement that maxItems is 2.

Is there any way we can describe that? Or maybe just allow a bigger maximum?

Thanks,
Ezequiel



From ezequiel at collabora.com  Thu Apr 22 18:23:15 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Thu, 22 Apr 2021 14:23:15 -0300
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <11131098.F0gNSz5aLb@diego>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com> <11131098.F0gNSz5aLb@diego>
Message-ID: <7d1f197d868ae84a8bc475f1f48178d2737518c1.camel@collabora.com>

Hi Liang,

I'm very impressed Rockchip is pushing patches so early, thanks a lot!

See below.

On Wed, 2021-04-21 at 11:13 +0200, Heiko St?bner wrote:
> Hi Liang,
> 
> Am Mittwoch, 21. April 2021, 08:59:20 CEST schrieb cl at rock-chips.com:
> > From: Liang Chen <cl at rock-chips.com>
> > 
> > RK3568 is a high-performance and low power quad-core application processor
> > designed for personal mobile internet device and AIoT equipments.
> > 
> > This patch add basic core dtsi file for it.
> > 
> > Signed-off-by: Liang Chen <cl at rock-chips.com>
> 
> this is a first round of basic stuff :-) .
> 
> First of all, I really like the move of moving the pretty standardized
> pinconfig entries to the rockchip-pinconf.dtsi .
> 
> (1) But please move this into a separate patch to make that more visible
> and maybe even convert _some_ or all arm64 Rockchip socs to use that
> as well
> 
> "arm64: dts: rockchip: add generic pinconfig settings used by most Rockchip socs
> 
> The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
> so move them to a shared dtsi to be included, instead of redefining them
> for each soc"
> 
> (2) I also like the external rk3568-pinctrl approach with the dtsi getting
> auto-generated. This will probably help us in keeping pinctrl settings
> synchronous between mainline and the vendor kernel.
> 
> (3) From my basic understanding the rk3568 is basically a rk3566 + more
> peripherals, so ideally they would share the basic ones in a rk3566.dtsi
> which the rk3568.dtsi then could include and extend with its additional
> peripherals.
> 
> With at least the pine64 boards being based on the rk3566, there probably
> will be quite a mainline use of it as well.
> 
> Or is there something that would prevent this?
> 

I agree with having a rk3566.dtsi, and rk3568.dtsi on top, instead of the
other way around. We have some RK3566 boards here, so we can surely test
the RK3566.dtsi patches very quickly.

Also, it's fine if you want to send v2 with just these minimal peripherals.
However, I think you could include GMAC and TS-ADC:

https://lore.kernel.org/linux-rockchip/31c2e531-96d0-a1c1-644c-28c60eb40cf4 at gmail.com/T/#t
https://lore.kernel.org/linux-rockchip/20210421203409.40717-1-ezequiel at collabora.com/T/#t

These should work right out of the box!

Thanks!
Ezequiel



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:31:47 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:31:47 +0900
Subject: [PATCH net v2 0/2] Change phy-mode to RGMII-ID to enable delay pins
 for RTL8211E
Message-ID: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>

UniPhier PXs2, LD20, and PXs3 boards have RTL8211E ethernet phy, and the
phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY
and TXDLY pins.

After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), the delays are working correctly, however, "rgmii" means
no delay and the phy doesn't work. So need to set the phy-mode to
"rgmii-id" to show that RX/TX delays are enabled.

Changes since v1:
- Fix the commit message

Kunihiko Hayashi (2):
  ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins
    for RTL8211E
  arm64: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins
    for RTL8211E

 arch/arm/boot/dts/uniphier-pxs2.dtsi             | 2 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +-
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.7.4



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:31:48 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:31:48 +0900
Subject: [PATCH net v2 1/2] ARM: dts: uniphier: Change phy-mode to RGMII-ID to
 enable delay pins for RTL8211E
In-Reply-To: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1619112709-13234-2-git-send-email-hayashi.kunihiko@socionext.com>

UniPhier PXs2 boards have RTL8211E ethernet phy, and the phy have the RX/TX
delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins.

After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), the delays are working correctly, however, "rgmii" means
no delay and the phy doesn't work. So need to set the phy-mode to
"rgmii-id" to show that RX/TX delays are enabled.

Fixes: e3cc931921d2 ("ARM: dts: uniphier: add AVE ethernet node")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
---
 arch/arm/boot/dts/uniphier-pxs2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 4d9f69a..5ba831e 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -583,7 +583,7 @@
 			clocks = <&sys_clk 6>;
 			reset-names = "ether";
 			resets = <&sys_rst 6>;
-			phy-mode = "rgmii";
+			phy-mode = "rgmii-id";
 			local-mac-address = [00 00 00 00 00 00];
 			socionext,syscon-phy-mode = <&soc_glue 0>;
 
-- 
2.7.4



From hayashi.kunihiko at socionext.com  Thu Apr 22 18:31:49 2021
From: hayashi.kunihiko at socionext.com (Kunihiko Hayashi)
Date: Fri, 23 Apr 2021 02:31:49 +0900
Subject: [PATCH net v2 2/2] arm64: dts: uniphier: Change phy-mode to RGMII-ID
 to enable delay pins for RTL8211E
In-Reply-To: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <1619112709-13234-3-git-send-email-hayashi.kunihiko@socionext.com>

UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have
the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY
pins.

After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), the delays are working correctly, however, "rgmii" means
no delay and the phy doesn't work. So need to set the phy-mode to
"rgmii-id" to show that RX/TX delays are enabled.

Fixes: c73730ee4c9a ("arm64: dts: uniphier: add AVE ethernet node")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko at socionext.com>
---
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +-
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 52dee61..bd9959f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -806,7 +806,7 @@
 			clocks = <&sys_clk 6>;
 			reset-names = "ether";
 			resets = <&sys_rst 6>;
-			phy-mode = "rgmii";
+			phy-mode = "rgmii-id";
 			local-mac-address = [00 00 00 00 00 00];
 			socionext,syscon-phy-mode = <&soc_glue 0>;
 
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
index 80e2597..2038f51 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
@@ -564,7 +564,7 @@
 			clocks = <&sys_clk 6>;
 			reset-names = "ether";
 			resets = <&sys_rst 6>;
-			phy-mode = "rgmii";
+			phy-mode = "rgmii-id";
 			local-mac-address = [00 00 00 00 00 00];
 			socionext,syscon-phy-mode = <&soc_glue 0>;
 
@@ -585,7 +585,7 @@
 			clocks = <&sys_clk 7>;
 			reset-names = "ether";
 			resets = <&sys_rst 7>;
-			phy-mode = "rgmii";
+			phy-mode = "rgmii-id";
 			local-mac-address = [00 00 00 00 00 00];
 			socionext,syscon-phy-mode = <&soc_glue 1>;
 
-- 
2.7.4



From sudeep.holla at arm.com  Thu Apr 22 18:46:31 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 22 Apr 2021 18:46:31 +0100
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
In-Reply-To: <YIE7pdqV/h10tEAK@mwanda>
References: <YIE7pdqV/h10tEAK@mwanda>
Message-ID: <20210422174631.aruiqqqx3szboqdp@bogus>

(dropping Tixy as I am sure it will bounce, he left/retired from Linaro
long back)

On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote:
> How type promotion works in ternary expressions is a bit tricky.
> The problem is that scpi_clk_get_val() returns longs, "ret" is a int
> which holds a negative error code, and le32_to_cpu() is an unsigned int.

Agreed.

> We want the negative error code to be cast to a negative long.  But
> because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
> becomes a high positive and then it is promoted to long and it is still
> a high positive value.
>

Thanks a lot for finding and fixing the bug!

> Fix this by getting rid of the ternary.
>
> Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
> Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
> ---
>  drivers/firmware/arm_scpi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index d0dee37ad522..3bf61854121d 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
>
>  	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
>  				sizeof(le_clk_id), &rate, sizeof(rate));
> +	if (ret)
> +		return ret;

This could be still an issue, ideally I would prefer to pass the return
value via argument pointer and always return success/failure as return
value. Can't remember any reason for this. Since this is old interface
with limited platform to test, I think returning 0 as clock rate on error
should be fine as Cristain suggested. If you agree with that, I can
fix up when applying. 

If you don't, we can look at changing the scpi interface to clock driver
which will anyway need to do the same(i.e. send 0 in case of error)

Let me know.

--
Regards,
Sudeep


From ebiederm at xmission.com  Thu Apr 22 19:22:04 2021
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 22 Apr 2021 13:22:04 -0500
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <20210422124849.GA1521@willie-the-truck> (Will Deacon's message
 of "Thu, 22 Apr 2021 13:48:50 +0100")
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck>
Message-ID: <m1v98egoxf.fsf@fess.ebiederm.org>

Will Deacon <will at kernel.org> writes:

> [+Eric as he actually understands how this is supposed to work]

I try.

> On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
>> arm64_notify_segfault() was used to force a SIGSEGV in all error cases
>> in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
>> There is now a better sig handler to use which does not search the VMA
>> address space and return a slightly incorrect error code.  Restore the
>> older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
>> the case of !access_ok(), simply return SIGSEGV with si_code
>> SEGV_ACCERR.

What is userspace cares?  Why does it care?

This is changing userspace visible semantics so understanding userspace
and understanding how it might break, and what the risk of regression
seems the most important detail here.

>> This change requires exporting arm64_notfiy_die() to the arm64 traps.h
>> 
>> Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
>> failing to deliver signal)
>> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
>> ---
>>  arch/arm64/include/asm/traps.h |  2 ++
>>  arch/arm64/kernel/signal.c     |  8 ++++++--
>>  arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
>>  3 files changed, 22 insertions(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
>> index 54f32a0675df..9b76144fcba6 100644
>> --- a/arch/arm64/include/asm/traps.h
>> +++ b/arch/arm64/include/asm/traps.h
>> @@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
>>  void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
>>  void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
>>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
>> +void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
>> +		      int sicode, unsigned long far, int err);
>>  
>>  /*
>>   * Move regs->pc to next instruction and do necessary setup before it
>> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
>> index 6237486ff6bb..9fde6dc760c3 100644
>> --- a/arch/arm64/kernel/signal.c
>> +++ b/arch/arm64/kernel/signal.c
>> @@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
>>  	frame = (struct rt_sigframe __user *)regs->sp;
>>  
>>  	if (!access_ok(frame, sizeof (*frame)))
>> -		goto badframe;
>> +		goto e_access;
>>  
>>  	if (restore_sigframe(regs, frame))
>>  		goto badframe;
>> @@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
>>  	return regs->regs[0];
>>  
>>  badframe:
>> -	arm64_notify_segfault(regs->sp);
>> +	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
>> +	return 0;
>> +
>> +e_access:
>> +	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
>>  	return 0;
>
> This seems really error-prone to me, but maybe I'm just missing some
> context. What's the rule for reporting an si_code of SI_KERNEL vs
> SEGV_ACCERR, and is the former actually valid for SIGSEGV?

The si_codes SI_USER == 0 and SI_KERNEL == 0x80 are valid for all
signals.  SI_KERNEL means I don't have any information for you other
than signal number.

In general something better than SI_KERNEL is desirable.

> With this change, pointing the (signal) stack to a kernel address will
> result in SEGV_ACCERR but pointing it to something like a PROT_NONE user
> address will give SI_KERNEL (well, assuming that we manage to deliver
> the SEGV somehow). I'm having a hard time seeing why that's a useful
> distinction to make..
>
> If it's important to get this a particular way around, please can you
> add some selftests?

Going down the current path I see 3 possible cases:

copy_from_user returns -EFAULT which becomes SEGV_MAPERR or SEGV_ACCERR.

A signal frame parse error.  For which SI_KERNEL seems as good an error
code as any.


On x86 there is no attempt to figure out the cause of the -EFAULT, and
always uses SI_KERNEL.  This is because x86 just does:
"force_sig(SIGSEGV);" As arm64 did until f71016a8a8c5 ("arm64: signal:
Call arm64_notify_segfault when failing to deliver signal")



I think the big question is what does it make sense to do here.

The big picture.  Upon return from a signal the kernel arranges
for rt_sigreturn to be called to return to a pre-signal state.
As such rt_sigreturn can not return an error code.

In general the kernel will write the signal frame and that will
guarantee that the signal from can be processes by rt_sigreturn.

For error handling we are dealing with the case that userspace
has modified the signal frame.  So that it either does not
parse or that it is unmapped.


So who cares?  The only two cases I can think of are debuggers, and
programs playing fancy memory management games like garbage collections.
I have heard of applications (like garbage collectors)
unmapping/mprotecting memory to create a barrier.

Liam Howlett is that the issue here?  Is not seeing SI_KERNEL confusing
the JVM?

For debuggers I expect the stack backtrace from SIGSEGV is enough to see
that something is wrong.

For applications performing fancy processing of the signal frame I think
that tends to be very architecture specific.  In part because even
knowing the faulting address the size of the access is not known so the
instruction must be interpreted.  Getting a system call instead of a
load or store instruction might be enough to completely confuse
applications processing SEGV_MAPERR or SEGV_ACCERR.  Such applications
may also struggle with the fact that the address in siginfo is less
precise than it would be for an ordinary page fault.


So my sense is if you known you are helping userspace returning either
SEGV_MAPERR or SEGV_ACCERR go for it.  Otherwise there are enough
variables that returning less information when rt_sigreturn fails
would be more reliable.


Or in short what is userspace doing?  What does userspace care about?

Eric


From ldv at altlinux.org  Thu Apr 22 19:57:43 2021
From: ldv at altlinux.org (Dmitry V. Levin)
Date: Thu, 22 Apr 2021 21:57:43 +0300
Subject: [PATCH 1/3] arm64: ptrace: Add is_syscall_success to handle compat
In-Reply-To: <20210422164228.GD66392@C02TD0UTHF1T.local>
References: <20210416075533.7720-1-zhe.he@windriver.com>
 <20210416123322.GA23184@arm.com>
 <20210416133431.GA2303@C02TD0UTHF1T.local>
 <20210419121932.GA30004@willie-the-truck>
 <20210421171005.GA46949@C02TD0UTHF1T.local>
 <20210422160752.GA2214@willie-the-truck>
 <20210422164228.GD66392@C02TD0UTHF1T.local>
Message-ID: <20210422185743.GC12226@altlinux.org>

On Thu, Apr 22, 2021 at 05:42:28PM +0100, Mark Rutland wrote:
> On Thu, Apr 22, 2021 at 05:07:53PM +0100, Will Deacon wrote:
> > On Wed, Apr 21, 2021 at 06:10:05PM +0100, Mark Rutland wrote:
> > > On Mon, Apr 19, 2021 at 01:19:33PM +0100, Will Deacon wrote:
> > > > On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
> > > > > I think this is a problem we created for ourselves back in commit:
> > > > > 
> > > > >   15956689a0e60aa0 ("arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return)
> > > > > 
> > > > > AFAICT, the perf regs samples are the only place this matters, since for
> > > > > ptrace the compat regs are implicitly truncated to compat_ulong_t, and
> > > > > audit expects the non-truncated return value. Other architectures don't
> > > > > truncate here, so I think we're setting ourselves up for a game of
> > > > > whack-a-mole to truncate and extend wherever we need to.
> > > > > 
> > > > > Given that, I suspect it'd be better to do something like the below.
> > > > > 
> > > > > Will, thoughts?
> > > > 
> > > > I think perf is one example, but this is also visible to userspace via the
> > > > native ptrace interface and I distinctly remember needing this for some
> > > > versions of arm64 strace to work correctly when tracing compat tasks.
> > > 
> > > FWIW, you've convinced me on your approach (more on that below), but
> > > when I went digging here this didn't seem to be exposed via ptrace --
> > > for any task tracing a compat task, the GPRs are exposed via
> > > compat_gpr_{get,set}(), which always truncate to compat_ulong_t, giving
> > > the lower 32 bits. See task_user_regset_view() for where we get the
> > > regset.
> > > 
> > > Am I missing something, or are you thinking of another issue you fixed
> > > at the same time?
> > 
> > I think it may depend on whether strace pokes at the GPRs or instead issues
> > a PTRACE_GET_SYSCALL_INFO request but I've forgotten the details,
> > unfortunately. I do remember seeing an issue though, and it was only last
> > year.
> 
> Ah; I hadn't spotted PTRACE_GET_SYSCALL_INFO, thanks for the pointer. I
> see that gets at the regs via syscall_get_arguments(), which doesn't
> truncate them.
> 
> That makes me wonder whether x86 and others do the right thing here...

Yes, some architectures had to be fixed, but they mostly do the right
thing nowadays.

Feel free to use tools/testing/selftests/ptrace/get_syscall_info.c for
testing, or indeed use strace test suite.


-- 
ldv


From elver at google.com  Thu Apr 22 20:18:22 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 21:18:22 +0200
Subject: [PATCH tip v2 1/2] signal, perf: Fix siginfo_t by avoiding u64 on
 32-bit architectures
Message-ID: <20210422191823.79012-1-elver@google.com>

The alignment of a structure is that of its largest member. On
architectures like 32-bit Arm (but not e.g. 32-bit x86) 64-bit integers
will require 64-bit alignment and not its natural word size.

This means that there is no portable way to add 64-bit integers to
siginfo_t on 32-bit architectures without breaking the ABI, because
siginfo_t does not yet (and therefore likely never will) contain 64-bit
fields on 32-bit architectures. Adding a 64-bit integer could change the
alignment of the union after the 3 initial int si_signo, si_errno,
si_code, thus introducing 4 bytes of padding shifting the entire union,
which would break the ABI.

One alternative would be to use the __packed attribute, however, it is
non-standard C. Given siginfo_t has definitions outside the Linux kernel
in various standard libraries that can be compiled with any number of
different compilers (not just those we rely on), using non-standard
attributes on siginfo_t should be avoided to ensure portability.

In the case of the si_perf field, word size is sufficient since there is
no exact requirement on size, given the data it contains is user-defined
via perf_event_attr::sig_data. On 32-bit architectures, any excess bits
of perf_event_attr::sig_data will therefore be truncated when copying
into si_perf.

Since si_perf is intended to disambiguate events (e.g. encoding relevant
information if there are more events of the same type), 32 bits should
provide enough entropy to do so on 32-bit architectures.

For 64-bit architectures, no change is intended.

Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
Reported-by: Marek Szyprowski <m.szyprowski at samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
Reported-by: Jon Hunter <jonathanh at nvidia.com>
Tested-by: Jon Hunter <jonathanh at nvidia.com>
Signed-off-by: Marco Elver <elver at google.com>
---
v2:
* Update commit message wording to be clearer and mentioned __packed, as
  pointed out by David Laight. I'm sure some time in the future somebody
  will wonder and perhaps run into the same issue, so let's try to give
  as much background as we can...

v1: https://lkml.kernel.org/r/20210422064437.3577327-1-elver at google.com

Note: I added static_assert()s to verify the siginfo_t layout to
arch/arm and arch/arm64, which caught the problem. I'll send them
separately to arm&arm64 maintainers respectively.
---
 include/linux/compat.h                                | 2 +-
 include/uapi/asm-generic/siginfo.h                    | 2 +-
 tools/testing/selftests/perf_events/sigtrap_threads.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/compat.h b/include/linux/compat.h
index c8821d966812..f0d2dd35d408 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -237,7 +237,7 @@ typedef struct compat_siginfo {
 					u32 _pkey;
 				} _addr_pkey;
 				/* used when si_code=TRAP_PERF */
-				compat_u64 _perf;
+				compat_ulong_t _perf;
 			};
 		} _sigfault;
 
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index d0bb9125c853..03d6f6d2c1fe 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -92,7 +92,7 @@ union __sifields {
 				__u32 _pkey;
 			} _addr_pkey;
 			/* used when si_code=TRAP_PERF */
-			__u64 _perf;
+			unsigned long _perf;
 		};
 	} _sigfault;
 
diff --git a/tools/testing/selftests/perf_events/sigtrap_threads.c b/tools/testing/selftests/perf_events/sigtrap_threads.c
index 9c0fd442da60..78ddf5e11625 100644
--- a/tools/testing/selftests/perf_events/sigtrap_threads.c
+++ b/tools/testing/selftests/perf_events/sigtrap_threads.c
@@ -44,7 +44,7 @@ static struct {
 } ctx;
 
 /* Unique value to check si_perf is correctly set from perf_event_attr::sig_data. */
-#define TEST_SIG_DATA(addr) (~(uint64_t)(addr))
+#define TEST_SIG_DATA(addr) (~(unsigned long)(addr))
 
 static struct perf_event_attr make_event_attr(bool enabled, volatile void *addr)
 {
-- 
2.31.1.498.g6c1eba8ee3d-goog



From elver at google.com  Thu Apr 22 20:18:23 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 21:18:23 +0200
Subject: [PATCH tip v2 2/2] signal,
 perf: Add missing TRAP_PERF case in siginfo_layout()
In-Reply-To: <20210422191823.79012-1-elver@google.com>
References: <20210422191823.79012-1-elver@google.com>
Message-ID: <20210422191823.79012-2-elver@google.com>

Add the missing TRAP_PERF case in siginfo_layout() for interpreting the
layout correctly as SIL_PERF_EVENT instead of just SIL_FAULT. This
ensures the si_perf field is copied and not just the si_addr field.

This was caught and tested by running the perf_events/sigtrap_threads
kselftest as a 32-bit binary with a 64-bit kernel.

Fixes: fb6cc127e0b6 ("signal: Introduce TRAP_PERF si_code and si_perf to siginfo")
Signed-off-by: Marco Elver <elver at google.com>
---
 kernel/signal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/signal.c b/kernel/signal.c
index 9ed81ee4ff17..b354655a0e57 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3251,6 +3251,8 @@ enum siginfo_layout siginfo_layout(unsigned sig, int si_code)
 			else if ((sig == SIGSEGV) && (si_code == SEGV_PKUERR))
 				layout = SIL_FAULT_PKUERR;
 #endif
+			else if ((sig == SIGTRAP) && (si_code == TRAP_PERF))
+				layout = SIL_PERF_EVENT;
 		}
 		else if (si_code <= NSIGPOLL)
 			layout = SIL_POLL;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From elver at google.com  Thu Apr 22 20:22:31 2021
From: elver at google.com (Marco Elver)
Date: Thu, 22 Apr 2021 21:22:31 +0200
Subject: [PATCH tip 1/2] signal, perf: Fix siginfo_t by avoiding u64 on
 32-bit architectures
In-Reply-To: <CANpmjNNjkQdziFZDkPy5EnwCF+VyBWKXEwCDgNpxHGZd+BLQag@mail.gmail.com>
References: <20210422064437.3577327-1-elver@google.com>
 <d480a4f56d544fb98eb1cdd62f44ae91@AcuMS.aculab.com>
 <CANpmjNNjkQdziFZDkPy5EnwCF+VyBWKXEwCDgNpxHGZd+BLQag@mail.gmail.com>
Message-ID: <CANpmjNNHRmaxawVKNe8Oe=pnEgoJG6iqevHNJRa4EoeFtS5fYQ@mail.gmail.com>

On Thu, 22 Apr 2021 at 12:17, Marco Elver <elver at google.com> wrote:
> On Thu, 22 Apr 2021 at 11:48, David Laight <David.Laight at aculab.com> wrote:
> >
> > From: Marco Elver
> > > Sent: 22 April 2021 07:45
> > >
> > > On some architectures, like Arm, the alignment of a structure is that of
> > > its largest member.
> >
> > That is true everywhere.
> > (Apart from obscure ABI where structure have at least 4 byte alignment!)
>
> For instance, x86 didn't complain, nor did m68k. Both of them have
> compile-time checks for the layout (I'm adding those for Arm
> elsewhere).
[...]
> > Much as I hate __packed, you could add __packed to the
> > definition of the structure member _perf.
> > The compiler will remove the padding before it and will
> > assume it has the alignment of the previous item.
> >
> > So it will never use byte accesses.
>
> Sure __packed works for Arm. But I think there's no precedent using
> this on siginfo_t, possibly for good reasons? I simply can't find
> evidence that this is portable on *all* architectures and for *all*
> possible definitions of siginfo_t, including those that live in things
> like glibc.
>
> Can we confirm that __packed is fine to add to siginfo_t on *all*
> architectures for *all* possible definitions of siginfo_t? I currently
> can't. And given it's outside the scope of the C standard (as of C11
> we got _Alignas, but that doesn't help I think), I'd vote to not
> venture too far for code that should be portable especially things as
> important as siginfo_t, and has definitions *outside* the kernel (I
> know we do lots of non-standard things, but others might not).

After thinking about this all afternoon, you convinced me that the
commit message wasn't great, and this should be in the commit message,
too: https://lkml.kernel.org/r/20210422191823.79012-1-elver at google.com

Thanks,
-- Marco


From liam.howlett at oracle.com  Thu Apr 22 20:24:00 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Thu, 22 Apr 2021 19:24:00 +0000
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <m1v98egoxf.fsf@fess.ebiederm.org>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck> <m1v98egoxf.fsf@fess.ebiederm.org>
Message-ID: <20210422192349.ekpinkf3wxnmywe3@revolver>

* Eric W. Biederman <ebiederm at xmission.com> [210422 14:23]:
> Will Deacon <will at kernel.org> writes:
> 
> > [+Eric as he actually understands how this is supposed to work]
> 
> I try.
> 

Thanks to both of you for looking at this.

> > On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
> >> arm64_notify_segfault() was used to force a SIGSEGV in all error cases
> >> in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
> >> There is now a better sig handler to use which does not search the VMA
> >> address space and return a slightly incorrect error code.  Restore the
> >> older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
> >> the case of !access_ok(), simply return SIGSEGV with si_code
> >> SEGV_ACCERR.
> 
> What is userspace cares?  Why does it care?


Calling arm64_notify_segfault() as it is written is unreliable.
Searching for the address with find_vma() will return SEG_ACCERR almost
always, unless the address is larger than anything within *any* VMA.
I'm trying to fix this issue by cleaning up the callers to that function
and fix the function itself.

I don't have an example of why userspace cares about SI_KERNEL vs
SEGV_ACCERR/SEGV_MAPERR, but the git log on f71016a8a8c5 specifies that
this function was used to avoid having specific code to print an error
code.  I am restoring the old return code as it seems to makes more
sense and avoids the bug in the calling path.  If you'd rather, I can
change the notify_die line to use SIG_ACCERR as this is *almost* always
what is returend - except when the above mentioned bug is hit.  Upon
examining the code here, it seems unnecessary to walk the VMA tree to
find where the address lands in either of the error scenarios to know
what should be returned.

> 
> This is changing userspace visible semantics so understanding userspace
> and understanding how it might break, and what the risk of regression
> seems the most important detail here.
> 
> >> This change requires exporting arm64_notfiy_die() to the arm64 traps.h
> >> 
> >> Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
> >> failing to deliver signal)
> >> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> >> ---
> >>  arch/arm64/include/asm/traps.h |  2 ++
> >>  arch/arm64/kernel/signal.c     |  8 ++++++--
> >>  arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
> >>  3 files changed, 22 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> >> index 54f32a0675df..9b76144fcba6 100644
> >> --- a/arch/arm64/include/asm/traps.h
> >> +++ b/arch/arm64/include/asm/traps.h
> >> @@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
> >>  void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
> >>  void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
> >>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
> >> +void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
> >> +		      int sicode, unsigned long far, int err);
> >>  
> >>  /*
> >>   * Move regs->pc to next instruction and do necessary setup before it
> >> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> >> index 6237486ff6bb..9fde6dc760c3 100644
> >> --- a/arch/arm64/kernel/signal.c
> >> +++ b/arch/arm64/kernel/signal.c
> >> @@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> >>  	frame = (struct rt_sigframe __user *)regs->sp;
> >>  
> >>  	if (!access_ok(frame, sizeof (*frame)))
> >> -		goto badframe;
> >> +		goto e_access;
> >>  
> >>  	if (restore_sigframe(regs, frame))
> >>  		goto badframe;
> >> @@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
> >>  	return regs->regs[0];
> >>  
> >>  badframe:
> >> -	arm64_notify_segfault(regs->sp);
> >> +	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
> >> +	return 0;
> >> +
> >> +e_access:
> >> +	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
> >>  	return 0;
> >
> > This seems really error-prone to me, but maybe I'm just missing some
> > context. What's the rule for reporting an si_code of SI_KERNEL vs
> > SEGV_ACCERR, and is the former actually valid for SIGSEGV?
> 
> The si_codes SI_USER == 0 and SI_KERNEL == 0x80 are valid for all
> signals.  SI_KERNEL means I don't have any information for you other
> than signal number.
> 
> In general something better than SI_KERNEL is desirable.

I went with SI_KERNEL as that's what was there before.  I have no strong
opinion on what should be returned; I do favour SIGBUS with si_code of
BUS_ADRALN but I didn't want to change user visable code too much -
especially to fix a bug in another function.

> 
> > With this change, pointing the (signal) stack to a kernel address will
> > result in SEGV_ACCERR but pointing it to something like a PROT_NONE user
> > address will give SI_KERNEL (well, assuming that we manage to deliver
> > the SEGV somehow). I'm having a hard time seeing why that's a useful
> > distinction to make..
> >
> > If it's important to get this a particular way around, please can you
> > add some selftests?
> 
> Going down the current path I see 3 possible cases:
> 
> copy_from_user returns -EFAULT which becomes SEGV_MAPERR or SEGV_ACCERR.

Almost always SEGV_ACCERR with the current bug, as mentioned above.
find_vma() searches from addr until the end of the address space, it
isn't just a simple lookup of the address.

> 
> A signal frame parse error.  For which SI_KERNEL seems as good an error
> code as any.
> 
> 
> On x86 there is no attempt to figure out the cause of the -EFAULT, and
> always uses SI_KERNEL.  This is because x86 just does:
> "force_sig(SIGSEGV);" As arm64 did until f71016a8a8c5 ("arm64: signal:
> Call arm64_notify_segfault when failing to deliver signal")
> 
> 
> 
> I think the big question is what does it make sense to do here.
> 
> The big picture.  Upon return from a signal the kernel arranges
> for rt_sigreturn to be called to return to a pre-signal state.
> As such rt_sigreturn can not return an error code.
> 
> In general the kernel will write the signal frame and that will
> guarantee that the signal from can be processes by rt_sigreturn.
> 
> For error handling we are dealing with the case that userspace
> has modified the signal frame.  So that it either does not
> parse or that it is unmapped.
> 
> 
> So who cares?  The only two cases I can think of are debuggers, and
> programs playing fancy memory management games like garbage collections.
> I have heard of applications (like garbage collectors)
> unmapping/mprotecting memory to create a barrier.
> 
> Liam Howlett is that the issue here?  Is not seeing SI_KERNEL confusing
> the JVM?

No, the issue here is that arm64_notify_segfault() has a bug which sent
me down a rabbit hole of issues and I'm really trying my best to help
out as best I can.  The bug certainly affects this function as it is
written today, but my patch will generate a consistent signal.

> 
> For debuggers I expect the stack backtrace from SIGSEGV is enough to see
> that something is wrong.
> 
> For applications performing fancy processing of the signal frame I think
> that tends to be very architecture specific.  In part because even
> knowing the faulting address the size of the access is not known so the
> instruction must be interpreted.  Getting a system call instead of a
> load or store instruction might be enough to completely confuse
> applications processing SEGV_MAPERR or SEGV_ACCERR.  Such applications
> may also struggle with the fact that the address in siginfo is less
> precise than it would be for an ordinary page fault.
> 
> 
> So my sense is if you known you are helping userspace returning either
> SEGV_MAPERR or SEGV_ACCERR go for it.  Otherwise there are enough
> variables that returning less information when rt_sigreturn fails
> would be more reliable.
> 
> 
> Or in short what is userspace doing?  What does userspace care about?

I think I've answered this, but it's more of trying to fix a bug which
causes an *almost* reliable return code to be a reliable return code.
Am I correct in stating that in both of these scnarios - !access_ok()
and badframe, it is unnecessary to search the VMAs for where the address
falls to know what error code to return?

Thanks,
Liam

From liam.howlett at oracle.com  Thu Apr 22 19:56:17 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Thu, 22 Apr 2021 18:56:17 +0000
Subject: [PATCH 3/3] arch/arm64/kernel/traps: Use find_vma_intersection()
 in traps for setting si_code
In-Reply-To: <20210422125334.GB1521@willie-the-truck>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-3-Liam.Howlett@Oracle.com>
 <20210422125334.GB1521@willie-the-truck>
Message-ID: <20210422185611.ccdf3rm4zr3xtuzl@revolver>

* Will Deacon <will at kernel.org> [210422 08:53]:
> On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
> > find_vma() will continue to search upwards until the end of the virtual
> > memory space.  This means the si_code would almost never be set to
> > SEGV_MAPERR even when the address falls outside of any VMA.  The result
> > is that the si_code is not reliable as it may or may not be set to the
> > correct result, depending on where the address falls in the address
> > space.
> > 
> > Using find_vma_intersection() allows for what is intended by only
> > returning a VMA if it falls within the range provided, in this case a
> > window of 1.
> > 
> > Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > ---
> >  arch/arm64/kernel/traps.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index a05d34f0e82a..a44007904a64 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -383,9 +383,10 @@ void force_signal_inject(int signal, int code, unsigned long address, unsigned i
> >  void arm64_notify_segfault(unsigned long addr)
> >  {
> >  	int code;
> > +	unsigned long ut_addr = untagged_addr(addr);
> >  
> >  	mmap_read_lock(current->mm);
> > -	if (find_vma(current->mm, untagged_addr(addr)) == NULL)
> > +	if (find_vma_intersection(current->mm, ut_addr, ut_addr + 1) == NULL)
> >  		code = SEGV_MAPERR;
> >  	else
> >  		code = SEGV_ACCERR;
> 
> I'm not seeing how this addresses VM_GROWSDOWN as Catalin mentioned before.

Sorry for not including the link before, but for context, I've added the
URL for the lore conversation from before at the end of my message [1].

I thought this was resolved by the fact that the stack expansion would
have already taken care of the VM_GROWSDOWN code path?  Did I
misunderstand what was said?

I've modified the other paths to this function to avoid causing issues
elsewhere and to hopefully do the necessary cleanup that Catalin said
needed to be tidied.

Link:  https://lore.kernel.org/lkml/20210413180030.GA31164 at arm.com/

Thanks,
Liam

From joe.burmeister at devtank.co.uk  Thu Apr 22 21:10:21 2021
From: joe.burmeister at devtank.co.uk (Joe Burmeister)
Date: Thu, 22 Apr 2021 21:10:21 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
Message-ID: <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>

> On 4/20/2021 1:34 AM, Joe Burmeister wrote:
>> It was previoulsy possible to have a device tree with more chips than
>> the driver supports and go off the end of CS arrays.
> Do you mind walking me through the code how that could have happened? We
> have spi_register_controller() call of_spi_get_gpio_numbers() which has
> the following:
>
> ctlr->num_chipselect = max_t(int, nb, ctlr->num_chipselect);
>
> such that what the controller has is the maximum between the number of
> 'cs-gpios' properties parsed and what was already populated in
> ctrl->num_chipselect during bcm2835_spi_probe(), which for this driver
> is BCM2835_SPI_NUM_CS (3).

If you make a initial device tree (or add overlay in the rpi's 
config.txt) with more on the bus than BCM2835_SPI_NUM_CS (in my case 8
devices), you get into this trampling memory state. As the devices are
added, once the chip_select is equal to or greater than
BCM2835_SPI_NUM_CS, it's writing off the end of the arrays.

There is no protection from this happening. By the looks of it, this
isn't the only driver this could happen with, but it is the one I have
hardware for to test. There are also drivers that look like they don't
have a problem going well beyond the limit they gave.

There is protection in spi_add_device, which will catch extra added
later, but not ones in the device tree when the spi controller was
registered.

>> This patches inforces CS limit but sets that limit to the max of the
>> default limit and what is in the device tree when driver is loaded.
>>
>> Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>
> You have changed many more things that just enforcing a limit on
> BCM2835_SPI_NUM_CS you have now made all chip-select related data
> structuresd dynamically allocated and you have changed a number of
> prints to use the shorthand "dev" instead of &pdev->dev.
The change to dynamic allocated arrays is just to support what is given
in the device? tree rather than increase and enforce the CS limit just
for my case.

The shorthand is of course not required. I'll drop it on resubmitting.

Regards,

Joe




From skomatineni at nvidia.com  Thu Apr 22 21:30:45 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 13:30:45 -0700
Subject: [RFC PATCH 1/4] firmware/psci: add support for PSCI function
 SET_STATE_IDLE_TIME
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <1619123448-10138-2-git-send-email-skomatineni@nvidia.com>

This patch adds support for new PSCI function ID SET_STATE_IDLE_TIME.

Some platforms use separate CPU firmware to handle all state transition
based on state enter request from kernel and may need runtime state
idle time of the corresponding state from kernel to pass to TF-A through
PSCI.

Current PSCI specification has no way of passing runtime state information
from kernel to TF-A.

So, this patch adds implementation for new PSCI function ID for this
purpose.

Signed-off-by: Sowjanya Komatineni <skomatineni at nvidia.com>
---
 drivers/firmware/psci/psci.c | 9 +++++++++
 include/linux/psci.h         | 1 +
 include/uapi/linux/psci.h    | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f5bd0dc..3bd63d7 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -180,6 +180,14 @@ static int psci_0_1_cpu_suspend(u32 state, unsigned long entry_point)
 				  state, entry_point);
 }
 
+static int psci_set_state_idle_time(u32 idle_time)
+{
+	int err;
+
+	err = invoke_psci_fn(PSCI_1_1_FN_SET_STATE_IDLE_TIME, idle_time, 0, 0);
+	return psci_to_linux_errno(err);
+}
+
 static int psci_0_2_cpu_suspend(u32 state, unsigned long entry_point)
 {
 	return __psci_cpu_suspend(PSCI_FN_NATIVE(0_2, CPU_SUSPEND),
@@ -470,6 +478,7 @@ static void __init psci_0_2_set_functions(void)
 		.migrate = psci_0_2_migrate,
 		.affinity_info = psci_affinity_info,
 		.migrate_info_type = psci_migrate_info_type,
+		.set_state_idle_time = psci_set_state_idle_time,
 	};
 
 	arm_pm_restart = psci_sys_reset;
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 4ca0060..6643bfd 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -30,6 +30,7 @@ struct psci_operations {
 	int (*affinity_info)(unsigned long target_affinity,
 			unsigned long lowest_affinity_level);
 	int (*migrate_info_type)(void);
+	int (*set_state_idle_time)(u32 idle_time);
 };
 
 extern struct psci_operations psci_ops;
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index 2fcad1d..0013db74 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -55,6 +55,8 @@
 #define PSCI_1_0_FN64_SYSTEM_SUSPEND		PSCI_0_2_FN64(14)
 #define PSCI_1_1_FN64_SYSTEM_RESET2		PSCI_0_2_FN64(18)
 
+#define PSCI_1_1_FN_SET_STATE_IDLE_TIME		PSCI_0_2_FN(25)
+
 /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
 #define PSCI_0_2_POWER_STATE_ID_MASK		0xffff
 #define PSCI_0_2_POWER_STATE_ID_SHIFT		0
-- 
2.7.4



From skomatineni at nvidia.com  Thu Apr 22 21:30:46 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 13:30:46 -0700
Subject: [RFC PATCH 2/4] cpuidle: menu: add idle_time to cpuidle_state
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <1619123448-10138-3-git-send-email-skomatineni@nvidia.com>

Some platforms use separate CPU firmware running in background to
handle state transitions which may need runtime idle time of the
corresponding target state from the kernel.

This patch adds idle_time to cpuidle state to expose to cpuidle driver the
idle time that the governor menu predicts based on next events and states
target residency for selecting proper idle state.

CPU idle driver passes this runtime state idle time to TF-A.

Signed-off-by: Sowjanya Komatineni <skomatineni at nvidia.com>
---
 drivers/cpuidle/governors/menu.c | 7 ++++++-
 include/linux/cpuidle.h          | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index c3aa8d6..0da5bc5 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -382,8 +382,10 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
 			 * stuck in the shallow one for too long.
 			 */
 			if (drv->states[idx].target_residency_ns < TICK_NSEC &&
-			    s->target_residency_ns <= delta_tick)
+			    s->target_residency_ns <= delta_tick) {
+				drv->states[idx].idle_time = delta_tick / NSEC_PER_USEC;
 				idx = i;
+			}
 
 			return idx;
 		}
@@ -393,6 +395,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
 		idx = i;
 	}
 
+	drv->states[idx].idle_time = predicted_ns / NSEC_PER_USEC;
 	if (idx == -1)
 		idx = 0; /* No states enabled. Must use 0. */
 
@@ -419,6 +422,8 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
 				if (drv->states[i].target_residency_ns <= delta_tick)
 					break;
 			}
+
+			drv->states[idx].idle_time = delta_tick / NSEC_PER_USEC;
 		}
 	}
 
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index fce4762..12db2e9 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -55,6 +55,7 @@ struct cpuidle_state {
 	unsigned int	exit_latency; /* in US */
 	int		power_usage; /* in mW */
 	unsigned int	target_residency; /* in US */
+	unsigned int	idle_time; /* in US */
 
 	int (*enter)	(struct cpuidle_device *dev,
 			struct cpuidle_driver *drv,
-- 
2.7.4



From skomatineni at nvidia.com  Thu Apr 22 21:30:47 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 13:30:47 -0700
Subject: [RFC PATCH 3/4] cpuidle: psci: pass state idle time before state
 enter callback
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <1619123448-10138-4-git-send-email-skomatineni@nvidia.com>

Some platforms use separate CPU firmware to handle all state transition
decisions and may need runtime state idle time of the target state it is
going to enter.

This patch calls set_state_idle_time psci operation callback to pass the
state idle time to TF-A through PSCI before calling psci_enter_state.

Signed-off-by: Sowjanya Komatineni <skomatineni at nvidia.com>
---
 drivers/cpuidle/cpuidle-psci.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
index b51b5df..22a5003 100644
--- a/drivers/cpuidle/cpuidle-psci.c
+++ b/drivers/cpuidle/cpuidle-psci.c
@@ -151,6 +151,17 @@ static int psci_enter_idle_state(struct cpuidle_device *dev,
 {
 	u32 *state = __this_cpu_read(psci_cpuidle_data.psci_states);
 
+	/*
+	 * Some platforms use separate CPU firmware running in background to
+	 * handle state transition which may need runtime idle time of the
+	 * corresponding state from kernel.
+	 * So, pass the state idle time from kernel to TF-A firmware through
+	 * PSCI. Platform specific TF-A firmware may update this to CPU
+	 * firmware.
+	 */
+	if (idx)
+		psci_ops.set_state_idle_time(drv->states[idx].idle_time);
+
 	return psci_enter_state(idx, state[idx]);
 }
 
-- 
2.7.4



From skomatineni at nvidia.com  Thu Apr 22 21:30:48 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 13:30:48 -0700
Subject: [RFC PATCH 4/4] arm64: dts: tegra194: Add CPU idle states
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <1619123448-10138-5-git-send-email-skomatineni@nvidia.com>

This patch adds CPU core and cluster idle states to Tegra194
device tree

Signed-off-by: Sowjanya Komatineni <skomatineni at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 9449156..c3b478e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -2161,6 +2161,7 @@
 			device_type = "cpu";
 			reg = <0x000>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2175,6 +2176,7 @@
 			device_type = "cpu";
 			reg = <0x001>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2189,6 +2191,7 @@
 			device_type = "cpu";
 			reg = <0x100>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2203,6 +2206,7 @@
 			device_type = "cpu";
 			reg = <0x101>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2217,6 +2221,7 @@
 			device_type = "cpu";
 			reg = <0x200>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2231,6 +2236,7 @@
 			device_type = "cpu";
 			reg = <0x201>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2245,6 +2251,7 @@
 			device_type = "cpu";
 			reg = <0x300>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2259,6 +2266,7 @@
 			device_type = "cpu";
 			reg = <0x301>;
 			enable-method = "psci";
+			cpu-idle-states = <&C6>;
 			i-cache-size = <131072>;
 			i-cache-line-size = <64>;
 			i-cache-sets = <512>;
@@ -2343,6 +2351,17 @@
 			cache-line-size = <64>;
 			cache-sets = <4096>;
 		};
+
+		idle-states {
+			entry-method = "arm,psci";
+			C6: c6 {
+				compatible = "arm,idle-state";
+				wakeup-latency-us = <2000>;
+				min-residency-us = <30000>;
+				arm,psci-suspend-param = <0x6>;
+				status = "okay";
+			};
+		};
 	};
 
 	psci {
-- 
2.7.4



From skomatineni at nvidia.com  Thu Apr 22 21:30:44 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 13:30:44 -0700
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to TF-A
Message-ID: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>

Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
in charge of deciding on state transition based on target state, state idle
time, and some other Tegra CPU core cluster states information.

Current PSCI specification don't have function defined for passing runtime
state idle time predicted by governor (based on next events and state target
residency) to ARM trusted firmware.

With the support of adding new PSCI function to allow passing runtime state
idle time from kernel to ARM trusted firmware, Tegra194 platforms can use
generic psci cpuidle driver rather than having Tegra specific cpuidle driver.

During Tegra specific cpuidle driver V1 review, Sudeep Holla from ARM also
suggested to use generic cpuidle driver by generalizing the need of runtime
state idle time.

So had internal discussion between ARM and NVIDIA on adding new PSCI function
to allow passing runtime state idle time from kernel to TF-A through PSCI and
once this implementation is accepted by upstream, ARM will look into further
to update PSCI specification for this new PSCI function.

So sending these patches as RFC as new PSCI function added in this series is
not part of PSCI specification and once this implementation is accepted by ARM
and upstream community, ARM can help to take this forward to add to PSCI
specification.

To keep the backward compatibility we can't update CPU_SUSPEND function to pass
state idle time argument. So added seperate function for passing state idle time
and serializing this with cpu suspend state enter.

Once this approach is agreed, we can either use this way of separate PSCI
function for passing state idle time or with PSCI specification update we can
use same CPU_SUSPEND function with extra argument for state idle time which can
be decided later for final patches based on discussion with ARM.


Sowjanya Komatineni (4):
  firmware/psci: add support for PSCI function SET_STATE_IDLE_TIME
  cpuidle: menu: add idle_time to cpuidle_state
  cpuidle: psci: pass state idle time before state enter callback
  arm64: dts: tegra194: Add CPU idle states

 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 19 +++++++++++++++++++
 drivers/cpuidle/cpuidle-psci.c           | 11 +++++++++++
 drivers/cpuidle/governors/menu.c         |  7 ++++++-
 drivers/firmware/psci/psci.c             |  9 +++++++++
 include/linux/cpuidle.h                  |  1 +
 include/linux/psci.h                     |  1 +
 include/uapi/linux/psci.h                |  2 ++
 7 files changed, 49 insertions(+), 1 deletion(-)

-- 
2.7.4



From patchwork-bot+netdevbpf at kernel.org  Thu Apr 22 23:10:10 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 22 Apr 2021 22:10:10 +0000
Subject: [PATCH net-next 0/2] Enable DWMAC HW descriptor prefetch
In-Reply-To: <20210422075501.20207-1-mohammad.athari.ismail@intel.com>
References: <20210422075501.20207-1-mohammad.athari.ismail@intel.com>
Message-ID: <161912941046.2979.7304318952227636688.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Thu, 22 Apr 2021 15:54:59 +0800 you wrote:
> From: Mohammad Athari Bin Ismail <mohammad.athari.ismail at intel.com>
> 
> This patch series to add setting for HW descriptor prefetch for DWMAC version 5.20 onwards. For Intel platform, enable the capability by default.
> 
> Mohammad Athari Bin Ismail (2):
>   net: stmmac: Add HW descriptor prefetch setting for DWMAC Core 5.20
>     onwards
>   stmmac: intel: Enable HW descriptor prefetch by default
> 
> [...]

Here is the summary with links:
  - [net-next,1/2] net: stmmac: Add HW descriptor prefetch setting for DWMAC Core 5.20 onwards
    https://git.kernel.org/netdev/net-next/c/96874c619c20
  - [net-next,2/2] stmmac: intel: Enable HW descriptor prefetch by default
    https://git.kernel.org/netdev/net-next/c/676b7ec67d79

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From patchwork-bot+netdevbpf at kernel.org  Thu Apr 22 23:10:09 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Thu, 22 Apr 2021 22:10:09 +0000
Subject: [PATCH net v2 0/2] Change phy-mode to RGMII-ID to enable delay
 pins for RTL8211E
In-Reply-To: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
References: <1619112709-13234-1-git-send-email-hayashi.kunihiko@socionext.com>
Message-ID: <161912940971.2979.14549137476438652466.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net.git (refs/heads/master):

On Fri, 23 Apr 2021 02:31:47 +0900 you wrote:
> UniPhier PXs2, LD20, and PXs3 boards have RTL8211E ethernet phy, and the
> phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY
> and TXDLY pins.
> 
> After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), the delays are working correctly, however, "rgmii" means
> no delay and the phy doesn't work. So need to set the phy-mode to
> "rgmii-id" to show that RX/TX delays are enabled.
> 
> [...]

Here is the summary with links:
  - [net,v2,1/2] ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E
    https://git.kernel.org/netdev/net/c/9ba585cc5b56
  - [net,v2,2/2] arm64: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E
    https://git.kernel.org/netdev/net/c/dcabb06bf127

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From gshan at redhat.com  Fri Apr 23 01:36:09 2021
From: gshan at redhat.com (Gavin Shan)
Date: Fri, 23 Apr 2021 10:36:09 +1000
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <20210415140328.24200-2-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
Message-ID: <b3da0d70-30e4-e128-cb76-16d335829541@redhat.com>

On 4/16/21 12:03 AM, Keqian Zhu wrote:
> The MMIO regions may be unmapped for many reasons and can be remapped
> by stage2 fault path. Map MMIO regions at creation time becomes a
> minor optimization and makes these two mapping path hard to sync.
> 
> Remove the mapping code while keep the useful sanity check.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>   arch/arm64/kvm/mmu.c | 38 +++-----------------------------------
>   1 file changed, 3 insertions(+), 35 deletions(-)
>

Reviewed-by: Gavin Shan <gshan at redhat.com>

  
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8711894db8c2..c59af5ca01b0 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1301,7 +1301,6 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   {
>   	hva_t hva = mem->userspace_addr;
>   	hva_t reg_end = hva + mem->memory_size;
> -	bool writable = !(mem->flags & KVM_MEM_READONLY);
>   	int ret = 0;
>   
>   	if (change != KVM_MR_CREATE && change != KVM_MR_MOVE &&
> @@ -1318,8 +1317,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   	mmap_read_lock(current->mm);
>   	/*
>   	 * A memory region could potentially cover multiple VMAs, and any holes
> -	 * between them, so iterate over all of them to find out if we can map
> -	 * any of them right now.
> +	 * between them, so iterate over all of them.
>   	 *
>   	 *     +--------------------------------------------+
>   	 * +---------------+----------------+   +----------------+
> @@ -1330,50 +1328,20 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   	 */
>   	do {
>   		struct vm_area_struct *vma = find_vma(current->mm, hva);
> -		hva_t vm_start, vm_end;
>   
>   		if (!vma || vma->vm_start >= reg_end)
>   			break;
>   
> -		/*
> -		 * Take the intersection of this VMA with the memory region
> -		 */
> -		vm_start = max(hva, vma->vm_start);
> -		vm_end = min(reg_end, vma->vm_end);
> -
>   		if (vma->vm_flags & VM_PFNMAP) {
> -			gpa_t gpa = mem->guest_phys_addr +
> -				    (vm_start - mem->userspace_addr);
> -			phys_addr_t pa;
> -
> -			pa = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
> -			pa += vm_start - vma->vm_start;
> -
>   			/* IO region dirty page logging not allowed */
>   			if (memslot->flags & KVM_MEM_LOG_DIRTY_PAGES) {
>   				ret = -EINVAL;
> -				goto out;
> -			}
> -
> -			ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
> -						    vm_end - vm_start,
> -						    writable);
> -			if (ret)
>   				break;
> +			}
>   		}
> -		hva = vm_end;
> +		hva = min(reg_end, vma->vm_end);
>   	} while (hva < reg_end);
>   
> -	if (change == KVM_MR_FLAGS_ONLY)
> -		goto out;
> -
> -	spin_lock(&kvm->mmu_lock);
> -	if (ret)
> -		unmap_stage2_range(&kvm->arch.mmu, mem->guest_phys_addr, mem->memory_size);
> -	else if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
> -		stage2_flush_memslot(kvm, memslot);
> -	spin_unlock(&kvm->mmu_lock);
> -out:
>   	mmap_read_unlock(current->mm);
>   	return ret;
>   }
> 



From gshan at redhat.com  Fri Apr 23 01:37:12 2021
From: gshan at redhat.com (Gavin Shan)
Date: Fri, 23 Apr 2021 10:37:12 +1000
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <20210415140328.24200-3-zhukeqian1@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
Message-ID: <b201abab-a183-8014-884b-436018c6f71a@redhat.com>

On 4/16/21 12:03 AM, Keqian Zhu wrote:
> The MMIO region of a device maybe huge (GB level), try to use
> block mapping in stage2 to speedup both map and unmap.
> 
> Compared to normal memory mapping, we should consider two more
> points when try block mapping for MMIO region:
> 
> 1. For normal memory mapping, the PA(host physical address) and
> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
> the HVA to request hugepage, so we don't need to consider PA
> alignment when verifing block mapping. But for device memory
> mapping, the PA and HVA may have different alignment.
> 
> 2. For normal memory mapping, we are sure hugepage size properly
> fit into vma, so we don't check whether the mapping size exceeds
> the boundary of vma. But for device memory mapping, we should pay
> attention to this.
> 
> This adds get_vma_page_shift() to get page shift for both normal
> memory and device MMIO region, and check these two points when
> selecting block mapping size for MMIO region.
> 
> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
> ---
>   arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>   1 file changed, 51 insertions(+), 10 deletions(-)
> 

Reviewed-by: Gavin Shan <gshan at redhat.com>

> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c59af5ca01b0..5a1cc7751e6d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>   	return PAGE_SIZE;
>   }
>   
> +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> +{
> +	unsigned long pa;
> +
> +	if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
> +		return huge_page_shift(hstate_vma(vma));
> +
> +	if (!(vma->vm_flags & VM_PFNMAP))
> +		return PAGE_SHIFT;
> +
> +	VM_BUG_ON(is_vm_hugetlb_page(vma));
> +
> +	pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
> +
> +#ifndef __PAGETABLE_PMD_FOLDED
> +	if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PUD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PUD_SIZE) <= vma->vm_end)
> +		return PUD_SHIFT;
> +#endif
> +
> +	if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
> +	    ALIGN_DOWN(hva, PMD_SIZE) >= vma->vm_start &&
> +	    ALIGN(hva, PMD_SIZE) <= vma->vm_end)
> +		return PMD_SHIFT;
> +
> +	return PAGE_SHIFT;
> +}
> +
>   static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   			  struct kvm_memory_slot *memslot, unsigned long hva,
>   			  unsigned long fault_status)
> @@ -769,7 +798,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   	}
>   
> -	/* Let's check if we will get back a huge page backed by hugetlbfs */
> +	/*
> +	 * Let's check if we will get back a huge page backed by hugetlbfs, or
> +	 * get block mapping for device MMIO region.
> +	 */
>   	mmap_read_lock(current->mm);
>   	vma = find_vma_intersection(current->mm, hva, hva + 1);
>   	if (unlikely(!vma)) {
> @@ -778,15 +810,15 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   	}
>   
> -	if (is_vm_hugetlb_page(vma))
> -		vma_shift = huge_page_shift(hstate_vma(vma));
> -	else
> -		vma_shift = PAGE_SHIFT;
> -
> -	if (logging_active ||
> -	    (vma->vm_flags & VM_PFNMAP)) {
> +	/*
> +	 * logging_active is guaranteed to never be true for VM_PFNMAP
> +	 * memslots.
> +	 */
> +	if (logging_active) {
>   		force_pte = true;
>   		vma_shift = PAGE_SHIFT;
> +	} else {
> +		vma_shift = get_vma_page_shift(vma, hva);
>   	}
>   
>   	switch (vma_shift) {
> @@ -854,8 +886,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   		return -EFAULT;
>   
>   	if (kvm_is_device_pfn(pfn)) {
> +		/*
> +		 * If the page was identified as device early by looking at
> +		 * the VMA flags, vma_pagesize is already representing the
> +		 * largest quantity we can map.  If instead it was mapped
> +		 * via gfn_to_pfn_prot(), vma_pagesize is set to PAGE_SIZE
> +		 * and must not be upgraded.
> +		 *
> +		 * In both cases, we don't let transparent_hugepage_adjust()
> +		 * change things at the last minute.
> +		 */
>   		device = true;
> -		force_pte = true;
>   	} else if (logging_active && !write_fault) {
>   		/*
>   		 * Only actually map the page as writable if this was a write
> @@ -876,7 +917,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>   	 * If we are not forced to use page mapping, check if we are
>   	 * backed by a THP and thus use block mapping if possible.
>   	 */
> -	if (vma_pagesize == PAGE_SIZE && !force_pte)
> +	if (vma_pagesize == PAGE_SIZE && !(force_pte || device))
>   		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>   							   &pfn, &fault_ipa);
>   	if (writable)
> 



From gshan at redhat.com  Fri Apr 23 01:42:08 2021
From: gshan at redhat.com (Gavin Shan)
Date: Fri, 23 Apr 2021 10:42:08 +1000
Subject: [PATCH v4 2/2] kvm/arm64: Try stage2 block mapping for host
 device MMIO
In-Reply-To: <87tunyq0av.wl-maz@kernel.org>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-3-zhukeqian1@huawei.com>
 <960e097d-818b-00bc-b2ee-0da17857f862@redhat.com>
 <105a403a-e48b-15bc-44ff-0ff34f7d2194@huawei.com>
 <46606f3e-ef41-6520-6647-88c0f76a83e0@redhat.com>
 <87tunyq0av.wl-maz@kernel.org>
Message-ID: <b39cb015-39bb-cb03-e095-414e323fd6aa@redhat.com>

Hi Marc,

On 4/22/21 4:51 PM, Marc Zyngier wrote:
> On Thu, 22 Apr 2021 03:25:23 +0100,
> Gavin Shan <gshan at redhat.com> wrote:
>> On 4/21/21 4:36 PM, Keqian Zhu wrote:
>>> On 2021/4/21 15:52, Gavin Shan wrote:
>>>> On 4/16/21 12:03 AM, Keqian Zhu wrote:
>>>>> The MMIO region of a device maybe huge (GB level), try to use
>>>>> block mapping in stage2 to speedup both map and unmap.
>>>>>
>>>>> Compared to normal memory mapping, we should consider two more
>>>>> points when try block mapping for MMIO region:
>>>>>
>>>>> 1. For normal memory mapping, the PA(host physical address) and
>>>>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>>>>> the HVA to request hugepage, so we don't need to consider PA
>>>>> alignment when verifing block mapping. But for device memory
>>>>> mapping, the PA and HVA may have different alignment.
>>>>>
>>>>> 2. For normal memory mapping, we are sure hugepage size properly
>>>>> fit into vma, so we don't check whether the mapping size exceeds
>>>>> the boundary of vma. But for device memory mapping, we should pay
>>>>> attention to this.
>>>>>
>>>>> This adds get_vma_page_shift() to get page shift for both normal
>>>>> memory and device MMIO region, and check these two points when
>>>>> selecting block mapping size for MMIO region.
>>>>>
>>>>> Signed-off-by: Keqian Zhu <zhukeqian1 at huawei.com>
>>>>> ---
>>>>>     arch/arm64/kvm/mmu.c | 61 ++++++++++++++++++++++++++++++++++++--------
>>>>>     1 file changed, 51 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>>>> index c59af5ca01b0..5a1cc7751e6d 100644
>>>>> --- a/arch/arm64/kvm/mmu.c
>>>>> +++ b/arch/arm64/kvm/mmu.c
>>>>> @@ -738,6 +738,35 @@ transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
>>>>>         return PAGE_SIZE;
>>>>>     }
>>>>>     +static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
>>>>> +{
>>>>> +    unsigned long pa;
>>>>> +
>>>>> +    if (is_vm_hugetlb_page(vma) && !(vma->vm_flags & VM_PFNMAP))
>>>>> +        return huge_page_shift(hstate_vma(vma));
>>>>> +
>>>>> +    if (!(vma->vm_flags & VM_PFNMAP))
>>>>> +        return PAGE_SHIFT;
>>>>> +
>>>>> +    VM_BUG_ON(is_vm_hugetlb_page(vma));
>>>>> +
>>>>
>>>> I don't understand how VM_PFNMAP is set for hugetlbfs related vma.
>>>> I think they are exclusive, meaning the flag is never set for
>>>> hugetlbfs vma. If it's true, VM_PFNMAP needn't be checked on hugetlbfs
>>>> vma and the VM_BUG_ON() becomes unnecessary.
>>> Yes, but we're not sure all drivers follow this rule. Add a BUG_ON() is
>>> a way to catch issue.
>>>
>>
>> I think I didn't make things clear. What I meant is VM_PFNMAP can't
>> be set for hugetlbfs VMAs. So the checks here can be simplified as
>> below if you agree:
>>
>>      if (is_vm_hugetlb_page(vma))
>>          return huge_page_shift(hstate_vma(vma));
>>
>>      if (!(vma->vm_flags & VM_PFNMAP))
>>          return PAGE_SHIFT;
>>
>>      VM_BUG_ON(is_vm_hugetlb_page(vma));       /* Can be dropped */
> 
> No. If this case happens, I want to see it. I have explicitly asked
> for it, and this check stays.
> 

Thanks for the explanation. To keep VM_BUG_ON() sounds good to me too :)

Thanks,
Gavin



From gshan at redhat.com  Fri Apr 23 02:35:22 2021
From: gshan at redhat.com (Gavin Shan)
Date: Fri, 23 Apr 2021 11:35:22 +1000
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <9eb47a6c-3c5c-cb4a-d1de-1a3ce1b60a87@huawei.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
 <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
 <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>
 <f13bfc39-bee6-4562-fefc-76051bbf9735@redhat.com>
 <9eb47a6c-3c5c-cb4a-d1de-1a3ce1b60a87@huawei.com>
Message-ID: <d185bbe1-4bb3-6a38-7a94-b0c52126e583@redhat.com>

Hi Keqian,

On 4/22/21 5:41 PM, Keqian Zhu wrote:
> On 2021/4/22 10:12, Gavin Shan wrote:
>> On 4/21/21 4:28 PM, Keqian Zhu wrote:
>>> On 2021/4/21 14:38, Gavin Shan wrote:
>>>> On 4/16/21 12:03 AM, Keqian Zhu wrote:

[...]

>>
>> Yeah, Sorry that I missed that part. Something associated with Santosh's
>> patch. The flag can be not existing until the page fault happened on
>> the vma. In this case, the check could be not working properly.
>>
>>    [PATCH] KVM: arm64: Correctly handle the mmio faulting
> Yeah, you are right.
> 
> If that happens, we won't try to use block mapping for memslot with VM_PFNMAP.
> But it keeps a same logic with old code.
> 
> 1. When without dirty-logging, we won't try block mapping for it, and we'll
> finally know that it's device, so won't try to do adjust THP (Transparent Huge Page)
> for it.
> 2. If userspace wrongly enables dirty logging for this memslot, we'll force_pte for it.
> 

It's not about the patch itself and just want more discussion to get more details.
The patch itself looks good to me. I got two questions as below:

(1) The memslot fails to be added if it's backed by MMIO region and dirty logging is
enabled in kvm_arch_prepare_memory_region(). As Santosh reported, the corresponding
vma could be associated with MMIO region and VM_PFNMAP is missed. In this case,
kvm_arch_prepare_memory_region() isn't returning error, meaning the memslot can be
added successfully and block mapping isn't used, as you mentioned. The question is
the memslot is added, but the expected result would be failure.

(2) If dirty logging is enabled on the MMIO memslot, everything should be fine. If
the dirty logging isn't enabled and VM_PFNMAP isn't set yet in user_mem_abort(),
block mapping won't be used and PAGE_SIZE is picked, but the failing IPA might
be good candidate for block mapping. It means we miss something for blocking
mapping?

By the way, do you have idea why dirty logging can't be enabled on MMIO memslot?
I guess Marc might know the history. For example, QEMU is taking "/dev/mem" or
"/dev/kmem" to back guest's memory, the vma is marked as MMIO, but dirty logging
and migration isn't supported?

Thanks,
Gavin



From gshan at redhat.com  Fri Apr 23 02:38:38 2021
From: gshan at redhat.com (Gavin Shan)
Date: Fri, 23 Apr 2021 11:38:38 +1000
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <87v98eq0dh.wl-maz@kernel.org>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
 <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
 <87v98eq0dh.wl-maz@kernel.org>
Message-ID: <33eb4850-2476-01ae-e3db-5bd20c1a2c23@redhat.com>

Hi Marc,

On 4/22/21 4:50 PM, Marc Zyngier wrote:
> On Thu, 22 Apr 2021 03:02:00 +0100,
> Gavin Shan <gshan at redhat.com> wrote:
>> On 4/21/21 9:59 PM, Marc Zyngier wrote:
>>> On Wed, 21 Apr 2021 07:17:44 +0100,
>>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>>> On 2021/4/21 14:20, Gavin Shan wrote:
>>>>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
>>>>>> On 2020/10/22 0:16, Santosh Shukla wrote:
>>>>>>> The Commit:6d674e28 introduces a notion to detect and handle the
>>>>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
>>>>>>> in vma->flags and if set then marks force_pte to true such that
>>>>>>> if force_pte is true then ignore the THP function check
>>>>>>> (/transparent_hugepage_adjust()).
>>>>>>>
>>>>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
>>>>>>> For example consider a case where the mdev vendor driver register's
>>>>>>> the vma_fault handler named vma_mmio_fault(), which maps the
>>>>>>> host MMIO region in-turn calls remap_pfn_range() and maps
>>>>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>>>>>>> the VM_PFNMAP flag into vma->flags.
>>>>>> Could you give the name of the mdev vendor driver that triggers this issue?
>>>>>> I failed to find one according to your description. Thanks.
>>>>>>
>>>>>
>>>>> I think it would be fixed in driver side to set VM_PFNMAP in
>>>>> its mmap() callback (call_mmap()), like vfio PCI driver does.
>>>>> It means it won't be delayed until page fault is issued and
>>>>> remap_pfn_range() is called. It's determined from the beginning
>>>>> that the vma associated the mdev vendor driver is serving as
>>>>> PFN remapping purpose. So the vma should be populated completely,
>>>>> including the VM_PFNMAP flag before it becomes visible to user
>>>>> space.
>>>
>>> Why should that be a requirement? Lazy populating of the VMA should be
>>> perfectly acceptable if the fault can only happen on the CPU side.
>>>
>>
>> It isn't a requirement and the drivers needn't follow strictly. I checked
>> several drivers before looking into the patch and found almost all the
>> drivers have VM_PFNMAP set at mmap() time. In drivers/vfio/vfio-pci.c,
>> there is a comment as below, but it doesn't reveal too much about why
>> we can't set VM_PFNMAP at fault time.
>>
>> static int vfio_pci_mmap(void *device_data, 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.
>>           */
>>          vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
>>          vma->vm_ops = &vfio_pci_mmap_ops;
>>
>>          return 0;
>> }
>>
>> To set these flags in advance does have advantages. For example,
>> VM_DONTEXPAND prevents the vma to be merged with another
>> one. VM_DONTDUMP make this vma isn't eligible for
>> coredump. Otherwise, the address space, which is associated with the
>> vma is accessed and unnecessary page faults are triggered on
>> coredump.  VM_IO and VM_PFNMAP avoids to walk the page frames
>> associated with the vma since we don't have valid PFN in the
>> mapping.
> 
> But PCI clearly isn't the case we are dealing with here, and not
> everything is VFIO either. I can *today* create a driver that
> implements a mmap+fault handler, call mmap() on it, pass the result to
> a memslot, and get to the exact same result Santosh describes.
> 
> No PCI, no VFIO, just a random driver. We are *required* to handle
> that.
> 

hmm, ok. I was thinking it's related to VFIO mdev driver when Santosh was
talking about "mdev driver". Anyway, it's always nice to support the case :)

Thanks,
Gavin



From f.fainelli at gmail.com  Fri Apr 23 00:49:19 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 22 Apr 2021 16:49:19 -0700
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
Message-ID: <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>



On 4/22/2021 1:10 PM, Joe Burmeister wrote:
>> On 4/20/2021 1:34 AM, Joe Burmeister wrote:
>>> It was previoulsy possible to have a device tree with more chips than
>>> the driver supports and go off the end of CS arrays.
>> Do you mind walking me through the code how that could have happened? We
>> have spi_register_controller() call of_spi_get_gpio_numbers() which has
>> the following:
>>
>> ctlr->num_chipselect = max_t(int, nb, ctlr->num_chipselect);
>>
>> such that what the controller has is the maximum between the number of
>> 'cs-gpios' properties parsed and what was already populated in
>> ctrl->num_chipselect during bcm2835_spi_probe(), which for this driver
>> is BCM2835_SPI_NUM_CS (3).
> 
> If you make a initial device tree (or add overlay in the rpi's 
> config.txt) with more on the bus than BCM2835_SPI_NUM_CS (in my case 8
> devices), you get into this trampling memory state. As the devices are
> added, once the chip_select is equal to or greater than
> BCM2835_SPI_NUM_CS, it's writing off the end of the arrays.

OK.

> 
> There is no protection from this happening. By the looks of it, this
> isn't the only driver this could happen with, but it is the one I have
> hardware for to test. There are also drivers that look like they don't
> have a problem going well beyond the limit they gave.

Right, which means that we should probably seek a solution within the
SPI core itself, even if you can only test with spi-bcm2835.c chances
are that the fix would be applicable for other controllers if done in
the core.

> 
> There is protection in spi_add_device, which will catch extra added
> later, but not ones in the device tree when the spi controller was
> registered.

Not sure I follow you, if we have the overlay before
spi_register_controller() is called, how can the check there not
trigger? And if we load the overlay later when the SPI controller is
already registered, why does not spi_add_device()'s check work?

How would I go about reproducing this on a Pi4?

> 
>>> This patches inforces CS limit but sets that limit to the max of the
>>> default limit and what is in the device tree when driver is loaded.
>>>
>>> Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>
>> You have changed many more things that just enforcing a limit on
>> BCM2835_SPI_NUM_CS you have now made all chip-select related data
>> structuresd dynamically allocated and you have changed a number of
>> prints to use the shorthand "dev" instead of &pdev->dev.
> The change to dynamic allocated arrays is just to support what is given
> in the device? tree rather than increase and enforce the CS limit just
> for my case.
> 
> The shorthand is of course not required. I'll drop it on resubmitting.
> 
> Regards,
> 
> Joe
> 
> 

-- 
Florian


From peng.fan at nxp.com  Fri Apr 23 02:01:27 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Fri, 23 Apr 2021 01:01:27 +0000
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <20210422165634.GD1256950@xps15>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
 <20210422165634.GD1256950@xps15>
Message-ID: <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>

Hi Mathieu,

> Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> i.MX7ULP/8MN/8MP
> 
> On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com wrote:
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > V5:
> >  Add R-b tag
> >  Move the change in detect mode of patch 5 to patch 7 Per Mathieu's
> > comments
> >
> > V4:
> >  Typo fix
> >  patch 4: take state as a check condition  patch 5: move regmap
> > lookup/attach to imx_rproc_detect_mode  patch 6: add
> > imx_rproc_clk_enable for optional clk  patch 8: use switch/case in
> > imx_rproc_detect_mode
> > V3:
> >  Add A-b tag for Patch 1/2
> >  Fix the checkpatch warning for Patch 6,8
> >
> > V2:
> >  Patch 1/8, use fsl as vendor, typo fix  Because patchset [1] has v2
> > version, patch 5,6,7,8 are adapted that  change.
> >
> > This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
> > parse fsl,auto-boot
> >
> 
> One of the request I had from the last revision was to explicitly list what other
> patchset this work depends on and what branch it is based of, something I
> can't find here.

Sorry, that patchset has been merged, so I remove that line.
I should mention that that patchset has been merged into Linux-next tree.

> 
> As such I am dropping this set and won't look at another revision before May
> 22nd.

Ah. Is it just because that the dependency patchset not been mentioned or you
have issue applying the patchset that delay the patchset for one month?

Thanks,
Peng.

> 
> > Peng Fan (8):
> >   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> >   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> >   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> >   remoteproc: imx_rproc: parse fsl,auto-boot
> >   remoteproc: imx_rproc: initial support for mutilple start/stop method
> >   remoteproc: imx_rproc: make clk optional
> >   remoteproc: imx_rproc: support i.MX7ULP
> >   remoteproc: imx_rproc: support i.MX8MN/P
> >
> >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
> >  drivers/remoteproc/imx_rproc.c                | 196
> +++++++++++++++---
> >  2 files changed, 173 insertions(+), 34 deletions(-)
> >
> > --
> > 2.30.0
> >


From kever.yang at rock-chips.com  Fri Apr 23 02:02:35 2021
From: kever.yang at rock-chips.com (Kever Yang)
Date: Fri, 23 Apr 2021 09:02:35 +0800
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <7d1f197d868ae84a8bc475f1f48178d2737518c1.camel@collabora.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com> <11131098.F0gNSz5aLb@diego>
 <7d1f197d868ae84a8bc475f1f48178d2737518c1.camel@collabora.com>
Message-ID: <1e0cb95e-e040-d34b-6443-ae93668962ec@rock-chips.com>

Hi Heiko, Ezequiel,

On 2021/4/23 ??1:23, Ezequiel Garcia wrote:
> Hi Liang,
>
> I'm very impressed Rockchip is pushing patches so early, thanks a lot!
>
> See below.
>
> On Wed, 2021-04-21 at 11:13 +0200, Heiko St?bner wrote:
>> Hi Liang,
>>
>> Am Mittwoch, 21. April 2021, 08:59:20 CEST schrieb cl at rock-chips.com:
>>> From: Liang Chen <cl at rock-chips.com>
>>>
>>> RK3568 is a high-performance and low power quad-core application processor
>>> designed for personal mobile internet device and AIoT equipments.
>>>
>>> This patch add basic core dtsi file for it.
>>>
>>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> this is a first round of basic stuff :-) .
>>
>> First of all, I really like the move of moving the pretty standardized
>> pinconfig entries to the rockchip-pinconf.dtsi .
>>
>> (1) But please move this into a separate patch to make that more visible
>> and maybe even convert _some_ or all arm64 Rockchip socs to use that
>> as well
>>
>> "arm64: dts: rockchip: add generic pinconfig settings used by most Rockchip socs
>>
>> The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
>> so move them to a shared dtsi to be included, instead of redefining them
>> for each soc"
>>
>> (2) I also like the external rk3568-pinctrl approach with the dtsi getting
>> auto-generated. This will probably help us in keeping pinctrl settings
>> synchronous between mainline and the vendor kernel.
>>
>> (3) From my basic understanding the rk3568 is basically a rk3566 + more
>> peripherals, so ideally they would share the basic ones in a rk3566.dtsi
>> which the rk3568.dtsi then could include and extend with its additional
>> peripherals.
>>
>> With at least the pine64 boards being based on the rk3566, there probably
>> will be quite a mainline use of it as well.
>>
>> Or is there something that would prevent this?
>>
> I agree with having a rk3566.dtsi, and rk3568.dtsi on top, instead of the
> other way around. We have some RK3566 boards here, so we can surely test
> the RK3566.dtsi patches very quickly.
We consider rk3568 as a full implementation and rk3566 is a subset, all 
the dts compatible string for
driver should go with string 'rk3568', and rk3568 will be the long term 
version and definitely have more
boards? in next few years. So we would like to upstream rk3568 first and 
follow the implement mode
of PX30+RK3326, which can also cover the need by RK3566.

We can have a rk3566.dtsi like rk3326.dtsi.


Thanks,
- Kever
>
> Also, it's fine if you want to send v2 with just these minimal peripherals.
> However, I think you could include GMAC and TS-ADC:
>
> https://lore.kernel.org/linux-rockchip/31c2e531-96d0-a1c1-644c-28c60eb40cf4 at gmail.com/T/#t
> https://lore.kernel.org/linux-rockchip/20210421203409.40717-1-ezequiel at collabora.com/T/#t
>
> These should work right out of the box!
>
> Thanks!
> Ezequiel
>
>
>




From skomatineni at nvidia.com  Fri Apr 23 02:03:27 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Thu, 22 Apr 2021 18:03:27 -0700
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <82b57776-9002-0dc8-aa0e-f1057ce3beef@nvidia.com>

kernel test robot reported below errors for patch-2 of this series. Will 
fix in next version to use div_u64() for nsec to usec conversion along 
with the other feedback I may be receiving.

drivers/cpuidle/governors/menu.c:398: undefined reference to `__udivdi3'
ld: drivers/cpuidle/governors/menu.c:398: undefined reference to `__udivdi3'
ld: drivers/cpuidle/governors/menu.c:398: undefined reference to `__udivdi3'
ld: drivers/cpuidle/governors/menu.c:398: undefined reference to `__udivdi3'

Thanks

Sowjanya

On 4/22/21 1:30 PM, Sowjanya Komatineni wrote:
> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
> in charge of deciding on state transition based on target state, state idle
> time, and some other Tegra CPU core cluster states information.
>
> Current PSCI specification don't have function defined for passing runtime
> state idle time predicted by governor (based on next events and state target
> residency) to ARM trusted firmware.
>
> With the support of adding new PSCI function to allow passing runtime state
> idle time from kernel to ARM trusted firmware, Tegra194 platforms can use
> generic psci cpuidle driver rather than having Tegra specific cpuidle driver.
>
> During Tegra specific cpuidle driver V1 review, Sudeep Holla from ARM also
> suggested to use generic cpuidle driver by generalizing the need of runtime
> state idle time.
>
> So had internal discussion between ARM and NVIDIA on adding new PSCI function
> to allow passing runtime state idle time from kernel to TF-A through PSCI and
> once this implementation is accepted by upstream, ARM will look into further
> to update PSCI specification for this new PSCI function.
>
> So sending these patches as RFC as new PSCI function added in this series is
> not part of PSCI specification and once this implementation is accepted by ARM
> and upstream community, ARM can help to take this forward to add to PSCI
> specification.
>
> To keep the backward compatibility we can't update CPU_SUSPEND function to pass
> state idle time argument. So added seperate function for passing state idle time
> and serializing this with cpu suspend state enter.
>
> Once this approach is agreed, we can either use this way of separate PSCI
> function for passing state idle time or with PSCI specification update we can
> use same CPU_SUSPEND function with extra argument for state idle time which can
> be decided later for final patches based on discussion with ARM.
>
>
> Sowjanya Komatineni (4):
>    firmware/psci: add support for PSCI function SET_STATE_IDLE_TIME
>    cpuidle: menu: add idle_time to cpuidle_state
>    cpuidle: psci: pass state idle time before state enter callback
>    arm64: dts: tegra194: Add CPU idle states
>
>   arch/arm64/boot/dts/nvidia/tegra194.dtsi | 19 +++++++++++++++++++
>   drivers/cpuidle/cpuidle-psci.c           | 11 +++++++++++
>   drivers/cpuidle/governors/menu.c         |  7 ++++++-
>   drivers/firmware/psci/psci.c             |  9 +++++++++
>   include/linux/cpuidle.h                  |  1 +
>   include/linux/psci.h                     |  1 +
>   include/uapi/linux/psci.h                |  2 ++
>   7 files changed, 49 insertions(+), 1 deletion(-)
>


From zhukeqian1 at huawei.com  Fri Apr 23 02:06:20 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Fri, 23 Apr 2021 09:06:20 +0800
Subject: [PATCH] KVM: arm64: Correctly handle the mmio faulting
In-Reply-To: <CACpj22xhXHMgsZHrL_2AbEzy=zzz=jXz0s6pRb0=zpJUai1ufg@mail.gmail.com>
References: <1603297010-18787-1-git-send-email-sashukla@nvidia.com>
 <8b20dfc0-3b5e-c658-c47d-ebc50d20568d@huawei.com>
 <2e23aaa7-0c8d-13ba-2eae-9e6ab2adc587@redhat.com>
 <ed8a8b90-8b96-4967-01f5-cd0f536c38d2@huawei.com>
 <871rb3rgpl.wl-maz@kernel.org>
 <b97415a2-7970-a741-9690-3e4514b4aa7d@redhat.com>
 <87v98eq0dh.wl-maz@kernel.org>
 <bf782ec1-71da-5a8e-f250-20ed88677b8c@nvidia.com>
 <CACpj22xhXHMgsZHrL_2AbEzy=zzz=jXz0s6pRb0=zpJUai1ufg@mail.gmail.com>
Message-ID: <c8b479d0-0766-ecb7-49fb-d94b715b0922@huawei.com>



On 2021/4/22 16:00, Santosh Shukla wrote:
> On Thu, Apr 22, 2021 at 1:07 PM Tarun Gupta (SW-GPU)
> <targupta at nvidia.com> wrote:
>>
>>
>>
>> On 4/22/2021 12:20 PM, Marc Zyngier wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On Thu, 22 Apr 2021 03:02:00 +0100,
>>> Gavin Shan <gshan at redhat.com> wrote:
>>>>
>>>> Hi Marc,
>>>>
>>>> On 4/21/21 9:59 PM, Marc Zyngier wrote:
>>>>> On Wed, 21 Apr 2021 07:17:44 +0100,
>>>>> Keqian Zhu <zhukeqian1 at huawei.com> wrote:
>>>>>> On 2021/4/21 14:20, Gavin Shan wrote:
>>>>>>> On 4/21/21 12:59 PM, Keqian Zhu wrote:
>>>>>>>> On 2020/10/22 0:16, Santosh Shukla wrote:
>>>>>>>>> The Commit:6d674e28 introduces a notion to detect and handle the
>>>>>>>>> device mapping. The commit checks for the VM_PFNMAP flag is set
>>>>>>>>> in vma->flags and if set then marks force_pte to true such that
>>>>>>>>> if force_pte is true then ignore the THP function check
>>>>>>>>> (/transparent_hugepage_adjust()).
>>>>>>>>>
>>>>>>>>> There could be an issue with the VM_PFNMAP flag setting and checking.
>>>>>>>>> For example consider a case where the mdev vendor driver register's
>>>>>>>>> the vma_fault handler named vma_mmio_fault(), which maps the
>>>>>>>>> host MMIO region in-turn calls remap_pfn_range() and maps
>>>>>>>>> the MMIO's vma space. Where, remap_pfn_range implicitly sets
>>>>>>>>> the VM_PFNMAP flag into vma->flags.
>>>>>>>> Could you give the name of the mdev vendor driver that triggers this issue?
>>>>>>>> I failed to find one according to your description. Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> I think it would be fixed in driver side to set VM_PFNMAP in
>>>>>>> its mmap() callback (call_mmap()), like vfio PCI driver does.
>>>>>>> It means it won't be delayed until page fault is issued and
>>>>>>> remap_pfn_range() is called. It's determined from the beginning
>>>>>>> that the vma associated the mdev vendor driver is serving as
>>>>>>> PFN remapping purpose. So the vma should be populated completely,
>>>>>>> including the VM_PFNMAP flag before it becomes visible to user
>>>>>>> space.
>>>>>
>>>>> Why should that be a requirement? Lazy populating of the VMA should be
>>>>> perfectly acceptable if the fault can only happen on the CPU side.
>>>>>
> 
> Right.
> Hi keqian,
> You can refer to case
> http://lkml.iu.edu/hypermail/linux/kernel/2010.3/00952.html
Hi Santosh,

Yeah, thanks for that.

BRs,
Keqian


From liam.howlett at oracle.com  Fri Apr 23 02:00:35 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Fri, 23 Apr 2021 01:00:35 +0000
Subject: [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal
 generation
In-Reply-To: <20210422125903.GD1521@willie-the-truck>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210422125903.GD1521@willie-the-truck>
Message-ID: <20210423010023.4jmzyzjzbnu4jgoa@revolver>

* Will Deacon <will at kernel.org> [210422 09:01]:
> On Tue, Apr 20, 2021 at 04:50:12PM +0000, Liam Howlett wrote:
> > arm64_notify_segfault() was written to decide on the si_code from the
> > assembly emulation of the swp_handler(), but was also used for the
> > signal generation from failed access_ok() and unaligned instructions.
> > 
> > When access_ok() fails, there is no need to search for the offending
> > address in the VMA space.  Instead, simply set the error to SIGSEGV with
> > si_code SEGV_ACCERR.
> > 
> > Change the return code from emulate_swpX() when there is an unaligned
> > pointer so the caller can differentiate from the EFAULT.  It is
> > unnecessary to search the VMAs in the case of an unaligned pointer.
> > This change uses SIGSEGV and SEGV_ACCERR instead of SIGBUS to keep with
> > what was returned before.
> > 
> > Fixes: bd35a4adc413 (arm64: Port SWP/SWPB emulation support from arm)
> > Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> > ---
> >  arch/arm64/kernel/armv8_deprecated.c | 20 +++++++++++++-------
> 
> Can you give an example of something that is fixed by this, please? At first
> glance, it doesn't look like it changes the user-visible behaviour.

In short, when !access_ok(), don't return SEGV_MAPERR.

access_ok() is defined as __range_ok() which checks if the address is a
userspace address.  If the access is not okay, then the return should be
SEGV_ACCERR.  However, if the address is above any known VMA, then the
return will be SEGV_MAPERR.  Isn't this a bug?

Right now this particular bug is masked almost always by the fact that
find_vma() will return SIGV_ACCERR unless it's abvove any known VMA, but
patch 3 in this series will alter the behaviour and thus, I wanted to
fix the bug here before fixing that bug.

> 
> We should also be compatible with arch/arm/ here (see set_segfault()).


Yes, the same error exists there it seems.  If my solution is
acceptable, I can expand it to include the same change there.

Thanks,
Liam

From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 02:19:09 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 02:19:09 +0100
Subject: [PATCH 0/4] Expand Xilinx CDMA functions
Message-ID: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>

Recently at Imgtec we had to provide GLES API buffers with DMA transfer
capabilities to device memory. We had access to a Xilinx CDMA IP module,
but even though the hardware supports scatter-gather operations,
the driver did not. This patch series' goal is to extend the driver
to support SG transfers on CDMA devices.

It also fixes a couple of issues I found in the driver: lack of support
for HW descriptors allocated in an extended address space (above 32 bits)
and an unusual race condition when closing a DMA channel.

Adrian Larumbe (4):
  dmaengine: xilinx_dma: Add extended address support in CDMA
  dmaengine: xilinx_dma: Add channel configuration setting callback
  dmaengine: xilinx_dma: Add CDMA SG transfer support
  dmaengine: xilinx_dma: Add device synchronisation callback

 drivers/dma/xilinx/xilinx_dma.c | 186 ++++++++++++++++++++++++++++++--
 1 file changed, 177 insertions(+), 9 deletions(-)

-- 
2.17.1



From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 02:19:10 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 02:19:10 +0100
Subject: [PATCH 1/4] dmaengine: xilinx_dma: Add extended address support in
 CDMA
In-Reply-To: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
Message-ID: <20210423011913.13122-2-adrian.martinezlarumbe@imgtec.com>

Not accounting for this means DMA HW descriptors can only be sourced from
the lower 32 bits of the address space. CDMA MSB descriptor registers were
also missing in the driver file, so this change also adds their register
offset definitions, which were taken from Xilpinx 'AXI Central Direct
Memory Access v4.1' LogiCORE IP Product Guide.

Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe at imgtec.com>
---
 drivers/dma/xilinx/xilinx_dma.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3aded7861fef..3f859de593dc 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -98,7 +98,9 @@
 #define XILINX_DMA_DMASR_FRAME_COUNT_MASK	GENMASK(23, 16)
 
 #define XILINX_DMA_REG_CURDESC			0x0008
+#define XILINX_DMA_REG_CURDESC_MSB		0x000C
 #define XILINX_DMA_REG_TAILDESC		0x0010
+#define XILINX_DMA_REG_TAILDESC_MSB	0x0014
 #define XILINX_DMA_REG_REG_INDEX		0x0014
 #define XILINX_DMA_REG_FRMSTORE		0x0018
 #define XILINX_DMA_REG_THRESHOLD		0x001c
@@ -184,6 +186,8 @@
 /* AXI CDMA Specific Registers/Offsets */
 #define XILINX_CDMA_REG_SRCADDR		0x18
 #define XILINX_CDMA_REG_DSTADDR		0x20
+#define XILINX_CDMA_REG_MSB_DSTADR	0x0024
+#define XILINX_CDMA_REG_MSB_SRCADDR	0x001C
 
 /* AXI CDMA Specific Masks */
 #define XILINX_CDMA_CR_SGMODE          BIT(3)
@@ -1459,9 +1463,19 @@ static void xilinx_cdma_start_transfer(struct xilinx_dma_chan *chan)
 		dma_ctrl_set(chan, XILINX_DMA_REG_DMACR,
 			     XILINX_CDMA_CR_SGMODE);
 
+		if (chan->ext_addr) {
+			xilinx_write(chan, XILINX_DMA_REG_CURDESC_MSB,
+				     upper_32_bits(head_desc->async_tx.phys));
+		}
+
 		xilinx_write(chan, XILINX_DMA_REG_CURDESC,
 			     head_desc->async_tx.phys);
 
+		if (chan->ext_addr) {
+			xilinx_write(chan, XILINX_DMA_REG_TAILDESC_MSB,
+				     upper_32_bits(tail_segment->phys));
+		}
+
 		/* Update tail ptr register which will start the transfer */
 		xilinx_write(chan, XILINX_DMA_REG_TAILDESC,
 			     tail_segment->phys);
@@ -1476,11 +1490,16 @@ static void xilinx_cdma_start_transfer(struct xilinx_dma_chan *chan)
 
 		hw = &segment->hw;
 
-		xilinx_write(chan, XILINX_CDMA_REG_SRCADDR,
-			     xilinx_prep_dma_addr_t(hw->src_addr));
-		xilinx_write(chan, XILINX_CDMA_REG_DSTADDR,
-			     xilinx_prep_dma_addr_t(hw->dest_addr));
-
+		xilinx_write(chan, XILINX_CDMA_REG_SRCADDR, hw->src_addr);
+		xilinx_write(chan, XILINX_CDMA_REG_DSTADDR, hw->dest_addr);
+		if (chan->ext_addr) {
+			xilinx_write(chan,
+				     XILINX_CDMA_REG_MSB_SRCADDR,
+				     hw->src_addr_msb);
+			xilinx_write(chan,
+				     XILINX_CDMA_REG_MSB_DSTADR,
+				     hw->dest_addr_msb);
+		}
 		/* Start the transfer */
 		dma_ctrl_write(chan, XILINX_DMA_REG_BTT,
 				hw->control & chan->xdev->max_buffer_len);
-- 
2.17.1



From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 02:19:13 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 02:19:13 +0100
Subject: [PATCH 4/4] dmaengine: xilinx_dma: Add device synchronisation callback
In-Reply-To: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
Message-ID: <20210423011913.13122-5-adrian.martinezlarumbe@imgtec.com>

This was required as an answer to a very unusual race condition, whereby a
thread waiting on a completion signaled in a callback triggered by
dmaengine_desc_callback_invoke might immediately attempt to release the
DMA channel whilst the channel lock was still free. This would cause the
remaining descriptors to be deallocated, and xilinx_dma_chan_desc_cleanup
to perform an invalid memory access when attempting to traverse the rest
of the channel's done_list.

Now, when releasing a DMA channel, it will wait until the tasklet has
finished.

Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe at imgtec.com>
---
 drivers/dma/xilinx/xilinx_dma.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 40c6cf8bf0e6..d4bad999e7f9 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -942,6 +942,13 @@ static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
 
 }
 
+static void xilinx_dma_synchronize(struct dma_chan *dchan)
+{
+	struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
+
+	tasklet_kill(&chan->tasklet);
+}
+
 /**
  * xilinx_dma_get_residue - Compute residue for a given descriptor
  * @chan: Driver specific dma channel
@@ -3235,6 +3242,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	xdev->common.device_tx_status = xilinx_dma_tx_status;
 	xdev->common.device_issue_pending = xilinx_dma_issue_pending;
 	xdev->common.device_config = xilinx_dma_slave_config;
+	xdev->common.device_synchronize = xilinx_dma_synchronize;
 	if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
 		dma_cap_set(DMA_CYCLIC, xdev->common.cap_mask);
 		xdev->common.device_prep_slave_sg = xilinx_dma_prep_slave_sg;
-- 
2.17.1



From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 02:19:11 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 02:19:11 +0100
Subject: [PATCH 2/4] dmaengine: xilinx_dma: Add channel configuration setting
 callback
In-Reply-To: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
Message-ID: <20210423011913.13122-3-adrian.martinezlarumbe@imgtec.com>

This callback allows the DMA Engine API user to set a per-channel
configuration structure before calling dmaengine_prep_slave_sg.
This is a prerequisite for being able to do CDMA SG transfers, because
one of the transfer ends is meant to be a preconfigured contiguous
block of memory.

A later implementation of CDMA SG transfers will access this configuration
structure, and is therefore dependent on this change.

Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe at imgtec.com>
---
 drivers/dma/xilinx/xilinx_dma.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3f859de593dc..49c7093e2487 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -392,6 +392,7 @@ struct xilinx_dma_tx_descriptor {
  * @irq: Channel IRQ
  * @id: Channel ID
  * @direction: Transfer direction
+ * @cfg: DMA slave channel configuration
  * @num_frms: Number of frames
  * @has_sg: Support scatter transfers
  * @cyclic: Check for cyclic transfers.
@@ -429,6 +430,7 @@ struct xilinx_dma_chan {
 	int irq;
 	int id;
 	enum dma_transfer_direction direction;
+	struct dma_slave_config cfg;
 	int num_frms;
 	bool has_sg;
 	bool cyclic;
@@ -2565,6 +2567,21 @@ static void xilinx_dma_chan_remove(struct xilinx_dma_chan *chan)
 	list_del(&chan->common.device_node);
 }
 
+/**
+ * xilinx_dma_slave_config - Set the channel config
+ * @dchan: DMA channel
+ * @cfg: DMA slave channel configuration
+ */
+static int xilinx_dma_slave_config(struct dma_chan *dchan,
+				   struct dma_slave_config *cfg)
+{
+	struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
+
+	chan->cfg = *cfg;
+
+	return 0;
+}
+
 static int axidma_clk_init(struct platform_device *pdev, struct clk **axi_clk,
 			    struct clk **tx_clk, struct clk **rx_clk,
 			    struct clk **sg_clk, struct clk **tmp_clk)
@@ -3095,6 +3112,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	xdev->common.device_terminate_all = xilinx_dma_terminate_all;
 	xdev->common.device_tx_status = xilinx_dma_tx_status;
 	xdev->common.device_issue_pending = xilinx_dma_issue_pending;
+	xdev->common.device_config = xilinx_dma_slave_config;
 	if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
 		dma_cap_set(DMA_CYCLIC, xdev->common.cap_mask);
 		xdev->common.device_prep_slave_sg = xilinx_dma_prep_slave_sg;
-- 
2.17.1



From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 02:19:12 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 02:19:12 +0100
Subject: [PATCH 3/4] dmaengine: xilinx_dma: Add CDMA SG transfer support
In-Reply-To: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
Message-ID: <20210423011913.13122-4-adrian.martinezlarumbe@imgtec.com>

CDMA devices have built-in SG capability, but it was not leveraged by the
driver. It adds a new binding for CDMA's device_prep_slave_sg, which
looks up the memory address supplied in a previous call to
dmaengine_slave_config as the beginning of a contiguous chunk of memory,
for either the source or destination of the transfer.

DMA_PRIVATE capability needs to be set for a CDMA channel too, or else
the DMA Engine core will take a reference upon registration, and it
won't be further available for callers of dma_request_chan.

Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe at imgtec.com>
---
 drivers/dma/xilinx/xilinx_dma.c | 131 +++++++++++++++++++++++++++++++-
 1 file changed, 127 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 49c7093e2487..40c6cf8bf0e6 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2433,6 +2433,130 @@ xilinx_mcdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
 	return NULL;
 }
 
+/**
+ * xilinx_cdma_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
+ * @dchan: DMA channel
+ * @sgl: scatterlist to transfer to/from
+ * @sg_len: number of entries in @scatterlist
+ * @direction: DMA direction
+ * @flags: transfer ack flags
+ * @context: APP words of the descriptor
+ *
+ * Return: Async transaction descriptor on success and NULL on failure
+ */
+static struct dma_async_tx_descriptor
+*xilinx_cdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
+						   unsigned int sg_len,
+						   enum dma_transfer_direction direction,
+						   unsigned long flags, void *context)
+{
+	struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
+	struct xilinx_cdma_tx_segment *segment, *prev = NULL;
+	struct xilinx_dma_tx_descriptor *desc;
+	struct xilinx_cdma_desc_hw *hw;
+	dma_addr_t dma_dst, dma_src, dma_addr;
+	size_t len, avail;
+
+	(void)flags;
+	(void)context;
+
+	if (!is_slave_direction(direction)) {
+		dev_err(chan->xdev->dev,
+			"%s: bad direction?\n", __func__);
+		return NULL;
+	}
+
+	if (unlikely(sg_len == 0 || !sgl))
+		return NULL;
+
+	dma_src = 0;
+	dma_dst = 0;
+
+	if (direction == DMA_DEV_TO_MEM)
+		dma_src = chan->cfg.src_addr;
+	else
+		dma_dst = chan->cfg.dst_addr;
+
+	desc = xilinx_dma_alloc_tx_descriptor(chan);
+	if (!desc)
+		return NULL;
+
+	dma_async_tx_descriptor_init(&desc->async_tx, &chan->common);
+	desc->async_tx.tx_submit = xilinx_dma_tx_submit;
+
+	avail = sg_dma_len(sgl);
+	/*
+	 * Loop until there is either no more source or no more
+	 * destination scatterlist entries
+	 */
+	while (true) {
+		len = min_t(size_t, avail, chan->xdev->max_buffer_len);
+		if (len == 0)
+			goto fetch;
+
+		/* Allocate the link descriptor from DMA pool */
+		segment = xilinx_cdma_alloc_tx_segment(chan);
+		if (!segment)
+			goto error;
+
+		dma_addr = sg_dma_address(sgl) + sg_dma_len(sgl) - avail;
+
+		if (direction == DMA_DEV_TO_MEM)
+			dma_dst = dma_addr;
+		else
+			dma_src = dma_addr;
+
+		hw = &segment->hw;
+		hw->control = len;
+		hw->src_addr = dma_src;
+		hw->dest_addr = dma_dst;
+		if (chan->ext_addr) {
+			hw->src_addr_msb = upper_32_bits(dma_src);
+			hw->dest_addr_msb = upper_32_bits(dma_dst);
+		}
+
+		if (prev) {
+			prev->hw.next_desc = segment->phys;
+			if (chan->ext_addr)
+				prev->hw.next_desc_msb = upper_32_bits(segment->phys);
+		}
+
+		prev = segment;
+		avail -= len;
+		list_add_tail(&segment->node, &desc->segments);
+
+		if (direction == DMA_DEV_TO_MEM)
+			dma_src += len;
+		else
+			dma_dst += len;
+fetch:
+		/* Fetch the next scatterlist entry */
+		if (avail == 0) {
+			if (sg_len == 0)
+				break;
+			sgl = sg_next(sgl);
+			if (!sgl)
+				break;
+			sg_len--;
+			avail = sg_dma_len(sgl);
+		}
+	}
+
+	/* Link the last hardware descriptor with the first. */
+	segment = list_first_entry(&desc->segments,
+							   struct xilinx_cdma_tx_segment, node);
+	desc->async_tx.phys = segment->phys;
+	prev->hw.next_desc = segment->phys;
+	if (chan->ext_addr)
+		prev->hw.next_desc_msb = upper_32_bits(segment->phys);
+
+	return &desc->async_tx;
+
+error:
+	xilinx_dma_free_tx_descriptor(chan, desc);
+	return NULL;
+}
+
 /**
  * xilinx_dma_terminate_all - Halt the channel and free descriptors
  * @dchan: Driver specific DMA Channel pointer
@@ -3100,10 +3224,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	xdev->common.dev = &pdev->dev;
 
 	INIT_LIST_HEAD(&xdev->common.channels);
-	if (!(xdev->dma_config->dmatype == XDMA_TYPE_CDMA)) {
-		dma_cap_set(DMA_SLAVE, xdev->common.cap_mask);
-		dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
-	}
+	dma_cap_set(DMA_SLAVE, xdev->common.cap_mask);
+	dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
 
 	xdev->common.device_alloc_chan_resources =
 				xilinx_dma_alloc_chan_resources;
@@ -3124,6 +3246,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
 	} else if (xdev->dma_config->dmatype == XDMA_TYPE_CDMA) {
 		dma_cap_set(DMA_MEMCPY, xdev->common.cap_mask);
 		xdev->common.device_prep_dma_memcpy = xilinx_cdma_prep_memcpy;
+		xdev->common.device_prep_slave_sg = xilinx_cdma_prep_slave_sg;
 		/* Residue calculation is supported by only AXI DMA and CDMA */
 		xdev->common.residue_granularity =
 					  DMA_RESIDUE_GRANULARITY_SEGMENT;
-- 
2.17.1



From ck.hu at mediatek.com  Fri Apr 23 02:29:41 2021
From: ck.hu at mediatek.com (CK Hu)
Date: Fri, 23 Apr 2021 09:29:41 +0800
Subject: [PATCH] drm/mediatek: clear pending flag when cmdq packet is done.
In-Reply-To: <20210422111004.1338867-1-hsinyi@chromium.org>
References: <20210422111004.1338867-1-hsinyi@chromium.org>
Message-ID: <1619141381.28327.8.camel@mtksdaap41>

Hi, Hsin-yi:

On Thu, 2021-04-22 at 19:10 +0800, Hsin-Yi Wang wrote:
> From: CK Hu <ck.hu at mediatek.com>
> 
> In cmdq mode, packet may be flushed before it is executed, so
> the pending flag should be cleared after cmdq packet is done.
> 
> Signed-off-by: CK Hu <ck.hu at mediatek.com>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  | 56 +++++++++++++++++++++---
>  include/linux/mailbox/mtk-cmdq-mailbox.h |  1 +
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 40df2c823187..051bf0eb00d3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -224,6 +224,45 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc,
>  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
>  static void ddp_cmdq_cb(struct cmdq_cb_data data)
>  {
> +	struct cmdq_pkt *pkt = (struct cmdq_pkt *)data.data;
> +	struct mtk_drm_crtc *mtk_crtc = (struct mtk_drm_crtc *)pkt->crtc;
> +	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> +	unsigned int i;
> +
> +	if (data.sta == CMDQ_CB_ERROR)

I prefer use standard error status instead of proprietary one, so I send
a patch [1]. I would like this patch depend on [1].

[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/20210314233323.23377-2-chunkuang.hu at kernel.org/

> +		goto destroy_pkt;
> +
> +	if (state->pending_config) {
> +		state->pending_config = false;
> +	}
> +
> +	if (mtk_crtc->pending_planes) {
> +		for (i = 0; i < mtk_crtc->layer_nr; i++) {
> +			struct drm_plane *plane = &mtk_crtc->planes[i];
> +			struct mtk_plane_state *plane_state;
> +
> +			plane_state = to_mtk_plane_state(plane->state);
> +
> +			if (plane_state->pending.config)
> +				plane_state->pending.config = false;
> +		}
> +		mtk_crtc->pending_planes = false;
> +	}
> +
> +	if (mtk_crtc->pending_async_planes) {
> +		for (i = 0; i < mtk_crtc->layer_nr; i++) {
> +			struct drm_plane *plane = &mtk_crtc->planes[i];
> +			struct mtk_plane_state *plane_state;
> +
> +			plane_state = to_mtk_plane_state(plane->state);
> +
> +			if (plane_state->pending.async_config)
> +				plane_state->pending.async_config = false;
> +		}
> +		mtk_crtc->pending_async_planes = false;
> +	}
> +
> +destroy_pkt:
>  	cmdq_pkt_destroy(data.data);
>  }
>  #endif
> @@ -377,8 +416,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
>  				    state->pending_height,
>  				    state->pending_vrefresh, 0,
>  				    cmdq_handle);
> -
> -		state->pending_config = false;
> +		if (!cmdq_handle)
> +			state->pending_config = false;
>  	}
>  
>  	if (mtk_crtc->pending_planes) {
> @@ -398,9 +437,11 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
>  				mtk_ddp_comp_layer_config(comp, local_layer,
>  							  plane_state,
>  							  cmdq_handle);
> -			plane_state->pending.config = false;
> +			if (!cmdq_handle)
> +				plane_state->pending.config = false;
>  		}
> -		mtk_crtc->pending_planes = false;
> +		if (!cmdq_handle)
> +			mtk_crtc->pending_planes = false;
>  	}
>  
>  	if (mtk_crtc->pending_async_planes) {
> @@ -420,9 +461,11 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
>  				mtk_ddp_comp_layer_config(comp, local_layer,
>  							  plane_state,
>  							  cmdq_handle);
> -			plane_state->pending.async_config = false;
> +			if (!cmdq_handle)
> +				plane_state->pending.async_config = false;
>  		}
> -		mtk_crtc->pending_async_planes = false;
> +		if (!cmdq_handle)
> +			mtk_crtc->pending_async_planes = false;
>  	}
>  }
>  
> @@ -475,6 +518,7 @@ static void mtk_drm_crtc_update_config(struct mtk_drm_crtc *mtk_crtc,
>  		cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
>  		mtk_crtc_ddp_config(crtc, cmdq_handle);
>  		cmdq_pkt_finalize(cmdq_handle);
> +		cmdq_handle->crtc = mtk_crtc;
>  		cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>  	}
>  #endif
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index d5a983d65f05..c06b14ec03e5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -90,6 +90,7 @@ struct cmdq_pkt {
>  	struct cmdq_task_cb	cb;
>  	struct cmdq_task_cb	async_cb;
>  	void			*cl;
> +	void			*crtc;

Not all client need crtc, so I would like to use another structure to
include cmdq_pkt and crtc and cast that structure to cmdq_pkt. I have a
plan to use mailbox rx_callback instead of cmdq_task_cb [2] (not
upstreamed yet), and it is an example that crtc include cmdq_pkt. To
upstream [2] would take a long time, you could choose to depend on [2]
or not.

[2]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/commit/?h=mediatek-cmdq&id=2c3289b1550ea1105a02750928df738753ddf8e1

Regards,
CK

>  };
>  
>  u8 cmdq_get_shift_pa(struct mbox_chan *chan);


From zhukeqian1 at huawei.com  Fri Apr 23 02:36:05 2021
From: zhukeqian1 at huawei.com (Keqian Zhu)
Date: Fri, 23 Apr 2021 09:36:05 +0800
Subject: [PATCH v4 1/2] kvm/arm64: Remove the creation time's mapping of
 MMIO regions
In-Reply-To: <d185bbe1-4bb3-6a38-7a94-b0c52126e583@redhat.com>
References: <20210415140328.24200-1-zhukeqian1@huawei.com>
 <20210415140328.24200-2-zhukeqian1@huawei.com>
 <ad39c796-2778-df26-b0c6-231e7626a747@redhat.com>
 <bd4d2cfc-37b9-f20a-5a5c-ed352d1a46dc@huawei.com>
 <f13bfc39-bee6-4562-fefc-76051bbf9735@redhat.com>
 <9eb47a6c-3c5c-cb4a-d1de-1a3ce1b60a87@huawei.com>
 <d185bbe1-4bb3-6a38-7a94-b0c52126e583@redhat.com>
Message-ID: <f521c845-610f-3efc-1713-9a01fb26f22f@huawei.com>

Hi Gavin,

On 2021/4/23 9:35, Gavin Shan wrote:
> Hi Keqian,
> 
> On 4/22/21 5:41 PM, Keqian Zhu wrote:
>> On 2021/4/22 10:12, Gavin Shan wrote:
>>> On 4/21/21 4:28 PM, Keqian Zhu wrote:
>>>> On 2021/4/21 14:38, Gavin Shan wrote:
>>>>> On 4/16/21 12:03 AM, Keqian Zhu wrote:
> 
> [...]
> 
>>>
>>> Yeah, Sorry that I missed that part. Something associated with Santosh's
>>> patch. The flag can be not existing until the page fault happened on
>>> the vma. In this case, the check could be not working properly.
>>>
>>>    [PATCH] KVM: arm64: Correctly handle the mmio faulting
>> Yeah, you are right.
>>
>> If that happens, we won't try to use block mapping for memslot with VM_PFNMAP.
>> But it keeps a same logic with old code.
>>
>> 1. When without dirty-logging, we won't try block mapping for it, and we'll
>> finally know that it's device, so won't try to do adjust THP (Transparent Huge Page)
>> for it.
>> 2. If userspace wrongly enables dirty logging for this memslot, we'll force_pte for it.
>>
> 
> It's not about the patch itself and just want more discussion to get more details.
> The patch itself looks good to me. I got two questions as below:
> 
> (1) The memslot fails to be added if it's backed by MMIO region and dirty logging is
> enabled in kvm_arch_prepare_memory_region(). As Santosh reported, the corresponding
> vma could be associated with MMIO region and VM_PFNMAP is missed. In this case,
> kvm_arch_prepare_memory_region() isn't returning error, meaning the memslot can be
> added successfully and block mapping isn't used, as you mentioned. The question is
> the memslot is added, but the expected result would be failure.
Sure. I think we could try to populate the final flag of vma in kvm_arch_prepare_memory_region().
Maybe through GUP or any better method? It's nice if you can try to solve this. :)

> 
> (2) If dirty logging is enabled on the MMIO memslot, everything should be fine. If
> the dirty logging isn't enabled and VM_PFNMAP isn't set yet in user_mem_abort(),
> block mapping won't be used and PAGE_SIZE is picked, but the failing IPA might
> be good candidate for block mapping. It means we miss something for blocking
> mapping?
Right. This issue also can be solved by populating the final flag of vma in kvm_arch_prepare_memory_region().


> 
> By the way, do you have idea why dirty logging can't be enabled on MMIO memslot?
IIUC, MMIO region is of device memory type, it's associated with device state and action.
For normal memory type, we can write it out-of-order and repeatedly, but for device memory
type, we can't do that. The write to MMIO will trigger device action based on current device
state, also what we can read from MMIO based on current device state. Thus the policy of
dirty logging for normal memory can't be applied to MMIO.



> I guess Marc might know the history. For example, QEMU is taking "/dev/mem" or
> "/dev/kmem" to back guest's memory, the vma is marked as MMIO, but dirty logging
> and migration isn't supported?
The MMIO region is a part of device state. We need extra kernel driver to support migration
of pass-through device, as how to save and restore the device state is closely related to
a specific type of device. You can refer VFIO migration for more detail.

Thanks,
Keqian


From wangqing at vivo.com  Fri Apr 23 03:53:23 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 10:53:23 +0800
Subject: [PATCH V7 2/2] doc: mtk-wdt: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619146403-12769-1-git-send-email-wangqing@vivo.com>
References: <1619146403-12769-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619146403-12769-3-git-send-email-wangqing@vivo.com>

Add description of pre-timeout in mtk-wdt.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index e36ba60..8e27777
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -1,5 +1,8 @@
 Mediatek SoCs Watchdog timer
 
+The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
+before the expiry.
+
 Required properties:
 
 - compatible should contain:
@@ -17,6 +20,7 @@ Required properties:
 - reg : Specifies base physical address and size of the registers.
 
 Optional properties:
+- interrupts: Watchdog pre-timeout (bark) interrupt.
 - timeout-sec: contains the watchdog timeout in seconds.
 - #reset-cells: Should be 1.
 
@@ -26,6 +30,7 @@ watchdog: watchdog at 10007000 {
 	compatible = "mediatek,mt8183-wdt",
 		     "mediatek,mt6589-wdt";
 	reg = <0 0x10007000 0 0x100>;
+	interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>;
 	timeout-sec = <10>;
 	#reset-cells = <1>;
 };
-- 
2.7.4



From wangqing at vivo.com  Fri Apr 23 03:53:21 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 10:53:21 +0800
Subject: [PATCH V7 0/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
Message-ID: <1619146403-12769-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.
The pretimeout notification shall occur at timeout-sec/2.

Wang Qing (2):
  watchdog: mtk: support pre-timeout when the bark irq is available
  doc: mtk-wdt: support pre-timeout when the bark irq is available

 .../devicetree/bindings/watchdog/mtk-wdt.txt       |  5 ++
 drivers/watchdog/mtk_wdt.c                         | 76 ++++++++++++++++++++--
 2 files changed, 76 insertions(+), 5 deletions(-)

-- 
2.7.4



From wangqing at vivo.com  Fri Apr 23 03:53:22 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 10:53:22 +0800
Subject: [PATCH V7 1/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1619146403-12769-1-git-send-email-wangqing@vivo.com>
References: <1619146403-12769-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619146403-12769-2-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The pretimeout notification shall occur at timeout-sec/2.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

V6:
- Realize pretimeout processing through dualmode.

V7:
- Add set_pretimeout().

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 71 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..ab3ac5d
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
 {
 	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	unsigned int timeout_interval = timeout;
 	u32 reg;
 
 	wdt_dev->timeout = timeout;
-
+	/*
+	 * In dual mode, irq will be triggered at timeout / 2
+	 * the real timeout occurs at timeout
+	 */
+	if (wdt_dev->pretimeout) {
+		wdt_dev->pretimeout = timeout / 2;
+		timeout_interval = wdt_dev->pretimeout;
+	}
 	/*
 	 * One bit is the value of 512 ticks
 	 * The clock has 32 KHz
 	 */
-	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
 	iowrite32(reg, wdt_base + WDT_LENGTH);
 
 	mtk_wdt_ping(wdt_dev);
@@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+					unsigned int timeout)
+{
+	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
+	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	u32 reg = ioread32(wdt_base + WDT_MODE);
+
+	if (timeout && !wdd->pretimeout) {
+		wdd->pretimeout = wdd->timeout / 2;
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else if (!timeout && wdd->pretimeout) {
+		wdd->pretimeout = 0;
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else
+		return 0;
+
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return mtk_wdt_set_timeout(wdd, wdd->timeout);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+					&mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From qiangqing.zhang at nxp.com  Fri Apr 23 04:18:32 2021
From: qiangqing.zhang at nxp.com (Joakim Zhang)
Date: Fri, 23 Apr 2021 03:18:32 +0000
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <20210419130106.6707-1-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
Message-ID: <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>


Hi Oleksij,

I look both stmmac selftest code and this patch set. For stmmac, if PHY doesn't support loopback, it will fallthrough to MAC loopback.
You provide this generic net selftest support based on PHY loopback, I have a question, is it possible to extend it also support MAC loopback later?

Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Oleksij Rempel <o.rempel at pengutronix.de>
> Sent: 2021?4?19? 21:01
> To: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian Fainelli
> <f.fainelli at gmail.com>; Heiner Kallweit <hkallweit1 at gmail.com>; Fugang
> Duan <fugang.duan at nxp.com>
> Cc: Oleksij Rempel <o.rempel at pengutronix.de>; kernel at pengutronix.de;
> netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
> Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>; Russell
> King <linux at armlinux.org.uk>; Philippe Schenker
> <philippe.schenker at toradex.com>
> Subject: [PATCH net-next v3 0/6] provide generic net selftest support
> 
> changes v3:
> - make more granular tests
> - enable loopback for all PHYs by default
> - fix allmodconfig build errors
> - poll for link status update after switching to the loopback mode
> 
> changes v2:
> - make generic selftests available for all networking devices.
> - make use of net_selftest* on FEC, ag71xx and all DSA switches.
> - add loopback support on more PHYs.
> 
> This patch set provides diagnostic capabilities for some iMX, ag71xx or any DSA
> based devices. For proper functionality, PHY loopback support is needed.
> So far there is only initial infrastructure with basic tests.
> 
> Oleksij Rempel (6):
>   net: phy: execute genphy_loopback() per default on all PHYs
>   net: phy: genphy_loopback: add link speed configuration
>   net: add generic selftest support
>   net: fec: make use of generic NET_SELFTESTS library
>   net: ag71xx: make use of generic NET_SELFTESTS library
>   net: dsa: enable selftest support for all switches by default
> 
>  drivers/net/ethernet/atheros/Kconfig      |   1 +
>  drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
>  drivers/net/ethernet/freescale/Kconfig    |   1 +
>  drivers/net/ethernet/freescale/fec_main.c |   7 +
>  drivers/net/phy/phy.c                     |   3 +-
>  drivers/net/phy/phy_device.c              |  35 +-
>  include/linux/phy.h                       |   1 +
>  include/net/dsa.h                         |   2 +
>  include/net/selftests.h                   |  12 +
>  net/Kconfig                               |   4 +
>  net/core/Makefile                         |   1 +
>  net/core/selftests.c                      | 400
> ++++++++++++++++++++++
>  net/dsa/Kconfig                           |   1 +
>  net/dsa/slave.c                           |  21 ++
>  14 files changed, 500 insertions(+), 9 deletions(-)  create mode 100644
> include/net/selftests.h  create mode 100644 net/core/selftests.c
> 
> --
> 2.29.2


From wangqing at vivo.com  Fri Apr 23 04:20:18 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 11:20:18 +0800
Subject: [PATCH V7,
 RESEND 0/2] watchdog: mtk: support pre-timeout when the bark irq is
 available
Message-ID: <1619148020-2236-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.
The pretimeout notification shall occur at timeout-sec/2.

Wang Qing (2):
  watchdog: mtk: support pre-timeout when the bark irq is available
  doc: mtk-wdt: support pre-timeout when the bark irq is available

 .../devicetree/bindings/watchdog/mtk-wdt.txt       |  5 ++
 drivers/watchdog/mtk_wdt.c                         | 76 ++++++++++++++++++++--
 2 files changed, 76 insertions(+), 5 deletions(-)

-- 
2.7.4



From wangqing at vivo.com  Fri Apr 23 04:20:19 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 11:20:19 +0800
Subject: [PATCH V7,
 RESEND 1/2] watchdog: mtk: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619148020-2236-1-git-send-email-wangqing@vivo.com>
References: <1619148020-2236-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619148020-2236-2-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The pretimeout notification shall occur at timeout-sec/2.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

V6:
- Realize pretimeout processing through dualmode.

V7:
- Add set_pretimeout().

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 71 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..ab3ac5d
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,6 +25,7 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
 #define WDT_MIN_TIMEOUT		1
@@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
 {
 	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
 	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	unsigned int timeout_interval = timeout;
 	u32 reg;
 
 	wdt_dev->timeout = timeout;
-
+	/*
+	 * In dual mode, irq will be triggered at timeout / 2
+	 * the real timeout occurs at timeout
+	 */
+	if (wdt_dev->pretimeout) {
+		wdt_dev->pretimeout = timeout / 2;
+		timeout_interval = wdt_dev->pretimeout;
+	}
 	/*
 	 * One bit is the value of 512 ticks
 	 * The clock has 32 KHz
 	 */
-	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
 	iowrite32(reg, wdt_base + WDT_LENGTH);
 
 	mtk_wdt_ping(wdt_dev);
@@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+					unsigned int timeout)
+{
+	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
+	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	u32 reg = ioread32(wdt_base + WDT_MODE);
+
+	if (timeout && !wdd->pretimeout) {
+		wdd->pretimeout = wdd->timeout / 2;
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN | WDT_MODE_KEY);
+	} else if (!timeout && wdd->pretimeout) {
+		wdd->pretimeout = 0;
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN | WDT_MODE_KEY);
+	} else
+		return 0;
+
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return mtk_wdt_set_timeout(wdd, wdd->timeout);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+					&mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From wangqing at vivo.com  Fri Apr 23 04:20:20 2021
From: wangqing at vivo.com (Wang Qing)
Date: Fri, 23 Apr 2021 11:20:20 +0800
Subject: [PATCH V7,
 RESEND 2/2] doc: mtk-wdt: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619148020-2236-1-git-send-email-wangqing@vivo.com>
References: <1619148020-2236-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619148020-2236-3-git-send-email-wangqing@vivo.com>

Add description of pre-timeout in mtk-wdt.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index e36ba60..8e27777
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -1,5 +1,8 @@
 Mediatek SoCs Watchdog timer
 
+The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
+before the expiry.
+
 Required properties:
 
 - compatible should contain:
@@ -17,6 +20,7 @@ Required properties:
 - reg : Specifies base physical address and size of the registers.
 
 Optional properties:
+- interrupts: Watchdog pre-timeout (bark) interrupt.
 - timeout-sec: contains the watchdog timeout in seconds.
 - #reset-cells: Should be 1.
 
@@ -26,6 +30,7 @@ watchdog: watchdog at 10007000 {
 	compatible = "mediatek,mt8183-wdt",
 		     "mediatek,mt6589-wdt";
 	reg = <0 0x10007000 0 0x100>;
+	interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>;
 	timeout-sec = <10>;
 	#reset-cells = <1>;
 };
-- 
2.7.4



From sfr at canb.auug.org.au  Fri Apr 23 04:22:28 2021
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 23 Apr 2021 13:22:28 +1000
Subject: linux-next: manual merge of the irqchip tree with the arm-soc tree
Message-ID: <20210423132228.643253a5@canb.auug.org.au>

Hi all,

Today's linux-next merge of the irqchip tree got conflicts in:

  drivers/irqchip/Kconfig
  drivers/irqchip/Makefile

between commit:

  76cde2639411 ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")

from the arm-soc tree and commit:

  529ea3681811 ("irqchip: Add support for IDT 79rc3243x interrupt controller")

from the irqchip 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 drivers/irqchip/Kconfig
index d3a14f304ec8,18b0d0b33b8b..000000000000
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@@ -577,12 -577,15 +577,23 @@@ config MST_IR
  	help
  	  Support MStar Interrupt Controller.
  
 +config APPLE_AIC
 +	bool "Apple Interrupt Controller (AIC)"
 +	depends on ARM64
 +	default ARCH_APPLE
 +	help
 +	  Support for the Apple Interrupt Controller found on Apple Silicon SoCs,
 +	  such as the M1.
 +
+ config WPCM450_AIC
+ 	bool "Nuvoton WPCM450 Advanced Interrupt Controller"
+ 	depends on ARCH_WPCM450
+ 	help
+ 	  Support for the interrupt controller in the Nuvoton WPCM450 BMC SoC.
+ 
+ config IRQ_IDT3243X
+ 	bool
+ 	select GENERIC_IRQ_CHIP
+ 	select IRQ_DOMAIN
+ 
  endmenu
diff --cc drivers/irqchip/Makefile
index eb6a515f0f64,18573602a939..000000000000
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -113,4 -113,5 +113,6 @@@ obj-$(CONFIG_LOONGSON_PCH_MSI)		+= irq-
  obj-$(CONFIG_MST_IRQ)			+= irq-mst-intc.o
  obj-$(CONFIG_SL28CPLD_INTC)		+= irq-sl28cpld.o
  obj-$(CONFIG_MACH_REALTEK_RTL)		+= irq-realtek-rtl.o
 +obj-$(CONFIG_APPLE_AIC)			+= irq-apple-aic.o
+ obj-$(CONFIG_WPCM450_AIC)		+= irq-wpcm450-aic.o
+ obj-$(CONFIG_IRQ_IDT3243X)		+= irq-idt3243x.o
-------------- 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/20210423/e3c88bda/attachment.sig>

From linux at roeck-us.net  Fri Apr 23 04:28:58 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 22 Apr 2021 20:28:58 -0700
Subject: [PATCH V7 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <1619146403-12769-2-git-send-email-wangqing@vivo.com>
References: <1619146403-12769-1-git-send-email-wangqing@vivo.com>
 <1619146403-12769-2-git-send-email-wangqing@vivo.com>
Message-ID: <0de7e5c8-57a2-9b27-d8a8-ed7e0b394b02@roeck-us.net>

On 4/22/21 7:53 PM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> When the watchdog timer expires in dual mode, an interrupt will be
> triggered first, then the timing restarts. The reset signal will be
> initiated when the timer expires again.
> 
> The pretimeout notification shall occur at timeout-sec/2.
> 
> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> 
> V3:
> - Modify the pretimeout behavior, manually reset after the pretimeout
> - is processed and wait until timeout.
> 
> V4:
> - Remove pretimeout related processing. 
> - Add dual mode control separately.
> 
> V5:
> - Fix some formatting and printing problems.
> 
> V6:
> - Realize pretimeout processing through dualmode.
> 
> V7:
> - Add set_pretimeout().
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 71 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..ab3ac5d
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,6 +25,7 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
>  #define WDT_MIN_TIMEOUT		1
> @@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>  {
>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
> +	unsigned int timeout_interval = timeout;
>  	u32 reg;
>  
>  	wdt_dev->timeout = timeout;
> -
> +	/*
> +	 * In dual mode, irq will be triggered at timeout / 2
> +	 * the real timeout occurs at timeout
> +	 */
> +	if (wdt_dev->pretimeout) {
> +		wdt_dev->pretimeout = timeout / 2;

min_timeout is set to 1. I don't this works well if timeout == 1.
You'll either need to set min_timeout to 2, or handle that case.

> +		timeout_interval = wdt_dev->pretimeout;

timeout_interval is unnecessary. Just update timeout accordingly.
It needs to take the situation of timeout == 1 into account, though.

> +	}
>  	/*
>  	 * One bit is the value of 512 ticks
>  	 * The clock has 32 KHz
>  	 */
> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>  
>  	mtk_wdt_ping(wdt_dev);
> @@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	if (wdt_dev->pretimeout)
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	else
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> +					unsigned int timeout)
> +{
> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
> +	u32 reg = ioread32(wdt_base + WDT_MODE);
> +
> +	if (timeout && !wdd->pretimeout) {
> +		wdd->pretimeout = wdd->timeout / 2;
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	} else if (!timeout && wdd->pretimeout) {
> +		wdd->pretimeout = 0;
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	} else
> +		return 0;
> +
> +	iowrite32(reg, wdt_base + WDT_MODE);

What is the point of setting the mode here ? It will
be set again in mtk_wdt_set_timeout(). Seems to me all
you need to do here is to set wdd->pretimeout,
then call mtk_wdt_set_timeout().

Guenter

> +
> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
> +}
> +
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +
> +	watchdog_notify_pretimeout(wdd);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
>  	.stop		= mtk_wdt_stop,
>  	.ping		= mtk_wdt_ping,
>  	.set_timeout	= mtk_wdt_set_timeout,
> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>  	.restart	= mtk_wdt_restart,
>  };
>  
> @@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +					&mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> 



From heying24 at huawei.com  Fri Apr 23 04:29:44 2021
From: heying24 at huawei.com (He Ying)
Date: Fri, 23 Apr 2021 11:29:44 +0800
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <875z0eijxh.wl-maz@kernel.org>
References: <20210416062217.25157-1-heying24@huawei.com>
 <87y2dis4d7.wl-maz@kernel.org>
 <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
 <875z0eijxh.wl-maz@kernel.org>
Message-ID: <47abc8a6-0f73-d1c0-789f-e979d4191ab2@huawei.com>


? 2021/4/22 20:27, Marc Zyngier ??:
> On Sat, 17 Apr 2021 03:01:54 +0100,
> He Ying <heying24 at huawei.com> wrote:
>> Hello Marc,
>>
>>
>> ? 2021/4/16 22:15, Marc Zyngier ??:
>>> [+ Mark]
>>>
>>> On Fri, 16 Apr 2021 07:22:17 +0100,
>>> He Ying <heying24 at huawei.com> wrote:
>>>> We found this problem in our kernel src tree:
>>>>
>>>> [   14.816231] ------------[ cut here ]------------
>>>> [   14.816231] kernel BUG at irq.c:99!
>>>> [   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
>>>> [   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
>>>> [   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95-1.h1.AOS2.0.aarch64 #14
>>>> [   14.816233] Hardware name: evb (DT)
>>>> [   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
>>>> [   14.816234] pc : asm_nmi_enter+0x94/0x98
>>>> [   14.816235] lr : asm_nmi_enter+0x18/0x98
>>>> [   14.816235] sp : ffff000008003c50
>>>> [   14.816235] pmr_save: 00000070
>>>> [   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
>>>> [   14.816238] x27: 0000000000000000 x26: ffff000008004000
>>>> [   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
>>>> [   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
>>>> [   14.816241] x21: ffff000008003da0 x20: 0000000000000060
>>>> [   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
>>>> [   14.816243] x17: 0000000000000008 x16: 003d090000000000
>>>> [   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
>>>> [   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
>>>> [   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
>>>> [   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
>>>> [   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
>>>> [   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
>>>> [   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
>>>> [   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
>>>> [   14.816251] Call trace:
>>>> [   14.816251]  asm_nmi_enter+0x94/0x98
>>>> [   14.816251]  el1_irq+0x8c/0x180
>>>> [   14.816252]  gic_handle_irq+0xbc/0x2e4
>>>> [   14.816252]  el1_irq+0xcc/0x180
>>>> [   14.816253]  arch_timer_handler_virt+0x38/0x58
>>>> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
>>>> [   14.816253]  generic_handle_irq+0x34/0x50
>>>> [   14.816254]  __handle_domain_irq+0x68/0xc0
>>>> [   14.816254]  gic_handle_irq+0xf8/0x2e4
>>>> [   14.816255]  el1_irq+0xcc/0x180
>>>> [   14.816255]  arch_cpu_idle+0x34/0x1c8
>>>> [   14.816255]  default_idle_call+0x24/0x44
>>>> [   14.816256]  do_idle+0x1d0/0x2c8
>>>> [   14.816256]  cpu_startup_entry+0x28/0x30
>>>> [   14.816256]  rest_init+0xb8/0xc8
>>>> [   14.816257]  start_kernel+0x4c8/0x4f4
>>>> [   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
>>>> [   14.816258] Modules linked in: start_dp(O) smeth(O)
>>>> [   15.103092] ---[ end trace 701753956cb14aa8 ]---
>>>> [   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
>>>> [   15.103099] SMP: stopping secondary CPUs
>>>> [   15.103100] Kernel Offset: disabled
>>>> [   15.103100] CPU features: 0x36,a2400218
>>>> [   15.103100] Memory Limit: none
>>> Urgh...
>>>
>>>> Our kernel src tree is based on 4.19.95 and backports arm64 pseudo-NMI
>>>> patches but doesn't support nested NMI. Its top relative commit is
>>>> commit 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs").
>>> Can you please reproduce it with mainline and without any backport?
>>> It is hard to reason about something that isn't a vanilla kernel.
>> I think our kernel is quite like v5.3 mainline. Reproducing it in
>> v5.3 mainline may be a little difficult for us because our product
>> needs some more self developed patches to work.
> I don't really care about 5.3. What I care about is the tip of the
> tree, and anything we fix there can trickle down to the previous
> stable releases.

I don't know if I give the tip of tree. I provide the Fixes tag

"Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of 
NMIs")".

Is that sufficient to help?

>
>>>> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
>>>> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
>>>> means an interrupt preempts the other one and the new one is an NMI.
>>>> Furthermore, by adding some prints, we find the first irq also calls
>>>> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
>>>> is 1023. It enables irq by calling gic_arch_enable_irqs() in
>>>> gic_handle_irq(). At this moment, the second irq preempts the first irq
>>>> and it's an NMI but current context is already in nmi. So that may be
>>>> the problem.
>>> I'm not sure I get it. From the stack trace, I see this:
>>>
>>> [   14.816251]  asm_nmi_enter+0x94/0x98
>>> [   14.816251]  el1_irq+0x8c/0x180			(C)
>>> [   14.816252]  gic_handle_irq+0xbc/0x2e4
>>> [   14.816252]  el1_irq+0xcc/0x180			(B)
>>> [   14.816253]  arch_timer_handler_virt+0x38/0x58
>>> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
>>> [   14.816253]  generic_handle_irq+0x34/0x50
>>> [   14.816254]  __handle_domain_irq+0x68/0xc0
>>> [   14.816254]  gic_handle_irq+0xf8/0x2e4
>>> [   14.816255]  el1_irq+0xcc/0x180			(A)
>>>
>>> which indicates that we preempted a timer interrupt (A) with another
>>> IRQ (B), itself immediately preempted by another IRQ (C)? That's
>>> indeed at least one too many.
>>>
>>> Can you please describe for each of (A), (B) and (C) whether they are
>>> spurious or not, what their priorities are if they aren't spurious?
>> Yes. I ignored interrupt (A). (B) is spurious and its priority is
>> 0xa0 and PMR is 0x70. (C) is an NMI and its priority is 0x20. Note
>> that GIC_PRIO_IRQON is 0xe0, GIC_PRIO_IRQOFF is 0x60,
>> GICD_INT_DEF_PRI is 0xa0 and GICD_INT_NMI_PRI is 0x20 in our kernel.
> If (B) is spurious (aka ICC_IAR1R_EL1 return 1023), then its
> "priority" doesn't really exist, and I don't really get what you mean
> by "its priority is 0xa0".  ICC_RPR_EL1 shouldn't change when Ack-ing
> a spurious interrupt, because there is no change in GIC state at all.
OK. By saying "its priority is 0xa0", I just mean ICC_RPR_EL1 is read as 
0xa0.
>
> And if PMR is 0x70 at the point where you get (B), then I really can't
> see how you can get an interrupt of priority 0xa0 anyway.

Yes, it also confuses me. Perhaps ICC_RPR_EL1 changes when read, I think.

>
>
>
>>>> In my opinion, when handling spurious interrupts, we shouldn't enable irqs.
>>>> My reason is that for spurious interrupts we may enter nmi context in
>>>> el1_irq() because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs
>>>> at this time, another NMI may happen and preempt this spurious interrupt
>>>> but the context is already in nmi. That causes a bug on if nested NMI is
>>>> not supported. Even for nested nmi, I think it's not a normal scenario.
>>> I would tend to agree that this isn't great. Actually, I'd probably
>>> move the check for a spurious interrupt right after the read of
>>> ICC_IAR1_EL1, because there is no real need to do anything else at
>>> that point.
>> So, we don't need to check NMI for spurious interrupts? Do you mean
>> that spurious interrupts' can't be NMIs? Or even spurious interrups
>> are NMIs, we shouldn't do anything for them? If so, I will move the
>> check after the read of ICC_IAR1_EL1 and send a V2.
> Spurious interrupts are not interrupts at all. It is either a level
> interrupt that has been retired before being handled, or some other
> transient effect (like an interrupt being moved from one CPU to
> another), or even flaky HW. So doing anything based on a spurious
> interrupt is definitely a potential bug, and I suggest this:
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index eb0ee356a629..00404024d7cd 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -648,6 +648,10 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>   
>   	irqnr = gic_read_iar();
>   
> +	/* Check for special IDs first */
> +	if ((irqnr >= 1020 && irqnr <= 1023))
> +		return;
> +
>   	if (gic_supports_nmi() &&
>   	    unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
>   		gic_handle_nmi(irqnr, regs);
> @@ -659,10 +663,6 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>   		gic_arch_enable_irqs();
>   	}
>   
> -	/* Check for special IDs first */
> -	if ((irqnr >= 1020 && irqnr <= 1023))
> -		return;
> -
>   	if (static_branch_likely(&supports_deactivate_key))
>   		gic_write_eoir(irqnr);
>   	else
>
> [...]
Thanks for explaining it. I quite agree with your suggestion.
>> In my opinion, since commit 17ce302f3117 ("arm64: Fix interrupt
>> tracing in the presence of NMIs"), spurious interrups can enter nmi
>> context in interrupt entry because PMR can be GIC_PRIO_IRQOFF for
>> spurious interrupts. That means test_irqs_unmasked is not 0 and
>> asm_nmi_enter is called.
>>
>>  ?? (some el1_irq entry code from v5.3)
>>  ?? test_irqs_unmasked? res=x0, pmr=x20
>>  ?? cbz x0, 1f
>>  ?? bl asm_nmi_enter
> That code has significantly changed upstream, and is now in C. I think
> it still do the same thing though.
Yes, you're right.
>
>> And it then calls gic_handle_irq(). It doesn't call gic_handle_nmi()
>> because its priority is not GICD_INT_NMI_PRI.
>>
>> Then it enables irqs. If at that point another NMI comes and
>> preempts it, which means NMI occurs in nmi context. That may cause a
>> bug on if nested NMI is not supported.
>>
>>  ?? (some gic_handle_irq code from v5.3)
>>
>>  ?? irqnr = gic_read_iar();
>>
>>  ?? if (gic_supports_nmi() &&
>>  ? ? ?? unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
>>  ?????????? gic_handle_nmi(irqnr,
>> regs);?????????????????????????????????? (C)
>>  ?????????? return;
>>  ?? }
>>
>>  ?? if (gic_prio_masking_enabled()) {
>>  ???????? gic_pmr_mask_irqs();
>> gic_arch_enable_irqs(); (D)
>>  ?? }
> I believe the above patch would fix the spurious interrupt issue you
> have experienced. Please let me know, and post a v2 if this works for
> you.

Fortunately, it works. I'll post a v2. Should I cc stable mail list?


Thanks.



From aisheng.dong at nxp.com  Fri Apr 23 04:33:29 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:29 +0800
Subject: [PATCH 1/6] dt-bindings: arm: imx: scu: fix naming typo of clk
 compatible string
Message-ID: <20210423033334.3317992-1-aisheng.dong@nxp.com>

There is a typo in binding doc that the name of compatible string of
scu clock should be "fsl,xxx-clk" rather than "fsl,xxx-clock".
In reality, both example and dts using "fsl,xxx-clk", so fixing the doc
is enough.

Cc: devicetree at vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 395359dc94fd..3adf3f6f2beb 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -86,8 +86,8 @@ This binding uses the common clock binding[1].
 
 Required properties:
 - compatible:		Should be one of:
-			  "fsl,imx8qm-clock"
-			  "fsl,imx8qxp-clock"
+			  "fsl,imx8qm-clk"
+			  "fsl,imx8qxp-clk"
 			followed by "fsl,scu-clk"
 - #clock-cells:		Should be either
 			2: Contains the Resource and Clock ID value.
-- 
2.25.1



From aisheng.dong at nxp.com  Fri Apr 23 04:33:30 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:30 +0800
Subject: [PATCH 2/6] dt-bindings: arm: imx: scu: drop deprecated legacy clock
 binding
In-Reply-To: <20210423033334.3317992-1-aisheng.dong@nxp.com>
References: <20210423033334.3317992-1-aisheng.dong@nxp.com>
Message-ID: <20210423033334.3317992-2-aisheng.dong@nxp.com>

The legacy clock binding are not maintained anymore. It has only
a very preliminary supported clocks during initial upstream and
meaningless for users. So drop it from binding doc now.

Cc: devicetree at vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 3adf3f6f2beb..fd0061712443 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -89,10 +89,8 @@ Required properties:
 			  "fsl,imx8qm-clk"
 			  "fsl,imx8qxp-clk"
 			followed by "fsl,scu-clk"
-- #clock-cells:		Should be either
-			2: Contains the Resource and Clock ID value.
-			or
-			1: Contains the Clock ID value. (DEPRECATED)
+- #clock-cells:		Should be 2.
+			Contains the Resource and Clock ID value.
 - clocks:		List of clock specifiers, must contain an entry for
 			each required entry in clock-names
 - clock-names:		Should include entries "xtal_32KHz", "xtal_24MHz"
-- 
2.25.1



From aisheng.dong at nxp.com  Fri Apr 23 04:33:31 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:31 +0800
Subject: [PATCH 3/6] clk: imx: scu: remove legacy scu clock binding support
In-Reply-To: <20210423033334.3317992-1-aisheng.dong@nxp.com>
References: <20210423033334.3317992-1-aisheng.dong@nxp.com>
Message-ID: <20210423033334.3317992-3-aisheng.dong@nxp.com>

Legacy scu clock binding are not maintained anymore, it has a very
limited clocks supported during initial upstreaming and obviously
unusable by products. So it's meaningless to keep it in
kernel which worse the code readability.
Remove it to keep code much cleaner.

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/clk/imx/clk-imx8qxp.c          | 201 ++++++++++---------------
 drivers/clk/imx/clk-scu.h              |  15 +-
 include/dt-bindings/clock/imx8-clock.h | 128 ----------------
 3 files changed, 81 insertions(+), 263 deletions(-)

diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index fbf1170c09ed..d17b418ac577 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -14,7 +14,6 @@
 
 #include "clk-scu.h"
 
-#include <dt-bindings/clock/imx8-clock.h>
 #include <dt-bindings/firmware/imx/rsrc.h>
 
 static const char *dc0_sels[] = {
@@ -28,149 +27,103 @@ static const char *dc0_sels[] = {
 static int imx8qxp_clk_probe(struct platform_device *pdev)
 {
 	struct device_node *ccm_node = pdev->dev.of_node;
-	struct clk_hw_onecell_data *clk_data;
-	struct clk_hw **clks;
-	u32 clk_cells;
-	int ret, i;
+	int ret;
 
 	ret = imx_clk_scu_init(ccm_node);
 	if (ret)
 		return ret;
 
-	clk_data = devm_kzalloc(&pdev->dev, struct_size(clk_data, hws,
-				IMX_SCU_CLK_END), GFP_KERNEL);
-	if (!clk_data)
-		return -ENOMEM;
-
-	if (of_property_read_u32(ccm_node, "#clock-cells", &clk_cells))
-		return -EINVAL;
-
-	clk_data->num = IMX_SCU_CLK_END;
-	clks = clk_data->hws;
-
-	/* Fixed clocks */
-	clks[IMX_CLK_DUMMY]		= clk_hw_register_fixed_rate(NULL, "dummy", NULL, 0, 0);
-	clks[IMX_ADMA_IPG_CLK_ROOT] 	= clk_hw_register_fixed_rate(NULL, "dma_ipg_clk_root", NULL, 0, 120000000);
-	clks[IMX_CONN_AXI_CLK_ROOT]	= clk_hw_register_fixed_rate(NULL, "conn_axi_clk_root", NULL, 0, 333333333);
-	clks[IMX_CONN_AHB_CLK_ROOT]	= clk_hw_register_fixed_rate(NULL, "conn_ahb_clk_root", NULL, 0, 166666666);
-	clks[IMX_CONN_IPG_CLK_ROOT]	= clk_hw_register_fixed_rate(NULL, "conn_ipg_clk_root", NULL, 0, 83333333);
-	clks[IMX_DC_AXI_EXT_CLK]	= clk_hw_register_fixed_rate(NULL, "dc_axi_ext_clk_root", NULL, 0, 800000000);
-	clks[IMX_DC_AXI_INT_CLK]	= clk_hw_register_fixed_rate(NULL, "dc_axi_int_clk_root", NULL, 0, 400000000);
-	clks[IMX_DC_CFG_CLK]		= clk_hw_register_fixed_rate(NULL, "dc_cfg_clk_root", NULL, 0, 100000000);
-	clks[IMX_MIPI_IPG_CLK]		= clk_hw_register_fixed_rate(NULL, "mipi_ipg_clk_root", NULL, 0, 120000000);
-	clks[IMX_IMG_AXI_CLK]		= clk_hw_register_fixed_rate(NULL, "img_axi_clk_root", NULL, 0, 400000000);
-	clks[IMX_IMG_IPG_CLK]		= clk_hw_register_fixed_rate(NULL, "img_ipg_clk_root", NULL, 0, 200000000);
-	clks[IMX_IMG_PXL_CLK]		= clk_hw_register_fixed_rate(NULL, "img_pxl_clk_root", NULL, 0, 600000000);
-	clks[IMX_HSIO_AXI_CLK]		= clk_hw_register_fixed_rate(NULL, "hsio_axi_clk_root", NULL, 0, 400000000);
-	clks[IMX_HSIO_PER_CLK]		= clk_hw_register_fixed_rate(NULL, "hsio_per_clk_root", NULL, 0, 133333333);
-	clks[IMX_LSIO_MEM_CLK]		= clk_hw_register_fixed_rate(NULL, "lsio_mem_clk_root", NULL, 0, 200000000);
-	clks[IMX_LSIO_BUS_CLK]		= clk_hw_register_fixed_rate(NULL, "lsio_bus_clk_root", NULL, 0, 100000000);
-
 	/* ARM core */
-	clks[IMX_A35_CLK]		= imx_clk_scu("a35_clk", IMX_SC_R_A35, IMX_SC_PM_CLK_CPU, clk_cells);
+	imx_clk_scu("a35_clk", IMX_SC_R_A35, IMX_SC_PM_CLK_CPU);
 
 	/* LSIO SS */
-	clks[IMX_LSIO_PWM0_CLK]		= imx_clk_scu("pwm0_clk", IMX_SC_R_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM1_CLK]		= imx_clk_scu("pwm1_clk", IMX_SC_R_PWM_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM2_CLK]		= imx_clk_scu("pwm2_clk", IMX_SC_R_PWM_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM3_CLK]		= imx_clk_scu("pwm3_clk", IMX_SC_R_PWM_3, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM4_CLK]		= imx_clk_scu("pwm4_clk", IMX_SC_R_PWM_4, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM5_CLK]		= imx_clk_scu("pwm5_clk", IMX_SC_R_PWM_5, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM6_CLK]		= imx_clk_scu("pwm6_clk", IMX_SC_R_PWM_6, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_PWM7_CLK]		= imx_clk_scu("pwm7_clk", IMX_SC_R_PWM_7, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_GPT0_CLK]		= imx_clk_scu("gpt0_clk", IMX_SC_R_GPT_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_GPT1_CLK]		= imx_clk_scu("gpt1_clk", IMX_SC_R_GPT_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_GPT2_CLK]		= imx_clk_scu("gpt2_clk", IMX_SC_R_GPT_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_GPT3_CLK]		= imx_clk_scu("gpt3_clk", IMX_SC_R_GPT_3, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_GPT4_CLK]		= imx_clk_scu("gpt4_clk", IMX_SC_R_GPT_4, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_FSPI0_CLK]	= imx_clk_scu("fspi0_clk", IMX_SC_R_FSPI_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_LSIO_FSPI1_CLK]	= imx_clk_scu("fspi1_clk", IMX_SC_R_FSPI_1, IMX_SC_PM_CLK_PER, clk_cells);
+	imx_clk_scu("pwm0_clk", IMX_SC_R_PWM_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm1_clk", IMX_SC_R_PWM_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm2_clk", IMX_SC_R_PWM_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm3_clk", IMX_SC_R_PWM_3, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm4_clk", IMX_SC_R_PWM_4, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm5_clk", IMX_SC_R_PWM_5, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm6_clk", IMX_SC_R_PWM_6, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm7_clk", IMX_SC_R_PWM_7, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpt0_clk", IMX_SC_R_GPT_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpt1_clk", IMX_SC_R_GPT_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpt2_clk", IMX_SC_R_GPT_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpt3_clk", IMX_SC_R_GPT_3, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpt4_clk", IMX_SC_R_GPT_4, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("fspi0_clk", IMX_SC_R_FSPI_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("fspi1_clk", IMX_SC_R_FSPI_1, IMX_SC_PM_CLK_PER);
 
 	/* ADMA SS */
-	clks[IMX_ADMA_UART0_CLK]	= imx_clk_scu("uart0_clk", IMX_SC_R_UART_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_UART1_CLK]	= imx_clk_scu("uart1_clk", IMX_SC_R_UART_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_UART2_CLK]	= imx_clk_scu("uart2_clk", IMX_SC_R_UART_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_UART3_CLK]	= imx_clk_scu("uart3_clk", IMX_SC_R_UART_3, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_SPI0_CLK]		= imx_clk_scu("spi0_clk",  IMX_SC_R_SPI_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_SPI1_CLK]		= imx_clk_scu("spi1_clk",  IMX_SC_R_SPI_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_SPI2_CLK]		= imx_clk_scu("spi2_clk",  IMX_SC_R_SPI_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_SPI3_CLK]		= imx_clk_scu("spi3_clk",  IMX_SC_R_SPI_3, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_CAN0_CLK]		= imx_clk_scu("can0_clk",  IMX_SC_R_CAN_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_I2C0_CLK]		= imx_clk_scu("i2c0_clk",  IMX_SC_R_I2C_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_I2C1_CLK]		= imx_clk_scu("i2c1_clk",  IMX_SC_R_I2C_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_I2C2_CLK]		= imx_clk_scu("i2c2_clk",  IMX_SC_R_I2C_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_I2C3_CLK]		= imx_clk_scu("i2c3_clk",  IMX_SC_R_I2C_3, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_FTM0_CLK]		= imx_clk_scu("ftm0_clk",  IMX_SC_R_FTM_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_FTM1_CLK]		= imx_clk_scu("ftm1_clk",  IMX_SC_R_FTM_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_ADC0_CLK]		= imx_clk_scu("adc0_clk",  IMX_SC_R_ADC_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_PWM_CLK]		= imx_clk_scu("pwm_clk",   IMX_SC_R_LCD_0_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_ADMA_LCD_CLK]		= imx_clk_scu("lcd_clk",   IMX_SC_R_LCD_0, IMX_SC_PM_CLK_PER, clk_cells);
+	imx_clk_scu("uart0_clk", IMX_SC_R_UART_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("uart1_clk", IMX_SC_R_UART_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("uart2_clk", IMX_SC_R_UART_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("uart3_clk", IMX_SC_R_UART_3, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("spi0_clk",  IMX_SC_R_SPI_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("spi1_clk",  IMX_SC_R_SPI_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("spi2_clk",  IMX_SC_R_SPI_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("spi3_clk",  IMX_SC_R_SPI_3, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("can0_clk",  IMX_SC_R_CAN_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("i2c0_clk",  IMX_SC_R_I2C_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("i2c1_clk",  IMX_SC_R_I2C_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("i2c2_clk",  IMX_SC_R_I2C_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("i2c3_clk",  IMX_SC_R_I2C_3, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("ftm0_clk",  IMX_SC_R_FTM_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("ftm1_clk",  IMX_SC_R_FTM_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("adc0_clk",  IMX_SC_R_ADC_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("pwm_clk",   IMX_SC_R_LCD_0_PWM_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("lcd_clk",   IMX_SC_R_LCD_0, IMX_SC_PM_CLK_PER);
 
 	/* Connectivity */
-	clks[IMX_CONN_SDHC0_CLK]	= imx_clk_scu("sdhc0_clk", IMX_SC_R_SDHC_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_SDHC1_CLK]	= imx_clk_scu("sdhc1_clk", IMX_SC_R_SDHC_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_SDHC2_CLK]	= imx_clk_scu("sdhc2_clk", IMX_SC_R_SDHC_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_ENET0_ROOT_CLK]	= imx_clk_scu("enet0_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_ENET0_BYPASS_CLK]	= imx_clk_scu("enet0_bypass_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_BYPASS, clk_cells);
-	clks[IMX_CONN_ENET0_RGMII_CLK]	= imx_clk_scu("enet0_rgmii_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_MISC0, clk_cells);
-	clks[IMX_CONN_ENET1_ROOT_CLK]	= imx_clk_scu("enet1_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_ENET1_BYPASS_CLK]	= imx_clk_scu("enet1_bypass_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_BYPASS, clk_cells);
-	clks[IMX_CONN_ENET1_RGMII_CLK]	= imx_clk_scu("enet1_rgmii_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_MISC0, clk_cells);
-	clks[IMX_CONN_GPMI_BCH_IO_CLK]	= imx_clk_scu("gpmi_io_clk", IMX_SC_R_NAND, IMX_SC_PM_CLK_MST_BUS, clk_cells);
-	clks[IMX_CONN_GPMI_BCH_CLK]	= imx_clk_scu("gpmi_bch_clk", IMX_SC_R_NAND, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_USB2_ACLK]	= imx_clk_scu("usb3_aclk_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CONN_USB2_BUS_CLK]	= imx_clk_scu("usb3_bus_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_MST_BUS, clk_cells);
-	clks[IMX_CONN_USB2_LPM_CLK]	= imx_clk_scu("usb3_lpm_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_MISC, clk_cells);
+	imx_clk_scu("sdhc0_clk", IMX_SC_R_SDHC_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("sdhc1_clk", IMX_SC_R_SDHC_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("sdhc2_clk", IMX_SC_R_SDHC_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("enet0_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("enet0_bypass_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_BYPASS);
+	imx_clk_scu("enet0_rgmii_clk", IMX_SC_R_ENET_0, IMX_SC_PM_CLK_MISC0);
+	imx_clk_scu("enet1_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("enet1_bypass_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_BYPASS);
+	imx_clk_scu("enet1_rgmii_clk", IMX_SC_R_ENET_1, IMX_SC_PM_CLK_MISC0);
+	imx_clk_scu("gpmi_io_clk", IMX_SC_R_NAND, IMX_SC_PM_CLK_MST_BUS);
+	imx_clk_scu("gpmi_bch_clk", IMX_SC_R_NAND, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("usb3_aclk_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("usb3_bus_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_MST_BUS);
+	imx_clk_scu("usb3_lpm_div", IMX_SC_R_USB_2, IMX_SC_PM_CLK_MISC);
 
 	/* Display controller SS */
-	clks[IMX_DC0_DISP0_CLK]		= imx_clk_scu2("dc0_disp0_clk", dc0_sels, ARRAY_SIZE(dc0_sels), IMX_SC_R_DC_0, IMX_SC_PM_CLK_MISC0, clk_cells);
-	clks[IMX_DC0_DISP1_CLK]		= imx_clk_scu2("dc0_disp1_clk", dc0_sels, ARRAY_SIZE(dc0_sels), IMX_SC_R_DC_0, IMX_SC_PM_CLK_MISC1, clk_cells);
-	clks[IMX_DC0_PLL0_CLK]		= imx_clk_scu("dc0_pll0_clk", IMX_SC_R_DC_0_PLL_0, IMX_SC_PM_CLK_PLL, clk_cells);
-	clks[IMX_DC0_PLL1_CLK]		= imx_clk_scu("dc0_pll1_clk", IMX_SC_R_DC_0_PLL_1, IMX_SC_PM_CLK_PLL, clk_cells);
-	clks[IMX_DC0_BYPASS0_CLK]	= imx_clk_scu("dc0_bypass0_clk", IMX_SC_R_DC_0_VIDEO0, IMX_SC_PM_CLK_BYPASS, clk_cells);
-	clks[IMX_DC0_BYPASS1_CLK]	= imx_clk_scu("dc0_bypass1_clk", IMX_SC_R_DC_0_VIDEO1, IMX_SC_PM_CLK_BYPASS, clk_cells);
+	imx_clk_scu2("dc0_disp0_clk", dc0_sels, ARRAY_SIZE(dc0_sels), IMX_SC_R_DC_0, IMX_SC_PM_CLK_MISC0);
+	imx_clk_scu2("dc0_disp1_clk", dc0_sels, ARRAY_SIZE(dc0_sels), IMX_SC_R_DC_0, IMX_SC_PM_CLK_MISC1);
+	imx_clk_scu("dc0_pll0_clk", IMX_SC_R_DC_0_PLL_0, IMX_SC_PM_CLK_PLL);
+	imx_clk_scu("dc0_pll1_clk", IMX_SC_R_DC_0_PLL_1, IMX_SC_PM_CLK_PLL);
+	imx_clk_scu("dc0_bypass0_clk", IMX_SC_R_DC_0_VIDEO0, IMX_SC_PM_CLK_BYPASS);
+	imx_clk_scu("dc0_bypass1_clk", IMX_SC_R_DC_0_VIDEO1, IMX_SC_PM_CLK_BYPASS);
 
 	/* MIPI-LVDS SS */
-	clks[IMX_MIPI0_LVDS_PIXEL_CLK]	= imx_clk_scu("mipi0_lvds_pixel_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI0_LVDS_BYPASS_CLK]	= imx_clk_scu("mipi0_lvds_bypass_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_BYPASS, clk_cells);
-	clks[IMX_MIPI0_LVDS_PHY_CLK]	= imx_clk_scu("mipi0_lvds_phy_clk", IMX_SC_R_LVDS_0, IMX_SC_PM_CLK_MISC3, clk_cells);
-	clks[IMX_MIPI0_I2C0_CLK]	= imx_clk_scu("mipi0_i2c0_clk", IMX_SC_R_MIPI_0_I2C_0, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI0_I2C1_CLK]	= imx_clk_scu("mipi0_i2c1_clk", IMX_SC_R_MIPI_0_I2C_1, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI0_PWM0_CLK]	= imx_clk_scu("mipi0_pwm0_clk", IMX_SC_R_MIPI_0_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_MIPI1_LVDS_PIXEL_CLK]	= imx_clk_scu("mipi1_lvds_pixel_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI1_LVDS_BYPASS_CLK]	= imx_clk_scu("mipi1_lvds_bypass_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_BYPASS, clk_cells);
-	clks[IMX_MIPI1_LVDS_PHY_CLK]	= imx_clk_scu("mipi1_lvds_phy_clk", IMX_SC_R_LVDS_1, IMX_SC_PM_CLK_MISC3, clk_cells);
-	clks[IMX_MIPI1_I2C0_CLK]	= imx_clk_scu("mipi1_i2c0_clk", IMX_SC_R_MIPI_1_I2C_0, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI1_I2C1_CLK]	= imx_clk_scu("mipi1_i2c1_clk", IMX_SC_R_MIPI_1_I2C_1, IMX_SC_PM_CLK_MISC2, clk_cells);
-	clks[IMX_MIPI1_PWM0_CLK]	= imx_clk_scu("mipi1_pwm0_clk", IMX_SC_R_MIPI_1_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
+	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_scu("mipi0_i2c0_clk", IMX_SC_R_MIPI_0_I2C_0, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu("mipi0_i2c1_clk", IMX_SC_R_MIPI_0_I2C_1, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu("mipi0_pwm0_clk", IMX_SC_R_MIPI_0_PWM_0, 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_scu("mipi1_i2c0_clk", IMX_SC_R_MIPI_1_I2C_0, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu("mipi1_i2c1_clk", IMX_SC_R_MIPI_1_I2C_1, IMX_SC_PM_CLK_MISC2);
+	imx_clk_scu("mipi1_pwm0_clk", IMX_SC_R_MIPI_1_PWM_0, IMX_SC_PM_CLK_PER);
 
 	/* MIPI CSI SS */
-	clks[IMX_CSI0_CORE_CLK]		= imx_clk_scu("mipi_csi0_core_clk", IMX_SC_R_CSI_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CSI0_ESC_CLK]		= imx_clk_scu("mipi_csi0_esc_clk",  IMX_SC_R_CSI_0, IMX_SC_PM_CLK_MISC, clk_cells);
-	clks[IMX_CSI0_I2C0_CLK]		= imx_clk_scu("mipi_csi0_i2c0_clk", IMX_SC_R_CSI_0_I2C_0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_CSI0_PWM0_CLK]		= imx_clk_scu("mipi_csi0_pwm0_clk", IMX_SC_R_CSI_0_PWM_0, IMX_SC_PM_CLK_PER, clk_cells);
+	imx_clk_scu("mipi_csi0_core_clk", IMX_SC_R_CSI_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("mipi_csi0_esc_clk",  IMX_SC_R_CSI_0, IMX_SC_PM_CLK_MISC);
+	imx_clk_scu("mipi_csi0_i2c0_clk", IMX_SC_R_CSI_0_I2C_0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("mipi_csi0_pwm0_clk", IMX_SC_R_CSI_0_PWM_0, IMX_SC_PM_CLK_PER);
 
 	/* GPU SS */
-	clks[IMX_GPU0_CORE_CLK]		= imx_clk_scu("gpu_core0_clk",	 IMX_SC_R_GPU_0_PID0, IMX_SC_PM_CLK_PER, clk_cells);
-	clks[IMX_GPU0_SHADER_CLK]	= imx_clk_scu("gpu_shader0_clk", IMX_SC_R_GPU_0_PID0, IMX_SC_PM_CLK_MISC, clk_cells);
-
-	for (i = 0; i < clk_data->num; i++) {
-		if (IS_ERR(clks[i]))
-			pr_warn("i.MX clk %u: register failed with %ld\n",
-				i, PTR_ERR(clks[i]));
-	}
-
-	if (clk_cells == 2) {
-		ret = of_clk_add_hw_provider(ccm_node, imx_scu_of_clk_src_get, imx_scu_clks);
-		if (ret)
-			imx_clk_scu_unregister();
-	} else {
-		/*
-		 * legacy binding code path doesn't unregister here because
-		 * it will be removed later.
-		 */
-		ret = of_clk_add_hw_provider(ccm_node, of_clk_hw_onecell_get, clk_data);
-	}
+	imx_clk_scu("gpu_core0_clk",	 IMX_SC_R_GPU_0_PID0, IMX_SC_PM_CLK_PER);
+	imx_clk_scu("gpu_shader0_clk", IMX_SC_R_GPU_0_PID0, IMX_SC_PM_CLK_MISC);
+
+	ret = of_clk_add_hw_provider(ccm_node, imx_scu_of_clk_src_get, imx_scu_clks);
+	if (ret)
+		imx_clk_scu_unregister();
 
 	return ret;
 }
diff --git a/drivers/clk/imx/clk-scu.h b/drivers/clk/imx/clk-scu.h
index e8352164923e..a6c6d3103e94 100644
--- a/drivers/clk/imx/clk-scu.h
+++ b/drivers/clk/imx/clk-scu.h
@@ -32,22 +32,15 @@ struct clk_hw *__imx_clk_lpcg_scu(struct device *dev, const char *name,
 void imx_clk_lpcg_scu_unregister(struct clk_hw *hw);
 
 static inline struct clk_hw *imx_clk_scu(const char *name, u32 rsrc_id,
-					 u8 clk_type, u8 clk_cells)
+					 u8 clk_type)
 {
-	if (clk_cells == 2)
-		return imx_clk_scu_alloc_dev(name, NULL, 0, rsrc_id, clk_type);
-	else
-		return __imx_clk_scu(NULL, name, NULL, 0, rsrc_id, clk_type);
+	return imx_clk_scu_alloc_dev(name, NULL, 0, rsrc_id, clk_type);
 }
 
 static inline struct clk_hw *imx_clk_scu2(const char *name, const char * const *parents,
-					  int num_parents, u32 rsrc_id, u8 clk_type,
-					  u8 clk_cells)
+					  int num_parents, u32 rsrc_id, u8 clk_type)
 {
-	if (clk_cells == 2)
-		return imx_clk_scu_alloc_dev(name, parents, num_parents, rsrc_id, clk_type);
-	else
-		return __imx_clk_scu(NULL, name, parents, num_parents, rsrc_id, clk_type);
+	return imx_clk_scu_alloc_dev(name, parents, num_parents, rsrc_id, clk_type);
 }
 
 static inline struct clk_hw *imx_clk_lpcg_scu_dev(struct device *dev, const char *name,
diff --git a/include/dt-bindings/clock/imx8-clock.h b/include/dt-bindings/clock/imx8-clock.h
index 82b1fc8d1ee0..2e60ce4d2622 100644
--- a/include/dt-bindings/clock/imx8-clock.h
+++ b/include/dt-bindings/clock/imx8-clock.h
@@ -7,134 +7,6 @@
 #ifndef __DT_BINDINGS_CLOCK_IMX_H
 #define __DT_BINDINGS_CLOCK_IMX_H
 
-/* SCU Clocks */
-
-#define IMX_CLK_DUMMY				0
-
-/* CPU */
-#define IMX_A35_CLK					1
-
-/* LSIO SS */
-#define IMX_LSIO_MEM_CLK				2
-#define IMX_LSIO_BUS_CLK				3
-#define IMX_LSIO_PWM0_CLK				10
-#define IMX_LSIO_PWM1_CLK				11
-#define IMX_LSIO_PWM2_CLK				12
-#define IMX_LSIO_PWM3_CLK				13
-#define IMX_LSIO_PWM4_CLK				14
-#define IMX_LSIO_PWM5_CLK				15
-#define IMX_LSIO_PWM6_CLK				16
-#define IMX_LSIO_PWM7_CLK				17
-#define IMX_LSIO_GPT0_CLK				18
-#define IMX_LSIO_GPT1_CLK				19
-#define IMX_LSIO_GPT2_CLK				20
-#define IMX_LSIO_GPT3_CLK				21
-#define IMX_LSIO_GPT4_CLK				22
-#define IMX_LSIO_FSPI0_CLK				23
-#define IMX_LSIO_FSPI1_CLK				24
-
-/* Connectivity SS */
-#define IMX_CONN_AXI_CLK_ROOT				30
-#define IMX_CONN_AHB_CLK_ROOT				31
-#define IMX_CONN_IPG_CLK_ROOT				32
-#define IMX_CONN_SDHC0_CLK				40
-#define IMX_CONN_SDHC1_CLK				41
-#define IMX_CONN_SDHC2_CLK				42
-#define IMX_CONN_ENET0_ROOT_CLK				43
-#define IMX_CONN_ENET0_BYPASS_CLK			44
-#define IMX_CONN_ENET0_RGMII_CLK			45
-#define IMX_CONN_ENET1_ROOT_CLK				46
-#define IMX_CONN_ENET1_BYPASS_CLK			47
-#define IMX_CONN_ENET1_RGMII_CLK			48
-#define IMX_CONN_GPMI_BCH_IO_CLK			49
-#define IMX_CONN_GPMI_BCH_CLK				50
-#define IMX_CONN_USB2_ACLK				51
-#define IMX_CONN_USB2_BUS_CLK				52
-#define IMX_CONN_USB2_LPM_CLK				53
-
-/* HSIO SS */
-#define IMX_HSIO_AXI_CLK				60
-#define IMX_HSIO_PER_CLK				61
-
-/* Display controller SS */
-#define IMX_DC_AXI_EXT_CLK				70
-#define IMX_DC_AXI_INT_CLK				71
-#define IMX_DC_CFG_CLK					72
-#define IMX_DC0_PLL0_CLK				80
-#define IMX_DC0_PLL1_CLK				81
-#define IMX_DC0_DISP0_CLK				82
-#define IMX_DC0_DISP1_CLK				83
-#define IMX_DC0_BYPASS0_CLK				84
-#define IMX_DC0_BYPASS1_CLK				85
-
-/* MIPI-LVDS SS */
-#define IMX_MIPI_IPG_CLK				90
-#define IMX_MIPI0_PIXEL_CLK				100
-#define IMX_MIPI0_BYPASS_CLK				101
-#define IMX_MIPI0_LVDS_PIXEL_CLK			102
-#define IMX_MIPI0_LVDS_BYPASS_CLK			103
-#define IMX_MIPI0_LVDS_PHY_CLK				104
-#define IMX_MIPI0_I2C0_CLK				105
-#define IMX_MIPI0_I2C1_CLK				106
-#define IMX_MIPI0_PWM0_CLK				107
-#define IMX_MIPI1_PIXEL_CLK				108
-#define IMX_MIPI1_BYPASS_CLK				109
-#define IMX_MIPI1_LVDS_PIXEL_CLK			110
-#define IMX_MIPI1_LVDS_BYPASS_CLK			111
-#define IMX_MIPI1_LVDS_PHY_CLK				112
-#define IMX_MIPI1_I2C0_CLK				113
-#define IMX_MIPI1_I2C1_CLK				114
-#define IMX_MIPI1_PWM0_CLK				115
-
-/* IMG SS */
-#define IMX_IMG_AXI_CLK					120
-#define IMX_IMG_IPG_CLK					121
-#define IMX_IMG_PXL_CLK					122
-
-/* MIPI-CSI SS */
-#define IMX_CSI0_CORE_CLK				130
-#define IMX_CSI0_ESC_CLK				131
-#define IMX_CSI0_PWM0_CLK				132
-#define IMX_CSI0_I2C0_CLK				133
-
-/* PARALLER CSI SS */
-#define IMX_PARALLEL_CSI_DPLL_CLK			140
-#define IMX_PARALLEL_CSI_PIXEL_CLK			141
-#define IMX_PARALLEL_CSI_MCLK_CLK			142
-
-/* VPU SS */
-#define IMX_VPU_ENC_CLK					150
-#define IMX_VPU_DEC_CLK					151
-
-/* GPU SS */
-#define IMX_GPU0_CORE_CLK				160
-#define IMX_GPU0_SHADER_CLK				161
-
-/* ADMA SS */
-#define IMX_ADMA_IPG_CLK_ROOT				165
-#define IMX_ADMA_UART0_CLK				170
-#define IMX_ADMA_UART1_CLK				171
-#define IMX_ADMA_UART2_CLK				172
-#define IMX_ADMA_UART3_CLK				173
-#define IMX_ADMA_SPI0_CLK				174
-#define IMX_ADMA_SPI1_CLK				175
-#define IMX_ADMA_SPI2_CLK				176
-#define IMX_ADMA_SPI3_CLK				177
-#define IMX_ADMA_CAN0_CLK				178
-#define IMX_ADMA_CAN1_CLK				179
-#define IMX_ADMA_CAN2_CLK				180
-#define IMX_ADMA_I2C0_CLK				181
-#define IMX_ADMA_I2C1_CLK				182
-#define IMX_ADMA_I2C2_CLK				183
-#define IMX_ADMA_I2C3_CLK				184
-#define IMX_ADMA_FTM0_CLK				185
-#define IMX_ADMA_FTM1_CLK				186
-#define IMX_ADMA_ADC0_CLK				187
-#define IMX_ADMA_PWM_CLK				188
-#define IMX_ADMA_LCD_CLK				189
-
-#define IMX_SCU_CLK_END					190
-
 /* LPCG clocks */
 
 /* LSIO SS LPCG */
-- 
2.25.1



From chunfeng.yun at mediatek.com  Fri Apr 23 04:26:31 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 23 Apr 2021 11:26:31 +0800
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <YIE3z7qYNtk7G/VB@kroah.com>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03> <YGq2YfURFApdJLxb@kroah.com>
 <1617675492.22435.4.camel@mhfsdcap03> <YIE3z7qYNtk7G/VB@kroah.com>
Message-ID: <1619148391.4048.6.camel@mhfsdcap03>

On Thu, 2021-04-22 at 10:46 +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 06, 2021 at 10:18:12AM +0800, Chunfeng Yun wrote:
> > On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > > > cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> > > > 
> > > > I'll test it , thanks
> > > 
> > > Did you test this series and find any problems?  If not, I'll go queue
> > > these up...
> > Yes, found an issue on the start-split transaction, but not found the
> > root cause yet :(
> 
> So you are objecting to these being merged at this point in time? 
Yes

>  Can
> you provide feedback to the author about what is wrong?
Already provided feedback add discussed on issue tracker in private

Thanks a lot

> 
> thanks,
> 
> greg k-h


From aisheng.dong at nxp.com  Fri Apr 23 04:33:32 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:32 +0800
Subject: [PATCH 4/6] clk: imx: scu: add gpr clocks support
In-Reply-To: <20210423033334.3317992-1-aisheng.dong@nxp.com>
References: <20210423033334.3317992-1-aisheng.dong@nxp.com>
Message-ID: <20210423033334.3317992-4-aisheng.dong@nxp.com>

SCU clock protocol supports a few clocks based on GPR controller
registers including mux/divider/gate.
And a general clock register API to support them all.

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/clk/imx/clk-scu.c | 186 ++++++++++++++++++++++++++++++++++++++
 drivers/clk/imx/clk-scu.h |  29 ++++++
 2 files changed, 215 insertions(+)

diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index 1f5518b7ab39..cff0e1bd7030 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -52,6 +52,22 @@ struct clk_scu {
 	u32 rate;
 };
 
+/*
+ * struct clk_gpr_scu - Description of one SCU GPR clock
+ * @hw: the common clk_hw
+ * @rsrc_id: resource ID of this SCU clock
+ * @gpr_id: GPR ID index to control the divider
+ */
+struct clk_gpr_scu {
+	struct clk_hw hw;
+	u16 rsrc_id;
+	u8 gpr_id;
+	u8 flags;
+	bool gate_invert;
+};
+
+#define to_clk_gpr_scu(_hw) container_of(_hw, struct clk_gpr_scu, hw)
+
 /*
  * struct imx_sc_msg_req_set_clock_rate - clock set rate protocol
  * @hdr: SCU protocol header
@@ -604,3 +620,173 @@ void imx_clk_scu_unregister(void)
 		}
 	}
 }
+
+static unsigned long clk_gpr_div_scu_recalc_rate(struct clk_hw *hw,
+						 unsigned long parent_rate)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+	unsigned long rate = 0;
+	u32 val;
+	int err;
+
+	err = imx_sc_misc_get_control(ccm_ipc_handle, clk->rsrc_id,
+				      clk->gpr_id, &val);
+
+	rate  = val ? parent_rate / 2 : parent_rate;
+
+	return err ? 0 : rate;
+}
+
+static long clk_gpr_div_scu_round_rate(struct clk_hw *hw, unsigned long rate,
+				   unsigned long *prate)
+{
+	if (rate < *prate)
+		rate = *prate / 2;
+	else
+		rate = *prate;
+
+	return rate;
+}
+
+static int clk_gpr_div_scu_set_rate(struct clk_hw *hw, unsigned long rate,
+				    unsigned long parent_rate)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+	uint32_t val;
+	int err;
+
+	val = (rate < parent_rate) ? 1 : 0;
+	err = imx_sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,
+				      clk->gpr_id, val);
+
+	return err ? -EINVAL : 0;
+}
+
+static const struct clk_ops clk_gpr_div_scu_ops = {
+	.recalc_rate = clk_gpr_div_scu_recalc_rate,
+	.round_rate = clk_gpr_div_scu_round_rate,
+	.set_rate = clk_gpr_div_scu_set_rate,
+};
+
+static u8 clk_gpr_mux_scu_get_parent(struct clk_hw *hw)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+	u32 val = 0;
+
+	imx_sc_misc_get_control(ccm_ipc_handle, clk->rsrc_id,
+				clk->gpr_id, &val);
+
+	return (u8)val;
+}
+
+static int clk_gpr_mux_scu_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+
+	return imx_sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,
+				       clk->gpr_id, index);
+}
+
+static const struct clk_ops clk_gpr_mux_scu_ops = {
+	.get_parent = clk_gpr_mux_scu_get_parent,
+	.set_parent = clk_gpr_mux_scu_set_parent,
+};
+
+static int clk_gpr_gate_scu_prepare(struct clk_hw *hw)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+
+	return imx_sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,
+				       clk->gpr_id, !clk->gate_invert);
+}
+
+static void clk_gpr_gate_scu_unprepare(struct clk_hw *hw)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+	int ret;
+
+	ret = imx_sc_misc_set_control(ccm_ipc_handle, clk->rsrc_id,
+				      clk->gpr_id, clk->gate_invert);
+	if (ret)
+		pr_err("%s: clk unprepare failed %d\n", clk_hw_get_name(hw),
+		       ret);
+}
+
+static int clk_gpr_gate_scu_is_prepared(struct clk_hw *hw)
+{
+	struct clk_gpr_scu *clk = to_clk_gpr_scu(hw);
+	int ret;
+	u32 val;
+
+	ret = imx_sc_misc_get_control(ccm_ipc_handle, clk->rsrc_id,
+				      clk->gpr_id, &val);
+	if (ret)
+		return ret;
+
+	return clk->gate_invert ? !val : val;
+}
+
+static const struct clk_ops clk_gpr_gate_scu_ops = {
+	.prepare = clk_gpr_gate_scu_prepare,
+	.unprepare = clk_gpr_gate_scu_unprepare,
+	.is_prepared = clk_gpr_gate_scu_is_prepared,
+};
+
+struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_name,
+				 int num_parents, u32 rsrc_id, u8 gpr_id, u8 flags,
+				 bool invert)
+{
+	struct imx_scu_clk_node *clk_node;
+	struct clk_gpr_scu *clk;
+	struct clk_hw *hw;
+	struct clk_init_data init;
+	int ret;
+
+	if (rsrc_id >= IMX_SC_R_LAST || gpr_id >= IMX_SC_C_LAST)
+		return ERR_PTR(-EINVAL);
+
+	clk_node = kzalloc(sizeof(*clk_node), GFP_KERNEL);
+	if (!clk_node)
+		return ERR_PTR(-ENOMEM);
+
+	clk = kzalloc(sizeof(*clk), GFP_KERNEL);
+	if (!clk) {
+		kfree(clk_node);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	clk->rsrc_id = rsrc_id;
+	clk->gpr_id = gpr_id;
+	clk->flags = flags;
+	clk->gate_invert = invert;
+
+	if (flags & IMX_SCU_GPR_CLK_GATE)
+		init.ops = &clk_gpr_gate_scu_ops;
+
+	if (flags & IMX_SCU_GPR_CLK_DIV)
+		init.ops = &clk_gpr_div_scu_ops;
+
+	if (flags & IMX_SCU_GPR_CLK_MUX)
+		init.ops = &clk_gpr_mux_scu_ops;
+
+	init.flags = 0;
+	init.name = name;
+	init.parent_names = parent_name;
+	init.num_parents = num_parents;
+
+	clk->hw.init = &init;
+
+	hw = &clk->hw;
+	ret = clk_hw_register(NULL, hw);
+	if (ret) {
+		kfree(clk);
+		kfree(clk_node);
+		hw = ERR_PTR(ret);
+	} else {
+		clk_node->hw = hw;
+		clk_node->clk_type = gpr_id;
+		list_add_tail(&clk_node->node, &imx_scu_clks[rsrc_id]);
+	}
+
+	return hw;
+}
diff --git a/drivers/clk/imx/clk-scu.h b/drivers/clk/imx/clk-scu.h
index a6c6d3103e94..8ebee0cb0fe6 100644
--- a/drivers/clk/imx/clk-scu.h
+++ b/drivers/clk/imx/clk-scu.h
@@ -10,6 +10,10 @@
 #include <linux/firmware/imx/sci.h>
 #include <linux/of.h>
 
+#define IMX_SCU_GPR_CLK_GATE	BIT(0)
+#define IMX_SCU_GPR_CLK_DIV	BIT(1)
+#define IMX_SCU_GPR_CLK_MUX	BIT(2)
+
 extern struct list_head imx_scu_clks[];
 extern const struct dev_pm_ops imx_clk_lpcg_scu_pm_ops;
 
@@ -31,6 +35,10 @@ struct clk_hw *__imx_clk_lpcg_scu(struct device *dev, const char *name,
 				  void __iomem *reg, u8 bit_idx, bool hw_gate);
 void imx_clk_lpcg_scu_unregister(struct clk_hw *hw);
 
+struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_name,
+				 int num_parents, u32 rsrc_id, u8 gpr_id, u8 flags,
+				 bool invert);
+
 static inline struct clk_hw *imx_clk_scu(const char *name, u32 rsrc_id,
 					 u8 clk_type)
 {
@@ -58,4 +66,25 @@ static inline struct clk_hw *imx_clk_lpcg_scu(const char *name, const char *pare
 	return __imx_clk_lpcg_scu(NULL, name, parent_name, flags, reg,
 				  bit_idx, hw_gate);
 }
+
+static inline struct clk_hw *imx_clk_gate_gpr_scu(const char *name, const char *parent_name,
+						  u32 rsrc_id, u8 gpr_id, bool invert)
+{
+	return __imx_clk_gpr_scu(name, &parent_name, 1, rsrc_id, gpr_id,
+				 IMX_SCU_GPR_CLK_GATE, invert);
+}
+
+static inline struct clk_hw *imx_clk_divider_gpr_scu(const char *name, const char *parent_name,
+						     u32 rsrc_id, u8 gpr_id)
+{
+	return __imx_clk_gpr_scu(name, &parent_name, 1, rsrc_id, gpr_id,
+				 IMX_SCU_GPR_CLK_DIV, 0);
+}
+
+static inline struct clk_hw *imx_clk_mux_gpr_scu(const char *name, const char * const *parent_names,
+						 int num_parents, u32 rsrc_id, u8 gpr_id)
+{
+	return __imx_clk_gpr_scu(name, parent_names, num_parents, rsrc_id,
+				 gpr_id, IMX_SCU_GPR_CLK_MUX, 0);
+}
 #endif
-- 
2.25.1



From aisheng.dong at nxp.com  Fri Apr 23 04:33:34 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:34 +0800
Subject: [PATCH 6/6] clk: imx8qm: add clock valid resource checking
In-Reply-To: <20210423033334.3317992-1-aisheng.dong@nxp.com>
References: <20210423033334.3317992-1-aisheng.dong@nxp.com>
Message-ID: <20210423033334.3317992-6-aisheng.dong@nxp.com>

Add imx8qm clock valid resource checking mechanism

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/clk/imx/Makefile          |   2 +-
 drivers/clk/imx/clk-imx8qm-rsrc.c | 116 ++++++++++++++++++++++++++++++
 drivers/clk/imx/clk-imx8qxp.c     |   1 +
 drivers/clk/imx/clk-scu.h         |   1 +
 4 files changed, 119 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/imx/clk-imx8qm-rsrc.c

diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 2fdd2fff16c7..c24a2acbfa56 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
 
 obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
 clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o \
-				     clk-imx8qxp-rsrc.o
+				     clk-imx8qxp-rsrc.o clk-imx8qm-rsrc.o
 clk-imx-lpcg-scu-$(CONFIG_CLK_IMX8QXP) += clk-lpcg-scu.o clk-imx8qxp-lpcg.o
 
 obj-$(CONFIG_CLK_IMX1)   += clk-imx1.o
diff --git a/drivers/clk/imx/clk-imx8qm-rsrc.c b/drivers/clk/imx/clk-imx8qm-rsrc.c
new file mode 100644
index 000000000000..183a071cbf20
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8qm-rsrc.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 NXP
+ *	Dong Aisheng <aisheng.dong at nxp.com>
+ */
+
+#include <dt-bindings/firmware/imx/rsrc.h>
+
+#include "clk-scu.h"
+
+/* Keep sorted in the ascending order */
+static u32 imx8qm_clk_scu_rsrc_table[] = {
+	IMX_SC_R_A53,
+	IMX_SC_R_A72,
+	IMX_SC_R_DC_0_VIDEO0,
+	IMX_SC_R_DC_0_VIDEO1,
+	IMX_SC_R_DC_0,
+	IMX_SC_R_DC_0_PLL_0,
+	IMX_SC_R_DC_0_PLL_1,
+	IMX_SC_R_DC_1_VIDEO0,
+	IMX_SC_R_DC_1_VIDEO1,
+	IMX_SC_R_DC_1,
+	IMX_SC_R_DC_1_PLL_0,
+	IMX_SC_R_DC_1_PLL_1,
+	IMX_SC_R_SPI_0,
+	IMX_SC_R_SPI_1,
+	IMX_SC_R_SPI_2,
+	IMX_SC_R_SPI_3,
+	IMX_SC_R_UART_0,
+	IMX_SC_R_UART_1,
+	IMX_SC_R_UART_2,
+	IMX_SC_R_UART_3,
+	IMX_SC_R_UART_4,
+	IMX_SC_R_EMVSIM_0,
+	IMX_SC_R_EMVSIM_1,
+	IMX_SC_R_I2C_0,
+	IMX_SC_R_I2C_1,
+	IMX_SC_R_I2C_2,
+	IMX_SC_R_I2C_3,
+	IMX_SC_R_I2C_4,
+	IMX_SC_R_ADC_0,
+	IMX_SC_R_ADC_1,
+	IMX_SC_R_FTM_0,
+	IMX_SC_R_FTM_1,
+	IMX_SC_R_CAN_0,
+	IMX_SC_R_GPU_0_PID0,
+	IMX_SC_R_GPU_1_PID0,
+	IMX_SC_R_PWM_0,
+	IMX_SC_R_PWM_1,
+	IMX_SC_R_PWM_2,
+	IMX_SC_R_PWM_3,
+	IMX_SC_R_PWM_4,
+	IMX_SC_R_PWM_5,
+	IMX_SC_R_PWM_6,
+	IMX_SC_R_PWM_7,
+	IMX_SC_R_GPT_0,
+	IMX_SC_R_GPT_1,
+	IMX_SC_R_GPT_2,
+	IMX_SC_R_GPT_3,
+	IMX_SC_R_GPT_4,
+	IMX_SC_R_FSPI_0,
+	IMX_SC_R_FSPI_1,
+	IMX_SC_R_SDHC_0,
+	IMX_SC_R_SDHC_1,
+	IMX_SC_R_SDHC_2,
+	IMX_SC_R_ENET_0,
+	IMX_SC_R_ENET_1,
+	IMX_SC_R_MLB_0,
+	IMX_SC_R_USB_2,
+	IMX_SC_R_NAND,
+	IMX_SC_R_LVDS_0,
+	IMX_SC_R_LVDS_0_PWM_0,
+	IMX_SC_R_LVDS_0_I2C_0,
+	IMX_SC_R_LVDS_0_I2C_1,
+	IMX_SC_R_LVDS_1,
+	IMX_SC_R_LVDS_1_PWM_0,
+	IMX_SC_R_LVDS_1_I2C_0,
+	IMX_SC_R_LVDS_1_I2C_1,
+	IMX_SC_R_M4_0_I2C,
+	IMX_SC_R_M4_1_I2C,
+	IMX_SC_R_AUDIO_PLL_0,
+	IMX_SC_R_VPU_UART,
+	IMX_SC_R_VPUCORE,
+	IMX_SC_R_MIPI_0,
+	IMX_SC_R_MIPI_0_PWM_0,
+	IMX_SC_R_MIPI_0_I2C_0,
+	IMX_SC_R_MIPI_0_I2C_1,
+	IMX_SC_R_MIPI_1,
+	IMX_SC_R_MIPI_1_PWM_0,
+	IMX_SC_R_MIPI_1_I2C_0,
+	IMX_SC_R_MIPI_1_I2C_1,
+	IMX_SC_R_CSI_0,
+	IMX_SC_R_CSI_0_PWM_0,
+	IMX_SC_R_CSI_0_I2C_0,
+	IMX_SC_R_CSI_1,
+	IMX_SC_R_CSI_1_PWM_0,
+	IMX_SC_R_CSI_1_I2C_0,
+	IMX_SC_R_HDMI,
+	IMX_SC_R_HDMI_I2S,
+	IMX_SC_R_HDMI_I2C_0,
+	IMX_SC_R_HDMI_PLL_0,
+	IMX_SC_R_HDMI_RX,
+	IMX_SC_R_HDMI_RX_BYPASS,
+	IMX_SC_R_HDMI_RX_I2C_0,
+	IMX_SC_R_AUDIO_PLL_1,
+	IMX_SC_R_AUDIO_CLK_0,
+	IMX_SC_R_AUDIO_CLK_1,
+	IMX_SC_R_HDMI_RX_PWM_0,
+	IMX_SC_R_HDMI_PLL_1,
+	IMX_SC_R_VPU,
+};
+
+const struct imx_clk_scu_rsrc_table imx_clk_scu_rsrc_imx8qm = {
+	.rsrc = imx8qm_clk_scu_rsrc_table,
+	.num = ARRAY_SIZE(imx8qm_clk_scu_rsrc_table),
+};
diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index 9e35ae45b3a0..88cc737ee125 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -134,6 +134,7 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
 static const struct of_device_id imx8qxp_match[] = {
 	{ .compatible = "fsl,scu-clk", },
 	{ .compatible = "fsl,imx8qxp-clk", &imx_clk_scu_rsrc_imx8qxp, },
+	{ .compatible = "fsl,imx8qm-clk", &imx_clk_scu_rsrc_imx8qm, },
 	{ /* sentinel */ }
 };
 
diff --git a/drivers/clk/imx/clk-scu.h b/drivers/clk/imx/clk-scu.h
index bcacd8b1d1ab..22156e93b85d 100644
--- a/drivers/clk/imx/clk-scu.h
+++ b/drivers/clk/imx/clk-scu.h
@@ -22,6 +22,7 @@ struct imx_clk_scu_rsrc_table {
 extern struct list_head imx_scu_clks[];
 extern const struct dev_pm_ops imx_clk_lpcg_scu_pm_ops;
 extern const struct imx_clk_scu_rsrc_table imx_clk_scu_rsrc_imx8qxp;
+extern const struct imx_clk_scu_rsrc_table imx_clk_scu_rsrc_imx8qm;
 
 int imx_clk_scu_init(struct device_node *np,
 		     const struct imx_clk_scu_rsrc_table *data);
-- 
2.25.1



From aisheng.dong at nxp.com  Fri Apr 23 04:33:33 2021
From: aisheng.dong at nxp.com (Dong Aisheng)
Date: Fri, 23 Apr 2021 11:33:33 +0800
Subject: [PATCH 5/6] clk: imx8qxp: add clock valid checking mechnism
In-Reply-To: <20210423033334.3317992-1-aisheng.dong@nxp.com>
References: <20210423033334.3317992-1-aisheng.dong@nxp.com>
Message-ID: <20210423033334.3317992-5-aisheng.dong@nxp.com>

clk-imx8qxp is a common SCU clock driver used by both QM and QXP
platforms. The clock numbers vary a bit between those two platforms.
This patch introduces a mechanism to only register the valid clocks
for one platform by checking the clk resource id table.

Signed-off-by: Dong Aisheng <aisheng.dong at nxp.com>
---
 drivers/clk/imx/Makefile           |  3 +-
 drivers/clk/imx/clk-imx8qxp-rsrc.c | 89 ++++++++++++++++++++++++++++++
 drivers/clk/imx/clk-imx8qxp.c      |  9 ++-
 drivers/clk/imx/clk-scu.c          | 33 ++++++++++-
 drivers/clk/imx/clk-scu.h          | 11 +++-
 5 files changed, 137 insertions(+), 8 deletions(-)
 create mode 100644 drivers/clk/imx/clk-imx8qxp-rsrc.c

diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index dd6a737d060b..2fdd2fff16c7 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -27,7 +27,8 @@ obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o
 obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
 
 obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o
-clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o
+clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o \
+				     clk-imx8qxp-rsrc.o
 clk-imx-lpcg-scu-$(CONFIG_CLK_IMX8QXP) += clk-lpcg-scu.o clk-imx8qxp-lpcg.o
 
 obj-$(CONFIG_CLK_IMX1)   += clk-imx1.o
diff --git a/drivers/clk/imx/clk-imx8qxp-rsrc.c b/drivers/clk/imx/clk-imx8qxp-rsrc.c
new file mode 100644
index 000000000000..ab66811ba9c1
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8qxp-rsrc.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 NXP
+ *	Dong Aisheng <aisheng.dong at nxp.com>
+ */
+
+#include <dt-bindings/firmware/imx/rsrc.h>
+
+#include "clk-scu.h"
+
+/* Keep sorted in the ascending order */
+static u32 imx8qxp_clk_scu_rsrc_table[] = {
+	IMX_SC_R_DC_0_VIDEO0,
+	IMX_SC_R_DC_0_VIDEO1,
+	IMX_SC_R_DC_0,
+	IMX_SC_R_DC_0_PLL_0,
+	IMX_SC_R_DC_0_PLL_1,
+	IMX_SC_R_SPI_0,
+	IMX_SC_R_SPI_1,
+	IMX_SC_R_SPI_2,
+	IMX_SC_R_SPI_3,
+	IMX_SC_R_UART_0,
+	IMX_SC_R_UART_1,
+	IMX_SC_R_UART_2,
+	IMX_SC_R_UART_3,
+	IMX_SC_R_I2C_0,
+	IMX_SC_R_I2C_1,
+	IMX_SC_R_I2C_2,
+	IMX_SC_R_I2C_3,
+	IMX_SC_R_ADC_0,
+	IMX_SC_R_FTM_0,
+	IMX_SC_R_FTM_1,
+	IMX_SC_R_CAN_0,
+	IMX_SC_R_GPU_0_PID0,
+	IMX_SC_R_LCD_0,
+	IMX_SC_R_LCD_0_PWM_0,
+	IMX_SC_R_PWM_0,
+	IMX_SC_R_PWM_1,
+	IMX_SC_R_PWM_2,
+	IMX_SC_R_PWM_3,
+	IMX_SC_R_PWM_4,
+	IMX_SC_R_PWM_5,
+	IMX_SC_R_PWM_6,
+	IMX_SC_R_PWM_7,
+	IMX_SC_R_GPT_0,
+	IMX_SC_R_GPT_1,
+	IMX_SC_R_GPT_2,
+	IMX_SC_R_GPT_3,
+	IMX_SC_R_GPT_4,
+	IMX_SC_R_FSPI_0,
+	IMX_SC_R_FSPI_1,
+	IMX_SC_R_SDHC_0,
+	IMX_SC_R_SDHC_1,
+	IMX_SC_R_SDHC_2,
+	IMX_SC_R_ENET_0,
+	IMX_SC_R_ENET_1,
+	IMX_SC_R_MLB_0,
+	IMX_SC_R_USB_2,
+	IMX_SC_R_NAND,
+	IMX_SC_R_LVDS_0,
+	IMX_SC_R_LVDS_1,
+	IMX_SC_R_M4_0_I2C,
+	IMX_SC_R_ELCDIF_PLL,
+	IMX_SC_R_AUDIO_PLL_0,
+	IMX_SC_R_PI_0,
+	IMX_SC_R_PI_0_PLL,
+	IMX_SC_R_MIPI_0,
+	IMX_SC_R_MIPI_0_PWM_0,
+	IMX_SC_R_MIPI_0_I2C_0,
+	IMX_SC_R_MIPI_0_I2C_1,
+	IMX_SC_R_MIPI_1,
+	IMX_SC_R_MIPI_1_PWM_0,
+	IMX_SC_R_MIPI_1_I2C_0,
+	IMX_SC_R_MIPI_1_I2C_1,
+	IMX_SC_R_CSI_0,
+	IMX_SC_R_CSI_0_PWM_0,
+	IMX_SC_R_CSI_0_I2C_0,
+	IMX_SC_R_AUDIO_PLL_1,
+	IMX_SC_R_AUDIO_CLK_0,
+	IMX_SC_R_AUDIO_CLK_1,
+	IMX_SC_R_A35,
+	IMX_SC_R_VPU_DEC_0,
+	IMX_SC_R_VPU_ENC_0,
+};
+
+const struct imx_clk_scu_rsrc_table imx_clk_scu_rsrc_imx8qxp = {
+	.rsrc = imx8qxp_clk_scu_rsrc_table,
+	.num = ARRAY_SIZE(imx8qxp_clk_scu_rsrc_table),
+};
diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index d17b418ac577..9e35ae45b3a0 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright 2018 NXP
+ * Copyright 2018-2021 NXP
  *	Dong Aisheng <aisheng.dong at nxp.com>
  */
 
@@ -9,6 +9,7 @@
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
@@ -27,9 +28,11 @@ static const char *dc0_sels[] = {
 static int imx8qxp_clk_probe(struct platform_device *pdev)
 {
 	struct device_node *ccm_node = pdev->dev.of_node;
+	const struct imx_clk_scu_rsrc_table *rsrc_table;
 	int ret;
 
-	ret = imx_clk_scu_init(ccm_node);
+	rsrc_table = of_device_get_match_data(&pdev->dev);
+	ret = imx_clk_scu_init(ccm_node, rsrc_table);
 	if (ret)
 		return ret;
 
@@ -130,7 +133,7 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
 
 static const struct of_device_id imx8qxp_match[] = {
 	{ .compatible = "fsl,scu-clk", },
-	{ .compatible = "fsl,imx8qxp-clk", },
+	{ .compatible = "fsl,imx8qxp-clk", &imx_clk_scu_rsrc_imx8qxp, },
 	{ /* sentinel */ }
 };
 
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index cff0e1bd7030..02044d48d9bc 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -1,11 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright 2018 NXP
+ * Copyright 2018-2021 NXP
  *   Dong Aisheng <aisheng.dong at nxp.com>
  */
 
 #include <dt-bindings/firmware/imx/rsrc.h>
 #include <linux/arm-smccc.h>
+#include <linux/bsearch.h>
 #include <linux/clk-provider.h>
 #include <linux/err.h>
 #include <linux/of_platform.h>
@@ -22,6 +23,7 @@
 static struct imx_sc_ipc *ccm_ipc_handle;
 static struct device_node *pd_np;
 static struct platform_driver imx_clk_scu_driver;
+static const struct imx_clk_scu_rsrc_table *rsrc_table;
 
 struct imx_scu_clk_node {
 	const char *name;
@@ -167,7 +169,26 @@ static inline struct clk_scu *to_clk_scu(struct clk_hw *hw)
 	return container_of(hw, struct clk_scu, hw);
 }
 
-int imx_clk_scu_init(struct device_node *np)
+static inline int imx_scu_clk_search_cmp(const void *rsrc, const void *rsrc_p)
+{
+	return *(u32 *)rsrc - *(u32 *)rsrc_p;
+}
+
+static bool imx_scu_clk_is_valid(u32 rsrc_id)
+{
+	void *p;
+
+	if (!rsrc_table)
+		return true;
+
+	p = bsearch(&rsrc_id, rsrc_table->rsrc, rsrc_table->num,
+		    sizeof(rsrc_table->rsrc[0]), imx_scu_clk_search_cmp);
+
+	return p != NULL;
+}
+
+int imx_clk_scu_init(struct device_node *np,
+		     const struct imx_clk_scu_rsrc_table *data)
 {
 	u32 clk_cells;
 	int ret, i;
@@ -186,6 +207,8 @@ int imx_clk_scu_init(struct device_node *np)
 		pd_np = of_find_compatible_node(NULL, NULL, "fsl,scu-pd");
 		if (!pd_np)
 			return -EINVAL;
+
+		rsrc_table = data;
 	}
 
 	return platform_driver_register(&imx_clk_scu_driver);
@@ -582,6 +605,9 @@ struct clk_hw *imx_clk_scu_alloc_dev(const char *name,
 	struct platform_device *pdev;
 	int ret;
 
+	if (!imx_scu_clk_is_valid(rsrc_id))
+		return ERR_PTR(-EINVAL);
+
 	pdev = platform_device_alloc(name, PLATFORM_DEVID_NONE);
 	if (!pdev) {
 		pr_err("%s: failed to allocate scu clk dev rsrc %d type %d\n",
@@ -749,6 +775,9 @@ struct clk_hw *__imx_clk_gpr_scu(const char *name, const char * const *parent_na
 	if (!clk_node)
 		return ERR_PTR(-ENOMEM);
 
+	if (!imx_scu_clk_is_valid(rsrc_id))
+		return ERR_PTR(-EINVAL);
+
 	clk = kzalloc(sizeof(*clk), GFP_KERNEL);
 	if (!clk) {
 		kfree(clk_node);
diff --git a/drivers/clk/imx/clk-scu.h b/drivers/clk/imx/clk-scu.h
index 8ebee0cb0fe6..bcacd8b1d1ab 100644
--- a/drivers/clk/imx/clk-scu.h
+++ b/drivers/clk/imx/clk-scu.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright 2018 NXP
+ * Copyright 2018-2021 NXP
  *   Dong Aisheng <aisheng.dong at nxp.com>
  */
 
@@ -14,10 +14,17 @@
 #define IMX_SCU_GPR_CLK_DIV	BIT(1)
 #define IMX_SCU_GPR_CLK_MUX	BIT(2)
 
+struct imx_clk_scu_rsrc_table {
+	const u32 *rsrc;
+	u8 num;
+};
+
 extern struct list_head imx_scu_clks[];
 extern const struct dev_pm_ops imx_clk_lpcg_scu_pm_ops;
+extern const struct imx_clk_scu_rsrc_table imx_clk_scu_rsrc_imx8qxp;
 
-int imx_clk_scu_init(struct device_node *np);
+int imx_clk_scu_init(struct device_node *np,
+		     const struct imx_clk_scu_rsrc_table *data);
 struct clk_hw *imx_scu_of_clk_src_get(struct of_phandle_args *clkspec,
 				      void *data);
 struct clk_hw *imx_clk_scu_alloc_dev(const char *name,
-- 
2.25.1



From email2tema at gmail.com  Fri Apr 23 04:42:47 2021
From: email2tema at gmail.com (Artem Lapkin)
Date: Fri, 23 Apr 2021 11:42:47 +0800
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
Message-ID: <20210423034247.992052-1-art@khadas.com>

Problem: rmmod meson_gx_mmc - not stable without spi_master_suspend call
and we can get stuck when try unload this module

rmmod meson_gx_mmc
...
[  421.108614] Deleting MTD partitions on "spi0.0":
[  424.219862] spi_master spi0: Failed to power device: -13
...
lsmod | grep spi
spi_meson_spifc        16384 -1

Solution: just add spi_master_suspend(master) call

Signed-off-by: Artem Lapkin <art at khadas.com>
---
 drivers/spi/spi-meson-spifc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-meson-spifc.c b/drivers/spi/spi-meson-spifc.c
index 8eca6f24c..8a97a6dbf 100644
--- a/drivers/spi/spi-meson-spifc.c
+++ b/drivers/spi/spi-meson-spifc.c
@@ -359,6 +359,7 @@ static int meson_spifc_remove(struct platform_device *pdev)
 	struct spi_master *master = platform_get_drvdata(pdev);
 	struct meson_spifc *spifc = spi_master_get_devdata(master);
 
+	spi_master_suspend(master);
 	pm_runtime_get_sync(&pdev->dev);
 	clk_disable_unprepare(spifc->clk);
 	pm_runtime_disable(&pdev->dev);
-- 
2.25.1



From wangqing at vivo.com  Fri Apr 23 04:48:06 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Fri, 23 Apr 2021 11:48:06 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSCBWNyAxLzJdIHdhdGNoZG9nOiBtdGs6IHN1cHBvcnQgcHJlLXRpbWVvdXQgd2hlbiB0aGUgYmFyayBpcnEgaXMgYXZhaWxhYmxl?=
In-Reply-To: <0de7e5c8-57a2-9b27-d8a8-ed7e0b394b02@roeck-us.net>
Message-ID: <AOUAdwCCDk8v*1Yj0s9Qo4qH.3.1619149686926.Hmail.wangqing@vivo.com>


>On 4/22/21 7:53 PM, Wang Qing wrote:
>> Use the bark interrupt as the pretimeout notifier if available.
>> 
>> When the watchdog timer expires in dual mode, an interrupt will be
>> triggered first, then the timing restarts. The reset signal will be
>> initiated when the timer expires again.
>> 
>> The pretimeout notification shall occur at timeout-sec/2.
>> 
>> V2:
>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>> 
>> V3:
>> - Modify the pretimeout behavior, manually reset after the pretimeout
>> - is processed and wait until timeout.
>> 
>> V4:
>> - Remove pretimeout related processing. 
>> - Add dual mode control separately.
>> 
>> V5:
>> - Fix some formatting and printing problems.
>> 
>> V6:
>> - Realize pretimeout processing through dualmode.
>> 
>> V7:
>> - Add set_pretimeout().
>> 
>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>> ---
>>  drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 71 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>> index 97ca993..ab3ac5d
>> --- a/drivers/watchdog/mtk_wdt.c
>> +++ b/drivers/watchdog/mtk_wdt.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/reset-controller.h>
>>  #include <linux/types.h>
>>  #include <linux/watchdog.h>
>> +#include <linux/interrupt.h>
>>  
>>  #define WDT_MAX_TIMEOUT		31
>>  #define WDT_MIN_TIMEOUT		1
>> @@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>  {
>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>> +	unsigned int timeout_interval = timeout;
>>  	u32 reg;
>>  
>>  	wdt_dev->timeout = timeout;
>> -
>> +	/*
>> +	 * In dual mode, irq will be triggered at timeout / 2
>> +	 * the real timeout occurs at timeout
>> +	 */
>> +	if (wdt_dev->pretimeout) {
>> +		wdt_dev->pretimeout = timeout / 2;
>
>min_timeout is set to 1. I don't this works well if timeout == 1.
>You'll either need to set min_timeout to 2, or handle that case.

It is appropriate to change min_timeout  to 2.

>
>> +		timeout_interval = wdt_dev->pretimeout;
>
>timeout_interval is unnecessary. Just update timeout accordingly.
>It needs to take the situation of timeout == 1 into account, though.

timeout represents the reset time. When the user calls timeout_show, 
He hopes to get the configured timeout, not the value changed
by pre-timeout.
I modify it like this more in line with the original intention.

>
>> +	}
>>  	/*
>>  	 * One bit is the value of 512 ticks
>>  	 * The clock has 32 KHz
>>  	 */
>> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
>> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>>  
>>  	mtk_wdt_ping(wdt_dev);
>> @@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>  		return ret;
>>  
>>  	reg = ioread32(wdt_base + WDT_MODE);
>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	if (wdt_dev->pretimeout)
>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	else
>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>>  	iowrite32(reg, wdt_base + WDT_MODE);
>>  
>>  	return 0;
>>  }
>>  
>> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
>> +					unsigned int timeout)
>> +{
>> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
>> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
>> +	u32 reg = ioread32(wdt_base + WDT_MODE);
>> +
>> +	if (timeout && !wdd->pretimeout) {
>> +		wdd->pretimeout = wdd->timeout / 2;
>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	} else if (!timeout && wdd->pretimeout) {
>> +		wdd->pretimeout = 0;
>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>> +	} else
>> +		return 0;
>> +
>> +	iowrite32(reg, wdt_base + WDT_MODE);
>
>What is the point of setting the mode here ? It will
>be set again in mtk_wdt_set_timeout(). Seems to me all
>you need to do here is to set wdd->pretimeout,
>then call mtk_wdt_set_timeout().

mtk_wdt_set_timeout() only set timeout and ping().
Here also need to config to the dualmode or not.

Thanks,
Qing
>
>Guenter
>
>> +
>> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
>> +}
>> +
>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
>> +{
>> +	struct watchdog_device *wdd = arg;
>> +
>> +	watchdog_notify_pretimeout(wdd);
>> +
>> +	return IRQ_HANDLED;
>> +}
>> +
>>  static const struct watchdog_info mtk_wdt_info = {
>>  	.identity	= DRV_NAME,
>>  	.options	= WDIOF_SETTIMEOUT |
>> @@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
>>  			  WDIOF_MAGICCLOSE,
>>  };
>>  
>> +static const struct watchdog_info mtk_wdt_pt_info = {
>> +	.identity	= DRV_NAME,
>> +	.options	= WDIOF_SETTIMEOUT |
>> +			  WDIOF_PRETIMEOUT |
>> +			  WDIOF_KEEPALIVEPING |
>> +			  WDIOF_MAGICCLOSE,
>> +};
>> +
>>  static const struct watchdog_ops mtk_wdt_ops = {
>>  	.owner		= THIS_MODULE,
>>  	.start		= mtk_wdt_start,
>>  	.stop		= mtk_wdt_stop,
>>  	.ping		= mtk_wdt_ping,
>>  	.set_timeout	= mtk_wdt_set_timeout,
>> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>>  	.restart	= mtk_wdt_restart,
>>  };
>>  
>> @@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>  	struct device *dev = &pdev->dev;
>>  	struct mtk_wdt_dev *mtk_wdt;
>>  	const struct mtk_wdt_data *wdt_data;
>> -	int err;
>> +	int err, irq;
>>  
>>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>>  	if (!mtk_wdt)
>> @@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>  	if (IS_ERR(mtk_wdt->wdt_base))
>>  		return PTR_ERR(mtk_wdt->wdt_base);
>>  
>> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>> +	irq = platform_get_irq(pdev, 0);
>> +	if (irq > 0) {
>> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
>> +					&mtk_wdt->wdt_dev);
>> +		if (err)
>> +			return err;
>> +
>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
>> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
>> +	} else {
>> +		if (irq == -EPROBE_DEFER)
>> +			return -EPROBE_DEFER;
>> +
>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>> +	}
>> +
>>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
>> 
>



From ilya.lipnitskiy at gmail.com  Fri Apr 23 05:16:19 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 21:16:19 -0700
Subject: [PATCH net-next 05/14] net: ethernet: mtk_eth_soc: reduce MDIO
 bus access latency
In-Reply-To: <d96206db-96e2-1eb7-6b19-47c9596ccfea@nbd.name>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-6-ilya.lipnitskiy@gmail.com>
 <d96206db-96e2-1eb7-6b19-47c9596ccfea@nbd.name>
Message-ID: <CALCv0x0dRPDsrkNYOgWW-+rFj_7ysNfj+x_2AmFRa0f3No2YZg@mail.gmail.com>

On Thu, Apr 22, 2021 at 5:33 AM Felix Fietkau <nbd at nbd.name> wrote:
>
>
> On 2021-04-22 06:09, Ilya Lipnitskiy wrote:
> > From: Felix Fietkau <nbd at nbd.name>
> >
> > usleep_range often ends up sleeping much longer than the 10-20us provided
> > as a range here. This causes significant latency in mdio bus acceses,
> > which easily adds multiple seconds to the boot time on MT7621 when polling
> > DSA slave ports.
> >
> > Use udelay via readx_poll_timeout_atomic, since the MDIO access does not
> > take much time
> >
> > Signed-off-by: Felix Fietkau <nbd at nbd.name>
> > [Ilya: use readx_poll_timeout_atomic instead of cond_resched]
> I still prefer the cond_resched() variant.
No problem, I will respin with your original change. Looks like we
can't take advantage of iopoll.h routine in this case, but that's not
the end of the world!

> On a fully loaded system, I'd
> prefer to let the MDIO access take longer instead of wasting cycles on
> udelay.
>
> - Felix

Ilya


From ilya.lipnitskiy at gmail.com  Fri Apr 23 05:18:31 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 21:18:31 -0700
Subject: [PATCH net-next 00/14] mtk_eth_soc: fixes and performance
 improvements
In-Reply-To: <YIFq2NIhdMWTDshX@lunn.ch>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <YIFq2NIhdMWTDshX@lunn.ch>
Message-ID: <CALCv0x1k+Bi+nCY+yJ-n+EYbRW1keRgF35QDNPe-WCO-z8qxBw@mail.gmail.com>

On Thu, Apr 22, 2021 at 5:23 AM Andrew Lunn <andrew at lunn.ch> wrote:
>
> On Wed, Apr 21, 2021 at 09:09:00PM -0700, Ilya Lipnitskiy wrote:
> > Most of these changes come from OpenWrt where they have been present and
> > tested for months.
> >
> > First three patches are bug fixes. The rest are performance
> > improvements. The last patch is a cleanup to use the iopoll.h macro for
> > busy-waiting instead of a custom loop.
>
> Do you have any benchmark numbers you can share?
No. Felix, do you have anything handy?

If needed, I'll run some tests before and after the patch series on
OpenWrt against v5.10, but I only have an MT7621 device - should be
better than nothing though...

Ilya


From ilya.lipnitskiy at gmail.com  Fri Apr 23 05:20:21 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 21:20:21 -0700
Subject: [PATCH net-next 12/14] net: ethernet: mtk_eth_soc: reduce
 unnecessary interrupts
In-Reply-To: <20210422092608.6b8ed5ff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210422040914.47788-1-ilya.lipnitskiy@gmail.com>
 <20210422040914.47788-13-ilya.lipnitskiy@gmail.com>
 <20210422092608.6b8ed5ff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <CALCv0x0vVzdtr=yezvHsq9TSx-nd76NiT2zYqQOuOa2W86VEqQ@mail.gmail.com>

On Thu, Apr 22, 2021 at 9:26 AM Jakub Kicinski <kuba at kernel.org> wrote:
>
> On Wed, 21 Apr 2021 21:09:12 -0700 Ilya Lipnitskiy wrote:
> > @@ -1551,8 +1551,9 @@ static int mtk_napi_rx(struct napi_struct *napi, int budget)
> >               remain_budget -= rx_done;
> >               goto poll_again;
> >       }
> > -     napi_complete(napi);
> > -     mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
> > +
> > +     if (napi_complete(napi))
> > +             mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
>
> Why not napi_complete_done(napi, rx_done + budget - remain_budget)?
> (Modulo possible elimination of rx_done in this function.)
No reason, I think. Thanks for pointing it out. I will clean up both
TX and RX NAPI callbacks to use napi_complete_done and to get rid of
that ugly goto...

Ilya


From adrian.hunter at intel.com  Fri Apr 23 05:23:49 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 23 Apr 2021 07:23:49 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <651f5d8a-5ab7-77dd-3fed-05feb3fd3e1a@codeaurora.org>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
 <fdadd467-b613-d800-18c5-be064396fd10@intel.com>
 <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
 <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>
 <1bc4a73e-b22a-6bad-2583-3a0ffa979414@intel.com>
 <651f5d8a-5ab7-77dd-3fed-05feb3fd3e1a@codeaurora.org>
Message-ID: <efe71230-5b6a-22a8-1aef-f1cae046df22@intel.com>

On 22/04/21 7:38 pm, Asutosh Das (asd) wrote:
> On 4/20/2021 12:42 AM, Adrian Hunter wrote:
>> On 20/04/21 7:15 am, Adrian Hunter wrote:
>>> On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
>>>> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>>>>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>>>>
>>>>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>>>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>>>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>>>>> ---
>>>>>
>>>>> I came across 3 issues while testing.? See comments below.
>>>>>
>>>> Hi Adrian
>>>> Thanks for the comments.
>>>>> <SNIP>
>>>>>
>>>>>> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>>>>>> ?????? if (ufshcd_is_clkscaling_supported(hba))
>>>>>> ?????????? ufshcd_clk_scaling_suspend(hba, false);
>>>>>> ?????? ufshcd_clear_ua_wluns(hba);
>>>>>
>>>>> ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
>>>>> if sdev_rpmb is suspended and sdev_ufs_device is suspending.
>>>>> e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
>>>>> is running, at which point sdev_rpmb has already suspended.
>>>>>
>>>> Umm, I didn't understand this deadlock.
>>>> When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
>>>> sdev_ufs_device is suspending - this can't be runtime_suspending, while ufshcd_err_handling_unprepare is running.
>>>>
>>>> If you've a call-stack of this deadlock, please can you share it with me. I'll also try to reproduce this.
>>>
>>> Yes it is system suspend. sdev_rpmb has suspended, sdev_ufs_device is waiting on host_sem.
>>> ufshcd_err_handler() holds host_sem. ufshcd_clear_ua_wlun(UFS_UPIU_RPMB_WLUN) gets stuck.
>>> I will get some call-stacks.
>>
> Hi Adrian,
> 
> Thanks for the call stacks.
> From the current information, I can't say for sure why it'd get stuck in blk_queue_enter().

I presume SCSI is leaving the RPMB WLUN device runtime suspended and consequently the queue status is RPM_SUSPENDED

> 
> I tried reproducing this issue on my setup yesterday but couldn't.
> Here's what I did:
> 1. sdev_rpmb is RPM_SUSPENDED, checked before initiating system suspend
> 2. sdev_ufs_device is RPM_RESUMED
> 3. I triggered system suspend (echo mem > /sys/power/state) and scheduled the error handler from ufshcd_wl_suspend().
> 4. Waited until error handler ran and then ufshcd_wl_suspend() blocks on host_sem.
> 5. The ufshcd_clear_wa_wlun(UFS_UPIU_RPMB_WLUN) went through fine.
> 
> Do you've some specific steps to reproduce this or a script, perhaps? If so, please can you share it with me. I will try again.

I was using a device that gives occasional errors, but I will what see I can do.

> My test environment is in 5.10 kernel with Android, I suppose that should be ok though.
> 
> Thanks
> -asd
> 
>> Here are the call stacks
>>
>> [?? 34.094321] Workqueue: ufs_eh_wq_0 ufshcd_err_handler
>> [?? 34.094788] Call Trace:
>> [?? 34.095281]? __schedule+0x275/0x6c0
>> [?? 34.095743]? schedule+0x41/0xa0
>> [?? 34.096240]? blk_queue_enter+0x10d/0x230
>> [?? 34.096693]? ? wait_woken+0x70/0x70
>> [?? 34.097167]? blk_mq_alloc_request+0x53/0xc0
>> [?? 34.097610]? blk_get_request+0x1e/0x60
>> [?? 34.098053]? __scsi_execute+0x3c/0x260
>> [?? 34.098529]? ufshcd_clear_ua_wlun.cold+0xa6/0x14b
>> [?? 34.098977]? ufshcd_clear_ua_wluns.part.0+0x4d/0x92
>> [?? 34.099456]? ufshcd_err_handler+0x97a/0x9ff
>> [?? 34.099902]? process_one_work+0x1cc/0x360
>> [?? 34.100384]? worker_thread+0x45/0x3b0
>> [?? 34.100851]? ? process_one_work+0x360/0x360
>> [?? 34.101308]? kthread+0xf6/0x130
>> [?? 34.101728]? ? kthread_park+0x80/0x80
>> [?? 34.102186]? ret_from_fork+0x1f/0x30
>>
>> [?? 34.640751] task:kworker/u10:9?? state:D stack:14528 pid:? 255 ppid:???? 2 flags:0x00004000
>> [?? 34.641253] Workqueue: events_unbound async_run_entry_fn
>> [?? 34.641722] Call Trace:
>> [?? 34.642217]? __schedule+0x275/0x6c0
>> [?? 34.642683]? schedule+0x41/0xa0
>> [?? 34.643179]? schedule_timeout+0x18b/0x290
>> [?? 34.643645]? ? del_timer_sync+0x30/0x30
>> [?? 34.644131]? __down_timeout+0x6b/0xc0
>> [?? 34.644568]? ? ufshcd_clkscale_enable_show+0x20/0x20
>> [?? 34.645014]? ? async_schedule_node_domain+0x17d/0x190
>> [?? 34.645496]? down_timeout+0x42/0x50
>> [?? 34.645947]? ufshcd_wl_suspend+0x79/0xa0
>> [?? 34.646432]? ? scmd_printk+0x100/0x100
>> [?? 34.646917]? scsi_bus_suspend_common+0x56/0xc0
>> [?? 34.647405]? ? scsi_bus_freeze+0x10/0x10
>> [?? 34.647858]? dpm_run_callback+0x45/0x110
>> [?? 34.648347]? __device_suspend+0x117/0x460
>> [?? 34.648788]? async_suspend+0x16/0x90
>> [?? 34.649251]? async_run_entry_fn+0x26/0x110
>> [?? 34.649676]? process_one_work+0x1cc/0x360
>> [?? 34.650137]? worker_thread+0x45/0x3b0
>> [?? 34.650563]? ? process_one_work+0x360/0x360
>> [?? 34.650994]? kthread+0xf6/0x130
>> [?? 34.651455]? ? kthread_park+0x80/0x80
>> [?? 34.651882]? ret_from_fork+0x1f/0x30
>>
>>
>>
>>>
>>>>
>>>> I'll address the other comments in the next version.
>>>>
>>>>
>>>> Thank you!
>>>>
>>>>>> -??? pm_runtime_put(hba->dev);
>>>>>> +??? ufshcd_rpm_put(hba);
>>>>>> ?? }
>>>>>
>>>>> <SNIP>
>>>>>
>>>>>> +void ufshcd_resume_complete(struct device *dev)
>>>>>> +{
>>>>
>>>
>>
> 
> 



From sean.wang at kernel.org  Fri Apr 23 05:26:16 2021
From: sean.wang at kernel.org (Sean Wang)
Date: Thu, 22 Apr 2021 21:26:16 -0700
Subject: [PATCH v5] pinctrl: add rsel setting on MT8195
In-Reply-To: <20210422033559.29700-2-zhiyong.tao@mediatek.com>
References: <20210422033559.29700-1-zhiyong.tao@mediatek.com>
 <20210422033559.29700-2-zhiyong.tao@mediatek.com>
Message-ID: <CAGp9Lzof434sM0amt7q5wqJz79VpUJQchn64wrEX2wXM_zg8CA@mail.gmail.com>

HI Zhiyong,

We should insist on using "pinctrl: mediatek" as the prefix.

On Wed, Apr 21, 2021 at 8:36 PM Zhiyong Tao <zhiyong.tao at mediatek.com> wrote:
>
> This patch provides rsel setting on MT8195.
>
> Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
> ---
>  drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
>  .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
>  .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
>  drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
>  4 files changed, 62 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> index a7500e18bb1d..66608b8d346a 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
> @@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
>         PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
>  };
>
<snip>


From linux at roeck-us.net  Fri Apr 23 05:26:35 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 22 Apr 2021 21:26:35 -0700
Subject: [PATCH V7 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <AOUAdwCCDk8v*1Yj0s9Qo4qH.3.1619149686926.Hmail.wangqing@vivo.com>
References: <AOUAdwCCDk8v*1Yj0s9Qo4qH.3.1619149686926.Hmail.wangqing@vivo.com>
Message-ID: <3acb9bb1-763b-5af7-de3c-d7d8d3f5b2f7@roeck-us.net>

On 4/22/21 8:48 PM, ?? wrote:
> 
>> On 4/22/21 7:53 PM, Wang Qing wrote:
>>> Use the bark interrupt as the pretimeout notifier if available.
>>>
>>> When the watchdog timer expires in dual mode, an interrupt will be
>>> triggered first, then the timing restarts. The reset signal will be
>>> initiated when the timer expires again.
>>>
>>> The pretimeout notification shall occur at timeout-sec/2.
>>>
>>> V2:
>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>
>>> V3:
>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>> - is processed and wait until timeout.
>>>
>>> V4:
>>> - Remove pretimeout related processing. 
>>> - Add dual mode control separately.
>>>
>>> V5:
>>> - Fix some formatting and printing problems.
>>>
>>> V6:
>>> - Realize pretimeout processing through dualmode.
>>>
>>> V7:
>>> - Add set_pretimeout().
>>>
>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>> ---
>>>  drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
>>>  1 file changed, 71 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>> index 97ca993..ab3ac5d
>>> --- a/drivers/watchdog/mtk_wdt.c
>>> +++ b/drivers/watchdog/mtk_wdt.c
>>> @@ -25,6 +25,7 @@
>>>  #include <linux/reset-controller.h>
>>>  #include <linux/types.h>
>>>  #include <linux/watchdog.h>
>>> +#include <linux/interrupt.h>
>>>  
>>>  #define WDT_MAX_TIMEOUT		31
>>>  #define WDT_MIN_TIMEOUT		1
>>> @@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>  {
>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>> +	unsigned int timeout_interval = timeout;
>>>  	u32 reg;
>>>  
>>>  	wdt_dev->timeout = timeout;
>>> -
>>> +	/*
>>> +	 * In dual mode, irq will be triggered at timeout / 2
>>> +	 * the real timeout occurs at timeout
>>> +	 */
>>> +	if (wdt_dev->pretimeout) {
>>> +		wdt_dev->pretimeout = timeout / 2;
>>
>> min_timeout is set to 1. I don't this works well if timeout == 1.
>> You'll either need to set min_timeout to 2, or handle that case.
> 
> It is appropriate to change min_timeout  to 2.
> 
>>
>>> +		timeout_interval = wdt_dev->pretimeout;
>>
>> timeout_interval is unnecessary. Just update timeout accordingly.
>> It needs to take the situation of timeout == 1 into account, though.
> 
> timeout represents the reset time. When the user calls timeout_show, 
> He hopes to get the configured timeout, not the value changed
> by pre-timeout.
> I modify it like this more in line with the original intention.
> 
>>
>>> +	}
>>>  	/*
>>>  	 * One bit is the value of 512 ticks
>>>  	 * The clock has 32 KHz
>>>  	 */
>>> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
>>> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>>>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>>>  
>>>  	mtk_wdt_ping(wdt_dev);
>>> @@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>  		return ret;
>>>  
>>>  	reg = ioread32(wdt_base + WDT_MODE);
>>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>> +	if (wdt_dev->pretimeout)
>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>> +	else
>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>>>  	iowrite32(reg, wdt_base + WDT_MODE);
>>>  
>>>  	return 0;
>>>  }
>>>  
>>> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
>>> +					unsigned int timeout)
>>> +{
>>> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
>>> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>> +	u32 reg = ioread32(wdt_base + WDT_MODE);
>>> +
>>> +	if (timeout && !wdd->pretimeout) {
>>> +		wdd->pretimeout = wdd->timeout / 2;
>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>> +	} else if (!timeout && wdd->pretimeout) {
>>> +		wdd->pretimeout = 0;
>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>> +	} else
>>> +		return 0;
>>> +
>>> +	iowrite32(reg, wdt_base + WDT_MODE);
>>
>> What is the point of setting the mode here ? It will
>> be set again in mtk_wdt_set_timeout(). Seems to me all
>> you need to do here is to set wdd->pretimeout,
>> then call mtk_wdt_set_timeout().
> 
> mtk_wdt_set_timeout() only set timeout and ping().
> Here also need to config to the dualmode or not.
> 
Ah, you are correct. Sorry, I confused this with the start function.
That makes me wonder if it would be better to extract a separate
function, mtk_wdt_set_mode(), for that purpose. Thoughts ?

Thanks,
Guenter

> Thanks,
> Qing
>>
>> Guenter
>>
>>> +
>>> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
>>> +}
>>> +
>>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
>>> +{
>>> +	struct watchdog_device *wdd = arg;
>>> +
>>> +	watchdog_notify_pretimeout(wdd);
>>> +
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>>  static const struct watchdog_info mtk_wdt_info = {
>>>  	.identity	= DRV_NAME,
>>>  	.options	= WDIOF_SETTIMEOUT |
>>> @@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
>>>  			  WDIOF_MAGICCLOSE,
>>>  };
>>>  
>>> +static const struct watchdog_info mtk_wdt_pt_info = {
>>> +	.identity	= DRV_NAME,
>>> +	.options	= WDIOF_SETTIMEOUT |
>>> +			  WDIOF_PRETIMEOUT |
>>> +			  WDIOF_KEEPALIVEPING |
>>> +			  WDIOF_MAGICCLOSE,
>>> +};
>>> +
>>>  static const struct watchdog_ops mtk_wdt_ops = {
>>>  	.owner		= THIS_MODULE,
>>>  	.start		= mtk_wdt_start,
>>>  	.stop		= mtk_wdt_stop,
>>>  	.ping		= mtk_wdt_ping,
>>>  	.set_timeout	= mtk_wdt_set_timeout,
>>> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>>>  	.restart	= mtk_wdt_restart,
>>>  };
>>>  
>>> @@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>>  	struct device *dev = &pdev->dev;
>>>  	struct mtk_wdt_dev *mtk_wdt;
>>>  	const struct mtk_wdt_data *wdt_data;
>>> -	int err;
>>> +	int err, irq;
>>>  
>>>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>>>  	if (!mtk_wdt)
>>> @@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>>  	if (IS_ERR(mtk_wdt->wdt_base))
>>>  		return PTR_ERR(mtk_wdt->wdt_base);
>>>  
>>> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>>> +	irq = platform_get_irq(pdev, 0);
>>> +	if (irq > 0) {
>>> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
>>> +					&mtk_wdt->wdt_dev);
>>> +		if (err)
>>> +			return err;
>>> +
>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
>>> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
>>> +	} else {
>>> +		if (irq == -EPROBE_DEFER)
>>> +			return -EPROBE_DEFER;
>>> +
>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>>> +	}
>>> +
>>>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>>>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>>>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
>>>
>>
> 
> 



From o.rempel at pengutronix.de  Fri Apr 23 05:37:29 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Fri, 23 Apr 2021 06:37:29 +0200
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
Message-ID: <20210423043729.tup7nntmmyv6vurm@pengutronix.de>

Hi Joakim,

On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
> 
> Hi Oleksij,
> 
> I look both stmmac selftest code and this patch set. For stmmac, if PHY doesn't support loopback, it will fallthrough to MAC loopback.
> You provide this generic net selftest support based on PHY loopback, I have a question, is it possible to extend it also support MAC loopback later?

Yes. If you have interest and time to implement it, please do.
It should be some kind of generic callback as phy_loopback() and if PHY
and MAC loopbacks are supported we need to tests both variants.

Best regards,
Oleksij

> > -----Original Message-----
> > From: Oleksij Rempel <o.rempel at pengutronix.de>
> > Sent: 2021?4?19? 21:01
> > To: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> > <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian Fainelli
> > <f.fainelli at gmail.com>; Heiner Kallweit <hkallweit1 at gmail.com>; Fugang
> > Duan <fugang.duan at nxp.com>
> > Cc: Oleksij Rempel <o.rempel at pengutronix.de>; kernel at pengutronix.de;
> > netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
> > Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>; Russell
> > King <linux at armlinux.org.uk>; Philippe Schenker
> > <philippe.schenker at toradex.com>
> > Subject: [PATCH net-next v3 0/6] provide generic net selftest support
> > 
> > changes v3:
> > - make more granular tests
> > - enable loopback for all PHYs by default
> > - fix allmodconfig build errors
> > - poll for link status update after switching to the loopback mode
> > 
> > changes v2:
> > - make generic selftests available for all networking devices.
> > - make use of net_selftest* on FEC, ag71xx and all DSA switches.
> > - add loopback support on more PHYs.
> > 
> > This patch set provides diagnostic capabilities for some iMX, ag71xx or any DSA
> > based devices. For proper functionality, PHY loopback support is needed.
> > So far there is only initial infrastructure with basic tests.
> > 
> > Oleksij Rempel (6):
> >   net: phy: execute genphy_loopback() per default on all PHYs
> >   net: phy: genphy_loopback: add link speed configuration
> >   net: add generic selftest support
> >   net: fec: make use of generic NET_SELFTESTS library
> >   net: ag71xx: make use of generic NET_SELFTESTS library
> >   net: dsa: enable selftest support for all switches by default
> > 
> >  drivers/net/ethernet/atheros/Kconfig      |   1 +
> >  drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
> >  drivers/net/ethernet/freescale/Kconfig    |   1 +
> >  drivers/net/ethernet/freescale/fec_main.c |   7 +
> >  drivers/net/phy/phy.c                     |   3 +-
> >  drivers/net/phy/phy_device.c              |  35 +-
> >  include/linux/phy.h                       |   1 +
> >  include/net/dsa.h                         |   2 +
> >  include/net/selftests.h                   |  12 +
> >  net/Kconfig                               |   4 +
> >  net/core/Makefile                         |   1 +
> >  net/core/selftests.c                      | 400
> > ++++++++++++++++++++++
> >  net/dsa/Kconfig                           |   1 +
> >  net/dsa/slave.c                           |  21 ++
> >  14 files changed, 500 insertions(+), 9 deletions(-)  create mode 100644
> > include/net/selftests.h  create mode 100644 net/core/selftests.c
> > 
> > --
> > 2.29.2
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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 ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:02 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:02 -0700
Subject: [PATCH net-next v2 09/15] net: ethernet: mtk_eth_soc: implement
 dynamic interrupt moderation
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-10-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Reduces the number of interrupts under load

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: add documentation for new struct fields]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/Kconfig       |  1 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 96 +++++++++++++++++++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 41 +++++++--
 3 files changed, 124 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
index 08c2e446d3d5..c357c193378e 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -11,6 +11,7 @@ config NET_MEDIATEK_SOC
 	tristate "MediaTek SoC Gigabit Ethernet support"
 	depends on NET_DSA || !NET_DSA
 	select PHYLINK
+	select DIMLIB
 	help
 	  This driver supports the gigabit ethernet MACs in the
 	  MediaTek SoC family.
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 645360cfdfe9..762e985fa294 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1233,12 +1233,13 @@ static void mtk_update_rx_cpu_idx(struct mtk_eth *eth)
 static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		       struct mtk_eth *eth)
 {
+	struct dim_sample dim_sample = {};
 	struct mtk_rx_ring *ring;
 	int idx;
 	struct sk_buff *skb;
 	u8 *data, *new_data;
 	struct mtk_rx_dma *rxd, trxd;
-	int done = 0;
+	int done = 0, bytes = 0;
 
 	while (done < budget) {
 		struct net_device *netdev;
@@ -1312,6 +1313,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		else
 			skb_checksum_none_assert(skb);
 		skb->protocol = eth_type_trans(skb, netdev);
+		bytes += pktlen;
 
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
 		    (trxd.rxd2 & RX_DMA_VTAG))
@@ -1344,6 +1346,12 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		mtk_update_rx_cpu_idx(eth);
 	}
 
+	eth->rx_packets += done;
+	eth->rx_bytes += bytes;
+	dim_update_sample(eth->rx_events, eth->rx_packets, eth->rx_bytes,
+			  &dim_sample);
+	net_dim(&eth->rx_dim, dim_sample);
+
 	return done;
 }
 
@@ -1436,6 +1444,7 @@ static int mtk_poll_tx_pdma(struct mtk_eth *eth, int budget,
 static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 {
 	struct mtk_tx_ring *ring = &eth->tx_ring;
+	struct dim_sample dim_sample = {};
 	unsigned int done[MTK_MAX_DEVS];
 	unsigned int bytes[MTK_MAX_DEVS];
 	int total = 0, i;
@@ -1453,8 +1462,14 @@ static int mtk_poll_tx(struct mtk_eth *eth, int budget)
 			continue;
 		netdev_completed_queue(eth->netdev[i], done[i], bytes[i]);
 		total += done[i];
+		eth->tx_packets += done[i];
+		eth->tx_bytes += bytes[i];
 	}
 
+	dim_update_sample(eth->tx_events, eth->tx_packets, eth->tx_bytes,
+			  &dim_sample);
+	net_dim(&eth->tx_dim, dim_sample);
+
 	if (mtk_queue_stopped(eth) &&
 	    (atomic_read(&ring->free_count) > ring->thresh))
 		mtk_wake_queue(eth);
@@ -2129,6 +2144,7 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
 {
 	struct mtk_eth *eth = _eth;
 
+	eth->rx_events++;
 	if (likely(napi_schedule_prep(&eth->rx_napi))) {
 		__napi_schedule(&eth->rx_napi);
 		mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
@@ -2141,6 +2157,7 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
 {
 	struct mtk_eth *eth = _eth;
 
+	eth->tx_events++;
 	if (likely(napi_schedule_prep(&eth->tx_napi))) {
 		__napi_schedule(&eth->tx_napi);
 		mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
@@ -2325,6 +2342,9 @@ static int mtk_stop(struct net_device *dev)
 	napi_disable(&eth->tx_napi);
 	napi_disable(&eth->rx_napi);
 
+	cancel_work_sync(&eth->rx_dim.work);
+	cancel_work_sync(&eth->tx_dim.work);
+
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
 		mtk_stop_dma(eth, MTK_QDMA_GLO_CFG);
 	mtk_stop_dma(eth, MTK_PDMA_GLO_CFG);
@@ -2377,6 +2397,64 @@ static int mtk_clk_enable(struct mtk_eth *eth)
 	return ret;
 }
 
+static void mtk_dim_rx(struct work_struct *work)
+{
+	struct dim *dim = container_of(work, struct dim, work);
+	struct mtk_eth *eth = container_of(dim, struct mtk_eth, rx_dim);
+	struct dim_cq_moder cur_profile;
+	u32 val, cur;
+
+	cur_profile = net_dim_get_rx_moderation(eth->rx_dim.mode,
+						dim->profile_ix);
+	spin_lock_bh(&eth->dim_lock);
+
+	val = mtk_r32(eth, MTK_PDMA_DELAY_INT);
+	val &= MTK_PDMA_DELAY_TX_MASK;
+	val |= MTK_PDMA_DELAY_RX_EN;
+
+	cur = min_t(u32, DIV_ROUND_UP(cur_profile.usec, 20), MTK_PDMA_DELAY_PTIME_MASK);
+	val |= cur << MTK_PDMA_DELAY_RX_PTIME_SHIFT;
+
+	cur = min_t(u32, cur_profile.pkts, MTK_PDMA_DELAY_PINT_MASK);
+	val |= cur << MTK_PDMA_DELAY_RX_PINT_SHIFT;
+
+	mtk_w32(eth, val, MTK_PDMA_DELAY_INT);
+	mtk_w32(eth, val, MTK_QDMA_DELAY_INT);
+
+	spin_unlock_bh(&eth->dim_lock);
+
+	dim->state = DIM_START_MEASURE;
+}
+
+static void mtk_dim_tx(struct work_struct *work)
+{
+	struct dim *dim = container_of(work, struct dim, work);
+	struct mtk_eth *eth = container_of(dim, struct mtk_eth, tx_dim);
+	struct dim_cq_moder cur_profile;
+	u32 val, cur;
+
+	cur_profile = net_dim_get_tx_moderation(eth->tx_dim.mode,
+						dim->profile_ix);
+	spin_lock_bh(&eth->dim_lock);
+
+	val = mtk_r32(eth, MTK_PDMA_DELAY_INT);
+	val &= MTK_PDMA_DELAY_RX_MASK;
+	val |= MTK_PDMA_DELAY_TX_EN;
+
+	cur = min_t(u32, DIV_ROUND_UP(cur_profile.usec, 20), MTK_PDMA_DELAY_PTIME_MASK);
+	val |= cur << MTK_PDMA_DELAY_TX_PTIME_SHIFT;
+
+	cur = min_t(u32, cur_profile.pkts, MTK_PDMA_DELAY_PINT_MASK);
+	val |= cur << MTK_PDMA_DELAY_TX_PINT_SHIFT;
+
+	mtk_w32(eth, val, MTK_PDMA_DELAY_INT);
+	mtk_w32(eth, val, MTK_QDMA_DELAY_INT);
+
+	spin_unlock_bh(&eth->dim_lock);
+
+	dim->state = DIM_START_MEASURE;
+}
+
 static int mtk_hw_init(struct mtk_eth *eth)
 {
 	int i, val, ret;
@@ -2398,9 +2476,6 @@ static int mtk_hw_init(struct mtk_eth *eth)
 			goto err_disable_pm;
 		}
 
-		/* enable interrupt delay for RX */
-		mtk_w32(eth, MTK_PDMA_DELAY_RX_DELAY, MTK_PDMA_DELAY_INT);
-
 		/* disable delay and normal interrupt */
 		mtk_tx_irq_disable(eth, ~0);
 		mtk_rx_irq_disable(eth, ~0);
@@ -2439,11 +2514,11 @@ static int mtk_hw_init(struct mtk_eth *eth)
 	/* Enable RX VLan Offloading */
 	mtk_w32(eth, 1, MTK_CDMP_EG_CTRL);
 
-	/* enable interrupt delay for RX */
-	mtk_w32(eth, MTK_PDMA_DELAY_RX_DELAY, MTK_PDMA_DELAY_INT);
+	/* set interrupt delays based on current Net DIM sample */
+	mtk_dim_rx(&eth->rx_dim.work);
+	mtk_dim_tx(&eth->tx_dim.work);
 
 	/* disable delay and normal interrupt */
-	mtk_w32(eth, 0, MTK_QDMA_DELAY_INT);
 	mtk_tx_irq_disable(eth, ~0);
 	mtk_rx_irq_disable(eth, ~0);
 
@@ -2978,6 +3053,13 @@ static int mtk_probe(struct platform_device *pdev)
 	spin_lock_init(&eth->page_lock);
 	spin_lock_init(&eth->tx_irq_lock);
 	spin_lock_init(&eth->rx_irq_lock);
+	spin_lock_init(&eth->dim_lock);
+
+	eth->rx_dim.mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+	INIT_WORK(&eth->rx_dim.work, mtk_dim_rx);
+
+	eth->tx_dim.mode = DIM_CQ_PERIOD_MODE_START_FROM_EQE;
+	INIT_WORK(&eth->tx_dim.work, mtk_dim_tx);
 
 	if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
 		eth->ethsys = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 540a5771b7bf..ceb5a4a661e6 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -16,6 +16,7 @@
 #include <linux/refcount.h>
 #include <linux/phylink.h>
 #include <linux/rhashtable.h>
+#include <linux/dim.h>
 #include "mtk_ppe.h"
 
 #define MTK_QDMA_PAGE_SIZE	2048
@@ -137,13 +138,18 @@
 
 /* PDMA Delay Interrupt Register */
 #define MTK_PDMA_DELAY_INT		0xa0c
+#define MTK_PDMA_DELAY_RX_MASK		GENMASK(15, 0)
 #define MTK_PDMA_DELAY_RX_EN		BIT(15)
-#define MTK_PDMA_DELAY_RX_PINT		4
 #define MTK_PDMA_DELAY_RX_PINT_SHIFT	8
-#define MTK_PDMA_DELAY_RX_PTIME		4
-#define MTK_PDMA_DELAY_RX_DELAY		\
-	(MTK_PDMA_DELAY_RX_EN | MTK_PDMA_DELAY_RX_PTIME | \
-	(MTK_PDMA_DELAY_RX_PINT << MTK_PDMA_DELAY_RX_PINT_SHIFT))
+#define MTK_PDMA_DELAY_RX_PTIME_SHIFT	0
+
+#define MTK_PDMA_DELAY_TX_MASK		GENMASK(31, 16)
+#define MTK_PDMA_DELAY_TX_EN		BIT(31)
+#define MTK_PDMA_DELAY_TX_PINT_SHIFT	24
+#define MTK_PDMA_DELAY_TX_PTIME_SHIFT	16
+
+#define MTK_PDMA_DELAY_PINT_MASK	0x7f
+#define MTK_PDMA_DELAY_PTIME_MASK	0xff
 
 /* PDMA Interrupt Status Register */
 #define MTK_PDMA_INT_STATUS	0xa20
@@ -225,6 +231,7 @@
 /* QDMA Interrupt Status Register */
 #define MTK_QDMA_INT_STATUS	0x1A18
 #define MTK_RX_DONE_DLY		BIT(30)
+#define MTK_TX_DONE_DLY		BIT(28)
 #define MTK_RX_DONE_INT3	BIT(19)
 #define MTK_RX_DONE_INT2	BIT(18)
 #define MTK_RX_DONE_INT1	BIT(17)
@@ -234,8 +241,7 @@
 #define MTK_TX_DONE_INT1	BIT(1)
 #define MTK_TX_DONE_INT0	BIT(0)
 #define MTK_RX_DONE_INT		MTK_RX_DONE_DLY
-#define MTK_TX_DONE_INT		(MTK_TX_DONE_INT0 | MTK_TX_DONE_INT1 | \
-				 MTK_TX_DONE_INT2 | MTK_TX_DONE_INT3)
+#define MTK_TX_DONE_INT		MTK_TX_DONE_DLY
 
 /* QDMA Interrupt grouping registers */
 #define MTK_QDMA_INT_GRP1	0x1a20
@@ -849,6 +855,7 @@ struct mtk_sgmii {
  * @page_lock:		Make sure that register operations are atomic
  * @tx_irq__lock:	Make sure that IRQ register operations are atomic
  * @rx_irq__lock:	Make sure that IRQ register operations are atomic
+ * @dim_lock:		Make sure that Net DIM operations are atomic
  * @dummy_dev:		we run 2 netdevs on 1 physical DMA ring and need a
  *			dummy for NAPI to work
  * @netdev:		The netdev instances
@@ -867,6 +874,14 @@ struct mtk_sgmii {
  * @rx_ring_qdma:	Pointer to the memory holding info about the QDMA RX ring
  * @tx_napi:		The TX NAPI struct
  * @rx_napi:		The RX NAPI struct
+ * @rx_events:		Net DIM RX event counter
+ * @rx_packets:		Net DIM RX packet counter
+ * @rx_bytes:		Net DIM RX byte counter
+ * @rx_dim:		Net DIM RX context
+ * @tx_events:		Net DIM TX event counter
+ * @tx_packets:		Net DIM TX packet counter
+ * @tx_bytes:		Net DIM TX byte counter
+ * @tx_dim:		Net DIM TX context
  * @scratch_ring:	Newer SoCs need memory for a second HW managed TX ring
  * @phy_scratch_ring:	physical address of scratch_ring
  * @scratch_head:	The scratch memory that scratch_ring points to.
@@ -911,6 +926,18 @@ struct mtk_eth {
 
 	const struct mtk_soc_data	*soc;
 
+	spinlock_t			dim_lock;
+
+	u32				rx_events;
+	u32				rx_packets;
+	u32				rx_bytes;
+	struct dim			rx_dim;
+
+	u32				tx_events;
+	u32				tx_packets;
+	u32				tx_bytes;
+	struct dim			tx_dim;
+
 	u32				tx_int_mask_reg;
 	u32				tx_int_status_reg;
 	u32				rx_dma_l4_valid;
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:53 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:53 -0700
Subject: [PATCH net-next v2 00/15] mtk_eth_soc: fixes and performance
 improvements
Message-ID: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>

Most of these changes come from OpenWrt where they have been present and
tested for months.

First three patches are bug fixes. The rest are performance
improvements. The last patch is a cleanup to use the iopoll.h macro for
busy-waiting instead of a custom loop.

v2:
 - Reverse christmas tree in "use iopoll.h macro for DMA init"
 - Use cond_resched() instead of iopoll.h macro in "reduce MDIO bus
   access latency"
 - Use napi_complete_done and rework NAPI callbacks in a new patch

Felix Fietkau (12):
  net: ethernet: mtk_eth_soc: fix RX VLAN offload
  net: ethernet: mtk_eth_soc: unmap RX data before calling build_skb
  net: ethernet: mtk_eth_soc: use napi_consume_skb
  net: ethernet: mtk_eth_soc: reduce MDIO bus access latency
  net: ethernet: mtk_eth_soc: remove unnecessary TX queue stops
  net: ethernet: mtk_eth_soc: use larger burst size for QDMA TX
  net: ethernet: mtk_eth_soc: increase DMA ring sizes
  net: ethernet: mtk_eth_soc: implement dynamic interrupt moderation
  net: ethernet: mtk_eth_soc: cache HW pointer of last freed TX
    descriptor
  net: ethernet: mtk_eth_soc: only read the full RX descriptor if DMA is
    done
  net: ethernet: mtk_eth_soc: reduce unnecessary interrupts
  net: ethernet: mtk_eth_soc: set PPE flow hash as skb hash if present

Ilya Lipnitskiy (3):
  net: ethernet: mtk_eth_soc: fix build_skb cleanup
  net: ethernet: mtk_eth_soc: rework NAPI callbacks
  net: ethernet: mtk_eth_soc: use iopoll.h macro for DMA init

 drivers/net/ethernet/mediatek/Kconfig       |   1 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 262 +++++++++++++-------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  50 +++-
 3 files changed, 213 insertions(+), 100 deletions(-)

-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:59 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:59 -0700
Subject: [PATCH net-next v2 06/15] net: ethernet: mtk_eth_soc: remove
 unnecessary TX queue stops
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-7-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

When running short on descriptors, only stop the queue for the netdev that
tx was attempted for. By the time something tries to send on the other
netdev, the ring might have some more room already.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d992d4f1f400..e6f832dde9a6 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1131,17 +1131,6 @@ static void mtk_wake_queue(struct mtk_eth *eth)
 	}
 }
 
-static void mtk_stop_queue(struct mtk_eth *eth)
-{
-	int i;
-
-	for (i = 0; i < MTK_MAC_COUNT; i++) {
-		if (!eth->netdev[i])
-			continue;
-		netif_stop_queue(eth->netdev[i]);
-	}
-}
-
 static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct mtk_mac *mac = netdev_priv(dev);
@@ -1162,7 +1151,7 @@ static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	tx_num = mtk_cal_txd_req(skb);
 	if (unlikely(atomic_read(&ring->free_count) <= tx_num)) {
-		mtk_stop_queue(eth);
+		netif_stop_queue(dev);
 		netif_err(eth, tx_queued, dev,
 			  "Tx Ring full when queue awake!\n");
 		spin_unlock(&eth->page_lock);
@@ -1188,7 +1177,7 @@ static netdev_tx_t mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	if (unlikely(atomic_read(&ring->free_count) <= ring->thresh))
-		mtk_stop_queue(eth);
+		netif_stop_queue(dev);
 
 	spin_unlock(&eth->page_lock);
 
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:55 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:55 -0700
Subject: [PATCH net-next v2 02/15] net: ethernet: mtk_eth_soc: unmap RX data
 before calling build_skb
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-3-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Since build_skb accesses the data area (for initializing shinfo), dma unmap
needs to happen before that call

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: split build_skb cleanup fix into a separate commit]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b2175ec451ab..540003f3fcb8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1298,6 +1298,9 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 			goto release_desc;
 		}
 
+		dma_unmap_single(eth->dev, trxd.rxd1,
+				 ring->buf_size, DMA_FROM_DEVICE);
+
 		/* receive data */
 		skb = build_skb(data, ring->frag_size);
 		if (unlikely(!skb)) {
@@ -1307,8 +1310,6 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		}
 		skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
 
-		dma_unmap_single(eth->dev, trxd.rxd1,
-				 ring->buf_size, DMA_FROM_DEVICE);
 		pktlen = RX_DMA_GET_PLEN0(trxd.rxd2);
 		skb->dev = netdev;
 		skb_put(skb, pktlen);
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:06 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:06 -0700
Subject: [PATCH net-next v2 13/15] net: ethernet: mtk_eth_soc: rework NAPI
 callbacks
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-14-ilya.lipnitskiy@gmail.com>

Use napi_complete_done to communicate total TX and RX work done to NAPI.
Count total RX work up instead of remaining work down for clarity.
Remove unneeded local variables for clarity. Use do {} while instead of
goto for clarity.

Suggested-by: Jakub Kicinski <kuba at kernel.org>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 54 +++++++++------------
 1 file changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e1792ccaedc3..8faf8fb1c83a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1496,7 +1496,6 @@ static void mtk_handle_status_irq(struct mtk_eth *eth)
 static int mtk_napi_tx(struct napi_struct *napi, int budget)
 {
 	struct mtk_eth *eth = container_of(napi, struct mtk_eth, tx_napi);
-	u32 status, mask;
 	int tx_done = 0;
 
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
@@ -1505,21 +1504,19 @@ static int mtk_napi_tx(struct napi_struct *napi, int budget)
 	tx_done = mtk_poll_tx(eth, budget);
 
 	if (unlikely(netif_msg_intr(eth))) {
-		status = mtk_r32(eth, eth->tx_int_status_reg);
-		mask = mtk_r32(eth, eth->tx_int_mask_reg);
 		dev_info(eth->dev,
-			 "done tx %d, intr 0x%08x/0x%x\n",
-			 tx_done, status, mask);
+			 "done tx %d, intr 0x%08x/0x%x\n", tx_done,
+			 mtk_r32(eth, eth->tx_int_status_reg),
+			 mtk_r32(eth, eth->tx_int_mask_reg));
 	}
 
 	if (tx_done == budget)
 		return budget;
 
-	status = mtk_r32(eth, eth->tx_int_status_reg);
-	if (status & MTK_TX_DONE_INT)
+	if (mtk_r32(eth, eth->tx_int_status_reg) & MTK_TX_DONE_INT)
 		return budget;
 
-	if (napi_complete(napi))
+	if (napi_complete_done(napi, tx_done))
 		mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
 
 	return tx_done;
@@ -1528,36 +1525,33 @@ static int mtk_napi_tx(struct napi_struct *napi, int budget)
 static int mtk_napi_rx(struct napi_struct *napi, int budget)
 {
 	struct mtk_eth *eth = container_of(napi, struct mtk_eth, rx_napi);
-	u32 status, mask;
-	int rx_done = 0;
-	int remain_budget = budget;
+	int rx_done_total = 0;
 
 	mtk_handle_status_irq(eth);
 
-poll_again:
-	mtk_w32(eth, MTK_RX_DONE_INT, MTK_PDMA_INT_STATUS);
-	rx_done = mtk_poll_rx(napi, remain_budget, eth);
+	do {
+		int rx_done;
 
-	if (unlikely(netif_msg_intr(eth))) {
-		status = mtk_r32(eth, MTK_PDMA_INT_STATUS);
-		mask = mtk_r32(eth, MTK_PDMA_INT_MASK);
-		dev_info(eth->dev,
-			 "done rx %d, intr 0x%08x/0x%x\n",
-			 rx_done, status, mask);
-	}
-	if (rx_done == remain_budget)
-		return budget;
+		mtk_w32(eth, MTK_RX_DONE_INT, MTK_PDMA_INT_STATUS);
+		rx_done = mtk_poll_rx(napi, budget - rx_done_total, eth);
+		rx_done_total += rx_done;
 
-	status = mtk_r32(eth, MTK_PDMA_INT_STATUS);
-	if (status & MTK_RX_DONE_INT) {
-		remain_budget -= rx_done;
-		goto poll_again;
-	}
+		if (unlikely(netif_msg_intr(eth))) {
+			dev_info(eth->dev,
+				 "done rx %d, intr 0x%08x/0x%x\n", rx_done,
+				 mtk_r32(eth, MTK_PDMA_INT_STATUS),
+				 mtk_r32(eth, MTK_PDMA_INT_MASK));
+		}
+
+		if (rx_done_total == budget)
+			return budget;
+
+	} while (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT);
 
-	if (napi_complete(napi))
+	if (napi_complete_done(napi, rx_done_total))
 		mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
 
-	return rx_done + budget - remain_budget;
+	return rx_done_total;
 }
 
 static int mtk_tx_alloc(struct mtk_eth *eth)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:58 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:58 -0700
Subject: [PATCH net-next v2 05/15] net: ethernet: mtk_eth_soc: reduce MDIO bus
 access latency
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-6-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

usleep_range often ends up sleeping much longer than the 10-20us provided
as a range here. This causes significant latency in mdio bus acceses,
which easily adds multiple seconds to the boot time on MT7621 when polling
DSA slave ports.
Use cond_resched instead of usleep_range, since the MDIO access does not
take much time

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 5cf64de3ddf8..d992d4f1f400 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -86,7 +86,7 @@ static int mtk_mdio_busy_wait(struct mtk_eth *eth)
 			return 0;
 		if (time_after(jiffies, t_start + PHY_IAC_TIMEOUT))
 			break;
-		usleep_range(10, 20);
+		cond_resched();
 	}
 
 	dev_err(eth->dev, "mdio: MDIO timeout\n");
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:54 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:54 -0700
Subject: [PATCH net-next v2 01/15] net: ethernet: mtk_eth_soc: fix RX VLAN
 offload
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-2-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is
set. Fixes frames wrongly marked with VLAN tags.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: fix commit message]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6b00c12c6c43..b2175ec451ab 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1319,7 +1319,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb->protocol = eth_type_trans(skb, netdev);
 
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
-		    RX_DMA_VID(trxd.rxd3))
+		    (trxd.rxd2 & RX_DMA_VTAG))
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
 					       RX_DMA_VID(trxd.rxd3));
 		skb_record_rx_queue(skb, 0);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 1a6750c08bb9..875e67b41561 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -301,6 +301,7 @@
 #define RX_DMA_LSO		BIT(30)
 #define RX_DMA_PLEN0(_x)	(((_x) & 0x3fff) << 16)
 #define RX_DMA_GET_PLEN0(_x)	(((_x) >> 16) & 0x3fff)
+#define RX_DMA_VTAG		BIT(15)
 
 /* QDMA descriptor rxd3 */
 #define RX_DMA_VID(_x)		((_x) & 0xfff)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:57 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:57 -0700
Subject: [PATCH net-next v2 04/15] net: ethernet: mtk_eth_soc: use
 napi_consume_skb
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-5-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Should improve performance, since it can use bulk free

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 07daa5de8bec..5cf64de3ddf8 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -858,7 +858,8 @@ static int txd_to_idx(struct mtk_tx_ring *ring, struct mtk_tx_dma *dma)
 	return ((void *)dma - (void *)ring->dma) / sizeof(*dma);
 }
 
-static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf)
+static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf,
+			 bool napi)
 {
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
 		if (tx_buf->flags & MTK_TX_FLAGS_SINGLE0) {
@@ -890,8 +891,12 @@ static void mtk_tx_unmap(struct mtk_eth *eth, struct mtk_tx_buf *tx_buf)
 
 	tx_buf->flags = 0;
 	if (tx_buf->skb &&
-	    (tx_buf->skb != (struct sk_buff *)MTK_DMA_DUMMY_DESC))
-		dev_kfree_skb_any(tx_buf->skb);
+	    (tx_buf->skb != (struct sk_buff *)MTK_DMA_DUMMY_DESC)) {
+		if (napi)
+			napi_consume_skb(tx_buf->skb, napi);
+		else
+			dev_kfree_skb_any(tx_buf->skb);
+	}
 	tx_buf->skb = NULL;
 }
 
@@ -1069,7 +1074,7 @@ static int mtk_tx_map(struct sk_buff *skb, struct net_device *dev,
 		tx_buf = mtk_desc_to_tx_buf(ring, itxd);
 
 		/* unmap dma */
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, false);
 
 		itxd->txd3 = TX_DMA_LS0 | TX_DMA_OWNER_CPU;
 		if (!MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
@@ -1388,7 +1393,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 			done[mac]++;
 			budget--;
 		}
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, true);
 
 		ring->last_free = desc;
 		atomic_inc(&ring->free_count);
@@ -1425,7 +1430,7 @@ static int mtk_poll_tx_pdma(struct mtk_eth *eth, int budget,
 			budget--;
 		}
 
-		mtk_tx_unmap(eth, tx_buf);
+		mtk_tx_unmap(eth, tx_buf, true);
 
 		desc = &ring->dma[cpu];
 		ring->last_free = desc;
@@ -1627,7 +1632,7 @@ static void mtk_tx_clean(struct mtk_eth *eth)
 
 	if (ring->buf) {
 		for (i = 0; i < MTK_DMA_SIZE; i++)
-			mtk_tx_unmap(eth, &ring->buf[i]);
+			mtk_tx_unmap(eth, &ring->buf[i], false);
 		kfree(ring->buf);
 		ring->buf = NULL;
 	}
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:07 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:07 -0700
Subject: [PATCH net-next v2 14/15] net: ethernet: mtk_eth_soc: set PPE flow
 hash as skb hash if present
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-15-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

This improves GRO performance

Signed-off-by: Felix Fietkau <nbd at nbd.name>
[Ilya: Use MTK_RXD4_FOE_ENTRY instead of GENMASK(13, 0)]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8faf8fb1c83a..37e50a2e7d0e 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -19,6 +19,7 @@
 #include <linux/interrupt.h>
 #include <linux/pinctrl/devinfo.h>
 #include <linux/phylink.h>
+#include <linux/jhash.h>
 #include <net/dsa.h>
 
 #include "mtk_eth_soc.h"
@@ -1250,6 +1251,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		struct net_device *netdev;
 		unsigned int pktlen;
 		dma_addr_t dma_addr;
+		u32 hash;
 		int mac;
 
 		ring = mtk_get_rx_ring(eth);
@@ -1319,6 +1321,12 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb->protocol = eth_type_trans(skb, netdev);
 		bytes += pktlen;
 
+		hash = trxd.rxd4 & MTK_RXD4_FOE_ENTRY;
+		if (hash != MTK_RXD4_FOE_ENTRY) {
+			hash = jhash_1word(hash, 0);
+			skb_set_hash(skb, hash, PKT_HASH_TYPE_L4);
+		}
+
 		if (netdev->features & NETIF_F_HW_VLAN_CTAG_RX &&
 		    (trxd.rxd2 & RX_DMA_VTAG))
 			__vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
-- 
2.31.1



From gregkh at linuxfoundation.org  Fri Apr 23 06:23:08 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 23 Apr 2021 07:23:08 +0200
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <1619148391.4048.6.camel@mhfsdcap03>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03> <YGq2YfURFApdJLxb@kroah.com>
 <1617675492.22435.4.camel@mhfsdcap03> <YIE3z7qYNtk7G/VB@kroah.com>
 <1619148391.4048.6.camel@mhfsdcap03>
Message-ID: <YIJZvN8py7s+Zq6I@kroah.com>

On Fri, Apr 23, 2021 at 11:26:31AM +0800, Chunfeng Yun wrote:
> On Thu, 2021-04-22 at 10:46 +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 06, 2021 at 10:18:12AM +0800, Chunfeng Yun wrote:
> > > On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> > > > On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > > > > cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> > > > > 
> > > > > I'll test it , thanks
> > > > 
> > > > Did you test this series and find any problems?  If not, I'll go queue
> > > > these up...
> > > Yes, found an issue on the start-split transaction, but not found the
> > > root cause yet :(
> > 
> > So you are objecting to these being merged at this point in time? 
> Yes
> 
> >  Can
> > you provide feedback to the author about what is wrong?
> Already provided feedback add discussed on issue tracker in private

That doesn't help us much as we can't see that :(

Please always keep us informed as to what is going on with publically
posted changes, otherwise you could find them being picked up and merged
into trees without an objection.

thanks,

greg k-h


From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:08 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:08 -0700
Subject: [PATCH net-next v2 15/15] net: ethernet: mtk_eth_soc: use iopoll.h
 macro for DMA init
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-16-ilya.lipnitskiy@gmail.com>

Replace a tight busy-wait loop without a pause with a standard
readx_poll_timeout_atomic routine with a 5 us poll period.

Tested by booting a MT7621 device to ensure the driver initializes
properly.

Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 29 +++++++++------------
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  2 +-
 2 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 37e50a2e7d0e..ed4eacef17ce 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2033,25 +2033,22 @@ static int mtk_set_features(struct net_device *dev, netdev_features_t features)
 /* wait for DMA to finish whatever it is doing before we start using it again */
 static int mtk_dma_busy_wait(struct mtk_eth *eth)
 {
-	unsigned long t_start = jiffies;
+	unsigned int reg;
+	int ret;
+	u32 val;
 
-	while (1) {
-		if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
-			if (!(mtk_r32(eth, MTK_QDMA_GLO_CFG) &
-			      (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)))
-				return 0;
-		} else {
-			if (!(mtk_r32(eth, MTK_PDMA_GLO_CFG) &
-			      (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)))
-				return 0;
-		}
+	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA))
+		reg = MTK_QDMA_GLO_CFG;
+	else
+		reg = MTK_PDMA_GLO_CFG;
 
-		if (time_after(jiffies, t_start + MTK_DMA_BUSY_TIMEOUT))
-			break;
-	}
+	ret = readx_poll_timeout_atomic(__raw_readl, eth->base + reg, val,
+					!(val & (MTK_RX_DMA_BUSY | MTK_TX_DMA_BUSY)),
+					5, MTK_DMA_BUSY_TIMEOUT_US);
+	if (ret)
+		dev_err(eth->dev, "DMA init timeout\n");
 
-	dev_err(eth->dev, "DMA init timeout\n");
-	return -1;
+	return ret;
 }
 
 static int mtk_dma_init(struct mtk_eth *eth)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 6b92dd6c2cda..11331b44ba07 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -214,7 +214,7 @@
 #define MTK_TX_DMA_BUSY		BIT(1)
 #define MTK_RX_DMA_EN		BIT(2)
 #define MTK_TX_DMA_EN		BIT(0)
-#define MTK_DMA_BUSY_TIMEOUT	HZ
+#define MTK_DMA_BUSY_TIMEOUT_US	1000000
 
 /* QDMA Reset Index Register */
 #define MTK_QDMA_RST_IDX	0x1A08
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:05 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:05 -0700
Subject: [PATCH net-next v2 12/15] net: ethernet: mtk_eth_soc: reduce
 unnecessary interrupts
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-13-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Avoid rearming interrupt if napi_complete returns false

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 4735942ed283..e1792ccaedc3 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1519,8 +1519,8 @@ static int mtk_napi_tx(struct napi_struct *napi, int budget)
 	if (status & MTK_TX_DONE_INT)
 		return budget;
 
-	napi_complete(napi);
-	mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
+	if (napi_complete(napi))
+		mtk_tx_irq_enable(eth, MTK_TX_DONE_INT);
 
 	return tx_done;
 }
@@ -1553,8 +1553,9 @@ static int mtk_napi_rx(struct napi_struct *napi, int budget)
 		remain_budget -= rx_done;
 		goto poll_again;
 	}
-	napi_complete(napi);
-	mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
+
+	if (napi_complete(napi))
+		mtk_rx_irq_enable(eth, MTK_RX_DONE_INT);
 
 	return rx_done + budget - remain_budget;
 }
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:01 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:01 -0700
Subject: [PATCH net-next v2 08/15] net: ethernet: mtk_eth_soc: increase DMA
 ring sizes
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-9-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

256 descriptors is not enough for multi-gigabit traffic under load on
MT7622. Bump it to 512 to improve performance.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 83883d86b881..540a5771b7bf 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -22,7 +22,7 @@
 #define MTK_MAX_RX_LENGTH	1536
 #define MTK_MAX_RX_LENGTH_2K	2048
 #define MTK_TX_DMA_BUF_LEN	0x3fff
-#define MTK_DMA_SIZE		256
+#define MTK_DMA_SIZE		512
 #define MTK_NAPI_WEIGHT		64
 #define MTK_MAC_COUNT		2
 #define MTK_RX_ETH_HLEN		(ETH_HLEN + ETH_FCS_LEN)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:00 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:00 -0700
Subject: [PATCH net-next v2 07/15] net: ethernet: mtk_eth_soc: use larger
 burst size for QDMA TX
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-8-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Improves tx performance

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index e6f832dde9a6..645360cfdfe9 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2193,7 +2193,7 @@ static int mtk_start_dma(struct mtk_eth *eth)
 	if (MTK_HAS_CAPS(eth->soc->caps, MTK_QDMA)) {
 		mtk_w32(eth,
 			MTK_TX_WB_DDONE | MTK_TX_DMA_EN |
-			MTK_DMA_SIZE_16DWORDS | MTK_NDP_CO_PRO |
+			MTK_TX_BT_32DWORDS | MTK_NDP_CO_PRO |
 			MTK_RX_DMA_EN | MTK_RX_2B_OFFSET |
 			MTK_RX_BT_32DWORDS,
 			MTK_QDMA_GLO_CFG);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 875e67b41561..83883d86b881 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -203,7 +203,7 @@
 #define MTK_RX_BT_32DWORDS	(3 << 11)
 #define MTK_NDP_CO_PRO		BIT(10)
 #define MTK_TX_WB_DDONE		BIT(6)
-#define MTK_DMA_SIZE_16DWORDS	(2 << 4)
+#define MTK_TX_BT_32DWORDS	(3 << 4)
 #define MTK_RX_DMA_BUSY		BIT(3)
 #define MTK_TX_DMA_BUSY		BIT(1)
 #define MTK_RX_DMA_EN		BIT(2)
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:03 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:03 -0700
Subject: [PATCH net-next v2 10/15] net: ethernet: mtk_eth_soc: cache HW
 pointer of last freed TX descriptor
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-11-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

The value is only updated by the CPU, so it is cheaper to access from the
ring data structure than from a hardware register.

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 ++++----
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 762e985fa294..6d23118b7a6c 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1364,7 +1364,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 	struct mtk_tx_buf *tx_buf;
 	u32 cpu, dma;
 
-	cpu = mtk_r32(eth, MTK_QTX_CRX_PTR);
+	cpu = ring->last_free_ptr;
 	dma = mtk_r32(eth, MTK_QTX_DRX_PTR);
 
 	desc = mtk_qdma_phys_to_virt(ring, cpu);
@@ -1398,6 +1398,7 @@ static int mtk_poll_tx_qdma(struct mtk_eth *eth, int budget,
 		cpu = next_cpu;
 	}
 
+	ring->last_free_ptr = cpu;
 	mtk_w32(eth, cpu, MTK_QTX_CRX_PTR);
 
 	return budget;
@@ -1598,6 +1599,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
 	atomic_set(&ring->free_count, MTK_DMA_SIZE - 2);
 	ring->next_free = &ring->dma[0];
 	ring->last_free = &ring->dma[MTK_DMA_SIZE - 1];
+	ring->last_free_ptr = (u32)(ring->phys + ((MTK_DMA_SIZE - 1) * sz));
 	ring->thresh = MAX_SKB_FRAGS;
 
 	/* make sure that all changes to the dma ring are flushed before we
@@ -1611,9 +1613,7 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
 		mtk_w32(eth,
 			ring->phys + ((MTK_DMA_SIZE - 1) * sz),
 			MTK_QTX_CRX_PTR);
-		mtk_w32(eth,
-			ring->phys + ((MTK_DMA_SIZE - 1) * sz),
-			MTK_QTX_DRX_PTR);
+		mtk_w32(eth, ring->last_free_ptr, MTK_QTX_DRX_PTR);
 		mtk_w32(eth, (QDMA_RES_THRES << 8) | QDMA_RES_THRES,
 			MTK_QTX_CFG(0));
 	} else {
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index ceb5a4a661e6..6b92dd6c2cda 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -642,6 +642,7 @@ struct mtk_tx_buf {
  * @phys:		The physical addr of tx_buf
  * @next_free:		Pointer to the next free descriptor
  * @last_free:		Pointer to the last free descriptor
+ * @last_free_ptr:	Hardware pointer value of the last free descriptor
  * @thresh:		The threshold of minimum amount of free descriptors
  * @free_count:		QDMA uses a linked list. Track how many free descriptors
  *			are present
@@ -652,6 +653,7 @@ struct mtk_tx_ring {
 	dma_addr_t phys;
 	struct mtk_tx_dma *next_free;
 	struct mtk_tx_dma *last_free;
+	u32 last_free_ptr;
 	u16 thresh;
 	atomic_t free_count;
 	int dma_size;
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:20:56 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:20:56 -0700
Subject: [PATCH net-next v2 03/15] net: ethernet: mtk_eth_soc: fix build_skb
 cleanup
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-4-ilya.lipnitskiy@gmail.com>

In case build_skb fails, call skb_free_frag on the correct pointer. Also
update the DMA structures with the new mapping before exiting, because
the mapping was successful

Suggested-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 540003f3fcb8..07daa5de8bec 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1304,9 +1304,9 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		/* receive data */
 		skb = build_skb(data, ring->frag_size);
 		if (unlikely(!skb)) {
-			skb_free_frag(new_data);
+			skb_free_frag(data);
 			netdev->stats.rx_dropped++;
-			goto release_desc;
+			goto skip_rx;
 		}
 		skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
 
@@ -1326,6 +1326,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		skb_record_rx_queue(skb, 0);
 		napi_gro_receive(napi, skb);
 
+skip_rx:
 		ring->data[idx] = new_data;
 		rxd->rxd1 = (unsigned int)dma_addr;
 
-- 
2.31.1



From ilya.lipnitskiy at gmail.com  Fri Apr 23 06:21:04 2021
From: ilya.lipnitskiy at gmail.com (Ilya Lipnitskiy)
Date: Thu, 22 Apr 2021 22:21:04 -0700
Subject: [PATCH net-next v2 11/15] net: ethernet: mtk_eth_soc: only read the
 full RX descriptor if DMA is done
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <20210423052108.423853-12-ilya.lipnitskiy@gmail.com>

From: Felix Fietkau <nbd at nbd.name>

Uncached memory access is expensive, and there is no need to access all
descriptor words if we can't process them anyway

Signed-off-by: Felix Fietkau <nbd at nbd.name>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy at gmail.com>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 6d23118b7a6c..4735942ed283 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -777,13 +777,18 @@ static inline int mtk_max_buf_size(int frag_size)
 	return buf_size;
 }
 
-static inline void mtk_rx_get_desc(struct mtk_rx_dma *rxd,
+static inline bool mtk_rx_get_desc(struct mtk_rx_dma *rxd,
 				   struct mtk_rx_dma *dma_rxd)
 {
-	rxd->rxd1 = READ_ONCE(dma_rxd->rxd1);
 	rxd->rxd2 = READ_ONCE(dma_rxd->rxd2);
+	if (!(rxd->rxd2 & RX_DMA_DONE))
+		return false;
+
+	rxd->rxd1 = READ_ONCE(dma_rxd->rxd1);
 	rxd->rxd3 = READ_ONCE(dma_rxd->rxd3);
 	rxd->rxd4 = READ_ONCE(dma_rxd->rxd4);
+
+	return true;
 }
 
 /* the qdma core needs scratch memory to be setup */
@@ -1255,8 +1260,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
 		rxd = &ring->dma[idx];
 		data = ring->data[idx];
 
-		mtk_rx_get_desc(&trxd, rxd);
-		if (!(trxd.rxd2 & RX_DMA_DONE))
+		if (!mtk_rx_get_desc(&trxd, rxd))
 			break;
 
 		/* find out which mac the packet come from. values start at 1 */
-- 
2.31.1



From eizan at chromium.org  Fri Apr 23 06:58:40 2021
From: eizan at chromium.org (Eizan Miyamoto)
Date: Fri, 23 Apr 2021 15:58:40 +1000
Subject: [PATCH v1 3/4] media: mtk-mdp: don't pm_run_time_get/put for master
 comp in clock_on
In-Reply-To: <20210423055842.2490679-1-eizan@chromium.org>
References: <20210423055842.2490679-1-eizan@chromium.org>
Message-ID: <20210423155824.v1.3.Ifd87681955689a08cce4c65e72ee5e8c6d09af95@changeid>

The original intent of commit 86698b9505bbc ("media: mtk-mdp: convert
mtk_mdp_dev.comp array to list") was to create a list to track all the
MDP components that needed to have their clocks enabled/disabled when
calling mtk_mdp_comp_clock_on/off. However, there was a bug inside
mtk_mdp_register_component where the args to a call to list_add were
swapped. The result is that only one component was added to
mtk_mdp_dev.comp_list because comp_list was instead being
repeatedly added to the single element lists headed by each
mtk_mdp_comp.

The order of the args to list_add in mtk_mdp_register_component was
fixed in https://patchwork.kernel.org/patch/11742895/ (Fix Null pointer
dereference when calling list_add).

Then, as a result of https://patchwork.kernel.org/patch/11530769/
(mtk-mdp: use pm_runtime in MDP component driver) if all the components
are added to the component list, the mdp "master" / rdma0 component
ends up having pm_runtime_get_sync() called on it twice recursively:

    rpm_resume+0x694/0x8f8
    __pm_runtime_resume+0x7c/0xa0 ***NOTE***
    mtk_mdp_comp_clock_on+0x48/0x104 [mtk_mdp]
    mtk_mdp_pm_resume+0x2c/0x44 [mtk_mdp]
    pm_generic_runtime_resume+0x34/0x48
    __genpd_runtime_resume+0x6c/0x80
    genpd_runtime_resume+0x104/0x1ac
    __rpm_callback+0x120/0x238
    rpm_callback+0x34/0x8c
    rpm_resume+0x7a0/0x8f8
    __pm_runtime_resume+0x7c/0xa0 ***NOTE***
    mtk_mdp_m2m_start_streaming+0x2c/0x3c [mtk_mdp]

(The calls to pm_runtime_get_sync are inlined and correspond to the
calls to __pm_runtime_resume). It is not correct to have
pm_runtime_get_sync called recursively and the second call will block
indefinitely.

As a result of all that, this change factors mtk_mdp_comp_clock_on/off
into mtk_mdp_comp_power_on/off and moves the calls to
pm_runtime_get/put into the power_on/off functions.

This change then special-cases the master/rdma0 MDP component and does
these things:
- the master/rdma0 component is not added to mtk_mdp_dev.comp_list
- the master/rdma0 component has its clocks (*but not power*) toggled
  by mtk_mpd_comp_clock_on/off inside mtk_mdp_clock_on/off.
- the other components have their clocks *and* power toggled with
  mtk_mdp_comp_power_on/off.

This change introduces the assumption that mtk_mdp_pm_resume will
always be called though a callback from pm_runtime_get_sync made on the
master / rdma0 component.

Signed-off-by: Eizan Miyamoto <eizan at chromium.org>
---

 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 28 ++++++++++++++-----
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  3 ++
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 23 ++++++++++-----
 3 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 84f9c529d74a..d447bfaadef4 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -53,15 +53,31 @@ static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
 
-void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
+void mtk_mdp_comp_power_on(struct mtk_mdp_comp *comp)
 {
-	int i, err;
+	int err;
 
 	err = pm_runtime_get_sync(comp->dev);
 	if (err < 0)
-		dev_err(comp->dev,
-			"failed to runtime get, err %d.\n",
-			err);
+		dev_err(comp->dev, "failed to runtime get, err %d.\n", err);
+
+	mtk_mdp_comp_clock_on(comp);
+}
+
+void mtk_mdp_comp_power_off(struct mtk_mdp_comp *comp)
+{
+	int err;
+
+	mtk_mdp_comp_clock_off(comp);
+
+	err = pm_runtime_put_sync(comp->dev);
+	if (err < 0)
+		dev_err(comp->dev, "failed to runtime put, err %d.\n", err);
+}
+
+void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
+{
+	int i, err;
 
 	for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
 		if (IS_ERR(comp->clk[i]))
@@ -83,8 +99,6 @@ void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
 			continue;
 		clk_disable_unprepare(comp->clk[i]);
 	}
-
-	pm_runtime_put_sync(comp->dev);
 }
 
 static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 355e226d74fe..7ad9b06bb11b 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -21,6 +21,9 @@ struct mtk_mdp_comp {
 
 int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev);
 
+void mtk_mdp_comp_power_on(struct mtk_mdp_comp *comp);
+void mtk_mdp_comp_power_off(struct mtk_mdp_comp *comp);
+
 void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp);
 void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp);
 
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index c55bcfe4cbb7..5e71496e2517 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -53,8 +53,15 @@ static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
 {
 	struct mtk_mdp_comp *comp_node;
 
+	/*
+	 * The master / rdma0 component will have pm_runtime_get_sync called
+	 * on it through mtk_mdp_m2m_start_streaming, making it unnecessary to
+	 * have mtk_mdp_comp_power_on called on it.
+	 */
+	mtk_mdp_comp_clock_on(&mdp->comp_self);
+
 	list_for_each_entry(comp_node, &mdp->comp_list, node)
-		mtk_mdp_comp_clock_on(comp_node);
+		mtk_mdp_comp_power_on(comp_node);
 }
 
 static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
@@ -62,7 +69,14 @@ static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
 	struct mtk_mdp_comp *comp_node;
 
 	list_for_each_entry(comp_node, &mdp->comp_list, node)
-		mtk_mdp_comp_clock_off(comp_node);
+		mtk_mdp_comp_power_off(comp_node);
+
+	/*
+	 * The master / rdma0 component will have pm_runtime_put called
+	 * on it through mtk_mdp_m2m_stop_streaming, making it unnecessary to
+	 * have mtk_mdp_comp_power_off called on it.
+	 */
+	mtk_mdp_comp_clock_off(&mdp->comp_self);
 }
 
 static void mtk_mdp_wdt_worker(struct work_struct *work)
@@ -101,8 +115,6 @@ static int mtk_mdp_master_bind(struct device *dev)
 	int status;
 	struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
 
-	mtk_mdp_register_component(mdp, &mdp->comp_self);
-
 	status = component_bind_all(dev, mdp);
 	if (status) {
 		dev_err(dev, "Failed to bind all components: %d\n", status);
@@ -124,8 +136,6 @@ static int mtk_mdp_master_bind(struct device *dev)
 	component_unbind_all(dev, mdp);
 
 err_component_bind_all:
-	mtk_mdp_unregister_component(mdp, &mdp->comp_self);
-
 	return status;
 }
 
@@ -136,7 +146,6 @@ static void mtk_mdp_master_unbind(struct device *dev)
 	pm_runtime_disable(dev);
 	mtk_mdp_unregister_m2m_device(mdp);
 	component_unbind_all(dev, mdp);
-	mtk_mdp_unregister_component(mdp, &mdp->comp_self);
 }
 
 static const struct component_master_ops mtk_mdp_com_ops = {
-- 
2.31.1.498.g6c1eba8ee3d-goog



From eizan at chromium.org  Fri Apr 23 06:58:38 2021
From: eizan at chromium.org (Eizan Miyamoto)
Date: Fri, 23 Apr 2021 15:58:38 +1000
Subject: [PATCH v1 1/4] mtk-mdp: add driver to probe mdp components
In-Reply-To: <20210423055842.2490679-1-eizan@chromium.org>
References: <20210423055842.2490679-1-eizan@chromium.org>
Message-ID: <20210423155824.v1.1.Ie6d1e6e39cf9b5d6b2108ae1096af34c3d55880b@changeid>

Broadly, this patch (1) adds a driver for various MTK MDP components to
go alongside the main MTK MDP driver, and (2) hooks them all together
using the component framework.

(1) Up until now, the MTK MDP driver controls 8 devices in the device
tree on its own. When running tests for the hardware video decoder, we
found that the iommus and LARBs were not being properly configured. To
configure them, a driver for each be added to mtk_mdp_comp so that
mtk_iommu_add_device() can (eventually) be called from dma_configure()
inside really_probe().

(2) The integration into the component framework allows us to defer the
registration with the v4l2 subsystem until all the MDP-related devices
have been probed, so that the relevant device node does not become
available until initialization of all the components is complete.

Some notes about how the component framework has been integrated:

- The driver for the rdma0 component serves double duty as the "master"
  (aggregate) driver as well as a component driver. This is a non-ideal
  compromise until a better solution is developed. This device is
  differentiated from the rest by checking for a "mediatek,vpu" property
  in the device node.

- The list of mdp components remains hard-coded as mtk_mdp_comp_dt_ids[]
  in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in
  mtk_mdp_comp.c. This unfortunate duplication of information is
  addressed in a following patch in this series.

- The component driver calls component_add() for each device that is
  probed.

- In mtk_mdp_probe (the "master" device), we scan the device tree for
  any matching nodes against mtk_mdp_comp_dt_ids, and add component
  matches for them. The match criteria is a matching device node
  pointer.

- When the set of components devices that have been probed corresponds
  with the list that is generated by the "master", the callback to
  mtk_mdp_master_bind() is made, which then calls the component bind
  functions.

- Inside mtk_mdp_master_bind(), once all the component bind functions
  have been called, we can then register our device to the v4l2
  subsystem.

- The call to pm_runtime_enable() in the master device is called after
  all the components have been registered by their bind() functions
  called by mtk_mtp_master_bind(). As a result, the list of components
  will not change while power management callbacks mtk_mdp_suspend()/
  resume() are accessing the list of components.

Signed-off-by: Eizan Miyamoto <eizan at chromium.org>
---

 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 139 ++++++++++++--
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  26 +--
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 175 +++++++++++++-----
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h |   1 +
 4 files changed, 255 insertions(+), 86 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 1e3833f1c9ae..3fbbcf05440a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -5,13 +5,51 @@
  */
 
 #include <linux/clk.h>
+#include <linux/component.h>
 #include <linux/device.h>
-#include <linux/of.h>
+#include <linux/module.h>
 #include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
 #include <linux/of_platform.h>
 
 #include "mtk_mdp_comp.h"
+#include "mtk_mdp_core.h"
+
+/**
+ * enum mtk_mdp_comp_type - the MDP component
+ * @MTK_MDP_RDMA:		Read DMA
+ * @MTK_MDP_RSZ:		Reszer
+ * @MTK_MDP_WDMA:		Write DMA
+ * @MTK_MDP_WROT:		Write DMA with rotation
+ * @MTK_MDP_COMP_TYPE_MAX:	Placeholder for num elems in this enum
+ */
+enum mtk_mdp_comp_type {
+	MTK_MDP_RDMA,
+	MTK_MDP_RSZ,
+	MTK_MDP_WDMA,
+	MTK_MDP_WROT,
+	MTK_MDP_COMP_TYPE_MAX,
+};
 
+static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
+	{
+		.compatible = "mediatek,mt8173-mdp-rdma",
+		.data = (void *)MTK_MDP_RDMA
+	}, {
+		.compatible = "mediatek,mt8173-mdp-rsz",
+		.data = (void *)MTK_MDP_RSZ
+	}, {
+		.compatible = "mediatek,mt8173-mdp-wdma",
+		.data = (void *)MTK_MDP_WDMA
+	}, {
+		.compatible = "mediatek,mt8173-mdp-wrot",
+		.data = (void *)MTK_MDP_WROT
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
 
 void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
 {
@@ -23,8 +61,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
 		err = clk_prepare_enable(comp->clk[i]);
 		if (err)
 			dev_err(dev,
-			"failed to enable clock, err %d. type:%d i:%d\n",
-				err, comp->type, i);
+				"failed to enable clock, err %d. i:%d\n",
+				err, i);
 	}
 }
 
@@ -39,15 +77,40 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
 	}
 }
 
-int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
-		      struct mtk_mdp_comp *comp,
-		      enum mtk_mdp_comp_type comp_type)
+static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
+			void *data)
+{
+	struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
+	struct mtk_mdp_dev *mdp = data;
+
+	mtk_mdp_register_component(mdp, comp);
+
+	return 0;
+}
+
+static void mtk_mdp_comp_unbind(struct device *dev, struct device *master,
+			   void *data)
+{
+	struct mtk_mdp_dev *mdp = data;
+	struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
+
+	mtk_mdp_unregister_component(mdp, comp);
+}
+
+static const struct component_ops mtk_mdp_component_ops = {
+	.bind   = mtk_mdp_comp_bind,
+	.unbind = mtk_mdp_comp_unbind,
+};
+
+int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
 {
 	int ret;
 	int i;
+	struct device_node *node = dev->of_node;
+	enum mtk_mdp_comp_type comp_type =
+		 (enum mtk_mdp_comp_type)of_device_get_match_data(dev);
 
-	comp->dev_node = of_node_get(node);
-	comp->type = comp_type;
+	INIT_LIST_HEAD(&comp->node);
 
 	for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
 		comp->clk[i] = of_clk_get(node, i);
@@ -55,23 +118,71 @@ int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
 			if (PTR_ERR(comp->clk[i]) != -EPROBE_DEFER)
 				dev_err(dev, "Failed to get clock\n");
 			ret = PTR_ERR(comp->clk[i]);
-			goto put_dev;
+			goto err;
 		}
 
 		/* Only RDMA needs two clocks */
-		if (comp->type != MTK_MDP_RDMA)
+		if (comp_type != MTK_MDP_RDMA)
 			break;
 	}
 
 	return 0;
 
-put_dev:
-	of_node_put(comp->dev_node);
+err:
+	dev_err(dev, "err %d\n", ret);
 
 	return ret;
 }
 
-void mtk_mdp_comp_deinit(struct device *dev, struct mtk_mdp_comp *comp)
+static int mtk_mdp_comp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *vpu_node;
+	int status;
+	struct mtk_mdp_comp *comp;
+
+	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
+	if (vpu_node) {
+		of_node_put(vpu_node);
+		/*
+		 * The device tree node with a mediatek,vpu property is deemed
+		 * the MDP "master" device, we don't want to add a component
+		 * for it in this function because the initialization for the
+		 * master is done elsewhere.
+		 */
+		dev_info(dev, "vpu node found, not probing\n");
+		return -ENODEV;
+	}
+
+	comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
+	if (!comp)
+		return -ENOMEM;
+
+	status = mtk_mdp_comp_init(comp, dev);
+	if (status) {
+		dev_err(dev, "Failed to initialize component: %d\n", status);
+		return status;
+	}
+
+	dev_set_drvdata(dev, comp);
+
+	return component_add(dev, &mtk_mdp_component_ops);
+}
+
+static int mtk_mdp_comp_remove(struct platform_device *pdev)
 {
-	of_node_put(comp->dev_node);
+	struct device *dev = &pdev->dev;
+
+	component_del(dev, &mtk_mdp_component_ops);
+	return 0;
 }
+
+struct platform_driver mtk_mdp_component_driver = {
+	.probe          = mtk_mdp_comp_probe,
+	.remove         = mtk_mdp_comp_remove,
+	.driver         = {
+		.name   = "mediatek-mdp-comp",
+		.owner  = THIS_MODULE,
+		.of_match_table = mtk_mdp_comp_driver_dt_match,
+	},
+};
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 36bc1b8f6222..956d20c01e34 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -7,41 +7,21 @@
 #ifndef __MTK_MDP_COMP_H__
 #define __MTK_MDP_COMP_H__
 
-/**
- * enum mtk_mdp_comp_type - the MDP component
- * @MTK_MDP_RDMA:	Read DMA
- * @MTK_MDP_RSZ:	Riszer
- * @MTK_MDP_WDMA:	Write DMA
- * @MTK_MDP_WROT:	Write DMA with rotation
- */
-enum mtk_mdp_comp_type {
-	MTK_MDP_RDMA,
-	MTK_MDP_RSZ,
-	MTK_MDP_WDMA,
-	MTK_MDP_WROT,
-	MTK_MDP_COMP_TYPE_MAX,
-};
-
 /**
  * struct mtk_mdp_comp - the MDP's function component data
  * @node:	list node to track sibing MDP components
- * @dev_node:	component device node
  * @clk:	clocks required for component
- * @type:	component type
  */
 struct mtk_mdp_comp {
 	struct list_head	node;
-	struct device_node	*dev_node;
 	struct clk		*clk[2];
-	enum mtk_mdp_comp_type	type;
 };
 
-int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
-		      struct mtk_mdp_comp *comp,
-		      enum mtk_mdp_comp_type comp_type);
-void mtk_mdp_comp_deinit(struct device *dev, struct mtk_mdp_comp *comp);
+int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev);
+
 void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp);
 void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp);
 
+extern struct platform_driver mtk_mdp_component_driver;
 
 #endif /* __MTK_MDP_COMP_H__ */
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 70a8eab16863..d79bf7f0031a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/component.h>
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/interrupt.h>
@@ -18,6 +19,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/workqueue.h>
 
+#include "mtk_mdp_comp.h"
 #include "mtk_mdp_core.h"
 #include "mtk_mdp_m2m.h"
 #include "mtk_vpu.h"
@@ -31,16 +33,12 @@ module_param(mtk_mdp_dbg_level, int, 0644);
 static const struct of_device_id mtk_mdp_comp_dt_ids[] = {
 	{
 		.compatible = "mediatek,mt8173-mdp-rdma",
-		.data = (void *)MTK_MDP_RDMA
 	}, {
 		.compatible = "mediatek,mt8173-mdp-rsz",
-		.data = (void *)MTK_MDP_RSZ
 	}, {
 		.compatible = "mediatek,mt8173-mdp-wdma",
-		.data = (void *)MTK_MDP_WDMA
 	}, {
 		.compatible = "mediatek,mt8173-mdp-wrot",
-		.data = (void *)MTK_MDP_WROT
 	},
 	{ },
 };
@@ -90,6 +88,64 @@ static void mtk_mdp_reset_handler(void *priv)
 	queue_work(mdp->wdt_wq, &mdp->wdt_work);
 }
 
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static void release_of(struct device *dev, void *data)
+{
+	of_node_put(data);
+}
+
+static int mtk_mdp_master_bind(struct device *dev)
+{
+	int status;
+	struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
+
+	mtk_mdp_register_component(mdp, &mdp->comp_self);
+
+	status = component_bind_all(dev, mdp);
+	if (status) {
+		dev_err(dev, "Failed to bind all components: %d\n", status);
+		goto err_component_bind_all;
+	}
+
+	status = mtk_mdp_register_m2m_device(mdp);
+	if (status) {
+		dev_err(dev, "Failed to register m2m device: %d\n", status);
+		v4l2_err(&mdp->v4l2_dev, "Failed to init mem2mem device\n");
+		goto err_mtk_mdp_register_m2m_device;
+	}
+
+	pm_runtime_enable(dev);
+
+	return 0;
+
+err_mtk_mdp_register_m2m_device:
+	component_unbind_all(dev, mdp);
+
+err_component_bind_all:
+	mtk_mdp_unregister_component(mdp, &mdp->comp_self);
+
+	return status;
+}
+
+static void mtk_mdp_master_unbind(struct device *dev)
+{
+	struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
+
+	pm_runtime_disable(dev);
+	mtk_mdp_unregister_m2m_device(mdp);
+	component_unbind_all(dev, mdp);
+	mtk_mdp_unregister_component(mdp, &mdp->comp_self);
+}
+
+static const struct component_master_ops mtk_mdp_com_ops = {
+	.bind		= mtk_mdp_master_bind,
+	.unbind		= mtk_mdp_master_unbind,
+};
+
 void mtk_mdp_register_component(struct mtk_mdp_dev *mdp,
 				struct mtk_mdp_comp *comp)
 {
@@ -107,8 +163,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 	struct mtk_mdp_dev *mdp;
 	struct device *dev = &pdev->dev;
 	struct device_node *node, *parent;
-	struct mtk_mdp_comp *comp, *comp_temp;
-	int ret = 0;
+	int i, ret = 0;
+	struct component_match *match = NULL;
 
 	mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
 	if (!mdp)
@@ -133,36 +189,43 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 	}
 
 	/* Iterate over sibling MDP function blocks */
+	i = 0;
 	for_each_child_of_node(parent, node) {
-		const struct of_device_id *of_id;
-		enum mtk_mdp_comp_type comp_type;
+		struct platform_device *pdev;
 
-		of_id = of_match_node(mtk_mdp_comp_dt_ids, node);
-		if (!of_id)
+		if (!of_match_node(mtk_mdp_comp_dt_ids, node))
 			continue;
 
-		if (!of_device_is_available(node)) {
-			dev_err(dev, "Skipping disabled component %pOF\n",
-				node);
+		if (!of_device_is_available(node))
 			continue;
-		}
 
-		comp_type = (enum mtk_mdp_comp_type)of_id->data;
-
-		comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
-		if (!comp) {
-			ret = -ENOMEM;
-			of_node_put(node);
-			goto err_comp;
+		pdev = of_find_device_by_node(node);
+		if (!pdev) {
+			dev_warn(dev, "Unable to find comp device %s\n",
+				 node->full_name);
+			continue;
 		}
 
-		ret = mtk_mdp_comp_init(dev, node, comp, comp_type);
-		if (ret) {
-			of_node_put(node);
-			goto err_comp;
+		/*
+		 * Do not add a match for my own (rdma0) device node.
+		 * I will be managing it directly instead using comp_self.
+		 */
+		if (&pdev->dev != dev) {
+			dev_dbg(dev, "adding match %d for: %pOF\n", i++, node);
+			component_match_add_release(dev, &match, release_of,
+						    compare_of,
+						    of_node_get(node));
 		}
+	}
 
-		mtk_mdp_register_component(mdp, comp);
+	/*
+	 * Create a component for myself so that clocks can be toggled in
+	 * clock_on().
+	 */
+	ret = mtk_mdp_comp_init(&mdp->comp_self, dev);
+	if (ret) {
+		dev_err(dev, "Failed to initialize component\n");
+		goto err_comp;
 	}
 
 	mdp->job_wq = create_singlethread_workqueue(MTK_MDP_MODULE_NAME);
@@ -187,18 +250,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 		goto err_dev_register;
 	}
 
-	ret = mtk_mdp_register_m2m_device(mdp);
-	if (ret) {
-		v4l2_err(&mdp->v4l2_dev, "Failed to init mem2mem device\n");
-		goto err_m2m_register;
-	}
-
 	mdp->vpu_dev = vpu_get_plat_device(pdev);
 	ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
 				  VPU_RST_MDP);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to register reset handler\n");
-		goto err_m2m_register;
+		goto err_wdt_reg;
 	}
 
 	platform_set_drvdata(pdev, mdp);
@@ -206,15 +263,25 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 	ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
-		goto err_m2m_register;
+		goto err_set_max_seg_size;
+	}
+
+	ret = component_master_add_with_match(dev, &mtk_mdp_com_ops, match);
+	if (ret) {
+		dev_err(dev, "Component master add failed\n");
+		goto err_component_master_add;
 	}
 
-	pm_runtime_enable(dev);
 	dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
 
 	return 0;
 
-err_m2m_register:
+err_component_master_add:
+	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
+
+err_set_max_seg_size:
+
+err_wdt_reg:
 	v4l2_device_unregister(&mdp->v4l2_dev);
 
 err_dev_register:
@@ -226,11 +293,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 err_alloc_job_wq:
 
 err_comp:
-	list_for_each_entry_safe(comp, comp_temp, &mdp->comp_list, node) {
-		mtk_mdp_unregister_component(mdp, comp);
-		mtk_mdp_comp_deinit(dev, comp);
-	}
-
 	dev_dbg(dev, "err %d\n", ret);
 	return ret;
 }
@@ -238,11 +300,10 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 static int mtk_mdp_remove(struct platform_device *pdev)
 {
 	struct mtk_mdp_dev *mdp = platform_get_drvdata(pdev);
-	struct mtk_mdp_comp *comp, *comp_temp;
 
-	pm_runtime_disable(&pdev->dev);
+	component_master_del(&pdev->dev, &mtk_mdp_com_ops);
+
 	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
-	mtk_mdp_unregister_m2m_device(mdp);
 	v4l2_device_unregister(&mdp->v4l2_dev);
 
 	flush_workqueue(mdp->wdt_wq);
@@ -251,10 +312,8 @@ static int mtk_mdp_remove(struct platform_device *pdev)
 	flush_workqueue(mdp->job_wq);
 	destroy_workqueue(mdp->job_wq);
 
-	list_for_each_entry_safe(comp, comp_temp, &mdp->comp_list, node) {
-		mtk_mdp_unregister_component(mdp, comp);
-		mtk_mdp_comp_deinit(&pdev->dev, comp);
-	}
+	if (!list_empty(&mdp->comp_list))
+		dev_err(&pdev->dev, "not all components removed\n");
 
 	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
 	return 0;
@@ -309,7 +368,25 @@ static struct platform_driver mtk_mdp_driver = {
 	}
 };
 
-module_platform_driver(mtk_mdp_driver);
+static struct platform_driver * const mtk_mdp_drivers[] = {
+	&mtk_mdp_driver,
+	&mtk_mdp_component_driver,
+};
+
+static int __init mtk_mdp_init(void)
+{
+	return platform_register_drivers(mtk_mdp_drivers,
+					 ARRAY_SIZE(mtk_mdp_drivers));
+}
+
+static void __exit mtk_mdp_exit(void)
+{
+	platform_unregister_drivers(mtk_mdp_drivers,
+				    ARRAY_SIZE(mtk_mdp_drivers));
+}
+
+module_init(mtk_mdp_init);
+module_exit(mtk_mdp_exit);
 
 MODULE_AUTHOR("Houlong Wei <houlong.wei at mediatek.com>");
 MODULE_DESCRIPTION("Mediatek image processor driver");
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index a7da14b97077..230f531400ca 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -155,6 +155,7 @@ struct mtk_mdp_dev {
 	struct mtk_mdp_variant		*variant;
 	u16				id;
 	struct list_head		comp_list;
+	struct mtk_mdp_comp		comp_self;
 	struct v4l2_m2m_dev		*m2m_dev;
 	struct list_head		ctx_list;
 	struct video_device		*vdev;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From eizan at chromium.org  Fri Apr 23 06:58:41 2021
From: eizan at chromium.org (Eizan Miyamoto)
Date: Fri, 23 Apr 2021 15:58:41 +1000
Subject: [PATCH v1 4/4] mtk-mdp: soc: mediatek: register mdp from mmsys
In-Reply-To: <20210423055842.2490679-1-eizan@chromium.org>
References: <20210423055842.2490679-1-eizan@chromium.org>
Message-ID: <20210423155824.v1.4.I558dcbaa17bf00243951a8ceb6d0e98758aacfa4@changeid>

Rather than hanging the MDP master component driver off of the rdma0
device, create a "virtual" device by the mmsys driver instead which is
probed by the mtk_mdp_core driver.

Broadly, four interdependent things are done by this change:
- A virtual device that is probed by the mtk_mdp_core driver is
  instantiated by the mtk_mmsys driver.
- Presence of a mediatek,vpu property in a child node to the mmsys
  device node is used to determine what device to use when dispatching
  dma ops from the relevant ioctl.
- v4l-related setup is moved into from the mtk_mdp_core driver to the
  mtk_mdp_comp driver.

Signed-off-by: Eizan Miyamoto <eizan at chromium.org>
---

 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 47 +++++++++-----
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 62 ++++++-------------
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  2 +
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  |  4 +-
 drivers/soc/mediatek/mtk-mmsys.c              | 20 +++++-
 5 files changed, 75 insertions(+), 60 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index d447bfaadef4..dc5231a1fcfd 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -106,8 +106,41 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
 {
 	struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
 	struct mtk_mdp_dev *mdp = data;
+	struct device_node *vpu_node;
 
 	mtk_mdp_register_component(mdp, comp);
+
+	// If this component has a "mediatek-vpu" property, it is responsible for
+	// notifying the mdp master driver about it so it can be further initialized
+	// later.
+	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
+	if (vpu_node) {
+		int ret;
+
+		mdp->vpu_dev = of_find_device_by_node(vpu_node);
+		if (WARN_ON(!mdp->vpu_dev)) {
+			dev_err(dev, "vpu pdev failed\n");
+			of_node_put(vpu_node);
+		}
+
+		ret = v4l2_device_register(dev, &mdp->v4l2_dev);
+		if (ret) {
+			dev_err(dev, "Failed to register v4l2 device\n");
+			return -EINVAL;
+		}
+
+		ret = vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
+		if (ret) {
+			dev_err(dev, "Failed to set vb2 dma mag seg size\n");
+			return -EINVAL;
+		}
+
+		// presence of the "mediatek,vpu" property in a device node
+		// indicates that it is the primary MDP rdma device and MDP DMA
+		// ops should be handled by its DMA callbacks.
+		mdp->rdma_dev = dev;
+	}
+
 	pm_runtime_enable(dev);
 
 	return 0;
@@ -164,23 +197,9 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
 static int mtk_mdp_comp_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct device_node *vpu_node;
 	int status;
 	struct mtk_mdp_comp *comp;
 
-	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
-	if (vpu_node) {
-		of_node_put(vpu_node);
-		/*
-		 * The device tree node with a mediatek,vpu property is deemed
-		 * the MDP "master" device, we don't want to add a component
-		 * for it in this function because the initialization for the
-		 * master is done elsewhere.
-		 */
-		dev_info(dev, "vpu node found, not probing\n");
-		return -ENODEV;
-	}
-
 	comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
 	if (!comp)
 		return -ENOMEM;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 5e71496e2517..4d7aa4e26be6 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -121,6 +121,17 @@ static int mtk_mdp_master_bind(struct device *dev)
 		goto err_component_bind_all;
 	}
 
+	if (mdp->vpu_dev) {
+		int ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
+					  VPU_RST_MDP);
+		if (ret) {
+			dev_err(dev, "Failed to register reset handler\n");
+			goto err_wdt_reg;
+		}
+	} else {
+		dev_err(dev, "no vpu_dev found\n");
+	}
+
 	status = mtk_mdp_register_m2m_device(mdp);
 	if (status) {
 		dev_err(dev, "Failed to register m2m device: %d\n", status);
@@ -133,6 +144,8 @@ static int mtk_mdp_master_bind(struct device *dev)
 	return 0;
 
 err_mtk_mdp_register_m2m_device:
+
+err_wdt_reg:
 	component_unbind_all(dev, mdp);
 
 err_component_bind_all:
@@ -191,8 +204,13 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 		of_node_put(node);
 		parent = dev->of_node;
 		dev_warn(dev, "device tree is out of date\n");
-	} else {
+	} else if (dev->of_node) {
 		parent = dev->of_node->parent;
+	} else if (dev->parent) {
+		// maybe we were created from a call to platform_device_register_data()
+		parent = dev->parent->parent->of_node;
+	} else {
+		return -ENODEV;
 	}
 
 	/* Iterate over sibling MDP function blocks */
@@ -225,16 +243,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 		}
 	}
 
-	/*
-	 * Create a component for myself so that clocks can be toggled in
-	 * clock_on().
-	 */
-	ret = mtk_mdp_comp_init(&mdp->comp_self, dev);
-	if (ret) {
-		dev_err(dev, "Failed to initialize component\n");
-		goto err_comp;
-	}
-
 	mdp->job_wq = create_singlethread_workqueue(MTK_MDP_MODULE_NAME);
 	if (!mdp->job_wq) {
 		dev_err(&pdev->dev, "unable to alloc job workqueue\n");
@@ -250,29 +258,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 	}
 	INIT_WORK(&mdp->wdt_work, mtk_mdp_wdt_worker);
 
-	ret = v4l2_device_register(dev, &mdp->v4l2_dev);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to register v4l2 device\n");
-		ret = -EINVAL;
-		goto err_dev_register;
-	}
-
-	mdp->vpu_dev = vpu_get_plat_device(pdev);
-	ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
-				  VPU_RST_MDP);
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to register reset handler\n");
-		goto err_wdt_reg;
-	}
-
 	platform_set_drvdata(pdev, mdp);
 
-	ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
-	if (ret) {
-		dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
-		goto err_set_max_seg_size;
-	}
-
 	ret = component_master_add_with_match(dev, &mtk_mdp_com_ops, match);
 	if (ret) {
 		dev_err(dev, "Component master add failed\n");
@@ -284,22 +271,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 	return 0;
 
 err_component_master_add:
-	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
-
-err_set_max_seg_size:
-
-err_wdt_reg:
-	v4l2_device_unregister(&mdp->v4l2_dev);
-
-err_dev_register:
 	destroy_workqueue(mdp->wdt_wq);
 
 err_alloc_wdt_wq:
 	destroy_workqueue(mdp->job_wq);
 
 err_alloc_job_wq:
-
-err_comp:
 	dev_dbg(dev, "err %d\n", ret);
 	return ret;
 }
@@ -371,7 +348,6 @@ static struct platform_driver mtk_mdp_driver = {
 	.driver = {
 		.name	= MTK_MDP_MODULE_NAME,
 		.pm	= &mtk_mdp_pm_ops,
-		.of_match_table = mtk_mdp_of_ids,
 	}
 };
 
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index 230f531400ca..78c3c77cd226 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -133,6 +133,7 @@ struct mtk_mdp_variant {
  * struct mtk_mdp_dev - abstraction for image processor entity
  * @lock:	the mutex protecting this data structure
  * @vpulock:	the mutex protecting the communication with VPU
+ * @rdma_dev:  device pointer to rdma device for MDP
  * @pdev:	pointer to the image processor platform device
  * @variant:	the IP variant information
  * @id:		image processor device index (0..MTK_MDP_MAX_DEVS)
@@ -151,6 +152,7 @@ struct mtk_mdp_variant {
 struct mtk_mdp_dev {
 	struct mutex			lock;
 	struct mutex			vpulock;
+	struct device			*rdma_dev;
 	struct platform_device		*pdev;
 	struct mtk_mdp_variant		*variant;
 	u16				id;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index d351e5a44768..c80ad8299c5e 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -932,7 +932,7 @@ static int mtk_mdp_m2m_queue_init(void *priv, struct vb2_queue *src_vq,
 	src_vq->mem_ops = &vb2_dma_contig_memops;
 	src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
 	src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
-	src_vq->dev = &ctx->mdp_dev->pdev->dev;
+	src_vq->dev = ctx->mdp_dev->rdma_dev;
 	src_vq->lock = &ctx->mdp_dev->lock;
 
 	ret = vb2_queue_init(src_vq);
@@ -947,7 +947,7 @@ static int mtk_mdp_m2m_queue_init(void *priv, struct vb2_queue *src_vq,
 	dst_vq->mem_ops = &vb2_dma_contig_memops;
 	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
 	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
-	dst_vq->dev = &ctx->mdp_dev->pdev->dev;
+	dst_vq->dev = ctx->mdp_dev->rdma_dev;
 	dst_vq->lock = &ctx->mdp_dev->lock;
 
 	return vb2_queue_init(dst_vq);
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 18f93979e14a..6f9cf7725529 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -305,6 +305,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct platform_device *clks;
 	struct platform_device *drm;
+	struct platform_device *mdp;
 	void __iomem *config_regs;
 	int ret;
 
@@ -328,10 +329,27 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
 					    PLATFORM_DEVID_AUTO, NULL, 0);
 	if (IS_ERR(drm)) {
 		platform_device_unregister(clks);
-		return PTR_ERR(drm);
+		ret = PTR_ERR(drm);
+		goto err_drm;
+	}
+
+	mdp = platform_device_register_data(&pdev->dev, "mtk-mdp",
+					    PLATFORM_DEVID_AUTO, NULL, 0);
+	if (IS_ERR(mdp)) {
+		ret = PTR_ERR(mdp);
+		dev_err(dev, "Failed to register mdp: %d\n", ret);
+		goto err_mdp;
 	}
 
 	return 0;
+
+err_mdp:
+	platform_device_unregister(drm);
+
+err_drm:
+	platform_device_unregister(clks);
+
+	return ret;
 }
 
 static const struct of_device_id of_match_mtk_mmsys[] = {
-- 
2.31.1.498.g6c1eba8ee3d-goog



From eizan at chromium.org  Fri Apr 23 06:58:37 2021
From: eizan at chromium.org (Eizan Miyamoto)
Date: Fri, 23 Apr 2021 15:58:37 +1000
Subject: [PATCH v1 0/4] Refactor MTK MDP driver into core/components
Message-ID: <20210423055842.2490679-1-eizan@chromium.org>

This is an update to
https://patchwork.kernel.org/project/linux-mediatek/list/?series=283075
To address some comments and fixes.

This series has been verified to work on 5.11.

It has been rebased on top of the series
https://patchwork.kernel.org/project/linux-mediatek/list/?series=464873

The first two patches are unchanged from the previous series submission.


Eizan Miyamoto (4):
  mtk-mdp: add driver to probe mdp components
  mtk-mdp: use pm_runtime in MDP component driver
  media: mtk-mdp: don't pm_run_time_get/put for master comp in clock_on
  mtk-mdp: soc: mediatek: register mdp from mmsys

 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 191 ++++++++++++++--
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  35 +--
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 214 +++++++++++-------
 drivers/media/platform/mtk-mdp/mtk_mdp_core.h |   3 +
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  |   4 +-
 drivers/soc/mediatek/mtk-mmsys.c              |  20 +-
 6 files changed, 345 insertions(+), 122 deletions(-)

-- 
2.31.1.498.g6c1eba8ee3d-goog



From eizan at chromium.org  Fri Apr 23 06:58:39 2021
From: eizan at chromium.org (Eizan Miyamoto)
Date: Fri, 23 Apr 2021 15:58:39 +1000
Subject: [PATCH v1 2/4] mtk-mdp: use pm_runtime in MDP component driver
In-Reply-To: <20210423055842.2490679-1-eizan@chromium.org>
References: <20210423055842.2490679-1-eizan@chromium.org>
Message-ID: <20210423155824.v1.2.I909f5375d930f5d0cc877128e30e2a67078b674c@changeid>

Without this change, the MDP components are not fully integrated into
the runtime power management subsystem, and the MDP driver does not
work.

For each of the component device drivers to be able to call
pm_runtime_get/put_sync() a pointer to the component's device struct
had to be added to struct mtk_mdp_comp, set by mtk_mdp_comp_init().

Note that the dev argument to mtk_mdp_comp_clock_on/off() has been
removed. Those functions used to be called from the "master" mdp driver
in mtk_mdp_core.c, but the component's device pointer no longer
corresponds to the mdp master device pointer, which is not the right
device to pass to pm_runtime_put/get_sync() which we had to add to get
the driver to work properly.

Signed-off-by: Eizan Miyamoto <eizan at chromium.org>
---

 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 19 ++++++++++++++++---
 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h |  6 ++++--
 drivers/media/platform/mtk-mdp/mtk_mdp_core.c |  6 ++----
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
index 3fbbcf05440a..84f9c529d74a 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
@@ -13,6 +13,8 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <soc/mediatek/smi.h>
+#include <linux/pm_runtime.h>
 
 #include "mtk_mdp_comp.h"
 #include "mtk_mdp_core.h"
@@ -51,22 +53,28 @@ static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
 
-void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
+void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
 {
 	int i, err;
 
+	err = pm_runtime_get_sync(comp->dev);
+	if (err < 0)
+		dev_err(comp->dev,
+			"failed to runtime get, err %d.\n",
+			err);
+
 	for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
 		if (IS_ERR(comp->clk[i]))
 			continue;
 		err = clk_prepare_enable(comp->clk[i]);
 		if (err)
-			dev_err(dev,
+			dev_err(comp->dev,
 				"failed to enable clock, err %d. i:%d\n",
 				err, i);
 	}
 }
 
-void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
+void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
 {
 	int i;
 
@@ -75,6 +83,8 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
 			continue;
 		clk_disable_unprepare(comp->clk[i]);
 	}
+
+	pm_runtime_put_sync(comp->dev);
 }
 
 static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
@@ -84,6 +94,7 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
 	struct mtk_mdp_dev *mdp = data;
 
 	mtk_mdp_register_component(mdp, comp);
+	pm_runtime_enable(dev);
 
 	return 0;
 }
@@ -94,6 +105,7 @@ static void mtk_mdp_comp_unbind(struct device *dev, struct device *master,
 	struct mtk_mdp_dev *mdp = data;
 	struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
 
+	pm_runtime_disable(dev);
 	mtk_mdp_unregister_component(mdp, comp);
 }
 
@@ -111,6 +123,7 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
 		 (enum mtk_mdp_comp_type)of_device_get_match_data(dev);
 
 	INIT_LIST_HEAD(&comp->node);
+	comp->dev = dev;
 
 	for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
 		comp->clk[i] = of_clk_get(node, i);
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
index 956d20c01e34..355e226d74fe 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
@@ -11,16 +11,18 @@
  * struct mtk_mdp_comp - the MDP's function component data
  * @node:	list node to track sibing MDP components
  * @clk:	clocks required for component
+ * @dev:	component's device
  */
 struct mtk_mdp_comp {
 	struct list_head	node;
 	struct clk		*clk[2];
+	struct device		*dev;
 };
 
 int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev);
 
-void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp);
-void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp);
+void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp);
+void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp);
 
 extern struct platform_driver mtk_mdp_component_driver;
 
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index d79bf7f0031a..c55bcfe4cbb7 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -51,20 +51,18 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_of_ids);
 
 static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
 {
-	struct device *dev = &mdp->pdev->dev;
 	struct mtk_mdp_comp *comp_node;
 
 	list_for_each_entry(comp_node, &mdp->comp_list, node)
-		mtk_mdp_comp_clock_on(dev, comp_node);
+		mtk_mdp_comp_clock_on(comp_node);
 }
 
 static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
 {
-	struct device *dev = &mdp->pdev->dev;
 	struct mtk_mdp_comp *comp_node;
 
 	list_for_each_entry(comp_node, &mdp->comp_list, node)
-		mtk_mdp_comp_clock_off(dev, comp_node);
+		mtk_mdp_comp_clock_off(comp_node);
 }
 
 static void mtk_mdp_wdt_worker(struct work_struct *work)
-- 
2.31.1.498.g6c1eba8ee3d-goog



From a-govindraju at ti.com  Fri Apr 23 07:01:33 2021
From: a-govindraju at ti.com (Aswath Govindraju)
Date: Fri, 23 Apr 2021 11:31:33 +0530
Subject: [PATCH] arm64: dts: ti: k3-am64-mcu: Fix the compatible string in
 GPIO DT node
Message-ID: <20210423060133.16473-1-a-govindraju@ti.com>

Fix the compatible string in mcu domain GPIO device tree node.

Fixes: 01a91e01b8fd ("arm64: dts: ti: k3-am64: Add GPIO DT nodes")
Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>
---
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
index 99e94dee1bd4..892db8229f77 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -86,7 +86,7 @@
 	};
 
 	mcu_gpio0: gpio at 4201000 {
-		compatible = "ti,am64-gpio", "keystone-gpio";
+		compatible = "ti,am64-gpio", "ti,keystone-gpio";
 		reg = <0x0 0x4201000 0x0 0x100>;
 		gpio-controller;
 		#gpio-cells = <2>;
-- 
2.17.1



From shengjiu.wang at nxp.com  Fri Apr 23 06:51:47 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Fri, 23 Apr 2021 13:51:47 +0800
Subject: [PATCH 2/2] ASoC: dt-bindings: imx-akcodec: Add binding doc for
 akcodec machine driver
In-Reply-To: <1619157107-3734-1-git-send-email-shengjiu.wang@nxp.com>
References: <1619157107-3734-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <1619157107-3734-2-git-send-email-shengjiu.wang@nxp.com>

Imx-akcodec is a new added machine driver for supporting
ak4458/ak5558/ak5552/ak4497 codec on i.MX platforms.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 .../bindings/sound/imx-audio-akcodec.yaml     | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml

diff --git a/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml b/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml
new file mode 100644
index 000000000000..7419bf7224e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-akcodec.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-audio-akcodec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX audio complex with AK4458/AK5558/AK5552/AK4497 codec
+
+maintainers:
+  - Shengjiu Wang <shengjiu.wang at nxp.com>
+
+properties:
+  compatible:
+    enum:
+      - fsl,imx8mq-audio-ak4458
+      - fsl,imx8mq-audio-ak4497
+      - fsl,imx8mq-audio-ak5558
+      - fsl,imx-audio-ak4497
+      - fsl,imx-audio-ak4458
+      - fsl,imx-audio-ak5558
+      - fsl,imx-audio-ak5552
+
+  model:
+    $ref: /schemas/types.yaml#/definitions/string
+    description: User specified audio sound card name
+
+  audio-cpu:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: The phandle of a CPU DAI controller
+
+  audio-codec:
+    description: The phandle of Codec DAI controllers, there are two
+                 controllers maximum.
+
+  audio-asrc:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description: The phandle of ASRC. It can be absent if there's no
+                 need to add ASRC support via DPCM.
+
+  fsl,tdm:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description: |
+      This is a boolean property. If present, the TDM mode is enabled.
+
+required:
+  - compatible
+  - model
+  - audio-cpu
+  - audio-codec
+
+additionalProperties: false
+
+examples:
+  - |
+    sound-ak4458 {
+        compatible = "fsl,imx-audio-ak4458";
+        model = "ak4458-audio";
+        audio-cpu = <&sai1>;
+        audio-codec = <&ak4458_1>, <&ak4458_2>;
+    };
-- 
2.17.1



From shengjiu.wang at nxp.com  Fri Apr 23 06:51:46 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Fri, 23 Apr 2021 13:51:46 +0800
Subject: [PATCH 1/2] ASoC: imx-akcodec: Add imx-akcodec machine driver
Message-ID: <1619157107-3734-1-git-send-email-shengjiu.wang@nxp.com>

Add machine driver for i.MX boards that have
AK4458/AK5558/AK4497/AK5552 DAC/ADC attached to
SAI interface.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
Signed-off-by: Mihai Serban <mihai.serban at nxp.com>
Signed-off-by: Cosmin-Gabriel Samoila <cosmin.samoila at nxp.com>
Signed-off-by: Viorel Suman <viorel.suman at nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta at nxp.com>
Signed-off-by: Adrian Alonso <adrian.alonso at nxp.com>
---
 sound/soc/fsl/Kconfig       |  12 +
 sound/soc/fsl/Makefile      |   2 +
 sound/soc/fsl/imx-akcodec.c | 868 ++++++++++++++++++++++++++++++++++++
 3 files changed, 882 insertions(+)
 create mode 100644 sound/soc/fsl/imx-akcodec.c

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 0917d65d6921..5720ad36494f 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -350,6 +350,18 @@ config SND_SOC_IMX_RPMSG
 	  Say Y if you want to add support for SoC audio on an i.MX board with
 	  a rpmsg devices.
 
+config SND_SOC_IMX_AKCODEC
+	tristate "SoC Audio support for i.MX boards with AKCODEC"
+	depends on OF && I2C
+	select SND_SOC_AK4458
+	select SND_SOC_AK5558
+	select SND_SOC_IMX_PCM_DMA
+	select SND_SOC_FSL_SAI
+	help
+	  SoC Audio support for i.MX boards with AK4458/AK4497/AK5558/AK5552
+	  Say Y if you want to add support for SoC audio on an i.MX board with
+	  an AK4458/AK4497/AK5558/AK5552 DAC/ADC.
+
 endif # SND_IMX_SOC
 
 endmenu
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index f146ce464acd..ee7caed0c758 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -71,6 +71,7 @@ snd-soc-imx-spdif-objs := imx-spdif.o
 snd-soc-imx-audmix-objs := imx-audmix.o
 snd-soc-imx-hdmi-objs := imx-hdmi.o
 snd-soc-imx-rpmsg-objs := imx-rpmsg.o
+snd-soc-imx-akcodec-objs := imx-akcodec.o
 
 obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
 obj-$(CONFIG_SND_SOC_IMX_ES8328) += snd-soc-imx-es8328.o
@@ -79,3 +80,4 @@ obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
 obj-$(CONFIG_SND_SOC_IMX_AUDMIX) += snd-soc-imx-audmix.o
 obj-$(CONFIG_SND_SOC_IMX_HDMI) += snd-soc-imx-hdmi.o
 obj-$(CONFIG_SND_SOC_IMX_RPMSG) += snd-soc-imx-rpmsg.o
+obj-$(CONFIG_SND_SOC_IMX_AKCODEC) += snd-soc-imx-akcodec.o
diff --git a/sound/soc/fsl/imx-akcodec.c b/sound/soc/fsl/imx-akcodec.c
new file mode 100644
index 000000000000..606365f79a54
--- /dev/null
+++ b/sound/soc/fsl/imx-akcodec.c
@@ -0,0 +1,868 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2017-2021 NXP
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of_device.h>
+#include <linux/i2c.h>
+#include <linux/of_gpio.h>
+#include <linux/clk.h>
+#include <sound/soc.h>
+#include <sound/pcm_params.h>
+#include <sound/pcm.h>
+#include <sound/soc-dapm.h>
+
+#include "fsl_sai.h"
+
+#define MAX_CODECS 2
+
+enum codec_type {
+	CODEC_AK5558 = 1,
+	CODEC_AK4458,
+	CODEC_AK4497,
+	CODEC_AK5552,
+};
+
+/*
+ * Mapping LRCK fs and frame width, table 3 & 4 in datasheet
+ * @rmin: min rate
+ * @rmax: max rate
+ * @wmin: min frame ratio
+ * @wmax: max frame ratio
+ */
+struct imx_akcodec_fs_mul {
+	unsigned int rmin;
+	unsigned int rmax;
+	unsigned int wmin;
+	unsigned int wmax;
+};
+
+/*
+ * Mapping TDM mode and frame width
+ */
+struct imx_akcodec_tdm_fs_mul {
+	unsigned int min;
+	unsigned int max;
+	unsigned int mul;
+};
+
+/*
+ * struct imx_akcodec_plat_data - specific info for codecs
+ *
+ * @fs_mul: ratio of mclk/fs for normal mode
+ * @tdm_fs_mul: ratio of mclk/fs for tdm mode
+ * @support_rates: supported sample rate
+ * @support_tdm_rates: supported sample rate for tdm mode
+ * @support_channels: supported channels
+ * @support_tdm_channels: supported channels for tdm mode
+ * @num_fs_mul: ARRAY_SIZE of fs_mul
+ * @num_tdm_fs_mul: ARRAY_SIZE of tdm_fs_mul
+ * @num_rates: ARRAY_SIZE of support_rates
+ * @num_tdm_rates: ARRAY_SIZE of support_tdm_rates
+ * @num_channels: ARRAY_SIZE of support_channels
+ * @num_tdm_channels: ARRAY_SIZE of support_tdm_channels
+ * @num_codecs: codec number, maximum is MAX_CODECS
+ * @playback_only: only playback supported
+ * @capture_only: only capture supported
+ * @one2one_ratio: if mclk/bclk = 1 or not
+ * @tdm_is_support: if this codec support tdm
+ * @type: codec type
+ * @dai_name: codec dai name
+ */
+struct imx_akcodec_plat_data {
+	struct imx_akcodec_fs_mul  *fs_mul;
+	struct imx_akcodec_tdm_fs_mul  *tdm_fs_mul;
+	const u32 *support_rates;
+	const u32 *support_tdm_rates;
+	const u32 *support_channels;
+	const u32 *support_tdm_channels;
+	unsigned int num_fs_mul;
+	unsigned int num_tdm_fs_mul;
+	unsigned int num_rates;
+	unsigned int num_tdm_rates;
+	unsigned int num_channels;
+	unsigned int num_tdm_channels;
+	unsigned int num_codecs;
+	unsigned int playback_only;
+	unsigned int capture_only;
+	bool one2one_ratio;
+	bool tdm_is_support;
+	enum codec_type type;
+	const char *dai_name;
+};
+
+/*
+ * struct imx_akcodec_data - platform device data
+ *
+ * @card: card instance
+ * @codec_conf: pointer of codec conf
+ * @plat_data: pointer of imx_akcodec_plat_data
+ * @dai_link: snd_soc_dai_link
+ * @codecs: codec dai link component
+ * @dapm_routes: pointer of dapm_routes
+ * @asrc_pdev: pointer of asrc_pdev
+ * @num_codec_conf: number of codec conf
+ * @num_dapm_routes: number of dapm_routes
+ * @slots: slots value
+ * @slot_width: slot width value
+ * @tdm_mode: tdm mode enabled or not
+ * @asrc_rate: asrc rates
+ * @asrc_format: asrc format
+ */
+struct imx_akcodec_data {
+	struct snd_soc_card card;
+	struct snd_soc_codec_conf *codec_conf;
+	const struct imx_akcodec_plat_data *plat_data;
+	struct snd_soc_dai_link dai_link[3];
+	struct snd_soc_dai_link_component codecs[MAX_CODECS];
+	struct snd_soc_dapm_route *dapm_routes;
+	struct platform_device *asrc_pdev;
+	int num_codec_conf;
+	int num_dapm_routes;
+	unsigned int slots;
+	unsigned int slot_width;
+	bool tdm_mode;
+	u32 asrc_rate;
+	u32 asrc_format;
+};
+
+struct imx_akcodec_fs_mul ak4458_fs_mul[] = {
+	/* Normal, < 32kHz */
+	{ .rmin = 8000,   .rmax = 24000,  .wmin = 1024, .wmax = 1024, },
+	/* Normal, 32kHz */
+	{ .rmin = 32000,  .rmax = 32000,  .wmin = 256,  .wmax = 1024, },
+	/* Normal */
+	{ .rmin = 44100,  .rmax = 48000,  .wmin = 256,  .wmax = 768,  },
+	/* Double */
+	{ .rmin = 88200,  .rmax = 96000,  .wmin = 256,  .wmax = 512,  },
+	/* Quad */
+	{ .rmin = 176400, .rmax = 192000, .wmin = 128,  .wmax = 256,  },
+	/* Oct */
+	{ .rmin = 352800, .rmax = 384000, .wmin = 32,   .wmax = 128,  },
+	/* Hex */
+	{ .rmin = 705600, .rmax = 768000, .wmin = 16,   .wmax = 64,   },
+};
+
+struct imx_akcodec_tdm_fs_mul ak4458_tdm_fs_mul[] = {
+	/*
+	 * Table 13	- Audio Interface Format
+	 * For TDM mode, MCLK should is set to
+	 * obtained from 2 * slots * slot_width
+	 */
+	{ .min = 128,	.max = 128,	.mul = 256  }, /* TDM128 */
+	{ .min = 256,	.max = 256,	.mul = 512  }, /* TDM256 */
+	{ .min = 512,	.max = 512,	.mul = 1024  }, /* TDM512 */
+};
+
+struct imx_akcodec_fs_mul ak4497_fs_mul[] = {
+	/**
+	 * Table 7      - mapping multiplier and speed mode
+	 * Tables 8 & 9 - mapping speed mode and LRCK fs
+	 */
+	{ .rmin = 8000,   .rmax = 32000,  .wmin = 1024, .wmax = 1024, }, /* Normal, <= 32kHz */
+	{ .rmin = 44100,  .rmax = 48000,  .wmin = 512,  .wmax = 512, }, /* Normal */
+	{ .rmin = 88200,  .rmax = 96000,  .wmin = 256,  .wmax = 256, }, /* Double */
+	{ .rmin = 176400, .rmax = 192000, .wmin = 128,  .wmax = 128, }, /* Quad */
+	{ .rmin = 352800, .rmax = 384000, .wmin = 128,  .wmax = 128, }, /* Oct */
+	{ .rmin = 705600, .rmax = 768000, .wmin = 64,   .wmax = 64, }, /* Hex */
+};
+
+/*
+ * Auto MCLK selection based on LRCK for Normal Mode
+ * (Table 4 from datasheet)
+ */
+struct imx_akcodec_fs_mul ak5558_fs_mul[] = {
+	{ .rmin = 8000,   .rmax = 32000,  .wmin = 1024, .wmax = 1024, },
+	{ .rmin = 44100,  .rmax = 48000,  .wmin = 512,  .wmax = 512, },
+	{ .rmin = 88200,  .rmax = 96000,  .wmin = 256,  .wmax = 256, },
+	{ .rmin = 176400, .rmax = 192000, .wmin = 128,  .wmax = 128, },
+	{ .rmin = 352800, .rmax = 384000, .wmin = 64,   .wmax = 64, },
+	{ .rmin = 705600, .rmax = 768000, .wmin = 32,   .wmax = 32, },
+};
+
+/*
+ * MCLK and BCLK selection based on TDM mode
+ * because of SAI we also add the restriction: MCLK >= 2 * BCLK
+ * (Table 9 from datasheet)
+ */
+struct imx_akcodec_tdm_fs_mul ak5558_tdm_fs_mul[] = {
+	{ .min = 128,	.max = 128,	.mul = 256 },
+	{ .min = 256,	.max = 256,	.mul = 512 },
+	{ .min = 512,	.max = 512,	.mul = 1024 },
+};
+
+static const u32 akcodec_rates[] = {
+	8000, 11025, 16000, 22050, 32000, 44100, 48000, 88200,
+	96000, 176400, 192000, 352800, 384000, 705600, 768000,
+};
+
+static const u32 akcodec_tdm_rates[] = {
+	8000, 16000, 32000, 48000, 96000,
+};
+
+static const u32 ak4458_channels[] = {
+	1, 2, 4, 6, 8, 10, 12, 14, 16,
+};
+
+static const u32 ak4458_tdm_channels[] = {
+	1, 2, 3, 4, 5, 6, 7, 8, 16,
+};
+
+static const u32 ak5558_channels[] = {
+	1, 2, 4, 6, 8,
+};
+
+static const u32 ak5558_tdm_channels[] = {
+	1, 2, 3, 4, 5, 6, 7, 8,
+};
+
+static const struct imx_akcodec_plat_data imx8mq_ak4458 = {
+	.fs_mul = ak4458_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak4458_fs_mul),
+	.tdm_fs_mul = ak4458_tdm_fs_mul,
+	.num_tdm_fs_mul = ARRAY_SIZE(ak4458_tdm_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_tdm_rates = akcodec_tdm_rates,
+	.num_tdm_rates = ARRAY_SIZE(akcodec_tdm_rates),
+	.support_channels = ak4458_channels,
+	.num_channels = ARRAY_SIZE(ak4458_channels),
+	.support_tdm_channels = ak4458_tdm_channels,
+	.num_tdm_channels = ARRAY_SIZE(ak4458_tdm_channels),
+	.one2one_ratio = false,
+	.dai_name = "ak4458-aif",
+	.num_codecs = MAX_CODECS,
+	.tdm_is_support = true,
+	.playback_only = 1,
+	.capture_only = 0,
+	.type = CODEC_AK4458,
+};
+
+static const struct imx_akcodec_plat_data imx_ak4458 = {
+	.fs_mul = ak4458_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak4458_fs_mul),
+	.tdm_fs_mul = ak4458_tdm_fs_mul,
+	.num_tdm_fs_mul = ARRAY_SIZE(ak4458_tdm_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_tdm_rates = akcodec_tdm_rates,
+	.num_tdm_rates = ARRAY_SIZE(akcodec_tdm_rates),
+	.support_channels = ak4458_channels,
+	.num_channels = ARRAY_SIZE(ak4458_channels),
+	.support_tdm_channels = ak4458_tdm_channels,
+	.num_tdm_channels = ARRAY_SIZE(ak4458_tdm_channels),
+	.one2one_ratio = true,
+	.dai_name = "ak4458-aif",
+	.num_codecs = MAX_CODECS,
+	.tdm_is_support = true,
+	.playback_only = 1,
+	.capture_only = 0,
+	.type = CODEC_AK4458,
+};
+
+static const struct imx_akcodec_plat_data imx8mq_ak4497 = {
+	.fs_mul = ak4497_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak4497_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_channels = ak4458_channels,
+	.num_channels = ARRAY_SIZE(ak4458_channels),
+	.one2one_ratio = false,
+	.dai_name = "ak4497-aif",
+	.num_codecs = 1,
+	.tdm_is_support = false,
+	.playback_only = 1,
+	.capture_only = 0,
+	.type = CODEC_AK4497,
+};
+
+static const struct imx_akcodec_plat_data imx_ak4497 = {
+	.fs_mul = ak4497_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak4497_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_channels = ak4458_channels,
+	.num_channels = ARRAY_SIZE(ak4458_channels),
+	.one2one_ratio = true,
+	.dai_name = "ak4497-aif",
+	.num_codecs = 1,
+	.tdm_is_support = false,
+	.playback_only = 1,
+	.capture_only = 0,
+	.type = CODEC_AK4497,
+};
+
+static const struct imx_akcodec_plat_data imx8mq_ak5558 = {
+	.fs_mul = ak5558_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak5558_fs_mul),
+	.tdm_fs_mul = ak5558_tdm_fs_mul,
+	.num_tdm_fs_mul = ARRAY_SIZE(ak5558_tdm_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_tdm_rates = akcodec_tdm_rates,
+	.num_tdm_rates = ARRAY_SIZE(akcodec_tdm_rates),
+	.support_channels = ak5558_channels,
+	.num_channels = ARRAY_SIZE(ak5558_channels),
+	.support_tdm_channels = ak5558_tdm_channels,
+	.num_tdm_channels = ARRAY_SIZE(ak5558_tdm_channels),
+	.one2one_ratio = false,
+	.dai_name = "ak5558-aif",
+	.num_codecs = 1,
+	.tdm_is_support = true,
+	.playback_only = 0,
+	.capture_only = 1,
+	.type = CODEC_AK5558,
+};
+
+static const struct imx_akcodec_plat_data imx_ak5558 = {
+	.fs_mul = ak5558_fs_mul,
+	.num_fs_mul = ARRAY_SIZE(ak5558_fs_mul),
+	.tdm_fs_mul = ak5558_tdm_fs_mul,
+	.num_tdm_fs_mul = ARRAY_SIZE(ak5558_tdm_fs_mul),
+	.support_rates = akcodec_rates,
+	.num_rates = ARRAY_SIZE(akcodec_rates),
+	.support_tdm_rates = akcodec_tdm_rates,
+	.num_tdm_rates = ARRAY_SIZE(akcodec_tdm_rates),
+	.support_channels = ak5558_channels,
+	.num_channels = ARRAY_SIZE(ak5558_channels),
+	.support_tdm_channels = ak5558_tdm_channels,
+	.num_tdm_channels = ARRAY_SIZE(ak5558_tdm_channels),
+	.one2one_ratio = true,
+	.dai_name = "ak5558-aif",
+	.num_codecs = 1,
+	.tdm_is_support = true,
+	.playback_only = 0,
+	.capture_only = 1,
+	.type = CODEC_AK5558,
+};
+
+static bool format_is_dsd(struct snd_pcm_hw_params *params)
+{
+	snd_pcm_format_t format = params_format(params);
+
+	switch (format) {
+	case SNDRV_PCM_FORMAT_DSD_U8:
+	case SNDRV_PCM_FORMAT_DSD_U16_LE:
+	case SNDRV_PCM_FORMAT_DSD_U16_BE:
+	case SNDRV_PCM_FORMAT_DSD_U32_LE:
+	case SNDRV_PCM_FORMAT_DSD_U32_BE:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static struct snd_soc_dapm_widget imx_akcodec_dapm_widgets[] = {
+	SND_SOC_DAPM_LINE("Line Out", NULL),
+	SND_SOC_DAPM_LINE("Line In", NULL),
+};
+
+static unsigned long akcodec_get_mclk_rate(struct snd_pcm_substream *substream,
+					   struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct imx_akcodec_data *data = snd_soc_card_get_drvdata(rtd->card);
+	const struct imx_akcodec_plat_data *plat_data = data->plat_data;
+	unsigned int width = data->slots * data->slot_width;
+	unsigned int rate = params_rate(params);
+	int i;
+
+	if (data->tdm_mode) {
+		for (i = 0; i < plat_data->num_tdm_fs_mul; i++) {
+			/* min = max = slots * slots_width */
+			if (width != plat_data->tdm_fs_mul[i].min)
+				continue;
+			return rate * plat_data->tdm_fs_mul[i].mul;
+		}
+	} else {
+		for (i = 0; i < plat_data->num_fs_mul; i++) {
+			if (rate >= plat_data->fs_mul[i].rmin &&
+			    rate <= plat_data->fs_mul[i].rmax) {
+				width = max(width, plat_data->fs_mul[i].wmin);
+				width = min(width, plat_data->fs_mul[i].wmax);
+
+				/* Adjust SAI bclk:mclk ratio */
+				width *= plat_data->one2one_ratio ? 1 : 2;
+
+				return rate * width;
+			}
+		}
+	}
+
+	/* Let DAI manage clk frequency by default */
+	return 0;
+}
+
+static int imx_aif_hw_params(struct snd_pcm_substream *substream,
+			     struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
+	struct snd_soc_card *card = rtd->card;
+	struct imx_akcodec_data *data = snd_soc_card_get_drvdata(card);
+	unsigned int fmt = SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS;
+	bool is_dsd = format_is_dsd(params);
+	struct device *dev = card->dev;
+	unsigned long mclk_freq;
+	int ret, i;
+
+	if (is_dsd) {
+		data->slots = 1;
+		data->slot_width = params_width(params);
+		fmt |= SND_SOC_DAIFMT_PDM;
+	} else if (data->tdm_mode) {
+		data->slots = 8;
+		data->slot_width = 32;
+		fmt |= SND_SOC_DAIFMT_DSP_B;
+	} else {
+		data->slots = 2;
+		data->slot_width = params_physical_width(params);
+		fmt |= SND_SOC_DAIFMT_I2S;
+	}
+
+	ret = snd_soc_dai_set_fmt(cpu_dai, fmt);
+	if (ret) {
+		dev_err(dev, "failed to set cpu dai fmt: %d\n", ret);
+		return ret;
+	}
+	ret = snd_soc_dai_set_tdm_slot(cpu_dai,
+				       BIT(data->slots) - 1,
+				       BIT(data->slots) - 1,
+				       data->slots, data->slot_width);
+	if (ret) {
+		dev_err(dev, "failed to set cpu dai tdm slot: %d\n", ret);
+		return ret;
+	}
+
+	for (i = 0; i < rtd->num_codecs; i++) {
+		struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, i);
+
+		ret = snd_soc_dai_set_fmt(codec_dai, fmt);
+		if (ret) {
+			dev_err(dev, "failed to set codec dai[%d] fmt: %d\n", i, ret);
+			return ret;
+		}
+		ret = snd_soc_dai_set_tdm_slot(codec_dai,
+					       BIT(data->slots) - 1,
+					       BIT(data->slots) - 1,
+					       data->slots, data->slot_width);
+		if (ret) {
+			dev_err(dev, "failed to set codec dai[%d] tdm slot: %d\n", i, ret);
+			return ret;
+		}
+	}
+
+	/* Set MCLK freq */
+	mclk_freq = akcodec_get_mclk_rate(substream, params);
+	/* Use the maximum freq from DSD512 (512*44100 = 22579200) */
+	if (is_dsd)
+		mclk_freq = 22579200;
+
+	ret = snd_soc_dai_set_sysclk(cpu_dai, FSL_SAI_CLK_MAST1, mclk_freq,
+				     SND_SOC_CLOCK_OUT);
+	if (ret < 0)
+		dev_err(dev, "failed to set cpui dai mclk1 rate (%lu): %d\n",
+			mclk_freq, ret);
+	return ret;
+}
+
+static int ak5558_hw_rule_rate(struct snd_pcm_hw_params *p, struct snd_pcm_hw_rule *r)
+{
+	struct imx_akcodec_data *data = r->private;
+	struct snd_interval t = { .min = 8000, .max = 8000, };
+	unsigned long mclk_freq;
+	unsigned int fs;
+	int i;
+
+	fs = hw_param_interval(p, SNDRV_PCM_HW_PARAM_SAMPLE_BITS)->min;
+	fs *= data->tdm_mode ? 8 : 2;
+
+	/* Identify maximum supported rate */
+	for (i = 0; i < ARRAY_SIZE(akcodec_rates); i++) {
+		mclk_freq = fs * akcodec_rates[i];
+		/* Adjust SAI bclk:mclk ratio */
+		mclk_freq *= data->plat_data->one2one_ratio ? 1 : 2;
+
+		/* Skip rates for which MCLK is beyond supported value */
+		if (mclk_freq > 36864000)
+			continue;
+
+		if (t.max < akcodec_rates[i])
+			t.max = akcodec_rates[i];
+	}
+
+	return snd_interval_refine(hw_param_interval(p, r->var), &t);
+}
+
+static int imx_aif_startup(struct snd_pcm_substream *substream)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct snd_soc_card *card = rtd->card;
+	struct imx_akcodec_data *data = snd_soc_card_get_drvdata(card);
+	static struct snd_pcm_hw_constraint_list constraint_rates;
+	static struct snd_pcm_hw_constraint_list constraint_channels;
+	int ret = 0;
+
+	if (data->tdm_mode) {
+		constraint_channels.list = data->plat_data->support_tdm_channels;
+		constraint_channels.count = data->plat_data->num_tdm_channels;
+		constraint_rates.list = data->plat_data->support_tdm_rates;
+		constraint_rates.count = data->plat_data->num_tdm_rates;
+	} else {
+		constraint_channels.list = data->plat_data->support_channels;
+		constraint_channels.count = data->plat_data->num_channels;
+		constraint_rates.list = data->plat_data->support_rates;
+		constraint_rates.count = data->plat_data->num_rates;
+	}
+
+	ret = snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
+					 &constraint_channels);
+	if (ret)
+		return ret;
+
+	ret = snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+					 &constraint_rates);
+	if (ret)
+		return ret;
+
+	if (data->plat_data->type == CODEC_AK5558)
+		ret = snd_pcm_hw_rule_add(substream->runtime, 0,
+					  SNDRV_PCM_HW_PARAM_RATE,
+					  ak5558_hw_rule_rate, data,
+					  SNDRV_PCM_HW_PARAM_SAMPLE_BITS, -1);
+
+	return ret;
+}
+
+static int imx_aif_hw_params_be(struct snd_pcm_substream *substream,
+				struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
+	struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+	struct snd_soc_card *card = rtd->card;
+	struct device *dev = card->dev;
+	struct imx_akcodec_data *data = snd_soc_card_get_drvdata(card);
+	unsigned int slots, slot_width;
+	unsigned long mclk_freq;
+	unsigned int fmt;
+	int ret;
+
+	/* In order to support odd channels, force tdm mode for FE-BE case */
+	if (data->plat_data->tdm_is_support) {
+		fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS;
+		/* support TDM256 (8 slots * 32 bits/per slot) */
+		slots = 8;
+		slot_width = 32;
+	} else {
+		fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBS_CFS;
+		slots = 2;
+		slot_width = 32;
+	}
+
+	ret = snd_soc_dai_set_fmt(cpu_dai, fmt);
+	if (ret) {
+		dev_err(dev, "failed to set cpu dai fmt: %d\n", ret);
+		return ret;
+	}
+
+	ret = snd_soc_dai_set_fmt(codec_dai, fmt);
+	if (ret) {
+		dev_err(dev, "failed to set codec dai fmt: %d\n", ret);
+		return ret;
+	}
+
+	ret = snd_soc_dai_set_tdm_slot(cpu_dai, BIT(slots) - 1, BIT(slots) - 1,
+				       slots, slot_width);
+	if (ret) {
+		dev_err(dev, "failed to set cpu dai tdm slot: %d\n", ret);
+		return ret;
+	}
+
+	ret = snd_soc_dai_set_tdm_slot(codec_dai, BIT(slots) - 1, BIT(slots) - 1,
+				       slots, slot_width);
+	if (ret) {
+		dev_err(dev, "failed to set codec dai fmt: %d\n", ret);
+		return ret;
+	}
+
+	mclk_freq = akcodec_get_mclk_rate(substream, params);
+	ret = snd_soc_dai_set_sysclk(cpu_dai, FSL_SAI_CLK_MAST1, mclk_freq,
+				     SND_SOC_CLOCK_OUT);
+	if (ret < 0)
+		dev_err(dev, "failed to set cpu_dai mclk1 rate %lu\n",
+			mclk_freq);
+
+	return ret;
+}
+
+static struct snd_soc_ops imx_aif_ops = {
+	.hw_params = imx_aif_hw_params,
+	.startup = imx_aif_startup,
+};
+
+static struct snd_soc_ops imx_aif_ops_be = {
+	.hw_params = imx_aif_hw_params_be,
+};
+
+static int be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
+			      struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_card *card = rtd->card;
+	struct imx_akcodec_data *data = snd_soc_card_get_drvdata(card);
+	struct snd_interval *rate;
+	struct snd_mask *mask;
+
+	if (!data->asrc_pdev)
+		return -EINVAL;
+
+	rate = hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE);
+	rate->max = data->asrc_rate;
+	rate->min = data->asrc_rate;
+
+	mask = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
+	snd_mask_none(mask);
+	snd_mask_set(mask, data->asrc_format);
+
+	return 0;
+}
+
+static int imx_akcodec_probe(struct platform_device *pdev)
+{
+	struct snd_soc_dai_link_component *dlc;
+	struct device_node *codec_np[MAX_CODECS];
+	struct device_node *cpu_np = NULL;
+	struct imx_akcodec_data *data;
+	struct device_node *asrc_np = NULL;
+	char tmp[MAX_CODECS][8];
+	int ret, i;
+	u32 width;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->plat_data = of_device_get_match_data(&pdev->dev);
+
+	dlc = devm_kzalloc(&pdev->dev, 9 * sizeof(*dlc), GFP_KERNEL);
+	if (!dlc)
+		return -ENOMEM;
+
+	cpu_np = of_parse_phandle(pdev->dev.of_node, "audio-cpu", 0);
+	if (!cpu_np) {
+		dev_err(&pdev->dev, "audio dai phandle missing or invalid\n");
+		ret = -EINVAL;
+		goto fail;
+	}
+
+	/* Parse codec node */
+	for (i = 0; i < data->plat_data->num_codecs; i++) {
+		codec_np[i] = of_parse_phandle(pdev->dev.of_node, "audio-codec", i);
+		if (!codec_np[i]) {
+			dev_err(&pdev->dev, "audio codec phandle missing or invalid\n");
+			ret = -EINVAL;
+			goto fail;
+		}
+	}
+
+	asrc_np = of_parse_phandle(pdev->dev.of_node, "audio-asrc", 0);
+	if (asrc_np)
+		data->asrc_pdev = of_find_device_by_node(asrc_np);
+
+	if (of_find_property(pdev->dev.of_node, "fsl,tdm", NULL) &&
+	    data->plat_data->tdm_is_support)
+		data->tdm_mode = true;
+
+	data->num_codec_conf = data->plat_data->num_codecs;
+	data->codec_conf = devm_kzalloc(&pdev->dev,
+					data->num_codec_conf * sizeof(struct snd_soc_codec_conf),
+					GFP_KERNEL);
+	if (!data->codec_conf) {
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	data->num_dapm_routes = data->plat_data->num_codecs + 1;
+	data->dapm_routes = devm_kcalloc(&pdev->dev, data->num_dapm_routes,
+					 sizeof(struct snd_soc_dapm_route),
+					 GFP_KERNEL);
+	if (!data->dapm_routes) {
+		ret = -ENOMEM;
+		goto fail;
+	}
+
+	data->dai_link[0].name = "akcodec";
+	data->dai_link[0].stream_name = "Audio";
+	data->dai_link[0].cpus = &dlc[0];
+	data->dai_link[0].platforms = &dlc[1];
+	data->dai_link[0].codecs = data->codecs;
+	data->dai_link[0].num_cpus = 1;
+	data->dai_link[0].num_platforms = 1;
+	data->dai_link[0].num_codecs = data->plat_data->num_codecs;
+	data->dai_link[0].cpus->of_node = cpu_np;
+	data->dai_link[0].platforms->of_node = cpu_np;
+
+	for (i = 0; i < data->plat_data->num_codecs; i++) {
+		sprintf(tmp[i], "%d", i);
+		data->codec_conf[i].name_prefix = tmp[i];
+		data->codec_conf[i].dlc.of_node = codec_np[i];
+		data->codecs[i].of_node = codec_np[i];
+		data->codecs[i].dai_name = data->plat_data->dai_name;
+
+		if (data->plat_data->playback_only) {
+			data->dapm_routes[i].sink =
+				devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s %s",
+					       tmp[i], "Playback");
+			data->dapm_routes[i].source = "CPU-Playback";
+		} else {
+			data->dapm_routes[i].source =
+				devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s %s",
+					       tmp[i], "Capture");
+			data->dapm_routes[i].sink = "CPU-Capture";
+		}
+	}
+
+	if (data->plat_data->playback_only) {
+		data->dapm_routes[i].sink = "CPU-Playback";
+		data->dapm_routes[i].source = "ASRC-Playback";
+	} else {
+		data->dapm_routes[i].sink = "ASRC-Capture";
+		data->dapm_routes[i].source = "CPU-Capture";
+	}
+
+	data->dai_link[0].ops = &imx_aif_ops;
+	data->dai_link[0].ignore_pmdown_time = 1;
+	data->dai_link[0].playback_only = data->plat_data->playback_only;
+	data->dai_link[0].capture_only = data->plat_data->capture_only;
+
+	data->card.codec_conf = data->codec_conf;
+	data->card.num_configs = data->num_codec_conf;
+	data->card.dai_link = &data->dai_link[0];
+	data->card.num_links = 1;
+	data->card.dev = &pdev->dev;
+	data->card.owner = THIS_MODULE;
+	data->card.dapm_widgets = imx_akcodec_dapm_widgets;
+	data->card.num_dapm_widgets = ARRAY_SIZE(imx_akcodec_dapm_widgets);
+
+	/*if there is no asrc controller, we only enable one device*/
+	if (data->asrc_pdev) {
+		data->dai_link[1].name = "HiFi-ASRC-FE";
+		data->dai_link[1].stream_name = "HiFi-ASRC-FE";
+		data->dai_link[1].dynamic = 1;
+		data->dai_link[1].ignore_pmdown_time = 1;
+		data->dai_link[1].dpcm_playback = data->plat_data->playback_only;
+		data->dai_link[1].dpcm_capture = data->plat_data->capture_only;
+		data->dai_link[1].dpcm_merged_chan = 1;
+
+		data->dai_link[1].cpus = &dlc[2];
+		data->dai_link[1].platforms = &dlc[3];
+		data->dai_link[1].codecs = &dlc[4];
+		data->dai_link[1].num_cpus = 1;
+		data->dai_link[1].num_platforms = 1;
+		data->dai_link[1].num_codecs = 1;
+		data->dai_link[1].cpus->of_node  = asrc_np;
+		data->dai_link[1].platforms->of_node  = asrc_np;
+		data->dai_link[1].codecs->name = "snd-soc-dummy";
+		data->dai_link[1].codecs->dai_name = "snd-soc-dummy-dai";
+
+		data->dai_link[2].cpus = &dlc[5];
+		data->dai_link[2].platforms = &dlc[6];
+		data->dai_link[2].codecs = data->codecs;
+		data->dai_link[2].num_cpus = 1;
+		data->dai_link[2].num_platforms = 1;
+		data->dai_link[2].num_codecs = data->plat_data->num_codecs;
+
+		data->dai_link[2].name = "HiFi-ASRC-BE";
+		data->dai_link[2].stream_name = "HiFi-ASRC-BE";
+		data->dai_link[2].cpus->of_node = cpu_np;
+		data->dai_link[2].platforms->name = "snd-soc-dummy";
+		data->dai_link[2].ops = &imx_aif_ops_be;
+		data->dai_link[2].be_hw_params_fixup = be_hw_params_fixup;
+		data->dai_link[2].no_pcm = 1;
+		data->dai_link[2].ignore_pmdown_time = 1;
+		data->dai_link[2].dpcm_playback = data->plat_data->playback_only;
+		data->dai_link[2].dpcm_capture = data->plat_data->capture_only;
+
+		data->card.dapm_routes = data->dapm_routes;
+		data->card.num_dapm_routes = data->num_dapm_routes;
+		data->card.num_links = 3;
+
+		ret = of_property_read_u32(asrc_np, "fsl,asrc-rate",
+					   &data->asrc_rate);
+		if (ret) {
+			dev_err(&pdev->dev, "failed to get output rate\n");
+			ret = -EINVAL;
+			goto fail;
+		}
+
+		ret = of_property_read_u32(asrc_np, "fsl,asrc-format",
+					   &data->asrc_format);
+		if (ret) {
+			/* Fallback to old binding; translate to asrc_format */
+			ret = of_property_read_u32(asrc_np, "fsl,asrc-width",
+						   &width);
+			if (ret) {
+				dev_err(&pdev->dev,
+					"failed to decide output format\n");
+				goto fail;
+			}
+
+			if (width == 24)
+				data->asrc_format = SNDRV_PCM_FORMAT_S24_LE;
+			else
+				data->asrc_format = SNDRV_PCM_FORMAT_S16_LE;
+		}
+	}
+
+	ret = snd_soc_of_parse_card_name(&data->card, "model");
+	if (ret)
+		goto fail;
+
+	snd_soc_card_set_drvdata(&data->card, data);
+	ret = devm_snd_soc_register_card(&pdev->dev, &data->card);
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);
+		goto fail;
+	}
+
+	ret = 0;
+fail:
+	if (cpu_np)
+		of_node_put(cpu_np);
+
+	for (i = 0; i < data->plat_data->num_codecs; i++)
+		if (codec_np[i])
+			of_node_put(codec_np[i]);
+
+	return ret;
+}
+
+static const struct of_device_id imx_akcodec_dt_ids[] = {
+	{ .compatible = "fsl,imx8mq-audio-ak4458", .data = &imx8mq_ak4458, },
+	{ .compatible = "fsl,imx8mq-audio-ak4497", .data = &imx8mq_ak4497, },
+	{ .compatible = "fsl,imx8mq-audio-ak5558", .data = &imx8mq_ak5558, },
+	{ .compatible = "fsl,imx-audio-ak4458", .data = &imx_ak4458, },
+	{ .compatible = "fsl,imx-audio-ak4497", .data = &imx_ak4497, },
+	{ .compatible = "fsl,imx-audio-ak5558", .data = &imx_ak5558, },
+	{ .compatible = "fsl,imx-audio-ak5552", .data = &imx_ak5558, },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, imx_akcodec_dt_ids);
+
+static struct platform_driver imx_akcodec_driver = {
+	.driver = {
+		.name = "imx-akcodec",
+		.pm = &snd_soc_pm_ops,
+		.of_match_table = imx_akcodec_dt_ids,
+	},
+	.probe = imx_akcodec_probe,
+};
+module_platform_driver(imx_akcodec_driver);
+
+MODULE_DESCRIPTION("Freescale i.MX AK CODEC ASoC machine driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:imx-akcodec");
-- 
2.17.1



From chunfeng.yun at mediatek.com  Fri Apr 23 07:06:48 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 23 Apr 2021 14:06:48 +0800
Subject: [PATCH 1/2] usb: xhci-mtk: remove unnecessary assignments in
 periodic TT scheduler
In-Reply-To: <YIJZvN8py7s+Zq6I@kroah.com>
References: <20210330080617.3746932-1-ikjn@chromium.org>
 <20210330160508.1.I797d214790033d0402d19ff6b47a34aff60d3062@changeid>
 <1617179455.2752.1.camel@mhfsdcap03> <YGq2YfURFApdJLxb@kroah.com>
 <1617675492.22435.4.camel@mhfsdcap03> <YIE3z7qYNtk7G/VB@kroah.com>
 <1619148391.4048.6.camel@mhfsdcap03> <YIJZvN8py7s+Zq6I@kroah.com>
Message-ID: <1619158008.4048.10.camel@mhfsdcap03>

On Fri, 2021-04-23 at 07:23 +0200, Greg Kroah-Hartman wrote:
> On Fri, Apr 23, 2021 at 11:26:31AM +0800, Chunfeng Yun wrote:
> > On Thu, 2021-04-22 at 10:46 +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Apr 06, 2021 at 10:18:12AM +0800, Chunfeng Yun wrote:
> > > > On Mon, 2021-04-05 at 09:04 +0200, Greg Kroah-Hartman wrote:
> > > > > On Wed, Mar 31, 2021 at 04:30:55PM +0800, Chunfeng Yun wrote:
> > > > > > cc Yaqii Wu <Yaqii.Wu at mediatek.com>
> > > > > > 
> > > > > > I'll test it , thanks
> > > > > 
> > > > > Did you test this series and find any problems?  If not, I'll go queue
> > > > > these up...
> > > > Yes, found an issue on the start-split transaction, but not found the
> > > > root cause yet :(
> > > 
> > > So you are objecting to these being merged at this point in time? 
> > Yes
> > 
> > >  Can
> > > you provide feedback to the author about what is wrong?
> > Already provided feedback add discussed on issue tracker in private
> 
> That doesn't help us much as we can't see that :(
> 
> Please always keep us informed as to what is going on with publically
> posted changes, otherwise you could find them being picked up and merged
> into trees without an objection.
Got it.
I'll update status when find the root cause of SS transaction issue,
thanks a lot.

> 
> thanks,
> 
> greg k-h


From adrian.hunter at intel.com  Fri Apr 23 07:18:47 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 23 Apr 2021 09:18:47 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <efe71230-5b6a-22a8-1aef-f1cae046df22@intel.com>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
 <fdadd467-b613-d800-18c5-be064396fd10@intel.com>
 <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
 <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>
 <1bc4a73e-b22a-6bad-2583-3a0ffa979414@intel.com>
 <651f5d8a-5ab7-77dd-3fed-05feb3fd3e1a@codeaurora.org>
 <efe71230-5b6a-22a8-1aef-f1cae046df22@intel.com>
Message-ID: <e6f3946a-dbe7-6b42-e43c-d3f8d705c732@intel.com>

On 23/04/21 7:23 am, Adrian Hunter wrote:
> On 22/04/21 7:38 pm, Asutosh Das (asd) wrote:
>> On 4/20/2021 12:42 AM, Adrian Hunter wrote:
>>> On 20/04/21 7:15 am, Adrian Hunter wrote:
>>>> On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
>>>>> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>>>>>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>>>>>
>>>>>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>>>>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>>>>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>>>>>> ---
>>>>>>
>>>>>> I came across 3 issues while testing.? See comments below.
>>>>>>
>>>>> Hi Adrian
>>>>> Thanks for the comments.
>>>>>> <SNIP>
>>>>>>
>>>>>>> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>>>>>>> ?????? if (ufshcd_is_clkscaling_supported(hba))
>>>>>>> ?????????? ufshcd_clk_scaling_suspend(hba, false);
>>>>>>> ?????? ufshcd_clear_ua_wluns(hba);
>>>>>>
>>>>>> ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
>>>>>> if sdev_rpmb is suspended and sdev_ufs_device is suspending.
>>>>>> e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
>>>>>> is running, at which point sdev_rpmb has already suspended.
>>>>>>
>>>>> Umm, I didn't understand this deadlock.
>>>>> When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
>>>>> sdev_ufs_device is suspending - this can't be runtime_suspending, while ufshcd_err_handling_unprepare is running.
>>>>>
>>>>> If you've a call-stack of this deadlock, please can you share it with me. I'll also try to reproduce this.
>>>>
>>>> Yes it is system suspend. sdev_rpmb has suspended, sdev_ufs_device is waiting on host_sem.
>>>> ufshcd_err_handler() holds host_sem. ufshcd_clear_ua_wlun(UFS_UPIU_RPMB_WLUN) gets stuck.
>>>> I will get some call-stacks.
>>>
>> Hi Adrian,
>>
>> Thanks for the call stacks.
>> From the current information, I can't say for sure why it'd get stuck in blk_queue_enter().
> 
> I presume SCSI is leaving the RPMB WLUN device runtime suspended and consequently the queue status is RPM_SUSPENDED
> 
>>
>> I tried reproducing this issue on my setup yesterday but couldn't.
>> Here's what I did:
>> 1. sdev_rpmb is RPM_SUSPENDED, checked before initiating system suspend
>> 2. sdev_ufs_device is RPM_RESUMED
>> 3. I triggered system suspend (echo mem > /sys/power/state) and scheduled the error handler from ufshcd_wl_suspend().
>> 4. Waited until error handler ran and then ufshcd_wl_suspend() blocks on host_sem.
>> 5. The ufshcd_clear_wa_wlun(UFS_UPIU_RPMB_WLUN) went through fine.
>>
>> Do you've some specific steps to reproduce this or a script, perhaps? If so, please can you share it with me. I will try again.
> 
> I was using a device that gives occasional errors, but I will what see I can do.

I have attached 2 patches to reproduce the issue, and the test script I used.
Note it is using down_timeout() so it doesn't lock up completely.
The kernel messages are:

[   79.385456] ufshcd_wl_suspend: doing ufshcd_schedule_eh_work
[   79.385511] ufshcd_wl_suspend: sleeping 1000 ms
[   79.386916] ufshcd_err_handler: start
[   79.386979] ufshcd_err_handler: got sem
[   79.387053] ufshcd_err_handling_unprepare: start
[   79.387302] ufshcd_clear_ua_wluns: before ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN)
[   80.435878] ufshcd_wl_suspend: trying to get sem
[   85.683876] ufshcd_wl_suspend: failed to get sem
[   85.683993] ufs_device_wlun 0:0:0:49488: PM: failed to suspend async: error -22
[   85.686901] ufshcd_clear_ua_wluns: after ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN), ret 0
[   85.687025] ufshcd_err_handling_unprepare: finish
[   85.687090] ufshcd_err_handler: finish 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-changes-suggested-since-v20.patch
Type: text/x-patch
Size: 3276 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210423/632b9dfc/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-instrumentation-to-reproduce-issue.patch
Type: text/x-patch
Size: 3068 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210423/632b9dfc/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: go.sh
Type: application/x-shellscript
Size: 316 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210423/632b9dfc/attachment-0002.bin>

From ruifeng.zhang0110 at gmail.com  Fri Apr 23 07:25:25 2021
From: ruifeng.zhang0110 at gmail.com (Ruifeng Zhang)
Date: Fri, 23 Apr 2021 14:25:25 +0800
Subject: [PATCH v2 0/1] arm: topology: parse the topology from the dt
In-Reply-To: <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com>
References: <20210414122326.5255-1-ruifeng.zhang0110@gmail.com>
 <8735vrmnc7.mognet@arm.com> <b7a76995-f6c3-67c5-b14e-d40587495d7e@arm.com>
 <CAG7+-3Nv=m0pd8t0eQEUv5zSeg86hfkKcs_VLzsbzWFabYbTTQ@mail.gmail.com>
 <87wnt2lglo.mognet@arm.com> <44ab835f-3456-6bd9-97e9-5936cf5372da@arm.com>
 <CAG7+-3OgN4Kx3Md1tOmqHDLs94DSv2puh=kA0oFMw+aZGnb3iw@mail.gmail.com>
 <2a4efeea-cc70-ca0a-81fd-84d8b54586c0@arm.com>
 <CAG7+-3MX8Ntzh-fiTFZq-d9EO4GNpY2b3AuAOZPxVmxA=jNtNg@mail.gmail.com>
 <31faf969-c8fe-1acf-e78f-793a37b8d0b2@arm.com>
Message-ID: <CAG7+-3OMkC_tYEKeXW6MGrsTbEsf6iUG24-9TYJGL-Kh6Dr83A@mail.gmail.com>

Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?20??? ??5:27???
>
> On 19/04/2021 04:55, Ruifeng Zhang wrote:
> > Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?17??? ??1:00???
> >>
> >> On 16/04/2021 13:04, Ruifeng Zhang wrote:
> >>> Dietmar Eggemann <dietmar.eggemann at arm.com> ?2021?4?16??? ??6:39???
> >>>>
> >>>> On 16/04/2021 11:32, Valentin Schneider wrote:
> >>>>> On 16/04/21 15:47, Ruifeng Zhang wrote:
>
> [...]
>
> >> I'm afraid that this is now a much weaker case to get this into
> >> mainline.
> >
> > But it's still a problem and it's not break the original logic ( parse
> > topology from MPIDR or parse capacity ), only add the support for
> > parse topology from DT.
> > I think it should still be merged into the mainline. If don't, the
> > DynamIQ SoC has some issue in sched and cpufreq.
>
> IMHO, not necessarily. Your DynamIQ SoC is one cluster with 8 CPUs. It's
> subdivided into 2 Frequency Domains (FDs).
>
> CFS Energy-Aware-Scheduling (EAS, find_energy_efficient_cpu()) and
> Capacity-Aware-Scheduling (CAS, select_idle_sibling() ->
> select_idle_capacity()) work correctly even in case you only have an MC
> sched domain (sd).
> No matter which sd (MC, DIE) the sd_asym_cpucapacity is, we always
> iterate over all CPUs. Per Performance Domains (i.e. FDs) in EAS and
> over sched_domain_span(sd) in CAS.
>
> CFS load-balancing (in case your system is `over-utilized`) might work
> slightly different due to the missing DIE sd but not inevitably worse.
>
> Do you have benchmarks or testcases in mind which convince you that
> Phantom Domains is something you would need? BTW, they are called
> Phantom since they let you use uarch and/or max CPU frequency domain to
> fake real topology (like LLC) boundaries.

I'm researching the impact of all CPUs in the same cluster, such as
DVFS. If there is any progress in the future, I hope to keep
communicating with you. Thank you very much.
>
> [...]
>
> > Why do you keep the logic of topology_parse_cpu_capacity in arm
> > get_coretype_capacity function? The capacity-dmips-mhz will be parsed
> > by drivers/base/arch_topology.c as following:
> > parse_dt_topology
> >     parse_cluster
> >         parse_core
> >             get_cpu_for_node
> >                 topology_parse_cpu_capacity
>
> I think we still need it for systems out there w/o cpu-map in dt, like
> my arm32 TC2 with mainline vexpress-v2p-ca15_a7.dts.
>
> It's called twice on each CPU in case I add the cpu-map dt entry though.


From lars at metafoo.de  Fri Apr 23 07:33:51 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 23 Apr 2021 08:33:51 +0200
Subject: [PATCH 4/4] dmaengine: xilinx_dma: Add device synchronisation
 callback
In-Reply-To: <20210423011913.13122-5-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <20210423011913.13122-5-adrian.martinezlarumbe@imgtec.com>
Message-ID: <4f286de6-ab91-ffd1-1119-cd94e5805aa9@metafoo.de>

On 4/23/21 3:19 AM, Adrian Larumbe wrote:
> This was required as an answer to a very unusual race condition, whereby a
> thread waiting on a completion signaled in a callback triggered by
> dmaengine_desc_callback_invoke might immediately attempt to release the
> DMA channel whilst the channel lock was still free. This would cause the
> remaining descriptors to be deallocated, and xilinx_dma_chan_desc_cleanup
> to perform an invalid memory access when attempting to traverse the rest
> of the channel's done_list.
>
> Now, when releasing a DMA channel, it will wait until the tasklet has
> finished.
>
> Signed-off-by: Adrian Larumbe <adrian.martinezlarumbe at imgtec.com>

Hi,


Patch looks good, but basically the same got already applied a few weeks 
ago.

See 
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/commit/?h=next&id=50db2050faf854cbaf4b6557a7a8ca21bff302ae

- Lars

> ---
>   drivers/dma/xilinx/xilinx_dma.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 40c6cf8bf0e6..d4bad999e7f9 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -942,6 +942,13 @@ static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
>   
>   }
>   
> +static void xilinx_dma_synchronize(struct dma_chan *dchan)
> +{
> +	struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
> +
> +	tasklet_kill(&chan->tasklet);
> +}
> +
>   /**
>    * xilinx_dma_get_residue - Compute residue for a given descriptor
>    * @chan: Driver specific dma channel
> @@ -3235,6 +3242,7 @@ static int xilinx_dma_probe(struct platform_device *pdev)
>   	xdev->common.device_tx_status = xilinx_dma_tx_status;
>   	xdev->common.device_issue_pending = xilinx_dma_issue_pending;
>   	xdev->common.device_config = xilinx_dma_slave_config;
> +	xdev->common.device_synchronize = xilinx_dma_synchronize;
>   	if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
>   		dma_cap_set(DMA_CYCLIC, xdev->common.cap_mask);
>   		xdev->common.device_prep_slave_sg = xilinx_dma_prep_slave_sg;




From punit1.agrawal at toshiba.co.jp  Fri Apr 23 07:37:25 2021
From: punit1.agrawal at toshiba.co.jp (Punit Agrawal)
Date: Fri, 23 Apr 2021 15:37:25 +0900
Subject: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE
In-Reply-To: <01e78b64-8ad1-dfc8-9fc0-6afff4841492@xilinx.com> (Michal Simek's
 message of "Thu, 22 Apr 2021 12:54:00 +0200")
References: <20210421134844.3297838-1-arnd@kernel.org>
 <871rb2swd9.fsf@kokedama.swc.toshiba.co.jp>
 <01e78b64-8ad1-dfc8-9fc0-6afff4841492@xilinx.com>
Message-ID: <87v98dqzfe.fsf@kokedama.swc.toshiba.co.jp>

Michal Simek <michal.simek at xilinx.com> writes:

> Hi,
>
> On 4/22/21 7:48 AM, Punit Agrawal wrote:
>> Hi Arnd,
>> 
>> Thanks for the fix.
>> 
>> Arnd Bergmann <arnd at kernel.org> writes:
>> 
>>> From: Arnd Bergmann <arnd at arndb.de>
>>>
>>> When the firmware code is disabled, the incomplete error handling
>>> in the clk driver causes compile-time warnings:
>>>
>>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>>> drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized]
>>>   147 |         rate =  parent_rate * fbdiv;
>>>       |                 ~~~~~~~~~~~~^~~~~~~
>>> In function 'zynqmp_pll_get_mode',
>>>     inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6:
>>> drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized]
>>>    61 |         return ret_payload[1];
>>>       |                ~~~~~~~~~~~^~~
>>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>>> drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here
>>>    53 |         u32 ret_payload[PAYLOAD_ARG_CNT];
>>>       |             ^~~~~~~~~~~
>>> drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent':
>>> drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized]
>>>    57 |         return val;
>>>       |                ^~~
>> 
>> 
>> Not sure what I am missing but I couldn't reproduce these warnings. I
>> tried a few different ways to toggle CONFIG_ZYNQMP_FIRMWARE.
>> 
>> Regardless...
>
> Me too. Can you share your .config file?
>
>> 
>>> As it was apparently intentional to support this for compile testing
>>> purposes, change the code to have just enough error handling for the
>>> compiler to not notice the remaining bugs.
>>>
>>> Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP")
>>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>>> ---
>>>  drivers/clk/zynqmp/clk-mux-zynqmp.c | 4 +++-
>>>  drivers/clk/zynqmp/pll.c            | 8 ++++++--
>>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/zynqmp/clk-mux-zynqmp.c b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> index 06194149be83..2afded3c7c11 100644
>>> --- a/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> +++ b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> @@ -50,9 +50,11 @@ static u8 zynqmp_clk_mux_get_parent(struct clk_hw *hw)
>>>  
>>>  	ret = zynqmp_pm_clock_getparent(clk_id, &val);
>>>  
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() getparent failed for clock: %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return ret;
>
> return should be u8 and this can be negative value. That's why I think
> this should be fixed differently and all users should be checked that it
> is handled like that.
>
>
>>> +	}
>>>  
>>>  	return val;
>>>  }
>>> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
>>> index abe6afbf3407..67d2a2d260c1 100644
>>> --- a/drivers/clk/zynqmp/pll.c
>>> +++ b/drivers/clk/zynqmp/pll.c
>>> @@ -54,9 +54,11 @@ static inline enum pll_mode zynqmp_pll_get_mode(struct clk_hw *hw)
>>>  	int ret;
>>>  
>>>  	ret = zynqmp_pm_get_pll_frac_mode(clk_id, ret_payload);
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() PLL get frac mode failed for %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return ret;
>>> +	}
>
> Return should be enum pll_mode which is 0 or 1 which is likely not done
> here.
>
>>>  
>>>  	return ret_payload[1];
>>>  }
>>> @@ -140,9 +142,11 @@ static unsigned long zynqmp_pll_recalc_rate(struct clk_hw *hw,
>>>  	int ret;
>>>  
>>>  	ret = zynqmp_pm_clock_getdivider(clk_id, &fbdiv);
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() get divider failed for %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return -1ul;
>>> +	}
>
> Same here.
>
>
>>>  
>>>  	rate =  parent_rate * fbdiv;
>>>  	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
>> 
>> The changes make sense in that the functions error out sensibly when the
>> zynqmp firmware driver is not enabled.
>> 
>> Acked-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>
>
> I think code should be checked that these error values are handled how
> they should be handled.

I only looked at it from the point of view of getting rid of the
warnings - based on the commit log, Arnd's patch is only taking care of
the compiler warnings when the driver is built with
CONFIG_COMPILE_TEST=y and likely CONFIG_ZYNQMP_FIRMWARE=n.

In practice, the code should not be hit at runtime due to the dependency
on the firmware driver. Even then, a better fix would indeed be taking
the returned values at call sites into account.

[...]


From a-govindraju at ti.com  Fri Apr 23 07:47:57 2021
From: a-govindraju at ti.com (Aswath Govindraju)
Date: Fri, 23 Apr 2021 12:17:57 +0530
Subject: [PATCH] arm64: dts: ti: k3-j7200: Remove "#address-cells" property
 from GPIO DT nodes
Message-ID: <20210423064758.25520-1-a-govindraju@ti.com>

GPIO device tree nodes do not have child nodes. Therefore, "#address-cells"
property should not be added.

Fixes: e0b2e6af39ea ("arm64: dts: ti: k3-j7200: Add gpio nodes")
Signed-off-by: Aswath Govindraju <a-govindraju at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi       | 4 ----
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 --
 2 files changed, 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index 07c0ce484cae..829b5db565f5 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -693,7 +693,6 @@
 			     <149>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <69>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
@@ -711,7 +710,6 @@
 			     <158>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <69>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
@@ -729,7 +727,6 @@
 			     <167>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <69>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 109 TI_SCI_PD_EXCLUSIVE>;
@@ -747,7 +744,6 @@
 			     <176>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <69>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 111 TI_SCI_PD_EXCLUSIVE>;
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 5e74e43822c3..d865805eeff2 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -116,7 +116,6 @@
 		interrupts = <103>, <104>, <105>, <106>, <107>, <108>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <85>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 113 TI_SCI_PD_EXCLUSIVE>;
@@ -133,7 +132,6 @@
 		interrupts = <112>, <113>, <114>, <115>, <116>, <117>;
 		interrupt-controller;
 		#interrupt-cells = <2>;
-		#address-cells = <0>;
 		ti,ngpio = <85>;
 		ti,davinci-gpio-unbanked = <0>;
 		power-domains = <&k3_pds 114 TI_SCI_PD_EXCLUSIVE>;
-- 
2.17.1



From hsinyi at chromium.org  Fri Apr 23 07:53:28 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Fri, 23 Apr 2021 14:53:28 +0800
Subject: [PATCH] arm64: dts: mt8183: add mediatek,gce-events in mutex
Message-ID: <20210423065327.1596075-1-hsinyi@chromium.org>

mediatek,gce-events is read by mutex node.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c5e822b6b77a..cf22d71161e5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1250,6 +1250,8 @@ mutex: mutex at 14016000 {
 			reg = <0 0x14016000 0 0x1000>;
 			interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
 			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+			mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
+					      <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
 		};
 
 		larb0: larb at 14017000 {
-- 
2.31.1.498.g6c1eba8ee3d-goog



From wangqing at vivo.com  Fri Apr 23 08:12:24 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Fri, 23 Apr 2021 15:12:24 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSCBWNyAxLzJdIHdhdGNoZG9nOiBtdGs6IHN1cHBvcnQgcHJlLXRpbWVvdXQgd2hlbiB0aGUgYmFyayBpcnEgaXMgYXZhaWxhYmxl?=
In-Reply-To: <3acb9bb1-763b-5af7-de3c-d7d8d3f5b2f7@roeck-us.net>
Message-ID: <AGAAwgADDgCvfda5u2TY64qq.3.1619161944242.Hmail.wangqing@vivo.com>


>On 4/22/21 8:48 PM, ?? wrote:
>> 
>>> On 4/22/21 7:53 PM, Wang Qing wrote:
>>>> Use the bark interrupt as the pretimeout notifier if available.
>>>>
>>>> When the watchdog timer expires in dual mode, an interrupt will be
>>>> triggered first, then the timing restarts. The reset signal will be
>>>> initiated when the timer expires again.
>>>>
>>>> The pretimeout notification shall occur at timeout-sec/2.
>>>>
>>>> V2:
>>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
>>>>
>>>> V3:
>>>> - Modify the pretimeout behavior, manually reset after the pretimeout
>>>> - is processed and wait until timeout.
>>>>
>>>> V4:
>>>> - Remove pretimeout related processing. 
>>>> - Add dual mode control separately.
>>>>
>>>> V5:
>>>> - Fix some formatting and printing problems.
>>>>
>>>> V6:
>>>> - Realize pretimeout processing through dualmode.
>>>>
>>>> V7:
>>>> - Add set_pretimeout().
>>>>
>>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
>>>> ---
>>>>  drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
>>>>  1 file changed, 71 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
>>>> index 97ca993..ab3ac5d
>>>> --- a/drivers/watchdog/mtk_wdt.c
>>>> +++ b/drivers/watchdog/mtk_wdt.c
>>>> @@ -25,6 +25,7 @@
>>>>  #include <linux/reset-controller.h>
>>>>  #include <linux/types.h>
>>>>  #include <linux/watchdog.h>
>>>> +#include <linux/interrupt.h>
>>>>  
>>>>  #define WDT_MAX_TIMEOUT		31
>>>>  #define WDT_MIN_TIMEOUT		1
>>>> @@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>>>>  {
>>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
>>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	unsigned int timeout_interval = timeout;
>>>>  	u32 reg;
>>>>  
>>>>  	wdt_dev->timeout = timeout;
>>>> -
>>>> +	/*
>>>> +	 * In dual mode, irq will be triggered at timeout / 2
>>>> +	 * the real timeout occurs at timeout
>>>> +	 */
>>>> +	if (wdt_dev->pretimeout) {
>>>> +		wdt_dev->pretimeout = timeout / 2;
>>>
>>> min_timeout is set to 1. I don't this works well if timeout == 1.
>>> You'll either need to set min_timeout to 2, or handle that case.
>> 
>> It is appropriate to change min_timeout  to 2.
>> 
>>>
>>>> +		timeout_interval = wdt_dev->pretimeout;
>>>
>>> timeout_interval is unnecessary. Just update timeout accordingly.
>>> It needs to take the situation of timeout == 1 into account, though.

I plan to remove timeout_interval and directly use (timeout-pretimeout)
update timeout.

>> 
>> timeout represents the reset time. When the user calls timeout_show, 
>> He hopes to get the configured timeout, not the value changed
>> by pre-timeout.
>> I modify it like this more in line with the original intention.
>> 
>>>
>>>> +	}
>>>>  	/*
>>>>  	 * One bit is the value of 512 ticks
>>>>  	 * The clock has 32 KHz
>>>>  	 */
>>>> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
>>>> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
>>>>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>>>>  
>>>>  	mtk_wdt_ping(wdt_dev);
>>>> @@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>>>>  		return ret;
>>>>  
>>>>  	reg = ioread32(wdt_base + WDT_MODE);
>>>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>> +	if (wdt_dev->pretimeout)
>>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>> +	else
>>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>>>>  	iowrite32(reg, wdt_base + WDT_MODE);
>>>>  
>>>>  	return 0;
>>>>  }
>>>>  
>>>> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
>>>> +					unsigned int timeout)
>>>> +{
>>>> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
>>>> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
>>>> +	u32 reg = ioread32(wdt_base + WDT_MODE);
>>>> +
>>>> +	if (timeout && !wdd->pretimeout) {
>>>> +		wdd->pretimeout = wdd->timeout / 2;
>>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>> +	} else if (!timeout && wdd->pretimeout) {
>>>> +		wdd->pretimeout = 0;
>>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>>>> +	} else
>>>> +		return 0;
>>>> +
>>>> +	iowrite32(reg, wdt_base + WDT_MODE);
>>>
>>> What is the point of setting the mode here ? It will
>>> be set again in mtk_wdt_set_timeout(). Seems to me all
>>> you need to do here is to set wdd->pretimeout,
>>> then call mtk_wdt_set_timeout().
>> 
>> mtk_wdt_set_timeout() only set timeout and ping().
>> Here also need to config to the dualmode or not.
>> 
>Ah, you are correct. Sorry, I confused this with the start function.
>That makes me wonder if it would be better to extract a separate
>function, mtk_wdt_set_mode(), for that purpose. Thoughts ?

I have done this, but I found there is no good abstract method, 
because wdt mode is used in combination, for example?
WDT_MODE_EN is included in start(), and here is not.
And the judgment of pretimeout here is also different.

Thanks,
Qing

>
>Thanks,
>Guenter
>
>> Thanks,
>> Qing
>>>
>>> Guenter
>>>
>>>> +
>>>> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
>>>> +}
>>>> +
>>>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
>>>> +{
>>>> +	struct watchdog_device *wdd = arg;
>>>> +
>>>> +	watchdog_notify_pretimeout(wdd);
>>>> +
>>>> +	return IRQ_HANDLED;
>>>> +}
>>>> +
>>>>  static const struct watchdog_info mtk_wdt_info = {
>>>>  	.identity	= DRV_NAME,
>>>>  	.options	= WDIOF_SETTIMEOUT |
>>>> @@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
>>>>  			  WDIOF_MAGICCLOSE,
>>>>  };
>>>>  
>>>> +static const struct watchdog_info mtk_wdt_pt_info = {
>>>> +	.identity	= DRV_NAME,
>>>> +	.options	= WDIOF_SETTIMEOUT |
>>>> +			  WDIOF_PRETIMEOUT |
>>>> +			  WDIOF_KEEPALIVEPING |
>>>> +			  WDIOF_MAGICCLOSE,
>>>> +};
>>>> +
>>>>  static const struct watchdog_ops mtk_wdt_ops = {
>>>>  	.owner		= THIS_MODULE,
>>>>  	.start		= mtk_wdt_start,
>>>>  	.stop		= mtk_wdt_stop,
>>>>  	.ping		= mtk_wdt_ping,
>>>>  	.set_timeout	= mtk_wdt_set_timeout,
>>>> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>>>>  	.restart	= mtk_wdt_restart,
>>>>  };
>>>>  
>>>> @@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>>>  	struct device *dev = &pdev->dev;
>>>>  	struct mtk_wdt_dev *mtk_wdt;
>>>>  	const struct mtk_wdt_data *wdt_data;
>>>> -	int err;
>>>> +	int err, irq;
>>>>  
>>>>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>>>>  	if (!mtk_wdt)
>>>> @@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>>>>  	if (IS_ERR(mtk_wdt->wdt_base))
>>>>  		return PTR_ERR(mtk_wdt->wdt_base);
>>>>  
>>>> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>>>> +	irq = platform_get_irq(pdev, 0);
>>>> +	if (irq > 0) {
>>>> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
>>>> +					&mtk_wdt->wdt_dev);
>>>> +		if (err)
>>>> +			return err;
>>>> +
>>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
>>>> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
>>>> +	} else {
>>>> +		if (irq == -EPROBE_DEFER)
>>>> +			return -EPROBE_DEFER;
>>>> +
>>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
>>>> +	}
>>>> +
>>>>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>>>>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>>>>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
>>>>
>>>
>> 
>> 
>



From enric.balletbo at collabora.com  Fri Apr 23 08:52:01 2021
From: enric.balletbo at collabora.com (Enric Balletbo i Serra)
Date: Fri, 23 Apr 2021 09:52:01 +0200
Subject: [PATCH] arm64: defconfig: Do not override the MTK_PMIC_WRAP symbol
Message-ID: <20210423075201.2616023-1-enric.balletbo@collabora.com>

Commit 'fbbe38309d56 ("arm64: defconfig: Allow mt8173-based boards to boot
from usb")' added the MTK_PMIC_WRAP config built-in. It needs to be
built-in in order to be able to boot from USB or the MMC without needing
a ramdisk, but that symbol was already defined as a module so now we are
getting the following warning:

  arch/arm64/configs/defconfig:996:warning: override: reassigning to symbol MTK_PMIC_WRAP

Remove the MTK_PMIC_WRAP=m from the defconfig to remove the error.

Fixes: fbbe38309d56 ("arm64: defconfig: Allow mt8173-based boards to boot from usb")
Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---

 arch/arm64/configs/defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 08c6f769df9a..9907a431db0d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -491,7 +491,6 @@ CONFIG_SPI_S3C64XX=y
 CONFIG_SPI_SH_MSIOF=m
 CONFIG_SPI_SUN6I=y
 CONFIG_SPI_SPIDEV=m
-CONFIG_MTK_PMIC_WRAP=m
 CONFIG_SPMI=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_PINCTRL_MAX77620=y
-- 
2.30.2



From enric.balletbo at collabora.com  Fri Apr 23 08:52:50 2021
From: enric.balletbo at collabora.com (Enric Balletbo i Serra)
Date: Fri, 23 Apr 2021 09:52:50 +0200
Subject: [PATCH] arm64: defconfig: Allow Mediatek boards to boot from the mmc
Message-ID: <20210423075250.2616275-1-enric.balletbo@collabora.com>

Enable the MMC_MTK option necessary to boot Mediatek boards from the
mmc. Booting from the mmc is the common method used for a bunch of
boards, specially Chromebooks, to boot from. Hence this driver is
built-in.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>
---

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7b4be3807b6d..acb718160345 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -851,6 +851,7 @@ CONFIG_MMC_DW_K3=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SUNXI=y
 CONFIG_MMC_BCM2835=y
+CONFIG_MMC_MTK=y
 CONFIG_MMC_SDHCI_XENON=y
 CONFIG_MMC_SDHCI_AM654=y
 CONFIG_MMC_OWL=y
-- 
2.30.2



From adrian.hunter at intel.com  Fri Apr 23 09:01:40 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 23 Apr 2021 11:01:40 +0300
Subject: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <e6f3946a-dbe7-6b42-e43c-d3f8d705c732@intel.com>
References: <cover.1618600985.git.asutoshd@codeaurora.org>
 <d660b8d4e1fb192810abd09a8ff0ef4d9f6b96cd.1618600985.git.asutoshd@codeaurora.org>
 <fdadd467-b613-d800-18c5-be064396fd10@intel.com>
 <07e3ea07-e1c3-7b8c-e398-8b008f873e6d@codeaurora.org>
 <90809796-1c32-3709-13d3-65e4d5c387cc@intel.com>
 <1bc4a73e-b22a-6bad-2583-3a0ffa979414@intel.com>
 <651f5d8a-5ab7-77dd-3fed-05feb3fd3e1a@codeaurora.org>
 <efe71230-5b6a-22a8-1aef-f1cae046df22@intel.com>
 <e6f3946a-dbe7-6b42-e43c-d3f8d705c732@intel.com>
Message-ID: <973e0bbb-ac2d-7196-2e25-37aee2b77b46@intel.com>

On 23/04/21 9:18 am, Adrian Hunter wrote:
> On 23/04/21 7:23 am, Adrian Hunter wrote:
>> On 22/04/21 7:38 pm, Asutosh Das (asd) wrote:
>>> On 4/20/2021 12:42 AM, Adrian Hunter wrote:
>>>> On 20/04/21 7:15 am, Adrian Hunter wrote:
>>>>> On 20/04/21 12:53 am, Asutosh Das (asd) wrote:
>>>>>> On 4/19/2021 11:37 AM, Adrian Hunter wrote:
>>>>>>> On 16/04/21 10:49 pm, Asutosh Das wrote:
>>>>>>>>
>>>>>>>> Co-developed-by: Can Guo <cang at codeaurora.org>
>>>>>>>> Signed-off-by: Can Guo <cang at codeaurora.org>
>>>>>>>> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
>>>>>>>> ---
>>>>>>>
>>>>>>> I came across 3 issues while testing.? See comments below.
>>>>>>>
>>>>>> Hi Adrian
>>>>>> Thanks for the comments.
>>>>>>> <SNIP>
>>>>>>>
>>>>>>>> @@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>>>>>>>> ?????? if (ufshcd_is_clkscaling_supported(hba))
>>>>>>>> ?????????? ufshcd_clk_scaling_suspend(hba, false);
>>>>>>>> ?????? ufshcd_clear_ua_wluns(hba);
>>>>>>>
>>>>>>> ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
>>>>>>> if sdev_rpmb is suspended and sdev_ufs_device is suspending.
>>>>>>> e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
>>>>>>> is running, at which point sdev_rpmb has already suspended.
>>>>>>>
>>>>>> Umm, I didn't understand this deadlock.
>>>>>> When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
>>>>>> sdev_ufs_device is suspending - this can't be runtime_suspending, while ufshcd_err_handling_unprepare is running.
>>>>>>
>>>>>> If you've a call-stack of this deadlock, please can you share it with me. I'll also try to reproduce this.
>>>>>
>>>>> Yes it is system suspend. sdev_rpmb has suspended, sdev_ufs_device is waiting on host_sem.
>>>>> ufshcd_err_handler() holds host_sem. ufshcd_clear_ua_wlun(UFS_UPIU_RPMB_WLUN) gets stuck.
>>>>> I will get some call-stacks.
>>>>
>>> Hi Adrian,
>>>
>>> Thanks for the call stacks.
>>> From the current information, I can't say for sure why it'd get stuck in blk_queue_enter().
>>
>> I presume SCSI is leaving the RPMB WLUN device runtime suspended and consequently the queue status is RPM_SUSPENDED
>>
>>>
>>> I tried reproducing this issue on my setup yesterday but couldn't.
>>> Here's what I did:
>>> 1. sdev_rpmb is RPM_SUSPENDED, checked before initiating system suspend
>>> 2. sdev_ufs_device is RPM_RESUMED
>>> 3. I triggered system suspend (echo mem > /sys/power/state) and scheduled the error handler from ufshcd_wl_suspend().
>>> 4. Waited until error handler ran and then ufshcd_wl_suspend() blocks on host_sem.
>>> 5. The ufshcd_clear_wa_wlun(UFS_UPIU_RPMB_WLUN) went through fine.
>>>
>>> Do you've some specific steps to reproduce this or a script, perhaps? If so, please can you share it with me. I will try again.
>>
>> I was using a device that gives occasional errors, but I will what see I can do.
> 
> I have attached 2 patches to reproduce the issue, and the test script I used.
> Note it is using down_timeout() so it doesn't lock up completely.
> The kernel messages are:
> 
> [   79.385456] ufshcd_wl_suspend: doing ufshcd_schedule_eh_work
> [   79.385511] ufshcd_wl_suspend: sleeping 1000 ms
> [   79.386916] ufshcd_err_handler: start
> [   79.386979] ufshcd_err_handler: got sem
> [   79.387053] ufshcd_err_handling_unprepare: start
> [   79.387302] ufshcd_clear_ua_wluns: before ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN)
> [   80.435878] ufshcd_wl_suspend: trying to get sem
> [   85.683876] ufshcd_wl_suspend: failed to get sem
> [   85.683993] ufs_device_wlun 0:0:0:49488: PM: failed to suspend async: error -22
> [   85.686901] ufshcd_clear_ua_wluns: after ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN), ret 0
> [   85.687025] ufshcd_err_handling_unprepare: finish
> [   85.687090] ufshcd_err_handler: finish 
> 
> 

I think we also need to runtime resume RPMB WLUN before system suspend.
e.g.

+static int ufshcd_rpmb_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_rpmb->sdev_gendev);
+}
+
+static int ufshcd_rpmb_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_rpmb->sdev_gendev);
+}
+
 void ufshcd_resume_complete(struct device *dev)
 {
 	struct ufs_hba *hba = dev_get_drvdata(dev);
 
+	if (hba->rpmb_complete_put) {
+		hba->rpmb_complete_put = false;
+		ufshcd_rpmb_rpm_put(hba);
+	}
 	if (hba->complete_put) {
 		hba->complete_put = false;
 		ufshcd_rpm_put(hba);
@@ -9611,6 +9625,11 @@ int ufshcd_suspend_prepare(struct device *dev)
 		return ret;
 	}
 	hba->complete_put = true;
+
+	if (hba->sdev_rpmb) {
+		ufshcd_rpmb_rpm_get_sync(hba);
+		hba->rpmb_complete_put = true;
+	}
 	return 0;
 }

That also avoids another issue: if RPMB WLUN is runtime suspended at system resume, we have to skip clearing UAC, but SCSI PM will force the runtime status to RPM_ACTIVE after system resume, so the UAC never gets cleared in that case.

Furthermore, it seems better not to report errors from RPMB resume and instead let the error handler sort it out.
So, with the above change, we can simplify a bit:

-static int ufshcd_rpmb_runtime_resume(struct device *dev)
-{
-	struct ufs_hba *hba = wlun_dev_to_hba(dev);
-
-	if (hba->sdev_rpmb)
-		return ufshcd_clear_rpmb_uac(hba);
-	return 0;
-}
-
 static int ufshcd_rpmb_resume(struct device *dev)
 {
 	struct ufs_hba *hba = wlun_dev_to_hba(dev);
 
-	if (hba->sdev_rpmb && !pm_runtime_suspended(dev))
-		return ufshcd_clear_rpmb_uac(hba);
+	if (hba->sdev_rpmb)
+		ufshcd_clear_rpmb_uac(hba);
 	return 0;
 }
 
 static const struct dev_pm_ops ufs_rpmb_pm_ops = {
-	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_runtime_resume, NULL)
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_resume, NULL)
 	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
 };




From maz at kernel.org  Fri Apr 23 09:08:13 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 23 Apr 2021 09:08:13 +0100
Subject: [RFC PATCH] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <47abc8a6-0f73-d1c0-789f-e979d4191ab2@huawei.com>
References: <20210416062217.25157-1-heying24@huawei.com>
 <87y2dis4d7.wl-maz@kernel.org>
 <cc4a6eee-8bdc-0fd1-66cb-365340f7405e@huawei.com>
 <875z0eijxh.wl-maz@kernel.org>
 <47abc8a6-0f73-d1c0-789f-e979d4191ab2@huawei.com>
Message-ID: <87tunxo236.wl-maz@kernel.org>

On Fri, 23 Apr 2021 04:29:44 +0100,
He Ying <heying24 at huawei.com> wrote:

[...]

> >>>> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
> >>>> in nmi_enter(). From the call trace, we find two 'el1_irqs' which
> >>>> means an interrupt preempts the other one and the new one is an NMI.
> >>>> Furthermore, by adding some prints, we find the first irq also calls
> >>>> nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq number
> >>>> is 1023. It enables irq by calling gic_arch_enable_irqs() in
> >>>> gic_handle_irq(). At this moment, the second irq preempts the first irq
> >>>> and it's an NMI but current context is already in nmi. So that may be
> >>>> the problem.
> >>> I'm not sure I get it. From the stack trace, I see this:
> >>> 
> >>> [   14.816251]  asm_nmi_enter+0x94/0x98
> >>> [   14.816251]  el1_irq+0x8c/0x180			(C)
> >>> [   14.816252]  gic_handle_irq+0xbc/0x2e4
> >>> [   14.816252]  el1_irq+0xcc/0x180			(B)
> >>> [   14.816253]  arch_timer_handler_virt+0x38/0x58
> >>> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> >>> [   14.816253]  generic_handle_irq+0x34/0x50
> >>> [   14.816254]  __handle_domain_irq+0x68/0xc0
> >>> [   14.816254]  gic_handle_irq+0xf8/0x2e4
> >>> [   14.816255]  el1_irq+0xcc/0x180			(A)
> >>> 
> >>> which indicates that we preempted a timer interrupt (A) with another
> >>> IRQ (B), itself immediately preempted by another IRQ (C)? That's
> >>> indeed at least one too many.
> >>> 
> >>> Can you please describe for each of (A), (B) and (C) whether they are
> >>> spurious or not, what their priorities are if they aren't spurious?
> >> Yes. I ignored interrupt (A). (B) is spurious and its priority is
> >> 0xa0 and PMR is 0x70. (C) is an NMI and its priority is 0x20. Note
> >> that GIC_PRIO_IRQON is 0xe0, GIC_PRIO_IRQOFF is 0x60,
> >> GICD_INT_DEF_PRI is 0xa0 and GICD_INT_NMI_PRI is 0x20 in our kernel.
> > If (B) is spurious (aka ICC_IAR1R_EL1 return 1023), then its
> > "priority" doesn't really exist, and I don't really get what you mean
> > by "its priority is 0xa0".  ICC_RPR_EL1 shouldn't change when Ack-ing
> > a spurious interrupt, because there is no change in GIC state at all.
> OK. By saying "its priority is 0xa0", I just mean ICC_RPR_EL1 is read
> as 0xa0.

Right. That's very different from saying that an interrupt has
priority 0xA0.

> > 
> > And if PMR is 0x70 at the point where you get (B), then I really can't
> > see how you can get an interrupt of priority 0xa0 anyway.
> 
> Yes, it also confuses me. Perhaps ICC_RPR_EL1 changes when read, I
> think.

No, it just means that we were already in an interrupt context when we
handled the spurious interrupt: I think interrupt (A) above was being
handled with priority 0xa0, preempted by a spurious interrupt (B) which
did the wrong thing by messing with the NMI state.

Probably (B) was an NMI that got retired early and presented again to
the cpuif as (C). If that's the case, the GIC implementation may be a
bit flaky. But the driver definitely has a bug.

[...]

> > I believe the above patch would fix the spurious interrupt issue you
> > have experienced. Please let me know, and post a v2 if this works for
> > you.
> 
> Fortunately, it works. I'll post a v2. Should I cc stable mail list?

Yes please.

Thanks,

	M.

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


From tan.shaopeng at fujitsu.com  Fri Apr 23 09:10:10 2021
From: tan.shaopeng at fujitsu.com (tan.shaopeng at fujitsu.com)
Date: Fri, 23 Apr 2021 08:10:10 +0000
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
Message-ID: <OSAPR01MB21467099EAA9B25F0A992BD88B459@OSAPR01MB2146.jpnprd01.prod.outlook.com>

Hi Reinette,

> On 4/21/2021 1:37 AM, tan.shaopeng at fujitsu.com wrote:
> > Hi,
> >
> > Ping... any comments&advice about add an A64FX cache control function
> into resctrl?
> 
> My apologies for the delay.
> 
> >
> > Best regards
> > Tan Shaopeng
> >
> >> Hello
> >>
> >>
> >> I'm Tan Shaopeng from Fujitsu Limited.
> >>
> >> I?m trying to implement Fujitsu A64FX?s cache related features.
> >> It is a cache partitioning function we called sector cache function
> >> that using the value of the tag that is upper 8 bits of the 64bit
> >> address and the value of the sector cache register to control virtual cache
> capacity of the L1D&L2 cache.
> >>
> >> A few days ago, when I sent a driver that realizes this function to
> >> ARM64 kernel community, Will Deacon and Arnd Bergmann suggested an
> >> idea to add the sector cache function of A64FX into resctrl.
> >>
> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5Oc
> >> Z=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/
> >>
> >> Based on my study, I think the sector cache function of A64FX can be
> >> added into the allocation features of resctrl after James' resctrl rework has
> finished.
> >> But, in order to implement this function, more interfaces for resctrl are
> need.
> >> The details are as follow, and could you give me some advice?
> >>
> >> [Sector cache function]
> >> The sector cache function split cache into multiple sectors and
> >> control them separately. It is implemented on the L1D cache and
> >> L2 cache in the A64FX processor and can be controlled individually
> >> for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache and
> >> L2 cache has 4 sectors. Which L1D sector is used is specified by the
> >> value of [57:56] bits of address, how many ways of sector are
> >> specified by the value of register (IMP_SCCR_L1_EL0).
> >> Which L2 sector is used is specified by the value of [56] bits of
> >> address, and how many ways of sector are specified by value of
> >> register (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
> >> IMP_SCCR_SET1_L2_EL1).
> >>
> >> For more details of sector cache function, see A64FX HPC extension
> >> specification (1.2. Sector cache) in https://github.com/fujitsu/A64FX
> 
> The overview in section 12 was informative but very high level.
> I was not able to find any instance of "IMP_SCCR" in this document to explore
> how this cache allocation works.
> 
> Are these cache sectors exposed to the OS in any way? For example, when the
> OS discovers the cache, does it learn about these sectors and expose the
> details to user space (/sys/devices/system/cpuX/cache)?
> 
> The overview of Sector Cache in that document provides details of how the size
> of the sector itself is dynamically adjusted to usage. That description is quite
> cryptic but it seems like a sector, since the number of ways associated with it
> can dynamically change, is more equivalent to a class of service or resource
> group in the resctrl environment.
> 
> I really may be interpreting things wrong here, could you perhaps point me to
> where I can obtain more details?
> 
> 
> >> [Difference between resctrl(CAT) and this sector cache function]
> >> L2/L3 CAT (Cache Allocation Technology) enables the user to specify
> >> some physical partition of cache space that an application can fill.
> >> A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function
> >> enables a user to specify number of ways each sector uses.
> >> Therefore, for CAT it is enough to specify a cache portion for each
> >> cache_id (socket). On the other hand, sector cache needs to specify
> >> cache portion of each sector for each cache_id, and following
> >> extension to resctrl interface is needed to support sector cache.
> >>
> >> [Idear for A64FX sector cache function control interface (schemata
> >> file details)]
> >>
> L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cw
> >> bm>,<cwbm>,<cwbm>,<cwbm>;?
> >>
> L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=
> >> <cwbm>,<cwbm>,<cwbm>,<cwbm>;?
> >>
> >> ?L1: Add a new interface to control the L1D cache.
> >> ?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for
> each
> >> sector.
> >> ?cwbm?Specify the number of ways in each sector as a bitmap
> (percentage),
> >>    but the bitmap does not indicate the location of the cache.
> >> * In the sector cache function, L2 sector cache way setting register is
> >>    shared among PEs (Processor Element) in shared domain. If two PEs
> >>    which share L2 cache belongs to different resource groups, one
> resource
> >>    group's L2 setting will affect to other resource group's L2 setting.
> 
> In resctrl a "resource group" can be viewed as a class of service.
> 
> >> * Since A64FX does not support MPAM, it is not necessary to consider
> >>    how to switch between MPAM and sector cache function now.
> >>
> >> Some questions:
> >> 1.I'm still studying about RDT, could you tell me whether RDT has
> >>    the similar mechanism with sector cache function?
> 
> This is not clear to me yet. One thing to keep in mind is that a bit in the capacity
> bitmask could correspond to some number of ways in a cache, but it does not
> have to. It is essentially a hint to hardware on how much cache space needs to
> be allocated while also indicating overlap and isolation from other allocations.
> 
> resctrl already supports the bitmask being interpreted differently between
> architectures and with the MPAM support there will be even more support for
> different interpretations.
> 
> >> 2.In RDT, L3 cache is shared among cores in socket. If two cores which
> >>    share L3 cache belongs to different resource groups, one resource
> >>    group's L3 setting will affect to other resource group's L3 setting?
> 
> This question is not entirely clear to me. Are you referring to the hardware layout
> or configuration changes via the resctrl "cpus" file?
> 
> Each resource group is a class of service (CLOS) that is supported by all cache
> instances. By default each resource group would thus contain all cache
> instances on the system (even if some cache instances do not support the
> same number of CLOS resctrl would only support the CLOS supported by all
> resources).

Thanks for your comment. 

I am sorry that the description about the sector cache function was
difficult to understand. Since all public specifications were shown
in the URL, please give me some time, I will organize the contents of
64FX cache control function. 

Best regards, 
Tan Shaopeng


From wangkefeng.wang at huawei.com  Fri Apr 23 09:11:16 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Fri, 23 Apr 2021 16:11:16 +0800
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
Message-ID: <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>


On 2021/4/22 23:28, Kefeng Wang wrote:
>
> On 2021/4/22 15:29, Mike Rapoport wrote:
>> On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
>>> On 2021/4/21 14:51, Mike Rapoport wrote:
>>>> From: Mike Rapoport <rppt at linux.ibm.com>
>>>>
>>>> Hi,
>>>>
>>>> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially 
>>>> hardwire
>>>> pfn_valid_within() to 1.
>>>>
>>>> The idea is to mark NOMAP pages as reserved in the memory map and 
>>>> restore
>>>> the intended semantics of pfn_valid() to designate availability of 
>>>> struct
>>>> page for a pfn.
>>>>
>>>> With this the core mm will be able to cope with the fact that it 
>>>> cannot use
>>>> NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER 
>>>> blocks
>>>> will be treated correctly even without the need for pfn_valid_within.
>>>>
>>>> The patches are only boot tested on qemu-system-aarch64 so I'd really
>>>> appreciate memory stress tests on real hardware.
>>>>
>>>> If this actually works we'll be one step closer to drop custom 
>>>> pfn_valid()
>>>> on arm64 altogether.
...
>
> Ok, thanks, we met a same panic like the link on arm32(without 
> HOLES_IN_ZONE),
>
> the scheme for arm64 could be suit for arm32, right?? I will try the 
> patchset with
>
> some changes on arm32 and give some feedback.

I tested this patchset(plus arm32 change, like arm64 does) based on lts 
5.10?add

some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, 
no panic,

any idea, thanks.

Zone ranges:
 ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
 ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
Movable zone start for each node
Early memory node ranges
 ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
 ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
 ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
 ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
 ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
 ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
 ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
 ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
 ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
 ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]

----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
=== >move_freepages: start_pfn/end_pfn [de600, de7ff], [de600000, 
de7ff000] :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags 
= ffffffff
8<--- cut here ---
Unable to handle kernel paging request at virtual address fffffffe
pgd = 5dd50df5
[fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
Internal error: Oops: 37 [#1] SMP ARM
Modules linked in: gmac(O)
CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
Hardware name: Hisilicon A9
PC is at move_freepages_block+0x150/0x278
LR is at move_freepages_block+0x150/0x278
pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
sp : c4179cf8? ip : 00000000? fp : 00000001
r10: c4179d58? r9 : 000de7ff? r8 : 00000000
r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
Process test-oom (pid: 635, stack limit = 0x25d667df)



From zhouchuangao at vivo.com  Fri Apr 23 09:14:45 2021
From: zhouchuangao at vivo.com (zhouchuangao)
Date: Fri, 23 Apr 2021 01:14:45 -0700
Subject: [PATCH] arm/mach-hisi: Use BUG_ON instead of if condition followed by
 BUG
Message-ID: <1619165686-69955-1-git-send-email-zhouchuangao@vivo.com>

BUG_ON uses unlikely in if(). Through disassembly, we can see that
brk #0x800 is compiled to the end of the function.
As you can see below:
    ......
    ffffff8008660bec:   d65f03c0    ret
    ffffff8008660bf0:   d4210000    brk #0x800

Usually, the condition in if () is not satisfied. For the
multi-stage pipeline, we do not need to perform fetch decode
and excute operation on brk instruction.

In my opinion, this can improve the efficiency of the
multi-stage pipeline.

Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
---
 arch/arm/mach-hisi/hotplug.c  | 3 +--
 arch/arm/mach-hisi/platmcpm.c | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
index c517941..b9ced60 100644
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -193,8 +193,7 @@ void hix5hd2_set_cpu(int cpu, bool enable)
 	u32 val = 0;
 
 	if (!ctrl_base)
-		if (!hix5hd2_hotplug_init())
-			BUG();
+		BUG_ON(!hix5hd2_hotplug_init());
 
 	if (enable) {
 		/* power on cpu1 */
diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c
index 96a4840..6c90039 100644
--- a/arch/arm/mach-hisi/platmcpm.c
+++ b/arch/arm/mach-hisi/platmcpm.c
@@ -82,8 +82,8 @@ static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
 {
 	unsigned long data;
 
-	if (!fabric)
-		BUG();
+	BUG_ON(!fabric);
+
 	data = readl_relaxed(fabric + FAB_SF_MODE);
 	if (on)
 		data |= 1 << cluster;
-- 
2.7.4



From leo.yan at linaro.org  Fri Apr 23 09:23:04 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 23 Apr 2021 16:23:04 +0800
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync
 buffer.
In-Reply-To: <20210421120413.3110775-2-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-2-daniel.kiss@arm.com>
Message-ID: <20210423082304.GA377091@leoy-ThinkPad-X240s>

On Wed, Apr 21, 2021 at 02:04:10PM +0200, Daniel Kiss wrote:
> With polling the sync could called multiple times in a row. Without this
> change the data will be overwritten at the beginning of the buffer.
> 
> Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
> Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>

>From the last week, I spent time to dig into AUX trace buffer, thus
this patch set gives me a good chance to apply my learning for perf
ring buffer.

For this patch:

Reviewed-by: Leo Yan <leo.yan at linaro.org>


> ---
>  drivers/hwtracing/coresight/coresight-tmc-etr.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index ea5027e397d02..dd19d1d1c3b38 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1442,7 +1442,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>  {
>  	long bytes;
>  	long pg_idx, pg_offset;
> -	unsigned long head = etr_perf->head;
> +	unsigned long head;
>  	char **dst_pages, *src_buf;
>  	struct etr_buf *etr_buf = etr_perf->etr_buf;
>  
> @@ -1465,7 +1465,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>  		bytes = tmc_etr_buf_get_data(etr_buf, src_offset, to_copy,
>  					     &src_buf);
>  		if (WARN_ON_ONCE(bytes <= 0))
> -			break;
> +			return;
>  		bytes = min(bytes, (long)(PAGE_SIZE - pg_offset));
>  
>  		memcpy(dst_pages[pg_idx] + pg_offset, src_buf, bytes);
> @@ -1483,6 +1483,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>  		/* Move source pointers */
>  		src_offset += bytes;
>  	}
> +	etr_perf->head = (pg_idx << PAGE_SHIFT) + pg_offset;
>  }
>  
>  /*
> -- 
> 2.25.1
> 


From zhouchuangao at vivo.com  Fri Apr 23 09:30:21 2021
From: zhouchuangao at vivo.com (zhouchuangao)
Date: Fri, 23 Apr 2021 01:30:21 -0700
Subject: [PATCH] mips/bcm63xx: Use BUG_ON instead of if condition followed by
 BUG
Message-ID: <1619166623-70445-1-git-send-email-zhouchuangao@vivo.com>

BUG_ON uses unlikely in if(), it can be optimized at compile time.

Usually, the condition in if() is not satisfied. In my opinion,
this can improve the efficiency of the multi-stage pipeline.

Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
---
 arch/mips/bcm63xx/gpio.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/mips/bcm63xx/gpio.c b/arch/mips/bcm63xx/gpio.c
index 16f353a..5c4a233 100644
--- a/arch/mips/bcm63xx/gpio.c
+++ b/arch/mips/bcm63xx/gpio.c
@@ -43,8 +43,7 @@ static void bcm63xx_gpio_set(struct gpio_chip *chip,
 	u32 *v;
 	unsigned long flags;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = gpio_out_low_reg;
@@ -70,8 +69,7 @@ static int bcm63xx_gpio_get(struct gpio_chip *chip, unsigned gpio)
 	u32 reg;
 	u32 mask;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = gpio_out_low_reg;
@@ -92,8 +90,7 @@ static int bcm63xx_gpio_set_direction(struct gpio_chip *chip,
 	u32 tmp;
 	unsigned long flags;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = GPIO_CTL_LO_REG;
-- 
2.7.4



From shameerali.kolothum.thodi at huawei.com  Fri Apr 23 09:31:06 2021
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Fri, 23 Apr 2021 08:31:06 +0000
Subject: [PATCH v4 00/16] kvm/arm: Align the VMID allocation with the
 arm64 ASID one
In-Reply-To: <20210422160846.GB2214@willie-the-truck>
References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com>
 <20210422160846.GB2214@willie-the-truck>
Message-ID: <acb761853cb1494a9eb2c345ddd9afd4@huawei.com>



> -----Original Message-----
> From: Will Deacon [mailto:will at kernel.org]
> Sent: 22 April 2021 18:09
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
> Cc: linux-arm-kernel at lists.infradead.org; kvmarm at lists.cs.columbia.edu;
> linux-kernel at vger.kernel.org; maz at kernel.org; catalin.marinas at arm.com;
> james.morse at arm.com; julien.thierry.kdev at gmail.com;
> suzuki.poulose at arm.com; jean-philippe at linaro.org; julien at xen.org; Linuxarm
> <linuxarm at huawei.com>
> Subject: Re: [PATCH v4 00/16] kvm/arm: Align the VMID allocation with the
> arm64 ASID one
> 
> On Wed, Apr 14, 2021 at 12:22:56PM +0100, Shameer Kolothum wrote:
> > Hi,
> >
> > This is an attempt to revive this series originally posted by
> > Julien Grall[1]. The main motive to work on this now is because
> > of the requirement to have Pinned KVM VMIDs and the RFC discussion
> > for the same basically suggested[2] to have a common/better vmid
> > allocator for KVM which this series provides.
> >
> > Major Changes from v3:
> >
> > -Changes related to Pinned ASID support.
> > -Changes to take care KPTI related bits reservation.
> > -Dropped support for 32 bit KVM.
> > -Rebase to 5.12-rc7
> >
> > Individual patches have change history for any major changes
> > from v3.
> >
> > Tests were performed on a HiSilicon D06 platform and so far not observed
> > any regressions.
> >
> > For ASID allocation,
> >
> > Avg of 10 runs(hackbench -s 512 -l 200 -g 300 -f 25 -P),
> > 5.12-rc7: Time:18.8119
> > 5.12-rc7+v4: Time: 18.459
> >
> > ~1.8% improvement.
> >
> > For KVM VMID,
> >
> > The measurement was made with maxcpus set to 8 and with the
> > number of VMID limited to 4-bit. The test involves running
> > concurrently 40 guests with 2 vCPUs. Each guest will then
> > execute hackbench 5 times before exiting.
> >
> > The performance difference between the current algo and the
> > new one are(ag. of 10 runs):
> >     - 1.9% less exit from the guest
> >     - 0.7% faster
> >
> > For complete series, please see,
> >  https://github.com/hisilicon/kernel-dev/tree/private-v5.12-rc7-asid-v4
> >
> > Please take a look and let me know your feedback.
> 
> Although I think aligning the two algorithms makes sense, I'm not completely
> sold on the need to abstract all this into a library and whether the
> additional indirection is justified.
> 
> It would be great to compare this approach with one where portions of the
> code are duplicated into a separate VMID allocator. Have you tried that to
> see what it looks like? Doesn't need to be a proper patch set, but comparing
> the end result might help to evaluate the proposal here.

Ok. I will give it a go and get back.

Thanks,
Shameer
	


From tomi.valkeinen at ideasonboard.com  Fri Apr 23 09:31:20 2021
From: tomi.valkeinen at ideasonboard.com (Tomi Valkeinen)
Date: Fri, 23 Apr 2021 11:31:20 +0300
Subject: [PATCH v2] arm64: dts: ti: k3-am654-base-board: remove ov5640
Message-ID: <20210423083120.73476-1-tomi.valkeinen@ideasonboard.com>

AM654 EVM boards are not shipped with OV5640 sensor module, it is a
separate purchase. OV5640 module is also just one of the possible
sensors or capture boards you can connect.

However, for some reason, OV5640 has been added to the board dts file,
making it cumbersome to use other sensors.

Remove the OV5640 from the dts file so that it is easy to use other
sensors via DT overlays.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
---

Changes in v2:
- drop empty csi2_0 node

A DT overlay with OV5640 can be found from:

https://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux-dt.git/commit/?h=multistream/work&id=ff7a6469a8c40e1fec14f0a186322ee114892117

 .../arm64/boot/dts/ti/k3-am654-base-board.dts | 31 -------------------
 1 file changed, 31 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index fe3043943906..7f27ba7e7256 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -85,12 +85,6 @@ sw6 {
 			gpios = <&wkup_gpio0 27 GPIO_ACTIVE_LOW>;
 		};
 	};
-
-	clk_ov5640_fixed: clock {
-		compatible = "fixed-clock";
-		#clock-cells = <0>;
-		clock-frequency = <24000000>;
-	};
 };
 
 &wkup_pmx0 {
@@ -287,23 +281,6 @@ &main_i2c1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&main_i2c1_pins_default>;
 	clock-frequency = <400000>;
-
-	ov5640: camera at 3c {
-		compatible = "ovti,ov5640";
-		reg = <0x3c>;
-
-		clocks = <&clk_ov5640_fixed>;
-		clock-names = "xclk";
-
-		port {
-			csi2_cam0: endpoint {
-				remote-endpoint = <&csi2_phy0>;
-				clock-lanes = <0>;
-				data-lanes = <1 2>;
-			};
-		};
-	};
-
 };
 
 &main_i2c2 {
@@ -496,14 +473,6 @@ flash at 0{
 	};
 };
 
-&csi2_0 {
-	csi2_phy0: endpoint {
-		remote-endpoint = <&csi2_cam0>;
-		clock-lanes = <0>;
-		data-lanes = <1 2>;
-	};
-};
-
 &mcu_cpsw {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>;
-- 
2.25.1



From heying24 at huawei.com  Fri Apr 23 09:35:16 2021
From: heying24 at huawei.com (He Ying)
Date: Fri, 23 Apr 2021 04:35:16 -0400
Subject: [PATCH v2] irqchip/gic-v3: Do not enable irqs when handling spurious
 interrups
Message-ID: <20210423083516.170111-1-heying24@huawei.com>

We found this problem in our kernel src tree:

[   14.816231] ------------[ cut here ]------------
[   14.816231] kernel BUG at irq.c:99!
[   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
[   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
[   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95.aarch64 #14
[   14.816233] Hardware name: evb (DT)
[   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[   14.816234] pc : asm_nmi_enter+0x94/0x98
[   14.816235] lr : asm_nmi_enter+0x18/0x98
[   14.816235] sp : ffff000008003c50
[   14.816235] pmr_save: 00000070
[   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
[   14.816238] x27: 0000000000000000 x26: ffff000008004000
[   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
[   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
[   14.816241] x21: ffff000008003da0 x20: 0000000000000060
[   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
[   14.816243] x17: 0000000000000008 x16: 003d090000000000
[   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
[   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
[   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
[   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
[   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
[   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
[   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
[   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
[   14.816251] Call trace:
[   14.816251]  asm_nmi_enter+0x94/0x98
[   14.816251]  el1_irq+0x8c/0x180                    (IRQ C)
[   14.816252]  gic_handle_irq+0xbc/0x2e4
[   14.816252]  el1_irq+0xcc/0x180                    (IRQ B)
[   14.816253]  arch_timer_handler_virt+0x38/0x58
[   14.816253]  handle_percpu_devid_irq+0x90/0x240
[   14.816253]  generic_handle_irq+0x34/0x50
[   14.816254]  __handle_domain_irq+0x68/0xc0
[   14.816254]  gic_handle_irq+0xf8/0x2e4
[   14.816255]  el1_irq+0xcc/0x180                    (IRQ A)
[   14.816255]  arch_cpu_idle+0x34/0x1c8
[   14.816255]  default_idle_call+0x24/0x44
[   14.816256]  do_idle+0x1d0/0x2c8
[   14.816256]  cpu_startup_entry+0x28/0x30
[   14.816256]  rest_init+0xb8/0xc8
[   14.816257]  start_kernel+0x4c8/0x4f4
[   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
[   14.816258] Modules linked in: start_dp(O) smeth(O)
[   15.103092] ---[ end trace 701753956cb14aa8 ]---
[   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
[   15.103099] SMP: stopping secondary CPUs
[   15.103100] Kernel Offset: disabled
[   15.103100] CPU features: 0x36,a2400218
[   15.103100] Memory Limit: none

I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
in nmi_enter(). From the call trace, we can find three interrupts which
I mark as IRQ A, B and C. By adding some prints, I find the IRQ B also
calls nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq
number is 1023. It enables irq by calling gic_arch_enable_irqs() in
gic_handle_irq(). At this moment, IRQ C preempts the IRQ B and it's
an NMI but current context is already in nmi. So that may be the problem.

When handling spurious interrupts, we shouldn't enable irqs. That's
because for spurious interrupts we may enter nmi context in el1_irq()
because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs at this
time, another NMI may happen and preempt this spurious interrupt
but the context is already in nmi. That causes a bug on if nested NMI
is not supported. Even for nested nmi, it's not a normal scenario.

Though the issue is reported on our private tree, I think it also
exists on the latest tree for the reasons above. To fix this issue,
check spurious interrupts right after the read of ICC_IAR1_EL1 and
return directly for spurious interrupts.

Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
Signed-off-by: He Ying <heying24 at huawei.com>
---

v2:
- Move the check right after the read of ICC_IAR1_EL1 suggested by Marc.

 drivers/irqchip/irq-gic-v3.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 94b89258d045..37a23aa6de37 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -648,6 +648,10 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 
 	irqnr = gic_read_iar();
 
+	/* Check for special IDs first */
+	if ((irqnr >= 1020 && irqnr <= 1023))
+		return;
+
 	if (gic_supports_nmi() &&
 	    unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
 		gic_handle_nmi(irqnr, regs);
@@ -659,10 +663,6 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
 		gic_arch_enable_irqs();
 	}
 
-	/* Check for special IDs first */
-	if ((irqnr >= 1020 && irqnr <= 1023))
-		return;
-
 	if (static_branch_likely(&supports_deactivate_key))
 		gic_write_eoir(irqnr);
 	else
-- 
2.17.1



From jon.lin at rock-chips.com  Fri Apr 23 09:41:48 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:41:48 +0800
Subject: [PATCH v1 1/8] dt-bindings: spi: spi-rockchip: add description for
 rv1126
Message-ID: <20210423084155.17439-1-jon.lin@rock-chips.com>

The description below will be used for rv1126.dtsi in the future

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 1e6cf29e6388..4ed5b72a8494 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -27,6 +27,7 @@ properties:
       - items:
           - enum:
               - rockchip,px30-spi
+              - rockchip,rv1126-spi
               - rockchip,rk3188-spi
               - rockchip,rk3288-spi
               - rockchip,rk3308-spi
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:41:49 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:41:49 +0800
Subject: [PATCH v1 2/8] spi: rockchip: add compatible string for rv1126
In-Reply-To: <20210423084155.17439-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
Message-ID: <20210423084155.17439-2-jon.lin@rock-chips.com>

Add compatible string for rv1126 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 52d6259d96ed..dae0281f6ba8 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -911,7 +911,9 @@ static const struct dev_pm_ops rockchip_spi_pm = {
 };
 
 static const struct of_device_id rockchip_spi_dt_match[] = {
-	{ .compatible = "rockchip,px30-spi", },
+	{ .compatible = "rockchip,px30-spi",   },
+	{ .compatible = "rockchip,rv1108-spi", },
+	{ .compatible = "rockchip,rv1126-spi", },
 	{ .compatible = "rockchip,rk3036-spi", },
 	{ .compatible = "rockchip,rk3066-spi", },
 	{ .compatible = "rockchip,rk3188-spi", },
@@ -921,7 +923,6 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3328-spi", },
 	{ .compatible = "rockchip,rk3368-spi", },
 	{ .compatible = "rockchip,rk3399-spi", },
-	{ .compatible = "rockchip,rv1108-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:41:50 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:41:50 +0800
Subject: [PATCH v1 3/8] spi: rockchip: Support cs-gpio
In-Reply-To: <20210423084155.17439-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
Message-ID: <20210423084155.17439-3-jon.lin@rock-chips.com>

1.Add standard cs-gpio support
2.Refer to spi-controller.yaml for details

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 61 ++++++++++++++++++++++++++++++++++----
 1 file changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index dae0281f6ba8..bb9d137b6f7f 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -6,6 +6,7 @@
 
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
+#include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -156,7 +157,8 @@
  */
 #define ROCKCHIP_SPI_MAX_TRANLEN		0xffff
 
-#define ROCKCHIP_SPI_MAX_CS_NUM			2
+/* 2 for native cs, 2 for cs-gpio */
+#define ROCKCHIP_SPI_MAX_CS_NUM			4
 #define ROCKCHIP_SPI_VER2_TYPE1			0x05EC0002
 #define ROCKCHIP_SPI_VER2_TYPE2			0x00110002
 
@@ -190,6 +192,7 @@ struct rockchip_spi {
 	bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
 
 	bool slave_abort;
+	bool gpio_requested;
 };
 
 static inline void spi_enable_chip(struct rockchip_spi *rs, bool enable)
@@ -238,11 +241,15 @@ static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 		/* Keep things powered as long as CS is asserted */
 		pm_runtime_get_sync(rs->dev);
 
-		ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
-				      BIT(spi->chip_select));
+		if (gpio_is_valid(spi->cs_gpio))
+			ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, 1);
+		else
+			ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, BIT(spi->chip_select));
 	} else {
-		ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
-				      BIT(spi->chip_select));
+		if (gpio_is_valid(spi->cs_gpio))
+			ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER, 1);
+		else
+			ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER, BIT(spi->chip_select));
 
 		/* Drop reference from when we first asserted CS */
 		pm_runtime_put(rs->dev);
@@ -625,6 +632,47 @@ static bool rockchip_spi_can_dma(struct spi_controller *ctlr,
 	return xfer->len / bytes_per_word >= rs->fifo_len;
 }
 
+static int rockchip_spi_setup(struct spi_device *spi)
+{
+
+	int ret = -EINVAL;
+	struct rockchip_spi *rs = spi_controller_get_devdata(spi->controller);
+
+	if (spi->cs_gpio == -ENOENT)
+		return 0;
+
+	if (!rs->gpio_requested && gpio_is_valid(spi->cs_gpio)) {
+		ret = gpio_request_one(spi->cs_gpio,
+				       (spi->mode & SPI_CS_HIGH) ?
+				       GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH,
+				       dev_name(&spi->dev));
+		if (ret)
+			dev_err(&spi->dev, "can't request chipselect gpio %d\n",
+				spi->cs_gpio);
+		else
+			rs->gpio_requested = true;
+	} else {
+		if (gpio_is_valid(spi->cs_gpio)) {
+			int mode = ((spi->mode & SPI_CS_HIGH) ? 0 : 1);
+
+			ret = gpio_direction_output(spi->cs_gpio, mode);
+			if (ret)
+				dev_err(&spi->dev, "chipselect gpio %d setup failed (%d)\n",
+					spi->cs_gpio, ret);
+		}
+	}
+
+	return ret;
+}
+
+static void rockchip_spi_cleanup(struct spi_device *spi)
+{
+	struct rockchip_spi *rs = spi_controller_get_devdata(spi->controller);
+
+	if (rs->gpio_requested)
+		gpio_free(spi->cs_gpio);
+}
+
 static int rockchip_spi_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -699,6 +747,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 
 	rs->dev = &pdev->dev;
 	rs->freq = clk_get_rate(rs->spiclk);
+	rs->gpio_requested = false;
 
 	if (!of_property_read_u32(pdev->dev.of_node, "rx-sample-delay-ns",
 				  &rsd_nsecs)) {
@@ -752,6 +801,8 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 	ctlr->max_speed_hz = min(rs->freq / BAUDR_SCKDV_MIN, MAX_SCLK_OUT);
 
 	ctlr->set_cs = rockchip_spi_set_cs;
+	ctlr->setup = rockchip_spi_setup;
+	ctlr->cleanup = rockchip_spi_cleanup;
 	ctlr->transfer_one = rockchip_spi_transfer_one;
 	ctlr->max_transfer_size = rockchip_spi_max_transfer_size;
 	ctlr->handle_err = rockchip_spi_handle_err;
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:41:51 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:41:51 +0800
Subject: [PATCH v1 4/8] dt-bindings: spi: spi-rockchip: add description for
 rk3568
In-Reply-To: <20210423084155.17439-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
Message-ID: <20210423084155.17439-4-jon.lin@rock-chips.com>

Add compatible string for rk3568 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 4ed5b72a8494..2d7957f9ae0a 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -34,6 +34,7 @@ properties:
               - rockchip,rk3328-spi
               - rockchip,rk3368-spi
               - rockchip,rk3399-spi
+              - rockchip,rk3568-spi
           - const: rockchip,rk3066-spi
 
   reg:
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:41:52 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:41:52 +0800
Subject: [PATCH v1 5/8] spi: rockchip: Add compatible string for rk3568
In-Reply-To: <20210423084155.17439-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
Message-ID: <20210423084155.17439-5-jon.lin@rock-chips.com>

Add compatible string for rv1126 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index bb9d137b6f7f..cfcbfd6c1be5 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -974,6 +974,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3328-spi", },
 	{ .compatible = "rockchip,rk3368-spi", },
 	{ .compatible = "rockchip,rk3399-spi", },
+	{ .compatible = "rockchip,rk3568-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:47:49 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:47:49 +0800
Subject: [PATCH v1 7/8] spi: rockchip: Wait for STB status in slave mode
 tx_xfer
In-Reply-To: <20210423084750.18533-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
 <20210423084750.18533-1-jon.lin@rock-chips.com>
Message-ID: <20210423084750.18533-2-jon.lin@rock-chips.com>

After ROCKCHIP_SPI_VER2_TYPE2, SR->STB is a more accurate judgment
bit for spi slave transmition.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index c245af1692c7..b17463e5fda6 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -117,13 +117,14 @@
 #define BAUDR_SCKDV_MIN				2
 #define BAUDR_SCKDV_MAX				65534
 
-/* Bit fields in SR, 5bit */
-#define SR_MASK						0x1f
+/* Bit fields in SR, 6bit */
+#define SR_MASK						0x3f
 #define SR_BUSY						(1 << 0)
 #define SR_TF_FULL					(1 << 1)
 #define SR_TF_EMPTY					(1 << 2)
 #define SR_RF_EMPTY					(1 << 3)
 #define SR_RF_FULL					(1 << 4)
+#define SR_SLAVE_TX_BUSY				(1 << 5)
 
 /* Bit fields in ISR, IMR, ISR, RISR, 5bit */
 #define INT_MASK					0x1f
@@ -200,13 +201,19 @@ static inline void spi_enable_chip(struct rockchip_spi *rs, bool enable)
 	writel_relaxed((enable ? 1U : 0U), rs->regs + ROCKCHIP_SPI_SSIENR);
 }
 
-static inline void wait_for_idle(struct rockchip_spi *rs)
+static inline void wait_for_tx_idle(struct rockchip_spi *rs, bool slave_mode)
 {
 	unsigned long timeout = jiffies + msecs_to_jiffies(5);
 
 	do {
-		if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
-			return;
+		if (slave_mode) {
+			if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_SLAVE_TX_BUSY) &&
+			    !((readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
+				return;
+		} else {
+			if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
+				return;
+		}
 	} while (!time_after(jiffies, timeout));
 
 	dev_warn(rs->dev, "spi controller is in busy state!\n");
@@ -390,7 +397,7 @@ static void rockchip_spi_dma_txcb(void *data)
 		return;
 
 	/* Wait until the FIFO data completely. */
-	wait_for_idle(rs);
+	wait_for_tx_idle(rs, ctlr->slave);
 
 	spi_enable_chip(rs, false);
 	spi_finalize_current_transfer(ctlr);
@@ -552,7 +559,7 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	else
 		writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 
-	writel_relaxed(rs->fifo_len / 2, rs->regs + ROCKCHIP_SPI_DMATDLR);
+	writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_DMATDLR);
 	writel_relaxed(rockchip_spi_calc_burst_size(xfer->len / rs->n_bytes) - 1,
 		       rs->regs + ROCKCHIP_SPI_DMARDLR);
 	writel_relaxed(dmacr, rs->regs + ROCKCHIP_SPI_DMACR);
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:47:50 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:47:50 +0800
Subject: [PATCH v1 8/8] spi: rockchip: Support SPI_CS_HIGH
In-Reply-To: <20210423084750.18533-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
 <20210423084750.18533-1-jon.lin@rock-chips.com>
Message-ID: <20210423084750.18533-3-jon.lin@rock-chips.com>

1.Add standard spi-cs-high support
2.Refer to spi-controller.yaml for details

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index b17463e5fda6..5b52f2bc3d9a 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -108,6 +108,8 @@
 #define CR0_OPM_MASTER				0x0
 #define CR0_OPM_SLAVE				0x1
 
+#define CR0_SOI_OFFSET				23
+
 #define CR0_MTM_OFFSET				0x21
 
 /* Bit fields in SER, 2bit */
@@ -238,7 +240,7 @@ static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 {
 	struct spi_controller *ctlr = spi->controller;
 	struct rockchip_spi *rs = spi_controller_get_devdata(ctlr);
-	bool cs_asserted = !enable;
+	bool cs_asserted = spi->mode & SPI_CS_HIGH ? enable : !enable;
 
 	/* Return immediately for no-op */
 	if (cs_asserted == rs->cs_asserted[spi->chip_select])
@@ -509,6 +511,8 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	cr0 |= (spi->mode & 0x3U) << CR0_SCPH_OFFSET;
 	if (spi->mode & SPI_LSB_FIRST)
 		cr0 |= CR0_FBM_LSB << CR0_FBM_OFFSET;
+	if (spi->mode & SPI_CS_HIGH)
+		cr0 |= BIT(spi->chip_select) << CR0_SOI_OFFSET;
 
 	if (xfer->rx_buf && xfer->tx_buf)
 		cr0 |= CR0_XFM_TR << CR0_XFM_OFFSET;
@@ -787,7 +791,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 
 	ctlr->auto_runtime_pm = true;
 	ctlr->bus_num = pdev->id;
-	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP | SPI_LSB_FIRST;
+	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP | SPI_LSB_FIRST | SPI_CS_HIGH;
 	if (slave_mode) {
 		ctlr->mode_bits |= SPI_NO_CS;
 		ctlr->slave_abort = rockchip_spi_slave_abort;
-- 
2.17.1





From jon.lin at rock-chips.com  Fri Apr 23 09:47:48 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Fri, 23 Apr 2021 16:47:48 +0800
Subject: [PATCH v1 6/8] spi: rockchip: Set rx_fifo interrupt waterline base on
 transfer item
In-Reply-To: <20210423084155.17439-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
Message-ID: <20210423084750.18533-1-jon.lin@rock-chips.com>

The error here is to calculate the width as 8 bits. In fact, 16 bits
should be considered.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index cfcbfd6c1be5..c245af1692c7 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -547,8 +547,8 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	 * interrupt exactly when the fifo is full doesn't seem to work,
 	 * so we need the strict inequality here
 	 */
-	if (xfer->len < rs->fifo_len)
-		writel_relaxed(xfer->len - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
+	if ((xfer->len / rs->n_bytes) < rs->fifo_len)
+		writel_relaxed(xfer->len / rs->n_bytes - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 	else
 		writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 
-- 
2.17.1





From heiko at sntech.de  Fri Apr 23 10:00:18 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Fri, 23 Apr 2021 11:00:18 +0200
Subject: [PATCH v1 2/8] spi: rockchip: add compatible string for rv1126
In-Reply-To: <20210423084155.17439-2-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
 <20210423084155.17439-2-jon.lin@rock-chips.com>
Message-ID: <10186800.nitPUkWRp2@diego>

Hi Jon,

Am Freitag, 23. April 2021, 10:41:49 CEST schrieb Jon Lin:
> Add compatible string for rv1126 to applications for potential
> applications.
> 
> Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
> ---
>  drivers/spi/spi-rockchip.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index 52d6259d96ed..dae0281f6ba8 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -911,7 +911,9 @@ static const struct dev_pm_ops rockchip_spi_pm = {
>  };
>  
>  static const struct of_device_id rockchip_spi_dt_match[] = {
> -	{ .compatible = "rockchip,px30-spi", },
> +	{ .compatible = "rockchip,px30-spi",   },

unrelated change with the add "space" at the end

> +	{ .compatible = "rockchip,rv1108-spi", },
> +	{ .compatible = "rockchip,rv1126-spi", },

it seems the list was sorted alphabetically, so rv* comes after rk*
which is probably why the rv1108 was at the bottom and rightfully so.


Heiko

>  	{ .compatible = "rockchip,rk3036-spi", },
>  	{ .compatible = "rockchip,rk3066-spi", },
>  	{ .compatible = "rockchip,rk3188-spi", },
> @@ -921,7 +923,6 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
>  	{ .compatible = "rockchip,rk3328-spi", },
>  	{ .compatible = "rockchip,rk3368-spi", },
>  	{ .compatible = "rockchip,rk3399-spi", },
> -	{ .compatible = "rockchip,rv1108-spi", },
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
> 






From dingsenjie at 163.com  Fri Apr 23 10:04:09 2021
From: dingsenjie at 163.com (dingsenjie at 163.com)
Date: Fri, 23 Apr 2021 17:04:09 +0800
Subject: [PATCH] soc: ti: Use devm_platform_ioremap_resource_byname
Message-ID: <20210423090409.25032-1-dingsenjie@163.com>

From: dingsenjie <dingsenjie at yulong.com>

Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately

Signed-off-by: dingsenjie <dingsenjie at yulong.com>
---
 drivers/soc/ti/k3-ringacc.c | 18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index b495b0d..aa8ebd4 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -1352,7 +1352,6 @@ static int k3_ringacc_init(struct platform_device *pdev,
 	const struct soc_device_attribute *soc;
 	void __iomem *base_fifo, *base_rt;
 	struct device *dev = &pdev->dev;
-	struct resource *res;
 	int ret, i;
 
 	dev->msi_domain = of_msi_get_domain(dev, dev->of_node,
@@ -1373,24 +1372,19 @@ static int k3_ringacc_init(struct platform_device *pdev,
 		ringacc->dma_ring_reset_quirk = soc_data->dma_ring_reset_quirk;
 	}
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rt");
-	base_rt = devm_ioremap_resource(dev, res);
+	base_rt = devm_platform_ioremap_resource_byname(pdev, "rt");
 	if (IS_ERR(base_rt))
 		return PTR_ERR(base_rt);
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fifos");
-	base_fifo = devm_ioremap_resource(dev, res);
+	base_fifo = devm_platform_ioremap_resource_byname(pdev, "fifos");
 	if (IS_ERR(base_fifo))
 		return PTR_ERR(base_fifo);
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "proxy_gcfg");
-	ringacc->proxy_gcfg = devm_ioremap_resource(dev, res);
+	ringacc->proxy_gcfg = devm_platform_ioremap_resource_byname(pdev, "proxy_gcfg");
 	if (IS_ERR(ringacc->proxy_gcfg))
 		return PTR_ERR(ringacc->proxy_gcfg);
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-					   "proxy_target");
-	ringacc->proxy_target_base = devm_ioremap_resource(dev, res);
+	ringacc->proxy_target_base = devm_platform_ioremap_resource_byname(pdev, "proxy_target");
 	if (IS_ERR(ringacc->proxy_target_base))
 		return PTR_ERR(ringacc->proxy_target_base);
 
@@ -1458,7 +1452,6 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev,
 	struct device *dev = &pdev->dev;
 	struct k3_ringacc *ringacc;
 	void __iomem *base_rt;
-	struct resource *res;
 	int i;
 
 	ringacc = devm_kzalloc(dev, sizeof(*ringacc), GFP_KERNEL);
@@ -1473,8 +1466,7 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev,
 
 	mutex_init(&ringacc->req_lock);
 
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ringrt");
-	base_rt = devm_ioremap_resource(dev, res);
+	base_rt = devm_platform_ioremap_resource_byname(pdev, "ringrt");
 	if (IS_ERR(base_rt))
 		return ERR_CAST(base_rt);
 
-- 
1.9.1



From lars at metafoo.de  Fri Apr 23 10:17:00 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 23 Apr 2021 11:17:00 +0200
Subject: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
Message-ID: <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>

On 4/23/21 3:19 AM, Adrian Larumbe wrote:
> Recently at Imgtec we had to provide GLES API buffers with DMA transfer
> capabilities to device memory. We had access to a Xilinx CDMA IP module,
> but even though the hardware supports scatter-gather operations,
> the driver did not. This patch series' goal is to extend the driver
> to support SG transfers on CDMA devices.

Hi,

Thanks for the patch series. From an implementation point of view this 
looks good. But I'm a bit concerned about dmaengine API compliance.

The device_config() and device_prep_slave_sg() APIs are meant for 
memory-to-device or device-to-memory transfers. This means the device 
address is fixed and usually maps to a FIFO in the device.

What you are implementing is memory-to-memory, which means addresses are 
incremented on both sides of transfer. And this works if you know what 
you are doing, e.g. you know that you are using a specific dmaengine 
driver that implements the dmaengine API in a way that does not comply 
with the specification. But it breaks for generic dmaengine API clients 
that expect compliant behavior. And it is the reason why we have an API 
in the first place, to get consistent behavior. If you have to know 
about the driver specific semantics you might as well just bypass the 
framework and use driver specific functions.

And the CDMA seems to support the dmaengine API intended behavior 
through what it calls the keyhole feature where the address is not 
incremented. And if somebody wanted to use that feature they wouldn't be 
able to add support for it because it will break your usage of the 
prep_slave_sg() API.

It seems to me what we are missing from the DMAengine API is the 
equivalent of device_prep_dma_memcpy() that is able to take SG lists. 
There is already a memset_sg, it should be possible to add something 
similar for memcpy.

 ?- Lars





From leo.yan at linaro.org  Fri Apr 23 10:20:38 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 23 Apr 2021 17:20:38 +0800
Subject: [PATCH 2/4] coresight: tmc-etr: Track perf handler.
In-Reply-To: <20210421120413.3110775-3-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-3-daniel.kiss@arm.com>
Message-ID: <20210423092038.GB377091@leoy-ThinkPad-X240s>

Hi Daniel,

On Wed, Apr 21, 2021 at 02:04:11PM +0200, Daniel Kiss wrote:

[...]

> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index dd19d1d1c3b38..bf9f6311d8663 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1511,6 +1511,12 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
>  		goto out;
>  	}
>  
> +	/* Serve only the tracer with the right handler */
> +	if (drvdata->perf_handle != handle) {
> +		spin_unlock_irqrestore(&drvdata->spinlock, flags);
> +		goto out;
> +	}
> +

I have concern for this change, Let's use the system-wide tracing as
an example.

If a system have 4 CPUs, for the perf with system wide tracing, the
tool maps the AUX ring buffers for four times, but the CoreSight
driver only allocates pages once and maps these physical pages for
four times to user space.  Therefore, the perf tool in the userspace
manages 4 AUX ring buffers, every AUX ring buffer is served for one
CPU.

The confusion between the CoreSight driver (in the kernel) and the
perf tool (in the userspace) is: there actually has only one ring
buffer for the enabled sink (let's say ETR), but there have four ring
buffer control structures, the control structure is
'perf_event_mmap_page' which is resident in the first page for perf's
general ring buffer (please note, this ring buffer is different from
AUX ring buffer).

IIUC, this patch only allows the first CPU which enables coresight path
to update the AUX ring buffer.  This can break the case:

  - Step 1: perf tool opens ETM event; we can use the command:

    # perf record -o ${perfdata} -e cs_etm/@tmc_etr0/ -a
           -- dd if=/dev/zero of=/dev/null

  - Step 2: the profiled program "dd" is firstly schedued in CPU0, so
    its "perf_handle" will be assigned to "drvdata->perf_handle";

  - Step 3: if the program "dd" is migrated to CPU1 and it never runs
    on CPU0 afterwards, then this patch will prevent to update the AUX
    ring buffer, due to the "drvdata->perf_handle" cannot match with
    CPU1's handler.

On the other hand, I think we should change to always stick to the
same "perf_output_handle" for all CPUs, thus it can allow all CPUs
to use the same structure 'perf_event_mmap_page' for AUX ring buffer
management.

[...]

Thanks,
Leo


From vivek.gautam at arm.com  Fri Apr 23 10:51:36 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:36 +0530
Subject: [PATCH RFC v1 00/11] iommu/virtio: vSVA support with Arm
Message-ID: <20210423095147.27922-1-vivek.gautam@arm.com>

This patch series aims at enabling vSVA (Shared virtual addressing)
support in virtio-iommu driver for devices assigned to the guest
kernel using pci-passthrough technique (also called as Device
assignment). The changes are proposed to make virtio-iommu driver
become intelligent to support Shared virtual addressing.

The virtio-iommu device serves as the para-virtualized iommu for
IO devices running in the guest. This work is done for PCI devices
that are able to generate Address Translation Service (ATS) and
Page Request Interface (PRI) requests.

With vSVA support now devices running in guest can start using process
address space (Guest virtual address, GVA) for DMA. The below diagram
shows a simple system layout using iommus in guest and host.

                 ------------------
		 |  virtio-iommu  |
		 |    driver      |
		 |  (front-end)   |
		 |________________|
                                               Guest kernel
          --------------------------------------------------

                 ------------------
		 |  virtio-iommu  |
		 |    driver      |
		 |  (back-end)    |
		 |________________|
                                                    kvmtool
          --------------------------------------------------

                  -----------------
		 |  arm-smmu-v3   |
		 |    driver      |
		 |________________|
                                                Host kernel
          --------------------------------------------------

                  -----------------
		 |  arm-smmu-v3   |
		 |    hardware    |
		 |________________|
                                                   Hardware
          --------------------------------------------------

The flow of various messages/requests looks like below:
a) The stage-1 page tables are prepared by virtio-iommu driver using
   CPU page table info. This page table data then flow from guest kernel
   to host kernel using VFIO uapi changes [1]. The stage-1 page tables
   are then programmed into the hardware by the arm-smmu-v3 driver.
b) The device can then start initiating DMA transactions using ATS
   request.
c) When using GVA, SMMU encounters a translation fault and responds
   to the device with ATS success - translation failure.
d) The device can then send a PRI request that eventually populates
   the PRIQ of arm-smmu-v3.
e) The page fault info is captured from PRIQ, and sent to the guest
   kernel using VFIO dma fault region as added in [1].
f) The page fault is received on the virt-queue by virtio-iommu driver
   and is then passed to io-page-fault handler. The io page fault
   handler talks to mm fault handling engine in guest kernel and gets
   the CPU page tables updated.
g) Virtio-iommu driver then sends page_response backend virtio-iommu
   in vmm. From there this page_response info is passed to host kernel.
h) The arm-smmu-v3 driver running in the host will then use this page
   repsonse info and send a response to the requesting device.

The series use nested page table support [2] as the base to build vSVA
solution.

The changes are inspired from the SVA support in arm-smmu-v3 and are
making use of io-page-fault changes added by Jean Philippe [3].

The changes include:
- The mmu notifier structure, and allocation and freeing up of shared
  context descriptors are moved to arm-smmu-v3-cd-lib library driver,
  and changes have been made to arm-smmu-v3-sva driver to use these
  shared cd alloc/free helpers.
- In virtio-iommu driver:
  - changes have been added to add various iommu_ops to enable/disable
    feature, and to perform sva_bind/unbind. 
  - A iopf queue has been added that accepts incoming page faults, and
    work with mm fault handler to get the page resident.
  - Incoming page fault information from vmm is parsed using a work-queue
    and passed to the iopf fault handler.
  - A new virt-queue request has been added to send page response back
    to the vmm back-end driver. The page response is populated from the
    mm fault handler response, and includes information on Page Request
    pasid, group-id, and response code, etc.

[1] https://lore.kernel.org/linux-iommu/20210411114659.15051-1-eric.auger at redhat.com/
    https://lore.kernel.org/linux-iommu/20210411111228.14386-1-eric.auger at redhat.com/
[2] https://lore.kernel.org/linux-iommu/20210115121342.15093-1-vivek.gautam at arm.com/
[3] https://www.spinics.net/lists/arm-kernel/msg886518.html

Vivek Gautam (11):
  uapi/virtio-iommu: Add page request grp-id and flags information
  iommu/virtio: Maintain a list of endpoints served by viommu_dev
  iommu/virtio: Handle incoming page faults
  iommu/virtio: Add a io page fault queue
  iommu/virtio: Add SVA feature and related enable/disable callbacks
  iommu/pasid-table: Add pasid table ops for shared context management
  iommu/arm-smmu-v3: Move shared context descriptor code to cd-lib
  iommu/arm-smmu-v3: Implement shared context alloc and free ops
  iommu/virtio: Implement sva bind/unbind calls
  uapi/virtio-iommu: Add a new request type to send page response
  iommu/virtio: Add support to send page response

 .../arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c      | 165 ++++-
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 230 +------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |   1 -
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |   2 -
 drivers/iommu/iommu-pasid-table.h             |  43 ++
 drivers/iommu/virtio-iommu.c                  | 634 +++++++++++++++++-
 include/uapi/linux/virtio_iommu.h             |  35 +
 7 files changed, 904 insertions(+), 206 deletions(-)

-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:37 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:37 +0530
Subject: [PATCH RFC v1 01/11] uapi/virtio-iommu: Add page request grp-id and
 flags information
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-2-vivek.gautam@arm.com>

Add fault information for group-id and necessary flags for page
request faults that can be handled by page fault handler in
virtio-iommu driver.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
Cc: Joerg Roedel <joro at 8bytes.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Robin Murphy <robin.murphy at arm.com>
Cc: Jean-Philippe Brucker <jean-philippe at linaro.org>
Cc: Eric Auger <eric.auger at redhat.com>
Cc: Alex Williamson <alex.williamson at redhat.com>
Cc: Kevin Tian <kevin.tian at intel.com>
Cc: Jacob Pan <jacob.jun.pan at linux.intel.com>
Cc: Liu Yi L <yi.l.liu at intel.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
---
 include/uapi/linux/virtio_iommu.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index f8bf927a0689..accc3318ce46 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -307,14 +307,27 @@ struct virtio_iommu_req_invalidate {
 #define VIRTIO_IOMMU_FAULT_F_DMA_UNRECOV	1
 #define VIRTIO_IOMMU_FAULT_F_PAGE_REQ		2
 
+#define VIRTIO_IOMMU_FAULT_PRQ_F_PASID_VALID		(1 << 0)
+#define VIRTIO_IOMMU_FAULT_PRQ_F_LAST_PAGE		(1 << 1)
+#define VIRTIO_IOMMU_FAULT_PRQ_F_PRIV_DATA		(1 << 2)
+#define VIRTIO_IOMMU_FAULT_PRQ_F_NEEDS_PASID		(1 << 3)
+
+#define VIRTIO_IOMMU_FAULT_UNREC_F_PASID_VALID		(1 << 0)
+#define VIRTIO_IOMMU_FAULT_UNREC_F_ADDR_VALID		(1 << 1)
+#define VIRTIO_IOMMU_FAULT_UNREC_F_FETCH_ADDR_VALID	(1 << 2)
+
 struct virtio_iommu_fault {
 	__u8					reason;
 	__u8					reserved[3];
 	__le16					flt_type;
 	__u8					reserved2[2];
+	/* flags is actually permission flags */
 	__le32					flags;
+	/* flags for PASID and Page request handling info */
+	__le32					pr_evt_flags;
 	__le32					endpoint;
 	__le32					pasid;
+	__le32					grpid;
 	__u8					reserved3[4];
 	__le64					address;
 	__u8					reserved4[8];
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:38 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:38 +0530
Subject: [PATCH RFC v1 02/11] iommu/virtio: Maintain a list of endpoints
 served by viommu_dev
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-3-vivek.gautam@arm.com>

Keeping a record of list of endpoints that are served by the virtio-iommu
device would help in redirecting the requests of page faults to the
correct endpoint device to handle such requests.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 50039070e2aa..c970f386f031 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -48,6 +48,7 @@ struct viommu_dev {
 	spinlock_t			request_lock;
 	struct list_head		requests;
 	void				*evts;
+	struct list_head		endpoints;
 
 	/* Device configuration */
 	struct iommu_domain_geometry	geometry;
@@ -115,6 +116,12 @@ struct viommu_endpoint {
 	void				*pgtf;
 };
 
+struct viommu_ep_entry {
+	u32				eid;
+	struct viommu_endpoint		*vdev;
+	struct list_head		list;
+};
+
 struct viommu_request {
 	struct list_head		list;
 	void				*writeback;
@@ -573,6 +580,7 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 	size_t probe_len;
 	struct virtio_iommu_req_probe *probe;
 	struct virtio_iommu_probe_property *prop;
+	struct viommu_ep_entry *ep;
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
 	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
 
@@ -640,6 +648,18 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 		prop = (void *)probe->properties + cur;
 		type = le16_to_cpu(prop->type) & VIRTIO_IOMMU_PROBE_T_MASK;
 	}
+	if (ret)
+		goto out_free;
+
+	ep = kzalloc(sizeof(*ep), GFP_KERNEL);
+	if (!ep) {
+		ret = -ENOMEM;
+		goto out_free;
+	}
+	ep->eid = probe->endpoint;
+	ep->vdev = vdev;
+
+	list_add(&ep->list, &viommu->endpoints);
 
 out_free:
 	kfree(probe);
@@ -1649,6 +1669,7 @@ static int viommu_probe(struct virtio_device *vdev)
 	viommu->dev = dev;
 	viommu->vdev = vdev;
 	INIT_LIST_HEAD(&viommu->requests);
+	INIT_LIST_HEAD(&viommu->endpoints);
 
 	ret = viommu_init_vqs(viommu);
 	if (ret)
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:39 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:39 +0530
Subject: [PATCH RFC v1 03/11] iommu/virtio: Handle incoming page faults
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-4-vivek.gautam@arm.com>

Redirect the incoming page faults to the registered fault handler
that can take the fault information such as, pasid, page request
group-id, address and pasid flags.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c      | 80 ++++++++++++++++++++++++++++++-
 include/uapi/linux/virtio_iommu.h |  1 +
 2 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index c970f386f031..fd237cad1ce5 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -37,6 +37,13 @@
 /* Some architectures need an Address Space ID for each page table */
 DEFINE_XARRAY_ALLOC1(viommu_asid_xa);
 
+struct viommu_dev_pri_work {
+	struct work_struct		work;
+	struct viommu_dev		*dev;
+	struct virtio_iommu_fault	*vfault;
+	u32				endpoint;
+};
+
 struct viommu_dev {
 	struct iommu_device		iommu;
 	struct device			*dev;
@@ -49,6 +56,8 @@ struct viommu_dev {
 	struct list_head		requests;
 	void				*evts;
 	struct list_head		endpoints;
+	struct workqueue_struct		*pri_wq;
+	struct viommu_dev_pri_work	*pri_work;
 
 	/* Device configuration */
 	struct iommu_domain_geometry	geometry;
@@ -666,6 +675,58 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 	return ret;
 }
 
+static void viommu_handle_ppr(struct work_struct *work)
+{
+	struct viommu_dev_pri_work *pwork =
+				container_of(work, struct viommu_dev_pri_work, work);
+	struct viommu_dev *viommu = pwork->dev;
+	struct virtio_iommu_fault *vfault = pwork->vfault;
+	struct viommu_endpoint *vdev;
+	struct viommu_ep_entry *ep;
+	struct iommu_fault_event fault_evt = {
+		.fault.type = IOMMU_FAULT_PAGE_REQ,
+	};
+	struct iommu_fault_page_request *prq = &fault_evt.fault.prm;
+
+	u32 flags	= le32_to_cpu(vfault->flags);
+	u32 prq_flags	= le32_to_cpu(vfault->pr_evt_flags);
+	u32 endpoint	= pwork->endpoint;
+
+	memset(prq, 0, sizeof(struct iommu_fault_page_request));
+	prq->addr = le64_to_cpu(vfault->address);
+
+	if (prq_flags & VIRTIO_IOMMU_FAULT_PRQ_F_LAST_PAGE)
+		prq->flags |= IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
+	if (prq_flags & VIRTIO_IOMMU_FAULT_PRQ_F_PASID_VALID) {
+		prq->flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
+		prq->pasid = le32_to_cpu(vfault->pasid);
+		prq->grpid = le32_to_cpu(vfault->grpid);
+	}
+
+	if (flags & VIRTIO_IOMMU_FAULT_F_READ)
+		prq->perm |= IOMMU_FAULT_PERM_READ;
+	if (flags & VIRTIO_IOMMU_FAULT_F_WRITE)
+		prq->perm |= IOMMU_FAULT_PERM_WRITE;
+	if (flags & VIRTIO_IOMMU_FAULT_F_EXEC)
+		prq->perm |= IOMMU_FAULT_PERM_EXEC;
+	if (flags & VIRTIO_IOMMU_FAULT_F_PRIV)
+		prq->perm |= IOMMU_FAULT_PERM_PRIV;
+
+	list_for_each_entry(ep, &viommu->endpoints, list) {
+		if (ep->eid == endpoint) {
+			vdev = ep->vdev;
+			break;
+		}
+	}
+
+	if ((prq_flags & VIRTIO_IOMMU_FAULT_PRQ_F_PASID_VALID) &&
+	    (prq_flags & VIRTIO_IOMMU_FAULT_PRQ_F_NEEDS_PASID))
+		prq->flags |= IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID;
+
+	if (iommu_report_device_fault(vdev->dev, &fault_evt))
+		dev_err(vdev->dev, "Couldn't handle page request\n");
+}
+
 static int viommu_fault_handler(struct viommu_dev *viommu,
 				struct virtio_iommu_fault *fault)
 {
@@ -679,7 +740,13 @@ static int viommu_fault_handler(struct viommu_dev *viommu,
 	u32 pasid	= le32_to_cpu(fault->pasid);
 
 	if (type == VIRTIO_IOMMU_FAULT_F_PAGE_REQ) {
-		dev_info(viommu->dev, "Page request fault - unhandled\n");
+		dev_info_ratelimited(viommu->dev,
+				     "Page request fault from EP %u\n",
+				     endpoint);
+
+		viommu->pri_work->vfault = fault;
+		viommu->pri_work->endpoint = endpoint;
+		queue_work(viommu->pri_wq, &viommu->pri_work->work);
 		return 0;
 	}
 
@@ -1683,6 +1750,17 @@ static int viommu_probe(struct virtio_device *vdev)
 		goto err_free_vqs;
 	}
 
+	viommu->pri_work = kzalloc(sizeof(*viommu->pri_work), GFP_KERNEL);
+	if (!viommu->pri_work)
+		return -ENOMEM;
+
+	viommu->pri_work->dev = viommu;
+
+	INIT_WORK(&viommu->pri_work->work, viommu_handle_ppr);
+	viommu->pri_wq = create_singlethread_workqueue("viommu-pri-wq");
+	if (!viommu->pri_wq)
+		return -ENOMEM;
+
 	viommu->map_flags = VIRTIO_IOMMU_MAP_F_READ | VIRTIO_IOMMU_MAP_F_WRITE;
 	viommu->last_domain = ~0U;
 
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index accc3318ce46..53aa88e6b077 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -302,6 +302,7 @@ struct virtio_iommu_req_invalidate {
 #define VIRTIO_IOMMU_FAULT_F_READ		(1 << 0)
 #define VIRTIO_IOMMU_FAULT_F_WRITE		(1 << 1)
 #define VIRTIO_IOMMU_FAULT_F_EXEC		(1 << 2)
+#define VIRTIO_IOMMU_FAULT_F_PRIV		(1 << 3)
 #define VIRTIO_IOMMU_FAULT_F_ADDRESS		(1 << 8)
 
 #define VIRTIO_IOMMU_FAULT_F_DMA_UNRECOV	1
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:40 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:40 +0530
Subject: [PATCH RFC v1 04/11] iommu/virtio: Add a io page fault queue
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-5-vivek.gautam@arm.com>

Add a io page fault queue to the driver so that it can be used
to redirect faults to the handler.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index fd237cad1ce5..3da5f0807711 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -58,6 +58,7 @@ struct viommu_dev {
 	struct list_head		endpoints;
 	struct workqueue_struct		*pri_wq;
 	struct viommu_dev_pri_work	*pri_work;
+	struct iopf_queue		*iopf_pri;
 
 	/* Device configuration */
 	struct iommu_domain_geometry	geometry;
@@ -581,6 +582,15 @@ static int viommu_add_pstf(struct viommu_endpoint *vdev, void *pstf, size_t len)
 	return 0;
 }
 
+static int viommu_init_queues(struct viommu_dev *viommu)
+{
+	viommu->iopf_pri = iopf_queue_alloc(dev_name(viommu->dev));
+	if (!viommu->iopf_pri)
+		return -ENOMEM;
+
+	return 0;
+}
+
 static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 {
 	int ret;
@@ -670,6 +680,15 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 
 	list_add(&ep->list, &viommu->endpoints);
 
+	ret = viommu_init_queues(viommu);
+	if (ret)
+		goto out_free_eps;
+
+	kfree(probe);
+	return 0;
+
+out_free_eps:
+	kfree(ep);
 out_free:
 	kfree(probe);
 	return ret;
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:41 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:41 +0530
Subject: [PATCH RFC v1 05/11] iommu/virtio: Add SVA feature and related
 enable/disable callbacks
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-6-vivek.gautam@arm.com>

Add a feature flag to virtio iommu for Shared virtual addressing
(SVA). This feature would indicate the availablily path for handling
device page faults, and the provision for sending page response.
Also add necessary methods to enable and disable SVA so that the
masters can enable the SVA path. This also requires enabling the
PRI capability on the device.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c      | 268 ++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_iommu.h |   1 +
 2 files changed, 269 insertions(+)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 3da5f0807711..250c137a211b 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -18,6 +18,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_platform.h>
 #include <linux/pci.h>
+#include <linux/pci-ats.h>
 #include <linux/platform_device.h>
 #include <linux/virtio.h>
 #include <linux/virtio_config.h>
@@ -26,6 +27,7 @@
 
 #include <uapi/linux/virtio_iommu.h>
 #include "iommu-pasid-table.h"
+#include "iommu-sva-lib.h"
 
 #define MSI_IOVA_BASE			0x8000000
 #define MSI_IOVA_LENGTH			0x100000
@@ -37,6 +39,9 @@
 /* Some architectures need an Address Space ID for each page table */
 DEFINE_XARRAY_ALLOC1(viommu_asid_xa);
 
+static DEFINE_MUTEX(sva_lock);
+static DEFINE_MUTEX(iopf_lock);
+
 struct viommu_dev_pri_work {
 	struct work_struct		work;
 	struct viommu_dev		*dev;
@@ -71,6 +76,7 @@ struct viommu_dev {
 
 	bool				has_map:1;
 	bool				has_table:1;
+	bool				has_sva:1;
 };
 
 struct viommu_mapping {
@@ -124,6 +130,12 @@ struct viommu_endpoint {
 	void				*pstf;
 	/* Preferred page table format */
 	void				*pgtf;
+
+	/* sva */
+	bool				ats_supported;
+	bool				pri_supported;
+	bool				sva_enabled;
+	bool				iopf_enabled;
 };
 
 struct viommu_ep_entry {
@@ -582,6 +594,64 @@ static int viommu_add_pstf(struct viommu_endpoint *vdev, void *pstf, size_t len)
 	return 0;
 }
 
+static int viommu_init_ats_pri(struct viommu_endpoint *vdev)
+{
+	struct device *dev = vdev->dev;
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	if (!dev_is_pci(vdev->dev))
+		return -EINVAL;
+
+	if (pci_ats_supported(pdev))
+		vdev->ats_supported = true;
+
+	if (pci_pri_supported(pdev))
+		vdev->pri_supported = true;
+
+	return 0;
+}
+
+static int viommu_enable_pri(struct viommu_endpoint *vdev)
+{
+	int ret;
+	struct pci_dev *pdev;
+
+	/* Let's allow only 4 requests for PRI right now */
+	size_t max_inflight_pprs = 4;
+
+	if (!vdev->pri_supported || !vdev->ats_supported)
+		return -ENODEV;
+
+	pdev = to_pci_dev(vdev->dev);
+
+	ret = pci_reset_pri(pdev);
+	if (ret)
+		return ret;
+
+	ret = pci_enable_pri(pdev, max_inflight_pprs);
+	if (ret) {
+		dev_err(vdev->dev, "cannot enable PRI: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void viommu_disable_pri(struct viommu_endpoint *vdev)
+{
+	struct pci_dev *pdev;
+
+	if (!dev_is_pci(vdev->dev))
+		return;
+
+	pdev = to_pci_dev(vdev->dev);
+
+	if (!pdev->pri_enabled)
+		return;
+
+	pci_disable_pri(pdev);
+}
+
 static int viommu_init_queues(struct viommu_dev *viommu)
 {
 	viommu->iopf_pri = iopf_queue_alloc(dev_name(viommu->dev));
@@ -684,6 +754,10 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
 	if (ret)
 		goto out_free_eps;
 
+	ret = viommu_init_ats_pri(vdev);
+	if (ret)
+		goto out_free_eps;
+
 	kfree(probe);
 	return 0;
 
@@ -1681,6 +1755,194 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
 	return iommu_fwspec_add_ids(dev, args->args, 1);
 }
 
+static bool viommu_endpoint_iopf_supported(struct viommu_endpoint *vdev)
+{
+	/* TODO: support Stall model later */
+	return vdev->pri_supported;
+}
+
+bool viommu_endpoint_sva_supported(struct viommu_endpoint *vdev)
+{
+	struct viommu_dev *viommu = vdev->viommu;
+
+	if (!viommu->has_sva)
+		return false;
+
+	return vdev->pasid_bits;
+}
+
+bool viommu_endpoint_sva_enabled(struct viommu_endpoint *vdev)
+{
+	bool enabled;
+
+	mutex_lock(&sva_lock);
+	enabled = vdev->sva_enabled;
+	mutex_unlock(&sva_lock);
+	return enabled;
+}
+
+static int viommu_endpoint_sva_enable_iopf(struct viommu_endpoint *vdev)
+{
+	int ret;
+	struct device *dev = vdev->dev;
+
+	if (!viommu_endpoint_iopf_supported(vdev))
+		return 0;
+
+	if (!vdev->iopf_enabled)
+		return -EINVAL;
+
+	if (vdev->pri_supported) {
+		ret = iopf_queue_add_device(vdev->viommu->iopf_pri, dev);
+		if (ret)
+			return ret;
+	} else {
+		/* No other way to handle io page fault then */
+		return -EINVAL;
+	}
+
+	ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf, dev);
+	if (ret)
+		iopf_queue_remove_device(vdev->viommu->iopf_pri, dev);
+
+	return ret;
+}
+
+static void viommu_endpoint_sva_disable_iopf(struct viommu_endpoint *vdev)
+{
+	struct device *dev = vdev->dev;
+
+	if (!vdev->iopf_enabled)
+		return;
+
+	iommu_unregister_device_fault_handler(dev);
+	iopf_queue_remove_device(vdev->viommu->iopf_pri, dev);
+}
+
+static int viommu_endpoint_enable_sva(struct viommu_endpoint *vdev)
+{
+	int ret;
+
+	mutex_lock(&sva_lock);
+	ret = viommu_endpoint_sva_enable_iopf(vdev);
+	if (!ret)
+		vdev->sva_enabled = true;
+	mutex_unlock(&sva_lock);
+
+	return ret;
+}
+
+static int viommu_endpoint_disable_sva(struct viommu_endpoint *vdev)
+{
+	mutex_lock(&sva_lock);
+	viommu_endpoint_sva_disable_iopf(vdev);
+	vdev->sva_enabled = false;
+	mutex_unlock(&sva_lock);
+
+	return 0;
+}
+
+int viommu_endpoint_enable_iopf(struct viommu_endpoint *vdev)
+{
+	int ret;
+
+	mutex_lock(&iopf_lock);
+	if (vdev->pri_supported) {
+		ret = viommu_enable_pri(vdev);
+		if (ret)
+			return ret;
+	}
+	vdev->iopf_enabled = true;
+	mutex_unlock(&iopf_lock);
+	return 0;
+}
+
+int viommu_endpoint_disable_iopf(struct viommu_endpoint *vdev)
+{
+	if (vdev->sva_enabled)
+		return -EBUSY;
+
+	mutex_lock(&iopf_lock);
+	viommu_disable_pri(vdev);
+	vdev->iopf_enabled = false;
+	mutex_unlock(&iopf_lock);
+	return 0;
+}
+
+static bool viommu_dev_has_feature(struct device *dev,
+				   enum iommu_dev_features feat)
+{
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+	if (!vdev)
+		return false;
+
+	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return viommu_endpoint_iopf_supported(vdev);
+	case IOMMU_DEV_FEAT_SVA:
+		return viommu_endpoint_sva_supported(vdev);
+	default:
+		return false;
+	}
+}
+
+static bool viommu_dev_feature_enabled(struct device *dev,
+				       enum iommu_dev_features feat)
+{
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+	if (!vdev)
+		return false;
+
+	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return vdev->iopf_enabled;
+	case IOMMU_DEV_FEAT_SVA:
+		return viommu_endpoint_sva_enabled(vdev);
+	default:
+		return false;
+	}
+}
+
+static int viommu_dev_enable_feature(struct device *dev,
+				     enum iommu_dev_features feat)
+{
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+	if (!viommu_dev_has_feature(dev, feat))
+		return -ENODEV;
+
+	if (viommu_dev_feature_enabled(dev, feat))
+		return -EBUSY;
+
+	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return viommu_endpoint_enable_iopf(vdev);
+	case IOMMU_DEV_FEAT_SVA:
+		return viommu_endpoint_enable_sva(vdev);
+	default:
+		return -EINVAL;
+	}
+}
+
+static int viommu_dev_disable_feature(struct device *dev,
+				      enum iommu_dev_features feat)
+{
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+
+	if (!viommu_dev_feature_enabled(dev, feat))
+		return -EINVAL;
+
+	switch (feat) {
+	case IOMMU_DEV_FEAT_IOPF:
+		return viommu_endpoint_disable_iopf(vdev);
+	case IOMMU_DEV_FEAT_SVA:
+		return viommu_endpoint_disable_sva(vdev);
+	default:
+		return -EINVAL;
+	}
+}
 static struct iommu_ops viommu_ops = {
 	.domain_alloc		= viommu_domain_alloc,
 	.domain_free		= viommu_domain_free,
@@ -1695,6 +1957,9 @@ static struct iommu_ops viommu_ops = {
 	.get_resv_regions	= viommu_get_resv_regions,
 	.put_resv_regions	= generic_iommu_put_resv_regions,
 	.of_xlate		= viommu_of_xlate,
+	.dev_feat_enabled	= viommu_dev_feature_enabled,
+	.dev_enable_feat	= viommu_dev_enable_feature,
+	.dev_disable_feat	= viommu_dev_disable_feature,
 };
 
 static int viommu_init_vqs(struct viommu_dev *viommu)
@@ -1811,6 +2076,8 @@ static int viommu_probe(struct virtio_device *vdev)
 		goto err_free_vqs;
 	}
 
+	viommu->has_sva = virtio_has_feature(vdev, VIRTIO_IOMMU_F_SVA);
+
 	viommu->geometry = (struct iommu_domain_geometry) {
 		.aperture_start	= input_start,
 		.aperture_end	= input_end,
@@ -1902,6 +2169,7 @@ static unsigned int features[] = {
 	VIRTIO_IOMMU_F_PROBE,
 	VIRTIO_IOMMU_F_MMIO,
 	VIRTIO_IOMMU_F_ATTACH_TABLE,
+	VIRTIO_IOMMU_F_SVA,
 };
 
 static struct virtio_device_id id_table[] = {
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index 53aa88e6b077..88a3db493108 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -17,6 +17,7 @@
 #define VIRTIO_IOMMU_F_PROBE			4
 #define VIRTIO_IOMMU_F_MMIO			5
 #define VIRTIO_IOMMU_F_ATTACH_TABLE		6
+#define VIRTIO_IOMMU_F_SVA			7
 
 struct virtio_iommu_range_64 {
 	__le64					start;
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:42 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:42 +0530
Subject: [PATCH RFC v1 06/11] iommu/pasid-table: Add pasid table ops for
 shared context management
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-7-vivek.gautam@arm.com>

Add pasid table ops to allocate and free shared contexts. These helpers
interact using mmu notifiers, so add a mmu notifier implementation
structure in pasid tables as well. This change can help pull out the
shared pasid (context-descriptor) implementation out of arm-smmu-v3.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 .../arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c      |  1 +
 drivers/iommu/iommu-pasid-table.h             | 42 +++++++++++++++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
index fa1a6a632559..ea94f57ad261 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
@@ -299,6 +299,7 @@ arm_smmu_register_cd_table(struct device *dev, void *cookie,
 	tbl->cookie = cookie;
 	tbl->ops = &arm_cd_table_ops;
 	tbl->cfg.sync = sync_ops;
+	INIT_LIST_HEAD(&tbl->mmu_notifiers);
 
 	return tbl;
 }
diff --git a/drivers/iommu/iommu-pasid-table.h b/drivers/iommu/iommu-pasid-table.h
index 00b1c66e6a9e..4d6590e60f9b 100644
--- a/drivers/iommu/iommu-pasid-table.h
+++ b/drivers/iommu/iommu-pasid-table.h
@@ -8,6 +8,7 @@
 #define __IOMMU_PASID_TABLE_H
 
 #include <linux/io-pgtable.h>
+#include <linux/mmu_notifier.h>
 
 #include "arm/arm-smmu-v3/arm-smmu-v3.h"
 
@@ -52,6 +53,21 @@ struct iommu_vendor_psdtable_cfg {
 
 struct iommu_vendor_psdtable_ops;
 
+/* In-line with 'struct arm_smmu_mmu_notifier' */
+struct iommu_psdtable_mmu_notifier {
+	struct mmu_notifier		mn;
+	bool				cleared;
+	refcount_t			refs;
+	struct list_head		list;
+	/* cookie captures the domain implementation */
+	void				*cookie;
+	union {
+		struct arm_smmu_ctx_desc	*cd;
+	} vendor;
+};
+#define mn_to_pstiommu(mn)	\
+	container_of(mn, struct iommu_psdtable_mmu_notifier, mn)
+
 /**
  * struct iommu_pasid_table - describes a set of PASID tables
  *
@@ -64,6 +80,7 @@ struct iommu_pasid_table {
 	void					*cookie;
 	struct iommu_vendor_psdtable_cfg	cfg;
 	const struct iommu_vendor_psdtable_ops	*ops;
+	struct list_head			mmu_notifiers;
 };
 
 #define pasid_table_cfg_to_table(pst_cfg) \
@@ -77,6 +94,11 @@ struct iommu_vendor_psdtable_ops {
 	int (*write)(struct iommu_vendor_psdtable_cfg *cfg, int ssid,
 		     void *cookie);
 	bool (*free_asid)(struct xarray *xa, void *cookie_cd);
+	struct iommu_psdtable_mmu_notifier *
+	(*alloc_shared)(struct iommu_pasid_table *tbl, struct mm_struct *mm,
+			struct xarray *xa, u32 asid_bits);
+	void (*free_shared)(struct iommu_pasid_table *tbl, struct xarray *xa,
+			    void *cookie_cd);
 };
 
 /* CD manipulation ops */
@@ -129,6 +151,26 @@ static inline bool iommu_psdtable_free_asid(struct iommu_pasid_table *tbl,
 	return tbl->ops->free_asid(xa, cookie_cd);
 }
 
+static inline struct iommu_psdtable_mmu_notifier *
+iommu_psdtable_alloc_shared(struct iommu_pasid_table *tbl,
+			    struct mm_struct *mm, struct xarray *xa,
+			    u32 asid_bits)
+{
+	if (!tbl->ops->alloc_shared)
+		return false;
+
+	return tbl->ops->alloc_shared(tbl, mm, xa, asid_bits);
+}
+
+static inline void iommu_psdtable_free_shared(struct iommu_pasid_table *tbl,
+					      struct xarray *xa, void *cookie)
+{
+	if (!tbl->ops->free_shared)
+		return;
+
+	tbl->ops->free_shared(tbl, xa, cookie);
+}
+
 /* Sync ops for CD cfg or tlb */
 static inline void iommu_psdtable_flush(struct iommu_pasid_table *tbl,
 					void *cookie, int ssid, bool leaf)
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:43 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:43 +0530
Subject: [PATCH RFC v1 07/11] iommu/arm-smmu-v3: Move shared context
 descriptor code to cd-lib
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-8-vivek.gautam@arm.com>

In preparation to adding shared descriptor allocation and free pasid
table ops, pull out the alloc_shared_cd and free_shared_cd helpers from
arm-smmu-v3 and place them in arm-smmu-v3-cd-lib library driver.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 .../arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c      | 149 ++++++++++++++++++
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 147 -----------------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  12 ++
 drivers/iommu/iommu-pasid-table.h             |   1 +
 4 files changed, 162 insertions(+), 147 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
index ea94f57ad261..537b7c784d40 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
@@ -6,9 +6,11 @@
  */
 
 #include <linux/dma-iommu.h>
+#include <linux/slab.h>
 
 #include "arm-smmu-v3.h"
 #include "../../iommu-pasid-table.h"
+#include "../../io-pgtable-arm.h"
 
 static int arm_smmu_alloc_cd_leaf_table(struct device *dev,
 					struct arm_smmu_l1_ctx_desc *l1_desc)
@@ -278,6 +280,153 @@ static bool arm_smmu_free_asid(struct xarray *xa, void *cookie_cd)
 	return free;
 }
 
+/*
+ * 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;
+	struct iommu_pasid_table *tbl;
+
+	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, s1_cfg.cd);
+	smmu = smmu_domain->smmu;
+	tbl = smmu_domain->tbl;
+
+	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.
+	 */
+	ret = iommu_psdtable_write(tbl, &tbl->cfg, 0, cd);
+	if (ret)
+		return ERR_PTR(-ENOSYS);
+
+	/* Invalidate TLB entries previously associated with that context */
+	iommu_psdtable_flush_tlb(tbl, smmu_domain, asid);
+
+	xa_erase(&arm_smmu_asid_xa, asid);
+	return NULL;
+}
+
+struct arm_smmu_ctx_desc *
+arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, 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;
+
+	asid = arm64_mm_context_get(mm);
+	if (!asid)
+		return ERR_PTR(-ESRCH);
+
+	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;
+
+	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_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;
+
+	return cd;
+
+out_free_asid:
+	iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd);
+out_free_cd:
+	kfree(cd);
+out_put_context:
+	arm64_mm_context_put(mm);
+	return err < 0 ? ERR_PTR(err) : ret;
+}
+
+void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
+			     struct arm_smmu_ctx_desc *cd)
+{
+	if (iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd)) {
+		/* Unpin ASID */
+		arm64_mm_context_put(cd->mm);
+		kfree(cd);
+	}
+}
+
 struct iommu_vendor_psdtable_ops arm_cd_table_ops = {
 	.alloc	 = arm_smmu_alloc_cd_tables,
 	.free	 = arm_smmu_free_cd_tables,
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 775c34899935..da35d4cc0c1e 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
@@ -37,153 +37,6 @@ struct arm_smmu_bond {
 
 static DEFINE_MUTEX(sva_lock);
 
-/*
- * 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;
-	struct iommu_pasid_table *tbl;
-
-	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, s1_cfg.cd);
-	smmu = smmu_domain->smmu;
-	tbl = smmu_domain->tbl;
-
-	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.
-	 */
-	ret = iommu_psdtable_write(tbl, &tbl->cfg, 0, cd);
-	if (ret)
-		return ERR_PTR(-ENOSYS);
-
-	/* Invalidate TLB entries previously associated with that context */
-	iommu_psdtable_flush_tlb(tbl, smmu_domain, asid);
-
-	xa_erase(&arm_smmu_asid_xa, asid);
-	return NULL;
-}
-
-static struct arm_smmu_ctx_desc *
-arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, 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;
-
-	asid = arm64_mm_context_get(mm);
-	if (!asid)
-		return ERR_PTR(-ESRCH);
-
-	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;
-
-	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_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;
-
-	return cd;
-
-out_free_asid:
-	iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd);
-out_free_cd:
-	kfree(cd);
-out_put_context:
-	arm64_mm_context_put(mm);
-	return err < 0 ? ERR_PTR(err) : ret;
-}
-
-static void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
-				    struct arm_smmu_ctx_desc *cd)
-{
-	if (iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd)) {
-		/* Unpin ASID */
-		arm64_mm_context_put(cd->mm);
-		kfree(cd);
-	}
-}
-
 static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
 					 struct mm_struct *mm,
 					 unsigned long start, unsigned long end)
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 d5cf2d521c29..13ff024ab0d5 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -773,6 +773,10 @@ struct iommu_sva *arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
 void arm_smmu_sva_unbind(struct iommu_sva *handle);
 u32 arm_smmu_sva_get_pasid(struct iommu_sva *handle);
 void arm_smmu_sva_notifier_synchronize(void);
+struct arm_smmu_ctx_desc *
+arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm);
+void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
+			     struct arm_smmu_ctx_desc *cd);
 #else /* CONFIG_ARM_SMMU_V3_SVA */
 static inline bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 {
@@ -828,5 +832,13 @@ static inline u32 arm_smmu_sva_get_pasid(struct iommu_sva *handle)
 }
 
 static inline void arm_smmu_sva_notifier_synchronize(void) {}
+struct arm_smmu_ctx_desc *
+arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm)
+{
+	return ERR_PTR(-EINVAL);
+}
+
+static inline void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
+					   struct arm_smmu_ctx_desc *cd) {}
 #endif /* CONFIG_ARM_SMMU_V3_SVA */
 #endif /* _ARM_SMMU_V3_H */
diff --git a/drivers/iommu/iommu-pasid-table.h b/drivers/iommu/iommu-pasid-table.h
index 4d6590e60f9b..0e774ae6682a 100644
--- a/drivers/iommu/iommu-pasid-table.h
+++ b/drivers/iommu/iommu-pasid-table.h
@@ -8,6 +8,7 @@
 #define __IOMMU_PASID_TABLE_H
 
 #include <linux/io-pgtable.h>
+#include <linux/mmu_context.h>
 #include <linux/mmu_notifier.h>
 
 #include "arm/arm-smmu-v3/arm-smmu-v3.h"
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:44 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:44 +0530
Subject: [PATCH RFC v1 08/11] iommu/arm-smmu-v3: Implement shared context
 alloc and free ops
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-9-vivek.gautam@arm.com>

Implementing the alloc_shared_cd and free_shared_cd in cd-lib, and
start using them for arm-smmu-v3-sva implementation.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 .../arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c      | 71 ++++++++--------
 .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   | 83 ++++++++-----------
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |  1 -
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   | 14 ----
 4 files changed, 73 insertions(+), 96 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
index 537b7c784d40..b87829796596 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-cd-lib.c
@@ -285,16 +285,14 @@ static bool arm_smmu_free_asid(struct xarray *xa, void *cookie_cd)
  * descriptor is using it, try to replace it.
  */
 static struct arm_smmu_ctx_desc *
-arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
+arm_smmu_share_asid(struct iommu_pasid_table *tbl, struct mm_struct *mm,
+		    struct xarray *xa, u16 asid, u32 asid_bits)
 {
 	int ret;
 	u32 new_asid;
 	struct arm_smmu_ctx_desc *cd;
-	struct arm_smmu_device *smmu;
-	struct arm_smmu_domain *smmu_domain;
-	struct iommu_pasid_table *tbl;
 
-	cd = xa_load(&arm_smmu_asid_xa, asid);
+	cd = xa_load(xa, asid);
 	if (!cd)
 		return NULL;
 
@@ -306,12 +304,8 @@ arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
 		return cd;
 	}
 
-	smmu_domain = container_of(cd, struct arm_smmu_domain, s1_cfg.cd);
-	smmu = smmu_domain->smmu;
-	tbl = smmu_domain->tbl;
-
-	ret = xa_alloc(&arm_smmu_asid_xa, &new_asid, cd,
-		       XA_LIMIT(1, (1 << smmu->asid_bits) - 1), GFP_KERNEL);
+	ret = xa_alloc(xa, &new_asid, cd, XA_LIMIT(1, (1 << asid_bits) - 1),
+		       GFP_KERNEL);
 	if (ret)
 		return ERR_PTR(-ENOSPC);
 	/*
@@ -325,48 +319,52 @@ arm_smmu_share_asid(struct mm_struct *mm, u16 asid)
 	 * be some overlap between use of both ASIDs, until we invalidate the
 	 * TLB.
 	 */
-	ret = iommu_psdtable_write(tbl, &tbl->cfg, 0, cd);
+	ret = arm_smmu_write_ctx_desc(&tbl->cfg, 0, cd);
 	if (ret)
 		return ERR_PTR(-ENOSYS);
 
 	/* Invalidate TLB entries previously associated with that context */
-	iommu_psdtable_flush_tlb(tbl, smmu_domain, asid);
+	iommu_psdtable_flush_tlb(tbl, tbl->cookie, asid);
 
-	xa_erase(&arm_smmu_asid_xa, asid);
+	xa_erase(xa, asid);
 	return NULL;
 }
 
-struct arm_smmu_ctx_desc *
-arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm)
+static struct iommu_psdtable_mmu_notifier *
+arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm,
+			 struct xarray *xa, u32 asid_bits)
 {
 	u16 asid;
 	int err = 0;
 	u64 tcr, par, reg;
 	struct arm_smmu_ctx_desc *cd;
 	struct arm_smmu_ctx_desc *ret = NULL;
+	struct iommu_psdtable_mmu_notifier *pst_mn;
 
 	asid = arm64_mm_context_get(mm);
 	if (!asid)
 		return ERR_PTR(-ESRCH);
 
+	pst_mn = kzalloc(sizeof(*pst_mn), GFP_KERNEL);
+	if (!pst_mn) {
+		err = -ENOMEM;
+		goto out_put_context;
+	}
+
 	cd = kzalloc(sizeof(*cd), GFP_KERNEL);
 	if (!cd) {
 		err = -ENOMEM;
-		goto out_put_context;
+		goto out_free_mn;
 	}
 
 	refcount_set(&cd->refs, 1);
 
-	mutex_lock(&arm_smmu_asid_lock);
-	ret = arm_smmu_share_asid(mm, asid);
+	ret = arm_smmu_share_asid(tbl, mm, xa, asid, asid_bits);
 	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);
-
+	err = xa_insert(xa, asid, cd, GFP_KERNEL);
 	if (err)
 		goto out_free_asid;
 
@@ -406,21 +404,26 @@ arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm)
 	cd->asid = asid;
 	cd->mm = mm;
 
-	return cd;
+	pst_mn->vendor.cd = cd;
+	return pst_mn;
 
 out_free_asid:
-	iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd);
+	arm_smmu_free_asid(xa, cd);
 out_free_cd:
 	kfree(cd);
+out_free_mn:
+	kfree(pst_mn);
 out_put_context:
 	arm64_mm_context_put(mm);
 	return err < 0 ? ERR_PTR(err) : ret;
 }
 
-void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
-			     struct arm_smmu_ctx_desc *cd)
+static void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
+				    struct xarray *xa, void *cookie)
 {
-	if (iommu_psdtable_free_asid(tbl, &arm_smmu_asid_xa, cd)) {
+	struct arm_smmu_ctx_desc *cd = cookie;
+
+	if (iommu_psdtable_free_asid(tbl, xa, cd)) {
 		/* Unpin ASID */
 		arm64_mm_context_put(cd->mm);
 		kfree(cd);
@@ -428,11 +431,13 @@ void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
 }
 
 struct iommu_vendor_psdtable_ops arm_cd_table_ops = {
-	.alloc	 = arm_smmu_alloc_cd_tables,
-	.free	 = arm_smmu_free_cd_tables,
-	.prepare = arm_smmu_prepare_cd,
-	.write	 = arm_smmu_write_ctx_desc,
-	.free_asid = arm_smmu_free_asid,
+	.alloc		= arm_smmu_alloc_cd_tables,
+	.free		= arm_smmu_free_cd_tables,
+	.prepare	= arm_smmu_prepare_cd,
+	.write		= arm_smmu_write_ctx_desc,
+	.free_asid	= arm_smmu_free_asid,
+	.alloc_shared	= arm_smmu_alloc_shared_cd,
+	.free_shared	= arm_smmu_free_shared_cd,
 };
 
 struct iommu_pasid_table *
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 da35d4cc0c1e..ef28d0c409da 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,23 +13,12 @@
 #include "../../io-pgtable-arm.h"
 #include "../../iommu-pasid-table.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 iommu_sva		sva;
-	struct mm_struct		*mm;
-	struct arm_smmu_mmu_notifier	*smmu_mn;
-	struct list_head		list;
-	refcount_t			refs;
+	struct iommu_sva			sva;
+	struct mm_struct			*mm;
+	struct iommu_psdtable_mmu_notifier	*smmu_mn;
+	struct list_head			list;
+	refcount_t				refs;
 };
 
 #define sva_to_bond(handle) \
@@ -41,20 +30,22 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
 					 struct mm_struct *mm,
 					 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 iommu_psdtable_mmu_notifier *smmu_mn = mn_to_pstiommu(mn);
+	struct arm_smmu_domain *smmu_domain = smmu_mn->cookie;
+	struct arm_smmu_ctx_desc *cd = smmu_mn->vendor.cd;
 	size_t size = end - start + 1;
 
 	if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
-		arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid,
+		arm_smmu_tlb_inv_range_asid(start, size, cd->asid,
 					    PAGE_SIZE, false, smmu_domain);
 	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 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 iommu_psdtable_mmu_notifier *smmu_mn = mn_to_pstiommu(mn);
+	struct arm_smmu_domain *smmu_domain = smmu_mn->cookie;
+	struct arm_smmu_ctx_desc *cd = smmu_mn->vendor.cd;
 	struct iommu_pasid_table *tbl = smmu_domain->tbl;
 
 	mutex_lock(&sva_lock);
@@ -69,7 +60,7 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 	 */
 	iommu_psdtable_write(tbl, &tbl->cfg, mm->pasid, &quiet_cd);
 
-	iommu_psdtable_flush_tlb(tbl, smmu_domain, smmu_mn->cd->asid);
+	iommu_psdtable_flush_tlb(tbl, smmu_domain, cd->asid);
 	arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, 0, 0);
 
 	smmu_mn->cleared = true;
@@ -78,7 +69,7 @@ static void arm_smmu_mm_release(struct mmu_notifier *mn, struct mm_struct *mm)
 
 static void arm_smmu_mmu_notifier_free(struct mmu_notifier *mn)
 {
-	kfree(mn_to_smmu(mn));
+	kfree(mn_to_pstiommu(mn));
 }
 
 static struct mmu_notifier_ops arm_smmu_mmu_notifier_ops = {
@@ -88,63 +79,59 @@ static struct mmu_notifier_ops arm_smmu_mmu_notifier_ops = {
 };
 
 /* Allocate or get existing MMU notifier for this {domain, mm} pair */
-static struct arm_smmu_mmu_notifier *
+static struct iommu_psdtable_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;
+	struct iommu_psdtable_mmu_notifier *smmu_mn;
+	struct arm_smmu_device *smmu = smmu_domain->smmu;
 	struct iommu_pasid_table *tbl = smmu_domain->tbl;
 
-	list_for_each_entry(smmu_mn, &smmu_domain->mmu_notifiers, list) {
+	list_for_each_entry(smmu_mn, &tbl->mmu_notifiers, list) {
 		if (smmu_mn->mn.mm == mm) {
 			refcount_inc(&smmu_mn->refs);
 			return smmu_mn;
 		}
 	}
 
-	cd = arm_smmu_alloc_shared_cd(tbl, 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;
-	}
+	mutex_lock(&arm_smmu_asid_lock);
+	smmu_mn = iommu_psdtable_alloc_shared(tbl, mm, &arm_smmu_asid_xa,
+					      smmu->asid_bits);
+	mutex_unlock(&arm_smmu_asid_lock);
+	if (IS_ERR(smmu_mn))
+		return ERR_CAST(smmu_mn);
 
 	refcount_set(&smmu_mn->refs, 1);
-	smmu_mn->cd = cd;
-	smmu_mn->domain = smmu_domain;
+	smmu_mn->cookie = smmu_domain;
 	smmu_mn->mn.ops = &arm_smmu_mmu_notifier_ops;
 
 	ret = mmu_notifier_register(&smmu_mn->mn, mm);
-	if (ret) {
-		kfree(smmu_mn);
+	if (ret)
 		goto err_free_cd;
-	}
 
-	ret = iommu_psdtable_write(tbl, &tbl->cfg, mm->pasid, cd);
+	ret = iommu_psdtable_write(tbl, &tbl->cfg, mm->pasid,
+				   smmu_mn->vendor.cd);
 	if (ret)
 		goto err_put_notifier;
 
-	list_add(&smmu_mn->list, &smmu_domain->mmu_notifiers);
+	list_add(&smmu_mn->list, &tbl->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(tbl, cd);
+	iommu_psdtable_free_shared(tbl, &arm_smmu_asid_xa, smmu_mn->vendor.cd);
 	return ERR_PTR(ret);
 }
 
-static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
+static void
+arm_smmu_mmu_notifier_put(struct iommu_psdtable_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_ctx_desc *cd = smmu_mn->vendor.cd;
+	struct arm_smmu_domain *smmu_domain = smmu_mn->cookie;
 	struct iommu_pasid_table *tbl = smmu_domain->tbl;
 
 	if (!refcount_dec_and_test(&smmu_mn->refs))
@@ -164,7 +151,7 @@ static void arm_smmu_mmu_notifier_put(struct arm_smmu_mmu_notifier *smmu_mn)
 
 	/* Frees smmu_mn */
 	mmu_notifier_put(&smmu_mn->mn);
-	arm_smmu_free_shared_cd(tbl, cd);
+	iommu_psdtable_free_shared(tbl, &arm_smmu_asid_xa, cd);
 }
 
 static struct iommu_sva *
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 bbc4dc75de72..e55567b4d2f4 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -1987,7 +1987,6 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 	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->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 13ff024ab0d5..8a689b4316ac 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -737,8 +737,6 @@ struct arm_smmu_domain {
 
 	struct list_head		devices;
 	spinlock_t			devices_lock;
-
-	struct list_head		mmu_notifiers;
 };
 
 static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
@@ -773,10 +771,6 @@ struct iommu_sva *arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm,
 void arm_smmu_sva_unbind(struct iommu_sva *handle);
 u32 arm_smmu_sva_get_pasid(struct iommu_sva *handle);
 void arm_smmu_sva_notifier_synchronize(void);
-struct arm_smmu_ctx_desc *
-arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm);
-void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
-			     struct arm_smmu_ctx_desc *cd);
 #else /* CONFIG_ARM_SMMU_V3_SVA */
 static inline bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 {
@@ -832,13 +826,5 @@ static inline u32 arm_smmu_sva_get_pasid(struct iommu_sva *handle)
 }
 
 static inline void arm_smmu_sva_notifier_synchronize(void) {}
-struct arm_smmu_ctx_desc *
-arm_smmu_alloc_shared_cd(struct iommu_pasid_table *tbl, struct mm_struct *mm)
-{
-	return ERR_PTR(-EINVAL);
-}
-
-static inline void arm_smmu_free_shared_cd(struct iommu_pasid_table *tbl,
-					   struct arm_smmu_ctx_desc *cd) {}
 #endif /* CONFIG_ARM_SMMU_V3_SVA */
 #endif /* _ARM_SMMU_V3_H */
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:45 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:45 +0530
Subject: [PATCH RFC v1 09/11] iommu/virtio: Implement sva bind/unbind calls
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-10-vivek.gautam@arm.com>

SVA bind and unbind implementations will allow to prepare translation
context with CPU page tables that can be programmed into host iommu
hardware to realize shared address space utilization between the CPU
and virtualized devices using virtio-iommu.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c      | 199 +++++++++++++++++++++++++++++-
 include/uapi/linux/virtio_iommu.h |   2 +
 2 files changed, 199 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 250c137a211b..08f1294baeab 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -14,6 +14,9 @@
 #include <linux/interval_tree.h>
 #include <linux/iommu.h>
 #include <linux/io-pgtable.h>
+#include <linux/mm.h>
+#include <linux/mmu_context.h>
+#include <linux/mmu_notifier.h>
 #include <linux/module.h>
 #include <linux/of_iommu.h>
 #include <linux/of_platform.h>
@@ -28,6 +31,7 @@
 #include <uapi/linux/virtio_iommu.h>
 #include "iommu-pasid-table.h"
 #include "iommu-sva-lib.h"
+#include "io-pgtable-arm.h"
 
 #define MSI_IOVA_BASE			0x8000000
 #define MSI_IOVA_LENGTH			0x100000
@@ -41,6 +45,7 @@ DEFINE_XARRAY_ALLOC1(viommu_asid_xa);
 
 static DEFINE_MUTEX(sva_lock);
 static DEFINE_MUTEX(iopf_lock);
+static DEFINE_MUTEX(viommu_asid_lock);
 
 struct viommu_dev_pri_work {
 	struct work_struct		work;
@@ -88,10 +93,22 @@ struct viommu_mapping {
 struct viommu_mm {
 	int				pasid;
 	u64				archid;
+	struct viommu_sva_bond		*bond;
 	struct io_pgtable_ops		*ops;
 	struct viommu_domain		*domain;
 };
 
+struct viommu_sva_bond {
+	struct iommu_sva		sva;
+	struct mm_struct		*mm;
+	struct iommu_psdtable_mmu_notifier	*viommu_mn;
+	struct list_head		list;
+	refcount_t			refs;
+};
+
+#define sva_to_viommu_bond(handle) \
+	container_of(handle, struct viommu_sva_bond, sva)
+
 struct viommu_domain {
 	struct iommu_domain		domain;
 	struct viommu_dev		*viommu;
@@ -136,6 +153,7 @@ struct viommu_endpoint {
 	bool				pri_supported;
 	bool				sva_enabled;
 	bool				iopf_enabled;
+	struct list_head		bonds;
 };
 
 struct viommu_ep_entry {
@@ -1423,14 +1441,15 @@ static int viommu_attach_pasid_table(struct viommu_endpoint *vdev,
 
 		pst_cfg->iommu_dev = viommu->dev->parent;
 
+		mutex_lock(&viommu_asid_lock);
 		/* Prepare PASID tables info to allocate a new table */
 		ret = viommu_prepare_pst(vdev, pst_cfg, fmt);
 		if (ret)
-			return ret;
+			goto err_out_unlock;
 
 		ret = iommu_psdtable_alloc(tbl, pst_cfg);
 		if (ret)
-			return ret;
+			goto err_out_unlock;
 
 		pst_cfg->iommu_dev = viommu->dev->parent;
 		pst_cfg->fmt = PASID_TABLE_ARM_SMMU_V3;
@@ -1452,6 +1471,7 @@ static int viommu_attach_pasid_table(struct viommu_endpoint *vdev,
 			if (ret)
 				goto err_free_ops;
 		}
+		mutex_unlock(&viommu_asid_lock);
 	} else {
 		/* TODO: otherwise, check for compatibility with vdev. */
 		return -ENOSYS;
@@ -1467,6 +1487,8 @@ static int viommu_attach_pasid_table(struct viommu_endpoint *vdev,
 err_free_psdtable:
 	iommu_psdtable_free(tbl, &tbl->cfg);
 
+err_out_unlock:
+	mutex_unlock(&viommu_asid_lock);
 	return ret;
 }
 
@@ -1706,6 +1728,7 @@ static struct iommu_device *viommu_probe_device(struct device *dev)
 	vdev->dev = dev;
 	vdev->viommu = viommu;
 	INIT_LIST_HEAD(&vdev->resv_regions);
+	INIT_LIST_HEAD(&vdev->bonds);
 	dev_iommu_priv_set(dev, vdev);
 
 	if (viommu->probe_size) {
@@ -1755,6 +1778,175 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
 	return iommu_fwspec_add_ids(dev, args->args, 1);
 }
 
+static u32 viommu_sva_get_pasid(struct iommu_sva *handle)
+{
+	struct viommu_sva_bond *bond = sva_to_viommu_bond(handle);
+
+	return bond->mm->pasid;
+}
+
+static void viommu_mmu_notifier_free(struct mmu_notifier *mn)
+{
+	kfree(mn_to_pstiommu(mn));
+}
+
+static struct mmu_notifier_ops viommu_mmu_notifier_ops = {
+	.free_notifier		= viommu_mmu_notifier_free,
+};
+
+/* Allocate or get existing MMU notifier for this {domain, mm} pair */
+static struct iommu_psdtable_mmu_notifier *
+viommu_mmu_notifier_get(struct viommu_domain *vdomain, struct mm_struct *mm,
+			u32 asid_bits)
+{
+	int ret;
+	struct iommu_psdtable_mmu_notifier *viommu_mn;
+	struct iommu_pasid_table *tbl = vdomain->pasid_tbl;
+
+	list_for_each_entry(viommu_mn, &tbl->mmu_notifiers, list) {
+		if (viommu_mn->mn.mm == mm) {
+			refcount_inc(&viommu_mn->refs);
+			return viommu_mn;
+		}
+	}
+
+	mutex_lock(&viommu_asid_lock);
+	viommu_mn = iommu_psdtable_alloc_shared(tbl, mm, &viommu_asid_xa,
+						asid_bits);
+	mutex_unlock(&viommu_asid_lock);
+	if (IS_ERR(viommu_mn))
+		return ERR_CAST(viommu_mn);
+
+	refcount_set(&viommu_mn->refs, 1);
+	viommu_mn->cookie = vdomain;
+	viommu_mn->mn.ops = &viommu_mmu_notifier_ops;
+
+	ret = mmu_notifier_register(&viommu_mn->mn, mm);
+	if (ret)
+		goto err_free_cd;
+
+	ret = iommu_psdtable_write(tbl, &tbl->cfg, mm->pasid,
+				   viommu_mn->vendor.cd);
+	if (ret)
+		goto err_put_notifier;
+
+	list_add(&viommu_mn->list, &tbl->mmu_notifiers);
+	return viommu_mn;
+
+err_put_notifier:
+	/* Frees viommu_mn */
+	mmu_notifier_put(&viommu_mn->mn);
+err_free_cd:
+	iommu_psdtable_free_shared(tbl, &viommu_asid_xa, viommu_mn->vendor.cd);
+	return ERR_PTR(ret);
+}
+
+static void
+viommu_mmu_notifier_put(struct iommu_psdtable_mmu_notifier *viommu_mn)
+{
+	struct mm_struct *mm = viommu_mn->mn.mm;
+	struct viommu_domain *vdomain = viommu_mn->cookie;
+	struct iommu_pasid_table *tbl = vdomain->pasid_tbl;
+	u16 asid = viommu_mn->vendor.cd->asid;
+
+	if (!refcount_dec_and_test(&viommu_mn->refs))
+		return;
+
+	list_del(&viommu_mn->list);
+	iommu_psdtable_write(tbl, &tbl->cfg, mm->pasid, NULL);
+
+	/*
+	 * If we went through clear(), we've already invalidated, and no
+	 * new TLB entry can have been formed.
+	 */
+	if (!viommu_mn->cleared)
+		iommu_psdtable_flush_tlb(tbl, vdomain, asid);
+
+	/* Frees smmu_mn */
+	mmu_notifier_put(&viommu_mn->mn);
+	iommu_psdtable_free_shared(tbl, &viommu_asid_xa, viommu_mn->vendor.cd);
+}
+
+static struct iommu_sva *
+__viommu_sva_bind(struct device *dev, struct mm_struct *mm)
+{
+	int ret;
+	struct viommu_sva_bond *bond;
+	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+	struct viommu_domain *vdomain = to_viommu_domain(domain);
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+	struct virtio_iommu_probe_table_format *desc = vdev->pgtf;
+
+	if (!vdev || !vdev->sva_enabled)
+		return ERR_PTR(-ENODEV);
+
+	/* If bind() was already called for this {dev, mm} pair, reuse it. */
+	list_for_each_entry(bond, &vdev->bonds, list) {
+		if (bond->mm == mm) {
+			refcount_inc(&bond->refs);
+			return &bond->sva;
+		}
+	}
+
+	bond = kzalloc(sizeof(*bond), GFP_KERNEL);
+	if (!bond)
+		return ERR_PTR(-ENOMEM);
+
+	/* Allocate a PASID for this mm if necessary */
+	ret = iommu_sva_alloc_pasid(mm, 1, (1U << vdev->pasid_bits) - 1);
+	if (ret)
+		goto err_free_bond;
+
+	bond->mm = mm;
+	bond->sva.dev = dev;
+	refcount_set(&bond->refs, 1);
+
+	bond->viommu_mn = viommu_mmu_notifier_get(vdomain, mm, desc->asid_bits);
+	if (IS_ERR(bond->viommu_mn)) {
+		ret = PTR_ERR(bond->viommu_mn);
+		goto err_free_pasid;
+	}
+
+	list_add(&bond->list, &vdev->bonds);
+	return &bond->sva;
+
+err_free_pasid:
+	iommu_sva_free_pasid(mm);
+err_free_bond:
+	kfree(bond);
+	return ERR_PTR(ret);
+}
+
+/* closely follows arm_smmu_sva_bind() */
+static struct iommu_sva *viommu_sva_bind(struct device *dev,
+					 struct mm_struct *mm, void *drvdata)
+{
+	struct iommu_sva *handle;
+
+	mutex_lock(&sva_lock);
+	handle = __viommu_sva_bind(dev, mm);
+	mutex_unlock(&sva_lock);
+	return handle;
+}
+
+void viommu_sva_unbind(struct iommu_sva *handle)
+{
+	struct viommu_sva_bond *bond = sva_to_viommu_bond(handle);
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(handle->dev);
+
+	if (vdev->pri_supported)
+		iopf_queue_flush_dev(handle->dev);
+
+	mutex_lock(&sva_lock);
+	if (refcount_dec_and_test(&bond->refs)) {
+		list_del(&bond->list);
+		viommu_mmu_notifier_put(bond->viommu_mn);
+		iommu_sva_free_pasid(bond->mm);
+		kfree(bond);
+	}
+	mutex_unlock(&sva_lock);
+}
+
 static bool viommu_endpoint_iopf_supported(struct viommu_endpoint *vdev)
 {
 	/* TODO: support Stall model later */
@@ -1960,6 +2152,9 @@ static struct iommu_ops viommu_ops = {
 	.dev_feat_enabled	= viommu_dev_feature_enabled,
 	.dev_enable_feat	= viommu_dev_enable_feature,
 	.dev_disable_feat	= viommu_dev_disable_feature,
+	.sva_bind		= viommu_sva_bind,
+	.sva_unbind		= viommu_sva_unbind,
+	.sva_get_pasid		= viommu_sva_get_pasid,
 };
 
 static int viommu_init_vqs(struct viommu_dev *viommu)
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index 88a3db493108..c12d9b6a7243 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -122,6 +122,8 @@ struct virtio_iommu_req_attach_pst_arm {
 #define VIRTIO_IOMMU_PGTF_ARM_HPD0		(1ULL << 41)
 #define VIRTIO_IOMMU_PGTF_ARM_EPD1		(1 << 23)
 
+#define VIRTIO_IOMMU_PGTF_ARM_IPS_SHIFT		32
+#define VIRTIO_IOMMU_PGTF_ARM_IPS_MASK		0x7
 #define VIRTIO_IOMMU_PGTF_ARM_TG0_SHIFT		14
 #define VIRTIO_IOMMU_PGTF_ARM_TG0_MASK		0x3
 #define VIRTIO_IOMMU_PGTF_ARM_SH0_SHIFT		12
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:46 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:46 +0530
Subject: [PATCH RFC v1 10/11] uapi/virtio-iommu: Add a new request type to
 send page response
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-11-vivek.gautam@arm.com>

Once the page faults are handled, the response has to be sent to
virtio-iommu backend, from where it can be sent to the host to
prepare the response to a generated io page fault by the device.
Add a new virt-queue request type to handle this.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 include/uapi/linux/virtio_iommu.h | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index c12d9b6a7243..1b174b98663a 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -48,6 +48,7 @@ struct virtio_iommu_config {
 #define VIRTIO_IOMMU_T_PROBE			0x05
 #define VIRTIO_IOMMU_T_ATTACH_TABLE		0x06
 #define VIRTIO_IOMMU_T_INVALIDATE		0x07
+#define VIRTIO_IOMMU_T_PAGE_RESP		0x08
 
 /* Status types */
 #define VIRTIO_IOMMU_S_OK			0x00
@@ -70,6 +71,23 @@ struct virtio_iommu_req_tail {
 	__u8					reserved[3];
 };
 
+struct virtio_iommu_req_page_resp {
+	struct virtio_iommu_req_head		head;
+	__le32					domain;
+	__le32					endpoint;
+#define VIRTIO_IOMMU_PAGE_RESP_PASID_VALID	(1 << 0)
+	__le32					flags;
+	__le32					pasid;
+	__le32					grpid;
+#define VIRTIO_IOMMU_PAGE_RESP_SUCCESS		(0x0)
+#define VIRTIO_IOMMU_PAGE_RESP_INVALID		(0x1)
+#define VIRTIO_IOMMU_PAGE_RESP_FAILURE		(0x2)
+	__le16					resp_code;
+	__u8					pasid_valid;
+	__u8					reserved[9];
+	struct virtio_iommu_req_tail		tail;
+};
+
 struct virtio_iommu_req_attach {
 	struct virtio_iommu_req_head		head;
 	__le32					domain;
-- 
2.17.1



From vivek.gautam at arm.com  Fri Apr 23 10:51:47 2021
From: vivek.gautam at arm.com (Vivek Gautam)
Date: Fri, 23 Apr 2021 15:21:47 +0530
Subject: [PATCH RFC v1 11/11] iommu/virtio: Add support to send page response
In-Reply-To: <20210423095147.27922-1-vivek.gautam@arm.com>
References: <20210423095147.27922-1-vivek.gautam@arm.com>
Message-ID: <20210423095147.27922-12-vivek.gautam@arm.com>

Add page_response iommu ops callback to send page response to
the device that generated io page fault.

Signed-off-by: Vivek Gautam <vivek.gautam at arm.com>
---
 drivers/iommu/virtio-iommu.c | 47 ++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 08f1294baeab..6d62d9eae452 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1778,6 +1778,52 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
 	return iommu_fwspec_add_ids(dev, args->args, 1);
 }
 
+static int viommu_page_response(struct device *dev,
+				struct iommu_fault_event *evt,
+				struct iommu_page_response *resp)
+{
+	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+	struct viommu_domain *vdomain = to_viommu_domain(domain);
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+	struct viommu_endpoint *vdev = dev_iommu_priv_get(dev);
+	struct viommu_dev *viommu = vdev->viommu;
+	bool pasid_valid = resp->flags & IOMMU_PAGE_RESP_PASID_VALID;
+	struct virtio_iommu_req_page_resp req = {
+		.head.type	= VIRTIO_IOMMU_T_PAGE_RESP,
+		.domain		= cpu_to_le32(vdomain->id),
+		.endpoint	= cpu_to_le32(fwspec->ids[0]),
+	};
+
+	if (vdev->pri_supported) {
+		bool needs_pasid = (evt->fault.prm.flags &
+				    IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID);
+
+		req.pasid_valid	= needs_pasid && pasid_valid;
+		req.flags	= cpu_to_le32((needs_pasid && pasid_valid) ?
+				   VIRTIO_IOMMU_PAGE_RESP_PASID_VALID : 0);
+		req.pasid	= cpu_to_le32(resp->pasid);
+		req.grpid	= cpu_to_le32(resp->grpid);
+
+		switch (resp->code) {
+		case IOMMU_PAGE_RESP_FAILURE:
+			req.resp_code = cpu_to_le16(VIRTIO_IOMMU_PAGE_RESP_FAILURE);
+			break;
+		case IOMMU_PAGE_RESP_INVALID:
+			req.resp_code = cpu_to_le16(VIRTIO_IOMMU_PAGE_RESP_INVALID);
+			break;
+		case IOMMU_PAGE_RESP_SUCCESS:
+			req.resp_code = cpu_to_le16(VIRTIO_IOMMU_PAGE_RESP_SUCCESS);
+			break;
+		default:
+			return -EINVAL;
+		}
+	} else {
+		return -ENODEV;
+	}
+
+	return viommu_send_req_sync(viommu, &req, sizeof(req));
+}
+
 static u32 viommu_sva_get_pasid(struct iommu_sva *handle)
 {
 	struct viommu_sva_bond *bond = sva_to_viommu_bond(handle);
@@ -2155,6 +2201,7 @@ static struct iommu_ops viommu_ops = {
 	.sva_bind		= viommu_sva_bind,
 	.sva_unbind		= viommu_sva_unbind,
 	.sva_get_pasid		= viommu_sva_get_pasid,
+	.page_response		= viommu_page_response,
 };
 
 static int viommu_init_vqs(struct viommu_dev *viommu)
-- 
2.17.1



From gregkh at linuxfoundation.org  Fri Apr 23 11:02:15 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 23 Apr 2021 12:02:15 +0200
Subject: [PATCH v1] coresight: add node to reset all coresight devices
In-Reply-To: <1619166578-28690-1-git-send-email-taozha@codeaurora.org>
References: <1619166578-28690-1-git-send-email-taozha@codeaurora.org>
Message-ID: <YIKbJ/WafuFnqGvr@kroah.com>

On Fri, Apr 23, 2021 at 04:29:38PM +0800, Tao Zhang wrote:
> Add new reset_source_sink node to be able to disable all active
> coresight devices.
> In this way, we no longer need to manually disable all active
> coresight devices one by one. After enabling multiple coresight
> paths, users can reset their status more conveniently by this
> node.
> 
> This patch base on coresight-next repo
> http://git.linaro.org/kernel/coresight.git/log/?h=next
> 
> And this patch depends on the following patch
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg2551216.html
> 
> Signed-off-by: Tingwei Zhang <tingwei at codeaurora.org>
> Signed-off-by: Mao Jinlong <jinlmao at codeaurora.org>
> Signed-off-by: Tao Zhang <taozha at codeaurora.org>
> ---
>  drivers/hwtracing/coresight/coresight-core.c | 72 ++++++++++++++++++++++++----
>  1 file changed, 64 insertions(+), 8 deletions(-)

You added new sysfs files with no new Documentation/ABI entries, so we
have no idea how to review this code to determine if it does what you
want it to do :(

thanks,

greg k-h


From joe.burmeister at devtank.co.uk  Fri Apr 23 11:03:22 2021
From: joe.burmeister at devtank.co.uk (Joe Burmeister)
Date: Fri, 23 Apr 2021 11:03:22 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
 <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
Message-ID: <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>


On 23/04/2021 00:49, Florian Fainelli wrote:
> On 4/22/2021 1:10 PM, Joe Burmeister wrote:
>>> On 4/20/2021 1:34 AM, Joe Burmeister wrote:
>>>> It was previoulsy possible to have a device tree with more chips than
>>>> the driver supports and go off the end of CS arrays.
>>> Do you mind walking me through the code how that could have happened? 
We
>>> have spi_register_controller() call of_spi_get_gpio_numbers() which has
>>> the following:
>>>
>>> ctlr->num_chipselect = max_t(int, nb, ctlr->num_chipselect);
>>>
>>> such that what the controller has is the maximum between the number of
>>> 'cs-gpios' properties parsed and what was already populated in
>>> ctrl->num_chipselect during bcm2835_spi_probe(), which for this driver
>>> is BCM2835_SPI_NUM_CS (3).
>> If you make a initial device tree (or add overlay in the rpi's 
>> config.txt) with more on the bus than BCM2835_SPI_NUM_CS (in my case 8
>> devices), you get into this trampling memory state. As the devices are
>> added, once the chip_select is equal to or greater than
>> BCM2835_SPI_NUM_CS, it's writing off the end of the arrays.
> OK.
>
>> There is no protection from this happening. By the looks of it, this
>> isn't the only driver this could happen with, but it is the one I have
>> hardware for to test. There are also drivers that look like they don't
>> have a problem going well beyond the limit they gave.
> Right, which means that we should probably seek a solution within the
> SPI core itself, even if you can only test with spi-bcm2835.c chances
> are that the fix would be applicable for other controllers if done in
> the core.

I'm not sure it's possible to do in the core alone. The numb of the
issue is the core changes ctlr->num_chipselect to what is in the device
tree and some drivers are cool with that overs quietly stomp memory.

If we stop the core changing ctlr->num_chipselect then sod's law says
that we'd break existing devices which exceed the drivers num_chipselect
without a problem.

I've got a simple little patch to warn when the core expands
ctlr->num_chipselect. This warning won't go off in bcm2835 with my patch
because I am also extending ctlr->num_chipselect to the amount in the
device tree before the core does that expansion. Hopefully that new
warning would make people investigate and fix problem drivers.


>> There is protection in spi_add_device, which will catch extra added
>> later, but not ones in the device tree when the spi controller was
>> registered.
> Not sure I follow you, if we have the overlay before
> spi_register_controller() is called, how can the check there not
> trigger? And if we load the overlay later when the SPI controller is
> already registered, why does not spi_add_device()'s check work?

I think it might be a RPI thing. I think it is merging in the overlay
and giving Linux one already merged.


> How would I go about reproducing this on a Pi4?

Attached is a device tree overlay. If you compile that up and stick it
in /boot/overlays and add dtoverlay=rpi-bug to your config.txt, you can
get into this state.

If you do dtoverlay, you don't see anything, but if you do:

ls /dev/spi*

You can see all the spidev added by this are added. 2 of which go beyond
the drivers CS arrays.


>>>> This patches inforces CS limit but sets that limit to the max of the
>>>> default limit and what is in the device tree when driver is loaded.
>>>>
>>>> Signed-off-by: Joe Burmeister <joe.burmeister at devtank.co.uk>
>>> You have changed many more things that just enforcing a limit on
>>> BCM2835_SPI_NUM_CS you have now made all chip-select related data
>>> structuresd dynamically allocated and you have changed a number of
>>> prints to use the shorthand "dev" instead of &pdev->dev.
>> The change to dynamic allocated arrays is just to support what is given
>> in the device? tree rather than increase and enforce the CS limit 
just
>> for my case.
>>
>> The shorthand is of course not required. I'll drop it on resubmitting.
>>
>> Regards,
>>
>> Joe
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpi-bug-overlay.dts
Type: audio/vnd.dts
Size: 1856 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210423/fcb1f85b/attachment.dts>

From lkp at intel.com  Fri Apr 23 11:07:39 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 23 Apr 2021 18:07:39 +0800
Subject: [soc:arm/dt] BUILD SUCCESS
 3f9a3345a3a116af806064826d42cf5211dd611d
Message-ID: <60829c6b.ATwe5CwQinNVDddX%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: 3f9a3345a3a116af806064826d42cf5211dd611d  dt-bindings: mali-bifrost: add dma-coherent

elapsed time: 721m

configs tested: 128
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
riscv                            allyesconfig
i386                             allyesconfig
powerpc                 xes_mpc85xx_defconfig
mips                           mtx1_defconfig
sh                               allmodconfig
ia64                            zx1_defconfig
arm                          lpd270_defconfig
um                           x86_64_defconfig
sh                            titan_defconfig
powerpc                  storcenter_defconfig
powerpc                 mpc834x_mds_defconfig
nios2                            alldefconfig
mips                         bigsur_defconfig
arm                           h3600_defconfig
xtensa                  audio_kc705_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                      chrp32_defconfig
sh                          sdk7786_defconfig
arm                       cns3420vb_defconfig
um                               alldefconfig
arm                         bcm2835_defconfig
openrisc                            defconfig
sh                          r7785rp_defconfig
m68k                           sun3_defconfig
sh                        sh7785lcr_defconfig
sh                         microdev_defconfig
powerpc                 mpc832x_mds_defconfig
arm                       spear13xx_defconfig
ia64                             alldefconfig
xtensa                         virt_defconfig
openrisc                         alldefconfig
sh                          rsk7269_defconfig
powerpc                     powernv_defconfig
powerpc                   currituck_defconfig
ia64                      gensparse_defconfig
sh                           se7750_defconfig
powerpc                      arches_defconfig
sh                          lboxre2_defconfig
arm                       omap2plus_defconfig
powerpc                 mpc832x_rdb_defconfig
openrisc                    or1ksim_defconfig
powerpc                      walnut_defconfig
powerpc                     rainier_defconfig
arm                           stm32_defconfig
powerpc                     mpc83xx_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
x86_64               randconfig-a004-20210421
x86_64               randconfig-a002-20210421
x86_64               randconfig-a001-20210421
x86_64               randconfig-a005-20210421
x86_64               randconfig-a006-20210421
x86_64               randconfig-a003-20210421
i386                 randconfig-a005-20210423
i386                 randconfig-a002-20210423
i386                 randconfig-a001-20210423
i386                 randconfig-a006-20210423
i386                 randconfig-a004-20210423
i386                 randconfig-a003-20210423
i386                 randconfig-a012-20210421
i386                 randconfig-a014-20210421
i386                 randconfig-a011-20210421
i386                 randconfig-a013-20210421
i386                 randconfig-a015-20210421
i386                 randconfig-a016-20210421
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a015-20210421
x86_64               randconfig-a016-20210421
x86_64               randconfig-a011-20210421
x86_64               randconfig-a014-20210421
x86_64               randconfig-a013-20210421
x86_64               randconfig-a012-20210421
x86_64               randconfig-a015-20210423
x86_64               randconfig-a016-20210423
x86_64               randconfig-a011-20210423
x86_64               randconfig-a014-20210423
x86_64               randconfig-a012-20210423
x86_64               randconfig-a013-20210423

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr 23 11:07:41 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 23 Apr 2021 18:07:41 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS 450225a402e5b2b4c7ddef7ec54f797868d0f583
Message-ID: <60829c6d.C3LhCPuvhMRuwJDv%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: 450225a402e5b2b4c7ddef7ec54f797868d0f583  Merge tag 'sunxi-fixes-for-5.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes

elapsed time: 721m

configs tested: 156
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                       ebony_defconfig
powerpc                      cm5200_defconfig
um                             i386_defconfig
arm                      jornada720_defconfig
arm                              alldefconfig
um                           x86_64_defconfig
sh                            titan_defconfig
powerpc                  storcenter_defconfig
riscv                             allnoconfig
powerpc                 mpc834x_mds_defconfig
powerpc                      ep88xc_defconfig
arc                      axs103_smp_defconfig
powerpc                 linkstation_defconfig
arm                         s5pv210_defconfig
sparc                       sparc32_defconfig
sh                              ul2_defconfig
nios2                            alldefconfig
mips                         bigsur_defconfig
arm                           h3600_defconfig
xtensa                  audio_kc705_defconfig
sh                   rts7751r2dplus_defconfig
mips                        workpad_defconfig
arm                         socfpga_defconfig
powerpc                     asp8347_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc                     tqm8540_defconfig
arm                     eseries_pxa_defconfig
parisc                           alldefconfig
powerpc                      mgcoge_defconfig
mips                        omega2p_defconfig
arm                          exynos_defconfig
sh                           se7724_defconfig
arm                          pcm027_defconfig
sh                        apsh4ad0a_defconfig
arm                        magician_defconfig
ia64                            zx1_defconfig
mips                      maltasmvp_defconfig
arm                         bcm2835_defconfig
openrisc                            defconfig
sh                          r7785rp_defconfig
m68k                           sun3_defconfig
sh                        sh7785lcr_defconfig
arm                          lpd270_defconfig
arm                       imx_v4_v5_defconfig
sh                          r7780mp_defconfig
mips                     decstation_defconfig
powerpc                           allnoconfig
openrisc                  or1klitex_defconfig
mips                      pic32mzda_defconfig
nios2                            allyesconfig
mips                        maltaup_defconfig
mips                        vocore2_defconfig
h8300                       h8s-sim_defconfig
sparc                               defconfig
powerpc                     ep8248e_defconfig
mips                          rb532_defconfig
powerpc                     tqm8548_defconfig
powerpc                     mpc512x_defconfig
powerpc                      walnut_defconfig
powerpc                     rainier_defconfig
arm                           stm32_defconfig
powerpc                     mpc83xx_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
x86_64               randconfig-a004-20210421
x86_64               randconfig-a002-20210421
x86_64               randconfig-a001-20210421
x86_64               randconfig-a005-20210421
x86_64               randconfig-a006-20210421
x86_64               randconfig-a003-20210421
x86_64               randconfig-a002-20210423
x86_64               randconfig-a004-20210423
x86_64               randconfig-a001-20210423
x86_64               randconfig-a005-20210423
x86_64               randconfig-a006-20210423
x86_64               randconfig-a003-20210423
i386                 randconfig-a005-20210421
i386                 randconfig-a002-20210421
i386                 randconfig-a001-20210421
i386                 randconfig-a006-20210421
i386                 randconfig-a004-20210421
i386                 randconfig-a003-20210421
i386                 randconfig-a005-20210423
i386                 randconfig-a002-20210423
i386                 randconfig-a001-20210423
i386                 randconfig-a006-20210423
i386                 randconfig-a004-20210423
i386                 randconfig-a003-20210423
i386                 randconfig-a012-20210421
i386                 randconfig-a014-20210421
i386                 randconfig-a011-20210421
i386                 randconfig-a013-20210421
i386                 randconfig-a015-20210421
i386                 randconfig-a016-20210421
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a015-20210423
x86_64               randconfig-a016-20210423
x86_64               randconfig-a011-20210423
x86_64               randconfig-a014-20210423
x86_64               randconfig-a012-20210423
x86_64               randconfig-a013-20210423
x86_64               randconfig-a015-20210421
x86_64               randconfig-a016-20210421
x86_64               randconfig-a011-20210421
x86_64               randconfig-a014-20210421
x86_64               randconfig-a013-20210421
x86_64               randconfig-a012-20210421

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr 23 11:07:43 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 23 Apr 2021 18:07:43 +0800
Subject: [soc:for-next] BUILD SUCCESS 23b0b51551a75b334b4d4e38d9a6c2ff1ccef793
Message-ID: <60829c6f.QKJMJVB5I3BEqtxK%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: 23b0b51551a75b334b4d4e38d9a6c2ff1ccef793  soc: document merges

elapsed time: 721m

configs tested: 127
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
x86_64                           allyesconfig
riscv                            allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                 xes_mpc85xx_defconfig
mips                           mtx1_defconfig
sh                               allmodconfig
ia64                            zx1_defconfig
arm                          lpd270_defconfig
nios2                            alldefconfig
mips                         bigsur_defconfig
arm                           h3600_defconfig
xtensa                  audio_kc705_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                 mpc836x_rdk_defconfig
powerpc                      chrp32_defconfig
sh                          sdk7786_defconfig
arm                       cns3420vb_defconfig
um                               alldefconfig
arm                         bcm2835_defconfig
openrisc                            defconfig
sh                          r7785rp_defconfig
m68k                           sun3_defconfig
sh                        sh7785lcr_defconfig
sh                         microdev_defconfig
powerpc                 mpc832x_mds_defconfig
arm                       spear13xx_defconfig
ia64                             alldefconfig
xtensa                         virt_defconfig
openrisc                         alldefconfig
sh                          rsk7269_defconfig
powerpc                     powernv_defconfig
powerpc                   currituck_defconfig
ia64                      gensparse_defconfig
sh                           se7750_defconfig
powerpc                      arches_defconfig
sh                          lboxre2_defconfig
powerpc                      walnut_defconfig
powerpc                     rainier_defconfig
arm                           stm32_defconfig
powerpc                     mpc83xx_defconfig
arm                        trizeps4_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a005-20210421
i386                 randconfig-a002-20210421
i386                 randconfig-a001-20210421
i386                 randconfig-a006-20210421
i386                 randconfig-a004-20210421
i386                 randconfig-a003-20210421
i386                 randconfig-a005-20210423
i386                 randconfig-a002-20210423
i386                 randconfig-a001-20210423
i386                 randconfig-a006-20210423
i386                 randconfig-a004-20210423
i386                 randconfig-a003-20210423
i386                 randconfig-a012-20210421
i386                 randconfig-a014-20210421
i386                 randconfig-a011-20210421
i386                 randconfig-a013-20210421
i386                 randconfig-a015-20210421
i386                 randconfig-a016-20210421
x86_64               randconfig-a004-20210421
x86_64               randconfig-a002-20210421
x86_64               randconfig-a001-20210421
x86_64               randconfig-a005-20210421
x86_64               randconfig-a006-20210421
x86_64               randconfig-a003-20210421
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a015-20210421
x86_64               randconfig-a016-20210421
x86_64               randconfig-a011-20210421
x86_64               randconfig-a014-20210421
x86_64               randconfig-a013-20210421
x86_64               randconfig-a012-20210421
x86_64               randconfig-a015-20210423
x86_64               randconfig-a016-20210423
x86_64               randconfig-a011-20210423
x86_64               randconfig-a014-20210423
x86_64               randconfig-a012-20210423
x86_64               randconfig-a013-20210423

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From mirela.rabulea at oss.nxp.com  Fri Apr 23 11:13:28 2021
From: mirela.rabulea at oss.nxp.com (Mirela Rabulea (OSS))
Date: Fri, 23 Apr 2021 10:13:28 +0000
Subject: [PATCH v10] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes
In-Reply-To: <AM6PR04MB496668C16DBDC3D46A2A018080479@AM6PR04MB4966.eurprd04.prod.outlook.com>
References: <20210406172740.13904-1-mirela.rabulea@oss.nxp.com>
 <AM6PR04MB496668C16DBDC3D46A2A018080479@AM6PR04MB4966.eurprd04.prod.outlook.com>
Message-ID: <aaab2b5036e4fa217fb4e660884c85ecb580afc8.camel@oss.nxp.com>

Hi Aisheng,
thanks for feedback, responses below.

On Wed, 2021-04-21 at 10:12 +0000, Aisheng Dong wrote:
> + linux-arm-kernel at lists.infradead.org
> 
> > From: Mirela Rabulea (OSS) <mirela.rabulea at oss.nxp.com>
> > Sent: Wednesday, April 7, 2021 1:28 AM
> > 
> > Add dts for imaging subsytem, include jpeg nodes here.
> > Tested on imx8qxp only, should work on imx8qm, but it was not
> > tested.
> > 
> > Signed-off-by: Mirela Rabulea <mirela.rabulea at nxp.com>
> > ---
> > This was patch #7 in the initial patch set that added mxc-jpeg
> > driver
> > 
> > Changes in v10:
> >   Addressed feedback from Aisheng Dong:
> >     -Add jpeg clocks in the jpeg dts nodes.
> >     -Adapt to the recent split of the dts into subsystems:
> >      add the imaging subsystem, and place jpeg nodes there.
> > 
> >  .../arm64/boot/dts/freescale/imx8-ss-img.dtsi | 89
> > +++++++++++++++++++
> >  arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |  1 +
> >  2 files changed, 90 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> > new file mode 100644
> > index 000000000000..1457d219a658
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> > @@ -0,0 +1,89 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2019-2021 NXP
> > + * Zhou Guoniu <guoniu.zhou at nxp.com>
> > + */
> > +img_subsys: bus at 58000000 {
> > +	compatible = "simple-bus";
> > +	#address-cells = <1>;
> > +	#size-cells = <1>;
> > +	ranges = <0x58000000 0x0 0x58000000 0x1000000>;
> > +
> > +	img_ipg_clk: clock-img-ipg {
> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <200000000>;
> > +		clock-output-names = "img_ipg_clk";
> > +	};
> > +
> > +	img_jpeg_dec_clk: clock-controller at 585d0000 {
> 
> s/clk/lpcg

Channged in v11

> 
> > +		compatible = "fsl,imx8qxp-lpcg";
> > +		reg = <0x585d0000 0x10000>;
> > +		#clock-cells = <1>;
> > +		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
> > +		clock-indices = <IMX_LPCG_CLK_0>,
> > +				<IMX_LPCG_CLK_4>;
> > +		clock-output-names = "img_jpeg_dec_clk",
> > +				     "img_jpeg_dec_ipg_clk";
> > +		power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>;
> > +	};
> > +
> > +	img_jpeg_enc_clk: clock-controller at 585f0000 {
> 
> s/clk/lpcg

Channged in v11

> 
> > +		compatible = "fsl,imx8qxp-lpcg";
> > +		reg = <0x585f0000 0x10000>;
> > +		#clock-cells = <1>;
> > +		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
> > +		clock-indices = <IMX_LPCG_CLK_0>,
> > +				<IMX_LPCG_CLK_4>;
> > +		clock-output-names = "img_jpeg_enc_clk",
> > +				     "img_jpeg_enc_ipg_clk";
> > +		power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>;
> > +	};
> > +
> > +	cameradev: camera {
> 
> Is this node necessary?

Dropped in v11

> 
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		ranges;
> > +
> > +		jpegdec: jpegdec at 58400000 {
> > +			compatible = "nxp,imx8qxp-jpgdec";
> 
> Is this compatible string upstreamed already?

Yes, it's upstreamed.

> 
> > +			reg = <0x58400000 0x00050000 >;
> > +			interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
> > +			clocks = <&img_jpeg_dec_clk 0>,
> > +				 <&img_jpeg_dec_clk 1>;
> 
> Is the index correct here?

Yes, per is for the lower 16 bits (15:0) of LPCG_MJPEG_COMMON_DEC_REGS,
and ipg for the upper 16-bits (31:16) of LPCG_MJPEG_COMMON_DEC_REGS.
The IMX_LPCG_CLK_4 is 16.

> 
> > +			clock-names = "per", "ipg";
> > +			assigned-clocks = <&img_jpeg_dec_clk 0>,
> > +					  <&img_jpeg_dec_clk 1>;
> > +			assigned-clock-rates = <200000000>;
> 
> Mismatch with assigned-clocks

Aligned in v11.

> 
> > +			power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>,
> > +					<&pd IMX_SC_R_MJPEG_DEC_S0>,
> > +					<&pd IMX_SC_R_MJPEG_DEC_S1>,
> > +					<&pd IMX_SC_R_MJPEG_DEC_S2>,
> > +					<&pd IMX_SC_R_MJPEG_DEC_S3>;
> > +		};
> > +
> > +		jpegenc: jpegenc at 58450000 {
> > +			compatible = "nxp,imx8qxp-jpgenc";
> > +			reg = <0x58450000 0x00050000 >;
> > +			interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
> > +			clocks = <&img_jpeg_enc_clk 0>,
> > +				 <&img_jpeg_enc_clk 1>;
> 
> Ditto
> 
> > +			clock-names = "per", "ipg";
> > +			assigned-clocks = <&img_jpeg_enc_clk 0>,
> > +					  <&img_jpeg_enc_clk 1>;
> > +			assigned-clock-rates = <200000000>;
> 
> Ditto
> 
> > +			power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>,
> > +					<&pd IMX_SC_R_MJPEG_ENC_S0>,
> > +					<&pd IMX_SC_R_MJPEG_ENC_S1>,
> > +					<&pd IMX_SC_R_MJPEG_ENC_S2>,
> > +					<&pd IMX_SC_R_MJPEG_ENC_S3>;
> > +		};
> > +	};
> > +};
> 
> Regards
> Aisheng
> 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > index 1e6b4995091e..2d9589309bd0 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > @@ -258,6 +258,7 @@
> >  	};
> > 
> >  	/* sorted in register address */
> > +	#include "imx8-ss-img.dtsi"
> >  	#include "imx8-ss-adma.dtsi"
> >  	#include "imx8-ss-conn.dtsi"
> >  	#include "imx8-ss-ddr.dtsi"
> > --
> > 2.17.1
> 
> 

From mirela.rabulea at oss.nxp.com  Fri Apr 23 11:14:14 2021
From: mirela.rabulea at oss.nxp.com (Mirela Rabulea (OSS))
Date: Fri, 23 Apr 2021 13:14:14 +0300
Subject: [PATCH v11] arm64: dts: imx8qxp: Add jpeg encoder/decoder nodes
Message-ID: <20210423101414.20068-1-mirela.rabulea@oss.nxp.com>

From: Mirela Rabulea <mirela.rabulea at nxp.com>

Add dts for imaging subsytem, include jpeg nodes here.
Tested on imx8qxp only, should work on imx8qm, but it was not tested.

Signed-off-by: Mirela Rabulea <mirela.rabulea at nxp.com>
---
Changes in v11:
  Adress feedback from Aisheng Dong:
  - Rename img_jpeg_dec_clk/img_jpeg_enc_clk to jpeg_dec_lpcg/jpeg_enc_lpcg to make it visible it's lpcg not other type of clk
  - Drop the cameradev node, not needed for jpeg
  - Match assigned-clocks & assigned-clock-rates

 .../arm64/boot/dts/freescale/imx8-ss-img.dtsi | 82 +++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi    |  1 +
 2 files changed, 83 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi

diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
new file mode 100644
index 000000000000..c508e5d0c92b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 NXP
+ * Zhou Guoniu <guoniu.zhou at nxp.com>
+ */
+img_subsys: bus at 58000000 {
+	compatible = "simple-bus";
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges = <0x58000000 0x0 0x58000000 0x1000000>;
+
+	img_ipg_clk: clock-img-ipg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <200000000>;
+		clock-output-names = "img_ipg_clk";
+	};
+
+	img_jpeg_dec_lpcg: clock-controller at 585d0000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x585d0000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>,
+				<IMX_LPCG_CLK_4>;
+		clock-output-names = "img_jpeg_dec_lpcg_clk",
+				     "img_jpeg_dec_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>;
+	};
+
+	img_jpeg_enc_lpcg: clock-controller at 585f0000 {
+		compatible = "fsl,imx8qxp-lpcg";
+		reg = <0x585f0000 0x10000>;
+		#clock-cells = <1>;
+		clocks = <&img_ipg_clk>, <&img_ipg_clk>;
+		clock-indices = <IMX_LPCG_CLK_0>,
+				<IMX_LPCG_CLK_4>;
+		clock-output-names = "img_jpeg_enc_lpcg_clk",
+				     "img_jpeg_enc_lpcg_ipg_clk";
+		power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>;
+	};
+
+	jpegdec: jpegdec at 58400000 {
+		compatible = "nxp,imx8qxp-jpgdec";
+		reg = <0x58400000 0x00050000 >;
+		interrupts = <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&img_jpeg_dec_lpcg 0>,
+			 <&img_jpeg_dec_lpcg 1>;
+		clock-names = "per", "ipg";
+		assigned-clocks = <&img_jpeg_dec_lpcg 0>,
+				  <&img_jpeg_dec_lpcg 1>;
+		assigned-clock-rates = <200000000>, <200000000>;
+		power-domains = <&pd IMX_SC_R_MJPEG_DEC_MP>,
+				<&pd IMX_SC_R_MJPEG_DEC_S0>,
+				<&pd IMX_SC_R_MJPEG_DEC_S1>,
+				<&pd IMX_SC_R_MJPEG_DEC_S2>,
+				<&pd IMX_SC_R_MJPEG_DEC_S3>;
+	};
+
+	jpegenc: jpegenc at 58450000 {
+		compatible = "nxp,imx8qxp-jpgenc";
+		reg = <0x58450000 0x00050000 >;
+		interrupts = <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&img_jpeg_enc_lpcg 0>,
+			 <&img_jpeg_enc_lpcg 1>;
+		clock-names = "per", "ipg";
+		assigned-clocks = <&img_jpeg_enc_lpcg 0>,
+				  <&img_jpeg_enc_lpcg 1>;
+		assigned-clock-rates = <200000000>, <200000000>;
+		power-domains = <&pd IMX_SC_R_MJPEG_ENC_MP>,
+				<&pd IMX_SC_R_MJPEG_ENC_S0>,
+				<&pd IMX_SC_R_MJPEG_ENC_S1>,
+				<&pd IMX_SC_R_MJPEG_ENC_S2>,
+				<&pd IMX_SC_R_MJPEG_ENC_S3>;
+	};
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1e6b4995091e..2d9589309bd0 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -258,6 +258,7 @@
 	};
 
 	/* sorted in register address */
+	#include "imx8-ss-img.dtsi"
 	#include "imx8-ss-adma.dtsi"
 	#include "imx8-ss-conn.dtsi"
 	#include "imx8-ss-ddr.dtsi"
-- 
2.17.1



From krzysztof.kozlowski at canonical.com  Fri Apr 23 11:18:15 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Fri, 23 Apr 2021 12:18:15 +0200
Subject: [PATCH 2/2] memory: atmel-ebi: add missing of_node_put for loop
 iteration
In-Reply-To: <20210423101815.119341-1-krzysztof.kozlowski@canonical.com>
References: <20210423101815.119341-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210423101815.119341-2-krzysztof.kozlowski@canonical.com>

Early exits from for_each_available_child_of_node() should decrement the
node reference counter.  Reported by Coccinelle:

  drivers/memory/atmel-ebi.c:593:1-33: WARNING:
    Function "for_each_available_child_of_node" should have of_node_put() before return around line 604.

Fixes: 6a4ec4cd0888 ("memory: add Atmel EBI (External Bus Interface) driver")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/memory/atmel-ebi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c
index 14386d0b5f57..c267283b01fd 100644
--- a/drivers/memory/atmel-ebi.c
+++ b/drivers/memory/atmel-ebi.c
@@ -600,8 +600,10 @@ static int atmel_ebi_probe(struct platform_device *pdev)
 				child);
 
 			ret = atmel_ebi_dev_disable(ebi, child);
-			if (ret)
+			if (ret) {
+				of_node_put(child);
 				return ret;
+			}
 		}
 	}
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Fri Apr 23 11:18:14 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Fri, 23 Apr 2021 12:18:14 +0200
Subject: [PATCH 1/2] memory: stm32-fmc2-ebi: add missing of_node_put for loop
 iteration
Message-ID: <20210423101815.119341-1-krzysztof.kozlowski@canonical.com>

Early exits from for_each_available_child_of_node() should decrement the
node reference counter.  Reported by Coccinelle:

  drivers/memory/stm32-fmc2-ebi.c:1046:1-33: WARNING:
    Function "for_each_available_child_of_node" should have of_node_put() before return around line 1051.

Fixes: 66b8173a197f ("memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/memory/stm32-fmc2-ebi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
index 4d5758c419c5..ffec26a99313 100644
--- a/drivers/memory/stm32-fmc2-ebi.c
+++ b/drivers/memory/stm32-fmc2-ebi.c
@@ -1048,16 +1048,19 @@ static int stm32_fmc2_ebi_parse_dt(struct stm32_fmc2_ebi *ebi)
 		if (ret) {
 			dev_err(dev, "could not retrieve reg property: %d\n",
 				ret);
+			of_node_put(child);
 			return ret;
 		}
 
 		if (bank >= FMC2_MAX_BANKS) {
 			dev_err(dev, "invalid reg value: %d\n", bank);
+			of_node_put(child);
 			return -EINVAL;
 		}
 
 		if (ebi->bank_assigned & BIT(bank)) {
 			dev_err(dev, "bank already assigned: %d\n", bank);
+			of_node_put(child);
 			return -EINVAL;
 		}
 
@@ -1066,6 +1069,7 @@ static int stm32_fmc2_ebi_parse_dt(struct stm32_fmc2_ebi *ebi)
 			if (ret) {
 				dev_err(dev, "setup chip select %d failed: %d\n",
 					bank, ret);
+				of_node_put(child);
 				return ret;
 			}
 		}
-- 
2.25.1



From zhe.he at windriver.com  Fri Apr 23 11:35:31 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 23 Apr 2021 18:35:31 +0800
Subject: [PATCH v2 1/3] arm64: ptrace: Add is_syscall_success to handle compat
Message-ID: <20210423103533.30121-1-zhe.he@windriver.com>

The general version of is_syscall_success does not handle 32-bit
compatible case, which would cause 32-bit negative return code to be
recoganized as a positive number later and seen as a "success".

Since syscall_get_return_value is defined in syscall.h, implementing
is_syscall_success in ptrace.h would introduce build failure due to
recursive inclusion of some basic headers like mutex.h. Let's put the
implementation to ptrace.c

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
v1 to v2: Call syscall_get_return_value to reduce code duplication

 arch/arm64/include/asm/ptrace.h | 3 +++
 arch/arm64/kernel/ptrace.c      | 5 +++++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e58bca832dff..3c415e9e5d85 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -328,6 +328,9 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
 	regs->regs[0] = rc;
 }
 
+extern inline int is_syscall_success(struct pt_regs *regs);
+#define is_syscall_success(regs) is_syscall_success(regs)
+
 /**
  * regs_get_kernel_argument() - get Nth function argument in kernel
  * @regs:	pt_regs of that context
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 170f42fd6101..2c84255e1e41 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1909,3 +1909,8 @@ int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
 	else
 		return valid_native_regs(regs);
 }
+
+inline int is_syscall_success(struct pt_regs *regs)
+{
+	return !IS_ERR_VALUE(syscall_get_return_value(current, regs));
+}
-- 
2.17.1



From zhe.he at windriver.com  Fri Apr 23 11:35:32 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 23 Apr 2021 18:35:32 +0800
Subject: [PATCH v2 2/3] arm64: syscall.h: Add sign extension handling in
 syscall_get_return_value for compat
In-Reply-To: <20210423103533.30121-1-zhe.he@windriver.com>
References: <20210423103533.30121-1-zhe.he@windriver.com>
Message-ID: <20210423103533.30121-2-zhe.he@windriver.com>

Add sign extension handling in syscall_get_return_value so that it can
handle 32-bit compatible case and can be used by for example audit, just
like what syscall_get_error does.

Suggested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: He Zhe <zhe.he at windriver.com>
---
v1 to v2: Improve error code check suggested by Mark

 arch/arm64/include/asm/syscall.h | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index cfc0672013f6..c3b5fca82ff4 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -44,7 +44,20 @@ static inline long syscall_get_error(struct task_struct *task,
 static inline long syscall_get_return_value(struct task_struct *task,
 					    struct pt_regs *regs)
 {
-	return regs->regs[0];
+	long val = regs->regs[0];
+	long error = val;
+
+	if (compat_user_mode(regs))
+		error = sign_extend64(error, 31);
+
+	/*
+	 * Return codes with bit 31 set may or may not be an error code.
+	 * For example, mmap may return a legal 32 bit address with bit 31 set
+	 * for 32 bit thread, in which case the untouched val should be
+	 * returned. Otherwise, the sign-extended error should be returned if
+	 * it still falls in error number range.
+	 */
+	return IS_ERR_VALUE(error) ? error : val;
 }
 
 static inline void syscall_set_return_value(struct task_struct *task,
-- 
2.17.1



From zhe.he at windriver.com  Fri Apr 23 11:35:33 2021
From: zhe.he at windriver.com (He Zhe)
Date: Fri, 23 Apr 2021 18:35:33 +0800
Subject: [PATCH v2 3/3] audit: Use syscall_get_return_value to get syscall
 return code in audit_syscall_exit
In-Reply-To: <20210423103533.30121-1-zhe.he@windriver.com>
References: <20210423103533.30121-1-zhe.he@windriver.com>
Message-ID: <20210423103533.30121-3-zhe.he@windriver.com>

regs_return_value for some architectures like arm64 simply retrieve
register value from pt_regs without sign extension in 32-bit compatible
case and cause audit to have false syscall return code. For example,
32-bit -13 would be treated as 4294967283 below.

type=SYSCALL msg=audit(1611110715.887:582): arch=40000028 syscall=322
success=yes exit=4294967283

We just added proper sign extension in syscall_get_return_value which
should be used instead.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
v1 to v2: No change

 include/linux/audit.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/audit.h b/include/linux/audit.h
index 82b7c1116a85..135adbe22c19 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -334,7 +334,7 @@ static inline void audit_syscall_exit(void *pt_regs)
 {
 	if (unlikely(audit_context())) {
 		int success = is_syscall_success(pt_regs);
-		long return_code = regs_return_value(pt_regs);
+		long return_code = syscall_get_return_value(current, pt_regs);
 
 		__audit_syscall_exit(success, return_code);
 	}
-- 
2.17.1



From mark.rutland at arm.com  Fri Apr 23 11:50:51 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 23 Apr 2021 11:50:51 +0100
Subject: [PATCH v2] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <20210423083516.170111-1-heying24@huawei.com>
References: <20210423083516.170111-1-heying24@huawei.com>
Message-ID: <20210423105051.GA83097@C02TD0UTHF1T.local>

On Fri, Apr 23, 2021 at 04:35:16AM -0400, He Ying wrote:
> We found this problem in our kernel src tree:
> 
> [   14.816231] ------------[ cut here ]------------
> [   14.816231] kernel BUG at irq.c:99!
> [   14.816232] Internal error: Oops - BUG: 0 [#1] SMP
> [   14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____))
> [   14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O      4.19.95.aarch64 #14
> [   14.816233] Hardware name: evb (DT)
> [   14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO)
> [   14.816234] pc : asm_nmi_enter+0x94/0x98
> [   14.816235] lr : asm_nmi_enter+0x18/0x98
> [   14.816235] sp : ffff000008003c50
> [   14.816235] pmr_save: 00000070
> [   14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0
> [   14.816238] x27: 0000000000000000 x26: ffff000008004000
> [   14.816239] x25: 00000000015e0000 x24: ffff8008fb916000
> [   14.816240] x23: 0000000020400005 x22: ffff0000080817cc
> [   14.816241] x21: ffff000008003da0 x20: 0000000000000060
> [   14.816242] x19: 00000000000003ff x18: ffffffffffffffff
> [   14.816243] x17: 0000000000000008 x16: 003d090000000000
> [   14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40
> [   14.816244] x13: ffff8008fff58b9d x12: 0000000000000000
> [   14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5
> [   14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f
> [   14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e
> [   14.816248] x5 : 0000000000000000 x4 : 0000000080000000
> [   14.816249] x3 : 0000000000000000 x2 : 0000000080000000
> [   14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0
> [   14.816251] Call trace:
> [   14.816251]  asm_nmi_enter+0x94/0x98
> [   14.816251]  el1_irq+0x8c/0x180                    (IRQ C)
> [   14.816252]  gic_handle_irq+0xbc/0x2e4
> [   14.816252]  el1_irq+0xcc/0x180                    (IRQ B)
> [   14.816253]  arch_timer_handler_virt+0x38/0x58
> [   14.816253]  handle_percpu_devid_irq+0x90/0x240
> [   14.816253]  generic_handle_irq+0x34/0x50
> [   14.816254]  __handle_domain_irq+0x68/0xc0
> [   14.816254]  gic_handle_irq+0xf8/0x2e4
> [   14.816255]  el1_irq+0xcc/0x180                    (IRQ A)
> [   14.816255]  arch_cpu_idle+0x34/0x1c8
> [   14.816255]  default_idle_call+0x24/0x44
> [   14.816256]  do_idle+0x1d0/0x2c8
> [   14.816256]  cpu_startup_entry+0x28/0x30
> [   14.816256]  rest_init+0xb8/0xc8
> [   14.816257]  start_kernel+0x4c8/0x4f4
> [   14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000)
> [   14.816258] Modules linked in: start_dp(O) smeth(O)
> [   15.103092] ---[ end trace 701753956cb14aa8 ]---
> [   15.103093] Kernel panic - not syncing: Fatal exception in interrupt
> [   15.103099] SMP: stopping secondary CPUs
> [   15.103100] Kernel Offset: disabled
> [   15.103100] CPU features: 0x36,a2400218
> [   15.103100] Memory Limit: none
> 
> I look into this issue and find that it's caused by 'BUG_ON(in_nmi())'
> in nmi_enter(). From the call trace, we can find three interrupts which
> I mark as IRQ A, B and C. By adding some prints, I find the IRQ B also
> calls nmi_enter(), but its priority is not GICD_INT_NMI_PRI and its irq
> number is 1023. It enables irq by calling gic_arch_enable_irqs() in
> gic_handle_irq(). At this moment, IRQ C preempts the IRQ B and it's
> an NMI but current context is already in nmi. So that may be the problem.
> 
> When handling spurious interrupts, we shouldn't enable irqs. That's
> because for spurious interrupts we may enter nmi context in el1_irq()
> because current PMR may be GIC_PRIO_IRQOFF. If we enable irqs at this
> time, another NMI may happen and preempt this spurious interrupt
> but the context is already in nmi. That causes a bug on if nested NMI
> is not supported. Even for nested nmi, it's not a normal scenario.
> 
> Though the issue is reported on our private tree, I think it also
> exists on the latest tree for the reasons above. To fix this issue,
> check spurious interrupts right after the read of ICC_IAR1_EL1 and
> return directly for spurious interrupts.
> 
> Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
> Signed-off-by: He Ying <heying24 at huawei.com>

I'm reckon the fixes tag should probably be either:

Fixes: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs")

... or:

Fixes: 3f1f3234bc2db1c1 (" irqchip/gic-v3: Switch to PMR masking before calling IRQ handler")

... since the underlying issue is that gic_handle_irq() unmasks DAIF.I
and permits unintended nesting, even if that doesn't trigger a BUG() at
that point.

Otherwise, this makes sense to me:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
> 
> v2:
> - Move the check right after the read of ICC_IAR1_EL1 suggested by Marc.
> 
>  drivers/irqchip/irq-gic-v3.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 94b89258d045..37a23aa6de37 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -648,6 +648,10 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>  
>  	irqnr = gic_read_iar();
>  
> +	/* Check for special IDs first */
> +	if ((irqnr >= 1020 && irqnr <= 1023))
> +		return;
> +
>  	if (gic_supports_nmi() &&
>  	    unlikely(gic_read_rpr() == GICD_INT_NMI_PRI)) {
>  		gic_handle_nmi(irqnr, regs);
> @@ -659,10 +663,6 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>  		gic_arch_enable_irqs();
>  	}
>  
> -	/* Check for special IDs first */
> -	if ((irqnr >= 1020 && irqnr <= 1023))
> -		return;
> -
>  	if (static_branch_likely(&supports_deactivate_key))
>  		gic_write_eoir(irqnr);
>  	else
> -- 
> 2.17.1
> 


From maz at kernel.org  Fri Apr 23 12:35:44 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 23 Apr 2021 12:35:44 +0100
Subject: [GIT PULL] KVM/arm64 updates for 5.13
Message-ID: <20210423113544.1726204-1-maz@kernel.org>

Hi Paolo,

Here's the rather large pull request for 5.13. Changes are all over
the map, but the big ticket items are the S2 host isolation when
running in protected mode, the save/restore support for GICv4.1 and
guest SVE support in nVHE mode. Plenty of fixes too.

Note that this pull request drags a number of branches from other
trees in order to avoid conflicts and make people's life easier:

- the Coresight ETE/TRBE branch, as it is intertwined with the KVM
  tracing support

- the arm64 vhe-only branch that deals with broken CPUs such as the
  Apple M1

- the arm64 neon-softirqs-disabled that improves the support for
  FP processing

You will still get a couple of conflicts with the KVM tree, but these
are absolutely trivial to resolve.

Please pull,

	M.

The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:

  Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-5.13

for you to fetch changes up to 9a8aae605b80fc0a830cdce747eed48e11acc067:

  Merge branch 'kvm-arm64/kill_oprofile_dependency' into kvmarm-master/next (2021-04-22 13:41:49 +0100)

----------------------------------------------------------------
KVM/arm64 updates for Linux 5.13

New features:

- Stage-2 isolation for the host kernel when running in protected mode
- Guest SVE support when running in nVHE mode
- Force W^X hypervisor mappings in nVHE mode
- ITS save/restore for guests using direct injection with GICv4.1
- nVHE panics now produce readable backtraces
- Guest support for PTP using the ptp_kvm driver
- Performance improvements in the S2 fault handler
- Alexandru is now a reviewer (not really a new feature...)

Fixes:
- Proper emulation of the GICR_TYPER register
- Handle the complete set of relocation in the nVHE EL2 object
- Get rid of the oprofile dependency in the PMU code (and of the
  oprofile body parts at the same time)
- Debug and SPE fixes
- Fix vcpu reset

----------------------------------------------------------------
Alexandru Elisei (4):
      Documentation: KVM: Document KVM_GUESTDBG_USE_HW control flag for arm64
      KVM: arm64: Initialize VCPU mdcr_el2 before loading it
      KVM: arm64: Don't print warning when trapping SPE registers
      KVM: arm64: Don't advertise FEAT_SPE to guests

Andrew Scull (5):
      bug: Remove redundant condition check in report_bug
      bug: Factor out a getter for a bug's file line
      bug: Assign values once in bug_get_file_line()
      KVM: arm64: Use BUG and BUG_ON in nVHE hyp
      KVM: arm64: Log source when panicking from nVHE hyp

Anshuman Khandual (5):
      arm64: Add TRBE definitions
      coresight: core: Add support for dedicated percpu sinks
      coresight: sink: Add TRBE driver
      Documentation: coresight: trbe: Sysfs ABI description
      Documentation: trace: Add documentation for TRBE

Ard Biesheuvel (3):
      arm64: assembler: remove conditional NEON yield macros
      arm64: assembler: introduce wxN aliases for wN registers
      arm64: fpsimd: run kernel mode NEON with softirqs disabled

Daniel Kiss (1):
      KVM: arm64: Enable SVE support for nVHE

David Brazdil (1):
      KVM: arm64: Support PREL/PLT relocs in EL2 code

Eric Auger (11):
      KVM: arm64: vgic-v3: Fix some error codes when setting RDIST base
      KVM: arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION read
      KVM: arm64: vgic-v3: Fix error handling in vgic_v3_set_redist_base()
      KVM: arm/arm64: vgic: Reset base address on kvm_vgic_dist_destroy()
      docs: kvm: devices/arm-vgic-v3: enhance KVM_DEV_ARM_VGIC_CTRL_INIT doc
      KVM: arm64: Simplify argument passing to vgic_uaccess_[read|write]
      kvm: arm64: vgic-v3: Introduce vgic_v3_free_redist_region()
      KVM: arm64: vgic-v3: Expose GICR_TYPER.Last for userspace
      KVM: selftests: aarch64/vgic-v3 init sequence tests
      KVM: selftests: vgic_init kvm selftests fixup
      KVM: arm/arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST read

Gavin Shan (3):
      KVM: arm64: Hide kvm_mmu_wp_memory_region()
      KVM: arm64: Use find_vma_intersection()
      KVM: arm64: Don't retrieve memory slot again in page fault handler

Jianyong Wu (4):
      ptp: Reorganize ptp_kvm.c to make it arch-independent
      clocksource: Add clocksource id for arm arch counter
      KVM: arm64: Add support for the KVM PTP service
      ptp: arm/arm64: Enable ptp_kvm for arm/arm64

Jon Hunter (1):
      ptp: Don't print an error if ptp_kvm is not supported

Marc Zyngier (50):
      KVM: arm64: Provide KVM's own save/restore SVE primitives
      KVM: arm64: Use {read,write}_sysreg_el1 to access ZCR_EL1
      KVM: arm64: Let vcpu_sve_pffr() handle HYP VAs
      KVM: arm64: Introduce vcpu_sve_vq() helper
      arm64: sve: Provide a conditional update accessor for ZCR_ELx
      KVM: arm64: Rework SVE host-save/guest-restore
      KVM: arm64: Map SVE context at EL2 when available
      KVM: arm64: Save guest's ZCR_EL1 before saving the FPSIMD state
      KVM: arm64: Trap host SVE accesses when the FPSIMD state is dirty
      KVM: arm64: Save/restore SVE state for nVHE
      arm64: Use INIT_SCTLR_EL1_MMU_OFF to disable the MMU on CPU restart
      KVM: arm64: Use INIT_SCTLR_EL2_MMU_OFF to disable the MMU on KVM teardown
      KVM: arm64: Turn SCTLR_ELx_FLAGS into INIT_SCTLR_EL2_MMU_ON
      KVM: arm64: Force SCTLR_EL2.WXN when running nVHE
      KVM: arm64: Fix host's ZCR_EL2 restore on nVHE
      Merge tag 'v5.12-rc3' into kvm-arm64/host-stage2
      irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
      KVM: arm64: Generate final CTR_EL0 value when running in Protected mode
      KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
      KVM: arm64: Elect Alexandru as a replacement for Julien as a reviewer
      KVM: arm64: Mark the kvmarm ML as moderated for non-subscribers
      KVM: arm64: Fix table format for PTP documentation
      Merge remote-tracking branch 'coresight/next-ETE-TRBE' into kvmarm-master/next
      arm64: cpufeature: Allow early filtering of feature override
      arm64: Cope with CPUs stuck in VHE mode
      arm64: Get rid of CONFIG_ARM64_VHE
      KVM: arm64: Clarify vcpu reset behaviour
      KVM: arm64: Fully zero the vcpu state on reset
      Merge branch 'kvm-arm64/debug-5.13' into kvmarm-master/next
      Merge branch 'kvm-arm64/host-stage2' into kvmarm-master/next
      Merge branch 'kvm-arm64/memslot-fixes' into kvmarm-master/next
      Merge branch 'kvm-arm64/misc-5.13' into kvmarm-master/next
      Merge branch 'kvm-arm64/nvhe-panic-info' into kvmarm-master/next
      Merge branch 'kvm-arm64/nvhe-sve' into kvmarm-master/next
      Merge branch 'kvm-arm64/nvhe-wxn' into kvmarm-master/next
      Merge branch 'kvm-arm64/ptp' into kvmarm-master/next
      Merge branch 'kvm-arm64/vgic-5.13' into kvmarm-master/next
      Merge branch 'kvm-arm64/vlpi-save-restore' into kvmarm-master/next
      Merge remote-tracking branch 'arm64/for-next/vhe-only' into kvmarm-master/next
      Merge remote-tracking branch 'arm64/for-next/neon-softirqs-disabled' into kvmarm-master/next
      Merge remote-tracking branch 'coresight/next-ETE-TRBE' into kvmarm-master/next
      bug: Provide dummy version of bug_get_file_line() when !GENERIC_BUG
      Merge branch 'kvm-arm64/nvhe-panic-info' into kvmarm-master/next
      Merge branch 'kvm-arm64/ptp' into kvmarm-master/next
      KVM: arm64: Divorce the perf code from oprofile helpers
      arm64: Get rid of oprofile leftovers
      s390: Get rid of oprofile leftovers
      sh: Get rid of oprofile leftovers
      perf: Get rid of oprofile leftovers
      Merge branch 'kvm-arm64/kill_oprofile_dependency' into kvmarm-master/next

Quentin Perret (35):
      KVM: arm64: Initialize kvm_nvhe_init_params early
      KVM: arm64: Avoid free_page() in page-table allocator
      KVM: arm64: Factor memory allocation out of pgtable.c
      KVM: arm64: Introduce a BSS section for use at Hyp
      KVM: arm64: Make kvm_call_hyp() a function call at Hyp
      KVM: arm64: Allow using kvm_nvhe_sym() in hyp code
      KVM: arm64: Introduce an early Hyp page allocator
      KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp
      KVM: arm64: Introduce a Hyp buddy page allocator
      KVM: arm64: Enable access to sanitized CPU features at EL2
      KVM: arm64: Provide __flush_dcache_area at EL2
      KVM: arm64: Factor out vector address calculation
      arm64: asm: Provide set_sctlr_el2 macro
      KVM: arm64: Prepare the creation of s1 mappings at EL2
      KVM: arm64: Elevate hypervisor mappings creation at EL2
      KVM: arm64: Use kvm_arch for stage 2 pgtable
      KVM: arm64: Use kvm_arch in kvm_s2_mmu
      KVM: arm64: Set host stage 2 using kvm_nvhe_init_params
      KVM: arm64: Refactor kvm_arm_setup_stage2()
      KVM: arm64: Refactor __load_guest_stage2()
      KVM: arm64: Refactor __populate_fault_info()
      KVM: arm64: Make memcache anonymous in pgtable allocator
      KVM: arm64: Reserve memory for host stage 2
      KVM: arm64: Sort the hypervisor memblocks
      KVM: arm64: Always zero invalid PTEs
      KVM: arm64: Use page-table to track page ownership
      KVM: arm64: Refactor the *_map_set_prot_attr() helpers
      KVM: arm64: Add kvm_pgtable_stage2_find_range()
      KVM: arm64: Introduce KVM_PGTABLE_S2_NOFWB stage 2 flag
      KVM: arm64: Introduce KVM_PGTABLE_S2_IDMAP stage 2 flag
      KVM: arm64: Provide sanitized mmfr* registers at EL2
      KVM: arm64: Wrap the host with a stage 2
      KVM: arm64: Page-align the .hyp sections
      KVM: arm64: Disable PMU support in protected mode
      KVM: arm64: Protect the .hyp sections from the host

Shenming Lu (4):
      irqchip/gic-v3-its: Drop the setting of PTZ altogether
      KVM: arm64: GICv4.1: Add function to get VLPI state
      KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables
      KVM: arm64: GICv4.1: Give a chance to save VLPI state

Suzuki K Poulose (17):
      KVM: arm64: Hide system instruction access to Trace registers
      KVM: arm64: Disable guest access to trace filter controls
      perf: aux: Add flags for the buffer format
      perf: aux: Add CoreSight PMU buffer formats
      arm64: Add support for trace synchronization barrier
      KVM: arm64: Handle access to TRFCR_EL1
      KVM: arm64: Move SPE availability check to VCPU load
      arm64: KVM: Enable access to TRBE support for host
      coresight: etm4x: Move ETM to prohibited region for disable
      coresight: etm-perf: Allow an event to use different sinks
      coresight: Do not scan for graph if none is present
      coresight: etm4x: Add support for PE OS lock
      coresight: ete: Add support for ETE sysreg access
      coresight: ete: Add support for ETE tracing
      dts: bindings: Document device tree bindings for ETE
      coresight: etm-perf: Handle stale output handles
      dts: bindings: Document device tree bindings for Arm TRBE

Thomas Gleixner (1):
      time: Add mechanism to recognize clocksource in time_get_snapshot

Wang Wensheng (1):
      KVM: arm64: Fix error return code in init_hyp_mode()

Wei Yongjun (2):
      coresight: core: Make symbol 'csdev_sink' static
      coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()

Will Deacon (5):
      arm64: lib: Annotate {clear, copy}_page() as position-independent
      KVM: arm64: Link position-independent string routines into .hyp.text
      arm64: kvm: Add standalone ticket spinlock implementation for use at hyp
      arm/arm64: Probe for the presence of KVM hypervisor
      KVM: arm64: Advertise KVM UID to guests via SMCCC

Xiaofei Tan (1):
      arm64: sve: Provide sve_cond_update_zcr_vq fallback when !ARM64_SVE

Xu Jia (1):
      KVM: arm64: Make symbol '_kvm_host_prot_finalize' static

Zenghui Yu (2):
      KVM: arm64: GICv4.1: Restore VLPI pending state to physical side
      KVM: arm64: Fix Function ID typo for PTP_KVM service

 .../ABI/testing/sysfs-bus-coresight-devices-trbe   |   14 +
 Documentation/admin-guide/kernel-parameters.txt    |    3 +-
 Documentation/devicetree/bindings/arm/ete.yaml     |   75 ++
 Documentation/devicetree/bindings/arm/trbe.yaml    |   49 +
 Documentation/trace/coresight/coresight-trbe.rst   |   38 +
 Documentation/virt/kvm/api.rst                     |   25 +-
 Documentation/virt/kvm/arm/index.rst               |    1 +
 Documentation/virt/kvm/arm/ptp_kvm.rst             |   25 +
 Documentation/virt/kvm/devices/arm-vgic-its.rst    |    2 +-
 Documentation/virt/kvm/devices/arm-vgic-v3.rst     |    2 +-
 MAINTAINERS                                        |    6 +-
 arch/arm/include/asm/hypervisor.h                  |    3 +
 arch/arm64/Kconfig                                 |   20 -
 arch/arm64/crypto/aes-modes.S                      |    2 +-
 arch/arm64/crypto/sha1-ce-core.S                   |    2 +-
 arch/arm64/crypto/sha2-ce-core.S                   |    2 +-
 arch/arm64/crypto/sha3-ce-core.S                   |    4 +-
 arch/arm64/crypto/sha512-ce-core.S                 |    2 +-
 arch/arm64/include/asm/assembler.h                 |  129 +--
 arch/arm64/include/asm/barrier.h                   |    1 +
 arch/arm64/include/asm/cpufeature.h                |   17 +
 arch/arm64/include/asm/el2_setup.h                 |   13 +
 arch/arm64/include/asm/fpsimd.h                    |   11 +
 arch/arm64/include/asm/fpsimdmacros.h              |   10 +-
 arch/arm64/include/asm/hyp_image.h                 |    7 +
 arch/arm64/include/asm/hypervisor.h                |    3 +
 arch/arm64/include/asm/kvm_arm.h                   |    3 +
 arch/arm64/include/asm/kvm_asm.h                   |    9 +
 arch/arm64/include/asm/kvm_host.h                  |   46 +-
 arch/arm64/include/asm/kvm_hyp.h                   |   14 +-
 arch/arm64/include/asm/kvm_mmu.h                   |   25 +-
 arch/arm64/include/asm/kvm_pgtable.h               |  164 ++-
 arch/arm64/include/asm/pgtable-prot.h              |    4 +-
 arch/arm64/include/asm/sections.h                  |    1 +
 arch/arm64/include/asm/sysreg.h                    |   59 +-
 arch/arm64/kernel/asm-offsets.c                    |    5 +
 arch/arm64/kernel/cpu-reset.S                      |    5 +-
 arch/arm64/kernel/cpufeature.c                     |   11 +-
 arch/arm64/kernel/fpsimd.c                         |    4 +-
 arch/arm64/kernel/head.S                           |   39 +-
 arch/arm64/kernel/hyp-stub.S                       |   13 +-
 arch/arm64/kernel/idreg-override.c                 |   26 +-
 arch/arm64/kernel/image-vars.h                     |   34 +-
 arch/arm64/kernel/vmlinux.lds.S                    |   74 +-
 arch/arm64/kvm/arm.c                               |  216 +++-
 arch/arm64/kvm/debug.c                             |  116 +-
 arch/arm64/kvm/fpsimd.c                            |   26 +-
 arch/arm64/kvm/guest.c                             |    6 +-
 arch/arm64/kvm/handle_exit.c                       |   45 +
 arch/arm64/kvm/hyp/Makefile                        |    2 +-
 arch/arm64/kvm/hyp/fpsimd.S                        |   10 +
 arch/arm64/kvm/hyp/include/hyp/switch.h            |  107 +-
 arch/arm64/kvm/hyp/include/nvhe/early_alloc.h      |   14 +
 arch/arm64/kvm/hyp/include/nvhe/gfp.h              |   68 ++
 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h      |   36 +
 arch/arm64/kvm/hyp/include/nvhe/memory.h           |   51 +
 arch/arm64/kvm/hyp/include/nvhe/mm.h               |   96 ++
 arch/arm64/kvm/hyp/include/nvhe/spinlock.h         |   92 ++
 arch/arm64/kvm/hyp/nvhe/Makefile                   |    9 +-
 arch/arm64/kvm/hyp/nvhe/cache.S                    |   13 +
 arch/arm64/kvm/hyp/nvhe/debug-sr.c                 |   56 +-
 arch/arm64/kvm/hyp/nvhe/early_alloc.c              |   54 +
 arch/arm64/kvm/hyp/nvhe/gen-hyprel.c               |   18 +
 arch/arm64/kvm/hyp/nvhe/host.S                     |   18 +-
 arch/arm64/kvm/hyp/nvhe/hyp-init.S                 |   54 +-
 arch/arm64/kvm/hyp/nvhe/hyp-main.c                 |   75 +-
 arch/arm64/kvm/hyp/nvhe/hyp-smp.c                  |    6 +-
 arch/arm64/kvm/hyp/nvhe/hyp.lds.S                  |    1 +
 arch/arm64/kvm/hyp/nvhe/mem_protect.c              |  279 +++++
 arch/arm64/kvm/hyp/nvhe/mm.c                       |  173 +++
 arch/arm64/kvm/hyp/nvhe/page_alloc.c               |  195 ++++
 arch/arm64/kvm/hyp/nvhe/psci-relay.c               |    4 +-
 arch/arm64/kvm/hyp/nvhe/setup.c                    |  214 ++++
 arch/arm64/kvm/hyp/nvhe/stub.c                     |   22 +
 arch/arm64/kvm/hyp/nvhe/switch.c                   |   26 +-
 arch/arm64/kvm/hyp/nvhe/tlb.c                      |    4 +-
 arch/arm64/kvm/hyp/pgtable.c                       |  410 +++++--
 arch/arm64/kvm/hyp/reserved_mem.c                  |  113 ++
 arch/arm64/kvm/hyp/vhe/switch.c                    |    4 +-
 arch/arm64/kvm/hypercalls.c                        |   80 +-
 arch/arm64/kvm/mmu.c                               |  136 ++-
 arch/arm64/kvm/perf.c                              |    7 +-
 arch/arm64/kvm/pmu-emul.c                          |    2 +-
 arch/arm64/kvm/pmu.c                               |    8 +-
 arch/arm64/kvm/reset.c                             |   51 +-
 arch/arm64/kvm/sys_regs.c                          |   16 +
 arch/arm64/kvm/va_layout.c                         |    7 +
 arch/arm64/kvm/vgic/vgic-init.c                    |   12 +-
 arch/arm64/kvm/vgic/vgic-its.c                     |    6 +-
 arch/arm64/kvm/vgic/vgic-kvm-device.c              |    7 +-
 arch/arm64/kvm/vgic/vgic-mmio-v3.c                 |   81 +-
 arch/arm64/kvm/vgic/vgic-mmio.c                    |   10 +-
 arch/arm64/kvm/vgic/vgic-v3.c                      |   66 +-
 arch/arm64/kvm/vgic/vgic-v4.c                      |   38 +
 arch/arm64/kvm/vgic/vgic.h                         |    2 +
 arch/arm64/lib/clear_page.S                        |    4 +-
 arch/arm64/lib/copy_page.S                         |    4 +-
 arch/arm64/mm/init.c                               |    3 +
 arch/s390/kernel/perf_event.c                      |   21 -
 arch/sh/kernel/perf_event.c                        |   18 -
 drivers/clocksource/arm_arch_timer.c               |   36 +
 drivers/firmware/psci/psci.c                       |    2 +
 drivers/firmware/smccc/Makefile                    |    2 +-
 drivers/firmware/smccc/kvm_guest.c                 |   50 +
 drivers/firmware/smccc/smccc.c                     |    1 +
 drivers/hwtracing/coresight/Kconfig                |   24 +-
 drivers/hwtracing/coresight/Makefile               |    1 +
 drivers/hwtracing/coresight/coresight-core.c       |   29 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  119 +-
 drivers/hwtracing/coresight/coresight-etm4x-core.c |  161 ++-
 .../hwtracing/coresight/coresight-etm4x-sysfs.c    |   19 +-
 drivers/hwtracing/coresight/coresight-etm4x.h      |   83 +-
 drivers/hwtracing/coresight/coresight-platform.c   |    6 +
 drivers/hwtracing/coresight/coresight-priv.h       |    3 +
 drivers/hwtracing/coresight/coresight-trbe.c       | 1157 ++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-trbe.h       |  152 +++
 drivers/irqchip/irq-gic-v3-its.c                   |   18 +-
 drivers/perf/arm_pmu.c                             |   30 -
 drivers/ptp/Kconfig                                |    2 +-
 drivers/ptp/Makefile                               |    2 +
 drivers/ptp/ptp_kvm_arm.c                          |   28 +
 drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c}        |   85 +-
 drivers/ptp/ptp_kvm_x86.c                          |   97 ++
 include/kvm/arm_pmu.h                              |    4 +
 include/kvm/arm_vgic.h                             |    1 +
 include/linux/arm-smccc.h                          |   41 +
 include/linux/bug.h                                |   10 +
 include/linux/clocksource.h                        |    6 +
 include/linux/clocksource_ids.h                    |   12 +
 include/linux/coresight.h                          |   13 +
 include/linux/perf_event.h                         |    2 -
 include/linux/ptp_kvm.h                            |   19 +
 include/linux/timekeeping.h                        |   12 +-
 include/uapi/linux/kvm.h                           |    1 +
 include/uapi/linux/perf_event.h                    |   13 +-
 kernel/events/core.c                               |    5 -
 kernel/time/clocksource.c                          |    2 +
 kernel/time/timekeeping.c                          |    1 +
 lib/bug.c                                          |   54 +-
 tools/testing/selftests/kvm/.gitignore             |    1 +
 tools/testing/selftests/kvm/Makefile               |    1 +
 tools/testing/selftests/kvm/aarch64/vgic_init.c    |  551 ++++++++++
 tools/testing/selftests/kvm/include/kvm_util.h     |    9 +
 tools/testing/selftests/kvm/lib/kvm_util.c         |   75 ++
 144 files changed, 6298 insertions(+), 856 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
 create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
 create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
 create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
 create mode 100644 Documentation/virt/kvm/arm/ptp_kvm.rst
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/gfp.h
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/memory.h
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/mm.h
 create mode 100644 arch/arm64/kvm/hyp/include/nvhe/spinlock.h
 create mode 100644 arch/arm64/kvm/hyp/nvhe/cache.S
 create mode 100644 arch/arm64/kvm/hyp/nvhe/early_alloc.c
 create mode 100644 arch/arm64/kvm/hyp/nvhe/mem_protect.c
 create mode 100644 arch/arm64/kvm/hyp/nvhe/mm.c
 create mode 100644 arch/arm64/kvm/hyp/nvhe/page_alloc.c
 create mode 100644 arch/arm64/kvm/hyp/nvhe/setup.c
 create mode 100644 arch/arm64/kvm/hyp/nvhe/stub.c
 create mode 100644 arch/arm64/kvm/hyp/reserved_mem.c
 create mode 100644 drivers/firmware/smccc/kvm_guest.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
 create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
 create mode 100644 drivers/ptp/ptp_kvm_arm.c
 rename drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} (60%)
 create mode 100644 drivers/ptp/ptp_kvm_x86.c
 create mode 100644 include/linux/clocksource_ids.h
 create mode 100644 include/linux/ptp_kvm.h
 create mode 100644 tools/testing/selftests/kvm/aarch64/vgic_init.c


From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 12:38:59 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 12:38:59 +0100
Subject: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
Message-ID: <20210423113859.tdowrt5nx5bxb225@adrianlarumbe-HP-Elite-7500-Series-MT>

On 23.04.2021 11:17, Lars-Peter Clausen wrote:

> The device_config() and device_prep_slave_sg() APIs are meant for
> memory-to-device or device-to-memory transfers. This means the device address
> is fixed and usually maps to a FIFO in the device.
> 
> What you are implementing is memory-to-memory, which means addresses are
> incremented on both sides of transfer. And this works if you know what you are
> doing, e.g. you know that you are using a specific dmaengine driver that
> implements the dmaengine API in a way that does not comply with the
> specification. But it breaks for generic dmaengine API clients that expect
> compliant behavior. And it is the reason why we have an API in the first
> place, to get consistent behavior. If you have to know about the driver
> specific semantics you might as well just bypass the framework and use driver
> specific functions.

You're absolutely right about this. I think I might've been confused when
picking the right DMA Engine API callback to write this new functionality into
by the fact that, on our particular configuration, transfers were being done
between main system memory and DDR memory on a PCI card. However, from the point
of view of the semantics of the API, these are still memory-to-memory transfers,
just like you said.

> It seems to me what we are missing from the DMAengine API is the equivalent of
> device_prep_dma_memcpy() that is able to take SG lists. There is already a
> memset_sg, it should be possible to add something similar for memcpy.

I wasn't aware of the existence of this callback. Grepping the sources reveals a
single consumer at the moment, I guess this also might've led me to wrongly
conclude device_prep_slave_sg was the right choice. Perhaps I can convert most
of the code currently in xilinx_cdma_prep_slave_sg to fit the semantics of this
DMAengine API function instead. Any thoughts on this?

Cheers,
Adrian


From pbonzini at redhat.com  Fri Apr 23 12:42:17 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Fri, 23 Apr 2021 13:42:17 +0200
Subject: [GIT PULL] KVM/arm64 updates for 5.13
In-Reply-To: <20210423113544.1726204-1-maz@kernel.org>
References: <20210423113544.1726204-1-maz@kernel.org>
Message-ID: <04ffb298-430d-c1fe-b1cd-8670cac5e888@redhat.com>

On 23/04/21 13:35, Marc Zyngier wrote:
> Hi Paolo,
> 
> Here's the rather large pull request for 5.13. Changes are all over
> the map, but the big ticket items are the S2 host isolation when
> running in protected mode, the save/restore support for GICv4.1 and
> guest SVE support in nVHE mode. Plenty of fixes too.
> 
> Note that this pull request drags a number of branches from other
> trees in order to avoid conflicts and make people's life easier:
> 
> - the Coresight ETE/TRBE branch, as it is intertwined with the KVM
>    tracing support
> 
> - the arm64 vhe-only branch that deals with broken CPUs such as the
>    Apple M1
> 
> - the arm64 neon-softirqs-disabled that improves the support for
>    FP processing
> 
> You will still get a couple of conflicts with the KVM tree, but these
> are absolutely trivial to resolve.

Great, thanks.  I've pulled, it and will send the pull request to Linus 
around mid week to let these go in first.

Paolo

> Please pull,
> 
> 	M.
> 
> The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
> 
>    Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
> 
> are available in the Git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-5.13
> 
> for you to fetch changes up to 9a8aae605b80fc0a830cdce747eed48e11acc067:
> 
>    Merge branch 'kvm-arm64/kill_oprofile_dependency' into kvmarm-master/next (2021-04-22 13:41:49 +0100)
> 
> ----------------------------------------------------------------
> KVM/arm64 updates for Linux 5.13
> 
> New features:
> 
> - Stage-2 isolation for the host kernel when running in protected mode
> - Guest SVE support when running in nVHE mode
> - Force W^X hypervisor mappings in nVHE mode
> - ITS save/restore for guests using direct injection with GICv4.1
> - nVHE panics now produce readable backtraces
> - Guest support for PTP using the ptp_kvm driver
> - Performance improvements in the S2 fault handler
> - Alexandru is now a reviewer (not really a new feature...)
> 
> Fixes:
> - Proper emulation of the GICR_TYPER register
> - Handle the complete set of relocation in the nVHE EL2 object
> - Get rid of the oprofile dependency in the PMU code (and of the
>    oprofile body parts at the same time)
> - Debug and SPE fixes
> - Fix vcpu reset
> 
> ----------------------------------------------------------------
> Alexandru Elisei (4):
>        Documentation: KVM: Document KVM_GUESTDBG_USE_HW control flag for arm64
>        KVM: arm64: Initialize VCPU mdcr_el2 before loading it
>        KVM: arm64: Don't print warning when trapping SPE registers
>        KVM: arm64: Don't advertise FEAT_SPE to guests
> 
> Andrew Scull (5):
>        bug: Remove redundant condition check in report_bug
>        bug: Factor out a getter for a bug's file line
>        bug: Assign values once in bug_get_file_line()
>        KVM: arm64: Use BUG and BUG_ON in nVHE hyp
>        KVM: arm64: Log source when panicking from nVHE hyp
> 
> Anshuman Khandual (5):
>        arm64: Add TRBE definitions
>        coresight: core: Add support for dedicated percpu sinks
>        coresight: sink: Add TRBE driver
>        Documentation: coresight: trbe: Sysfs ABI description
>        Documentation: trace: Add documentation for TRBE
> 
> Ard Biesheuvel (3):
>        arm64: assembler: remove conditional NEON yield macros
>        arm64: assembler: introduce wxN aliases for wN registers
>        arm64: fpsimd: run kernel mode NEON with softirqs disabled
> 
> Daniel Kiss (1):
>        KVM: arm64: Enable SVE support for nVHE
> 
> David Brazdil (1):
>        KVM: arm64: Support PREL/PLT relocs in EL2 code
> 
> Eric Auger (11):
>        KVM: arm64: vgic-v3: Fix some error codes when setting RDIST base
>        KVM: arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION read
>        KVM: arm64: vgic-v3: Fix error handling in vgic_v3_set_redist_base()
>        KVM: arm/arm64: vgic: Reset base address on kvm_vgic_dist_destroy()
>        docs: kvm: devices/arm-vgic-v3: enhance KVM_DEV_ARM_VGIC_CTRL_INIT doc
>        KVM: arm64: Simplify argument passing to vgic_uaccess_[read|write]
>        kvm: arm64: vgic-v3: Introduce vgic_v3_free_redist_region()
>        KVM: arm64: vgic-v3: Expose GICR_TYPER.Last for userspace
>        KVM: selftests: aarch64/vgic-v3 init sequence tests
>        KVM: selftests: vgic_init kvm selftests fixup
>        KVM: arm/arm64: Fix KVM_VGIC_V3_ADDR_TYPE_REDIST read
> 
> Gavin Shan (3):
>        KVM: arm64: Hide kvm_mmu_wp_memory_region()
>        KVM: arm64: Use find_vma_intersection()
>        KVM: arm64: Don't retrieve memory slot again in page fault handler
> 
> Jianyong Wu (4):
>        ptp: Reorganize ptp_kvm.c to make it arch-independent
>        clocksource: Add clocksource id for arm arch counter
>        KVM: arm64: Add support for the KVM PTP service
>        ptp: arm/arm64: Enable ptp_kvm for arm/arm64
> 
> Jon Hunter (1):
>        ptp: Don't print an error if ptp_kvm is not supported
> 
> Marc Zyngier (50):
>        KVM: arm64: Provide KVM's own save/restore SVE primitives
>        KVM: arm64: Use {read,write}_sysreg_el1 to access ZCR_EL1
>        KVM: arm64: Let vcpu_sve_pffr() handle HYP VAs
>        KVM: arm64: Introduce vcpu_sve_vq() helper
>        arm64: sve: Provide a conditional update accessor for ZCR_ELx
>        KVM: arm64: Rework SVE host-save/guest-restore
>        KVM: arm64: Map SVE context at EL2 when available
>        KVM: arm64: Save guest's ZCR_EL1 before saving the FPSIMD state
>        KVM: arm64: Trap host SVE accesses when the FPSIMD state is dirty
>        KVM: arm64: Save/restore SVE state for nVHE
>        arm64: Use INIT_SCTLR_EL1_MMU_OFF to disable the MMU on CPU restart
>        KVM: arm64: Use INIT_SCTLR_EL2_MMU_OFF to disable the MMU on KVM teardown
>        KVM: arm64: Turn SCTLR_ELx_FLAGS into INIT_SCTLR_EL2_MMU_ON
>        KVM: arm64: Force SCTLR_EL2.WXN when running nVHE
>        KVM: arm64: Fix host's ZCR_EL2 restore on nVHE
>        Merge tag 'v5.12-rc3' into kvm-arm64/host-stage2
>        irqchip/gic-v3-its: Add a cache invalidation right after vPE unmapping
>        KVM: arm64: Generate final CTR_EL0 value when running in Protected mode
>        KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
>        KVM: arm64: Elect Alexandru as a replacement for Julien as a reviewer
>        KVM: arm64: Mark the kvmarm ML as moderated for non-subscribers
>        KVM: arm64: Fix table format for PTP documentation
>        Merge remote-tracking branch 'coresight/next-ETE-TRBE' into kvmarm-master/next
>        arm64: cpufeature: Allow early filtering of feature override
>        arm64: Cope with CPUs stuck in VHE mode
>        arm64: Get rid of CONFIG_ARM64_VHE
>        KVM: arm64: Clarify vcpu reset behaviour
>        KVM: arm64: Fully zero the vcpu state on reset
>        Merge branch 'kvm-arm64/debug-5.13' into kvmarm-master/next
>        Merge branch 'kvm-arm64/host-stage2' into kvmarm-master/next
>        Merge branch 'kvm-arm64/memslot-fixes' into kvmarm-master/next
>        Merge branch 'kvm-arm64/misc-5.13' into kvmarm-master/next
>        Merge branch 'kvm-arm64/nvhe-panic-info' into kvmarm-master/next
>        Merge branch 'kvm-arm64/nvhe-sve' into kvmarm-master/next
>        Merge branch 'kvm-arm64/nvhe-wxn' into kvmarm-master/next
>        Merge branch 'kvm-arm64/ptp' into kvmarm-master/next
>        Merge branch 'kvm-arm64/vgic-5.13' into kvmarm-master/next
>        Merge branch 'kvm-arm64/vlpi-save-restore' into kvmarm-master/next
>        Merge remote-tracking branch 'arm64/for-next/vhe-only' into kvmarm-master/next
>        Merge remote-tracking branch 'arm64/for-next/neon-softirqs-disabled' into kvmarm-master/next
>        Merge remote-tracking branch 'coresight/next-ETE-TRBE' into kvmarm-master/next
>        bug: Provide dummy version of bug_get_file_line() when !GENERIC_BUG
>        Merge branch 'kvm-arm64/nvhe-panic-info' into kvmarm-master/next
>        Merge branch 'kvm-arm64/ptp' into kvmarm-master/next
>        KVM: arm64: Divorce the perf code from oprofile helpers
>        arm64: Get rid of oprofile leftovers
>        s390: Get rid of oprofile leftovers
>        sh: Get rid of oprofile leftovers
>        perf: Get rid of oprofile leftovers
>        Merge branch 'kvm-arm64/kill_oprofile_dependency' into kvmarm-master/next
> 
> Quentin Perret (35):
>        KVM: arm64: Initialize kvm_nvhe_init_params early
>        KVM: arm64: Avoid free_page() in page-table allocator
>        KVM: arm64: Factor memory allocation out of pgtable.c
>        KVM: arm64: Introduce a BSS section for use at Hyp
>        KVM: arm64: Make kvm_call_hyp() a function call at Hyp
>        KVM: arm64: Allow using kvm_nvhe_sym() in hyp code
>        KVM: arm64: Introduce an early Hyp page allocator
>        KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp
>        KVM: arm64: Introduce a Hyp buddy page allocator
>        KVM: arm64: Enable access to sanitized CPU features at EL2
>        KVM: arm64: Provide __flush_dcache_area at EL2
>        KVM: arm64: Factor out vector address calculation
>        arm64: asm: Provide set_sctlr_el2 macro
>        KVM: arm64: Prepare the creation of s1 mappings at EL2
>        KVM: arm64: Elevate hypervisor mappings creation at EL2
>        KVM: arm64: Use kvm_arch for stage 2 pgtable
>        KVM: arm64: Use kvm_arch in kvm_s2_mmu
>        KVM: arm64: Set host stage 2 using kvm_nvhe_init_params
>        KVM: arm64: Refactor kvm_arm_setup_stage2()
>        KVM: arm64: Refactor __load_guest_stage2()
>        KVM: arm64: Refactor __populate_fault_info()
>        KVM: arm64: Make memcache anonymous in pgtable allocator
>        KVM: arm64: Reserve memory for host stage 2
>        KVM: arm64: Sort the hypervisor memblocks
>        KVM: arm64: Always zero invalid PTEs
>        KVM: arm64: Use page-table to track page ownership
>        KVM: arm64: Refactor the *_map_set_prot_attr() helpers
>        KVM: arm64: Add kvm_pgtable_stage2_find_range()
>        KVM: arm64: Introduce KVM_PGTABLE_S2_NOFWB stage 2 flag
>        KVM: arm64: Introduce KVM_PGTABLE_S2_IDMAP stage 2 flag
>        KVM: arm64: Provide sanitized mmfr* registers at EL2
>        KVM: arm64: Wrap the host with a stage 2
>        KVM: arm64: Page-align the .hyp sections
>        KVM: arm64: Disable PMU support in protected mode
>        KVM: arm64: Protect the .hyp sections from the host
> 
> Shenming Lu (4):
>        irqchip/gic-v3-its: Drop the setting of PTZ altogether
>        KVM: arm64: GICv4.1: Add function to get VLPI state
>        KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables
>        KVM: arm64: GICv4.1: Give a chance to save VLPI state
> 
> Suzuki K Poulose (17):
>        KVM: arm64: Hide system instruction access to Trace registers
>        KVM: arm64: Disable guest access to trace filter controls
>        perf: aux: Add flags for the buffer format
>        perf: aux: Add CoreSight PMU buffer formats
>        arm64: Add support for trace synchronization barrier
>        KVM: arm64: Handle access to TRFCR_EL1
>        KVM: arm64: Move SPE availability check to VCPU load
>        arm64: KVM: Enable access to TRBE support for host
>        coresight: etm4x: Move ETM to prohibited region for disable
>        coresight: etm-perf: Allow an event to use different sinks
>        coresight: Do not scan for graph if none is present
>        coresight: etm4x: Add support for PE OS lock
>        coresight: ete: Add support for ETE sysreg access
>        coresight: ete: Add support for ETE tracing
>        dts: bindings: Document device tree bindings for ETE
>        coresight: etm-perf: Handle stale output handles
>        dts: bindings: Document device tree bindings for Arm TRBE
> 
> Thomas Gleixner (1):
>        time: Add mechanism to recognize clocksource in time_get_snapshot
> 
> Wang Wensheng (1):
>        KVM: arm64: Fix error return code in init_hyp_mode()
> 
> Wei Yongjun (2):
>        coresight: core: Make symbol 'csdev_sink' static
>        coresight: trbe: Fix return value check in arm_trbe_register_coresight_cpu()
> 
> Will Deacon (5):
>        arm64: lib: Annotate {clear, copy}_page() as position-independent
>        KVM: arm64: Link position-independent string routines into .hyp.text
>        arm64: kvm: Add standalone ticket spinlock implementation for use at hyp
>        arm/arm64: Probe for the presence of KVM hypervisor
>        KVM: arm64: Advertise KVM UID to guests via SMCCC
> 
> Xiaofei Tan (1):
>        arm64: sve: Provide sve_cond_update_zcr_vq fallback when !ARM64_SVE
> 
> Xu Jia (1):
>        KVM: arm64: Make symbol '_kvm_host_prot_finalize' static
> 
> Zenghui Yu (2):
>        KVM: arm64: GICv4.1: Restore VLPI pending state to physical side
>        KVM: arm64: Fix Function ID typo for PTP_KVM service
> 
>   .../ABI/testing/sysfs-bus-coresight-devices-trbe   |   14 +
>   Documentation/admin-guide/kernel-parameters.txt    |    3 +-
>   Documentation/devicetree/bindings/arm/ete.yaml     |   75 ++
>   Documentation/devicetree/bindings/arm/trbe.yaml    |   49 +
>   Documentation/trace/coresight/coresight-trbe.rst   |   38 +
>   Documentation/virt/kvm/api.rst                     |   25 +-
>   Documentation/virt/kvm/arm/index.rst               |    1 +
>   Documentation/virt/kvm/arm/ptp_kvm.rst             |   25 +
>   Documentation/virt/kvm/devices/arm-vgic-its.rst    |    2 +-
>   Documentation/virt/kvm/devices/arm-vgic-v3.rst     |    2 +-
>   MAINTAINERS                                        |    6 +-
>   arch/arm/include/asm/hypervisor.h                  |    3 +
>   arch/arm64/Kconfig                                 |   20 -
>   arch/arm64/crypto/aes-modes.S                      |    2 +-
>   arch/arm64/crypto/sha1-ce-core.S                   |    2 +-
>   arch/arm64/crypto/sha2-ce-core.S                   |    2 +-
>   arch/arm64/crypto/sha3-ce-core.S                   |    4 +-
>   arch/arm64/crypto/sha512-ce-core.S                 |    2 +-
>   arch/arm64/include/asm/assembler.h                 |  129 +--
>   arch/arm64/include/asm/barrier.h                   |    1 +
>   arch/arm64/include/asm/cpufeature.h                |   17 +
>   arch/arm64/include/asm/el2_setup.h                 |   13 +
>   arch/arm64/include/asm/fpsimd.h                    |   11 +
>   arch/arm64/include/asm/fpsimdmacros.h              |   10 +-
>   arch/arm64/include/asm/hyp_image.h                 |    7 +
>   arch/arm64/include/asm/hypervisor.h                |    3 +
>   arch/arm64/include/asm/kvm_arm.h                   |    3 +
>   arch/arm64/include/asm/kvm_asm.h                   |    9 +
>   arch/arm64/include/asm/kvm_host.h                  |   46 +-
>   arch/arm64/include/asm/kvm_hyp.h                   |   14 +-
>   arch/arm64/include/asm/kvm_mmu.h                   |   25 +-
>   arch/arm64/include/asm/kvm_pgtable.h               |  164 ++-
>   arch/arm64/include/asm/pgtable-prot.h              |    4 +-
>   arch/arm64/include/asm/sections.h                  |    1 +
>   arch/arm64/include/asm/sysreg.h                    |   59 +-
>   arch/arm64/kernel/asm-offsets.c                    |    5 +
>   arch/arm64/kernel/cpu-reset.S                      |    5 +-
>   arch/arm64/kernel/cpufeature.c                     |   11 +-
>   arch/arm64/kernel/fpsimd.c                         |    4 +-
>   arch/arm64/kernel/head.S                           |   39 +-
>   arch/arm64/kernel/hyp-stub.S                       |   13 +-
>   arch/arm64/kernel/idreg-override.c                 |   26 +-
>   arch/arm64/kernel/image-vars.h                     |   34 +-
>   arch/arm64/kernel/vmlinux.lds.S                    |   74 +-
>   arch/arm64/kvm/arm.c                               |  216 +++-
>   arch/arm64/kvm/debug.c                             |  116 +-
>   arch/arm64/kvm/fpsimd.c                            |   26 +-
>   arch/arm64/kvm/guest.c                             |    6 +-
>   arch/arm64/kvm/handle_exit.c                       |   45 +
>   arch/arm64/kvm/hyp/Makefile                        |    2 +-
>   arch/arm64/kvm/hyp/fpsimd.S                        |   10 +
>   arch/arm64/kvm/hyp/include/hyp/switch.h            |  107 +-
>   arch/arm64/kvm/hyp/include/nvhe/early_alloc.h      |   14 +
>   arch/arm64/kvm/hyp/include/nvhe/gfp.h              |   68 ++
>   arch/arm64/kvm/hyp/include/nvhe/mem_protect.h      |   36 +
>   arch/arm64/kvm/hyp/include/nvhe/memory.h           |   51 +
>   arch/arm64/kvm/hyp/include/nvhe/mm.h               |   96 ++
>   arch/arm64/kvm/hyp/include/nvhe/spinlock.h         |   92 ++
>   arch/arm64/kvm/hyp/nvhe/Makefile                   |    9 +-
>   arch/arm64/kvm/hyp/nvhe/cache.S                    |   13 +
>   arch/arm64/kvm/hyp/nvhe/debug-sr.c                 |   56 +-
>   arch/arm64/kvm/hyp/nvhe/early_alloc.c              |   54 +
>   arch/arm64/kvm/hyp/nvhe/gen-hyprel.c               |   18 +
>   arch/arm64/kvm/hyp/nvhe/host.S                     |   18 +-
>   arch/arm64/kvm/hyp/nvhe/hyp-init.S                 |   54 +-
>   arch/arm64/kvm/hyp/nvhe/hyp-main.c                 |   75 +-
>   arch/arm64/kvm/hyp/nvhe/hyp-smp.c                  |    6 +-
>   arch/arm64/kvm/hyp/nvhe/hyp.lds.S                  |    1 +
>   arch/arm64/kvm/hyp/nvhe/mem_protect.c              |  279 +++++
>   arch/arm64/kvm/hyp/nvhe/mm.c                       |  173 +++
>   arch/arm64/kvm/hyp/nvhe/page_alloc.c               |  195 ++++
>   arch/arm64/kvm/hyp/nvhe/psci-relay.c               |    4 +-
>   arch/arm64/kvm/hyp/nvhe/setup.c                    |  214 ++++
>   arch/arm64/kvm/hyp/nvhe/stub.c                     |   22 +
>   arch/arm64/kvm/hyp/nvhe/switch.c                   |   26 +-
>   arch/arm64/kvm/hyp/nvhe/tlb.c                      |    4 +-
>   arch/arm64/kvm/hyp/pgtable.c                       |  410 +++++--
>   arch/arm64/kvm/hyp/reserved_mem.c                  |  113 ++
>   arch/arm64/kvm/hyp/vhe/switch.c                    |    4 +-
>   arch/arm64/kvm/hypercalls.c                        |   80 +-
>   arch/arm64/kvm/mmu.c                               |  136 ++-
>   arch/arm64/kvm/perf.c                              |    7 +-
>   arch/arm64/kvm/pmu-emul.c                          |    2 +-
>   arch/arm64/kvm/pmu.c                               |    8 +-
>   arch/arm64/kvm/reset.c                             |   51 +-
>   arch/arm64/kvm/sys_regs.c                          |   16 +
>   arch/arm64/kvm/va_layout.c                         |    7 +
>   arch/arm64/kvm/vgic/vgic-init.c                    |   12 +-
>   arch/arm64/kvm/vgic/vgic-its.c                     |    6 +-
>   arch/arm64/kvm/vgic/vgic-kvm-device.c              |    7 +-
>   arch/arm64/kvm/vgic/vgic-mmio-v3.c                 |   81 +-
>   arch/arm64/kvm/vgic/vgic-mmio.c                    |   10 +-
>   arch/arm64/kvm/vgic/vgic-v3.c                      |   66 +-
>   arch/arm64/kvm/vgic/vgic-v4.c                      |   38 +
>   arch/arm64/kvm/vgic/vgic.h                         |    2 +
>   arch/arm64/lib/clear_page.S                        |    4 +-
>   arch/arm64/lib/copy_page.S                         |    4 +-
>   arch/arm64/mm/init.c                               |    3 +
>   arch/s390/kernel/perf_event.c                      |   21 -
>   arch/sh/kernel/perf_event.c                        |   18 -
>   drivers/clocksource/arm_arch_timer.c               |   36 +
>   drivers/firmware/psci/psci.c                       |    2 +
>   drivers/firmware/smccc/Makefile                    |    2 +-
>   drivers/firmware/smccc/kvm_guest.c                 |   50 +
>   drivers/firmware/smccc/smccc.c                     |    1 +
>   drivers/hwtracing/coresight/Kconfig                |   24 +-
>   drivers/hwtracing/coresight/Makefile               |    1 +
>   drivers/hwtracing/coresight/coresight-core.c       |   29 +-
>   drivers/hwtracing/coresight/coresight-etm-perf.c   |  119 +-
>   drivers/hwtracing/coresight/coresight-etm4x-core.c |  161 ++-
>   .../hwtracing/coresight/coresight-etm4x-sysfs.c    |   19 +-
>   drivers/hwtracing/coresight/coresight-etm4x.h      |   83 +-
>   drivers/hwtracing/coresight/coresight-platform.c   |    6 +
>   drivers/hwtracing/coresight/coresight-priv.h       |    3 +
>   drivers/hwtracing/coresight/coresight-trbe.c       | 1157 ++++++++++++++++++++
>   drivers/hwtracing/coresight/coresight-trbe.h       |  152 +++
>   drivers/irqchip/irq-gic-v3-its.c                   |   18 +-
>   drivers/perf/arm_pmu.c                             |   30 -
>   drivers/ptp/Kconfig                                |    2 +-
>   drivers/ptp/Makefile                               |    2 +
>   drivers/ptp/ptp_kvm_arm.c                          |   28 +
>   drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c}        |   85 +-
>   drivers/ptp/ptp_kvm_x86.c                          |   97 ++
>   include/kvm/arm_pmu.h                              |    4 +
>   include/kvm/arm_vgic.h                             |    1 +
>   include/linux/arm-smccc.h                          |   41 +
>   include/linux/bug.h                                |   10 +
>   include/linux/clocksource.h                        |    6 +
>   include/linux/clocksource_ids.h                    |   12 +
>   include/linux/coresight.h                          |   13 +
>   include/linux/perf_event.h                         |    2 -
>   include/linux/ptp_kvm.h                            |   19 +
>   include/linux/timekeeping.h                        |   12 +-
>   include/uapi/linux/kvm.h                           |    1 +
>   include/uapi/linux/perf_event.h                    |   13 +-
>   kernel/events/core.c                               |    5 -
>   kernel/time/clocksource.c                          |    2 +
>   kernel/time/timekeeping.c                          |    1 +
>   lib/bug.c                                          |   54 +-
>   tools/testing/selftests/kvm/.gitignore             |    1 +
>   tools/testing/selftests/kvm/Makefile               |    1 +
>   tools/testing/selftests/kvm/aarch64/vgic_init.c    |  551 ++++++++++
>   tools/testing/selftests/kvm/include/kvm_util.h     |    9 +
>   tools/testing/selftests/kvm/lib/kvm_util.c         |   75 ++
>   144 files changed, 6298 insertions(+), 856 deletions(-)
>   create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe
>   create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
>   create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml
>   create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
>   create mode 100644 Documentation/virt/kvm/arm/ptp_kvm.rst
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/early_alloc.h
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/gfp.h
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/memory.h
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/mm.h
>   create mode 100644 arch/arm64/kvm/hyp/include/nvhe/spinlock.h
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/cache.S
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/early_alloc.c
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/mem_protect.c
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/mm.c
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/page_alloc.c
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/setup.c
>   create mode 100644 arch/arm64/kvm/hyp/nvhe/stub.c
>   create mode 100644 arch/arm64/kvm/hyp/reserved_mem.c
>   create mode 100644 drivers/firmware/smccc/kvm_guest.c
>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
>   create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
>   create mode 100644 drivers/ptp/ptp_kvm_arm.c
>   rename drivers/ptp/{ptp_kvm.c => ptp_kvm_common.c} (60%)
>   create mode 100644 drivers/ptp/ptp_kvm_x86.c
>   create mode 100644 include/linux/clocksource_ids.h
>   create mode 100644 include/linux/ptp_kvm.h
>   create mode 100644 tools/testing/selftests/kvm/aarch64/vgic_init.c
> 



From maz at kernel.org  Fri Apr 23 12:47:55 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 23 Apr 2021 12:47:55 +0100
Subject: [PATCH v2] irqchip/gic-v3: Do not enable irqs when handling
 spurious interrups
In-Reply-To: <20210423105051.GA83097@C02TD0UTHF1T.local>
References: <20210423083516.170111-1-heying24@huawei.com>
 <20210423105051.GA83097@C02TD0UTHF1T.local>
Message-ID: <87r1j1nrx0.wl-maz@kernel.org>

On Fri, 23 Apr 2021 11:50:51 +0100,
Mark Rutland <mark.rutland at arm.com> wrote:

[...]

> > Fixes: 17ce302f3117 ("arm64: Fix interrupt tracing in the presence of NMIs")
> > Signed-off-by: He Ying <heying24 at huawei.com>
> 
> I'm reckon the fixes tag should probably be either:
> 
> Fixes: f32c926651dcd168 ("irqchip/gic-v3: Handle pseudo-NMIs")
> 
> ... or:
> 
> Fixes: 3f1f3234bc2db1c1 (" irqchip/gic-v3: Switch to PMR masking before calling IRQ handler")
> 
> ... since the underlying issue is that gic_handle_irq() unmasks DAIF.I
> and permits unintended nesting, even if that doesn't trigger a BUG() at
> that point.

I used the latter (see 161917211934.29796.1841651233234902273.tip-bot2 at tip-bot2).

> Otherwise, this makes sense to me:
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>

I'll update the commit to reflect this.

Thanks.

	M.

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


From broonie at kernel.org  Fri Apr 23 12:47:35 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 12:47:35 +0100
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
In-Reply-To: <20210423034247.992052-1-art@khadas.com>
References: <20210423034247.992052-1-art@khadas.com>
Message-ID: <20210423114735.GA5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 11:42:47AM +0800, Artem Lapkin wrote:
> Problem: rmmod meson_gx_mmc - not stable without spi_master_suspend call
> and we can get stuck when try unload this module

> +++ b/drivers/spi/spi-meson-spifc.c
> @@ -359,6 +359,7 @@ static int meson_spifc_remove(struct platform_device *pdev)
>  	struct spi_master *master = platform_get_drvdata(pdev);
>  	struct meson_spifc *spifc = spi_master_get_devdata(master);
>  
> +	spi_master_suspend(master);
>  	pm_runtime_get_sync(&pdev->dev);
>  	clk_disable_unprepare(spifc->clk);
>  	pm_runtime_disable(&pdev->dev);

I would expect the driver to unregister the controller at the start of
the remove function, suspend doesn't really make sense 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/20210423/f4966c05/attachment.sig>

From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 12:49:47 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 12:49:47 +0100
Subject: [EXTERNAL] Re: [PATCH 4/4] dmaengine: xilinx_dma: Add device
 synchronisation callback
In-Reply-To: <4f286de6-ab91-ffd1-1119-cd94e5805aa9@metafoo.de>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <20210423011913.13122-5-adrian.martinezlarumbe@imgtec.com>
 <4f286de6-ab91-ffd1-1119-cd94e5805aa9@metafoo.de>
Message-ID: <20210423114947.v52rrqihpowdjitc@adrianlarumbe-HP-Elite-7500-Series-MT>


On 23.04.2021 08:33, Lars-Peter Clausen wrote:

> Hi,
> 
> 
> Patch looks good, but basically the same got already applied a few weeks ago.

I'll get rid of mine altogether in a later version.

Cheers,
Adrian


From jean-philippe at linaro.org  Fri Apr 23 12:38:31 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:31 +0200
Subject: [PATCH v2 0/6] Add support for ACPI VIOT
Message-ID: <20210423113836.3974972-1-jean-philippe@linaro.org>

Add a driver for the ACPI VIOT table, which provides topology
information for para-virtual platforms. Enable virtio-iommu on
non-devicetree platforms, including x86.

Since v1 [1]:
* The VIOT header definitions have been picked for v5.13
* Share more code with IORT. Patches 1 and 2 extract the common code
  from IORT.
* Simplify the VIOT driver. Use the existing fwnode infrastructure
  instead of adding hooks to the IOMMU driver.

You can find a QEMU implementation at [2], with extra support for
testing all VIOT nodes including MMIO-based endpoints and IOMMU. This
series, based on linux-next, is at [3]

[1] https://lore.kernel.org/linux-iommu/20210316191652.3401335-1-jean-philippe at linaro.org/
[2] https://jpbrucker.net/git/qemu/log/?h=virtio-iommu/acpi
[3] https://jpbrucker.net/git/linux/log/?h=virtio-iommu/acpi

Jean-Philippe Brucker (6):
  ACPI: arm64: Move DMA setup operations out of IORT
  ACPI: Move IOMMU setup code out of IORT
  ACPI: Add driver for the VIOT table
  iommu/dma: Pass address limit rather than size to
    iommu_setup_dma_ops()
  iommu/dma: Simplify calls to iommu_setup_dma_ops()
  iommu/virtio: Enable x86 support

 drivers/acpi/Kconfig         |   3 +
 drivers/iommu/Kconfig        |   4 +-
 drivers/acpi/Makefile        |   2 +
 drivers/acpi/arm64/Makefile  |   1 +
 include/acpi/acpi_bus.h      |   3 +
 include/linux/acpi.h         |   3 +
 include/linux/acpi_iort.h    |  14 +-
 include/linux/acpi_viot.h    |  19 ++
 include/linux/dma-iommu.h    |   4 +-
 arch/arm64/mm/dma-mapping.c  |   2 +-
 drivers/acpi/arm64/dma.c     |  50 +++++
 drivers/acpi/arm64/iort.c    | 129 ++-----------
 drivers/acpi/bus.c           |   2 +
 drivers/acpi/scan.c          |  60 +++++-
 drivers/acpi/viot.c          | 350 +++++++++++++++++++++++++++++++++++
 drivers/iommu/amd/iommu.c    |   9 +-
 drivers/iommu/dma-iommu.c    |  17 +-
 drivers/iommu/intel/iommu.c  |  10 +-
 drivers/iommu/virtio-iommu.c |   8 +
 MAINTAINERS                  |   8 +
 20 files changed, 548 insertions(+), 150 deletions(-)
 create mode 100644 include/linux/acpi_viot.h
 create mode 100644 drivers/acpi/arm64/dma.c
 create mode 100644 drivers/acpi/viot.c

-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:32 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:32 +0200
Subject: [PATCH v2 1/6] ACPI: arm64: Move DMA setup operations out of IORT
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-2-jean-philippe@linaro.org>

Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms that haven't run this code so far, if they have invalid
tables.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/acpi/arm64/Makefile |  1 +
 include/linux/acpi.h        |  3 +++
 include/linux/acpi_iort.h   |  6 ++---
 drivers/acpi/arm64/dma.c    | 50 ++++++++++++++++++++++++++++++++++
 drivers/acpi/arm64/iort.c   | 54 ++++++-------------------------------
 drivers/acpi/scan.c         |  2 +-
 6 files changed, 66 insertions(+), 50 deletions(-)
 create mode 100644 drivers/acpi/arm64/dma.c

diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 6ff50f4ed947..66acbe77f46e 100644
--- a/drivers/acpi/arm64/Makefile
+++ b/drivers/acpi/arm64/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_ACPI_IORT) 	+= iort.o
 obj-$(CONFIG_ACPI_GTDT) 	+= gtdt.o
+obj-y				+= dma.o
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index c60745f657e9..7aaa9559cc19 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -259,9 +259,12 @@ void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
 
 #ifdef CONFIG_ARM64
 void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
+void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size);
 #else
 static inline void
 acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
+static inline void
+acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size) { }
 #endif
 
 int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 1a12baa58e40..f7f054833afd 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -34,7 +34,7 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 id,
 void acpi_configure_pmsi_domain(struct device *dev);
 int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
 /* IOMMU interface */
-void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
+int iort_dma_get_ranges(struct device *dev, u64 *size);
 const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 						const u32 *id_in);
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
@@ -48,8 +48,8 @@ static inline struct irq_domain *iort_get_device_domain(
 { return NULL; }
 static inline void acpi_configure_pmsi_domain(struct device *dev) { }
 /* IOMMU interface */
-static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
-				  u64 *size) { }
+static inline int iort_dma_get_ranges(struct device *dev, u64 *size)
+{ return -ENODEV; }
 static inline const struct iommu_ops *iort_iommu_configure_id(
 				      struct device *dev, const u32 *id_in)
 { return NULL; }
diff --git a/drivers/acpi/arm64/dma.c b/drivers/acpi/arm64/dma.c
new file mode 100644
index 000000000000..f16739ad3cc0
--- /dev/null
+++ b/drivers/acpi/arm64/dma.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/acpi.h>
+#include <linux/acpi_iort.h>
+#include <linux/device.h>
+#include <linux/dma-direct.h>
+
+void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
+{
+	int ret;
+	u64 end, mask;
+	u64 dmaaddr = 0, size = 0, offset = 0;
+
+	/*
+	 * If @dev is expected to be DMA-capable then the bus code that created
+	 * it should have initialised its dma_mask pointer by this point. For
+	 * now, we'll continue the legacy behaviour of coercing it to the
+	 * coherent mask if not, but we'll no longer do so quietly.
+	 */
+	if (!dev->dma_mask) {
+		dev_warn(dev, "DMA mask not set\n");
+		dev->dma_mask = &dev->coherent_dma_mask;
+	}
+
+	if (dev->coherent_dma_mask)
+		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
+	else
+		size = 1ULL << 32;
+
+	ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
+	if (ret == -ENODEV)
+		ret = iort_dma_get_ranges(dev, &size);
+	if (!ret) {
+		/*
+		 * Limit coherent and dma mask based on size retrieved from
+		 * firmware.
+		 */
+		end = dmaaddr + size - 1;
+		mask = DMA_BIT_MASK(ilog2(end) + 1);
+		dev->bus_dma_limit = end;
+		dev->coherent_dma_mask = min(dev->coherent_dma_mask, mask);
+		*dev->dma_mask = min(*dev->dma_mask, mask);
+	}
+
+	*dma_addr = dmaaddr;
+	*dma_size = size;
+
+	ret = dma_direct_set_offset(dev, dmaaddr + offset, dmaaddr, size);
+
+	dev_dbg(dev, "dma_offset(%#08llx)%s\n", offset, ret ? " failed!" : "");
+}
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 3912a1f6058e..a940be1cf2af 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1144,56 +1144,18 @@ static int rc_dma_get_range(struct device *dev, u64 *size)
 }
 
 /**
- * iort_dma_setup() - Set-up device DMA parameters.
+ * iort_dma_get_ranges() - Look up DMA addressing limit for the device
+ * @dev: device to lookup
+ * @size: DMA range size result pointer
  *
- * @dev: device to configure
- * @dma_addr: device DMA address result pointer
- * @dma_size: DMA range size result pointer
+ * Return: 0 on success, an error otherwise.
  */
-void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
+int iort_dma_get_ranges(struct device *dev, u64 *size)
 {
-	u64 end, mask, dmaaddr = 0, size = 0, offset = 0;
-	int ret;
-
-	/*
-	 * If @dev is expected to be DMA-capable then the bus code that created
-	 * it should have initialised its dma_mask pointer by this point. For
-	 * now, we'll continue the legacy behaviour of coercing it to the
-	 * coherent mask if not, but we'll no longer do so quietly.
-	 */
-	if (!dev->dma_mask) {
-		dev_warn(dev, "DMA mask not set\n");
-		dev->dma_mask = &dev->coherent_dma_mask;
-	}
-
-	if (dev->coherent_dma_mask)
-		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
+	if (dev_is_pci(dev))
+		return rc_dma_get_range(dev, size);
 	else
-		size = 1ULL << 32;
-
-	ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
-	if (ret == -ENODEV)
-		ret = dev_is_pci(dev) ? rc_dma_get_range(dev, &size)
-				      : nc_dma_get_range(dev, &size);
-
-	if (!ret) {
-		/*
-		 * Limit coherent and dma mask based on size retrieved from
-		 * firmware.
-		 */
-		end = dmaaddr + size - 1;
-		mask = DMA_BIT_MASK(ilog2(end) + 1);
-		dev->bus_dma_limit = end;
-		dev->coherent_dma_mask = min(dev->coherent_dma_mask, mask);
-		*dev->dma_mask = min(*dev->dma_mask, mask);
-	}
-
-	*dma_addr = dmaaddr;
-	*dma_size = size;
-
-	ret = dma_direct_set_offset(dev, dmaaddr + offset, dmaaddr, size);
-
-	dev_dbg(dev, "dma_offset(%#08llx)%s\n", offset, ret ? " failed!" : "");
+		return nc_dma_get_range(dev, size);
 }
 
 static void __init acpi_iort_register_irq(int hwirq, const char *name,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index bc973fbd70b2..e166916eb9db 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1536,7 +1536,7 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
 		return 0;
 	}
 
-	iort_dma_setup(dev, &dma_addr, &size);
+	acpi_arch_dma_setup(dev, &dma_addr, &size);
 
 	iommu = iort_iommu_configure_id(dev, input_id);
 	if (PTR_ERR(iommu) == -EPROBE_DEFER)
-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:33 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:33 +0200
Subject: [PATCH v2 2/6] ACPI: Move IOMMU setup code out of IORT
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-3-jean-philippe@linaro.org>

Some of the IOMMU setup code in IORT is fairly generic and can be reused
by VIOT. Extract it from IORT.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 include/acpi/acpi_bus.h   |  3 ++
 include/linux/acpi_iort.h |  8 ++---
 drivers/acpi/arm64/iort.c | 75 +++++----------------------------------
 drivers/acpi/scan.c       | 55 +++++++++++++++++++++++++++-
 4 files changed, 69 insertions(+), 72 deletions(-)

diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 3a82faac5767..41f092a269f6 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -588,6 +588,9 @@ struct acpi_pci_root {
 
 bool acpi_dma_supported(struct acpi_device *adev);
 enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
+int acpi_iommu_fwspec_init(struct device *dev, u32 id,
+			   struct fwnode_handle *fwnode,
+			   const struct iommu_ops *ops);
 int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
 		       u64 *size);
 int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index f7f054833afd..f1f0842a2cb2 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -35,8 +35,7 @@ void acpi_configure_pmsi_domain(struct device *dev);
 int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
 /* IOMMU interface */
 int iort_dma_get_ranges(struct device *dev, u64 *size);
-const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
-						const u32 *id_in);
+int iort_iommu_configure_id(struct device *dev, const u32 *id_in);
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 phys_addr_t acpi_iort_dma_get_max_cpu_address(void);
 #else
@@ -50,9 +49,8 @@ static inline void acpi_configure_pmsi_domain(struct device *dev) { }
 /* IOMMU interface */
 static inline int iort_dma_get_ranges(struct device *dev, u64 *size)
 { return -ENODEV; }
-static inline const struct iommu_ops *iort_iommu_configure_id(
-				      struct device *dev, const u32 *id_in)
-{ return NULL; }
+static inline int iort_iommu_configure_id(struct device *dev, const u32 *id_in)
+{ return -ENODEV; }
 static inline
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 { return 0; }
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index a940be1cf2af..b5b021e064b6 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -806,23 +806,6 @@ static struct acpi_iort_node *iort_get_msi_resv_iommu(struct device *dev)
 	return NULL;
 }
 
-static inline const struct iommu_ops *iort_fwspec_iommu_ops(struct device *dev)
-{
-	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
-
-	return (fwspec && fwspec->ops) ? fwspec->ops : NULL;
-}
-
-static inline int iort_add_device_replay(struct device *dev)
-{
-	int err = 0;
-
-	if (dev->bus && !device_iommu_mapped(dev))
-		err = iommu_probe_device(dev);
-
-	return err;
-}
-
 /**
  * iort_iommu_msi_get_resv_regions - Reserved region driver helper
  * @dev: Device from iommu_get_resv_regions()
@@ -900,18 +883,6 @@ static inline bool iort_iommu_driver_enabled(u8 type)
 	}
 }
 
-static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
-			       struct fwnode_handle *fwnode,
-			       const struct iommu_ops *ops)
-{
-	int ret = iommu_fwspec_init(dev, fwnode, ops);
-
-	if (!ret)
-		ret = iommu_fwspec_add_ids(dev, &streamid, 1);
-
-	return ret;
-}
-
 static bool iort_pci_rc_supports_ats(struct acpi_iort_node *node)
 {
 	struct acpi_iort_root_complex *pci_rc;
@@ -946,7 +917,7 @@ static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
 		return iort_iommu_driver_enabled(node->type) ?
 		       -EPROBE_DEFER : -ENODEV;
 
-	return arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
+	return acpi_iommu_fwspec_init(dev, streamid, iort_fwnode, ops);
 }
 
 struct iort_pci_alias_info {
@@ -1020,24 +991,14 @@ static int iort_nc_iommu_map_id(struct device *dev,
  * @dev: device to configure
  * @id_in: optional input id const value pointer
  *
- * Returns: iommu_ops pointer on configuration success
- *          NULL on configuration failure
+ * Returns: 0 on success, <0 on failure
  */
-const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
-						const u32 *id_in)
+int iort_iommu_configure_id(struct device *dev, const u32 *id_in)
 {
 	struct acpi_iort_node *node;
-	const struct iommu_ops *ops;
+	const struct iommu_ops *ops = NULL;
 	int err = -ENODEV;
 
-	/*
-	 * If we already translated the fwspec there
-	 * is nothing left to do, return the iommu_ops.
-	 */
-	ops = iort_fwspec_iommu_ops(dev);
-	if (ops)
-		return ops;
-
 	if (dev_is_pci(dev)) {
 		struct iommu_fwspec *fwspec;
 		struct pci_bus *bus = to_pci_dev(dev)->bus;
@@ -1046,7 +1007,7 @@ const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 		node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
 				      iort_match_node_callback, &bus->dev);
 		if (!node)
-			return NULL;
+			return -ENODEV;
 
 		info.node = node;
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
@@ -1059,7 +1020,7 @@ const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 		node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
 				      iort_match_node_callback, dev);
 		if (!node)
-			return NULL;
+			return -ENODEV;
 
 		err = id_in ? iort_nc_iommu_map_id(dev, node, id_in) :
 			      iort_nc_iommu_map(dev, node);
@@ -1068,32 +1029,14 @@ const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
 			iort_named_component_init(dev, node);
 	}
 
-	/*
-	 * If we have reason to believe the IOMMU driver missed the initial
-	 * add_device callback for dev, replay it to get things in order.
-	 */
-	if (!err) {
-		ops = iort_fwspec_iommu_ops(dev);
-		err = iort_add_device_replay(dev);
-	}
-
-	/* Ignore all other errors apart from EPROBE_DEFER */
-	if (err == -EPROBE_DEFER) {
-		ops = ERR_PTR(err);
-	} else if (err) {
-		dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
-		ops = NULL;
-	}
-
-	return ops;
+	return err;
 }
 
 #else
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 { return 0; }
-const struct iommu_ops *iort_iommu_configure_id(struct device *dev,
-						const u32 *input_id)
-{ return NULL; }
+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)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index e166916eb9db..5924421075f6 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -9,6 +9,7 @@
 #include <linux/kernel.h>
 #include <linux/acpi.h>
 #include <linux/acpi_iort.h>
+#include <linux/iommu.h>
 #include <linux/signal.h>
 #include <linux/kthread.h>
 #include <linux/dmi.h>
@@ -1519,6 +1520,58 @@ int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
 	return ret >= 0 ? 0 : ret;
 }
 
+int acpi_iommu_fwspec_init(struct device *dev, u32 id,
+			   struct fwnode_handle *fwnode,
+			   const struct iommu_ops *ops)
+{
+	int ret = iommu_fwspec_init(dev, fwnode, ops);
+
+	if (!ret)
+		ret = iommu_fwspec_add_ids(dev, &id, 1);
+
+	return ret;
+}
+
+static inline const struct iommu_ops *acpi_iommu_fwspec_ops(struct device *dev)
+{
+	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+	return fwspec ? fwspec->ops : NULL;
+}
+
+static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
+						       const u32 *id_in)
+{
+	int err;
+	const struct iommu_ops *ops;
+
+	/*
+	 * If we already translated the fwspec there is nothing left to do,
+	 * return the iommu_ops.
+	 */
+	ops = acpi_iommu_fwspec_ops(dev);
+	if (ops)
+		return ops;
+
+	err = iort_iommu_configure_id(dev, id_in);
+
+	/*
+	 * If we have reason to believe the IOMMU driver missed the initial
+	 * add_device callback for dev, replay it to get things in order.
+	 */
+	if (!err && dev->bus && !device_iommu_mapped(dev))
+		err = iommu_probe_device(dev);
+
+	/* Ignore all other errors apart from EPROBE_DEFER */
+	if (err == -EPROBE_DEFER) {
+		return ERR_PTR(err);
+	} else if (err) {
+		dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
+		return NULL;
+	}
+	return acpi_iommu_fwspec_ops(dev);
+}
+
 /**
  * acpi_dma_configure_id - Set-up DMA configuration for the device.
  * @dev: The pointer to the device
@@ -1538,7 +1591,7 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
 
 	acpi_arch_dma_setup(dev, &dma_addr, &size);
 
-	iommu = iort_iommu_configure_id(dev, input_id);
+	iommu = acpi_iommu_configure_id(dev, input_id);
 	if (PTR_ERR(iommu) == -EPROBE_DEFER)
 		return -EPROBE_DEFER;
 
-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:36 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:36 +0200
Subject: [PATCH v2 5/6] iommu/dma: Simplify calls to iommu_setup_dma_ops()
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-6-jean-philippe@linaro.org>

dma-iommu uses the address bounds described in domain->geometry during
IOVA allocation. The address size parameters of iommu_setup_dma_ops()
are useful for describing additional limits set by the platform
firmware, but aren't needed for drivers that call this function from
probe_finalize(). The base parameter can be zero because dma-iommu
already removes the first IOVA page, and the limit parameter can be
U64_MAX because it's only checked against the domain geometry. Simplify
calls to iommu_setup_dma_ops().

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/iommu/amd/iommu.c   |  9 +--------
 drivers/iommu/dma-iommu.c   |  4 +++-
 drivers/iommu/intel/iommu.c | 10 +---------
 3 files changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 50041df43391..bbb09840cf40 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1708,14 +1708,7 @@ static struct iommu_device *amd_iommu_probe_device(struct device *dev)
 
 static void amd_iommu_probe_finalize(struct device *dev)
 {
-	struct iommu_domain *domain;
-
-	/* Domains are initialized for this device - have a look what we ended up with */
-	domain = iommu_get_domain_for_dev(dev);
-	if (domain->type == IOMMU_DOMAIN_DMA)
-		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
-	else
-		set_dma_ops(dev, NULL);
+	iommu_setup_dma_ops(dev, 0, U64_MAX);
 }
 
 static void amd_iommu_release_device(struct device *dev)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c62e19bed302..175f8eaeb5b3 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1322,7 +1322,9 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
 	if (domain->type == IOMMU_DOMAIN_DMA) {
 		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
 			goto out_err;
-		dev->dma_ops = &iommu_dma_ops;
+		set_dma_ops(dev, &iommu_dma_ops);
+	} else {
+		set_dma_ops(dev, NULL);
 	}
 
 	return;
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 39a4e672b1c2..c6fe11d3624e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5160,15 +5160,7 @@ static void intel_iommu_release_device(struct device *dev)
 
 static void intel_iommu_probe_finalize(struct device *dev)
 {
-	dma_addr_t base = IOVA_START_PFN << VTD_PAGE_SHIFT;
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-	struct dmar_domain *dmar_domain = to_dmar_domain(domain);
-
-	if (domain && domain->type == IOMMU_DOMAIN_DMA)
-		iommu_setup_dma_ops(dev, base,
-				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
-	else
-		set_dma_ops(dev, NULL);
+	iommu_setup_dma_ops(dev, 0, U64_MAX);
 }
 
 static void intel_iommu_get_resv_regions(struct device *device,
-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:37 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:37 +0200
Subject: [PATCH v2 6/6] iommu/virtio: Enable x86 support
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-7-jean-philippe@linaro.org>

With the VIOT support in place, x86 platforms can now use the
virtio-iommu.

Because the other x86 IOMMU drivers aren't yet ready to use the
acpi_dma_setup() path, x86 doesn't implement arch_setup_dma_ops() at the
moment. Similarly to Vt-d and AMD IOMMU, call iommu_setup_dma_ops() from
probe_finalize().

Acked-by: Joerg Roedel <jroedel at suse.de>
Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/iommu/Kconfig        | 3 ++-
 drivers/iommu/dma-iommu.c    | 1 +
 drivers/iommu/virtio-iommu.c | 8 ++++++++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index aff8a4830dd1..07b7c25cbed8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -400,8 +400,9 @@ config HYPERV_IOMMU
 config VIRTIO_IOMMU
 	tristate "Virtio IOMMU driver"
 	depends on VIRTIO
-	depends on ARM64
+	depends on (ARM64 || X86)
 	select IOMMU_API
+	select IOMMU_DMA
 	select INTERVAL_TREE
 	select ACPI_VIOT if ACPI
 	help
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 175f8eaeb5b3..46ed43c400cf 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1332,6 +1332,7 @@ 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/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 29a397c2d12f..8be546a338e7 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -1027,6 +1027,13 @@ 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
+	iommu_setup_dma_ops(dev, 0, U64_MAX);
+#endif
+}
+
 static void viommu_release_device(struct device *dev)
 {
 	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
@@ -1063,6 +1070,7 @@ static struct iommu_ops viommu_ops = {
 	.iova_to_phys		= viommu_iova_to_phys,
 	.iotlb_sync		= viommu_iotlb_sync,
 	.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,
-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:34 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:34 +0200
Subject: [PATCH v2 3/6] ACPI: Add driver for the VIOT table
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-4-jean-philippe@linaro.org>

The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.

Three steps are needed to configure DMA of endpoints:

(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
    associated to each vIOMMU device.

(2) When probing the vIOMMU device, the driver registers its IOMMU ops
    within the IOMMU subsystem. This step doesn't require any
    intervention from the VIOT driver.

(3) viot_iommu_configure(): before binding the endpoint to a driver,
    find the associated IOMMU ops. Register them, along with the
    endpoint ID, into the device's iommu_fwspec.

If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 drivers/acpi/Kconfig      |   3 +
 drivers/iommu/Kconfig     |   1 +
 drivers/acpi/Makefile     |   2 +
 include/linux/acpi_viot.h |  19 +++
 drivers/acpi/bus.c        |   2 +
 drivers/acpi/scan.c       |   3 +
 drivers/acpi/viot.c       | 350 ++++++++++++++++++++++++++++++++++++++
 MAINTAINERS               |   8 +
 8 files changed, 388 insertions(+)
 create mode 100644 include/linux/acpi_viot.h
 create mode 100644 drivers/acpi/viot.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index eedec61e3476..3758c6940ed7 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -526,6 +526,9 @@ endif
 
 source "drivers/acpi/pmic/Kconfig"
 
+config ACPI_VIOT
+	bool
+
 endif	# ACPI
 
 config X86_PM_TIMER
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 1f111b399bca..aff8a4830dd1 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -403,6 +403,7 @@ config VIRTIO_IOMMU
 	depends on ARM64
 	select IOMMU_API
 	select INTERVAL_TREE
+	select ACPI_VIOT if ACPI
 	help
 	  Para-virtualised IOMMU driver with virtio.
 
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 700b41adf2db..a6e644c48987 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -118,3 +118,5 @@ video-objs			+= acpi_video.o video_detect.o
 obj-y				+= dptf/
 
 obj-$(CONFIG_ARM64)		+= arm64/
+
+obj-$(CONFIG_ACPI_VIOT)		+= viot.o
diff --git a/include/linux/acpi_viot.h b/include/linux/acpi_viot.h
new file mode 100644
index 000000000000..1eb8ee5b0e5f
--- /dev/null
+++ b/include/linux/acpi_viot.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ACPI_VIOT_H__
+#define __ACPI_VIOT_H__
+
+#include <linux/acpi.h>
+
+#ifdef CONFIG_ACPI_VIOT
+void __init acpi_viot_init(void);
+int viot_iommu_configure(struct device *dev);
+#else
+static inline void acpi_viot_init(void) {}
+static inline int viot_iommu_configure(struct device *dev)
+{
+	return -ENODEV;
+}
+#endif
+
+#endif /* __ACPI_VIOT_H__ */
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index be7da23fad76..b835ca702ff0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -27,6 +27,7 @@
 #include <linux/dmi.h>
 #endif
 #include <linux/acpi_iort.h>
+#include <linux/acpi_viot.h>
 #include <linux/pci.h>
 #include <acpi/apei.h>
 #include <linux/suspend.h>
@@ -1339,6 +1340,7 @@ static int __init acpi_init(void)
 	pci_mmcfg_late_init();
 	acpi_iort_init();
 	acpi_scan_init();
+	acpi_viot_init();
 	acpi_ec_init();
 	acpi_debugfs_init();
 	acpi_sleep_proc_init();
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5924421075f6..4db43c822ee7 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -9,6 +9,7 @@
 #include <linux/kernel.h>
 #include <linux/acpi.h>
 #include <linux/acpi_iort.h>
+#include <linux/acpi_viot.h>
 #include <linux/iommu.h>
 #include <linux/signal.h>
 #include <linux/kthread.h>
@@ -1554,6 +1555,8 @@ static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
 		return ops;
 
 	err = iort_iommu_configure_id(dev, id_in);
+	if (err && err != -EPROBE_DEFER)
+		err = viot_iommu_configure(dev);
 
 	/*
 	 * If we have reason to believe the IOMMU driver missed the initial
diff --git a/drivers/acpi/viot.c b/drivers/acpi/viot.c
new file mode 100644
index 000000000000..710e5a5eac70
--- /dev/null
+++ b/drivers/acpi/viot.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Virtual I/O topology
+ */
+#define pr_fmt(fmt) "ACPI: VIOT: " fmt
+
+#include <linux/acpi_viot.h>
+#include <linux/dma-iommu.h>
+#include <linux/fwnode.h>
+#include <linux/iommu.h>
+#include <linux/list.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+struct viot_iommu {
+	/* Node offset within the table */
+	unsigned int			offset;
+	struct fwnode_handle		*fwnode;
+	struct list_head		list;
+};
+
+struct viot_endpoint {
+	union {
+		/* PCI range */
+		struct {
+			u16		segment_start;
+			u16		segment_end;
+			u16		bdf_start;
+			u16		bdf_end;
+		};
+		/* MMIO */
+		u64			address;
+	};
+	u32				endpoint_id;
+	struct viot_iommu		*viommu;
+	struct list_head		list;
+};
+
+static struct acpi_table_viot *viot;
+static LIST_HEAD(viot_iommus);
+static LIST_HEAD(viot_pci_ranges);
+static LIST_HEAD(viot_mmio_endpoints);
+
+static int __init viot_check_bounds(const struct acpi_viot_header *hdr)
+{
+	struct acpi_viot_header *start, *end, *hdr_end;
+
+	start = ACPI_ADD_PTR(struct acpi_viot_header, viot,
+			     max_t(size_t, sizeof(*viot), viot->node_offset));
+	end = ACPI_ADD_PTR(struct acpi_viot_header, viot, viot->header.length);
+	hdr_end = ACPI_ADD_PTR(struct acpi_viot_header, hdr, sizeof(*hdr));
+
+	if (hdr < start || hdr_end > end) {
+		pr_err(FW_BUG "Node pointer overflows\n");
+		return -EOVERFLOW;
+	}
+	if (hdr->length < sizeof(*hdr)) {
+		pr_err(FW_BUG "Empty node\n");
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int __init viot_get_pci_iommu_fwnode(struct viot_iommu *viommu,
+					    u16 segment, u16 bdf)
+{
+	struct pci_dev *pdev;
+	struct fwnode_handle *fwnode;
+
+	pdev = pci_get_domain_bus_and_slot(segment, PCI_BUS_NUM(bdf),
+					   bdf & 0xff);
+	if (!pdev) {
+		pr_err("Could not find PCI IOMMU\n");
+		return -ENODEV;
+	}
+
+	fwnode = pdev->dev.fwnode;
+	if (!fwnode) {
+		/*
+		 * PCI devices aren't necessarily described by ACPI. Create a
+		 * fwnode so the IOMMU subsystem can identify this device.
+		 */
+		fwnode = acpi_alloc_fwnode_static();
+		if (!fwnode) {
+			pci_dev_put(pdev);
+			return -ENOMEM;
+		}
+		set_primary_fwnode(&pdev->dev, fwnode);
+	}
+	viommu->fwnode = pdev->dev.fwnode;
+	pci_dev_put(pdev);
+	return 0;
+}
+
+static int __init viot_get_mmio_iommu_fwnode(struct viot_iommu *viommu,
+					     u64 address)
+{
+	struct acpi_device *adev;
+	struct resource res = {
+		.start	= address,
+		.end	= address,
+		.flags	= IORESOURCE_MEM,
+	};
+
+	adev = acpi_resource_consumer(&res);
+	if (!adev) {
+		pr_err("Could not find MMIO IOMMU\n");
+		return -EINVAL;
+	}
+	viommu->fwnode = &adev->fwnode;
+	return 0;
+}
+
+static struct viot_iommu * __init viot_get_iommu(unsigned int offset)
+{
+	int ret;
+	struct viot_iommu *viommu;
+	struct acpi_viot_header *hdr = ACPI_ADD_PTR(struct acpi_viot_header,
+						    viot, offset);
+	union {
+		struct acpi_viot_virtio_iommu_pci pci;
+		struct acpi_viot_virtio_iommu_mmio mmio;
+	} *node = (void *)hdr;
+
+	list_for_each_entry(viommu, &viot_iommus, list)
+		if (viommu->offset == offset)
+			return viommu;
+
+	if (viot_check_bounds(hdr))
+		return NULL;
+
+	viommu = kzalloc(sizeof(*viommu), GFP_KERNEL);
+	if (!viommu)
+		return NULL;
+
+	viommu->offset = offset;
+	switch (hdr->type) {
+	case ACPI_VIOT_NODE_VIRTIO_IOMMU_PCI:
+		if (hdr->length < sizeof(node->pci))
+			goto err_free;
+
+		ret = viot_get_pci_iommu_fwnode(viommu, node->pci.segment,
+						node->pci.bdf);
+		break;
+	case ACPI_VIOT_NODE_VIRTIO_IOMMU_MMIO:
+		if (hdr->length < sizeof(node->mmio))
+			goto err_free;
+
+		ret = viot_get_mmio_iommu_fwnode(viommu,
+						 node->mmio.base_address);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+	if (ret)
+		goto err_free;
+
+	list_add(&viommu->list, &viot_iommus);
+	return viommu;
+
+err_free:
+	kfree(viommu);
+	return NULL;
+}
+
+static int __init viot_parse_node(const struct acpi_viot_header *hdr)
+{
+	int ret = -EINVAL;
+	struct list_head *list;
+	struct viot_endpoint *ep;
+	union {
+		struct acpi_viot_mmio mmio;
+		struct acpi_viot_pci_range pci;
+	} *node = (void *)hdr;
+
+	if (viot_check_bounds(hdr))
+		return -EINVAL;
+
+	if (hdr->type == ACPI_VIOT_NODE_VIRTIO_IOMMU_PCI ||
+	    hdr->type == ACPI_VIOT_NODE_VIRTIO_IOMMU_MMIO)
+		return 0;
+
+	ep = kzalloc(sizeof(*ep), GFP_KERNEL);
+	if (!ep)
+		return -ENOMEM;
+
+	switch (hdr->type) {
+	case ACPI_VIOT_NODE_PCI_RANGE:
+		if (hdr->length < sizeof(node->pci)) {
+			pr_err(FW_BUG "Invalid PCI node size\n");
+			goto err_free;
+		}
+
+		ep->segment_start = node->pci.segment_start;
+		ep->segment_end = node->pci.segment_end;
+		ep->bdf_start = node->pci.bdf_start;
+		ep->bdf_end = node->pci.bdf_end;
+		ep->endpoint_id = node->pci.endpoint_start;
+		ep->viommu = viot_get_iommu(node->pci.output_node);
+		list = &viot_pci_ranges;
+		break;
+	case ACPI_VIOT_NODE_MMIO:
+		if (hdr->length < sizeof(node->mmio)) {
+			pr_err(FW_BUG "Invalid MMIO node size\n");
+			goto err_free;
+		}
+
+		ep->address = node->mmio.base_address;
+		ep->endpoint_id = node->mmio.endpoint;
+		ep->viommu = viot_get_iommu(node->mmio.output_node);
+		list = &viot_mmio_endpoints;
+		break;
+	default:
+		pr_warn("Unsupported node %x\n", hdr->type);
+		ret = 0;
+		goto err_free;
+	}
+
+	/*
+	 * To be compatible with future versions of the table which may include
+	 * other node types, keep parsing.
+	 */
+	if (!ep->viommu) {
+		pr_warn("No IOMMU node found\n");
+		ret = 0;
+		goto err_free;
+	}
+
+	list_add(&ep->list, list);
+	return 0;
+
+err_free:
+	kfree(ep);
+	return ret;
+}
+
+/**
+ * acpi_viot_init - Parse the VIOT table
+ *
+ * Parse the VIOT table, prepare the list of endpoints to be used during DMA
+ * setup of devices.
+ */
+void __init acpi_viot_init(void)
+{
+	int i;
+	acpi_status status;
+	struct acpi_table_header *hdr;
+	struct acpi_viot_header *node;
+
+	status = acpi_get_table(ACPI_SIG_VIOT, 0, &hdr);
+	if (ACPI_FAILURE(status)) {
+		if (status != AE_NOT_FOUND) {
+			const char *msg = acpi_format_exception(status);
+
+			pr_err("Failed to get table, %s\n", msg);
+		}
+		return;
+	}
+
+	viot = (void *)hdr;
+
+	node = ACPI_ADD_PTR(struct acpi_viot_header, viot, viot->node_offset);
+	for (i = 0; i < viot->node_count; i++) {
+		if (viot_parse_node(node))
+			return;
+
+		node = ACPI_ADD_PTR(struct acpi_viot_header, node,
+				    node->length);
+	}
+}
+
+static int viot_dev_iommu_init(struct device *dev, struct viot_iommu *viommu,
+			       u32 epid)
+{
+	const struct iommu_ops *ops;
+
+	if (!viommu)
+		return -ENODEV;
+
+	/* We're not translating ourself */
+	if (viommu->fwnode == dev->fwnode)
+		return -EINVAL;
+
+	ops = iommu_ops_from_fwnode(viommu->fwnode);
+	if (!ops)
+		return IS_ENABLED(CONFIG_VIRTIO_IOMMU) ?
+			-EPROBE_DEFER : -ENODEV;
+
+	return acpi_iommu_fwspec_init(dev, epid, viommu->fwnode, ops);
+}
+
+static int viot_pci_dev_iommu_init(struct pci_dev *pdev, u16 dev_id, void *data)
+{
+	u32 epid;
+	struct viot_endpoint *ep;
+	u32 domain_nr = pci_domain_nr(pdev->bus);
+
+	list_for_each_entry(ep, &viot_pci_ranges, list) {
+		if (domain_nr >= ep->segment_start &&
+		    domain_nr <= ep->segment_end &&
+		    dev_id >= ep->bdf_start &&
+		    dev_id <= ep->bdf_end) {
+			epid = ((domain_nr - ep->segment_start) << 16) +
+				dev_id - ep->bdf_start + ep->endpoint_id;
+
+			/*
+			 * If we found a PCI range managed by the viommu, we're
+			 * the one that has to request ACS.
+			 */
+			pci_request_acs();
+
+			return viot_dev_iommu_init(&pdev->dev, ep->viommu,
+						   epid);
+		}
+	}
+	return -ENODEV;
+}
+
+static int viot_mmio_dev_iommu_init(struct platform_device *pdev)
+{
+	struct resource *mem;
+	struct viot_endpoint *ep;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!mem)
+		return -ENODEV;
+
+	list_for_each_entry(ep, &viot_mmio_endpoints, list) {
+		if (ep->address == mem->start)
+			return viot_dev_iommu_init(&pdev->dev, ep->viommu,
+						   ep->endpoint_id);
+	}
+	return -ENODEV;
+}
+
+/**
+ * viot_iommu_configure - Setup IOMMU ops for an endpoint described by VIOT
+ * @dev: the endpoint
+ *
+ * Return: 0 on success, <0 on failure
+ */
+int viot_iommu_configure(struct device *dev)
+{
+	if (dev_is_pci(dev))
+		return pci_for_each_dma_alias(to_pci_dev(dev),
+					      viot_pci_dev_iommu_init, NULL);
+	else if (dev_is_platform(dev))
+		return viot_mmio_dev_iommu_init(to_platform_device(dev));
+	return -ENODEV;
+}
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b1560c45e2a..1a018afff162 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -431,6 +431,14 @@ W:	https://01.org/linux-acpi
 B:	https://bugzilla.kernel.org
 F:	drivers/acpi/acpi_video.c
 
+ACPI VIOT DRIVER
+M:	Jean-Philippe Brucker <jean-philippe at linaro.org>
+L:	linux-acpi at vger.kernel.org
+L:	iommu at lists.linux-foundation.org
+S:	Maintained
+F:	drivers/acpi/viot.c
+F:	include/linux/acpi_viot.h
+
 ACPI WMI DRIVER
 L:	platform-driver-x86 at vger.kernel.org
 S:	Orphan
-- 
2.31.1



From jean-philippe at linaro.org  Fri Apr 23 12:38:35 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Fri, 23 Apr 2021 13:38:35 +0200
Subject: [PATCH v2 4/6] iommu/dma: Pass address limit rather than size to
 iommu_setup_dma_ops()
In-Reply-To: <20210423113836.3974972-1-jean-philippe@linaro.org>
References: <20210423113836.3974972-1-jean-philippe@linaro.org>
Message-ID: <20210423113836.3974972-5-jean-philippe@linaro.org>

Passing a 64-bit address width to iommu_setup_dma_ops() is valid on
virtual platforms, but isn't currently possible. The overflow check in
iommu_dma_init_domain() prevents this even when @dma_base isn't 0. Pass
a limit address instead of a size, so callers don't have to fake a size
to work around the check.

Signed-off-by: Jean-Philippe Brucker <jean-philippe at linaro.org>
---
 include/linux/dma-iommu.h   |  4 ++--
 arch/arm64/mm/dma-mapping.c |  2 +-
 drivers/iommu/amd/iommu.c   |  2 +-
 drivers/iommu/dma-iommu.c   | 12 ++++++------
 drivers/iommu/intel/iommu.c |  2 +-
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 6e75a2d689b4..758ca4694257 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -19,7 +19,7 @@ int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
 void iommu_put_dma_cookie(struct iommu_domain *domain);
 
 /* Setup call for arch DMA mapping code */
-void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size);
+void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit);
 
 /* The DMA API isn't _quite_ the whole story, though... */
 /*
@@ -50,7 +50,7 @@ struct msi_msg;
 struct device;
 
 static inline void iommu_setup_dma_ops(struct device *dev, u64 dma_base,
-		u64 size)
+				       u64 dma_limit)
 {
 }
 
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 93e87b287556..83f4f4bad5e4 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -50,7 +50,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 
 	dev->dma_coherent = coherent;
 	if (iommu)
-		iommu_setup_dma_ops(dev, dma_base, size);
+		iommu_setup_dma_ops(dev, dma_base, size - dma_base - 1);
 
 #ifdef CONFIG_XEN
 	if (xen_initial_domain())
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 67da96d5b3c2..50041df43391 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1713,7 +1713,7 @@ static void amd_iommu_probe_finalize(struct device *dev)
 	/* Domains are initialized for this device - have a look what we ended up with */
 	domain = iommu_get_domain_for_dev(dev);
 	if (domain->type == IOMMU_DOMAIN_DMA)
-		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, 0);
+		iommu_setup_dma_ops(dev, IOVA_START_PFN << PAGE_SHIFT, U64_MAX);
 	else
 		set_dma_ops(dev, NULL);
 }
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 7bcdd1205535..c62e19bed302 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -319,16 +319,16 @@ static bool dev_is_untrusted(struct device *dev)
  * 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
- * @size: Size of IOVA space
+ * @limit: Last address of the IOVA space
  * @dev: Device the domain is being initialised for
  *
- * @base and @size should be exact multiples of IOMMU page granularity to
+ * @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
  * 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,
-		u64 size, struct device *dev)
+				 dma_addr_t limit, struct device *dev)
 {
 	struct iommu_dma_cookie *cookie = domain->iova_cookie;
 	unsigned long order, base_pfn;
@@ -346,7 +346,7 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
 	/* Check the domain allows at least some access to the device... */
 	if (domain->geometry.force_aperture) {
 		if (base > domain->geometry.aperture_end ||
-		    base + size <= domain->geometry.aperture_start) {
+		    limit < domain->geometry.aperture_start) {
 			pr_warn("specified DMA range outside IOMMU capability\n");
 			return -EFAULT;
 		}
@@ -1308,7 +1308,7 @@ static const struct dma_map_ops iommu_dma_ops = {
  * 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 size)
+void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit)
 {
 	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
 
@@ -1320,7 +1320,7 @@ void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size)
 	 * underlying IOMMU driver needs to support via the dma-iommu layer.
 	 */
 	if (domain->type == IOMMU_DOMAIN_DMA) {
-		if (iommu_dma_init_domain(domain, dma_base, size, dev))
+		if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev))
 			goto out_err;
 		dev->dma_ops = &iommu_dma_ops;
 	}
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 708f430af1c4..39a4e672b1c2 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5166,7 +5166,7 @@ static void intel_iommu_probe_finalize(struct device *dev)
 
 	if (domain && domain->type == IOMMU_DOMAIN_DMA)
 		iommu_setup_dma_ops(dev, base,
-				    __DOMAIN_MAX_ADDR(dmar_domain->gaw) - base);
+				    __DOMAIN_MAX_ADDR(dmar_domain->gaw));
 	else
 		set_dma_ops(dev, NULL);
 }
-- 
2.31.1



From broonie at kernel.org  Fri Apr 23 12:57:24 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 12:57:24 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
 <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
 <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>
Message-ID: <20210423115724.GB5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 11:03:22AM +0100, Joe Burmeister wrote:
> On 23/04/2021 00:49, Florian Fainelli wrote:

> > Right, which means that we should probably seek a solution within the
> > SPI core itself, even if you can only test with spi-bcm2835.c chances
> > are that the fix would be applicable for other controllers if done in
> > the core.

> I'm not sure it's possible to do in the core alone. The numb of the
> issue is the core changes ctlr->num_chipselect to what is in the device
> tree and some drivers are cool with that overs quietly stomp memory.

I wouldn't expect any controller to be OK with that?  Drivers can store
per-client data in spi_device->controller_data which doesn't need
scaling (but is also not so helpful if you need to look at clients other
than the one you're currently controlling).

> I've got a simple little patch to warn when the core expands
> ctlr->num_chipselect. This warning won't go off in bcm2835 with my patch
> because I am also extending ctlr->num_chipselect to the amount in the
> device tree before the core does that expansion. Hopefully that new
> warning would make people investigate and fix problem drivers.

> >> There is protection in spi_add_device, which will catch extra added
> >> later, but not ones in the device tree when the spi controller was
> >> registered.

> > Not sure I follow you, if we have the overlay before
> > spi_register_controller() is called, how can the check there not
> > trigger? And if we load the overlay later when the SPI controller is
> > already registered, why does not spi_add_device()'s check work?

> I think it might be a RPI thing. I think it is merging in the overlay
> and giving Linux one already merged.

If the overlay is handled by the bootloader then from the point of view
of Linux there is no overlay - sounds like there's an issue in the
overlay, it should be overriding something that it doesn't?
-------------- 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/20210423/a4988f2a/attachment.sig>

From christophe.kerello at foss.st.com  Fri Apr 23 13:02:39 2021
From: christophe.kerello at foss.st.com (Christophe Kerello)
Date: Fri, 23 Apr 2021 14:02:39 +0200
Subject: [Linux-stm32] [PATCH 1/2] memory: stm32-fmc2-ebi: add missing
 of_node_put for loop iteration
In-Reply-To: <20210423101815.119341-1-krzysztof.kozlowski@canonical.com>
References: <20210423101815.119341-1-krzysztof.kozlowski@canonical.com>
Message-ID: <86a216db-b9b7-da45-ab74-a32538da6e00@foss.st.com>

Hi Krzysztof,

On 4/23/21 12:18 PM, Krzysztof Kozlowski wrote:
> Early exits from for_each_available_child_of_node() should decrement the
> node reference counter.  Reported by Coccinelle:
> 
>    drivers/memory/stm32-fmc2-ebi.c:1046:1-33: WARNING:
>      Function "for_each_available_child_of_node" should have of_node_put() before return around line 1051.
> 
> Fixes: 66b8173a197f ("memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
>   drivers/memory/stm32-fmc2-ebi.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index 4d5758c419c5..ffec26a99313 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -1048,16 +1048,19 @@ static int stm32_fmc2_ebi_parse_dt(struct stm32_fmc2_ebi *ebi)
>   		if (ret) {
>   			dev_err(dev, "could not retrieve reg property: %d\n",
>   				ret);
> +			of_node_put(child);
>   			return ret;
>   		}
>   
>   		if (bank >= FMC2_MAX_BANKS) {
>   			dev_err(dev, "invalid reg value: %d\n", bank);
> +			of_node_put(child);
>   			return -EINVAL;
>   		}
>   
>   		if (ebi->bank_assigned & BIT(bank)) {
>   			dev_err(dev, "bank already assigned: %d\n", bank);
> +			of_node_put(child);
>   			return -EINVAL;
>   		}
>   
> @@ -1066,6 +1069,7 @@ static int stm32_fmc2_ebi_parse_dt(struct stm32_fmc2_ebi *ebi)
>   			if (ret) {
>   				dev_err(dev, "setup chip select %d failed: %d\n",
>   					bank, ret);
> +				of_node_put(child);
>   				return ret;
>   			}
>   		}
>

Reviewed-by: Christophe Kerello <christophe.kerello at foss.st.com>

Regards,
Christophe Kerello.



From robin.murphy at arm.com  Fri Apr 23 13:16:30 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 23 Apr 2021 13:16:30 +0100
Subject: [PATCH] arm/mach-hisi: Use BUG_ON instead of if condition
 followed by BUG
In-Reply-To: <1619165686-69955-1-git-send-email-zhouchuangao@vivo.com>
References: <1619165686-69955-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <8875077b-ed17-0896-97e7-1b2b13e9a9fa@arm.com>

On 2021-04-23 09:14, zhouchuangao wrote:
> BUG_ON uses unlikely in if(). Through disassembly, we can see that
> brk #0x800 is compiled to the end of the function.
> As you can see below:
>      ......
>      ffffff8008660bec:   d65f03c0    ret
>      ffffff8008660bf0:   d4210000    brk #0x800
> 
> Usually, the condition in if () is not satisfied. For the
> multi-stage pipeline, we do not need to perform fetch decode
> and excute operation on brk instruction.

32-bit Arm does not have "ret" and "brk" instructions, and either way 
the relevant BUG() instruction(s) aren't executed unless the condition 
is met, so this really makes very little sense.

> In my opinion, this can improve the efficiency of the
> multi-stage pipeline.

It has very little to do with the pipeline - modern cores are 
considerably more sophisticated than the 3-stage Acorn RISC Machine of 
1985, and are not usually limited by frontend throughput. The point of 
unlikely() is to avoid having a normally-taken forward branch to skip 
over in-line code, and instead make sure the only thing in the normal 
execution path is a normally-not-taken branch to handle the condition 
out-of-line. Yes, the impact of branches - and thus why it can be 
desirable to avoid them - is indeed *related* to pipelining, but that's 
rather tangential.

Even then, it's only worth considering things at this level in 
frequently-executed and/or performance-critical code. Saving a couple of 
CPU cycles in something that is effectively a one-time operation is 
utterly immaterial.

The realistic justification for these patches is that that BUG_ON() 
exists for implementing conditional BUG()s, so we may as well use it if 
it makes the source code more readable.

> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
> ---
>   arch/arm/mach-hisi/hotplug.c  | 3 +--
>   arch/arm/mach-hisi/platmcpm.c | 4 ++--
>   2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
> index c517941..b9ced60 100644
> --- a/arch/arm/mach-hisi/hotplug.c
> +++ b/arch/arm/mach-hisi/hotplug.c
> @@ -193,8 +193,7 @@ void hix5hd2_set_cpu(int cpu, bool enable)
>   	u32 val = 0;
>   
>   	if (!ctrl_base)
> -		if (!hix5hd2_hotplug_init())
> -			BUG();
> +		BUG_ON(!hix5hd2_hotplug_init());

Whatever tool you're using to detect these patterns, consider improving 
it, or at least giving a bit more thought to the results beyond blindly 
applying one single rule - "if(x) BUG_ON(y);" arguably makes even less 
sense since it's now neither one thing nor the other.

Robin.

>   	if (enable) {
>   		/* power on cpu1 */
> diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c
> index 96a4840..6c90039 100644
> --- a/arch/arm/mach-hisi/platmcpm.c
> +++ b/arch/arm/mach-hisi/platmcpm.c
> @@ -82,8 +82,8 @@ static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
>   {
>   	unsigned long data;
>   
> -	if (!fabric)
> -		BUG();
> +	BUG_ON(!fabric);
> +
>   	data = readl_relaxed(fabric + FAB_SF_MODE);
>   	if (on)
>   		data |= 1 << cluster;
> 


From broonie at kernel.org  Fri Apr 23 13:18:57 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 13:18:57 +0100
Subject: [PATCH v1 6/8] spi: rockchip: Set rx_fifo interrupt waterline
 base on transfer item
In-Reply-To: <20210423084750.18533-1-jon.lin@rock-chips.com>
References: <20210423084155.17439-1-jon.lin@rock-chips.com>
 <20210423084750.18533-1-jon.lin@rock-chips.com>
Message-ID: <20210423121857.GC5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 04:47:48PM +0800, Jon Lin wrote:
> The error here is to calculate the width as 8 bits. In fact, 16 bits
> should be considered.

Bugfix patches like this should go at the start of a series so they can
be sent as fixes without any dependencies on earlier patches.
-------------- 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/20210423/733988c3/attachment.sig>

From rafael at kernel.org  Fri Apr 23 13:22:55 2021
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Fri, 23 Apr 2021 14:22:55 +0200
Subject: [RFC PATCH 2/4] cpuidle: menu: add idle_time to cpuidle_state
In-Reply-To: <1619123448-10138-3-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <1619123448-10138-3-git-send-email-skomatineni@nvidia.com>
Message-ID: <CAJZ5v0hb7AES4A2QHhtMo76GbbkH=FnyQb0oEpHOaWWirpJ80A@mail.gmail.com>

On Thu, Apr 22, 2021 at 10:31 PM Sowjanya Komatineni
<skomatineni at nvidia.com> wrote:
>
> Some platforms use separate CPU firmware running in background to
> handle state transitions which may need runtime idle time of the
> corresponding target state from the kernel.

How exactly does this work?

> This patch adds idle_time to cpuidle state to expose to cpuidle driver the
> idle time that the governor menu predicts based on next events and states
> target residency for selecting proper idle state.
>
> CPU idle driver passes this runtime state idle time to TF-A.
>
> Signed-off-by: Sowjanya Komatineni <skomatineni at nvidia.com>
> ---
>  drivers/cpuidle/governors/menu.c | 7 ++++++-
>  include/linux/cpuidle.h          | 1 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index c3aa8d6..0da5bc5 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -382,8 +382,10 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>                          * stuck in the shallow one for too long.
>                          */
>                         if (drv->states[idx].target_residency_ns < TICK_NSEC &&
> -                           s->target_residency_ns <= delta_tick)
> +                           s->target_residency_ns <= delta_tick) {
> +                               drv->states[idx].idle_time = delta_tick / NSEC_PER_USEC;
>                                 idx = i;
> +                       }
>
>                         return idx;
>                 }
> @@ -393,6 +395,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>                 idx = i;
>         }
>
> +       drv->states[idx].idle_time = predicted_ns / NSEC_PER_USEC;
>         if (idx == -1)
>                 idx = 0; /* No states enabled. Must use 0. */
>
> @@ -419,6 +422,8 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
>                                 if (drv->states[i].target_residency_ns <= delta_tick)
>                                         break;
>                         }
> +
> +                       drv->states[idx].idle_time = delta_tick / NSEC_PER_USEC;
>                 }
>         }
>
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index fce4762..12db2e9 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -55,6 +55,7 @@ struct cpuidle_state {
>         unsigned int    exit_latency; /* in US */
>         int             power_usage; /* in mW */
>         unsigned int    target_residency; /* in US */
> +       unsigned int    idle_time; /* in US */

No way.

This structure holds idle state properties of and not some random data
passed between cpuidle components.  And it is not per-CPU, while the
governors work on the per-CPU basis.

state_usage might be more suitable, but that only if I'm convinced
that this is really necessary.

>
>         int (*enter)    (struct cpuidle_device *dev,
>                         struct cpuidle_driver *drv,
> --


From rafael at kernel.org  Fri Apr 23 13:27:05 2021
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Fri, 23 Apr 2021 14:27:05 +0200
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <CAJZ5v0hivxQjA2AZpPxVadzaM7gB+L3BRnoNyeD7hyvr-3Fh4g@mail.gmail.com>

On Thu, Apr 22, 2021 at 10:31 PM Sowjanya Komatineni
<skomatineni at nvidia.com> wrote:
>
> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
> in charge of deciding on state transition based on target state, state idle
> time, and some other Tegra CPU core cluster states information.
>
> Current PSCI specification don't have function defined for passing runtime
> state idle time predicted by governor (based on next events and state target
> residency) to ARM trusted firmware.

Presumably that's because this is not a good idea.

A basic design principle of cpuidle is that it should be possible to
use every governor with every driver and the changes in this series
make the platforms in question only work with menu AFAICS.


From thierry.reding at gmail.com  Fri Apr 23 13:56:03 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 14:56:03 +0200
Subject: [GIT PULL 5/5] arm64: tegra: Device tree fixes for v5.12-rc6
In-Reply-To: <20210401172622.3352990-5-thierry.reding@gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-5-thierry.reding@gmail.com>
Message-ID: <YILD4yyPXuiYbHW1@orome.fritz.box>

On Thu, Apr 01, 2021 at 07:26:22PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
> 
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> 
>   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm64-dt
> 
> for you to fetch changes up to 405fa9e9d8664e830982c5fbcb70f9ba8656bafc:
> 
>   arm64: tegra: Move clocks from RT5658 endpoint to device node (2021-03-25 14:04:49 +0100)
> 
> Thanks,
> Thierry

Hi Arnd,

I noticed that v5.12-rc8 is still broken because of the missing
fw_devlink=on patch from this PR. This PR was meant to go into v5.12,
but it looks like you pulled it for the next release.

In retrospect I realize that the way I sent this out was rather
confusing. Any chance you can still pull these into v5.12 to unbreak
the final release?

Thanks,
Thierry

> ----------------------------------------------------------------
> arm64: tegra: Device tree fixes for v5.12-rc6
> 
> This contains a couple of device tree fixes for the v5.12 release cycle.
> These are needed for proper audio support on Jetson AGX Xavier, to boot
> the Jetson Xavier NX from an SD card and to be able to suspend/resume
> the Jetson TX2.
> 
> ----------------------------------------------------------------
> Jon Hunter (2):
>       arm64: tegra: Set fw_devlink=on for Jetson TX2
>       arm64: tegra: Fix mmc0 alias for Jetson Xavier NX
> 
> Sameer Pujar (1):
>       arm64: tegra: Move clocks from RT5658 endpoint to device node
> 
> Thierry Reding (1):
>       arm64: tegra: Add unit-address for ACONNECT on Tegra186
> 
>  arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts  | 2 +-
>  arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi      | 2 +-
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi            | 2 +-
>  arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts  | 3 ++-
>  arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi | 4 ++++
>  arch/arm64/boot/dts/nvidia/tegra194-p3668-0001.dtsi | 4 ++++
>  arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi      | 1 -
>  7 files changed, 13 insertions(+), 5 deletions(-)
-------------- 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/20210423/c1b8521a/attachment.sig>

From enric.balletbo at collabora.com  Fri Apr 23 14:00:43 2021
From: enric.balletbo at collabora.com (Enric Balletbo i Serra)
Date: Fri, 23 Apr 2021 15:00:43 +0200
Subject: [PATCH] arm64: dts: mt8183: add mediatek,gce-events in mutex
In-Reply-To: <20210423065327.1596075-1-hsinyi@chromium.org>
References: <20210423065327.1596075-1-hsinyi@chromium.org>
Message-ID: <846d2a7a-d9c2-7d9e-9d7e-843ff604be44@collabora.com>

Hi Hsin-Yi,

Thank you for your patch.

On 23/4/21 8:53, Hsin-Yi Wang wrote:
> mediatek,gce-events is read by mutex node.
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>

Although I know this property is used and needed I didn't find documentation
about it. It would be really nice document in the bindings this mediatek property.

In any case this patch LGTM, so

Reviewed-by: Enric Balletbo i Serra <enric.balletbo at collabora.com>

> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index c5e822b6b77a..cf22d71161e5 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1250,6 +1250,8 @@ mutex: mutex at 14016000 {
>  			reg = <0 0x14016000 0 0x1000>;
>  			interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
>  			power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> +			mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
> +					      <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
>  		};
>  
>  		larb0: larb at 14017000 {
> 


From zhouchuangao at vivo.com  Fri Apr 23 14:10:48 2021
From: zhouchuangao at vivo.com (=?UTF-8?B?5ZGo5Lyg6auY?=)
Date: Fri, 23 Apr 2021 21:10:48 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6UmU6IFtQQVRDSF0gYXJtL21hY2gtaGlzaTogVXNlIEJVR19PTiBpbnN0ZWFkIG9mIGlmIGNvbmRpdGlvbiBmb2xsb3dlZCBieSBCVUc=?=
In-Reply-To: <8875077b-ed17-0896-97e7-1b2b13e9a9fa@arm.com>
Message-ID: <ABIADwBIDlOwglwOvNgTgKrM.3.1619183448038.Hmail.zhouchuangao@vivo.com>


>On 2021-04-23 09:14, zhouchuangao wrote:
>> BUG_ON uses unlikely in if(). Through disassembly, we can see that
>> brk #0x800 is compiled to the end of the function.
>> As you can see below:
>>      ......
>>      ffffff8008660bec:   d65f03c0    ret
>>      ffffff8008660bf0:   d4210000    brk #0x800
>> 
>> Usually, the condition in if () is not satisfied. For the
>> multi-stage pipeline, we do not need to perform fetch decode
>> and excute operation on brk instruction.
>
>32-bit Arm does not have "ret" and "brk" instructions, and either way 
>the relevant BUG() instruction(s) aren't executed unless the condition 
>is met, so this really makes very little sense.
>

Sorry, this is just an analysis based on ARM64.

>> In my opinion, this can improve the efficiency of the
>> multi-stage pipeline.
>
>It has very little to do with the pipeline - modern cores are 
>considerably more sophisticated than the 3-stage Acorn RISC Machine of 
>1985, and are not usually limited by frontend throughput. The point of 
>unlikely() is to avoid having a normally-taken forward branch to skip 
>over in-line code, and instead make sure the only thing in the normal 
>execution path is a normally-not-taken branch to handle the condition 
>out-of-line. Yes, the impact of branches - and thus why it can be 
>desirable to avoid them - is indeed *related* to pipelining, but that's 
>rather tangential.
>
>Even then, it's only worth considering things at this level in 
>frequently-executed and/or performance-critical code. Saving a couple of 
>CPU cycles in something that is effectively a one-time operation is 
>utterly immaterial.
>
>The realistic justification for these patches is that that BUG_ON() 
>exists for implementing conditional BUG()s, so we may as well use it if 
>it makes the source code more readable.
>

Thank you for your excellent analysis, Indeed, only in the case of
Frequently Executed and/or Performance-Critical Code, the patch is of
great value.

Hmm...Perhaps the best reason is to make the code more readable.

BR,
zhouchuangao

>> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
>> ---
>>   arch/arm/mach-hisi/hotplug.c  | 3 +--
>>   arch/arm/mach-hisi/platmcpm.c | 4 ++--
>>   2 files changed, 3 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
>> index c517941..b9ced60 100644
>> --- a/arch/arm/mach-hisi/hotplug.c
>> +++ b/arch/arm/mach-hisi/hotplug.c
>> @@ -193,8 +193,7 @@ void hix5hd2_set_cpu(int cpu, bool enable)
>>   	u32 val = 0;
>>   
>>   	if (!ctrl_base)
>> -		if (!hix5hd2_hotplug_init())
>> -			BUG();
>> +		BUG_ON(!hix5hd2_hotplug_init());
>
>Whatever tool you're using to detect these patterns, consider improving 
>it, or at least giving a bit more thought to the results beyond blindly 
>applying one single rule - "if(x) BUG_ON(y);" arguably makes even less 
>sense since it's now neither one thing nor the other.
>
>Robin.
>
>>   	if (enable) {
>>   		/* power on cpu1 */
>> diff --git a/arch/arm/mach-hisi/platmcpm.c b/arch/arm/mach-hisi/platmcpm.c
>> index 96a4840..6c90039 100644
>> --- a/arch/arm/mach-hisi/platmcpm.c
>> +++ b/arch/arm/mach-hisi/platmcpm.c
>> @@ -82,8 +82,8 @@ static void hip04_set_snoop_filter(unsigned int cluster, unsigned int on)
>>   {
>>   	unsigned long data;
>>   
>> -	if (!fabric)
>> -		BUG();
>> +	BUG_ON(!fabric);
>> +
>>   	data = readl_relaxed(fabric + FAB_SF_MODE);
>>   	if (on)
>>   		data |= 1 << cluster;
>> 



From suzuki.poulose at arm.com  Fri Apr 23 14:20:18 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Fri, 23 Apr 2021 14:20:18 +0100
Subject: [PATCH v1] coresight: add node to reset all coresight devices
In-Reply-To: <1619166578-28690-1-git-send-email-taozha@codeaurora.org>
References: <1619166578-28690-1-git-send-email-taozha@codeaurora.org>
Message-ID: <e753898c-0334-cf84-620e-d9b9f18d87e7@arm.com>

On 23/04/2021 09:29, Tao Zhang wrote:
> Add new reset_source_sink node to be able to disable all active
> coresight devices.
> In this way, we no longer need to manually disable all active
> coresight devices one by one. After enabling multiple coresight
> paths, users can reset their status more conveniently by this
> node.
> 

What is the use case here ? Why would you trigger a reset for all the
sources/sink without gracefully completing any on-going sessions
(including the perf ones, which are driven by the kernel perf layer)

> This patch base on coresight-next repo
> http://git.linaro.org/kernel/coresight.git/log/?h=next
> 
> And this patch depends on the following patch
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg2551216.html

Please post related patches as a series, possibly describing the overall
problem that you are trying to solve, in the cover letter.

> 
> Signed-off-by: Tingwei Zhang <tingwei at codeaurora.org>
> Signed-off-by: Mao Jinlong <jinlmao at codeaurora.org>
> Signed-off-by: Tao Zhang <taozha at codeaurora.org>
> ---
>   drivers/hwtracing/coresight/coresight-core.c | 72 ++++++++++++++++++++++++----
>   1 file changed, 64 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 7dfadb6..0001b6c 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -107,6 +107,23 @@ static int coresight_source_is_unique(struct coresight_device *csdev)
>   				 csdev, coresight_id_match);
>   }
>   
> +static int coresight_reset_sink(struct device *dev, void *data)
> +{
> +	struct coresight_device *csdev = to_coresight_device(dev);
> +
> +	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
> +	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
> +	     csdev->activated)
> +		csdev->activated = false;

Why is this needed, when the disabl_path() should have taken care of this ?

> +
> +	return 0;
> +}
> +
> +static void coresight_reset_all_sink(void)
> +{
> +	bus_for_each_dev(&coresight_bustype, NULL, NULL, coresight_reset_sink);
> +}
> +

How can you disable all the active sinks when some of the sinks could be 
driven by perf ?

>   static int coresight_find_link_inport(struct coresight_device *csdev,
>   				      struct coresight_device *parent)
>   {
> @@ -1137,7 +1154,7 @@ int coresight_enable(struct coresight_device *csdev)
>   }
>   EXPORT_SYMBOL_GPL(coresight_enable);
>   
> -void coresight_disable(struct coresight_device *csdev)
> +static void __coresight_disable(struct coresight_device *csdev)
>   {
>   	int  ret;
>   	struct list_head *path = NULL;
> @@ -1145,14 +1162,12 @@ void coresight_disable(struct coresight_device *csdev)
>   	struct coresight_path *cspath_next = NULL;
>   	struct coresight_device *src_csdev = NULL;
>   
> -	mutex_lock(&coresight_mutex);
> -
>   	ret = coresight_validate_source(csdev, __func__);
>   	if (ret)
> -		goto out;
> +		return;
>   
>   	if (!csdev->enable || !coresight_disable_source(csdev))
> -		goto out;
> +		return;
>   
>   	list_for_each_entry_safe(cspath, cspath_next, &cs_active_paths, link) {
>   		src_csdev = coresight_get_source(cspath->path);
> @@ -1165,12 +1180,16 @@ void coresight_disable(struct coresight_device *csdev)
>   		}
>   	}
>   	if (path == NULL)
> -		goto out;
> +		return;
>   
>   	coresight_disable_path(path);
>   	coresight_release_path(path);
> +}
>   
> -out:
> +void coresight_disable(struct coresight_device *csdev)
> +{
> +	mutex_lock(&coresight_mutex);
> +	__coresight_disable(csdev);
>   	mutex_unlock(&coresight_mutex);
>   }
>   EXPORT_SYMBOL_GPL(coresight_disable);
> @@ -1467,7 +1486,43 @@ int coresight_timeout(void __iomem *addr, u32 offset, int position, int value)
>   
>   	return -EAGAIN;
>   }
> -EXPORT_SYMBOL_GPL(coresight_timeout);

Why ?

> +
> +static ssize_t reset_source_sink_store(struct bus_type *bus,
> +				       const char *buf, size_t size)
> +{
> +	int ret = 0;
> +	unsigned long val;
> +	struct coresight_path *cspath = NULL;
> +	struct coresight_path *cspath_next = NULL;
> +	struct coresight_device *csdev;
> +
> +	ret = kstrtoul(buf, 10, &val);
> +	if (ret)
> +		return ret;
> +
> +	mutex_lock(&coresight_mutex);
> +
> +	list_for_each_entry_safe(cspath, cspath_next, &cs_active_paths, link) {
> +		csdev = coresight_get_source(cspath->path);
> +		if (!csdev)
> +			continue;
> +		atomic_set(csdev->refcnt, 1);

Is this safe ?

> +		__coresight_disable(csdev);
> +	}
> +
> +	/* Reset all activated sinks */
> +	coresight_reset_all_sink();
> +
> +	mutex_unlock(&coresight_mutex);
> +	return size;
> +}
> +static BUS_ATTR_WO(reset_source_sink);
> +
> +static struct attribute *coresight_reset_source_sink_attrs[] = {
> +	&bus_attr_reset_source_sink.attr,
> +	NULL,
> +};
> +ATTRIBUTE_GROUPS(coresight_reset_source_sink);
>   
>   /*
>    * coresight_release_platform_data: Release references to the devices connected
> @@ -1680,6 +1735,7 @@ EXPORT_SYMBOL_GPL(coresight_alloc_device_name);
>   
>   struct bus_type coresight_bustype = {
>   	.name	= "coresight",
> +	.bus_groups	= coresight_reset_source_sink_groups,
>   };
>   
>   static int __init coresight_init(void)
> 



From vkoul at kernel.org  Fri Apr 23 14:24:59 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 23 Apr 2021 18:54:59 +0530
Subject: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
Message-ID: <YILKq+jNZZSs37xa@vkoul-mobl.Dlink>

On 23-04-21, 11:17, Lars-Peter Clausen wrote:
> 
> It seems to me what we are missing from the DMAengine API is the equivalent
> of device_prep_dma_memcpy() that is able to take SG lists. There is already
> a memset_sg, it should be possible to add something similar for memcpy.

You mean something like dmaengine_prep_dma_sg() which was removed?

static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg(
               struct dma_chan *chan,
               struct scatterlist *dst_sg, unsigned int dst_nents,
               struct scatterlist *src_sg, unsigned int src_nents,
               unsigned long flags)

The problem with this API is that it would work only when src_sg and
dst_sg is of similar nature, if not then how should one go about
copying...should we fill without a care for dst_sg being different than
src_sg as long as total data to be copied has enough space in dst...

We can always add this back if we have in-kernel user but the semantics
of the API needs to be thought thru

Thanks
-- 
~Vinod


From arnd at arndb.de  Fri Apr 23 14:42:42 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 23 Apr 2021 15:42:42 +0200
Subject: [GIT PULL 5/5] arm64: tegra: Device tree fixes for v5.12-rc6
In-Reply-To: <YILD4yyPXuiYbHW1@orome.fritz.box>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-5-thierry.reding@gmail.com>
 <YILD4yyPXuiYbHW1@orome.fritz.box>
Message-ID: <CAK8P3a1fDD6FXj1gL8Gwb+03ERKhm6uT94Yt7Ne2aRghn539fQ@mail.gmail.com>

On Fri, Apr 23, 2021 at 2:56 PM Thierry Reding <thierry.reding at gmail.com> wrote:
>
> On Thu, Apr 01, 2021 at 07:26:22PM +0200, Thierry Reding wrote:
> > Hi ARM SoC maintainers,
> >
> > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> >
> >   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> >
> > are available in the Git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm64-dt
> >
> > for you to fetch changes up to 405fa9e9d8664e830982c5fbcb70f9ba8656bafc:
> >
> >   arm64: tegra: Move clocks from RT5658 endpoint to device node (2021-03-25 14:04:49 +0100)
> >
> > Thanks,
> > Thierry
>
> Hi Arnd,
>
> I noticed that v5.12-rc8 is still broken because of the missing
> fw_devlink=on patch from this PR. This PR was meant to go into v5.12,
> but it looks like you pulled it for the next release.

Indeed, I never noticed the difference between the subject line and
the tag name. I usually go by the subject to see what branch to pick
and only then check if there are any discrepancies, but I missed this one.

> In retrospect I realize that the way I sent this out was rather
> confusing. Any chance you can still pull these into v5.12 to unbreak
> the final release?

I've pulled it into the arm/fixes branch now. There is only one other fix in
the arm/fixes, but I should still be able to send it out tomorrow.

      Arnd


From catalin.marinas at arm.com  Fri Apr 23 14:43:35 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 14:43:35 +0100
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
In-Reply-To: <20210422142334.GA24087@lpieralisi>
References: <20210421164317.1718831-1-maz@kernel.org>
 <20210422142334.GA24087@lpieralisi>
Message-ID: <20210423134334.GO18757@arm.com>

On Thu, Apr 22, 2021 at 03:23:42PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Apr 21, 2021 at 05:43:15PM +0100, Marc Zyngier wrote:
> > Dann recently reported that his ThunderX machine failed to boot since
> > 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
> > interrupts"), with a not so pretty crash while trying to send an IPI.
> > 
> > It turned out to be caused by a mix of broken firmware and a buggy
> > GTDT watchdog driver. Both have forever been buggy, but the above
> > commit revealed that the error handling path of the driver was
> > probably the worse part of it all.
> > 
> > Anyway, this short series has two goals:
> > - handle broken firmware in a less broken way
> > - make sure that the route cause of the problem can be identified
> >   quickly
> > 
> > Thanks,
> > 
> > 	M.
> > 
> > Marc Zyngier (2):
> >   ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
> >   ACPI: irq: Prevent unregistering of GIC SGIs
> > 
> >  drivers/acpi/arm64/gtdt.c | 10 ++++++----
> >  drivers/acpi/irq.c        |  6 +++++-
> >  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> Patch(2) needs an ACK from Rafael - usually these patches go via
> the ARM64 tree but I don't think it is compulsory for this series.
> 
> Thank you !
> 
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Thanks Lorenzo.

Rafael, if there are no objections, I'll take these two patches in the
arm64 tree.

-- 
Catalin


From arnd at kernel.org  Fri Apr 23 14:47:44 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 23 Apr 2021 15:47:44 +0200
Subject: [RFC PATCH 1/2] ARM: mstar: Add header with macros for RIU
 register access
In-Reply-To: <20210422140945.4131092-2-daniel@0x0f.com>
References: <20210422140945.4131092-1-daniel@0x0f.com>
 <20210422140945.4131092-2-daniel@0x0f.com>
Message-ID: <CAK8P3a3fkjy2YYwhmsFQt-MSyOh=1zf1wqzQB7usjsHbUBWdtQ@mail.gmail.com>

On Thu, Apr 22, 2021 at 4:11 PM Daniel Palmer <daniel at 0x0f.com> wrote:

> +
> +#include <linux/io.h>
> +
> +static inline u32 riu_readl(__iomem void *base, unsigned int offset)

The __iomem token comes after the type, so this should be 'void __iomem *'.

> +       return readw_relaxed(reg + 4) << 16 | readw_relaxed(reg);

This should probably be using 'readw' instead of 'readw_relaxed'. If you
absolutely need to use one of the relaxed accessors somewhere,
better add both sets and make sure drivers use the non-relaxed version
by default.

Maybe both types of accessors can be in a single header.

     Arnd


From lars at metafoo.de  Fri Apr 23 14:51:01 2021
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Fri, 23 Apr 2021 15:51:01 +0200
Subject: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <YILKq+jNZZSs37xa@vkoul-mobl.Dlink>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
 <YILKq+jNZZSs37xa@vkoul-mobl.Dlink>
Message-ID: <bed31611-a084-2a05-f3a3-25585a47be9a@metafoo.de>

On 4/23/21 3:24 PM, Vinod Koul wrote:
> On 23-04-21, 11:17, Lars-Peter Clausen wrote:
>> It seems to me what we are missing from the DMAengine API is the equivalent
>> of device_prep_dma_memcpy() that is able to take SG lists. There is already
>> a memset_sg, it should be possible to add something similar for memcpy.
> You mean something like dmaengine_prep_dma_sg() which was removed?
>
Ah, that's why I could have sworn we already had this!

> static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg(
>                 struct dma_chan *chan,
>                 struct scatterlist *dst_sg, unsigned int dst_nents,
>                 struct scatterlist *src_sg, unsigned int src_nents,
>                 unsigned long flags)
>
> The problem with this API is that it would work only when src_sg and
> dst_sg is of similar nature, if not then how should one go about
> copying...should we fill without a care for dst_sg being different than
> src_sg as long as total data to be copied has enough space in dst...
At least for the CDMA the only requirement is that both buffers have the 
same total size.


From sean at poorly.run  Fri Apr 23 14:53:02 2021
From: sean at poorly.run (Sean Paul)
Date: Fri, 23 Apr 2021 09:53:02 -0400
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
In-Reply-To: <20210409045314.3420733-1-hsinyi@chromium.org>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
Message-ID: <CAMavQKJUpYP8jo2JDGMYNBGtbPSSO7z9BAComm5JQoty=HPtJg@mail.gmail.com>

On Fri, Apr 9, 2021 at 12:53 AM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning. So set panel orientation in dsi before drm_dev_register() is
> called.
>
> [    4.480976] ------------[ cut here ]------------
> [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> <snip>
> [    4.609772] Call trace:
> [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> [    4.616466]  drm_mode_object_add+0x20/0x2c
> [    4.620552]  drm_property_create+0xdc/0x174
> [    4.624723]  drm_property_create_enum+0x34/0x98
> [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [    4.634716]  boe_panel_get_modes+0x88/0xd8
> [    4.638802]  drm_panel_get_modes+0x2c/0x48
> [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [    4.662699]  drm_ioctl_kernel+0xac/0x128
> [    4.666611]  drm_ioctl+0x268/0x410
> [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.678436]  el0_svc_common+0xf4/0x1c0
> [    4.682174]  do_el0_svc_compat+0x28/0x3c
> [    4.686088]  el0_svc_compat+0x10/0x1c
> [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [    4.694171]  el0_sync_compat+0x178/0x180
> [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [    4.702721] ------------[ cut here ]------------
> [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> <snip>
> [    4.833830] Call trace:
> [    4.836266]  drm_object_attach_property+0x48/0xb8
> [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [    4.846432]  boe_panel_get_modes+0x88/0xd8
> [    4.850516]  drm_panel_get_modes+0x2c/0x48
> [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [    4.874410]  drm_ioctl_kernel+0xac/0x128
> [    4.878320]  drm_ioctl+0x268/0x410
> [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.890142]  el0_svc_common+0xf4/0x1c0
> [    4.893879]  do_el0_svc_compat+0x28/0x3c
> [    4.897791]  el0_svc_compat+0x10/0x1c
> [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [    4.905873]  el0_sync_compat+0x178/0x180
> [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ae403c67cbd9..45a702ee09f3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -205,6 +205,7 @@ struct mtk_dsi {
>         u32 irq_data;
>         wait_queue_head_t irq_wait_queue;
>         const struct mtk_dsi_driver_data *driver_data;
> +       enum drm_panel_orientation orientation;
>  };
>
>  static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> @@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>         }
>         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>
> +       drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
> +
>         return 0;
>
>  err_cleanup_encoder:
> @@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>                         ret = PTR_ERR(dsi->next_bridge);
>                         goto err_unregister_host;
>                 }
> +
> +               ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
> +               if (ret) {
> +                       dev_err(dev, "failed to get panel orientation %d\n", ret);
> +                       return ret;
> +               }

I don't think this is the right place to mine orientation since it
duplicates the call from the panel driver.

Instead, how about splitting out
property_create_enum/attach_orientation_property from
set_panel_orientation such that you can attach the property (with
UNKNOWN value) in the connector init and then leave the panel to set
it properly in get_modes (I kind of disagree with populating this in
get_modes as well, but I don't think there's anywhere else to stick it
right now)?

AFAICT orientation is the only property which has the create/attach
calls in the set function which seems like a perfect recipe for this
type of failure.


Sean

>         }
>
>         dsi->driver_data = of_device_get_match_data(dev);
> --
> 2.31.1.295.g9ea45b61b8-goog
>


From thierry.reding at gmail.com  Fri Apr 23 14:59:30 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 15:59:30 +0200
Subject: [GIT PULL 5/5] arm64: tegra: Device tree fixes for v5.12-rc6
In-Reply-To: <CAK8P3a1fDD6FXj1gL8Gwb+03ERKhm6uT94Yt7Ne2aRghn539fQ@mail.gmail.com>
References: <20210401172622.3352990-1-thierry.reding@gmail.com>
 <20210401172622.3352990-5-thierry.reding@gmail.com>
 <YILD4yyPXuiYbHW1@orome.fritz.box>
 <CAK8P3a1fDD6FXj1gL8Gwb+03ERKhm6uT94Yt7Ne2aRghn539fQ@mail.gmail.com>
Message-ID: <YILSwt6e8v5PUvFP@orome.fritz.box>

On Fri, Apr 23, 2021 at 03:42:42PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 23, 2021 at 2:56 PM Thierry Reding <thierry.reding at gmail.com> wrote:
> >
> > On Thu, Apr 01, 2021 at 07:26:22PM +0200, Thierry Reding wrote:
> > > Hi ARM SoC maintainers,
> > >
> > > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> > >
> > >   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.13-arm64-dt
> > >
> > > for you to fetch changes up to 405fa9e9d8664e830982c5fbcb70f9ba8656bafc:
> > >
> > >   arm64: tegra: Move clocks from RT5658 endpoint to device node (2021-03-25 14:04:49 +0100)
> > >
> > > Thanks,
> > > Thierry
> >
> > Hi Arnd,
> >
> > I noticed that v5.12-rc8 is still broken because of the missing
> > fw_devlink=on patch from this PR. This PR was meant to go into v5.12,
> > but it looks like you pulled it for the next release.
> 
> Indeed, I never noticed the difference between the subject line and
> the tag name. I usually go by the subject to see what branch to pick
> and only then check if there are any discrepancies, but I missed this one.

Oh yeah, that's even worse than I thought. I hadn't realized that my
scripts had named the tag tegra-for-5.13-arm64-dt.

Next time I'm going to take a closer look at the tag name and also send
out fixes PRs separately from the feature PRs.

> > In retrospect I realize that the way I sent this out was rather
> > confusing. Any chance you can still pull these into v5.12 to unbreak
> > the final release?
> 
> I've pulled it into the arm/fixes branch now. There is only one other fix in
> the arm/fixes, but I should still be able to send it out tomorrow.

Excellent, thanks!

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/20210423/5d9ba262/attachment.sig>

From daniel at 0x0f.com  Fri Apr 23 15:02:42 2021
From: daniel at 0x0f.com (Daniel Palmer)
Date: Fri, 23 Apr 2021 23:02:42 +0900
Subject: [RFC PATCH 1/2] ARM: mstar: Add header with macros for RIU
 register access
In-Reply-To: <CAK8P3a3fkjy2YYwhmsFQt-MSyOh=1zf1wqzQB7usjsHbUBWdtQ@mail.gmail.com>
References: <20210422140945.4131092-1-daniel@0x0f.com>
 <20210422140945.4131092-2-daniel@0x0f.com>
 <CAK8P3a3fkjy2YYwhmsFQt-MSyOh=1zf1wqzQB7usjsHbUBWdtQ@mail.gmail.com>
Message-ID: <CAFr9PX=QeON1C_25tyNK1rWGm3A_Kc2Ad5qLUCfunmdHQUsv_g@mail.gmail.com>

Hi Arnd,

On Fri, 23 Apr 2021 at 22:48, Arnd Bergmann <arnd at kernel.org> wrote:
>
> The __iomem token comes after the type, so this should be 'void __iomem *'.
>

Bit of copy/paste fail. Fixed.

> > +       return readw_relaxed(reg + 4) << 16 | readw_relaxed(reg);
>
> This should probably be using 'readw' instead of 'readw_relaxed'. If you
> absolutely need to use one of the relaxed accessors somewhere,
> better add both sets and make sure drivers use the non-relaxed version
> by default.

I'll add a relaxed/non-relaxed version of each.
Because of the heavy memory barrier to access one 32 bit register
we'll hit the barrier twice in the non-relaxed version.
And we don't need to hit the barrier at all because it doesn't
actually matter for IO. Is there something better I can do there?

> Maybe both types of accessors can be in a single header.

That makes sense. I'll merge them. Would this header be something that
could go in alone without anything that uses them in mainline right
now?

Thanks,

Daniel


From linux at roeck-us.net  Fri Apr 23 15:10:48 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 23 Apr 2021 07:10:48 -0700
Subject: [PATCH V7 1/2] watchdog: mtk: support pre-timeout when the
 bark irq is available
In-Reply-To: <AGAAwgADDgCvfda5u2TY64qq.3.1619161944242.Hmail.wangqing@vivo.com>
References: <3acb9bb1-763b-5af7-de3c-d7d8d3f5b2f7@roeck-us.net>
 <AGAAwgADDgCvfda5u2TY64qq.3.1619161944242.Hmail.wangqing@vivo.com>
Message-ID: <20210423141048.GA135134@roeck-us.net>

On Fri, Apr 23, 2021 at 03:12:24PM +0800, ?? wrote:
> 
> >On 4/22/21 8:48 PM, ?? wrote:
> >> 
> >>> On 4/22/21 7:53 PM, Wang Qing wrote:
> >>>> Use the bark interrupt as the pretimeout notifier if available.
> >>>>
> >>>> When the watchdog timer expires in dual mode, an interrupt will be
> >>>> triggered first, then the timing restarts. The reset signal will be
> >>>> initiated when the timer expires again.
> >>>>
> >>>> The pretimeout notification shall occur at timeout-sec/2.
> >>>>
> >>>> V2:
> >>>> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> >>>>
> >>>> V3:
> >>>> - Modify the pretimeout behavior, manually reset after the pretimeout
> >>>> - is processed and wait until timeout.
> >>>>
> >>>> V4:
> >>>> - Remove pretimeout related processing. 
> >>>> - Add dual mode control separately.
> >>>>
> >>>> V5:
> >>>> - Fix some formatting and printing problems.
> >>>>
> >>>> V6:
> >>>> - Realize pretimeout processing through dualmode.
> >>>>
> >>>> V7:
> >>>> - Add set_pretimeout().
> >>>>
> >>>> Signed-off-by: Wang Qing <wangqing at vivo.com>
> >>>> ---
> >>>>  drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
> >>>>  1 file changed, 71 insertions(+), 5 deletions(-)
> >>>>
> >>>> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> >>>> index 97ca993..ab3ac5d
> >>>> --- a/drivers/watchdog/mtk_wdt.c
> >>>> +++ b/drivers/watchdog/mtk_wdt.c
> >>>> @@ -25,6 +25,7 @@
> >>>>  #include <linux/reset-controller.h>
> >>>>  #include <linux/types.h>
> >>>>  #include <linux/watchdog.h>
> >>>> +#include <linux/interrupt.h>
> >>>>  
> >>>>  #define WDT_MAX_TIMEOUT		31
> >>>>  #define WDT_MIN_TIMEOUT		1
> >>>> @@ -184,15 +185,23 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
> >>>>  {
> >>>>  	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
> >>>>  	void __iomem *wdt_base = mtk_wdt->wdt_base;
> >>>> +	unsigned int timeout_interval = timeout;
> >>>>  	u32 reg;
> >>>>  
> >>>>  	wdt_dev->timeout = timeout;
> >>>> -
> >>>> +	/*
> >>>> +	 * In dual mode, irq will be triggered at timeout / 2
> >>>> +	 * the real timeout occurs at timeout
> >>>> +	 */
> >>>> +	if (wdt_dev->pretimeout) {
> >>>> +		wdt_dev->pretimeout = timeout / 2;
> >>>
> >>> min_timeout is set to 1. I don't this works well if timeout == 1.
> >>> You'll either need to set min_timeout to 2, or handle that case.
> >> 
> >> It is appropriate to change min_timeout  to 2.
> >> 
> >>>
> >>>> +		timeout_interval = wdt_dev->pretimeout;
> >>>
> >>> timeout_interval is unnecessary. Just update timeout accordingly.
> >>> It needs to take the situation of timeout == 1 into account, though.
> 
> I plan to remove timeout_interval and directly use (timeout-pretimeout)
> update timeout.
> 
> >> 
> >> timeout represents the reset time. When the user calls timeout_show, 
> >> He hopes to get the configured timeout, not the value changed
> >> by pre-timeout.
> >> I modify it like this more in line with the original intention.
> >> 
> >>>
> >>>> +	}
> >>>>  	/*
> >>>>  	 * One bit is the value of 512 ticks
> >>>>  	 * The clock has 32 KHz
> >>>>  	 */
> >>>> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
> >>>> +	reg = WDT_LENGTH_TIMEOUT(timeout_interval << 6) | WDT_LENGTH_KEY;
> >>>>  	iowrite32(reg, wdt_base + WDT_LENGTH);
> >>>>  
> >>>>  	mtk_wdt_ping(wdt_dev);
> >>>> @@ -239,13 +248,46 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
> >>>>  		return ret;
> >>>>  
> >>>>  	reg = ioread32(wdt_base + WDT_MODE);
> >>>> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> >>>> +	if (wdt_dev->pretimeout)
> >>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> >>>> +	else
> >>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> >>>>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
> >>>>  	iowrite32(reg, wdt_base + WDT_MODE);
> >>>>  
> >>>>  	return 0;
> >>>>  }
> >>>>  
> >>>> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> >>>> +					unsigned int timeout)
> >>>> +{
> >>>> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
> >>>> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
> >>>> +	u32 reg = ioread32(wdt_base + WDT_MODE);
> >>>> +
> >>>> +	if (timeout && !wdd->pretimeout) {
> >>>> +		wdd->pretimeout = wdd->timeout / 2;
> >>>> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> >>>> +	} else if (!timeout && wdd->pretimeout) {
> >>>> +		wdd->pretimeout = 0;
> >>>> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> >>>> +	} else
> >>>> +		return 0;

Please run your patch through checkpatch; the above results
in a note about a missing { }.

> >>>> +
> >>>> +	iowrite32(reg, wdt_base + WDT_MODE);
> >>>
> >>> What is the point of setting the mode here ? It will
> >>> be set again in mtk_wdt_set_timeout(). Seems to me all
> >>> you need to do here is to set wdd->pretimeout,
> >>> then call mtk_wdt_set_timeout().
> >> 
> >> mtk_wdt_set_timeout() only set timeout and ping().
> >> Here also need to config to the dualmode or not.
> >> 
> >Ah, you are correct. Sorry, I confused this with the start function.
> >That makes me wonder if it would be better to extract a separate
> >function, mtk_wdt_set_mode(), for that purpose. Thoughts ?
> 
> I have done this, but I found there is no good abstract method, 
> because wdt mode is used in combination, for example?
> WDT_MODE_EN is included in start(), and here is not.
> And the judgment of pretimeout here is also different.
> 
Ok, makes sense. Another minor comment above, though.

Thanks,
Guenter

> Thanks,
> Qing
> 
> >
> >Thanks,
> >Guenter
> >
> >> Thanks,
> >> Qing
> >>>
> >>> Guenter
> >>>
> >>>> +
> >>>> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
> >>>> +}
> >>>> +
> >>>> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> >>>> +{
> >>>> +	struct watchdog_device *wdd = arg;
> >>>> +
> >>>> +	watchdog_notify_pretimeout(wdd);
> >>>> +
> >>>> +	return IRQ_HANDLED;
> >>>> +}
> >>>> +
> >>>>  static const struct watchdog_info mtk_wdt_info = {
> >>>>  	.identity	= DRV_NAME,
> >>>>  	.options	= WDIOF_SETTIMEOUT |
> >>>> @@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
> >>>>  			  WDIOF_MAGICCLOSE,
> >>>>  };
> >>>>  
> >>>> +static const struct watchdog_info mtk_wdt_pt_info = {
> >>>> +	.identity	= DRV_NAME,
> >>>> +	.options	= WDIOF_SETTIMEOUT |
> >>>> +			  WDIOF_PRETIMEOUT |
> >>>> +			  WDIOF_KEEPALIVEPING |
> >>>> +			  WDIOF_MAGICCLOSE,
> >>>> +};
> >>>> +
> >>>>  static const struct watchdog_ops mtk_wdt_ops = {
> >>>>  	.owner		= THIS_MODULE,
> >>>>  	.start		= mtk_wdt_start,
> >>>>  	.stop		= mtk_wdt_stop,
> >>>>  	.ping		= mtk_wdt_ping,
> >>>>  	.set_timeout	= mtk_wdt_set_timeout,
> >>>> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
> >>>>  	.restart	= mtk_wdt_restart,
> >>>>  };
> >>>>  
> >>>> @@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
> >>>>  	struct device *dev = &pdev->dev;
> >>>>  	struct mtk_wdt_dev *mtk_wdt;
> >>>>  	const struct mtk_wdt_data *wdt_data;
> >>>> -	int err;
> >>>> +	int err, irq;
> >>>>  
> >>>>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
> >>>>  	if (!mtk_wdt)
> >>>> @@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
> >>>>  	if (IS_ERR(mtk_wdt->wdt_base))
> >>>>  		return PTR_ERR(mtk_wdt->wdt_base);
> >>>>  
> >>>> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> >>>> +	irq = platform_get_irq(pdev, 0);
> >>>> +	if (irq > 0) {
> >>>> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> >>>> +					&mtk_wdt->wdt_dev);
> >>>> +		if (err)
> >>>> +			return err;
> >>>> +
> >>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> >>>> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
> >>>> +	} else {
> >>>> +		if (irq == -EPROBE_DEFER)
> >>>> +			return -EPROBE_DEFER;
> >>>> +
> >>>> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> >>>> +	}
> >>>> +
> >>>>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
> >>>>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
> >>>>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> >>>>
> >>>
> >> 
> >> 
> >
> 
> 


From joe.burmeister at devtank.co.uk  Fri Apr 23 15:12:11 2021
From: joe.burmeister at devtank.co.uk (Joe Burmeister)
Date: Fri, 23 Apr 2021 15:12:11 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <20210423115724.GB5507@sirena.org.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
 <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
 <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>
 <20210423115724.GB5507@sirena.org.uk>
Message-ID: <672e8d77-ee5c-f10f-0bd3-f8708dfc24c8@devtank.co.uk>

On 23/04/2021 12:57, Mark Brown wrote:
> On Fri, Apr 23, 2021 at 11:03:22AM +0100, Joe Burmeister wrote:
>> On 23/04/2021 00:49, Florian Fainelli wrote:
>>> Right, which means that we should probably seek a solution within the
>>> SPI core itself, even if you can only test with spi-bcm2835.c chances
>>> are that the fix would be applicable for other controllers if done in
>>> the core.
>> I'm not sure it's possible to do in the core alone. The numb of the
>> issue is the core changes ctlr->num_chipselect to what is in the device
>> tree and some drivers are cool with that overs quietly stomp memory.
> I wouldn't expect any controller to be OK with that?  Drivers can store
> per-client data in spi_device->controller_data which doesn't need
> scaling (but is also not so helpful if you need to look at clients other
> than the one you're currently controlling).
I can see a number which certainly wouldn't. Though I don't want to
assume that all don't.

If we are happy just not letting the core expand num_chipselect that
does stop the condition on everything.

Any controller that can go higher without issue could them have their
num_chipselect set to what their real limit is if this enforcement
causes an issue.


>> I've got a simple little patch to warn when the core expands
>> ctlr->num_chipselect. This warning won't go off in bcm2835 with my patch
>> because I am also extending ctlr->num_chipselect to the amount in the
>> device tree before the core does that expansion. Hopefully that new
>> warning would make people investigate and fix problem drivers.
>>>> There is protection in spi_add_device, which will catch extra added
>>>> later, but not ones in the device tree when the spi controller was
>>>> registered.
>>> Not sure I follow you, if we have the overlay before
>>> spi_register_controller() is called, how can the check there not
>>> trigger? And if we load the overlay later when the SPI controller is
>>> already registered, why does not spi_add_device()'s check work?
>> I think it might be a RPI thing. I think it is merging in the overlay
>> and giving Linux one already merged.
> If the overlay is handled by the bootloader then from the point of view
> of Linux there is no overlay - sounds like there's an issue in the
> overlay, it should be overriding something that it doesn't?
Does it matter if the final device tree was compiled like that in the
first place or merge into that by the bootloader?

The limit isn't an hardware issue because the bcm2835 just uses any
gpios for CS. So hardware like ours with 8 spi chips on the bus is fine.
The driver's limit at 4 is arbitrary.

My patch for the bcm2835 just compares of what is in the device
tree and the harcoded limit and uses the largest. Other drivers do this.

Of course we could just raise BCM2835_SPI_NUM_CS to 8 or more if that is
preferred. Does seams like the dynamic solution is less favoured.

Regards,

Joe




From adrian.martinezlarumbe at imgtec.com  Fri Apr 23 15:36:43 2021
From: adrian.martinezlarumbe at imgtec.com (Adrian Larumbe)
Date: Fri, 23 Apr 2021 15:36:43 +0100
Subject: [EXTERNAL] Re: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <bed31611-a084-2a05-f3a3-25585a47be9a@metafoo.de>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
 <YILKq+jNZZSs37xa@vkoul-mobl.Dlink>
 <bed31611-a084-2a05-f3a3-25585a47be9a@metafoo.de>
Message-ID: <20210423143643.3y6opm6j4ry4wmao@adrianlarumbe-HP-Elite-7500-Series-MT>

On 23.04.2021 15:51, Lars-Peter Clausen wrote:

> > On 23-04-21, 11:17, Lars-Peter Clausen wrote:
> > > It seems to me what we are missing from the DMAengine API is the equivalent
> > > of device_prep_dma_memcpy() that is able to take SG lists. There is already
> > > a memset_sg, it should be possible to add something similar for memcpy.
> > You mean something like dmaengine_prep_dma_sg() which was removed?
> > 
> Ah, that's why I could have sworn we already had this!

Yes, after that API function was removed, the Xilinx DMA driver effectively
ceased to support memory-to-memory SG transfers. My assumption was if it wasn't
ever reimplemented through the callback you mentioned before, is because there
isn't truly much interest in this device.

However we do need this functionality in our system. At the moment, and for our
particular use of it, we can always guarantee that either the source or
destination will be one contiguous chunk of memory, so just one scatterlist
pointer array was enough to fully program an operation. I think this would fit
alright into memset_sg.  What do you think?

Also, at the moment we're using it for transfers between main memory and
CPU-mapped PCI memory, which cannot be allocated with kmalloc. Wouldn't this
fall into the use case for device_prep_slave_sg?

Adrian


From mathieu.poirier at linaro.org  Fri Apr 23 15:50:18 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 23 Apr 2021 08:50:18 -0600
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
 <20210422165634.GD1256950@xps15>
 <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
Message-ID: <CANLsYkwoS+3qYq=FHRLMjrJSr5cj_PiHaU+a+M17C+8-VJ+b9g@mail.gmail.com>

On Thu, 22 Apr 2021 at 19:01, Peng Fan <peng.fan at nxp.com> wrote:
>
> Hi Mathieu,
>
> > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > i.MX7ULP/8MN/8MP
> >
> > On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com wrote:
> > > From: Peng Fan <peng.fan at nxp.com>
> > >
> > > V5:
> > >  Add R-b tag
> > >  Move the change in detect mode of patch 5 to patch 7 Per Mathieu's
> > > comments
> > >
> > > V4:
> > >  Typo fix
> > >  patch 4: take state as a check condition  patch 5: move regmap
> > > lookup/attach to imx_rproc_detect_mode  patch 6: add
> > > imx_rproc_clk_enable for optional clk  patch 8: use switch/case in
> > > imx_rproc_detect_mode
> > > V3:
> > >  Add A-b tag for Patch 1/2
> > >  Fix the checkpatch warning for Patch 6,8
> > >
> > > V2:
> > >  Patch 1/8, use fsl as vendor, typo fix  Because patchset [1] has v2
> > > version, patch 5,6,7,8 are adapted that  change.
> > >
> > > This patchset is to support i.MX7ULP/8MN/8MP, also includes a patch to
> > > parse fsl,auto-boot
> > >
> >
> > One of the request I had from the last revision was to explicitly list what other
> > patchset this work depends on and what branch it is based of, something I
> > can't find here.
>
> Sorry, that patchset has been merged, so I remove that line.
> I should mention that that patchset has been merged into Linux-next tree.
>

And what branch this set should be applied to is missing.

> >
> > As such I am dropping this set and won't look at another revision before May
> > 22nd.
>
> Ah. Is it just because that the dependency patchset not been mentioned or you
> have issue applying the patchset that delay the patchset for one month?
>

Both.

> Thanks,
> Peng.
>
> >
> > > Peng Fan (8):
> > >   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> > >   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> > >   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> > >   remoteproc: imx_rproc: parse fsl,auto-boot
> > >   remoteproc: imx_rproc: initial support for mutilple start/stop method
> > >   remoteproc: imx_rproc: make clk optional
> > >   remoteproc: imx_rproc: support i.MX7ULP
> > >   remoteproc: imx_rproc: support i.MX8MN/P
> > >
> > >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
> > >  drivers/remoteproc/imx_rproc.c                | 196
> > +++++++++++++++---
> > >  2 files changed, 173 insertions(+), 34 deletions(-)
> > >
> > > --
> > > 2.30.0
> > >


From robh+dt at kernel.org  Fri Apr 23 16:33:38 2021
From: robh+dt at kernel.org (Rob Herring)
Date: Fri, 23 Apr 2021 10:33:38 -0500
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,
 pci-domain to zero
In-Reply-To: <20210417144953.pznysgn5rdraxggx@pali>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali> <20210415104537.403de52e@thinkpad>
 <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
 <20210417144953.pznysgn5rdraxggx@pali>
Message-ID: <CAL_Jsq+fNGQ+qMuqQ_c1Nou1h4R=-R5sn2n0p7rx==+e2JybSg@mail.gmail.com>

On Sat, Apr 17, 2021 at 9:49 AM Pali Roh?r <pali at kernel.org> wrote:
>
> On Thursday 15 April 2021 10:13:17 Rob Herring wrote:
> > On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun at nic.cz> wrote:
> > >
> > > On Thu, 15 Apr 2021 10:36:40 +0200
> > > Pali Roh?r <pali at kernel.org> wrote:
> > >
> > > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > > > On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
> > > > > >
> > > > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > > > > function and allow to build it as module") PCIe controller driver for
> > > > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > > > > > allows dynamic binding and unbinding of PCIe controller device.
> > > > > >
> > > > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > > > > number (starting from zero) for this PCIe controller every time when device
> > > > > > is bound. So PCI domain changes after every unbind / bind operation.
> > > > >
> > > > > PCI host bridges as a module are relatively new, so seems likely a bug to me.
> > > >
> > > > Why a bug? It is there since 5.10 and it is working.
> >
> > I mean historically, the PCI subsystem didn't even support host
> > bridges as a module. They weren't even proper drivers and it was all
> > arch specific code. Most of the host bridge drivers are still built-in
> > only. This seems like a small detail that was easily overlooked.
> > unbind is not a well tested path.
>
> Ok! Just to note that during my testing I have not spotted any issue.
>
> > > > > > Alternative way for assigning PCI domain number is to use static allocated
> > > > > > numbers defined in Device Tree. This option has requirement that every PCI
> > > > > > controller in system must have defined PCI bus number in Device Tree.
> > > > >
> > > > > That seems entirely pointless from a DT point of view with a single PCI bridge.
> > > >
> > > > If domain id is not specified in DT then kernel uses counter and assigns
> > > > counter++. So it is not pointless if we want to have stable domain id.
> > >
> > > What Rob is trying to say is that
> > > - the bug is that kernel assigns counter++
> > > - device-tree should not be used to fix problems with how kernel does
> > >   things
> > > - if a device has only one PCIe controller, it is pointless to define
> > >   it's pci-domain. If there were multiple controllers, then it would
> > >   make sense, but there is only one
> >
> > Yes. I think what we want here is a domain bitmap rather than a
> > counter and we assign the lowest free bit. That could also allow for
> > handling a mixture of fixed domain numbers and dynamically assigned
> > ones.
>
> Currently this code is implemented in pci_bus_find_domain_nr() function.
> IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> of memory. I'm not sure if it is fine or some other tree-based structure
> for allocated domain numbers is needed.

It's an atomic_t but then shortened (potentially) to an 'int'. Surely
we don't need 8k (or 2^31) host bridges? Seems like we could start
with 64 and bump it as needed. Or the idr route is another option if
that works. We'd need to get the lowest free value and be able to
reserve values (when specified by firmware).

> > You could create scenarios where the numbers change on you, but it
> > wouldn't be any different than say plugging in USB serial adapters.
> > You get the same ttyUSBx device when you re-attach unless there's been
> > other ttyUSBx devices attached/detached.
>
> This should be fine for most scenarios. Dynamically attaching /
> detaching PCI domain is not such common action...
>
> Will you implement this new feature?

Yes, after I find a DT binding co-maintainer.

Rob


From catalin.marinas at arm.com  Fri Apr 23 16:37:02 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 16:37:02 +0100
Subject: [PATCH] arm64:align function __arch_clear_user
In-Reply-To: <6829062c-a2d4-57da-4037-269fb7508993@huawei.com>
References: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
 <20210414104144.GB8320@arm.com>
 <6829062c-a2d4-57da-4037-269fb7508993@huawei.com>
Message-ID: <20210423153701.GP18757@arm.com>

On Mon, Apr 19, 2021 at 10:05:16AM +0800, Kai Shen wrote:
> On 2021/4/14 18:41, Catalin Marinas wrote:
> > On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
> > > Performance decreases happen in __arch_clear_user when this
> > > function is not correctly aligned on HISI-HIP08 arm64 SOC which
> > > fetches 32 bytes (8 instructions) from icache with a 32-bytes
> > > aligned end address. As a result, if the hot loop is not 32-bytes
> > > aligned, it may take more icache fetches which leads to decrease
> > > in performance.
> > > Dump of assembler code for function __arch_clear_user:
> > >         0xffff0000809e3f10 :    nop
> > >         0xffff0000809e3f14 :    mov x2, x1
> > >         0xffff0000809e3f18 :    subs x1, x1, #0x8
> > >         0xffff0000809e3f1c :    b.mi 0xffff0000809e3f30 <__arch_clear_user+3
> > > -----  0xffff0000809e3f20 :    str    xzr, [x0],#8
> > > hot    0xffff0000809e3f24 :    nop
> > > loop   0xffff0000809e3f28 :    subs x1, x1, #0x8
> > > -----  0xffff0000809e3f2c :    b.pl  0xffff0000809e3f20 <__arch_clear_user+1
> > > The hot loop above takes one icache fetch as the code is in one
> > > 32-bytes aligned area and the loop takes one more icache fetch
> > > when it is not aligned like below.
> > >         0xffff0000809e4178 :   str    xzr, [x0],#8
> > >         0xffff0000809e417c :   nop
> > >         0xffff0000809e4180 :   subs x1, x1, #0x8
> > >         0xffff0000809e4184 :   b.pl  0xffff0000809e4178 <__arch_clear_user+
> > > Data collected by perf:
> > >                           aligned   not aligned
> > >            instructions   57733790     57739065
> > >         L1-dcache-store   14938070     13718242
> > > L1-dcache-store-misses     349280       349869
> > >         L1-icache-loads   15380895     28500665
> > > As we can see, L1-icache-loads almost double when the loop is not
> > > aligned.
> > > This problem is found in linux 4.19 on HISI-HIP08 arm64 SOC.
> > > Not sure what the case is on other arm64 SOC, but it should do
> > > no harm.
> > > Signed-off-by: Kai Shen <shenkai8 at huawei.com>
> > 
> > Do you have a real world workload that's affected by this function?
> > 
> > I'm against adding alignments and nops for specific hardware
> > implementations. What about lots of other loops that the compiler may
> > generate or that we wrote in asm?
>
> The benchmark we used which suffer performance decrease:
>     https://github.com/redhat-performance/libMicro
>     pread $OPTS -N "pread_z1k"    -s 1k    -I 300  -f /dev/zero
>     pread $OPTS -N "pread_z10k"    -s 10k    -I 1000 -f /dev/zero
>     pread $OPTS -N "pread_z100k"    -s 100k    -I 2000 -f /dev/zero

Is there any real world use-case that would benefit from this
optimisation? Reading /dev/zero in a loop hardly counts as a practical
workload.

-- 
Catalin


From f.fainelli at gmail.com  Fri Apr 23 16:45:41 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 23 Apr 2021 08:45:41 -0700
Subject: [PATCH] mips/bcm63xx: Use BUG_ON instead of if condition followed
 by BUG
In-Reply-To: <1619166623-70445-1-git-send-email-zhouchuangao@vivo.com>
References: <1619166623-70445-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <800fd777-dc61-07e0-bc13-bb95a0924335@gmail.com>



On 4/23/2021 1:30 AM, zhouchuangao wrote:
> BUG_ON uses unlikely in if(), it can be optimized at compile time.
> 
> Usually, the condition in if() is not satisfied. In my opinion,
> this can improve the efficiency of the multi-stage pipeline.
> 
> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>

Acked-by: Florian Fainelli <f.fainelli at gmail.com>

Subject prefix should have been: MIPS: BCM63XX: Use BUG_ON instead of
condition followed by BUG to match prior submissions done to this
directory. Thanks.
-- 
Florian


From andy.shevchenko at gmail.com  Fri Apr 23 16:53:58 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 18:53:58 +0300
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
Message-ID: <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>

On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
<lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
>
> Adding pinctrl driver for Xilinx ZynqMP platform.
> This driver queries pin information from firmware and registers
> pin control accordingly.
>
> Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>

You may reduce the number of LOCs by joining some lines. See below.

...

> +config PINCTRL_ZYNQMP
> +       tristate "Pinctrl driver for Xilinx ZynqMP"
> +       depends on ZYNQMP_FIRMWARE
> +       select PINMUX
> +       select GENERIC_PINCONF
> +       default ZYNQMP_FIRMWARE
> +       help
> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> +         This driver will query the pin information from the firmware
> +         and allow configuring the pins.
> +         Configuration can include the mux function to select on those
> +         pin(s)/group(s), and various pin configuration parameters
> +         such as pull-up, slew rate, etc.

Missed module name.

...

> +/*
> + * ZynqMP pin controller
> + *
> + * Copyright (C) 2020 Xilinx, Inc.

2021?

> + *
> + * Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
> + * Rajan Vaja <rajan.vaja at xilinx.com>
> + */

...

> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/firmware/xlnx-zynqmp.h>

...

> +static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
> +                                 unsigned int pin,
> +                                 unsigned long *config)
> +{
> +       unsigned int arg, param = pinconf_to_config_param(*config);
> +       int ret;

> +       if (pin >= zynqmp_desc.npins)
> +               return -EOPNOTSUPP;

Is it possible?

> +       switch (param) {
> +       case PIN_CONFIG_SLEW_RATE:
> +               param = PM_PINCTRL_CONFIG_SLEW_RATE;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_BIAS_PULL_UP:
> +               param = PM_PINCTRL_CONFIG_PULL_CTRL;

> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               if (arg != PM_PINCTRL_BIAS_PULL_UP)
> +                       return -EINVAL;

Error code being shadowed. Instead check it here properly.

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_BIAS_PULL_DOWN:
> +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
> +                       return -EINVAL;

Ditto.

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_BIAS_DISABLE:
> +               param = PM_PINCTRL_CONFIG_BIAS_STATUS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               if (arg != PM_PINCTRL_BIAS_DISABLE)
> +                       return -EINVAL;

Ditto.

> +               arg = 1;
> +               break;
> +       case PIN_CONFIG_POWER_SOURCE:
> +               param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> +               param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               break;
> +       case PIN_CONFIG_DRIVE_STRENGTH:
> +               param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
> +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> +               switch (arg) {
> +               case PM_PINCTRL_DRIVE_STRENGTH_2MA:
> +                       arg = DRIVE_STRENGTH_2MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_4MA:
> +                       arg = DRIVE_STRENGTH_4MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_8MA:
> +                       arg = DRIVE_STRENGTH_8MA;
> +                       break;
> +               case PM_PINCTRL_DRIVE_STRENGTH_12MA:
> +                       arg = DRIVE_STRENGTH_12MA;
> +                       break;
> +               default:
> +                       /* Invalid drive strength */
> +                       dev_warn(pctldev->dev,
> +                                "Invalid drive strength for pin %d\n",
> +                                pin);
> +                       return -EINVAL;
> +               }
> +               break;
> +       default:
> +               ret = -EOPNOTSUPP;
> +               break;
> +       }
> +
> +       if (ret)
> +               return ret;
> +
> +       param = pinconf_to_config_param(*config);
> +       *config = pinconf_to_config_packed(param, arg);
> +
> +       return 0;
> +}

...

> +                       ret = -EOPNOTSUPP;

Isn't it ENOTSUP for all cases here?

...

> +       ret = zynqmp_pm_query_data(qdata, payload);
> +       if (ret)
> +               return ret;
> +
> +       *ngroups = payload[1];
> +

> +       return ret;

return 0;

...

> + * Query firmware to get group IDs for each function. Firmware returns
> + * group IDs. Based on group index for the function, group names in

on the group

> + * the function are stored. For example, the first group in "eth0" function
> + * is named as "eth0_0" and second group as "eth0_1" and so on.

and the second

> + *
> + * Based on the group ID received from the firmware, function stores name of
> + * the group for that group ID. For example, if "eth0" first group ID
> + * is x, groups[x] name will be stored as "eth0_0".
> + *
> + * Once done for each function, each function would have its group names
> + * and each groups would also have their names.

each group

...

> +done:
> +       func->groups = fgroups;
> +
> +       return ret;

return 0; ?

...

> +       *nfuncs = payload[1];
> +
> +       return ret;

Ditto.

...

> +       ret = zynqmp_pm_query_data(qdata, payload);
> +       if (ret)
> +               return ret;
> +
> +       memcpy(groups, &payload[1], PINCTRL_GET_PIN_GROUPS_RESP_LEN);
> +
> +       return ret;

Ditto.

...

> + * Query firmware to get groups available for the given pin.
> + * Based on the firmware response(group IDs for the pin), add
> + * pin number to the respective group's pin array.
> + *
> + * Once all pins are queries, each groups would have its number

each group

> + * of pins and pin numbers data.

...

> +       return ret;

return 0;

...

> + * Query number of functions and number of function groups (number
> + * of groups in given function) to allocate required memory buffers

in the given

> + * for functions and groups. Once buffers are allocated to store
> + * functions and groups data, query and store required information
> + * (number of groups and group names for each function, number of
> + * pins and pin numbers for each group).

...

> +       pctrl->funcs = funcs;
> +       pctrl->groups = groups;
> +
> +       return ret;

return 0;

...

> +       *npins = payload[1];
> +
> +       return ret;

Ditto.

...

> +               dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
> +                       ret);

One line.

...

> +               dev_err(&pdev->dev, "function info prepare fail with %d\n",
> +                       ret);

Ditto.

...

> +       pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);

devm_pinctrl_register()

> +       if (IS_ERR(pctrl->pctrl))
> +               return PTR_ERR(pctrl->pctrl);

...

> +};

> +

Extra blank line.

> +MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);

...

> +};

> +

Ditto.

> +module_platform_driver(zynqmp_pinctrl_driver);

-- 
With Best Regards,
Andy Shevchenko


From andy.shevchenko at gmail.com  Fri Apr 23 16:54:59 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 18:54:59 +0300
Subject: [PATCH v6 0/3] Add ZynqMP pinctrl driver
In-Reply-To: <CACRpkdaDP+JnCP+go9hZAObnNgmJyJRDFypX2CZGp-UJBh5wNA@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CACRpkdaDP+JnCP+go9hZAObnNgmJyJRDFypX2CZGp-UJBh5wNA@mail.gmail.com>
Message-ID: <CAHp75VfpvPdAAW2JpvdiDtzS3LUF_=Ej7c2LEML_+pOwi6CtWg@mail.gmail.com>

On Thu, Apr 22, 2021 at 12:14 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Thu, Apr 22, 2021 at 10:30 AM Sai Krishna Potthuri
> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
>
> > changes in v6:
> > - Rebased the patche series on 'devel' branch in pinctrl tree and no
> > functional changes.
>
> Remaining patches applied! Thanks for working so hard on this!

Hmm... I have had a bunch of comments. Okay, they may be addressed by
follow up(s).

-- 
With Best Regards,
Andy Shevchenko


From broonie at kernel.org  Fri Apr 23 17:20:55 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 17:20:55 +0100
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <672e8d77-ee5c-f10f-0bd3-f8708dfc24c8@devtank.co.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
 <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
 <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>
 <20210423115724.GB5507@sirena.org.uk>
 <672e8d77-ee5c-f10f-0bd3-f8708dfc24c8@devtank.co.uk>
Message-ID: <20210423162055.GE5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 03:12:11PM +0100, Joe Burmeister wrote:
> On 23/04/2021 12:57, Mark Brown wrote:

> > I wouldn't expect any controller to be OK with that?  Drivers can store
> > per-client data in spi_device->controller_data which doesn't need
> > scaling (but is also not so helpful if you need to look at clients other
> > than the one you're currently controlling).

> I can see a number which certainly wouldn't. Though I don't want to
> assume that all don't.

Yeah, some won't - some do also rely on system specific assumptions
about what's possible but there's not really mechanisms for declaring
that.

> If we are happy just not letting the core expand num_chipselect that
> does stop the condition on everything.

> Any controller that can go higher without issue could them have their
> num_chipselect set to what their real limit is if this enforcement
> causes an issue.

Part of the issue here is that there has been some variation in how
num_chipselect is interpreted with regard to GPIO based chip selects
over time.  It *should* be redundant, I'm not clear why it's in the
generic bindings at all but that's lost to history AFAICT.

> >>> Not sure I follow you, if we have the overlay before
> >>> spi_register_controller() is called, how can the check there not
> >>> trigger? And if we load the overlay later when the SPI controller is
> >>> already registered, why does not spi_add_device()'s check work?

> >> I think it might be a RPI thing. I think it is merging in the overlay
> >> and giving Linux one already merged.

> > If the overlay is handled by the bootloader then from the point of view
> > of Linux there is no overlay - sounds like there's an issue in the
> > overlay, it should be overriding something that it doesn't?

> Does it matter if the final device tree was compiled like that in the
> first place or merge into that by the bootloader?

It matters in the context of a discussion of ordering between loading
the overlay and spi_register_controller() - it's clearly not loaded
afterwards.

> Of course we could just raise BCM2835_SPI_NUM_CS to 8 or more if that is
> preferred. Does seams like the dynamic solution is less favoured.

The best thing would be to have it not have a single array of chip
select specific data and instead store everything in the controller_data
that's there per-device.
-------------- 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/20210423/05caf598/attachment.sig>

From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:25 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:25 +0300
Subject: [PATCH v1 02/14] spi: pxa2xx: Utilize MMIO and physical base from
 struct ssp_device
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-2-andriy.shevchenko@linux.intel.com>

We have a duplication of MMIO and physical base addresses in
the struct driver_data, get rid of it and reuse members from
struct ssp_device instead.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c |  4 ++--
 drivers/spi/spi-pxa2xx.c     |  4 +---
 drivers/spi/spi-pxa2xx.h     | 14 ++++----------
 3 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 37567bc7a523..3b27f356a18f 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -94,14 +94,14 @@ pxa2xx_spi_dma_prepare_one(struct driver_data *drv_data,
 	cfg.direction = dir;
 
 	if (dir == DMA_MEM_TO_DEV) {
-		cfg.dst_addr = drv_data->ssdr_physical;
+		cfg.dst_addr = drv_data->ssp->phys_base + SSDR;
 		cfg.dst_addr_width = width;
 		cfg.dst_maxburst = chip->dma_burst_size;
 
 		sgt = &xfer->tx_sg;
 		chan = drv_data->controller->dma_tx;
 	} else {
-		cfg.src_addr = drv_data->ssdr_physical;
+		cfg.src_addr = drv_data->ssp->phys_base + SSDR;
 		cfg.src_addr_width = width;
 		cfg.src_maxburst = chip->dma_burst_size;
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0ef22045b006..82df028c4a71 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -325,7 +325,7 @@ static void lpss_ssp_setup(struct driver_data *drv_data)
 	u32 value;
 
 	config = lpss_get_config(drv_data);
-	drv_data->lpss_base = drv_data->ioaddr + config->offset;
+	drv_data->lpss_base = drv_data->ssp->mmio_base + config->offset;
 
 	/* Enable software chip select control */
 	value = __lpss_ssp_read_priv(drv_data, config->reg_cs_ctrl);
@@ -1729,8 +1729,6 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 
 	drv_data->ssp_type = ssp->type;
 
-	drv_data->ioaddr = ssp->mmio_base;
-	drv_data->ssdr_physical = ssp->phys_base + SSDR;
 	if (pxa25x_ssp_comp(drv_data)) {
 		switch (drv_data->ssp_type) {
 		case QUARK_X1000_SSP:
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 1400472bc986..ad9980ebefa6 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -33,10 +33,6 @@ struct driver_data {
 	/* PXA hookup */
 	struct pxa2xx_spi_controller *controller_info;
 
-	/* SSP register addresses */
-	void __iomem *ioaddr;
-	phys_addr_t ssdr_physical;
-
 	/* SSP masks*/
 	u32 dma_cr1;
 	u32 int_cr1;
@@ -87,16 +83,14 @@ struct chip_data {
 	void (*cs_control)(u32 command);
 };
 
-static inline u32 pxa2xx_spi_read(const struct driver_data *drv_data,
-				  unsigned reg)
+static inline u32 pxa2xx_spi_read(const struct driver_data *drv_data, u32 reg)
 {
-	return __raw_readl(drv_data->ioaddr + reg);
+	return pxa_ssp_read_reg(drv_data->ssp, reg);
 }
 
-static  inline void pxa2xx_spi_write(const struct driver_data *drv_data,
-				     unsigned reg, u32 val)
+static inline void pxa2xx_spi_write(const struct driver_data *drv_data, u32 reg, u32 val)
 {
-	__raw_writel(val, drv_data->ioaddr + reg);
+	pxa_ssp_write_reg(drv_data->ssp, reg, val);
 }
 
 #define DMA_ALIGNMENT		8
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:24 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:24 +0300
Subject: [PATCH v1 01/14] spi: pxa2xx: Use one point of return when ->probe()
 fails
Message-ID: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>

When we can't allocate SPI controller, jump to the error path rather than
return locally.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0cc767283674..0ef22045b006 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1701,8 +1701,8 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 
 	if (!controller) {
 		dev_err(&pdev->dev, "cannot alloc spi_controller\n");
-		pxa_ssp_free(ssp);
-		return -ENOMEM;
+		status = -ENOMEM;
+		goto out_error_controller_alloc;
 	}
 	drv_data = spi_controller_get_devdata(controller);
 	drv_data->controller = controller;
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:30 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:30 +0300
Subject: [PATCH v1 07/14] spi: pxa2xx: Introduce int_stop_and_reset() helper
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-7-andriy.shevchenko@linux.intel.com>

Currently we have three times the same few lines repeated in the code.
Deduplicate them by newly introduced int_stop_and_reset() helper.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0296cbdee848..4dab47e18d10 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -620,13 +620,20 @@ static void reset_sccr1(struct driver_data *drv_data)
 	pxa2xx_spi_write(drv_data, SSCR1, sccr1_reg);
 }
 
-static void int_error_stop(struct driver_data *drv_data, const char* msg)
+static void int_stop_and_reset(struct driver_data *drv_data)
 {
-	/* Stop and reset SSP */
+	/* Clear and disable interrupts */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	if (pxa25x_ssp_comp(drv_data))
+		return;
+
+	pxa2xx_spi_write(drv_data, SSTO, 0);
+}
+
+static void int_error_stop(struct driver_data *drv_data, const char *msg)
+{
+	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
@@ -638,11 +645,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 
 static void int_transfer_complete(struct driver_data *drv_data)
 {
-	/* Clear and disable interrupts */
-	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	int_stop_and_reset(drv_data);
 
 	spi_finalize_current_transfer(drv_data->controller);
 }
@@ -1151,11 +1154,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	/* Stop and reset SSP */
-	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:26 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:26 +0300
Subject: [PATCH v1 03/14] spi: pxa2xx: Utilize struct device from struct
 ssp_device
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-3-andriy.shevchenko@linux.intel.com>

We have a duplication of struct device in the struct driver_data,
get rid of it and reuse member from struct ssp_device instead.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c | 12 +++++-------
 drivers/spi/spi-pxa2xx-pci.c |  1 +
 drivers/spi/spi-pxa2xx.c     | 12 +++++-------
 drivers/spi/spi-pxa2xx.h     |  4 ----
 4 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 3b27f356a18f..2e4a49567146 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -111,7 +111,7 @@ pxa2xx_spi_dma_prepare_one(struct driver_data *drv_data,
 
 	ret = dmaengine_slave_config(chan, &cfg);
 	if (ret) {
-		dev_warn(&drv_data->pdev->dev, "DMA slave config failed\n");
+		dev_warn(drv_data->ssp->dev, "DMA slave config failed\n");
 		return NULL;
 	}
 
@@ -125,7 +125,7 @@ irqreturn_t pxa2xx_spi_dma_transfer(struct driver_data *drv_data)
 
 	status = pxa2xx_spi_read(drv_data, SSSR) & drv_data->mask_sr;
 	if (status & SSSR_ROR) {
-		dev_err(&drv_data->pdev->dev, "FIFO overrun\n");
+		dev_err(drv_data->ssp->dev, "FIFO overrun\n");
 
 		dmaengine_terminate_async(drv_data->controller->dma_rx);
 		dmaengine_terminate_async(drv_data->controller->dma_tx);
@@ -145,16 +145,14 @@ int pxa2xx_spi_dma_prepare(struct driver_data *drv_data,
 
 	tx_desc = pxa2xx_spi_dma_prepare_one(drv_data, DMA_MEM_TO_DEV, xfer);
 	if (!tx_desc) {
-		dev_err(&drv_data->pdev->dev,
-			"failed to get DMA TX descriptor\n");
+		dev_err(drv_data->ssp->dev, "failed to get DMA TX descriptor\n");
 		err = -EBUSY;
 		goto err_tx;
 	}
 
 	rx_desc = pxa2xx_spi_dma_prepare_one(drv_data, DMA_DEV_TO_MEM, xfer);
 	if (!rx_desc) {
-		dev_err(&drv_data->pdev->dev,
-			"failed to get DMA RX descriptor\n");
+		dev_err(drv_data->ssp->dev, "failed to get DMA RX descriptor\n");
 		err = -EBUSY;
 		goto err_rx;
 	}
@@ -191,8 +189,8 @@ void pxa2xx_spi_dma_stop(struct driver_data *drv_data)
 int pxa2xx_spi_dma_setup(struct driver_data *drv_data)
 {
 	struct pxa2xx_spi_controller *pdata = drv_data->controller_info;
-	struct device *dev = &drv_data->pdev->dev;
 	struct spi_controller *controller = drv_data->controller;
+	struct device *dev = drv_data->ssp->dev;
 	dma_cap_mask_t mask;
 
 	dma_cap_zero(mask);
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 14fc41ed2361..f60ed4c62000 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -239,6 +239,7 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
 	spi_pdata.dma_burst_size = c->dma_burst_size ? c->dma_burst_size : 1;
 
 	ssp = &spi_pdata.ssp;
+	ssp->dev = &dev->dev;
 	ssp->phys_base = pci_resource_start(dev, 0);
 	ssp->mmio_base = pcim_iomap_table(dev)[0];
 	ssp->port_id = (c->port_id >= 0) ? c->port_id : dev->devfn;
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 82df028c4a71..e9dddcbd92f1 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -628,7 +628,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-	dev_err(&drv_data->pdev->dev, "%s\n", msg);
+	dev_err(drv_data->ssp->dev, "%s\n", msg);
 
 	drv_data->controller->cur_msg->status = -EIO;
 	spi_finalize_current_transfer(drv_data->controller);
@@ -731,8 +731,7 @@ static void handle_bad_msg(struct driver_data *drv_data)
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 
-	dev_err(&drv_data->pdev->dev,
-		"bad message state in interrupt handler\n");
+	dev_err(drv_data->ssp->dev, "bad message state in interrupt handler\n");
 }
 
 static irqreturn_t ssp_int(int irq, void *dev_id)
@@ -748,7 +747,7 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
 	 * the IRQ was not for us (we shouldn't be RPM suspended when the
 	 * interrupt is enabled).
 	 */
-	if (pm_runtime_suspended(&drv_data->pdev->dev))
+	if (pm_runtime_suspended(drv_data->ssp->dev))
 		return IRQ_NONE;
 
 	/*
@@ -1158,7 +1157,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-	dev_dbg(&drv_data->pdev->dev, "transfer aborted\n");
+	dev_dbg(drv_data->ssp->dev, "transfer aborted\n");
 
 	drv_data->controller->cur_msg->status = -EINTR;
 	spi_finalize_current_transfer(drv_data->controller);
@@ -1641,7 +1640,7 @@ static int pxa2xx_spi_fw_translate_cs(struct spi_controller *controller,
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	if (has_acpi_companion(&drv_data->pdev->dev)) {
+	if (has_acpi_companion(drv_data->ssp->dev)) {
 		switch (drv_data->ssp_type) {
 		/*
 		 * For Atoms the ACPI DeviceSelection used by the Windows
@@ -1707,7 +1706,6 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 	drv_data = spi_controller_get_devdata(controller);
 	drv_data->controller = controller;
 	drv_data->controller_info = platform_info;
-	drv_data->pdev = pdev;
 	drv_data->ssp = ssp;
 
 	controller->dev.of_node = pdev->dev.of_node;
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index ad9980ebefa6..6724d7e056ce 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
-#include <linux/platform_device.h>
 #include <linux/pxa2xx_ssp.h>
 #include <linux/scatterlist.h>
 #include <linux/sizes.h>
@@ -20,9 +19,6 @@
 #include <linux/spi/pxa2xx_spi.h>
 
 struct driver_data {
-	/* Driver model hookup */
-	struct platform_device *pdev;
-
 	/* SSP Info */
 	struct ssp_device *ssp;
 
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:34 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:34 +0300
Subject: [PATCH v1 11/14] spi: pxa2xx: Extract clear_SSCR1_bits() helper
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-11-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "clear some bits in SSCR1".
Extract clear_SSCR1_bits() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c | 4 +---
 drivers/spi/spi-pxa2xx.c     | 7 ++-----
 drivers/spi/spi-pxa2xx.h     | 5 +++++
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 5ca01ad7f460..e581027e99f9 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -41,9 +41,7 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 		}
 
 		/* Clear status & disable interrupts */
-		pxa2xx_spi_write(drv_data, SSCR1,
-				 pxa2xx_spi_read(drv_data, SSCR1)
-				 & ~drv_data->dma_cr1);
+		clear_SSCR1_bits(drv_data, drv_data->dma_cr1);
 		write_SSSR_CS(drv_data, drv_data->clear_sr);
 		if (!pxa25x_ssp_comp(drv_data))
 			pxa2xx_spi_write(drv_data, SSTO, 0);
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4b3237f14ead..58178ba704dc 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -733,8 +733,7 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 static void handle_bad_msg(struct driver_data *drv_data)
 {
 	pxa2xx_spi_off(drv_data);
-	pxa2xx_spi_write(drv_data, SSCR1,
-			 pxa2xx_spi_read(drv_data, SSCR1) & ~drv_data->int_cr1);
+	clear_SSCR1_bits(drv_data, drv_data->int_cr1);
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
@@ -1161,9 +1160,7 @@ static void pxa2xx_spi_handle_err(struct spi_controller *controller,
 	pxa2xx_spi_off(drv_data);
 	/* Clear and disable interrupts and service requests */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	pxa2xx_spi_write(drv_data, SSCR1,
-			 pxa2xx_spi_read(drv_data, SSCR1)
-			 & ~(drv_data->int_cr1 | drv_data->dma_cr1));
+	clear_SSCR1_bits(drv_data, drv_data->int_cr1 | drv_data->dma_cr1);
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index b6dae0981b61..398dbd680208 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -105,6 +105,11 @@ static inline int pxa25x_ssp_comp(struct driver_data *drv_data)
 	}
 }
 
+static inline void clear_SSCR1_bits(const struct driver_data *drv_data, u32 bits)
+{
+	pxa2xx_spi_write(drv_data, SSCR1, pxa2xx_spi_read(drv_data, SSCR1) & ~bits);
+}
+
 static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:27 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:27 +0300
Subject: [PATCH v1 04/14] spi: pxa2xx: Replace header inclusions by forward
 declarations
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-4-andriy.shevchenko@linux.intel.com>

When the data structure is only referred by pointer, compiler may not need
to see the contents of the data type. Thus, we may replace header inclusions
by respective forward declarations. Due to above add missed headers as well.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c   |  6 ++++--
 drivers/spi/spi-pxa2xx.c       |  2 ++
 drivers/spi/spi-pxa2xx.h       | 18 ++++++++++--------
 include/linux/spi/pxa2xx_spi.h |  2 ++
 4 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 2e4a49567146..32ab7391396d 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -9,11 +9,13 @@
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/dmaengine.h>
-#include <linux/pxa2xx_ssp.h>
 #include <linux/scatterlist.h>
 #include <linux/sizes.h>
-#include <linux/spi/spi.h>
+
 #include <linux/spi/pxa2xx_spi.h>
+#include <linux/spi/spi.h>
+
+#include <linux/pxa2xx_ssp.h>
 
 #include "spi-pxa2xx.h"
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e9dddcbd92f1..0296cbdee848 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -9,6 +9,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/dmaengine.h>
 #include <linux/err.h>
 #include <linux/errno.h>
 #include <linux/gpio/consumer.h>
@@ -25,6 +26,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/property.h>
 #include <linux/slab.h>
+
 #include <linux/spi/pxa2xx_spi.h>
 #include <linux/spi/spi.h>
 
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 6724d7e056ce..739e264feaa6 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -7,16 +7,18 @@
 #ifndef SPI_PXA2XX_H
 #define SPI_PXA2XX_H
 
-#include <linux/atomic.h>
-#include <linux/dmaengine.h>
-#include <linux/errno.h>
-#include <linux/io.h>
 #include <linux/interrupt.h>
-#include <linux/pxa2xx_ssp.h>
-#include <linux/scatterlist.h>
+#include <linux/io.h>
+#include <linux/types.h>
 #include <linux/sizes.h>
-#include <linux/spi/spi.h>
-#include <linux/spi/pxa2xx_spi.h>
+
+#include <linux/pxa2xx_ssp.h>
+
+struct gpio_desc;
+struct pxa2xx_spi_controller;
+struct spi_controller;
+struct spi_device;
+struct spi_transfer;
 
 struct driver_data {
 	/* SSP Info */
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
index 31f00c7f4f59..1e0e2f136319 100644
--- a/include/linux/spi/pxa2xx_spi.h
+++ b/include/linux/spi/pxa2xx_spi.h
@@ -5,6 +5,8 @@
 #ifndef __linux_pxa2xx_spi_h
 #define __linux_pxa2xx_spi_h
 
+#include <linux/types.h>
+
 #include <linux/pxa2xx_ssp.h>
 
 #define PXA2XX_CS_ASSERT (0x01)
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:29 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:29 +0300
Subject: [PATCH v1 06/14] spi: pxa2xx: Group Intel Quark specific definitions
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-6-andriy.shevchenko@linux.intel.com>

DDS_RATE is Intel Quark specific definition. Move it to the rest
Intel Quark related.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 include/linux/spi/pxa2xx_ssp.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/spi/pxa2xx_ssp.h b/include/linux/spi/pxa2xx_ssp.h
index 14b049840faf..1b6c1a0922bd 100644
--- a/include/linux/spi/pxa2xx_ssp.h
+++ b/include/linux/spi/pxa2xx_ssp.h
@@ -38,7 +38,6 @@ struct device_node;
 #define SSDR		(0x10)  /* SSP Data Write/Data Read Register */
 
 #define SSTO		(0x28)  /* SSP Time Out Register */
-#define DDS_RATE	(0x28)  /* SSP DDS Clock Rate Register (Intel Quark) */
 #define SSPSP		(0x2C)  /* SSP Programmable Serial Protocol */
 #define SSTSA		(0x30)  /* SSP Tx Timeslot Active */
 #define SSRSA		(0x34)  /* SSP Rx Timeslot Active */
@@ -105,6 +104,9 @@ struct device_node;
 #define CE4100_SSCR1_RFT	GENMASK(11, 10)	/* Receive FIFO Threshold (mask) */
 #define CE4100_SSCR1_RxTresh(x) (((x) - 1) << 10)	/* level [1..4] */
 
+/* Intel Quark X1000 */
+#define DDS_RATE		0x28		 /* SSP DDS Clock Rate Register */
+
 /* QUARK_X1000 SSCR0 bit definition */
 #define QUARK_X1000_SSCR0_DSS		GENMASK(4, 0)	/* Data Size Select (mask) */
 #define QUARK_X1000_SSCR0_DataSize(x)	((x) - 1)	/* Data Size Select [4..32] */
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:31 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:31 +0300
Subject: [PATCH v1 08/14] spi: pxa2xx: Reuse int_error_stop() in
 pxa2xx_spi_slave_abort()
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-8-andriy.shevchenko@linux.intel.com>

It appears that pxa2xx_spi_slave_abort()almost  repeats the functionality
of the int_error_stop(). Reuse int_error_stop() in pxa2xx_spi_slave_abort().

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4dab47e18d10..85a8d228a117 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -631,7 +631,7 @@ static void int_stop_and_reset(struct driver_data *drv_data)
 	pxa2xx_spi_write(drv_data, SSTO, 0);
 }
 
-static void int_error_stop(struct driver_data *drv_data, const char *msg)
+static void int_error_stop(struct driver_data *drv_data, const char *msg, int err)
 {
 	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
@@ -639,7 +639,7 @@ static void int_error_stop(struct driver_data *drv_data, const char *msg)
 
 	dev_err(drv_data->ssp->dev, "%s\n", msg);
 
-	drv_data->controller->cur_msg->status = -EIO;
+	drv_data->controller->cur_msg->status = err;
 	spi_finalize_current_transfer(drv_data->controller);
 }
 
@@ -658,12 +658,12 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 	u32 irq_status = pxa2xx_spi_read(drv_data, SSSR) & irq_mask;
 
 	if (irq_status & SSSR_ROR) {
-		int_error_stop(drv_data, "interrupt_transfer: fifo overrun");
+		int_error_stop(drv_data, "interrupt_transfer: fifo overrun", -EIO);
 		return IRQ_HANDLED;
 	}
 
 	if (irq_status & SSSR_TUR) {
-		int_error_stop(drv_data, "interrupt_transfer: fifo underrun");
+		int_error_stop(drv_data, "interrupt_transfer: fifo underrun", -EIO);
 		return IRQ_HANDLED;
 	}
 
@@ -1154,14 +1154,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	int_stop_and_reset(drv_data);
-	pxa2xx_spi_flush(drv_data);
-	pxa2xx_spi_off(drv_data);
-
-	dev_dbg(drv_data->ssp->dev, "transfer aborted\n");
-
-	drv_data->controller->cur_msg->status = -EINTR;
-	spi_finalize_current_transfer(drv_data->controller);
+	int_error_stop(drv_data, "transfer aborted", -EINTR);
 
 	return 0;
 }
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:33 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:33 +0300
Subject: [PATCH v1 10/14] spi: pxa2xx: Extract pxa2xx_spi_update() helper
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-10-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "update if changed".
Extract pxa2xx_spi_update() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 33 ++++++++++++++-------------------
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index f85c7439757c..4b3237f14ead 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -200,6 +200,12 @@ static bool is_mmp2_ssp(const struct driver_data *drv_data)
 	return drv_data->ssp_type == MMP2_SSP;
 }
 
+static void pxa2xx_spi_update(const struct driver_data *drv_data, u32 reg, u32 mask, u32 value)
+{
+	if ((pxa2xx_spi_read(drv_data, reg) & mask) != value)
+		pxa2xx_spi_write(drv_data, reg, value & mask);
+}
+
 static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data *drv_data)
 {
 	switch (drv_data->ssp_type) {
@@ -1081,19 +1087,12 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 			dma_mapped ? "DMA" : "PIO");
 
 	if (is_lpss_ssp(drv_data)) {
-		if ((pxa2xx_spi_read(drv_data, SSIRF) & 0xff)
-		    != chip->lpss_rx_threshold)
-			pxa2xx_spi_write(drv_data, SSIRF,
-					 chip->lpss_rx_threshold);
-		if ((pxa2xx_spi_read(drv_data, SSITF) & 0xffff)
-		    != chip->lpss_tx_threshold)
-			pxa2xx_spi_write(drv_data, SSITF,
-					 chip->lpss_tx_threshold);
+		pxa2xx_spi_update(drv_data, SSIRF, GENMASK(7, 0), chip->lpss_rx_threshold);
+		pxa2xx_spi_update(drv_data, SSITF, GENMASK(15, 0), chip->lpss_tx_threshold);
 	}
 
-	if (is_quark_x1000_ssp(drv_data) &&
-	    (pxa2xx_spi_read(drv_data, DDS_RATE) != chip->dds_rate))
-		pxa2xx_spi_write(drv_data, DDS_RATE, chip->dds_rate);
+	if (is_quark_x1000_ssp(drv_data))
+		pxa2xx_spi_update(drv_data, DDS_RATE, GENMASK(23, 0), chip->dds_rate);
 
 	/* Stop the SSP */
 	if (!is_mmp2_ssp(drv_data))
@@ -1102,15 +1101,11 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 
+	/* first set CR1 without interrupt and service enables */
+	pxa2xx_spi_update(drv_data, SSCR1, change_mask, cr1);
+
 	/* see if we need to reload the config registers */
-	if ((pxa2xx_spi_read(drv_data, SSCR0) != cr0)
-	    || (pxa2xx_spi_read(drv_data, SSCR1) & change_mask)
-	    != (cr1 & change_mask)) {
-		/* first set CR1 without interrupt and service enables */
-		pxa2xx_spi_write(drv_data, SSCR1, cr1 & change_mask);
-		/* Update the other bits */
-		pxa2xx_spi_write(drv_data, SSCR0, cr0);
-	}
+	pxa2xx_spi_update(drv_data, SSCR0, GENMASK(31, 0), cr0);
 
 	/* Restart the SSP */
 	pxa_ssp_enable(drv_data->ssp);
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:36 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:36 +0300
Subject: [PATCH v1 13/14] spi: pxa2xx: Constify struct driver_data parameter
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-13-andriy.shevchenko@linux.intel.com>

In a couple of functions the contents of struct driver_data are not altered,
hence we may constify the respective function parameter.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 6d4273772b1f..301969fc3c95 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -93,7 +93,7 @@ static inline void pxa2xx_spi_write(const struct driver_data *drv_data, u32 reg,
 
 #define DMA_ALIGNMENT		8
 
-static inline int pxa25x_ssp_comp(struct driver_data *drv_data)
+static inline int pxa25x_ssp_comp(const struct driver_data *drv_data)
 {
 	switch (drv_data->ssp_type) {
 	case PXA25x_SSP:
@@ -115,7 +115,7 @@ static inline u32 read_SSSR_bits(const struct driver_data *drv_data, u32 bits)
 	return pxa2xx_spi_read(drv_data, SSSR) & bits;
 }
 
-static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
+static inline void write_SSSR_CS(const struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
 	    drv_data->ssp_type == QUARK_X1000_SSP)
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:35 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:35 +0300
Subject: [PATCH v1 12/14] spi: pxa2xx: Extract read_SSSR_bits() helper
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-12-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "read some bits from SSSR".
Extract read_SSSR_bits() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c |  9 +++------
 drivers/spi/spi-pxa2xx.c     | 26 +++++++++++---------------
 drivers/spi/spi-pxa2xx.h     |  7 ++++++-
 3 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index e581027e99f9..f022d82dcb1b 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -34,11 +34,8 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 		 * might not know about the error yet. So we re-check the
 		 * ROR bit here before we clear the status register.
 		 */
-		if (!error) {
-			u32 status = pxa2xx_spi_read(drv_data, SSSR)
-				     & drv_data->mask_sr;
-			error = status & SSSR_ROR;
-		}
+		if (!error)
+			error = read_SSSR_bits(drv_data, drv_data->mask_sr) & SSSR_ROR;
 
 		/* Clear status & disable interrupts */
 		clear_SSCR1_bits(drv_data, drv_data->dma_cr1);
@@ -119,7 +116,7 @@ irqreturn_t pxa2xx_spi_dma_transfer(struct driver_data *drv_data)
 {
 	u32 status;
 
-	status = pxa2xx_spi_read(drv_data, SSSR) & drv_data->mask_sr;
+	status = read_SSSR_bits(drv_data, drv_data->mask_sr);
 	if (status & SSSR_ROR) {
 		dev_err(drv_data->ssp->dev, "FIFO overrun\n");
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 58178ba704dc..5a4f808eefde 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -247,7 +247,7 @@ static bool pxa2xx_spi_txfifo_full(const struct driver_data *drv_data)
 		break;
 	}
 
-	return (pxa2xx_spi_read(drv_data, SSSR) & mask) == mask;
+	return read_SSSR_bits(drv_data, mask) == mask;
 }
 
 static void pxa2xx_spi_clear_rx_thre(const struct driver_data *drv_data,
@@ -488,7 +488,7 @@ int pxa2xx_spi_flush(struct driver_data *drv_data)
 	unsigned long limit = loops_per_jiffy << 1;
 
 	do {
-		while (pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
+		while (read_SSSR_bits(drv_data, SSSR_RNE))
 			pxa2xx_spi_read(drv_data, SSDR);
 	} while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_BSY) && --limit);
 	write_SSSR_CS(drv_data, SSSR_ROR);
@@ -523,8 +523,7 @@ static int null_reader(struct driver_data *drv_data)
 {
 	u8 n_bytes = drv_data->n_bytes;
 
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += n_bytes;
 	}
@@ -546,8 +545,7 @@ static int u8_writer(struct driver_data *drv_data)
 
 static int u8_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u8 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		++drv_data->rx;
 	}
@@ -569,8 +567,7 @@ static int u16_writer(struct driver_data *drv_data)
 
 static int u16_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u16 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += 2;
 	}
@@ -592,8 +589,7 @@ static int u32_writer(struct driver_data *drv_data)
 
 static int u32_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u32 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += 4;
 	}
@@ -655,10 +651,11 @@ static void int_transfer_complete(struct driver_data *drv_data)
 
 static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 {
-	u32 irq_mask = (pxa2xx_spi_read(drv_data, SSCR1) & SSCR1_TIE) ?
-		       drv_data->mask_sr : drv_data->mask_sr & ~SSSR_TFS;
+	u32 irq_status;
 
-	u32 irq_status = pxa2xx_spi_read(drv_data, SSSR) & irq_mask;
+	irq_status = read_SSSR_bits(drv_data, drv_data->mask_sr);
+	if (!(pxa2xx_spi_read(drv_data, SSCR1) & SSCR1_TIE))
+		irq_status &= ~SSSR_TFS;
 
 	if (irq_status & SSSR_ROR) {
 		int_error_stop(drv_data, "interrupt_transfer: fifo overrun", -EIO);
@@ -1110,8 +1107,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	pxa_ssp_enable(drv_data->ssp);
 
 	if (is_mmp2_ssp(drv_data)) {
-		u8 tx_level = (pxa2xx_spi_read(drv_data, SSSR)
-					& SSSR_TFL_MASK) >> 8;
+		u8 tx_level = read_SSSR_bits(drv_data, SSSR_TFL_MASK) >> 8;
 
 		if (tx_level) {
 			/* On MMP2, flipping SSE doesn't to empty TXFIFO. */
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 398dbd680208..6d4273772b1f 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -110,11 +110,16 @@ static inline void clear_SSCR1_bits(const struct driver_data *drv_data, u32 bits
 	pxa2xx_spi_write(drv_data, SSCR1, pxa2xx_spi_read(drv_data, SSCR1) & ~bits);
 }
 
+static inline u32 read_SSSR_bits(const struct driver_data *drv_data, u32 bits)
+{
+	return pxa2xx_spi_read(drv_data, SSSR) & bits;
+}
+
 static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
 	    drv_data->ssp_type == QUARK_X1000_SSP)
-		val |= pxa2xx_spi_read(drv_data, SSSR) & SSSR_ALT_FRM_MASK;
+		val |= read_SSSR_bits(drv_data, SSSR_ALT_FRM_MASK);
 
 	pxa2xx_spi_write(drv_data, SSSR, val);
 }
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:32 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:32 +0300
Subject: [PATCH v1 09/14] spi: pxa2xx: Use pxa_ssp_enable()/pxa_ssp_disable()
 in the driver
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-9-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of pxa_ssp_enable() and
pxa_ssp_disable(). Use them instead of open coded variants.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c   |  4 +---
 drivers/spi/spi-pxa2xx.c       | 36 +++++++++++++++++-----------------
 include/linux/spi/pxa2xx_ssp.h | 16 +++++++++++++++
 sound/soc/pxa/pxa-ssp.c        | 16 ---------------
 4 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index e00dbadd39ec..5ca01ad7f460 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -50,9 +50,7 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 
 		if (error) {
 			/* In case we got an error we disable the SSP now */
-			pxa2xx_spi_write(drv_data, SSCR0,
-					 pxa2xx_spi_read(drv_data, SSCR0)
-					 & ~SSCR0_SSE);
+			pxa_ssp_disable(drv_data->ssp);
 			msg->status = -EIO;
 		}
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 85a8d228a117..f85c7439757c 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -286,13 +286,11 @@ static u32 pxa2xx_configure_sscr0(const struct driver_data *drv_data,
 	case QUARK_X1000_SSP:
 		return clk_div
 			| QUARK_X1000_SSCR0_Motorola
-			| QUARK_X1000_SSCR0_DataSize(bits > 32 ? 8 : bits)
-			| SSCR0_SSE;
+			| QUARK_X1000_SSCR0_DataSize(bits > 32 ? 8 : bits);
 	default:
 		return clk_div
 			| SSCR0_Motorola
 			| SSCR0_DataSize(bits > 16 ? bits - 16 : bits)
-			| SSCR0_SSE
 			| (bits > 16 ? SSCR0_EDSS : 0);
 	}
 }
@@ -498,8 +496,7 @@ static void pxa2xx_spi_off(struct driver_data *drv_data)
 	if (is_mmp2_ssp(drv_data))
 		return;
 
-	pxa2xx_spi_write(drv_data, SSCR0,
-			 pxa2xx_spi_read(drv_data, SSCR0) & ~SSCR0_SSE);
+	pxa_ssp_disable(drv_data->ssp);
 }
 
 static int null_writer(struct driver_data *drv_data)
@@ -1098,25 +1095,26 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	    (pxa2xx_spi_read(drv_data, DDS_RATE) != chip->dds_rate))
 		pxa2xx_spi_write(drv_data, DDS_RATE, chip->dds_rate);
 
+	/* Stop the SSP */
+	if (!is_mmp2_ssp(drv_data))
+		pxa_ssp_disable(drv_data->ssp);
+
+	if (!pxa25x_ssp_comp(drv_data))
+		pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
+
 	/* see if we need to reload the config registers */
 	if ((pxa2xx_spi_read(drv_data, SSCR0) != cr0)
 	    || (pxa2xx_spi_read(drv_data, SSCR1) & change_mask)
 	    != (cr1 & change_mask)) {
-		/* stop the SSP, and update the other bits */
-		if (!is_mmp2_ssp(drv_data))
-			pxa2xx_spi_write(drv_data, SSCR0, cr0 & ~SSCR0_SSE);
-		if (!pxa25x_ssp_comp(drv_data))
-			pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 		/* first set CR1 without interrupt and service enables */
 		pxa2xx_spi_write(drv_data, SSCR1, cr1 & change_mask);
-		/* restart the SSP */
+		/* Update the other bits */
 		pxa2xx_spi_write(drv_data, SSCR0, cr0);
-
-	} else {
-		if (!pxa25x_ssp_comp(drv_data))
-			pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 	}
 
+	/* Restart the SSP */
+	pxa_ssp_enable(drv_data->ssp);
+
 	if (is_mmp2_ssp(drv_data)) {
 		u8 tx_level = (pxa2xx_spi_read(drv_data, SSSR)
 					& SSSR_TFL_MASK) >> 8;
@@ -1782,8 +1780,9 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 		controller->min_speed_hz =
 			DIV_ROUND_UP(controller->max_speed_hz, 512);
 
+	pxa_ssp_disable(ssp);
+
 	/* Load default SSP configuration */
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
 	switch (drv_data->ssp_type) {
 	case QUARK_X1000_SSP:
 		tmp = QUARK_X1000_SSCR1_RxTresh(RX_THRESH_QUARK_X1000_DFLT) |
@@ -1924,7 +1923,7 @@ static int pxa2xx_spi_remove(struct platform_device *pdev)
 	spi_unregister_controller(drv_data->controller);
 
 	/* Disable the SSP at the peripheral and SOC level */
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
+	pxa_ssp_disable(ssp);
 	clk_disable_unprepare(ssp->clk);
 
 	/* Release DMA */
@@ -1953,7 +1952,8 @@ static int pxa2xx_spi_suspend(struct device *dev)
 	status = spi_controller_suspend(drv_data->controller);
 	if (status != 0)
 		return status;
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
+
+	pxa_ssp_disable(ssp);
 
 	if (!pm_runtime_suspended(dev))
 		clk_disable_unprepare(ssp->clk);
diff --git a/include/linux/spi/pxa2xx_ssp.h b/include/linux/spi/pxa2xx_ssp.h
index 1b6c1a0922bd..fdfbe17e15f4 100644
--- a/include/linux/spi/pxa2xx_ssp.h
+++ b/include/linux/spi/pxa2xx_ssp.h
@@ -254,6 +254,22 @@ static inline u32 pxa_ssp_read_reg(struct ssp_device *dev, u32 reg)
 	return __raw_readl(dev->mmio_base + reg);
 }
 
+static inline void pxa_ssp_enable(struct ssp_device *ssp)
+{
+	u32 sscr0;
+
+	sscr0 = pxa_ssp_read_reg(ssp, SSCR0) | SSCR0_SSE;
+	pxa_ssp_write_reg(ssp, SSCR0, sscr0);
+}
+
+static inline void pxa_ssp_disable(struct ssp_device *ssp)
+{
+	u32 sscr0;
+
+	sscr0 = pxa_ssp_read_reg(ssp, SSCR0) & ~SSCR0_SSE;
+	pxa_ssp_write_reg(ssp, SSCR0, sscr0);
+}
+
 #if IS_ENABLED(CONFIG_PXA_SSP)
 struct ssp_device *pxa_ssp_request(int port, const char *label);
 void pxa_ssp_free(struct ssp_device *);
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index 710c8dbd18bc..5a83331fc160 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -62,22 +62,6 @@ static void dump_registers(struct ssp_device *ssp)
 		 pxa_ssp_read_reg(ssp, SSACD));
 }
 
-static void pxa_ssp_enable(struct ssp_device *ssp)
-{
-	uint32_t sscr0;
-
-	sscr0 = __raw_readl(ssp->mmio_base + SSCR0) | SSCR0_SSE;
-	__raw_writel(sscr0, ssp->mmio_base + SSCR0);
-}
-
-static void pxa_ssp_disable(struct ssp_device *ssp)
-{
-	uint32_t sscr0;
-
-	sscr0 = __raw_readl(ssp->mmio_base + SSCR0) & ~SSCR0_SSE;
-	__raw_writel(sscr0, ssp->mmio_base + SSCR0);
-}
-
 static void pxa_ssp_set_dma_params(struct ssp_device *ssp, int width4,
 			int out, struct snd_dmaengine_dai_dma_data *dma)
 {
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:28 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:28 +0300
Subject: [PATCH v1 05/14] spi: pxa2xx: Consolidate related headers under
 include/linux/spi
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-5-andriy.shevchenko@linux.intel.com>

We have two headers split between include/linux and include/linux/spi.
Consolidated them under SPI realm, i.e. in the latter folder.

Update users accordingly.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/input/mouse/navpoint.c       | 3 ++-
 drivers/spi/spi-pxa2xx-dma.c         | 2 --
 drivers/spi/spi-pxa2xx-pci.c         | 1 +
 drivers/spi/spi-pxa2xx.h             | 2 +-
 include/linux/spi/pxa2xx_spi.h       | 9 +++++----
 include/linux/{ => spi}/pxa2xx_ssp.h | 6 +++---
 sound/soc/intel/catpt/dsp.c          | 4 +++-
 sound/soc/pxa/pxa-ssp.c              | 3 ++-
 8 files changed, 17 insertions(+), 13 deletions(-)
 rename include/linux/{ => spi}/pxa2xx_ssp.h (99%)

diff --git a/drivers/input/mouse/navpoint.c b/drivers/input/mouse/navpoint.c
index 4d67575bb276..a0731cfbbafa 100644
--- a/drivers/input/mouse/navpoint.c
+++ b/drivers/input/mouse/navpoint.c
@@ -15,9 +15,10 @@
 #include <linux/input/navpoint.h>
 #include <linux/interrupt.h>
 #include <linux/mutex.h>
-#include <linux/pxa2xx_ssp.h>
 #include <linux/slab.h>
 
+#include <linux/spi/pxa2xx_ssp.h>
+
 /*
  * Synaptics Modular Embedded Protocol: Module Packet Format.
  * Module header byte 2:0 = Length (# bytes that follow)
diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 32ab7391396d..e00dbadd39ec 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -15,8 +15,6 @@
 #include <linux/spi/pxa2xx_spi.h>
 #include <linux/spi/spi.h>
 
-#include <linux/pxa2xx_ssp.h>
-
 #include "spi-pxa2xx.h"
 
 static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index f60ed4c62000..5af0a3fbc1b0 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -8,6 +8,7 @@
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
+
 #include <linux/spi/pxa2xx_spi.h>
 
 #include <linux/dmaengine.h>
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 739e264feaa6..b6dae0981b61 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -12,7 +12,7 @@
 #include <linux/types.h>
 #include <linux/sizes.h>
 
-#include <linux/pxa2xx_ssp.h>
+#include <linux/spi/pxa2xx_ssp.h>
 
 struct gpio_desc;
 struct pxa2xx_spi_controller;
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
index 1e0e2f136319..4baae475bd89 100644
--- a/include/linux/spi/pxa2xx_spi.h
+++ b/include/linux/spi/pxa2xx_spi.h
@@ -2,12 +2,12 @@
 /*
  * Copyright (C) 2005 Stephen Street / StreetFire Sound Labs
  */
-#ifndef __linux_pxa2xx_spi_h
-#define __linux_pxa2xx_spi_h
+#ifndef __LINUX_PXA2XX_SPI_H
+#define __LINUX_PXA2XX_SPI_H
 
 #include <linux/types.h>
 
-#include <linux/pxa2xx_ssp.h>
+#include <linux/spi/pxa2xx_ssp.h>
 
 #define PXA2XX_CS_ASSERT (0x01)
 #define PXA2XX_CS_DEASSERT (0x02)
@@ -51,4 +51,5 @@ struct pxa2xx_spi_chip {
 extern void pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_controller *info);
 
 #endif
-#endif
+
+#endif	/* __LINUX_PXA2XX_SPI_H */
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/spi/pxa2xx_ssp.h
similarity index 99%
rename from include/linux/pxa2xx_ssp.h
rename to include/linux/spi/pxa2xx_ssp.h
index 7f73b26ed22e..14b049840faf 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/spi/pxa2xx_ssp.h
@@ -11,8 +11,8 @@
  *       PXA3xx     SSP1, SSP2, SSP3, SSP4
  */
 
-#ifndef __LINUX_SSP_H
-#define __LINUX_SSP_H
+#ifndef __LINUX_PXA2XX_SSP_H
+#define __LINUX_PXA2XX_SSP_H
 
 #include <linux/bits.h>
 #include <linux/compiler_types.h>
@@ -270,4 +270,4 @@ static inline struct ssp_device *pxa_ssp_request_of(const struct device_node *n,
 static inline void pxa_ssp_free(struct ssp_device *ssp) {}
 #endif
 
-#endif
+#endif	/* __LINUX_PXA2XX_SSP_H */
diff --git a/sound/soc/intel/catpt/dsp.c b/sound/soc/intel/catpt/dsp.c
index 9c5fd18f2600..08af8bab8704 100644
--- a/sound/soc/intel/catpt/dsp.c
+++ b/sound/soc/intel/catpt/dsp.c
@@ -9,7 +9,9 @@
 #include <linux/dma-mapping.h>
 #include <linux/firmware.h>
 #include <linux/pci.h>
-#include <linux/pxa2xx_ssp.h>
+
+#include <linux/spi/pxa2xx_ssp.h>
+
 #include "core.h"
 #include "messages.h"
 #include "registers.h"
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index b941adcbb8f9..710c8dbd18bc 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -16,10 +16,11 @@
 #include <linux/platform_device.h>
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/pxa2xx_ssp.h>
 #include <linux/of.h>
 #include <linux/dmaengine.h>
 
+#include <linux/spi/pxa2xx_ssp.h>
+
 #include <asm/irq.h>
 
 #include <sound/core.h>
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 17:34:37 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 19:34:37 +0300
Subject: [PATCH v1 14/14] spi: pxa2xx: Introduce special type for Merrifield
 SPIs
In-Reply-To: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423163437.89306-14-andriy.shevchenko@linux.intel.com>

Intel Merrifield SPI is actually more closer to PXA3xx. It has extended FIFO
(32 bytes) and additional registers to get or set FIFO thresholds.

Introduce new type for Intel Merrifield SPI host controllers and handle bigger
FIFO size.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-pci.c   |  2 +-
 drivers/spi/spi-pxa2xx.c       | 32 +++++++++++++++++++++++++++++---
 include/linux/spi/pxa2xx_ssp.h | 16 ++++++++++++++++
 3 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 5af0a3fbc1b0..5df6e11b345d 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -179,7 +179,7 @@ static struct pxa_spi_info spi_info_configs[] = {
 		.rx_param = &bsw2_rx_param,
 	},
 	[PORT_MRFLD] = {
-		.type = PXA27x_SSP,
+		.type = MRFLD_SSP,
 		.max_clk_rate = 25000000,
 		.setup = mrfld_spi_setup,
 	},
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 5a4f808eefde..313095bfa7dd 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -200,6 +200,11 @@ static bool is_mmp2_ssp(const struct driver_data *drv_data)
 	return drv_data->ssp_type == MMP2_SSP;
 }
 
+static bool is_mrfld_ssp(const struct driver_data *drv_data)
+{
+	return drv_data->ssp_type == MRFLD_SSP;
+}
+
 static void pxa2xx_spi_update(const struct driver_data *drv_data, u32 reg, u32 mask, u32 value)
 {
 	if ((pxa2xx_spi_read(drv_data, reg) & mask) != value)
@@ -1087,6 +1092,15 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 		pxa2xx_spi_update(drv_data, SSITF, GENMASK(15, 0), chip->lpss_tx_threshold);
 	}
 
+	if (is_mrfld_ssp(drv_data)) {
+		u32 thresh = 0;
+
+		thresh |= SFIFOTT_RxThresh(chip->lpss_rx_threshold);
+		thresh |= SFIFOTT_TxThresh(chip->lpss_tx_threshold);
+
+		pxa2xx_spi_update(drv_data, SFIFOTT, 0xffffffff, thresh);
+	}
+
 	if (is_quark_x1000_ssp(drv_data))
 		pxa2xx_spi_update(drv_data, DDS_RATE, GENMASK(23, 0), chip->dds_rate);
 
@@ -1253,6 +1267,11 @@ static int setup(struct spi_device *spi)
 		tx_hi_thres = 0;
 		rx_thres = RX_THRESH_QUARK_X1000_DFLT;
 		break;
+	case MRFLD_SSP:
+		tx_thres = TX_THRESH_MRFLD_DFLT;
+		tx_hi_thres = 0;
+		rx_thres = RX_THRESH_MRFLD_DFLT;
+		break;
 	case CE4100_SSP:
 		tx_thres = TX_THRESH_CE4100_DFLT;
 		tx_hi_thres = 0;
@@ -1328,9 +1347,16 @@ static int setup(struct spi_device *spi)
 		chip->cr1 |= SSCR1_SPH;
 	}
 
-	chip->lpss_rx_threshold = SSIRF_RxThresh(rx_thres);
-	chip->lpss_tx_threshold = SSITF_TxLoThresh(tx_thres)
-				| SSITF_TxHiThresh(tx_hi_thres);
+	if (is_lpss_ssp(drv_data)) {
+		chip->lpss_rx_threshold = SSIRF_RxThresh(rx_thres);
+		chip->lpss_tx_threshold = SSITF_TxLoThresh(tx_thres) |
+					  SSITF_TxHiThresh(tx_hi_thres);
+	}
+
+	if (is_mrfld_ssp(drv_data)) {
+		chip->lpss_rx_threshold = rx_thres;
+		chip->lpss_tx_threshold = tx_thres;
+	}
 
 	/* set dma burst and threshold outside of chip_info path so that if
 	 * chip_info goes away after setting chip->enable_dma, the
diff --git a/include/linux/spi/pxa2xx_ssp.h b/include/linux/spi/pxa2xx_ssp.h
index fdfbe17e15f4..2b21bc1f3c73 100644
--- a/include/linux/spi/pxa2xx_ssp.h
+++ b/include/linux/spi/pxa2xx_ssp.h
@@ -183,6 +183,21 @@ struct device_node;
 #define SSACD_ACPS(x)		((x) << 4)	/* Audio clock PLL select */
 #define SSACD_SCDX8		BIT(7)		/* SYSCLK division ratio select */
 
+/* Intel Merrifield SSP */
+#define SFIFOL			0x68		/* FIFO level */
+#define SFIFOTT			0x6c		/* FIFO trigger threshold */
+
+#define RX_THRESH_MRFLD_DFLT	16
+#define TX_THRESH_MRFLD_DFLT	16
+
+#define SFIFOL_TFL_MASK		GENMASK(15, 0)	/* Transmit FIFO Level mask */
+#define SFIFOL_RFL_MASK		GENMASK(31, 16)	/* Receive FIFO Level mask */
+
+#define SFIFOTT_TFT		GENMASK(15, 0)	/* Transmit FIFO Threshold (mask) */
+#define SFIFOTT_TxThresh(x)	(((x) - 1) << 0)	/* TX FIFO trigger threshold / level */
+#define SFIFOTT_RFT		GENMASK(31, 16)	/* Receive FIFO Threshold (mask) */
+#define SFIFOTT_RxThresh(x)	(((x) - 1) << 16)	/* RX FIFO trigger threshold / level */
+
 /* LPSS SSP */
 #define SSITF			0x44		/* TX FIFO trigger level */
 #define SSITF_TxHiThresh(x)	(((x) - 1) << 0)
@@ -205,6 +220,7 @@ enum pxa_ssp_type {
 	MMP2_SSP,
 	PXA910_SSP,
 	CE4100_SSP,
+	MRFLD_SSP,
 	QUARK_X1000_SSP,
 	LPSS_LPT_SSP, /* Keep LPSS types sorted with lpss_platforms[] */
 	LPSS_BYT_SSP,
-- 
2.30.2



From chunkuang.hu at kernel.org  Fri Apr 23 17:36:55 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 24 Apr 2021 00:36:55 +0800
Subject: [PATCH 3/4] drm/mediatek: fine tune the dsi panel's power sequence
In-Reply-To: <20210420132614.150242-3-jitao.shi@mediatek.com>
References: <20210420132614.150242-1-jitao.shi@mediatek.com>
 <20210420132614.150242-3-jitao.shi@mediatek.com>
Message-ID: <CAAOTY_-SKcX+4U5hKOgRaip-vk+ofEWe_g4VNUxFjN7LCprq1w@mail.gmail.com>

Hi, Jitao:

Jitao Shi <jitao.shi at mediatek.com> ? 2021?4?20? ?? ??9:26???
>
> Add the drm_panel_prepare_power and drm_panel_unprepare_power control.
> Turn on panel power(drm_panel_prepare_power) and control before dsi
> enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last
> turn on backlight.

Please describe WHY do you need this patch? Fix any bug?

>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a1ff152ef468..455fe582c6b5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -615,10 +615,13 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>         dsi->data_rate = DIV_ROUND_UP_ULL(dsi->vm.pixelclock * bit_per_pixel,
>                                           dsi->lanes);
>
> +       if (panel_bridge_prepare_power(dsi->next_bridge))

ret = panel_bridge_prepare_power(dsi->next_bridge);
if (ret)

> +               DRM_INFO("can't prepare power the panel\n");

I think you should goto err_refcount;

> +
>         ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
>         if (ret < 0) {
>                 dev_err(dev, "Failed to set data rate: %d\n", ret);
> -               goto err_refcount;
> +               goto err_prepare_power;
>         }
>
>         phy_power_on(dsi->phy);
> @@ -661,7 +664,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>         clk_disable_unprepare(dsi->engine_clk);
>  err_phy_power_off:
>         phy_power_off(dsi->phy);
> -err_refcount:
> +err_prepare_power:
> +       if (panel_bridge_unprepare_power(dsi->next_bridge))

ret = panel_bridge_unprepare_power(dsi->next_bridge);

> +               DRM_INFO("Can't unprepare power the panel\n");
>         dsi->refcount--;
>         return ret;
>  }
> @@ -694,6 +699,9 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>         clk_disable_unprepare(dsi->digital_clk);
>
>         phy_power_off(dsi->phy);
> +
> +       if (panel_bridge_unprepare_power(dsi->next_bridge))

ret = panel_bridge_unprepare_power(dsi->next_bridge);

> +               DRM_INFO("Can't unprepare power the panel\n");
>  }
>
>  static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> --
> 2.25.1
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From thierry.reding at gmail.com  Fri Apr 23 17:47:54 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 18:47:54 +0200
Subject: [PATCH] pwm: mediatek: remove unused function
In-Reply-To: <1618475753-102123-1-git-send-email-jiapeng.chong@linux.alibaba.com>
References: <1618475753-102123-1-git-send-email-jiapeng.chong@linux.alibaba.com>
Message-ID: <YIL6OoqF+CtGyi1p@orome.fritz.box>

On Thu, Apr 15, 2021 at 04:35:53PM +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
> 
> drivers/pwm/pwm-mediatek.c:110:19: warning: unused function
> 'pwm_mediatek_readl' [-Wunused-function].
> 
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong at linux.alibaba.com>
> ---
>  drivers/pwm/pwm-mediatek.c | 6 ------
>  1 file changed, 6 deletions(-)

Applied, thanks.

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/20210423/8d673763/attachment.sig>

From thierry.reding at gmail.com  Fri Apr 23 17:53:29 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 18:53:29 +0200
Subject: [PATCH v3 1/4] dt-bindings: pwm: convert pwm-rockchip.txt to YAML
In-Reply-To: <20210412200155.5316-1-jbx6244@gmail.com>
References: <20210412200155.5316-1-jbx6244@gmail.com>
Message-ID: <YIL7ibC/Pojfw3OT@orome.fritz.box>

On Mon, Apr 12, 2021 at 10:01:52PM +0200, Johan Jonker wrote:
> Current dts files with 'pwm' nodes are manually verified.
> In order to automate this process pwm-rockchip.txt
> has to be converted to yaml.
> 
> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
> ---
> For some SoC nodes this patch serie generates notifications
> for undocumented "interrupts" properties shared between
> PWM channels till there is consensus of what to do with it or
> someone makes a solution for the whole PWM block.
> 
> Changed V3:
>   fix mistake with compatibles introduced in V2
> Changed V2:
>   changed schema for clocks and clock-names
> ---
>  .../devicetree/bindings/pwm/pwm-rockchip.txt       | 27 -------
>  .../devicetree/bindings/pwm/pwm-rockchip.yaml      | 88 ++++++++++++++++++++++
>  2 files changed, 88 insertions(+), 27 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.txt
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml

All 4 patches applied, thanks.

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/20210423/8e5fa6b7/attachment-0001.sig>

From broonie at kernel.org  Fri Apr 23 17:56:30 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 17:56:30 +0100
Subject: [PATCH v1 05/14] spi: pxa2xx: Consolidate related headers under
 include/linux/spi
In-Reply-To: <20210423163437.89306-5-andriy.shevchenko@linux.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
 <20210423163437.89306-5-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423165630.GH5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 07:34:28PM +0300, Andy Shevchenko wrote:

> We have two headers split between include/linux and include/linux/spi.
> Consolidated them under SPI realm, i.e. in the latter folder.

Why?  Isn't the point to maintain an abstraction between the general
purpose use of the SSP IP and its application as a SPI controller?  I'd
check the cover letter for the series but there doesn't seem to be one.
-------------- 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/20210423/41ba4a88/attachment.sig>

From thierry.reding at gmail.com  Fri Apr 23 18:05:35 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 19:05:35 +0200
Subject: [PATCH v6 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
References: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <YIL+Xwjbk1EE04Sm@orome.fritz.box>

On Mon, Apr 19, 2021 at 09:00:05AM +0900, Nobuhiro Iwamatsu wrote:
> Hi,
> 
> This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
> This provides DT binding documentation and device driver.
> 
> [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html
> 
> Updates:
> 
>   dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
>     v5 -> v6:
>       - No update.
>     v4 -> v5:
>       - No update.
>     v3 -> v4:
>       - No update.
>     v2 -> v3:
>       - Change compatible to toshiba,visconti-pwm
>       - Change filename to toshiba,visconti-pwm.yaml.
>       - Add Reviewed-by tag from Rob.
>     v1 -> v2:
>       - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
>       - Set compatible toshiba,pwm-visconti only.
>       - Drop unnecessary comments.
> 
>   pwm: visconti: Add Toshiba Visconti SoC PWM support
>     v5 -> v6:
>      - Update year in copyright.
>      - Update limitations.
>      - Fix coding style, used braces for both branches.
>     v4 -> v5:
>       - Droped checking PIPGM_PCSR from visconti_pwm_get_state.
>       - Changed from to_visconti_chip to visconti_pwm_from_chip.
>       - Removed pwmchip_remove return value management.
>       - Add limitations of this device.
>       - Add 'state->enabled = true' to visconti_pwm_get_state().
>     v3 -> v4:
>       - Sorted alphabetically include files.
>       - Changed container_of to using static inline functions.
>       - Dropped unnecessary dev_dbg().
>       - Drop Initialization of chip.base.
>       - Drop commnet "period too small".
>       - Rebased for-next. 
>     v2 -> v3:
>       - Change compatible to toshiba,visconti-pwm.
>       - Fix MODULE_ALIAS to platform:pwm-visconti, again.
>       - Align continuation line to the opening parenthesis.
>       - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
>     v1 -> v2:
>       - Change SPDX-License-Identifier to GPL-2.0-only.
>       - Add prefix for the register defines.
>       - Drop struct device from struct visconti_pwm_chip.
>       - Use '>>' instead of '/'.
>       - Drop error message by devm_platform_ioremap_resource().
>       - Use dev_err_probe instead of dev_err.
>       - Change dev_info to dev_dbg.
>       - Remove some empty lines.
>       - Fix MODULE_ALIAS to platform:pwm-visconti.
>       - Add .get_state() function.
>       - Use the author name and email address to MODULE_AUTHOR.
>       - Add more comment to function of the hardware.
>       - Support .get_status() function.
>       - Use NSEC_PER_USEC instead of 1000.
>       - Alphabetically sorted for Makefile and Kconfig.
>       - Added check for set value in visconti_pwm_apply().
> 
> Nobuhiro Iwamatsu (2):
>   dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
>   pwm: visconti: Add Toshiba Visconti SoC PWM support
> 
>  .../bindings/pwm/toshiba,pwm-visconti.yaml    |  43 ++++
>  drivers/pwm/Kconfig                           |   9 +
>  drivers/pwm/Makefile                          |   1 +
>  drivers/pwm/pwm-visconti.c                    | 189 ++++++++++++++++++
>  4 files changed, 242 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
>  create mode 100644 drivers/pwm/pwm-visconti.c

Both patches applied, thanks.

checkpatch did complain when I applied:

> WARNING: please write a paragraph that describes the config symbol fully
> #9: FILE: drivers/pwm/Kconfig:604:
> +config PWM_VISCONTI

That seems a bit excessive. The paragraph is perhaps not a poster child
for Kconfig, but there are others that aren't better, so I think that's
fine.

> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #32: 
> new file mode 100644

Fine, too.

> WARNING: 'loosing' may be misspelled - perhaps 'losing'?
> #112: FILE: drivers/pwm/pwm-visconti.c:76:
>  +	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
>   	                                         ^^^^^^^

I've fixed that up while applying.

> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON()
> #127: FILE: drivers/pwm/pwm-visconti.c:91:
> +		BUG_ON(pwmc0 > 3);

I think that one is legit. I've turned that into:

	if (WARN_ON(pwmc0 > 3))
		return -EINVAL;

so that requests for too big period will be rejected rather than crash
the system. Next time, please run checkpatch before submitting and
eliminate at least the big warnings.

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/20210423/f924c824/attachment.sig>

From thierry.reding at gmail.com  Fri Apr 23 18:07:18 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 19:07:18 +0200
Subject: [PATCH 1/2] pwm: atmel: Fix duty cycle calculation in .get_state()
In-Reply-To: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
Message-ID: <YIL+xs0jstJZAs8p@orome.fritz.box>

On Tue, Apr 20, 2021 at 11:51:17AM +0200, Uwe Kleine-K?nig wrote:
> The CDTY register contains the number of inactive cycles. .apply() does
> this correctly, however .get_state() got this wrong.
> 
> Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()")
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/pwm/pwm-atmel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

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/20210423/000e767a/attachment.sig>

From thierry.reding at gmail.com  Fri Apr 23 18:07:32 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Fri, 23 Apr 2021 19:07:32 +0200
Subject: [PATCH 2/2] pwm: atmel: Improve duty cycle calculation in .apply()
In-Reply-To: <20210420095118.1571344-2-u.kleine-koenig@pengutronix.de>
References: <20210420095118.1571344-1-u.kleine-koenig@pengutronix.de>
 <20210420095118.1571344-2-u.kleine-koenig@pengutronix.de>
Message-ID: <YIL+1APYTqWSKRIc@orome.fritz.box>

On Tue, Apr 20, 2021 at 11:51:18AM +0200, Uwe Kleine-K?nig wrote:
> In the calculation of the register value determining the duty cycle the
> requested period is used instead of the actually implemented period which
> results in suboptimal settings.
> 
> The following example assumes an input clock of 133333333 Hz on one of
> the SoCs with 16 bit period.
> 
> When the following state is to be applied:
> 
>         .period = 414727681
>         .duty_cycle = 652806
> 
> the following register values used to be  calculated:
> 
>         PRES = 10
>         CPRD = 54000
>         CDTY = 53916
> 
> which yields an actual duty cycle of a bit more than 645120 ns.
> 
> The setting
> 
>         PRES = 10
>         CPRD = 54000
>         CDTY = 53915
> 
> however yields a duty of 652800 ns which is between the current result
> and the requested value and so is a better approximation.
> 
> The reason for this error is that for the calculation of CDTY the
> requested period was used instead of the actually implemented one.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/pwm/pwm-atmel.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)

Applied, thanks.

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/20210423/25b2aeb0/attachment-0001.sig>

From catalin.marinas at arm.com  Fri Apr 23 18:09:46 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:09:46 +0100
Subject: [PATCH] arm64: Force SPARSEMEM_VMEMMAP as the only memory
 management model
In-Reply-To: <20210420093559.23168-1-catalin.marinas@arm.com>
References: <20210420093559.23168-1-catalin.marinas@arm.com>
Message-ID: <161919777114.6013.6751893244325348911.b4-ty@arm.com>

On Tue, 20 Apr 2021 10:35:59 +0100, Catalin Marinas wrote:
> Currently arm64 allows a choice of FLATMEM, SPARSEMEM and
> SPARSEMEM_VMEMMAP. However, only the latter is tested regularly. FLATMEM
> does not seem to boot in certain configurations (guest under KVM with
> Qemu as a VMM). Since the reduction of the SECTION_SIZE_BITS to 27 (4K
> pages) or 29 (64K page), there's little argument against the memory
> wasted by the mem_map array with SPARSEMEM.
> 
> [...]

Applied to arm64 (for-next/core).

[1/1] arm64: Force SPARSEMEM_VMEMMAP as the only memory management model
      https://git.kernel.org/arm64/c/782276b4d0ad

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 23 18:10:08 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:10:08 +0100
Subject: [PATCH] arm64: remove HAVE_DEBUG_BUGVERBOSE
In-Reply-To: <20210418215231.563d4b72@xhacker>
References: <20210418215231.563d4b72@xhacker>
Message-ID: <161919777114.6013.3497530317233037222.b4-ty@arm.com>

On Sun, 18 Apr 2021 21:52:31 +0800, Jisheng Zhang wrote:
> After commit 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic
> BUG traps"), arm64 has switched to generic BUG implementation, so
> there's no need to select HAVE_DEBUG_BUGVERBOSE.

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: remove HAVE_DEBUG_BUGVERBOSE
      https://git.kernel.org/arm64/c/4139cf940d52

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 23 18:10:26 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:10:26 +0100
Subject: [PATCH] arm64: alternative: simplify passing alt_region
In-Reply-To: <20210416163032.10857-1-mark.rutland@arm.com>
References: <20210416163032.10857-1-mark.rutland@arm.com>
Message-ID: <161919777114.6013.632158250785000360.b4-ty@arm.com>

On Fri, 16 Apr 2021 17:30:32 +0100, Mark Rutland wrote:
> In __apply_alternatives() we take a pointer to void which we later
> assign to a pointer to struct alt_region. As all callers are passing a
> pointer to struct alt_region to begin with, it's simpler and more robust
> to take a pointer to struct alt region, so let's do so and avoid the
> need for a temporary variable.

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: alternative: simplify passing alt_region
      https://git.kernel.org/arm64/c/8d144746ecc5

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 23 18:11:07 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:11:07 +0100
Subject: [PATCH 0/2] arm64: ACPI GTDT watchdog fixes
In-Reply-To: <20210421164317.1718831-1-maz@kernel.org>
References: <20210421164317.1718831-1-maz@kernel.org>
Message-ID: <161919777114.6013.5171405926781894062.b4-ty@arm.com>

On Wed, 21 Apr 2021 17:43:15 +0100, Marc Zyngier wrote:
> Dann recently reported that his ThunderX machine failed to boot since
> 64b499d8df40 ("irqchip/gic-v3: Configure SGIs as standard
> interrupts"), with a not so pretty crash while trying to send an IPI.
> 
> It turned out to be caused by a mix of broken firmware and a buggy
> GTDT watchdog driver. Both have forever been buggy, but the above
> commit revealed that the error handling path of the driver was
> probably the worse part of it all.
> 
> [...]

Applied to arm64 (for-next/core), thanks!

[1/2] ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure
      https://git.kernel.org/arm64/c/1ecd5b129252
[2/2] ACPI: irq: Prevent unregistering of GIC SGIs
      https://git.kernel.org/arm64/c/2a20b08f06e7

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 23 18:11:24 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:11:24 +0100
Subject: [PATCH v3] arm64: vdso32: drop -no-integrated-as flag
In-Reply-To: <20210420174427.230228-1-ndesaulniers@google.com>
References: <20210420174427.230228-1-ndesaulniers@google.com>
Message-ID: <161919777113.6013.4451539814173734627.b4-ty@arm.com>

On Tue, 20 Apr 2021 10:44:25 -0700, Nick Desaulniers wrote:
> Clang can assemble these files just fine; this is a relic from the top
> level Makefile conditionally adding this. We no longer need --prefix,
> --gcc-toolchain, or -Qunused-arguments flags either with this change, so
> remove those too.
> 
> To test building:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
>   CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make LLVM=1 LLVM_IAS=1 \
>   defconfig arch/arm64/kernel/vdso32/

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: vdso32: drop -no-integrated-as flag
      https://git.kernel.org/arm64/c/ef94340583ee

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 23 18:11:46 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:11:46 +0100
Subject: [PATCH] arm64: Show three registers per line
In-Reply-To: <20210420172245.3679077-1-willy@infradead.org>
References: <20210420172245.3679077-1-willy@infradead.org>
Message-ID: <161919777114.6013.3738864758201386208.b4-ty@arm.com>

On Tue, 20 Apr 2021 18:22:45 +0100, Matthew Wilcox (Oracle) wrote:
> Displaying two registers per line takes 15 lines.  That improves to just
> 10 lines if we display three registers per line, which reduces the amount
> of information lost when oopses are cut off.  It stays within 80 columns
> and matches x86-64.

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: Show three registers per line
      https://git.kernel.org/arm64/c/0bca3ec846d7

-- 
Catalin



From vkoul at kernel.org  Fri Apr 23 18:20:40 2021
From: vkoul at kernel.org (Vinod Koul)
Date: Fri, 23 Apr 2021 22:50:40 +0530
Subject: [PATCH 0/4] Expand Xilinx CDMA functions
In-Reply-To: <bed31611-a084-2a05-f3a3-25585a47be9a@metafoo.de>
References: <20210423011913.13122-1-adrian.martinezlarumbe@imgtec.com>
 <c2876f2c-beb2-f159-9b61-d69ae6b8275a@metafoo.de>
 <YILKq+jNZZSs37xa@vkoul-mobl.Dlink>
 <bed31611-a084-2a05-f3a3-25585a47be9a@metafoo.de>
Message-ID: <YIMB6DpM//wrPC6q@vkoul-mobl.Dlink>

On 23-04-21, 15:51, Lars-Peter Clausen wrote:
> On 4/23/21 3:24 PM, Vinod Koul wrote:
> > On 23-04-21, 11:17, Lars-Peter Clausen wrote:
> > > It seems to me what we are missing from the DMAengine API is the equivalent
> > > of device_prep_dma_memcpy() that is able to take SG lists. There is already
> > > a memset_sg, it should be possible to add something similar for memcpy.
> > You mean something like dmaengine_prep_dma_sg() which was removed?
> > 
> Ah, that's why I could have sworn we already had this!

Even at that time we had the premise that we can bring the API back if
we had users. I think many have asked for it, but I havent seen a patch
with user yet :)

> > static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg(
> >                 struct dma_chan *chan,
> >                 struct scatterlist *dst_sg, unsigned int dst_nents,
> >                 struct scatterlist *src_sg, unsigned int src_nents,
> >                 unsigned long flags)
> > 
> > The problem with this API is that it would work only when src_sg and
> > dst_sg is of similar nature, if not then how should one go about
> > copying...should we fill without a care for dst_sg being different than
> > src_sg as long as total data to be copied has enough space in dst...
> At least for the CDMA the only requirement is that both buffers have the
> same total size.

I will merge if with a user but semantics need to be absolutely clear on
what is allowed and not, do I hear a volunteer ?
-- 
~Vinod


From u.kleine-koenig at pengutronix.de  Fri Apr 23 18:20:41 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 23 Apr 2021 19:20:41 +0200
Subject: [PATCH v6 0/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
In-Reply-To: <YIL+Xwjbk1EE04Sm@orome.fritz.box>
References: <20210419000007.1944301-1-nobuhiro1.iwamatsu@toshiba.co.jp>
 <YIL+Xwjbk1EE04Sm@orome.fritz.box>
Message-ID: <20210423172041.jwmrrbnv76irmzxz@pengutronix.de>

On Fri, Apr 23, 2021 at 07:05:35PM +0200, Thierry Reding wrote:
> On Mon, Apr 19, 2021 at 09:00:05AM +0900, Nobuhiro Iwamatsu wrote:
> > Hi,
> > 
> > This series is the PWM driver for Toshiba's ARM SoC, Visconti[0].
> > This provides DT binding documentation and device driver.
> > 
> > [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html
> > 
> > Updates:
> > 
> >   dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
> >     v5 -> v6:
> >       - No update.
> >     v4 -> v5:
> >       - No update.
> >     v3 -> v4:
> >       - No update.
> >     v2 -> v3:
> >       - Change compatible to toshiba,visconti-pwm
> >       - Change filename to toshiba,visconti-pwm.yaml.
> >       - Add Reviewed-by tag from Rob.
> >     v1 -> v2:
> >       - Change SPDX-License-Identifier to GPL-2.0-only OR BSD-2-Clause.
> >       - Set compatible toshiba,pwm-visconti only.
> >       - Drop unnecessary comments.
> > 
> >   pwm: visconti: Add Toshiba Visconti SoC PWM support
> >     v5 -> v6:
> >      - Update year in copyright.
> >      - Update limitations.
> >      - Fix coding style, used braces for both branches.
> >     v4 -> v5:
> >       - Droped checking PIPGM_PCSR from visconti_pwm_get_state.
> >       - Changed from to_visconti_chip to visconti_pwm_from_chip.
> >       - Removed pwmchip_remove return value management.
> >       - Add limitations of this device.
> >       - Add 'state->enabled = true' to visconti_pwm_get_state().
> >     v3 -> v4:
> >       - Sorted alphabetically include files.
> >       - Changed container_of to using static inline functions.
> >       - Dropped unnecessary dev_dbg().
> >       - Drop Initialization of chip.base.
> >       - Drop commnet "period too small".
> >       - Rebased for-next. 
> >     v2 -> v3:
> >       - Change compatible to toshiba,visconti-pwm.
> >       - Fix MODULE_ALIAS to platform:pwm-visconti, again.
> >       - Align continuation line to the opening parenthesis.
> >       - Rewrite the contents of visconti_pwm_apply() based on the contents suggested by Uwe.
> >     v1 -> v2:
> >       - Change SPDX-License-Identifier to GPL-2.0-only.
> >       - Add prefix for the register defines.
> >       - Drop struct device from struct visconti_pwm_chip.
> >       - Use '>>' instead of '/'.
> >       - Drop error message by devm_platform_ioremap_resource().
> >       - Use dev_err_probe instead of dev_err.
> >       - Change dev_info to dev_dbg.
> >       - Remove some empty lines.
> >       - Fix MODULE_ALIAS to platform:pwm-visconti.
> >       - Add .get_state() function.
> >       - Use the author name and email address to MODULE_AUTHOR.
> >       - Add more comment to function of the hardware.
> >       - Support .get_status() function.
> >       - Use NSEC_PER_USEC instead of 1000.
> >       - Alphabetically sorted for Makefile and Kconfig.
> >       - Added check for set value in visconti_pwm_apply().
> > 
> > Nobuhiro Iwamatsu (2):
> >   dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
> >   pwm: visconti: Add Toshiba Visconti SoC PWM support
> > 
> >  .../bindings/pwm/toshiba,pwm-visconti.yaml    |  43 ++++
> >  drivers/pwm/Kconfig                           |   9 +
> >  drivers/pwm/Makefile                          |   1 +
> >  drivers/pwm/pwm-visconti.c                    | 189 ++++++++++++++++++
> >  4 files changed, 242 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml
> >  create mode 100644 drivers/pwm/pwm-visconti.c
> 
> Both patches applied, thanks.
> 
> checkpatch did complain when I applied:
> 
> > WARNING: please write a paragraph that describes the config symbol fully
> > #9: FILE: drivers/pwm/Kconfig:604:
> > +config PWM_VISCONTI
> 
> That seems a bit excessive. The paragraph is perhaps not a poster child
> for Kconfig, but there are others that aren't better, so I think that's
> fine.
> 
> > WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> > #32: 
> > new file mode 100644
> 
> Fine, too.
> 
> > WARNING: 'loosing' may be misspelled - perhaps 'losing'?
> > #112: FILE: drivers/pwm/pwm-visconti.c:76:
> >  +	 * NSEC_PER_SEC / CLKFREQ = 1000 without loosing precision.
> >   	                                         ^^^^^^^
> 
> I've fixed that up while applying.
> 
> > WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON()
> > #127: FILE: drivers/pwm/pwm-visconti.c:91:
> > +		BUG_ON(pwmc0 > 3);
> 
> I think that one is legit. I've turned that into:
> 
> 	if (WARN_ON(pwmc0 > 3))
> 		return -EINVAL;

> 
> so that requests for too big period will be rejected rather than crash
> the system.

If this BUG_ON (or your if) triggers we have a compiler or memory
problem. The relevant parts of the code are:

	if (state->period > (0xffff << 3) * 1000)
		period = (0xffff << 3) * 1000;
	else
		period = state->period;

	period /= 1000;

	if (period > 0xffff) {
		pwmc0 = ilog2(period >> 16);
		BUG_ON(pwmc0 > 3);

Given that period is never bigger than 0xffff << 3 when it is used to
calculate the argument to ilog2, pwmc0 <= ilog2(7) = 2.

Hmm, I wonder if the formula is wrong given that pwmc0 never becomes 3?!
Should this better be

	pwmc0 = fls(period >> 16);

?

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/20210423/21c8c633/attachment.sig>

From dafna.hirschfeld at collabora.com  Fri Apr 23 18:27:45 2021
From: dafna.hirschfeld at collabora.com (Dafna Hirschfeld)
Date: Fri, 23 Apr 2021 19:27:45 +0200
Subject: [PATCH] media: mtk-vpu: on suspend,
 read/write regs only if vpu is running
Message-ID: <20210423172745.30092-1-dafna.hirschfeld@collabora.com>

If the vpu is not running, we should not relay on VPU_IDLE_REG
value. In this case, the suspend cb should only unprepare the
clock. This fixes a system-wide suspend to ram failure:

[  273.073363] PM: suspend entry (deep)
[  273.410502] mtk-msdc 11230000.mmc: phase: [map:ffffffff] [maxlen:32] [final:10]
[  273.455926] Filesystems sync: 0.378 seconds
[  273.589707] Freezing user space processes ... (elapsed 0.003 seconds) done.
[  273.600104] OOM killer disabled.
[  273.603409] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  273.613361] mwifiex_sdio mmc2:0001:1: None of the WOWLAN triggers enabled
[  274.784952] mtk_vpu 10020000.vpu: vpu idle timeout
[  274.789764] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x70 returns -5
[  274.796740] mtk_vpu 10020000.vpu: PM: failed to suspend: error -5
[  274.802842] PM: Some devices failed to suspend, or early wake event detected
[  275.426489] OOM killer enabled.
[  275.429718] Restarting tasks ...
[  275.435765] done.
[  275.447510] PM: suspend exit

Fixes: 1f565e263c3e ("media: mtk-vpu: VPU should be in idle state before system is suspended")
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld at collabora.com>
---
 drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index 043894f7188c..f49f6d53a941 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -987,6 +987,12 @@ static int mtk_vpu_suspend(struct device *dev)
 		return ret;
 	}
 
+	if (!vpu_running(vpu)) {
+		vpu_clock_disable(vpu);
+		clk_unprepare(vpu->clk);
+		return 0;
+	}
+
 	mutex_lock(&vpu->vpu_mutex);
 	/* disable vpu timer interrupt */
 	vpu_cfg_writel(vpu, vpu_cfg_readl(vpu, VPU_INT_STATUS) | VPU_IDLE_STATE,
-- 
2.17.1



From andriy.shevchenko at linux.intel.com  Fri Apr 23 18:30:08 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 20:30:08 +0300
Subject: [PATCH v1 05/14] spi: pxa2xx: Consolidate related headers under
 include/linux/spi
In-Reply-To: <20210423165630.GH5507@sirena.org.uk>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
 <20210423163437.89306-5-andriy.shevchenko@linux.intel.com>
 <20210423165630.GH5507@sirena.org.uk>
Message-ID: <YIMEIEnt4meMP6Hx@smile.fi.intel.com>

On Fri, Apr 23, 2021 at 05:56:30PM +0100, Mark Brown wrote:
> On Fri, Apr 23, 2021 at 07:34:28PM +0300, Andy Shevchenko wrote:
> 
> > We have two headers split between include/linux and include/linux/spi.
> > Consolidated them under SPI realm, i.e. in the latter folder.
> 
> Why?  Isn't the point to maintain an abstraction between the general
> purpose use of the SSP IP and its application as a SPI controller?

Aren't the General Purpose of the SSP IP is an SPI controller either way?
What you are talking about is probably GP SPI vs. private (dedicated) SPI.

But okay, I got the idea, I can drop this patch.

> I'd
> check the cover letter for the series but there doesn't seem to be one.

Set of cleanups here and there related to the SPI PXA2xx driver.
It's hard to add something else here.

-- 
With Best Regards,
Andy Shevchenko




From nsaenzju at redhat.com  Fri Apr 23 18:34:14 2021
From: nsaenzju at redhat.com (Nicolas Saenz Julienne)
Date: Fri, 23 Apr 2021 19:34:14 +0200
Subject: [PATCH] spi: bcm2835: Fix buffer overflow with CS able to go
 beyond limit.
In-Reply-To: <20210423162055.GE5507@sirena.org.uk>
References: <20210420083402.6950-1-joe.burmeister@devtank.co.uk>
 <c087ba2c-7839-02d1-a522-b104d8ffb8d2@gmail.com>
 <7c9f9376-1a80-b624-7b9e-0f6d04437c02@devtank.co.uk>
 <271ad212-a606-620e-3f0c-d6bff272be3c@gmail.com>
 <380624c4-82f3-0e6e-8cdb-8a9732636db8@devtank.co.uk>
 <20210423115724.GB5507@sirena.org.uk>
 <672e8d77-ee5c-f10f-0bd3-f8708dfc24c8@devtank.co.uk>
 <20210423162055.GE5507@sirena.org.uk>
Message-ID: <84cafe48637fd1deed7da2cd15eb2f7679545416.camel@redhat.com>

On Fri, 2021-04-23 at 17:20 +0100, Mark Brown wrote:
> On Fri, Apr 23, 2021 at 03:12:11PM +0100, Joe Burmeister wrote:
> > Of course we could just raise BCM2835_SPI_NUM_CS to 8 or more if that is
> > preferred. Does seams like the dynamic solution is less favoured.
> 
> The best thing would be to have it not have a single array of chip
> select specific data and instead store everything in the controller_data
> that's there per-device.

+1

All in all, it would make for a cleaner driver.

-- 
Nicol?s S?enz



From robh at kernel.org  Fri Apr 23 18:39:22 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 23 Apr 2021 12:39:22 -0500
Subject: [PATCH V7, RESEND 2/2] doc: mtk-wdt: support pre-timeout when
 the bark irq is available
In-Reply-To: <1619148020-2236-3-git-send-email-wangqing@vivo.com>
References: <1619148020-2236-1-git-send-email-wangqing@vivo.com>
 <1619148020-2236-3-git-send-email-wangqing@vivo.com>
Message-ID: <20210423173922.GA1308513@robh.at.kernel.org>

On Fri, 23 Apr 2021 11:20:20 +0800, Wang Qing wrote:
> Add description of pre-timeout in mtk-wdt.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From broonie at kernel.org  Fri Apr 23 18:49:25 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 23 Apr 2021 18:49:25 +0100
Subject: [PATCH v1 05/14] spi: pxa2xx: Consolidate related headers under
 include/linux/spi
In-Reply-To: <YIMEIEnt4meMP6Hx@smile.fi.intel.com>
References: <20210423163437.89306-1-andriy.shevchenko@linux.intel.com>
 <20210423163437.89306-5-andriy.shevchenko@linux.intel.com>
 <20210423165630.GH5507@sirena.org.uk>
 <YIMEIEnt4meMP6Hx@smile.fi.intel.com>
Message-ID: <20210423174924.GI5507@sirena.org.uk>

On Fri, Apr 23, 2021 at 08:30:08PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 23, 2021 at 05:56:30PM +0100, Mark Brown wrote:
> > On Fri, Apr 23, 2021 at 07:34:28PM +0300, Andy Shevchenko wrote:

> > > We have two headers split between include/linux and include/linux/spi.
> > > Consolidated them under SPI realm, i.e. in the latter folder.

> > Why?  Isn't the point to maintain an abstraction between the general
> > purpose use of the SSP IP and its application as a SPI controller?

> Aren't the General Purpose of the SSP IP is an SPI controller either way?
> What you are talking about is probably GP SPI vs. private (dedicated) SPI.

SPI and any other serial protocols that happen to come up - these
generic serial IPs also often get used for audio for example.

> > I'd
> > check the cover letter for the series but there doesn't seem to be one.

> Set of cleanups here and there related to the SPI PXA2xx driver.
> It's hard to add something else here.

It doesn't need to be much more than what you just wrote.
-------------- 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/20210423/a9645c3b/attachment.sig>

From catalin.marinas at arm.com  Fri Apr 23 18:51:34 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 23 Apr 2021 18:51:34 +0100
Subject: [PATCH] arm64: doc: Add brk/mmap/mremap() to the Tagged Address ABI
 Exceptions
Message-ID: <20210423175134.14838-1-catalin.marinas@arm.com>

Prior to commit dcde237319e6 ("mm: Avoid creating virtual address
aliases in brk()/mmap()/mremap()"), the kernel allowed tagged addresses
to be passed to the brk/mmap/mremap() syscalls. This relaxation was
tightened in 5.6 (backported to stable 5.4) but the
tagged-address-abi.rst document was only partially updated.

Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
Fixes: dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()")
Reported-by: Peter Maydell <peter.maydell at linaro.org>
Cc: Will Deacon <will at kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino at arm.com>
---
 Documentation/arm64/tagged-address-abi.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
index cbc4d4500241..459e6b66ff68 100644
--- a/Documentation/arm64/tagged-address-abi.rst
+++ b/Documentation/arm64/tagged-address-abi.rst
@@ -113,6 +113,12 @@ ABI relaxation:
 
 - ``shmat()`` and ``shmdt()``.
 
+- ``brk()`` (since kernel v5.6).
+
+- ``mmap()`` (since kernel v5.6).
+
+- ``mremap()``, the ``new_address`` argument (since kernel v5.6).
+
 Any attempt to use non-zero tagged pointers may result in an error code
 being returned, a (fatal) signal being raised, or other modes of
 failure.


From marex at denx.de  Fri Apr 23 18:57:01 2021
From: marex at denx.de (Marek Vasut)
Date: Fri, 23 Apr 2021 19:57:01 +0200
Subject: [PATCH V2] ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulators
Message-ID: <20210423175701.76637-1-marex@denx.de>

Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1
via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied
from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs.

While no instability or problems are currently observed, the regulators
should be fully described in DT and that description should fully match
the hardware, else this might lead to unforseen issues later. Fix this.

Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
Cc: Christoph Niedermaier <cniedermaier at dh-electronics.com>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Ludwig Zenz <lzenz at dh-electronics.com>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: stable at vger.kernel.org
---
V2: Amend commit message
---
 arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
index 236fc205c389..d0768ae429fa 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
@@ -406,6 +406,18 @@ &reg_soc {
 	vin-supply = <&sw1_reg>;
 };
 
+&reg_pu {
+	vin-supply = <&sw1_reg>;
+};
+
+&reg_vdd1p1 {
+	vin-supply = <&sw2_reg>;
+};
+
+&reg_vdd2p5 {
+	vin-supply = <&sw2_reg>;
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1>;
-- 
2.30.2



From ebiederm at xmission.com  Fri Apr 23 19:17:07 2021
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 23 Apr 2021 13:17:07 -0500
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <20210422192349.ekpinkf3wxnmywe3@revolver> (Liam Howlett's
 message of "Thu, 22 Apr 2021 19:24:00 +0000")
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck>
 <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver>
Message-ID: <m1y2d8dfx8.fsf@fess.ebiederm.org>

Liam Howlett <liam.howlett at oracle.com> writes:

> * Eric W. Biederman <ebiederm at xmission.com> [210422 14:23]:
>> Will Deacon <will at kernel.org> writes:
>> 
>> > [+Eric as he actually understands how this is supposed to work]
>> 
>> I try.
>> 
>
> Thanks to both of you for looking at this.
>
>> > On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
>> >> arm64_notify_segfault() was used to force a SIGSEGV in all error cases
>> >> in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
>> >> There is now a better sig handler to use which does not search the VMA
>> >> address space and return a slightly incorrect error code.  Restore the
>> >> older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
>> >> the case of !access_ok(), simply return SIGSEGV with si_code
>> >> SEGV_ACCERR.
>> 
>> What is userspace cares?  Why does it care?
>
>
> Calling arm64_notify_segfault() as it is written is unreliable.
> Searching for the address with find_vma() will return SEG_ACCERR almost
> always, unless the address is larger than anything within *any* VMA.
> I'm trying to fix this issue by cleaning up the callers to that function
> and fix the function itself.

I can't see the rest of the patches in your series so I am not quite
certain what you are doing.

Looking at the places that arm64_notify_segfault is called I do
think you are right to be suspicious of that function.

swp_handler seems a legitimate user as it emulates an instruction.
For that case at least you should probably add the necessary
check to see if the address is contained in the returned vma.

user_cache_maint_handler calls it with the tagged address, when
it should use an untagged address with find_vma.  Otherwise
user_cache_maint_handler is also performing instruction emulation
and should work the same as swp_handler.

The only other users are in sigreturn and rt_sigreturn, where the
address is iffy.  But assuming the proper address is passed sigreturn
and rt_sigreturn are also performing instruction emulation.

> I don't have an example of why userspace cares about SI_KERNEL vs
> SEGV_ACCERR/SEGV_MAPERR, but the git log on f71016a8a8c5 specifies that
> this function was used to avoid having specific code to print an error
> code.  I am restoring the old return code as it seems to makes more
> sense and avoids the bug in the calling path.  If you'd rather, I can
> change the notify_die line to use SIG_ACCERR as this is *almost* always
> what is returend - except when the above mentioned bug is hit.  Upon
> examining the code here, it seems unnecessary to walk the VMA tree to
> find where the address lands in either of the error scenarios to know
> what should be returned.

Ignoring the possibility of a parse error what the code has is -EFAULT.
If we want to distinguish between SEGV_ACCERR and SEGV_MAPERR we need
the find_vma (and confirmation that the found vma contains the specified
address) to see if there is a mapping at the specified address.

Or as you point out later this could be a SIGBUS situation.

>> This is changing userspace visible semantics so understanding userspace
>> and understanding how it might break, and what the risk of regression
>> seems the most important detail here.
>> 
>> >> This change requires exporting arm64_notfiy_die() to the arm64 traps.h
>> >> 
>> >> Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
>> >> failing to deliver signal)
>> >> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
>> >> ---
>> >>  arch/arm64/include/asm/traps.h |  2 ++
>> >>  arch/arm64/kernel/signal.c     |  8 ++++++--
>> >>  arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
>> >>  3 files changed, 22 insertions(+), 6 deletions(-)
>> >> 
>> >> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
>> >> index 54f32a0675df..9b76144fcba6 100644
>> >> --- a/arch/arm64/include/asm/traps.h
>> >> +++ b/arch/arm64/include/asm/traps.h
>> >> @@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
>> >>  void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
>> >>  void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
>> >>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
>> >> +void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
>> >> +		      int sicode, unsigned long far, int err);
>> >>  
>> >>  /*
>> >>   * Move regs->pc to next instruction and do necessary setup before it
>> >> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
>> >> index 6237486ff6bb..9fde6dc760c3 100644
>> >> --- a/arch/arm64/kernel/signal.c
>> >> +++ b/arch/arm64/kernel/signal.c
>> >> @@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
>> >>  	frame = (struct rt_sigframe __user *)regs->sp;
>> >>  
>> >>  	if (!access_ok(frame, sizeof (*frame)))
>> >> -		goto badframe;
>> >> +		goto e_access;
>> >>  
>> >>  	if (restore_sigframe(regs, frame))
>> >>  		goto badframe;
>> >> @@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
>> >>  	return regs->regs[0];
>> >>  
>> >>  badframe:
>> >> -	arm64_notify_segfault(regs->sp);
>> >> +	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
>> >> +	return 0;
>> >> +
>> >> +e_access:
>> >> +	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
>> >>  	return 0;
>> >
>> > This seems really error-prone to me, but maybe I'm just missing some
>> > context. What's the rule for reporting an si_code of SI_KERNEL vs
>> > SEGV_ACCERR, and is the former actually valid for SIGSEGV?
>> 
>> The si_codes SI_USER == 0 and SI_KERNEL == 0x80 are valid for all
>> signals.  SI_KERNEL means I don't have any information for you other
>> than signal number.
>> 
>> In general something better than SI_KERNEL is desirable.
>
> I went with SI_KERNEL as that's what was there before.  I have no strong
> opinion on what should be returned; I do favour SIGBUS with si_code of
> BUS_ADRALN but I didn't want to change user visable code too much -
> especially to fix a bug in another function.

I hadn't noticed earlier, but I agree that what the code is doing is a
little strange.  I get SIGBUS and SIGEGV confused when I have not looked
at the recently.  I think SIGBUS is for mapped access that fail, and
SIGSEGV is for everything else.  

>> > With this change, pointing the (signal) stack to a kernel address will
>> > result in SEGV_ACCERR but pointing it to something like a PROT_NONE user
>> > address will give SI_KERNEL (well, assuming that we manage to deliver
>> > the SEGV somehow). I'm having a hard time seeing why that's a useful
>> > distinction to make..
>> >
>> > If it's important to get this a particular way around, please can you
>> > add some selftests?
>> 
>> Going down the current path I see 3 possible cases:
>> 
>> copy_from_user returns -EFAULT which becomes SEGV_MAPERR or SEGV_ACCERR.
>
> Almost always SEGV_ACCERR with the current bug, as mentioned above.
> find_vma() searches from addr until the end of the address space, it
> isn't just a simple lookup of the address.

Which is clearly a logic error.

In practice I don't know if anyone cares how sigreturn fails so we are
in a grey area.

>> A signal frame parse error.  For which SI_KERNEL seems as good an error
>> code as any.
>> 
>> 
>> On x86 there is no attempt to figure out the cause of the -EFAULT, and
>> always uses SI_KERNEL.  This is because x86 just does:
>> "force_sig(SIGSEGV);" As arm64 did until f71016a8a8c5 ("arm64: signal:
>> Call arm64_notify_segfault when failing to deliver signal")
>> 
>> 
>> 
>> I think the big question is what does it make sense to do here.
>> 
>> The big picture.  Upon return from a signal the kernel arranges
>> for rt_sigreturn to be called to return to a pre-signal state.
>> As such rt_sigreturn can not return an error code.
>> 
>> In general the kernel will write the signal frame and that will
>> guarantee that the signal from can be processes by rt_sigreturn.
>> 
>> For error handling we are dealing with the case that userspace
>> has modified the signal frame.  So that it either does not
>> parse or that it is unmapped.
>> 
>> 
>> So who cares?  The only two cases I can think of are debuggers, and
>> programs playing fancy memory management games like garbage collections.
>> I have heard of applications (like garbage collectors)
>> unmapping/mprotecting memory to create a barrier.
>> 
>> Liam Howlett is that the issue here?  Is not seeing SI_KERNEL confusing
>> the JVM?
>
> No, the issue here is that arm64_notify_segfault() has a bug which sent
> me down a rabbit hole of issues and I'm really trying my best to help
> out as best I can.  The bug certainly affects this function as it is
> written today, but my patch will generate a consistent signal.

Not so much.  There are other cases where -EFAULT causing a failing
return in that function.  So I think you have in practice made the
matter worse.  As after this patch it becomes less clear what the
return code is.

>> For debuggers I expect the stack backtrace from SIGSEGV is enough to see
>> that something is wrong.
>> 
>> For applications performing fancy processing of the signal frame I think
>> that tends to be very architecture specific.  In part because even
>> knowing the faulting address the size of the access is not known so the
>> instruction must be interpreted.  Getting a system call instead of a
>> load or store instruction might be enough to completely confuse
>> applications processing SEGV_MAPERR or SEGV_ACCERR.  Such applications
>> may also struggle with the fact that the address in siginfo is less
>> precise than it would be for an ordinary page fault.
>> 
>> 
>> So my sense is if you known you are helping userspace returning either
>> SEGV_MAPERR or SEGV_ACCERR go for it.  Otherwise there are enough
>> variables that returning less information when rt_sigreturn fails
>> would be more reliable.
>> 
>> 
>> Or in short what is userspace doing?  What does userspace care about?
>
> I think I've answered this, but it's more of trying to fix a bug which
> causes an *almost* reliable return code to be a reliable return code.
> Am I correct in stating that in both of these scnarios - !access_ok()
> and badframe, it is unnecessary to search the VMAs for where the address
> falls to know what error code to return?

You have answered you don't know what piece of userspace cares.

For access_ok failure you are correct we don't need a find_vma call
to tell what kind of failure we have.

For anything return -EFAULT we don't know as -EFAULT has less precision
than the instruction itself.

My sense is that you should concentrate on the userspace instruction
emulation case from swp_handler or user_cache_maint_handler.  Because
those instructions can run unemulated we know exactly what the semantics
should be in those cases.

I suspect arm64_notify_segfault should be renamed arm64_notify_fault
and generate SIGBUS or SIGSEGV as appropriate.

In fact I suspect that proper handling is to call __do_page_fault or
handle_mm_fault as do_page_fault does and then parse the VM_FAULT code
for which signal to generate.   Possibly factoring out a helper
converting VM_FAULT codes to signals.

Eric



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:29 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:29 +0300
Subject: [PATCH v2 02/14] spi: pxa2xx: Utilize MMIO and physical base from
 struct ssp_device
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-3-andriy.shevchenko@linux.intel.com>

We have a duplication of MMIO and physical base addresses in
the struct driver_data, get rid of it and reuse members from
struct ssp_device instead.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c |  4 ++--
 drivers/spi/spi-pxa2xx.c     |  4 +---
 drivers/spi/spi-pxa2xx.h     | 14 ++++----------
 3 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 37567bc7a523..3b27f356a18f 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -94,14 +94,14 @@ pxa2xx_spi_dma_prepare_one(struct driver_data *drv_data,
 	cfg.direction = dir;
 
 	if (dir == DMA_MEM_TO_DEV) {
-		cfg.dst_addr = drv_data->ssdr_physical;
+		cfg.dst_addr = drv_data->ssp->phys_base + SSDR;
 		cfg.dst_addr_width = width;
 		cfg.dst_maxburst = chip->dma_burst_size;
 
 		sgt = &xfer->tx_sg;
 		chan = drv_data->controller->dma_tx;
 	} else {
-		cfg.src_addr = drv_data->ssdr_physical;
+		cfg.src_addr = drv_data->ssp->phys_base + SSDR;
 		cfg.src_addr_width = width;
 		cfg.src_maxburst = chip->dma_burst_size;
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0ef22045b006..82df028c4a71 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -325,7 +325,7 @@ static void lpss_ssp_setup(struct driver_data *drv_data)
 	u32 value;
 
 	config = lpss_get_config(drv_data);
-	drv_data->lpss_base = drv_data->ioaddr + config->offset;
+	drv_data->lpss_base = drv_data->ssp->mmio_base + config->offset;
 
 	/* Enable software chip select control */
 	value = __lpss_ssp_read_priv(drv_data, config->reg_cs_ctrl);
@@ -1729,8 +1729,6 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 
 	drv_data->ssp_type = ssp->type;
 
-	drv_data->ioaddr = ssp->mmio_base;
-	drv_data->ssdr_physical = ssp->phys_base + SSDR;
 	if (pxa25x_ssp_comp(drv_data)) {
 		switch (drv_data->ssp_type) {
 		case QUARK_X1000_SSP:
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 1400472bc986..ad9980ebefa6 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -33,10 +33,6 @@ struct driver_data {
 	/* PXA hookup */
 	struct pxa2xx_spi_controller *controller_info;
 
-	/* SSP register addresses */
-	void __iomem *ioaddr;
-	phys_addr_t ssdr_physical;
-
 	/* SSP masks*/
 	u32 dma_cr1;
 	u32 int_cr1;
@@ -87,16 +83,14 @@ struct chip_data {
 	void (*cs_control)(u32 command);
 };
 
-static inline u32 pxa2xx_spi_read(const struct driver_data *drv_data,
-				  unsigned reg)
+static inline u32 pxa2xx_spi_read(const struct driver_data *drv_data, u32 reg)
 {
-	return __raw_readl(drv_data->ioaddr + reg);
+	return pxa_ssp_read_reg(drv_data->ssp, reg);
 }
 
-static  inline void pxa2xx_spi_write(const struct driver_data *drv_data,
-				     unsigned reg, u32 val)
+static inline void pxa2xx_spi_write(const struct driver_data *drv_data, u32 reg, u32 val)
 {
-	__raw_writel(val, drv_data->ioaddr + reg);
+	pxa_ssp_write_reg(drv_data->ssp, reg, val);
 }
 
 #define DMA_ALIGNMENT		8
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:28 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:28 +0300
Subject: [PATCH v2 01/14] spi: pxa2xx: Use one point of return when ->probe()
 fails
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-2-andriy.shevchenko@linux.intel.com>

When we can't allocate SPI controller, jump to the error path rather than
return locally.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0cc767283674..0ef22045b006 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1701,8 +1701,8 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 
 	if (!controller) {
 		dev_err(&pdev->dev, "cannot alloc spi_controller\n");
-		pxa_ssp_free(ssp);
-		return -ENOMEM;
+		status = -ENOMEM;
+		goto out_error_controller_alloc;
 	}
 	drv_data = spi_controller_get_devdata(controller);
 	drv_data->controller = controller;
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:31 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:31 +0300
Subject: [PATCH v2 04/14] spi: pxa2xx: Replace header inclusions by forward
 declarations
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-5-andriy.shevchenko@linux.intel.com>

When the data structure is only referred by pointer, compiler may not need
to see the contents of the data type. Thus, we may replace header inclusions
by respective forward declarations. Due to above add missed headers as well.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c   |  4 ++--
 drivers/spi/spi-pxa2xx-pci.c   |  1 +
 drivers/spi/spi-pxa2xx.c       |  2 ++
 drivers/spi/spi-pxa2xx.h       | 18 ++++++++++--------
 include/linux/spi/pxa2xx_spi.h |  2 ++
 5 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 2e4a49567146..e00dbadd39ec 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -9,11 +9,11 @@
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/dmaengine.h>
-#include <linux/pxa2xx_ssp.h>
 #include <linux/scatterlist.h>
 #include <linux/sizes.h>
-#include <linux/spi/spi.h>
+
 #include <linux/spi/pxa2xx_spi.h>
+#include <linux/spi/spi.h>
 
 #include "spi-pxa2xx.h"
 
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index f60ed4c62000..5af0a3fbc1b0 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -8,6 +8,7 @@
 #include <linux/module.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
+
 #include <linux/spi/pxa2xx_spi.h>
 
 #include <linux/dmaengine.h>
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index e9dddcbd92f1..0296cbdee848 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -9,6 +9,7 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/dmaengine.h>
 #include <linux/err.h>
 #include <linux/errno.h>
 #include <linux/gpio/consumer.h>
@@ -25,6 +26,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/property.h>
 #include <linux/slab.h>
+
 #include <linux/spi/pxa2xx_spi.h>
 #include <linux/spi/spi.h>
 
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 6724d7e056ce..739e264feaa6 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -7,16 +7,18 @@
 #ifndef SPI_PXA2XX_H
 #define SPI_PXA2XX_H
 
-#include <linux/atomic.h>
-#include <linux/dmaengine.h>
-#include <linux/errno.h>
-#include <linux/io.h>
 #include <linux/interrupt.h>
-#include <linux/pxa2xx_ssp.h>
-#include <linux/scatterlist.h>
+#include <linux/io.h>
+#include <linux/types.h>
 #include <linux/sizes.h>
-#include <linux/spi/spi.h>
-#include <linux/spi/pxa2xx_spi.h>
+
+#include <linux/pxa2xx_ssp.h>
+
+struct gpio_desc;
+struct pxa2xx_spi_controller;
+struct spi_controller;
+struct spi_device;
+struct spi_transfer;
 
 struct driver_data {
 	/* SSP Info */
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
index 31f00c7f4f59..1e0e2f136319 100644
--- a/include/linux/spi/pxa2xx_spi.h
+++ b/include/linux/spi/pxa2xx_spi.h
@@ -5,6 +5,8 @@
 #ifndef __linux_pxa2xx_spi_h
 #define __linux_pxa2xx_spi_h
 
+#include <linux/types.h>
+
 #include <linux/pxa2xx_ssp.h>
 
 #define PXA2XX_CS_ASSERT (0x01)
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:27 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:27 +0300
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
Message-ID: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>

Set of cleanups here and there related to the SPI PXA2xx driver.
On top of them, adding the special type for Intel Merrifield.

In v2:
- cover letter (Mark)
- drop moving the header in patch 5 (Mark)

Andy Shevchenko (14):
  spi: pxa2xx: Use one point of return when ->probe() fails
  spi: pxa2xx: Utilize MMIO and physical base from struct ssp_device
  spi: pxa2xx: Utilize struct device from struct ssp_device
  spi: pxa2xx: Replace header inclusions by forward declarations
  spi: pxa2xx: Unify ifdeffery used in the headers
  spi: pxa2xx: Group Intel Quark specific definitions
  spi: pxa2xx: Introduce int_stop_and_reset() helper
  spi: pxa2xx: Reuse int_error_stop() in pxa2xx_spi_slave_abort()
  spi: pxa2xx: Use pxa_ssp_enable()/pxa_ssp_disable() in the driver
  spi: pxa2xx: Extract pxa2xx_spi_update() helper
  spi: pxa2xx: Extract clear_SSCR1_bits() helper
  spi: pxa2xx: Extract read_SSSR_bits() helper
  spi: pxa2xx: Constify struct driver_data parameter
  spi: pxa2xx: Introduce special type for Merrifield SPIs

 drivers/spi/spi-pxa2xx-dma.c   |  37 +++----
 drivers/spi/spi-pxa2xx-pci.c   |   4 +-
 drivers/spi/spi-pxa2xx.c       | 190 +++++++++++++++++----------------
 drivers/spi/spi-pxa2xx.h       |  52 ++++-----
 include/linux/pxa2xx_ssp.h     |  42 +++++++-
 include/linux/spi/pxa2xx_spi.h |   9 +-
 sound/soc/pxa/pxa-ssp.c        |  16 ---
 7 files changed, 185 insertions(+), 165 deletions(-)

-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:30 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:30 +0300
Subject: [PATCH v2 03/14] spi: pxa2xx: Utilize struct device from struct
 ssp_device
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-4-andriy.shevchenko@linux.intel.com>

We have a duplication of struct device in the struct driver_data,
get rid of it and reuse member from struct ssp_device instead.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c | 12 +++++-------
 drivers/spi/spi-pxa2xx-pci.c |  1 +
 drivers/spi/spi-pxa2xx.c     | 12 +++++-------
 drivers/spi/spi-pxa2xx.h     |  4 ----
 4 files changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 3b27f356a18f..2e4a49567146 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -111,7 +111,7 @@ pxa2xx_spi_dma_prepare_one(struct driver_data *drv_data,
 
 	ret = dmaengine_slave_config(chan, &cfg);
 	if (ret) {
-		dev_warn(&drv_data->pdev->dev, "DMA slave config failed\n");
+		dev_warn(drv_data->ssp->dev, "DMA slave config failed\n");
 		return NULL;
 	}
 
@@ -125,7 +125,7 @@ irqreturn_t pxa2xx_spi_dma_transfer(struct driver_data *drv_data)
 
 	status = pxa2xx_spi_read(drv_data, SSSR) & drv_data->mask_sr;
 	if (status & SSSR_ROR) {
-		dev_err(&drv_data->pdev->dev, "FIFO overrun\n");
+		dev_err(drv_data->ssp->dev, "FIFO overrun\n");
 
 		dmaengine_terminate_async(drv_data->controller->dma_rx);
 		dmaengine_terminate_async(drv_data->controller->dma_tx);
@@ -145,16 +145,14 @@ int pxa2xx_spi_dma_prepare(struct driver_data *drv_data,
 
 	tx_desc = pxa2xx_spi_dma_prepare_one(drv_data, DMA_MEM_TO_DEV, xfer);
 	if (!tx_desc) {
-		dev_err(&drv_data->pdev->dev,
-			"failed to get DMA TX descriptor\n");
+		dev_err(drv_data->ssp->dev, "failed to get DMA TX descriptor\n");
 		err = -EBUSY;
 		goto err_tx;
 	}
 
 	rx_desc = pxa2xx_spi_dma_prepare_one(drv_data, DMA_DEV_TO_MEM, xfer);
 	if (!rx_desc) {
-		dev_err(&drv_data->pdev->dev,
-			"failed to get DMA RX descriptor\n");
+		dev_err(drv_data->ssp->dev, "failed to get DMA RX descriptor\n");
 		err = -EBUSY;
 		goto err_rx;
 	}
@@ -191,8 +189,8 @@ void pxa2xx_spi_dma_stop(struct driver_data *drv_data)
 int pxa2xx_spi_dma_setup(struct driver_data *drv_data)
 {
 	struct pxa2xx_spi_controller *pdata = drv_data->controller_info;
-	struct device *dev = &drv_data->pdev->dev;
 	struct spi_controller *controller = drv_data->controller;
+	struct device *dev = drv_data->ssp->dev;
 	dma_cap_mask_t mask;
 
 	dma_cap_zero(mask);
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 14fc41ed2361..f60ed4c62000 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -239,6 +239,7 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
 	spi_pdata.dma_burst_size = c->dma_burst_size ? c->dma_burst_size : 1;
 
 	ssp = &spi_pdata.ssp;
+	ssp->dev = &dev->dev;
 	ssp->phys_base = pci_resource_start(dev, 0);
 	ssp->mmio_base = pcim_iomap_table(dev)[0];
 	ssp->port_id = (c->port_id >= 0) ? c->port_id : dev->devfn;
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 82df028c4a71..e9dddcbd92f1 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -628,7 +628,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-	dev_err(&drv_data->pdev->dev, "%s\n", msg);
+	dev_err(drv_data->ssp->dev, "%s\n", msg);
 
 	drv_data->controller->cur_msg->status = -EIO;
 	spi_finalize_current_transfer(drv_data->controller);
@@ -731,8 +731,7 @@ static void handle_bad_msg(struct driver_data *drv_data)
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 
-	dev_err(&drv_data->pdev->dev,
-		"bad message state in interrupt handler\n");
+	dev_err(drv_data->ssp->dev, "bad message state in interrupt handler\n");
 }
 
 static irqreturn_t ssp_int(int irq, void *dev_id)
@@ -748,7 +747,7 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
 	 * the IRQ was not for us (we shouldn't be RPM suspended when the
 	 * interrupt is enabled).
 	 */
-	if (pm_runtime_suspended(&drv_data->pdev->dev))
+	if (pm_runtime_suspended(drv_data->ssp->dev))
 		return IRQ_NONE;
 
 	/*
@@ -1158,7 +1157,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-	dev_dbg(&drv_data->pdev->dev, "transfer aborted\n");
+	dev_dbg(drv_data->ssp->dev, "transfer aborted\n");
 
 	drv_data->controller->cur_msg->status = -EINTR;
 	spi_finalize_current_transfer(drv_data->controller);
@@ -1641,7 +1640,7 @@ static int pxa2xx_spi_fw_translate_cs(struct spi_controller *controller,
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	if (has_acpi_companion(&drv_data->pdev->dev)) {
+	if (has_acpi_companion(drv_data->ssp->dev)) {
 		switch (drv_data->ssp_type) {
 		/*
 		 * For Atoms the ACPI DeviceSelection used by the Windows
@@ -1707,7 +1706,6 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 	drv_data = spi_controller_get_devdata(controller);
 	drv_data->controller = controller;
 	drv_data->controller_info = platform_info;
-	drv_data->pdev = pdev;
 	drv_data->ssp = ssp;
 
 	controller->dev.of_node = pdev->dev.of_node;
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index ad9980ebefa6..6724d7e056ce 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -12,7 +12,6 @@
 #include <linux/errno.h>
 #include <linux/io.h>
 #include <linux/interrupt.h>
-#include <linux/platform_device.h>
 #include <linux/pxa2xx_ssp.h>
 #include <linux/scatterlist.h>
 #include <linux/sizes.h>
@@ -20,9 +19,6 @@
 #include <linux/spi/pxa2xx_spi.h>
 
 struct driver_data {
-	/* Driver model hookup */
-	struct platform_device *pdev;
-
 	/* SSP Info */
 	struct ssp_device *ssp;
 
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:37 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:37 +0300
Subject: [PATCH v2 10/14] spi: pxa2xx: Extract pxa2xx_spi_update() helper
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-11-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "update if changed".
Extract pxa2xx_spi_update() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 33 ++++++++++++++-------------------
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index f85c7439757c..4b3237f14ead 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -200,6 +200,12 @@ static bool is_mmp2_ssp(const struct driver_data *drv_data)
 	return drv_data->ssp_type == MMP2_SSP;
 }
 
+static void pxa2xx_spi_update(const struct driver_data *drv_data, u32 reg, u32 mask, u32 value)
+{
+	if ((pxa2xx_spi_read(drv_data, reg) & mask) != value)
+		pxa2xx_spi_write(drv_data, reg, value & mask);
+}
+
 static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data *drv_data)
 {
 	switch (drv_data->ssp_type) {
@@ -1081,19 +1087,12 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 			dma_mapped ? "DMA" : "PIO");
 
 	if (is_lpss_ssp(drv_data)) {
-		if ((pxa2xx_spi_read(drv_data, SSIRF) & 0xff)
-		    != chip->lpss_rx_threshold)
-			pxa2xx_spi_write(drv_data, SSIRF,
-					 chip->lpss_rx_threshold);
-		if ((pxa2xx_spi_read(drv_data, SSITF) & 0xffff)
-		    != chip->lpss_tx_threshold)
-			pxa2xx_spi_write(drv_data, SSITF,
-					 chip->lpss_tx_threshold);
+		pxa2xx_spi_update(drv_data, SSIRF, GENMASK(7, 0), chip->lpss_rx_threshold);
+		pxa2xx_spi_update(drv_data, SSITF, GENMASK(15, 0), chip->lpss_tx_threshold);
 	}
 
-	if (is_quark_x1000_ssp(drv_data) &&
-	    (pxa2xx_spi_read(drv_data, DDS_RATE) != chip->dds_rate))
-		pxa2xx_spi_write(drv_data, DDS_RATE, chip->dds_rate);
+	if (is_quark_x1000_ssp(drv_data))
+		pxa2xx_spi_update(drv_data, DDS_RATE, GENMASK(23, 0), chip->dds_rate);
 
 	/* Stop the SSP */
 	if (!is_mmp2_ssp(drv_data))
@@ -1102,15 +1101,11 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 
+	/* first set CR1 without interrupt and service enables */
+	pxa2xx_spi_update(drv_data, SSCR1, change_mask, cr1);
+
 	/* see if we need to reload the config registers */
-	if ((pxa2xx_spi_read(drv_data, SSCR0) != cr0)
-	    || (pxa2xx_spi_read(drv_data, SSCR1) & change_mask)
-	    != (cr1 & change_mask)) {
-		/* first set CR1 without interrupt and service enables */
-		pxa2xx_spi_write(drv_data, SSCR1, cr1 & change_mask);
-		/* Update the other bits */
-		pxa2xx_spi_write(drv_data, SSCR0, cr0);
-	}
+	pxa2xx_spi_update(drv_data, SSCR0, GENMASK(31, 0), cr0);
 
 	/* Restart the SSP */
 	pxa_ssp_enable(drv_data->ssp);
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:33 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:33 +0300
Subject: [PATCH v2 06/14] spi: pxa2xx: Group Intel Quark specific definitions
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-7-andriy.shevchenko@linux.intel.com>

DDS_RATE is Intel Quark specific definition. Move it to the rest
Intel Quark related.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 include/linux/pxa2xx_ssp.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 14b049840faf..1b6c1a0922bd 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -38,7 +38,6 @@ struct device_node;
 #define SSDR		(0x10)  /* SSP Data Write/Data Read Register */
 
 #define SSTO		(0x28)  /* SSP Time Out Register */
-#define DDS_RATE	(0x28)  /* SSP DDS Clock Rate Register (Intel Quark) */
 #define SSPSP		(0x2C)  /* SSP Programmable Serial Protocol */
 #define SSTSA		(0x30)  /* SSP Tx Timeslot Active */
 #define SSRSA		(0x34)  /* SSP Rx Timeslot Active */
@@ -105,6 +104,9 @@ struct device_node;
 #define CE4100_SSCR1_RFT	GENMASK(11, 10)	/* Receive FIFO Threshold (mask) */
 #define CE4100_SSCR1_RxTresh(x) (((x) - 1) << 10)	/* level [1..4] */
 
+/* Intel Quark X1000 */
+#define DDS_RATE		0x28		 /* SSP DDS Clock Rate Register */
+
 /* QUARK_X1000 SSCR0 bit definition */
 #define QUARK_X1000_SSCR0_DSS		GENMASK(4, 0)	/* Data Size Select (mask) */
 #define QUARK_X1000_SSCR0_DataSize(x)	((x) - 1)	/* Data Size Select [4..32] */
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:41 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:41 +0300
Subject: [PATCH v2 14/14] spi: pxa2xx: Introduce special type for Merrifield
 SPIs
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-15-andriy.shevchenko@linux.intel.com>

Intel Merrifield SPI is actually more closer to PXA3xx. It has extended FIFO
(32 bytes) and additional registers to get or set FIFO thresholds.

Introduce new type for Intel Merrifield SPI host controllers and handle bigger
FIFO size.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-pci.c |  2 +-
 drivers/spi/spi-pxa2xx.c     | 32 +++++++++++++++++++++++++++++---
 include/linux/pxa2xx_ssp.h   | 16 ++++++++++++++++
 3 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 5af0a3fbc1b0..5df6e11b345d 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -179,7 +179,7 @@ static struct pxa_spi_info spi_info_configs[] = {
 		.rx_param = &bsw2_rx_param,
 	},
 	[PORT_MRFLD] = {
-		.type = PXA27x_SSP,
+		.type = MRFLD_SSP,
 		.max_clk_rate = 25000000,
 		.setup = mrfld_spi_setup,
 	},
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 5a4f808eefde..313095bfa7dd 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -200,6 +200,11 @@ static bool is_mmp2_ssp(const struct driver_data *drv_data)
 	return drv_data->ssp_type == MMP2_SSP;
 }
 
+static bool is_mrfld_ssp(const struct driver_data *drv_data)
+{
+	return drv_data->ssp_type == MRFLD_SSP;
+}
+
 static void pxa2xx_spi_update(const struct driver_data *drv_data, u32 reg, u32 mask, u32 value)
 {
 	if ((pxa2xx_spi_read(drv_data, reg) & mask) != value)
@@ -1087,6 +1092,15 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 		pxa2xx_spi_update(drv_data, SSITF, GENMASK(15, 0), chip->lpss_tx_threshold);
 	}
 
+	if (is_mrfld_ssp(drv_data)) {
+		u32 thresh = 0;
+
+		thresh |= SFIFOTT_RxThresh(chip->lpss_rx_threshold);
+		thresh |= SFIFOTT_TxThresh(chip->lpss_tx_threshold);
+
+		pxa2xx_spi_update(drv_data, SFIFOTT, 0xffffffff, thresh);
+	}
+
 	if (is_quark_x1000_ssp(drv_data))
 		pxa2xx_spi_update(drv_data, DDS_RATE, GENMASK(23, 0), chip->dds_rate);
 
@@ -1253,6 +1267,11 @@ static int setup(struct spi_device *spi)
 		tx_hi_thres = 0;
 		rx_thres = RX_THRESH_QUARK_X1000_DFLT;
 		break;
+	case MRFLD_SSP:
+		tx_thres = TX_THRESH_MRFLD_DFLT;
+		tx_hi_thres = 0;
+		rx_thres = RX_THRESH_MRFLD_DFLT;
+		break;
 	case CE4100_SSP:
 		tx_thres = TX_THRESH_CE4100_DFLT;
 		tx_hi_thres = 0;
@@ -1328,9 +1347,16 @@ static int setup(struct spi_device *spi)
 		chip->cr1 |= SSCR1_SPH;
 	}
 
-	chip->lpss_rx_threshold = SSIRF_RxThresh(rx_thres);
-	chip->lpss_tx_threshold = SSITF_TxLoThresh(tx_thres)
-				| SSITF_TxHiThresh(tx_hi_thres);
+	if (is_lpss_ssp(drv_data)) {
+		chip->lpss_rx_threshold = SSIRF_RxThresh(rx_thres);
+		chip->lpss_tx_threshold = SSITF_TxLoThresh(tx_thres) |
+					  SSITF_TxHiThresh(tx_hi_thres);
+	}
+
+	if (is_mrfld_ssp(drv_data)) {
+		chip->lpss_rx_threshold = rx_thres;
+		chip->lpss_tx_threshold = tx_thres;
+	}
 
 	/* set dma burst and threshold outside of chip_info path so that if
 	 * chip_info goes away after setting chip->enable_dma, the
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index fdfbe17e15f4..2b21bc1f3c73 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -183,6 +183,21 @@ struct device_node;
 #define SSACD_ACPS(x)		((x) << 4)	/* Audio clock PLL select */
 #define SSACD_SCDX8		BIT(7)		/* SYSCLK division ratio select */
 
+/* Intel Merrifield SSP */
+#define SFIFOL			0x68		/* FIFO level */
+#define SFIFOTT			0x6c		/* FIFO trigger threshold */
+
+#define RX_THRESH_MRFLD_DFLT	16
+#define TX_THRESH_MRFLD_DFLT	16
+
+#define SFIFOL_TFL_MASK		GENMASK(15, 0)	/* Transmit FIFO Level mask */
+#define SFIFOL_RFL_MASK		GENMASK(31, 16)	/* Receive FIFO Level mask */
+
+#define SFIFOTT_TFT		GENMASK(15, 0)	/* Transmit FIFO Threshold (mask) */
+#define SFIFOTT_TxThresh(x)	(((x) - 1) << 0)	/* TX FIFO trigger threshold / level */
+#define SFIFOTT_RFT		GENMASK(31, 16)	/* Receive FIFO Threshold (mask) */
+#define SFIFOTT_RxThresh(x)	(((x) - 1) << 16)	/* RX FIFO trigger threshold / level */
+
 /* LPSS SSP */
 #define SSITF			0x44		/* TX FIFO trigger level */
 #define SSITF_TxHiThresh(x)	(((x) - 1) << 0)
@@ -205,6 +220,7 @@ enum pxa_ssp_type {
 	MMP2_SSP,
 	PXA910_SSP,
 	CE4100_SSP,
+	MRFLD_SSP,
 	QUARK_X1000_SSP,
 	LPSS_LPT_SSP, /* Keep LPSS types sorted with lpss_platforms[] */
 	LPSS_BYT_SSP,
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:34 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:34 +0300
Subject: [PATCH v2 07/14] spi: pxa2xx: Introduce int_stop_and_reset() helper
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-8-andriy.shevchenko@linux.intel.com>

Currently we have three times the same few lines repeated in the code.
Deduplicate them by newly introduced int_stop_and_reset() helper.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 0296cbdee848..4dab47e18d10 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -620,13 +620,20 @@ static void reset_sccr1(struct driver_data *drv_data)
 	pxa2xx_spi_write(drv_data, SSCR1, sccr1_reg);
 }
 
-static void int_error_stop(struct driver_data *drv_data, const char* msg)
+static void int_stop_and_reset(struct driver_data *drv_data)
 {
-	/* Stop and reset SSP */
+	/* Clear and disable interrupts */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	if (pxa25x_ssp_comp(drv_data))
+		return;
+
+	pxa2xx_spi_write(drv_data, SSTO, 0);
+}
+
+static void int_error_stop(struct driver_data *drv_data, const char *msg)
+{
+	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
@@ -638,11 +645,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 
 static void int_transfer_complete(struct driver_data *drv_data)
 {
-	/* Clear and disable interrupts */
-	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	int_stop_and_reset(drv_data);
 
 	spi_finalize_current_transfer(drv_data->controller);
 }
@@ -1151,11 +1154,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	/* Stop and reset SSP */
-	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	reset_sccr1(drv_data);
-	if (!pxa25x_ssp_comp(drv_data))
-		pxa2xx_spi_write(drv_data, SSTO, 0);
+	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
 	pxa2xx_spi_off(drv_data);
 
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:39 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:39 +0300
Subject: [PATCH v2 12/14] spi: pxa2xx: Extract read_SSSR_bits() helper
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-13-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "read some bits from SSSR".
Extract read_SSSR_bits() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c |  9 +++------
 drivers/spi/spi-pxa2xx.c     | 26 +++++++++++---------------
 drivers/spi/spi-pxa2xx.h     |  7 ++++++-
 3 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index e581027e99f9..f022d82dcb1b 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -34,11 +34,8 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 		 * might not know about the error yet. So we re-check the
 		 * ROR bit here before we clear the status register.
 		 */
-		if (!error) {
-			u32 status = pxa2xx_spi_read(drv_data, SSSR)
-				     & drv_data->mask_sr;
-			error = status & SSSR_ROR;
-		}
+		if (!error)
+			error = read_SSSR_bits(drv_data, drv_data->mask_sr) & SSSR_ROR;
 
 		/* Clear status & disable interrupts */
 		clear_SSCR1_bits(drv_data, drv_data->dma_cr1);
@@ -119,7 +116,7 @@ irqreturn_t pxa2xx_spi_dma_transfer(struct driver_data *drv_data)
 {
 	u32 status;
 
-	status = pxa2xx_spi_read(drv_data, SSSR) & drv_data->mask_sr;
+	status = read_SSSR_bits(drv_data, drv_data->mask_sr);
 	if (status & SSSR_ROR) {
 		dev_err(drv_data->ssp->dev, "FIFO overrun\n");
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 58178ba704dc..5a4f808eefde 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -247,7 +247,7 @@ static bool pxa2xx_spi_txfifo_full(const struct driver_data *drv_data)
 		break;
 	}
 
-	return (pxa2xx_spi_read(drv_data, SSSR) & mask) == mask;
+	return read_SSSR_bits(drv_data, mask) == mask;
 }
 
 static void pxa2xx_spi_clear_rx_thre(const struct driver_data *drv_data,
@@ -488,7 +488,7 @@ int pxa2xx_spi_flush(struct driver_data *drv_data)
 	unsigned long limit = loops_per_jiffy << 1;
 
 	do {
-		while (pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
+		while (read_SSSR_bits(drv_data, SSSR_RNE))
 			pxa2xx_spi_read(drv_data, SSDR);
 	} while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_BSY) && --limit);
 	write_SSSR_CS(drv_data, SSSR_ROR);
@@ -523,8 +523,7 @@ static int null_reader(struct driver_data *drv_data)
 {
 	u8 n_bytes = drv_data->n_bytes;
 
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += n_bytes;
 	}
@@ -546,8 +545,7 @@ static int u8_writer(struct driver_data *drv_data)
 
 static int u8_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u8 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		++drv_data->rx;
 	}
@@ -569,8 +567,7 @@ static int u16_writer(struct driver_data *drv_data)
 
 static int u16_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u16 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += 2;
 	}
@@ -592,8 +589,7 @@ static int u32_writer(struct driver_data *drv_data)
 
 static int u32_reader(struct driver_data *drv_data)
 {
-	while ((pxa2xx_spi_read(drv_data, SSSR) & SSSR_RNE)
-	       && (drv_data->rx < drv_data->rx_end)) {
+	while (read_SSSR_bits(drv_data, SSSR_RNE) && drv_data->rx < drv_data->rx_end) {
 		*(u32 *)(drv_data->rx) = pxa2xx_spi_read(drv_data, SSDR);
 		drv_data->rx += 4;
 	}
@@ -655,10 +651,11 @@ static void int_transfer_complete(struct driver_data *drv_data)
 
 static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 {
-	u32 irq_mask = (pxa2xx_spi_read(drv_data, SSCR1) & SSCR1_TIE) ?
-		       drv_data->mask_sr : drv_data->mask_sr & ~SSSR_TFS;
+	u32 irq_status;
 
-	u32 irq_status = pxa2xx_spi_read(drv_data, SSSR) & irq_mask;
+	irq_status = read_SSSR_bits(drv_data, drv_data->mask_sr);
+	if (!(pxa2xx_spi_read(drv_data, SSCR1) & SSCR1_TIE))
+		irq_status &= ~SSSR_TFS;
 
 	if (irq_status & SSSR_ROR) {
 		int_error_stop(drv_data, "interrupt_transfer: fifo overrun", -EIO);
@@ -1110,8 +1107,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	pxa_ssp_enable(drv_data->ssp);
 
 	if (is_mmp2_ssp(drv_data)) {
-		u8 tx_level = (pxa2xx_spi_read(drv_data, SSSR)
-					& SSSR_TFL_MASK) >> 8;
+		u8 tx_level = read_SSSR_bits(drv_data, SSSR_TFL_MASK) >> 8;
 
 		if (tx_level) {
 			/* On MMP2, flipping SSE doesn't to empty TXFIFO. */
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index ed63f7165cd8..d2cb40f97c4b 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -110,11 +110,16 @@ static inline void clear_SSCR1_bits(const struct driver_data *drv_data, u32 bits
 	pxa2xx_spi_write(drv_data, SSCR1, pxa2xx_spi_read(drv_data, SSCR1) & ~bits);
 }
 
+static inline u32 read_SSSR_bits(const struct driver_data *drv_data, u32 bits)
+{
+	return pxa2xx_spi_read(drv_data, SSSR) & bits;
+}
+
 static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
 	    drv_data->ssp_type == QUARK_X1000_SSP)
-		val |= pxa2xx_spi_read(drv_data, SSSR) & SSSR_ALT_FRM_MASK;
+		val |= read_SSSR_bits(drv_data, SSSR_ALT_FRM_MASK);
 
 	pxa2xx_spi_write(drv_data, SSSR, val);
 }
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:35 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:35 +0300
Subject: [PATCH v2 08/14] spi: pxa2xx: Reuse int_error_stop() in
 pxa2xx_spi_slave_abort()
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-9-andriy.shevchenko@linux.intel.com>

It appears that pxa2xx_spi_slave_abort()almost  repeats the functionality
of the int_error_stop(). Reuse int_error_stop() in pxa2xx_spi_slave_abort().

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.c | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4dab47e18d10..85a8d228a117 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -631,7 +631,7 @@ static void int_stop_and_reset(struct driver_data *drv_data)
 	pxa2xx_spi_write(drv_data, SSTO, 0);
 }
 
-static void int_error_stop(struct driver_data *drv_data, const char *msg)
+static void int_error_stop(struct driver_data *drv_data, const char *msg, int err)
 {
 	int_stop_and_reset(drv_data);
 	pxa2xx_spi_flush(drv_data);
@@ -639,7 +639,7 @@ static void int_error_stop(struct driver_data *drv_data, const char *msg)
 
 	dev_err(drv_data->ssp->dev, "%s\n", msg);
 
-	drv_data->controller->cur_msg->status = -EIO;
+	drv_data->controller->cur_msg->status = err;
 	spi_finalize_current_transfer(drv_data->controller);
 }
 
@@ -658,12 +658,12 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 	u32 irq_status = pxa2xx_spi_read(drv_data, SSSR) & irq_mask;
 
 	if (irq_status & SSSR_ROR) {
-		int_error_stop(drv_data, "interrupt_transfer: fifo overrun");
+		int_error_stop(drv_data, "interrupt_transfer: fifo overrun", -EIO);
 		return IRQ_HANDLED;
 	}
 
 	if (irq_status & SSSR_TUR) {
-		int_error_stop(drv_data, "interrupt_transfer: fifo underrun");
+		int_error_stop(drv_data, "interrupt_transfer: fifo underrun", -EIO);
 		return IRQ_HANDLED;
 	}
 
@@ -1154,14 +1154,7 @@ static int pxa2xx_spi_slave_abort(struct spi_controller *controller)
 {
 	struct driver_data *drv_data = spi_controller_get_devdata(controller);
 
-	int_stop_and_reset(drv_data);
-	pxa2xx_spi_flush(drv_data);
-	pxa2xx_spi_off(drv_data);
-
-	dev_dbg(drv_data->ssp->dev, "transfer aborted\n");
-
-	drv_data->controller->cur_msg->status = -EINTR;
-	spi_finalize_current_transfer(drv_data->controller);
+	int_error_stop(drv_data, "transfer aborted", -EINTR);
 
 	return 0;
 }
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:40 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:40 +0300
Subject: [PATCH v2 13/14] spi: pxa2xx: Constify struct driver_data parameter
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-14-andriy.shevchenko@linux.intel.com>

In a couple of functions the contents of struct driver_data are not altered,
hence we may constify the respective function parameter.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index d2cb40f97c4b..5c6a5e0f249e 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -93,7 +93,7 @@ static inline void pxa2xx_spi_write(const struct driver_data *drv_data, u32 reg,
 
 #define DMA_ALIGNMENT		8
 
-static inline int pxa25x_ssp_comp(struct driver_data *drv_data)
+static inline int pxa25x_ssp_comp(const struct driver_data *drv_data)
 {
 	switch (drv_data->ssp_type) {
 	case PXA25x_SSP:
@@ -115,7 +115,7 @@ static inline u32 read_SSSR_bits(const struct driver_data *drv_data, u32 bits)
 	return pxa2xx_spi_read(drv_data, SSSR) & bits;
 }
 
-static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
+static inline void write_SSSR_CS(const struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
 	    drv_data->ssp_type == QUARK_X1000_SSP)
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:32 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:32 +0300
Subject: [PATCH v2 05/14] spi: pxa2xx: Unify ifdeffery used in the headers
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-6-andriy.shevchenko@linux.intel.com>

The two headers have quite different ifdeffery to prevent multiple inclusion.
Unify them with the pattern that in particular reflects their location.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 include/linux/pxa2xx_ssp.h     | 6 +++---
 include/linux/spi/pxa2xx_spi.h | 7 ++++---
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 7f73b26ed22e..14b049840faf 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -11,8 +11,8 @@
  *       PXA3xx     SSP1, SSP2, SSP3, SSP4
  */
 
-#ifndef __LINUX_SSP_H
-#define __LINUX_SSP_H
+#ifndef __LINUX_PXA2XX_SSP_H
+#define __LINUX_PXA2XX_SSP_H
 
 #include <linux/bits.h>
 #include <linux/compiler_types.h>
@@ -270,4 +270,4 @@ static inline struct ssp_device *pxa_ssp_request_of(const struct device_node *n,
 static inline void pxa_ssp_free(struct ssp_device *ssp) {}
 #endif
 
-#endif
+#endif	/* __LINUX_PXA2XX_SSP_H */
diff --git a/include/linux/spi/pxa2xx_spi.h b/include/linux/spi/pxa2xx_spi.h
index 1e0e2f136319..12ef04d0896d 100644
--- a/include/linux/spi/pxa2xx_spi.h
+++ b/include/linux/spi/pxa2xx_spi.h
@@ -2,8 +2,8 @@
 /*
  * Copyright (C) 2005 Stephen Street / StreetFire Sound Labs
  */
-#ifndef __linux_pxa2xx_spi_h
-#define __linux_pxa2xx_spi_h
+#ifndef __LINUX_SPI_PXA2XX_SPI_H
+#define __LINUX_SPI_PXA2XX_SPI_H
 
 #include <linux/types.h>
 
@@ -51,4 +51,5 @@ struct pxa2xx_spi_chip {
 extern void pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_controller *info);
 
 #endif
-#endif
+
+#endif	/* __LINUX_SPI_PXA2XX_SPI_H */
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:36 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:36 +0300
Subject: [PATCH v2 09/14] spi: pxa2xx: Use pxa_ssp_enable()/pxa_ssp_disable()
 in the driver
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-10-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of pxa_ssp_enable() and
pxa_ssp_disable(). Use them instead of open coded variants.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c |  4 +---
 drivers/spi/spi-pxa2xx.c     | 36 ++++++++++++++++++------------------
 include/linux/pxa2xx_ssp.h   | 16 ++++++++++++++++
 sound/soc/pxa/pxa-ssp.c      | 16 ----------------
 4 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index e00dbadd39ec..5ca01ad7f460 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -50,9 +50,7 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 
 		if (error) {
 			/* In case we got an error we disable the SSP now */
-			pxa2xx_spi_write(drv_data, SSCR0,
-					 pxa2xx_spi_read(drv_data, SSCR0)
-					 & ~SSCR0_SSE);
+			pxa_ssp_disable(drv_data->ssp);
 			msg->status = -EIO;
 		}
 
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 85a8d228a117..f85c7439757c 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -286,13 +286,11 @@ static u32 pxa2xx_configure_sscr0(const struct driver_data *drv_data,
 	case QUARK_X1000_SSP:
 		return clk_div
 			| QUARK_X1000_SSCR0_Motorola
-			| QUARK_X1000_SSCR0_DataSize(bits > 32 ? 8 : bits)
-			| SSCR0_SSE;
+			| QUARK_X1000_SSCR0_DataSize(bits > 32 ? 8 : bits);
 	default:
 		return clk_div
 			| SSCR0_Motorola
 			| SSCR0_DataSize(bits > 16 ? bits - 16 : bits)
-			| SSCR0_SSE
 			| (bits > 16 ? SSCR0_EDSS : 0);
 	}
 }
@@ -498,8 +496,7 @@ static void pxa2xx_spi_off(struct driver_data *drv_data)
 	if (is_mmp2_ssp(drv_data))
 		return;
 
-	pxa2xx_spi_write(drv_data, SSCR0,
-			 pxa2xx_spi_read(drv_data, SSCR0) & ~SSCR0_SSE);
+	pxa_ssp_disable(drv_data->ssp);
 }
 
 static int null_writer(struct driver_data *drv_data)
@@ -1098,25 +1095,26 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *controller,
 	    (pxa2xx_spi_read(drv_data, DDS_RATE) != chip->dds_rate))
 		pxa2xx_spi_write(drv_data, DDS_RATE, chip->dds_rate);
 
+	/* Stop the SSP */
+	if (!is_mmp2_ssp(drv_data))
+		pxa_ssp_disable(drv_data->ssp);
+
+	if (!pxa25x_ssp_comp(drv_data))
+		pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
+
 	/* see if we need to reload the config registers */
 	if ((pxa2xx_spi_read(drv_data, SSCR0) != cr0)
 	    || (pxa2xx_spi_read(drv_data, SSCR1) & change_mask)
 	    != (cr1 & change_mask)) {
-		/* stop the SSP, and update the other bits */
-		if (!is_mmp2_ssp(drv_data))
-			pxa2xx_spi_write(drv_data, SSCR0, cr0 & ~SSCR0_SSE);
-		if (!pxa25x_ssp_comp(drv_data))
-			pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 		/* first set CR1 without interrupt and service enables */
 		pxa2xx_spi_write(drv_data, SSCR1, cr1 & change_mask);
-		/* restart the SSP */
+		/* Update the other bits */
 		pxa2xx_spi_write(drv_data, SSCR0, cr0);
-
-	} else {
-		if (!pxa25x_ssp_comp(drv_data))
-			pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
 	}
 
+	/* Restart the SSP */
+	pxa_ssp_enable(drv_data->ssp);
+
 	if (is_mmp2_ssp(drv_data)) {
 		u8 tx_level = (pxa2xx_spi_read(drv_data, SSSR)
 					& SSSR_TFL_MASK) >> 8;
@@ -1782,8 +1780,9 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
 		controller->min_speed_hz =
 			DIV_ROUND_UP(controller->max_speed_hz, 512);
 
+	pxa_ssp_disable(ssp);
+
 	/* Load default SSP configuration */
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
 	switch (drv_data->ssp_type) {
 	case QUARK_X1000_SSP:
 		tmp = QUARK_X1000_SSCR1_RxTresh(RX_THRESH_QUARK_X1000_DFLT) |
@@ -1924,7 +1923,7 @@ static int pxa2xx_spi_remove(struct platform_device *pdev)
 	spi_unregister_controller(drv_data->controller);
 
 	/* Disable the SSP at the peripheral and SOC level */
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
+	pxa_ssp_disable(ssp);
 	clk_disable_unprepare(ssp->clk);
 
 	/* Release DMA */
@@ -1953,7 +1952,8 @@ static int pxa2xx_spi_suspend(struct device *dev)
 	status = spi_controller_suspend(drv_data->controller);
 	if (status != 0)
 		return status;
-	pxa2xx_spi_write(drv_data, SSCR0, 0);
+
+	pxa_ssp_disable(ssp);
 
 	if (!pm_runtime_suspended(dev))
 		clk_disable_unprepare(ssp->clk);
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 1b6c1a0922bd..fdfbe17e15f4 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -254,6 +254,22 @@ static inline u32 pxa_ssp_read_reg(struct ssp_device *dev, u32 reg)
 	return __raw_readl(dev->mmio_base + reg);
 }
 
+static inline void pxa_ssp_enable(struct ssp_device *ssp)
+{
+	u32 sscr0;
+
+	sscr0 = pxa_ssp_read_reg(ssp, SSCR0) | SSCR0_SSE;
+	pxa_ssp_write_reg(ssp, SSCR0, sscr0);
+}
+
+static inline void pxa_ssp_disable(struct ssp_device *ssp)
+{
+	u32 sscr0;
+
+	sscr0 = pxa_ssp_read_reg(ssp, SSCR0) & ~SSCR0_SSE;
+	pxa_ssp_write_reg(ssp, SSCR0, sscr0);
+}
+
 #if IS_ENABLED(CONFIG_PXA_SSP)
 struct ssp_device *pxa_ssp_request(int port, const char *label);
 void pxa_ssp_free(struct ssp_device *);
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index b941adcbb8f9..939e7e28486a 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -61,22 +61,6 @@ static void dump_registers(struct ssp_device *ssp)
 		 pxa_ssp_read_reg(ssp, SSACD));
 }
 
-static void pxa_ssp_enable(struct ssp_device *ssp)
-{
-	uint32_t sscr0;
-
-	sscr0 = __raw_readl(ssp->mmio_base + SSCR0) | SSCR0_SSE;
-	__raw_writel(sscr0, ssp->mmio_base + SSCR0);
-}
-
-static void pxa_ssp_disable(struct ssp_device *ssp)
-{
-	uint32_t sscr0;
-
-	sscr0 = __raw_readl(ssp->mmio_base + SSCR0) & ~SSCR0_SSE;
-	__raw_writel(sscr0, ssp->mmio_base + SSCR0);
-}
-
 static void pxa_ssp_set_dma_params(struct ssp_device *ssp, int width4,
 			int out, struct snd_dmaengine_dai_dma_data *dma)
 {
-- 
2.30.2



From andriy.shevchenko at linux.intel.com  Fri Apr 23 19:24:38 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 23 Apr 2021 21:24:38 +0300
Subject: [PATCH v2 11/14] spi: pxa2xx: Extract clear_SSCR1_bits() helper
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <20210423182441.50272-12-andriy.shevchenko@linux.intel.com>

There are few places that repeat the logic of "clear some bits in SSCR1".
Extract clear_SSCR1_bits() helper to deduplicate that.

Signed-off-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
---
 drivers/spi/spi-pxa2xx-dma.c | 4 +---
 drivers/spi/spi-pxa2xx.c     | 7 ++-----
 drivers/spi/spi-pxa2xx.h     | 5 +++++
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-dma.c b/drivers/spi/spi-pxa2xx-dma.c
index 5ca01ad7f460..e581027e99f9 100644
--- a/drivers/spi/spi-pxa2xx-dma.c
+++ b/drivers/spi/spi-pxa2xx-dma.c
@@ -41,9 +41,7 @@ static void pxa2xx_spi_dma_transfer_complete(struct driver_data *drv_data,
 		}
 
 		/* Clear status & disable interrupts */
-		pxa2xx_spi_write(drv_data, SSCR1,
-				 pxa2xx_spi_read(drv_data, SSCR1)
-				 & ~drv_data->dma_cr1);
+		clear_SSCR1_bits(drv_data, drv_data->dma_cr1);
 		write_SSSR_CS(drv_data, drv_data->clear_sr);
 		if (!pxa25x_ssp_comp(drv_data))
 			pxa2xx_spi_write(drv_data, SSTO, 0);
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 4b3237f14ead..58178ba704dc 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -733,8 +733,7 @@ static irqreturn_t interrupt_transfer(struct driver_data *drv_data)
 static void handle_bad_msg(struct driver_data *drv_data)
 {
 	pxa2xx_spi_off(drv_data);
-	pxa2xx_spi_write(drv_data, SSCR1,
-			 pxa2xx_spi_read(drv_data, SSCR1) & ~drv_data->int_cr1);
+	clear_SSCR1_bits(drv_data, drv_data->int_cr1);
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
@@ -1161,9 +1160,7 @@ static void pxa2xx_spi_handle_err(struct spi_controller *controller,
 	pxa2xx_spi_off(drv_data);
 	/* Clear and disable interrupts and service requests */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
-	pxa2xx_spi_write(drv_data, SSCR1,
-			 pxa2xx_spi_read(drv_data, SSCR1)
-			 & ~(drv_data->int_cr1 | drv_data->dma_cr1));
+	clear_SSCR1_bits(drv_data, drv_data->int_cr1 | drv_data->dma_cr1);
 	if (!pxa25x_ssp_comp(drv_data))
 		pxa2xx_spi_write(drv_data, SSTO, 0);
 
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index 739e264feaa6..ed63f7165cd8 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -105,6 +105,11 @@ static inline int pxa25x_ssp_comp(struct driver_data *drv_data)
 	}
 }
 
+static inline void clear_SSCR1_bits(const struct driver_data *drv_data, u32 bits)
+{
+	pxa2xx_spi_write(drv_data, SSCR1, pxa2xx_spi_read(drv_data, SSCR1) & ~bits);
+}
+
 static inline void write_SSSR_CS(struct driver_data *drv_data, u32 val)
 {
 	if (drv_data->ssp_type == CE4100_SSP ||
-- 
2.30.2



From skomatineni at nvidia.com  Fri Apr 23 19:32:58 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Fri, 23 Apr 2021 11:32:58 -0700
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <CAJZ5v0hivxQjA2AZpPxVadzaM7gB+L3BRnoNyeD7hyvr-3Fh4g@mail.gmail.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <CAJZ5v0hivxQjA2AZpPxVadzaM7gB+L3BRnoNyeD7hyvr-3Fh4g@mail.gmail.com>
Message-ID: <9c01bdb9-90cf-f14a-a886-c91ef01bcf25@nvidia.com>


On 4/23/21 5:27 AM, Rafael J. Wysocki wrote:
> On Thu, Apr 22, 2021 at 10:31 PM Sowjanya Komatineni
> <skomatineni at nvidia.com> wrote:
>> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
>> in charge of deciding on state transition based on target state, state idle
>> time, and some other Tegra CPU core cluster states information.
>>
>> Current PSCI specification don't have function defined for passing runtime
>> state idle time predicted by governor (based on next events and state target
>> residency) to ARM trusted firmware.
> Presumably that's because this is not a good idea.
Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs.

MCE firmware handles CPU complex power management states entry/exit 
based on its background tasks and uses expected wake time of the core to 
decide on state transition.

Expected wake time is based on next event and allowed? min residency of 
the state which governor predicts in kernel which MCE is not aware of.

So need a way to pass this info from kernel through PSCI to TF-A and 
TF-A will update this to MCE along with requested state of entry.

For example, When C6 core idle state is requested, MCE notes the time at 
which core is likely to wake up. There could be background tasks running 
on core which kernel is not aware of.

When those tasks are completed it will check the remaining time against 
states crossover thresholds (programmed by ARM trusted FW) to determine 
if its still have enough time to enter into C6 state.

While a core is power gates, it could be woken up for background tasks 
and put back to power gated state again by MCE based on expected wake 
time of the corresponding core.


So, Tegra194/Tegra186 CPU idle support, we need this runtime state 
expected wake time predicted by governor to be passed from kernel to TF-A.

Thanks

Sowjanya

>
> A basic design principle of cpuidle is that it should be possible to
> use every governor with every driver and the changes in this series
> make the platforms in question only work with menu AFAICS.


From skomatineni at nvidia.com  Fri Apr 23 19:33:41 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Fri, 23 Apr 2021 11:33:41 -0700
Subject: [RFC PATCH 2/4] cpuidle: menu: add idle_time to cpuidle_state
In-Reply-To: <CAJZ5v0hb7AES4A2QHhtMo76GbbkH=FnyQb0oEpHOaWWirpJ80A@mail.gmail.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <1619123448-10138-3-git-send-email-skomatineni@nvidia.com>
 <CAJZ5v0hb7AES4A2QHhtMo76GbbkH=FnyQb0oEpHOaWWirpJ80A@mail.gmail.com>
Message-ID: <f4c0fba9-6f7d-3bc3-49cc-c239fba975ce@nvidia.com>


On 4/23/21 5:22 AM, Rafael J. Wysocki wrote:
> On Thu, Apr 22, 2021 at 10:31 PM Sowjanya Komatineni
> <skomatineni at nvidia.com>  wrote:
>> Some platforms use separate CPU firmware running in background to
>> handle state transitions which may need runtime idle time of the
>> corresponding target state from the kernel.
> How exactly does this work?
>
Explained this as part of other feedback in Patch-0

Thanks

Sowjanya



From robh at kernel.org  Fri Apr 23 19:41:56 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 23 Apr 2021 13:41:56 -0500
Subject: [PATCH] dt-bindings: net: mediatek/ralink: remove unused bindings
In-Reply-To: <CALCv0x2oSXBT-6LteYtr9J5XmmDuer_=sbCgB5CBXWe_cKk2sA@mail.gmail.com>
References: <20210420024222.101615-1-ilya.lipnitskiy@gmail.com>
 <20210421220302.GA1637795@robh.at.kernel.org>
 <CALCv0x2oSXBT-6LteYtr9J5XmmDuer_=sbCgB5CBXWe_cKk2sA@mail.gmail.com>
Message-ID: <CAL_Jsq+Zhgn53wGdMbZKMjxk2gPQQFpjSsudVso+keonDCd+oQ@mail.gmail.com>

On Wed, Apr 21, 2021 at 5:05 PM Ilya Lipnitskiy
<ilya.lipnitskiy at gmail.com> wrote:
>
> Hi Rob,
>
> On Wed, Apr 21, 2021 at 3:03 PM Rob Herring <robh at kernel.org> wrote:
> >
> > On Mon, Apr 19, 2021 at 07:42:22PM -0700, Ilya Lipnitskiy wrote:
> > > Revert commit 663148e48a66 ("Documentation: DT: net: add docs for
> > > ralink/mediatek SoC ethernet binding")
> > >
> > > No in-tree drivers use the compatible strings present in these bindings,
> > > and some have been superseded by DSA-capable mtk_eth_soc driver, so
> > > remove these obsolete bindings.
> >
> > Looks like maybe OpenWRT folks are using these. If so, you can't revert
> > them.
> Indeed, there are out of tree drivers for some of these. I wasn't sure
> what the dt-binding policy was for such use cases - can you point me
> to a definitive reference?

Perhaps we should write that down more explicitly, but I think it is
pretty rare actually. And really, I'd like to require we have at least
1 dts user. Though, then we'd just have dead dts files. More
generally, other projects use the bindings and dts files. The bindings
and dts files live in the kernel tree for convenience and the simple
fact that is where the vast majority of both developers and hardware
support are. There are exceptions of course such as h/w that doesn't
run Linux.

I'm all for removing this if no one cares (please try to find out) or
if the existing binding is just bad (doesn't match the h/w or is
incomplete in an incompatible way). I would have expected in the 5
years since it was added, a user (either dts file or driver) would
have appeared.

Rob


From lyude at redhat.com  Fri Apr 23 19:42:57 2021
From: lyude at redhat.com (Lyude Paul)
Date: Fri, 23 Apr 2021 14:42:57 -0400
Subject: [PATCH v4 05/17] drm/dp: Pass drm_dp_aux to
 drm_dp_link_train_clock_recovery_delay()
In-Reply-To: <20210423184309.207645-1-lyude@redhat.com>
References: <20210423184309.207645-1-lyude@redhat.com>
Message-ID: <20210423184309.207645-6-lyude@redhat.com>

So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().

Signed-off-by: Lyude Paul <lyude at redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c              | 2 +-
 drivers/gpu/drm/drm_dp_helper.c                       | 3 ++-
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c                      | 2 +-
 drivers/gpu/drm/msm/edp/edp_ctrl.c                    | 2 +-
 drivers/gpu/drm/radeon/atombios_dp.c                  | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c                      | 2 +-
 include/drm/drm_dp_helper.h                           | 4 +++-
 8 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 062625a8a4ec..92d76f4cfdfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -612,7 +612,7 @@ amdgpu_atombios_dp_link_train_cr(struct amdgpu_atombios_dp_link_train_info *dp_i
 	dp_info->tries = 0;
 	voltage = 0xff;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+		drm_dp_link_train_clock_recovery_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9f66153a3c55..f71b035a48b4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
 
-void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+					    const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
 	unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 					 DP_TRAINING_AUX_RD_MASK;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 591ddc4b876c..198ddb3c173a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -513,7 +513,7 @@ static void intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
 							enum drm_dp_phy dp_phy)
 {
 	if (dp_phy == DP_PHY_DPRX)
-		drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
+		drm_dp_link_train_clock_recovery_delay(&intel_dp->aux, intel_dp->dpcd);
 	else
 		drm_dp_lttpr_link_train_clock_recovery_delay();
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 1390f3547fde..264a9eae87d3 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
 	tries = 0;
 	old_v_level = ctrl->link->phy_params.v_level;
 	for (tries = 0; tries < maximum_retries; tries++) {
-		drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
+		drm_dp_link_train_clock_recovery_delay(ctrl->aux, ctrl->panel->dpcd);
 
 		ret = dp_ctrl_read_link_status(ctrl, link_status);
 		if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 57af3d8b6699..6501598448b4 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
 	tries = 0;
 	old_v_level = ctrl->v_level;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
+		drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux, ctrl->dpcd);
 
 		rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
 		if (rlen < DP_LINK_STATUS_SIZE) {
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index c50c504bad50..299b9d8da376 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -680,7 +680,7 @@ static int radeon_dp_link_train_cr(struct radeon_dp_link_train_info *dp_info)
 	dp_info->tries = 0;
 	voltage = 0xff;
 	while (1) {
-		drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
+		drm_dp_link_train_clock_recovery_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 7e5e89305028..e75f67cbae69 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -713,7 +713,7 @@ static int zynqmp_dp_link_train_cr(struct zynqmp_dp *dp)
 		if (ret)
 			return ret;
 
-		drm_dp_link_train_clock_recovery_delay(dp->dpcd);
+		drm_dp_link_train_clock_recovery_delay(&dp->aux, dp->dpcd);
 		ret = drm_dp_dpcd_read_link_status(&dp->aux, link_status);
 		if (ret < 0)
 			return ret;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 95efe37ea9ca..675ad0029699 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -29,6 +29,7 @@
 #include <drm/drm_connector.h>
 
 struct drm_device;
+struct drm_dp_aux;
 
 /*
  * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
@@ -1482,7 +1483,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 #define DP_LTTPR_COMMON_CAP_SIZE	8
 #define DP_LTTPR_PHY_CAP_SIZE		3
 
-void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
+					    const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_clock_recovery_delay(void);
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_channel_eq_delay(const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
-- 
2.30.2



From lyude at redhat.com  Fri Apr 23 19:42:58 2021
From: lyude at redhat.com (Lyude Paul)
Date: Fri, 23 Apr 2021 14:42:58 -0400
Subject: [PATCH v4 06/17] drm/dp: Pass drm_dp_aux to
 drm_dp*_link_train_channel_eq_delay()
In-Reply-To: <20210423184309.207645-1-lyude@redhat.com>
References: <20210423184309.207645-1-lyude@redhat.com>
Message-ID: <20210423184309.207645-7-lyude@redhat.com>

So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().

Signed-off-by: Lyude Paul <lyude at redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c           |  2 +-
 drivers/gpu/drm/drm_dp_helper.c                    | 14 +++++++++-----
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  4 ++--
 drivers/gpu/drm/msm/dp/dp_ctrl.c                   |  4 ++--
 drivers/gpu/drm/msm/edp/edp_ctrl.c                 |  4 ++--
 drivers/gpu/drm/radeon/atombios_dp.c               |  2 +-
 drivers/gpu/drm/xlnx/zynqmp_dp.c                   |  2 +-
 include/drm/drm_dp_helper.h                        |  6 ++++--
 8 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index 92d76f4cfdfc..f327becb022f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -677,7 +677,7 @@ amdgpu_atombios_dp_link_train_ce(struct amdgpu_atombios_dp_link_train_info *dp_i
 	dp_info->tries = 0;
 	channel_eq = false;
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+		drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f71b035a48b4..a2047dae3ab7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -151,7 +151,8 @@ void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
-static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
+static void __drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+						 unsigned long rd_interval)
 {
 	if (rd_interval > 4)
 		DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
@@ -165,9 +166,11 @@ static void __drm_dp_link_train_channel_eq_delay(unsigned long rd_interval)
 	usleep_range(rd_interval, rd_interval * 2);
 }
 
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-	__drm_dp_link_train_channel_eq_delay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+	__drm_dp_link_train_channel_eq_delay(aux,
+					     dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
 					     DP_TRAINING_AUX_RD_MASK);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
@@ -183,13 +186,14 @@ static u8 dp_lttpr_phy_cap(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE], int r)
 	return phy_cap[r - DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1];
 }
 
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE])
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					      const u8 phy_cap[DP_LTTPR_PHY_CAP_SIZE])
 {
 	u8 interval = dp_lttpr_phy_cap(phy_cap,
 				       DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1) &
 		      DP_TRAINING_AUX_RD_MASK;
 
-	__drm_dp_link_train_channel_eq_delay(interval);
+	__drm_dp_link_train_channel_eq_delay(aux, interval);
 }
 EXPORT_SYMBOL(drm_dp_lttpr_link_train_channel_eq_delay);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 198ddb3c173a..6bf6f1ec13ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -665,11 +665,11 @@ intel_dp_link_training_channel_equalization_delay(struct intel_dp *intel_dp,
 						  enum drm_dp_phy dp_phy)
 {
 	if (dp_phy == DP_PHY_DPRX) {
-		drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
+		drm_dp_link_train_channel_eq_delay(&intel_dp->aux, intel_dp->dpcd);
 	} else {
 		const u8 *phy_caps = intel_dp_lttpr_phy_caps(intel_dp, dp_phy);
 
-		drm_dp_lttpr_link_train_channel_eq_delay(phy_caps);
+		drm_dp_lttpr_link_train_channel_eq_delay(&intel_dp->aux, phy_caps);
 	}
 }
 
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 264a9eae87d3..2cebd17a7289 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1184,7 +1184,7 @@ static int dp_ctrl_link_lane_down_shift(struct dp_ctrl_private *ctrl)
 static void dp_ctrl_clear_training_pattern(struct dp_ctrl_private *ctrl)
 {
 	dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_DISABLE);
-	drm_dp_link_train_channel_eq_delay(ctrl->panel->dpcd);
+	drm_dp_link_train_channel_eq_delay(ctrl->aux, ctrl->panel->dpcd);
 }
 
 static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
@@ -1215,7 +1215,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
 	dp_ctrl_train_pattern_set(ctrl, pattern | DP_RECOVERED_CLOCK_OUT_EN);
 
 	for (tries = 0; tries <= maximum_retries; tries++) {
-		drm_dp_link_train_channel_eq_delay(ctrl->panel->dpcd);
+		drm_dp_link_train_channel_eq_delay(ctrl->aux, ctrl->panel->dpcd);
 
 		ret = dp_ctrl_read_link_status(ctrl, link_status);
 		if (ret)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 6501598448b4..4fb397ee7c84 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -665,7 +665,7 @@ static int edp_start_link_train_2(struct edp_ctrl *ctrl)
 		return ret;
 
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(ctrl->dpcd);
+		drm_dp_link_train_channel_eq_delay(ctrl->drm_aux, ctrl->dpcd);
 
 		rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
 		if (rlen < DP_LINK_STATUS_SIZE) {
@@ -743,7 +743,7 @@ static int edp_clear_training_pattern(struct edp_ctrl *ctrl)
 
 	ret = edp_train_pattern_set_write(ctrl, 0);
 
-	drm_dp_link_train_channel_eq_delay(ctrl->dpcd);
+	drm_dp_link_train_channel_eq_delay(ctrl->drm_aux, ctrl->dpcd);
 
 	return ret;
 }
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 299b9d8da376..4c1e551d9714 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -743,7 +743,7 @@ static int radeon_dp_link_train_ce(struct radeon_dp_link_train_info *dp_info)
 	dp_info->tries = 0;
 	channel_eq = false;
 	while (1) {
-		drm_dp_link_train_channel_eq_delay(dp_info->dpcd);
+		drm_dp_link_train_channel_eq_delay(dp_info->aux, dp_info->dpcd);
 
 		if (drm_dp_dpcd_read_link_status(dp_info->aux,
 						 dp_info->link_status) <= 0) {
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index e75f67cbae69..82430ca9b913 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -778,7 +778,7 @@ static int zynqmp_dp_link_train_ce(struct zynqmp_dp *dp)
 		if (ret)
 			return ret;
 
-		drm_dp_link_train_channel_eq_delay(dp->dpcd);
+		drm_dp_link_train_channel_eq_delay(&dp->aux, dp->dpcd);
 		ret = drm_dp_dpcd_read_link_status(&dp->aux, link_status);
 		if (ret < 0)
 			return ret;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 675ad0029699..e932b2c40095 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1486,8 +1486,10 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZ
 void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
 					    const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
 void drm_dp_lttpr_link_train_clock_recovery_delay(void);
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
-void drm_dp_lttpr_link_train_channel_eq_delay(const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
+void drm_dp_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					const u8 dpcd[DP_RECEIVER_CAP_SIZE]);
+void drm_dp_lttpr_link_train_channel_eq_delay(const struct drm_dp_aux *aux,
+					      const u8 caps[DP_LTTPR_PHY_CAP_SIZE]);
 
 u8 drm_dp_link_rate_to_bw_code(int link_rate);
 int drm_dp_bw_code_to_link_rate(u8 link_bw);
-- 
2.30.2



From grygorii.strashko at ti.com  Fri Apr 23 20:06:45 2021
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Fri, 23 Apr 2021 22:06:45 +0300
Subject: [PATCH] soc: ti: Use devm_platform_ioremap_resource_byname
In-Reply-To: <20210423090409.25032-1-dingsenjie@163.com>
References: <20210423090409.25032-1-dingsenjie@163.com>
Message-ID: <229e8a69-818a-5024-67f7-8afc09522810@ti.com>



On 23/04/2021 12:04, dingsenjie at 163.com wrote:
> From: dingsenjie <dingsenjie at yulong.com>
> 
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately
> 
> Signed-off-by: dingsenjie <dingsenjie at yulong.com>
> ---
>   drivers/soc/ti/k3-ringacc.c | 18 +++++-------------
>   1 file changed, 5 insertions(+), 13 deletions(-)

Reviewed-by: Grygorii Strashko <grygorii.strashko at ti.com>

> 
> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
> index b495b0d..aa8ebd4 100644
> --- a/drivers/soc/ti/k3-ringacc.c
> +++ b/drivers/soc/ti/k3-ringacc.c
> @@ -1352,7 +1352,6 @@ static int k3_ringacc_init(struct platform_device *pdev,
>   	const struct soc_device_attribute *soc;
>   	void __iomem *base_fifo, *base_rt;
>   	struct device *dev = &pdev->dev;
> -	struct resource *res;
>   	int ret, i;
>   
>   	dev->msi_domain = of_msi_get_domain(dev, dev->of_node,
> @@ -1373,24 +1372,19 @@ static int k3_ringacc_init(struct platform_device *pdev,
>   		ringacc->dma_ring_reset_quirk = soc_data->dma_ring_reset_quirk;
>   	}
>   
> -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rt");
> -	base_rt = devm_ioremap_resource(dev, res);
> +	base_rt = devm_platform_ioremap_resource_byname(pdev, "rt");
>   	if (IS_ERR(base_rt))
>   		return PTR_ERR(base_rt);
>   
> -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fifos");
> -	base_fifo = devm_ioremap_resource(dev, res);
> +	base_fifo = devm_platform_ioremap_resource_byname(pdev, "fifos");
>   	if (IS_ERR(base_fifo))
>   		return PTR_ERR(base_fifo);
>   
> -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "proxy_gcfg");
> -	ringacc->proxy_gcfg = devm_ioremap_resource(dev, res);
> +	ringacc->proxy_gcfg = devm_platform_ioremap_resource_byname(pdev, "proxy_gcfg");
>   	if (IS_ERR(ringacc->proxy_gcfg))
>   		return PTR_ERR(ringacc->proxy_gcfg);
>   
> -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> -					   "proxy_target");
> -	ringacc->proxy_target_base = devm_ioremap_resource(dev, res);
> +	ringacc->proxy_target_base = devm_platform_ioremap_resource_byname(pdev, "proxy_target");
>   	if (IS_ERR(ringacc->proxy_target_base))
>   		return PTR_ERR(ringacc->proxy_target_base);
>   
> @@ -1458,7 +1452,6 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev,
>   	struct device *dev = &pdev->dev;
>   	struct k3_ringacc *ringacc;
>   	void __iomem *base_rt;
> -	struct resource *res;
>   	int i;
>   
>   	ringacc = devm_kzalloc(dev, sizeof(*ringacc), GFP_KERNEL);
> @@ -1473,8 +1466,7 @@ struct k3_ringacc *k3_ringacc_dmarings_init(struct platform_device *pdev,
>   
>   	mutex_init(&ringacc->req_lock);
>   
> -	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ringrt");
> -	base_rt = devm_ioremap_resource(dev, res);
> +	base_rt = devm_platform_ioremap_resource_byname(pdev, "ringrt");
>   	if (IS_ERR(base_rt))
>   		return ERR_CAST(base_rt);
>   
> 

-- 
Best regards,
grygorii


From arnd at kernel.org  Fri Apr 23 20:52:25 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 23 Apr 2021 21:52:25 +0200
Subject: [RFC PATCH 1/2] ARM: mstar: Add header with macros for RIU
 register access
In-Reply-To: <CAFr9PX=QeON1C_25tyNK1rWGm3A_Kc2Ad5qLUCfunmdHQUsv_g@mail.gmail.com>
References: <20210422140945.4131092-1-daniel@0x0f.com>
 <20210422140945.4131092-2-daniel@0x0f.com>
 <CAK8P3a3fkjy2YYwhmsFQt-MSyOh=1zf1wqzQB7usjsHbUBWdtQ@mail.gmail.com>
 <CAFr9PX=QeON1C_25tyNK1rWGm3A_Kc2Ad5qLUCfunmdHQUsv_g@mail.gmail.com>
Message-ID: <CAK8P3a3fxvH_DrxtrCDOwjzx1zvw09E4K7eFC697FH0je9=tmw@mail.gmail.com>

On Fri, Apr 23, 2021 at 4:03 PM Daniel Palmer <daniel at 0x0f.com> wrote:
> On Fri, 23 Apr 2021 at 22:48, Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > The __iomem token comes after the type, so this should be 'void __iomem *'.
> >
>
> Bit of copy/paste fail. Fixed.
>
> > > +       return readw_relaxed(reg + 4) << 16 | readw_relaxed(reg);
> >
> > This should probably be using 'readw' instead of 'readw_relaxed'. If you
> > absolutely need to use one of the relaxed accessors somewhere,
> > better add both sets and make sure drivers use the non-relaxed version
> > by default.
>
> I'll add a relaxed/non-relaxed version of each.
> Because of the heavy memory barrier to access one 32 bit register
> we'll hit the barrier twice in the non-relaxed version.
> And we don't need to hit the barrier at all because it doesn't
> actually matter for IO. Is there something better I can do there?

I think you can do the heavy barrier only once in this case. For writel,
the barrier comes first, so you can do writel();write_relaxed(), and the
reverse for the read side, doing readl_relaxed(); readl();.

> > Maybe both types of accessors can be in a single header.
>
> That makes sense. I'll merge them. Would this header be something that
> could go in alone without anything that uses them in mainline right
> now?

I don't care much, I can provide an Acked-by for merging it along with
whatever driver change first needs it, or I can merge it after
5.13-rc1 through the soc tree.

          Arnd


From arnd at kernel.org  Fri Apr 23 20:55:22 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Fri, 23 Apr 2021 21:55:22 +0200
Subject: [GIT PULL] ARM SoC fixes for v5.12, part 4
Message-ID: <CAK8P3a20H54BCzzEtZEq2CXx57e1xeyzxf_uHq+OEMgKQvaC7g@mail.gmail.com>

The following changes since commit b9a9786a13ea158ee3b23614217f2e3158178421:

  Merge tag 'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/fixes (2021-04-08 17:56:09 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-fixes-5.12-4

for you to fetch changes up to a1768dad775b5ceb25d17bc7a13318f43adf3069:

  Merge branch 'tegra/dt64' into arm/fixes (2021-04-23 15:38:13 +0200)

----------------------------------------------------------------
ARM SoC fixes for v5.12, part 4

These should be the final fixes for v5.12. There is one fix for SD card
detection on one Allwinner board, and a few fixes for the Tegra
platform that I had already queued up for v5.13 due to a communication
problem. This addresses MMC device ordering on multiple machines,
audio support on Jetson AGX Xavier and suspend/resume on Jetson TX2.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Andre Przywara (1):
      arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS

Arnd Bergmann (2):
      Merge tag 'sunxi-fixes-for-5.12-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into
arm/fixes
      Merge branch 'tegra/dt64' into arm/fixes

Jon Hunter (2):
      arm64: tegra: Set fw_devlink=on for Jetson TX2
      arm64: tegra: Fix mmc0 alias for Jetson Xavier NX

Sameer Pujar (1):
      arm64: tegra: Move clocks from RT5658 endpoint to device node

Thierry Reding (1):
      arm64: tegra: Add unit-address for ACONNECT on Tegra186

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 2 +-
 arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts      | 2 +-
 arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi          | 2 +-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi                | 2 +-
 arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts      | 3 ++-
 arch/arm64/boot/dts/nvidia/tegra194-p3668-0000.dtsi     | 4 ++++
 arch/arm64/boot/dts/nvidia/tegra194-p3668-0001.dtsi     | 4 ++++
 arch/arm64/boot/dts/nvidia/tegra194-p3668.dtsi          | 1 -
 8 files changed, 14 insertions(+), 6 deletions(-)


From pr-tracker-bot at kernel.org  Fri Apr 23 21:02:55 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Fri, 23 Apr 2021 20:02:55 +0000
Subject: [GIT PULL] ARM SoC fixes for v5.12, part 4
In-Reply-To: <CAK8P3a20H54BCzzEtZEq2CXx57e1xeyzxf_uHq+OEMgKQvaC7g@mail.gmail.com>
References: <CAK8P3a20H54BCzzEtZEq2CXx57e1xeyzxf_uHq+OEMgKQvaC7g@mail.gmail.com>
Message-ID: <161920817538.27381.9976776143787988171.pr-tracker-bot@kernel.org>

The pull request you sent on Fri, 23 Apr 2021 21:55:22 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6d1d45cb98347dbd101b378d11b5f0deb87b345d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From liam.howlett at oracle.com  Fri Apr 23 21:03:17 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Fri, 23 Apr 2021 20:03:17 +0000
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <m1y2d8dfx8.fsf@fess.ebiederm.org>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck> <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver> <m1y2d8dfx8.fsf@fess.ebiederm.org>
Message-ID: <20210423200126.otleormmjh22joj3@revolver>

* Eric W. Biederman <ebiederm at xmission.com> [210423 14:23]:
> Liam Howlett <liam.howlett at oracle.com> writes:
> 
> > * Eric W. Biederman <ebiederm at xmission.com> [210422 14:23]:
> >> Will Deacon <will at kernel.org> writes:
> >> 
> >> > [+Eric as he actually understands how this is supposed to work]
> >> 
> >> I try.
> >> 
> >
> > Thanks to both of you for looking at this.
> >
> >> > On Tue, Apr 20, 2021 at 04:50:13PM +0000, Liam Howlett wrote:
> >> >> arm64_notify_segfault() was used to force a SIGSEGV in all error cases
> >> >> in sigreturn() and rt_sigreturn() to avoid writing a new sig handler.
> >> >> There is now a better sig handler to use which does not search the VMA
> >> >> address space and return a slightly incorrect error code.  Restore the
> >> >> older and correct si_code of SI_KERNEL by using arm64_notify_die().  In
> >> >> the case of !access_ok(), simply return SIGSEGV with si_code
> >> >> SEGV_ACCERR.
> >> 
> >> What is userspace cares?  Why does it care?
> >
> >
> > Calling arm64_notify_segfault() as it is written is unreliable.
> > Searching for the address with find_vma() will return SEG_ACCERR almost
> > always, unless the address is larger than anything within *any* VMA.
> > I'm trying to fix this issue by cleaning up the callers to that function
> > and fix the function itself.
> 
> I can't see the rest of the patches in your series so I am not quite
> certain what you are doing.
> 
> Looking at the places that arm64_notify_segfault is called I do
> think you are right to be suspicious of that function.
> 
> swp_handler seems a legitimate user as it emulates an instruction.
> For that case at least you should probably add the necessary
> check to see if the address is contained in the returned vma.

The initial patch was to do just that, but the discussion resulted in
other patches to try and clean up the signal handling around this area.
I was switching to find_vma_intersection() to find the vma.  There was
concern on if SEGV_ACCERR should be returned if the next vma
VM_GROWSDOWN as that would potentially indicate a stack expansion. [1]

> 
> user_cache_maint_handler calls it with the tagged address, when
> it should use an untagged address with find_vma.  Otherwise
> user_cache_maint_handler is also performing instruction emulation
> and should work the same as swp_handler.

arm64_notify_segfault() calls untagged_addr() on the address passed to
find_vma().  Is there anything missing/wrong with this?

> 
> The only other users are in sigreturn and rt_sigreturn, where the
> address is iffy.  But assuming the proper address is passed sigreturn
> and rt_sigreturn are also performing instruction emulation.
> 
> > I don't have an example of why userspace cares about SI_KERNEL vs
> > SEGV_ACCERR/SEGV_MAPERR, but the git log on f71016a8a8c5 specifies that
> > this function was used to avoid having specific code to print an error
> > code.  I am restoring the old return code as it seems to makes more
> > sense and avoids the bug in the calling path.  If you'd rather, I can
> > change the notify_die line to use SIG_ACCERR as this is *almost* always
> > what is returend - except when the above mentioned bug is hit.  Upon
> > examining the code here, it seems unnecessary to walk the VMA tree to
> > find where the address lands in either of the error scenarios to know
> > what should be returned.
> 
> Ignoring the possibility of a parse error what the code has is -EFAULT.
> If we want to distinguish between SEGV_ACCERR and SEGV_MAPERR we need
> the find_vma (and confirmation that the found vma contains the specified
> address) to see if there is a mapping at the specified address.
> 
> Or as you point out later this could be a SIGBUS situation.
> 
> >> This is changing userspace visible semantics so understanding userspace
> >> and understanding how it might break, and what the risk of regression
> >> seems the most important detail here.
> >> 
> >> >> This change requires exporting arm64_notfiy_die() to the arm64 traps.h
> >> >> 
> >> >> Fixes: f71016a8a8c5 (arm64: signal: Call arm64_notify_segfault when
> >> >> failing to deliver signal)
> >> >> Signed-off-by: Liam R. Howlett <Liam.Howlett at Oracle.com>
> >> >> ---
> >> >>  arch/arm64/include/asm/traps.h |  2 ++
> >> >>  arch/arm64/kernel/signal.c     |  8 ++++++--
> >> >>  arch/arm64/kernel/signal32.c   | 18 ++++++++++++++----
> >> >>  3 files changed, 22 insertions(+), 6 deletions(-)
> >> >> 
> >> >> diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> >> >> index 54f32a0675df..9b76144fcba6 100644
> >> >> --- a/arch/arm64/include/asm/traps.h
> >> >> +++ b/arch/arm64/include/asm/traps.h
> >> >> @@ -29,6 +29,8 @@ void arm64_notify_segfault(unsigned long addr);
> >> >>  void arm64_force_sig_fault(int signo, int code, unsigned long far, const char *str);
> >> >>  void arm64_force_sig_mceerr(int code, unsigned long far, short lsb, const char *str);
> >> >>  void arm64_force_sig_ptrace_errno_trap(int errno, unsigned long far, const char *str);
> >> >> +void arm64_notify_die(const char *str, struct pt_regs *regs, int signo,
> >> >> +		      int sicode, unsigned long far, int err);
> >> >>  
> >> >>  /*
> >> >>   * Move regs->pc to next instruction and do necessary setup before it
> >> >> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> >> >> index 6237486ff6bb..9fde6dc760c3 100644
> >> >> --- a/arch/arm64/kernel/signal.c
> >> >> +++ b/arch/arm64/kernel/signal.c
> >> >> @@ -544,7 +544,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> >> >>  	frame = (struct rt_sigframe __user *)regs->sp;
> >> >>  
> >> >>  	if (!access_ok(frame, sizeof (*frame)))
> >> >> -		goto badframe;
> >> >> +		goto e_access;
> >> >>  
> >> >>  	if (restore_sigframe(regs, frame))
> >> >>  		goto badframe;
> >> >> @@ -555,7 +555,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
> >> >>  	return regs->regs[0];
> >> >>  
> >> >>  badframe:
> >> >> -	arm64_notify_segfault(regs->sp);
> >> >> +	arm64_notify_die("Bad frame", regs, SIGSEGV, SI_KERNEL, regs->sp, 0);
> >> >> +	return 0;
> >> >> +
> >> >> +e_access:
> >> >> +	force_signal_inject(SIGSEGV, SEGV_ACCERR, regs->sp, 0);
> >> >>  	return 0;
> >> >
> >> > This seems really error-prone to me, but maybe I'm just missing some
> >> > context. What's the rule for reporting an si_code of SI_KERNEL vs
> >> > SEGV_ACCERR, and is the former actually valid for SIGSEGV?
> >> 
> >> The si_codes SI_USER == 0 and SI_KERNEL == 0x80 are valid for all
> >> signals.  SI_KERNEL means I don't have any information for you other
> >> than signal number.
> >> 
> >> In general something better than SI_KERNEL is desirable.
> >
> > I went with SI_KERNEL as that's what was there before.  I have no strong
> > opinion on what should be returned; I do favour SIGBUS with si_code of
> > BUS_ADRALN but I didn't want to change user visable code too much -
> > especially to fix a bug in another function.
> 
> I hadn't noticed earlier, but I agree that what the code is doing is a
> little strange.  I get SIGBUS and SIGEGV confused when I have not looked
> at the recently.  I think SIGBUS is for mapped access that fail, and
> SIGSEGV is for everything else.  
> 
> >> > With this change, pointing the (signal) stack to a kernel address will
> >> > result in SEGV_ACCERR but pointing it to something like a PROT_NONE user
> >> > address will give SI_KERNEL (well, assuming that we manage to deliver
> >> > the SEGV somehow). I'm having a hard time seeing why that's a useful
> >> > distinction to make..
> >> >
> >> > If it's important to get this a particular way around, please can you
> >> > add some selftests?
> >> 
> >> Going down the current path I see 3 possible cases:
> >> 
> >> copy_from_user returns -EFAULT which becomes SEGV_MAPERR or SEGV_ACCERR.
> >
> > Almost always SEGV_ACCERR with the current bug, as mentioned above.
> > find_vma() searches from addr until the end of the address space, it
> > isn't just a simple lookup of the address.
> 
> Which is clearly a logic error.
> 
> In practice I don't know if anyone cares how sigreturn fails so we are
> in a grey area.
> 
> >> A signal frame parse error.  For which SI_KERNEL seems as good an error
> >> code as any.
> >> 
> >> 
> >> On x86 there is no attempt to figure out the cause of the -EFAULT, and
> >> always uses SI_KERNEL.  This is because x86 just does:
> >> "force_sig(SIGSEGV);" As arm64 did until f71016a8a8c5 ("arm64: signal:
> >> Call arm64_notify_segfault when failing to deliver signal")
> >> 
> >> 
> >> 
> >> I think the big question is what does it make sense to do here.
> >> 
> >> The big picture.  Upon return from a signal the kernel arranges
> >> for rt_sigreturn to be called to return to a pre-signal state.
> >> As such rt_sigreturn can not return an error code.
> >> 
> >> In general the kernel will write the signal frame and that will
> >> guarantee that the signal from can be processes by rt_sigreturn.
> >> 
> >> For error handling we are dealing with the case that userspace
> >> has modified the signal frame.  So that it either does not
> >> parse or that it is unmapped.
> >> 
> >> 
> >> So who cares?  The only two cases I can think of are debuggers, and
> >> programs playing fancy memory management games like garbage collections.
> >> I have heard of applications (like garbage collectors)
> >> unmapping/mprotecting memory to create a barrier.
> >> 
> >> Liam Howlett is that the issue here?  Is not seeing SI_KERNEL confusing
> >> the JVM?
> >
> > No, the issue here is that arm64_notify_segfault() has a bug which sent
> > me down a rabbit hole of issues and I'm really trying my best to help
> > out as best I can.  The bug certainly affects this function as it is
> > written today, but my patch will generate a consistent signal.
> 
> Not so much.  There are other cases where -EFAULT causing a failing
> return in that function.  So I think you have in practice made the
> matter worse.  As after this patch it becomes less clear what the
> return code is.

I do not see my error.  The rt_sigreturn() checks for unaligned access,
the frame is access_ok(), then tries to restore the sigframe/altstack.
If it's unaligned the patch would retrun SI_KERNEL, if the access is not
okay then it returns SEGV_ACCERR, if the sigframe/altstack fail to be
restored then it retuns SI_KERNEL.

> 
> >> For debuggers I expect the stack backtrace from SIGSEGV is enough to see
> >> that something is wrong.
> >> 
> >> For applications performing fancy processing of the signal frame I think
> >> that tends to be very architecture specific.  In part because even
> >> knowing the faulting address the size of the access is not known so the
> >> instruction must be interpreted.  Getting a system call instead of a
> >> load or store instruction might be enough to completely confuse
> >> applications processing SEGV_MAPERR or SEGV_ACCERR.  Such applications
> >> may also struggle with the fact that the address in siginfo is less
> >> precise than it would be for an ordinary page fault.
> >> 
> >> 
> >> So my sense is if you known you are helping userspace returning either
> >> SEGV_MAPERR or SEGV_ACCERR go for it.  Otherwise there are enough
> >> variables that returning less information when rt_sigreturn fails
> >> would be more reliable.
> >> 
> >> 
> >> Or in short what is userspace doing?  What does userspace care about?
> >
> > I think I've answered this, but it's more of trying to fix a bug which
> > causes an *almost* reliable return code to be a reliable return code.
> > Am I correct in stating that in both of these scnarios - !access_ok()
> > and badframe, it is unnecessary to search the VMAs for where the address
> > falls to know what error code to return?
> 
> You have answered you don't know what piece of userspace cares.
> 
> For access_ok failure you are correct we don't need a find_vma call
> to tell what kind of failure we have.
> 
> For anything return -EFAULT we don't know as -EFAULT has less precision
> than the instruction itself.
> 
> My sense is that you should concentrate on the userspace instruction
> emulation case from swp_handler or user_cache_maint_handler.  Because
> those instructions can run unemulated we know exactly what the semantics
> should be in those cases.
> 
> I suspect arm64_notify_segfault should be renamed arm64_notify_fault
> and generate SIGBUS or SIGSEGV as appropriate.
> 
> In fact I suspect that proper handling is to call __do_page_fault or
> handle_mm_fault as do_page_fault does and then parse the VM_FAULT code
> for which signal to generate.   Possibly factoring out a helper
> converting VM_FAULT codes to signals.
> 

This seems a bit too much for something that is in a gray area, as you
said above.

My goal was to tidy up the signal processing in these two functions and
alter the behaviour to be reliable.  If you believe that
arm64_notify_segfault() should be called anyways, then is there harm in
fixing the logic in that function and leaving rt_sigreturn() and
sigreturn() as they are? Please see my 3rd patch in the series at [2].

Thanks,
Liam

Link:
[1] https://lore.kernel.org/lkml/20210422185611.ccdf3rm4zr3xtuzl at revolver/
[2]
https://lore.kernel.org/lkml/20210420165001.3790670-3-Liam.Howlett at Oracle.com/

From lukasz.luba at arm.com  Fri Apr 23 21:16:57 2021
From: lukasz.luba at arm.com (Lukasz Luba)
Date: Fri, 23 Apr 2021 21:16:57 +0100
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
Message-ID: <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com>

Hi Sowjanya,

On 4/22/21 9:30 PM, Sowjanya Komatineni wrote:
> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs which is
> in charge of deciding on state transition based on target state, state idle
> time, and some other Tegra CPU core cluster states information.
> 
> Current PSCI specification don't have function defined for passing runtime
> state idle time predicted by governor (based on next events and state target
> residency) to ARM trusted firmware.

Do you have some numbers from experiments showing that these idle
governor prediction values, which are passed from kernel to MCE
firmware, are making a good 'guess'?
How much precision (1us? 1ms?) in the values do you need there?

IIRC (probably Rafael's presentations) predicting in the kernel
something like CPU idle time residency is not a trivial thing.

Another idea (depending on DT structure and PSCI bits):
Could this be solved differently, but just having a knowledge that if
the governor requested some C-state, this means governor 'predicted'
an idle residency to be greater that min_residency attached to this
C-state?
Then, when that request shows up in your FW, you know that it must be at
least min_residency because of this C-state id.
It would depend on number of available states, max_residency, scale
that you would choose while assigning values from [0, max_residency]
to each state.
IIRC there can be many state IDs for idle, so it would depend on
number of bits encoding this state, and your needs. Example of
linear scale:
4-bits encoding idle state and max predicted residency 10msec,
that means 10000us / 16 states = 625us/state.
The max_residency might be split differently, using different than
linear function, to have some rage more precised.

Open question is if these idle states must be all represented
in DT, or there is a way of describing a 'set of idle states'
automatically.

Regards,
Lukasz


From bgolaszewski at baylibre.com  Fri Apr 23 21:41:26 2021
From: bgolaszewski at baylibre.com (Bartosz Golaszewski)
Date: Fri, 23 Apr 2021 22:41:26 +0200
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
In-Reply-To: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>

On Thu, Apr 8, 2021 at 4:55 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> The change in the series has been inspired by [1], which, I think,
> can be improved. Here I present the view how it can be done.
>
> The series marked as RFT since I have no hardware and I perform
> compile test only.
>
> The patches 1 and 2 can be (independently) applied for v5.13, but I'm not in
> hurry with the series, due to above (lack of real testing). So I'm flexible in
> a way how it can be proceed.
>
> [1]: cover.1617380819.git.syednwaris at gmail.com
>
> Andy Shevchenko (5):
>   bitmap: Make bitmap_remap() and bitmap_bitremap() available to users
>   gpio: xilinx: Correct kernel doc for xgpio_probe()
>   gpio: xilinx: Introduce xgpio_read_chan() / xgpio_write_chan()
>   gpio: xilinx: Switch to use bitmap APIs
>   gpio: xilinx: No need to disable IRQs in the handler
>
>  drivers/gpio/gpio-xilinx.c | 377 ++++++++++++++++++-------------------
>  lib/bitmap.c               |   5 +-
>  2 files changed, 190 insertions(+), 192 deletions(-)
>
> --
> 2.30.2
>

I usually trust Andy with his work but is there any chance we can get
a Tested-by before the merge window?

Bart


From morbo at google.com  Fri Apr 23 21:51:59 2021
From: morbo at google.com (Bill Wendling)
Date: Fri, 23 Apr 2021 13:51:59 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
Message-ID: <20210423205159.830854-1-morbo@google.com>

The arm64 assembler in binutils 2.32 and above generates a program
property note in a note section, .note.gnu.property, to encode used x86
ISAs and features. But the kernel linker script only contains a single
NOTE segment:

  PHDRS
  {
    text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
    dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
    note    PT_NOTE    FLAGS(4);               /* PF_R */
  }

The NOTE segment generated by the vDSO linker script is aligned to 4 bytes.
But the .note.gnu.property section must be aligned to 8 bytes on arm64.

  $ readelf -n vdso64.so

  Displaying notes found in: .note
    Owner                Data size      Description
    Linux                0x00000004     Unknown note type: (0x00000000)
     description data: 06 00 00 00
  readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20
  readelf: Warning:  type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8

Since the note.gnu.property section in the vDSO is not checked by the
dynamic linker, discard the .note.gnu.property sections in the vDSO.

Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property
sections in vDSO"), but for arm64.

Signed-off-by: Bill Wendling <morbo at google.com>
---
 arch/arm64/kernel/vdso/vdso.lds.S | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
index 61dbb4c838ef..a5e61e09ea92 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -31,6 +31,13 @@ SECTIONS
 	.gnu.version_d	: { *(.gnu.version_d) }
 	.gnu.version_r	: { *(.gnu.version_r) }
 
+	/*
+	 * Discard .note.gnu.property sections which are unused and have
+	 * different alignment requirement from vDSO note sections.
+	 */
+	/DISCARD/	: {
+		*(.note.GNU-stack .note.gnu.property)
+	}
 	.note		: { *(.note.*) }		:text	:note
 
 	. = ALIGN(16);
@@ -48,7 +55,6 @@ SECTIONS
 	PROVIDE(end = .);
 
 	/DISCARD/	: {
-		*(.note.GNU-stack)
 		*(.data .data.* .gnu.linkonce.d.* .sdata*)
 		*(.bss .sbss .dynbss .dynsbss)
 		*(.eh_frame .eh_frame_hdr)
-- 
2.31.1.498.g6c1eba8ee3d-goog



From patchwork-bot+netdevbpf at kernel.org  Fri Apr 23 22:00:13 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Fri, 23 Apr 2021 21:00:13 +0000
Subject: [PATCH net-next v2 00/15] mtk_eth_soc: fixes and performance
 improvements
In-Reply-To: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
References: <20210423052108.423853-1-ilya.lipnitskiy@gmail.com>
Message-ID: <161921161314.19917.14237701035571279323.git-patchwork-notify@kernel.org>

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Thu, 22 Apr 2021 22:20:53 -0700 you wrote:
> Most of these changes come from OpenWrt where they have been present and
> tested for months.
> 
> First three patches are bug fixes. The rest are performance
> improvements. The last patch is a cleanup to use the iopoll.h macro for
> busy-waiting instead of a custom loop.
> 
> [...]

Here is the summary with links:
  - [net-next,v2,01/15] net: ethernet: mtk_eth_soc: fix RX VLAN offload
    https://git.kernel.org/netdev/net-next/c/3f57d8c40fea
  - [net-next,v2,02/15] net: ethernet: mtk_eth_soc: unmap RX data before calling build_skb
    https://git.kernel.org/netdev/net-next/c/5196c4178549
  - [net-next,v2,03/15] net: ethernet: mtk_eth_soc: fix build_skb cleanup
    https://git.kernel.org/netdev/net-next/c/787082ab9f7b
  - [net-next,v2,04/15] net: ethernet: mtk_eth_soc: use napi_consume_skb
    https://git.kernel.org/netdev/net-next/c/c30c4a827390
  - [net-next,v2,05/15] net: ethernet: mtk_eth_soc: reduce MDIO bus access latency
    https://git.kernel.org/netdev/net-next/c/3630d519d7c3
  - [net-next,v2,06/15] net: ethernet: mtk_eth_soc: remove unnecessary TX queue stops
    https://git.kernel.org/netdev/net-next/c/16ef670789b2
  - [net-next,v2,07/15] net: ethernet: mtk_eth_soc: use larger burst size for QDMA TX
    https://git.kernel.org/netdev/net-next/c/59555a8d0dd3
  - [net-next,v2,08/15] net: ethernet: mtk_eth_soc: increase DMA ring sizes
    https://git.kernel.org/netdev/net-next/c/6b4423b258b9
  - [net-next,v2,09/15] net: ethernet: mtk_eth_soc: implement dynamic interrupt moderation
    https://git.kernel.org/netdev/net-next/c/e9229ffd550b
  - [net-next,v2,10/15] net: ethernet: mtk_eth_soc: cache HW pointer of last freed TX descriptor
    https://git.kernel.org/netdev/net-next/c/4e6bf609569c
  - [net-next,v2,11/15] net: ethernet: mtk_eth_soc: only read the full RX descriptor if DMA is done
    https://git.kernel.org/netdev/net-next/c/816ac3e6e67b
  - [net-next,v2,12/15] net: ethernet: mtk_eth_soc: reduce unnecessary interrupts
    https://git.kernel.org/netdev/net-next/c/16769a8923fa
  - [net-next,v2,13/15] net: ethernet: mtk_eth_soc: rework NAPI callbacks
    https://git.kernel.org/netdev/net-next/c/db2c7b353db3
  - [net-next,v2,14/15] net: ethernet: mtk_eth_soc: set PPE flow hash as skb hash if present
    https://git.kernel.org/netdev/net-next/c/fa817272c37e
  - [net-next,v2,15/15] net: ethernet: mtk_eth_soc: use iopoll.h macro for DMA init
    https://git.kernel.org/netdev/net-next/c/3bc8e0aff23b

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From skomatineni at nvidia.com  Fri Apr 23 23:24:51 2021
From: skomatineni at nvidia.com (Sowjanya Komatineni)
Date: Fri, 23 Apr 2021 15:24:51 -0700
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com>
Message-ID: <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com>


On 4/23/21 1:16 PM, Lukasz Luba wrote:
> Hi Sowjanya,
>
> On 4/22/21 9:30 PM, Sowjanya Komatineni wrote:
>> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs 
>> which is
>> in charge of deciding on state transition based on target state, 
>> state idle
>> time, and some other Tegra CPU core cluster states information.
>>
>> Current PSCI specification don't have function defined for passing 
>> runtime
>> state idle time predicted by governor (based on next events and state 
>> target
>> residency) to ARM trusted firmware.
>
> Do you have some numbers from experiments showing that these idle
> governor prediction values, which are passed from kernel to MCE
> firmware, are making a good 'guess'?
> How much precision (1us? 1ms?) in the values do you need there?

it could also be in few ms depending on when next cpu event/activity 
might happen which is not transparent to MCE firmware.

>
> IIRC (probably Rafael's presentations) predicting in the kernel
> something like CPU idle time residency is not a trivial thing.
>
> Another idea (depending on DT structure and PSCI bits):
> Could this be solved differently, but just having a knowledge that if
> the governor requested some C-state, this means governor 'predicted'
> an idle residency to be greater that min_residency attached to this
> C-state?
> Then, when that request shows up in your FW, you know that it must be at
> least min_residency because of this C-state id.
C6 is the only deepest state for Tegra194 Carmel CPU that we support in 
addition to C1 (WFI) idle state.

MCE firmware gets state crossover thresholds for C1 to C6 transition 
from TF-A and uses it along with state idle time to decide on C6 state 
entry based on its background work.

Assuming for now if we use min_residency as state idle time which is 
static value from DT, then it enters into deepest state C6 always as we 
use min_residency value we use is always higher than state crossover 
threshold.

But MCE firmware is not aware of when next cpu event can happen to 
predict if next event can take longer than state min_residency time.

Using min residency in such case is very conservative where MCE firmware 
exits C6 state early where we may not have better power saving.

But with MCE firmware being aware of when next event can happen it can 
use that to stay in C6 state without early exit for better power savings.

> It would depend on number of available states, max_residency, scale
> that you would choose while assigning values from [0, max_residency]
> to each state.
> IIRC there can be many state IDs for idle, so it would depend on
> number of bits encoding this state, and your needs. Example of
> linear scale:
> 4-bits encoding idle state and max predicted residency 10msec,
> that means 10000us / 16 states = 625us/state.
> The max_residency might be split differently, using different than
> linear function, to have some rage more precised.
>
> Open question is if these idle states must be all represented
> in DT, or there is a way of describing a 'set of idle states'
> automatically.
We only support C6 state through DT as C6 is the only deepest state for 
Tegra194 carmel CPU. WFI idle state is completely handled by kernel and 
does not require MCE sequences for entry/exit.
>
> Regards,
> Lukasz


From lkp at intel.com  Fri Apr 23 23:50:55 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 24 Apr 2021 06:50:55 +0800
Subject: [soc:arm/drivers] BUILD SUCCESS
 5ffa828534036348fa90fb3079ccc0972d202c4a
Message-ID: <60834f4f.B7b3QZcoqRfr5B3I%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/drivers
branch HEAD: 5ffa828534036348fa90fb3079ccc0972d202c4a  soc: aspeed: fix a ternary sign expansion bug

elapsed time: 725m

configs tested: 129
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                               defconfig
arm                              allyesconfig
arm64                            allyesconfig
arm                              allmodconfig
i386                             allyesconfig
riscv                            allyesconfig
powerpc                    socrates_defconfig
m68k                       m5208evb_defconfig
powerpc                     tqm5200_defconfig
sh                          sdk7780_defconfig
s390                             alldefconfig
sh                   rts7751r2dplus_defconfig
m68k                       m5475evb_defconfig
m68k                          sun3x_defconfig
mips                       capcella_defconfig
powerpc                         wii_defconfig
arm                          exynos_defconfig
arm                            zeus_defconfig
xtensa                    xip_kc705_defconfig
arm64                            alldefconfig
arc                        nsim_700_defconfig
mips                    maltaup_xpa_defconfig
um                                  defconfig
mips                        workpad_defconfig
arm                         socfpga_defconfig
powerpc                     asp8347_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc                     tqm8540_defconfig
um                                allnoconfig
m68k                        mvme16x_defconfig
mips                  decstation_64_defconfig
sh                  sh7785lcr_32bit_defconfig
m68k                        stmark2_defconfig
arm                          moxart_defconfig
powerpc                     tqm8555_defconfig
arm                         vf610m4_defconfig
powerpc                        cell_defconfig
mips                        nlm_xlp_defconfig
sh                          lboxre2_defconfig
powerpc                     tqm8541_defconfig
arm                        shmobile_defconfig
mips                  maltasmvp_eva_defconfig
sh                           sh2007_defconfig
nios2                         3c120_defconfig
sh                 kfr2r09-romimage_defconfig
arm                            lart_defconfig
powerpc                  storcenter_defconfig
powerpc                     taishan_defconfig
h8300                       h8s-sim_defconfig
sh                          urquell_defconfig
powerpc                 linkstation_defconfig
powerpc                      pasemi_defconfig
arm                         s5pv210_defconfig
arm                             ezx_defconfig
mips                           ip22_defconfig
powerpc                     mpc5200_defconfig
arm                         lpc18xx_defconfig
powerpc                    mvme5100_defconfig
powerpc                     tqm8548_defconfig
mips                           gcw0_defconfig
sh                          polaris_defconfig
um                           x86_64_defconfig
ia64                        generic_defconfig
sh                     sh7710voipgw_defconfig
powerpc                      pcm030_defconfig
powerpc                 mpc832x_mds_defconfig
arm                         palmz72_defconfig
mips                        nlm_xlr_defconfig
arc                        nsimosci_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
nios2                            allyesconfig
alpha                            allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
xtensa                           allyesconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
s390                                defconfig
parisc                           allyesconfig
sparc                               defconfig
i386                                defconfig
sparc                            allyesconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
powerpc                          allyesconfig
x86_64               randconfig-a004-20210423
x86_64               randconfig-a003-20210423
i386                 randconfig-a002-20210423
i386                 randconfig-a001-20210423
i386                 randconfig-a003-20210423
i386                 randconfig-a012-20210423
i386                 randconfig-a013-20210423
i386                 randconfig-a015-20210423
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                               allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec
x86_64                           allyesconfig

clang tested configs:
x86_64               randconfig-a015-20210423
x86_64               randconfig-a016-20210423
x86_64               randconfig-a011-20210423
x86_64               randconfig-a014-20210423
x86_64               randconfig-a013-20210423

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From lkp at intel.com  Fri Apr 23 23:50:58 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 24 Apr 2021 06:50:58 +0800
Subject: [soc:for-next] BUILD SUCCESS d42805807be7cb74a13c1d3b0035148f3637e035
Message-ID: <60834f52.0Wcise3B+Qccylua%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: d42805807be7cb74a13c1d3b0035148f3637e035  Merge branch 'arm/drivers' into for-next

elapsed time: 725m

configs tested: 97
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                            allyesconfig
arm                              allmodconfig
arm                                 defconfig
arm64                               defconfig
arm                              allyesconfig
i386                             allyesconfig
mips                        workpad_defconfig
arm                         socfpga_defconfig
powerpc                     asp8347_defconfig
powerpc                       holly_defconfig
m68k                            mac_defconfig
powerpc                     tqm8540_defconfig
powerpc                    ge_imp3a_defconfig
sh                          r7780mp_defconfig
sh                             sh03_defconfig
ia64                          tiger_defconfig
mips                         mpc30x_defconfig
powerpc                     tqm8548_defconfig
powerpc                  mpc885_ads_defconfig
mips                      pic32mzda_defconfig
riscv                          rv32_defconfig
um                               allyesconfig
sparc                       sparc32_defconfig
mips                         tb0226_defconfig
xtensa                  cadence_csp_defconfig
powerpc                     tqm8541_defconfig
arm                        shmobile_defconfig
mips                  maltasmvp_eva_defconfig
sh                           sh2007_defconfig
sh                   rts7751r2dplus_defconfig
powerpc                     mpc5200_defconfig
arm                         lpc18xx_defconfig
powerpc                    mvme5100_defconfig
m68k                        stmark2_defconfig
sh                          lboxre2_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                                defconfig
m68k                             allmodconfig
m68k                             allyesconfig
arc                              allyesconfig
nios2                            allyesconfig
alpha                            allyesconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
h8300                            allyesconfig
xtensa                           allyesconfig
arc                                 defconfig
sh                               allmodconfig
nios2                               defconfig
nds32                             allnoconfig
parisc                              defconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
s390                             allyesconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
powerpc                          allyesconfig
i386                 randconfig-a002-20210423
i386                 randconfig-a001-20210423
i386                 randconfig-a003-20210423
i386                 randconfig-a014-20210423
i386                 randconfig-a012-20210423
i386                 randconfig-a011-20210423
i386                 randconfig-a013-20210423
i386                 randconfig-a015-20210423
i386                 randconfig-a016-20210423
x86_64               randconfig-a004-20210423
x86_64               randconfig-a003-20210423
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allyesconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a015-20210423
x86_64               randconfig-a016-20210423
x86_64               randconfig-a011-20210423
x86_64               randconfig-a014-20210423
x86_64               randconfig-a013-20210423

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From peng.fan at nxp.com  Sat Apr 24 00:28:00 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Fri, 23 Apr 2021 23:28:00 +0000
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <CANLsYkwoS+3qYq=FHRLMjrJSr5cj_PiHaU+a+M17C+8-VJ+b9g@mail.gmail.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
 <20210422165634.GD1256950@xps15>
 <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <CANLsYkwoS+3qYq=FHRLMjrJSr5cj_PiHaU+a+M17C+8-VJ+b9g@mail.gmail.com>
Message-ID: <DB6PR0402MB2760EA88942E5549BA9CC4B588459@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> i.MX7ULP/8MN/8MP
> 
> On Thu, 22 Apr 2021 at 19:01, Peng Fan <peng.fan at nxp.com> wrote:
> >
> > Hi Mathieu,
> >
> > > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > > i.MX7ULP/8MN/8MP
> > >
> > > On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com
> wrote:
> > > > From: Peng Fan <peng.fan at nxp.com>
> > > >
> > > > V5:
> > > >  Add R-b tag
> > > >  Move the change in detect mode of patch 5 to patch 7 Per
> > > > Mathieu's comments
> > > >
> > > > V4:
> > > >  Typo fix
> > > >  patch 4: take state as a check condition  patch 5: move regmap
> > > > lookup/attach to imx_rproc_detect_mode  patch 6: add
> > > > imx_rproc_clk_enable for optional clk  patch 8: use switch/case in
> > > > imx_rproc_detect_mode
> > > > V3:
> > > >  Add A-b tag for Patch 1/2
> > > >  Fix the checkpatch warning for Patch 6,8
> > > >
> > > > V2:
> > > >  Patch 1/8, use fsl as vendor, typo fix  Because patchset [1] has
> > > > v2 version, patch 5,6,7,8 are adapted that  change.
> > > >
> > > > This patchset is to support i.MX7ULP/8MN/8MP, also includes a
> > > > patch to parse fsl,auto-boot
> > > >
> > >
> > > One of the request I had from the last revision was to explicitly
> > > list what other patchset this work depends on and what branch it is
> > > based of, something I can't find here.
> >
> > Sorry, that patchset has been merged, so I remove that line.
> > I should mention that that patchset has been merged into Linux-next tree.
> >
> 
> And what branch this set should be applied to is missing.

I take latest linux-next/master for my upstream new feature work.

> 
> > >
> > > As such I am dropping this set and won't look at another revision
> > > before May 22nd.
> >
> > Ah. Is it just because that the dependency patchset not been mentioned
> > or you have issue applying the patchset that delay the patchset for one
> month?
> >
> 
> Both.

I replay my flow:
git fetch linux-next
git checkout linux-next/master -b master-next-4-24-2021
pwclient list -w "Peng Fan (OSS)" -s New | grep V5 | awk '{print $1}' | xargs -I {} pwclient git-am {}

It could successfully apply the patchset.
Applying patch #12215291 using 'git am'
Description: [V5,1/8] dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
Applying: dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
Applying patch #12215293 using 'git am'
Description: [V5,2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
Applying: dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
Applying patch #12215295 using 'git am'
Description: [V5,3/8] dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
Applying: dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
Applying patch #12215297 using 'git am'
Description: [V5,4/8] remoteproc: imx_rproc: parse fsl,auto-boot
Applying: remoteproc: imx_rproc: parse fsl,auto-boot
Applying patch #12215299 using 'git am'
Description: [V5,5/8] remoteproc: imx_rproc: initial support for mutilple start/stop method
Applying: remoteproc: imx_rproc: initial support for mutilple start/stop method
Applying patch #12215301 using 'git am'
Description: [V5,6/8] remoteproc: imx_rproc: make clk optional
Applying: remoteproc: imx_rproc: make clk optional
Applying patch #12215303 using 'git am'
Description: [V5,7/8] remoteproc: imx_rproc: support i.MX7ULP
Applying: remoteproc: imx_rproc: support i.MX7ULP
Applying patch #12215305 using 'git am'
Description: [V5,8/8] remoteproc: imx_rproc: support i.MX8MN/P
Applying: remoteproc: imx_rproc: support i.MX8MN/P


If anything wrong my work flow conflicts with Linux remoteproc subsystem upstream flow,
please correct me, and I'll follow.

Thanks for your time and patience on reviewing my patches. Sorry for the inconvince
that I bring in.

Anyway please share me your flow to apply patches, I will try to avoid unhappy things
in following patches. 

Thanks,
Peng.

> 
> > Thanks,
> > Peng.
> >
> > >
> > > > Peng Fan (8):
> > > >   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> > > >   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> > > >   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> > > >   remoteproc: imx_rproc: parse fsl,auto-boot
> > > >   remoteproc: imx_rproc: initial support for mutilple start/stop method
> > > >   remoteproc: imx_rproc: make clk optional
> > > >   remoteproc: imx_rproc: support i.MX7ULP
> > > >   remoteproc: imx_rproc: support i.MX8MN/P
> > > >
> > > >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
> > > >  drivers/remoteproc/imx_rproc.c                | 196
> > > +++++++++++++++---
> > > >  2 files changed, 173 insertions(+), 34 deletions(-)
> > > >
> > > > --
> > > > 2.30.0
> > > >

From chunkuang.hu at kernel.org  Sat Apr 24 00:50:07 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 24 Apr 2021 07:50:07 +0800
Subject: [PATCH 4/4] drm/mediatek: add dsi module reset driver
In-Reply-To: <20210420132614.150242-4-jitao.shi@mediatek.com>
References: <20210420132614.150242-1-jitao.shi@mediatek.com>
 <20210420132614.150242-4-jitao.shi@mediatek.com>
Message-ID: <CAAOTY__JZsAmGtX-+hNu0123xKoEdP2CgGxmQK2bqa-i+3dr6Q@mail.gmail.com>

Hi, Jitao:

Jitao Shi <jitao.shi at mediatek.com> ? 2021?4?20? ?? ??9:26???
>
> Reset dsi HW to default when power on. Prevent the setting differet
> between bootloader and kernel.
>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 36 +++++++++++++++++++++++++++++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 455fe582c6b5..113438ddd4cc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -7,10 +7,12 @@
>  #include <linux/component.h>
>  #include <linux/iopoll.h>
>  #include <linux/irq.h>
> +#include <linux/mfd/syscon.h>
>  #include <linux/of.h>
>  #include <linux/of_platform.h>
>  #include <linux/phy/phy.h>
>  #include <linux/platform_device.h>
> +#include <linux/regmap.h>
>
>  #include <video/mipi_display.h>
>  #include <video/videomode.h>
> @@ -143,6 +145,8 @@
>  #define DATA_0                         (0xff << 16)
>  #define DATA_1                         (0xff << 24)
>
> +#define MMSYS_SW_RST_DSI_B BIT(25)
> +
>  #define NS_TO_CYCLE(n, c)    ((n) / (c) + (((n) % (c)) ? 1 : 0))
>
>  #define MTK_DSI_HOST_IS_READ(type) \
> @@ -186,7 +190,8 @@ struct mtk_dsi {
>         struct drm_bridge *next_bridge;
>         struct drm_connector *connector;
>         struct phy *phy;
> -
> +       struct regmap *mmsys_sw_rst_b;
> +       u32 sw_rst_b;
>         void __iomem *regs;
>
>         struct clk *engine_clk;
> @@ -272,6 +277,16 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>         mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>
> +static void mtk_dsi_reset_all(struct mtk_dsi *dsi)
> +{
> +       regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
> +                          MMSYS_SW_RST_DSI_B, 0);
> +       usleep_range(1000, 1100);
> +
> +       regmap_update_bits(dsi->mmsys_sw_rst_b, dsi->sw_rst_b,
> +                          MMSYS_SW_RST_DSI_B, MMSYS_SW_RST_DSI_B);
> +}
> +
>  static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>         mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
> @@ -985,6 +1000,8 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
>
>         ret = mtk_dsi_encoder_init(drm, dsi);
>
> +       mtk_dsi_reset_all(dsi);
> +
>         return ret;
>  }
>
> @@ -1007,6 +1024,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>         struct device *dev = &pdev->dev;
>         struct drm_panel *panel;
>         struct resource *regs;
> +       struct regmap *regmap;
>         int irq_num;
>         int ret;
>
> @@ -1022,6 +1040,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>                 return ret;
>         }
>
> +       regmap = syscon_regmap_lookup_by_phandle(dev->of_node,
> +                                                "mediatek,syscon-dsi");
> +       ret = of_property_read_u32_index(dev->of_node, "mediatek,syscon-dsi", 1,
> +                                        &dsi->sw_rst_b);
> +
> +       if (IS_ERR(regmap))
> +               ret = PTR_ERR(regmap);
> +
> +       if (ret) {
> +               ret = PTR_ERR(regmap);
> +               dev_err(dev, "Failed to get mmsys registers: %d\n", ret);
> +               return ret;
> +       }
> +
> +       dsi->mmsys_sw_rst_b = regmap;
> +

It looks like that mtk-mmsys is the reset controller and mtk-dsi is
reset consumer. Please refer to [1], [2] to implement.

[1] https://www.kernel.org/doc/html/latest/driver-api/reset.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reset/reset.txt?h=v5.12-rc8

Regards,
Chun-Kuang.

>         ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
>                                           &panel, &dsi->next_bridge);
>         if (ret)
> --
> 2.25.1
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From email2tema at gmail.com  Sat Apr 24 01:08:57 2021
From: email2tema at gmail.com (Art Nikpal)
Date: Sat, 24 Apr 2021 08:08:57 +0800
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
In-Reply-To: <20210423114735.GA5507@sirena.org.uk>
References: <20210423034247.992052-1-art@khadas.com>
 <20210423114735.GA5507@sirena.org.uk>
Message-ID: <CAKaHn9LC19cduyrwxkDRAdM5pjgSPBCdZUjsEMgGqS7yVQS1-g@mail.gmail.com>

> I would expect the driver to unregister the controller at the start of
> the remove function, suspend doesn't really make sense here

It's strange - But without spi_master_suspend i have randomly stucks
when i try unload this module - as was written before
i was test it (load/unload module in loop) and for me suspend make sense here

If anybody has another solution - or real problem not here - please
help to find the right way!

PS: i have another way for solve this problem (may be it can help us
fix problem in kernel)

# before unload module need
echo -n spi0.0 > /sys/bus/spi/drivers/spi-nor/unbind
# after unbind driver we can unload module without problem
rmmod spi_meson_spifc # can stuck without unbind driver before ...


On Fri, Apr 23, 2021 at 7:48 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Fri, Apr 23, 2021 at 11:42:47AM +0800, Artem Lapkin wrote:
> > Problem: rmmod meson_gx_mmc - not stable without spi_master_suspend call
> > and we can get stuck when try unload this module
>
> > +++ b/drivers/spi/spi-meson-spifc.c
> > @@ -359,6 +359,7 @@ static int meson_spifc_remove(struct platform_device *pdev)
> >       struct spi_master *master = platform_get_drvdata(pdev);
> >       struct meson_spifc *spifc = spi_master_get_devdata(master);
> >
> > +     spi_master_suspend(master);
> >       pm_runtime_get_sync(&pdev->dev);
> >       clk_disable_unprepare(spifc->clk);
> >       pm_runtime_disable(&pdev->dev);
>
> I would expect the driver to unregister the controller at the start of
> the remove function, suspend doesn't really make sense here.


From asutoshd at codeaurora.org  Sat Apr 24 01:20:15 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Fri, 23 Apr 2021 17:20:15 -0700
Subject: [PATCH v21 0/2] Enable power management for ufs wlun 
Message-ID: <cover.1619223249.git.asutoshd@codeaurora.org>

This patch attempts to fix a deadlock in ufs while sending SSU.
Recently, blk_queue_enter() added a check to not process requests if the
queue is suspended. That leads to a resume of the associated device which
is suspended. In ufs, that device is ufs device wlun and it's parent is
ufs_hba. This resume tries to resume ufs device wlun which in turn tries
to resume ufs_hba, which is already in the process of suspending, thus
causing a deadlock.

This patch takes care of:
* Suspending the ufs device lun only after all other luns are suspended
* Sending SSU during ufs device wlun suspend
* Clearing uac for rpmb and ufs device wlun
* Not sending commands to the device during host suspend

v20 -> v21: 
- Addressed Adrian's comments

v19 -> v20:
- Addressed Adrian's comments
- Addressed Bart's comments

v18 -> v19:
- Addressed Adrian's comments
- Fixed smatch warnings

v17 -> v18:
- Addressed Adrian's comments

v16 -> v17:
- Addressed Adrian's & Daejun's comments

v15 -> v16:
- Brought back the missing changes
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Fix ufshcd_wl_poweroff()

v14 -> v15:
- Rebased on 5.13/scsi-staging

v13 -> v14:
- Addressed Adrian's comments
  * Rebased it on top of scsi-next
  * Added scsi_autopm_[get/put] to ufs_debugfs[get/put]_user_access()
  * Resume the device in ufshcd_remove()
  * Unregister ufs_rpmb_wlun before ufs_dev_wlun
  * hba->shutting_down moved to ufshcd_wl_shutdown()

v12 -> v13:
- Addressed Adrian's comments
  * Paired pm_runtime_get_noresume() with pm_runtime_put()
  * no rpm_autosuspend for ufs device wlun
  * Moved runtime-pm init functionality to ufshcd_wl_probe()
- Addressed Bart's comments
  * Expanded abbrevs in commit message

v11 -> v12:
- Addressed Adrian's comments
  * Fixed ahit for Mediatek driver
  * Fixed error handling in ufshcd_core_init()
  * Tested this patch and the issue is still seen.

v10 -> v11:
- Fixed supplier suspending before consumer race
- Addressed Adrian's comments
  * Added proper resume/suspend cb to ufshcd_auto_hibern8_update()
  * Cosmetic changes to ufshcd-pci.c
  * Cleaned up ufshcd_system_suspend()
  * Added ufshcd_debugfs_eh_exit to ufshcd_core_init()

v9 -> v10:
- Addressed Adrian's comments
  * Moved suspend/resume vops to __ufshcd_wl_[suspend/resume]()
  * Added correct resume in ufs_bsg

v8 -> v9:
- Addressed Adrian's comments
  * Moved link transition to __ufshcd_wl_[suspend/resume]()
  * Fixed the other minor comments

v7 -> v8:
- Addressed Adrian's comments
  * Removed separate autosuspend delay for ufs-device lun
  * Fixed the ee handler getting scheduled during pm
  * Always runtime resume in suspend_prepare()
  * Added CONFIG_PM_SLEEP where needed
  
v6 -> v7:
  * Resume the ufs device before shutting it down

v5 -> v6:
- Addressed Adrian's comments
  * Added complete() cb
  * Added suspend_prepare() and complete() to all drivers
  * Moved suspend_prepare() and complete() to ufshcd
  * .poweroff() uses ufhcd_wl_poweroff()
  * Removed several forward declarations
  * Moved scsi_register_driver() to ufshcd_core_init()

v4 -> v5:
- Addressed Adrian's comments
  * Used the rpmb driver contributed by Adrian
  * Runtime-resume the ufs device during suspend to honor spm-lvl
  * Unregister the scsi_driver in ufshcd_remove()
  * Currently shutdown() puts the ufs device to power-down mode
    so, just removed ufshcd_pci_poweroff()
  * Quiesce the scsi device during shutdown instead of remove

v3 RFC -> v4:
- Addressed Bart's comments
  * Except that I didn't get any checkpatch failures
- Addressed Avri's comments
- Addressed Adrian's comments
  * Added a check for deepsleep power mode
  * Removed a couple of forward declarations
  * Didn't separate the scsi drivers because in rpmb case it just sends uac
    in resume and it seemed pretty neat to me.
- Added sysfs changes to resume the devices before accessing

Asutosh Das (2):
  scsi: ufs: Enable power management for wlun
  ufs: sysfs: Resume the proper scsi device

 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs-sysfs.c       |  24 +-
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 700 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  33 ++
 include/trace/events/ufs.h         |  20 ++
 14 files changed, 585 insertions(+), 264 deletions(-)

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From asutoshd at codeaurora.org  Sat Apr 24 01:20:16 2021
From: asutoshd at codeaurora.org (Asutosh Das)
Date: Fri, 23 Apr 2021 17:20:16 -0700
Subject: [PATCH v21 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <cover.1619223249.git.asutoshd@codeaurora.org>
References: <cover.1619223249.git.asutoshd@codeaurora.org>
Message-ID: <4662c462e79e3e7f541f54f88f8993f421026d83.1619223249.git.asutoshd@codeaurora.org>

During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU (START_STOP_UNIT) to wlun
during its runtime-suspend.
During the process blk_queue_enter checks if the queue is not in
suspended state. If so, it waits for the queue to resume, and never
comes out of it.
The commit
(d55d15a33: scsi: block: Do not accept any requests while suspended)
adds the check if the queue is in suspended state in blk_queue_enter().

Call trace:
 __switch_to+0x174/0x2c4
 __schedule+0x478/0x764
 schedule+0x9c/0xe0
 blk_queue_enter+0x158/0x228
 blk_mq_alloc_request+0x40/0xa4
 blk_get_request+0x2c/0x70
 __scsi_execute+0x60/0x1c4
 ufshcd_set_dev_pwr_mode+0x124/0x1e4
 ufshcd_suspend+0x208/0x83c
 ufshcd_runtime_suspend+0x40/0x154
 ufshcd_pltfrm_runtime_suspend+0x14/0x20
 pm_generic_runtime_suspend+0x28/0x3c
 __rpm_callback+0x80/0x2a4
 rpm_suspend+0x308/0x614
 rpm_idle+0x158/0x228
 pm_runtime_work+0x84/0xac
 process_one_work+0x1f0/0x470
 worker_thread+0x26c/0x4c8
 kthread+0x13c/0x320
 ret_from_fork+0x10/0x18

Fix this by registering ufs device wlun as a scsi driver and
registering it for block runtime-pm. Also make this as a
supplier for all other luns. That way, this device wlun
suspends after all the consumers and resumes after
hba resumes. This also registers a new scsi driver for rpmb wlun.
This new driver is mostly used to clear rpmb uac.

Fixed smatch warnings:
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

Co-developed-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Can Guo <cang at codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>
---
 drivers/scsi/ufs/cdns-pltfrm.c     |   2 +
 drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
 drivers/scsi/ufs/ufs-debugfs.c     |   6 +-
 drivers/scsi/ufs/ufs-debugfs.h     |   2 +-
 drivers/scsi/ufs/ufs-exynos.c      |   2 +
 drivers/scsi/ufs/ufs-hisi.c        |   2 +
 drivers/scsi/ufs/ufs-mediatek.c    |  12 +-
 drivers/scsi/ufs/ufs-qcom.c        |   2 +
 drivers/scsi/ufs/ufs_bsg.c         |   6 +-
 drivers/scsi/ufs/ufshcd-pci.c      |  36 +-
 drivers/scsi/ufs/ufshcd.c          | 700 ++++++++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h          |  33 ++
 include/trace/events/ufs.h         |  20 ++
 13 files changed, 573 insertions(+), 252 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 13d9204..908ff39 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -323,6 +323,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver cdns_ufs_pltfrm_driver = {
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..ec4589a 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
 	.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
 	.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
 	.runtime_idle    = tc_dwc_g210_pci_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index ced9ef4..4e1ff20 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -13,7 +13,7 @@ void __init ufs_debugfs_init(void)
 	ufs_debugfs_root = debugfs_create_dir("ufshcd", NULL);
 }
 
-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)
 {
 	debugfs_remove_recursive(ufs_debugfs_root);
 }
@@ -60,14 +60,14 @@ __acquires(&hba->host_sem)
 		up(&hba->host_sem);
 		return -EBUSY;
 	}
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	return 0;
 }
 
 static void ufs_debugfs_put_user_access(struct ufs_hba *hba)
 __releases(&hba->host_sem)
 {
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 	up(&hba->host_sem);
 }
 
diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index 3ca29d3..97548a3 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -9,7 +9,7 @@ struct ufs_hba;
 
 #ifdef CONFIG_DEBUG_FS
 void __init ufs_debugfs_init(void);
-void __exit ufs_debugfs_exit(void);
+void ufs_debugfs_exit(void);
 void ufs_debugfs_hba_init(struct ufs_hba *hba);
 void ufs_debugfs_hba_exit(struct ufs_hba *hba);
 void ufs_debugfs_exception_event(struct ufs_hba *hba, u16 status);
diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c
index 70647ea..8b31efb 100644
--- a/drivers/scsi/ufs/ufs-exynos.c
+++ b/drivers/scsi/ufs/ufs-exynos.c
@@ -1267,6 +1267,8 @@ static const struct dev_pm_ops exynos_ufs_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver exynos_ufs_pltform = {
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa5813..a473349 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -574,6 +574,8 @@ static const struct dev_pm_ops ufs_hisi_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_hisi_pltform = {
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index a981f26..9912e20 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -810,12 +810,10 @@ static int ufs_mtk_post_link(struct ufs_hba *hba)
 	/* enable unipro clock gating feature */
 	ufs_mtk_cfg_unipro_cg(hba, true);
 
-	/* configure auto-hibern8 timer to 10ms */
-	if (ufshcd_is_auto_hibern8_supported(hba)) {
-		ufshcd_auto_hibern8_update(hba,
-			FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
-			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3));
-	}
+	/* will be configured during probe hba */
+	if (ufshcd_is_auto_hibern8_supported(hba))
+		hba->ahit = FIELD_PREP(UFSHCI_AHIBERN8_TIMER_MASK, 10) |
+			FIELD_PREP(UFSHCI_AHIBERN8_SCALE_MASK, 3);
 
 	ufs_mtk_setup_clk_gating(hba);
 
@@ -1097,6 +1095,8 @@ static const struct dev_pm_ops ufs_mtk_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_mtk_pltform = {
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9b711d6..9fc218f 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1556,6 +1556,8 @@ static const struct dev_pm_ops ufs_qcom_pm_ops = {
 	.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
 	.runtime_resume  = ufshcd_pltfrm_runtime_resume,
 	.runtime_idle    = ufshcd_pltfrm_runtime_idle,
+	.prepare	 = ufshcd_suspend_prepare,
+	.complete	 = ufshcd_resume_complete,
 };
 
 static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..39bf204 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 
 	bsg_reply->reply_payload_rcv_len = 0;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 
 	msgcode = bsg_request->msgcode;
 	switch (msgcode) {
@@ -106,7 +106,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		ret = ufs_bsg_alloc_desc_buffer(hba, job, &desc_buff,
 						&desc_len, desc_op);
 		if (ret) {
-			pm_runtime_put_sync(hba->dev);
+			ufshcd_rpm_put_sync(hba);
 			goto out;
 		}
 
@@ -138,7 +138,7 @@ static int ufs_bsg_request(struct bsg_job *job)
 		break;
 	}
 
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 
 	if (!desc_buff)
 		goto out;
diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
index 23ee828..e6c334b 100644
--- a/drivers/scsi/ufs/ufshcd-pci.c
+++ b/drivers/scsi/ufs/ufshcd-pci.c
@@ -410,29 +410,6 @@ static int ufshcd_pci_resume(struct device *dev)
 	return ufshcd_system_resume(dev_get_drvdata(dev));
 }
 
-/**
- * ufshcd_pci_poweroff - suspend-to-disk poweroff function
- * @dev: pointer to PCI device handle
- *
- * Returns 0 if successful
- * Returns non-zero otherwise
- */
-static int ufshcd_pci_poweroff(struct device *dev)
-{
-	struct ufs_hba *hba = dev_get_drvdata(dev);
-	int spm_lvl = hba->spm_lvl;
-	int ret;
-
-	/*
-	 * For poweroff we need to set the UFS device to PowerDown mode.
-	 * Force spm_lvl to ensure that.
-	 */
-	hba->spm_lvl = 5;
-	ret = ufshcd_system_suspend(hba);
-	hba->spm_lvl = spm_lvl;
-	return ret;
-}
-
 #endif /* !CONFIG_PM_SLEEP */
 
 #ifdef CONFIG_PM
@@ -533,17 +510,14 @@ ufshcd_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 }
 
 static const struct dev_pm_ops ufshcd_pci_pm_ops = {
-#ifdef CONFIG_PM_SLEEP
-	.suspend	= ufshcd_pci_suspend,
-	.resume		= ufshcd_pci_resume,
-	.freeze		= ufshcd_pci_suspend,
-	.thaw		= ufshcd_pci_resume,
-	.poweroff	= ufshcd_pci_poweroff,
-	.restore	= ufshcd_pci_resume,
-#endif
 	SET_RUNTIME_PM_OPS(ufshcd_pci_runtime_suspend,
 			   ufshcd_pci_runtime_resume,
 			   ufshcd_pci_runtime_idle)
+	SET_SYSTEM_SLEEP_PM_OPS(ufshcd_pci_suspend, ufshcd_pci_resume)
+#ifdef CONFIG_PM_SLEEP
+	.prepare	= ufshcd_suspend_prepare,
+	.complete	= ufshcd_resume_complete,
+#endif
 };
 
 static const struct pci_device_id ufshcd_pci_tbl[] = {
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0625da7..c8b5239 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -16,6 +16,7 @@
 #include <linux/bitfield.h>
 #include <linux/blk-pm.h>
 #include <linux/blkdev.h>
+#include <scsi/scsi_driver.h>
 #include "ufshcd.h"
 #include "ufs_quirks.h"
 #include "unipro.h"
@@ -77,6 +78,8 @@
 /* Polling time to wait for fDeviceInit */
 #define FDEVICEINIT_COMPL_TIMEOUT 1500 /* millisecs */
 
+#define wlun_dev_to_hba(dv) shost_priv(to_scsi_device(dv)->host)
+
 #define ufshcd_toggle_vreg(_dev, _vreg, _on)				\
 	({                                                              \
 		int _ret;                                               \
@@ -1551,7 +1554,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	if (value == hba->clk_scaling.is_enabled)
 		goto out;
 
-	pm_runtime_get_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
 	ufshcd_hold(hba, false);
 
 	hba->clk_scaling.is_enabled = value;
@@ -1567,7 +1570,7 @@ static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
 	}
 
 	ufshcd_release(hba);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_put_sync(hba);
 out:
 	up(&hba->host_sem);
 	return err ? err : count;
@@ -2565,6 +2568,17 @@ static inline u16 ufshcd_upiu_wlun_to_scsi_wlun(u8 upiu_wlun_id)
 	return (upiu_wlun_id & ~UFS_UPIU_WLUN_ID) | SCSI_W_LUN_BASE;
 }
 
+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+	return sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN);
+}
+
+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+	return sdev->lun ==
+		ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN);
+}
+
 static void ufshcd_init_lrb(struct ufs_hba *hba, struct ufshcd_lrb *lrb, int i)
 {
 	struct utp_transfer_cmd_desc *cmd_descp = hba->ucdl_base_addr;
@@ -4098,12 +4112,13 @@ void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit)
 	}
 	spin_unlock_irqrestore(hba->host->host_lock, flags);
 
-	if (update && !pm_runtime_suspended(hba->dev)) {
-		pm_runtime_get_sync(hba->dev);
+	if (update &&
+	    !pm_runtime_suspended(&hba->sdev_ufs_device->sdev_gendev)) {
+		ufshcd_rpm_get_sync(hba);
 		ufshcd_hold(hba, false);
 		ufshcd_auto_hibern8_enable(hba);
 		ufshcd_release(hba);
-		pm_runtime_put(hba->dev);
+		ufshcd_rpm_put_sync(hba);
 	}
 }
 EXPORT_SYMBOL_GPL(ufshcd_auto_hibern8_update);
@@ -4801,6 +4816,43 @@ static inline void ufshcd_get_lu_power_on_wp_status(struct ufs_hba *hba,
 }
 
 /**
+ * ufshcd_setup_links - associate link b/w device wlun and other luns
+ * @sdev: pointer to SCSI device
+ * @hba: pointer to ufs hba
+ */
+static void ufshcd_setup_links(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+	struct device_link *link;
+
+	/*
+	 * device wlun is the supplier & rest of the luns are consumers
+	 * This ensures that device wlun suspends after all other luns.
+	 */
+	if (hba->sdev_ufs_device) {
+		link = device_link_add(&sdev->sdev_gendev,
+				       &hba->sdev_ufs_device->sdev_gendev,
+				       DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
+		if (!link) {
+			dev_err(&sdev->sdev_gendev, "Failed establishing link - %s\n",
+				dev_name(&hba->sdev_ufs_device->sdev_gendev));
+			return;
+		}
+		hba->luns_avail--;
+		/* Ignore REPORT_LUN wlun probing */
+		if (hba->luns_avail == 1) {
+			ufshcd_rpm_put(hba);
+			return;
+		}
+	} else {
+		/*
+		 * Device wlun is probed. The assumption is that WLUNs are
+		 * scanned before other LUNs.
+		 */
+		hba->luns_avail--;
+	}
+}
+
+/**
  * ufshcd_slave_alloc - handle initial SCSI device configurations
  * @sdev: pointer to SCSI device
  *
@@ -4831,6 +4883,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
 
 	ufshcd_get_lu_power_on_wp_status(hba, sdev);
 
+	ufshcd_setup_links(hba, sdev);
+
 	return 0;
 }
 
@@ -4862,8 +4916,13 @@ static int ufshcd_slave_configure(struct scsi_device *sdev)
 	blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
 	if (hba->quirks & UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE)
 		blk_queue_update_dma_alignment(q, PAGE_SIZE - 1);
-
-	if (ufshcd_is_rpm_autosuspend_allowed(hba))
+	/*
+	 * Block runtime-pm until all consumers are added.
+	 * Refer ufshcd_setup_links().
+	 */
+	if (is_device_wlun(sdev))
+		pm_runtime_get_noresume(&sdev->sdev_gendev);
+	else if (ufshcd_is_rpm_autosuspend_allowed(hba))
 		sdev->rpm_autosuspend = 1;
 
 	ufshcd_crypto_setup_rq_keyslot_manager(hba, q);
@@ -4979,15 +5038,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 			 */
 			if (!hba->pm_op_in_progress &&
 			    !ufshcd_eh_in_progress(hba) &&
-			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-			    schedule_work(&hba->eeh_work)) {
-				/*
-				 * Prevent suspend once eeh_work is scheduled
-				 * to avoid deadlock between ufshcd_suspend
-				 * and exception event handler.
-				 */
-				pm_runtime_get_noresume(hba->dev);
-			}
+			    ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+				/* Flushed in suspend */
+				schedule_work(&hba->eeh_work);
 			break;
 		case UPIU_TRANSACTION_REJECT_UPIU:
 			/* TODO: handle Reject UPIU Response */
@@ -5586,8 +5639,8 @@ static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)
 	 * after a certain delay to recheck the threshold by next runtime
 	 * suspend.
 	 */
-	pm_runtime_get_sync(hba->dev);
-	pm_runtime_put_sync(hba->dev);
+	ufshcd_rpm_get_sync(hba);
+	ufshcd_rpm_put_sync(hba);
 }
 
 /**
@@ -5604,7 +5657,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	u32 status = 0;
 	hba = container_of(work, struct ufs_hba, eeh_work);
 
-	pm_runtime_get_sync(hba->dev);
 	ufshcd_scsi_block_requests(hba);
 	err = ufshcd_get_ee_status(hba, &status);
 	if (err) {
@@ -5621,14 +5673,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
 	ufs_debugfs_exception_event(hba, status);
 out:
 	ufshcd_scsi_unblock_requests(hba);
-	/*
-	 * pm_runtime_get_noresume is called while scheduling
-	 * eeh_work to avoid suspend racing with exception work.
-	 * Hence decrement usage counter using pm_runtime_put_noidle
-	 * to allow suspend on completion of exception event handler.
-	 */
-	pm_runtime_put_noidle(hba->dev);
-	pm_runtime_put(hba->dev);
 	return;
 }
 
@@ -5753,12 +5797,13 @@ static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool suspend)
 
 static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
 {
-	pm_runtime_get_sync(hba->dev);
-	if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+	ufshcd_rpm_get_sync(hba);
+	if (pm_runtime_status_suspended(&hba->sdev_ufs_device->sdev_gendev) ||
+	    hba->is_sys_suspended) {
 		enum ufs_pm_op pm_op;
 
 		/*
-		 * Don't assume anything of pm_runtime_get_sync(), if
+		 * Don't assume anything of resume, if
 		 * resume fails, irq and clocks can be OFF, and powers
 		 * can be OFF or in LPM.
 		 */
@@ -5794,12 +5839,13 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 	ufshcd_clear_ua_wluns(hba);
-	pm_runtime_put(hba->dev);
+	ufshcd_rpm_put(hba);
 }
 
 static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
 {
 	return (!hba->is_powered || hba->shutting_down ||
+		!hba->sdev_ufs_device ||
 		hba->ufshcd_state == UFSHCD_STATE_ERROR ||
 		(!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
 		   ufshcd_is_link_broken(hba))));
@@ -5815,14 +5861,18 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
 
 	hba->is_sys_suspended = false;
 	/*
-	 * Set RPM status of hba device to RPM_ACTIVE,
+	 * Set RPM status of wlun device to RPM_ACTIVE,
 	 * this also clears its runtime error.
 	 */
-	ret = pm_runtime_set_active(hba->dev);
+	ret = pm_runtime_set_active(&hba->sdev_ufs_device->sdev_gendev);
+
+	/* hba device might have a runtime error otherwise */
+	if (ret)
+		ret = pm_runtime_set_active(hba->dev);
 	/*
-	 * If hba device had runtime error, we also need to resume those
-	 * scsi devices under hba in case any of them has failed to be
-	 * resumed due to hba runtime resume failure. This is to unblock
+	 * If wlun device had runtime error, we also need to resume those
+	 * consumer scsi devices in case any of them has failed to be
+	 * resumed due to supplier runtime resume failure. This is to unblock
 	 * blk_queue_enter in case there are bios waiting inside it.
 	 */
 	if (!ret) {
@@ -7246,7 +7296,6 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
 		hba->sdev_ufs_device = NULL;
 		goto out;
 	}
-	ufshcd_blk_pm_runtime_init(hba->sdev_ufs_device);
 	scsi_device_put(hba->sdev_ufs_device);
 
 	hba->sdev_rpmb = __scsi_add_device(hba->host, 0, 0,
@@ -7410,6 +7459,9 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
 		goto out;
 	}
 
+	hba->luns_avail = desc_buf[DEVICE_DESC_PARAM_NUM_LU] +
+		desc_buf[DEVICE_DESC_PARAM_NUM_WLU];
+
 	ufs_fixup_device_setup(hba);
 
 	ufshcd_wb_probe(hba, desc_buf);
@@ -7887,6 +7939,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba, bool async)
 	ufshcd_set_ufs_dev_active(hba);
 	ufshcd_force_reset_auto_bkops(hba);
 	hba->wlun_dev_clr_ua = true;
+	hba->wlun_rpmb_clr_ua = true;
 
 	/* Gear up to HS gear if supported */
 	if (hba->max_pwr_info.is_valid) {
@@ -8472,7 +8525,8 @@ static int ufshcd_set_dev_pwr_mode(struct ufs_hba *hba,
 	 * handling context.
 	 */
 	hba->host->eh_noresume = 1;
-	ufshcd_clear_ua_wluns(hba);
+	if (hba->wlun_dev_clr_ua)
+		ufshcd_clear_ua_wlun(hba, UFS_UPIU_UFS_DEVICE_WLUN);
 
 	cmd[4] = pwr_mode << 4;
 
@@ -8647,23 +8701,7 @@ static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba)
 		ufshcd_setup_hba_vreg(hba, true);
 }
 
-/**
- * ufshcd_suspend - helper function for suspend operations
- * @hba: per adapter instance
- * @pm_op: desired low power operation type
- *
- * This function will try to put the UFS device and link into low power
- * mode based on the "rpm_lvl" (Runtime PM level) or "spm_lvl"
- * (System PM level).
- *
- * If this function is called during shutdown, it will make sure that
- * both UFS device and UFS link is powered off.
- *
- * NOTE: UFS device & link must be active before we enter in this function.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret = 0;
 	int check_for_bkops;
@@ -8671,7 +8709,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	enum ufs_dev_pwr_mode req_dev_pwr_mode;
 	enum uic_link_state req_link_state;
 
-	hba->pm_op_in_progress = 1;
+	hba->pm_op_in_progress = true;
 	if (!ufshcd_is_shutdown_pm(pm_op)) {
 		pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
 			 hba->rpm_lvl : hba->spm_lvl;
@@ -8694,17 +8732,17 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
-		goto disable_clks;
+		goto vops_suspend;
 	}
 
 	if ((req_dev_pwr_mode == hba->curr_dev_pwr_mode) &&
 	    (req_link_state == hba->uic_link_state))
-		goto enable_gating;
+		goto enable_scaling;
 
 	/* UFS device & link must be active before we enter in this function */
 	if (!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba)) {
 		ret = -EINVAL;
-		goto enable_gating;
+		goto enable_scaling;
 	}
 
 	if (ufshcd_is_runtime_pm(pm_op)) {
@@ -8716,7 +8754,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			 */
 			ret = ufshcd_urgent_bkops(hba);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		} else {
 			/* make sure that auto bkops is disabled */
 			ufshcd_disable_auto_bkops(hba);
@@ -8744,7 +8782,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 		if (!hba->dev_info.b_rpm_dev_flush_capable) {
 			ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
 			if (ret)
-				goto enable_gating;
+				goto enable_scaling;
 		}
 	}
 
@@ -8757,7 +8795,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (ret)
 		goto set_dev_active;
 
-disable_clks:
+vops_suspend:
 	/*
 	 * Call vendor specific suspend callback. As these callbacks may access
 	 * vendor specific host controller register space call them before the
@@ -8766,28 +8804,9 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	ret = ufshcd_vops_suspend(hba, pm_op);
 	if (ret)
 		goto set_link_active;
-	/*
-	 * Disable the host irq as host controller as there won't be any
-	 * host controller transaction expected till resume.
-	 */
-	ufshcd_disable_irq(hba);
-
-	ufshcd_setup_clocks(hba, false);
-
-	if (ufshcd_is_clkgating_allowed(hba)) {
-		hba->clk_gating.state = CLKS_OFF;
-		trace_ufshcd_clk_gating(dev_name(hba->dev),
-					hba->clk_gating.state);
-	}
-
-	ufshcd_vreg_set_lpm(hba);
-
-	/* Put the host controller in low power mode if possible */
-	ufshcd_hba_vreg_set_lpm(hba);
 	goto out;
 
 set_link_active:
-	ufshcd_vreg_set_hpm(hba);
 	/*
 	 * Device hardware reset is required to exit DeepSleep. Also, for
 	 * DeepSleep, the link is off so host reset and restore will be done
@@ -8809,57 +8828,32 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	}
 	if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
 		ufshcd_disable_auto_bkops(hba);
-enable_gating:
+enable_scaling:
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	hba->clk_gating.is_suspended = false;
 	hba->dev_info.b_rpm_dev_flush_capable = false;
-	ufshcd_clear_ua_wluns(hba);
-	ufshcd_release(hba);
 out:
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		schedule_delayed_work(&hba->rpm_dev_flush_recheck_work,
 			msecs_to_jiffies(RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS));
 	}
 
-	hba->pm_op_in_progress = 0;
-
-	if (ret)
-		ufshcd_update_evt_hist(hba, UFS_EVT_SUSPEND_ERR, (u32)ret);
+	if (ret) {
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
+		hba->clk_gating.is_suspended = false;
+		ufshcd_release(hba);
+	}
+	hba->pm_op_in_progress = false;
 	return ret;
 }
 
-/**
- * ufshcd_resume - helper function for resume operations
- * @hba: per adapter instance
- * @pm_op: runtime PM or system PM
- *
- * This function basically brings the UFS device, UniPro link and controller
- * to active state.
- *
- * Returns 0 for success and non-zero for failure
- */
-static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
+static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 {
 	int ret;
-	enum uic_link_state old_link_state;
-
-	hba->pm_op_in_progress = 1;
-	old_link_state = hba->uic_link_state;
+	enum uic_link_state old_link_state = hba->uic_link_state;
 
-	ufshcd_hba_vreg_set_hpm(hba);
-	ret = ufshcd_vreg_set_hpm(hba);
-	if (ret)
-		goto out;
-
-	/* Make sure clocks are enabled before accessing controller */
-	ret = ufshcd_setup_clocks(hba, true);
-	if (ret)
-		goto disable_vreg;
-
-	/* enable the host irq as host controller would be active soon */
-	ufshcd_enable_irq(hba);
+	hba->pm_op_in_progress = true;
 
 	/*
 	 * Call vendor specific resume callback. As these callbacks may access
@@ -8868,7 +8862,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	 */
 	ret = ufshcd_vops_resume(hba, pm_op);
 	if (ret)
-		goto disable_irq_and_vops_clks;
+		goto out;
 
 	/* For DeepSleep, the only supported option is to have the link off */
 	WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba));
@@ -8916,42 +8910,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 	if (hba->ee_usr_mask)
 		ufshcd_write_ee_control(hba);
 
-	hba->clk_gating.is_suspended = false;
-
 	if (ufshcd_is_clkscaling_supported(hba))
 		ufshcd_clk_scaling_suspend(hba, false);
 
-	/* Enable Auto-Hibernate if configured */
-	ufshcd_auto_hibern8_enable(hba);
-
 	if (hba->dev_info.b_rpm_dev_flush_capable) {
 		hba->dev_info.b_rpm_dev_flush_capable = false;
 		cancel_delayed_work(&hba->rpm_dev_flush_recheck_work);
 	}
 
-	ufshcd_clear_ua_wluns(hba);
-
-	/* Schedule clock gating in case of no access to UFS device yet */
-	ufshcd_release(hba);
-
+	/* Enable Auto-Hibernate if configured */
+	ufshcd_auto_hibern8_enable(hba);
 	goto out;
 
 set_old_link_state:
 	ufshcd_link_state_transition(hba, old_link_state, 0);
 vendor_suspend:
 	ufshcd_vops_suspend(hba, pm_op);
-disable_irq_and_vops_clks:
+out:
+	if (ret)
+		ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret);
+	hba->clk_gating.is_suspended = false;
+	ufshcd_release(hba);
+	hba->pm_op_in_progress = false;
+	return ret;
+}
+
+static int ufshcd_wl_runtime_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_suspend(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_runtime_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	ret = __ufshcd_wl_resume(hba, UFS_RUNTIME_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+
+	trace_ufshcd_wl_runtime_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_suspend(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+	down(&hba->host_sem);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_suspend(hba, UFS_SYSTEM_PM);
+	if (ret) {
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__,  ret);
+		up(&hba->host_sem);
+	}
+
+out:
+	if (!ret)
+		hba->is_sys_suspended = true;
+	trace_ufshcd_wl_suspend(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+
+	return ret;
+}
+
+static int ufshcd_wl_resume(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+	int ret = 0;
+	ktime_t start = ktime_get();
+
+	hba = shost_priv(sdev->host);
+
+	if (pm_runtime_suspended(dev))
+		goto out;
+
+	ret = __ufshcd_wl_resume(hba, UFS_SYSTEM_PM);
+	if (ret)
+		dev_err(&sdev->sdev_gendev, "%s failed: %d\n", __func__, ret);
+out:
+	trace_ufshcd_wl_resume(dev_name(dev), ret,
+		ktime_to_us(ktime_sub(ktime_get(), start)),
+		hba->curr_dev_pwr_mode, hba->uic_link_state);
+	if (!ret)
+		hba->is_sys_suspended = false;
+	up(&hba->host_sem);
+	return ret;
+}
+#endif
+
+static void ufshcd_wl_shutdown(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba;
+
+	hba = shost_priv(sdev->host);
+
+	down(&hba->host_sem);
+	hba->shutting_down = true;
+	up(&hba->host_sem);
+
+	/* Turn on everything while shutting down */
+	ufshcd_rpm_get_sync(hba);
+	scsi_device_quiesce(sdev);
+	shost_for_each_device(sdev, hba->host) {
+		if (sdev == hba->sdev_ufs_device)
+			continue;
+		scsi_device_quiesce(sdev);
+	}
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+}
+
+/**
+ * ufshcd_suspend - helper function for suspend operations
+ * @hba: per adapter instance
+ *
+ * This function will put disable irqs, turn off clocks
+ * and set vreg and hba-vreg in lpm mode.
+ * Also check the description of __ufshcd_wl_suspend().
+ */
+static int ufshcd_suspend(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+	/*
+	 * Disable the host irq as host controller as there won't be any
+	 * host controller transaction expected till resume.
+	 */
 	ufshcd_disable_irq(hba);
-	ufshcd_setup_clocks(hba, false);
+	ret = ufshcd_setup_clocks(hba, false);
+	if (ret) {
+		ufshcd_enable_irq(hba);
+		return ret;
+	}
 	if (ufshcd_is_clkgating_allowed(hba)) {
 		hba->clk_gating.state = CLKS_OFF;
 		trace_ufshcd_clk_gating(dev_name(hba->dev),
 					hba->clk_gating.state);
 	}
+
+	ufshcd_vreg_set_lpm(hba);
+	/* Put the host controller in low power mode if possible */
+	ufshcd_hba_vreg_set_lpm(hba);
+	return ret;
+}
+
+/**
+ * ufshcd_resume - helper function for resume operations
+ * @hba: per adapter instance
+ *
+ * This function basically turns on the regulators, clocks and
+ * irqs of the hba.
+ * Also check the description of __ufshcd_wl_resume().
+ *
+ * Returns 0 for success and non-zero for failure
+ */
+static int ufshcd_resume(struct ufs_hba *hba)
+{
+	int ret;
+
+	if (!hba->is_powered)
+		return 0;
+
+	ufshcd_hba_vreg_set_hpm(hba);
+	ret = ufshcd_vreg_set_hpm(hba);
+	if (ret)
+		goto out;
+
+	/* Make sure clocks are enabled before accessing controller */
+	ret = ufshcd_setup_clocks(hba, true);
+	if (ret)
+		goto disable_vreg;
+
+	/* enable the host irq as host controller would be active soon */
+	ufshcd_enable_irq(hba);
+	goto out;
+
 disable_vreg:
 	ufshcd_vreg_set_lpm(hba);
 out:
-	hba->pm_op_in_progress = 0;
 	if (ret)
 		ufshcd_update_evt_hist(hba, UFS_EVT_RESUME_ERR, (u32)ret);
 	return ret;
@@ -8962,6 +9133,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
@@ -8970,41 +9142,14 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	down(&hba->host_sem);
-
-	if (!hba->is_powered)
-		return 0;
-
-	if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
-	     hba->curr_dev_pwr_mode) &&
-	    (ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-	     hba->uic_link_state) &&
-	     !hba->dev_info.b_rpm_dev_flush_capable)
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
 
-	if (pm_runtime_suspended(hba->dev)) {
-		/*
-		 * UFS device and/or UFS link low power states during runtime
-		 * suspend seems to be different than what is expected during
-		 * system suspend. Hence runtime resume the devic & link and
-		 * let the system suspend low power states to take effect.
-		 * TODO: If resume takes longer time, we might have optimize
-		 * it in future by not resuming everything if possible.
-		 */
-		ret = ufshcd_runtime_resume(hba);
-		if (ret)
-			goto out;
-	}
-
-	ret = ufshcd_suspend(hba, UFS_SYSTEM_PM);
+	ret = ufshcd_suspend(hba);
 out:
 	trace_ufshcd_system_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = true;
-	else
-		up(&hba->host_sem);
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_suspend);
@@ -9021,21 +9166,16 @@ int ufshcd_system_resume(struct ufs_hba *hba)
 	int ret = 0;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered || pm_runtime_suspended(hba->dev))
-		/*
-		 * Let the runtime resume take care of resuming
-		 * if runtime suspended.
-		 */
+	if (pm_runtime_suspended(hba->dev))
 		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+
+	ret = ufshcd_resume(hba);
+
 out:
 	trace_ufshcd_system_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
-	if (!ret)
-		hba->is_sys_suspended = false;
-	up(&hba->host_sem);
+
 	return ret;
 }
 EXPORT_SYMBOL(ufshcd_system_resume);
@@ -9045,19 +9185,17 @@ EXPORT_SYMBOL(ufshcd_system_resume);
  * @hba: per adapter instance
  *
  * Check the description of ufshcd_suspend() function for more details.
+ * Also check the description of __ufshcd_wl_suspend().
  *
  * Returns 0 for success and non-zero for failure
  */
 int ufshcd_runtime_suspend(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_suspend(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_suspend(hba);
+
 	trace_ufshcd_runtime_suspend(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9069,33 +9207,19 @@ EXPORT_SYMBOL(ufshcd_runtime_suspend);
  * ufshcd_runtime_resume - runtime resume routine
  * @hba: per adapter instance
  *
- * This function basically brings the UFS device, UniPro link and controller
+ * This function basically brings controller
  * to active state. Following operations are done in this function:
  *
  * 1. Turn on all the controller related clocks
- * 2. Bring the UniPro link out of Hibernate state
- * 3. If UFS device is in sleep state, turn ON VCC rail and bring the UFS device
- *    to active state.
- * 4. If auto-bkops is enabled on the device, disable it.
- *
- * So following would be the possible power state after this function return
- * successfully:
- *	S1: UFS device in Active state with VCC rail ON
- *	    UniPro link in Active state
- *	    All the UFS/UniPro controller clocks are ON
- *
- * Returns 0 for success and non-zero for failure
+ * 2. Turn ON VCC rail
  */
 int ufshcd_runtime_resume(struct ufs_hba *hba)
 {
-	int ret = 0;
+	int ret;
 	ktime_t start = ktime_get();
 
-	if (!hba->is_powered)
-		goto out;
-	else
-		ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
-out:
+	ret = ufshcd_resume(hba);
+
 	trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
 		ktime_to_us(ktime_sub(ktime_get(), start)),
 		hba->curr_dev_pwr_mode, hba->uic_link_state);
@@ -9113,30 +9237,20 @@ EXPORT_SYMBOL(ufshcd_runtime_idle);
  * ufshcd_shutdown - shutdown routine
  * @hba: per adapter instance
  *
- * This function would power off both UFS device and UFS link.
+ * This function would turn off both UFS device and UFS hba
+ * regulators. It would also disable clocks.
  *
  * Returns 0 always to allow force shutdown even in case of errors.
  */
 int ufshcd_shutdown(struct ufs_hba *hba)
 {
-	int ret = 0;
-
-	down(&hba->host_sem);
-	hba->shutting_down = true;
-	up(&hba->host_sem);
-
-	if (!hba->is_powered)
-		goto out;
-
 	if (ufshcd_is_ufs_dev_poweroff(hba) && ufshcd_is_link_off(hba))
 		goto out;
 
 	pm_runtime_get_sync(hba->dev);
 
-	ret = ufshcd_suspend(hba, UFS_SHUTDOWN_PM);
+	ufshcd_suspend(hba);
 out:
-	if (ret)
-		dev_err(hba->dev, "%s failed, err %d\n", __func__, ret);
 	hba->is_powered = false;
 	/* allow force shutdown even in case of errors */
 	return 0;
@@ -9150,6 +9264,8 @@ EXPORT_SYMBOL(ufshcd_shutdown);
  */
 void ufshcd_remove(struct ufs_hba *hba)
 {
+	if (hba->sdev_ufs_device)
+		ufshcd_rpm_get_sync(hba);
 	ufs_bsg_remove(hba);
 	ufs_sysfs_remove_nodes(hba->dev);
 	blk_cleanup_queue(hba->tmf_queue);
@@ -9453,15 +9569,183 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(ufshcd_init);
 
+void ufshcd_resume_complete(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+
+	if (hba->complete_put) {
+		ufshcd_rpm_put(hba);
+		hba->complete_put = false;
+	}
+	if (hba->rpmb_complete_put) {
+		ufshcd_rpmb_rpm_put(hba);
+		hba->rpmb_complete_put = false;
+	}
+}
+EXPORT_SYMBOL_GPL(ufshcd_resume_complete);
+
+int ufshcd_suspend_prepare(struct device *dev)
+{
+	struct ufs_hba *hba = dev_get_drvdata(dev);
+	int ret;
+
+	/*
+	 * SCSI assumes that runtime-pm and system-pm for scsi drivers
+	 * are same. And it doesn't wake up the device for system-suspend
+	 * if it's runtime suspended. But ufs doesn't follow that.
+	 * Refer ufshcd_resume_complete()
+	 */
+	if (hba->sdev_ufs_device) {
+		ret = ufshcd_rpm_get_sync(hba);
+		if (ret < 0 && ret != -EACCES) {
+			ufshcd_rpm_put(hba);
+			return ret;
+		}
+		hba->complete_put = true;
+	}
+	if (hba->sdev_rpmb) {
+		ufshcd_rpmb_rpm_get_sync(hba);
+		hba->rpmb_complete_put = true;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(ufshcd_suspend_prepare);
+
+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+	struct ufs_hba *hba = shost_priv(sdev->host);
+
+	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
+	return 0;
+}
+#endif
+
+static int ufshcd_wl_probe(struct device *dev)
+{
+	struct scsi_device *sdev = to_scsi_device(dev);
+
+	if (!is_device_wlun(sdev))
+		return -ENODEV;
+
+	blk_pm_runtime_init(sdev->request_queue, dev);
+	pm_runtime_set_autosuspend_delay(dev, 0);
+	pm_runtime_allow(dev);
+
+	return  0;
+}
+
+static int ufshcd_wl_remove(struct device *dev)
+{
+	pm_runtime_forbid(dev);
+	return 0;
+}
+
+static const struct dev_pm_ops ufshcd_wl_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+	.suspend = ufshcd_wl_suspend,
+	.resume = ufshcd_wl_resume,
+	.freeze = ufshcd_wl_suspend,
+	.thaw = ufshcd_wl_resume,
+	.poweroff = ufshcd_wl_poweroff,
+	.restore = ufshcd_wl_resume,
+#endif
+	SET_RUNTIME_PM_OPS(ufshcd_wl_runtime_suspend, ufshcd_wl_runtime_resume, NULL)
+};
+
+/**
+ * ufs_dev_wlun_template - describes ufs device wlun
+ * ufs-device wlun - used to send pm commands
+ * All luns are consumers of ufs-device wlun.
+ *
+ * Currently, no sd driver is present for wluns.
+ * Hence the no specific pm operations are performed.
+ * With ufs design, SSU should be sent to ufs-device wlun.
+ * Hence register a scsi driver for ufs wluns only.
+ */
+static struct scsi_driver ufs_dev_wlun_template = {
+	.gendrv = {
+		.name = "ufs_device_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_wl_probe,
+		.remove = ufshcd_wl_remove,
+		.pm = &ufshcd_wl_pm_ops,
+		.shutdown = ufshcd_wl_shutdown,
+	},
+};
+
+static int ufshcd_rpmb_probe(struct device *dev)
+{
+	return is_rpmb_wlun(to_scsi_device(dev)) ? 0 : -ENODEV;
+}
+
+static inline int ufshcd_clear_rpmb_uac(struct ufs_hba *hba)
+{
+	int ret = 0;
+
+	if (!hba->wlun_rpmb_clr_ua)
+		return 0;
+	ret = ufshcd_clear_ua_wlun(hba, UFS_UPIU_RPMB_WLUN);
+	if (!ret)
+		hba->wlun_rpmb_clr_ua = 0;
+	return ret;
+}
+
+static int ufshcd_rpmb_resume(struct device *dev)
+{
+	struct ufs_hba *hba = wlun_dev_to_hba(dev);
+
+	if (hba->sdev_rpmb)
+		ufshcd_clear_rpmb_uac(hba);
+	return 0;
+}
+
+static const struct dev_pm_ops ufs_rpmb_pm_ops = {
+	SET_RUNTIME_PM_OPS(NULL, ufshcd_rpmb_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(NULL, ufshcd_rpmb_resume)
+};
+
+/**
+ * Describes the ufs rpmb wlun.
+ * Used only to send uac.
+ */
+static struct scsi_driver ufs_rpmb_wlun_template = {
+	.gendrv = {
+		.name = "ufs_rpmb_wlun",
+		.owner = THIS_MODULE,
+		.probe = ufshcd_rpmb_probe,
+		.pm = &ufs_rpmb_pm_ops,
+	},
+};
+
 static int __init ufshcd_core_init(void)
 {
+	int ret;
+
 	ufs_debugfs_init();
-	return 0;
+
+	ret = scsi_register_driver(&ufs_dev_wlun_template.gendrv);
+	if (ret)
+		goto debugfs_exit;
+
+	ret = scsi_register_driver(&ufs_rpmb_wlun_template.gendrv);
+	if (ret)
+		goto unregister;
+
+	return ret;
+unregister:
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
+debugfs_exit:
+	ufs_debugfs_exit();
+	return ret;
 }
 
 static void __exit ufshcd_core_exit(void)
 {
 	ufs_debugfs_exit();
+	scsi_unregister_driver(&ufs_rpmb_wlun_template.gendrv);
+	scsi_unregister_driver(&ufs_dev_wlun_template.gendrv);
 }
 
 module_init(ufshcd_core_init);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5eb66a8..b8b4fe2 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -72,6 +72,8 @@ enum ufs_event_type {
 	UFS_EVT_LINK_STARTUP_FAIL,
 	UFS_EVT_RESUME_ERR,
 	UFS_EVT_SUSPEND_ERR,
+	UFS_EVT_WL_SUSP_ERR,
+	UFS_EVT_WL_RES_ERR,
 
 	/* abnormal events */
 	UFS_EVT_DEV_RESET,
@@ -807,6 +809,7 @@ struct ufs_hba {
 	struct list_head clk_list_head;
 
 	bool wlun_dev_clr_ua;
+	bool wlun_rpmb_clr_ua;
 
 	/* Number of requests aborts */
 	int req_abort_count;
@@ -846,6 +849,9 @@ struct ufs_hba {
 	struct delayed_work debugfs_ee_work;
 	u32 debugfs_ee_rate_limit_ms;
 #endif
+	u32 luns_avail;
+	bool complete_put;
+	bool rpmb_complete_put;
 };
 
 /* Returns true if clocks can be gated. Otherwise false */
@@ -1105,6 +1111,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 			     enum query_opcode desc_op);
 
 int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
+int ufshcd_suspend_prepare(struct device *dev);
+void ufshcd_resume_complete(struct device *dev);
 
 /* Wrapper functions for safely calling variant operations */
 static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
@@ -1309,4 +1317,29 @@ static inline int ufshcd_update_ee_usr_mask(struct ufs_hba *hba,
 					&hba->ee_drv_mask, set, clr);
 }
 
+static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_put_sync(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev);
+}
+
+static inline int ufshcd_rpmb_rpm_get_sync(struct ufs_hba *hba)
+{
+	return pm_runtime_get_sync(&hba->sdev_rpmb->sdev_gendev);
+}
+
+static inline int ufshcd_rpmb_rpm_put(struct ufs_hba *hba)
+{
+	return pm_runtime_put(&hba->sdev_rpmb->sdev_gendev);
+}
+
 #endif /* End of Header */
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index 1cb6f1a..599739e 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -246,6 +246,26 @@ DEFINE_EVENT(ufshcd_template, ufshcd_init,
 		      int dev_state, int link_state),
 	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
 
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_suspend,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
+DEFINE_EVENT(ufshcd_template, ufshcd_wl_runtime_resume,
+	     TP_PROTO(const char *dev_name, int err, s64 usecs,
+		      int dev_state, int link_state),
+	     TP_ARGS(dev_name, err, usecs, dev_state, link_state));
+
 TRACE_EVENT(ufshcd_command,
 	TP_PROTO(const char *dev_name, enum ufs_trace_str_t str_t,
 		 unsigned int tag, u32 doorbell, int transfer_len, u32 intr,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



From chunkuang.hu at kernel.org  Sat Apr 24 01:24:10 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 24 Apr 2021 08:24:10 +0800
Subject: [PATCH v3 3/5] gpu/drm: mediatek: hdmi: add check for CEA modes
 only
In-Reply-To: <20210419073244.2678688-4-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
 <20210419073244.2678688-4-narmstrong@baylibre.com>
Message-ID: <CAAOTY_8g0voFQb22RrvMdYst7U0SZOUE+U5oab5bGJXD0nJsJQ@mail.gmail.com>

Hi, Neil:

Neil Armstrong <narmstrong at baylibre.com> ? 2021?4?19? ?? ??3:33???
>
> Some SoCs like the MT8167 are not validated and supported for HDMI modes
> out of HDMI CEA modes, so add a configuration boolean to filter out
> non-CEA modes.

Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>

>
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index dea46d66e712..0539262e69d3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -148,6 +148,7 @@ struct hdmi_audio_param {
>
>  struct mtk_hdmi_conf {
>         bool tz_disabled;
> +       bool cea_modes_only;
>  };
>
>  struct mtk_hdmi {
> @@ -1222,6 +1223,9 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
>                         return MODE_BAD;
>         }
>
> +       if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
> +               return MODE_BAD;
> +
>         if (mode->clock < 27000)
>                 return MODE_CLOCK_LOW;
>         if (mode->clock > 297000)
> --
> 2.25.1
>


From chunkuang.hu at kernel.org  Sat Apr 24 01:24:45 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 24 Apr 2021 08:24:45 +0800
Subject: [PATCH v3 4/5] gpu/drm: mediatek: hdmi: add optional limit on
 maximal HDMI mode clock
In-Reply-To: <20210419073244.2678688-5-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
 <20210419073244.2678688-5-narmstrong@baylibre.com>
Message-ID: <CAAOTY_-N4D2PJR0-YG3r+tLg0kcFZh8zyN=7kBNJsghpZG4nDA@mail.gmail.com>

Hi, Neil:

Neil Armstrong <narmstrong at baylibre.com> ? 2021?4?19? ?? ??3:33???
>
> Some SoCs like the MT8167 have a hard limit on the maximal supported HDMI TMDS
> clock, so add a configuration value to filter out those modes.

Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>

>
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 0539262e69d3..bc50d97f2553 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -149,6 +149,7 @@ struct hdmi_audio_param {
>  struct mtk_hdmi_conf {
>         bool tz_disabled;
>         bool cea_modes_only;
> +       unsigned long max_mode_clock;
>  };
>
>  struct mtk_hdmi {
> @@ -1226,6 +1227,10 @@ static int mtk_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
>         if (hdmi->conf->cea_modes_only && !drm_match_cea_mode(mode))
>                 return MODE_BAD;
>
> +       if (hdmi->conf->max_mode_clock &&
> +           mode->clock > hdmi->conf->max_mode_clock)
> +               return MODE_CLOCK_HIGH;
> +
>         if (mode->clock < 27000)
>                 return MODE_CLOCK_LOW;
>         if (mode->clock > 297000)
> --
> 2.25.1
>


From chunkuang.hu at kernel.org  Sat Apr 24 01:25:36 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Sat, 24 Apr 2021 08:25:36 +0800
Subject: [PATCH v3 5/5] gpu/drm: mediatek: hdmi: add MT8167 configuration
In-Reply-To: <20210419073244.2678688-6-narmstrong@baylibre.com>
References: <20210419073244.2678688-1-narmstrong@baylibre.com>
 <20210419073244.2678688-6-narmstrong@baylibre.com>
Message-ID: <CAAOTY_9PyKK4+gqiU4aP48fB-y34EdW7RULBxOfU2KU+V1toXw@mail.gmail.com>

Hi, Neil:

Neil Armstrong <narmstrong at baylibre.com> ? 2021?4?19? ?? ??3:33???
>
> The MT8167 SoC have a hard limit on the maximal supported HDMI TMDS clock,
> and is not validated and supported for HDMI modes out of HDMI CEA modes,
> so add a configuration entry linked to the MT8167 compatible.

Reviewed-by: Chun-Kuang Hu <chunkuang.hu at kernel.org>

>
> Signed-off-by: Fabien Parent <fparent at baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index bc50d97f2553..c1651a83700d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1787,10 +1787,18 @@ static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
>         .tz_disabled = true,
>  };
>
> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8167 = {
> +       .max_mode_clock = 148500,
> +       .cea_modes_only = true,
> +};
> +
>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
>         { .compatible = "mediatek,mt2701-hdmi",
>           .data = &mtk_hdmi_conf_mt2701,
>         },
> +       { .compatible = "mediatek,mt8167-hdmi",
> +         .data = &mtk_hdmi_conf_mt8167,
> +       },
>         { .compatible = "mediatek,mt8173-hdmi",
>         },
>         {}
> --
> 2.25.1
>


From lkp at intel.com  Sat Apr 24 03:09:12 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 24 Apr 2021 10:09:12 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS a1768dad775b5ceb25d17bc7a13318f43adf3069
Message-ID: <60837dc8.73o8+84dUG5+PYWp%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: a1768dad775b5ceb25d17bc7a13318f43adf3069  Merge branch 'tegra/dt64' into arm/fixes

elapsed time: 722m

configs tested: 110
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm                                 defconfig
arm64                            allyesconfig
arm64                               defconfig
arm                              allmodconfig
arm                              allyesconfig
riscv                            allyesconfig
arc                      axs103_smp_defconfig
arm                            pleb_defconfig
um                             i386_defconfig
arm                        vexpress_defconfig
mips                        bcm47xx_defconfig
mips                        nlm_xlp_defconfig
arm                            dove_defconfig
sh                           sh2007_defconfig
sh                         ecovec24_defconfig
arm                          lpd270_defconfig
arm                         orion5x_defconfig
powerpc                     tqm5200_defconfig
mips                        maltaup_defconfig
powerpc                         wii_defconfig
mips                      loongson3_defconfig
mips                   sb1250_swarm_defconfig
powerpc                    sam440ep_defconfig
sh                          rsk7203_defconfig
mips                     loongson1b_defconfig
m68k                       bvme6000_defconfig
um                               alldefconfig
sh                        dreamcast_defconfig
sh                           se7724_defconfig
arm64                            alldefconfig
mips                  decstation_64_defconfig
m68k                          multi_defconfig
mips                     cu1830-neo_defconfig
parisc                generic-64bit_defconfig
arm                         lubbock_defconfig
powerpc                  storcenter_defconfig
arm                       spear13xx_defconfig
openrisc                  or1klitex_defconfig
m68k                        m5272c3_defconfig
arc                        vdk_hs38_defconfig
arm                     eseries_pxa_defconfig
powerpc                     tqm8555_defconfig
sh                           se7619_defconfig
mips                 decstation_r4k_defconfig
arm                  colibri_pxa300_defconfig
mips                     cu1000-neo_defconfig
mips                    maltaup_xpa_defconfig
ia64                      gensparse_defconfig
arm                            mps2_defconfig
arm                        trizeps4_defconfig
mips                      pic32mzda_defconfig
arm                            lart_defconfig
powerpc                      cm5200_defconfig
arm                       cns3420vb_defconfig
arm                            xcep_defconfig
h8300                    h8300h-sim_defconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
i386                             allyesconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a014-20210423
i386                 randconfig-a012-20210423
i386                 randconfig-a011-20210423
i386                 randconfig-a013-20210423
i386                 randconfig-a015-20210423
i386                 randconfig-a016-20210423
riscv                    nommu_k210_defconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                          rv32_defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                           allyesconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From mchehab+huawei at kernel.org  Sat Apr 24 07:44:15 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:15 +0200
Subject: [PATCH 05/78] media: mdk-mdp: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <6ff9d0c049f94f38fd0b172fe3a6dbb36ba2b87e.1619191723.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

While here, check if the PM runtime was caught during
chipset probing time.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rga/rga.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
index 9d122429706e..bf3fd71ec3af 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
 		goto unreg_video_dev;
 	}
 
-	pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
+	if (ret < 0)
+		goto unreg_video_dev;
 
 	rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
 	rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:24 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:24 +0200
Subject: [PATCH 14/78] staging: media: imx7-mipi-csis: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <d5f5cb75e48ef7386f83ed023ec3dc1f5be5d08f.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index 025fdc488bd6..1dc680d94a46 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -695,11 +695,10 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 
 		mipi_csis_clear_counters(state);
 
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
 		if (ret < 0 && ret != -ENOIOCTLCMD)
 			goto done;
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:13 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:13 +0200
Subject: [PATCH 03/78] media: mdk-mdp: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <8b84cb38beeac55b21c8cbc9dc16e1319c5dc960.1619191723.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
as it doesn't make any sense to return 0 if the PM runtime failed
to resume.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index ace4528cdc5e..f14779e7596e 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct mtk_mdp_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
 	if (ret < 0)
-		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
+		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
 			    ctx->id, ret);
 
-	return 0;
+	return ret;
 }
 
 static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx,
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:26 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:26 +0200
Subject: [PATCH 16/78] staging: media: cedrus_video: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <58a0e35f0da9e7c25dea9088a439a77c6a448626.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index b62eb8e84057..9ddd789d0b1f 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq, unsigned int count)
 	}
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(dev->dev);
+		ret = pm_runtime_resume_and_get(dev->dev);
+		if (ret < 0)
 			goto err_cleanup;
-		}
 
 		if (dev->dec_ops[ctx->current_codec]->start) {
 			ret = dev->dec_ops[ctx->current_codec]->start(ctx);
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:21 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:21 +0200
Subject: [PATCH 71/78] media: rkisp1-capture: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <563a000045b459596c013269311a738d2dddaa37.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..3730376897d9 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -1003,9 +1003,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
 	if (ret)
 		goto err_pipeline_stop;
 
-	ret = pm_runtime_get_sync(cap->rkisp1->dev);
+	ret = pm_runtime_resume_and_get(cap->rkisp1->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(cap->rkisp1->dev);
 		dev_err(cap->rkisp1->dev, "power up failed %d\n", ret);
 		goto err_destroy_dummy;
 	}
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:09 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:09 +0200
Subject: [PATCH 59/78] media: mtk-jpeg: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <eab8f44c9b31646771f00eb7b9a992b6f54bb529.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 88a23bce569d..a89c7b206eef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv)
 	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto enc_end;
 
@@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv)
 		return;
 	}
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto dec_end;
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:26 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:26 +0200
Subject: [PATCH 76/78] media: sun4i_v4l2: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <19ff6114784154d1ce289b01bd22230a37b77a98.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 4785faddf630..ed6ec41b9c2d 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -206,9 +206,9 @@ static int sun4i_csi_open(struct file *file)
 	if (ret)
 		return ret;
 
-	ret = pm_runtime_get_sync(csi->dev);
+	ret = pm_runtime_resume_and_get(csi->dev);
 	if (ret < 0)
-		goto err_pm_put;
+		goto err_unlock;
 
 	ret = v4l2_pipeline_pm_get(&csi->vdev.entity);
 	if (ret)
@@ -225,8 +225,7 @@ static int sun4i_csi_open(struct file *file)
 err_pipeline_pm_put:
 	v4l2_pipeline_pm_put(&csi->vdev.entity);
 
-err_pm_put:
-	pm_runtime_put(csi->dev);
+err_unlock:
 	mutex_unlock(&csi->lock);
 
 	return ret;
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:25 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:25 +0200
Subject: [PATCH 75/78] media: stm32: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <c3fdab46e373c69bdc88edb0efffce61cae06929.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/stm32/stm32-dcmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index bbcc2254fa2e..5f4e1db8cfcd 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -723,11 +723,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 	u32 val = 0;
 	int ret;
 
-	ret = pm_runtime_get_sync(dcmi->dev);
+	ret = pm_runtime_resume_and_get(dcmi->dev);
 	if (ret < 0) {
 		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
 			__func__, ret);
-		goto err_pm_put;
+		goto err_unlock;
 	}
 
 	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
@@ -848,6 +848,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_pm_put:
 	pm_runtime_put(dcmi->dev);
+err_unlock:
 	spin_lock_irq(&dcmi->irqlock);
 	/*
 	 * Return all buffers to vb2 in QUEUED state.
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:07 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:07 +0200
Subject: [PATCH 57/78] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <091915bb1cbec13b566d129f85ae229fcb92e2e4.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
 drivers/media/platform/exynos4-is/fimc-is.c        | 3 ++-
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
 drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
 drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
 drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
 drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
 drivers/media/platform/exynos4-is/mipi-csis.c      | 5 ++---
 8 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index 13c838d3f947..0da36443173c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
 		goto unlock;
 
 	set_bit(ST_CAPT_BUSY, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
-	if (ret < 0) {
-		pm_runtime_put_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
+	if (ret < 0)
 		goto unlock;
-	}
 
 	ret = v4l2_fh_open(file);
 	if (ret) {
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 972d9601d236..bca35866cc74 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -828,7 +828,7 @@ static int fimc_is_probe(struct platform_device *pdev)
 			goto err_irq;
 	}
 
-	ret = pm_runtime_get_sync(dev);
+	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0)
 		goto err_pm;
 
@@ -862,6 +862,7 @@ static int fimc_is_probe(struct platform_device *pdev)
 	fimc_is_unregister_subdevs(is);
 err_pm:
 	pm_runtime_put_noidle(dev);
+err_suspend:
 	if (!pm_runtime_enabled(dev))
 		fimc_is_runtime_suspend(dev);
 err_irq:
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..8d9dc597deaa 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -275,7 +275,7 @@ static int isp_video_open(struct file *file)
 	if (ret < 0)
 		goto unlock;
 
-	ret = pm_runtime_get_sync(&isp->pdev->dev);
+	ret = pm_runtime_resume_and_get(&isp->pdev->dev);
 	if (ret < 0)
 		goto rel_fh;
 
@@ -293,7 +293,6 @@ static int isp_video_open(struct file *file)
 	if (!ret)
 		goto unlock;
 rel_fh:
-	pm_runtime_put_noidle(&isp->pdev->dev);
 	v4l2_fh_release(file);
 unlock:
 	mutex_unlock(&isp->video_lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
index a77c49b18511..74b49d30901e 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -304,11 +304,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
 	pr_debug("on: %d\n", on);
 
 	if (on) {
-		ret = pm_runtime_get_sync(&is->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put(&is->pdev->dev);
+		ret = pm_runtime_resume_and_get(&is->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		set_bit(IS_ST_PWR_ON, &is->state);
 
 		ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index fe20af3a7178..4d8b18078ff3 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -469,9 +469,9 @@ static int fimc_lite_open(struct file *file)
 	}
 
 	set_bit(ST_FLITE_IN_USE, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_in_use;
 
 	ret = v4l2_fh_open(file);
 	if (ret < 0)
@@ -499,6 +499,7 @@ static int fimc_lite_open(struct file *file)
 	v4l2_fh_release(file);
 err_pm:
 	pm_runtime_put_sync(&fimc->pdev->dev);
+err_in_use:
 	clear_bit(ST_FLITE_IN_USE, &fimc->state);
 unlock:
 	mutex_unlock(&fimc->lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
index c9704a147e5c..7c1eb05c508f 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -75,7 +75,7 @@ static int start_streaming(struct vb2_queue *q, unsigned int count)
 	struct fimc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->fimc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->fimc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 13d192ba4aa6..9346d44a06c2 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -512,11 +512,9 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
 	if (!fmd->pmf)
 		return -ENXIO;
 
-	ret = pm_runtime_get_sync(fmd->pmf);
-	if (ret < 0) {
-		pm_runtime_put(fmd->pmf);
+	ret = pm_runtime_resume_and_get(fmd->pmf);
+	if (ret < 0)
 		return ret;
-	}
 
 	fmd->num_sensors = 0;
 
@@ -1291,7 +1289,7 @@ static int cam_clk_prepare(struct clk_hw *hw)
 	if (camclk->fmd->pmf == NULL)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(camclk->fmd->pmf);
+	ret = pm_runtime_resume_and_get(camclk->fmd->pmf);
 	return ret < 0 ? ret : 0;
 }
 
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 1aac167abb17..a0218237d66b 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
 	struct device *dev = &state->pdev->dev;
 
 	if (on)
-		return pm_runtime_get_sync(dev);
+		return pm_runtime_resume_and_get(dev);
 
 	return pm_runtime_put_sync(dev);
 }
@@ -509,9 +509,8 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
 
 	if (enable) {
 		s5pcsis_clear_counters(state);
-		ret = pm_runtime_get_sync(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
 		if (ret && ret != 1) {
-			pm_runtime_put_noidle(&state->pdev->dev);
 			return ret;
 		}
 	}
-- 
2.30.2



From dan.carpenter at oracle.com  Sat Apr 24 07:43:07 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Sat, 24 Apr 2021 09:43:07 +0300
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
In-Reply-To: <20210422174631.aruiqqqx3szboqdp@bogus>
References: <YIE7pdqV/h10tEAK@mwanda> <20210422174631.aruiqqqx3szboqdp@bogus>
Message-ID: <20210424064307.GV1959@kadam>

On Thu, Apr 22, 2021 at 06:46:31PM +0100, Sudeep Holla wrote:
> (dropping Tixy as I am sure it will bounce, he left/retired from Linaro
> long back)
> 
> On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote:
> > How type promotion works in ternary expressions is a bit tricky.
> > The problem is that scpi_clk_get_val() returns longs, "ret" is a int
> > which holds a negative error code, and le32_to_cpu() is an unsigned int.
> 
> Agreed.
> 
> > We want the negative error code to be cast to a negative long.  But
> > because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
> > becomes a high positive and then it is promoted to long and it is still
> > a high positive value.
> >
> 
> Thanks a lot for finding and fixing the bug!
> 
> > Fix this by getting rid of the ternary.
> >
> > Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol")
> > Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
> > ---
> >  drivers/firmware/arm_scpi.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> > index d0dee37ad522..3bf61854121d 100644
> > --- a/drivers/firmware/arm_scpi.c
> > +++ b/drivers/firmware/arm_scpi.c
> > @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
> >
> >  	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
> >  				sizeof(le_clk_id), &rate, sizeof(rate));
> > +	if (ret)
> > +		return ret;
> 
> This could be still an issue, ideally I would prefer to pass the return
> value via argument pointer and always return success/failure as return
> value. Can't remember any reason for this. Since this is old interface
> with limited platform to test, I think returning 0 as clock rate on error
> should be fine as Cristain suggested. If you agree with that, I can
> fix up when applying. 
> 

That sounds great.  Thanks.

regards,
dan carpenter



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:08 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:08 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
 drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..9d5841194f6b 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
 	struct gsc_dev *gsc = platform_get_drvdata(pdev);
 	int i;
 
-	pm_runtime_get_sync(&pdev->dev);
+	pm_runtime_resume_and_get(&pdev->dev);
 
 	gsc_unregister_m2m_device(gsc);
 	v4l2_device_unregister(&gsc->v4l2_dev);
@@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
 	for (i = 0; i < gsc->num_clocks; i++)
 		clk_disable_unprepare(gsc->clock[i]);
 
-	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 27a3c92c73bc..09551e96ac15 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -58,7 +58,7 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct gsc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->gsc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:31 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:31 +0200
Subject: [PATCH 21/78] media: s5p-jpeg: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <01560ba01a8e6ecb0e2e525e9b47a544c04f735c.1619191723.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 026111505f5a..c4f19418a460 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2568,7 +2568,7 @@ static int s5p_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(q);
 	int ret;
 
-	ret = pm_runtime_get_sync(ctx->jpeg->dev);
+	ret = pm_runtime_resume_and_get(ctx->jpeg->dev);
 
 	return ret > 0 ? 0 : ret;
 }
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:33 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:33 +0200
Subject: [PATCH 23/78] media: sun8i_rotate: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <4be9eda76abe0279438375abb0204bcf96aeb618.1619191723.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
index 3f81dd17755c..fbcca59a0517 100644
--- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
+++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
@@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
 		struct device *dev = ctx->dev->dev;
 		int ret;
 
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:20 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:20 +0200
Subject: [PATCH 70/78] media: rga-buf: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <d81e6df2d1a77dc70a4172b77fc15576010e05b3.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
index bf9a75b75083..81508ed5abf3 100644
--- a/drivers/media/platform/rockchip/rga/rga-buf.c
+++ b/drivers/media/platform/rockchip/rga/rga-buf.c
@@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct rockchip_rga *rga = ctx->rga;
 	int ret;
 
-	ret = pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(rga->dev);
 		rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
 		return ret;
 	}
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:45:23 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:45:23 +0200
Subject: [PATCH 73/78] media: s5p-mfc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <f01c6e2c5e61bc198443ecb82cd8a6eb6961b6d7.1619191723.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 62d2320a7218..88b7d33c9197 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -78,11 +78,9 @@ int s5p_mfc_power_on(void)
 {
 	int i, ret = 0;
 
-	ret = pm_runtime_get_sync(pm->device);
-	if (ret < 0) {
-		pm_runtime_put_noidle(pm->device);
+	ret = pm_runtime_resume_and_get(pm->device);
+	if (ret < 0)
 		return ret;
-	}
 
 	/* clock control */
 	for (i = 0; i < pm->num_clocks; i++) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:11 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:11 +0200
Subject: [PATCH 01/78] media: atmel: properly get pm_runtime
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <cd5ded1d2ea82a0fb0e983d014ffcebfadffae31.1619191723.git.mchehab+huawei@kernel.org>

There are several issues in the way the atmel driver handles
pm_runtime_get_sync():

- it doesn't check return codes;
- it doesn't properly decrement the usage_count on all places;
- it starts streaming even if pm_runtime_get_sync() fails.
- while it tries to get pm_runtime at the clock enable logic,
  it doesn't check if the operation was suceeded.

Replace all occurrences of it to use the new kAPI:
pm_runtime_resume_and_get(), which ensures that, if the
return code is not negative, the usage_count was incremented.

With that, add additional checks when this is called, in order
to ensure that errors will be properly addressed.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 26 ++++++++++++++-----
 drivers/media/platform/atmel/atmel-isi.c      | 19 +++++++++++---
 2 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..db1be719192a 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -294,9 +294,13 @@ static int isc_wait_clk_stable(struct clk_hw *hw)
 static int isc_clk_prepare(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	return isc_wait_clk_stable(hw);
 }
@@ -353,9 +357,13 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
 	u32 status;
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	regmap_read(isc_clk->regmap, ISC_CLKSR, &status);
 
@@ -807,7 +815,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 		goto err_start_stream;
 	}
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		goto err_pm_get;
 
 	ret = isc_configure(isc);
 	if (unlikely(ret))
@@ -838,7 +848,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_configure:
 	pm_runtime_put_sync(isc->dev);
-
+err_pm_get:
 	v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
 
 err_start_stream:
@@ -1831,7 +1841,9 @@ static void isc_awb_work(struct work_struct *w)
 	ctrls->hist_id = hist_id;
 	baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		return;
 
 	/*
 	 * only update if we have all the required histograms and controls
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index 0514be6153df..6a433926726d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -422,7 +422,9 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
 	struct frame_buffer *buf, *node;
 	int ret;
 
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	/* Enable stream on the sub device */
 	ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
@@ -782,9 +784,10 @@ static int isi_enum_frameintervals(struct file *file, void *fh,
 	return 0;
 }
 
-static void isi_camera_set_bus_param(struct atmel_isi *isi)
+static int isi_camera_set_bus_param(struct atmel_isi *isi)
 {
 	u32 cfg1 = 0;
+	int ret;
 
 	/* set bus param for ISI */
 	if (isi->pdata.hsync_act_low)
@@ -801,12 +804,16 @@ static void isi_camera_set_bus_param(struct atmel_isi *isi)
 	cfg1 |= ISI_CFG1_THMASK_BEATS_16;
 
 	/* Enable PM and peripheral clock before operate isi registers */
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
 	isi_writel(isi, ISI_CFG1, cfg1);
 
 	pm_runtime_put(isi->dev);
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------*/
@@ -1085,7 +1092,11 @@ static int isi_graph_notify_complete(struct v4l2_async_notifier *notifier)
 		dev_err(isi->dev, "No supported mediabus format found\n");
 		return ret;
 	}
-	isi_camera_set_bus_param(isi);
+	ret = isi_camera_set_bus_param(isi);
+	if (ret) {
+		dev_err(isi->dev, "Can't wake up device\n");
+		return ret;
+	}
 
 	ret = isi_set_default_fmt(isi);
 	if (ret) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Sat Apr 24 07:44:30 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Sat, 24 Apr 2021 08:44:30 +0200
Subject: [PATCH 20/78] media: mtk-vcodec: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <f4906ceabe4bbc6a6b10c2409a44b7a14f5c0926.1619191723.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index ddee7046ce42..fe096fe61c9d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -92,9 +92,9 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
-	ret = pm_runtime_get_sync(pm->dev);
+	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
-		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
+		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
 }
 
 void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
-- 
2.30.2



From lkp at intel.com  Sat Apr 24 10:36:57 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 24 Apr 2021 17:36:57 +0800
Subject: [PATCH 01/78] media: atmel: properly get pm_runtime
In-Reply-To: <cd5ded1d2ea82a0fb0e983d014ffcebfadffae31.1619191723.git.mchehab+huawei@kernel.org>
References: <cd5ded1d2ea82a0fb0e983d014ffcebfadffae31.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <202104241743.v0qZn5KP-lkp@intel.com>

Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on rockchip/for-next tegra/for-next v5.12-rc8 next-20210423]
[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]

url:    https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/media-use-pm_runtime_resume_and_get-instead-of-pm_runtime_get_sync/20210424-145029
base:   git://linuxtv.org/media_tree.git master
config: nios2-randconfig-s031-20210424 (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-341-g8af24329-dirty
        # https://github.com/0day-ci/linux/commit/40fc496edfa42498090c5a0d8230ec732b82bdc9
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mauro-Carvalho-Chehab/media-use-pm_runtime_resume_and_get-instead-of-pm_runtime_get_sync/20210424-145029
        git checkout 40fc496edfa42498090c5a0d8230ec732b82bdc9
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/media/platform/atmel/atmel-isc-base.c: In function 'isc_awb_work':
>> drivers/media/platform/atmel/atmel-isc-base.c:1844:2: error: 'ret' undeclared (first use in this function); did you mean 'net'?
    1844 |  ret = pm_runtime_resume_and_get(isc->dev);
         |  ^~~
         |  net
   drivers/media/platform/atmel/atmel-isc-base.c:1844:2: note: each undeclared identifier is reported only once for each function it appears in

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SERIAL_CORE_CONSOLE
   Depends on TTY && HAS_IOMEM
   Selected by
   - EARLY_PRINTK


vim +1844 drivers/media/platform/atmel/atmel-isc-base.c

  1811	
  1812	static void isc_awb_work(struct work_struct *w)
  1813	{
  1814		struct isc_device *isc =
  1815			container_of(w, struct isc_device, awb_work);
  1816		struct regmap *regmap = isc->regmap;
  1817		struct isc_ctrls *ctrls = &isc->ctrls;
  1818		u32 hist_id = ctrls->hist_id;
  1819		u32 baysel;
  1820		unsigned long flags;
  1821		u32 min, max;
  1822	
  1823		/* streaming is not active anymore */
  1824		if (isc->stop)
  1825			return;
  1826	
  1827		if (ctrls->hist_stat != HIST_ENABLED)
  1828			return;
  1829	
  1830		isc_hist_count(isc, &min, &max);
  1831		ctrls->hist_minmax[hist_id][HIST_MIN_INDEX] = min;
  1832		ctrls->hist_minmax[hist_id][HIST_MAX_INDEX] = max;
  1833	
  1834		if (hist_id != ISC_HIS_CFG_MODE_B) {
  1835			hist_id++;
  1836		} else {
  1837			isc_wb_update(ctrls);
  1838			hist_id = ISC_HIS_CFG_MODE_GR;
  1839		}
  1840	
  1841		ctrls->hist_id = hist_id;
  1842		baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
  1843	
> 1844		ret = pm_runtime_resume_and_get(isc->dev);
  1845		if (ret < 0)
  1846			return;
  1847	
  1848		/*
  1849		 * only update if we have all the required histograms and controls
  1850		 * if awb has been disabled, we need to reset registers as well.
  1851		 */
  1852		if (hist_id == ISC_HIS_CFG_MODE_GR || ctrls->awb == ISC_WB_NONE) {
  1853			/*
  1854			 * It may happen that DMA Done IRQ will trigger while we are
  1855			 * updating white balance registers here.
  1856			 * In that case, only parts of the controls have been updated.
  1857			 * We can avoid that by locking the section.
  1858			 */
  1859			spin_lock_irqsave(&isc->awb_lock, flags);
  1860			isc_update_awb_ctrls(isc);
  1861			spin_unlock_irqrestore(&isc->awb_lock, flags);
  1862	
  1863			/*
  1864			 * if we are doing just the one time white balance adjustment,
  1865			 * we are basically done.
  1866			 */
  1867			if (ctrls->awb == ISC_WB_ONETIME) {
  1868				v4l2_info(&isc->v4l2_dev,
  1869					  "Completed one time white-balance adjustment.\n");
  1870				/* update the v4l2 controls values */
  1871				isc_update_v4l2_ctrls(isc);
  1872				ctrls->awb = ISC_WB_NONE;
  1873			}
  1874		}
  1875		regmap_write(regmap, ISC_HIS_CFG, hist_id | baysel | ISC_HIS_CFG_RAR);
  1876		isc_update_profile(isc);
  1877		/* if awb has been disabled, we don't need to start another histogram */
  1878		if (ctrls->awb)
  1879			regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_HISREQ);
  1880	
  1881		pm_runtime_put_sync(isc->dev);
  1882	}
  1883	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 34795 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210424/f45bd0b0/attachment-0001.gz>

From lkp at intel.com  Sat Apr 24 11:21:23 2021
From: lkp at intel.com (kernel test robot)
Date: Sat, 24 Apr 2021 18:21:23 +0800
Subject: [PATCH 76/78] media: sun4i_v4l2: use pm_runtime_resume_and_get()
In-Reply-To: <19ff6114784154d1ce289b01bd22230a37b77a98.1619191723.git.mchehab+huawei@kernel.org>
References: <19ff6114784154d1ce289b01bd22230a37b77a98.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <202104241847.RVMtbDKs-lkp@intel.com>

Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20210423]
[cannot apply to rockchip/for-next tegra/for-next v5.12-rc8]
[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]

url:    https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/media-use-pm_runtime_resume_and_get-instead-of-pm_runtime_get_sync/20210424-145029
base:   git://linuxtv.org/media_tree.git master
config: nios2-randconfig-s031-20210424 (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-341-g8af24329-dirty
        # https://github.com/0day-ci/linux/commit/ddf22a45db8814ab855d3535a125e17f5e58f94b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mauro-Carvalho-Chehab/media-use-pm_runtime_resume_and_get-instead-of-pm_runtime_get_sync/20210424-145029
        git checkout ddf22a45db8814ab855d3535a125e17f5e58f94b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c: In function 'sun4i_csi_open':
>> drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c:215:3: error: label 'err_pm_put' used but not defined
     215 |   goto err_pm_put;
         |   ^~~~

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for SERIAL_CORE_CONSOLE
   Depends on TTY && HAS_IOMEM
   Selected by
   - EARLY_PRINTK


vim +/err_pm_put +215 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c

577bbf23b758848 Maxime Ripard         2019-08-22  199  
577bbf23b758848 Maxime Ripard         2019-08-22  200  static int sun4i_csi_open(struct file *file)
577bbf23b758848 Maxime Ripard         2019-08-22  201  {
577bbf23b758848 Maxime Ripard         2019-08-22  202  	struct sun4i_csi *csi = video_drvdata(file);
577bbf23b758848 Maxime Ripard         2019-08-22  203  	int ret;
577bbf23b758848 Maxime Ripard         2019-08-22  204  
577bbf23b758848 Maxime Ripard         2019-08-22  205  	ret = mutex_lock_interruptible(&csi->lock);
577bbf23b758848 Maxime Ripard         2019-08-22  206  	if (ret)
577bbf23b758848 Maxime Ripard         2019-08-22  207  		return ret;
577bbf23b758848 Maxime Ripard         2019-08-22  208  
ddf22a45db8814a Mauro Carvalho Chehab 2021-04-24  209  	ret = pm_runtime_resume_and_get(csi->dev);
577bbf23b758848 Maxime Ripard         2019-08-22  210  	if (ret < 0)
ddf22a45db8814a Mauro Carvalho Chehab 2021-04-24  211  		goto err_unlock;
577bbf23b758848 Maxime Ripard         2019-08-22  212  
8fd390b89cc8ca7 Ezequiel Garcia       2020-01-24  213  	ret = v4l2_pipeline_pm_get(&csi->vdev.entity);
577bbf23b758848 Maxime Ripard         2019-08-22  214  	if (ret)
577bbf23b758848 Maxime Ripard         2019-08-22 @215  		goto err_pm_put;
577bbf23b758848 Maxime Ripard         2019-08-22  216  
577bbf23b758848 Maxime Ripard         2019-08-22  217  	ret = v4l2_fh_open(file);
577bbf23b758848 Maxime Ripard         2019-08-22  218  	if (ret)
577bbf23b758848 Maxime Ripard         2019-08-22  219  		goto err_pipeline_pm_put;
577bbf23b758848 Maxime Ripard         2019-08-22  220  
577bbf23b758848 Maxime Ripard         2019-08-22  221  	mutex_unlock(&csi->lock);
577bbf23b758848 Maxime Ripard         2019-08-22  222  
577bbf23b758848 Maxime Ripard         2019-08-22  223  	return 0;
577bbf23b758848 Maxime Ripard         2019-08-22  224  
577bbf23b758848 Maxime Ripard         2019-08-22  225  err_pipeline_pm_put:
8fd390b89cc8ca7 Ezequiel Garcia       2020-01-24  226  	v4l2_pipeline_pm_put(&csi->vdev.entity);
577bbf23b758848 Maxime Ripard         2019-08-22  227  
ddf22a45db8814a Mauro Carvalho Chehab 2021-04-24  228  err_unlock:
577bbf23b758848 Maxime Ripard         2019-08-22  229  	mutex_unlock(&csi->lock);
577bbf23b758848 Maxime Ripard         2019-08-22  230  
577bbf23b758848 Maxime Ripard         2019-08-22  231  	return ret;
577bbf23b758848 Maxime Ripard         2019-08-22  232  }
577bbf23b758848 Maxime Ripard         2019-08-22  233  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 34795 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210424/1f253702/attachment-0001.gz>

From andriy.shevchenko at linux.intel.com  Sat Apr 24 12:08:42 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Sat, 24 Apr 2021 14:08:42 +0300
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
In-Reply-To: <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
Message-ID: <YIP8OsHSpEi1/RJg@smile.fi.intel.com>

On Fri, Apr 23, 2021 at 10:41:26PM +0200, Bartosz Golaszewski wrote:
> On Thu, Apr 8, 2021 at 4:55 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> >
> > The change in the series has been inspired by [1], which, I think,
> > can be improved. Here I present the view how it can be done.
> >
> > The series marked as RFT since I have no hardware and I perform
> > compile test only.
> >
> > The patches 1 and 2 can be (independently) applied for v5.13, but I'm not in
> > hurry with the series, due to above (lack of real testing). So I'm flexible in
> > a way how it can be proceed.
> >
> > [1]: cover.1617380819.git.syednwaris at gmail.com

> I usually trust Andy with his work but is there any chance we can get
> a Tested-by before the merge window?

I'm not in hurry with this and I really want to have a confirmation on this
before we proceed. I may send a v2 RFT after v5.13-rc1 is out.

Note TWIMC that the series has an additional followup fix that I sent
separately (it's properly linked to the thread nevertheless).

-- 
With Best Regards,
Andy Shevchenko




From andriy.shevchenko at linux.intel.com  Sat Apr 24 12:14:30 2021
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Sat, 24 Apr 2021 14:14:30 +0300
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
In-Reply-To: <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
Message-ID: <YIP9ltcdf7mNtYRd@smile.fi.intel.com>

On Fri, Apr 23, 2021 at 10:41:26PM +0200, Bartosz Golaszewski wrote:
> On Thu, Apr 8, 2021 at 4:55 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> >
> > The change in the series has been inspired by [1], which, I think,
> > can be improved. Here I present the view how it can be done.
> >
> > The series marked as RFT since I have no hardware and I perform
> > compile test only.
> >
> > The patches 1 and 2 can be (independently) applied for v5.13, but I'm not in
> > hurry with the series, due to above (lack of real testing). So I'm flexible in
> > a way how it can be proceed.

> >   bitmap: Make bitmap_remap() and bitmap_bitremap() available to users
> >   gpio: xilinx: Correct kernel doc for xgpio_probe()

Bart, thanks for the warm words, just pointing out that patches 1 and 2 has
been reviewed and may be applied for v5.13 cycle. Up to you.

> I usually trust Andy with his work but is there any chance we can get
> a Tested-by before the merge window?

-- 
With Best Regards,
Andy Shevchenko




From j.neuschaefer at gmx.net  Sat Apr 24 13:37:28 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Sat, 24 Apr 2021 14:37:28 +0200
Subject: [PATCH] ARM: imx: pm-imx5: Fix references to imx5_cpu_suspend_info
Message-ID: <20210424123729.578295-1-j.neuschaefer@gmx.net>

The name of the struct, as defined in arch/arm/mach-imx/pm-imx5.c,
is imx5_cpu_suspend_info.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---
 arch/arm/mach-imx/suspend-imx53.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/suspend-imx53.S b/arch/arm/mach-imx/suspend-imx53.S
index 41b8aad653634..46570ec2fbcfe 100644
--- a/arch/arm/mach-imx/suspend-imx53.S
+++ b/arch/arm/mach-imx/suspend-imx53.S
@@ -28,11 +28,11 @@
  *                              ^
  *                              ^
  *                      imx53_suspend code
- *              PM_INFO structure(imx53_suspend_info)
+ *              PM_INFO structure(imx5_cpu_suspend_info)
  * ======================== low address =======================
  */

-/* Offsets of members of struct imx53_suspend_info */
+/* Offsets of members of struct imx5_cpu_suspend_info */
 #define SUSPEND_INFO_MX53_M4IF_V_OFFSET		0x0
 #define SUSPEND_INFO_MX53_IOMUXC_V_OFFSET	0x4
 #define SUSPEND_INFO_MX53_IO_COUNT_OFFSET	0x8
--
2.30.2



From festevam at gmail.com  Sat Apr 24 13:43:41 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 24 Apr 2021 09:43:41 -0300
Subject: [PATCH] ARM: imx: pm-imx5: Fix references to imx5_cpu_suspend_info
In-Reply-To: <20210424123729.578295-1-j.neuschaefer@gmx.net>
References: <20210424123729.578295-1-j.neuschaefer@gmx.net>
Message-ID: <CAOMZO5DjYQYjfLb4Sn496-inV9PqVG6C4YVunxLxTYa93_DbpA@mail.gmail.com>

Hi Jonathan,

On Sat, Apr 24, 2021 at 9:39 AM Jonathan Neusch?fer
<j.neuschaefer at gmx.net> wrote:
>
> The name of the struct, as defined in arch/arm/mach-imx/pm-imx5.c,
> is imx5_cpu_suspend_info.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>

Good catch:

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From masahiroy at kernel.org  Sat Apr 24 16:57:00 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sun, 25 Apr 2021 00:57:00 +0900
Subject: [PATCH] ARM: boot: remove redundant piggy_data from clean-files
Message-ID: <20210424155700.818824-1-masahiroy@kernel.org>

Kbuild cleans up files listed in 'targets'.

'piggy_data' is already added to 'targets' a few lines above.

Adding it to 'clean-files' is redundant.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

 arch/arm/boot/compressed/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 182b300e3f8a..e046e78e7945 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -100,7 +100,7 @@ targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
 		 head.o $(OBJS)
 
-clean-files += piggy_data lib1funcs.S ashldi3.S bswapsdi2.S hyp-stub.S
+clean-files += lib1funcs.S ashldi3.S bswapsdi2.S hyp-stub.S
 
 KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
 
-- 
2.27.0



From zhouchuangao at vivo.com  Sat Apr 24 16:59:50 2021
From: zhouchuangao at vivo.com (zhouchuangao)
Date: Sat, 24 Apr 2021 08:59:50 -0700
Subject: [PATCH] MIPS: BCM63XX: Use BUG_ON instead of condition followed by
 BUG.
Message-ID: <1619279992-81335-1-git-send-email-zhouchuangao@vivo.com>

BUG_ON uses unlikely in if(), it can be optimized at compile time.

Usually, the condition in if() is not satisfied. In my opinion,
this can improve the efficiency of the multi-stage pipeline.

Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
---
 arch/mips/bcm63xx/gpio.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/mips/bcm63xx/gpio.c b/arch/mips/bcm63xx/gpio.c
index 16f353a..5c4a233 100644
--- a/arch/mips/bcm63xx/gpio.c
+++ b/arch/mips/bcm63xx/gpio.c
@@ -43,8 +43,7 @@ static void bcm63xx_gpio_set(struct gpio_chip *chip,
 	u32 *v;
 	unsigned long flags;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = gpio_out_low_reg;
@@ -70,8 +69,7 @@ static int bcm63xx_gpio_get(struct gpio_chip *chip, unsigned gpio)
 	u32 reg;
 	u32 mask;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = gpio_out_low_reg;
@@ -92,8 +90,7 @@ static int bcm63xx_gpio_set_direction(struct gpio_chip *chip,
 	u32 tmp;
 	unsigned long flags;
 
-	if (gpio >= chip->ngpio)
-		BUG();
+	BUG_ON(gpio >= chip->ngpio);
 
 	if (gpio < 32) {
 		reg = GPIO_CTL_LO_REG;
-- 
2.7.4



From masahiroy at kernel.org  Sat Apr 24 17:00:07 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sun, 25 Apr 2021 01:00:07 +0900
Subject: [PATCH] ARM: boot: remove redundant piggy_data from clean-files
Message-ID: <20210424160007.819275-1-masahiroy@kernel.org>

Kbuild cleans up files listed in 'targets'.

'piggy_data' is already added to 'targets' a few lines above.

Adding it to 'clean-files' is redundant.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

KernelVersion: v5.12-rc1

 arch/arm/boot/compressed/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 182b300e3f8a..e046e78e7945 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -100,7 +100,7 @@ targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
 		 head.o $(OBJS)
 
-clean-files += piggy_data lib1funcs.S ashldi3.S bswapsdi2.S hyp-stub.S
+clean-files += lib1funcs.S ashldi3.S bswapsdi2.S hyp-stub.S
 
 KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
 
-- 
2.27.0



From j.neuschaefer at gmx.net  Sat Apr 24 17:21:27 2021
From: j.neuschaefer at gmx.net (=?UTF-8?q?Jonathan=20Neusch=C3=A4fer?=)
Date: Sat, 24 Apr 2021 18:21:27 +0200
Subject: [PATCH] ARM: imx: Initialize SoC ID on i.MX50
Message-ID: <20210424162133.680213-1-j.neuschaefer@gmx.net>

As on i.MX51 and i.MX53, initialize the SoC ID based on the SoC
compatible string of the board.

Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>
---
 arch/arm/mach-imx/mach-imx50.c | 7 +++++++
 drivers/soc/imx/soc-imx.c      | 3 +++
 include/soc/imx/cpu.h          | 1 +
 3 files changed, 11 insertions(+)

diff --git a/arch/arm/mach-imx/mach-imx50.c b/arch/arm/mach-imx/mach-imx50.c
index f4da205f57db9..a2d35f9ba474a 100644
--- a/arch/arm/mach-imx/mach-imx50.c
+++ b/arch/arm/mach-imx/mach-imx50.c
@@ -9,6 +9,12 @@
 #include <asm/mach/arch.h>

 #include "common.h"
+#include "hardware.h"
+
+static void __init imx50_init_early(void)
+{
+	mxc_set_cpu_type(MXC_CPU_MX50);
+}

 static const char * const imx50_dt_board_compat[] __initconst = {
 	"fsl,imx50",
@@ -16,5 +22,6 @@ static const char * const imx50_dt_board_compat[] __initconst = {
 };

 DT_MACHINE_START(IMX50_DT, "Freescale i.MX50 (Device Tree Support)")
+	.init_early	= imx50_init_early,
 	.dt_compat	= imx50_dt_board_compat,
 MACHINE_END
diff --git a/drivers/soc/imx/soc-imx.c b/drivers/soc/imx/soc-imx.c
index 01bfea1cb64a8..e11d237b883a9 100644
--- a/drivers/soc/imx/soc-imx.c
+++ b/drivers/soc/imx/soc-imx.c
@@ -67,6 +67,9 @@ static int __init imx_soc_device_init(void)
 	case MXC_CPU_MX35:
 		soc_id = "i.MX35";
 		break;
+	case MXC_CPU_MX50:
+		soc_id = "i.MX50";
+		break;
 	case MXC_CPU_MX51:
 		soc_id = "i.MX51";
 		break;
diff --git a/include/soc/imx/cpu.h b/include/soc/imx/cpu.h
index 42d6aeb951fa6..0bf610acafd06 100644
--- a/include/soc/imx/cpu.h
+++ b/include/soc/imx/cpu.h
@@ -9,6 +9,7 @@
 #define MXC_CPU_MX27		27
 #define MXC_CPU_MX31		31
 #define MXC_CPU_MX35		35
+#define MXC_CPU_MX50		50
 #define MXC_CPU_MX51		51
 #define MXC_CPU_MX53		53
 #define MXC_CPU_IMX6SL		0x60
--
2.30.2



From ezequiel at collabora.com  Sat Apr 24 19:23:29 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Sat, 24 Apr 2021 15:23:29 -0300
Subject: [PATCH 05/78] media: mdk-mdp: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <6ff9d0c049f94f38fd0b172fe3a6dbb36ba2b87e.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <6ff9d0c049f94f38fd0b172fe3a6dbb36ba2b87e.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <aa053292f1efd29d01f8e1685e82d6f1b520e9a3.camel@collabora.com>

Hi Mauro,

On Sat, 2021-04-24 at 08:44 +0200, Mauro Carvalho Chehab wrote:
> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
> 
> While here, check if the PM runtime was caught during
> chipset probing time.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
> ?drivers/media/platform/rockchip/rga/rga.c | 4 +++-
> ?1 file changed, 3 insertions(+), 1 deletion(-)
> 

The commit log "media" mdk-mdp" is wrong here.

Maybe you can squash this commit with media: rga-buf: use pm_runtime_resume_and_get()?

Thanks,
Ezequiel



From f.fainelli at gmail.com  Sun Apr 25 02:03:41 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 24 Apr 2021 18:03:41 -0700
Subject: [PATCH] MIPS: BCM63XX: Use BUG_ON instead of condition followed
 by BUG.
In-Reply-To: <1619279992-81335-1-git-send-email-zhouchuangao@vivo.com>
References: <1619279992-81335-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <08bbb077-cfa3-69b8-e366-378f3c43a187@gmail.com>



On 4/24/2021 8:59 AM, zhouchuangao wrote:
> BUG_ON uses unlikely in if(), it can be optimized at compile time.
> 
> Usually, the condition in if() is not satisfied. In my opinion,
> this can improve the efficiency of the multi-stage pipeline.
> 
> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>

Acked-by: Florian Fainelli <f.fainelli at gmail.com>
-- 
Florian


From wangqing at vivo.com  Sun Apr 25 02:44:02 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:44:02 +0800
Subject: [PATCH V8 1/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1619315043-1345-1-git-send-email-wangqing@vivo.com>
References: <1619315043-1345-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619315043-1345-2-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The pretimeout notification shall occur at timeout-sec/2.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

V6:
- Realize pretimeout processing through dualmode.

V7:
- Add set_pretimeout().

V8:
- Fix some formatting problems.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 76 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 71 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..98a9b89
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,9 +25,10 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
-#define WDT_MIN_TIMEOUT		1
+#define WDT_MIN_TIMEOUT		2
 #define WDT_LENGTH_TIMEOUT(n)	((n) << 5)
 
 #define WDT_LENGTH		0x04
@@ -187,12 +188,19 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
 	u32 reg;
 
 	wdt_dev->timeout = timeout;
+	/*
+	 * In dual mode, irq will be triggered at timeout / 2
+	 * the real timeout occurs at timeout
+	 */
+	if (wdt_dev->pretimeout)
+		wdt_dev->pretimeout = timeout / 2;
 
 	/*
 	 * One bit is the value of 512 ticks
 	 * The clock has 32 KHz
 	 */
-	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+	reg = WDT_LENGTH_TIMEOUT((timeout - wdt_dev->pretimeout) << 6)
+			| WDT_LENGTH_KEY;
 	iowrite32(reg, wdt_base + WDT_LENGTH);
 
 	mtk_wdt_ping(wdt_dev);
@@ -239,13 +247,47 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+				  unsigned int timeout)
+{
+	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
+	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	u32 reg = ioread32(wdt_base + WDT_MODE);
+
+	if (timeout && !wdd->pretimeout) {
+		wdd->pretimeout = wdd->timeout / 2;
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else if (!timeout && wdd->pretimeout) {
+		wdd->pretimeout = 0;
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else {
+		return 0;
+	}
+
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return mtk_wdt_set_timeout(wdd, wdd->timeout);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +295,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +318,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +330,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+				       &mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From wangqing at vivo.com  Sun Apr 25 02:44:01 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:44:01 +0800
Subject: [PATCH V8 0/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
Message-ID: <1619315043-1345-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.
The pretimeout notification shall occur at timeout-sec/2.

Wang Qing (2):
  watchdog: mtk: support pre-timeout when the bark irq is available
  doc: mtk-wdt: support pre-timeout when the bark irq is available

 .../devicetree/bindings/watchdog/mtk-wdt.txt       |  5 ++
 drivers/watchdog/mtk_wdt.c                         | 76 ++++++++++++++++++++--
 2 files changed, 76 insertions(+), 5 deletions(-)

-- 
2.7.4



From wangqing at vivo.com  Sun Apr 25 02:44:03 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:44:03 +0800
Subject: [PATCH V8 2/2] doc: mtk-wdt: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619315043-1345-1-git-send-email-wangqing@vivo.com>
References: <1619315043-1345-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619315043-1345-3-git-send-email-wangqing@vivo.com>

Add description of pre-timeout in mtk-wdt.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index e36ba60..8e27777
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -1,5 +1,8 @@
 Mediatek SoCs Watchdog timer
 
+The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
+before the expiry.
+
 Required properties:
 
 - compatible should contain:
@@ -17,6 +20,7 @@ Required properties:
 - reg : Specifies base physical address and size of the registers.
 
 Optional properties:
+- interrupts: Watchdog pre-timeout (bark) interrupt.
 - timeout-sec: contains the watchdog timeout in seconds.
 - #reset-cells: Should be 1.
 
@@ -26,6 +30,7 @@ watchdog: watchdog at 10007000 {
 	compatible = "mediatek,mt8183-wdt",
 		     "mediatek,mt6589-wdt";
 	reg = <0 0x10007000 0 0x100>;
+	interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>;
 	timeout-sec = <10>;
 	#reset-cells = <1>;
 };
-- 
2.7.4



From wangqing at vivo.com  Sun Apr 25 02:52:05 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:52:05 +0800
Subject: [PATCH V9 0/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
Message-ID: <1619315527-8171-1-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.
The pretimeout notification shall occur at timeout-sec/2.

Wang Qing (2):
  watchdog: mtk: support pre-timeout when the bark irq is available
  doc: mtk-wdt: support pre-timeout when the bark irq is available

 .../devicetree/bindings/watchdog/mtk-wdt.txt       |  5 ++
 drivers/watchdog/mtk_wdt.c                         | 77 ++++++++++++++++++++--
 2 files changed, 77 insertions(+), 5 deletions(-)

-- 
2.7.4



From wangqing at vivo.com  Sun Apr 25 02:52:07 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:52:07 +0800
Subject: [PATCH V9 2/2] doc: mtk-wdt: support pre-timeout when the bark irq is
 available
In-Reply-To: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
References: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619315527-8171-3-git-send-email-wangqing@vivo.com>

Add description of pre-timeout in mtk-wdt.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index e36ba60..8e27777
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -1,5 +1,8 @@
 Mediatek SoCs Watchdog timer
 
+The watchdog supports a pre-timeout interrupt that fires timeout-sec/2
+before the expiry.
+
 Required properties:
 
 - compatible should contain:
@@ -17,6 +20,7 @@ Required properties:
 - reg : Specifies base physical address and size of the registers.
 
 Optional properties:
+- interrupts: Watchdog pre-timeout (bark) interrupt.
 - timeout-sec: contains the watchdog timeout in seconds.
 - #reset-cells: Should be 1.
 
@@ -26,6 +30,7 @@ watchdog: watchdog at 10007000 {
 	compatible = "mediatek,mt8183-wdt",
 		     "mediatek,mt6589-wdt";
 	reg = <0 0x10007000 0 0x100>;
+	interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>;
 	timeout-sec = <10>;
 	#reset-cells = <1>;
 };
-- 
2.7.4



From wangqing at vivo.com  Sun Apr 25 02:52:06 2021
From: wangqing at vivo.com (Wang Qing)
Date: Sun, 25 Apr 2021 09:52:06 +0800
Subject: [PATCH V9 1/2] watchdog: mtk: support pre-timeout when the bark irq
 is available
In-Reply-To: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
References: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
Message-ID: <1619315527-8171-2-git-send-email-wangqing@vivo.com>

Use the bark interrupt as the pretimeout notifier if available.

When the watchdog timer expires in dual mode, an interrupt will be
triggered first, then the timing restarts. The reset signal will be
initiated when the timer expires again.

The pretimeout notification shall occur at timeout-sec/2.

V2:
- panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.

V3:
- Modify the pretimeout behavior, manually reset after the pretimeout
- is processed and wait until timeout.

V4:
- Remove pretimeout related processing. 
- Add dual mode control separately.

V5:
- Fix some formatting and printing problems.

V6:
- Realize pretimeout processing through dualmode.

V7:
- Add set_pretimeout().

V8/V9:
- Fix some formatting problems.

Signed-off-by: Wang Qing <wangqing at vivo.com>
---
 drivers/watchdog/mtk_wdt.c | 77 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 72 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 97ca993..7bb0774
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -25,9 +25,10 @@
 #include <linux/reset-controller.h>
 #include <linux/types.h>
 #include <linux/watchdog.h>
+#include <linux/interrupt.h>
 
 #define WDT_MAX_TIMEOUT		31
-#define WDT_MIN_TIMEOUT		1
+#define WDT_MIN_TIMEOUT		2
 #define WDT_LENGTH_TIMEOUT(n)	((n) << 5)
 
 #define WDT_LENGTH		0x04
@@ -187,12 +188,19 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
 	u32 reg;
 
 	wdt_dev->timeout = timeout;
+	/*
+	 * In dual mode, irq will be triggered at timeout / 2
+	 * the real timeout occurs at timeout
+	 */
+	if (wdt_dev->pretimeout)
+		wdt_dev->pretimeout = timeout / 2;
 
 	/*
 	 * One bit is the value of 512 ticks
 	 * The clock has 32 KHz
 	 */
-	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+	reg = WDT_LENGTH_TIMEOUT((timeout - wdt_dev->pretimeout) << 6)
+			| WDT_LENGTH_KEY;
 	iowrite32(reg, wdt_base + WDT_LENGTH);
 
 	mtk_wdt_ping(wdt_dev);
@@ -239,13 +247,48 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
 		return ret;
 
 	reg = ioread32(wdt_base + WDT_MODE);
-	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	if (wdt_dev->pretimeout)
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	else
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
 	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
 	iowrite32(reg, wdt_base + WDT_MODE);
 
 	return 0;
 }
 
+static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
+				  unsigned int timeout)
+{
+	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
+	void __iomem *wdt_base = mtk_wdt->wdt_base;
+	u32 reg = ioread32(wdt_base + WDT_MODE);
+
+	if (timeout && !wdd->pretimeout) {
+		wdd->pretimeout = wdd->timeout / 2;
+		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else if (!timeout && wdd->pretimeout) {
+		wdd->pretimeout = 0;
+		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
+	} else {
+		return 0;
+	}
+
+	reg |= WDT_MODE_KEY;
+	iowrite32(reg, wdt_base + WDT_MODE);
+
+	return mtk_wdt_set_timeout(wdd, wdd->timeout);
+}
+
+static irqreturn_t mtk_wdt_isr(int irq, void *arg)
+{
+	struct watchdog_device *wdd = arg;
+
+	watchdog_notify_pretimeout(wdd);
+
+	return IRQ_HANDLED;
+}
+
 static const struct watchdog_info mtk_wdt_info = {
 	.identity	= DRV_NAME,
 	.options	= WDIOF_SETTIMEOUT |
@@ -253,12 +296,21 @@ static const struct watchdog_info mtk_wdt_info = {
 			  WDIOF_MAGICCLOSE,
 };
 
+static const struct watchdog_info mtk_wdt_pt_info = {
+	.identity	= DRV_NAME,
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_PRETIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE,
+};
+
 static const struct watchdog_ops mtk_wdt_ops = {
 	.owner		= THIS_MODULE,
 	.start		= mtk_wdt_start,
 	.stop		= mtk_wdt_stop,
 	.ping		= mtk_wdt_ping,
 	.set_timeout	= mtk_wdt_set_timeout,
+	.set_pretimeout	= mtk_wdt_set_pretimeout,
 	.restart	= mtk_wdt_restart,
 };
 
@@ -267,7 +319,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct mtk_wdt_dev *mtk_wdt;
 	const struct mtk_wdt_data *wdt_data;
-	int err;
+	int err, irq;
 
 	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
 	if (!mtk_wdt)
@@ -279,7 +331,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(mtk_wdt->wdt_base))
 		return PTR_ERR(mtk_wdt->wdt_base);
 
-	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	irq = platform_get_irq(pdev, 0);
+	if (irq > 0) {
+		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
+				       &mtk_wdt->wdt_dev);
+		if (err)
+			return err;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
+		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
+	} else {
+		if (irq == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
+
+		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
+	}
+
 	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
 	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
 	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
-- 
2.7.4



From shenkai8 at huawei.com  Sun Apr 25 03:07:39 2021
From: shenkai8 at huawei.com (Kai Shen)
Date: Sun, 25 Apr 2021 10:07:39 +0800
Subject: [PATCH] arm64:align function __arch_clear_user
In-Reply-To: <20210423153701.GP18757@arm.com>
References: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
 <20210414104144.GB8320@arm.com>
 <6829062c-a2d4-57da-4037-269fb7508993@huawei.com>
 <20210423153701.GP18757@arm.com>
Message-ID: <b7ed22f7-2c89-c67d-5e06-380964371150@huawei.com>

On 2021/4/23 23:37, Catalin Marinas wrote:
> On Mon, Apr 19, 2021 at 10:05:16AM +0800, Kai Shen wrote:
>> On 2021/4/14 18:41, Catalin Marinas wrote:
>>> On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
>>>> Performance decreases happen in __arch_clear_user when this
>>>> function is not correctly aligned on HISI-HIP08 arm64 SOC which
>>>> fetches 32 bytes (8 instructions) from icache with a 32-bytes
>>>> aligned end address. As a result, if the hot loop is not 32-bytes
>>>> aligned, it may take more icache fetches which leads to decrease
>>>> in performance.
>>>> Dump of assembler code for function __arch_clear_user:
>>>>          0xffff0000809e3f10 :    nop
>>>>          0xffff0000809e3f14 :    mov x2, x1
>>>>          0xffff0000809e3f18 :    subs x1, x1, #0x8
>>>>          0xffff0000809e3f1c :    b.mi 0xffff0000809e3f30 <__arch_clear_user+3
>>>> -----  0xffff0000809e3f20 :    str    xzr, [x0],#8
>>>> hot    0xffff0000809e3f24 :    nop
>>>> loop   0xffff0000809e3f28 :    subs x1, x1, #0x8
>>>> -----  0xffff0000809e3f2c :    b.pl  0xffff0000809e3f20 <__arch_clear_user+1
>>>> The hot loop above takes one icache fetch as the code is in one
>>>> 32-bytes aligned area and the loop takes one more icache fetch
>>>> when it is not aligned like below.
>>>>          0xffff0000809e4178 :   str    xzr, [x0],#8
>>>>          0xffff0000809e417c :   nop
>>>>          0xffff0000809e4180 :   subs x1, x1, #0x8
>>>>          0xffff0000809e4184 :   b.pl  0xffff0000809e4178 <__arch_clear_user+
>>>> Data collected by perf:
>>>>                            aligned   not aligned
>>>>             instructions   57733790     57739065
>>>>          L1-dcache-store   14938070     13718242
>>>> L1-dcache-store-misses     349280       349869
>>>>          L1-icache-loads   15380895     28500665
>>>> As we can see, L1-icache-loads almost double when the loop is not
>>>> aligned.
>>>> This problem is found in linux 4.19 on HISI-HIP08 arm64 SOC.
>>>> Not sure what the case is on other arm64 SOC, but it should do
>>>> no harm.
>>>> Signed-off-by: Kai Shen <shenkai8 at huawei.com>
>>>
>>> Do you have a real world workload that's affected by this function?
>>>
>>> I'm against adding alignments and nops for specific hardware
>>> implementations. What about lots of other loops that the compiler may
>>> generate or that we wrote in asm?
>>
>> The benchmark we used which suffer performance decrease:
>>      https://github.com/redhat-performance/libMicro
>>      pread $OPTS -N "pread_z1k"    -s 1k    -I 300  -f /dev/zero
>>      pread $OPTS -N "pread_z10k"    -s 10k    -I 1000 -f /dev/zero
>>      pread $OPTS -N "pread_z100k"    -s 100k    -I 2000 -f /dev/zero
> 
> Is there any real world use-case that would benefit from this
> optimisation? Reading /dev/zero in a loop hardly counts as a practical
> workload.
> 
Operations like "dd if=/dev/zero of=/dev/sda1" ?


From yuzenghui at huawei.com  Sun Apr 25 06:29:31 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Sun, 25 Apr 2021 13:29:31 +0800
Subject: [PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel
 transitions
In-Reply-To: <20201130115950.22492-10-mark.rutland@arm.com>
References: <20201130115950.22492-1-mark.rutland@arm.com>
 <20201130115950.22492-10-mark.rutland@arm.com>
Message-ID: <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>

Hi Mark,

On 2020/11/30 19:59, Mark Rutland wrote:
> There are periods in kernel mode when RCU is not watching and/or the
> scheduler tick is disabled, but we can still take exceptions such as
> interrupts. The arm64 exception handlers do not account for this, and
> it's possible that RCU is not watching while an exception handler runs.
> 
> The x86/generic entry code handles this by ensuring that all (non-NMI)
> kernel exception handlers call irqentry_enter() and irqentry_exit(),
> which handle RCU, lockdep, and IRQ flag tracing. We can't yet move to
> the generic entry code, and already hadnle the user<->kernel transitions
> elsewhere, so we add new kernel<->kernel transition helpers alog the
> lines of the generic entry code.
> 
> Since we now track interrupts becoming masked when an exception is
> taken, local_daif_inherit() is modified to track interrupts becoming
> re-enabled when the original context is inherited. To balance the
> entry/exit paths, each handler masks all DAIF exceptions before
> exit_to_kernel_mode().
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Cc: Will Deacon <will at kernel.org>

[...]

> +/*
> + * This is intended to match the logic in irqentry_enter(), handling the kernel
> + * mode transitions only.
> + */
> +static void noinstr enter_from_kernel_mode(struct pt_regs *regs)
> +{
> +	regs->exit_rcu = false;
> +
> +	if (!IS_ENABLED(CONFIG_TINY_RCU) && is_idle_task(current)) {
> +		lockdep_hardirqs_off(CALLER_ADDR0);
> +		rcu_irq_enter();
> +		trace_hardirqs_off_finish();
> +
> +		regs->exit_rcu = true;
> +		return;
> +	}
> +
> +	lockdep_hardirqs_off(CALLER_ADDR0);
> +	rcu_irq_enter_check_tick();
> +	trace_hardirqs_off_finish();
> +}

Booting a lockdep-enabled kernel with "irqchip.gicv3_pseudo_nmi=1" would
result in splats as below:

| DEBUG_LOCKS_WARN_ON(!irqs_disabled())
| WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 
lockdep_hardirqs_off+0xd4/0xe8
| Modules linked in:
| CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+ 
#463
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
| pc : lockdep_hardirqs_off+0xd4/0xe8
| lr : lockdep_hardirqs_off+0xd4/0xe8
| sp : ffff80002a39bad0
| pmr_save: 000000e0
| x29: ffff80002a39bad0 x28: ffff0000de214bc0
| x27: ffff0000de1c0400 x26: 000000000049b328
| x25: 0000000000406f30 x24: ffff0000de1c00a0
| x23: 0000000020400005 x22: ffff8000105f747c
| x21: 0000000096000044 x20: 0000000000498ef9
| x19: ffff80002a39bc88 x18: ffffffffffffffff
| x17: 0000000000000000 x16: ffff800011c61eb0
| x15: ffff800011700a88 x14: 0720072007200720
| x13: 0720072007200720 x12: 0720072007200720
| x11: 0720072007200720 x10: 0720072007200720
| x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
| x7 : ffff8000119f0800 x6 : c0000000ffff7fff
| x5 : ffff8000119f07a8 x4 : 0000000000000001
| x3 : 9bcdab23f2432800 x2 : ffff800011730538
| x1 : 9bcdab23f2432800 x0 : 0000000000000000
| Call trace:
|  lockdep_hardirqs_off+0xd4/0xe8
|  enter_from_kernel_mode.isra.5+0x7c/0xa8
|  el1_abort+0x24/0x100
|  el1_sync_handler+0x80/0xd0
|  el1_sync+0x6c/0x100
|  __arch_clear_user+0xc/0x90
|  load_elf_binary+0x9fc/0x1450
|  bprm_execve+0x404/0x880
|  kernel_execve+0x180/0x188
|  call_usermodehelper_exec_async+0xdc/0x158
|  ret_from_fork+0x10/0x18

The code that triggers the splat is lockdep_hardirqs_off+0xd4/0xe8:

|	/*
|	 * So we're supposed to get called after you mask local IRQs, but for
|	 * some reason the hardware doesn't quite think you did a proper job.
|	 */
|	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
|		return;

which looks like a false positive as DAIF are all masked on taking
an synchronous exception and hardirqs are therefore disabled. With
pseudo NMI used, irqs_disabled() takes the value of ICC_PMR_EL1 as
the interrupt enable state, which is GIC_PRIO_IRQON (0xe0) in this
case and doesn't help much. Not dig further though.


Thanks,
Zenghui


From rppt at kernel.org  Sun Apr 25 07:59:20 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Sun, 25 Apr 2021 09:59:20 +0300
Subject: [PATCH v2 0/4] arm64: drop pfn_valid_within() and simplify
 pfn_valid()
In-Reply-To: <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
Message-ID: <YIUTSDnWe97vX1YP@kernel.org>

On Thu, Apr 22, 2021 at 11:28:24PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/22 15:29, Mike Rapoport wrote:
> > On Thu, Apr 22, 2021 at 03:00:20PM +0800, Kefeng Wang wrote:
> > > On 2021/4/21 14:51, Mike Rapoport wrote:
> > > > From: Mike Rapoport <rppt at linux.ibm.com>
> > > > 
> > > > Hi,
> > > > 
> > > > These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> > > > pfn_valid_within() to 1.
> > > > 
> > > > The idea is to mark NOMAP pages as reserved in the memory map and restore
> > > > the intended semantics of pfn_valid() to designate availability of struct
> > > > page for a pfn.
> > > > 
> > > > With this the core mm will be able to cope with the fact that it cannot use
> > > > NOMAP pages and the holes created by NOMAP ranges within MAX_ORDER blocks
> > > > will be treated correctly even without the need for pfn_valid_within.
> > > > 
> > > > The patches are only boot tested on qemu-system-aarch64 so I'd really
> > > > appreciate memory stress tests on real hardware.
> > > > 
> > > > If this actually works we'll be one step closer to drop custom pfn_valid()
> > > > on arm64 altogether.
> > > Hi Mike?I have a question, without HOLES_IN_ZONE, the pfn_valid_within() in
> > > move_freepages_block()->move_freepages()
> > > will be optimized, if there are holes in zone, the 'struce page'(memory map)
> > > for pfn range of hole will be free by
> > > free_memmap(), and then the page traverse in the zone(with holes) from
> > > move_freepages() will meet the wrong page?
> > > then it could panic at PageLRU(page) test, check link[1],
> > First, HOLES_IN_ZONE name us hugely misleading, this configuration option
> > has nothing to to with memory holes, but rather it is there to deal with
> > holes or undefined struct pages in the memory map, when these holes can be
> > inside a MAX_ORDER_NR_PAGES region.
> > 
> > In general pfn walkers use pfn_valid() and pfn_valid_within() to avoid
> > accessing *missing* struct pages, like those that are freed at
> > free_memmap(). But on arm64 these tests also filter out the nomap entries
> > because their struct pages are not initialized.
> > 
> > The panic you refer to happened because there was an uninitialized struct
> > page in the middle of MAX_ORDER_NR_PAGES region because it corresponded to
> > nomap memory.
> > 
> > With these changes I make sure that such pages will be properly initialized
> > as PageReserved and the pfn walkers will be able to rely on the memory map.
> > 
> > Note also, that free_memmap() aligns the parts being freed on MAX_ORDER
> > boundaries, so there will be no missing parts in the memory map within a
> > MAX_ORDER_NR_PAGES region.
> 
> Ok, thanks, we met a same panic like the link on arm32(without
> HOLES_IN_ZONE),
> 
> the scheme for arm64 could be suit for arm32, right?

In general yes. You just need to make sure that usage of pfn_valid() in
arch/arm does not presume that it tests something beyond availability of
struct page for a pfn.
 
>?I will try the patchset with some changes on arm32 and give some
> feedback.
> 
> Again, the stupid question, where will mark the region of memblock with
> MEMBLOCK_NOMAP flag ?
 
Not sure I understand the question. The memory regions with "nomap"
property in the device tree will be marked MEMBLOCK_NOMAP.
 
> > > "The idea is to mark NOMAP pages as reserved in the memory map", I see the
> > > patch2 check memblock_is_nomap() in memory region
> > > of memblock, but it seems that memblock_mark_nomap() is not called(maybe I
> > > missed), then memmap_init_reserved_pages() won't
> > > work, so should the HOLES_IN_ZONE still be needed for generic mm code?
> > > 
> > > [1] https://lore.kernel.org/linux-arm-kernel/541193a6-2bce-f042-5bb2-88913d5f1047 at arm.com/
> > > 

-- 
Sincerely yours,
Mike.


From masahiroy at kernel.org  Sun Apr 25 08:07:12 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Sun, 25 Apr 2021 16:07:12 +0900
Subject: [PATCH] kbuild: add a script to remove stale generated files
Message-ID: <20210425070712.1202472-1-masahiroy@kernel.org>

We maintain .gitignore and Makefiles so build artifacts are properly
ignored by Git, and cleaned up by 'make clean'. However, the code is
always changing; generated files are often moved to another directory,
or removed when they become unnecessary. Such garbage files tend to be
left over in the source tree because people usually git-pull without
cleaning the tree.

This is not only the noise for 'git status', but also a build issue
in some cases.

One solution is to remove a stale file like commit 223c24a7dba9 ("kbuild:
Automatically remove stale <linux/version.h> file") did. Such workaround
should be removed after a while, but we forget about that if we scatter
the workaround code in random places.

So, this commit adds a new script to collect cleanings of stale files.

As a start point, move the code in arch/arm/boot/compressed/Makefile
into this script.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

 Makefile                          |  6 +++++-
 arch/arm/boot/compressed/Makefile |  7 -------
 scripts/remove-stale-files        | 31 +++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+), 8 deletions(-)
 create mode 100755 scripts/remove-stale-files

diff --git a/Makefile b/Makefile
index b14483742a67..e970c8adf272 100644
--- a/Makefile
+++ b/Makefile
@@ -1202,7 +1202,7 @@ PHONY += prepare archprepare
 
 archprepare: outputmakefile archheaders archscripts scripts include/config/kernel.release \
 	asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
-	include/generated/autoconf.h
+	include/generated/autoconf.h remove-stale-files
 
 prepare0: archprepare
 	$(Q)$(MAKE) $(build)=scripts/mod
@@ -1211,6 +1211,10 @@ prepare0: archprepare
 # All the preparing..
 prepare: prepare0 prepare-objtool prepare-resolve_btfids
 
+PHONY += remove-stale-files
+remove-stale-files:
+	$(Q)$(srctree)/scripts/remove-stale-files
+
 # Support for using generic headers in asm-generic
 asm-generic := -f $(srctree)/scripts/Makefile.asm-generic obj
 
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index fd94e27ba4fa..182b300e3f8a 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -96,13 +96,6 @@ endif
 $(foreach o, $(libfdt_objs) atags_to_fdt.o fdt_check_mem_start.o, \
 	$(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt -fno-stack-protector))
 
-# These were previously generated C files. When you are building the kernel
-# with O=, make sure to remove the stale files in the output tree. Otherwise,
-# the build system wrongly compiles the stale ones.
-ifdef building_out_of_srctree
-$(shell rm -f $(addprefix $(obj)/, fdt_rw.c fdt_ro.c fdt_wip.c fdt.c))
-endif
-
 targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
 		 head.o $(OBJS)
diff --git a/scripts/remove-stale-files b/scripts/remove-stale-files
new file mode 100755
index 000000000000..c3eb81c3f7de
--- /dev/null
+++ b/scripts/remove-stale-files
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+set -e
+
+# When you move, remove or rename generated files, you probably also update
+# .gitignore and cleaning rules in the Makefile. This is the right thing
+# to do. However, people usually do 'git pull', 'git bisect', etc. without
+# running 'make clean'. Then, the stale generated files are left over, often
+# causing build issues.
+#
+# Also, 'git status' shows such stale build artifacts as untracked files.
+# What is worse, some people send a wrong patch to get them back to .gitignore
+# without checking the commit history.
+#
+# So, when you (re)move generated files, please move the cleaning rules from
+# the Makefile to this script. This is run before Kbuild starts building
+# anything, so people will not be annoyed by such garbage files.
+#
+# This script is not intended to grow endlessly. Rather, it is a temporary scrap
+# yard. Stale files stay in this file for a while (for some release cycles?),
+# then will be really dead and removed from the code base entirely.
+
+# These were previously generated source files. When you are building the kernel
+# with O=, make sure to remove the stale files in the output tree. Otherwise,
+# the build system wrongly compiles the stale ones.
+if [ -n "${building_out_of_srctree}" ]; then
+	for f in fdt_rw.c fdt_ro.c fdt_wip.c fdt.c
+	do
+		rm -f arch/arm/boot/compressed/${f}
+	done
+fi
-- 
2.27.0



From rppt at kernel.org  Sun Apr 25 08:19:55 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Sun, 25 Apr 2021 10:19:55 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
Message-ID: <YIUYG8N9T3/C/tSG@kernel.org>

On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> 
> I tested this patchset(plus arm32 change, like arm64 does) based on lts
> 5.10?add
> 
> some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
> panic,
> 
> any idea, thanks.
 
Are there any changes on top of 5.10 except for pfn_valid() patch?
Do you see this panic on 5.10 without the changes?
Can you see stack backtrace beyond move_freepages_block?

> Zone ranges:
> ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
> ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
> Movable zone start for each node
> Early memory node ranges
> ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
> ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
> ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
> ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
> ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
> ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
> ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
> ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
> ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
> ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
> 
> ----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
> ----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
> ----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
> ----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
> ----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
> ----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
> ----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
> === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
> :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
> 8<--- cut here ---
> Unable to handle kernel paging request at virtual address fffffffe
> pgd = 5dd50df5
> [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
> Internal error: Oops: 37 [#1] SMP ARM
> Modules linked in: gmac(O)
> CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
> Hardware name: Hisilicon A9
> PC is at move_freepages_block+0x150/0x278
> LR is at move_freepages_block+0x150/0x278
> pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
> sp : c4179cf8? ip : 00000000? fp : 00000001
> r10: c4179d58? r9 : 000de7ff? r8 : 00000000
> r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
> r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
> Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
> Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
> Process test-oom (pid: 635, stack limit = 0x25d667df)
> 

-- 
Sincerely yours,
Mike.


From cl at rock-chips.com  Sun Apr 25 10:16:50 2021
From: cl at rock-chips.com (=?UTF-8?B?6ZmI5Lqu?=)
Date: Sun, 25 Apr 2021 17:16:50 +0800
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <87zgxrpxo5.wl-maz@kernel.org>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com> <87zgxrpxo5.wl-maz@kernel.org>
Message-ID: <ec556a6c-e950-d152-c878-986e2616ddcd@rock-chips.com>

Hi Marc?

 ??? Thanks for reply.

 ??? See below.

? 2021/4/21 ??9:36, Marc Zyngier ??:
> On Wed, 21 Apr 2021 07:59:20 +0100,
> <cl at rock-chips.com> wrote:
>> From: Liang Chen <cl at rock-chips.com>
>>
>> RK3568 is a high-performance and low power quad-core application processor
>> designed for personal mobile internet device and AIoT equipments.
>>
>> This patch add basic core dtsi file for it.
>>
>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> ---
>>   .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 2789 +++++++++++++++++
>>   arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  795 +++++
>>   .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  346 ++
>>   3 files changed, 3930 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
>>
> [...]
>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> new file mode 100644
>> index 000000000000..ac8db2f54f2b
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> @@ -0,0 +1,795 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
>> + */
>> +
>> +#include <dt-bindings/clock/rk3568-cru.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/pinctrl/rockchip.h>
>> +#include <dt-bindings/soc/rockchip,boot-mode.h>
>> +#include <dt-bindings/phy/phy.h>
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>> +	compatible = "rockchip,rk3568";
>> +
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	aliases {
>> +		serial2 = &uart2;
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <2>;
>> +		#size-cells = <0>;
>> +
>> +		cpu0: cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a55";
>> +			reg = <0x0 0x0>;
>> +			enable-method = "psci";
>> +			clocks = <&scmi_clk 0>;
>> +			operating-points-v2 = <&cpu0_opp_table>;
>> +			#cooling-cells = <2>;
>> +		};
>> +		cpu1: cpu at 100 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a55";
>> +			reg = <0x0 0x100>;
>> +			enable-method = "psci";
>> +			operating-points-v2 = <&cpu0_opp_table>;
>> +		};
>> +		cpu2: cpu at 200 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a55";
>> +			reg = <0x0 0x200>;
>> +			enable-method = "psci";
>> +			operating-points-v2 = <&cpu0_opp_table>;
>> +		};
>> +		cpu3: cpu at 300 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a55";
>> +			reg = <0x0 0x300>;
>> +			enable-method = "psci";
>> +			operating-points-v2 = <&cpu0_opp_table>;
>> +		};
>> +	};
>> +
>> +	cpu0_opp_table: cpu0-opp-table {
>> +		compatible = "operating-points-v2";
>> +		opp-shared;
>> +
>> +		opp-408000000 {
>> +			opp-hz = /bits/ 64 <408000000>;
>> +			opp-microvolt = <825000 825000 1150000>;
>> +			clock-latency-ns = <40000>;
>> +		};
>> +		opp-600000000 {
>> +			opp-hz = /bits/ 64 <600000000>;
>> +			opp-microvolt = <825000 825000 1150000>;
>> +		};
>> +		opp-816000000 {
>> +			opp-hz = /bits/ 64 <816000000>;
>> +			opp-microvolt = <825000 825000 1150000>;
>> +			opp-suspend;
>> +		};
>> +		opp-1104000000 {
>> +			opp-hz = /bits/ 64 <1104000000>;
>> +			opp-microvolt = <825000 825000 1150000>;
>> +		};
>> +		opp-1416000000 {
>> +			opp-hz = /bits/ 64 <1416000000>;
>> +			opp-microvolt = <900000 900000 1150000>;
>> +		};
>> +		opp-1608000000 {
>> +			opp-hz = /bits/ 64 <1608000000>;
>> +			opp-microvolt = <975000 975000 1150000>;
>> +		};
>> +		opp-1800000000 {
>> +			opp-hz = /bits/ 64 <1800000000>;
>> +			opp-microvolt = <1050000 1050000 1150000>;
>> +		};
>> +		opp-1992000000 {
>> +			opp-hz = /bits/ 64 <1992000000>;
>> +			opp-microvolt = <1150000 1150000 1150000>;
>> +		};
>> +	};
>> +
>> +	arm-pmu {
>> +		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
>> +		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
>> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
>> +	};
>> +
>> +	firmware {
>> +		scmi: scmi {
>> +			compatible = "arm,scmi-smc";
>> +			shmem = <&scmi_shmem>;
>> +			arm,smc-id = <0x82000010>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			scmi_clk: protocol at 14 {
>> +				reg = <0x14>;
>> +				#clock-cells = <1>;
>> +			};
>> +		};
>> +
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci-1.0";
>> +		method = "smc";
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> This doesn't match the GICv3 binding for PPIs.
fixed in V2.
>
>> +		arm,no-tick-in-suspend;
> Oh, really? :-(
yes, arm arch timer will stop in suspend mode on rk3568.
>
>> +	};
>> +
>> +	xin24m: xin24m {
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <24000000>;
>> +		clock-output-names = "xin24m";
>> +	};
>> +
>> +	xin32k: xin32k {
>> +		compatible = "fixed-clock";
>> +		clock-frequency = <32768>;
>> +		clock-output-names = "xin32k";
>> +		#clock-cells = <0>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&clk32k_out0>;
>> +	};
>> +
>> +	scmi_shmem: scmi-shmem at 10f000 {
>> +		compatible = "arm,scmi-shmem";
>> +		reg = <0x0 0x0010f000 0x0 0x100>;
>> +	};
>> +
>> +	gic: interrupt-controller at fd400000 {
>> +		compatible = "arm,gic-v3";
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +		interrupt-controller;
>> +
>> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
>> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
>> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> Please add the 'mbi-alias' property, which should map onto the GICA
> range that GIC600 provides. At least this could be useful to have MSIs
> despite the lack of a working ITS. We can work out the usable ranges
> on a per-board basis.

Thanks, we will try mbi-alias later, but we are afraid that the number 
of SPI is not enough.


>
> Thanks,
>
> 	M.
>




From cl at rock-chips.com  Sun Apr 25 10:42:09 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:42:09 +0800
Subject: [PATCH v2 0/7] arm64: dts: rockchip: add basic dtsi/dts files for
 RK3568 SoC
Message-ID: <20210425094216.25724-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

v1:
1. add some dt-bindings for RK3568 devices.
2. add core dtsi for RK3568 SoC.
3. add basic dts for RK3568 EVB

v2:
1. sort device nodes by some rules.

Liang Chen (7):
  dt-bindings: i2c: i2c-rk3x: add description for rk3568
  dt-bindings: serial: snps-dw-apb-uart: add description for rk3568
  dt-bindings: mmc: rockchip-dw-mshc: add description for rk3568
  dt-bindings: watchdog: dw-wdt: add description for rk3568
  arm64: dts: rockchip: add generic pinconfig settings used by most
    Rockchip socs
  arm64: dts: rockchip: add core dtsi for RK3568 SoC
  arm64: dts: rockchip: add basic dts for RK3568 EVB

 .../devicetree/bindings/arm/rockchip.yaml     |    5 +
 .../devicetree/bindings/i2c/i2c-rk3x.yaml     |    1 +
 .../bindings/mmc/rockchip-dw-mshc.yaml        |    9 +-
 .../bindings/serial/snps-dw-apb-uart.yaml     |    1 +
 .../bindings/watchdog/snps,dw-wdt.yaml        |    1 +
 arch/arm64/boot/dts/rockchip/Makefile         |    1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     |   80 +
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  345 ++
 10 files changed, 4366 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:42:10 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:42:10 +0800
Subject: [PATCH v2 1/7] dt-bindings: i2c: i2c-rk3x: add description for rk3568
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094216.25724-2-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on
a rk3568 platform to i2c-rk3x.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
index 7f254d79558c..5339dd4fc370 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -36,6 +36,7 @@ properties:
               - rockchip,px30-i2c
               - rockchip,rk3308-i2c
               - rockchip,rk3328-i2c
+              - rockchip,rk3568-i2c
           - const: rockchip,rk3399-i2c
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:42:11 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:42:11 +0800
Subject: [PATCH v2 2/7] dt-bindings: serial: snps-dw-apb-uart: add description
 for rk3568
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094216.25724-3-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
a rk3568 platform to snps-dw-apb-uart.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 87ef1e218152..97debbf68748 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -31,6 +31,7 @@ properties:
               - rockchip,rk3328-uart
               - rockchip,rk3368-uart
               - rockchip,rk3399-uart
+              - rockchip,rk3568-uart
               - rockchip,rv1108-uart
           - const: snps,dw-apb-uart
       - items:
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:42:12 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:42:12 +0800
Subject: [PATCH v2 3/7] dt-bindings: mmc: rockchip-dw-mshc: add description
 for rk3568
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094216.25724-4-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci" for mmc nodes on
a rk3568 platform to rockchip-dw-mshc.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/mmc/rockchip-dw-mshc.yaml        | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index 3762f1c8de96..eaa3b0ef24f6 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -29,21 +29,14 @@ properties:
       - const: rockchip,rk3288-dw-mshc
       - items:
           - enum:
-            # for Rockchip PX30
               - rockchip,px30-dw-mshc
-            # for Rockchip RK3036
               - rockchip,rk3036-dw-mshc
-            # for Rockchip RK322x
               - rockchip,rk3228-dw-mshc
-            # for Rockchip RK3308
               - rockchip,rk3308-dw-mshc
-            # for Rockchip RK3328
               - rockchip,rk3328-dw-mshc
-            # for Rockchip RK3368
               - rockchip,rk3368-dw-mshc
-            # for Rockchip RK3399
               - rockchip,rk3399-dw-mshc
-            # for Rockchip RV1108
+              - rockchip,rk3568-dw-mshc
               - rockchip,rv1108-dw-mshc
           - const: rockchip,rk3288-dw-mshc
 
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:42:13 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:42:13 +0800
Subject: [PATCH v2 4/7] dt-bindings: watchdog: dw-wdt: add description for
 rk3568
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094216.25724-5-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-wdt", "snps,dw-wdt" for watchdog nodes on
a rk3568 platform to snps,dw-wdt.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index b58596b1831d..6461eb4f4a27 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -27,6 +27,7 @@ properties:
               - rockchip,rk3328-wdt
               - rockchip,rk3368-wdt
               - rockchip,rk3399-wdt
+              - rockchip,rk3568-wdt
               - rockchip,rv1108-wdt
           - const: snps,dw-wdt
 
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:44:21 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:44:21 +0800
Subject: [PATCH v2 5/7] arm64: dts: rockchip: add generic pinconfig settings
 used by most Rockchip socs
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094421.25838-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
so move them to a shared dtsi to be included, instead of redefining them
for each soc.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
new file mode 100644
index 000000000000..da67e72fbfec
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
@@ -0,0 +1,345 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+&pinctrl {
+	/omit-if-no-ref/
+	pcfg_pull_up: pcfg-pull-up {
+		bias-pull-up;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down: pcfg-pull-down {
+		bias-pull-down;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none: pcfg-pull-none {
+		bias-disable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0: pcfg-pull-none-drv-level-0 {
+		bias-disable;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_1: pcfg-pull-none-drv-level-1 {
+		bias-disable;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_2: pcfg-pull-none-drv-level-2 {
+		bias-disable;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_3: pcfg-pull-none-drv-level-3 {
+		bias-disable;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_4: pcfg-pull-none-drv-level-4 {
+		bias-disable;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_5: pcfg-pull-none-drv-level-5 {
+		bias-disable;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_6: pcfg-pull-none-drv-level-6 {
+		bias-disable;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_7: pcfg-pull-none-drv-level-7 {
+		bias-disable;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_8: pcfg-pull-none-drv-level-8 {
+		bias-disable;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_9: pcfg-pull-none-drv-level-9 {
+		bias-disable;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_10: pcfg-pull-none-drv-level-10 {
+		bias-disable;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_11: pcfg-pull-none-drv-level-11 {
+		bias-disable;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_12: pcfg-pull-none-drv-level-12 {
+		bias-disable;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_13: pcfg-pull-none-drv-level-13 {
+		bias-disable;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_14: pcfg-pull-none-drv-level-14 {
+		bias-disable;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_15: pcfg-pull-none-drv-level-15 {
+		bias-disable;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_0: pcfg-pull-up-drv-level-0 {
+		bias-pull-up;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_1: pcfg-pull-up-drv-level-1 {
+		bias-pull-up;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_2: pcfg-pull-up-drv-level-2 {
+		bias-pull-up;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_3: pcfg-pull-up-drv-level-3 {
+		bias-pull-up;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_4: pcfg-pull-up-drv-level-4 {
+		bias-pull-up;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_5: pcfg-pull-up-drv-level-5 {
+		bias-pull-up;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_6: pcfg-pull-up-drv-level-6 {
+		bias-pull-up;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_7: pcfg-pull-up-drv-level-7 {
+		bias-pull-up;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_8: pcfg-pull-up-drv-level-8 {
+		bias-pull-up;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_9: pcfg-pull-up-drv-level-9 {
+		bias-pull-up;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_10: pcfg-pull-up-drv-level-10 {
+		bias-pull-up;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_11: pcfg-pull-up-drv-level-11 {
+		bias-pull-up;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_12: pcfg-pull-up-drv-level-12 {
+		bias-pull-up;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_13: pcfg-pull-up-drv-level-13 {
+		bias-pull-up;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_14: pcfg-pull-up-drv-level-14 {
+		bias-pull-up;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_15: pcfg-pull-up-drv-level-15 {
+		bias-pull-up;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_0: pcfg-pull-down-drv-level-0 {
+		bias-pull-down;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_1: pcfg-pull-down-drv-level-1 {
+		bias-pull-down;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_2: pcfg-pull-down-drv-level-2 {
+		bias-pull-down;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_3: pcfg-pull-down-drv-level-3 {
+		bias-pull-down;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_4: pcfg-pull-down-drv-level-4 {
+		bias-pull-down;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_5: pcfg-pull-down-drv-level-5 {
+		bias-pull-down;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_6: pcfg-pull-down-drv-level-6 {
+		bias-pull-down;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_7: pcfg-pull-down-drv-level-7 {
+		bias-pull-down;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_8: pcfg-pull-down-drv-level-8 {
+		bias-pull-down;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_9: pcfg-pull-down-drv-level-9 {
+		bias-pull-down;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_10: pcfg-pull-down-drv-level-10 {
+		bias-pull-down;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_11: pcfg-pull-down-drv-level-11 {
+		bias-pull-down;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_12: pcfg-pull-down-drv-level-12 {
+		bias-pull-down;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_13: pcfg-pull-down-drv-level-13 {
+		bias-pull-down;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_14: pcfg-pull-down-drv-level-14 {
+		bias-pull-down;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_15: pcfg-pull-down-drv-level-15 {
+		bias-pull-down;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_smt: pcfg-pull-up-smt {
+		bias-pull-up;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_smt: pcfg-pull-down-smt {
+		bias-pull-down;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_smt: pcfg-pull-none-smt {
+		bias-disable;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0_smt: pcfg-pull-none-drv-level-0-smt {
+		bias-disable;
+		drive-strength = <0>;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_low: pcfg-output-low {
+		output-low;
+	};
+};
+
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:44:39 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:44:39 +0800
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094439.25895-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

RK3568 is a high-performance and low power quad-core application processor
designed for personal mobile internet device and AIoT equipments. This patch
add basic core dtsi file for it.

We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
enalbe a special high-performacne PLL when high frequency is required. The
smci_clk code is in ATF, and clkid for cpu is 0, as below:

    cpu0: cpu at 0 {
        device_type = "cpu";
        compatible = "arm,cortex-a55";
        reg = <0x0 0x0>;
        clocks = <&scmi_clk 0>;
    };

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
 2 files changed, 3931 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
new file mode 100644
index 000000000000..94ee3c2c38af
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
@@ -0,0 +1,3119 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+&pinctrl {
+	acodec {
+		/omit-if-no-ref/
+		acodec_pins: acodec-pins {
+			rockchip,pins =
+				/* acodec_adc_sync */
+				<1 RK_PB1 5 &pcfg_pull_none>,
+				/* acodec_adcclk */
+				<1 RK_PA1 5 &pcfg_pull_none>,
+				/* acodec_adcdata */
+				<1 RK_PA0 5 &pcfg_pull_none>,
+				/* acodec_dac_datal */
+				<1 RK_PA7 5 &pcfg_pull_none>,
+				/* acodec_dac_datar */
+				<1 RK_PB0 5 &pcfg_pull_none>,
+				/* acodec_dacclk */
+				<1 RK_PA3 5 &pcfg_pull_none>,
+				/* acodec_dacsync */
+				<1 RK_PA5 5 &pcfg_pull_none>;
+		};
+	};
+
+	audiopwm {
+		/omit-if-no-ref/
+		audiopwm_lout: audiopwm-lout {
+			rockchip,pins =
+				/* audiopwm_lout */
+				<1 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutn: audiopwm-loutn {
+			rockchip,pins =
+				/* audiopwm_loutn */
+				<1 RK_PA1 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutp: audiopwm-loutp {
+			rockchip,pins =
+				/* audiopwm_loutp */
+				<1 RK_PA0 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_rout: audiopwm-rout {
+			rockchip,pins =
+				/* audiopwm_rout */
+				<1 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routn: audiopwm-routn {
+			rockchip,pins =
+				/* audiopwm_routn */
+				<1 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routp: audiopwm-routp {
+			rockchip,pins =
+				/* audiopwm_routp */
+				<1 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	bt656 {
+		/omit-if-no-ref/
+		bt656m0_pins: bt656m0-pins {
+			rockchip,pins =
+				/* bt656_clkm0 */
+				<3 RK_PA0 2 &pcfg_pull_none>,
+				/* bt656_d0m0 */
+				<2 RK_PD0 2 &pcfg_pull_none>,
+				/* bt656_d1m0 */
+				<2 RK_PD1 2 &pcfg_pull_none>,
+				/* bt656_d2m0 */
+				<2 RK_PD2 2 &pcfg_pull_none>,
+				/* bt656_d3m0 */
+				<2 RK_PD3 2 &pcfg_pull_none>,
+				/* bt656_d4m0 */
+				<2 RK_PD4 2 &pcfg_pull_none>,
+				/* bt656_d5m0 */
+				<2 RK_PD5 2 &pcfg_pull_none>,
+				/* bt656_d6m0 */
+				<2 RK_PD6 2 &pcfg_pull_none>,
+				/* bt656_d7m0 */
+				<2 RK_PD7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		bt656m1_pins: bt656m1-pins {
+			rockchip,pins =
+				/* bt656_clkm1 */
+				<4 RK_PB4 5 &pcfg_pull_none>,
+				/* bt656_d0m1 */
+				<3 RK_PC6 5 &pcfg_pull_none>,
+				/* bt656_d1m1 */
+				<3 RK_PC7 5 &pcfg_pull_none>,
+				/* bt656_d2m1 */
+				<3 RK_PD0 5 &pcfg_pull_none>,
+				/* bt656_d3m1 */
+				<3 RK_PD1 5 &pcfg_pull_none>,
+				/* bt656_d4m1 */
+				<3 RK_PD2 5 &pcfg_pull_none>,
+				/* bt656_d5m1 */
+				<3 RK_PD3 5 &pcfg_pull_none>,
+				/* bt656_d6m1 */
+				<3 RK_PD4 5 &pcfg_pull_none>,
+				/* bt656_d7m1 */
+				<3 RK_PD5 5 &pcfg_pull_none>;
+		};
+	};
+
+	bt1120 {
+		/omit-if-no-ref/
+		bt1120_pins: bt1120-pins {
+			rockchip,pins =
+				/* bt1120_clk */
+				<3 RK_PA6 2 &pcfg_pull_none>,
+				/* bt1120_d0 */
+				<3 RK_PA1 2 &pcfg_pull_none>,
+				/* bt1120_d1 */
+				<3 RK_PA2 2 &pcfg_pull_none>,
+				/* bt1120_d2 */
+				<3 RK_PA3 2 &pcfg_pull_none>,
+				/* bt1120_d3 */
+				<3 RK_PA4 2 &pcfg_pull_none>,
+				/* bt1120_d4 */
+				<3 RK_PA5 2 &pcfg_pull_none>,
+				/* bt1120_d5 */
+				<3 RK_PA7 2 &pcfg_pull_none>,
+				/* bt1120_d6 */
+				<3 RK_PB0 2 &pcfg_pull_none>,
+				/* bt1120_d7 */
+				<3 RK_PB1 2 &pcfg_pull_none>,
+				/* bt1120_d8 */
+				<3 RK_PB2 2 &pcfg_pull_none>,
+				/* bt1120_d9 */
+				<3 RK_PB3 2 &pcfg_pull_none>,
+				/* bt1120_d10 */
+				<3 RK_PB4 2 &pcfg_pull_none>,
+				/* bt1120_d11 */
+				<3 RK_PB5 2 &pcfg_pull_none>,
+				/* bt1120_d12 */
+				<3 RK_PB6 2 &pcfg_pull_none>,
+				/* bt1120_d13 */
+				<3 RK_PC1 2 &pcfg_pull_none>,
+				/* bt1120_d14 */
+				<3 RK_PC2 2 &pcfg_pull_none>,
+				/* bt1120_d15 */
+				<3 RK_PC3 2 &pcfg_pull_none>;
+		};
+	};
+
+	cam {
+		/omit-if-no-ref/
+		cam_clkout0: cam-clkout0 {
+			rockchip,pins =
+				/* cam_clkout0 */
+				<4 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cam_clkout1: cam-clkout1 {
+			rockchip,pins =
+				/* cam_clkout1 */
+				<4 RK_PB0 1 &pcfg_pull_none>;
+		};
+	};
+
+	can0 {
+		/omit-if-no-ref/
+		can0m0_pins: can0m0-pins {
+			rockchip,pins =
+				/* can0_rxm0 */
+				<0 RK_PB4 2 &pcfg_pull_none>,
+				/* can0_txm0 */
+				<0 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can0m1_pins: can0m1-pins {
+			rockchip,pins =
+				/* can0_rxm1 */
+				<2 RK_PA2 4 &pcfg_pull_none>,
+				/* can0_txm1 */
+				<2 RK_PA1 4 &pcfg_pull_none>;
+		};
+	};
+
+	can1 {
+		/omit-if-no-ref/
+		can1m0_pins: can1m0-pins {
+			rockchip,pins =
+				/* can1_rxm0 */
+				<1 RK_PA0 3 &pcfg_pull_none>,
+				/* can1_txm0 */
+				<1 RK_PA1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can1m1_pins: can1m1-pins {
+			rockchip,pins =
+				/* can1_rxm1 */
+				<4 RK_PC2 3 &pcfg_pull_none>,
+				/* can1_txm1 */
+				<4 RK_PC3 3 &pcfg_pull_none>;
+		};
+	};
+
+	can2 {
+		/omit-if-no-ref/
+		can2m0_pins: can2m0-pins {
+			rockchip,pins =
+				/* can2_rxm0 */
+				<4 RK_PB4 3 &pcfg_pull_none>,
+				/* can2_txm0 */
+				<4 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can2m1_pins: can2m1-pins {
+			rockchip,pins =
+				/* can2_rxm1 */
+				<2 RK_PB1 4 &pcfg_pull_none>,
+				/* can2_txm1 */
+				<2 RK_PB2 4 &pcfg_pull_none>;
+		};
+	};
+
+	cif {
+		/omit-if-no-ref/
+		cif_clk: cif-clk {
+			rockchip,pins =
+				/* cif_clkout */
+				<4 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_clk: cif-dvp-clk {
+			rockchip,pins =
+				/* cif_clkin */
+				<4 RK_PC1 1 &pcfg_pull_none>,
+				/* cif_href */
+				<4 RK_PB6 1 &pcfg_pull_none>,
+				/* cif_vsync */
+				<4 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus16: cif-dvp-bus16 {
+			rockchip,pins =
+				/* cif_d8 */
+				<3 RK_PD6 1 &pcfg_pull_none>,
+				/* cif_d9 */
+				<3 RK_PD7 1 &pcfg_pull_none>,
+				/* cif_d10 */
+				<4 RK_PA0 1 &pcfg_pull_none>,
+				/* cif_d11 */
+				<4 RK_PA1 1 &pcfg_pull_none>,
+				/* cif_d12 */
+				<4 RK_PA2 1 &pcfg_pull_none>,
+				/* cif_d13 */
+				<4 RK_PA3 1 &pcfg_pull_none>,
+				/* cif_d14 */
+				<4 RK_PA4 1 &pcfg_pull_none>,
+				/* cif_d15 */
+				<4 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus8: cif-dvp-bus8 {
+			rockchip,pins =
+				/* cif_d0 */
+				<3 RK_PC6 1 &pcfg_pull_none>,
+				/* cif_d1 */
+				<3 RK_PC7 1 &pcfg_pull_none>,
+				/* cif_d2 */
+				<3 RK_PD0 1 &pcfg_pull_none>,
+				/* cif_d3 */
+				<3 RK_PD1 1 &pcfg_pull_none>,
+				/* cif_d4 */
+				<3 RK_PD2 1 &pcfg_pull_none>,
+				/* cif_d5 */
+				<3 RK_PD3 1 &pcfg_pull_none>,
+				/* cif_d6 */
+				<3 RK_PD4 1 &pcfg_pull_none>,
+				/* cif_d7 */
+				<3 RK_PD5 1 &pcfg_pull_none>;
+		};
+	};
+
+	clk32k {
+		/omit-if-no-ref/
+		clk32k_in: clk32k-in {
+			rockchip,pins =
+				/* clk32k_in */
+				<0 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out0: clk32k-out0 {
+			rockchip,pins =
+				/* clk32k_out0 */
+				<0 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out1: clk32k-out1 {
+			rockchip,pins =
+				/* clk32k_out1 */
+				<2 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	cpu {
+		/omit-if-no-ref/
+		cpu_pins: cpu-pins {
+			rockchip,pins =
+				/* cpu_avs */
+				<0 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	ebc {
+		/omit-if-no-ref/
+		ebc_extern: ebc-extern {
+			rockchip,pins =
+				/* ebc_sdce1 */
+				<4 RK_PA7 2 &pcfg_pull_none>,
+				/* ebc_sdce2 */
+				<4 RK_PB0 2 &pcfg_pull_none>,
+				/* ebc_sdce3 */
+				<4 RK_PB1 2 &pcfg_pull_none>,
+				/* ebc_sdshr */
+				<4 RK_PB5 2 &pcfg_pull_none>,
+				/* ebc_vcom */
+				<4 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		ebc_pins: ebc-pins {
+			rockchip,pins =
+				/* ebc_gdclk */
+				<4 RK_PC0 2 &pcfg_pull_none>,
+				/* ebc_gdoe */
+				<4 RK_PB3 2 &pcfg_pull_none>,
+				/* ebc_gdsp */
+				<4 RK_PB4 2 &pcfg_pull_none>,
+				/* ebc_sdce0 */
+				<4 RK_PA6 2 &pcfg_pull_none>,
+				/* ebc_sdclk */
+				<4 RK_PC1 2 &pcfg_pull_none>,
+				/* ebc_sddo0 */
+				<3 RK_PC6 2 &pcfg_pull_none>,
+				/* ebc_sddo1 */
+				<3 RK_PC7 2 &pcfg_pull_none>,
+				/* ebc_sddo2 */
+				<3 RK_PD0 2 &pcfg_pull_none>,
+				/* ebc_sddo3 */
+				<3 RK_PD1 2 &pcfg_pull_none>,
+				/* ebc_sddo4 */
+				<3 RK_PD2 2 &pcfg_pull_none>,
+				/* ebc_sddo5 */
+				<3 RK_PD3 2 &pcfg_pull_none>,
+				/* ebc_sddo6 */
+				<3 RK_PD4 2 &pcfg_pull_none>,
+				/* ebc_sddo7 */
+				<3 RK_PD5 2 &pcfg_pull_none>,
+				/* ebc_sddo8 */
+				<3 RK_PD6 2 &pcfg_pull_none>,
+				/* ebc_sddo9 */
+				<3 RK_PD7 2 &pcfg_pull_none>,
+				/* ebc_sddo10 */
+				<4 RK_PA0 2 &pcfg_pull_none>,
+				/* ebc_sddo11 */
+				<4 RK_PA1 2 &pcfg_pull_none>,
+				/* ebc_sddo12 */
+				<4 RK_PA2 2 &pcfg_pull_none>,
+				/* ebc_sddo13 */
+				<4 RK_PA3 2 &pcfg_pull_none>,
+				/* ebc_sddo14 */
+				<4 RK_PA4 2 &pcfg_pull_none>,
+				/* ebc_sddo15 */
+				<4 RK_PA5 2 &pcfg_pull_none>,
+				/* ebc_sdle */
+				<4 RK_PB6 2 &pcfg_pull_none>,
+				/* ebc_sdoe */
+				<4 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	edpdp {
+		/omit-if-no-ref/
+		edpdpm0_pins: edpdpm0-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm0 */
+				<4 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		edpdpm1_pins: edpdpm1-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm1 */
+				<0 RK_PC2 2 &pcfg_pull_none>;
+		};
+	};
+
+	emmc {
+		/omit-if-no-ref/
+		emmc_rstnout: emmc-rstnout {
+			rockchip,pins =
+				/* emmc_rstn */
+				<1 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		emmc_bus8: emmc-bus8 {
+			rockchip,pins =
+				/* emmc_d0 */
+				<1 RK_PB4 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d1 */
+				<1 RK_PB5 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d2 */
+				<1 RK_PB6 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d3 */
+				<1 RK_PB7 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d4 */
+				<1 RK_PC0 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d5 */
+				<1 RK_PC1 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d6 */
+				<1 RK_PC2 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d7 */
+				<1 RK_PC3 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_clk: emmc-clk {
+			rockchip,pins =
+				/* emmc_clkout */
+				<1 RK_PC5 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_cmd: emmc-cmd {
+			rockchip,pins =
+				/* emmc_cmd */
+				<1 RK_PC4 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_datastrobe: emmc-datastrobe {
+			rockchip,pins =
+				/* emmc_datastrobe */
+				<1 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	eth0 {
+		/omit-if-no-ref/
+		eth0_pins: eth0-pins {
+			rockchip,pins =
+				/* eth0_refclko25m */
+				<2 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	eth1 {
+		/omit-if-no-ref/
+		eth1m0_pins: eth1m0-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm0 */
+				<3 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		eth1m1_pins: eth1m1-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm1 */
+				<4 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	flash {
+		/omit-if-no-ref/
+		flash_pins: flash-pins {
+			rockchip,pins =
+				/* flash_ale */
+				<1 RK_PD0 2 &pcfg_pull_none>,
+				/* flash_cle */
+				<1 RK_PC6 3 &pcfg_pull_none>,
+				/* flash_cs0n */
+				<1 RK_PD3 2 &pcfg_pull_none>,
+				/* flash_cs1n */
+				<1 RK_PD4 2 &pcfg_pull_none>,
+				/* flash_d0 */
+				<1 RK_PB4 2 &pcfg_pull_none>,
+				/* flash_d1 */
+				<1 RK_PB5 2 &pcfg_pull_none>,
+				/* flash_d2 */
+				<1 RK_PB6 2 &pcfg_pull_none>,
+				/* flash_d3 */
+				<1 RK_PB7 2 &pcfg_pull_none>,
+				/* flash_d4 */
+				<1 RK_PC0 2 &pcfg_pull_none>,
+				/* flash_d5 */
+				<1 RK_PC1 2 &pcfg_pull_none>,
+				/* flash_d6 */
+				<1 RK_PC2 2 &pcfg_pull_none>,
+				/* flash_d7 */
+				<1 RK_PC3 2 &pcfg_pull_none>,
+				/* flash_dqs */
+				<1 RK_PC5 2 &pcfg_pull_none>,
+				/* flash_rdn */
+				<1 RK_PD2 2 &pcfg_pull_none>,
+				/* flash_rdy */
+				<1 RK_PD1 2 &pcfg_pull_none>,
+				/* flash_volsel */
+				<0 RK_PA7 1 &pcfg_pull_none>,
+				/* flash_wpn */
+				<1 RK_PC7 3 &pcfg_pull_none>,
+				/* flash_wrn */
+				<1 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	fspi {
+		/omit-if-no-ref/
+		fspi_pins: fspi-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>,
+				/* fspi_d2 */
+				<1 RK_PC7 2 &pcfg_pull_none>,
+				/* fspi_d3 */
+				<1 RK_PD4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		fspi_cs1: fspi-cs1 {
+			rockchip,pins =
+				/* fspi_cs1n */
+				<1 RK_PC6 2 &pcfg_pull_up>;
+		};
+	};
+
+	gmac0 {
+		/omit-if-no-ref/
+		gmac0_miim: gmac0-miim {
+			rockchip,pins =
+				/* gmac0_mdc */
+				<2 RK_PC3 2 &pcfg_pull_none>,
+				/* gmac0_mdio */
+				<2 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_clkinout: gmac0-clkinout {
+			rockchip,pins =
+				/* gmac0_mclkinout */
+				<2 RK_PC2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_er: gmac0-rx-er {
+			rockchip,pins =
+				/* gmac0_rxer */
+				<2 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_bus2: gmac0-rx-bus2 {
+			rockchip,pins =
+				/* gmac0_rxd0 */
+				<2 RK_PB6 1 &pcfg_pull_none>,
+				/* gmac0_rxd1 */
+				<2 RK_PB7 2 &pcfg_pull_none>,
+				/* gmac0_rxdvcrs */
+				<2 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_tx_bus2: gmac0-tx-bus2 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_clk: gmac0-rgmii-clk {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus: gmac0-rgmii-bus {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gmac1 {
+		/omit-if-no-ref/
+		gmac1m0_miim: gmac1m0-miim {
+			rockchip,pins =
+				/* gmac1_mdcm0 */
+				<3 RK_PC4 3 &pcfg_pull_none>,
+				/* gmac1_mdiom0 */
+				<3 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_clkinout: gmac1m0-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm0 */
+				<3 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_er: gmac1m0-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm0 */
+				<3 RK_PB4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_bus2: gmac1m0-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m0 */
+				<3 RK_PB1 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m0 */
+				<3 RK_PB2 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm0 */
+				<3 RK_PB3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2: gmac1m0-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk: gmac1m0-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus: gmac1m0-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_miim: gmac1m1-miim {
+			rockchip,pins =
+				/* gmac1_mdcm1 */
+				<4 RK_PB6 3 &pcfg_pull_none>,
+				/* gmac1_mdiom1 */
+				<4 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_clkinout: gmac1m1-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm1 */
+				<4 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_er: gmac1m1-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm1 */
+				<4 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_bus2: gmac1m1-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m1 */
+				<4 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m1 */
+				<4 RK_PB0 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm1 */
+				<4 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2: gmac1m1-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk: gmac1m1-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus: gmac1m1-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gpu {
+		/omit-if-no-ref/
+		gpu_pins: gpu-pins {
+			rockchip,pins =
+				/* gpu_avs */
+				<0 RK_PC0 2 &pcfg_pull_none>,
+				/* gpu_pwren */
+				<0 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	hdmitx {
+		/omit-if-no-ref/
+		hdmitxm0_cec: hdmitxm0-cec {
+			rockchip,pins =
+				/* hdmitxm0_cec */
+				<4 RK_PD1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitxm1_cec: hdmitxm1-cec {
+			rockchip,pins =
+				/* hdmitxm1_cec */
+				<0 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_scl: hdmitx-scl {
+			rockchip,pins =
+				/* hdmitx_scl */
+				<4 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_sda: hdmitx-sda {
+			rockchip,pins =
+				/* hdmitx_sda */
+				<4 RK_PD0 1 &pcfg_pull_none>;
+		};
+	};
+
+	i2c0 {
+		/omit-if-no-ref/
+		i2c0_xfer: i2c0-xfer {
+			rockchip,pins =
+				/* i2c0_scl */
+				<0 RK_PB1 1 &pcfg_pull_none_smt>,
+				/* i2c0_sda */
+				<0 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c1 {
+		/omit-if-no-ref/
+		i2c1_xfer: i2c1-xfer {
+			rockchip,pins =
+				/* i2c1_scl */
+				<0 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c1_sda */
+				<0 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c2 {
+		/omit-if-no-ref/
+		i2c2m0_xfer: i2c2m0-xfer {
+			rockchip,pins =
+				/* i2c2_sclm0 */
+				<0 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam0 */
+				<0 RK_PB6 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c2m1_xfer: i2c2m1-xfer {
+			rockchip,pins =
+				/* i2c2_sclm1 */
+				<4 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam1 */
+				<4 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c3 {
+		/omit-if-no-ref/
+		i2c3m0_xfer: i2c3m0-xfer {
+			rockchip,pins =
+				/* i2c3_sclm0 */
+				<1 RK_PA1 1 &pcfg_pull_none_smt>,
+				/* i2c3_sdam0 */
+				<1 RK_PA0 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c3m1_xfer: i2c3m1-xfer {
+			rockchip,pins =
+				/* i2c3_sclm1 */
+				<3 RK_PB5 4 &pcfg_pull_none_smt>,
+				/* i2c3_sdam1 */
+				<3 RK_PB6 4 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c4 {
+		/omit-if-no-ref/
+		i2c4m0_xfer: i2c4m0-xfer {
+			rockchip,pins =
+				/* i2c4_sclm0 */
+				<4 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c4_sdam0 */
+				<4 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c4m1_xfer: i2c4m1-xfer {
+			rockchip,pins =
+				/* i2c4_sclm1 */
+				<2 RK_PB2 2 &pcfg_pull_none_smt>,
+				/* i2c4_sdam1 */
+				<2 RK_PB1 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c5 {
+		/omit-if-no-ref/
+		i2c5m0_xfer: i2c5m0-xfer {
+			rockchip,pins =
+				/* i2c5_sclm0 */
+				<3 RK_PB3 4 &pcfg_pull_none_smt>,
+				/* i2c5_sdam0 */
+				<3 RK_PB4 4 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c5m1_xfer: i2c5m1-xfer {
+			rockchip,pins =
+				/* i2c5_sclm1 */
+				<4 RK_PC7 2 &pcfg_pull_none_smt>,
+				/* i2c5_sdam1 */
+				<4 RK_PD0 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2s1 {
+		/omit-if-no-ref/
+		i2s1m0_lrckrx: i2s1m0-lrckrx {
+			rockchip,pins =
+				/* i2s1m0_lrckrx */
+				<1 RK_PA6 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_lrcktx: i2s1m0-lrcktx {
+			rockchip,pins =
+				/* i2s1m0_lrcktx */
+				<1 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_mclk: i2s1m0-mclk {
+			rockchip,pins =
+				/* i2s1m0_mclk */
+				<1 RK_PA2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclkrx: i2s1m0-sclkrx {
+			rockchip,pins =
+				/* i2s1m0_sclkrx */
+				<1 RK_PA4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclktx: i2s1m0-sclktx {
+			rockchip,pins =
+				/* i2s1m0_sclktx */
+				<1 RK_PA3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi0: i2s1m0-sdi0 {
+			rockchip,pins =
+				/* i2s1m0_sdi0 */
+				<1 RK_PB3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi1: i2s1m0-sdi1 {
+			rockchip,pins =
+				/* i2s1m0_sdi1 */
+				<1 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi2: i2s1m0-sdi2 {
+			rockchip,pins =
+				/* i2s1m0_sdi2 */
+				<1 RK_PB1 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi3: i2s1m0-sdi3 {
+			rockchip,pins =
+				/* i2s1m0_sdi3 */
+				<1 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo0: i2s1m0-sdo0 {
+			rockchip,pins =
+				/* i2s1m0_sdo0 */
+				<1 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo1: i2s1m0-sdo1 {
+			rockchip,pins =
+				/* i2s1m0_sdo1 */
+				<1 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo2: i2s1m0-sdo2 {
+			rockchip,pins =
+				/* i2s1m0_sdo2 */
+				<1 RK_PB1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo3: i2s1m0-sdo3 {
+			rockchip,pins =
+				/* i2s1m0_sdo3 */
+				<1 RK_PB2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrckrx: i2s1m1-lrckrx {
+			rockchip,pins =
+				/* i2s1m1_lrckrx */
+				<4 RK_PA7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrcktx: i2s1m1-lrcktx {
+			rockchip,pins =
+				/* i2s1m1_lrcktx */
+				<3 RK_PD0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_mclk: i2s1m1-mclk {
+			rockchip,pins =
+				/* i2s1m1_mclk */
+				<3 RK_PC6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclkrx: i2s1m1-sclkrx {
+			rockchip,pins =
+				/* i2s1m1_sclkrx */
+				<4 RK_PA6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclktx: i2s1m1-sclktx {
+			rockchip,pins =
+				/* i2s1m1_sclktx */
+				<3 RK_PC7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi0: i2s1m1-sdi0 {
+			rockchip,pins =
+				/* i2s1m1_sdi0 */
+				<3 RK_PD2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi1: i2s1m1-sdi1 {
+			rockchip,pins =
+				/* i2s1m1_sdi1 */
+				<3 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi2: i2s1m1-sdi2 {
+			rockchip,pins =
+				/* i2s1m1_sdi2 */
+				<3 RK_PD4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi3: i2s1m1-sdi3 {
+			rockchip,pins =
+				/* i2s1m1_sdi3 */
+				<3 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo0: i2s1m1-sdo0 {
+			rockchip,pins =
+				/* i2s1m1_sdo0 */
+				<3 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo1: i2s1m1-sdo1 {
+			rockchip,pins =
+				/* i2s1m1_sdo1 */
+				<4 RK_PB0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo2: i2s1m1-sdo2 {
+			rockchip,pins =
+				/* i2s1m1_sdo2 */
+				<4 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo3: i2s1m1-sdo3 {
+			rockchip,pins =
+				/* i2s1m1_sdo3 */
+				<4 RK_PB5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrckrx: i2s1m2-lrckrx {
+			rockchip,pins =
+				/* i2s1m2_lrckrx */
+				<3 RK_PC5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrcktx: i2s1m2-lrcktx {
+			rockchip,pins =
+				/* i2s1m2_lrcktx */
+				<2 RK_PD2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_mclk: i2s1m2-mclk {
+			rockchip,pins =
+				/* i2s1m2_mclk */
+				<2 RK_PD0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclkrx: i2s1m2-sclkrx {
+			rockchip,pins =
+				/* i2s1m2_sclkrx */
+				<3 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclktx: i2s1m2-sclktx {
+			rockchip,pins =
+				/* i2s1m2_sclktx */
+				<2 RK_PD1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi0: i2s1m2-sdi0 {
+			rockchip,pins =
+				/* i2s1m2_sdi0 */
+				<2 RK_PD3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi1: i2s1m2-sdi1 {
+			rockchip,pins =
+				/* i2s1m2_sdi1 */
+				<2 RK_PD4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi2: i2s1m2-sdi2 {
+			rockchip,pins =
+				/* i2s1m2_sdi2 */
+				<2 RK_PD5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi3: i2s1m2-sdi3 {
+			rockchip,pins =
+				/* i2s1m2_sdi3 */
+				<2 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo0: i2s1m2-sdo0 {
+			rockchip,pins =
+				/* i2s1m2_sdo0 */
+				<2 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo1: i2s1m2-sdo1 {
+			rockchip,pins =
+				/* i2s1m2_sdo1 */
+				<3 RK_PA0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo2: i2s1m2-sdo2 {
+			rockchip,pins =
+				/* i2s1m2_sdo2 */
+				<3 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo3: i2s1m2-sdo3 {
+			rockchip,pins =
+				/* i2s1m2_sdo3 */
+				<3 RK_PC2 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s2 {
+		/omit-if-no-ref/
+		i2s2m0_lrckrx: i2s2m0-lrckrx {
+			rockchip,pins =
+				/* i2s2m0_lrckrx */
+				<2 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_lrcktx: i2s2m0-lrcktx {
+			rockchip,pins =
+				/* i2s2m0_lrcktx */
+				<2 RK_PC3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_mclk: i2s2m0-mclk {
+			rockchip,pins =
+				/* i2s2m0_mclk */
+				<2 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclkrx: i2s2m0-sclkrx {
+			rockchip,pins =
+				/* i2s2m0_sclkrx */
+				<2 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclktx: i2s2m0-sclktx {
+			rockchip,pins =
+				/* i2s2m0_sclktx */
+				<2 RK_PC2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdi: i2s2m0-sdi {
+			rockchip,pins =
+				/* i2s2m0_sdi */
+				<2 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdo: i2s2m0-sdo {
+			rockchip,pins =
+				/* i2s2m0_sdo */
+				<2 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrckrx: i2s2m1-lrckrx {
+			rockchip,pins =
+				/* i2s2m1_lrckrx */
+				<4 RK_PA5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrcktx: i2s2m1-lrcktx {
+			rockchip,pins =
+				/* i2s2m1_lrcktx */
+				<4 RK_PA4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_mclk: i2s2m1-mclk {
+			rockchip,pins =
+				/* i2s2m1_mclk */
+				<4 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclkrx: i2s2m1-sclkrx {
+			rockchip,pins =
+				/* i2s2m1_sclkrx */
+				<4 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclktx: i2s2m1-sclktx {
+			rockchip,pins =
+				/* i2s2m1_sclktx */
+				<4 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdi: i2s2m1-sdi {
+			rockchip,pins =
+				/* i2s2m1_sdi */
+				<4 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdo: i2s2m1-sdo {
+			rockchip,pins =
+				/* i2s2m1_sdo */
+				<4 RK_PB3 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s3 {
+		/omit-if-no-ref/
+		i2s3m0_lrck: i2s3m0-lrck {
+			rockchip,pins =
+				/* i2s3m0_lrck */
+				<3 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_mclk: i2s3m0-mclk {
+			rockchip,pins =
+				/* i2s3m0_mclk */
+				<3 RK_PA2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sclk: i2s3m0-sclk {
+			rockchip,pins =
+				/* i2s3m0_sclk */
+				<3 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdi: i2s3m0-sdi {
+			rockchip,pins =
+				/* i2s3m0_sdi */
+				<3 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdo: i2s3m0-sdo {
+			rockchip,pins =
+				/* i2s3m0_sdo */
+				<3 RK_PA5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_lrck: i2s3m1-lrck {
+			rockchip,pins =
+				/* i2s3m1_lrck */
+				<4 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_mclk: i2s3m1-mclk {
+			rockchip,pins =
+				/* i2s3m1_mclk */
+				<4 RK_PC2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sclk: i2s3m1-sclk {
+			rockchip,pins =
+				/* i2s3m1_sclk */
+				<4 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdi: i2s3m1-sdi {
+			rockchip,pins =
+				/* i2s3m1_sdi */
+				<4 RK_PC6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdo: i2s3m1-sdo {
+			rockchip,pins =
+				/* i2s3m1_sdo */
+				<4 RK_PC5 5 &pcfg_pull_none>;
+		};
+	};
+
+	isp {
+		/omit-if-no-ref/
+		isp_pins: isp-pins {
+			rockchip,pins =
+				/* isp_flashtrigin */
+				<4 RK_PB4 4 &pcfg_pull_none>,
+				/* isp_flashtrigout */
+				<4 RK_PA6 1 &pcfg_pull_none>,
+				/* isp_prelighttrig */
+				<4 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	jtag {
+		/omit-if-no-ref/
+		jtag_pins: jtag-pins {
+			rockchip,pins =
+				/* jtag_tck */
+				<1 RK_PD7 2 &pcfg_pull_none>,
+				/* jtag_tms */
+				<2 RK_PA0 2 &pcfg_pull_none>;
+		};
+	};
+
+	lcdc {
+		/omit-if-no-ref/
+		lcdc_ctl: lcdc-ctl {
+			rockchip,pins =
+				/* lcdc_clk */
+				<3 RK_PA0 1 &pcfg_pull_none>,
+				/* lcdc_d0 */
+				<2 RK_PD0 1 &pcfg_pull_none>,
+				/* lcdc_d1 */
+				<2 RK_PD1 1 &pcfg_pull_none>,
+				/* lcdc_d2 */
+				<2 RK_PD2 1 &pcfg_pull_none>,
+				/* lcdc_d3 */
+				<2 RK_PD3 1 &pcfg_pull_none>,
+				/* lcdc_d4 */
+				<2 RK_PD4 1 &pcfg_pull_none>,
+				/* lcdc_d5 */
+				<2 RK_PD5 1 &pcfg_pull_none>,
+				/* lcdc_d6 */
+				<2 RK_PD6 1 &pcfg_pull_none>,
+				/* lcdc_d7 */
+				<2 RK_PD7 1 &pcfg_pull_none>,
+				/* lcdc_d8 */
+				<3 RK_PA1 1 &pcfg_pull_none>,
+				/* lcdc_d9 */
+				<3 RK_PA2 1 &pcfg_pull_none>,
+				/* lcdc_d10 */
+				<3 RK_PA3 1 &pcfg_pull_none>,
+				/* lcdc_d11 */
+				<3 RK_PA4 1 &pcfg_pull_none>,
+				/* lcdc_d12 */
+				<3 RK_PA5 1 &pcfg_pull_none>,
+				/* lcdc_d13 */
+				<3 RK_PA6 1 &pcfg_pull_none>,
+				/* lcdc_d14 */
+				<3 RK_PA7 1 &pcfg_pull_none>,
+				/* lcdc_d15 */
+				<3 RK_PB0 1 &pcfg_pull_none>,
+				/* lcdc_d16 */
+				<3 RK_PB1 1 &pcfg_pull_none>,
+				/* lcdc_d17 */
+				<3 RK_PB2 1 &pcfg_pull_none>,
+				/* lcdc_d18 */
+				<3 RK_PB3 1 &pcfg_pull_none>,
+				/* lcdc_d19 */
+				<3 RK_PB4 1 &pcfg_pull_none>,
+				/* lcdc_d20 */
+				<3 RK_PB5 1 &pcfg_pull_none>,
+				/* lcdc_d21 */
+				<3 RK_PB6 1 &pcfg_pull_none>,
+				/* lcdc_d22 */
+				<3 RK_PB7 1 &pcfg_pull_none>,
+				/* lcdc_d23 */
+				<3 RK_PC0 1 &pcfg_pull_none>,
+				/* lcdc_den */
+				<3 RK_PC3 1 &pcfg_pull_none>,
+				/* lcdc_hsync */
+				<3 RK_PC1 1 &pcfg_pull_none>,
+				/* lcdc_vsync */
+				<3 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	mcu {
+		/omit-if-no-ref/
+		mcu_pins: mcu-pins {
+			rockchip,pins =
+				/* mcu_jtagtck */
+				<0 RK_PB4 4 &pcfg_pull_none>,
+				/* mcu_jtagtdi */
+				<0 RK_PC1 4 &pcfg_pull_none>,
+				/* mcu_jtagtdo */
+				<0 RK_PB3 4 &pcfg_pull_none>,
+				/* mcu_jtagtms */
+				<0 RK_PC2 4 &pcfg_pull_none>,
+				/* mcu_jtagtrstn */
+				<0 RK_PC3 4 &pcfg_pull_none>;
+		};
+	};
+
+	npu {
+		/omit-if-no-ref/
+		npu_pins: npu-pins {
+			rockchip,pins =
+				/* npu_avs */
+				<0 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pcie20 {
+		/omit-if-no-ref/
+		pcie20m0_pins: pcie20m0-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm0 */
+				<0 RK_PA5 3 &pcfg_pull_none>,
+				/* pcie20_perstnm0 */
+				<0 RK_PB6 3 &pcfg_pull_none>,
+				/* pcie20_wakenm0 */
+				<0 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m1_pins: pcie20m1-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm1 */
+				<2 RK_PD0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm1 */
+				<3 RK_PC1 4 &pcfg_pull_none>,
+				/* pcie20_wakenm1 */
+				<2 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m2_pins: pcie20m2-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm2 */
+				<1 RK_PB0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm2 */
+				<1 RK_PB2 4 &pcfg_pull_none>,
+				/* pcie20_wakenm2 */
+				<1 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20_buttonrstn: pcie20-buttonrstn {
+			rockchip,pins =
+				/* pcie20_buttonrstn */
+				<0 RK_PB4 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x1 {
+		/omit-if-no-ref/
+		pcie30x1m0_pins: pcie30x1m0-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm0 */
+				<0 RK_PA4 3 &pcfg_pull_none>,
+				/* pcie30x1_perstnm0 */
+				<0 RK_PC3 3 &pcfg_pull_none>,
+				/* pcie30x1_wakenm0 */
+				<0 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m1_pins: pcie30x1m1-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm1 */
+				<2 RK_PD2 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm1 */
+				<3 RK_PA1 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm1 */
+				<2 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m2_pins: pcie30x1m2-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm2 */
+				<1 RK_PA5 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm2 */
+				<1 RK_PA2 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm2 */
+				<1 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1_buttonrstn: pcie30x1-buttonrstn {
+			rockchip,pins =
+				/* pcie30x1_buttonrstn */
+				<0 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x2 {
+		/omit-if-no-ref/
+		pcie30x2m0_pins: pcie30x2m0-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm0 */
+				<0 RK_PA6 2 &pcfg_pull_none>,
+				/* pcie30x2_perstnm0 */
+				<0 RK_PC6 3 &pcfg_pull_none>,
+				/* pcie30x2_wakenm0 */
+				<0 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m1_pins: pcie30x2m1-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm1 */
+				<2 RK_PD4 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm1 */
+				<2 RK_PD6 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm1 */
+				<2 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m2_pins: pcie30x2m2-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm2 */
+				<4 RK_PC2 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm2 */
+				<4 RK_PC4 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm2 */
+				<4 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2_buttonrstn: pcie30x2-buttonrstn {
+			rockchip,pins =
+				/* pcie30x2_buttonrstn */
+				<0 RK_PB0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pdm {
+		/omit-if-no-ref/
+		pdmm0_clk: pdmm0-clk {
+			rockchip,pins =
+				/* pdm_clk0m0 */
+				<1 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_clk1: pdmm0-clk1 {
+			rockchip,pins =
+				/* pdmm0_clk1 */
+				<1 RK_PA4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi0: pdmm0-sdi0 {
+			rockchip,pins =
+				/* pdmm0_sdi0 */
+				<1 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi1: pdmm0-sdi1 {
+			rockchip,pins =
+				/* pdmm0_sdi1 */
+				<1 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi2: pdmm0-sdi2 {
+			rockchip,pins =
+				/* pdmm0_sdi2 */
+				<1 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi3: pdmm0-sdi3 {
+			rockchip,pins =
+				/* pdmm0_sdi3 */
+				<1 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk: pdmm1-clk {
+			rockchip,pins =
+				/* pdm_clk0m1 */
+				<3 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk1: pdmm1-clk1 {
+			rockchip,pins =
+				/* pdmm1_clk1 */
+				<4 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi0: pdmm1-sdi0 {
+			rockchip,pins =
+				/* pdmm1_sdi0 */
+				<3 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi1: pdmm1-sdi1 {
+			rockchip,pins =
+				/* pdmm1_sdi1 */
+				<4 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi2: pdmm1-sdi2 {
+			rockchip,pins =
+				/* pdmm1_sdi2 */
+				<4 RK_PA2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi3: pdmm1-sdi3 {
+			rockchip,pins =
+				/* pdmm1_sdi3 */
+				<4 RK_PA3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_clk1: pdmm2-clk1 {
+			rockchip,pins =
+				/* pdmm2_clk1 */
+				<3 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi0: pdmm2-sdi0 {
+			rockchip,pins =
+				/* pdmm2_sdi0 */
+				<3 RK_PB3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi1: pdmm2-sdi1 {
+			rockchip,pins =
+				/* pdmm2_sdi1 */
+				<3 RK_PB4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi2: pdmm2-sdi2 {
+			rockchip,pins =
+				/* pdmm2_sdi2 */
+				<3 RK_PB7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi3: pdmm2-sdi3 {
+			rockchip,pins =
+				/* pdmm2_sdi3 */
+				<3 RK_PC0 5 &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		/omit-if-no-ref/
+		pmic_pins: pmic-pins {
+			rockchip,pins =
+				/* pmic_sleep */
+				<0 RK_PA2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pmu {
+		/omit-if-no-ref/
+		pmu_pins: pmu-pins {
+			rockchip,pins =
+				/* pmu_debug0 */
+				<0 RK_PA5 4 &pcfg_pull_none>,
+				/* pmu_debug1 */
+				<0 RK_PA6 3 &pcfg_pull_none>,
+				/* pmu_debug2 */
+				<0 RK_PC4 4 &pcfg_pull_none>,
+				/* pmu_debug3 */
+				<0 RK_PC5 4 &pcfg_pull_none>,
+				/* pmu_debug4 */
+				<0 RK_PC6 4 &pcfg_pull_none>,
+				/* pmu_debug5 */
+				<0 RK_PC7 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm0 {
+		/omit-if-no-ref/
+		pwm0m0_pins: pwm0m0-pins {
+			rockchip,pins =
+				/* pwm0_m0 */
+				<0 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm0m1_pins: pwm0m1-pins {
+			rockchip,pins =
+				/* pwm0_m1 */
+				<0 RK_PC7 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm1 {
+		/omit-if-no-ref/
+		pwm1m0_pins: pwm1m0-pins {
+			rockchip,pins =
+				/* pwm1_m0 */
+				<0 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm1m1_pins: pwm1m1-pins {
+			rockchip,pins =
+				/* pwm1_m1 */
+				<0 RK_PB5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm2 {
+		/omit-if-no-ref/
+		pwm2m0_pins: pwm2m0-pins {
+			rockchip,pins =
+				/* pwm2_m0 */
+				<0 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm2m1_pins: pwm2m1-pins {
+			rockchip,pins =
+				/* pwm2_m1 */
+				<0 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm3 {
+		/omit-if-no-ref/
+		pwm3_pins: pwm3-pins {
+			rockchip,pins =
+				/* pwm3_ir */
+				<0 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm4 {
+		/omit-if-no-ref/
+		pwm4_pins: pwm4-pins {
+			rockchip,pins =
+				/* pwm4 */
+				<0 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm5 {
+		/omit-if-no-ref/
+		pwm5_pins: pwm5-pins {
+			rockchip,pins =
+				/* pwm5 */
+				<0 RK_PC4 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm6 {
+		/omit-if-no-ref/
+		pwm6_pins: pwm6-pins {
+			rockchip,pins =
+				/* pwm6 */
+				<0 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm7 {
+		/omit-if-no-ref/
+		pwm7_pins: pwm7-pins {
+			rockchip,pins =
+				/* pwm7_ir */
+				<0 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm8 {
+		/omit-if-no-ref/
+		pwm8m0_pins: pwm8m0-pins {
+			rockchip,pins =
+				/* pwm8_m0 */
+				<3 RK_PB1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm8m1_pins: pwm8m1-pins {
+			rockchip,pins =
+				/* pwm8_m1 */
+				<1 RK_PD5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm9 {
+		/omit-if-no-ref/
+		pwm9m0_pins: pwm9m0-pins {
+			rockchip,pins =
+				/* pwm9_m0 */
+				<3 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm9m1_pins: pwm9m1-pins {
+			rockchip,pins =
+				/* pwm9_m1 */
+				<1 RK_PD6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm10 {
+		/omit-if-no-ref/
+		pwm10m0_pins: pwm10m0-pins {
+			rockchip,pins =
+				/* pwm10_m0 */
+				<3 RK_PB5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm10m1_pins: pwm10m1-pins {
+			rockchip,pins =
+				/* pwm10_m1 */
+				<2 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm11 {
+		/omit-if-no-ref/
+		pwm11m0_pins: pwm11m0-pins {
+			rockchip,pins =
+				/* pwm11_irm0 */
+				<3 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm11m1_pins: pwm11m1-pins {
+			rockchip,pins =
+				/* pwm11_irm1 */
+				<4 RK_PC0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pwm12 {
+		/omit-if-no-ref/
+		pwm12m0_pins: pwm12m0-pins {
+			rockchip,pins =
+				/* pwm12_m0 */
+				<3 RK_PB7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm12m1_pins: pwm12m1-pins {
+			rockchip,pins =
+				/* pwm12_m1 */
+				<4 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm13 {
+		/omit-if-no-ref/
+		pwm13m0_pins: pwm13m0-pins {
+			rockchip,pins =
+				/* pwm13_m0 */
+				<3 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm13m1_pins: pwm13m1-pins {
+			rockchip,pins =
+				/* pwm13_m1 */
+				<4 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm14 {
+		/omit-if-no-ref/
+		pwm14m0_pins: pwm14m0-pins {
+			rockchip,pins =
+				/* pwm14_m0 */
+				<3 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm14m1_pins: pwm14m1-pins {
+			rockchip,pins =
+				/* pwm14_m1 */
+				<4 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm15 {
+		/omit-if-no-ref/
+		pwm15m0_pins: pwm15m0-pins {
+			rockchip,pins =
+				/* pwm15_irm0 */
+				<3 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm15m1_pins: pwm15m1-pins {
+			rockchip,pins =
+				/* pwm15_irm1 */
+				<4 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	refclk {
+		/omit-if-no-ref/
+		refclk_pins: refclk-pins {
+			rockchip,pins =
+				/* refclk_ou */
+				<0 RK_PA0 1 &pcfg_pull_none>;
+		};
+	};
+
+	sata {
+		/omit-if-no-ref/
+		sata_pins: sata-pins {
+			rockchip,pins =
+				/* sata_cpdet */
+				<0 RK_PA4 2 &pcfg_pull_none>,
+				/* sata_cppod */
+				<0 RK_PA6 1 &pcfg_pull_none>,
+				/* sata_mpswitch */
+				<0 RK_PA5 2 &pcfg_pull_none>;
+		};
+	};
+
+	sata0 {
+		/omit-if-no-ref/
+		sata0_pins: sata0-pins {
+			rockchip,pins =
+				/* sata0_actled */
+				<4 RK_PC6 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata1 {
+		/omit-if-no-ref/
+		sata1_pins: sata1-pins {
+			rockchip,pins =
+				/* sata1_actled */
+				<4 RK_PC5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata2 {
+		/omit-if-no-ref/
+		sata2_pins: sata2-pins {
+			rockchip,pins =
+				/* sata2_actled */
+				<4 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	scr {
+		/omit-if-no-ref/
+		scr_pins: scr-pins {
+			rockchip,pins =
+				/* scr_clk */
+				<1 RK_PA2 3 &pcfg_pull_none>,
+				/* scr_det */
+				<1 RK_PA7 3 &pcfg_pull_up>,
+				/* scr_io */
+				<1 RK_PA3 3 &pcfg_pull_up>,
+				/* scr_rst */
+				<1 RK_PA5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc0 {
+		/omit-if-no-ref/
+		sdmmc0_bus4: sdmmc0-bus4 {
+			rockchip,pins =
+				/* sdmmc0_d0 */
+				<1 RK_PD5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d1 */
+				<1 RK_PD6 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d2 */
+				<1 RK_PD7 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d3 */
+				<2 RK_PA0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_clk: sdmmc0-clk {
+			rockchip,pins =
+				/* sdmmc0_clk */
+				<2 RK_PA2 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_cmd: sdmmc0-cmd {
+			rockchip,pins =
+				/* sdmmc0_cmd */
+				<2 RK_PA1 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_det: sdmmc0-det {
+			rockchip,pins =
+				/* sdmmc0_det */
+				<0 RK_PA4 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_pwren: sdmmc0-pwren {
+			rockchip,pins =
+				/* sdmmc0_pwren */
+				<0 RK_PA5 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc1 {
+		/omit-if-no-ref/
+		sdmmc1_bus4: sdmmc1-bus4 {
+			rockchip,pins =
+				/* sdmmc1_d0 */
+				<2 RK_PA3 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d1 */
+				<2 RK_PA4 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d2 */
+				<2 RK_PA5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d3 */
+				<2 RK_PA6 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_clk: sdmmc1-clk {
+			rockchip,pins =
+				/* sdmmc1_clk */
+				<2 RK_PB0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_cmd: sdmmc1-cmd {
+			rockchip,pins =
+				/* sdmmc1_cmd */
+				<2 RK_PA7 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_det: sdmmc1-det {
+			rockchip,pins =
+				/* sdmmc1_det */
+				<2 RK_PB2 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_pwren: sdmmc1-pwren {
+			rockchip,pins =
+				/* sdmmc1_pwren */
+				<2 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc2 {
+		/omit-if-no-ref/
+		sdmmc2m0_bus4: sdmmc2m0-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m0 */
+				<3 RK_PC6 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m0 */
+				<3 RK_PC7 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m0 */
+				<3 RK_PD0 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m0 */
+				<3 RK_PD1 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_clk: sdmmc2m0-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm0 */
+				<3 RK_PD3 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_cmd: sdmmc2m0-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm0 */
+				<3 RK_PD2 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_det: sdmmc2m0-det {
+			rockchip,pins =
+				/* sdmmc2_detm0 */
+				<3 RK_PD4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_pwren: sdmmc2m0-pwren {
+			rockchip,pins =
+				/* sdmmc2m0_pwren */
+				<3 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_bus4: sdmmc2m1-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m1 */
+				<3 RK_PA1 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m1 */
+				<3 RK_PA2 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m1 */
+				<3 RK_PA3 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m1 */
+				<3 RK_PA4 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_clk: sdmmc2m1-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm1 */
+				<3 RK_PA6 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_cmd: sdmmc2m1-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm1 */
+				<3 RK_PA5 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_det: sdmmc2m1-det {
+			rockchip,pins =
+				/* sdmmc2_detm1 */
+				<3 RK_PA7 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_pwren: sdmmc2m1-pwren {
+			rockchip,pins =
+				/* sdmmc2m1_pwren */
+				<3 RK_PB0 4 &pcfg_pull_none>;
+		};
+	};
+
+	spdif {
+		/omit-if-no-ref/
+		spdifm0_tx: spdifm0-tx {
+			rockchip,pins =
+				/* spdifm0_tx */
+				<1 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm1_tx: spdifm1-tx {
+			rockchip,pins =
+				/* spdifm1_tx */
+				<3 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm2_tx: spdifm2-tx {
+			rockchip,pins =
+				/* spdifm2_tx */
+				<4 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	spi0 {
+		/omit-if-no-ref/
+		spi0m0_pins: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_none>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_none>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_none>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_none>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi1 {
+		/omit-if-no-ref/
+		spi1m0_pins: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_none>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_none>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_none>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_none>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi2 {
+		/omit-if-no-ref/
+		spi2m0_pins: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_none>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_none>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_none>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_none>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi3 {
+		/omit-if-no-ref/
+		spi3m0_pins: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_none>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_none>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_none>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_none>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_none>;
+		};
+	};
+
+	tsadc {
+		/omit-if-no-ref/
+		tsadcm0_shut: tsadcm0-shut {
+			rockchip,pins =
+				/* tsadcm0_shut */
+				<0 RK_PA1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadcm1_shut: tsadcm1-shut {
+			rockchip,pins =
+				/* tsadcm1_shut */
+				<0 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadc_shutorg: tsadc-shutorg {
+			rockchip,pins =
+				/* tsadc_shutorg */
+				<0 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	uart0 {
+		/omit-if-no-ref/
+		uart0_xfer: uart0-xfer {
+			rockchip,pins =
+				/* uart0_rx */
+				<0 RK_PC0 3 &pcfg_pull_up>,
+				/* uart0_tx */
+				<0 RK_PC1 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart0_ctsn: uart0-ctsn {
+			rockchip,pins =
+				/* uart0_ctsn */
+				<0 RK_PC7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart0_rtsn: uart0-rtsn {
+			rockchip,pins =
+				/* uart0_rtsn */
+				<0 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	uart1 {
+		/omit-if-no-ref/
+		uart1m0_xfer: uart1m0-xfer {
+			rockchip,pins =
+				/* uart1_rxm0 */
+				<2 RK_PB3 2 &pcfg_pull_up>,
+				/* uart1_txm0 */
+				<2 RK_PB4 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_ctsn: uart1m0-ctsn {
+			rockchip,pins =
+				/* uart1m0_ctsn */
+				<2 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_rtsn: uart1m0-rtsn {
+			rockchip,pins =
+				/* uart1m0_rtsn */
+				<2 RK_PB5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_xfer: uart1m1-xfer {
+			rockchip,pins =
+				/* uart1_rxm1 */
+				<3 RK_PD7 4 &pcfg_pull_up>,
+				/* uart1_txm1 */
+				<3 RK_PD6 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_ctsn: uart1m1-ctsn {
+			rockchip,pins =
+				/* uart1m1_ctsn */
+				<4 RK_PC1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_rtsn: uart1m1-rtsn {
+			rockchip,pins =
+				/* uart1m1_rtsn */
+				<4 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	uart2 {
+		/omit-if-no-ref/
+		uart2m0_xfer: uart2m0-xfer {
+			rockchip,pins =
+				/* uart2_rxm0 */
+				<0 RK_PD0 1 &pcfg_pull_up>,
+				/* uart2_txm0 */
+				<0 RK_PD1 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart2m1_xfer: uart2m1-xfer {
+			rockchip,pins =
+				/* uart2_rxm1 */
+				<1 RK_PD6 2 &pcfg_pull_up>,
+				/* uart2_txm1 */
+				<1 RK_PD5 2 &pcfg_pull_up>;
+		};
+	};
+
+	uart3 {
+		/omit-if-no-ref/
+		uart3m0_xfer: uart3m0-xfer {
+			rockchip,pins =
+				/* uart3_rxm0 */
+				<1 RK_PA0 2 &pcfg_pull_up>,
+				/* uart3_txm0 */
+				<1 RK_PA1 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_ctsn: uart3m0-ctsn {
+			rockchip,pins =
+				/* uart3m0_ctsn */
+				<1 RK_PA3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_rtsn: uart3m0-rtsn {
+			rockchip,pins =
+				/* uart3m0_rtsn */
+				<1 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m1_xfer: uart3m1-xfer {
+			rockchip,pins =
+				/* uart3_rxm1 */
+				<3 RK_PC0 4 &pcfg_pull_up>,
+				/* uart3_txm1 */
+				<3 RK_PB7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart4 {
+		/omit-if-no-ref/
+		uart4m0_xfer: uart4m0-xfer {
+			rockchip,pins =
+				/* uart4_rxm0 */
+				<1 RK_PA4 2 &pcfg_pull_up>,
+				/* uart4_txm0 */
+				<1 RK_PA6 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_ctsn: uart4m0-ctsn {
+			rockchip,pins =
+				/* uart4m0_ctsn */
+				<1 RK_PA7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_rtsn: uart4m0-rtsn {
+			rockchip,pins =
+				/* uart4m0_rtsn */
+				<1 RK_PA5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m1_xfer: uart4m1-xfer {
+			rockchip,pins =
+				/* uart4_rxm1 */
+				<3 RK_PB1 4 &pcfg_pull_up>,
+				/* uart4_txm1 */
+				<3 RK_PB2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart5 {
+		/omit-if-no-ref/
+		uart5m0_xfer: uart5m0-xfer {
+			rockchip,pins =
+				/* uart5_rxm0 */
+				<2 RK_PA1 3 &pcfg_pull_up>,
+				/* uart5_txm0 */
+				<2 RK_PA2 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_ctsn: uart5m0-ctsn {
+			rockchip,pins =
+				/* uart5m0_ctsn */
+				<1 RK_PD7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_rtsn: uart5m0-rtsn {
+			rockchip,pins =
+				/* uart5m0_rtsn */
+				<2 RK_PA0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m1_xfer: uart5m1-xfer {
+			rockchip,pins =
+				/* uart5_rxm1 */
+				<3 RK_PC3 4 &pcfg_pull_up>,
+				/* uart5_txm1 */
+				<3 RK_PC2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart6 {
+		/omit-if-no-ref/
+		uart6m0_xfer: uart6m0-xfer {
+			rockchip,pins =
+				/* uart6_rxm0 */
+				<2 RK_PA3 3 &pcfg_pull_up>,
+				/* uart6_txm0 */
+				<2 RK_PA4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_ctsn: uart6m0-ctsn {
+			rockchip,pins =
+				/* uart6m0_ctsn */
+				<2 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_rtsn: uart6m0-rtsn {
+			rockchip,pins =
+				/* uart6m0_rtsn */
+				<2 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m1_xfer: uart6m1-xfer {
+			rockchip,pins =
+				/* uart6_rxm1 */
+				<1 RK_PD6 3 &pcfg_pull_up>,
+				/* uart6_txm1 */
+				<1 RK_PD5 3 &pcfg_pull_up>;
+		};
+	};
+
+	uart7 {
+		/omit-if-no-ref/
+		uart7m0_xfer: uart7m0-xfer {
+			rockchip,pins =
+				/* uart7_rxm0 */
+				<2 RK_PA5 3 &pcfg_pull_up>,
+				/* uart7_txm0 */
+				<2 RK_PA6 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_ctsn: uart7m0-ctsn {
+			rockchip,pins =
+				/* uart7m0_ctsn */
+				<2 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_rtsn: uart7m0-rtsn {
+			rockchip,pins =
+				/* uart7m0_rtsn */
+				<2 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m1_xfer: uart7m1-xfer {
+			rockchip,pins =
+				/* uart7_rxm1 */
+				<3 RK_PC5 4 &pcfg_pull_up>,
+				/* uart7_txm1 */
+				<3 RK_PC4 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m2_xfer: uart7m2-xfer {
+			rockchip,pins =
+				/* uart7_rxm2 */
+				<4 RK_PA3 4 &pcfg_pull_up>,
+				/* uart7_txm2 */
+				<4 RK_PA2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart8 {
+		/omit-if-no-ref/
+		uart8m0_xfer: uart8m0-xfer {
+			rockchip,pins =
+				/* uart8_rxm0 */
+				<2 RK_PC6 2 &pcfg_pull_up>,
+				/* uart8_txm0 */
+				<2 RK_PC5 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_ctsn: uart8m0-ctsn {
+			rockchip,pins =
+				/* uart8m0_ctsn */
+				<2 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_rtsn: uart8m0-rtsn {
+			rockchip,pins =
+				/* uart8m0_rtsn */
+				<2 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m1_xfer: uart8m1-xfer {
+			rockchip,pins =
+				/* uart8_rxm1 */
+				<3 RK_PA0 4 &pcfg_pull_up>,
+				/* uart8_txm1 */
+				<2 RK_PD7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart9 {
+		/omit-if-no-ref/
+		uart9m0_xfer: uart9m0-xfer {
+			rockchip,pins =
+				/* uart9_rxm0 */
+				<2 RK_PA7 3 &pcfg_pull_up>,
+				/* uart9_txm0 */
+				<2 RK_PB0 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_ctsn: uart9m0-ctsn {
+			rockchip,pins =
+				/* uart9m0_ctsn */
+				<2 RK_PC4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_rtsn: uart9m0-rtsn {
+			rockchip,pins =
+				/* uart9m0_rtsn */
+				<2 RK_PC3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m1_xfer: uart9m1-xfer {
+			rockchip,pins =
+				/* uart9_rxm1 */
+				<4 RK_PC6 4 &pcfg_pull_up>,
+				/* uart9_txm1 */
+				<4 RK_PC5 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m2_xfer: uart9m2-xfer {
+			rockchip,pins =
+				/* uart9_rxm2 */
+				<4 RK_PA5 4 &pcfg_pull_up>,
+				/* uart9_txm2 */
+				<4 RK_PA4 4 &pcfg_pull_up>;
+		};
+	};
+
+	vop {
+		/omit-if-no-ref/
+		vopm0_pins: vopm0-pins {
+			rockchip,pins =
+				/* vop_pwmm0 */
+				<0 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		vopm1_pins: vopm1-pins {
+			rockchip,pins =
+				/* vop_pwmm1 */
+				<3 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+};
+
+/*
+ * This part is edited handly.
+ */
+&pinctrl {
+	spi0-hs {
+		/omit-if-no-ref/
+		spi0m0_pins_hs: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0_hs: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1_hs: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins_hs: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0_hs: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi1-hs {
+		/omit-if-no-ref/
+		spi1m0_pins_hs: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0_hs: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1_hs: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins_hs: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0_hs: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi2-hs {
+		/omit-if-no-ref/
+		spi2m0_pins_hs: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0_hs: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1_hs: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins_hs: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0_hs: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1_hs: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi3-hs {
+		/omit-if-no-ref/
+		spi3m0_pins_hs: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0_hs: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1_hs: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins_hs: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0_hs: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1_hs: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	gmac-txd-level3 {
+		/omit-if-no-ref/
+		gmac0_tx_bus2_level3: gmac0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus_level3: gmac0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2_level3: gmac1m0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus_level3: gmac1m0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2_level3: gmac1m1-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus_level3: gmac1m1-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_3>;
+		};
+	};
+
+	gmac-txc-level2 {
+		/omit-if-no-ref/
+		gmac0_rgmii_clk_level2: gmac0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk_level2: gmac1m0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk_level2: gmac1m1-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gpio {
+		/omit-if-no-ref/
+		tsadc_gpio: tsadc-gpio {
+			rockchip,pins =
+				<0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
new file mode 100644
index 000000000000..66cb50218ca1
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -0,0 +1,812 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/clock/rk3568-cru.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,boot-mode.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+	compatible = "rockchip,rk3568";
+
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc0;
+		mmc2 = &sdmmc1;
+		mmc3 = &sdmmc2;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x0>;
+			clocks = <&scmi_clk 0>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x300>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+	};
+
+	cpu0_opp_table: cpu0-opp-table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <825000 825000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <825000 825000 1150000>;
+		};
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <825000 825000 1150000>;
+			opp-suspend;
+		};
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <825000 825000 1150000>;
+		};
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <975000 975000 1150000>;
+		};
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1050000 1050000 1150000>;
+		};
+		opp-1992000000 {
+			opp-hz = /bits/ 64 <1992000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+		};
+	};
+
+	firmware {
+		scmi: scmi {
+			compatible = "arm,scmi-smc";
+			arm,smc-id = <0x82000010>;
+			shmem = <&scmi_shmem>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			scmi_clk: protocol at 14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+		};
+
+	};
+
+	pmu {
+		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	shmem at 10f000 {
+		compatible = "mmio-sram";
+		reg = <0x0 0x0010f000 0x0 0x100>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x0 0x0010f000 0x100>;
+
+		scmi_shmem: scmi-shmem at 10f000 {
+			compatible = "arm,scmi-shmem";
+			reg = <0x0 0x0010f000 0x0 0x100>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+		arm,no-tick-in-suspend;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+		#clock-cells = <0>;
+	};
+
+	xin32k: xin32k {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		clock-output-names = "xin32k";
+		pinctrl-0 = <&clk32k_out0>;
+		pinctrl-names = "default";
+		#clock-cells = <0>;
+	};
+
+	gic: interrupt-controller at fd400000 {
+		compatible = "arm,gic-v3";
+		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
+		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+	};
+
+	pmugrf: syscon at fdc20000 {
+		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc20000 0x0 0x10000>;
+
+		reboot_mode: reboot-mode {
+			compatible = "syscon-reboot-mode";
+			mode-bootloader = <BOOT_BL_DOWNLOAD>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_BL_DOWNLOAD>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			offset = <0x200>;
+		};
+	};
+
+	grf: syscon at fdc60000 {
+		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc60000 0x0 0x10000>;
+	};
+
+	pmucru: clock-controller at fdd00000 {
+		compatible = "rockchip,rk3568-pmucru";
+		reg = <0x0 0xfdd00000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		rockchip,pmugrf = <&pmugrf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at fdd20000 {
+		compatible = "rockchip,rk3568-cru";
+		reg = <0x0 0xfdd20000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+
+		assigned-clocks =
+			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
+			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
+			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
+			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
+			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
+			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
+			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
+			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
+			<&cru ACLK_VOP>;
+		assigned-clock-rates =
+			<32768>, <200000000>,
+			<100000000>, <1000000000>,
+			<1188000000>, <150000000>,
+			<100000000>, <500000000>,
+			<400000000>, <150000000>,
+			<100000000>, <300000000>,
+			<150000000>, <1200000000>,
+			<400000000>, <100000000>,
+			<500000000>;
+		assigned-clock-parents =
+			<&pmucru CLK_RTC32K_FRAC>;
+	};
+
+	i2c0: i2c at fdd40000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfdd40000 0x0 0x1000>;
+		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart0: serial at fdd50000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfdd50000 0x0 0x100>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 0>, <&dmac0 1>;
+		pinctrl-0 = <&uart0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm0: pwm at fdd70000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70000 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm0m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm1: pwm at fdd70010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70010 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm1m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm2: pwm at fdd70020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70020 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm2m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm3: pwm at fdd70030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70030 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm3_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	sdmmc2: dwmmc at fe000000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe000000 0x0 0x4000>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
+			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC2>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc0: dwmmc at fe2b0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2b0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
+			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC0>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc1: dwmmc at fe2c0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2c0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
+			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC1>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdhci: sdhci at fe310000 {
+		compatible = "rockchip,rk3568-dwcmshc";
+		reg = <0x0 0xfe310000 0x0 0x10000>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
+		assigned-clock-rates = <200000000>, <24000000>;
+		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
+			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
+			 <&cru TCLK_EMMC>;
+		clock-names = "core", "bus", "axi", "block", "timer";
+		status = "disabled";
+	};
+
+	dmac0: dmac at fe530000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe530000 0x0 0x4000>;
+		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	dmac1: dmac at fe550000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe550000 0x0 0x4000>;
+		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	i2c1: i2c at fe5a0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c1_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at fe5b0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5b0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c2m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at fe5c0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5c0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c3m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at fe5d0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5d0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c4m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at fe5e0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5e0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c5m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	wdt: watchdog at fe600000 {
+		compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
+		reg = <0x0 0xfe600000 0x0 0x100>;
+		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
+		clock-names = "tclk", "pclk";
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	uart1: serial at fe650000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe650000 0x0 0x100>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 2>, <&dmac0 3>;
+		pinctrl-0 = <&uart1m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart2: serial at fe660000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe660000 0x0 0x100>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 4>, <&dmac0 5>;
+		pinctrl-0 = <&uart2m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart3: serial at fe670000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe670000 0x0 0x100>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 6>, <&dmac0 7>;
+		pinctrl-0 = <&uart3m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart4: serial at fe680000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe680000 0x0 0x100>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 8>, <&dmac0 9>;
+		pinctrl-0 = <&uart4m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart5: serial at fe690000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe690000 0x0 0x100>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 10>, <&dmac0 11>;
+		pinctrl-0 = <&uart5m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart6: serial at fe6a0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6a0000 0x0 0x100>;
+		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 12>, <&dmac0 13>;
+		pinctrl-0 = <&uart6m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart7: serial at fe6b0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6b0000 0x0 0x100>;
+		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 14>, <&dmac0 15>;
+		pinctrl-0 = <&uart7m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart8: serial at fe6c0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6c0000 0x0 0x100>;
+		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 16>, <&dmac0 17>;
+		pinctrl-0 = <&uart8m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart9: serial at fe6d0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6d0000 0x0 0x100>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 18>, <&dmac0 19>;
+		pinctrl-0 = <&uart9m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm4: pwm at fe6e0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm4_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm5: pwm at fe6e0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm5_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm6: pwm at fe6e0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm6_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm7: pwm at fe6e0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm7_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm8: pwm at fe6f0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm8m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm9: pwm at fe6f0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm9m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm10: pwm at fe6f0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm10m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm11: pwm at fe6f0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm11m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm12: pwm at fe700000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700000 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm12m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm13: pwm at fe700010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700010 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm13m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm14: pwm at fe700020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700020 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm14m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm15: pwm at fe700030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700030 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm15m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3568-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gpio0: gpio at fdd60000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfdd60000 0x0 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio1: gpio at fe740000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe740000 0x0 0x100>;
+			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio2: gpio at fe750000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe750000 0x0 0x100>;
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio3: gpio at fe760000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe760000 0x0 0x100>;
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio4: gpio at fe770000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe770000 0x0 0x100>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
+
+#include "rk3568-pinctrl.dtsi"
-- 
2.17.1





From cl at rock-chips.com  Sun Apr 25 10:44:55 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Sun, 25 Apr 2021 17:44:55 +0800
Subject: [PATCH v2 7/7] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210425094216.25724-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
Message-ID: <20210425094455.25949-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
add uart/emmc/i2c/rk809 node for basic function.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/arm/rockchip.yaml     |  5 ++
 arch/arm64/boot/dts/rockchip/Makefile         |  1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 80 +++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4a6f772c1043..95ab9714af44 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -565,6 +565,11 @@ properties:
           - const: rockchip,rk3399-evb
           - const: rockchip,rk3399
 
+      - description: Rockchip RK3568 Evaluation board
+        items:
+          - const: rockchip,rk3568-evb1-v10
+          - const: rockchip,rk3568
+
       - description: Rockchip RK3399 Sapphire standalone
         items:
           - const: rockchip,rk3399-sapphire
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index c3e00c0e2db7..7fdb41de01ec 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -51,3 +51,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
new file mode 100644
index 000000000000..33a97ce03c84
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3568.dtsi"
+
+/ {
+	model = "Rockchip RK3568 EVB1 DDR4 V10 Board";
+	compatible = "rockchip,rk3568-evb1-v10", "rockchip,rk3568";
+
+	chosen: chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		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>;
+	};
+
+	vcc3v3_lcd0_n: vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_lcd1_n: vcc3v3-lcd1-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd1_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	rockchip,txclk-tapnum = <0x8>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
-- 
2.17.1





From maz at kernel.org  Sun Apr 25 11:20:13 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 25 Apr 2021 11:20:13 +0100
Subject: [PATCH v1 4/5] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <ec556a6c-e950-d152-c878-986e2616ddcd@rock-chips.com>
References: <20210421065921.23917-1-cl@rock-chips.com>
 <20210421065921.23917-5-cl@rock-chips.com>
 <87zgxrpxo5.wl-maz@kernel.org>
 <ec556a6c-e950-d152-c878-986e2616ddcd@rock-chips.com>
Message-ID: <87o8e2sm1u.wl-maz@kernel.org>

On Sun, 25 Apr 2021 10:16:50 +0100,
?? <cl at rock-chips.com> wrote:
> 
> Hi Marc?
> 
> ??? Thanks for reply.
> 
> ??? See below.
> 
> ? 2021/4/21 ??9:36, Marc Zyngier ??:
> > On Wed, 21 Apr 2021 07:59:20 +0100,
> > <cl at rock-chips.com> wrote:
> >> From: Liang Chen <cl at rock-chips.com>

[...]

> >> +	timer {
> >> +		compatible = "arm,armv8-timer";
> >> +		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > This doesn't match the GICv3 binding for PPIs.
> fixed in V2.
> > 
> >> +		arm,no-tick-in-suspend;
> > Oh, really? :-(
> yes, arm arch timer will stop in suspend mode on rk3568.

That the comparator stops is completely expected, as it lives in the
CPU power domain.

But losing the system counter on suspend is a complete violation of
the architecture, which clearly states that "The system counter must
be implemented in an always-on power domain." (ARMv8 ARM G_a, D11.1.2
The system counter).

Are you actually losing the system counter?

> >
> >> +	};
> >> +
> >> +	xin24m: xin24m {
> >> +		compatible = "fixed-clock";
> >> +		#clock-cells = <0>;
> >> +		clock-frequency = <24000000>;
> >> +		clock-output-names = "xin24m";
> >> +	};
> >> +
> >> +	xin32k: xin32k {
> >> +		compatible = "fixed-clock";
> >> +		clock-frequency = <32768>;
> >> +		clock-output-names = "xin32k";
> >> +		#clock-cells = <0>;
> >> +		pinctrl-names = "default";
> >> +		pinctrl-0 = <&clk32k_out0>;
> >> +	};
> >> +
> >> +	scmi_shmem: scmi-shmem at 10f000 {
> >> +		compatible = "arm,scmi-shmem";
> >> +		reg = <0x0 0x0010f000 0x0 0x100>;
> >> +	};
> >> +
> >> +	gic: interrupt-controller at fd400000 {
> >> +		compatible = "arm,gic-v3";
> >> +		#interrupt-cells = <3>;
> >> +		#address-cells = <2>;
> >> +		#size-cells = <2>;
> >> +		ranges;
> >> +		interrupt-controller;
> >> +
> >> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> >> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> >> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> > Please add the 'mbi-alias' property, which should map onto the GICA
> > range that GIC600 provides. At least this could be useful to have MSIs
> > despite the lack of a working ITS. We can work out the usable ranges
> > on a per-board basis.
> 
> Thanks, we will try mbi-alias later, but we are afraid that the number
> of SPI is not enough.

Not enough for what? People might want to trade the use of in-SoC
devices for MSIs. Also, the DT should describe the whole of the HW,
including features that you don't find useful.

Thanks,

	M.

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


From maz at kernel.org  Sun Apr 25 11:28:49 2021
From: maz at kernel.org (Marc Zyngier)
Date: Sun, 25 Apr 2021 11:28:49 +0100
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210425094439.25895-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
Message-ID: <87mttmslni.wl-maz@kernel.org>

As I reviewed a previous version of this series, please have the
courtesy of cc'ing me on further revisions of this series.

On Sun, 25 Apr 2021 10:44:39 +0100,
<cl at rock-chips.com> wrote:
> 
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipments. This patch
> add basic core dtsi file for it.
> 
> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> enalbe a special high-performacne PLL when high frequency is required. The
> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> 
>     cpu0: cpu at 0 {
>         device_type = "cpu";
>         compatible = "arm,cortex-a55";
>         reg = <0x0 0x0>;
>         clocks = <&scmi_clk 0>;
>     };
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
>  2 files changed, 3931 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi

[...]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..66cb50218ca1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,812 @@

[...]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,no-tick-in-suspend;

My questions on this property still stand [1].

> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +		#clock-cells = <0>;
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		pinctrl-0 = <&clk32k_out0>;
> +		pinctrl-names = "default";
> +		#clock-cells = <0>;
> +	};
> +
> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;

My request for a full description of the GICA region still stands [1].

Thanks,

	M.

[1] https://lore.kernel.org/r/87o8e2sm1u.wl-maz at kernel.org

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


From adrian.hunter at intel.com  Sun Apr 25 13:20:19 2021
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Sun, 25 Apr 2021 15:20:19 +0300
Subject: [PATCH v21 1/2] scsi: ufs: Enable power management for wlun
In-Reply-To: <4662c462e79e3e7f541f54f88f8993f421026d83.1619223249.git.asutoshd@codeaurora.org>
References: <cover.1619223249.git.asutoshd@codeaurora.org>
 <4662c462e79e3e7f541f54f88f8993f421026d83.1619223249.git.asutoshd@codeaurora.org>
Message-ID: <9e0655c3-42cf-d090-8aa5-2cb644b2e93c@intel.com>

On 24/04/21 3:20 am, Asutosh Das wrote:
> During runtime-suspend of ufs host, the scsi devices are
> already suspended and so are the queues associated with them.
> But the ufs host sends SSU (START_STOP_UNIT) to wlun
> during its runtime-suspend.
> During the process blk_queue_enter checks if the queue is not in
> suspended state. If so, it waits for the queue to resume, and never
> comes out of it.
> The commit
> (d55d15a33: scsi: block: Do not accept any requests while suspended)
> adds the check if the queue is in suspended state in blk_queue_enter().
> 
> Call trace:
>  __switch_to+0x174/0x2c4
>  __schedule+0x478/0x764
>  schedule+0x9c/0xe0
>  blk_queue_enter+0x158/0x228
>  blk_mq_alloc_request+0x40/0xa4
>  blk_get_request+0x2c/0x70
>  __scsi_execute+0x60/0x1c4
>  ufshcd_set_dev_pwr_mode+0x124/0x1e4
>  ufshcd_suspend+0x208/0x83c
>  ufshcd_runtime_suspend+0x40/0x154
>  ufshcd_pltfrm_runtime_suspend+0x14/0x20
>  pm_generic_runtime_suspend+0x28/0x3c
>  __rpm_callback+0x80/0x2a4
>  rpm_suspend+0x308/0x614
>  rpm_idle+0x158/0x228
>  pm_runtime_work+0x84/0xac
>  process_one_work+0x1f0/0x470
>  worker_thread+0x26c/0x4c8
>  kthread+0x13c/0x320
>  ret_from_fork+0x10/0x18
> 
> Fix this by registering ufs device wlun as a scsi driver and
> registering it for block runtime-pm. Also make this as a
> supplier for all other luns. That way, this device wlun
> suspends after all the consumers and resumes after
> hba resumes. This also registers a new scsi driver for rpmb wlun.
> This new driver is mostly used to clear rpmb uac.
> 
> Fixed smatch warnings:
> Reported-by: kernel test robot <lkp at intel.com>
> Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
> 
> Co-developed-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Can Guo <cang at codeaurora.org>
> Signed-off-by: Asutosh Das <asutoshd at codeaurora.org>

Note we don't use regulators, clocks, clock scaling or gating.
Although those things do look OK.
Notwithstanding that:

Reviewed-by: Adrian Hunter <adrian.hunter at intel.com>


From jrdr.linux at gmail.com  Sun Apr 25 13:26:24 2021
From: jrdr.linux at gmail.com (Souptick Joarder)
Date: Sun, 25 Apr 2021 17:56:24 +0530
Subject: [PATCH] pinctrl: aspeed: Fix minor documentation error
Message-ID: <1619353584-8196-1-git-send-email-jrdr.linux@gmail.com>

Kernel test robot throws below warning ->

drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c:2705: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2614: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinctrl-aspeed.c:111: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinmux-aspeed.c:24: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst

Fix minor documentation error.

Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux at gmail.com>
Cc: Randy Dunlap <rdunlap at infradead.org>
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 4 ++--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 4 ++--
 drivers/pinctrl/aspeed/pinctrl-aspeed.c    | 3 ++-
 drivers/pinctrl/aspeed/pinmux-aspeed.c     | 3 ++-
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 996ebcb..4c0d266 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2702,8 +2702,8 @@ static int aspeed_g5_sig_expr_eval(struct aspeed_pinmux_data *ctx,
 }
 
 /**
- * Configure a pin's signal by applying an expression's descriptor state for
- * all descriptors in the expression.
+ * aspeed_g5_sig_expr_set() - Configure a pin's signal by applying an
+ * expression's descriptor state for all descriptors in the expression.
  *
  * @ctx: The pinmux context
  * @expr: The expression associated with the function whose signal is to be
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
index 5c1a109..eeab093 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -2611,8 +2611,8 @@
 };
 
 /**
- * Configure a pin's signal by applying an expression's descriptor state for
- * all descriptors in the expression.
+ * aspeed_g6_sig_expr_set() - Configure a pin's signal by applying an
+ * expression's descriptor state for all descriptors in the expression.
  *
  * @ctx: The pinmux context
  * @expr: The expression associated with the function whose signal is to be
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
index 9c65d56..9bbfe5c 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
@@ -108,7 +108,8 @@ static int aspeed_sig_expr_disable(struct aspeed_pinmux_data *ctx,
 }
 
 /**
- * Disable a signal on a pin by disabling all provided signal expressions.
+ * aspeed_disable_sig() - Disable a signal on a pin by disabling all provided
+ * signal expressions.
  *
  * @ctx: The pinmux context
  * @exprs: The list of signal expressions (from a priority level on a pin)
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.c b/drivers/pinctrl/aspeed/pinmux-aspeed.c
index 57305ca..894e2ef 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.c
@@ -21,7 +21,8 @@ static inline void aspeed_sig_desc_print_val(
 }
 
 /**
- * Query the enabled or disabled state of a signal descriptor
+ * aspeed_sig_desc_eval() - Query the enabled or disabled state of a signal
+ * descriptor.
  *
  * @desc: The signal descriptor of interest
  * @enabled: True to query the enabled state, false to query disabled state
-- 
1.9.1



From kernelfans at gmail.com  Sun Apr 25 15:12:54 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:54 +0800
Subject: [PATCHv2 00/10] use __create_pgd_mapping() to implement idmap and
 unify codes
Message-ID: <20210425141304.32721-1-kernelfans@gmail.com>

This series aim to share the pgtable manipulation code to head.S and
trans_pgd_idmap_page().

The core of the idea is by redefinition the CONFIG_PGTABLE_LEVEL, two
sets of pgtable manipulation code are generated, one as now is for
swapper_pg_dir, the other one is for idmap. And a dedicated
create_idmap() API is introduced.

The series can be grouped into two
[1~5/10] achieves porting trans_pgd_idmap_page() and introduce
create_idmap() API
[6-10/10] replace head.S pgtable manipulation asm with calling to
__create_pgd_mapping()


This series can success booting with the following configuration on Cavium
ThunderX 88XX cpu :
        PAGE_SIZE  VA  PA  PGTABLE_LEVEL
        4K         48  48  4
        4K         39  48  3
        16K        48  48  4
        16K        47  48  3
        64K        52  52  3
        64K        42  52  2


History

RFC:
https://lore.kernel.org/linux-arm-kernel/20210410095654.24102-1-kernelfans at gmail.com/

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org

Pingfan Liu (10):
  arm64/mm: split out __create_pgd_mapping() routines
  arm64/mm: change __create_pgd_mapping() to accept nr_entries param and
    introduce create_idmap()
  arm64/mm: change __create_pgd_mapping() to accept extra parameter for
    allocator
  arm64/mm: enable __create_pgd_mapping() to run across different
    pgtable
  arm64/mm: port trans_pgd_idmap_page() onto create_idmap()
  arm64/mm: introduce pgtable allocator for idmap_pg_dir and init_pg_dir
  arm64/pgtable-prot.h: reorganize to cope with asm
  arm64/mmu_include.c: disable WARN_ON() and BUG_ON() when booting.
  arm64/mm: make __create_pgd_mapping() coped with pgtable's paddr
  arm64/head: convert idmap_pg_dir and init_pg_dir to
    __create_pgd_mapping()

 arch/arm64/Kconfig                    |   4 +
 arch/arm64/include/asm/pgalloc.h      |  29 +++
 arch/arm64/include/asm/pgtable-prot.h |  34 ++-
 arch/arm64/kernel/head.S              | 196 ++++----------
 arch/arm64/mm/Makefile                |   2 +
 arch/arm64/mm/idmap_mmu.c             |  39 +++
 arch/arm64/mm/mmu.c                   | 362 ++++++--------------------
 arch/arm64/mm/mmu_include.c           | 320 +++++++++++++++++++++++
 arch/arm64/mm/trans_pgd.c             |  62 +++--
 9 files changed, 579 insertions(+), 469 deletions(-)
 create mode 100644 arch/arm64/mm/idmap_mmu.c
 create mode 100644 arch/arm64/mm/mmu_include.c

-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:12:55 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:55 +0800
Subject: [PATCHv2 01/10] arm64/mm: split out __create_pgd_mapping() routines
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-2-kernelfans@gmail.com>

If VA_BITS < 48, an additional table level should be used to allow an ID
mapping to cover system RAM. At present, it is done by macro
create_table_entry in head.S. But with second thoughts, this expansion
can be easily achieved by redefinition of CONFIG_PGTABLE_LEVELS.

Split out the routines for __create_pgd_mapping(), so that two sets of
code will be generated to manipulate pgtable under two different
CONFIG_PGTABLE_LEVELS. Later the one generated under
'CONFIG_PGTABLE_LEVELS + 1' can be used for idmap.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org

---
RFC -> v2:
  consider the config ARM64_16K_PAGES && ARM64_VA_BITS_36
  and move redefinition of CONFIG_PGTABLE_LEVELS to the head of
idmap_mmu.c
---
 arch/arm64/Kconfig          |   4 +
 arch/arm64/mm/Makefile      |   2 +
 arch/arm64/mm/idmap_mmu.c   |  34 +++++
 arch/arm64/mm/mmu.c         | 263 +----------------------------------
 arch/arm64/mm/mmu_include.c | 270 ++++++++++++++++++++++++++++++++++++
 5 files changed, 312 insertions(+), 261 deletions(-)
 create mode 100644 arch/arm64/mm/idmap_mmu.c
 create mode 100644 arch/arm64/mm/mmu_include.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..79755ade5d27 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -327,6 +327,10 @@ config PGTABLE_LEVELS
 	default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
 	default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
 
+config IDMAP_PGTABLE_EXPAND
+	def_bool y
+	depends on (ARM64_16K_PAGES && ARM64_VA_BITS_36) || (ARM64_64K_PAGES && ARM64_VA_BITS_42) || (ARM64_4K_PAGES && ARM64_VA_BITS_39) || (ARM64_16K_PAGES && ARM64_VA_BITS_47)
+
 config ARCH_SUPPORTS_UPROBES
 	def_bool y
 
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index f188c9092696..f9283cb9a201 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -3,6 +3,8 @@ 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
+
+obj-$(CONFIG_IDMAP_PGTABLE_EXPAND)	+= idmap_mmu.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/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
new file mode 100644
index 000000000000..42a27dd5cc9f
--- /dev/null
+++ b/arch/arm64/mm/idmap_mmu.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#ifdef CONFIG_IDMAP_PGTABLE_EXPAND
+
+#if CONFIG_PGTABLE_LEVELS == 2
+#define EXTEND_LEVEL 3
+#elif CONFIG_PGTABLE_LEVELS == 3
+#define EXTEND_LEVEL 4
+#endif
+
+#undef CONFIG_PGTABLE_LEVELS
+#define CONFIG_PGTABLE_LEVELS EXTEND_LEVEL
+
+#include <linux/errno.h>
+
+#include <asm/barrier.h>
+#include <asm/fixmap.h>
+#include <asm/kernel-pgtable.h>
+#include <asm/sections.h>
+#include <asm/pgalloc.h>
+
+#include "./mmu_include.c"
+
+void __create_pgd_mapping_extend(pgd_t *pgdir, phys_addr_t phys,
+				 unsigned long virt, phys_addr_t size,
+				 pgprot_t prot,
+				 phys_addr_t (*pgtable_alloc)(int),
+				 int flags)
+{
+	__create_pgd_mapping(pgdir, phys, virt, size, prot, pgtable_alloc, flags);
+}
+#endif
+
+
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d9550fdb9cf..56e4f25e8d6d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -37,9 +37,6 @@
 #include <asm/tlbflush.h>
 #include <asm/pgalloc.h>
 
-#define NO_BLOCK_MAPPINGS	BIT(0)
-#define NO_CONT_MAPPINGS	BIT(1)
-
 u64 idmap_t0sz = TCR_T0SZ(VA_BITS_MIN);
 u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
 
@@ -116,264 +113,6 @@ static phys_addr_t __init early_pgtable_alloc(int shift)
 	return phys;
 }
 
-static bool pgattr_change_is_safe(u64 old, u64 new)
-{
-	/*
-	 * The following mapping attributes may be updated in live
-	 * kernel mappings without the need for break-before-make.
-	 */
-	pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE | PTE_NG;
-
-	/* creating or taking down mappings is always safe */
-	if (old == 0 || new == 0)
-		return true;
-
-	/* live contiguous mappings may not be manipulated at all */
-	if ((old | new) & PTE_CONT)
-		return false;
-
-	/* Transitioning from Non-Global to Global is unsafe */
-	if (old & ~new & PTE_NG)
-		return false;
-
-	/*
-	 * Changing the memory type between Normal and Normal-Tagged is safe
-	 * since Tagged is considered a permission attribute from the
-	 * mismatched attribute aliases perspective.
-	 */
-	if (((old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
-	     (old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)) &&
-	    ((new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
-	     (new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)))
-		mask |= PTE_ATTRINDX_MASK;
-
-	return ((old ^ new) & ~mask) == 0;
-}
-
-static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot)
-{
-	pte_t *ptep;
-
-	ptep = pte_set_fixmap_offset(pmdp, addr);
-	do {
-		pte_t old_pte = READ_ONCE(*ptep);
-
-		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
-
-		/*
-		 * After the PTE entry has been populated once, we
-		 * only allow updates to the permission attributes.
-		 */
-		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
-					      READ_ONCE(pte_val(*ptep))));
-
-		phys += PAGE_SIZE;
-	} while (ptep++, addr += PAGE_SIZE, addr != end);
-
-	pte_clear_fixmap();
-}
-
-static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
-				unsigned long end, phys_addr_t phys,
-				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int),
-				int flags)
-{
-	unsigned long next;
-	pmd_t pmd = READ_ONCE(*pmdp);
-
-	BUG_ON(pmd_sect(pmd));
-	if (pmd_none(pmd)) {
-		phys_addr_t pte_phys;
-		BUG_ON(!pgtable_alloc);
-		pte_phys = pgtable_alloc(PAGE_SHIFT);
-		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
-		pmd = READ_ONCE(*pmdp);
-	}
-	BUG_ON(pmd_bad(pmd));
-
-	do {
-		pgprot_t __prot = prot;
-
-		next = pte_cont_addr_end(addr, end);
-
-		/* use a contiguous mapping if the range is suitably aligned */
-		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
-			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
-
-		init_pte(pmdp, addr, next, phys, __prot);
-
-		phys += next - addr;
-	} while (addr = next, addr != end);
-}
-
-static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot,
-		     phys_addr_t (*pgtable_alloc)(int), int flags)
-{
-	unsigned long next;
-	pmd_t *pmdp;
-
-	pmdp = pmd_set_fixmap_offset(pudp, addr);
-	do {
-		pmd_t old_pmd = READ_ONCE(*pmdp);
-
-		next = pmd_addr_end(addr, end);
-
-		/* try section mapping first */
-		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
-		    (flags & NO_BLOCK_MAPPINGS) == 0) {
-			pmd_set_huge(pmdp, phys, prot);
-
-			/*
-			 * After the PMD entry has been populated once, we
-			 * only allow updates to the permission attributes.
-			 */
-			BUG_ON(!pgattr_change_is_safe(pmd_val(old_pmd),
-						      READ_ONCE(pmd_val(*pmdp))));
-		} else {
-			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
-
-			BUG_ON(pmd_val(old_pmd) != 0 &&
-			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
-		}
-		phys += next - addr;
-	} while (pmdp++, addr = next, addr != end);
-
-	pmd_clear_fixmap();
-}
-
-static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
-				unsigned long end, phys_addr_t phys,
-				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int), int flags)
-{
-	unsigned long next;
-	pud_t pud = READ_ONCE(*pudp);
-
-	/*
-	 * Check for initial section mappings in the pgd/pud.
-	 */
-	BUG_ON(pud_sect(pud));
-	if (pud_none(pud)) {
-		phys_addr_t pmd_phys;
-		BUG_ON(!pgtable_alloc);
-		pmd_phys = pgtable_alloc(PMD_SHIFT);
-		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
-		pud = READ_ONCE(*pudp);
-	}
-	BUG_ON(pud_bad(pud));
-
-	do {
-		pgprot_t __prot = prot;
-
-		next = pmd_cont_addr_end(addr, end);
-
-		/* use a contiguous mapping if the range is suitably aligned */
-		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
-		    (flags & NO_CONT_MAPPINGS) == 0)
-			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
-
-		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
-
-		phys += next - addr;
-	} while (addr = next, addr != end);
-}
-
-static inline bool use_1G_block(unsigned long addr, unsigned long next,
-			unsigned long phys)
-{
-	if (PAGE_SHIFT != 12)
-		return false;
-
-	if (((addr | next | phys) & ~PUD_MASK) != 0)
-		return false;
-
-	return true;
-}
-
-static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
-			   phys_addr_t phys, pgprot_t prot,
-			   phys_addr_t (*pgtable_alloc)(int),
-			   int flags)
-{
-	unsigned long next;
-	pud_t *pudp;
-	p4d_t *p4dp = p4d_offset(pgdp, addr);
-	p4d_t p4d = READ_ONCE(*p4dp);
-
-	if (p4d_none(p4d)) {
-		phys_addr_t pud_phys;
-		BUG_ON(!pgtable_alloc);
-		pud_phys = pgtable_alloc(PUD_SHIFT);
-		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
-		p4d = READ_ONCE(*p4dp);
-	}
-	BUG_ON(p4d_bad(p4d));
-
-	pudp = pud_set_fixmap_offset(p4dp, addr);
-	do {
-		pud_t old_pud = READ_ONCE(*pudp);
-
-		next = pud_addr_end(addr, end);
-
-		/*
-		 * For 4K granule only, attempt to put down a 1GB block
-		 */
-		if (use_1G_block(addr, next, phys) &&
-		    (flags & NO_BLOCK_MAPPINGS) == 0) {
-			pud_set_huge(pudp, phys, prot);
-
-			/*
-			 * After the PUD entry has been populated once, we
-			 * only allow updates to the permission attributes.
-			 */
-			BUG_ON(!pgattr_change_is_safe(pud_val(old_pud),
-						      READ_ONCE(pud_val(*pudp))));
-		} else {
-			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
-
-			BUG_ON(pud_val(old_pud) != 0 &&
-			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
-		}
-		phys += next - addr;
-	} while (pudp++, addr = next, addr != end);
-
-	pud_clear_fixmap();
-}
-
-static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
-				 unsigned long virt, phys_addr_t size,
-				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
-				 int flags)
-{
-	unsigned long addr, end, next;
-	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
-
-	/*
-	 * If the virtual and physical address don't have the same offset
-	 * within a page, we cannot map the region as the caller expects.
-	 */
-	if (WARN_ON((phys ^ virt) & ~PAGE_MASK))
-		return;
-
-	phys &= PAGE_MASK;
-	addr = virt & PAGE_MASK;
-	end = PAGE_ALIGN(virt + size);
-
-	do {
-		next = pgd_addr_end(addr, end);
-		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
-			       flags);
-		phys += next - addr;
-	} while (pgdp++, addr = next, addr != end);
-}
-
 static phys_addr_t __pgd_pgtable_alloc(int shift)
 {
 	void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
@@ -404,6 +143,8 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
 	return pa;
 }
 
+#include "./mmu_include.c"
+
 /*
  * This function can only be used to modify existing table entries,
  * without allocating new levels of table. Note that this permits the
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
new file mode 100644
index 000000000000..95ff35a3c6cb
--- /dev/null
+++ b/arch/arm64/mm/mmu_include.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This file is shared
+ * And these functions should be PIC because they are called under both MMU-disable
+ * and MMU-enable
+ */
+
+#define NO_BLOCK_MAPPINGS	BIT(0)
+#define NO_CONT_MAPPINGS	BIT(1)
+
+static bool pgattr_change_is_safe(u64 old, u64 new)
+{
+	/*
+	 * The following mapping attributes may be updated in live
+	 * kernel mappings without the need for break-before-make.
+	 */
+	pteval_t mask = PTE_PXN | PTE_RDONLY | PTE_WRITE | PTE_NG;
+
+	/* creating or taking down mappings is always safe */
+	if (old == 0 || new == 0)
+		return true;
+
+	/* live contiguous mappings may not be manipulated at all */
+	if ((old | new) & PTE_CONT)
+		return false;
+
+	/* Transitioning from Non-Global to Global is unsafe */
+	if (old & ~new & PTE_NG)
+		return false;
+
+	/*
+	 * Changing the memory type between Normal and Normal-Tagged is safe
+	 * since Tagged is considered a permission attribute from the
+	 * mismatched attribute aliases perspective.
+	 */
+	if (((old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
+	     (old & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)) &&
+	    ((new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL) ||
+	     (new & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)))
+		mask |= PTE_ATTRINDX_MASK;
+
+	return ((old ^ new) & ~mask) == 0;
+}
+
+static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
+		     phys_addr_t phys, pgprot_t prot)
+{
+	pte_t *ptep;
+
+	ptep = pte_set_fixmap_offset(pmdp, addr);
+	do {
+		pte_t old_pte = READ_ONCE(*ptep);
+
+		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+
+		/*
+		 * After the PTE entry has been populated once, we
+		 * only allow updates to the permission attributes.
+		 */
+		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
+					      READ_ONCE(pte_val(*ptep))));
+
+		phys += PAGE_SIZE;
+	} while (ptep++, addr += PAGE_SIZE, addr != end);
+
+	pte_clear_fixmap();
+}
+
+static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
+				unsigned long end, phys_addr_t phys,
+				pgprot_t prot,
+				phys_addr_t (*pgtable_alloc)(int),
+				int flags)
+{
+	unsigned long next;
+	pmd_t pmd = READ_ONCE(*pmdp);
+
+	BUG_ON(pmd_sect(pmd));
+	if (pmd_none(pmd)) {
+		phys_addr_t pte_phys;
+
+		BUG_ON(!pgtable_alloc);
+		pte_phys = pgtable_alloc(PAGE_SHIFT);
+		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
+		pmd = READ_ONCE(*pmdp);
+	}
+	BUG_ON(pmd_bad(pmd));
+
+	do {
+		pgprot_t __prot = prot;
+
+		next = pte_cont_addr_end(addr, end);
+
+		/* use a contiguous mapping if the range is suitably aligned */
+		if ((((addr | next | phys) & ~CONT_PTE_MASK) == 0) &&
+		    (flags & NO_CONT_MAPPINGS) == 0)
+			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+
+		init_pte(pmdp, addr, next, phys, __prot);
+
+		phys += next - addr;
+	} while (addr = next, addr != end);
+}
+
+static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
+		     phys_addr_t phys, pgprot_t prot,
+		     phys_addr_t (*pgtable_alloc)(int), int flags)
+{
+	unsigned long next;
+	pmd_t *pmdp;
+
+	pmdp = pmd_set_fixmap_offset(pudp, addr);
+	do {
+		pmd_t old_pmd = READ_ONCE(*pmdp);
+
+		next = pmd_addr_end(addr, end);
+
+		/* try section mapping first */
+		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
+		    (flags & NO_BLOCK_MAPPINGS) == 0) {
+			pmd_set_huge(pmdp, phys, prot);
+
+			/*
+			 * After the PMD entry has been populated once, we
+			 * only allow updates to the permission attributes.
+			 */
+			BUG_ON(!pgattr_change_is_safe(pmd_val(old_pmd),
+						      READ_ONCE(pmd_val(*pmdp))));
+		} else {
+			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
+					    pgtable_alloc, flags);
+
+			BUG_ON(pmd_val(old_pmd) != 0 &&
+			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
+		}
+		phys += next - addr;
+	} while (pmdp++, addr = next, addr != end);
+
+	pmd_clear_fixmap();
+}
+
+static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
+				unsigned long end, phys_addr_t phys,
+				pgprot_t prot,
+				phys_addr_t (*pgtable_alloc)(int), int flags)
+{
+	unsigned long next;
+	pud_t pud = READ_ONCE(*pudp);
+
+	/*
+	 * Check for initial section mappings in the pgd/pud.
+	 */
+	BUG_ON(pud_sect(pud));
+	if (pud_none(pud)) {
+		phys_addr_t pmd_phys;
+
+		BUG_ON(!pgtable_alloc);
+		pmd_phys = pgtable_alloc(PMD_SHIFT);
+		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
+		pud = READ_ONCE(*pudp);
+	}
+	BUG_ON(pud_bad(pud));
+
+	do {
+		pgprot_t __prot = prot;
+
+		next = pmd_cont_addr_end(addr, end);
+
+		/* use a contiguous mapping if the range is suitably aligned */
+		if ((((addr | next | phys) & ~CONT_PMD_MASK) == 0) &&
+		    (flags & NO_CONT_MAPPINGS) == 0)
+			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
+
+		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
+
+		phys += next - addr;
+	} while (addr = next, addr != end);
+}
+
+static inline bool use_1G_block(unsigned long addr, unsigned long next,
+			unsigned long phys)
+{
+	if (PAGE_SHIFT != 12)
+		return false;
+
+	if (((addr | next | phys) & ~PUD_MASK) != 0)
+		return false;
+
+	return true;
+}
+
+static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
+			   phys_addr_t phys, pgprot_t prot,
+			   phys_addr_t (*pgtable_alloc)(int),
+			   int flags)
+{
+	unsigned long next;
+	pud_t *pudp;
+	p4d_t *p4dp = p4d_offset(pgdp, addr);
+	p4d_t p4d = READ_ONCE(*p4dp);
+
+	if (p4d_none(p4d)) {
+		phys_addr_t pud_phys;
+
+		BUG_ON(!pgtable_alloc);
+		pud_phys = pgtable_alloc(PUD_SHIFT);
+		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
+		p4d = READ_ONCE(*p4dp);
+	}
+	BUG_ON(p4d_bad(p4d));
+
+	pudp = pud_set_fixmap_offset(p4dp, addr);
+	do {
+		pud_t old_pud = READ_ONCE(*pudp);
+
+		next = pud_addr_end(addr, end);
+
+		/*
+		 * For 4K granule only, attempt to put down a 1GB block
+		 */
+		if (use_1G_block(addr, next, phys) &&
+		    (flags & NO_BLOCK_MAPPINGS) == 0) {
+			pud_set_huge(pudp, phys, prot);
+
+			/*
+			 * After the PUD entry has been populated once, we
+			 * only allow updates to the permission attributes.
+			 */
+			BUG_ON(!pgattr_change_is_safe(pud_val(old_pud),
+						      READ_ONCE(pud_val(*pudp))));
+		} else {
+			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
+					    pgtable_alloc, flags);
+
+			BUG_ON(pud_val(old_pud) != 0 &&
+			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
+		}
+		phys += next - addr;
+	} while (pudp++, addr = next, addr != end);
+
+	pud_clear_fixmap();
+}
+
+static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
+				 unsigned long virt, phys_addr_t size,
+				 pgprot_t prot,
+				 phys_addr_t (*pgtable_alloc)(int),
+				 int flags)
+{
+	unsigned long addr, end, next;
+	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
+
+	/*
+	 * If the virtual and physical address don't have the same offset
+	 * within a page, we cannot map the region as the caller expects.
+	 */
+	if (WARN_ON((phys ^ virt) & ~PAGE_MASK))
+		return;
+
+	phys &= PAGE_MASK;
+	addr = virt & PAGE_MASK;
+	end = PAGE_ALIGN(virt + size);
+
+	do {
+		next = pgd_addr_end(addr, end);
+		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
+			       flags);
+		phys += next - addr;
+	} while (pgdp++, addr = next, addr != end);
+}
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:12:56 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:56 +0800
Subject: [PATCHv2 02/10] arm64/mm: change __create_pgd_mapping() to accept
 nr_entries param and introduce create_idmap()
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-3-kernelfans@gmail.com>

As idmap_ptrs_per_pgd may have pgd entries greater than PTRS_PER_PGD,
the prototype of __create_pgd_mapping() needs change to cope with that
to create idmap.

Now this adaption, create_idmap() API can be introduced to create idmap
handly for all kinds of CONFIG_PGTABLE_LEVEL

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  7 ++++++
 arch/arm64/kernel/head.S         |  3 +++
 arch/arm64/mm/idmap_mmu.c        | 16 ++++++++-----
 arch/arm64/mm/mmu.c              | 41 ++++++++++++++++++++++++++------
 arch/arm64/mm/mmu_include.c      |  9 +++++--
 5 files changed, 61 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 3c6a7f5988b1..555792921af0 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -83,4 +83,11 @@ pmd_populate(struct mm_struct *mm, pmd_t *pmdp, pgtable_t ptep)
 }
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
+extern void __create_pgd_mapping_extend(pgd_t *pgdir,
+		unsigned int entries_cnt, phys_addr_t phys,
+		unsigned long virt, phys_addr_t size,
+		pgprot_t prot,
+		phys_addr_t (*pgtable_alloc)(int),
+		int flags);
+
 #endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 840bda1869e9..e19649dbbafb 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -341,6 +341,9 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 #if VA_BITS != EXTRA_SHIFT
 #error "Mismatch between VA_BITS and page size/number of translation levels"
 #endif
+	adr_l	x4, idmap_extend_pgtable
+	mov	x5, #1
+	str	x5, [x4]                //require expanded pagetable
 
 	mov	x4, EXTRA_PTRS
 	create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
diff --git a/arch/arm64/mm/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
index 42a27dd5cc9f..bff1bffee321 100644
--- a/arch/arm64/mm/idmap_mmu.c
+++ b/arch/arm64/mm/idmap_mmu.c
@@ -21,13 +21,17 @@
 
 #include "./mmu_include.c"
 
-void __create_pgd_mapping_extend(pgd_t *pgdir, phys_addr_t phys,
-				 unsigned long virt, phys_addr_t size,
-				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
-				 int flags)
+void __create_pgd_mapping_extend(pgd_t *pgdir,
+				unsigned int entries_cnt,
+				phys_addr_t phys,
+				unsigned long virt,
+				phys_addr_t size,
+				pgprot_t prot,
+				phys_addr_t (*pgtable_alloc)(int),
+				int flags)
 {
-	__create_pgd_mapping(pgdir, phys, virt, size, prot, pgtable_alloc, flags);
+	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size, prot,
+		pgtable_alloc, flags);
 }
 #endif
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 56e4f25e8d6d..70a5a7b032dc 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -145,6 +145,33 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
 
 #include "./mmu_include.c"
 
+int idmap_extend_pgtable;
+
+/*
+ * lock: no lock protection alongside this function call
+ * todo: tear down idmap. (no requirement at present)
+ */
+void create_idmap(pgd_t *pgdir, phys_addr_t phys,
+		phys_addr_t size,
+		pgprot_t prot,
+		phys_addr_t (*pgtable_alloc)(int),
+		int flags)
+{
+	u64 ptrs_per_pgd = idmap_ptrs_per_pgd;
+
+#ifdef CONFIG_IDMAP_PGTABLE_EXPAND
+	if (idmap_extend_pgtable)
+		__create_pgd_mapping_extend(pgdir, ptrs_per_pgd,
+				phys, phys, size, prot, pgtable_alloc, flags);
+	else
+		__create_pgd_mapping(pgdir, ptrs_per_pgd,
+				phys, phys, size, prot, pgtable_alloc, flags);
+#else
+	__create_pgd_mapping(pgdir, ptrs_per_pgd,
+			phys, phys, size, prot, pgtable_alloc, flags);
+#endif
+}
+
 /*
  * This function can only be used to modify existing table entries,
  * without allocating new levels of table. Note that this permits the
@@ -158,7 +185,7 @@ static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 			&phys, virt);
 		return;
 	}
-	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
+	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
 			     NO_CONT_MAPPINGS);
 }
 
@@ -173,7 +200,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
 	if (page_mappings_only)
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
-	__create_pgd_mapping(mm->pgd, phys, virt, size, prot,
+	__create_pgd_mapping(mm->pgd, PTRS_PER_PGD, phys, virt, size, prot,
 			     pgd_pgtable_alloc, flags);
 }
 
@@ -186,7 +213,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 
-	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
+	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
 			     NO_CONT_MAPPINGS);
 
 	/* flush the TLBs after updating live kernel mappings */
@@ -196,7 +223,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
 				  phys_addr_t end, pgprot_t prot, int flags)
 {
-	__create_pgd_mapping(pgdp, start, __phys_to_virt(start), end - start,
+	__create_pgd_mapping(pgdp, PTRS_PER_PGD, start, __phys_to_virt(start), end - start,
 			     prot, early_pgtable_alloc, flags);
 }
 
@@ -297,7 +324,7 @@ static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
 	BUG_ON(!PAGE_ALIGNED(pa_start));
 	BUG_ON(!PAGE_ALIGNED(size));
 
-	__create_pgd_mapping(pgdp, pa_start, (unsigned long)va_start, size, prot,
+	__create_pgd_mapping(pgdp, PTRS_PER_PGD, pa_start, (unsigned long)va_start, size, prot,
 			     early_pgtable_alloc, flags);
 
 	if (!(vm_flags & VM_NO_GUARD))
@@ -341,7 +368,7 @@ static int __init map_entry_trampoline(void)
 
 	/* Map only the text into the trampoline page table */
 	memset(tramp_pg_dir, 0, PGD_SIZE);
-	__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
+	__create_pgd_mapping(tramp_pg_dir, PTRS_PER_PGD, pa_start, TRAMP_VALIAS, PAGE_SIZE,
 			     prot, __pgd_pgtable_alloc, 0);
 
 	/* Map both the text and data into the kernel page table */
@@ -1233,7 +1260,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
 	    IS_ENABLED(CONFIG_KFENCE))
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
-	__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
+	__create_pgd_mapping(swapper_pg_dir, PTRS_PER_PGD, start, __phys_to_virt(start),
 			     size, params->pgprot, __pgd_pgtable_alloc,
 			     flags);
 
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 95ff35a3c6cb..be51689d1133 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -241,14 +241,19 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	pud_clear_fixmap();
 }
 
-static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
+static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
 				 unsigned long virt, phys_addr_t size,
 				 pgprot_t prot,
 				 phys_addr_t (*pgtable_alloc)(int),
 				 int flags)
 {
 	unsigned long addr, end, next;
-	pgd_t *pgdp = pgd_offset_pgd(pgdir, virt);
+	pgd_t *pgdp;
+
+	if (likely(entries_cnt == PTRS_PER_PGD))
+		pgdp = pgd_offset_pgd(pgdir, virt);
+	else
+		pgdp = pgdir + ((virt >> PGDIR_SHIFT) & (entries_cnt - 1));
 
 	/*
 	 * If the virtual and physical address don't have the same offset
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:12:57 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:57 +0800
Subject: [PATCHv2 03/10] arm64/mm: change __create_pgd_mapping() to accept
 extra parameter for allocator
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-4-kernelfans@gmail.com>

The current pgtable allocator only accepts the depth of pgtable as
parameter. And the allocator function itself determines the memory pool
info.

But incoming pgtable allocator needs an extra param to get local pool
info, which directs the allocation. Here preparing the prototype for the
incoming change.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  5 +++-
 arch/arm64/mm/idmap_mmu.c        |  5 ++--
 arch/arm64/mm/mmu.c              | 31 +++++++++++++------------
 arch/arm64/mm/mmu_include.c      | 39 +++++++++++++++++++-------------
 4 files changed, 46 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 555792921af0..42f602528b90 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -83,11 +83,14 @@ pmd_populate(struct mm_struct *mm, pmd_t *pmdp, pgtable_t ptep)
 }
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
+typedef phys_addr_t (*pgtable_alloc)(unsigned long shift, void *data);
+
 extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		unsigned int entries_cnt, phys_addr_t phys,
 		unsigned long virt, phys_addr_t size,
 		pgprot_t prot,
-		phys_addr_t (*pgtable_alloc)(int),
+		pgtable_alloc allocator,
+		void *info,
 		int flags);
 
 #endif
diff --git a/arch/arm64/mm/idmap_mmu.c b/arch/arm64/mm/idmap_mmu.c
index bff1bffee321..4477cc2704a7 100644
--- a/arch/arm64/mm/idmap_mmu.c
+++ b/arch/arm64/mm/idmap_mmu.c
@@ -27,11 +27,12 @@ void __create_pgd_mapping_extend(pgd_t *pgdir,
 				unsigned long virt,
 				phys_addr_t size,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int),
+				pgtable_alloc allocator,
+				void *info,
 				int flags)
 {
 	__create_pgd_mapping(pgdir, entries_cnt, phys, virt, size, prot,
-		pgtable_alloc, flags);
+		allocator, info, flags);
 }
 #endif
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 70a5a7b032dc..520738c43874 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -86,7 +86,7 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 }
 EXPORT_SYMBOL(phys_mem_access_prot);
 
-static phys_addr_t __init early_pgtable_alloc(int shift)
+static phys_addr_t __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	phys_addr_t phys;
 	void *ptr;
@@ -113,7 +113,7 @@ static phys_addr_t __init early_pgtable_alloc(int shift)
 	return phys;
 }
 
-static phys_addr_t __pgd_pgtable_alloc(int shift)
+static phys_addr_t __pgd_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
 	BUG_ON(!ptr);
@@ -123,9 +123,9 @@ static phys_addr_t __pgd_pgtable_alloc(int shift)
 	return __pa(ptr);
 }
 
-static phys_addr_t pgd_pgtable_alloc(int shift)
+static phys_addr_t pgd_pgtable_alloc(unsigned long shift, void *unused)
 {
-	phys_addr_t pa = __pgd_pgtable_alloc(shift);
+	phys_addr_t pa = __pgd_pgtable_alloc(shift, unused);
 
 	/*
 	 * Call proper page table ctor in case later we need to
@@ -154,7 +154,8 @@ int idmap_extend_pgtable;
 void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 		phys_addr_t size,
 		pgprot_t prot,
-		phys_addr_t (*pgtable_alloc)(int),
+		pgtable_alloc allocator,
+		void *info,
 		int flags)
 {
 	u64 ptrs_per_pgd = idmap_ptrs_per_pgd;
@@ -162,13 +163,13 @@ void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 #ifdef CONFIG_IDMAP_PGTABLE_EXPAND
 	if (idmap_extend_pgtable)
 		__create_pgd_mapping_extend(pgdir, ptrs_per_pgd,
-				phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 	else
 		__create_pgd_mapping(pgdir, ptrs_per_pgd,
-				phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 #else
 	__create_pgd_mapping(pgdir, ptrs_per_pgd,
-			phys, phys, size, prot, pgtable_alloc, flags);
+				phys, phys, size, prot, allocator, info, flags);
 #endif
 }
 
@@ -186,7 +187,7 @@ static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
-			     NO_CONT_MAPPINGS);
+			     NULL, NO_CONT_MAPPINGS);
 }
 
 void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -201,7 +202,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
 	__create_pgd_mapping(mm->pgd, PTRS_PER_PGD, phys, virt, size, prot,
-			     pgd_pgtable_alloc, flags);
+			     pgd_pgtable_alloc, NULL, flags);
 }
 
 static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
@@ -214,7 +215,7 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
 	}
 
 	__create_pgd_mapping(init_mm.pgd, PTRS_PER_PGD, phys, virt, size, prot, NULL,
-			     NO_CONT_MAPPINGS);
+			     NULL, NO_CONT_MAPPINGS);
 
 	/* flush the TLBs after updating live kernel mappings */
 	flush_tlb_kernel_range(virt, virt + size);
@@ -224,7 +225,7 @@ static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
 				  phys_addr_t end, pgprot_t prot, int flags)
 {
 	__create_pgd_mapping(pgdp, PTRS_PER_PGD, start, __phys_to_virt(start), end - start,
-			     prot, early_pgtable_alloc, flags);
+			     prot, early_pgtable_alloc, NULL, flags);
 }
 
 void __init mark_linear_text_alias_ro(void)
@@ -325,7 +326,7 @@ static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
 	BUG_ON(!PAGE_ALIGNED(size));
 
 	__create_pgd_mapping(pgdp, PTRS_PER_PGD, pa_start, (unsigned long)va_start, size, prot,
-			     early_pgtable_alloc, flags);
+			     early_pgtable_alloc, NULL, flags);
 
 	if (!(vm_flags & VM_NO_GUARD))
 		size += PAGE_SIZE;
@@ -369,7 +370,7 @@ static int __init map_entry_trampoline(void)
 	/* Map only the text into the trampoline page table */
 	memset(tramp_pg_dir, 0, PGD_SIZE);
 	__create_pgd_mapping(tramp_pg_dir, PTRS_PER_PGD, pa_start, TRAMP_VALIAS, PAGE_SIZE,
-			     prot, __pgd_pgtable_alloc, 0);
+			     prot, __pgd_pgtable_alloc, NULL, 0);
 
 	/* Map both the text and data into the kernel page table */
 	__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
@@ -1261,7 +1262,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
 		flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 
 	__create_pgd_mapping(swapper_pg_dir, PTRS_PER_PGD, start, __phys_to_virt(start),
-			     size, params->pgprot, __pgd_pgtable_alloc,
+			     size, params->pgprot, __pgd_pgtable_alloc, NULL,
 			     flags);
 
 	memblock_clear_nomap(start, size);
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index be51689d1133..732e603fe3fc 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -69,7 +69,8 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 				unsigned long end, phys_addr_t phys,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int),
+				pgtable_alloc allocator,
+				void *info,
 				int flags)
 {
 	unsigned long next;
@@ -79,8 +80,8 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 	if (pmd_none(pmd)) {
 		phys_addr_t pte_phys;
 
-		BUG_ON(!pgtable_alloc);
-		pte_phys = pgtable_alloc(PAGE_SHIFT);
+		BUG_ON(!allocator);
+		pte_phys = allocator(PAGE_SHIFT, info);
 		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
 		pmd = READ_ONCE(*pmdp);
 	}
@@ -104,7 +105,9 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 
 static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 		     phys_addr_t phys, pgprot_t prot,
-		     phys_addr_t (*pgtable_alloc)(int), int flags)
+		     pgtable_alloc allocator,
+		     void *info,
+		     int flags)
 {
 	unsigned long next;
 	pmd_t *pmdp;
@@ -128,7 +131,7 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 						      READ_ONCE(pmd_val(*pmdp))));
 		} else {
 			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
+					    allocator, info, flags);
 
 			BUG_ON(pmd_val(old_pmd) != 0 &&
 			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
@@ -142,7 +145,9 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 				unsigned long end, phys_addr_t phys,
 				pgprot_t prot,
-				phys_addr_t (*pgtable_alloc)(int), int flags)
+				pgtable_alloc allocator,
+				void *info,
+				int flags)
 {
 	unsigned long next;
 	pud_t pud = READ_ONCE(*pudp);
@@ -154,8 +159,8 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 	if (pud_none(pud)) {
 		phys_addr_t pmd_phys;
 
-		BUG_ON(!pgtable_alloc);
-		pmd_phys = pgtable_alloc(PMD_SHIFT);
+		BUG_ON(!allocator);
+		pmd_phys = allocator(PMD_SHIFT, info);
 		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
 		pud = READ_ONCE(*pudp);
 	}
@@ -171,7 +176,7 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 		    (flags & NO_CONT_MAPPINGS) == 0)
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
-		init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
+		init_pmd(pudp, addr, next, phys, __prot, allocator, info, flags);
 
 		phys += next - addr;
 	} while (addr = next, addr != end);
@@ -191,7 +196,8 @@ static inline bool use_1G_block(unsigned long addr, unsigned long next,
 
 static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 			   phys_addr_t phys, pgprot_t prot,
-			   phys_addr_t (*pgtable_alloc)(int),
+			   pgtable_alloc allocator,
+			   void *info,
 			   int flags)
 {
 	unsigned long next;
@@ -202,8 +208,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	if (p4d_none(p4d)) {
 		phys_addr_t pud_phys;
 
-		BUG_ON(!pgtable_alloc);
-		pud_phys = pgtable_alloc(PUD_SHIFT);
+		BUG_ON(!allocator);
+		pud_phys = allocator(PUD_SHIFT, info);
 		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
 		p4d = READ_ONCE(*p4dp);
 	}
@@ -230,7 +236,7 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 						      READ_ONCE(pud_val(*pudp))));
 		} else {
 			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
-					    pgtable_alloc, flags);
+					    allocator, info, flags);
 
 			BUG_ON(pud_val(old_pud) != 0 &&
 			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
@@ -244,7 +250,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
 				 unsigned long virt, phys_addr_t size,
 				 pgprot_t prot,
-				 phys_addr_t (*pgtable_alloc)(int),
+				 pgtable_alloc allocator,
+				 void *info,
 				 int flags)
 {
 	unsigned long addr, end, next;
@@ -268,8 +275,8 @@ static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_ad
 
 	do {
 		next = pgd_addr_end(addr, end);
-		alloc_init_pud(pgdp, addr, next, phys, prot, pgtable_alloc,
-			       flags);
+		alloc_init_pud(pgdp, addr, next, phys, prot, allocator,
+			       info, flags);
 		phys += next - addr;
 	} while (pgdp++, addr = next, addr != end);
 }
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:12:58 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:58 +0800
Subject: [PATCHv2 04/10] arm64/mm: enable __create_pgd_mapping() to run across
 different pgtable
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-5-kernelfans@gmail.com>

__create_pgd_mapping() is planned not only to be used in boot process,
but also after fully bootup. The latter means several callers can run
__create_pgd_mapping() concurrenlty.

In this case, PUP/PMD/PTE fixmap should be not used, instead, the
virtual addresss owned by each pgtable is used.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org

---
rfc -> v2:
  change allocator return type back to phys_addr_t
---
 arch/arm64/mm/mmu_include.c | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 732e603fe3fc..ac8850fe6ce2 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -7,6 +7,7 @@
 
 #define NO_BLOCK_MAPPINGS	BIT(0)
 #define NO_CONT_MAPPINGS	BIT(1)
+#define NO_FIXMAP	BIT(2)
 
 static bool pgattr_change_is_safe(u64 old, u64 new)
 {
@@ -43,11 +44,14 @@ static bool pgattr_change_is_safe(u64 old, u64 new)
 }
 
 static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
-		     phys_addr_t phys, pgprot_t prot)
+		     phys_addr_t phys, pgprot_t prot, int flags)
 {
 	pte_t *ptep;
 
-	ptep = pte_set_fixmap_offset(pmdp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		ptep = pte_set_fixmap_offset(pmdp, addr);
+	else
+		ptep = pte_offset_kernel(pmdp, addr);
 	do {
 		pte_t old_pte = READ_ONCE(*ptep);
 
@@ -63,7 +67,8 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		phys += PAGE_SIZE;
 	} while (ptep++, addr += PAGE_SIZE, addr != end);
 
-	pte_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pte_clear_fixmap();
 }
 
 static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
@@ -97,7 +102,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 		    (flags & NO_CONT_MAPPINGS) == 0)
 			__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
 
-		init_pte(pmdp, addr, next, phys, __prot);
+		init_pte(pmdp, addr, next, phys, __prot, flags);
 
 		phys += next - addr;
 	} while (addr = next, addr != end);
@@ -112,7 +117,10 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 	unsigned long next;
 	pmd_t *pmdp;
 
-	pmdp = pmd_set_fixmap_offset(pudp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		pmdp = pmd_set_fixmap_offset(pudp, addr);
+	else
+		pmdp = pmd_offset(pudp, addr);
 	do {
 		pmd_t old_pmd = READ_ONCE(*pmdp);
 
@@ -139,7 +147,8 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 		phys += next - addr;
 	} while (pmdp++, addr = next, addr != end);
 
-	pmd_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pmd_clear_fixmap();
 }
 
 static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
@@ -215,7 +224,10 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	}
 	BUG_ON(p4d_bad(p4d));
 
-	pudp = pud_set_fixmap_offset(p4dp, addr);
+	if (likely(!(flags & NO_FIXMAP)))
+		pudp = pud_set_fixmap_offset(p4dp, addr);
+	else
+		pudp = pud_offset(p4dp, addr);
 	do {
 		pud_t old_pud = READ_ONCE(*pudp);
 
@@ -244,7 +256,8 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 		phys += next - addr;
 	} while (pudp++, addr = next, addr != end);
 
-	pud_clear_fixmap();
+	if (likely(!(flags & NO_FIXMAP)))
+		pud_clear_fixmap();
 }
 
 static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_addr_t phys,
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:12:59 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:12:59 +0800
Subject: [PATCHv2 05/10] arm64/mm: port trans_pgd_idmap_page() onto
 create_idmap()
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-6-kernelfans@gmail.com>

At present, trans_pgd_idmap_page() has its own logic to set up idmap. To
share the common code, porting it onto create_idmap().

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h | 13 +++++++
 arch/arm64/mm/mmu_include.c      |  4 ---
 arch/arm64/mm/trans_pgd.c        | 62 ++++++++++++++++----------------
 3 files changed, 43 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 42f602528b90..8e6638b4d1dd 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -93,4 +93,17 @@ extern void __create_pgd_mapping_extend(pgd_t *pgdir,
 		void *info,
 		int flags);
 
+extern int idmap_extend_pgtable;
+
+extern void create_idmap(pgd_t *pgdir, phys_addr_t phys,
+		phys_addr_t size,
+		pgprot_t prot,
+		pgtable_alloc allocator,
+		void *info,
+		int flags);
+
+#define NO_BLOCK_MAPPINGS	BIT(0)
+#define NO_CONT_MAPPINGS	BIT(1)
+#define NO_FIXMAP	BIT(2)
+
 #endif
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index ac8850fe6ce2..98c560197ea9 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -5,10 +5,6 @@
  * and MMU-enable
  */
 
-#define NO_BLOCK_MAPPINGS	BIT(0)
-#define NO_CONT_MAPPINGS	BIT(1)
-#define NO_FIXMAP	BIT(2)
-
 static bool pgattr_change_is_safe(u64 old, u64 new)
 {
 	/*
diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c
index 527f0a39c3da..9f4512ab8659 100644
--- a/arch/arm64/mm/trans_pgd.c
+++ b/arch/arm64/mm/trans_pgd.c
@@ -274,6 +274,14 @@ int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
 	return 0;
 }
 
+static phys_addr_t allocator_trans_alloc(unsigned long unused, void *info)
+{
+	unsigned long *p;
+
+	p = trans_alloc(info);
+	return virt_to_phys(p);
+}
+
 /*
  * The page we want to idmap may be outside the range covered by VA_BITS that
  * can be built using the kernel's p?d_populate() helpers. As a one off, for a
@@ -287,38 +295,28 @@ int trans_pgd_map_page(struct trans_pgd_info *info, pgd_t *trans_pgd,
 int trans_pgd_idmap_page(struct trans_pgd_info *info, phys_addr_t *trans_ttbr0,
 			 unsigned long *t0sz, void *page)
 {
-	phys_addr_t dst_addr = virt_to_phys(page);
-	unsigned long pfn = __phys_to_pfn(dst_addr);
-	int max_msb = (dst_addr & GENMASK(52, 48)) ? 51 : 47;
-	int bits_mapped = PAGE_SHIFT - 4;
-	unsigned long level_mask, prev_level_entry, *levels[4];
-	int this_level, index, level_lsb, level_msb;
-
-	dst_addr &= PAGE_MASK;
-	prev_level_entry = pte_val(pfn_pte(pfn, PAGE_KERNEL_EXEC));
-
-	for (this_level = 3; this_level >= 0; this_level--) {
-		levels[this_level] = trans_alloc(info);
-		if (!levels[this_level])
-			return -ENOMEM;
-
-		level_lsb = ARM64_HW_PGTABLE_LEVEL_SHIFT(this_level);
-		level_msb = min(level_lsb + bits_mapped, max_msb);
-		level_mask = GENMASK_ULL(level_msb, level_lsb);
-
-		index = (dst_addr & level_mask) >> level_lsb;
-		*(levels[this_level] + index) = prev_level_entry;
-
-		pfn = virt_to_pfn(levels[this_level]);
-		prev_level_entry = pte_val(pfn_pte(pfn,
-						   __pgprot(PMD_TYPE_TABLE)));
-
-		if (level_msb == max_msb)
-			break;
-	}
-
-	*trans_ttbr0 = phys_to_ttbr(__pfn_to_phys(pfn));
-	*t0sz = TCR_T0SZ(max_msb + 1);
+	pgd_t *pgdir = trans_alloc(info);
+	unsigned long base, step, level, va_bits;
+	int flags = NO_FIXMAP;
+
+#ifdef CONFIG_ARM64_64K_PAGES
+	base = 16;
+	step = 13;
+#elif defined(CONFIG_ARM64_4K_PAGES)
+	base = 12;
+	step = 9;
+#elif defined(CONFIG_ARM64_16K_PAGES)
+	base = 14;
+	step = 11;
+#endif
+	create_idmap(pgdir, virt_to_phys(page), PAGE_SIZE, PAGE_KERNEL_EXEC,
+			allocator_trans_alloc, info, flags);
+
+	*trans_ttbr0 = phys_to_ttbr(__virt_to_phys(pgdir));
+	level = CONFIG_PGTABLE_LEVELS + idmap_extend_pgtable ? 1 : 0;
+	va_bits = base + step * level;
+	va_bits = min(va_bits, vabits_actual);
+	*t0sz = 64 - va_bits;
 
 	return 0;
 }
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:13:00 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:13:00 +0800
Subject: [PATCHv2 06/10] arm64/mm: introduce pgtable allocator for
 idmap_pg_dir and init_pg_dir
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-7-kernelfans@gmail.com>

>From the view of __create_pgd_mapping(), both idmap_pg_dir and
init_pg_dir can be treated as a memory pool.  Introduce an allocator
working on them, so __create_pgd_mapping() can create mapping.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/mm/mmu.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 520738c43874..fa1d1d4fee8f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -86,6 +86,28 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 }
 EXPORT_SYMBOL(phys_mem_access_prot);
 
+struct mempool {
+	phys_addr_t start;
+	unsigned long size;
+	unsigned long next_idx;
+};
+
+struct mempool cur_pool;
+
+void set_cur_mempool(phys_addr_t start, unsigned long size)
+{
+	cur_pool.start = start;
+	cur_pool.size = size;
+	cur_pool.next_idx = 0;
+}
+
+phys_addr_t __init head_pgtable_alloc(unsigned long unused_a, void *unused_b)
+{
+	unsigned long idx = cur_pool.next_idx++;
+
+	return cur_pool.start + (idx << PAGE_SHIFT);
+}
+
 static phys_addr_t __init early_pgtable_alloc(unsigned long unused_a, void *unused_b)
 {
 	phys_addr_t phys;
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:13:01 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:13:01 +0800
Subject: [PATCHv2 07/10] arm64/pgtable-prot.h: reorganize to cope with asm
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-8-kernelfans@gmail.com>

This patch is one of the preparation for calling __create_pgd_mapping()
from head.S.

In order to refer PAGE_KERNEL_EXEC in head.S, reorganize this file and
move the needed part under #ifdef __ASSEMBLY__

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgtable-prot.h | 34 +++++++++++++++++----------
 1 file changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 9a65fb528110..424fc5e6fd69 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -33,9 +33,6 @@
 
 extern bool arm64_use_ng_mappings;
 
-#define _PROT_DEFAULT		(PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
-#define _PROT_SECT_DEFAULT	(PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
-
 #define PTE_MAYBE_NG		(arm64_use_ng_mappings ? PTE_NG : 0)
 #define PMD_MAYBE_NG		(arm64_use_ng_mappings ? PMD_SECT_NG : 0)
 
@@ -49,6 +46,26 @@ extern bool arm64_use_ng_mappings;
 #define PTE_MAYBE_GP		0
 #endif
 
+#define PAGE_S2_MEMATTR(attr)						\
+	({								\
+		u64 __val;						\
+		if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))		\
+			__val = PTE_S2_MEMATTR(MT_S2_FWB_ ## attr);	\
+		else							\
+			__val = PTE_S2_MEMATTR(MT_S2_ ## attr);		\
+		__val;							\
+	 })
+
+#endif /* __ASSEMBLY__ */
+
+#ifdef __ASSEMBLY__
+#define PTE_MAYBE_NG	0
+#define __pgprot(x)	(x)
+#endif
+
+#define _PROT_DEFAULT		(PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
+#define _PROT_SECT_DEFAULT	(PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
+
 #define PROT_DEFAULT		(_PROT_DEFAULT | PTE_MAYBE_NG)
 #define PROT_SECT_DEFAULT	(_PROT_SECT_DEFAULT | PMD_MAYBE_NG)
 
@@ -71,15 +88,7 @@ extern bool arm64_use_ng_mappings;
 #define PAGE_KERNEL_EXEC	__pgprot(PROT_NORMAL & ~PTE_PXN)
 #define PAGE_KERNEL_EXEC_CONT	__pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT)
 
-#define PAGE_S2_MEMATTR(attr)						\
-	({								\
-		u64 __val;						\
-		if (cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))		\
-			__val = PTE_S2_MEMATTR(MT_S2_FWB_ ## attr);	\
-		else							\
-			__val = PTE_S2_MEMATTR(MT_S2_ ## attr);		\
-		__val;							\
-	 })
+
 
 #define PAGE_NONE		__pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
 /* shared+writable pages are clean by default, hence PTE_RDONLY|PTE_WRITE */
@@ -106,6 +115,5 @@ extern bool arm64_use_ng_mappings;
 #define __S110  PAGE_SHARED_EXEC
 #define __S111  PAGE_SHARED_EXEC
 
-#endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_PROT_H */
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:13:02 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:13:02 +0800
Subject: [PATCHv2 08/10] arm64/mmu_include.c: disable WARN_ON() and BUG_ON()
 when booting.
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-9-kernelfans@gmail.com>

This patch is still one of the preparation for calling
__create_pgd_mapping() from head.S

When calling from head.S, printk is not ready to work. Hence define
SAFE_BUG_ON()/SAFE_WARN_ON(), wrapping around BUG_ON()/WARN_ON() to
protect against early calling.

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/include/asm/pgalloc.h |  1 +
 arch/arm64/mm/mmu_include.c      | 36 +++++++++++++++++++-------------
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 8e6638b4d1dd..c3875af99432 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -105,5 +105,6 @@ extern void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 #define NO_BLOCK_MAPPINGS	BIT(0)
 #define NO_CONT_MAPPINGS	BIT(1)
 #define NO_FIXMAP	BIT(2)
+#define BOOT_HEAD	BIT(3)
 
 #endif
diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 98c560197ea9..746cb2b502a3 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -5,6 +5,14 @@
  * and MMU-enable
  */
 
+/*
+ * printk is not ready in the very early stage. And this pair macro should be used
+ * instead
+ */
+#define SAFE_BUG_ON(x, y)	if (likely(!(x & BOOT_HEAD))) { BUG_ON(y); }
+#define SAFE_WARN_ON(x, y)	\
+	({ int _ret; _ret = (x & BOOT_HEAD) ? false : WARN_ON(y); })
+
 static bool pgattr_change_is_safe(u64 old, u64 new)
 {
 	/*
@@ -57,7 +65,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 		 * After the PTE entry has been populated once, we
 		 * only allow updates to the permission attributes.
 		 */
-		BUG_ON(!pgattr_change_is_safe(pte_val(old_pte),
+		SAFE_BUG_ON(flags, !pgattr_change_is_safe(pte_val(old_pte),
 					      READ_ONCE(pte_val(*ptep))));
 
 		phys += PAGE_SIZE;
@@ -77,16 +85,16 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
 	unsigned long next;
 	pmd_t pmd = READ_ONCE(*pmdp);
 
-	BUG_ON(pmd_sect(pmd));
+	SAFE_BUG_ON(flags, pmd_sect(pmd));
 	if (pmd_none(pmd)) {
 		phys_addr_t pte_phys;
 
-		BUG_ON(!allocator);
+		SAFE_BUG_ON(flags, !allocator);
 		pte_phys = allocator(PAGE_SHIFT, info);
 		__pmd_populate(pmdp, pte_phys, PMD_TYPE_TABLE);
 		pmd = READ_ONCE(*pmdp);
 	}
-	BUG_ON(pmd_bad(pmd));
+	SAFE_BUG_ON(flags, pmd_bad(pmd));
 
 	do {
 		pgprot_t __prot = prot;
@@ -131,13 +139,13 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 			 * After the PMD entry has been populated once, we
 			 * only allow updates to the permission attributes.
 			 */
-			BUG_ON(!pgattr_change_is_safe(pmd_val(old_pmd),
+			SAFE_BUG_ON(flags, !pgattr_change_is_safe(pmd_val(old_pmd),
 						      READ_ONCE(pmd_val(*pmdp))));
 		} else {
 			alloc_init_cont_pte(pmdp, addr, next, phys, prot,
 					    allocator, info, flags);
 
-			BUG_ON(pmd_val(old_pmd) != 0 &&
+			SAFE_BUG_ON(flags, pmd_val(old_pmd) != 0 &&
 			       pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
 		}
 		phys += next - addr;
@@ -160,16 +168,16 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
 	/*
 	 * Check for initial section mappings in the pgd/pud.
 	 */
-	BUG_ON(pud_sect(pud));
+	SAFE_BUG_ON(flags, pud_sect(pud));
 	if (pud_none(pud)) {
 		phys_addr_t pmd_phys;
 
-		BUG_ON(!allocator);
+		SAFE_BUG_ON(flags, !allocator);
 		pmd_phys = allocator(PMD_SHIFT, info);
 		__pud_populate(pudp, pmd_phys, PUD_TYPE_TABLE);
 		pud = READ_ONCE(*pudp);
 	}
-	BUG_ON(pud_bad(pud));
+	SAFE_BUG_ON(flags, pud_bad(pud));
 
 	do {
 		pgprot_t __prot = prot;
@@ -213,12 +221,12 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	if (p4d_none(p4d)) {
 		phys_addr_t pud_phys;
 
-		BUG_ON(!allocator);
+		SAFE_BUG_ON(flags, !allocator);
 		pud_phys = allocator(PUD_SHIFT, info);
 		__p4d_populate(p4dp, pud_phys, PUD_TYPE_TABLE);
 		p4d = READ_ONCE(*p4dp);
 	}
-	BUG_ON(p4d_bad(p4d));
+	SAFE_BUG_ON(flags, p4d_bad(p4d));
 
 	if (likely(!(flags & NO_FIXMAP)))
 		pudp = pud_set_fixmap_offset(p4dp, addr);
@@ -240,13 +248,13 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 			 * After the PUD entry has been populated once, we
 			 * only allow updates to the permission attributes.
 			 */
-			BUG_ON(!pgattr_change_is_safe(pud_val(old_pud),
+			SAFE_BUG_ON(flags, !pgattr_change_is_safe(pud_val(old_pud),
 						      READ_ONCE(pud_val(*pudp))));
 		} else {
 			alloc_init_cont_pmd(pudp, addr, next, phys, prot,
 					    allocator, info, flags);
 
-			BUG_ON(pud_val(old_pud) != 0 &&
+			SAFE_BUG_ON(flags, pud_val(old_pud) != 0 &&
 			       pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
 		}
 		phys += next - addr;
@@ -275,7 +283,7 @@ static void __create_pgd_mapping(pgd_t *pgdir, unsigned int entries_cnt, phys_ad
 	 * If the virtual and physical address don't have the same offset
 	 * within a page, we cannot map the region as the caller expects.
 	 */
-	if (WARN_ON((phys ^ virt) & ~PAGE_MASK))
+	if (SAFE_WARN_ON(flags, (phys ^ virt) & ~PAGE_MASK))
 		return;
 
 	phys &= PAGE_MASK;
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:13:03 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:13:03 +0800
Subject: [PATCHv2 09/10] arm64/mm: make __create_pgd_mapping() coped with
 pgtable's paddr
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-10-kernelfans@gmail.com>

This patch is the last preparation for calling __create_pgd_mapping()
from head.S.

Under mmu-offset situation, pud_t */pmd_t */pte_t * points to paddr.
During the building of pgtable, they should be carefully handled to
avoid the involvement of __va().

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm64/mm/mmu_include.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/mm/mmu_include.c b/arch/arm64/mm/mmu_include.c
index 746cb2b502a3..c4ea00bae4df 100644
--- a/arch/arm64/mm/mmu_include.c
+++ b/arch/arm64/mm/mmu_include.c
@@ -54,6 +54,9 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
 
 	if (likely(!(flags & NO_FIXMAP)))
 		ptep = pte_set_fixmap_offset(pmdp, addr);
+	else if (flags & BOOT_HEAD)
+		/* for head.S, there is no __va() */
+		ptep = (pte_t *)__pmd_to_phys(*pmdp) + pte_index(addr);
 	else
 		ptep = pte_offset_kernel(pmdp, addr);
 	do {
@@ -121,10 +124,19 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
 	unsigned long next;
 	pmd_t *pmdp;
 
-	if (likely(!(flags & NO_FIXMAP)))
+	if (likely(!(flags & NO_FIXMAP))) {
 		pmdp = pmd_set_fixmap_offset(pudp, addr);
-	else
+	} else if (flags & BOOT_HEAD) {
+#if CONFIG_PGTABLE_LEVELS > 2
+		/* for head.S, there is no __va() */
+		pmdp = (pmd_t *)__pud_to_phys(*pudp) + pmd_index(addr);
+#else
+		pmdp = (pmd_t *)pudp;
+#endif
+	} else {
 		pmdp = pmd_offset(pudp, addr);
+	}
+
 	do {
 		pmd_t old_pmd = READ_ONCE(*pmdp);
 
@@ -228,10 +240,19 @@ static void alloc_init_pud(pgd_t *pgdp, unsigned long addr, unsigned long end,
 	}
 	SAFE_BUG_ON(flags, p4d_bad(p4d));
 
-	if (likely(!(flags & NO_FIXMAP)))
+	if (likely(!(flags & NO_FIXMAP))) {
 		pudp = pud_set_fixmap_offset(p4dp, addr);
-	else
+	} else if (flags & BOOT_HEAD) {
+#if CONFIG_PGTABLE_LEVELS > 3
+		/* for head.S, there is no __va() */
+		pudp = (pud_t *)__p4d_to_phys(*p4dp) + pud_index(addr);
+#else
+		pudp = (pud_t *)p4dp;
+#endif
+	} else {
 		pudp = pud_offset(p4dp, addr);
+	}
+
 	do {
 		pud_t old_pud = READ_ONCE(*pudp);
 
-- 
2.29.2



From kernelfans at gmail.com  Sun Apr 25 15:13:04 2021
From: kernelfans at gmail.com (Pingfan Liu)
Date: Sun, 25 Apr 2021 22:13:04 +0800
Subject: [PATCHv2 10/10] arm64/head: convert idmap_pg_dir and init_pg_dir to
 __create_pgd_mapping()
In-Reply-To: <20210425141304.32721-1-kernelfans@gmail.com>
References: <20210425141304.32721-1-kernelfans@gmail.com>
Message-ID: <20210425141304.32721-11-kernelfans@gmail.com>

Now, everything is ready for calling __create_pgd_mapping() from head.S.
Switching to these C routine and remove the asm counterpart.

This patch has been successfully tested with the following config value:
    PAGE_SIZE  VA  PA  PGTABLE_LEVEL
    4K         48  48  4
    4K         39  48  3
    16K        48  48  4
    16K        47  48  3
    64K        52  52  3
    64K        42  52  2

Signed-off-by: Pingfan Liu <kernelfans at gmail.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Kristina Martsenko <kristina.martsenko at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Steven Price <steven.price at arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron at huawei.com>
Cc: Pavel Tatashin <pasha.tatashin at soleen.com>
Cc: Anshuman Khandual <anshuman.khandual at arm.com>
Cc: Atish Patra <atish.patra at wdc.com>
Cc: Mike Rapoport <rppt at kernel.org>
Cc: Logan Gunthorpe <logang at deltatee.com>
Cc: Mark Brown <broonie at kernel.org>
To: linux-arm-kernel at lists.infradead.org

---
RFC -> V2:
    correct the asm calling convention.
---
 arch/arm64/include/asm/pgalloc.h |   5 +
 arch/arm64/kernel/head.S         | 193 ++++++++-----------------------
 arch/arm64/mm/mmu.c              |  13 +++
 3 files changed, 66 insertions(+), 145 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index c3875af99432..b1182b656b00 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -8,6 +8,9 @@
 #ifndef __ASM_PGALLOC_H
 #define __ASM_PGALLOC_H
 
+#include <vdso/bits.h>
+
+#ifndef __ASSEMBLY__
 #include <asm/pgtable-hwdef.h>
 #include <asm/processor.h>
 #include <asm/cacheflush.h>
@@ -102,6 +105,8 @@ extern void create_idmap(pgd_t *pgdir, phys_addr_t phys,
 		void *info,
 		int flags);
 
+#endif
+
 #define NO_BLOCK_MAPPINGS	BIT(0)
 #define NO_CONT_MAPPINGS	BIT(1)
 #define NO_FIXMAP	BIT(2)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index e19649dbbafb..ddb9601d61c2 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -28,6 +28,8 @@
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/page.h>
+#include <asm/pgtable-prot.h>
+#include <asm/pgalloc.h>
 #include <asm/scs.h>
 #include <asm/smp.h>
 #include <asm/sysreg.h>
@@ -92,6 +94,8 @@ SYM_CODE_START(primary_entry)
 	bl	init_kernel_el			// w0=cpu_boot_mode
 	adrp	x23, __PHYS_OFFSET
 	and	x23, x23, MIN_KIMG_ALIGN - 1	// KASLR offset, defaults to 0
+	adrp	x4, init_thread_union
+	add	sp, x4, #THREAD_SIZE
 	bl	set_cpu_boot_mode_flag
 	bl	__create_page_tables
 	/*
@@ -121,135 +125,6 @@ SYM_CODE_START_LOCAL(preserve_boot_args)
 	b	__inval_dcache_area		// tail call
 SYM_CODE_END(preserve_boot_args)
 
-/*
- * Macro to create a table entry to the next page.
- *
- *	tbl:	page table address
- *	virt:	virtual address
- *	shift:	#imm page table shift
- *	ptrs:	#imm pointers per table page
- *
- * Preserves:	virt
- * Corrupts:	ptrs, tmp1, tmp2
- * Returns:	tbl -> next level table page address
- */
-	.macro	create_table_entry, tbl, virt, shift, ptrs, tmp1, tmp2
-	add	\tmp1, \tbl, #PAGE_SIZE
-	phys_to_pte \tmp2, \tmp1
-	orr	\tmp2, \tmp2, #PMD_TYPE_TABLE	// address of next table and entry type
-	lsr	\tmp1, \virt, #\shift
-	sub	\ptrs, \ptrs, #1
-	and	\tmp1, \tmp1, \ptrs		// table index
-	str	\tmp2, [\tbl, \tmp1, lsl #3]
-	add	\tbl, \tbl, #PAGE_SIZE		// next level table page
-	.endm
-
-/*
- * Macro to populate page table entries, these entries can be pointers to the next level
- * or last level entries pointing to physical memory.
- *
- *	tbl:	page table address
- *	rtbl:	pointer to page table or physical memory
- *	index:	start index to write
- *	eindex:	end index to write - [index, eindex] written to
- *	flags:	flags for pagetable entry to or in
- *	inc:	increment to rtbl between each entry
- *	tmp1:	temporary variable
- *
- * Preserves:	tbl, eindex, flags, inc
- * Corrupts:	index, tmp1
- * Returns:	rtbl
- */
-	.macro populate_entries, tbl, rtbl, index, eindex, flags, inc, tmp1
-.Lpe\@:	phys_to_pte \tmp1, \rtbl
-	orr	\tmp1, \tmp1, \flags	// tmp1 = table entry
-	str	\tmp1, [\tbl, \index, lsl #3]
-	add	\rtbl, \rtbl, \inc	// rtbl = pa next level
-	add	\index, \index, #1
-	cmp	\index, \eindex
-	b.ls	.Lpe\@
-	.endm
-
-/*
- * Compute indices of table entries from virtual address range. If multiple entries
- * were needed in the previous page table level then the next page table level is assumed
- * to be composed of multiple pages. (This effectively scales the end index).
- *
- *	vstart:	virtual address of start of range
- *	vend:	virtual address of end of range
- *	shift:	shift used to transform virtual address into index
- *	ptrs:	number of entries in page table
- *	istart:	index in table corresponding to vstart
- *	iend:	index in table corresponding to vend
- *	count:	On entry: how many extra entries were required in previous level, scales
- *			  our end index.
- *		On exit: returns how many extra entries required for next page table level
- *
- * Preserves:	vstart, vend, shift, ptrs
- * Returns:	istart, iend, count
- */
-	.macro compute_indices, vstart, vend, shift, ptrs, istart, iend, count
-	lsr	\iend, \vend, \shift
-	mov	\istart, \ptrs
-	sub	\istart, \istart, #1
-	and	\iend, \iend, \istart	// iend = (vend >> shift) & (ptrs - 1)
-	mov	\istart, \ptrs
-	mul	\istart, \istart, \count
-	add	\iend, \iend, \istart	// iend += (count - 1) * ptrs
-					// our entries span multiple tables
-
-	lsr	\istart, \vstart, \shift
-	mov	\count, \ptrs
-	sub	\count, \count, #1
-	and	\istart, \istart, \count
-
-	sub	\count, \iend, \istart
-	.endm
-
-/*
- * Map memory for specified virtual address range. Each level of page table needed supports
- * multiple entries. If a level requires n entries the next page table level is assumed to be
- * formed from n pages.
- *
- *	tbl:	location of page table
- *	rtbl:	address to be used for first level page table entry (typically tbl + PAGE_SIZE)
- *	vstart:	start address to map
- *	vend:	end address to map - we map [vstart, vend]
- *	flags:	flags to use to map last level entries
- *	phys:	physical address corresponding to vstart - physical memory is contiguous
- *	pgds:	the number of pgd entries
- *
- * Temporaries:	istart, iend, tmp, count, sv - these need to be different registers
- * Preserves:	vstart, vend, flags
- * Corrupts:	tbl, rtbl, istart, iend, tmp, count, sv
- */
-	.macro map_memory, tbl, rtbl, vstart, vend, flags, phys, pgds, istart, iend, tmp, count, sv
-	add \rtbl, \tbl, #PAGE_SIZE
-	mov \sv, \rtbl
-	mov \count, #0
-	compute_indices \vstart, \vend, #PGDIR_SHIFT, \pgds, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-	mov \sv, \rtbl
-
-#if SWAPPER_PGTABLE_LEVELS > 3
-	compute_indices \vstart, \vend, #PUD_SHIFT, #PTRS_PER_PUD, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-	mov \sv, \rtbl
-#endif
-
-#if SWAPPER_PGTABLE_LEVELS > 2
-	compute_indices \vstart, \vend, #SWAPPER_TABLE_SHIFT, #PTRS_PER_PMD, \istart, \iend, \count
-	populate_entries \tbl, \rtbl, \istart, \iend, #PMD_TYPE_TABLE, #PAGE_SIZE, \tmp
-	mov \tbl, \sv
-#endif
-
-	compute_indices \vstart, \vend, #SWAPPER_BLOCK_SHIFT, #PTRS_PER_PTE, \istart, \iend, \count
-	bic \count, \phys, #SWAPPER_BLOCK_SIZE - 1
-	populate_entries \tbl, \count, \istart, \iend, \flags, #SWAPPER_BLOCK_SIZE, \tmp
-	.endm
-
 /*
  * Setup the initial page tables. We only setup the barest amount which is
  * required to get the kernel running. The following sections are required:
@@ -345,8 +220,6 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	mov	x5, #1
 	str	x5, [x4]                //require expanded pagetable
 
-	mov	x4, EXTRA_PTRS
-	create_table_entry x0, x3, EXTRA_SHIFT, x4, x5, x6
 #else
 	/*
 	 * If VA_BITS == 48, we don't have to configure an additional
@@ -356,25 +229,55 @@ SYM_FUNC_START_LOCAL(__create_page_tables)
 	str_l	x4, idmap_ptrs_per_pgd, x5
 #endif
 1:
-	ldr_l	x4, idmap_ptrs_per_pgd
-	mov	x5, x3				// __pa(__idmap_text_start)
-	adr_l	x6, __idmap_text_end		// __pa(__idmap_text_end)
-
-	map_memory x0, x1, x3, x6, x7, x3, x4, x10, x11, x12, x13, x14
+	stp     x0, x1, [sp, #-64]!
+	stp     x2, x3, [sp, #48]
+	stp     x4, x5, [sp, #32]
+	stp     x6, x7, [sp, #16]
+
+	adrp    x0, idmap_pg_dir
+	adrp    x1, idmap_pg_end
+	sub     x1, x1, x0
+	bl      set_cur_mempool
+	mov	x0, #0
+	mov	x0, #0
+	bl	head_pgtable_alloc	// x0 contains idmap_pg_dir
+
+	adrp    x1, __idmap_text_start
+	adr_l   x2, __idmap_text_end
+	sub     x2, x2, x1
+	ldr     x3, =PAGE_KERNEL_EXEC
+	adr_l   x4, head_pgtable_alloc
+	mov     x5, #0
+	mov     x6, #(NO_FIXMAP | BOOT_HEAD)
+	bl      create_idmap
 
 	/*
 	 * Map the kernel image (starting with PHYS_OFFSET).
 	 */
 	adrp	x0, init_pg_dir
-	mov_q	x5, KIMAGE_VADDR		// compile time __va(_text)
-	add	x5, x5, x23			// add KASLR displacement
-	mov	x4, PTRS_PER_PGD
-	adrp	x6, _end			// runtime __pa(_end)
-	adrp	x3, _text			// runtime __pa(_text)
-	sub	x6, x6, x3			// _end - _text
-	add	x6, x6, x5			// runtime __va(_end)
-
-	map_memory x0, x1, x5, x6, x7, x3, x4, x10, x11, x12, x13, x14
+	adrp	x1, init_pg_end
+	sub	x1, x1, x0
+	bl	set_cur_mempool
+	mov	x0, #0
+	mov	x0, #0
+	bl	head_pgtable_alloc		// x0 is init_pg_dir
+
+	adrp	x1, _text			// runtime __pa(_text)
+	mov_q	x2, KIMAGE_VADDR		// compile time __va(_text)
+	add	x2, x2, x23			// add KASLR displacement
+	adrp	x3, _end			// runtime __pa(_end)
+	sub	x3, x3, x1			// _end - _text
+
+	ldr	x4, =PAGE_KERNEL_EXEC
+	adr_l	x5, head_pgtable_alloc
+	mov	x6, #0
+	mov	x7, #(NO_FIXMAP | BOOT_HEAD)
+
+	bl	create_init_pgd_mapping
+	ldp	x6, x7, [sp, #16]
+	ldp	x4, x5, [sp, #32]
+	ldp	x2, x3, [sp, #48]
+	ldp	x0, x1, [sp], #64
 
 	/*
 	 * Since the page tables have been populated with non-cacheable
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index fa1d1d4fee8f..1ae72a3f2d27 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -167,6 +167,19 @@ static phys_addr_t pgd_pgtable_alloc(unsigned long shift, void *unused)
 
 #include "./mmu_include.c"
 
+void create_init_pgd_mapping(pgd_t *pgdir,
+		phys_addr_t phys,
+		unsigned long virt,
+		phys_addr_t size,
+		pgprot_t prot,
+		pgtable_alloc allocator,
+		void* info,
+		int flags)
+{
+	__create_pgd_mapping(pgdir, PTRS_PER_PGD, phys, virt, size,
+		prot, allocator, info, flags);
+}
+
 int idmap_extend_pgtable;
 
 /*
-- 
2.29.2



From dariobin at libero.it  Sun Apr 25 15:22:08 2021
From: dariobin at libero.it (Dario Binacchi)
Date: Sun, 25 Apr 2021 16:22:08 +0200
Subject: [RESEND PATCH] ARM: OMAP2+: CM: remove omap2_set_globals_cm()
Message-ID: <20210425142208.20159-1-dariobin@libero.it>

The function is no longer used, so let's remove it.

Signed-off-by: Dario Binacchi <dariobin at libero.it>

---

 arch/arm/mach-omap2/cm.h        |  1 -
 arch/arm/mach-omap2/cm_common.c | 13 -------------
 2 files changed, 14 deletions(-)

diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index d02fe63dab59..14beb59e5f7b 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -26,7 +26,6 @@
 
 extern struct omap_domain_base cm_base;
 extern struct omap_domain_base cm2_base;
-extern void omap2_set_globals_cm(void __iomem *cm, void __iomem *cm2);
 # endif
 
 /*
diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
index b7ea609386d5..e2d069fe67f1 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -37,19 +37,6 @@ struct omap_domain_base cm2_base;
 #define CM_NO_CLOCKS		0x1
 #define CM_SINGLE_INSTANCE	0x2
 
-/**
- * omap2_set_globals_cm - set the CM/CM2 base addresses (for early use)
- * @cm: CM base virtual address
- * @cm2: CM2 base virtual address (if present on the booted SoC)
- *
- * XXX Will be replaced when the PRM/CM drivers are completed.
- */
-void __init omap2_set_globals_cm(void __iomem *cm, void __iomem *cm2)
-{
-	cm_base.va = cm;
-	cm2_base.va = cm2;
-}
-
 /**
  * cm_split_idlest_reg - split CM_IDLEST reg addr into its components
  * @idlest_reg: CM_IDLEST* virtual address
-- 
2.17.1



From dariobin at libero.it  Sun Apr 25 15:23:30 2021
From: dariobin at libero.it (Dario Binacchi)
Date: Sun, 25 Apr 2021 16:23:30 +0200
Subject: [RESEND PATCH] ARM: OMAP2+: remove omap2_set_globals_control()
Message-ID: <20210425142331.20268-1-dariobin@libero.it>

The function is no longer used, so let's remove it.

Signed-off-by: Dario Binacchi <dariobin at libero.it>


---

 arch/arm/mach-omap2/control.c | 5 -----
 arch/arm/mach-omap2/control.h | 1 -
 2 files changed, 6 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 73338cf80d76..062d431fc33a 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -136,11 +136,6 @@ struct omap3_control_regs {
 static struct omap3_control_regs control_context;
 #endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
 
-void __init omap2_set_globals_control(void __iomem *ctrl)
-{
-	omap2_ctrl_base = ctrl;
-}
-
 u8 omap_ctrl_readb(u16 offset)
 {
 	u32 val;
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index eceb4b09adb2..c4ca30ba1790 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -528,7 +528,6 @@ extern int omap3_ctrl_save_padconf(void);
 void omap3_ctrl_init(void);
 int omap2_control_base_init(void);
 int omap_control_init(void);
-void omap2_set_globals_control(void __iomem *ctrl);
 void __init omap3_control_legacy_iomap_init(void);
 #else
 #define omap_ctrl_readb(x)		0
-- 
2.17.1



From pali at kernel.org  Sun Apr 25 16:21:55 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Sun, 25 Apr 2021 17:21:55 +0200
Subject: [PATCH] arm64: dts: marvell: armada-37xx: Set linux,pci-domain
 to zero
In-Reply-To: <CAL_Jsq+fNGQ+qMuqQ_c1Nou1h4R=-R5sn2n0p7rx==+e2JybSg@mail.gmail.com>
References: <20210412123936.25555-1-pali@kernel.org>
 <CAL_JsqLSse=W3TFu=Wc=eEAV4fKDGfsQ6JUvO3KyG_pnGTVg6A@mail.gmail.com>
 <20210415083640.ntg6kv6ayppxldgd@pali>
 <20210415104537.403de52e@thinkpad>
 <CAL_JsqL2gjprb3MDv8KPSpe0CUBFjGajnMbF71DM+F9Yewp2uw@mail.gmail.com>
 <20210417144953.pznysgn5rdraxggx@pali>
 <CAL_Jsq+fNGQ+qMuqQ_c1Nou1h4R=-R5sn2n0p7rx==+e2JybSg@mail.gmail.com>
Message-ID: <20210425152155.mstuxndsoqdbdape@pali>

On Friday 23 April 2021 10:33:38 Rob Herring wrote:
> On Sat, Apr 17, 2021 at 9:49 AM Pali Roh?r <pali at kernel.org> wrote:
> >
> > On Thursday 15 April 2021 10:13:17 Rob Herring wrote:
> > > On Thu, Apr 15, 2021 at 3:45 AM Marek Behun <marek.behun at nic.cz> wrote:
> > > >
> > > > On Thu, 15 Apr 2021 10:36:40 +0200
> > > > Pali Roh?r <pali at kernel.org> wrote:
> > > >
> > > > > On Tuesday 13 April 2021 13:17:29 Rob Herring wrote:
> > > > > > On Mon, Apr 12, 2021 at 7:41 AM Pali Roh?r <pali at kernel.org> wrote:
> > > > > > >
> > > > > > > Since commit 526a76991b7b ("PCI: aardvark: Implement driver 'remove'
> > > > > > > function and allow to build it as module") PCIe controller driver for
> > > > > > > Armada 37xx can be dynamically loaded and unloaded at runtime. Also driver
> > > > > > > allows dynamic binding and unbinding of PCIe controller device.
> > > > > > >
> > > > > > > Kernel PCI subsystem assigns by default dynamically allocated PCI domain
> > > > > > > number (starting from zero) for this PCIe controller every time when device
> > > > > > > is bound. So PCI domain changes after every unbind / bind operation.
> > > > > >
> > > > > > PCI host bridges as a module are relatively new, so seems likely a bug to me.
> > > > >
> > > > > Why a bug? It is there since 5.10 and it is working.
> > >
> > > I mean historically, the PCI subsystem didn't even support host
> > > bridges as a module. They weren't even proper drivers and it was all
> > > arch specific code. Most of the host bridge drivers are still built-in
> > > only. This seems like a small detail that was easily overlooked.
> > > unbind is not a well tested path.
> >
> > Ok! Just to note that during my testing I have not spotted any issue.
> >
> > > > > > > Alternative way for assigning PCI domain number is to use static allocated
> > > > > > > numbers defined in Device Tree. This option has requirement that every PCI
> > > > > > > controller in system must have defined PCI bus number in Device Tree.
> > > > > >
> > > > > > That seems entirely pointless from a DT point of view with a single PCI bridge.
> > > > >
> > > > > If domain id is not specified in DT then kernel uses counter and assigns
> > > > > counter++. So it is not pointless if we want to have stable domain id.
> > > >
> > > > What Rob is trying to say is that
> > > > - the bug is that kernel assigns counter++
> > > > - device-tree should not be used to fix problems with how kernel does
> > > >   things
> > > > - if a device has only one PCIe controller, it is pointless to define
> > > >   it's pci-domain. If there were multiple controllers, then it would
> > > >   make sense, but there is only one
> > >
> > > Yes. I think what we want here is a domain bitmap rather than a
> > > counter and we assign the lowest free bit. That could also allow for
> > > handling a mixture of fixed domain numbers and dynamically assigned
> > > ones.
> >
> > Currently this code is implemented in pci_bus_find_domain_nr() function.
> > IIRC domain number is 16bit integer, so plain bitmap would consume 8 kB
> > of memory. I'm not sure if it is fine or some other tree-based structure
> > for allocated domain numbers is needed.
> 
> It's an atomic_t but then shortened (potentially) to an 'int'. Surely
> we don't need 8k (or 2^31) host bridges? Seems like we could start
> with 64 and bump it as needed. Or the idr route is another option if
> that works. We'd need to get the lowest free value and be able to
> reserve values (when specified by firmware).

Seems that idr_alloc() supports both required operations as you can ask
idr_alloc() for allocating specific id (if is available).

> > > You could create scenarios where the numbers change on you, but it
> > > wouldn't be any different than say plugging in USB serial adapters.
> > > You get the same ttyUSBx device when you re-attach unless there's been
> > > other ttyUSBx devices attached/detached.
> >
> > This should be fine for most scenarios. Dynamically attaching /
> > detaching PCI domain is not such common action...
> >
> > Will you implement this new feature?
> 
> Yes, after I find a DT binding co-maintainer.
> 
> Rob


From rdunlap at infradead.org  Sun Apr 25 18:32:00 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Sun, 25 Apr 2021 10:32:00 -0700
Subject: [PATCH] pinctrl: aspeed: Fix minor documentation error
In-Reply-To: <1619353584-8196-1-git-send-email-jrdr.linux@gmail.com>
References: <1619353584-8196-1-git-send-email-jrdr.linux@gmail.com>
Message-ID: <6db04e41-3ee6-c569-34b2-83693b620362@infradead.org>

On 4/25/21 5:26 AM, Souptick Joarder wrote:
> Kernel test robot throws below warning ->
> 
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c:2705: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2614: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinctrl-aspeed.c:111: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinmux-aspeed.c:24: warning: This comment starts
> with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> 
> Fix minor documentation error.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Signed-off-by: Souptick Joarder <jrdr.linux at gmail.com>
> Cc: Randy Dunlap <rdunlap at infradead.org>

Reviewed-by: Randy Dunlap <rdunlap at infradead.org>

Thanks.

> ---
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 4 ++--
>  drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 4 ++--
>  drivers/pinctrl/aspeed/pinctrl-aspeed.c    | 3 ++-
>  drivers/pinctrl/aspeed/pinmux-aspeed.c     | 3 ++-
>  4 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 996ebcb..4c0d266 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -2702,8 +2702,8 @@ static int aspeed_g5_sig_expr_eval(struct aspeed_pinmux_data *ctx,
>  }
>  
>  /**
> - * Configure a pin's signal by applying an expression's descriptor state for
> - * all descriptors in the expression.
> + * aspeed_g5_sig_expr_set() - Configure a pin's signal by applying an
> + * expression's descriptor state for all descriptors in the expression.
>   *
>   * @ctx: The pinmux context
>   * @expr: The expression associated with the function whose signal is to be
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> index 5c1a109..eeab093 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
> @@ -2611,8 +2611,8 @@
>  };
>  
>  /**
> - * Configure a pin's signal by applying an expression's descriptor state for
> - * all descriptors in the expression.
> + * aspeed_g6_sig_expr_set() - Configure a pin's signal by applying an
> + * expression's descriptor state for all descriptors in the expression.
>   *
>   * @ctx: The pinmux context
>   * @expr: The expression associated with the function whose signal is to be
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 9c65d56..9bbfe5c 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -108,7 +108,8 @@ static int aspeed_sig_expr_disable(struct aspeed_pinmux_data *ctx,
>  }
>  
>  /**
> - * Disable a signal on a pin by disabling all provided signal expressions.
> + * aspeed_disable_sig() - Disable a signal on a pin by disabling all provided
> + * signal expressions.
>   *
>   * @ctx: The pinmux context
>   * @exprs: The list of signal expressions (from a priority level on a pin)
> diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.c b/drivers/pinctrl/aspeed/pinmux-aspeed.c
> index 57305ca..894e2ef 100644
> --- a/drivers/pinctrl/aspeed/pinmux-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinmux-aspeed.c
> @@ -21,7 +21,8 @@ static inline void aspeed_sig_desc_print_val(
>  }
>  
>  /**
> - * Query the enabled or disabled state of a signal descriptor
> + * aspeed_sig_desc_eval() - Query the enabled or disabled state of a signal
> + * descriptor.
>   *
>   * @desc: The signal descriptor of interest
>   * @enabled: True to query the enabled state, false to query disabled state
> 


-- 
~Randy



From krzysztof.kozlowski at canonical.com  Sun Apr 25 18:48:30 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Sun, 25 Apr 2021 19:48:30 +0200
Subject: [PATCH 1/2] thermal: imx_sc: add missing of_node_put for loop
 iteration
Message-ID: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>

Early exits from for_each_available_child_of_node() should decrement the
node reference counter.  Reported by Coccinelle:

  drivers/thermal/imx_sc_thermal.c:93:1-33: WARNING:
    Function "for_each_available_child_of_node" should have of_node_put() before return around line 97.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/thermal/imx_sc_thermal.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
index b01d28eca7ee..8d76dbfde6a9 100644
--- a/drivers/thermal/imx_sc_thermal.c
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -93,6 +93,7 @@ static int imx_sc_thermal_probe(struct platform_device *pdev)
 	for_each_available_child_of_node(np, child) {
 		sensor = devm_kzalloc(&pdev->dev, sizeof(*sensor), GFP_KERNEL);
 		if (!sensor) {
+			of_node_put(child);
 			of_node_put(sensor_np);
 			return -ENOMEM;
 		}
@@ -104,6 +105,7 @@ static int imx_sc_thermal_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev,
 				"failed to get valid sensor resource id: %d\n",
 				ret);
+			of_node_put(child);
 			break;
 		}
 
@@ -114,6 +116,7 @@ static int imx_sc_thermal_probe(struct platform_device *pdev)
 		if (IS_ERR(sensor->tzd)) {
 			dev_err(&pdev->dev, "failed to register thermal zone\n");
 			ret = PTR_ERR(sensor->tzd);
+			of_node_put(child);
 			break;
 		}
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Sun Apr 25 18:48:31 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Sun, 25 Apr 2021 19:48:31 +0200
Subject: [PATCH 2/2] thermal: sprd: add missing of_node_put for loop iteration
In-Reply-To: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>
References: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>
Message-ID: <20210425174831.164332-2-krzysztof.kozlowski@canonical.com>

Early exits from for_each_available_child_of_node() should decrement the
node reference counter.  Reported by Coccinelle:

  drivers/thermal/sprd_thermal.c:387:1-23: WARNING:
    Function "for_each_child_of_node" should have of_node_put() before goto around lines 391.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 drivers/thermal/sprd_thermal.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/thermal/sprd_thermal.c b/drivers/thermal/sprd_thermal.c
index 3682edb2f466..2778971aaf03 100644
--- a/drivers/thermal/sprd_thermal.c
+++ b/drivers/thermal/sprd_thermal.c
@@ -388,6 +388,7 @@ static int sprd_thm_probe(struct platform_device *pdev)
 		sen = devm_kzalloc(&pdev->dev, sizeof(*sen), GFP_KERNEL);
 		if (!sen) {
 			ret = -ENOMEM;
+			of_node_put(sen_child);
 			goto disable_clk;
 		}
 
@@ -397,12 +398,14 @@ static int sprd_thm_probe(struct platform_device *pdev)
 		ret = of_property_read_u32(sen_child, "reg", &sen->id);
 		if (ret) {
 			dev_err(&pdev->dev, "get sensor reg failed");
+			of_node_put(sen_child);
 			goto disable_clk;
 		}
 
 		ret = sprd_thm_sensor_calibration(sen_child, thm, sen);
 		if (ret) {
 			dev_err(&pdev->dev, "efuse cal analysis failed");
+			of_node_put(sen_child);
 			goto disable_clk;
 		}
 
@@ -416,6 +419,7 @@ static int sprd_thm_probe(struct platform_device *pdev)
 			dev_err(&pdev->dev, "register thermal zone failed %d\n",
 				sen->id);
 			ret = PTR_ERR(sen->tzd);
+			of_node_put(sen_child);
 			goto disable_clk;
 		}
 
-- 
2.25.1



From krzysztof.kozlowski at canonical.com  Sun Apr 25 18:49:45 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Sun, 25 Apr 2021 19:49:45 +0200
Subject: [PATCH] ARM: exynos: add missing of_node_put for loop iteration
Message-ID: <20210425174945.164612-1-krzysztof.kozlowski@canonical.com>

Early exits from for_each_compatible_node() should decrement the
node reference counter.  Reported by Coccinelle:

  arch/arm/mach-exynos/exynos.c:52:1-25: WARNING:
    Function "for_each_compatible_node" should have of_node_put() before break around line 58.

Fixes: b3205dea8fbf ("ARM: EXYNOS: Map SYSRAM through generic DT bindings")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
 arch/arm/mach-exynos/exynos.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 25b01da4771b..8b48326be9fd 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -55,6 +55,7 @@ void __init exynos_sysram_init(void)
 		sysram_base_addr = of_iomap(node, 0);
 		sysram_base_phys = of_translate_address(node,
 					   of_get_address(node, 0, NULL, NULL));
+		of_node_put(node);
 		break;
 	}
 
@@ -62,6 +63,7 @@ void __init exynos_sysram_init(void)
 		if (!of_device_is_available(node))
 			continue;
 		sysram_ns_base_addr = of_iomap(node, 0);
+		of_node_put(node);
 		break;
 	}
 }
-- 
2.25.1



From masahiroy at kernel.org  Sun Apr 25 18:57:32 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Mon, 26 Apr 2021 02:57:32 +0900
Subject: [PATCH 2/4] crypto: arm: use a pattern rule for generating *.S files
In-Reply-To: <20210425175734.1310191-1-masahiroy@kernel.org>
References: <20210425175734.1310191-1-masahiroy@kernel.org>
Message-ID: <20210425175734.1310191-2-masahiroy@kernel.org>

Unify similar build rules.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

 arch/arm/crypto/Makefile | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 51f160c61740..eafa898ba6a7 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -48,13 +48,7 @@ curve25519-neon-y := curve25519-core.o curve25519-glue.o
 quiet_cmd_perl = PERL    $@
       cmd_perl = $(PERL) $(<) > $(@)
 
-$(obj)/poly1305-core.S: $(src)/poly1305-armv4.pl
-	$(call cmd,perl)
-
-$(obj)/sha256-core.S: $(src)/sha256-armv4.pl
-	$(call cmd,perl)
-
-$(obj)/sha512-core.S: $(src)/sha512-armv4.pl
+$(obj)/%-core.S: $(src)/%-armv4.pl
 	$(call cmd,perl)
 
 clean-files += poly1305-core.S sha256-core.S sha512-core.S
-- 
2.27.0



From masahiroy at kernel.org  Sun Apr 25 18:57:34 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Mon, 26 Apr 2021 02:57:34 +0900
Subject: [PATCH 4/4] crypto: arm64: use a pattern rule for generating *.S files
In-Reply-To: <20210425175734.1310191-1-masahiroy@kernel.org>
References: <20210425175734.1310191-1-masahiroy@kernel.org>
Message-ID: <20210425175734.1310191-4-masahiroy@kernel.org>

Unify similar build rules.

sha256-core.S opts out it because it is generated from sha512-armv8.pl.

Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
---

 arch/arm64/crypto/Makefile | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 592e52a08c62..09a805cc32d7 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -71,13 +71,10 @@ $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE
 quiet_cmd_perlasm = PERLASM $@
       cmd_perlasm = $(PERL) $(<) void $(@)
 
-$(obj)/poly1305-core.S: $(src)/poly1305-armv8.pl
+$(obj)/%-core.S: $(src)/%-armv8.pl
 	$(call cmd,perlasm)
 
 $(obj)/sha256-core.S: $(src)/sha512-armv8.pl
 	$(call cmd,perlasm)
 
-$(obj)/sha512-core.S: $(src)/sha512-armv8.pl
-	$(call cmd,perlasm)
-
 clean-files += poly1305-core.S sha256-core.S sha512-core.S
-- 
2.27.0



From arnd at arndb.de  Sun Apr 25 19:43:36 2021
From: arnd at arndb.de (Arnd Bergmann)
Date: Sun, 25 Apr 2021 20:43:36 +0200
Subject: [PATCH] ARM: exynos: add missing of_node_put for loop iteration
In-Reply-To: <20210425174945.164612-1-krzysztof.kozlowski@canonical.com>
References: <20210425174945.164612-1-krzysztof.kozlowski@canonical.com>
Message-ID: <CAK8P3a2piuYczrajMuHCf6qtqadKciVY2XqdxZ0mrRtCdz2f9w@mail.gmail.com>

On Sun, Apr 25, 2021 at 7:50 PM Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> Early exits from for_each_compatible_node() should decrement the
> node reference counter.  Reported by Coccinelle:
>
>   arch/arm/mach-exynos/exynos.c:52:1-25: WARNING:
>     Function "for_each_compatible_node" should have of_node_put() before break around line 58.
>
> Fixes: b3205dea8fbf ("ARM: EXYNOS: Map SYSRAM through generic DT bindings")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Acked-by: Arnd Bergmann <arnd at arndb.de>

I've already tagged the pull requests for 5.13, so I guess you can
just add this into
your next fixes branch.

       Arnd


From pavel at ucw.cz  Sun Apr 25 21:19:28 2021
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 25 Apr 2021 22:19:28 +0200
Subject: [PATCH v2 2/4] leds: Add driver for QCOM SPMI Flash LEDs
In-Reply-To: <7bb757c7-55af-66a4-aa12-fe646a19fcf6@gmail.com>
References: <20210126140240.1517044-1-nfraprado@protonmail.com>
 <20210126140240.1517044-3-nfraprado@protonmail.com>
 <a26a1d40-1c7c-b97c-2970-58a2fda8f1cf@gmail.com>
 <20210219110227.GG19207@duo.ucw.cz>
 <7bb757c7-55af-66a4-aa12-fe646a19fcf6@gmail.com>
Message-ID: <20210425201928.GA10996@amd>

Hi!

> >>>+#include <linux/kernel.h>
> >>>+#include <linux/module.h>
> >>>+#include <linux/spmi.h>
> >>>+#include <linux/of_device.h>
> >>>+#include <linux/device.h>
> >>>+#include <linux/types.h>
> >>>+#include <linux/string.h>
> >>>+#include <linux/mutex.h>
> >>>+#include <linux/sysfs.h>
> >>>+#include <linux/led-class-flash.h>
> >>>+#include <linux/regulator/consumer.h>
> >>>+#include <linux/delay.h>
> >>>+#include <linux/regmap.h>
> >>>+#include <dt-bindings/leds/leds-qcom-spmi-flash.h>
> >>
> >>Please sort includes alphabetically.
> >
> >No need to do that.
> 
> Keeping the includes sorted eliminates the risk of introducing duplicates
> and allows for faster lookup.
> 
> What gain is in having them unsorted?

It is not there is gain in them unsorted; it is that keeping sorted
order is not worth the effort.

> >>>+#define FLASH_SAFETY_TIMER		0x40
> >>
> >>Namespacing prefix is needed for macros, e.g. QCOM_FLASH*.
> >
> >No need for that in .c files.
> 
> In general it eliminates the risk of name clash with other subsystems
> headers.
> 
> And actually the prefix here should be QCOM_LED_FLASH to avoid ambiguity
> with flash memory. If you dropped the vendor prefix then you'd get
> possible name clash with led-class-flash.h namespace prefix.

I believe the cost (longer macro names) outweights the benefits here.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210425/3c8cb99a/attachment.sig>

From snawrocki at kernel.org  Sun Apr 25 21:57:25 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Sun, 25 Apr 2021 22:57:25 +0200
Subject: [PATCH 57/78] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <091915bb1cbec13b566d129f85ae229fcb92e2e4.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <091915bb1cbec13b566d129f85ae229fcb92e2e4.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <45068e81-8f9b-fea8-b7bc-bdd0443ba7e6@kernel.org>

On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>   drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
>   drivers/media/platform/exynos4-is/fimc-is.c        | 3 ++-
>   drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
>   drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
>   drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
>   drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
>   drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
>   drivers/media/platform/exynos4-is/mipi-csis.c      | 5 ++---
>   8 files changed, 17 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
> index 13c838d3f947..0da36443173c 100644
> --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> @@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
>   		goto unlock;
>   
>   	set_bit(ST_CAPT_BUSY, &fimc->state);
> -	ret = pm_runtime_get_sync(&fimc->pdev->dev);
> -	if (ret < 0) {
> -		pm_runtime_put_sync(&fimc->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
> +	if (ret < 0)
>   		goto unlock;
> -	}
>   
>   	ret = v4l2_fh_open(file);
>   	if (ret) {
> diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
> index 972d9601d236..bca35866cc74 100644
> --- a/drivers/media/platform/exynos4-is/fimc-is.c
> +++ b/drivers/media/platform/exynos4-is/fimc-is.c
> @@ -828,7 +828,7 @@ static int fimc_is_probe(struct platform_device *pdev)
>   			goto err_irq;
>   	}
>   
> -	ret = pm_runtime_get_sync(dev);
> +	ret = pm_runtime_resume_and_get(dev);
>   	if (ret < 0)
>   		goto err_pm;

It seems you intended to use err_suspend label here. We don't need
a new label though, instead of err_pm we can jump to err_irq when
pm_runtime_resume_and_get() fails. Note that when runtime PM is
disabled pm_runtime_resume_and_get() always returns 0.

> @@ -862,6 +862,7 @@ static int fimc_is_probe(struct platform_device *pdev)
>   	fimc_is_unregister_subdevs(is);
>   err_pm:
>   	pm_runtime_put_noidle(dev);
> +err_suspend:
>   	if (!pm_runtime_enabled(dev))
>   		fimc_is_runtime_suspend(dev);
>   err_irq:


> diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
> index 1aac167abb17..a0218237d66b 100644
> --- a/drivers/media/platform/exynos4-is/mipi-csis.c
> +++ b/drivers/media/platform/exynos4-is/mipi-csis.c
> @@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
>   	struct device *dev = &state->pdev->dev;
>   
>   	if (on)
> -		return pm_runtime_get_sync(dev);
> +		return pm_runtime_resume_and_get(dev);
>   
>   	return pm_runtime_put_sync(dev);
>   }
> @@ -509,9 +509,8 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
>   
>   	if (enable) {
>   		s5pcsis_clear_counters(state);
> -		ret = pm_runtime_get_sync(&state->pdev->dev);
> +		ret = pm_runtime_resume_and_get(&state->pdev->dev);
>   		if (ret && ret != 1) {
> -			pm_runtime_put_noidle(&state->pdev->dev);
>   			return ret;
>   		}

Braces could be dropped as well here.

>   	}


Thanks,
Sylwester



From pavel at ucw.cz  Sun Apr 25 22:25:39 2021
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 25 Apr 2021 23:25:39 +0200
Subject: [PATCH v3 2/2] rockchip: rk3399: Add support for FriendlyARM
 NanoPi R4S
In-Reply-To: <CAOP2_TjFtBqBP8wOY-wxSd89yYuYF4bwqWCP4c6FXNMNH=2t-w@mail.gmail.com>
References: <CAMuHMdWYrS=YT7F7erM-e6xhDME4judx-T7rdFGi7CpW1_iqkg@mail.gmail.com>
 <20210316150033.15987-1-cnsztl@gmail.com>
 <CAMuHMdU+agaOdf4hQhn5JQDHCbuWm3dETJu01baxfDAY=nikow@mail.gmail.com>
 <20210316193839.GA28184@duo.ucw.cz>
 <CAOP2_TjFtBqBP8wOY-wxSd89yYuYF4bwqWCP4c6FXNMNH=2t-w@mail.gmail.com>
Message-ID: <20210425212539.GE10996@amd>

Hi!

> However, Documentation/leds/leds-class.rst says the form of naming is
> "devicename:color:function",
> and according to the given examples, as well as other dts(i), would it
> be okay to use `green:lan`
> etc. as the lable?

Yes, that sounds right.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210425/a9cf06aa/attachment.sig>

From pavel at ucw.cz  Sun Apr 25 22:33:21 2021
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 25 Apr 2021 23:33:21 +0200
Subject: [PATCH v6 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
In-Reply-To: <161640742725.808893.3666594351389773587.b4-ty@sntech.de>
References: <20210319051627.814-1-cnsztl@gmail.com>
 <161640742725.808893.3666594351389773587.b4-ty@sntech.de>
Message-ID: <20210425213321.GF10996@amd>

Hi!

> > Changes in v6:
> > - Fixed format of LED nodes
> > 
> > Changes in v5:
> > - Dropped the empty PCIe node
> > - Dropped useless `/delete-property/`
> > - Renamed LED nodes
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
>       commit: 1003888415e83e15ddb63d1d96189b4f2c5f1d48
> [2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
>       commit: db792e9adbf85ffc9d6b0b060ac3c8e3148c8992

Sorry for late review, but:


+                       label = "red:sys";

This should be red:power based on the discussion in earlier threads.

Thanks,
									Pavel
-- 
http://www.livejournal.com/~pavelmachek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210425/20071161/attachment.sig>

From leo.yan at linaro.org  Mon Apr 26 01:25:51 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 26 Apr 2021 08:25:51 +0800
Subject: [PATCH 2/4] coresight: tmc-etr: Track perf handler.
In-Reply-To: <20210423092038.GB377091@leoy-ThinkPad-X240s>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-3-daniel.kiss@arm.com>
 <20210423092038.GB377091@leoy-ThinkPad-X240s>
Message-ID: <20210426002551.GA176271@leoy-ThinkPad-X240s>

On Fri, Apr 23, 2021 at 05:20:38PM +0800, Leo Yan wrote:
> Hi Daniel,
> 
> On Wed, Apr 21, 2021 at 02:04:11PM +0200, Daniel Kiss wrote:
> 
> [...]
> 
> > diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> > index dd19d1d1c3b38..bf9f6311d8663 100644
> > --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> > +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> > @@ -1511,6 +1511,12 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> >  		goto out;
> >  	}
> >  
> > +	/* Serve only the tracer with the right handler */
> > +	if (drvdata->perf_handle != handle) {
> > +		spin_unlock_irqrestore(&drvdata->spinlock, flags);
> > +		goto out;
> > +	}
> > +
> 
> I have concern for this change, Let's use the system-wide tracing as
> an example.
> 
> If a system have 4 CPUs, for the perf with system wide tracing, the
> tool maps the AUX ring buffers for four times, but the CoreSight
> driver only allocates pages once and maps these physical pages for
> four times to user space.  Therefore, the perf tool in the userspace
> manages 4 AUX ring buffers, every AUX ring buffer is served for one
> CPU.
> 
> The confusion between the CoreSight driver (in the kernel) and the
> perf tool (in the userspace) is: there actually has only one ring
> buffer for the enabled sink (let's say ETR), but there have four ring
> buffer control structures, the control structure is
> 'perf_event_mmap_page' which is resident in the first page for perf's
> general ring buffer (please note, this ring buffer is different from
> AUX ring buffer).
> 
> IIUC, this patch only allows the first CPU which enables coresight path
> to update the AUX ring buffer.  This can break the case:
> 
>   - Step 1: perf tool opens ETM event; we can use the command:
> 
>     # perf record -o ${perfdata} -e cs_etm/@tmc_etr0/ -a
>            -- dd if=/dev/zero of=/dev/null
> 
>   - Step 2: the profiled program "dd" is firstly schedued in CPU0, so
>     its "perf_handle" will be assigned to "drvdata->perf_handle";
> 
>   - Step 3: if the program "dd" is migrated to CPU1 and it never runs
>     on CPU0 afterwards, then this patch will prevent to update the AUX
>     ring buffer, due to the "drvdata->perf_handle" cannot match with
>     CPU1's handler.

Want to clarify, this case only happens with "snapshot" mode; With
Mathieu's reminding, "snapshot" mode is quite special: it creates AUX
ring buffer per CPU, but when enable the tracing, if without
specifying the option "-a" for system wide tracing, it only enables
ETM tracer for a CPU when the profiled program is scheduled on that CPU.

To avoid over complexsity, let's give this low priority and firstly
focus on the system-wide tracing case.

Thanks,
Leo

> On the other hand, I think we should change to always stick to the
> same "perf_output_handle" for all CPUs, thus it can allow all CPUs
> to use the same structure 'perf_event_mmap_page' for AUX ring buffer
> management.

> 
> [...]
> 
> Thanks,
> Leo


From shawn.guo at linaro.org  Mon Apr 26 01:41:49 2021
From: shawn.guo at linaro.org (Shawn Guo)
Date: Mon, 26 Apr 2021 08:41:49 +0800
Subject: [PATCH v2 0/3] arm-smmu-qcom: Create qcom_smmu_impl for ACPI boot
In-Reply-To: <20210402035602.9484-1-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
Message-ID: <20210426004148.GG15093@dragon>

On Fri, Apr 02, 2021 at 11:55:59AM +0800, Shawn Guo wrote:
> The arm-smmu-qcom driver needs to hook up qcom_smmu_impl for booting up
> Snapdragon platforms.  Such hook-up is being done for DT boot by
> matching compatibles.  The series tries to handle the hook-up for ACPI
> boot by looking at model identifier, which is figured out by IORT driver
> using acpi_match_platform_list() helper.  It helps to get Debian
> installer booting with ACPI work for Qualcomm SC8180X based laptops like
> Lenovo Flex 5G.
> 
> Changes for v2:
> - Rather than using asl_compiler_id in IORT table, follow suggestion
>   from Robin Murphy to use acpi_match_platform_list() to match platform.

How does this version look?  Any comments?

Shawn

> Shawn Guo (3):
>   ACPI/IORT: Consolidate use of SMMU device platdata
>   ACPI/IORT: Add Qualcomm Snapdragon platforms to iort_plat_info[]
>   iommu/arm-smmu-qcom: hook up qcom_smmu_impl for ACPI boot
> 
>  drivers/acpi/arm64/iort.c                   | 36 +++++++++------------
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  6 +++-
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c  |  9 ++++++
>  drivers/iommu/arm/arm-smmu/arm-smmu.c       |  9 ++++--
>  drivers/perf/arm_smmuv3_pmu.c               |  8 +++--
>  include/linux/acpi_iort.h                   | 12 +++++--
>  6 files changed, 51 insertions(+), 29 deletions(-)
> 
> -- 
> 2.17.1
> 


From festevam at gmail.com  Mon Apr 26 02:07:38 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 25 Apr 2021 22:07:38 -0300
Subject: [PATCH V2] ARM: dts: imx6q-dhcom: Add PU, VDD1P1,
 VDD2P5 regulators
In-Reply-To: <20210423175701.76637-1-marex@denx.de>
References: <20210423175701.76637-1-marex@denx.de>
Message-ID: <CAOMZO5C00Lz1U6vWYCgi2cWG9cCjxSNxrB2Zxn3d5rTTKJQO=Q@mail.gmail.com>

Hi Marek,

On Fri, Apr 23, 2021 at 2:57 PM Marek Vasut <marex at denx.de> wrote:
>
> Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1
> via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied
> from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs.
>
> While no instability or problems are currently observed, the regulators
> should be fully described in DT and that description should fully match
> the hardware, else this might lead to unforseen issues later. Fix this.
>
> Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
> Cc: Christoph Niedermaier <cniedermaier at dh-electronics.com>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Ludwig Zenz <lzenz at dh-electronics.com>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: stable at vger.kernel.org

You missed your Signed-off-by tag.

With that added:

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From festevam at gmail.com  Mon Apr 26 02:08:52 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 25 Apr 2021 22:08:52 -0300
Subject: [PATCH] ARM: imx: Initialize SoC ID on i.MX50
In-Reply-To: <20210424162133.680213-1-j.neuschaefer@gmx.net>
References: <20210424162133.680213-1-j.neuschaefer@gmx.net>
Message-ID: <CAOMZO5D--BCUyP3LGWnw5-ecphXgaUaBrqYLwh8-OXqoX-tnKA@mail.gmail.com>

Hi Jonathan,

On Sat, Apr 24, 2021 at 1:24 PM Jonathan Neusch?fer
<j.neuschaefer at gmx.net> wrote:
>
> As on i.MX51 and i.MX53, initialize the SoC ID based on the SoC
> compatible string of the board.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer at gmx.net>

Reviewed-by: Fabio Estevam <festevam at gmail.com>


From leo.yan at linaro.org  Mon Apr 26 02:18:24 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 26 Apr 2021 09:18:24 +0800
Subject: [PATCH 4/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210421120413.3110775-5-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-5-daniel.kiss@arm.com>
Message-ID: <20210426011824.GB176271@leoy-ThinkPad-X240s>

On Wed, Apr 21, 2021 at 02:04:13PM +0200, Daniel Kiss wrote:
> ETR might fill up the buffer sooner than an event makes perf to trigger
> the synchronisation especially in system wide trace. Polling runs
> periodically to sync the ETR buffer. Period is configurable via sysfs,
> disabled by default.
> 
> Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
> Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
> ---
>  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
>  drivers/hwtracing/coresight/Makefile          |   2 +-
>  .../hwtracing/coresight/coresight-etm-perf.c  |   8 +
>  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
>  .../coresight/coresight-etr-perf-polling.h    |  42 +++
>  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
>  .../hwtracing/coresight/coresight-tmc-etr.c   |   9 +
>  7 files changed, 386 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> index 6aa527296c710..4ca7af22a3686 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> @@ -91,3 +91,11 @@ Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
>  Description:	(RW) Size of the trace buffer for TMC-ETR when used in SYSFS
>  		mode. Writable only for TMC-ETR configurations. The value
>  		should be aligned to the kernel pagesize.
> +
> +What:		/sys/bus/coresight/devices/<memory_map>.tmc/polling/period
> +Date:		April 2021
> +KernelVersion:	5.13
> +Contact:	Daniel Kiss <daniel.kiss at arm.com>
> +Description:	(RW) Time in milliseconds when the TMC-ETR is synced.
> +		Default value is 0, means the feature is disabled.
> +		Writable only for TMC-ETR configurations.
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index d60816509755c..4df90b71d98cd 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -4,7 +4,7 @@
>  #
>  obj-$(CONFIG_CORESIGHT) += coresight.o
>  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
> -		coresight-sysfs.o
> +		coresight-sysfs.o  coresight-etr-perf-polling.o
>  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
>  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
>  		      coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 78a55fc2bcab5..910a99944eea8 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -19,6 +19,7 @@
>  #include <linux/workqueue.h>
>  
>  #include "coresight-etm-perf.h"
> +#include "coresight-etr-perf-polling.h"
>  #include "coresight-priv.h"
>  
>  static struct pmu etm_pmu;
> @@ -438,6 +439,8 @@ static void etm_event_start(struct perf_event *event, int flags)
>  	/* Tell the perf core the event is alive */
>  	event->hw.state = 0;
>  
> +	etr_perf_polling_event_start(event, event_data, handle);
> +
>  	/* Finally enable the tracer */
>  	if (source_ops(csdev)->enable(csdev, event, CS_MODE_PERF))
>  		goto fail_disable_path;
> @@ -497,6 +500,8 @@ static void etm_event_stop(struct perf_event *event, int mode)
>  	if (!sink)
>  		return;
>  
> +	etr_perf_polling_event_stop(event, event_data);
> +
>  	/* stop tracer */
>  	source_ops(csdev)->disable(csdev, event);
>  
> @@ -741,6 +746,8 @@ int __init etm_perf_init(void)
>  	etm_pmu.addr_filters_validate	= etm_addr_filters_validate;
>  	etm_pmu.nr_addr_filters		= ETM_ADDR_CMP_MAX;
>  
> +	etr_perf_polling_init();
> +
>  	ret = perf_pmu_register(&etm_pmu, CORESIGHT_ETM_PMU_NAME, -1);
>  	if (ret == 0)
>  		etm_perf_up = true;
> @@ -750,5 +757,6 @@ int __init etm_perf_init(void)
>  
>  void __exit etm_perf_exit(void)
>  {
> +	etr_perf_polling_exit();
>  	perf_pmu_unregister(&etm_pmu);
>  }
> diff --git a/drivers/hwtracing/coresight/coresight-etr-perf-polling.c b/drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> new file mode 100644
> index 0000000000000..aa0352908873a
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> @@ -0,0 +1,316 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2021 Arm Limited. All rights reserved.
> + * Author: Daniel Kiss <daniel.kiss at arm.com>
> + */
> +
> +#include <linux/coresight.h>
> +#include <linux/coresight-pmu.h>
> +#include <linux/cpumask.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/list.h>
> +#include <linux/percpu-defs.h>
> +#include <linux/perf_event.h>
> +#include <linux/slab.h>
> +#include <linux/stringhash.h>
> +#include <linux/types.h>
> +#include <linux/workqueue.h>
> +
> +#include "coresight-etr-perf-polling.h"
> +#include "coresight-priv.h"
> +#include "coresight-tmc.h"
> +
> +#if defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) || \
> +    defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC_MODULE)

It's good to add a new config "CONFIG_CORESIGHT_ETM_PERF_POLL" and
developers can selectively enable it when build kernel.

> +struct polling_event_list {
> +	struct perf_event *perf_event;
> +	struct etm_event_data *etm_event_data;
> +	struct perf_output_handle *ctx_handle;
> +	void (*tmc_etr_reset_hw)(struct tmc_drvdata *);
> +	struct list_head list;
> +};
> +
> +struct polling {
> +	int cpu;
> +	struct list_head polled_events;

Based the structure definition, every CPU has its own polling
structure, and there have multiple polled event for one CPU.  In
theory, should every CPU have only one perf event for polling?

If so, it's not necessary to create event list for every CPU; in other
words, we can create a list which can be used to maintain all events
cross all CPUs.

> +	struct delayed_work delayed_work;
> +};

Every CPU has its own delayed work, a potential issue is it's hard to
synchronize within CPUs; and after the CPU number increases, the
situation will get worse.  For example, when polling for multiple CPUs,
there might have no chance to stop all tracers attached to CPUs.

I understand this patch simply captures the trace data for the first CPU
which reigstered its handler in the driver; IOW, we have no chance to
stop all tracers to record a clean tracing data (here "clean" means
there have no mixed behaviours that one CPU is reading trace data from
ETR buffer and tracers from other CPUs still write data into the ETR
buffer).

> +static atomic_t period;
> +static spinlock_t spinlock_re;
> +static struct list_head registered_events;
> +
> +static DEFINE_PER_CPU(struct polling, polling);
> +
> +static ssize_t period_show(struct device *dev, struct device_attribute *attr,
> +			   char *buf)
> +{
> +	int temp;
> +	struct tmc_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> +		return -EPERM;

IMHO, the checking is redundant.

> +
> +	temp = atomic_read(&period);
> +	return sprintf(buf, "%i\n", temp);
> +}
> +
> +static ssize_t period_store(struct device *dev, struct device_attribute *attr,
> +			    const char *buf, size_t count)
> +{
> +	int temp = 0;
> +	struct tmc_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> +		return -EPERM;

Ditto.

> +
> +	if ((1 == sscanf(buf, "%i", &temp)) && (temp >= 0))
> +		atomic_set(&period, temp);
> +	return count;
> +}
> +
> +static DEVICE_ATTR_RW(period);
> +
> +static struct attribute *coresight_tmc_polling_attrs[] = {
> +	&dev_attr_period.attr,
> +	NULL,
> +};
> +const struct attribute_group coresight_tmc_polling_group = {
> +	.attrs = coresight_tmc_polling_attrs,
> +	.name = "polling",
> +};
> +EXPORT_SYMBOL_GPL(coresight_tmc_polling_group);

Don't need to export the symbol.

> +
> +static inline void polling_sched_worker(struct polling *p)
> +{
> +	int tickrate = atomic_read(&period);
> +	if (!list_empty(&p->polled_events) && (tickrate > 0))
> +		schedule_delayed_work_on(p->cpu, &p->delayed_work,
> +					 msecs_to_jiffies(tickrate));
> +}
> +
> +static inline bool is_etr_related(struct etm_event_data *etm_event_data, int cpu)
> +{
> +	struct list_head *path;
> +	struct coresight_device *sink;
> +	struct tmc_drvdata *drvdata;
> +	path = etm_event_cpu_path(etm_event_data, cpu);
> +	if (WARN_ON(!path))
> +		return false;
> +	sink = coresight_get_sink(path);
> +	if (WARN_ON(!sink))
> +		return false;
> +	drvdata = dev_get_drvdata(sink->dev.parent);
> +	if (drvdata->config_type != TMC_CONFIG_TYPE_ETR)
> +		return false;
> +	return true;
> +}

Understand these operations are from etm_event_start(); we can avoid
the duplicate code if arrange code more reasonable.

I suggest below flow:

  - From the function etm_setup_aux(), insert an AUX event into the
    polling list;
  - From the function etm_event_start(), enable the AUX event, so this
    AUX event will be polled periodically;
  - From the function etm_event_stop(), disable the AUX event, the
    event will not be polled anymore;
  - From the function etm_free_AUX(), remove the AUX event from the
    polling list.

> +
> +/*
> + * Adds the event to the polled events list.
> + */
> +void etr_perf_polling_event_start(struct perf_event *event,
> +				  struct etm_event_data *etm_event_data,
> +				  struct perf_output_handle *ctx_handle)
> +{
> +	int cpu = smp_processor_id();
> +	struct polling *p = per_cpu_ptr(&polling, cpu);
> +	struct polling_event_list *element;
> +	struct list_head *i, *tmp;
> +
> +	if (!is_etr_related(etm_event_data, cpu))
> +		return;
> +
> +	spin_lock(&spinlock_re);
> +	list_for_each_safe (i, tmp, &registered_events) {

Suprious space before parenthese; and better to use
list_for_each_entry_safe().

> +		element = list_entry(i, struct polling_event_list, list);
> +		if (element->ctx_handle == ctx_handle) {
> +			element->perf_event = event;
> +			element->etm_event_data = etm_event_data;
> +			list_del(&element->list);
> +			spin_unlock(&spinlock_re);
> +			list_add(&element->list, &p->polled_events);
> +			polling_sched_worker(p);
> +			return;
> +		}
> +	}
> +	spin_unlock(&spinlock_re);
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_event_start);

No need to export the symbol.

> +
> +/*
> + * Removes the event from the to be polled events list.
> + */
> +void etr_perf_polling_event_stop(struct perf_event *event,
> +				 struct etm_event_data *etm_event_data)
> +{
> +	int cpu = smp_processor_id();
> +	struct list_head *i, *tmp;
> +	struct polling *p = per_cpu_ptr(&polling, cpu);
> +
> +	if (!is_etr_related(etm_event_data, cpu))
> +		return;
> +
> +	list_for_each_safe (i, tmp, &p->polled_events) {
> +		struct polling_event_list *element =
> +			list_entry(i, struct polling_event_list, list);
> +		if (element->perf_event == event) {
> +			list_del(&element->list);
> +			element->perf_event = NULL;
> +			element->etm_event_data = NULL;
> +			spin_lock(&spinlock_re);
> +			list_add(&element->list, &registered_events);
> +			spin_unlock(&spinlock_re);
> +			if (list_empty(&p->polled_events)) {
> +				cancel_delayed_work(&p->delayed_work);
> +			}
> +			return;
> +		}
> +	}
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_event_stop);

Ditto.

> +
> +/*
> + * The polling worker is a workqueue job which is periodically
> + * woken up to update the perf aux buffer from the etr shrink.
> + */
> +static void etr_perf_polling_worker(struct work_struct *work)
> +{
> +	unsigned long flags;
> +	int cpu = smp_processor_id();
> +	struct polling *p = per_cpu_ptr(&polling, cpu);
> +	struct list_head *i, *tmp;
> +
> +	if (!atomic_read(&period))
> +		return;
> +
> +	/*
> +	 * Scheduling would do the same from the perf hooks,
> +	 * this should be done in one go.
> +	 */
> +	local_irq_save(flags);
> +	preempt_disable();

The locking usage is questionable...

local_irq_save() will disable the local interrupt, and it also
disables preemption; after disabling interrupt, it's needless to
disable preemption.

Here neither local_irq_save() nor preempt_disable() is the right
locking to be used; alternatively, should use the pair functions
spinlock(&spinlock_re) / spin_unlock(&spinlock_re), this is because it
needs to protect the poll list.

> +	/* Perf requires rcu lock. */
> +	rcu_read_lock();

Though it gives comments, I still don't understand why need to use
rcu_read_lock().  Which critical resource it protects?

> +
> +	polling_sched_worker(p);
> +
> +	list_for_each_safe (i, tmp, &p->polled_events) {
> +		struct list_head *path;
> +		struct coresight_device *sink;
> +		struct polling_event_list *element =
> +			list_entry(i, struct polling_event_list, list);
> +
> +		path = etm_event_cpu_path(element->etm_event_data, cpu);
> +		if (WARN_ON(!path))
> +			continue;
> +		sink = coresight_get_sink(path);
> +		if (WARN_ON(!sink))
> +			continue;

When inserting the event into polling list, it have checked for path
and validate sink; so it's no need to check the path again.

> +		if (sink_ops(sink)->update_buffer) {
> +			int size, refcnt;
> +			struct tmc_drvdata *drvdata = dev_get_drvdata(sink->dev.parent);
> +
> +			/*
> +			 * Act as now we are the only users of the sink. Due to the locks
> +			 * we are safe.
> +			 */
> +			refcnt = atomic_xchg(sink->refcnt, 1);
> +			size = sink_ops(sink)->update_buffer(
> +				sink, element->ctx_handle,
> +				element->etm_event_data->snk_config);
> +			refcnt = atomic_xchg(sink->refcnt, refcnt);

This is tricky.  This change is like a workaround, it's better to
refactor the code for "sink->refcnt"; maybe we can refactor the coe
to track the sink's reference counter in the polling list rather than
in the low level driver.

> +			/*
> +			 * Restart the trace.
> +			 */
> +			if (element->tmc_etr_reset_hw)
> +				element->tmc_etr_reset_hw(drvdata);
> +
> +			WARN_ON(size < 0);
> +			if (size > 0) {
> +				struct etm_event_data *new_event_data;
> +
> +				perf_aux_output_end(element->ctx_handle, size);
> +				new_event_data = perf_aux_output_begin(
> +					element->ctx_handle,
> +					element->perf_event);
> +				if (WARN_ON(new_event_data == NULL))
> +					continue;
> +				element->etm_event_data = new_event_data;
> +				WARN_ON(new_event_data->snk_config !=
> +					element->etm_event_data->snk_config);
> +			}
> +		}
> +	}
> +
> +	rcu_read_unlock();
> +	preempt_enable();
> +	local_irq_restore(flags);
> +}
> +
> +void etr_perf_polling_handle_register(struct perf_output_handle *handle,
> +				      void (*tmc_etr_reset_hw)(struct tmc_drvdata *drvdata))
> +{
> +	struct polling_event_list *element;
> +
> +	element = kmalloc(sizeof(*element), GFP_KERNEL);
> +	if (WARN_ON(!element))
> +		return;
> +	memset(element, 0, sizeof(*element));
> +	element->ctx_handle = handle;
> +	element->tmc_etr_reset_hw = tmc_etr_reset_hw;
> +	spin_lock(&spinlock_re);
> +	list_add(&element->list, &registered_events);
> +	spin_unlock(&spinlock_re);
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_handle_register);
> +
> +void etr_perf_polling_handle_deregister(struct perf_output_handle *handle)
> +{
> +	struct list_head *i, *tmp;
> +
> +	spin_lock(&spinlock_re);
> +	list_for_each_safe (i, tmp, &registered_events) {
> +		struct polling_event_list *element =
> +			list_entry(i, struct polling_event_list, list);
> +		if (element->ctx_handle == handle) {
> +			list_del(&element->list);
> +			spin_unlock(&spinlock_re);
> +			kfree(element);
> +			return;
> +		}
> +	}
> +	spin_unlock(&spinlock_re);
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_handle_deregister);
> +
> +void etr_perf_polling_init(void)
> +{
> +	int cpu;
> +	spin_lock_init(&spinlock_re);
> +	INIT_LIST_HEAD(&registered_events);
> +	atomic_set(&period, 0);
> +	for_each_possible_cpu (cpu) {
> +		struct polling *p = per_cpu_ptr(&polling, cpu);
> +		p->cpu = cpu;
> +		INIT_LIST_HEAD(&p->polled_events);
> +		INIT_DELAYED_WORK(&p->delayed_work, etr_perf_polling_worker);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_init);
> +
> +void etr_perf_polling_exit(void)
> +{
> +	int cpu;
> +	for_each_possible_cpu (cpu) {
> +		struct polling *p = per_cpu_ptr(&polling, cpu);
> +		cancel_delayed_work_sync(&p->delayed_work);
> +		WARN_ON(!list_empty(&p->polled_events));
> +	}
> +	WARN_ON(!list_empty(&registered_events));
> +}
> +EXPORT_SYMBOL_GPL(etr_perf_polling_exit);
> +
> +#endif
> diff --git a/drivers/hwtracing/coresight/coresight-etr-perf-polling.h b/drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> new file mode 100644
> index 0000000000000..5917e1fa408bb
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright(C) 2021 Arm Limited. All rights reserved.
> + * Author: Daniel Kiss <daniel.kiss at arm.com>
> + */
> +
> +#ifndef _CORESIGHT_ETM_PERF_POLLING_H
> +#define _CORESIGHT_ETM_PERF_POLLING_H
> +
> +#include <linux/coresight.h>
> +#include <linux/perf_event.h>
> +#include "coresight-etm-perf.h"
> +#include "coresight-tmc.h"
> +
> +#if defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) || \
> +    defined(CONFIG_CORESIGHT_LINK_AND_SINK_TMC_MODULE)
> +
> +void etr_perf_polling_init(void);
> +void etr_perf_polling_exit(void);
> +void etr_perf_polling_handle_register(struct perf_output_handle *handle,
> +				      void (*tmc_etr_reset_hw)(struct tmc_drvdata *drvdata));
> +void etr_perf_polling_handle_deregister(struct perf_output_handle *handle);
> +void etr_perf_polling_event_start(struct perf_event *event,
> +				  struct etm_event_data *etm_event_data,
> +				  struct perf_output_handle *ctx_handle);
> +void etr_perf_polling_event_stop(struct perf_event *event,
> +				 struct etm_event_data *etm_event_data);
> +
> +extern const struct attribute_group coresight_tmc_polling_group;
> +#define CORESIGHT_TMP_POLLING_GROUP &coresight_tmc_polling_group,
> +
> +#else /* !CONFIG_CORESIGHT_LINK_AND_SINK_TMC */
> +#define etr_perf_polling_init()
> +#define etr_perf_polling_exit()
> +#define etr_perf_polling_handle_register(...)
> +#define etr_perf_polling_handle_deregister(...)
> +#define etr_perf_polling_event_start(...)
> +#define etr_perf_polling_event_stop(...)
> +#define CORESIGHT_TMP_POLLING_GROUP
> +#endif
> +
> +#endif
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c
> index 74c6323d4d6ab..51e705ef3ffa3 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c
> @@ -26,6 +26,7 @@
>  
>  #include "coresight-priv.h"
>  #include "coresight-tmc.h"
> +#include "coresight-etr-perf-polling.h"
>  
>  DEFINE_CORESIGHT_DEVLIST(etb_devs, "tmc_etb");
>  DEFINE_CORESIGHT_DEVLIST(etf_devs, "tmc_etf");
> @@ -365,6 +366,7 @@ static const struct attribute_group coresight_tmc_mgmt_group = {
>  static const struct attribute_group *coresight_tmc_groups[] = {
>  	&coresight_tmc_group,
>  	&coresight_tmc_mgmt_group,
> +	CORESIGHT_TMP_POLLING_GROUP

This is a bit wired for me.  It's more readable with:

#ifdef CONFIG_CORESIGHT_ETM_PERF_POLL
        &coresight_tmc_polling_group,
#endif

>  	NULL,
>  };
>  
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index bf9f6311d8663..021b594e38e71 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -16,6 +16,7 @@
>  #include <linux/vmalloc.h>
>  #include "coresight-catu.h"
>  #include "coresight-etm-perf.h"
> +#include "coresight-etr-perf-polling.h"
>  #include "coresight-priv.h"
>  #include "coresight-tmc.h"
>  
> @@ -1139,6 +1140,12 @@ void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
>  	drvdata->etr_buf = NULL;
>  }
>  
> +static void tmc_etr_reset_hw(struct tmc_drvdata *drvdata)
> +{
> +	__tmc_etr_disable_hw(drvdata);
> +	__tmc_etr_enable_hw(drvdata);
> +}
> +
>  static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev)
>  {
>  	int ret = 0;
> @@ -1630,6 +1637,7 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, void *data)
>  		drvdata->mode = CS_MODE_PERF;
>  		drvdata->perf_buf = etr_perf->etr_buf;
>  		drvdata->perf_handle = handle;
> +		etr_perf_polling_handle_register(handle, tmc_etr_reset_hw);
>  		atomic_inc(csdev->refcnt);
>  	}
>  
> @@ -1677,6 +1685,7 @@ static int tmc_disable_etr_sink(struct coresight_device *csdev)
>  	drvdata->mode = CS_MODE_DISABLED;
>  	/* Reset perf specific data */
>  	drvdata->perf_buf = NULL;
> +	etr_perf_polling_handle_deregister(drvdata->perf_handle);
>  	drvdata->perf_handle = NULL;
>  
>  	spin_unlock_irqrestore(&drvdata->spinlock, flags);
> -- 
> 2.25.1
> 


From shawnguo at kernel.org  Mon Apr 26 02:21:39 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 09:21:39 +0800
Subject: [PATCH 0/2] dt-bindings: usb: dwc3-imx8mp: Use the correct name
 for child node "snps,dwc3"
In-Reply-To: <20210329072714.2135-1-thunder.leizhen@huawei.com>
References: <20210329072714.2135-1-thunder.leizhen@huawei.com>
Message-ID: <20210426012138.GA27585@dragon>

On Mon, Mar 29, 2021 at 03:27:12PM +0800, Zhen Lei wrote:
> File snps,dwc3.yaml describes the schema of Synopsys DesignWare USB3
> Controller, it directly or indirectly contains "$ref: usb.yaml". So the
> node name of "snps,dwc3" must start with "usb". Otherwise, the following
> warning will be displayed:
> 
> Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.example.dt.yaml: \
> dwc3 at 38100000: $nodename:0: 'dwc3 at 38100000' does not match '^usb(@.*)?'
>         From schema: Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> 
> 
> Zhen Lei (2):
>   dt-bindings: usb: dwc3-imx8mp: Use the correct name for child node
>     "snps,dwc3"
>   arm64: dts: imx8mp: Use the correct name for child node "snps,dwc3"

Applied both, thanks.


From shawnguo at kernel.org  Mon Apr 26 02:24:57 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 09:24:57 +0800
Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to power
 up pcie phy
In-Reply-To: <1617005163-29824-1-git-send-email-hongxing.zhu@nxp.com>
References: <1617005163-29824-1-git-send-email-hongxing.zhu@nxp.com>
Message-ID: <20210426012456.GB27585@dragon>

On Mon, Mar 29, 2021 at 04:06:03PM +0800, Richard Zhu wrote:
> Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> the VREG_BYPASS bits of GPR registers should be cleared from default
> value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
> turned on.
> 
> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> ---
>  arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> index 85b045253a0e..4d2035e3dd7c 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> @@ -318,6 +318,7 @@
>  		 <&clk IMX8MQ_CLK_PCIE1_PHY>,
>  		 <&pcie0_refclk>;
>  	clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> +	vph-supply = <&vgen5_reg>;

Hmm, I do not see this in the bindings doc.

Shawn

>  	status = "okay";
>  };
>  
> -- 
> 2.17.1
> 


From shawnguo at kernel.org  Mon Apr 26 02:26:09 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 09:26:09 +0800
Subject: [PATCH] ARM: dts: imx6qdl-wandboard-revd1: Remove PAD_EIM_D22
 from hog group
In-Reply-To: <20210329120954.574957-1-festevam@gmail.com>
References: <20210329120954.574957-1-festevam@gmail.com>
Message-ID: <20210426012608.GC27585@dragon>

On Mon, Mar 29, 2021 at 09:09:54AM -0300, Fabio Estevam wrote:
> The MX6QDL_PAD_EIM_D22 pad is already handled in the common
> imx6qdl-wandboard.dtsi file.
> 
> Remove it from the local hog group to avoid the following runtime error:
> 
> [    0.117763] imx6q-pinctrl 20e0000.pinctrl: pin MX6Q_PAD_EIM_D22 already requested by 20e0000.pinctrl; cannot claim for regulator-usbotgvbus
> [    0.117785] imx6q-pinctrl 20e0000.pinctrl: pin-42 (regulator-usbotgvbus) status -22
> [    0.117802] imx6q-pinctrl 20e0000.pinctrl: could not request pin 42 (MX6Q_PAD_EIM_D22) from group usbotgvbusgrp on device 20e0000.pinctrl
> [    0.117822] reg-fixed-voltage regulator-usbotgvbus: Error applying setting, reverse things back
> [    0.117844] reg-fixed-voltage: probe of regulator-usbotgvbus failed with error -22
> 
> Signed-off-by: Fabio Estevam <festevam at gmail.com>

Applied, thanks.


From shawnguo at kernel.org  Mon Apr 26 02:29:08 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 09:29:08 +0800
Subject: [PATCH] arm64: dts: imx8mp-evk: Add PMIC device
In-Reply-To: <20210329123409.26975-1-u.kleine-koenig@pengutronix.de>
References: <20210329123409.26975-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210426012907.GD27585@dragon>

On Mon, Mar 29, 2021 at 02:34:09PM +0200, Uwe Kleine-K?nig wrote:
> The imx8mp-evk uses an PCA9450C as PMIC that supplies various
> regulators.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

Applied, thanks.


From lushenming at huawei.com  Mon Apr 26 02:41:23 2021
From: lushenming at huawei.com (Shenming Lu)
Date: Mon, 26 Apr 2021 09:41:23 +0800
Subject: [RFC PATCH v3 0/8] Add IOPF support for VFIO passthrough
In-Reply-To: <20210409034420.1799-1-lushenming@huawei.com>
References: <20210409034420.1799-1-lushenming@huawei.com>
Message-ID: <cb9584fd-c7f5-8cac-8c63-219ded2ef9db@huawei.com>

On 2021/4/9 11:44, Shenming Lu wrote:
> Hi,
> 
> Requesting for your comments and suggestions. :-)

Kind ping...

> 
> The static pinning and mapping problem in VFIO and possible solutions
> have been discussed a lot [1, 2]. One of the solutions is to add I/O
> Page Fault support for VFIO devices. Different from those relatively
> complicated software approaches such as presenting a vIOMMU that provides
> the DMA buffer information (might include para-virtualized optimizations),
> IOPF mainly depends on the hardware faulting capability, such as the PCIe
> PRI extension or Arm SMMU stall model. What's more, the IOPF support in
> the IOMMU driver has already been implemented in SVA [3]. So we add IOPF
> support for VFIO passthrough based on the IOPF part of SVA in this series.
> 
> We have measured its performance with UADK [4] (passthrough an accelerator
> to a VM(1U16G)) on Hisilicon Kunpeng920 board (and compared with host SVA):
> 
> Run hisi_sec_test...
>  - with varying sending times and message lengths
>  - with/without IOPF enabled (speed slowdown)
> 
> when msg_len = 1MB (and PREMAP_LEN (in Patch 4) = 1):
>             slowdown (num of faults)
>  times      VFIO IOPF      host SVA
>  1          63.4% (518)    82.8% (512)
>  100        22.9% (1058)   47.9% (1024)
>  1000       2.6% (1071)    8.5% (1024)
> 
> when msg_len = 10MB (and PREMAP_LEN = 512):
>             slowdown (num of faults)
>  times      VFIO IOPF
>  1          32.6% (13)
>  100        3.5% (26)
>  1000       1.6% (26)
> 
> History:
> 
> v2 -> v3
>  - Nit fixes.
>  - No reason to disable reporting the unrecoverable faults. (baolu)
>  - Maintain a global IOPF enabled group list.
>  - Split the pre-mapping optimization to be a separate patch.
>  - Add selective faulting support (use vfio_pin_pages to indicate the
>    non-faultable scope and add a new struct vfio_range to record it,
>    untested). (Kevin)
> 
> v1 -> v2
>  - Numerous improvements following the suggestions. Thanks a lot to all
>    of you.
> 
> Note that PRI is not supported at the moment since there is no hardware.
> 
> Links:
> [1] Lesokhin I, et al. Page Fault Support for Network Controllers. In ASPLOS,
>     2016.
> [2] Tian K, et al. coIOMMU: A Virtual IOMMU with Cooperative DMA Buffer Tracking
>     for Efficient Memory Management in Direct I/O. In USENIX ATC, 2020.
> [3] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210401154718.307519-1-jean-philippe at linaro.org/
> [4] https://github.com/Linaro/uadk
> 
> Thanks,
> Shenming
> 
> 
> Shenming Lu (8):
>   iommu: Evolve the device fault reporting framework
>   vfio/type1: Add a page fault handler
>   vfio/type1: Add an MMU notifier to avoid pinning
>   vfio/type1: Pre-map more pages than requested in the IOPF handling
>   vfio/type1: VFIO_IOMMU_ENABLE_IOPF
>   vfio/type1: No need to statically pin and map if IOPF enabled
>   vfio/type1: Add selective DMA faulting support
>   vfio: Add nested IOPF support
> 
>  .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |    3 +-
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   |   18 +-
>  drivers/iommu/iommu.c                         |   56 +-
>  drivers/vfio/vfio.c                           |   85 +-
>  drivers/vfio/vfio_iommu_type1.c               | 1000 ++++++++++++++++-
>  include/linux/iommu.h                         |   19 +-
>  include/linux/vfio.h                          |   13 +
>  include/uapi/linux/iommu.h                    |    4 +
>  include/uapi/linux/vfio.h                     |    6 +
>  9 files changed, 1181 insertions(+), 23 deletions(-)
> 


From shawnguo at kernel.org  Mon Apr 26 03:00:54 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 10:00:54 +0800
Subject: [PATCH] arm64: dts: imx8mq-evk: add one regulator used to
 power up pcie phy
In-Reply-To: <VI1PR04MB5853CB1B4E6C07C2DC3BC8D88C429@VI1PR04MB5853.eurprd04.prod.outlook.com>
References: <VI1PR04MB5853CB1B4E6C07C2DC3BC8D88C429@VI1PR04MB5853.eurprd04.prod.outlook.com>
Message-ID: <20210426020053.GE27585@dragon>

On Mon, Apr 26, 2021 at 01:28:34AM +0000, Richard Zhu wrote:
> > -----Original Message-----
> <snipped>
> > Subject: Re: [PATCH] arm64: dts: imx8mq-evk: add one regulator used
> > to power up pcie phy
> > On Mon, Mar 29, 2021 at 04:06:03PM +0800, Richard Zhu wrote:
> > > Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
> > > In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
> > > sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
> > > the VREG_BYPASS bits of GPR registers should be cleared from default
> > > value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
> > > turned on.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > Reviewed-by: Lucas Stach <l.stach at pengutronix.de>
> > > ---
> > >  arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > > b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > > index 85b045253a0e..4d2035e3dd7c 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > > @@ -318,6 +318,7 @@
> > >                <&clk IMX8MQ_CLK_PCIE1_PHY>,
> > >                <&pcie0_refclk>;
> > >       clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> > > +     vph-supply = <&vgen5_reg>;
> > 
> > Hmm, I do not see this in the bindings doc.
> [Richard Zhu] Hi Shawn:
> The binding document changes are going to PCI tree by the following patch.
> 
> https://patchwork.kernel.org/project/linux-pci/patch/1617091701-6444-2-git-send-email-hongxing.zhu at nxp.com/

Ah, okay, ping me when the series is applied to PCI tree.

Shawn


From shawnguo at kernel.org  Mon Apr 26 03:37:45 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 10:37:45 +0800
Subject: [PATCH] arm64: dts: ls1028a-rdb: enable optee node
In-Reply-To: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
References: <20210330145027.16897-1-sahil.malhotra@oss.nxp.com>
Message-ID: <20210426023744.GF27585@dragon>

On Tue, Mar 30, 2021 at 08:20:27PM +0530, Sahil Malhotra wrote:
> From: Sahil Malhotra <sahil.malhotra at nxp.com>
> 
> optee node was disabled by default, enabling it for ls1028a-rdb.
> 
> Signed-off-by: Michael Walle <michael at walle.cc>
> Signed-off-by: Sahil Malhotra <sahil.malhotra at nxp.com>

Applied, thanks.


From shawnguo at kernel.org  Mon Apr 26 03:39:58 2021
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 26 Apr 2021 10:39:58 +0800
Subject: [PATCH] arm64: dts: ls1012a: enable PCIe on freeway board
In-Reply-To: <20210330151920.29146-1-ykaukab@suse.de>
References: <20210330151920.29146-1-ykaukab@suse.de>
Message-ID: <20210426023957.GG27585@dragon>

On Tue, Mar 30, 2021 at 05:19:20PM +0200, Mian Yousaf Kaukab wrote:
> ls1012a-freeway board contains a M.2 2230 slot. Update the status of
> pcei1 node to okay so that the pcie controller can be probed.
> 
> Signed-off-by: Mian Yousaf Kaukab <ykaukab at suse.de>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> index 6290e2f9de6a..e3f371788f85 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
> @@ -38,3 +38,7 @@ w25q16dw0: flash at 0 {
>  		spi-tx-bus-width = <2>;
>  	};
>  };
> +
> +&pcie1 {
> +	status = "okay";
> +};

Keep the labeling nodes sort alphabetically.

Shawn

> -- 
> 2.26.2
> 


From zhiyong.tao at mediatek.com  Mon Apr 26 03:38:47 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Mon, 26 Apr 2021 10:38:47 +0800
Subject: [PATCH] pinctrl: mediatek: dd rsel setting on MT8195
In-Reply-To: <20210426023847.20746-1-zhiyong.tao@mediatek.com>
References: <20210426023847.20746-1-zhiyong.tao@mediatek.com>
Message-ID: <20210426023847.20746-2-zhiyong.tao@mediatek.com>

This patch provides rsel setting on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index a7500e18bb1d..66608b8d346a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
 	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_rsel_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x0c0, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x0c0, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x0c0, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x0c0, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x0c0, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x0c0, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x0c0, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x0c0, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x0c0, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x0c0, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x080, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x080, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x0e0, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x0e0, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x0e0, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x0e0, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -793,6 +812,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
 	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
+	[PINCTRL_PIN_REG_RSEL] = MTK_RANGE(mt8195_pin_rsel_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -823,6 +843,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.drive_get = mtk_pinconf_drive_get_rev1,
 	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
 	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
+	.rsel_set = mtk_pinconf_rsel_set,
+	.rsel_get = mtk_pinconf_rsel_get,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 2b51f4a9b860..d1526d0c6248 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1041,6 +1041,20 @@ int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_RSEL, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_set);
+
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_RSEL, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_get);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fd5ce9c5dcbd..570e8da7bf38 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -67,6 +67,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
 	PINCTRL_PIN_REG_DRV_ADV,
+	PINCTRL_PIN_REG_RSEL,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -237,6 +238,10 @@ struct mtk_pin_soc {
 			     const struct mtk_pin_desc *desc, u32 arg);
 	int (*adv_drive_get)(struct mtk_pinctrl *hw,
 			     const struct mtk_pin_desc *desc, u32 *val);
+	int (*rsel_set)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 arg);
+	int (*rsel_get)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 *val);
 
 	/* Specific driver data */
 	void				*driver_data;
@@ -320,5 +325,10 @@ int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
 int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 				  const struct mtk_pin_desc *desc, u32 *val);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val);
+
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..392fdfcb5b87 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -22,6 +22,8 @@
 #define MTK_PIN_CONFIG_PU_ADV	(PIN_CONFIG_END + 3)
 #define MTK_PIN_CONFIG_PD_ADV	(PIN_CONFIG_END + 4)
 #define MTK_PIN_CONFIG_DRV_ADV	(PIN_CONFIG_END + 5)
+#define MTK_PIN_CONFIG_RSEL	(PIN_CONFIG_END + 6)
+
 
 static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,tdsel",	MTK_PIN_CONFIG_TDSEL,		0},
@@ -29,6 +31,7 @@ static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,pull-up-adv", MTK_PIN_CONFIG_PU_ADV,		1},
 	{"mediatek,pull-down-adv", MTK_PIN_CONFIG_PD_ADV,	1},
 	{"mediatek,drive-strength-adv", MTK_PIN_CONFIG_DRV_ADV,	2},
+	{"mediatek,rsel",		MTK_PIN_CONFIG_RSEL,	2},
 };
 
 #ifdef CONFIG_DEBUG_FS
@@ -38,6 +41,7 @@ static const struct pin_config_item mtk_conf_items[] = {
 	PCONFDUMP(MTK_PIN_CONFIG_PU_ADV, "pu-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_PD_ADV, "pd-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_DRV_ADV, "drive-strength-adv", NULL, true),
+	PCONFDUMP(MTK_PIN_CONFIG_RSEL, "rsel", NULL, true),
 };
 #endif
 
@@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_get)
+			err = hw->soc->rsel_get(hw, desc, &ret);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
@@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_set)
+			err = hw->soc->rsel_set(hw, desc, arg);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
-- 
2.18.0

From zhiyong.tao at mediatek.com  Mon Apr 26 03:38:46 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Mon, 26 Apr 2021 10:38:46 +0800
Subject: [PATCH v6 0/1] Mediatek pinctrl patch on mt8195 
Message-ID: <20210426023847.20746-1-zhiyong.tao@mediatek.com>

This series includes 1 patches:
1.add pinctrl rsel setting on MT8195.

Changes in patch v6:
1)add "pintcrl: mediatek" as prefix.

Changes in patch v5:
1)document and driver patch are apploed.
2)change '-EOPNOTSUPP' to '-ENOTSUPP'

Changes in patch v4:
1)fix pinctrl-mt8195.yaml warning error.
2)remove pinctrl device node patch which is based on "mt8195.dtsi".

Changes in patch v3:
1)change '^pins' to '-pins$'.
2)change 'state_0_node_a' to 'gpio_pin' which is defined in dts.
3)change 'state_0_node_b' to 'i2c0_pin' which is defined in dts.
4)reorder this series patches. change pinctrl file and binding document
together in one patch.

There are no changes in v1 & v2.

Zhiyong Tao (1):
  pinctrl: mediatek: dd rsel setting on MT8195

 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

--
2.18.0


From zhiyong.tao at mediatek.com  Mon Apr 26 03:45:32 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Mon, 26 Apr 2021 10:45:32 +0800
Subject: [PATCH v7 0/1] Mediatek pinctrl patch on mt8195 
Message-ID: <20210426024533.20840-1-zhiyong.tao@mediatek.com>

This series includes 1 patches:
1.add pinctrl rsel setting on MT8195.

Changes in patch v7:
1)add version in patch and fix spelling mistakes.

Changes in patch v6:
1)add "pintcrl: mediatek" as prefix.

Changes in patch v5:
1)document and driver patch are apploed.
2)change '-EOPNOTSUPP' to '-ENOTSUPP'

Changes in patch v4:
1)fix pinctrl-mt8195.yaml warning error.
2)remove pinctrl device node patch which is based on "mt8195.dtsi".

Changes in patch v3:
1)change '^pins' to '-pins$'.
2)change 'state_0_node_a' to 'gpio_pin' which is defined in dts.
3)change 'state_0_node_b' to 'i2c0_pin' which is defined in dts.
4)reorder this series patches. change pinctrl file and binding document
together in one patch.

There are no changes in v1 & v2.


From zhiyong.tao at mediatek.com  Mon Apr 26 03:45:33 2021
From: zhiyong.tao at mediatek.com (Zhiyong Tao)
Date: Mon, 26 Apr 2021 10:45:33 +0800
Subject: [PATCH v7] pinctrl: mediatek: add rsel setting on MT8195
In-Reply-To: <20210426024533.20840-1-zhiyong.tao@mediatek.com>
References: <20210426024533.20840-1-zhiyong.tao@mediatek.com>
Message-ID: <20210426024533.20840-2-zhiyong.tao@mediatek.com>

This patch provides rsel setting on MT8195.

Signed-off-by: Zhiyong Tao <zhiyong.tao at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mt8195.c     | 22 +++++++++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.c  | 14 ++++++++++++
 .../pinctrl/mediatek/pinctrl-mtk-common-v2.h  | 10 +++++++++
 drivers/pinctrl/mediatek/pinctrl-paris.c      | 16 ++++++++++++++
 4 files changed, 62 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8195.c b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
index a7500e18bb1d..66608b8d346a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8195.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8195.c
@@ -779,6 +779,25 @@ static const struct mtk_pin_field_calc mt8195_pin_drv_adv_range[] = {
 	PIN_FIELD_BASE(45, 45, 1, 0x040, 0x10, 9, 3),
 };
 
+static const struct mtk_pin_field_calc mt8195_pin_rsel_range[] = {
+	PIN_FIELD_BASE(8, 8, 4, 0x0c0, 0x10, 15, 3),
+	PIN_FIELD_BASE(9, 9, 4, 0x0c0, 0x10, 0, 3),
+	PIN_FIELD_BASE(10, 10, 4, 0x0c0, 0x10, 18, 3),
+	PIN_FIELD_BASE(11, 11, 4, 0x0c0, 0x10, 3, 3),
+	PIN_FIELD_BASE(12, 12, 4, 0x0c0, 0x10, 21, 3),
+	PIN_FIELD_BASE(13, 13, 4, 0x0c0, 0x10, 6, 3),
+	PIN_FIELD_BASE(14, 14, 4, 0x0c0, 0x10, 24, 3),
+	PIN_FIELD_BASE(15, 15, 4, 0x0c0, 0x10, 9, 3),
+	PIN_FIELD_BASE(16, 16, 4, 0x0c0, 0x10, 27, 3),
+	PIN_FIELD_BASE(17, 17, 4, 0x0c0, 0x10, 12, 3),
+	PIN_FIELD_BASE(29, 29, 2, 0x080, 0x10, 0, 3),
+	PIN_FIELD_BASE(30, 30, 2, 0x080, 0x10, 3, 3),
+	PIN_FIELD_BASE(34, 34, 1, 0x0e0, 0x10, 0, 3),
+	PIN_FIELD_BASE(35, 35, 1, 0x0e0, 0x10, 3, 3),
+	PIN_FIELD_BASE(44, 44, 1, 0x0e0, 0x10, 6, 3),
+	PIN_FIELD_BASE(45, 45, 1, 0x0e0, 0x10, 9, 3),
+};
+
 static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_MODE] = MTK_RANGE(mt8195_pin_mode_range),
 	[PINCTRL_PIN_REG_DIR] = MTK_RANGE(mt8195_pin_dir_range),
@@ -793,6 +812,7 @@ static const struct mtk_pin_reg_calc mt8195_reg_cals[PINCTRL_PIN_REG_MAX] = {
 	[PINCTRL_PIN_REG_R0] = MTK_RANGE(mt8195_pin_r0_range),
 	[PINCTRL_PIN_REG_R1] = MTK_RANGE(mt8195_pin_r1_range),
 	[PINCTRL_PIN_REG_DRV_ADV] = MTK_RANGE(mt8195_pin_drv_adv_range),
+	[PINCTRL_PIN_REG_RSEL] = MTK_RANGE(mt8195_pin_rsel_range),
 };
 
 static const char * const mt8195_pinctrl_register_base_names[] = {
@@ -823,6 +843,8 @@ static const struct mtk_pin_soc mt8195_data = {
 	.drive_get = mtk_pinconf_drive_get_rev1,
 	.adv_drive_get = mtk_pinconf_adv_drive_get_raw,
 	.adv_drive_set = mtk_pinconf_adv_drive_set_raw,
+	.rsel_set = mtk_pinconf_rsel_set,
+	.rsel_get = mtk_pinconf_rsel_get,
 };
 
 static const struct of_device_id mt8195_pinctrl_of_match[] = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 2b51f4a9b860..d1526d0c6248 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -1041,6 +1041,20 @@ int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 }
 EXPORT_SYMBOL_GPL(mtk_pinconf_adv_drive_get_raw);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg)
+{
+	return mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_RSEL, arg);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_set);
+
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val)
+{
+	return mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_RSEL, val);
+}
+EXPORT_SYMBOL_GPL(mtk_pinconf_rsel_get);
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Sean Wang <sean.wang at mediatek.com>");
 MODULE_DESCRIPTION("Pin configuration library module for mediatek SoCs");
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index fd5ce9c5dcbd..570e8da7bf38 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -67,6 +67,7 @@ enum {
 	PINCTRL_PIN_REG_DRV_E0,
 	PINCTRL_PIN_REG_DRV_E1,
 	PINCTRL_PIN_REG_DRV_ADV,
+	PINCTRL_PIN_REG_RSEL,
 	PINCTRL_PIN_REG_MAX,
 };
 
@@ -237,6 +238,10 @@ struct mtk_pin_soc {
 			     const struct mtk_pin_desc *desc, u32 arg);
 	int (*adv_drive_get)(struct mtk_pinctrl *hw,
 			     const struct mtk_pin_desc *desc, u32 *val);
+	int (*rsel_set)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 arg);
+	int (*rsel_get)(struct mtk_pinctrl *hw,
+			const struct mtk_pin_desc *desc, u32 *val);
 
 	/* Specific driver data */
 	void				*driver_data;
@@ -320,5 +325,10 @@ int mtk_pinconf_adv_drive_set_raw(struct mtk_pinctrl *hw,
 int mtk_pinconf_adv_drive_get_raw(struct mtk_pinctrl *hw,
 				  const struct mtk_pin_desc *desc, u32 *val);
 
+int mtk_pinconf_rsel_set(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_rsel_get(struct mtk_pinctrl *hw,
+			 const struct mtk_pin_desc *desc, u32 *val);
+
 bool mtk_is_virt_gpio(struct mtk_pinctrl *hw, unsigned int gpio_n);
 #endif /* __PINCTRL_MTK_COMMON_V2_H */
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c
index da1f19288aa6..392fdfcb5b87 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -22,6 +22,8 @@
 #define MTK_PIN_CONFIG_PU_ADV	(PIN_CONFIG_END + 3)
 #define MTK_PIN_CONFIG_PD_ADV	(PIN_CONFIG_END + 4)
 #define MTK_PIN_CONFIG_DRV_ADV	(PIN_CONFIG_END + 5)
+#define MTK_PIN_CONFIG_RSEL	(PIN_CONFIG_END + 6)
+
 
 static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,tdsel",	MTK_PIN_CONFIG_TDSEL,		0},
@@ -29,6 +31,7 @@ static const struct pinconf_generic_params mtk_custom_bindings[] = {
 	{"mediatek,pull-up-adv", MTK_PIN_CONFIG_PU_ADV,		1},
 	{"mediatek,pull-down-adv", MTK_PIN_CONFIG_PD_ADV,	1},
 	{"mediatek,drive-strength-adv", MTK_PIN_CONFIG_DRV_ADV,	2},
+	{"mediatek,rsel",		MTK_PIN_CONFIG_RSEL,	2},
 };
 
 #ifdef CONFIG_DEBUG_FS
@@ -38,6 +41,7 @@ static const struct pin_config_item mtk_conf_items[] = {
 	PCONFDUMP(MTK_PIN_CONFIG_PU_ADV, "pu-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_PD_ADV, "pd-adv", NULL, true),
 	PCONFDUMP(MTK_PIN_CONFIG_DRV_ADV, "drive-strength-adv", NULL, true),
+	PCONFDUMP(MTK_PIN_CONFIG_RSEL, "rsel", NULL, true),
 };
 #endif
 
@@ -176,6 +180,12 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_get)
+			err = hw->soc->rsel_get(hw, desc, &ret);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
@@ -295,6 +305,12 @@ static int mtk_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 		else
 			err = -ENOTSUPP;
 		break;
+	case MTK_PIN_CONFIG_RSEL:
+		if (hw->soc->rsel_set)
+			err = hw->soc->rsel_set(hw, desc, arg);
+		else
+			err = -ENOTSUPP;
+		break;
 	default:
 		err = -ENOTSUPP;
 	}
-- 
2.18.0

From ikjn at chromium.org  Mon Apr 26 06:06:22 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Mon, 26 Apr 2021 13:06:22 +0800
Subject: [PATCH v7 00/22] Mediatek MT8192 clock support
In-Reply-To: <20210323113512.4980-1-chun-jie.chen@mediatek.com>
References: <20210323113512.4980-1-chun-jie.chen@mediatek.com>
Message-ID: <CAATdQgD8zGGsW0fDpba5Bf-Xv-DFAwuVSFpKgB33Qxy=5Ds5cg@mail.gmail.com>

On Tue, Mar 23, 2021 at 7:36 PM chun-jie.chen
<chun-jie.chen at mediatek.com> wrote:
>
> change since v6:
> - update from series below
> [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=405295
> - fix DT bindings fail
> - fix checkpatch warning
> - update mux ops without gate control
>
> change since v5:
> - remove unused clocks by rolling Tinghan's patches[1][2] into series
> [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=398781
> [2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=405143
> - remove dts related patches from series
>
> change since v4:
> - merge some subsystem into same driver
> - add a generic probe function to reduce duplicated code
>
> changes since v3:
> - add critical clocks
> - split large patches into small ones
>
> changes since v2:
> - update and split dt-binding documents by functionalities
> - add error checking in probe() function
> - fix incorrect clock relation and add critical clocks
> - update license identifier and minor fix of coding style
>
> changes since v1:
> - fix asymmetrical control of PLL
> - have en_mask used as divider enable mask on all MediaTek SoC
>
> chun-jie.chen (22):
>   dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c
>     wrapper controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of mdpsys
>     controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of msdc
>     controller
>   dt-bindings: ARM: Mediatek: Add new document bindings of scp adsp
>     controller
>   dt-bindings: ARM: Mediatek: Document bindings of MT8192 clock
>     controllers
>   clk: mediatek: Add dt-bindings of MT8192 clocks
>   clk: mediatek: Fix asymmetrical PLL enable and disable control
>   clk: mediatek: Add configurable enable control to mtk_pll_data
>   clk: mediatek: Add mtk_clk_simple_probe() to simplify clock providers
>   clk: mediatek: Add MT8192 basic clocks support
>   clk: mediatek: Add MT8192 audio clock support
>   clk: mediatek: Add MT8192 camsys clock support
>   clk: mediatek: Add MT8192 imgsys clock support
>   clk: mediatek: Add MT8192 imp i2c wrapper clock support
>   clk: mediatek: Add MT8192 ipesys clock support
>   clk: mediatek: Add MT8192 mdpsys clock support
>   clk: mediatek: Add MT8192 mfgcfg clock support
>   clk: mediatek: Add MT8192 mmsys clock support
>   clk: mediatek: Add MT8192 msdc clock support
>   clk: mediatek: Add MT8192 scp adsp clock support
>   clk: mediatek: Add MT8192 vdecsys clock support
>   clk: mediatek: Add MT8192 vencsys clock support
>
>  .../arm/mediatek/mediatek,apmixedsys.txt      |    1 +
>  .../bindings/arm/mediatek/mediatek,audsys.txt |    1 +
>  .../bindings/arm/mediatek/mediatek,camsys.txt |   22 +
>  .../bindings/arm/mediatek/mediatek,imgsys.txt |    2 +
>  .../arm/mediatek/mediatek,imp_iic_wrap.yaml   |   80 +
>  .../arm/mediatek/mediatek,infracfg.txt        |    1 +
>  .../bindings/arm/mediatek/mediatek,ipesys.txt |    1 +
>  .../arm/mediatek/mediatek,mdpsys.yaml         |   40 +
>  .../bindings/arm/mediatek/mediatek,mfgcfg.txt |    1 +
>  .../bindings/arm/mediatek/mediatek,mmsys.txt  |    1 +
>  .../bindings/arm/mediatek/mediatek,msdc.yaml  |   48 +
>  .../arm/mediatek/mediatek,pericfg.yaml        |    1 +
>  .../arm/mediatek/mediatek,scp-adsp.yaml       |   40 +
>  .../arm/mediatek/mediatek,topckgen.txt        |    1 +
>  .../arm/mediatek/mediatek,vdecsys.txt         |    8 +
>  .../arm/mediatek/mediatek,vencsys.txt         |    1 +
>  drivers/clk/mediatek/Kconfig                  |   80 +
>  drivers/clk/mediatek/Makefile                 |   13 +
>  drivers/clk/mediatek/clk-mt8192-aud.c         |  118 ++
>  drivers/clk/mediatek/clk-mt8192-cam.c         |  107 ++
>  drivers/clk/mediatek/clk-mt8192-img.c         |   70 +
>  .../clk/mediatek/clk-mt8192-imp_iic_wrap.c    |  119 ++
>  drivers/clk/mediatek/clk-mt8192-ipe.c         |   57 +
>  drivers/clk/mediatek/clk-mt8192-mdp.c         |   82 +
>  drivers/clk/mediatek/clk-mt8192-mfg.c         |   50 +
>  drivers/clk/mediatek/clk-mt8192-mm.c          |  108 ++
>  drivers/clk/mediatek/clk-mt8192-msdc.c        |   85 ++
>  drivers/clk/mediatek/clk-mt8192-scp_adsp.c    |   50 +
>  drivers/clk/mediatek/clk-mt8192-vdec.c        |   94 ++
>  drivers/clk/mediatek/clk-mt8192-venc.c        |   53 +
>  drivers/clk/mediatek/clk-mt8192.c             | 1326 +++++++++++++++++
>  drivers/clk/mediatek/clk-mtk.c                |   23 +
>  drivers/clk/mediatek/clk-mtk.h                |   28 +-
>  drivers/clk/mediatek/clk-mux.c                |    9 +-
>  drivers/clk/mediatek/clk-mux.h                |   18 +-
>  drivers/clk/mediatek/clk-pll.c                |   31 +-
>  include/dt-bindings/clock/mt8192-clk.h        |  585 ++++++++
>  37 files changed, 3335 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-aud.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-cam.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-imp_iic_wrap.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-ipe.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mdp.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mfg.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-msdc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-scp_adsp.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8192.c
>  create mode 100644 include/dt-bindings/clock/mt8192-clk.h
>
> --
> 2.18.0
>

A gentle ping on this series.

Thanks!

>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From nadeem at cadence.com  Mon Apr 26 06:14:27 2021
From: nadeem at cadence.com (Nadeem Athani)
Date: Mon, 26 Apr 2021 07:14:27 +0200
Subject: [PATCH] PCI: cadence: Set LTSSM Detect Quiet state minimum delay as
 workaround for training defect.
Message-ID: <20210426051427.15945-1-nadeem@cadence.com>

Adding a quirk flag "quirk_detect_quiet_flag" to program the minimum
time that LTSSM waits on entering Detect.Quiet state.
Setting this to 2ms for specific TI j7200 SOC as a workaround to resolve
a link training issue in IP.
In future revisions this setting will not be required.

As per PCIe specification, all Receivers must meet the Z-RX-DC
specification for 2.5 GT/s within 1ms of entering Detect.Quiet LTSSM
substate. The LTSSM must stay in this substate until the ZRXDC
specification for 2.5 GT/s is met.

00 : 0 minimum wait time in Detect.Quiet state.
01 : 100us minimum wait time in Detect.Quiet state.
10 : 1ms minimum wait time in Detect.Quiet state.
11 : 2ms minimum wait time in Detect.Quiet state.

Signed-off-by: Nadeem Athani <nadeem at cadence.com>
---
 drivers/pci/controller/cadence/pcie-cadence-ep.c   | 21 +++++++++++++++++++++
 drivers/pci/controller/cadence/pcie-cadence-host.c | 21 +++++++++++++++++++++
 drivers/pci/controller/cadence/pcie-cadence.h      | 12 ++++++++++++
 3 files changed, 54 insertions(+)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 897cdde02bd8..245771f03c21 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -552,6 +552,23 @@ static const struct pci_epc_ops cdns_pcie_epc_ops = {
 	.get_features	= cdns_pcie_ep_get_features,
 };
 
+static void cdns_pcie_detect_quiet_min_delay_set(struct cdns_pcie_ep *ep)
+{
+	struct cdns_pcie *pcie = &ep->pcie;
+	u32 delay = 0x3;
+	u32 ltssm_control_cap;
+
+	/*
+	 * Set the LTSSM Detect Quiet state min. delay to 2ms.
+	 */
+
+	ltssm_control_cap = cdns_pcie_readl(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP);
+	ltssm_control_cap = ((ltssm_control_cap &
+			    ~CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK) |
+			    CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay));
+
+	cdns_pcie_writel(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP, ltssm_control_cap);
+}
 
 int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 {
@@ -623,6 +640,10 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
 	ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE;
 	/* Reserve region 0 for IRQs */
 	set_bit(0, &ep->ob_region_map);
+
+	if (ep->quirk_detect_quiet_flag)
+		cdns_pcie_detect_quiet_min_delay_set(ep);
+
 	spin_lock_init(&ep->lock);
 
 	return 0;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c
index ae1c55503513..ffc2dbeb1240 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -462,6 +462,24 @@ static int cdns_pcie_host_init(struct device *dev,
 	return cdns_pcie_host_init_address_translation(rc);
 }
 
+static void cdns_pcie_detect_quiet_min_delay_set(struct cdns_pcie_rc *rc)
+{
+	struct cdns_pcie *pcie = &rc->pcie;
+	u32 delay = 0x3;
+	u32 ltssm_control_cap;
+
+	/*
+	 * Set the LTSSM Detect Quiet state min. delay to 2ms.
+	 */
+
+	ltssm_control_cap = cdns_pcie_readl(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP);
+	ltssm_control_cap = ((ltssm_control_cap &
+			    ~CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK) |
+			    CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay));
+
+	cdns_pcie_writel(pcie, CDNS_PCIE_LTSSM_CONTROL_CAP, ltssm_control_cap);
+}
+
 int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
 {
 	struct device *dev = rc->pcie.dev;
@@ -498,6 +516,9 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
 		return PTR_ERR(rc->cfg_base);
 	rc->cfg_res = res;
 
+	if (rc->quirk_detect_quiet_flag)
+		cdns_pcie_detect_quiet_min_delay_set(rc);
+
 	ret = cdns_pcie_start_link(pcie);
 	if (ret) {
 		dev_err(dev, "Failed to start link\n");
diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
index 254d2570f8c9..d074475fe887 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.h
+++ b/drivers/pci/controller/cadence/pcie-cadence.h
@@ -189,6 +189,14 @@
 /* AXI link down register */
 #define CDNS_PCIE_AT_LINKDOWN (CDNS_PCIE_AT_BASE + 0x0824)
 
+/* LTSSM Capabilities register */
+#define CDNS_PCIE_LTSSM_CONTROL_CAP             (CDNS_PCIE_LM_BASE + 0x0054)
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK  GENMASK(2, 1)
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT 1
+#define  CDNS_PCIE_DETECT_QUIET_MIN_DELAY(delay) \
+	 (((delay) << CDNS_PCIE_DETECT_QUIET_MIN_DELAY_SHIFT) & \
+	 CDNS_PCIE_DETECT_QUIET_MIN_DELAY_MASK)
+
 enum cdns_pcie_rp_bar {
 	RP_BAR_UNDEFINED = -1,
 	RP_BAR0,
@@ -292,6 +300,7 @@ struct cdns_pcie {
  * @avail_ib_bar: Satus of RP_BAR0, RP_BAR1 and	RP_NO_BAR if it's free or
  *                available
  * @quirk_retrain_flag: Retrain link as quirk for PCIe Gen2
+ * @quirk_detect_quiet_flag: LTSSM Detect Quiet min delay set as quirk
  */
 struct cdns_pcie_rc {
 	struct cdns_pcie	pcie;
@@ -301,6 +310,7 @@ struct cdns_pcie_rc {
 	u32			device_id;
 	bool			avail_ib_bar[CDNS_PCIE_RP_MAX_IB];
 	bool                    quirk_retrain_flag;
+	bool			quirk_detect_quiet_flag;
 };
 
 /**
@@ -331,6 +341,7 @@ struct cdns_pcie_epf {
  *        registers fields (RMW) accessible by both remote RC and EP to
  *        minimize time between read and write
  * @epf: Structure to hold info about endpoint function
+ * @quirk_detect_quiet_flag: LTSSM Detect Quiet min delay set as quirk
  */
 struct cdns_pcie_ep {
 	struct cdns_pcie	pcie;
@@ -345,6 +356,7 @@ struct cdns_pcie_ep {
 	/* protect writing to PCI_STATUS while raising legacy interrupts */
 	spinlock_t		lock;
 	struct cdns_pcie_epf	*epf;
+	bool                    quirk_detect_quiet_flag;
 };
 
 
-- 
2.15.0



From hsinyi at chromium.org  Mon Apr 26 06:18:47 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Mon, 26 Apr 2021 13:18:47 +0800
Subject: [PATCH v2 1/2] gpu: drm: init set panel orientation property earlier
Message-ID: <20210426051848.2600890-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Create panel orientation property in drm_connector_init()
and set default value to UNKNOWN. Let the panel set the real value
later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
v1:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
---
 drivers/gpu/drm/drm_connector.c | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..a1acb4af0ef4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -303,6 +303,10 @@ int drm_connector_init(struct drm_device *dev,
 				   config->tile_property,
 				   0);
 
+	drm_object_attach_property(&connector->base,
+				   config->panel_orientation_property,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
 	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
 	}
@@ -1210,7 +1214,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -1298,6 +1302,14 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
 		return -ENOMEM;
 	dev->mode_config.hdr_output_metadata_property = prop;
 
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+					"panel orientation",
+					drm_panel_orientation_enum_list,
+					ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+	dev->mode_config.panel_orientation_property = prop;
+
 	return 0;
 }
 
@@ -2205,19 +2217,9 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Mon Apr 26 06:18:48 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Mon, 26 Apr 2021 13:18:48 +0800
Subject: [PATCH v2 2/2] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210426051848.2600890-1-hsinyi@chromium.org>
References: <20210426051848.2600890-1-hsinyi@chromium.org>
Message-ID: <20210426051848.2600890-2-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Mon Apr 26 06:19:59 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Mon, 26 Apr 2021 13:19:59 +0800
Subject: [PATCH 1/2] drm/mediatek: set panel orientation before
 drm_dev_register().
In-Reply-To: <CAMavQKJUpYP8jo2JDGMYNBGtbPSSO7z9BAComm5JQoty=HPtJg@mail.gmail.com>
References: <20210409045314.3420733-1-hsinyi@chromium.org>
 <CAMavQKJUpYP8jo2JDGMYNBGtbPSSO7z9BAComm5JQoty=HPtJg@mail.gmail.com>
Message-ID: <CAJMQK-govRgDfKhzxhe-GPBQ27EEfpmsxbbNH6X=6CTni=uqRA@mail.gmail.com>

On Fri, Apr 23, 2021 at 9:53 PM Sean Paul <sean at poorly.run> wrote:
>
> On Fri, Apr 9, 2021 at 12:53 AM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning. So set panel orientation in dsi before drm_dev_register() is
> > called.
> >
> > [    4.480976] ------------[ cut here ]------------
> > [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> > <snip>
> > [    4.609772] Call trace:
> > [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> > [    4.616466]  drm_mode_object_add+0x20/0x2c
> > [    4.620552]  drm_property_create+0xdc/0x174
> > [    4.624723]  drm_property_create_enum+0x34/0x98
> > [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> > [    4.634716]  boe_panel_get_modes+0x88/0xd8
> > [    4.638802]  drm_panel_get_modes+0x2c/0x48
> > [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> > [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.662699]  drm_ioctl_kernel+0xac/0x128
> > [    4.666611]  drm_ioctl+0x268/0x410
> > [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> > [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.678436]  el0_svc_common+0xf4/0x1c0
> > [    4.682174]  do_el0_svc_compat+0x28/0x3c
> > [    4.686088]  el0_svc_compat+0x10/0x1c
> > [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.694171]  el0_sync_compat+0x178/0x180
> > [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> > [    4.702721] ------------[ cut here ]------------
> > [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> > <snip>
> > [    4.833830] Call trace:
> > [    4.836266]  drm_object_attach_property+0x48/0xb8
> > [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> > [    4.846432]  boe_panel_get_modes+0x88/0xd8
> > [    4.850516]  drm_panel_get_modes+0x2c/0x48
> > [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> > [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.874410]  drm_ioctl_kernel+0xac/0x128
> > [    4.878320]  drm_ioctl+0x268/0x410
> > [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> > [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.890142]  el0_svc_common+0xf4/0x1c0
> > [    4.893879]  do_el0_svc_compat+0x28/0x3c
> > [    4.897791]  el0_svc_compat+0x10/0x1c
> > [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.905873]  el0_sync_compat+0x178/0x180
> > [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index ae403c67cbd9..45a702ee09f3 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -205,6 +205,7 @@ struct mtk_dsi {
> >         u32 irq_data;
> >         wait_queue_head_t irq_wait_queue;
> >         const struct mtk_dsi_driver_data *driver_data;
> > +       enum drm_panel_orientation orientation;
> >  };
> >
> >  static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> > @@ -966,6 +967,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> >         }
> >         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> >
> > +       drm_connector_set_panel_orientation(dsi->connector, dsi->orientation);
> > +
> >         return 0;
> >
> >  err_cleanup_encoder:
> > @@ -1029,6 +1032,12 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> >                         ret = PTR_ERR(dsi->next_bridge);
> >                         goto err_unregister_host;
> >                 }
> > +
> > +               ret = of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation);
> > +               if (ret) {
> > +                       dev_err(dev, "failed to get panel orientation %d\n", ret);
> > +                       return ret;
> > +               }
>
> I don't think this is the right place to mine orientation since it
> duplicates the call from the panel driver.
>
> Instead, how about splitting out
> property_create_enum/attach_orientation_property from
> set_panel_orientation such that you can attach the property (with
> UNKNOWN value) in the connector init and then leave the panel to set
> it properly in get_modes (I kind of disagree with populating this in
> get_modes as well, but I don't think there's anywhere else to stick it
> right now)?
>
> AFAICT orientation is the only property which has the create/attach
> calls in the set function which seems like a perfect recipe for this
> type of failure.
>
>
> Sean
>

Thanks for the review. It is updated in v2.

> >         }
> >
> >         dsi->driver_data = of_device_get_match_data(dev);
> > --
> > 2.31.1.295.g9ea45b61b8-goog
> >


From rppt at kernel.org  Mon Apr 26 06:20:43 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Mon, 26 Apr 2021 08:20:43 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
Message-ID: <YIZNq5HMfJ1rWytv@kernel.org>

On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/25 15:19, Mike Rapoport wrote:
> 
>     On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> 
>         I tested this patchset(plus arm32 change, like arm64 does) based on lts
>         5.10?add
> 
>         some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
>         panic,
> 
>         any idea, thanks.
> 
> 
>     Are there any changes on top of 5.10 except for pfn_valid() patch?
>     Do you see this panic on 5.10 without the changes?
> 
> Yes, there are some BSP support for arm board based on 5.10, with or without
> 
> your patch will get same panic, the panic pfn=de600 in the range of
> [dcc00,de00]
> 
> which is freed by free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700,
> de700000
> 
> we see the PC is at PageLRU, same reason like arm64 panic log,
> 
>    "PageBuddy in move_freepages returns false
>     Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>     compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>     resturns 0xfffffffffffffffe - and accessing this address causes crash"
> 
>     Can you see stack backtrace beyond move_freepages_block?
> 
> I do some oom test, so the log is about memory allocate,
> 
> [<c02383c8>] (move_freepages_block) from [<c0238668>]
> (steal_suitable_fallback+0x174/0x1f4)
> 
> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)

Hmm, this is called with a page from free list, having a page from a freed
part of the memory map passed to steal_suitable_fallback() means that there
is an issue with creation of the free list.

Can you please add "memblock=debug" to the kernel command line and post the
log?

> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
> 
> 
> 
>         Zone ranges:
>         ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
>         ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
>         Movable zone start for each node
>         Early memory node ranges
>         ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
>         ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
>         ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
>         ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
>         ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
>         ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>         ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
>         ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>         ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>         ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
> 
>         ----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
>         ----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
>         ----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
>         ----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
>         ----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
>         ----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
>         ----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
>         === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>         :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>         8<--- cut here ---
>         Unable to handle kernel paging request at virtual address fffffffe
>         pgd = 5dd50df5
>         [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>         Internal error: Oops: 37 [#1] SMP ARM
>         Modules linked in: gmac(O)
>         CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
>         Hardware name: Hisilicon A9
>         PC is at move_freepages_block+0x150/0x278
>         LR is at move_freepages_block+0x150/0x278
>         pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
>         sp : c4179cf8? ip : 00000000? fp : 00000001
>         r10: c4179d58? r9 : 000de7ff? r8 : 00000000
>         r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
>         r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
>         Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
>         Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
>         Process test-oom (pid: 635, stack limit = 0x25d667df)
> 
> 

-- 
Sincerely yours,
Mike.


From egorenar at linux.ibm.com  Mon Apr 26 08:35:11 2021
From: egorenar at linux.ibm.com (Alexander Egorenkov)
Date: Mon, 26 Apr 2021 09:35:11 +0200
Subject: [PATCH v4 05/10] signal: Introduce TRAP_PERF si_code and si_perf
 to siginfo
In-Reply-To: <CANpmjNPbMOUd_Wh5aHGdH8WLrYpyBFUpwx6g3Kj2D6eevvaU8w@mail.gmail.com>
References: <CANpmjNPbMOUd_Wh5aHGdH8WLrYpyBFUpwx6g3Kj2D6eevvaU8w@mail.gmail.com>
Message-ID: <20210426073511.270990-1-egorenar@linux.ibm.com>

Hi,

this also fixes s390.
strace's tests-m32 on s390 were failing.

Regards
Alex


From ykaukab at suse.de  Mon Apr 26 08:52:11 2021
From: ykaukab at suse.de (Mian Yousaf Kaukab)
Date: Mon, 26 Apr 2021 09:52:11 +0200
Subject: [PATCH v2] arm64: dts: ls1012a: enable PCIe on freeway board
Message-ID: <20210426075211.30467-1-ykaukab@suse.de>

ls1012a-freeway board contains a M.2 2230 slot. Update the status of
pcei1 node to okay so that the pcie controller can be probed.

Signed-off-by: Mian Yousaf Kaukab <ykaukab at suse.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
index 6290e2f9de6a..e8562585d4ac 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
@@ -24,6 +24,10 @@ &i2c0 {
 	status = "okay";
 };
 
+&pcie1 {
+	status = "okay";
+};
+
 &qspi {
 	status = "okay";
 
-- 
2.26.2



From zhang.lyra at gmail.com  Mon Apr 26 09:07:34 2021
From: zhang.lyra at gmail.com (Chunyan Zhang)
Date: Mon, 26 Apr 2021 16:07:34 +0800
Subject: [PATCH 2/2] thermal: sprd: add missing of_node_put for loop
 iteration
In-Reply-To: <20210425174831.164332-2-krzysztof.kozlowski@canonical.com>
References: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>
 <20210425174831.164332-2-krzysztof.kozlowski@canonical.com>
Message-ID: <CAAfSe-tyAm1y-LV5LiiF_X6-ExFD3P9CxOwu+m2ZrLC5wdrnkQ@mail.gmail.com>

On Mon, 26 Apr 2021 at 01:48, Krzysztof Kozlowski
<krzysztof.kozlowski at canonical.com> wrote:
>
> Early exits from for_each_available_child_of_node() should decrement the
> node reference counter.  Reported by Coccinelle:
>
>   drivers/thermal/sprd_thermal.c:387:1-23: WARNING:
>     Function "for_each_child_of_node" should have of_node_put() before goto around lines 391.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

Acked-by: Chunyan Zhang <zhang.lyra at gmail.com>

Thanks for fixing this.

> ---
>  drivers/thermal/sprd_thermal.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/sprd_thermal.c b/drivers/thermal/sprd_thermal.c
> index 3682edb2f466..2778971aaf03 100644
> --- a/drivers/thermal/sprd_thermal.c
> +++ b/drivers/thermal/sprd_thermal.c
> @@ -388,6 +388,7 @@ static int sprd_thm_probe(struct platform_device *pdev)
>                 sen = devm_kzalloc(&pdev->dev, sizeof(*sen), GFP_KERNEL);
>                 if (!sen) {
>                         ret = -ENOMEM;
> +                       of_node_put(sen_child);
>                         goto disable_clk;
>                 }
>
> @@ -397,12 +398,14 @@ static int sprd_thm_probe(struct platform_device *pdev)
>                 ret = of_property_read_u32(sen_child, "reg", &sen->id);
>                 if (ret) {
>                         dev_err(&pdev->dev, "get sensor reg failed");
> +                       of_node_put(sen_child);
>                         goto disable_clk;
>                 }
>
>                 ret = sprd_thm_sensor_calibration(sen_child, thm, sen);
>                 if (ret) {
>                         dev_err(&pdev->dev, "efuse cal analysis failed");
> +                       of_node_put(sen_child);
>                         goto disable_clk;
>                 }
>
> @@ -416,6 +419,7 @@ static int sprd_thm_probe(struct platform_device *pdev)
>                         dev_err(&pdev->dev, "register thermal zone failed %d\n",
>                                 sen->id);
>                         ret = PTR_ERR(sen->tzd);
> +                       of_node_put(sen_child);
>                         goto disable_clk;
>                 }
>
> --
> 2.25.1
>


From krzysztof.kozlowski at canonical.com  Mon Apr 26 09:28:43 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 10:28:43 +0200
Subject: [PATCH v2 01/10] memory: tegra: Implement SID override programming
In-Reply-To: <20210420172619.3782831-2-thierry.reding@gmail.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
 <20210420172619.3782831-2-thierry.reding@gmail.com>
Message-ID: <03e2a655-7dbf-a729-75f6-98db353e2b91@canonical.com>

On 20/04/2021 19:26, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Instead of programming all SID overrides during early boot, perform the
> operation on-demand after the SMMU translations have been set up for a
> device. This reuses data from device tree to match memory clients for a
> device and programs the SID specified in device tree, which corresponds
> to the SID used for the SMMU context banks for the device.
> 
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
>  drivers/memory/tegra/mc.c       |  9 +++++
>  drivers/memory/tegra/tegra186.c | 72 +++++++++++++++++++++++++++++++++
>  include/soc/tegra/mc.h          |  3 ++
>  3 files changed, 84 insertions(+)
> 
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index c854639cf30c..bace5ecfe770 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -97,6 +97,15 @@ struct tegra_mc *devm_tegra_memory_controller_get(struct device *dev)
>  }
>  EXPORT_SYMBOL_GPL(devm_tegra_memory_controller_get);
>  
> +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> +{
> +	if (mc->soc->ops && mc->soc->ops->probe_device)
> +		return mc->soc->ops->probe_device(mc, dev);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(tegra_mc_probe_device);
> +
>  static int tegra_mc_block_dma_common(struct tegra_mc *mc,
>  				     const struct tegra_mc_reset *rst)
>  {
> diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> index 1f87915ccd62..e65eac5764d4 100644
> --- a/drivers/memory/tegra/tegra186.c
> +++ b/drivers/memory/tegra/tegra186.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include <linux/io.h>
> +#include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/mod_devicetable.h>
>  #include <linux/of_device.h>
> @@ -15,6 +16,10 @@
>  #include <dt-bindings/memory/tegra186-mc.h>
>  #endif
>  
> +#define MC_SID_STREAMID_OVERRIDE_MASK GENMASK(7, 0)
> +#define MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED BIT(16)
> +#define MC_SID_STREAMID_SECURITY_OVERRIDE BIT(8)
> +
>  static void tegra186_mc_program_sid(struct tegra_mc *mc)
>  {
>  	unsigned int i;
> @@ -66,10 +71,77 @@ static int tegra186_mc_resume(struct tegra_mc *mc)
>  	return 0;
>  }
>  
> +static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> +					    const struct tegra_mc_client *client,
> +					    unsigned int sid)
> +{
> +	u32 value, old;
> +
> +	value = readl(mc->regs + client->regs.sid.security);
> +	if ((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0) {
> +		/*
> +		 * If the secure firmware has locked this down the override
> +		 * for this memory client, there's nothing we can do here.
> +		 */
> +		if (value & MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED)
> +			return;
> +
> +		/*
> +		 * Otherwise, try to set the override itself. Typically the
> +		 * secure firmware will never have set this configuration.
> +		 * Instead, it will either have disabled write access to
> +		 * this field, or it will already have set an explicit
> +		 * override itself.
> +		 */
> +		WARN_ON((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0);
> +
> +		value |= MC_SID_STREAMID_SECURITY_OVERRIDE;
> +		writel(value, mc->regs + client->regs.sid.security);
> +	}
> +
> +	value = readl(mc->regs + client->regs.sid.override);
> +	old = value & MC_SID_STREAMID_OVERRIDE_MASK;
> +
> +	if (old != sid) {
> +		dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
> +			client->name, sid);
> +		writel(sid, mc->regs + client->regs.sid.override);
> +	}
> +}
> +
> +static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> +{
> +#if IS_ENABLED(CONFIG_IOMMU_API)

Is this part really build-time dependent? I don't see here any uses of
IOMMU specific fields, so maybe this should be runtime choice based on
enabled interconnect devices?

> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +	struct of_phandle_args args;
> +	unsigned int i, index = 0;
> +
> +	while (!of_parse_phandle_with_args(dev->of_node, "interconnects", "#interconnect-cells",
> +					   index, &args)) {
> +		if (args.np == mc->dev->of_node && args.args_count != 0) {
> +			for (i = 0; i < mc->soc->num_clients; i++) {
> +				const struct tegra_mc_client *client = &mc->soc->clients[i];
> +
> +				if (client->id == args.args[0]) {
> +					u32 sid = fwspec->ids[0] & MC_SID_STREAMID_OVERRIDE_MASK;
> +
> +					tegra186_mc_client_sid_override(mc, client, sid);
> +				}
> +			}
> +		}
> +
> +		index++;
> +	}
> +#endif
> +
> +	return 0;
> +}
> +
>  const struct tegra_mc_ops tegra186_mc_ops = {
>  	.probe = tegra186_mc_probe,
>  	.remove = tegra186_mc_remove,
>  	.resume = tegra186_mc_resume,
> +	.probe_device = tegra186_mc_probe_device,
>  };
>  
>  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> index 1387747d574b..bbad6330008b 100644
> --- a/include/soc/tegra/mc.h
> +++ b/include/soc/tegra/mc.h
> @@ -176,6 +176,7 @@ struct tegra_mc_ops {
>  	int (*suspend)(struct tegra_mc *mc);
>  	int (*resume)(struct tegra_mc *mc);
>  	irqreturn_t (*handle_irq)(int irq, void *data);
> +	int (*probe_device)(struct tegra_mc *mc, struct device *dev);
>  };
>  
>  struct tegra_mc_soc {
> @@ -240,4 +241,6 @@ devm_tegra_memory_controller_get(struct device *dev)
>  }
>  #endif
>  
> +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
> +

What about !CONFIG_TEGRA_MC? I think arm-smmmu will fail.

>  #endif /* __SOC_TEGRA_MC_H__ */
> 


Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Mon Apr 26 09:47:11 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 10:47:11 +0200
Subject: [PATCH 03/10] memory: tegra: Push suspend/resume into SoC drivers
In-Reply-To: <20210420165237.3523732-4-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-4-thierry.reding@gmail.com>
Message-ID: <d1626fd2-90e3-7a26-51b8-497a344aee6f@canonical.com>

On 20/04/2021 18:52, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Continuing the scheme of unification, push suspend/resume callbacks into
> per-SoC driver so that they can be properly parameterized.
> 
> While at it, also move the ->init() callback into the new tegra_mc_ops
> structure to keep things clean.

Please split this part. This is just moving pointer from one structure
to another, quite small change.

The rest of the patchset is quite different - you now call
tegra_mc_suspend() from a per-SoC driver and move the code around.

> 
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
>  drivers/memory/tegra/mc.c       | 24 ++++++++---------------
>  drivers/memory/tegra/tegra186.c | 27 ++++++++++++++++++++++----
>  drivers/memory/tegra/tegra20.c  | 34 ++++++++++++++++++++++++++++++++-
>  include/soc/tegra/mc.h          |  9 +++++++--
>  4 files changed, 71 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index b7e104bf6614..2b21131d779c 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -829,8 +829,8 @@ static int tegra_mc_probe(struct platform_device *pdev)
>  
>  	mc->debugfs.root = debugfs_create_dir("mc", NULL);
>  
> -	if (mc->soc->init) {
> -		err = mc->soc->init(mc);
> +	if (mc->soc->ops && mc->soc->ops->init) {
> +		err = mc->soc->ops->init(mc);
>  		if (err < 0)
>  			dev_err(&pdev->dev, "failed to initialize SoC driver: %d\n",
>  				err);
> @@ -867,30 +867,22 @@ static int tegra_mc_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static int tegra_mc_suspend(struct device *dev)
> +static int __maybe_unused tegra_mc_suspend(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
> -	int err;
>  
> -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> -		err = tegra_gart_suspend(mc->gart);
> -		if (err)
> -			return err;
> -	}
> +	if (mc->soc->ops && mc->soc->ops->suspend)
> +		return mc->soc->ops->suspend(mc);
>  
>  	return 0;
>  }
>  
> -static int tegra_mc_resume(struct device *dev)
> +static int __maybe_unused tegra_mc_resume(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
> -	int err;
>  
> -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> -		err = tegra_gart_resume(mc->gart);
> -		if (err)
> -			return err;
> -	}
> +	if (mc->soc->ops && mc->soc->ops->resume)
> +		return mc->soc->ops->resume(mc);
>  
>  	return 0;
>  }
> diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> index 8e77567d1378..9d3fdb609d55 100644
> --- a/drivers/memory/tegra/tegra186.c
> +++ b/drivers/memory/tegra/tegra186.c
> @@ -45,6 +45,17 @@ static void tegra186_mc_program_sid(struct tegra_mc *mc)
>  	}
>  }
>  
> +static int tegra186_mc_resume(struct tegra_mc *mc)
> +{
> +	tegra186_mc_program_sid(mc);
> +
> +	return 0;
> +}
> +
> +static const struct tegra_mc_ops tegra186_mc_ops = {
> +	.resume = tegra186_mc_resume,
> +};
> +
>  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
>  static const struct tegra_mc_client tegra186_mc_clients[] = {
>  	{
> @@ -701,6 +712,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
>  static const struct tegra_mc_soc tegra186_mc_soc = {
>  	.num_clients = ARRAY_SIZE(tegra186_mc_clients),
>  	.clients = tegra186_mc_clients,
> +	.ops = &tegra186_mc_ops,
>  };
>  #endif
>  
> @@ -1909,6 +1921,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
>  static const struct tegra_mc_soc tegra194_mc_soc = {
>  	.num_clients = ARRAY_SIZE(tegra194_mc_clients),
>  	.clients = tegra194_mc_clients,
> +	.ops = &tegra186_mc_ops,
>  };
>  #endif
>  
> @@ -1961,22 +1974,28 @@ static const struct of_device_id tegra186_mc_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, tegra186_mc_of_match);
>  
> -static int __maybe_unused tegra186_mc_suspend(struct device *dev)
> +static int __maybe_unused tegra_mc_suspend(struct device *dev)
>  {
> +	struct tegra_mc *mc = dev_get_drvdata(dev);
> +
> +	if (mc->soc->ops && mc->soc->ops->suspend)
> +		return mc->soc->ops->suspend(mc);
> +
>  	return 0;
>  }
>  
> -static int __maybe_unused tegra186_mc_resume(struct device *dev)
> +static int __maybe_unused tegra_mc_resume(struct device *dev)
>  {
>  	struct tegra_mc *mc = dev_get_drvdata(dev);
>  
> -	tegra186_mc_program_sid(mc);
> +	if (mc->soc->ops && mc->soc->ops->resume)
> +		return mc->soc->ops->resume(mc);
>  
>  	return 0;
>  }
>  
>  static const struct dev_pm_ops tegra186_mc_pm_ops = {
> -	SET_SYSTEM_SLEEP_PM_OPS(tegra186_mc_suspend, tegra186_mc_resume)
> +	SET_SYSTEM_SLEEP_PM_OPS(tegra_mc_suspend, tegra_mc_resume)

What's the benefit here? You basically define your own suspend-resume
ops, on top of PM suspend-resume ops... Before it was quite obvious code
- the Tegra186 MC driver had very simple suspend/resume which did simple
job. Now it feels like trickier code to follow - Tegra186 driver calls
it's resume (with the same name as others - another confusion) which is
a simple wrapper calling somewhere else (need to jump to assinment of
resume()).


Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Mon Apr 26 09:49:52 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 10:49:52 +0200
Subject: [PATCH 04/10] memory: tegra: Make per-SoC setup more generic
In-Reply-To: <20210420165237.3523732-5-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-5-thierry.reding@gmail.com>
Message-ID: <200ebdd4-bee0-caf3-e0b6-f4ba5e55b0e6@canonical.com>

On 20/04/2021 18:52, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> The current per-SoC setup code runs at a fairly arbitrary point during
> probe, thereby making it less flexible for other SoC generations. Move
> the call around slightly, which will allow it to be used for other
> implementations.

You moved from one arbitrary point to another - please therefore explain
the rationale of new arbitrary point a little bit more (e.g. after clock
initialization? before HW access?) and put it next to struct tegra_mc_ops.


Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Mon Apr 26 09:58:27 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 10:58:27 +0200
Subject: [PATCH 05/10] memory: tegra: Extract setup code into callback
In-Reply-To: <20210420165237.3523732-6-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-6-thierry.reding@gmail.com>
Message-ID: <25ea4721-f9d3-ae4e-6310-73182ad43d8f@canonical.com>

On 20/04/2021 18:52, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Separate the setup code for Tegra30 and later into a ->setup() callback
> and set it for all applicable chips.

I assume the code is functionally equivalent - the same
tegra_mc_setup_latency_allowance() will be executed on all these SoCs?


Best regards,
Krzysztof


From will at kernel.org  Mon Apr 26 09:58:36 2021
From: will at kernel.org (Will Deacon)
Date: Mon, 26 Apr 2021 09:58:36 +0100
Subject: [PATCH 3/4] crypto: arm64: generate *.S by Perl at build time
 instead of shipping them
In-Reply-To: <20210425175734.1310191-3-masahiroy@kernel.org>
References: <20210425175734.1310191-1-masahiroy@kernel.org>
 <20210425175734.1310191-3-masahiroy@kernel.org>
Message-ID: <20210426085836.GA5802@willie-the-truck>

[+Ard]

On Mon, Apr 26, 2021 at 02:57:33AM +0900, Masahiro Yamada wrote:
> Generate *.S by Perl like arch/{mips,x86}/crypto/Makefile.
> 
> Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
> ---
> 
>  arch/arm64/crypto/Makefile                |    9 +-
>  arch/arm64/crypto/poly1305-core.S_shipped |  835 ---------
>  arch/arm64/crypto/sha256-core.S_shipped   | 2069 ---------------------
>  arch/arm64/crypto/sha512-core.S_shipped   | 1093 -----------
>  4 files changed, 3 insertions(+), 4003 deletions(-)
>  delete mode 100644 arch/arm64/crypto/poly1305-core.S_shipped
>  delete mode 100644 arch/arm64/crypto/sha256-core.S_shipped
>  delete mode 100644 arch/arm64/crypto/sha512-core.S_shipped

What's the advantage of removing the _shipped files? We included them
originally so that we didn't require perl for the kernel build -- is that no
longer an issue?

I guess I'm just missing the justification for the change.

Cheers,

Will


From krzysztof.kozlowski at canonical.com  Mon Apr 26 10:01:00 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 11:01:00 +0200
Subject: [PATCH 06/10] memory: tegra: Parameterize interrupt handler
In-Reply-To: <20210420165237.3523732-7-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-7-thierry.reding@gmail.com>
Message-ID: <aa5d7581-0cda-596f-8929-ba0dbd8155d1@canonical.com>

On 20/04/2021 18:52, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Tegra20 requires a slightly different interrupt handler than Tegra30 and
> later, so parameterize the handler, so that each SoC implementation can
> provide its own.
> 
> While at it, also make IRQ support optional, which will help unify the
> Tegra186 memory controller driver with this one.

Please split making it optional to separate patch. Looking at the code
should be possible and not affect bisectability.

Best regards,
Krzysztof


From ardb at kernel.org  Mon Apr 26 10:01:43 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Mon, 26 Apr 2021 11:01:43 +0200
Subject: [PATCH 3/4] crypto: arm64: generate *.S by Perl at build time
 instead of shipping them
In-Reply-To: <20210426085836.GA5802@willie-the-truck>
References: <20210425175734.1310191-1-masahiroy@kernel.org>
 <20210425175734.1310191-3-masahiroy@kernel.org>
 <20210426085836.GA5802@willie-the-truck>
Message-ID: <CAMj1kXFe7wf_3jmoSAM98s+sZS4Ex4yyoXXiToR-EX8K0e-aNw@mail.gmail.com>

On Mon, 26 Apr 2021 at 10:58, Will Deacon <will at kernel.org> wrote:
>
> [+Ard]
>
> On Mon, Apr 26, 2021 at 02:57:33AM +0900, Masahiro Yamada wrote:
> > Generate *.S by Perl like arch/{mips,x86}/crypto/Makefile.
> >
> > Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
> > ---
> >
> >  arch/arm64/crypto/Makefile                |    9 +-
> >  arch/arm64/crypto/poly1305-core.S_shipped |  835 ---------
> >  arch/arm64/crypto/sha256-core.S_shipped   | 2069 ---------------------
> >  arch/arm64/crypto/sha512-core.S_shipped   | 1093 -----------
> >  4 files changed, 3 insertions(+), 4003 deletions(-)
> >  delete mode 100644 arch/arm64/crypto/poly1305-core.S_shipped
> >  delete mode 100644 arch/arm64/crypto/sha256-core.S_shipped
> >  delete mode 100644 arch/arm64/crypto/sha512-core.S_shipped
>
> What's the advantage of removing the _shipped files? We included them
> originally so that we didn't require perl for the kernel build -- is that no
> longer an issue?
>
> I guess I'm just missing the justification for the change.

Removing 4000 lines of code is an improvement in itself, I suppose,
but I have no preference either way,


From krzysztof.kozlowski at canonical.com  Mon Apr 26 10:06:51 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 11:06:51 +0200
Subject: [PATCH 00/10] memory: tegra: Driver unification
In-Reply-To: <20210420165237.3523732-1-thierry.reding@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
Message-ID: <519a1ee4-52a3-a465-9203-b14ae10d5e49@canonical.com>

On 20/04/2021 18:52, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Hi,
> 
> this set of patches converges the feature sets of the pre-Tegra186 and
> the post-Tegra186 memory controller drivers such that newer chips can
> take advantage of some features that were previously only implemented
> on earlier chips.
> 
> Note that this looks a bit daunting from a diffstat point of view but
> the bulk of this is in the first two patches that basically shuffle
> around where some of the per-memory-client register definitions are
> located, hence the big number of changed lines.
> 
> I haven't done any exhaustive testing on the series yet, but wanted to
> get some feedback on the general idea. I'll queue up this up for our
> automated testing in the coming days.
> 
> Thierry
> 
> Thierry Reding (10):
>   memory: tegra: Consolidate register fields
>   memory: tegra: Unify struct tegra_mc across SoC generations
>   memory: tegra: Push suspend/resume into SoC drivers
>   memory: tegra: Make per-SoC setup more generic
>   memory: tegra: Extract setup code into callback
>   memory: tegra: Parameterize interrupt handler
>   memory: tegra: Only initialize reset controller if available
>   memory: tegra: Unify drivers
>   memory: tegra: Add memory client IDs to tables
>   memory: tegra: Split Tegra194 data into separate file

I didn't get patch 10/10. Neither did lore.


Best regards,
Krzysztof


From cl at rock-chips.com  Mon Apr 26 10:21:33 2021
From: cl at rock-chips.com (=?UTF-8?B?6ZmI5Lqu?=)
Date: Mon, 26 Apr 2021 17:21:33 +0800
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <87mttmslni.wl-maz@kernel.org>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com> <87mttmslni.wl-maz@kernel.org>
Message-ID: <ee4172da-13a4-2a94-446f-cfdd937574c3@rock-chips.com>

Hi Marc,

? 2021/4/25 ??6:28, Marc Zyngier ??:
> As I reviewed a previous version of this series, please have the
> courtesy of cc'ing me on further revisions of this series.
I am really sorry, i will add you to the cc list on further revisions.
>
> On Sun, 25 Apr 2021 10:44:39 +0100,
> <cl at rock-chips.com> wrote:
>> From: Liang Chen <cl at rock-chips.com>
>>
>> RK3568 is a high-performance and low power quad-core application processor
>> designed for personal mobile internet device and AIoT equipments. This patch
>> add basic core dtsi file for it.
>>
>> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
>> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
>> enalbe a special high-performacne PLL when high frequency is required. The
>> smci_clk code is in ATF, and clkid for cpu is 0, as below:
>>
>>      cpu0: cpu at 0 {
>>          device_type = "cpu";
>>          compatible = "arm,cortex-a55";
>>          reg = <0x0 0x0>;
>>          clocks = <&scmi_clk 0>;
>>      };
>>
>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> ---
>>   .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
>>   arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
>>   2 files changed, 3931 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
> [...]
>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> new file mode 100644
>> index 000000000000..66cb50218ca1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> @@ -0,0 +1,812 @@
> [...]
>
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
>> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
>> +		arm,no-tick-in-suspend;
> My questions on this property still stand [1].

Yes, rk3568 will lose the system counter in suspend mode, we must 
retrieve system time from RTC.

rk3588 will fix this issue.

>
>> +	};
>> +
>> +	xin24m: xin24m {
>> +		compatible = "fixed-clock";
>> +		clock-frequency = <24000000>;
>> +		clock-output-names = "xin24m";
>> +		#clock-cells = <0>;
>> +	};
>> +
>> +	xin32k: xin32k {
>> +		compatible = "fixed-clock";
>> +		clock-frequency = <32768>;
>> +		clock-output-names = "xin32k";
>> +		pinctrl-0 = <&clk32k_out0>;
>> +		pinctrl-names = "default";
>> +		#clock-cells = <0>;
>> +	};
>> +
>> +	gic: interrupt-controller at fd400000 {
>> +		compatible = "arm,gic-v3";
>> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
>> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
>> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
> My request for a full description of the GICA region still stands [1].
Thanks, i will test MSIs with "mbi-alias", then add relative property in 
the next version.
>
> Thanks,
>
> 	M.
>
> [1] https://lore.kernel.org/r/87o8e2sm1u.wl-maz at kernel.org
>




From mark.rutland at arm.com  Mon Apr 26 10:21:39 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 26 Apr 2021 10:21:39 +0100
Subject: [PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel
 transitions
In-Reply-To: <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>
References: <20201130115950.22492-1-mark.rutland@arm.com>
 <20201130115950.22492-10-mark.rutland@arm.com>
 <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>
Message-ID: <20210426092139.GA16287@C02TD0UTHF1T.local>

On Sun, Apr 25, 2021 at 01:29:31PM +0800, Zenghui Yu wrote:
> Hi Mark,

Hi Zenghui,

> On 2020/11/30 19:59, Mark Rutland wrote:
> > There are periods in kernel mode when RCU is not watching and/or the
> > scheduler tick is disabled, but we can still take exceptions such as
> > interrupts. The arm64 exception handlers do not account for this, and
> > it's possible that RCU is not watching while an exception handler runs.
> > 
> > The x86/generic entry code handles this by ensuring that all (non-NMI)
> > kernel exception handlers call irqentry_enter() and irqentry_exit(),
> > which handle RCU, lockdep, and IRQ flag tracing. We can't yet move to
> > the generic entry code, and already hadnle the user<->kernel transitions
> > elsewhere, so we add new kernel<->kernel transition helpers alog the
> > lines of the generic entry code.
> > 
> > Since we now track interrupts becoming masked when an exception is
> > taken, local_daif_inherit() is modified to track interrupts becoming
> > re-enabled when the original context is inherited. To balance the
> > entry/exit paths, each handler masks all DAIF exceptions before
> > exit_to_kernel_mode().
> > 
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: James Morse <james.morse at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> 
> [...]
> 
> > +/*
> > + * This is intended to match the logic in irqentry_enter(), handling the kernel
> > + * mode transitions only.
> > + */
> > +static void noinstr enter_from_kernel_mode(struct pt_regs *regs)
> > +{
> > +	regs->exit_rcu = false;
> > +
> > +	if (!IS_ENABLED(CONFIG_TINY_RCU) && is_idle_task(current)) {
> > +		lockdep_hardirqs_off(CALLER_ADDR0);
> > +		rcu_irq_enter();
> > +		trace_hardirqs_off_finish();
> > +
> > +		regs->exit_rcu = true;
> > +		return;
> > +	}
> > +
> > +	lockdep_hardirqs_off(CALLER_ADDR0);
> > +	rcu_irq_enter_check_tick();
> > +	trace_hardirqs_off_finish();
> > +}
> 
> Booting a lockdep-enabled kernel with "irqchip.gicv3_pseudo_nmi=1" would
> result in splats as below:
> 
> | DEBUG_LOCKS_WARN_ON(!irqs_disabled())
> | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258
> lockdep_hardirqs_off+0xd4/0xe8
> | Modules linked in:
> | CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+
> #463
> | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
> | pc : lockdep_hardirqs_off+0xd4/0xe8
> | lr : lockdep_hardirqs_off+0xd4/0xe8
> | sp : ffff80002a39bad0
> | pmr_save: 000000e0
> | x29: ffff80002a39bad0 x28: ffff0000de214bc0
> | x27: ffff0000de1c0400 x26: 000000000049b328
> | x25: 0000000000406f30 x24: ffff0000de1c00a0
> | x23: 0000000020400005 x22: ffff8000105f747c
> | x21: 0000000096000044 x20: 0000000000498ef9
> | x19: ffff80002a39bc88 x18: ffffffffffffffff
> | x17: 0000000000000000 x16: ffff800011c61eb0
> | x15: ffff800011700a88 x14: 0720072007200720
> | x13: 0720072007200720 x12: 0720072007200720
> | x11: 0720072007200720 x10: 0720072007200720
> | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
> | x7 : ffff8000119f0800 x6 : c0000000ffff7fff
> | x5 : ffff8000119f07a8 x4 : 0000000000000001
> | x3 : 9bcdab23f2432800 x2 : ffff800011730538
> | x1 : 9bcdab23f2432800 x0 : 0000000000000000
> | Call trace:
> |  lockdep_hardirqs_off+0xd4/0xe8
> |  enter_from_kernel_mode.isra.5+0x7c/0xa8
> |  el1_abort+0x24/0x100
> |  el1_sync_handler+0x80/0xd0
> |  el1_sync+0x6c/0x100
> |  __arch_clear_user+0xc/0x90
> |  load_elf_binary+0x9fc/0x1450
> |  bprm_execve+0x404/0x880
> |  kernel_execve+0x180/0x188
> |  call_usermodehelper_exec_async+0xdc/0x158
> |  ret_from_fork+0x10/0x18
> 
> The code that triggers the splat is lockdep_hardirqs_off+0xd4/0xe8:
> 
> |	/*
> |	 * So we're supposed to get called after you mask local IRQs, but for
> |	 * some reason the hardware doesn't quite think you did a proper job.
> |	 */
> |	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> |		return;
> 
> which looks like a false positive as DAIF are all masked on taking
> an synchronous exception and hardirqs are therefore disabled. With
> pseudo NMI used, irqs_disabled() takes the value of ICC_PMR_EL1 as
> the interrupt enable state, which is GIC_PRIO_IRQON (0xe0) in this
> case and doesn't help much. Not dig further though.

Thanks for this report. I think I understand the problem.

In some paths (e.g. el1_dbg, el0_svc) we update the PMR with
(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) before we notify lockdep, but in
others (e.g. el1_abort) we do not. The case where we do not are where
lockdep will warn, since IRQs will be masked by DAIF but not the PMR, as
you describe above.

With the current PMR management scheme, we'll need to consistently
update the PMR earlier in the entry code. Does the below diff help?

Thanks,
Mark.

---->8----
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9d3588450473..117412bae915 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -226,14 +226,6 @@ static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr)
 {
 	unsigned long far = read_sysreg(far_el1);
 
-	/*
-	 * The CPU masked interrupts, and we are leaving them masked during
-	 * do_debug_exception(). Update PMR as if we had called
-	 * local_daif_mask().
-	 */
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	arm64_enter_el1_dbg(regs);
 	if (!cortex_a76_erratum_1463225_debug_handler(regs))
 		do_debug_exception(far, esr, regs);
@@ -398,9 +390,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
 	/* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */
 	unsigned long far = read_sysreg(far_el1);
 
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	do_debug_exception(far, esr, regs);
 	local_daif_restore(DAIF_PROCCTX_NOIRQ);
@@ -408,9 +397,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
 
 static void noinstr el0_svc(struct pt_regs *regs)
 {
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	cortex_a76_erratum_1463225_svc_handler();
 	do_el0_svc(regs);
@@ -486,9 +472,6 @@ static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
 
 static void noinstr el0_svc_compat(struct pt_regs *regs)
 {
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	cortex_a76_erratum_1463225_svc_handler();
 	do_el0_svc_compat(regs);
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 6acfc5e6b5e0..7d46c74a8706 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -292,6 +292,8 @@ alternative_else_nop_endif
 alternative_if ARM64_HAS_IRQ_PRIO_MASKING
 	mrs_s	x20, SYS_ICC_PMR_EL1
 	str	x20, [sp, #S_PMR_SAVE]
+	orr	x20, x20, #GIC_PRIO_PSR_I_SET
+	msr_s	SYS_ICC_PMR_EL1, x20
 alternative_else_nop_endif
 
 	/* Re-enable tag checking (TCO set on exception entry) */


From frieder.schrempf at kontron.de  Mon Apr 26 10:24:17 2021
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Mon, 26 Apr 2021 11:24:17 +0200
Subject: [PATCH v2 08/13] dt-bindings: imx: gpcv2: add support for
 optional resets
In-Reply-To: <928adc851c756f27562b0ae1847f08e2c857504d.camel@pengutronix.de>
References: <20201105174434.1817539-1-l.stach@pengutronix.de>
 <20201105174434.1817539-9-l.stach@pengutronix.de>
 <20201109201557.GA1690230@bogus>
 <5b6c97dc74ccb38107a50972427d091cdb114209.camel@pengutronix.de>
 <f652344c2c1664d541300dc71cc9ccd8aeaee292.camel@pengutronix.de>
 <928adc851c756f27562b0ae1847f08e2c857504d.camel@pengutronix.de>
Message-ID: <f9400040-0884-81a4-ae76-5cd1db8c195d@kontron.de>

Hi Rob,

On 10.02.21 15:35, Lucas Stach wrote:
> Am Montag, dem 30.11.2020 um 10:57 +0100 schrieb Lucas Stach:
>> Hi Rob,
>>
>> Am Dienstag, den 17.11.2020, 15:11 +0100 schrieb Lucas Stach:
>> Am Montag, den 09.11.2020, 14:15 -0600 schrieb Rob Herring:
>>> On Thu, Nov 05, 2020 at 06:44:29PM +0100, Lucas Stach wrote:
>>>> For some domains the resets of the devices in the domain are not
>>>> automatically triggered. Add an optional resets property to allow
>>>> the GPC driver to trigger those resets explicitly.
>>>>
>>>> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
>>>> ---
>>>>  ?Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 7
>>>> +++++++
>>>>  ?1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-
>>>> gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-
>>>> gpcv2.yaml
>>>> index a96e6dbf1858..4330c73a2c30 100644
>>>> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>> @@ -66,6 +66,13 @@ properties:
>>>>   
>>>>  ?????????? power-supply: true
>>>>   
>>>> +????????? resets:
>>>> +??????????? description: |
>>>> +????????????? A number of phandles to resets that need to be
>>>> asserted during
>>>> +????????????? power-up sequencing of the domain.
>>>> +??????????? minItems: 1
>>>> +??????????? maxItems: 4
>>>
>>> You need to define what each reset is.
>>
>> I can't. The resets belong to devices located inside the power domain,
>> which need to be held in reset across the power-up sequence. So I
>> have no means to specify what each reset is in a generic power-domain
>> binding. Same situation as with the clocks in this binding actually.
>>
>> Do you have any guidance on what do here? Is this binding okay with
>> this explanation, or do we need to do something different here?
> 
> Any pointers on how we can make some progress with this? It's blocking
> quite a bit of functionality of the i.MX8MM SoC being enabled upstream.

One more ping from my side. Can you give us some feedback about whether 
we can proceed with the bindings proposed by Lucas or not?

This has been on hold now for over 5 months and it looks like one of the 
reasons is that we don't know if the bindings will be accepted.

Thanks
Frieder


From narmstrong at baylibre.com  Mon Apr 26 10:58:59 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 11:58:59 +0200
Subject: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
In-Reply-To: <20210421052855.1279713-1-drinkcat@chromium.org>
References: <20210421052855.1279713-1-drinkcat@chromium.org>
Message-ID: <c91746ce-88b6-5612-74a5-74600c7761e8@baylibre.com>

Hi,

On 21/04/2021 07:28, Nicolas Boichat wrote:
> Hi!
> 
> This is just a rebase of the v11, untested (but it seems like
> Neil Armstrong recently tested it), with small changes in
> binding and dts. v11 cover follows:
> 
> Follow-up on the v5 [1], things have gotten significantly
> better in the last year, thanks to the efforts on Bifrost
> support by the Collabora team (and probably others I'm not
> aware of).
> 
> I've been testing this series on a MT8183/kukui device, with a
> chromeos-5.10 kernel [2], and got basic Chromium OS UI up with
> mesa 20.3.2 (lots of artifacts though).
> 
> devfreq is currently not supported, as we'll need:
>  - Clock core support for switching the GPU core clock (see 2/4).
>  - Platform-specific handling of the 2-regulator (see 3/4).
> 
> Since the latter is easy to detect, patch 3/4 just disables
> devfreq if the more than one regulator is specified in the
> compatible matching table.
> 
> [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drinkcat at chromium.org/
> [2] https://crrev.com/c/2608070
> 
> Changes in v13:
>  - devfreq: Fix conflict resolution mistake when rebasing, didn't
>    even compile. Oops.
> 
> Changes in v12:
>  - binding: Fix min/maxItems logic (Rob Herring)
>  - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong).
> 
> Changes in v11:
>  - binding: power-domain-names not power-domainS-names
>  - mt8183*.dts: remove incorrect supply-names
> 
> Changes in v10:
>  - Fix the binding to make sure sram-supply property can be provided.
> 
> Changes in v9:
>  - Explain why devfreq needs to be disabled for GPUs with >1
>    regulators.
> 
> Changes in v8:
>  - Use DRM_DEV_INFO instead of ERROR
> 
> Changes in v7:
>  - Fix GPU ID in commit message
>  - Fix GPU ID in commit message
> 
> Changes in v6:
>  - Rebased, actually tested with recent mesa driver.
>  - Add gpu regulators to kukui dtsi as well.
>  - Power domains are now attached to spm, not scpsys
>  - Drop R-B.
>  - devfreq: New change
>  - Context conflicts, reflow the code.
>  - Use ARRAY_SIZE for power domains too.
> 
> Changes in v5:
>  - Rename "2d" power domain to "core2"
>  - Rename "2d" power domain to "core2" (keep R-B again).
>  - Change power domain name from 2d to core2.
> 
> Changes in v4:
>  - Add power-domain-names description
>    (kept Alyssa's reviewed-by as the change is minor)
>  - Add power-domain-names to describe the 3 domains.
>    (kept Alyssa's reviewed-by as the change is minor)
>  - Add power domain names.
> 
> Changes in v3:
>  - Match mt8183-mali instead of bifrost, as we require special
>    handling for the 2 regulators and 3 power domains.
> 
> Changes in v2:
>  - Use sram instead of mali_sram as SRAM supply name.
>  - Rename mali@ to gpu at .
> 
> Nicolas Boichat (4):
>   dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
>   arm64: dts: mt8183: Add node for the Mali GPU
>   drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
>   drm/panfrost: Add mt8183-mali compatible string
> 
>  .../bindings/gpu/arm,mali-bifrost.yaml        |  30 ++++-
>  arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   5 +
>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi |   5 +
>  .../boot/dts/mediatek/mt8183-pumpkin.dts      |   5 +
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi      | 105 ++++++++++++++++++
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c   |   9 ++
>  drivers/gpu/drm/panfrost/panfrost_drv.c       |  10 ++
>  7 files changed, 168 insertions(+), 1 deletion(-)
> 

Seems this version is ready to be applied if we get a review on the DT ?

Mathias ? could you have a look ?

Neil


From wens at kernel.org  Mon Apr 26 10:59:16 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Mon, 26 Apr 2021 17:59:16 +0800
Subject: [PATCH] arm64: dts: rockchip: rk3328: rock-pi-e: Drop fephy pinctrl
 from gmac2phy
Message-ID: <20210426095916.14574-1-wens@kernel.org>

From: Chen-Yu Tsai <wens at csie.org>

Turns out the fephy pins are already claimed in the phy node, which is
rightfully where they should be claimed.

Drop the pinctrl properties from the gmac2phy node for the ROCK Pi E.

Fixes: b918e81f2145 ("arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E")
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts | 2 --
 1 file changed, 2 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 07538951a3a6..018a3a5075c7 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -177,8 +177,6 @@ rtl8211e: ethernet-phy at 1 {
 };
 
 &gmac2phy {
-	pinctrl-names = "default";
-	pinctrl-0 = <&fephyled_linkm1>, <&fephyled_rxm1>;
 	status = "okay";
 };
 
-- 
2.31.1



From Souvik.Chakravarty at arm.com  Mon Apr 26 11:10:45 2021
From: Souvik.Chakravarty at arm.com (Souvik Chakravarty)
Date: Mon, 26 Apr 2021 10:10:45 +0000
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com>
 <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com>
Message-ID: <AM6PR08MB3656190AAF022E0457BEBF9282429@AM6PR08MB3656.eurprd08.prod.outlook.com>

Hi Sowjanya,

> From: Sowjanya Komatineni
> Sent: Friday, April 23, 2021 11:25 PM
> 
> On 4/23/21 1:16 PM, Lukasz Luba wrote:
> > Hi Sowjanya,
> >
> > On 4/22/21 9:30 PM, Sowjanya Komatineni wrote:
> >> Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs
> >> which is in charge of deciding on state transition based on target
> >> state, state idle time, and some other Tegra CPU core cluster states
> >> information.
> >>
> >> Current PSCI specification don't have function defined for passing
> >> runtime state idle time predicted by governor (based on next events
> >> and state target
> >> residency) to ARM trusted firmware.
> >
> > Do you have some numbers from experiments showing that these idle
> > governor prediction values, which are passed from kernel to MCE
> > firmware, are making a good 'guess'?
> > How much precision (1us? 1ms?) in the values do you need there?
> 
> it could also be in few ms depending on when next cpu event/activity might
> happen which is not transparent to MCE firmware.
> 
> >
> > IIRC (probably Rafael's presentations) predicting in the kernel
> > something like CPU idle time residency is not a trivial thing.
> >
> > Another idea (depending on DT structure and PSCI bits):
> > Could this be solved differently, but just having a knowledge that if
> > the governor requested some C-state, this means governor 'predicted'
> > an idle residency to be greater that min_residency attached to this
> > C-state?
> > Then, when that request shows up in your FW, you know that it must be
> > at least min_residency because of this C-state id.
> C6 is the only deepest state for Tegra194 Carmel CPU that we support in
> addition to C1 (WFI) idle state.
> 
> MCE firmware gets state crossover thresholds for C1 to C6 transition from TF-
> A and uses it along with state idle time to decide on C6 state entry based on
> its background work.
> 
> Assuming for now if we use min_residency as state idle time which is static
> value from DT, then it enters into deepest state C6 always as we use
> min_residency value we use is always higher than state crossover threshold.
> 
> But MCE firmware is not aware of when next cpu event can happen to
> predict if next event can take longer than state min_residency time.
> 
> Using min residency in such case is very conservative where MCE firmware
> exits C6 state early where we may not have better power saving.
> 
> But with MCE firmware being aware of when next event can happen it can
> use that to stay in C6 state without early exit for better power savings.

This part confuses me. Are you saying that the firmware will forcefully wake up
the core, even if no wakeups are pending, when min residency for C6 expires?

Regards,
Souvik

> 
> > It would depend on number of available states, max_residency, scale
> > that you would choose while assigning values from [0, max_residency]
> > to each state.
> > IIRC there can be many state IDs for idle, so it would depend on
> > number of bits encoding this state, and your needs. Example of linear
> > scale:
> > 4-bits encoding idle state and max predicted residency 10msec, that
> > means 10000us / 16 states = 625us/state.
> > The max_residency might be split differently, using different than
> > linear function, to have some rage more precised.
> >
> > Open question is if these idle states must be all represented in DT,
> > or there is a way of describing a 'set of idle states'
> > automatically.
> We only support C6 state through DT as C6 is the only deepest state for
> Tegra194 carmel CPU. WFI idle state is completely handled by kernel and
> does not require MCE sequences for entry/exit.
> >
> > Regards,
> > Lukasz

From colin.king at canonical.com  Mon Apr 26 11:11:06 2021
From: colin.king at canonical.com (Colin King)
Date: Mon, 26 Apr 2021 11:11:06 +0100
Subject: [PATCH] serial: meson: remove redundant initialization of variable id
Message-ID: <20210426101106.9122-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The variable id being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed. Since id is just being used in a for-loop
inside a local scope, move the declaration of id to that scope.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/tty/serial/meson_uart.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index 529cd0289056..d7f55031b2cf 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -716,12 +716,13 @@ static int meson_uart_probe(struct platform_device *pdev)
 	struct resource *res_mem, *res_irq;
 	struct uart_port *port;
 	int ret = 0;
-	int id = -1;
 
 	if (pdev->dev.of_node)
 		pdev->id = of_alias_get_id(pdev->dev.of_node, "serial");
 
 	if (pdev->id < 0) {
+		int id;
+
 		for (id = AML_UART_PORT_OFFSET; id < AML_UART_PORT_NUM; id++) {
 			if (!meson_ports[id]) {
 				pdev->id = id;
-- 
2.30.2



From rmfrfs at gmail.com  Mon Apr 26 11:11:13 2021
From: rmfrfs at gmail.com (Rui Miguel Silva)
Date: Mon, 26 Apr 2021 11:11:13 +0100
Subject: [PATCH 14/78] staging: media: imx7-mipi-csis: use
 pm_runtime_resume_and_get()
In-Reply-To: <d5f5cb75e48ef7386f83ed023ec3dc1f5be5d08f.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <d5f5cb75e48ef7386f83ed023ec3dc1f5be5d08f.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <CAXKOS5IEQ7O.393TTUPR42AWE@arch-thunder>

Hi Mauro,
On Sat Apr 24, 2021 at 7:44 AM WEST, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Thanks, looks good.

Acked-by: Rui Miguel Silva <rmfrfs at gmail.com>

------
Cheers,
	 Rui
> ---
>  drivers/staging/media/imx/imx7-mipi-csis.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
> index 025fdc488bd6..1dc680d94a46 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -695,11 +695,10 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
>  
>  		mipi_csis_clear_counters(state);
>  
> -		ret = pm_runtime_get_sync(&state->pdev->dev);
> -		if (ret < 0) {
> -			pm_runtime_put_noidle(&state->pdev->dev);
> +		ret = pm_runtime_resume_and_get(&state->pdev->dev);
> +		if (ret < 0)
>  			return ret;
> -		}
> +
>  		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
>  		if (ret < 0 && ret != -ENOIOCTLCMD)
>  			goto done;
> -- 
> 2.30.2




From marex at denx.de  Mon Apr 26 11:23:21 2021
From: marex at denx.de (Marek Vasut)
Date: Mon, 26 Apr 2021 12:23:21 +0200
Subject: [PATCH V3] ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulators
Message-ID: <20210426102321.5039-1-marex@denx.de>

Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1
via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied
from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs.

While no instability or problems are currently observed, the regulators
should be fully described in DT and that description should fully match
the hardware, else this might lead to unforseen issues later. Fix this.

Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
Reviewed-by: Fabio Estevam <festevam at gmail.com>
Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Christoph Niedermaier <cniedermaier at dh-electronics.com>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: Ludwig Zenz <lzenz at dh-electronics.com>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: stable at vger.kernel.org
---
V2: Amend commit message
V3: Reinstate the missing SoB line, add RB
---
 arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
index 236fc205c389..d0768ae429fa 100644
--- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
@@ -406,6 +406,18 @@ &reg_soc {
 	vin-supply = <&sw1_reg>;
 };
 
+&reg_pu {
+	vin-supply = <&sw1_reg>;
+};
+
+&reg_vdd1p1 {
+	vin-supply = <&sw2_reg>;
+};
+
+&reg_vdd2p5 {
+	vin-supply = <&sw2_reg>;
+};
+
 &uart1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1>;
-- 
2.30.2



From maz at kernel.org  Mon Apr 26 11:36:05 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 26 Apr 2021 11:36:05 +0100
Subject: [PATCH] KVM: arm64: Skip CMOs when updating a PTE pointing to
 non-memory
Message-ID: <20210426103605.616908-1-maz@kernel.org>

Sumit Gupta and Krishna Reddy both reported that for MMIO regions
mapped into userspace using VFIO, a PTE update can trigger a MMU
notifier reaching kvm_set_spte_hva().

There is an assumption baked in kvm_set_spte_hva() that it only
deals with memory pages, and not MMIO. For this purpose, it
performs a cache cleaning of the potentially newly mapped page.
However, for a MMIO range, this explodes as there is no linear
mapping for this range (and doing cache maintenance on it would
make little sense anyway).

Check for the validity of the page before performing the CMO
addresses the problem.

Reported-by: Krishna Reddy <vdumpa at nvidia.com>
Reported-by: Sumit Gupta <sumitg at nvidia.com>,
Tested-by: Sumit Gupta <sumitg at nvidia.com>,
Signed-off-by: Marc Zyngier <maz at kernel.org>
Link: https://lore.kernel.org/r/5a8825bc-286e-b316-515f-3bd3c9c70a80 at nvidia.com
---
 arch/arm64/kvm/mmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index cd4d51ae3d4a..564a0f7fcd05 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1236,7 +1236,8 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
 	 * We've moved a page around, probably through CoW, so let's treat it
 	 * just like a translation fault and clean the cache to the PoC.
 	 */
-	clean_dcache_guest_page(pfn, PAGE_SIZE);
+	if (!kvm_is_device_pfn(pfn))
+		clean_dcache_guest_page(pfn, PAGE_SIZE);
 	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
 	return 0;
 }
-- 
2.30.2



From cnsztl at gmail.com  Mon Apr 26 11:39:03 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon, 26 Apr 2021 18:39:03 +0800
Subject: [PATCH v6 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
In-Reply-To: <20210425213321.GF10996@amd>
References: <20210319051627.814-1-cnsztl@gmail.com>
 <161640742725.808893.3666594351389773587.b4-ty@sntech.de>
 <20210425213321.GF10996@amd>
Message-ID: <CAOP2_ThcRMkgSm872q2By=gALoK-qAjq92FtNQkDO999pZR8kg@mail.gmail.com>

Hi Pavel,

On Mon, Apr 26, 2021 at 5:33 AM Pavel Machek <pavel at ucw.cz> wrote:
>
> Hi!
>
> > > Changes in v6:
> > > - Fixed format of LED nodes
> > >
> > > Changes in v5:
> > > - Dropped the empty PCIe node
> > > - Dropped useless `/delete-property/`
> > > - Renamed LED nodes
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
> >       commit: 1003888415e83e15ddb63d1d96189b4f2c5f1d48
> > [2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
> >       commit: db792e9adbf85ffc9d6b0b060ac3c8e3148c8992
>
> Sorry for late review, but:
>
>
> +                       label = "red:sys";
>
> This should be red:power based on the discussion in earlier threads.

However based on the introduction from FriendlyELEC[1], this is not
the "power" lamp...
"LEDs: 1 x power LED and 3 x GPIO Controlled LED (SYS, LAN, WAN)"

1. https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S#Hardware_Spec

Thanks,
Tianling.

>
> Thanks,
>                                                                         Pavel
> --
> http://www.livejournal.com/~pavelmachek


From patrice.chotard at foss.st.com  Mon Apr 26 11:39:56 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 12:39:56 +0200
Subject: [1/1] ARM: dts: stm32: Configure qspi's mdma transfer to block for
 stm32mp151
Message-ID: <20210426103956.29007-1-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

Configure qspi's mdma from buffer transfer (max 128 bytes) to
block transfer (max 64K bytes).

mtd_speedtest shows that write throughtput increases :
  - from 734 to 782 KiB/s (~6.5%) with s25fl512s SPI-NOR.
  - from 4848 to 5319 KiB/s (~9.72%) with Micron SPI-NAND.

Signed-off-by: Christophe Kerello <christophe.kerello at st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 arch/arm/boot/dts/stm32mp151.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 4b8031782555..cb326c1e12bc 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1358,8 +1358,8 @@
 			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
 			reg-names = "qspi", "qspi_mm";
 			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma1 22 0x2 0x100002 0x0 0x0>,
-			       <&mdma1 22 0x2 0x100008 0x0 0x0>;
+			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>;
-- 
2.17.1



From suzuki.poulose at arm.com  Mon Apr 26 11:40:44 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Mon, 26 Apr 2021 11:40:44 +0100
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync
 buffer.
In-Reply-To: <20210421120413.3110775-2-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-2-daniel.kiss@arm.com>
Message-ID: <bd9de3ab-14f7-2659-0dc8-619bca0f52d7@arm.com>

On 21/04/2021 13:04, Daniel Kiss wrote:
> With polling the sync could called multiple times in a row. Without this
> change the data will be overwritten at the beginning of the buffer.
> 
> Signed-off-by: Daniel Kiss <daniel.kiss at arm.com>
> Signed-off-by: Branislav Rankov <Branislav.Rankov at arm.com>
> ---
>   drivers/hwtracing/coresight/coresight-tmc-etr.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index ea5027e397d02..dd19d1d1c3b38 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -1442,7 +1442,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>   {
>   	long bytes;
>   	long pg_idx, pg_offset;
> -	unsigned long head = etr_perf->head;
> +	unsigned long head;
>   	char **dst_pages, *src_buf;
>   	struct etr_buf *etr_buf = etr_perf->etr_buf;
>   
> @@ -1465,7 +1465,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>   		bytes = tmc_etr_buf_get_data(etr_buf, src_offset, to_copy,
>   					     &src_buf);
>   		if (WARN_ON_ONCE(bytes <= 0))
> -			break;
> +			return;
>   		bytes = min(bytes, (long)(PAGE_SIZE - pg_offset));
>   
>   		memcpy(dst_pages[pg_idx] + pg_offset, src_buf, bytes);
> @@ -1483,6 +1483,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>   		/* Move source pointers */
>   		src_offset += bytes;
>   	}
> +	etr_perf->head = (pg_idx << PAGE_SHIFT) + pg_offset;


Looking at this patch, I feel the driver is doing a couple wrong things
already.

1) We initialise etr_perf->head every time the ETR enable is called, 
irrespective of whether we actually try to enable the Hardware. e.g,

etm_0 on -> .. -> enable_etr :
etr_perf->head = <head of the handle_0>
   enable_hw()

emt_1 on -> ... -> enable_etr:
   etr_perf->head = <head of the handle_1>
   already_enabled, skip enable_hw()

etm_2 on -> ... -> enable_etr:
   etr_perf->head = <head of the handle_2>
   already_enable, skip enable_hw()...


This doesn't look correct as we don't know which handle is going to get 
the data. This looks pointless.

2) Even more problematic is where we copy the AUX buffer content to.
As mentioned above, we don't know which handle is going to be the last
one to consume and we have a "etr_perf->head" that came from one of the 
handles and the "pages" that came from the first handle which created a
etr_perf buffer. In sync_perf_buffer() we copy the hardware buffers to
the "pages" (say of handle_0) with "etr_perf->head" (which could be from
any other handle, say handle_2) and then we could return the number of 
bytes copied, which then is used to update the last handle (could be say 
handle_3), where there is no actual data copied.

To fix all of these issues, we must
1) Stop using etr_perf->head, and instead use the handle->head where we 
are called update_buffer on.

2) Keep track of the "pages" that belong to a given "handle" and then 
use those pages to copy the data to the current handle we are called to 
update the buffer on.

Did I get this wrong ?

Suzuki


From maz at kernel.org  Mon Apr 26 11:41:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 26 Apr 2021 11:41:09 +0100
Subject: [PATCH] KVM: arm64: Skip CMOs when updating a PTE pointing to
 non-memory
In-Reply-To: <20210426103605.616908-1-maz@kernel.org>
References: <20210426103605.616908-1-maz@kernel.org>
Message-ID: <fa71b02d1a7c8be97968be1461749649@kernel.org>

On 2021-04-26 11:36, Marc Zyngier wrote:
> Sumit Gupta and Krishna Reddy both reported that for MMIO regions
> mapped into userspace using VFIO, a PTE update can trigger a MMU
> notifier reaching kvm_set_spte_hva().
> 
> There is an assumption baked in kvm_set_spte_hva() that it only
> deals with memory pages, and not MMIO. For this purpose, it
> performs a cache cleaning of the potentially newly mapped page.
> However, for a MMIO range, this explodes as there is no linear
> mapping for this range (and doing cache maintenance on it would
> make little sense anyway).
> 
> Check for the validity of the page before performing the CMO
> addresses the problem.
> 
> Reported-by: Krishna Reddy <vdumpa at nvidia.com>
> Reported-by: Sumit Gupta <sumitg at nvidia.com>,
> Tested-by: Sumit Gupta <sumitg at nvidia.com>,
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> Link: 
> https://lore.kernel.org/r/5a8825bc-286e-b316-515f-3bd3c9c70a80 at nvidia.com

FWIW, I've locally added:

Fixes: 694556d54f35 ("KVM: arm/arm64: Clean dcache to PoC when changing 
PTE due to CoW")
Cc: stable at vger.kernel.org

         M.
-- 
Jazz is not dead. It just smells funny...


From masahiroy at kernel.org  Mon Apr 26 11:40:24 2021
From: masahiroy at kernel.org (Masahiro Yamada)
Date: Mon, 26 Apr 2021 19:40:24 +0900
Subject: [PATCH 3/4] crypto: arm64: generate *.S by Perl at build time
 instead of shipping them
In-Reply-To: <CAMj1kXFe7wf_3jmoSAM98s+sZS4Ex4yyoXXiToR-EX8K0e-aNw@mail.gmail.com>
References: <20210425175734.1310191-1-masahiroy@kernel.org>
 <20210425175734.1310191-3-masahiroy@kernel.org>
 <20210426085836.GA5802@willie-the-truck>
 <CAMj1kXFe7wf_3jmoSAM98s+sZS4Ex4yyoXXiToR-EX8K0e-aNw@mail.gmail.com>
Message-ID: <CAK7LNAR+3DKGOdg=Jo1yt0QvjjjCzthKzpx5RCMK3x+MO0oMew@mail.gmail.com>

On Mon, Apr 26, 2021 at 6:01 PM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Mon, 26 Apr 2021 at 10:58, Will Deacon <will at kernel.org> wrote:
> >
> > [+Ard]
> >
> > On Mon, Apr 26, 2021 at 02:57:33AM +0900, Masahiro Yamada wrote:
> > > Generate *.S by Perl like arch/{mips,x86}/crypto/Makefile.
> > >
> > > Signed-off-by: Masahiro Yamada <masahiroy at kernel.org>
> > > ---
> > >
> > >  arch/arm64/crypto/Makefile                |    9 +-
> > >  arch/arm64/crypto/poly1305-core.S_shipped |  835 ---------
> > >  arch/arm64/crypto/sha256-core.S_shipped   | 2069 ---------------------
> > >  arch/arm64/crypto/sha512-core.S_shipped   | 1093 -----------
> > >  4 files changed, 3 insertions(+), 4003 deletions(-)
> > >  delete mode 100644 arch/arm64/crypto/poly1305-core.S_shipped
> > >  delete mode 100644 arch/arm64/crypto/sha256-core.S_shipped
> > >  delete mode 100644 arch/arm64/crypto/sha512-core.S_shipped
> >
> > What's the advantage of removing the _shipped files? We included them
> > originally so that we didn't require perl for the kernel build -- is that no
> > longer an issue?
> >
> > I guess I'm just missing the justification for the change.
>
> Removing 4000 lines of code is an improvement in itself, I suppose,
> but I have no preference either way,



If necessary, I can send v2 with the following info added.


------------------------------>8---------------------------------
People building the arm64 kernel are likely to have Perl already
installed on the system.

ARCH=arm64 defconfig sets CONFIG_OID_REGISTRY=y, so Perl is required
to generate lib/oid_registery_data.c anyway.

Also, Documentation/process/changes.rst says:

You will need perl 5 and the following modules: ``Getopt::Long``,
``Getopt::Std``, ``File::Basename``, and ``File::Find`` to build the kernel.
------------------------------>8---------------------------------





--
Best Regards
Masahiro Yamada


From patrice.chotard at foss.st.com  Mon Apr 26 11:44:22 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Mon, 26 Apr 2021 12:44:22 +0200
Subject: [1/1] ARM: dts: stm32: Configure qspi's mdma transfer to block
 for stm32mp151
In-Reply-To: <20210426103956.29007-1-patrice.chotard@foss.st.com>
References: <20210426103956.29007-1-patrice.chotard@foss.st.com>
Message-ID: <c6a63d27-e0d9-ec7e-0f40-907084dde28f@foss.st.com>

Don't take care of this patch, i will resend it with the correct header.

Patrice

On 4/26/21 12:39 PM, patrice.chotard at foss.st.com wrote:
> From: Patrice Chotard <patrice.chotard at foss.st.com>
> 
> Configure qspi's mdma from buffer transfer (max 128 bytes) to
> block transfer (max 64K bytes).
> 
> mtd_speedtest shows that write throughtput increases :
>   - from 734 to 782 KiB/s (~6.5%) with s25fl512s SPI-NOR.
>   - from 4848 to 5319 KiB/s (~9.72%) with Micron SPI-NAND.
> 
> Signed-off-by: Christophe Kerello <christophe.kerello at st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
> ---
>  arch/arm/boot/dts/stm32mp151.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
> index 4b8031782555..cb326c1e12bc 100644
> --- a/arch/arm/boot/dts/stm32mp151.dtsi
> +++ b/arch/arm/boot/dts/stm32mp151.dtsi
> @@ -1358,8 +1358,8 @@
>  			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
>  			reg-names = "qspi", "qspi_mm";
>  			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
> -			dmas = <&mdma1 22 0x2 0x100002 0x0 0x0>,
> -			       <&mdma1 22 0x2 0x100008 0x0 0x0>;
> +			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>;
> 


From patrice.chotard at foss.st.com  Mon Apr 26 11:45:36 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 12:45:36 +0200
Subject: [PATCH 1/1] ARM: dts: stm32: Configure qspi's mdma transfer to block
 for stm32mp151
Message-ID: <20210426104536.29576-1-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

Configure qspi's mdma from buffer transfer (max 128 bytes) to
block transfer (max 64K bytes).

mtd_speedtest shows that write throughtput increases :
  - from 734 to 782 KiB/s (~6.5%) with s25fl512s SPI-NOR.
  - from 4848 to 5319 KiB/s (~9.72%) with Micron SPI-NAND.

Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 arch/arm/boot/dts/stm32mp151.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 4b8031782555..cb326c1e12bc 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1358,8 +1358,8 @@
 			reg = <0x58003000 0x1000>, <0x70000000 0x10000000>;
 			reg-names = "qspi", "qspi_mm";
 			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-			dmas = <&mdma1 22 0x2 0x100002 0x0 0x0>,
-			       <&mdma1 22 0x2 0x100008 0x0 0x0>;
+			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>;
-- 
2.17.1



From pavel at ucw.cz  Mon Apr 26 12:03:16 2021
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 26 Apr 2021 13:03:16 +0200
Subject: [PATCH v6 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
In-Reply-To: <CAOP2_ThcRMkgSm872q2By=gALoK-qAjq92FtNQkDO999pZR8kg@mail.gmail.com>
References: <20210319051627.814-1-cnsztl@gmail.com>
 <161640742725.808893.3666594351389773587.b4-ty@sntech.de>
 <20210425213321.GF10996@amd>
 <CAOP2_ThcRMkgSm872q2By=gALoK-qAjq92FtNQkDO999pZR8kg@mail.gmail.com>
Message-ID: <20210426110316.GA13974@duo.ucw.cz>

Hi!
> > > > - Fixed format of LED nodes
> > > >
> > > > Changes in v5:
> > > > - Dropped the empty PCIe node
> > > > - Dropped useless `/delete-property/`
> > > > - Renamed LED nodes
> > > >
> > > > [...]
> > >
> > > Applied, thanks!
> > >
> > > [1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
> > >       commit: 1003888415e83e15ddb63d1d96189b4f2c5f1d48
> > > [2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
> > >       commit: db792e9adbf85ffc9d6b0b060ac3c8e3148c8992
> >
> > Sorry for late review, but:
> >
> >
> > +                       label = "red:sys";
> >
> > This should be red:power based on the discussion in earlier threads.
> 
> However based on the introduction from FriendlyELEC[1], this is not
> the "power" lamp...
> "LEDs: 1 x power LED and 3 x GPIO Controlled LED (SYS, LAN, WAN)"

It is always on, and "sys" is not a valid function.

I'd suggest labeling it as "red:power". Feel free to make other
suggestion but lets keep existing functions.
								Pavel
-- 
http://www.livejournal.com/~pavelmachek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210426/68e08de3/attachment.sig>

From cnsztl at gmail.com  Mon Apr 26 12:14:03 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon, 26 Apr 2021 19:14:03 +0800
Subject: [PATCH v6 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
In-Reply-To: <20210426110316.GA13974@duo.ucw.cz>
References: <20210319051627.814-1-cnsztl@gmail.com>
 <161640742725.808893.3666594351389773587.b4-ty@sntech.de>
 <20210425213321.GF10996@amd>
 <CAOP2_ThcRMkgSm872q2By=gALoK-qAjq92FtNQkDO999pZR8kg@mail.gmail.com>
 <20210426110316.GA13974@duo.ucw.cz>
Message-ID: <CAOP2_Tixnza0w8x7-viZAgV1fSysuJ5ht_Ri1kyMEgZ9yabOhQ@mail.gmail.com>

Hi,

On Mon, Apr 26, 2021 at 7:03 PM Pavel Machek <pavel at ucw.cz> wrote:
>
> Hi!
> > > > > - Fixed format of LED nodes
> > > > >
> > > > > Changes in v5:
> > > > > - Dropped the empty PCIe node
> > > > > - Dropped useless `/delete-property/`
> > > > > - Renamed LED nodes
> > > > >
> > > > > [...]
> > > >
> > > > Applied, thanks!
> > > >
> > > > [1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
> > > >       commit: 1003888415e83e15ddb63d1d96189b4f2c5f1d48
> > > > [2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
> > > >       commit: db792e9adbf85ffc9d6b0b060ac3c8e3148c8992
> > >
> > > Sorry for late review, but:
> > >
> > >
> > > +                       label = "red:sys";
> > >
> > > This should be red:power based on the discussion in earlier threads.
> >
> > However based on the introduction from FriendlyELEC[1], this is not
> > the "power" lamp...
> > "LEDs: 1 x power LED and 3 x GPIO Controlled LED (SYS, LAN, WAN)"
>
> It is always on, and "sys" is not a valid function.
>
> I'd suggest labeling it as "red:power". Feel free to make other
> suggestion but lets keep existing functions.

I see, thank you very much!
I'll submit a patch later.

Thanks,
Tianling.

>                                                                 Pavel
> --
> http://www.livejournal.com/~pavelmachek


From andre.przywara at arm.com  Mon Apr 26 12:30:16 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 26 Apr 2021 12:30:16 +0100
Subject: [boot-wrapper PATCH 1/5] Decouple V2M_SYS config by auto-detect
 dtb node
In-Reply-To: <20210420072438.183086-2-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-2-jaxson.han@arm.com>
Message-ID: <20210426123016.76947383@slackpad.fritz.box>

On Tue, 20 Apr 2021 15:24:34 +0800
Jaxson Han <jaxson.han at arm.com> wrote:

Hi,

> An auto-detect switch is added to make it an option to enable/disable
> 'arm,vexpress-sysreg', because not all platforms support this feature.

The change itself is fine, only has the side effect of now printing an
message about the missing node:
No matching devices found at ./findbase.pl line 37.

I will have a look if we can avoid this, or we drop this message in findbase.pl at all.

But for the sake of this patch:

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre

> Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> ---
>  Makefile.am | 2 +-
>  platform.c  | 4 ++++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index af694b7..e131207 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -19,7 +19,7 @@ NR_CPUS         := $(shell echo $(CPU_IDS) | tr ',' ' ' | wc -w)
>  DEFINES		= -DCNTFRQ=$(CNTFRQ)
>  DEFINES		+= -DCPU_IDS=$(CPU_IDS)
>  DEFINES		+= -DNR_CPUS=$(NR_CPUS)
> -DEFINES		+= -DSYSREGS_BASE=$(SYSREGS_BASE)
> +DEFINES		+= $(if $(SYSREGS_BASE), -DSYSREGS_BASE=$(SYSREGS_BASE), )
>  DEFINES		+= -DUART_BASE=$(UART_BASE)
>  DEFINES		+= -DSTACK_SIZE=256
>  
> diff --git a/platform.c b/platform.c
> index a528a55..d11f568 100644
> --- a/platform.c
> +++ b/platform.c
> @@ -23,10 +23,12 @@
>  
>  #define PL011(reg)	((void *)UART_BASE + PL011_##reg)
>  
> +#ifdef SYSREGS_BASE
>  #define V2M_SYS_CFGDATA		0xa0
>  #define V2M_SYS_CFGCTRL		0xa4
>  
>  #define V2M_SYS(reg)	((void *)SYSREGS_BASE + V2M_SYS_##reg)
> +#endif
>  
>  static void print_string(const char *str)
>  {
> @@ -59,6 +61,7 @@ void init_platform(void)
>  
>  	print_string("Boot-wrapper v0.2\r\n\r\n");
>  
> +#ifdef SYSREGS_BASE
>  	/*
>  	 * CLCD output site MB
>  	 */
> @@ -66,4 +69,5 @@ void init_platform(void)
>  	/* START | WRITE | MUXFPGA | SITE_MB */
>  	raw_writel((1 << 31) | (1 << 30) | (7 << 20) | (0 << 16),
>  				V2M_SYS(CFGCTRL));
> +#endif
>  }



From andre.przywara at arm.com  Mon Apr 26 12:40:54 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 26 Apr 2021 12:40:54 +0100
Subject: [boot-wrapper PATCH 2/5] aarch64: Rename labels and prepare for
 lower EL booting
In-Reply-To: <20210420072438.183086-3-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-3-jaxson.han@arm.com>
Message-ID: <20210426124055.20253825@slackpad.fritz.box>

On Tue, 20 Apr 2021 15:24:35 +0800
Jaxson Han <jaxson.han at arm.com> wrote:

> Prepare for booting from lower EL. Rename *_el3 relavant labels with
> *_el_max and *_no_el3 with *_keep_el. Since the original _no_el3 means
> "We neither do init sequence at this highest EL nor drop to lower EL
> when entering to kernel", we rename it with _keep_el to make it more
> clear for lower EL initialisation.

So this cleanup and rename is fine, however the patch is hard to read
since various other changes are mixed in.
Can you try to isolate this more? If this patch would just rename the
labels, and wouldn't carry any functional change, it might be easier to
reason about. At least the SPSR value change should be separate.

Some more below:

> Also in jump_kernel, skip sctlr_el2 initialisation when CurrentEL < EL2.
> 
> Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> ---
>  arch/aarch64/boot.S            | 54 +++++++++++++++++++++++++---------
>  arch/aarch64/include/asm/cpu.h |  3 ++
>  arch/aarch64/psci.S            | 13 ++++----
>  arch/aarch64/spin.S            |  8 ++---
>  4 files changed, 54 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index e47cf59..f7dbf3f 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -12,7 +12,7 @@
>  	.section .init
>  
>  	.globl	_start
> -	.globl jump_kernel
> +	.globl	jump_kernel
>  
>  _start:
>  	cpuid	x0, x1
> @@ -22,20 +22,30 @@ _start:
>  	bl	setup_stack
>  
>  	/*
> -	 * EL3 initialisation
> +	 * Boot sequence
> +	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
> +	 *   lower EL before entering the kernel.
> +	 * Else, no initialisation and keep the current EL before
> +	 *   entering the kernel.
>  	 */
>  	mrs	x0, CurrentEL
>  	cmp	x0, #CURRENTEL_EL3
> -	b.eq	1f
> +	beq	el3_init
>  
> +	/*
> +	 * We stay in the current EL for entering the kernel
> +	 */
>  	mov	w0, #1
> -	ldr	x1, =flag_no_el3
> +	ldr	x1, =flag_keep_el
>  	str	w0, [x1]
>  
> -	bl	setup_stack

I think this is indeed redundant, but can you either make this a
separate patch or at least mention it in the commit message?

> -	b	start_no_el3
> +	b	start_keep_el
>  
> -1:	mov	x0, #0x30			// RES1
> +	/*
> +	 * EL3 initialisation
> +	 */
> +el3_init:
> +	mov	x0, #0x30			// RES1
>  	orr	x0, x0, #(1 << 0)		// Non-secure EL1
>  	orr	x0, x0, #(1 << 8)		// HVC enable
>  
> @@ -93,13 +103,23 @@ _start:
>  	mov	x0, #ZCR_EL3_LEN_MASK		// SVE: Enable full vector len
>  	msr	ZCR_EL3, x0			// for EL2.
>  
> -1:
> +	/*
> +	 * Save SPSR_KERNEL into spsr_to_elx.
> +	 * The jump_kernel will load spsr_to_elx into spsr_el3
> +	 */
> +1:	mov	w0, #SPSR_KERNEL
> +	ldr	x1, =spsr_to_elx
> +	str	w0, [x1]
> +	b	el_max_init

This (and the other SPSR related changes below) should be in a separate
patch.

> +
> +el_max_init:
>  	ldr	x0, =CNTFRQ
>  	msr	cntfrq_el0, x0
> +	isb

Why this isb here? I don't see that we would require this?

>  	bl	gic_secure_init
>  
> -	b	start_el3
> +	b	start_el_max
>  
>  err_invalid_id:
>  	b	.
> @@ -119,14 +139,18 @@ jump_kernel:
>  	ldr	x0, =SCTLR_EL1_RESET
>  	msr	sctlr_el1, x0
>  
> +	mrs	x0, CurrentEL
> +	cmp	x0, #CURRENTEL_EL2
> +	b.lt	1f
> +

This is also a change which might be separate.

Cheers,
Andre


>  	ldr	x0, =SCTLR_EL2_RESET
>  	msr	sctlr_el2, x0
>  
> -	cpuid	x0, x1
> +1:	cpuid	x0, x1
>  	bl	find_logical_id
>  	bl	setup_stack		// Reset stack pointer
>  
> -	ldr	w0, flag_no_el3
> +	ldr	w0, flag_keep_el
>  	cmp	w0, #0			// Prepare Z flag
>  
>  	mov	x0, x20
> @@ -135,9 +159,9 @@ jump_kernel:
>  	mov	x3, x23
>  
>  	b.eq	1f
> -	br	x19			// No EL3
> +	br	x19			// Keep current EL
>  
> -1:	mov	x4, #SPSR_KERNEL
> +1:	ldr	w4, spsr_to_elx
>  
>  	/*
>  	 * If bit 0 of the kernel address is set, we're entering in AArch32
> @@ -153,5 +177,7 @@ jump_kernel:
>  
>  	.data
>  	.align 3
> -flag_no_el3:
> +flag_keep_el:
> +	.long 0
> +spsr_to_elx:
>  	.long 0
> diff --git a/arch/aarch64/include/asm/cpu.h b/arch/aarch64/include/asm/cpu.h
> index ccb5397..2b3a0a4 100644
> --- a/arch/aarch64/include/asm/cpu.h
> +++ b/arch/aarch64/include/asm/cpu.h
> @@ -11,6 +11,7 @@
>  
>  #define MPIDR_ID_BITS		0xff00ffffff
>  
> +#define CURRENTEL_EL2		(2 << 2)
>  #define CURRENTEL_EL3		(3 << 2)
>  
>  /*
> @@ -24,6 +25,7 @@
>  #define SPSR_I			(1 << 7)	/* IRQ masked */
>  #define SPSR_F			(1 << 6)	/* FIQ masked */
>  #define SPSR_T			(1 << 5)	/* Thumb */
> +#define SPSR_EL1H		(5 << 0)	/* EL1 Handler mode */
>  #define SPSR_EL2H		(9 << 0)	/* EL2 Handler mode */
>  #define SPSR_HYP		(0x1a << 0)	/* M[3:0] = hyp, M[4] = AArch32 */
>  
> @@ -42,6 +44,7 @@
>  #else
>  #define SCTLR_EL1_RESET		SCTLR_EL1_RES1
>  #define SPSR_KERNEL		(SPSR_A | SPSR_D | SPSR_I | SPSR_F | SPSR_EL2H)
> +#define SPSR_KERNEL_EL1		(SPSR_A | SPSR_D | SPSR_I | SPSR_F | SPSR_EL1H)
>  #endif
>  
>  #ifndef __ASSEMBLY__
> diff --git a/arch/aarch64/psci.S b/arch/aarch64/psci.S
> index 01ebe7d..ae02fd6 100644
> --- a/arch/aarch64/psci.S
> +++ b/arch/aarch64/psci.S
> @@ -45,8 +45,8 @@ vector:
>  
>  	.text
>  
> -	.globl start_no_el3
> -	.globl start_el3
> +	.globl start_keep_el
> +	.globl start_el_max
>  
>  err_exception:
>  	b err_exception
> @@ -101,7 +101,7 @@ smc_exit:
>  	eret
>  
>  
> -start_el3:
> +start_el_max:
>  	ldr	x0, =vector
>  	bl	setup_vector
>  
> @@ -111,10 +111,11 @@ start_el3:
>  	b	psci_first_spin
>  
>  /*
> - * This PSCI implementation requires EL3. Without EL3 we'll only boot the
> - * primary cpu, all others will be trapped in an infinite loop.
> + * This PSCI implementation requires the highest EL(EL3 or Armv8-R EL2).
> + * Without the highest EL, we'll only boot the primary cpu, all others
> + * will be trapped in an infinite loop.
>   */
> -start_no_el3:
> +start_keep_el:
>  	cpuid	x0, x1
>  	bl	find_logical_id
>  	cbz	x0, psci_first_spin
> diff --git a/arch/aarch64/spin.S b/arch/aarch64/spin.S
> index 72603cf..533177c 100644
> --- a/arch/aarch64/spin.S
> +++ b/arch/aarch64/spin.S
> @@ -11,11 +11,11 @@
>  
>  	.text
>  
> -	.globl start_no_el3
> -	.globl start_el3
> +	.globl start_keep_el
> +	.globl start_el_max
>  
> -start_el3:
> -start_no_el3:
> +start_el_max:
> +start_keep_el:
>  	cpuid	x0, x1
>  	bl	find_logical_id
>  



From cnsztl at gmail.com  Mon Apr 26 12:46:52 2021
From: cnsztl at gmail.com (Tianling Shen)
Date: Mon, 26 Apr 2021 19:46:52 +0800
Subject: [PATCH] arm64: dts: rockchip: rename LED label for NanoPi R4S
Message-ID: <20210426114652.29542-1-cnsztl@gmail.com>

However "sys" is not a valid function, and it is always on.
Let's keep existing functions.

Fixes: db792e9adbf85f ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S")

Suggested-by: Pavel Machek <pavel at ucw.cz>
Signed-off-by: Tianling Shen <cnsztl at gmail.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
index fa5809887643..cef4d18b599d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
@@ -33,7 +33,7 @@
 
 		sys_led: led-sys {
 			gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
-			label = "red:sys";
+			label = "red:power";
 			default-state = "on";
 		};
 
-- 
2.17.1



From andre.przywara at arm.com  Mon Apr 26 12:48:18 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 26 Apr 2021 12:48:18 +0100
Subject: [boot-wrapper PATCH 3/5] gic-v3: Prepare for gicv3 with EL2
In-Reply-To: <20210420072438.183086-4-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-4-jaxson.han@arm.com>
Message-ID: <20210426124818.28a57afa@slackpad.fritz.box>

On Tue, 20 Apr 2021 15:24:36 +0800
Jaxson Han <jaxson.han at arm.com> wrote:

> This is a preparation for allowing boot-wrapper configuring the gicv3
> with EL2.

The GIC is always confusing, so can you please give some more
background here? The introduction of ICC_SRE_EL2 looks straight-forward
enough, but the change to the ICC_CTLR_RESET register deserves some
comments, I guess.

Cheers,
Andre

> Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> ---
>  arch/aarch32/include/asm/gic-v3.h |  7 ++++++
>  arch/aarch64/include/asm/gic-v3.h | 38 ++++++++++++++++++++++++++++---
>  gic-v3.c                          |  2 +-
>  3 files changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/aarch32/include/asm/gic-v3.h b/arch/aarch32/include/asm/gic-v3.h
> index ec9a327..86abe09 100644
> --- a/arch/aarch32/include/asm/gic-v3.h
> +++ b/arch/aarch32/include/asm/gic-v3.h
> @@ -9,6 +9,8 @@
>  #ifndef __ASM_AARCH32_GICV3_H
>  #define __ASM_AARCH32_GICV3_H
>  
> +#define ICC_CTLR_RESET	(0UL)
> +
>  static inline uint32_t gic_read_icc_sre(void)
>  {
>  	uint32_t val;
> @@ -26,4 +28,9 @@ static inline void gic_write_icc_ctlr(uint32_t val)
>  	asm volatile ("mcr p15, 6, %0, c12, c12, 4" : : "r" (val));
>  }
>  
> +static inline void gic_init_icc_ctlr()
> +{
> +	gic_write_icc_ctlr(ICC_CTLR_RESET);
> +}
> +
>  #endif
> diff --git a/arch/aarch64/include/asm/gic-v3.h b/arch/aarch64/include/asm/gic-v3.h
> index e743c02..b3dfbd3 100644
> --- a/arch/aarch64/include/asm/gic-v3.h
> +++ b/arch/aarch64/include/asm/gic-v3.h
> @@ -15,21 +15,53 @@
>  #define ICC_CTLR_EL3	"S3_6_C12_C12_4"
>  #define ICC_PMR_EL1	"S3_0_C4_C6_0"
>  
> +#define ICC_CTLR_EL3_RESET	(0UL)
> +#define ICC_CTLR_EL1_RESET	(0UL)
> +
> +static inline uint32_t current_el(void)
> +{
> +	uint32_t val;
> +
> +	asm volatile ("mrs %0, CurrentEL" : "=r" (val));
> +	return val;
> +}
> +
>  static inline uint32_t gic_read_icc_sre(void)
>  {
>  	uint32_t val;
> -	asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
> +
> +	if(current_el() == CURRENTEL_EL3)
> +		asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
> +	else
> +		asm volatile ("mrs %0, " ICC_SRE_EL2 : "=r" (val));
> +
>  	return val;
>  }
>  
>  static inline void gic_write_icc_sre(uint32_t val)
>  {
> -	asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
> +	if(current_el() == CURRENTEL_EL3)
> +		asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
> +	else
> +		asm volatile ("msr " ICC_SRE_EL2 ", %0" : : "r" (val));
>  }
>  
> -static inline void gic_write_icc_ctlr(uint32_t val)
> +static inline void gic_write_icc_ctlr_el3(uint32_t val)
>  {
>  	asm volatile ("msr " ICC_CTLR_EL3 ", %0" : : "r" (val));
>  }
>  
> +static inline void gic_write_icc_ctlr_el1(uint32_t val)
> +{
> +	asm volatile ("msr " ICC_CTLR_EL1 ", %0" : : "r" (val));
> +}
> +
> +static inline void gic_init_icc_ctlr()
> +{
> +	if(current_el() == CURRENTEL_EL3)
> +		gic_write_icc_ctlr_el3(ICC_CTLR_EL3_RESET);
> +	else
> +		gic_write_icc_ctlr_el1(ICC_CTLR_EL1_RESET);
> +}
> +
>  #endif
> diff --git a/gic-v3.c b/gic-v3.c
> index ae2d2bc..4850572 100644
> --- a/gic-v3.c
> +++ b/gic-v3.c
> @@ -121,6 +121,6 @@ void gic_secure_init(void)
>  	gic_write_icc_sre(sre);
>  	isb();
>  
> -	gic_write_icc_ctlr(0);
> +	gic_init_icc_ctlr();
>  	isb();
>  }



From andre.przywara at arm.com  Mon Apr 26 12:51:01 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 26 Apr 2021 12:51:01 +0100
Subject: [boot-wrapper PATCH 4/5] aarch64: Prepare for booting with EL2
In-Reply-To: <20210420072438.183086-5-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-5-jaxson.han@arm.com>
Message-ID: <20210426125101.07c62fe6@slackpad.fritz.box>

On Tue, 20 Apr 2021 15:24:37 +0800
Jaxson Han <jaxson.han at arm.com> wrote:

> Prepare for allowing boot-wrapper to be entered in EL2.
> 
> Signed-off-by: Jaxson Han <jaxson.han at arm.com>

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Thanks,
Andre

> ---
>  arch/aarch64/utils.S | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/aarch64/utils.S b/arch/aarch64/utils.S
> index ae22ea7..94e9931 100644
> --- a/arch/aarch64/utils.S
> +++ b/arch/aarch64/utils.S
> @@ -37,10 +37,18 @@ find_logical_id:
>  	ret
>  
>  /*
> - * Setup EL3 vectors
> + * Setup EL3/EL2 vectors
>   * x0: vector address
>   */
>  setup_vector:
> +	mrs	x1, CurrentEL
> +	cmp	x1, #CURRENTEL_EL2
> +	b.eq	1f
> +
>  	msr	VBAR_EL3, x0
>  	isb
>  	ret
> +
> +1:	msr	VBAR_EL2, x0
> +	isb
> +	ret



From qii.wang at mediatek.com  Mon Apr 26 12:46:15 2021
From: qii.wang at mediatek.com (qii.wang at mediatek.com)
Date: Mon, 26 Apr 2021 19:46:15 +0800
Subject: [PATCH] i2c: mediatek: Rename i2c irq name
Message-ID: <1619437575-23482-1-git-send-email-qii.wang@mediatek.com>

From: Qii Wang <qii.wang at mediatek.com>

Rename i2c irq name with dev_name() which can provide unique
naming in /proc/interrupts for each instance of the I2C IP core.

Signed-off-by: Qii Wang <qii.wang at mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 5ddfa4e..ea337ba 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1281,7 +1281,7 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 
 	ret = devm_request_irq(&pdev->dev, irq, mtk_i2c_irq,
 			       IRQF_NO_SUSPEND | IRQF_TRIGGER_NONE,
-			       I2C_DRV_NAME, i2c);
+			       dev_name(&pdev->dev), i2c);
 	if (ret < 0) {
 		dev_err(&pdev->dev,
 			"Request I2C IRQ %d fail\n", irq);
-- 
1.9.1

From broonie at kernel.org  Mon Apr 26 12:56:45 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 26 Apr 2021 12:56:45 +0100
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
In-Reply-To: <CAKaHn9+d5crmmG-aKyLuvyxk+A7aC9qqfX_3wuMXm50pg+pZ4w@mail.gmail.com>
References: <20210423034247.992052-1-art@khadas.com>
 <20210423114735.GA5507@sirena.org.uk>
 <CAKaHn9+d5crmmG-aKyLuvyxk+A7aC9qqfX_3wuMXm50pg+pZ4w@mail.gmail.com>
Message-ID: <20210426115645.GB4590@sirena.org.uk>

On Sat, Apr 24, 2021 at 07:57:19AM +0800, Art Nikpal wrote:

> > I would expect the driver to unregister the controller at the start of
> > the remove function, suspend doesn't really make sense here

> It's strange - But without spi_master_suspend i have randomly stucks when i
> try unload this module - as was written before
> i was test it (load/unload module in loop) and for me suspend make sense
> here

> If anybody has another solution - or real problem not here - please write
> to me the right way!

As I said above unregister the controller at the start of the remove
function.
-------------- 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/20210426/d63c513e/attachment.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:13:11 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:13:11 +0200
Subject: [PATCH v2 01/10] memory: tegra: Implement SID override programming
In-Reply-To: <03e2a655-7dbf-a729-75f6-98db353e2b91@canonical.com>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
 <20210420172619.3782831-2-thierry.reding@gmail.com>
 <03e2a655-7dbf-a729-75f6-98db353e2b91@canonical.com>
Message-ID: <YIauV/BgPCZSZ8u2@orome.fritz.box>

On Mon, Apr 26, 2021 at 10:28:43AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 19:26, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > Instead of programming all SID overrides during early boot, perform the
> > operation on-demand after the SMMU translations have been set up for a
> > device. This reuses data from device tree to match memory clients for a
> > device and programs the SID specified in device tree, which corresponds
> > to the SID used for the SMMU context banks for the device.
> > 
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > ---
> >  drivers/memory/tegra/mc.c       |  9 +++++
> >  drivers/memory/tegra/tegra186.c | 72 +++++++++++++++++++++++++++++++++
> >  include/soc/tegra/mc.h          |  3 ++
> >  3 files changed, 84 insertions(+)
> > 
> > diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > index c854639cf30c..bace5ecfe770 100644
> > --- a/drivers/memory/tegra/mc.c
> > +++ b/drivers/memory/tegra/mc.c
> > @@ -97,6 +97,15 @@ struct tegra_mc *devm_tegra_memory_controller_get(struct device *dev)
> >  }
> >  EXPORT_SYMBOL_GPL(devm_tegra_memory_controller_get);
> >  
> > +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> > +{
> > +	if (mc->soc->ops && mc->soc->ops->probe_device)
> > +		return mc->soc->ops->probe_device(mc, dev);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tegra_mc_probe_device);
> > +
> >  static int tegra_mc_block_dma_common(struct tegra_mc *mc,
> >  				     const struct tegra_mc_reset *rst)
> >  {
> > diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> > index 1f87915ccd62..e65eac5764d4 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -4,6 +4,7 @@
> >   */
> >  
> >  #include <linux/io.h>
> > +#include <linux/iommu.h>
> >  #include <linux/module.h>
> >  #include <linux/mod_devicetable.h>
> >  #include <linux/of_device.h>
> > @@ -15,6 +16,10 @@
> >  #include <dt-bindings/memory/tegra186-mc.h>
> >  #endif
> >  
> > +#define MC_SID_STREAMID_OVERRIDE_MASK GENMASK(7, 0)
> > +#define MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED BIT(16)
> > +#define MC_SID_STREAMID_SECURITY_OVERRIDE BIT(8)
> > +
> >  static void tegra186_mc_program_sid(struct tegra_mc *mc)
> >  {
> >  	unsigned int i;
> > @@ -66,10 +71,77 @@ static int tegra186_mc_resume(struct tegra_mc *mc)
> >  	return 0;
> >  }
> >  
> > +static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> > +					    const struct tegra_mc_client *client,
> > +					    unsigned int sid)
> > +{
> > +	u32 value, old;
> > +
> > +	value = readl(mc->regs + client->regs.sid.security);
> > +	if ((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0) {
> > +		/*
> > +		 * If the secure firmware has locked this down the override
> > +		 * for this memory client, there's nothing we can do here.
> > +		 */
> > +		if (value & MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED)
> > +			return;
> > +
> > +		/*
> > +		 * Otherwise, try to set the override itself. Typically the
> > +		 * secure firmware will never have set this configuration.
> > +		 * Instead, it will either have disabled write access to
> > +		 * this field, or it will already have set an explicit
> > +		 * override itself.
> > +		 */
> > +		WARN_ON((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0);
> > +
> > +		value |= MC_SID_STREAMID_SECURITY_OVERRIDE;
> > +		writel(value, mc->regs + client->regs.sid.security);
> > +	}
> > +
> > +	value = readl(mc->regs + client->regs.sid.override);
> > +	old = value & MC_SID_STREAMID_OVERRIDE_MASK;
> > +
> > +	if (old != sid) {
> > +		dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
> > +			client->name, sid);
> > +		writel(sid, mc->regs + client->regs.sid.override);
> > +	}
> > +}
> > +
> > +static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> > +{
> > +#if IS_ENABLED(CONFIG_IOMMU_API)
> 
> Is this part really build-time dependent? I don't see here any uses of
> IOMMU specific fields, so maybe this should be runtime choice based on
> enabled interconnect devices?

Unfortunately it is. struct iommu_fwspec is an empty structure for
!CONFIG_IOMMU_API, so the code below that tries to access fwspec->ids
fails for !CONFIG_IOMMU_API configurations if we don't protect this with
the preprocessor guard.

> 
> > +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > +	struct of_phandle_args args;
> > +	unsigned int i, index = 0;
> > +
> > +	while (!of_parse_phandle_with_args(dev->of_node, "interconnects", "#interconnect-cells",
> > +					   index, &args)) {
> > +		if (args.np == mc->dev->of_node && args.args_count != 0) {
> > +			for (i = 0; i < mc->soc->num_clients; i++) {
> > +				const struct tegra_mc_client *client = &mc->soc->clients[i];
> > +
> > +				if (client->id == args.args[0]) {
> > +					u32 sid = fwspec->ids[0] & MC_SID_STREAMID_OVERRIDE_MASK;
> > +
> > +					tegra186_mc_client_sid_override(mc, client, sid);
> > +				}
> > +			}
> > +		}
> > +
> > +		index++;
> > +	}
> > +#endif
> > +
> > +	return 0;
> > +}
> > +
> >  const struct tegra_mc_ops tegra186_mc_ops = {
> >  	.probe = tegra186_mc_probe,
> >  	.remove = tegra186_mc_remove,
> >  	.resume = tegra186_mc_resume,
> > +	.probe_device = tegra186_mc_probe_device,
> >  };
> >  
> >  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
> > diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> > index 1387747d574b..bbad6330008b 100644
> > --- a/include/soc/tegra/mc.h
> > +++ b/include/soc/tegra/mc.h
> > @@ -176,6 +176,7 @@ struct tegra_mc_ops {
> >  	int (*suspend)(struct tegra_mc *mc);
> >  	int (*resume)(struct tegra_mc *mc);
> >  	irqreturn_t (*handle_irq)(int irq, void *data);
> > +	int (*probe_device)(struct tegra_mc *mc, struct device *dev);
> >  };
> >  
> >  struct tegra_mc_soc {
> > @@ -240,4 +241,6 @@ devm_tegra_memory_controller_get(struct device *dev)
> >  }
> >  #endif
> >  
> > +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
> > +
> 
> What about !CONFIG_TEGRA_MC? I think arm-smmmu will fail.

I think it doesn't fail because for !CONFIG_TEGRA_MC it basically throws
away most of nvidia_smmu_impl_init() already because ERR_PTR(-ENODEV) is
returned by devm_tegra_memory_controller_get() and so it unconditionally
fails early on already.

I say I /think/ that happens because I can't reproduce a build failure
even if I manually tweak the .config such that ARM_SMMU is enabled and
TEGRA_MC is disabled. But I can't say I fully understand why it's
working, because, yes, the symbol definitely doesn't exist. But again,
if the compiler is clever enough to figure out that that function can't
be called anyway and doesn't even want it, why bother making it more
complicated than it has to be?

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/20210426/a7d7c9a8/attachment-0001.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:15:06 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:15:06 +0200
Subject: [PATCH 00/10] memory: tegra: Driver unification
In-Reply-To: <519a1ee4-52a3-a465-9203-b14ae10d5e49@canonical.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <519a1ee4-52a3-a465-9203-b14ae10d5e49@canonical.com>
Message-ID: <YIauys8FZGKCDl0V@orome.fritz.box>

On Mon, Apr 26, 2021 at 11:06:51AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 18:52, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > Hi,
> > 
> > this set of patches converges the feature sets of the pre-Tegra186 and
> > the post-Tegra186 memory controller drivers such that newer chips can
> > take advantage of some features that were previously only implemented
> > on earlier chips.
> > 
> > Note that this looks a bit daunting from a diffstat point of view but
> > the bulk of this is in the first two patches that basically shuffle
> > around where some of the per-memory-client register definitions are
> > located, hence the big number of changed lines.
> > 
> > I haven't done any exhaustive testing on the series yet, but wanted to
> > get some feedback on the general idea. I'll queue up this up for our
> > automated testing in the coming days.
> > 
> > Thierry
> > 
> > Thierry Reding (10):
> >   memory: tegra: Consolidate register fields
> >   memory: tegra: Unify struct tegra_mc across SoC generations
> >   memory: tegra: Push suspend/resume into SoC drivers
> >   memory: tegra: Make per-SoC setup more generic
> >   memory: tegra: Extract setup code into callback
> >   memory: tegra: Parameterize interrupt handler
> >   memory: tegra: Only initialize reset controller if available
> >   memory: tegra: Unify drivers
> >   memory: tegra: Add memory client IDs to tables
> >   memory: tegra: Split Tegra194 data into separate file
> 
> I didn't get patch 10/10. Neither did lore.

I suspect that I typed one too many zeros before the wildcard and
therefore the glob didn't pick up that last patch. I'll make sure to
include it in v2.

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/20210426/1211355b/attachment.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:15:54 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:15:54 +0200
Subject: [PATCH 08/10] memory: tegra: Unify drivers
In-Reply-To: <a4d73dca-92a3-d5e5-677f-498f84aa0457@gmail.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-9-thierry.reding@gmail.com>
 <a4d73dca-92a3-d5e5-677f-498f84aa0457@gmail.com>
Message-ID: <YIau+hPAXWgDBGRe@orome.fritz.box>

On Wed, Apr 21, 2021 at 02:46:24PM +0300, Dmitry Osipenko wrote:
> 20.04.2021 19:52, Thierry Reding ?????:
> > +/*
> > + * XXX The Tegra186 memory controller driver used to be able to do this. Once
> > + * removing the driver is supported on all chips, this can be uncommented.
> > + */
> > +/*
> > +static int tegra_mc_remove(struct platform_device *pdev)
> > +{
> > +	struct tegra_mc *mc = platform_get_drvdata(pdev);
> > +
> > +	if (mc->soc->ops && mc->soc->ops->remove)
> > +		mc->soc->ops->remove(mc);
> > +
> > +	return 0;
> > +}
> > +*/
> > +
> >  static int __maybe_unused tegra_mc_suspend(struct device *dev)
> >  {
> >  	struct tegra_mc *mc = dev_get_drvdata(dev);
> > @@ -834,6 +856,9 @@ static struct platform_driver tegra_mc_driver = {
> >  	},
> >  	.prevent_deferred_probe = true,
> >  	.probe = tegra_mc_probe,
> > +	/*
> > +	.remove = tegra_mc_remove,
> > +	*/
> >  };
> 
> The commented lines shouldn't be in the final version of the patch, IMO.
> These lines either should be uncommented and the remove() callback
> should return -EOPNOTSUPP or they should be removed for now.

Fair enough, I'll drop them in v2.

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/20210426/45490bcd/attachment.sig>

From lukma at denx.de  Mon Apr 26 13:16:05 2021
From: lukma at denx.de (Lukasz Majewski)
Date: Mon, 26 Apr 2021 14:16:05 +0200
Subject: [PATCH 2/2] ARM: dts: imx28: Add DTS description of imx28 based XEA
 board
Message-ID: <20210426121605.31651-1-lukma@denx.de>

This patch adds DTS definition of the imx278 based XEA board.

Signed-off-by: Lukasz Majewski <lukma at denx.de>

---
Changes for v2:
- Fix 'memory' node and remove regulators subnode
- Rename 'flash0: s25fl256s0 at 0' to flash at 0
- Add proper compatible for XEA board
---
 arch/arm/boot/dts/Makefile       |   3 +-
 arch/arm/boot/dts/imx28-lwe.dtsi | 174 +++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx28-xea.dts  |  99 ++++++++++++++++++
 3 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx28-lwe.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-xea.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e5d4ab4e75e..d2398a090e4d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -721,7 +721,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
 	imx28-m28evk.dtb \
 	imx28-sps1.dtb \
 	imx28-ts4600.dtb \
-	imx28-tx28.dtb
+	imx28-tx28.dtb \
+	imx28-xea.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
 	ste-nomadik-s8815.dtb \
 	ste-nomadik-nhk15.dtb
diff --git a/arch/arm/boot/dts/imx28-lwe.dtsi b/arch/arm/boot/dts/imx28-lwe.dtsi
new file mode 100644
index 000000000000..2d14a8ae91f8
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-lwe.dtsi
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2021
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+
+/ {
+	aliases {
+		spi2 = &ssp3;
+	};
+
+	chosen {
+		bootargs = "root=/dev/mmcblk0p2 rootfstype=ext4 ro rootwait console=ttyAMA0,115200 panic=1";
+	};
+
+	memory at 0x40000000 {
+		reg = <0x40000000 0x08000000>;
+	};
+
+	reg_3v3: regulator-reg-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_usb_5v: regulator-reg-usb-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+	};
+
+	reg_fec_3v3: regulator-reg-fec-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "fec-phy";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		enable-active-high;
+		regulator-boot-on;
+	};
+};
+
+&duart {
+	pinctrl-names = "default";
+	pinctrl-0 = <&duart_pins_a>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+};
+
+&saif0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif0_pins_a>;
+	#sound-dai-cells = <0>;
+	assigned-clocks = <&clks 53>;
+	assigned-clock-rates = <12000000>;
+	status = "okay";
+};
+
+&saif1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&saif1_pins_a>;
+	fsl,saif-master = <&saif0>;
+	#sound-dai-cells = <0>;
+	status = "okay";
+};
+
+&spi3_pins_a {
+	fsl,pinmux-ids = <
+		MX28_PAD_AUART2_RX__SSP3_D4
+		MX28_PAD_AUART2_TX__SSP3_D5
+		MX28_PAD_SSP3_SCK__SSP3_SCK
+		MX28_PAD_SSP3_MOSI__SSP3_CMD
+		MX28_PAD_SSP3_MISO__SSP3_D0
+		MX28_PAD_SSP3_SS0__SSP3_D3
+		MX28_PAD_AUART2_TX__GPIO_3_9
+	>;
+};
+
+&ssp3 {
+	compatible = "fsl,imx28-spi";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi3_pins_a>;
+	status = "okay";
+
+	flash at 0 {
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <40000000>;
+		reg = <0>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				label = "u-boot";
+				reg = <0 0x80000>;
+				read-only;
+			};
+
+			partition at 80000 {
+				label = "env0";
+				reg = <0x80000 0x10000>;
+			};
+
+			partition at 90000 {
+				label = "env1";
+				reg = <0x90000 0x10000>;
+			};
+
+			partition at 100000 {
+				label = "kernel";
+				reg = <0x100000 0x400000>;
+			};
+
+			partition at 500000 {
+				label = "swupdate";
+				reg = <0x500000 0x800000>;
+			};
+		};
+	};
+};
+
+&ssp2 {
+	compatible = "fsl,imx28-spi";
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_pins_a>;
+	status = "okay";
+};
+
+&ssp0 {
+	compatible = "fsl,imx28-mmc";
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_8bit_pins_a>;
+	bus-width = <8>;
+	vmmc-supply = <&reg_3v3>;
+	non-removable;
+	status = "okay";
+};
+
+&usb0 {
+	vbus-supply = <&reg_usb_5v>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_pins_b>, <&usb0_id_pins_a>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy0 {
+	status = "okay";
+};
+
+&usb1 {
+	vbus-supply = <&reg_usb_5v>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb1_pins_b>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx28-xea.dts b/arch/arm/boot/dts/imx28-xea.dts
new file mode 100644
index 000000000000..a400c108f66a
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-xea.dts
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2021
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx28-lwe.dtsi"
+
+/ {
+	compatible = "lwn,imx28-xea", "fsl,imx28";
+};
+
+&can0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&can1_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins_b>;
+	status = "okay";
+};
+
+&pinctrl {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hog_pins_a &hog_pins_tiva>;
+
+	hog_pins_a: hog at 0 {
+		reg = <0>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_D00__GPIO_0_0
+			MX28_PAD_GPMI_D02__GPIO_0_2
+			MX28_PAD_GPMI_D05__GPIO_0_5
+			MX28_PAD_GPMI_CE1N__GPIO_0_17
+			MX28_PAD_GPMI_RDY0__GPIO_0_20
+			MX28_PAD_GPMI_RDY1__GPIO_0_21
+			MX28_PAD_GPMI_RDY2__GPIO_0_22
+			MX28_PAD_GPMI_RDN__GPIO_0_24
+			MX28_PAD_GPMI_CLE__GPIO_0_27
+			MX28_PAD_LCD_VSYNC__GPIO_1_28
+			MX28_PAD_SSP1_SCK__GPIO_2_12
+			MX28_PAD_SSP1_CMD__GPIO_2_13
+			MX28_PAD_SSP2_SS1__GPIO_2_20
+			MX28_PAD_SSP2_SS2__GPIO_2_21
+			MX28_PAD_LCD_D00__GPIO_1_0
+			MX28_PAD_LCD_D01__GPIO_1_1
+			MX28_PAD_LCD_D02__GPIO_1_2
+			MX28_PAD_LCD_D03__GPIO_1_3
+			MX28_PAD_LCD_D04__GPIO_1_4
+			MX28_PAD_LCD_D05__GPIO_1_5
+			MX28_PAD_LCD_D06__GPIO_1_6
+		>;
+		fsl,drive-strength = <MXS_DRIVE_4mA>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+
+	hog_pins_tiva: hog at 1 {
+		reg = <1>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_RDY3__GPIO_0_23
+			MX28_PAD_GPMI_WRN__GPIO_0_25
+		>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+
+	hog_pins_coding: hog at 2 {
+		reg = <2>;
+		fsl,pinmux-ids = <
+			MX28_PAD_GPMI_D01__GPIO_0_1
+			MX28_PAD_GPMI_D03__GPIO_0_3
+			MX28_PAD_GPMI_D04__GPIO_0_4
+			MX28_PAD_GPMI_D06__GPIO_0_6
+			MX28_PAD_GPMI_D07__GPIO_0_7
+		>;
+		fsl,voltage = <MXS_VOLTAGE_HIGH>;
+		fsl,pull-up = <MXS_PULL_DISABLE>;
+	};
+};
+
+&reg_fec_3v3 {
+	gpio = <&gpio0 0 0>;
+};
+
+&reg_usb_5v {
+	gpio = <&gpio0 2 0>;
+};
+
+&spi2_pins_a {
+	fsl,pinmux-ids = <
+		MX28_PAD_SSP2_SCK__SSP2_SCK
+		MX28_PAD_SSP2_MOSI__SSP2_CMD
+		MX28_PAD_SSP2_MISO__SSP2_D0
+		MX28_PAD_SSP2_SS0__GPIO_2_19
+	>;
+};
-- 
2.20.1



From jbx6244 at gmail.com  Mon Apr 26 13:16:45 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Mon, 26 Apr 2021 14:16:45 +0200
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210425094439.25895-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
Message-ID: <3d584cdc-020e-5aae-cae3-59ef45e64a9f@gmail.com>

Hi Liang,

Some minor things to improve.
Found with the command below.

make ARCH=arm64 dtbs_check
===

pwm-rockchip.yaml is now in linux-next
Maybe add rockchip,rk3568-pwm too.

===

compatible = "rockchip,rk3568";
Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
of board list ???
Please advise.

===

Change rockchip,gpio-bank.yaml

  clocks:
    maxItems: 2

===

TODO:
rockchip,rk3568-grf
rockchip,rk3568-pmugrf

===

git am
PATCH-v2-5-7-arm64-dts-rockchip-add-generic-pinconfig-settings-used-by-most-Rockchip-socs.patch
Applying: arm64: dts: rockchip: add generic pinconfig settings used by
most Rockchip socs
.git/rebase-apply/patch:356: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

===

Change commit message in:
[PATCH v2 3/7] dt-bindings: mmc: rockchip-dw-mshc: add description for
rk3568

from:
add "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci" for mmc nodes on
a rk3568 platform to rockchip-dw-mshc.yaml.

to:
... "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" ...

Do not mix dw-mshc and dwcmshc. ;)

===

Johan

On 4/25/21 11:44 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipments. This patch
> add basic core dtsi file for it.
> 
> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> enalbe a special high-performacne PLL when high frequency is required. The
> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> 
>     cpu0: cpu at 0 {
>         device_type = "cpu";
>         compatible = "arm,cortex-a55";
>         reg = <0x0 0x0>;
>         clocks = <&scmi_clk 0>;
>     };
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
>  2 files changed, 3931 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
> 

[..]

> +
> +	gpio {

>From gpio.yaml

properties:
  gpio:
    # 'gpio' can appear as a property or node name
    oneOf:
      - type: object
      - $ref: "/schemas/types.yaml#/definitions/phandle-array"


> +		/omit-if-no-ref/

> +		tsadc_gpio: tsadc-gpio {

>From gpio-consumer.yaml

properties:
  gpios:
    $ref: "/schemas/types.yaml#/definitions/phandle-array"

patternProperties:
  "(?<!,nr)-gpios?$":
    $ref: "/schemas/types.yaml#/definitions/phandle-array"

===

Try to avoid anything with gpio.

> +			rockchip,pins =
> +				<0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..66cb50218ca1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,812 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <dt-bindings/clock/rk3568-cru.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,boot-mode.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {

> +	compatible = "rockchip,rk3568";

Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
of board list ???
Please advise.

> +
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +		i2c4 = &i2c4;
> +		i2c5 = &i2c5;

> +		mmc0 = &sdhci;
> +		mmc1 = &sdmmc0;
> +		mmc2 = &sdmmc1;
> +		mmc3 = &sdmmc2;

>From a  privious discussion: aliases for mmc should go from the dtsi to
the board dts
sort mmc aliases based on reg address and availability, so no number gap

> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5;
> +		serial6 = &uart6;
> +		serial7 = &uart7;
> +		serial8 = &uart8;
> +		serial9 = &uart9;
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x0>;
> +			clocks = <&scmi_clk 0>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu1: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x100>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu2: cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x200>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu3: cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x300>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +	};
> +
> +	cpu0_opp_table: cpu0-opp-table {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-408000000 {
> +			opp-hz = /bits/ 64 <408000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			clock-latency-ns = <40000>;
> +		};

Add all empty lines between

> +		opp-600000000 {
> +			opp-hz = /bits/ 64 <600000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +			opp-suspend;
> +		};
> +		opp-1104000000 {
> +			opp-hz = /bits/ 64 <1104000000>;
> +			opp-microvolt = <825000 825000 1150000>;
> +		};
> +		opp-1416000000 {
> +			opp-hz = /bits/ 64 <1416000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +		opp-1608000000 {
> +			opp-hz = /bits/ 64 <1608000000>;
> +			opp-microvolt = <975000 975000 1150000>;
> +		};
> +		opp-1800000000 {
> +			opp-hz = /bits/ 64 <1800000000>;
> +			opp-microvolt = <1050000 1050000 1150000>;
> +		};
> +		opp-1992000000 {
> +			opp-hz = /bits/ 64 <1992000000>;
> +			opp-microvolt = <1150000 1150000 1150000>;
> +		};
> +	};
> +
> +	firmware {
> +		scmi: scmi {
> +			compatible = "arm,scmi-smc";
> +			arm,smc-id = <0x82000010>;
> +			shmem = <&scmi_shmem>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			scmi_clk: protocol at 14 {
> +				reg = <0x14>;
> +				#clock-cells = <1>;
> +			};
> +		};
> +
> +	};
> +
> +	pmu {

> +		compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";

compatible: ['arm,cortex-a55-pmu', 'arm,armv8-pmuv3'] is too long

> +		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +

> +	shmem at 10f000 {

shmem at 10f000: $nodename:0: 'shmem at 10f000' does not match '^sram(@.*)?'

> +		compatible = "mmio-sram";
> +		reg = <0x0 0x0010f000 0x0 0x100>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges = <0 0x0 0x0010f000 0x100>;
> +

> +		scmi_shmem: scmi-shmem at 10f000 {

shmem at 10f000: 'scmi-shmem at 10f000' does not match any of the regexes:
'^([a-z]*-)?sram(-section)?@[a-f0-9]+$'

> +			compatible = "arm,scmi-shmem";
> +			reg = <0x0 0x0010f000 0x0 0x100>;
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,no-tick-in-suspend;
> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +		#clock-cells = <0>;
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		pinctrl-0 = <&clk32k_out0>;
> +		pinctrl-names = "default";
> +		#clock-cells = <0>;
> +	};
> +
> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-controller;
> +		#interrupt-cells = <3>;

> +		#address-cells = <2>;
> +		#size-cells = <2>;

subnodes ??

> +		ranges;
> +	};
> +
> +	pmugrf: syscon at fdc20000 {

> +		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";

TODO

> +		reg = <0x0 0xfdc20000 0x0 0x10000>;
> +
> +		reboot_mode: reboot-mode {
> +			compatible = "syscon-reboot-mode";
> +			mode-bootloader = <BOOT_BL_DOWNLOAD>;
> +			mode-fastboot = <BOOT_FASTBOOT>;
> +			mode-loader = <BOOT_BL_DOWNLOAD>;
> +			mode-normal = <BOOT_NORMAL>;
> +			mode-recovery = <BOOT_RECOVERY>;
> +			offset = <0x200>;
> +		};
> +	};
> +
> +	grf: syscon at fdc60000 {

> +		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";

TODO

> +		reg = <0x0 0xfdc60000 0x0 0x10000>;
> +	};
> +
> +	pmucru: clock-controller at fdd00000 {

> +		compatible = "rockchip,rk3568-pmucru";
> +		reg = <0x0 0xfdd00000 0x0 0x1000>;
> +		rockchip,grf = <&grf>;
> +		rockchip,pmugrf = <&pmugrf>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	cru: clock-controller at fdd20000 {
> +		compatible = "rockchip,rk3568-cru";
> +		reg = <0x0 0xfdd20000 0x0 0x1000>;
> +		rockchip,grf = <&grf>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +
> +		assigned-clocks =
> +			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
> +			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
> +			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
> +			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
> +			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
> +			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
> +			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
> +			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
> +			<&cru ACLK_VOP>;
> +		assigned-clock-rates =
> +			<32768>, <200000000>,
> +			<100000000>, <1000000000>,
> +			<1188000000>, <150000000>,
> +			<100000000>, <500000000>,
> +			<400000000>, <150000000>,
> +			<100000000>, <300000000>,
> +			<150000000>, <1200000000>,
> +			<400000000>, <100000000>,
> +			<500000000>;
> +		assigned-clock-parents =
> +			<&pmucru CLK_RTC32K_FRAC>;
> +	};
> +
> +	i2c0: i2c at fdd40000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfdd40000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	uart0: serial at fdd50000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfdd50000 0x0 0x100>;
> +		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 0>, <&dmac0 1>;
> +		pinctrl-0 = <&uart0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	pwm0: pwm at fdd70000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70000 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm0m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm1: pwm at fdd70010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70010 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm1m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm2: pwm at fdd70020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70020 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm2m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm3: pwm at fdd70030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70030 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm3_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	sdmmc2: dwmmc at fe000000 {

dwmmc at fe000000: $nodename:0: 'dwmmc at fe000000' does not match '^mmc(@.*)?$'

> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe000000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
> +			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC2>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +

> +	sdmmc0: dwmmc at fe2b0000 {

dwmmc at fe2b0000: $nodename:0: 'dwmmc at fe2b0000' does not match '^mmc(@.*)?$'

> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe2b0000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
> +			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC0>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +

> +	sdmmc1: dwmmc at fe2c0000 {

dwmmc at fe2c0000: $nodename:0: 'dwmmc at fe2c0000' does not match '^mmc(@.*)?$'

> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe2c0000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
> +			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC1>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +

> +	sdhci: sdhci at fe310000 {

sdhci at fe310000: $nodename:0: 'sdhci at fe310000' does not match '^mmc(@.*)?$'

> +		compatible = "rockchip,rk3568-dwcmshc";
> +		reg = <0x0 0xfe310000 0x0 0x10000>;
> +		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
> +		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
> +		assigned-clock-rates = <200000000>, <24000000>;
> +		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
> +			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
> +			 <&cru TCLK_EMMC>;
> +		clock-names = "core", "bus", "axi", "block", "timer";
> +		status = "disabled";
> +	};
> +
> +	dmac0: dmac at fe530000 {
> +		compatible = "arm,pl330", "arm,primecell";
> +		reg = <0x0 0xfe530000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,pl330-periph-burst;
> +		clocks = <&cru ACLK_BUS>;
> +		clock-names = "apb_pclk";
> +		#dma-cells = <1>;
> +	};
> +
> +	dmac1: dmac at fe550000 {
> +		compatible = "arm,pl330", "arm,primecell";
> +		reg = <0x0 0xfe550000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,pl330-periph-burst;
> +		clocks = <&cru ACLK_BUS>;
> +		clock-names = "apb_pclk";
> +		#dma-cells = <1>;
> +	};
> +
> +	i2c1: i2c at fe5a0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5a0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c1_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c2: i2c at fe5b0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5b0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c2m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c3: i2c at fe5c0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5c0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c3m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c4: i2c at fe5d0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5d0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c4m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c5: i2c at fe5e0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5e0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c5m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	wdt: watchdog at fe600000 {
> +		compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
> +		reg = <0x0 0xfe600000 0x0 0x100>;

> +		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
> +		clock-names = "tclk", "pclk";

below interrupts

> +		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;

> +	};
> +
> +	uart1: serial at fe650000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe650000 0x0 0x100>;
> +		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 2>, <&dmac0 3>;
> +		pinctrl-0 = <&uart1m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart2: serial at fe660000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe660000 0x0 0x100>;
> +		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 4>, <&dmac0 5>;
> +		pinctrl-0 = <&uart2m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart3: serial at fe670000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe670000 0x0 0x100>;
> +		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 6>, <&dmac0 7>;
> +		pinctrl-0 = <&uart3m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart4: serial at fe680000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe680000 0x0 0x100>;
> +		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 8>, <&dmac0 9>;
> +		pinctrl-0 = <&uart4m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart5: serial at fe690000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe690000 0x0 0x100>;
> +		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 10>, <&dmac0 11>;
> +		pinctrl-0 = <&uart5m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart6: serial at fe6a0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6a0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 12>, <&dmac0 13>;
> +		pinctrl-0 = <&uart6m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart7: serial at fe6b0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6b0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 14>, <&dmac0 15>;
> +		pinctrl-0 = <&uart7m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart8: serial at fe6c0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6c0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 16>, <&dmac0 17>;
> +		pinctrl-0 = <&uart8m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart9: serial at fe6d0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6d0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 18>, <&dmac0 19>;
> +		pinctrl-0 = <&uart9m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	pwm4: pwm at fe6e0000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm4_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm5: pwm at fe6e0010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm5_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm6: pwm at fe6e0020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm6_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm7: pwm at fe6e0030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm7_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm8: pwm at fe6f0000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm8m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm9: pwm at fe6f0010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm9m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm10: pwm at fe6f0020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm10m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm11: pwm at fe6f0030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm11m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm12: pwm at fe700000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm12m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm13: pwm at fe700010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm13m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm14: pwm at fe700020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm14m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm15: pwm at fe700030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm15m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pinctrl: pinctrl {
> +		compatible = "rockchip,rk3568-pinctrl";
> +		rockchip,grf = <&grf>;
> +		rockchip,pmu = <&pmugrf>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		gpio0: gpio at fdd60000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfdd60000 0x0 0x100>;
> +			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;

> +			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;

> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio1: gpio at fe740000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe740000 0x0 0x100>;
> +			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;

> +			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;

> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio2: gpio at fe750000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe750000 0x0 0x100>;
> +			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;

> +			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;

gpio at fe750000: clocks: [[13, 357], [13, 358]] is too long

Change rockchip,gpio-bank.yaml

  clocks:
    maxItems: 2

> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio3: gpio at fe760000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe760000 0x0 0x100>;
> +			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;

> +			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;

> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio4: gpio at fe770000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe770000 0x0 0x100>;
> +			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;

> +			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;

> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +	};
> +};
> +
> +#include "rk3568-pinctrl.dtsi"
> 


From thierry.reding at gmail.com  Mon Apr 26 13:19:06 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:19:06 +0200
Subject: [PATCH 06/10] memory: tegra: Parameterize interrupt handler
In-Reply-To: <aa5d7581-0cda-596f-8929-ba0dbd8155d1@canonical.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-7-thierry.reding@gmail.com>
 <aa5d7581-0cda-596f-8929-ba0dbd8155d1@canonical.com>
Message-ID: <YIavul2o2MCSVxLI@orome.fritz.box>

On Mon, Apr 26, 2021 at 11:01:00AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 18:52, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > Tegra20 requires a slightly different interrupt handler than Tegra30 and
> > later, so parameterize the handler, so that each SoC implementation can
> > provide its own.
> > 
> > While at it, also make IRQ support optional, which will help unify the
> > Tegra186 memory controller driver with this one.
> 
> Please split making it optional to separate patch. Looking at the code
> should be possible and not affect bisectability.

Technically that means I'd have to add a check for valid callback,
otherwise it'd risks oopsing if for whatever reason that's passed in as
NULL. It shouldn't be a problem in practice because it'll be valid in
all cases, at least until the unification patch, so perhaps there's no
need for the check if it's made optional in a subsequent patch anyway.

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/20210426/b2b0cfcd/attachment.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:20:58 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:20:58 +0200
Subject: [PATCH 05/10] memory: tegra: Extract setup code into callback
In-Reply-To: <25ea4721-f9d3-ae4e-6310-73182ad43d8f@canonical.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-6-thierry.reding@gmail.com>
 <25ea4721-f9d3-ae4e-6310-73182ad43d8f@canonical.com>
Message-ID: <YIawKoKFohRC2nfK@orome.fritz.box>

On Mon, Apr 26, 2021 at 10:58:27AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 18:52, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > Separate the setup code for Tegra30 and later into a ->setup() callback
> > and set it for all applicable chips.
> 
> I assume the code is functionally equivalent - the same
> tegra_mc_setup_latency_allowance() will be executed on all these SoCs?

Yes, that's what was previously the case and this holds true after the
patch. Really the only thing that this patch does is move that code into
a separate callback in tegra_mc_ops so that it can be changed for later
chips.

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/20210426/5b9ec799/attachment.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:21:49 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:21:49 +0200
Subject: [PATCH 04/10] memory: tegra: Make per-SoC setup more generic
In-Reply-To: <200ebdd4-bee0-caf3-e0b6-f4ba5e55b0e6@canonical.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-5-thierry.reding@gmail.com>
 <200ebdd4-bee0-caf3-e0b6-f4ba5e55b0e6@canonical.com>
Message-ID: <YIawXTrsClV1gRU8@orome.fritz.box>

On Mon, Apr 26, 2021 at 10:49:52AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 18:52, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > The current per-SoC setup code runs at a fairly arbitrary point during
> > probe, thereby making it less flexible for other SoC generations. Move
> > the call around slightly, which will allow it to be used for other
> > implementations.
> 
> You moved from one arbitrary point to another - please therefore explain
> the rationale of new arbitrary point a little bit more (e.g. after clock
> initialization? before HW access?) and put it next to struct tegra_mc_ops.

Okay, will do.

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/20210426/9045ae78/attachment.sig>

From thierry.reding at gmail.com  Mon Apr 26 13:24:46 2021
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 26 Apr 2021 14:24:46 +0200
Subject: [PATCH 03/10] memory: tegra: Push suspend/resume into SoC drivers
In-Reply-To: <d1626fd2-90e3-7a26-51b8-497a344aee6f@canonical.com>
References: <20210420165237.3523732-1-thierry.reding@gmail.com>
 <20210420165237.3523732-4-thierry.reding@gmail.com>
 <d1626fd2-90e3-7a26-51b8-497a344aee6f@canonical.com>
Message-ID: <YIaxDk39hjMJ6nxA@orome.fritz.box>

On Mon, Apr 26, 2021 at 10:47:11AM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2021 18:52, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > Continuing the scheme of unification, push suspend/resume callbacks into
> > per-SoC driver so that they can be properly parameterized.
> > 
> > While at it, also move the ->init() callback into the new tegra_mc_ops
> > structure to keep things clean.
> 
> Please split this part. This is just moving pointer from one structure
> to another, quite small change.
> 
> The rest of the patchset is quite different - you now call
> tegra_mc_suspend() from a per-SoC driver and move the code around.

Okay, I think I can split that off into a separate patch.

> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > ---
> >  drivers/memory/tegra/mc.c       | 24 ++++++++---------------
> >  drivers/memory/tegra/tegra186.c | 27 ++++++++++++++++++++++----
> >  drivers/memory/tegra/tegra20.c  | 34 ++++++++++++++++++++++++++++++++-
> >  include/soc/tegra/mc.h          |  9 +++++++--
> >  4 files changed, 71 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > index b7e104bf6614..2b21131d779c 100644
> > --- a/drivers/memory/tegra/mc.c
> > +++ b/drivers/memory/tegra/mc.c
> > @@ -829,8 +829,8 @@ static int tegra_mc_probe(struct platform_device *pdev)
> >  
> >  	mc->debugfs.root = debugfs_create_dir("mc", NULL);
> >  
> > -	if (mc->soc->init) {
> > -		err = mc->soc->init(mc);
> > +	if (mc->soc->ops && mc->soc->ops->init) {
> > +		err = mc->soc->ops->init(mc);
> >  		if (err < 0)
> >  			dev_err(&pdev->dev, "failed to initialize SoC driver: %d\n",
> >  				err);
> > @@ -867,30 +867,22 @@ static int tegra_mc_probe(struct platform_device *pdev)
> >  	return 0;
> >  }
> >  
> > -static int tegra_mc_suspend(struct device *dev)
> > +static int __maybe_unused tegra_mc_suspend(struct device *dev)
> >  {
> >  	struct tegra_mc *mc = dev_get_drvdata(dev);
> > -	int err;
> >  
> > -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> > -		err = tegra_gart_suspend(mc->gart);
> > -		if (err)
> > -			return err;
> > -	}
> > +	if (mc->soc->ops && mc->soc->ops->suspend)
> > +		return mc->soc->ops->suspend(mc);
> >  
> >  	return 0;
> >  }
> >  
> > -static int tegra_mc_resume(struct device *dev)
> > +static int __maybe_unused tegra_mc_resume(struct device *dev)
> >  {
> >  	struct tegra_mc *mc = dev_get_drvdata(dev);
> > -	int err;
> >  
> > -	if (IS_ENABLED(CONFIG_TEGRA_IOMMU_GART) && mc->gart) {
> > -		err = tegra_gart_resume(mc->gart);
> > -		if (err)
> > -			return err;
> > -	}
> > +	if (mc->soc->ops && mc->soc->ops->resume)
> > +		return mc->soc->ops->resume(mc);
> >  
> >  	return 0;
> >  }
> > diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> > index 8e77567d1378..9d3fdb609d55 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -45,6 +45,17 @@ static void tegra186_mc_program_sid(struct tegra_mc *mc)
> >  	}
> >  }
> >  
> > +static int tegra186_mc_resume(struct tegra_mc *mc)
> > +{
> > +	tegra186_mc_program_sid(mc);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct tegra_mc_ops tegra186_mc_ops = {
> > +	.resume = tegra186_mc_resume,
> > +};
> > +
> >  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
> >  static const struct tegra_mc_client tegra186_mc_clients[] = {
> >  	{
> > @@ -701,6 +712,7 @@ static const struct tegra_mc_client tegra186_mc_clients[] = {
> >  static const struct tegra_mc_soc tegra186_mc_soc = {
> >  	.num_clients = ARRAY_SIZE(tegra186_mc_clients),
> >  	.clients = tegra186_mc_clients,
> > +	.ops = &tegra186_mc_ops,
> >  };
> >  #endif
> >  
> > @@ -1909,6 +1921,7 @@ static const struct tegra_mc_client tegra194_mc_clients[] = {
> >  static const struct tegra_mc_soc tegra194_mc_soc = {
> >  	.num_clients = ARRAY_SIZE(tegra194_mc_clients),
> >  	.clients = tegra194_mc_clients,
> > +	.ops = &tegra186_mc_ops,
> >  };
> >  #endif
> >  
> > @@ -1961,22 +1974,28 @@ static const struct of_device_id tegra186_mc_of_match[] = {
> >  };
> >  MODULE_DEVICE_TABLE(of, tegra186_mc_of_match);
> >  
> > -static int __maybe_unused tegra186_mc_suspend(struct device *dev)
> > +static int __maybe_unused tegra_mc_suspend(struct device *dev)
> >  {
> > +	struct tegra_mc *mc = dev_get_drvdata(dev);
> > +
> > +	if (mc->soc->ops && mc->soc->ops->suspend)
> > +		return mc->soc->ops->suspend(mc);
> > +
> >  	return 0;
> >  }
> >  
> > -static int __maybe_unused tegra186_mc_resume(struct device *dev)
> > +static int __maybe_unused tegra_mc_resume(struct device *dev)
> >  {
> >  	struct tegra_mc *mc = dev_get_drvdata(dev);
> >  
> > -	tegra186_mc_program_sid(mc);
> > +	if (mc->soc->ops && mc->soc->ops->resume)
> > +		return mc->soc->ops->resume(mc);
> >  
> >  	return 0;
> >  }
> >  
> >  static const struct dev_pm_ops tegra186_mc_pm_ops = {
> > -	SET_SYSTEM_SLEEP_PM_OPS(tegra186_mc_suspend, tegra186_mc_resume)
> > +	SET_SYSTEM_SLEEP_PM_OPS(tegra_mc_suspend, tegra_mc_resume)
> 
> What's the benefit here? You basically define your own suspend-resume
> ops, on top of PM suspend-resume ops... Before it was quite obvious code
> - the Tegra186 MC driver had very simple suspend/resume which did simple
> job. Now it feels like trickier code to follow - Tegra186 driver calls
> it's resume (with the same name as others - another confusion) which is
> a simple wrapper calling somewhere else (need to jump to assinment of
> resume()).

This confusion is merely temporary. The idea here is to make the
Tegra186 driver the same as the "legacy" driver in this regard so that
the unification patch becomes just a removal of this code. If I didn't
first make this the same, I would've had to push this set of changes
into the unification patch, making it more difficult to understand.

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/20210426/daf09668/attachment-0001.sig>

From andre.przywara at arm.com  Mon Apr 26 13:35:46 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 26 Apr 2021 13:35:46 +0100
Subject: [boot-wrapper PATCH 5/5] aarch64: Introduce EL2 boot code for
 Armv8-R AArch64
In-Reply-To: <20210420072438.183086-6-jaxson.han@arm.com>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-6-jaxson.han@arm.com>
Message-ID: <20210426133546.65ee1ad6@slackpad.fritz.box>

On Tue, 20 Apr 2021 15:24:38 +0800
Jaxson Han <jaxson.han at arm.com> wrote:

Hi,

> The Armv8-R AArch64 profile does not support the EL3 exception level.
> The Armv8-R AArch64 profile allows for an (optional) VMSAv8-64 MMU
> at EL1, which allows to run off-the-shelf Linux. However EL2 only
> supports a PMSA, which is not supported by Linux, so we need to drop
> into EL1 before entering the kernel.
> 
> The boot sequence is:
> If CurrentEL == EL3, then goto EL3 initialisation and drop to lower EL
>   before entering the kernel.
> If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf (Armv8-R aarch64),
>   then goto Armv8-R AArch64 initialisation and drop to EL1 before
>   entering the kernel.
> Else, no initialisation and keep the current EL before entering the
>   kernel.
> 
> Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> ---
>  arch/aarch64/boot.S | 51 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> index f7dbf3f..6961a2a 100644
> --- a/arch/aarch64/boot.S
> +++ b/arch/aarch64/boot.S
> @@ -25,16 +25,22 @@ _start:
>  	 * Boot sequence
>  	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
>  	 *   lower EL before entering the kernel.
> +	 * If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf, then goto
> +	 *   Armv8-R AArch64 initialisation and drop to EL1 before
> +	 *   entering the kernel.
>  	 * Else, no initialisation and keep the current EL before
>  	 *   entering the kernel.
>  	 */
>  	mrs	x0, CurrentEL
>  	cmp	x0, #CURRENTEL_EL3
>  	beq	el3_init
> +	cmp	x0, #CURRENTEL_EL2
> +	beq	el2_init

nitpick: I tend to compare against EL2, then use b.gt for EL3, b.lt for
EL1 and b.eq for EL2 code. Saves you an extra cmp here.

>  	/*
>  	 * We stay in the current EL for entering the kernel
>  	 */
> +keep_el:
>  	mov	w0, #1
>  	ldr	x1, =flag_keep_el
>  	str	w0, [x1]
> @@ -112,6 +118,43 @@ el3_init:
>  	str	w0, [x1]
>  	b	el_max_init
>  
> +	/*
> +	 * EL2 Armv8-R AArch64 initialisation
> +	 */
> +el2_init:
> +	/* Detect Armv8-R AArch64 */
> +	mrs	x1, id_aa64mmfr0_el1
> +	ubfx	x1, x1, #48, #4			// MSA
> +	/* 0xf means Armv8-R AArch64 */
> +	cmp	x1, 0xf
> +	bne	keep_el

Don't we need to also check bits[55:52], to have at least 0b0010?
IIUC the support for VMSA in EL1&0 is optional, and should be checked
before we proceed? VTCR_EL2[31] can only be set in the 0b0010 case.

> +
> +	mrs	x0, midr_el1
> +	msr	vpidr_el2, x0
> +
> +	mrs	x0, mpidr_el1
> +	msr	vmpidr_el2, x0
> +
> +	mov	x0, #(1 << 31)			// VTCR_MSA: VMSAv8-64 support
> +	msr	vtcr_el2, x0
> +
> +	/* Enable pointer authentication if present */
> +	mrs	x1, id_aa64isar1_el1
> +	ldr	x2, =(((0xff) << 24) | (0xff << 4))

Each feature only holds four bits, so the mask you shift should be 0xf.

> +	and	x1, x1, x2
> +	cbz	x1, 1f
> +
> +	mrs	x0, hcr_el2

Shouldn't we force HCR_EL2, instead of modifying it? Just to make sure
nothing unexpected traps into EL2, which we don't handle very well?
So basically just set bit 31 (RES1), plus those two bits on top, if
needed. But I also wonder about FIEN[47] and EnSCXT[53] ...


Rest looks alright.

Cheers,
Andre

> +	orr	x0, x0, #(1 << 40)		// AP key enable
> +	orr	x0, x0, #(1 << 41)		// AP insn enable
> +	msr	hcr_el2, x0
> +
> +1:	isb
> +	mov	w0, #SPSR_KERNEL_EL1
> +	ldr	x1, =spsr_to_elx
> +	str	w0, [x1]
> +	b	el_max_init
> +
>  el_max_init:
>  	ldr	x0, =CNTFRQ
>  	msr	cntfrq_el0, x0
> @@ -169,10 +212,18 @@ jump_kernel:
>  	 */
>  	bfi	x4, x19, #5, #1
>  
> +	mrs	x5, CurrentEL
> +	cmp	x5, #CURRENTEL_EL2
> +	b.eq	1f
> +
>  	msr	elr_el3, x19
>  	msr	spsr_el3, x4
>  	eret
>  
> +1:	msr	elr_el2, x19
> +	msr	spsr_el2, x4
> +	eret
> +
>  	.ltorg
>  
>  	.data



From mlevitsk at redhat.com  Mon Apr 26 13:43:48 2021
From: mlevitsk at redhat.com (Maxim Levitsky)
Date: Mon, 26 Apr 2021 15:43:48 +0300
Subject: [PATCH v2 0/9] KVM: my debug patch queue
In-Reply-To: <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
 <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>
Message-ID: <6d7146021f3435330b42f2e1b917d4b5dea00edc.camel@redhat.com>

On Fri, 2021-04-02 at 10:38 -0700, Paolo Bonzini wrote:
> On 01/04/21 15:54, Maxim Levitsky wrote:
> > Hi!
> > 
> > I would like to publish two debug features which were needed for other stuff
> > I work on.
> > 
> > One is the reworked lx-symbols script which now actually works on at least
> > gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
> > for some reason, not related to this patch) and upstream qemu.
> 
> Queued patches 2-5 for now.  6 is okay but it needs a selftest. (e.g. 
> using KVM_VCPU_SET_EVENTS) and the correct name for the constant.
Do you mean to add a kvm-unit-test or to add a test to kernel's kvm unit tests
for this?

Best regards,
	Maxim Levitsky

> 
> Paolo
> 
> > The other feature is the ability to trap all guest exceptions (on SVM for now)
> > and see them in kvmtrace prior to potential merge to double/triple fault.
> > 
> > This can be very useful and I already had to manually patch KVM a few
> > times for this.
> > I will, once time permits, implement this feature on Intel as well.
> > 
> > V2:
> > 
> >   * Some more refactoring and workarounds for lx-symbols script
> > 
> >   * added KVM_GUESTDBG_BLOCKEVENTS flag to enable 'block interrupts on
> >     single step' together with KVM_CAP_SET_GUEST_DEBUG2 capability
> >     to indicate which guest debug flags are supported.
> > 
> >     This is a replacement for unconditional block of interrupts on single
> >     step that was done in previous version of this patch set.
> >     Patches to qemu to use that feature will be sent soon.
> > 
> >   * Reworked the the 'intercept all exceptions for debug' feature according
> >     to the review feedback:
> > 
> >     - renamed the parameter that enables the feature and
> >       moved it to common kvm module.
> >       (only SVM part is currently implemented though)
> > 
> >     - disable the feature for SEV guests as was suggested during the review
> >     - made the vmexit table const again, as was suggested in the review as well.
> > 
> > Best regards,
> > 	Maxim Levitsky
> > 
> > Maxim Levitsky (9):
> >    scripts/gdb: rework lx-symbols gdb script
> >    KVM: introduce KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: x86: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: aarch64: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: s390x: implement KVM_CAP_SET_GUEST_DEBUG2
> >    KVM: x86: implement KVM_GUESTDBG_BLOCKEVENTS
> >    KVM: SVM: split svm_handle_invalid_exit
> >    KVM: x86: add force_intercept_exceptions_mask
> >    KVM: SVM: implement force_intercept_exceptions_mask
> > 
> >   Documentation/virt/kvm/api.rst    |   4 +
> >   arch/arm64/include/asm/kvm_host.h |   4 +
> >   arch/arm64/kvm/arm.c              |   2 +
> >   arch/arm64/kvm/guest.c            |   5 -
> >   arch/s390/include/asm/kvm_host.h  |   4 +
> >   arch/s390/kvm/kvm-s390.c          |   3 +
> >   arch/x86/include/asm/kvm_host.h   |  12 ++
> >   arch/x86/include/uapi/asm/kvm.h   |   1 +
> >   arch/x86/kvm/svm/svm.c            |  87 +++++++++++--
> >   arch/x86/kvm/svm/svm.h            |   6 +-
> >   arch/x86/kvm/x86.c                |  14 ++-
> >   arch/x86/kvm/x86.h                |   2 +
> >   include/uapi/linux/kvm.h          |   1 +
> >   kernel/module.c                   |   8 +-
> >   scripts/gdb/linux/symbols.py      | 203 ++++++++++++++++++++----------
> >   15 files changed, 272 insertions(+), 84 deletions(-)
> > 




From pbonzini at redhat.com  Mon Apr 26 13:55:25 2021
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Mon, 26 Apr 2021 14:55:25 +0200
Subject: [PATCH v2 0/9] KVM: my debug patch queue
In-Reply-To: <6d7146021f3435330b42f2e1b917d4b5dea00edc.camel@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
 <cb7f918c-932f-d558-76ec-801ed8ed1f62@redhat.com>
 <6d7146021f3435330b42f2e1b917d4b5dea00edc.camel@redhat.com>
Message-ID: <afba4cd8-72d3-ae18-df22-92be3b8eb321@redhat.com>

On 26/04/21 14:43, Maxim Levitsky wrote:
> On Fri, 2021-04-02 at 10:38 -0700, Paolo Bonzini wrote:
>> On 01/04/21 15:54, Maxim Levitsky wrote:
>>> Hi!
>>>
>>> I would like to publish two debug features which were needed for other stuff
>>> I work on.
>>>
>>> One is the reworked lx-symbols script which now actually works on at least
>>> gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
>>> for some reason, not related to this patch) and upstream qemu.
>>
>> Queued patches 2-5 for now.  6 is okay but it needs a selftest. (e.g.
>> using KVM_VCPU_SET_EVENTS) and the correct name for the constant.
> Do you mean to add a kvm-unit-test or to add a test to kernel's kvm unit tests
> for this?

selftests is used for those in the kernel.  "Unit test" can mean both, 
but usually it means kvm-unit-tests because they're easier to write.

Paolo



From tsbogend at alpha.franken.de  Mon Apr 26 14:00:05 2021
From: tsbogend at alpha.franken.de (Thomas Bogendoerfer)
Date: Mon, 26 Apr 2021 15:00:05 +0200
Subject: [PATCH] MIPS: BCM63XX: Use BUG_ON instead of condition followed
 by BUG.
In-Reply-To: <1619279992-81335-1-git-send-email-zhouchuangao@vivo.com>
References: <1619279992-81335-1-git-send-email-zhouchuangao@vivo.com>
Message-ID: <20210426130005.GA9176@alpha.franken.de>

On Sat, Apr 24, 2021 at 08:59:50AM -0700, zhouchuangao wrote:
> BUG_ON uses unlikely in if(), it can be optimized at compile time.
> 
> Usually, the condition in if() is not satisfied. In my opinion,
> this can improve the efficiency of the multi-stage pipeline.
> 
> Signed-off-by: zhouchuangao <zhouchuangao at vivo.com>
> ---
>  arch/mips/bcm63xx/gpio.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]


From morten.rasmussen at arm.com  Mon Apr 26 14:11:50 2021
From: morten.rasmussen at arm.com (Morten Rasmussen)
Date: Mon, 26 Apr 2021 15:11:50 +0200
Subject: [RFC PATCH 0/4] Support for passing runtime state idle time to
 TF-A
In-Reply-To: <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com>
References: <1619123448-10138-1-git-send-email-skomatineni@nvidia.com>
 <064341f7-dce3-5ad4-e69b-9568115035c1@arm.com>
 <486856be-1e66-fd77-e306-949b91bcdb1d@nvidia.com>
Message-ID: <20210426131150.GA36549@e123083-lin>

Hi,

On Fri, Apr 23, 2021 at 03:24:51PM -0700, Sowjanya Komatineni wrote:
> On 4/23/21 1:16 PM, Lukasz Luba wrote:
> > Hi Sowjanya,
> > 
> > On 4/22/21 9:30 PM, Sowjanya Komatineni wrote:
> > > Tegra194 and Tegra186 platforms use separate MCE firmware for CPUs
> > > which is
> > > in charge of deciding on state transition based on target state,
> > > state idle
> > > time, and some other Tegra CPU core cluster states information.
> > > 
> > > Current PSCI specification don't have function defined for passing
> > > runtime
> > > state idle time predicted by governor (based on next events and
> > > state target
> > > residency) to ARM trusted firmware.
> > 
> > Do you have some numbers from experiments showing that these idle
> > governor prediction values, which are passed from kernel to MCE
> > firmware, are making a good 'guess'?
> > How much precision (1us? 1ms?) in the values do you need there?
> 
> it could also be in few ms depending on when next cpu event/activity might
> happen which is not transparent to MCE firmware.
> 
> > 
> > IIRC (probably Rafael's presentations) predicting in the kernel
> > something like CPU idle time residency is not a trivial thing.
> > 
> > Another idea (depending on DT structure and PSCI bits):
> > Could this be solved differently, but just having a knowledge that if
> > the governor requested some C-state, this means governor 'predicted'
> > an idle residency to be greater that min_residency attached to this
> > C-state?
> > Then, when that request shows up in your FW, you know that it must be at
> > least min_residency because of this C-state id.
> C6 is the only deepest state for Tegra194 Carmel CPU that we support in
> addition to C1 (WFI) idle state.
> 
> MCE firmware gets state crossover thresholds for C1 to C6 transition from
> TF-A and uses it along with state idle time to decide on C6 state entry
> based on its background work.
> 
> Assuming for now if we use min_residency as state idle time which is static
> value from DT, then it enters into deepest state C6 always as we use
> min_residency value we use is always higher than state crossover threshold.
> 
> But MCE firmware is not aware of when next cpu event can happen to predict
> if next event can take longer than state min_residency time.
> 
> Using min residency in such case is very conservative where MCE firmware
> exits C6 state early where we may not have better power saving.
> 
> But with MCE firmware being aware of when next event can happen it can use
> that to stay in C6 state without early exit for better power savings.
> 
> > It would depend on number of available states, max_residency, scale
> > that you would choose while assigning values from [0, max_residency]
> > to each state.
> > IIRC there can be many state IDs for idle, so it would depend on
> > number of bits encoding this state, and your needs. Example of
> > linear scale:
> > 4-bits encoding idle state and max predicted residency 10msec,
> > that means 10000us / 16 states = 625us/state.
> > The max_residency might be split differently, using different than
> > linear function, to have some rage more precised.
> > 
> > Open question is if these idle states must be all represented
> > in DT, or there is a way of describing a 'set of idle states'
> > automatically.
> We only support C6 state through DT as C6 is the only deepest state for
> Tegra194 carmel CPU. WFI idle state is completely handled by kernel and does
> not require MCE sequences for entry/exit.

I think Lukasz's point is that you can encode the predicted idle time by
having multiple idle_state entries with different min_residency mapping
to the same actual idle-state. So you would several variants of C6 with
different min_residencies and if the OS picks one with longer
min_residency firmware would have a better estimate of the predicted
idle residency.

I'm not convinced it is the right way to work around passing this
information on to firmware. I would rather see an example of how well
this works (best with numbers) and have a proper solution.

Morten


From mchehab+huawei at kernel.org  Mon Apr 26 14:12:24 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Mon, 26 Apr 2021 15:12:24 +0200
Subject: [PATCH 57/78] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <45068e81-8f9b-fea8-b7bc-bdd0443ba7e6@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <091915bb1cbec13b566d129f85ae229fcb92e2e4.1619191723.git.mchehab+huawei@kernel.org>
 <45068e81-8f9b-fea8-b7bc-bdd0443ba7e6@kernel.org>
Message-ID: <20210426151224.2b677d1b@coco.lan>

Em Sun, 25 Apr 2021 22:57:25 +0200
Sylwester Nawrocki <snawrocki at kernel.org> escreveu:

> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
> > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> > added pm_runtime_resume_and_get() in order to automatically handle
> > dev->power.usage_count decrement on errors.
> > 
> > Use the new API, in order to cleanup the error check logic.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> > ---
> >   drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
> >   drivers/media/platform/exynos4-is/fimc-is.c        | 3 ++-
> >   drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
> >   drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
> >   drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
> >   drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
> >   drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
> >   drivers/media/platform/exynos4-is/mipi-csis.c      | 5 ++---
> >   8 files changed, 17 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
> > index 13c838d3f947..0da36443173c 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> > @@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
> >   		goto unlock;
> >   
> >   	set_bit(ST_CAPT_BUSY, &fimc->state);
> > -	ret = pm_runtime_get_sync(&fimc->pdev->dev);
> > -	if (ret < 0) {
> > -		pm_runtime_put_sync(&fimc->pdev->dev);
> > +	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
> > +	if (ret < 0)
> >   		goto unlock;
> > -	}
> >   
> >   	ret = v4l2_fh_open(file);
> >   	if (ret) {
> > diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
> > index 972d9601d236..bca35866cc74 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-is.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-is.c
> > @@ -828,7 +828,7 @@ static int fimc_is_probe(struct platform_device *pdev)
> >   			goto err_irq;
> >   	}
> >   
> > -	ret = pm_runtime_get_sync(dev);
> > +	ret = pm_runtime_resume_and_get(dev);
> >   	if (ret < 0)
> >   		goto err_pm;  
> 
> It seems you intended to use err_suspend label here. We don't need
> a new label though, instead of err_pm we can jump to err_irq when
> pm_runtime_resume_and_get() fails. 

Thanks! Will fix at the next version.

> Note that when runtime PM is
> disabled pm_runtime_resume_and_get() always returns 0.

Ok, but there are a couple of conditions at rpm_resume() function
at drivers/base/power/runtime.c (which is the code that actually
handles those PM macros) that could make it to return errors,
which are independent on the PM callbacks, like those:

        if (dev->power.runtime_error)
                retval = -EINVAL;
        else if (dev->power.disable_depth > 0)
                retval = -EACCES;

and more might be added as the PM core changes.

> 
> > @@ -862,6 +862,7 @@ static int fimc_is_probe(struct platform_device *pdev)
> >   	fimc_is_unregister_subdevs(is);
> >   err_pm:
> >   	pm_runtime_put_noidle(dev);
> > +err_suspend:
> >   	if (!pm_runtime_enabled(dev))
> >   		fimc_is_runtime_suspend(dev);
> >   err_irq:  
> 
> 
> > diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
> > index 1aac167abb17..a0218237d66b 100644
> > --- a/drivers/media/platform/exynos4-is/mipi-csis.c
> > +++ b/drivers/media/platform/exynos4-is/mipi-csis.c
> > @@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
> >   	struct device *dev = &state->pdev->dev;
> >   
> >   	if (on)
> > -		return pm_runtime_get_sync(dev);
> > +		return pm_runtime_resume_and_get(dev);
> >   
> >   	return pm_runtime_put_sync(dev);
> >   }
> > @@ -509,9 +509,8 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
> >   
> >   	if (enable) {
> >   		s5pcsis_clear_counters(state);
> > -		ret = pm_runtime_get_sync(&state->pdev->dev);
> > +		ret = pm_runtime_resume_and_get(&state->pdev->dev);
> >   		if (ret && ret != 1) {
> > -			pm_runtime_put_noidle(&state->pdev->dev);
> >   			return ret;
> >   		}  
> 
> Braces could be dropped as well here.

OK.

> 
> >   	}  
> 
> 
> Thanks,
> Sylwester
> 



Thanks,
Mauro


From tiantao6 at hisilicon.com  Mon Apr 26 14:18:55 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Mon, 26 Apr 2021 21:18:55 +0800
Subject: [PATCH v2] tty: serial: samsung_tty: remove set but not used variables
Message-ID: <1619443135-21399-1-git-send-email-tiantao6@hisilicon.com>

The value of 'ret' is not used which reported by svace, so jutst return
instead of break.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
---
v2: s3c24xx_serial_probe function exit than convert ret to some default
value when the attribute "reg-io-width" is not 1 or 4.
---
 drivers/tty/serial/samsung_tty.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index d9e4b67..9fbc611 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2220,8 +2220,7 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
 			default:
 				dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
 						prop);
-				ret = -EINVAL;
-				break;
+				return -EINVAL;
 			}
 		}
 	}
-- 
2.7.4



From lakshmis at xilinx.com  Mon Apr 26 14:20:54 2021
From: lakshmis at xilinx.com (Sai Krishna Potthuri)
Date: Mon, 26 Apr 2021 13:20:54 +0000
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
Message-ID: <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>

Hi Andy Shevchenko,

Thanks for the review.

> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko at gmail.com>
> Sent: Friday, April 23, 2021 9:24 PM
> To: Sai Krishna Potthuri <lakshmis at xilinx.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>; Rob Herring
> <robh+dt at kernel.org>; Michal Simek <michals at xilinx.com>; Greg Kroah-
> Hartman <gregkh at linuxfoundation.org>; linux-arm Mailing List <linux-arm-
> kernel at lists.infradead.org>; Linux Kernel Mailing List <linux-
> kernel at vger.kernel.org>; devicetree <devicetree at vger.kernel.org>; open
> list:GPIO SUBSYSTEM <linux-gpio at vger.kernel.org>; git <git at xilinx.com>;
> saikrishna12468 at gmail.com
> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> >
> > Adding pinctrl driver for Xilinx ZynqMP platform.
> > This driver queries pin information from firmware and registers pin
> > control accordingly.
> >
> > Signed-off-by: Sai Krishna Potthuri
> > <lakshmi.sai.krishna.potthuri at xilinx.com>
> 
> You may reduce the number of LOCs by joining some lines. See below.
> 
> ...
> 
> > +config PINCTRL_ZYNQMP
> > +       tristate "Pinctrl driver for Xilinx ZynqMP"
> > +       depends on ZYNQMP_FIRMWARE
> > +       select PINMUX
> > +       select GENERIC_PINCONF
> > +       default ZYNQMP_FIRMWARE
> > +       help
> > +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> > +         This driver will query the pin information from the firmware
> > +         and allow configuring the pins.
> > +         Configuration can include the mux function to select on those
> > +         pin(s)/group(s), and various pin configuration parameters
> > +         such as pull-up, slew rate, etc.
> 
> Missed module name.
Is this (module name) a configuration option in Kconfig?
> 
> ...
> 
> > +/*
> > + * ZynqMP pin controller
> > + *
> > + * Copyright (C) 2020 Xilinx, Inc.
> 
> 2021?
Couple of versions for this patch series sent in 2020, hence maintaining
the same.
Is it like we maintain the year when this patch series is applied, which is
2021?
> 
> > + *
> > + * Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri at xilinx.com>
> > + * Rajan Vaja <rajan.vaja at xilinx.com> */
> 
> ...
> 
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/firmware/xlnx-zynqmp.h>
> 
> ...
> 
> > +static int zynqmp_pinconf_cfg_get(struct pinctrl_dev *pctldev,
> > +                                 unsigned int pin,
> > +                                 unsigned long *config)
> > +{
> > +       unsigned int arg, param = pinconf_to_config_param(*config);
> > +       int ret;
> 
> > +       if (pin >= zynqmp_desc.npins)
> > +               return -EOPNOTSUPP;
> 
> Is it possible?
This is a safe check.
Pin information will get from dt files/Xilinx firmware (query pin information
for a group)/user application and there are chances of getting wrong pin.
> 
> > +       switch (param) {
> > +       case PIN_CONFIG_SLEW_RATE:
> > +               param = PM_PINCTRL_CONFIG_SLEW_RATE;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_BIAS_PULL_UP:
> > +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> 
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               if (arg != PM_PINCTRL_BIAS_PULL_UP)
> > +                       return -EINVAL;
> 
> Error code being shadowed. Instead check it here properly.
Are you mentioning the case where ret is also a non-zero?
If yes, then I will update this check to 
if (!ret && arg != PM_PINCTRL_BIAS_PULL_UP)
	return -EINVAL;
ret non-zero case, we are handling at the end of switch case.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_BIAS_PULL_DOWN:
> > +               param = PM_PINCTRL_CONFIG_PULL_CTRL;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               if (arg != PM_PINCTRL_BIAS_PULL_DOWN)
> > +                       return -EINVAL;
> 
> Ditto.
Same as above.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_BIAS_DISABLE:
> > +               param = PM_PINCTRL_CONFIG_BIAS_STATUS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               if (arg != PM_PINCTRL_BIAS_DISABLE)
> > +                       return -EINVAL;
> 
> Ditto.
Same as above.
> 
> > +               arg = 1;
> > +               break;
> > +       case PIN_CONFIG_POWER_SOURCE:
> > +               param = PM_PINCTRL_CONFIG_VOLTAGE_STATUS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> > +               param = PM_PINCTRL_CONFIG_SCHMITT_CMOS;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               break;
> > +       case PIN_CONFIG_DRIVE_STRENGTH:
> > +               param = PM_PINCTRL_CONFIG_DRIVE_STRENGTH;
> > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > +               switch (arg) {
> > +               case PM_PINCTRL_DRIVE_STRENGTH_2MA:
> > +                       arg = DRIVE_STRENGTH_2MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_4MA:
> > +                       arg = DRIVE_STRENGTH_4MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_8MA:
> > +                       arg = DRIVE_STRENGTH_8MA;
> > +                       break;
> > +               case PM_PINCTRL_DRIVE_STRENGTH_12MA:
> > +                       arg = DRIVE_STRENGTH_12MA;
> > +                       break;
> > +               default:
> > +                       /* Invalid drive strength */
> > +                       dev_warn(pctldev->dev,
> > +                                "Invalid drive strength for pin %d\n",
> > +                                pin);
> > +                       return -EINVAL;
> > +               }
> > +               break;
> > +       default:
> > +               ret = -EOPNOTSUPP;
> > +               break;
> > +       }
> > +
> > +       if (ret)
> > +               return ret;
> > +
> > +       param = pinconf_to_config_param(*config);
> > +       *config = pinconf_to_config_packed(param, arg);
> > +
> > +       return 0;
> > +}
> 
> ...
> 
> > +                       ret = -EOPNOTSUPP;
> 
> Isn't it ENOTSUP for all cases here?
Giving 'Operation Not Supported (EOPNOTSUPP)' error, when
driver gets a request for unsupported pin or configuration.
Can you please elaborate your question if I didn't answer properly.
> 
> ...
> 
> > +       ret = zynqmp_pm_query_data(qdata, payload);
> > +       if (ret)
> > +               return ret;
> > +
> > +       *ngroups = payload[1];
> > +
> 
> > +       return ret;
> 
> return 0;
I will fix.
> 
> ...
> 
> > + * Query firmware to get group IDs for each function. Firmware returns
> > + * group IDs. Based on group index for the function, group names in
> 
> on the group
> 
> > + * the function are stored. For example, the first group in "eth0" function
> > + * is named as "eth0_0" and second group as "eth0_1" and so on.
> 
> and the second
> 
> > + *
> > + * Based on the group ID received from the firmware, function stores
> name of
> > + * the group for that group ID. For example, if "eth0" first group ID
> > + * is x, groups[x] name will be stored as "eth0_0".
> > + *
> > + * Once done for each function, each function would have its group names
> > + * and each groups would also have their names.
> 
> each group
I will fix all the above.
> 
> ...
> 
> > +done:
> > +       func->groups = fgroups;
> > +
> > +       return ret;
> 
> return 0; ?
> 
> ...
> 
> > +       *nfuncs = payload[1];
> > +
> > +       return ret;
> 
> Ditto.
> 
> ...
> 
> > +       ret = zynqmp_pm_query_data(qdata, payload);
> > +       if (ret)
> > +               return ret;
> > +
> > +       memcpy(groups, &payload[1],
> PINCTRL_GET_PIN_GROUPS_RESP_LEN);
> > +
> > +       return ret;
> 
> Ditto.
> 
> ...
> 
> > + * Query firmware to get groups available for the given pin.
> > + * Based on the firmware response(group IDs for the pin), add
> > + * pin number to the respective group's pin array.
> > + *
> > + * Once all pins are queries, each groups would have its number
> 
> each group
> 
> > + * of pins and pin numbers data.
> 
> ...
> 
> > +       return ret;
> 
> return 0;
> 
> ...
> 
> > + * Query number of functions and number of function groups (number
> > + * of groups in given function) to allocate required memory buffers
> 
> in the given
> 
> > + * for functions and groups. Once buffers are allocated to store
> > + * functions and groups data, query and store required information
> > + * (number of groups and group names for each function, number of
> > + * pins and pin numbers for each group).
> 
> ...
> 
> > +       pctrl->funcs = funcs;
> > +       pctrl->groups = groups;
> > +
> > +       return ret;
> 
> return 0;
> 
> ...
> 
> > +       *npins = payload[1];
> > +
> > +       return ret;
> 
> Ditto.
I will fix all the above similar comments.
> 
> ...
> 
> > +               dev_err(&pdev->dev, "pin desc prepare fail with %d\n",
> > +                       ret);
> 
> One line.
> 
> ...
> 
> > +               dev_err(&pdev->dev, "function info prepare fail with %d\n",
> > +                       ret);
> 
> Ditto.
I will fix all.
> 
> ...
> 
> > +       pctrl->pctrl = pinctrl_register(&zynqmp_desc, &pdev->dev, pctrl);
> 
> devm_pinctrl_register()
I will update.
> 
> > +       if (IS_ERR(pctrl->pctrl))
> > +               return PTR_ERR(pctrl->pctrl);
> 
> ...
> 
> > +};
> 
> > +
> 
> Extra blank line.
> 
> > +MODULE_DEVICE_TABLE(of, zynqmp_pinctrl_of_match);
> 
> ...
> 
> > +};
> 
> > +
> 
> Ditto.
I see some drivers are maintaining the extra line in above two cases.
We shouldn't maintain extra line after struct declaration?

Regards
Sai Krishna
> 
> > +module_platform_driver(zynqmp_pinctrl_driver);
> 
> --
> With Best Regards,
> Andy Shevchenko

From yuzenghui at huawei.com  Mon Apr 26 14:39:04 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Mon, 26 Apr 2021 21:39:04 +0800
Subject: [PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel
 transitions
In-Reply-To: <20210426092139.GA16287@C02TD0UTHF1T.local>
References: <20201130115950.22492-1-mark.rutland@arm.com>
 <20201130115950.22492-10-mark.rutland@arm.com>
 <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>
 <20210426092139.GA16287@C02TD0UTHF1T.local>
Message-ID: <0e1143a5-8e1a-c04e-e4fd-5c57f8354f61@huawei.com>

Hi Mark,

On 2021/4/26 17:21, Mark Rutland wrote:
> On Sun, Apr 25, 2021 at 01:29:31PM +0800, Zenghui Yu wrote:
>> Hi Mark,
> 
> Hi Zenghui,

[...]

>> Booting a lockdep-enabled kernel with "irqchip.gicv3_pseudo_nmi=1" would
>> result in splats as below:
>>
>> | DEBUG_LOCKS_WARN_ON(!irqs_disabled())
>> | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258
>> lockdep_hardirqs_off+0xd4/0xe8
>> | Modules linked in:
>> | CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+
>> #463
>> | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
>> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
>> | pc : lockdep_hardirqs_off+0xd4/0xe8
>> | lr : lockdep_hardirqs_off+0xd4/0xe8
>> | sp : ffff80002a39bad0
>> | pmr_save: 000000e0
>> | x29: ffff80002a39bad0 x28: ffff0000de214bc0
>> | x27: ffff0000de1c0400 x26: 000000000049b328
>> | x25: 0000000000406f30 x24: ffff0000de1c00a0
>> | x23: 0000000020400005 x22: ffff8000105f747c
>> | x21: 0000000096000044 x20: 0000000000498ef9
>> | x19: ffff80002a39bc88 x18: ffffffffffffffff
>> | x17: 0000000000000000 x16: ffff800011c61eb0
>> | x15: ffff800011700a88 x14: 0720072007200720
>> | x13: 0720072007200720 x12: 0720072007200720
>> | x11: 0720072007200720 x10: 0720072007200720
>> | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
>> | x7 : ffff8000119f0800 x6 : c0000000ffff7fff
>> | x5 : ffff8000119f07a8 x4 : 0000000000000001
>> | x3 : 9bcdab23f2432800 x2 : ffff800011730538
>> | x1 : 9bcdab23f2432800 x0 : 0000000000000000
>> | Call trace:
>> |  lockdep_hardirqs_off+0xd4/0xe8
>> |  enter_from_kernel_mode.isra.5+0x7c/0xa8
>> |  el1_abort+0x24/0x100
>> |  el1_sync_handler+0x80/0xd0
>> |  el1_sync+0x6c/0x100
>> |  __arch_clear_user+0xc/0x90
>> |  load_elf_binary+0x9fc/0x1450
>> |  bprm_execve+0x404/0x880
>> |  kernel_execve+0x180/0x188
>> |  call_usermodehelper_exec_async+0xdc/0x158
>> |  ret_from_fork+0x10/0x18
>>
>> The code that triggers the splat is lockdep_hardirqs_off+0xd4/0xe8:
>>
>> |	/*
>> |	 * So we're supposed to get called after you mask local IRQs, but for
>> |	 * some reason the hardware doesn't quite think you did a proper job.
>> |	 */
>> |	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
>> |		return;
>>
>> which looks like a false positive as DAIF are all masked on taking
>> an synchronous exception and hardirqs are therefore disabled. With
>> pseudo NMI used, irqs_disabled() takes the value of ICC_PMR_EL1 as
>> the interrupt enable state, which is GIC_PRIO_IRQON (0xe0) in this
>> case and doesn't help much. Not dig further though.
> 
> Thanks for this report. I think I understand the problem.
> 
> In some paths (e.g. el1_dbg, el0_svc) we update the PMR with
> (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) before we notify lockdep, but in
> others (e.g. el1_abort) we do not. The case where we do not are where
> lockdep will warn, since IRQs will be masked by DAIF but not the PMR, as
> you describe above.
> 
> With the current PMR management scheme, we'll need to consistently
> update the PMR earlier in the entry code. Does the below diff help?

[...]

> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 6acfc5e6b5e0..7d46c74a8706 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -292,6 +292,8 @@ alternative_else_nop_endif
>  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
>  	mrs_s	x20, SYS_ICC_PMR_EL1
>  	str	x20, [sp, #S_PMR_SAVE]
> +	orr	x20, x20, #GIC_PRIO_PSR_I_SET
> +	msr_s	SYS_ICC_PMR_EL1, x20
>  alternative_else_nop_endif

While this does fix the lockdep part, it breaks something else. The
sleep-in-atomic one stands out (which says, I've seen other splats
triggered with this diff), where irqs_disabled() in do_mem_abort() now
gets confused by the updated PMR (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET).

Please have a look.


Thanks,
Zenghui

| BUG: sleeping function called from invalid context at 
arch/arm64/mm/fault.c:582
| in_atomic(): 0, irqs_disabled(): 16, non_block: 0, pid: 512, name: sh
| CPU: 2 PID: 512 Comm: sh Tainted: G S      W         5.12.0+
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| Call trace:
|  dump_backtrace+0x0/0x210
|  show_stack+0x2c/0x38
|  dump_stack+0x150/0x1c4
|  ___might_sleep+0x154/0x250
|  __might_sleep+0x58/0x90
|  do_page_fault+0x24c/0x498
|  do_mem_abort+0x50/0xc0
|  el1_abort+0x50/0x100
|  el1_sync_handler+0x80/0xd0
|  el1_sync+0x74/0x100
|  schedule_tail+0xa0/0xd0
|  ret_from_fork+0x4/0x18


From andy.shevchenko at gmail.com  Mon Apr 26 15:04:42 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 26 Apr 2021 17:04:42 +0300
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
Message-ID: <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>

On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
<lakshmis at xilinx.com> wrote:
> > From: Andy Shevchenko <andy.shevchenko at gmail.com>
> > Sent: Friday, April 23, 2021 9:24 PM
> > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> > <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:

...

> > > +config PINCTRL_ZYNQMP
> > > +       tristate "Pinctrl driver for Xilinx ZynqMP"
> > > +       depends on ZYNQMP_FIRMWARE
> > > +       select PINMUX
> > > +       select GENERIC_PINCONF
> > > +       default ZYNQMP_FIRMWARE
> > > +       help
> > > +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> > > +         This driver will query the pin information from the firmware
> > > +         and allow configuring the pins.
> > > +         Configuration can include the mux function to select on those
> > > +         pin(s)/group(s), and various pin configuration parameters
> > > +         such as pull-up, slew rate, etc.
> >
> > Missed module name.
> Is this (module name) a configuration option in Kconfig?

It's a text in a free form that sheds light on how the module will be
named in case the user will choose "m".

...

> > > + * Copyright (C) 2020 Xilinx, Inc.
> >
> > 2021?
> Couple of versions for this patch series sent in 2020, hence maintaining
> the same.
> Is it like we maintain the year when this patch series is applied, which is
> 2021?

2020, 2021 sounds okay as well.

...

> > > +       if (pin >= zynqmp_desc.npins)
> > > +               return -EOPNOTSUPP;
> >
> > Is it possible?
> This is a safe check.

I.o.w. dead code, right?

> Pin information will get from dt files/Xilinx firmware (query pin information
> for a group)/user application and there are chances of getting wrong pin.

I'm not sure I understand this. How comes that pin control core will
ask for a pin higher than npins?

...

> > > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > > +               if (arg != PM_PINCTRL_BIAS_PULL_UP)
> > > +                       return -EINVAL;
> >
> > Error code being shadowed. Instead check it here properly.

> Are you mentioning the case where ret is also a non-zero?
> If yes, then I will update this check to
> if (!ret && arg != PM_PINCTRL_BIAS_PULL_UP)
>         return -EINVAL;

No, this is wrong in the same way.

> ret non-zero case, we are handling at the end of switch case.

I meant that you need to pass the real return code to the (upper) caller.
Ditto for all other cases (mentioned and not mentioned)

...

> > > +                       ret = -EOPNOTSUPP;
> >
> > Isn't it ENOTSUP for all cases here?
> Giving 'Operation Not Supported (EOPNOTSUPP)' error, when
> driver gets a request for unsupported pin or configuration.
> Can you please elaborate your question if I didn't answer properly.

The pin control subsystem along with the GPIO library are using
-ENOTSUPP error code for internal operations.
EOPNOTSUPP is the one that should be returned to user space. Is it the
case here?

...

> > > +};
> >
> > > +
> >
> > Ditto.
> I see some drivers are maintaining the extra line in above two cases.
> We shouldn't maintain extra line after struct declaration?

What's the point to add more blank lines where they won't add any value?

> > > +module_platform_driver(zynqmp_pinctrl_driver);

-- 
With Best Regards,
Andy Shevchenko


From krzysztof.kozlowski at canonical.com  Mon Apr 26 15:10:07 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 16:10:07 +0200
Subject: [PATCH v2 01/10] memory: tegra: Implement SID override programming
In-Reply-To: <YIauV/BgPCZSZ8u2@orome.fritz.box>
References: <20210420172619.3782831-1-thierry.reding@gmail.com>
 <20210420172619.3782831-2-thierry.reding@gmail.com>
 <03e2a655-7dbf-a729-75f6-98db353e2b91@canonical.com>
 <YIauV/BgPCZSZ8u2@orome.fritz.box>
Message-ID: <526942f8-861a-8b0f-66a2-42eda600fabe@canonical.com>

On 26/04/2021 14:13, Thierry Reding wrote:
> On Mon, Apr 26, 2021 at 10:28:43AM +0200, Krzysztof Kozlowski wrote:

(...)

>>> +
>>> +	value = readl(mc->regs + client->regs.sid.override);
>>> +	old = value & MC_SID_STREAMID_OVERRIDE_MASK;
>>> +
>>> +	if (old != sid) {
>>> +		dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
>>> +			client->name, sid);
>>> +		writel(sid, mc->regs + client->regs.sid.override);
>>> +	}
>>> +}
>>> +
>>> +static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
>>> +{
>>> +#if IS_ENABLED(CONFIG_IOMMU_API)
>>
>> Is this part really build-time dependent? I don't see here any uses of
>> IOMMU specific fields, so maybe this should be runtime choice based on
>> enabled interconnect devices?
> 
> Unfortunately it is. struct iommu_fwspec is an empty structure for
> !CONFIG_IOMMU_API, so the code below that tries to access fwspec->ids
> fails for !CONFIG_IOMMU_API configurations if we don't protect this with
> the preprocessor guard.

OK, thanks.

> 
>>
>>> +	struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>>> +	struct of_phandle_args args;
>>> +	unsigned int i, index = 0;
>>> +
>>> +	while (!of_parse_phandle_with_args(dev->of_node, "interconnects", "#interconnect-cells",
>>> +					   index, &args)) {
>>> +		if (args.np == mc->dev->of_node && args.args_count != 0) {
>>> +			for (i = 0; i < mc->soc->num_clients; i++) {
>>> +				const struct tegra_mc_client *client = &mc->soc->clients[i];
>>> +
>>> +				if (client->id == args.args[0]) {
>>> +					u32 sid = fwspec->ids[0] & MC_SID_STREAMID_OVERRIDE_MASK;
>>> +
>>> +					tegra186_mc_client_sid_override(mc, client, sid);
>>> +				}
>>> +			}
>>> +		}
>>> +
>>> +		index++;
>>> +	}
>>> +#endif
>>> +
>>> +	return 0;
>>> +}
>>> +
>>>  const struct tegra_mc_ops tegra186_mc_ops = {
>>>  	.probe = tegra186_mc_probe,
>>>  	.remove = tegra186_mc_remove,
>>>  	.resume = tegra186_mc_resume,
>>> +	.probe_device = tegra186_mc_probe_device,
>>>  };
>>>  
>>>  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
>>> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
>>> index 1387747d574b..bbad6330008b 100644
>>> --- a/include/soc/tegra/mc.h
>>> +++ b/include/soc/tegra/mc.h
>>> @@ -176,6 +176,7 @@ struct tegra_mc_ops {
>>>  	int (*suspend)(struct tegra_mc *mc);
>>>  	int (*resume)(struct tegra_mc *mc);
>>>  	irqreturn_t (*handle_irq)(int irq, void *data);
>>> +	int (*probe_device)(struct tegra_mc *mc, struct device *dev);
>>>  };
>>>  
>>>  struct tegra_mc_soc {
>>> @@ -240,4 +241,6 @@ devm_tegra_memory_controller_get(struct device *dev)
>>>  }
>>>  #endif
>>>  
>>> +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
>>> +
>>
>> What about !CONFIG_TEGRA_MC? I think arm-smmmu will fail.
> 
> I think it doesn't fail because for !CONFIG_TEGRA_MC it basically throws
> away most of nvidia_smmu_impl_init() already because ERR_PTR(-ENODEV) is
> returned by devm_tegra_memory_controller_get() and so it unconditionally
> fails early on already.
> 
> I say I /think/ that happens because I can't reproduce a build failure
> even if I manually tweak the .config such that ARM_SMMU is enabled and
> TEGRA_MC is disabled. But I can't say I fully understand why it's
> working, because, yes, the symbol definitely doesn't exist. But again,
> if the compiler is clever enough to figure out that that function can't
> be called anyway and doesn't even want it, why bother making it more
> complicated than it has to be?

Since you tested that case, it's fine.


Best regards,
Krzysztof


From krzysztof.kozlowski at canonical.com  Mon Apr 26 15:12:43 2021
From: krzysztof.kozlowski at canonical.com (Krzysztof Kozlowski)
Date: Mon, 26 Apr 2021 16:12:43 +0200
Subject: [PATCH v2] tty: serial: samsung_tty: remove set but not used
 variables
In-Reply-To: <1619443135-21399-1-git-send-email-tiantao6@hisilicon.com>
References: <1619443135-21399-1-git-send-email-tiantao6@hisilicon.com>
Message-ID: <ff816f12-c9fc-94bd-52a7-1d1b1c9a49de@canonical.com>

On 26/04/2021 15:18, Tian Tao wrote:
> The value of 'ret' is not used which reported by svace, so jutst return

s/jutst/just/


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>

> instead of break.
> 
> Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
> ---
> v2: s3c24xx_serial_probe function exit than convert ret to some default
> value when the attribute "reg-io-width" is not 1 or 4.
> ---
>  drivers/tty/serial/samsung_tty.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)



Best regards,
Krzysztof


From u.kleine-koenig at pengutronix.de  Mon Apr 26 15:17:24 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 16:17:24 +0200
Subject: [PATCH v6 0/6] clk: provide new devm helpers for prepared and enabled
 clocks
Message-ID: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>

Hello,

compared to v5 sent last week this series only fixes two typos in the
commit logs.

The range-diff is
1:  0f2fe65a9c9c ! 1:  38f213c5eeff rtc: at91sma9: Simplify using devm_clk_get_enabled()
    @@ Metadata
     Author: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
     
      ## Commit message ##
    -    rtc: at91sma9: Simplify using devm_clk_get_enabled()
    +    rtc: at91sam9: Simplify using devm_clk_get_enabled()
     
         devm_clk_get_enabled() returns the clk already (prepared and) enabled
         and the automatically called cleanup cares for disabling (and
2:  3f11b70e7427 ! 2:  b9cebea08a73 i2c: imx: Simplify using devm_clk_get_enableded()
    @@ Metadata
     Author: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
     
      ## Commit message ##
    -    i2c: imx: Simplify using devm_clk_get_enableded()
    +    i2c: imx: Simplify using devm_clk_get_enabled()
     
         devm_clk_get_enabled() returns the clk already (prepared and) enabled
         and the automatically called cleanup cares for disabling (and
3:  6c357913e391 = 3:  8167605ad349 spi: davinci: Simplify using devm_clk_get_enabled()
4:  71b3db526357 < -:  ------------ pwm: Clarify documentation about pwm_get_state()

Other than that the state is still unchanged: This is a series which
allows several cleanups (as can be seen from patches 2 to 6) and I
didn't get any feedback from the clock maintainers since v1 that I sent
in October.

Best regards
Uwe

Uwe Kleine-K?nig (6):
  clk: generalize devm_clk_get() a bit
  clk: Provide new devm_clk_helpers for prepared and enabled clocks
  pwm: atmel: Simplify using devm_clk_get_prepared()
  rtc: at91sam9: Simplify using devm_clk_get_enabled()
  i2c: imx: Simplify using devm_clk_get_enabled()
  spi: davinci: Simplify using devm_clk_get_enabled()

 drivers/clk/clk-devres.c     | 96 ++++++++++++++++++++++++++++++------
 drivers/i2c/busses/i2c-imx.c | 12 +----
 drivers/pwm/pwm-atmel.c      | 15 +-----
 drivers/rtc/rtc-at91sam9.c   | 22 ++-------
 drivers/spi/spi-davinci.c    | 11 +----
 include/linux/clk.h          | 87 +++++++++++++++++++++++++++++++-
 6 files changed, 176 insertions(+), 67 deletions(-)


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Mon Apr 26 15:17:25 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 16:17:25 +0200
Subject: [PATCH v6 1/6] clk: generalize devm_clk_get() a bit
In-Reply-To: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
References: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210426141730.2826832-2-u.kleine-koenig@pengutronix.de>

Allow to add an exit hook to devm managed clocks. Also use
clk_get_optional() in devm_clk_get_optional instead of open coding it.
The generalisation will be used in the next commit to add some more
devm_clk helpers.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk-devres.c | 67 ++++++++++++++++++++++++++++++----------
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index be160764911b..91c995815b57 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -4,39 +4,72 @@
 #include <linux/export.h>
 #include <linux/gfp.h>
 
+struct devm_clk_state {
+	struct clk *clk;
+	void (*exit)(struct clk *clk);
+};
+
 static void devm_clk_release(struct device *dev, void *res)
 {
-	clk_put(*(struct clk **)res);
+	struct devm_clk_state *state = *(struct devm_clk_state **)res;
+
+	if (state->exit)
+		state->exit(state->clk);
+
+	clk_put(state->clk);
 }
 
-struct clk *devm_clk_get(struct device *dev, const char *id)
+static struct clk *__devm_clk_get(struct device *dev, const char *id,
+				  struct clk *(*get)(struct device *dev, const char *id),
+				  int (*init)(struct clk *clk),
+				  void (*exit)(struct clk *clk))
 {
-	struct clk **ptr, *clk;
+	struct devm_clk_state *state;
+	struct clk *clk;
+	int ret;
 
-	ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
-	if (!ptr)
+	state = devres_alloc(devm_clk_release, sizeof(*state), GFP_KERNEL);
+	if (!state)
 		return ERR_PTR(-ENOMEM);
 
-	clk = clk_get(dev, id);
-	if (!IS_ERR(clk)) {
-		*ptr = clk;
-		devres_add(dev, ptr);
-	} else {
-		devres_free(ptr);
+	clk = get(dev, id);
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		goto err_clk_get;
 	}
 
+	if (init) {
+		ret = init(clk);
+		if (ret)
+			goto err_clk_init;
+	}
+
+	state->clk = clk;
+	state->exit = exit;
+
+	devres_add(dev, state);
+
 	return clk;
+
+err_clk_init:
+
+	clk_put(clk);
+err_clk_get:
+
+	devres_free(state);
+	return ERR_PTR(ret);
 }
-EXPORT_SYMBOL(devm_clk_get);
 
-struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+struct clk *devm_clk_get(struct device *dev, const char *id)
 {
-	struct clk *clk = devm_clk_get(dev, id);
+	return __devm_clk_get(dev, id, clk_get, NULL, NULL);
 
-	if (clk == ERR_PTR(-ENOENT))
-		return NULL;
+}
+EXPORT_SYMBOL(devm_clk_get);
 
-	return clk;
+struct clk *devm_clk_get_optional(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
 }
 EXPORT_SYMBOL(devm_clk_get_optional);
 
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Mon Apr 26 15:17:29 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 16:17:29 +0200
Subject: [PATCH v6 5/6] i2c: imx: Simplify using devm_clk_get_enabled()
In-Reply-To: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
References: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210426141730.2826832-6-u.kleine-koenig@pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Acked-by: Oleksij Rempel <o.rempel at pengutronix.de>
Acked-by: Wolfram Sang <wsa at kernel.org>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/i2c/busses/i2c-imx.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index b80fdc1f0092..d6594358cf83 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1405,16 +1405,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	ACPI_COMPANION_SET(&i2c_imx->adapter.dev, ACPI_COMPANION(&pdev->dev));
 
 	/* Get I2C clock */
-	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
+	i2c_imx->clk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(i2c_imx->clk))
 		return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
-				     "can't get I2C clock\n");
-
-	ret = clk_prepare_enable(i2c_imx->clk);
-	if (ret) {
-		dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
-		return ret;
-	}
+				     "can't get prepared I2C clock\n");
 
 	/* Init queue */
 	init_waitqueue_head(&i2c_imx->queue);
@@ -1487,7 +1481,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-	clk_disable_unprepare(i2c_imx->clk);
 	return ret;
 }
 
@@ -1517,7 +1510,6 @@ static int i2c_imx_remove(struct platform_device *pdev)
 	irq = platform_get_irq(pdev, 0);
 	if (irq >= 0)
 		free_irq(irq, i2c_imx);
-	clk_disable_unprepare(i2c_imx->clk);
 
 	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Mon Apr 26 15:17:28 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 16:17:28 +0200
Subject: [PATCH v6 4/6] rtc: at91sam9: Simplify using devm_clk_get_enabled()
In-Reply-To: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
References: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210426141730.2826832-5-u.kleine-koenig@pengutronix.de>

devm_clk_get_enabled() returns the clk already (prepared and) enabled
and the automatically called cleanup cares for disabling (and
unpreparing). So simplify .probe() and .remove() accordingly.

Acked-by: Nicolas Ferre <nicolas.ferre at microchip.com>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/rtc/rtc-at91sam9.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/rtc/rtc-at91sam9.c b/drivers/rtc/rtc-at91sam9.c
index 2216be429ab7..b52e7bd26303 100644
--- a/drivers/rtc/rtc-at91sam9.c
+++ b/drivers/rtc/rtc-at91sam9.c
@@ -374,21 +374,14 @@ static int at91_rtc_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	rtc->sclk = devm_clk_get(&pdev->dev, NULL);
+	rtc->sclk = devm_clk_get_enabled(&pdev->dev, NULL);
 	if (IS_ERR(rtc->sclk))
 		return PTR_ERR(rtc->sclk);
 
-	ret = clk_prepare_enable(rtc->sclk);
-	if (ret) {
-		dev_err(&pdev->dev, "Could not enable slow clock\n");
-		return ret;
-	}
-
 	sclk_rate = clk_get_rate(rtc->sclk);
 	if (!sclk_rate || sclk_rate > AT91_RTT_RTPRES) {
 		dev_err(&pdev->dev, "Invalid slow clock rate\n");
-		ret = -EINVAL;
-		goto err_clk;
+		return -EINVAL;
 	}
 
 	mr = rtt_readl(rtc, MR);
@@ -406,7 +399,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
 	rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
 	if (IS_ERR(rtc->rtcdev)) {
 		ret = PTR_ERR(rtc->rtcdev);
-		goto err_clk;
+		return ret;
 	}
 
 	rtc->rtcdev->ops = &at91_rtc_ops;
@@ -418,7 +411,7 @@ static int at91_rtc_probe(struct platform_device *pdev)
 			       dev_name(&rtc->rtcdev->dev), rtc);
 	if (ret) {
 		dev_dbg(&pdev->dev, "can't share IRQ %d?\n", rtc->irq);
-		goto err_clk;
+		return ret;
 	}
 
 	/* NOTE:  sam9260 rev A silicon has a ROM bug which resets the
@@ -432,11 +425,6 @@ static int at91_rtc_probe(struct platform_device *pdev)
 			 dev_name(&rtc->rtcdev->dev));
 
 	return devm_rtc_register_device(rtc->rtcdev);
-
-err_clk:
-	clk_disable_unprepare(rtc->sclk);
-
-	return ret;
 }
 
 /*
@@ -450,8 +438,6 @@ static int at91_rtc_remove(struct platform_device *pdev)
 	/* disable all interrupts */
 	rtt_writel(rtc, MR, mr & ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN));
 
-	clk_disable_unprepare(rtc->sclk);
-
 	return 0;
 }
 
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Mon Apr 26 15:17:26 2021
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 16:17:26 +0200
Subject: [PATCH v6 2/6] clk: Provide new devm_clk_helpers for prepared and
 enabled clocks
In-Reply-To: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
References: <20210426141730.2826832-1-u.kleine-koenig@pengutronix.de>
Message-ID: <20210426141730.2826832-3-u.kleine-koenig@pengutronix.de>

When a driver keeps a clock prepared (or enabled) during the whole
lifetime of the driver, these helpers allow to simplify the drivers.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/clk/clk-devres.c | 31 ++++++++++++++
 include/linux/clk.h      | 87 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
index 91c995815b57..b54f7f0f2a35 100644
--- a/drivers/clk/clk-devres.c
+++ b/drivers/clk/clk-devres.c
@@ -67,12 +67,43 @@ struct clk *devm_clk_get(struct device *dev, const char *id)
 }
 EXPORT_SYMBOL(devm_clk_get);
 
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get, clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_prepared);
+
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get,
+			      clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_enabled);
+
 struct clk *devm_clk_get_optional(struct device *dev, const char *id)
 {
 	return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
 }
 EXPORT_SYMBOL(devm_clk_get_optional);
 
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional,
+			      clk_prepare, clk_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_prepared);
+
+struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id)
+{
+	return __devm_clk_get(dev, id, clk_get_optional,
+			      clk_prepare_enable, clk_disable_unprepare);
+
+}
+EXPORT_SYMBOL(devm_clk_get_optional_enabled);
+
 struct clk_bulk_devres {
 	struct clk_bulk_data *clks;
 	int num_clks;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 266e8de3cb51..b3c5da388b08 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -449,7 +449,7 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
  * the clock producer.  (IOW, @id may be identical strings, but
  * clk_get may return different clock producers depending on @dev.)
  *
- * Drivers must assume that the clock source is not enabled.
+ * Drivers must assume that the clock source is neither prepared nor enabled.
  *
  * devm_clk_get should not be called from within interrupt context.
  *
@@ -458,6 +458,47 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
  */
 struct clk *devm_clk_get(struct device *dev, const char *id);
 
+/**
+ * devm_clk_get_prepared - devm_clk_get() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer.  (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared. Drivers must however assume that the
+ * clock is not enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_prepared(struct device *dev, const char *id);
+
+/**
+ * devm_clk_get_enabled - devm_clk_get() + clk_prepare_enable()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer.  (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * The returned clk (if valid) is prepared and enabled.
+ *
+ * devm_clk_get_prepared should not be called from within interrupt context.
+ *
+ * The clock will automatically be disabled, unprepared and freed when the
+ * device is unbound from the bus.
+ */
+struct clk *devm_clk_get_enabled(struct device *dev, const char *id);
+
 /**
  * devm_clk_get_optional - lookup and obtain a managed reference to an optional
  *			   clock producer.
@@ -469,6 +510,26 @@ struct clk *devm_clk_get(struct device *dev, const char *id);
  */
 struct clk *devm_clk_get_optional(struct device *dev, const char *id);
 
+/**
+ * devm_clk_get_optional_prepared - devm_clk_get_optional() + clk_prepare()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Behaves the same as devm_clk_get_prepared() except where there is no clock producer.
+ * In this case, instead of returning -ENOENT, the function returns NULL.
+ */
+struct clk *devm_clk_get_optional_prepared(struct device *dev, const char *id);
+
+/**
+ * devm_clk_get_optional_enabled - devm_clk_get_optional() + clk_prepare_enable()
+ * @dev: device for clock "consumer"
+ * @id: clock consumer ID
+ *
+ * Behaves the same as devm_clk_get_enabled() except where there is no clock producer.
+ * In this case, instead of returning -ENOENT, the function returns NULL.
+ */
+struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id);
+
 /**
  * devm_get_clk_from_child - lookup and obtain a managed reference to a
  *			     clock producer from child node.
@@ -813,12 +874,36 @@ static inline struct clk *devm_clk_get(struct device *dev, const char *id)
 	return NULL;
 }
 
+static inline struct clk *devm_clk_get_prepared(struct device *dev,
+						const char *id)
+{
+	return NULL;
+}
+
+static inline struct clk *devm_clk_get_enabled(struct device *dev,
+					       const char *id)
+{
+	return NULL;
+}
+
 static inline struct clk *devm_clk_get_optional(struct device *dev,
 						const char *id)
 {
 	return NULL;
 }
 
+static inline struct clk *devm_clk_get_optional_prepared(struct device *dev,
+							 const char *id)
+{
+	return NULL;
+}
+
+static inline struct clk *devm_clk_get_optional_enabled(struct device *dev,
+							const char *id)
+{
+	return NULL;
+}
+
 static inline int __must_check devm_clk_bulk_get(struct device *dev, int num_clks,
 						 struct clk_bulk_data *clks)
 {
-- 
2.30.2



From sfr at rothwell.id.au  Mon Apr 26 15:26:48 2021
From: sfr at rothwell.id.au (Stephen Rothwell)
Date: Tue, 27 Apr 2021 00:26:48 +1000
Subject: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
In-Reply-To: <YIa2ErYuJyCfSkS+@kroah.com>
References: <YIa2ErYuJyCfSkS+@kroah.com>
Message-ID: <20210427002648.22459fa7@elm.ozlabs.ibm.com>

Hi Greg,

On Mon, 26 Apr 2021 14:46:10 +0200 Greg KH <gregkh at linuxfoundation.org> wrote:
>
> All of these have been in linux-next for a while with no reported
> issues.

There was just these:

https://lore.kernel.org/linux-next/20210329165525.32d51a3a at canb.auug.org.au/

https://lore.kernel.org/linux-next/20210331175151.67fcfe4d at canb.auug.org.au/

(the scmi tree commit mentioned in the latter is now in the arm-soc tree)

Not issues as such, but worth mentioning the conflicts and resolutions.
-- 
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/20210427/4472264a/attachment.sig>

From catalin.marinas at arm.com  Mon Apr 26 15:27:12 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 26 Apr 2021 15:27:12 +0100
Subject: [GIT PULL] arm64 updates for 5.13-rc1
Message-ID: <20210426142710.GA10892@arm.com>

Hi Linus,

Please pull the arm64 updates below for 5.13. Apart from the usual arm64
and perf stuff, the MTE changes touch the kasan code under mm/ (acked by
the kasan maintainers). There is a minor conflicts with v5.12 due to
a fix that went in a late -rc stage. I included my resolution after the
diffstat below, though the only one not automatically resolved is in
arch/arm64/include/asm/cpucaps.h.

Thanks.

The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:

  Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream

for you to fetch changes up to a27a8816568964fcef62a3ae5f9d2228ec1ebc68:

  Merge branch 'for-next/pac-set-get-enabled-keys' into for-next/core (2021-04-15 14:00:48 +0100)

----------------------------------------------------------------
arm64 updates for 5.13:

- MTE asynchronous support for KASan. Previously only synchronous
  (slower) mode was supported. Asynchronous is faster but does not allow
  precise identification of the illegal access.

- Run kernel mode SIMD with softirqs disabled. This allows using NEON in
  softirq context for crypto performance improvements. The conditional
  yield support is modified to take softirqs into account and reduce the
  latency.

- Preparatory patches for Apple M1: handle CPUs that only have the VHE
  mode available (host kernel running at EL2), add FIQ support.

- arm64 perf updates: support for HiSilicon PA and SLLC PMU drivers, new
  functions for the HiSilicon HHA and L3C PMU, cleanups.

- Re-introduce support for execute-only user permissions but only when
  the EPAN (Enhanced Privileged Access Never) architecture feature is
  available.

- Disable fine-grained traps at boot and improve the documented boot
  requirements.

- Support CONFIG_KASAN_VMALLOC on arm64 (only with KASAN_GENERIC).

- Add hierarchical eXecute Never permissions for all page tables.

- Add arm64 prctl(PR_PAC_{SET,GET}_ENABLED_KEYS) allowing user programs
  to control which PAC keys are enabled in a particular task.

- arm64 kselftests for BTI and some improvements to the MTE tests.

- Minor improvements to the compat vdso and sigpage.

- Miscellaneous cleanups.

----------------------------------------------------------------
Andre Przywara (11):
      kselftest/arm64: mte: Fix compilation with native compiler
      kselftest/arm64: mte: Fix pthread linking
      kselftest/arm64: mte: ksm_options: Fix fscanf warning
      kselftest/arm64: mte: user_mem: Fix write() warning
      kselftest/arm64: mte: common: Fix write() warnings
      kselftest/arm64: mte: Fix MTE feature detection
      kselftest/arm64: mte: Use cross-compiler if specified
      kselftest/arm64: mte: Output warning about failing compiler
      kselftest/arm64: mte: Makefile: Fix clang compilation
      kselftest/arm64: mte: Fix clang warning
      kselftest/arm64: mte: Report filename on failing temp file creation

Andrey Konovalov (1):
      kasan, arm64: tests supports for HW_TAGS async mode

Ard Biesheuvel (6):
      arm64: mm: add missing P4D definitions and use them consistently
      arm64: mm: use XN table mapping attributes for the linear region
      arm64: mm: use XN table mapping attributes for user/kernel mappings
      arm64: assembler: remove conditional NEON yield macros
      arm64: assembler: introduce wxN aliases for wN registers
      arm64: fpsimd: run kernel mode NEON with softirqs disabled

Catalin Marinas (3):
      Merge branches 'for-next/misc', 'for-next/kselftest', 'for-next/xntable', 'for-next/vdso', 'for-next/fiq', 'for-next/epan', 'for-next/kasan-vmalloc', 'for-next/fgt-boot-init', 'for-next/vhe-only' and 'for-next/neon-softirqs-disabled', remote-tracking branch 'arm64/for-next/perf' into for-next/core
      Merge branch 'for-next/mte-async-kernel-mode' into for-next/core
      Merge branch 'for-next/pac-set-get-enabled-keys' into for-next/core

Chen Lifu (1):
      arm64: smp: Add missing prototype for some smp.c functions

He Ying (1):
      docs: arm64: Fix a grammar error

Hector Martin (1):
      arm64: Always keep DAIF.[IF] in sync

Jisheng Zhang (1):
      arm64: Add __init section marker to some functions

Lecopzer Chen (5):
      arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
      arm64: kasan: abstract _text and _end to KERNEL_START/END
      arm64: Kconfig: support CONFIG_KASAN_VMALLOC
      arm64: kaslr: support randomized module area with KASAN_VMALLOC
      arm64: Kconfig: select KASAN_VMALLOC if KANSAN_GENERIC is enabled

Linus Walleij (1):
      arm64: barrier: Remove spec_bar() macro

Marc Zyngier (6):
      genirq: Allow architectures to override set_handle_irq() fallback
      arm64: don't use GENERIC_IRQ_MULTI_HANDLER
      arm64: entry: factor irq triage logic into macros
      arm64: cpufeature: Allow early filtering of feature override
      arm64: Cope with CPUs stuck in VHE mode
      arm64: Get rid of CONFIG_ARM64_VHE

Mark Brown (9):
      arm64: defconfig: Use DEBUG_INFO_REDUCED
      kselftest: arm64: Add BTI tests
      arm64: stacktrace: Move start_backtrace() out of the header
      arm64/sve: Rework SVE access trap to convert state in registers
      arm64: Document requirements for fine grained traps at boot
      arm64: Disable fine grained traps on boot
      arm64: Require that system registers at all visible ELs be initialized
      arm64/sve: Remove redundant system_supports_sve() tests
      arm64/sve: Add compile time checks for SVE hooks in generic functions

Mark Rutland (5):
      arm64: irq: rework root IRQ handler registration
      arm64: irq: allow FIQs to be handled
      arm64: entry: remove test_irqs_unmasked macro
      arm64: setup: name `mair` register
      arm64: setup: name `tcr` register

Peter Collingbourne (3):
      arm64: mte: make the per-task SCTLR_EL1 field usable elsewhere
      arm64: Introduce prctl(PR_PAC_{SET,GET}_ENABLED_KEYS)
      arm64: pac: Optimize kernel entry/exit key installation code paths

Qi Liu (5):
      drivers/perf: convert sysfs scnprintf family to sysfs_emit_at() and sysfs_emit()
      drivers/perf: convert sysfs sprintf family to sysfs_emit
      drivers/perf: Simplify the SMMUv3 PMU event attributes
      docs: perf: Address some html build warnings
      arm64: perf: Remove redundant initialization in perf_event.c

Robin Murphy (3):
      perf/arm_pmu_platform: Use dev_err_probe() for IRQ errors
      perf/arm_pmu_platform: Fix error handling
      perf/arm_pmu_platform: Clean up with dev_printk

Shaokun Zhang (9):
      drivers/perf: hisi: Remove unnecessary check of counter index
      drivers/perf: hisi: Refactor code for more uncore PMUs
      drivers/perf: hisi: Add PMU version for uncore PMU drivers.
      drivers/perf: hisi: Add new functions for L3C PMU
      drivers/perf: hisi: Add new functions for HHA PMU
      drivers/perf: hisi: Update DDRC PMU for programmable counter
      drivers/perf: hisi: Add support for HiSilicon SLLC PMU driver
      drivers/perf: hisi: Add support for HiSilicon PA PMU driver
      docs: perf: Add new description on HiSilicon uncore PMU v2

Vincenzo Frascino (9):
      arm64: mte: Remove unused mte_assign_mem_tag_range()
      arm64: mte: Add asynchronous mode support
      kasan: Add KASAN mode kernel parameter
      arm64: mte: Drop arch_enable_tagging()
      kasan: Add report for async mode
      arm64: mte: Enable TCO in functions that can read beyond buffer limits
      arm64: mte: Conditionally compile mte_enable_kernel_*()
      arm64: mte: Enable async tag check fault
      arm64: mte: Report async tag faults before suspend

Vladimir Murzin (1):
      arm64: Support execute-only permissions with Enhanced PAN

Will Deacon (5):
      arm64: vdso: Use GFP_KERNEL for allocating compat vdso and signal pages
      arm64: vdso: Remove redundant calls to flush_dcache_page()
      arm64: compat: Allow signal page to be remapped
      arm64: vdso: Avoid ISB after reading from cntvct_el0
      arm64: compat: Poison the compat sigpage

Yury Norov (1):
      ARM64: enable GENERIC_FIND_FIRST_BIT

Zihao Tang (1):
      drivers/perf: convert sysfs snprintf family to sysfs_emit

zhouchuangao (1):
      arm64/kernel/probes: Use BUG_ON instead of if condition followed by BUG.

 Documentation/admin-guide/kernel-parameters.txt    |   3 +-
 Documentation/admin-guide/perf/hisi-pmu.rst        |  54 +++
 Documentation/arm64/booting.rst                    |  13 +-
 Documentation/arm64/pointer-authentication.rst     |  34 ++
 Documentation/arm64/tagged-address-abi.rst         |   2 +-
 Documentation/dev-tools/kasan.rst                  |   9 +
 arch/arm64/Kconfig                                 |  41 +-
 arch/arm64/configs/defconfig                       |   1 +
 arch/arm64/crypto/aes-modes.S                      |   2 +-
 arch/arm64/crypto/sha1-ce-core.S                   |   2 +-
 arch/arm64/crypto/sha2-ce-core.S                   |   2 +-
 arch/arm64/crypto/sha3-ce-core.S                   |   4 +-
 arch/arm64/crypto/sha512-ce-core.S                 |   2 +-
 arch/arm64/include/asm/arch_gicv3.h                |   2 +-
 arch/arm64/include/asm/arch_timer.h                |  21 -
 arch/arm64/include/asm/asm_pointer_auth.h          |  20 +-
 arch/arm64/include/asm/assembler.h                 | 114 ++---
 arch/arm64/include/asm/barrier.h                   |  23 +-
 arch/arm64/include/asm/cpucaps.h                   |   3 +-
 arch/arm64/include/asm/cpufeature.h                |  17 +
 arch/arm64/include/asm/daifflags.h                 |  10 +-
 arch/arm64/include/asm/el2_setup.h                 |  21 +
 arch/arm64/include/asm/fpsimd.h                    |   1 +
 arch/arm64/include/asm/irq.h                       |   4 +
 arch/arm64/include/asm/irq_work.h                  |   2 +
 arch/arm64/include/asm/irqflags.h                  |  16 +-
 arch/arm64/include/asm/memory.h                    |   4 +-
 arch/arm64/include/asm/mte-kasan.h                 |   9 +-
 arch/arm64/include/asm/mte.h                       |  54 ++-
 arch/arm64/include/asm/pgalloc.h                   |  19 +-
 arch/arm64/include/asm/pgtable-hwdef.h             |  15 +
 arch/arm64/include/asm/pgtable-prot.h              |   5 +-
 arch/arm64/include/asm/pgtable.h                   |  31 +-
 arch/arm64/include/asm/pointer_auth.h              |  61 ++-
 arch/arm64/include/asm/processor.h                 |  13 +-
 arch/arm64/include/asm/ptdump.h                    |   2 +-
 arch/arm64/include/asm/smp.h                       |   1 +
 arch/arm64/include/asm/stacktrace.h                |  24 +-
 arch/arm64/include/asm/sysreg.h                    |  13 +-
 arch/arm64/include/asm/uaccess.h                   |  22 +
 arch/arm64/include/asm/vdso/gettimeofday.h         |   6 +-
 arch/arm64/include/asm/word-at-a-time.h            |   4 +
 arch/arm64/kernel/asm-offsets.c                    |   7 +-
 arch/arm64/kernel/cpufeature.c                     |  22 +-
 arch/arm64/kernel/entry-common.c                   |   6 +
 arch/arm64/kernel/entry-fpsimd.S                   |   5 +
 arch/arm64/kernel/entry.S                          | 174 ++++---
 arch/arm64/kernel/fpsimd.c                         |  39 +-
 arch/arm64/kernel/head.S                           |  39 +-
 arch/arm64/kernel/hyp-stub.S                       |  10 +-
 arch/arm64/kernel/idreg-override.c                 |  26 +-
 arch/arm64/kernel/irq.c                            |  35 +-
 arch/arm64/kernel/kaslr.c                          |  18 +-
 arch/arm64/kernel/module.c                         |  16 +-
 arch/arm64/kernel/mte.c                            | 121 +++--
 arch/arm64/kernel/perf_event.c                     |   5 +-
 arch/arm64/kernel/pointer_auth.c                   |  63 +++
 arch/arm64/kernel/probes/kprobes.c                 |   3 +-
 arch/arm64/kernel/process.c                        |  35 +-
 arch/arm64/kernel/ptrace.c                         |  41 ++
 arch/arm64/kernel/smp.c                            |   1 +
 arch/arm64/kernel/stacktrace.c                     |  24 +
 arch/arm64/kernel/suspend.c                        |   6 +-
 arch/arm64/kernel/vdso.c                           |  26 +-
 arch/arm64/mm/fault.c                              |  18 +-
 arch/arm64/mm/kasan_init.c                         |  29 +-
 arch/arm64/mm/mmu.c                                |  41 +-
 arch/arm64/mm/proc.S                               |  48 +-
 arch/arm64/mm/ptdump.c                             |   4 +-
 arch/arm64/mm/ptdump_debugfs.c                     |   2 +-
 drivers/perf/arm-cci.c                             |  12 +-
 drivers/perf/arm-ccn.c                             |  31 +-
 drivers/perf/arm-cmn.c                             |  22 +-
 drivers/perf/arm_dmc620_pmu.c                      |   2 +-
 drivers/perf/arm_dsu_pmu.c                         |   5 +-
 drivers/perf/arm_pmu_platform.c                    |  54 +--
 drivers/perf/arm_smmuv3_pmu.c                      |  36 +-
 drivers/perf/arm_spe_pmu.c                         |   3 +-
 drivers/perf/fsl_imx8_ddr_perf.c                   |   7 +-
 drivers/perf/hisilicon/Makefile                    |   3 +-
 drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c      | 348 +++++++++-----
 drivers/perf/hisilicon/hisi_uncore_hha_pmu.c       | 301 ++++++++----
 drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c       | 355 ++++++++++----
 drivers/perf/hisilicon/hisi_uncore_pa_pmu.c        | 500 +++++++++++++++++++
 drivers/perf/hisilicon/hisi_uncore_pmu.c           |  79 ++-
 drivers/perf/hisilicon/hisi_uncore_pmu.h           |  20 +-
 drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c      | 530 +++++++++++++++++++++
 drivers/perf/qcom_l2_pmu.c                         |   2 +-
 drivers/perf/qcom_l3_pmu.c                         |   4 +-
 drivers/perf/thunderx2_pmu.c                       |   4 +-
 drivers/perf/xgene_pmu.c                           |   4 +-
 include/linux/cpuhotplug.h                         |   2 +
 include/linux/irq.h                                |   2 +
 include/linux/kasan.h                              |   6 +
 include/uapi/linux/elf.h                           |   1 +
 include/uapi/linux/prctl.h                         |   4 +
 kernel/sys.c                                       |  16 +
 lib/test_kasan.c                                   |  19 +-
 mm/kasan/hw_tags.c                                 |  66 ++-
 mm/kasan/kasan.h                                   |  40 +-
 mm/kasan/report.c                                  |  22 +-
 mm/mmap.c                                          |   6 +
 tools/testing/selftests/arm64/Makefile             |   2 +-
 tools/testing/selftests/arm64/bti/.gitignore       |   2 +
 tools/testing/selftests/arm64/bti/Makefile         |  61 +++
 tools/testing/selftests/arm64/bti/assembler.h      |  80 ++++
 tools/testing/selftests/arm64/bti/btitest.h        |  23 +
 tools/testing/selftests/arm64/bti/compiler.h       |  21 +
 tools/testing/selftests/arm64/bti/gen/.gitignore   |   2 +
 tools/testing/selftests/arm64/bti/signal.c         |  37 ++
 tools/testing/selftests/arm64/bti/signal.h         |  21 +
 tools/testing/selftests/arm64/bti/start.S          |  14 +
 tools/testing/selftests/arm64/bti/syscall.S        |  23 +
 tools/testing/selftests/arm64/bti/system.c         |  22 +
 tools/testing/selftests/arm64/bti/system.h         |  28 ++
 tools/testing/selftests/arm64/bti/test.c           | 234 +++++++++
 tools/testing/selftests/arm64/bti/teststubs.S      |  39 ++
 tools/testing/selftests/arm64/bti/trampoline.S     |  29 ++
 tools/testing/selftests/arm64/mte/Makefile         |  15 +-
 .../selftests/arm64/mte/check_ksm_options.c        |   5 +-
 tools/testing/selftests/arm64/mte/check_user_mem.c |   3 +-
 .../testing/selftests/arm64/mte/mte_common_util.c  |  39 +-
 122 files changed, 3862 insertions(+), 914 deletions(-)
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_pa_pmu.c
 create mode 100644 drivers/perf/hisilicon/hisi_uncore_sllc_pmu.c
 create mode 100644 tools/testing/selftests/arm64/bti/.gitignore
 create mode 100644 tools/testing/selftests/arm64/bti/Makefile
 create mode 100644 tools/testing/selftests/arm64/bti/assembler.h
 create mode 100644 tools/testing/selftests/arm64/bti/btitest.h
 create mode 100644 tools/testing/selftests/arm64/bti/compiler.h
 create mode 100644 tools/testing/selftests/arm64/bti/gen/.gitignore
 create mode 100644 tools/testing/selftests/arm64/bti/signal.c
 create mode 100644 tools/testing/selftests/arm64/bti/signal.h
 create mode 100644 tools/testing/selftests/arm64/bti/start.S
 create mode 100644 tools/testing/selftests/arm64/bti/syscall.S
 create mode 100644 tools/testing/selftests/arm64/bti/system.c
 create mode 100644 tools/testing/selftests/arm64/bti/system.h
 create mode 100644 tools/testing/selftests/arm64/bti/test.c
 create mode 100644 tools/testing/selftests/arm64/bti/teststubs.S
 create mode 100644 tools/testing/selftests/arm64/bti/trampoline.S

---
diff --cc arch/arm64/include/asm/cpucaps.h
index c40f2490cd7b,9e3ec4dd56d8..b0c5eda0498f
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@@ -66,8 -66,8 +66,9 @@@
  #define ARM64_WORKAROUND_1508412		58
  #define ARM64_HAS_LDAPR				59
  #define ARM64_KVM_PROTECTED_MODE		60
 -#define ARM64_HAS_EPAN				61
 +#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP	61
++#define ARM64_HAS_EPAN				62
  
--#define ARM64_NCAPS				62
++#define ARM64_NCAPS				63
  
  #endif /* __ASM_CPUCAPS_H */
diff --cc arch/arm64/include/asm/word-at-a-time.h
index ea487218db79,c62d9fa791aa..2dcb104c645b
--- a/arch/arm64/include/asm/word-at-a-time.h
+++ b/arch/arm64/include/asm/word-at-a-time.h
@@@ -53,8 -53,10 +53,10 @@@ static inline unsigned long find_zero(u
   */
  static inline unsigned long load_unaligned_zeropad(const void *addr)
  {
 -	unsigned long ret, offset;
 +	unsigned long ret, tmp;
  
+ 	__uaccess_enable_tco_async();
+ 
  	/* Load word from unaligned pointer addr */
  	asm(
  	"1:	ldr	%0, %3\n"
@@@ -73,9 -75,11 +75,11 @@@
  	"	b	2b\n"
  	"	.popsection\n"
  	_ASM_EXTABLE(1b, 3b)
 -	: "=&r" (ret), "=&r" (offset)
 +	: "=&r" (ret), "=&r" (tmp)
  	: "r" (addr), "Q" (*(unsigned long *)addr));
  
+ 	__uaccess_disable_tco_async();
+ 
  	return ret;
  }
  
diff --cc arch/arm64/kernel/entry.S
index 6acfc5e6b5e0,2df32a516ffe..4ac5455c0ead
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@@ -246,10 -244,32 +246,32 @@@ alternative_else_nop_endi
  	disable_step_tsk x19, x20
  
  	/* Check for asynchronous tag check faults in user space */
 -	check_mte_async_tcf x19, x22
 +	check_mte_async_tcf x22, x23
  	apply_ssbd 1, x22, x23
  
- 	ptrauth_keys_install_kernel tsk, x20, x22, x23
+ #ifdef CONFIG_ARM64_PTR_AUTH
+ alternative_if ARM64_HAS_ADDRESS_AUTH
+ 	/*
+ 	 * Enable IA for in-kernel PAC if the task had it disabled. Although
+ 	 * this could be implemented with an unconditional MRS which would avoid
+ 	 * a load, this was measured to be slower on Cortex-A75 and Cortex-A76.
+ 	 *
+ 	 * Install the kernel IA key only if IA was enabled in the task. If IA
+ 	 * was disabled on kernel exit then we would have left the kernel IA
+ 	 * installed so there is no need to install it again.
+ 	 */
+ 	ldr	x0, [tsk, THREAD_SCTLR_USER]
+ 	tbz	x0, SCTLR_ELx_ENIA_SHIFT, 1f
+ 	__ptrauth_keys_install_kernel_nosync tsk, x20, x22, x23
+ 	b	2f
+ 1:
+ 	mrs	x0, sctlr_el1
+ 	orr	x0, x0, SCTLR_ELx_ENIA
+ 	msr	sctlr_el1, x0
+ 2:
+ 	isb
+ alternative_else_nop_endif
+ #endif
  
  	mte_set_kernel_gcr x22, x23
  
diff --cc arch/arm64/kernel/probes/kprobes.c
index 85645b2b0c7a,ecf0f613327f..d607c9912025
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@@ -264,15 -264,12 +264,14 @@@ int __kprobes kprobe_fault_handler(stru
  		 * normal page fault.
  		 */
  		instruction_pointer_set(regs, (unsigned long) cur->addr);
- 		if (!instruction_pointer(regs))
- 			BUG();
+ 		BUG_ON(!instruction_pointer(regs));
  
 -		if (kcb->kprobe_status == KPROBE_REENTER)
 +		if (kcb->kprobe_status == KPROBE_REENTER) {
  			restore_previous_kprobe(kcb);
 -		else
 +		} else {
 +			kprobes_restore_local_irqflag(kcb, regs);
  			reset_current_kprobe();
 +		}
  
  		break;
  	case KPROBE_HIT_ACTIVE:



From patrice.chotard at foss.st.com  Mon Apr 26 15:39:33 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 16:39:33 +0200
Subject: [PATCH 2/3] mtd: spinand: use the spi-mem poll status APIs
In-Reply-To: <20210426143934.25275-1-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
Message-ID: <20210426143934.25275-3-patrice.chotard@foss.st.com>

From: Christophe Kerello <christophe.kerello at foss.st.com>

Make use of spi-mem poll status APIs to let advanced controllers
optimize wait operations

Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/mtd/nand/spi/core.c | 22 ++++++++++++++++++----
 include/linux/mtd/spinand.h |  1 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 17f63f95f4a2..916f435257bd 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -475,18 +475,32 @@ static int spinand_erase_op(struct spinand_device *spinand,
 
 static int spinand_wait(struct spinand_device *spinand, u8 *s)
 {
-	unsigned long timeo =  jiffies + msecs_to_jiffies(400);
+	struct spi_mem_op op = SPINAND_GET_FEATURE_OP(REG_STATUS,
+						      spinand->scratchbuf);
+	unsigned long timeo =  jiffies + msecs_to_jiffies(SPINAND_STATUS_TIMEOUT_MS);
 	u8 status;
 	int ret;
 
-	do {
-		ret = spinand_read_status(spinand, &status);
+	ret = spi_mem_poll_status(spinand->spimem, &op, STATUS_BUSY, 0,
+				  SPINAND_STATUS_TIMEOUT_MS);
+	if (ret != -EOPNOTSUPP) {
 		if (ret)
 			return ret;
 
+		status = *spinand->scratchbuf;
+
 		if (!(status & STATUS_BUSY))
 			goto out;
-	} while (time_before(jiffies, timeo));
+	} else {
+		do {
+			ret = spinand_read_status(spinand, &status);
+			if (ret)
+				return ret;
+
+			if (!(status & STATUS_BUSY))
+				goto out;
+		} while (time_before(jiffies, timeo));
+	}
 
 	/*
 	 * Extra read, just in case the STATUS_READY bit has changed
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 6bb92f26833e..28ee481d96eb 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -170,6 +170,7 @@ struct spinand_op;
 struct spinand_device;
 
 #define SPINAND_MAX_ID_LEN	4
+#define SPINAND_STATUS_TIMEOUT_MS	400
 
 /**
  * struct spinand_id - SPI NAND id structure
-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 26 15:39:31 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 16:39:31 +0200
Subject: [PATCH 0/3] MTD: spinand: Add spi_mem_poll_status() support
Message-ID: <20210426143934.25275-1-patrice.chotard@foss.st.com>

From: Patrice Chotard <patrice.chotard at foss.st.com>

This series adds support for the spi_mem_poll_status() spinand
interface.
Some QSPI controllers allows to poll automatically memory 
status during operations (erase or write). This allows to 
offload the CPU for this task.
STM32 QSPI is supporting this feature, driver update are also
part of this series.

Christophe Kerello (3):
  spi: spi-mem: add automatic poll status functions
  mtd: spinand: use the spi-mem poll status APIs
  spi: stm32-qspi: add automatic poll status feature

 drivers/mtd/nand/spi/core.c  | 22 ++++++++--
 drivers/spi/spi-mem.c        | 34 +++++++++++++++
 drivers/spi/spi-stm32-qspi.c | 80 ++++++++++++++++++++++++++++++++----
 include/linux/mtd/spinand.h  |  1 +
 include/linux/spi/spi-mem.h  |  8 ++++
 5 files changed, 133 insertions(+), 12 deletions(-)

-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 26 15:39:32 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 16:39:32 +0200
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426143934.25275-1-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
Message-ID: <20210426143934.25275-2-patrice.chotard@foss.st.com>

From: Christophe Kerello <christophe.kerello at foss.st.com>

With STM32 QSPI, it is possible to poll the status register of the device.
This could be done to offload the CPU during an operation (erase or
program a SPI NAND for example).

spi_mem_poll_status API has been added to handle this feature.

Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/spi/spi-mem.c       | 34 ++++++++++++++++++++++++++++++++++
 include/linux/spi/spi-mem.h |  8 ++++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 1513553e4080..43dce4b0efa4 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -743,6 +743,40 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
 	return container_of(drv, struct spi_mem_driver, spidrv.driver);
 }
 
+/**
+ * spi_mem_poll_status() - Poll memory device status
+ * @mem: SPI memory device
+ * @op: the memory operation to execute
+ * @mask: status bitmask to ckeck
+ * @match: status expected value
+ * @timeout: timeout
+ *
+ * This function send a polling status request to the controller driver
+ *
+ * Return: 0 in case of success, -ETIMEDOUT in case of error,
+ *         -EOPNOTSUPP if not supported.
+ */
+int spi_mem_poll_status(struct spi_mem *mem,
+			const struct spi_mem_op *op,
+			u8 mask, u8 match, u16 timeout)
+{
+	struct spi_controller *ctlr = mem->spi->controller;
+	int ret = -EOPNOTSUPP;
+
+	if (ctlr->mem_ops && ctlr->mem_ops->poll_status) {
+		ret = spi_mem_access_start(mem);
+		if (ret)
+			return ret;
+
+		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);
+
+		spi_mem_access_end(mem);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(spi_mem_poll_status);
+
 static int spi_mem_probe(struct spi_device *spi)
 {
 	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 2b65c9edc34e..5f78917c0f68 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -250,6 +250,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
  *		  the currently mapped area), and the caller of
  *		  spi_mem_dirmap_write() is responsible for calling it again in
  *		  this case.
+ * @poll_status: poll memory device status
  *
  * This interface should be implemented by SPI controllers providing an
  * high-level interface to execute SPI memory operation, which is usually the
@@ -274,6 +275,9 @@ struct spi_controller_mem_ops {
 			       u64 offs, size_t len, void *buf);
 	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
 				u64 offs, size_t len, const void *buf);
+	int (*poll_status)(struct spi_mem *mem,
+			   const struct spi_mem_op *op,
+			   u8 mask, u8 match, u16 timeout);
 };
 
 /**
@@ -369,6 +373,10 @@ devm_spi_mem_dirmap_create(struct device *dev, struct spi_mem *mem,
 void devm_spi_mem_dirmap_destroy(struct device *dev,
 				 struct spi_mem_dirmap_desc *desc);
 
+int spi_mem_poll_status(struct spi_mem *mem,
+			const struct spi_mem_op *op,
+			u8 mask, u8 match, u16 timeout);
+
 int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
 				       struct module *owner);
 
-- 
2.17.1



From patrice.chotard at foss.st.com  Mon Apr 26 15:39:34 2021
From: patrice.chotard at foss.st.com (patrice.chotard at foss.st.com)
Date: Mon, 26 Apr 2021 16:39:34 +0200
Subject: [PATCH 3/3] spi: stm32-qspi: add automatic poll status feature
In-Reply-To: <20210426143934.25275-1-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
Message-ID: <20210426143934.25275-4-patrice.chotard@foss.st.com>

From: Christophe Kerello <christophe.kerello at foss.st.com>

STM32 QSPI is able to automatically poll a specified register inside the
memory and relieve the CPU from this task.

As example, when erasing a large memory area, we got cpu load
equal to 50%. This patch allows to perform the same operation
with a cpu load around 2%.

Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
---
 drivers/spi/spi-stm32-qspi.c | 80 ++++++++++++++++++++++++++++++++----
 1 file changed, 72 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
index 7e640ccc7e77..2f9e5941f14f 100644
--- a/drivers/spi/spi-stm32-qspi.c
+++ b/drivers/spi/spi-stm32-qspi.c
@@ -36,6 +36,7 @@
 #define CR_FTIE			BIT(18)
 #define CR_SMIE			BIT(19)
 #define CR_TOIE			BIT(20)
+#define CR_APMS			BIT(22)
 #define CR_PRESC_MASK		GENMASK(31, 24)
 
 #define QSPI_DCR		0x04
@@ -53,6 +54,7 @@
 #define QSPI_FCR		0x0c
 #define FCR_CTEF		BIT(0)
 #define FCR_CTCF		BIT(1)
+#define FCR_CSMF		BIT(3)
 
 #define QSPI_DLR		0x10
 
@@ -107,6 +109,7 @@ struct stm32_qspi {
 	u32 clk_rate;
 	struct stm32_qspi_flash flash[STM32_QSPI_MAX_NORCHIP];
 	struct completion data_completion;
+	struct completion match_completion;
 	u32 fmode;
 
 	struct dma_chan *dma_chtx;
@@ -115,6 +118,7 @@ struct stm32_qspi {
 
 	u32 cr_reg;
 	u32 dcr_reg;
+	u16 status_timeout;
 
 	/*
 	 * to protect device configuration, could be different between
@@ -128,11 +132,20 @@ static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
 	struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
 	u32 cr, sr;
 
+	cr = readl_relaxed(qspi->io_base + QSPI_CR);
 	sr = readl_relaxed(qspi->io_base + QSPI_SR);
 
+	if (cr & CR_SMIE && sr & SR_SMF) {
+		/* disable irq */
+		cr &= ~CR_SMIE;
+		writel_relaxed(cr, qspi->io_base + QSPI_CR);
+		complete(&qspi->match_completion);
+
+		return IRQ_HANDLED;
+	}
+
 	if (sr & (SR_TEF | SR_TCF)) {
 		/* disable irq */
-		cr = readl_relaxed(qspi->io_base + QSPI_CR);
 		cr &= ~CR_TCIE & ~CR_TEIE;
 		writel_relaxed(cr, qspi->io_base + QSPI_CR);
 		complete(&qspi->data_completion);
@@ -319,6 +332,24 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi,
 	return err;
 }
 
+static int stm32_qspi_wait_poll_status(struct stm32_qspi *qspi,
+				       const struct spi_mem_op *op)
+{
+	u32 cr;
+
+	reinit_completion(&qspi->match_completion);
+	cr = readl_relaxed(qspi->io_base + QSPI_CR);
+	writel_relaxed(cr | CR_SMIE, qspi->io_base + QSPI_CR);
+
+	if (!wait_for_completion_timeout(&qspi->match_completion,
+				msecs_to_jiffies(qspi->status_timeout)))
+		return -ETIMEDOUT;
+
+	writel_relaxed(FCR_CSMF, qspi->io_base + QSPI_FCR);
+
+	return 0;
+}
+
 static int stm32_qspi_get_mode(struct stm32_qspi *qspi, u8 buswidth)
 {
 	if (buswidth == 4)
@@ -332,7 +363,7 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
 	struct stm32_qspi_flash *flash = &qspi->flash[mem->spi->chip_select];
 	u32 ccr, cr;
-	int timeout, err = 0;
+	int timeout, err = 0, err_poll_status = 0;
 
 	dev_dbg(qspi->dev, "cmd:%#x mode:%d.%d.%d.%d addr:%#llx len:%#x\n",
 		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
@@ -378,6 +409,9 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 	if (op->addr.nbytes && qspi->fmode != CCR_FMODE_MM)
 		writel_relaxed(op->addr.val, qspi->io_base + QSPI_AR);
 
+	if (qspi->fmode == CCR_FMODE_APM)
+		err_poll_status = stm32_qspi_wait_poll_status(qspi, op);
+
 	err = stm32_qspi_tx(qspi, op);
 
 	/*
@@ -387,7 +421,7 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 	 *  byte of device (device size - fifo size). like device size is not
 	 *  knows, the prefetching is always stop.
 	 */
-	if (err || qspi->fmode == CCR_FMODE_MM)
+	if (err || err_poll_status || qspi->fmode == CCR_FMODE_MM)
 		goto abort;
 
 	/* wait end of tx in indirect mode */
@@ -406,15 +440,43 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
 						    cr, !(cr & CR_ABORT), 1,
 						    STM32_ABT_TIMEOUT_US);
 
-	writel_relaxed(FCR_CTCF, qspi->io_base + QSPI_FCR);
+	writel_relaxed(FCR_CTCF | FCR_CSMF, qspi->io_base + QSPI_FCR);
 
-	if (err || timeout)
-		dev_err(qspi->dev, "%s err:%d abort timeout:%d\n",
-			__func__, err, timeout);
+	if (err || err_poll_status || timeout)
+		dev_err(qspi->dev, "%s err:%d err_poll_status:%d abort timeout:%d\n",
+			__func__, err, err_poll_status, timeout);
 
 	return err;
 }
 
+static int stm32_qspi_poll_status(struct spi_mem *mem, const struct spi_mem_op *op,
+				  u8 mask, u8 match, u16 timeout_ms)
+{
+	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
+	int ret;
+
+	ret = pm_runtime_get_sync(qspi->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(qspi->dev);
+		return ret;
+	}
+
+	mutex_lock(&qspi->lock);
+
+	writel_relaxed(mask, qspi->io_base + QSPI_PSMKR);
+	writel_relaxed(match, qspi->io_base + QSPI_PSMAR);
+	qspi->fmode = CCR_FMODE_APM;
+	qspi->status_timeout = timeout_ms;
+
+	ret = stm32_qspi_send(mem, op);
+	mutex_unlock(&qspi->lock);
+
+	pm_runtime_mark_last_busy(qspi->dev);
+	pm_runtime_put_autosuspend(qspi->dev);
+
+	return ret;
+}
+
 static int stm32_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
 {
 	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
@@ -527,7 +589,7 @@ static int stm32_qspi_setup(struct spi_device *spi)
 	flash->presc = presc;
 
 	mutex_lock(&qspi->lock);
-	qspi->cr_reg = 3 << CR_FTHRES_SHIFT | CR_SSHIFT | CR_EN;
+	qspi->cr_reg = CR_APMS | 3 << CR_FTHRES_SHIFT | CR_SSHIFT | CR_EN;
 	writel_relaxed(qspi->cr_reg, qspi->io_base + QSPI_CR);
 
 	/* set dcr fsize to max address */
@@ -607,6 +669,7 @@ static const struct spi_controller_mem_ops stm32_qspi_mem_ops = {
 	.exec_op	= stm32_qspi_exec_op,
 	.dirmap_create	= stm32_qspi_dirmap_create,
 	.dirmap_read	= stm32_qspi_dirmap_read,
+	.poll_status	= stm32_qspi_poll_status,
 };
 
 static int stm32_qspi_probe(struct platform_device *pdev)
@@ -661,6 +724,7 @@ static int stm32_qspi_probe(struct platform_device *pdev)
 	}
 
 	init_completion(&qspi->data_completion);
+	init_completion(&qspi->match_completion);
 
 	qspi->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(qspi->clk)) {
-- 
2.17.1



From nm at ti.com  Mon Apr 26 15:47:08 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 09:47:08 -0500
Subject: [PATCH v2] soc: ti: smartreflex after the relocation to maintain
 consistency
In-Reply-To: <1619090212-103038-1-git-send-email-yang.lee@linux.alibaba.com>
References: <1619090212-103038-1-git-send-email-yang.lee@linux.alibaba.com>
Message-ID: <20210426144708.3r3h4csg6wywyude@italics>

On 19:16-20210422, Yang Li wrote:
> v2: According to Nishanth Menon's suggestion, the subject has been 
> corrected.
> https://lore.kernel.org/patchwork/patch/1383883/

The above does'nt belong to commit message. it should probably be posted
in diffstat section.

will also be good to rebase once 5.13-rc1 is out.
> 
> Fix the following coccicheck warning:
> ./drivers/soc/ti/smartreflex.c:820:0-23: WARNING: pm_sr_fops should be
> defined with DEFINE_DEBUGFS_ATTRIBUTE
> 
> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
> Reviewed-by: Nishanth Menon <nm at ti.com>
> ---
>  drivers/soc/ti/smartreflex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
> index 5376f3d..b3c7460 100644
> --- a/drivers/soc/ti/smartreflex.c
> +++ b/drivers/soc/ti/smartreflex.c
> @@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
>  	return 0;
>  }
>  
> -DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
> +DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
>  			omap_sr_autocomp_store, "%llu\n");
>  
>  static int omap_sr_probe(struct platform_device *pdev)
> -- 
> 1.8.3.1
> 

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


From marex at denx.de  Mon Apr 26 16:00:12 2021
From: marex at denx.de (Marek Vasut)
Date: Mon, 26 Apr 2021 17:00:12 +0200
Subject: [PATCH 1/2] ARM: dts: stm32: Remove extra size-cells
Message-ID: <20210426150013.121406-1-marex@denx.de>

Fix make dtbs_check warning:
arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys-polled: '#address-cells' is a dependency of '#size-cells'
arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: gpio-keys: '#address-cells' is a dependency of '#size-cells'

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at st.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: Patrick Delaunay <patrick.delaunay at st.com>
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org

Signed-off-by: Marek Vasut <marex at denx.de>
---
 arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
index 5523f4138fd6..0fbf9913e8df 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
@@ -34,7 +34,6 @@ display_bl: display-bl {
 
 	gpio-keys-polled {
 		compatible = "gpio-keys-polled";
-		#size-cells = <0>;
 		poll-interval = <20>;
 
 		/*
@@ -60,7 +59,6 @@ button-2 {
 
 	gpio-keys {
 		compatible = "gpio-keys";
-		#size-cells = <0>;
 
 		button-1 {
 			label = "TA2-GPIO-B";
-- 
2.30.2



From marex at denx.de  Mon Apr 26 16:00:13 2021
From: marex at denx.de (Marek Vasut)
Date: Mon, 26 Apr 2021 17:00:13 +0200
Subject: [PATCH 2/2] ARM: dts: stm32: Fix touchscreen node
In-Reply-To: <20210426150013.121406-1-marex@denx.de>
References: <20210426150013.121406-1-marex@denx.de>
Message-ID: <20210426150013.121406-2-marex@denx.de>

Fix make dtbs_check warning:
arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml:0:0: /soc/i2c at 40015000/polytouch at 38: failed to match any schema with compatible: ['edt,edt-ft5x06']

Signed-off-by: Marek Vasut <marex at denx.de>
Cc: Alexandre Torgue <alexandre.torgue at st.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: Patrick Delaunay <patrick.delaunay at st.com>
Cc: linux-stm32 at st-md-mailman.stormreply.com
To: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
index 0fbf9913e8df..b8c8f0b284c3 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-pdk2.dtsi
@@ -182,8 +182,8 @@ sgtl5000_rx_endpoint: endpoint at 1 {
 
 	};
 
-	polytouch at 38 {
-		compatible = "edt,edt-ft5x06";
+	touchscreen at 38 {
+		compatible = "edt,edt-ft5406";
 		reg = <0x38>;
 		interrupt-parent = <&gpiog>;
 		interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO E */
-- 
2.30.2



From gregkh at linuxfoundation.org  Mon Apr 26 16:11:31 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 26 Apr 2021 17:11:31 +0200
Subject: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
In-Reply-To: <20210427002648.22459fa7@elm.ozlabs.ibm.com>
References: <YIa2ErYuJyCfSkS+@kroah.com>
 <20210427002648.22459fa7@elm.ozlabs.ibm.com>
Message-ID: <YIbYI2825E4Z2b/3@kroah.com>

On Tue, Apr 27, 2021 at 12:26:48AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 26 Apr 2021 14:46:10 +0200 Greg KH <gregkh at linuxfoundation.org> wrote:
> >
> > All of these have been in linux-next for a while with no reported
> > issues.
> 
> There was just these:
> 
> https://lore.kernel.org/linux-next/20210329165525.32d51a3a at canb.auug.org.au/
> 
> https://lore.kernel.org/linux-next/20210331175151.67fcfe4d at canb.auug.org.au/
> 
> (the scmi tree commit mentioned in the latter is now in the arm-soc tree)
> 
> Not issues as such, but worth mentioning the conflicts and resolutions.

Yeah, merge issues with other trees are hard to resolve in the single
tree here, not much I can just yet, have to wait for them to hit Linus's
tree.

thanks,

greg k-h


From khilman at baylibre.com  Mon Apr 26 16:18:53 2021
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 26 Apr 2021 08:18:53 -0700
Subject: [PATCH] serial: meson: remove redundant initialization of
 variable id
In-Reply-To: <20210426101106.9122-1-colin.king@canonical.com>
References: <20210426101106.9122-1-colin.king@canonical.com>
Message-ID: <7hwnspysyq.fsf@baylibre.com>

Colin King <colin.king at canonical.com> writes:

> From: Colin Ian King <colin.king at canonical.com>
>
> The variable id being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed. Since id is just being used in a for-loop
> inside a local scope, move the declaration of id to that scope.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>

Reviewed-by: Kevin Hilman <khilman at baylibre.com>

> ---
>  drivers/tty/serial/meson_uart.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index 529cd0289056..d7f55031b2cf 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -716,12 +716,13 @@ static int meson_uart_probe(struct platform_device *pdev)
>  	struct resource *res_mem, *res_irq;
>  	struct uart_port *port;
>  	int ret = 0;
> -	int id = -1;
>  
>  	if (pdev->dev.of_node)
>  		pdev->id = of_alias_get_id(pdev->dev.of_node, "serial");
>  
>  	if (pdev->id < 0) {
> +		int id;
> +
>  		for (id = AML_UART_PORT_OFFSET; id < AML_UART_PORT_NUM; id++) {
>  			if (!meson_ports[id]) {
>  				pdev->id = id;
> -- 
> 2.30.2


From wangkefeng.wang at huawei.com  Mon Apr 26 16:26:38 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Mon, 26 Apr 2021 23:26:38 +0800
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <YIZNq5HMfJ1rWytv@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
Message-ID: <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>


On 2021/4/26 13:20, Mike Rapoport wrote:
> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>
>>      On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>
>>          I tested this patchset(plus arm32 change, like arm64 does) based on lts
>>          5.10?add
>>
>>          some debug log, the useful info shows below, if we enable HOLES_IN_ZONE, no
>>          panic,
>>
>>          any idea, thanks.
>>
>>
>>      Are there any changes on top of 5.10 except for pfn_valid() patch?
>>      Do you see this panic on 5.10 without the changes?
>>
>> Yes, there are some BSP support for arm board based on 5.10, with or without
>>
>> your patch will get same panic, the panic pfn=de600 in the range of
>> [dcc00,de00]
>>
>> which is freed by free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700,
>> de700000
>>
>> we see the PC is at PageLRU, same reason like arm64 panic log,
>>
>>     "PageBuddy in move_freepages returns false
>>      Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>>      compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>>      resturns 0xfffffffffffffffe - and accessing this address causes crash"
>>
>>      Can you see stack backtrace beyond move_freepages_block?
>>
>> I do some oom test, so the log is about memory allocate,
>>
>> [<c02383c8>] (move_freepages_block) from [<c0238668>]
>> (steal_suitable_fallback+0x174/0x1f4)
>>
>> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
> Hmm, this is called with a page from free list, having a page from a freed
> part of the memory map passed to steal_suitable_fallback() means that there
> is an issue with creation of the free list.
>
> Can you please add "memblock=debug" to the kernel command line and post the
> log?

Here is the log,

CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d

CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: HISI-CA9
memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
Malformed early option 'vecpage_wrprotect'
Memory policy: Data cache writealloc
memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
MEMBLOCK configuration:
 ?memory size = 0x4c0fffff reserved size = 0x027ef058
 ?memory.cnt? = 0xa
 ?memory[0x0]??? [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
 ?memory[0x1]??? [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
 ?memory[0x2]??? [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
 ?memory[0x3]??? [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
 ?memory[0x4]??? [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
 ?memory[0x5]??? [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
 ?memory[0x6]??? [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
 ?memory[0x7]??? [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
 ?memory[0x8]??? [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
 ?memory[0x9]??? [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
 ?reserved.cnt? = 0x4
 ?reserved[0x0]??? [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
 ?reserved[0x1]??? [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
 ?reserved[0x2]??? [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
 ?reserved[0x3]??? [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
memblock_alloc_try_nid: 2097152 bytes align=0x200000 nid=-1 
from=0x00000000 max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xb0000000-0xb01fffff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xaffff000-0xafffffff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 40 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 iotable_init+0x34/0xf0
memblock_reserve: [0xafffefd8-0xafffefff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffd000-0xafffdfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffc000-0xafffcfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffb000-0xafffbfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 early_alloc+0x20/0x4c
memblock_reserve: [0xafffa000-0xafffafff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 384 bytes align=0x20 nid=0 from=0x00000000 
max_addr=0x00000000 sparse_init_nid+0x34/0x1d8
memblock_reserve: [0xafffee40-0xafffefbf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_exact_nid_raw: 12582912 bytes align=0x80000 nid=0 
from=0xc09fffff max_addr=0x00000000 sparse_init_nid+0xec/0x1d8
memblock_reserve: [0xaf380000-0xaff7ffff] 
memblock_alloc_range_nid+0x104/0x13c
Zone ranges:
 ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
 ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
Movable zone start for each node
Early memory node ranges
 ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
 ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
 ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
 ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
 ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
 ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
 ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
 ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
 ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
 ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
Zeroed struct page in unavailable ranges: 513 pages
Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
On node 0 totalpages: 311551
 ? Normal zone: 1230 pages used for memmap
 ? Normal zone: 0 pages reserved
 ? Normal zone: 157440 pages, LIFO batch:31
 ? HighMem zone: 154111 pages, LIFO batch:31
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffee20-0xafffee3f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffee00-0xafffee1f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffede0-0xafffedff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffedc0-0xafffeddf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffeda0-0xafffedbf] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed80-0xafffed9f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed60-0xafffed7f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed40-0xafffed5f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed20-0xafffed3f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 32 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_arch+0x440/0x5c4
memblock_reserve: [0xafffed00-0xafffed1f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 22396 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 early_init_dt_alloc_memory_arch+0x30/0x64
memblock_reserve: [0xafff4884-0xafff9fff] 
memblock_alloc_range_nid+0x104/0x13c
[dts]:cpu type is 1380
memblock_alloc_try_nid: 404 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc.constprop.8+0x1c/0x24
memblock_reserve: [0xafffeb60-0xafffecf3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 404 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc.constprop.8+0x1c/0x24
memblock_reserve: [0xafffe9c0-0xafffeb53] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff3000-0xafff3fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4096 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff2000-0xafff2fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 278528 bytes align=0x1000 nid=-1 from=0xc09fffff 
max_addr=0x00000000 pcpu_dfl_fc_alloc+0x28/0x34
memblock_reserve: [0xaffae000-0xafff1fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_free: [0xaffbf000-0xaffbefff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xaffd0000-0xaffcffff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xaffe1000-0xaffe0fff] pcpu_embed_first_chunk+0x5ec/0x6a8
memblock_free: [0xafff2000-0xafff1fff] pcpu_embed_first_chunk+0x5ec/0x6a8
percpu: Embedded 17 pages/cpu s37044 r8192 d24396 u69632
memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffefc0-0xafffefc3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 4 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe9a0-0xafffe9a3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 16 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe980-0xafffe98f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 16 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe960-0xafffe96f] 
memblock_alloc_range_nid+0x104/0x13c
pcpu-alloc: s37044 r8192 d24396 u69632 alloc=17*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
memblock_alloc_try_nid: 128 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe8e0-0xafffe95f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 92 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe880-0xafffe8db] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 384 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe700-0xafffe87f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 388 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe560-0xafffe6e3] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 96 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe500-0xafffe55f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 92 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe4a0-0xafffe4fb] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 768 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe1a0-0xafffe49f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 772 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafff4580-0xafff4883] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 192 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 memblock_alloc+0x18/0x20
memblock_reserve: [0xafffe0e0-0xafffe19f] 
memblock_alloc_range_nid+0x104/0x13c
memblock_free: [0xafff3000-0xafff3fff] pcpu_embed_first_chunk+0x570/0x6a8
memblock_free: [0xafff2000-0xafff2fff] pcpu_embed_first_chunk+0x58c/0x6a8
Built 1 zonelists, mobility grouping on.? Total pages: 310321
Kernel command line: console=ttyAMA0,9600n8N lpj=8000000 
initrd=0x83000000,0x2000000 maxcpus=4 master_cpu=1 quiet highres=off? 
oops=panic vecpage_wrprotect ksm=1 ramdisk_size=30720 kmemleak=off 
min_loop=128 lockd.nlm_tcpport=13001 lockd.nlm_udpport=13001 
rdinit=/sbin/init root=/dev/ram0 vmalloc=256M
printk: log_buf_len individual max cpu contribution: 4096 bytes
printk: log_buf_len total cpu_extra contributions: 12288 bytes
printk: log_buf_len min size: 16384 bytes
memblock_alloc_try_nid: 32768 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0xe4/0x404
memblock_reserve: [0xaffa6000-0xaffadfff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 12288 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0x130/0x404
memblock_reserve: [0xaffa3000-0xaffa5fff] 
memblock_alloc_range_nid+0x104/0x13c
memblock_alloc_try_nid: 90112 bytes align=0x4 nid=-1 from=0x00000000 
max_addr=0x00000000 setup_log_buf+0x180/0x404
memblock_reserve: [0xaff8d000-0xaffa2fff] 
memblock_alloc_range_nid+0x104/0x13c
printk: log_buf_len: 32768 bytes
printk: early log buf free: 2492(15%)
memblock_alloc_try_nid: 524288 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 alloc_large_system_hash+0x1b0/0x2e8
memblock_reserve: [0xaf300000-0xaf37ffff] 
memblock_alloc_range_nid+0x104/0x13c
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
memblock_alloc_try_nid: 262144 bytes align=0x20 nid=-1 from=0x00000000 
max_addr=0x00000000 alloc_large_system_hash+0x1b0/0x2e8
memblock_reserve: [0xaf2c0000-0xaf2fffff] 
memblock_alloc_range_nid+0x104/0x13c
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
memblock_free: [0xaf430000-0xaf453fff] mem_init+0x154/0x238
memblock_free: [0xaf510000-0xaf545fff] mem_init+0x154/0x238
memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x154/0x238
memblock_free: [0xafd98000-0xafdcdfff] mem_init+0x154/0x238
memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x154/0x238
memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x154/0x238
memblock_free: [0xafee0000-0xafefffff] mem_init+0x154/0x238
Memory: 1191160K/1246204K available (4096K kernel code, 436K rwdata, 
1120K rodata, 1024K init, 491K bss, 55044K reserved, 0K cma-reserved, 
616444K highmem)

>> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
>> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
>> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
>> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
>> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
>> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
>>
>>
>>
>>          Zone ranges:
>>          ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
>>          ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
>>          Movable zone start for each node
>>          Early memory node ranges
>>          ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
>>          ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>          ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>          ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
>>          ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>          ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>          ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
>>          ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>          ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>          ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
>>
>>          ----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
>>          ----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
>>          ----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
>>          ----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
>>          ----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
>>          ----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
>>          ----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
>>          === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>>          :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>>          8<--- cut here ---
>>          Unable to handle kernel paging request at virtual address fffffffe
>>          pgd = 5dd50df5
>>          [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>>          Internal error: Oops: 37 [#1] SMP ARM
>>          Modules linked in: gmac(O)
>>          CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
>>          Hardware name: Hisilicon A9
>>          PC is at move_freepages_block+0x150/0x278
>>          LR is at move_freepages_block+0x150/0x278
>>          pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
>>          sp : c4179cf8? ip : 00000000? fp : 00000001
>>          r10: c4179d58? r9 : 000de7ff? r8 : 00000000
>>          r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
>>          r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
>>          Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
>>          Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
>>          Process test-oom (pid: 635, stack limit = 0x25d667df)
>>
>>


From ville.syrjala at linux.intel.com  Mon Apr 26 16:33:18 2021
From: ville.syrjala at linux.intel.com (Ville =?iso-8859-1?Q?Syrj=E4l=E4?=)
Date: Mon, 26 Apr 2021 18:33:18 +0300
Subject: [PATCH v2 1/2] gpu: drm: init set panel orientation property
 earlier
In-Reply-To: <20210426051848.2600890-1-hsinyi@chromium.org>
References: <20210426051848.2600890-1-hsinyi@chromium.org>
Message-ID: <YIbdPqolop6cBnYH@intel.com>

On Mon, Apr 26, 2021 at 01:18:47PM +0800, Hsin-Yi Wang wrote:
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev_register(), it will fail several checks and results in following
> warning.
> 
> Create panel orientation property in drm_connector_init()
> and set default value to UNKNOWN. Let the panel set the real value
> later.
> 
> [    4.480976] ------------[ cut here ]------------
> [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> <snip>
> [    4.609772] Call trace:
> [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> [    4.616466]  drm_mode_object_add+0x20/0x2c
> [    4.620552]  drm_property_create+0xdc/0x174
> [    4.624723]  drm_property_create_enum+0x34/0x98
> [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> [    4.634716]  boe_panel_get_modes+0x88/0xd8
> [    4.638802]  drm_panel_get_modes+0x2c/0x48
> [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> [    4.662699]  drm_ioctl_kernel+0xac/0x128
> [    4.666611]  drm_ioctl+0x268/0x410
> [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.678436]  el0_svc_common+0xf4/0x1c0
> [    4.682174]  do_el0_svc_compat+0x28/0x3c
> [    4.686088]  el0_svc_compat+0x10/0x1c
> [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> [    4.694171]  el0_sync_compat+0x178/0x180
> [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> [    4.702721] ------------[ cut here ]------------
> [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> <snip>
> [    4.833830] Call trace:
> [    4.836266]  drm_object_attach_property+0x48/0xb8
> [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> [    4.846432]  boe_panel_get_modes+0x88/0xd8
> [    4.850516]  drm_panel_get_modes+0x2c/0x48
> [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> [    4.874410]  drm_ioctl_kernel+0xac/0x128
> [    4.878320]  drm_ioctl+0x268/0x410
> [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> [    4.890142]  el0_svc_common+0xf4/0x1c0
> [    4.893879]  do_el0_svc_compat+0x28/0x3c
> [    4.897791]  el0_svc_compat+0x10/0x1c
> [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> [    4.905873]  el0_sync_compat+0x178/0x180
> [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
> 
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
> v1:
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
> ---
>  drivers/gpu/drm/drm_connector.c | 28 +++++++++++++++-------------
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..a1acb4af0ef4 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -303,6 +303,10 @@ int drm_connector_init(struct drm_device *dev,
>  				   config->tile_property,
>  				   0);
>  
> +	drm_object_attach_property(&connector->base,
> +				   config->panel_orientation_property,
> +				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
> +

A bit silly to add this to every connector. I think you should just
fix the driver/bridge stuff to set up the orientaion earlier.

>  	if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>  		drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
>  	}
> @@ -1210,7 +1214,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
>   *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
>   *	coordinates, so if userspace rotates the picture to adjust for
>   *	the orientation it must also apply the same transformation to the
> - *	touchscreen input coordinates. This property is initialized by calling
> + *	touchscreen input coordinates. This property value is set by calling
>   *	drm_connector_set_panel_orientation() or
>   *	drm_connector_set_panel_orientation_with_quirk()
>   *
> @@ -1298,6 +1302,14 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
>  		return -ENOMEM;
>  	dev->mode_config.hdr_output_metadata_property = prop;
>  
> +	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> +					"panel orientation",
> +					drm_panel_orientation_enum_list,
> +					ARRAY_SIZE(drm_panel_orientation_enum_list));
> +	if (!prop)
> +		return -ENOMEM;
> +	dev->mode_config.panel_orientation_property = prop;
> +
>  	return 0;
>  }
>  
> @@ -2205,19 +2217,9 @@ int drm_connector_set_panel_orientation(
>  	info->panel_orientation = panel_orientation;
>  
>  	prop = dev->mode_config.panel_orientation_property;
> -	if (!prop) {
> -		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -				"panel orientation",
> -				drm_panel_orientation_enum_list,
> -				ARRAY_SIZE(drm_panel_orientation_enum_list));
> -		if (!prop)
> -			return -ENOMEM;
> -
> -		dev->mode_config.panel_orientation_property = prop;
> -	}
>  
> -	drm_object_attach_property(&connector->base, prop,
> -				   info->panel_orientation);
> +	drm_object_property_set_value(&connector->base, prop,
> +				      info->panel_orientation);
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_connector_set_panel_orientation);
> -- 
> 2.31.1.498.g6c1eba8ee3d-goog
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel


From mathieu.poirier at linaro.org  Mon Apr 26 16:46:23 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 26 Apr 2021 09:46:23 -0600
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <DB6PR0402MB2760EA88942E5549BA9CC4B588459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
 <20210422165634.GD1256950@xps15>
 <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <CANLsYkwoS+3qYq=FHRLMjrJSr5cj_PiHaU+a+M17C+8-VJ+b9g@mail.gmail.com>
 <DB6PR0402MB2760EA88942E5549BA9CC4B588459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
Message-ID: <20210426154623.GA1390475@xps15>

On Fri, Apr 23, 2021 at 11:28:00PM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > i.MX7ULP/8MN/8MP
> > 
> > On Thu, 22 Apr 2021 at 19:01, Peng Fan <peng.fan at nxp.com> wrote:
> > >
> > > Hi Mathieu,
> > >
> > > > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > > > i.MX7ULP/8MN/8MP
> > > >
> > > > On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com
> > wrote:
> > > > > From: Peng Fan <peng.fan at nxp.com>
> > > > >
> > > > > V5:
> > > > >  Add R-b tag
> > > > >  Move the change in detect mode of patch 5 to patch 7 Per
> > > > > Mathieu's comments
> > > > >
> > > > > V4:
> > > > >  Typo fix
> > > > >  patch 4: take state as a check condition  patch 5: move regmap
> > > > > lookup/attach to imx_rproc_detect_mode  patch 6: add
> > > > > imx_rproc_clk_enable for optional clk  patch 8: use switch/case in
> > > > > imx_rproc_detect_mode
> > > > > V3:
> > > > >  Add A-b tag for Patch 1/2
> > > > >  Fix the checkpatch warning for Patch 6,8
> > > > >
> > > > > V2:
> > > > >  Patch 1/8, use fsl as vendor, typo fix  Because patchset [1] has
> > > > > v2 version, patch 5,6,7,8 are adapted that  change.
> > > > >
> > > > > This patchset is to support i.MX7ULP/8MN/8MP, also includes a
> > > > > patch to parse fsl,auto-boot
> > > > >
> > > >
> > > > One of the request I had from the last revision was to explicitly
> > > > list what other patchset this work depends on and what branch it is
> > > > based of, something I can't find here.
> > >
> > > Sorry, that patchset has been merged, so I remove that line.
> > > I should mention that that patchset has been merged into Linux-next tree.
> > >
> > 
> > And what branch this set should be applied to is missing.
> 
> I take latest linux-next/master for my upstream new feature work.
> 
> > 
> > > >
> > > > As such I am dropping this set and won't look at another revision
> > > > before May 22nd.
> > >
> > > Ah. Is it just because that the dependency patchset not been mentioned
> > > or you have issue applying the patchset that delay the patchset for one
> > month?
> > >
> > 
> > Both.
> 
> I replay my flow:
> git fetch linux-next
> git checkout linux-next/master -b master-next-4-24-2021
> pwclient list -w "Peng Fan (OSS)" -s New | grep V5 | awk '{print $1}' | xargs -I {} pwclient git-am {}
> 
> It could successfully apply the patchset.
> Applying patch #12215291 using 'git am'
> Description: [V5,1/8] dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> Applying: dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> Applying patch #12215293 using 'git am'
> Description: [V5,2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> Applying: dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> Applying patch #12215295 using 'git am'
> Description: [V5,3/8] dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> Applying: dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> Applying patch #12215297 using 'git am'
> Description: [V5,4/8] remoteproc: imx_rproc: parse fsl,auto-boot
> Applying: remoteproc: imx_rproc: parse fsl,auto-boot
> Applying patch #12215299 using 'git am'
> Description: [V5,5/8] remoteproc: imx_rproc: initial support for mutilple start/stop method
> Applying: remoteproc: imx_rproc: initial support for mutilple start/stop method
> Applying patch #12215301 using 'git am'
> Description: [V5,6/8] remoteproc: imx_rproc: make clk optional
> Applying: remoteproc: imx_rproc: make clk optional
> Applying patch #12215303 using 'git am'
> Description: [V5,7/8] remoteproc: imx_rproc: support i.MX7ULP
> Applying: remoteproc: imx_rproc: support i.MX7ULP
> Applying patch #12215305 using 'git am'
> Description: [V5,8/8] remoteproc: imx_rproc: support i.MX8MN/P
> Applying: remoteproc: imx_rproc: support i.MX8MN/P
> 
> 
> If anything wrong my work flow conflicts with Linux remoteproc subsystem upstream flow,
> please correct me, and I'll follow.
> 
> Thanks for your time and patience on reviewing my patches. Sorry for the inconvince
> that I bring in.
> 
> Anyway please share me your flow to apply patches, I will try to avoid unhappy things
> in following patches. 
>

All I asked is that you list the branch your work is based on _and_ any
dependencies, something you did not do.

I review hundreds of patchsets every year and knowing exactly how to work with a
series goes a long way in saving precious time, time that can be used to
review other people's submissions.

I am not angry at you but at the same time I can't review your patches if you
are not ready to help me do so.
 
> Thanks,
> Peng.
> 
> > 
> > > Thanks,
> > > Peng.
> > >
> > > >
> > > > > Peng Fan (8):
> > > > >   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> > > > >   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> > > > >   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> > > > >   remoteproc: imx_rproc: parse fsl,auto-boot
> > > > >   remoteproc: imx_rproc: initial support for mutilple start/stop method
> > > > >   remoteproc: imx_rproc: make clk optional
> > > > >   remoteproc: imx_rproc: support i.MX7ULP
> > > > >   remoteproc: imx_rproc: support i.MX8MN/P
> > > > >
> > > > >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
> > > > >  drivers/remoteproc/imx_rproc.c                | 196
> > > > +++++++++++++++---
> > > > >  2 files changed, 173 insertions(+), 34 deletions(-)
> > > > >
> > > > > --
> > > > > 2.30.0
> > > > >


From arnd at kernel.org  Mon Apr 26 16:52:39 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 17:52:39 +0200
Subject: [GIT PULL 0/6] ARM SoC branches for 5.13
Message-ID: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>

Here are six branches for the SoC tree for the 5.13 merge window.
There are a couple
of new SoCs this time, with the initial Apple M1 support being the
most exciting one.
The STM32H750 platform is also noteworthy because it's fairly
unexpected to still
see new MMU-less boards.

The arm-apple-m1-5.13 tag includes changes from the tty and arm64
trees, so it would
be good to merge those first in order to get a neater git history.
Both have been
submitted today by Greg and Catalin.

As usual, the changes are mostly for devicetree files, aside from the
ongoing cleanup
work to omap2 and driver work for tegra and socfpga.  About two thirds
this of the
overall changes this time are for 64-bit machines, which is more than usual but
fits in with the long-term trend.

A few more statistics: There are 863 non-merge commits this time, from 195
authors. These twenty people have done more than ten changes each:

     79 Tony Lindgren
     47 Krzysztof Kozlowski
     38 Cristian Marussi
     28 Vinod Koul
     28 Dmitry Osipenko
     21 Manivannan Sadhasivam
     18 Hector Martin
     18 Geert Uytterhoeven
     18 Dong Aisheng
     18 Arnd Bergmann
     17 Sai Prakash Ranjan
     17 Rafa? Mi?ecki
     15 Jagan Teki
     12 Stephen Boyd
     12 Nicolas Saenz Julienne
     11 Linus Walleij
     11 Jonathan Neusch?fer
     11 Heiko Stuebner
     11 Eddie James
     11 Chunfeng Yun

This is the total diffstat:

   0.6% Documentation/devicetree/bindings/arm/
   0.2% Documentation/devicetree/bindings/interrupt-controller/
   0.3% Documentation/devicetree/bindings/memory-controllers/
   0.2% Documentation/devicetree/bindings/mfd/
   0.2% Documentation/devicetree/bindings/
   1.6% Documentation/driver-api/
  23.1% arch/arm/boot/dts/
   0.5% arch/arm/configs/
   4.8% arch/arm/mach-omap2/
   1.2% arch/arm/
   0.2% arch/arm64/boot/dts/allwinner/
   0.8% arch/arm64/boot/dts/amlogic/
   0.3% arch/arm64/boot/dts/apple/
   0.5% arch/arm64/boot/dts/broadcom/bcm4908/
   8.1% arch/arm64/boot/dts/freescale/
   0.6% arch/arm64/boot/dts/intel/
   0.4% arch/arm64/boot/dts/marvell/
   3.1% arch/arm64/boot/dts/mediatek/
  14.4% arch/arm64/boot/dts/qcom/
   2.3% arch/arm64/boot/dts/renesas/
   0.8% arch/arm64/boot/dts/rockchip/
   8.3% arch/arm64/boot/dts/ti/
   0.2% arch/arm64/include/asm/
   0.2% arch/arm64/
   0.2% drivers/bus/
   0.4% drivers/clk/
   0.3% drivers/cpufreq/
   9.2% drivers/firmware/arm_scmi/
   0.6% drivers/firmware/
   1.7% drivers/iio/common/scmi_sensors/
   2.1% drivers/irqchip/
   1.2% drivers/memory/tegra/
   0.5% drivers/pwm/
   0.9% drivers/soc/fsl/qe/
   2.5% drivers/soc/mediatek/
   0.5% drivers/soc/qcom/
   0.5% drivers/soc/tegra/
   0.3% drivers/soc/
   0.4% drivers/tty/serial/
   1.2% drivers/
   1.3% include/linux/
   0.2% include/soc/
   0.2% include/
 774 files changed, 35247 insertions(+), 8091 deletions(-)


From arnd at kernel.org  Mon Apr 26 16:53:31 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 17:53:31 +0200
Subject: [GIT PULL 1/6] ARM: SoC changes for v5.13
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a08ONpuYxcNOOr1Yr04SYosAPKH+i=PPp9h0hvhknn+Mg@mail.gmail.com>

The following changes since commit 4c9f4865f4604744d4f1a43db22ac6ec9dc8e587:

  Merge branch 'fixes-rc2' into fixes (2021-03-08 11:34:12 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-soc-5.13

for you to fetch changes up to d92e5e32fb4fce7ae939ad322aad77955dd5dcda:

  Merge tag 'arm-soc/for-5.13/maintainers' of
https://github.com/Broadcom/stblinux into arm/soc (2021-04-09 21:48:03
+0200)

----------------------------------------------------------------
ARM: SoC changes for v5.13

Almost all SoC code changes this time are for the TI OMAP
platform, which continues its decade-long quest to move from
describing a complex SoC in code to device tree.

Aside from this, the Uniphier platform has a new maintainer
and some platforms have minor bugfixes and cleanups that were
not urgent enough for v5.12.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Aditya Srivastava (2):
      ARM: OMAP2+: fix incorrect kernel-doc comment syntax in file
      ARM: OMAP1: fix incorrect kernel-doc comment syntax in file

Arnd Bergmann (7):
      Merge tag 'omap-for-v5.13/genpd-cleanup-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/soc
      Merge tag 'imx-soc-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/soc
      Merge tag 'at91-soc-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/soc
      Merge tag 'hisi-armv7soc-for-5.13' of
git://github.com/hisilicon/linux-hisi into arm/soc
      Merge tag 'omap-for-v5.13/soc-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/soc
      Merge tag 'samsung-soc-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/soc
      Merge tag 'arm-soc/for-5.13/maintainers' of
https://github.com/Broadcom/stblinux into arm/soc

Ben Dooks (1):
      ARM: ux500: make ux500_cpu_die static

Bhaskar Chowdhury (1):
      ARM: mach-imx: Fix a spelling in the file pm-imx5.c

Hao Fang (1):
      ARM: hisi: use the correct HiSilicon copyright

Jiapeng Chong (1):
      ARM: OMAP2+: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE

Krzysztof Kozlowski (2):
      MAINTAINERS: use Krzysztof Kozlowski's Canonical address
      ARM: exynos: correct kernel doc in platsmp

Kunihiko Hayashi (1):
      MAINTAINERS: Update ARM/UniPhier SoCs maintainers and status

Lee Jones (1):
      ARM: at91: pm: Move prototypes to mutually included header

Lifu Chen (1):
      ARM: OMAP2+: Use DEFINE_SPINLOCK() for spinlock

Nicolas Saenz Julienne (2):
      MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
      mailmap: Update email address for Nicolas Saenz

Nobuhiro Iwamatsu (1):
      ARM: imx: Kconfig: Fix typo in help

Tony Lindgren (81):
      bus: ti-sysc: Fix initializing module_pa for modules without sysc register
      bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first
      bus: ti-sysc: Detect more modules for debugging
      bus: ti-sysc: Check for old incomplete dtb
      ARM: OMAP2+: Init both prm and prcm nodes early for clocks
      soc: ti: omap-prm: Allow hardware supported retention when idle
      clk: ti: omap5: Add missing gpmc and ocmc clkctrl
      PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver
      ARM: dts: Update pcie ranges for dra7
      ARM: dts: Configure interconnect target module for dra7 pcie
      ARM: dts: Properly configure dra7 edma sysconfig registers
      ARM: OMAP2+: Drop legacy platform data for dra7 pcie
      ARM: dts: Move dra7 l3 noc to a separate node
      ARM: OMAP2+: Drop legacy platform data for dra7 qspi
      ARM: dts: Configure interconnect target module for dra7 qspi
      ARM: OMAP2+: Drop legacy platform data for dra7 sata
      ARM: dts: Configure interconnect target module for dra7 sata
      ARM: OMAP2+: Drop legacy platform data for dra7 mpu
      ARM: dts: Configure interconnect target module for dra7 mpu
      ARM: OMAP2+: Drop legacy platform data for dra7 dmm
      ARM: dts: Configure interconnect target module for dra7 dmm
      ARM: OMAP2+: Drop legacy platform data for dra7 l4_wkup
      ARM: dts: Configure simple-pm-bus for dra7 l4_wkup
      ARM: OMAP2+: Drop legacy platform data for dra7 l4_per1
      ARM: dts: Configure simple-pm-bus for dra7 l4_per1
      ARM: OMAP2+: Drop legacy platform data for dra7 l4_per2
      ARM: dts: Configure simple-pm-bus for dra7 l4_per2
      ARM: OMAP2+: Drop legacy platform data for dra7 l4_per3
      ARM: dts: Configure simple-pm-bus for dra7 l4_per3
      ARM: OMAP2+: Drop legacy platform data for dra7 l4_cfg
      ARM: dts: Configure simple-pm-bus for dra7 l4_cfg
      ARM: OMAP2+: Drop legacy platform data for dra7 l3
      ARM: dts: Configure simple-pm-bus for dra7 l3
      ARM: OMAP2+: Drop legacy platform data for dra7 hwmod
      ARM: dts: Configure power-domain for omap4 gfx
      ARM: dts: Configure power-domain for omap4 dts iss
      ARM: dts: Configure interconnect target module for omap4 dmm
      ARM: dts: Configure interconnect target module for omap4 emif
      ARM: dts: Configure interconnect target module for omap4 debugss
      ARM: dts: Configure interconnect target module for omap4 mpu
      ARM: dts: Move omap4 mmio-sram out of l3 interconnect
      ARM: dts: Move omap4 l3-noc to a separate node
      ARM: dts: Configure simple-pm-bus for omap4 l4_wkup
      ARM: dts: Configure simple-pm-bus for omap4 l4_per
      ARM: dts: Configure simple-pm-bus for omap4 l4_cfg
      ARM: OMAP2+: Drop legacy platform data for omap4 iss
      ARM: OMAP2+: Drop legacy platform data for omap4 control modules
      ARM: dts: Prepare for simple-pm-bus for omap4 l3
      ARM: OMAP2+: Drop legacy platform data for omap4 dmm
      ARM: OMAP2+: Drop legacy platform data for omap4 emif
      ARM: OMAP2+: Drop legacy platform data for omap4 debugss
      ARM: OMAP2+: Drop legacy platform data for omap4 mpu
      ARM: OMAP2+: Drop legacy platform data for omap4 l4_wkup
      ARM: OMAP2+: Drop legacy platform data for omap4 l4_per
      ARM: OMAP2+: Drop legacy platform data for omap4 l4_cfg
      ARM: OMAP2+: Drop legacy platform data for omap4 l3
      ARM: OMAP2+: Drop legacy platform data for omap4 hwmod
      ARM: dts: Configure interconnect target module for omap5 dmm
      ARM: dts: Configure interconnect target module for omap5 emif
      ARM: dts: Configure interconnect target module for omap5 mpu
      ARM: dts: Configure interconnect target module for omap5 gpmc
      ARM: dts: Configure interconnect target module for omap5 sata
      ARM: dts: Move omap5 mmio-sram out of l3 interconnect
      ARM: dts: Move omap5 l3-noc to a separate node
      ARM: dts: Configure simple-pm-bus for omap5 l4_wkup
      ARM: dts: Configure simple-pm-bus for omap5 l4_per
      ARM: dts: Configure simple-pm-bus for omap5 l4_cfg
      ARM: dts: Configure simple-pm-bus for omap5 l3
      ARM: OMAP2+: Drop legacy platform data for omap5 dmm
      ARM: OMAP2+: Drop legacy platform data for omap5 emif
      ARM: OMAP2+: Drop legacy platform data for omap5 mpu
      ARM: OMAP2+: Drop legacy platform data for omap5 sata
      ARM: OMAP2+: Drop legacy platform data for omap5 l4_wkup
      ARM: OMAP2+: Drop legacy platform data for omap5 l4_per
      ARM: OMAP2+: Drop legacy platform data for omap5 l4_cfg
      ARM: OMAP2+: Drop legacy platform data for omap5 l3
      ARM: OMAP2+: Drop legacy platform data for omap5 hwmod
      Merge tags 'genpd-dts-dra7', 'genpd-dts-omap4' and
'genpd-dts-omap5' into omap-for-v5.13/dts-genpd
      Merge branches 'omap-for-v5.13/genpd-dra7',
'omap-for-v5.13/genpd-omap4' and 'omap-for-v5.13/genpd-omap5' into
omap-for-v5.13/genpd-drop-legacy
      ARM: OMAP2+: Stop building legacy code for dra7 and omap4/5
      bus: ti-sysc: Warn about old dtb for dra7 and omap4/5

Uwe Kleine-K?nig (1):
      ARM: s3c: Use pwm_get() in favour of pwm_request() in RX1950

Yang Li (2):
      ARM: OMAP2+: add missing call to of_node_put()
      ARM: OMAP2+: use true and false for bool variable

 .mailmap                                   |   2 +
 MAINTAINERS                                |  30 +-
 arch/arm/boot/dts/dra7-l4.dtsi             |  75 ++-
 arch/arm/boot/dts/dra7.dtsi                | 220 +++++---
 arch/arm/boot/dts/omap4-l4.dtsi            |  43 +-
 arch/arm/boot/dts/omap4.dtsi               | 169 ++++--
 arch/arm/boot/dts/omap4460.dtsi            |  13 +-
 arch/arm/boot/dts/omap5-l4.dtsi            |  67 ++-
 arch/arm/boot/dts/omap5.dtsi               | 204 ++++---
 arch/arm/mach-at91/pm.c                    |  19 +-
 arch/arm/mach-exynos/platsmp.c             |  28 +-
 arch/arm/mach-hisi/hisilicon.c             |   4 +-
 arch/arm/mach-hisi/hotplug.c               |   2 +-
 arch/arm/mach-hisi/platmcpm.c              |   2 +-
 arch/arm/mach-hisi/platsmp.c               |   2 +-
 arch/arm/mach-imx/Kconfig                  |   2 +-
 arch/arm/mach-imx/pm-imx5.c                |   2 +-
 arch/arm/mach-omap1/timer.c                |   2 +-
 arch/arm/mach-omap2/Kconfig                |   3 -
 arch/arm/mach-omap2/Makefile               |  11 +-
 arch/arm/mach-omap2/common.h               |   9 -
 arch/arm/mach-omap2/io.c                   |  12 +-
 arch/arm/mach-omap2/omap_hwmod.c           |   9 +-
 arch/arm/mach-omap2/omap_hwmod.h           |  14 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 877 -----------------------------
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 467 ---------------
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 719 -----------------------
 arch/arm/mach-omap2/omap_twl.c             |   2 +-
 arch/arm/mach-omap2/pdata-quirks.c         |  31 +-
 arch/arm/mach-omap2/pm-debug.c             |   4 +-
 arch/arm/mach-omap2/powerdomain.c          |  12 +-
 arch/arm/mach-omap2/sr_device.c            |   7 +
 arch/arm/mach-s3c/mach-rx1950.c            |  11 +-
 arch/arm/mach-ux500/platsmp.c              |   2 +-
 arch/arm/plat-omap/dma.c                   |   3 +-
 drivers/bus/ti-sysc.c                      |  81 ++-
 drivers/clk/ti/clk-54xx.c                  |   2 +
 drivers/pci/controller/dwc/pci-dra7xx.c    |  13 +-
 drivers/pinctrl/pinctrl-at91.c             |   2 +
 drivers/soc/ti/omap_prm.c                  |  16 +-
 include/dt-bindings/clock/omap5.h          |   2 +
 include/soc/at91/pm.h                      |  16 +
 42 files changed, 758 insertions(+), 2453 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 delete mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c
 delete mode 100644 arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 create mode 100644 include/soc/at91/pm.h


From arnd at kernel.org  Mon Apr 26 16:54:30 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 17:54:30 +0200
Subject: [GIT PULL 2/6] ARM: defconfigs for v5.13
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a0WbrYBeR_VMBDfgC9R7aVXna26_LQjdHrd2xnN9e6_Cg@mail.gmail.com>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-defconfig-5.13

for you to fetch changes up to 028a1e968435383c9555fc9386d116688f31dfce:

  Merge tag 'qcom-defconfig-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/defconfig (2021-04-19 17:39:12 +0200)

----------------------------------------------------------------
ARM: defconfigs for v5.13

The usual set of defconfig updates, enabling newly added drivers.
There are platform updates for at91, omap, ux500 and qcom platforms,
and a number of changes to the arm64 defconfig.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Adam Ford (1):
      ARM: omap2plus_defconfig: Add AT25 EEPROM module

Adrien Grassein (1):
      arm64: defconfig: Enable wm8960 audio driver.

Arnd Bergmann (8):
      Merge tag 'renesas-arm-defconfig-for-v5.13-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into
arm/defconfig
      Merge tag 'arm64_defconfig_for_v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into
arm/defconfig
      Merge tag 'imx-defconfig-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/defconfig
      Merge tag 'v5.12-next-defconfig' of
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into
arm/defconfig
      Merge tag 'at91-defconfig-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into
arm/defconfig
      Merge tag 'qcom-arm64-defconfig-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/defconfig
      Merge tag 'omap-for-v5.13/defconfig-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/defconfig
      Merge tag 'qcom-defconfig-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/defconfig

Bjorn Andersson (1):
      arm64: defconfig: Enable Qualcomm SM8350 TLMM and GCC

Codrin Ciubotariu (1):
      ARM: configs: at91: sama5: Add audio MIKROE PROTO board

Dong Aisheng (1):
      arm64: defconfig: add imx8qm pinctrl support

Emil Velikov (2):
      ARM: configs: at91: sama5: update with savedefconfig
      ARM: configs: at91: sama5: enable the Hantro G1 engine

Enric Balletbo i Serra (2):
      arm64: defconfig: Allow mt8173-based boards to boot from usb
      arm64: defconfig: Enable options to support panel display for
Mediatek Chromebooks

Fabio Estevam (2):
      arm64: defconfig: Enable the Hantro decoder
      arm64: configs: Select REALTEK_PHY as built-in

Geert Uytterhoeven (1):
      ARM: shmobile: defconfig: Refresh for v5.12-rc2

Guido G?nther (2):
      arm64: defconfig: Enable devfreq support for i.MX8MQ
      arm64: defconfig: Enable asoc simple mux

Heiko Thiery (1):
      arm64: configs: Enable PCIe support for imx8mq boards

Ivan Jelincic (2):
      ARM: omap2plus_defconfig: Update for dropped simple-pm-bus
      ARM: omap2plus_defconfig: Enable Netfilter components as modules

Krzysztof Kozlowski (1):
      arm64: defconfig: enable Intel's eASIC N5X SoCFPGA and Keem Bay SoC

Linus Walleij (1):
      ARM: configs: ux500: Update for new drivers

Manivannan Sadhasivam (7):
      ARM: configs: qcom_defconfig: Enable APCS IPC mailbox driver
      ARM: configs: qcom_defconfig: Enable SDX55 A7 PLL and APCS clock driver
      ARM: configs: qcom_defconfig: Enable CPUFreq support
      ARM: configs: qcom_defconfig: Enable Q6V5_PAS remoteproc driver
      ARM: configs: qcom_defconfig: Enable SDX55 interconnect driver
      ARM: configs: qcom_defconfig: Enable GLINK SMEM driver
      ARM: configs: qcom_defconfig: Reduce CMA size to 64MB

Mark Brown (1):
      ARM: configs: Remove REGULATOR_USERSPACE_CONSUMER

Michael Walle (1):
      arm64: configs: enable FlexTimer alarm timer

Nicolas Ferre (4):
      ARM: configs: at91: sama5: MCP16502 regulator as built-in
      ARM: configs: at91: Add mtd tests as modules
      ARM: configs: at91: Add USB Video webcam class
      ARM: configs: at91: Modernize UBI defconfig part

Razvan Stefanescu (2):
      ARM: configs: at91: sama5: PIOBU as built-in
      ARM: configs: at91: sama5: Enable LAN78XX as module

 arch/arm/configs/at91_dt_defconfig   |   5 +-
 arch/arm/configs/ezx_defconfig       |   1 -
 arch/arm/configs/imote2_defconfig    |   1 -
 arch/arm/configs/omap2plus_defconfig | 151 ++++++++++++++++++++++++++++++++++-
 arch/arm/configs/pxa_defconfig       |   1 -
 arch/arm/configs/qcom_defconfig      |  10 ++-
 arch/arm/configs/sama5_defconfig     |  51 +++++++-----
 arch/arm/configs/shmobile_defconfig  |   1 -
 arch/arm/configs/u8500_defconfig     |  14 ++++
 arch/arm64/configs/defconfig         |  35 +++++++-
 10 files changed, 240 insertions(+), 30 deletions(-)


From nm at ti.com  Mon Apr 26 16:54:53 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 10:54:53 -0500
Subject: [PATCH V2 0/4] dt-bindings: soc/arm: Convert pending ti,
 sci* bindings to json format
Message-ID: <20210426155457.21221-1-nm@ti.com>

Hi,

V2 of the series posted in [1] to convert the remaining ti,sci bindings
to json schema format. V2 is mostly review comments being incorporated -
details in each of the patches and in applicable patches, I have picked
up Rob's and Tero's reviewed bys.

There are also dts fixups that this series exposes, which is good, but
I chose to hold them back for now pending binding review at least. The
complete series is available in [2] if folks are curious - to be posted
once v5.13-rc1 is available for fixes.

[1] https://lore.kernel.org/linux-arm-kernel/20210416063721.20538-1-nm at ti.com/
[2] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci

Nishanth Menon (4):
  dt-bindings: reset: Convert ti,sci-reset to json schema
  dt-bindings: clock: Convert ti,sci-clk to json schema
  dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
  dt-bindings: arm: keystone: Convert ti,sci to json schema

 .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
 .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
 .../devicetree/bindings/clock/ti,sci-clk.txt  |  36 -----
 .../devicetree/bindings/clock/ti,sci-clk.yaml |  49 +++++++
 .../bindings/reset/ti,sci-reset.txt           |  62 ---------
 .../bindings/reset/ti,sci-reset.yaml          |  51 +++++++
 .../bindings/soc/ti/sci-pm-domain.txt         |  65 ---------
 .../bindings/soc/ti/sci-pm-domain.yaml        |  59 ++++++++
 8 files changed, 288 insertions(+), 249 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
 delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
 delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
 delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml

Regards,
Nishanth Menon
-- 
2.31.0



From nm at ti.com  Mon Apr 26 16:54:54 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 10:54:54 -0500
Subject: [PATCH V2 1/4] dt-bindings: reset: Convert ti,
 sci-reset to json schema
In-Reply-To: <20210426155457.21221-1-nm@ti.com>
References: <20210426155457.21221-1-nm@ti.com>
Message-ID: <20210426155457.21221-2-nm@ti.com>

Convert the ti,sci-reset to json schema for better checks and documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Drop phandle description for reset consumer or cell definition as it is
   redundant.

Signed-off-by: Nishanth Menon <nm at ti.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Tero Kristo <kristo at kernel.org>
---

Changes since V1:
 * reviewed by from Tero and Rob
    https://lore.kernel.org/linux-arm-kernel/20210421223254.GA1734415 at robh.at.kernel.org/
    https://lore.kernel.org/linux-arm-kernel/56388707-c8d3-ebdf-77a2-c5a983856b4d at kernel.org/
 * Updated commit message to drop the 'checkpatch warning'

v1: https://lore.kernel.org/linux-arm-kernel/20210416063721.20538-2-nm at ti.com/

 .../bindings/reset/ti,sci-reset.txt           | 62 -------------------
 .../bindings/reset/ti,sci-reset.yaml          | 51 +++++++++++++++
 2 files changed, 51 insertions(+), 62 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml

diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
deleted file mode 100644
index 8b1cf022f18a..000000000000
--- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Reset Controller
-=====================================================================
-
-Some TI SoCs contain a system controller (like the Power Management Micro
-Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
-the state of the various hardware modules present on the SoC. Communication
-between the host processor running an OS and the system controller happens
-through a protocol called TI System Control Interface (TI-SCI protocol).
-For TI SCI details, please refer to the document,
-Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-TI-SCI Reset Controller Node
-============================
-This reset controller node uses the TI SCI protocol to perform the reset
-management of various hardware modules present on the SoC. Must be a child
-node of the associated TI-SCI system controller node.
-
-Required properties:
---------------------
- - compatible	: Should be "ti,sci-reset"
- - #reset-cells	: Should be 2. Please see the reset consumer node below for
-		  usage details.
-
-TI-SCI Reset Consumer Nodes
-===========================
-Each of the reset consumer nodes should have the following properties,
-in addition to their own properties.
-
-Required properties:
---------------------
- - resets	: A phandle and reset specifier pair, one pair for each reset
-		  signal that affects the device, or that the device manages.
-		  The phandle should point to the TI-SCI reset controller node,
-		  and the reset specifier should have 2 cell-values. The first
-		  cell should contain the device ID. The second cell should
-		  contain the reset mask value used by system controller.
-		  Please refer to the protocol documentation for these values
-		  to be used for different devices,
-		  http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
-common reset controller usage by consumers.
-
-Example:
---------
-The following example demonstrates both a TI-SCI reset controller node and a
-consumer (a DSP device) on the 66AK2G SoC.
-
-pmmc: pmmc {
-	compatible = "ti,k2g-sci";
-
-	k2g_reset: reset-controller {
-		compatible = "ti,sci-reset";
-		#reset-cells = <2>;
-	};
-};
-
-dsp0: dsp at 10800000 {
-	...
-	resets = <&k2g_reset 0x0046 0x1>;
-	...
-};
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
new file mode 100644
index 000000000000..4639d2cec557
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI reset controller node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This reset controller node uses the TI SCI protocol to perform the reset
+  management of various hardware modules present on the SoC. Must be a child
+  node of the associated TI-SCI system controller node.
+
+properties:
+  $nodename:
+    pattern: "^reset-controller$"
+
+  compatible:
+    const: ti,sci-reset
+
+  "#reset-cells":
+    const: 2
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell should contain the reset mask corresponding to the device
+      used by system controller.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+
+additionalProperties: false
+
+examples:
+  - |
+    k3_reset: reset-controller {
+        compatible = "ti,sci-reset";
+        #reset-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Mon Apr 26 16:54:56 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 10:54:56 -0500
Subject: [PATCH V2 3/4] dt-bindings: soc: ti: Convert ti,
 sci-pm-domain to json schema
In-Reply-To: <20210426155457.21221-1-nm@ti.com>
References: <20210426155457.21221-1-nm@ti.com>
Message-ID: <20210426155457.21221-4-nm@ti.com>

Convert the ti,sci-pm-domain to json schema for better checks and
documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Drop phandle description for reset consumer or cell definition as it
   is redundant.

Signed-off-by: Nishanth Menon <nm at ti.com>
Reviewed-by: Rob Herring <robh at kernel.org>
Reviewed-by: Tero Kristo <kristo at kernel.org>
---

Changes since V1:
 * reviewed by from Tero and Rob
    https://lore.kernel.org/linux-arm-kernel/20210421223627.GA1740013 at robh.at.kernel.org/
    https://lore.kernel.org/linux-arm-kernel/56388707-c8d3-ebdf-77a2-c5a983856b4d at kernel.org/
 * Updated commit message to drop the 'checkpatch warning'

v1: https://lore.kernel.org/linux-arm-kernel/20210416063721.20538-4-nm at ti.com/

 .../bindings/soc/ti/sci-pm-domain.txt         | 65 -------------------
 .../bindings/soc/ti/sci-pm-domain.yaml        | 59 +++++++++++++++++
 2 files changed, 59 insertions(+), 65 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
 create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml

diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
deleted file mode 100644
index 6217e64309de..000000000000
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Texas Instruments TI-SCI Generic Power Domain
----------------------------------------------
-
-Some TI SoCs contain a system controller (like the PMMC, etc...) that is
-responsible for controlling the state of the IPs that are present.
-Communication between the host processor running an OS and the system
-controller happens through a protocol known as TI-SCI [1].
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-PM Domain Node
-==============
-The PM domain node represents the global PM domain managed by the PMMC, which
-in this case is the implementation as documented by the generic PM domain
-bindings in Documentation/devicetree/bindings/power/power-domain.yaml.  Because
-this relies on the TI SCI protocol to communicate with the PMMC it must be a
-child of the pmmc node.
-
-Required Properties:
---------------------
-- compatible: should be "ti,sci-pm-domain"
-- #power-domain-cells: Can be one of the following:
-			1: Containing the device id of each node
-			2: First entry should be device id
-			   Second entry should be one of the floowing:
-			   TI_SCI_PD_EXCLUSIVE: To allow device to be
-						exclusively controlled by
-						the requesting hosts.
-			   TI_SCI_PD_SHARED: To allow device to be shared
-					     by multiple hosts.
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		...
-
-		k2g_pds: power-controller {
-			compatible = "ti,sci-pm-domain";
-			#power-domain-cells = <1>;
-		};
-	};
-
-PM Domain Consumers
-===================
-Hardware blocks belonging to a PM domain should contain a "power-domains"
-property that is a phandle pointing to the corresponding PM domain node
-along with an index representing the device id to be passed to the PMMC
-for device control.
-
-Required Properties:
---------------------
-- power-domains: phandle pointing to the corresponding PM domain node
-		 and an ID representing the device.
-
-See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list
-of valid identifiers for k2g.
-
-Example (K2G):
---------------------
-	uart0: serial at 2530c00 {
-		compatible = "ns16550a";
-		...
-		power-domains = <&k2g_pds 0x002c>;
-	};
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
new file mode 100644
index 000000000000..9e6cb4ee9755
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI generic power domain node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+allOf:
+  - $ref: /schemas/power/power-domain.yaml#
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This PM domain node represents the global PM domain managed by the TI-SCI
+  controller. Since this relies on the TI SCI protocol to communicate with
+  the TI-SCI controller, it must be a child of the TI-SCI controller node.
+
+properties:
+  compatible:
+    const: ti,sci-pm-domain
+
+  "#power-domain-cells":
+    enum: [1, 2]
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell, if cell-value is 2, should be one of the following
+      TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled
+      or
+      TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts.
+      Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+  - |
+    k2g_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <1>;
+    };
+
+  - |
+    k3_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Mon Apr 26 16:54:55 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 10:54:55 -0500
Subject: [PATCH V2 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
In-Reply-To: <20210426155457.21221-1-nm@ti.com>
References: <20210426155457.21221-1-nm@ti.com>
Message-ID: <20210426155457.21221-3-nm@ti.com>

Convert the ti,sci-clk to json schema for better checks and documentation.

Differences being:
 - Drop consumer example as they are documented in the corresponding
   bindings themselves.
 - Standardize the node name as clock-controller rather than clocks as
   it is more appropriate.
 - Drop phandle description for clock-cells as it is redundant.

Signed-off-by: Nishanth Menon <nm at ti.com>
Reviewed-by: Tero Kristo <kristo at kernel.org>
---

Changes since V1:
 * reviewed by from Tero
   https://lore.kernel.org/linux-arm-kernel/56388707-c8d3-ebdf-77a2-c5a983856b4d at kernel.org/
 * Updated commit message to drop the 'checkpatch warning'
 * Dropped reference to clock.yaml

v1: https://lore.kernel.org/linux-arm-kernel/20210416063721.20538-3-nm at ti.com/

 .../devicetree/bindings/clock/ti,sci-clk.txt  | 36 --------------
 .../devicetree/bindings/clock/ti,sci-clk.yaml | 49 +++++++++++++++++++
 2 files changed, 49 insertions(+), 36 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml

diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
deleted file mode 100644
index 4e59dc6b1778..000000000000
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Texas Instruments TI-SCI Clocks
-===============================
-
-All clocks on Texas Instruments' SoCs that contain a System Controller,
-are only controlled by this entity. Communication between a host processor
-running an OS and the System Controller happens through a protocol known
-as TI-SCI[1]. This clock implementation plugs into the common clock
-framework and makes use of the TI-SCI protocol on clock API requests.
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-Required properties:
--------------------
-- compatible: Must be "ti,k2g-sci-clk"
-- #clock-cells: Shall be 2.
-  In clock consumers, this cell represents the device ID and clock ID
-  exposed by the PM firmware. The list of valid values for the device IDs
-  and clocks IDs for 66AK2G SoC are documented at
-  http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Examples:
---------
-
-pmmc: pmmc {
-	compatible = "ti,k2g-sci";
-
-	k2g_clks: clocks {
-		compatible = "ti,k2g-sci-clk";
-		#clock-cells = <2>;
-	};
-};
-
-uart0: serial at 2530c00 {
-	compatible = "ns16550a";
-	clocks = <&k2g_clks 0x2c 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
new file mode 100644
index 000000000000..0e370289a053
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI clock controller node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  Some TI SoCs contain a system controller (like the Power Management Micro
+  Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+  the state of the various hardware modules present on the SoC. Communication
+  between the host processor running an OS and the system controller happens
+  through a protocol called TI System Control Interface (TI-SCI protocol).
+
+  This clock controller node uses the TI SCI protocol to perform various clock
+  management of various hardware modules (devices) present on the SoC. This
+  node must be a child node of the associated TI-SCI system controller node.
+
+properties:
+  $nodename:
+    pattern: "^clock-controller$"
+
+  compatible:
+    const: ti,k2g-sci-clk
+
+  "#clock-cells":
+    const: 2
+    description:
+      The two cells represent values that the TI-SCI controller defines.
+
+      The first cell should contain the device ID.
+
+      The second cell should contain the clock ID.
+
+      Please see  http://processors.wiki.ti.com/index.php/TISCI for
+      protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+  - |
+    k3_clks: clock-controller {
+        compatible = "ti,k2g-sci-clk";
+        #clock-cells = <2>;
+    };
-- 
2.31.0



From nm at ti.com  Mon Apr 26 16:54:57 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 10:54:57 -0500
Subject: [PATCH V2 4/4] dt-bindings: arm: keystone: Convert ti,
 sci to json schema
In-Reply-To: <20210426155457.21221-1-nm@ti.com>
References: <20210426155457.21221-1-nm@ti.com>
Message-ID: <20210426155457.21221-5-nm@ti.com>

Convert the ti,sci to json schema for better checks and documentation.

NOTE: This change does introduce a stricter naming convention for
TI-SCI controller nodes.

Signed-off-by: Nishanth Menon <nm at ti.com>
Reviewed-by: Tero Kristo <kristo at kernel.org>
---

Changes since V1:
 * reviewed by from Tero
    https://lore.kernel.org/linux-arm-kernel/56388707-c8d3-ebdf-77a2-c5a983856b4d at kernel.org/
 * Updated commit message to drop the 'checkpatch warning'
 * Inclusion of mbox-consumer.yaml dropped
 * debug_messages is a const
 * power-controller, clock-controller, reset-controller subnodes are
   explicit subnode properties

v1: https://lore.kernel.org/linux-arm-kernel/20210416063721.20538-5-nm at ti.com/

 .../bindings/arm/keystone/ti,sci.txt          |  86 ------------
 .../bindings/arm/keystone/ti,sci.yaml         | 129 ++++++++++++++++++
 2 files changed, 129 insertions(+), 86 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml

diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
deleted file mode 100644
index 6f0cd31c1520..000000000000
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Message Protocol
---------------------------------------------------------------------
-
-Texas Instrument's processors including those belonging to Keystone generation
-of processors have separate hardware entity which is now responsible for the
-management of the System on Chip (SoC) system. These include various system
-level functions as well.
-
-An example of such an SoC is K2G, which contains the system control hardware
-block called Power Management Micro Controller (PMMC). This hardware block is
-initialized early into boot process and provides services to Operating Systems
-on multiple processors including ones running Linux.
-
-See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
-
-TI-SCI controller Device Node:
-=============================
-
-The TI-SCI node describes the Texas Instrument's System Controller entity node.
-This parent node may optionally have additional children nodes which describe
-specific functionality such as clocks, power domain, reset or additional
-functionality as may be required for the SoC. This hierarchy also describes the
-relationship between the TI-SCI parent node to the child node.
-
-Required properties:
--------------------
-- compatible:	should be "ti,k2g-sci" for TI 66AK2G SoC
-		should be "ti,am654-sci" for for TI AM654 SoC
-- mbox-names:
-	"rx" - Mailbox corresponding to receive path
-	"tx" - Mailbox corresponding to transmit path
-
-- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
-	  property should contain a phandle to the mailbox controller device
-	  node and an args specifier that will be the phandle to the intended
-	  sub-mailbox child node to be used for communication.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings. Also see
-Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
-controller that is used to communicate with this System controllers.
-
-Optional Properties:
--------------------
-- reg-names:
-	debug_messages - Map the Debug message region
-- reg:  register space corresponding to the debug_messages
-- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
-- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
-	for identification of host processing entities such as virtual
-	machines
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		ti,host-id = <2>;
-		mbox-names = "rx", "tx";
-		mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
-			<&msgmgr &msgmgr_proxy_pmmc_tx>;
-		reg-names = "debug_messages";
-		reg = <0x02921800 0x800>;
-	};
-
-
-TI-SCI Client Device Node:
-=========================
-
-Client nodes are maintained as children of the relevant TI-SCI device node.
-
-Example (K2G):
--------------
-	pmmc: pmmc {
-		compatible = "ti,k2g-sci";
-		...
-
-		my_clk_node: clk_node {
-			...
-			...
-		};
-
-		my_pd_node: pd_node {
-			...
-			...
-		};
-	};
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
new file mode 100644
index 000000000000..34f5f877d444
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI controller device node bindings
+
+maintainers:
+  - Nishanth Menon <nm at ti.com>
+
+description: |
+  Texas Instrument's processors including those belonging to Keystone generation
+  of processors have separate hardware entity which is now responsible for the
+  management of the System on Chip (SoC) system. These include various system
+  level functions as well.
+
+  An example of such an SoC is K2G, which contains the system control hardware
+  block called Power Management Micro Controller (PMMC). This hardware block is
+  initialized early into boot process and provides services to Operating Systems
+  on multiple processors including ones running Linux.
+
+  See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
+
+  The TI-SCI node describes the Texas Instrument's System Controller entity node.
+  This parent node may optionally have additional children nodes which describe
+  specific functionality such as clocks, power domain, reset or additional
+  functionality as may be required for the SoC. This hierarchy also describes the
+  relationship between the TI-SCI parent node to the child node.
+
+properties:
+  $nodename:
+    pattern: "^system-controller@[0-9a-f]+$"
+
+  compatible:
+    oneOf:
+      - description: System controller on TI 66AK2G SoC and other K3 SoCs
+        items:
+          - const: ti,k2g-sci
+      - description: System controller on TI AM654 SoC
+        items:
+          - const: ti,am654-sci
+
+  reg-names:
+    description: |
+      Specifies the debug messages memory mapped region that is optionally
+      made available from TI-SCI controller.
+    const: debug_messages
+
+  reg:
+    minItems: 1
+
+  mbox-names:
+    description: |
+      Specifies the mailboxes used to communicate with TI-SCI Controller
+      made available from TI-SCI controller.
+    items:
+      - const: rx
+      - const: tx
+
+  mboxes:
+    minItems: 2
+
+  ti,system-reboot-controller:
+    description: Determines If system reboot can be triggered by SoC reboot
+    type: boolean
+
+  ti,host-id:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: |
+      Value corresponding to the host ID assigned by Firmware
+      for identification of host processing entities such as virtual machines.
+
+  power-controller:
+    type: object
+    $ref: /schemas/soc/ti/sci-pm-domain.yaml#
+
+  clock-controller:
+    type: object
+    $ref: /schemas/clock/ti,sci-clk.yaml#
+
+  reset-controller:
+    type: object
+    $ref: /schemas/reset/ti,sci-reset.yaml#
+
+required:
+  - compatible
+  - mbox-names
+  - mboxes
+
+additionalProperties: false
+
+examples:
+  - |
+    pmmc: system-controller at 2921800 {
+      compatible = "ti,k2g-sci";
+      ti,system-reboot-controller;
+      mbox-names = "rx", "tx";
+      mboxes= <&msgmgr 5 2>,
+              <&msgmgr 0 0>;
+      reg-names = "debug_messages";
+      reg = <0x02921800 0x800>;
+    };
+
+  - |
+    dmsc: system-controller at 44083000 {
+      compatible = "ti,k2g-sci";
+      ti,host-id = <12>;
+      mbox-names = "rx", "tx";
+      mboxes= <&secure_proxy_main 11>,
+              <&secure_proxy_main 13>;
+      reg-names = "debug_messages";
+      reg = <0x44083000 0x1000>;
+
+      k3_pds: power-controller {
+        compatible = "ti,sci-pm-domain";
+        #power-domain-cells = <2>;
+      };
+
+      k3_clks: clock-controller {
+        compatible = "ti,k2g-sci-clk";
+        #clock-cells = <2>;
+      };
+
+      k3_reset: reset-controller {
+        compatible = "ti,sci-reset";
+        #reset-cells = <2>;
+      };
+    };
-- 
2.31.0



From arnd at kernel.org  Mon Apr 26 16:55:47 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 17:55:47 +0200
Subject: [GIT PULL 3/6] ARM: SoC drivers for v5.13
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a3uSjSyrRAq2BjR2fo6S7kCfOo+3szQ2cvBt8-D2KybwQ@mail.gmail.com>

The following changes since commit 4c9f4865f4604744d4f1a43db22ac6ec9dc8e587:

  Merge branch 'fixes-rc2' into fixes (2021-03-08 11:34:12 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-drivers-5.13

for you to fetch changes up to 5ffa828534036348fa90fb3079ccc0972d202c4a:

  soc: aspeed: fix a ternary sign expansion bug (2021-04-23 11:16:47 +0200)

----------------------------------------------------------------
ARM: SoC drivers for v5.13

Updates for SoC specific drivers include a few subsystems that
have their own maintainers but send them through the soc tree:

TEE/OP-TEE:
 -  Add tracepoints around calls to secure world

Memory controller drivers:
 - Minor fixes for Renesas, Exynos, Mediatek and Tegra platforms
 - Add debug statistics to Tegra20 memory controller
 - Update Tegra bindings and convert to dtschema

ARM SCMI Firmware:
 - Support for modular SCMI protocols and vendor specific extensions
 - New SCMI IIO driver
 - Per-cpu DVFS

The other driver changes are all from the platform maintainers
directly and reflect the drivers that don't fit into any other
subsystem as well as treewide changes for a particular platform.

SoCFPGA:
 - Various cleanups contributed by Krzysztof Kozlowski

Mediatek:
 - add MT8183 support to mutex driver
 - MMSYS: use per SoC array to describe the possible routing
 - add MMSYS support for MT8183 and MT8167
 - add support for PMIC wrapper with integrated arbiter
 - add support for MT8192/MT6873

Tegra:
 - Bug fixes to PMC and clock drivers

NXP/i.MX:
 - Update SCU power domain driver to keep console domain power on.
 - Add missing ADC1 power domain to SCU power domain driver.
 - Update comments for single global power domain in SCU power domain
   driver.
 - Add i.MX51/i.MX53 unique id support to i.MX SoC driver.

NXP/FSL SoC driver updates for v5.13
 - Add ACPI support for RCPM driver
 - Use generic io{read,write} for QE drivers after performance optimized
   for PowerPC
 - Fix QBMAN probe to cleanup HW states correctly for kexec
 - Various cleanup and style fix for QBMAN/QE/GUTS drivers

OMAP:
 - Preparation to use devicetree for genpd
 - ti-sysc needs iorange check improved when the interconnect target module
   has no control registers listed
 - ti-sysc needs to probe l4_wkup and l4_cfg interconnects first to avoid
   issues with missing resources and unnecessary deferred probe
 - ti-sysc debug option can now detect more devices
 - ti-sysc now warns if an old incomplete devicetree data is found as we
   now rely on it being complete for am3 and 4
 - soc init code needs to check for prcm and prm nodes for omap4/5 and dra7
 - omap-prm driver needs to enable autoidle retention support for omap4
 - omap5 clocks are missing gpmc and ocmc clock registers
 - pci-dra7xx now needs to use builtin_platform_driver instead of using
   builtin_platform_driver_probe for deferred probe to work

Raspberry Pi:
 - Fix-up all RPi firmware drivers so as for unbind to happen in an
   orderly fashion
 - Support for RPi's PoE hat PWM bus

Qualcomm
 - Improved detection for SCM calling conventions
 - Support for OEM specific wifi firmware path
 - Added drivers for SC7280/SM8350: RPMH, LLCC< AOSS QMP

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Aditya Srivastava (1):
      soc: fsl: guts: fix comment syntax in file

Arnd Bergmann (23):
      Merge tag 'optee-tracepoints-for-v5.13' of
git://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers
      Merge tag 'renesas-drivers-for-v5.13-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into
arm/drivers
      Merge tag 'optee-tracepoints-fix-for-v5.13' of
git://git.linaro.org/people/jens.wiklander/linux-tee into arm/fixes
      Merge tag 'rpi-poe-v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi into
arm/drivers
      Merge tag 'omap-for-v5.13/ti-sysc-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/drivers
      Merge tag 'optee-memref-size-for-v5.13' of
git://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers
      Merge tag 'arm-soc/for-5.13/drivers' of
https://github.com/Broadcom/stblinux into arm/drivers
      Merge tag 'imx-drivers-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/drivers
      Merge tag 'tegra-for-5.13-clk' of
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into
arm/drivers
      Merge tag 'tegra-for-5.13-soc' of
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into
arm/drivers
      Merge tag 'v5.12-next-soc' of
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into
arm/drivers
      Merge tag 'socfpga_update_for_v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into
arm/drivers
      Merge tag 'scmi-updates-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into
arm/drivers
      Merge tag 'qcom-drivers-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/drivers
      Merge tag 'socfpga_update_for_v5.13_part2' of
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into
arm/drivers
      Merge tag 'v5.12-next-soc.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into
arm/drivers
      Merge tag 'memory-controller-drv-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into
arm/drivers
      Merge tag 'memory-controller-drv-tegra-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into
arm/drivers
      Merge tag 'aspeed-5.13-lpc' of
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into
arm/drivers
      Merge tag 'qcom-drivers-for-5.13-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into
arm/drivers
      Merge tag 'zynqmp-soc-for-v5.13' of
https://github.com/Xilinx/linux-xlnx into arm/drivers
      Merge tag 'soc-fsl-next-v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux into
arm/drivers
      Merge tag 'memory-controller-drv-5.13-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into
arm/drivers

Bhaskar Chowdhury (1):
      soc: qcom: Fix typos in the file qmi_encdec.c

Bjorn Andersson (5):
      dt-bindings: soc: qcom: wcnss: Add firmware-name property
      soc: qcom: wcnss_ctrl: Introduce local variable "dev"
      soc: qcom: wcnss_ctrl: Allow reading firmware-name from DT
      soc: qcom: mdt_loader: Validate that p_filesz < p_memsz
      soc: qcom: mdt_loader: Detect truncated read of segments

CK Hu (2):
      soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
      soc: mediatek: mmsys: Use an array for setting the routing registers

Chia-Wei, Wang (5):
      dt-bindings: aspeed-lpc: Remove LPC partitioning
      ARM: dts: Remove LPC BMC and Host partitions
      ipmi: kcs: aspeed: Adapt to new LPC DTS layout
      pinctrl: aspeed-g5: Adapt to new LPC device tree layout
      soc: aspeed: Adapt to new LPC device tree layout

Christophe Leroy (3):
      soc: fsl: qe: replace qe_io{read,write}* wrappers by generic
io{read,write}*
      tty: serial: ucc_uart: replace qe_io{read,write}* wrappers by
generic io{read,write}*
      Revert "soc: fsl: qe: introduce qe_io{read,write}* wrappers"

Colin Ian King (1):
      memory: gpmc: fix out of bounds read and dereference on gpmc_cs[]

Cristian Marussi (38):
      firmware: arm_scmi: Extend protocol registration interfaces
      firmware: arm_scmi: Introduce protocol handle definitions
      firmware: arm_scmi: Introduce devres get/put protocols operations
      firmware: arm_scmi: Make notifications aware of protocols users
      firmware: arm_scmi: Introduce new devres notification ops
      firmware: arm_scmi: Refactor events registration
      firmware: arm_scmi: Convert events registration to protocol handles
      firmware: arm_scmi: Add new protocol handle core transfer ops
      firmware: arm_scmi: Add helper to access protocol revision/version
      firmware: arm_scmi: Port base protocol to new interface
      firmware: arm_scmi: Port perf protocol to new protocols interface
      cpufreq: scmi: Port driver to the new scmi_perf_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_perf_ops protocol interface
      firmware: arm_scmi: Port power protocol to new protocols interface
      firmware: arm_scmi: Port genpd driver to the new
scmi_power_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_power_ops protocol interface
      firmware: arm_scmi: Port clock protocol to new protocols interface
      clk: scmi: Port driver to the new scmi_clk_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_clk_ops protocol interface
      firmware: arm_scmi: Port reset protocol to new protocols interface
      reset: reset-scmi: Port driver to the new scmi_reset_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_reset_ops protocol interface
      firmware: arm_scmi: Port sensor protocol to new protocols interface
      hwmon: (scmi) port driver to the new scmi_sensor_proto_ops interface
      iio/scmi: Port driver to the new scmi_sensor_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_sensor_ops protocol interface
      firmware: arm_scmi: Port systempower protocol to new protocols interface
      firmware: arm_scmi: Port voltage protocol to new protocols interface
      regulator: scmi: Port driver to the new scmi_voltage_proto_ops interface
      firmware: arm_scmi: Remove legacy scmi_voltage_ops protocol interface
      firmware: arm_scmi: Make references to handle const
      firmware: arm_scmi: Cleanup legacy protocol init code
      firmware: arm_scmi: Cleanup unused core transfer helper wrappers
      firmware: arm_scmi: Cleanup events registration transient code
      firmware: arm_scmi: Make notify_priv really private
      firmware: arm_scmi: Rename non devres notify_ops
      firmware: arm_scmi: Add protocol modularization support
      firmware: arm_scmi: Add dynamic scmi devices creation

Dan Carpenter (1):
      soc: aspeed: fix a ternary sign expansion bug

Dmitry Osipenko (13):
      soc/tegra: regulators: Fix locking up when voltage-spread is out of range
      soc/tegra: pmc: Fix imbalanced clock disabling in error code path
      soc/tegra: pmc: Fix completion of power-gate toggling
      soc/tegra: pmc: Ensure that clock rates aren't too high
      soc/tegra: pmc: Print out domain name when reset fails to acquire
      memory: tegra20: Add debug statistics
      memory: tegra20: Correct comment to MC_STAT registers writes
      memory: tegra20: Protect debug code with a lock
      memory: tegra: Print out info-level once per driver probe
      dt-bindings: memory: tegra20: emc: Replace core regulator with
power domain
      dt-bindings: memory: tegra30: emc: Replace core regulator with
power domain
      dt-bindings: memory: tegra124: emc: Replace core regulator with
power domain
      dt-bindings: memory: tegra20: mc: Convert to schema

Dong Aisheng (1):
      firmware: imx: scu-pd: do not power off console domain

Enric Balletbo i Serra (5):
      soc: mediatek: pm-domains: Fix missing error code in
scpsys_add_subdomain()
      soc: mediatek: pm-domains: Add a meaningful power domain name
      soc: mediatek: pm-domains: Add a power domain names for mt8183
      soc: mediatek: pm-domains: Add a power domain names for mt8192
      soc: mediatek: pm-domains: Add a power domain names for mt8167

Fabien Parent (2):
      dt-bindings: mediatek: mmsys: add mt8167 binding
      soc: mediatek: mmsys: Add support for MT8167 SoC

Frank Li (1):
      firmware: imx: scu-pd: add missed ADC1 pd

Geert Uytterhoeven (2):
      soc: renesas: rmobile-sysc: Remove unneeded platform includes
      soc: renesas: rmobile-sysc: Mark fwnode when PM domain is added

Hsin-Hsiung Wang (4):
      soc: mediatek: pwrap: use BIT() macro
      soc: mediatek: pwrap: add arbiter capability
      dt-bindings: mediatek: add compatible for MT6873/8192 pwrap
      soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs

Hsin-Yi Wang (1):
      soc: mediatek: mmsys: Add mt8183 mmsys routing table

JC Kuo (3):
      clk: tegra: Add PLLE HW power sequencer control
      clk: tegra: Don't enable PLLE HW sequencer at init
      soc/tegra: pmc: Provide USB sleepwalk register map

Jerome Forissier (1):
      tee: optee: do not check memref size on return from Secure World

Jisheng Zhang (2):
      tee: optee: add invoke_fn tracepoints
      tee: optee: fix build error caused by recent optee tracepoints feature

Jyoti Bhayana (1):
      iio/scmi: Adding support for IIO SCMI Based Sensors

Krzysztof Kozlowski (19):
      clk: socfpga: allow building N5X clocks with ARCH_N5X
      ARM: socfpga: introduce common ARCH_INTEL_SOCFPGA
      mfd: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10
      net: stmmac: merge ARCH_SOCFPGA and ARCH_STRATIX10
      clk: socfpga: build together Stratix 10, Agilex and N5X clock drivers
      clk: socfpga: merge ARCH_SOCFPGA and ARCH_STRATIX10
      EDAC: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10
      arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGA
      clk: socfpga: allow compile testing of Stratix 10 / Agilex clocks
      clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
(and compile test)
      dmaengine: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
      fpga: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
      i2c: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
      reset: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs
      ARM: socfpga: drop ARCH_SOCFPGA
      firmware: stratix10-svc: build only on 64-bit ARM
      clk: socfpga: fix iomem pointer cast on 64-bit
      memory: renesas-rpc-if: fix possible NULL pointer dereference of resource
      memory: samsung: exynos5422-dmc: handle clk_set_parent() failure

Lukas Bulwahn (2):
      MAINTAINERS: add another entry for ARM/QUALCOMM SUPPORT
      soc: qcom: address kernel-doc warnings

Nicola Mazzucato (2):
      scmi-cpufreq: Remove deferred probe
      scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM

Nicolas Saenz Julienne (10):
      firmware: raspberrypi: Keep count of all consumers
      firmware: raspberrypi: Introduce devm_rpi_firmware_get()
      clk: bcm: rpi: Release firmware handle on unbind
      gpio: raspberrypi-exp: Release firmware handle on unbind
      reset: raspberrypi: Release firmware handle on unbind
      soc: bcm: raspberrypi-power: Release firmware handle on unbind
      staging: vchiq: Release firmware handle on unbind
      input: raspberrypi-ts: Release firmware handle when not needed
      dt-bindings: pwm: Add binding for RPi firmware PWM bus
      pwm: Add Raspberry Pi Firmware based PWM bus

Nobuhiro Iwamatsu (1):
      firmware: xilinx: Remove zynqmp_pm_get_eemi_ops() in
IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE)

Pan Bian (1):
      bus: qcom: Put child node before return

Peng Ma (1):
      soc: fsl: enable acpi support in RCPM driver

Qiheng Lin (1):
      memory: fsl-corenet-cf: Remove redundant dev_err call in ccf_probe()

Qinglang Miao (1):
      soc: qcom: pdr: Fix error return code in pdr_register_listener

Rafa? Mi?ecki (2):
      dt-bindings: power: bcm-pmb: add BCM63138 binding
      soc: bcm: bcm-pmb: add BCM63138 SATA support

Rajendra Nayak (3):
      dt-bindings: power: rpmpd: Add sc7280 to rpmpd binding
      soc: qcom: rpmhpd: Add sc7280 powerdomains
      dt-bindings: firmware: scm: Add sc7280 support

Roy Pledge (1):
      soc: fsl: qbman: Ensure device cleanup is run for kexec

Sai Prakash Ranjan (4):
      dt-bindings: arm: msm: Add LLCC for SC7280
      soc: qcom: llcc: Add configuration data for SC7280
      dt-bindings: soc: qcom: aoss: Add SC7280 compatible
      soc: qcom: aoss: Add AOSS QMP support for SC7280

Sebastian Reichel (1):
      soc: imx: add i.MX51/i.MX53 unique id support

Sibi Sankar (1):
      soc: qcom: smem: Update max processor count

Stephen Boyd (8):
      soc: qcom: rpmh-rsc: Remove tcs_is_free() API
      soc: qcom: rpmh-rsc: Loop over fewer bits in irq handler
      soc: qcom: rpmh-rsc: Fold WARN_ON() into if condition
      firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool
      firmware: qcom_scm: Reduce locking section for __get_convention()
      firmware: qcom_scm: Workaround lack of "is available" call on SC7180
      firmware: qcom_scm: Suppress sysfs bind attributes
      firmware: qcom_scm: Fix kernel-doc function names to match

Sudeep Holla (1):
      Merge branch 'ib-iio-scmi-5.12-rc2-take3' of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into
for-next/scmi

Tejas Patel (1):
      firmware: xilinx: Fix dereferencing freed memory

Tony Lindgren (8):
      bus: ti-sysc: Fix initializing module_pa for modules without sysc register
      bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first
      bus: ti-sysc: Detect more modules for debugging
      bus: ti-sysc: Check for old incomplete dtb
      ARM: OMAP2+: Init both prm and prcm nodes early for clocks
      soc: ti: omap-prm: Allow hardware supported retention when idle
      clk: ti: omap5: Add missing gpmc and ocmc clkctrl
      PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver

Ulf Hansson (1):
      firmware: imx: scu-pd: Update comments for single global power domain

Vinod Koul (2):
      dt-bindings: power: Add rpm power domain bindings for SM8350
      soc: qcom: rpmhpd: Add SM8350 power domains

Wei Yongjun (2):
      ARM: OMAP2+: Make symbol 'pdata_quirks_init_clocks' static
      soc: mediatek: Make symbol 'mtk_mutex_driver' static

Yang Li (3):
      bus: ti-sysc: remove unneeded semicolon
      memory: tegra: replace DEFINE_SIMPLE_ATTRIBUTE with
DEFINE_DEBUGFS_ATTRIBUTE
      soc: fsl: guts: remove unneeded semicolon

Yong Wu (1):
      memory: mtk-smi: Add device-link between smi-larb and smi-common

Yongqiang Niu (1):
      soc: mediatek: add mtk mutex support for MT8183

Zheng Yongjun (3):
      bus: ti-sysc: Use kzalloc for allocating only one thing
      soc: fsl: qbman: Delete useless kfree code
      soc: fsl: qe: Use DEFINE_SPINLOCK() for spinlock

gexueyuan (1):
      memory: pl353: fix mask of ECC page_size config register

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml      |  20 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt       |   1 +
 .../devicetree/bindings/arm/msm/qcom,llcc.yaml     |   1 +
 .../devicetree/bindings/firmware/qcom,scm.txt      |   1 +
 .../memory-controllers/nvidia,tegra124-emc.yaml    |   7 +-
 .../memory-controllers/nvidia,tegra20-emc.txt      |   4 +-
 .../memory-controllers/nvidia,tegra20-mc.txt       |  40 --
 .../memory-controllers/nvidia,tegra20-mc.yaml      |  79 ++
 .../memory-controllers/nvidia,tegra30-emc.yaml     |   7 +-
 .../devicetree/bindings/mfd/aspeed-lpc.txt         | 100 +--
 .../devicetree/bindings/power/brcm,bcm-pmb.yaml    |   1 +
 .../devicetree/bindings/power/qcom,rpmpd.yaml      |   2 +
 .../devicetree/bindings/soc/mediatek/pwrap.txt     |   1 +
 .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt |   1 +
 .../devicetree/bindings/soc/qcom/qcom,wcnss.txt    |   7 +
 Documentation/driver-api/xilinx/eemi.rst           |  31 +-
 MAINTAINERS                                        |   7 +
 arch/arm/Kconfig                                   |   2 +-
 arch/arm/Kconfig.debug                             |   6 +-
 arch/arm/Makefile                                  |   2 +-
 arch/arm/boot/dts/Makefile                         |   2 +-
 arch/arm/boot/dts/aspeed-g4.dtsi                   |  76 +-
 arch/arm/boot/dts/aspeed-g5.dtsi                   | 137 ++--
 arch/arm/boot/dts/aspeed-g6.dtsi                   | 137 ++--
 arch/arm/configs/multi_v7_defconfig                |   2 +-
 arch/arm/configs/socfpga_defconfig                 |   2 +-
 arch/arm/mach-omap2/pdata-quirks.c                 |  29 +-
 arch/arm/mach-socfpga/Kconfig                      |   4 +-
 arch/arm64/Kconfig.platforms                       |  17 +-
 arch/arm64/boot/dts/altera/Makefile                |   2 +-
 arch/arm64/boot/dts/intel/Makefile                 |   6 +-
 arch/arm64/configs/defconfig                       |   2 +-
 drivers/bus/qcom-ebi2.c                            |   4 +-
 drivers/bus/ti-sysc.c                              |  84 ++-
 drivers/char/ipmi/kcs_bmc_aspeed.c                 |  27 +-
 drivers/clk/Kconfig                                |   1 +
 drivers/clk/Makefile                               |   4 +-
 drivers/clk/bcm/clk-raspberrypi.c                  |   2 +-
 drivers/clk/clk-scmi.c                             |  28 +-
 drivers/clk/socfpga/Kconfig                        |  19 +
 drivers/clk/socfpga/Makefile                       |  11 +-
 drivers/clk/socfpga/clk-gate.c                     |   2 +-
 drivers/clk/tegra/clk-pll.c                        |  12 -
 drivers/clk/tegra/clk-tegra210.c                   |  53 +-
 drivers/clk/ti/clk-54xx.c                          |   2 +
 drivers/cpufreq/scmi-cpufreq.c                     | 107 ++-
 drivers/dma/Kconfig                                |   2 +-
 drivers/edac/Kconfig                               |   2 +-
 drivers/edac/altera_edac.c                         |  17 +-
 drivers/firmware/Kconfig                           |   2 +-
 drivers/firmware/arm_scmi/base.c                   | 142 ++--
 drivers/firmware/arm_scmi/bus.c                    | 100 ++-
 drivers/firmware/arm_scmi/clock.c                  | 129 ++--
 drivers/firmware/arm_scmi/common.h                 | 133 +++-
 drivers/firmware/arm_scmi/driver.c                 | 798 +++++++++++++++++++--
 drivers/firmware/arm_scmi/notify.c                 | 328 +++++++--
 drivers/firmware/arm_scmi/notify.h                 |  40 +-
 drivers/firmware/arm_scmi/perf.c                   | 262 +++----
 drivers/firmware/arm_scmi/power.c                  | 134 ++--
 drivers/firmware/arm_scmi/reset.c                  | 146 ++--
 drivers/firmware/arm_scmi/scmi_pm_domain.c         |  26 +-
 drivers/firmware/arm_scmi/sensors.c                | 232 +++---
 drivers/firmware/arm_scmi/system.c                 |  63 +-
 drivers/firmware/arm_scmi/voltage.c                | 126 ++--
 drivers/firmware/imx/scu-pd.c                      |  41 +-
 drivers/firmware/qcom_scm-legacy.c                 |   4 +-
 drivers/firmware/qcom_scm-smc.c                    |  12 +-
 drivers/firmware/qcom_scm.c                        |  89 ++-
 drivers/firmware/qcom_scm.h                        |   7 +-
 drivers/firmware/raspberrypi.c                     |  69 +-
 drivers/firmware/xilinx/zynqmp.c                   |   5 +-
 drivers/fpga/Kconfig                               |   8 +-
 drivers/gpio/gpio-raspberrypi-exp.c                |   2 +-
 drivers/hwmon/scmi-hwmon.c                         |  24 +-
 drivers/i2c/busses/Kconfig                         |   2 +-
 drivers/iio/common/Kconfig                         |   1 +
 drivers/iio/common/Makefile                        |   1 +
 drivers/iio/common/scmi_sensors/Kconfig            |  18 +
 drivers/iio/common/scmi_sensors/Makefile           |   5 +
 drivers/iio/common/scmi_sensors/scmi_iio.c         | 683 ++++++++++++++++++
 drivers/input/touchscreen/raspberrypi-ts.c         |   2 +-
 drivers/memory/fsl-corenet-cf.c                    |   4 +-
 drivers/memory/mtk-smi.c                           |  19 +-
 drivers/memory/omap-gpmc.c                         |   7 +-
 drivers/memory/pl353-smc.c                         |   2 +-
 drivers/memory/renesas-rpc-if.c                    |   2 +-
 drivers/memory/samsung/exynos5422-dmc.c            |   4 +-
 drivers/memory/tegra/mc.c                          |   9 +
 drivers/memory/tegra/mc.h                          |   4 +-
 drivers/memory/tegra/tegra124-emc.c                |  16 +-
 drivers/memory/tegra/tegra20-emc.c                 |  20 +-
 drivers/memory/tegra/tegra20.c                     | 332 +++++++++
 drivers/memory/tegra/tegra30-emc.c                 |  18 +-
 drivers/mfd/Kconfig                                |   4 +-
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |   4 +-
 drivers/pci/controller/dwc/pci-dra7xx.c            |  13 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c         |  17 +-
 drivers/pwm/Kconfig                                |   9 +
 drivers/pwm/Makefile                               |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c                  | 206 ++++++
 drivers/regulator/scmi-regulator.c                 |  42 +-
 drivers/reset/Kconfig                              |   6 +-
 drivers/reset/reset-raspberrypi.c                  |   2 +-
 drivers/reset/reset-scmi.c                         |  33 +-
 drivers/soc/aspeed/aspeed-lpc-ctrl.c               |  20 +-
 drivers/soc/aspeed/aspeed-lpc-snoop.c              |  27 +-
 drivers/soc/bcm/bcm63xx/bcm-pmb.c                  |  30 +
 drivers/soc/bcm/raspberrypi-power.c                |   2 +-
 drivers/soc/fsl/guts.c                             |   2 +-
 drivers/soc/fsl/qbman/bman.c                       |   1 -
 drivers/soc/fsl/qbman/bman_portal.c                |   3 +-
 drivers/soc/fsl/qbman/qman_portal.c                |   3 +-
 drivers/soc/fsl/qe/gpio.c                          |  20 +-
 drivers/soc/fsl/qe/qe.c                            |  24 +-
 drivers/soc/fsl/qe/qe_common.c                     |   3 +-
 drivers/soc/fsl/qe/qe_ic.c                         |   4 +-
 drivers/soc/fsl/qe/qe_io.c                         |  36 +-
 drivers/soc/fsl/qe/ucc_fast.c                      |  68 +-
 drivers/soc/fsl/qe/ucc_slow.c                      |  42 +-
 drivers/soc/fsl/rcpm.c                             |  24 +-
 drivers/soc/imx/soc-imx.c                          |  12 +
 drivers/soc/mediatek/mt8167-mmsys.h                |  35 +
 drivers/soc/mediatek/mt8167-pm-domains.h           |   7 +
 drivers/soc/mediatek/mt8173-pm-domains.h           |  10 +
 drivers/soc/mediatek/mt8183-mmsys.h                |  54 ++
 drivers/soc/mediatek/mt8183-pm-domains.h           |  15 +
 drivers/soc/mediatek/mt8192-pm-domains.h           |  21 +
 drivers/soc/mediatek/mtk-mmsys.c                   | 314 ++------
 drivers/soc/mediatek/mtk-mmsys.h                   | 215 ++++++
 drivers/soc/mediatek/mtk-mutex.c                   |  52 +-
 drivers/soc/mediatek/mtk-pm-domains.c              |  11 +-
 drivers/soc/mediatek/mtk-pm-domains.h              |   2 +
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  97 ++-
 drivers/soc/qcom/llcc-qcom.c                       |  19 +
 drivers/soc/qcom/mdt_loader.c                      |  17 +
 drivers/soc/qcom/pdr_interface.c                   |   2 +-
 drivers/soc/qcom/qcom_aoss.c                       |   1 +
 drivers/soc/qcom/qmi_encdec.c                      |   8 +-
 drivers/soc/qcom/rpmh-rsc.c                        |  65 +-
 drivers/soc/qcom/rpmhpd.c                          |  56 ++
 drivers/soc/qcom/smem.c                            |   2 +-
 drivers/soc/qcom/wcnss_ctrl.c                      |  15 +-
 drivers/soc/renesas/rmobile-sysc.c                 |   4 +-
 drivers/soc/tegra/pmc.c                            | 259 ++++++-
 drivers/soc/tegra/regulators-tegra30.c             |   2 +-
 drivers/soc/ti/omap_prm.c                          |  16 +-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  |   2 +-
 drivers/tee/optee/Makefile                         |   3 +
 drivers/tee/optee/call.c                           |   4 +
 drivers/tee/optee/core.c                           |  10 -
 drivers/tee/optee/optee_trace.h                    |  67 ++
 drivers/tty/serial/ucc_uart.c                      | 124 ++--
 include/dt-bindings/clock/omap5.h                  |   2 +
 include/dt-bindings/power/qcom-rpmpd.h             |  26 +
 .../dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h |  13 +
 include/dt-bindings/soc/bcm-pmb.h                  |   1 +
 include/linux/clk/tegra.h                          |   4 +-
 include/linux/firmware/xlnx-zynqmp.h               |   5 -
 include/linux/fsl/guts.h                           |   4 +-
 include/linux/scmi_protocol.h                      | 200 +++---
 include/linux/soc/qcom/apr.h                       |   2 +-
 include/linux/soc/qcom/irq.h                       |   2 +-
 include/linux/soc/qcom/llcc-qcom.h                 |   6 +-
 include/linux/soc/qcom/qmi.h                       |   4 +-
 include/soc/bcm2835/raspberrypi-firmware.h         |  10 +
 include/soc/fsl/qe/qe.h                            |  34 +-
 include/soc/tegra/mc.h                             |   7 +
 167 files changed, 5560 insertions(+), 2111 deletions(-)
 delete mode 100644
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
 create mode 100644
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.yaml
 create mode 100644 drivers/clk/socfpga/Kconfig
 create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
 create mode 100644 drivers/iio/common/scmi_sensors/Makefile
 create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 drivers/soc/mediatek/mt8167-mmsys.h
 create mode 100644 drivers/soc/mediatek/mt8183-mmsys.h
 create mode 100644 drivers/soc/mediatek/mtk-mmsys.h
 create mode 100644 drivers/tee/optee/optee_trace.h
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h


From arnd at kernel.org  Mon Apr 26 16:57:08 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 17:57:08 +0200
Subject: [GIT PULL 4/6] ARM: devicetree changes for 5.13
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a0=urEEHzcQt0u2fbb7SLDO6NGs8aeYvNpj=jP+YWd2Hw@mail.gmail.com>

The following changes since commit 405fa9e9d8664e830982c5fbcb70f9ba8656bafc:

  arm64: tegra: Move clocks from RT5658 endpoint to device node
(2021-03-25 14:04:49 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-dt-5.13

for you to fetch changes up to 3f9a3345a3a116af806064826d42cf5211dd611d:

  dt-bindings: mali-bifrost: add dma-coherent (2021-04-22 23:19:47 +0200)

----------------------------------------------------------------
ARM: devicetree changes for 5.13

There are six new SoCs added this time. Apple M1 and Nuvoton WPCM450
have separate branches because they are new SoC families that require
changes outside of device tree files. The other four are variations of
already supported chips and get merged through this branch:

 - STMicroelectronics STM32H750 is one of many variants of STM32
   microcontrollers based on the Cortex-M7 core. This is particularly
   notable since we rarely add support for new MMU-less chips
   these days. In this case, the board that gets added along with
   the platform is not a SoC reference platform but the "Art Pi"
   (https://art-pi.gitee.io/website/) machine that was originally design
   for the RT-Thread RTOS.

 - NXP i.MX8QuadMax is a variant of the growing i.MX8 embedded/industrial
   SoC family, using two Cortex-A72 and four Cortex-A53 cores. It
   gets added along with its reference board, the "NXP i.MX8QuadMax
   Multisensory Enablement Kit".

 - Qualcomm SC7280 is a Laptop SoC following the SC7180 (Snapdragon 7c)
   that is used in some Chromebooks and Windows laptops. Only a reference
   board is added for the moment.

 - TI AM64x Sita4ra is a new version of the K3 SoC family for industrial
   control, motor control, remote IO, IoT gateway etc., similar to the
   older AM65x family. Two reference machines are added alongside.

Among the newly added machines, there is a very clear skew towards 64-bit
machines now, with 12 32-bit machines compared to 23 64-bit machines. The
full list sorted by SoC is:

 - ASpeed AST2500 BMC: ASRock E3C246D4I Xeon server board
 - Allwinner A10: Topwise A721 Tablet
 - Amlogic GXL: MeCool KII TV box
 - Amlogic GXM: Mecool KIII, Minix Neo U9-H TV boxes
 - Broadcom BCM4908: TP-Link Archer C2300 V1 router
 - MStar SSD202D: M5Stack UnitV2 camera
 - Marvell Armada 38x: ATL-x530 ethernet switch
 - Mediatek MT8183 Chromebooks: Lenovo 10e, Acer Spin 311,
   Asus Flip CM3, Asus Detachable CM3
 - Mediatek MT8516/MT8183: OLogic Pumpkin Board
 - NXP i.MX7: reMarkable Tablet
 - NXP i.MX8M: Kontron pitx-imx8m, Engicam i.Core MX8M Mini
 - Nuvoton NPCM730: Quanta GBS BMC
 - Qualcomm X55: Telit FN980 TLB SoM, Thundercomm TurboX T55 SoM
 - Qualcomm MSM8998: OnePlus 5/5T phones
 - Qualcomm SM8350: Snapdragon 888 Mobile Hardware Development Kit
 - Rockchip RK3399: NanoPi R4S board
 - STM32MP1: Engicam MicroGEA STM32MP1 MicroDev 2.0 and SOM,
   EDIMM2.2 Starter Kit, Carrier, SOM
 - TI AM65: Siemens SIMATIC IOT2050 gateway

There is notable work going into extending already supported machines
and SoCs:

 - ASpeed AST2500
 - Allwinner A23, A83t, A31, A64, H6
 - Amlogic G12B
 - Broadcom BCM4908
 - Marvell Armada 7K/8K/CN91xx
 - Mediatek MT6589, MT7622, MT8173, MT8183, MT8195
 - NXP i.MX8Q, i.MX8MM, i.MX8MP
 - Qualcomm MSM8916, SC7180, SDM845, SDX55, SM8350
 - Renesas R-Car M3, V3U
 - Rockchip RK3328, RK3399
 - STEricsson U8500
 - STMicroelectronics STM32MP141
 - Samsung Exynos 4412
 - TI K3-AM65, K3-J7200
 - TI OMAP3

Among the treewide cleanups and bug fixes, two parts stand out:

 - There are a number of cleanups for issues pointed out by 'make
   dtbs_check' this time, and I expect more to come in the future as we
   increasingly check for regressions.

 - After a change to the MMC subsystem that can lead to unpredictable
   device numbers, several platforms add 'aliases' properties for these
   to give each MMC controller a fixed number.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Abhishek Kumar (1):
      arm64: dts: qcom: sc7180: add GO_LAZOR variant property for lazor

Adam Ford (1):
      arm64: dts: imx8mn-beacon: Enable SDR104 on WiFi SDIO interface

Adrien Grassein (9):
      arm64: dts: imx8mm-nitrogen-r2: add wifi/bt chip
      arm64: dts: imx8mm-nitrogen-r2: rework USDHC1
      arm64: dts: imx8mm-nitrogen-r2: add USB support
      arm64: dts: imx8mm-nitrogen-r2: add UARTs
      arm64: dts: imx8mm-nitrogen-r2: rework UART 2
      arm64: dts: imx8mm-nitrogen-r2: add PWMs
      arm64: dts: imx8mm-nitrogen-r2: add FlexSPI
      arm64: dts: imx8mm-nitrogen-r2: add audio
      arm64: dts: imx8mm-nitrogen-r2: add ecspi2 support

Ajit Pandey (1):
      arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver

Alain Volmat (1):
      ARM: dts: stm32: enable the analog filter for all I2C nodes in stm32mp151

Alex Elder (1):
      ARM: dts: qcom: sdx55: add IPA information

Alexander Shiyan (8):
      ARM: dts: imx6qdl-ts7970: Drop redundant "fsl,mode" option
      ARM: dts: imx6qdl-phytec-pbab01: Select synchronous mode for AUDMUX
      ARM: dts: imx6ql-pfla02: Move "hog" pins into corresponded pin groups
      ARM: dts: clps711x: Add SYSCON nodes where it is used
      ARM: dts: clps711x: Add keypad node
      ARM: dts: clps711x: Fix serial port names
      ARM: dts: clps711x: edb7211: Add unit-address to memory node
      ARM: dts: clps711x: Add an empty chosen node to top level DTSI

Alexander Stein (1):
      arm64: dts: amlogic: Assign a fixed index to mmc devices

Alexandre Torgue (2):
      ARM: dts: stm32: add new instances for stm32h743 MCU
      ARM: dts: stm32: fix i2c node typo in stm32h743

Alexandru M Stan (1):
      arm64: dts: qcom: sc7180-trogdor: Remove fp control pins in prep
for coachz

Alexey Minnekhanov (2):
      ARM: dts: qcom: msm8974: add blsp2_uart8
      ARM: dts: qcom: msm8974-klte: Add bluetooth support

Alistair Francis (3):
      dt-bindings: Add vendor prefix for reMarkable
      dt-bindings: arm: fsl: Add the reMarkable 2 e-Ink tablet
      ARM: imx7d-remarkable2: Initial device tree for reMarkable2

Alpana Kumari (2):
      ARM: dts: aspeed: rainier: Add presence GPIOs
      ARM: dts: aspeed: everest: GPIOs support

Andreas Kemnade (1):
      ARM: dts: imx6sl-tolino-shine2hd: Add Netronix embedded controller

Andr? Hentschel (2):
      ARM: dts: omap3-echo: Update LED configuration
      ARM: dts: omap3-echo: Add ath6kl node

Angus Ainslie (1):
      arm64: dts: librem5: protect some partitions of the nor-flash

Arnd Bergmann (39):
      Merge tag 'renesas-arm-dt-for-v5.13-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into
arm/dt
      Merge tag 'omap-for-v5.13/dts-genpd-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/dt
      Merge tag 'socfpga_dts_update_for_v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into
arm/dt
      Merge tag 'arm-soc/for-5.13/devicetree' of
https://github.com/Broadcom/stblinux into arm/dt
      Merge tag 'arm-soc/for-5.13/devicetre-arm64' of
https://github.com/Broadcom/stblinux into arm/dt
      Merge tag 'imx-bindgins-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/dt
      Merge tag 'imx-dt-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/dt
      Merge tag 'imx-dt64-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into
arm/dt
      Merge tag 'juno-updates-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into
arm/dt
      Merge tag 'ux500-dts-v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik
into arm/dt
      Merge tag 'stm32-dt-for-v5.13-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into
arm/dt
      Merge tag 'tegra-for-5.13-dt-bindings' of
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
      Merge tag 'tegra-for-5.13-arm-dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
      Merge tag 'tegra-for-5.13-arm64-dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
      Merge tag 'v5.12-next-dts32' of
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into
arm/dt
      Merge tag 'v5.12-next-dts64' of
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into
arm/dt
      Merge tag 'renesas-arm-dt-for-v5.13-tag2' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into
arm/dt
      Merge tag 'sunxi-dt-for-5.13-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/dt
      Merge tag 'mvebu-dt64-5.13-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into
arm/dt
      Merge tag 'qcom-arm64-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
      Merge tag 'ti-k3-dt-for-v5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/dt
      Merge tag 'amlogic-dt64' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic
into arm/dt
      Merge tag 'omap-for-v5.13/dt-v2-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
arm/dt
      Merge tag 'samsung-dt-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt
      Merge tag 'samsung-dt64-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt
      Merge tag 'at91-dt-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/dt
      Merge tag 'mvebu-dt-5.13-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into
arm/dt
      Merge tag 'bmc-5.13-devicetree' of
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt
      ARM: dts: mvebu: fix SPI device node
      ARM: dts: clps711x: fix missing interrupt parent
      Merge tag 'qcom-dts-for-5.13' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
      Merge tag 'qcom-arm64-for-5.13-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
      Merge tag 'amlogic-dt64-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic
into arm/dt
      Merge tag 'v5.13-rockchip-dts32' of
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip
into arm/dt
      Merge tag 'v5.13-rockchip-dts64' of
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip
into arm/dt
      Merge tag 'zynqmp-dt-for-v5.13' of
https://github.com/Xilinx/linux-xlnx into arm/dt
      Merge tag 'qcom-dts-for-5.13-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
      Merge tag 'qcom-arm64-for-5.13-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
      Merge tag 'bmc-5.13-devicetree-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt

Aryan Srivastava (1):
      ARM: dts: mvebu: Add device tree for ATL-x530 Board

Aswath Govindraju (7):
      arm64: dts: ti: k3-j721e-main: Update the speed modes supported
and their itap delay values for MMCSD subsystems
      arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM
      arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
      arm64: dts: ti: k3-am642-evm: Add USB support
      arm64: dts: ti: k3-am64: Add GPIO DT nodes
      arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware usage
      arm64: dts: ti: k3-j7200: Add support for higher speed modes and
update delay select values for MMCSD subsystems

Bhaskar Chowdhury (1):
      ARM: dts: at91: Fix a typo

Bjorn Andersson (3):
      arm64: dts: qcom: Introduce SM8350 HDK
      dt-bindings: arm: qcom: Add SM8350 HDK
      arm64: dts: qcom: pm8150: Enable RTC

Boris Lysov (1):
      arm: mediatek: dts: activate SMP for mt6589

Brandon Wyman (2):
      ARM: dts: aspeed: rainier: Add gpio-keys-polled for fans
      ARM: dts: aspeed: everest: Add power supply i2c devices

Bryan O'Donoghue (1):
      arm64: dts: qcom: sm8250: Add venus DT node

Caleb Connolly (2):
      arm64: dts: qcom: sm8150: add other QUP nodes and iommus
      arm64: dts: qcom: sm8150: add i2c nodes

Cameron Nemo (1):
      arm64: dts: rockchip: add rk3328 dwc3 usb controller node

Christian Hewitt (6):
      dt-bindings: arm: amlogic: add support for the Minix NEO U9-H
      arm64: dts: meson: add initial device-tree for Minix NEO U9-H
      dt-bindings: arm: amlogic: add MeCool KII/KIII Pro bindings
      arm64: dts: meson: add initial device-tree for MeCool KII Pro
      arm64: dts: meson: add initial device-tree for MeCool KIII Pro
      arm64: dts: meson: remove extra tab from ODROID N2/N2+ ext_mdio node

Chunfeng Yun (11):
      arm64: dts: mt8183: update wakeup register offset
      arm64: dts: mt8173: fix property typo of 'phys' in dsi node
      arm64: dts: mediatek: mt8173: fix dtbs_check warning
      arm64: dts: mediatek: mt2712: harmonize node names
      arm64: dts: mediatek: mt8516: harmonize node names and compatibles
      arm64: dts: mediatek: mt7622: harmonize node names and compatibles
      arm64: dts: mediatek: mt8183: fix dtbs_check warning
      arm: dts: mt7629: harmonize node names and compatibles
      arm: dts: mt7623: harmonize node names and compatibles
      arm: dts: mt2701: harmonize node names and compatibles
      arm64: dts: mt8173: fix wrong power-domain phandle of pmic

Cristian Ciocaltea (1):
      ARM: dts: owl-s500-roseapplepi: Add ATC2603C PMIC

Daniel Palmer (6):
      ARM: mstar: Select MSTAR_MSC313_MPLL
      ARM: mstar: Add the external clocks to the base dsti
      ARM: mstar: Add mpll to base dtsi
      dt-bindings: vendor-prefixes: Add vendor prefix for M5Stack
      dt-bindings: arm: mstar: Add compatible for M5Stack UnitV2
      ARM: dts: mstar: Add a dts for M5Stack UnitV2

Dario Binacchi (1):
      ARM: dts: am33xx-l4: fix tscadc at 0 node indentation

Dave Gerlach (4):
      dt-bindings: arm: ti: Add bindings for AM642 SoC
      dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64
      arm64: dts: ti: Add support for AM642 SoC
      arm64: dts: ti: Add support for AM642 EVM

Dien Pham (1):
      arm64: dts: renesas: salvator-common: Add cpu-supply property to
a57_0 node

Dima Azarkin (1):
      ARM: dts: imx6qdl-wandboard: add scl/sda gpios definitions for
i2c bus recovery

Dinh Nguyen (1):
      arm64: dts: intel: adjust qpsi read-delay property

Dmitry Baryshkov (8):
      arm64: dts: qcom: sm8250: split spi pinctrl config
      arm64: dts: qcom: sm8250: further split of spi pinctrl config
      arm64: dts: qcom: sm8250: add pinctrl for SPI using GPIO as a CS
      arm64: dts: qcom: qrb5165-rb5: switch into using GPIO for SPI0 CS
      arm64: dts: qcom: sdm845: add required clocks on the gcc
      arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode
      arm64: dts: qcom: use dp_phy to provide clocks to dispcc
      arm64: dts: sdm845-db845c: make firmware filenames follow linux-firmware

Dmitry Osipenko (15):
      ARM: tegra: ventana: Support CPU and Core voltage scaling
      ARM: tegra: ventana: Support CPU thermal throttling
      ARM: tegra: cardhu: Support CPU frequency and voltage scaling on
all board variants
      ARM: tegra: cardhu: Support CPU thermal throttling
      ARM: tegra: paz00: Enable full voltage scaling ranges for CPU
and Core domains
      ARM: tegra: acer-a500: Enable core voltage scaling
      ARM: tegra: acer-a500: Reduce thermal throttling hysteresis to 0.2C
      ARM: tegra: acer-a500: Specify all CPU cores as cooling devices
      ARM: tegra: acer-a500: Rename avdd to vdda of touchscreen node
      ARM: tegra: nexus7: Specify all CPU cores as cooling devices
      ARM: tegra: ouya: Specify all CPU cores as cooling devices
      ARM: tegra: Specify CPU suspend OPP in device-tree
      ARM: tegra: Specify memory suspend OPP in device-tree
      ARM: tegra: Specify tps65911 as wakeup source
      ARM: tegra: acer-a500: Add atmel,wakeup-method property

Dong Aisheng (16):
      dt-bindings: arm: fsl: add imx8qm boards compatible string
      dt-bindings: mailbox: mu: add imx8qm support
      arm64: dts: imx8qxp: add fallback compatible string for scu pd
      arm64: dts: imx8qxp: move scu pd node before scu clock node
      arm64: dts: imx8qxp: orginize dts in subsystems
      arm64: dts: imx8: add lsio lpcg clocks
      arm64: dts: imx8: add conn lpcg clocks
      arm64: dts: imx8: add adma lpcg clocks
      arm64: dts: imx8: switch to two cell scu clock binding
      arm64: dts: imx8: switch to new lpcg clock binding
      arm64: dts: imx8qm: add lsio ss support
      arm64: dts: imx8qm: add conn ss support
      arm64: dts: imx8: split adma ss into dma and audio ss
      arm64: dts: imx8qm: add dma ss support
      arm64: dts: imx: add imx8qm common dts file
      arm64: dts: imx: add imx8qm mek support

Douglas Anderson (9):
      arm64: dts: qcom: Move sc7180 MI2S config to board files and make pulldown
      arm64: dts: qcom: Prep sc7180-trogdor trackpad IRQ for new boards
      arm64: dts: qcom: Unify the sc7180-trogdor panel nodes
      arm64: dts: qcom: Add sc7180-lazor-limozeen skus
      arm64: dts: qcom: Add sc7180-trogdor-pompom skus
      arm64: dts: qcom: Add sc7180-trogdor-coachz skus
      arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor
      arm64: dts: qcom: sc7180: coachz: Add "dmic_clk_en"
      arm64: dts: qcom: sc7180: pompom: Add "dmic_clk_en" + sound model

Drew Fustini (2):
      ARM: dts: am335x-pocketbeagle: unique gpio-line-names
      ARM: dts: am335x-boneblack.dts: unique gpio-line-names

Eddie James (11):
      ARM: dts: aspeed: rainier: Add additional processor CFAMs
      ARM: dts: aspeed: rainier: Enable fan watchdog
      ARM: dts: aspeed: rainier 4U: Fix fan configuration
      ARM: dts: aspeed: everest: Add FSI CFAMs and re-number engines
      ARM: dts: aspeed: everest: Add RTC
      ARM: dts: aspeed: everest: Enable fan watchdog
      ARM: dts: aspeed: Add Rainier 1S4U machine
      ARM: dts: aspeed: Rainier: Fix PCA9552 on bus 8
      ARM: dts: aspeed: Rainier: Fix humidity sensor bus address
      ARM: dts: aspeed: Rainier 1S4U: Fix fan nodes
      ARM: dts: aspeed: Rainier: Update to pass 2 hardware

Fabien Parent (4):
      dt-bindings: arm64: dts: mediatek: Add mt8516-pumpkin board
      dt-bindings: arm64: dts: mediatek: Add mt8183-pumpkin board
      arm64: dts: mt8183: add mt8183 pumpkin board
      arm64: dts: mediatek: fix reset GPIO level on pumpkin

Fabio Estevam (5):
      arm64: dts: imx8mm-nitrogen-r2: Pass the i2c3 unit name
      ARM: dts: imx53-qsb: Describe the esdhc1 card detect pin
      ARM: dts: imx6dl-plybas: Fix gpio-keys W=1 warnings
      ARM: dts: imx7d-mba7: Remove unsupported PCI properties
      arm64: dts: imx8mp-evk: Improve the Ethernet PHY description

Faiz Abbas (2):
      arm64: dts: ti: k3-j7200: Add gpio nodes
      arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules

Geert Uytterhoeven (15):
      ARM: dts: renesas: Group tuples in APMU cpus properties
      ARM: dts: renesas: Group tuples in playback and capture properties
      ARM: dts: renesas: Group tuples in pin control properties
      arm64: dts: renesas: Group tuples in playback and capture properties
      arm64: dts: renesas: Group tuples in pin control properties
      arm64: dts: renesas: Consolidate Salvator-X(S) HDMI0 handling
      ARM: dts: rza2mevb: Upstream Linux requires SDRAM
      arm64: dts: renesas: falcon: Add I2C EEPROM nodes
      arm64: dts: renesas: falcon: Add CSI/DSI sub-board
      arm64: dts: renesas: falcon: Add Ethernet sub-board
      arm64: dts: renesas: falcon: Move console config to CPU board DTS
      arm64: dts: renesas: falcon: Move watchdog config to CPU board DTS
      arm64: dts: renesas: falcon: Move AVB0 to main DTS
      ARM: dts: koelsch: Configure pull-up for SOFT_SW GPIO keys
      arm64: dts: renesas: r8a77950: Drop operating points above 1.5 GHz

George Hung (1):
      ARM: dts: nuvoton: Add Quanta GBS BMC Device Tree

Grygorii Strashko (1):
      arm64: dts: ti: k3-am64-main: add main CPTS entry

Guido G?nther (8):
      arm64: dts: imx8mq-librem5-devkit: Drop buck3 startup-ramp-delay
      arm64: dts: librem5: Drop assigned-clocks from SAI2
      arm64: dts: librem5-devkit: Use a less generic codec name
      arm64: dts: librem5-devkit: Add speaker amplifier
      arm64: dts: librem5-devkit: "Drop Line In Jack"
      arm64: dts: librem5-devkit: Add mux for built-in vs headset mic
      arm64: dts: librem5-devkit: Move headphone detection to sound card
      arm64: dts: imx8mq-librem5: Hog the correct gpio

Heiko Stuebner (11):
      arm64: dts: rockchip: synchronize rk3399 opps with vendor kernel
      arm64: dts: rockchip: used range'd gpu opps on rk3399
      arm64: dts: rockchip: drop separate opp table on rk3399-puma
      arm64: dts: rockchip: add phandle to timer0 on rk3368
      ARM: dts: rockchip: move rk322x mmcx aliases to board dts files
      ARM: dts: rockchip: move rv1108 mmcx aliases to board dts files
      arm64: dts: rockchip: move mmc aliases to board dts on px30
      arm64: dts: rockchip: move mmc aliases to board dts on rk3308
      arm64: dts: rockchip: move mmc aliases to board dts on rk3328
      arm64: dts: rockchip: move mmc aliases to board dts on rk3368
      arm64: dts: rockchip: move mmc aliases to board dts on rk3399

Heiko Thiery (2):
      dt-bindings: arm: fsl: add Kontron pITX-imx8m board
      arm64: dts: fsl: add support for Kontron pitx-imx8m board

Horia Geant? (1):
      ARM: dts: ls1021a: mark crypto engine dma coherent

Hsin-Yi Wang (9):
      arm64: dts: mediatek: mt8183: evb: Add domain supply for mfg
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-damu
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-juniper
      arm64: dts: mt8183: Add kukui-jacuzzi-damu board
      arm64: dts: mt8183: Add kukui-jacuzzi-juniper board
      arm64: dts: mt8183: Add gce client reg for display subcomponents
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-kakadu
      dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-kodama
      arm64: dts: mt8183: Add kukui kodama board

Hyeonki Hong (2):
      arm64: dts: meson: add saradc node to ODROID N2/N2+
      arm64: dts: meson: add GPIO line names to ODROID N2/N2+

Ian Ray (1):
      ARM: dts: imx: bx50v3: Define GPIO line names

JC Kuo (1):
      dt-bindings: phy: tegra-xusb: Add nvidia,pmc prop

Jack Pham (2):
      arm64: dts: qcom: sm8350: add USB and PHY device nodes
      arm64: dts: qcom: sm8350-mtp: enable USB nodes

Jagan Teki (15):
      dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0
      ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 SoM
      ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board
      dt-bindings: arm: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
      ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF
      dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0
      ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM
      ARM: dts: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0
      dt-bindings: arm: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
      ARM: dts: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit
      dt-bindings: arm: fsl: Add Engicam i.Core MX8M Mini C.TOUCH 2.0
      dt-bindings: arm: fsl: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit
      arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini SoM
      arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0
      arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit

Jami Kettunen (2):
      arm64: dts: qcom: msm8998: Disable MSS remoteproc by default
      arm64: dts: qcom: Add support for OnePlus 5/5T

Jan Kiszka (5):
      arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes
      arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
      dt-bindings: Add Siemens vendor prefix
      dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
      arm64: dts: ti: Add support for Siemens IOT2050 boards

Jernej Skrabec (1):
      ARM: dts: sun8i: h3: beelink-x2: Add power button

Jim Wright (1):
      ARM: dts: aspeed: everest: Add UCD90320 power sequencer

Joel Stanley (2):
      ARM: dts: aspeed: rainier: Add missing fan nodes
      ARM: dts: aspeed: everest: Add size/address cells

Johan Jonker (8):
      arm64: dts: rockchip: enable dwc3 usb for A95X Z2
      arm64: dts: rockchip: add new watchdog compatible to px30.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3308.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3328.dtsi
      arm64: dts: rockchip: add new watchdog compatible to rk3399.dtsi
      ARM: dts: rockchip: add new watchdog compatible to rv1108.dtsi
      ARM: dts: rockchip: add new watchdog compatible to rk322x.dtsi
      ARM: dts: rockchip: remove clock-names property from watchdog
node in rv1108.dtsi

Jonathan Marek (2):
      arm64: dts: qcom: sm8250: fix display nodes
      arm64: dts: qcom: update usb qmp phy clock-cells property

Jonathan Neusch?fer (1):
      ARM: dts: imx50-kobo-aura: Add Netronix embedded controller

Kevin Hilman (2):
      arm64: dts: amlogic: misc DT schema fixups
      dt-bindings: mali-bifrost: add dma-coherent

Kieran Bingham (3):
      arm64: dts: renesas: falcon-cpu: Add GP LEDs
      arm64: dts: renesas: r8a779a0: Add FCPVD support
      arm64: dts: renesas: r8a779a0: Add VSPD support

Konstantin Aladyshev (1):
      ARM: dts: aspeed: amd-ethanolx: Enable all used I2C busses

Konstantin Porotchkin (2):
      arm64: dts: marvell: add support for Marvell CP110 UTMI PHY
      arm64: dts: marvell: enable CP110 UTMI PHY usage

Krzysztof Kozlowski (25):
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on GT-I9100
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on
P4 Note family
      ARM: dts: exynos: correct fuel gauge interrupt trigger level on
Midas family
      ARM: dts: exynos: correct MUIC interrupt trigger level on Midas family
      ARM: dts: exynos: correct PMIC interrupt trigger level on Midas family
      ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid
X/U3 family
      ARM: dts: exynos: correct PMIC interrupt trigger level on P4 Note family
      ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250
      ARM: dts: exynos: correct PMIC interrupt trigger level on Snow
      ARM: dts: s5pv210: correct fuel gauge interrupt trigger level on
Fascinate family
      arm64: dts: exynos: re-order Slim SSS clocks to match dtschema
      ARM: dts: exynos: add input clock to CMU in Exynos4412 Odroid
      ARM: dts: exynos: replace deprecated NTC/Murata compatibles
      ARM: dts: exynos: white-space cleanups
      arm64: dts: exynos: white-space cleanups
      arm64: dts: intel: socfpga: override clocks by label
      arm64: dts: intel: socfpga_agilex: move clocks out of soc node
      arm64: dts: intel: socfpga_agilex: move timer out of soc node
      arm64: dts: intel: socfpga_agilex: remove default status=okay
      arm64: dts: intel: socfpga_agilex: move usbphy out of soc node
      arm64: dts: intel: socfpga_agilex: use defined for GIC interrupts
      arm64: dts: intel: socfpga_agilex: align node names with dtschema
      arm64: dts: intel: socfpga_agilex_socdk_nand: align LED node
names with dtschema
      ARM: dts: qcom: msm8974-lge-nexus5: correct fuel gauge interrupt
trigger level
      ARM: dts: qcom: msm8974-samsung-klte: correct fuel gauge
interrupt trigger level

Kuldeep Singh (2):
      arm64: dts: imx8mm: Reorder flexspi clock-names entry
      arm64: dts: imx8mn: Reorder flexspi clock-names entry

Kurt Kanzenbach (1):
      ARM: dts: stm32: Add PTP clock to Ethernet controller

Lad Prabhakar (2):
      ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Separate out ov5640 nodes
      ARM: dts: r8a7742-iwg21d-q7-dbcm-ca: Add support for 8-bit ov7725 sensors

Laurent Pinchart (1):
      arm64: dts: zynqmp: Add power domain for the DisplayPort DMA controller

Linus Walleij (10):
      ARM: dts: ux500: Fix BT+WLAN on Janice
      ARM: dts: ux500: Fix touchscreen on TVK R2
      ARM: dts: ux500: Move Synaptics to right include
      ARM: dts: ux500: Push sensors to TVK R2 board
      ARM: dts: ux500: Fix up TVK R3 sensors
      ARM: dts: ux500: Push TC35893 defines to each UIB
      ARM: dts: ux500: Totally separate TVK R2 and R3
      ARM: dts: ux500: Clarify UIB version per board
      ARM: dts: ux500: Bump AUX1 voltage
      ARM: dts: ux500: Add Cypress CTTYSP touch to TVK UIB

Lokesh Vutla (2):
      dt-bindings: arm: ti: Add bindings for AM642 SK
      arm64: dts: ti: Add support for AM642 SK

Luca Weiss (1):
      ARM: dts: qcom: msm8974-hammerhead: add mount matrix for IMU

Ludovic Desroches (1):
      ARM: dts: at91: change the key code of the gpio key

Maciej Matuszczyk (1):
      arm64: dts: rockchip: Add gpu opp nodes to px30 dtsi

Manivannan Sadhasivam (14):
      ARM: dts: qcom: sdx55: Add support for A7 PLL clock
      ARM: dts: qcom: sdx55: Add support for APCS block
      ARM: dts: qcom: sdx55: Add CPUFreq support
      ARM: dts: qcom: sdx55: Add modem SMP2P node
      ARM: dts: qcom: sdx55: Add IMEM and PIL info region
      dt-bindings: firmware: scm: Add compatible for SDX55
      ARM: dts: qcom: sdx55: Add SCM node
      ARM: dts: qcom: sdx55: Add interconnect nodes
      ARM: dts: qcom: Fix node name for NAND controller node
      ARM: dts: qcom: sdx55: Add Modem remoteproc node
      dt-bindings: arm: qcom: Add binding for Telit FN980 TLB board
      ARM: dts: qcom: sdx55: Add basic devicetree support for Telit FN980 TLB
      dt-bindings: arm: qcom: Add binding for Thundercomm T55 kit
      ARM: dts: qcom: sdx55: Add basic devicetree support for Thundercomm T55

Marek Beh?n (1):
      arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node

Marek Vasut (7):
      arm64: dts: imx8mp: add eqos node and alias
      arm64: dts: freescale: Add support EQOS MAC on phyBOARD-Pollux-i.MX8MP
      ARM: dts: stm32: Fill GPIO line names on DHCOM SoM
      ARM: dts: stm32: Fill GPIO line names on AV96
      ARM: dts: stm32: Update GPIO line names on DRC02
      ARM: dts: stm32: Update GPIO line names on PicoITX
      ARM: dts: stm32: Enable crc1 and cryp1 where applicable on DHSOM

Martin Kepplinger (1):
      arm64: dts: imx8mq-librem5-r2: set nearlevel to 120

Matthew Barth (2):
      ARM: dts: aspeed: everest: Add max31785 fan controller device
      ARM: dts: aspeed: everest: Add pca9552 fan presence

Matthias Brugger (2):
      arm64: dts: mt8183-pumpkin: fix dtbs_check warning
      arm64: dts: mt8183: fix dtbs_check warning

Matthias Kaehlcke (6):
      arm64: dts: qcom: sc7180: trogdor: Add label to charger thermal zone
      arm64: dts: qcom: sc7180: Disable charger thermal zone for lazor
      arm64: dts: qcom: sc7180: trogdor: Fix trip point config of
charger thermal zone
      arm64: dts: qcom: sc7180: trogdor: Use ADC TM channel 0 instead
of 1 for charger temperature
      arm64: dts: qcom: sc7180: Set up lazor r3+ as sc7180-lite SKUs
      arm64: dts: mt8183: Configure CPU cooling

Maulik Shah (3):
      arm64: dts: qcom: sc7280: Add RSC and PDC devices
      arm64: dts: qcom: sc7280: Add reserved memory for fw
      arm64: dts: qcom: sc7280: Add cpuidle states

Michael Walle (5):
      arm64: dts: ls1028a: add interrupt to Root Complex Event Collector
      arm64: dts: fsl-ls1028a-kontron-sl28: move MTD partitions
      arm64: dts: fsl-ls1028a-kontron-sl28: combine unused partitions
      arm64: dts: ls1028a: move rtc alias to individual boards
      arm64: dts: fsl-ls1028a-kontron-sl28: add rtc0 alias

Nichole Wang (1):
      ARM: dts: aspeed: mihawk: Add GPIO line names

Nicolas Boichat (1):
      arm64: dts: mt8183: Add kukui kakadu board

Nicolas Ferre (2):
      ARM: dts: at91: sama5d2: add ETB and ETM unit name
      ARM: dts: at91: sama5d2/trivial: fix letter case for etm hex address

Niklas S?derlund (2):
      arm64: dts: renesas: r8a779a0: Add thermal support
      arm64: dts: renesas: r8a77961: Add VIN and CSI-2 device nodes

Pascal Roeleven (2):
      dt-bindings: arm: Add Topwise A721
      ARM: dts: sun4i: Add support for Topwise A721 tablet

Paul Fertser (1):
      ARM: dts: aspeed: tiogapass: add hotplug controller

Peng Fan (3):
      dt-bindings: clock: imx8qxp-lpcg: correct the example clock-names
      arm64: dts: imx8qxp: correct usdhc clock-names sequence
      arm64: dts: imx8mp: add wdog2/3 nodes

Peter Ujfalusi (1):
      arm64: dts: ti: k3-am64-main: Enable DMA support

Philippe Schenker (1):
      ARM: dts: colibri-imx6ull: Change drive strength for usdhc2

Phong Hoang (2):
      arm64: dts: renesas: r8a779a0: Add TMU support
      arm64: dts: renesas: r8a779a0: Add CMT support

Pieter Beers (1):
      ARM: dts: sunxi: h2-plus-bananapi-m2-zero: Add HDMI out

Pratyush Yadav (6):
      arm64: dts: ti: k3-j721e-som-p0: Enable 8D-8D-8D mode on OSPI
      arm64: dts: ti: am654-base-board: Enable 8D-8D-8D mode on OSPI
      arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
      arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
      arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
      arm64: dts: ti: k3-am64-main: Fix ospi compatible

Priyanga Ramasamy (1):
      ARM: dts: aspeed: everest: Add I2C components

Quanyang Wang (1):
      arm64: dts: zynqmp: Remove si5328 device nodes

Rafa? Mi?ecki (15):
      arm64: dts: broadcom: bcm4908: describe USB PHY
      arm64: dts: broadcom: bcm4908: describe Ethernet controller
      arm64: dts: broadcom: bcm4908: describe Netgear R8000P switch
      arm64: dts: broadcom: bcm4908: add remaining Netgear R8000P LEDs
      arm64: dts: broadcom: bcm4908: describe firmware partitions
      arm64: dts: broadcom: bcm4908: fix switch parent node name
      dt-bindings: arm: bcm: document TP-Link Archer C2300 binding
      arm64: dts: broadcom: bcm4908: add TP-Link Archer C2300 V1
      arm64: dts: broadcom: bcm4908: set Asus GT-AC5300 port 7 PHY mode
      arm64: dts: broadcom: bcm4908: add Ethernet TX irq
      ARM: dts: BCM5301X: fix "reg" formatting in /memory node
      ARM: dts: BCM5301X: Describe NVMEM NVRAM on Linksys & Luxul routers
      ARM: dts: BCM5301X: Fix Linksys EA9500 partitions
      ARM: dts: BCM5301X: Set Linksys EA9500 power LED
      arm64: dts: broadcom: bcm4908: add Ethernet MAC addr

Rajendra Nayak (4):
      dt-bindings: arm: qcom: Document sc7280 SoC and board
      arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc
      arm64: dts: qcom: SC7280: Add rpmhcc clock controller node
      arm64: dts: qcom: sc7280: Add rpmh power-domain node

Robert Foss (5):
      arm64: dts: qcom: sdm845: Add CAMSS ISP node
      arm64: dts: qcom: sdm845-db845c: Configure regulators for camss node
      arm64: dts: qcom: sdm845-db845c: Enable ov8856 sensor and connect to ISP
      arm64: dts: qcom: sm8350: Add thermal zones and throttling support
      arm64: dts: qcom: sm8350: Add support for PRNG EE

Robin Murphy (2):
      arm64: dts: juno: Describe PCI dma-ranges
      arm64: dts: juno: Enable more SMMUs

Russell King (3):
      arm64: dts: lx2160a-clearfog-itx: add SFP support
      arm64: dts: marvell: clearfog-gt-8k: add pwm-fan
      arm64: dts: marvell: clearfog-gt-8k: add cooling maps

Ryan Wu (1):
      dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC

Ryder Lee (1):
      arm64: dts: mt7622: add ePA/eLNA pinmux for built-in WiFi

Sai Prakash Ranjan (13):
      arm64: dts: qcom: sc7180: Rename the qmp node to power-controller
      arm64: dts: qcom: sdm845: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8250: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8350: Rename the qmp node to power-controller
      arm64: dts: qcom: sm8250: Fix level triggered PMU interrupt polarity
      arm64: dts: qcom: sm8350: Fix level triggered PMU interrupt polarity
      arm64: dts: qcom: sm8250: Fix timer interrupt to specify EL2
physical timer
      arm64: dts: qcom: sc7280: Add device node for APPS SMMU
      arm64: dts: qcom: sc7280: Add APSS watchdog node
      arm64: dts: qcom: sc7280: Add device tree node for LLCC
      arm64: dts: qcom: sc7280: Add IPCC for SC7280 SoC
      arm64: dts: qcom: sc7280: Add AOSS QMP node
      arm64: dts: qcom: sc7280: Add Coresight support

Samuel Holland (6):
      ARM: dts: sunxi: Use the new r_intc binding
      ARM: dts: sunxi: h3/h5: Add r_intc node
      ARM: dts: sunxi: Move wakeup-capable IRQs to r_intc
      arm64: dts: allwinner: Use the new r_intc binding
      arm64: dts: allwinner: Move wakeup-capable IRQs to r_intc
      arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

Sandeep Maheswaram (1):
      arm64: dts: qcom: sc7180: Use pdc interrupts for USB instead of
GIC interrupts

Sebastian Krzyszkowiak (1):
      arm64: dts: imx8mq-librem5-r3: Mark buck3 as always on

Sebastian Reichel (5):
      ARM: dts: imx: Mark IIM as syscon on i.MX51/i.MX53
      ARM: dts: imx6q-ba16: add USB OTG VBUS enable GPIO
      ARM: dts: imx6q-ba16: improve PHY information
      ARM: dts: imx: bx50v3: i2c GPIOs are open drain
      ARM: dts: motorola-cpcap-mapphone: Prepare for dtbs_check parsing

Seiya Wang (3):
      dt-bindings: timer: Add compatible for Mediatek MT8195
      dt-bindings: serial: Add compatible for Mediatek MT8195
      dt-bindings: arm: Add compatible for Mediatek MT8195

Serge Semin (1):
      ARM: dts: ls1021a: Harmonize DWC USB3 DT nodes name

Shawn Guo (4):
      arm64: dts: qcom: sdm845: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8250: fix number of pins in 'gpio-ranges'
      arm64: dts: qcom: sm8350: fix number of pins in 'gpio-ranges'

Srinivas Kandagatla (1):
      arm64: dts: qcom: db845c: fix correct powerdown pin for WSA881x

Srinivasa Rao Mandadapu (1):
      arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz

Stefan Riedmueller (2):
      ARM: dts: imx6: pfla02: Fix USB vbus enable pinmuxing
      ARM: dts: imx6: pbab01: Set USB OTG port to peripheral

Stephan Gerhold (1):
      arm64: dts: qcom: msm8916: Add GICv2 hypervisor registers/interrupt

Stephen Boyd (4):
      arm64: dts: qcom: sc7180: Update dts for DP phy inside QMP phy
      arm64: dts: qcom: trogdor: Only wakeup from pen eject
      arm64: dts: qcom: Disable camera clk on sc7180-trogdor devices by default
      arm64: dts: qcom: sc7180: Drop duplicate dp_hot_plug_det node in trogdor

Sujit Kautkar (1):
      arm64: dts: qcom: Move rmtfs memory region

Suman Anna (5):
      arm64: dts: ti: k3-am65-main: Add ICSSG nodes
      arm64: dts: ti: k3-j721e-main: Add ICSSG nodes
      arm64: dts: ti: k3-am64-main: Add hwspinlock node
      arm64: dts: ti: k3-am64-main: Add mailbox cluster nodes
      arm64: dts: ti: k3-am642-evm/sk: Add IPC sub-mailbox nodes

Sumit Semwal (1):
      arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits

Teresa Remmet (1):
      arm64: dts: imx8mp-phyboard-pollux-rdk: Change debug UART

Thomas Schneider (1):
      arm64: dts: rockchip: add infrared receiver node to rockpro64

Tianling Shen (2):
      dt-bindings: Add doc for FriendlyARM NanoPi R4S
      rockchip: rk3399: Add support for FriendlyARM NanoPi R4S

Tim Harvey (1):
      ARM: dts: imx6qdl-gw*: Remove unnecessary #address-cells/#size-cells

Timon Baetz (2):
      ARM: dts: exynos: add charger supply for I9100
      ARM: dts: exynos: Add front camera support to I9100

Tony Lindgren (46):
      bus: ti-sysc: Fix initializing module_pa for modules without sysc register
      bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first
      bus: ti-sysc: Detect more modules for debugging
      bus: ti-sysc: Check for old incomplete dtb
      ARM: OMAP2+: Init both prm and prcm nodes early for clocks
      soc: ti: omap-prm: Allow hardware supported retention when idle
      clk: ti: omap5: Add missing gpmc and ocmc clkctrl
      PCI: pci-dra7xx: Prepare for deferred probe with module_platform_driver
      ARM: dts: Update pcie ranges for dra7
      ARM: dts: Configure interconnect target module for dra7 pcie
      ARM: dts: Properly configure dra7 edma sysconfig registers
      ARM: dts: Move dra7 l3 noc to a separate node
      ARM: dts: Configure interconnect target module for dra7 qspi
      ARM: dts: Configure interconnect target module for dra7 sata
      ARM: dts: Configure interconnect target module for dra7 mpu
      ARM: dts: Configure interconnect target module for dra7 dmm
      ARM: dts: Configure simple-pm-bus for dra7 l4_wkup
      ARM: dts: Configure simple-pm-bus for dra7 l4_per1
      ARM: dts: Configure simple-pm-bus for dra7 l4_per2
      ARM: dts: Configure simple-pm-bus for dra7 l4_per3
      ARM: dts: Configure simple-pm-bus for dra7 l4_cfg
      ARM: dts: Configure simple-pm-bus for dra7 l3
      ARM: dts: Configure power-domain for omap4 gfx
      ARM: dts: Configure power-domain for omap4 dts iss
      ARM: dts: Configure interconnect target module for omap4 dmm
      ARM: dts: Configure interconnect target module for omap4 emif
      ARM: dts: Configure interconnect target module for omap4 debugss
      ARM: dts: Configure interconnect target module for omap4 mpu
      ARM: dts: Move omap4 mmio-sram out of l3 interconnect
      ARM: dts: Move omap4 l3-noc to a separate node
      ARM: dts: Configure simple-pm-bus for omap4 l4_wkup
      ARM: dts: Configure simple-pm-bus for omap4 l4_per
      ARM: dts: Configure simple-pm-bus for omap4 l4_cfg
      ARM: dts: Prepare for simple-pm-bus for omap4 l3
      ARM: dts: Configure interconnect target module for omap5 dmm
      ARM: dts: Configure interconnect target module for omap5 emif
      ARM: dts: Configure interconnect target module for omap5 mpu
      ARM: dts: Configure interconnect target module for omap5 gpmc
      ARM: dts: Configure interconnect target module for omap5 sata
      ARM: dts: Move omap5 mmio-sram out of l3 interconnect
      ARM: dts: Move omap5 l3-noc to a separate node
      ARM: dts: Configure simple-pm-bus for omap5 l4_wkup
      ARM: dts: Configure simple-pm-bus for omap5 l4_per
      ARM: dts: Configure simple-pm-bus for omap5 l4_cfg
      ARM: dts: Configure simple-pm-bus for omap5 l3
      Merge tags 'genpd-dts-dra7', 'genpd-dts-omap4' and
'genpd-dts-omap5' into omap-for-v5.13/dts-genpd

V Sujith Kumar Reddy (1):
      arm64: dts: qcom: sc7180: Update iommu property for simultaneous playback

Valentin CARON - foss (1):
      ARM: dts: stm32: fix usart 2 & 3 pinconf to wake up with flow control

Venkata Lakshmi Narayana Gubba (1):
      arm64: dts: qcom: sc7180: Remove clock for bluetooth on Trogdor

Vignesh Raghavendra (6):
      arm64: dts: ti: k3-am64-main: Add CPSW DT node
      arm64: dts: ti: k3-am642-evm: add CPSW3g DT nodes
      arm64: dts: ti: k3-am642-sk: Add CPSW DT nodes
      arm64: dts: ti: k3-am64-main: Add ADC nodes
      arm64: dts: ti: k3-am64-main: Add OSPI node
      arm64: dts: ti: k3-am64-evm/sk: Add OSPI flash DT node

Vinod Koul (26):
      arm64: dts: qcom: sm8350: Add apss_smmu node
      arm64: dts: qcom: sm8350: Add UFS nodes
      arm64: dts: qcom: sm8350-mtp: enable UFS nodes
      arm64: dts: qcom: sm8350-mtp: add regulator names
      arm64: dts: qcom: sm8350: fix typo
      arm64: dts: qcom: sm8350: Add rpmhpd node
      arm64: dts: qcom: sm8350: Add rmtfs node
      arm64: dts: qcom: sm8350: Add SMP2P nodes
      arm64: dts: qcom: sm8350: Add remoteprocs
      arm64: dts: qcom: sm8350-mtp: Enable remoteprocs
      arm64: dts: qcom: sm8350: Use enums for GCC
      arm64: dts: qcom: sm8350: Add cpufreq node
      arm64: dts: qcom: apq8016-sbc: drop qcom,sbc
      arm64: dts: qcom: msm8916: don't use empty memory node
      dt-bindings: arm: qcom: Document ipq6018-cp01 board
      arm64: dts: qcom: msm8994: don't use empty memory node
      dt-bindings: arm: qcom: Document sony boards for apq8094
      arm64: dts: qcom: sm8350: Add spmi node
      arm64: dts: qcom: pmk8350: Add base dts file
      arm64: dts: qcom: pm8350: Add base dts file
      arm64: dts: qcom: pm8350b: Add base dts file
      arm64: dts: qcom: pm8350c: Add base dts file
      arm64: dts: qcom: pmr735a: Add base dts file
      arm64: dts: qcom: pmr735B: Add base dts file
      arm64: dts: qcom: sm8350-mtp: Add PMICs
      arm64: dts: qcom: sm8350: Add interconnects

Vishwanatha Subbanna (1):
      ARM: dts: aspeed: rainier: Add directly controlled LEDs

Vladimir Barinov (1):
      arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding

Vladimir Oltean (1):
      arm64: dts: ls1028a: set up the real link speed for ENETC port 2

Yoshihiro Shimoda (4):
      ARM: dts: renesas: Add mmc aliases into R-Car Gen2 board dts files
      arm64: dts: renesas: Add mmc aliases into board dts files
      arm64: dts: renesas: r8a77961: Add CAN nodes
      arm64: dts: renesas: r8a779a0: Fix PMU interrupt

Yusuke Goda (1):
      arm64: dts: renesas: ulcb: Add cpu-supply property to a57_0 node

Yuya Hamamachi (1):
      arm64: dts: renesas: r8a77961-ulcb: add HDMI Display support

Zev Weiss (1):
      ARM: dts: aspeed: Add ASRock E3C246D4I BMC

dillon min (6):
      Documentation: arm: stm32: Add stm32h750 value line doc
      dt-bindings: arm: stm32: Add compatible strings for ART-PI board
      ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750
      ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6
      ARM: stm32: Add a new SoC - STM32H750
      dt-bindings: serial: stm32: Use 'type: object' instead of false
for 'additionalProperties'

jonathan at marek.ca (1):
      arm64: dts: qcom: sm8250: Add videocc DT node

michael.kao (1):
      arm64: dts: mt8183: add thermal zone node

satya priya (2):
      arm64: dts: qcom: sc7280: Add SPMI PMIC arbiter device for SC7280
      arm64: dts: qcom: sc7280: Add RPMh regulators for sc7280-idp

 Documentation/arm/index.rst                        |    1 +
 Documentation/arm/stm32/stm32h750-overview.rst     |   34 +
 Documentation/devicetree/bindings/arm/amlogic.yaml |    3 +
 .../devicetree/bindings/arm/bcm/brcm,bcm4908.yaml  |    1 +
 Documentation/devicetree/bindings/arm/fsl.yaml     |   16 +
 .../devicetree/bindings/arm/mediatek.yaml          |   36 +
 .../devicetree/bindings/arm/mstar/mstar.yaml       |    1 +
 Documentation/devicetree/bindings/arm/qcom.yaml    |   20 +
 .../devicetree/bindings/arm/rockchip.yaml          |    1 +
 .../devicetree/bindings/arm/stm32/stm32.yaml       |   21 +
 Documentation/devicetree/bindings/arm/sunxi.yaml   |    5 +
 Documentation/devicetree/bindings/arm/ti/k3.yaml   |    9 +
 .../devicetree/bindings/clock/imx8qxp-lpcg.yaml    |    6 +-
 .../devicetree/bindings/firmware/qcom,scm.txt      |    1 +
 .../devicetree/bindings/gpu/arm,mali-bifrost.yaml  |    2 +
 .../devicetree/bindings/mailbox/fsl,mu.yaml        |    5 +-
 Documentation/devicetree/bindings/media/rc.yaml    |    4 +
 .../devicetree/bindings/nvmem/mtk-efuse.txt        |    1 +
 .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   |    1 +
 .../devicetree/bindings/serial/mtk-uart.txt        |    1 +
 .../devicetree/bindings/serial/st,stm32-uart.yaml  |    3 +-
 .../bindings/timer/mediatek,mtk-timer.txt          |    1 +
 .../devicetree/bindings/vendor-prefixes.yaml       |    6 +
 arch/arm/boot/dts/Makefile                         |   18 +-
 arch/arm/boot/dts/am335x-boneblack.dts             |  132 +-
 arch/arm/boot/dts/am335x-pocketbeagle.dts          |  140 +-
 arch/arm/boot/dts/am33xx-l4.dtsi                   |   28 +-
 arch/arm/boot/dts/am33xx.dtsi                      |    3 +
 arch/arm/boot/dts/armada-385-atl-x530.dts          |  235 +++
 arch/arm/boot/dts/aspeed-bmc-amd-ethanolx.dts      |   30 +
 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts  |  202 +++
 .../arm/boot/dts/aspeed-bmc-facebook-tiogapass.dts |    5 +
 arch/arm/boot/dts/aspeed-bmc-ibm-everest.dts       | 1747 ++++++++++++++++++--
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier-1s4u.dts  |   14 +
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier-4u.dts    |   14 +
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts       |  748 ++++++++-
 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts        |   33 +
 arch/arm/boot/dts/at91-sam9x60ek.dts               |    3 +-
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts        |    3 +-
 arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts      |    3 +-
 arch/arm/boot/dts/at91-sama5d2_icp.dts             |    3 +-
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts          |    3 +-
 arch/arm/boot/dts/at91-sama5d2_xplained.dts        |    3 +-
 arch/arm/boot/dts/at91-sama5d3_xplained.dts        |    3 +-
 arch/arm/boot/dts/at91sam9260ek.dts                |    3 +-
 arch/arm/boot/dts/at91sam9g20ek_common.dtsi        |    3 +-
 arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts        |    4 +-
 arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts        |    4 +-
 arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts  |    4 +-
 arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts    |    5 +
 arch/arm/boot/dts/bcm4708-netgear-r6250.dts        |    4 +-
 arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts     |    4 +-
 arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts      |    4 +-
 arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts        |    4 +-
 arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts |    4 +-
 arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts  |    4 +-
 arch/arm/boot/dts/bcm47081-luxul-xwr-1200.dts      |    5 +
 arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts        |    4 +-
 arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts  |    4 +-
 arch/arm/boot/dts/bcm4709-linksys-ea9200.dts       |    9 +-
 arch/arm/boot/dts/bcm4709-netgear-r7000.dts        |    4 +-
 arch/arm/boot/dts/bcm4709-netgear-r8000.dts        |    4 +-
 arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts      |    4 +-
 arch/arm/boot/dts/bcm47094-linksys-panamera.dts    |   26 +-
 arch/arm/boot/dts/bcm47094-luxul-abr-4500.dts      |    9 +-
 arch/arm/boot/dts/bcm47094-luxul-xbr-4500.dts      |    9 +-
 arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dts      |    4 +-
 arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts      |    9 +-
 arch/arm/boot/dts/bcm47094-luxul-xwr-3150-v1.dts   |    9 +-
 arch/arm/boot/dts/bcm47094-netgear-r8500.dts       |    4 +-
 arch/arm/boot/dts/bcm47094-phicomm-k3.dts          |    4 +-
 arch/arm/boot/dts/dra7-l4.dtsi                     |   76 +-
 arch/arm/boot/dts/dra7.dtsi                        |  215 ++-
 arch/arm/boot/dts/ep7209.dtsi                      |   18 +-
 arch/arm/boot/dts/ep7211-edb7211.dts               |    2 +-
 arch/arm/boot/dts/exynos3250-monk.dts              |    4 +-
 arch/arm/boot/dts/exynos3250-rinato.dts            |    4 +-
 arch/arm/boot/dts/exynos4210-i9100.dts             |   56 +-
 arch/arm/boot/dts/exynos4412-midas.dtsi            |    6 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi    |    5 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts           |    3 +-
 arch/arm/boot/dts/exynos4412-p4note.dtsi           |    4 +-
 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi      |   48 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |    2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi      |    2 +-
 arch/arm/boot/dts/exynos5410-pinctrl.dtsi          |   28 +-
 arch/arm/boot/dts/imx50-kobo-aura.dts              |   16 +-
 arch/arm/boot/dts/imx51.dtsi                       |    2 +-
 arch/arm/boot/dts/imx53-qsb-common.dtsi            |    2 +
 arch/arm/boot/dts/imx53.dtsi                       |    2 +-
 arch/arm/boot/dts/imx6dl-plybas.dts                |    6 +-
 arch/arm/boot/dts/imx6q-b450v3.dts                 |    5 +
 arch/arm/boot/dts/imx6q-b650v3.dts                 |    5 +
 arch/arm/boot/dts/imx6q-b850v3.dts                 |    5 +
 arch/arm/boot/dts/imx6q-ba16.dtsi                  |   21 +
 arch/arm/boot/dts/imx6q-bx50v3.dtsi                |   12 +-
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi              |    2 -
 arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi       |    6 +-
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi       |   38 +-
 arch/arm/boot/dts/imx6qdl-ts7970.dtsi              |    1 -
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi           |   24 +-
 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts       |    7 +-
 arch/arm/boot/dts/imx6ull-colibri.dtsi             |   12 +-
 arch/arm/boot/dts/imx7d-mba7.dts                   |    2 -
 arch/arm/boot/dts/imx7d-remarkable2.dts            |  146 ++
 arch/arm/boot/dts/iwg20d-q7-common.dtsi            |    4 +-
 arch/arm/boot/dts/ls1021a.dtsi                     |    3 +-
 arch/arm/boot/dts/motorola-cpcap-mapphone.dtsi     |   59 +-
 .../boot/dts/mstar-infinity2m-ssd202d-unitv2.dts   |   25 +
 arch/arm/boot/dts/mstar-v7.dtsi                    |   23 +
 arch/arm/boot/dts/mt2701.dtsi                      |   19 +-
 arch/arm/boot/dts/mt6589.dtsi                      |    1 +
 arch/arm/boot/dts/mt7623.dtsi                      |   26 +-
 arch/arm/boot/dts/mt7623n.dtsi                     |    4 +-
 arch/arm/boot/dts/mt7629.dtsi                      |   12 +-
 arch/arm/boot/dts/nuvoton-npcm730-gbs.dts          | 1135 +++++++++++++
 arch/arm/boot/dts/omap3-echo.dts                   |  476 ++++--
 arch/arm/boot/dts/omap4-l4.dtsi                    |   39 +-
 arch/arm/boot/dts/omap4.dtsi                       |  170 +-
 arch/arm/boot/dts/omap4460.dtsi                    |   13 +-
 arch/arm/boot/dts/omap44xx-clocks.dtsi             |    8 -
 arch/arm/boot/dts/omap5-l4.dtsi                    |   67 +-
 arch/arm/boot/dts/omap5.dtsi                       |  209 ++-
 arch/arm/boot/dts/owl-s500-roseapplepi.dts         |  132 +-
 arch/arm/boot/dts/qcom-ipq4019.dtsi                |    2 +-
 .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts     |    6 +-
 arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts    |   52 +-
 arch/arm/boot/dts/qcom-msm8974.dtsi                |    9 +
 arch/arm/boot/dts/qcom-sdx55-t55.dts               |  281 ++++
 arch/arm/boot/dts/qcom-sdx55-telit-fn980-tlb.dts   |  282 ++++
 arch/arm/boot/dts/qcom-sdx55.dtsi                  |  207 ++-
 arch/arm/boot/dts/r7s9210-rza2mevb.dts             |   55 +-
 arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ca.dts    |  159 +-
 .../dts/r8a7742-iwg21d-q7-dbcm-ov5640-single.dtsi  |   32 +
 .../dts/r8a7742-iwg21d-q7-dbcm-ov7725-single.dtsi  |   29 +
 arch/arm/boot/dts/r8a7742-iwg21d-q7.dts            |    4 +-
 arch/arm/boot/dts/r8a7742.dtsi                     |    4 +-
 arch/arm/boot/dts/r8a7743-sk-rzg1m.dts             |    2 +-
 arch/arm/boot/dts/r8a7743.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a7744.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a7745-iwg22d-sodimm.dts        |    4 +-
 arch/arm/boot/dts/r8a7745-sk-rzg1e.dts             |    2 +-
 arch/arm/boot/dts/r8a7745.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a77470.dtsi                    |    2 +-
 arch/arm/boot/dts/r8a7790-lager.dts                |   11 +-
 arch/arm/boot/dts/r8a7790-stout.dts                |    4 +-
 arch/arm/boot/dts/r8a7790.dtsi                     |    4 +-
 arch/arm/boot/dts/r8a7791-koelsch.dts              |   19 +-
 arch/arm/boot/dts/r8a7791-porter.dts               |    6 +-
 arch/arm/boot/dts/r8a7791.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a7792-blanche.dts              |    2 +-
 arch/arm/boot/dts/r8a7792-wheat.dts                |    2 +-
 arch/arm/boot/dts/r8a7792.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a7793-gose.dts                 |   11 +-
 arch/arm/boot/dts/r8a7793.dtsi                     |    2 +-
 arch/arm/boot/dts/r8a7794-alt.dts                  |    5 +-
 arch/arm/boot/dts/r8a7794-silk.dts                 |    8 +-
 arch/arm/boot/dts/r8a7794.dtsi                     |    2 +-
 arch/arm/boot/dts/rk3228-evb.dts                   |    4 +
 arch/arm/boot/dts/rk3229-evb.dts                   |    4 +
 arch/arm/boot/dts/rk3229-xms6.dts                  |    6 +
 arch/arm/boot/dts/rk322x.dtsi                      |    5 +-
 arch/arm/boot/dts/rv1108-elgin-r1.dts              |    4 +
 arch/arm/boot/dts/rv1108-evb.dts                   |    4 +
 arch/arm/boot/dts/rv1108.dtsi                      |    6 +-
 arch/arm/boot/dts/s5pv210-fascinate4g.dts          |    2 +-
 arch/arm/boot/dts/sama5d2.dtsi                     |    6 +-
 arch/arm/boot/dts/sama5d3.dtsi                     |    2 +-
 arch/arm/boot/dts/ste-ab8500.dtsi                  |    4 +-
 arch/arm/boot/dts/ste-href-tvk1281618-r2.dtsi      |  214 ++-
 arch/arm/boot/dts/ste-href-tvk1281618-r3.dtsi      |  210 ++-
 arch/arm/boot/dts/ste-href-tvk1281618.dtsi         |  218 ---
 arch/arm/boot/dts/ste-href520-tvk.dts              |    4 +-
 arch/arm/boot/dts/ste-hrefprev60-tvk.dts           |    2 +-
 arch/arm/boot/dts/ste-hrefv60plus-tvk.dts          |    4 +-
 arch/arm/boot/dts/ste-ux500-samsung-janice.dts     |   48 +-
 arch/arm/boot/dts/stm32h7-pinctrl.dtsi             |  275 +++
 arch/arm/boot/dts/stm32h743-pinctrl.dtsi           |  306 ----
 arch/arm/boot/dts/stm32h743.dtsi                   |  177 +-
 arch/arm/boot/dts/stm32h743i-disco.dts             |    2 +-
 arch/arm/boot/dts/stm32h743i-eval.dts              |    2 +-
 arch/arm/boot/dts/stm32h750.dtsi                   |    6 +
 arch/arm/boot/dts/stm32h750i-art-pi.dts            |  229 +++
 arch/arm/boot/dts/stm32mp15-pinctrl.dtsi           |   21 +-
 arch/arm/boot/dts/stm32mp151.dtsi                  |    8 +
 arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dts      |    4 +
 .../dts/stm32mp157a-icore-stm32mp1-ctouch2.dts     |   47 +
 .../dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts    |   47 +
 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi  |  196 +++
 ...m32mp157a-microgea-stm32mp1-microdev2.0-of7.dts |  154 ++
 .../stm32mp157a-microgea-stm32mp1-microdev2.0.dts  |   55 +
 .../boot/dts/stm32mp157a-microgea-stm32mp1.dtsi    |  148 ++
 arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dts       |    4 +
 arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dts    |    4 +
 arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi     |   12 +-
 arch/arm/boot/dts/stm32mp15xx-dhcom-picoitx.dtsi   |   12 +-
 arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi       |   64 +
 arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi |   35 +
 arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi       |    4 +
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts       |  242 +++
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts        |    2 +-
 arch/arm/boot/dts/sun6i-a31-m9.dts                 |    2 +-
 arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts   |    2 +-
 arch/arm/boot/dts/sun6i-a31.dtsi                   |    6 +-
 arch/arm/boot/dts/sun6i-a31s-primo81.dts           |    2 +-
 arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi     |    2 +-
 arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts   |    2 +-
 .../dts/sun6i-a31s-yones-toptech-bs1078-v2.dts     |    2 +-
 .../boot/dts/sun6i-reference-design-tablet.dtsi    |    2 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi               |    6 +-
 arch/arm/boot/dts/sun8i-a33-olinuxino.dts          |    2 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts     |    2 +-
 .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts  |    4 +-
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts       |    4 +-
 arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts   |    4 +-
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts          |    4 +-
 arch/arm/boot/dts/sun8i-a83t.dtsi                  |    5 +-
 .../boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts    |   25 +
 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts          |   11 +
 arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts       |    2 +-
 arch/arm/boot/dts/sun8i-r16-parrot.dts             |    2 +-
 .../boot/dts/sun8i-reference-design-tablet.dtsi    |    2 +-
 arch/arm/boot/dts/sunxi-h3-h5.dtsi                 |   12 +
 arch/arm/boot/dts/tegra124-peripherals-opp.dtsi    |    5 +
 arch/arm/boot/dts/tegra20-acer-a500-picasso.dts    |   16 +-
 arch/arm/boot/dts/tegra20-cpu-opp.dtsi             |    2 +
 arch/arm/boot/dts/tegra20-paz00.dts                |   14 +-
 arch/arm/boot/dts/tegra20-peripherals-opp.dtsi     |    1 +
 arch/arm/boot/dts/tegra20-ventana.dts              |   78 +-
 arch/arm/boot/dts/tegra30-apalis.dtsi              |    1 +
 .../dts/tegra30-asus-nexus7-grouper-common.dtsi    |   14 +-
 .../dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi   |    1 +
 arch/arm/boot/dts/tegra30-beaver.dts               |    1 +
 arch/arm/boot/dts/tegra30-cardhu-a04.dts           |   48 -
 arch/arm/boot/dts/tegra30-cardhu.dtsi              |   84 +-
 arch/arm/boot/dts/tegra30-colibri.dtsi             |    1 +
 arch/arm/boot/dts/tegra30-cpu-opp.dtsi             |    3 +
 arch/arm/boot/dts/tegra30-ouya.dts                 |   16 +-
 arch/arm/boot/dts/tegra30-peripherals-opp.dtsi     |    3 +
 arch/arm/mach-mstar/Kconfig                        |    1 +
 arch/arm/mach-omap2/pdata-quirks.c                 |   29 +-
 arch/arm/mach-omap2/sr_device.c                    |   75 +-
 arch/arm/mach-stm32/board-dt.c                     |    1 +
 .../dts/allwinner/sun50i-a64-amarula-relic.dts     |    2 +-
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts |    2 +-
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   |    2 +-
 .../boot/dts/allwinner/sun50i-a64-olinuxino.dts    |    2 +-
 .../boot/dts/allwinner/sun50i-a64-orangepi-win.dts |    2 +-
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |    2 +-
 .../boot/dts/allwinner/sun50i-a64-pinebook.dts     |    2 +-
 .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi   |    2 +-
 .../boot/dts/allwinner/sun50i-a64-pinetab.dts      |    2 +-
 .../boot/dts/allwinner/sun50i-a64-sopine.dtsi      |    2 +-
 .../boot/dts/allwinner/sun50i-a64-teres-i.dts      |    2 +-
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |    6 +-
 .../boot/dts/allwinner/sun50i-h6-beelink-gs1.dts   |   40 +-
 .../boot/dts/allwinner/sun50i-h6-orangepi-3.dts    |   16 +-
 .../boot/dts/allwinner/sun50i-h6-orangepi.dtsi     |   24 +-
 .../boot/dts/allwinner/sun50i-h6-pine-h64.dts      |    4 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi       |    8 +-
 arch/arm64/boot/dts/amlogic/Makefile               |    3 +
 arch/arm64/boot/dts/amlogic/meson-a1.dtsi          |    4 +-
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi         |    1 -
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi  |   20 +-
 .../arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts |    2 +-
 .../boot/dts/amlogic/meson-g12b-gtking-pro.dts     |    4 +-
 arch/arm64/boot/dts/amlogic/meson-g12b-gtking.dts  |    2 +-
 .../boot/dts/amlogic/meson-g12b-odroid-n2.dtsi     |   56 +-
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi          |    6 +
 .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts |    2 +-
 .../dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts |   86 +
 .../boot/dts/amlogic/meson-gxl-s905d-sml5442tw.dts |    8 +-
 .../boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts |  113 ++
 .../boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts   |  120 ++
 .../boot/dts/amlogic/meson-gxm-wetek-core2.dts     |    2 +-
 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi |    4 +-
 .../arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts |    2 +-
 arch/arm64/boot/dts/arm/juno-base.dtsi             |    5 +-
 arch/arm64/boot/dts/arm/juno-r1.dts                |    4 +
 arch/arm64/boot/dts/arm/juno-r2.dts                |    4 +
 arch/arm64/boot/dts/broadcom/bcm4908/Makefile      |    1 +
 .../broadcom/bcm4908/bcm4906-netgear-r8000p.dts    |  107 +-
 .../bcm4908/bcm4906-tplink-archer-c2300-v1.dts     |  182 ++
 .../broadcom/bcm4908/bcm4908-asus-gt-ac5300.dts    |   44 +-
 arch/arm64/boot/dts/broadcom/bcm4908/bcm4908.dtsi  |   47 +-
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi     |    2 +-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi         |    6 +-
 arch/arm64/boot/dts/freescale/Makefile             |    4 +
 .../dts/freescale/fsl-ls1028a-kontron-sl28.dts     |   80 +-
 arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts  |    1 +
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts  |    1 +
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi     |   12 +-
 .../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi |   24 +
 .../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi    |   64 +
 arch/arm64/boot/dts/freescale/imx8-ss-adma.dtsi    |    8 +
 arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi   |   68 +
 arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi    |  184 +++
 arch/arm64/boot/dts/freescale/imx8-ss-ddr.dtsi     |   18 +
 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi     |  202 +++
 arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi    |  311 ++++
 .../dts/freescale/imx8mm-icore-mx8mm-ctouch2.dts   |   97 ++
 .../dts/freescale/imx8mm-icore-mx8mm-edimm2.2.dts  |   97 ++
 .../boot/dts/freescale/imx8mm-icore-mx8mm.dtsi     |  232 +++
 .../boot/dts/freescale/imx8mm-nitrogen-r2.dts      |  314 +++-
 arch/arm64/boot/dts/freescale/imx8mm.dtsi          |    2 +-
 .../boot/dts/freescale/imx8mn-beacon-som.dtsi      |    6 +-
 arch/arm64/boot/dts/freescale/imx8mn.dtsi          |    2 +-
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts       |    2 +
 .../dts/freescale/imx8mp-phyboard-pollux-rdk.dts   |   56 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi          |   39 +
 .../dts/freescale/imx8mq-kontron-pitx-imx8m.dts    |  613 +++++++
 .../boot/dts/freescale/imx8mq-librem5-devkit.dts   |   70 +-
 .../arm64/boot/dts/freescale/imx8mq-librem5-r2.dts |    2 +-
 .../arm64/boot/dts/freescale/imx8mq-librem5-r3.dts |    4 +
 arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi  |   24 +-
 arch/arm64/boot/dts/freescale/imx8qm-mek.dts       |  144 ++
 arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi  |   21 +
 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi   |   51 +
 arch/arm64/boot/dts/freescale/imx8qm-ss-lsio.dtsi  |   61 +
 arch/arm64/boot/dts/freescale/imx8qm.dtsi          |  176 ++
 arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts    |   20 +-
 .../dts/freescale/imx8qxp-colibri-eval-v3.dtsi     |    8 +-
 arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi |   12 +-
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts      |   50 +-
 arch/arm64/boot/dts/freescale/imx8qxp-ss-adma.dtsi |   37 +
 arch/arm64/boot/dts/freescale/imx8qxp-ss-conn.dtsi |   25 +
 arch/arm64/boot/dts/freescale/imx8qxp-ss-lsio.dtsi |   61 +
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi         |  423 +----
 arch/arm64/boot/dts/intel/socfpga_agilex.dtsi      |  222 +--
 arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dts |   14 +-
 .../boot/dts/intel/socfpga_agilex_socdk_nand.dts   |   18 +-
 arch/arm64/boot/dts/intel/socfpga_n5x_socdk.dts    |   12 +-
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       |    3 +-
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |   14 +-
 .../dts/marvell/armada-8040-clearfog-gt-8k.dts     |  127 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts     |   21 +-
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dtsi |   19 +-
 arch/arm64/boot/dts/marvell/armada-cp11x.dtsi      |   19 +
 arch/arm64/boot/dts/marvell/cn9130-db.dts          |   12 +-
 arch/arm64/boot/dts/marvell/cn9131-db.dts          |    9 +-
 arch/arm64/boot/dts/marvell/cn9132-db.dts          |   11 +-
 arch/arm64/boot/dts/mediatek/Makefile              |    8 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi          |    8 +-
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts       |   12 +
 arch/arm64/boot/dts/mediatek/mt7622.dtsi           |    9 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts        |    6 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   15 +-
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts        |    4 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-damu.dts     |   31 +
 .../mt8183-kukui-jacuzzi-juniper-sku16.dts         |   13 +
 .../dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi |   27 +
 .../boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi    |  474 ++++++
 .../boot/dts/mediatek/mt8183-kukui-kakadu.dts      |   13 +
 .../boot/dts/mediatek/mt8183-kukui-kakadu.dtsi     |  378 +++++
 .../dts/mediatek/mt8183-kukui-kodama-sku16.dts     |   21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku272.dts    |   21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku288.dts    |   21 +
 .../dts/mediatek/mt8183-kukui-kodama-sku32.dts     |   21 +
 .../boot/dts/mediatek/mt8183-kukui-kodama.dtsi     |  343 ++++
 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts    |  378 +++++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi           |  160 +-
 arch/arm64/boot/dts/mediatek/mt8516.dtsi           |    9 +-
 arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi   |    3 +-
 arch/arm64/boot/dts/qcom/Makefile                  |   15 +
 arch/arm64/boot/dts/qcom/apq8016-sbc.dts           |    2 +-
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |    8 +-
 arch/arm64/boot/dts/qcom/msm8994.dtsi              |    4 +-
 arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi    |    4 +
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi          |    4 +
 .../boot/dts/qcom/msm8998-oneplus-cheeseburger.dts |   42 +
 .../boot/dts/qcom/msm8998-oneplus-common.dtsi      |  514 ++++++
 .../boot/dts/qcom/msm8998-oneplus-dumpling.dts     |   25 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi              |    2 +
 arch/arm64/boot/dts/qcom/pm8150.dtsi               |    4 +-
 arch/arm64/boot/dts/qcom/pm8350.dtsi               |   25 +
 arch/arm64/boot/dts/qcom/pm8350b.dtsi              |   25 +
 arch/arm64/boot/dts/qcom/pm8350c.dtsi              |   25 +
 arch/arm64/boot/dts/qcom/pmk8350.dtsi              |   25 +
 arch/arm64/boot/dts/qcom/pmr735a.dtsi              |   25 +
 arch/arm64/boot/dts/qcom/pmr735b.dtsi              |   25 +
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts           |   18 +-
 .../boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dts |   18 +
 .../boot/dts/qcom/sc7180-trogdor-coachz-r1.dts     |  141 ++
 .../boot/dts/qcom/sc7180-trogdor-coachz-r2-lte.dts |   18 +
 .../boot/dts/qcom/sc7180-trogdor-coachz-r2.dts     |   15 +
 .../arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi |  266 +++
 .../qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dts |   34 +
 .../qcom/sc7180-trogdor-lazor-limozeen-nots.dts    |   26 +
 .../dts/qcom/sc7180-trogdor-lazor-limozeen.dts     |   42 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts      |    9 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts      |    9 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts   |    5 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts  |    4 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r3.dts      |   10 +
 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor.dtsi |   39 +-
 .../boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dts |   14 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r1.dts     |   26 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r2-lte.dts |   14 +
 .../boot/dts/qcom/sc7180-trogdor-pompom-r2.dts     |   44 +
 .../arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi |  295 ++++
 arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts     |   35 +-
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi       |  222 ++-
 arch/arm64/boot/dts/qcom/sc7180.dtsi               |   58 +-
 arch/arm64/boot/dts/qcom/sc7280-idp.dts            |  259 +++
 arch/arm64/boot/dts/qcom/sc7280.dtsi               | 1128 +++++++++++++
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts         |   31 +-
 .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts      |   71 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |  155 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi               |  555 ++++++-
 arch/arm64/boot/dts/qcom/sm8250-mtp.dts            |    4 -
 arch/arm64/boot/dts/qcom/sm8250.dtsi               |  676 ++++----
 arch/arm64/boot/dts/qcom/sm8350-hdk.dts            |  319 ++++
 arch/arm64/boot/dts/qcom/sm8350-mtp.dts            |  116 ++
 arch/arm64/boot/dts/qcom/sm8350.dtsi               | 1637 +++++++++++++++++-
 .../boot/dts/renesas/beacon-renesom-baseboard.dtsi |    4 +-
 arch/arm64/boot/dts/renesas/hihope-common.dtsi     |    3 +
 arch/arm64/boot/dts/renesas/hihope-rev4.dtsi       |    2 +-
 .../boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts |    3 +
 .../boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts |    3 +
 arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts    |    6 +-
 .../boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts |    3 +
 .../arm64/boot/dts/renesas/r8a77950-salvator-x.dts |   37 +-
 arch/arm64/boot/dts/renesas/r8a77950.dtsi          |    5 +
 .../arm64/boot/dts/renesas/r8a77951-salvator-x.dts |   37 +-
 .../boot/dts/renesas/r8a77951-salvator-xs.dts      |   37 +-
 .../arm64/boot/dts/renesas/r8a77960-salvator-x.dts |   46 -
 .../boot/dts/renesas/r8a77960-salvator-xs.dts      |   46 -
 .../boot/dts/renesas/r8a77961-salvator-xs.dts      |   46 -
 arch/arm64/boot/dts/renesas/r8a77961-ulcb.dts      |   11 +
 arch/arm64/boot/dts/renesas/r8a77961.dtsi          |  340 +++-
 .../arm64/boot/dts/renesas/r8a77965-salvator-x.dts |   45 -
 .../boot/dts/renesas/r8a77965-salvator-xs.dts      |   45 -
 arch/arm64/boot/dts/renesas/r8a77980.dtsi          |   16 +-
 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts     |    9 +-
 .../boot/dts/renesas/r8a779a0-falcon-cpu.dtsi      |   79 +-
 .../boot/dts/renesas/r8a779a0-falcon-csi-dsi.dtsi  |   15 +
 .../boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi |   15 +
 arch/arm64/boot/dts/renesas/r8a779a0-falcon.dts    |   50 +-
 arch/arm64/boot/dts/renesas/r8a779a0.dtsi          |  263 ++-
 arch/arm64/boot/dts/renesas/salvator-common.dtsi   |   52 +-
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi           |    1 +
 arch/arm64/boot/dts/renesas/ulcb.dtsi              |   12 +-
 arch/arm64/boot/dts/rockchip/Makefile              |    1 +
 .../boot/dts/rockchip/px30-engicam-common.dtsi     |    5 +
 .../boot/dts/rockchip/px30-engicam-px30-core.dtsi  |    4 +
 arch/arm64/boot/dts/rockchip/px30-evb.dts          |    6 +
 arch/arm64/boot/dts/rockchip/px30.dtsi             |   27 +-
 arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts     |    6 +
 arch/arm64/boot/dts/rockchip/rk3308.dtsi           |    5 +-
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts    |   11 +
 arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3328-a1.dts         |    5 +
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts        |    6 +
 arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts     |    5 +
 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts  |    5 +
 arch/arm64/boot/dts/rockchip/rk3328-rock64.dts     |    5 +
 arch/arm64/boot/dts/rockchip/rk3328.dtsi           |   24 +-
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi       |    4 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts    |    4 +
 .../arm64/boot/dts/rockchip/rk3368-lion-haikou.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3368-lion.dtsi      |    4 +
 .../boot/dts/rockchip/rk3368-orion-r68-meta.dts    |    5 +
 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts    |    5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts        |    5 +
 arch/arm64/boot/dts/rockchip/rk3368.dtsi           |    5 +-
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts        |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts    |    6 +
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       |    5 +
 arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts |    6 +
 .../boot/dts/rockchip/rk3399-khadas-edge.dtsi      |    6 +
 .../boot/dts/rockchip/rk3399-kobol-helios64.dts    |    5 +
 arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts  |    6 +
 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts |  133 ++
 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi   |    6 +
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi       |   40 +-
 arch/arm64/boot/dts/rockchip/rk3399-orangepi.dts   |    6 +
 .../boot/dts/rockchip/rk3399-pinebook-pro.dts      |    6 +
 .../arm64/boot/dts/rockchip/rk3399-puma-haikou.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi      |   55 +-
 .../boot/dts/rockchip/rk3399-roc-pc-mezzanine.dts  |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi    |    5 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |    5 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4c.dts |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi   |    6 +
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi |   19 +
 .../dts/rockchip/rk3399-sapphire-excavator.dts     |    4 +
 arch/arm64/boot/dts/rockchip/rk3399-sapphire.dtsi  |    5 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |    5 +-
 .../boot/dts/rockchip/rk3399pro-vmarc-som.dtsi     |    5 +
 arch/arm64/boot/dts/ti/Makefile                    |    8 +-
 arch/arm64/boot/dts/ti/k3-am64-main.dtsi           |  675 ++++++++
 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi            |  103 ++
 arch/arm64/boot/dts/ti/k3-am64.dtsi                |  105 ++
 arch/arm64/boot/dts/ti/k3-am642-evm.dts            |  468 ++++++
 arch/arm64/boot/dts/ti/k3-am642-sk.dts             |  334 ++++
 arch/arm64/boot/dts/ti/k3-am642.dtsi               |   65 +
 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi |  655 ++++++++
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi           |  395 +++++
 arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi            |    9 +
 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts |   61 +
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts     |    4 +-
 .../boot/dts/ti/k3-am6548-iot2050-advanced.dts     |   60 +
 .../boot/dts/ti/k3-j7200-common-proc-board.dts     |   94 ++
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi          |   86 +-
 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi    |   51 +
 arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi        |   36 +
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi          |  279 +++-
 arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi    |    4 +-
 arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi        |    4 +-
 arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revA.dts  |   20 +-
 arch/arm64/boot/dts/xilinx/zynqmp-zcu106-revA.dts  |   20 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi             |    1 +
 drivers/bus/omap_l3_noc.c                          |    4 +-
 drivers/bus/ti-sysc.c                              |   82 +-
 drivers/clk/ti/clk-54xx.c                          |    2 +
 drivers/pci/controller/dwc/pci-dra7xx.c            |   13 +-
 drivers/soc/ti/omap_prm.c                          |   24 +-
 include/dt-bindings/clock/omap5.h                  |    2 +
 include/dt-bindings/pinctrl/k3.h                   |    5 +-
 532 files changed, 27292 insertions(+), 3725 deletions(-)
 create mode 100644 Documentation/arm/stm32/stm32h750-overview.rst
 create mode 100644 arch/arm/boot/dts/armada-385-atl-x530.dts
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-asrock-e3c246d4i.dts
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-ibm-rainier-1s4u.dts
 create mode 100644 arch/arm/boot/dts/imx7d-remarkable2.dts
 create mode 100644 arch/arm/boot/dts/mstar-infinity2m-ssd202d-unitv2.dts
 create mode 100644 arch/arm/boot/dts/nuvoton-npcm730-gbs.dts
 create mode 100644 arch/arm/boot/dts/qcom-sdx55-t55.dts
 create mode 100644 arch/arm/boot/dts/qcom-sdx55-telit-fn980-tlb.dts
 create mode 100644 arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ov5640-single.dtsi
 create mode 100644 arch/arm/boot/dts/r8a7742-iwg21d-q7-dbcm-ov7725-single.dtsi
 delete mode 100644 arch/arm/boot/dts/ste-href-tvk1281618.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h7-pinctrl.dtsi
 delete mode 100644 arch/arm/boot/dts/stm32h743-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750.dtsi
 create mode 100644 arch/arm/boot/dts/stm32h750i-art-pi.dts
 create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts
 create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts
 create mode 100644 arch/arm/boot/dts/stm32mp157a-icore-stm32mp1.dtsi
 create mode 100644
arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts
 create mode 100644
arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts
 create mode 100644 arch/arm/boot/dts/stm32mp157a-microgea-stm32mp1.dtsi
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
 create mode 100644
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-mecool-kii-pro.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-mecool-kiii-pro.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-minix-neo-u9h.dts
 create mode 100644
arch/arm64/boot/dts/broadcom/bcm4908/bcm4906-tplink-archer-c2300-v1.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-adma.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-ddr.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-dma.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8-ss-lsio.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-icore-mx8mm-ctouch2.dts
 create mode 100644
arch/arm64/boot/dts/freescale/imx8mm-icore-mx8mm-edimm2.2.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-icore-mx8mm.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-kontron-pitx-imx8m.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-mek.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm-ss-lsio.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qm.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-adma.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-conn.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ss-lsio.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
 create mode 100644
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper-sku16.dts
 create mode 100644
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-juniper.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku16.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku272.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku288.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama-sku32.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
 create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-common.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dts
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350b.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmr735b.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r2-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
 create mode 100644
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dts
 create mode 100644
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen-nots.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-limozeen.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2-lte.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-pompom.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sc7280-idp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sc7280.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sm8350-hdk.dts
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779a0-falcon-csi-dsi.dtsi
 create mode 100644 arch/arm64/boot/dts/renesas/r8a779a0-falcon-ethernet.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642-sk.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts


From bpeled at marvell.com  Mon Apr 26 16:58:33 2021
From: bpeled at marvell.com (Ben Peled)
Date: Mon, 26 Apr 2021 15:58:33 +0000
Subject: =?Windows-1252?Q?RE:_[EXT]_Re:_[=94PATCH=94_3/5]_dt-bindings:_pci:_add_sy?=
 =?Windows-1252?Q?stem_controller_and_MAC_reset_bit_to_Armada_7K/8K_contro?=
 =?Windows-1252?Q?ller_bindings?=
In-Reply-To: <20210413151013.GA1683364@robh.at.kernel.org>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
 <1618241456-27200-4-git-send-email-bpeled@marvell.com>
 <20210413151013.GA1683364@robh.at.kernel.org>
Message-ID: <MW2PR18MB2217D165D4E0435888525310C2429@MW2PR18MB2217.namprd18.prod.outlook.com>

Hi Rob,
Sorry I missed it.

> > diff --git a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > index 7a813d0..2696e79 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-armada8k.txt
> > @@ -24,6 +24,10 @@ Optional properties:
> >  - phy-names: names of the PHYs corresponding to the number of lanes.
> >  	Must be "cp0-pcie0-x4-lane0-phy", "cp0-pcie0-x4-lane1-phy" for
> >  	2 PHYs.
> > +- marvell,system-controller: address of system controller needed
> > +	in order to reset MAC used by link-down handle
> > +- marvell,mac-reset-bit-mask: MAC reset bit of system controller
> > +	needed in order to reset MAC used by link-down handle
> 
> Seems like this should use the reset controller binding instead.
> 
> If not, this can be a single property with a phandle plus arg.
> 
> Rob

I will fix it v3.
Thanks


From arnd at kernel.org  Mon Apr 26 17:00:02 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 18:00:02 +0200
Subject: [GIT PULL 5/6] ARM: platform support for Nuvoton WPCM450
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a2apTEYei_w6+_dM5a6ZD+QCA65x9hDjVWe2ueVO2C_dw@mail.gmail.com>

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-newsoc-5.13

for you to fetch changes up to 39b95079f68cf17888a4cee93ad3c4acc3854b38:

  Merge tag 'bmc-5.13-wpcm450' of
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/newsoc
(2021-04-09 09:02:55 +0200)

----------------------------------------------------------------
ARM: platform support for Nuvoton WPCM450

The Nuvoton WPCM450 BMC is an older chip based on the ARM926 CPU core
that remains in use on Supermicro X9 server boards among others. Support
gets added for a particular server board using this SoC along with the
basic platform bringup.

As the platform is a predecessor to the npcm7xx platform we already
support, it is added to the same directory, despite using a different
name. It also seems to be related to the older w90x900/nuc9xx platform
that was removed last year.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------
Arnd Bergmann (1):
      Merge tag 'bmc-5.13-wpcm450' of
git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/newsoc

Joel Stanley (1):
      ARM: config: Add WPCM to multi v5

Jonathan Neusch?fer (10):
      dt-bindings: arm: Convert nuvoton,npcm750 binding to YAML
      ARM: dts: Add board-specific compatible string to npcm750-evb devicetree
      dt-bindings: vendor-prefixes: Add Supermicro
      dt-bindings: arm: npcm: Add nuvoton,wpcm450 compatible string
      dt-bindings: watchdog: npcm: Add nuvoton,wpcm450-wdt
      ARM: npcm: Introduce Nuvoton WPCM450 SoC
      watchdog: npcm: Add support for WPCM450
      ARM: dts: Add devicetree for Nuvoton WPCM450 BMC chip
      ARM: dts: Add devicetree for Supermicro X9SCi-LN4F based on WPCM450
      MAINTAINERS: Add entry for Nuvoton WPCM450

 .../devicetree/bindings/arm/npcm/npcm.txt          |  6 --
 .../devicetree/bindings/arm/npcm/npcm.yaml         | 29 +++++++++
 .../devicetree/bindings/vendor-prefixes.yaml       |  2 +
 .../bindings/watchdog/nuvoton,npcm-wdt.txt         |  3 +-
 MAINTAINERS                                        |  9 +++
 arch/arm/boot/dts/Makefile                         |  2 +
 arch/arm/boot/dts/nuvoton-npcm750-evb.dts          |  2 +-
 .../dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts  | 40 ++++++++++++
 arch/arm/boot/dts/nuvoton-wpcm450.dtsi             | 76 ++++++++++++++++++++++
 arch/arm/configs/multi_v5_defconfig                |  3 +
 arch/arm/mach-npcm/Kconfig                         | 12 +++-
 arch/arm/mach-npcm/Makefile                        |  1 +
 arch/arm/mach-npcm/wpcm450.c                       | 13 ++++
 drivers/watchdog/npcm_wdt.c                        |  1 +
 14 files changed, 190 insertions(+), 9 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
 create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.yaml
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
 create mode 100644 arch/arm/boot/dts/nuvoton-wpcm450.dtsi
 create mode 100644 arch/arm/mach-npcm/wpcm450.c


From arnd at kernel.org  Mon Apr 26 17:05:42 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Mon, 26 Apr 2021 18:05:42 +0200
Subject: [GIT PULL 6/6, look out for dependencies ] ARM: platform support for
 Apple M1
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAK8P3a388f9iSncTW-sAdbeg3-=vc=6r0X9392puGE=FsWy=Yw@mail.gmail.com>

The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:

  Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
tags/arm-apple-m1-5.13

for you to fetch changes up to ea96292838397682530ac77a429974f8ff5f2df3:

  asm-generic/io.h: Unbork ioremap_np() declaration (2021-04-09 08:48:27 +0200)

----------------------------------------------------------------
ARM: platform support for Apple M1

The Apple M1 is the processor used it all current generation Apple
Macintosh computers. Support for this platform so far is rudimentary,
but it boots and can use framebuffer and serial console over a special
USB cable.

Support for several essential on-chip devices (USB, PCIe, IOMMU, NVMe)
is work in progress but was not ready in time.

A very detailed description of what works is in the merge commit
and on the AsahiLinux wiki.

Link: https://lore.kernel.org/linux-arm-kernel/bdb18e9f-fcd7-1e31-2224-19c0e5090706 at marcan.st/
Signed-off-by: Arnd Bergmann <arnd at arndb.de>

----------------------------------------------------------------

Note: this tree pulls in changes from the tty and arm64 trees as a dependency.
The diffstat below is based on on commit 847bea3d08a (Merge remote-tracking
branch 'arm64/for-next/fiq'), and is what  you should see when you
pull those two first.

There is also a small Makefile conflict against the irqchip branch of
the tip tree.

----------------------------------------------------------------
Arnd Bergmann (3):
      docs: driver-api: device-io: Document I/O access functions
      Merge branch 'apple/m1-dependency' into arm/apple-m1
      Merge tag 'm1-soc-bringup-v5' of
https://github.com/AsahiLinux/linux into arm/apple-m1

Hector Martin (18):
      dt-bindings: vendor-prefixes: Add apple prefix
      dt-bindings: arm: apple: Add bindings for Apple ARM platforms
      dt-bindings: arm: cpus: Add apple,firestorm & icestorm compatibles
      arm64: cputype: Add CPU implementor & types for the Apple M1 cores
      dt-bindings: timer: arm,arch_timer: Add interrupt-names support
      arm64: arch_timer: Implement support for interrupt-names
      asm-generic/io.h:  Add a non-posted variant of ioremap()
      docs: driver-api: device-io: Document ioremap() variants & access funcs
      arm64: Implement ioremap_np() to map MMIO as nGnRnE
      asm-generic/io.h: implement pci_remap_cfgspace using ioremap_np
      of/address: Add infrastructure to declare MMIO as non-posted
      arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h
      dt-bindings: interrupt-controller: Add DT bindings for apple-aic
      irqchip/apple-aic: Add support for the Apple Interrupt Controller
      arm64: Kconfig: Introduce CONFIG_ARCH_APPLE
      dt-bindings: display: Add apple,simple-framebuffer
      arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree
      asm-generic/io.h: Unbork ioremap_np() declaration

 Documentation/devicetree/bindings/arm/apple.yaml   |  64 ++
 Documentation/devicetree/bindings/arm/cpus.yaml    |   2 +
 .../bindings/display/simple-framebuffer.yaml       |   5 +
 .../bindings/interrupt-controller/apple,aic.yaml   |  88 +++
 .../devicetree/bindings/timer/arm,arch_timer.yaml  |  19 +
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 Documentation/driver-api/device-io.rst             | 356 +++++++++
 Documentation/driver-api/driver-model/devres.rst   |   1 +
 MAINTAINERS                                        |  14 +
 arch/arm64/Kconfig.platforms                       |   7 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/apple/Makefile                 |   2 +
 arch/arm64/boot/dts/apple/t8103-j274.dts           |  45 ++
 arch/arm64/boot/dts/apple/t8103.dtsi               | 135 ++++
 arch/arm64/configs/defconfig                       |   1 +
 arch/arm64/include/asm/cputype.h                   |   6 +
 arch/arm64/include/asm/io.h                        |  11 +-
 arch/arm64/include/asm/sysreg.h                    |  60 ++
 arch/sparc/include/asm/io_64.h                     |   4 +
 drivers/clocksource/arm_arch_timer.c               |  24 +-
 drivers/irqchip/Kconfig                            |   8 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-apple-aic.c                    | 852 +++++++++++++++++++++
 drivers/of/address.c                               |  43 +-
 include/asm-generic/io.h                           |  21 +-
 include/asm-generic/iomap.h                        |   9 +
 include/clocksource/arm_arch_timer.h               |   1 +
 .../dt-bindings/interrupt-controller/apple-aic.h   |  15 +
 include/linux/cpuhotplug.h                         |   1 +
 include/linux/io.h                                 |  18 +-
 include/linux/ioport.h                             |   1 +
 include/linux/irqchip/arm-gic-v3.h                 |  56 --
 lib/devres.c                                       |  22 +
 33 files changed, 1815 insertions(+), 80 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/apple.yaml
 create mode 100644
Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml
 create mode 100644 arch/arm64/boot/dts/apple/Makefile
 create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts
 create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi
 create mode 100644 drivers/irqchip/irq-apple-aic.c
 create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h


From p.yadav at ti.com  Mon Apr 26 17:26:12 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Mon, 26 Apr 2021 21:56:12 +0530
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426143934.25275-2-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
Message-ID: <20210426162610.erpt5ubeddx7paeq@ti.com>

Hi,

On 26/04/21 04:39PM, patrice.chotard at foss.st.com wrote:
> From: Christophe Kerello <christophe.kerello at foss.st.com>
> 
> With STM32 QSPI, it is possible to poll the status register of the device.
> This could be done to offload the CPU during an operation (erase or
> program a SPI NAND for example).
> 
> spi_mem_poll_status API has been added to handle this feature.
> 
> Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
> ---
>  drivers/spi/spi-mem.c       | 34 ++++++++++++++++++++++++++++++++++
>  include/linux/spi/spi-mem.h |  8 ++++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index 1513553e4080..43dce4b0efa4 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -743,6 +743,40 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>  	return container_of(drv, struct spi_mem_driver, spidrv.driver);
>  }
>  
> +/**
> + * spi_mem_poll_status() - Poll memory device status
> + * @mem: SPI memory device
> + * @op: the memory operation to execute
> + * @mask: status bitmask to ckeck
> + * @match: status expected value

Technically, (status & mask) expected value. Dunno if that is obvious 
enough to not spell out explicitly.

> + * @timeout: timeout
> + *
> + * This function send a polling status request to the controller driver
> + *
> + * Return: 0 in case of success, -ETIMEDOUT in case of error,
> + *         -EOPNOTSUPP if not supported.
> + */
> +int spi_mem_poll_status(struct spi_mem *mem,
> +			const struct spi_mem_op *op,
> +			u8 mask, u8 match, u16 timeout)
> +{
> +	struct spi_controller *ctlr = mem->spi->controller;
> +	int ret = -EOPNOTSUPP;
> +
> +	if (ctlr->mem_ops && ctlr->mem_ops->poll_status) {

You should call spi_mem_supports_op() before sending any ops to the 
controller. Invalid/unsupported ops can cause unexpected behavior.

> +		ret = spi_mem_access_start(mem);
> +		if (ret)
> +			return ret;
> +
> +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);

I wonder if it is better to let spi-mem core take care of the timeout 
part. On one hand it reduces code duplication on the driver side a 
little bit. Plus it makes sure drivers don't mess anything up with bad 
(or no) handling of the timeout. But on the other hand the interface 
becomes a bit awkward since you'd have to pass a struct completion 
around, and it isn't something particularly hard to get right either. 
What do you think?

> +
> +		spi_mem_access_end(mem);
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(spi_mem_poll_status);
> +
>  static int spi_mem_probe(struct spi_device *spi)
>  {
>  	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index 2b65c9edc34e..5f78917c0f68 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -250,6 +250,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
>   *		  the currently mapped area), and the caller of
>   *		  spi_mem_dirmap_write() is responsible for calling it again in
>   *		  this case.
> + * @poll_status: poll memory device status
>   *
>   * This interface should be implemented by SPI controllers providing an
>   * high-level interface to execute SPI memory operation, which is usually the
> @@ -274,6 +275,9 @@ struct spi_controller_mem_ops {
>  			       u64 offs, size_t len, void *buf);
>  	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
>  				u64 offs, size_t len, const void *buf);
> +	int (*poll_status)(struct spi_mem *mem,
> +			   const struct spi_mem_op *op,
> +			   u8 mask, u8 match, u16 timeout);
>  };
>  
>  /**
> @@ -369,6 +373,10 @@ devm_spi_mem_dirmap_create(struct device *dev, struct spi_mem *mem,
>  void devm_spi_mem_dirmap_destroy(struct device *dev,
>  				 struct spi_mem_dirmap_desc *desc);
>  
> +int spi_mem_poll_status(struct spi_mem *mem,
> +			const struct spi_mem_op *op,
> +			u8 mask, u8 match, u16 timeout);
> +
>  int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>  				       struct module *owner);

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From nm at ti.com  Mon Apr 26 17:40:08 2021
From: nm at ti.com (Nishanth Menon)
Date: Mon, 26 Apr 2021 11:40:08 -0500
Subject: [PATCH V2] dt-bindings: arm: firmware: Convert linaro,
 optee-tz to json schema
Message-ID: <20210426164008.20000-1-nm@ti.com>

Convert linaro,optee-tz to json schema format for better documentation
and error checks.

NOTE: This change does introduce a stricter naming convention for
optee nodes.

Signed-off-by: Nishanth Menon <nm at ti.com>
---

Changes since v1:
* Dropped un-necessary quotes around compatible
* Converted the method to enum, updated description as well
* Updated commit message to drop the 'checkpatch warning'

V1: https://lore.kernel.org/linux-arm-kernel/20210416222518.15801-1-nm at ti.com/

 .../bindings/arm/firmware/linaro,optee-tz.txt | 31 ----------
 .../arm/firmware/linaro,optee-tz.yaml         | 58 +++++++++++++++++++
 2 files changed, 58 insertions(+), 31 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml

diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
deleted file mode 100644
index d38834c67dff..000000000000
--- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OP-TEE Device Tree Bindings
-
-OP-TEE is a piece of software using hardware features to provide a Trusted
-Execution Environment. The security can be provided with ARM TrustZone, but
-also by virtualization or a separate chip.
-
-We're using "linaro" as the first part of the compatible property for
-the reference implementation maintained by Linaro.
-
-* OP-TEE based on ARM TrustZone required properties:
-
-- compatible     : should contain "linaro,optee-tz"
-
-- method         : The method of calling the OP-TEE Trusted OS. Permitted
-                   values are:
-
-                   "smc" : SMC #0, with the register assignments specified
-		           in drivers/tee/optee/optee_smc.h
-
-                   "hvc" : HVC #0, with the register assignments specified
-		           in drivers/tee/optee/optee_smc.h
-
-
-
-Example:
-	firmware {
-		optee {
-			compatible = "linaro,optee-tz";
-			method = "smc";
-		};
-	};
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
new file mode 100644
index 000000000000..c24047c1fdd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OP-TEE Device Tree Bindings
+
+maintainers:
+  - Jens Wiklander <jens.wiklander at linaro.org>
+
+description: |
+  OP-TEE is a piece of software using hardware features to provide a Trusted
+  Execution Environment. The security can be provided with ARM TrustZone, but
+  also by virtualization or a separate chip.
+
+  We're using "linaro" as the first part of the compatible property for
+  the reference implementation maintained by Linaro.
+
+properties:
+  $nodename:
+    const: optee
+
+  compatible:
+    const: linaro,optee-tz
+
+  method:
+    enum: [smc, hvc]
+    description: |
+      The method of calling the OP-TEE Trusted OS depending on smc or hvc
+      instruction usage.
+      SMC #0, register assignments
+      or
+      HVC #0, register assignments
+      register assignments are specified in drivers/tee/optee/optee_smc.h
+
+required:
+  - compatible
+  - method
+
+additionalProperties: false
+
+examples:
+  - |
+    firmware  {
+        optee  {
+            compatible = "linaro,optee-tz";
+            method = "smc";
+        };
+    };
+
+  - |
+    firmware  {
+        optee  {
+            compatible = "linaro,optee-tz";
+            method = "hvc";
+        };
+    };
-- 
2.31.0



From broonie at kernel.org  Mon Apr 26 17:51:18 2021
From: broonie at kernel.org (Mark Brown)
Date: Mon, 26 Apr 2021 17:51:18 +0100
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426162610.erpt5ubeddx7paeq@ti.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
 <20210426162610.erpt5ubeddx7paeq@ti.com>
Message-ID: <20210426165118.GH4590@sirena.org.uk>

On Mon, Apr 26, 2021 at 09:56:12PM +0530, Pratyush Yadav wrote:
> On 26/04/21 04:39PM, patrice.chotard at foss.st.com wrote:

> > + * spi_mem_poll_status() - Poll memory device status
> > + * @mem: SPI memory device
> > + * @op: the memory operation to execute
> > + * @mask: status bitmask to ckeck
> > + * @match: status expected value

> Technically, (status & mask) expected value. Dunno if that is obvious 
> enough to not spell out explicitly.

Is it possible there's some situation where you're waiting for some bits
to clear as well?

> > +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);

I'm not sure I like this name since it makes me think the driver is
going to poll when really it's offloaded to the hardware, but I can't
think of any better ideas either and it *is* what the hardware is going
to be doing so meh.

> I wonder if it is better to let spi-mem core take care of the timeout 
> part. On one hand it reduces code duplication on the driver side a 
> little bit. Plus it makes sure drivers don't mess anything up with bad 
> (or no) handling of the timeout. But on the other hand the interface 
> becomes a bit awkward since you'd have to pass a struct completion 
> around, and it isn't something particularly hard to get right either. 
> What do you think?

We already have the core handling other timeouts.  We don't pass around
completions but rather have an API function that the driver has to call
when the operation completes, a similar pattern might work here.  Part
of the thing with those APIs which I'm missing here is that this will
just return -EOPNOTSUPP if the driver can't do the delay in hardware, I
think it would be cleaner if this API were similar and the core dealt
with doing the delay/poll on the CPU.  That way the users don't need to
repeat the handling for the offload/non-offload cases.
-------------- 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/20210426/a766f08f/attachment.sig>

From catalin.marinas at arm.com  Mon Apr 26 18:07:46 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 26 Apr 2021 18:07:46 +0100
Subject: Removed MTE function
In-Reply-To: <CAJoBWHwvkoTx=01FQDn6TcsFUPps_7cmjLG3nopJMdpHOJEvhw@mail.gmail.com>
References: <CAJoBWHz5GdRVnYAuvCkVxcx8qFEMnkmLToSy4Lwckg1LptHfpA@mail.gmail.com>
 <20210402123415.GA2830@arm.com>
 <CAJoBWHwvkoTx=01FQDn6TcsFUPps_7cmjLG3nopJMdpHOJEvhw@mail.gmail.com>
Message-ID: <20210426170746.GH4985@arm.com>

On Fri, Apr 16, 2021 at 01:58:27PM -0400, Derrick McKee wrote:
> On Fri, Apr 2, 2021 at 8:34 AM Catalin Marinas <catalin.marinas at arm.com> wrote:
> > It was added in commit 85f49cae4dfc ("arm64: mte: add in-kernel MTE
> > helpers") in 5.11 but moved out of mte.S by commit 2cb34276427a ("arm64:
> > kasan: simplify and inline MTE functions") in 5.12 and renamed to
> > mte_set_mem_tag_range(). Unfortunately, that commit did not delete the
> > old function prototypes in mte.h. I'll clean it up next week, unless
> > someone beats me to it with a patch.
> 
> Ahh, ok, thanks for the information.
> 
> > What do you need this function for? It's supposed to be used only by
> > kasan, hence moved to mte-kasan.h.
> 
> I am working on a research prototype attempting to harden kernel
> modules using a combination of MTE and PAC.  I'd actually be
> interested in hearing how KASAN handles dynamic percpu allocations,
> because that's been a challenge for me in this project.

At a quick look, I don't think it does anything special. It relies on
the page allocator to set a tag on the page and I presume it uses that
tag. However, individual objects won't be tagged differently, nor the
tag reset on free.

-- 
Catalin


From pr-tracker-bot at kernel.org  Mon Apr 26 18:38:22 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 17:38:22 +0000
Subject: [GIT PULL] arm64 updates for 5.13-rc1
In-Reply-To: <20210426142710.GA10892@arm.com>
References: <20210426142710.GA10892@arm.com>
Message-ID: <161945870208.23425.13058610930150962201.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 15:27:12 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31a24ae89c92d5533c049046a76c6a2d649efb72

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From p.yadav at ti.com  Mon Apr 26 18:39:36 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Mon, 26 Apr 2021 23:09:36 +0530
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426165118.GH4590@sirena.org.uk>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
 <20210426162610.erpt5ubeddx7paeq@ti.com>
 <20210426165118.GH4590@sirena.org.uk>
Message-ID: <20210426173934.zigt6b66ieuzuchy@ti.com>

On 26/04/21 05:51PM, Mark Brown wrote:
> On Mon, Apr 26, 2021 at 09:56:12PM +0530, Pratyush Yadav wrote:
> > On 26/04/21 04:39PM, patrice.chotard at foss.st.com wrote:
> 
> > > + * spi_mem_poll_status() - Poll memory device status
> > > + * @mem: SPI memory device
> > > + * @op: the memory operation to execute
> > > + * @mask: status bitmask to ckeck
> > > + * @match: status expected value
> 
> > Technically, (status & mask) expected value. Dunno if that is obvious 
> > enough to not spell out explicitly.
> 
> Is it possible there's some situation where you're waiting for some bits
> to clear as well?

Yes. In fact, that is the more common situation. Both SPI NOR 
(spi_nor_sr_ready()) and SPI NAND (spinand_wait()) need to wait for the 
"busy" bit to be cleared.

AFAICT this API is supposed to check for (status & mask) == (match & 
mask) so it should be able to handle both polarities for the bits being 
polled.

> 
> > > +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);
> 
> I'm not sure I like this name since it makes me think the driver is
> going to poll when really it's offloaded to the hardware, but I can't
> think of any better ideas either and it *is* what the hardware is going
> to be doing so meh.
> 
> > I wonder if it is better to let spi-mem core take care of the timeout 
> > part. On one hand it reduces code duplication on the driver side a 
> > little bit. Plus it makes sure drivers don't mess anything up with bad 
> > (or no) handling of the timeout. But on the other hand the interface 
> > becomes a bit awkward since you'd have to pass a struct completion 
> > around, and it isn't something particularly hard to get right either. 
> > What do you think?
> 
> We already have the core handling other timeouts.  We don't pass around
> completions but rather have an API function that the driver has to call
> when the operation completes, a similar pattern might work here.  Part
> of the thing with those APIs which I'm missing here is that this will
> just return -EOPNOTSUPP if the driver can't do the delay in hardware, I
> think it would be cleaner if this API were similar and the core dealt
> with doing the delay/poll on the CPU.  That way the users don't need to
> repeat the handling for the offload/non-offload cases.

Makes sense to me.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From mathieu.poirier at linaro.org  Mon Apr 26 18:54:25 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 26 Apr 2021 11:54:25 -0600
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <20210426175425.GA1391779@xps15>

Hi Daniel,

On Wed, Apr 21, 2021 at 02:04:09PM +0200, Daniel Kiss wrote:
> This series adds a feature to ETR-PERF that sync the ETR buffer to perf
> periodically. This is really handy when the system wide trace is used
> because in this case the perf won't sync during the trace. In a per-thread
> setup the traced program might not go to the kernel frequvently enought
> to collect trace. Polling helps in both usecases. Can be used with strobing.
> Tuning polling period is challanging, I'm working on an additional patch
> that adds some metrics to help tune the polling period.
>

Suzuki and Leo have already commented on a number of problems with this set and
as such I will concentrate on the general idea.

Over the years we have thought long and hard about fixing the overflow issues
created by the lack of interrupt when a sink gets full, installing a timer to
empty the sink buffer at regular intervals is one of them.  Ultimately we
haven't moved forward with the idea because it requires to stop the sink when an
event is active, something that introduces more trace data loss.  

To me this kind of interval snapshot should be achieved using Mike's new
strobing feature that came bundled with the complex configuration framework,
available on next-ETE-TRBE[1].  I will rebase that branch to 5.13-rc1 when it
is released in a couple of weeks from now.

Thanks,
Mathieu

PS: Always run your work through checkpatch.pl before sending a patchset for
review. 

[1]. https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-ETE-TRBE
 
> Daniel Kiss (4):
>   coresight: tmc-etr: Advance buffer pointer in sync buffer.
>   coresight: tmc-etr: Track perf handler.
>   coresight: etm-perf: Export etm_event_cpu_path.
>   coresight: Add ETR-PERF polling.
> 
>  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
>  drivers/hwtracing/coresight/Makefile          |   2 +-
>  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
>  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
>  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
>  .../coresight/coresight-etr-perf-polling.h    |  42 +++
>  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
>  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>  9 files changed, 401 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> 
> -- 
> 2.25.1
> 


From narmstrong at baylibre.com  Mon Apr 26 18:55:58 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 19:55:58 +0200
Subject: [PATCH 1/2] mmc: meson-gx: make replace WARN_ONCE with dev_warn_once
 about scatterlist offset alignment
Message-ID: <20210426175559.3110575-1-narmstrong@baylibre.com>

Some drivers like ath10k can sometimg give an sg buffer with an offset whose alignment
is not compatible with the Amlogic DMA descriptor engine requirements.

Simply replace with dev_warn_once() to inform user this should be fixed to avoid
degraded performance.

This should be ultimately fixed in ath10k, but since it's only a performance issue
the warning should be removed.

Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode")
Reported-by: Christian Hewitt <christianshewitt at gmail.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index b8b771b643cc..1c61f0f24c09 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -258,7 +258,9 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
 	for_each_sg(data->sg, sg, data->sg_len, i) {
 		/* check for 8 byte alignment */
 		if (sg->offset % 8) {
-			WARN_ONCE(1, "unaligned scatterlist buffer\n");
+			dev_warn_once(mmc_dev(mmc),
+				      "unaligned sg offset %u, disabling descriptor DMA for transfer\n",
+				      sg->offset);
 			return;
 		}
 	}
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 26 18:55:59 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 19:55:59 +0200
Subject: [PATCH 2/2] mmc: meson-gx: also check SD_IO_RW_EXTENDED for
 scatterlist size alignment
In-Reply-To: <20210426175559.3110575-1-narmstrong@baylibre.com>
References: <20210426175559.3110575-1-narmstrong@baylibre.com>
Message-ID: <20210426175559.3110575-2-narmstrong@baylibre.com>

The brcmfmac driver can generate a scatterlist from a skb with each packets
not aligned to the block size. This is not supported by the Amlogic Descriptor
dma engine where each descriptor must match a multiple of the block size.

The sg list is valid, since the sum of the sg buffers is a multiple of the
block size, but we must discard those when in SD_IO_RW_EXTENDED mode since
SDIO block mode can be used under the hood even with data->blocks == 1.

Those transfers are very rare, thus can be replaced by a bounce buffer
without real performance loss.

Fixes: 7412dee9f1fd ("mmc: meson-gx: replace WARN_ONCE with dev_warn_once about scatterlist size alignment in block mode")
Reported-by: Christian Hewitt <christianshewitt at gmail.com>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/mmc/host/meson-gx-mmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 1c61f0f24c09..016a6106151a 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -236,7 +236,8 @@ static void meson_mmc_get_transfer_mode(struct mmc_host *mmc,
 	if (host->dram_access_quirk)
 		return;
 
-	if (data->blocks > 1) {
+	/* SD_IO_RW_EXTENDED (CMD53) can also use block mode under the hood */
+	if (data->blocks > 1 || mrq->cmd->opcode == SD_IO_RW_EXTENDED) {
 		/*
 		 * In block mode DMA descriptor format, "length" field indicates
 		 * number of blocks and there is no way to pass DMA size that
-- 
2.25.1



From narmstrong at baylibre.com  Mon Apr 26 19:02:22 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 20:02:22 +0200
Subject: [PATCH -next] soc: amlogic: meson-clk-measure: remove redundant
 dev_err call in meson_msr_probe()
In-Reply-To: <20210409110243.41-1-linqiheng@huawei.com>
References: <20210409110243.41-1-linqiheng@huawei.com>
Message-ID: <3299a54f-0aeb-3dfa-dedb-d32f87de5ae9@baylibre.com>

On 09/04/2021 13:02, Qiheng Lin wrote:
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Reported-by: Hulk Robot <hulkci at huawei.com>
> Signed-off-by: Qiheng Lin <linqiheng at huawei.com>
> ---
>  drivers/soc/amlogic/meson-clk-measure.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
> index e1957476a006..6dd190270123 100644
> --- a/drivers/soc/amlogic/meson-clk-measure.c
> +++ b/drivers/soc/amlogic/meson-clk-measure.c
> @@ -626,10 +626,8 @@ static int meson_msr_probe(struct platform_device *pdev)
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	base = devm_ioremap_resource(&pdev->dev, res);
> -	if (IS_ERR(base)) {
> -		dev_err(&pdev->dev, "io resource mapping failed\n");
> +	if (IS_ERR(base))
>  		return PTR_ERR(base);
> -	}
>  
>  	priv->regmap = devm_regmap_init_mmio(&pdev->dev, base,
>  					     &meson_clk_msr_regmap_config);
> 
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
> 

Acked-by: Neil Armstrong <narmstrong at baylibre.com>


From narmstrong at baylibre.com  Mon Apr 26 19:03:34 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 20:03:34 +0200
Subject: [PATCH] staging: media/meson: remove redundant dev_err call
In-Reply-To: <20210407160921.GA1504294@LEGION>
References: <20210407160921.GA1504294@LEGION>
Message-ID: <3fac78c4-189f-57cb-ca81-a97c918e2386@baylibre.com>

On 07/04/2021 18:09, Muhammad Usama Anjum wrote:
> devm_ioremap_resource() prints error message in itself. Remove the
> dev_err call to avoid redundant error message.
> 
> Signed-off-by: Muhammad Usama Anjum <musamaanjum at gmail.com>
> ---
>  drivers/staging/media/meson/vdec/vdec.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
> index 5d4db7a5b4b5..e51d69c4729d 100644
> --- a/drivers/staging/media/meson/vdec/vdec.c
> +++ b/drivers/staging/media/meson/vdec/vdec.c
> @@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
>  
>  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
>  	core->dos_base = devm_ioremap_resource(dev, r);
> -	if (IS_ERR(core->dos_base)) {
> -		dev_err(dev, "Couldn't remap DOS memory\n");
> +	if (IS_ERR(core->dos_base))
>  		return PTR_ERR(core->dos_base);
> -	}
>  
>  	r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
>  	core->esparser_base = devm_ioremap_resource(dev, r);
> -	if (IS_ERR(core->esparser_base)) {
> -		dev_err(dev, "Couldn't remap ESPARSER memory\n");
> +	if (IS_ERR(core->esparser_base))
>  		return PTR_ERR(core->esparser_base);
> -	}
>  
>  	core->regmap_ao =
>  		syscon_regmap_lookup_by_phandle(dev->of_node,
> 

Acked-by: Neil Armstrong <narmstrong at baylibre.com>


From narmstrong at baylibre.com  Mon Apr 26 19:06:31 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 26 Apr 2021 20:06:31 +0200
Subject: [PATCH v2 1/3] dt-bindings: serial: amlogic,meson-uart: add
 fifo-size property
In-Reply-To: <20210325152410.1795557-2-narmstrong@baylibre.com>
References: <20210325152410.1795557-1-narmstrong@baylibre.com>
 <20210325152410.1795557-2-narmstrong@baylibre.com>
Message-ID: <39c92a23-e009-6bc2-a20b-9b0ab3e01c75@baylibre.com>

Hi Rob,

On 25/03/2021 16:24, Neil Armstrong wrote:
> On most of the Amlogic SoCs, the first UART controller in the "Everything-Else"
> power domain has 128bytes of RX & TX FIFO, so add an optional property to describe
> a different FIFO size from the other ports (64bytes).
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
> ---
>  .../devicetree/bindings/serial/amlogic,meson-uart.yaml      | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
> index 75ebc9952a99..8ece7f420c19 100644
> --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
> @@ -55,6 +55,12 @@ properties:
>        - const: pclk
>        - const: baud
>  
> +
> +  fifo-size:
> +    description: The fifo size supported by the UART channel.
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    enum: [64, 128]
> +
>  required:
>    - compatible
>    - reg
> 


Is it ok with the generic fifo-size property ?

Neil


From pasha.tatashin at soleen.com  Mon Apr 26 19:10:30 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Mon, 26 Apr 2021 14:10:30 -0400
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <CA+CK2bB9M05UKfvu66_wMK1u_HBvRws4R0KxPgTu4vPdKuGy9w@mail.gmail.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
 <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
 <87v98wom5n.wl-maz@kernel.org>
 <CA+CK2bB9M05UKfvu66_wMK1u_HBvRws4R0KxPgTu4vPdKuGy9w@mail.gmail.com>
Message-ID: <CA+CK2bADNkoX-Q3tNyjJ7fo6-f4sBPkAVYLiQh-rxFOcHzbJGw@mail.gmail.com>

Hi Marc

Are you planning to send more review comments, or should I send the new version?

Thanks,
Pasha

On Thu, Apr 8, 2021 at 12:28 PM Pavel Tatashin
<pasha.tatashin at soleen.com> wrote:
>
> > > Thank you for noticing this. Not sure how this missmerge happened. I
> > > have added the missing case, and VHE is initialized correctly during
> > > boot.
> > > [   14.698175] kvm [1]: VHE mode initialized successfully
> > >
> > > During normal boot, kexec reboot, and kdump reboot. I will respin the
> > > series and send the version 14 soon.
> >
> > Please give people a chance to review this lot first. This isn't code
> > that is easy to digest, and immediate re-spinning does more harm than
> > good (this isn't targeting 5.13, I would assume).
> >
>
> There are people who are testing this series, this is why I wanted to
> respin. But, I will wait for review comments before sending the next
> version. In the meantime I will send a fixed version of this patch as
> a reply to this thread instead.
>
> Thanks,
> Pasha


From pasha.tatashin at soleen.com  Mon Apr 26 19:11:37 2021
From: pasha.tatashin at soleen.com (Pavel Tatashin)
Date: Mon, 26 Apr 2021 14:11:37 -0400
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <CA+CK2bADNkoX-Q3tNyjJ7fo6-f4sBPkAVYLiQh-rxFOcHzbJGw@mail.gmail.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
 <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
 <87v98wom5n.wl-maz@kernel.org>
 <CA+CK2bB9M05UKfvu66_wMK1u_HBvRws4R0KxPgTu4vPdKuGy9w@mail.gmail.com>
 <CA+CK2bADNkoX-Q3tNyjJ7fo6-f4sBPkAVYLiQh-rxFOcHzbJGw@mail.gmail.com>
Message-ID: <CA+CK2bDcZiWhQ+xALnQm43zGpv+BE9wkHejMS81v=wk3iJPttA@mail.gmail.com>

> > > Please give people a chance to review this lot first. This isn't code
> > > that is easy to digest, and immediate re-spinning does more harm than
> > > good (this isn't targeting 5.13, I would assume).

Sorry for top posting, the previous e-mail intended as a reply to the above.

Pasha


From torvalds at linux-foundation.org  Mon Apr 26 19:18:49 2021
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 26 Apr 2021 11:18:49 -0700
Subject: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
In-Reply-To: <YIbYI2825E4Z2b/3@kroah.com>
References: <YIa2ErYuJyCfSkS+@kroah.com>
 <20210427002648.22459fa7@elm.ozlabs.ibm.com>
 <YIbYI2825E4Z2b/3@kroah.com>
Message-ID: <CAHk-=wgWLrNQeV20DiCnJVQpfKFkbtC+8=rAqt-wyBFMrHToEw@mail.gmail.com>

On Mon, Apr 26, 2021 at 8:11 AM Greg KH <gregkh at linuxfoundation.org> wrote:
>
> Yeah, merge issues with other trees are hard to resolve in the single
> tree here, not much I can just yet, have to wait for them to hit Linus's
> tree.

It's generally a good idea to mention these things if you know about
them, just in case the other tree had come in in the meantime and I
had merged it first.

That didn't happen this time, and I do generally catch these things
anyway as long as they at least trigger problems for my usual x86-64
allmodconfig builds (but not everything does trigger that).

              Linus


From maz at kernel.org  Mon Apr 26 19:24:39 2021
From: maz at kernel.org (Marc Zyngier)
Date: Mon, 26 Apr 2021 19:24:39 +0100
Subject: [PATCH v13 03/18] arm64: hyp-stub: Move el1_sync into the vectors
In-Reply-To: <CA+CK2bADNkoX-Q3tNyjJ7fo6-f4sBPkAVYLiQh-rxFOcHzbJGw@mail.gmail.com>
References: <20210408040537.2703241-1-pasha.tatashin@soleen.com>
 <20210408040537.2703241-4-pasha.tatashin@soleen.com>
 <480272f8fb3e46d24a0ee1418fb85809@kernel.org>
 <CA+CK2bDc+9EsH_TLTgg9Pqv_-rZfZfPohdZEfsYjT8ss+8skjg@mail.gmail.com>
 <87v98wom5n.wl-maz@kernel.org>
 <CA+CK2bB9M05UKfvu66_wMK1u_HBvRws4R0KxPgTu4vPdKuGy9w@mail.gmail.com>
 <CA+CK2bADNkoX-Q3tNyjJ7fo6-f4sBPkAVYLiQh-rxFOcHzbJGw@mail.gmail.com>
Message-ID: <ae6b032cee2ebc3c6a1c531d9bf8bee1@kernel.org>

On 2021-04-26 19:10, Pavel Tatashin wrote:
> Hi Marc
> 
> Are you planning to send more review comments, or should I send the new 
> version?

Yeah, I'll hopefully have a bit more bandwidth in a few days.
You shouldn't post this kind of code during the merge window anyway... 
;-)

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...


From pali at kernel.org  Mon Apr 26 19:36:12 2021
From: pali at kernel.org (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Mon, 26 Apr 2021 20:36:12 +0200
Subject: [PATCH mvebu + mvebu/dt64 4/4] arm64: dts: marvell: armada-37xx:
 move firmware node to generic dtsi file
In-Reply-To: <YE9OMFHwLi8q0qnb@lunn.ch>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210308153703.23097-4-kabel@kernel.org>
 <87czw4kath.fsf@BL-laptop> <20210312101027.1997ec75@kernel.org>
 <YEt/Ll08M1cwgGR/@lunn.ch> <20210312161704.5e575906@kernel.org>
 <YEuOfI5FKLYgdQV+@lunn.ch> <20210315101454.dpyfdwk43poirxlw@pali>
 <YE9OMFHwLi8q0qnb@lunn.ch>
Message-ID: <20210426183612.kj5g3wklgue3gx55@pali>

On Monday 15 March 2021 13:08:16 Andrew Lunn wrote:
> On Mon, Mar 15, 2021 at 11:14:54AM +0100, Pali Roh?r wrote:
> > On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
> > > > So theoretically the turris-mox-rwtm driver can be renamed into
> > > > something else and we can add a different compatible in order not to
> > > > sound so turris-mox specific.
> > > 
> > > That would be a good idea. And if possible, try to push the hardware
> > > random number code upstream in the firmware repos, so everybody gets
> > > it by default, not just those using your build. Who is responsible for
> > > upstream? Marvell?
> > > 
> > > 	  Andrew
> > 
> > Hello Andrew!
> > 
> > I do not think that renaming driver is the best option. For future it
> > would complicate backporting patches to stable kernel and also it would
> > make usage of 'gitk' harder as this tool cannot automatically track file
> > renames.
> 
> Hi Pali
> 
> I'm not suggesting renaming the .c file.
> 
> What would be good is to add additional compatible strings. Add a more
> generic compatible. What goes into the .dtsi should use the generic
> name. Also, the node names should also be generic, since the node name
> is probably not used anywhere, just the compatible string. Keep the
> current compatible in the driver, for backwards compatibility with
> older DT blobs.

Ok! What about compatible string "marvell,armada-3700-rwtm-firmware"?

Mailbox layer which is used by this driver has compatible string
"marvell,armada-3700-rwtm-mailbox", so name is similar.


From torvalds at linux-foundation.org  Mon Apr 26 20:39:01 2021
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Mon, 26 Apr 2021 12:39:01 -0700
Subject: [GIT PULL 0/6] ARM SoC branches for 5.13
In-Reply-To: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
Message-ID: <CAHk-=wgDQ23kEkVVhjwcVPkQCDUVmJJdhO_HtjaRRCv_mtZgag@mail.gmail.com>

On Mon, Apr 26, 2021 at 8:53 AM Arnd Bergmann <arnd at kernel.org> wrote:
>
> Here are six branches for the SoC tree [...]

Ok, all merged. Please do check my conflict resolutions - not because
I think there is anything wrong there, but simply because the arm side
doesn't get the same build coverage testing when I merge.

All but the two first had some fairly trivial conflicts with the other
trees I've been merging today.

              Linus


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:32 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:32 +0000
Subject: [GIT PULL 4/6] ARM: devicetree changes for 5.13
In-Reply-To: <CAK8P3a0=urEEHzcQt0u2fbb7SLDO6NGs8aeYvNpj=jP+YWd2Hw@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a0=urEEHzcQt0u2fbb7SLDO6NGs8aeYvNpj=jP+YWd2Hw@mail.gmail.com>
Message-ID: <161946615251.4821.10515143179081060713.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 17:57:08 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-dt-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f7857bf3745e9ede6367a8ff89c1c4f308bfd914

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:32 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:32 +0000
Subject: [GIT PULL 2/6] ARM: defconfigs for v5.13
In-Reply-To: <CAK8P3a0WbrYBeR_VMBDfgC9R7aVXna26_LQjdHrd2xnN9e6_Cg@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a0WbrYBeR_VMBDfgC9R7aVXna26_LQjdHrd2xnN9e6_Cg@mail.gmail.com>
Message-ID: <161946615201.4821.6020771080190512041.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 17:54:30 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-defconfig-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2b90506a8186df5f7c81ad1ebd250103d8469e27

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:31 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:31 +0000
Subject: [GIT PULL 1/6] ARM: SoC changes for v5.13
In-Reply-To: <CAK8P3a08ONpuYxcNOOr1Yr04SYosAPKH+i=PPp9h0hvhknn+Mg@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a08ONpuYxcNOOr1Yr04SYosAPKH+i=PPp9h0hvhknn+Mg@mail.gmail.com>
Message-ID: <161946615169.4821.6059481784147393808.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 17:53:31 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-soc-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/01d7136894410a71932096e0fb9f1d301b6ccf07

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:32 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:32 +0000
Subject: [GIT PULL 3/6] ARM: SoC drivers for v5.13
In-Reply-To: <CAK8P3a3uSjSyrRAq2BjR2fo6S7kCfOo+3szQ2cvBt8-D2KybwQ@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a3uSjSyrRAq2BjR2fo6S7kCfOo+3szQ2cvBt8-D2KybwQ@mail.gmail.com>
Message-ID: <161946615226.4821.9858108754030458185.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 17:55:47 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-drivers-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/37f00ab4a003f371f81e0eae76cf372f06dec780

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:32 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:32 +0000
Subject: [GIT PULL 6/6,
 look out for dependencies ] ARM: platform support for Apple M1
In-Reply-To: <CAK8P3a388f9iSncTW-sAdbeg3-=vc=6r0X9392puGE=FsWy=Yw@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a388f9iSncTW-sAdbeg3-=vc=6r0X9392puGE=FsWy=Yw@mail.gmail.com>
Message-ID: <161946615297.4821.6463208046152364085.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 18:05:42 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-apple-m1-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0c855563182001c829065faa17f8e29e9ceffe13

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From pr-tracker-bot at kernel.org  Mon Apr 26 20:42:32 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Mon, 26 Apr 2021 19:42:32 +0000
Subject: [GIT PULL 5/6] ARM: platform support for Nuvoton WPCM450
In-Reply-To: <CAK8P3a2apTEYei_w6+_dM5a6ZD+QCA65x9hDjVWe2ueVO2C_dw@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAK8P3a2apTEYei_w6+_dM5a6ZD+QCA65x9hDjVWe2ueVO2C_dw@mail.gmail.com>
Message-ID: <161946615276.4821.7651727399452852128.pr-tracker-bot@kernel.org>

The pull request you sent on Mon, 26 Apr 2021 18:00:02 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/arm-newsoc-5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6b0fbc540c2fc34e55828ef9918cc61528071a01

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From andrew at lunn.ch  Mon Apr 26 20:52:09 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 26 Apr 2021 21:52:09 +0200
Subject: [PATCH mvebu + mvebu/dt64 4/4] arm64: dts: marvell: armada-37xx:
 move firmware node to generic dtsi file
In-Reply-To: <20210426183612.kj5g3wklgue3gx55@pali>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210308153703.23097-4-kabel@kernel.org>
 <87czw4kath.fsf@BL-laptop> <20210312101027.1997ec75@kernel.org>
 <YEt/Ll08M1cwgGR/@lunn.ch> <20210312161704.5e575906@kernel.org>
 <YEuOfI5FKLYgdQV+@lunn.ch> <20210315101454.dpyfdwk43poirxlw@pali>
 <YE9OMFHwLi8q0qnb@lunn.ch> <20210426183612.kj5g3wklgue3gx55@pali>
Message-ID: <YIcZ6cUSzp/1/liH@lunn.ch>

> Ok! What about compatible string "marvell,armada-3700-rwtm-firmware"?

Yes, that is O.K.

     Andrew


From u.kleine-koenig at pengutronix.de  Mon Apr 26 21:43:33 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Mon, 26 Apr 2021 22:43:33 +0200
Subject: [v2 2/2] pwm: Add Aspeed ast2600 PWM support
In-Reply-To: <20210414104939.1093-3-billy_tsai@aspeedtech.com>
References: <20210414104939.1093-1-billy_tsai@aspeedtech.com>
 <20210414104939.1093-3-billy_tsai@aspeedtech.com>
Message-ID: <20210426204333.gzqke6td33dtugnh@pengutronix.de>

On Wed, Apr 14, 2021 at 06:49:39PM +0800, Billy Tsai wrote:
> This patch add the support of PWM controller which can be found at aspeed
> ast2600 soc. The pwm supoorts up to 16 channels and it's part function
> of multi-funciton device "pwm-tach controller".

s/funciton/function/

> Signed-off-by: Billy Tsai <billy_tsai at aspeedtech.com>
> ---
>  drivers/pwm/Kconfig         |   7 +
>  drivers/pwm/Makefile        |   1 +
>  drivers/pwm/pwm-aspeed-g6.c | 324 ++++++++++++++++++++++++++++++++++++
>  3 files changed, 332 insertions(+)
>  create mode 100644 drivers/pwm/pwm-aspeed-g6.c
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 9a4f66ae8070..d6c1e25717d7 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -42,6 +42,13 @@ config PWM_DEBUG
>  	  It is expected to introduce some runtime overhead and diagnostic
>  	  output to the kernel log, so only enable while working on a driver.
>  
> +config PWM_ASPEED_G6
> +	tristate "ASPEEDG6 PWM support"
> +	depends on ARCH_ASPEED || COMPILE_TEST
> +	help
> +	  This driver provides support for ASPEED G6 PWM controllers.
> +
> +

A single empty line is enough. Please keep the list sorted.

>  config PWM_AB8500
>  	tristate "AB8500 PWM support"
>  	depends on AB8500_CORE && ARCH_U8500
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 6374d3b1d6f3..2d9b4590662e 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_PWM)		+= core.o
>  obj-$(CONFIG_PWM_SYSFS)		+= sysfs.o
> +obj-$(CONFIG_PWM_ASPEED_G6)	+= pwm-aspeed-g6.o
>  obj-$(CONFIG_PWM_AB8500)	+= pwm-ab8500.o

Ditto, this should be sorted alphabetically.

>  obj-$(CONFIG_PWM_ATMEL)		+= pwm-atmel.o
>  obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)	+= pwm-atmel-hlcdc.o
> diff --git a/drivers/pwm/pwm-aspeed-g6.c b/drivers/pwm/pwm-aspeed-g6.c
> new file mode 100644
> index 000000000000..b537a5d7015a
> --- /dev/null
> +++ b/drivers/pwm/pwm-aspeed-g6.c
> @@ -0,0 +1,324 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2021 ASPEED Technology Inc.
> + *
> + * PWM controller driver for Aspeed ast26xx SoCs.
> + * This drivers doesn't rollback to previous version of aspeed SoCs.
> + *
> + * Hardware Features:

Please call this "Limitations" for easier grepping.

> + * 1. Support up to 16 channels
> + * 2. Support PWM frequency range from 24Hz to 780KHz
> + * 3. Duty cycle from 0 to 100% with 1/256 resolution incremental
> + * 4. Support wdt reset tolerance (Driver not ready)

The interesting facts to mention here are: Does the hardware complete a
period on configuration changes? Does the hardware complete a period on
disable? Does the hardware switch configuration atomically, that is if
it is currently running with

	.duty_cycle = A + .period = B

and is then asked to run at

	.duty_cycle = C + .period = D

can it happen, that we see a period with .duty_cycle = A and period
length D, or similar? If this is configurable, please program the
hardware that is completes a currently running period and then
atomically switches to the new setting.

> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/errno.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/sysfs.h>
> +#include <linux/reset.h>
> +#include <linux/regmap.h>
> +#include <linux/bitfield.h>
> +#include <linux/slab.h>
> +#include <linux/pwm.h>

empty line here

> +/* The channel number of Aspeed pwm controller */
> +#define PWM_ASPEED_NR_PWMS 16
> +
> +/* PWM Control Register */
> +#define PWM_ASPEED_CTRL_CH(ch) (((ch * 0x10) + 0x00))
> +#define PWM_LOAD_SEL_RISING_AS_WDT BIT(19)
> +#define PWM_DUTY_LOAD_AS_WDT_ENABLE BIT(18)
> +#define PWM_DUTY_SYNC_DISABLE BIT(17)
> +#define PWM_CLK_ENABLE BIT(16)
> +#define PWM_LEVEL_OUTPUT BIT(15)
> +#define PWM_INVERSE BIT(14)
> +#define PWM_OPEN_DRAIN_ENABLE BIT(13)
> +#define PWM_PIN_ENABLE BIT(12)
> +#define PWM_CLK_DIV_H GENMASK(11, 8)
> +#define PWM_CLK_DIV_L GENMASK(7, 0)
> +
> +/* PWM Duty Cycle Register */
> +#define PWM_ASPEED_DUTY_CYCLE_CH(ch) (((ch * 0x10) + 0x04))
> +#define PWM_PERIOD GENMASK(31, 24)
> +#define PWM_POINT_AS_WDT GENMASK(23, 16)
> +#define PWM_FALLING_POINT GENMASK(15, 8)
> +#define PWM_RISING_POINT GENMASK(7, 0)

Please use a common prefix for register defines. Also ch must be used in
parenthesis, Something like:

	#define PWM_ASPEED_CTRL(ch)			(0x00 + (ch) * 0x10)
	#define PWM_ASPEED_CTRL_LOAD_SEL_RISING_AS_WDT		BIT(19)
	...

	#define ASPEED_PWM_DUTY_CYCLE(ch)		(0x04 + (ch) * 0x10)
	#define ASPEED_PWM_DUTY_CYCLE_PERIOD			GENMASK(31, 24)
	#define ASPEED_PWM_DUTY_CYCLE_POINT_AS_WDT		GENMASK(23, 16)
	...

(I already asked that in reply to your v1.)

> +/* PWM fixed value */
> +#define PWM_FIXED_PERIOD 0xff
> +
> +struct aspeed_pwm_data {
> +	struct pwm_chip chip;
> +	struct clk *clk;
> +	struct regmap *regmap;
> +	struct reset_control *reset;
> +};
> +
> +static void aspeed_set_pwm_channel_enable(struct regmap *regmap, u8 pwm_channel,
> +					  bool enable)
> +{
> +	regmap_update_bits(regmap, PWM_ASPEED_CTRL_CH(pwm_channel),
> +			   (PWM_CLK_ENABLE | PWM_PIN_ENABLE),
> +			   enable ? (PWM_CLK_ENABLE | PWM_PIN_ENABLE) : 0);

What is the semantic difference between CLK_ENABLE and PIN_ENABLE? Does
the pin stay at it's inactive level if PIN_ENABLE is unset? Does the
output just freeze at it's current level if CLK_ENABLE is unset?

> +}
> +/*
> + * The PWM frequency = HCLK(200Mhz) / (clock division L bit *
> + * clock division H bit * (period bit + 1))
> + */
> +static void aspeed_set_pwm_freq(struct aspeed_pwm_data *priv,
> +				struct pwm_device *pwm, u32 freq)
> +{
> +	u32 target_div, freq_a_fix_div, out_freq;
> +	u32 tmp_div_h, tmp_div_l, diff, min_diff = INT_MAX;
> +	u32 div_h = BIT(5) - 1, div_l = BIT(8) - 1;
> +	u8 div_found;
> +	u32 index = pwm->hwpwm;
> +	/* Frequency after fixed divide */
> +	freq_a_fix_div = clk_get_rate(priv->clk) / (PWM_FIXED_PERIOD + 1);
> +	/*
> +	 * Use round up to avoid 0 case.
> +	 * After that the only scenario which can't find divide pair is too slow
> +	 */
> +	target_div = DIV_ROUND_UP(freq_a_fix_div, freq);

You're losing precision here, as freq is already the result of a division.

> +	div_found = 0;
> +	/* calculate for target frequency */
> +	for (tmp_div_h = 0; tmp_div_h < 0x10; tmp_div_h++) {
> +		tmp_div_l = target_div / BIT(tmp_div_h) - 1;
> +
> +		if (tmp_div_l < 0 || tmp_div_l > 255)
> +			continue;
> +
> +		diff = freq - ((freq_a_fix_div >> tmp_div_h) / (tmp_div_l + 1));
> +		if (abs(diff) < abs(min_diff)) {
> +			min_diff = diff;
> +			div_l = tmp_div_l;
> +			div_h = tmp_div_h;
> +			div_found = 1;
> +			if (diff == 0)
> +				break;
> +		}
> +	}
> +	if (div_found == 0) {
> +		pr_debug("target freq: %d too slow set minimal frequency\n",
> +			 freq);
> +	}
> +	out_freq = freq_a_fix_div / (BIT(div_h) * (div_l + 1));

This is overly complicated. Just pick the smallest value for div_h that
allows to approximate the period. Using a bigger div_h doesn't have any
advantage as it just results in using a smaller div_l which makes the
resolution more coarse. So something like:

	rate = clk_get_rate(...);

	/* this might need some reordering to prevent an integer overflow */
	div_h = round_up(state->period * rate / (256 * NSEC_PER_SEC * (PWM_PERIOD + 1)));
	div_h = order_base_2(div_h);
	if (div_h > 0xf)
		div_h = 0xf

	div_l = round_up((state->period * rate) >> div_h / (NSEC_PER_SEC * (PWM_PERIOD + 1)));
	if (div_l == 0)
		/* period too small, cannot implement it */
		return -ERANGE;

	div_l -= 1;

	if (div_l > 255)
		div_l = 255;


The intended goal is to provide the biggest possible period not bigger
than the requested value.

> +	pr_debug("div h %x, l : %x\n", div_h, div_l);
> +	pr_debug("hclk %ld, target pwm freq %d, real pwm freq %d\n",
> +		 clk_get_rate(priv->clk), freq, out_freq);
> +
> +	regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL_CH(index),
> +			   (PWM_CLK_DIV_H | PWM_CLK_DIV_L),
> +			   FIELD_PREP(PWM_CLK_DIV_H, div_h) |
> +				   FIELD_PREP(PWM_CLK_DIV_L, div_l));
> +}
> +
> +static void aspeed_set_pwm_duty(struct aspeed_pwm_data *priv,
> +				struct pwm_device *pwm, u32 duty_pt)
> +{
> +	u32 index = pwm->hwpwm;
> +
> +	if (duty_pt == 0) {
> +		aspeed_set_pwm_channel_enable(priv->regmap, index, false);
> +	} else {
> +		regmap_update_bits(priv->regmap,
> +				   PWM_ASPEED_DUTY_CYCLE_CH(index),
> +				   PWM_FALLING_POINT,
> +				   FIELD_PREP(PWM_FALLING_POINT, duty_pt));
> +		aspeed_set_pwm_channel_enable(priv->regmap, index, true);
> +	}
> +}
> +
> +static void aspeed_set_pwm_polarity(struct aspeed_pwm_data *priv,
> +				    struct pwm_device *pwm, u8 polarity)

polarity is an enum, not an u8.

> +{
> +	u32 index = pwm->hwpwm;
> +
> +	regmap_update_bits(priv->regmap, PWM_ASPEED_CTRL_CH(index), PWM_INVERSE,
> +			   (polarity) ? PWM_INVERSE : 0);

You can drop the parenthesis around polarity.

> +}
> +
> +static int aspeed_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct device *dev = chip->dev;
> +	struct aspeed_pwm_data *priv = dev_get_drvdata(dev);
> +	struct pwm_state *channel;
> +	u32 index = pwm->hwpwm;
> +	/*
> +	 * Fixed the period to the max value and rising point to 0
> +	 * for high resolution and simplified frequency calculation.

Stray character before "simplified".

> +	 */
> +	regmap_update_bits(priv->regmap, PWM_ASPEED_DUTY_CYCLE_CH(index),
> +			   PWM_PERIOD,
> +			   FIELD_PREP(PWM_PERIOD, PWM_FIXED_PERIOD));
> +
> +	regmap_update_bits(priv->regmap, PWM_ASPEED_DUTY_CYCLE_CH(index),
> +			   PWM_RISING_POINT, 0);

.request() is not supposed to touch the hardware configuration. Only
.apply() is allowed to modify the output. Also initialisation isn't
supposed to happen in case the bootloader setup the hardware for some
purpose.

> +	channel = kzalloc(sizeof(*channel), GFP_KERNEL);
> +	if (!channel)
> +		return -ENOMEM;
> +
> +	return pwm_set_chip_data(pwm, channel);
> +}
> +
> +static void aspeed_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct pwm_state *channel = pwm_get_chip_data(pwm);
> +
> +	kfree(channel);
> +}
> +
> +static inline struct aspeed_pwm_data *
> +aspeed_pwm_chip_to_data(struct pwm_chip *c)
> +{
> +	return container_of(c, struct aspeed_pwm_data, chip);
> +}
> +
> +static int aspeed_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +			    const struct pwm_state *state)
> +{
> +	struct device *dev = chip->dev;
> +	struct aspeed_pwm_data *priv = aspeed_pwm_chip_to_data(chip);
> +	struct pwm_state *channel = pwm_get_chip_data(pwm);
> +	/* compute the ns to Hz */
> +	u32 freq = DIV_ROUND_UP_ULL(1000000000, state->period);

Please use NSEC_PER_SEC here.

> +	u32 duty_pt = DIV_ROUND_UP_ULL(
> +		state->duty_cycle * (PWM_FIXED_PERIOD + 1), state->period);

In the v1 thread you said you have to set PWM_FALLING_POINT to
PWM_RISING_POINT to implement a 100% relative duty cycle. It seems this
only works by chance here (because duty_pt will be 256 in this case. The
value & 255 is written to the PWM_FALLING_POINT bit field). Assuming
this is what you intended, this needs some comment to be understandable.

Also please round down in the division to never provide a duty_cycle
bigger than the requested vaule. Also you have to use the actually used
period as divider, not state->period.

> +	dev_dbg(dev, "freq: %d, duty_pt: %d", freq, duty_pt);
> +	if (state->enabled) {
> +		aspeed_set_pwm_freq(priv, pwm, freq);
> +		aspeed_set_pwm_duty(priv, pwm, duty_pt);
> +		aspeed_set_pwm_polarity(priv, pwm, state->polarity);

How does the hardware behave in between these calls? If for example the
polarity is changed, does this affect the output immediately? Does this
start a new period?

> +	} else {
> +		aspeed_set_pwm_duty(priv, pwm, 0);
> +	}
> +	channel->period = state->period;
> +	channel->duty_cycle = state->duty_cycle;
> +	channel->polarity = state->polarity;
> +	channel->enabled = state->enabled;
> +
> +	return 0;
> +}
> +
> +static void aspeed_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +				 struct pwm_state *state)
> +{
> +	struct pwm_state *channel = pwm_get_chip_data(pwm);
> +
> +	state->period = channel->period;
> +	state->duty_cycle = channel->duty_cycle;
> +	state->polarity = channel->polarity;
> +	state->enabled = channel->enabled;

This is not what .get_state() is supposed to do. You should read the
hardware registers and then fill state with the description of the
actually emitted wave form.

> +}
> +
> +static const struct pwm_ops aspeed_pwm_ops = {
> +	.request = aspeed_pwm_request,
> +	.free = aspeed_pwm_free,
> +	.apply = aspeed_pwm_apply,
> +	.get_state = aspeed_pwm_get_state,
> +	.owner = THIS_MODULE,
> +};
> +
> +static int aspeed_pwm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	int ret;
> +	struct aspeed_pwm_data *priv;
> +	struct device_node *np;
> +
> +	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	np = pdev->dev.parent->of_node;
> +	if (!of_device_is_compatible(np, "aspeed,ast2600-pwm-tach")) {
> +		dev_err(dev, "unsupported pwm device binding\n");
> +		return -ENODEV;
> +	}
> +
> +	priv->regmap = syscon_node_to_regmap(np);
> +	if (IS_ERR(priv->regmap)) {
> +		dev_err(dev, "Couldn't get regmap\n");
> +		return -ENODEV;
> +	}
> +
> +	priv->clk = devm_clk_get(dev, NULL);
> +	if (IS_ERR(priv->clk))
> +		return -ENODEV;

Please consider using dev_err_probe to emit an error message here. Also
for the other error paths for consistency.

> +	ret = clk_prepare_enable(priv->clk);
> +	if (ret) {
> +		dev_err(dev, "couldn't enable clock\n");
> +		return ret;
> +	}
> +
> +	priv->reset = reset_control_get_shared(dev, NULL);
> +	if (IS_ERR(priv->reset)) {
> +		dev_err(dev, "can't get aspeed_pwm_tacho reset: %pe\n",
> +			ERR_PTR((long)priv->reset));

This cast can (and should) be dropped.

> +		return PTR_ERR(priv->reset);
> +	}
> +
> +	ret = reset_control_deassert(priv->reset);
> +	if (ret) {
> +		dev_err(&pdev->dev, "cannot deassert reset control: %pe\n",
> +			ERR_PTR(ret));

You have to undo clk_prepare_enable() here.

> +		return ret;
> +	}
> +
> +	priv->chip.dev = dev;
> +	priv->chip.ops = &aspeed_pwm_ops;
> +	priv->chip.npwm = PWM_ASPEED_NR_PWMS;
> +	priv->chip.of_xlate = of_pwm_xlate_with_flags;
> +	priv->chip.of_pwm_n_cells = 3;
> +
> +	ret = pwmchip_add(&priv->chip);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to add PWM chip: %pe\n", ERR_PTR(ret));

Again missing clk_disable_unprepare.

> +		return ret;
> +	}
> +	dev_set_drvdata(dev, priv);
> +	return ret;
> +}
> +
> +static int aspeed_pwm_remove(struct platform_device *dev)
> +{
> +	struct aspeed_pwm_data *priv = platform_get_drvdata(dev);
> +
> +	reset_control_assert(priv->reset);
> +	clk_disable_unprepare(priv->clk);
> +
> +	return pwmchip_remove(&priv->chip);

Please clean up in reverse order compared to probe. Also there is no
need to check the return value of pwmchip_remove, so this should be:

	pwmchip_remove(&priv->chip);
	reset_control_assert(priv->reset);
	clk_disable_unprepare(priv->clk);

> +}
> +
> +static const struct of_device_id of_pwm_match_table[] = {
> +	{
> +		.compatible = "aspeed,ast2600-pwm",
> +	},
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, of_pwm_match_table);
> +
> +static struct platform_driver aspeed_pwm_driver = {
> +	.probe		= aspeed_pwm_probe,
> +	.remove		= aspeed_pwm_remove,
> +	.driver		= {
> +		.name	= "aspeed_pwm",
> +		.of_match_table = of_pwm_match_table,
> +	},
> +};
> +
> +module_platform_driver(aspeed_pwm_driver);
> +
> +MODULE_AUTHOR("Billy Tsai <billy_tsai at aspeedtech.com>");
> +MODULE_DESCRIPTION("ASPEED PWM device driver");
> +MODULE_LICENSE("GPL v2");

-- 
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/20210426/0a040548/attachment-0001.sig>

From f.fainelli at gmail.com  Mon Apr 26 22:36:46 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 26 Apr 2021 14:36:46 -0700
Subject: [PATCH] thermal: brcmstb_thermal: Interrupt is optional
Message-ID: <20210426213647.704823-1-f.fainelli@gmail.com>

Utilize platform_get_irq_optional() to silence these messages:

brcmstb_thermal a581500.thermal: IRQ index 0 not found

Signed-off-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/thermal/broadcom/brcmstb_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c b/drivers/thermal/broadcom/brcmstb_thermal.c
index 8df5edef1ded..0cedb8b4f00a 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -351,7 +351,7 @@ static int brcmstb_thermal_probe(struct platform_device *pdev)
 
 	priv->thermal = thermal;
 
-	irq = platform_get_irq(pdev, 0);
+	irq = platform_get_irq_optional(pdev, 0);
 	if (irq >= 0) {
 		ret = devm_request_threaded_irq(&pdev->dev, irq, NULL,
 						brcmstb_tmon_irq_thread,
-- 
2.25.1



From lkp at intel.com  Mon Apr 26 23:33:57 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 27 Apr 2021 06:33:57 +0800
Subject: [PATCH] KVM: arm64: fix boolreturn.cocci warnings
In-Reply-To: <202104270655.gBGhIPdZ-lkp@intel.com>
References: <202104270655.gBGhIPdZ-lkp@intel.com>
Message-ID: <20210426223357.GA45871@cd4295a34ed8>

From: kernel test robot <lkp at intel.com>

arch/arm64/kvm/mmu.c:1114:9-10: WARNING: return of 0/1 in function 'kvm_age_gfn' with return type bool
arch/arm64/kvm/mmu.c:1084:9-10: WARNING: return of 0/1 in function 'kvm_set_spte_gfn' with return type bool
arch/arm64/kvm/mmu.c:1127:9-10: WARNING: return of 0/1 in function 'kvm_test_age_gfn' with return type bool
arch/arm64/kvm/mmu.c:1070:9-10: WARNING: return of 0/1 in function 'kvm_unmap_gfn_range' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

Fixes: cd4c71835228 ("KVM: arm64: Convert to the gfn-based MMU notifier callbacks")
CC: Sean Christopherson <seanjc at google.com>
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: kernel test robot <lkp at intel.com>
---

tree:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head:   9f242010c3b46e63bc62f08fff42cef992d3801b
commit: cd4c7183522817087278b3e000b8a888f9f91b5c [134/252] KVM: arm64: Convert to the gfn-based MMU notifier callbacks

 mmu.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1067,13 +1067,13 @@ out_unlock:
 bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	if (!kvm->arch.mmu.pgt)
-		return 0;
+		return false;
 
 	__unmap_stage2_range(&kvm->arch.mmu, range->start << PAGE_SHIFT,
 			     (range->end - range->start) << PAGE_SHIFT,
 			     range->may_block);
 
-	return 0;
+	return false;
 }
 
 bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
@@ -1081,7 +1081,7 @@ bool kvm_set_spte_gfn(struct kvm *kvm, s
 	kvm_pfn_t pfn = pte_pfn(range->pte);
 
 	if (!kvm->arch.mmu.pgt)
-		return 0;
+		return false;
 
 	WARN_ON(range->end - range->start != 1);
 
@@ -1101,7 +1101,7 @@ bool kvm_set_spte_gfn(struct kvm *kvm, s
 			       PAGE_SIZE, __pfn_to_phys(pfn),
 			       KVM_PGTABLE_PROT_R, NULL);
 
-	return 0;
+	return false;
 }
 
 bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
@@ -1111,7 +1111,7 @@ bool kvm_age_gfn(struct kvm *kvm, struct
 	pte_t pte;
 
 	if (!kvm->arch.mmu.pgt)
-		return 0;
+		return false;
 
 	WARN_ON(size != PAGE_SIZE && size != PMD_SIZE && size != PUD_SIZE);
 
@@ -1124,7 +1124,7 @@ bool kvm_age_gfn(struct kvm *kvm, struct
 bool kvm_test_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
 {
 	if (!kvm->arch.mmu.pgt)
-		return 0;
+		return false;
 
 	return kvm_pgtable_stage2_is_young(kvm->arch.mmu.pgt,
 					   range->start << PAGE_SHIFT);


From linux at roeck-us.net  Mon Apr 26 23:39:42 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 26 Apr 2021 15:39:42 -0700
Subject: [PATCH 2/9] ARM: PXA: Kill use of irq_create_strict_mappings()
In-Reply-To: <20210406093557.1073423-3-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-3-maz@kernel.org>
Message-ID: <20210426223942.GA213931@roeck-us.net>

On Tue, Apr 06, 2021 at 10:35:50AM +0100, Marc Zyngier wrote:
> irq_create_strict_mappings() is a poor way to allow the use of
> a linear IRQ domain as a legacy one. Let's be upfront about
> it and use a legacy domain when appropriate.
> 
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---

When running the "mainstone" qemu emulation, this patch results
in many (32, actually) runtime warnings such as the following.

[    0.528272] ------------[ cut here ]------------
[    0.528285] WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:550 irq_domain_associate+0x194/0x1f0
[    0.528315] error: virq335 is not allocated
[    0.528325] Modules linked in:
[    0.528351] CPU: 0 PID: 1 Comm: swapper Tainted: G        W         5.12.0-rc8-next-20210423 #1
[    0.528372] Hardware name: Intel HCDDBBVA0 Development Platform (aka Mainstone)
[    0.528387] Backtrace:
[    0.528406] [<c06bd188>] (dump_backtrace) from [<c06bd468>] (show_stack+0x20/0x24)
[    0.528441]  r7:00000226 r6:c00796e8 r5:00000009 r4:c088d2a0
[    0.528454] [<c06bd448>] (show_stack) from [<c06c11dc>] (dump_stack+0x28/0x30)
[    0.528479] [<c06c11b4>] (dump_stack) from [<c002a2b8>] (__warn+0xe8/0x110)
[    0.528507]  r5:00000009 r4:c0872698
[    0.528520] [<c002a1d0>] (__warn) from [<c06bdbc0>] (warn_slowpath_fmt+0xa0/0xe0)
[    0.528551]  r7:c00796e8 r6:00000226 r5:c0872698 r4:c0872700
[    0.528564] [<c06bdb24>] (warn_slowpath_fmt) from [<c00796e8>] (irq_domain_associate+0x194/0x1f0)
[    0.528597]  r8:00000130 r7:0000014f r6:0000001f r5:00000000 r4:c11bd780
[    0.528610] [<c0079554>] (irq_domain_associate) from [<c00797a4>] (irq_domain_associate_many+0x60/0xa4)
[    0.528642]  r8:00000130 r7:c11bd780 r6:fffffed0 r5:00000150 r4:00000150
[    0.528655] [<c0079744>] (irq_domain_associate_many) from [<c0079e5c>] (irq_domain_create_legacy+0x5c/0x68)
[    0.528687]  r8:00000130 r7:00000130 r6:00000020 r5:00000000 r4:c11bd780
[    0.528699] [<c0079e00>] (irq_domain_create_legacy) from [<c0079e9c>] (irq_domain_add_legacy+0x34/0x3c)
[    0.528730]  r7:c09b1370 r6:c09b1360 r5:c11bd3a0 r4:00000000
[    0.528743] [<c0079e68>] (irq_domain_add_legacy) from [<c0024f28>] (cplds_probe+0x170/0x1ac)
[    0.528768] [<c0024db8>] (cplds_probe) from [<c0432cec>] (platform_probe+0x50/0xb0)
[    0.528800]  r8:c09d2c94 r7:c0aa4f88 r6:c09d2c94 r5:c09b1370 r4:00000000
[    0.528814] [<c0432c9c>] (platform_probe) from [<c042fc70>] (really_probe+0x100/0x4d4)
[    0.528844]  r7:c0aa4f88 r6:00000000 r5:00000000 r4:c09b1370
[    0.528858] [<c042fb70>] (really_probe) from [<c04300cc>] (driver_probe_device+0x88/0x20c)
[    0.528892]  r10:c0974830 r9:c0a70000 r8:c093b224 r7:c0a31de8 r6:c09d2c94 r5:c09d2c94
[    0.528907]  r4:c09b1370
[    0.528919] [<c0430044>] (driver_probe_device) from [<c04306cc>] (device_driver_attach+0x68/0x70)
[    0.528953]  r9:c0a70000 r8:c093b224 r7:c0a31de8 r6:c09d2c94 r5:00000000 r4:c09b1370
[    0.528969] [<c0430664>] (device_driver_attach) from [<c0430794>] (__driver_attach+0xc0/0x164)
[    0.528997]  r7:c0a31de8 r6:c09b1370 r5:c09d2c94 r4:00000000
[    0.529009] [<c04306d4>] (__driver_attach) from [<c042d8d0>] (bus_for_each_dev+0x84/0xcc)
[    0.529039]  r7:c0a31de8 r6:c04306d4 r5:c09d2c94 r4:00000000
[    0.529052] [<c042d84c>] (bus_for_each_dev) from [<c042f494>] (driver_attach+0x28/0x30)
[    0.529082]  r6:00000000 r5:c11bd200 r4:c09d2c94
[    0.529095] [<c042f46c>] (driver_attach) from [<c042edac>] (bus_add_driver+0x168/0x210)
[    0.529122] [<c042ec44>] (bus_add_driver) from [<c0431304>] (driver_register+0x88/0x120)
[    0.529152]  r7:c0a5c7e0 r6:00000000 r5:ffffe000 r4:c09d2c94
[    0.529165] [<c043127c>] (driver_register) from [<c04329a0>] (__platform_driver_register+0x2c/0x34)
[    0.529191]  r5:ffffe000 r4:c094ba64
[    0.529204] [<c0432974>] (__platform_driver_register) from [<c094ba84>] (cplds_driver_init+0x20/0x28)
[    0.529230] [<c094ba64>] (cplds_driver_init) from [<c000a2a8>] (do_one_initcall+0x60/0x27c)
[    0.529255] [<c000a248>] (do_one_initcall) from [<c093f244>] (kernel_init_freeable+0x158/0x1e4)
[    0.529284]  r7:c0974850 r6:00000007 r5:c0c0f720 r4:c09a02fc
[    0.529297] [<c093f0ec>] (kernel_init_freeable) from [<c06c5274>] (kernel_init+0x18/0x110)
[    0.529328]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06c525c
[    0.529343]  r4:00000000
[    0.529354] [<c06c525c>] (kernel_init) from [<c0008348>] (ret_from_fork+0x14/0x2c)
[    0.529387] Exception stack(0xc0bdffb0 to 0xc0bdfff8)
[    0.529467] ffa0:                                     00000000 00000000 00000000 00000000
[    0.529587] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.529684] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    0.529726]  r5:c06c525c r4:00000000
[    0.529752] ---[ end trace d199929d2b87e077 ]---

Bisect log attached.

Guenter

---
# bad: [e3d35712f85ac84fb06234848f6c043ab418cf8b] Add linux-next specific files for 20210423
# good: [bf05bf16c76bb44ab5156223e1e58e26dfe30a88] Linux 5.12-rc8
git bisect start 'HEAD' 'v5.12-rc8'
# good: [d4b5d9d94679a18bfa4ccdafd19876d58777911e] Merge remote-tracking branch 'crypto/master'
git bisect good d4b5d9d94679a18bfa4ccdafd19876d58777911e
# good: [27628e42fe59a698e66b671bf1e1f01f6a3fe765] Merge remote-tracking branch 'tip/auto-latest'
git bisect good 27628e42fe59a698e66b671bf1e1f01f6a3fe765
# bad: [bc6c3ae4f662fc719d0bf144f150f72cab8912d4] Merge remote-tracking branch 'vfio/next'
git bisect bad bc6c3ae4f662fc719d0bf144f150f72cab8912d4
# bad: [5ff5b00609c64a043ccd5bc92273c132b33f7f9a] Merge remote-tracking branch 'driver-core/driver-core-next'
git bisect bad 5ff5b00609c64a043ccd5bc92273c132b33f7f9a
# bad: [c878be9c883153797d5749620e58f180cc429e88] Merge remote-tracking branch 'kvm/next'
git bisect bad c878be9c883153797d5749620e58f180cc429e88
# good: [52acd22faa1af8a0514ccd075a6978ac97986425] KVM: Boost vCPU candidate in user mode which is delivering interrupt
git bisect good 52acd22faa1af8a0514ccd075a6978ac97986425
# good: [988aab640a6c46ab9552e65c2c3a8d577a4e30f3] rcu: Make rcu_gp_cleanup() be noinline for tracing
git bisect good 988aab640a6c46ab9552e65c2c3a8d577a4e30f3
# bad: [6603c2d8bd6cc7fa591fd3b4232bf25b65a0ea8f] Merge remote-tracking branch 'ftrace/for-next'
git bisect bad 6603c2d8bd6cc7fa591fd3b4232bf25b65a0ea8f
# good: [c658797f1a70561205a224be0c8be64977ed64e8] tracing: Add method for recording "func_repeats" events
git bisect good c658797f1a70561205a224be0c8be64977ed64e8
# good: [46135d6f878ab00261d4a2082d620bfb41019aab] irqchip/gic-v4.1: Disable vSGI upon (GIC CPUIF < v4.1) detection
git bisect good 46135d6f878ab00261d4a2082d620bfb41019aab
# bad: [05d7bf817019890e4d049e0b851940c596adbd9b] dt-bindings: interrupt-controller: Add IDT 79RC3243x Interrupt Controller
git bisect bad 05d7bf817019890e4d049e0b851940c596adbd9b
# bad: [1a0b05e435544cd53cd3936bdab425d88784b71a] irqdomain: Get rid of irq_create_strict_mappings()
git bisect bad 1a0b05e435544cd53cd3936bdab425d88784b71a
# bad: [5f8b938bd790cff6542c7fe3c1495c71f89fef1b] irqchip/jcore-aic: Kill use of irq_create_strict_mappings()
git bisect bad 5f8b938bd790cff6542c7fe3c1495c71f89fef1b
# bad: [b68761da01114a64b9c521975c3bca6d10eeb950] ARM: PXA: Kill use of irq_create_strict_mappings()
git bisect bad b68761da01114a64b9c521975c3bca6d10eeb950
# first bad commit: [b68761da01114a64b9c521975c3bca6d10eeb950] ARM: PXA: Kill use of irq_create_strict_mappings()


From peng.fan at nxp.com  Tue Apr 27 00:45:49 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Mon, 26 Apr 2021 23:45:49 +0000
Subject: [PATCH V5 0/8] remoteproc: imx_rproc: support i.MX7ULP/8MN/8MP
In-Reply-To: <20210426154623.GA1390475@xps15>
References: <1618971622-30539-1-git-send-email-peng.fan@oss.nxp.com>
 <20210422165634.GD1256950@xps15>
 <DB6PR0402MB2760E471A0391FF8A31980BA88459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <CANLsYkwoS+3qYq=FHRLMjrJSr5cj_PiHaU+a+M17C+8-VJ+b9g@mail.gmail.com>
 <DB6PR0402MB2760EA88942E5549BA9CC4B588459@DB6PR0402MB2760.eurprd04.prod.outlook.com>
 <20210426154623.GA1390475@xps15>
Message-ID: <DB6PR0402MB2760B5F403FDA7EDED34B31C88429@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> i.MX7ULP/8MN/8MP
> 
> On Fri, Apr 23, 2021 at 11:28:00PM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > > i.MX7ULP/8MN/8MP
> > >
> > > On Thu, 22 Apr 2021 at 19:01, Peng Fan <peng.fan at nxp.com> wrote:
> > > >
> > > > Hi Mathieu,
> > > >
> > > > > Subject: Re: [PATCH V5 0/8] remoteproc: imx_rproc: support
> > > > > i.MX7ULP/8MN/8MP
> > > > >
> > > > > On Wed, Apr 21, 2021 at 10:20:14AM +0800, peng.fan at oss.nxp.com
> > > wrote:
> > > > > > From: Peng Fan <peng.fan at nxp.com>
> > > > > >
> > > > > > V5:
> > > > > >  Add R-b tag
> > > > > >  Move the change in detect mode of patch 5 to patch 7 Per
> > > > > > Mathieu's comments
> > > > > >
> > > > > > V4:
> > > > > >  Typo fix
> > > > > >  patch 4: take state as a check condition  patch 5: move
> > > > > > regmap lookup/attach to imx_rproc_detect_mode  patch 6: add
> > > > > > imx_rproc_clk_enable for optional clk  patch 8: use
> > > > > > switch/case in imx_rproc_detect_mode
> > > > > > V3:
> > > > > >  Add A-b tag for Patch 1/2
> > > > > >  Fix the checkpatch warning for Patch 6,8
> > > > > >
> > > > > > V2:
> > > > > >  Patch 1/8, use fsl as vendor, typo fix  Because patchset [1]
> > > > > > has
> > > > > > v2 version, patch 5,6,7,8 are adapted that  change.
> > > > > >
> > > > > > This patchset is to support i.MX7ULP/8MN/8MP, also includes a
> > > > > > patch to parse fsl,auto-boot
> > > > > >
> > > > >
> > > > > One of the request I had from the last revision was to
> > > > > explicitly list what other patchset this work depends on and
> > > > > what branch it is based of, something I can't find here.
> > > >
> > > > Sorry, that patchset has been merged, so I remove that line.
> > > > I should mention that that patchset has been merged into Linux-next
> tree.
> > > >
> > >
> > > And what branch this set should be applied to is missing.
> >
> > I take latest linux-next/master for my upstream new feature work.
> >
> > >
> > > > >
> > > > > As such I am dropping this set and won't look at another
> > > > > revision before May 22nd.
> > > >
> > > > Ah. Is it just because that the dependency patchset not been
> > > > mentioned or you have issue applying the patchset that delay the
> > > > patchset for one
> > > month?
> > > >
> > >
> > > Both.
> >
> > I replay my flow:
> > git fetch linux-next
> > git checkout linux-next/master -b master-next-4-24-2021 pwclient list
> > -w "Peng Fan (OSS)" -s New | grep V5 | awk '{print $1}' | xargs -I {}
> > pwclient git-am {}
> >
> > It could successfully apply the patchset.
> > Applying patch #12215291 using 'git am'
> > Description: [V5,1/8] dt-bindings: remoteproc: imx_rproc: add
> > fsl,auto-boot property
> > Applying: dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot
> > property Applying patch #12215293 using 'git am'
> > Description: [V5,2/8] dt-bindings: remoteproc: imx_rproc: add i.MX7ULP
> > support
> > Applying: dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> > Applying patch #12215295 using 'git am'
> > Description: [V5,3/8] dt-bindings: remoteproc: imx_rproc: support
> > i.MX8MN/P
> > Applying: dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> > Applying patch #12215297 using 'git am'
> > Description: [V5,4/8] remoteproc: imx_rproc: parse fsl,auto-boot
> > Applying: remoteproc: imx_rproc: parse fsl,auto-boot Applying patch
> > #12215299 using 'git am'
> > Description: [V5,5/8] remoteproc: imx_rproc: initial support for
> > mutilple start/stop method
> > Applying: remoteproc: imx_rproc: initial support for mutilple
> > start/stop method Applying patch #12215301 using 'git am'
> > Description: [V5,6/8] remoteproc: imx_rproc: make clk optional
> > Applying: remoteproc: imx_rproc: make clk optional Applying patch
> > #12215303 using 'git am'
> > Description: [V5,7/8] remoteproc: imx_rproc: support i.MX7ULP
> > Applying: remoteproc: imx_rproc: support i.MX7ULP Applying patch
> > #12215305 using 'git am'
> > Description: [V5,8/8] remoteproc: imx_rproc: support i.MX8MN/P
> > Applying: remoteproc: imx_rproc: support i.MX8MN/P
> >
> >
> > If anything wrong my work flow conflicts with Linux remoteproc
> > subsystem upstream flow, please correct me, and I'll follow.
> >
> > Thanks for your time and patience on reviewing my patches. Sorry for
> > the inconvince that I bring in.
> >
> > Anyway please share me your flow to apply patches, I will try to avoid
> > unhappy things in following patches.
> >
> 
> All I asked is that you list the branch your work is based on _and_ any
> dependencies, something you did not do.

ok, got it.

> 
> I review hundreds of patchsets every year and knowing exactly how to work
> with a series goes a long way in saving precious time, time that can be used to
> review other people's submissions.
> 
> I am not angry at you but at the same time I can't review your patches if you
> are not ready to help me do so.

Understand. Since one month is a bit long period, I'll post v6 later to avoid
potential conflicts. Or if you could help check this V5 patchset based on
Linux-next/master, that would be appreciated.

Thanks,
Peng.

> 
> > Thanks,
> > Peng.
> >
> > >
> > > > Thanks,
> > > > Peng.
> > > >
> > > > >
> > > > > > Peng Fan (8):
> > > > > >   dt-bindings: remoteproc: imx_rproc: add fsl,auto-boot property
> > > > > >   dt-bindings: remoteproc: imx_rproc: add i.MX7ULP support
> > > > > >   dt-bindings: remoteproc: imx_rproc: support i.MX8MN/P
> > > > > >   remoteproc: imx_rproc: parse fsl,auto-boot
> > > > > >   remoteproc: imx_rproc: initial support for mutilple start/stop
> method
> > > > > >   remoteproc: imx_rproc: make clk optional
> > > > > >   remoteproc: imx_rproc: support i.MX7ULP
> > > > > >   remoteproc: imx_rproc: support i.MX8MN/P
> > > > > >
> > > > > >  .../bindings/remoteproc/fsl,imx-rproc.yaml    |  11 +-
> > > > > >  drivers/remoteproc/imx_rproc.c                | 196
> > > > > +++++++++++++++---
> > > > > >  2 files changed, 173 insertions(+), 34 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.30.0
> > > > > >


From jay.xu at rock-chips.com  Tue Apr 27 01:35:15 2021
From: jay.xu at rock-chips.com (jay.xu at rock-chips.com)
Date: Tue, 27 Apr 2021 08:35:15 +0800
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568
 SoC
References: <20210425094216.25724-1-cl@rock-chips.com>, 
 <20210425094439.25895-1-cl@rock-chips.com>, 
 <3d584cdc-020e-5aae-cae3-59ef45e64a9f@gmail.com>
Message-ID: <202104270835153474548@rock-chips.com>

Hi, Johan Jonker:

--------------
jay.xu at rock-chips.com
>Hi Liang,
>
>Some minor things to improve.
>Found with the command below.
>
>make ARCH=arm64 dtbs_check
>===
>
>pwm-rockchip.yaml is now in linux-next
>Maybe add rockchip,rk3568-pwm too.
>
>===
>
>compatible = "rockchip,rk3568";
>Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
>of board list ???
>Please advise.
>
>===
>
>Change rockchip,gpio-bank.yaml
>
>? clocks:
>??? maxItems: 2
>
>===
>
>TODO:
>rockchip,rk3568-grf
>rockchip,rk3568-pmugrf
>
>===
>
>git am
>PATCH-v2-5-7-arm64-dts-rockchip-add-generic-pinconfig-settings-used-by-most-Rockchip-socs.patch
>Applying: arm64: dts: rockchip: add generic pinconfig settings used by
>most Rockchip socs
>.git/rebase-apply/patch:356: new blank line at EOF.
>+
>warning: 1 line adds whitespace errors.
>
>===
>
>Change commit message in:
>[PATCH v2 3/7] dt-bindings: mmc: rockchip-dw-mshc: add description for
>rk3568
>
>from:
>add "rockchip,rk3568-dwcmshc", "snps,dwcmshc-sdhci" for mmc nodes on
>a rk3568 platform to rockchip-dw-mshc.yaml.
>
>to:
>... "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" ...
>
>Do not mix dw-mshc and dwcmshc. ;)
>
>===
>
>Johan
>
>On 4/25/21 11:44 AM, cl at rock-chips.com wrote:
>> From: Liang Chen <cl at rock-chips.com>
>>
>> RK3568 is a high-performance and low power quad-core application processor
>> designed for personal mobile internet device and AIoT equipments. This patch
>> add basic core dtsi file for it.
>>
>> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
>> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
>> enalbe a special high-performacne PLL when high frequency is required. The
>> smci_clk code is in ATF, and clkid for cpu is 0, as below:
>>
>>???? cpu0: cpu at 0 {
>>???????? device_type = "cpu";
>>???????? compatible = "arm,cortex-a55";
>>???????? reg = <0x0 0x0>;
>>???????? clocks = <&scmi_clk 0>;
>>???? };
>>
>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> ---
>>? .../boot/dts/rockchip/rk3568-pinctrl.dtsi???? | 3119 +++++++++++++++++
>>? arch/arm64/boot/dts/rockchip/rk3568.dtsi????? |? 812 +++++
>>? 2 files changed, 3931 insertions(+)
>>? create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>>? create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
>>
>
>[..]
>
>> +
>> +	gpio {
>
>From gpio.yaml
>
>properties:
>? gpio:
>??? # 'gpio' can appear as a property or node name
>??? oneOf:
>????? - type: object
>????? - $ref: "/schemas/types.yaml#/definitions/phandle-array"
> 
For this reason, then maybe we can change it to 'gpio-function' ?

>
>> +	/omit-if-no-ref/
>
>> +	tsadc_gpio: tsadc-gpio {
>
>From gpio-consumer.yaml
>
>properties:
>? gpios:
>??? $ref: "/schemas/types.yaml#/definitions/phandle-array"
>
>patternProperties:
>? "(?<!,nr)-gpios?$":
>??? $ref: "/schemas/types.yaml#/definitions/phandle-array"
>
>===
>
>Try to avoid anything with gpio.
>
>> +	rockchip,pins =
>> +	<0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
>> +	};
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> new file mode 100644
>> index 000000000000..66cb50218ca1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>> @@ -0,0 +1,812 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
>> + */
>> +
>> +#include <dt-bindings/clock/rk3568-cru.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/phy/phy.h>
>> +#include <dt-bindings/pinctrl/rockchip.h>
>> +#include <dt-bindings/soc/rockchip,boot-mode.h>
>> +#include <dt-bindings/thermal/thermal.h>
>> +
>> +/ {
>
>> +	compatible = "rockchip,rk3568";
>
>Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
>of board list ???
>Please advise.
>
>> +
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	aliases {
>> +	gpio0 = &gpio0;
>> +	gpio1 = &gpio1;
>> +	gpio2 = &gpio2;
>> +	gpio3 = &gpio3;
>> +	gpio4 = &gpio4;
>> +	i2c0 = &i2c0;
>> +	i2c1 = &i2c1;
>> +	i2c2 = &i2c2;
>> +	i2c3 = &i2c3;
>> +	i2c4 = &i2c4;
>> +	i2c5 = &i2c5;
>
>> +	mmc0 = &sdhci;
>> +	mmc1 = &sdmmc0;
>> +	mmc2 = &sdmmc1;
>> +	mmc3 = &sdmmc2;
>
>From a? privious discussion: aliases for mmc should go from the dtsi to
>the board dts
>sort mmc aliases based on reg address and availability, so no number gap
>
>> +	serial0 = &uart0;
>> +	serial1 = &uart1;
>> +	serial2 = &uart2;
>> +	serial3 = &uart3;
>> +	serial4 = &uart4;
>> +	serial5 = &uart5;
>> +	serial6 = &uart6;
>> +	serial7 = &uart7;
>> +	serial8 = &uart8;
>> +	serial9 = &uart9;
>> +	};
>> +
>> +	cpus {
>> +	#address-cells = <2>;
>> +	#size-cells = <0>;
>> +
>> +	cpu0: cpu at 0 {
>> +	device_type = "cpu";
>> +	compatible = "arm,cortex-a55";
>> +	reg = <0x0 0x0>;
>> +	clocks = <&scmi_clk 0>;
>> +	enable-method = "psci";
>> +	operating-points-v2 = <&cpu0_opp_table>;
>> +	};
>> +
>> +	cpu1: cpu at 100 {
>> +	device_type = "cpu";
>> +	compatible = "arm,cortex-a55";
>> +	reg = <0x0 0x100>;
>> +	enable-method = "psci";
>> +	operating-points-v2 = <&cpu0_opp_table>;
>> +	};
>> +
>> +	cpu2: cpu at 200 {
>> +	device_type = "cpu";
>> +	compatible = "arm,cortex-a55";
>> +	reg = <0x0 0x200>;
>> +	enable-method = "psci";
>> +	operating-points-v2 = <&cpu0_opp_table>;
>> +	};
>> +
>> +	cpu3: cpu at 300 {
>> +	device_type = "cpu";
>> +	compatible = "arm,cortex-a55";
>> +	reg = <0x0 0x300>;
>> +	enable-method = "psci";
>> +	operating-points-v2 = <&cpu0_opp_table>;
>> +	};
>> +	};
>> +
>> +	cpu0_opp_table: cpu0-opp-table {
>> +	compatible = "operating-points-v2";
>> +	opp-shared;
>> +
>> +	opp-408000000 {
>> +	opp-hz = /bits/ 64 <408000000>;
>> +	opp-microvolt = <825000 825000 1150000>;
>> +	clock-latency-ns = <40000>;
>> +	};
>
>Add all empty lines between
>
>> +	opp-600000000 {
>> +	opp-hz = /bits/ 64 <600000000>;
>> +	opp-microvolt = <825000 825000 1150000>;
>> +	};
>> +	opp-816000000 {
>> +	opp-hz = /bits/ 64 <816000000>;
>> +	opp-microvolt = <825000 825000 1150000>;
>> +	opp-suspend;
>> +	};
>> +	opp-1104000000 {
>> +	opp-hz = /bits/ 64 <1104000000>;
>> +	opp-microvolt = <825000 825000 1150000>;
>> +	};
>> +	opp-1416000000 {
>> +	opp-hz = /bits/ 64 <1416000000>;
>> +	opp-microvolt = <900000 900000 1150000>;
>> +	};
>> +	opp-1608000000 {
>> +	opp-hz = /bits/ 64 <1608000000>;
>> +	opp-microvolt = <975000 975000 1150000>;
>> +	};
>> +	opp-1800000000 {
>> +	opp-hz = /bits/ 64 <1800000000>;
>> +	opp-microvolt = <1050000 1050000 1150000>;
>> +	};
>> +	opp-1992000000 {
>> +	opp-hz = /bits/ 64 <1992000000>;
>> +	opp-microvolt = <1150000 1150000 1150000>;
>> +	};
>> +	};
>> +
>> +	firmware {
>> +	scmi: scmi {
>> +	compatible = "arm,scmi-smc";
>> +	arm,smc-id = <0x82000010>;
>> +	shmem = <&scmi_shmem>;
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +
>> +	scmi_clk: protocol at 14 {
>> +	reg = <0x14>;
>> +	#clock-cells = <1>;
>> +	};
>> +	};
>> +
>> +	};
>> +
>> +	pmu {
>
>> +	compatible = "arm,cortex-a55-pmu", "arm,armv8-pmuv3";
>
>compatible: ['arm,cortex-a55-pmu', 'arm,armv8-pmuv3'] is too long
>
>> +	interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
>> +	interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
>> +	};
>> +
>> +	psci {
>> +	compatible = "arm,psci-1.0";
>> +	method = "smc";
>> +	};
>> +
>
>> +	shmem at 10f000 {
>
>shmem at 10f000: $nodename:0: 'shmem at 10f000' does not match '^sram(@.*)?'
>
>> +	compatible = "mmio-sram";
>> +	reg = <0x0 0x0010f000 0x0 0x100>;
>> +
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +	ranges = <0 0x0 0x0010f000 0x100>;
>> +
>
>> +	scmi_shmem: scmi-shmem at 10f000 {
>
>shmem at 10f000: 'scmi-shmem at 10f000' does not match any of the regexes:
>'^([a-z]*-)?sram(-section)?@[a-f0-9]+$'
>
>> +	compatible = "arm,scmi-shmem";
>> +	reg = <0x0 0x0010f000 0x0 0x100>;
>> +	};
>> +	};
>> +
>> +	timer {
>> +	compatible = "arm,armv8-timer";
>> +	interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
>> +	arm,no-tick-in-suspend;
>> +	};
>> +
>> +	xin24m: xin24m {
>> +	compatible = "fixed-clock";
>> +	clock-frequency = <24000000>;
>> +	clock-output-names = "xin24m";
>> +	#clock-cells = <0>;
>> +	};
>> +
>> +	xin32k: xin32k {
>> +	compatible = "fixed-clock";
>> +	clock-frequency = <32768>;
>> +	clock-output-names = "xin32k";
>> +	pinctrl-0 = <&clk32k_out0>;
>> +	pinctrl-names = "default";
>> +	#clock-cells = <0>;
>> +	};
>> +
>> +	gic: interrupt-controller at fd400000 {
>> +	compatible = "arm,gic-v3";
>> +	reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
>> +	????? <0x0 0xfd460000 0 0xc0000>; /* GICR */
>> +	interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <3>;
>
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>
>subnodes ??
>
>> +	ranges;
>> +	};
>> +
>> +	pmugrf: syscon at fdc20000 {
>
>> +	compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
>
>TODO
>
>> +	reg = <0x0 0xfdc20000 0x0 0x10000>;
>> +
>> +	reboot_mode: reboot-mode {
>> +	compatible = "syscon-reboot-mode";
>> +	mode-bootloader = <BOOT_BL_DOWNLOAD>;
>> +	mode-fastboot = <BOOT_FASTBOOT>;
>> +	mode-loader = <BOOT_BL_DOWNLOAD>;
>> +	mode-normal = <BOOT_NORMAL>;
>> +	mode-recovery = <BOOT_RECOVERY>;
>> +	offset = <0x200>;
>> +	};
>> +	};
>> +
>> +	grf: syscon at fdc60000 {
>
>> +	compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
>
>TODO
>
>> +	reg = <0x0 0xfdc60000 0x0 0x10000>;
>> +	};
>> +
>> +	pmucru: clock-controller at fdd00000 {
>
>> +	compatible = "rockchip,rk3568-pmucru";
>> +	reg = <0x0 0xfdd00000 0x0 0x1000>;
>> +	rockchip,grf = <&grf>;
>> +	rockchip,pmugrf = <&pmugrf>;
>> +	#clock-cells = <1>;
>> +	#reset-cells = <1>;
>> +	};
>> +
>> +	cru: clock-controller at fdd20000 {
>> +	compatible = "rockchip,rk3568-cru";
>> +	reg = <0x0 0xfdd20000 0x0 0x1000>;
>> +	rockchip,grf = <&grf>;
>> +	#clock-cells = <1>;
>> +	#reset-cells = <1>;
>> +
>> +	assigned-clocks =
>> +	<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
>> +	<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
>> +	<&cru PLL_GPLL>, <&cru ACLK_BUS>,
>> +	<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
>> +	<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
>> +	<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
>> +	<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
>> +	<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
>> +	<&cru ACLK_VOP>;
>> +	assigned-clock-rates =
>> +	<32768>, <200000000>,
>> +	<100000000>, <1000000000>,
>> +	<1188000000>, <150000000>,
>> +	<100000000>, <500000000>,
>> +	<400000000>, <150000000>,
>> +	<100000000>, <300000000>,
>> +	<150000000>, <1200000000>,
>> +	<400000000>, <100000000>,
>> +	<500000000>;
>> +	assigned-clock-parents =
>> +	<&pmucru CLK_RTC32K_FRAC>;
>> +	};
>> +
>> +	i2c0: i2c at fdd40000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfdd40000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c0_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart0: serial at fdd50000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfdd50000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 0>, <&dmac0 1>;
>> +	pinctrl-0 = <&uart0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm0: pwm at fdd70000 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfdd70000 0x0 0x10>;
>> +	clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm0m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm1: pwm at fdd70010 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfdd70010 0x0 0x10>;
>> +	clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm1m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm2: pwm at fdd70020 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfdd70020 0x0 0x10>;
>> +	clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm2m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm3: pwm at fdd70030 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfdd70030 0x0 0x10>;
>> +	clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm3_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	sdmmc2: dwmmc at fe000000 {
>
>dwmmc at fe000000: $nodename:0: 'dwmmc at fe000000' does not match '^mmc(@.*)?$'
>
>> +	compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
>> +	reg = <0x0 0xfe000000 0x0 0x4000>;
>> +	interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
>> +	<&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
>> +	clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
>> +	fifo-depth = <0x100>;
>> +	max-frequency = <150000000>;
>> +	resets = <&cru SRST_SDMMC2>;
>> +	reset-names = "reset";
>> +	status = "disabled";
>> +	};
>> +
>
>> +	sdmmc0: dwmmc at fe2b0000 {
>
>dwmmc at fe2b0000: $nodename:0: 'dwmmc at fe2b0000' does not match '^mmc(@.*)?$'
>
>> +	compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
>> +	reg = <0x0 0xfe2b0000 0x0 0x4000>;
>> +	interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
>> +	<&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
>> +	clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
>> +	fifo-depth = <0x100>;
>> +	max-frequency = <150000000>;
>> +	resets = <&cru SRST_SDMMC0>;
>> +	reset-names = "reset";
>> +	status = "disabled";
>> +	};
>> +
>
>> +	sdmmc1: dwmmc at fe2c0000 {
>
>dwmmc at fe2c0000: $nodename:0: 'dwmmc at fe2c0000' does not match '^mmc(@.*)?$'
>
>> +	compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
>> +	reg = <0x0 0xfe2c0000 0x0 0x4000>;
>> +	interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
>> +	<&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
>> +	clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
>> +	fifo-depth = <0x100>;
>> +	max-frequency = <150000000>;
>> +	resets = <&cru SRST_SDMMC1>;
>> +	reset-names = "reset";
>> +	status = "disabled";
>> +	};
>> +
>
>> +	sdhci: sdhci at fe310000 {
>
>sdhci at fe310000: $nodename:0: 'sdhci at fe310000' does not match '^mmc(@.*)?$'
>
>> +	compatible = "rockchip,rk3568-dwcmshc";
>> +	reg = <0x0 0xfe310000 0x0 0x10000>;
>> +	interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
>> +	assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
>> +	assigned-clock-rates = <200000000>, <24000000>;
>> +	clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
>> +	<&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
>> +	<&cru TCLK_EMMC>;
>> +	clock-names = "core", "bus", "axi", "block", "timer";
>> +	status = "disabled";
>> +	};
>> +
>> +	dmac0: dmac at fe530000 {
>> +	compatible = "arm,pl330", "arm,primecell";
>> +	reg = <0x0 0xfe530000 0x0 0x4000>;
>> +	interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> +	arm,pl330-periph-burst;
>> +	clocks = <&cru ACLK_BUS>;
>> +	clock-names = "apb_pclk";
>> +	#dma-cells = <1>;
>> +	};
>> +
>> +	dmac1: dmac at fe550000 {
>> +	compatible = "arm,pl330", "arm,primecell";
>> +	reg = <0x0 0xfe550000 0x0 0x4000>;
>> +	interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
>> +	???? <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>> +	arm,pl330-periph-burst;
>> +	clocks = <&cru ACLK_BUS>;
>> +	clock-names = "apb_pclk";
>> +	#dma-cells = <1>;
>> +	};
>> +
>> +	i2c1: i2c at fe5a0000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfe5a0000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c1_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	i2c2: i2c at fe5b0000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfe5b0000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c2m0_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	i2c3: i2c at fe5c0000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfe5c0000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c3m0_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	i2c4: i2c at fe5d0000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfe5d0000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c4m0_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	i2c5: i2c at fe5e0000 {
>> +	compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
>> +	reg = <0x0 0xfe5e0000 0x0 0x1000>;
>> +	interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
>> +	clock-names = "i2c", "pclk";
>> +	pinctrl-0 = <&i2c5m0_xfer>;
>> +	pinctrl-names = "default";
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "disabled";
>> +	};
>> +
>> +	wdt: watchdog at fe600000 {
>> +	compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
>> +	reg = <0x0 0xfe600000 0x0 0x100>;
>
>> +	clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
>> +	clock-names = "tclk", "pclk";
>
>below interrupts
>
>> +	interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	};
>> +
>> +	uart1: serial at fe650000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe650000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 2>, <&dmac0 3>;
>> +	pinctrl-0 = <&uart1m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart2: serial at fe660000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe660000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 4>, <&dmac0 5>;
>> +	pinctrl-0 = <&uart2m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart3: serial at fe670000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe670000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 6>, <&dmac0 7>;
>> +	pinctrl-0 = <&uart3m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart4: serial at fe680000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe680000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 8>, <&dmac0 9>;
>> +	pinctrl-0 = <&uart4m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart5: serial at fe690000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe690000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 10>, <&dmac0 11>;
>> +	pinctrl-0 = <&uart5m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart6: serial at fe6a0000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe6a0000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 12>, <&dmac0 13>;
>> +	pinctrl-0 = <&uart6m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart7: serial at fe6b0000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe6b0000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 14>, <&dmac0 15>;
>> +	pinctrl-0 = <&uart7m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart8: serial at fe6c0000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe6c0000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 16>, <&dmac0 17>;
>> +	pinctrl-0 = <&uart8m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	uart9: serial at fe6d0000 {
>> +	compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
>> +	reg = <0x0 0xfe6d0000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
>> +	clock-names = "baudclk", "apb_pclk";
>> +	dmas = <&dmac0 18>, <&dmac0 19>;
>> +	pinctrl-0 = <&uart9m0_xfer>;
>> +	pinctrl-names = "default";
>> +	reg-io-width = <4>;
>> +	reg-shift = <2>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm4: pwm at fe6e0000 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6e0000 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm4_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm5: pwm at fe6e0010 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6e0010 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm5_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm6: pwm at fe6e0020 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6e0020 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm6_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm7: pwm at fe6e0030 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6e0030 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm7_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm8: pwm at fe6f0000 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6f0000 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm8m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm9: pwm at fe6f0010 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6f0010 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm9m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm10: pwm at fe6f0020 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6f0020 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm10m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm11: pwm at fe6f0030 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe6f0030 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm11m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm12: pwm at fe700000 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe700000 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm12m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm13: pwm at fe700010 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe700010 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm13m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm14: pwm at fe700020 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe700020 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm14m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pwm15: pwm at fe700030 {
>> +	compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
>> +	reg = <0x0 0xfe700030 0x0 0x10>;
>> +	clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
>> +	clock-names = "pwm", "pclk";
>> +	pinctrl-0 = <&pwm15m0_pins>;
>> +	pinctrl-names = "active";
>> +	#pwm-cells = <3>;
>> +	status = "disabled";
>> +	};
>> +
>> +	pinctrl: pinctrl {
>> +	compatible = "rockchip,rk3568-pinctrl";
>> +	rockchip,grf = <&grf>;
>> +	rockchip,pmu = <&pmugrf>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +	ranges;
>> +
>> +	gpio0: gpio at fdd60000 {
>> +	compatible = "rockchip,gpio-bank";
>> +	reg = <0x0 0xfdd60000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
>
>> +	gpio-controller;
>> +	#gpio-cells = <2>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <2>;
>> +	};
>> +
>> +	gpio1: gpio at fe740000 {
>> +	compatible = "rockchip,gpio-bank";
>> +	reg = <0x0 0xfe740000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
>
>> +	gpio-controller;
>> +	#gpio-cells = <2>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <2>;
>> +	};
>> +
>> +	gpio2: gpio at fe750000 {
>> +	compatible = "rockchip,gpio-bank";
>> +	reg = <0x0 0xfe750000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
>
>gpio at fe750000: clocks: [[13, 357], [13, 358]] is too long
>
>Change rockchip,gpio-bank.yaml
>
>? clocks:
>??? maxItems: 2
>
>> +	gpio-controller;
>> +	#gpio-cells = <2>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <2>;
>> +	};
>> +
>> +	gpio3: gpio at fe760000 {
>> +	compatible = "rockchip,gpio-bank";
>> +	reg = <0x0 0xfe760000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
>
>> +	gpio-controller;
>> +	#gpio-cells = <2>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <2>;
>> +	};
>> +
>> +	gpio4: gpio at fe770000 {
>> +	compatible = "rockchip,gpio-bank";
>> +	reg = <0x0 0xfe770000 0x0 0x100>;
>> +	interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
>
>> +	clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
>
>> +	gpio-controller;
>> +	#gpio-cells = <2>;
>> +	interrupt-controller;
>> +	#interrupt-cells = <2>;
>> +	};
>> +	};
>> +};
>> +
>> +#include "rk3568-pinctrl.dtsi"
>>
>
>
>

From tiantao6 at hisilicon.com  Tue Apr 27 01:49:35 2021
From: tiantao6 at hisilicon.com (Tian Tao)
Date: Tue, 27 Apr 2021 08:49:35 +0800
Subject: [PATCH v3] tty: serial: samsung_tty: remove set but not used variables
Message-ID: <1619484575-26098-1-git-send-email-tiantao6@hisilicon.com>

The value of 'ret' is not used which reported by svace, so just return
instead of break.

Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
---
v2: s3c24xx_serial_probe function exit than convert ret to some default
value when the attribute "reg-io-width" is not 1 or 4.

v3: Fix word spelling error in commit message.
---
 drivers/tty/serial/samsung_tty.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung_tty.c b/drivers/tty/serial/samsung_tty.c
index d9e4b67..9fbc611 100644
--- a/drivers/tty/serial/samsung_tty.c
+++ b/drivers/tty/serial/samsung_tty.c
@@ -2220,8 +2220,7 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
 			default:
 				dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
 						prop);
-				ret = -EINVAL;
-				break;
+				return -EINVAL;
 			}
 		}
 	}
-- 
2.7.4



From andrew at aj.id.au  Tue Apr 27 02:17:09 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 27 Apr 2021 10:47:09 +0930
Subject: [PATCH] pinctrl: aspeed: Fix minor documentation error
In-Reply-To: <1619353584-8196-1-git-send-email-jrdr.linux@gmail.com>
References: <1619353584-8196-1-git-send-email-jrdr.linux@gmail.com>
Message-ID: <3cb5cc18-fc03-46d7-be3d-3d132b42c82b@www.fastmail.com>



On Sun, 25 Apr 2021, at 21:56, Souptick Joarder wrote:
> Kernel test robot throws below warning ->
> 
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c:2705: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2614: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinctrl-aspeed.c:111: warning: This comment
> starts with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> drivers/pinctrl/aspeed/pinmux-aspeed.c:24: warning: This comment starts
> with '/**', but isn't a kernel-doc comment. Refer
> Documentation/doc-guide/kernel-doc.rst
> 
> Fix minor documentation error.
> 
> Reported-by: kernel test robot <lkp at intel.com>
> Signed-off-by: Souptick Joarder <jrdr.linux at gmail.com>
> Cc: Randy Dunlap <rdunlap at infradead.org>

Acked-by: Andrew Jeffery <andrew at aj.id.au>


From andrew at aj.id.au  Tue Apr 27 03:22:41 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 27 Apr 2021 11:52:41 +0930
Subject: =?UTF-8?Q?Re:_[PATCH]_EDAC/aspeed:_use_proper_format_string_for_printing?=
 =?UTF-8?Q?_resource?=
In-Reply-To: <20210421135500.3518661-1-arnd@kernel.org>
References: <20210421135500.3518661-1-arnd@kernel.org>
Message-ID: <dd4286c6-c856-40c4-b1f8-060f76258d57@www.fastmail.com>



On Wed, 21 Apr 2021, at 23:24, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> On ARMv7, resource_size_t can be 64-bit, which breaks printing
> it as %x:
> 
> drivers/edac/aspeed_edac.c: In function 'init_csrows':
> drivers/edac/aspeed_edac.c:257:28: error: format '%x' expects argument 
> of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 
> 'long long unsigned int'} [-Werror=format=]
>   257 |         dev_dbg(mci->pdev, "dt: /memory node resources: first 
> page r.start=0x%x, resource_size=0x%x, PAGE_SHIFT macro=0x%x\n",
> 
> Use the special %pR format string to pretty-print the entire
> resource instead.
> 
> Fixes: edfc2d73ca45 ("EDAC/aspeed: Add support for AST2400 and AST2600")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/edac/aspeed_edac.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
> index a46da56d6d54..6bd5f8815919 100644
> --- a/drivers/edac/aspeed_edac.c
> +++ b/drivers/edac/aspeed_edac.c
> @@ -254,8 +254,8 @@ static int init_csrows(struct mem_ctl_info *mci)
>  		return rc;
>  	}
>  
> -	dev_dbg(mci->pdev, "dt: /memory node resources: first page 
> r.start=0x%x, resource_size=0x%x, PAGE_SHIFT macro=0x%x\n",
> -		r.start, resource_size(&r), PAGE_SHIFT);
> +	dev_dbg(mci->pdev, "dt: /memory node resources: first page %pR, PAGE_SHIFT macro=0x%x\n",

Could probably drop the "first page " as well, but it's a dev_dbg() and not a big deal.

Reviewed-by: Andrew Jeffery <andrew at aj.id.au>


From lyl2019 at mail.ustc.edu.cn  Tue Apr 27 03:33:15 2021
From: lyl2019 at mail.ustc.edu.cn (Lv Yunlong)
Date: Mon, 26 Apr 2021 19:33:15 -0700
Subject: [PATCH] media:exynos4-is: Fix a use after free in isp_video_release
Message-ID: <20210427023315.4537-1-lyl2019@mail.ustc.edu.cn>

In isp_video_release, file->private_data is freed via
_vb2_fop_release()->v4l2_fh_release(). But the freed
file->private_data is still used in v4l2_fh_is_singular_file()
->v4l2_fh_is_singular(filp->private_data), which is a use
after free bug.

My patch set file->private_data to NULL after _vb2_fop_release()
to avoid the use after free.

Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>
---
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..f414493258ad 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -315,6 +315,7 @@ static int isp_video_release(struct file *file)
 	}
 
 	_vb2_fop_release(file, NULL);
+	filp->private_data = NULL;
 
 	if (v4l2_fh_is_singular_file(file)) {
 		fimc_pipeline_call(&ivc->ve, close);
-- 
2.25.1




From song.bao.hua at hisilicon.com  Tue Apr 27 03:37:58 2021
From: song.bao.hua at hisilicon.com (Barry Song)
Date: Tue, 27 Apr 2021 14:37:58 +1200
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
Message-ID: <20210427023758.4048-1-song.bao.hua@hisilicon.com>

a severe qperf performance decrease was reported in the below use case:
For a hardware with 2 NUMA nodes, node0 has cpu0-31, node1 has cpu32-63.
Ethernet is located in node1.

Run the below commands:
$ taskset -c 32-63 stress -c 32 &
$ qperf 192.168.50.166 tcp_lat
tcp_lat:
	latency = 2.95ms.
Normally the latency should be less than 20us. But in the above test,
latency increased dramatically to 2.95ms.

This is caused by ping-pong of qperf between node0 and node1. Since it
is a sync wake-up and waker's nr_running == 1, WAKE_AFFINE will pull
qperf to node1, but LB will soon migrate qperf back to node0.
Not like a normal sync wake-up coming from a task, the waker in the above
test is an interrupt and nr_running happens to be 1 since stress starts
32 threads on node1 with 32 cpus.

Testing also shows the performance of qperf won't drop if the number
of threads are increased to 64, 96 or larger values:
$ taskset -c 32-63 stress -c 96 &
$ qperf 192.168.50.166 tcp_lat
tcp_lat:
	latency = 14.7us.

Obviously "-c 96" makes "cpu_rq(this_cpu)->nr_running == 1" false in
wake_affine_idle() so WAKE_AFFINE won't pull qperf to node1.

To fix this issue, this patch checks the waker of sync wake-up is a task
but not an interrupt. In this case, the waker will schedule out and give
CPU to wakee.

Reported-by: Yongjia Xie <xieyongjia1 at huawei.com>
Signed-off-by: Barry Song <song.bao.hua at hisilicon.com>
---
 kernel/sched/fair.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6d73bdbb2d40..8ad2d732033d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5829,7 +5829,12 @@ wake_affine_idle(int this_cpu, int prev_cpu, int sync)
 	if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu))
 		return available_idle_cpu(prev_cpu) ? prev_cpu : this_cpu;
 
-	if (sync && cpu_rq(this_cpu)->nr_running == 1)
+	/*
+	 * If this is a sync wake-up and the only running thread is just
+	 * waker, thus, waker is not interrupt, we assume wakee will get
+	 * the cpu of waker soon
+	 */
+	if (sync && cpu_rq(this_cpu)->nr_running == 1 && in_task())
 		return this_cpu;
 
 	if (available_idle_cpu(prev_cpu))
-- 
2.25.1



From wanjiabing at vivo.com  Tue Apr 27 04:30:31 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Tue, 27 Apr 2021 11:30:31 +0800
Subject: [PATCH] firmware: arm_scmi: Remove repeated struct declaration
Message-ID: <20210427033031.4580-1-wanjiabing@vivo.com>

struct scmi_protocol_handle is declared at 34th line.
The declaration here is duplicate. Remove it.

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 drivers/firmware/arm_scmi/notify.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/firmware/arm_scmi/notify.h b/drivers/firmware/arm_scmi/notify.h
index ce0324be6c71..4e9b627edfef 100644
--- a/drivers/firmware/arm_scmi/notify.h
+++ b/drivers/firmware/arm_scmi/notify.h
@@ -79,8 +79,6 @@ struct scmi_protocol_events {
 
 int scmi_notification_init(struct scmi_handle *handle);
 void scmi_notification_exit(struct scmi_handle *handle);
-
-struct scmi_protocol_handle;
 int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
 				  const struct scmi_protocol_handle *ph,
 				  const struct scmi_protocol_events *ee);
-- 
2.25.1



From kever.yang at rock-chips.com  Tue Apr 27 04:45:03 2021
From: kever.yang at rock-chips.com (Kever Yang)
Date: Tue, 27 Apr 2021 11:45:03 +0800
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <3d584cdc-020e-5aae-cae3-59ef45e64a9f@gmail.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
 <3d584cdc-020e-5aae-cae3-59ef45e64a9f@gmail.com>
Message-ID: <c2e96d99-3af5-3f22-78de-f6eff18b9c24@rock-chips.com>

Hi Johan, Heiko,

On 2021/4/26 ??8:16, Johan Jonker wrote:
> ===
>
> compatible = "rockchip,rk3568";
> Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
> of board list ???
> Please advise.
This rockchip.yaml is now describe boards without any sort, it would be 
better to refactor and sort in two level:
- soc level
- board level base on the same soc.

This will need a separate patch to do the clean up, maybe goes after the 
rk3568.dtsi?


Thanks,
- Kever




From leo.yan at linaro.org  Tue Apr 27 04:45:31 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Tue, 27 Apr 2021 11:45:31 +0800
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync
 buffer.
In-Reply-To: <bd9de3ab-14f7-2659-0dc8-619bca0f52d7@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-2-daniel.kiss@arm.com>
 <bd9de3ab-14f7-2659-0dc8-619bca0f52d7@arm.com>
Message-ID: <20210427034531.GA328795@leoy-ThinkPad-X240s>

On Mon, Apr 26, 2021 at 11:40:44AM +0100, Suzuki Kuruppassery Poulose wrote:

[...]

> > @@ -1442,7 +1442,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> >   {
> >   	long bytes;
> >   	long pg_idx, pg_offset;
> > -	unsigned long head = etr_perf->head;
> > +	unsigned long head;
> >   	char **dst_pages, *src_buf;
> >   	struct etr_buf *etr_buf = etr_perf->etr_buf;
> > @@ -1465,7 +1465,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> >   		bytes = tmc_etr_buf_get_data(etr_buf, src_offset, to_copy,
> >   					     &src_buf);
> >   		if (WARN_ON_ONCE(bytes <= 0))
> > -			break;
> > +			return;
> >   		bytes = min(bytes, (long)(PAGE_SIZE - pg_offset));
> >   		memcpy(dst_pages[pg_idx] + pg_offset, src_buf, bytes);
> > @@ -1483,6 +1483,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> >   		/* Move source pointers */
> >   		src_offset += bytes;
> >   	}
> > +	etr_perf->head = (pg_idx << PAGE_SHIFT) + pg_offset;
> 
> 
> Looking at this patch, I feel the driver is doing a couple wrong things
> already.
> 
> 1) We initialise etr_perf->head every time the ETR enable is called,
> irrespective of whether we actually try to enable the Hardware. e.g,
> 
> etm_0 on -> .. -> enable_etr :
> etr_perf->head = <head of the handle_0>
>   enable_hw()
> 
> emt_1 on -> ... -> enable_etr:
>   etr_perf->head = <head of the handle_1>
>   already_enabled, skip enable_hw()
> 
> etm_2 on -> ... -> enable_etr:
>   etr_perf->head = <head of the handle_2>
>   already_enable, skip enable_hw()...
> 
> 
> This doesn't look correct as we don't know which handle is going to get the
> data. This looks pointless.

I'd like to convert mapping into below diagram (for system wide trace):

  CPU0: AUX RB (perf_output_handle_0) -> etr_perf ->  +---------+
  CPU1: AUX RB (perf_output_handle_1) -> etr_perf ->  | etr_buf |
  CPU2: AUX RB (perf_output_handle_2) -> etr_perf ->  |         |
  CPU3: AUX RB (perf_output_handle_3) -> etr_perf ->  +---------+

Simply to say, there have two layers for controlling ring buffer, one
layer is for perf AUX ring buffer, it mainly uses the structure
perf_output_handle to manage the ring buffer.  And in the ETR driver,
it uses structure etr_perf to manage the header pointer for copying
data into ETR buffer (tagged as "etr_buf").

ETR buffer is the single one, but the structures "perf_output_handle"
and "etr_perf" are per CPU.  We have multiple copies for the headers and
tails to manage a single buffer, but the problem is these multiple
copies have not been synced with each other.

> 2) Even more problematic is where we copy the AUX buffer content to.
> As mentioned above, we don't know which handle is going to be the last
> one to consume and we have a "etr_perf->head" that came from one of the
> handles and the "pages" that came from the first handle which created a
> etr_perf buffer. In sync_perf_buffer() we copy the hardware buffers to
> the "pages" (say of handle_0) with "etr_perf->head" (which could be from
> any other handle, say handle_2) and then we could return the number of bytes
> copied, which then is used to update the last handle (could be say
> handle_3), where there is no actual data copied.
> 
> To fix all of these issues, we must
> 1) Stop using etr_perf->head, and instead use the handle->head where we are
> called update_buffer on.
> 
> 2) Keep track of the "pages" that belong to a given "handle" and then use
> those pages to copy the data to the current handle we are called to update
> the buffer on.

The "pages" are only allocated once, even they are attached to multiple
handles.  I think the right way is to use the single structure
"etr_perf" and single "perf_output_handle" to manage the "pages", IOW,
if there have single buffer, then we just use one copy of header and
tail to manage it.

The difficult thing is how to use the single one "perf_output_handle"
to manage the AUX ring buffer and notify to user space.  I am
wandering if we can only use CPU0's perf_output_handle to manage the
AUX ring buffer, if any other CPUs read out the data, they always use
CPU0's perf_output_handle.

Thanks,
Leo


From andrew at aj.id.au  Tue Apr 27 04:59:22 2021
From: andrew at aj.id.au (Andrew Jeffery)
Date: Tue, 27 Apr 2021 13:29:22 +0930
Subject: [PATCH] ARM: dts: aspeed: update e3c246d4i vuart properties
In-Reply-To: <20210416075113.18047-1-zev@bewilderbeest.net>
References: <20210416075113.18047-1-zev@bewilderbeest.net>
Message-ID: <201d989f-882f-4b73-ab06-5085f99301ed@www.fastmail.com>



On Fri, 16 Apr 2021, at 17:21, Zev Weiss wrote:
> This device-tree was merged with a provisional vuart IRQ-polarity
> property that was still under review and ended up taking a somewhat
> different form.  This patch updates it to match the final form of the
> new vuart properties, which additionally allow specifying the SIRQ
> number and LPC address.
> 
> Signed-off-by: Zev Weiss <zev at bewilderbeest.net>

Reviewed-by: Andrew Jeffery <andrew at aj.id.au>


From lkp at intel.com  Tue Apr 27 05:17:34 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 27 Apr 2021 12:17:34 +0800
Subject: [xlnx:master 11243/12163] spi-zynqmp-gqspi.c:undefined reference to
 `update_stripe'
Message-ID: <202104271226.uxkqQC2K-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   931271170915c905acca7c82114b9fea8598c1fe
commit: ffc5cb8494ba2abe218134584b22fd874b71d504 [11243/12163] spi: Update ZynqMP and Versal QSPI controller driver
config: i386-randconfig-m021-20210426 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/ffc5cb8494ba2abe218134584b22fd874b71d504
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout ffc5cb8494ba2abe218134584b22fd874b71d504
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   ld: drivers/spi/spi-zynqmp-gqspi.o: in function `zynqmp_qspi_exec_op':
>> spi-zynqmp-gqspi.c:(.text.unlikely+0x579): undefined reference to `update_stripe'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 41086 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210427/cfa00f75/attachment-0001.gz>

From efault at gmx.de  Tue Apr 27 05:21:30 2021
From: efault at gmx.de (Mike Galbraith)
Date: Tue, 27 Apr 2021 06:21:30 +0200
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
In-Reply-To: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
References: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
Message-ID: <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>

On Tue, 2021-04-27 at 14:37 +1200, Barry Song wrote:
>
> To fix this issue, this patch checks the waker of sync wake-up is a task
> but not an interrupt. In this case, the waker will schedule out and give
> CPU to wakee.

That rash "the waker will schedule out" assumption, ie this really
really is a synchronous wakeup, may be true in your particular case,
but the sync hint is so overused as to be fairly meaningless. We've
squabbled with it repeatedly over the years because of that.  It really
should either become more of a communication of intent than it
currently is, or just go away.

I'd argue for go away, simply because there is no way for the kernel to
know that there isn't more work directly behind any particular wakeup.

Take a pipe, does shoving some bits through a pipe mean you have no
further use of your CPU?  IFF you're doing nothing but playing ping-
pong, sure it does, but how many real proggies have zero overlap among
its threads of execution?  The mere notion of threaded apps having no
overlap *to be converted to throughput* is dainbramaged, which should
be the death knell of the sync wakeup hint.  Threaded apps can't do
stuff like, oh, networking, which uses the sync hint heavily, without
at least to some extent defeating the purpose of threading if we were
to take the hint seriously.  Heck, just look at the beauty (gak) of
wake_wide().  It was born specifically to combat the pure-evil side of
the sync wakeup hint.

Bah, 'nuff "Danger Will Robinson, that thing will *eat you*!!" ;-)

	-Mike



From song.bao.hua at hisilicon.com  Tue Apr 27 05:44:32 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Tue, 27 Apr 2021 04:44:32 +0000
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
In-Reply-To: <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
References: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
 <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
Message-ID: <d057eb13ec4e4643b314dd1652ffa9d4@hisilicon.com>



> -----Original Message-----
> From: Mike Galbraith [mailto:efault at gmx.de]
> Sent: Tuesday, April 27, 2021 4:22 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> vincent.guittot at linaro.org; mingo at redhat.com; peterz at infradead.org;
> dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> mgorman at suse.de
> Cc: valentin.schneider at arm.com; juri.lelli at redhat.com; bristot at redhat.com;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; xuwei (O)
> <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; wanghuiqiang
> <wanghuiqiang at huawei.com>; xieyongjia (A) <xieyongjia1 at huawei.com>
> Subject: Re: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
> wake-up is interrupt
> 
> On Tue, 2021-04-27 at 14:37 +1200, Barry Song wrote:
> >
> > To fix this issue, this patch checks the waker of sync wake-up is a task
> > but not an interrupt. In this case, the waker will schedule out and give
> > CPU to wakee.
> 
> That rash "the waker will schedule out" assumption, ie this really
> really is a synchronous wakeup, may be true in your particular case,

Hi Mike,

For my particular case, sync hint is used by interrupt but not task.
so "the waker will schedule out" is false because the existing task
is relevant at all.

Here the description "the waker will schedule out" is just copying
the general idea of sync wake-up though the real code might overuse
this hint.

> but the sync hint is so overused as to be fairly meaningless. We've
> squabbled with it repeatedly over the years because of that.  It really
> should either become more of a communication of intent than it
> currently is, or just go away.

I agree sync hint might have been overused by other kernel subsystem.
But this patch will at least fix a case: sync waker is interrupt,
in this case, the existing task has nothing to do with waker and wakee,
so this case should be excluded from wake_affine_idle().

> 
> I'd argue for go away, simply because there is no way for the kernel to
> know that there isn't more work directly behind any particular wakeup.

To some extent, "go way" might be a good choice. But this is a more
aggressive action. For those cases waker will really scheduler out,
wakee won't be able to take the advantage of getting the idle cpu
of waker.

> 
> Take a pipe, does shoving some bits through a pipe mean you have no
> further use of your CPU?  IFF you're doing nothing but playing ping-
> pong, sure it does, but how many real proggies have zero overlap among
> its threads of execution?  The mere notion of threaded apps having no
> overlap *to be converted to throughput* is dainbramaged, which should
> be the death knell of the sync wakeup hint.  Threaded apps can't do
> stuff like, oh, networking, which uses the sync hint heavily, without
> at least to some extent defeating the purpose of threading if we were
> to take the hint seriously.  Heck, just look at the beauty (gak) of
> wake_wide().  It was born specifically to combat the pure-evil side of
> the sync wakeup hint.

As above, removing the code of migrating wakee to the cpu of sync waker
could be an option, but needs more investigations.

> 
> Bah, 'nuff "Danger Will Robinson, that thing will *eat you*!!" ;-)
> 
> 	-Mike

Thanks
Barry


From qiangqing.zhang at nxp.com  Tue Apr 27 05:48:42 2021
From: qiangqing.zhang at nxp.com (Joakim Zhang)
Date: Tue, 27 Apr 2021 04:48:42 +0000
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
Message-ID: <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>


> -----Original Message-----
> From: Oleksij Rempel <o.rempel at pengutronix.de>
> Sent: 2021?4?23? 12:37
> To: Joakim Zhang <qiangqing.zhang at nxp.com>
> Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian Fainelli
> <f.fainelli at gmail.com>; Heiner Kallweit <hkallweit1 at gmail.com>; Fugang
> Duan <fugang.duan at nxp.com>; kernel at pengutronix.de;
> netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
> Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>; Russell
> King <linux at armlinux.org.uk>; Philippe Schenker
> <philippe.schenker at toradex.com>
> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support
> 
> Hi Joakim,
> 
> On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
> >
> > Hi Oleksij,
> >
> > I look both stmmac selftest code and this patch set. For stmmac, if PHY
> doesn't support loopback, it will fallthrough to MAC loopback.
> > You provide this generic net selftest support based on PHY loopback, I have a
> question, is it possible to extend it also support MAC loopback later?
> 
> Yes. If you have interest and time to implement it, please do.
> It should be some kind of generic callback as phy_loopback() and if PHY and
> MAC loopbacks are supported we need to tests both variants.
Hi Oleksij,

Yes, I can try to implement it when I am free, but I still have some questions:
1. Where we place the generic function? Such as mac_loopback().
2. MAC is different from PHY, need program different registers to enable loopback on different SoCs, that means we need get MAC private data from "struct net_device".
So we need a callback for MAC drivers, where we extend this callback? Could be "struct net_device_ops"? Such as ndo_set_loopback?

Best Regards,
Joakim Zhang
> Best regards,
> Oleksij
> 
> > > -----Original Message-----
> > > From: Oleksij Rempel <o.rempel at pengutronix.de>
> > > Sent: 2021?4?19? 21:01
> > > To: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> > > <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian
> > > Fainelli <f.fainelli at gmail.com>; Heiner Kallweit
> > > <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>
> > > Cc: Oleksij Rempel <o.rempel at pengutronix.de>; kernel at pengutronix.de;
> > > netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>;
> > > Fabio Estevam <festevam at gmail.com>; David Jander
> > > <david at protonic.nl>; Russell King <linux at armlinux.org.uk>; Philippe
> > > Schenker <philippe.schenker at toradex.com>
> > > Subject: [PATCH net-next v3 0/6] provide generic net selftest
> > > support
> > >
> > > changes v3:
> > > - make more granular tests
> > > - enable loopback for all PHYs by default
> > > - fix allmodconfig build errors
> > > - poll for link status update after switching to the loopback mode
> > >
> > > changes v2:
> > > - make generic selftests available for all networking devices.
> > > - make use of net_selftest* on FEC, ag71xx and all DSA switches.
> > > - add loopback support on more PHYs.
> > >
> > > This patch set provides diagnostic capabilities for some iMX, ag71xx
> > > or any DSA based devices. For proper functionality, PHY loopback support is
> needed.
> > > So far there is only initial infrastructure with basic tests.
> > >
> > > Oleksij Rempel (6):
> > >   net: phy: execute genphy_loopback() per default on all PHYs
> > >   net: phy: genphy_loopback: add link speed configuration
> > >   net: add generic selftest support
> > >   net: fec: make use of generic NET_SELFTESTS library
> > >   net: ag71xx: make use of generic NET_SELFTESTS library
> > >   net: dsa: enable selftest support for all switches by default
> > >
> > >  drivers/net/ethernet/atheros/Kconfig      |   1 +
> > >  drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
> > >  drivers/net/ethernet/freescale/Kconfig    |   1 +
> > >  drivers/net/ethernet/freescale/fec_main.c |   7 +
> > >  drivers/net/phy/phy.c                     |   3 +-
> > >  drivers/net/phy/phy_device.c              |  35 +-
> > >  include/linux/phy.h                       |   1 +
> > >  include/net/dsa.h                         |   2 +
> > >  include/net/selftests.h                   |  12 +
> > >  net/Kconfig                               |   4 +
> > >  net/core/Makefile                         |   1 +
> > >  net/core/selftests.c                      | 400
> > > ++++++++++++++++++++++
> > >  net/dsa/Kconfig                           |   1 +
> > >  net/dsa/slave.c                           |  21 ++
> > >  14 files changed, 500 insertions(+), 9 deletions(-)  create mode
> > > 100644 include/net/selftests.h  create mode 100644
> > > net/core/selftests.c
> > >
> > > --
> > > 2.29.2
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&amp;data=04%7
> C0
> >
> 1%7Cqiangqing.zhang%40nxp.com%7C8796bf53e46b4b1be92b08d9061186f9
> %7C686
> >
> ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637547494614753358%7CU
> nknown%7
> >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXV
> >
> CI6Mn0%3D%7C1000&amp;sdata=x%2BUFB%2B1Xp0zbR1mG5HDGvqBUvKhX
> VJn337T%2BB
> > D7cO6g%3D&amp;reserved=0
> 
> --
> Pengutronix e.K.                           |
> |
> Steuerwalder Str. 21                       |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
> ngutronix.de%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C87
> 96bf53e46b4b1be92b08d9061186f9%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637547494614753358%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> 00&amp;sdata=K2dsGVxEXv%2FtC7p0l4TFlLlaqzzTa6ktrbSdcCJ10J0%3D&amp;
> reserved=0  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

From hsinyi at chromium.org  Tue Apr 27 05:49:46 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 12:49:46 +0800
Subject: [PATCH v3 1/3] gpu: drm: separate panel orientation property creating
 and value setting
Message-ID: <20210427044948.12596-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
v3:
create property in dsi driver and set value in panel. 

v2:
create property in connector init
https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsinyi at chromium.org/

v1:
set panel orientation in dsi driver
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
---
 drivers/gpu/drm/drm_connector.c | 58 +++++++++++++++++++++++++--------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..cda83314d7ad 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will create one first.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2206,18 +2206,16 @@ int drm_connector_set_panel_orientation(
 
 	prop = dev->mode_config.panel_orientation_property;
 	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
+		int ret;
 
-		dev->mode_config.panel_orientation_property = prop;
+		ret = drm_connector_init_panel_orientation_property(connector);
+		if (ret)
+			return ret;
+		prop = dev->mode_config.panel_orientation_property;
 	}
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2225,7 +2223,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk -
  *	set the connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2252,6 +2250,40 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..4396c1c4a5db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 05:49:47 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 12:49:47 +0800
Subject: [PATCH v3 2/3] drm/mediatek: init panel orientation property
In-Reply-To: <20210427044948.12596-1-hsinyi@chromium.org>
References: <20210427044948.12596-1-hsinyi@chromium.org>
Message-ID: <20210427044948.12596-2-hsinyi@chromium.org>

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..0bd27872f2a4 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -964,6 +964,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+	drm_connector_init_panel_orientation_property(dsi->connector);
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 05:49:48 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 12:49:48 +0800
Subject: [PATCH v3 3/3] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210427044948.12596-1-hsinyi@chromium.org>
References: <20210427044948.12596-1-hsinyi@chromium.org>
Message-ID: <20210427044948.12596-3-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 05:54:47 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 12:54:47 +0800
Subject: [PATCH v2 1/2] gpu: drm: init set panel orientation property
 earlier
In-Reply-To: <YIbdPqolop6cBnYH@intel.com>
References: <20210426051848.2600890-1-hsinyi@chromium.org>
 <YIbdPqolop6cBnYH@intel.com>
Message-ID: <CAJMQK-hKew8RyEJ=e3upUCC-qFaeZE=jLiJdOpv5gw6izwdeCQ@mail.gmail.com>

On Mon, Apr 26, 2021 at 11:33 PM Ville Syrj?l?
<ville.syrjala at linux.intel.com> wrote:
>
> On Mon, Apr 26, 2021 at 01:18:47PM +0800, Hsin-Yi Wang wrote:
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> > drm_connector_set_panel_orientation() is first called after
> > drm_dev_register(), it will fail several checks and results in following
> > warning.
> >
> > Create panel orientation property in drm_connector_init()
> > and set default value to UNKNOWN. Let the panel set the real value
> > later.
> >
> > [    4.480976] ------------[ cut here ]------------
> > [    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
> > <snip>
> > [    4.609772] Call trace:
> > [    4.612208]  __drm_mode_object_add+0xb4/0xbc
> > [    4.616466]  drm_mode_object_add+0x20/0x2c
> > [    4.620552]  drm_property_create+0xdc/0x174
> > [    4.624723]  drm_property_create_enum+0x34/0x98
> > [    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
> > [    4.634716]  boe_panel_get_modes+0x88/0xd8
> > [    4.638802]  drm_panel_get_modes+0x2c/0x48
> > [    4.642887]  panel_bridge_get_modes+0x1c/0x28
> > [    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.658266]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.662699]  drm_ioctl_kernel+0xac/0x128
> > [    4.666611]  drm_ioctl+0x268/0x410
> > [    4.670002]  drm_compat_ioctl+0xdc/0xf0
> > [    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.678436]  el0_svc_common+0xf4/0x1c0
> > [    4.682174]  do_el0_svc_compat+0x28/0x3c
> > [    4.686088]  el0_svc_compat+0x10/0x1c
> > [    4.689738]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.694171]  el0_sync_compat+0x178/0x180
> > [    4.698082] ---[ end trace b4f2db9d9c88610b ]---
> > [    4.702721] ------------[ cut here ]------------
> > [    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
> > <snip>
> > [    4.833830] Call trace:
> > [    4.836266]  drm_object_attach_property+0x48/0xb8
> > [    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
> > [    4.846432]  boe_panel_get_modes+0x88/0xd8
> > [    4.850516]  drm_panel_get_modes+0x2c/0x48
> > [    4.854600]  panel_bridge_get_modes+0x1c/0x28
> > [    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
> > [    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
> > [    4.869978]  drm_mode_getconnector+0x1b4/0x45c
> > [    4.874410]  drm_ioctl_kernel+0xac/0x128
> > [    4.878320]  drm_ioctl+0x268/0x410
> > [    4.881711]  drm_compat_ioctl+0xdc/0xf0
> > [    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
> > [    4.890142]  el0_svc_common+0xf4/0x1c0
> > [    4.893879]  do_el0_svc_compat+0x28/0x3c
> > [    4.897791]  el0_svc_compat+0x10/0x1c
> > [    4.901441]  el0_sync_compat_handler+0xa8/0xcc
> > [    4.905873]  el0_sync_compat+0x178/0x180
> > [    4.909783] ---[ end trace b4f2db9d9c88610c ]---
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> > ---
> > v1:
> > https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
> > ---
> >  drivers/gpu/drm/drm_connector.c | 28 +++++++++++++++-------------
> >  1 file changed, 15 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 7631f76e7f34..a1acb4af0ef4 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -303,6 +303,10 @@ int drm_connector_init(struct drm_device *dev,
> >                                  config->tile_property,
> >                                  0);
> >
> > +     drm_object_attach_property(&connector->base,
> > +                                config->panel_orientation_property,
> > +                                DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
> > +
>
> A bit silly to add this to every connector. I think you should just
> fix the driver/bridge stuff to set up the orientaion earlier.
>

v3 is sent: https://patchwork.kernel.org/project/linux-mediatek/patch/20210427044948.12596-1-hsinyi at chromium.org/
Create a function to init this property so that drivers can call this
after connector init. Panel can set the value later.

> >       if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> >               drm_object_attach_property(&connector->base, config->prop_crtc_id, 0);
> >       }
> > @@ -1210,7 +1214,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> >   *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> >   *   coordinates, so if userspace rotates the picture to adjust for
> >   *   the orientation it must also apply the same transformation to the
> > - *   touchscreen input coordinates. This property is initialized by calling
> > + *   touchscreen input coordinates. This property value is set by calling
> >   *   drm_connector_set_panel_orientation() or
> >   *   drm_connector_set_panel_orientation_with_quirk()
> >   *
> > @@ -1298,6 +1302,14 @@ int drm_connector_create_standard_properties(struct drm_device *dev)
> >               return -ENOMEM;
> >       dev->mode_config.hdr_output_metadata_property = prop;
> >
> > +     prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > +                                     "panel orientation",
> > +                                     drm_panel_orientation_enum_list,
> > +                                     ARRAY_SIZE(drm_panel_orientation_enum_list));
> > +     if (!prop)
> > +             return -ENOMEM;
> > +     dev->mode_config.panel_orientation_property = prop;
> > +
> >       return 0;
> >  }
> >
> > @@ -2205,19 +2217,9 @@ int drm_connector_set_panel_orientation(
> >       info->panel_orientation = panel_orientation;
> >
> >       prop = dev->mode_config.panel_orientation_property;
> > -     if (!prop) {
> > -             prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> > -                             "panel orientation",
> > -                             drm_panel_orientation_enum_list,
> > -                             ARRAY_SIZE(drm_panel_orientation_enum_list));
> > -             if (!prop)
> > -                     return -ENOMEM;
> > -
> > -             dev->mode_config.panel_orientation_property = prop;
> > -     }
> >
> > -     drm_object_attach_property(&connector->base, prop,
> > -                                info->panel_orientation);
> > +     drm_object_property_set_value(&connector->base, prop,
> > +                                   info->panel_orientation);
> >       return 0;
> >  }
> >  EXPORT_SYMBOL(drm_connector_set_panel_orientation);
> > --
> > 2.31.1.498.g6c1eba8ee3d-goog
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrj?l?
> Intel


From lkp at intel.com  Tue Apr 27 06:07:37 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 27 Apr 2021 13:07:37 +0800
Subject: [PATCH] media:exynos4-is: Fix a use after free in
 isp_video_release
In-Reply-To: <20210427023315.4537-1-lyl2019@mail.ustc.edu.cn>
References: <20210427023315.4537-1-lyl2019@mail.ustc.edu.cn>
Message-ID: <202104271335.gNNaJrxh-lkp@intel.com>

Hi Lv,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v5.12 next-20210426]
[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]

url:    https://github.com/0day-ci/linux/commits/Lv-Yunlong/media-exynos4-is-Fix-a-use-after-free-in-isp_video_release/20210427-103518
base:   git://linuxtv.org/media_tree.git master
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/be22db53410320e33e9e471a8a15f14904b5e801
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Lv-Yunlong/media-exynos4-is-Fix-a-use-after-free-in-isp_video_release/20210427-103518
        git checkout be22db53410320e33e9e471a8a15f14904b5e801
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/build_bug.h:5,
                    from include/linux/bits.h:22,
                    from include/linux/bitops.h:6,
                    from drivers/media/platform/exynos4-is/fimc-isp-video.c:14:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of pointer with null pointer [-Wextra]
     174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory)
         |                                                 ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
      78 | # define unlikely(x) __builtin_expect(!!(x), 0)
         |                                          ^
   include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
     137 |  BUG_ON(!virt_addr_valid(buf));
         |  ^~~~~~
   include/linux/scatterlist.h:137:10: note: in expansion of macro 'virt_addr_valid'
     137 |  BUG_ON(!virt_addr_valid(buf));
         |          ^~~~~~~~~~~~~~~
   drivers/media/platform/exynos4-is/fimc-isp-video.c: In function 'isp_video_release':
>> drivers/media/platform/exynos4-is/fimc-isp-video.c:318:2: error: 'filp' undeclared (first use in this function); did you mean 'file'?
     318 |  filp->private_data = NULL;
         |  ^~~~
         |  file
   drivers/media/platform/exynos4-is/fimc-isp-video.c:318:2: note: each undeclared identifier is reported only once for each function it appears in


vim +318 drivers/media/platform/exynos4-is/fimc-isp-video.c

   302	
   303	static int isp_video_release(struct file *file)
   304	{
   305		struct fimc_isp *isp = video_drvdata(file);
   306		struct fimc_is_video *ivc = &isp->video_capture;
   307		struct media_entity *entity = &ivc->ve.vdev.entity;
   308		struct media_device *mdev = entity->graph_obj.mdev;
   309	
   310		mutex_lock(&isp->video_lock);
   311	
   312		if (v4l2_fh_is_singular_file(file) && ivc->streaming) {
   313			media_pipeline_stop(entity);
   314			ivc->streaming = 0;
   315		}
   316	
   317		_vb2_fop_release(file, NULL);
 > 318		filp->private_data = NULL;
   319	
   320		if (v4l2_fh_is_singular_file(file)) {
   321			fimc_pipeline_call(&ivc->ve, close);
   322	
   323			mutex_lock(&mdev->graph_mutex);
   324			entity->use_count--;
   325			mutex_unlock(&mdev->graph_mutex);
   326		}
   327	
   328		pm_runtime_put(&isp->pdev->dev);
   329		mutex_unlock(&isp->video_lock);
   330	
   331		return 0;
   332	}
   333	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 59843 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210427/c6ef1ee1/attachment-0001.gz>

From hsinyi at chromium.org  Tue Apr 27 06:36:12 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:12 +0800
Subject: [PATCH v20 0/5] add power control in i2c
Message-ID: <20210427053617.27972-1-hsinyi@chromium.org>

Although in the most platforms, the power of eeprom
and i2c are alway on, some platforms disable the
eeprom and i2c power in order to meet low power request.

This patch add the pm_runtime ops to control power to
support all platforms.

Changes since v19:
 - resend v19 with fix tag added.

Changes since v18:
 - Fix a function name conflict with drivers/gpu/drm/i915/selftests/i915_gem.c

Changes since v17:
 - Add a patch to fix unbalanced regulator disabling.
 - Add dts patch.

Changes since v16:
 - request regulator in device instead of in the core.
 - control regulator only if it's provided.

Changes since v15:
 - Squash the fix[1] for v15.
[1] https://patchwork.ozlabs.org/project/linux-i2c/patch/20200522101327.13456-1-m.szyprowski at samsung.com/

Changes since v14:
 - change the return value in normal condition
 - access the variable after NULL pointer checking
 - add ack tag

Changes since v13:
 - fixup some logic error

Changes since v12:
 - rebase onto v5.7-rc1
 - change the property description in binding

Changes since v11:
 - use suspend_late/resume_early instead of suspend/resume
 - rebase onto v5.6-rc1

Changes since v10:
 - fixup some worng codes

Changes since v9:
 - fixup build error
 - remove redundant code

Changes since v8:
 - fixup some wrong code
 - remove redundant message

[... snip ...]


Bibby Hsieh (1):
  i2c: core: support bus regulator controlling in adapter

Hsin-Yi Wang (4):
  dt-binding: i2c: mt65xx: add vbus-supply property
  i2c: mediatek: mt65xx: add optional vbus-supply
  misc: eeprom: at24: check suspend status before disable regulator
  arm64: dts: mt8183: add supply name for eeprom

 .../devicetree/bindings/i2c/i2c-mt65xx.txt    |  1 +
 .../dts/mediatek/mt8183-kukui-kakadu.dtsi     |  4 +
 .../dts/mediatek/mt8183-kukui-kodama.dtsi     |  4 +
 .../boot/dts/mediatek/mt8183-kukui-krane.dtsi |  4 +
 drivers/i2c/busses/i2c-mt65xx.c               |  7 ++
 drivers/i2c/i2c-core-base.c                   | 88 +++++++++++++++++++
 drivers/misc/eeprom/at24.c                    |  6 +-
 include/linux/i2c.h                           |  2 +
 8 files changed, 114 insertions(+), 2 deletions(-)

-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 06:36:13 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:13 +0800
Subject: [PATCH v20 1/5] i2c: core: support bus regulator controlling in
 adapter
In-Reply-To: <20210427053617.27972-1-hsinyi@chromium.org>
References: <20210427053617.27972-1-hsinyi@chromium.org>
Message-ID: <20210427053617.27972-2-hsinyi@chromium.org>

From: Bibby Hsieh <bibby.hsieh at mediatek.com>

Although in the most platforms, the bus power of i2c
are alway on, some platforms disable the i2c bus power
in order to meet low power request.

We can control bulk regulator if it is provided in i2c
adapter device.

Signed-off-by: Bibby Hsieh <bibby.hsieh at mediatek.com>
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/i2c-core-base.c | 88 +++++++++++++++++++++++++++++++++++++
 include/linux/i2c.h         |  2 +
 2 files changed, 90 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 24c8f11bac73..c34920f30c5a 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -461,12 +461,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
 static int i2c_device_probe(struct device *dev)
 {
 	struct i2c_client	*client = i2c_verify_client(dev);
+	struct i2c_adapter	*adap;
 	struct i2c_driver	*driver;
 	int status;
 
 	if (!client)
 		return 0;
 
+	adap = client->adapter;
 	client->irq = client->init_irq;
 
 	if (!client->irq) {
@@ -532,6 +534,14 @@ static int i2c_device_probe(struct device *dev)
 
 	dev_dbg(dev, "probe\n");
 
+	if (adap->bus_regulator) {
+		status = regulator_enable(adap->bus_regulator);
+		if (status < 0) {
+			dev_err(&adap->dev, "Failed to enable bus regulator\n");
+			goto err_clear_wakeup_irq;
+		}
+	}
+
 	status = of_clk_set_defaults(dev->of_node, false);
 	if (status < 0)
 		goto err_clear_wakeup_irq;
@@ -589,8 +599,10 @@ static int i2c_device_probe(struct device *dev)
 static int i2c_device_remove(struct device *dev)
 {
 	struct i2c_client	*client = to_i2c_client(dev);
+	struct i2c_adapter      *adap;
 	struct i2c_driver	*driver;
 
+	adap = client->adapter;
 	driver = to_i2c_driver(dev->driver);
 	if (driver->remove) {
 		int status;
@@ -605,6 +617,8 @@ static int i2c_device_remove(struct device *dev)
 	devres_release_group(&client->dev, client->devres_group_id);
 
 	dev_pm_domain_detach(&client->dev, true);
+	if (!pm_runtime_status_suspended(&client->dev) && adap->bus_regulator)
+		regulator_disable(adap->bus_regulator);
 
 	dev_pm_clear_wake_irq(&client->dev);
 	device_init_wakeup(&client->dev, false);
@@ -617,6 +631,79 @@ static int i2c_device_remove(struct device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int i2c_resume_early(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	if (!pm_runtime_status_suspended(&client->dev)) {
+		err = regulator_enable(client->adapter->bus_regulator);
+		if (err)
+			return err;
+	}
+
+	return pm_generic_resume_early(&client->dev);
+}
+
+static int i2c_suspend_late(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_suspend_late(&client->dev);
+	if (err)
+		return err;
+
+	if (!pm_runtime_status_suspended(&client->dev))
+		return regulator_disable(client->adapter->bus_regulator);
+
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_PM
+static int i2c_runtime_resume(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = regulator_enable(client->adapter->bus_regulator);
+	if (err)
+		return err;
+	return pm_generic_runtime_resume(&client->dev);
+}
+
+static int i2c_runtime_suspend(struct device *dev)
+{
+	struct i2c_client *client = i2c_verify_client(dev);
+	int err;
+
+	if (!client || !client->adapter->bus_regulator)
+		return 0;
+
+	err = pm_generic_runtime_suspend(&client->dev);
+	if (err)
+		return err;
+
+	return regulator_disable(client->adapter->bus_regulator);
+}
+#endif
+
+static const struct dev_pm_ops i2c_device_pm = {
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(i2c_suspend_late, i2c_resume_early)
+	SET_RUNTIME_PM_OPS(i2c_runtime_suspend, i2c_runtime_resume, NULL)
+};
+
 static void i2c_device_shutdown(struct device *dev)
 {
 	struct i2c_client *client = i2c_verify_client(dev);
@@ -674,6 +761,7 @@ struct bus_type i2c_bus_type = {
 	.probe		= i2c_device_probe,
 	.remove		= i2c_device_remove,
 	.shutdown	= i2c_device_shutdown,
+	.pm		= &i2c_device_pm,
 };
 EXPORT_SYMBOL_GPL(i2c_bus_type);
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e8f2ac8c9c3d..953a4eecb88f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -15,6 +15,7 @@
 #include <linux/device.h>	/* for struct device */
 #include <linux/sched.h>	/* for completion */
 #include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
 #include <linux/rtmutex.h>
 #include <linux/irqdomain.h>		/* for Host Notify IRQ */
 #include <linux/of.h>		/* for struct device_node */
@@ -729,6 +730,7 @@ struct i2c_adapter {
 	const struct i2c_adapter_quirks *quirks;
 
 	struct irq_domain *host_notify_domain;
+	struct regulator *bus_regulator;
 };
 #define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 06:36:14 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:14 +0800
Subject: [PATCH v20 2/5] dt-binding: i2c: mt65xx: add vbus-supply property
In-Reply-To: <20210427053617.27972-1-hsinyi@chromium.org>
References: <20210427053617.27972-1-hsinyi@chromium.org>
Message-ID: <20210427053617.27972-3-hsinyi@chromium.org>

Add vbus-supply property for mt65xx. The regulator can be passed into
core and turned off during suspend/sleep to reduce power consumption.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
index 7f0194fdd0cc..2c45647e9f0b 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
@@ -32,6 +32,7 @@ Optional properties:
   - mediatek,have-pmic: platform can control i2c form special pmic side.
     Only mt6589 and mt8135 support this feature.
   - mediatek,use-push-pull: IO config use push-pull mode.
+  - vbus-supply: phandle to the regulator that provides power to SCL/SDA.
 
 Example:
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 06:36:16 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:16 +0800
Subject: [PATCH v20 4/5] misc: eeprom: at24: check suspend status before
 disable regulator
In-Reply-To: <20210427053617.27972-1-hsinyi@chromium.org>
References: <20210427053617.27972-1-hsinyi@chromium.org>
Message-ID: <20210427053617.27972-5-hsinyi@chromium.org>

cd5676db0574 ("misc: eeprom: at24: support pm_runtime control") disables
regulator in runtime suspend. If runtime suspend is called before
regulator disable, it will results in regulator unbalanced disabling.

Fixes: cd5676db0574 ("misc: eeprom: at24: support pm_runtime control")
Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
Acked-by: Bartosz Golaszewski <bgolaszewski at baylibre.com>
---
 drivers/misc/eeprom/at24.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 926408b41270..7a6f01ace78a 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -763,7 +763,8 @@ static int at24_probe(struct i2c_client *client)
 	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
 	if (IS_ERR(at24->nvmem)) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return PTR_ERR(at24->nvmem);
 	}
 
@@ -774,7 +775,8 @@ static int at24_probe(struct i2c_client *client)
 	err = at24_read(at24, 0, &test_byte, 1);
 	if (err) {
 		pm_runtime_disable(dev);
-		regulator_disable(at24->vcc_reg);
+		if (!pm_runtime_status_suspended(dev))
+			regulator_disable(at24->vcc_reg);
 		return -ENODEV;
 	}
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 06:36:17 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:17 +0800
Subject: [PATCH v20 5/5] arm64: dts: mt8183: add supply name for eeprom
In-Reply-To: <20210427053617.27972-1-hsinyi@chromium.org>
References: <20210427053617.27972-1-hsinyi@chromium.org>
Message-ID: <20210427053617.27972-6-hsinyi@chromium.org>

Add supplies for eeprom for mt8183 boards.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi | 4 ++++
 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi  | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
index b442e38a3156..28966a65391b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi
@@ -88,11 +88,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -101,11 +103,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
index 2f5234a16ead..3aa79403c0c2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi
@@ -62,11 +62,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c64";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcamio_reg>;
 	};
 };
 
@@ -75,11 +77,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c64";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
index fbc471ccf805..30c183c96a54 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
@@ -71,11 +71,13 @@ &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcamio_reg>;
 
 	eeprom at 58 {
 		compatible = "atmel,24c32";
 		reg = <0x58>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcama2_reg>;
 	};
 };
 
@@ -84,11 +86,13 @@ &i2c4 {
 	pinctrl-0 = <&i2c4_pins>;
 	status = "okay";
 	clock-frequency = <400000>;
+	vbus-supply = <&mt6358_vcn18_reg>;
 
 	eeprom at 54 {
 		compatible = "atmel,24c32";
 		reg = <0x54>;
 		pagesize = <32>;
+		vcc-supply = <&mt6358_vcn18_reg>;
 	};
 };
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Tue Apr 27 06:36:15 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Tue, 27 Apr 2021 13:36:15 +0800
Subject: [PATCH v20 3/5] i2c: mediatek: mt65xx: add optional vbus-supply
In-Reply-To: <20210427053617.27972-1-hsinyi@chromium.org>
References: <20210427053617.27972-1-hsinyi@chromium.org>
Message-ID: <20210427053617.27972-4-hsinyi@chromium.org>

Add vbus-supply which provides power to SCL/SDA. Pass this regulator
into core so it can be turned on/off for low power mode support.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/i2c/busses/i2c-mt65xx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 2ffd2f354d0a..82f2b6716005 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1215,6 +1215,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 	i2c->adap.quirks = i2c->dev_comp->quirks;
 	i2c->adap.timeout = 2 * HZ;
 	i2c->adap.retries = 1;
+	i2c->adap.bus_regulator = devm_regulator_get_optional(&pdev->dev, "vbus");
+	if (IS_ERR(i2c->adap.bus_regulator)) {
+		if (PTR_ERR(i2c->adap.bus_regulator) == -ENODEV)
+			i2c->adap.bus_regulator = NULL;
+		else
+			return PTR_ERR(i2c->adap.bus_regulator);
+	}
 
 	ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
 	if (ret)
-- 
2.31.1.498.g6c1eba8ee3d-goog



From efault at gmx.de  Tue Apr 27 06:54:32 2021
From: efault at gmx.de (Mike Galbraith)
Date: Tue, 27 Apr 2021 07:54:32 +0200
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
In-Reply-To: <d057eb13ec4e4643b314dd1652ffa9d4@hisilicon.com>
References: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
 <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
 <d057eb13ec4e4643b314dd1652ffa9d4@hisilicon.com>
Message-ID: <3fe7113cc87ac89077b55ca55bda2b99729f13c8.camel@gmx.de>

On Tue, 2021-04-27 at 04:44 +0000, Song Bao Hua (Barry Song) wrote:
>
>
> I agree sync hint might have been overused by other kernel subsystem.
> But this patch will at least fix a case: sync waker is interrupt,
> in this case, the existing task has nothing to do with waker and wakee,
> so this case should be excluded from wake_affine_idle().

I long ago tried filtering interrupt wakeups, and met some surprises.
Wakeup twiddling always managing to end up being a rob Peter to pay
Paul operation despite our best efforts, here's hoping that your pile
of stolen cycles is small enough to escape performance bot notice :)

	-Mike



From lyl2019 at mail.ustc.edu.cn  Tue Apr 27 07:02:55 2021
From: lyl2019 at mail.ustc.edu.cn (Lv Yunlong)
Date: Mon, 26 Apr 2021 23:02:55 -0700
Subject: [PATCH v2] media:exynos4-is: Fix a use after free in isp_video_release
Message-ID: <20210427060255.3318-1-lyl2019@mail.ustc.edu.cn>

In isp_video_release, file->private_data is freed via
_vb2_fop_release()->v4l2_fh_release(). But the freed
file->private_data is still used in v4l2_fh_is_singular_file()
->v4l2_fh_is_singular(file->private_data), which is a use
after free bug.

My patch set file->private_data to NULL after _vb2_fop_release()
to avoid the use after free.

Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>
---
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..2e04589068b4 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -315,7 +315,8 @@ static int isp_video_release(struct file *file)
 	}
 
 	_vb2_fop_release(file, NULL);
-
+	file->private_data = NULL;
+
 	if (v4l2_fh_is_singular_file(file)) {
 		fimc_pipeline_call(&ivc->ve, close);
 
-- 
2.25.1




From song.bao.hua at hisilicon.com  Tue Apr 27 07:05:09 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Tue, 27 Apr 2021 06:05:09 +0000
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
In-Reply-To: <3fe7113cc87ac89077b55ca55bda2b99729f13c8.camel@gmx.de>
References: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
 <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
 <d057eb13ec4e4643b314dd1652ffa9d4@hisilicon.com>
 <3fe7113cc87ac89077b55ca55bda2b99729f13c8.camel@gmx.de>
Message-ID: <6c91195a6de9423abc78e8f85efc2780@hisilicon.com>



> -----Original Message-----
> From: Mike Galbraith [mailto:efault at gmx.de]
> Sent: Tuesday, April 27, 2021 5:55 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> vincent.guittot at linaro.org; mingo at redhat.com; peterz at infradead.org;
> dietmar.eggemann at arm.com; rostedt at goodmis.org; bsegall at google.com;
> mgorman at suse.de
> Cc: valentin.schneider at arm.com; juri.lelli at redhat.com; bristot at redhat.com;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; xuwei (O)
> <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; wanghuiqiang
> <wanghuiqiang at huawei.com>; xieyongjia (A) <xieyongjia1 at huawei.com>
> Subject: Re: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
> wake-up is interrupt
> 
> On Tue, 2021-04-27 at 04:44 +0000, Song Bao Hua (Barry Song) wrote:
> >
> >
> > I agree sync hint might have been overused by other kernel subsystem.
> > But this patch will at least fix a case: sync waker is interrupt,
> > in this case, the existing task has nothing to do with waker and wakee,
> > so this case should be excluded from wake_affine_idle().
> 
> I long ago tried filtering interrupt wakeups, and met some surprises.
> Wakeup twiddling always managing to end up being a rob Peter to pay
> Paul operation despite our best efforts, here's hoping that your pile
> of stolen cycles is small enough to escape performance bot notice :)

Would you like to share the link you did before to filter interrupt
wakeups?

The wake up path has hundreds of lines of code, so I don't expect that
reading preempt_count will cause visible performance losses to bot. But
who knows :-)

> 
> 	-Mike

Thanks
Barry


From yaffs at qq.com  Tue Apr 27 07:06:45 2021
From: yaffs at qq.com (=?ISO-8859-1?B?cnRxcQ==?=)
Date: Tue, 27 Apr 2021 14:06:45 +0800
Subject: usb:xhci Report issue of missing memory barrier before ring doorbell
Message-ID: <tencent_7E793A927D2DBCBF6E834C4A0EEC03B14109@qq.com>

Hi,

Armv8 cpu core, xhci usb controller, Linux 5.4 kernel;
xhci usb controller port connect one high speed usb thumb drive, read data from usb disk device, at same time run "many" memtester apps;
after some time,  log as below:
[   97.488082] usb 1-1: reset high-speed USB device number 2
[   97.644326] sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
[   97.652605] sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 0c 80 08 00 00 f0 00
[   97.660300] blk_update_request: I/O error, dev sda, sector 819208 op 0x0:(READ) flags 0x84700 phys_seg 2 prio class 0 

Note must run apps to make enough traffic on system bus, for example many instances of memtester, or many graphic rendering application.

This issue seems is caused by missing memory barrier before ring xhci doorbell.
Function giveback_first_trb:  there is toggle operation on cycle bit filed of start_trb, then call xhci_ring_ep_doorbell.
The cycle bit of trb identify the enqueue pointer of one transfer ring.

I doubt missing memory barrier between toggle cycle bit and xhci_ring_ep_doorbell, so change it like:
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3123,6 +3123,7 @@ static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id,
                start_trb->field[3] |= cpu_to_le32(start_cycle);
        else
                start_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+       wmb();
        xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id);
 }

Then this issue gone by run same test.

From efault at gmx.de  Tue Apr 27 07:15:48 2021
From: efault at gmx.de (Mike Galbraith)
Date: Tue, 27 Apr 2021 08:15:48 +0200
Subject: [PATCH] sched/fair: don't use waker's cpu if the waker of sync
 wake-up is interrupt
In-Reply-To: <6c91195a6de9423abc78e8f85efc2780@hisilicon.com>
References: <20210427023758.4048-1-song.bao.hua@hisilicon.com>
 <9a6cadd9b65068b52c95adc44119bd09c6a4f9d7.camel@gmx.de>
 <d057eb13ec4e4643b314dd1652ffa9d4@hisilicon.com>
 <3fe7113cc87ac89077b55ca55bda2b99729f13c8.camel@gmx.de>
 <6c91195a6de9423abc78e8f85efc2780@hisilicon.com>
Message-ID: <b16c49d6c870594e770dd3eea9f7aea41faf14f6.camel@gmx.de>

On Tue, 2021-04-27 at 06:05 +0000, Song Bao Hua (Barry Song) wrote:
>
> Would you like to share the link you did before to filter interrupt
> wakeups?

Can't, failed experiments go only to my Bitmaster-9000 patch shredder
to avoid needing a snow plow to get to near my box.  Besides, it was
long ago in a much changed code base.

	-Mike



From gregkh at linuxfoundation.org  Tue Apr 27 07:22:04 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Tue, 27 Apr 2021 08:22:04 +0200
Subject: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
In-Reply-To: <CAHk-=wgWLrNQeV20DiCnJVQpfKFkbtC+8=rAqt-wyBFMrHToEw@mail.gmail.com>
References: <YIa2ErYuJyCfSkS+@kroah.com>
 <20210427002648.22459fa7@elm.ozlabs.ibm.com>
 <YIbYI2825E4Z2b/3@kroah.com>
 <CAHk-=wgWLrNQeV20DiCnJVQpfKFkbtC+8=rAqt-wyBFMrHToEw@mail.gmail.com>
Message-ID: <YIetjCa11gzUPos7@kroah.com>

On Mon, Apr 26, 2021 at 11:18:49AM -0700, Linus Torvalds wrote:
> On Mon, Apr 26, 2021 at 8:11 AM Greg KH <gregkh at linuxfoundation.org> wrote:
> >
> > Yeah, merge issues with other trees are hard to resolve in the single
> > tree here, not much I can just yet, have to wait for them to hit Linus's
> > tree.
> 
> It's generally a good idea to mention these things if you know about
> them, just in case the other tree had come in in the meantime and I
> had merged it first.
> 
> That didn't happen this time, and I do generally catch these things
> anyway as long as they at least trigger problems for my usual x86-64
> allmodconfig builds (but not everything does trigger that).

Sorry, will mention it next time when I know it's going to happen with
another tree like this.

Thanks for pulling,

greg k-h


From CLoehle at hyperstone.com  Tue Apr 27 07:20:44 2021
From: CLoehle at hyperstone.com (=?iso-8859-1?Q?Christian_L=F6hle?=)
Date: Tue, 27 Apr 2021 06:20:44 +0000
Subject: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64
Message-ID: <CWXP265MB2680938B222248792AC205F9C4419@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>

The DesignWare Host Controller has full UHS-I support, so use it.

Signed-off-by: Christian Loehle <cloehle at hyperstone.com>
---
 arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
index 6bff8db7d33e..d22a489ec214 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
@@ -722,6 +722,7 @@ &sdmmc {
 	max-frequency = <150000000>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+	sd-uhs-sdr104;
 	vmmc-supply = <&vcc3v0_sd>;
 	vqmmc-supply = <&vcc_sdio>;
 	status = "okay";
-- 
2.31.1
Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782



From rppt at kernel.org  Tue Apr 27 07:23:33 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Tue, 27 Apr 2021 09:23:33 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
Message-ID: <YIet5X7lgygD9rpZ@kernel.org>

On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/26 13:20, Mike Rapoport wrote:
> > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > 
> > >      On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > 
> > >          I tested this patchset(plus arm32 change, like arm64 does)
> > >          based on lts 5.10?add some debug log, the useful info shows
> > >          below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > >          thanks.
> > > 
> > >      Are there any changes on top of 5.10 except for pfn_valid() patch?
> > >      Do you see this panic on 5.10 without the changes?
> > > 
> > > Yes, there are some BSP support for arm board based on 5.10,

Is it possible to test 5.12?

> > > with or without your patch will get same panic, the panic pfn=de600
> > > in the range of [dcc00,de00] which is freed by free_memmap, start_pfn
> > > = dcc00,? dcc00000 end_pfn = de700, de700000
> > > 
> > > we see the PC is at PageLRU, same reason like arm64 panic log,
> > > 
> > >     "PageBuddy in move_freepages returns false
> > >      Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
> > >      compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
> > >      resturns 0xfffffffffffffffe - and accessing this address causes crash"
> > > 
> > >      Can you see stack backtrace beyond move_freepages_block?
> > > 
> > > I do some oom test, so the log is about memory allocate,
> > > 
> > > [<c02383c8>] (move_freepages_block) from [<c0238668>]
> > > (steal_suitable_fallback+0x174/0x1f4)
> > > 
> > > [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
> >
> > Hmm, this is called with a page from free list, having a page from a freed
> > part of the memory map passed to steal_suitable_fallback() means that there
> > is an issue with creation of the free list.
> > 
> > Can you please add "memblock=debug" to the kernel command line and post the
> > log?
> 
> Here is the log,
> 
> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d
> 
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> OF: fdt: Machine model: HISI-CA9
> memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
> memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
> Malformed early option 'vecpage_wrprotect'
> Memory policy: Data cache writealloc
> memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
> memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
> memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
> memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
> MEMBLOCK configuration:
> ?memory size = 0x4c0fffff reserved size = 0x027ef058
> ?memory.cnt? = 0xa
> ?memory[0x0]??? [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
> ?memory[0x1]??? [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
> ?memory[0x2]??? [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
> ?memory[0x3]??? [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
> ?memory[0x4]??? [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
> ?memory[0x5]??? [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
> ?memory[0x6]??? [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
> ?memory[0x7]??? [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
> ?memory[0x8]??? [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
> ?memory[0x9]??? [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
> ?reserved.cnt? = 0x4
> ?reserved[0x0]??? [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
> ?reserved[0x1]??? [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
> ?reserved[0x2]??? [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
> ?reserved[0x3]??? [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
...
> Zone ranges:
> ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
> ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
> Movable zone start for each node
> Early memory node ranges
> ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
> ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
> ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
> ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
> ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
> ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
> ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
> ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
> ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
> ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
> Zeroed struct page in unavailable ranges: 513 pages
> Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
> On node 0 totalpages: 311551
> ? Normal zone: 1230 pages used for memmap
> ? Normal zone: 0 pages reserved
> ? Normal zone: 157440 pages, LIFO batch:31
> ? HighMem zone: 154111 pages, LIFO batch:31

AFAICT the range [de600000, de7ff000] should not be added to the free
lists.

Can you try with the below patch:

diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..7f3c33d53f87 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1994,6 +1994,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
 	unsigned long end_pfn = min_t(unsigned long,
 				      PFN_DOWN(end), max_low_pfn);
 
+	pr_info("%s: range: %pa - %pa, pfn: %lx - %lx\n", __func__, &start, &end, start_pfn, end_pfn);
+
 	if (start_pfn >= end_pfn)
 		return 0;
 
 
> > > [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
> > > [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
> > > [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
> > > [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
> > > [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
> > > [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
> > > 
> > >          Zone ranges:
> > >          ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
> > >          ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
> > >          Movable zone start for each node
> > >          Early memory node ranges
> > >          ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
> > >          ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
> > >          ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
> > >          ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
> > >          ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
> > >          ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
> > >          ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
> > >          ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
> > >          ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
> > >          ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
> > > 
> > >          ----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
> > >          ----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
> > >          ----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
> > >          ----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
> > >          ----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
> > >          ----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
> > >          ----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
> > >          === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
> > >          :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
> > >          8<--- cut here ---
> > >          Unable to handle kernel paging request at virtual address fffffffe
> > >          pgd = 5dd50df5
> > >          [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
> > >          Internal error: Oops: 37 [#1] SMP ARM
> > >          Modules linked in: gmac(O)
> > >          CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
> > >          Hardware name: Hisilicon A9
> > >          PC is at move_freepages_block+0x150/0x278
> > >          LR is at move_freepages_block+0x150/0x278
> > >          pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
> > >          sp : c4179cf8? ip : 00000000? fp : 00000001
> > >          r10: c4179d58? r9 : 000de7ff? r8 : 00000000
> > >          r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
> > >          r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
> > >          Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
> > >          Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
> > >          Process test-oom (pid: 635, stack limit = 0x25d667df)
> > > 
> > > 

-- 
Sincerely yours,
Mike.


From cristian.marussi at arm.com  Tue Apr 27 07:36:04 2021
From: cristian.marussi at arm.com (Cristian Marussi)
Date: Tue, 27 Apr 2021 07:36:04 +0100
Subject: [PATCH] firmware: arm_scmi: Remove repeated struct declaration
In-Reply-To: <20210427033031.4580-1-wanjiabing@vivo.com>
References: <20210427033031.4580-1-wanjiabing@vivo.com>
Message-ID: <20210427063604.GH43717@e120937-lin>

Hi,

On Tue, Apr 27, 2021 at 11:30:31AM +0800, Wan Jiabing wrote:
> struct scmi_protocol_handle is declared at 34th line.
> The declaration here is duplicate. Remove it.
> 

You're right.

Reviewed-by: Cristian Marussi <cristian.marussi at arm.com>

Thanks,
Cristian

> Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
> ---
>  drivers/firmware/arm_scmi/notify.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/notify.h b/drivers/firmware/arm_scmi/notify.h
> index ce0324be6c71..4e9b627edfef 100644
> --- a/drivers/firmware/arm_scmi/notify.h
> +++ b/drivers/firmware/arm_scmi/notify.h
> @@ -79,8 +79,6 @@ struct scmi_protocol_events {
>  
>  int scmi_notification_init(struct scmi_handle *handle);
>  void scmi_notification_exit(struct scmi_handle *handle);
> -
> -struct scmi_protocol_handle;
>  int scmi_register_protocol_events(const struct scmi_handle *handle, u8 proto_id,
>  				  const struct scmi_protocol_handle *ph,
>  				  const struct scmi_protocol_events *ee);
> -- 
> 2.25.1
> 


From bpeled at marvell.com  Tue Apr 27 08:07:20 2021
From: bpeled at marvell.com (Ben Peled)
Date: Tue, 27 Apr 2021 07:07:20 +0000
Subject: =?Windows-1252?Q?RE:_[EXT]_Re:_[=94PATCH=94_2/5]_PCI:_armada8k:_Add_link-?=
 =?Windows-1252?Q?down_handle?=
In-Reply-To: <20210414134240.000057b4@Huawei.com>
References: <1618241456-27200-1-git-send-email-bpeled@marvell.com>
 <1618241456-27200-3-git-send-email-bpeled@marvell.com>
 <20210414134240.000057b4@Huawei.com>
Message-ID: <MW2PR18MB2217E007583257709A026553C2419@MW2PR18MB2217.namprd18.prod.outlook.com>

Hi Jonathan,


> > In PCIE ISR routine caused by RST_LINK_DOWN we schedule work to handle
> > the link-down procedure.
> > Link-down procedure will:
> > 1. Remove PCIe bus
> > 2. Reset the MAC
> > 3. Reconfigure link back up
> > 4. Rescan PCIe bus
> >
> > Signed-off-by: Ben Peled <bpeled at marvell.com>
> 
> Trivial comment inline.
> 
> Also, something odd with quotes around PATCH in the title you probably
> want to clean up.
> 

I'll change the comment to more informative comments

> > ---
> >  drivers/pci/controller/dwc/pcie-armada8k.c | 68 ++++++++++++++++++++
> >  1 file changed, 68 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-armada8k.c
> > b/drivers/pci/controller/dwc/pcie-armada8k.c
> > index b2278b1..4eb8607 100644
> > --- a/drivers/pci/controller/dwc/pcie-armada8k.c
> > +++ b/drivers/pci/controller/dwc/pcie-armada8k.c
> > @@ -22,6 +22,8 @@
> >  #include <linux/resource.h>
> >  #include <linux/of_pci.h>
> >  #include <linux/of_irq.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/regmap.h>
> >
> >  #include "pcie-designware.h"
> >
> > @@ -33,6 +35,9 @@ struct armada8k_pcie {
> >  	struct clk *clk_reg;
> >  	struct phy *phy[ARMADA8K_PCIE_MAX_LANES];
> >  	unsigned int phy_count;
> > +	struct regmap *sysctrl_base;
> > +	u32 mac_rest_bitmask;
> > +	struct work_struct recover_link_work;
> >  };
> >
> >  #define PCIE_VENDOR_REGS_OFFSET		0x8000
> > @@ -73,6 +78,8 @@ struct armada8k_pcie {
> >  #define AX_USER_DOMAIN_MASK		0x3
> >  #define AX_USER_DOMAIN_SHIFT		4
> >
> > +#define UNIT_SOFT_RESET_CONFIG_REG	0x268
> > +
> >  #define to_armada8k_pcie(x)	dev_get_drvdata((x)->dev)
> >
> >  static void armada8k_pcie_disable_phys(struct armada8k_pcie *pcie) @@
> > -224,6 +231,49 @@ static int armada8k_pcie_host_init(struct pcie_port
> > *pp)
> >
> >  	return 0;
> >  }
> > +static void armada8k_pcie_recover_link(struct work_struct *ws) {
> > +	struct armada8k_pcie *pcie = container_of(ws, struct
> armada8k_pcie, recover_link_work);
> > +	struct pcie_port *pp = &pcie->pci->pp;
> > +	struct pci_bus *bus = pp->bridge->bus;
> > +	struct pci_dev *root_port;
> > +	int ret;
> > +
> > +	root_port = pci_get_slot(bus, 0);
> > +	if (!root_port) {
> > +		dev_err(pcie->pci->dev, "failed to get root port\n");
> > +		return;
> > +	}
> > +	pci_lock_rescan_remove();
> > +	pci_stop_and_remove_bus_device(root_port);
> > +	/*
> > +	 * Sleep needed to make sure all pcie transactions and access
> > +	 * are flushed before resetting the mac
> > +	 */
> > +	msleep(100);
> > +
> > +	/* Reset mac */
> > +	regmap_update_bits_base(pcie->sysctrl_base,
> UNIT_SOFT_RESET_CONFIG_REG,
> > +				pcie->mac_rest_bitmask, 0, NULL, false, true);
> > +	udelay(1);
> > +	regmap_update_bits_base(pcie->sysctrl_base,
> UNIT_SOFT_RESET_CONFIG_REG,
> > +				pcie->mac_rest_bitmask, pcie-
> >mac_rest_bitmask,
> > +				NULL, false, true);
> > +	udelay(1);
> > +	ret = armada8k_pcie_host_init(pp);
> > +	if (ret) {
> > +		dev_err(pcie->pci->dev, "failed to initialize host: %d\n", ret);
> > +		pci_unlock_rescan_remove();
> > +		pci_dev_put(root_port);
> > +		return;
> > +	}
> > +
> > +	bus = NULL;
> > +	while ((bus = pci_find_next_bus(bus)) != NULL)
> > +		pci_rescan_bus(bus);
> > +	pci_unlock_rescan_remove();
> > +	pci_dev_put(root_port);
> > +}
> >
> >  static irqreturn_t armada8k_pcie_irq_handler(int irq, void *arg)  {
> > @@ -262,6 +312,9 @@ static irqreturn_t armada8k_pcie_irq_handler(int
> irq, void *arg)
> >  		 * initiate a link retrain. If link retrains were
> >  		 * possible, that is.
> >  		 */
> > +		if (pcie->sysctrl_base && pcie->mac_rest_bitmask)
> > +			schedule_work(&pcie->recover_link_work);
> > +
> >  		dev_dbg(pci->dev, "%s: link went down\n", __func__);
> >  	}
> >
> > @@ -330,6 +383,8 @@ static int armada8k_pcie_probe(struct
> > platform_device *pdev)
> >
> >  	pcie->pci = pci;
> >
> > +	INIT_WORK(&pcie->recover_link_work,
> armada8k_pcie_recover_link);
> > +
> >  	pcie->clk = devm_clk_get(dev, NULL);
> >  	if (IS_ERR(pcie->clk))
> >  		return PTR_ERR(pcie->clk);
> > @@ -357,6 +412,19 @@ static int armada8k_pcie_probe(struct
> platform_device *pdev)
> >  		goto fail_clkreg;
> >  	}
> >
> > +	pcie->sysctrl_base = syscon_regmap_lookup_by_phandle(pdev-
> >dev.of_node,
> > +						       "marvell,system-
> controller");
> > +	if (IS_ERR(pcie->sysctrl_base)) {
> > +		dev_warn(dev, "failed to find marvell,system-controller\n");
> > +		pcie->sysctrl_base = 0x0;
> 
> = NULL; ?
> 
I will change this to NULL in v3
> > +	}
> > +
> > +	ret = of_property_read_u32(pdev->dev.of_node, "marvell,mac-reset-
> bit-mask",
> > +				   &pcie->mac_rest_bitmask);
> > +	if (ret < 0) {
> > +		dev_warn(dev, "couldn't find mac reset bit mask: %d\n", ret);
> > +		pcie->mac_rest_bitmask = 0x0;
> > +	}
> >  	ret = armada8k_pcie_setup_phys(pcie);
> >  	if (ret)
> >  		goto fail_clkreg;

Thanks,
Ben





From o.rempel at pengutronix.de  Tue Apr 27 08:15:12 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Tue, 27 Apr 2021 09:15:12 +0200
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
 <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
Message-ID: <20210427071512.vprrsajwwhmmb3ch@pengutronix.de>

Hi Joakim,

On Tue, Apr 27, 2021 at 04:48:42AM +0000, Joakim Zhang wrote:
> > Hi Joakim,
> > 
> > On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
> > >
> > > Hi Oleksij,
> > >
> > > I look both stmmac selftest code and this patch set. For stmmac, if PHY
> > doesn't support loopback, it will fallthrough to MAC loopback.
> > > You provide this generic net selftest support based on PHY loopback, I have a
> > question, is it possible to extend it also support MAC loopback later?
> > 
> > Yes. If you have interest and time to implement it, please do.
> > It should be some kind of generic callback as phy_loopback() and if PHY and
> > MAC loopbacks are supported we need to tests both variants.
> Hi Oleksij,
> 
> Yes, I can try to implement it when I am free, but I still have some questions:
> 1. Where we place the generic function? Such as mac_loopback().
> 2. MAC is different from PHY, need program different registers to enable loopback on different SoCs, that means we need get MAC private data from "struct net_device".

ACK

> So we need a callback for MAC drivers, where we extend this callback? Could be "struct net_device_ops"? Such as ndo_set_loopback?

yes. Sounds good for me. ndo_set_loopback could be implemented for
ethernet controllers, DSA and even CAN. 

Regards,
Oleksij

> > > > -----Original Message-----
> > > > From: Oleksij Rempel <o.rempel at pengutronix.de>
> > > > Sent: 2021?4?19? 21:01
> > > > To: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> > > > <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian
> > > > Fainelli <f.fainelli at gmail.com>; Heiner Kallweit
> > > > <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>
> > > > Cc: Oleksij Rempel <o.rempel at pengutronix.de>; kernel at pengutronix.de;
> > > > netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > > > linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>;
> > > > Fabio Estevam <festevam at gmail.com>; David Jander
> > > > <david at protonic.nl>; Russell King <linux at armlinux.org.uk>; Philippe
> > > > Schenker <philippe.schenker at toradex.com>
> > > > Subject: [PATCH net-next v3 0/6] provide generic net selftest
> > > > support
> > > >
> > > > changes v3:
> > > > - make more granular tests
> > > > - enable loopback for all PHYs by default
> > > > - fix allmodconfig build errors
> > > > - poll for link status update after switching to the loopback mode
> > > >
> > > > changes v2:
> > > > - make generic selftests available for all networking devices.
> > > > - make use of net_selftest* on FEC, ag71xx and all DSA switches.
> > > > - add loopback support on more PHYs.
> > > >
> > > > This patch set provides diagnostic capabilities for some iMX, ag71xx
> > > > or any DSA based devices. For proper functionality, PHY loopback support is
> > needed.
> > > > So far there is only initial infrastructure with basic tests.
> > > >
> > > > Oleksij Rempel (6):
> > > >   net: phy: execute genphy_loopback() per default on all PHYs
> > > >   net: phy: genphy_loopback: add link speed configuration
> > > >   net: add generic selftest support
> > > >   net: fec: make use of generic NET_SELFTESTS library
> > > >   net: ag71xx: make use of generic NET_SELFTESTS library
> > > >   net: dsa: enable selftest support for all switches by default
> > > >
> > > >  drivers/net/ethernet/atheros/Kconfig      |   1 +
> > > >  drivers/net/ethernet/atheros/ag71xx.c     |  20 +-
> > > >  drivers/net/ethernet/freescale/Kconfig    |   1 +
> > > >  drivers/net/ethernet/freescale/fec_main.c |   7 +
> > > >  drivers/net/phy/phy.c                     |   3 +-
> > > >  drivers/net/phy/phy_device.c              |  35 +-
> > > >  include/linux/phy.h                       |   1 +
> > > >  include/net/dsa.h                         |   2 +
> > > >  include/net/selftests.h                   |  12 +
> > > >  net/Kconfig                               |   4 +
> > > >  net/core/Makefile                         |   1 +
> > > >  net/core/selftests.c                      | 400
> > > > ++++++++++++++++++++++
> > > >  net/dsa/Kconfig                           |   1 +
> > > >  net/dsa/slave.c                           |  21 ++
> > > >  14 files changed, 500 insertions(+), 9 deletions(-)  create mode
> > > > 100644 include/net/selftests.h  create mode 100644
> > > > net/core/selftests.c
> > > >
> > > > --
> > > > 2.29.2
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&amp;data=04%7
> > C0
> > >
> > 1%7Cqiangqing.zhang%40nxp.com%7C8796bf53e46b4b1be92b08d9061186f9
> > %7C686
> > >
> > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637547494614753358%7CU
> > nknown%7
> > >
> > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > CJXV
> > >
> > CI6Mn0%3D%7C1000&amp;sdata=x%2BUFB%2B1Xp0zbR1mG5HDGvqBUvKhX
> > VJn337T%2BB
> > > D7cO6g%3D&amp;reserved=0
> > 
> > --
> > Pengutronix e.K.                           |
> > |
> > Steuerwalder Str. 21                       |
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
> > ngutronix.de%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C87
> > 96bf53e46b4b1be92b08d9061186f9%7C686ea1d3bc2b4c6fa92cd99c5c301635
> > %7C0%7C0%7C637547494614753358%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10
> > 00&amp;sdata=K2dsGVxEXv%2FtC7p0l4TFlLlaqzzTa6ktrbSdcCJ10J0%3D&amp;
> > reserved=0  |
> > 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0
> > |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:
> > +49-5121-206917-5555 |

-- 
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 yuzenghui at huawei.com  Tue Apr 27 08:15:39 2021
From: yuzenghui at huawei.com (Zenghui Yu)
Date: Tue, 27 Apr 2021 15:15:39 +0800
Subject: [PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel
 transitions
In-Reply-To: <0e1143a5-8e1a-c04e-e4fd-5c57f8354f61@huawei.com>
References: <20201130115950.22492-1-mark.rutland@arm.com>
 <20201130115950.22492-10-mark.rutland@arm.com>
 <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>
 <20210426092139.GA16287@C02TD0UTHF1T.local>
 <0e1143a5-8e1a-c04e-e4fd-5c57f8354f61@huawei.com>
Message-ID: <d7ee0514-9be0-1c38-c280-045989e5778a@huawei.com>

On 2021/4/26 21:39, Zenghui Yu wrote:
> Hi Mark,
> 
> On 2021/4/26 17:21, Mark Rutland wrote:
 >
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 6acfc5e6b5e0..7d46c74a8706 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -292,6 +292,8 @@ alternative_else_nop_endif
>>  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
>>  	mrs_s	x20, SYS_ICC_PMR_EL1
>>  	str	x20, [sp, #S_PMR_SAVE]
>> +	orr	x20, x20, #GIC_PRIO_PSR_I_SET
>> +	msr_s	SYS_ICC_PMR_EL1, x20
>>  alternative_else_nop_endif
> 
> While this does fix the lockdep part, it breaks something else. The
> sleep-in-atomic one stands out (which says, I've seen other splats
> triggered with this diff), where irqs_disabled() in do_mem_abort() now
> gets confused by the updated PMR (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET).

Seem that this can be addressed by restoring pt_regs->pmr_save into PMR
in local_daif_inherit() (before we restore the DAIF bits)?


Thanks,
Zenghui


From jernej.skrabec at siol.net  Tue Apr 27 08:15:54 2021
From: jernej.skrabec at siol.net (Jernej Skrabec)
Date: Tue, 27 Apr 2021 09:15:54 +0200
Subject: [PATCH] media: hevc: Fix dependent slice segment flags
Message-ID: <20210427071554.2222625-1-jernej.skrabec@siol.net>

Dependent slice segment flag for PPS control is misnamed. It should have
"enabled" at the end. It only tells if this flag is present in slice
header or not and not the actual value.

Fix this by renaming the PPS flag and introduce another flag for slice
control which tells actual value.

Signed-off-by: Jernej Skrabec <jernej.skrabec at siol.net>
---
 Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 5 ++++-
 drivers/staging/media/sunxi/cedrus/cedrus_h265.c          | 4 ++--
 include/media/hevc-ctrls.h                                | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 7b90cb939e9d..5ed343ddd1ea 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -3059,7 +3059,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     :stub-columns: 0
     :widths:       1 1 2
 
-    * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT``
+    * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED``
       - 0x00000001
       -
     * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT``
@@ -3274,6 +3274,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
     * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED``
       - 0x00000100
       -
+    * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT``
+      - 0x00000200
+      -
 
 .. raw:: latex
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
index 397a4ba5df4c..6821e3d05d34 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
@@ -479,8 +479,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
 				slice_params->flags);
 
 	reg |= VE_DEC_H265_FLAG(VE_DEC_H265_DEC_SLICE_HDR_INFO0_FLAG_DEPENDENT_SLICE_SEGMENT,
-				V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT,
-				pps->flags);
+				V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT,
+				slice_params->flags);
 
 	/* FIXME: For multi-slice support. */
 	reg |= VE_DEC_H265_DEC_SLICE_HDR_INFO0_FLAG_FIRST_SLICE_SEGMENT_IN_PIC;
diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
index b713eeed1915..dc964ff7cd29 100644
--- a/include/media/hevc-ctrls.h
+++ b/include/media/hevc-ctrls.h
@@ -83,7 +83,7 @@ struct v4l2_ctrl_hevc_sps {
 	__u64	flags;
 };
 
-#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT		(1ULL << 0)
+#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED	(1ULL << 0)
 #define V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT			(1ULL << 1)
 #define V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED		(1ULL << 2)
 #define V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT			(1ULL << 3)
@@ -166,6 +166,7 @@ struct v4l2_hevc_pred_weight_table {
 #define V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV		(1ULL << 6)
 #define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED (1ULL << 7)
 #define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 8)
+#define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT	(1ULL << 9)
 
 struct v4l2_ctrl_hevc_slice_params {
 	__u32	bit_size;
-- 
2.31.1



From michal.simek at xilinx.com  Tue Apr 27 08:23:17 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 27 Apr 2021 09:23:17 +0200
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
Message-ID: <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>

Hi Andy,

On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> <lakshmis at xilinx.com> wrote:
>>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
>>> Sent: Friday, April 23, 2021 9:24 PM
>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> 
> ...
> 
>>>> +config PINCTRL_ZYNQMP
>>>> +       tristate "Pinctrl driver for Xilinx ZynqMP"
>>>> +       depends on ZYNQMP_FIRMWARE
>>>> +       select PINMUX
>>>> +       select GENERIC_PINCONF
>>>> +       default ZYNQMP_FIRMWARE
>>>> +       help
>>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
>>>> +         This driver will query the pin information from the firmware
>>>> +         and allow configuring the pins.
>>>> +         Configuration can include the mux function to select on those
>>>> +         pin(s)/group(s), and various pin configuration parameters
>>>> +         such as pull-up, slew rate, etc.
>>>
>>> Missed module name.
>> Is this (module name) a configuration option in Kconfig?
> 
> It's a text in a free form that sheds light on how the module will be
> named in case the user will choose "m".

Is this described somewhere in documentation that module name should be
the part of symbol description? I was looking at pinctrl Kconfig and I
can't see any description like this there that's why I want to double
check.

Also if this is a rule checkpatch should be extended to checking this.

Thanks,
Michal


From andy.shevchenko at gmail.com  Tue Apr 27 08:31:08 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 27 Apr 2021 10:31:08 +0300
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
Message-ID: <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>

On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek at xilinx.com> wrote:
>
> Hi Andy,
>
> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> > On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> > <lakshmis at xilinx.com> wrote:
> >>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
> >>> Sent: Friday, April 23, 2021 9:24 PM
> >>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> >
> > ...
> >
> >>>> +config PINCTRL_ZYNQMP
> >>>> +       tristate "Pinctrl driver for Xilinx ZynqMP"
> >>>> +       depends on ZYNQMP_FIRMWARE
> >>>> +       select PINMUX
> >>>> +       select GENERIC_PINCONF
> >>>> +       default ZYNQMP_FIRMWARE
> >>>> +       help
> >>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> >>>> +         This driver will query the pin information from the firmware
> >>>> +         and allow configuring the pins.
> >>>> +         Configuration can include the mux function to select on those
> >>>> +         pin(s)/group(s), and various pin configuration parameters
> >>>> +         such as pull-up, slew rate, etc.
> >>>
> >>> Missed module name.
> >> Is this (module name) a configuration option in Kconfig?
> >
> > It's a text in a free form that sheds light on how the module will be
> > named in case the user will choose "m".
>
> Is this described somewhere in documentation that module name should be
> the part of symbol description? I was looking at pinctrl Kconfig and I
> can't see any description like this there that's why I want to double
> check.

I dunno if it is described, the group of maintainers require that for some time.
I personally found this as a good practice.

> Also if this is a rule checkpatch should be extended to checking this.

There was a discussion at some point to add a check that help
description shouldn't be less than 3 lines. Not sure what the outcome
of it.

-- 
With Best Regards,
Andy Shevchenko


From jon.lin at rock-chips.com  Tue Apr 27 08:37:28 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:37:28 +0800
Subject: [PATCH v2 3/8] dt-bindings: spi: spi-rockchip: add description for
 rv1126
In-Reply-To: <20210427073733.31419-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
Message-ID: <20210427073733.31419-3-jon.lin@rock-chips.com>

The description below will be used for rv1126.dtsi in the future

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 1e6cf29e6388..4ed5b72a8494 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -27,6 +27,7 @@ properties:
       - items:
           - enum:
               - rockchip,px30-spi
+              - rockchip,rv1126-spi
               - rockchip,rk3188-spi
               - rockchip,rk3288-spi
               - rockchip,rk3308-spi
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:37:29 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:37:29 +0800
Subject: [PATCH v2 4/8] spi: rockchip: add compatible string for rv1126
In-Reply-To: <20210427073733.31419-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
Message-ID: <20210427073733.31419-4-jon.lin@rock-chips.com>

Add compatible string for rv1126 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 0f39ea2d1d31..9fdb53fb7ede 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -929,6 +929,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3368-spi", },
 	{ .compatible = "rockchip,rk3399-spi", },
 	{ .compatible = "rockchip,rv1108-spi", },
+	{ .compatible = "rockchip,rv1126-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:37:26 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:37:26 +0800
Subject: [PATCH v2 1/8] spi: rockchip: Set rx_fifo interrupt waterline base on
 transfer item
Message-ID: <20210427073733.31419-1-jon.lin@rock-chips.com>

The error here is to calculate the width as 8 bits. In fact, 16 bits
should be considered.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 52d6259d96ed..406ea3c6abd9 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -540,8 +540,8 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	 * interrupt exactly when the fifo is full doesn't seem to work,
 	 * so we need the strict inequality here
 	 */
-	if (xfer->len < rs->fifo_len)
-		writel_relaxed(xfer->len - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
+	if ((xfer->len / rs->n_bytes) < rs->fifo_len)
+		writel_relaxed(xfer->len / rs->n_bytes - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 	else
 		writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:37:27 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:37:27 +0800
Subject: [PATCH v2 2/8] spi: rockchip: Wait for STB status in slave mode
 tx_xfer
In-Reply-To: <20210427073733.31419-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
Message-ID: <20210427073733.31419-2-jon.lin@rock-chips.com>

After ROCKCHIP_SPI_VER2_TYPE2, SR->STB is a more accurate judgment
bit for spi slave transmition.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 406ea3c6abd9..0f39ea2d1d31 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -116,13 +116,14 @@
 #define BAUDR_SCKDV_MIN				2
 #define BAUDR_SCKDV_MAX				65534
 
-/* Bit fields in SR, 5bit */
-#define SR_MASK						0x1f
+/* Bit fields in SR, 6bit */
+#define SR_MASK						0x3f
 #define SR_BUSY						(1 << 0)
 #define SR_TF_FULL					(1 << 1)
 #define SR_TF_EMPTY					(1 << 2)
 #define SR_RF_EMPTY					(1 << 3)
 #define SR_RF_FULL					(1 << 4)
+#define SR_SLAVE_TX_BUSY				(1 << 5)
 
 /* Bit fields in ISR, IMR, ISR, RISR, 5bit */
 #define INT_MASK					0x1f
@@ -197,13 +198,19 @@ static inline void spi_enable_chip(struct rockchip_spi *rs, bool enable)
 	writel_relaxed((enable ? 1U : 0U), rs->regs + ROCKCHIP_SPI_SSIENR);
 }
 
-static inline void wait_for_idle(struct rockchip_spi *rs)
+static inline void wait_for_tx_idle(struct rockchip_spi *rs, bool slave_mode)
 {
 	unsigned long timeout = jiffies + msecs_to_jiffies(5);
 
 	do {
-		if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
-			return;
+		if (slave_mode) {
+			if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_SLAVE_TX_BUSY) &&
+			    !((readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
+				return;
+		} else {
+			if (!(readl_relaxed(rs->regs + ROCKCHIP_SPI_SR) & SR_BUSY))
+				return;
+		}
 	} while (!time_after(jiffies, timeout));
 
 	dev_warn(rs->dev, "spi controller is in busy state!\n");
@@ -383,7 +390,7 @@ static void rockchip_spi_dma_txcb(void *data)
 		return;
 
 	/* Wait until the FIFO data completely. */
-	wait_for_idle(rs);
+	wait_for_tx_idle(rs, ctlr->slave);
 
 	spi_enable_chip(rs, false);
 	spi_finalize_current_transfer(ctlr);
@@ -545,7 +552,7 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	else
 		writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_RXFTLR);
 
-	writel_relaxed(rs->fifo_len / 2, rs->regs + ROCKCHIP_SPI_DMATDLR);
+	writel_relaxed(rs->fifo_len / 2 - 1, rs->regs + ROCKCHIP_SPI_DMATDLR);
 	writel_relaxed(rockchip_spi_calc_burst_size(xfer->len / rs->n_bytes) - 1,
 		       rs->regs + ROCKCHIP_SPI_DMARDLR);
 	writel_relaxed(dmacr, rs->regs + ROCKCHIP_SPI_DMACR);
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:37:30 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:37:30 +0800
Subject: [PATCH v2 5/8] spi: rockchip: Support cs-gpio
In-Reply-To: <20210427073733.31419-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
Message-ID: <20210427073733.31419-5-jon.lin@rock-chips.com>

1.Add standard cs-gpio support
2.Refer to spi-controller.yaml for details

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 61 ++++++++++++++++++++++++++++++++++----
 1 file changed, 56 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 9fdb53fb7ede..3b05c1ed6308 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -6,6 +6,7 @@
 
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
+#include <linux/gpio.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -157,7 +158,8 @@
  */
 #define ROCKCHIP_SPI_MAX_TRANLEN		0xffff
 
-#define ROCKCHIP_SPI_MAX_CS_NUM			2
+/* 2 for native cs, 2 for cs-gpio */
+#define ROCKCHIP_SPI_MAX_CS_NUM			4
 #define ROCKCHIP_SPI_VER2_TYPE1			0x05EC0002
 #define ROCKCHIP_SPI_VER2_TYPE2			0x00110002
 
@@ -191,6 +193,7 @@ struct rockchip_spi {
 	bool cs_asserted[ROCKCHIP_SPI_MAX_CS_NUM];
 
 	bool slave_abort;
+	bool gpio_requested;
 };
 
 static inline void spi_enable_chip(struct rockchip_spi *rs, bool enable)
@@ -245,11 +248,15 @@ static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 		/* Keep things powered as long as CS is asserted */
 		pm_runtime_get_sync(rs->dev);
 
-		ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER,
-				      BIT(spi->chip_select));
+		if (gpio_is_valid(spi->cs_gpio))
+			ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, 1);
+		else
+			ROCKCHIP_SPI_SET_BITS(rs->regs + ROCKCHIP_SPI_SER, BIT(spi->chip_select));
 	} else {
-		ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER,
-				      BIT(spi->chip_select));
+		if (gpio_is_valid(spi->cs_gpio))
+			ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER, 1);
+		else
+			ROCKCHIP_SPI_CLR_BITS(rs->regs + ROCKCHIP_SPI_SER, BIT(spi->chip_select));
 
 		/* Drop reference from when we first asserted CS */
 		pm_runtime_put(rs->dev);
@@ -632,6 +639,47 @@ static bool rockchip_spi_can_dma(struct spi_controller *ctlr,
 	return xfer->len / bytes_per_word >= rs->fifo_len;
 }
 
+static int rockchip_spi_setup(struct spi_device *spi)
+{
+
+	int ret = -EINVAL;
+	struct rockchip_spi *rs = spi_controller_get_devdata(spi->controller);
+
+	if (spi->cs_gpio == -ENOENT)
+		return 0;
+
+	if (!rs->gpio_requested && gpio_is_valid(spi->cs_gpio)) {
+		ret = gpio_request_one(spi->cs_gpio,
+				       (spi->mode & SPI_CS_HIGH) ?
+				       GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH,
+				       dev_name(&spi->dev));
+		if (ret)
+			dev_err(&spi->dev, "can't request chipselect gpio %d\n",
+				spi->cs_gpio);
+		else
+			rs->gpio_requested = true;
+	} else {
+		if (gpio_is_valid(spi->cs_gpio)) {
+			int mode = ((spi->mode & SPI_CS_HIGH) ? 0 : 1);
+
+			ret = gpio_direction_output(spi->cs_gpio, mode);
+			if (ret)
+				dev_err(&spi->dev, "chipselect gpio %d setup failed (%d)\n",
+					spi->cs_gpio, ret);
+		}
+	}
+
+	return ret;
+}
+
+static void rockchip_spi_cleanup(struct spi_device *spi)
+{
+	struct rockchip_spi *rs = spi_controller_get_devdata(spi->controller);
+
+	if (rs->gpio_requested)
+		gpio_free(spi->cs_gpio);
+}
+
 static int rockchip_spi_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -706,6 +754,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 
 	rs->dev = &pdev->dev;
 	rs->freq = clk_get_rate(rs->spiclk);
+	rs->gpio_requested = false;
 
 	if (!of_property_read_u32(pdev->dev.of_node, "rx-sample-delay-ns",
 				  &rsd_nsecs)) {
@@ -759,6 +808,8 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 	ctlr->max_speed_hz = min(rs->freq / BAUDR_SCKDV_MIN, MAX_SCLK_OUT);
 
 	ctlr->set_cs = rockchip_spi_set_cs;
+	ctlr->setup = rockchip_spi_setup;
+	ctlr->cleanup = rockchip_spi_cleanup;
 	ctlr->transfer_one = rockchip_spi_transfer_one;
 	ctlr->max_transfer_size = rockchip_spi_max_transfer_size;
 	ctlr->handle_err = rockchip_spi_handle_err;
-- 
2.17.1





From michal.simek at xilinx.com  Tue Apr 27 08:38:00 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 27 Apr 2021 09:38:00 +0200
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
 <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
Message-ID: <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>

Hi,

On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek at xilinx.com> wrote:
>>
>> Hi Andy,
>>
>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
>>> <lakshmis at xilinx.com> wrote:
>>>>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
>>>>> Sent: Friday, April 23, 2021 9:24 PM
>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>>>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
>>>
>>> ...
>>>
>>>>>> +config PINCTRL_ZYNQMP
>>>>>> +       tristate "Pinctrl driver for Xilinx ZynqMP"
>>>>>> +       depends on ZYNQMP_FIRMWARE
>>>>>> +       select PINMUX
>>>>>> +       select GENERIC_PINCONF
>>>>>> +       default ZYNQMP_FIRMWARE
>>>>>> +       help
>>>>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
>>>>>> +         This driver will query the pin information from the firmware
>>>>>> +         and allow configuring the pins.
>>>>>> +         Configuration can include the mux function to select on those
>>>>>> +         pin(s)/group(s), and various pin configuration parameters
>>>>>> +         such as pull-up, slew rate, etc.
>>>>>
>>>>> Missed module name.
>>>> Is this (module name) a configuration option in Kconfig?
>>>
>>> It's a text in a free form that sheds light on how the module will be
>>> named in case the user will choose "m".
>>
>> Is this described somewhere in documentation that module name should be
>> the part of symbol description? I was looking at pinctrl Kconfig and I
>> can't see any description like this there that's why I want to double
>> check.
> 
> I dunno if it is described, the group of maintainers require that for some time.
> I personally found this as a good practice.

I don't think it is a big deal to add it but it is a question if this
information is useful because module names should correspond target in
Makefile which can be considered as additional information.

> 
>> Also if this is a rule checkpatch should be extended to checking this.
> 
> There was a discussion at some point to add a check that help
> description shouldn't be less than 3 lines. Not sure what the outcome
> of it.

This check is likely there because I have definitely seen these messages
coming but never seen any name checking.

Thanks,
Michal



From jon.lin at rock-chips.com  Tue Apr 27 08:38:20 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:38:20 +0800
Subject: [PATCH v2 8/8] spi: rockchip: Support SPI_CS_HIGH
In-Reply-To: <20210427073820.31797-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
 <20210427073820.31797-1-jon.lin@rock-chips.com>
Message-ID: <20210427073820.31797-3-jon.lin@rock-chips.com>

1.Add standard spi-cs-high support
2.Refer to spi-controller.yaml for details

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 2b68691157d0..9d60c1b275e8 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -108,6 +108,8 @@
 #define CR0_OPM_MASTER				0x0
 #define CR0_OPM_SLAVE				0x1
 
+#define CR0_SOI_OFFSET				23
+
 #define CR0_MTM_OFFSET				0x21
 
 /* Bit fields in SER, 2bit */
@@ -238,7 +240,7 @@ static void rockchip_spi_set_cs(struct spi_device *spi, bool enable)
 {
 	struct spi_controller *ctlr = spi->controller;
 	struct rockchip_spi *rs = spi_controller_get_devdata(ctlr);
-	bool cs_asserted = !enable;
+	bool cs_asserted = spi->mode & SPI_CS_HIGH ? enable : !enable;
 
 	/* Return immediately for no-op */
 	if (cs_asserted == rs->cs_asserted[spi->chip_select])
@@ -509,6 +511,8 @@ static int rockchip_spi_config(struct rockchip_spi *rs,
 	cr0 |= (spi->mode & 0x3U) << CR0_SCPH_OFFSET;
 	if (spi->mode & SPI_LSB_FIRST)
 		cr0 |= CR0_FBM_LSB << CR0_FBM_OFFSET;
+	if (spi->mode & SPI_CS_HIGH)
+		cr0 |= BIT(spi->chip_select) << CR0_SOI_OFFSET;
 
 	if (xfer->rx_buf && xfer->tx_buf)
 		cr0 |= CR0_XFM_TR << CR0_XFM_OFFSET;
@@ -787,7 +791,7 @@ static int rockchip_spi_probe(struct platform_device *pdev)
 
 	ctlr->auto_runtime_pm = true;
 	ctlr->bus_num = pdev->id;
-	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP | SPI_LSB_FIRST;
+	ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP | SPI_LSB_FIRST | SPI_CS_HIGH;
 	if (slave_mode) {
 		ctlr->mode_bits |= SPI_NO_CS;
 		ctlr->slave_abort = rockchip_spi_slave_abort;
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:38:19 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:38:19 +0800
Subject: [PATCH v2 7/8] spi: rockchip: Add compatible string for rk3568
In-Reply-To: <20210427073820.31797-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
 <20210427073820.31797-1-jon.lin@rock-chips.com>
Message-ID: <20210427073820.31797-2-jon.lin@rock-chips.com>

Add compatible string for rv1126 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 drivers/spi/spi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 3b05c1ed6308..2b68691157d0 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -979,6 +979,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3328-spi", },
 	{ .compatible = "rockchip,rk3368-spi", },
 	{ .compatible = "rockchip,rk3399-spi", },
+	{ .compatible = "rockchip,rk3568-spi", },
 	{ .compatible = "rockchip,rv1108-spi", },
 	{ .compatible = "rockchip,rv1126-spi", },
 	{ },
-- 
2.17.1





From jon.lin at rock-chips.com  Tue Apr 27 08:38:18 2021
From: jon.lin at rock-chips.com (Jon Lin)
Date: Tue, 27 Apr 2021 15:38:18 +0800
Subject: [PATCH v2 6/8] dt-bindings: spi: spi-rockchip: add description for
 rk3568
In-Reply-To: <20210427073733.31419-1-jon.lin@rock-chips.com>
References: <20210427073733.31419-1-jon.lin@rock-chips.com>
Message-ID: <20210427073820.31797-1-jon.lin@rock-chips.com>

Add compatible string for rk3568 to applications for potential
applications.

Signed-off-by: Jon Lin <jon.lin at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
index 4ed5b72a8494..2d7957f9ae0a 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml
@@ -34,6 +34,7 @@ properties:
               - rockchip,rk3328-spi
               - rockchip,rk3368-spi
               - rockchip,rk3399-spi
+              - rockchip,rk3568-spi
           - const: rockchip,rk3066-spi
 
   reg:
-- 
2.17.1





From jbx6244 at gmail.com  Tue Apr 27 08:41:40 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Tue, 27 Apr 2021 09:41:40 +0200
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210425094439.25895-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
Message-ID: <16908f63-4e20-ba1b-3b5c-39b4c4db242b@gmail.com>



On 4/25/21 11:44 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipments. This patch
> add basic core dtsi file for it.
> 
> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> enalbe a special high-performacne PLL when high frequency is required. The
> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> 
>     cpu0: cpu at 0 {
>         device_type = "cpu";
>         compatible = "arm,cortex-a55";
>         reg = <0x0 0x0>;
>         clocks = <&scmi_clk 0>;
>     };
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
>  2 files changed, 3931 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> new file mode 100644
> index 000000000000..94ee3c2c38af
> --- /dev/null

[..]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..66cb50218ca1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,812 @@

[..]

> +
> +	pmugrf: syscon at fdc20000 {

> +		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";

TODO:

> +		reg = <0x0 0xfdc20000 0x0 0x10000>;
> +
> +		reboot_mode: reboot-mode {
> +			compatible = "syscon-reboot-mode";
> +			mode-bootloader = <BOOT_BL_DOWNLOAD>;
> +			mode-fastboot = <BOOT_FASTBOOT>;
> +			mode-loader = <BOOT_BL_DOWNLOAD>;
> +			mode-normal = <BOOT_NORMAL>;
> +			mode-recovery = <BOOT_RECOVERY>;
> +			offset = <0x200>;
> +		};
> +	};
> +
> +	grf: syscon at fdc60000 {

> +		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";

TODO:

> +		reg = <0x0 0xfdc60000 0x0 0x10000>;
> +	};
> +
> +	pmucru: clock-controller at fdd00000 {
> +		compatible = "rockchip,rk3568-pmucru";
> +		reg = <0x0 0xfdd00000 0x0 0x1000>;

> +		rockchip,grf = <&grf>;
> +		rockchip,pmugrf = <&pmugrf>;

clock-controller at fdd00000: 'rockchip,grf', 'rockchip,pmugrf' do not
match any of the regexes: 'pinctrl-[0-9]+'

Currently clk.c has only support for:

	ctx->grf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
						   "rockchip,grf");

Manufacturer tree:

	ctx->pmugrf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
						   "rockchip,pmugrf");
		case branch_muxpmugrf:
			clk = rockchip_clk_register_muxgrf(list->name,
				list->parent_names, list->num_parents,
				flags, ctx->pmugrf, list->muxdiv_offset,
				list->mux_shift, list->mux_width,
				list->mux_flags);
			break;


	MUXPMUGRF(SCLK_32K_IOE, "clk_32k_ioe", clk_32k_ioe_p,  0,
			RK3568_PMU_GRF_SOC_CON0, 0, 1, MFLAGS)

Do we need a fix?

> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	cru: clock-controller at fdd20000 {
> +		compatible = "rockchip,rk3568-cru";
> +		reg = <0x0 0xfdd20000 0x0 0x1000>;

> +		rockchip,grf = <&grf>;

clock-controller at fdd20000: 'assigned-clock-parents',
'assigned-clock-rates', 'assigned-clocks', 'rockchip,grf' do not match
any of the regexes:

Add more properties to rockchip,rk3568-cru.yaml

> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +
> +		assigned-clocks =
> +			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
> +			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
> +			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
> +			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
> +			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
> +			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
> +			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
> +			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
> +			<&cru ACLK_VOP>;
> +		assigned-clock-rates =
> +			<32768>, <200000000>,
> +			<100000000>, <1000000000>,
> +			<1188000000>, <150000000>,
> +			<100000000>, <500000000>,
> +			<400000000>, <150000000>,
> +			<100000000>, <300000000>,
> +			<150000000>, <1200000000>,
> +			<400000000>, <100000000>,
> +			<500000000>;
> +		assigned-clock-parents =
> +			<&pmucru CLK_RTC32K_FRAC>;
> +	};


From heiko at sntech.de  Tue Apr 27 08:48:41 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 27 Apr 2021 09:48:41 +0200
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <c2e96d99-3af5-3f22-78de-f6eff18b9c24@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <3d584cdc-020e-5aae-cae3-59ef45e64a9f@gmail.com>
 <c2e96d99-3af5-3f22-78de-f6eff18b9c24@rock-chips.com>
Message-ID: <2088315.NnIJQXNAa5@diego>

Hi,

Am Dienstag, 27. April 2021, 05:45:03 CEST schrieb Kever Yang:
> Hi Johan, Heiko,
> 
> On 2021/4/26 ??8:16, Johan Jonker wrote:
> > ===
> >
> > compatible = "rockchip,rk3568";
> > Maybe add this together with other rkXXXX SoCs to rockchip.yaml on top
> > of board list ???
> > Please advise.

I don't think so. I.e. the rockchip,rk3568 compatible is not supposed be
standing alone somewhere, but should always be combined with a board-
compatible. Same as the rk3568.dtsi should not be used alone but included
into a board dts.

And patch7 does this by adding the necessary entry to the board list.

> This rockchip.yaml is now describe boards without any sort, it would be 
> better to refactor and sort in two level:
> - soc level
> - board level base on the same soc.

The sorting in rockchip.yaml is supposed to be alphabetically by description.
(vendor + boardname)

My intention for this was to allow readers to find their board to get
the matching compatible - and I like that ordering somehow ;-) .

So I don't think there are bigger changes necessary to rockchip.yaml


Heiko




From heiko at sntech.de  Tue Apr 27 08:50:51 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 27 Apr 2021 09:50:51 +0200
Subject: [PATCH v2 7/7] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210425094455.25949-1-cl@rock-chips.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094455.25949-1-cl@rock-chips.com>
Message-ID: <3689795.CpGBqz00pN@diego>

Am Sonntag, 25. April 2021, 11:44:55 CEST schrieb cl at rock-chips.com:
> From: Liang Chen <cl at rock-chips.com>
> 
> This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
> add uart/emmc/i2c/rk809 node for basic function.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/arm/rockchip.yaml     |  5 ++
>  arch/arm64/boot/dts/rockchip/Makefile         |  1 +
>  .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 80 +++++++++++++++++++
>  3 files changed, 86 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
> index 4a6f772c1043..95ab9714af44 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.yaml
> +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
> @@ -565,6 +565,11 @@ properties:
>            - const: rockchip,rk3399-evb
>            - const: rockchip,rk3399
>  
> +      - description: Rockchip RK3568 Evaluation board

please sort this below the rk3399 stuff in the file
( 3568 is a bigger number than 3399 )

Thanks
Heiko




From snawrocki at kernel.org  Tue Apr 27 09:06:31 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 10:06:31 +0200
Subject: [PATCH 57/78] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <20210426151224.2b677d1b@coco.lan>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <091915bb1cbec13b566d129f85ae229fcb92e2e4.1619191723.git.mchehab+huawei@kernel.org>
 <45068e81-8f9b-fea8-b7bc-bdd0443ba7e6@kernel.org>
 <20210426151224.2b677d1b@coco.lan>
Message-ID: <1a98b4b7-78c2-810d-a4ba-762c1a9576b3@kernel.org>

On 26.04.2021 15:12, Mauro Carvalho Chehab wrote:
> Em Sun, 25 Apr 2021 22:57:25 +0200
> Sylwester Nawrocki <snawrocki at kernel.org> escreveu:
> 
>> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
>>> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
>>> added pm_runtime_resume_and_get() in order to automatically handle
>>> dev->power.usage_count decrement on errors.
>>>
>>> Use the new API, in order to cleanup the error check logic.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

>>> diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
>>> index 972d9601d236..bca35866cc74 100644
>>> --- a/drivers/media/platform/exynos4-is/fimc-is.c
>>> +++ b/drivers/media/platform/exynos4-is/fimc-is.c
>>> @@ -828,7 +828,7 @@ static int fimc_is_probe(struct platform_device *pdev)
>>>    			goto err_irq;
>>>    	}
>>>    
>>> -	ret = pm_runtime_get_sync(dev);
>>> +	ret = pm_runtime_resume_and_get(dev);
>>>    	if (ret < 0)
>>>    		goto err_pm;
>>
>> It seems you intended to use err_suspend label here. We don't need
>> a new label though, instead of err_pm we can jump to err_irq when
>> pm_runtime_resume_and_get() fails.
> 
> Thanks! Will fix at the next version.
> 
>> Note that when runtime PM is
>> disabled pm_runtime_resume_and_get() always returns 0.
> 
> Ok, but there are a couple of conditions at rpm_resume() function
> at drivers/base/power/runtime.c (which is the code that actually
> handles those PM macros) that could make it to return errors,
> which are independent on the PM callbacks, like those:
> 
>          if (dev->power.runtime_error)
>                  retval = -EINVAL;
>          else if (dev->power.disable_depth > 0)
>                  retval = -EACCES;
> 
> and more might be added as the PM core changes.

Right, I looked only at !CONFIG_PM case, this is what the "if (!pm_runtime_enabled(dev))"
test and explicit fimc_is_runtime_{resume,suspend} calls were originally for.
Agreed, better not to rely too much on internal implementation as there is
no specific guarantees about return value at the API documentation.

Regards,
Sylwester

>>> @@ -862,6 +862,7 @@ static int fimc_is_probe(struct platform_device *pdev)
>>>    	fimc_is_unregister_subdevs(is);
>>>    err_pm:
>>>    	pm_runtime_put_noidle(dev);
>>> +err_suspend:
>>>    	if (!pm_runtime_enabled(dev))
>>>    		fimc_is_runtime_suspend(dev);
>>>    err_irq:
>>


From heiko at sntech.de  Tue Apr 27 09:07:00 2021
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 27 Apr 2021 10:07:00 +0200
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <16908f63-4e20-ba1b-3b5c-39b4c4db242b@gmail.com>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
 <16908f63-4e20-ba1b-3b5c-39b4c4db242b@gmail.com>
Message-ID: <6618564.gtipl9YmvM@diego>

Am Dienstag, 27. April 2021, 09:41:40 CEST schrieb Johan Jonker:
> 
> On 4/25/21 11:44 AM, cl at rock-chips.com wrote:
> > From: Liang Chen <cl at rock-chips.com>
> > 
> > RK3568 is a high-performance and low power quad-core application processor
> > designed for personal mobile internet device and AIoT equipments. This patch
> > add basic core dtsi file for it.
> > 
> > We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> > kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> > enalbe a special high-performacne PLL when high frequency is required. The
> > smci_clk code is in ATF, and clkid for cpu is 0, as below:
> > 
> >     cpu0: cpu at 0 {
> >         device_type = "cpu";
> >         compatible = "arm,cortex-a55";
> >         reg = <0x0 0x0>;
> >         clocks = <&scmi_clk 0>;
> >     };
> > 
> > Signed-off-by: Liang Chen <cl at rock-chips.com>
> > ---
> >  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
> >  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
> >  2 files changed, 3931 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> > new file mode 100644
> > index 000000000000..94ee3c2c38af
> > --- /dev/null
> 
> [..]
> 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > new file mode 100644
> > index 000000000000..66cb50218ca1
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > @@ -0,0 +1,812 @@
> 
> [..]
> 
> > +
> > +	pmugrf: syscon at fdc20000 {
> 
> > +		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
> 
> TODO:
> 
> > +		reg = <0x0 0xfdc20000 0x0 0x10000>;
> > +
> > +		reboot_mode: reboot-mode {
> > +			compatible = "syscon-reboot-mode";
> > +			mode-bootloader = <BOOT_BL_DOWNLOAD>;
> > +			mode-fastboot = <BOOT_FASTBOOT>;
> > +			mode-loader = <BOOT_BL_DOWNLOAD>;
> > +			mode-normal = <BOOT_NORMAL>;
> > +			mode-recovery = <BOOT_RECOVERY>;
> > +			offset = <0x200>;
> > +		};
> > +	};
> > +
> > +	grf: syscon at fdc60000 {
> 
> > +		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
> 
> TODO:
> 
> > +		reg = <0x0 0xfdc60000 0x0 0x10000>;
> > +	};
> > +
> > +	pmucru: clock-controller at fdd00000 {
> > +		compatible = "rockchip,rk3568-pmucru";
> > +		reg = <0x0 0xfdd00000 0x0 0x1000>;
> 
> > +		rockchip,grf = <&grf>;
> > +		rockchip,pmugrf = <&pmugrf>;
> 
> clock-controller at fdd00000: 'rockchip,grf', 'rockchip,pmugrf' do not
> match any of the regexes: 'pinctrl-[0-9]+'
> 
> Currently clk.c has only support for:
> 
> 	ctx->grf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
> 						   "rockchip,grf");
> 
> Manufacturer tree:
> 
> 	ctx->pmugrf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
> 						   "rockchip,pmugrf");
> 		case branch_muxpmugrf:
> 			clk = rockchip_clk_register_muxgrf(list->name,
> 				list->parent_names, list->num_parents,
> 				flags, ctx->pmugrf, list->muxdiv_offset,
> 				list->mux_shift, list->mux_width,
> 				list->mux_flags);
> 			break;
> 
> 
> 	MUXPMUGRF(SCLK_32K_IOE, "clk_32k_ioe", clk_32k_ioe_p,  0,
> 			RK3568_PMU_GRF_SOC_CON0, 0, 1, MFLAGS)

(1) drop the rockchip,pmugrf property please
(2) as I see it, we will only need the rockchip,grf property.

For main clock controller grf points to main grf
For pmu clock controller grf points to pmugrf

Each clock controller has its own associated grf.

I really see no case where main-clk would need to access the pmugrf
same as pmu-clk would should not need to access the main grf, as the
split into main-{clk,grf} + pmu-{clk,grf} is probably a for power-management
reasons to separate different power-areas, the driver should also not
cross this barrier anyway ;-) .

Same as, if a clk uses the pmugrf it is a pmu-based clock, if it uses the
main grf, it should live in the main clock driver.

And as expected the clk_32k_ioe is already defined in the pmuclk
part of the driver ;-)


Heiko


> > +		#clock-cells = <1>;
> > +		#reset-cells = <1>;
> > +	};
> > +
> > +	cru: clock-controller at fdd20000 {
> > +		compatible = "rockchip,rk3568-cru";
> > +		reg = <0x0 0xfdd20000 0x0 0x1000>;
> 
> > +		rockchip,grf = <&grf>;
> 
> clock-controller at fdd20000: 'assigned-clock-parents',
> 'assigned-clock-rates', 'assigned-clocks', 'rockchip,grf' do not match
> any of the regexes:
> 
> Add more properties to rockchip,rk3568-cru.yaml
> 
> > +		#clock-cells = <1>;
> > +		#reset-cells = <1>;
> > +
> > +		assigned-clocks =
> > +			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
> > +			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
> > +			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
> > +			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
> > +			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
> > +			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
> > +			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
> > +			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
> > +			<&cru ACLK_VOP>;
> > +		assigned-clock-rates =
> > +			<32768>, <200000000>,
> > +			<100000000>, <1000000000>,
> > +			<1188000000>, <150000000>,
> > +			<100000000>, <500000000>,
> > +			<400000000>, <150000000>,
> > +			<100000000>, <300000000>,
> > +			<150000000>, <1200000000>,
> > +			<400000000>, <100000000>,
> > +			<500000000>;
> > +		assigned-clock-parents =
> > +			<&pmucru CLK_RTC32K_FRAC>;
> > +	};
> 






From s.nawrocki at samsung.com  Tue Apr 27 09:18:12 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 10:18:12 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>

On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
>  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 9f41c2e7097a..9d5841194f6b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
>  	int i;
>  
> -	pm_runtime_get_sync(&pdev->dev);
> +	pm_runtime_resume_and_get(&pdev->dev);
>  
>  	gsc_unregister_m2m_device(gsc);
>  	v4l2_device_unregister(&gsc->v4l2_dev);
> @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
>  	for (i = 0; i < gsc->num_clocks; i++)
>  		clk_disable_unprepare(gsc->clock[i]);
>  
> -	pm_runtime_put_noidle(&pdev->dev);

If we do this then the device usage count will not get decremented
after the pm_runtime_resume_and_get() call above and after driver
unload/load cycle it will not be possible to suspend the device.
I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
works better in that case.

Regards,
Sylwester

>  	pm_runtime_disable(&pdev->dev);
>  
>  	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name


From maz at kernel.org  Tue Apr 27 09:30:09 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 27 Apr 2021 09:30:09 +0100
Subject: [PATCH 2/9] ARM: PXA: Kill use of irq_create_strict_mappings()
In-Reply-To: <20210426223942.GA213931@roeck-us.net>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-3-maz@kernel.org>
 <20210426223942.GA213931@roeck-us.net>
Message-ID: <87o8e0nn8u.wl-maz@kernel.org>

Hi Guenter,

Thanks for the heads up.

On Mon, 26 Apr 2021 23:39:42 +0100,
Guenter Roeck <linux at roeck-us.net> wrote:
> 
> On Tue, Apr 06, 2021 at 10:35:50AM +0100, Marc Zyngier wrote:
> > irq_create_strict_mappings() is a poor way to allow the use of
> > a linear IRQ domain as a legacy one. Let's be upfront about
> > it and use a legacy domain when appropriate.
> > 
> > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > ---
> 
> When running the "mainstone" qemu emulation, this patch results
> in many (32, actually) runtime warnings such as the following.
> 
> [    0.528272] ------------[ cut here ]------------
> [    0.528285] WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:550 irq_domain_associate+0x194/0x1f0
> [    0.528315] error: virq335 is not allocated

[...]

This looks like a case of CONFIG_SPARSE_IRQ, combined with a lack of
brain engagement. I've come up with the following patch, which lets
the kernel boot in QEMU without screaming (other than the lack of a
rootfs...).

Please let me know if this helps.

Thanks,

	M.

From 4d7f6ddbbfdff1c9f029bafca79020d3294dc32c Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz at kernel.org>
Date: Tue, 27 Apr 2021 09:00:28 +0100
Subject: [PATCH] ARM: PXA: Fix cplds irqdesc allocation when using legacy mode

The Mainstone PXA platform uses CONFIG_SPARSE_IRQ, and thus we
cannot rely on the irq descriptors to be readilly allocated
before creating the irqdomain in legacy mode. The kernel then
complains loudly about not being able to associate the interrupt
in the domain -- can't blame it.

Fix it by allocating the irqdescs upfront in the legacy case.

Fixes: b68761da0111 ("ARM: PXA: Kill use of irq_create_strict_mappings()")
Reported-by: Guenter Roeck <linux at roeck-us.net>
Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm/mach-pxa/pxa_cplds_irqs.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/pxa_cplds_irqs.c b/arch/arm/mach-pxa/pxa_cplds_irqs.c
index ec0d9b094744..bddfc7cd5d40 100644
--- a/arch/arm/mach-pxa/pxa_cplds_irqs.c
+++ b/arch/arm/mach-pxa/pxa_cplds_irqs.c
@@ -121,8 +121,13 @@ static int cplds_probe(struct platform_device *pdev)
 		return fpga->irq;
 
 	base_irq = platform_get_irq(pdev, 1);
-	if (base_irq < 0)
+	if (base_irq < 0) {
 		base_irq = 0;
+	} else {
+		ret = devm_irq_alloc_descs(&pdev->dev, base_irq, base_irq, CPLDS_NB_IRQ, 0);
+		if (ret < 0)
+			return ret;
+	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	fpga->base = devm_ioremap_resource(&pdev->dev, res);
-- 
2.30.2


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


From andy.shevchenko at gmail.com  Tue Apr 27 09:39:06 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 27 Apr 2021 11:39:06 +0300
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
 <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
 <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>
Message-ID: <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>

On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <michal.simek at xilinx.com> wrote:
> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek at xilinx.com> wrote:
> >> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> >>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> >>> <lakshmis at xilinx.com> wrote:
> >>>>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
> >>>>> Sent: Friday, April 23, 2021 9:24 PM
> >>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>>>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:

...

> >>>>>> +       help
> >>>>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> >>>>>> +         This driver will query the pin information from the firmware
> >>>>>> +         and allow configuring the pins.
> >>>>>> +         Configuration can include the mux function to select on those
> >>>>>> +         pin(s)/group(s), and various pin configuration parameters
> >>>>>> +         such as pull-up, slew rate, etc.
> >>>>>
> >>>>> Missed module name.
> >>>> Is this (module name) a configuration option in Kconfig?
> >>>
> >>> It's a text in a free form that sheds light on how the module will be
> >>> named in case the user will choose "m".
> >>
> >> Is this described somewhere in documentation that module name should be
> >> the part of symbol description? I was looking at pinctrl Kconfig and I
> >> can't see any description like this there that's why I want to double
> >> check.
> >
> > I dunno if it is described, the group of maintainers require that for some time.
> > I personally found this as a good practice.
>
> I don't think it is a big deal to add it but it is a question if this
> information is useful because module names should correspond target in
> Makefile which can be considered as additional information.

For you as a *developer* ? yes, for me as a *user* ? no. You are
telling me something like "hey, if you want to know more you must dig
into kernel sources". No, this is not how we should treat users,
should we?


> >> Also if this is a rule checkpatch should be extended to checking this.
> >
> > There was a discussion at some point to add a check that help
> > description shouldn't be less than 3 lines. Not sure what the outcome
> > of it.
>
> This check is likely there because I have definitely seen these messages
> coming but never seen any name checking.

Yeah, it was about insisting developers to be more verbose in the help
descriptions, but the name is, as I said, an activity "de facto"
rather than "de jure". Just look around for the latest new driver
contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
provide their help descriptions (I admit that not everybody follows
that practice).

-- 
With Best Regards,
Andy Shevchenko


From xiaoning.wang at nxp.com  Tue Apr 27 09:52:11 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue, 27 Apr 2021 16:52:11 +0800
Subject: [PATCH] spi: imx: remove CLK calculation and divider in slave mode
Message-ID: <20210427085211.299756-1-xiaoning.wang@nxp.com>

In the slave mode, the clock signal is controlled by the master.
The slave does not need to calculate and configure the clock
frequency division. The slave can directly use the root clock
to sample the SCL signal.
Therefore, remove the calculation and frequency division
function of the clock in the slave mode.

Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
---
Please remove the patch(4df2f5e1372e spi: imx: add a check for speed_hz before
calculating the clock) first and then apply this patch.
Sorry about this. Thank you!
---
 drivers/spi/spi-imx.c | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 24ba7ab1b05d..68cdd87404f6 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -33,6 +33,7 @@ module_param(use_dma, bool, 0644);
 MODULE_PARM_DESC(use_dma, "Enable usage of DMA when available (default)");
 
 #define MXC_RPM_TIMEOUT		2000 /* 2000ms */
+#define MXC_DEFAULT_SPEED	500000 /* 500KHz */
 
 #define MXC_CSPIRXDATA		0x00
 #define MXC_CSPITXDATA		0x04
@@ -599,8 +600,10 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	/* set clock speed */
 	ctrl &= ~(0xf << MX51_ECSPI_CTRL_POSTDIV_OFFSET |
 		  0xf << MX51_ECSPI_CTRL_PREDIV_OFFSET);
-	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
-	spi_imx->spi_bus_clk = clk;
+	if (!spi_imx->slave_mode) {
+		ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
+		spi_imx->spi_bus_clk = clk;
+	}
 
 	if (spi_imx->usedma)
 		ctrl |= MX51_ECSPI_CTRL_SMC;
@@ -717,9 +720,11 @@ static int mx31_prepare_transfer(struct spi_imx_data *spi_imx,
 	unsigned int reg = MX31_CSPICTRL_ENABLE | MX31_CSPICTRL_MASTER;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
-		MX31_CSPICTRL_DR_SHIFT;
-	spi_imx->spi_bus_clk = clk;
+	if (!spi_imx->slave_mode) {
+		reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+			MX31_CSPICTRL_DR_SHIFT;
+		spi_imx->spi_bus_clk = clk;
+	}
 
 	if (is_imx35_cspi(spi_imx)) {
 		reg |= (spi_imx->bits_per_word - 1) << MX35_CSPICTRL_BL_SHIFT;
@@ -823,9 +828,11 @@ static int mx21_prepare_transfer(struct spi_imx_data *spi_imx,
 	unsigned int max = is_imx27_cspi(spi_imx) ? 16 : 18;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, t->speed_hz, max, &clk)
-		<< MX21_CSPICTRL_DR_SHIFT;
-	spi_imx->spi_bus_clk = clk;
+	if (!spi_imx->slave_mode) {
+		reg |= spi_imx_clkdiv_1(spi_imx->spi_clk, t->speed_hz, max, &clk)
+			<< MX21_CSPICTRL_DR_SHIFT;
+		spi_imx->spi_bus_clk = clk;
+	}
 
 	reg |= spi_imx->bits_per_word - 1;
 
@@ -898,9 +905,11 @@ static int mx1_prepare_transfer(struct spi_imx_data *spi_imx,
 	unsigned int reg = MX1_CSPICTRL_ENABLE | MX1_CSPICTRL_MASTER;
 	unsigned int clk;
 
-	reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
-		MX1_CSPICTRL_DR_SHIFT;
-	spi_imx->spi_bus_clk = clk;
+	if (!spi_imx->slave_mode) {
+		reg |= spi_imx_clkdiv_2(spi_imx->spi_clk, t->speed_hz, &clk) <<
+			MX1_CSPICTRL_DR_SHIFT;
+		spi_imx->spi_bus_clk = clk;
+	}
 
 	reg |= spi_imx->bits_per_word - 1;
 
@@ -1485,8 +1494,6 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	transfer->effective_speed_hz = spi_imx->spi_bus_clk;
-
 	/* flush rxfifo before transfer */
 	while (spi_imx->devtype_data->rx_available(spi_imx))
 		readl(spi_imx->base + MXC_CSPIRXDATA);
@@ -1494,6 +1501,8 @@ static int spi_imx_transfer(struct spi_device *spi,
 	if (spi_imx->slave_mode)
 		return spi_imx_pio_transfer_slave(spi, transfer);
 
+	transfer->effective_speed_hz = spi_imx->spi_bus_clk;
+
 	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
 
@@ -1593,6 +1602,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	spi_imx->bitbang.master = master;
 	spi_imx->dev = &pdev->dev;
 	spi_imx->slave_mode = slave_mode;
+	spi_imx->spi_bus_clk = MXC_DEFAULT_SPEED;
 
 	spi_imx->devtype_data = devtype_data;
 
-- 
2.25.1



From ping.bai at nxp.com  Tue Apr 27 09:55:36 2021
From: ping.bai at nxp.com (Jacky Bai)
Date: Tue, 27 Apr 2021 08:55:36 +0000
Subject: [PATCH 1/2] thermal: imx_sc: add missing of_node_put for loop
 iteration
In-Reply-To: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>
References: <20210425174831.164332-1-krzysztof.kozlowski@canonical.com>
Message-ID: <DBBPR04MB79307DF87746E3D5540910FD87419@DBBPR04MB7930.eurprd04.prod.outlook.com>

> Subject: [PATCH 1/2] thermal: imx_sc: add missing of_node_put for loop
> iteration
> 
> Early exits from for_each_available_child_of_node() should decrement the
> node reference counter.  Reported by Coccinelle:
> 
>   drivers/thermal/imx_sc_thermal.c:93:1-33: WARNING:
>     Function "for_each_available_child_of_node" should have of_node_put()
> before return around line 97.
> 

Reviewed-by: Jacky Bai <ping.bai at nxp.com>

BR
Jacky Bai

> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> ---
>  drivers/thermal/imx_sc_thermal.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/thermal/imx_sc_thermal.c
> b/drivers/thermal/imx_sc_thermal.c
> index b01d28eca7ee..8d76dbfde6a9 100644
> --- a/drivers/thermal/imx_sc_thermal.c
> +++ b/drivers/thermal/imx_sc_thermal.c
> @@ -93,6 +93,7 @@ static int imx_sc_thermal_probe(struct platform_device
> *pdev)
>  	for_each_available_child_of_node(np, child) {
>  		sensor = devm_kzalloc(&pdev->dev, sizeof(*sensor), GFP_KERNEL);
>  		if (!sensor) {
> +			of_node_put(child);
>  			of_node_put(sensor_np);
>  			return -ENOMEM;
>  		}
> @@ -104,6 +105,7 @@ static int imx_sc_thermal_probe(struct
> platform_device *pdev)
>  			dev_err(&pdev->dev,
>  				"failed to get valid sensor resource id: %d\n",
>  				ret);
> +			of_node_put(child);
>  			break;
>  		}
> 
> @@ -114,6 +116,7 @@ static int imx_sc_thermal_probe(struct
> platform_device *pdev)
>  		if (IS_ERR(sensor->tzd)) {
>  			dev_err(&pdev->dev, "failed to register thermal zone\n");
>  			ret = PTR_ERR(sensor->tzd);
> +			of_node_put(child);
>  			break;
>  		}
> 
> --
> 2.25.1


From pavel at ucw.cz  Tue Apr 27 10:11:33 2021
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 27 Apr 2021 11:11:33 +0200
Subject: [PATCH] arm64: dts: rockchip: rename LED label for NanoPi R4S
In-Reply-To: <20210426114652.29542-1-cnsztl@gmail.com>
References: <20210426114652.29542-1-cnsztl@gmail.com>
Message-ID: <20210427091132.GA9373@amd>

On Mon 2021-04-26 19:46:52, Tianling Shen wrote:
> However "sys" is not a valid function, and it is always on.
> Let's keep existing functions.
> 
> Fixes: db792e9adbf85f ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S")
> 

Acked-by: Pavel Machek <pavel at ucw.cz>

-- 
http://www.livejournal.com/~pavelmachek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210427/53c626fb/attachment-0001.sig>

From s.nawrocki at samsung.com  Tue Apr 27 10:14:36 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 11:14:36 +0200
Subject: [PATCH 21/78] media: s5p-jpeg: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <01560ba01a8e6ecb0e2e525e9b47a544c04f735c.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064539eucas1p2f05b6e94d755623d4e70a21f0a681c94@eucas1p2.samsung.com>
 <01560ba01a8e6ecb0e2e525e9b47a544c04f735c.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <d5509bf0-78b6-dde8-5925-ea07d78c7ece@samsung.com>

On 24.04.2021 08:44, Mauro Carvalho Chehab wrote:
> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> replace it by the new pm_runtime_resume_and_get(), introduced by:

s/replace/Replace

> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.

Thank you for the patch. I'm not sure if that could cause any memory
leaks, for sure not optimal power handling for the device.

> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From daniel.vetter at ffwll.ch  Tue Apr 27 10:20:17 2021
From: daniel.vetter at ffwll.ch (Daniel Vetter)
Date: Tue, 27 Apr 2021 11:20:17 +0200
Subject: [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210427092018.832258-1-daniel.vetter@ffwll.ch>
References: <20210427092018.832258-1-daniel.vetter@ffwll.ch>
Message-ID: <20210427092018.832258-7-daniel.vetter@ffwll.ch>

Since

commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Yannick Fertre <yannick.fertre at foss.st.com>
Cc: Philippe Cornu <philippe.cornu at foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard at linaro.org>
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/gpu/drm/stm/ltdc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
 		goto err;
 	}
 
-	ddev->mode_config.allow_fb_modifiers = true;
-
 	ret = ltdc_crtc_init(ddev, crtc);
 	if (ret) {
 		DRM_ERROR("Failed to init crtc\n");
-- 
2.31.0



From mchehab+huawei at kernel.org  Tue Apr 27 10:30:55 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 11:30:55 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
Message-ID: <20210427113055.745d0560@coco.lan>

Em Tue, 27 Apr 2021 10:18:12 +0200
Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:

> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
> > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> > added pm_runtime_resume_and_get() in order to automatically handle
> > dev->power.usage_count decrement on errors.
> > 
> > Use the new API, in order to cleanup the error check logic.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> > ---
> >  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
> >  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> > index 9f41c2e7097a..9d5841194f6b 100644
> > --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> > +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> > @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
> >  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
> >  	int i;
> >  
> > -	pm_runtime_get_sync(&pdev->dev);
> > +	pm_runtime_resume_and_get(&pdev->dev);
> >  
> >  	gsc_unregister_m2m_device(gsc);
> >  	v4l2_device_unregister(&gsc->v4l2_dev);
> > @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
> >  	for (i = 0; i < gsc->num_clocks; i++)
> >  		clk_disable_unprepare(gsc->clock[i]);
> >  
> > -	pm_runtime_put_noidle(&pdev->dev);  
> 
> If we do this then the device usage count will not get decremented
> after the pm_runtime_resume_and_get() call above and after driver
> unload/load cycle it will not be possible to suspend the device.
> I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
> works better in that case.

Good point.

Actually, I don't see any reason why to call a PM resume
function - either being pm_runtime_get_sync() or
pm_runtime_resume_and_get().

The code there could simply be:

    static int gsc_remove(struct platform_device *pdev)
    {
        struct gsc_dev *gsc = platform_get_drvdata(pdev);
        int i;

        gsc_unregister_m2m_device(gsc);
        v4l2_device_unregister(&gsc->v4l2_dev);

        vb2_dma_contig_clear_max_seg_size(&pdev->dev);
        for (i = 0; i < gsc->num_clocks; i++)
                clk_disable_unprepare(gsc->clock[i]);

        pm_runtime_disable(&pdev->dev);

        dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
        return 0;
    }

Eventually also adding:
	pm_runtime_suspended(&pdev->dev);

just after pm_runtime_disable().

Regards,
Mauro


From s.nawrocki at samsung.com  Tue Apr 27 10:36:06 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 11:36:06 +0200
Subject: [PATCH 73/78] media: s5p-mfc: use pm_runtime_resume_and_get()
In-Reply-To: <f01c6e2c5e61bc198443ecb82cd8a6eb6961b6d7.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064654eucas1p21309858fa610e3cb3a796fabe685e457@eucas1p2.samsung.com>
 <f01c6e2c5e61bc198443ecb82cd8a6eb6961b6d7.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <b7fcbc42-a78c-50cb-803f-cdd99cd26404@samsung.com>

On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Thank you for the patch.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From mchehab+huawei at kernel.org  Tue Apr 27 10:42:35 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 11:42:35 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <20210427113055.745d0560@coco.lan>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
 <20210427113055.745d0560@coco.lan>
Message-ID: <20210427114235.45a7b2a4@coco.lan>

Em Tue, 27 Apr 2021 11:30:55 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:

> Em Tue, 27 Apr 2021 10:18:12 +0200
> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
> 
> > On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:  
> > > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> > > added pm_runtime_resume_and_get() in order to automatically handle
> > > dev->power.usage_count decrement on errors.
> > > 
> > > Use the new API, in order to cleanup the error check logic.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> > > ---
> > >  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
> > >  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
> > >  2 files changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> > > index 9f41c2e7097a..9d5841194f6b 100644
> > > --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> > > +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> > > @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
> > >  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
> > >  	int i;
> > >  
> > > -	pm_runtime_get_sync(&pdev->dev);
> > > +	pm_runtime_resume_and_get(&pdev->dev);
> > >  
> > >  	gsc_unregister_m2m_device(gsc);
> > >  	v4l2_device_unregister(&gsc->v4l2_dev);
> > > @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
> > >  	for (i = 0; i < gsc->num_clocks; i++)
> > >  		clk_disable_unprepare(gsc->clock[i]);
> > >  
> > > -	pm_runtime_put_noidle(&pdev->dev);    
> > 
> > If we do this then the device usage count will not get decremented
> > after the pm_runtime_resume_and_get() call above and after driver
> > unload/load cycle it will not be possible to suspend the device.
> > I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
> > works better in that case.  
> 
> Good point.
> 
> Actually, I don't see any reason why to call a PM resume
> function - either being pm_runtime_get_sync() or
> pm_runtime_resume_and_get().
> 
> The code there could simply be:
> 
>     static int gsc_remove(struct platform_device *pdev)
>     {
>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
>         int i;
> 
>         gsc_unregister_m2m_device(gsc);
>         v4l2_device_unregister(&gsc->v4l2_dev);
> 
>         vb2_dma_contig_clear_max_seg_size(&pdev->dev);
>         for (i = 0; i < gsc->num_clocks; i++)
>                 clk_disable_unprepare(gsc->clock[i]);
> 
>         pm_runtime_disable(&pdev->dev);
> 
>         dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
>         return 0;
>     }
> 
> Eventually also adding:
> 	pm_runtime_suspended(&pdev->dev);

In time: I actually meant:

	pm_runtime_set_suspended(&pdev->dev);

but after double-checking the PM runtime code, it sounds to me that
just calling pm_runtime_disable() would be enough. Not 100% sure
here. Btw, some media drivers call it after pm_runtime_disable(),
while others don't do.

Thanks,
Mauro


From michal.simek at xilinx.com  Tue Apr 27 10:59:40 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 27 Apr 2021 11:59:40 +0200
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
 <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
 <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>
 <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>
Message-ID: <67cef577-0965-2fad-7d61-17181d692003@xilinx.com>



On 4/27/21 10:39 AM, Andy Shevchenko wrote:
> On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <michal.simek at xilinx.com> wrote:
>> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
>>> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek at xilinx.com> wrote:
>>>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
>>>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
>>>>> <lakshmis at xilinx.com> wrote:
>>>>>>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
>>>>>>> Sent: Friday, April 23, 2021 9:24 PM
>>>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
>>>>>>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> 
> ...
> 
>>>>>>>> +       help
>>>>>>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
>>>>>>>> +         This driver will query the pin information from the firmware
>>>>>>>> +         and allow configuring the pins.
>>>>>>>> +         Configuration can include the mux function to select on those
>>>>>>>> +         pin(s)/group(s), and various pin configuration parameters
>>>>>>>> +         such as pull-up, slew rate, etc.
>>>>>>>
>>>>>>> Missed module name.
>>>>>> Is this (module name) a configuration option in Kconfig?
>>>>>
>>>>> It's a text in a free form that sheds light on how the module will be
>>>>> named in case the user will choose "m".
>>>>
>>>> Is this described somewhere in documentation that module name should be
>>>> the part of symbol description? I was looking at pinctrl Kconfig and I
>>>> can't see any description like this there that's why I want to double
>>>> check.
>>>
>>> I dunno if it is described, the group of maintainers require that for some time.
>>> I personally found this as a good practice.
>>
>> I don't think it is a big deal to add it but it is a question if this
>> information is useful because module names should correspond target in
>> Makefile which can be considered as additional information.
> 
> For you as a *developer* ? yes, for me as a *user* ? no. You are
> telling me something like "hey, if you want to know more you must dig
> into kernel sources". No, this is not how we should treat users,
> should we?

As I said it is not big deal but we should care about consistency on
this. Adding Joe here if we can extend checkpatch to report a warning
about it. Then it will be visible and can be checked.

>>>> Also if this is a rule checkpatch should be extended to checking this.
>>>
>>> There was a discussion at some point to add a check that help
>>> description shouldn't be less than 3 lines. Not sure what the outcome
>>> of it.
>>
>> This check is likely there because I have definitely seen these messages
>> coming but never seen any name checking.
> 
> Yeah, it was about insisting developers to be more verbose in the help
> descriptions, but the name is, as I said, an activity "de facto"
> rather than "de jure". Just look around for the latest new driver
> contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
> provide their help descriptions (I admit that not everybody follows
> that practice).
> 

I have seen some on linux-next but really when any rule/recommendation
like this is introduced it should be more visible and checked by
standard tools (checkpatch or by bots) then people will start to do it.

Thanks,
Michal



From suzuki.poulose at arm.com  Tue Apr 27 11:00:51 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 27 Apr 2021 11:00:51 +0100
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync
 buffer.
In-Reply-To: <20210427034531.GA328795@leoy-ThinkPad-X240s>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-2-daniel.kiss@arm.com>
 <bd9de3ab-14f7-2659-0dc8-619bca0f52d7@arm.com>
 <20210427034531.GA328795@leoy-ThinkPad-X240s>
Message-ID: <f957c2d3-9265-1e84-49d3-dc38147816ca@arm.com>

On 27/04/2021 04:45, Leo Yan wrote:
> On Mon, Apr 26, 2021 at 11:40:44AM +0100, Suzuki Kuruppassery Poulose wrote:
> 
> [...]
> 
>>> @@ -1442,7 +1442,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>>>    {
>>>    	long bytes;
>>>    	long pg_idx, pg_offset;
>>> -	unsigned long head = etr_perf->head;
>>> +	unsigned long head;
>>>    	char **dst_pages, *src_buf;
>>>    	struct etr_buf *etr_buf = etr_perf->etr_buf;
>>> @@ -1465,7 +1465,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>>>    		bytes = tmc_etr_buf_get_data(etr_buf, src_offset, to_copy,
>>>    					     &src_buf);
>>>    		if (WARN_ON_ONCE(bytes <= 0))
>>> -			break;
>>> +			return;
>>>    		bytes = min(bytes, (long)(PAGE_SIZE - pg_offset));
>>>    		memcpy(dst_pages[pg_idx] + pg_offset, src_buf, bytes);
>>> @@ -1483,6 +1483,7 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
>>>    		/* Move source pointers */
>>>    		src_offset += bytes;
>>>    	}
>>> +	etr_perf->head = (pg_idx << PAGE_SHIFT) + pg_offset;
>>
>>
>> Looking at this patch, I feel the driver is doing a couple wrong things
>> already.
>>
>> 1) We initialise etr_perf->head every time the ETR enable is called,
>> irrespective of whether we actually try to enable the Hardware. e.g,
>>
>> etm_0 on -> .. -> enable_etr :
>> etr_perf->head = <head of the handle_0>
>>    enable_hw()
>>
>> emt_1 on -> ... -> enable_etr:
>>    etr_perf->head = <head of the handle_1>
>>    already_enabled, skip enable_hw()
>>
>> etm_2 on -> ... -> enable_etr:
>>    etr_perf->head = <head of the handle_2>
>>    already_enable, skip enable_hw()...
>>
>>
>> This doesn't look correct as we don't know which handle is going to get the
>> data. This looks pointless.
> 
> I'd like to convert mapping into below diagram (for system wide trace):
> 
>    CPU0: AUX RB (perf_output_handle_0) -> etr_perf ->  +---------+
>    CPU1: AUX RB (perf_output_handle_1) -> etr_perf ->  | etr_buf |
>    CPU2: AUX RB (perf_output_handle_2) -> etr_perf ->  |         |
>    CPU3: AUX RB (perf_output_handle_3) -> etr_perf ->  +---------+ >

To make it more clear:

     CPU0: AUX RB (perf_output_handle_0) -> etr_perf0 ->  +---------+
     CPU1: AUX RB (perf_output_handle_1) -> etr_perf1 ->  |etr_buf0 |
     CPU2: AUX RB (perf_output_handle_2) -> etr_perf2 ->  |         |
     CPU3: AUX RB (perf_output_handle_3) -> etr_perf3 ->  +---------+


> Simply to say, there have two layers for controlling ring buffer, one
> layer is for perf AUX ring buffer, it mainly uses the structure
> perf_output_handle to manage the ring buffer.  And in the ETR driver,
> it uses structure etr_perf to manage the header pointer for copying
> data into ETR buffer (tagged as "etr_buf").
> 
> ETR buffer is the single one, but the structures "perf_output_handle"
> and "etr_perf" are per CPU.  We have multiple copies for the headers and

minor Correction, they are "per-event" to be precise. And there are 
events per-CPU in a system wide mode or task mode (but not per-thread 
mode). So, you are correct

> tails to manage a single buffer, but the problem is these multiple
> copies have not been synced with each other.
> 
>> 2) Even more problematic is where we copy the AUX buffer content to.
>> As mentioned above, we don't know which handle is going to be the last
>> one to consume and we have a "etr_perf->head" that came from one of the
>> handles and the "pages" that came from the first handle which created a
>> etr_perf buffer. In sync_perf_buffer() we copy the hardware buffers to
>> the "pages" (say of handle_0) with "etr_perf->head" (which could be from
>> any other handle, say handle_2) and then we could return the number of bytes
>> copied, which then is used to update the last handle (could be say
>> handle_3), where there is no actual data copied.

This is not valid and am relieved that the driver is correct. The 
assumption that there is only one etr_perf per ETR is incorrect as
pictured above.

>>
>> To fix all of these issues, we must
>> 1) Stop using etr_perf->head, and instead use the handle->head where we are
>> called update_buffer on.
>>
>> 2) Keep track of the "pages" that belong to a given "handle" and then use
>> those pages to copy the data to the current handle we are called to update
>> the buffer on.
> 
> The "pages" are only allocated once, even they are attached to multiple
> handles.  I think the right way is to use the single structure

I assume you mean the pages in the etr_buf and not etr_perf right ?

> "etr_perf" and single "perf_output_handle" to manage the "pages", IOW,
> if there have single buffer, then we just use one copy of header and
> tail to manage it.

I think this is not needed and the way we do things are fine and the 
patch as such looks correct to me.

The perf_output_handle is per-event and nothing that we can combine 
with. etr_perf captures what the "ouput_handle" stands for and is 
something necessary for syncing the buffer.

Now coming back to this patch, I understand that the sync_perf could be 
called with the polling patches multiple times. But don't we do a
perf_output_handle_end() each of the time we wake up ? (I haven't looked
at the later patches yet).

I would expect:

   perf_aux_output_begin() -> update the etr_perf-> head

   when we sync the buffer, we do :

  Poll-> sync_buffer-> perf_aux_output_end() and perf_aux_output_begin() 
-> update etr_perf->head.


Kind regards
Suzuki



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:33 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:33 +0200
Subject: [PATCH v2 06/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <7f29a390daf93c38c4d52b9ccdfb113df5ebace7.1619518193.git.mchehab+huawei@kernel.org>

Calling pm_runtime_get_sync() at driver's removal time is not
needed, as this will resume PM runtime. Also, the PM runtime
code at pm_runtime_disable() already calls it, if it detects
the need.

So, simplify the code by getting rid of that.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..70e86cdc1012 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1210,8 +1210,6 @@ static int gsc_remove(struct platform_device *pdev)
 	struct gsc_dev *gsc = platform_get_drvdata(pdev);
 	int i;
 
-	pm_runtime_get_sync(&pdev->dev);
-
 	gsc_unregister_m2m_device(gsc);
 	v4l2_device_unregister(&gsc->v4l2_dev);
 
@@ -1219,7 +1217,6 @@ static int gsc_remove(struct platform_device *pdev)
 	for (i = 0; i < gsc->num_clocks; i++)
 		clk_disable_unprepare(gsc->clock[i]);
 
-	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:44 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:44 +0200
Subject: [PATCH v2 17/79] media: s5p-jpeg: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <b6a5ee6479e005c271849b27e752c10f0fd8a150.1619518193.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 026111505f5a..c4f19418a460 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2568,7 +2568,7 @@ static int s5p_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(q);
 	int ret;
 
-	ret = pm_runtime_get_sync(ctx->jpeg->dev);
+	ret = pm_runtime_resume_and_get(ctx->jpeg->dev);
 
 	return ret > 0 ? 0 : ret;
 }
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:43 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:43 +0200
Subject: [PATCH v2 16/79] media: mtk-vcodec: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <e91e271160c17f6dbfc99663c735cfc9533cd7c2.1619518193.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index ddee7046ce42..fe096fe61c9d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -92,9 +92,9 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
-	ret = pm_runtime_get_sync(pm->dev);
+	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
-		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
+		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
 }
 
 void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:34 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:34 +0200
Subject: [PATCH v2 07/79] media: atmel: properly get pm_runtime
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <246fe06a2621c5945f474fdf357aa5e5a4e1fb12.1619518193.git.mchehab+huawei@kernel.org>

There are several issues in the way the atmel driver handles
pm_runtime_get_sync():

- it doesn't check return codes;
- it doesn't properly decrement the usage_count on all places;
- it starts streaming even if pm_runtime_get_sync() fails.
- while it tries to get pm_runtime at the clock enable logic,
  it doesn't check if the operation was suceeded.

Replace all occurrences of it to use the new kAPI:
pm_runtime_resume_and_get(), which ensures that, if the
return code is not negative, the usage_count was incremented.

With that, add additional checks when this is called, in order
to ensure that errors will be properly addressed.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 27 ++++++++++++++-----
 drivers/media/platform/atmel/atmel-isi.c      | 19 ++++++++++---
 2 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..02543fe42e9d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -294,9 +294,13 @@ static int isc_wait_clk_stable(struct clk_hw *hw)
 static int isc_clk_prepare(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	return isc_wait_clk_stable(hw);
 }
@@ -353,9 +357,13 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
 	u32 status;
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	regmap_read(isc_clk->regmap, ISC_CLKSR, &status);
 
@@ -807,7 +815,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 		goto err_start_stream;
 	}
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		goto err_pm_get;
 
 	ret = isc_configure(isc);
 	if (unlikely(ret))
@@ -838,7 +848,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_configure:
 	pm_runtime_put_sync(isc->dev);
-
+err_pm_get:
 	v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
 
 err_start_stream:
@@ -1809,6 +1819,7 @@ static void isc_awb_work(struct work_struct *w)
 	u32 baysel;
 	unsigned long flags;
 	u32 min, max;
+	int ret;
 
 	/* streaming is not active anymore */
 	if (isc->stop)
@@ -1831,7 +1842,9 @@ static void isc_awb_work(struct work_struct *w)
 	ctrls->hist_id = hist_id;
 	baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		return;
 
 	/*
 	 * only update if we have all the required histograms and controls
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index 0514be6153df..6a433926726d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -422,7 +422,9 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
 	struct frame_buffer *buf, *node;
 	int ret;
 
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	/* Enable stream on the sub device */
 	ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
@@ -782,9 +784,10 @@ static int isi_enum_frameintervals(struct file *file, void *fh,
 	return 0;
 }
 
-static void isi_camera_set_bus_param(struct atmel_isi *isi)
+static int isi_camera_set_bus_param(struct atmel_isi *isi)
 {
 	u32 cfg1 = 0;
+	int ret;
 
 	/* set bus param for ISI */
 	if (isi->pdata.hsync_act_low)
@@ -801,12 +804,16 @@ static void isi_camera_set_bus_param(struct atmel_isi *isi)
 	cfg1 |= ISI_CFG1_THMASK_BEATS_16;
 
 	/* Enable PM and peripheral clock before operate isi registers */
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
 	isi_writel(isi, ISI_CFG1, cfg1);
 
 	pm_runtime_put(isi->dev);
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------*/
@@ -1085,7 +1092,11 @@ static int isi_graph_notify_complete(struct v4l2_async_notifier *notifier)
 		dev_err(isi->dev, "No supported mediabus format found\n");
 		return ret;
 	}
-	isi_camera_set_bus_param(isi);
+	ret = isi_camera_set_bus_param(isi);
+	if (ret) {
+		dev_err(isi->dev, "Can't wake up device\n");
+		return ret;
+	}
 
 	ret = isi_set_default_fmt(isi);
 	if (ret) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:36 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:36 +0200
Subject: [PATCH v2 09/79] media: mdk-mdp: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <36568b7ce611dfaf4abc3233c76018a137f934c8.1619518193.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
as it doesn't make any sense to return 0 if the PM runtime failed
to resume.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index ace4528cdc5e..f14779e7596e 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct mtk_mdp_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
 	if (ret < 0)
-		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
+		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
 			    ctx->id, ret);
 
-	return 0;
+	return ret;
 }
 
 static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx,
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:49 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:49 +0200
Subject: [PATCH v2 22/79] staging: media: imx7-mipi-csis: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <9b52f8d9709e32ac129563f508beaec8ab321409.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Acked-by: Rui Miguel Silva <rmfrfs at gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index 025fdc488bd6..1dc680d94a46 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -695,11 +695,10 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 
 		mipi_csis_clear_counters(state);
 
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
 		if (ret < 0 && ret != -ENOIOCTLCMD)
 			goto done;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:46 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:46 +0200
Subject: [PATCH v2 19/79] media: sun8i_rotate: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <4e9d12ab641622cf2cd1721c257c12c52271cf05.1619518193.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
index 3f81dd17755c..fbcca59a0517 100644
--- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
+++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
@@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
 		struct device *dev = ctx->dev->dev;
 		int ret;
 
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:38 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:38 +0200
Subject: [PATCH v2 11/79] media: rga-buf: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <a0c6f5de9bbc9c28d2c39878a99a147cff95b3e9.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
 drivers/media/platform/rockchip/rga/rga.c     | 4 +++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
index bf9a75b75083..81508ed5abf3 100644
--- a/drivers/media/platform/rockchip/rga/rga-buf.c
+++ b/drivers/media/platform/rockchip/rga/rga-buf.c
@@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct rockchip_rga *rga = ctx->rga;
 	int ret;
 
-	ret = pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(rga->dev);
 		rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
 		return ret;
 	}
diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
index 9d122429706e..bf3fd71ec3af 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
 		goto unreg_video_dev;
 	}
 
-	pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
+	if (ret < 0)
+		goto unreg_video_dev;
 
 	rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
 	rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:12:51 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:12:51 +0200
Subject: [PATCH v2 24/79] staging: media: cedrus_video: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <3c993a816dba970cf45d7d9ecbae8b13047ee18a.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index b62eb8e84057..9ddd789d0b1f 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq, unsigned int count)
 	}
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(dev->dev);
+		ret = pm_runtime_resume_and_get(dev->dev);
+		if (ret < 0)
 			goto err_cleanup;
-		}
 
 		if (dev->dec_ops[ctx->current_codec]->start) {
 			ret = dev->dec_ops[ctx->current_codec]->start(ctx);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:31 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:31 +0200
Subject: [PATCH v2 64/79] media: mtk-jpeg: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <6b9c896cd16a090b334dd657f8937cd436288ba1.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 88a23bce569d..a89c7b206eef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv)
 	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto enc_end;
 
@@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv)
 		return;
 	}
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto dec_end;
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:29 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:29 +0200
Subject: [PATCH v2 62/79] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <549d4b739a70d1b273590693a14cf9c0efefa8c1.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
 drivers/media/platform/exynos4-is/fimc-is.c        | 4 ++--
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
 drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
 drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
 drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
 drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
 drivers/media/platform/exynos4-is/mipi-csis.c      | 8 +++-----
 8 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index 13c838d3f947..0da36443173c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
 		goto unlock;
 
 	set_bit(ST_CAPT_BUSY, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
-	if (ret < 0) {
-		pm_runtime_put_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
+	if (ret < 0)
 		goto unlock;
-	}
 
 	ret = v4l2_fh_open(file);
 	if (ret) {
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 972d9601d236..1b24f5bfc4af 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -828,9 +828,9 @@ static int fimc_is_probe(struct platform_device *pdev)
 			goto err_irq;
 	}
 
-	ret = pm_runtime_get_sync(dev);
+	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_irq;
 
 	vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..8d9dc597deaa 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -275,7 +275,7 @@ static int isp_video_open(struct file *file)
 	if (ret < 0)
 		goto unlock;
 
-	ret = pm_runtime_get_sync(&isp->pdev->dev);
+	ret = pm_runtime_resume_and_get(&isp->pdev->dev);
 	if (ret < 0)
 		goto rel_fh;
 
@@ -293,7 +293,6 @@ static int isp_video_open(struct file *file)
 	if (!ret)
 		goto unlock;
 rel_fh:
-	pm_runtime_put_noidle(&isp->pdev->dev);
 	v4l2_fh_release(file);
 unlock:
 	mutex_unlock(&isp->video_lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
index a77c49b18511..74b49d30901e 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -304,11 +304,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
 	pr_debug("on: %d\n", on);
 
 	if (on) {
-		ret = pm_runtime_get_sync(&is->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put(&is->pdev->dev);
+		ret = pm_runtime_resume_and_get(&is->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		set_bit(IS_ST_PWR_ON, &is->state);
 
 		ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index fe20af3a7178..4d8b18078ff3 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -469,9 +469,9 @@ static int fimc_lite_open(struct file *file)
 	}
 
 	set_bit(ST_FLITE_IN_USE, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_in_use;
 
 	ret = v4l2_fh_open(file);
 	if (ret < 0)
@@ -499,6 +499,7 @@ static int fimc_lite_open(struct file *file)
 	v4l2_fh_release(file);
 err_pm:
 	pm_runtime_put_sync(&fimc->pdev->dev);
+err_in_use:
 	clear_bit(ST_FLITE_IN_USE, &fimc->state);
 unlock:
 	mutex_unlock(&fimc->lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
index c9704a147e5c..7c1eb05c508f 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -75,7 +75,7 @@ static int start_streaming(struct vb2_queue *q, unsigned int count)
 	struct fimc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->fimc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->fimc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 13d192ba4aa6..9346d44a06c2 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -512,11 +512,9 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
 	if (!fmd->pmf)
 		return -ENXIO;
 
-	ret = pm_runtime_get_sync(fmd->pmf);
-	if (ret < 0) {
-		pm_runtime_put(fmd->pmf);
+	ret = pm_runtime_resume_and_get(fmd->pmf);
+	if (ret < 0)
 		return ret;
-	}
 
 	fmd->num_sensors = 0;
 
@@ -1291,7 +1289,7 @@ static int cam_clk_prepare(struct clk_hw *hw)
 	if (camclk->fmd->pmf == NULL)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(camclk->fmd->pmf);
+	ret = pm_runtime_resume_and_get(camclk->fmd->pmf);
 	return ret < 0 ? ret : 0;
 }
 
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 1aac167abb17..2a6afb78a049 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
 	struct device *dev = &state->pdev->dev;
 
 	if (on)
-		return pm_runtime_get_sync(dev);
+		return pm_runtime_resume_and_get(dev);
 
 	return pm_runtime_put_sync(dev);
 }
@@ -509,11 +509,9 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
 
 	if (enable) {
 		s5pcsis_clear_counters(state);
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret && ret != 1) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret && ret != 1)
 			return ret;
-		}
 	}
 
 	mutex_lock(&state->lock);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:39 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:39 +0200
Subject: [PATCH v2 72/79] media: s5p-mfc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <1b06b8e70c547f8bba0c154488f9f8a8013a0ea4.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 62d2320a7218..88b7d33c9197 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -78,11 +78,9 @@ int s5p_mfc_power_on(void)
 {
 	int i, ret = 0;
 
-	ret = pm_runtime_get_sync(pm->device);
-	if (ret < 0) {
-		pm_runtime_put_noidle(pm->device);
+	ret = pm_runtime_resume_and_get(pm->device);
+	if (ret < 0)
 		return ret;
-	}
 
 	/* clock control */
 	for (i = 0; i < pm->num_clocks; i++) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:30 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:30 +0200
Subject: [PATCH v2 63/79] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <6ba2ed04d791b8a1529977920bcc3930c2f3238e.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 27a3c92c73bc..09551e96ac15 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -58,7 +58,7 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct gsc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->gsc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:41 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:41 +0200
Subject: [PATCH v2 74/79] media: stm32: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <138647d154e523f6e0ff04af1dd94e8bd0facff3.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/stm32/stm32-dcmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index bbcc2254fa2e..5f4e1db8cfcd 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -723,11 +723,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 	u32 val = 0;
 	int ret;
 
-	ret = pm_runtime_get_sync(dcmi->dev);
+	ret = pm_runtime_resume_and_get(dcmi->dev);
 	if (ret < 0) {
 		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
 			__func__, ret);
-		goto err_pm_put;
+		goto err_unlock;
 	}
 
 	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
@@ -848,6 +848,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_pm_put:
 	pm_runtime_put(dcmi->dev);
+err_unlock:
 	spin_lock_irq(&dcmi->irqlock);
 	/*
 	 * Return all buffers to vb2 in QUEUED state.
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:37 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:37 +0200
Subject: [PATCH v2 70/79] media: rkisp1: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <ba62fb97e435003c2eb2949fffa450764772db8f.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..3730376897d9 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -1003,9 +1003,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
 	if (ret)
 		goto err_pipeline_stop;
 
-	ret = pm_runtime_get_sync(cap->rkisp1->dev);
+	ret = pm_runtime_resume_and_get(cap->rkisp1->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(cap->rkisp1->dev);
 		dev_err(cap->rkisp1->dev, "power up failed %d\n", ret);
 		goto err_destroy_dummy;
 	}
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:13:42 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:13:42 +0200
Subject: [PATCH v2 75/79] media: sunxi: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619518193.git.mchehab+huawei@kernel.org>
References: <cover.1619518193.git.mchehab+huawei@kernel.org>
Message-ID: <8c9d978dfc49ea2de6a1b6cf5b3a9d647e6b1cbf.1619518193.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 4785faddf630..54b909987caa 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -206,9 +206,9 @@ static int sun4i_csi_open(struct file *file)
 	if (ret)
 		return ret;
 
-	ret = pm_runtime_get_sync(csi->dev);
+	ret = pm_runtime_resume_and_get(csi->dev);
 	if (ret < 0)
-		goto err_pm_put;
+		goto err_unlock;
 
 	ret = v4l2_pipeline_pm_get(&csi->vdev.entity);
 	if (ret)
@@ -227,6 +227,8 @@ static int sun4i_csi_open(struct file *file)
 
 err_pm_put:
 	pm_runtime_put(csi->dev);
+
+err_unlock:
 	mutex_unlock(&csi->lock);
 
 	return ret;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:07 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:07 +0200
Subject: [PATCH v3 17/79] media: s5p-jpeg: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <7ef9d9ec7810a6d2ff53ba8685fcc91a952bbbb5.1619519080.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 026111505f5a..c4f19418a460 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2568,7 +2568,7 @@ static int s5p_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(q);
 	int ret;
 
-	ret = pm_runtime_get_sync(ctx->jpeg->dev);
+	ret = pm_runtime_resume_and_get(ctx->jpeg->dev);
 
 	return ret > 0 ? 0 : ret;
 }
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:14 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:14 +0200
Subject: [PATCH v3 24/79] staging: media: cedrus_video: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <991f59e8ff469c6b0e410db2aca6a1d3885b03d8.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index b62eb8e84057..9ddd789d0b1f 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq, unsigned int count)
 	}
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(dev->dev);
+		ret = pm_runtime_resume_and_get(dev->dev);
+		if (ret < 0)
 			goto err_cleanup;
-		}
 
 		if (dev->dec_ops[ctx->current_codec]->start) {
 			ret = dev->dec_ops[ctx->current_codec]->start(ctx);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:01 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:01 +0200
Subject: [PATCH v3 11/79] media: rga-buf: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <a9099f1ffc537e5f997cb260a175715892387c5a.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
 drivers/media/platform/rockchip/rga/rga.c     | 4 +++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
index bf9a75b75083..81508ed5abf3 100644
--- a/drivers/media/platform/rockchip/rga/rga-buf.c
+++ b/drivers/media/platform/rockchip/rga/rga-buf.c
@@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct rockchip_rga *rga = ctx->rga;
 	int ret;
 
-	ret = pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(rga->dev);
 		rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
 		return ret;
 	}
diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
index 9d122429706e..bf3fd71ec3af 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
 		goto unreg_video_dev;
 	}
 
-	pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
+	if (ret < 0)
+		goto unreg_video_dev;
 
 	rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
 	rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:25:59 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:25:59 +0200
Subject: [PATCH v3 09/79] media: mdk-mdp: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <6f2e4b112f845f9be1de07cb8d73ff3173dec01a.1619519080.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
as it doesn't make any sense to return 0 if the PM runtime failed
to resume.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index ace4528cdc5e..f14779e7596e 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct mtk_mdp_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
 	if (ret < 0)
-		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
+		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
 			    ctx->id, ret);
 
-	return 0;
+	return ret;
 }
 
 static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx,
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:25:57 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:25:57 +0200
Subject: [PATCH v3 07/79] media: atmel: properly get pm_runtime
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <f1dc61f9e8cf2b4c7804423d11dffc43dc4c911a.1619519080.git.mchehab+huawei@kernel.org>

There are several issues in the way the atmel driver handles
pm_runtime_get_sync():

- it doesn't check return codes;
- it doesn't properly decrement the usage_count on all places;
- it starts streaming even if pm_runtime_get_sync() fails.
- while it tries to get pm_runtime at the clock enable logic,
  it doesn't check if the operation was suceeded.

Replace all occurrences of it to use the new kAPI:
pm_runtime_resume_and_get(), which ensures that, if the
return code is not negative, the usage_count was incremented.

With that, add additional checks when this is called, in order
to ensure that errors will be properly addressed.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 27 ++++++++++++++-----
 drivers/media/platform/atmel/atmel-isi.c      | 19 ++++++++++---
 2 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..02543fe42e9d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -294,9 +294,13 @@ static int isc_wait_clk_stable(struct clk_hw *hw)
 static int isc_clk_prepare(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	return isc_wait_clk_stable(hw);
 }
@@ -353,9 +357,13 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
 	u32 status;
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	regmap_read(isc_clk->regmap, ISC_CLKSR, &status);
 
@@ -807,7 +815,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 		goto err_start_stream;
 	}
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		goto err_pm_get;
 
 	ret = isc_configure(isc);
 	if (unlikely(ret))
@@ -838,7 +848,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_configure:
 	pm_runtime_put_sync(isc->dev);
-
+err_pm_get:
 	v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
 
 err_start_stream:
@@ -1809,6 +1819,7 @@ static void isc_awb_work(struct work_struct *w)
 	u32 baysel;
 	unsigned long flags;
 	u32 min, max;
+	int ret;
 
 	/* streaming is not active anymore */
 	if (isc->stop)
@@ -1831,7 +1842,9 @@ static void isc_awb_work(struct work_struct *w)
 	ctrls->hist_id = hist_id;
 	baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		return;
 
 	/*
 	 * only update if we have all the required histograms and controls
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index 0514be6153df..6a433926726d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -422,7 +422,9 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
 	struct frame_buffer *buf, *node;
 	int ret;
 
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	/* Enable stream on the sub device */
 	ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
@@ -782,9 +784,10 @@ static int isi_enum_frameintervals(struct file *file, void *fh,
 	return 0;
 }
 
-static void isi_camera_set_bus_param(struct atmel_isi *isi)
+static int isi_camera_set_bus_param(struct atmel_isi *isi)
 {
 	u32 cfg1 = 0;
+	int ret;
 
 	/* set bus param for ISI */
 	if (isi->pdata.hsync_act_low)
@@ -801,12 +804,16 @@ static void isi_camera_set_bus_param(struct atmel_isi *isi)
 	cfg1 |= ISI_CFG1_THMASK_BEATS_16;
 
 	/* Enable PM and peripheral clock before operate isi registers */
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
 	isi_writel(isi, ISI_CFG1, cfg1);
 
 	pm_runtime_put(isi->dev);
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------*/
@@ -1085,7 +1092,11 @@ static int isi_graph_notify_complete(struct v4l2_async_notifier *notifier)
 		dev_err(isi->dev, "No supported mediabus format found\n");
 		return ret;
 	}
-	isi_camera_set_bus_param(isi);
+	ret = isi_camera_set_bus_param(isi);
+	if (ret) {
+		dev_err(isi->dev, "Can't wake up device\n");
+		return ret;
+	}
 
 	ret = isi_set_default_fmt(isi);
 	if (ret) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:25:56 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:25:56 +0200
Subject: [PATCH v3 06/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <a561d9eb253076cbcb9debe5fcbd3c949d5023d2.1619519080.git.mchehab+huawei@kernel.org>

Calling pm_runtime_get_sync() at driver's removal time is not
needed, as this will resume PM runtime. Also, the PM runtime
code at pm_runtime_disable() already calls it, if it detects
the need.

So, simplify the code by getting rid of that.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..70e86cdc1012 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1210,8 +1210,6 @@ static int gsc_remove(struct platform_device *pdev)
 	struct gsc_dev *gsc = platform_get_drvdata(pdev);
 	int i;
 
-	pm_runtime_get_sync(&pdev->dev);
-
 	gsc_unregister_m2m_device(gsc);
 	v4l2_device_unregister(&gsc->v4l2_dev);
 
@@ -1219,7 +1217,6 @@ static int gsc_remove(struct platform_device *pdev)
 	for (i = 0; i < gsc->num_clocks; i++)
 		clk_disable_unprepare(gsc->clock[i]);
 
-	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
 	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:06 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:06 +0200
Subject: [PATCH v3 16/79] media: mtk-vcodec: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <5ecb7c839255ae1b74a4f623cad05cc1a1ed3efe.1619519080.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index ddee7046ce42..fe096fe61c9d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -92,9 +92,9 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
-	ret = pm_runtime_get_sync(pm->dev);
+	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
-		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
+		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
 }
 
 void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:53 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:53 +0200
Subject: [PATCH v3 63/79] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <5a8d3ca13956feb5e611cb1fe08195966be5edf2.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 27a3c92c73bc..09551e96ac15 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -58,7 +58,7 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct gsc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->gsc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:54 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:54 +0200
Subject: [PATCH v3 64/79] media: mtk-jpeg: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <a6fcf38f0add7f5ffc3b8d8b923c8dabf22738d7.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 88a23bce569d..a89c7b206eef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv)
 	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto enc_end;
 
@@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv)
 		return;
 	}
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto dec_end;
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:27:04 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:27:04 +0200
Subject: [PATCH v3 74/79] media: stm32: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <7a01ab8c03a6778c6aeb9357a3807829c6dc91f3.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/stm32/stm32-dcmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index bbcc2254fa2e..5f4e1db8cfcd 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -723,11 +723,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 	u32 val = 0;
 	int ret;
 
-	ret = pm_runtime_get_sync(dcmi->dev);
+	ret = pm_runtime_resume_and_get(dcmi->dev);
 	if (ret < 0) {
 		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
 			__func__, ret);
-		goto err_pm_put;
+		goto err_unlock;
 	}
 
 	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
@@ -848,6 +848,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_pm_put:
 	pm_runtime_put(dcmi->dev);
+err_unlock:
 	spin_lock_irq(&dcmi->irqlock);
 	/*
 	 * Return all buffers to vb2 in QUEUED state.
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:09 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:09 +0200
Subject: [PATCH v3 19/79] media: sun8i_rotate: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <2ea29dfab3849fc6856f6a196850ae711a61d4a8.1619519080.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
index 3f81dd17755c..fbcca59a0517 100644
--- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
+++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
@@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
 		struct device *dev = ctx->dev->dev;
 		int ret;
 
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:27:00 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:27:00 +0200
Subject: [PATCH v3 70/79] media: rkisp1: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <ed910c61ae00f88fcd29d15282e1018c1d894b56.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..3730376897d9 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -1003,9 +1003,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
 	if (ret)
 		goto err_pipeline_stop;
 
-	ret = pm_runtime_get_sync(cap->rkisp1->dev);
+	ret = pm_runtime_resume_and_get(cap->rkisp1->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(cap->rkisp1->dev);
 		dev_err(cap->rkisp1->dev, "power up failed %d\n", ret);
 		goto err_destroy_dummy;
 	}
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:12 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:12 +0200
Subject: [PATCH v3 22/79] staging: media: imx7-mipi-csis: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <706a63dc9019ebea7904acedc6d40ae44cb706b6.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Acked-by: Rui Miguel Silva <rmfrfs at gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index 025fdc488bd6..1dc680d94a46 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -695,11 +695,10 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 
 		mipi_csis_clear_counters(state);
 
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
 		if (ret < 0 && ret != -ENOIOCTLCMD)
 			goto done;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:26:52 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:26:52 +0200
Subject: [PATCH v3 62/79] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <834b16534ae8e18a29c734956e3eda671d455451.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
 drivers/media/platform/exynos4-is/fimc-is.c        | 4 ++--
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
 drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
 drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
 drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
 drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
 drivers/media/platform/exynos4-is/mipi-csis.c      | 8 +++-----
 8 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index 13c838d3f947..0da36443173c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
 		goto unlock;
 
 	set_bit(ST_CAPT_BUSY, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
-	if (ret < 0) {
-		pm_runtime_put_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
+	if (ret < 0)
 		goto unlock;
-	}
 
 	ret = v4l2_fh_open(file);
 	if (ret) {
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 972d9601d236..1b24f5bfc4af 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -828,9 +828,9 @@ static int fimc_is_probe(struct platform_device *pdev)
 			goto err_irq;
 	}
 
-	ret = pm_runtime_get_sync(dev);
+	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_irq;
 
 	vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..8d9dc597deaa 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -275,7 +275,7 @@ static int isp_video_open(struct file *file)
 	if (ret < 0)
 		goto unlock;
 
-	ret = pm_runtime_get_sync(&isp->pdev->dev);
+	ret = pm_runtime_resume_and_get(&isp->pdev->dev);
 	if (ret < 0)
 		goto rel_fh;
 
@@ -293,7 +293,6 @@ static int isp_video_open(struct file *file)
 	if (!ret)
 		goto unlock;
 rel_fh:
-	pm_runtime_put_noidle(&isp->pdev->dev);
 	v4l2_fh_release(file);
 unlock:
 	mutex_unlock(&isp->video_lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
index a77c49b18511..74b49d30901e 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -304,11 +304,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
 	pr_debug("on: %d\n", on);
 
 	if (on) {
-		ret = pm_runtime_get_sync(&is->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put(&is->pdev->dev);
+		ret = pm_runtime_resume_and_get(&is->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		set_bit(IS_ST_PWR_ON, &is->state);
 
 		ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index fe20af3a7178..4d8b18078ff3 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -469,9 +469,9 @@ static int fimc_lite_open(struct file *file)
 	}
 
 	set_bit(ST_FLITE_IN_USE, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_in_use;
 
 	ret = v4l2_fh_open(file);
 	if (ret < 0)
@@ -499,6 +499,7 @@ static int fimc_lite_open(struct file *file)
 	v4l2_fh_release(file);
 err_pm:
 	pm_runtime_put_sync(&fimc->pdev->dev);
+err_in_use:
 	clear_bit(ST_FLITE_IN_USE, &fimc->state);
 unlock:
 	mutex_unlock(&fimc->lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
index c9704a147e5c..7c1eb05c508f 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -75,7 +75,7 @@ static int start_streaming(struct vb2_queue *q, unsigned int count)
 	struct fimc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->fimc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->fimc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 13d192ba4aa6..9346d44a06c2 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -512,11 +512,9 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
 	if (!fmd->pmf)
 		return -ENXIO;
 
-	ret = pm_runtime_get_sync(fmd->pmf);
-	if (ret < 0) {
-		pm_runtime_put(fmd->pmf);
+	ret = pm_runtime_resume_and_get(fmd->pmf);
+	if (ret < 0)
 		return ret;
-	}
 
 	fmd->num_sensors = 0;
 
@@ -1291,7 +1289,7 @@ static int cam_clk_prepare(struct clk_hw *hw)
 	if (camclk->fmd->pmf == NULL)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(camclk->fmd->pmf);
+	ret = pm_runtime_resume_and_get(camclk->fmd->pmf);
 	return ret < 0 ? ret : 0;
 }
 
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 1aac167abb17..2a6afb78a049 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
 	struct device *dev = &state->pdev->dev;
 
 	if (on)
-		return pm_runtime_get_sync(dev);
+		return pm_runtime_resume_and_get(dev);
 
 	return pm_runtime_put_sync(dev);
 }
@@ -509,11 +509,9 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
 
 	if (enable) {
 		s5pcsis_clear_counters(state);
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret && ret != 1) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret && ret != 1)
 			return ret;
-		}
 	}
 
 	mutex_lock(&state->lock);
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:27:05 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:27:05 +0200
Subject: [PATCH v3 75/79] media: sunxi: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <f1901bc5c3e2a6e88e678f5763b97509cc706bf5.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 4785faddf630..54b909987caa 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -206,9 +206,9 @@ static int sun4i_csi_open(struct file *file)
 	if (ret)
 		return ret;
 
-	ret = pm_runtime_get_sync(csi->dev);
+	ret = pm_runtime_resume_and_get(csi->dev);
 	if (ret < 0)
-		goto err_pm_put;
+		goto err_unlock;
 
 	ret = v4l2_pipeline_pm_get(&csi->vdev.entity);
 	if (ret)
@@ -227,6 +227,8 @@ static int sun4i_csi_open(struct file *file)
 
 err_pm_put:
 	pm_runtime_put(csi->dev);
+
+err_unlock:
 	mutex_unlock(&csi->lock);
 
 	return ret;
-- 
2.30.2



From mchehab+huawei at kernel.org  Tue Apr 27 11:27:02 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Tue, 27 Apr 2021 12:27:02 +0200
Subject: [PATCH v3 72/79] media: s5p-mfc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <828322e0f8b06ef2962b64a6f6f1b368eaecf7a0.1619519080.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 62d2320a7218..88b7d33c9197 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -78,11 +78,9 @@ int s5p_mfc_power_on(void)
 {
 	int i, ret = 0;
 
-	ret = pm_runtime_get_sync(pm->device);
-	if (ret < 0) {
-		pm_runtime_put_noidle(pm->device);
+	ret = pm_runtime_resume_and_get(pm->device);
+	if (ret < 0)
 		return ret;
-	}
 
 	/* clock control */
 	for (i = 0; i < pm->num_clocks; i++) {
-- 
2.30.2



From snawrocki at kernel.org  Tue Apr 27 11:36:48 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 12:36:48 +0200
Subject: [PATCH v2] media:exynos4-is: Fix a use after free in
 isp_video_release
In-Reply-To: <20210427060255.3318-1-lyl2019@mail.ustc.edu.cn>
References: <20210427060255.3318-1-lyl2019@mail.ustc.edu.cn>
Message-ID: <a56d14d8-5be6-24ff-24f1-80274320dfe5@kernel.org>

On 27.04.2021 08:02, Lv Yunlong wrote:
> In isp_video_release, file->private_data is freed via
> _vb2_fop_release()->v4l2_fh_release(). But the freed
> file->private_data is still used in v4l2_fh_is_singular_file()
> ->v4l2_fh_is_singular(file->private_data), which is a use
> after free bug.
> 
> My patch set file->private_data to NULL after _vb2_fop_release()
> to avoid the use after free.
> 
> Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
> Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>
> ---
>   drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> index 612b9872afc8..2e04589068b4 100644
> --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> @@ -315,7 +315,8 @@ static int isp_video_release(struct file *file)
>   	}
>   
>   	_vb2_fop_release(file, NULL);
> -
> +	file->private_data = NULL;

>   	if (v4l2_fh_is_singular_file(file)) {
>   		fimc_pipeline_call(&ivc->ve, close);
>   

Thank you for the patch. To ensure the pipeline stop call is done
only when the last file handle is released we would need something
as below.

--------8<---------
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..3335fec509cb 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -306,17 +306,20 @@ static int isp_video_release(struct file *file)
         struct fimc_is_video *ivc = &isp->video_capture;
         struct media_entity *entity = &ivc->ve.vdev.entity;
         struct media_device *mdev = entity->graph_obj.mdev;
+       bool is_singular_file;

         mutex_lock(&isp->video_lock);

-       if (v4l2_fh_is_singular_file(file) && ivc->streaming) {
+       is_singular_file = v4l2_fh_is_singular_file(file);
+
+       if (is_singular_file && ivc->streaming) {
                 media_pipeline_stop(entity);
                 ivc->streaming = 0;
         }

         _vb2_fop_release(file, NULL);

-       if (v4l2_fh_is_singular_file(file)) {
+       if (is_singular_file) {
                 fimc_pipeline_call(&ivc->ve, close);

                 mutex_lock(&mdev->graph_mutex);
--------8<---------

Regards,
Sylwester


From Al.Grant at arm.com  Tue Apr 27 11:43:28 2021
From: Al.Grant at arm.com (Al Grant)
Date: Tue, 27 Apr 2021 10:43:28 +0000
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210426175425.GA1391779@xps15>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210426175425.GA1391779@xps15>
Message-ID: <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>

> Hi Daniel,
> 
> On Wed, Apr 21, 2021 at 02:04:09PM +0200, Daniel Kiss wrote:
> > This series adds a feature to ETR-PERF that sync the ETR buffer to
> > perf periodically. This is really handy when the system wide trace is
> > used because in this case the perf won't sync during the trace. In a
> > per-thread setup the traced program might not go to the kernel
> > frequvently enought to collect trace. Polling helps in both usecases. Can be
> used with strobing.
> > Tuning polling period is challanging, I'm working on an additional
> > patch that adds some metrics to help tune the polling period.
> >
> 
> Suzuki and Leo have already commented on a number of problems with this set
> and as such I will concentrate on the general idea.
> 
> Over the years we have thought long and hard about fixing the overflow issues
> created by the lack of interrupt when a sink gets full, installing a timer to empty
> the sink buffer at regular intervals is one of them.  Ultimately we haven't moved
> forward with the idea because it requires to stop the sink when an event is
> active, something that introduces more trace data loss.
> 
> To me this kind of interval snapshot should be achieved using Mike's new
> strobing feature that came bundled with the complex configuration framework,
> available on next-ETE-TRBE[1].  I will rebase that branch to 5.13-rc1 when it is
> released in a couple of weeks from now.

It's important to understand what strobing is. It acts internally to the ETM
and switches the ETM on for a time and then off for a time. It is as the
name suggests, like a stroboscope (or a lighthouse).

There is no synchronization between the on-periods of different ETMs.
When you have multiple ETMs funnelling into a common ETR, strobing
does not guarantee you a window where you can safely harvest the buffer.
It achieves a reduction in the overall bandwidth of trace being dumped
into the buffer, and there may be times when no trace is being written
at all because all the ETMs are in their off-period.

At worst, it may create a false sense of security - tests that consistently
fail without strobing, may pass often enough with strobing to create the
impression that strobing has solved the problem. But these tests are also
likely to fail eventually with strobing. To fix this problem without
disabling either ETR or ETMs you would have to guarantee that you can
harvest the ETR buffer in less time than it takes to fill it. That would need 
very careful quntitative arguments to be made about:

 - the rate of trace generation by each ETM (as modified by strobing)

 - the number of ETMs writing into the buffer

 - the time available to the kernel to harvest the buffer

So if there are 10 ETMs generating trace at average 1Gb/s into a 1Mb
buffer, the buffer will fill in 100us, and that gives the kernel 100us to
harvest the buffer before its read pointer is caught up by the ETR's
advancing write pointer. If strobing is used to reduce average ETM rate
to 100Mb/s the kernel has 1ms to read the buffer, and so on. In short
the kernel must *guarantee* a minimum readout rate equal to the
maximum aggregate write rate of the ETMs. But can the kernel
guarantee any minimum readout rate at all?

The alternative would be double-buffering the ETR, which we've 
also discussed - so while the kernel is harvesting the contents of one
buffer, the ETR is writing (and possibly wrapping) the other.
Some trace will still be lost but it does mean the kernel will be
harvesting monotonically increasing sequences of trace, and won't be
seeing artefacts from its reads colliding with the ETR's writes.

Al


> 
> Thanks,
> Mathieu
> 
> PS: Always run your work through checkpatch.pl before sending a patchset for
> review.
> 
> [1].
> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-
> ETE-TRBE
> 
> > Daniel Kiss (4):
> >   coresight: tmc-etr: Advance buffer pointer in sync buffer.
> >   coresight: tmc-etr: Track perf handler.
> >   coresight: etm-perf: Export etm_event_cpu_path.
> >   coresight: Add ETR-PERF polling.
> >
> >  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
> >  drivers/hwtracing/coresight/Makefile          |   2 +-
> >  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
> >  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
> >  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
> >  .../coresight/coresight-etr-perf-polling.h    |  42 +++
> >  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
> >  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
> >  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
> >  9 files changed, 401 insertions(+), 4 deletions(-)  create mode
> > 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> >  create mode 100644
> > drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> >
> > --
> > 2.25.1
> >
> _______________________________________________
> CoreSight mailing list
> CoreSight at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight


From Al.Grant at arm.com  Tue Apr 27 11:43:28 2021
From: Al.Grant at arm.com (Al Grant)
Date: Tue, 27 Apr 2021 10:43:28 +0000
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210426175425.GA1391779@xps15>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210426175425.GA1391779@xps15>
Message-ID: <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>

> Hi Daniel,
> 
> On Wed, Apr 21, 2021 at 02:04:09PM +0200, Daniel Kiss wrote:
> > This series adds a feature to ETR-PERF that sync the ETR buffer to
> > perf periodically. This is really handy when the system wide trace is
> > used because in this case the perf won't sync during the trace. In a
> > per-thread setup the traced program might not go to the kernel
> > frequvently enought to collect trace. Polling helps in both usecases. Can be
> used with strobing.
> > Tuning polling period is challanging, I'm working on an additional
> > patch that adds some metrics to help tune the polling period.
> >
> 
> Suzuki and Leo have already commented on a number of problems with this set
> and as such I will concentrate on the general idea.
> 
> Over the years we have thought long and hard about fixing the overflow issues
> created by the lack of interrupt when a sink gets full, installing a timer to empty
> the sink buffer at regular intervals is one of them.  Ultimately we haven't moved
> forward with the idea because it requires to stop the sink when an event is
> active, something that introduces more trace data loss.
> 
> To me this kind of interval snapshot should be achieved using Mike's new
> strobing feature that came bundled with the complex configuration framework,
> available on next-ETE-TRBE[1].  I will rebase that branch to 5.13-rc1 when it is
> released in a couple of weeks from now.

It's important to understand what strobing is. It acts internally to the ETM
and switches the ETM on for a time and then off for a time. It is as the
name suggests, like a stroboscope (or a lighthouse).

There is no synchronization between the on-periods of different ETMs.
When you have multiple ETMs funnelling into a common ETR, strobing
does not guarantee you a window where you can safely harvest the buffer.
It achieves a reduction in the overall bandwidth of trace being dumped
into the buffer, and there may be times when no trace is being written
at all because all the ETMs are in their off-period.

At worst, it may create a false sense of security - tests that consistently
fail without strobing, may pass often enough with strobing to create the
impression that strobing has solved the problem. But these tests are also
likely to fail eventually with strobing. To fix this problem without
disabling either ETR or ETMs you would have to guarantee that you can
harvest the ETR buffer in less time than it takes to fill it. That would need 
very careful quntitative arguments to be made about:

 - the rate of trace generation by each ETM (as modified by strobing)

 - the number of ETMs writing into the buffer

 - the time available to the kernel to harvest the buffer

So if there are 10 ETMs generating trace at average 1Gb/s into a 1Mb
buffer, the buffer will fill in 100us, and that gives the kernel 100us to
harvest the buffer before its read pointer is caught up by the ETR's
advancing write pointer. If strobing is used to reduce average ETM rate
to 100Mb/s the kernel has 1ms to read the buffer, and so on. In short
the kernel must *guarantee* a minimum readout rate equal to the
maximum aggregate write rate of the ETMs. But can the kernel
guarantee any minimum readout rate at all?

The alternative would be double-buffering the ETR, which we've 
also discussed - so while the kernel is harvesting the contents of one
buffer, the ETR is writing (and possibly wrapping) the other.
Some trace will still be lost but it does mean the kernel will be
harvesting monotonically increasing sequences of trace, and won't be
seeing artefacts from its reads colliding with the ETR's writes.

Al


> 
> Thanks,
> Mathieu
> 
> PS: Always run your work through checkpatch.pl before sending a patchset for
> review.
> 
> [1].
> https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-
> ETE-TRBE
> 
> > Daniel Kiss (4):
> >   coresight: tmc-etr: Advance buffer pointer in sync buffer.
> >   coresight: tmc-etr: Track perf handler.
> >   coresight: etm-perf: Export etm_event_cpu_path.
> >   coresight: Add ETR-PERF polling.
> >
> >  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
> >  drivers/hwtracing/coresight/Makefile          |   2 +-
> >  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
> >  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
> >  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
> >  .../coresight/coresight-etr-perf-polling.h    |  42 +++
> >  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
> >  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
> >  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
> >  9 files changed, 401 insertions(+), 4 deletions(-)  create mode
> > 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> >  create mode 100644
> > drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> >
> > --
> > 2.25.1
> >
> _______________________________________________
> CoreSight mailing list
> CoreSight at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight


From s.nawrocki at samsung.com  Tue Apr 27 11:45:00 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 12:45:00 +0200
Subject: [PATCH v3 62/79] media: exynos4-is: use
 pm_runtime_resume_and_get()
In-Reply-To: <834b16534ae8e18a29c734956e3eda671d455451.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
 <CGME20210427102817eucas1p189868733a2485301909918a76f56bed9@eucas1p1.samsung.com>
 <834b16534ae8e18a29c734956e3eda671d455451.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <be384ba7-c657-ff3b-b21a-f8d2be96edaa@samsung.com>

On 27.04.2021 12:26, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From s.nawrocki at samsung.com  Tue Apr 27 11:47:31 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 12:47:31 +0200
Subject: [PATCH v3 63/79] media: exynos-gsc: use
 pm_runtime_resume_and_get()
In-Reply-To: <5a8d3ca13956feb5e611cb1fe08195966be5edf2.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
 <CGME20210427102804eucas1p175159e50b5d3431e6b0cffea7d52aaed@eucas1p1.samsung.com>
 <5a8d3ca13956feb5e611cb1fe08195966be5edf2.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <dafff234-b575-9c84-b5bb-d7e6e912a5f3@samsung.com>

On 27.04.2021 12:26, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From marcan at marcan.st  Tue Apr 27 12:07:10 2021
From: marcan at marcan.st (Hector Martin)
Date: Tue, 27 Apr 2021 20:07:10 +0900
Subject: [PATCH] irqchip: APPLE_AIC should depend on ARCH_APPLE
In-Reply-To: <f37e8daea37d50651d2164b0b3dad90780188548.1618316398.git.geert+renesas@glider.be>
References: <f37e8daea37d50651d2164b0b3dad90780188548.1618316398.git.geert+renesas@glider.be>
Message-ID: <26a1ca39-5c60-b54c-d3fc-df1a7cc38818@marcan.st>

On 13/04/2021 21.21, Geert Uytterhoeven wrote:
> The Apple Interrupt Controller is only present on Apple Silicon SoCs.
> Hence add a dependency on ARCH_APPLE, to prevent asking the user about
> this driver when configuring a kernel without Apple Silicon SoC support.
> 
> Drop the default, as ARCH_APPLE already selects APPLE_AIC.
> 
> Fixes: 76cde26394114f6a ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
>   drivers/irqchip/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Makes sense. Thanks!

Acked-by: Hector Martin <marcan at marcan.st>

-- 
Hector Martin (marcan at marcan.st)
Public Key: https://mrcn.st/pub


From wangkefeng.wang at huawei.com  Tue Apr 27 12:08:59 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Tue, 27 Apr 2021 19:08:59 +0800
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <YIet5X7lgygD9rpZ@kernel.org>
References: <20210421065108.1987-1-rppt@kernel.org>
 <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
Message-ID: <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>


On 2021/4/27 14:23, Mike Rapoport wrote:
> On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
>> On 2021/4/26 13:20, Mike Rapoport wrote:
>>> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>>>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>>>
>>>>       On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>>>
>>>>           I tested this patchset(plus arm32 change, like arm64 does)
>>>>           based on lts 5.10?add some debug log, the useful info shows
>>>>           below, if we enable HOLES_IN_ZONE, no panic, any idea,
>>>>           thanks.
>>>>
>>>>       Are there any changes on top of 5.10 except for pfn_valid() patch?
>>>>       Do you see this panic on 5.10 without the changes?
>>>>
>>>> Yes, there are some BSP support for arm board based on 5.10,
> Is it possible to test 5.12?
>
>>>> with or without your patch will get same panic, the panic pfn=de600
>>>> in the range of [dcc00,de00] which is freed by free_memmap, start_pfn
>>>> = dcc00,? dcc00000 end_pfn = de700, de700000
>>>>
>>>> we see the PC is at PageLRU, same reason like arm64 panic log,
>>>>
>>>>      "PageBuddy in move_freepages returns false
>>>>       Then we call PageLRU, the macro calls PF_HEAD which is compound_page()
>>>>       compound_page reads page->compound_head, it is 0xffffffffffffffff, so it
>>>>       resturns 0xfffffffffffffffe - and accessing this address causes crash"
>>>>
>>>>       Can you see stack backtrace beyond move_freepages_block?
>>>>
>>>> I do some oom test, so the log is about memory allocate,
>>>>
>>>> [<c02383c8>] (move_freepages_block) from [<c0238668>]
>>>> (steal_suitable_fallback+0x174/0x1f4)
>>>>
>>>> [<c0238668>] (steal_suitable_fallback) from [<c023999c>] (get_page_from_freelist+0x490/0x9a4)
>>> Hmm, this is called with a page from free list, having a page from a freed
>>> part of the memory map passed to steal_suitable_fallback() means that there
>>> is an issue with creation of the free list.
>>>
>>> Can you please add "memblock=debug" to the kernel command line and post the
>>> log?
>> Here is the log,
>>
>> CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=1ac5387d
>>
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> OF: fdt: Machine model: HISI-CA9
>> memblock_add: [0x80a00000-0x855fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x86a00000-0x87dfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x8bd00000-0x8c4fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x8e300000-0x8ecfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0x90d00000-0xbfffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xcc000000-0xdc9fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xe0800000-0xe0bfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf5300000-0xf5bfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf5c00000-0xf6ffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfe100000-0xfebfffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfec00000-0xffffffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xde700000-0xde9fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xf4b00000-0xf52fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_add: [0xfda00000-0xfe0fffff] early_init_dt_scan_memory+0x11c/0x188
>> memblock_reserve: [0x80a01000-0x80a02d2e] setup_arch+0x68/0x5c4
>> Malformed early option 'vecpage_wrprotect'
>> Memory policy: Data cache writealloc
>> memblock_reserve: [0x80b00000-0x812e8057] arm_memblock_init+0x34/0x14c
>> memblock_reserve: [0x83000000-0x84ffffff] arm_memblock_init+0x100/0x14c
>> memblock_reserve: [0x80a04000-0x80a07fff] arm_memblock_init+0xa0/0x14c
>> memblock_reserve: [0x80a00000-0x80a02fff] hisi_mem_reserve+0x14/0x30
>> MEMBLOCK configuration:
>>  ?memory size = 0x4c0fffff reserved size = 0x027ef058
>>  ?memory.cnt? = 0xa
>>  ?memory[0x0]??? [0x80a00000-0x855fffff], 0x04c00000 bytes flags: 0x0
>>  ?memory[0x1]??? [0x86a00000-0x87dfffff], 0x01400000 bytes flags: 0x0
>>  ?memory[0x2]??? [0x8bd00000-0x8c4fffff], 0x00800000 bytes flags: 0x0
>>  ?memory[0x3]??? [0x8e300000-0x8ecfffff], 0x00a00000 bytes flags: 0x0
>>  ?memory[0x4]??? [0x90d00000-0xbfffffff], 0x2f300000 bytes flags: 0x0
>>  ?memory[0x5]??? [0xcc000000-0xdc9fffff], 0x10a00000 bytes flags: 0x0
>>  ?memory[0x6]??? [0xde700000-0xde9fffff], 0x00300000 bytes flags: 0x0
>>  ?memory[0x7]??? [0xe0800000-0xe0bfffff], 0x00400000 bytes flags: 0x0
>>  ?memory[0x8]??? [0xf4b00000-0xf6ffffff], 0x02500000 bytes flags: 0x0
>>  ?memory[0x9]??? [0xfda00000-0xfffffffe], 0x025fffff bytes flags: 0x0
>>  ?reserved.cnt? = 0x4
>>  ?reserved[0x0]??? [0x80a00000-0x80a02fff], 0x00003000 bytes flags: 0x0
>>  ?reserved[0x1]??? [0x80a04000-0x80a07fff], 0x00004000 bytes flags: 0x0
>>  ?reserved[0x2]??? [0x80b00000-0x812e8057], 0x007e8058 bytes flags: 0x0
>>  ?reserved[0x3]??? [0x83000000-0x84ffffff], 0x02000000 bytes flags: 0x0
> ...
>> Zone ranges:
>>  ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
>>  ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
>> Movable zone start for each node
>> Early memory node ranges
>>  ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
>>  ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>  ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>  ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
>>  ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>  ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>  ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
>>  ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>  ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>  ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
>> Zeroed struct page in unavailable ranges: 513 pages
>> Initmem setup node 0 [mem 0x0000000080a00000-0x00000000ffffefff]
>> On node 0 totalpages: 311551
>>  ? Normal zone: 1230 pages used for memmap
>>  ? Normal zone: 0 pages reserved
>>  ? Normal zone: 157440 pages, LIFO batch:31
>>  ? HighMem zone: 154111 pages, LIFO batch:31
> AFAICT the range [de600000, de7ff000] should not be added to the free
> lists.
>
> Can you try with the below patch:
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..7f3c33d53f87 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1994,6 +1994,8 @@ static unsigned long __init __free_memory_core(phys_addr_t start,
>   	unsigned long end_pfn = min_t(unsigned long,
>   				      PFN_DOWN(end), max_low_pfn);
>   
> +	pr_info("%s: range: %pa - %pa, pfn: %lx - %lx\n", __func__, &start, &end, start_pfn, end_pfn);
> +
>   	if (start_pfn >= end_pfn)
>   		return 0;
>   
__free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
__free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
__free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
__free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
__free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
__free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
__free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
__free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
__free_memory_core, range: 0xaf430000 - 0xaf454000, pfn: af430 - af454
__free_memory_core, range: 0xaf510000 - 0xaf546000, pfn: af510 - af546
__free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
__free_memory_core, range: 0xafd98000 - 0xafdce000, pfn: afd98 - afdce
__free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
__free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
__free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
__free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
__free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
__free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
__free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
__free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
__free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
__free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
__free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
__free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
__free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
__free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
__free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
__free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
__free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
__free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
__free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
__free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
__free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200

>   
>>>> [<c023999c>] (get_page_from_freelist) from [<c023a4dc>] (__alloc_pages_nodemask+0x188/0xc08)
>>>> [<c023a4dc>] (__alloc_pages_nodemask) from [<c0223078>] (alloc_zeroed_user_highpage_movable+0x14/0x3c)
>>>> [<c0223078>] (alloc_zeroed_user_highpage_movable) from [<c0226768>] (handle_mm_fault+0x254/0xac8)
>>>> [<c0226768>] (handle_mm_fault) from [<c04ba09c>] (do_page_fault+0x228/0x2f4)
>>>> [<c04ba09c>] (do_page_fault) from [<c0111d80>] (do_DataAbort+0x48/0xd0)
>>>> [<c0111d80>] (do_DataAbort) from [<c0100e00>] (__dabt_usr+0x40/0x60)
>>>>
>>>>           Zone ranges:
>>>>           ? Normal?? [mem 0x0000000080a00000-0x00000000b01fffff]
>>>>           ? HighMem? [mem 0x00000000b0200000-0x00000000ffffefff]
>>>>           Movable zone start for each node
>>>>           Early memory node ranges
>>>>           ? node?? 0: [mem 0x0000000080a00000-0x00000000855fffff]
>>>>           ? node?? 0: [mem 0x0000000086a00000-0x0000000087dfffff]
>>>>           ? node?? 0: [mem 0x000000008bd00000-0x000000008c4fffff]
>>>>           ? node?? 0: [mem 0x000000008e300000-0x000000008ecfffff]
>>>>           ? node?? 0: [mem 0x0000000090d00000-0x00000000bfffffff]
>>>>           ? node?? 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
>>>>           ? node?? 0: [mem 0x00000000de700000-0x00000000de9fffff]
>>>>           ? node?? 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
>>>>           ? node?? 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
>>>>           ? node?? 0: [mem 0x00000000fda00000-0x00000000ffffefff]
>>>>
>>>>           ----> free_memmap, start_pfn = 85800,? 85800000 end_pfn = 86a00, 86a00000
>>>>           ----> free_memmap, start_pfn = 8c800,? 8c800000 end_pfn = 8e300, 8e300000
>>>>           ----> free_memmap, start_pfn = 8f000,? 8f000000 end_pfn = 90000, 90000000
>>>>           ----> free_memmap, start_pfn = dcc00,? dcc00000 end_pfn = de700, de700000
>>>>           ----> free_memmap, start_pfn = dec00,? dec00000 end_pfn = e0000, e0000000
>>>>           ----> free_memmap, start_pfn = e0c00,? e0c00000 end_pfn = e4000, e4000000
>>>>           ----> free_memmap, start_pfn = f7000,? f7000000 end_pfn = f8000, f8000000
>>>>           === >move_freepages: start_pfn/end_pfn [de601, de7ff], [de600000, de7ff000]
>>>>           :? pfn =de600 pfn2phy = de600000 , page = ef3cc000, page-flags = ffffffff
>>>>           8<--- cut here ---
>>>>           Unable to handle kernel paging request at virtual address fffffffe
>>>>           pgd = 5dd50df5
>>>>           [fffffffe] *pgd=affff861, *pte=00000000, *ppte=00000000
>>>>           Internal error: Oops: 37 [#1] SMP ARM
>>>>           Modules linked in: gmac(O)
>>>>           CPU: 2 PID: 635 Comm: test-oom Tainted: G?????????? O????? 5.10.0+ #31
>>>>           Hardware name: Hisilicon A9
>>>>           PC is at move_freepages_block+0x150/0x278
>>>>           LR is at move_freepages_block+0x150/0x278
>>>>           pc : [<c02383a4>]??? lr : [<c02383a4>]??? psr: 200e0393
>>>>           sp : c4179cf8? ip : 00000000? fp : 00000001
>>>>           r10: c4179d58? r9 : 000de7ff? r8 : 00000000
>>>>           r7 : c0863280? r6 : 000de600? r5 : 000de600? r4 : ef3cc000
>>>>           r3 : ffffffff? r2 : 00000000? r1 : ef5d069c? r0 : fffffffe
>>>>           Flags: nzCv? IRQs off? FIQs on? Mode SVC_32? ISA ARM? Segment user
>>>>           Control: 1ac5387d? Table: 83b0c04a? DAC: 55555555
>>>>           Process test-oom (pid: 635, stack limit = 0x25d667df)
>>>>
>>>>


From broonie at kernel.org  Tue Apr 27 12:12:33 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 27 Apr 2021 12:12:33 +0100
Subject: [PATCH] spi: imx: add a check for speed_hz before
 calculating the clock
In-Reply-To: <AM6PR04MB56233BE0FFF7E5D80527B54CF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>
References: <AM6PR04MB56233BE0FFF7E5D80527B54CF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>
Message-ID: <20210427111233.GD4605@sirena.org.uk>

On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:

> However, I notice that you have applied this patch to the next branch?
> Will you revert this patch?

Well, it's redundant but not harmful.

> I think you may want to apply this patch I sent before.
> 
> Author: Clark Wang <xiaoning.wang at nxp.com>
> Date:   Mon Dec 14 17:05:04 2020 +0800
> 
>     spi: imx: add 16/32 bits per word support for slave mode
>     
>     Enable 16/32 bits per word support for spi-imx slave mode.
>     It only support 8 bits per word in slave mode before.

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
-------------- 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/20210427/3d6f0ca3/attachment.sig>

From broonie at kernel.org  Tue Apr 27 12:18:33 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 27 Apr 2021 12:18:33 +0100
Subject: [PATCH] spi: imx: add a check for speed_hz before
 calculating the clock
In-Reply-To: <AM6PR04MB56233BE0FFF7E5D80527B54CF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>
References: <AM6PR04MB56233BE0FFF7E5D80527B54CF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>
Message-ID: <20210427111833.GE4605@sirena.org.uk>

On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:

> However, I notice that you have applied this patch to the next branch?
> Will you revert this patch?
> I think you may want to apply this patch I sent before.
> 
> Author: Clark Wang <xiaoning.wang at nxp.com>
> Date:   Mon Dec 14 17:05:04 2020 +0800
> 
>     spi: imx: add 16/32 bits per word support for slave mode

Oh, in this case what happened is that you sent your speed_hz patch as a
reply to this patch so the speed_hz patch looked like a replacement for
it which confused both me and the tooling.
-------------- 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/20210427/ad756438/attachment-0001.sig>

From broonie at kernel.org  Tue Apr 27 12:19:58 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 27 Apr 2021 12:19:58 +0100
Subject: [PATCH] spi: imx: remove CLK calculation and divider in slave mode
In-Reply-To: <20210427085211.299756-1-xiaoning.wang@nxp.com>
References: <20210427085211.299756-1-xiaoning.wang@nxp.com>
Message-ID: <20210427111958.GF4605@sirena.org.uk>

On Tue, Apr 27, 2021 at 04:52:11PM +0800, Clark Wang wrote:

> ---
> Please remove the patch(4df2f5e1372e spi: imx: add a check for speed_hz before
> calculating the clock) first and then apply this patch.
> Sorry about this. Thank you!
> ---

Please resumbit with a revert (with appropriate changelog) either sent
in a series with this or just squashed into this patch.
-------------- 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/20210427/0de22802/attachment.sig>

From s.nawrocki at samsung.com  Tue Apr 27 12:21:32 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 13:21:32 +0200
Subject: [PATCH v3 06/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <a561d9eb253076cbcb9debe5fcbd3c949d5023d2.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
 <CGME20210427102744eucas1p208d6f3801db6b5180e7364efc0cd83d2@eucas1p2.samsung.com>
 <a561d9eb253076cbcb9debe5fcbd3c949d5023d2.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <5aab0e11-6818-990b-f583-35036c1bb740@samsung.com>

On 27.04.2021 12:25, Mauro Carvalho Chehab wrote:
> Calling pm_runtime_get_sync() at driver's removal time is not
> needed, as this will resume PM runtime. Also, the PM runtime
> code at pm_runtime_disable() already calls it, if it detects
> the need.
> 
> So, simplify the code by getting rid of that.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 9f41c2e7097a..70e86cdc1012 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1210,8 +1210,6 @@ static int gsc_remove(struct platform_device *pdev)
>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
>  	int i;
>  
> -	pm_runtime_get_sync(&pdev->dev);
> -
>  	gsc_unregister_m2m_device(gsc);
>  	v4l2_device_unregister(&gsc->v4l2_dev);
>  
> @@ -1219,7 +1217,6 @@ static int gsc_remove(struct platform_device *pdev)
>  	for (i = 0; i < gsc->num_clocks; i++)
>  		clk_disable_unprepare(gsc->clock[i]);
>  
> -	pm_runtime_put_noidle(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);

This will result in unbalanced clk_disable_unprepare() calls when 
the device is not runtime PM active at the time of gsc_remove() call. 
I think we need to first disable runtime PM for the device and then 
disable the clocks only when pm_runtime_status_suspended(&pdev->dev)
returns false.


Thanks,
Sylwester


From xiaoning.wang at nxp.com  Tue Apr 27 12:25:31 2021
From: xiaoning.wang at nxp.com (Clark Wang)
Date: Tue, 27 Apr 2021 11:25:31 +0000
Subject: [EXT] Re: Re: [PATCH] spi: imx: add a check for speed_hz before
 calculating the clock
In-Reply-To: <20210427111833.GE4605@sirena.org.uk>
References: <AM6PR04MB56233BE0FFF7E5D80527B54CF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>
 <20210427111833.GE4605@sirena.org.uk>
Message-ID: <AM6PR04MB5623FEB82965EED9DB16C0EAF3419@AM6PR04MB5623.eurprd04.prod.outlook.com>


> -----Original Message-----
> From: Mark Brown <broonie at kernel.org>
> Sent: Tuesday, April 27, 2021 19:19
> To: Clark Wang <xiaoning.wang at nxp.com>
> Cc: shawnguo at kernel.org; s.hauer at pengutronix.de; festevam at gmail.com;
> kernel at pengutronix.de; dl-linux-imx <linux-imx at nxp.com>; linux-
> spi at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: [EXT] Re: Re: [PATCH] spi: imx: add a check for speed_hz before
> calculating the clock
> 
> On Tue, Apr 27, 2021 at 08:33:06AM +0000, Clark Wang wrote:
> 
> > However, I notice that you have applied this patch to the next branch?
> > Will you revert this patch?
> > I think you may want to apply this patch I sent before.
> >
> > Author: Clark Wang <xiaoning.wang at nxp.com>
> > Date:   Mon Dec 14 17:05:04 2020 +0800
> >
> >     spi: imx: add 16/32 bits per word support for slave mode
> 
> Oh, in this case what happened is that you sent your speed_hz patch as a
> reply to this patch so the speed_hz patch looked like a replacement for it
> which confused both me and the tooling.

I'm sorry to cause you confusion.
 1) spi: imx: add 16/32 bits per word support for slave mode and B 
 2) spi: imx: add a check for speed_hz before calculating the clock
These two patch above are two independent patches.
Now 2) is no longer needed, I just sent 3) to fix the real problem.
 3) spi: imx: remove CLK calculation and divider in slave mode

Thank you very much!

Best Regards,
Clark Wang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9583 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210427/ad69f476/attachment-0001.p7s>

From geert+renesas at glider.be  Tue Apr 27 12:29:43 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 27 Apr 2021 13:29:43 +0200
Subject: [GIT PULL] Renesas ARM DT updates for v5.13 (take three)
Message-ID: <cover.1619522726.git.geert+renesas@glider.be>

	Hi arm-soc folks,

The following changes since commit 2b35ca2fe605f85aa1a52c713571baf04a5f434a:

  arm64: dts: renesas: ulcb: Add cpu-supply property to a57_0 node (2021-04-02 09:22:35 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-dt-for-v5.13-tag3

for you to fetch changes up to 0a96c05995ef1085f9c5e6bf005a04915dd2ec6f:

  arm64: dts: renesas: Add port at 0 node for all CSI-2 nodes to dtsi (2021-04-27 09:09:03 +0200)

----------------------------------------------------------------
Renesas ARM DT updates for v5.13 (take three)

  - Fix DT schema validation errors related to CSI-2.

Note that I have rebased my branch to add Laurent's review tags, but the
actual contents are identical to what is included in next-20210427.

Thanks for pulling!

----------------------------------------------------------------
Niklas S?derlund (2):
      arm64: dts: renesas: aistarvision-mipi-adapter-2.1: Fix CSI40 ports
      arm64: dts: renesas: Add port at 0 node for all CSI-2 nodes to dtsi

 .../hihope-rzg2-ex-aistarvision-mipi-adapter-2.1.dtsi        |  2 --
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a774b1.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dts      |  2 +-
 arch/arm64/boot/dts/renesas/r8a774c0.dtsi                    |  4 ++++
 arch/arm64/boot/dts/renesas/r8a774e1.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a77950.dtsi                    |  4 ++++
 arch/arm64/boot/dts/renesas/r8a77951.dtsi                    | 12 ++++++++++++
 arch/arm64/boot/dts/renesas/r8a77960.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a77961.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a77965.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a77970.dtsi                    |  4 ++++
 arch/arm64/boot/dts/renesas/r8a77980.dtsi                    |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts               |  2 --
 arch/arm64/boot/dts/renesas/r8a77990.dtsi                    |  4 ++++
 arch/arm64/boot/dts/renesas/salvator-common.dtsi             |  3 ---
 16 files changed, 85 insertions(+), 8 deletions(-)

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 anirudha.sarangi at xilinx.com  Tue Apr 27 12:31:33 2021
From: anirudha.sarangi at xilinx.com (Anirudha Sarangi)
Date: Tue, 27 Apr 2021 17:01:33 +0530
Subject: [PATCH 0/3] Updates in irqchip framework to remove irqchip
Message-ID: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>

Available irqchip framework does not fully support use cases where an
irqchip driver has to be loaded and unloaded as a module. 
Existing Xilinx INTC driver does not have a remove path which means the
INTC IP cannot be removed from a removable partition.

Anirudha Sarangi (3):
  irqchip: xilinx: Avoid __init macro usage for xilinx_intc_of_init
  irqchip: Add support to remove irqchip driver modules.
  irqchip: xilinx: Add support to remove the Xilinx INTC driver module.

 drivers/irqchip/irq-xilinx-intc.c | 53 ++++++++++++++++++++++++++++---
 drivers/irqchip/irqchip.c         | 38 ++++++++++++++++++++--
 include/linux/irq.h               | 15 ++++++++-
 include/linux/of_irq.h            |  1 +
 kernel/irq/handle.c               |  2 +-
 5 files changed, 100 insertions(+), 9 deletions(-)

-- 
2.17.1



From anirudha.sarangi at xilinx.com  Tue Apr 27 12:31:34 2021
From: anirudha.sarangi at xilinx.com (Anirudha Sarangi)
Date: Tue, 27 Apr 2021 17:01:34 +0530
Subject: [PATCH 1/3] irqchip: xilinx: Avoid __init macro usage for
 xilinx_intc_of_init
In-Reply-To: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
Message-ID: <20210427113136.12469-2-anirudha.sarangi@xilinx.com>

This patch ensures that xilinx_intc_of_init API is not allocated into
the .init.text section. Since this API calls the API set_handle_irq
which uses __init macro to be put into .init.text section, this patch
makes changes to ensure that set_handle_irq also does not stay in
.init.text section.
This patch is in preparation for the patch through which the xilinx
intc driver will be loaded and unloaded as a module.

Signed-off-by: Anirudha Sarangi <anirudha.sarangi at xilinx.com>
---
 drivers/irqchip/irq-xilinx-intc.c | 4 ++--
 include/linux/irq.h               | 2 +-
 kernel/irq/handle.c               | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-xilinx-intc.c b/drivers/irqchip/irq-xilinx-intc.c
index 1d3d273309bd..642733a6cbdf 100644
--- a/drivers/irqchip/irq-xilinx-intc.c
+++ b/drivers/irqchip/irq-xilinx-intc.c
@@ -177,8 +177,8 @@ static void xil_intc_irq_handler(struct irq_desc *desc)
 	chained_irq_exit(chip, desc);
 }
 
-static int __init xilinx_intc_of_init(struct device_node *intc,
-					     struct device_node *parent)
+static int xilinx_intc_of_init(struct device_node *intc,
+			       struct device_node *parent)
 {
 	struct xintc_irq_chip *irqc;
 	int ret, irq;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 2efde6a79b7e..252fab8074de 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1250,7 +1250,7 @@ int ipi_send_mask(unsigned int virq, const struct cpumask *dest);
  * Returns 0 on success, or -EBUSY if an IRQ handler has already been
  * registered.
  */
-int __init set_handle_irq(void (*handle_irq)(struct pt_regs *));
+int set_handle_irq(void (*handle_irq)(struct pt_regs *));
 
 /*
  * Allows interrupt handlers to find the irqchip that's been registered as the
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 762a928e18f9..a0b18e8f5af0 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -218,7 +218,7 @@ irqreturn_t handle_irq_event(struct irq_desc *desc)
 }
 
 #ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
-int __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
+int set_handle_irq(void (*handle_irq)(struct pt_regs *))
 {
 	if (handle_arch_irq)
 		return -EBUSY;
-- 
2.17.1



From anirudha.sarangi at xilinx.com  Tue Apr 27 12:31:35 2021
From: anirudha.sarangi at xilinx.com (Anirudha Sarangi)
Date: Tue, 27 Apr 2021 17:01:35 +0530
Subject: [PATCH 2/3] irqchip: Add support to remove irqchip driver modules.
In-Reply-To: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
Message-ID: <20210427113136.12469-3-anirudha.sarangi@xilinx.com>

The existing irqchip implementation does not fully support use cases
where an irqchip driver has to be used as a module. In particular there
is no support to remove an irqchip driver module.
The use cases where an irqchip driver has to be loaded and then removed
as a module are really relevant in fpga world. A user can decide to
have a irqchip as part of a removable partial fpga region. In such cases
not only the corresponding irqchip driver has to be loaded as a module,
but must also be removed when the removable partial region is removed.

The existing implementation updates the existing framework to achieve
the above said goal.

Signed-off-by: Anirudha Sarangi <anirudha.sarangi at xilinx.com>
---
 drivers/irqchip/irqchip.c | 38 +++++++++++++++++++++++++++++++++++---
 include/linux/irq.h       | 13 +++++++++++++
 include/linux/of_irq.h    |  1 +
 3 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 3570f0a588c4..8687131e7268 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -15,6 +15,11 @@
 #include <linux/irqchip.h>
 #include <linux/platform_device.h>
 
+struct platform_irqchip_instance {
+	of_irq_init_cb_t irq_init_cb;
+	of_irq_remove_cb_t irq_remove_cb;
+};
+
 /*
  * This special of_device_id is the sentinel at the end of the
  * of_device_id[] array of all irqchips. It is automatically placed at
@@ -34,11 +39,22 @@ void __init irqchip_init(void)
 
 int platform_irqchip_probe(struct platform_device *pdev)
 {
+	struct platform_irqchip_instance *irqchip;
+	const struct irqc_init_remove_funps *irqchip_funps;
 	struct device_node *np = pdev->dev.of_node;
 	struct device_node *par_np = of_irq_find_parent(np);
-	of_irq_init_cb_t irq_init_cb = of_device_get_match_data(&pdev->dev);
 
-	if (!irq_init_cb)
+	irqchip = devm_kzalloc(&pdev->dev, sizeof(*irqchip), GFP_KERNEL);
+	if (!irqchip)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, irqchip);
+
+	irqchip_funps = of_device_get_match_data(&pdev->dev);
+	irqchip->irq_init_cb =	irqchip_funps->irqchip_initp;
+	irqchip->irq_remove_cb = irqchip_funps->irqchip_removep;
+
+	if (!irqchip->irq_init_cb)
 		return -EINVAL;
 
 	if (par_np == np)
@@ -55,6 +71,22 @@ int platform_irqchip_probe(struct platform_device *pdev)
 	if (par_np && !irq_find_matching_host(par_np, DOMAIN_BUS_ANY))
 		return -EPROBE_DEFER;
 
-	return irq_init_cb(np, par_np);
+	return irqchip->irq_init_cb(np, par_np);
 }
 EXPORT_SYMBOL_GPL(platform_irqchip_probe);
+
+int platform_irqchip_remove(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *par_np = of_irq_find_parent(np);
+	struct platform_irqchip_instance *irqchip = platform_get_drvdata(pdev);
+
+	if (!irqchip->irq_remove_cb)
+		return -EINVAL;
+
+	if (par_np == np)
+		par_np = NULL;
+
+	return irqchip->irq_remove_cb(np, par_np);
+}
+EXPORT_SYMBOL_GPL(platform_irqchip_remove);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 252fab8074de..d46d28f56bc0 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1098,6 +1098,19 @@ struct irq_domain_chip_generic {
 	struct irq_chip_generic	*gc[];
 };
 
+/**
+ * struct irqc_init_remove_funps - Stores function pointers for irqc init
+ * and remove APIs. Used when the irqchip driver is to be used as a module.
+ * @irqchip_initp:	Function pointer for init/entry point of a irqchip driver.
+ * @irqchip_removep:Function pointer for irqchip driver remove function.
+ */
+struct irqc_init_remove_funps {
+	int (*irqchip_initp)(struct device_node *irqc,
+			     struct device_node *parent);
+	int (*irqchip_removep)(struct device_node *irqc,
+			       struct device_node *parent);
+};
+
 /* Generic chip callback functions */
 void irq_gc_noop(struct irq_data *d);
 void irq_gc_mask_disable_reg(struct irq_data *d);
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index aaf219bd0354..4210ac64956f 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -10,6 +10,7 @@
 #include <linux/of.h>
 
 typedef int (*of_irq_init_cb_t)(struct device_node *, struct device_node *);
+typedef int (*of_irq_remove_cb_t)(struct device_node *, struct device_node *);
 
 /*
  * Workarounds only applied to 32bit powermac machines
-- 
2.17.1



From anirudha.sarangi at xilinx.com  Tue Apr 27 12:31:36 2021
From: anirudha.sarangi at xilinx.com (Anirudha Sarangi)
Date: Tue, 27 Apr 2021 17:01:36 +0530
Subject: [PATCH 3/3] irqchip: xilinx: Add support to remove the Xilinx INTC
 driver module.
In-Reply-To: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
Message-ID: <20210427113136.12469-4-anirudha.sarangi@xilinx.com>

The existing Xilinx INTC driver does not have mechanism to remove the
driver when it is being used as a module. For example, if the Xilinx
INTC IP is part of a removable fpga partition and a user intends to
replace the removable partition with a new one, the existing
implementation will not support the same.
The enhancement is done by adding a new remove API and making other
necessary changes.

Signed-off-by: Anirudha Sarangi <anirudha.sarangi at xilinx.com>
---
 drivers/irqchip/irq-xilinx-intc.c | 49 +++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-xilinx-intc.c b/drivers/irqchip/irq-xilinx-intc.c
index 642733a6cbdf..2c5b76efabf6 100644
--- a/drivers/irqchip/irq-xilinx-intc.c
+++ b/drivers/irqchip/irq-xilinx-intc.c
@@ -39,6 +39,7 @@ struct xintc_irq_chip {
 	struct		irq_domain *root_domain;
 	u32		intr_mask;
 	u32		nr_irq;
+	int		irq;
 };
 
 static struct xintc_irq_chip *primary_intc;
@@ -234,6 +235,8 @@ static int xilinx_intc_of_init(struct device_node *intc,
 
 	if (parent) {
 		irq = irq_of_parse_and_map(intc, 0);
+		irqc->irq = irq;
+		intc->data = irqc;
 		if (irq) {
 			irq_set_chained_handler_and_data(irq,
 							 xil_intc_irq_handler,
@@ -257,5 +260,47 @@ static int xilinx_intc_of_init(struct device_node *intc,
 
 }
 
-IRQCHIP_DECLARE(xilinx_intc_xps, "xlnx,xps-intc-1.00.a", xilinx_intc_of_init);
-IRQCHIP_DECLARE(xilinx_intc_opb, "xlnx,opb-intc-1.00.c", xilinx_intc_of_init);
+static int xilinx_intc_of_remove(struct device_node *intc,
+				 struct device_node *parent)
+{
+	int irq;
+	struct xintc_irq_chip *irqc;
+
+	if (!parent)
+		return 0;
+
+	irqc = intc->data;
+	irq = irqc->irq;
+	irq_set_chained_handler_and_data(irq, NULL, NULL);
+	if (irqc->domain) {
+		irq_dispose_mapping(irq);
+		irq_domain_remove(irqc->domain);
+	}
+	/*
+	 * Disable all external interrupts until they are
+	 * explicity requested.
+	 */
+	xintc_write(irqc, IER, 0);
+	/* Acknowledge any pending interrupts just in case. */
+	xintc_write(irqc, IAR, 0xffffffff);
+	/* Turn off the Master Enable. */
+	xintc_write(irqc, MER, 0x0);
+
+	iounmap(irqc->base);
+	kfree(irqc);
+
+	return 0;
+}
+
+static struct irqc_init_remove_funps intc_funps = {
+		.irqchip_initp = xilinx_intc_of_init,
+		.irqchip_removep = xilinx_intc_of_remove,
+};
+
+IRQCHIP_PLATFORM_DRIVER_BEGIN(xilinx_intc_xps)
+IRQCHIP_MATCH("xlnx,xps-intc-1.00.a", &intc_funps)
+IRQCHIP_PLATFORM_DRIVER_END(xilinx_intc_xps)
+
+IRQCHIP_PLATFORM_DRIVER_BEGIN(xilinx_intc_opb)
+IRQCHIP_MATCH("xlnx,opb-intc-1.00.c", &intc_funps)
+IRQCHIP_PLATFORM_DRIVER_END(xilinx_intc_opb)
-- 
2.17.1



From dietmar.eggemann at arm.com  Tue Apr 27 12:35:35 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Tue, 27 Apr 2021 13:35:35 +0200
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <20210420001844.9116-4-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
 <20210420001844.9116-4-song.bao.hua@hisilicon.com>
Message-ID: <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>

On 20/04/2021 02:18, Barry Song wrote:

[...]

> @@ -5786,11 +5786,12 @@ static void record_wakee(struct task_struct *p)
>   * whatever is irrelevant, spread criteria is apparent partner count exceeds
>   * socket size.
>   */
> -static int wake_wide(struct task_struct *p)
> +static int wake_wide(struct task_struct *p, int cluster)
>  {
>  	unsigned int master = current->wakee_flips;
>  	unsigned int slave = p->wakee_flips;
> -	int factor = __this_cpu_read(sd_llc_size);
> +	int factor = cluster ? __this_cpu_read(sd_cluster_size) :
> +		__this_cpu_read(sd_llc_size);

I don't see that the wake_wide() change has any effect here. None of the
sched domains has SD_BALANCE_WAKE set so a wakeup (WF_TTWU) can never
end up in the slow path.
Have you seen a diff when running your `lmbench stream` workload in what
wake_wide() returns when you use `sd cluster size` instead of `sd llc
size` as factor?

I guess for you,  wakeups are now subdivided into faster (cluster = 4
CPUs) and fast (llc = 24 CPUs) via sis(), not into fast (sis()) and slow
(find_idlest_cpu()).

>  
>  	if (master < slave)
>  		swap(master, slave);

[...]

> @@ -6745,6 +6748,12 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  	int want_affine = 0;
>  	/* SD_flags and WF_flags share the first nibble */
>  	int sd_flag = wake_flags & 0xF;
> +	/*
> +	 * if cpu and prev_cpu share LLC, consider cluster sibling rather
> +	 * than llc. this is typically true while tasks are bound within
> +	 * one numa
> +	 */
> +	int cluster = sched_cluster_active() && cpus_share_cache(cpu, prev_cpu, 0);

So you changed from scanning cluster before LLC to scan either cluster
or LLC.

And this is based on whether `this_cpu` and `prev_cpu` are sharing LLC
or not. So you only see an effect when running the workload with
`numactl -N X ...`.

>  
>  	if (wake_flags & WF_TTWU) {
>  		record_wakee(p);
> @@ -6756,7 +6765,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  			new_cpu = prev_cpu;
>  		}
>  
> -		want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
> +		want_affine = !wake_wide(p, cluster) && cpumask_test_cpu(cpu, p->cpus_ptr);
>  	}
>  
>  	rcu_read_lock();
> @@ -6768,7 +6777,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  		if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
>  		    cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
>  			if (cpu != prev_cpu)
> -				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
> +				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync, cluster);
>  
>  			sd = NULL; /* Prefer wake_affine over balance flags */
>  			break;
> @@ -6785,7 +6794,7 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>  		new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
>  	} else if (wake_flags & WF_TTWU) { /* XXX always ? */
>  		/* Fast path */
> -		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
> +		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu, cluster);
>  
>  		if (want_affine)
>  			current->recent_used_cpu = cpu;

[...]


From bp at alien8.de  Tue Apr 27 12:38:40 2021
From: bp at alien8.de (Borislav Petkov)
Date: Tue, 27 Apr 2021 13:38:40 +0200
Subject: [PATCH v2 8/9] KVM: x86: add force_intercept_exceptions_mask
In-Reply-To: <20210401135451.1004564-9-mlevitsk@redhat.com>
References: <20210401135451.1004564-1-mlevitsk@redhat.com>
 <20210401135451.1004564-9-mlevitsk@redhat.com>
Message-ID: <YIf3wM1+enU1U/gn@zn.tnic>

On Thu, Apr 01, 2021 at 04:54:50PM +0300, Maxim Levitsky wrote:
> This parameter will be used by VMX and SVM code to force
> interception of a set of exceptions, given by a bitmask
> for guest debug and/or kvm debug.
> 
> This option is not intended for production.
> 
> This is based on an idea first shown here:
> https://patchwork.kernel.org/project/kvm/patch/20160301192822.GD22677 at pd.tnic/
> 
> CC: Borislav Petkov <bp at suse.de>
> Signed-off-by: Maxim Levitsky <mlevitsk at redhat.com>
> ---
>  arch/x86/kvm/x86.c | 3 +++
>  arch/x86/kvm/x86.h | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 3627ce8fe5bb..1a51031d64d8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -176,6 +176,9 @@ module_param(force_emulation_prefix, bool, S_IRUGO);
>  int __read_mostly pi_inject_timer = -1;
>  module_param(pi_inject_timer, bint, S_IRUGO | S_IWUSR);
>  
> +uint force_intercept_exceptions_mask;
> +module_param(force_intercept_exceptions_mask, uint, S_IRUGO | S_IWUSR);
> +EXPORT_SYMBOL_GPL(force_intercept_exceptions_mask);

That's nice.

I could use some text explaning the usage though, i.e. that thing takes
a bitfield of exception vectors, so that I don't have to look at the
code each time. :-)

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette


From yang.lee at linux.alibaba.com  Tue Apr 27 12:41:13 2021
From: yang.lee at linux.alibaba.com (Yang Li)
Date: Tue, 27 Apr 2021 19:41:13 +0800
Subject: [Resend PATCH v2] soc: ti: smartreflex after the relocation to
 maintain 
Message-ID: <1619523673-120782-1-git-send-email-yang.lee@linux.alibaba.com>

Fix the following coccicheck warning:
./drivers/soc/ti/smartreflex.c:820:0-23: WARNING: pm_sr_fops should be
defined with DEFINE_DEBUGFS_ATTRIBUTE

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
Reviewed-by: Nishanth Menon <nm at ti.com>
---

Change in v2:
--According to Nishanth Menon's suggestion, the subject has been 
corrected.
https://lore.kernel.org/patchwork/patch/1383883/

 drivers/soc/ti/smartreflex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c
index 5376f3d..b3c7460 100644
--- a/drivers/soc/ti/smartreflex.c
+++ b/drivers/soc/ti/smartreflex.c
@@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
 	return 0;
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
+DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
 			omap_sr_autocomp_store, "%llu\n");
 
 static int omap_sr_probe(struct platform_device *pdev)
-- 
1.8.3.1



From andy.shevchenko at gmail.com  Tue Apr 27 12:46:02 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 27 Apr 2021 14:46:02 +0300
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
Message-ID: <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>

On Fri, Apr 23, 2021 at 9:25 PM Andy Shevchenko
<andriy.shevchenko at linux.intel.com> wrote:
>
> Set of cleanups here and there related to the SPI PXA2xx driver.
> On top of them, adding the special type for Intel Merrifield.

Mark, are you accepting patches for v5.14 now, or should I resend
after v5.13-rc1 is out?

(I have few more in my queue :-)

> In v2:
> - cover letter (Mark)
> - drop moving the header in patch 5 (Mark)
>
> Andy Shevchenko (14):
>   spi: pxa2xx: Use one point of return when ->probe() fails
>   spi: pxa2xx: Utilize MMIO and physical base from struct ssp_device
>   spi: pxa2xx: Utilize struct device from struct ssp_device
>   spi: pxa2xx: Replace header inclusions by forward declarations
>   spi: pxa2xx: Unify ifdeffery used in the headers
>   spi: pxa2xx: Group Intel Quark specific definitions
>   spi: pxa2xx: Introduce int_stop_and_reset() helper
>   spi: pxa2xx: Reuse int_error_stop() in pxa2xx_spi_slave_abort()
>   spi: pxa2xx: Use pxa_ssp_enable()/pxa_ssp_disable() in the driver
>   spi: pxa2xx: Extract pxa2xx_spi_update() helper
>   spi: pxa2xx: Extract clear_SSCR1_bits() helper
>   spi: pxa2xx: Extract read_SSSR_bits() helper
>   spi: pxa2xx: Constify struct driver_data parameter
>   spi: pxa2xx: Introduce special type for Merrifield SPIs
>
>  drivers/spi/spi-pxa2xx-dma.c   |  37 +++----
>  drivers/spi/spi-pxa2xx-pci.c   |   4 +-
>  drivers/spi/spi-pxa2xx.c       | 190 +++++++++++++++++----------------
>  drivers/spi/spi-pxa2xx.h       |  52 ++++-----
>  include/linux/pxa2xx_ssp.h     |  42 +++++++-
>  include/linux/spi/pxa2xx_spi.h |   9 +-
>  sound/soc/pxa/pxa-ssp.c        |  16 ---
>  7 files changed, 185 insertions(+), 165 deletions(-)
>
> --
> 2.30.2
>


-- 
With Best Regards,
Andy Shevchenko


From s.nawrocki at samsung.com  Tue Apr 27 12:50:44 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 13:50:44 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <20210427114235.45a7b2a4@coco.lan>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
 <20210427113055.745d0560@coco.lan> <20210427114235.45a7b2a4@coco.lan>
Message-ID: <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>

On 27.04.2021 11:42, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Apr 2021 11:30:55 +0200
> Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:
> 
>> Em Tue, 27 Apr 2021 10:18:12 +0200
>> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
>>
>>> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:  
>>>> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
>>>> added pm_runtime_resume_and_get() in order to automatically handle
>>>> dev->power.usage_count decrement on errors.
>>>>
>>>> Use the new API, in order to cleanup the error check logic.
>>>>
>>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
>>>> ---
>>>>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
>>>>  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
>>>>  2 files changed, 2 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
>>>> index 9f41c2e7097a..9d5841194f6b 100644
>>>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
>>>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
>>>> @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
>>>>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
>>>>  	int i;
>>>>  
>>>> -	pm_runtime_get_sync(&pdev->dev);
>>>> +	pm_runtime_resume_and_get(&pdev->dev);
>>>>  
>>>>  	gsc_unregister_m2m_device(gsc);
>>>>  	v4l2_device_unregister(&gsc->v4l2_dev);
>>>> @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
>>>>  	for (i = 0; i < gsc->num_clocks; i++)
>>>>  		clk_disable_unprepare(gsc->clock[i]);
>>>>  
>>>> -	pm_runtime_put_noidle(&pdev->dev);    
>>>
>>> If we do this then the device usage count will not get decremented
>>> after the pm_runtime_resume_and_get() call above and after driver
>>> unload/load cycle it will not be possible to suspend the device.
>>> I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
>>> works better in that case.  
>>
>> Good point.
>>
>> Actually, I don't see any reason why to call a PM resume
>> function - either being pm_runtime_get_sync() or
>> pm_runtime_resume_and_get().
>>
>> The code there could simply be:
>>
>>     static int gsc_remove(struct platform_device *pdev)
>>     {
>>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
>>         int i;
>>
>>         gsc_unregister_m2m_device(gsc);
>>         v4l2_device_unregister(&gsc->v4l2_dev);
>>
>>         vb2_dma_contig_clear_max_seg_size(&pdev->dev);
>>         for (i = 0; i < gsc->num_clocks; i++)
>>                 clk_disable_unprepare(gsc->clock[i]);
>>
>>         pm_runtime_disable(&pdev->dev);
>>
>>         dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
>>         return 0;
>>     }
>>
>> Eventually also adding:
>> 	pm_runtime_suspended(&pdev->dev);
> 
> In time: I actually meant:
> 
> 	pm_runtime_set_suspended(&pdev->dev);
> 
> but after double-checking the PM runtime code, it sounds to me that
> just calling pm_runtime_disable() would be enough. Not 100% sure
> here. Btw, some media drivers call it after pm_runtime_disable(),
> while others don't do.

I think if the device is brought into suspended state (e.g. by
disabling clocks as above) the pm_runtime_set_suspended() call
should be there. IOW a following sequence: 

	pm_runtime_disable(dev);
	if (!pm_runtime_status_suspended(dev))
		/* put device into suspended state (disable clocks, 
		  voltage regulators, assert GPIOs, etc. */
	pm_runtime_set_suspended(dev);

--
Regards,
Sylwester


From m.felsch at pengutronix.de  Tue Apr 27 13:07:01 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:07:01 +0200
Subject: [PATCH 6/6] media: imx: csi: add custom SGRGB_IGIG_GBGR_IGIG format
 support
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-7-m.felsch@pengutronix.de>

Add custom OnSemi RGB-IR pixel formats which is used by the OnSemi
AR0237IR sensor [1]. The colorspace is irrelevant since the
user space has to debayer the images.

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/staging/media/imx/imx-media-csi.c   |  2 ++
 drivers/staging/media/imx/imx-media-utils.c | 12 ++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
index e3bfd635a89a..1085feacf27f 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -448,6 +448,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
 	case V4L2_PIX_FMT_SGBRG8:
 	case V4L2_PIX_FMT_SGRBG8:
 	case V4L2_PIX_FMT_SRGGB8:
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8:
 	case V4L2_PIX_FMT_GREY:
 		burst_size = 16;
 		passthrough_bits = 8;
@@ -456,6 +457,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
 	case V4L2_PIX_FMT_SGBRG16:
 	case V4L2_PIX_FMT_SGRBG16:
 	case V4L2_PIX_FMT_SRGGB16:
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16:
 	case V4L2_PIX_FMT_Y10:
 	case V4L2_PIX_FMT_Y12:
 		burst_size = 8;
diff --git a/drivers/staging/media/imx/imx-media-utils.c b/drivers/staging/media/imx/imx-media-utils.c
index 5128915a5d6f..c4ed8bf89b31 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -174,6 +174,18 @@ static const struct imx_media_pixfmt pixel_formats[] = {
 		.cs     = IPUV3_COLORSPACE_RGB,
 		.bpp    = 16,
 		.bayer  = true,
+	}, {
+		.fourcc = V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8,
+		.codes  = IMX_BUS_FMTS(MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8),
+		.cs     = IPUV3_COLORSPACE_RGB,
+		.bpp    = 8,
+		.bayer  = true,
+	}, {
+		.fourcc = V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16,
+		.codes  = IMX_BUS_FMTS(MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12),
+		.cs     = IPUV3_COLORSPACE_RGB,
+		.bpp    = 16,
+		.bayer  = true,
 	}, {
 		.fourcc = V4L2_PIX_FMT_GREY,
 		.codes = IMX_BUS_FMTS(
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:06:55 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:06:55 +0200
Subject: [PATCH 0/6] Add new bayer ir formats
Message-ID: <20210427120701.21809-1-m.felsch@pengutronix.de>

Hi all,

this adds the inital support for a new sensor format called RGB-IR
found on sensors from OnSemi [1]. This is a new custom bayer format with
interleaved ir pixels. For more information see the documentation
commit.

[1] https://www.onsemi.com/products/sensors/image-sensors-processors/image-sensors/ar0237sr

Marco Felsch (6):
  media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media bus formats
  media: v4l: Add definition for bayered IR formats
  media: v4l2-ioctl.c: add V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG to
    v4l_fill_fmtdesc
  media: video-mux: add new SGRGB_IGIG_GBGR_IGIG format support
  gpu: ipu-v3: add custom SGRGB_IGIG_GBGR_IGIG format support
  media: imx: csi: add custom SGRGB_IGIG_GBGR_IGIG format support

 .../media/v4l/subdev-formats.rst              | 42 +++++++++++++++++++
 drivers/gpu/ipu-v3/ipu-cpmem.c                |  2 +
 drivers/gpu/ipu-v3/ipu-csi.c                  |  2 +
 drivers/media/platform/video-mux.c            |  2 +
 drivers/media/v4l2-core/v4l2-ioctl.c          |  2 +
 drivers/staging/media/imx/imx-media-csi.c     |  2 +
 drivers/staging/media/imx/imx-media-utils.c   | 12 ++++++
 include/uapi/linux/media-bus-format.h         |  4 +-
 include/uapi/linux/videodev2.h                |  4 ++
 9 files changed, 71 insertions(+), 1 deletion(-)

-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:06:57 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:06:57 +0200
Subject: [PATCH 2/6] media: v4l: Add definition for bayered IR formats
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-3-m.felsch@pengutronix.de>

Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
with the interleaved IR pixels looks like:

        |  G |  R |  G |  B | ...
        +----+----+----+----+---
        | IR |  G | IR |  G | ...
        +----+----+----+----+---
        |  G |  B |  G |  R | ...
        +----+----+----+----+---
        | IR |  G | IR |  G | ...
        +----+----+----+----+---
        | .. | .. | .. | .. | ..

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 include/uapi/linux/videodev2.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 311a01cc5775..45ffd3867394 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -632,6 +632,8 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SGBRG8  v4l2_fourcc('G', 'B', 'R', 'G') /*  8  GBGB.. RGRG.. */
 #define V4L2_PIX_FMT_SGRBG8  v4l2_fourcc('G', 'R', 'B', 'G') /*  8  GRGR.. BGBG.. */
 #define V4L2_PIX_FMT_SRGGB8  v4l2_fourcc('R', 'G', 'G', 'B') /*  8  RGRG.. GBGB.. */
+	/* 8bit infrared interleaved bayer format */
+#define V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8 v4l2_fourcc('I', 'R', '0', '8') /* 8 GRGB.. IGIG.. GBGR.. IGIG.. */
 #define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10  BGBG.. GRGR.. */
 #define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10  GBGB.. RGRG.. */
 #define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10  GRGR.. BGBG.. */
@@ -673,6 +675,8 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SGBRG16 v4l2_fourcc('G', 'B', '1', '6') /* 16  GBGB.. RGRG.. */
 #define V4L2_PIX_FMT_SGRBG16 v4l2_fourcc('G', 'R', '1', '6') /* 16  GRGR.. BGBG.. */
 #define V4L2_PIX_FMT_SRGGB16 v4l2_fourcc('R', 'G', '1', '6') /* 16  RGRG.. GBGB.. */
+	/* 16bit infrared interleaved bayer format */
+#define V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16 v4l2_fourcc('I', 'R', '1', '6') /* 16 GRGB.. IGIG.. GBGR.. IGIG.. */
 
 /* HSV formats */
 #define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:06:56 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:06:56 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG media
 bus formats
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-2-m.felsch@pengutronix.de>

Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
with the interleaved IR pixels looks like:

        |  G |  R |  G |  B | ...
        +----+----+----+----+---
        | IR |  G | IR |  G | ...
        +----+----+----+----+---
        |  G |  B |  G |  R | ...
        +----+----+----+----+---
        | IR |  G | IR |  G | ...
        +----+----+----+----+---
        | .. | .. | .. | .. | ..

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
---
 .../media/v4l/subdev-formats.rst              | 42 +++++++++++++++++++
 include/uapi/linux/media-bus-format.h         |  4 +-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index bd68588b2683..d774ccd57c1b 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -2252,6 +2252,27 @@ organization is given as an example for the first pixel only.
       - g\ :sub:`2`
       - g\ :sub:`1`
       - g\ :sub:`0`
+    * .. _MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8:
+
+      - MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8
+      - 0x3021
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      -
+      - g\ :sub:`7`
+      - g\ :sub:`6`
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
     * .. _MEDIA-BUS-FMT-SRGGB8-1X8:
 
       - MEDIA_BUS_FMT_SRGGB8_1X8
@@ -2748,6 +2769,27 @@ organization is given as an example for the first pixel only.
       - g\ :sub:`2`
       - g\ :sub:`1`
       - g\ :sub:`0`
+    * .. _MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12:
+
+      - MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12
+      - 0x3022
+      -
+      -
+      -
+      -
+      -
+      - g\ :sub:`11`
+      - g\ :sub:`10`
+      - g\ :sub:`9`
+      - g\ :sub:`8`
+      - g\ :sub:`7`
+      - g\ :sub:`6`
+      - g\ :sub:`5`
+      - g\ :sub:`4`
+      - g\ :sub:`3`
+      - g\ :sub:`2`
+      - g\ :sub:`1`
+      - g\ :sub:`0`
     * .. _MEDIA-BUS-FMT-SRGGB12-1X12:
 
       - MEDIA_BUS_FMT_SRGGB12_1X12
diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
index 0dfc11ee243a..cdd995e44926 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -112,10 +112,11 @@
 #define MEDIA_BUS_FMT_YUV16_1X48		0x202a
 #define MEDIA_BUS_FMT_UYYVYY16_0_5X48		0x202b
 
-/* Bayer - next is	0x3021 */
+/* Bayer - next is	0x3023 */
 #define MEDIA_BUS_FMT_SBGGR8_1X8		0x3001
 #define MEDIA_BUS_FMT_SGBRG8_1X8		0x3013
 #define MEDIA_BUS_FMT_SGRBG8_1X8		0x3002
+#define MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8	0x3021
 #define MEDIA_BUS_FMT_SRGGB8_1X8		0x3014
 #define MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8		0x3015
 #define MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8		0x3016
@@ -136,6 +137,7 @@
 #define MEDIA_BUS_FMT_SBGGR12_1X12		0x3008
 #define MEDIA_BUS_FMT_SGBRG12_1X12		0x3010
 #define MEDIA_BUS_FMT_SGRBG12_1X12		0x3011
+#define MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12	0x3022
 #define MEDIA_BUS_FMT_SRGGB12_1X12		0x3012
 #define MEDIA_BUS_FMT_SBGGR14_1X14		0x3019
 #define MEDIA_BUS_FMT_SGBRG14_1X14		0x301a
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:06:59 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:06:59 +0200
Subject: [PATCH 4/6] media: video-mux: add new SGRGB_IGIG_GBGR_IGIG format
 support
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-5-m.felsch@pengutronix.de>

Add custom OnSemi RGB-IR pixel formats. This format is used by the OnSemi
AR0237IR camera sensor [1].

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/media/platform/video-mux.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
index 133122e38515..aaec24d60101 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -268,6 +268,7 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
 	case MEDIA_BUS_FMT_SGBRG8_1X8:
 	case MEDIA_BUS_FMT_SGRBG8_1X8:
 	case MEDIA_BUS_FMT_SRGGB8_1X8:
+	case MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8:
 	case MEDIA_BUS_FMT_SBGGR10_1X10:
 	case MEDIA_BUS_FMT_SGBRG10_1X10:
 	case MEDIA_BUS_FMT_SGRBG10_1X10:
@@ -276,6 +277,7 @@ static int video_mux_set_format(struct v4l2_subdev *sd,
 	case MEDIA_BUS_FMT_SGBRG12_1X12:
 	case MEDIA_BUS_FMT_SGRBG12_1X12:
 	case MEDIA_BUS_FMT_SRGGB12_1X12:
+	case MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12:
 	case MEDIA_BUS_FMT_SBGGR14_1X14:
 	case MEDIA_BUS_FMT_SGBRG14_1X14:
 	case MEDIA_BUS_FMT_SGRBG14_1X14:
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:07:00 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:07:00 +0200
Subject: [PATCH 5/6] gpu: ipu-v3: add custom SGRGB_IGIG_GBGR_IGIG format
 support
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-6-m.felsch@pengutronix.de>

Add custom OnSemi RGB-IR pixel formats to the ipu library functions. This
format is used by the OnSemi AR0237IR camera sensor [1].

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/gpu/ipu-v3/ipu-cpmem.c | 2 ++
 drivers/gpu/ipu-v3/ipu-csi.c   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index a1c85d1521f5..c579aafb60ba 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -861,6 +861,7 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct ipu_image *image)
 	case V4L2_PIX_FMT_SGBRG8:
 	case V4L2_PIX_FMT_SGRBG8:
 	case V4L2_PIX_FMT_SRGGB8:
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8:
 	case V4L2_PIX_FMT_GREY:
 		offset = image->rect.left + image->rect.top * pix->bytesperline;
 		break;
@@ -868,6 +869,7 @@ int ipu_cpmem_set_image(struct ipuv3_channel *ch, struct ipu_image *image)
 	case V4L2_PIX_FMT_SGBRG16:
 	case V4L2_PIX_FMT_SGRBG16:
 	case V4L2_PIX_FMT_SRGGB16:
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16:
 	case V4L2_PIX_FMT_Y16:
 		offset = image->rect.left * 2 +
 			 image->rect.top * pix->bytesperline;
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 8ae301eef643..cf7763f50fdf 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -268,6 +268,7 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code,
 	case MEDIA_BUS_FMT_SGBRG8_1X8:
 	case MEDIA_BUS_FMT_SGRBG8_1X8:
 	case MEDIA_BUS_FMT_SRGGB8_1X8:
+	case MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8:
 	case MEDIA_BUS_FMT_Y8_1X8:
 		cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
 		cfg->mipi_dt = MIPI_DT_RAW8;
@@ -298,6 +299,7 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config *cfg, u32 mbus_code,
 	case MEDIA_BUS_FMT_SGBRG12_1X12:
 	case MEDIA_BUS_FMT_SGRBG12_1X12:
 	case MEDIA_BUS_FMT_SRGGB12_1X12:
+	case MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12:
 	case MEDIA_BUS_FMT_Y12_1X12:
 		cfg->data_fmt = CSI_SENS_CONF_DATA_FMT_BAYER;
 		cfg->mipi_dt = MIPI_DT_RAW12;
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:06:58 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:06:58 +0200
Subject: [PATCH 3/6] media: v4l2-ioctl.c: add
 V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG to v4l_fill_fmtdesc
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120701.21809-4-m.felsch@pengutronix.de>

Add custom OnSemi RGB-IR pixel formats to the list of pixelformats
that v4l_fill_fmtdesc() understands. This format is used by the OnSemi
AR0237IR camera sensor [1].

[1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 6a5d1c6d11d6..e9d0c9417719 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1337,6 +1337,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 	case V4L2_PIX_FMT_SGBRG8:	descr = "8-bit Bayer GBGB/RGRG"; break;
 	case V4L2_PIX_FMT_SGRBG8:	descr = "8-bit Bayer GRGR/BGBG"; break;
 	case V4L2_PIX_FMT_SRGGB8:	descr = "8-bit Bayer RGRG/GBGB"; break;
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8: descr = "8-bit GRGB/IGIG/GBGR/IGIG"; break;
 	case V4L2_PIX_FMT_SBGGR10:	descr = "10-bit Bayer BGBG/GRGR"; break;
 	case V4L2_PIX_FMT_SGBRG10:	descr = "10-bit Bayer GBGB/RGRG"; break;
 	case V4L2_PIX_FMT_SGRBG10:	descr = "10-bit Bayer GRGR/BGBG"; break;
@@ -1377,6 +1378,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
 	case V4L2_PIX_FMT_SGBRG16:	descr = "16-bit Bayer GBGB/RGRG"; break;
 	case V4L2_PIX_FMT_SGRBG16:	descr = "16-bit Bayer GRGR/BGBG"; break;
 	case V4L2_PIX_FMT_SRGGB16:	descr = "16-bit Bayer RGRG/GBGB"; break;
+	case V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16: descr = "16-bit GRGB/IGIG/GBGR/IGIG"; break;
 	case V4L2_PIX_FMT_SN9C20X_I420:	descr = "GSPCA SN9C20X I420"; break;
 	case V4L2_PIX_FMT_SPCA501:	descr = "GSPCA SPCA501"; break;
 	case V4L2_PIX_FMT_SPCA505:	descr = "GSPCA SPCA505"; break;
-- 
2.29.2



From m.felsch at pengutronix.de  Tue Apr 27 13:09:43 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Tue, 27 Apr 2021 14:09:43 +0200
Subject: [PATCH 0/6] Add new bayer ir formats
In-Reply-To: <20210427120701.21809-1-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
Message-ID: <20210427120943.owuah4pbzfjtk3za@pengutronix.de>

On 21-04-27 14:06, Marco Felsch wrote:
> Hi all,
> 
> this adds the inital support for a new sensor format called RGB-IR
> found on sensors from OnSemi [1]. This is a new custom bayer format with
> interleaved ir pixels. For more information see the documentation
> commit.
> 
> [1] https://www.onsemi.com/products/sensors/image-sensors-processors/image-sensors/ar0237sr

Sorry, I forget to say that I know that checkpatch.pl complains but I
kept my changes to be more readable.

Regards,
  Marco


From maz at kernel.org  Tue Apr 27 13:17:45 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 27 Apr 2021 13:17:45 +0100
Subject: [PATCH 1/3] irqchip: xilinx: Avoid __init macro usage for
 xilinx_intc_of_init
In-Reply-To: <20210427113136.12469-2-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
 <20210427113136.12469-2-anirudha.sarangi@xilinx.com>
Message-ID: <87mttjor9y.wl-maz@kernel.org>

On Tue, 27 Apr 2021 12:31:34 +0100,
Anirudha Sarangi <anirudha.sarangi at xilinx.com> wrote:
> 
> This patch ensures that xilinx_intc_of_init API is not allocated into
> the .init.text section. Since this API calls the API set_handle_irq
> which uses __init macro to be put into .init.text section, this patch
> makes changes to ensure that set_handle_irq also does not stay in
> .init.text section.
> This patch is in preparation for the patch through which the xilinx
> intc driver will be loaded and unloaded as a module.
> 
> Signed-off-by: Anirudha Sarangi <anirudha.sarangi at xilinx.com>
> ---
>  drivers/irqchip/irq-xilinx-intc.c | 4 ++--
>  include/linux/irq.h               | 2 +-
>  kernel/irq/handle.c               | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-xilinx-intc.c b/drivers/irqchip/irq-xilinx-intc.c
> index 1d3d273309bd..642733a6cbdf 100644
> --- a/drivers/irqchip/irq-xilinx-intc.c
> +++ b/drivers/irqchip/irq-xilinx-intc.c
> @@ -177,8 +177,8 @@ static void xil_intc_irq_handler(struct irq_desc *desc)
>  	chained_irq_exit(chip, desc);
>  }
>  
> -static int __init xilinx_intc_of_init(struct device_node *intc,
> -					     struct device_node *parent)
> +static int xilinx_intc_of_init(struct device_node *intc,
> +			       struct device_node *parent)
>  {
>  	struct xintc_irq_chip *irqc;
>  	int ret, irq;
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 2efde6a79b7e..252fab8074de 100644
> --- a/include/linux/irq.h
> +++ b/include/linux/irq.h
> @@ -1250,7 +1250,7 @@ int ipi_send_mask(unsigned int virq, const struct cpumask *dest);
>   * Returns 0 on success, or -EBUSY if an IRQ handler has already been
>   * registered.
>   */
> -int __init set_handle_irq(void (*handle_irq)(struct pt_regs *));
> +int set_handle_irq(void (*handle_irq)(struct pt_regs *));
>  
>  /*
>   * Allows interrupt handlers to find the irqchip that's been registered as the
> diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
> index 762a928e18f9..a0b18e8f5af0 100644
> --- a/kernel/irq/handle.c
> +++ b/kernel/irq/handle.c
> @@ -218,7 +218,7 @@ irqreturn_t handle_irq_event(struct irq_desc *desc)
>  }
>  
>  #ifdef CONFIG_GENERIC_IRQ_MULTI_HANDLER
> -int __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
> +int set_handle_irq(void (*handle_irq)(struct pt_regs *))
>  {
>  	if (handle_arch_irq)
>  		return -EBUSY;

No, never.

This function is for a root interrupt controller. You will never be
able to use this from a module. If you are calling this from something
that isn't marked __init, this is a terrible bug.

	M.

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


From maz at kernel.org  Tue Apr 27 13:35:10 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 27 Apr 2021 13:35:10 +0100
Subject: [PATCH 2/3] irqchip: Add support to remove irqchip driver modules.
In-Reply-To: <20210427113136.12469-3-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-1-anirudha.sarangi@xilinx.com>
 <20210427113136.12469-3-anirudha.sarangi@xilinx.com>
Message-ID: <87lf93oqgx.wl-maz@kernel.org>

On Tue, 27 Apr 2021 12:31:35 +0100,
Anirudha Sarangi <anirudha.sarangi at xilinx.com> wrote:
> 
> The existing irqchip implementation does not fully support use cases
> where an irqchip driver has to be used as a module. In particular there
> is no support to remove an irqchip driver module.
> The use cases where an irqchip driver has to be loaded and then removed
> as a module are really relevant in fpga world. A user can decide to
> have a irqchip as part of a removable partial fpga region. In such cases
> not only the corresponding irqchip driver has to be loaded as a module,
> but must also be removed when the removable partial region is removed.
> 
> The existing implementation updates the existing framework to achieve
> the above said goal.
> 
> Signed-off-by: Anirudha Sarangi <anirudha.sarangi at xilinx.com>

There is absolutely no way we can entertain the removal of an
interrupt controller based on *this*.

What happen to the irqdesc structures? What happen when a client
driver decides to do a disable_irq(), or any other interaction with
the interrupt controller that now has dangling pointers everywhere (if
your third patch is supposed to be an example of how to use this
functionality)?

So no, you can't do that until you figure out all the dependencies
that need to be accounted for to safely remove an interrupt
controller.

	M.

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


From andrzejtp2010 at gmail.com  Tue Apr 27 13:36:01 2021
From: andrzejtp2010 at gmail.com (Andrzej Pietrasiewicz)
Date: Tue, 27 Apr 2021 14:36:01 +0200
Subject: [PATCH v3 17/79] media: s5p-jpeg: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <7ef9d9ec7810a6d2ff53ba8685fcc91a952bbbb5.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
 <7ef9d9ec7810a6d2ff53ba8685fcc91a952bbbb5.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <2aac6758-8f57-f27f-2d43-61a2b925b2f8@gmail.com>

Hi Mauro,

Thanks for the patch.

W dniu 27.04.2021 o?12:26, Mauro Carvalho Chehab pisze:
> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> Replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
> 
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Acked-by: Andrzej Pietrasiewicz <andrzejtp2010 at gmail.com>

> ---
>   drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 026111505f5a..c4f19418a460 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -2568,7 +2568,7 @@ static int s5p_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
>   	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(q);
>   	int ret;
>   
> -	ret = pm_runtime_get_sync(ctx->jpeg->dev);
> +	ret = pm_runtime_resume_and_get(ctx->jpeg->dev);
>   
>   	return ret > 0 ? 0 : ret;
>   }
> 


From maz at kernel.org  Tue Apr 27 13:36:40 2021
From: maz at kernel.org (Marc Zyngier)
Date: Tue, 27 Apr 2021 13:36:40 +0100
Subject: [PATCH] irqchip: APPLE_AIC should depend on ARCH_APPLE
In-Reply-To: <26a1ca39-5c60-b54c-d3fc-df1a7cc38818@marcan.st>
References: <f37e8daea37d50651d2164b0b3dad90780188548.1618316398.git.geert+renesas@glider.be>
 <26a1ca39-5c60-b54c-d3fc-df1a7cc38818@marcan.st>
Message-ID: <b40459d5e88f9735b3370184106f3cc0@kernel.org>

On 2021-04-27 12:07, Hector Martin wrote:
> On 13/04/2021 21.21, Geert Uytterhoeven wrote:
>> The Apple Interrupt Controller is only present on Apple Silicon SoCs.
>> Hence add a dependency on ARCH_APPLE, to prevent asking the user about
>> this driver when configuring a kernel without Apple Silicon SoC 
>> support.
>> 
>> Drop the default, as ARCH_APPLE already selects APPLE_AIC.
>> 
>> Fixes: 76cde26394114f6a ("irqchip/apple-aic: Add support for the Apple 
>> Interrupt Controller")
>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>> ---
>>   drivers/irqchip/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
> 
> Makes sense. Thanks!
> 
> Acked-by: Hector Martin <marcan at marcan.st>

I'll pick this up post -rc1.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...


From linux at roeck-us.net  Tue Apr 27 13:56:21 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 27 Apr 2021 05:56:21 -0700
Subject: [PATCH 2/9] ARM: PXA: Kill use of irq_create_strict_mappings()
In-Reply-To: <87o8e0nn8u.wl-maz@kernel.org>
References: <20210406093557.1073423-1-maz@kernel.org>
 <20210406093557.1073423-3-maz@kernel.org>
 <20210426223942.GA213931@roeck-us.net> <87o8e0nn8u.wl-maz@kernel.org>
Message-ID: <4dfcc837-8474-0173-2de8-146e5cf1d142@roeck-us.net>

On 4/27/21 1:30 AM, Marc Zyngier wrote:
> Hi Guenter,
> 
> Thanks for the heads up.
> 
> On Mon, 26 Apr 2021 23:39:42 +0100,
> Guenter Roeck <linux at roeck-us.net> wrote:
>>
>> On Tue, Apr 06, 2021 at 10:35:50AM +0100, Marc Zyngier wrote:
>>> irq_create_strict_mappings() is a poor way to allow the use of
>>> a linear IRQ domain as a legacy one. Let's be upfront about
>>> it and use a legacy domain when appropriate.
>>>
>>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>>> ---
>>
>> When running the "mainstone" qemu emulation, this patch results
>> in many (32, actually) runtime warnings such as the following.
>>
>> [    0.528272] ------------[ cut here ]------------
>> [    0.528285] WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:550 irq_domain_associate+0x194/0x1f0
>> [    0.528315] error: virq335 is not allocated
> 
> [...]
> 
> This looks like a case of CONFIG_SPARSE_IRQ, combined with a lack of
> brain engagement. I've come up with the following patch, which lets
> the kernel boot in QEMU without screaming (other than the lack of a
> rootfs...).
> 
> Please let me know if this helps.
> 

It does.

Tested-by: Guenter Roeck <linux at roeck-us.net>

Thanks,
Guenter

> Thanks,
> 
> 	M.
> 
> From 4d7f6ddbbfdff1c9f029bafca79020d3294dc32c Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <maz at kernel.org>
> Date: Tue, 27 Apr 2021 09:00:28 +0100
> Subject: [PATCH] ARM: PXA: Fix cplds irqdesc allocation when using legacy mode
> 
> The Mainstone PXA platform uses CONFIG_SPARSE_IRQ, and thus we
> cannot rely on the irq descriptors to be readilly allocated
> before creating the irqdomain in legacy mode. The kernel then
> complains loudly about not being able to associate the interrupt
> in the domain -- can't blame it.
> 
> Fix it by allocating the irqdescs upfront in the legacy case.
> 
> Fixes: b68761da0111 ("ARM: PXA: Kill use of irq_create_strict_mappings()")
> Reported-by: Guenter Roeck <linux at roeck-us.net>
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> ---
>  arch/arm/mach-pxa/pxa_cplds_irqs.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-pxa/pxa_cplds_irqs.c b/arch/arm/mach-pxa/pxa_cplds_irqs.c
> index ec0d9b094744..bddfc7cd5d40 100644
> --- a/arch/arm/mach-pxa/pxa_cplds_irqs.c
> +++ b/arch/arm/mach-pxa/pxa_cplds_irqs.c
> @@ -121,8 +121,13 @@ static int cplds_probe(struct platform_device *pdev)
>  		return fpga->irq;
>  
>  	base_irq = platform_get_irq(pdev, 1);
> -	if (base_irq < 0)
> +	if (base_irq < 0) {
>  		base_irq = 0;
> +	} else {
> +		ret = devm_irq_alloc_descs(&pdev->dev, base_irq, base_irq, CPLDS_NB_IRQ, 0);
> +		if (ret < 0)
> +			return ret;
> +	}
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	fpga->base = devm_ioremap_resource(&pdev->dev, res);
> 



From lyl2019 at mail.ustc.edu.cn  Tue Apr 27 14:27:34 2021
From: lyl2019 at mail.ustc.edu.cn (Lv Yunlong)
Date: Tue, 27 Apr 2021 06:27:34 -0700
Subject: [PATCH v3] media:exynos4-is: Fix a use after free in isp_video_release
Message-ID: <20210427132734.5212-1-lyl2019@mail.ustc.edu.cn>

In isp_video_release, file->private_data is freed via
_vb2_fop_release()->v4l2_fh_release(). But the freed
file->private_data is still used in v4l2_fh_is_singular_file()
->v4l2_fh_is_singular(file->private_data), which is a use
after free bug.

My patch sets file->private_data to NULL after _vb2_fop_release()
to avoid the use after free, and uses a variable 'is_singular_file'
to keep the original function unchanged.

Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>
---
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..c07dcb0bccc2 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -306,17 +306,21 @@ static int isp_video_release(struct file *file)
 	struct fimc_is_video *ivc = &isp->video_capture;
 	struct media_entity *entity = &ivc->ve.vdev.entity;
 	struct media_device *mdev = entity->graph_obj.mdev;
+	bool is_singular_file;
 
 	mutex_lock(&isp->video_lock);
 
-	if (v4l2_fh_is_singular_file(file) && ivc->streaming) {
+	is_singular_file = v4l2_fh_is_singular_file(file);
+
+	if (is_singular_file && ivc->streaming) {
 		media_pipeline_stop(entity);
 		ivc->streaming = 0;
 	}
 
 	_vb2_fop_release(file, NULL);
+	file->private_data = NULL;
 
-	if (v4l2_fh_is_singular_file(file)) {
+	if (is_singular_file) {
 		fimc_pipeline_call(&ivc->ve, close);
 
 		mutex_lock(&mdev->graph_mutex);
-- 
2.25.1




From lyl2019 at mail.ustc.edu.cn  Tue Apr 27 14:29:57 2021
From: lyl2019 at mail.ustc.edu.cn (lyl2019 at mail.ustc.edu.cn)
Date: Tue, 27 Apr 2021 21:29:57 +0800 (GMT+08:00)
Subject: [PATCH v2] media:exynos4-is: Fix a use after free in
 isp_video_release
In-Reply-To: <a56d14d8-5be6-24ff-24f1-80274320dfe5@kernel.org>
References: <20210427060255.3318-1-lyl2019@mail.ustc.edu.cn>
 <a56d14d8-5be6-24ff-24f1-80274320dfe5@kernel.org>
Message-ID: <5233bec4.64281.1791385ab97.Coremail.lyl2019@mail.ustc.edu.cn>




> -----????-----
> ???: "Sylwester Nawrocki" <snawrocki at kernel.org>
> ????: 2021-04-27 18:36:48 (???)
> ???: "Lv Yunlong" <lyl2019 at mail.ustc.edu.cn>
> ??: linux-media at vger.kernel.org, linux-arm-kernel at lists.infradead.org, linux-samsung-soc at vger.kernel.org, linux-kernel at vger.kernel.org, s.nawrocki at samsung.com, mchehab at kernel.org, krzk at kernel.org
> ??: Re: [PATCH v2] media:exynos4-is: Fix a use after free in isp_video_release
> 
> On 27.04.2021 08:02, Lv Yunlong wrote:
> > In isp_video_release, file->private_data is freed via
> > _vb2_fop_release()->v4l2_fh_release(). But the freed
> > file->private_data is still used in v4l2_fh_is_singular_file()
> > ->v4l2_fh_is_singular(file->private_data), which is a use
> > after free bug.
> > 
> > My patch set file->private_data to NULL after _vb2_fop_release()
> > to avoid the use after free.
> > 
> > Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
> > Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>
> > ---
> >   drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > index 612b9872afc8..2e04589068b4 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> > @@ -315,7 +315,8 @@ static int isp_video_release(struct file *file)
> >   	}
> >   
> >   	_vb2_fop_release(file, NULL);
> > -
> > +	file->private_data = NULL;
> 
> >   	if (v4l2_fh_is_singular_file(file)) {
> >   		fimc_pipeline_call(&ivc->ve, close);
> >   
> 
> Thank you for the patch. To ensure the pipeline stop call is done
> only when the last file handle is released we would need something
> as below.
> 
> --------8<---------
> diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c 
> b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> index 612b9872afc8..3335fec509cb 100644
> --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> @@ -306,17 +306,20 @@ static int isp_video_release(struct file *file)
>          struct fimc_is_video *ivc = &isp->video_capture;
>          struct media_entity *entity = &ivc->ve.vdev.entity;
>          struct media_device *mdev = entity->graph_obj.mdev;
> +       bool is_singular_file;
> 
>          mutex_lock(&isp->video_lock);
> 
> -       if (v4l2_fh_is_singular_file(file) && ivc->streaming) {
> +       is_singular_file = v4l2_fh_is_singular_file(file);
> +
> +       if (is_singular_file && ivc->streaming) {
>                  media_pipeline_stop(entity);
>                  ivc->streaming = 0;
>          }
> 
>          _vb2_fop_release(file, NULL);
> 
> -       if (v4l2_fh_is_singular_file(file)) {
> +       if (is_singular_file) {
>                  fimc_pipeline_call(&ivc->ve, close);
> 
>                  mutex_lock(&mdev->graph_mutex);
> --------8<---------
> 
> Regards,
> Sylwester

Ok, thanks for your review and help.
I have corrected my patch and sent the PATCH v3 for you review again.

Thanks.

From s.nawrocki at samsung.com  Tue Apr 27 14:48:15 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 27 Apr 2021 15:48:15 +0200
Subject: [PATCH v3] media:exynos4-is: Fix a use after free in
 isp_video_release
In-Reply-To: <20210427132734.5212-1-lyl2019@mail.ustc.edu.cn>
References: <CGME20210427132754eucas1p21042e4e176135e7b3f7b540dc9aadfbb@eucas1p2.samsung.com>
 <20210427132734.5212-1-lyl2019@mail.ustc.edu.cn>
Message-ID: <ed80a3f0-048a-17df-4dff-e9d52b777699@samsung.com>

On 27.04.2021 15:27, Lv Yunlong wrote:
> In isp_video_release, file->private_data is freed via
> _vb2_fop_release()->v4l2_fh_release(). But the freed
> file->private_data is still used in v4l2_fh_is_singular_file()
> ->v4l2_fh_is_singular(file->private_data), which is a use
> after free bug.
> 
> My patch sets file->private_data to NULL after _vb2_fop_release()
> to avoid the use after free, and uses a variable 'is_singular_file'
> to keep the original function unchanged.
> 
> Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
> Signed-off-by: Lv Yunlong <lyl2019 at mail.ustc.edu.cn>

Thanks,

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>


From robh at kernel.org  Tue Apr 27 14:48:52 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 27 Apr 2021 08:48:52 -0500
Subject: [PATCH] arm64: perf: Ensure EL0 access is disabled at reset
Message-ID: <20210427134852.1411642-1-robh@kernel.org>

The ER, SW, and EN bits in the PMUSERENR_EL0 register are UNKNOWN at
reset and the register is never initialized, so EL0 access could be
enabled by default on some implementations. Let's initialize
PMUSERENR_EL0 to a known state with EL0 access disabled.

Signed-off-by: Rob Herring <robh at kernel.org>
---
 arch/arm64/kernel/perf_event.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4658fcf88c2b..c32778ae5117 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -450,6 +450,11 @@ static inline void armv8pmu_pmcr_write(u32 val)
 	write_sysreg(val, pmcr_el0);
 }
 
+static void armv8pmu_clear_pmuserenr(void)
+{
+	write_sysreg(0, pmuserenr_el0);
+}
+
 static inline int armv8pmu_has_overflowed(u32 pmovsr)
 {
 	return pmovsr & ARMV8_PMU_OVERFLOWED_MASK;
@@ -933,6 +938,9 @@ static void armv8pmu_reset(void *info)
 	armv8pmu_disable_counter(U32_MAX);
 	armv8pmu_disable_intens(U32_MAX);
 
+	/* User access is unknown at reset. */
+	armv8pmu_clear_pmuserenr();
+
 	/* Clear the counters we flip at guest entry/exit */
 	kvm_clr_pmu_events(U32_MAX);
 
-- 
2.27.0



From mark.rutland at arm.com  Tue Apr 27 14:55:06 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 27 Apr 2021 14:55:06 +0100
Subject: [PATCH] arm64: perf: Ensure EL0 access is disabled at reset
In-Reply-To: <20210427134852.1411642-1-robh@kernel.org>
References: <20210427134852.1411642-1-robh@kernel.org>
Message-ID: <20210427135506.GC37475@C02TD0UTHF1T.local>

On Tue, Apr 27, 2021 at 08:48:52AM -0500, Rob Herring wrote:
> The ER, SW, and EN bits in the PMUSERENR_EL0 register are UNKNOWN at
> reset and the register is never initialized, so EL0 access could be
> enabled by default on some implementations. Let's initialize
> PMUSERENR_EL0 to a known state with EL0 access disabled.

We reset PMUSERENR_EL0 via the reset_pmuserenr_el0 macro, called from
__cpu_setup when a CPU is onlined and from cpu_do_resume() when a CPU
returns from a context-destructive idle state. We do it there so that
it's handled even if a kernel isn't built with perf support.

AFAICT, that *should* do the right thing -- are you seeing UNKNOWN
values, or was this found by inspection?

Thanks,
Mark.

> 
> Signed-off-by: Rob Herring <robh at kernel.org>
> ---
>  arch/arm64/kernel/perf_event.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 4658fcf88c2b..c32778ae5117 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -450,6 +450,11 @@ static inline void armv8pmu_pmcr_write(u32 val)
>  	write_sysreg(val, pmcr_el0);
>  }
>  
> +static void armv8pmu_clear_pmuserenr(void)
> +{
> +	write_sysreg(0, pmuserenr_el0);
> +}
> +
>  static inline int armv8pmu_has_overflowed(u32 pmovsr)
>  {
>  	return pmovsr & ARMV8_PMU_OVERFLOWED_MASK;
> @@ -933,6 +938,9 @@ static void armv8pmu_reset(void *info)
>  	armv8pmu_disable_counter(U32_MAX);
>  	armv8pmu_disable_intens(U32_MAX);
>  
> +	/* User access is unknown at reset. */
> +	armv8pmu_clear_pmuserenr();
> +
>  	/* Clear the counters we flip at guest entry/exit */
>  	kvm_clr_pmu_events(U32_MAX);
>  
> -- 
> 2.27.0
> 


From andy.shevchenko at gmail.com  Tue Apr 27 15:04:13 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 27 Apr 2021 17:04:13 +0300
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <67cef577-0965-2fad-7d61-17181d692003@xilinx.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
 <d1220d39-4be4-a375-042f-e7bb0264ed35@xilinx.com>
 <CAHp75Vejqe3r6s5eoOfza0DjXEwN-hK73FWkxx6VNpx0y1ms2w@mail.gmail.com>
 <180ca47b-d627-2d7b-1d18-5557bfcf5875@xilinx.com>
 <CAHp75Ve1MY6wms7d1e2cByzV0Zy-rRs-qNMk=6X_fw=zu4rbgw@mail.gmail.com>
 <67cef577-0965-2fad-7d61-17181d692003@xilinx.com>
Message-ID: <CAHp75VcqNC=MUJJJdou_2rJub2yeD50MQk03J2DfmHF4N0-htA@mail.gmail.com>

On Tue, Apr 27, 2021 at 12:59 PM Michal Simek <michal.simek at xilinx.com> wrote:
> On 4/27/21 10:39 AM, Andy Shevchenko wrote:
> > On Tue, Apr 27, 2021 at 10:38 AM Michal Simek <michal.simek at xilinx.com> wrote:
> >> On 4/27/21 9:31 AM, Andy Shevchenko wrote:
> >>> On Tue, Apr 27, 2021 at 10:23 AM Michal Simek <michal.simek at xilinx.com> wrote:
> >>>> On 4/26/21 4:04 PM, Andy Shevchenko wrote:
> >>>>> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> >>>>> <lakshmis at xilinx.com> wrote:
> >>>>>>> From: Andy Shevchenko <andy.shevchenko at gmail.com>
> >>>>>>> Sent: Friday, April 23, 2021 9:24 PM
> >>>>>>> On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> >>>>>>> <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> >
> > ...
> >
> >>>>>>>> +       help
> >>>>>>>> +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> >>>>>>>> +         This driver will query the pin information from the firmware
> >>>>>>>> +         and allow configuring the pins.
> >>>>>>>> +         Configuration can include the mux function to select on those
> >>>>>>>> +         pin(s)/group(s), and various pin configuration parameters
> >>>>>>>> +         such as pull-up, slew rate, etc.
> >>>>>>>
> >>>>>>> Missed module name.
> >>>>>> Is this (module name) a configuration option in Kconfig?
> >>>>>
> >>>>> It's a text in a free form that sheds light on how the module will be
> >>>>> named in case the user will choose "m".
> >>>>
> >>>> Is this described somewhere in documentation that module name should be
> >>>> the part of symbol description? I was looking at pinctrl Kconfig and I
> >>>> can't see any description like this there that's why I want to double
> >>>> check.
> >>>
> >>> I dunno if it is described, the group of maintainers require that for some time.
> >>> I personally found this as a good practice.
> >>
> >> I don't think it is a big deal to add it but it is a question if this
> >> information is useful because module names should correspond target in
> >> Makefile which can be considered as additional information.
> >
> > For you as a *developer* ? yes, for me as a *user* ? no. You are
> > telling me something like "hey, if you want to know more you must dig
> > into kernel sources". No, this is not how we should treat users,
> > should we?
>
> As I said it is not big deal but we should care about consistency on
> this. Adding Joe here if we can extend checkpatch to report a warning
> about it. Then it will be visible and can be checked.

> >>>> Also if this is a rule checkpatch should be extended to checking this.
> >>>
> >>> There was a discussion at some point to add a check that help
> >>> description shouldn't be less than 3 lines. Not sure what the outcome
> >>> of it.
> >>
> >> This check is likely there because I have definitely seen these messages
> >> coming but never seen any name checking.
> >
> > Yeah, it was about insisting developers to be more verbose in the help
> > descriptions, but the name is, as I said, an activity "de facto"
> > rather than "de jure". Just look around for the latest new driver
> > contributions (I follow IIO, I2C, SPI, GPIO, pin control) for how they
> > provide their help descriptions (I admit that not everybody follows
> > that practice).
>
> I have seen some on linux-next but really when any rule/recommendation
> like this is introduced it should be more visible and checked by
> standard tools (checkpatch or by bots) then people will start to do it.

I agree on this.


-- 
With Best Regards,
Andy Shevchenko


From robh at kernel.org  Tue Apr 27 15:05:37 2021
From: robh at kernel.org (Rob Herring)
Date: Tue, 27 Apr 2021 09:05:37 -0500
Subject: [PATCH] arm64: perf: Ensure EL0 access is disabled at reset
In-Reply-To: <20210427135506.GC37475@C02TD0UTHF1T.local>
References: <20210427134852.1411642-1-robh@kernel.org>
 <20210427135506.GC37475@C02TD0UTHF1T.local>
Message-ID: <CAL_Jsq+s+9TVBaeGjRxKa+-DKJqO_ZUUJGgYsJOv5xauMDUgpA@mail.gmail.com>

On Tue, Apr 27, 2021 at 8:55 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Tue, Apr 27, 2021 at 08:48:52AM -0500, Rob Herring wrote:
> > The ER, SW, and EN bits in the PMUSERENR_EL0 register are UNKNOWN at
> > reset and the register is never initialized, so EL0 access could be
> > enabled by default on some implementations. Let's initialize
> > PMUSERENR_EL0 to a known state with EL0 access disabled.
>
> We reset PMUSERENR_EL0 via the reset_pmuserenr_el0 macro, called from
> __cpu_setup when a CPU is onlined and from cpu_do_resume() when a CPU
> returns from a context-destructive idle state. We do it there so that
> it's handled even if a kernel isn't built with perf support.

Indeed.

> AFAICT, that *should* do the right thing -- are you seeing UNKNOWN
> values, or was this found by inspection?

Inspection. Sorry for the noise.

Rob


From michal.simek at xilinx.com  Tue Apr 27 15:19:20 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 27 Apr 2021 16:19:20 +0200
Subject: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to
 get_cycles() not supported
In-Reply-To: <20210406130045.15491-1-andrea.merello@gmail.com>
References: <20210406130045.15491-1-andrea.merello@gmail.com>
Message-ID: <f20bbd62-db3d-d0e0-aa28-888bdbbd4f9a@xilinx.com>

Hi,

On 4/6/21 3:00 PM, Andrea Merello wrote:
> Changes wrt v1:
>  - rebased on latest kernel tree
>  - fix cover letter: does -> doesn't
> 
> A real-world problem has been seen with a Zynq-based board running
> Debian 10, where ssh daemon takes a really long time to come up at boot.
> This is due to lack of random numbers.
> 
> Since commit 50ee7529ec450 ("random: try to actively add entropy rather
> than passively wait for it") we try to generate entropy whenever we are
> in short of random numbers and someone needs them.
> 
> This trick works only when CPU cycle counter is available. On ARM this
> means that get_cycles() works and in turn read_current_timer() works.
> 
> Zynq HW includes two "cadence TTC" timers and the "ARM global timer".
> All these pieces of HW are fed by the CPU clock, which dynamically
> changes whenever CPU frequency scaling is enabled.
> 
> In timer-cadence-ttc driver this scenario is handled by looking at parent
> clock changes and adjusting things when required. This is the only usable
> clocksource when CPU frequency scaling is in use. arm_global_timer driver
> is disabled in Kconfig when CPU_FREQ is enabled for Zynq arch.
> 
> Unfortunately timer-cadence-ttc driver doesn't register itself via
> register_current_timer_delay() and that ultimately ends up in get_cycles()
> to always return zero, causing the aforementioned lack of entropy problem.
> I believe that the reason for this is because Cadence TTC counter on Zynq
> silicon is only 16-bit wide.
> 
> This patchset works around this by implementing in ARM global timer driver
> a mechanism to compensate for parent clock variations, similarly to what
> it's done in Cadence TTC timer driver, so that it can be used together
> with CPU frequency scaling on Zynq arch.
> 
> This proved to finally fix the problem on my Zynq-based Z-turn board.
> 
> Signed-off-by: Andrea Merello <andrea.merello at gmail.com>
> Cc: Patrice Chotard <patrice.chotard at st.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
> 
> Andrea Merello (2):
>   clocksource: arm_global_timer: implement rate compensation whenever
>     source clock changes
>   arm: zynq: don't disable CONFIG_ARM_GLOBAL_TIMER due to
>     CONFIG_CPU_FREQ anymore
> 
>  arch/arm/mach-zynq/Kconfig             |   2 +-
>  drivers/clocksource/Kconfig            |  14 +++
>  drivers/clocksource/arm_global_timer.c | 122 +++++++++++++++++++++++--
>  3 files changed, 127 insertions(+), 11 deletions(-)
> 
> --
> 2.17.1
> 

I have no problem with these patches. I have tested it on zc706 board
and I see performance improvement when I generate random numbers.

Only question what I have is if ARM_GT_INITIAL_PRESCALER_VAL=2 make
sense also for others SoC with multi_v7_defconfig.

Other than this feel free to add my
Acked-by: Michal Simek <michal.simek at xilinx.com>
Tested-by: Michal Simek <michal.simek at xilinx.com> (on Zynq)

Daniel: Can you please take a look at this series?

Thanks,
Michal



From broonie at kernel.org  Tue Apr 27 15:34:57 2021
From: broonie at kernel.org (Mark Brown)
Date: Tue, 27 Apr 2021 15:34:57 +0100
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
 <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
Message-ID: <20210427143457.GI4605@sirena.org.uk>

On Tue, Apr 27, 2021 at 02:46:02PM +0300, Andy Shevchenko wrote:

> Mark, are you accepting patches for v5.14 now, or should I resend
> after v5.13-rc1 is out?

> (I have few more in my queue :-)

Send them now if you like.
-------------- 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/20210427/e6c82ba3/attachment-0001.sig>

From mike.leach at linaro.org  Tue Apr 27 15:41:01 2021
From: mike.leach at linaro.org (Mike Leach)
Date: Tue, 27 Apr 2021 15:41:01 +0100
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210426175425.GA1391779@xps15>
 <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>
Message-ID: <CAJ9a7Vi6yEvKBxCAvvq2X_0WNs570-W+=nQ17AJNJOi+_a+Rzg@mail.gmail.com>

Hi Mathieu,

I thought I'd add a little backgound to what has been said so far...

On Tue, 27 Apr 2021 at 11:43, Al Grant <Al.Grant at arm.com> wrote:
>
> > Hi Daniel,
> >
> > On Wed, Apr 21, 2021 at 02:04:09PM +0200, Daniel Kiss wrote:
> > > This series adds a feature to ETR-PERF that sync the ETR buffer to
> > > perf periodically. This is really handy when the system wide trace is
> > > used because in this case the perf won't sync during the trace. In a
> > > per-thread setup the traced program might not go to the kernel
> > > frequvently enought to collect trace. Polling helps in both usecases. Can be
> > used with strobing.
> > > Tuning polling period is challanging, I'm working on an additional
> > > patch that adds some metrics to help tune the polling period.
> > >
> >
> > Suzuki and Leo have already commented on a number of problems with this set
> > and as such I will concentrate on the general idea.
> >
> > Over the years we have thought long and hard about fixing the overflow issues
> > created by the lack of interrupt when a sink gets full, installing a timer to empty
> > the sink buffer at regular intervals is one of them.  Ultimately we haven't moved
> > forward with the idea because it requires to stop the sink when an event is
> > active, something that introduces more trace data loss.
> >
> > To me this kind of interval snapshot should be achieved using Mike's new
> > strobing feature that came bundled with the complex configuration framework,
> > available on next-ETE-TRBE[1].  I will rebase that branch to 5.13-rc1 when it is
> > released in a couple of weeks from now.
>
> It's important to understand what strobing is. It acts internally to the ETM
> and switches the ETM on for a time and then off for a time. It is as the
> name suggests, like a stroboscope (or a lighthouse).
>
> There is no synchronization between the on-periods of different ETMs.
> When you have multiple ETMs funnelling into a common ETR, strobing
> does not guarantee you a window where you can safely harvest the buffer.
> It achieves a reduction in the overall bandwidth of trace being dumped
> into the buffer, and there may be times when no trace is being written
> at all because all the ETMs are in their off-period.
>
> At worst, it may create a false sense of security - tests that consistently
> fail without strobing, may pass often enough with strobing to create the
> impression that strobing has solved the problem. But these tests are also
> likely to fail eventually with strobing. To fix this problem without
> disabling either ETR or ETMs you would have to guarantee that you can
> harvest the ETR buffer in less time than it takes to fill it. That would need
> very careful quntitative arguments to be made about:
>
>  - the rate of trace generation by each ETM (as modified by strobing)
>
>  - the number of ETMs writing into the buffer
>
>  - the time available to the kernel to harvest the buffer
>
> So if there are 10 ETMs generating trace at average 1Gb/s into a 1Mb
> buffer, the buffer will fill in 100us, and that gives the kernel 100us to
> harvest the buffer before its read pointer is caught up by the ETR's
> advancing write pointer. If strobing is used to reduce average ETM rate
> to 100Mb/s the kernel has 1ms to read the buffer, and so on. In short
> the kernel must *guarantee* a minimum readout rate equal to the
> maximum aggregate write rate of the ETMs. But can the kernel
> guarantee any minimum readout rate at all?
>
> The alternative would be double-buffering the ETR, which we've
> also discussed - so while the kernel is harvesting the contents of one
> buffer, the ETR is writing (and possibly wrapping) the other.
> Some trace will still be lost but it does mean the kernel will be
> harvesting monotonically increasing sequences of trace, and won't be
> seeing artefacts from its reads colliding with the ETR's writes.
>
> Al
>

As Al mentions, ETR polling is designed to solve a different issue
than ETM strobing.  These two techniques can be used together or
separately.

It was noticed by users that the amount of trace captured during a
given trace run would vary greatly even when tracing the same
application for the same length of time.
This was also found to be sensitive to process scheduling - frequent
re-scheds did seem to result in more frequent ETR updates and more
trace data collected. If perf does not wake up during a trace run then
the ETR may wrap mulitple times and all the data  will be a single
buffer biased towards the end of the trace session.

ETR polling is designed to ensure that more trace data is collected
consistently across the whole of the trace session. There are issues
of course, with stopping collection without stopping the sources. -
shared to some extent by the ETE / TRBE combination.
This can result in incomplete packets and other trace discontinuities.
For this reason it is necessary to ensure that the decoder is
restarted for each block of trace captured  - which is where the patch
set from James that does this using AUX records in perf to correctly
split the AUXTRACE records into valid blocks is needed.

In summary:-
1) ETM strobing samples trace to allow greater coverage of the program
being traced for a given buffer. This is useful when building
statistical profiles such as for AutoFDO
2) ETR polling ensures that more trace is collected across the entire
trace session - seeking to reduce inconsistent capture volumes.
3) Use AUX records to split the AUXTRACE buffer into valid capture
blocks and reset the decoder at the start of these blocks. This is
essential for ETE+TRBE, the ETR polling, and systems where we are
seeing hardware errata around the flush process causing similar
spurious packets. (an alternative for the ETR polling / flush errata
might be to insert barrier packets to force a decoder reset for every
ETR block copied to the perf buffer - but this does not work for
ETE/TRBE that uses no CoreSight formatted framing).

Regards

Mike


>
> >
> > Thanks,
> > Mathieu
> >
> > PS: Always run your work through checkpatch.pl before sending a patchset for
> > review.
> >
> > [1].
> > https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-
> > ETE-TRBE
> >
> > > Daniel Kiss (4):
> > >   coresight: tmc-etr: Advance buffer pointer in sync buffer.
> > >   coresight: tmc-etr: Track perf handler.
> > >   coresight: etm-perf: Export etm_event_cpu_path.
> > >   coresight: Add ETR-PERF polling.
> > >
> > >  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
> > >  drivers/hwtracing/coresight/Makefile          |   2 +-
> > >  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
> > >  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
> > >  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
> > >  .../coresight/coresight-etr-perf-polling.h    |  42 +++
> > >  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
> > >  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
> > >  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
> > >  9 files changed, 401 insertions(+), 4 deletions(-)  create mode
> > > 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> > >  create mode 100644
> > > drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> > >
> > > --
> > > 2.25.1
> > >
> > _______________________________________________
> > CoreSight mailing list
> > CoreSight at lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/coresight



--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK


From mark.rutland at arm.com  Tue Apr 27 15:43:33 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 27 Apr 2021 15:43:33 +0100
Subject: [PATCHv2 09/11] arm64: entry: fix non-NMI kernel<->kernel
 transitions
In-Reply-To: <d7ee0514-9be0-1c38-c280-045989e5778a@huawei.com>
References: <20201130115950.22492-1-mark.rutland@arm.com>
 <20201130115950.22492-10-mark.rutland@arm.com>
 <f4012761-026f-4e51-3a0c-7524e434e8b3@huawei.com>
 <20210426092139.GA16287@C02TD0UTHF1T.local>
 <0e1143a5-8e1a-c04e-e4fd-5c57f8354f61@huawei.com>
 <d7ee0514-9be0-1c38-c280-045989e5778a@huawei.com>
Message-ID: <20210427144333.GD37475@C02TD0UTHF1T.local>

On Tue, Apr 27, 2021 at 03:15:39PM +0800, Zenghui Yu wrote:
> On 2021/4/26 21:39, Zenghui Yu wrote:
> > Hi Mark,
> > 
> > On 2021/4/26 17:21, Mark Rutland wrote:
> >
> > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > index 6acfc5e6b5e0..7d46c74a8706 100644
> > > --- a/arch/arm64/kernel/entry.S
> > > +++ b/arch/arm64/kernel/entry.S
> > > @@ -292,6 +292,8 @@ alternative_else_nop_endif
> > >  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> > >  	mrs_s	x20, SYS_ICC_PMR_EL1
> > >  	str	x20, [sp, #S_PMR_SAVE]
> > > +	orr	x20, x20, #GIC_PRIO_PSR_I_SET
> > > +	msr_s	SYS_ICC_PMR_EL1, x20
> > >  alternative_else_nop_endif
> > 
> > While this does fix the lockdep part, it breaks something else. The
> > sleep-in-atomic one stands out (which says, I've seen other splats
> > triggered with this diff), where irqs_disabled() in do_mem_abort() now
> > gets confused by the updated PMR (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET).
> 
> Seem that this can be addressed by restoring pt_regs->pmr_save into PMR
> in local_daif_inherit() (before we restore the DAIF bits)?

I think so, yes.

Looking at this some more, I'm not sure whether the entry code should:

* ORR in GIC_PRIO_PSR_I_SET, matching gic_prio_irq_setup

* MOV in (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) matching
  gic_prio_kentry_setup

... as it's not clear to me why the two differ, nor whether we can
follow the same approach in both cases.

I'll dig a bit more through the history and see what I can dredge up,
unless Marc has any ideas.

Thanks,
Mark.


From lkp at intel.com  Tue Apr 27 15:46:06 2021
From: lkp at intel.com (kernel test robot)
Date: Tue, 27 Apr 2021 22:46:06 +0800
Subject: [PATCH 2/3] irqchip: Add support to remove irqchip driver modules.
In-Reply-To: <20210427113136.12469-3-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-3-anirudha.sarangi@xilinx.com>
Message-ID: <202104272228.SJUihvGL-lkp@intel.com>

Hi Anirudha,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/irq/core]
[also build test WARNING on robh/for-next linus/master v5.12 next-20210427]
[cannot apply to xlnx/master]
[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]

url:    https://github.com/0day-ci/linux/commits/Anirudha-Sarangi/Updates-in-irqchip-framework-to-remove-irqchip/20210427-193255
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 765822e1569a37aab5e69736c52d4ad4a289eba6
config: mips-randconfig-r033-20210427 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d7308da4a5aaded897a7e0c06e7e88d81fc64879)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install mips cross compiling tool for clang build
        # apt-get install binutils-mips-linux-gnu
        # https://github.com/0day-ci/linux/commit/70da936a840d5e21d42f09996e9fc8c56e6a44ce
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Anirudha-Sarangi/Updates-in-irqchip-framework-to-remove-irqchip/20210427-193255
        git checkout 70da936a840d5e21d42f09996e9fc8c56e6a44ce
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/irqchip/irqchip.c:78:5: warning: no previous prototype for function 'platform_irqchip_remove' [-Wmissing-prototypes]
   int platform_irqchip_remove(struct platform_device *pdev)
       ^
   drivers/irqchip/irqchip.c:78:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   int platform_irqchip_remove(struct platform_device *pdev)
   ^
   static 
   1 warning generated.


vim +/platform_irqchip_remove +78 drivers/irqchip/irqchip.c

    77	
  > 78	int platform_irqchip_remove(struct platform_device *pdev)

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 19852 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210427/b2c3879c/attachment-0001.gz>

From cniedermaier at dh-electronics.com  Tue Apr 27 15:46:55 2021
From: cniedermaier at dh-electronics.com (Christoph Niedermaier)
Date: Tue, 27 Apr 2021 14:46:55 +0000
Subject: [PATCH V3] ARM: dts: imx6q-dhcom: Add PU, VDD1P1,
 VDD2P5 regulators
In-Reply-To: <20210426102321.5039-1-marex@denx.de>
References: <20210426102321.5039-1-marex@denx.de>
Message-ID: <a5b1890db288453991089c3f3eca9af6@dh-electronics.com>

From: Marek Vasut [mailto:marex at denx.de]
Sent: Monday, April 26, 2021 12:23 PM

> Per schematic, both PU and SOC regulator are supplied from LTC3676 SW1
> via VDDSOC_IN rail, add the PU input. Both VDD1P1, VDD2P5 are supplied
> from LTC3676 SW2 via VDDHIGH_IN rail, add both inputs.
> 
> While no instability or problems are currently observed, the regulators
> should be fully described in DT and that description should fully match
> the hardware, else this might lead to unforseen issues later. Fix this.
> 
> Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM
> and PDK2")
> Reviewed-by: Fabio Estevam <festevam at gmail.com>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Christoph Niedermaier <cniedermaier at dh-electronics.com>
> Cc: Fabio Estevam <festevam at gmail.com>
> Cc: Ludwig Zenz <lzenz at dh-electronics.com>
> Cc: NXP Linux Team <linux-imx at nxp.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: stable at vger.kernel.org
> ---
> V2: Amend commit message
> V3: Reinstate the missing SoB line, add RB
> ---
>  arch/arm/boot/dts/imx6q-dhcom-som.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> index 236fc205c389..d0768ae429fa 100644
> --- a/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> +++ b/arch/arm/boot/dts/imx6q-dhcom-som.dtsi
> @@ -406,6 +406,18 @@ &reg_soc {
>         vin-supply = <&sw1_reg>;
>  };
> 
> +&reg_pu {
> +       vin-supply = <&sw1_reg>;
> +};
> +
> +&reg_vdd1p1 {
> +       vin-supply = <&sw2_reg>;
> +};
> +
> +&reg_vdd2p5 {
> +       vin-supply = <&sw2_reg>;
> +};
> +
>  &uart1 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_uart1>;
> --
> 2.30.2

Reviewed-by: Christoph Niedermaier <cniedermaier at dh-electronics.com>


From alexandru.elisei at arm.com  Tue Apr 27 15:52:46 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Tue, 27 Apr 2021 15:52:46 +0100
Subject: [PATCH] KVM: arm64: Skip CMOs when updating a PTE pointing to
 non-memory
In-Reply-To: <20210426103605.616908-1-maz@kernel.org>
References: <20210426103605.616908-1-maz@kernel.org>
Message-ID: <e6d955f1-f2a4-9505-19ab-5a770f821386@arm.com>

Hi,

I've been trying to reproduce the panic, but I haven't had any success.

With a known working PCI passtrough device, this is how I changed kvmtool:

diff --git a/vfio/core.c b/vfio/core.c
index 3ff2c0b..b4ee7e9 100644
--- a/vfio/core.c
+++ b/vfio/core.c
@@ -261,6 +261,9 @@ int vfio_map_region(struct kvm *kvm, struct vfio_device *vdev,
??????????????? return ret;
??????? }
?
+?????? char c = *(char *)base;
+?????? fprintf(stderr, "c = %c\n", c);
+
??????? return 0;
?}
?
What the change is doing is reading from the BAR region after it's has been
mmap'ed into userspace. I can see that the read hits vfio_pci_mmap_fault(), which
calls io_remap_pfn_range(), but I can't figure out how I can trigger the MMU
notifiers. Any suggestions?

The comment [1] suggested that the panic is triggered during page aging.
vfio_pci_mmap() sets the VM_PFNMAP for the VMA and I see in the Documentation that
pages with VM_PFNMAP are added to the unevictable LRU list, doesn't that mean it's
not subject the page aging? I feel like there's something I'm missing.

[1]
https://lore.kernel.org/kvm/BY5PR12MB37642B9AC7E5D907F5A664F6B3459 at BY5PR12MB3764.namprd12.prod.outlook.com/

Thanks,

Alex

On 4/26/21 11:36 AM, Marc Zyngier wrote:
> Sumit Gupta and Krishna Reddy both reported that for MMIO regions
> mapped into userspace using VFIO, a PTE update can trigger a MMU
> notifier reaching kvm_set_spte_hva().
>
> There is an assumption baked in kvm_set_spte_hva() that it only
> deals with memory pages, and not MMIO. For this purpose, it
> performs a cache cleaning of the potentially newly mapped page.
> However, for a MMIO range, this explodes as there is no linear
> mapping for this range (and doing cache maintenance on it would
> make little sense anyway).
>
> Check for the validity of the page before performing the CMO
> addresses the problem.
>
> Reported-by: Krishna Reddy <vdumpa at nvidia.com>
> Reported-by: Sumit Gupta <sumitg at nvidia.com>,
> Tested-by: Sumit Gupta <sumitg at nvidia.com>,
> Signed-off-by: Marc Zyngier <maz at kernel.org>
> Link: https://lore.kernel.org/r/5a8825bc-286e-b316-515f-3bd3c9c70a80 at nvidia.com
> ---
>  arch/arm64/kvm/mmu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index cd4d51ae3d4a..564a0f7fcd05 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1236,7 +1236,8 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
>  	 * We've moved a page around, probably through CoW, so let's treat it
>  	 * just like a translation fault and clean the cache to the PoC.
>  	 */
> -	clean_dcache_guest_page(pfn, PAGE_SIZE);
> +	if (!kvm_is_device_pfn(pfn))
> +		clean_dcache_guest_page(pfn, PAGE_SIZE);
>  	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
>  	return 0;
>  }


From andy.shevchenko at gmail.com  Tue Apr 27 15:53:14 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 27 Apr 2021 17:53:14 +0300
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <20210427143457.GI4605@sirena.org.uk>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
 <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
 <20210427143457.GI4605@sirena.org.uk>
Message-ID: <YIglWpz8lSidXmDd@smile.fi.intel.com>

On Tue, Apr 27, 2021 at 03:34:57PM +0100, Mark Brown wrote:
> On Tue, Apr 27, 2021 at 02:46:02PM +0300, Andy Shevchenko wrote:
> 
> > Mark, are you accepting patches for v5.14 now, or should I resend
> > after v5.13-rc1 is out?
> 
> > (I have few more in my queue :-)
> 
> Send them now if you like.

Got it!

I think I prefer to produce a less noise in case this series for some reason
needs to be changed / amended. I'll wait till this series lands in your queue.

P.S. basically my question was about this series.


-- 
With Best Regards,
Andy Shevchenko




From smoch at web.de  Tue Apr 27 16:07:04 2021
From: smoch at web.de (Soeren Moch)
Date: Tue, 27 Apr 2021 17:07:04 +0200
Subject: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64
In-Reply-To: <CWXP265MB2680938B222248792AC205F9C4419@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>
References: <CWXP265MB2680938B222248792AC205F9C4419@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <97bcbcde-9ccf-f9cc-ef10-36cbd582825a@web.de>

On 27.04.21 08:20, Christian L?hle wrote:
> The DesignWare Host Controller has full UHS-I support, so use it.
Enabling this UHS support makes 'reboot' hang when booting the RockPro64
from SD card. It would work when booting from eMMC, or with a modified
ATF which does a power cycle on reboot.

But for general use it is not save to enable UHS support, or did I miss
some recent changes?

Regards,
Soeren
>
> Signed-off-by: Christian Loehle <cloehle at hyperstone.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> index 6bff8db7d33e..d22a489ec214 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> @@ -722,6 +722,7 @@ &sdmmc {
>  	max-frequency = <150000000>;
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> +	sd-uhs-sdr104;
>  	vmmc-supply = <&vcc3v0_sd>;
>  	vqmmc-supply = <&vcc_sdio>;
>  	status = "okay";



From jean-philippe at linaro.org  Tue Apr 27 16:23:26 2021
From: jean-philippe at linaro.org (Jean-Philippe Brucker)
Date: Tue, 27 Apr 2021 17:23:26 +0200
Subject: [PATCH] KVM: arm64: Skip CMOs when updating a PTE pointing to
 non-memory
In-Reply-To: <e6d955f1-f2a4-9505-19ab-5a770f821386@arm.com>
References: <20210426103605.616908-1-maz@kernel.org>
 <e6d955f1-f2a4-9505-19ab-5a770f821386@arm.com>
Message-ID: <YIgsbp/hRxM9U+ZN@myrica>

On Tue, Apr 27, 2021 at 03:52:46PM +0100, Alexandru Elisei wrote:
> The comment [1] suggested that the panic is triggered during page aging.

I think only with an out-of-tree patch applied
https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=d32d8baaf293aaefef8a1c9b8a4508ab2ec46c61
which probably is not going upstream.

Thanks,
Jean

> vfio_pci_mmap() sets the VM_PFNMAP for the VMA and I see in the Documentation that
> pages with VM_PFNMAP are added to the unevictable LRU list, doesn't that mean it's
> not subject the page aging? I feel like there's something I'm missing.
> 
> [1]
> https://lore.kernel.org/kvm/BY5PR12MB37642B9AC7E5D907F5A664F6B3459 at BY5PR12MB3764.namprd12.prod.outlook.com/
> 
> Thanks,
> 
> Alex


From chunkuang.hu at kernel.org  Tue Apr 27 16:34:01 2021
From: chunkuang.hu at kernel.org (Chun-Kuang Hu)
Date: Tue, 27 Apr 2021 23:34:01 +0800
Subject: [PATCH v3 2/3] drm/mediatek: init panel orientation property
In-Reply-To: <20210427044948.12596-2-hsinyi@chromium.org>
References: <20210427044948.12596-1-hsinyi@chromium.org>
 <20210427044948.12596-2-hsinyi@chromium.org>
Message-ID: <CAAOTY__6agGjApVEkAyhPdV46qTjWdHODBGD_VQcYf5PRhF-hA@mail.gmail.com>

Hi, Hsin-Yi:

Hsin-Yi Wang <hsinyi at chromium.org> ? 2021?4?27? ?? ??12:49???
>
> Init panel orientation property after connector is initialized. Let the
> panel driver decides the orientation value later.
>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ae403c67cbd9..0bd27872f2a4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -964,6 +964,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>                 ret = PTR_ERR(dsi->connector);
>                 goto err_cleanup_encoder;
>         }
> +       drm_connector_init_panel_orientation_property(dsi->connector);

Process the return value.

Regards,
Chun-Kuang.

>         drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>
>         return 0;
> --
> 2.31.1.498.g6c1eba8ee3d-goog
>


From mathieu.poirier at linaro.org  Tue Apr 27 16:47:46 2021
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 27 Apr 2021 09:47:46 -0600
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <CAJ9a7Vi6yEvKBxCAvvq2X_0WNs570-W+=nQ17AJNJOi+_a+Rzg@mail.gmail.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210426175425.GA1391779@xps15>
 <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>
 <CAJ9a7Vi6yEvKBxCAvvq2X_0WNs570-W+=nQ17AJNJOi+_a+Rzg@mail.gmail.com>
Message-ID: <20210427154746.GA1422814@xps15>

Good day Mike,

On Tue, Apr 27, 2021 at 03:41:01PM +0100, Mike Leach wrote:
> Hi Mathieu,
> 
> I thought I'd add a little backgound to what has been said so far...
> 
> On Tue, 27 Apr 2021 at 11:43, Al Grant <Al.Grant at arm.com> wrote:
> >
> > > Hi Daniel,
> > >
> > > On Wed, Apr 21, 2021 at 02:04:09PM +0200, Daniel Kiss wrote:
> > > > This series adds a feature to ETR-PERF that sync the ETR buffer to
> > > > perf periodically. This is really handy when the system wide trace is
> > > > used because in this case the perf won't sync during the trace. In a
> > > > per-thread setup the traced program might not go to the kernel
> > > > frequvently enought to collect trace. Polling helps in both usecases. Can be
> > > used with strobing.
> > > > Tuning polling period is challanging, I'm working on an additional
> > > > patch that adds some metrics to help tune the polling period.
> > > >
> > >
> > > Suzuki and Leo have already commented on a number of problems with this set
> > > and as such I will concentrate on the general idea.
> > >
> > > Over the years we have thought long and hard about fixing the overflow issues
> > > created by the lack of interrupt when a sink gets full, installing a timer to empty
> > > the sink buffer at regular intervals is one of them.  Ultimately we haven't moved
> > > forward with the idea because it requires to stop the sink when an event is
> > > active, something that introduces more trace data loss.
> > >
> > > To me this kind of interval snapshot should be achieved using Mike's new
> > > strobing feature that came bundled with the complex configuration framework,
> > > available on next-ETE-TRBE[1].  I will rebase that branch to 5.13-rc1 when it is
> > > released in a couple of weeks from now.
> >
> > It's important to understand what strobing is. It acts internally to the ETM
> > and switches the ETM on for a time and then off for a time. It is as the
> > name suggests, like a stroboscope (or a lighthouse).
> >
> > There is no synchronization between the on-periods of different ETMs.
> > When you have multiple ETMs funnelling into a common ETR, strobing
> > does not guarantee you a window where you can safely harvest the buffer.
> > It achieves a reduction in the overall bandwidth of trace being dumped
> > into the buffer, and there may be times when no trace is being written
> > at all because all the ETMs are in their off-period.
> >
> > At worst, it may create a false sense of security - tests that consistently
> > fail without strobing, may pass often enough with strobing to create the
> > impression that strobing has solved the problem. But these tests are also
> > likely to fail eventually with strobing. To fix this problem without
> > disabling either ETR or ETMs you would have to guarantee that you can
> > harvest the ETR buffer in less time than it takes to fill it. That would need
> > very careful quntitative arguments to be made about:
> >
> >  - the rate of trace generation by each ETM (as modified by strobing)
> >
> >  - the number of ETMs writing into the buffer
> >
> >  - the time available to the kernel to harvest the buffer
> >
> > So if there are 10 ETMs generating trace at average 1Gb/s into a 1Mb
> > buffer, the buffer will fill in 100us, and that gives the kernel 100us to
> > harvest the buffer before its read pointer is caught up by the ETR's
> > advancing write pointer. If strobing is used to reduce average ETM rate
> > to 100Mb/s the kernel has 1ms to read the buffer, and so on. In short
> > the kernel must *guarantee* a minimum readout rate equal to the
> > maximum aggregate write rate of the ETMs. But can the kernel
> > guarantee any minimum readout rate at all?
> >
> > The alternative would be double-buffering the ETR, which we've
> > also discussed - so while the kernel is harvesting the contents of one
> > buffer, the ETR is writing (and possibly wrapping) the other.
> > Some trace will still be lost but it does mean the kernel will be
> > harvesting monotonically increasing sequences of trace, and won't be
> > seeing artefacts from its reads colliding with the ETR's writes.
> >
> > Al
> >
> 
> As Al mentions, ETR polling is designed to solve a different issue
> than ETM strobing.  These two techniques can be used together or
> separately.
> 
> It was noticed by users that the amount of trace captured during a
> given trace run would vary greatly even when tracing the same
> application for the same length of time.

Indeed, that problem is well known.

> This was also found to be sensitive to process scheduling - frequent
> re-scheds did seem to result in more frequent ETR updates and more
> trace data collected. If perf does not wake up during a trace run then
> the ETR may wrap mulitple times and all the data  will be a single
> buffer biased towards the end of the trace session.
> 

Right.

> ETR polling is designed to ensure that more trace data is collected
> consistently across the whole of the trace session. There are issues
> of course, with stopping collection without stopping the sources. -
> shared to some extent by the ETE / TRBE combination.
> This can result in incomplete packets and other trace discontinuities.
> For this reason it is necessary to ensure that the decoder is
> restarted for each block of trace captured  - which is where the patch
> set from James that does this using AUX records in perf to correctly
> split the AUXTRACE records into valid blocks is needed.

I am still waiting for a new revision from James.

> 
> In summary:-
> 1) ETM strobing samples trace to allow greater coverage of the program
> being traced for a given buffer. This is useful when building
> statistical profiles such as for AutoFDO
> 2) ETR polling ensures that more trace is collected across the entire
> trace session - seeking to reduce inconsistent capture volumes.

I am not convinced disabling a sink to collect traces while an
event is active is the right way to go.  To me it will add (more) complexity to
the coresight subsystem for very little gains, if any.

If I remember correctly Leo brought forward the exact same idea about a year ago
and after discussion, we all agreed the benefit would not be important enough to
offset the drawbacks.

As usual I am open to discussion and my opinion is not set in stone.  But as I
mentioned I worry the feature will increase complexity in the driver and
produce dubious results.  And we also have to factor in usability which, as
Al pointed, out will be a problem. 

> 3) Use AUX records to split the AUXTRACE buffer into valid capture
> blocks and reset the decoder at the start of these blocks. This is
> essential for ETE+TRBE, the ETR polling, and systems where we are
> seeing hardware errata around the flush process causing similar
> spurious packets. (an alternative for the ETR polling / flush errata
> might be to insert barrier packets to force a decoder reset for every
> ETR block copied to the perf buffer - but this does not work for
> ETE/TRBE that uses no CoreSight formatted framing).
> 
> Regards
> 
> Mike
> 
> 
> >
> > >
> > > Thanks,
> > > Mathieu
> > >
> > > PS: Always run your work through checkpatch.pl before sending a patchset for
> > > review.
> > >
> > > [1].
> > > https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/log/?h=next-
> > > ETE-TRBE
> > >
> > > > Daniel Kiss (4):
> > > >   coresight: tmc-etr: Advance buffer pointer in sync buffer.
> > > >   coresight: tmc-etr: Track perf handler.
> > > >   coresight: etm-perf: Export etm_event_cpu_path.
> > > >   coresight: Add ETR-PERF polling.
> > > >
> > > >  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
> > > >  drivers/hwtracing/coresight/Makefile          |   2 +-
> > > >  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
> > > >  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
> > > >  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
> > > >  .../coresight/coresight-etr-perf-polling.h    |  42 +++
> > > >  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
> > > >  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
> > > >  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
> > > >  9 files changed, 401 insertions(+), 4 deletions(-)  create mode
> > > > 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
> > > >  create mode 100644
> > > > drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> > > >
> > > > --
> > > > 2.25.1
> > > >
> > > _______________________________________________
> > > CoreSight mailing list
> > > CoreSight at lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/coresight
> 
> 
> 
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK


From leo.yan at linaro.org  Tue Apr 27 17:04:43 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 28 Apr 2021 00:04:43 +0800
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210427154746.GA1422814@xps15>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210426175425.GA1391779@xps15>
 <AM0PR08MB3347CD12BB300A2A224BB7A586419@AM0PR08MB3347.eurprd08.prod.outlook.com>
 <CAJ9a7Vi6yEvKBxCAvvq2X_0WNs570-W+=nQ17AJNJOi+_a+Rzg@mail.gmail.com>
 <20210427154746.GA1422814@xps15>
Message-ID: <20210427160443.GA208852@leoy-ThinkPad-X240s>

On Tue, Apr 27, 2021 at 09:47:46AM -0600, Mathieu Poirier wrote:

[...]

> > 2) ETR polling ensures that more trace is collected across the entire
> > trace session - seeking to reduce inconsistent capture volumes.
> 
> I am not convinced disabling a sink to collect traces while an
> event is active is the right way to go.  To me it will add (more) complexity to
> the coresight subsystem for very little gains, if any.
> 
> If I remember correctly Leo brought forward the exact same idea about a year ago
> and after discussion, we all agreed the benefit would not be important enough to
> offset the drawbacks.
> 
> As usual I am open to discussion and my opinion is not set in stone.  But as I
> mentioned I worry the feature will increase complexity in the driver and
> produce dubious results.  And we also have to factor in usability which, as
> Al pointed, out will be a problem. 

Just want to remind one thing for ETR polling.  From one perspective,
the ETR polling mode is actually very similar with perf's snapshot
mode.  E.g. we can use specific interval to send USR2 singal to perf
tool to captcure CoreSight trace data, thus it also can record the
trace data continuously.

I can see a benefit from ETR polling mode is it might introduce less
overhead than perf snapshot mode.  The kernel's mechanism (workqueue
or kernel thread) will be much efficiency than perf's signal handling
+ SMP call with IPIs.

So it's good to firstly understand if perf snapshot mode can meet the
requirement or not.

Thanks,
Leo


From james.clark at arm.com  Tue Apr 27 17:24:40 2021
From: james.clark at arm.com (James Clark)
Date: Tue, 27 Apr 2021 19:24:40 +0300
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <20210421120413.3110775-1-daniel.kiss@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
Message-ID: <df3bcfcb-eacf-7807-6c26-e4b94bce80d3@arm.com>



On 21/04/2021 15:04, Daniel Kiss wrote:
> This series adds a feature to ETR-PERF that sync the ETR buffer to perf
> periodically. This is really handy when the system wide trace is used
> because in this case the perf won't sync during the trace. In a per-thread
> setup the traced program might not go to the kernel frequvently enought
> to collect trace. Polling helps in both usecases. Can be used with strobing.
> Tuning polling period is challanging, I'm working on an additional patch
> that adds some metrics to help tune the polling period.

Hi Daniel,

Is the expectation that leaving the polling period at 0 should have no affect
on the amount of data collected vs not using this patch?

I've been running the octane 2 benchmark on Chrome on Juno and get these results:

  No patch:             I consistently get 130MB of trace across dozens of runs.
  Patch, polling = 0:   Run 1 - 6.1MB
                        Run 2 - 4.7MB
  Patch, polling = 100: 1600MB


Thanks
James

> 
> Daniel Kiss (4):
>   coresight: tmc-etr: Advance buffer pointer in sync buffer.
>   coresight: tmc-etr: Track perf handler.
>   coresight: etm-perf: Export etm_event_cpu_path.
>   coresight: Add ETR-PERF polling.
> 
>  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
>  drivers/hwtracing/coresight/Makefile          |   2 +-
>  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
>  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
>  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
>  .../coresight/coresight-etr-perf-polling.h    |  42 +++
>  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
>  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>  9 files changed, 401 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h
> 


From lkp at intel.com  Tue Apr 27 17:27:39 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 00:27:39 +0800
Subject: [PATCH 3/3] irqchip: xilinx: Add support to remove the Xilinx
 INTC driver module.
In-Reply-To: <20210427113136.12469-4-anirudha.sarangi@xilinx.com>
References: <20210427113136.12469-4-anirudha.sarangi@xilinx.com>
Message-ID: <202104280007.sYrmwyYo-lkp@intel.com>

Hi Anirudha,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/irq/core]
[also build test ERROR on robh/for-next linus/master v5.12 next-20210427]
[cannot apply to xlnx/master]
[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]

url:    https://github.com/0day-ci/linux/commits/Anirudha-Sarangi/Updates-in-irqchip-framework-to-remove-irqchip/20210427-193255
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 765822e1569a37aab5e69736c52d4ad4a289eba6
config: microblaze-randconfig-s031-20210426 (attached as .config)
compiler: microblaze-linux-gcc (GCC) 9.3.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.3-341-g8af24329-dirty
        # https://github.com/0day-ci/linux/commit/5ca8cc6e787f51feed9a979547906dded222b51b
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Anirudha-Sarangi/Updates-in-irqchip-framework-to-remove-irqchip/20210427-193255
        git checkout 5ca8cc6e787f51feed9a979547906dded222b51b
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=microblaze 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/irqchip/irq-xilinx-intc.c: In function 'xilinx_intc_of_remove':
>> drivers/irqchip/irq-xilinx-intc.c:275:10: error: 'struct xintc_irq_chip' has no member named 'domain'
     275 |  if (irqc->domain) {
         |          ^~
   drivers/irqchip/irq-xilinx-intc.c:277:25: error: 'struct xintc_irq_chip' has no member named 'domain'
     277 |   irq_domain_remove(irqc->domain);
         |                         ^~


vim +275 drivers/irqchip/irq-xilinx-intc.c

   262	
   263	static int xilinx_intc_of_remove(struct device_node *intc,
   264					 struct device_node *parent)
   265	{
   266		int irq;
   267		struct xintc_irq_chip *irqc;
   268	
   269		if (!parent)
   270			return 0;
   271	
   272		irqc = intc->data;
   273		irq = irqc->irq;
   274		irq_set_chained_handler_and_data(irq, NULL, NULL);
 > 275		if (irqc->domain) {
   276			irq_dispose_mapping(irq);
   277			irq_domain_remove(irqc->domain);
   278		}
   279		/*
   280		 * Disable all external interrupts until they are
   281		 * explicity requested.
   282		 */
   283		xintc_write(irqc, IER, 0);
   284		/* Acknowledge any pending interrupts just in case. */
   285		xintc_write(irqc, IAR, 0xffffffff);
   286		/* Turn off the Master Enable. */
   287		xintc_write(irqc, MER, 0x0);
   288	
   289		iounmap(irqc->base);
   290		kfree(irqc);
   291	
   292		return 0;
   293	}
   294	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 24139 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/323eb1c6/attachment-0001.gz>

From f.fainelli at gmail.com  Tue Apr 27 17:40:50 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 27 Apr 2021 09:40:50 -0700
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
 <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
Message-ID: <6416c580-0df9-7d36-c42d-65293c40aa25@gmail.com>



On 4/26/2021 9:48 PM, Joakim Zhang wrote:
> 
>> -----Original Message-----
>> From: Oleksij Rempel <o.rempel at pengutronix.de>
>> Sent: 2021?4?23? 12:37
>> To: Joakim Zhang <qiangqing.zhang at nxp.com>
>> Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
>> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian Fainelli
>> <f.fainelli at gmail.com>; Heiner Kallweit <hkallweit1 at gmail.com>; Fugang
>> Duan <fugang.duan at nxp.com>; kernel at pengutronix.de;
>> netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
>> Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>; Russell
>> King <linux at armlinux.org.uk>; Philippe Schenker
>> <philippe.schenker at toradex.com>
>> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support
>>
>> Hi Joakim,
>>
>> On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
>>>
>>> Hi Oleksij,
>>>
>>> I look both stmmac selftest code and this patch set. For stmmac, if PHY
>> doesn't support loopback, it will fallthrough to MAC loopback.
>>> You provide this generic net selftest support based on PHY loopback, I have a
>> question, is it possible to extend it also support MAC loopback later?
>>
>> Yes. If you have interest and time to implement it, please do.
>> It should be some kind of generic callback as phy_loopback() and if PHY and
>> MAC loopbacks are supported we need to tests both variants.
> Hi Oleksij,
> 
> Yes, I can try to implement it when I am free, but I still have some questions:
> 1. Where we place the generic function? Such as mac_loopback().
> 2. MAC is different from PHY, need program different registers to enable loopback on different SoCs, that means we need get MAC private data from "struct net_device".
> So we need a callback for MAC drivers, where we extend this callback? Could be "struct net_device_ops"? Such as ndo_set_loopback?

Even for PHY devices, if we implemented external PHY loopback in the
future, the programming would be different from one vendor to another. I
am starting to wonder if the existing ethtool self-tests are the best
API to expose the ability for an user to perform PHY and MAC loopback
testing.

>From an Ethernet MAC and PHY driver perspective, what I would imagine we
could have for a driver API is:

enum ethtool_loopback_mode {
	ETHTOOL_LOOPBACK_OFF,
	ETHTOOL_LOOPBACK_PHY_INTERNAL,
	ETHTOOL_LOOPBACK_PHY_EXTERNAL,
	ETHTOOL_LOOPBACK_MAC_INTERNAL,
	ETHTOOL_LOOPBACK_MAC_EXTERNAL,
	ETHTOOL_LOOPBACK_FIXTURE,
	__ETHTOOL_LOOPBACK_MAX
};

	int (*ndo_set_loopback_mode)(struct net_device *dev, enum
ethtool_loopback_mode mode);

and within the Ethernet MAC driver you would do something like this:

	switch (mode) {
	case ETHTOOL_LOOPBACK_PHY_INTERNAL:
	case ETHTOOL_LOOPBACK_PHY_EXTERNAL:
	case ETHTOOL_LOOPBACK_OFF:
		ret = phy_loopback(ndev->phydev, mode);
		break;
	/* Other case statements implemented in driver */
	
we would need to change the signature of phy_loopback() to accept being
passed ethtool_loopback_mode so we can support different modes.

Whether we want to continue using the self-tests API, or if we implement
a new ethtool command in order to request a loopback operation is up for
discussion.
-- 
Florian


From robin.murphy at arm.com  Tue Apr 27 17:50:00 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 27 Apr 2021 17:50:00 +0100
Subject: [PATCH] arm64:align function __arch_clear_user
In-Reply-To: <b7ed22f7-2c89-c67d-5e06-380964371150@huawei.com>
References: <58fecb22-f932-cb6e-d996-ca75fe26a75d@huawei.com>
 <20210414104144.GB8320@arm.com>
 <6829062c-a2d4-57da-4037-269fb7508993@huawei.com>
 <20210423153701.GP18757@arm.com>
 <b7ed22f7-2c89-c67d-5e06-380964371150@huawei.com>
Message-ID: <3fde204b-5dfd-f7dd-cdc9-37c2fabdd723@arm.com>

On 2021-04-25 03:07, Kai Shen wrote:
> On 2021/4/23 23:37, Catalin Marinas wrote:
>> On Mon, Apr 19, 2021 at 10:05:16AM +0800, Kai Shen wrote:
>>> On 2021/4/14 18:41, Catalin Marinas wrote:
>>>> On Wed, Apr 14, 2021 at 05:25:43PM +0800, Kai Shen wrote:
>>>>> Performance decreases happen in __arch_clear_user when this
>>>>> function is not correctly aligned on HISI-HIP08 arm64 SOC which
>>>>> fetches 32 bytes (8 instructions) from icache with a 32-bytes
>>>>> aligned end address. As a result, if the hot loop is not 32-bytes
>>>>> aligned, it may take more icache fetches which leads to decrease
>>>>> in performance.
>>>>> Dump of assembler code for function __arch_clear_user:
>>>>> ???????? 0xffff0000809e3f10 :??? nop
>>>>> ???????? 0xffff0000809e3f14 :??? mov x2, x1
>>>>> ???????? 0xffff0000809e3f18 :??? subs x1, x1, #0x8
>>>>> ???????? 0xffff0000809e3f1c :??? b.mi 0xffff0000809e3f30 
>>>>> <__arch_clear_user+3
>>>>> -----? 0xffff0000809e3f20 :??? str??? xzr, [x0],#8
>>>>> hot??? 0xffff0000809e3f24 :??? nop
>>>>> loop?? 0xffff0000809e3f28 :??? subs x1, x1, #0x8
>>>>> -----? 0xffff0000809e3f2c :??? b.pl? 0xffff0000809e3f20 
>>>>> <__arch_clear_user+1
>>>>> The hot loop above takes one icache fetch as the code is in one
>>>>> 32-bytes aligned area and the loop takes one more icache fetch
>>>>> when it is not aligned like below.
>>>>> ???????? 0xffff0000809e4178 :?? str??? xzr, [x0],#8
>>>>> ???????? 0xffff0000809e417c :?? nop
>>>>> ???????? 0xffff0000809e4180 :?? subs x1, x1, #0x8
>>>>> ???????? 0xffff0000809e4184 :?? b.pl? 0xffff0000809e4178 
>>>>> <__arch_clear_user+
>>>>> Data collected by perf:
>>>>> ?????????????????????????? aligned?? not aligned
>>>>> ??????????? instructions?? 57733790???? 57739065
>>>>> ???????? L1-dcache-store?? 14938070???? 13718242
>>>>> L1-dcache-store-misses???? 349280?????? 349869
>>>>> ???????? L1-icache-loads?? 15380895???? 28500665
>>>>> As we can see, L1-icache-loads almost double when the loop is not
>>>>> aligned.

Sure, if the function spans two cache lines, and I$ pressure is so high 
that it gets evicted between each call, then indeed one would expect 
about twice as many fetches in total compared to if the function fits in 
a single line. However, that's not necessarily indicative of visible 
performance - if the predictors and prefetchers can do their jobs well 
enough there could still be little to no impact on actual execution latency.

If you want to use perf to try to justify this, at least drill down into 
more specific events to show that you're really stalling on I$ misses. 
The most convincing argument, though, would be a measured difference in 
actual user-memory-zeroing bandwidth - the fact that you haven't shared 
that, even for your synthetic test, makes me suspect that it's probably 
not as significant and exciting as a supposed "2x" figure... ;)

>>>>> This problem is found in linux 4.19 on HISI-HIP08 arm64 SOC.
>>>>> Not sure what the case is on other arm64 SOC, but it should do
>>>>> no harm.
>>>>> Signed-off-by: Kai Shen <shenkai8 at huawei.com>
>>>>
>>>> Do you have a real world workload that's affected by this function?
>>>>
>>>> I'm against adding alignments and nops for specific hardware
>>>> implementations. What about lots of other loops that the compiler may
>>>> generate or that we wrote in asm?
>>>
>>> The benchmark we used which suffer performance decrease:
>>> ???? https://github.com/redhat-performance/libMicro
>>> ???? pread $OPTS -N "pread_z1k"??? -s 1k??? -I 300? -f /dev/zero
>>> ???? pread $OPTS -N "pread_z10k"??? -s 10k??? -I 1000 -f /dev/zero
>>> ???? pread $OPTS -N "pread_z100k"??? -s 100k??? -I 2000 -f /dev/zero
>>
>> Is there any real world use-case that would benefit from this
>> optimisation? Reading /dev/zero in a loop hardly counts as a practical
>> workload.
>>
> Operations like "dd if=/dev/zero of=/dev/sda1" ?

Surely the write() side of that operation is still going to dominate 
either way? What kind of device would sda be for the whole operation to 
be significantly bottlenecked on *instruction fetch bandwidth* in read()!?

FWIW I'm currently playing about with some changes to this code anyway - 
I'll make sure to check whether function alignment has any noticeable 
impact on the microarchitectures I have to hand.

Robin.


From robin.murphy at arm.com  Tue Apr 27 18:37:24 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 27 Apr 2021 18:37:24 +0100
Subject: [PATCH v2 1/3] ACPI/IORT: Consolidate use of SMMU device platdata
In-Reply-To: <20210402035602.9484-2-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
 <20210402035602.9484-2-shawn.guo@linaro.org>
Message-ID: <bf51c5b3-082c-98dd-ff8d-559ef5b56bad@arm.com>

On 2021-04-02 04:56, Shawn Guo wrote:
> Currently the platdata is being used in different way by SMMU and PMCG
> device.  The former uses it for acpi_iort_node pointer passing, while
> the later uses it for model identifier.  As it's been seen that the
> model identifier is useful for SMMU devices as well, let's consolidate
> the platdata use to get it accommodate both acpi_iort_node pointer and
> model identifier, so that all IORT devices (SMMU, SMMUv3 and PMCG) pass
> platdata in a consistent manner.
> 
> With this change, model identifier is not specific to PMCG, so
> IORT_SMMU_V3_PMCG_GENERIC gets renamed to IORT_SMMU_GENERIC.  While at
> it, the spaces used in model defines are converted to tabs.

SMMUs and PMCGs are deliberately kept distinct because they are not 
necessarily equivalent - a PMCG may belong to something other than an 
SMMU, (like a root complex or a device with its own TLB), and even a 
single SMMU may implement heterogeneous PMCGs (e.g. Arm's MMU-600 has 
PMCGs in its control unit and TLB units which count different sets of 
events). So NAK to that aspect, sorry.

FWIW this was originally here because we envisaged needing to identify 
individual PMCG implementations through a variety of poking at different 
fields and tables, so hiding that behind an abstraction in ACPI code 
seemed neatest. However, things haven't really panned out that way - now 
we seem to have moved more towards describing events in userspace in 
conjunction with other system-specific identifiers. If we've no need to 
identify PMCGs in the kernel for the sake of exporting imp-def events, 
then most of the argument for this PMCG identifier abstraction is gone, 
and it's looking increasingly like the HIP08 case deserves to be punted 
back to the PMCG driver itself as a one-off erratum workaround.

I think at this point we should accept that if a driver needs to match 
*some* platform-specific data for its own internal purposes, the fact 
that that data might be the IORT header still doesn't make it "IORT 
functionality", and referencing ACPI_SIG_IORT from drivers is a lesser 
evil than cluttering up the IORT code with increasing amounts of random 
stuff that's outside the scope of the IORT specification itself.

Robin.

> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>   drivers/acpi/arm64/iort.c                   | 31 ++++++++-------------
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  6 +++-
>   drivers/iommu/arm/arm-smmu/arm-smmu.c       |  9 ++++--
>   drivers/perf/arm_smmuv3_pmu.c               |  8 ++++--
>   include/linux/acpi_iort.h                   | 11 ++++++--
>   5 files changed, 36 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 2494138a6905..e2a96d2d399a 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1463,25 +1463,28 @@ static void __init arm_smmu_v3_pmcg_init_resources(struct resource *res,
>   				       ACPI_EDGE_SENSITIVE, &res[2]);
>   }
>   
> -static struct acpi_platform_list pmcg_plat_info[] __initdata = {
> +static struct acpi_platform_list iort_plat_info[] __initdata = {
>   	/* HiSilicon Hip08 Platform */
>   	{"HISI  ", "HIP08   ", 0, ACPI_SIG_IORT, greater_than_or_equal,
>   	 "Erratum #162001800", IORT_SMMU_V3_PMCG_HISI_HIP08},
>   	{ }
>   };
>   
> -static int __init arm_smmu_v3_pmcg_add_platdata(struct platform_device *pdev)
> +static int __init iort_smmu_add_platdata(struct platform_device *pdev,
> +					 struct acpi_iort_node *node)
>   {
> -	u32 model;
> +	struct iort_smmu_pdata pdata;
>   	int idx;
>   
> -	idx = acpi_match_platform_list(pmcg_plat_info);
> +	pdata.node = node;
> +
> +	idx = acpi_match_platform_list(iort_plat_info);
>   	if (idx >= 0)
> -		model = pmcg_plat_info[idx].data;
> +		pdata.model = iort_plat_info[idx].data;
>   	else
> -		model = IORT_SMMU_V3_PMCG_GENERIC;
> +		pdata.model = IORT_SMMU_GENERIC;
>   
> -	return platform_device_add_data(pdev, &model, sizeof(model));
> +	return platform_device_add_data(pdev, &pdata, sizeof(pdata));
>   }
>   
>   struct iort_dev_config {
> @@ -1494,7 +1497,6 @@ struct iort_dev_config {
>   				     struct acpi_iort_node *node);
>   	int (*dev_set_proximity)(struct device *dev,
>   				    struct acpi_iort_node *node);
> -	int (*dev_add_platdata)(struct platform_device *pdev);
>   };
>   
>   static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
> @@ -1516,7 +1518,6 @@ static const struct iort_dev_config iort_arm_smmu_v3_pmcg_cfg __initconst = {
>   	.name = "arm-smmu-v3-pmcg",
>   	.dev_count_resources = arm_smmu_v3_pmcg_count_resources,
>   	.dev_init_resources = arm_smmu_v3_pmcg_init_resources,
> -	.dev_add_platdata = arm_smmu_v3_pmcg_add_platdata,
>   };
>   
>   static __init const struct iort_dev_config *iort_get_dev_cfg(
> @@ -1579,17 +1580,7 @@ static int __init iort_add_platform_device(struct acpi_iort_node *node,
>   	if (ret)
>   		goto dev_put;
>   
> -	/*
> -	 * Platform devices based on PMCG nodes uses platform_data to
> -	 * pass the hardware model info to the driver. For others, add
> -	 * a copy of IORT node pointer to platform_data to be used to
> -	 * retrieve IORT data information.
> -	 */
> -	if (ops->dev_add_platdata)
> -		ret = ops->dev_add_platdata(pdev);
> -	else
> -		ret = platform_device_add_data(pdev, &node, sizeof(node));
> -
> +	ret = iort_smmu_add_platdata(pdev, node);
>   	if (ret)
>   		goto dev_put;
>   
> 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 8ca7415d785d..91c9a74d8ac6 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3397,9 +3397,13 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
>   {
>   	struct acpi_iort_smmu_v3 *iort_smmu;
>   	struct device *dev = smmu->dev;
> +	struct iort_smmu_pdata *pdata = dev_get_platdata(dev);
>   	struct acpi_iort_node *node;
>   
> -	node = *(struct acpi_iort_node **)dev_get_platdata(dev);
> +	if (pdata == NULL)
> +		return -ENODEV;
> +
> +	node = pdata->node;
>   
>   	/* Retrieve SMMUv3 specific data */
>   	iort_smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index d8c6bfde6a61..d53ab3927a30 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -1991,11 +1991,16 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
>   				      struct arm_smmu_device *smmu)
>   {
>   	struct device *dev = smmu->dev;
> -	struct acpi_iort_node *node =
> -		*(struct acpi_iort_node **)dev_get_platdata(dev);
> +	struct iort_smmu_pdata *pdata = dev_get_platdata(dev);
> +	struct acpi_iort_node *node;
>   	struct acpi_iort_smmu *iort_smmu;
>   	int ret;
>   
> +	if (pdata == NULL)
> +		return -ENODEV;
> +
> +	node = pdata->node;
> +
>   	/* Retrieve SMMU1/2 specific data */
>   	iort_smmu = (struct acpi_iort_smmu *)node->node_data;
>   
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index 74474bb322c3..77fcf5e7413a 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
> @@ -747,17 +747,19 @@ static void smmu_pmu_reset(struct smmu_pmu *smmu_pmu)
>   
>   static void smmu_pmu_get_acpi_options(struct smmu_pmu *smmu_pmu)
>   {
> -	u32 model;
> +	struct iort_smmu_pdata *pdata = dev_get_platdata(smmu_pmu->dev);
>   
> -	model = *(u32 *)dev_get_platdata(smmu_pmu->dev);
> +	if (pdata == NULL)
> +		goto done;
>   
> -	switch (model) {
> +	switch (pdata->model) {
>   	case IORT_SMMU_V3_PMCG_HISI_HIP08:
>   		/* HiSilicon Erratum 162001800 */
>   		smmu_pmu->options |= SMMU_PMCG_EVCNTR_RDONLY;
>   		break;
>   	}
>   
> +done:
>   	dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
>   }
>   
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 1a12baa58e40..678cdf036948 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -15,12 +15,17 @@
>   #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
>   
>   /*
> - * PMCG model identifiers for use in smmu pmu driver. Please note
> + * Model identifiers for use in SMMU drivers. Please note
>    * that this is purely for the use of software and has nothing to
>    * do with hardware or with IORT specification.
>    */
> -#define IORT_SMMU_V3_PMCG_GENERIC        0x00000000 /* Generic SMMUv3 PMCG */
> -#define IORT_SMMU_V3_PMCG_HISI_HIP08     0x00000001 /* HiSilicon HIP08 PMCG */
> +#define IORT_SMMU_GENERIC		0x00000000 /* Generic SMMU */
> +#define IORT_SMMU_V3_PMCG_HISI_HIP08	0x00000001 /* HiSilicon HIP08 PMCG */
> +
> +struct iort_smmu_pdata {
> +	struct acpi_iort_node *node;
> +	u32 model;
> +};
>   
>   int iort_register_domain_token(int trans_id, phys_addr_t base,
>   			       struct fwnode_handle *fw_node);
> 


From robin.murphy at arm.com  Tue Apr 27 18:41:12 2021
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 27 Apr 2021 18:41:12 +0100
Subject: [PATCH v2 2/3] ACPI/IORT: Add Qualcomm Snapdragon platforms to
 iort_plat_info[]
In-Reply-To: <20210402035602.9484-3-shawn.guo@linaro.org>
References: <20210402035602.9484-1-shawn.guo@linaro.org>
 <20210402035602.9484-3-shawn.guo@linaro.org>
Message-ID: <06a62dc7-f2d8-7b74-3240-adf8504c5063@arm.com>

On 2021-04-02 04:56, Shawn Guo wrote:
> The SMMU driver on Qualcomm Snapdragon platforms needs to hook up some
> QCOM specific arm_smmu_impl.  Define model identifier for QCOM SMMU and
> add Qualcomm SC8180X platform to iort_plat_info[], so that SMMU
> driver can detect the model and handle QCOM specific arm_smmu_impl.
> 
> Some device chooses to use manufacturer name in IORT table, like Lenovo
> Flex 5G, while others use SoC vendor name, such as Microsoft Surface Pro
> X and Samsung Galaxy Book S.

Just to clarify, my expectation was that the relevant match table and 
its usage would be private to arm-smmu-qcom. There didn't seem to be any 
obvious reason that couldn't work, but please do enlighten me if I've 
overlooked something.

Robin.

> Signed-off-by: Shawn Guo <shawn.guo at linaro.org>
> ---
>   drivers/acpi/arm64/iort.c | 5 +++++
>   include/linux/acpi_iort.h | 1 +
>   2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index e2a96d2d399a..f88b8c0a7d84 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -1467,6 +1467,11 @@ static struct acpi_platform_list iort_plat_info[] __initdata = {
>   	/* HiSilicon Hip08 Platform */
>   	{"HISI  ", "HIP08   ", 0, ACPI_SIG_IORT, greater_than_or_equal,
>   	 "Erratum #162001800", IORT_SMMU_V3_PMCG_HISI_HIP08},
> +	/* Qualcomm Snapdragon Platform */
> +	{ "LENOVO", "CB-01   ", 0x8180, ACPI_SIG_IORT, equal,
> +	  "QCOM SMMU", IORT_SMMU_QCOM },
> +	{ "QCOM  ", "QCOMEDK2", 0x8180, ACPI_SIG_IORT, equal,
> +	  "QCOM SMMU", IORT_SMMU_QCOM },
>   	{ }
>   };
>   
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 678cdf036948..66c859ea2abf 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -21,6 +21,7 @@
>    */
>   #define IORT_SMMU_GENERIC		0x00000000 /* Generic SMMU */
>   #define IORT_SMMU_V3_PMCG_HISI_HIP08	0x00000001 /* HiSilicon HIP08 PMCG */
> +#define IORT_SMMU_QCOM			0x00000002 /* QCOM SMMU */
>   
>   struct iort_smmu_pdata {
>   	struct acpi_iort_node *node;
> 


From catalin.marinas at arm.com  Tue Apr 27 18:43:58 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 27 Apr 2021 18:43:58 +0100
Subject: [PATCH v11 1/6] arm64: mte: Sync tags for pages where PTE is
 untagged
In-Reply-To: <20210416154309.22129-2-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-2-steven.price@arm.com>
Message-ID: <20210427174357.GA17872@arm.com>

On Fri, Apr 16, 2021 at 04:43:04PM +0100, Steven Price wrote:
> A KVM guest could store tags in a page even if the VMM hasn't mapped
> the page with PROT_MTE. So when restoring pages from swap we will
> need to check to see if there are any saved tags even if !pte_tagged().
> 
> However don't check pages which are !pte_valid_user() as these will
> not have been swapped out.

You should remove the pte_valid_user() mention from the commit log as
well.

> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e17b96d0e4b5..cf4b52a33b3c 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		__sync_icache_dcache(pte);
>  
>  	if (system_supports_mte() &&
> -	    pte_present(pte) && pte_tagged(pte) && !pte_special(pte))
> +	    pte_present(pte) && (pte_val(pte) & PTE_USER) && !pte_special(pte))

I would add a pte_user() macro here or, if we restore the tags only when
the page is readable, use pte_access_permitted(pte, false). Also add a
comment why we do this.

There's also the pte_user_exec() case which may not have the PTE_USER
set (exec-only permission) but I don't think it matters. We don't do tag
checking on instruction fetches, so if the user adds a PROT_READ to it,
it would go through set_pte_at() again. I'm not sure KVM does anything
special with exec-only mappings at stage 2, I suspect they won't be
accessible by the guest (but needs checking).

>  		mte_sync_tags(ptep, pte);
>  
>  	__check_racy_pte_update(mm, ptep, pte);
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index b3c70a612c7a..e016ab57ea36 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -26,17 +26,23 @@ u64 gcr_kernel_excl __ro_after_init;
>  
>  static bool report_fault_once = true;
>  
> -static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
> +static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap,
> +			       bool pte_is_tagged)
>  {
>  	pte_t old_pte = READ_ONCE(*ptep);
>  
>  	if (check_swap && is_swap_pte(old_pte)) {
>  		swp_entry_t entry = pte_to_swp_entry(old_pte);
>  
> -		if (!non_swap_entry(entry) && mte_restore_tags(entry, page))
> +		if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) {
> +			set_bit(PG_mte_tagged, &page->flags);
>  			return;
> +		}
>  	}
>  
> +	if (!pte_is_tagged || test_and_set_bit(PG_mte_tagged, &page->flags))
> +		return;

I don't think we need another test_bit() here, it was done in the
caller (bar potential races which need more thought).

> +
>  	page_kasan_tag_reset(page);
>  	/*
>  	 * We need smp_wmb() in between setting the flags and clearing the
> @@ -54,11 +60,13 @@ void mte_sync_tags(pte_t *ptep, pte_t pte)
>  	struct page *page = pte_page(pte);
>  	long i, nr_pages = compound_nr(page);
>  	bool check_swap = nr_pages == 1;
> +	bool pte_is_tagged = pte_tagged(pte);
>  
>  	/* if PG_mte_tagged is set, tags have already been initialised */
>  	for (i = 0; i < nr_pages; i++, page++) {
> -		if (!test_and_set_bit(PG_mte_tagged, &page->flags))
> -			mte_sync_page_tags(page, ptep, check_swap);
> +		if (!test_bit(PG_mte_tagged, &page->flags))
> +			mte_sync_page_tags(page, ptep, check_swap,
> +					   pte_is_tagged);
>  	}
>  }

You were right in the previous thread that if we have a race, it's
already there even without your patches KVM patches.

If it's the same pte in a multithreaded app, we should be ok as the core
code holds the ptl (the arch code also holds the mmap_lock during
exception handling but only as a reader, so you can have multiple
holders).

If there are multiple ptes to the same page, for example mapped with
MAP_ANONYMOUS | MAP_SHARED, metadata recovery is done via
arch_swap_restore() before we even set the pte and with the page locked.
So calling lock_page() again in mte_restore_tags() would deadlock.

I can see that do_swap_page() also holds the page lock around
set_pte_at(), so I think we are covered.

Any other scenario I may have missed? My understanding is that if the
pte is the same, we have the ptl. Otherwise we have the page lock for
shared pages.

-- 
Catalin


From jim2101024 at gmail.com  Tue Apr 27 18:51:35 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 27 Apr 2021 13:51:35 -0400
Subject: [PATCH v1 0/4] PCI: brcmstb: Add panic handler and shutdown func
Message-ID: <20210427175140.17800-1-jim2101024@gmail.com>

v1 -- These commits were part of a previous pullreq but have
      been split off because they are unrelated to said pullreq's
      other more complex commits.

Jim Quinlan (4):
  PCI: brcmstb: Check return value of clk_prepare_enable()
  PCI: brcmstb: Give 7216 SOCs their own config type
  PCI: brcmstb: Add panic/die handler to RC driver
  PCI: brcmstb: add shutdown call to driver

 drivers/pci/controller/pcie-brcmstb.c | 145 +++++++++++++++++++++++++-
 1 file changed, 143 insertions(+), 2 deletions(-)

-- 
2.17.1



From jim2101024 at gmail.com  Tue Apr 27 18:51:36 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 27 Apr 2021 13:51:36 -0400
Subject: [PATCH v1 1/4] PCI: brcmstb: Check return value of
 clk_prepare_enable()
In-Reply-To: <20210427175140.17800-1-jim2101024@gmail.com>
References: <20210427175140.17800-1-jim2101024@gmail.com>
Message-ID: <20210427175140.17800-2-jim2101024@gmail.com>

Check for failure of clk_prepare_enable() on device resume.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
Fixes: 8195b7417018 ("PCI: brcmstb: Add suspend and resume pm_ops")
---
 drivers/pci/controller/pcie-brcmstb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index e330e6811f0b..4ce1f3a60574 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1161,7 +1161,9 @@ static int brcm_pcie_resume(struct device *dev)
 	int ret;
 
 	base = pcie->base;
-	clk_prepare_enable(pcie->clk);
+	ret = clk_prepare_enable(pcie->clk);
+	if (ret)
+		return ret;
 
 	ret = brcm_phy_start(pcie);
 	if (ret)
-- 
2.17.1



From jim2101024 at gmail.com  Tue Apr 27 18:51:37 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 27 Apr 2021 13:51:37 -0400
Subject: [PATCH v1 2/4] PCI: brcmstb: Give 7216 SOCs their own config type
In-Reply-To: <20210427175140.17800-1-jim2101024@gmail.com>
References: <20210427175140.17800-1-jim2101024@gmail.com>
Message-ID: <20210427175140.17800-3-jim2101024@gmail.com>

This distinction is required for an imminent commit.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 4ce1f3a60574..3b6a62dd2e72 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -257,6 +257,13 @@ static const struct pcie_cfg_data bcm2711_cfg = {
 	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_generic,
 };
 
+static const struct pcie_cfg_data bcm7216_cfg = {
+	.offsets	= pcie_offset_bcm7278,
+	.type		= BCM7278,
+	.perst_set	= brcm_pcie_perst_set_7278,
+	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
+};
+
 struct brcm_msi {
 	struct device		*dev;
 	void __iomem		*base;
@@ -1220,7 +1227,7 @@ static const struct of_device_id brcm_pcie_match[] = {
 	{ .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
 	{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
 	{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
-	{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
+	{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7216_cfg },
 	{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
 	{},
 };
-- 
2.17.1



From jim2101024 at gmail.com  Tue Apr 27 18:51:38 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 27 Apr 2021 13:51:38 -0400
Subject: [PATCH v1 3/4] PCI: brcmstb: Add panic/die handler to RC driver
In-Reply-To: <20210427175140.17800-1-jim2101024@gmail.com>
References: <20210427175140.17800-1-jim2101024@gmail.com>
Message-ID: <20210427175140.17800-4-jim2101024@gmail.com>

Whereas most PCIe HW returns 0xffffffff on illegal accesses and the like,
by default Broadcom's STB PCIe controller effects an abort.  This simple
handler determines if the PCIe controller was the cause of the abort and if
so, prints out diagnostic info.

Example output:
  brcm-pcie 8b20000.pcie: Error: Mem Acc: 32bit, Read, @0x38000000
  brcm-pcie 8b20000.pcie:  Type: TO=0 Abt=0 UnspReq=1 AccDsble=0 BadAddr=0

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 122 ++++++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 3b6a62dd2e72..d3af8d84f0d6 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -12,11 +12,13 @@
 #include <linux/ioport.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqdomain.h>
+#include <linux/kdebug.h>
 #include <linux/kernel.h>
 #include <linux/list.h>
 #include <linux/log2.h>
 #include <linux/module.h>
 #include <linux/msi.h>
+#include <linux/notifier.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/of_pci.h>
@@ -184,6 +186,39 @@
 #define  PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK		0x1
 #define  PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT		0x0
 
+/* Error report regiseters */
+#define PCIE_OUTB_ERR_TREAT				0x6000
+#define  PCIE_OUTB_ERR_TREAT_CONFIG_MASK		0x1
+#define  PCIE_OUTB_ERR_TREAT_MEM_MASK			0x2
+#define PCIE_OUTB_ERR_VALID				0x6004
+#define PCIE_OUTB_ERR_CLEAR				0x6008
+#define PCIE_OUTB_ERR_ACC_INFO				0x600c
+#define  PCIE_OUTB_ERR_ACC_INFO_CFG_ERR_MASK		0x01
+#define  PCIE_OUTB_ERR_ACC_INFO_MEM_ERR_MASK		0x02
+#define  PCIE_OUTB_ERR_ACC_INFO_TYPE_64_MASK		0x04
+#define  PCIE_OUTB_ERR_ACC_INFO_DIR_WRITE_MASK		0x10
+#define  PCIE_OUTB_ERR_ACC_INFO_BYTE_LANES_MASK		0xff00
+#define PCIE_OUTB_ERR_ACC_ADDR				0x6010
+#define PCIE_OUTB_ERR_ACC_ADDR_BUS_MASK			0xff00000
+#define PCIE_OUTB_ERR_ACC_ADDR_DEV_MASK			0xf8000
+#define PCIE_OUTB_ERR_ACC_ADDR_FUNC_MASK		0x7000
+#define PCIE_OUTB_ERR_ACC_ADDR_REG_MASK			0xfff
+#define PCIE_OUTB_ERR_CFG_CAUSE				0x6014
+#define  PCIE_OUTB_ERR_CFG_CAUSE_TIMEOUT_MASK		0x40
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ABORT_MASK		0x20
+#define  PCIE_OUTB_ERR_CFG_CAUSE_UNSUPP_REQ_MASK	0x10
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_TIMEOUT_MASK	0x4
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_DISABLED_MASK	0x2
+#define  PCIE_OUTB_ERR_CFG_CAUSE_ACC_64BIT__MASK	0x1
+#define PCIE_OUTB_ERR_MEM_ADDR_LO			0x6018
+#define PCIE_OUTB_ERR_MEM_ADDR_HI			0x601c
+#define PCIE_OUTB_ERR_MEM_CAUSE				0x6020
+#define  PCIE_OUTB_ERR_MEM_CAUSE_TIMEOUT_MASK		0x40
+#define  PCIE_OUTB_ERR_MEM_CAUSE_ABORT_MASK		0x20
+#define  PCIE_OUTB_ERR_MEM_CAUSE_UNSUPP_REQ_MASK	0x10
+#define  PCIE_OUTB_ERR_MEM_CAUSE_ACC_DISABLED_MASK	0x2
+#define  PCIE_OUTB_ERR_MEM_CAUSE_BAD_ADDR_MASK		0x1
+
 /* Forward declarations */
 struct brcm_pcie;
 static inline void brcm_pcie_bridge_sw_init_set_7278(struct brcm_pcie *pcie, u32 val);
@@ -215,6 +250,7 @@ struct pcie_cfg_data {
 	const enum pcie_type type;
 	void (*perst_set)(struct brcm_pcie *pcie, u32 val);
 	void (*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
+	const bool has_err_report;
 };
 
 static const int pcie_offsets[] = {
@@ -262,6 +298,7 @@ static const struct pcie_cfg_data bcm7216_cfg = {
 	.type		= BCM7278,
 	.perst_set	= brcm_pcie_perst_set_7278,
 	.bridge_sw_init_set = brcm_pcie_bridge_sw_init_set_7278,
+	.has_err_report = true,
 };
 
 struct brcm_msi {
@@ -302,8 +339,87 @@ struct brcm_pcie {
 	u32			hw_rev;
 	void			(*perst_set)(struct brcm_pcie *pcie, u32 val);
 	void			(*bridge_sw_init_set)(struct brcm_pcie *pcie, u32 val);
+	bool			has_err_report;
+	struct notifier_block	die_notifier;
 };
 
+/* Dump out PCIe errors on die or panic */
+static int dump_pcie_error(struct notifier_block *self, unsigned long v, void *p)
+{
+	const struct brcm_pcie *pcie = container_of(self, struct brcm_pcie, die_notifier);
+	void __iomem *base = pcie->base;
+	int i, is_cfg_err, is_mem_err, lanes;
+	char *width_str, *direction_str, lanes_str[9];
+	u32 info;
+
+	if (readl(base + PCIE_OUTB_ERR_VALID) == 0)
+		return NOTIFY_DONE;
+	info = readl(base + PCIE_OUTB_ERR_ACC_INFO);
+
+
+	is_cfg_err = !!(info & PCIE_OUTB_ERR_ACC_INFO_CFG_ERR_MASK);
+	is_mem_err = !!(info & PCIE_OUTB_ERR_ACC_INFO_MEM_ERR_MASK);
+	width_str = (info & PCIE_OUTB_ERR_ACC_INFO_TYPE_64_MASK) ? "64bit" : "32bit";
+	direction_str = (info & PCIE_OUTB_ERR_ACC_INFO_DIR_WRITE_MASK) ? "Write" : "Read";
+	lanes = FIELD_GET(PCIE_OUTB_ERR_ACC_INFO_BYTE_LANES_MASK, info);
+	for (i = 0, lanes_str[8] = 0; i < 8; i++)
+		lanes_str[i] = (lanes & (1 << i)) ? '1' : '0';
+
+	if (is_cfg_err) {
+		u32 cfg_addr = readl(base + PCIE_OUTB_ERR_ACC_ADDR);
+		u32 cause = readl(base + PCIE_OUTB_ERR_CFG_CAUSE);
+		int bus = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_BUS_MASK, cfg_addr);
+		int dev = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_DEV_MASK, cfg_addr);
+		int func = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_FUNC_MASK, cfg_addr);
+		int reg = FIELD_GET(PCIE_OUTB_ERR_ACC_ADDR_REG_MASK, cfg_addr);
+
+		dev_err(pcie->dev, "Error: CFG Acc, %s, %s, Bus=%d, Dev=%d, Fun=%d, Reg=0x%x, lanes=%s\n",
+			width_str, direction_str, bus, dev, func, reg, lanes_str);
+		dev_err(pcie->dev, " Type: TO=%d Abt=%d UnsupReq=%d AccTO=%d AccDsbld=%d Acc64bit=%d\n",
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ABORT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_UNSUPP_REQ_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_DISABLED_MASK),
+			!!(cause & PCIE_OUTB_ERR_CFG_CAUSE_ACC_64BIT__MASK));
+	}
+
+	if (is_mem_err) {
+		u32 cause = readl(base + PCIE_OUTB_ERR_MEM_CAUSE);
+		u32 lo = readl(base + PCIE_OUTB_ERR_MEM_ADDR_LO);
+		u32 hi = readl(base + PCIE_OUTB_ERR_MEM_ADDR_HI);
+		u64 addr = ((u64)hi << 32) | (u64)lo;
+
+		dev_err(pcie->dev, "Error: Mem Acc, %s, %s, @0x%llx, lanes=%s\n",
+			width_str, direction_str, addr, lanes_str);
+		dev_err(pcie->dev, " Type: TO=%d Abt=%d UnsupReq=%d AccDsble=%d BadAddr=%d\n",
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_TIMEOUT_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_ABORT_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_UNSUPP_REQ_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_ACC_DISABLED_MASK),
+			!!(cause & PCIE_OUTB_ERR_MEM_CAUSE_BAD_ADDR_MASK));
+	}
+
+	/* Clear the error */
+	writel(1, base + PCIE_OUTB_ERR_CLEAR);
+
+	return NOTIFY_DONE;
+}
+
+static void brcm_register_die_notifiers(struct brcm_pcie *pcie)
+{
+	pcie->die_notifier.notifier_call = dump_pcie_error;
+	register_die_notifier(&pcie->die_notifier);
+	atomic_notifier_chain_register(&panic_notifier_list, &pcie->die_notifier);
+}
+
+static void brcm_unregister_die_notifiers(struct brcm_pcie *pcie)
+{
+	unregister_die_notifier(&pcie->die_notifier);
+	atomic_notifier_chain_unregister(&panic_notifier_list, &pcie->die_notifier);
+	pcie->die_notifier.notifier_call = NULL;
+}
+
 /*
  * This is to convert the size of the inbound "BAR" region to the
  * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
@@ -1216,6 +1332,8 @@ static int brcm_pcie_remove(struct platform_device *pdev)
 	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
 
 	pci_stop_root_bus(bridge->bus);
+	if (pcie->has_err_report)
+		brcm_unregister_die_notifiers(pcie);
 	pci_remove_root_bus(bridge->bus);
 	__brcm_pcie_remove(pcie);
 
@@ -1255,6 +1373,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 	pcie->np = np;
 	pcie->reg_offsets = data->offsets;
 	pcie->type = data->type;
+	pcie->has_err_report = data->has_err_report;
 	pcie->perst_set = data->perst_set;
 	pcie->bridge_sw_init_set = data->bridge_sw_init_set;
 
@@ -1322,6 +1441,9 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, pcie);
 
+	if (pcie->has_err_report)
+		brcm_register_die_notifiers(pcie);
+
 	return pci_host_probe(bridge);
 fail:
 	__brcm_pcie_remove(pcie);
-- 
2.17.1



From jim2101024 at gmail.com  Tue Apr 27 18:51:39 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Tue, 27 Apr 2021 13:51:39 -0400
Subject: [PATCH v1 4/4] PCI: brcmstb: add shutdown call to driver
In-Reply-To: <20210427175140.17800-1-jim2101024@gmail.com>
References: <20210427175140.17800-1-jim2101024@gmail.com>
Message-ID: <20210427175140.17800-5-jim2101024@gmail.com>

The shutdown() call is similar to the remove() call except the former does
not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
if it does.

Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index d3af8d84f0d6..a1fe1a2ada48 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1340,6 +1340,15 @@ static int brcm_pcie_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static void brcm_pcie_shutdown(struct platform_device *pdev)
+{
+	struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+	if (pcie->has_err_report)
+		brcm_unregister_die_notifiers(pcie);
+	__brcm_pcie_remove(pcie);
+}
+
 static const struct of_device_id brcm_pcie_match[] = {
 	{ .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
 	{ .compatible = "brcm,bcm4908-pcie", .data = &bcm4908_cfg },
@@ -1460,6 +1469,7 @@ static const struct dev_pm_ops brcm_pcie_pm_ops = {
 static struct platform_driver brcm_pcie_driver = {
 	.probe = brcm_pcie_probe,
 	.remove = brcm_pcie_remove,
+	.shutdown = brcm_pcie_shutdown,
 	.driver = {
 		.name = "brcm-pcie",
 		.of_match_table = brcm_pcie_match,
-- 
2.17.1



From vigneshr at ti.com  Tue Apr 27 18:51:30 2021
From: vigneshr at ti.com (Vignesh Raghavendra)
Date: Tue, 27 Apr 2021 23:21:30 +0530
Subject: [PATCH] arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherent
Message-ID: <20210427175130.29451-1-vigneshr@ti.com>

Traffic through main NAVSS interconnect is coherent wrt ARM caches on
J7200 SoC.  Add missing dma-coherent property to main_navss node.

Also add dma-ranges to be consistent with mcu_navss node.

Fixes: d361ed88455fe ("arm64: dts: ti: Add support for J7200 SoC")
Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
---
 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index f86c493a44f1c..a6826f1888ef0 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -85,6 +85,8 @@ main_navss: bus at 30000000 {
 		#size-cells = <2>;
 		ranges = <0x00 0x30000000 0x00 0x30000000 0x00 0x0c400000>;
 		ti,sci-dev-id = <199>;
+		dma-coherent;
+		dma-ranges;
 
 		main_navss_intr: interrupt-controller1 {
 			compatible = "ti,sci-intr";
-- 
2.31.1



From catalin.marinas at arm.com  Tue Apr 27 18:58:44 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 27 Apr 2021 18:58:44 +0100
Subject: [PATCH v11 5/6] KVM: arm64: ioctl to fetch/store tags in a guest
In-Reply-To: <20210416154309.22129-6-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-6-steven.price@arm.com>
Message-ID: <20210427175844.GB17872@arm.com>

On Fri, Apr 16, 2021 at 04:43:08PM +0100, Steven Price wrote:
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 24223adae150..2b85a047c37d 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -184,6 +184,20 @@ struct kvm_vcpu_events {
>  	__u32 reserved[12];
>  };
>  
> +struct kvm_arm_copy_mte_tags {
> +	__u64 guest_ipa;
> +	__u64 length;
> +	union {
> +		void __user *addr;
> +		__u64 padding;
> +	};
> +	__u64 flags;
> +	__u64 reserved[2];
> +};

I know Marc asked for some reserved space in here but I'm not sure it's
the right place. And what's with the union of a 64-bit pointer and
64-bit padding, it doesn't change any layout? Maybe add the two reserved
values to the union in case we want to store something else in the
future.

Or maybe I'm missing something, I haven't checked how other KVM ioctls
work.

-- 
Catalin


From lkp at intel.com  Tue Apr 27 18:59:36 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 01:59:36 +0800
Subject: [xlnx:master 11243/12166] ld.lld: error: undefined symbol:
 update_stripe
Message-ID: <202104280124.Tt1OoTZV-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   d5a09f395b397dcee476af3a5c3f9de6d8a4d328
commit: ffc5cb8494ba2abe218134584b22fd874b71d504 [11243/12166] spi: Update ZynqMP and Versal QSPI controller driver
config: x86_64-randconfig-a004-20210426 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project d941863de2becb3d8d2e00676fc7125974934c7f)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/ffc5cb8494ba2abe218134584b22fd874b71d504
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout ffc5cb8494ba2abe218134584b22fd874b71d504
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: update_stripe
   >>> referenced by spi-zynqmp-gqspi.c:1173 (drivers/spi/spi-zynqmp-gqspi.c:1173)
   >>>               spi/spi-zynqmp-gqspi.o:(zynqmp_qspi_exec_op) in archive drivers/built-in.a

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 31760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/b56cdc2a/attachment-0001.gz>

From peter.ujfalusi at gmail.com  Tue Apr 27 19:19:54 2021
From: peter.ujfalusi at gmail.com (=?UTF-8?Q?P=c3=a9ter_Ujfalusi?=)
Date: Tue, 27 Apr 2021 21:19:54 +0300
Subject: [PATCH] arm64: dts: ti: j7200-main: Mark Main NAVSS as
 dma-coherent
In-Reply-To: <20210427175130.29451-1-vigneshr@ti.com>
References: <20210427175130.29451-1-vigneshr@ti.com>
Message-ID: <d36f0be0-3358-971c-e385-f920cfa333cd@gmail.com>



On 4/27/21 8:51 PM, Vignesh Raghavendra wrote:
> Traffic through main NAVSS interconnect is coherent wrt ARM caches on
> J7200 SoC.  Add missing dma-coherent property to main_navss node.
> 
> Also add dma-ranges to be consistent with mcu_navss node.

and with am65, j721e main and mcu navss...

Reviewed-by: Peter Ujfalusi <peter.ujfalusi at gmail.com>

> Fixes: d361ed88455fe ("arm64: dts: ti: Add support for J7200 SoC")
> Signed-off-by: Vignesh Raghavendra <vigneshr at ti.com>
> ---
>  arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index f86c493a44f1c..a6826f1888ef0 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -85,6 +85,8 @@ main_navss: bus at 30000000 {
>  		#size-cells = <2>;
>  		ranges = <0x00 0x30000000 0x00 0x30000000 0x00 0x0c400000>;
>  		ti,sci-dev-id = <199>;
> +		dma-coherent;
> +		dma-ranges;
>  
>  		main_navss_intr: interrupt-controller1 {
>  			compatible = "ti,sci-intr";
> 

-- 
P?ter


From martin.blumenstingl at googlemail.com  Tue Apr 27 19:31:33 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Tue, 27 Apr 2021 20:31:33 +0200
Subject: [PATCH] serial: meson: remove redundant initialization of
 variable id
In-Reply-To: <20210426101106.9122-1-colin.king@canonical.com>
References: <20210426101106.9122-1-colin.king@canonical.com>
Message-ID: <CAFBinCBh1_s7NDpOZjuO3hKcvimwiD+2X15JY3CqeDKg8wemSQ@mail.gmail.com>

On Mon, Apr 26, 2021 at 12:11 PM Colin King <colin.king at canonical.com> wrote:
>
> From: Colin Ian King <colin.king at canonical.com>
>
> The variable id being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed. Since id is just being used in a for-loop
> inside a local scope, move the declaration of id to that scope.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From martin.blumenstingl at googlemail.com  Tue Apr 27 19:34:08 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Tue, 27 Apr 2021 20:34:08 +0200
Subject: [PATCH 1/2] mmc: meson-gx: make replace WARN_ONCE with
 dev_warn_once about scatterlist offset alignment
In-Reply-To: <20210426175559.3110575-1-narmstrong@baylibre.com>
References: <20210426175559.3110575-1-narmstrong@baylibre.com>
Message-ID: <CAFBinCCN88nfSnmPoFq4H_ROWFMbq=Kcpr1W6CpNs58XeHtV2w@mail.gmail.com>

Hi Neil,

On Mon, Apr 26, 2021 at 7:58 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
>
> Some drivers like ath10k can sometimg give an sg buffer with an offset whose alignment
sometimg -> sometimes

> is not compatible with the Amlogic DMA descriptor engine requirements.
>
> Simply replace with dev_warn_once() to inform user this should be fixed to avoid
> degraded performance.
>
> This should be ultimately fixed in ath10k, but since it's only a performance issue
> the warning should be removed.
>
> Fixes: 79ed05e329c3 ("mmc: meson-gx: add support for descriptor chain mode")
> Reported-by: Christian Hewitt <christianshewitt at gmail.com>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From martin.blumenstingl at googlemail.com  Tue Apr 27 20:03:28 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Tue, 27 Apr 2021 21:03:28 +0200
Subject: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for
 Meson AO ARC rproc
In-Reply-To: <YHYGLuxIN7WMakco@builder.lan>
References: <20201230012724.1326156-1-martin.blumenstingl@googlemail.com>
 <20201230012724.1326156-4-martin.blumenstingl@googlemail.com>
 <YFLBPGNQpT9mM3AJ@builder.lan>
 <CAFBinCA92411o5+AGApr8+nkMdmzJ4ddzVY+Cb5FLBez+-92nA@mail.gmail.com>
 <YHYGLuxIN7WMakco@builder.lan>
Message-ID: <CAFBinCDCtaqZG4a5jbw64RK4mrccSJTmznTiMPpp+gJNmo2LkA@mail.gmail.com>

Hi Bjorn,

On Tue, Apr 13, 2021 at 10:59 PM Bjorn Andersson
<bjorn.andersson at linaro.org> wrote:
[...]
> Describing these kinds blocks in DT is indeed tricky, I've had
> both cases where a block maps to multiple "functions" or where they
> contain misc registers to be used in relation to some other block.
>
> The prior typically lends itself to be modelled as a "simple-mfd" and
> the latter as a "syscon".
I think here the former description matches better
each set of registers has one very specific purpose (pinctrl, GPIO,
I2C, RTC, IR receiver, ...). there's only one exception inside the
whole AO region called "PMU" (which mostly contains power management
registers and a few clock control bits)

> So perhaps you could do a simple-mfd that spans the entire block and
> then describe the remoteproc, watchdog?, pinctrl pieces as children
> under that?
I can send patches for the simple-mfd conversion (syscon won't be
involved) so Rob can also give his feedback.

in my opinion this would not change the dt-bindings for the AO ARC
remote-processor.
Please let me know if there would be any dt-bindings changes so I can
also include this when updating this series.


Best regards,
Martin


From f.fainelli at gmail.com  Tue Apr 27 20:35:28 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 27 Apr 2021 12:35:28 -0700
Subject: [PATCH v1 4/4] PCI: brcmstb: add shutdown call to driver
In-Reply-To: <20210427175140.17800-5-jim2101024@gmail.com>
References: <20210427175140.17800-1-jim2101024@gmail.com>
 <20210427175140.17800-5-jim2101024@gmail.com>
Message-ID: <3a5a67e0-4554-f581-91b2-a8098814a9e9@gmail.com>



On 4/27/2021 10:51 AM, Jim Quinlan wrote:
> The shutdown() call is similar to the remove() call except the former does
> not need to invoke pci_{stop,remove}_root_bus(), and besides, errors occur
> if it does.
> 
> Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>

Acked-by: Florian Fainelli <f.fainelli at gmail.com>
-- 
Florian


From arnd at kernel.org  Tue Apr 27 22:01:08 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 27 Apr 2021 23:01:08 +0200
Subject: [PATCH] dt-bindings: nvmem: mediatek: remove duplicate mt8192 line
Message-ID: <20210427210121.1080364-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

The same patch was accidentally merged twice, resulting in a
duplicate line for the mt8192 SoC.

Fixes: f2674c0c7488 ("dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC")
Fixes: 2a1405a14c3a ("dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
index d479ad977e24..2f2895b1f06d 100644
--- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
+++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
@@ -7,7 +7,6 @@ Required properties:
 	      "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
 	      "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
 	      "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
-	      "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
 	      "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
 	      "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
 - reg: Should contain registers location and length
-- 
2.29.2



From arnd at kernel.org  Tue Apr 27 22:15:00 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Tue, 27 Apr 2021 23:15:00 +0200
Subject: [GIT PULL 0/6] ARM SoC branches for 5.13
In-Reply-To: <CAHk-=wgDQ23kEkVVhjwcVPkQCDUVmJJdhO_HtjaRRCv_mtZgag@mail.gmail.com>
References: <CAK8P3a2RjRSjTcmwVf3VHy2CUB2HBj5AaJTx=1NSYuA_Qy4E-w@mail.gmail.com>
 <CAHk-=wgDQ23kEkVVhjwcVPkQCDUVmJJdhO_HtjaRRCv_mtZgag@mail.gmail.com>
Message-ID: <CAK8P3a23sx+M1sh2pXmb3Peuy5hV_0hy4KP7sfcXkCNXto0EMg@mail.gmail.com>

On Mon, Apr 26, 2021 at 9:41 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> On Mon, Apr 26, 2021 at 8:53 AM Arnd Bergmann <arnd at kernel.org> wrote:
> >
> > Here are six branches for the SoC tree [...]
>
> Ok, all merged. Please do check my conflict resolutions - not because
> I think there is anything wrong there, but simply because the arm side
> doesn't get the same build coverage testing when I merge.
>
> All but the two first had some fairly trivial conflicts with the other
> trees I've been merging today.

I've inspected the merges and ran the tree through my randconfig
test box for today. It seems you fixed one merge that went wrong
in linux-next, but you missed a harmless mismerge in a DT binding
documentation file. I've applied a fix to the arm/fixes branch now
and sent it to the list [1].

       Arnd

[1] https://lore.kernel.org/linux-arm-kernel/20210427210121.1080364-1-arnd at kernel.org/T/#u


From keescook at chromium.org  Tue Apr 27 23:58:23 2021
From: keescook at chromium.org (Kees Cook)
Date: Tue, 27 Apr 2021 15:58:23 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210423205159.830854-1-morbo@google.com>
References: <20210423205159.830854-1-morbo@google.com>
Message-ID: <202104271557.412DD365A@keescook>

On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> The arm64 assembler in binutils 2.32 and above generates a program
> property note in a note section, .note.gnu.property, to encode used x86
> ISAs and features. But the kernel linker script only contains a single
> NOTE segment:
> 
>   PHDRS
>   {
>     text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
>     dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
>     note    PT_NOTE    FLAGS(4);               /* PF_R */
>   }
> 
> The NOTE segment generated by the vDSO linker script is aligned to 4 bytes.
> But the .note.gnu.property section must be aligned to 8 bytes on arm64.
> 
>   $ readelf -n vdso64.so
> 
>   Displaying notes found in: .note
>     Owner                Data size      Description
>     Linux                0x00000004     Unknown note type: (0x00000000)
>      description data: 06 00 00 00
>   readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20
>   readelf: Warning:  type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8
> 
> Since the note.gnu.property section in the vDSO is not checked by the
> dynamic linker, discard the .note.gnu.property sections in the vDSO.
> 
> Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property
> sections in vDSO"), but for arm64.
> 
> Signed-off-by: Bill Wendling <morbo at google.com>

Seems good to me. If we ever need the BTI markings, etc, for the vDSO,
we can revisit it then.

Reviewed-by: Kees Cook <keescook at chromium.org>

-Kees

-- 
Kees Cook


From public_timo.s at silentcreek.de  Wed Apr 28 00:05:37 2021
From: public_timo.s at silentcreek.de (Timo Sigurdsson)
Date: Wed, 28 Apr 2021 01:05:37 +0200
Subject: [PATCH] ata: ahci_sunxi: Disable DIPM
Message-ID: <20210427230537.21423-1-public_timo.s@silentcreek.de>

DIPM is unsupported or broken on sunxi. Trying to enable the power
management policy med_power_with_dipm on an Allwinner A20 SoC based board
leads to immediate I/O errors and the attached SATA disk disappears from
the /dev filesystem. A reset (power cycle) is required to make the SATA
controller or disk work again. The A10 and A20 SoC data sheets and manuals
don't mention DIPM at all [1], so it's fair to assume that it's simply not
supported. But even if it were, it should be considered broken and best be
disabled in the ahci_sunxi driver.

Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")

[1] https://github.com/allwinner-zh/documents/tree/master/

Signed-off-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
Tested-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
---
 drivers/ata/ahci_sunxi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
index cb69b737cb49..56b695136977 100644
--- a/drivers/ata/ahci_sunxi.c
+++ b/drivers/ata/ahci_sunxi.c
@@ -200,7 +200,7 @@ static void ahci_sunxi_start_engine(struct ata_port *ap)
 }
 
 static const struct ata_port_info ahci_sunxi_port_info = {
-	.flags		= AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
+	.flags		= AHCI_FLAG_COMMON | ATA_FLAG_NCQ | ATA_FLAG_NO_DIPM,
 	.pio_mask	= ATA_PIO4,
 	.udma_mask	= ATA_UDMA6,
 	.port_ops	= &ahci_platform_ops,
-- 
2.26.2



From roman.beranek at prusa3d.cz  Wed Apr 28 01:19:46 2021
From: roman.beranek at prusa3d.cz (Roman Beranek)
Date: Wed, 28 Apr 2021 02:19:46 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
Message-ID: <20210428001946.1059426-1-roman.beranek@prusa3d.com>

More often than not, a PWM period may span nowhere near as far
as 1 jiffy, yet it still must be waited upon before the channel
is disabled.

Signed-off-by: Roman Beranek <roman.beranek at prusa3d.com>
---
 drivers/pwm/pwm-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index ce5c4fc8d..f4b991048 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -285,7 +285,7 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 	val = (duty & PWM_DTY_MASK) | PWM_PRD(period);
 	sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
 	sun4i_pwm->next_period[pwm->hwpwm] = jiffies +
-		nsecs_to_jiffies(cstate.period + 1000);
+		nsecs_to_jiffies(cstate.period) + 1;
 
 	if (state->polarity != PWM_POLARITY_NORMAL)
 		ctrl &= ~BIT_CH(PWM_ACT_STATE, pwm->hwpwm);
-- 
2.31.1



From sboyd at kernel.org  Wed Apr 28 01:38:04 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Tue, 27 Apr 2021 17:38:04 -0700
Subject: [PATCH V2 0/4] dt-bindings: soc/arm: Convert pending ti,
 sci* bindings to json format
In-Reply-To: <20210426155457.21221-1-nm@ti.com>
References: <20210426155457.21221-1-nm@ti.com>
Message-ID: <161957028464.177949.14790878722521589025@swboyd.mtv.corp.google.com>

Quoting Nishanth Menon (2021-04-26 08:54:53)
> Hi,
> 
> V2 of the series posted in [1] to convert the remaining ti,sci bindings
> to json schema format. V2 is mostly review comments being incorporated -
> details in each of the patches and in applicable patches, I have picked
> up Rob's and Tero's reviewed bys.
> 
> There are also dts fixups that this series exposes, which is good, but
> I chose to hold them back for now pending binding review at least. The
> complete series is available in [2] if folks are curious - to be posted
> once v5.13-rc1 is available for fixes.

Is Rob going to pick this up? If so

Acked-by: Stephen Boyd <sboyd at kernel.org>


From leo.yan at linaro.org  Wed Apr 28 02:36:59 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 28 Apr 2021 09:36:59 +0800
Subject: [RFC PATCH] coresight: etm-perf: Correct buffer syncing for snapshot
Message-ID: <20210428013659.324230-1-leo.yan@linaro.org>

The perf tool records the Arm CoreSight trace data with snapshot mode
with the option '-S', when receiving USR2 signal, it is observed the
captured trace data size is very varied: from several MBs to ~20MBs.
This can be reproduced with the command:

  perf record -e cs_etm// -S \
	-- dd if=/dev/zero of=/dev/null > /dev/null 2>&1 &
  PERFPID=$!
  sleep 1
  kill -USR2 $PERFPID

It's different for only specifying option '-S' than options '-a -S'.  If
without option '-a', perf tool creates separate AUX buffers for every
CPU, but the tracer will be enabled only when the profiled program is
scheduled onto the corresponding CPU, this might lead to record very
old trace data when snapshot.

Let's see below diagram:
                                                            snapshot
  CPU0: ______###P1###__________________________________________|
  CPU1: __________________________###P3###____________###P5###__|
  CPU2: ____________________________________###P4###____________|
  CPU3: ________________###P2###________________________________V

In this diagram, the program runs for 5 periods (from P1 to P5), these 5
periods show the task run on different CPUs, e.g. during P1 period the
program runs on CPU0, and during P2 period the program is migrated to
CPU1, and so on.  At the end of P1 period when the program is switched
out from CPU0, the ETR trace data is saved into AUX trace buffer, this
AUX buffer is a dedicated buffer for CPU0's tracer.  With the same
logic, P2's trace data is saved into CPU3's tracer buffer, P4's trace
data is saved into CPU2's buffer, P3 and P5's trace data is saved into
CPU1's.  Therefore, when snapshot, it saves the trace data from all AUX
ring buffers (in this case, it have total 4 AUX ring buffers) into perf
data file.

This is why we can see varied trace data size, it's quite dependent on
the task scheduling on CPUs, if the task is spinned to only one CPU and
without scheduling out, it will only record trace data from only one
AUX trace buffer.  If the task is frequently scheduled in and out, then
it gives more chance to fill trace data into the AUX buffer.

In this example, it also causes the discontinuous trace data.  If P3's
trace data is lost after P5's trace data overwrites the AUX trace data,
thus perf tool fails to record continuous trace data if only have
trace data for P1/P2/P4/P5.

For snapshot mode, usually the user only wants to capture the trace data
for the specific time point and prior to the that point the tracer
should work with free run mode.  This means it's not necessary to
capture trace data for task's scheduling in and out until the perf tool
explicitly disables tracers for snapshot.  This can be fulfilled by
checking the variable "event->ctx->is_active", when the task is
scheduled out this variable is set to zero, and when snapshot this
variable is still non-zero value.  So the driver can only record trace
data only when "event->ctx->is_active" is non-zero.

After applying this change, the perf tool can record the consistent
trace data size for snapshot.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 .../hwtracing/coresight/coresight-etm-perf.c  | 21 ++++++++++++++++---
 .../hwtracing/coresight/coresight-etm-perf.h  |  2 ++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 0f603b4094f2..5fceefe9513c 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -245,6 +245,7 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
 	if (!event_data)
 		return NULL;
 	INIT_WORK(&event_data->work, free_event_data);
+	event_data->overwrite = overwrite;
 
 	/* First get the selected sink from user space. */
 	if (event->attr.config2) {
@@ -424,9 +425,23 @@ static void etm_event_stop(struct perf_event *event, int mode)
 		if (!sink_ops(sink)->update_buffer)
 			return;
 
-		size = sink_ops(sink)->update_buffer(sink, handle,
-					      event_data->snk_config);
-		perf_aux_output_end(handle, size);
+		/*
+		 * In the snapshot mode, here should avoid to record trace data
+		 * when the profiled program is scheduled out and only capture
+		 * trace data when the perf tool receives USR2 signal.
+		 *
+		 * This is distinguished by variable "event->ctx->is_active",
+		 * its value is zero for profiled task scheduling out, and it
+		 * is a non-zero value when perf tool invokes ioctl
+		 * PERF_EVENT_IOC_DISABLE.
+		 */
+		if (!event_data->overwrite || event->ctx->is_active) {
+			size = sink_ops(sink)->update_buffer(sink, handle,
+						      event_data->snk_config);
+			perf_aux_output_end(handle, size);
+		} else {
+			perf_aux_output_end(handle, 0);
+		}
 	}
 
 	/* Disabling the path make its elements available to other sessions */
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
index 3e4f2ad5e193..2cc3af05495f 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.h
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -49,12 +49,14 @@ struct etm_filters {
  * @mask:		Hold the CPU(s) this event was set for.
  * @snk_config:		The sink configuration.
  * @path:		An array of path, each slot for one CPU.
+ * @overwrite:		Flag for snapshot mode.
  */
 struct etm_event_data {
 	struct work_struct work;
 	cpumask_t mask;
 	void *snk_config;
 	struct list_head * __percpu *path;
+	bool overwrite;
 };
 
 #if IS_ENABLED(CONFIG_CORESIGHT)
-- 
2.25.1



From wangqing at vivo.com  Wed Apr 28 02:51:58 2021
From: wangqing at vivo.com (=?UTF-8?B?546L5pOO?=)
Date: Wed, 28 Apr 2021 09:51:58 +0800 (GMT+08:00)
Subject: =?UTF-8?B?UmU6W1BBVENIIFY5IDAvMl0gd2F0Y2hkb2c6IG10azogc3VwcG9ydCBwcmUtdGltZW91dCB3aGVuIHRoZSBiYXJrIGlycSBpcyBhdmFpbGFibGU=?=
In-Reply-To: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
Message-ID: <ADUA9AALDva0XEeX2p71l4rW.3.1619574718914.Hmail.wangqing@vivo.com>


>Use the bark interrupt as the pretimeout notifier if available.
>The pretimeout notification shall occur at timeout-sec/2.
>
>Wang Qing (2):
>  watchdog: mtk: support pre-timeout when the bark irq is available
>  doc: mtk-wdt: support pre-timeout when the bark irq is available
>
> .../devicetree/bindings/watchdog/mtk-wdt.txt       |  5 ++
> drivers/watchdog/mtk_wdt.c                         | 77 ++++++++++++++++++++--
> 2 files changed, 77 insertions(+), 5 deletions(-)
>
>-- 
>2.7.4
>

Hi Guenter:
Please help review this version, if there is no problem, 
can you pick up to the next branch?

Thanks,
Qing


From yongqiang.niu at mediatek.com  Wed Apr 28 03:08:50 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Wed, 28 Apr 2021 10:08:50 +0800
Subject: [PATCH v1] MTK_MMSYS tristrate support
Message-ID: <1619575731-23388-1-git-send-email-yongqiang.niu@mediatek.com>

MTK_MMSYS tristrate support

Chun-Hung Wu (1):
  [ALPS05103552] soc: mediatek: MTK_MMSYS tristrate support

 drivers/soc/mediatek/Kconfig     | 2 +-
 drivers/soc/mediatek/mtk-mmsys.c | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

-- 
1.8.1.1.dirty

From yongqiang.niu at mediatek.com  Wed Apr 28 03:08:51 2021
From: yongqiang.niu at mediatek.com (Yongqiang Niu)
Date: Wed, 28 Apr 2021 10:08:51 +0800
Subject: [PATCH v1] soc: mediatek: MTK_MMSYS tristrate support
In-Reply-To: <1619575731-23388-1-git-send-email-yongqiang.niu@mediatek.com>
References: <1619575731-23388-1-git-send-email-yongqiang.niu@mediatek.com>
Message-ID: <1619575731-23388-2-git-send-email-yongqiang.niu@mediatek.com>

From: Chun-Hung Wu <chun-hung.wu at mediatek.com>

MTK_MMSYS driver tristrate support.

Signed-off-by: Chun-Hung Wu <chun-hung.wu at mediatek.com>
Signed-off-by: Yongqiang Niu <yongqiang.niu at mediatek.com>
---
 drivers/soc/mediatek/Kconfig     | 2 +-
 drivers/soc/mediatek/mtk-mmsys.c | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc0..1437ed0 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -66,7 +66,7 @@ config MTK_SCPSYS_PM_DOMAINS
 	  tasks in the system.
 
 config MTK_MMSYS
-	bool "MediaTek MMSYS Support"
+	tristate "MediaTek MMSYS Support"
 	default ARCH_MEDIATEK
 	depends on HAS_IOMEM
 	help
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 18f9397..55a104e 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -6,6 +6,7 @@
 
 #include <linux/device.h>
 #include <linux/io.h>
+#include <linux/module.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/soc/mediatek/mtk-mmsys.h>
@@ -370,4 +371,8 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
 	.probe = mtk_mmsys_probe,
 };
 
-builtin_platform_driver(mtk_mmsys_drv);
+module_platform_driver(mtk_mmsys_drv);
+
+MODULE_AUTHOR("Yongqiang Niu, MediaTek");
+MODULE_DESCRIPTION("MediaTek MMSYS Driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.1.1.dirty

From leo.yan at linaro.org  Wed Apr 28 03:34:20 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Wed, 28 Apr 2021 10:34:20 +0800
Subject: [PATCH 1/4] coresight: tmc-etr: Advance buffer pointer in sync
 buffer.
In-Reply-To: <f957c2d3-9265-1e84-49d3-dc38147816ca@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <20210421120413.3110775-2-daniel.kiss@arm.com>
 <bd9de3ab-14f7-2659-0dc8-619bca0f52d7@arm.com>
 <20210427034531.GA328795@leoy-ThinkPad-X240s>
 <f957c2d3-9265-1e84-49d3-dc38147816ca@arm.com>
Message-ID: <20210428023420.GB324438@leoy-ThinkPad-X240s>

On Tue, Apr 27, 2021 at 11:00:51AM +0100, Suzuki Kuruppassery Poulose wrote:

[...]

> To make it more clear:
> 
>     CPU0: AUX RB (perf_output_handle_0) -> etr_perf0 ->  +---------+
>     CPU1: AUX RB (perf_output_handle_1) -> etr_perf1 ->  |etr_buf0 |
>     CPU2: AUX RB (perf_output_handle_2) -> etr_perf2 ->  |         |
>     CPU3: AUX RB (perf_output_handle_3) -> etr_perf3 ->  +---------+

Thanks for the clarification.

> > Simply to say, there have two layers for controlling ring buffer, one
> > layer is for perf AUX ring buffer, it mainly uses the structure
> > perf_output_handle to manage the ring buffer.  And in the ETR driver,
> > it uses structure etr_perf to manage the header pointer for copying
> > data into ETR buffer (tagged as "etr_buf").
> > 
> > ETR buffer is the single one, but the structures "perf_output_handle"
> > and "etr_perf" are per CPU.  We have multiple copies for the headers and
> 
> minor Correction, they are "per-event" to be precise. And there are events
> per-CPU in a system wide mode or task mode (but not per-thread mode). So,
> you are correct
> 
> > tails to manage a single buffer, but the problem is these multiple
> > copies have not been synced with each other.
> > 
> > > 2) Even more problematic is where we copy the AUX buffer content to.
> > > As mentioned above, we don't know which handle is going to be the last
> > > one to consume and we have a "etr_perf->head" that came from one of the
> > > handles and the "pages" that came from the first handle which created a
> > > etr_perf buffer. In sync_perf_buffer() we copy the hardware buffers to
> > > the "pages" (say of handle_0) with "etr_perf->head" (which could be from
> > > any other handle, say handle_2) and then we could return the number of bytes
> > > copied, which then is used to update the last handle (could be say
> > > handle_3), where there is no actual data copied.
> 
> This is not valid and am relieved that the driver is correct. The assumption
> that there is only one etr_perf per ETR is incorrect as
> pictured above.

Yeah, etr_perf is per event wise.

> > > To fix all of these issues, we must
> > > 1) Stop using etr_perf->head, and instead use the handle->head where we are
> > > called update_buffer on.
> > > 
> > > 2) Keep track of the "pages" that belong to a given "handle" and then use
> > > those pages to copy the data to the current handle we are called to update
> > > the buffer on.
> > 
> > The "pages" are only allocated once, even they are attached to multiple
> > handles.  I think the right way is to use the single structure
> 
> I assume you mean the pages in the etr_buf and not etr_perf right ?

Yes.

> > "etr_perf" and single "perf_output_handle" to manage the "pages", IOW,
> > if there have single buffer, then we just use one copy of header and
> > tail to manage it.
> 
> I think this is not needed and the way we do things are fine and the patch
> as such looks correct to me.
> 
> The perf_output_handle is per-event and nothing that we can combine with.
> etr_perf captures what the "ouput_handle" stands for and is something
> necessary for syncing the buffer.

Correct myself for one thing.  At beginning I wrongly understood the AUX
buffer is only allocated once but mapped into VMA for multiple times for all
events, but this is wrong.  In the file kernel/events/ring_buffer.c,
function rb_alloc_aux() clearly shows the AUX ring buffer is allocated
for every event.  So the buffer management is as below:

        +---------+
  CPU0: | AUX RB0 | (perf_output_handle_0) -> etr_perf0 ->  +---------+
        +---------+                                         |         |
  CPU1: | AUX RB1 | (perf_output_handle_1) -> etr_perf1 ->  |etr_buf0 |
        +---------+                                         |         |
  CPU2: | AUX RB2 | (perf_output_handle_2) -> etr_perf2 ->  |         |
        +---------+                                         |         |
  CPU3: | AUX RB3 | (perf_output_handle_3) -> etr_perf3 ->  +---------+
        +---------+                                              |
             ^---------------------------------------------------/
                           tmc_etr_sync_perf_buffer()

> Now coming back to this patch, I understand that the sync_perf could be
> called with the polling patches multiple times. But don't we do a
> perf_output_handle_end() each of the time we wake up ? (I haven't looked
> at the later patches yet).

Here "we" means the polling's work (or we can say the polling thread).
>From my understanding for the patch of implementation the polling, it
adds the delayed work on work queue periodically, every time the work
resets the ETR and sync the trace data from etr_buf0 to AUX ring
buffer.  The target AUX ring buffer is fixed, it should be the first
registered AUX ring buffer when launch the session.

So the flow is:

  etr_perf_polling_worker()
    sink_ops(sink)->update_buffer()
      tmc_etr_sync_perf_buffer() -> Update 'etr_perf->head'
    tmc_etr_reset
    perf_aux_output_end(handle, size)  -> Update AUX ring buffer head
                                          and notify the perf tool
    perf_aux_output_begin()            -> Prepare for next recording

> I would expect:
> 
>   perf_aux_output_begin() -> update the etr_perf-> head
> 
>   when we sync the buffer, we do :
> 
>  Poll-> sync_buffer-> perf_aux_output_end() and perf_aux_output_begin() ->
> update etr_perf->head.

I understand your meaning, essentially "etr_perf->head" should keep
up the latest value of the AUX ring buffer's head.  So I think below
change is what you are proposing:

diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 8e8596dc75fa..daeeda00236e 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -1567,6 +1567,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
 	/* Insert barrier packets at the beginning, if there was an overflow */
 	if (lost)
 		tmc_etr_buf_insert_barrier_packet(etr_buf, offset);
+	etr_perf->head = handle->head;
 	tmc_etr_sync_perf_buffer(etr_perf, offset, size);
 
 	/*

Thanks,
Leo


From wanjiabing at vivo.com  Wed Apr 28 04:03:24 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Wed, 28 Apr 2021 11:03:24 +0800
Subject: [PATCH] firmware: psci: Remove unneeded semicolon
Message-ID: <20210428030324.37998-1-wanjiabing@vivo.com>

Fix the following coccicheck warning:

./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 drivers/firmware/psci/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 64344e84bd63..6e7bac61ba93 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -138,7 +138,7 @@ static int psci_to_linux_errno(int errno)
 		return -EINVAL;
 	case PSCI_RET_DENIED:
 		return -EPERM;
-	};
+	}
 
 	return -EINVAL;
 }
-- 
2.25.1



From Jaxson.Han at arm.com  Wed Apr 28 04:23:18 2021
From: Jaxson.Han at arm.com (Jaxson Han)
Date: Wed, 28 Apr 2021 03:23:18 +0000
Subject: [boot-wrapper PATCH 1/5] Decouple V2M_SYS config by auto-detect
 dtb node
In-Reply-To: <20210426123016.76947383@slackpad.fritz.box>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-2-jaxson.han@arm.com>
 <20210426123016.76947383@slackpad.fritz.box>
Message-ID: <AS8PR08MB61171B1D7D7954EE1609BA4F83409@AS8PR08MB6117.eurprd08.prod.outlook.com>

Hi Andre,

> -----Original Message-----
> From: Andre Przywara <andre.przywara at arm.com>
> Sent: Monday, April 26, 2021 7:30 PM
> To: Jaxson Han <Jaxson.Han at arm.com>
> Cc: Mark Rutland <Mark.Rutland at arm.com>; linux-arm-
> kernel at lists.infradead.org; Wei Chen <Wei.Chen at arm.com>
> Subject: Re: [boot-wrapper PATCH 1/5] Decouple V2M_SYS config by auto-
> detect dtb node
> 
> On Tue, 20 Apr 2021 15:24:34 +0800
> Jaxson Han <jaxson.han at arm.com> wrote:
> 
> Hi,
> 
> > An auto-detect switch is added to make it an option to enable/disable
> > 'arm,vexpress-sysreg', because not all platforms support this feature.
> 
> The change itself is fine, only has the side effect of now printing an message
> about the missing node:
> No matching devices found at ./findbase.pl line 37.
> 
> I will have a look if we can avoid this, or we drop this message in findbase.pl
> at all.

Thanks, if you have any suggestions, please let me know:)

> 
> But for the sake of this patch:
> 
> Reviewed-by: Andre Przywara <andre.przywara at arm.com>
> 
> Cheers,
> Andre

Thanks!
Jaxson

> 
> > Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> > ---
> >  Makefile.am | 2 +-
> >  platform.c  | 4 ++++
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile.am b/Makefile.am index af694b7..e131207 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -19,7 +19,7 @@ NR_CPUS         := $(shell echo $(CPU_IDS) | tr ',' ' ' | wc
> -w)
> >  DEFINES		= -DCNTFRQ=$(CNTFRQ)
> >  DEFINES		+= -DCPU_IDS=$(CPU_IDS)
> >  DEFINES		+= -DNR_CPUS=$(NR_CPUS)
> > -DEFINES		+= -DSYSREGS_BASE=$(SYSREGS_BASE)
> > +DEFINES		+= $(if $(SYSREGS_BASE), -
> DSYSREGS_BASE=$(SYSREGS_BASE), )
> >  DEFINES		+= -DUART_BASE=$(UART_BASE)
> >  DEFINES		+= -DSTACK_SIZE=256
> >
> > diff --git a/platform.c b/platform.c
> > index a528a55..d11f568 100644
> > --- a/platform.c
> > +++ b/platform.c
> > @@ -23,10 +23,12 @@
> >
> >  #define PL011(reg)	((void *)UART_BASE + PL011_##reg)
> >
> > +#ifdef SYSREGS_BASE
> >  #define V2M_SYS_CFGDATA		0xa0
> >  #define V2M_SYS_CFGCTRL		0xa4
> >
> >  #define V2M_SYS(reg)	((void *)SYSREGS_BASE + V2M_SYS_##reg)
> > +#endif
> >
> >  static void print_string(const char *str)  { @@ -59,6 +61,7 @@ void
> > init_platform(void)
> >
> >  	print_string("Boot-wrapper v0.2\r\n\r\n");
> >
> > +#ifdef SYSREGS_BASE
> >  	/*
> >  	 * CLCD output site MB
> >  	 */
> > @@ -66,4 +69,5 @@ void init_platform(void)
> >  	/* START | WRITE | MUXFPGA | SITE_MB */
> >  	raw_writel((1 << 31) | (1 << 30) | (7 << 20) | (0 << 16),
> >  				V2M_SYS(CFGCTRL));
> > +#endif
> >  }



From Jaxson.Han at arm.com  Wed Apr 28 04:28:57 2021
From: Jaxson.Han at arm.com (Jaxson Han)
Date: Wed, 28 Apr 2021 03:28:57 +0000
Subject: [boot-wrapper PATCH 2/5] aarch64: Rename labels and prepare for
 lower EL booting
In-Reply-To: <20210426124055.20253825@slackpad.fritz.box>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-3-jaxson.han@arm.com>
 <20210426124055.20253825@slackpad.fritz.box>
Message-ID: <AS8PR08MB61176B35E989EAABA676D41283409@AS8PR08MB6117.eurprd08.prod.outlook.com>

Hi Andre,

> -----Original Message-----
> From: Andre Przywara <andre.przywara at arm.com>
> Sent: Monday, April 26, 2021 7:41 PM
> To: Jaxson Han <Jaxson.Han at arm.com>
> Cc: Mark Rutland <Mark.Rutland at arm.com>; linux-arm-
> kernel at lists.infradead.org; Wei Chen <Wei.Chen at arm.com>
> Subject: Re: [boot-wrapper PATCH 2/5] aarch64: Rename labels and prepare
> for lower EL booting
> 
> On Tue, 20 Apr 2021 15:24:35 +0800
> Jaxson Han <jaxson.han at arm.com> wrote:
> 
> > Prepare for booting from lower EL. Rename *_el3 relavant labels with
> > *_el_max and *_no_el3 with *_keep_el. Since the original _no_el3 means
> > "We neither do init sequence at this highest EL nor drop to lower EL
> > when entering to kernel", we rename it with _keep_el to make it more
> > clear for lower EL initialisation.
> 
> So this cleanup and rename is fine, however the patch is hard to read since
> various other changes are mixed in.
> Can you try to isolate this more? If this patch would just rename the labels,
> and wouldn't carry any functional change, it might be easier to reason about.
> At least the SPSR value change should be separate.

Yes, I will.

> 
> Some more below:
> 
> > Also in jump_kernel, skip sctlr_el2 initialisation when CurrentEL < EL2.
> >
> > Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> > ---
> >  arch/aarch64/boot.S            | 54 +++++++++++++++++++++++++---------
> >  arch/aarch64/include/asm/cpu.h |  3 ++
> >  arch/aarch64/psci.S            | 13 ++++----
> >  arch/aarch64/spin.S            |  8 ++---
> >  4 files changed, 54 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S index
> > e47cf59..f7dbf3f 100644
> > --- a/arch/aarch64/boot.S
> > +++ b/arch/aarch64/boot.S
> > @@ -12,7 +12,7 @@
> >  	.section .init
> >
> >  	.globl	_start
> > -	.globl jump_kernel
> > +	.globl	jump_kernel
> >
> >  _start:
> >  	cpuid	x0, x1
> > @@ -22,20 +22,30 @@ _start:
> >  	bl	setup_stack
> >
> >  	/*
> > -	 * EL3 initialisation
> > +	 * Boot sequence
> > +	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
> > +	 *   lower EL before entering the kernel.
> > +	 * Else, no initialisation and keep the current EL before
> > +	 *   entering the kernel.
> >  	 */
> >  	mrs	x0, CurrentEL
> >  	cmp	x0, #CURRENTEL_EL3
> > -	b.eq	1f
> > +	beq	el3_init
> >
> > +	/*
> > +	 * We stay in the current EL for entering the kernel
> > +	 */
> >  	mov	w0, #1
> > -	ldr	x1, =flag_no_el3
> > +	ldr	x1, =flag_keep_el
> >  	str	w0, [x1]
> >
> > -	bl	setup_stack
> 
> I think this is indeed redundant, but can you either make this a separate
> patch or at least mention it in the commit message?

Yes, I will make this separate.

> 
> > -	b	start_no_el3
> > +	b	start_keep_el
> >
> > -1:	mov	x0, #0x30			// RES1
> > +	/*
> > +	 * EL3 initialisation
> > +	 */
> > +el3_init:
> > +	mov	x0, #0x30			// RES1
> >  	orr	x0, x0, #(1 << 0)		// Non-secure EL1
> >  	orr	x0, x0, #(1 << 8)		// HVC enable
> >
> > @@ -93,13 +103,23 @@ _start:
> >  	mov	x0, #ZCR_EL3_LEN_MASK		// SVE: Enable full
> vector len
> >  	msr	ZCR_EL3, x0			// for EL2.
> >
> > -1:
> > +	/*
> > +	 * Save SPSR_KERNEL into spsr_to_elx.
> > +	 * The jump_kernel will load spsr_to_elx into spsr_el3
> > +	 */
> > +1:	mov	w0, #SPSR_KERNEL
> > +	ldr	x1, =spsr_to_elx
> > +	str	w0, [x1]
> > +	b	el_max_init
> 
> This (and the other SPSR related changes below) should be in a separate
> patch.

Yes, I will

> 
> > +
> > +el_max_init:
> >  	ldr	x0, =CNTFRQ
> >  	msr	cntfrq_el0, x0
> > +	isb
> 
> Why this isb here? I don't see that we would require this?

No need here. I'll remove it.

> 
> >  	bl	gic_secure_init
> >
> > -	b	start_el3
> > +	b	start_el_max
> >
> >  err_invalid_id:
> >  	b	.
> > @@ -119,14 +139,18 @@ jump_kernel:
> >  	ldr	x0, =SCTLR_EL1_RESET
> >  	msr	sctlr_el1, x0
> >
> > +	mrs	x0, CurrentEL
> > +	cmp	x0, #CURRENTEL_EL2
> > +	b.lt	1f
> > +
> 
> This is also a change which might be separate.

Yes

Thanks,
Jaxson

> 
> Cheers,
> Andre
> 
> 
> >  	ldr	x0, =SCTLR_EL2_RESET
> >  	msr	sctlr_el2, x0
> >
> > -	cpuid	x0, x1
> > +1:	cpuid	x0, x1
> >  	bl	find_logical_id
> >  	bl	setup_stack		// Reset stack pointer
> >
> > -	ldr	w0, flag_no_el3
> > +	ldr	w0, flag_keep_el
> >  	cmp	w0, #0			// Prepare Z flag
> >
> >  	mov	x0, x20
> > @@ -135,9 +159,9 @@ jump_kernel:
> >  	mov	x3, x23
> >
> >  	b.eq	1f
> > -	br	x19			// No EL3
> > +	br	x19			// Keep current EL
> >
> > -1:	mov	x4, #SPSR_KERNEL
> > +1:	ldr	w4, spsr_to_elx
> >
> >  	/*
> >  	 * If bit 0 of the kernel address is set, we're entering in AArch32
> > @@ -153,5 +177,7 @@ jump_kernel:
> >
> >  	.data
> >  	.align 3
> > -flag_no_el3:
> > +flag_keep_el:
> > +	.long 0
> > +spsr_to_elx:
> >  	.long 0
> > diff --git a/arch/aarch64/include/asm/cpu.h
> > b/arch/aarch64/include/asm/cpu.h index ccb5397..2b3a0a4 100644
> > --- a/arch/aarch64/include/asm/cpu.h
> > +++ b/arch/aarch64/include/asm/cpu.h
> > @@ -11,6 +11,7 @@
> >
> >  #define MPIDR_ID_BITS		0xff00ffffff
> >
> > +#define CURRENTEL_EL2		(2 << 2)
> >  #define CURRENTEL_EL3		(3 << 2)
> >
> >  /*
> > @@ -24,6 +25,7 @@
> >  #define SPSR_I			(1 << 7)	/* IRQ masked */
> >  #define SPSR_F			(1 << 6)	/* FIQ masked */
> >  #define SPSR_T			(1 << 5)	/* Thumb */
> > +#define SPSR_EL1H		(5 << 0)	/* EL1 Handler mode */
> >  #define SPSR_EL2H		(9 << 0)	/* EL2 Handler mode */
> >  #define SPSR_HYP		(0x1a << 0)	/* M[3:0] = hyp, M[4] =
> AArch32 */
> >
> > @@ -42,6 +44,7 @@
> >  #else
> >  #define SCTLR_EL1_RESET		SCTLR_EL1_RES1
> >  #define SPSR_KERNEL		(SPSR_A | SPSR_D | SPSR_I | SPSR_F |
> SPSR_EL2H)
> > +#define SPSR_KERNEL_EL1		(SPSR_A | SPSR_D | SPSR_I | SPSR_F |
> SPSR_EL1H)
> >  #endif
> >
> >  #ifndef __ASSEMBLY__
> > diff --git a/arch/aarch64/psci.S b/arch/aarch64/psci.S index
> > 01ebe7d..ae02fd6 100644
> > --- a/arch/aarch64/psci.S
> > +++ b/arch/aarch64/psci.S
> > @@ -45,8 +45,8 @@ vector:
> >
> >  	.text
> >
> > -	.globl start_no_el3
> > -	.globl start_el3
> > +	.globl start_keep_el
> > +	.globl start_el_max
> >
> >  err_exception:
> >  	b err_exception
> > @@ -101,7 +101,7 @@ smc_exit:
> >  	eret
> >
> >
> > -start_el3:
> > +start_el_max:
> >  	ldr	x0, =vector
> >  	bl	setup_vector
> >
> > @@ -111,10 +111,11 @@ start_el3:
> >  	b	psci_first_spin
> >
> >  /*
> > - * This PSCI implementation requires EL3. Without EL3 we'll only boot
> > the
> > - * primary cpu, all others will be trapped in an infinite loop.
> > + * This PSCI implementation requires the highest EL(EL3 or Armv8-R EL2).
> > + * Without the highest EL, we'll only boot the primary cpu, all
> > + others
> > + * will be trapped in an infinite loop.
> >   */
> > -start_no_el3:
> > +start_keep_el:
> >  	cpuid	x0, x1
> >  	bl	find_logical_id
> >  	cbz	x0, psci_first_spin
> > diff --git a/arch/aarch64/spin.S b/arch/aarch64/spin.S index
> > 72603cf..533177c 100644
> > --- a/arch/aarch64/spin.S
> > +++ b/arch/aarch64/spin.S
> > @@ -11,11 +11,11 @@
> >
> >  	.text
> >
> > -	.globl start_no_el3
> > -	.globl start_el3
> > +	.globl start_keep_el
> > +	.globl start_el_max
> >
> > -start_el3:
> > -start_no_el3:
> > +start_el_max:
> > +start_keep_el:
> >  	cpuid	x0, x1
> >  	bl	find_logical_id
> >



From Jaxson.Han at arm.com  Wed Apr 28 04:30:36 2021
From: Jaxson.Han at arm.com (Jaxson Han)
Date: Wed, 28 Apr 2021 03:30:36 +0000
Subject: [boot-wrapper PATCH 3/5] gic-v3: Prepare for gicv3 with EL2
In-Reply-To: <20210426124818.28a57afa@slackpad.fritz.box>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-4-jaxson.han@arm.com>
 <20210426124818.28a57afa@slackpad.fritz.box>
Message-ID: <AS8PR08MB6117F82176AF738DCC74F38683409@AS8PR08MB6117.eurprd08.prod.outlook.com>

Hi Andre,

> -----Original Message-----
> From: Andre Przywara <andre.przywara at arm.com>
> Sent: Monday, April 26, 2021 7:48 PM
> To: Jaxson Han <Jaxson.Han at arm.com>
> Cc: Mark Rutland <Mark.Rutland at arm.com>; linux-arm-
> kernel at lists.infradead.org; Wei Chen <Wei.Chen at arm.com>
> Subject: Re: [boot-wrapper PATCH 3/5] gic-v3: Prepare for gicv3 with EL2
> 
> On Tue, 20 Apr 2021 15:24:36 +0800
> Jaxson Han <jaxson.han at arm.com> wrote:
> 
> > This is a preparation for allowing boot-wrapper configuring the gicv3
> > with EL2.
> 
> The GIC is always confusing, so can you please give some more background
> here? The introduction of ICC_SRE_EL2 looks straight-forward enough, but
> the change to the ICC_CTLR_RESET register deserves some comments, I guess.

Right, I will put more details here.

Thanks,
Jaxson

> 
> Cheers,
> Andre
> 
> > Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> > ---
> >  arch/aarch32/include/asm/gic-v3.h |  7 ++++++
> > arch/aarch64/include/asm/gic-v3.h | 38 ++++++++++++++++++++++++++++-
> --
> >  gic-v3.c                          |  2 +-
> >  3 files changed, 43 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/aarch32/include/asm/gic-v3.h
> > b/arch/aarch32/include/asm/gic-v3.h
> > index ec9a327..86abe09 100644
> > --- a/arch/aarch32/include/asm/gic-v3.h
> > +++ b/arch/aarch32/include/asm/gic-v3.h
> > @@ -9,6 +9,8 @@
> >  #ifndef __ASM_AARCH32_GICV3_H
> >  #define __ASM_AARCH32_GICV3_H
> >
> > +#define ICC_CTLR_RESET	(0UL)
> > +
> >  static inline uint32_t gic_read_icc_sre(void)  {
> >  	uint32_t val;
> > @@ -26,4 +28,9 @@ static inline void gic_write_icc_ctlr(uint32_t val)
> >  	asm volatile ("mcr p15, 6, %0, c12, c12, 4" : : "r" (val));  }
> >
> > +static inline void gic_init_icc_ctlr() {
> > +	gic_write_icc_ctlr(ICC_CTLR_RESET);
> > +}
> > +
> >  #endif
> > diff --git a/arch/aarch64/include/asm/gic-v3.h
> > b/arch/aarch64/include/asm/gic-v3.h
> > index e743c02..b3dfbd3 100644
> > --- a/arch/aarch64/include/asm/gic-v3.h
> > +++ b/arch/aarch64/include/asm/gic-v3.h
> > @@ -15,21 +15,53 @@
> >  #define ICC_CTLR_EL3	"S3_6_C12_C12_4"
> >  #define ICC_PMR_EL1	"S3_0_C4_C6_0"
> >
> > +#define ICC_CTLR_EL3_RESET	(0UL)
> > +#define ICC_CTLR_EL1_RESET	(0UL)
> > +
> > +static inline uint32_t current_el(void) {
> > +	uint32_t val;
> > +
> > +	asm volatile ("mrs %0, CurrentEL" : "=r" (val));
> > +	return val;
> > +}
> > +
> >  static inline uint32_t gic_read_icc_sre(void)  {
> >  	uint32_t val;
> > -	asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
> > +
> > +	if(current_el() == CURRENTEL_EL3)
> > +		asm volatile ("mrs %0, " ICC_SRE_EL3 : "=r" (val));
> > +	else
> > +		asm volatile ("mrs %0, " ICC_SRE_EL2 : "=r" (val));
> > +
> >  	return val;
> >  }
> >
> >  static inline void gic_write_icc_sre(uint32_t val)  {
> > -	asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
> > +	if(current_el() == CURRENTEL_EL3)
> > +		asm volatile ("msr " ICC_SRE_EL3 ", %0" : : "r" (val));
> > +	else
> > +		asm volatile ("msr " ICC_SRE_EL2 ", %0" : : "r" (val));
> >  }
> >
> > -static inline void gic_write_icc_ctlr(uint32_t val)
> > +static inline void gic_write_icc_ctlr_el3(uint32_t val)
> >  {
> >  	asm volatile ("msr " ICC_CTLR_EL3 ", %0" : : "r" (val));  }
> >
> > +static inline void gic_write_icc_ctlr_el1(uint32_t val) {
> > +	asm volatile ("msr " ICC_CTLR_EL1 ", %0" : : "r" (val)); }
> > +
> > +static inline void gic_init_icc_ctlr() {
> > +	if(current_el() == CURRENTEL_EL3)
> > +		gic_write_icc_ctlr_el3(ICC_CTLR_EL3_RESET);
> > +	else
> > +		gic_write_icc_ctlr_el1(ICC_CTLR_EL1_RESET);
> > +}
> > +
> >  #endif
> > diff --git a/gic-v3.c b/gic-v3.c
> > index ae2d2bc..4850572 100644
> > --- a/gic-v3.c
> > +++ b/gic-v3.c
> > @@ -121,6 +121,6 @@ void gic_secure_init(void)
> >  	gic_write_icc_sre(sre);
> >  	isb();
> >
> > -	gic_write_icc_ctlr(0);
> > +	gic_init_icc_ctlr();
> >  	isb();
> >  }



From Jaxson.Han at arm.com  Wed Apr 28 04:44:22 2021
From: Jaxson.Han at arm.com (Jaxson Han)
Date: Wed, 28 Apr 2021 03:44:22 +0000
Subject: [boot-wrapper PATCH 5/5] aarch64: Introduce EL2 boot code for
 Armv8-R AArch64
In-Reply-To: <20210426133546.65ee1ad6@slackpad.fritz.box>
References: <20210420072438.183086-1-jaxson.han@arm.com>
 <20210420072438.183086-6-jaxson.han@arm.com>
 <20210426133546.65ee1ad6@slackpad.fritz.box>
Message-ID: <AS8PR08MB61175AE98ABB0106BC9F899683409@AS8PR08MB6117.eurprd08.prod.outlook.com>

Hi Andre,

> -----Original Message-----
> From: Andre Przywara <andre.przywara at arm.com>
> Sent: Monday, April 26, 2021 8:36 PM
> To: Jaxson Han <Jaxson.Han at arm.com>
> Cc: Mark Rutland <Mark.Rutland at arm.com>; linux-arm-
> kernel at lists.infradead.org; Wei Chen <Wei.Chen at arm.com>
> Subject: Re: [boot-wrapper PATCH 5/5] aarch64: Introduce EL2 boot code for
> Armv8-R AArch64
> 
> On Tue, 20 Apr 2021 15:24:38 +0800
> Jaxson Han <jaxson.han at arm.com> wrote:
> 
> Hi,
> 
> > The Armv8-R AArch64 profile does not support the EL3 exception level.
> > The Armv8-R AArch64 profile allows for an (optional) VMSAv8-64 MMU at
> > EL1, which allows to run off-the-shelf Linux. However EL2 only
> > supports a PMSA, which is not supported by Linux, so we need to drop
> > into EL1 before entering the kernel.
> >
> > The boot sequence is:
> > If CurrentEL == EL3, then goto EL3 initialisation and drop to lower EL
> >   before entering the kernel.
> > If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf (Armv8-R aarch64),
> >   then goto Armv8-R AArch64 initialisation and drop to EL1 before
> >   entering the kernel.
> > Else, no initialisation and keep the current EL before entering the
> >   kernel.
> >
> > Signed-off-by: Jaxson Han <jaxson.han at arm.com>
> > ---
> >  arch/aarch64/boot.S | 51
> > +++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> >
> > diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S index
> > f7dbf3f..6961a2a 100644
> > --- a/arch/aarch64/boot.S
> > +++ b/arch/aarch64/boot.S
> > @@ -25,16 +25,22 @@ _start:
> >  	 * Boot sequence
> >  	 * If CurrentEL == EL3, then goto EL3 initialisation and drop to
> >  	 *   lower EL before entering the kernel.
> > +	 * If CurrentEL == EL2 && id_aa64mmfr0_el1.MSA == 0xf, then goto
> > +	 *   Armv8-R AArch64 initialisation and drop to EL1 before
> > +	 *   entering the kernel.
> >  	 * Else, no initialisation and keep the current EL before
> >  	 *   entering the kernel.
> >  	 */
> >  	mrs	x0, CurrentEL
> >  	cmp	x0, #CURRENTEL_EL3
> >  	beq	el3_init
> > +	cmp	x0, #CURRENTEL_EL2
> > +	beq	el2_init
> 
> nitpick: I tend to compare against EL2, then use b.gt for EL3, b.lt for
> EL1 and b.eq for EL2 code. Saves you an extra cmp here.

Exactly, I will. Thanks!

> 
> >  	/*
> >  	 * We stay in the current EL for entering the kernel
> >  	 */
> > +keep_el:
> >  	mov	w0, #1
> >  	ldr	x1, =flag_keep_el
> >  	str	w0, [x1]
> > @@ -112,6 +118,43 @@ el3_init:
> >  	str	w0, [x1]
> >  	b	el_max_init
> >
> > +	/*
> > +	 * EL2 Armv8-R AArch64 initialisation
> > +	 */
> > +el2_init:
> > +	/* Detect Armv8-R AArch64 */
> > +	mrs	x1, id_aa64mmfr0_el1
> > +	ubfx	x1, x1, #48, #4			// MSA
> > +	/* 0xf means Armv8-R AArch64 */
> > +	cmp	x1, 0xf
> > +	bne	keep_el
> 
> Don't we need to also check bits[55:52], to have at least 0b0010?
> IIUC the support for VMSA in EL1&0 is optional, and should be checked
> before we proceed? VTCR_EL2[31] can only be set in the 0b0010 case.

Yes, it should be checked, I will add it.

> 
> > +
> > +	mrs	x0, midr_el1
> > +	msr	vpidr_el2, x0
> > +
> > +	mrs	x0, mpidr_el1
> > +	msr	vmpidr_el2, x0
> > +
> > +	mov	x0, #(1 << 31)			// VTCR_MSA: VMSAv8-64
> support
> > +	msr	vtcr_el2, x0
> > +
> > +	/* Enable pointer authentication if present */
> > +	mrs	x1, id_aa64isar1_el1
> > +	ldr	x2, =(((0xff) << 24) | (0xff << 4))
> 
> Each feature only holds four bits, so the mask you shift should be 0xf.

Yes, I will fix.

> 
> > +	and	x1, x1, x2
> > +	cbz	x1, 1f
> > +
> > +	mrs	x0, hcr_el2
> 
> Shouldn't we force HCR_EL2, instead of modifying it? Just to make sure
> nothing unexpected traps into EL2, which we don't handle very well?
> So basically just set bit 31 (RES1), plus those two bits on top, if needed. But I
> also wonder about FIEN[47] and EnSCXT[53] ...

Right, we should force to set HCR_EL2. The API and APK is needed.
And I will also check if we need the FIEN[47] and EnSCXT[53].

Thanks,
Jaxson

> 
> 
> Rest looks alright.
> 
> Cheers,
> Andre
> 
> > +	orr	x0, x0, #(1 << 40)		// AP key enable
> > +	orr	x0, x0, #(1 << 41)		// AP insn enable
> > +	msr	hcr_el2, x0
> > +
> > +1:	isb
> > +	mov	w0, #SPSR_KERNEL_EL1
> > +	ldr	x1, =spsr_to_elx
> > +	str	w0, [x1]
> > +	b	el_max_init
> > +
> >  el_max_init:
> >  	ldr	x0, =CNTFRQ
> >  	msr	cntfrq_el0, x0
> > @@ -169,10 +212,18 @@ jump_kernel:
> >  	 */
> >  	bfi	x4, x19, #5, #1
> >
> > +	mrs	x5, CurrentEL
> > +	cmp	x5, #CURRENTEL_EL2
> > +	b.eq	1f
> > +
> >  	msr	elr_el3, x19
> >  	msr	spsr_el3, x4
> >  	eret
> >
> > +1:	msr	elr_el2, x19
> > +	msr	spsr_el2, x4
> > +	eret
> > +
> >  	.ltorg
> >
> >  	.data



From cl at rock-chips.com  Wed Apr 28 04:51:55 2021
From: cl at rock-chips.com (=?UTF-8?B?6ZmI5Lqu?=)
Date: Wed, 28 Apr 2021 11:51:55 +0800
Subject: [PATCH v2 6/7] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <6618564.gtipl9YmvM@diego>
References: <20210425094216.25724-1-cl@rock-chips.com>
 <20210425094439.25895-1-cl@rock-chips.com>
 <16908f63-4e20-ba1b-3b5c-39b4c4db242b@gmail.com> <6618564.gtipl9YmvM@diego>
Message-ID: <12c486c7-f9ce-5ddc-c5db-97e4855f38d6@rock-chips.com>

Hi heiko,

 ??? ??? I plan to drop grf stuff in next version, and make a new submit 
for grf and document later, thanks.

? 2021/4/27 ??4:07, Heiko St?bner ??:
> Am Dienstag, 27. April 2021, 09:41:40 CEST schrieb Johan Jonker:
>> On 4/25/21 11:44 AM, cl at rock-chips.com wrote:
>>> From: Liang Chen <cl at rock-chips.com>
>>>
>>> RK3568 is a high-performance and low power quad-core application processor
>>> designed for personal mobile internet device and AIoT equipments. This patch
>>> add basic core dtsi file for it.
>>>
>>> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
>>> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
>>> enalbe a special high-performacne PLL when high frequency is required. The
>>> smci_clk code is in ATF, and clkid for cpu is 0, as below:
>>>
>>>      cpu0: cpu at 0 {
>>>          device_type = "cpu";
>>>          compatible = "arm,cortex-a55";
>>>          reg = <0x0 0x0>;
>>>          clocks = <&scmi_clk 0>;
>>>      };
>>>
>>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>>> ---
>>>   .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3119 +++++++++++++++++
>>>   arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  812 +++++
>>>   2 files changed, 3931 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>>> new file mode 100644
>>> index 000000000000..94ee3c2c38af
>>> --- /dev/null
>> [..]
>>
>>> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>>> new file mode 100644
>>> index 000000000000..66cb50218ca1
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
>>> @@ -0,0 +1,812 @@
>> [..]
>>
>>> +
>>> +	pmugrf: syscon at fdc20000 {
>>> +		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
>> TODO:
>>
>>> +		reg = <0x0 0xfdc20000 0x0 0x10000>;
>>> +
>>> +		reboot_mode: reboot-mode {
>>> +			compatible = "syscon-reboot-mode";
>>> +			mode-bootloader = <BOOT_BL_DOWNLOAD>;
>>> +			mode-fastboot = <BOOT_FASTBOOT>;
>>> +			mode-loader = <BOOT_BL_DOWNLOAD>;
>>> +			mode-normal = <BOOT_NORMAL>;
>>> +			mode-recovery = <BOOT_RECOVERY>;
>>> +			offset = <0x200>;
>>> +		};
>>> +	};
>>> +
>>> +	grf: syscon at fdc60000 {
>>> +		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
>> TODO:
>>
>>> +		reg = <0x0 0xfdc60000 0x0 0x10000>;
>>> +	};
>>> +
>>> +	pmucru: clock-controller at fdd00000 {
>>> +		compatible = "rockchip,rk3568-pmucru";
>>> +		reg = <0x0 0xfdd00000 0x0 0x1000>;
>>> +		rockchip,grf = <&grf>;
>>> +		rockchip,pmugrf = <&pmugrf>;
>> clock-controller at fdd00000: 'rockchip,grf', 'rockchip,pmugrf' do not
>> match any of the regexes: 'pinctrl-[0-9]+'
>>
>> Currently clk.c has only support for:
>>
>> 	ctx->grf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
>> 						   "rockchip,grf");
>>
>> Manufacturer tree:
>>
>> 	ctx->pmugrf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
>> 						   "rockchip,pmugrf");
>> 		case branch_muxpmugrf:
>> 			clk = rockchip_clk_register_muxgrf(list->name,
>> 				list->parent_names, list->num_parents,
>> 				flags, ctx->pmugrf, list->muxdiv_offset,
>> 				list->mux_shift, list->mux_width,
>> 				list->mux_flags);
>> 			break;
>>
>>
>> 	MUXPMUGRF(SCLK_32K_IOE, "clk_32k_ioe", clk_32k_ioe_p,  0,
>> 			RK3568_PMU_GRF_SOC_CON0, 0, 1, MFLAGS)
> (1) drop the rockchip,pmugrf property please
> (2) as I see it, we will only need the rockchip,grf property.
>
> For main clock controller grf points to main grf
> For pmu clock controller grf points to pmugrf
>
> Each clock controller has its own associated grf.
>
> I really see no case where main-clk would need to access the pmugrf
> same as pmu-clk would should not need to access the main grf, as the
> split into main-{clk,grf} + pmu-{clk,grf} is probably a for power-management
> reasons to separate different power-areas, the driver should also not
> cross this barrier anyway ;-) .
>
> Same as, if a clk uses the pmugrf it is a pmu-based clock, if it uses the
> main grf, it should live in the main clock driver.
>
> And as expected the clk_32k_ioe is already defined in the pmuclk
> part of the driver ;-)
>
>
> Heiko
>
>
>>> +		#clock-cells = <1>;
>>> +		#reset-cells = <1>;
>>> +	};
>>> +
>>> +	cru: clock-controller at fdd20000 {
>>> +		compatible = "rockchip,rk3568-cru";
>>> +		reg = <0x0 0xfdd20000 0x0 0x1000>;
>>> +		rockchip,grf = <&grf>;
>> clock-controller at fdd20000: 'assigned-clock-parents',
>> 'assigned-clock-rates', 'assigned-clocks', 'rockchip,grf' do not match
>> any of the regexes:
>>
>> Add more properties to rockchip,rk3568-cru.yaml
>>
>>> +		#clock-cells = <1>;
>>> +		#reset-cells = <1>;
>>> +
>>> +		assigned-clocks =
>>> +			<&pmucru CLK_RTC_32K>, <&pmucru PLL_PPLL>,
>>> +			<&pmucru PCLK_PMU>, <&cru PLL_CPLL>,
>>> +			<&cru PLL_GPLL>, <&cru ACLK_BUS>,
>>> +			<&cru PCLK_BUS>, <&cru ACLK_TOP_HIGH>,
>>> +			<&cru ACLK_TOP_LOW>, <&cru HCLK_TOP>,
>>> +			<&cru PCLK_TOP>, <&cru ACLK_PERIMID>,
>>> +			<&cru HCLK_PERIMID>, <&cru PLL_NPLL>,
>>> +			<&cru ACLK_PIPE>, <&cru PCLK_PIPE>,
>>> +			<&cru ACLK_VOP>;
>>> +		assigned-clock-rates =
>>> +			<32768>, <200000000>,
>>> +			<100000000>, <1000000000>,
>>> +			<1188000000>, <150000000>,
>>> +			<100000000>, <500000000>,
>>> +			<400000000>, <150000000>,
>>> +			<100000000>, <300000000>,
>>> +			<150000000>, <1200000000>,
>>> +			<400000000>, <100000000>,
>>> +			<500000000>;
>>> +		assigned-clock-parents =
>>> +			<&pmucru CLK_RTC32K_FRAC>;
>>> +	};
>
>
>
>
>
>




From hsinyi at chromium.org  Wed Apr 28 05:55:31 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 28 Apr 2021 12:55:31 +0800
Subject: [PATCH v4 1/3] gpu: drm: separate panel orientation property creating
 and value setting
Message-ID: <20210428045533.564724-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
v4, v3:
create property in dsi driver and set value in panel.

v2:
create property in connector init
https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsinyi at chromium.org/

v1:
set panel orientation in dsi driver
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
---
 drivers/gpu/drm/drm_connector.c | 58 +++++++++++++++++++++++++--------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..cda83314d7ad 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will create one first.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2206,18 +2206,16 @@ int drm_connector_set_panel_orientation(
 
 	prop = dev->mode_config.panel_orientation_property;
 	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
+		int ret;
 
-		dev->mode_config.panel_orientation_property = prop;
+		ret = drm_connector_init_panel_orientation_property(connector);
+		if (ret)
+			return ret;
+		prop = dev->mode_config.panel_orientation_property;
 	}
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2225,7 +2223,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk -
  *	set the connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2252,6 +2250,40 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..4396c1c4a5db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 28 05:55:32 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 28 Apr 2021 12:55:32 +0800
Subject: [PATCH v4 2/3] drm/mediatek: init panel orientation property
In-Reply-To: <20210428045533.564724-1-hsinyi@chromium.org>
References: <20210428045533.564724-1-hsinyi@chromium.org>
Message-ID: <20210428045533.564724-2-hsinyi@chromium.org>

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..9da1fd649131 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -964,6 +964,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 28 05:55:33 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Wed, 28 Apr 2021 12:55:33 +0800
Subject: [PATCH v4 3/3] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210428045533.564724-1-hsinyi@chromium.org>
References: <20210428045533.564724-1-hsinyi@chromium.org>
Message-ID: <20210428045533.564724-3-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From lakshmis at xilinx.com  Wed Apr 28 06:33:46 2021
From: lakshmis at xilinx.com (Sai Krishna Potthuri)
Date: Wed, 28 Apr 2021 05:33:46 +0000
Subject: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
In-Reply-To: <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <1619080202-31924-4-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CAHp75VfCbbnN-TBJiYFb=6Rhf30jA-Hz1p1UORsubF7UG6-ATw@mail.gmail.com>
 <DM5PR02MB3877B234F85F3B4887DF3A95BD429@DM5PR02MB3877.namprd02.prod.outlook.com>
 <CAHp75VfugGqLNU8LKJ_K3dPr=-eh6LHx75eV=33jH9OnryBoGA@mail.gmail.com>
Message-ID: <DM5PR02MB387726AB4144F0DB28105007BD409@DM5PR02MB3877.namprd02.prod.outlook.com>

Hi Andy Shevchenko,

> -----Original Message-----
> From: Andy Shevchenko <andy.shevchenko at gmail.com>
> Sent: Monday, April 26, 2021 7:35 PM
> To: Sai Krishna Potthuri <lakshmis at xilinx.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>; Rob Herring
> <robh+dt at kernel.org>; Michal Simek <michals at xilinx.com>; Greg Kroah-
> Hartman <gregkh at linuxfoundation.org>; linux-arm Mailing List <linux-arm-
> kernel at lists.infradead.org>; Linux Kernel Mailing List <linux-
> kernel at vger.kernel.org>; devicetree <devicetree at vger.kernel.org>; open
> list:GPIO SUBSYSTEM <linux-gpio at vger.kernel.org>; git <git at xilinx.com>;
> saikrishna12468 at gmail.com
> Subject: Re: [PATCH v6 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
> 
> On Mon, Apr 26, 2021 at 4:20 PM Sai Krishna Potthuri
> <lakshmis at xilinx.com> wrote:
> > > From: Andy Shevchenko <andy.shevchenko at gmail.com>
> > > Sent: Friday, April 23, 2021 9:24 PM
> > > On Thu, Apr 22, 2021 at 11:31 AM Sai Krishna Potthuri
> > > <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> 
> ...
> 
> > > > +config PINCTRL_ZYNQMP
> > > > +       tristate "Pinctrl driver for Xilinx ZynqMP"
> > > > +       depends on ZYNQMP_FIRMWARE
> > > > +       select PINMUX
> > > > +       select GENERIC_PINCONF
> > > > +       default ZYNQMP_FIRMWARE
> > > > +       help
> > > > +         This selects the pinctrl driver for Xilinx ZynqMP platform.
> > > > +         This driver will query the pin information from the firmware
> > > > +         and allow configuring the pins.
> > > > +         Configuration can include the mux function to select on those
> > > > +         pin(s)/group(s), and various pin configuration parameters
> > > > +         such as pull-up, slew rate, etc.
> > >
> > > Missed module name.
> > Is this (module name) a configuration option in Kconfig?
> 
> It's a text in a free form that sheds light on how the module will be
> named in case the user will choose "m".
Ok, I will add.
> 
> ...
> 
> > > > + * Copyright (C) 2020 Xilinx, Inc.
> > >
> > > 2021?
> > Couple of versions for this patch series sent in 2020, hence maintaining
> > the same.
> > Is it like we maintain the year when this patch series is applied, which is
> > 2021?
> 
> 2020, 2021 sounds okay as well.
Ok, I will update.
> 
> ...
> 
> > > > +       if (pin >= zynqmp_desc.npins)
> > > > +               return -EOPNOTSUPP;
> > >
> > > Is it possible?
> > This is a safe check.
> 
> I.o.w. dead code, right?
> 
> > Pin information will get from dt files/Xilinx firmware (query pin information
> > for a group)/user application and there are chances of getting wrong pin.
> 
> I'm not sure I understand this. How comes that pin control core will
> ask for a pin higher than npins?
Ok, I got your point.
It is duplicate and will remove this check.
> 
> ...
> 
> > > > +               ret = zynqmp_pm_pinctrl_get_config(pin, param, &arg);
> > > > +               if (arg != PM_PINCTRL_BIAS_PULL_UP)
> > > > +                       return -EINVAL;
> > >
> > > Error code being shadowed. Instead check it here properly.
> 
> > Are you mentioning the case where ret is also a non-zero?
> > If yes, then I will update this check to
> > if (!ret && arg != PM_PINCTRL_BIAS_PULL_UP)
> >         return -EINVAL;
> 
> No, this is wrong in the same way.
> 
> > ret non-zero case, we are handling at the end of switch case.
> 
> I meant that you need to pass the real return code to the (upper) caller.
Here we are checking for valid argument and not the return value of the API.
If the read value(argument) is not valid and return value of the API is
zero (SUCCESS) then framework expects driver to be returned with
'-EINVAL' and it is a legal error code in this case.
> Ditto for all other cases (mentioned and not mentioned)
> 
> ...
> 
> > > > +                       ret = -EOPNOTSUPP;
> > >
> > > Isn't it ENOTSUP for all cases here?
> > Giving 'Operation Not Supported (EOPNOTSUPP)' error, when
> > driver gets a request for unsupported pin or configuration.
> > Can you please elaborate your question if I didn't answer properly.
> 
> The pin control subsystem along with the GPIO library are using
> -ENOTSUPP error code for internal operations.
> EOPNOTSUPP is the one that should be returned to user space. Is it the
> case here?
Got your point, I will update error code with ENOTSUPP.
> 
> ...
> 
> > > > +};
> > >
> > > > +
> > >
> > > Ditto.
> > I see some drivers are maintaining the extra line in above two cases.
> > We shouldn't maintain extra line after struct declaration?
> 
> What's the point to add more blank lines where they won't add any value?
I will remove.

Regards
Sai Krishna
> 
> > > > +module_platform_driver(zynqmp_pinctrl_driver);
> 
> --
> With Best Regards,
> Andy Shevchenko

From gregkh at linuxfoundation.org  Wed Apr 28 06:59:28 2021
From: gregkh at linuxfoundation.org (Greg KH)
Date: Wed, 28 Apr 2021 07:59:28 +0200
Subject: [PATCH] ata: ahci_sunxi: Disable DIPM
In-Reply-To: <20210427230537.21423-1-public_timo.s@silentcreek.de>
References: <20210427230537.21423-1-public_timo.s@silentcreek.de>
Message-ID: <YIj5wKTdOVWLdD2d@kroah.com>

On Wed, Apr 28, 2021 at 01:05:37AM +0200, Timo Sigurdsson wrote:
> DIPM is unsupported or broken on sunxi. Trying to enable the power
> management policy med_power_with_dipm on an Allwinner A20 SoC based board
> leads to immediate I/O errors and the attached SATA disk disappears from
> the /dev filesystem. A reset (power cycle) is required to make the SATA
> controller or disk work again. The A10 and A20 SoC data sheets and manuals
> don't mention DIPM at all [1], so it's fair to assume that it's simply not
> supported. But even if it were, it should be considered broken and best be
> disabled in the ahci_sunxi driver.
> 
> Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")
> 
> [1] https://github.com/allwinner-zh/documents/tree/master/
> 
> Signed-off-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
> Tested-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
> ---
>  drivers/ata/ahci_sunxi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
> index cb69b737cb49..56b695136977 100644
> --- a/drivers/ata/ahci_sunxi.c
> +++ b/drivers/ata/ahci_sunxi.c
> @@ -200,7 +200,7 @@ static void ahci_sunxi_start_engine(struct ata_port *ap)
>  }
>  
>  static const struct ata_port_info ahci_sunxi_port_info = {
> -	.flags		= AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
> +	.flags		= AHCI_FLAG_COMMON | ATA_FLAG_NCQ | ATA_FLAG_NO_DIPM,
>  	.pio_mask	= ATA_PIO4,
>  	.udma_mask	= ATA_UDMA6,
>  	.port_ops	= &ahci_platform_ops,
> -- 
> 2.26.2
> 
<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>


From rppt at kernel.org  Wed Apr 28 06:59:41 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Wed, 28 Apr 2021 08:59:41 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
References: <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
Message-ID: <YIj5zcbHBHt7CC8B@kernel.org>

On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/27 14:23, Mike Rapoport wrote:
> > On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> > > On 2021/4/26 13:20, Mike Rapoport wrote:
> > > > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > > > 
> > > > >       On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > > > 
> > > > >           I tested this patchset(plus arm32 change, like arm64 does)
> > > > >           based on lts 5.10?add some debug log, the useful info shows
> > > > >           below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > > > >           thanks.
> > > > > 
> > > > >       Are there any changes on top of 5.10 except for pfn_valid() patch?
> > > > >       Do you see this panic on 5.10 without the changes?
> > > > > 
> > > > > Yes, there are some BSP support for arm board based on 5.10,
> > Is it possible to test 5.12?

Do you use SPARSMEM? If yes, what is your section size?
What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?

-- 
Sincerely yours,
Mike.


From gregkh at linuxfoundation.org  Wed Apr 28 07:12:03 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 28 Apr 2021 08:12:03 +0200
Subject: [PATCH] dt-bindings: nvmem: mediatek: remove duplicate mt8192 line
In-Reply-To: <20210427210121.1080364-1-arnd@kernel.org>
References: <20210427210121.1080364-1-arnd@kernel.org>
Message-ID: <YIj8sySF3W0x8E+/@kroah.com>

On Tue, Apr 27, 2021 at 11:01:08PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> The same patch was accidentally merged twice, resulting in a
> duplicate line for the mt8192 SoC.
> 
> Fixes: f2674c0c7488 ("dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC")
> Fixes: 2a1405a14c3a ("dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> index d479ad977e24..2f2895b1f06d 100644
> --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> @@ -7,7 +7,6 @@ Required properties:
>  	      "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
>  	      "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
>  	      "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
> -	      "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
>  	      "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
>  	      "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192

Shouldn't you drop the bottom one here to keep this in sorted order?

thanks,

greg k-h


From u.kleine-koenig at pengutronix.de  Wed Apr 28 07:13:57 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Wed, 28 Apr 2021 08:13:57 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
References: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
Message-ID: <20210428061357.725m72aikc52n4gg@pengutronix.de>

Hello Roman,

On Wed, Apr 28, 2021 at 02:19:46AM +0200, Roman Beranek wrote:
> More often than not, a PWM period may span nowhere near as far
> as 1 jiffy, yet it still must be waited upon before the channel
> is disabled.

I wonder what happens if you don't wait long enough. Is this a
theoretical issue, or do you see an (occasional?) breakage that is fixed
by this patch?

I guess the problem is that if you disable too early the output freezes
and that might be in a state where the output is still active? Would
polling the PWMx_RDY bit in the control register help here?

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/20210428/6f406378/attachment.sig>

From CLoehle at hyperstone.com  Wed Apr 28 07:28:06 2021
From: CLoehle at hyperstone.com (=?iso-8859-1?Q?Christian_L=F6hle?=)
Date: Wed, 28 Apr 2021 06:28:06 +0000
Subject: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64
In-Reply-To: <97bcbcde-9ccf-f9cc-ef10-36cbd582825a@web.de>
References: <CWXP265MB2680938B222248792AC205F9C4419@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>,
 <97bcbcde-9ccf-f9cc-ef10-36cbd582825a@web.de>
Message-ID: <CWXP265MB2680159B5F44B014FA544E89C4409@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>

Oh okay, I was not aware of this issue
and have not encountered it yet.
But wouldn't it be more appropriate
to get u-boot to power cycle the host controller at boot?


From: Soeren Moch <smoch at web.de>
Sent: Tuesday, April 27, 2021 5:07 PM
To: Christian L?hle <CLoehle at hyperstone.com>; robh+dt at kernel.org <robh+dt at kernel.org>; heiko at sntech.de <heiko at sntech.de>; jbx6244 at gmail.com <jbx6244 at gmail.com>; devicetree at vger.kernel.org <devicetree at vger.kernel.org>; linux-arm-kernel at lists.infradead.org <linux-arm-kernel at lists.infradead.org>; linux-rockchip at lists.infradead.org <linux-rockchip at lists.infradead.org>; linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>
Subject: Re: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64 
?
On 27.04.21 08:20, Christian L?hle wrote:
> The DesignWare Host Controller has full UHS-I support, so use it.
Enabling this UHS support makes 'reboot' hang when booting the RockPro64
from SD card. It would work when booting from eMMC, or with a modified
ATF which does a power cycle on reboot.

But for general use it is not save to enable UHS support, or did I miss
some recent changes?

Regards,
Soeren
>
> Signed-off-by: Christian Loehle <cloehle at hyperstone.com>
> ---
>? arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 1 +
>? 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> index 6bff8db7d33e..d22a489ec214 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> @@ -722,6 +722,7 @@ &sdmmc {
>??????? max-frequency = <150000000>;
>??????? pinctrl-names = "default";
>??????? pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> +???? sd-uhs-sdr104;
>??????? vmmc-supply = <&vcc3v0_sd>;
>??????? vqmmc-supply = <&vcc_sdio>;
>??????? status = "okay";

Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782



From ikjn at chromium.org  Wed Apr 28 07:44:18 2021
From: ikjn at chromium.org (Ikjoon Jang)
Date: Wed, 28 Apr 2021 14:44:18 +0800
Subject: [RESEND PATCH v7 00/22] Mediatek MT8192 clock support
In-Reply-To: <1617881329.6756.3.camel@mtksdccf07>
References: <20210324104110.13383-1-chun-jie.chen@mediatek.com>
 <1617881329.6756.3.camel@mtksdccf07>
Message-ID: <CAATdQgBkY0Gc+WpGkvf9CuRF_WpJTymzi+j2whQ13pfCoxBWmg@mail.gmail.com>

ping again.

On Thu, Apr 8, 2021 at 7:29 PM 20181221120906 created
<chun-jie.chen at mediatek.com> wrote:
>
> On Wed, 2021-03-24 at 18:40 +0800, Chun-Jie Chen (???) wrote:
>
> Hi Maintainers,
>
> Gentle pin for this patch series.
>
> Thanks
>
> > reason for resending v7:
> > - add review history from series below
> > [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405295__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBXEY4iHa$
> >
> > change since v6:
> > - update from series below
> > [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405295__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBXEY4iHa$
> > - fix DT bindings fail
> > - fix checkpatch warning
> > - update mux ops without gate control
> >
> > change since v5:
> > - remove unused clocks by rolling Tinghan's patches[1][2] into series
> > [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=398781__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBS6llsNi$
> > [2] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=405143__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBfBntgEt$
> > - remove dts related patches from series
> >
> > change since v4:
> > - merge some subsystem into same driver
> > - add a generic probe function to reduce duplicated code
> >
> > changes since v3:
> > - add critical clocks
> > - split large patches into small ones
> >
> > changes since v2:
> > - update and split dt-binding documents by functionalities
> > - add error checking in probe() function
> > - fix incorrect clock relation and add critical clocks
> > - update license identifier and minor fix of coding style
> >
> > changes since v1:
> > - fix asymmetrical control of PLL
> > - have en_mask used as divider enable mask on all MediaTek SoC
> >
> > chun-jie.chen (22):
> >   dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c
> >     wrapper controller
> >   dt-bindings: ARM: Mediatek: Add new document bindings of mdpsys
> >     controller
> >   dt-bindings: ARM: Mediatek: Add new document bindings of msdc
> >     controller
> >   dt-bindings: ARM: Mediatek: Add new document bindings of scp adsp
> >     controller
> >   dt-bindings: ARM: Mediatek: Document bindings of MT8192 clock
> >     controllers
> >   clk: mediatek: Add dt-bindings of MT8192 clocks
> >   clk: mediatek: Fix asymmetrical PLL enable and disable control
> >   clk: mediatek: Add configurable enable control to mtk_pll_data
> >   clk: mediatek: Add mtk_clk_simple_probe() to simplify clock providers
> >   clk: mediatek: Add MT8192 basic clocks support
> >   clk: mediatek: Add MT8192 audio clock support
> >   clk: mediatek: Add MT8192 camsys clock support
> >   clk: mediatek: Add MT8192 imgsys clock support
> >   clk: mediatek: Add MT8192 imp i2c wrapper clock support
> >   clk: mediatek: Add MT8192 ipesys clock support
> >   clk: mediatek: Add MT8192 mdpsys clock support
> >   clk: mediatek: Add MT8192 mfgcfg clock support
> >   clk: mediatek: Add MT8192 mmsys clock support
> >   clk: mediatek: Add MT8192 msdc clock support
> >   clk: mediatek: Add MT8192 scp adsp clock support
> >   clk: mediatek: Add MT8192 vdecsys clock support
> >   clk: mediatek: Add MT8192 vencsys clock support
> >
> >  .../arm/mediatek/mediatek,apmixedsys.txt      |    1 +
> >  .../bindings/arm/mediatek/mediatek,audsys.txt |    1 +
> >  .../bindings/arm/mediatek/mediatek,camsys.txt |   22 +
> >  .../bindings/arm/mediatek/mediatek,imgsys.txt |    2 +
> >  .../arm/mediatek/mediatek,imp_iic_wrap.yaml   |   80 +
> >  .../arm/mediatek/mediatek,infracfg.txt        |    1 +
> >  .../bindings/arm/mediatek/mediatek,ipesys.txt |    1 +
> >  .../arm/mediatek/mediatek,mdpsys.yaml         |   40 +
> >  .../bindings/arm/mediatek/mediatek,mfgcfg.txt |    1 +
> >  .../bindings/arm/mediatek/mediatek,mmsys.txt  |    1 +
> >  .../bindings/arm/mediatek/mediatek,msdc.yaml  |   48 +
> >  .../arm/mediatek/mediatek,pericfg.yaml        |    1 +
> >  .../arm/mediatek/mediatek,scp-adsp.yaml       |   40 +
> >  .../arm/mediatek/mediatek,topckgen.txt        |    1 +
> >  .../arm/mediatek/mediatek,vdecsys.txt         |    8 +
> >  .../arm/mediatek/mediatek,vencsys.txt         |    1 +
> >  drivers/clk/mediatek/Kconfig                  |   80 +
> >  drivers/clk/mediatek/Makefile                 |   13 +
> >  drivers/clk/mediatek/clk-mt8192-aud.c         |  118 ++
> >  drivers/clk/mediatek/clk-mt8192-cam.c         |  107 ++
> >  drivers/clk/mediatek/clk-mt8192-img.c         |   70 +
> >  .../clk/mediatek/clk-mt8192-imp_iic_wrap.c    |  119 ++
> >  drivers/clk/mediatek/clk-mt8192-ipe.c         |   57 +
> >  drivers/clk/mediatek/clk-mt8192-mdp.c         |   82 +
> >  drivers/clk/mediatek/clk-mt8192-mfg.c         |   50 +
> >  drivers/clk/mediatek/clk-mt8192-mm.c          |  108 ++
> >  drivers/clk/mediatek/clk-mt8192-msdc.c        |   85 ++
> >  drivers/clk/mediatek/clk-mt8192-scp_adsp.c    |   50 +
> >  drivers/clk/mediatek/clk-mt8192-vdec.c        |   94 ++
> >  drivers/clk/mediatek/clk-mt8192-venc.c        |   53 +
> >  drivers/clk/mediatek/clk-mt8192.c             | 1326 +++++++++++++++++
> >  drivers/clk/mediatek/clk-mtk.c                |   23 +
> >  drivers/clk/mediatek/clk-mtk.h                |   28 +-
> >  drivers/clk/mediatek/clk-mux.c                |    9 +-
> >  drivers/clk/mediatek/clk-mux.h                |   18 +-
> >  drivers/clk/mediatek/clk-pll.c                |   31 +-
> >  include/dt-bindings/clock/mt8192-clk.h        |  585 ++++++++
> >  37 files changed, 3335 insertions(+), 20 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml
> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml
> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-aud.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-cam.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-img.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-imp_iic_wrap.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-ipe.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-mdp.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-mfg.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-mm.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-msdc.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-scp_adsp.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-vdec.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192-venc.c
> >  create mode 100644 drivers/clk/mediatek/clk-mt8192.c
> >  create mode 100644 include/dt-bindings/clock/mt8192-clk.h
> >
> > --
> > 2.18.0
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek at lists.infradead.org
> > https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!yiC4Bd7Av9itRUTEQeBUWbH_wX08o2rIYTH0BJ_BljLXWzCPb2sYdGLjFLwWBdxKKU1e$
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek


From roger.lu at mediatek.com  Wed Apr 28 07:54:39 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:39 +0800
Subject: [PATCH v16 6/7] arm64: dts: mt8192: add svs device information
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-7-roger.lu@mediatek.com>

add compitable/reg/irq/clock/efuse/reset setting in svs node

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 34 ++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index fe24cc66ff7a..e9816a56d87b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -270,6 +270,14 @@
 			compatible = "mediatek,mt8192-infracfg", "syscon";
 			reg = <0 0x10001000 0 0x1000>;
 			#clock-cells = <1>;
+
+			infracfg_rst: reset-controller {
+				compatible = "mediatek,infra-reset", "ti,syscon-reset";
+				#reset-cells = <1>;
+				ti,reset-bits = <
+					0x150 5 0x154 5 0 0     (ASSERT_SET | DEASSERT_SET | STATUS_NONE) /* 0: svs */
+				>;
+			};
 		};
 
 		pericfg: syscon at 10003000 {
@@ -564,6 +572,20 @@
 			status = "disabled";
 		};
 
+		svs: svs at 1100b000 {
+			compatible = "mediatek,mt8192-svs";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH 0>;
+			clocks = <&infracfg CLK_INFRA_THERM>;
+			clock-names = "main";
+			nvmem-cells = <&svs_calibration>,
+				      <&lvts_e_data1>;
+			nvmem-cell-names = "svs-calibration-data",
+					   "t-calibration-data";
+			resets = <&infracfg_rst 0>;
+			reset-names = "svs_rst";
+		};
+
 		spi1: spi at 11010000 {
 			compatible = "mediatek,mt8192-spi",
 				     "mediatek,mt6765-spi";
@@ -681,6 +703,18 @@
 			#clock-cells = <1>;
 		};
 
+		efuse: efuse at 11c10000 {
+			compatible = "mediatek,efuse";
+			reg = <0 0x11c10000 0 0x1000>;
+
+			lvts_e_data1: data1 {
+				reg = <0x1C0 0x58>;
+			};
+			svs_calibration: calib at 580 {
+				reg = <0x580 0x68>;
+			};
+		};
+
 		i2c3: i2c3 at 11cb0000 {
 			compatible = "mediatek,mt8192-i2c";
 			reg = <0 0x11cb0000 0 0x1000>,
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:35 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:35 +0800
Subject: [PATCH v16 2/7] arm64: dts: mt8183: add svs device information
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-3-roger.lu@mediatek.com>

add compitable/reg/irq/clock/efuse setting in svs node

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 80519a145f13..441d617ece43 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -657,6 +657,18 @@
 			status = "disabled";
 		};
 
+		svs: svs at 1100b000 {
+			compatible = "mediatek,mt8183-svs";
+			reg = <0 0x1100b000 0 0x1000>;
+			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&infracfg CLK_INFRA_THERM>;
+			clock-names = "main";
+			nvmem-cells = <&svs_calibration>,
+				      <&thermal_calibration>;
+			nvmem-cell-names = "svs-calibration-data",
+					   "t-calibration-data";
+		};
+
 		pwm0: pwm at 1100e000 {
 			compatible = "mediatek,mt8183-disp-pwm";
 			reg = <0 0x1100e000 0 0x1000>;
@@ -941,9 +953,15 @@
 			reg = <0 0x11f10000 0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <1>;
+			thermal_calibration: calib at 180 {
+				reg = <0x180 0xc>;
+			};
 			mipi_tx_calibration: calib at 190 {
 				reg = <0x190 0xc>;
 			};
+			svs_calibration: calib at 580 {
+				reg = <0x580 0x64>;
+			};
 		};
 
 		u3phy: usb-phy at 11f40000 {
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:38 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:38 +0800
Subject: [PATCH v16 5/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-6-roger.lu@mediatek.com>

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/soc/mediatek/mtk-svs.yaml         | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
index a855ced410f8..59342e627b67 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -22,6 +22,7 @@ properties:
   compatible:
     enum:
       - mediatek,mt8183-svs
+      - mediatek,mt8192-svs
 
   reg:
     maxItems: 1
@@ -51,6 +52,13 @@ properties:
       - const: svs-calibration-data
       - const: t-calibration-data
 
+  resets:
+    maxItems: 1
+
+  reset-names:
+    items:
+      - const: svs_rst
+
 required:
   - compatible
   - reg
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:34 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:34 +0800
Subject: [PATCH v16 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-2-roger.lu@mediatek.com>

Document the binding for enabling mtk svs on MediaTek SoC.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
Reviewed-by: Rob Herring <robh at kernel.org>
---
 .../bindings/soc/mediatek/mtk-svs.yaml        | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
new file mode 100644
index 000000000000..a855ced410f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Smart Voltage Scaling (SVS) Device Tree Bindings
+
+maintainers:
+  - Roger Lu <roger.lu at mediatek.com>
+  - Matthias Brugger <matthias.bgg at gmail.com>
+  - Kevin Hilman <khilman at kernel.org>
+
+description: |+
+  The SVS engine is a piece of hardware which has several
+  controllers(banks) for calculating suitable voltage to
+  different power domains(CPU/GPU/CCI) according to
+  chip process corner, temperatures and other factors. Then DVFS
+  driver could apply SVS bank voltage to PMIC/Buck.
+
+properties:
+  compatible:
+    enum:
+      - mediatek,mt8183-svs
+
+  reg:
+    maxItems: 1
+    description: Address range of the MTK SVS controller.
+
+  interrupts:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: Main clock for MTK SVS controller to work.
+
+  clock-names:
+    const: main
+
+  nvmem-cells:
+    minItems: 1
+    maxItems: 2
+    description:
+      Phandle to the calibration data provided by a nvmem device.
+    items:
+      - description: SVS efuse for SVS controller
+      - description: Thermal efuse for SVS controller
+
+  nvmem-cell-names:
+    items:
+      - const: svs-calibration-data
+      - const: t-calibration-data
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - nvmem-cells
+  - nvmem-cell-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/mt8183-clk.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        svs at 1100b000 {
+            compatible = "mediatek,mt8183-svs";
+            reg = <0 0x1100b000 0 0x1000>;
+            interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
+            clocks = <&infracfg CLK_INFRA_THERM>;
+            clock-names = "main";
+            nvmem-cells = <&svs_calibration>, <&thermal_calibration>;
+            nvmem-cell-names = "svs-calibration-data", "t-calibration-data";
+        };
+    };
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:40 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:40 +0800
Subject: [PATCH v16 7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-8-roger.lu@mediatek.com>

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 485 ++++++++++++++++++++++++++++++++-
 1 file changed, 479 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 8794a2d87baa..9a0cc9cbf679 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -36,6 +36,10 @@
 #define SVSB_CCI			BIT(2)
 #define SVSB_GPU			BIT(3)
 
+/* svs bank 2-line type */
+#define SVSB_LOW			BIT(4)
+#define SVSB_HIGH			BIT(5)
+
 /* svs bank mode support */
 #define SVSB_MODE_ALL_DISABLE		0
 #define SVSB_MODE_INIT01		BIT(1)
@@ -323,6 +327,7 @@ struct svs_platform {
  * @volts: bank voltages
  * @reg_data: bank register data of each phase
  * @freq_base: reference frequency for bank init
+ * @turn_freq_base: refenrece frequency for turn point
  * @vboot: voltage request for bank init01 stage only
  * @volt_step: bank voltage step
  * @volt_base: bank voltage base
@@ -343,6 +348,8 @@ struct svs_platform {
  * @hw_id: bank hardware identification
  * @ctl0: bank thermal sensor selection
  * @cpu_id: cpu core id for SVS CPU only
+ * @turn_pt: turn point informs which opp_volt calculated by high/low bank.
+ * @type: bank type to represent it is 2-line (high/low) bank or 1-line bank.
  *
  * Other structure members which are not listed above are svs platform
  * efuse data for bank init
@@ -371,6 +378,7 @@ struct svs_bank {
 	u32 volts[16];
 	u32 reg_data[SVSB_PHASE_NUM][SVS_REG_NUM];
 	u32 freq_base;
+	u32 turn_freq_base;
 	u32 vboot;
 	u32 volt_step;
 	u32 volt_base;
@@ -410,6 +418,8 @@ struct svs_bank {
 	u32 hw_id;
 	u32 ctl0;
 	u32 cpu_id;
+	u32 turn_pt;
+	u32 type;
 };
 
 static u32 percent(u32 numerator, u32 denominator)
@@ -445,6 +455,37 @@ static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
 	return (svsb_volt * svsb_volt_step) + svsb_volt_base;
 }
 
+static u32 svs_opp_volt_to_bank_volt(u32 opp_u_volt, u32 svsb_volt_step,
+				     u32 svsb_volt_base)
+{
+	return (opp_u_volt - svsb_volt_base) / svsb_volt_step;
+}
+
+static int svs_sync_bank_volts_from_opp(struct svs_bank *svsb)
+{
+	struct dev_pm_opp *opp;
+	u32 i, opp_u_volt;
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+						 svsb->opp_freqs[i],
+						 true);
+		if (IS_ERR(opp)) {
+			dev_err(svsb->dev, "cannot find freq = %u (%ld)\n",
+				svsb->opp_freqs[i], PTR_ERR(opp));
+			return PTR_ERR(opp);
+		}
+
+		opp_u_volt = dev_pm_opp_get_voltage(opp);
+		svsb->volts[i] = svs_opp_volt_to_bank_volt(opp_u_volt,
+							   svsb->volt_step,
+							   svsb->volt_base);
+		dev_pm_opp_put(opp);
+	}
+
+	return 0;
+}
+
 static int svs_get_bank_zone_temperature(const char *tzone_name,
 					 int *tzone_temp)
 {
@@ -460,7 +501,7 @@ static int svs_get_bank_zone_temperature(const char *tzone_name,
 static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 {
 	int tzone_temp = 0, ret = -EPERM;
-	u32 i, svsb_volt, opp_volt, temp_offset = 0;
+	u32 i, svsb_volt, opp_volt, temp_offset = 0, opp_start, opp_stop;
 
 	mutex_lock(&svsb->lock);
 
@@ -474,6 +515,21 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 		goto unlock_mutex;
 	}
 
+	/*
+	 * 2-line bank updates its corresponding opp volts.
+	 * 1-line bank updates all opp volts.
+	 */
+	if (svsb->type == SVSB_HIGH) {
+		opp_start = 0;
+		opp_stop = svsb->turn_pt;
+	} else if (svsb->type == SVSB_LOW) {
+		opp_start = svsb->turn_pt;
+		opp_stop = svsb->opp_count;
+	} else {
+		opp_start = 0;
+		opp_stop = svsb->opp_count;
+	}
+
 	/* Get thermal effect */
 	if (svsb->phase == SVSB_PHASE_MON) {
 		if (svsb->temp > svsb->temp_upper_bound &&
@@ -495,10 +551,16 @@ static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
 			temp_offset += svsb->tzone_high_temp_offset;
 		else if (tzone_temp <= svsb->tzone_low_temp)
 			temp_offset += svsb->tzone_low_temp_offset;
+
+		/* 2-line bank takes thermal factor to update all opp volts */
+		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+			opp_start = 0;
+			opp_stop = svsb->opp_count;
+		}
 	}
 
 	/* vmin <= svsb_volt (opp_volt) <= signed-off (default) voltage */
-	for (i = 0; i < svsb->opp_count; i++) {
+	for (i = opp_start; i < opp_stop; i++) {
 		if (svsb->phase == SVSB_PHASE_MON) {
 			svsb_volt = max(svsb->volts[i] + svsb->volt_offset +
 					temp_offset, svsb->vmin);
@@ -549,6 +611,184 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
 	return DIV_ROUND_UP(vx, 100);
 }
 
+static void svs_get_vops_v3(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 i, vop_i, *vop, vop74, vop30, mask7_0 = GENMASK(7, 0);
+	u32 b_sft, bits8 = 8, shift_byte = 0, reg_4bytes = 4;
+	u32 middle_index = (svsb->opp_count / 2);
+	u32 opp_start = 0, opp_stop = 0, turn_pt = svsb->turn_pt;
+
+	if (svsb->phase == SVSB_PHASE_MON &&
+	    svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
+		return;
+
+	vop74 = svs_readl(svsp, VOP74);
+	vop30 = svs_readl(svsp, VOP30);
+
+	if (turn_pt < middle_index) {
+		if (svsb->type == SVSB_HIGH) {
+			/* We attain volts[0 ~ (turn_pt - 1)] */
+			for (i = 0; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/*
+			 * We attain volts[turn_pt] +
+			 * volts[vop_i ~ (opp_count - 1)]
+			 */
+			vop_i = svsb->opp_count - 7;
+			svsb->volts[turn_pt] = vop30 & mask7_0;
+			shift_byte++;
+			for (i = vop_i; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+
+			/*
+			 * We attain volts[turn_pt + 1 ~ (vop_i - 1)]
+			 * by interpolate
+			 */
+			for (i = turn_pt + 1; i < vop_i; i++)
+				svsb->volts[i] =
+					interpolate(svsb->freqs_pct[turn_pt],
+						    svsb->freqs_pct[vop_i],
+						    svsb->volts[turn_pt],
+						    svsb->volts[vop_i],
+						    svsb->freqs_pct[i]);
+		}
+	} else {
+		if (svsb->type == SVSB_HIGH) {
+			/* We attain volts[0] + volts[vop_i ~ (turn_pt - 1)] */
+			vop_i = turn_pt - 7;
+			svsb->volts[0] = vop30 & mask7_0;
+			shift_byte++;
+			for (i = vop_i; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+
+			/* We attain volts[1 ~ (vop_i - 1)] by interpolate */
+			for (i = 1; i < vop_i; i++)
+				svsb->volts[i] =
+					interpolate(svsb->freqs_pct[0],
+						    svsb->freqs_pct[vop_i],
+						    svsb->volts[0],
+						    svsb->volts[vop_i],
+						    svsb->freqs_pct[i]);
+		} else if (svsb->type == SVSB_LOW) {
+			/* We attain volts[turn_pt ~ (opp_count - 1)] */
+			for (i = turn_pt; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				vop = (shift_byte < reg_4bytes) ? &vop30 :
+								  &vop74;
+				svsb->volts[i] = (*vop >> b_sft) & mask7_0;
+				shift_byte++;
+			}
+		}
+	}
+
+	if (svsb->volt_flags & SVSB_INIT02_RM_DVTFIXED) {
+		if (svsb->type == SVSB_HIGH) {
+			opp_start = 0;
+			opp_stop = svsb->turn_pt;
+		} else if (svsb->type == SVSB_LOW) {
+			opp_start = svsb->turn_pt;
+			opp_stop = svsb->opp_count;
+		}
+
+		for (i = opp_start; i < opp_stop; i++)
+			svsb->volts[i] -= svsb->dvt_fixed;
+	}
+}
+
+static void svs_set_freqs_pct_v3(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 i, freq_i, *freq_pct, freq_pct74 = 0;
+	u32 freq_pct30 = svsb->freqs_pct[0];
+	u32 b_sft, bits8 = 8, shift_byte = 0, reg_4bytes = 4;
+	u32 middle_index = (svsb->opp_count / 2);
+	u32 turn_pt = middle_index;
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		if (svsb->opp_freqs[i] <= svsb->turn_freq_base) {
+			svsb->turn_pt = i;
+			break;
+		}
+	}
+
+	turn_pt = svsb->turn_pt;
+
+	/* Target is to fill out freq_pct74 / freq_pct30 */
+	if (turn_pt < middle_index) {
+		if (svsb->type == SVSB_HIGH) {
+			/* We select freqs_pct[0 ~ (turn_pt - 1)] */
+			for (i = 0; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/*
+			 * We select freqs_pct[turn_pt] +
+			 * freqs_pct[(opp_count - 7) ~ (opp_count -1)]
+			 */
+			freq_pct30 = svsb->freqs_pct[turn_pt];
+			shift_byte++;
+			freq_i = svsb->opp_count - 7;
+			for (i = freq_i; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		}
+	} else {
+		if (svsb->type == SVSB_HIGH) {
+			/*
+			 * We select freqs_pct[0] +
+			 * freqs_pct[(turn_pt - 7) ~ (turn_pt - 1)]
+			 */
+			freq_pct30 = svsb->freqs_pct[0];
+			shift_byte++;
+			freq_i = turn_pt - 7;
+			for (i = freq_i; i < turn_pt; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		} else if (svsb->type == SVSB_LOW) {
+			/* We select freqs_pct[turn_pt ~ (opp_count - 1)] */
+			for (i = turn_pt; i < svsb->opp_count; i++) {
+				b_sft = bits8 * (shift_byte % reg_4bytes);
+				freq_pct = (shift_byte < reg_4bytes) ?
+					   &freq_pct30 : &freq_pct74;
+				*freq_pct |= (svsb->freqs_pct[i] << b_sft);
+				shift_byte++;
+			}
+		}
+	}
+
+	svs_writel(svsp, freq_pct74, FREQPCT74);
+	svs_writel(svsp, freq_pct30, FREQPCT30);
+}
+
 static void svs_get_vops_v2(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
@@ -868,6 +1108,25 @@ static int svs_init02(struct svs_platform *svsp)
 		}
 	}
 
+	/*
+	 * 2-line high/low bank update its corresponding opp voltages only.
+	 * Therefore, we sync voltages from opp for high/low bank voltages
+	 * consistency.
+	 */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT02))
+			continue;
+
+		if (svsb->type == SVSB_HIGH || svsb->type == SVSB_LOW) {
+			if (svs_sync_bank_volts_from_opp(svsb)) {
+				dev_err(svsb->dev, "sync volt fail\n");
+				return -EPERM;
+			}
+		}
+	}
+
 	return 0;
 }
 
@@ -1114,7 +1373,12 @@ static int svs_resource_setup(struct svs_platform *svsp)
 			svsb->name = "SVSB_CCI";
 			break;
 		case SVSB_GPU:
-			svsb->name = "SVSB_GPU";
+			if (svsb->type == SVSB_HIGH)
+				svsb->name = "SVSB_GPU_HIGH";
+			else if (svsb->type == SVSB_LOW)
+				svsb->name = "SVSB_GPU_LOW";
+			else
+				svsb->name = "SVSB_GPU";
 			break;
 		default:
 			WARN_ON(1);
@@ -1176,6 +1440,88 @@ static int svs_resource_setup(struct svs_platform *svsp)
 	return 0;
 }
 
+static bool svs_mt8192_efuse_parsing(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct nvmem_cell *cell;
+	u32 idx, i, ft_pgm, vmin, golden_temp;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse[i])
+			dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+				 i, svsp->efuse[i]);
+
+	/* Svs efuse parsing */
+	ft_pgm = svsp->efuse[0] & GENMASK(7, 0);
+	vmin = (svsp->efuse[19] >> 4) & GENMASK(1, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->sw_id != SVSB_GPU)
+			return false;
+
+		if (vmin == 0x1)
+			svsb->vmin = 0x1e;
+
+		if (ft_pgm == 0)
+			svsb->volt_flags |= SVSB_INIT01_VOLT_IGNORE;
+
+		if (svsb->type == SVSB_LOW) {
+			svsb->mtdes = svsp->efuse[10] & GENMASK(7, 0);
+			svsb->bdes = (svsp->efuse[10] >> 16) & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[10] >> 24) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[17]) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[17] >> 8) & GENMASK(7, 0);
+			svsb->vmax += svsb->dvt_fixed;
+		} else if (svsb->type == SVSB_HIGH) {
+			svsb->mtdes = svsp->efuse[9] & GENMASK(7, 0);
+			svsb->bdes = (svsp->efuse[9] >> 16) & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[9] >> 24) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[17] >> 24) & GENMASK(7, 0);
+			svsb->vmax += svsb->dvt_fixed;
+		}
+	}
+
+	/* Thermal efuse parsing */
+	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev, "no thermal cell, no mon mode\n");
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_num);
+	svsp->tefuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	for (i = 0; i < svsp->tefuse_num; i++)
+		if (svsp->tefuse[i] != 0)
+			break;
+
+	if (i == svsp->tefuse_num)
+		golden_temp = 50; /* All thermal efuse data are 0 */
+	else
+		golden_temp = (svsp->tefuse[0] >> 24) & GENMASK(7, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->sw_id != SVSB_GPU)
+			return false;
+
+		svsb->mts = 500;
+		svsb->bts = (((500 * golden_temp + 250460) / 1000) - 25) * 4;
+	}
+
+	return true;
+}
+
 static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
 {
 	struct thermal_parameter tp;
@@ -1598,10 +1944,11 @@ static int svs_status_debug_show(struct seq_file *m, void *v)
 
 	ret = svs_get_bank_zone_temperature(svsb->tzone_name, &tzone_temp);
 	if (ret)
-		seq_printf(m, "%s: no \"%s\" zone?\n", svsb->name,
-			   svsb->tzone_name);
+		seq_printf(m, "%s: no \"%s\" zone? turn_pt = %u\n",
+			   svsb->name, svsb->tzone_name, svsb->turn_pt);
 	else
-		seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+		seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
+			   svsb->name, tzone_temp, svsb->turn_pt);
 
 	for (i = 0; i < svsb->opp_count; i++) {
 		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
@@ -1734,6 +2081,89 @@ static int svs_create_svs_debug_cmds(struct svs_platform *svsp)
 	return 0;
 }
 
+static struct svs_bank svs_mt8192_banks[] = {
+	{
+		.sw_id			= SVSB_GPU,
+		.set_freqs_pct		= svs_set_freqs_pct_v3,
+		.get_vops		= svs_get_vops_v3,
+		.hw_id			= 0,
+		.tzone_name		= "gpu1",
+		.buck_name		= "mali",
+		.volt_flags		= SVSB_INIT02_RM_DVTFIXED |
+					  SVSB_MON_VOLT_IGNORE,
+		.mode_support		= SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 688000000,
+		.turn_freq_base		= 688000000,
+		.vboot			= 0x38,
+		.volt_step		= 6250,
+		.volt_base		= 400000,
+		.volt_offset		= 0,
+		.vmax			= 0x60,
+		.vmin			= 0x1a,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x1,
+		.dvt_fixed		= 0x1,
+		.vco			= 0x18,
+		.chk_shift		= 0x87,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= 85000,
+		.tzone_high_temp_offset	= 0,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 7,
+		.core_sel		= 0x0fff0100,
+		.int_st			= BIT(0),
+		.ctl0			= 0x00540003,
+		.type			= SVSB_LOW,
+	},
+	{
+		.sw_id			= SVSB_GPU,
+		.set_freqs_pct		= svs_set_freqs_pct_v3,
+		.get_vops		= svs_get_vops_v3,
+		.hw_id			= 1,
+		.tzone_name		= "gpu1",
+		.buck_name		= "mali",
+		.volt_flags		= SVSB_INIT02_RM_DVTFIXED |
+					  SVSB_MON_VOLT_IGNORE,
+		.mode_support		= SVSB_MODE_INIT02 | SVSB_MODE_MON,
+		.opp_count		= 16,
+		.freq_base		= 902000000,
+		.turn_freq_base		= 688000000,
+		.vboot			= 0x38,
+		.volt_step		= 6250,
+		.volt_base		= 400000,
+		.volt_offset		= 0,
+		.vmax			= 0x60,
+		.vmin			= 0x1a,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x1,
+		.dvt_fixed		= 0x6,
+		.vco			= 0x18,
+		.chk_shift		= 0x87,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= 85000,
+		.tzone_high_temp_offset	= 0,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 7,
+		.core_sel		= 0x0fff0101,
+		.int_st			= BIT(1),
+		.ctl0			= 0x00540003,
+		.type			= SVSB_HIGH,
+	},
+};
+
 static struct svs_bank svs_mt8183_banks[] = {
 	{
 		.sw_id			= SVSB_CPU_LITTLE,
@@ -1888,6 +2318,46 @@ static struct svs_bank svs_mt8183_banks[] = {
 	},
 };
 
+static int svs_get_svs_mt8192_platform_data(struct svs_platform *svsp)
+{
+	struct device *dev;
+	struct svs_bank *svsb;
+	u32 idx;
+
+	svsp->name = "mt8192-svs";
+	svsp->banks = svs_mt8192_banks;
+	svsp->efuse_parsing = svs_mt8192_efuse_parsing;
+	svsp->regs = svs_regs_v2;
+	svsp->irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+	svsp->bank_num = ARRAY_SIZE(svs_mt8192_banks);
+	svsp->efuse_check = 9;
+
+	svsp->rst = devm_reset_control_get_optional(svsp->dev, "svs_rst");
+	if (IS_ERR(svsp->rst)) {
+		dev_err_probe(svsp->dev, PTR_ERR(svsp->rst),
+			      "cannot get svs reset control\n");
+		return PTR_ERR(svsp->rst);
+	}
+
+	dev = svs_add_device_link(svsp, "lvts");
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (svsb->type == SVSB_HIGH)
+			svsb->opp_dev = svs_add_device_link(svsp, "mali");
+		else if (svsb->type == SVSB_LOW)
+			svsb->opp_dev = svs_get_subsys_device(svsp, "mali");
+
+		if (IS_ERR(svsb->opp_dev))
+			return PTR_ERR(svsb->opp_dev);
+	}
+
+	return 0;
+}
+
 static int svs_get_svs_mt8183_platform_data(struct svs_platform *svsp)
 {
 	struct device *dev;
@@ -1941,6 +2411,9 @@ static const struct of_device_id mtk_svs_of_match[] = {
 	{
 		.compatible = "mediatek,mt8183-svs",
 		.data = &svs_get_svs_mt8183_platform_data,
+	}, {
+		.compatible = "mediatek,mt8192-svs",
+		.data = &svs_get_svs_mt8192_platform_data,
 	}, {
 		/* Sentinel */
 	},
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:36 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:36 +0800
Subject: [PATCH v16 3/7] soc: mediatek: SVS: introduce MTK SVS engine
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-4-roger.lu@mediatek.com>

The Smart Voltage Scaling(SVS) engine is a piece of hardware
which calculates suitable SVS bank voltages to OPP voltage table.
Then, DVFS driver could apply those SVS bank voltages to PMIC/Buck
when receiving OPP_EVENT_ADJUST_VOLTAGE.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/Kconfig   |   10 +
 drivers/soc/mediatek/Makefile  |    1 +
 drivers/soc/mediatek/mtk-svs.c | 1723 ++++++++++++++++++++++++++++++++
 3 files changed, 1734 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-svs.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index fdd8bc08569e..3c3eedea35f7 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -73,4 +73,14 @@ config MTK_MMSYS
 	  Say yes here to add support for the MediaTek Multimedia
 	  Subsystem (MMSYS).
 
+config MTK_SVS
+	tristate "MediaTek Smart Voltage Scaling(SVS)"
+	depends on MTK_EFUSE && NVMEM
+	help
+	  The Smart Voltage Scaling(SVS) engine is a piece of hardware
+	  which has several controllers(banks) for calculating suitable
+	  voltage to different power domains(CPU/GPU/CCI) according to
+	  chip process corner, temperatures and other factors. Then DVFS
+	  driver could apply SVS bank voltage to PMIC/Buck.
+
 endmenu
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 90270f8114ed..0e9e703c931a 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
 obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mutex.o
+obj-$(CONFIG_MTK_SVS) += mtk-svs.o
diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
new file mode 100644
index 000000000000..2d2153c92373
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -0,0 +1,1723 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_opp.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/thermal.h>
+
+/* svs bank 1-line sw id */
+#define SVSB_CPU_LITTLE			BIT(0)
+#define SVSB_CPU_BIG			BIT(1)
+#define SVSB_CCI			BIT(2)
+#define SVSB_GPU			BIT(3)
+
+/* svs bank mode support */
+#define SVSB_MODE_ALL_DISABLE		0
+#define SVSB_MODE_INIT01		BIT(1)
+#define SVSB_MODE_INIT02		BIT(2)
+#define SVSB_MODE_MON			BIT(3)
+
+/* svs bank volt flags */
+#define SVSB_INIT01_VOLT_IGNORE		BIT(1)
+#define SVSB_INIT01_VOLT_INC_ONLY	BIT(2)
+#define SVSB_INIT02_RM_DVTFIXED		BIT(8)
+#define SVSB_MON_VOLT_IGNORE		BIT(16)
+
+/* svs bank common setting */
+#define SVSB_DET_CLK_EN			BIT(31)
+#define SVSB_TZONE_HIGH_TEMP_MAX	U32_MAX
+#define SVSB_RUNCONFIG_DEFAULT		0x80000000
+#define SVSB_DC_SIGNED_BIT		0x8000
+#define SVSB_INTEN_INIT0x		0x00005f01
+#define SVSB_INTEN_MONVOPEN		0x00ff0000
+#define SVSB_EN_OFF			0x0
+#define SVSB_EN_MASK			0x7
+#define SVSB_EN_INIT01			0x1
+#define SVSB_EN_INIT02			0x5
+#define SVSB_EN_MON			0x2
+#define SVSB_INTSTS_MONVOP		0x00ff0000
+#define SVSB_INTSTS_COMPLETE		0x1
+#define SVSB_INTSTS_CLEAN		0x00ffffff
+
+static DEFINE_SPINLOCK(mtk_svs_lock);
+
+/*
+ * enum svsb_phase - svs bank phase enumeration
+ * @SVSB_PHASE_INIT01: basic init for svs bank
+ * @SVSB_PHASE_INIT02: svs bank can provide voltages
+ * @SVSB_PHASE_MON: svs bank can provide voltages with thermal effect
+ * @SVSB_PHASE_ERROR: svs bank encounters unexpected condition
+ *
+ * Each svs bank has its own independent phase. We enable each svs bank by
+ * running their phase orderly. However, When svs bank encounters unexpected
+ * condition, it will fire an irq (PHASE_ERROR) to inform svs software.
+ *
+ * svs bank general phase-enabled order:
+ * SVSB_PHASE_INIT01 -> SVSB_PHASE_INIT02 -> SVSB_PHASE_MON
+ */
+enum svsb_phase {
+	SVSB_PHASE_ERROR = 0,
+	SVSB_PHASE_INIT01,
+	SVSB_PHASE_INIT02,
+	SVSB_PHASE_MON,
+};
+
+enum svs_reg_index {
+	DESCHAR = 0,
+	TEMPCHAR,
+	DETCHAR,
+	AGECHAR,
+	DCCONFIG,
+	AGECONFIG,
+	FREQPCT30,
+	FREQPCT74,
+	LIMITVALS,
+	VBOOT,
+	DETWINDOW,
+	CONFIG,
+	TSCALCS,
+	RUNCONFIG,
+	SVSEN,
+	INIT2VALS,
+	DCVALUES,
+	AGEVALUES,
+	VOP30,
+	VOP74,
+	TEMP,
+	INTSTS,
+	INTSTSRAW,
+	INTEN,
+	CHKINT,
+	CHKSHIFT,
+	STATUS,
+	VDESIGN30,
+	VDESIGN74,
+	DVT30,
+	DVT74,
+	AGECOUNT,
+	SMSTATE0,
+	SMSTATE1,
+	CTL0,
+	DESDETSEC,
+	TEMPAGESEC,
+	CTRLSPARE0,
+	CTRLSPARE1,
+	CTRLSPARE2,
+	CTRLSPARE3,
+	CORESEL,
+	THERMINTST,
+	INTST,
+	THSTAGE0ST,
+	THSTAGE1ST,
+	THSTAGE2ST,
+	THAHBST0,
+	THAHBST1,
+	SPARE0,
+	SPARE1,
+	SPARE2,
+	SPARE3,
+	THSLPEVEB,
+};
+
+static const u32 svs_regs_v2[] = {
+	[DESCHAR]		= 0xc00,
+	[TEMPCHAR]		= 0xc04,
+	[DETCHAR]		= 0xc08,
+	[AGECHAR]		= 0xc0c,
+	[DCCONFIG]		= 0xc10,
+	[AGECONFIG]		= 0xc14,
+	[FREQPCT30]		= 0xc18,
+	[FREQPCT74]		= 0xc1c,
+	[LIMITVALS]		= 0xc20,
+	[VBOOT]			= 0xc24,
+	[DETWINDOW]		= 0xc28,
+	[CONFIG]		= 0xc2c,
+	[TSCALCS]		= 0xc30,
+	[RUNCONFIG]		= 0xc34,
+	[SVSEN]			= 0xc38,
+	[INIT2VALS]		= 0xc3c,
+	[DCVALUES]		= 0xc40,
+	[AGEVALUES]		= 0xc44,
+	[VOP30]			= 0xc48,
+	[VOP74]			= 0xc4c,
+	[TEMP]			= 0xc50,
+	[INTSTS]		= 0xc54,
+	[INTSTSRAW]		= 0xc58,
+	[INTEN]			= 0xc5c,
+	[CHKINT]		= 0xc60,
+	[CHKSHIFT]		= 0xc64,
+	[STATUS]		= 0xc68,
+	[VDESIGN30]		= 0xc6c,
+	[VDESIGN74]		= 0xc70,
+	[DVT30]			= 0xc74,
+	[DVT74]			= 0xc78,
+	[AGECOUNT]		= 0xc7c,
+	[SMSTATE0]		= 0xc80,
+	[SMSTATE1]		= 0xc84,
+	[CTL0]			= 0xc88,
+	[DESDETSEC]		= 0xce0,
+	[TEMPAGESEC]		= 0xce4,
+	[CTRLSPARE0]		= 0xcf0,
+	[CTRLSPARE1]		= 0xcf4,
+	[CTRLSPARE2]		= 0xcf8,
+	[CTRLSPARE3]		= 0xcfc,
+	[CORESEL]		= 0xf00,
+	[THERMINTST]		= 0xf04,
+	[INTST]			= 0xf08,
+	[THSTAGE0ST]		= 0xf0c,
+	[THSTAGE1ST]		= 0xf10,
+	[THSTAGE2ST]		= 0xf14,
+	[THAHBST0]		= 0xf18,
+	[THAHBST1]		= 0xf1c,
+	[SPARE0]		= 0xf20,
+	[SPARE1]		= 0xf24,
+	[SPARE2]		= 0xf28,
+	[SPARE3]		= 0xf2c,
+	[THSLPEVEB]		= 0xf30,
+};
+
+/*
+ * struct thermal_parameter - This is for storing thermal efuse data.
+ * We calculate thermal efuse data to produce "mts" and "bts" for
+ * svs bank mon mode.
+ */
+struct thermal_parameter {
+	int adc_ge_t;
+	int adc_oe_t;
+	int ge;
+	int oe;
+	int gain;
+	int o_vtsabb;
+	int o_vtsmcu1;
+	int o_vtsmcu2;
+	int o_vtsmcu3;
+	int o_vtsmcu4;
+	int o_vtsmcu5;
+	int degc_cali;
+	int adc_cali_en_t;
+	int o_slope;
+	int o_slope_sign;
+	int ts_id;
+};
+
+/*
+ * struct svs_platform - svs platform data
+ * @dev: svs platform device
+ * @base: svs platform register address base
+ * @main_clk: main clock for svs bank
+ * @pbank: phandle of svs bank and needs to be protected by spin_lock
+ * @banks: phandle of the banks that support
+ * @efuse_parsing: phandle of efuse parsing function
+ * @irqflags: irq settings flags
+ * @rst: svs reset control
+ * @regs: phandle to the registers map
+ * @efuse_num: the total number of svs platform efuse
+ * @tefuse_num: the total number of thermal efuse
+ * @bank_num: the total number of banks
+ * @efuse_check: the svs efuse check index
+ * @efuse: svs platform efuse data received from NVMEM framework
+ * @tefuse: thermal efuse data received from NVMEM framework
+ * @name: svs platform name
+ */
+struct svs_platform {
+	struct device *dev;
+	void __iomem *base;
+	struct clk *main_clk;
+	struct svs_bank *pbank;
+	struct svs_bank *banks;
+	bool (*efuse_parsing)(struct svs_platform *svsp);
+	unsigned long irqflags;
+	struct reset_control *rst;
+	const u32 *regs;
+	char *name;
+	size_t efuse_num;
+	size_t tefuse_num;
+	u32 bank_num;
+	u32 efuse_check;
+	u32 *efuse;
+	u32 *tefuse;
+};
+
+/*
+ * struct svs_bank - svs bank representation
+ * @dev: svs bank device
+ * @opp_dev: device for opp table/buck control
+ * @pd_dev: power domain device for SoC mtcmos control
+ * @init_completion: the timeout completion for bank init
+ * @buck: phandle of the regulator
+ * @lock: mutex lock to protect voltage update process
+ * @phase: bank current phase
+ * @name: bank name
+ * @tzone_name: thermal zone name
+ * @buck_name: regulator name
+ * @suspended: suspend flag of this bank
+ * @pd_req: bank's power-domain on request
+ * @enable_pm_runtime_ever: bank enables pm-runtime flag
+ * @set_freqs_pct: phandle of set frequencies percent function
+ * @get_vops: phandle of get bank voltages function
+ * @volt_offset: bank voltage offset controlled by svs software
+ * @mode_support: bank mode support.
+ * @opp_freqs: signed-off frequencies from default opp table
+ * @opp_volts: signed-off voltages from default opp table
+ * @freqs_pct: percent of "opp_freqs / freq_base" for bank init
+ * @volts: bank voltages
+ * @freq_base: reference frequency for bank init
+ * @vboot: voltage request for bank init01 stage only
+ * @volt_step: bank voltage step
+ * @volt_base: bank voltage base
+ * @volt_flags: bank voltage flags
+ * @vmax: bank voltage maximum
+ * @vmin: bank voltage minimum
+ * @temp: bank temperature
+ * @temp_upper_bound: bank temperature upper bound
+ * @temp_lower_bound: bank temperature lower bound
+ * @tzone_high_temp: thermal zone high temperature threshold
+ * @tzone_high_temp_offset: thermal zone high temperature offset
+ * @tzone_low_temp: thermal zone low temperature threshold
+ * @tzone_low_temp_offset: thermal zone low temperature offset
+ * @core_sel: bank selection
+ * @opp_count: bank opp count
+ * @int_st: bank interrupt identification
+ * @sw_id: bank software identification
+ * @ctl0: bank thermal sensor selection
+ * @cpu_id: cpu core id for SVS CPU only
+ *
+ * Other structure members which are not listed above are svs platform
+ * efuse data for bank init
+ */
+struct svs_bank {
+	struct device *dev;
+	struct device *opp_dev;
+	struct device *pd_dev;
+	struct completion init_completion;
+	struct regulator *buck;
+	struct mutex lock;	/* lock to protect voltage update process */
+	enum svsb_phase phase;
+	char *name;
+	char *tzone_name;
+	char *buck_name;
+	bool suspended;
+	bool pd_req;
+	bool enable_pm_runtime_ever;
+	void (*set_freqs_pct)(struct svs_platform *svsp);
+	void (*get_vops)(struct svs_platform *svsp);
+	s32 volt_offset;
+	u32 mode_support;
+	u32 opp_freqs[16];
+	u32 opp_volts[16];
+	u32 freqs_pct[16];
+	u32 volts[16];
+	u32 freq_base;
+	u32 vboot;
+	u32 volt_step;
+	u32 volt_base;
+	u32 volt_flags;
+	u32 vmax;
+	u32 vmin;
+	u32 bts;
+	u32 mts;
+	u32 bdes;
+	u32 mdes;
+	u32 mtdes;
+	u32 dcbdet;
+	u32 dcmdet;
+	u32 dthi;
+	u32 dtlo;
+	u32 det_window;
+	u32 det_max;
+	u32 age_config;
+	u32 age_voffset_in;
+	u32 agem;
+	u32 dc_config;
+	u32 dc_voffset_in;
+	u32 dvt_fixed;
+	u32 vco;
+	u32 chk_shift;
+	u32 temp;
+	u32 temp_upper_bound;
+	u32 temp_lower_bound;
+	u32 tzone_high_temp;
+	u32 tzone_high_temp_offset;
+	u32 tzone_low_temp;
+	u32 tzone_low_temp_offset;
+	u32 core_sel;
+	u32 opp_count;
+	u32 int_st;
+	u32 sw_id;
+	u32 ctl0;
+	u32 cpu_id;
+};
+
+static u32 percent(u32 numerator, u32 denominator)
+{
+	/* If not divide 1000, "numerator * 100" will have data overflow. */
+	numerator /= 1000;
+	denominator /= 1000;
+
+	return DIV_ROUND_UP(numerator * 100, denominator);
+}
+
+static u32 svs_readl(struct svs_platform *svsp, enum svs_reg_index rg_i)
+{
+	return readl(svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_writel(struct svs_platform *svsp, u32 val,
+		       enum svs_reg_index rg_i)
+{
+	writel(val, svsp->base + svsp->regs[rg_i]);
+}
+
+static void svs_switch_bank(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svs_writel(svsp, svsb->core_sel, CORESEL);
+}
+
+static u32 svs_bank_volt_to_opp_volt(u32 svsb_volt, u32 svsb_volt_step,
+				     u32 svsb_volt_base)
+{
+	return (svsb_volt * svsb_volt_step) + svsb_volt_base;
+}
+
+static int svs_get_bank_zone_temperature(const char *tzone_name,
+					 int *tzone_temp)
+{
+	struct thermal_zone_device *tzd;
+
+	tzd = thermal_zone_get_zone_by_name(tzone_name);
+	if (IS_ERR(tzd))
+		return PTR_ERR(tzd);
+
+	return thermal_zone_get_temp(tzd, tzone_temp);
+}
+
+static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
+{
+	int tzone_temp = 0, ret = -EPERM;
+	u32 i, svsb_volt, opp_volt, temp_offset = 0;
+
+	mutex_lock(&svsb->lock);
+
+	/*
+	 * If svs bank is suspended, it means signed-off voltages are applied.
+	 * Don't need to update opp voltage anymore.
+	 */
+	if (svsb->suspended && !force_update) {
+		dev_notice(svsb->dev, "bank is suspended\n");
+		ret = -EPERM;
+		goto unlock_mutex;
+	}
+
+	/* Get thermal effect */
+	if (svsb->phase == SVSB_PHASE_MON) {
+		if (svsb->temp > svsb->temp_upper_bound &&
+		    svsb->temp < svsb->temp_lower_bound) {
+			dev_warn(svsb->dev, "svsb temp = 0x%x?\n", svsb->temp);
+			ret = -EINVAL;
+			goto unlock_mutex;
+		}
+
+		ret = svs_get_bank_zone_temperature(svsb->tzone_name,
+						    &tzone_temp);
+		if (ret) {
+			dev_err(svsb->dev, "no %s? (%d), run default volts\n",
+				svsb->tzone_name, ret);
+			svsb->phase = SVSB_PHASE_ERROR;
+		}
+
+		if (tzone_temp >= svsb->tzone_high_temp)
+			temp_offset += svsb->tzone_high_temp_offset;
+		else if (tzone_temp <= svsb->tzone_low_temp)
+			temp_offset += svsb->tzone_low_temp_offset;
+	}
+
+	/* vmin <= svsb_volt (opp_volt) <= signed-off (default) voltage */
+	for (i = 0; i < svsb->opp_count; i++) {
+		if (svsb->phase == SVSB_PHASE_MON) {
+			svsb_volt = max(svsb->volts[i] + svsb->volt_offset +
+					temp_offset, svsb->vmin);
+			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+							     svsb->volt_step,
+							     svsb->volt_base);
+		} else if (svsb->phase == SVSB_PHASE_INIT02) {
+			svsb_volt = max(svsb->volts[i] + svsb->volt_offset,
+					svsb->vmin);
+			opp_volt = svs_bank_volt_to_opp_volt(svsb_volt,
+							     svsb->volt_step,
+							     svsb->volt_base);
+		} else if (svsb->phase == SVSB_PHASE_ERROR) {
+			opp_volt = svsb->opp_volts[i];
+		} else {
+			dev_err(svsb->dev, "unknown phase: %u?\n", svsb->phase);
+			ret = -EINVAL;
+			goto unlock_mutex;
+		}
+
+		opp_volt = min(opp_volt, svsb->opp_volts[i]);
+		ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+						svsb->opp_freqs[i],
+						opp_volt, opp_volt,
+						svsb->opp_volts[i]);
+		if (ret) {
+			dev_err(svsb->dev, "set voltage fail: %d\n", ret);
+			goto unlock_mutex;
+		}
+	}
+
+unlock_mutex:
+	mutex_unlock(&svsb->lock);
+
+	return ret;
+}
+
+static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1, u32 fx)
+{
+	u32 vx;
+
+	if (v0 == v1 || f0 == f1)
+		return v0;
+
+	/* *100 to have decimal fraction factor */
+	vx = (v0 * 100) - ((((v0 - v1) * 100) / (f0 - f1)) * (f0 - fx));
+
+	return DIV_ROUND_UP(vx, 100);
+}
+
+static void svs_get_vops_v2(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 temp, i;
+
+	if (svsb->phase == SVSB_PHASE_MON &&
+	    svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
+		return;
+
+	temp = svs_readl(svsp, VOP74);
+	svsb->volts[14] = (temp >> 24) & GENMASK(7, 0);
+	svsb->volts[12] = (temp >> 16) & GENMASK(7, 0);
+	svsb->volts[10] = (temp >> 8)  & GENMASK(7, 0);
+	svsb->volts[8] = (temp & GENMASK(7, 0));
+
+	temp = svs_readl(svsp, VOP30);
+	svsb->volts[6] = (temp >> 24) & GENMASK(7, 0);
+	svsb->volts[4] = (temp >> 16) & GENMASK(7, 0);
+	svsb->volts[2] = (temp >> 8)  & GENMASK(7, 0);
+	svsb->volts[0] = (temp & GENMASK(7, 0));
+
+	for (i = 0; i <= 12; i += 2)
+		svsb->volts[i + 1] =
+			interpolate(svsb->freqs_pct[i],
+				    svsb->freqs_pct[i + 2],
+				    svsb->volts[i],
+				    svsb->volts[i + 2],
+				    svsb->freqs_pct[i + 1]);
+
+	svsb->volts[15] =
+		interpolate(svsb->freqs_pct[12],
+			    svsb->freqs_pct[14],
+			    svsb->volts[12],
+			    svsb->volts[14],
+			    svsb->freqs_pct[15]);
+
+	if (svsb->volt_flags & SVSB_INIT02_RM_DVTFIXED)
+		for (i = 0; i < svsb->opp_count; i++)
+			svsb->volts[i] -= svsb->dvt_fixed;
+}
+
+static void svs_set_freqs_pct_v2(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svs_writel(svsp,
+		   (svsb->freqs_pct[14] << 24) |
+		   (svsb->freqs_pct[12] << 16) |
+		   (svsb->freqs_pct[10] << 8) |
+		   svsb->freqs_pct[8],
+		   FREQPCT74);
+
+	svs_writel(svsp,
+		   (svsb->freqs_pct[6] << 24) |
+		   (svsb->freqs_pct[4] << 16) |
+		   (svsb->freqs_pct[2] << 8) |
+		   svsb->freqs_pct[0],
+		   FREQPCT30);
+}
+
+static void svs_set_bank_phase(struct svs_platform *svsp,
+			       enum svsb_phase target_phase)
+{
+	struct svs_bank *svsb = svsp->pbank;
+	u32 des_char, temp_char, det_char, limit_vals;
+	u32 init2vals, ts_calcs, val, filter, i;
+
+	svs_switch_bank(svsp);
+
+	des_char = (svsb->bdes << 8) | svsb->mdes;
+	svs_writel(svsp, des_char, DESCHAR);
+
+	temp_char = (svsb->vco << 16) | (svsb->mtdes << 8) | svsb->dvt_fixed;
+	svs_writel(svsp, temp_char, TEMPCHAR);
+
+	det_char = (svsb->dcbdet << 8) | svsb->dcmdet;
+	svs_writel(svsp, det_char, DETCHAR);
+
+	svs_writel(svsp, svsb->dc_config, DCCONFIG);
+	svs_writel(svsp, svsb->age_config, AGECONFIG);
+
+	if (!svsb->agem) {
+		svs_writel(svsp, SVSB_RUNCONFIG_DEFAULT, RUNCONFIG);
+	} else {
+		val = 0x0;
+
+		for (i = 0; i < 24; i += 2) {
+			filter = 0x3 << i;
+
+			if (!(svsb->age_config & filter))
+				val |= (0x1 << i);
+			else
+				val |= (svsb->age_config & filter);
+		}
+		svs_writel(svsp, val, RUNCONFIG);
+	}
+
+	svsb->set_freqs_pct(svsp);
+
+	limit_vals = (svsb->vmax << 24) | (svsb->vmin << 16) |
+		     (svsb->dthi << 8) | svsb->dtlo;
+	svs_writel(svsp, limit_vals, LIMITVALS);
+	svs_writel(svsp, svsb->vboot, VBOOT);
+	svs_writel(svsp, svsb->det_window, DETWINDOW);
+	svs_writel(svsp, svsb->det_max, CONFIG);
+
+	if (svsb->chk_shift)
+		svs_writel(svsp, svsb->chk_shift, CHKSHIFT);
+
+	if (svsb->ctl0)
+		svs_writel(svsp, svsb->ctl0, CTL0);
+
+	svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+
+	switch (target_phase) {
+	case SVSB_PHASE_INIT01:
+		svs_writel(svsp, SVSB_INTEN_INIT0x, INTEN);
+		svs_writel(svsp, SVSB_EN_INIT01, SVSEN);
+		break;
+	case SVSB_PHASE_INIT02:
+		svs_writel(svsp, SVSB_INTEN_INIT0x, INTEN);
+		init2vals = (svsb->age_voffset_in << 16) | svsb->dc_voffset_in;
+		svs_writel(svsp, init2vals, INIT2VALS);
+		svs_writel(svsp, SVSB_EN_INIT02, SVSEN);
+		break;
+	case SVSB_PHASE_MON:
+		ts_calcs = (svsb->bts << 12) | svsb->mts;
+		svs_writel(svsp, ts_calcs, TSCALCS);
+		svs_writel(svsp, SVSB_INTEN_MONVOPEN, INTEN);
+		svs_writel(svsp, SVSB_EN_MON, SVSEN);
+		break;
+	default:
+		WARN_ON(1);
+		break;
+	}
+}
+
+static inline void svs_init01_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
+		 __func__, svs_readl(svsp, VDESIGN74),
+		 svs_readl(svsp, VDESIGN30), svs_readl(svsp, DCVALUES));
+
+	svsb->phase = SVSB_PHASE_INIT01;
+	svsb->dc_voffset_in = ~(svs_readl(svsp, DCVALUES) & GENMASK(15, 0)) + 1;
+	if (svsb->volt_flags & SVSB_INIT01_VOLT_IGNORE ||
+	    (svsb->dc_voffset_in & SVSB_DC_SIGNED_BIT &&
+	     svsb->volt_flags & SVSB_INIT01_VOLT_INC_ONLY))
+		svsb->dc_voffset_in = 0;
+
+	svsb->age_voffset_in = svs_readl(svsp, AGEVALUES) & GENMASK(15, 0);
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+
+	/* svs init01 clock gating */
+	svsb->core_sel &= ~SVSB_DET_CLK_EN;
+}
+
+static inline void svs_init02_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
+		 __func__, svs_readl(svsp, VOP74), svs_readl(svsp, VOP30),
+		 svs_readl(svsp, DCVALUES));
+
+	svsb->phase = SVSB_PHASE_INIT02;
+	svsb->get_vops(svsp);
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_COMPLETE, INTSTS);
+}
+
+static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	svsb->phase = SVSB_PHASE_MON;
+	svsb->temp = svs_readl(svsp, TEMP) & GENMASK(7, 0);
+	svsb->get_vops(svsp);
+
+	svs_writel(svsp, SVSB_INTSTS_MONVOP, INTSTS);
+}
+
+static inline void svs_error_isr_handler(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb = svsp->pbank;
+
+	dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
+		__func__, svs_readl(svsp, CORESEL));
+	dev_err(svsb->dev, "SVSEN = 0x%08x, INTSTS = 0x%08x\n",
+		svs_readl(svsp, SVSEN), svs_readl(svsp, INTSTS));
+	dev_err(svsb->dev, "SMSTATE0 = 0x%08x, SMSTATE1 = 0x%08x\n",
+		svs_readl(svsp, SMSTATE0), svs_readl(svsp, SMSTATE1));
+	dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl(svsp, TEMP));
+
+	svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+	svsb->phase = SVSB_PHASE_ERROR;
+
+	svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+	svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+}
+
+static irqreturn_t svs_isr(int irq, void *data)
+{
+	struct svs_platform *svsp = data;
+	struct svs_bank *svsb = NULL;
+	unsigned long flags;
+	u32 idx, int_sts, svs_en;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		WARN_ON(!svsb);
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+
+		/* Find out which svs bank fires interrupt */
+		if (svsb->int_st & svs_readl(svsp, INTST)) {
+			spin_unlock_irqrestore(&mtk_svs_lock, flags);
+			continue;
+		}
+
+		if (!svsb->suspended) {
+			svs_switch_bank(svsp);
+			int_sts = svs_readl(svsp, INTSTS);
+			svs_en = svs_readl(svsp, SVSEN) & SVSB_EN_MASK;
+
+			if (int_sts == SVSB_INTSTS_COMPLETE &&
+			    svs_en == SVSB_EN_INIT01)
+				svs_init01_isr_handler(svsp);
+			else if (int_sts == SVSB_INTSTS_COMPLETE &&
+				 svs_en == SVSB_EN_INIT02)
+				svs_init02_isr_handler(svsp);
+			else if (int_sts & SVSB_INTSTS_MONVOP)
+				svs_mon_mode_isr_handler(svsp);
+			else
+				svs_error_isr_handler(svsp);
+		}
+
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+		break;
+	}
+
+	if (svsb->phase != SVSB_PHASE_INIT01)
+		svs_adjust_pm_opp_volts(svsb, false);
+
+	if (svsb->phase == SVSB_PHASE_INIT01 ||
+	    svsb->phase == SVSB_PHASE_INIT02)
+		complete(&svsb->init_completion);
+
+	return IRQ_HANDLED;
+}
+
+static void svs_mon_mode(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	unsigned long flags;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_MON))
+			continue;
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_MON);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+	}
+}
+
+static int svs_init02(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	unsigned long flags, time_left;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT02))
+			continue;
+
+		reinit_completion(&svsb->init_completion);
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_INIT02);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		time_left =
+			wait_for_completion_timeout(&svsb->init_completion,
+						    msecs_to_jiffies(5000));
+		if (!time_left) {
+			dev_err(svsb->dev, "init02 completion timeout\n");
+			return -EBUSY;
+		}
+	}
+
+	return 0;
+}
+
+static int svs_init01(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct pm_qos_request *qos_request;
+	unsigned long flags, time_left;
+	bool search_done;
+	int ret = 0;
+	u32 opp_freqs, opp_vboot, buck_volt, idx, i;
+
+	qos_request = kzalloc(sizeof(*qos_request), GFP_KERNEL);
+	if (!qos_request)
+		return -ENOMEM;
+
+	/* Let CPUs leave idle-off state for initializing svs_init01. */
+	cpu_latency_qos_add_request(qos_request, 0);
+
+	/*
+	 * Sometimes two svs banks use the same buck.
+	 * Therefore, we set each svs bank to vboot voltage first.
+	 */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		search_done = false;
+
+		if (svsb->pd_req) {
+			ret = regulator_enable(svsb->buck);
+			if (ret) {
+				dev_err(svsb->dev, "%s enable fail: %d\n",
+					svsb->buck_name, ret);
+				goto init01_finish;
+			}
+
+			if (!pm_runtime_enabled(svsb->pd_dev)) {
+				pm_runtime_enable(svsb->pd_dev);
+				svsb->enable_pm_runtime_ever = true;
+			}
+
+			ret = pm_runtime_get_sync(svsb->pd_dev);
+			if (ret < 0) {
+				dev_err(svsb->dev, "mtcmos on fail: %d\n", ret);
+				goto init01_finish;
+			}
+		}
+
+		if (regulator_set_mode(svsb->buck, REGULATOR_MODE_FAST))
+			dev_notice(svsb->dev, "set fast mode fail\n");
+
+		/*
+		 * Find the fastest freq that can be run at vboot and
+		 * fix to that freq until svs_init01 is done.
+		 */
+		opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+						      svsb->volt_step,
+						      svsb->volt_base);
+
+		for (i = 0; i < svsb->opp_count; i++) {
+			opp_freqs = svsb->opp_freqs[i];
+			if (!search_done && svsb->opp_volts[i] <= opp_vboot) {
+				ret = dev_pm_opp_adjust_voltage(svsb->opp_dev,
+								opp_freqs,
+								opp_vboot,
+								opp_vboot,
+								opp_vboot);
+				if (ret) {
+					dev_err(svsb->dev,
+						"set voltage fail: %d\n", ret);
+					goto init01_finish;
+				}
+
+				search_done = true;
+			} else {
+				dev_pm_opp_disable(svsb->opp_dev,
+						   svsb->opp_freqs[i]);
+			}
+		}
+	}
+
+	/* svs bank init01 begins */
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		opp_vboot = svs_bank_volt_to_opp_volt(svsb->vboot,
+						      svsb->volt_step,
+						      svsb->volt_base);
+
+		buck_volt = regulator_get_voltage(svsb->buck);
+		if (buck_volt != opp_vboot) {
+			dev_err(svsb->dev,
+				"buck voltage: %u, expected vboot: %u\n",
+				buck_volt, opp_vboot);
+			ret = -EPERM;
+			goto init01_finish;
+		}
+
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_set_bank_phase(svsp, SVSB_PHASE_INIT01);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		time_left =
+			wait_for_completion_timeout(&svsb->init_completion,
+						    msecs_to_jiffies(5000));
+		if (!time_left) {
+			dev_err(svsb->dev, "init01 completion timeout\n");
+			ret = -EBUSY;
+			goto init01_finish;
+		}
+	}
+
+init01_finish:
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (!(svsb->mode_support & SVSB_MODE_INIT01))
+			continue;
+
+		for (i = 0; i < svsb->opp_count; i++)
+			dev_pm_opp_enable(svsb->opp_dev, svsb->opp_freqs[i]);
+
+		if (regulator_set_mode(svsb->buck, REGULATOR_MODE_NORMAL))
+			dev_notice(svsb->dev, "fail to set normal mode\n");
+
+		if (svsb->pd_req) {
+			if (pm_runtime_put_sync(svsb->pd_dev))
+				dev_err(svsb->dev, "mtcmos off fail\n");
+
+			if (svsb->enable_pm_runtime_ever) {
+				pm_runtime_disable(svsb->pd_dev);
+				svsb->enable_pm_runtime_ever = false;
+			}
+
+			if (regulator_disable(svsb->buck))
+				dev_err(svsb->dev, "%s disable fail: %d\n",
+					svsb->buck_name, ret);
+		}
+	}
+
+	cpu_latency_qos_remove_request(qos_request);
+	kfree(qos_request);
+
+	return ret;
+}
+
+static int svs_start(struct svs_platform *svsp)
+{
+	int ret;
+
+	ret = svs_init01(svsp);
+	if (ret)
+		return ret;
+
+	ret = svs_init02(svsp);
+	if (ret)
+		return ret;
+
+	svs_mon_mode(svsp);
+
+	return 0;
+}
+
+static struct device *svs_get_subsys_device(struct svs_platform *svsp,
+					    const char *node_name)
+{
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	np = of_find_node_by_name(NULL, node_name);
+	if (!np) {
+		dev_err(svsp->dev, "cannot find %s node\n", node_name);
+		return ERR_PTR(-ENODEV);
+	}
+
+	pdev = of_find_device_by_node(np);
+	if (!pdev) {
+		of_node_put(np);
+		dev_err(svsp->dev, "cannot find pdev by %s\n", node_name);
+		return ERR_PTR(-ENXIO);
+	}
+
+	of_node_put(np);
+
+	return &pdev->dev;
+}
+
+static struct device *svs_add_device_link(struct svs_platform *svsp,
+					  const char *node_name)
+{
+	struct device *dev;
+	struct device_link *sup_link;
+
+	if (!node_name) {
+		dev_err(svsp->dev, "node name cannot be null\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	dev = svs_get_subsys_device(svsp, node_name);
+	if (IS_ERR(dev))
+		return dev;
+
+	sup_link = device_link_add(svsp->dev, dev,
+				   DL_FLAG_AUTOREMOVE_CONSUMER);
+	if (!sup_link) {
+		dev_err(svsp->dev, "sup_link is NULL\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND)
+		return ERR_PTR(-EPROBE_DEFER);
+
+	return dev;
+}
+
+static int svs_resource_setup(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct dev_pm_opp *opp;
+	unsigned long freq;
+	int count, ret;
+	u32 idx, i;
+
+	dev_set_drvdata(svsp->dev, svsp);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			svsb->name = "SVSB_CPU_LITTLE";
+			break;
+		case SVSB_CPU_BIG:
+			svsb->name = "SVSB_CPU_BIG";
+			break;
+		case SVSB_CCI:
+			svsb->name = "SVSB_CCI";
+			break;
+		case SVSB_GPU:
+			svsb->name = "SVSB_GPU";
+			break;
+		default:
+			WARN_ON(1);
+			return -EINVAL;
+		}
+
+		svsb->dev = devm_kzalloc(svsp->dev, sizeof(*svsb->dev),
+					 GFP_KERNEL);
+		if (!svsb->dev)
+			return -ENOMEM;
+
+		ret = dev_set_name(svsb->dev, "%s", svsb->name);
+		if (ret)
+			return ret;
+
+		dev_set_drvdata(svsb->dev, svsp);
+
+		ret = dev_pm_opp_of_add_table(svsb->opp_dev);
+		if (ret) {
+			dev_err(svsb->dev, "add opp table fail: %d\n", ret);
+			return ret;
+		}
+
+		mutex_init(&svsb->lock);
+		init_completion(&svsb->init_completion);
+
+		svsb->buck = devm_regulator_get_optional(svsb->opp_dev,
+							 svsb->buck_name);
+		if (IS_ERR(svsb->buck)) {
+			dev_err(svsb->dev, "cannot get \"%s-supply\"\n",
+				svsb->buck_name);
+			return PTR_ERR(svsb->buck);
+		}
+
+		count = dev_pm_opp_get_opp_count(svsb->opp_dev);
+		if (svsb->opp_count != count) {
+			dev_err(svsb->dev,
+				"opp_count not \"%u\" but get \"%d\"?\n",
+				svsb->opp_count, count);
+			return count;
+		}
+
+		for (i = 0, freq = U32_MAX; i < svsb->opp_count; i++, freq--) {
+			opp = dev_pm_opp_find_freq_floor(svsb->opp_dev, &freq);
+			if (IS_ERR(opp)) {
+				dev_err(svsb->dev, "cannot find freq = %ld\n",
+					PTR_ERR(opp));
+				return PTR_ERR(opp);
+			}
+
+			svsb->opp_freqs[i] = freq;
+			svsb->opp_volts[i] = dev_pm_opp_get_voltage(opp);
+			svsb->freqs_pct[i] = percent(svsb->opp_freqs[i],
+						     svsb->freq_base);
+			dev_pm_opp_put(opp);
+		}
+	}
+
+	return 0;
+}
+
+static bool svs_mt8183_efuse_parsing(struct svs_platform *svsp)
+{
+	struct thermal_parameter tp;
+	struct svs_bank *svsb;
+	bool mon_mode_support = true;
+	int format[6], x_roomt[6], tb_roomt = 0;
+	struct nvmem_cell *cell;
+	u32 idx, i, ft_pgm, mts, temp0, temp1, temp2;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse[i])
+			dev_info(svsp->dev, "M_HW_RES%d: 0x%08x\n",
+				 i, svsp->efuse[i]);
+
+	/* Svs efuse parsing */
+	ft_pgm = (svsp->efuse[0] >> 4) & GENMASK(3, 0);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		if (ft_pgm <= 1)
+			svsb->volt_flags |= SVSB_INIT01_VOLT_IGNORE;
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			svsb->bdes = svsp->efuse[16] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[16] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[16] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[16] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = (svsp->efuse[17] >> 16) & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 10;
+			else
+				svsb->volt_offset += 2;
+			break;
+		case SVSB_CPU_BIG:
+			svsb->bdes = svsp->efuse[18] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[18] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[18] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[18] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = svsp->efuse[17] & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 15;
+			else
+				svsb->volt_offset += 12;
+			break;
+		case SVSB_CCI:
+			svsb->bdes = svsp->efuse[4] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[4] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[4] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[4] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = (svsp->efuse[5] >> 16) & GENMASK(7, 0);
+
+			if (ft_pgm <= 3)
+				svsb->volt_offset += 10;
+			else
+				svsb->volt_offset += 2;
+			break;
+		case SVSB_GPU:
+			svsb->bdes = svsp->efuse[6] & GENMASK(7, 0);
+			svsb->mdes = (svsp->efuse[6] >> 8) & GENMASK(7, 0);
+			svsb->dcbdet = (svsp->efuse[6] >> 16) & GENMASK(7, 0);
+			svsb->dcmdet = (svsp->efuse[6] >> 24) & GENMASK(7, 0);
+			svsb->mtdes  = svsp->efuse[5] & GENMASK(7, 0);
+
+			if (ft_pgm >= 2) {
+				svsb->freq_base = 800000000; /* 800MHz */
+				svsb->dvt_fixed = 2;
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	/* Get thermal efuse by nvmem */
+	cell = nvmem_cell_get(svsp->dev, "t-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev, "no thermal cell, no mon mode\n");
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	svsp->tefuse = nvmem_cell_read(cell, &svsp->tefuse_num);
+	svsp->tefuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	/* Thermal efuse parsing */
+	tp.adc_ge_t = (svsp->tefuse[1] >> 22) & GENMASK(9, 0);
+	tp.adc_oe_t = (svsp->tefuse[1] >> 12) & GENMASK(9, 0);
+
+	tp.o_vtsmcu1 = (svsp->tefuse[0] >> 17) & GENMASK(8, 0);
+	tp.o_vtsmcu2 = (svsp->tefuse[0] >> 8) & GENMASK(8, 0);
+	tp.o_vtsmcu3 = svsp->tefuse[1] & GENMASK(8, 0);
+	tp.o_vtsmcu4 = (svsp->tefuse[2] >> 23) & GENMASK(8, 0);
+	tp.o_vtsmcu5 = (svsp->tefuse[2] >> 5) & GENMASK(8, 0);
+	tp.o_vtsabb = (svsp->tefuse[2] >> 14) & GENMASK(8, 0);
+
+	tp.degc_cali = (svsp->tefuse[0] >> 1) & GENMASK(5, 0);
+	tp.adc_cali_en_t = svsp->tefuse[0] & BIT(0);
+	tp.o_slope_sign = (svsp->tefuse[0] >> 7) & BIT(0);
+
+	tp.ts_id = (svsp->tefuse[1] >> 9) & BIT(0);
+	tp.o_slope = (svsp->tefuse[0] >> 26) & GENMASK(5, 0);
+
+	if (tp.adc_cali_en_t == 1) {
+		if (!tp.ts_id)
+			tp.o_slope = 0;
+
+		if (tp.adc_ge_t < 265 || tp.adc_ge_t > 758 ||
+		    tp.adc_oe_t < 265 || tp.adc_oe_t > 758 ||
+		    tp.o_vtsmcu1 < -8 || tp.o_vtsmcu1 > 484 ||
+		    tp.o_vtsmcu2 < -8 || tp.o_vtsmcu2 > 484 ||
+		    tp.o_vtsmcu3 < -8 || tp.o_vtsmcu3 > 484 ||
+		    tp.o_vtsmcu4 < -8 || tp.o_vtsmcu4 > 484 ||
+		    tp.o_vtsmcu5 < -8 || tp.o_vtsmcu5 > 484 ||
+		    tp.o_vtsabb < -8 || tp.o_vtsabb > 484 ||
+		    tp.degc_cali < 1 || tp.degc_cali > 63) {
+			dev_err(svsp->dev, "bad thermal efuse, no mon mode\n");
+			mon_mode_support = false;
+		}
+	} else {
+		dev_err(svsp->dev, "no thermal efuse, no mon mode\n");
+		mon_mode_support = false;
+	}
+
+	if (!mon_mode_support) {
+		for (idx = 0; idx < svsp->bank_num; idx++) {
+			svsb = &svsp->banks[idx];
+			svsb->mode_support &= ~SVSB_MODE_MON;
+		}
+
+		return true;
+	}
+
+	tp.ge = ((tp.adc_ge_t - 512) * 10000) / 4096;
+	tp.oe = (tp.adc_oe_t - 512);
+	tp.gain = (10000 + tp.ge);
+
+	format[0] = (tp.o_vtsmcu1 + 3350 - tp.oe);
+	format[1] = (tp.o_vtsmcu2 + 3350 - tp.oe);
+	format[2] = (tp.o_vtsmcu3 + 3350 - tp.oe);
+	format[3] = (tp.o_vtsmcu4 + 3350 - tp.oe);
+	format[4] = (tp.o_vtsmcu5 + 3350 - tp.oe);
+	format[5] = (tp.o_vtsabb + 3350 - tp.oe);
+
+	for (i = 0; i < 6; i++)
+		x_roomt[i] = (((format[i] * 10000) / 4096) * 10000) / tp.gain;
+
+	temp0 = (10000 * 100000 / tp.gain) * 15 / 18;
+
+	if (!tp.o_slope_sign)
+		mts = (temp0 * 10) / (1534 + tp.o_slope * 10);
+	else
+		mts = (temp0 * 10) / (1534 - tp.o_slope * 10);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		svsb->mts = mts;
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+			tb_roomt = x_roomt[3];
+			break;
+		case SVSB_CPU_BIG:
+			tb_roomt = x_roomt[4];
+			break;
+		case SVSB_CCI:
+			tb_roomt = x_roomt[3];
+			break;
+		case SVSB_GPU:
+			tb_roomt = x_roomt[1];
+			break;
+		default:
+			break;
+		}
+
+		temp0 = (tp.degc_cali * 10 / 2);
+		temp1 = ((10000 * 100000 / 4096 / tp.gain) *
+			 tp.oe + tb_roomt * 10) * 15 / 18;
+
+		if (!tp.o_slope_sign)
+			temp2 = temp1 * 100 / (1534 + tp.o_slope * 10);
+		else
+			temp2 = temp1 * 100 / (1534 - tp.o_slope * 10);
+
+		svsb->bts = (temp0 + temp2 - 250) * 4 / 10;
+	}
+
+	return true;
+}
+
+static bool svs_is_supported(struct svs_platform *svsp)
+{
+	struct nvmem_cell *cell;
+
+	/* Get svs efuse by nvmem */
+	cell = nvmem_cell_get(svsp->dev, "svs-calibration-data");
+	if (IS_ERR_OR_NULL(cell)) {
+		dev_err(svsp->dev,
+			"no \"svs-calibration-data\" from dts? disable svs\n");
+		return false;
+	}
+
+	svsp->efuse = nvmem_cell_read(cell, &svsp->efuse_num);
+	svsp->efuse_num /= sizeof(u32);
+	nvmem_cell_put(cell);
+
+	if (!svsp->efuse[svsp->efuse_check]) {
+		dev_err(svsp->dev, "svs_efuse[%u] = 0x%x?\n",
+			svsp->efuse_check, svsp->efuse[svsp->efuse_check]);
+		return false;
+	}
+
+	return svsp->efuse_parsing(svsp);
+}
+
+static int svs_suspend(struct device *dev)
+{
+	struct svs_platform *svsp = dev_get_drvdata(dev);
+	struct svs_bank *svsb;
+	unsigned long flags;
+	int ret;
+	u32 idx;
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		/* Wait if svs_isr() is still in process. */
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svs_switch_bank(svsp);
+		svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+		svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		svsb->suspended = true;
+		if (svsb->phase != SVSB_PHASE_INIT01) {
+			svsb->phase = SVSB_PHASE_ERROR;
+			svs_adjust_pm_opp_volts(svsb, true);
+		}
+	}
+
+	if (svsp->rst) {
+		ret = reset_control_assert(svsp->rst);
+		if (ret) {
+			dev_err(svsp->dev, "cannot assert reset %d\n", ret);
+			return ret;
+		}
+	}
+
+	clk_disable_unprepare(svsp->main_clk);
+
+	return 0;
+}
+
+static int svs_resume(struct device *dev)
+{
+	struct svs_platform *svsp = dev_get_drvdata(dev);
+	struct svs_bank *svsb;
+	int ret;
+	u32 idx;
+
+	ret = clk_prepare_enable(svsp->main_clk);
+	if (ret) {
+		dev_err(svsp->dev, "cannot enable main_clk, disable svs\n");
+		return ret;
+	}
+
+	if (svsp->rst) {
+		ret = reset_control_deassert(svsp->rst);
+		if (ret) {
+			dev_err(svsp->dev, "cannot deassert reset %d\n", ret);
+			return ret;
+		}
+	}
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+		svsb->suspended = false;
+	}
+
+	ret = svs_init02(svsp);
+	if (ret)
+		return ret;
+
+	svs_mon_mode(svsp);
+
+	return 0;
+}
+
+static struct svs_bank svs_mt8183_banks[] = {
+	{
+		.sw_id			= SVSB_CPU_LITTLE,
+		.set_freqs_pct		= svs_set_freqs_pct_v2,
+		.get_vops		= svs_get_vops_v2,
+		.cpu_id			= 0,
+		.tzone_name		= "tzts4",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.volt_flags		= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1989000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x64,
+		.vmin			= 0x18,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0000,
+		.int_st			= BIT(0),
+		.ctl0			= 0x00010001,
+	},
+	{
+		.sw_id			= SVSB_CPU_BIG,
+		.set_freqs_pct		= svs_set_freqs_pct_v2,
+		.get_vops		= svs_get_vops_v2,
+		.cpu_id			= 4,
+		.tzone_name		= "tzts5",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.volt_flags		= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1989000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x58,
+		.vmin			= 0x10,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0001,
+		.int_st			= BIT(1),
+		.ctl0			= 0x00000001,
+	},
+	{
+		.sw_id			= SVSB_CCI,
+		.set_freqs_pct		= svs_set_freqs_pct_v2,
+		.get_vops		= svs_get_vops_v2,
+		.tzone_name		= "tzts4",
+		.buck_name		= "proc",
+		.pd_req			= false,
+		.volt_flags		= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02,
+		.opp_count		= 16,
+		.freq_base		= 1196000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x64,
+		.vmin			= 0x18,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x7,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 0,
+		.core_sel		= 0x8fff0002,
+		.int_st			= BIT(2),
+		.ctl0			= 0x00100003,
+	},
+	{
+		.sw_id			= SVSB_GPU,
+		.set_freqs_pct		= svs_set_freqs_pct_v2,
+		.get_vops		= svs_get_vops_v2,
+		.tzone_name		= "tzts2",
+		.buck_name		= "mali",
+		.pd_req			= true,
+		.volt_flags		= SVSB_INIT01_VOLT_INC_ONLY,
+		.mode_support		= SVSB_MODE_INIT01 | SVSB_MODE_INIT02 |
+					  SVSB_MODE_MON,
+		.opp_count		= 16,
+		.freq_base		= 900000000,
+		.vboot			= 0x30,
+		.volt_step		= 6250,
+		.volt_base		= 500000,
+		.volt_offset		= 0,
+		.vmax			= 0x40,
+		.vmin			= 0x14,
+		.dthi			= 0x1,
+		.dtlo			= 0xfe,
+		.det_window		= 0xa28,
+		.det_max		= 0xffff,
+		.age_config		= 0x555555,
+		.agem			= 0,
+		.dc_config		= 0x555555,
+		.dvt_fixed		= 0x3,
+		.vco			= 0x10,
+		.chk_shift		= 0x77,
+		.temp_upper_bound	= 0x64,
+		.temp_lower_bound	= 0xb2,
+		.tzone_high_temp	= SVSB_TZONE_HIGH_TEMP_MAX,
+		.tzone_low_temp		= 25000,
+		.tzone_low_temp_offset	= 3,
+		.core_sel		= 0x8fff0003,
+		.int_st			= BIT(3),
+		.ctl0			= 0x00050001,
+	},
+};
+
+static int svs_get_svs_mt8183_platform_data(struct svs_platform *svsp)
+{
+	struct device *dev;
+	struct svs_bank *svsb;
+	u32 idx;
+
+	svsp->name = "mt8183-svs";
+	svsp->banks = svs_mt8183_banks;
+	svsp->efuse_parsing = svs_mt8183_efuse_parsing;
+	svsp->regs = svs_regs_v2;
+	svsp->irqflags = IRQF_TRIGGER_LOW | IRQF_ONESHOT;
+	svsp->rst = NULL;
+	svsp->bank_num = ARRAY_SIZE(svs_mt8183_banks);
+	svsp->efuse_check = 2;
+
+	dev = svs_add_device_link(svsp, "thermal");
+	if (IS_ERR(dev))
+		return PTR_ERR(dev);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		switch (svsb->sw_id) {
+		case SVSB_CPU_LITTLE:
+		case SVSB_CPU_BIG:
+			svsb->opp_dev = get_cpu_device(svsb->cpu_id);
+			break;
+		case SVSB_CCI:
+			svsb->opp_dev = svs_add_device_link(svsp, "cci");
+			break;
+		case SVSB_GPU:
+			svsb->opp_dev = svs_add_device_link(svsp, "mali");
+			svsb->pd_dev = svs_add_device_link(svsp,
+							   "mali_gpu_core2");
+			if (IS_ERR(svsb->pd_dev))
+				return PTR_ERR(svsb->pd_dev);
+			break;
+		default:
+			WARN_ON(1);
+			return -EINVAL;
+		}
+
+		if (IS_ERR(svsb->opp_dev))
+			return PTR_ERR(svsb->opp_dev);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id mtk_svs_of_match[] = {
+	{
+		.compatible = "mediatek,mt8183-svs",
+		.data = &svs_get_svs_mt8183_platform_data,
+	}, {
+		/* Sentinel */
+	},
+};
+
+static int svs_probe(struct platform_device *pdev)
+{
+	int (*svs_get_svs_platform_data)(struct svs_platform *svsp);
+	struct svs_platform *svsp;
+	unsigned int svsp_irq;
+	int ret;
+
+	svsp = devm_kzalloc(&pdev->dev, sizeof(*svsp), GFP_KERNEL);
+	if (!svsp)
+		return -ENOMEM;
+
+	svs_get_svs_platform_data = of_device_get_match_data(&pdev->dev);
+	if (!svs_get_svs_platform_data) {
+		dev_err(svsp->dev, "no svs platform data? why?\n");
+		return -EPERM;
+	}
+
+	svsp->dev = &pdev->dev;
+	ret = svs_get_svs_platform_data(svsp);
+	if (ret) {
+		dev_err_probe(svsp->dev, ret, "fail to get svsp data\n");
+		return ret;
+	}
+
+	if (!svs_is_supported(svsp)) {
+		dev_notice(svsp->dev, "svs is not supported\n");
+		return -EPERM;
+	}
+
+	ret = svs_resource_setup(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs resource setup fail: %d\n", ret);
+		return ret;
+	}
+
+	svsp_irq = irq_of_parse_and_map(svsp->dev->of_node, 0);
+	ret = devm_request_threaded_irq(svsp->dev, svsp_irq, NULL, svs_isr,
+					svsp->irqflags, svsp->name, svsp);
+	if (ret) {
+		dev_err(svsp->dev, "register irq(%d) failed: %d\n",
+			svsp_irq, ret);
+		return ret;
+	}
+
+	svsp->main_clk = devm_clk_get(svsp->dev, "main");
+	if (IS_ERR(svsp->main_clk)) {
+		dev_err(svsp->dev, "failed to get clock: %ld\n",
+			PTR_ERR(svsp->main_clk));
+		return PTR_ERR(svsp->main_clk);
+	}
+
+	ret = clk_prepare_enable(svsp->main_clk);
+	if (ret) {
+		dev_err(svsp->dev, "cannot enable main clk: %d\n", ret);
+		return ret;
+	}
+
+	svsp->base = of_iomap(svsp->dev->of_node, 0);
+	if (IS_ERR_OR_NULL(svsp->base)) {
+		dev_err(svsp->dev, "cannot find svs register base\n");
+		ret = -EINVAL;
+		goto svs_probe_clk_disable;
+	}
+
+	ret = svs_start(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs start fail: %d\n", ret);
+		goto svs_probe_iounmap;
+	}
+
+	return 0;
+
+svs_probe_iounmap:
+	iounmap(svsp->base);
+
+svs_probe_clk_disable:
+	clk_disable_unprepare(svsp->main_clk);
+
+	return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(svs_pm_ops, svs_suspend, svs_resume);
+
+static struct platform_driver svs_driver = {
+	.probe	= svs_probe,
+	.driver	= {
+		.name		= "mtk-svs",
+		.pm		= &svs_pm_ops,
+		.of_match_table	= of_match_ptr(mtk_svs_of_match),
+	},
+};
+
+module_platform_driver(svs_driver);
+
+MODULE_AUTHOR("Roger Lu <roger.lu at mediatek.com>");
+MODULE_DESCRIPTION("MediaTek SVS driver");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:37 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:37 +0800
Subject: [PATCH v16 4/7] soc: mediatek: SVS: add debug commands
In-Reply-To: <20210428065440.3704-1-roger.lu@mediatek.com>
References: <20210428065440.3704-1-roger.lu@mediatek.com>
Message-ID: <20210428065440.3704-5-roger.lu@mediatek.com>

The purpose of SVS is to help find the suitable voltages
for DVFS. Therefore, if SVS bank voltages are concerned
to be wrong, we can adjust SVS bank voltages by this patch.

Signed-off-by: Roger Lu <roger.lu at mediatek.com>
---
 drivers/soc/mediatek/mtk-svs.c | 328 +++++++++++++++++++++++++++++++++
 1 file changed, 328 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
index 2d2153c92373..8794a2d87baa 100644
--- a/drivers/soc/mediatek/mtk-svs.c
+++ b/drivers/soc/mediatek/mtk-svs.c
@@ -6,6 +6,7 @@
 #include <linux/bits.h>
 #include <linux/clk.h>
 #include <linux/completion.h>
+#include <linux/debugfs.h>
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
@@ -24,6 +25,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/regulator/consumer.h>
 #include <linux/reset.h>
+#include <linux/seq_file.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/thermal.h>
@@ -62,6 +64,39 @@
 #define SVSB_INTSTS_COMPLETE		0x1
 #define SVSB_INTSTS_CLEAN		0x00ffffff
 
+#define debug_fops_ro(name)						\
+	static int svs_##name##_debug_open(struct inode *inode,		\
+					   struct file *filp)		\
+	{								\
+		return single_open(filp, svs_##name##_debug_show,	\
+				   inode->i_private);			\
+	}								\
+	static const struct file_operations svs_##name##_debug_fops = {	\
+		.owner = THIS_MODULE,					\
+		.open = svs_##name##_debug_open,			\
+		.read = seq_read,					\
+		.llseek = seq_lseek,					\
+		.release = single_release,				\
+	}
+
+#define debug_fops_rw(name)						\
+	static int svs_##name##_debug_open(struct inode *inode,		\
+					   struct file *filp)		\
+	{								\
+		return single_open(filp, svs_##name##_debug_show,	\
+				   inode->i_private);			\
+	}								\
+	static const struct file_operations svs_##name##_debug_fops = {	\
+		.owner = THIS_MODULE,					\
+		.open = svs_##name##_debug_open,			\
+		.read = seq_read,					\
+		.write = svs_##name##_debug_write,			\
+		.llseek = seq_lseek,					\
+		.release = single_release,				\
+	}
+
+#define svs_dentry(name)	{__stringify(name), &svs_##name##_debug_fops}
+
 static DEFINE_SPINLOCK(mtk_svs_lock);
 
 /*
@@ -83,6 +118,7 @@ enum svsb_phase {
 	SVSB_PHASE_INIT01,
 	SVSB_PHASE_INIT02,
 	SVSB_PHASE_MON,
+	SVSB_PHASE_NUM,
 };
 
 enum svs_reg_index {
@@ -140,6 +176,7 @@ enum svs_reg_index {
 	SPARE2,
 	SPARE3,
 	THSLPEVEB,
+	SVS_REG_NUM,
 };
 
 static const u32 svs_regs_v2[] = {
@@ -284,6 +321,7 @@ struct svs_platform {
  * @opp_volts: signed-off voltages from default opp table
  * @freqs_pct: percent of "opp_freqs / freq_base" for bank init
  * @volts: bank voltages
+ * @reg_data: bank register data of each phase
  * @freq_base: reference frequency for bank init
  * @vboot: voltage request for bank init01 stage only
  * @volt_step: bank voltage step
@@ -302,6 +340,7 @@ struct svs_platform {
  * @opp_count: bank opp count
  * @int_st: bank interrupt identification
  * @sw_id: bank software identification
+ * @hw_id: bank hardware identification
  * @ctl0: bank thermal sensor selection
  * @cpu_id: cpu core id for SVS CPU only
  *
@@ -330,6 +369,7 @@ struct svs_bank {
 	u32 opp_volts[16];
 	u32 freqs_pct[16];
 	u32 volts[16];
+	u32 reg_data[SVSB_PHASE_NUM][SVS_REG_NUM];
 	u32 freq_base;
 	u32 vboot;
 	u32 volt_step;
@@ -367,6 +407,7 @@ struct svs_bank {
 	u32 opp_count;
 	u32 int_st;
 	u32 sw_id;
+	u32 hw_id;
 	u32 ctl0;
 	u32 cpu_id;
 };
@@ -648,11 +689,15 @@ static void svs_set_bank_phase(struct svs_platform *svsp,
 static inline void svs_init01_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_info(svsb->dev, "%s: VDN74~30:0x%08x~0x%08x, DC:0x%08x\n",
 		 __func__, svs_readl(svsp, VDESIGN74),
 		 svs_readl(svsp, VDESIGN30), svs_readl(svsp, DCVALUES));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_INIT01][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->phase = SVSB_PHASE_INIT01;
 	svsb->dc_voffset_in = ~(svs_readl(svsp, DCVALUES) & GENMASK(15, 0)) + 1;
 	if (svsb->volt_flags & SVSB_INIT01_VOLT_IGNORE ||
@@ -672,11 +717,15 @@ static inline void svs_init01_isr_handler(struct svs_platform *svsp)
 static inline void svs_init02_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_info(svsb->dev, "%s: VOP74~30:0x%08x~0x%08x, DC:0x%08x\n",
 		 __func__, svs_readl(svsp, VOP74), svs_readl(svsp, VOP30),
 		 svs_readl(svsp, DCVALUES));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_INIT02][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->phase = SVSB_PHASE_INIT02;
 	svsb->get_vops(svsp);
 
@@ -687,6 +736,10 @@ static inline void svs_init02_isr_handler(struct svs_platform *svsp)
 static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
+
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_MON][rg_i] = svs_readl(svsp, rg_i);
 
 	svsb->phase = SVSB_PHASE_MON;
 	svsb->temp = svs_readl(svsp, TEMP) & GENMASK(7, 0);
@@ -698,6 +751,7 @@ static inline void svs_mon_mode_isr_handler(struct svs_platform *svsp)
 static inline void svs_error_isr_handler(struct svs_platform *svsp)
 {
 	struct svs_bank *svsb = svsp->pbank;
+	enum svs_reg_index rg_i;
 
 	dev_err(svsb->dev, "%s: CORESEL = 0x%08x\n",
 		__func__, svs_readl(svsp, CORESEL));
@@ -707,6 +761,9 @@ static inline void svs_error_isr_handler(struct svs_platform *svsp)
 		svs_readl(svsp, SMSTATE0), svs_readl(svsp, SMSTATE1));
 	dev_err(svsb->dev, "TEMP = 0x%08x\n", svs_readl(svsp, TEMP));
 
+	for (rg_i = DESCHAR; rg_i < SVS_REG_NUM; rg_i++)
+		svsb->reg_data[SVSB_PHASE_ERROR][rg_i] = svs_readl(svsp, rg_i);
+
 	svsb->mode_support = SVSB_MODE_ALL_DISABLE;
 	svsb->phase = SVSB_PHASE_ERROR;
 
@@ -1416,11 +1473,273 @@ static int svs_resume(struct device *dev)
 	return 0;
 }
 
+/*
+ * svs_dump_debug_show - dump svs/thermal efuse and svs banks' registers
+ */
+static int svs_dump_debug_show(struct seq_file *m, void *p)
+{
+	struct svs_platform *svsp = (struct svs_platform *)m->private;
+	struct svs_bank *svsb;
+	unsigned long svs_reg_addr;
+	u32 idx, i, j;
+
+	for (i = 0; i < svsp->efuse_num; i++)
+		if (svsp->efuse && svsp->efuse[i])
+			seq_printf(m, "M_HW_RES%d = 0x%08x\n",
+				   i, svsp->efuse[i]);
+
+	for (i = 0; i < svsp->tefuse_num; i++)
+		if (svsp->tefuse)
+			seq_printf(m, "THERMAL_EFUSE%d = 0x%08x\n",
+				   i, svsp->tefuse[i]);
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		for (i = SVSB_PHASE_INIT01; i <= SVSB_PHASE_MON; i++) {
+			seq_printf(m, "Bank_number = %u\n", svsb->hw_id);
+
+			if (i == SVSB_PHASE_INIT01 || i == SVSB_PHASE_INIT02)
+				seq_printf(m, "mode = init%d\n", i);
+			else if (i == SVSB_PHASE_MON)
+				seq_puts(m, "mode = mon\n");
+			else
+				seq_puts(m, "mode = error\n");
+
+			for (j = DESCHAR; j < SVS_REG_NUM; j++) {
+				svs_reg_addr = (unsigned long)(svsp->base +
+							       svsp->regs[j]);
+				seq_printf(m, "0x%08lx = 0x%08x\n",
+					   svs_reg_addr, svsb->reg_data[i][j]);
+			}
+		}
+	}
+
+	return 0;
+}
+
+debug_fops_ro(dump);
+
+/*
+ * svs_enable_debug_show - show svs bank current enable phase
+ */
+static int svs_enable_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+	if (svsb->phase == SVSB_PHASE_INIT01)
+		seq_puts(m, "init1\n");
+	else if (svsb->phase == SVSB_PHASE_INIT02)
+		seq_puts(m, "init2\n");
+	else if (svsb->phase == SVSB_PHASE_MON)
+		seq_puts(m, "mon mode\n");
+	else if (svsb->phase == SVSB_PHASE_ERROR)
+		seq_puts(m, "disabled\n");
+	else
+		seq_puts(m, "unknown\n");
+
+	return 0;
+}
+
+/*
+ * svs_enable_debug_write - we only support svs bank disable control
+ */
+static ssize_t svs_enable_debug_write(struct file *filp,
+				      const char __user *buffer,
+				      size_t count, loff_t *pos)
+{
+	struct svs_bank *svsb = file_inode(filp)->i_private;
+	struct svs_platform *svsp = dev_get_drvdata(svsb->dev);
+	unsigned long flags;
+	int enabled, ret;
+	char *buf = NULL;
+
+	if (count >= PAGE_SIZE)
+		return -EINVAL;
+
+	buf = (char *)memdup_user_nul(buffer, count);
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	ret = kstrtoint(buf, 10, &enabled);
+	if (ret)
+		return ret;
+
+	if (!enabled) {
+		spin_lock_irqsave(&mtk_svs_lock, flags);
+		svsp->pbank = svsb;
+		svsb->mode_support = SVSB_MODE_ALL_DISABLE;
+		svs_switch_bank(svsp);
+		svs_writel(svsp, SVSB_EN_OFF, SVSEN);
+		svs_writel(svsp, SVSB_INTSTS_CLEAN, INTSTS);
+		spin_unlock_irqrestore(&mtk_svs_lock, flags);
+
+		svsb->phase = SVSB_PHASE_ERROR;
+		svs_adjust_pm_opp_volts(svsb, true);
+	}
+
+	kfree(buf);
+
+	return count;
+}
+
+debug_fops_rw(enable);
+
+/*
+ * svs_status_debug_show - show svs bank's tzone_temp/voltages/freqs_pct
+ * and its corresponding opp-table's opp_freqs/opp_volts
+ */
+static int svs_status_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+	struct dev_pm_opp *opp;
+	int tzone_temp = 0, ret;
+	u32 i;
+
+	ret = svs_get_bank_zone_temperature(svsb->tzone_name, &tzone_temp);
+	if (ret)
+		seq_printf(m, "%s: no \"%s\" zone?\n", svsb->name,
+			   svsb->tzone_name);
+	else
+		seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
+
+	for (i = 0; i < svsb->opp_count; i++) {
+		opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
+						 svsb->opp_freqs[i], true);
+		if (IS_ERR(opp)) {
+			seq_printf(m, "%s: cannot find freq = %u (%ld)\n",
+				   svsb->name, svsb->opp_freqs[i],
+				   PTR_ERR(opp));
+			return PTR_ERR(opp);
+		}
+
+		seq_printf(m, "opp_freqs[%02u]: %u, opp_volts[%02u]: %lu, ",
+			   i, svsb->opp_freqs[i], i,
+			   dev_pm_opp_get_voltage(opp));
+		seq_printf(m, "svsb_volts[%02u]: 0x%x, freqs_pct[%02u]: %u\n",
+			   i, svsb->volts[i], i, svsb->freqs_pct[i]);
+		dev_pm_opp_put(opp);
+	}
+
+	return 0;
+}
+
+debug_fops_ro(status);
+
+/*
+ * svs_volt_offset_debug_show - show svs bank's voltage offset
+ */
+static int svs_volt_offset_debug_show(struct seq_file *m, void *v)
+{
+	struct svs_bank *svsb = (struct svs_bank *)m->private;
+
+	seq_printf(m, "%d\n", svsb->volt_offset);
+
+	return 0;
+}
+
+/*
+ * svs_volt_offset_debug_write - write svs bank's voltage offset
+ */
+static ssize_t svs_volt_offset_debug_write(struct file *filp,
+					   const char __user *buffer,
+					   size_t count, loff_t *pos)
+{
+	struct svs_bank *svsb = file_inode(filp)->i_private;
+	char *buf = NULL;
+	s32 volt_offset;
+
+	if (count >= PAGE_SIZE)
+		return -EINVAL;
+
+	buf = (char *)memdup_user_nul(buffer, count);
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
+
+	if (!kstrtoint(buf, 10, &volt_offset)) {
+		svsb->volt_offset = volt_offset;
+		svs_adjust_pm_opp_volts(svsb, true);
+	}
+
+	kfree(buf);
+
+	return count;
+}
+
+debug_fops_rw(volt_offset);
+
+static int svs_create_svs_debug_cmds(struct svs_platform *svsp)
+{
+	struct svs_bank *svsb;
+	struct dentry *svs_dir, *svsb_dir, *file_entry;
+	const char *d = "/sys/kernel/debug/svs";
+	u32 i, idx;
+
+	struct svs_dentry {
+		const char *name;
+		const struct file_operations *fops;
+	};
+
+	struct svs_dentry svs_entries[] = {
+		svs_dentry(dump),
+	};
+
+	struct svs_dentry svsb_entries[] = {
+		svs_dentry(enable),
+		svs_dentry(status),
+		svs_dentry(volt_offset),
+	};
+
+	svs_dir = debugfs_create_dir("svs", NULL);
+	if (IS_ERR(svs_dir)) {
+		dev_err(svsp->dev, "cannot create %s: %ld\n",
+			d, PTR_ERR(svs_dir));
+		return 0;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(svs_entries); i++) {
+		file_entry = debugfs_create_file(svs_entries[i].name, 0664,
+						 svs_dir, svsp,
+						 svs_entries[i].fops);
+		if (IS_ERR(file_entry)) {
+			dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+				d, svs_entries[i].name, PTR_ERR(file_entry));
+			return PTR_ERR(file_entry);
+		}
+	}
+
+	for (idx = 0; idx < svsp->bank_num; idx++) {
+		svsb = &svsp->banks[idx];
+
+		svsb_dir = debugfs_create_dir(svsb->name, svs_dir);
+		if (IS_ERR(svsb_dir)) {
+			dev_err(svsp->dev, "cannot create %s/%s: %ld\n",
+				d, svsb->name, PTR_ERR(svsb_dir));
+			return PTR_ERR(svsb_dir);
+		}
+
+		for (i = 0; i < ARRAY_SIZE(svsb_entries); i++) {
+			file_entry = debugfs_create_file(svsb_entries[i].name,
+							 0664, svsb_dir, svsb,
+							 svsb_entries[i].fops);
+			if (IS_ERR(file_entry)) {
+				dev_err(svsp->dev, "no %s/%s/%s?: %ld\n",
+					d, svsb->name, svsb_entries[i].name,
+					PTR_ERR(file_entry));
+				return PTR_ERR(file_entry);
+			}
+		}
+	}
+
+	return 0;
+}
+
 static struct svs_bank svs_mt8183_banks[] = {
 	{
 		.sw_id			= SVSB_CPU_LITTLE,
 		.set_freqs_pct		= svs_set_freqs_pct_v2,
 		.get_vops		= svs_get_vops_v2,
+		.hw_id			= 0,
 		.cpu_id			= 0,
 		.tzone_name		= "tzts4",
 		.buck_name		= "proc",
@@ -1458,6 +1777,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 		.sw_id			= SVSB_CPU_BIG,
 		.set_freqs_pct		= svs_set_freqs_pct_v2,
 		.get_vops		= svs_get_vops_v2,
+		.hw_id			= 1,
 		.cpu_id			= 4,
 		.tzone_name		= "tzts5",
 		.buck_name		= "proc",
@@ -1495,6 +1815,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 		.sw_id			= SVSB_CCI,
 		.set_freqs_pct		= svs_set_freqs_pct_v2,
 		.get_vops		= svs_get_vops_v2,
+		.hw_id			= 2,
 		.tzone_name		= "tzts4",
 		.buck_name		= "proc",
 		.pd_req			= false,
@@ -1531,6 +1852,7 @@ static struct svs_bank svs_mt8183_banks[] = {
 		.sw_id			= SVSB_GPU,
 		.set_freqs_pct		= svs_set_freqs_pct_v2,
 		.get_vops		= svs_get_vops_v2,
+		.hw_id			= 3,
 		.tzone_name		= "tzts2",
 		.buck_name		= "mali",
 		.pd_req			= true,
@@ -1694,6 +2016,12 @@ static int svs_probe(struct platform_device *pdev)
 		goto svs_probe_iounmap;
 	}
 
+	ret = svs_create_svs_debug_cmds(svsp);
+	if (ret) {
+		dev_err(svsp->dev, "svs create debug cmds fail: %d\n", ret);
+		goto svs_probe_iounmap;
+	}
+
 	return 0;
 
 svs_probe_iounmap:
-- 
2.18.0

From roger.lu at mediatek.com  Wed Apr 28 07:54:33 2021
From: roger.lu at mediatek.com (Roger Lu)
Date: Wed, 28 Apr 2021 14:54:33 +0800
Subject: [PATCH v16 0/7] soc: mediatek: SVS: introduce MTK SVS
Message-ID: <20210428065440.3704-1-roger.lu@mediatek.com>

1. SVS driver uses OPP adjust event in [1] to update OPP table voltage part.
2. SVS driver gets thermal/GPU device by node [2][3] and CPU device by get_cpu_device().
After retrieving subsys device, SVS driver calls device_link_add() to make sure probe/suspend callback priority.
3. SVS dts refers to reset controller [4] to help reset SVS HW.

#mt8183 SVS related patches
[1] https://patchwork.kernel.org/patch/11193513/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/20201013102358.22588-2-michael.kao at mediatek.com/
[3] https://patchwork.kernel.org/project/linux-mediatek/patch/20200306041345.259332-3-drinkcat at chromium.org/

#mt8192 SVS related patches
[1] https://patchwork.kernel.org/patch/11193513/
[2] https://patchwork.kernel.org/project/linux-mediatek/patch/20201223074944.2061-1-michael.kao at mediatek.com/
[3] https://lore.kernel.org/patchwork/patch/1360551/
[4] https://patchwork.kernel.org/project/linux-mediatek/patch/20200817030324.5690-5-crystal.guo at mediatek.com/

changes since v15:
- Put (*set_freqs_pct) and (*get_vops) in struct svs_bank because they are part of svs bank's operation
- Add define "SVSB_INIT02_RM_DVTFIXED" and "SVSB_MON_VOLT_IGNORE" to make control clearly.
- Remove unnecessary parenthesis

Roger Lu (7):
  [v16,1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
  [v16,2/7] arm64: dts: mt8183: add svs device information
  [v16,3/7] soc: mediatek: SVS: introduce MTK SVS engine
  [v16,4/7] soc: mediatek: SVS: add debug commands
  [v16,5/7] dt-bindings: soc: mediatek: add mt8192 svs dt-bindings
  [v16,6/7] arm64: dts: mt8192: add svs device information
  [v16,7/7] soc: mediatek: SVS: add mt8192 SVS GPU driver

 .../bindings/soc/mediatek/mtk-svs.yaml        |   92 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi      |   18 +
 arch/arm64/boot/dts/mediatek/mt8192.dtsi      |   34 +
 drivers/soc/mediatek/Kconfig                  |   10 +
 drivers/soc/mediatek/Makefile                 |    1 +
 drivers/soc/mediatek/mtk-svs.c                | 2524 +++++++++++++++++
 6 files changed, 2679 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml
 create mode 100644 drivers/soc/mediatek/mtk-svs.c


From mchehab+huawei at kernel.org  Wed Apr 28 08:13:02 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 09:13:02 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
 <20210427113055.745d0560@coco.lan>
 <20210427114235.45a7b2a4@coco.lan>
 <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>
Message-ID: <20210428091302.64af1e5d@coco.lan>

Em Tue, 27 Apr 2021 13:50:44 +0200
Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:

> On 27.04.2021 11:42, Mauro Carvalho Chehab wrote:
> > Em Tue, 27 Apr 2021 11:30:55 +0200
> > Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:
> >   
> >> Em Tue, 27 Apr 2021 10:18:12 +0200
> >> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
> >>  
> >>> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:    
> >>>> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> >>>> added pm_runtime_resume_and_get() in order to automatically handle
> >>>> dev->power.usage_count decrement on errors.
> >>>>
> >>>> Use the new API, in order to cleanup the error check logic.
> >>>>
> >>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> >>>> ---
> >>>>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
> >>>>  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
> >>>>  2 files changed, 2 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> index 9f41c2e7097a..9d5841194f6b 100644
> >>>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> >>>> @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
> >>>>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
> >>>>  	int i;
> >>>>  
> >>>> -	pm_runtime_get_sync(&pdev->dev);
> >>>> +	pm_runtime_resume_and_get(&pdev->dev);
> >>>>  
> >>>>  	gsc_unregister_m2m_device(gsc);
> >>>>  	v4l2_device_unregister(&gsc->v4l2_dev);
> >>>> @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
> >>>>  	for (i = 0; i < gsc->num_clocks; i++)
> >>>>  		clk_disable_unprepare(gsc->clock[i]);
> >>>>  
> >>>> -	pm_runtime_put_noidle(&pdev->dev);      
> >>>
> >>> If we do this then the device usage count will not get decremented
> >>> after the pm_runtime_resume_and_get() call above and after driver
> >>> unload/load cycle it will not be possible to suspend the device.
> >>> I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
> >>> works better in that case.    
> >>
> >> Good point.
> >>
> >> Actually, I don't see any reason why to call a PM resume
> >> function - either being pm_runtime_get_sync() or
> >> pm_runtime_resume_and_get().
> >>
> >> The code there could simply be:
> >>
> >>     static int gsc_remove(struct platform_device *pdev)
> >>     {
> >>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
> >>         int i;
> >>
> >>         gsc_unregister_m2m_device(gsc);
> >>         v4l2_device_unregister(&gsc->v4l2_dev);
> >>
> >>         vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> >>         for (i = 0; i < gsc->num_clocks; i++)
> >>                 clk_disable_unprepare(gsc->clock[i]);
> >>
> >>         pm_runtime_disable(&pdev->dev);
> >>
> >>         dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
> >>         return 0;
> >>     }
> >>
> >> Eventually also adding:
> >> 	pm_runtime_suspended(&pdev->dev);  
> > 
> > In time: I actually meant:
> > 
> > 	pm_runtime_set_suspended(&pdev->dev);
> > 
> > but after double-checking the PM runtime code, it sounds to me that
> > just calling pm_runtime_disable() would be enough. Not 100% sure
> > here. Btw, some media drivers call it after pm_runtime_disable(),
> > while others don't do.  
> 
> I think if the device is brought into suspended state (e.g. by
> disabling clocks as above) the pm_runtime_set_suspended() call
> should be there. IOW a following sequence: 
> 
> 	pm_runtime_disable(dev);
> 	if (!pm_runtime_status_suspended(dev))
> 		/* put device into suspended state (disable clocks, 
> 		  voltage regulators, assert GPIOs, etc. */
> 	pm_runtime_set_suspended(dev);

Not sure if this would work, as the clock framework would try
to do things like calling clk_pm_runtime_put().

Perhaps an alternative would be to just return an error if it
can't resume PM runtime, e. g.:

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..d47d02c75484 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1208,9 +1208,11 @@ static int gsc_probe(struct platform_device *pdev)
 static int gsc_remove(struct platform_device *pdev)
 {
        struct gsc_dev *gsc = platform_get_drvdata(pdev);
-       int i;
+       int ret, i;
 
-       pm_runtime_get_sync(&pdev->dev);
+       ret = pm_runtime_resume_and_get(&pdev->dev);
+       if (ret < 0)
+               return ret;
 
        gsc_unregister_m2m_device(gsc);
        v4l2_device_unregister(&gsc->v4l2_dev);


Thanks,
Mauro


From mchehab at kernel.org  Wed Apr 28 08:17:07 2021
From: mchehab at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 09:17:07 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <20210428091302.64af1e5d@coco.lan>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
 <20210427113055.745d0560@coco.lan>
 <20210427114235.45a7b2a4@coco.lan>
 <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>
 <20210428091302.64af1e5d@coco.lan>
Message-ID: <20210428091707.3c99d124@coco.lan>

Em Wed, 28 Apr 2021 09:13:02 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:

> Em Tue, 27 Apr 2021 13:50:44 +0200
> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
> 
> > On 27.04.2021 11:42, Mauro Carvalho Chehab wrote:  
> > > Em Tue, 27 Apr 2021 11:30:55 +0200
> > > Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:
> > >     
> > >> Em Tue, 27 Apr 2021 10:18:12 +0200
> > >> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
> > >>    
> > >>> On 24.04.2021 08:45, Mauro Carvalho Chehab wrote:      
> > >>>> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> > >>>> added pm_runtime_resume_and_get() in order to automatically handle
> > >>>> dev->power.usage_count decrement on errors.
> > >>>>
> > >>>> Use the new API, in order to cleanup the error check logic.
> > >>>>
> > >>>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> > >>>> ---
> > >>>>  drivers/media/platform/exynos-gsc/gsc-core.c | 3 +--
> > >>>>  drivers/media/platform/exynos-gsc/gsc-m2m.c  | 2 +-
> > >>>>  2 files changed, 2 insertions(+), 3 deletions(-)
> > >>>>
> > >>>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> > >>>> index 9f41c2e7097a..9d5841194f6b 100644
> > >>>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> > >>>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> > >>>> @@ -1210,7 +1210,7 @@ static int gsc_remove(struct platform_device *pdev)
> > >>>>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
> > >>>>  	int i;
> > >>>>  
> > >>>> -	pm_runtime_get_sync(&pdev->dev);
> > >>>> +	pm_runtime_resume_and_get(&pdev->dev);
> > >>>>  
> > >>>>  	gsc_unregister_m2m_device(gsc);
> > >>>>  	v4l2_device_unregister(&gsc->v4l2_dev);
> > >>>> @@ -1219,7 +1219,6 @@ static int gsc_remove(struct platform_device *pdev)
> > >>>>  	for (i = 0; i < gsc->num_clocks; i++)
> > >>>>  		clk_disable_unprepare(gsc->clock[i]);
> > >>>>  
> > >>>> -	pm_runtime_put_noidle(&pdev->dev);        
> > >>>
> > >>> If we do this then the device usage count will not get decremented
> > >>> after the pm_runtime_resume_and_get() call above and after driver
> > >>> unload/load cycle it will not be possible to suspend the device.
> > >>> I wouldn't be changing anything in gsc_remove(), pm_runtime_get_sync()
> > >>> works better in that case.      
> > >>
> > >> Good point.
> > >>
> > >> Actually, I don't see any reason why to call a PM resume
> > >> function - either being pm_runtime_get_sync() or
> > >> pm_runtime_resume_and_get().
> > >>
> > >> The code there could simply be:
> > >>
> > >>     static int gsc_remove(struct platform_device *pdev)
> > >>     {
> > >>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
> > >>         int i;
> > >>
> > >>         gsc_unregister_m2m_device(gsc);
> > >>         v4l2_device_unregister(&gsc->v4l2_dev);
> > >>
> > >>         vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> > >>         for (i = 0; i < gsc->num_clocks; i++)
> > >>                 clk_disable_unprepare(gsc->clock[i]);
> > >>
> > >>         pm_runtime_disable(&pdev->dev);
> > >>
> > >>         dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
> > >>         return 0;
> > >>     }
> > >>
> > >> Eventually also adding:
> > >> 	pm_runtime_suspended(&pdev->dev);    
> > > 
> > > In time: I actually meant:
> > > 
> > > 	pm_runtime_set_suspended(&pdev->dev);
> > > 
> > > but after double-checking the PM runtime code, it sounds to me that
> > > just calling pm_runtime_disable() would be enough. Not 100% sure
> > > here. Btw, some media drivers call it after pm_runtime_disable(),
> > > while others don't do.    
> > 
> > I think if the device is brought into suspended state (e.g. by
> > disabling clocks as above) the pm_runtime_set_suspended() call
> > should be there. IOW a following sequence: 
> > 
> > 	pm_runtime_disable(dev);
> > 	if (!pm_runtime_status_suspended(dev))
> > 		/* put device into suspended state (disable clocks, 
> > 		  voltage regulators, assert GPIOs, etc. */
> > 	pm_runtime_set_suspended(dev);  
> 
> Not sure if this would work, as the clock framework would try
> to do things like calling clk_pm_runtime_put().
> 
> Perhaps an alternative would be to just return an error if it
> can't resume PM runtime, e. g.:
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 9f41c2e7097a..d47d02c75484 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1208,9 +1208,11 @@ static int gsc_probe(struct platform_device *pdev)
>  static int gsc_remove(struct platform_device *pdev)
>  {
>         struct gsc_dev *gsc = platform_get_drvdata(pdev);
> -       int i;
> +       int ret, i;
>  
> -       pm_runtime_get_sync(&pdev->dev);
> +       ret = pm_runtime_resume_and_get(&pdev->dev);
> +       if (ret < 0)
> +               return ret;

Nah, forget about that. Despite the platform driver having a return code,
support for it bogus:


static int platform_remove(struct device *_dev)
{
        struct platform_driver *drv = to_platform_driver(_dev->driver);
        struct platform_device *dev = to_platform_device(_dev);

        if (drv->remove) {
                int ret = drv->remove(dev);

                if (ret)
                        dev_warn(_dev, "remove callback returned a non-zero value. This will be ignored.\n");
        }
        dev_pm_domain_detach(_dev, true);

        return 0;
}

Thanks,
Mauro


From qiangqing.zhang at nxp.com  Wed Apr 28 09:06:05 2021
From: qiangqing.zhang at nxp.com (Joakim Zhang)
Date: Wed, 28 Apr 2021 08:06:05 +0000
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <6416c580-0df9-7d36-c42d-65293c40aa25@gmail.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
 <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <6416c580-0df9-7d36-c42d-65293c40aa25@gmail.com>
Message-ID: <DB8PR04MB6795AD745C2B27B6AC68497EE6409@DB8PR04MB6795.eurprd04.prod.outlook.com>


Hi Florian,

> -----Original Message-----
> From: Florian Fainelli <f.fainelli at gmail.com>
> Sent: 2021?4?28? 0:41
> To: Joakim Zhang <qiangqing.zhang at nxp.com>; Oleksij Rempel
> <o.rempel at pengutronix.de>
> Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Heiner Kallweit
> <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>;
> kernel at pengutronix.de; netdev at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> dl-linux-imx <linux-imx at nxp.com>; Fabio Estevam <festevam at gmail.com>;
> David Jander <david at protonic.nl>; Russell King <linux at armlinux.org.uk>;
> Philippe Schenker <philippe.schenker at toradex.com>
> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support
> 
> 
> 
> On 4/26/2021 9:48 PM, Joakim Zhang wrote:
> >
> >> -----Original Message-----
> >> From: Oleksij Rempel <o.rempel at pengutronix.de>
> >> Sent: 2021?4?23? 12:37
> >> To: Joakim Zhang <qiangqing.zhang at nxp.com>
> >> Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> >> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian
> >> Fainelli <f.fainelli at gmail.com>; Heiner Kallweit
> >> <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>;
> >> kernel at pengutronix.de; netdev at vger.kernel.org;
> >> linux-arm-kernel at lists.infradead.org;
> >> linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
> >> Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>;
> >> Russell King <linux at armlinux.org.uk>; Philippe Schenker
> >> <philippe.schenker at toradex.com>
> >> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest
> >> support
> >>
> >> Hi Joakim,
> >>
> >> On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
> >>>
> >>> Hi Oleksij,
> >>>
> >>> I look both stmmac selftest code and this patch set. For stmmac, if
> >>> PHY
> >> doesn't support loopback, it will fallthrough to MAC loopback.
> >>> You provide this generic net selftest support based on PHY loopback,
> >>> I have a
> >> question, is it possible to extend it also support MAC loopback later?
> >>
> >> Yes. If you have interest and time to implement it, please do.
> >> It should be some kind of generic callback as phy_loopback() and if
> >> PHY and MAC loopbacks are supported we need to tests both variants.
> > Hi Oleksij,
> >
> > Yes, I can try to implement it when I am free, but I still have some questions:
> > 1. Where we place the generic function? Such as mac_loopback().
> > 2. MAC is different from PHY, need program different registers to enable
> loopback on different SoCs, that means we need get MAC private data from
> "struct net_device".
> > So we need a callback for MAC drivers, where we extend this callback? Could
> be "struct net_device_ops"? Such as ndo_set_loopback?
> 
> Even for PHY devices, if we implemented external PHY loopback in the future,
> the programming would be different from one vendor to another. I am starting
> to wonder if the existing ethtool self-tests are the best API to expose the ability
> for an user to perform PHY and MAC loopback testing.
> 
> From an Ethernet MAC and PHY driver perspective, what I would imagine we
> could have for a driver API is:
> 
> enum ethtool_loopback_mode {
> 	ETHTOOL_LOOPBACK_OFF,
> 	ETHTOOL_LOOPBACK_PHY_INTERNAL,
> 	ETHTOOL_LOOPBACK_PHY_EXTERNAL,
> 	ETHTOOL_LOOPBACK_MAC_INTERNAL,
> 	ETHTOOL_LOOPBACK_MAC_EXTERNAL,
> 	ETHTOOL_LOOPBACK_FIXTURE,
> 	__ETHTOOL_LOOPBACK_MAX
> };

What's the difference between internal and external loopback for both PHY and MAC? I am not familiar with these concepts. Thanks.

Best Regards,
Joakim Zhang
> 	int (*ndo_set_loopback_mode)(struct net_device *dev, enum
> ethtool_loopback_mode mode);
> 
> and within the Ethernet MAC driver you would do something like this:
> 
> 	switch (mode) {
> 	case ETHTOOL_LOOPBACK_PHY_INTERNAL:
> 	case ETHTOOL_LOOPBACK_PHY_EXTERNAL:
> 	case ETHTOOL_LOOPBACK_OFF:
> 		ret = phy_loopback(ndev->phydev, mode);
> 		break;
> 	/* Other case statements implemented in driver */
> 
> we would need to change the signature of phy_loopback() to accept being
> passed ethtool_loopback_mode so we can support different modes.
> 
> Whether we want to continue using the self-tests API, or if we implement a
> new ethtool command in order to request a loopback operation is up for
> discussion.
> --
> Florian

From tan.shaopeng at fujitsu.com  Wed Apr 28 09:16:48 2021
From: tan.shaopeng at fujitsu.com (tan.shaopeng at fujitsu.com)
Date: Wed, 28 Apr 2021 08:16:48 +0000
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
Message-ID: <OSAPR01MB2146D42FC04779268BA231878B409@OSAPR01MB2146.jpnprd01.prod.outlook.com>

Hi Reinette,

> On 4/21/2021 1:37 AM, tan.shaopeng at fujitsu.com wrote:
> > Hi,
> >
> > Ping... any comments&advice about add an A64FX cache control function
> into resctrl?
> 
> My apologies for the delay.
> 
> >
> > Best regards
> > Tan Shaopeng
> >
> >> Hello
> >>
> >>
> >> I'm Tan Shaopeng from Fujitsu Limited.
> >>
> >> I?m trying to implement Fujitsu A64FX?s cache related features.
> >> It is a cache partitioning function we called sector cache function
> >> that using the value of the tag that is upper 8 bits of the 64bit
> >> address and the value of the sector cache register to control virtual cache
> capacity of the L1D&L2 cache.
> >>
> >> A few days ago, when I sent a driver that realizes this function to
> >> ARM64 kernel community, Will Deacon and Arnd Bergmann suggested an
> >> idea to add the sector cache function of A64FX into resctrl.
> >>
> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5Oc
> >> Z=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/
> >>
> >> Based on my study, I think the sector cache function of A64FX can be
> >> added into the allocation features of resctrl after James' resctrl rework has
> finished.
> >> But, in order to implement this function, more interfaces for resctrl are
> need.
> >> The details are as follow, and could you give me some advice?
> >>
> >> [Sector cache function]
> >> The sector cache function split cache into multiple sectors and
> >> control them separately. It is implemented on the L1D cache and
> >> L2 cache in the A64FX processor and can be controlled individually
> >> for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache and
> >> L2 cache has 4 sectors. Which L1D sector is used is specified by the
> >> value of [57:56] bits of address, how many ways of sector are
> >> specified by the value of register (IMP_SCCR_L1_EL0).
> >> Which L2 sector is used is specified by the value of [56] bits of
> >> address, and how many ways of sector are specified by value of
> >> register (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
> >> IMP_SCCR_SET1_L2_EL1).
> >>
> >> For more details of sector cache function, see A64FX HPC extension
> >> specification (1.2. Sector cache) in https://github.com/fujitsu/A64FX
> 
> The overview in section 12 was informative but very high level.

I'm considering how to answer your questions from your email which 
I received before, when I check the email again, I am sorry that 
the information I provided before are insufficient.  

To understand the sector cache function of A64FX, could you please see  
A64FX_Microarchitecture_Manual - section 12. Sector Cache 
https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.4.pdf  
and, 
A64FX_Specification_HPC_Extension ? section 1.2. Sector Cache  
https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Specification_HPC_Extension_v1_EN.pdf  

In addition, Japan will be on a long holiday about one week from 
April 29th, I will answer your other questions after the holidays.  

> I was not able to find any instance of "IMP_SCCR" in this document to explore
> how this cache allocation works.
> 
> Are these cache sectors exposed to the OS in any way? For example, when the
> OS discovers the cache, does it learn about these sectors and expose the
> details to user space (/sys/devices/system/cpuX/cache)?
> 
> The overview of Sector Cache in that document provides details of how the size
> of the sector itself is dynamically adjusted to usage. That description is quite
> cryptic but it seems like a sector, since the number of ways associated with it
> can dynamically change, is more equivalent to a class of service or resource
> group in the resctrl environment.
> 
> I really may be interpreting things wrong here, could you perhaps point me to
> where I can obtain more details?
> 
> 
> >> [Difference between resctrl(CAT) and this sector cache function]
> >> L2/L3 CAT (Cache Allocation Technology) enables the user to specify
> >> some physical partition of cache space that an application can fill.
> >> A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function
> >> enables a user to specify number of ways each sector uses.
> >> Therefore, for CAT it is enough to specify a cache portion for each
> >> cache_id (socket). On the other hand, sector cache needs to specify
> >> cache portion of each sector for each cache_id, and following
> >> extension to resctrl interface is needed to support sector cache.
> >>
> >> [Idear for A64FX sector cache function control interface (schemata
> >> file details)]
> >>
> L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cw
> >> bm>,<cwbm>,<cwbm>,<cwbm>;?
> >>
> L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=
> >> <cwbm>,<cwbm>,<cwbm>,<cwbm>;?
> >>
> >> ?L1: Add a new interface to control the L1D cache.
> >> ?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for
> each
> >> sector.
> >> ?cwbm?Specify the number of ways in each sector as a bitmap
> (percentage),
> >>    but the bitmap does not indicate the location of the cache.
> >> * In the sector cache function, L2 sector cache way setting register is
> >>    shared among PEs (Processor Element) in shared domain. If two PEs
> >>    which share L2 cache belongs to different resource groups, one
> resource
> >>    group's L2 setting will affect to other resource group's L2 setting.
> 
> In resctrl a "resource group" can be viewed as a class of service.
> 
> >> * Since A64FX does not support MPAM, it is not necessary to consider
> >>    how to switch between MPAM and sector cache function now.
> >>
> >> Some questions:
> >> 1.I'm still studying about RDT, could you tell me whether RDT has
> >>    the similar mechanism with sector cache function?
> 
> This is not clear to me yet. One thing to keep in mind is that a bit in the capacity
> bitmask could correspond to some number of ways in a cache, but it does not
> have to. It is essentially a hint to hardware on how much cache space needs to
> be allocated while also indicating overlap and isolation from other allocations.
> 
> resctrl already supports the bitmask being interpreted differently between
> architectures and with the MPAM support there will be even more support for
> different interpretations.
> 
> >> 2.In RDT, L3 cache is shared among cores in socket. If two cores which
> >>    share L3 cache belongs to different resource groups, one resource
> >>    group's L3 setting will affect to other resource group's L3 setting?
> 
> This question is not entirely clear to me. Are you referring to the hardware layout
> or configuration changes via the resctrl "cpus" file?
> 
> Each resource group is a class of service (CLOS) that is supported by all cache
> instances. By default each resource group would thus contain all cache
> instances on the system (even if some cache instances do not support the
> same number of CLOS resctrl would only support the CLOS supported by all
> resources).

Best regards 
Tan Shaopeng


From snawrocki at kernel.org  Wed Apr 28 09:27:30 2021
From: snawrocki at kernel.org (Sylwester Nawrocki)
Date: Wed, 28 Apr 2021 10:27:30 +0200
Subject: [PATCH 58/78] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <20210428091707.3c99d124@coco.lan>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <CGME20210424064556eucas1p1e89378837c377168c9782b4172e70482@eucas1p1.samsung.com>
 <9c7d683907b9f9cf4a99f57f978671ec7f5a1dbc.1619191723.git.mchehab+huawei@kernel.org>
 <ee7b580a-d5bc-bdbf-3efc-c9d8f43316db@samsung.com>
 <20210427113055.745d0560@coco.lan> <20210427114235.45a7b2a4@coco.lan>
 <5f6088c7-c839-f097-737f-b4234c413eac@samsung.com>
 <20210428091302.64af1e5d@coco.lan> <20210428091707.3c99d124@coco.lan>
Message-ID: <01a14e06-b7f2-7246-ad12-4a13a96622a0@kernel.org>

On 28.04.2021 09:17, Mauro Carvalho Chehab wrote:
> Em Wed, 28 Apr 2021 09:13:02 +0200
> Mauro Carvalho Chehab <mchehab+huawei at kernel.org> escreveu:
> 
>> Em Tue, 27 Apr 2021 13:50:44 +0200
>> Sylwester Nawrocki <s.nawrocki at samsung.com> escreveu:
>>
>>> On 27.04.2021 11:42, Mauro Carvalho Chehab wrote:

>>> I think if the device is brought into suspended state (e.g. by
>>> disabling clocks as above) the pm_runtime_set_suspended() call
>>> should be there. IOW a following sequence:
>>>
>>> 	pm_runtime_disable(dev);
>>> 	if (!pm_runtime_status_suspended(dev))
>>> 		/* put device into suspended state (disable clocks,
>>> 		  voltage regulators, assert GPIOs, etc. */
>>> 	pm_runtime_set_suspended(dev);
>>
>> Not sure if this would work, as the clock framework would try
>> to do things like calling clk_pm_runtime_put().

It's done in multiple drivers this way. clk_pm_runtime_put() operates
on different device - the clock supplier, not the consumer device.
We just need to disable runtime PM for GSC as the last step, to avoid
any possible v4l2 m2m device_run() call with runtime PM disabled.

>> Perhaps an alternative would be to just return an error if it
>> can't resume PM runtime, e. g.:
[...]
> Nah, forget about that. Despite the platform driver having a return code,
> support for it bogus:

Yes, we can't really stop remove() from driver level so as much complete
resource release is being done as possible.


Regards,
Sylwester


From sergei.shtylyov at gmail.com  Wed Apr 28 09:40:44 2021
From: sergei.shtylyov at gmail.com (Sergei Shtylyov)
Date: Wed, 28 Apr 2021 11:40:44 +0300
Subject: [PATCH] ata: ahci_sunxi: Disable DIPM
In-Reply-To: <20210427230537.21423-1-public_timo.s@silentcreek.de>
References: <20210427230537.21423-1-public_timo.s@silentcreek.de>
Message-ID: <24eb672c-9772-4e3f-e3de-0fe3390c659f@gmail.com>

Hello!

On 28.04.2021 2:05, Timo Sigurdsson wrote:

> DIPM is unsupported or broken on sunxi. Trying to enable the power
> management policy med_power_with_dipm on an Allwinner A20 SoC based board
> leads to immediate I/O errors and the attached SATA disk disappears from
> the /dev filesystem. A reset (power cycle) is required to make the SATA
> controller or disk work again. The A10 and A20 SoC data sheets and manuals
> don't mention DIPM at all [1], so it's fair to assume that it's simply not
> supported. But even if it were, it should be considered broken and best be
                             ^ was

> disabled in the ahci_sunxi driver.
> 
> Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")

    The "Fixes:" tag should immediately precede the signoff tag...

> [1] https://github.com/allwinner-zh/documents/tree/master/

    And this line should be immediately after the patch description.

> Signed-off-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
> Tested-by: Timo Sigurdsson <public_timo.s at silentcreek.de>
[...]

MBR, Sergei


From smoch at web.de  Wed Apr 28 09:43:36 2021
From: smoch at web.de (Soeren Moch)
Date: Wed, 28 Apr 2021 10:43:36 +0200
Subject: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64
In-Reply-To: <CWXP265MB2680159B5F44B014FA544E89C4409@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>
References: <CWXP265MB2680938B222248792AC205F9C4419@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>
 <97bcbcde-9ccf-f9cc-ef10-36cbd582825a@web.de>
 <CWXP265MB2680159B5F44B014FA544E89C4409@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <8466ba81-7334-d23c-8496-b3d11adcd595@web.de>

On 28.04.21 08:28, Christian L?hle wrote:
> Oh okay, I was not aware of this issue
> and have not encountered it yet.
> But wouldn't it be more appropriate
> to get u-boot to power cycle the host controller at boot?
This is not about power-cycling the host controller. We have to
power-cycle the SD card itself to switch it back to default speed and
3.3V operation. This is the mode the boot ROM expects.

Unfortunately there is no separate power switch for SD card power on
RockPro64. So we have to power-cycle the whole SoC. This obviously
cannot be done easily after reboot in u-boot, but can be done in trusted
firmware (TF-A, was called ATF before) at reboot. This is what I use on
my boards, see the hack in [1]. Rockchip seems to prefer soft reset,
maybe someone from Rockchip can comment on the exact reasons.

Regards,
Soeren


[1] https://github.com/s-moch/arm-trusted-firmware-rockpro64
>
>
> From: Soeren Moch <smoch at web.de>
> Sent: Tuesday, April 27, 2021 5:07 PM
> To: Christian L?hle <CLoehle at hyperstone.com>; robh+dt at kernel.org <robh+dt at kernel.org>; heiko at sntech.de <heiko at sntech.de>; jbx6244 at gmail.com <jbx6244 at gmail.com>; devicetree at vger.kernel.org <devicetree at vger.kernel.org>; linux-arm-kernel at lists.infradead.org <linux-arm-kernel at lists.infradead.org>; linux-rockchip at lists.infradead.org <linux-rockchip at lists.infradead.org>; linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>
> Subject: Re: [PATCH] arm64: dts: rockchip: include uhs support for rockpro64
> ?
> On 27.04.21 08:20, Christian L?hle wrote:
>> The DesignWare Host Controller has full UHS-I support, so use it.
> Enabling this UHS support makes 'reboot' hang when booting the RockPro64
> from SD card. It would work when booting from eMMC, or with a modified
> ATF which does a power cycle on reboot.
>
> But for general use it is not save to enable UHS support, or did I miss
> some recent changes?
>
> Regards,
> Soeren
>> Signed-off-by: Christian Loehle <cloehle at hyperstone.com>
>> ---
>> ? arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 1 +
>> ? 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> index 6bff8db7d33e..d22a489ec214 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> @@ -722,6 +722,7 @@ &sdmmc {
>> ??????? max-frequency = <150000000>;
>> ??????? pinctrl-names = "default";
>> ??????? pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
>> +???? sd-uhs-sdr104;
>> ??????? vmmc-supply = <&vcc3v0_sd>;
>> ??????? vqmmc-supply = <&vcc_sdio>;
>> ??????? status = "okay";
> Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
> Managing Directors: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
>



From o.rempel at pengutronix.de  Wed Apr 28 09:51:15 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Wed, 28 Apr 2021 10:51:15 +0200
Subject: [PATCH net-next v3 0/6] provide generic net selftest support
In-Reply-To: <DB8PR04MB6795AD745C2B27B6AC68497EE6409@DB8PR04MB6795.eurprd04.prod.outlook.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <DB8PR04MB67951B9C6AB1620E807205F2E6459@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <20210423043729.tup7nntmmyv6vurm@pengutronix.de>
 <DB8PR04MB6795479FBF086751D16080E2E6419@DB8PR04MB6795.eurprd04.prod.outlook.com>
 <6416c580-0df9-7d36-c42d-65293c40aa25@gmail.com>
 <DB8PR04MB6795AD745C2B27B6AC68497EE6409@DB8PR04MB6795.eurprd04.prod.outlook.com>
Message-ID: <20210428085115.mehvsj2vlqmbmib5@pengutronix.de>

On Wed, Apr 28, 2021 at 08:06:05AM +0000, Joakim Zhang wrote:
> 
> Hi Florian,
> 
> > -----Original Message-----
> > From: Florian Fainelli <f.fainelli at gmail.com>
> > Sent: 2021?4?28? 0:41
> > To: Joakim Zhang <qiangqing.zhang at nxp.com>; Oleksij Rempel
> > <o.rempel at pengutronix.de>
> > Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> > <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Heiner Kallweit
> > <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>;
> > kernel at pengutronix.de; netdev at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > dl-linux-imx <linux-imx at nxp.com>; Fabio Estevam <festevam at gmail.com>;
> > David Jander <david at protonic.nl>; Russell King <linux at armlinux.org.uk>;
> > Philippe Schenker <philippe.schenker at toradex.com>
> > Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest support
> > 
> > 
> > 
> > On 4/26/2021 9:48 PM, Joakim Zhang wrote:
> > >
> > >> -----Original Message-----
> > >> From: Oleksij Rempel <o.rempel at pengutronix.de>
> > >> Sent: 2021?4?23? 12:37
> > >> To: Joakim Zhang <qiangqing.zhang at nxp.com>
> > >> Cc: Shawn Guo <shawnguo at kernel.org>; Sascha Hauer
> > >> <s.hauer at pengutronix.de>; Andrew Lunn <andrew at lunn.ch>; Florian
> > >> Fainelli <f.fainelli at gmail.com>; Heiner Kallweit
> > >> <hkallweit1 at gmail.com>; Fugang Duan <fugang.duan at nxp.com>;
> > >> kernel at pengutronix.de; netdev at vger.kernel.org;
> > >> linux-arm-kernel at lists.infradead.org;
> > >> linux-kernel at vger.kernel.org; dl-linux-imx <linux-imx at nxp.com>; Fabio
> > >> Estevam <festevam at gmail.com>; David Jander <david at protonic.nl>;
> > >> Russell King <linux at armlinux.org.uk>; Philippe Schenker
> > >> <philippe.schenker at toradex.com>
> > >> Subject: Re: [PATCH net-next v3 0/6] provide generic net selftest
> > >> support
> > >>
> > >> Hi Joakim,
> > >>
> > >> On Fri, Apr 23, 2021 at 03:18:32AM +0000, Joakim Zhang wrote:
> > >>>
> > >>> Hi Oleksij,
> > >>>
> > >>> I look both stmmac selftest code and this patch set. For stmmac, if
> > >>> PHY
> > >> doesn't support loopback, it will fallthrough to MAC loopback.
> > >>> You provide this generic net selftest support based on PHY loopback,
> > >>> I have a
> > >> question, is it possible to extend it also support MAC loopback later?
> > >>
> > >> Yes. If you have interest and time to implement it, please do.
> > >> It should be some kind of generic callback as phy_loopback() and if
> > >> PHY and MAC loopbacks are supported we need to tests both variants.
> > > Hi Oleksij,
> > >
> > > Yes, I can try to implement it when I am free, but I still have some questions:
> > > 1. Where we place the generic function? Such as mac_loopback().
> > > 2. MAC is different from PHY, need program different registers to enable
> > loopback on different SoCs, that means we need get MAC private data from
> > "struct net_device".
> > > So we need a callback for MAC drivers, where we extend this callback? Could
> > be "struct net_device_ops"? Such as ndo_set_loopback?
> > 
> > Even for PHY devices, if we implemented external PHY loopback in the future,
> > the programming would be different from one vendor to another. I am starting
> > to wonder if the existing ethtool self-tests are the best API to expose the ability
> > for an user to perform PHY and MAC loopback testing.
> > 
> > From an Ethernet MAC and PHY driver perspective, what I would imagine we
> > could have for a driver API is:
> > 
> > enum ethtool_loopback_mode {
> > 	ETHTOOL_LOOPBACK_OFF,
> > 	ETHTOOL_LOOPBACK_PHY_INTERNAL,
> > 	ETHTOOL_LOOPBACK_PHY_EXTERNAL,
> > 	ETHTOOL_LOOPBACK_MAC_INTERNAL,
> > 	ETHTOOL_LOOPBACK_MAC_EXTERNAL,
> > 	ETHTOOL_LOOPBACK_FIXTURE,
> > 	__ETHTOOL_LOOPBACK_MAX
> > };
> 
> What's the difference between internal and external loopback for both PHY and MAC? I am not familiar with these concepts. Thanks.

For example KSZ9031 PHY. It supports two loopback modes. See page 23:
https://ww1.microchip.com/downloads/en/DeviceDoc/00002096E.pdf

TI DP83TC811R-Q1 PHY supports 4 modes. See page 27:
https://www.ti.com/lit/ds/symlink/dp83tc811r-q1.pdf


> Best Regards,
> Joakim Zhang
> > 	int (*ndo_set_loopback_mode)(struct net_device *dev, enum
> > ethtool_loopback_mode mode);
> > 
> > and within the Ethernet MAC driver you would do something like this:
> > 
> > 	switch (mode) {
> > 	case ETHTOOL_LOOPBACK_PHY_INTERNAL:
> > 	case ETHTOOL_LOOPBACK_PHY_EXTERNAL:
> > 	case ETHTOOL_LOOPBACK_OFF:
> > 		ret = phy_loopback(ndev->phydev, mode);
> > 		break;
> > 	/* Other case statements implemented in driver */
> > 
> > we would need to change the signature of phy_loopback() to accept being
> > passed ethtool_loopback_mode so we can support different modes.
> > 
> > Whether we want to continue using the self-tests API, or if we implement a
> > new ethtool command in order to request a loopback operation is up for
> > discussion.
> > --
> > Florian

-- 
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 ardb at kernel.org  Wed Apr 28 09:51:38 2021
From: ardb at kernel.org (Ard Biesheuvel)
Date: Wed, 28 Apr 2021 10:51:38 +0200
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <202104271557.412DD365A@keescook>
References: <20210423205159.830854-1-morbo@google.com>
 <202104271557.412DD365A@keescook>
Message-ID: <CAMj1kXEEHEeRdPanD5uRc+e95_qB3pd_NoWA0eu80wRSrPxOvA@mail.gmail.com>

On Wed, 28 Apr 2021 at 00:58, Kees Cook <keescook at chromium.org> wrote:
>
> On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> > The arm64 assembler in binutils 2.32 and above generates a program
> > property note in a note section, .note.gnu.property, to encode used x86
> > ISAs and features. But the kernel linker script only contains a single
> > NOTE segment:
> >
> >   PHDRS
> >   {
> >     text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
> >     dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
> >     note    PT_NOTE    FLAGS(4);               /* PF_R */
> >   }
> >
> > The NOTE segment generated by the vDSO linker script is aligned to 4 bytes.
> > But the .note.gnu.property section must be aligned to 8 bytes on arm64.
> >
> >   $ readelf -n vdso64.so
> >
> >   Displaying notes found in: .note
> >     Owner                Data size      Description
> >     Linux                0x00000004     Unknown note type: (0x00000000)
> >      description data: 06 00 00 00
> >   readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20
> >   readelf: Warning:  type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8
> >
> > Since the note.gnu.property section in the vDSO is not checked by the
> > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> >
> > Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property
> > sections in vDSO"), but for arm64.
> >
> > Signed-off-by: Bill Wendling <morbo at google.com>
>
> Seems good to me. If we ever need the BTI markings, etc, for the vDSO,
> we can revisit it then.
>
> Reviewed-by: Kees Cook <keescook at chromium.org>
>

Acked-by: Ard Biesheuvel <ardb at kernel.org>


From michael at walle.cc  Wed Apr 28 09:56:06 2021
From: michael at walle.cc (Michael Walle)
Date: Wed, 28 Apr 2021 10:56:06 +0200
Subject: [PATCH 1/2] MAINTAINERS: remove Wingman Kwok
Message-ID: <20210428085607.32075-1-michael@walle.cc>

His email bounces with permanent error "550 Invalid recipient". His last
email on the LKML was from 2015-10-22 on the LKML.

Signed-off-by: Michael Walle <michael at walle.cc>
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 80ae7dbf8723..981413f41bf3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18324,7 +18324,6 @@ F:	sound/soc/codecs/isabelle*
 F:	sound/soc/codecs/lm49453*
 
 TI NETCP ETHERNET DRIVER
-M:	Wingman Kwok <w-kwok2 at ti.com>
 M:	Murali Karicheri <m-karicheri2 at ti.com>
 L:	netdev at vger.kernel.org
 S:	Maintained
-- 
2.20.1



From michael at walle.cc  Wed Apr 28 09:56:07 2021
From: michael at walle.cc (Michael Walle)
Date: Wed, 28 Apr 2021 10:56:07 +0200
Subject: [PATCH 2/2] MAINTAINERS: move Murali Karicheri to credits
In-Reply-To: <20210428085607.32075-1-michael@walle.cc>
References: <20210428085607.32075-1-michael@walle.cc>
Message-ID: <20210428085607.32075-2-michael@walle.cc>

His email bounces with permanent error "550 Invalid recipient". His last
email on the LKML was from 2020-09-09 and he seems to have left TI.

Signed-off-by: Michael Walle <michael at walle.cc>
---
His linked in profiles says that, but I guess that shouldn't be in the
commit message.

 CREDITS     |  5 +++++
 MAINTAINERS | 13 -------------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/CREDITS b/CREDITS
index b06760f09c66..7ef7b136e71d 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1874,6 +1874,11 @@ S: Krosenska' 543
 S: 181 00 Praha 8
 S: Czech Republic
 
+N: Murali Karicheri
+E: m-karicheri2 at ti.com
+D: Keystone NetCP driver
+D: Keystone PCIe host controller driver
+
 N: Jan "Yenya" Kasprzak
 E: kas at fi.muni.cz
 D: Author of the COSA/SRP sync serial board driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 981413f41bf3..2cd7b40bb15f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14096,13 +14096,6 @@ F:	Documentation/devicetree/bindings/pci/ti-pci.txt
 F:	drivers/pci/controller/cadence/pci-j721e.c
 F:	drivers/pci/controller/dwc/pci-dra7xx.c
 
-PCI DRIVER FOR TI KEYSTONE
-M:	Murali Karicheri <m-karicheri2 at ti.com>
-L:	linux-pci at vger.kernel.org
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-F:	drivers/pci/controller/dwc/pci-keystone.c
-
 PCI DRIVER FOR V3 SEMICONDUCTOR V360EPC
 M:	Linus Walleij <linus.walleij at linaro.org>
 L:	linux-pci at vger.kernel.org
@@ -18323,12 +18316,6 @@ S:	Maintained
 F:	sound/soc/codecs/isabelle*
 F:	sound/soc/codecs/lm49453*
 
-TI NETCP ETHERNET DRIVER
-M:	Murali Karicheri <m-karicheri2 at ti.com>
-L:	netdev at vger.kernel.org
-S:	Maintained
-F:	drivers/net/ethernet/ti/netcp*
-
 TI PCM3060 ASoC CODEC DRIVER
 M:	Kirill Marinushkin <kmarinushkin at birdec.com>
 L:	alsa-devel at alsa-project.org (moderated for non-subscribers)
-- 
2.20.1



From lkp at intel.com  Wed Apr 28 10:15:05 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 17:15:05 +0800
Subject: [soc:arm/fixes] BUILD SUCCESS b5144a2bf401f06962761b9d16ad8f0983213582
Message-ID: <60892799.oUi6AlVtn3BX2X/4%lkp@intel.com>

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/fixes
branch HEAD: b5144a2bf401f06962761b9d16ad8f0983213582  dt-bindings: nvmem: mediatek: remove duplicate mt8192 line

elapsed time: 722m

configs tested: 114
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm64                               defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                                 defconfig
arm64                            allyesconfig
x86_64                           allyesconfig
i386                             allyesconfig
powerpc                    mvme5100_defconfig
arm                         lpc32xx_defconfig
sh                           se7343_defconfig
ia64                             allmodconfig
csky                                defconfig
riscv                          rv32_defconfig
mips                        maltaup_defconfig
mips                           rs90_defconfig
powerpc                     mpc83xx_defconfig
microblaze                          defconfig
openrisc                 simple_smp_defconfig
mips                        bcm47xx_defconfig
h8300                            alldefconfig
sh                            titan_defconfig
sh                           se7619_defconfig
arm                      integrator_defconfig
arm                          pxa3xx_defconfig
mips                     cu1830-neo_defconfig
riscv                            alldefconfig
powerpc                     pseries_defconfig
powerpc                mpc7448_hpc2_defconfig
xtensa                  nommu_kc705_defconfig
powerpc                   bluestone_defconfig
arm                       mainstone_defconfig
arm                   milbeaut_m10v_defconfig
powerpc                     tqm8548_defconfig
powerpc                    ge_imp3a_defconfig
powerpc                      arches_defconfig
sh                           sh2007_defconfig
mips                      maltasmvp_defconfig
arm                         cm_x300_defconfig
sh                          urquell_defconfig
riscv             nommu_k210_sdcard_defconfig
m68k                           sun3_defconfig
sh                               alldefconfig
m68k                       m5475evb_defconfig
mips                      fuloong2e_defconfig
sh                          sdk7780_defconfig
arm                        keystone_defconfig
ia64                                defconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                                defconfig
m68k                             allyesconfig
nds32                               defconfig
nios2                            allyesconfig
alpha                               defconfig
alpha                            allyesconfig
nios2                               defconfig
arc                              allyesconfig
nds32                             allnoconfig
xtensa                           allyesconfig
h8300                            allyesconfig
arc                                 defconfig
sh                               allmodconfig
parisc                              defconfig
s390                             allyesconfig
s390                             allmodconfig
parisc                           allyesconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
i386                                defconfig
mips                             allyesconfig
mips                             allmodconfig
powerpc                          allyesconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a005-20210426
i386                 randconfig-a002-20210426
i386                 randconfig-a001-20210426
i386                 randconfig-a006-20210426
i386                 randconfig-a004-20210426
i386                 randconfig-a003-20210426
x86_64               randconfig-a015-20210426
x86_64               randconfig-a016-20210426
x86_64               randconfig-a011-20210426
x86_64               randconfig-a014-20210426
x86_64               randconfig-a012-20210426
x86_64               randconfig-a013-20210426
i386                 randconfig-a012-20210428
i386                 randconfig-a014-20210428
i386                 randconfig-a013-20210428
i386                 randconfig-a011-20210428
i386                 randconfig-a015-20210428
i386                 randconfig-a016-20210428
riscv                    nommu_k210_defconfig
riscv                            allyesconfig
riscv                    nommu_virt_defconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
um                               allmodconfig
um                                allnoconfig
um                               allyesconfig
um                                  defconfig
x86_64                    rhel-8.3-kselftests
x86_64                              defconfig
x86_64                               rhel-8.3
x86_64                      rhel-8.3-kbuiltin
x86_64                                  kexec

clang tested configs:
x86_64               randconfig-a002-20210426
x86_64               randconfig-a004-20210426
x86_64               randconfig-a001-20210426
x86_64               randconfig-a006-20210426
x86_64               randconfig-a005-20210426
x86_64               randconfig-a003-20210426

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org


From sudeep.holla at arm.com  Wed Apr 28 10:31:48 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 28 Apr 2021 10:31:48 +0100
Subject: [GIT PULL] firmware: arm_scmi: Fixes for v5.13
Message-ID: <20210428093148.flrcowzr2dsj7byz@bogus>

Hi ARM SoC Team,

Please pull !

Regards,
Sudeep

-->8

The following changes since commit d4f9dddd21f39395c62ea12d3d91239637d4805f:

  firmware: arm_scmi: Add dynamic scmi devices creation (2021-03-30 16:35:16 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-fixes-5.13

for you to fetch changes up to 03f840c49207e8c125b3df8c29c13137c6675d42:

  firmware: arm_scmi: Remove duplicate declaration of struct scmi_protocol_handle (2021-04-27 11:57:26 +0100)

----------------------------------------------------------------
ARM SCMI fixes for v5.13

A fix for very old possible ternary operation sign extention bug in the old
ARM SCPI firmware driver and a cleanup to remove duplicate structure declartion
in SCMI driver.

----------------------------------------------------------------
Dan Carpenter (1):
      firmware: arm_scpi: Prevent the ternary sign expansion bug

Wan Jiabing (1):
      firmware: arm_scmi: Remove duplicate declaration of struct scmi_protocol_handle

 drivers/firmware/arm_scmi/notify.h | 2 --
 drivers/firmware/arm_scpi.c        | 4 +++-
 2 files changed, 3 insertions(+), 3 deletions(-)


From lorenzo.pieralisi at arm.com  Wed Apr 28 10:41:30 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 28 Apr 2021 10:41:30 +0100
Subject: [PATCH] psci: remove unneeded semicolon
In-Reply-To: <1612247872-32603-1-git-send-email-yang.lee@linux.alibaba.com>
References: <1612247872-32603-1-git-send-email-yang.lee@linux.alibaba.com>
Message-ID: <20210428094121.GA6543@lpieralisi>

On Tue, Feb 02, 2021 at 02:37:52PM +0800, Yang Li wrote:
> Eliminate the following coccicheck warning:
> ./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon

Nit: subject should read "psci: Remove unneeded semicolon"

> Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
> ---
>  drivers/firmware/psci/psci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Please send a v2 and address it to Mark, me and arm at kernel.org so
that they can pick it up.

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index f5fc429..35b355e 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -138,7 +138,7 @@ static int psci_to_linux_errno(int errno)
>  		return -EINVAL;
>  	case PSCI_RET_DENIED:
>  		return -EPERM;
> -	};
> +	}
>  
>  	return -EINVAL;
>  }
> -- 
> 1.8.3.1
> 


From lorenzo.pieralisi at arm.com  Wed Apr 28 10:46:21 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 28 Apr 2021 10:46:21 +0100
Subject: [PATCH] firmware: psci: Remove unneeded semicolon
In-Reply-To: <20210428030324.37998-1-wanjiabing@vivo.com>
References: <20210428030324.37998-1-wanjiabing@vivo.com>
Message-ID: <20210428094621.GB6543@lpieralisi>

On Wed, Apr 28, 2021 at 11:03:24AM +0800, Wan Jiabing wrote:
> Fix the following coccicheck warning:
> 
> ./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon
> 
> Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
> ---
>  drivers/firmware/psci/psci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Fixed by a previous posting:

https://lore.kernel.org/lkml/1612247872-32603-1-git-send-email-yang.lee at linux.alibaba.com

Thank you anyway.

Lorenzo

> 
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 64344e84bd63..6e7bac61ba93 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -138,7 +138,7 @@ static int psci_to_linux_errno(int errno)
>  		return -EINVAL;
>  	case PSCI_RET_DENIED:
>  		return -EPERM;
> -	};
> +	}
>  
>  	return -EINVAL;
>  }
> -- 
> 2.25.1
> 


From arnd at kernel.org  Wed Apr 28 10:48:34 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 28 Apr 2021 11:48:34 +0200
Subject: [PATCH] dt-bindings: nvmem: mediatek: remove duplicate mt8192 line
In-Reply-To: <YIj8sySF3W0x8E+/@kroah.com>
References: <20210427210121.1080364-1-arnd@kernel.org>
 <YIj8sySF3W0x8E+/@kroah.com>
Message-ID: <CAK8P3a3Fae0B+3KTqWx_f1nTUhr5sKfYMRo6zJHFQENo-KTjzQ@mail.gmail.com>

On Wed, Apr 28, 2021 at 8:12 AM Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> > @@ -7,7 +7,6 @@ Required properties:
> >             "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
> >             "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
> >             "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
> > -           "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
> >             "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516
> >             "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192
>
> Shouldn't you drop the bottom one here to keep this in sorted order?

Indeed. For some reason I assumed they were meant to be in chronological
order, but you are right that the others are all sorted alphanumerically.

Fixed in the arm/fixes branch, it was the only commit there. Thanks!

     Arnd


From drjones at redhat.com  Wed Apr 28 10:48:11 2021
From: drjones at redhat.com (Andrew Jones)
Date: Wed, 28 Apr 2021 11:48:11 +0200
Subject: [RFC PATCH v6 1/4] topology: Represent clusters of CPUs within a
 die
In-Reply-To: <20210420001844.9116-2-song.bao.hua@hisilicon.com>
References: <20210420001844.9116-2-song.bao.hua@hisilicon.com>
Message-ID: <20210428094811.159245-1-drjones@redhat.com>

On 20/04/2021 12:18, Barry Song wrote:
...
> Currently the ID provided is the offset of the Processor
> Hierarchy Nodes Structure within PPTT.  Whilst this is unique
> it is not terribly elegant so alternative suggestions welcome.
> 

The ACPI table offsets are consistent with how other topology IDs are
generated. I once tried to make them a little more human friendly with
[1], but it was nacked.

[1] https://lore.kernel.org/lkml/20180629132934.GA16282 at e107155-lin/t/

Thanks,
drew



From song.bao.hua at hisilicon.com  Wed Apr 28 10:51:03 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Wed, 28 Apr 2021 09:51:03 +0000
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
 <20210420001844.9116-4-song.bao.hua@hisilicon.com>
 <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>
Message-ID: <b42c762a287b4360bfa3179a5c7c3e8c@hisilicon.com>



> -----Original Message-----
> From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]
> Sent: Tuesday, April 27, 2021 11:36 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> tim.c.chen at linux.intel.com; catalin.marinas at arm.com; will at kernel.org;
> rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org; peterz at infradead.org;
> rostedt at goodmis.org; bsegall at google.com; mgorman at suse.de
> Cc: msys.mizuma at gmail.com; valentin.schneider at arm.com;
> gregkh at linuxfoundation.org; Jonathan Cameron <jonathan.cameron at huawei.com>;
> juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com
> Subject: Re: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
> within one LLC
> 
> On 20/04/2021 02:18, Barry Song wrote:
> 
> [...]
> 
> > @@ -5786,11 +5786,12 @@ static void record_wakee(struct task_struct *p)
> >   * whatever is irrelevant, spread criteria is apparent partner count exceeds
> >   * socket size.
> >   */
> > -static int wake_wide(struct task_struct *p)
> > +static int wake_wide(struct task_struct *p, int cluster)
> >  {
> >  	unsigned int master = current->wakee_flips;
> >  	unsigned int slave = p->wakee_flips;
> > -	int factor = __this_cpu_read(sd_llc_size);
> > +	int factor = cluster ? __this_cpu_read(sd_cluster_size) :
> > +		__this_cpu_read(sd_llc_size);
> 
> I don't see that the wake_wide() change has any effect here. None of the
> sched domains has SD_BALANCE_WAKE set so a wakeup (WF_TTWU) can never
> end up in the slow path.

I am really confused. The whole code has only checked if wake_flags
has WF_TTWU, it has never checked if sd_domain has SD_BALANCE_WAKE flag.

static int
select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
{
	...

	if (wake_flags & WF_TTWU) {
		record_wakee(p);

		if (sched_energy_enabled()) {
			new_cpu = find_energy_efficient_cpu(p, prev_cpu);
			if (new_cpu >= 0)
				return new_cpu;
			new_cpu = prev_cpu;
		}

		want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
	}
}

And try_to_wake_up() has always set WF_TTWU:
static int
try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) 
{
	cpu = select_task_rq(p, p->wake_cpu, wake_flags | WF_TTWU);
	...
}

So the change in wake_wide will actually affect the value of want_affine.
And I did also see code entered slow path during my benchmark.

One issue I mentioned during linaro open discussion is that
since I have moved to use cluster size to decide the value
of wake_wide, relatively less tasks will make wake_wide()
decide to go to slow path, thus, tasks begin to spread to
other NUMA,  but actually llc_size might be able to contain
those tasks. So a possible model might be:
static int wake_wide(struct task_struct *p)
{
	tasksize < cluster : scan cluster
	tasksize > llc      : slow path
	tasksize > cluster && tasksize < llc: scan llc
}

thoughts?

> Have you seen a diff when running your `lmbench stream` workload in what
> wake_wide() returns when you use `sd cluster size` instead of `sd llc
> size` as factor?
> 
> I guess for you,  wakeups are now subdivided into faster (cluster = 4
> CPUs) and fast (llc = 24 CPUs) via sis(), not into fast (sis()) and slow
> (find_idlest_cpu()).
> 
> >
> >  	if (master < slave)
> >  		swap(master, slave);
> 
> [...]
> 
> > @@ -6745,6 +6748,12 @@ static int find_energy_efficient_cpu(struct
> task_struct *p, int prev_cpu)
> >  	int want_affine = 0;
> >  	/* SD_flags and WF_flags share the first nibble */
> >  	int sd_flag = wake_flags & 0xF;
> > +	/*
> > +	 * if cpu and prev_cpu share LLC, consider cluster sibling rather
> > +	 * than llc. this is typically true while tasks are bound within
> > +	 * one numa
> > +	 */
> > +	int cluster = sched_cluster_active() && cpus_share_cache(cpu, prev_cpu, 0);
> 
> So you changed from scanning cluster before LLC to scan either cluster
> or LLC.

Yes, I have seen two ugly things for scanning cluster before scanning LLC
in select_idle_cpu.
1. avg_scan_cost is actually measuring the scanning time. But if we scan
cluster before scanning LLC, during the gap of these two different
domains, we need a huge bit operation and this bit operation is not
a scanning operation at all. This makes the scan_cost quite
untrustworthy particularly "nr" can sometimes be < cluster size, sometimes
> cluster size.

2. select_idle_cpu() is actually the last step of wake_affine, before
that, wake_affine code has been totally depending on cpus_share_cache()
to decide the target to scan from. When waker and wakee have been already
in one LLC, if we only change select_idle_cpu(), at that time, decision
has been made. we may lose some chance to choose the right target to scan
from. So it should be more sensible to let cpus_share_cache() check cluster
when related tasks have been in one same LLC.

> 
> And this is based on whether `this_cpu` and `prev_cpu` are sharing LLC
> or not. So you only see an effect when running the workload with
> `numactl -N X ...`.

Ideally, I'd expect this can also positively affect tasks located in
different LLCs.
For example, if taskA and taskB are in different NUMAs(also LLC for both
kunpeng920 and Tim's hardware) at the first beginning, a two-stage packing
might make them take the advantage of cluster:
For the first wake-up, taskA and taskB will be put in one LLC by scanning
LLC; 
For the second wake-up, they might be put in one cluster by scanning
cluster.
So ideally, scanning LLC and scanning cluster can work in two stages
for related tasks and pack them step by step. Practically, this
could happen. But LB between NUMA might take the opposite way. Actually,
for a kernel completely *without* cluster patch, I have seen some
serious ping-pong of tasks in two numa nodes due to the conflict
of wake_affine and LB. this kind of ping-pong could seriously affect
the performance.
For example, for g=6,12,18,24,28,32, I have found running same workload
on 2numa shows so much worse latency than doing that on single one
numa(each numa has 24 cpus).
1numa command: numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g $1
2numa command: numactl -N 0-1 hackbench -p -T -l 1000000 -f 1 -g $1

Measured the average latency of 20 times for each command.

*)without cluster scheduler, 2numa vs 1numa:
g      =     6     12     18    24      28     32
1numa      1.2474 1.5635 1.5133 1.4796 1.6177 1.7898
2numa      4.1997 5.8172 6.0159 7.2343 6.8264 6.5419

BTW, my cluster patch actually also improves 2numa:
*)with cluster scheduler 2numa vs 1numa:
g      =     6     12     18    24      28     32
1numa      0.9500 1.0728 1.1756 1.2201 1.4166 1.5464
2numa      3.5404 4.3744 4.3988 4.6994 5.3117 5.4908

*) 2numa  w/ and w/o cluster:
g          =     6     12     18    24      28     32
2numa w/o      4.1997 5.8172 6.0159 7.2343 6.8264 6.5419
2numa w/       3.5404 4.3744 4.3988 4.6994 5.3117 5.4908

Ideally, load balance should try to pull unmarried tasks rather than
married tasks. I mean, if we have
groupA: task1+task2 as couple, task3 as bachelor
groupB: task4.
groupB should try to pull task3. But I feel it is extremely hard to let
LB understand who is married and who is unmarried.

I assume 2numa worse than 1numa should be a different topic
which might be worth more investigation.

On the other hand, use cases I'm now targeting at are really using
"numactl -N x" to bind processes in one NUMA. If we ignore other NUMA
(also other LLCs) and think one NUMA as a whole system, cluster would
be the last-level topology scheduler can use. And the code could be
quite clean to directly leverage the existing select_sibling code for
LLC by simply changing cpus_share_cache() to cluster level.

> 
> >
> >  	if (wake_flags & WF_TTWU) {
> >  		record_wakee(p);
> > @@ -6756,7 +6765,7 @@ static int find_energy_efficient_cpu(struct task_struct
> *p, int prev_cpu)
> >  			new_cpu = prev_cpu;
> >  		}
> >
> > -		want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
> > +		want_affine = !wake_wide(p, cluster) && cpumask_test_cpu(cpu,
> p->cpus_ptr);
> >  	}
> >
> >  	rcu_read_lock();
> > @@ -6768,7 +6777,7 @@ static int find_energy_efficient_cpu(struct task_struct
> *p, int prev_cpu)
> >  		if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
> >  		    cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
> >  			if (cpu != prev_cpu)
> > -				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
> > +				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync, cluster);
> >
> >  			sd = NULL; /* Prefer wake_affine over balance flags */
> >  			break;
> > @@ -6785,7 +6794,7 @@ static int find_energy_efficient_cpu(struct task_struct
> *p, int prev_cpu)
> >  		new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
> >  	} else if (wake_flags & WF_TTWU) { /* XXX always ? */
> >  		/* Fast path */
> > -		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
> > +		new_cpu = select_idle_sibling(p, prev_cpu, new_cpu, cluster);
> >
> >  		if (want_affine)
> >  			current->recent_used_cpu = cpu;
> 
> [...]

Thanks
Barry


From arnd at kernel.org  Wed Apr 28 10:51:58 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Wed, 28 Apr 2021 11:51:58 +0200
Subject: [GIT PULL] firmware: arm_scmi: Fixes for v5.13
In-Reply-To: <20210428093148.flrcowzr2dsj7byz@bogus>
References: <20210428093148.flrcowzr2dsj7byz@bogus>
Message-ID: <161960350770.2272527.9069383680761503934.b4-ty@arndb.de>

From: Arnd Bergmann <arnd at arndb.de>

On Wed, 28 Apr 2021 10:31:48 +0100, Sudeep Holla wrote:
> Please pull !
> 
> Regards,
> Sudeep
> 
> -->8
> 
> The following changes since commit d4f9dddd21f39395c62ea12d3d91239637d4805f:
> 
> [...]

Merged into arm/fixes, thanks!

merge commit: e393cc4e9ce015abc8a68c762dc361cdb0b0db96

       Arnd


From sudeep.holla at arm.com  Wed Apr 28 10:54:32 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 28 Apr 2021 10:54:32 +0100
Subject: [PATCH] psci: remove unneeded semicolon
In-Reply-To: <20210428094121.GA6543@lpieralisi>
References: <1612247872-32603-1-git-send-email-yang.lee@linux.alibaba.com>
 <20210428094121.GA6543@lpieralisi>
Message-ID: <20210428095432.bmewlodcoficxmhj@bogus>

On Wed, Apr 28, 2021 at 10:41:30AM +0100, Lorenzo Pieralisi wrote:
> On Tue, Feb 02, 2021 at 02:37:52PM +0800, Yang Li wrote:
> > Eliminate the following coccicheck warning:
> > ./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon
> 
> Nit: subject should read "psci: Remove unneeded semicolon"
> 
> > Reported-by: Abaci Robot <abaci at linux.alibaba.com>
> > Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
> > ---
> >  drivers/firmware/psci/psci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Please send a v2 and address it to Mark, me and arm at kernel.org so
> that they can pick it up.
> 

Though I assume they still check arm at kernel.org, soc at kernel.org is new
and more preferred these days. I just checked MAINTAINERS entry to be
sure and I see only soc at kernel.org. So please add soc at kernel.org to the
list, may be it gets quicker attention than the other ?.

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Wed Apr 28 11:03:06 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 28 Apr 2021 11:03:06 +0100
Subject: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug
In-Reply-To: <YIE7pdqV/h10tEAK@mwanda>
References: <YIE7pdqV/h10tEAK@mwanda>
Message-ID: <161960405992.396847.5531876675862211477.b4-ty@arm.com>

On Thu, 22 Apr 2021 12:02:29 +0300, Dan Carpenter wrote:
> How type promotion works in ternary expressions is a bit tricky.
> The problem is that scpi_clk_get_val() returns longs, "ret" is a int
> which holds a negative error code, and le32_to_cpu() is an unsigned int.
> We want the negative error code to be cast to a negative long.  But
> because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and
> becomes a high positive and then it is promoted to long and it is still
> a high positive value.
>
> [...]

Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/1] firmware: arm_scpi: prevent ternary sign expansion bug
      https://git.kernel.org/sudeep.holla/c/d9cd78edb2

--
Regards,
Sudeep



From sudeep.holla at arm.com  Wed Apr 28 11:03:29 2021
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 28 Apr 2021 11:03:29 +0100
Subject: [PATCH] firmware: arm_scmi: Remove repeated struct declaration
In-Reply-To: <20210427033031.4580-1-wanjiabing@vivo.com>
References: <20210427033031.4580-1-wanjiabing@vivo.com>
Message-ID: <161960405992.396847.7773596762858834965.b4-ty@arm.com>

On Tue, 27 Apr 2021 11:30:31 +0800, Wan Jiabing wrote:
> struct scmi_protocol_handle is declared at 34th line.
> The declaration here is duplicate. Remove it.

Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/1] firmware: arm_scmi: Remove repeated struct declaration
      https://git.kernel.org/sudeep.holla/c/03f840c492

--
Regards,
Sudeep



From suzuki.poulose at arm.com  Wed Apr 28 11:09:19 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Wed, 28 Apr 2021 11:09:19 +0100
Subject: [PATCH v1] coresight: add node to reset all coresight devices
In-Reply-To: <4036d63a8759ac67a26fd8798b9adf6b@codeaurora.org>
References: <1619166578-28690-1-git-send-email-taozha@codeaurora.org>
 <e753898c-0334-cf84-620e-d9b9f18d87e7@arm.com>
 <4036d63a8759ac67a26fd8798b9adf6b@codeaurora.org>
Message-ID: <38865567-8557-e48d-779b-ca257e318c19@arm.com>

On 28/04/2021 10:57, taozha at codeaurora.org wrote:
> On 2021-04-23 21:20, Suzuki K Poulose wrote:
>> On 23/04/2021 09:29, Tao Zhang wrote:
>>> Add new reset_source_sink node to be able to disable all active
>>> coresight devices.
>>> In this way, we no longer need to manually disable all active
>>> coresight devices one by one. After enabling multiple coresight
>>> paths, users can reset their status more conveniently by this
>>> node.
>>>
>>
>> What is the use case here ? Why would you trigger a reset for all the
>> sources/sink without gracefully completing any on-going sessions
>> (including the perf ones, which are driven by the kernel perf layer)
>>
> We have a tool needs a command that could reset all active devices.
> Since the tool cannot what dvices are activated, we add this new node
> to sysFS for our tool could reset all active device by one command.
> We hope that this patch can also provide a more convenient option
> for the other users with the same needs.

There is sysfs handles to do this already. See the testcase under perf, 
e.g, that can walk the sysfs and figure out the source devices and the 
"sinks" that can be reached from the given device.

If some information is missing, to achieve this. we could provide that. 
But simply because a tool wants to do something without bothering to use 
the provided ABI, is not a justification to add something to the kernel.

Suzuki



From alex.bennee at linaro.org  Wed Apr 28 11:18:43 2021
From: alex.bennee at linaro.org (=?UTF-8?q?Alex=20Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 11:18:43 +0100
Subject: [kvm-unit-tests PATCH v1 3/4] arm64: enable its-migration tests for
 TCG
In-Reply-To: <20210428101844.22656-1-alex.bennee@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
Message-ID: <20210428101844.22656-4-alex.bennee@linaro.org>

With the support for TCG emulated GIC we can also test these now. You
need to call run_tests.sh with -a to trigger the
its-migrate-unmapped-collection test which obviously doesn't need the
KVM errata to run in TCG system emulation mode.

Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
---
 arm/unittests.cfg | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index c72dc34..d4dbc8b 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -203,7 +203,6 @@ arch = arm64
 [its-migration]
 file = gic.flat
 smp = $MAX_SMP
-accel = kvm
 extra_params = -machine gic-version=3 -append 'its-migration'
 groups = its migration
 arch = arm64
@@ -211,7 +210,6 @@ arch = arm64
 [its-pending-migration]
 file = gic.flat
 smp = $MAX_SMP
-accel = kvm
 extra_params = -machine gic-version=3 -append 'its-pending-migration'
 groups = its migration
 arch = arm64
@@ -219,7 +217,6 @@ arch = arm64
 [its-migrate-unmapped-collection]
 file = gic.flat
 smp = $MAX_SMP
-accel = kvm
 extra_params = -machine gic-version=3 -append 'its-migrate-unmapped-collection'
 groups = its migration
 arch = arm64
-- 
2.20.1



From alex.bennee at linaro.org  Wed Apr 28 11:18:40 2021
From: alex.bennee at linaro.org (=?UTF-8?q?Alex=20Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 11:18:40 +0100
Subject: [kvm-unit-tests PATCH v1 0/4] enable LPI and ITS for TCG
Message-ID: <20210428101844.22656-1-alex.bennee@linaro.org>

This is a companion to Shashi's series enabling LPI and ITS features
for QEMU's TCG emulation. This is part of our push for a sbsa-ref
platform which needs a more modern set of features.

  From: Shashi Mallela <shashi.mallela at linaro.org>
  Subject: [PATCH v2 0/8] GICv3 LPI and ITS feature implementation
  Date: Wed, 31 Mar 2021 22:41:44 -0400
  Message-Id: <20210401024152.203896-1-shashi.mallela at linaro.org>

Most of the changes are minor except the its-trigger test which skips
invall handling checks which I think is relying on IMPDEF behaviour
which we can't probe for. There is also a hilarious work around to
some limitations in the run_migration() script in the last patch.

Alex Benn?e (4):
  arm64: split its-trigger test into KVM and TCG variants
  scripts/arch-run: don't use deprecated server/nowait options
  arm64: enable its-migration tests for TCG
  arm64: split its-migrate-unmapped-collection into KVM and TCG variants

 scripts/arch-run.bash |  4 +--
 arm/gic.c             | 67 ++++++++++++++++++++++++++-----------------
 arm/unittests.cfg     | 23 ++++++++++++---
 3 files changed, 62 insertions(+), 32 deletions(-)

-- 
2.20.1



From alex.bennee at linaro.org  Wed Apr 28 11:18:42 2021
From: alex.bennee at linaro.org (=?UTF-8?q?Alex=20Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 11:18:42 +0100
Subject: [kvm-unit-tests PATCH v1 2/4] scripts/arch-run: don't use deprecated
 server/nowait options
In-Reply-To: <20210428101844.22656-1-alex.bennee@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
Message-ID: <20210428101844.22656-3-alex.bennee@linaro.org>

The very fact that QEMU drops the deprecation warning while running is
enough to confuse the its-migration test into failing. The boolean
options server and wait have accepted the long form options for a long
time.

Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
---
 scripts/arch-run.bash | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/arch-run.bash b/scripts/arch-run.bash
index 5997e38..70693f2 100644
--- a/scripts/arch-run.bash
+++ b/scripts/arch-run.bash
@@ -122,14 +122,14 @@ run_migration ()
 	trap 'kill 0; exit 2' INT TERM
 	trap 'rm -f ${migout1} ${migsock} ${qmp1} ${qmp2} ${fifo}' RETURN EXIT
 
-	eval "$@" -chardev socket,id=mon1,path=${qmp1},server,nowait \
+	eval "$@" -chardev socket,id=mon1,path=${qmp1},server=on,wait=off \
 		-mon chardev=mon1,mode=control | tee ${migout1} &
 
 	# We have to use cat to open the named FIFO, because named FIFO's, unlike
 	# pipes, will block on open() until the other end is also opened, and that
 	# totally breaks QEMU...
 	mkfifo ${fifo}
-	eval "$@" -chardev socket,id=mon2,path=${qmp2},server,nowait \
+	eval "$@" -chardev socket,id=mon2,path=${qmp2},server=on,wait=off \
 		-mon chardev=mon2,mode=control -incoming unix:${migsock} < <(cat ${fifo}) &
 	incoming_pid=`jobs -l %+ | awk '{print$2}'`
 
-- 
2.20.1



From alex.bennee at linaro.org  Wed Apr 28 11:18:41 2021
From: alex.bennee at linaro.org (=?UTF-8?q?Alex=20Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 11:18:41 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into KVM
 and TCG variants
In-Reply-To: <20210428101844.22656-1-alex.bennee@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
Message-ID: <20210428101844.22656-2-alex.bennee@linaro.org>

A few of the its-trigger tests rely on IMPDEF behaviour where caches
aren't flushed before invall events. However TCG emulation doesn't
model any invall behaviour and as we can't probe for it we need to be
told. Split the test into a KVM and TCG variant and skip the invall
tests when under TCG.

Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
Cc: Shashi Mallela <shashi.mallela at linaro.org>
---
 arm/gic.c         | 60 +++++++++++++++++++++++++++--------------------
 arm/unittests.cfg | 11 ++++++++-
 2 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/arm/gic.c b/arm/gic.c
index 98135ef..96a329d 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -36,6 +36,7 @@ static struct gic *gic;
 static int acked[NR_CPUS], spurious[NR_CPUS];
 static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
 static cpumask_t ready;
+static bool under_tcg;
 
 static void nr_cpu_check(int nr)
 {
@@ -734,32 +735,38 @@ static void test_its_trigger(void)
 	/*
 	 * re-enable the LPI but willingly do not call invall
 	 * so the change in config is not taken into account.
-	 * The LPI should not hit
+	 * The LPI should not hit. This does however depend on
+	 * implementation defined behaviour - under QEMU TCG emulation
+	 * it can quite correctly process the event directly.
 	 */
-	gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
-	stats_reset();
-	cpumask_clear(&mask);
-	its_send_int(dev2, 20);
-	wait_for_interrupts(&mask);
-	report(check_acked(&mask, -1, -1),
-			"dev2/eventid=20 still does not trigger any LPI");
-
-	/* Now call the invall and check the LPI hits */
-	stats_reset();
-	cpumask_clear(&mask);
-	cpumask_set_cpu(3, &mask);
-	its_send_invall(col3);
-	wait_for_interrupts(&mask);
-	report(check_acked(&mask, 0, 8195),
-			"dev2/eventid=20 pending LPI is received");
-
-	stats_reset();
-	cpumask_clear(&mask);
-	cpumask_set_cpu(3, &mask);
-	its_send_int(dev2, 20);
-	wait_for_interrupts(&mask);
-	report(check_acked(&mask, 0, 8195),
-			"dev2/eventid=20 now triggers an LPI");
+	if (under_tcg) {
+		report_skip("checking LPI triggers without invall");
+	} else {
+		gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
+		stats_reset();
+		cpumask_clear(&mask);
+		its_send_int(dev2, 20);
+		wait_for_interrupts(&mask);
+		report(check_acked(&mask, -1, -1),
+		       "dev2/eventid=20 still does not trigger any LPI");
+
+		/* Now call the invall and check the LPI hits */
+		stats_reset();
+		cpumask_clear(&mask);
+		cpumask_set_cpu(3, &mask);
+		its_send_invall(col3);
+		wait_for_interrupts(&mask);
+		report(check_acked(&mask, 0, 8195),
+		       "dev2/eventid=20 pending LPI is received");
+
+		stats_reset();
+		cpumask_clear(&mask);
+		cpumask_set_cpu(3, &mask);
+		its_send_int(dev2, 20);
+		wait_for_interrupts(&mask);
+		report(check_acked(&mask, 0, 8195),
+		       "dev2/eventid=20 now triggers an LPI");
+	}
 
 	report_prefix_pop();
 
@@ -981,6 +988,9 @@ int main(int argc, char **argv)
 	if (argc < 2)
 		report_abort("no test specified");
 
+	if (argc == 3 && strcmp(argv[2], "tcg") == 0)
+		under_tcg = true;
+
 	if (strcmp(argv[1], "ipi") == 0) {
 		report_prefix_push(argv[1]);
 		nr_cpu_check(2);
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index f776b66..c72dc34 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -184,13 +184,22 @@ extra_params = -machine gic-version=3 -append 'its-introspection'
 groups = its
 arch = arm64
 
-[its-trigger]
+[its-trigger-kvm]
 file = gic.flat
 smp = $MAX_SMP
+accel = kvm
 extra_params = -machine gic-version=3 -append 'its-trigger'
 groups = its
 arch = arm64
 
+[its-trigger-tcg]
+file = gic.flat
+smp = $MAX_SMP
+accel = tcg
+extra_params = -machine gic-version=3 -append 'its-trigger tcg'
+groups = its
+arch = arm64
+
 [its-migration]
 file = gic.flat
 smp = $MAX_SMP
-- 
2.20.1



From alex.bennee at linaro.org  Wed Apr 28 11:18:44 2021
From: alex.bennee at linaro.org (=?UTF-8?q?Alex=20Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 11:18:44 +0100
Subject: [kvm-unit-tests PATCH v1 4/4] arm64: split
 its-migrate-unmapped-collection into KVM and TCG variants
In-Reply-To: <20210428101844.22656-1-alex.bennee@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
Message-ID: <20210428101844.22656-5-alex.bennee@linaro.org>

When running the test in TCG we are basically running on bare metal so
don't rely on having a particular kernel errata applied.

You might wonder why we handle this with a totally new test name
instead of adjusting the append as we have before? Well the
run_migration shell script uses eval "$@" which unwraps the -append
leading to any second parameter being split and leaving QEMU very
confused and the test hanging. This seemed simpler than re-writing all
the test running logic in something sane ;-)

Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
Cc: Shashi Mallela <shashi.mallela at linaro.org>
---
 arm/gic.c         |  7 ++++++-
 arm/unittests.cfg | 11 ++++++++++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arm/gic.c b/arm/gic.c
index 96a329d..3bc7477 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -843,7 +843,7 @@ static void test_migrate_unmapped_collection(void)
 		goto do_migrate;
 	}
 
-	if (!errata(ERRATA_UNMAPPED_COLLECTIONS)) {
+	if (!errata(ERRATA_UNMAPPED_COLLECTIONS) && !under_tcg) {
 		report_skip("Skipping test, as this test hangs without the fix. "
 			    "Set %s=y to enable.", ERRATA_UNMAPPED_COLLECTIONS);
 		test_skipped = true;
@@ -1017,6 +1017,11 @@ int main(int argc, char **argv)
 		report_prefix_push(argv[1]);
 		test_migrate_unmapped_collection();
 		report_prefix_pop();
+	} else if (!strcmp(argv[1], "its-migrate-unmapped-collection-tcg")) {
+		under_tcg = true;
+		report_prefix_push(argv[1]);
+		test_migrate_unmapped_collection();
+		report_prefix_pop();
 	} else if (strcmp(argv[1], "its-introspection") == 0) {
 		report_prefix_push(argv[1]);
 		test_its_introspection();
diff --git a/arm/unittests.cfg b/arm/unittests.cfg
index d4dbc8b..e8f2e74 100644
--- a/arm/unittests.cfg
+++ b/arm/unittests.cfg
@@ -214,13 +214,22 @@ extra_params = -machine gic-version=3 -append 'its-pending-migration'
 groups = its migration
 arch = arm64
 
-[its-migrate-unmapped-collection]
+[its-migrate-unmapped-collection-kvm]
 file = gic.flat
 smp = $MAX_SMP
+accel = kvm
 extra_params = -machine gic-version=3 -append 'its-migrate-unmapped-collection'
 groups = its migration
 arch = arm64
 
+[its-migrate-unmapped-collection-tcg]
+file = gic.flat
+smp = $MAX_SMP
+accel = tcg
+extra_params = -machine gic-version=3 -append 'its-migrate-unmapped-collection-tcg'
+groups = its migration
+arch = arm64
+
 # Test PSCI emulation
 [psci]
 file = psci.flat
-- 
2.20.1



From christophe.leroy at csgroup.eu  Wed Apr 28 09:32:58 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 10:32:58 +0200
Subject: [PATCH v13 06/14] mm: HUGE_VMAP arch support cleanup
In-Reply-To: <20210317062402.533919-7-npiggin@gmail.com>
References: <20210317062402.533919-1-npiggin@gmail.com>
 <20210317062402.533919-7-npiggin@gmail.com>
Message-ID: <303a93df-6b32-1b3e-d293-b569e1a4b03e@csgroup.eu>



Le 17/03/2021 ? 07:23, Nicholas Piggin a ?crit?:
> This changes the awkward approach where architectures provide init
> functions to determine which levels they can provide large mappings for,
> to one where the arch is queried for each call.
> 
> This removes code and indirection, and allows constant-folding of dead
> code for unsupported levels.
> 
> This also adds a prot argument to the arch query. This is unused
> currently but could help with some architectures (e.g., some powerpc
> processors can't map uncacheable memory with large pages).
> 
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Ingo Molnar <mingo at redhat.com>
> Cc: Borislav Petkov <bp at alien8.de>
> Cc: x86 at kernel.org
> Cc: "H. Peter Anvin" <hpa at zytor.com>
> Reviewed-by: Ding Tianhong <dingtianhong at huawei.com>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com> [arm64]
> Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
> ---
>   arch/arm64/include/asm/vmalloc.h         |  8 ++
>   arch/arm64/mm/mmu.c                      | 10 +--
>   arch/powerpc/include/asm/vmalloc.h       |  8 ++
>   arch/powerpc/mm/book3s64/radix_pgtable.c |  8 +-
>   arch/x86/include/asm/vmalloc.h           |  7 ++
>   arch/x86/mm/ioremap.c                    | 12 +--
>   include/linux/io.h                       |  9 ---
>   include/linux/vmalloc.h                  |  6 ++
>   init/main.c                              |  1 -
>   mm/debug_vm_pgtable.c                    |  4 +-
>   mm/ioremap.c                             | 94 ++++++++++--------------
>   11 files changed, 87 insertions(+), 80 deletions(-)
> 

> diff --git a/mm/ioremap.c b/mm/ioremap.c
> index 3f4d36f9745a..3264d0203785 100644
> --- a/mm/ioremap.c
> +++ b/mm/ioremap.c
> @@ -16,49 +16,16 @@
>   #include "pgalloc-track.h"
>   
>   #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> -static int __read_mostly ioremap_p4d_capable;
> -static int __read_mostly ioremap_pud_capable;
> -static int __read_mostly ioremap_pmd_capable;
> -static int __read_mostly ioremap_huge_disabled;
> +static bool __ro_after_init iomap_max_page_shift = PAGE_SHIFT;

Must be an int, not a bool.

>   
>   static int __init set_nohugeiomap(char *str)
>   {
> -	ioremap_huge_disabled = 1;
> +	iomap_max_page_shift = P4D_SHIFT;
>   	return 0;
>   }
>   early_param("nohugeiomap", set_nohugeiomap);
> -
> -void __init ioremap_huge_init(void)
> -{
> -	if (!ioremap_huge_disabled) {
> -		if (arch_ioremap_p4d_supported())
> -			ioremap_p4d_capable = 1;
> -		if (arch_ioremap_pud_supported())
> -			ioremap_pud_capable = 1;
> -		if (arch_ioremap_pmd_supported())
> -			ioremap_pmd_capable = 1;
> -	}
> -}
> -
> -static inline int ioremap_p4d_enabled(void)
> -{
> -	return ioremap_p4d_capable;
> -}
> -
> -static inline int ioremap_pud_enabled(void)
> -{
> -	return ioremap_pud_capable;
> -}
> -
> -static inline int ioremap_pmd_enabled(void)
> -{
> -	return ioremap_pmd_capable;
> -}
> -
> -#else	/* !CONFIG_HAVE_ARCH_HUGE_VMAP */
> -static inline int ioremap_p4d_enabled(void) { return 0; }
> -static inline int ioremap_pud_enabled(void) { return 0; }
> -static inline int ioremap_pmd_enabled(void) { return 0; }
> +#else /* CONFIG_HAVE_ARCH_HUGE_VMAP */
> +static const bool iomap_max_page_shift = PAGE_SHIFT;
>   #endif	/* CONFIG_HAVE_ARCH_HUGE_VMAP */
>   
>   static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,

Christophe


From christophe.leroy at csgroup.eu  Wed Apr 28 09:34:28 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 10:34:28 +0200
Subject: [PATCH v13 06/14] mm: HUGE_VMAP arch support cleanup
In-Reply-To: <303a93df-6b32-1b3e-d293-b569e1a4b03e@csgroup.eu>
References: <20210317062402.533919-1-npiggin@gmail.com>
 <20210317062402.533919-7-npiggin@gmail.com>
 <303a93df-6b32-1b3e-d293-b569e1a4b03e@csgroup.eu>
Message-ID: <ad8138dd-3b99-bb76-3257-2d959f770d4b@csgroup.eu>



Le 28/04/2021 ? 10:32, Christophe Leroy a ?crit?:
> 
> 
> Le 17/03/2021 ? 07:23, Nicholas Piggin a ?crit?:
>> This changes the awkward approach where architectures provide init
>> functions to determine which levels they can provide large mappings for,
>> to one where the arch is queried for each call.
>>
>> This removes code and indirection, and allows constant-folding of dead
>> code for unsupported levels.
>>
>> This also adds a prot argument to the arch query. This is unused
>> currently but could help with some architectures (e.g., some powerpc
>> processors can't map uncacheable memory with large pages).
>>
>> Cc: linuxppc-dev at lists.ozlabs.org
>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>> Cc: Will Deacon <will at kernel.org>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Ingo Molnar <mingo at redhat.com>
>> Cc: Borislav Petkov <bp at alien8.de>
>> Cc: x86 at kernel.org
>> Cc: "H. Peter Anvin" <hpa at zytor.com>
>> Reviewed-by: Ding Tianhong <dingtianhong at huawei.com>
>> Acked-by: Catalin Marinas <catalin.marinas at arm.com> [arm64]
>> Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
>> ---
>> ? arch/arm64/include/asm/vmalloc.h???????? |? 8 ++
>> ? arch/arm64/mm/mmu.c????????????????????? | 10 +--
>> ? arch/powerpc/include/asm/vmalloc.h?????? |? 8 ++
>> ? arch/powerpc/mm/book3s64/radix_pgtable.c |? 8 +-
>> ? arch/x86/include/asm/vmalloc.h?????????? |? 7 ++
>> ? arch/x86/mm/ioremap.c??????????????????? | 12 +--
>> ? include/linux/io.h?????????????????????? |? 9 ---
>> ? include/linux/vmalloc.h????????????????? |? 6 ++
>> ? init/main.c????????????????????????????? |? 1 -
>> ? mm/debug_vm_pgtable.c??????????????????? |? 4 +-
>> ? mm/ioremap.c???????????????????????????? | 94 ++++++++++--------------
>> ? 11 files changed, 87 insertions(+), 80 deletions(-)
>>
> 
>> diff --git a/mm/ioremap.c b/mm/ioremap.c
>> index 3f4d36f9745a..3264d0203785 100644
>> --- a/mm/ioremap.c
>> +++ b/mm/ioremap.c
>> @@ -16,49 +16,16 @@
>> ? #include "pgalloc-track.h"
>> ? #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> -static int __read_mostly ioremap_p4d_capable;
>> -static int __read_mostly ioremap_pud_capable;
>> -static int __read_mostly ioremap_pmd_capable;
>> -static int __read_mostly ioremap_huge_disabled;
>> +static bool __ro_after_init iomap_max_page_shift = PAGE_SHIFT;
> 
> Must be an int, not a bool.

And the initial value seems wrong. Should be P4D_SHIFT ?

> 
>> ? static int __init set_nohugeiomap(char *str)
>> ? {
>> -??? ioremap_huge_disabled = 1;
>> +??? iomap_max_page_shift = P4D_SHIFT;

And PAGE_SHIFT here when NO hugeiomap ?

>> ????? return 0;
>> ? }
>> ? early_param("nohugeiomap", set_nohugeiomap);

Christophe


From maz at kernel.org  Wed Apr 28 11:29:25 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 28 Apr 2021 11:29:25 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into
 KVM and TCG variants
In-Reply-To: <20210428101844.22656-2-alex.bennee@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
Message-ID: <eaed3c63988513fe2849c2d6f22937af@kernel.org>

On 2021-04-28 11:18, Alex Benn?e wrote:
> A few of the its-trigger tests rely on IMPDEF behaviour where caches
> aren't flushed before invall events. However TCG emulation doesn't
> model any invall behaviour and as we can't probe for it we need to be
> told. Split the test into a KVM and TCG variant and skip the invall
> tests when under TCG.
> 
> Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
> Cc: Shashi Mallela <shashi.mallela at linaro.org>
> ---
>  arm/gic.c         | 60 +++++++++++++++++++++++++++--------------------
>  arm/unittests.cfg | 11 ++++++++-
>  2 files changed, 45 insertions(+), 26 deletions(-)
> 
> diff --git a/arm/gic.c b/arm/gic.c
> index 98135ef..96a329d 100644
> --- a/arm/gic.c
> +++ b/arm/gic.c
> @@ -36,6 +36,7 @@ static struct gic *gic;
>  static int acked[NR_CPUS], spurious[NR_CPUS];
>  static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
>  static cpumask_t ready;
> +static bool under_tcg;
> 
>  static void nr_cpu_check(int nr)
>  {
> @@ -734,32 +735,38 @@ static void test_its_trigger(void)
>  	/*
>  	 * re-enable the LPI but willingly do not call invall
>  	 * so the change in config is not taken into account.
> -	 * The LPI should not hit
> +	 * The LPI should not hit. This does however depend on
> +	 * implementation defined behaviour - under QEMU TCG emulation
> +	 * it can quite correctly process the event directly.

It looks to me that you are using an IMPDEF behaviour of *TCG*
here. The programming model mandates that there is an invalidation
if you change the configuration of the LPI.

         M.
-- 
Jazz is not dead. It just smells funny...


From lkp at intel.com  Wed Apr 28 11:41:16 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 18:41:16 +0800
Subject: [xlnx:xlnx_rebase_v5.4 217/1755]
 drivers/media/i2c/adv7511-v4l2.c:2102:63: sparse: sparse: incorrect type in
 argument 1 (different base types)
Message-ID: <202104281811.XntUdOS2-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: 9836a252284b997aacd6b86766514a0bb84b4f43 [217/1755] drivers: media: Customized adv7511 for Xylon LogiCVC (deprecated)
config: x86_64-randconfig-s022-20210428 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-341-g8af24329-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/9836a252284b997aacd6b86766514a0bb84b4f43
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 9836a252284b997aacd6b86766514a0bb84b4f43
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/media/i2c/adv7511-v4l2.c:427:16: sparse: sparse: return expression in void function
>> drivers/media/i2c/adv7511-v4l2.c:2102:63: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2102:63: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2102:63: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2106:65: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2106:65: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2106:65: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2110:62: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2110:62: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2110:62: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2117:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2117:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2117:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2121:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2121:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2121:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2125:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2125:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2125:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2129:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2129:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2129:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2133:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2133:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2133:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2137:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2137:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2137:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2141:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2141:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2141:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2151:42: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2151:42: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2151:42: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2157:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2157:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2157:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2161:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2161:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2161:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2165:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2165:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2165:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2169:55: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2169:55: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2169:55: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2174:63: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2174:63: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2174:63: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2181:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2181:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2181:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2186:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2186:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2186:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2191:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2191:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2191:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2196:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2196:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2196:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2201:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2201:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2201:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2206:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2206:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2206:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2211:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2211:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2211:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2216:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2216:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2216:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2221:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2221:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2221:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2226:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2226:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2226:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2231:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2231:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2231:72: sparse:     got unsigned int const [usertype] *[assigned] prop
   drivers/media/i2c/adv7511-v4l2.c:2236:72: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected restricted __be32 const [usertype] *p @@     got unsigned int const [usertype] *[assigned] prop @@
   drivers/media/i2c/adv7511-v4l2.c:2236:72: sparse:     expected restricted __be32 const [usertype] *p
   drivers/media/i2c/adv7511-v4l2.c:2236:72: sparse:     got unsigned int const [usertype] *[assigned] prop

vim +2102 drivers/media/i2c/adv7511-v4l2.c

  2086	
  2087	
  2088	static void adv7511_get_ofdt_config(struct i2c_client *client,
  2089		struct adv7511_state *state)
  2090	{
  2091		struct device_node *dn = client->dev.of_node;
  2092		struct device_node *np;
  2093		struct adv7511_config *config = &state->cfg;
  2094		u32 const *prop;
  2095		int size;
  2096		bool vin_loaded, vout_loaded;
  2097	
  2098		vin_loaded = vout_loaded = false;
  2099	
  2100		prop = of_get_property(dn, "edid-addr", &size);
  2101		if (prop)
> 2102			state->pdata.i2c_edid = (uint8_t)be32_to_cpup(prop);
  2103	
  2104		prop = of_get_property(dn, "pktmem-addr", &size);
  2105		if (prop)
  2106			state->pdata.i2c_pktmem = (uint8_t)be32_to_cpup(prop);
  2107	
  2108		prop = of_get_property(dn, "cec-addr", &size);
  2109		if (prop)
  2110			state->pdata.i2c_cec = (uint8_t)be32_to_cpup(prop);
  2111	
  2112		np = of_find_node_by_name(dn, "video-input");
  2113		if (np) {
  2114			prop = of_get_property(np, "input-id", &size);
  2115			if (prop)
  2116				config->in_params.input_id =
  2117					(uint8_t)be32_to_cpup(prop);
  2118			prop = of_get_property(np, "input-style", &size);
  2119			if (prop)
  2120				config->in_params.input_style =
  2121					(uint8_t)be32_to_cpup(prop);
  2122			prop = of_get_property(np, "input-color-depth", &size);
  2123			if (prop)
  2124				config->in_params.input_color_depth =
  2125					(uint8_t)be32_to_cpup(prop);
  2126			prop = of_get_property(np, "bit-justification", &size);
  2127			if (prop)
  2128				config->in_params.bit_justification =
  2129					(uint8_t)be32_to_cpup(prop);
  2130			prop = of_get_property(np, "hsync-polarity", &size);
  2131			if (prop)
  2132				config->in_params.hsync_polarity =
  2133					(uint8_t)be32_to_cpup(prop);
  2134			prop = of_get_property(np, "vsync-polarity", &size);
  2135			if (prop)
  2136				config->in_params.vsync_polarity =
  2137					(uint8_t)be32_to_cpup(prop);
  2138			prop = of_get_property(np, "clock-delay", &size);
  2139			if (prop)
  2140				config->in_params.clock_delay =
  2141					(uint8_t)be32_to_cpup(prop);
  2142			vin_loaded = true;
  2143		} else {
  2144			pr_info("No video input configuration, using device default\n");
  2145		}
  2146	
  2147		np = of_find_node_by_name(dn, "video-output");
  2148		if (np) {
  2149			prop = of_get_property(np, "hdmi-mode", &size);
  2150			if (prop) {
  2151				if (be32_to_cpup(prop) == 1)
  2152					config->out_params.hdmi_mode = true;
  2153			}
  2154			prop = of_get_property(np, "output-format", &size);
  2155			if (prop)
  2156				config->out_params.output_format =
  2157					(uint8_t)be32_to_cpup(prop);
  2158			prop = of_get_property(np, "output-color-space", &size);
  2159			if (prop)
  2160				config->out_params.output_color_space =
  2161					(uint8_t)be32_to_cpup(prop);
  2162			prop = of_get_property(np, "up-conversion", &size);
  2163			if (prop)
  2164				config->out_params.up_conversion =
  2165					(uint8_t)be32_to_cpup(prop);
  2166			prop = of_get_property(np, "csc-enable", &size);
  2167			if (prop)
  2168				config->out_params.csc_enable =
  2169					(uint8_t)be32_to_cpup(prop);
  2170			if (config->out_params.csc_enable) {
  2171				prop = of_get_property(np, "csc-scaling-factor", &size);
  2172				if (prop) {
  2173					config->out_params.csc_scaling_factor =
  2174						(uint8_t)be32_to_cpup(prop);
  2175				}
  2176				np = of_find_node_by_name(dn, "csc-coefficients");
  2177				if (np) {
  2178					prop = of_get_property(np, "a1", &size);
  2179					if (prop) {
  2180						config->out_params.csc_coeff.a1 =
  2181							(uint16_t)be32_to_cpup(prop);
  2182					}
  2183					prop = of_get_property(np, "a2", &size);
  2184					if (prop) {
  2185						config->out_params.csc_coeff.a2 =
  2186							(uint16_t)be32_to_cpup(prop);
  2187					}
  2188					prop = of_get_property(np, "a3", &size);
  2189					if (prop) {
  2190						config->out_params.csc_coeff.a3 =
  2191							(uint16_t)be32_to_cpup(prop);
  2192					}
  2193					prop = of_get_property(np, "a4", &size);
  2194					if (prop) {
  2195						config->out_params.csc_coeff.a4 =
  2196							(uint16_t)be32_to_cpup(prop);
  2197					}
  2198					prop = of_get_property(np, "b1", &size);
  2199					if (prop) {
  2200						config->out_params.csc_coeff.b1 =
  2201							(uint16_t)be32_to_cpup(prop);
  2202					}
  2203					prop = of_get_property(np, "b2", &size);
  2204					if (prop) {
  2205						config->out_params.csc_coeff.b2 =
  2206							(uint16_t)be32_to_cpup(prop);
  2207					}
  2208					prop = of_get_property(np, "b3", &size);
  2209					if (prop) {
  2210						config->out_params.csc_coeff.b3 =
  2211							(uint16_t)be32_to_cpup(prop);
  2212					}
  2213					prop = of_get_property(np, "b4", &size);
  2214					if (prop) {
  2215						config->out_params.csc_coeff.b4 =
  2216							(uint16_t)be32_to_cpup(prop);
  2217					}
  2218					prop = of_get_property(np, "c1", &size);
  2219					if (prop) {
  2220						config->out_params.csc_coeff.c1 =
  2221							(uint16_t)be32_to_cpup(prop);
  2222					}
  2223					prop = of_get_property(np, "c2", &size);
  2224					if (prop) {
  2225						config->out_params.csc_coeff.c2 =
  2226							(uint16_t)be32_to_cpup(prop);
  2227					}
  2228					prop = of_get_property(np, "c3", &size);
  2229					if (prop) {
  2230						config->out_params.csc_coeff.c3 =
  2231							(uint16_t)be32_to_cpup(prop);
  2232					}
  2233					prop = of_get_property(np, "c4", &size);
  2234					if (prop) {
  2235						config->out_params.csc_coeff.c4 =
  2236							(uint16_t)be32_to_cpup(prop);
  2237					}
  2238				} else {
  2239					pr_info("No CSC coefficients, using default\n");
  2240				}
  2241			}
  2242			vout_loaded = true;
  2243		} else {
  2244			pr_info("No video output configuration, using device default\n");
  2245		}
  2246	
  2247		if (vin_loaded && vout_loaded)
  2248			config->loaded = true;
  2249	}
  2250	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29898 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/941848fb/attachment-0001.gz>

From mark.rutland at arm.com  Wed Apr 28 12:15:55 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 28 Apr 2021 12:15:55 +0100
Subject: [PATCH] arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
Message-ID: <20210428111555.50880-1-mark.rutland@arm.com>

Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"
on the command line hits a warning during kernel entry, due to the way
we manipulate the PMR.

Early in the entry sequence, we call lockdep_hardirqs_off() to inform
lockdep that interrupts have been masked (as the HW sets DAIF wqhen
entering an exception). Architecturally PMR_EL1 is not affected by
exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in
the exception entry sequence, so early in exception entry the PMR can
indicate that interrupts are unmasked even though they are masked by
DAIF.

If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that
interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the
exception entry paths, and hence lockdep_hardirqs_off() will WARN() that
something is amiss.

We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during
exception entry so that kernel code sees a consistent environment. We
must also update local_daif_inherit() to undo this, as currently only
touches DAIF. For other paths, local_daif_restore() will update both
DAIF and the PMR. With this done, we can remove the existing special
cases which set this later in the entry code.

We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with
local_daif_save(), as this will warn if it ever encounters
(GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This
matches the gic_prio_kentry_setup that we have to retain for
ret_to_user.

The original splat from Zenghui's report was:

| DEBUG_LOCKS_WARN_ON(!irqs_disabled())
| WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8
| Modules linked in:
| CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+ #463
| Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
| pc : lockdep_hardirqs_off+0xd4/0xe8
| lr : lockdep_hardirqs_off+0xd4/0xe8
| sp : ffff80002a39bad0
| pmr_save: 000000e0
| x29: ffff80002a39bad0 x28: ffff0000de214bc0
| x27: ffff0000de1c0400 x26: 000000000049b328
| x25: 0000000000406f30 x24: ffff0000de1c00a0
| x23: 0000000020400005 x22: ffff8000105f747c
| x21: 0000000096000044 x20: 0000000000498ef9
| x19: ffff80002a39bc88 x18: ffffffffffffffff
| x17: 0000000000000000 x16: ffff800011c61eb0
| x15: ffff800011700a88 x14: 0720072007200720
| x13: 0720072007200720 x12: 0720072007200720
| x11: 0720072007200720 x10: 0720072007200720
| x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
| x7 : ffff8000119f0800 x6 : c0000000ffff7fff
| x5 : ffff8000119f07a8 x4 : 0000000000000001
| x3 : 9bcdab23f2432800 x2 : ffff800011730538
| x1 : 9bcdab23f2432800 x0 : 0000000000000000
| Call trace:
|  lockdep_hardirqs_off+0xd4/0xe8
|  enter_from_kernel_mode.isra.5+0x7c/0xa8
|  el1_abort+0x24/0x100
|  el1_sync_handler+0x80/0xd0
|  el1_sync+0x6c/0x100
|  __arch_clear_user+0xc/0x90
|  load_elf_binary+0x9fc/0x1450
|  bprm_execve+0x404/0x880
|  kernel_execve+0x180/0x188
|  call_usermodehelper_exec_async+0xdc/0x158
|  ret_from_fork+0x10/0x18

Fixes: 23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
Fixes: 7cd1ea1010acbede ("arm64: entry: fix non-NMI kernel<->kernel transitions")
Fixes: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
Fixes: 2a9b3e6ac69a8bf1 ("arm64: entry: fix EL1 debug transitions")
Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3 at huawei.com
Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Reported-by: Zenghui Yu <yuzenghui at huawei.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Marc Zyngier <maz at kernel.org>
Cc: Will Deacon <will at kernel.org>
---
 arch/arm64/include/asm/daifflags.h |  3 +++
 arch/arm64/kernel/entry-common.c   | 17 -----------------
 arch/arm64/kernel/entry.S          | 15 ++-------------
 3 files changed, 5 insertions(+), 30 deletions(-)

diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
index 1c26d7baa67f..cfdde3a56805 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -131,6 +131,9 @@ static inline void local_daif_inherit(struct pt_regs *regs)
 	if (interrupts_enabled(regs))
 		trace_hardirqs_on();
 
+	if (system_uses_irq_prio_masking())
+		gic_write_pmr(regs->pmr_save);
+
 	/*
 	 * We can't use local_daif_restore(regs->pstate) here as
 	 * system_has_prio_mask_debugging() won't restore the I bit if it can
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 9d3588450473..117412bae915 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -226,14 +226,6 @@ static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr)
 {
 	unsigned long far = read_sysreg(far_el1);
 
-	/*
-	 * The CPU masked interrupts, and we are leaving them masked during
-	 * do_debug_exception(). Update PMR as if we had called
-	 * local_daif_mask().
-	 */
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	arm64_enter_el1_dbg(regs);
 	if (!cortex_a76_erratum_1463225_debug_handler(regs))
 		do_debug_exception(far, esr, regs);
@@ -398,9 +390,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
 	/* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */
 	unsigned long far = read_sysreg(far_el1);
 
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	do_debug_exception(far, esr, regs);
 	local_daif_restore(DAIF_PROCCTX_NOIRQ);
@@ -408,9 +397,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
 
 static void noinstr el0_svc(struct pt_regs *regs)
 {
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	cortex_a76_erratum_1463225_svc_handler();
 	do_el0_svc(regs);
@@ -486,9 +472,6 @@ static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
 
 static void noinstr el0_svc_compat(struct pt_regs *regs)
 {
-	if (system_uses_irq_prio_masking())
-		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
-
 	enter_from_user_mode();
 	cortex_a76_erratum_1463225_svc_handler();
 	do_el0_svc_compat(regs);
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 6acfc5e6b5e0..941bb52b5e21 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -292,6 +292,8 @@ alternative_else_nop_endif
 alternative_if ARM64_HAS_IRQ_PRIO_MASKING
 	mrs_s	x20, SYS_ICC_PMR_EL1
 	str	x20, [sp, #S_PMR_SAVE]
+	mov	x20, #GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET
+	msr_s	SYS_ICC_PMR_EL1, x20
 alternative_else_nop_endif
 
 	/* Re-enable tag checking (TCO set on exception entry) */
@@ -524,15 +526,6 @@ alternative_endif
 #endif
 	.endm
 
-	.macro	gic_prio_irq_setup, pmr:req, tmp:req
-#ifdef CONFIG_ARM64_PSEUDO_NMI
-	alternative_if ARM64_HAS_IRQ_PRIO_MASKING
-	orr	\tmp, \pmr, #GIC_PRIO_PSR_I_SET
-	msr_s	SYS_ICC_PMR_EL1, \tmp
-	alternative_else_nop_endif
-#endif
-	.endm
-
 	.text
 
 /*
@@ -662,7 +655,6 @@ SYM_CODE_END(el1_sync)
 	.align	6
 SYM_CODE_START_LOCAL_NOALIGN(el1_irq)
 	kernel_entry 1
-	gic_prio_irq_setup pmr=x20, tmp=x1
 	enable_da_f
 
 	mov	x0, sp
@@ -727,7 +719,6 @@ SYM_CODE_END(el0_error_compat)
 SYM_CODE_START_LOCAL_NOALIGN(el0_irq)
 	kernel_entry 0
 el0_irq_naked:
-	gic_prio_irq_setup pmr=x20, tmp=x0
 	user_exit_irqoff
 	enable_da_f
 
@@ -742,7 +733,6 @@ SYM_CODE_END(el0_irq)
 SYM_CODE_START_LOCAL(el1_error)
 	kernel_entry 1
 	mrs	x1, esr_el1
-	gic_prio_kentry_setup tmp=x2
 	enable_dbg
 	mov	x0, sp
 	bl	do_serror
@@ -753,7 +743,6 @@ SYM_CODE_START_LOCAL(el0_error)
 	kernel_entry 0
 el0_error_naked:
 	mrs	x25, esr_el1
-	gic_prio_kentry_setup tmp=x2
 	user_exit_irqoff
 	enable_dbg
 	mov	x0, sp
-- 
2.11.0



From james.clark at arm.com  Wed Apr 28 12:30:18 2021
From: james.clark at arm.com (James Clark)
Date: Wed, 28 Apr 2021 14:30:18 +0300
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <df3bcfcb-eacf-7807-6c26-e4b94bce80d3@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <df3bcfcb-eacf-7807-6c26-e4b94bce80d3@arm.com>
Message-ID: <ee3fba50-6cf6-f46e-744d-e2b5a1f6e247@arm.com>



On 27/04/2021 19:24, James Clark wrote:
> 
> 
> On 21/04/2021 15:04, Daniel Kiss wrote:
>> This series adds a feature to ETR-PERF that sync the ETR buffer to perf
>> periodically. This is really handy when the system wide trace is used
>> because in this case the perf won't sync during the trace. In a per-thread
>> setup the traced program might not go to the kernel frequvently enought
>> to collect trace. Polling helps in both usecases. Can be used with strobing.
>> Tuning polling period is challanging, I'm working on an additional patch
>> that adds some metrics to help tune the polling period.
> 
> Hi Daniel,
> 
> Is the expectation that leaving the polling period at 0 should have no affect
> on the amount of data collected vs not using this patch?
> 
> I've been running the octane 2 benchmark on Chrome on Juno and get these results:
> 
>   No patch:             I consistently get 130MB of trace across dozens of runs.
>   Patch, polling = 0:   Run 1 - 6.1MB
>                         Run 2 - 4.7MB

Sorry, these small files are because there is no AUXTRACE event at all, only built in events. It's not small because
less trace was collected.

>   Patch, polling = 100: 1600MB
> 
> 
> Thanks
> James
> 
>>
>> Daniel Kiss (4):
>>   coresight: tmc-etr: Advance buffer pointer in sync buffer.
>>   coresight: tmc-etr: Track perf handler.
>>   coresight: etm-perf: Export etm_event_cpu_path.
>>   coresight: Add ETR-PERF polling.
>>
>>  .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
>>  drivers/hwtracing/coresight/Makefile          |   2 +-
>>  .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
>>  .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
>>  .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
>>  .../coresight/coresight-etr-perf-polling.h    |  42 +++
>>  .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
>>  .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
>>  drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>>  9 files changed, 401 insertions(+), 4 deletions(-)
>>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
>>  create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h
>>


From Daniel.Kiss at arm.com  Wed Apr 28 12:52:44 2021
From: Daniel.Kiss at arm.com (Daniel Kiss)
Date: Wed, 28 Apr 2021 11:52:44 +0000
Subject: [PATCH 0/4] coresight: Add ETR-PERF polling.
In-Reply-To: <df3bcfcb-eacf-7807-6c26-e4b94bce80d3@arm.com>
References: <20210421120413.3110775-1-daniel.kiss@arm.com>
 <df3bcfcb-eacf-7807-6c26-e4b94bce80d3@arm.com>
Message-ID: <C11AC98E-1AD6-4CCC-B283-51EBA6523ED4@arm.com>



> On 27 Apr 2021, at 18:24, James Clark <James.Clark at arm.com> wrote:
> 
> 
> 
> On 21/04/2021 15:04, Daniel Kiss wrote:
>> This series adds a feature to ETR-PERF that sync the ETR buffer to perf
>> periodically. This is really handy when the system wide trace is used
>> because in this case the perf won't sync during the trace. In a per-thread
>> setup the traced program might not go to the kernel frequvently enought
>> to collect trace. Polling helps in both usecases. Can be used with strobing.
>> Tuning polling period is challanging, I'm working on an additional patch
>> that adds some metrics to help tune the polling period.
> 
> Hi Daniel,
> 
> Is the expectation that leaving the polling period at 0 should have no affect
> on the amount of data collected vs not using this patch?
> 
> I've been running the octane 2 benchmark on Chrome on Juno and get these results:
> 
>  No patch:             I consistently get 130MB of trace across dozens of runs.
>  Patch, polling = 0:   Run 1 - 6.1MB
>                        Run 2 - 4.7MB
>  Patch, polling = 100: 1600MB

Polling = 0 should not change the behaviour. 
We noticed this too, which is a bug. 
I?m going to drop the "coresight: tmc-etr: Track perf handler.?  patch, because it causes it.
Seems the csdev->refcnt and drvdata->perf_handle are out of sync 

Thanks,
Daniel



> Thanks
> James
> 
>> 
>> Daniel Kiss (4):
>>  coresight: tmc-etr: Advance buffer pointer in sync buffer.
>>  coresight: tmc-etr: Track perf handler.
>>  coresight: etm-perf: Export etm_event_cpu_path.
>>  coresight: Add ETR-PERF polling.
>> 
>> .../testing/sysfs-bus-coresight-devices-tmc   |   8 +
>> drivers/hwtracing/coresight/Makefile          |   2 +-
>> .../hwtracing/coresight/coresight-etm-perf.c  |  10 +-
>> .../hwtracing/coresight/coresight-etm-perf.h  |   1 +
>> .../coresight/coresight-etr-perf-polling.c    | 316 ++++++++++++++++++
>> .../coresight/coresight-etr-perf-polling.h    |  42 +++
>> .../hwtracing/coresight/coresight-tmc-core.c  |   2 +
>> .../hwtracing/coresight/coresight-tmc-etr.c   |  22 +-
>> drivers/hwtracing/coresight/coresight-tmc.h   |   2 +
>> 9 files changed, 401 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.c
>> create mode 100644 drivers/hwtracing/coresight/coresight-etr-perf-polling.h
>> 


From alex.bennee at linaro.org  Wed Apr 28 13:06:18 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 13:06:18 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test
 into KVM and TCG variants
In-Reply-To: <eaed3c63988513fe2849c2d6f22937af@kernel.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org>
Message-ID: <87fszasjdg.fsf@linaro.org>


Marc Zyngier <maz at kernel.org> writes:

> On 2021-04-28 11:18, Alex Benn?e wrote:
>> A few of the its-trigger tests rely on IMPDEF behaviour where caches
>> aren't flushed before invall events. However TCG emulation doesn't
>> model any invall behaviour and as we can't probe for it we need to be
>> told. Split the test into a KVM and TCG variant and skip the invall
>> tests when under TCG.
>> Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
>> Cc: Shashi Mallela <shashi.mallela at linaro.org>
>> ---
>>  arm/gic.c         | 60 +++++++++++++++++++++++++++--------------------
>>  arm/unittests.cfg | 11 ++++++++-
>>  2 files changed, 45 insertions(+), 26 deletions(-)
>> diff --git a/arm/gic.c b/arm/gic.c
>> index 98135ef..96a329d 100644
>> --- a/arm/gic.c
>> +++ b/arm/gic.c
>> @@ -36,6 +36,7 @@ static struct gic *gic;
>>  static int acked[NR_CPUS], spurious[NR_CPUS];
>>  static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
>>  static cpumask_t ready;
>> +static bool under_tcg;
>>  static void nr_cpu_check(int nr)
>>  {
>> @@ -734,32 +735,38 @@ static void test_its_trigger(void)
>>  	/*
>>  	 * re-enable the LPI but willingly do not call invall
>>  	 * so the change in config is not taken into account.
>> -	 * The LPI should not hit
>> +	 * The LPI should not hit. This does however depend on
>> +	 * implementation defined behaviour - under QEMU TCG emulation
>> +	 * it can quite correctly process the event directly.
>
> It looks to me that you are using an IMPDEF behaviour of *TCG*
> here. The programming model mandates that there is an invalidation
> if you change the configuration of the LPI.

But does it mandate that the LPI cannot be sent until the invalidation?

>
>         M.


-- 
Alex Benn?e


From roman.beranek at prusa3d.cz  Wed Apr 28 13:14:31 2021
From: roman.beranek at prusa3d.cz (=?UTF-8?Q?Roman_Ber=C3=A1nek?=)
Date: Wed, 28 Apr 2021 14:14:31 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <20210428061357.725m72aikc52n4gg@pengutronix.de>
References: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
 <20210428061357.725m72aikc52n4gg@pengutronix.de>
Message-ID: <CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ@mail.gmail.com>

Hello Uwe,

Correct, the output may stay in an active state. I only discovered this
bug as I investigated a report of unreliable screen timeout. The period
we use the PWM with is 50 us.

The PWMx_RDY bit stays 0 well after the last period ends, so if the bit
has any function at all, this one is certainly not it.

Cheers,
Roman

Note: my apologies for the previous HTML message


On Wed, Apr 28, 2021 at 8:14 AM Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:
>
> Hello Roman,
>
> On Wed, Apr 28, 2021 at 02:19:46AM +0200, Roman Beranek wrote:
> > More often than not, a PWM period may span nowhere near as far
> > as 1 jiffy, yet it still must be waited upon before the channel
> > is disabled.
>
> I wonder what happens if you don't wait long enough. Is this a
> theoretical issue, or do you see an (occasional?) breakage that is fixed
> by this patch?
>
> I guess the problem is that if you disable too early the output freezes
> and that might be in a state where the output is still active? Would
> polling the PWMx_RDY bit in the control register help here?
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | https://www.pengutronix.de/ |


From broonie at kernel.org  Wed Apr 28 13:12:31 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 28 Apr 2021 13:12:31 +0100
Subject: [PATCH] arm64: Generate cpucaps.h
Message-ID: <20210428121231.11219-1-broonie@kernel.org>

The arm64 code allocates an internal constant to every CPU feature it can
detect, distinct from the public hwcap numbers we use to expose some
features to userspace. Currently this is maintained manually which is an
irritating source of conflicts when working on new features, to avoid this
replace the header with a simple text file listing the names we've assigned
and sort it to minimise conflicts.

As part of doing this we also do the Kbuild hookup required to hook up
an arch tools directory and to generate header files in there.

This will result in a renumbering and reordering of the existing constants,
since they are all internal only the values should not be important. The
reordering will impact the order in which some steps in enumeration handle
features but the algorithm is not intended to depend on this and I haven't
seen any issues when testing. Due to the UAO cpucap having been removed in
the past we end up with ARM64_NCAPS being 1 smaller than it was before.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 arch/arm64/Makefile              |  3 ++
 arch/arm64/include/asm/Kbuild    |  2 +
 arch/arm64/include/asm/cpucaps.h | 74 --------------------------------
 arch/arm64/tools/Makefile        | 22 ++++++++++
 arch/arm64/tools/cpucaps         | 65 ++++++++++++++++++++++++++++
 arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++
 6 files changed, 132 insertions(+), 74 deletions(-)
 delete mode 100644 arch/arm64/include/asm/cpucaps.h
 create mode 100644 arch/arm64/tools/Makefile
 create mode 100644 arch/arm64/tools/cpucaps
 create mode 100755 arch/arm64/tools/gen-cpucaps.awk

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 7ef44478560d..b52481f0605d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -175,6 +175,9 @@ vdso_install:
 	$(if $(CONFIG_COMPAT_VDSO), \
 		$(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso32 $@)
 
+archprepare:
+	$(Q)$(MAKE) $(build)=arch/arm64/tools kapi
+
 # We use MRPROPER_FILES and CLEAN_FILES now
 archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 73aa25843f65..64202010b700 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,3 +4,5 @@ generic-y += mcs_spinlock.h
 generic-y += qrwlock.h
 generic-y += qspinlock.h
 generic-y += user.h
+
+generated-y += cpucaps.h
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
deleted file mode 100644
index b0c5eda0498f..000000000000
--- a/arch/arm64/include/asm/cpucaps.h
+++ /dev/null
@@ -1,74 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * arch/arm64/include/asm/cpucaps.h
- *
- * Copyright (C) 2016 ARM Ltd.
- */
-#ifndef __ASM_CPUCAPS_H
-#define __ASM_CPUCAPS_H
-
-#define ARM64_WORKAROUND_CLEAN_CACHE		0
-#define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE	1
-#define ARM64_WORKAROUND_845719			2
-#define ARM64_HAS_SYSREG_GIC_CPUIF		3
-#define ARM64_HAS_PAN				4
-#define ARM64_HAS_LSE_ATOMICS			5
-#define ARM64_WORKAROUND_CAVIUM_23154		6
-#define ARM64_WORKAROUND_834220			7
-#define ARM64_HAS_NO_HW_PREFETCH		8
-#define ARM64_HAS_VIRT_HOST_EXTN		11
-#define ARM64_WORKAROUND_CAVIUM_27456		12
-#define ARM64_HAS_32BIT_EL0			13
-#define ARM64_SPECTRE_V3A			14
-#define ARM64_HAS_CNP				15
-#define ARM64_HAS_NO_FPSIMD			16
-#define ARM64_WORKAROUND_REPEAT_TLBI		17
-#define ARM64_WORKAROUND_QCOM_FALKOR_E1003	18
-#define ARM64_WORKAROUND_858921			19
-#define ARM64_WORKAROUND_CAVIUM_30115		20
-#define ARM64_HAS_DCPOP				21
-#define ARM64_SVE				22
-#define ARM64_UNMAP_KERNEL_AT_EL0		23
-#define ARM64_SPECTRE_V2			24
-#define ARM64_HAS_RAS_EXTN			25
-#define ARM64_WORKAROUND_843419			26
-#define ARM64_HAS_CACHE_IDC			27
-#define ARM64_HAS_CACHE_DIC			28
-#define ARM64_HW_DBM				29
-#define ARM64_SPECTRE_V4			30
-#define ARM64_MISMATCHED_CACHE_TYPE		31
-#define ARM64_HAS_STAGE2_FWB			32
-#define ARM64_HAS_CRC32				33
-#define ARM64_SSBS				34
-#define ARM64_WORKAROUND_1418040		35
-#define ARM64_HAS_SB				36
-#define ARM64_WORKAROUND_SPECULATIVE_AT		37
-#define ARM64_HAS_ADDRESS_AUTH_ARCH		38
-#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF		39
-#define ARM64_HAS_GENERIC_AUTH_ARCH		40
-#define ARM64_HAS_GENERIC_AUTH_IMP_DEF		41
-#define ARM64_HAS_IRQ_PRIO_MASKING		42
-#define ARM64_HAS_DCPODP			43
-#define ARM64_WORKAROUND_1463225		44
-#define ARM64_WORKAROUND_CAVIUM_TX2_219_TVM	45
-#define ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM	46
-#define ARM64_WORKAROUND_1542419		47
-#define ARM64_HAS_E0PD				48
-#define ARM64_HAS_RNG				49
-#define ARM64_HAS_AMU_EXTN			50
-#define ARM64_HAS_ADDRESS_AUTH			51
-#define ARM64_HAS_GENERIC_AUTH			52
-#define ARM64_HAS_32BIT_EL1			53
-#define ARM64_BTI				54
-#define ARM64_HAS_ARMv8_4_TTL			55
-#define ARM64_HAS_TLB_RANGE			56
-#define ARM64_MTE				57
-#define ARM64_WORKAROUND_1508412		58
-#define ARM64_HAS_LDAPR				59
-#define ARM64_KVM_PROTECTED_MODE		60
-#define ARM64_WORKAROUND_NVIDIA_CARMEL_CNP	61
-#define ARM64_HAS_EPAN				62
-
-#define ARM64_NCAPS				63
-
-#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/tools/Makefile b/arch/arm64/tools/Makefile
new file mode 100644
index 000000000000..932b4fe5c768
--- /dev/null
+++ b/arch/arm64/tools/Makefile
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0
+
+gen := arch/$(ARCH)/include/generated
+kapi := $(gen)/asm
+
+kapi-hdrs-y := $(kapi)/cpucaps.h
+
+targets += $(addprefix ../../../,$(gen-y) $(kapi-hdrs-y))
+
+PHONY += kapi
+
+kapi:   $(kapi-hdrs-y) $(gen-y)
+
+# Create output directory if not already present
+_dummy := $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
+
+quiet_cmd_gen_cpucaps = GEN     $@
+      cmd_gen_cpucaps = mkdir -p $(dir $@) && \
+                     $(AWK) -f $(filter-out $(PHONY),$^) > $@
+
+$(kapi)/cpucaps.h: $(src)/gen-cpucaps.awk $(src)/cpucaps FORCE
+	$(call if_changed,gen_cpucaps)
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
new file mode 100644
index 000000000000..21fbdda7086e
--- /dev/null
+++ b/arch/arm64/tools/cpucaps
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Internal CPU capabilities constants, keep this list sorted
+
+BTI
+HAS_32BIT_EL0
+HAS_32BIT_EL1
+HAS_ADDRESS_AUTH
+HAS_ADDRESS_AUTH_ARCH
+HAS_ADDRESS_AUTH_IMP_DEF
+HAS_AMU_EXTN
+HAS_ARMv8_4_TTL
+HAS_CACHE_DIC
+HAS_CACHE_IDC
+HAS_CNP
+HAS_CRC32
+HAS_DCPODP
+HAS_DCPOP
+HAS_E0PD
+HAS_EPAN
+HAS_GENERIC_AUTH
+HAS_GENERIC_AUTH_ARCH
+HAS_GENERIC_AUTH_IMP_DEF
+HAS_IRQ_PRIO_MASKING
+HAS_LDAPR
+HAS_LSE_ATOMICS
+HAS_NO_FPSIMD
+HAS_NO_HW_PREFETCH
+HAS_PAN
+HAS_RAS_EXTN
+HAS_RNG
+HAS_SB
+HAS_STAGE2_FWB
+HAS_SYSREG_GIC_CPUIF
+HAS_TLB_RANGE
+HAS_VIRT_HOST_EXTN
+HW_DBM
+KVM_PROTECTED_MODE
+MISMATCHED_CACHE_TYPE
+MTE
+SPECTRE_V2
+SPECTRE_V3A
+SPECTRE_V4
+SSBS
+SVE
+UNMAP_KERNEL_AT_EL0
+WORKAROUND_834220
+WORKAROUND_843419
+WORKAROUND_845719
+WORKAROUND_858921
+WORKAROUND_1418040
+WORKAROUND_1463225
+WORKAROUND_1508412
+WORKAROUND_1542419
+WORKAROUND_CAVIUM_23154
+WORKAROUND_CAVIUM_27456
+WORKAROUND_CAVIUM_30115
+WORKAROUND_CAVIUM_TX2_219_PRFM
+WORKAROUND_CAVIUM_TX2_219_TVM
+WORKAROUND_CLEAN_CACHE
+WORKAROUND_DEVICE_LOAD_ACQUIRE
+WORKAROUND_NVIDIA_CARMEL_CNP
+WORKAROUND_QCOM_FALKOR_E1003
+WORKAROUND_REPEAT_TLBI
+WORKAROUND_SPECULATIVE_AT
diff --git a/arch/arm64/tools/gen-cpucaps.awk b/arch/arm64/tools/gen-cpucaps.awk
new file mode 100755
index 000000000000..18737a1ce044
--- /dev/null
+++ b/arch/arm64/tools/gen-cpucaps.awk
@@ -0,0 +1,40 @@
+#!/bin/awk -f
+# SPDX-License-Identifier: GPL-2.0
+# gen-cpucaps.awk: arm64 cpucaps header generator
+#
+# Usage: awk -f gen-cpucaps.awk cpucaps.txt
+
+# Log an error and terminate
+function fatal(msg) {
+	print "Error at line " NR ": " msg > "/dev/stderr"
+	exit 1
+}
+
+# skip blank lines and comment lines
+/^$/ { next }
+/^#/ { next }
+
+BEGIN {
+	print "#ifndef __ASM_CPUCAPS_H"
+	print "#define __ASM_CPUCAPS_H"
+	print ""
+	print "/* Generated file - do not edit */"
+	cap_num = 0
+	print ""
+}
+
+/^[vA-Z0-9_]+$/ {
+	printf("#define ARM64_%-30s\t%d\n", $0, cap_num++)
+	next
+}
+
+END {
+	printf("#define ARM64_NCAPS\t\t\t\t%d\n", cap_num)
+	print ""
+	print "#endif"
+}
+
+# Any lines not handled by previous rules are unexpected
+{
+	fatal("unhandled statement")
+}
-- 
2.20.1



From ykaukab at suse.de  Wed Apr 28 13:58:07 2021
From: ykaukab at suse.de (Mian Yousaf Kaukab)
Date: Wed, 28 Apr 2021 14:58:07 +0200
Subject: [PATCH] arm64: dts: ls208xa: remove bus-num from dspi node
Message-ID: <20210428125807.29553-1-ykaukab@suse.de>

On LS2088A-RDB board, if the spi-fsl-dspi driver is built as module
then its probe fails with the following warning:

[   10.471363] couldn't get idr
[   10.471381] WARNING: CPU: 4 PID: 488 at drivers/spi/spi.c:2689 spi_register_controller+0x73c/0x8d0
...
[   10.471651] fsl-dspi 2100000.spi: Problem registering DSPI ctlr
[   10.471708] fsl-dspi: probe of 2100000.spi failed with error -16

Reason for the failure is that bus-num property is set for dspi node.
However, bus-num property is not set for the qspi node. If probe for
spi-fsl-qspi happens first then id 0 is dynamically allocated to it.
Call to spi_register_controller() from spi-fsl-dspi driver then fails.
Since commit 29d2daf2c33c ("spi: spi-fsl-dspi: Make bus-num property
optional") bus-num property is optional. Remove bus-num property from
dspi node to fix the issue.

Signed-off-by: Mian Yousaf Kaukab <ykaukab at suse.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 135ac8210871..801ba9612d36 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -929,7 +929,6 @@ dspi: spi at 2100000 {
 					    QORIQ_CLK_PLL_DIV(4)>;
 			clock-names = "dspi";
 			spi-num-chipselects = <5>;
-			bus-num = <0>;
 		};
 
 		esdhc: esdhc at 2140000 {
-- 
2.26.2



From aford173 at gmail.com  Wed Apr 28 14:00:58 2021
From: aford173 at gmail.com (Adam Ford)
Date: Wed, 28 Apr 2021 08:00:58 -0500
Subject: [PATCH] arm64: dts: imx8mn-beacon-som: Assign PMIC clock
Message-ID: <20210428130058.402131-1-aford173@gmail.com>

The PMIC throws an errors because the clock isn't assigned to it.
Fix this by assigning the clocks info.

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index c35eeaff958f..54eaf3d6055b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -120,6 +120,9 @@ pmic at 4b {
 		interrupt-parent = <&gpio1>;
 		interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
 		rohm,reset-snvs-powered;
+		#clock-cells = <0>;
+		clocks = <&osc_32k 0>;
+		clock-output-names = "clk-32k-out";
 
 		regulators {
 			buck1_reg: BUCK1 {
-- 
2.25.1



From vincent.guittot at linaro.org  Wed Apr 28 14:04:16 2021
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Wed, 28 Apr 2021 15:04:16 +0200
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <b42c762a287b4360bfa3179a5c7c3e8c@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
 <20210420001844.9116-4-song.bao.hua@hisilicon.com>
 <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>
 <b42c762a287b4360bfa3179a5c7c3e8c@hisilicon.com>
Message-ID: <CAKfTPtC51eO2mAuW6mHQ-SdznAtfDL3D4UOs4HmnXaPOOCN_cA@mail.gmail.com>

On Wed, 28 Apr 2021 at 11:51, Song Bao Hua (Barry Song)
<song.bao.hua at hisilicon.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]
> > Sent: Tuesday, April 27, 2021 11:36 PM
> > To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>;
> > tim.c.chen at linux.intel.com; catalin.marinas at arm.com; will at kernel.org;
> > rjw at rjwysocki.net; vincent.guittot at linaro.org; bp at alien8.de;
> > tglx at linutronix.de; mingo at redhat.com; lenb at kernel.org; peterz at infradead.org;
> > rostedt at goodmis.org; bsegall at google.com; mgorman at suse.de
> > Cc: msys.mizuma at gmail.com; valentin.schneider at arm.com;
> > gregkh at linuxfoundation.org; Jonathan Cameron <jonathan.cameron at huawei.com>;
> > juri.lelli at redhat.com; mark.rutland at arm.com; sudeep.holla at arm.com;
> > aubrey.li at linux.intel.com; linux-arm-kernel at lists.infradead.org;
> > linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; x86 at kernel.org;
> > xuwei (O) <xuwei5 at huawei.com>; Zengtao (B) <prime.zeng at hisilicon.com>;
> > guodong.xu at linaro.org; yangyicong <yangyicong at huawei.com>; Liguozhu (Kenneth)
> > <liguozhu at hisilicon.com>; linuxarm at openeuler.org; hpa at zytor.com
> > Subject: Re: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
> > within one LLC
> >
> > On 20/04/2021 02:18, Barry Song wrote:
> >
> > [...]
> >
> > > @@ -5786,11 +5786,12 @@ static void record_wakee(struct task_struct *p)
> > >   * whatever is irrelevant, spread criteria is apparent partner count exceeds
> > >   * socket size.
> > >   */
> > > -static int wake_wide(struct task_struct *p)
> > > +static int wake_wide(struct task_struct *p, int cluster)
> > >  {
> > >     unsigned int master = current->wakee_flips;
> > >     unsigned int slave = p->wakee_flips;
> > > -   int factor = __this_cpu_read(sd_llc_size);
> > > +   int factor = cluster ? __this_cpu_read(sd_cluster_size) :
> > > +           __this_cpu_read(sd_llc_size);
> >
> > I don't see that the wake_wide() change has any effect here. None of the
> > sched domains has SD_BALANCE_WAKE set so a wakeup (WF_TTWU) can never
> > end up in the slow path.
>
> I am really confused. The whole code has only checked if wake_flags
> has WF_TTWU, it has never checked if sd_domain has SD_BALANCE_WAKE flag.

look at :
#define WF_TTWU     0x08 /* Wakeup;            maps to SD_BALANCE_WAKE */

so  when wake_wide return false, we use the wake_affine mecanism but
if it's false then we fllback to default mode which looks for:
if (tmp->flags & sd_flag)

This means looking for SD_BALANCE_WAKE which is never set

so sd will stay NULL and you will end up calling select_idle_sibling anyway

>
> static int
> select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
> {
>         ...
>
>         if (wake_flags & WF_TTWU) {
>                 record_wakee(p);
>
>                 if (sched_energy_enabled()) {
>                         new_cpu = find_energy_efficient_cpu(p, prev_cpu);
>                         if (new_cpu >= 0)
>                                 return new_cpu;
>                         new_cpu = prev_cpu;
>                 }
>
>                 want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
>         }
> }
>
> And try_to_wake_up() has always set WF_TTWU:
> static int
> try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> {
>         cpu = select_task_rq(p, p->wake_cpu, wake_flags | WF_TTWU);
>         ...
> }
>
> So the change in wake_wide will actually affect the value of want_affine.
> And I did also see code entered slow path during my benchmark.
>
> One issue I mentioned during linaro open discussion is that
> since I have moved to use cluster size to decide the value
> of wake_wide, relatively less tasks will make wake_wide()
> decide to go to slow path, thus, tasks begin to spread to
> other NUMA,  but actually llc_size might be able to contain
> those tasks. So a possible model might be:
> static int wake_wide(struct task_struct *p)
> {
>         tasksize < cluster : scan cluster
>         tasksize > llc      : slow path
>         tasksize > cluster && tasksize < llc: scan llc
> }
>
> thoughts?
>
> > Have you seen a diff when running your `lmbench stream` workload in what
> > wake_wide() returns when you use `sd cluster size` instead of `sd llc
> > size` as factor?
> >
> > I guess for you,  wakeups are now subdivided into faster (cluster = 4
> > CPUs) and fast (llc = 24 CPUs) via sis(), not into fast (sis()) and slow
> > (find_idlest_cpu()).
> >
> > >
> > >     if (master < slave)
> > >             swap(master, slave);
> >
> > [...]
> >
> > > @@ -6745,6 +6748,12 @@ static int find_energy_efficient_cpu(struct
> > task_struct *p, int prev_cpu)
> > >     int want_affine = 0;
> > >     /* SD_flags and WF_flags share the first nibble */
> > >     int sd_flag = wake_flags & 0xF;
> > > +   /*
> > > +    * if cpu and prev_cpu share LLC, consider cluster sibling rather
> > > +    * than llc. this is typically true while tasks are bound within
> > > +    * one numa
> > > +    */
> > > +   int cluster = sched_cluster_active() && cpus_share_cache(cpu, prev_cpu, 0);
> >
> > So you changed from scanning cluster before LLC to scan either cluster
> > or LLC.
>
> Yes, I have seen two ugly things for scanning cluster before scanning LLC
> in select_idle_cpu.
> 1. avg_scan_cost is actually measuring the scanning time. But if we scan
> cluster before scanning LLC, during the gap of these two different
> domains, we need a huge bit operation and this bit operation is not
> a scanning operation at all. This makes the scan_cost quite
> untrustworthy particularly "nr" can sometimes be < cluster size, sometimes
> > cluster size.
>
> 2. select_idle_cpu() is actually the last step of wake_affine, before
> that, wake_affine code has been totally depending on cpus_share_cache()
> to decide the target to scan from. When waker and wakee have been already
> in one LLC, if we only change select_idle_cpu(), at that time, decision
> has been made. we may lose some chance to choose the right target to scan
> from. So it should be more sensible to let cpus_share_cache() check cluster
> when related tasks have been in one same LLC.
>
> >
> > And this is based on whether `this_cpu` and `prev_cpu` are sharing LLC
> > or not. So you only see an effect when running the workload with
> > `numactl -N X ...`.
>
> Ideally, I'd expect this can also positively affect tasks located in
> different LLCs.
> For example, if taskA and taskB are in different NUMAs(also LLC for both
> kunpeng920 and Tim's hardware) at the first beginning, a two-stage packing
> might make them take the advantage of cluster:
> For the first wake-up, taskA and taskB will be put in one LLC by scanning
> LLC;
> For the second wake-up, they might be put in one cluster by scanning
> cluster.
> So ideally, scanning LLC and scanning cluster can work in two stages
> for related tasks and pack them step by step. Practically, this
> could happen. But LB between NUMA might take the opposite way. Actually,
> for a kernel completely *without* cluster patch, I have seen some
> serious ping-pong of tasks in two numa nodes due to the conflict
> of wake_affine and LB. this kind of ping-pong could seriously affect
> the performance.
> For example, for g=6,12,18,24,28,32, I have found running same workload
> on 2numa shows so much worse latency than doing that on single one
> numa(each numa has 24 cpus).
> 1numa command: numactl -N 0 hackbench -p -T -l 1000000 -f 1 -g $1
> 2numa command: numactl -N 0-1 hackbench -p -T -l 1000000 -f 1 -g $1
>
> Measured the average latency of 20 times for each command.
>
> *)without cluster scheduler, 2numa vs 1numa:
> g      =     6     12     18    24      28     32
> 1numa      1.2474 1.5635 1.5133 1.4796 1.6177 1.7898
> 2numa      4.1997 5.8172 6.0159 7.2343 6.8264 6.5419
>
> BTW, my cluster patch actually also improves 2numa:
> *)with cluster scheduler 2numa vs 1numa:
> g      =     6     12     18    24      28     32
> 1numa      0.9500 1.0728 1.1756 1.2201 1.4166 1.5464
> 2numa      3.5404 4.3744 4.3988 4.6994 5.3117 5.4908
>
> *) 2numa  w/ and w/o cluster:
> g          =     6     12     18    24      28     32
> 2numa w/o      4.1997 5.8172 6.0159 7.2343 6.8264 6.5419
> 2numa w/       3.5404 4.3744 4.3988 4.6994 5.3117 5.4908
>
> Ideally, load balance should try to pull unmarried tasks rather than
> married tasks. I mean, if we have
> groupA: task1+task2 as couple, task3 as bachelor
> groupB: task4.
> groupB should try to pull task3. But I feel it is extremely hard to let
> LB understand who is married and who is unmarried.
>
> I assume 2numa worse than 1numa should be a different topic
> which might be worth more investigation.
>
> On the other hand, use cases I'm now targeting at are really using
> "numactl -N x" to bind processes in one NUMA. If we ignore other NUMA
> (also other LLCs) and think one NUMA as a whole system, cluster would
> be the last-level topology scheduler can use. And the code could be
> quite clean to directly leverage the existing select_sibling code for
> LLC by simply changing cpus_share_cache() to cluster level.
>
> >
> > >
> > >     if (wake_flags & WF_TTWU) {
> > >             record_wakee(p);
> > > @@ -6756,7 +6765,7 @@ static int find_energy_efficient_cpu(struct task_struct
> > *p, int prev_cpu)
> > >                     new_cpu = prev_cpu;
> > >             }
> > >
> > > -           want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
> > > +           want_affine = !wake_wide(p, cluster) && cpumask_test_cpu(cpu,
> > p->cpus_ptr);
> > >     }
> > >
> > >     rcu_read_lock();
> > > @@ -6768,7 +6777,7 @@ static int find_energy_efficient_cpu(struct task_struct
> > *p, int prev_cpu)
> > >             if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
> > >                 cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
> > >                     if (cpu != prev_cpu)
> > > -                           new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
> > > +                           new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync, cluster);
> > >
> > >                     sd = NULL; /* Prefer wake_affine over balance flags */
> > >                     break;
> > > @@ -6785,7 +6794,7 @@ static int find_energy_efficient_cpu(struct task_struct
> > *p, int prev_cpu)
> > >             new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
> > >     } else if (wake_flags & WF_TTWU) { /* XXX always ? */
> > >             /* Fast path */
> > > -           new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
> > > +           new_cpu = select_idle_sibling(p, prev_cpu, new_cpu, cluster);
> > >
> > >             if (want_affine)
> > >                     current->recent_used_cpu = cpu;
> >
> > [...]
>
> Thanks
> Barry
>


From lkp at intel.com  Wed Apr 28 14:06:13 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 21:06:13 +0800
Subject: [xlnx:xlnx_rebase_v5.4 903/1755] drivers/usb/dwc3/host.c:16:6:
 error: redefinition of 'dwc3_host_wakeup_capable'
Message-ID: <202104282110.uw19pWi4-lkp@intel.com>

Hi Michal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: 6d0468b837bc2b3cce625f59904d137e63637b5d [903/1755] usb: dwc3: Add support for clock disabling during suspend
config: x86_64-randconfig-a003-20210428 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 87fc97169e7901dfe56ca0da0d92da0c02d2ef48)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/6d0468b837bc2b3cce625f59904d137e63637b5d
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 6d0468b837bc2b3cce625f59904d137e63637b5d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from drivers/usb/dwc3/host.c:12:
   include/linux/usb/xhci_pdriver.h:22:6: warning: no previous prototype for function 'dwc3_host_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
        ^
   include/linux/usb/xhci_pdriver.h:22:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
   In file included from drivers/usb/dwc3/host.c:14:
   drivers/usb/dwc3/core.h:1418:6: warning: no previous prototype for function 'dwc3_simple_wakeup_capable' [-Wmissing-prototypes]
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
        ^
   drivers/usb/dwc3/core.h:1418:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
   ^
   static 
>> drivers/usb/dwc3/host.c:16:6: error: redefinition of 'dwc3_host_wakeup_capable'
   void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
        ^
   include/linux/usb/xhci_pdriver.h:22:6: note: previous definition is here
   void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
        ^
   2 warnings and 1 error generated.


vim +/dwc3_host_wakeup_capable +16 drivers/usb/dwc3/host.c

    13	
  > 14	#include "core.h"
    15	
  > 16	void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
    17	{
    18		dwc3_simple_wakeup_capable(dev, wakeup);
    19	}
    20	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 40471 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/cddf253d/attachment-0001.gz>

From o.rempel at pengutronix.de  Wed Apr 28 14:09:46 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Wed, 28 Apr 2021 15:09:46 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: fix build issue if INET is
 disabled
Message-ID: <20210428130947.29649-1-o.rempel@pengutronix.de>

In case ethernet driver is enabled and INET is disabled, selftest will
fail to build.

Reported-by: Randy Dunlap <rdunlap at infradead.org>
Fixes: 3e1e58d64c3d ("net: add generic selftest support")
Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 drivers/net/ethernet/atheros/Kconfig   |  2 +-
 drivers/net/ethernet/freescale/Kconfig |  2 +-
 include/net/selftests.h                | 19 +++++++++++++++++++
 net/Kconfig                            |  2 +-
 net/core/Makefile                      |  2 +-
 net/dsa/Kconfig                        |  2 +-
 6 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/atheros/Kconfig b/drivers/net/ethernet/atheros/Kconfig
index 6842b74b0696..482c58c4c584 100644
--- a/drivers/net/ethernet/atheros/Kconfig
+++ b/drivers/net/ethernet/atheros/Kconfig
@@ -20,8 +20,8 @@ if NET_VENDOR_ATHEROS
 config AG71XX
 	tristate "Atheros AR7XXX/AR9XXX built-in ethernet mac support"
 	depends on ATH79
-	select NET_SELFTESTS
 	select PHYLINK
+	imply NET_SELFTESTS
 	help
 	  If you wish to compile a kernel for AR7XXX/91XXX and enable
 	  ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3d937b4650b2..2d1abdd58fab 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -26,8 +26,8 @@ config FEC
 		   ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
 	default ARCH_MXC || SOC_IMX28 if ARM
 	select CRC32
-	select NET_SELFTESTS
 	select PHYLIB
+	imply NET_SELFTESTS
 	imply PTP_1588_CLOCK
 	help
 	  Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/include/net/selftests.h b/include/net/selftests.h
index 9993b9498cf3..61926c33a022 100644
--- a/include/net/selftests.h
+++ b/include/net/selftests.h
@@ -4,9 +4,28 @@
 
 #include <linux/ethtool.h>
 
+#if IS_ENABLED(CONFIG_NET_SELFTESTS)
+
 void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
 		  u64 *buf);
 int net_selftest_get_count(void);
 void net_selftest_get_strings(u8 *data);
 
+#else
+
+static inline void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
+		  u64 *buf)
+{
+}
+
+static inline int net_selftest_get_count(void)
+{
+	return 0;
+}
+
+static inline void net_selftest_get_strings(u8 *data)
+{
+}
+
+#endif
 #endif /* _NET_SELFTESTS */
diff --git a/net/Kconfig b/net/Kconfig
index 8d955195c069..f5ee7c65e6b4 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -431,7 +431,7 @@ config SOCK_VALIDATE_XMIT
 
 config NET_SELFTESTS
 	def_tristate PHYLIB
-	depends on PHYLIB
+	depends on PHYLIB && INET
 
 config NET_SOCK_MSG
 	bool
diff --git a/net/core/Makefile b/net/core/Makefile
index 1a6168d8f23b..f7f16650fe9e 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_NETPOLL) += netpoll.o
 obj-$(CONFIG_FIB_RULES) += fib_rules.o
 obj-$(CONFIG_TRACEPOINTS) += net-traces.o
 obj-$(CONFIG_NET_DROP_MONITOR) += drop_monitor.o
+obj-$(CONFIG_NET_SELFTESTS) += selftests.o
 obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o
 obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
 obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
@@ -33,7 +34,6 @@ obj-$(CONFIG_NET_DEVLINK) += devlink.o
 obj-$(CONFIG_GRO_CELLS) += gro_cells.o
 obj-$(CONFIG_FAILOVER) += failover.o
 ifeq ($(CONFIG_INET),y)
-obj-$(CONFIG_NET_SELFTESTS) += selftests.o
 obj-$(CONFIG_NET_SOCK_MSG) += skmsg.o
 obj-$(CONFIG_BPF_SYSCALL) += sock_map.o
 endif
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index cbc2bd643ab2..183e27b50202 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -9,7 +9,7 @@ menuconfig NET_DSA
 	select NET_SWITCHDEV
 	select PHYLINK
 	select NET_DEVLINK
-	select NET_SELFTESTS
+	imply NET_SELFTESTS
 	help
 	  Say Y if you want to enable support for the hardware switches supported
 	  by the Distributed Switch Architecture.
-- 
2.29.2



From michal.simek at xilinx.com  Wed Apr 28 14:17:25 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Wed, 28 Apr 2021 15:17:25 +0200
Subject: [PATCH 0/4] soc: xilinx: pm_domains: cleanup and fix
 PM_INIT_FINALIZE
In-Reply-To: <20210420141847.blcjrrvekjt6llck@bogus>
References: <20210317160410.2097178-1-m.tretter@pengutronix.de>
 <BYAPR02MB394191514C07A76D037D1618B74D9@BYAPR02MB3941.namprd02.prod.outlook.com>
 <20210419073239.GA12636@pengutronix.de>
 <20210420141847.blcjrrvekjt6llck@bogus>
Message-ID: <93cdc435-448f-233b-5b3f-b4ff1d47f897@xilinx.com>

Hi,

On 4/20/21 4:18 PM, Sudeep Holla wrote:
> On Mon, Apr 19, 2021 at 09:32:39AM +0200, Michael Tretter wrote:
> 
> Sorry for chiming in randomly. I always though the way PM_INIT_FINALIZE
> is designed has issues(e.g. racy). I was involved in discussion with
> Xilinx when we will designing more generic version of EEMI - SCMI
> which is now supported in upstream. EEMI was in production already when
> we started on SCMI 3-4 years back and wanted to get feedback.
> 
> [...]
> 
>>
>> What is the reason why all devices have to be requested before calling
>> zynqmp_pm_init_finalize()?
>>
> 
> Yes that is wrong assumption/expectation from the firmware.
> 
>> I was expecting that calling PM_INIT_FINALIZE only would tell the PMU_FW that
>> Linux is using the PM API and the PMU_FW should power down/up PM slaves as
>> requested by Linux. It is somewhat surprising that this isn't the case and all
>> PM slaves have to be powered up before calling PM_INIT_FINALIZE.
>>
> 
> Agreed that was my understanding too.
> 
>> What would happen if some driver is built as a module? In that case, the
>> module would be loaded and request the pm node only after PM_INIT_FINALIZE was
>> called. Do we have to avoid/disallow such cases?
>>
> 
> I was told it will work. But it will be always racy if there are multiple
> channels to talk to firmware.
> 
> My argument firmware can turn off all the devices before giving control
> to OS and no need for that. But there is some boot time optimisation
> possible I am told which I could well be. But this interface for too
> racy IMO, just happens to be fine with limited configurations it operates
> in.

Rajan: Can you please do deep dive to this in pmufw and try to figured
it out how to fix this on firmware side?

Thanks,
Michal


From jonas.rabenstein at studium.uni-erlangen.de  Wed Apr 28 14:35:26 2021
From: jonas.rabenstein at studium.uni-erlangen.de (Jonas Rabenstein)
Date: Wed, 28 Apr 2021 15:35:26 +0200
Subject: [PATCH RESEND] ARM: vfp: fix misspelled identifier in documentation
In-Reply-To: <20210415103955.38983-1-jonas.rabenstein@studium.uni-erlangen.de>
References: <20210415103955.38983-1-jonas.rabenstein@studium.uni-erlangen.de>
Message-ID: <20210428133525.7932-1-jonas.rabenstein@studium.uni-erlangen.de>

The documentation comment for vfp_notifier misspelled
THREAD_NOTIFY_SWITCH as THREAD_NOFTIFY_SWTICH.

Signed-off-by: Jonas Rabenstein <jonas.rabenstein at studium.uni-erlangen.de>
---
 arch/arm/vfp/vfpmodule.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2cb355c1b5b7..4f8c6f583b79 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -140,7 +140,7 @@ static void vfp_thread_copy(struct thread_info *thread)
 /*
  * When this function is called with the following 'cmd's, the following
  * is true while this function is being run:
- *  THREAD_NOFTIFY_SWTICH:
+ *  THREAD_NOTIFY_SWITCH:
  *   - the previously running thread will not be scheduled onto another CPU.
  *   - the next thread to be run (v) will not be running on another CPU.
  *   - thread->cpu is the local CPU number
-- 
2.26.3



From stanimir.varbanov at linaro.org  Wed Apr 28 14:48:06 2021
From: stanimir.varbanov at linaro.org (Stanimir Varbanov)
Date: Wed, 28 Apr 2021 16:48:06 +0300
Subject: Update venus firmware files for v5.4 and venus firmware files for
 VPU-2.0
In-Reply-To: <bee73b3fe8b04c1a2663be0cd3cc7318@codeaurora.org>
References: <bee73b3fe8b04c1a2663be0cd3cc7318@codeaurora.org>
Message-ID: <9eaaec5d-a7d4-1889-5c92-28944b198adc@linaro.org>



On 4/28/21 3:32 PM, smagar at codeaurora.org wrote:
> Hello Team,
> 
> Please include updated firmware bins for venus-5.4 and vpu-2.0.
> 
> I have fixed comment and title updated.
> 
> Removed 0 byte unwanted bins.
> 
> Below is combined pull request for venus-5.4 and VPU-2.0.
> 
> Please find snapshot of pull request, let me know if anything is missing.
> 
> 
> The following changes since commit
> 85286184d9df1b03bb76049edcfd87c39ce46e94:
> 
> ? Merge branch 'for-upstream' of
> git://git.chelsio.net/pub/git/linux-firmware into main (2021-04-19
> 11:34:11 -0400)
> 
> are available in the git repository at:
> 
> ? https://github.com/suraj714/linux-firmware-venus.git master
> 
> for you to fetch changes up to 6cdef281cd16d967ad89c01af6fdda85529a2d80:
> 
> ? qcom: Add venus firmware files for VPU-2.0 (2021-04-28 14:42:48 +0530)
> 
> ----------------------------------------------------------------
> smagar (2):
> ????? qcom: update venus firmware files for v5.4
> ????? qcom: Add venus firmware files for VPU-2.0
> 
> ?WHENCE??????????????????? |? 34 +++++++++++++++++++++++++++++++++-
> ?qcom/venus-5.4/venus.b00? | Bin 212 -> 212 bytes
> ?qcom/venus-5.4/venus.b01? | Bin 6808 -> 6808 bytes
> ?qcom/venus-5.4/venus.b02? | Bin 873680 -> 873596 bytes
> ?qcom/venus-5.4/venus.b03? | Bin 33792 -> 33792 bytes
> ?qcom/venus-5.4/venus.mbn? | Bin 919792 -> 919708 bytes
> ?qcom/venus-5.4/venus.mdt? | Bin 7020 -> 7020 bytes
> ?qcom/vpu-2.0/vpu20_1v.b00 | Bin 0 -> 692 bytes
> ?qcom/vpu-2.0/vpu20_1v.b01 | Bin 0 -> 7376 bytes
> ?qcom/vpu-2.0/vpu20_1v.b02 | Bin 0 -> 300 bytes
> ?qcom/vpu-2.0/vpu20_1v.b03 | Bin 0 -> 20 bytes
> ?qcom/vpu-2.0/vpu20_1v.b04 | Bin 0 -> 20 bytes
> ?qcom/vpu-2.0/vpu20_1v.b05 | Bin 0 -> 20 bytes
> ?qcom/vpu-2.0/vpu20_1v.b06 | Bin 0 -> 20 bytes
> ?qcom/vpu-2.0/vpu20_1v.b07 | Bin 0 -> 24 bytes
> ?qcom/vpu-2.0/vpu20_1v.b08 | Bin 0 -> 16 bytes
> ?qcom/vpu-2.0/vpu20_1v.b09 | Bin 0 -> 939184 bytes
> ?qcom/vpu-2.0/vpu20_1v.b10 | Bin 0 -> 42976 bytes
> ?qcom/vpu-2.0/vpu20_1v.b19 |?? 1 +
> ?qcom/vpu-2.0/vpu20_1v.mbn | Bin 0 -> 2031188 bytes
> ?qcom/vpu-2.0/vpu20_1v.mdt | Bin 0 -> 8068 bytes

Which Venus IP/SoCs use vpu-2.0 firmware? And what is the difference
with existing vpu-1.0?

-- 
regards,
Stan


From cl at rock-chips.com  Wed Apr 28 14:47:52 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:47:52 +0800
Subject: [PATCH v3 03/10] dt-bindings: mmc: rockchip-dw-mshc: add description
 for rk3568
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134759.22076-4-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" for mmc nodes on
a rk3568 platform to rockchip-dw-mshc.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/mmc/rockchip-dw-mshc.yaml        | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index 3762f1c8de96..eaa3b0ef24f6 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -29,21 +29,14 @@ properties:
       - const: rockchip,rk3288-dw-mshc
       - items:
           - enum:
-            # for Rockchip PX30
               - rockchip,px30-dw-mshc
-            # for Rockchip RK3036
               - rockchip,rk3036-dw-mshc
-            # for Rockchip RK322x
               - rockchip,rk3228-dw-mshc
-            # for Rockchip RK3308
               - rockchip,rk3308-dw-mshc
-            # for Rockchip RK3328
               - rockchip,rk3328-dw-mshc
-            # for Rockchip RK3368
               - rockchip,rk3368-dw-mshc
-            # for Rockchip RK3399
               - rockchip,rk3399-dw-mshc
-            # for Rockchip RV1108
+              - rockchip,rk3568-dw-mshc
               - rockchip,rv1108-dw-mshc
           - const: rockchip,rk3288-dw-mshc
 
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:47:49 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:47:49 +0800
Subject: [PATCH v3 00/10] arm64: dts: rockchip: add basic dtsi/dts files for
 RK3568 SoC
Message-ID: <20210428134759.22076-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

v1:
1. add some dt-bindings for RK3568 devices.
2. add core dtsi for RK3568 SoC.
3. add basic dts for RK3568 EVB

v2:
1. sort device nodes by some rules.

v3:
1. make ARCH=arm64 dtbs_check, then fix some errors and add some documents.

Liang Chen (10):
  dt-bindings: i2c: i2c-rk3x: add description for rk3568
  dt-bindings: serial: snps-dw-apb-uart: add description for rk3568
  dt-bindings: mmc: rockchip-dw-mshc: add description for rk3568
  dt-bindings: watchdog: dw-wdt: add description for rk3568
  dt-bindings: pwm: rockchip: add description for rk3568
  dt-bindings: gpio: change items restriction of clock for
    rockchip,gpio-bank
  dt-bindings: soc: rockchip: Convert grf.txt to YAML
  arm64: dts: rockchip: add generic pinconfig settings used by most
    Rockchip socs
  arm64: dts: rockchip: add core dtsi for RK3568 SoC
  arm64: dts: rockchip: add basic dts for RK3568 EVB

 .../devicetree/bindings/arm/rockchip.yaml     |    5 +
 .../bindings/gpio/rockchip,gpio-bank.yaml     |    3 +-
 .../devicetree/bindings/i2c/i2c-rk3x.yaml     |    1 +
 .../bindings/mmc/rockchip-dw-mshc.yaml        |    9 +-
 .../devicetree/bindings/pwm/pwm-rockchip.yaml |    1 +
 .../bindings/serial/snps-dw-apb-uart.yaml     |    1 +
 .../devicetree/bindings/soc/rockchip/grf.txt  |   61 -
 .../devicetree/bindings/soc/rockchip/grf.yaml |   58 +
 .../bindings/watchdog/snps,dw-wdt.yaml        |    1 +
 arch/arm64/boot/dts/rockchip/Makefile         |    1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     |   80 +
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  789 +++++
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  344 ++
 14 files changed, 4395 insertions(+), 70 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:47:51 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:47:51 +0800
Subject: [PATCH v3 02/10] dt-bindings: serial: snps-dw-apb-uart: add
 description for rk3568
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134759.22076-3-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
a rk3568 platform to snps-dw-apb-uart.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 87ef1e218152..97debbf68748 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -31,6 +31,7 @@ properties:
               - rockchip,rk3328-uart
               - rockchip,rk3368-uart
               - rockchip,rk3399-uart
+              - rockchip,rk3568-uart
               - rockchip,rv1108-uart
           - const: snps,dw-apb-uart
       - items:
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:47:53 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:47:53 +0800
Subject: [PATCH v3 04/10] dt-bindings: watchdog: dw-wdt: add description for
 rk3568
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134759.22076-5-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-wdt", "snps,dw-wdt" for watchdog nodes on
a rk3568 platform to snps,dw-wdt.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index b58596b1831d..6461eb4f4a27 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -27,6 +27,7 @@ properties:
               - rockchip,rk3328-wdt
               - rockchip,rk3368-wdt
               - rockchip,rk3399-wdt
+              - rockchip,rk3568-wdt
               - rockchip,rv1108-wdt
           - const: snps,dw-wdt
 
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:47:50 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:47:50 +0800
Subject: [PATCH v3 01/10] dt-bindings: i2c: i2c-rk3x: add description for
 rk3568
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134759.22076-2-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on
a rk3568 platform to i2c-rk3x.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
index 7f254d79558c..5339dd4fc370 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -36,6 +36,7 @@ properties:
               - rockchip,px30-i2c
               - rockchip,rk3308-i2c
               - rockchip,rk3328-i2c
+              - rockchip,rk3568-i2c
           - const: rockchip,rk3399-i2c
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:49:13 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:49:13 +0800
Subject: [PATCH v3 05/10] dt-bindings: pwm: rockchip: add description for
 rk3568
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134913.22246-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-pwm", "rockchip,rk3328-pwm" for pwm nodes on
a rk3568 platform to pwm-rockchip.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index 5596bee70509..81a54a4e8e3e 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -29,6 +29,7 @@ properties:
           - enum:
               - rockchip,px30-pwm
               - rockchip,rk3308-pwm
+              - rockchip,rk3568-pwm
           - const: rockchip,rk3328-pwm
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:49:26 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:49:26 +0800
Subject: [PATCH v3 06/10] dt-bindings: gpio: change items restriction of clock
 for rockchip, gpio-bank
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134926.22318-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

The clock property need 2 items on some rockchip chips.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
index d993e002cebe..7b3fd2975c74 100644
--- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
@@ -22,7 +22,8 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   gpio-controller: true
 
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:49:38 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:49:38 +0800
Subject: [PATCH v3 07/10] dt-bindings: soc: rockchip: Convert grf.txt to YAML
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134938.22383-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

Current dts files with 'grf' nodes are manually verified. In order to
automate this process grf.txt has to be converted to YAML.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
 .../devicetree/bindings/soc/rockchip/grf.yaml | 61 +++++++++++++++++++
 2 files changed, 61 insertions(+), 61 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
deleted file mode 100644
index f96511aa3897..000000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-* Rockchip General Register Files (GRF)
-
-The general register file will be used to do static set by software, which
-is composed of many registers for system control.
-
-From RK3368 SoCs, the GRF is divided into two sections,
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- PMUGRF, used for always on system
-
-On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
-
-ON RK3308 SoC, the GRF is divided into four sections:
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- DETECTGRF, used for audio codec system,
-- COREGRF, used for pvtm,
-
-Required Properties:
-
-- compatible: GRF should be one of the following:
-   - "rockchip,px30-grf", "syscon": for px30
-   - "rockchip,rk3036-grf", "syscon": for rk3036
-   - "rockchip,rk3066-grf", "syscon": for rk3066
-   - "rockchip,rk3188-grf", "syscon": for rk3188
-   - "rockchip,rk3228-grf", "syscon": for rk3228
-   - "rockchip,rk3288-grf", "syscon": for rk3288
-   - "rockchip,rk3308-grf", "syscon": for rk3308
-   - "rockchip,rk3328-grf", "syscon": for rk3328
-   - "rockchip,rk3368-grf", "syscon": for rk3368
-   - "rockchip,rk3399-grf", "syscon": for rk3399
-   - "rockchip,rv1108-grf", "syscon": for rv1108
-- compatible: DETECTGRF should be one of the following:
-   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
-- compatilbe: COREGRF should be one of the following:
-   - "rockchip,rk3308-core-grf", "syscon": for rk3308
-- compatible: PMUGRF should be one of the following:
-   - "rockchip,px30-pmugrf", "syscon": for px30
-   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
-   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
-- compatible: SGRF should be one of the following:
-   - "rockchip,rk3288-sgrf", "syscon": for rk3288
-- compatible: USB2PHYGRF should be one of the following:
-   - "rockchip,px30-usb2phy-grf", "syscon": for px30
-   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
-- compatible: USBGRF should be one of the following:
-   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
-- reg: physical base address of the controller and length of memory mapped
-  region.
-
-Example: GRF and PMUGRF of RK3399 SoCs
-
-	pmugrf: syscon at ff320000 {
-		compatible = "rockchip,rk3399-pmugrf", "syscon";
-		reg = <0x0 0xff320000 0x0 0x1000>;
-	};
-
-	grf: syscon at ff770000 {
-		compatible = "rockchip,rk3399-grf", "syscon";
-		reg = <0x0 0xff770000 0x0 0x10000>;
-	};
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
new file mode 100644
index 000000000000..61ce5b4c9ed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip General Register Files
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - rockchip,px30-grf
+              - rockchip,px30-pmugrf
+              - rockchip,px30-usb2phy-grf
+              - rockchip,rk3036-grf
+              - rockchip,rk3066-grf
+              - rockchip,rk3188-grf
+              - rockchip,rk3228-grf
+              - rockchip,rk3288-grf
+              - rockchip,rk3288-sgrf
+              - rockchip,rk3308-core-grf
+              - rockchip,rk3308-detect-grf
+              - rockchip,rk3308-grf
+              - rockchip,rk3328-grf
+              - rockchip,rk3328-usb2phy-grf
+              - rockchip,rk3368-grf
+              - rockchip,rk3368-pmugrf
+              - rockchip,rk3399-grf
+              - rockchip,rk3399-pmugrf
+              - rockchip,rk3568-grf
+              - rockchip,rk3568-pmugrf
+              - rockchip,rv1108-grf
+              - rockchip,rv1108-usbgrf
+          - const: syscon
+          - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    pmugrf: syscon at ff320000 {
+       compatible = "rockchip,rk3399-pmugrf", "syscon";
+       reg = <0x0 0xff320000 0x0 0x1000>;
+    };
+
+    grf: syscon at ff770000 {
+       compatible = "rockchip,rk3399-grf", "syscon";
+       reg = <0x0 0xff770000 0x0 0x10000>;
+    };
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:49:51 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:49:51 +0800
Subject: [PATCH v3 08/10] arm64: dts: rockchip: add generic pinconfig settings
 used by most Rockchip socs
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428134951.22457-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
so move them to a shared dtsi to be included, instead of redefining them
for each soc.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   | 344 ++++++++++++++++++
 1 file changed, 344 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
new file mode 100644
index 000000000000..5c645437b507
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+&pinctrl {
+	/omit-if-no-ref/
+	pcfg_pull_up: pcfg-pull-up {
+		bias-pull-up;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down: pcfg-pull-down {
+		bias-pull-down;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none: pcfg-pull-none {
+		bias-disable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0: pcfg-pull-none-drv-level-0 {
+		bias-disable;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_1: pcfg-pull-none-drv-level-1 {
+		bias-disable;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_2: pcfg-pull-none-drv-level-2 {
+		bias-disable;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_3: pcfg-pull-none-drv-level-3 {
+		bias-disable;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_4: pcfg-pull-none-drv-level-4 {
+		bias-disable;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_5: pcfg-pull-none-drv-level-5 {
+		bias-disable;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_6: pcfg-pull-none-drv-level-6 {
+		bias-disable;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_7: pcfg-pull-none-drv-level-7 {
+		bias-disable;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_8: pcfg-pull-none-drv-level-8 {
+		bias-disable;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_9: pcfg-pull-none-drv-level-9 {
+		bias-disable;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_10: pcfg-pull-none-drv-level-10 {
+		bias-disable;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_11: pcfg-pull-none-drv-level-11 {
+		bias-disable;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_12: pcfg-pull-none-drv-level-12 {
+		bias-disable;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_13: pcfg-pull-none-drv-level-13 {
+		bias-disable;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_14: pcfg-pull-none-drv-level-14 {
+		bias-disable;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_15: pcfg-pull-none-drv-level-15 {
+		bias-disable;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_0: pcfg-pull-up-drv-level-0 {
+		bias-pull-up;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_1: pcfg-pull-up-drv-level-1 {
+		bias-pull-up;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_2: pcfg-pull-up-drv-level-2 {
+		bias-pull-up;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_3: pcfg-pull-up-drv-level-3 {
+		bias-pull-up;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_4: pcfg-pull-up-drv-level-4 {
+		bias-pull-up;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_5: pcfg-pull-up-drv-level-5 {
+		bias-pull-up;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_6: pcfg-pull-up-drv-level-6 {
+		bias-pull-up;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_7: pcfg-pull-up-drv-level-7 {
+		bias-pull-up;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_8: pcfg-pull-up-drv-level-8 {
+		bias-pull-up;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_9: pcfg-pull-up-drv-level-9 {
+		bias-pull-up;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_10: pcfg-pull-up-drv-level-10 {
+		bias-pull-up;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_11: pcfg-pull-up-drv-level-11 {
+		bias-pull-up;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_12: pcfg-pull-up-drv-level-12 {
+		bias-pull-up;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_13: pcfg-pull-up-drv-level-13 {
+		bias-pull-up;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_14: pcfg-pull-up-drv-level-14 {
+		bias-pull-up;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_15: pcfg-pull-up-drv-level-15 {
+		bias-pull-up;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_0: pcfg-pull-down-drv-level-0 {
+		bias-pull-down;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_1: pcfg-pull-down-drv-level-1 {
+		bias-pull-down;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_2: pcfg-pull-down-drv-level-2 {
+		bias-pull-down;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_3: pcfg-pull-down-drv-level-3 {
+		bias-pull-down;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_4: pcfg-pull-down-drv-level-4 {
+		bias-pull-down;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_5: pcfg-pull-down-drv-level-5 {
+		bias-pull-down;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_6: pcfg-pull-down-drv-level-6 {
+		bias-pull-down;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_7: pcfg-pull-down-drv-level-7 {
+		bias-pull-down;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_8: pcfg-pull-down-drv-level-8 {
+		bias-pull-down;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_9: pcfg-pull-down-drv-level-9 {
+		bias-pull-down;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_10: pcfg-pull-down-drv-level-10 {
+		bias-pull-down;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_11: pcfg-pull-down-drv-level-11 {
+		bias-pull-down;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_12: pcfg-pull-down-drv-level-12 {
+		bias-pull-down;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_13: pcfg-pull-down-drv-level-13 {
+		bias-pull-down;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_14: pcfg-pull-down-drv-level-14 {
+		bias-pull-down;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_15: pcfg-pull-down-drv-level-15 {
+		bias-pull-down;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_smt: pcfg-pull-up-smt {
+		bias-pull-up;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_smt: pcfg-pull-down-smt {
+		bias-pull-down;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_smt: pcfg-pull-none-smt {
+		bias-disable;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0_smt: pcfg-pull-none-drv-level-0-smt {
+		bias-disable;
+		drive-strength = <0>;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_low: pcfg-output-low {
+		output-low;
+	};
+};
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:50:02 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:50:02 +0800
Subject: [PATCH v3 09/10] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428135002.22528-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

RK3568 is a high-performance and low power quad-core application processor
designed for personal mobile internet device and AIoT equipment. This patch
add basic core dtsi file for it.

We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
enalbe a special high-performance PLL when high frequency is required. The
smci_clk code is in ATF, and clkid for cpu is 0, as below:

    cpu0: cpu at 0 {
        device_type = "cpu";
        compatible = "arm,cortex-a55";
        reg = <0x0 0x0>;
        clocks = <&scmi_clk 0>;
    };

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  779 +++++
 2 files changed, 3890 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
new file mode 100644
index 000000000000..a588ca95ace2
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
@@ -0,0 +1,3111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+&pinctrl {
+	acodec {
+		/omit-if-no-ref/
+		acodec_pins: acodec-pins {
+			rockchip,pins =
+				/* acodec_adc_sync */
+				<1 RK_PB1 5 &pcfg_pull_none>,
+				/* acodec_adcclk */
+				<1 RK_PA1 5 &pcfg_pull_none>,
+				/* acodec_adcdata */
+				<1 RK_PA0 5 &pcfg_pull_none>,
+				/* acodec_dac_datal */
+				<1 RK_PA7 5 &pcfg_pull_none>,
+				/* acodec_dac_datar */
+				<1 RK_PB0 5 &pcfg_pull_none>,
+				/* acodec_dacclk */
+				<1 RK_PA3 5 &pcfg_pull_none>,
+				/* acodec_dacsync */
+				<1 RK_PA5 5 &pcfg_pull_none>;
+		};
+	};
+
+	audiopwm {
+		/omit-if-no-ref/
+		audiopwm_lout: audiopwm-lout {
+			rockchip,pins =
+				/* audiopwm_lout */
+				<1 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutn: audiopwm-loutn {
+			rockchip,pins =
+				/* audiopwm_loutn */
+				<1 RK_PA1 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutp: audiopwm-loutp {
+			rockchip,pins =
+				/* audiopwm_loutp */
+				<1 RK_PA0 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_rout: audiopwm-rout {
+			rockchip,pins =
+				/* audiopwm_rout */
+				<1 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routn: audiopwm-routn {
+			rockchip,pins =
+				/* audiopwm_routn */
+				<1 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routp: audiopwm-routp {
+			rockchip,pins =
+				/* audiopwm_routp */
+				<1 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	bt656 {
+		/omit-if-no-ref/
+		bt656m0_pins: bt656m0-pins {
+			rockchip,pins =
+				/* bt656_clkm0 */
+				<3 RK_PA0 2 &pcfg_pull_none>,
+				/* bt656_d0m0 */
+				<2 RK_PD0 2 &pcfg_pull_none>,
+				/* bt656_d1m0 */
+				<2 RK_PD1 2 &pcfg_pull_none>,
+				/* bt656_d2m0 */
+				<2 RK_PD2 2 &pcfg_pull_none>,
+				/* bt656_d3m0 */
+				<2 RK_PD3 2 &pcfg_pull_none>,
+				/* bt656_d4m0 */
+				<2 RK_PD4 2 &pcfg_pull_none>,
+				/* bt656_d5m0 */
+				<2 RK_PD5 2 &pcfg_pull_none>,
+				/* bt656_d6m0 */
+				<2 RK_PD6 2 &pcfg_pull_none>,
+				/* bt656_d7m0 */
+				<2 RK_PD7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		bt656m1_pins: bt656m1-pins {
+			rockchip,pins =
+				/* bt656_clkm1 */
+				<4 RK_PB4 5 &pcfg_pull_none>,
+				/* bt656_d0m1 */
+				<3 RK_PC6 5 &pcfg_pull_none>,
+				/* bt656_d1m1 */
+				<3 RK_PC7 5 &pcfg_pull_none>,
+				/* bt656_d2m1 */
+				<3 RK_PD0 5 &pcfg_pull_none>,
+				/* bt656_d3m1 */
+				<3 RK_PD1 5 &pcfg_pull_none>,
+				/* bt656_d4m1 */
+				<3 RK_PD2 5 &pcfg_pull_none>,
+				/* bt656_d5m1 */
+				<3 RK_PD3 5 &pcfg_pull_none>,
+				/* bt656_d6m1 */
+				<3 RK_PD4 5 &pcfg_pull_none>,
+				/* bt656_d7m1 */
+				<3 RK_PD5 5 &pcfg_pull_none>;
+		};
+	};
+
+	bt1120 {
+		/omit-if-no-ref/
+		bt1120_pins: bt1120-pins {
+			rockchip,pins =
+				/* bt1120_clk */
+				<3 RK_PA6 2 &pcfg_pull_none>,
+				/* bt1120_d0 */
+				<3 RK_PA1 2 &pcfg_pull_none>,
+				/* bt1120_d1 */
+				<3 RK_PA2 2 &pcfg_pull_none>,
+				/* bt1120_d2 */
+				<3 RK_PA3 2 &pcfg_pull_none>,
+				/* bt1120_d3 */
+				<3 RK_PA4 2 &pcfg_pull_none>,
+				/* bt1120_d4 */
+				<3 RK_PA5 2 &pcfg_pull_none>,
+				/* bt1120_d5 */
+				<3 RK_PA7 2 &pcfg_pull_none>,
+				/* bt1120_d6 */
+				<3 RK_PB0 2 &pcfg_pull_none>,
+				/* bt1120_d7 */
+				<3 RK_PB1 2 &pcfg_pull_none>,
+				/* bt1120_d8 */
+				<3 RK_PB2 2 &pcfg_pull_none>,
+				/* bt1120_d9 */
+				<3 RK_PB3 2 &pcfg_pull_none>,
+				/* bt1120_d10 */
+				<3 RK_PB4 2 &pcfg_pull_none>,
+				/* bt1120_d11 */
+				<3 RK_PB5 2 &pcfg_pull_none>,
+				/* bt1120_d12 */
+				<3 RK_PB6 2 &pcfg_pull_none>,
+				/* bt1120_d13 */
+				<3 RK_PC1 2 &pcfg_pull_none>,
+				/* bt1120_d14 */
+				<3 RK_PC2 2 &pcfg_pull_none>,
+				/* bt1120_d15 */
+				<3 RK_PC3 2 &pcfg_pull_none>;
+		};
+	};
+
+	cam {
+		/omit-if-no-ref/
+		cam_clkout0: cam-clkout0 {
+			rockchip,pins =
+				/* cam_clkout0 */
+				<4 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cam_clkout1: cam-clkout1 {
+			rockchip,pins =
+				/* cam_clkout1 */
+				<4 RK_PB0 1 &pcfg_pull_none>;
+		};
+	};
+
+	can0 {
+		/omit-if-no-ref/
+		can0m0_pins: can0m0-pins {
+			rockchip,pins =
+				/* can0_rxm0 */
+				<0 RK_PB4 2 &pcfg_pull_none>,
+				/* can0_txm0 */
+				<0 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can0m1_pins: can0m1-pins {
+			rockchip,pins =
+				/* can0_rxm1 */
+				<2 RK_PA2 4 &pcfg_pull_none>,
+				/* can0_txm1 */
+				<2 RK_PA1 4 &pcfg_pull_none>;
+		};
+	};
+
+	can1 {
+		/omit-if-no-ref/
+		can1m0_pins: can1m0-pins {
+			rockchip,pins =
+				/* can1_rxm0 */
+				<1 RK_PA0 3 &pcfg_pull_none>,
+				/* can1_txm0 */
+				<1 RK_PA1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can1m1_pins: can1m1-pins {
+			rockchip,pins =
+				/* can1_rxm1 */
+				<4 RK_PC2 3 &pcfg_pull_none>,
+				/* can1_txm1 */
+				<4 RK_PC3 3 &pcfg_pull_none>;
+		};
+	};
+
+	can2 {
+		/omit-if-no-ref/
+		can2m0_pins: can2m0-pins {
+			rockchip,pins =
+				/* can2_rxm0 */
+				<4 RK_PB4 3 &pcfg_pull_none>,
+				/* can2_txm0 */
+				<4 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can2m1_pins: can2m1-pins {
+			rockchip,pins =
+				/* can2_rxm1 */
+				<2 RK_PB1 4 &pcfg_pull_none>,
+				/* can2_txm1 */
+				<2 RK_PB2 4 &pcfg_pull_none>;
+		};
+	};
+
+	cif {
+		/omit-if-no-ref/
+		cif_clk: cif-clk {
+			rockchip,pins =
+				/* cif_clkout */
+				<4 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_clk: cif-dvp-clk {
+			rockchip,pins =
+				/* cif_clkin */
+				<4 RK_PC1 1 &pcfg_pull_none>,
+				/* cif_href */
+				<4 RK_PB6 1 &pcfg_pull_none>,
+				/* cif_vsync */
+				<4 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus16: cif-dvp-bus16 {
+			rockchip,pins =
+				/* cif_d8 */
+				<3 RK_PD6 1 &pcfg_pull_none>,
+				/* cif_d9 */
+				<3 RK_PD7 1 &pcfg_pull_none>,
+				/* cif_d10 */
+				<4 RK_PA0 1 &pcfg_pull_none>,
+				/* cif_d11 */
+				<4 RK_PA1 1 &pcfg_pull_none>,
+				/* cif_d12 */
+				<4 RK_PA2 1 &pcfg_pull_none>,
+				/* cif_d13 */
+				<4 RK_PA3 1 &pcfg_pull_none>,
+				/* cif_d14 */
+				<4 RK_PA4 1 &pcfg_pull_none>,
+				/* cif_d15 */
+				<4 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus8: cif-dvp-bus8 {
+			rockchip,pins =
+				/* cif_d0 */
+				<3 RK_PC6 1 &pcfg_pull_none>,
+				/* cif_d1 */
+				<3 RK_PC7 1 &pcfg_pull_none>,
+				/* cif_d2 */
+				<3 RK_PD0 1 &pcfg_pull_none>,
+				/* cif_d3 */
+				<3 RK_PD1 1 &pcfg_pull_none>,
+				/* cif_d4 */
+				<3 RK_PD2 1 &pcfg_pull_none>,
+				/* cif_d5 */
+				<3 RK_PD3 1 &pcfg_pull_none>,
+				/* cif_d6 */
+				<3 RK_PD4 1 &pcfg_pull_none>,
+				/* cif_d7 */
+				<3 RK_PD5 1 &pcfg_pull_none>;
+		};
+	};
+
+	clk32k {
+		/omit-if-no-ref/
+		clk32k_in: clk32k-in {
+			rockchip,pins =
+				/* clk32k_in */
+				<0 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out0: clk32k-out0 {
+			rockchip,pins =
+				/* clk32k_out0 */
+				<0 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out1: clk32k-out1 {
+			rockchip,pins =
+				/* clk32k_out1 */
+				<2 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	cpu {
+		/omit-if-no-ref/
+		cpu_pins: cpu-pins {
+			rockchip,pins =
+				/* cpu_avs */
+				<0 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	ebc {
+		/omit-if-no-ref/
+		ebc_extern: ebc-extern {
+			rockchip,pins =
+				/* ebc_sdce1 */
+				<4 RK_PA7 2 &pcfg_pull_none>,
+				/* ebc_sdce2 */
+				<4 RK_PB0 2 &pcfg_pull_none>,
+				/* ebc_sdce3 */
+				<4 RK_PB1 2 &pcfg_pull_none>,
+				/* ebc_sdshr */
+				<4 RK_PB5 2 &pcfg_pull_none>,
+				/* ebc_vcom */
+				<4 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		ebc_pins: ebc-pins {
+			rockchip,pins =
+				/* ebc_gdclk */
+				<4 RK_PC0 2 &pcfg_pull_none>,
+				/* ebc_gdoe */
+				<4 RK_PB3 2 &pcfg_pull_none>,
+				/* ebc_gdsp */
+				<4 RK_PB4 2 &pcfg_pull_none>,
+				/* ebc_sdce0 */
+				<4 RK_PA6 2 &pcfg_pull_none>,
+				/* ebc_sdclk */
+				<4 RK_PC1 2 &pcfg_pull_none>,
+				/* ebc_sddo0 */
+				<3 RK_PC6 2 &pcfg_pull_none>,
+				/* ebc_sddo1 */
+				<3 RK_PC7 2 &pcfg_pull_none>,
+				/* ebc_sddo2 */
+				<3 RK_PD0 2 &pcfg_pull_none>,
+				/* ebc_sddo3 */
+				<3 RK_PD1 2 &pcfg_pull_none>,
+				/* ebc_sddo4 */
+				<3 RK_PD2 2 &pcfg_pull_none>,
+				/* ebc_sddo5 */
+				<3 RK_PD3 2 &pcfg_pull_none>,
+				/* ebc_sddo6 */
+				<3 RK_PD4 2 &pcfg_pull_none>,
+				/* ebc_sddo7 */
+				<3 RK_PD5 2 &pcfg_pull_none>,
+				/* ebc_sddo8 */
+				<3 RK_PD6 2 &pcfg_pull_none>,
+				/* ebc_sddo9 */
+				<3 RK_PD7 2 &pcfg_pull_none>,
+				/* ebc_sddo10 */
+				<4 RK_PA0 2 &pcfg_pull_none>,
+				/* ebc_sddo11 */
+				<4 RK_PA1 2 &pcfg_pull_none>,
+				/* ebc_sddo12 */
+				<4 RK_PA2 2 &pcfg_pull_none>,
+				/* ebc_sddo13 */
+				<4 RK_PA3 2 &pcfg_pull_none>,
+				/* ebc_sddo14 */
+				<4 RK_PA4 2 &pcfg_pull_none>,
+				/* ebc_sddo15 */
+				<4 RK_PA5 2 &pcfg_pull_none>,
+				/* ebc_sdle */
+				<4 RK_PB6 2 &pcfg_pull_none>,
+				/* ebc_sdoe */
+				<4 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	edpdp {
+		/omit-if-no-ref/
+		edpdpm0_pins: edpdpm0-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm0 */
+				<4 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		edpdpm1_pins: edpdpm1-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm1 */
+				<0 RK_PC2 2 &pcfg_pull_none>;
+		};
+	};
+
+	emmc {
+		/omit-if-no-ref/
+		emmc_rstnout: emmc-rstnout {
+			rockchip,pins =
+				/* emmc_rstn */
+				<1 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		emmc_bus8: emmc-bus8 {
+			rockchip,pins =
+				/* emmc_d0 */
+				<1 RK_PB4 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d1 */
+				<1 RK_PB5 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d2 */
+				<1 RK_PB6 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d3 */
+				<1 RK_PB7 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d4 */
+				<1 RK_PC0 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d5 */
+				<1 RK_PC1 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d6 */
+				<1 RK_PC2 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d7 */
+				<1 RK_PC3 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_clk: emmc-clk {
+			rockchip,pins =
+				/* emmc_clkout */
+				<1 RK_PC5 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_cmd: emmc-cmd {
+			rockchip,pins =
+				/* emmc_cmd */
+				<1 RK_PC4 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_datastrobe: emmc-datastrobe {
+			rockchip,pins =
+				/* emmc_datastrobe */
+				<1 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	eth0 {
+		/omit-if-no-ref/
+		eth0_pins: eth0-pins {
+			rockchip,pins =
+				/* eth0_refclko25m */
+				<2 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	eth1 {
+		/omit-if-no-ref/
+		eth1m0_pins: eth1m0-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm0 */
+				<3 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		eth1m1_pins: eth1m1-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm1 */
+				<4 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	flash {
+		/omit-if-no-ref/
+		flash_pins: flash-pins {
+			rockchip,pins =
+				/* flash_ale */
+				<1 RK_PD0 2 &pcfg_pull_none>,
+				/* flash_cle */
+				<1 RK_PC6 3 &pcfg_pull_none>,
+				/* flash_cs0n */
+				<1 RK_PD3 2 &pcfg_pull_none>,
+				/* flash_cs1n */
+				<1 RK_PD4 2 &pcfg_pull_none>,
+				/* flash_d0 */
+				<1 RK_PB4 2 &pcfg_pull_none>,
+				/* flash_d1 */
+				<1 RK_PB5 2 &pcfg_pull_none>,
+				/* flash_d2 */
+				<1 RK_PB6 2 &pcfg_pull_none>,
+				/* flash_d3 */
+				<1 RK_PB7 2 &pcfg_pull_none>,
+				/* flash_d4 */
+				<1 RK_PC0 2 &pcfg_pull_none>,
+				/* flash_d5 */
+				<1 RK_PC1 2 &pcfg_pull_none>,
+				/* flash_d6 */
+				<1 RK_PC2 2 &pcfg_pull_none>,
+				/* flash_d7 */
+				<1 RK_PC3 2 &pcfg_pull_none>,
+				/* flash_dqs */
+				<1 RK_PC5 2 &pcfg_pull_none>,
+				/* flash_rdn */
+				<1 RK_PD2 2 &pcfg_pull_none>,
+				/* flash_rdy */
+				<1 RK_PD1 2 &pcfg_pull_none>,
+				/* flash_volsel */
+				<0 RK_PA7 1 &pcfg_pull_none>,
+				/* flash_wpn */
+				<1 RK_PC7 3 &pcfg_pull_none>,
+				/* flash_wrn */
+				<1 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	fspi {
+		/omit-if-no-ref/
+		fspi_pins: fspi-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>,
+				/* fspi_d2 */
+				<1 RK_PC7 2 &pcfg_pull_none>,
+				/* fspi_d3 */
+				<1 RK_PD4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		fspi_cs1: fspi-cs1 {
+			rockchip,pins =
+				/* fspi_cs1n */
+				<1 RK_PC6 2 &pcfg_pull_up>;
+		};
+	};
+
+	gmac0 {
+		/omit-if-no-ref/
+		gmac0_miim: gmac0-miim {
+			rockchip,pins =
+				/* gmac0_mdc */
+				<2 RK_PC3 2 &pcfg_pull_none>,
+				/* gmac0_mdio */
+				<2 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_clkinout: gmac0-clkinout {
+			rockchip,pins =
+				/* gmac0_mclkinout */
+				<2 RK_PC2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_er: gmac0-rx-er {
+			rockchip,pins =
+				/* gmac0_rxer */
+				<2 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_bus2: gmac0-rx-bus2 {
+			rockchip,pins =
+				/* gmac0_rxd0 */
+				<2 RK_PB6 1 &pcfg_pull_none>,
+				/* gmac0_rxd1 */
+				<2 RK_PB7 2 &pcfg_pull_none>,
+				/* gmac0_rxdvcrs */
+				<2 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_tx_bus2: gmac0-tx-bus2 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_clk: gmac0-rgmii-clk {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus: gmac0-rgmii-bus {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gmac1 {
+		/omit-if-no-ref/
+		gmac1m0_miim: gmac1m0-miim {
+			rockchip,pins =
+				/* gmac1_mdcm0 */
+				<3 RK_PC4 3 &pcfg_pull_none>,
+				/* gmac1_mdiom0 */
+				<3 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_clkinout: gmac1m0-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm0 */
+				<3 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_er: gmac1m0-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm0 */
+				<3 RK_PB4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_bus2: gmac1m0-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m0 */
+				<3 RK_PB1 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m0 */
+				<3 RK_PB2 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm0 */
+				<3 RK_PB3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2: gmac1m0-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk: gmac1m0-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus: gmac1m0-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_miim: gmac1m1-miim {
+			rockchip,pins =
+				/* gmac1_mdcm1 */
+				<4 RK_PB6 3 &pcfg_pull_none>,
+				/* gmac1_mdiom1 */
+				<4 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_clkinout: gmac1m1-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm1 */
+				<4 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_er: gmac1m1-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm1 */
+				<4 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_bus2: gmac1m1-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m1 */
+				<4 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m1 */
+				<4 RK_PB0 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm1 */
+				<4 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2: gmac1m1-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk: gmac1m1-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus: gmac1m1-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gpu {
+		/omit-if-no-ref/
+		gpu_pins: gpu-pins {
+			rockchip,pins =
+				/* gpu_avs */
+				<0 RK_PC0 2 &pcfg_pull_none>,
+				/* gpu_pwren */
+				<0 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	hdmitx {
+		/omit-if-no-ref/
+		hdmitxm0_cec: hdmitxm0-cec {
+			rockchip,pins =
+				/* hdmitxm0_cec */
+				<4 RK_PD1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitxm1_cec: hdmitxm1-cec {
+			rockchip,pins =
+				/* hdmitxm1_cec */
+				<0 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_scl: hdmitx-scl {
+			rockchip,pins =
+				/* hdmitx_scl */
+				<4 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_sda: hdmitx-sda {
+			rockchip,pins =
+				/* hdmitx_sda */
+				<4 RK_PD0 1 &pcfg_pull_none>;
+		};
+	};
+
+	i2c0 {
+		/omit-if-no-ref/
+		i2c0_xfer: i2c0-xfer {
+			rockchip,pins =
+				/* i2c0_scl */
+				<0 RK_PB1 1 &pcfg_pull_none_smt>,
+				/* i2c0_sda */
+				<0 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c1 {
+		/omit-if-no-ref/
+		i2c1_xfer: i2c1-xfer {
+			rockchip,pins =
+				/* i2c1_scl */
+				<0 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c1_sda */
+				<0 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c2 {
+		/omit-if-no-ref/
+		i2c2m0_xfer: i2c2m0-xfer {
+			rockchip,pins =
+				/* i2c2_sclm0 */
+				<0 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam0 */
+				<0 RK_PB6 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c2m1_xfer: i2c2m1-xfer {
+			rockchip,pins =
+				/* i2c2_sclm1 */
+				<4 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam1 */
+				<4 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c3 {
+		/omit-if-no-ref/
+		i2c3m0_xfer: i2c3m0-xfer {
+			rockchip,pins =
+				/* i2c3_sclm0 */
+				<1 RK_PA1 1 &pcfg_pull_none_smt>,
+				/* i2c3_sdam0 */
+				<1 RK_PA0 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c3m1_xfer: i2c3m1-xfer {
+			rockchip,pins =
+				/* i2c3_sclm1 */
+				<3 RK_PB5 4 &pcfg_pull_none_smt>,
+				/* i2c3_sdam1 */
+				<3 RK_PB6 4 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c4 {
+		/omit-if-no-ref/
+		i2c4m0_xfer: i2c4m0-xfer {
+			rockchip,pins =
+				/* i2c4_sclm0 */
+				<4 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c4_sdam0 */
+				<4 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c4m1_xfer: i2c4m1-xfer {
+			rockchip,pins =
+				/* i2c4_sclm1 */
+				<2 RK_PB2 2 &pcfg_pull_none_smt>,
+				/* i2c4_sdam1 */
+				<2 RK_PB1 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c5 {
+		/omit-if-no-ref/
+		i2c5m0_xfer: i2c5m0-xfer {
+			rockchip,pins =
+				/* i2c5_sclm0 */
+				<3 RK_PB3 4 &pcfg_pull_none_smt>,
+				/* i2c5_sdam0 */
+				<3 RK_PB4 4 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c5m1_xfer: i2c5m1-xfer {
+			rockchip,pins =
+				/* i2c5_sclm1 */
+				<4 RK_PC7 2 &pcfg_pull_none_smt>,
+				/* i2c5_sdam1 */
+				<4 RK_PD0 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2s1 {
+		/omit-if-no-ref/
+		i2s1m0_lrckrx: i2s1m0-lrckrx {
+			rockchip,pins =
+				/* i2s1m0_lrckrx */
+				<1 RK_PA6 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_lrcktx: i2s1m0-lrcktx {
+			rockchip,pins =
+				/* i2s1m0_lrcktx */
+				<1 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_mclk: i2s1m0-mclk {
+			rockchip,pins =
+				/* i2s1m0_mclk */
+				<1 RK_PA2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclkrx: i2s1m0-sclkrx {
+			rockchip,pins =
+				/* i2s1m0_sclkrx */
+				<1 RK_PA4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclktx: i2s1m0-sclktx {
+			rockchip,pins =
+				/* i2s1m0_sclktx */
+				<1 RK_PA3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi0: i2s1m0-sdi0 {
+			rockchip,pins =
+				/* i2s1m0_sdi0 */
+				<1 RK_PB3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi1: i2s1m0-sdi1 {
+			rockchip,pins =
+				/* i2s1m0_sdi1 */
+				<1 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi2: i2s1m0-sdi2 {
+			rockchip,pins =
+				/* i2s1m0_sdi2 */
+				<1 RK_PB1 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi3: i2s1m0-sdi3 {
+			rockchip,pins =
+				/* i2s1m0_sdi3 */
+				<1 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo0: i2s1m0-sdo0 {
+			rockchip,pins =
+				/* i2s1m0_sdo0 */
+				<1 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo1: i2s1m0-sdo1 {
+			rockchip,pins =
+				/* i2s1m0_sdo1 */
+				<1 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo2: i2s1m0-sdo2 {
+			rockchip,pins =
+				/* i2s1m0_sdo2 */
+				<1 RK_PB1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo3: i2s1m0-sdo3 {
+			rockchip,pins =
+				/* i2s1m0_sdo3 */
+				<1 RK_PB2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrckrx: i2s1m1-lrckrx {
+			rockchip,pins =
+				/* i2s1m1_lrckrx */
+				<4 RK_PA7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrcktx: i2s1m1-lrcktx {
+			rockchip,pins =
+				/* i2s1m1_lrcktx */
+				<3 RK_PD0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_mclk: i2s1m1-mclk {
+			rockchip,pins =
+				/* i2s1m1_mclk */
+				<3 RK_PC6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclkrx: i2s1m1-sclkrx {
+			rockchip,pins =
+				/* i2s1m1_sclkrx */
+				<4 RK_PA6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclktx: i2s1m1-sclktx {
+			rockchip,pins =
+				/* i2s1m1_sclktx */
+				<3 RK_PC7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi0: i2s1m1-sdi0 {
+			rockchip,pins =
+				/* i2s1m1_sdi0 */
+				<3 RK_PD2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi1: i2s1m1-sdi1 {
+			rockchip,pins =
+				/* i2s1m1_sdi1 */
+				<3 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi2: i2s1m1-sdi2 {
+			rockchip,pins =
+				/* i2s1m1_sdi2 */
+				<3 RK_PD4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi3: i2s1m1-sdi3 {
+			rockchip,pins =
+				/* i2s1m1_sdi3 */
+				<3 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo0: i2s1m1-sdo0 {
+			rockchip,pins =
+				/* i2s1m1_sdo0 */
+				<3 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo1: i2s1m1-sdo1 {
+			rockchip,pins =
+				/* i2s1m1_sdo1 */
+				<4 RK_PB0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo2: i2s1m1-sdo2 {
+			rockchip,pins =
+				/* i2s1m1_sdo2 */
+				<4 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo3: i2s1m1-sdo3 {
+			rockchip,pins =
+				/* i2s1m1_sdo3 */
+				<4 RK_PB5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrckrx: i2s1m2-lrckrx {
+			rockchip,pins =
+				/* i2s1m2_lrckrx */
+				<3 RK_PC5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrcktx: i2s1m2-lrcktx {
+			rockchip,pins =
+				/* i2s1m2_lrcktx */
+				<2 RK_PD2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_mclk: i2s1m2-mclk {
+			rockchip,pins =
+				/* i2s1m2_mclk */
+				<2 RK_PD0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclkrx: i2s1m2-sclkrx {
+			rockchip,pins =
+				/* i2s1m2_sclkrx */
+				<3 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclktx: i2s1m2-sclktx {
+			rockchip,pins =
+				/* i2s1m2_sclktx */
+				<2 RK_PD1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi0: i2s1m2-sdi0 {
+			rockchip,pins =
+				/* i2s1m2_sdi0 */
+				<2 RK_PD3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi1: i2s1m2-sdi1 {
+			rockchip,pins =
+				/* i2s1m2_sdi1 */
+				<2 RK_PD4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi2: i2s1m2-sdi2 {
+			rockchip,pins =
+				/* i2s1m2_sdi2 */
+				<2 RK_PD5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi3: i2s1m2-sdi3 {
+			rockchip,pins =
+				/* i2s1m2_sdi3 */
+				<2 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo0: i2s1m2-sdo0 {
+			rockchip,pins =
+				/* i2s1m2_sdo0 */
+				<2 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo1: i2s1m2-sdo1 {
+			rockchip,pins =
+				/* i2s1m2_sdo1 */
+				<3 RK_PA0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo2: i2s1m2-sdo2 {
+			rockchip,pins =
+				/* i2s1m2_sdo2 */
+				<3 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo3: i2s1m2-sdo3 {
+			rockchip,pins =
+				/* i2s1m2_sdo3 */
+				<3 RK_PC2 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s2 {
+		/omit-if-no-ref/
+		i2s2m0_lrckrx: i2s2m0-lrckrx {
+			rockchip,pins =
+				/* i2s2m0_lrckrx */
+				<2 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_lrcktx: i2s2m0-lrcktx {
+			rockchip,pins =
+				/* i2s2m0_lrcktx */
+				<2 RK_PC3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_mclk: i2s2m0-mclk {
+			rockchip,pins =
+				/* i2s2m0_mclk */
+				<2 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclkrx: i2s2m0-sclkrx {
+			rockchip,pins =
+				/* i2s2m0_sclkrx */
+				<2 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclktx: i2s2m0-sclktx {
+			rockchip,pins =
+				/* i2s2m0_sclktx */
+				<2 RK_PC2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdi: i2s2m0-sdi {
+			rockchip,pins =
+				/* i2s2m0_sdi */
+				<2 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdo: i2s2m0-sdo {
+			rockchip,pins =
+				/* i2s2m0_sdo */
+				<2 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrckrx: i2s2m1-lrckrx {
+			rockchip,pins =
+				/* i2s2m1_lrckrx */
+				<4 RK_PA5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrcktx: i2s2m1-lrcktx {
+			rockchip,pins =
+				/* i2s2m1_lrcktx */
+				<4 RK_PA4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_mclk: i2s2m1-mclk {
+			rockchip,pins =
+				/* i2s2m1_mclk */
+				<4 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclkrx: i2s2m1-sclkrx {
+			rockchip,pins =
+				/* i2s2m1_sclkrx */
+				<4 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclktx: i2s2m1-sclktx {
+			rockchip,pins =
+				/* i2s2m1_sclktx */
+				<4 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdi: i2s2m1-sdi {
+			rockchip,pins =
+				/* i2s2m1_sdi */
+				<4 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdo: i2s2m1-sdo {
+			rockchip,pins =
+				/* i2s2m1_sdo */
+				<4 RK_PB3 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s3 {
+		/omit-if-no-ref/
+		i2s3m0_lrck: i2s3m0-lrck {
+			rockchip,pins =
+				/* i2s3m0_lrck */
+				<3 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_mclk: i2s3m0-mclk {
+			rockchip,pins =
+				/* i2s3m0_mclk */
+				<3 RK_PA2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sclk: i2s3m0-sclk {
+			rockchip,pins =
+				/* i2s3m0_sclk */
+				<3 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdi: i2s3m0-sdi {
+			rockchip,pins =
+				/* i2s3m0_sdi */
+				<3 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdo: i2s3m0-sdo {
+			rockchip,pins =
+				/* i2s3m0_sdo */
+				<3 RK_PA5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_lrck: i2s3m1-lrck {
+			rockchip,pins =
+				/* i2s3m1_lrck */
+				<4 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_mclk: i2s3m1-mclk {
+			rockchip,pins =
+				/* i2s3m1_mclk */
+				<4 RK_PC2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sclk: i2s3m1-sclk {
+			rockchip,pins =
+				/* i2s3m1_sclk */
+				<4 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdi: i2s3m1-sdi {
+			rockchip,pins =
+				/* i2s3m1_sdi */
+				<4 RK_PC6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdo: i2s3m1-sdo {
+			rockchip,pins =
+				/* i2s3m1_sdo */
+				<4 RK_PC5 5 &pcfg_pull_none>;
+		};
+	};
+
+	isp {
+		/omit-if-no-ref/
+		isp_pins: isp-pins {
+			rockchip,pins =
+				/* isp_flashtrigin */
+				<4 RK_PB4 4 &pcfg_pull_none>,
+				/* isp_flashtrigout */
+				<4 RK_PA6 1 &pcfg_pull_none>,
+				/* isp_prelighttrig */
+				<4 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	jtag {
+		/omit-if-no-ref/
+		jtag_pins: jtag-pins {
+			rockchip,pins =
+				/* jtag_tck */
+				<1 RK_PD7 2 &pcfg_pull_none>,
+				/* jtag_tms */
+				<2 RK_PA0 2 &pcfg_pull_none>;
+		};
+	};
+
+	lcdc {
+		/omit-if-no-ref/
+		lcdc_ctl: lcdc-ctl {
+			rockchip,pins =
+				/* lcdc_clk */
+				<3 RK_PA0 1 &pcfg_pull_none>,
+				/* lcdc_d0 */
+				<2 RK_PD0 1 &pcfg_pull_none>,
+				/* lcdc_d1 */
+				<2 RK_PD1 1 &pcfg_pull_none>,
+				/* lcdc_d2 */
+				<2 RK_PD2 1 &pcfg_pull_none>,
+				/* lcdc_d3 */
+				<2 RK_PD3 1 &pcfg_pull_none>,
+				/* lcdc_d4 */
+				<2 RK_PD4 1 &pcfg_pull_none>,
+				/* lcdc_d5 */
+				<2 RK_PD5 1 &pcfg_pull_none>,
+				/* lcdc_d6 */
+				<2 RK_PD6 1 &pcfg_pull_none>,
+				/* lcdc_d7 */
+				<2 RK_PD7 1 &pcfg_pull_none>,
+				/* lcdc_d8 */
+				<3 RK_PA1 1 &pcfg_pull_none>,
+				/* lcdc_d9 */
+				<3 RK_PA2 1 &pcfg_pull_none>,
+				/* lcdc_d10 */
+				<3 RK_PA3 1 &pcfg_pull_none>,
+				/* lcdc_d11 */
+				<3 RK_PA4 1 &pcfg_pull_none>,
+				/* lcdc_d12 */
+				<3 RK_PA5 1 &pcfg_pull_none>,
+				/* lcdc_d13 */
+				<3 RK_PA6 1 &pcfg_pull_none>,
+				/* lcdc_d14 */
+				<3 RK_PA7 1 &pcfg_pull_none>,
+				/* lcdc_d15 */
+				<3 RK_PB0 1 &pcfg_pull_none>,
+				/* lcdc_d16 */
+				<3 RK_PB1 1 &pcfg_pull_none>,
+				/* lcdc_d17 */
+				<3 RK_PB2 1 &pcfg_pull_none>,
+				/* lcdc_d18 */
+				<3 RK_PB3 1 &pcfg_pull_none>,
+				/* lcdc_d19 */
+				<3 RK_PB4 1 &pcfg_pull_none>,
+				/* lcdc_d20 */
+				<3 RK_PB5 1 &pcfg_pull_none>,
+				/* lcdc_d21 */
+				<3 RK_PB6 1 &pcfg_pull_none>,
+				/* lcdc_d22 */
+				<3 RK_PB7 1 &pcfg_pull_none>,
+				/* lcdc_d23 */
+				<3 RK_PC0 1 &pcfg_pull_none>,
+				/* lcdc_den */
+				<3 RK_PC3 1 &pcfg_pull_none>,
+				/* lcdc_hsync */
+				<3 RK_PC1 1 &pcfg_pull_none>,
+				/* lcdc_vsync */
+				<3 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	mcu {
+		/omit-if-no-ref/
+		mcu_pins: mcu-pins {
+			rockchip,pins =
+				/* mcu_jtagtck */
+				<0 RK_PB4 4 &pcfg_pull_none>,
+				/* mcu_jtagtdi */
+				<0 RK_PC1 4 &pcfg_pull_none>,
+				/* mcu_jtagtdo */
+				<0 RK_PB3 4 &pcfg_pull_none>,
+				/* mcu_jtagtms */
+				<0 RK_PC2 4 &pcfg_pull_none>,
+				/* mcu_jtagtrstn */
+				<0 RK_PC3 4 &pcfg_pull_none>;
+		};
+	};
+
+	npu {
+		/omit-if-no-ref/
+		npu_pins: npu-pins {
+			rockchip,pins =
+				/* npu_avs */
+				<0 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pcie20 {
+		/omit-if-no-ref/
+		pcie20m0_pins: pcie20m0-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm0 */
+				<0 RK_PA5 3 &pcfg_pull_none>,
+				/* pcie20_perstnm0 */
+				<0 RK_PB6 3 &pcfg_pull_none>,
+				/* pcie20_wakenm0 */
+				<0 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m1_pins: pcie20m1-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm1 */
+				<2 RK_PD0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm1 */
+				<3 RK_PC1 4 &pcfg_pull_none>,
+				/* pcie20_wakenm1 */
+				<2 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m2_pins: pcie20m2-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm2 */
+				<1 RK_PB0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm2 */
+				<1 RK_PB2 4 &pcfg_pull_none>,
+				/* pcie20_wakenm2 */
+				<1 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20_buttonrstn: pcie20-buttonrstn {
+			rockchip,pins =
+				/* pcie20_buttonrstn */
+				<0 RK_PB4 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x1 {
+		/omit-if-no-ref/
+		pcie30x1m0_pins: pcie30x1m0-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm0 */
+				<0 RK_PA4 3 &pcfg_pull_none>,
+				/* pcie30x1_perstnm0 */
+				<0 RK_PC3 3 &pcfg_pull_none>,
+				/* pcie30x1_wakenm0 */
+				<0 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m1_pins: pcie30x1m1-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm1 */
+				<2 RK_PD2 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm1 */
+				<3 RK_PA1 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm1 */
+				<2 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m2_pins: pcie30x1m2-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm2 */
+				<1 RK_PA5 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm2 */
+				<1 RK_PA2 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm2 */
+				<1 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1_buttonrstn: pcie30x1-buttonrstn {
+			rockchip,pins =
+				/* pcie30x1_buttonrstn */
+				<0 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x2 {
+		/omit-if-no-ref/
+		pcie30x2m0_pins: pcie30x2m0-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm0 */
+				<0 RK_PA6 2 &pcfg_pull_none>,
+				/* pcie30x2_perstnm0 */
+				<0 RK_PC6 3 &pcfg_pull_none>,
+				/* pcie30x2_wakenm0 */
+				<0 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m1_pins: pcie30x2m1-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm1 */
+				<2 RK_PD4 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm1 */
+				<2 RK_PD6 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm1 */
+				<2 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m2_pins: pcie30x2m2-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm2 */
+				<4 RK_PC2 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm2 */
+				<4 RK_PC4 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm2 */
+				<4 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2_buttonrstn: pcie30x2-buttonrstn {
+			rockchip,pins =
+				/* pcie30x2_buttonrstn */
+				<0 RK_PB0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pdm {
+		/omit-if-no-ref/
+		pdmm0_clk: pdmm0-clk {
+			rockchip,pins =
+				/* pdm_clk0m0 */
+				<1 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_clk1: pdmm0-clk1 {
+			rockchip,pins =
+				/* pdmm0_clk1 */
+				<1 RK_PA4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi0: pdmm0-sdi0 {
+			rockchip,pins =
+				/* pdmm0_sdi0 */
+				<1 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi1: pdmm0-sdi1 {
+			rockchip,pins =
+				/* pdmm0_sdi1 */
+				<1 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi2: pdmm0-sdi2 {
+			rockchip,pins =
+				/* pdmm0_sdi2 */
+				<1 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi3: pdmm0-sdi3 {
+			rockchip,pins =
+				/* pdmm0_sdi3 */
+				<1 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk: pdmm1-clk {
+			rockchip,pins =
+				/* pdm_clk0m1 */
+				<3 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk1: pdmm1-clk1 {
+			rockchip,pins =
+				/* pdmm1_clk1 */
+				<4 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi0: pdmm1-sdi0 {
+			rockchip,pins =
+				/* pdmm1_sdi0 */
+				<3 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi1: pdmm1-sdi1 {
+			rockchip,pins =
+				/* pdmm1_sdi1 */
+				<4 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi2: pdmm1-sdi2 {
+			rockchip,pins =
+				/* pdmm1_sdi2 */
+				<4 RK_PA2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi3: pdmm1-sdi3 {
+			rockchip,pins =
+				/* pdmm1_sdi3 */
+				<4 RK_PA3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_clk1: pdmm2-clk1 {
+			rockchip,pins =
+				/* pdmm2_clk1 */
+				<3 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi0: pdmm2-sdi0 {
+			rockchip,pins =
+				/* pdmm2_sdi0 */
+				<3 RK_PB3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi1: pdmm2-sdi1 {
+			rockchip,pins =
+				/* pdmm2_sdi1 */
+				<3 RK_PB4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi2: pdmm2-sdi2 {
+			rockchip,pins =
+				/* pdmm2_sdi2 */
+				<3 RK_PB7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi3: pdmm2-sdi3 {
+			rockchip,pins =
+				/* pdmm2_sdi3 */
+				<3 RK_PC0 5 &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		/omit-if-no-ref/
+		pmic_pins: pmic-pins {
+			rockchip,pins =
+				/* pmic_sleep */
+				<0 RK_PA2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pmu {
+		/omit-if-no-ref/
+		pmu_pins: pmu-pins {
+			rockchip,pins =
+				/* pmu_debug0 */
+				<0 RK_PA5 4 &pcfg_pull_none>,
+				/* pmu_debug1 */
+				<0 RK_PA6 3 &pcfg_pull_none>,
+				/* pmu_debug2 */
+				<0 RK_PC4 4 &pcfg_pull_none>,
+				/* pmu_debug3 */
+				<0 RK_PC5 4 &pcfg_pull_none>,
+				/* pmu_debug4 */
+				<0 RK_PC6 4 &pcfg_pull_none>,
+				/* pmu_debug5 */
+				<0 RK_PC7 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm0 {
+		/omit-if-no-ref/
+		pwm0m0_pins: pwm0m0-pins {
+			rockchip,pins =
+				/* pwm0_m0 */
+				<0 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm0m1_pins: pwm0m1-pins {
+			rockchip,pins =
+				/* pwm0_m1 */
+				<0 RK_PC7 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm1 {
+		/omit-if-no-ref/
+		pwm1m0_pins: pwm1m0-pins {
+			rockchip,pins =
+				/* pwm1_m0 */
+				<0 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm1m1_pins: pwm1m1-pins {
+			rockchip,pins =
+				/* pwm1_m1 */
+				<0 RK_PB5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm2 {
+		/omit-if-no-ref/
+		pwm2m0_pins: pwm2m0-pins {
+			rockchip,pins =
+				/* pwm2_m0 */
+				<0 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm2m1_pins: pwm2m1-pins {
+			rockchip,pins =
+				/* pwm2_m1 */
+				<0 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm3 {
+		/omit-if-no-ref/
+		pwm3_pins: pwm3-pins {
+			rockchip,pins =
+				/* pwm3_ir */
+				<0 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm4 {
+		/omit-if-no-ref/
+		pwm4_pins: pwm4-pins {
+			rockchip,pins =
+				/* pwm4 */
+				<0 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm5 {
+		/omit-if-no-ref/
+		pwm5_pins: pwm5-pins {
+			rockchip,pins =
+				/* pwm5 */
+				<0 RK_PC4 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm6 {
+		/omit-if-no-ref/
+		pwm6_pins: pwm6-pins {
+			rockchip,pins =
+				/* pwm6 */
+				<0 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm7 {
+		/omit-if-no-ref/
+		pwm7_pins: pwm7-pins {
+			rockchip,pins =
+				/* pwm7_ir */
+				<0 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm8 {
+		/omit-if-no-ref/
+		pwm8m0_pins: pwm8m0-pins {
+			rockchip,pins =
+				/* pwm8_m0 */
+				<3 RK_PB1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm8m1_pins: pwm8m1-pins {
+			rockchip,pins =
+				/* pwm8_m1 */
+				<1 RK_PD5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm9 {
+		/omit-if-no-ref/
+		pwm9m0_pins: pwm9m0-pins {
+			rockchip,pins =
+				/* pwm9_m0 */
+				<3 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm9m1_pins: pwm9m1-pins {
+			rockchip,pins =
+				/* pwm9_m1 */
+				<1 RK_PD6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm10 {
+		/omit-if-no-ref/
+		pwm10m0_pins: pwm10m0-pins {
+			rockchip,pins =
+				/* pwm10_m0 */
+				<3 RK_PB5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm10m1_pins: pwm10m1-pins {
+			rockchip,pins =
+				/* pwm10_m1 */
+				<2 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm11 {
+		/omit-if-no-ref/
+		pwm11m0_pins: pwm11m0-pins {
+			rockchip,pins =
+				/* pwm11_irm0 */
+				<3 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm11m1_pins: pwm11m1-pins {
+			rockchip,pins =
+				/* pwm11_irm1 */
+				<4 RK_PC0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pwm12 {
+		/omit-if-no-ref/
+		pwm12m0_pins: pwm12m0-pins {
+			rockchip,pins =
+				/* pwm12_m0 */
+				<3 RK_PB7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm12m1_pins: pwm12m1-pins {
+			rockchip,pins =
+				/* pwm12_m1 */
+				<4 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm13 {
+		/omit-if-no-ref/
+		pwm13m0_pins: pwm13m0-pins {
+			rockchip,pins =
+				/* pwm13_m0 */
+				<3 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm13m1_pins: pwm13m1-pins {
+			rockchip,pins =
+				/* pwm13_m1 */
+				<4 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm14 {
+		/omit-if-no-ref/
+		pwm14m0_pins: pwm14m0-pins {
+			rockchip,pins =
+				/* pwm14_m0 */
+				<3 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm14m1_pins: pwm14m1-pins {
+			rockchip,pins =
+				/* pwm14_m1 */
+				<4 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm15 {
+		/omit-if-no-ref/
+		pwm15m0_pins: pwm15m0-pins {
+			rockchip,pins =
+				/* pwm15_irm0 */
+				<3 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm15m1_pins: pwm15m1-pins {
+			rockchip,pins =
+				/* pwm15_irm1 */
+				<4 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	refclk {
+		/omit-if-no-ref/
+		refclk_pins: refclk-pins {
+			rockchip,pins =
+				/* refclk_ou */
+				<0 RK_PA0 1 &pcfg_pull_none>;
+		};
+	};
+
+	sata {
+		/omit-if-no-ref/
+		sata_pins: sata-pins {
+			rockchip,pins =
+				/* sata_cpdet */
+				<0 RK_PA4 2 &pcfg_pull_none>,
+				/* sata_cppod */
+				<0 RK_PA6 1 &pcfg_pull_none>,
+				/* sata_mpswitch */
+				<0 RK_PA5 2 &pcfg_pull_none>;
+		};
+	};
+
+	sata0 {
+		/omit-if-no-ref/
+		sata0_pins: sata0-pins {
+			rockchip,pins =
+				/* sata0_actled */
+				<4 RK_PC6 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata1 {
+		/omit-if-no-ref/
+		sata1_pins: sata1-pins {
+			rockchip,pins =
+				/* sata1_actled */
+				<4 RK_PC5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata2 {
+		/omit-if-no-ref/
+		sata2_pins: sata2-pins {
+			rockchip,pins =
+				/* sata2_actled */
+				<4 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	scr {
+		/omit-if-no-ref/
+		scr_pins: scr-pins {
+			rockchip,pins =
+				/* scr_clk */
+				<1 RK_PA2 3 &pcfg_pull_none>,
+				/* scr_det */
+				<1 RK_PA7 3 &pcfg_pull_up>,
+				/* scr_io */
+				<1 RK_PA3 3 &pcfg_pull_up>,
+				/* scr_rst */
+				<1 RK_PA5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc0 {
+		/omit-if-no-ref/
+		sdmmc0_bus4: sdmmc0-bus4 {
+			rockchip,pins =
+				/* sdmmc0_d0 */
+				<1 RK_PD5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d1 */
+				<1 RK_PD6 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d2 */
+				<1 RK_PD7 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d3 */
+				<2 RK_PA0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_clk: sdmmc0-clk {
+			rockchip,pins =
+				/* sdmmc0_clk */
+				<2 RK_PA2 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_cmd: sdmmc0-cmd {
+			rockchip,pins =
+				/* sdmmc0_cmd */
+				<2 RK_PA1 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_det: sdmmc0-det {
+			rockchip,pins =
+				/* sdmmc0_det */
+				<0 RK_PA4 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_pwren: sdmmc0-pwren {
+			rockchip,pins =
+				/* sdmmc0_pwren */
+				<0 RK_PA5 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc1 {
+		/omit-if-no-ref/
+		sdmmc1_bus4: sdmmc1-bus4 {
+			rockchip,pins =
+				/* sdmmc1_d0 */
+				<2 RK_PA3 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d1 */
+				<2 RK_PA4 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d2 */
+				<2 RK_PA5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d3 */
+				<2 RK_PA6 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_clk: sdmmc1-clk {
+			rockchip,pins =
+				/* sdmmc1_clk */
+				<2 RK_PB0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_cmd: sdmmc1-cmd {
+			rockchip,pins =
+				/* sdmmc1_cmd */
+				<2 RK_PA7 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_det: sdmmc1-det {
+			rockchip,pins =
+				/* sdmmc1_det */
+				<2 RK_PB2 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_pwren: sdmmc1-pwren {
+			rockchip,pins =
+				/* sdmmc1_pwren */
+				<2 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc2 {
+		/omit-if-no-ref/
+		sdmmc2m0_bus4: sdmmc2m0-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m0 */
+				<3 RK_PC6 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m0 */
+				<3 RK_PC7 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m0 */
+				<3 RK_PD0 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m0 */
+				<3 RK_PD1 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_clk: sdmmc2m0-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm0 */
+				<3 RK_PD3 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_cmd: sdmmc2m0-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm0 */
+				<3 RK_PD2 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_det: sdmmc2m0-det {
+			rockchip,pins =
+				/* sdmmc2_detm0 */
+				<3 RK_PD4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_pwren: sdmmc2m0-pwren {
+			rockchip,pins =
+				/* sdmmc2m0_pwren */
+				<3 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_bus4: sdmmc2m1-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m1 */
+				<3 RK_PA1 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m1 */
+				<3 RK_PA2 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m1 */
+				<3 RK_PA3 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m1 */
+				<3 RK_PA4 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_clk: sdmmc2m1-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm1 */
+				<3 RK_PA6 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_cmd: sdmmc2m1-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm1 */
+				<3 RK_PA5 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_det: sdmmc2m1-det {
+			rockchip,pins =
+				/* sdmmc2_detm1 */
+				<3 RK_PA7 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_pwren: sdmmc2m1-pwren {
+			rockchip,pins =
+				/* sdmmc2m1_pwren */
+				<3 RK_PB0 4 &pcfg_pull_none>;
+		};
+	};
+
+	spdif {
+		/omit-if-no-ref/
+		spdifm0_tx: spdifm0-tx {
+			rockchip,pins =
+				/* spdifm0_tx */
+				<1 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm1_tx: spdifm1-tx {
+			rockchip,pins =
+				/* spdifm1_tx */
+				<3 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm2_tx: spdifm2-tx {
+			rockchip,pins =
+				/* spdifm2_tx */
+				<4 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	spi0 {
+		/omit-if-no-ref/
+		spi0m0_pins: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_none>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_none>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_none>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_none>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi1 {
+		/omit-if-no-ref/
+		spi1m0_pins: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_none>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_none>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_none>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_none>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi2 {
+		/omit-if-no-ref/
+		spi2m0_pins: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_none>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_none>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_none>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_none>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi3 {
+		/omit-if-no-ref/
+		spi3m0_pins: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_none>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_none>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_none>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_none>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_none>;
+		};
+	};
+
+	tsadc {
+		/omit-if-no-ref/
+		tsadcm0_shut: tsadcm0-shut {
+			rockchip,pins =
+				/* tsadcm0_shut */
+				<0 RK_PA1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadcm1_shut: tsadcm1-shut {
+			rockchip,pins =
+				/* tsadcm1_shut */
+				<0 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadc_shutorg: tsadc-shutorg {
+			rockchip,pins =
+				/* tsadc_shutorg */
+				<0 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	uart0 {
+		/omit-if-no-ref/
+		uart0_xfer: uart0-xfer {
+			rockchip,pins =
+				/* uart0_rx */
+				<0 RK_PC0 3 &pcfg_pull_up>,
+				/* uart0_tx */
+				<0 RK_PC1 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart0_ctsn: uart0-ctsn {
+			rockchip,pins =
+				/* uart0_ctsn */
+				<0 RK_PC7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart0_rtsn: uart0-rtsn {
+			rockchip,pins =
+				/* uart0_rtsn */
+				<0 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	uart1 {
+		/omit-if-no-ref/
+		uart1m0_xfer: uart1m0-xfer {
+			rockchip,pins =
+				/* uart1_rxm0 */
+				<2 RK_PB3 2 &pcfg_pull_up>,
+				/* uart1_txm0 */
+				<2 RK_PB4 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_ctsn: uart1m0-ctsn {
+			rockchip,pins =
+				/* uart1m0_ctsn */
+				<2 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_rtsn: uart1m0-rtsn {
+			rockchip,pins =
+				/* uart1m0_rtsn */
+				<2 RK_PB5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_xfer: uart1m1-xfer {
+			rockchip,pins =
+				/* uart1_rxm1 */
+				<3 RK_PD7 4 &pcfg_pull_up>,
+				/* uart1_txm1 */
+				<3 RK_PD6 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_ctsn: uart1m1-ctsn {
+			rockchip,pins =
+				/* uart1m1_ctsn */
+				<4 RK_PC1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_rtsn: uart1m1-rtsn {
+			rockchip,pins =
+				/* uart1m1_rtsn */
+				<4 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	uart2 {
+		/omit-if-no-ref/
+		uart2m0_xfer: uart2m0-xfer {
+			rockchip,pins =
+				/* uart2_rxm0 */
+				<0 RK_PD0 1 &pcfg_pull_up>,
+				/* uart2_txm0 */
+				<0 RK_PD1 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart2m1_xfer: uart2m1-xfer {
+			rockchip,pins =
+				/* uart2_rxm1 */
+				<1 RK_PD6 2 &pcfg_pull_up>,
+				/* uart2_txm1 */
+				<1 RK_PD5 2 &pcfg_pull_up>;
+		};
+	};
+
+	uart3 {
+		/omit-if-no-ref/
+		uart3m0_xfer: uart3m0-xfer {
+			rockchip,pins =
+				/* uart3_rxm0 */
+				<1 RK_PA0 2 &pcfg_pull_up>,
+				/* uart3_txm0 */
+				<1 RK_PA1 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_ctsn: uart3m0-ctsn {
+			rockchip,pins =
+				/* uart3m0_ctsn */
+				<1 RK_PA3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_rtsn: uart3m0-rtsn {
+			rockchip,pins =
+				/* uart3m0_rtsn */
+				<1 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m1_xfer: uart3m1-xfer {
+			rockchip,pins =
+				/* uart3_rxm1 */
+				<3 RK_PC0 4 &pcfg_pull_up>,
+				/* uart3_txm1 */
+				<3 RK_PB7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart4 {
+		/omit-if-no-ref/
+		uart4m0_xfer: uart4m0-xfer {
+			rockchip,pins =
+				/* uart4_rxm0 */
+				<1 RK_PA4 2 &pcfg_pull_up>,
+				/* uart4_txm0 */
+				<1 RK_PA6 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_ctsn: uart4m0-ctsn {
+			rockchip,pins =
+				/* uart4m0_ctsn */
+				<1 RK_PA7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_rtsn: uart4m0-rtsn {
+			rockchip,pins =
+				/* uart4m0_rtsn */
+				<1 RK_PA5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m1_xfer: uart4m1-xfer {
+			rockchip,pins =
+				/* uart4_rxm1 */
+				<3 RK_PB1 4 &pcfg_pull_up>,
+				/* uart4_txm1 */
+				<3 RK_PB2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart5 {
+		/omit-if-no-ref/
+		uart5m0_xfer: uart5m0-xfer {
+			rockchip,pins =
+				/* uart5_rxm0 */
+				<2 RK_PA1 3 &pcfg_pull_up>,
+				/* uart5_txm0 */
+				<2 RK_PA2 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_ctsn: uart5m0-ctsn {
+			rockchip,pins =
+				/* uart5m0_ctsn */
+				<1 RK_PD7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_rtsn: uart5m0-rtsn {
+			rockchip,pins =
+				/* uart5m0_rtsn */
+				<2 RK_PA0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m1_xfer: uart5m1-xfer {
+			rockchip,pins =
+				/* uart5_rxm1 */
+				<3 RK_PC3 4 &pcfg_pull_up>,
+				/* uart5_txm1 */
+				<3 RK_PC2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart6 {
+		/omit-if-no-ref/
+		uart6m0_xfer: uart6m0-xfer {
+			rockchip,pins =
+				/* uart6_rxm0 */
+				<2 RK_PA3 3 &pcfg_pull_up>,
+				/* uart6_txm0 */
+				<2 RK_PA4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_ctsn: uart6m0-ctsn {
+			rockchip,pins =
+				/* uart6m0_ctsn */
+				<2 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_rtsn: uart6m0-rtsn {
+			rockchip,pins =
+				/* uart6m0_rtsn */
+				<2 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m1_xfer: uart6m1-xfer {
+			rockchip,pins =
+				/* uart6_rxm1 */
+				<1 RK_PD6 3 &pcfg_pull_up>,
+				/* uart6_txm1 */
+				<1 RK_PD5 3 &pcfg_pull_up>;
+		};
+	};
+
+	uart7 {
+		/omit-if-no-ref/
+		uart7m0_xfer: uart7m0-xfer {
+			rockchip,pins =
+				/* uart7_rxm0 */
+				<2 RK_PA5 3 &pcfg_pull_up>,
+				/* uart7_txm0 */
+				<2 RK_PA6 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_ctsn: uart7m0-ctsn {
+			rockchip,pins =
+				/* uart7m0_ctsn */
+				<2 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_rtsn: uart7m0-rtsn {
+			rockchip,pins =
+				/* uart7m0_rtsn */
+				<2 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m1_xfer: uart7m1-xfer {
+			rockchip,pins =
+				/* uart7_rxm1 */
+				<3 RK_PC5 4 &pcfg_pull_up>,
+				/* uart7_txm1 */
+				<3 RK_PC4 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m2_xfer: uart7m2-xfer {
+			rockchip,pins =
+				/* uart7_rxm2 */
+				<4 RK_PA3 4 &pcfg_pull_up>,
+				/* uart7_txm2 */
+				<4 RK_PA2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart8 {
+		/omit-if-no-ref/
+		uart8m0_xfer: uart8m0-xfer {
+			rockchip,pins =
+				/* uart8_rxm0 */
+				<2 RK_PC6 2 &pcfg_pull_up>,
+				/* uart8_txm0 */
+				<2 RK_PC5 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_ctsn: uart8m0-ctsn {
+			rockchip,pins =
+				/* uart8m0_ctsn */
+				<2 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_rtsn: uart8m0-rtsn {
+			rockchip,pins =
+				/* uart8m0_rtsn */
+				<2 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m1_xfer: uart8m1-xfer {
+			rockchip,pins =
+				/* uart8_rxm1 */
+				<3 RK_PA0 4 &pcfg_pull_up>,
+				/* uart8_txm1 */
+				<2 RK_PD7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart9 {
+		/omit-if-no-ref/
+		uart9m0_xfer: uart9m0-xfer {
+			rockchip,pins =
+				/* uart9_rxm0 */
+				<2 RK_PA7 3 &pcfg_pull_up>,
+				/* uart9_txm0 */
+				<2 RK_PB0 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_ctsn: uart9m0-ctsn {
+			rockchip,pins =
+				/* uart9m0_ctsn */
+				<2 RK_PC4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_rtsn: uart9m0-rtsn {
+			rockchip,pins =
+				/* uart9m0_rtsn */
+				<2 RK_PC3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m1_xfer: uart9m1-xfer {
+			rockchip,pins =
+				/* uart9_rxm1 */
+				<4 RK_PC6 4 &pcfg_pull_up>,
+				/* uart9_txm1 */
+				<4 RK_PC5 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m2_xfer: uart9m2-xfer {
+			rockchip,pins =
+				/* uart9_rxm2 */
+				<4 RK_PA5 4 &pcfg_pull_up>,
+				/* uart9_txm2 */
+				<4 RK_PA4 4 &pcfg_pull_up>;
+		};
+	};
+
+	vop {
+		/omit-if-no-ref/
+		vopm0_pins: vopm0-pins {
+			rockchip,pins =
+				/* vop_pwmm0 */
+				<0 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		vopm1_pins: vopm1-pins {
+			rockchip,pins =
+				/* vop_pwmm1 */
+				<3 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+};
+
+/*
+ * This part is edited handly.
+ */
+&pinctrl {
+	spi0-hs {
+		/omit-if-no-ref/
+		spi0m0_pins_hs: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0_hs: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1_hs: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins_hs: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0_hs: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi1-hs {
+		/omit-if-no-ref/
+		spi1m0_pins_hs: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0_hs: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1_hs: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins_hs: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0_hs: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi2-hs {
+		/omit-if-no-ref/
+		spi2m0_pins_hs: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0_hs: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1_hs: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins_hs: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0_hs: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1_hs: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi3-hs {
+		/omit-if-no-ref/
+		spi3m0_pins_hs: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0_hs: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1_hs: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins_hs: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0_hs: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1_hs: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	gmac-txd-level3 {
+		/omit-if-no-ref/
+		gmac0_tx_bus2_level3: gmac0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus_level3: gmac0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2_level3: gmac1m0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus_level3: gmac1m0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2_level3: gmac1m1-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus_level3: gmac1m1-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_3>;
+		};
+	};
+
+	gmac-txc-level2 {
+		/omit-if-no-ref/
+		gmac0_rgmii_clk_level2: gmac0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk_level2: gmac1m0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk_level2: gmac1m1-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
new file mode 100644
index 000000000000..7983fa13d93f
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -0,0 +1,779 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/clock/rk3568-cru.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,boot-mode.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+	compatible = "rockchip,rk3568";
+
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x0>;
+			clocks = <&scmi_clk 0>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x300>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+	};
+
+	cpu0_opp_table: cpu0-opp-table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <975000 975000 1150000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1050000 1050000 1150000>;
+		};
+
+		opp-1992000000 {
+			opp-hz = /bits/ 64 <1992000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+		};
+	};
+
+	firmware {
+		scmi: scmi {
+			compatible = "arm,scmi-smc";
+			arm,smc-id = <0x82000010>;
+			shmem = <&scmi_shmem>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			scmi_clk: protocol at 14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+		};
+
+	};
+
+	pmu {
+		compatible = "arm,cortex-a55-pmu";
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+		arm,no-tick-in-suspend;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+		#clock-cells = <0>;
+	};
+
+	xin32k: xin32k {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		clock-output-names = "xin32k";
+		pinctrl-0 = <&clk32k_out0>;
+		pinctrl-names = "default";
+		#clock-cells = <0>;
+	};
+
+	sram at 10f000 {
+		compatible = "mmio-sram";
+		reg = <0x0 0x0010f000 0x0 0x100>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x0 0x0010f000 0x100>;
+
+		scmi_shmem: sram at 0 {
+			compatible = "arm,scmi-shmem";
+			reg = <0x0 0x100>;
+		};
+	};
+
+	gic: interrupt-controller at fd400000 {
+		compatible = "arm,gic-v3";
+		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
+		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		mbi-alias = <0x0 0xfd400000>;
+		mbi-ranges = <296 24>;
+		msi-controller;
+	};
+
+	pmugrf: syscon at fdc20000 {
+		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc20000 0x0 0x10000>;
+	};
+
+	grf: syscon at fdc60000 {
+		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc60000 0x0 0x10000>;
+	};
+
+	pmucru: clock-controller at fdd00000 {
+		compatible = "rockchip,rk3568-pmucru";
+		reg = <0x0 0xfdd00000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at fdd20000 {
+		compatible = "rockchip,rk3568-cru";
+		reg = <0x0 0xfdd20000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	i2c0: i2c at fdd40000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfdd40000 0x0 0x1000>;
+		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart0: serial at fdd50000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfdd50000 0x0 0x100>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 0>, <&dmac0 1>;
+		pinctrl-0 = <&uart0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm0: pwm at fdd70000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70000 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm0m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm1: pwm at fdd70010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70010 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm1m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm2: pwm at fdd70020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70020 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm2m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm3: pwm at fdd70030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70030 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm3_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	sdmmc2: mmc at fe000000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe000000 0x0 0x4000>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
+			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC2>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc0: mmc at fe2b0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2b0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
+			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC0>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc1: mmc at fe2c0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2c0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
+			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC1>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdhci: mmc at fe310000 {
+		compatible = "rockchip,rk3568-dwcmshc";
+		reg = <0x0 0xfe310000 0x0 0x10000>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
+		assigned-clock-rates = <200000000>, <24000000>;
+		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
+			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
+			 <&cru TCLK_EMMC>;
+		clock-names = "core", "bus", "axi", "block", "timer";
+		status = "disabled";
+	};
+
+	dmac0: dmac at fe530000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe530000 0x0 0x4000>;
+		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	dmac1: dmac at fe550000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe550000 0x0 0x4000>;
+		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	i2c1: i2c at fe5a0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c1_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at fe5b0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5b0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c2m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at fe5c0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5c0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c3m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at fe5d0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5d0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c4m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at fe5e0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5e0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c5m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	wdt: watchdog at fe600000 {
+		compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
+		reg = <0x0 0xfe600000 0x0 0x100>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
+		clock-names = "tclk", "pclk";
+	};
+
+	uart1: serial at fe650000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe650000 0x0 0x100>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 2>, <&dmac0 3>;
+		pinctrl-0 = <&uart1m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart2: serial at fe660000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe660000 0x0 0x100>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 4>, <&dmac0 5>;
+		pinctrl-0 = <&uart2m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart3: serial at fe670000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe670000 0x0 0x100>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 6>, <&dmac0 7>;
+		pinctrl-0 = <&uart3m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart4: serial at fe680000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe680000 0x0 0x100>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 8>, <&dmac0 9>;
+		pinctrl-0 = <&uart4m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart5: serial at fe690000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe690000 0x0 0x100>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 10>, <&dmac0 11>;
+		pinctrl-0 = <&uart5m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart6: serial at fe6a0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6a0000 0x0 0x100>;
+		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 12>, <&dmac0 13>;
+		pinctrl-0 = <&uart6m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart7: serial at fe6b0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6b0000 0x0 0x100>;
+		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 14>, <&dmac0 15>;
+		pinctrl-0 = <&uart7m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart8: serial at fe6c0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6c0000 0x0 0x100>;
+		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 16>, <&dmac0 17>;
+		pinctrl-0 = <&uart8m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart9: serial at fe6d0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6d0000 0x0 0x100>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 18>, <&dmac0 19>;
+		pinctrl-0 = <&uart9m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm4: pwm at fe6e0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm4_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm5: pwm at fe6e0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm5_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm6: pwm at fe6e0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm6_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm7: pwm at fe6e0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm7_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm8: pwm at fe6f0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm8m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm9: pwm at fe6f0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm9m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm10: pwm at fe6f0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm10m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm11: pwm at fe6f0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm11m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm12: pwm at fe700000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700000 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm12m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm13: pwm at fe700010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700010 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm13m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm14: pwm at fe700020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700020 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm14m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm15: pwm at fe700030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700030 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm15m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3568-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gpio0: gpio at fdd60000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfdd60000 0x0 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio1: gpio at fe740000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe740000 0x0 0x100>;
+			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio2: gpio at fe750000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe750000 0x0 0x100>;
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio3: gpio at fe760000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe760000 0x0 0x100>;
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio4: gpio at fe770000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe770000 0x0 0x100>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
+
+#include "rk3568-pinctrl.dtsi"
-- 
2.17.1





From cl at rock-chips.com  Wed Apr 28 14:50:14 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Wed, 28 Apr 2021 21:50:14 +0800
Subject: [PATCH v3 10/10] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210428134759.22076-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
Message-ID: <20210428135014.22593-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
add uart/emmc/i2c/rk809 node for basic function.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/arm/rockchip.yaml     |  5 ++
 arch/arm64/boot/dts/rockchip/Makefile         |  1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 80 +++++++++++++++++++
 3 files changed, 86 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4a6f772c1043..6546b015fc62 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -600,6 +600,11 @@ properties:
           - const: zkmagic,a95x-z2
           - const: rockchip,rk3318
 
+      - description: Rockchip RK3568 Evaluation board
+        items:
+          - const: rockchip,rk3568-evb1-v10
+          - const: rockchip,rk3568
+
 additionalProperties: true
 
 ...
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index c3e00c0e2db7..7fdb41de01ec 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -51,3 +51,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
new file mode 100644
index 000000000000..33a97ce03c84
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3568.dtsi"
+
+/ {
+	model = "Rockchip RK3568 EVB1 DDR4 V10 Board";
+	compatible = "rockchip,rk3568-evb1-v10", "rockchip,rk3568";
+
+	chosen: chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		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>;
+	};
+
+	vcc3v3_lcd0_n: vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_lcd1_n: vcc3v3-lcd1-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd1_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	rockchip,txclk-tapnum = <0x8>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
-- 
2.17.1





From lkp at intel.com  Wed Apr 28 14:57:24 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 21:57:24 +0800
Subject: [xlnx:xlnx_rebase_v5.4 842/1755] drivers/spi/spi-mem.c:18:6:
 warning: no previous prototype for 'update_stripe'
Message-ID: <202104282116.bhoUcl6A-lkp@intel.com>

Hi Amit,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: 3780469dd372e934445de2fbb5e8cf6e712b9b99 [842/1755] spi: Add Zynq QSPI controller driver
config: i386-randconfig-r006-20210428 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/3780469dd372e934445de2fbb5e8cf6e712b9b99
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 3780469dd372e934445de2fbb5e8cf6e712b9b99
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

>> drivers/spi/spi-mem.c:18:6: warning: no previous prototype for 'update_stripe' [-Wmissing-prototypes]
      18 | bool update_stripe(const u8 opcode)
         |      ^~~~~~~~~~~~~


vim +/update_stripe +18 drivers/spi/spi-mem.c

    17	
  > 18	bool update_stripe(const u8 opcode)
    19	{
    20		if (opcode ==  SPINOR_OP_BE_4K ||
    21		    opcode ==  SPINOR_OP_BE_32K ||
    22		    opcode ==  SPINOR_OP_CHIP_ERASE ||
    23		    opcode ==  SPINOR_OP_SE ||
    24		    opcode ==  SPINOR_OP_BE_32K_4B ||
    25		    opcode ==  SPINOR_OP_SE_4B ||
    26		    opcode == SPINOR_OP_BE_4K_4B ||
    27		    opcode ==  SPINOR_OP_WRSR ||
    28		    opcode ==  SPINOR_OP_WREAR ||
    29		    opcode ==  SPINOR_OP_BRWR ||
    30		    opcode ==  SPINOR_OP_WRSR2)
    31			return false;
    32	
    33		return true;
    34	}
    35	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36987 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/f527e79d/attachment-0001.gz>

From alexandru.elisei at arm.com  Wed Apr 28 15:00:15 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Wed, 28 Apr 2021 15:00:15 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into
 KVM and TCG variants
In-Reply-To: <87fszasjdg.fsf@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org> <87fszasjdg.fsf@linaro.org>
Message-ID: <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>

Hi,

On 4/28/21 1:06 PM, Alex Benn?e wrote:
> Marc Zyngier <maz at kernel.org> writes:
>
>> On 2021-04-28 11:18, Alex Benn?e wrote:
>>> A few of the its-trigger tests rely on IMPDEF behaviour where caches
>>> aren't flushed before invall events. However TCG emulation doesn't
>>> model any invall behaviour and as we can't probe for it we need to be
>>> told. Split the test into a KVM and TCG variant and skip the invall
>>> tests when under TCG.
>>> Signed-off-by: Alex Benn?e <alex.bennee at linaro.org>
>>> Cc: Shashi Mallela <shashi.mallela at linaro.org>
>>> ---
>>>  arm/gic.c         | 60 +++++++++++++++++++++++++++--------------------
>>>  arm/unittests.cfg | 11 ++++++++-
>>>  2 files changed, 45 insertions(+), 26 deletions(-)
>>> diff --git a/arm/gic.c b/arm/gic.c
>>> index 98135ef..96a329d 100644
>>> --- a/arm/gic.c
>>> +++ b/arm/gic.c
>>> @@ -36,6 +36,7 @@ static struct gic *gic;
>>>  static int acked[NR_CPUS], spurious[NR_CPUS];
>>>  static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
>>>  static cpumask_t ready;
>>> +static bool under_tcg;
>>>  static void nr_cpu_check(int nr)
>>>  {
>>> @@ -734,32 +735,38 @@ static void test_its_trigger(void)
>>>  	/*
>>>  	 * re-enable the LPI but willingly do not call invall
>>>  	 * so the change in config is not taken into account.
>>> -	 * The LPI should not hit
>>> +	 * The LPI should not hit. This does however depend on
>>> +	 * implementation defined behaviour - under QEMU TCG emulation
>>> +	 * it can quite correctly process the event directly.
>> It looks to me that you are using an IMPDEF behaviour of *TCG*
>> here. The programming model mandates that there is an invalidation
>> if you change the configuration of the LPI.
> But does it mandate that the LPI cannot be sent until the invalidation?

I think Marc is referring to this section of the GIC architecture (Arm IHI 0069F,
page 5-82, I've highlighted the interesting bits):

"A Redistributor can cache the information from the LPI Configuration tables
pointed to by GICR_PROPBASER, when GICR_CTLR.EnableLPI == 1, subject to all of the
following rules:
* Whether or not one or more caches are present is IMPLEMENTATION DEFINED. Where
at least one cache is present, the structure and size is IMPLEMENTATION DEFINED.
* An LPI Configuration table entry might be allocated into the cache at any time.
* A cached LPI Configuration table entry is not guaranteed to remain in the cache.
* A cached LPI Configuration table entry *is not guaranteed to remain incoherent
with memory*.
* A change to the LPI configuration *is not guaranteed to be visible until an
appropriate invalidation operation has completed*"

I interpret that as that an INVALL guarantees that a change is visible, but it the
change can become visible even without the INVALL.

The test relies on the fact that changes to the LPI tables are not visible *under
KVM* until the INVALL command, but that's not necessarily the case on real
hardware. To match the spec, I think the test "dev2/eventid=20 still does not
trigger any LPI" should be removed and the stats reset should take place before
the configuration for LPI 8195 is set to the default.

Thanks,

Alex



From maz at kernel.org  Wed Apr 28 15:36:08 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 28 Apr 2021 15:36:08 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into
 KVM and TCG variants
In-Reply-To: <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org>
 <87fszasjdg.fsf@linaro.org>
 <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>
Message-ID: <87k0omo4rr.wl-maz@kernel.org>

On Wed, 28 Apr 2021 15:00:15 +0100,
Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> 
> I interpret that as that an INVALL guarantees that a change is
> visible, but it the change can become visible even without the
> INVALL.

Yes. Expecting the LPI to be delivered or not in the absence of an
invalidate when its configuration has been altered is wrong. The
architecture doesn't guarantee anything of the sort.

> The test relies on the fact that changes to the LPI tables are not
> visible *under KVM* until the INVALL command, but that's not
> necessarily the case on real hardware. To match the spec, I think
> the test "dev2/eventid=20 still does not trigger any LPI" should be
> removed and the stats reset should take place before the
> configuration for LPI 8195 is set to the default.

If that's what the test expects (I haven't tried to investigate), it
should be dropped completely, rather than trying to sidestep it for
TCG.

Thanks,

	M.

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


From maz at kernel.org  Wed Apr 28 15:41:17 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 28 Apr 2021 15:41:17 +0100
Subject: [PATCH] arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
In-Reply-To: <20210428111555.50880-1-mark.rutland@arm.com>
References: <20210428111555.50880-1-mark.rutland@arm.com>
Message-ID: <87im46o4j6.wl-maz@kernel.org>

Hi Mark,

On Wed, 28 Apr 2021 12:15:55 +0100,
Mark Rutland <mark.rutland at arm.com> wrote:
> 
> Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"
> on the command line hits a warning during kernel entry, due to the way
> we manipulate the PMR.
> 
> Early in the entry sequence, we call lockdep_hardirqs_off() to inform
> lockdep that interrupts have been masked (as the HW sets DAIF wqhen
> entering an exception). Architecturally PMR_EL1 is not affected by
> exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in
> the exception entry sequence, so early in exception entry the PMR can
> indicate that interrupts are unmasked even though they are masked by
> DAIF.
> 
> If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that
> interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the
> exception entry paths, and hence lockdep_hardirqs_off() will WARN() that
> something is amiss.
> 
> We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during
> exception entry so that kernel code sees a consistent environment. We
> must also update local_daif_inherit() to undo this, as currently only
> touches DAIF. For other paths, local_daif_restore() will update both
> DAIF and the PMR. With this done, we can remove the existing special
> cases which set this later in the entry code.
> 
> We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with
> local_daif_save(), as this will warn if it ever encounters
> (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This
> matches the gic_prio_kentry_setup that we have to retain for
> ret_to_user.
> 
> The original splat from Zenghui's report was:
> 
> | DEBUG_LOCKS_WARN_ON(!irqs_disabled())
> | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8
> | Modules linked in:
> | CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+ #463
> | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
> | pc : lockdep_hardirqs_off+0xd4/0xe8
> | lr : lockdep_hardirqs_off+0xd4/0xe8
> | sp : ffff80002a39bad0
> | pmr_save: 000000e0
> | x29: ffff80002a39bad0 x28: ffff0000de214bc0
> | x27: ffff0000de1c0400 x26: 000000000049b328
> | x25: 0000000000406f30 x24: ffff0000de1c00a0
> | x23: 0000000020400005 x22: ffff8000105f747c
> | x21: 0000000096000044 x20: 0000000000498ef9
> | x19: ffff80002a39bc88 x18: ffffffffffffffff
> | x17: 0000000000000000 x16: ffff800011c61eb0
> | x15: ffff800011700a88 x14: 0720072007200720
> | x13: 0720072007200720 x12: 0720072007200720
> | x11: 0720072007200720 x10: 0720072007200720
> | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
> | x7 : ffff8000119f0800 x6 : c0000000ffff7fff
> | x5 : ffff8000119f07a8 x4 : 0000000000000001
> | x3 : 9bcdab23f2432800 x2 : ffff800011730538
> | x1 : 9bcdab23f2432800 x0 : 0000000000000000
> | Call trace:
> |  lockdep_hardirqs_off+0xd4/0xe8
> |  enter_from_kernel_mode.isra.5+0x7c/0xa8
> |  el1_abort+0x24/0x100
> |  el1_sync_handler+0x80/0xd0
> |  el1_sync+0x6c/0x100
> |  __arch_clear_user+0xc/0x90
> |  load_elf_binary+0x9fc/0x1450
> |  bprm_execve+0x404/0x880
> |  kernel_execve+0x180/0x188
> |  call_usermodehelper_exec_async+0xdc/0x158
> |  ret_from_fork+0x10/0x18
> 
> Fixes: 23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
> Fixes: 7cd1ea1010acbede ("arm64: entry: fix non-NMI kernel<->kernel transitions")
> Fixes: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
> Fixes: 2a9b3e6ac69a8bf1 ("arm64: entry: fix EL1 debug transitions")
> Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3 at huawei.com
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Reported-by: Zenghui Yu <yuzenghui at huawei.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Will Deacon <will at kernel.org>
> ---
>  arch/arm64/include/asm/daifflags.h |  3 +++
>  arch/arm64/kernel/entry-common.c   | 17 -----------------
>  arch/arm64/kernel/entry.S          | 15 ++-------------
>  3 files changed, 5 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
> index 1c26d7baa67f..cfdde3a56805 100644
> --- a/arch/arm64/include/asm/daifflags.h
> +++ b/arch/arm64/include/asm/daifflags.h
> @@ -131,6 +131,9 @@ static inline void local_daif_inherit(struct pt_regs *regs)
>  	if (interrupts_enabled(regs))
>  		trace_hardirqs_on();
>  
> +	if (system_uses_irq_prio_masking())
> +		gic_write_pmr(regs->pmr_save);
> +
>  	/*
>  	 * We can't use local_daif_restore(regs->pstate) here as
>  	 * system_has_prio_mask_debugging() won't restore the I bit if it can
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 9d3588450473..117412bae915 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -226,14 +226,6 @@ static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr)
>  {
>  	unsigned long far = read_sysreg(far_el1);
>  
> -	/*
> -	 * The CPU masked interrupts, and we are leaving them masked during
> -	 * do_debug_exception(). Update PMR as if we had called
> -	 * local_daif_mask().
> -	 */
> -	if (system_uses_irq_prio_masking())
> -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> -
>  	arm64_enter_el1_dbg(regs);
>  	if (!cortex_a76_erratum_1463225_debug_handler(regs))
>  		do_debug_exception(far, esr, regs);
> @@ -398,9 +390,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
>  	/* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */
>  	unsigned long far = read_sysreg(far_el1);
>  
> -	if (system_uses_irq_prio_masking())
> -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> -
>  	enter_from_user_mode();
>  	do_debug_exception(far, esr, regs);
>  	local_daif_restore(DAIF_PROCCTX_NOIRQ);
> @@ -408,9 +397,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
>  
>  static void noinstr el0_svc(struct pt_regs *regs)
>  {
> -	if (system_uses_irq_prio_masking())
> -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> -
>  	enter_from_user_mode();
>  	cortex_a76_erratum_1463225_svc_handler();
>  	do_el0_svc(regs);
> @@ -486,9 +472,6 @@ static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
>  
>  static void noinstr el0_svc_compat(struct pt_regs *regs)
>  {
> -	if (system_uses_irq_prio_masking())
> -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> -
>  	enter_from_user_mode();
>  	cortex_a76_erratum_1463225_svc_handler();
>  	do_el0_svc_compat(regs);
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 6acfc5e6b5e0..941bb52b5e21 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -292,6 +292,8 @@ alternative_else_nop_endif
>  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
>  	mrs_s	x20, SYS_ICC_PMR_EL1
>  	str	x20, [sp, #S_PMR_SAVE]
> +	mov	x20, #GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET
> +	msr_s	SYS_ICC_PMR_EL1, x20

I'm a bit worried about forcing PMR to IRQON at this stage. We could
have been in IRQOFF state and entering the kernel because of a
NMI. Don't we risk losing track of how we made it here? In the current
code, the ORR makes it plain that only the I bit has changed at this
stage.

Is there some other state tracking that make this complexity
irrelevant?

Thanks,

	M.

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


From lkp at intel.com  Wed Apr 28 15:48:29 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 22:48:29 +0800
Subject: [xlnx:xlnx_rebase_v5.4 903/1755]
 include/linux/usb/xhci_pdriver.h:22:6: warning: no previous prototype for
 'dwc3_host_wakeup_capable'
Message-ID: <202104282217.t7ccgY9d-lkp@intel.com>

Hi Michal,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: 6d0468b837bc2b3cce625f59904d137e63637b5d [903/1755] usb: dwc3: Add support for clock disabling during suspend
config: i386-randconfig-r006-20210428 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/Xilinx/linux-xlnx/commit/6d0468b837bc2b3cce625f59904d137e63637b5d
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 6d0468b837bc2b3cce625f59904d137e63637b5d
        # save the attached .config to linux build tree
        make W=1 W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All warnings (new ones prefixed by >>):

   In file included from drivers/usb/host/xhci-plat.c:23:
>> include/linux/usb/xhci_pdriver.h:22:6: warning: no previous prototype for 'dwc3_host_wakeup_capable' [-Wmissing-prototypes]
      22 | void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
         |      ^~~~~~~~~~~~~~~~~~~~~~~~


vim +/dwc3_host_wakeup_capable +22 include/linux/usb/xhci_pdriver.h

    20	
    21	#else
  > 22	void dwc3_host_wakeup_capable(struct device *dev, bool wakeup)
    23	{ ; }
    24	#endif
    25	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 36996 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/a8b064a1/attachment-0001.gz>

From mchehab+huawei at kernel.org  Wed Apr 28 15:51:28 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:28 +0200
Subject: [PATCH v4 07/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>

Calling pm_runtime_get_sync() at driver's removal time is not
needed, as this will resume PM runtime. Also, the PM runtime
code at pm_runtime_disable() already calls it, if it detects
the need.

So, change the logic in order to disable PM runtime earlier.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-core.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9f41c2e7097a..8b943075c503 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1210,18 +1210,19 @@ static int gsc_remove(struct platform_device *pdev)
 	struct gsc_dev *gsc = platform_get_drvdata(pdev);
 	int i;
 
-	pm_runtime_get_sync(&pdev->dev);
-
 	gsc_unregister_m2m_device(gsc);
 	v4l2_device_unregister(&gsc->v4l2_dev);
 
 	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
-	for (i = 0; i < gsc->num_clocks; i++)
-		clk_disable_unprepare(gsc->clock[i]);
 
-	pm_runtime_put_noidle(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 
+	if (!pm_runtime_status_suspended(dev))
+		for (i = 0; i < gsc->num_clocks; i++)
+			clk_disable_unprepare(gsc->clock[i]);
+
+	pm_runtime_set_suspended(dev);
+
 	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
 	return 0;
 }
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:29 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:29 +0200
Subject: [PATCH v4 08/79] media: atmel: properly get pm_runtime
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <3150349be99187c4f9290ac35d6227bb6a83519b.1619621413.git.mchehab+huawei@kernel.org>

There are several issues in the way the atmel driver handles
pm_runtime_get_sync():

- it doesn't check return codes;
- it doesn't properly decrement the usage_count on all places;
- it starts streaming even if pm_runtime_get_sync() fails.
- while it tries to get pm_runtime at the clock enable logic,
  it doesn't check if the operation was suceeded.

Replace all occurrences of it to use the new kAPI:
pm_runtime_resume_and_get(), which ensures that, if the
return code is not negative, the usage_count was incremented.

With that, add additional checks when this is called, in order
to ensure that errors will be properly addressed.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/atmel/atmel-isc-base.c | 27 ++++++++++++++-----
 drivers/media/platform/atmel/atmel-isi.c      | 19 ++++++++++---
 2 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
index fe3ec8d0eaee..02543fe42e9d 100644
--- a/drivers/media/platform/atmel/atmel-isc-base.c
+++ b/drivers/media/platform/atmel/atmel-isc-base.c
@@ -294,9 +294,13 @@ static int isc_wait_clk_stable(struct clk_hw *hw)
 static int isc_clk_prepare(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	return isc_wait_clk_stable(hw);
 }
@@ -353,9 +357,13 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
 {
 	struct isc_clk *isc_clk = to_isc_clk(hw);
 	u32 status;
+	int ret;
 
-	if (isc_clk->id == ISC_ISPCK)
-		pm_runtime_get_sync(isc_clk->dev);
+	if (isc_clk->id == ISC_ISPCK) {
+		ret = pm_runtime_resume_and_get(isc_clk->dev);
+		if (ret < 0)
+			return 0;
+	}
 
 	regmap_read(isc_clk->regmap, ISC_CLKSR, &status);
 
@@ -807,7 +815,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 		goto err_start_stream;
 	}
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		goto err_pm_get;
 
 	ret = isc_configure(isc);
 	if (unlikely(ret))
@@ -838,7 +848,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_configure:
 	pm_runtime_put_sync(isc->dev);
-
+err_pm_get:
 	v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
 
 err_start_stream:
@@ -1809,6 +1819,7 @@ static void isc_awb_work(struct work_struct *w)
 	u32 baysel;
 	unsigned long flags;
 	u32 min, max;
+	int ret;
 
 	/* streaming is not active anymore */
 	if (isc->stop)
@@ -1831,7 +1842,9 @@ static void isc_awb_work(struct work_struct *w)
 	ctrls->hist_id = hist_id;
 	baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
 
-	pm_runtime_get_sync(isc->dev);
+	ret = pm_runtime_resume_and_get(isc->dev);
+	if (ret < 0)
+		return;
 
 	/*
 	 * only update if we have all the required histograms and controls
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index 0514be6153df..6a433926726d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -422,7 +422,9 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
 	struct frame_buffer *buf, *node;
 	int ret;
 
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	/* Enable stream on the sub device */
 	ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
@@ -782,9 +784,10 @@ static int isi_enum_frameintervals(struct file *file, void *fh,
 	return 0;
 }
 
-static void isi_camera_set_bus_param(struct atmel_isi *isi)
+static int isi_camera_set_bus_param(struct atmel_isi *isi)
 {
 	u32 cfg1 = 0;
+	int ret;
 
 	/* set bus param for ISI */
 	if (isi->pdata.hsync_act_low)
@@ -801,12 +804,16 @@ static void isi_camera_set_bus_param(struct atmel_isi *isi)
 	cfg1 |= ISI_CFG1_THMASK_BEATS_16;
 
 	/* Enable PM and peripheral clock before operate isi registers */
-	pm_runtime_get_sync(isi->dev);
+	ret = pm_runtime_resume_and_get(isi->dev);
+	if (ret < 0)
+		return ret;
 
 	isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
 	isi_writel(isi, ISI_CFG1, cfg1);
 
 	pm_runtime_put(isi->dev);
+
+	return 0;
 }
 
 /* -----------------------------------------------------------------------*/
@@ -1085,7 +1092,11 @@ static int isi_graph_notify_complete(struct v4l2_async_notifier *notifier)
 		dev_err(isi->dev, "No supported mediabus format found\n");
 		return ret;
 	}
-	isi_camera_set_bus_param(isi);
+	ret = isi_camera_set_bus_param(isi);
+	if (ret) {
+		dev_err(isi->dev, "Can't wake up device\n");
+		return ret;
+	}
 
 	ret = isi_set_default_fmt(isi);
 	if (ret) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:31 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:31 +0200
Subject: [PATCH v4 10/79] media: mdk-mdp: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <39851c54046fa0d63f34549803df3388361828b7.1619621413.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
as it doesn't make any sense to return 0 if the PM runtime failed
to resume.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index ace4528cdc5e..f14779e7596e 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct mtk_mdp_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
 	if (ret < 0)
-		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
+		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
 			    ctx->id, ret);
 
-	return 0;
+	return ret;
 }
 
 static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx,
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:40 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:40 +0200
Subject: [PATCH v4 19/79] media: sunxi: fix pm_runtime_get_sync() usage count
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <17cf60c9e5190ff83de40284bb858581bb0ec4a6.1619621413.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
index 3f81dd17755c..fbcca59a0517 100644
--- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
+++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
@@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
 		struct device *dev = ctx->dev->dev;
 		int ret;
 
-		ret = pm_runtime_get_sync(dev);
+		ret = pm_runtime_resume_and_get(dev);
 		if (ret < 0) {
 			dev_err(dev, "Failed to enable module\n");
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:38 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:38 +0200
Subject: [PATCH v4 17/79] media: s5p-jpeg: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <83a1f7979382d5d5c44964baae819589c94d80c2.1619621413.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Acked-by: Andrzej Pietrasiewicz <andrzejtp2010 at gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-jpeg/jpeg-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 026111505f5a..c4f19418a460 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2568,7 +2568,7 @@ static int s5p_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct s5p_jpeg_ctx *ctx = vb2_get_drv_priv(q);
 	int ret;
 
-	ret = pm_runtime_get_sync(ctx->jpeg->dev);
+	ret = pm_runtime_resume_and_get(ctx->jpeg->dev);
 
 	return ret > 0 ? 0 : ret;
 }
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:37 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:37 +0200
Subject: [PATCH v4 16/79] media: mtk-vcodec: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <b2f5f6e6287d4b56530dcf51b25b5a1c009381f8.1619621413.git.mchehab+huawei@kernel.org>

The pm_runtime_get_sync() internally increments the
dev->power.usage_count without decrementing it, even on errors.
Replace it by the new pm_runtime_resume_and_get(), introduced by:
commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
in order to properly decrement the usage counter and avoid memory
leaks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index ddee7046ce42..fe096fe61c9d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -92,9 +92,9 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
 {
 	int ret;
 
-	ret = pm_runtime_get_sync(pm->dev);
+	ret = pm_runtime_resume_and_get(pm->dev);
 	if (ret)
-		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
+		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
 }
 
 void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:45 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:45 +0200
Subject: [PATCH v4 24/79] staging: media: cedrus_video: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <cc0761dc51d021a4295cce298834afb9be0211c6.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index b62eb8e84057..9ddd789d0b1f 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq, unsigned int count)
 	}
 
 	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
-		ret = pm_runtime_get_sync(dev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(dev->dev);
+		ret = pm_runtime_resume_and_get(dev->dev);
+		if (ret < 0)
 			goto err_cleanup;
-		}
 
 		if (dev->dec_ops[ctx->current_codec]->start) {
 			ret = dev->dec_ops[ctx->current_codec]->start(ctx);
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:51:43 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:51:43 +0200
Subject: [PATCH v4 22/79] staging: media: imx7-mipi-csis: use
 pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <914f9a1ac35dbb25cee9636b9f8533e743173ee7.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Acked-by: Rui Miguel Silva <rmfrfs at gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/staging/media/imx/imx7-mipi-csis.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c b/drivers/staging/media/imx/imx7-mipi-csis.c
index 025fdc488bd6..1dc680d94a46 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -695,11 +695,10 @@ static int mipi_csis_s_stream(struct v4l2_subdev *mipi_sd, int enable)
 
 		mipi_csis_clear_counters(state);
 
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		ret = v4l2_subdev_call(state->src_sd, core, s_power, 1);
 		if (ret < 0 && ret != -ENOIOCTLCMD)
 			goto done;
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:18 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:18 +0200
Subject: [PATCH v4 57/79] media: rockchip/rga: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <cf0f0cb266c8b552f03583590a3b02a56f751c79.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
 drivers/media/platform/rockchip/rga/rga.c     | 4 +++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
index bf9a75b75083..81508ed5abf3 100644
--- a/drivers/media/platform/rockchip/rga/rga-buf.c
+++ b/drivers/media/platform/rockchip/rga/rga-buf.c
@@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct rockchip_rga *rga = ctx->rga;
 	int ret;
 
-	ret = pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(rga->dev);
 		rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
 		return ret;
 	}
diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
index 9d122429706e..bf3fd71ec3af 100644
--- a/drivers/media/platform/rockchip/rga/rga.c
+++ b/drivers/media/platform/rockchip/rga/rga.c
@@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
 		goto unreg_video_dev;
 	}
 
-	pm_runtime_get_sync(rga->dev);
+	ret = pm_runtime_resume_and_get(rga->dev);
+	if (ret < 0)
+		goto unreg_video_dev;
 
 	rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
 	rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:33 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:33 +0200
Subject: [PATCH v4 72/79] media: s5p-mfc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <030ac0a2930f8d2c9d3237de5dff71f3913c3b45.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 62d2320a7218..88b7d33c9197 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -78,11 +78,9 @@ int s5p_mfc_power_on(void)
 {
 	int i, ret = 0;
 
-	ret = pm_runtime_get_sync(pm->device);
-	if (ret < 0) {
-		pm_runtime_put_noidle(pm->device);
+	ret = pm_runtime_resume_and_get(pm->device);
+	if (ret < 0)
 		return ret;
-	}
 
 	/* clock control */
 	for (i = 0; i < pm->num_clocks; i++) {
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:23 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:23 +0200
Subject: [PATCH v4 62/79] media: exynos4-is: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <31eadd61972541bf1e27706f9ff7be66a21e23e6.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
 drivers/media/platform/exynos4-is/fimc-is.c        | 4 ++--
 drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
 drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
 drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
 drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
 drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
 drivers/media/platform/exynos4-is/mipi-csis.c      | 8 +++-----
 8 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index 13c838d3f947..0da36443173c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
 		goto unlock;
 
 	set_bit(ST_CAPT_BUSY, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
-	if (ret < 0) {
-		pm_runtime_put_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
+	if (ret < 0)
 		goto unlock;
-	}
 
 	ret = v4l2_fh_open(file);
 	if (ret) {
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
index 972d9601d236..1b24f5bfc4af 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -828,9 +828,9 @@ static int fimc_is_probe(struct platform_device *pdev)
 			goto err_irq;
 	}
 
-	ret = pm_runtime_get_sync(dev);
+	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_irq;
 
 	vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
index 612b9872afc8..8d9dc597deaa 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
@@ -275,7 +275,7 @@ static int isp_video_open(struct file *file)
 	if (ret < 0)
 		goto unlock;
 
-	ret = pm_runtime_get_sync(&isp->pdev->dev);
+	ret = pm_runtime_resume_and_get(&isp->pdev->dev);
 	if (ret < 0)
 		goto rel_fh;
 
@@ -293,7 +293,6 @@ static int isp_video_open(struct file *file)
 	if (!ret)
 		goto unlock;
 rel_fh:
-	pm_runtime_put_noidle(&isp->pdev->dev);
 	v4l2_fh_release(file);
 unlock:
 	mutex_unlock(&isp->video_lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
index a77c49b18511..74b49d30901e 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -304,11 +304,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
 	pr_debug("on: %d\n", on);
 
 	if (on) {
-		ret = pm_runtime_get_sync(&is->pdev->dev);
-		if (ret < 0) {
-			pm_runtime_put(&is->pdev->dev);
+		ret = pm_runtime_resume_and_get(&is->pdev->dev);
+		if (ret < 0)
 			return ret;
-		}
+
 		set_bit(IS_ST_PWR_ON, &is->state);
 
 		ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index fe20af3a7178..4d8b18078ff3 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -469,9 +469,9 @@ static int fimc_lite_open(struct file *file)
 	}
 
 	set_bit(ST_FLITE_IN_USE, &fimc->state);
-	ret = pm_runtime_get_sync(&fimc->pdev->dev);
+	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
 	if (ret < 0)
-		goto err_pm;
+		goto err_in_use;
 
 	ret = v4l2_fh_open(file);
 	if (ret < 0)
@@ -499,6 +499,7 @@ static int fimc_lite_open(struct file *file)
 	v4l2_fh_release(file);
 err_pm:
 	pm_runtime_put_sync(&fimc->pdev->dev);
+err_in_use:
 	clear_bit(ST_FLITE_IN_USE, &fimc->state);
 unlock:
 	mutex_unlock(&fimc->lock);
diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
index c9704a147e5c..7c1eb05c508f 100644
--- a/drivers/media/platform/exynos4-is/fimc-m2m.c
+++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
@@ -75,7 +75,7 @@ static int start_streaming(struct vb2_queue *q, unsigned int count)
 	struct fimc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->fimc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->fimc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index 13d192ba4aa6..9346d44a06c2 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -512,11 +512,9 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
 	if (!fmd->pmf)
 		return -ENXIO;
 
-	ret = pm_runtime_get_sync(fmd->pmf);
-	if (ret < 0) {
-		pm_runtime_put(fmd->pmf);
+	ret = pm_runtime_resume_and_get(fmd->pmf);
+	if (ret < 0)
 		return ret;
-	}
 
 	fmd->num_sensors = 0;
 
@@ -1291,7 +1289,7 @@ static int cam_clk_prepare(struct clk_hw *hw)
 	if (camclk->fmd->pmf == NULL)
 		return -ENODEV;
 
-	ret = pm_runtime_get_sync(camclk->fmd->pmf);
+	ret = pm_runtime_resume_and_get(camclk->fmd->pmf);
 	return ret < 0 ? ret : 0;
 }
 
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 1aac167abb17..2a6afb78a049 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
 	struct device *dev = &state->pdev->dev;
 
 	if (on)
-		return pm_runtime_get_sync(dev);
+		return pm_runtime_resume_and_get(dev);
 
 	return pm_runtime_put_sync(dev);
 }
@@ -509,11 +509,9 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
 
 	if (enable) {
 		s5pcsis_clear_counters(state);
-		ret = pm_runtime_get_sync(&state->pdev->dev);
-		if (ret && ret != 1) {
-			pm_runtime_put_noidle(&state->pdev->dev);
+		ret = pm_runtime_resume_and_get(&state->pdev->dev);
+		if (ret && ret != 1)
 			return ret;
-		}
 	}
 
 	mutex_lock(&state->lock);
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:35 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:35 +0200
Subject: [PATCH v4 74/79] media: sunxi: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <3138e98e18858b3133b9a6e04890c29c731903f3.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
index 4785faddf630..54b909987caa 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_v4l2.c
@@ -206,9 +206,9 @@ static int sun4i_csi_open(struct file *file)
 	if (ret)
 		return ret;
 
-	ret = pm_runtime_get_sync(csi->dev);
+	ret = pm_runtime_resume_and_get(csi->dev);
 	if (ret < 0)
-		goto err_pm_put;
+		goto err_unlock;
 
 	ret = v4l2_pipeline_pm_get(&csi->vdev.entity);
 	if (ret)
@@ -227,6 +227,8 @@ static int sun4i_csi_open(struct file *file)
 
 err_pm_put:
 	pm_runtime_put(csi->dev);
+
+err_unlock:
 	mutex_unlock(&csi->lock);
 
 	return ret;
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:31 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:31 +0200
Subject: [PATCH v4 70/79] media: rkisp1: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <17d3cf0b3b137011353079109a4918592c4f57fd.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 5f6c9d1623e4..3730376897d9 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -1003,9 +1003,8 @@ rkisp1_vb2_start_streaming(struct vb2_queue *queue, unsigned int count)
 	if (ret)
 		goto err_pipeline_stop;
 
-	ret = pm_runtime_get_sync(cap->rkisp1->dev);
+	ret = pm_runtime_resume_and_get(cap->rkisp1->dev);
 	if (ret < 0) {
-		pm_runtime_put_noidle(cap->rkisp1->dev);
 		dev_err(cap->rkisp1->dev, "power up failed %d\n", ret);
 		goto err_destroy_dummy;
 	}
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:34 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:34 +0200
Subject: [PATCH v4 73/79] media: stm32: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <cd918677e36e89196670cacd7027569e741f7d98.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/stm32/stm32-dcmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index bbcc2254fa2e..5f4e1db8cfcd 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -723,11 +723,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 	u32 val = 0;
 	int ret;
 
-	ret = pm_runtime_get_sync(dcmi->dev);
+	ret = pm_runtime_resume_and_get(dcmi->dev);
 	if (ret < 0) {
 		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
 			__func__, ret);
-		goto err_pm_put;
+		goto err_unlock;
 	}
 
 	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
@@ -848,6 +848,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
 
 err_pm_put:
 	pm_runtime_put(dcmi->dev);
+err_unlock:
 	spin_lock_irq(&dcmi->irqlock);
 	/*
 	 * Return all buffers to vb2 in QUEUED state.
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:24 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:24 +0200
Subject: [PATCH v4 63/79] media: exynos-gsc: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <31bdadf2f59e86c6a315ec390b44c6c681af6647.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 27a3c92c73bc..09551e96ac15 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -58,7 +58,7 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
 	struct gsc_ctx *ctx = q->drv_priv;
 	int ret;
 
-	ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
+	ret = pm_runtime_resume_and_get(&ctx->gsc_dev->pdev->dev);
 	return ret > 0 ? 0 : ret;
 }
 
-- 
2.30.2



From mchehab+huawei at kernel.org  Wed Apr 28 15:52:25 2021
From: mchehab+huawei at kernel.org (Mauro Carvalho Chehab)
Date: Wed, 28 Apr 2021 16:52:25 +0200
Subject: [PATCH v4 64/79] media: mtk-jpeg: use pm_runtime_resume_and_get()
In-Reply-To: <cover.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <71dd5d55eba4fc353900354acffd6861be8a8abb.1619621413.git.mchehab+huawei@kernel.org>

Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
added pm_runtime_resume_and_get() in order to automatically handle
dev->power.usage_count decrement on errors.

Use the new API, in order to cleanup the error check logic.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 88a23bce569d..a89c7b206eef 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -920,7 +920,7 @@ static void mtk_jpeg_enc_device_run(void *priv)
 	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
 	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto enc_end;
 
@@ -973,7 +973,7 @@ static void mtk_jpeg_dec_device_run(void *priv)
 		return;
 	}
 
-	ret = pm_runtime_get_sync(jpeg->dev);
+	ret = pm_runtime_resume_and_get(jpeg->dev);
 	if (ret < 0)
 		goto dec_end;
 
-- 
2.30.2



From lkp at intel.com  Wed Apr 28 15:54:12 2021
From: lkp at intel.com (kernel test robot)
Date: Wed, 28 Apr 2021 22:54:12 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1277/1755] drivers/gpio/gpio-xilinx.c:68:25:
 error: field has incomplete type 'struct of_mm_gpio_chip'
Message-ID: <202104282258.DydARn5f-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: af0c19b6f15388c554317280433100fd9f3d7d0a [1277/1755] gpio: xilinx: Use xilinx tested gpio driver
config: x86_64-randconfig-a004-20210428 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 87fc97169e7901dfe56ca0da0d92da0c02d2ef48)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/af0c19b6f15388c554317280433100fd9f3d7d0a
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout af0c19b6f15388c554317280433100fd9f3d7d0a
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All error/warnings (new ones prefixed by >>):

>> drivers/gpio/gpio-xilinx.c:68:25: error: field has incomplete type 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                                  ^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
>> drivers/gpio/gpio-xilinx.c:94:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
>> drivers/gpio/gpio-xilinx.c:94:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
>> drivers/gpio/gpio-xilinx.c:98:28: error: incomplete definition of type 'struct of_mm_gpio_chip'
           void __iomem *regs = mm_gc->regs + chip->offset;
                                ~~~~~^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:115:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
   drivers/gpio/gpio-xilinx.c:115:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:118:28: error: incomplete definition of type 'struct of_mm_gpio_chip'
           void __iomem *regs = mm_gc->regs;
                                ~~~~~^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:147:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
   drivers/gpio/gpio-xilinx.c:147:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:150:28: error: incomplete definition of type 'struct of_mm_gpio_chip'
           void __iomem *regs = mm_gc->regs;
                                ~~~~~^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:187:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
   drivers/gpio/gpio-xilinx.c:187:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:190:28: error: incomplete definition of type 'struct of_mm_gpio_chip'
           void __iomem *regs = mm_gc->regs;
                                ~~~~~^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:218:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
   drivers/gpio/gpio-xilinx.c:218:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
   drivers/gpio/gpio-xilinx.c:221:28: error: incomplete definition of type 'struct of_mm_gpio_chip'
           void __iomem *regs = mm_gc->regs;
                                ~~~~~^
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:251:41: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   chip->gpio_state = xgpio_readreg(mm_gc->regs +
                                                    ~~~~~^
   drivers/gpio/gpio-xilinx.c:49:45: note: expanded from macro 'xgpio_readreg'
   # define xgpio_readreg(offset)          __raw_readl(offset)
                                                       ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:253:39: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   chip->gpio_dir = xgpio_readreg(mm_gc->regs + XGPIO_TRI_OFFSET);
                                                  ~~~~~^
   drivers/gpio/gpio-xilinx.c:49:45: note: expanded from macro 'xgpio_readreg'
   # define xgpio_readreg(offset)          __raw_readl(offset)
                                                       ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:255:23: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   xgpio_writereg(mm_gc->regs + chip->offset + XGPIO_DATA_OFFSET,
                                  ~~~~~^
   drivers/gpio/gpio-xilinx.c:50:56: note: expanded from macro 'xgpio_writereg'
   # define xgpio_writereg(offset, val)    __raw_writel(val, offset)
                                                             ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:257:23: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   xgpio_writereg(mm_gc->regs + chip->offset + XGPIO_TRI_OFFSET,
                                  ~~~~~^
   drivers/gpio/gpio-xilinx.c:50:56: note: expanded from macro 'xgpio_writereg'
   # define xgpio_writereg(offset, val)    __raw_writel(val, offset)
                                                             ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:274:34: error: implicit declaration of function 'to_of_mm_gpio_chip' [-Werror,-Wimplicit-function-declaration]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                           ^
   drivers/gpio/gpio-xilinx.c:274:26: warning: incompatible integer to pointer conversion initializing 'struct of_mm_gpio_chip *' with an expression of type 'int' [-Wint-conversion]
           struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
                                   ^       ~~~~~~~~~~~~~~~~~~~~~~
>> drivers/gpio/gpio-xilinx.c:277:10: error: no member named 'of_gpio_n_cells' in 'struct gpio_chip'
           if (gc->of_gpio_n_cells == 3 && flags)
               ~~  ^
   drivers/gpio/gpio-xilinx.c:307:29: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   temp = xgpio_readreg(mm_gc->regs + XGPIO_IPIER_OFFSET);
                                        ~~~~~^
   drivers/gpio/gpio-xilinx.c:49:45: note: expanded from macro 'xgpio_readreg'
   # define xgpio_readreg(offset)          __raw_readl(offset)
                                                       ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   drivers/gpio/gpio-xilinx.c:309:23: error: incomplete definition of type 'struct of_mm_gpio_chip'
                   xgpio_writereg(mm_gc->regs + XGPIO_IPIER_OFFSET, temp);
                                  ~~~~~^
   drivers/gpio/gpio-xilinx.c:50:56: note: expanded from macro 'xgpio_writereg'
   # define xgpio_writereg(offset, val)    __raw_writel(val, offset)
                                                             ^~~~~~
   drivers/gpio/gpio-xilinx.c:68:9: note: forward declaration of 'struct of_mm_gpio_chip'
           struct of_mm_gpio_chip mmchip;
                  ^
   fatal error: too many errors emitted, stopping now [-ferror-limit=]
   6 warnings and 20 errors generated.


vim +68 drivers/gpio/gpio-xilinx.c

    52	
    53	/**
    54	 * struct xgpio_instance - Stores information about GPIO device
    55	 * @mmchip: OF GPIO chip for memory mapped banks
    56	 * @mmchip_dual: Pointer to the OF dual gpio chip
    57	 * @gpio_state: GPIO state shadow register
    58	 * @gpio_dir: GPIO direction shadow register
    59	 * @offset: GPIO channel offset
    60	 * @irq_base: GPIO channel irq base address
    61	 * @irq_enable: GPIO irq enable/disable bitfield
    62	 * @no_init: No intitialisation at probe
    63	 * @gpio_lock: Lock used for synchronization
    64	 * @irq_domain: irq_domain of the controller
    65	 * @clk: clock resource for this driver
    66	 */
    67	struct xgpio_instance {
  > 68		struct of_mm_gpio_chip mmchip;
    69		struct of_mm_gpio_chip *mmchip_dual;
    70		u32 gpio_state;
    71		u32 gpio_dir;
    72		u32 offset;
    73		int irq_base;
    74		u32 irq_enable;
    75		bool no_init;
    76		spinlock_t gpio_lock;
    77		struct irq_domain *irq_domain;
    78		struct clk *clk;
    79	};
    80	
    81	/**
    82	 * xgpio_get - Read the specified signal of the GPIO device.
    83	 * @gc:     Pointer to gpio_chip device structure.
    84	 * @gpio:   GPIO signal number.
    85	 *
    86	 * This function reads the specified signal of the GPIO device.
    87	 *
    88	 * Return:
    89	 * 0 if direction of GPIO signals is set as input otherwise it
    90	 * returns negative error value.
    91	 */
    92	static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
    93	{
  > 94		struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
    95		struct xgpio_instance *chip =
    96		    container_of(mm_gc, struct xgpio_instance, mmchip);
    97	
  > 98		void __iomem *regs = mm_gc->regs + chip->offset;
    99	
   100		return !!(xgpio_readreg(regs + XGPIO_DATA_OFFSET) & BIT(gpio));
   101	}
   102	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29541 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210428/668ef798/attachment-0001.gz>

From maz at kernel.org  Wed Apr 28 16:06:33 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 28 Apr 2021 16:06:33 +0100
Subject: [PATCH v3 09/10] arm64: dts: rockchip: add core dtsi for RK3568
 SoC
In-Reply-To: <20210428135002.22528-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
 <20210428135002.22528-1-cl@rock-chips.com>
Message-ID: <87h7jqo3d2.wl-maz@kernel.org>

On Wed, 28 Apr 2021 14:50:02 +0100,
<cl at rock-chips.com> wrote:
> 
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipment. This patch
> add basic core dtsi file for it.
> 
> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> enalbe a special high-performance PLL when high frequency is required. The
> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> 
>     cpu0: cpu at 0 {
>         device_type = "cpu";
>         compatible = "arm,cortex-a55";
>         reg = <0x0 0x0>;
>         clocks = <&scmi_clk 0>;
>     };
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  779 +++++
>  2 files changed, 3890 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi

[...]

> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */

If this SoC has 4 CPUs, that's 4 redistributors. Given that GIC600
doesn't implement VLPIs, that's 128kB per redistributors. Why is GICR
large enough for 6 CPUs here? Is that copy-pasted from another SoC?

> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		mbi-alias = <0x0 0xfd400000>;
> +		mbi-ranges = <296 24>;
> +		msi-controller;
> +	};

Glad to see that you found some spare SPIs to get MSIs going

However, the whole point of mbi-alias (aka GICA in GIC600) is to be
different from GICD and provide some isolation via an IOMMU.  If I
trust the TRM, if should be at 0xfd10000 in your implementation.

Thanks,

	M.

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


From mark.rutland at arm.com  Wed Apr 28 16:19:11 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 28 Apr 2021 16:19:11 +0100
Subject: [PATCH] arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
In-Reply-To: <87im46o4j6.wl-maz@kernel.org>
References: <20210428111555.50880-1-mark.rutland@arm.com>
 <87im46o4j6.wl-maz@kernel.org>
Message-ID: <20210428151439.GA1343@C02TD0UTHF1T.local>

On Wed, Apr 28, 2021 at 03:41:17PM +0100, Marc Zyngier wrote:
> Hi Mark,
> 
> On Wed, 28 Apr 2021 12:15:55 +0100,
> Mark Rutland <mark.rutland at arm.com> wrote:
> > 
> > Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"
> > on the command line hits a warning during kernel entry, due to the way
> > we manipulate the PMR.
> > 
> > Early in the entry sequence, we call lockdep_hardirqs_off() to inform
> > lockdep that interrupts have been masked (as the HW sets DAIF wqhen
> > entering an exception). Architecturally PMR_EL1 is not affected by
> > exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in
> > the exception entry sequence, so early in exception entry the PMR can
> > indicate that interrupts are unmasked even though they are masked by
> > DAIF.
> > 
> > If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that
> > interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the
> > exception entry paths, and hence lockdep_hardirqs_off() will WARN() that
> > something is amiss.
> > 
> > We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during
> > exception entry so that kernel code sees a consistent environment. We
> > must also update local_daif_inherit() to undo this, as currently only
> > touches DAIF. For other paths, local_daif_restore() will update both
> > DAIF and the PMR. With this done, we can remove the existing special
> > cases which set this later in the entry code.
> > 
> > We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with
> > local_daif_save(), as this will warn if it ever encounters
> > (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This
> > matches the gic_prio_kentry_setup that we have to retain for
> > ret_to_user.
> > 
> > The original splat from Zenghui's report was:
> > 
> > | DEBUG_LOCKS_WARN_ON(!irqs_disabled())
> > | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8
> > | Modules linked in:
> > | CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+ #463
> > | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> > | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
> > | pc : lockdep_hardirqs_off+0xd4/0xe8
> > | lr : lockdep_hardirqs_off+0xd4/0xe8
> > | sp : ffff80002a39bad0
> > | pmr_save: 000000e0
> > | x29: ffff80002a39bad0 x28: ffff0000de214bc0
> > | x27: ffff0000de1c0400 x26: 000000000049b328
> > | x25: 0000000000406f30 x24: ffff0000de1c00a0
> > | x23: 0000000020400005 x22: ffff8000105f747c
> > | x21: 0000000096000044 x20: 0000000000498ef9
> > | x19: ffff80002a39bc88 x18: ffffffffffffffff
> > | x17: 0000000000000000 x16: ffff800011c61eb0
> > | x15: ffff800011700a88 x14: 0720072007200720
> > | x13: 0720072007200720 x12: 0720072007200720
> > | x11: 0720072007200720 x10: 0720072007200720
> > | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
> > | x7 : ffff8000119f0800 x6 : c0000000ffff7fff
> > | x5 : ffff8000119f07a8 x4 : 0000000000000001
> > | x3 : 9bcdab23f2432800 x2 : ffff800011730538
> > | x1 : 9bcdab23f2432800 x0 : 0000000000000000
> > | Call trace:
> > |  lockdep_hardirqs_off+0xd4/0xe8
> > |  enter_from_kernel_mode.isra.5+0x7c/0xa8
> > |  el1_abort+0x24/0x100
> > |  el1_sync_handler+0x80/0xd0
> > |  el1_sync+0x6c/0x100
> > |  __arch_clear_user+0xc/0x90
> > |  load_elf_binary+0x9fc/0x1450
> > |  bprm_execve+0x404/0x880
> > |  kernel_execve+0x180/0x188
> > |  call_usermodehelper_exec_async+0xdc/0x158
> > |  ret_from_fork+0x10/0x18
> > 
> > Fixes: 23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
> > Fixes: 7cd1ea1010acbede ("arm64: entry: fix non-NMI kernel<->kernel transitions")
> > Fixes: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
> > Fixes: 2a9b3e6ac69a8bf1 ("arm64: entry: fix EL1 debug transitions")
> > Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3 at huawei.com
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > Reported-by: Zenghui Yu <yuzenghui at huawei.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Marc Zyngier <maz at kernel.org>
> > Cc: Will Deacon <will at kernel.org>
> > ---
> >  arch/arm64/include/asm/daifflags.h |  3 +++
> >  arch/arm64/kernel/entry-common.c   | 17 -----------------
> >  arch/arm64/kernel/entry.S          | 15 ++-------------
> >  3 files changed, 5 insertions(+), 30 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
> > index 1c26d7baa67f..cfdde3a56805 100644
> > --- a/arch/arm64/include/asm/daifflags.h
> > +++ b/arch/arm64/include/asm/daifflags.h
> > @@ -131,6 +131,9 @@ static inline void local_daif_inherit(struct pt_regs *regs)
> >  	if (interrupts_enabled(regs))
> >  		trace_hardirqs_on();
> >  
> > +	if (system_uses_irq_prio_masking())
> > +		gic_write_pmr(regs->pmr_save);
> > +
> >  	/*
> >  	 * We can't use local_daif_restore(regs->pstate) here as
> >  	 * system_has_prio_mask_debugging() won't restore the I bit if it can
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index 9d3588450473..117412bae915 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -226,14 +226,6 @@ static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr)
> >  {
> >  	unsigned long far = read_sysreg(far_el1);
> >  
> > -	/*
> > -	 * The CPU masked interrupts, and we are leaving them masked during
> > -	 * do_debug_exception(). Update PMR as if we had called
> > -	 * local_daif_mask().
> > -	 */
> > -	if (system_uses_irq_prio_masking())
> > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > -
> >  	arm64_enter_el1_dbg(regs);
> >  	if (!cortex_a76_erratum_1463225_debug_handler(regs))
> >  		do_debug_exception(far, esr, regs);
> > @@ -398,9 +390,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
> >  	/* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */
> >  	unsigned long far = read_sysreg(far_el1);
> >  
> > -	if (system_uses_irq_prio_masking())
> > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > -
> >  	enter_from_user_mode();
> >  	do_debug_exception(far, esr, regs);
> >  	local_daif_restore(DAIF_PROCCTX_NOIRQ);
> > @@ -408,9 +397,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
> >  
> >  static void noinstr el0_svc(struct pt_regs *regs)
> >  {
> > -	if (system_uses_irq_prio_masking())
> > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > -
> >  	enter_from_user_mode();
> >  	cortex_a76_erratum_1463225_svc_handler();
> >  	do_el0_svc(regs);
> > @@ -486,9 +472,6 @@ static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
> >  
> >  static void noinstr el0_svc_compat(struct pt_regs *regs)
> >  {
> > -	if (system_uses_irq_prio_masking())
> > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > -
> >  	enter_from_user_mode();
> >  	cortex_a76_erratum_1463225_svc_handler();
> >  	do_el0_svc_compat(regs);
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 6acfc5e6b5e0..941bb52b5e21 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -292,6 +292,8 @@ alternative_else_nop_endif
> >  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> >  	mrs_s	x20, SYS_ICC_PMR_EL1
> >  	str	x20, [sp, #S_PMR_SAVE]
> > +	mov	x20, #GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET
> > +	msr_s	SYS_ICC_PMR_EL1, x20
> 
> I'm a bit worried about forcing PMR to IRQON at this stage. We could
> have been in IRQOFF state and entering the kernel because of a
> NMI. Don't we risk losing track of how we made it here?

I also worried about this, but after digging for a while I convinced
myself there wasn't a problem, as:

* This is what local_daif_mask() does today. It sets the PMR to
 GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET regardless of its original state.

* For checking how we got here, we use either:
 - regs::pmr_save, which is sampled (immediately) before we alter HW PMR
   in the asm above.
 - DAIF, which is unaffected by this.

* This is transparent to local_irq_save() .. local_irq_restore(), as
  that blindly saves/restores the PMR.

... and from digging through the history, I don't think this was
necessary even when it was introduced in commit:

  bd82d4bd21880b7c ("arm64: Fix incorrect irqflag restore for priority masking")

... for which (AFAICT) all of the above held true too.

Also, as mentioned above, local_daif_save() explicitly WARN()s if it
ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and I'd like to
ensure by construction that this case is never exposed to C code such as
the entry-common logic.

FWIW, I also don't *like* this, and still intend to rework local_irq_*()
and local_daif_*() to remove the pseudo-DAIF and PSR_I_SET logic, but
that still needs some preparatory work, and this is at least
self-consistent today.

> In the current code, the ORR makes it plain that only the I bit has
> changed at this stage.

I agree it makes that clear, however, given that would be inconsistent
with how local_daif_mask() programs the PMR (and given it'll WARN()) if
it's ever used with (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), I don't
think we can do that for all the entry cases (and would strongly prefer
to remove the existing inconsistency).

> Is there some other state tracking that make this complexity
> irrelevant?

Hopefully I've covered that above?

Thanks,
Mark.


From s.nawrocki at samsung.com  Wed Apr 28 16:25:51 2021
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 28 Apr 2021 17:25:51 +0200
Subject: [PATCH v4 07/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <CGME20210428145257eucas1p2152894daee2534dd26ced8df46456d72@eucas1p2.samsung.com>
 <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <138de070-a06c-654e-4912-d41f0cd658c2@samsung.com>

On 28.04.2021 16:51, Mauro Carvalho Chehab wrote:
> Calling pm_runtime_get_sync() at driver's removal time is not
> needed, as this will resume PM runtime. Also, the PM runtime
> code at pm_runtime_disable() already calls it, if it detects
> the need.
> 
> So, change the logic in order to disable PM runtime earlier.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Thank you for correcting that.

> ---
>  drivers/media/platform/exynos-gsc/gsc-core.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 9f41c2e7097a..8b943075c503 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1210,18 +1210,19 @@ static int gsc_remove(struct platform_device *pdev)
>  	struct gsc_dev *gsc = platform_get_drvdata(pdev);
>  	int i;
>  
> -	pm_runtime_get_sync(&pdev->dev);
> -
>  	gsc_unregister_m2m_device(gsc);
>  	v4l2_device_unregister(&gsc->v4l2_dev);
>  
>  	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> -	for (i = 0; i < gsc->num_clocks; i++)
> -		clk_disable_unprepare(gsc->clock[i]);
>  
> -	pm_runtime_put_noidle(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
> +	if (!pm_runtime_status_suspended(dev)) {

It should be &pdev->dev here rather than dev...

> +		for (i = 0; i < gsc->num_clocks; i++)
> +			clk_disable_unprepare(gsc->clock[i]);
> +	}
> +	pm_runtime_set_suspended(dev);

and here s/dev/&pdev->dev.

With above issues fixed,
Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>

>  	dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
>  	return 0;
>  }
 

Thanks,
Sylwester


From eric.auger at redhat.com  Wed Apr 28 16:26:26 2021
From: eric.auger at redhat.com (Auger Eric)
Date: Wed, 28 Apr 2021 17:26:26 +0200
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into
 KVM and TCG variants
In-Reply-To: <87k0omo4rr.wl-maz@kernel.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org> <87fszasjdg.fsf@linaro.org>
 <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com> <87k0omo4rr.wl-maz@kernel.org>
Message-ID: <5c446e6e-fb21-3a47-587b-6ad5e6baf096@redhat.com>

Hi,

On 4/28/21 4:36 PM, Marc Zyngier wrote:
> On Wed, 28 Apr 2021 15:00:15 +0100,
> Alexandru Elisei <alexandru.elisei at arm.com> wrote:
>>
>> I interpret that as that an INVALL guarantees that a change is
>> visible, but it the change can become visible even without the
>> INVALL.
> 
> Yes. Expecting the LPI to be delivered or not in the absence of an
> invalidate when its configuration has been altered is wrong. The
> architecture doesn't guarantee anything of the sort.
> 
>> The test relies on the fact that changes to the LPI tables are not
>> visible *under KVM* until the INVALL command, but that's not
>> necessarily the case on real hardware. To match the spec, I think
>> the test "dev2/eventid=20 still does not trigger any LPI" should be
>> removed and the stats reset should take place before the
>> configuration for LPI 8195 is set to the default.

Yes I do agree with Alexandru and Marc after another reading of the
spec. I initially thought the INVALL was the gate keeper for the new
config but that sounds wrong. This test shall be removed then.

Eric
> 
> If that's what the test expects (I haven't tried to investigate), it
> should be dropped completely, rather than trying to sidestep it for
> TCG.
> 
> Thanks,
> 
> 	M.
> 



From mark.rutland at arm.com  Wed Apr 28 16:29:39 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 28 Apr 2021 16:29:39 +0100
Subject: [PATCH] arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
In-Reply-To: <20210428151439.GA1343@C02TD0UTHF1T.local>
References: <20210428111555.50880-1-mark.rutland@arm.com>
 <87im46o4j6.wl-maz@kernel.org>
 <20210428151439.GA1343@C02TD0UTHF1T.local>
Message-ID: <20210428152939.GB1343@C02TD0UTHF1T.local>

On Wed, Apr 28, 2021 at 04:19:11PM +0100, Mark Rutland wrote:
> On Wed, Apr 28, 2021 at 03:41:17PM +0100, Marc Zyngier wrote:
> > Hi Mark,
> > 
> > On Wed, 28 Apr 2021 12:15:55 +0100,
> > Mark Rutland <mark.rutland at arm.com> wrote:
> > > 
> > > Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1"
> > > on the command line hits a warning during kernel entry, due to the way
> > > we manipulate the PMR.
> > > 
> > > Early in the entry sequence, we call lockdep_hardirqs_off() to inform
> > > lockdep that interrupts have been masked (as the HW sets DAIF wqhen
> > > entering an exception). Architecturally PMR_EL1 is not affected by
> > > exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in
> > > the exception entry sequence, so early in exception entry the PMR can
> > > indicate that interrupts are unmasked even though they are masked by
> > > DAIF.
> > > 
> > > If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that
> > > interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the
> > > exception entry paths, and hence lockdep_hardirqs_off() will WARN() that
> > > something is amiss.
> > > 
> > > We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during
> > > exception entry so that kernel code sees a consistent environment. We
> > > must also update local_daif_inherit() to undo this, as currently only
> > > touches DAIF. For other paths, local_daif_restore() will update both
> > > DAIF and the PMR. With this done, we can remove the existing special
> > > cases which set this later in the entry code.
> > > 
> > > We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with
> > > local_daif_save(), as this will warn if it ever encounters
> > > (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This
> > > matches the gic_prio_kentry_setup that we have to retain for
> > > ret_to_user.
> > > 
> > > The original splat from Zenghui's report was:
> > > 
> > > | DEBUG_LOCKS_WARN_ON(!irqs_disabled())
> > > | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8
> > > | Modules linked in:
> > > | CPU: 3 PID: 125 Comm: modprobe Tainted: G        W         5.12.0-rc8+ #463
> > > | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> > > | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--)
> > > | pc : lockdep_hardirqs_off+0xd4/0xe8
> > > | lr : lockdep_hardirqs_off+0xd4/0xe8
> > > | sp : ffff80002a39bad0
> > > | pmr_save: 000000e0
> > > | x29: ffff80002a39bad0 x28: ffff0000de214bc0
> > > | x27: ffff0000de1c0400 x26: 000000000049b328
> > > | x25: 0000000000406f30 x24: ffff0000de1c00a0
> > > | x23: 0000000020400005 x22: ffff8000105f747c
> > > | x21: 0000000096000044 x20: 0000000000498ef9
> > > | x19: ffff80002a39bc88 x18: ffffffffffffffff
> > > | x17: 0000000000000000 x16: ffff800011c61eb0
> > > | x15: ffff800011700a88 x14: 0720072007200720
> > > | x13: 0720072007200720 x12: 0720072007200720
> > > | x11: 0720072007200720 x10: 0720072007200720
> > > | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0
> > > | x7 : ffff8000119f0800 x6 : c0000000ffff7fff
> > > | x5 : ffff8000119f07a8 x4 : 0000000000000001
> > > | x3 : 9bcdab23f2432800 x2 : ffff800011730538
> > > | x1 : 9bcdab23f2432800 x0 : 0000000000000000
> > > | Call trace:
> > > |  lockdep_hardirqs_off+0xd4/0xe8
> > > |  enter_from_kernel_mode.isra.5+0x7c/0xa8
> > > |  el1_abort+0x24/0x100
> > > |  el1_sync_handler+0x80/0xd0
> > > |  el1_sync+0x6c/0x100
> > > |  __arch_clear_user+0xc/0x90
> > > |  load_elf_binary+0x9fc/0x1450
> > > |  bprm_execve+0x404/0x880
> > > |  kernel_execve+0x180/0x188
> > > |  call_usermodehelper_exec_async+0xdc/0x158
> > > |  ret_from_fork+0x10/0x18
> > > 
> > > Fixes: 23529049c6842382 ("arm64: entry: fix non-NMI user<->kernel transitions")
> > > Fixes: 7cd1ea1010acbede ("arm64: entry: fix non-NMI kernel<->kernel transitions")
> > > Fixes: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions")
> > > Fixes: 2a9b3e6ac69a8bf1 ("arm64: entry: fix EL1 debug transitions")
> > > Link: https://lore.kernel.org/r/f4012761-026f-4e51-3a0c-7524e434e8b3 at huawei.com
> > > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > > Reported-by: Zenghui Yu <yuzenghui at huawei.com>
> > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > Cc: Marc Zyngier <maz at kernel.org>
> > > Cc: Will Deacon <will at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/daifflags.h |  3 +++
> > >  arch/arm64/kernel/entry-common.c   | 17 -----------------
> > >  arch/arm64/kernel/entry.S          | 15 ++-------------
> > >  3 files changed, 5 insertions(+), 30 deletions(-)
> > > 
> > > diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
> > > index 1c26d7baa67f..cfdde3a56805 100644
> > > --- a/arch/arm64/include/asm/daifflags.h
> > > +++ b/arch/arm64/include/asm/daifflags.h
> > > @@ -131,6 +131,9 @@ static inline void local_daif_inherit(struct pt_regs *regs)
> > >  	if (interrupts_enabled(regs))
> > >  		trace_hardirqs_on();
> > >  
> > > +	if (system_uses_irq_prio_masking())
> > > +		gic_write_pmr(regs->pmr_save);
> > > +
> > >  	/*
> > >  	 * We can't use local_daif_restore(regs->pstate) here as
> > >  	 * system_has_prio_mask_debugging() won't restore the I bit if it can
> > > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > > index 9d3588450473..117412bae915 100644
> > > --- a/arch/arm64/kernel/entry-common.c
> > > +++ b/arch/arm64/kernel/entry-common.c
> > > @@ -226,14 +226,6 @@ static void noinstr el1_dbg(struct pt_regs *regs, unsigned long esr)
> > >  {
> > >  	unsigned long far = read_sysreg(far_el1);
> > >  
> > > -	/*
> > > -	 * The CPU masked interrupts, and we are leaving them masked during
> > > -	 * do_debug_exception(). Update PMR as if we had called
> > > -	 * local_daif_mask().
> > > -	 */
> > > -	if (system_uses_irq_prio_masking())
> > > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > > -
> > >  	arm64_enter_el1_dbg(regs);
> > >  	if (!cortex_a76_erratum_1463225_debug_handler(regs))
> > >  		do_debug_exception(far, esr, regs);
> > > @@ -398,9 +390,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
> > >  	/* Only watchpoints write FAR_EL1, otherwise its UNKNOWN */
> > >  	unsigned long far = read_sysreg(far_el1);
> > >  
> > > -	if (system_uses_irq_prio_masking())
> > > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > > -
> > >  	enter_from_user_mode();
> > >  	do_debug_exception(far, esr, regs);
> > >  	local_daif_restore(DAIF_PROCCTX_NOIRQ);
> > > @@ -408,9 +397,6 @@ static void noinstr el0_dbg(struct pt_regs *regs, unsigned long esr)
> > >  
> > >  static void noinstr el0_svc(struct pt_regs *regs)
> > >  {
> > > -	if (system_uses_irq_prio_masking())
> > > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > > -
> > >  	enter_from_user_mode();
> > >  	cortex_a76_erratum_1463225_svc_handler();
> > >  	do_el0_svc(regs);
> > > @@ -486,9 +472,6 @@ static void noinstr el0_cp15(struct pt_regs *regs, unsigned long esr)
> > >  
> > >  static void noinstr el0_svc_compat(struct pt_regs *regs)
> > >  {
> > > -	if (system_uses_irq_prio_masking())
> > > -		gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
> > > -
> > >  	enter_from_user_mode();
> > >  	cortex_a76_erratum_1463225_svc_handler();
> > >  	do_el0_svc_compat(regs);
> > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > index 6acfc5e6b5e0..941bb52b5e21 100644
> > > --- a/arch/arm64/kernel/entry.S
> > > +++ b/arch/arm64/kernel/entry.S
> > > @@ -292,6 +292,8 @@ alternative_else_nop_endif
> > >  alternative_if ARM64_HAS_IRQ_PRIO_MASKING
> > >  	mrs_s	x20, SYS_ICC_PMR_EL1
> > >  	str	x20, [sp, #S_PMR_SAVE]
> > > +	mov	x20, #GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET
> > > +	msr_s	SYS_ICC_PMR_EL1, x20
> > 
> > I'm a bit worried about forcing PMR to IRQON at this stage. We could
> > have been in IRQOFF state and entering the kernel because of a
> > NMI. Don't we risk losing track of how we made it here?
> 
> I also worried about this, but after digging for a while I convinced
> myself there wasn't a problem, as:
> 
> * This is what local_daif_mask() does today. It sets the PMR to
>  GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET regardless of its original state.
> 
> * For checking how we got here, we use either:
>  - regs::pmr_save, which is sampled (immediately) before we alter HW PMR
>    in the asm above.
>  - DAIF, which is unaffected by this.
> 
> * This is transparent to local_irq_save() .. local_irq_restore(), as
>   that blindly saves/restores the PMR.
> 

... oh, and within the GIC driver:

* for a pNMI, we'll leave both PMR and DAIF as-is

* for an IRQ, we'll set the PMU to GIC_PRIO_IRQOFF (regardless of the
  original value), then unmask DAIF.

... so that'll do the right thing even if we enter with PMR set to
(GIC_PRIO_IRQON | CIG_PRIO_PSR_I_SET).

Thanks.
Mark.


From rdunlap at infradead.org  Wed Apr 28 16:31:15 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Wed, 28 Apr 2021 08:31:15 -0700
Subject: [PATCH net-next v1 1/1] net: selftest: fix build issue if INET is
 disabled
In-Reply-To: <20210428130947.29649-1-o.rempel@pengutronix.de>
References: <20210428130947.29649-1-o.rempel@pengutronix.de>
Message-ID: <8a6612ee-8bb7-7287-265f-1a57d9532904@infradead.org>

On 4/28/21 6:09 AM, Oleksij Rempel wrote:
> In case ethernet driver is enabled and INET is disabled, selftest will
> fail to build.
> 
> Reported-by: Randy Dunlap <rdunlap at infradead.org>
> Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>

Acked-by: Randy Dunlap <rdunlap at infradead.org> # build-tested

Thanks.

> ---
>  drivers/net/ethernet/atheros/Kconfig   |  2 +-
>  drivers/net/ethernet/freescale/Kconfig |  2 +-
>  include/net/selftests.h                | 19 +++++++++++++++++++
>  net/Kconfig                            |  2 +-
>  net/core/Makefile                      |  2 +-
>  net/dsa/Kconfig                        |  2 +-
>  6 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/atheros/Kconfig b/drivers/net/ethernet/atheros/Kconfig
> index 6842b74b0696..482c58c4c584 100644
> --- a/drivers/net/ethernet/atheros/Kconfig
> +++ b/drivers/net/ethernet/atheros/Kconfig
> @@ -20,8 +20,8 @@ if NET_VENDOR_ATHEROS
>  config AG71XX
>  	tristate "Atheros AR7XXX/AR9XXX built-in ethernet mac support"
>  	depends on ATH79
> -	select NET_SELFTESTS
>  	select PHYLINK
> +	imply NET_SELFTESTS
>  	help
>  	  If you wish to compile a kernel for AR7XXX/91XXX and enable
>  	  ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> index 3d937b4650b2..2d1abdd58fab 100644
> --- a/drivers/net/ethernet/freescale/Kconfig
> +++ b/drivers/net/ethernet/freescale/Kconfig
> @@ -26,8 +26,8 @@ config FEC
>  		   ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
>  	default ARCH_MXC || SOC_IMX28 if ARM
>  	select CRC32
> -	select NET_SELFTESTS
>  	select PHYLIB
> +	imply NET_SELFTESTS
>  	imply PTP_1588_CLOCK
>  	help
>  	  Say Y here if you want to use the built-in 10/100 Fast ethernet
> diff --git a/include/net/selftests.h b/include/net/selftests.h
> index 9993b9498cf3..61926c33a022 100644
> --- a/include/net/selftests.h
> +++ b/include/net/selftests.h
> @@ -4,9 +4,28 @@
>  
>  #include <linux/ethtool.h>
>  
> +#if IS_ENABLED(CONFIG_NET_SELFTESTS)
> +
>  void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
>  		  u64 *buf);
>  int net_selftest_get_count(void);
>  void net_selftest_get_strings(u8 *data);
>  
> +#else
> +
> +static inline void net_selftest(struct net_device *ndev, struct ethtool_test *etest,
> +		  u64 *buf)
> +{
> +}
> +
> +static inline int net_selftest_get_count(void)
> +{
> +	return 0;
> +}
> +
> +static inline void net_selftest_get_strings(u8 *data)
> +{
> +}
> +
> +#endif
>  #endif /* _NET_SELFTESTS */
> diff --git a/net/Kconfig b/net/Kconfig
> index 8d955195c069..f5ee7c65e6b4 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -431,7 +431,7 @@ config SOCK_VALIDATE_XMIT
>  
>  config NET_SELFTESTS
>  	def_tristate PHYLIB
> -	depends on PHYLIB
> +	depends on PHYLIB && INET
>  
>  config NET_SOCK_MSG
>  	bool
> diff --git a/net/core/Makefile b/net/core/Makefile
> index 1a6168d8f23b..f7f16650fe9e 100644
> --- a/net/core/Makefile
> +++ b/net/core/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_NETPOLL) += netpoll.o
>  obj-$(CONFIG_FIB_RULES) += fib_rules.o
>  obj-$(CONFIG_TRACEPOINTS) += net-traces.o
>  obj-$(CONFIG_NET_DROP_MONITOR) += drop_monitor.o
> +obj-$(CONFIG_NET_SELFTESTS) += selftests.o
>  obj-$(CONFIG_NETWORK_PHY_TIMESTAMPING) += timestamping.o
>  obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
>  obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
> @@ -33,7 +34,6 @@ obj-$(CONFIG_NET_DEVLINK) += devlink.o
>  obj-$(CONFIG_GRO_CELLS) += gro_cells.o
>  obj-$(CONFIG_FAILOVER) += failover.o
>  ifeq ($(CONFIG_INET),y)
> -obj-$(CONFIG_NET_SELFTESTS) += selftests.o
>  obj-$(CONFIG_NET_SOCK_MSG) += skmsg.o
>  obj-$(CONFIG_BPF_SYSCALL) += sock_map.o
>  endif
> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index cbc2bd643ab2..183e27b50202 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -9,7 +9,7 @@ menuconfig NET_DSA
>  	select NET_SWITCHDEV
>  	select PHYLINK
>  	select NET_DEVLINK
> -	select NET_SELFTESTS
> +	imply NET_SELFTESTS
>  	help
>  	  Say Y if you want to enable support for the hardware switches supported
>  	  by the Distributed Switch Architecture.
> 


-- 
~Randy



From f.fainelli at gmail.com  Wed Apr 28 16:45:36 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 28 Apr 2021 08:45:36 -0700
Subject: [PATCH net-next v1 1/1] net: selftest: fix build issue if INET is
 disabled
In-Reply-To: <20210428130947.29649-1-o.rempel@pengutronix.de>
References: <20210428130947.29649-1-o.rempel@pengutronix.de>
Message-ID: <3fff9119-9f0e-33b1-64d0-a0a06c0f75ec@gmail.com>



On 4/28/2021 6:09 AM, Oleksij Rempel wrote:
> In case ethernet driver is enabled and INET is disabled, selftest will
> fail to build.
> 
> Reported-by: Randy Dunlap <rdunlap at infradead.org>
> Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>

Reviewed-by: Florian Fainelli <f.fainelli at gmail.com>
-- 
Florian


From alex.bennee at linaro.org  Wed Apr 28 16:37:45 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 16:37:45 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test
 into KVM and TCG variants
In-Reply-To: <87k0omo4rr.wl-maz@kernel.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org> <87fszasjdg.fsf@linaro.org>
 <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>
 <87k0omo4rr.wl-maz@kernel.org>
Message-ID: <87czues90k.fsf@linaro.org>


Marc Zyngier <maz at kernel.org> writes:

> On Wed, 28 Apr 2021 15:00:15 +0100,
> Alexandru Elisei <alexandru.elisei at arm.com> wrote:
>> 
>> I interpret that as that an INVALL guarantees that a change is
>> visible, but it the change can become visible even without the
>> INVALL.
>
> Yes. Expecting the LPI to be delivered or not in the absence of an
> invalidate when its configuration has been altered is wrong. The
> architecture doesn't guarantee anything of the sort.

Is the underlying hypervisor allowed to invalidate and reload the
configuration whenever it wants or should it only be driven by the
guests requests?

I did consider a more nuanced variant of the test that allowed for a
delivery pre-inval and a pass for post-inval as long as it had been
delivered one way or another:

--8<---------------cut here---------------start------------->8---
modified   arm/gic.c
@@ -36,6 +36,7 @@ static struct gic *gic;
 static int acked[NR_CPUS], spurious[NR_CPUS];
 static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
 static cpumask_t ready;
+static bool under_tcg;
 
 static void nr_cpu_check(int nr)
 {
@@ -687,6 +688,7 @@ static void test_its_trigger(void)
 	struct its_collection *col3;
 	struct its_device *dev2, *dev7;
 	cpumask_t mask;
+	bool before, after;
 
 	if (its_setup1())
 		return;
@@ -734,15 +736,17 @@ static void test_its_trigger(void)
 	/*
 	 * re-enable the LPI but willingly do not call invall
 	 * so the change in config is not taken into account.
-	 * The LPI should not hit
+	 * The LPI should not hit. This does however depend on
+	 * implementation defined behaviour - under QEMU TCG emulation
+	 * it can quite correctly process the event directly.
 	 */
 	gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
 	stats_reset();
 	cpumask_clear(&mask);
 	its_send_int(dev2, 20);
 	wait_for_interrupts(&mask);
-	report(check_acked(&mask, -1, -1),
-			"dev2/eventid=20 still does not trigger any LPI");
+	before = check_acked(&mask, -1, -1);
+	report_xfail(under_tcg, before, "dev2/eventid=20 still may not trigger any LPI");
 
 	/* Now call the invall and check the LPI hits */
 	stats_reset();
@@ -750,8 +754,8 @@ static void test_its_trigger(void)
 	cpumask_set_cpu(3, &mask);
 	its_send_invall(col3);
 	wait_for_interrupts(&mask);
-	report(check_acked(&mask, 0, 8195),
-			"dev2/eventid=20 pending LPI is received");
+	after = check_acked(&mask, 0, 8195);
+	report(before != after, "dev2/eventid=20 pending LPI is received");
 
 	stats_reset();
 	cpumask_clear(&mask);
@@ -759,7 +763,7 @@ static void test_its_trigger(void)
 	its_send_int(dev2, 20);
 	wait_for_interrupts(&mask);
 	report(check_acked(&mask, 0, 8195),
-			"dev2/eventid=20 now triggers an LPI");
+	       "dev2/eventid=20 now triggers an LPI");
 
 	report_prefix_pop();
 
@@ -981,6 +985,9 @@ int main(int argc, char **argv)
 	if (argc < 2)
 		report_abort("no test specified");
 
+	if (argc == 3 && strcmp(argv[2], "tcg") == 0)
+		under_tcg = true;
+
 	if (strcmp(argv[1], "ipi") == 0) {
 		report_prefix_push(argv[1]);
 		nr_cpu_check(2);
--8<---------------cut here---------------end--------------->8---

But that gets confused (that may be something for Sashi to look at):

  ITS: MAPD devid=2 size = 0x8 itt=0x40440000 valid=1
  ITS: MAPD devid=7 size = 0x8 itt=0x40450000 valid=1
  MAPC col_id=3 target_addr = 0x30000 valid=1
  MAPC col_id=2 target_addr = 0x20000 valid=1
  INVALL col_id=2
  INVALL col_id=3
  MAPTI dev_id=2 event_id=20 -> phys_id=8195, col_id=3
  MAPTI dev_id=7 event_id=255 -> phys_id=8196, col_id=2
  INT dev_id=2 event_id=20
  PASS: gicv3: its-trigger: int: dev=2, eventid=20  -> lpi= 8195, col=3
  INT dev_id=7 event_id=255
  PASS: gicv3: its-trigger: int: dev=7, eventid=255 -> lpi= 8196, col=2
  INV dev_id=2 event_id=20
  INT dev_id=2 event_id=20
  PASS: gicv3: its-trigger: inv/invall: dev2/eventid=20 does not trigger any LPI
  INT dev_id=2 event_id=20
  INFO: gicv3: its-trigger: inv/invall: interrupts timed-out (5s)
  INFO: gicv3: its-trigger: inv/invall: cpu3 received wrong irq 8195
  INFO: gicv3: its-trigger: inv/invall: ACKS: missing=0 extra=0 unexpected=1
  XFAIL: gicv3: its-trigger: inv/invall: dev2/eventid=20 still may not trigger any LPI
  INVALL col_id=3
  INFO: gicv3: its-trigger: inv/invall: interrupts timed-out (5s)
  INFO: gicv3: its-trigger: inv/invall: ACKS: missing=1 extra=0 unexpected=0
  FAIL: gicv3: its-trigger: inv/invall: dev2/eventid=20 pending LPI is received
  INT dev_id=2 event_id=20
  PASS: gicv3: its-trigger: inv/invall: dev2/eventid=20 now triggers an LPI
  ITS: MAPD devid=2 size = 0x8 itt=0x40440000 valid=0
  INT dev_id=2 event_id=20
  PASS: gicv3: its-trigger: mapd valid=false: no LPI after device unmap
  SUMMARY: 7 tests, 1 unexpected failures, 1 expected failures

>> The test relies on the fact that changes to the LPI tables are not
>> visible *under KVM* until the INVALL command, but that's not
>> necessarily the case on real hardware. To match the spec, I think
>> the test "dev2/eventid=20 still does not trigger any LPI" should be
>> removed and the stats reset should take place before the
>> configuration for LPI 8195 is set to the default.
>
> If that's what the test expects (I haven't tried to investigate), it
> should be dropped completely, rather than trying to sidestep it for
> TCG.

All three parts of that section?

	report(check_acked(&mask, -1, -1),
			"dev2/eventid=20 still does not trigger any LPI");
	report(check_acked(&mask, 0, 8195),
			"dev2/eventid=20 pending LPI is received");
	report(check_acked(&mask, 0, 8195),
			"dev2/eventid=20 now triggers an LPI");


-- 
Alex Benn?e


From jassisinghbrar at gmail.com  Wed Apr 28 17:02:24 2021
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Wed, 28 Apr 2021 11:02:24 -0500
Subject: [GIT PULL] Mailbox changes for v5.13
Message-ID: <CABb+yY0j+ENA=z40pCEZxGYJM-hXVxiYK0CU-OB4aA24SmV5nw@mail.gmail.com>

Hi Linus,

The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:

  Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)

are available in the Git repository at:

  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
tags/mailbox-v5.13

for you to fetch changes up to 2335f556b3afadbee6548456f543f53ac3d1af42:

  dt-bindings: mailbox: qcom-ipcc: Add compatible for SC7280
(2021-04-26 09:44:21 -0500)

----------------------------------------------------------------
- qcom: enable support for SM8350 and SC7280
- sprd: refcounting channel usage
specify interrupt names in dt
support sc9863a
- arm: drop redundant print
- ti: convert dt-bindings to json schema
- misc: spelling fixes

----------------------------------------------------------------
Bjorn Andersson (1):
      MAINTAINERS: Add DT bindings directory to mailbox

Nishanth Menon (1):
      dt-bindings: mailbox: ti,secure-proxy: Convert to json schema

Orson Zhai (3):
      mailbox: sprd: Introduce refcnt when clients requests/free channels
      dt-bindings: mailbox: Add interrupt-names to SPRD mailbox
      mailbox: sprd: Add supplementary inbox support

Qiheng Lin (1):
      mailbox: arm_mhu_db: Remove redundant dev_err call in mhu_db_probe()

Sai Prakash Ranjan (1):
      dt-bindings: mailbox: qcom-ipcc: Add compatible for SC7280

Tom Saeger (1):
      mailbox: fix various typos in comments

Vinod Koul (1):
      dt-bindings: mailbox: Add compatible for SM8350 IPCC

Yang Li (1):
      mailbox: pcc: fix platform_no_drv_owner.cocci warnings

 .../devicetree/bindings/mailbox/qcom-ipcc.yaml     |   2 +
 .../devicetree/bindings/mailbox/sprd-mailbox.yaml  |  13 +-
 .../bindings/mailbox/ti,secure-proxy.txt           |  50 -------
 .../bindings/mailbox/ti,secure-proxy.yaml          |  79 +++++++++++
 MAINTAINERS                                        |   1 +
 drivers/mailbox/Kconfig                            |   2 +-
 drivers/mailbox/arm_mhu_db.c                       |   4 +-
 drivers/mailbox/bcm-flexrm-mailbox.c               |   4 +-
 drivers/mailbox/mailbox-xgene-slimpro.c            |   6 +-
 drivers/mailbox/mailbox.h                          |   2 +-
 drivers/mailbox/pcc.c                              |   3 +-
 drivers/mailbox/pl320-ipc.c                        |   2 +-
 drivers/mailbox/sprd-mailbox.c                     | 147 +++++++++++++++------
 drivers/mailbox/ti-msgmgr.c                        |   2 +-
 14 files changed, 212 insertions(+), 105 deletions(-)
 delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
 create mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml


From sean at poorly.run  Wed Apr 28 17:15:59 2021
From: sean at poorly.run (Sean Paul)
Date: Wed, 28 Apr 2021 12:15:59 -0400
Subject: [PATCH v4 1/3] gpu: drm: separate panel orientation property
 creating and value setting
In-Reply-To: <20210428045533.564724-1-hsinyi@chromium.org>
References: <20210428045533.564724-1-hsinyi@chromium.org>
Message-ID: <CAMavQKKJp-d-ji6Ao8=1Mnx0pA0+YBregZ4aS0OS1sEqKCoE8w@mail.gmail.com>

On Wed, Apr 28, 2021 at 12:55 AM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>


Thank you for revising the patchset, this looks much better to me!


/snip

>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..cda83314d7ad 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c

/snip

> @@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
>   * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   *
> - * This function sets the connector's panel_orientation and attaches
> - * a "panel orientation" property to the connector.
> + * This function sets the connector's panel_orientation value. If the property
> + * doesn't exist, it will create one first.

I still don't think this function should overload initialization and
assignment. I'd prefer we just removed the creation from
set_panel_orientation entirely so this WARN can't be hit.


>   *
>   * Calling this function on a connector where the panel_orientation has
>   * already been set is a no-op (e.g. the orientation has been overridden with
> @@ -2206,18 +2206,16 @@ int drm_connector_set_panel_orientation(
>
>         prop = dev->mode_config.panel_orientation_property;
>         if (!prop) {
> -               prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> -                               "panel orientation",
> -                               drm_panel_orientation_enum_list,
> -                               ARRAY_SIZE(drm_panel_orientation_enum_list));
> -               if (!prop)
> -                       return -ENOMEM;
> +               int ret;
>
> -               dev->mode_config.panel_orientation_property = prop;
> +               ret = drm_connector_init_panel_orientation_property(connector);
> +               if (ret)
> +                       return ret;
> +               prop = dev->mode_config.panel_orientation_property;
>         }
>
> -       drm_object_attach_property(&connector->base, prop,
> -                                  info->panel_orientation);
> +       drm_object_property_set_value(&connector->base, prop,
> +                                     info->panel_orientation);
>         return 0;
>  }
>  EXPORT_SYMBOL(drm_connector_set_panel_orientation);
> @@ -2225,7 +2223,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
>  /**
>   * drm_connector_set_panel_orientation_with_quirk -
>   *     set the connector's panel_orientation after checking for quirks
> - * @connector: connector for which to init the panel-orientation property.
> + * @connector: connector for which to set the panel-orientation property.
>   * @panel_orientation: drm_panel_orientation value to set
>   * @width: width in pixels of the panel, used for panel quirk detection
>   * @height: height in pixels of the panel, used for panel quirk detection
> @@ -2252,6 +2250,40 @@ int drm_connector_set_panel_orientation_with_quirk(
>  }
>  EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
>
> +/**
> + * drm_connector_init_panel_orientation_property -
> + *     create the connector's panel orientation property
> + *
> + * This function attaches a "panel orientation" property to the connector
> + * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
> + *
> + * The value of the property can be set by drm_connector_set_panel_orientation()
> + * or drm_connector_set_panel_orientation_with_quirk() later.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_init_panel_orientation_property(
> +       struct drm_connector *connector)
> +{
> +       struct drm_device *dev = connector->dev;
> +       struct drm_property *prop;
> +
> +       prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
> +                       "panel orientation",
> +                       drm_panel_orientation_enum_list,
> +                       ARRAY_SIZE(drm_panel_orientation_enum_list));
> +       if (!prop)
> +               return -ENOMEM;
> +
> +       dev->mode_config.panel_orientation_property = prop;
> +       drm_object_attach_property(&connector->base, prop,
> +                                  DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
> +
>  int drm_connector_set_obj_prop(struct drm_mode_object *obj,
>                                     struct drm_property *property,
>                                     uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1922b278ffad..4396c1c4a5db 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk(
>         struct drm_connector *connector,
>         enum drm_panel_orientation panel_orientation,
>         int width, int height);
> +int drm_connector_init_panel_orientation_property(
> +       struct drm_connector *connector);
>  int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
>                                           int min, int max);
>
> --
> 2.31.1.498.g6c1eba8ee3d-goog
>


From alex.bennee at linaro.org  Wed Apr 28 17:31:27 2021
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 28 Apr 2021 17:31:27 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test
 into KVM and TCG variants
In-Reply-To: <87czues90k.fsf@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org> <87fszasjdg.fsf@linaro.org>
 <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>
 <87k0omo4rr.wl-maz@kernel.org> <87czues90k.fsf@linaro.org>
Message-ID: <877dkms72n.fsf@linaro.org>


Alex Benn?e <alex.bennee at linaro.org> writes:

> Marc Zyngier <maz at kernel.org> writes:
>
>> On Wed, 28 Apr 2021 15:00:15 +0100,
>> Alexandru Elisei <alexandru.elisei at arm.com> wrote:
>>> 
>>> I interpret that as that an INVALL guarantees that a change is
>>> visible, but it the change can become visible even without the
>>> INVALL.
>>
>> Yes. Expecting the LPI to be delivered or not in the absence of an
>> invalidate when its configuration has been altered is wrong. The
>> architecture doesn't guarantee anything of the sort.
>
> Is the underlying hypervisor allowed to invalidate and reload the
> configuration whenever it wants or should it only be driven by the
> guests requests?
>
> I did consider a more nuanced variant of the test that allowed for a
> delivery pre-inval and a pass for post-inval as long as it had been
> delivered one way or another:
>
> --8<---------------cut here---------------start------------->8---
> modified   arm/gic.c
> @@ -36,6 +36,7 @@ static struct gic *gic;
>  static int acked[NR_CPUS], spurious[NR_CPUS];
>  static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
>  static cpumask_t ready;
> +static bool under_tcg;
>  
>  static void nr_cpu_check(int nr)
>  {
> @@ -687,6 +688,7 @@ static void test_its_trigger(void)
>  	struct its_collection *col3;
>  	struct its_device *dev2, *dev7;
>  	cpumask_t mask;
> +	bool before, after;
>  
>  	if (its_setup1())
>  		return;
> @@ -734,15 +736,17 @@ static void test_its_trigger(void)
>  	/*
>  	 * re-enable the LPI but willingly do not call invall
>  	 * so the change in config is not taken into account.
> -	 * The LPI should not hit
> +	 * The LPI should not hit. This does however depend on
> +	 * implementation defined behaviour - under QEMU TCG emulation
> +	 * it can quite correctly process the event directly.
>  	 */
>  	gicv3_lpi_set_config(8195, LPI_PROP_DEFAULT);
>  	stats_reset();
>  	cpumask_clear(&mask);
>  	its_send_int(dev2, 20);
>  	wait_for_interrupts(&mask);
> -	report(check_acked(&mask, -1, -1),
> -			"dev2/eventid=20 still does not trigger any LPI");
> +	before = check_acked(&mask, -1, -1);
> +	report_xfail(under_tcg, before, "dev2/eventid=20 still may not trigger any LPI");
>  
>  	/* Now call the invall and check the LPI hits */
>  	stats_reset();
> @@ -750,8 +754,8 @@ static void test_its_trigger(void)
>  	cpumask_set_cpu(3, &mask);
>  	its_send_invall(col3);
>  	wait_for_interrupts(&mask);
> -	report(check_acked(&mask, 0, 8195),
> -			"dev2/eventid=20 pending LPI is received");
> +	after = check_acked(&mask, 0, 8195);
> +	report(before != after, "dev2/eventid=20 pending LPI is
>  	received");

Actually that should be:

         report(after || !before, "dev2/eventid=20 pending LPI is received");

so either the IRQ arrives after the flush or it had previously.

-- 
Alex Benn?e


From mkorpershoek at baylibre.com  Wed Apr 28 17:42:12 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:12 +0200
Subject: [PATCH 0/7] Input: mtk-pmic-keys - add support for MT6358
Message-ID: <20210428164219.1115537-1-mkorpershoek@baylibre.com>

The MediaTek MT6358 PMIC has support for two buttons: PWR and HOME.

The interrupt logic is a little different than other PMICs from the
same family:
* for MT6323 and MT6397, we have one interrupt source per button
* for MT6358, we have two interrupts lines per button: the press and
* release interrupts are distinct sources.

These series:
* Fix a NULL ptr error when we use mtk-pmic-keys without dts code
* Rework the mt6397 driver to prepare for this different interrupt logic
* Add support for the MT6358 power buttons

This has been functionally tested (using evtest) on
the mt8183-pumpkin board on linux/master

It has also been used for a couple of months in a downstream
tree based on v5.4.

Mattijs Korpershoek (7):
  Input: mtk-pmic-keys - check for NULL on of_match_device()
  mfd: mt6397: add mt6358 register definitions for power key
  mfd: mt6397: keys: use named IRQs instead of index
  dt-bindings: input: mtk-pmic-keys: add MT6358 binding definition
  Input: mtk-pmic-keys - add support for MT6358
  mfd: mt6397: Add PMIC keys for MT6358
  arm64: dts: mt6358: add mt6358-keys node

 .../bindings/input/mtk-pmic-keys.txt          |  5 +-
 arch/arm64/boot/dts/mediatek/mt6358.dtsi      | 12 ++++
 drivers/input/keyboard/mtk-pmic-keys.c        | 59 +++++++++++++++++--
 drivers/mfd/mt6397-core.c                     | 20 +++++--
 include/linux/mfd/mt6358/registers.h          |  2 +
 5 files changed, 89 insertions(+), 9 deletions(-)


base-commit: 4a0225c3d208cfa6e4550f2210ffd9114a952a81
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:13 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:13 +0200
Subject: [PATCH 1/7] Input: mtk-pmic-keys - check for NULL on of_match_device()
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-2-mkorpershoek@baylibre.com>

mtk-pmic-keys being a child device of mt6397, it will always get probed
when mt6397_probe() is called.

This also happens when we have no device tree node matching
mediatek,mt6397-keys.

In that case, the mfd core warns us:

  [    0.352175] mtk-pmic-keys: Failed to locate of_node [id: -1]

Check return value from call to of_match_device()
in order to prevent a NULL pointer dereference.

In case of NULL print error message and return -ENODEV

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 drivers/input/keyboard/mtk-pmic-keys.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index 62391d6c7da6..12c449eed026 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -247,6 +247,9 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 	const struct of_device_id *of_id =
 		of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
 
+	if (!of_id)
+		return -ENODEV;
+
 	keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
 	if (!keys)
 		return -ENOMEM;
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:14 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:14 +0200
Subject: [PATCH 2/7] mfd: mt6397: add mt6358 register definitions for power key
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-3-mkorpershoek@baylibre.com>

In order to support power/home key detection, add definitions for
two more MT6358 PMIC registers:

- TOPSTATUS: homekey and powerkey debounce status
- TOP_RST_MISC: controls homekey,powerkey long press reset time

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 include/linux/mfd/mt6358/registers.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mfd/mt6358/registers.h b/include/linux/mfd/mt6358/registers.h
index 2ad0b312aa28..201139b12140 100644
--- a/include/linux/mfd/mt6358/registers.h
+++ b/include/linux/mfd/mt6358/registers.h
@@ -8,6 +8,8 @@
 
 /* PMIC Registers */
 #define MT6358_SWCID                          0xa
+#define MT6358_TOPSTATUS                      0x28
+#define MT6358_TOP_RST_MISC                   0x14c
 #define MT6358_MISC_TOP_INT_CON0              0x188
 #define MT6358_MISC_TOP_INT_STATUS0           0x194
 #define MT6358_TOP_INT_STATUS0                0x19e
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:15 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:15 +0200
Subject: [PATCH 3/7] mfd: mt6397: keys: use named IRQs instead of index
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-4-mkorpershoek@baylibre.com>

For some compatible pmics (such as MT6358), there are two IRQs per
physical key: one for press event, another for release event.

Currently, the mtk-pmic-keys driver assumes that each key only has one
IRQ. The key index and the RES_IRQ resource index have a 1/1 mapping.

This won't work for MT6358, as we have multiple resources (2) for one key.

To prepare mtk-pmic-keys to support MT6358, retrieve IRQs by name
instead of by index.

Note: The keys_resources are not part of the device-tree bindings so
this won't break any DT schemas.

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 drivers/input/keyboard/mtk-pmic-keys.c | 7 +++++--
 drivers/mfd/mt6397-core.c              | 8 ++++----
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index 12c449eed026..b877bf98db38 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -241,6 +241,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 	unsigned int keycount;
 	struct mt6397_chip *pmic_chip = dev_get_drvdata(pdev->dev.parent);
 	struct device_node *node = pdev->dev.of_node, *child;
+	static const char *const irqnames[] = { "powerkey", "homekey" };
 	struct mtk_pmic_keys *keys;
 	const struct mtk_pmic_regs *mtk_pmic_regs;
 	struct input_dev *input_dev;
@@ -271,7 +272,8 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 	input_dev->id.version = 0x0001;
 
 	keycount = of_get_available_child_count(node);
-	if (keycount > MTK_PMIC_MAX_KEY_COUNT) {
+	if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
+	    keycount > ARRAY_SIZE(irqnames)) {
 		dev_err(keys->dev, "too many keys defined (%d)\n", keycount);
 		return -EINVAL;
 	}
@@ -279,7 +281,8 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 	for_each_child_of_node(node, child) {
 		keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index];
 
-		keys->keys[index].irq = platform_get_irq(pdev, index);
+		keys->keys[index].irq =
+			platform_get_irq_byname(pdev, irqnames[index]);
 		if (keys->keys[index].irq < 0) {
 			of_node_put(child);
 			return keys->keys[index].irq;
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 7518d74c3b4c..8738b5524783 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -46,13 +46,13 @@ static const struct resource mt6397_rtc_resources[] = {
 };
 
 static const struct resource mt6323_keys_resources[] = {
-	DEFINE_RES_IRQ(MT6323_IRQ_STATUS_PWRKEY),
-	DEFINE_RES_IRQ(MT6323_IRQ_STATUS_FCHRKEY),
+	DEFINE_RES_IRQ_NAMED(MT6323_IRQ_STATUS_PWRKEY, "powerkey"),
+	DEFINE_RES_IRQ_NAMED(MT6323_IRQ_STATUS_FCHRKEY, "homekey"),
 };
 
 static const struct resource mt6397_keys_resources[] = {
-	DEFINE_RES_IRQ(MT6397_IRQ_PWRKEY),
-	DEFINE_RES_IRQ(MT6397_IRQ_HOMEKEY),
+	DEFINE_RES_IRQ_NAMED(MT6397_IRQ_PWRKEY, "powerkey"),
+	DEFINE_RES_IRQ_NAMED(MT6397_IRQ_HOMEKEY, "homekey"),
 };
 
 static const struct resource mt6323_pwrc_resources[] = {
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:17 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:17 +0200
Subject: [PATCH 5/7] Input: mtk-pmic-keys - add support for MT6358
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-6-mkorpershoek@baylibre.com>

MT6358 pmic keys behave differently than mt6397 and mt6323: there are
two interrupts per key: one for press, the other one for release (_r)

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 drivers/input/keyboard/mtk-pmic-keys.c | 49 ++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
index b877bf98db38..c635d612bd44 100644
--- a/drivers/input/keyboard/mtk-pmic-keys.c
+++ b/drivers/input/keyboard/mtk-pmic-keys.c
@@ -9,6 +9,7 @@
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/mfd/mt6323/registers.h>
+#include <linux/mfd/mt6358/registers.h>
 #include <linux/mfd/mt6397/core.h>
 #include <linux/mfd/mt6397/registers.h>
 #include <linux/module.h>
@@ -74,11 +75,22 @@ static const struct mtk_pmic_regs mt6323_regs = {
 	.pmic_rst_reg = MT6323_TOP_RST_MISC,
 };
 
+static const struct mtk_pmic_regs mt6358_regs = {
+	.keys_regs[MTK_PMIC_PWRKEY_INDEX] =
+		MTK_PMIC_KEYS_REGS(MT6358_TOPSTATUS,
+		0x2, MT6358_PSC_TOP_INT_CON0, 0x5),
+	.keys_regs[MTK_PMIC_HOMEKEY_INDEX] =
+		MTK_PMIC_KEYS_REGS(MT6358_TOPSTATUS,
+		0x8, MT6358_PSC_TOP_INT_CON0, 0xa),
+	.pmic_rst_reg = MT6358_TOP_RST_MISC,
+};
+
 struct mtk_pmic_keys_info {
 	struct mtk_pmic_keys *keys;
 	const struct mtk_pmic_keys_regs *regs;
 	unsigned int keycode;
 	int irq;
+	int irq_r; /* optional: release irq if different */
 	bool wakeup:1;
 };
 
@@ -188,6 +200,19 @@ static int mtk_pmic_key_setup(struct mtk_pmic_keys *keys,
 		return ret;
 	}
 
+	if (info->irq_r > 0) {
+		ret = devm_request_threaded_irq(
+			keys->dev, info->irq_r, NULL,
+			mtk_pmic_keys_irq_handler_thread,
+			IRQF_ONESHOT | IRQF_TRIGGER_HIGH, "mtk-pmic-keys",
+			info);
+		if (ret) {
+			dev_err(keys->dev, "Failed to request IRQ_r: %d: %d\n",
+				info->irq, ret);
+			return ret;
+		}
+	}
+
 	input_set_capability(keys->input_dev, EV_KEY, info->keycode);
 
 	return 0;
@@ -199,8 +224,11 @@ static int __maybe_unused mtk_pmic_keys_suspend(struct device *dev)
 	int index;
 
 	for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
-		if (keys->keys[index].wakeup)
+		if (keys->keys[index].wakeup) {
 			enable_irq_wake(keys->keys[index].irq);
+			if (keys->keys[index].irq_r > 0)
+				enable_irq_wake(keys->keys[index].irq_r);
+		}
 	}
 
 	return 0;
@@ -212,8 +240,11 @@ static int __maybe_unused mtk_pmic_keys_resume(struct device *dev)
 	int index;
 
 	for (index = 0; index < MTK_PMIC_MAX_KEY_COUNT; index++) {
-		if (keys->keys[index].wakeup)
+		if (keys->keys[index].wakeup) {
 			disable_irq_wake(keys->keys[index].irq);
+			if (keys->keys[index].irq_r > 0)
+				disable_irq_wake(keys->keys[index].irq_r);
+		}
 	}
 
 	return 0;
@@ -229,6 +260,9 @@ static const struct of_device_id of_mtk_pmic_keys_match_tbl[] = {
 	}, {
 		.compatible = "mediatek,mt6323-keys",
 		.data = &mt6323_regs,
+	}, {
+		.compatible = "mediatek,mt6358-keys",
+		.data = &mt6358_regs,
 	}, {
 		/* sentinel */
 	}
@@ -242,6 +276,7 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 	struct mt6397_chip *pmic_chip = dev_get_drvdata(pdev->dev.parent);
 	struct device_node *node = pdev->dev.of_node, *child;
 	static const char *const irqnames[] = { "powerkey", "homekey" };
+	static const char *const irqnames_r[] = { "powerkey_r", "homekey_r" };
 	struct mtk_pmic_keys *keys;
 	const struct mtk_pmic_regs *mtk_pmic_regs;
 	struct input_dev *input_dev;
@@ -288,6 +323,16 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
 			return keys->keys[index].irq;
 		}
 
+		if (of_device_is_compatible(node, "mediatek,mt6358-keys")) {
+			keys->keys[index].irq_r = platform_get_irq_byname(
+				pdev, irqnames_r[index]);
+
+			if (keys->keys[index].irq_r < 0) {
+				of_node_put(child);
+				return keys->keys[index].irq_r;
+			}
+		}
+
 		error = of_property_read_u32(child,
 			"linux,keycodes", &keys->keys[index].keycode);
 		if (error) {
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:18 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:18 +0200
Subject: [PATCH 6/7] mfd: mt6397: Add PMIC keys for MT6358
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-7-mkorpershoek@baylibre.com>

This patch adds compatible strings and interrupts for pmic keys
which serves as child device of MFD.

MT6358 has two interrupts per key: one for press, another one for
release (_R)

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 drivers/mfd/mt6397-core.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 8738b5524783..13a5e15e9dd6 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -45,6 +45,13 @@ static const struct resource mt6397_rtc_resources[] = {
 	DEFINE_RES_IRQ(MT6397_IRQ_RTC),
 };
 
+static const struct resource mt6358_keys_resources[] = {
+	DEFINE_RES_IRQ_NAMED(MT6358_IRQ_PWRKEY, "powerkey"),
+	DEFINE_RES_IRQ_NAMED(MT6358_IRQ_HOMEKEY, "homekey"),
+	DEFINE_RES_IRQ_NAMED(MT6358_IRQ_PWRKEY_R, "powerkey_r"),
+	DEFINE_RES_IRQ_NAMED(MT6358_IRQ_HOMEKEY_R, "homekey_r"),
+};
+
 static const struct resource mt6323_keys_resources[] = {
 	DEFINE_RES_IRQ_NAMED(MT6323_IRQ_STATUS_PWRKEY, "powerkey"),
 	DEFINE_RES_IRQ_NAMED(MT6323_IRQ_STATUS_FCHRKEY, "homekey"),
@@ -96,6 +103,11 @@ static const struct mfd_cell mt6358_devs[] = {
 	}, {
 		.name = "mt6358-sound",
 		.of_compatible = "mediatek,mt6358-sound"
+	}, {
+		.name = "mtk-pmic-keys",
+		.num_resources = ARRAY_SIZE(mt6358_keys_resources),
+		.resources = mt6358_keys_resources,
+		.of_compatible = "mediatek,mt6358-keys"
 	},
 };
 
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:16 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:16 +0200
Subject: [PATCH 4/7] dt-bindings: input: mtk-pmic-keys: add MT6358 binding
 definition
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-5-mkorpershoek@baylibre.com>

Add the binding documentation of the mtk-pmic-keys for the MT6358 PMICs.

MT6358 is a little different since it used separate IRQs for the
release key (_r) event

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 Documentation/devicetree/bindings/input/mtk-pmic-keys.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
index 535d92885372..9d00f2a8e13a 100644
--- a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
+++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
@@ -9,7 +9,10 @@ For MT6397/MT6323 MFD bindings see:
 Documentation/devicetree/bindings/mfd/mt6397.txt
 
 Required properties:
-- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
+- compatible: Should be one of:
+	- "mediatek,mt6397-keys"
+	- "mediatek,mt6323-keys"
+	- "mediatek,mt6358-keys"
 - linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml
 
 Optional Properties:
-- 
2.27.0



From mkorpershoek at baylibre.com  Wed Apr 28 17:42:19 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Wed, 28 Apr 2021 18:42:19 +0200
Subject: [PATCH 7/7] arm64: dts: mt6358: add mt6358-keys node
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <20210428164219.1115537-8-mkorpershoek@baylibre.com>

This enables the power,home keys on MediaTek boards with a mt6358 pmic.

Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---
 arch/arm64/boot/dts/mediatek/mt6358.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6358.dtsi b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
index fa159b20379e..a1b017a6a751 100644
--- a/arch/arm64/boot/dts/mediatek/mt6358.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6358.dtsi
@@ -2,6 +2,7 @@
 /*
  * Copyright (c) 2020 MediaTek Inc.
  */
+#include <dt-bindings/input/input.h>
 
 &pwrap {
 	pmic: mt6358 {
@@ -356,5 +357,16 @@ mt6358_vsim2_reg: ldo_vsim2 {
 		mt6358rtc: mt6358rtc {
 			compatible = "mediatek,mt6358-rtc";
 		};
+
+		mt6358keys: mt6358keys {
+			compatible = "mediatek,mt6358-keys";
+			power {
+				linux,keycodes = <KEY_POWER>;
+				wakeup-source;
+			};
+			home {
+				linux,keycodes = <KEY_HOME>;
+			};
+		};
 	};
 };
-- 
2.27.0



From christophe.leroy at csgroup.eu  Wed Apr 28 17:46:13 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 16:46:13 +0000 (UTC)
Subject: [RFC PATCH v1 3/4] mm/pgtable: Add stubs for
 {pmd/pub}_{set/clear}_huge
In-Reply-To: <cover.1619628001.git.christophe.leroy@csgroup.eu>
References: <cover.1619628001.git.christophe.leroy@csgroup.eu>
Message-ID: <6f482b6722f7a891ce335db7e02ecbdb42574e8b.1619628001.git.christophe.leroy@csgroup.eu>

For architectures with no PMD and/or no PUD, add stubs
similar to what we have for architectures without P4D.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 include/linux/pgtable.h | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 46b13780c2c8..d41474a2d255 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1371,10 +1371,34 @@ static inline int p4d_clear_huge(p4d_t *p4d)
 }
 #endif /* !__PAGETABLE_P4D_FOLDED */
 
+#ifndef __PAGETABLE_PUD_FOLDED
 int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
-int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
 int pud_clear_huge(pud_t *pud);
+#else
+static inline int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
+{
+	return 0;
+}
+static inline int pud_clear_huge(pud_t *pud)
+{
+	return 0;
+}
+#endif /* !__PAGETABLE_PUD_FOLDED */
+
+#ifndef __PAGETABLE_PMD_FOLDED
+int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
 int pmd_clear_huge(pmd_t *pmd);
+#else
+static inline int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
+{
+	return 0;
+}
+static inline int pmd_clear_huge(pmd_t *pmd)
+{
+	return 0;
+}
+#endif /* !__PAGETABLE_PMD_FOLDED */
+
 int p4d_free_pud_page(p4d_t *p4d, unsigned long addr);
 int pud_free_pmd_page(pud_t *pud, unsigned long addr);
 int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
-- 
2.25.0



From christophe.leroy at csgroup.eu  Wed Apr 28 17:46:10 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 16:46:10 +0000 (UTC)
Subject: [RFC PATCH v1 0/4] Implement huge VMAP and VMALLOC on powerpc 8xx
Message-ID: <cover.1619628001.git.christophe.leroy@csgroup.eu>

This series is a first tentative to implement huge VMAP and VMALLOC
on powerpc 8xx. This series applies on Linux next.
For the time being the 8xx specificities are plugged directly into
generic mm functions. I have no real idea on how to make it a nice
beautiful generic implementation for the time being, hence this RFC
in order to get suggestions.

powerpc 8xx has 4 page sizes:
- 4k
- 16k
- 512k
- 8M

At the time being, vmalloc and vmap only support huge pages which are
leaf at PMD level.

Here the PMD level is 4M, it doesn't correspond to any supported
page size.

For the time being, implement use of 16k and 512k pages which is done
at PTE level.

Support of 8M pages will be implemented later, it requires use of
hugepd tables.

Christophe Leroy (4):
  mm/ioremap: Fix iomap_max_page_shift
  mm/hugetlb: Change parameters of arch_make_huge_pte()
  mm/pgtable: Add stubs for {pmd/pub}_{set/clear}_huge
  mm/vmalloc: Add support for huge pages on VMAP and VMALLOC for powerpc
    8xx

 arch/arm64/include/asm/hugetlb.h              |  3 +-
 arch/arm64/mm/hugetlbpage.c                   |  5 +-
 arch/powerpc/Kconfig                          |  3 +-
 .../include/asm/nohash/32/hugetlb-8xx.h       |  5 +-
 arch/sparc/include/asm/pgtable_64.h           |  3 +-
 arch/sparc/mm/hugetlbpage.c                   |  6 +-
 include/linux/hugetlb.h                       |  4 +-
 include/linux/pgtable.h                       | 26 ++++++-
 mm/hugetlb.c                                  |  6 +-
 mm/ioremap.c                                  |  6 +-
 mm/migrate.c                                  |  4 +-
 mm/vmalloc.c                                  | 74 ++++++++++++++++---
 12 files changed, 111 insertions(+), 34 deletions(-)

-- 
2.25.0



From christophe.leroy at csgroup.eu  Wed Apr 28 17:46:11 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 16:46:11 +0000 (UTC)
Subject: [RFC PATCH v1 1/4] mm/ioremap: Fix iomap_max_page_shift
In-Reply-To: <cover.1619628001.git.christophe.leroy@csgroup.eu>
References: <cover.1619628001.git.christophe.leroy@csgroup.eu>
Message-ID: <bb90cec22c8734e0614ef2b16e380aebe887a80a.1619628001.git.christophe.leroy@csgroup.eu>

iomap_max_page_shift is expected to contain a page shift,
so it can't be a 'bool', has to be an 'unsigned int'

And fix the default values: P4D_SHIFT is when huge iomap is allowed.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 mm/ioremap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/ioremap.c b/mm/ioremap.c
index d1dcc7e744ac..2f7193c6a99e 100644
--- a/mm/ioremap.c
+++ b/mm/ioremap.c
@@ -16,16 +16,16 @@
 #include "pgalloc-track.h"
 
 #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
-static bool __ro_after_init iomap_max_page_shift = PAGE_SHIFT;
+static unsigned int __ro_after_init iomap_max_page_shift = P4D_SHIFT;
 
 static int __init set_nohugeiomap(char *str)
 {
-	iomap_max_page_shift = P4D_SHIFT;
+	iomap_max_page_shift = PAGE_SHIFT;
 	return 0;
 }
 early_param("nohugeiomap", set_nohugeiomap);
 #else /* CONFIG_HAVE_ARCH_HUGE_VMAP */
-static const bool iomap_max_page_shift = PAGE_SHIFT;
+static const unsigned int iomap_max_page_shift = PAGE_SHIFT;
 #endif	/* CONFIG_HAVE_ARCH_HUGE_VMAP */
 
 int ioremap_page_range(unsigned long addr,
-- 
2.25.0



From christophe.leroy at csgroup.eu  Wed Apr 28 17:46:14 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 16:46:14 +0000 (UTC)
Subject: [RFC PATCH v1 4/4] mm/vmalloc: Add support for huge pages on VMAP and
 VMALLOC for powerpc 8xx
In-Reply-To: <cover.1619628001.git.christophe.leroy@csgroup.eu>
References: <cover.1619628001.git.christophe.leroy@csgroup.eu>
Message-ID: <15cea17065678a4e9019a20b7d011ca6eb205de6.1619628001.git.christophe.leroy@csgroup.eu>

powerpc 8xx has 4 page sizes:
- 4k
- 16k
- 512k
- 8M

At the time being, vmalloc and vmap only support huge pages which are
leaf at PMD level.

Here the PMD level is 4M, it doesn't correspond to any supported
page size.

For the time being, implement use of 16k and 512k pages which is done
at PTE level.

Support of 8M pages will be implemented later, it requires use of
hugepd tables.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/powerpc/Kconfig |  3 +-
 mm/vmalloc.c         | 74 ++++++++++++++++++++++++++++++++++++++------
 2 files changed, 66 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 27e88c38fdf7..b443716f7413 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -188,7 +188,8 @@ config PPC
 	select GENERIC_TIME_VSYSCALL
 	select GENERIC_VDSO_TIME_NS
 	select HAVE_ARCH_AUDITSYSCALL
-	select HAVE_ARCH_HUGE_VMAP		if PPC_BOOK3S_64 && PPC_RADIX_MMU
+	select HAVE_ARCH_HUGE_VMAP		if (PPC_BOOK3S_64 && PPC_RADIX_MMU) || PPC_8xx
+	select HAVE_ARCH_HUGE_VMALLOC		if PPC_8xx
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
 	select HAVE_ARCH_KASAN			if PPC32 && PPC_PAGE_SHIFT <= 14
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 5d96fee17226..1f9f9be8ec01 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -36,6 +36,7 @@
 #include <linux/overflow.h>
 #include <linux/pgtable.h>
 #include <linux/uaccess.h>
+#include <linux/hugetlb.h>
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 
@@ -81,12 +82,55 @@ static void free_work(struct work_struct *w)
 }
 
 /*** Page table manipulation functions ***/
+static int vmap_try_huge_pte(pte_t *ptep, unsigned long addr, unsigned long end,
+			     u64 pfn, pgprot_t prot, unsigned int max_page_shift)
+{
+	unsigned long size = end - addr;
+	pte_t pte;
+
+	if (!IS_ENABLED(CONFIG_PPC_8xx))
+		return 0;
+
+	if (PAGE_SIZE == SZ_16K && size < SZ_512K)
+		return 0;
+
+	if (size < SZ_16K)
+		return 0;
+
+	if (max_page_shift < 14)
+		return 0;
+
+	if (size > SZ_512K)
+		size = SZ_512K;
+
+	if (max_page_shift < 19 && size > SZ_16K)
+		size = SZ_16K;
+
+	if (!IS_ALIGNED(addr, size))
+		return 0;
+
+	if (!IS_ALIGNED(PFN_PHYS(pfn), size))
+		return 0;
+
+	if (pte_present(*ptep))
+		return 0;
+
+	pte = pfn_pte(pfn, prot);
+	pte = pte_mkhuge(pte);
+	pte = arch_make_huge_pte(pte, ilog2(size), 0);
+
+	set_huge_pte_at(&init_mm, addr, ptep, pte);
+
+	return PFN_DOWN(size);
+}
+
 static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 			phys_addr_t phys_addr, pgprot_t prot,
-			pgtbl_mod_mask *mask)
+			unsigned int max_page_shift, pgtbl_mod_mask *mask)
 {
 	pte_t *pte;
 	u64 pfn;
+	int npages;
 
 	pfn = phys_addr >> PAGE_SHIFT;
 	pte = pte_alloc_kernel_track(pmd, addr, mask);
@@ -94,9 +138,14 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
 		return -ENOMEM;
 	do {
 		BUG_ON(!pte_none(*pte));
-		set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
-		pfn++;
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+
+		npages = vmap_try_huge_pte(pte, addr, end, pfn, prot, max_page_shift);
+		if (!npages) {
+			set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
+			npages = 1;
+		}
+		pfn += npages;
+	} while (pte += npages, addr += PAGE_SIZE * npages, addr != end);
 	*mask |= PGTBL_PTE_MODIFIED;
 	return 0;
 }
@@ -145,7 +194,7 @@ static int vmap_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
 			continue;
 		}
 
-		if (vmap_pte_range(pmd, addr, next, phys_addr, prot, mask))
+		if (vmap_pte_range(pmd, addr, next, phys_addr, prot, max_page_shift, mask))
 			return -ENOMEM;
 	} while (pmd++, phys_addr += (next - addr), addr = next, addr != end);
 	return 0;
@@ -2881,8 +2930,7 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
 		return NULL;
 	}
 
-	if (vmap_allow_huge && !(vm_flags & VM_NO_HUGE_VMAP) &&
-			arch_vmap_pmd_supported(prot)) {
+	if (vmap_allow_huge && !(vm_flags & VM_NO_HUGE_VMAP)) {
 		unsigned long size_per_node;
 
 		/*
@@ -2895,11 +2943,17 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
 		size_per_node = size;
 		if (node == NUMA_NO_NODE)
 			size_per_node /= num_online_nodes();
-		if (size_per_node >= PMD_SIZE) {
+		if (arch_vmap_pmd_supported(prot) && size_per_node >= PMD_SIZE) {
 			shift = PMD_SHIFT;
-			align = max(real_align, 1UL << shift);
-			size = ALIGN(real_size, 1UL << shift);
+		} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
+			if (size_per_node >= SZ_512K) {
+				shift = 19;
+			} else if (size_per_node >= SZ_16K) {
+				shift = 14;
+			}
 		}
+		align = max(real_align, 1UL << shift);
+		size = ALIGN(real_size, 1UL << shift);
 	}
 
 again:
-- 
2.25.0



From christophe.leroy at csgroup.eu  Wed Apr 28 17:46:12 2021
From: christophe.leroy at csgroup.eu (Christophe Leroy)
Date: Wed, 28 Apr 2021 16:46:12 +0000 (UTC)
Subject: [RFC PATCH v1 2/4] mm/hugetlb: Change parameters of
 arch_make_huge_pte()
In-Reply-To: <cover.1619628001.git.christophe.leroy@csgroup.eu>
References: <cover.1619628001.git.christophe.leroy@csgroup.eu>
Message-ID: <e111d0d90231ae63e4b89da8efa87cde31daeeee.1619628001.git.christophe.leroy@csgroup.eu>

At the time being, arch_make_huge_pte() has the following prototype:

	pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
				 struct page *page, int writable);

vma is used to get the pages shift or size.
vma is also used on Sparc to get vm_flags.
page is not used.
writable is not used.

In order to use this function without a vma, and replace vma by shift
and flags. Also remove the used parameters.

Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
---
 arch/arm64/include/asm/hugetlb.h                 | 3 +--
 arch/arm64/mm/hugetlbpage.c                      | 5 ++---
 arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 5 ++---
 arch/sparc/include/asm/pgtable_64.h              | 3 +--
 arch/sparc/mm/hugetlbpage.c                      | 6 ++----
 include/linux/hugetlb.h                          | 4 ++--
 mm/hugetlb.c                                     | 6 ++++--
 mm/migrate.c                                     | 4 +++-
 8 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index 5abf91e3494c..1242f71937f8 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -23,8 +23,7 @@ static inline void arch_clear_hugepage_flags(struct page *page)
 }
 #define arch_clear_hugepage_flags arch_clear_hugepage_flags
 
-extern pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-				struct page *page, int writable);
+pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags);
 #define arch_make_huge_pte arch_make_huge_pte
 #define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
 extern void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 58987a98e179..23505fc35324 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -339,10 +339,9 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
 	return NULL;
 }
 
-pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-			 struct page *page, int writable)
+pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags)
 {
-	size_t pagesize = huge_page_size(hstate_vma(vma));
+	size_t pagesize = 1UL << shift;
 
 	if (pagesize == CONT_PTE_SIZE) {
 		entry = pte_mkcont(entry);
diff --git a/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h b/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
index 39be9aea86db..64b6c608eca4 100644
--- a/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h
@@ -66,10 +66,9 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
 }
 
 #ifdef CONFIG_PPC_4K_PAGES
-static inline pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-				       struct page *page, int writable)
+static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags)
 {
-	size_t size = huge_page_size(hstate_vma(vma));
+	size_t size = 1UL << shift;
 
 	if (size == SZ_16K)
 		return __pte(pte_val(entry) & ~_PAGE_HUGE);
diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 550d3904de65..2cd80a0a9795 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -377,8 +377,7 @@ static inline pgprot_t pgprot_noncached(pgprot_t prot)
 #define pgprot_noncached pgprot_noncached
 
 #if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
-extern pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-				struct page *page, int writable);
+pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags);
 #define arch_make_huge_pte arch_make_huge_pte
 static inline unsigned long __pte_default_huge_mask(void)
 {
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 04d8790f6c32..0f49fada2093 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -177,10 +177,8 @@ static pte_t hugepage_shift_to_tte(pte_t entry, unsigned int shift)
 		return sun4u_hugepage_shift_to_tte(entry, shift);
 }
 
-pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-			 struct page *page, int writeable)
+pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags)
 {
-	unsigned int shift = huge_page_shift(hstate_vma(vma));
 	pte_t pte;
 
 	pte = hugepage_shift_to_tte(entry, shift);
@@ -188,7 +186,7 @@ pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
 #ifdef CONFIG_SPARC64
 	/* If this vma has ADI enabled on it, turn on TTE.mcd
 	 */
-	if (vma->vm_flags & VM_SPARC_ADI)
+	if (flags & VM_SPARC_ADI)
 		return pte_mkmcd(pte);
 	else
 		return pte_mknotmcd(pte);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index b92f25ccef58..24f47981c166 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -710,8 +710,8 @@ static inline void arch_clear_hugepage_flags(struct page *page) { }
 #endif
 
 #ifndef arch_make_huge_pte
-static inline pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
-				       struct page *page, int writable)
+static inline pte_t arch_make_huge_pte(pte_t entry, unsigned int shift,
+				       vm_flags_t flags)
 {
 	return entry;
 }
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3db405dea3dc..396285b16dd8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3856,6 +3856,7 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
 				int writable)
 {
 	pte_t entry;
+	unsigned int shift = huge_page_shift(hstate_vma(vma));
 
 	if (writable) {
 		entry = huge_pte_mkwrite(huge_pte_mkdirty(mk_huge_pte(page,
@@ -3866,7 +3867,7 @@ static pte_t make_huge_pte(struct vm_area_struct *vma, struct page *page,
 	}
 	entry = pte_mkyoung(entry);
 	entry = pte_mkhuge(entry);
-	entry = arch_make_huge_pte(entry, vma, page, writable);
+	entry = arch_make_huge_pte(entry, shift, vma->vm_flags);
 
 	return entry;
 }
@@ -5250,10 +5251,11 @@ unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
 		}
 		if (!huge_pte_none(pte)) {
 			pte_t old_pte;
+			unsigned int shift = huge_page_shift(hstate_vma(vma));
 
 			old_pte = huge_ptep_modify_prot_start(vma, address, ptep);
 			pte = pte_mkhuge(huge_pte_modify(old_pte, newprot));
-			pte = arch_make_huge_pte(pte, vma, NULL, 0);
+			pte = arch_make_huge_pte(pte, shift, vma->vm_flags);
 			huge_ptep_modify_prot_commit(vma, address, ptep, old_pte, pte);
 			pages++;
 		}
diff --git a/mm/migrate.c b/mm/migrate.c
index b234c3f3acb7..49ee64cd2ff3 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -226,8 +226,10 @@ static bool remove_migration_pte(struct page *page, struct vm_area_struct *vma,
 
 #ifdef CONFIG_HUGETLB_PAGE
 		if (PageHuge(new)) {
+			unsigned int shift = huge_page_shift(hstate_vma(vma));
+
 			pte = pte_mkhuge(pte);
-			pte = arch_make_huge_pte(pte, vma, new, 0);
+			pte = arch_make_huge_pte(pte, shift, vma->vm_flags);
 			set_huge_pte_at(vma->vm_mm, pvmw.address, pvmw.pte, pte);
 			if (PageAnon(new))
 				hugepage_add_anon_rmap(new, vma, pvmw.address);
-- 
2.25.0



From maz at kernel.org  Wed Apr 28 17:46:56 2021
From: maz at kernel.org (Marc Zyngier)
Date: Wed, 28 Apr 2021 17:46:56 +0100
Subject: [kvm-unit-tests PATCH v1 1/4] arm64: split its-trigger test into
 KVM and TCG variants
In-Reply-To: <87czues90k.fsf@linaro.org>
References: <20210428101844.22656-1-alex.bennee@linaro.org>
 <20210428101844.22656-2-alex.bennee@linaro.org>
 <eaed3c63988513fe2849c2d6f22937af@kernel.org>
 <87fszasjdg.fsf@linaro.org>
 <996210ae-9c63-54ff-1a65-6dbd63da74d2@arm.com>
 <87k0omo4rr.wl-maz@kernel.org> <87czues90k.fsf@linaro.org>
Message-ID: <87fszanypr.wl-maz@kernel.org>

On Wed, 28 Apr 2021 16:37:45 +0100,
Alex Benn?e <alex.bennee at linaro.org> wrote:
> 
> 
> Marc Zyngier <maz at kernel.org> writes:
> 
> > On Wed, 28 Apr 2021 15:00:15 +0100,
> > Alexandru Elisei <alexandru.elisei at arm.com> wrote:
> >> 
> >> I interpret that as that an INVALL guarantees that a change is
> >> visible, but it the change can become visible even without the
> >> INVALL.
> >
> > Yes. Expecting the LPI to be delivered or not in the absence of an
> > invalidate when its configuration has been altered is wrong. The
> > architecture doesn't guarantee anything of the sort.
> 
> Is the underlying hypervisor allowed to invalidate and reload the
> configuration whenever it wants or should it only be driven by the
> guests requests?

The HW can do it at any time. It all depends on whether the RD has
cached this LPI configuration or not. KVM relies on the required
invalidation as a hook to reload the cached state, as it has an
infinite LPI configuration cache, while TCG doesn't have a cache at
all. Both approaches are valid implementations.

> I did consider a more nuanced variant of the test that allowed for a
> delivery pre-inval and a pass for post-inval as long as it had been
> delivered one way or another:
> 
> --8<---------------cut here---------------start------------->8---
> modified   arm/gic.c
> @@ -36,6 +36,7 @@ static struct gic *gic;
>  static int acked[NR_CPUS], spurious[NR_CPUS];
>  static int irq_sender[NR_CPUS], irq_number[NR_CPUS];
>  static cpumask_t ready;
> +static bool under_tcg;
>  
>  static void nr_cpu_check(int nr)
>  {
> @@ -687,6 +688,7 @@ static void test_its_trigger(void)
>  	struct its_collection *col3;
>  	struct its_device *dev2, *dev7;
>  	cpumask_t mask;
> +	bool before, after;
>  
>  	if (its_setup1())
>  		return;
> @@ -734,15 +736,17 @@ static void test_its_trigger(void)
>  	/*
>  	 * re-enable the LPI but willingly do not call invall
>  	 * so the change in config is not taken into account.
> -	 * The LPI should not hit
> +	 * The LPI should not hit. This does however depend on

This first point is *wrong*. From the architecture spec:

<quote>
* A change to the LPI configuration is not guaranteed to be visible
  until an appropriate invalidation operation has completed:

  - If one or more ITS is implemented, invalidation is performed using
    the INV or INVALL command. A SYNC command completes the INV and
    INVALL commands.
</quote>

*not guaranteed* means that it may fire, it may not.

> +	 * implementation defined behaviour - under QEMU TCG emulation
> +	 * it can quite correctly process the event directly.

I really don't see the point in testing IMPDEF behaviours. We should
test for architectural compliance, not for implementation choices.

	M.

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


From dietmar.eggemann at arm.com  Wed Apr 28 17:47:26 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Wed, 28 Apr 2021 18:47:26 +0200
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <CAKfTPtC51eO2mAuW6mHQ-SdznAtfDL3D4UOs4HmnXaPOOCN_cA@mail.gmail.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
 <20210420001844.9116-4-song.bao.hua@hisilicon.com>
 <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>
 <b42c762a287b4360bfa3179a5c7c3e8c@hisilicon.com>
 <CAKfTPtC51eO2mAuW6mHQ-SdznAtfDL3D4UOs4HmnXaPOOCN_cA@mail.gmail.com>
Message-ID: <8b5277d9-e367-566d-6bd1-44ac78d21d3f@arm.com>

On 28/04/2021 15:04, Vincent Guittot wrote:
> On Wed, 28 Apr 2021 at 11:51, Song Bao Hua (Barry Song)
> <song.bao.hua at hisilicon.com> wrote:
>>
>>> -----Original Message-----
>>> From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]

[...]

>>> On 20/04/2021 02:18, Barry Song wrote:

[...]

>> I am really confused. The whole code has only checked if wake_flags
>> has WF_TTWU, it has never checked if sd_domain has SD_BALANCE_WAKE flag.
> 
> look at :
> #define WF_TTWU     0x08 /* Wakeup;            maps to SD_BALANCE_WAKE */
> 
> so  when wake_wide return false, we use the wake_affine mecanism but
> if it's false then we fllback to default mode which looks for:
> if (tmp->flags & sd_flag)
> 
> This means looking for SD_BALANCE_WAKE which is never set
> 
> so sd will stay NULL and you will end up calling select_idle_sibling anyway
> 
>>
>> static int
>> select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
>> {
>>         ...
>>
>>         if (wake_flags & WF_TTWU) {
>>                 record_wakee(p);
>>
>>                 if (sched_energy_enabled()) {
>>                         new_cpu = find_energy_efficient_cpu(p, prev_cpu);
>>                         if (new_cpu >= 0)
>>                                 return new_cpu;
>>                         new_cpu = prev_cpu;
>>                 }
>>
>>                 want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr);
>>         }
>> }
>>
>> And try_to_wake_up() has always set WF_TTWU:
>> static int
>> try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
>> {
>>         cpu = select_task_rq(p, p->wake_cpu, wake_flags | WF_TTWU);
>>         ...
>> }
>>
>> So the change in wake_wide will actually affect the value of want_affine.
>> And I did also see code entered slow path during my benchmark.

Yes, this is happening but IMHO not for wakeups. Check wake_flags for
the tasks which go through `slow path` on your machine. They should have
WF_EXEC or WF_FORK, not WF_TTWU (& WF_SYNC).

>> One issue I mentioned during linaro open discussion is that
>> since I have moved to use cluster size to decide the value
>> of wake_wide, relatively less tasks will make wake_wide()
>> decide to go to slow path, thus, tasks begin to spread to
>> other NUMA,  but actually llc_size might be able to contain
>> those tasks. So a possible model might be:
>> static int wake_wide(struct task_struct *p)
>> {
>>         tasksize < cluster : scan cluster
>>         tasksize > llc      : slow path
>>         tasksize > cluster && tasksize < llc: scan llc
>> }
>>
>> thoughts?

Like Vincent explained, the return value of wake_wide() doesn't matter.
For wakeups you always end up in sis().

[...]


From jbx6244 at gmail.com  Wed Apr 28 17:56:20 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 28 Apr 2021 18:56:20 +0200
Subject: [PATCH v3 07/10] dt-bindings: soc: rockchip: Convert grf.txt to
 YAML
In-Reply-To: <20210428134938.22383-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
 <20210428134938.22383-1-cl@rock-chips.com>
Message-ID: <1f0ddd45-98a0-1e9d-f228-3c58f88fb76d@gmail.com>

Hi Liang,

Check example with:
make ARCH=arm64 dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/soc/rockchip/grf.yaml

Build log:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210428134938.22383-1-cl at rock-chips.com/

On 4/28/21 3:49 PM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> Current dts files with 'grf' nodes are manually verified. In order to
> automate this process grf.txt has to be converted to YAML.

Add new descriptions for:
"rockchip,rk3399-pmugrf", "syscon", "simple-mfd"
"rockchip,rk3399-grf", "syscon", "simple-mfd"

> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>  .../devicetree/bindings/soc/rockchip/grf.yaml | 61 +++++++++++++++++++
>  2 files changed, 61 insertions(+), 61 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> deleted file mode 100644
> index f96511aa3897..000000000000
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -* Rockchip General Register Files (GRF)
> -
> -The general register file will be used to do static set by software, which
> -is composed of many registers for system control.
> -
> -From RK3368 SoCs, the GRF is divided into two sections,
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- PMUGRF, used for always on system
> -
> -On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
> -
> -ON RK3308 SoC, the GRF is divided into four sections:
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- DETECTGRF, used for audio codec system,
> -- COREGRF, used for pvtm,
> -
> -Required Properties:
> -
> -- compatible: GRF should be one of the following:
> -   - "rockchip,px30-grf", "syscon": for px30
> -   - "rockchip,rk3036-grf", "syscon": for rk3036
> -   - "rockchip,rk3066-grf", "syscon": for rk3066
> -   - "rockchip,rk3188-grf", "syscon": for rk3188
> -   - "rockchip,rk3228-grf", "syscon": for rk3228
> -   - "rockchip,rk3288-grf", "syscon": for rk3288
> -   - "rockchip,rk3308-grf", "syscon": for rk3308
> -   - "rockchip,rk3328-grf", "syscon": for rk3328
> -   - "rockchip,rk3368-grf", "syscon": for rk3368
> -   - "rockchip,rk3399-grf", "syscon": for rk3399
> -   - "rockchip,rv1108-grf", "syscon": for rv1108
> -- compatible: DETECTGRF should be one of the following:
> -   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
> -- compatilbe: COREGRF should be one of the following:
> -   - "rockchip,rk3308-core-grf", "syscon": for rk3308
> -- compatible: PMUGRF should be one of the following:
> -   - "rockchip,px30-pmugrf", "syscon": for px30
> -   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> -   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> -- compatible: SGRF should be one of the following:
> -   - "rockchip,rk3288-sgrf", "syscon": for rk3288
> -- compatible: USB2PHYGRF should be one of the following:
> -   - "rockchip,px30-usb2phy-grf", "syscon": for px30
> -   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> -- compatible: USBGRF should be one of the following:
> -   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> -
> -Example: GRF and PMUGRF of RK3399 SoCs
> -
> -	pmugrf: syscon at ff320000 {
> -		compatible = "rockchip,rk3399-pmugrf", "syscon";
> -		reg = <0x0 0xff320000 0x0 0x1000>;
> -	};
> -
> -	grf: syscon at ff770000 {
> -		compatible = "rockchip,rk3399-grf", "syscon";
> -		reg = <0x0 0xff770000 0x0 0x10000>;
> -	};
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> new file mode 100644
> index 000000000000..61ce5b4c9ed0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip General Register Files
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:

> +    oneOf:
> +      - items:

items:

When there are no other combinations then with syscon and simple-mfd
then there's no need for "oneOf".


> +          - enum:
> +              - rockchip,px30-grf
> +              - rockchip,px30-pmugrf
> +              - rockchip,px30-usb2phy-grf
> +              - rockchip,rk3036-grf
> +              - rockchip,rk3066-grf
> +              - rockchip,rk3188-grf
> +              - rockchip,rk3228-grf
> +              - rockchip,rk3288-grf
> +              - rockchip,rk3288-sgrf
> +              - rockchip,rk3308-core-grf
> +              - rockchip,rk3308-detect-grf
> +              - rockchip,rk3308-grf
> +              - rockchip,rk3328-grf
> +              - rockchip,rk3328-usb2phy-grf
> +              - rockchip,rk3368-grf
> +              - rockchip,rk3368-pmugrf
> +              - rockchip,rk3399-grf
> +              - rockchip,rk3399-pmugrf

> +              - rockchip,rk3568-grf
> +              - rockchip,rk3568-pmugrf

Conversion and new properties are two separate actions.
Must add that to the commit message.

> +              - rockchip,rv1108-grf
> +              - rockchip,rv1108-usbgrf
> +          - const: syscon
> +          - const: simple-mfd
> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    pmugrf: syscon at ff320000 {

> +       compatible = "rockchip,rk3399-pmugrf", "syscon";

compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";

> +       reg = <0x0 0xff320000 0x0 0x1000>;

This is for 64 bit, normal examples use 32 bit.

> +    };
> +
> +    grf: syscon at ff770000 {

> +       compatible = "rockchip,rk3399-grf", "syscon";

compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";

> +       reg = <0x0 0xff770000 0x0 0x10000>;

use 32 bit

> +    };
> 


From hsinyi at chromium.org  Wed Apr 28 18:04:13 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 01:04:13 +0800
Subject: [PATCH v5 1/4] gpu: drm: separate panel orientation property creating
 and value setting
Message-ID: <20210428170416.1027484-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
v5:
don't create property in set_panel_orientation.

v4, v3:
create property in dsi driver and set value in panel.

v2:
create property in connector init
https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsinyi at chromium.org/

v1:
set panel orientation in dsi driver
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
---
 drivers/gpu/drm/drm_connector.c | 58 ++++++++++++++++++++++++---------
 include/drm/drm_connector.h     |  2 ++
 2 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..7189baaabf41 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will return an error.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2205,19 +2205,11 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (WARN_ON(!prop))
+		return -EINVAL;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2225,7 +2217,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk -
  *	set the connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2252,6 +2244,40 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..4396c1c4a5db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 28 18:04:14 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 01:04:14 +0800
Subject: [PATCH v5 2/4] drm/mediatek: init panel orientation property
In-Reply-To: <20210428170416.1027484-1-hsinyi@chromium.org>
References: <20210428170416.1027484-1-hsinyi@chromium.org>
Message-ID: <20210428170416.1027484-2-hsinyi@chromium.org>

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..9da1fd649131 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -964,6 +964,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 28 18:04:15 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 01:04:15 +0800
Subject: [PATCH v5 3/4] drm/i915: init panel orientation property
In-Reply-To: <20210428170416.1027484-1-hsinyi@chromium.org>
References: <20210428170416.1027484-1-hsinyi@chromium.org>
Message-ID: <20210428170416.1027484-3-hsinyi@chromium.org>

Creating the panel orientation property first since we separate the
property creating and value setting.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/i915/display/icl_dsi.c  | 1 +
 drivers/gpu/drm/i915/display/intel_dp.c | 1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c
index 9282978060b0..162fb3cf0f5a 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1903,6 +1903,7 @@ static void icl_dsi_add_properties(struct intel_connector *connector)
 
 	connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
 
+	drm_connector_attach_scaling_mode_property(&connector->base);
 	drm_connector_set_panel_orientation_with_quirk(&connector->base,
 				intel_dsi_get_panel_orientation(connector),
 				connector->panel.fixed_mode->hdisplay,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index a5231ac3443a..f1d664e5abb2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5263,6 +5263,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	intel_panel_setup_backlight(connector, pipe);
 
 	if (fixed_mode) {
+		drm_connector_init_panel_orientation_property(connector);
 		drm_connector_set_panel_orientation_with_quirk(connector,
 				dev_priv->vbt.orientation,
 				fixed_mode->hdisplay, fixed_mode->vdisplay);
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 9bee99fe5495..853855482af1 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1632,6 +1632,7 @@ static void vlv_dsi_add_properties(struct intel_connector *connector)
 
 		connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
 
+		drm_connector_init_panel_orientation_property(&connector->base);
 		drm_connector_set_panel_orientation_with_quirk(
 				&connector->base,
 				intel_dsi_get_panel_orientation(connector),
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Wed Apr 28 18:04:16 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 01:04:16 +0800
Subject: [PATCH v5 4/4] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210428170416.1027484-1-hsinyi@chromium.org>
References: <20210428170416.1027484-1-hsinyi@chromium.org>
Message-ID: <20210428170416.1027484-4-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From catalin.marinas at arm.com  Wed Apr 28 18:07:08 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 28 Apr 2021 18:07:08 +0100
Subject: [PATCH v11 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210416154309.22129-3-steven.price@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-3-steven.price@arm.com>
Message-ID: <20210428170705.GB4022@arm.com>

On Fri, Apr 16, 2021 at 04:43:05PM +0100, Steven Price wrote:
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 77cb2d28f2a4..5f8e165ea053 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -879,6 +879,26 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	if (vma_pagesize == PAGE_SIZE && !force_pte)
>  		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>  							   &pfn, &fault_ipa);
> +
> +	if (fault_status != FSC_PERM && kvm_has_mte(kvm) && !device &&
> +	    pfn_valid(pfn)) {

In the current implementation, device == !pfn_valid(), so we could skip
the latter check.

> +		/*
> +		 * VM will be able to see the page's tags, so we must ensure
> +		 * they have been initialised. if PG_mte_tagged is set, tags
> +		 * have already been initialised.
> +		 */
> +		unsigned long i, nr_pages = vma_pagesize >> PAGE_SHIFT;
> +		struct page *page = pfn_to_online_page(pfn);
> +
> +		if (!page)
> +			return -EFAULT;

I think that's fine, though maybe adding a comment that otherwise it
would be mapped at stage 2 as Normal Cacheable and we cannot guarantee
that the memory supports MTE tags.

> +
> +		for (i = 0; i < nr_pages; i++, page++) {
> +			if (!test_and_set_bit(PG_mte_tagged, &page->flags))
> +				mte_clear_page_tags(page_address(page));
> +		}
> +	}
> +
>  	if (writable)
>  		prot |= KVM_PGTABLE_PROT_W;

I probably asked already but is the only way to map a standard RAM page
(not device) in stage 2 via the fault handler? One case I had in mind
was something like get_user_pages() but it looks like that one doesn't
call set_pte_at_notify(). There are a few other places where
set_pte_at_notify() is called and these may happen before we got a
chance to fault on stage 2, effectively populating the entry (IIUC). If
that's an issue, we could move the above loop and check closer to the
actual pte setting like kvm_pgtable_stage2_map().

While the set_pte_at() race on the page flags is somewhat clearer, we
may still have a race here with the VMM's set_pte_at() if the page is
mapped as tagged. KVM has its own mmu_lock but it wouldn't be held when
handling the VMM page tables (well, not always, see below).

gfn_to_pfn_prot() ends up calling get_user_pages*(). At least the slow
path (hva_to_pfn_slow()) ends up with FOLL_TOUCH in gup and the VMM pte
would be set, tags cleared (if PROT_MTE) before the stage 2 pte. I'm not
sure whether get_user_page_fast_only() does the same.

The race with an mprotect(PROT_MTE) in the VMM is fine I think as the
KVM mmu notifier is invoked before set_pte_at() and racing with another
user_mem_abort() is serialised by the KVM mmu_lock. The subsequent
set_pte_at() would see the PG_mte_tagged set either by the current CPU
or by the one it was racing with.

-- 
Catalin


From ezequiel at collabora.com  Wed Apr 28 18:09:40 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Wed, 28 Apr 2021 14:09:40 -0300
Subject: [PATCH 70/78] media: rga-buf: use pm_runtime_resume_and_get()
In-Reply-To: <d81e6df2d1a77dc70a4172b77fc15576010e05b3.1619191723.git.mchehab+huawei@kernel.org>
References: <cover.1619191723.git.mchehab+huawei@kernel.org>
 <d81e6df2d1a77dc70a4172b77fc15576010e05b3.1619191723.git.mchehab+huawei@kernel.org>
Message-ID: <a56aee6c6e80cc0166cec9b0a331873e9651df0a.camel@collabora.com>

On Sat, 2021-04-24 at 08:45 +0200, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>


Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>

Thanks,

> ---
> ?drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
> ?1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
> index bf9a75b75083..81508ed5abf3 100644
> --- a/drivers/media/platform/rockchip/rga/rga-buf.c
> +++ b/drivers/media/platform/rockchip/rga/rga-buf.c
> @@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
> ????????struct rockchip_rga *rga = ctx->rga;
> ????????int ret;
> ?
> -???????ret = pm_runtime_get_sync(rga->dev);
> +???????ret = pm_runtime_resume_and_get(rga->dev);
> ????????if (ret < 0) {
> -???????????????pm_runtime_put_noidle(rga->dev);
> ????????????????rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
> ????????????????return ret;
> ????????}




From ezequiel at collabora.com  Wed Apr 28 18:10:41 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Wed, 28 Apr 2021 14:10:41 -0300
Subject: [PATCH v3 11/79] media: rga-buf: use pm_runtime_resume_and_get()
In-Reply-To: <a9099f1ffc537e5f997cb260a175715892387c5a.1619519080.git.mchehab+huawei@kernel.org>
References: <cover.1619519080.git.mchehab+huawei@kernel.org>
 <a9099f1ffc537e5f997cb260a175715892387c5a.1619519080.git.mchehab+huawei@kernel.org>
Message-ID: <00113d54d30be862195b736a5e5026eab8f6b5ec.camel@collabora.com>

On Tue, 2021-04-27 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Sorry, I just replied to the wrong patch version.
Again:

Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>

Thanks,
Ezequiel

> ---
> ?drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
> ?drivers/media/platform/rockchip/rga/rga.c???? | 4 +++-
> ?2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
> index bf9a75b75083..81508ed5abf3 100644
> --- a/drivers/media/platform/rockchip/rga/rga-buf.c
> +++ b/drivers/media/platform/rockchip/rga/rga-buf.c
> @@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
> ????????struct rockchip_rga *rga = ctx->rga;
> ????????int ret;
> ?
> -???????ret = pm_runtime_get_sync(rga->dev);
> +???????ret = pm_runtime_resume_and_get(rga->dev);
> ????????if (ret < 0) {
> -???????????????pm_runtime_put_noidle(rga->dev);
> ????????????????rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
> ????????????????return ret;
> ????????}
> diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
> index 9d122429706e..bf3fd71ec3af 100644
> --- a/drivers/media/platform/rockchip/rga/rga.c
> +++ b/drivers/media/platform/rockchip/rga/rga.c
> @@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
> ????????????????goto unreg_video_dev;
> ????????}
> ?
> -???????pm_runtime_get_sync(rga->dev);
> +???????ret = pm_runtime_resume_and_get(rga->dev);
> +???????if (ret < 0)
> +???????????????goto unreg_video_dev;
> ?
> ????????rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
> ????????rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;




From ezequiel at collabora.com  Wed Apr 28 18:11:44 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Wed, 28 Apr 2021 14:11:44 -0300
Subject: [PATCH v4 57/79] media: rockchip/rga: use
 pm_runtime_resume_and_get()
In-Reply-To: <cf0f0cb266c8b552f03583590a3b02a56f751c79.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <cf0f0cb266c8b552f03583590a3b02a56f751c79.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <2615f6be602573869e979d4d763155a86332c845.camel@collabora.com>

On Wed, 2021-04-28 at 16:52 +0200, Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>

Ugh, sigh... OK, there was a v4. Sorry for the noise!

Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>

> ---
> ?drivers/media/platform/rockchip/rga/rga-buf.c | 3 +--
> ?drivers/media/platform/rockchip/rga/rga.c???? | 4 +++-
> ?2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rga/rga-buf.c b/drivers/media/platform/rockchip/rga/rga-buf.c
> index bf9a75b75083..81508ed5abf3 100644
> --- a/drivers/media/platform/rockchip/rga/rga-buf.c
> +++ b/drivers/media/platform/rockchip/rga/rga-buf.c
> @@ -79,9 +79,8 @@ static int rga_buf_start_streaming(struct vb2_queue *q, unsigned int count)
> ????????struct rockchip_rga *rga = ctx->rga;
> ????????int ret;
> ?
> -???????ret = pm_runtime_get_sync(rga->dev);
> +???????ret = pm_runtime_resume_and_get(rga->dev);
> ????????if (ret < 0) {
> -???????????????pm_runtime_put_noidle(rga->dev);
> ????????????????rga_buf_return_buffers(q, VB2_BUF_STATE_QUEUED);
> ????????????????return ret;
> ????????}
> diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
> index 9d122429706e..bf3fd71ec3af 100644
> --- a/drivers/media/platform/rockchip/rga/rga.c
> +++ b/drivers/media/platform/rockchip/rga/rga.c
> @@ -866,7 +866,9 @@ static int rga_probe(struct platform_device *pdev)
> ????????????????goto unreg_video_dev;
> ????????}
> ?
> -???????pm_runtime_get_sync(rga->dev);
> +???????ret = pm_runtime_resume_and_get(rga->dev);
> +???????if (ret < 0)
> +???????????????goto unreg_video_dev;
> ?
> ????????rga->version.major = (rga_read(rga, RGA_VERSION_INFO) >> 24) & 0xFF;
> ????????rga->version.minor = (rga_read(rga, RGA_VERSION_INFO) >> 20) & 0x0F;




From catalin.marinas at arm.com  Wed Apr 28 18:28:47 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 28 Apr 2021 18:28:47 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210423205159.830854-1-morbo@google.com>
References: <20210423205159.830854-1-morbo@google.com>
Message-ID: <20210428172847.GC4022@arm.com>

On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> The arm64 assembler in binutils 2.32 and above generates a program
> property note in a note section, .note.gnu.property, to encode used x86
> ISAs and features. But the kernel linker script only contains a single
> NOTE segment:
> 
>   PHDRS
>   {
>     text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
>     dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
>     note    PT_NOTE    FLAGS(4);               /* PF_R */
>   }
> 
> The NOTE segment generated by the vDSO linker script is aligned to 4 bytes.
> But the .note.gnu.property section must be aligned to 8 bytes on arm64.
> 
>   $ readelf -n vdso64.so
> 
>   Displaying notes found in: .note
>     Owner                Data size      Description
>     Linux                0x00000004     Unknown note type: (0x00000000)
>      description data: 06 00 00 00
>   readelf: Warning: note with invalid namesz and/or descsz found at offset 0x20
>   readelf: Warning:  type: 0x78, namesize: 0x00000100, descsize: 0x756e694c, alignment: 8
> 
> Since the note.gnu.property section in the vDSO is not checked by the
> dynamic linker, discard the .note.gnu.property sections in the vDSO.
> 
> Similar to commit 4caffe6a28d31 ("x86/vdso: Discard .note.gnu.property
> sections in vDSO"), but for arm64.

Can we not instead fix the linker script to preserve the
.note.gnu.property, correctly aligned? It doesn't take much space and
while we don't use it now, it has the BTI information about the binary.

Cc'ing a few others who were involved in the BTI support.

> Signed-off-by: Bill Wendling <morbo at google.com>
> ---
>  arch/arm64/kernel/vdso/vdso.lds.S | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
> index 61dbb4c838ef..a5e61e09ea92 100644
> --- a/arch/arm64/kernel/vdso/vdso.lds.S
> +++ b/arch/arm64/kernel/vdso/vdso.lds.S
> @@ -31,6 +31,13 @@ SECTIONS
>  	.gnu.version_d	: { *(.gnu.version_d) }
>  	.gnu.version_r	: { *(.gnu.version_r) }
>  
> +	/*
> +	 * Discard .note.gnu.property sections which are unused and have
> +	 * different alignment requirement from vDSO note sections.
> +	 */
> +	/DISCARD/	: {
> +		*(.note.GNU-stack .note.gnu.property)
> +	}
>  	.note		: { *(.note.*) }		:text	:note
>  
>  	. = ALIGN(16);
> @@ -48,7 +55,6 @@ SECTIONS
>  	PROVIDE(end = .);
>  
>  	/DISCARD/	: {
> -		*(.note.GNU-stack)
>  		*(.data .data.* .gnu.linkonce.d.* .sdata*)
>  		*(.bss .sbss .dynbss .dynsbss)
>  		*(.eh_frame .eh_frame_hdr)
> -- 
> 2.31.1.498.g6c1eba8ee3d-goog

-- 
Catalin


From broonie at kernel.org  Wed Apr 28 18:40:10 2021
From: broonie at kernel.org (Mark Brown)
Date: Wed, 28 Apr 2021 18:40:10 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210428172847.GC4022@arm.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
Message-ID: <20210428174010.GA4593@sirena.org.uk>

On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:

> > Since the note.gnu.property section in the vDSO is not checked by the
> > dynamic linker, discard the .note.gnu.property sections in the vDSO.

> Can we not instead fix the linker script to preserve the
> .note.gnu.property, correctly aligned? It doesn't take much space and
> while we don't use it now, it has the BTI information about the binary.

> Cc'ing a few others who were involved in the BTI support.

Not just BTI, we also flag PAC usage in there too and could add other
extensions going forwards.  While the note isn't actively used by
anything right now due to the kernel mapping the vDSO prior to userspace
starting it is part of the ABI and something could end up wanting to use
it and getting confused if it's not there.  It would be much better to
fix the alignment issue.
-------------- 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/20210428/de55caeb/attachment.sig>

From clabbe at baylibre.com  Wed Apr 28 18:48:30 2021
From: clabbe at baylibre.com (Corentin Labbe)
Date: Wed, 28 Apr 2021 17:48:30 +0000
Subject: [PATCH] ARM: dts: gemini: rename mdio to the right name
Message-ID: <20210428174830.3691034-1-clabbe@baylibre.com>

ethernet-phy is not the right name for mdio, fix it.

Signed-off-by: Corentin Labbe <clabbe at baylibre.com>
---
 arch/arm/boot/dts/gemini-dlink-dns-313.dts | 2 +-
 arch/arm/boot/dts/gemini-nas4220b.dts      | 2 +-
 arch/arm/boot/dts/gemini-rut1xx.dts        | 2 +-
 arch/arm/boot/dts/gemini-wbd111.dts        | 2 +-
 arch/arm/boot/dts/gemini-wbd222.dts        | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/gemini-dlink-dns-313.dts b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
index 1b2bb3beaccb..f5313f6be956 100644
--- a/arch/arm/boot/dts/gemini-dlink-dns-313.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dns-313.dts
@@ -140,7 +140,7 @@ map1 {
 		};
 	};
 
-	mdio0: ethernet-phy {
+	mdio0: mdio {
 		compatible = "virtual,mdio-gpio";
 		/* Uses MDC and MDIO */
 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index 77776c371ce0..da4ce90eec22 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -62,7 +62,7 @@ led-green-os {
 		};
 	};
 
-	mdio0: ethernet-phy {
+	mdio0: mdio {
 		compatible = "virtual,mdio-gpio";
 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
 			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts b/arch/arm/boot/dts/gemini-rut1xx.dts
index f8826a3b774f..6cea953150b5 100644
--- a/arch/arm/boot/dts/gemini-rut1xx.dts
+++ b/arch/arm/boot/dts/gemini-rut1xx.dts
@@ -56,7 +56,7 @@ led-power {
 		};
 	};
 
-	mdio0: ethernet-phy {
+	mdio0: mdio {
 		compatible = "virtual,mdio-gpio";
 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
 			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
diff --git a/arch/arm/boot/dts/gemini-wbd111.dts b/arch/arm/boot/dts/gemini-wbd111.dts
index 4f3e097d784b..00ea66f4788f 100644
--- a/arch/arm/boot/dts/gemini-wbd111.dts
+++ b/arch/arm/boot/dts/gemini-wbd111.dts
@@ -68,7 +68,7 @@ led-greeb-l3 {
 		};
 	};
 
-	mdio0: ethernet-phy {
+	mdio0: mdio {
 		compatible = "virtual,mdio-gpio";
 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
 			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
diff --git a/arch/arm/boot/dts/gemini-wbd222.dts b/arch/arm/boot/dts/gemini-wbd222.dts
index e6fe59ee65b6..6dfb61b8d133 100644
--- a/arch/arm/boot/dts/gemini-wbd222.dts
+++ b/arch/arm/boot/dts/gemini-wbd222.dts
@@ -67,7 +67,7 @@ led-green-l3 {
 		};
 	};
 
-	mdio0: ethernet-phy {
+	mdio0: mdio {
 		compatible = "virtual,mdio-gpio";
 		gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>, /* MDC */
 			<&gpio0 21 GPIO_ACTIVE_HIGH>; /* MDIO */
-- 
2.26.3



From clabbe at baylibre.com  Wed Apr 28 18:55:03 2021
From: clabbe at baylibre.com (Corentin Labbe)
Date: Wed, 28 Apr 2021 17:55:03 +0000
Subject: [PATCH] ARM: dts: gemini: rename to nand-controller
Message-ID: <20210428175503.3692090-1-clabbe@baylibre.com>

We must use nand-controller instead of flash.

Signed-off-by: Corentin Labbe <clabbe at baylibre.com>
---
 arch/arm/boot/dts/gemini-dlink-dir-685.dts | 2 +-
 arch/arm/boot/dts/gemini-nas4220b.dts      | 2 +-
 arch/arm/boot/dts/gemini-rut1xx.dts        | 3 +--
 arch/arm/boot/dts/gemini-sl93512r.dts      | 2 +-
 arch/arm/boot/dts/gemini-sq201.dts         | 2 +-
 arch/arm/boot/dts/gemini-wbd111.dts        | 2 +-
 arch/arm/boot/dts/gemini-wbd222.dts        | 2 +-
 arch/arm/boot/dts/gemini.dtsi              | 2 +-
 8 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
index cc39289e99dd..5e205bb53e5a 100644
--- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -281,7 +281,7 @@ phy4: phy at 4 {
 	};
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			/*
 			 * Flash access collides with the Chip Enable signal for
 			 * the display panel, that reuse the parallel flash Chip
diff --git a/arch/arm/boot/dts/gemini-nas4220b.dts b/arch/arm/boot/dts/gemini-nas4220b.dts
index 43c45f7e1e0a..1e2d3162d9c1 100644
--- a/arch/arm/boot/dts/gemini-nas4220b.dts
+++ b/arch/arm/boot/dts/gemini-nas4220b.dts
@@ -76,7 +76,7 @@ phy0: ethernet-phy at 1 {
 	};
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			/* 16MB of flash */
 			reg = <0x30000000 0x01000000>;
diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts b/arch/arm/boot/dts/gemini-rut1xx.dts
index 08091d2a64e1..f8826a3b774f 100644
--- a/arch/arm/boot/dts/gemini-rut1xx.dts
+++ b/arch/arm/boot/dts/gemini-rut1xx.dts
@@ -70,7 +70,7 @@ phy0: ethernet-phy at 1 {
 	};
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			/* 8MB of flash */
 			reg = <0x30000000 0x00800000>;
@@ -124,7 +124,6 @@ ethernet-port at 1 {
 				/* Not used in this platform */
 			};
 		};
-
 		usb at 68000000 {
 			status = "okay";
 		};
diff --git a/arch/arm/boot/dts/gemini-sl93512r.dts b/arch/arm/boot/dts/gemini-sl93512r.dts
index a0916d3c1059..995be04425b7 100644
--- a/arch/arm/boot/dts/gemini-sl93512r.dts
+++ b/arch/arm/boot/dts/gemini-sl93512r.dts
@@ -138,7 +138,7 @@ fixed-link {
 
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			/* 16MB of flash */
 			reg = <0x30000000 0x01000000>;
diff --git a/arch/arm/boot/dts/gemini-sq201.dts b/arch/arm/boot/dts/gemini-sq201.dts
index 0c6e6d35bfaa..df6146aaff4b 100644
--- a/arch/arm/boot/dts/gemini-sq201.dts
+++ b/arch/arm/boot/dts/gemini-sq201.dts
@@ -123,7 +123,7 @@ fixed-link {
 
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			pinctrl-names = "enabled", "disabled";
 			pinctrl-0 = <&pflash_default_pins>;
diff --git a/arch/arm/boot/dts/gemini-wbd111.dts b/arch/arm/boot/dts/gemini-wbd111.dts
index 0c47b2b9811c..f253743b1c55 100644
--- a/arch/arm/boot/dts/gemini-wbd111.dts
+++ b/arch/arm/boot/dts/gemini-wbd111.dts
@@ -82,7 +82,7 @@ phy0: ethernet-phy at 1 {
 	};
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			/* 8MB of flash */
 			reg = <0x30000000 0x00800000>;
diff --git a/arch/arm/boot/dts/gemini-wbd222.dts b/arch/arm/boot/dts/gemini-wbd222.dts
index 52b4dbc0c072..76b6faaf806e 100644
--- a/arch/arm/boot/dts/gemini-wbd222.dts
+++ b/arch/arm/boot/dts/gemini-wbd222.dts
@@ -86,7 +86,7 @@ phy1: ethernet-phy at 3 {
 	};
 
 	soc {
-		flash at 30000000 {
+		nand-controller at 30000000 {
 			status = "okay";
 			/* 8MB of flash */
 			reg = <0x30000000 0x00800000>;
diff --git a/arch/arm/boot/dts/gemini.dtsi b/arch/arm/boot/dts/gemini.dtsi
index 38671523dec5..5c8c5179c944 100644
--- a/arch/arm/boot/dts/gemini.dtsi
+++ b/arch/arm/boot/dts/gemini.dtsi
@@ -16,7 +16,7 @@ soc {
 		compatible = "simple-bus";
 		interrupt-parent = <&intcon>;
 
-		flash at 30000000 {
+		nand: nand-controller at 30000000 {
 			compatible = "cortina,gemini-flash", "cfi-flash";
 			syscon = <&syscon>;
 			pinctrl-names = "default";
-- 
2.26.3



From sandberg at mailfence.com  Wed Apr 28 19:12:07 2021
From: sandberg at mailfence.com (Mauri Sandberg)
Date: Wed, 28 Apr 2021 21:12:07 +0300
Subject: [PATCH] ARM: orion5x: Add missing config symbol
Message-ID: <20210428181207.11994-1-sandberg@mailfence.com>

MVEBU_DEVBUS depends on MEMORY and, without the latter, turning on
ARCH_ORION5x is left a little bit crippled.

Adding MEMORY to the symbols ARCH_ORION5x selects fixes the situation.

Signed-off-by: Mauri Sandberg <sandberg at mailfence.com>
---
 arch/arm/mach-orion5x/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index e94a61901ffd..86a5308cca3d 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -4,6 +4,7 @@ menuconfig ARCH_ORION5X
 	depends on MMU && ARCH_MULTI_V5
 	select CPU_FEROCEON
 	select GPIOLIB
+	select MEMORY
 	select MVEBU_MBUS
 	select FORCE_PCI
 	select PHYLIB if NETDEVICES

base-commit: 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
-- 
2.25.1



From jbx6244 at gmail.com  Wed Apr 28 19:25:17 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Wed, 28 Apr 2021 20:25:17 +0200
Subject: [PATCH v3 09/10] arm64: dts: rockchip: add core dtsi for RK3568
 SoC
In-Reply-To: <20210428135002.22528-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
 <20210428135002.22528-1-cl@rock-chips.com>
Message-ID: <a6b9daab-c3db-15ba-2944-5cccf0434b08@gmail.com>

Hi,

Question for rob+dt or others.

===

1: Given error:

/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dt.yaml: sram at 10f000:
sram at 0:compatible: None of ['arm,scmi-shmem'] are valid under the given
schema
	From schema: /Documentation/devicetree/bindings/sram/sram.yaml

===
2: Given incorrect sram Example arm,scmi.txt that is in need to convert to
YAML:

sram at 50000000 {
	compatible = "mmio-sram";
	reg = <0x0 0x50000000 0x0 0x10000>;

	#address-cells = <1>;
	#size-cells = <1>;
	ranges = <0 0x0 0x50000000 0x10000>;

	cpu_scp_lpri: scp-shmem at 0 {
===
sram at 0
===
		compatible = "arm,scmi-shmem";
		reg = <0x0 0x200>;
	};

	cpu_scp_hpri: scp-shmem at 200 {
===
sram at 200
===
		compatible = "arm,scmi-shmem";
		reg = <0x200 0x200>;
	};
};

===

Should "arm,scmi-shmem" also be added to sram.yaml ??
What to do with "arm,scmi.txt" then ??


patternProperties:
  "^([a-z]*-)?sram(-section)?@[a-f0-9]+$":
    type: object
    description:
      Each child of the sram node specifies a region of reserved memory.
    properties:
      compatible:
        description:
          Should contain a vendor specific string in the form
          <vendor>,[<device>-]<usage>
        contains:
          enum:
            - allwinner,sun4i-a10-sram-a3-a4
            - allwinner,sun4i-a10-sram-c1
            - allwinner,sun4i-a10-sram-d
            - allwinner,sun9i-a80-smp-sram
            - allwinner,sun50i-a64-sram-c
            - amlogic,meson8-ao-arc-sram
            - amlogic,meson8b-ao-arc-sram
            - amlogic,meson8-smp-sram
            - amlogic,meson8b-smp-sram
            - amlogic,meson-gxbb-scp-shmem
            - amlogic,meson-axg-scp-shmem
===
            - arm,scmi-shmem
===
            - renesas,smp-sram
            - rockchip,rk3066-smp-sram
            - samsung,exynos4210-sysram
            - samsung,exynos4210-sysram-ns
            - socionext,milbeaut-smp-sram

====

Given missing YAML documents for:

operating-points-v2
arm,pl330, arm,primecell
arm,scmi-smc
arm,scmi-shmem
rockchip,rk3568-pinctrl

For sort order and dtbs_check and for what's worth and fixed:

Reviewed-by: Johan Jonker <jbx6244 at gmail.com>

On 4/28/21 3:50 PM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> RK3568 is a high-performance and low power quad-core application processor
> designed for personal mobile internet device and AIoT equipment. This patch
> add basic core dtsi file for it.
> 
> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> enalbe a special high-performance PLL when high frequency is required. The
> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> 
>     cpu0: cpu at 0 {
>         device_type = "cpu";
>         compatible = "arm,cortex-a55";
>         reg = <0x0 0x0>;
>         clocks = <&scmi_clk 0>;
>     };
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---

[..]

> diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> new file mode 100644
> index 000000000000..7983fa13d93f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> @@ -0,0 +1,779 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include <dt-bindings/clock/rk3568-cru.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,boot-mode.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {
> +	compatible = "rockchip,rk3568";
> +
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		gpio0 = &gpio0;
> +		gpio1 = &gpio1;
> +		gpio2 = &gpio2;
> +		gpio3 = &gpio3;
> +		gpio4 = &gpio4;
> +		i2c0 = &i2c0;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +		i2c4 = &i2c4;
> +		i2c5 = &i2c5;
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +		serial5 = &uart5;
> +		serial6 = &uart6;
> +		serial7 = &uart7;
> +		serial8 = &uart8;
> +		serial9 = &uart9;
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x0>;
> +			clocks = <&scmi_clk 0>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu1: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x100>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu2: cpu at 200 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x200>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +
> +		cpu3: cpu at 300 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a55";
> +			reg = <0x0 0x300>;
> +			enable-method = "psci";
> +			operating-points-v2 = <&cpu0_opp_table>;
> +		};
> +	};
> +
> +	cpu0_opp_table: cpu0-opp-table {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-408000000 {
> +			opp-hz = /bits/ 64 <408000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +			clock-latency-ns = <40000>;
> +		};
> +
> +		opp-600000000 {
> +			opp-hz = /bits/ 64 <600000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +
> +		opp-816000000 {
> +			opp-hz = /bits/ 64 <816000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +			opp-suspend;
> +		};
> +
> +		opp-1104000000 {
> +			opp-hz = /bits/ 64 <1104000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +
> +		opp-1416000000 {
> +			opp-hz = /bits/ 64 <1416000000>;
> +			opp-microvolt = <900000 900000 1150000>;
> +		};
> +
> +		opp-1608000000 {
> +			opp-hz = /bits/ 64 <1608000000>;
> +			opp-microvolt = <975000 975000 1150000>;
> +		};
> +
> +		opp-1800000000 {
> +			opp-hz = /bits/ 64 <1800000000>;
> +			opp-microvolt = <1050000 1050000 1150000>;
> +		};
> +
> +		opp-1992000000 {
> +			opp-hz = /bits/ 64 <1992000000>;
> +			opp-microvolt = <1150000 1150000 1150000>;
> +		};
> +	};
> +
> +	firmware {
> +		scmi: scmi {
> +			compatible = "arm,scmi-smc";
> +			arm,smc-id = <0x82000010>;
> +			shmem = <&scmi_shmem>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			scmi_clk: protocol at 14 {
> +				reg = <0x14>;
> +				#clock-cells = <1>;
> +			};
> +		};

> +

Remove empty line.

> +	};
> +
> +	pmu {
> +		compatible = "arm,cortex-a55-pmu";
> +		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,no-tick-in-suspend;
> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +		#clock-cells = <0>;
> +	};
> +
> +	xin32k: xin32k {
> +		compatible = "fixed-clock";
> +		clock-frequency = <32768>;
> +		clock-output-names = "xin32k";
> +		pinctrl-0 = <&clk32k_out0>;
> +		pinctrl-names = "default";
> +		#clock-cells = <0>;
> +	};
> +
> +	sram at 10f000 {
> +		compatible = "mmio-sram";
> +		reg = <0x0 0x0010f000 0x0 0x100>;

> +

Remove empty line.

> +		#address-cells = <1>;
> +		#size-cells = <1>;

> +		ranges = <0 0x0 0x0010f000 0x100>;

Is this correct ?

> +
> +		scmi_shmem: sram at 0 {
> +			compatible = "arm,scmi-shmem";
> +			reg = <0x0 0x100>;
> +		};
> +	};
> +
> +	gic: interrupt-controller at fd400000 {
> +		compatible = "arm,gic-v3";
> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		mbi-alias = <0x0 0xfd400000>;
> +		mbi-ranges = <296 24>;
> +		msi-controller;
> +	};
> +
> +	pmugrf: syscon at fdc20000 {
> +		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
> +		reg = <0x0 0xfdc20000 0x0 0x10000>;
> +	};
> +
> +	grf: syscon at fdc60000 {
> +		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
> +		reg = <0x0 0xfdc60000 0x0 0x10000>;
> +	};
> +
> +	pmucru: clock-controller at fdd00000 {
> +		compatible = "rockchip,rk3568-pmucru";
> +		reg = <0x0 0xfdd00000 0x0 0x1000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	cru: clock-controller at fdd20000 {
> +		compatible = "rockchip,rk3568-cru";
> +		reg = <0x0 0xfdd20000 0x0 0x1000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	i2c0: i2c at fdd40000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfdd40000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	uart0: serial at fdd50000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfdd50000 0x0 0x100>;
> +		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 0>, <&dmac0 1>;
> +		pinctrl-0 = <&uart0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	pwm0: pwm at fdd70000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70000 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm0m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm1: pwm at fdd70010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70010 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm1m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm2: pwm at fdd70020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70020 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm2m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm3: pwm at fdd70030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfdd70030 0x0 0x10>;
> +		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm3_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	sdmmc2: mmc at fe000000 {
> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe000000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
> +			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC2>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +
> +	sdmmc0: mmc at fe2b0000 {
> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe2b0000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
> +			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC0>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +
> +	sdmmc1: mmc at fe2c0000 {
> +		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
> +		reg = <0x0 0xfe2c0000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
> +			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
> +		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
> +		fifo-depth = <0x100>;
> +		max-frequency = <150000000>;
> +		resets = <&cru SRST_SDMMC1>;
> +		reset-names = "reset";
> +		status = "disabled";
> +	};
> +

> +	sdhci: mmc at fe310000 {

mmc at fe310000: rockchip,txclk-tapnum: missing size tag in [[8]]

>From snps,dwcmshc-sdhci.yaml:

  rockchip,txclk-tapnum:
===
    maxItems: 1
    default: 8

Add default 8.
There's no maxItems specified in snps,dwcmshc-sdhci.yaml.
===
    description: Specify the number of delay for tx sampling.
    $ref: /schemas/types.yaml#/definitions/uint8
===

#define DLL_TXCLK_TAPNUM_DEFAULT	0x8


	if (of_property_read_u8(mmc_dev(host->mmc)->of_node,
"rockchip,txclk-tapnum",
				&priv->txclk_tapnum))

		priv->txclk_tapnum = DLL_TXCLK_TAPNUM_DEFAULT;
===

+&sdhci {
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;

+	rockchip,txclk-tapnum = <0x8>;

Remove.
Default is already 8.

+	status = "okay";
+};


> +		compatible = "rockchip,rk3568-dwcmshc";
> +		reg = <0x0 0xfe310000 0x0 0x10000>;
> +		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
> +		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
> +		assigned-clock-rates = <200000000>, <24000000>;
> +		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
> +			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
> +			 <&cru TCLK_EMMC>;
> +		clock-names = "core", "bus", "axi", "block", "timer";
> +		status = "disabled";
> +	};
> +
> +	dmac0: dmac at fe530000 {
> +		compatible = "arm,pl330", "arm,primecell";
> +		reg = <0x0 0xfe530000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,pl330-periph-burst;
> +		clocks = <&cru ACLK_BUS>;
> +		clock-names = "apb_pclk";
> +		#dma-cells = <1>;
> +	};
> +
> +	dmac1: dmac at fe550000 {
> +		compatible = "arm,pl330", "arm,primecell";
> +		reg = <0x0 0xfe550000 0x0 0x4000>;
> +		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
> +			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> +		arm,pl330-periph-burst;
> +		clocks = <&cru ACLK_BUS>;
> +		clock-names = "apb_pclk";
> +		#dma-cells = <1>;
> +	};
> +
> +	i2c1: i2c at fe5a0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5a0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c1_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c2: i2c at fe5b0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5b0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c2m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c3: i2c at fe5c0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5c0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c3m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c4: i2c at fe5d0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5d0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c4m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	i2c5: i2c at fe5e0000 {
> +		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
> +		reg = <0x0 0xfe5e0000 0x0 0x1000>;
> +		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
> +		clock-names = "i2c", "pclk";
> +		pinctrl-0 = <&i2c5m0_xfer>;
> +		pinctrl-names = "default";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
> +	wdt: watchdog at fe600000 {
> +		compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
> +		reg = <0x0 0xfe600000 0x0 0x100>;
> +		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
> +		clock-names = "tclk", "pclk";
> +	};
> +
> +	uart1: serial at fe650000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe650000 0x0 0x100>;
> +		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 2>, <&dmac0 3>;
> +		pinctrl-0 = <&uart1m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart2: serial at fe660000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe660000 0x0 0x100>;
> +		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 4>, <&dmac0 5>;
> +		pinctrl-0 = <&uart2m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart3: serial at fe670000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe670000 0x0 0x100>;
> +		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 6>, <&dmac0 7>;
> +		pinctrl-0 = <&uart3m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart4: serial at fe680000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe680000 0x0 0x100>;
> +		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 8>, <&dmac0 9>;
> +		pinctrl-0 = <&uart4m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart5: serial at fe690000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe690000 0x0 0x100>;
> +		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 10>, <&dmac0 11>;
> +		pinctrl-0 = <&uart5m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart6: serial at fe6a0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6a0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 12>, <&dmac0 13>;
> +		pinctrl-0 = <&uart6m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart7: serial at fe6b0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6b0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 14>, <&dmac0 15>;
> +		pinctrl-0 = <&uart7m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart8: serial at fe6c0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6c0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 16>, <&dmac0 17>;
> +		pinctrl-0 = <&uart8m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	uart9: serial at fe6d0000 {
> +		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xfe6d0000 0x0 0x100>;
> +		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
> +		clock-names = "baudclk", "apb_pclk";
> +		dmas = <&dmac0 18>, <&dmac0 19>;
> +		pinctrl-0 = <&uart9m0_xfer>;
> +		pinctrl-names = "default";
> +		reg-io-width = <4>;
> +		reg-shift = <2>;
> +		status = "disabled";
> +	};
> +
> +	pwm4: pwm at fe6e0000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm4_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm5: pwm at fe6e0010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm5_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm6: pwm at fe6e0020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm6_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm7: pwm at fe6e0030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6e0030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm7_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm8: pwm at fe6f0000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm8m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm9: pwm at fe6f0010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm9m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm10: pwm at fe6f0020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm10m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm11: pwm at fe6f0030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe6f0030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm11m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm12: pwm at fe700000 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700000 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm12m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm13: pwm at fe700010 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700010 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm13m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm14: pwm at fe700020 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700020 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm14m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pwm15: pwm at fe700030 {
> +		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
> +		reg = <0x0 0xfe700030 0x0 0x10>;
> +		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
> +		clock-names = "pwm", "pclk";
> +		pinctrl-0 = <&pwm15m0_pins>;
> +		pinctrl-names = "active";
> +		#pwm-cells = <3>;
> +		status = "disabled";
> +	};
> +
> +	pinctrl: pinctrl {
> +		compatible = "rockchip,rk3568-pinctrl";
> +		rockchip,grf = <&grf>;
> +		rockchip,pmu = <&pmugrf>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +

> +		gpio0: gpio at fdd60000 {

For Heiko:
Driver must also change for this nodename.

> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfdd60000 0x0 0x100>;
> +			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio1: gpio at fe740000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe740000 0x0 0x100>;
> +			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio2: gpio at fe750000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe750000 0x0 0x100>;
> +			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio3: gpio at fe760000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe760000 0x0 0x100>;
> +			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +
> +		gpio4: gpio at fe770000 {
> +			compatible = "rockchip,gpio-bank";
> +			reg = <0x0 0xfe770000 0x0 0x100>;
> +			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
> +			gpio-controller;
> +			#gpio-cells = <2>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +		};
> +	};
> +};
> +
> +#include "rk3568-pinctrl.dtsi"
> 


From youling257 at gmail.com  Wed Apr 28 19:49:46 2021
From: youling257 at gmail.com (youling257)
Date: Thu, 29 Apr 2021 02:49:46 +0800
Subject: [PATCH 04/17] rtc: cmos: remove cmos_rtc_ops_no_alarm
In-Reply-To: <20210110231752.1418816-5-alexandre.belloni@bootlin.com>
References: <20210110231752.1418816-5-alexandre.belloni@bootlin.com>
Message-ID: <20210428184946.23999-1-youling257@gmail.com>

this patch cause suspend failed on my Bay trail z3735f tablet.

[  162.038713] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x40 returns -22
[  162.038760] alarmtimer alarmtimer.0.auto: PM: failed to suspend: error -22


From clabbe at baylibre.com  Wed Apr 28 19:54:57 2021
From: clabbe at baylibre.com (Corentin Labbe)
Date: Wed, 28 Apr 2021 18:54:57 +0000
Subject: [PATCH] ARM: dts: gemini-rut1xx: remove duplicate ethernet node
Message-ID: <20210428185457.3719842-1-clabbe@baylibre.com>

Two ethernet node was added by
commit 95220046a62c ("ARM: dts: Add ethernet to a bunch of platforms")
and commit d6d0cef55e5b ("ARM: dts: Add the FOTG210 USB host to Gemini boards")

This patch removes the duplicate one.

Fixes: d6d0cef55e5b ("ARM: dts: Add the FOTG210 USB host to Gemini boards")
Signed-off-by: Corentin Labbe <clabbe at baylibre.com>
---
 arch/arm/boot/dts/gemini-rut1xx.dts | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/boot/dts/gemini-rut1xx.dts b/arch/arm/boot/dts/gemini-rut1xx.dts
index 9611ddf06792..08091d2a64e1 100644
--- a/arch/arm/boot/dts/gemini-rut1xx.dts
+++ b/arch/arm/boot/dts/gemini-rut1xx.dts
@@ -125,18 +125,6 @@ ethernet-port at 1 {
 			};
 		};
 
-		ethernet at 60000000 {
-			status = "okay";
-
-			ethernet-port at 0 {
-				phy-mode = "rgmii";
-				phy-handle = <&phy0>;
-			};
-			ethernet-port at 1 {
-				/* Not used in this platform */
-			};
-		};
-
 		usb at 68000000 {
 			status = "okay";
 		};
-- 
2.26.3



From morbo at google.com  Wed Apr 28 20:21:38 2021
From: morbo at google.com (Bill Wendling)
Date: Wed, 28 Apr 2021 12:21:38 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210428174010.GA4593@sirena.org.uk>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
Message-ID: <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>

On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
>
> > > Since the note.gnu.property section in the vDSO is not checked by the
> > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
>
> > Can we not instead fix the linker script to preserve the
> > .note.gnu.property, correctly aligned? It doesn't take much space and
> > while we don't use it now, it has the BTI information about the binary.
>
> > Cc'ing a few others who were involved in the BTI support.
>
> Not just BTI, we also flag PAC usage in there too and could add other
> extensions going forwards.  While the note isn't actively used by
> anything right now due to the kernel mapping the vDSO prior to userspace
> starting it is part of the ABI and something could end up wanting to use
> it and getting confused if it's not there.  It would be much better to
> fix the alignment issue.

If there's only one of the 8-byte aligned sections guaranteed, we
could place it first in the note. Otherwise, we will have to change
the alignment of the note (or somehow merge multiple notes).

-bw


From morbo at google.com  Wed Apr 28 20:31:01 2021
From: morbo at google.com (Bill Wendling)
Date: Wed, 28 Apr 2021 12:31:01 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
Message-ID: <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>

On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo at google.com> wrote:
> On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> >
> > > > Since the note.gnu.property section in the vDSO is not checked by the
> > > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> >
> > > Can we not instead fix the linker script to preserve the
> > > .note.gnu.property, correctly aligned? It doesn't take much space and
> > > while we don't use it now, it has the BTI information about the binary.
> >
> > > Cc'ing a few others who were involved in the BTI support.
> >
> > Not just BTI, we also flag PAC usage in there too and could add other
> > extensions going forwards.  While the note isn't actively used by
> > anything right now due to the kernel mapping the vDSO prior to userspace
> > starting it is part of the ABI and something could end up wanting to use
> > it and getting confused if it's not there.  It would be much better to
> > fix the alignment issue.
>
> If there's only one of the 8-byte aligned sections guaranteed, we
> could place it first in the note. Otherwise, we will have to change
> the alignment of the note (or somehow merge multiple notes).
>
I should have clarified that there's only one *entry* in the
.note.gnu.properties section, and if not then is it possible to merge
multiple entries into one. (Excuse my ignorance if this is already the
case.)

-bw


From lkp at intel.com  Wed Apr 28 20:44:22 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 29 Apr 2021 03:44:22 +0800
Subject: [PATCH v4 07/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
References: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <202104290331.tfwbdGzt-lkp@intel.com>

Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on rockchip/for-next tegra/for-next v5.12 next-20210428]
[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]

url:    https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/Address-some-issues-with-PM-runtime-at-media-subsystem/20210428-225742
base:   git://linuxtv.org/media_tree.git master
config: nds32-randconfig-r035-20210428 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/b6dba4aea621c15b0aa6f92e548c74cd6994eb20
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mauro-Carvalho-Chehab/Address-some-issues-with-PM-runtime-at-media-subsystem/20210428-225742
        git checkout b6dba4aea621c15b0aa6f92e548c74cd6994eb20
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nds32 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/media/platform/exynos-gsc/gsc-core.c: In function 'gsc_remove':
>> drivers/media/platform/exynos-gsc/gsc-core.c:1220:35: error: 'dev' undeclared (first use in this function); did you mean 'pdev'?
    1220 |  if (!pm_runtime_status_suspended(dev))
         |                                   ^~~
         |                                   pdev
   drivers/media/platform/exynos-gsc/gsc-core.c:1220:35: note: each undeclared identifier is reported only once for each function it appears in


vim +1220 drivers/media/platform/exynos-gsc/gsc-core.c

  1207	
  1208	static int gsc_remove(struct platform_device *pdev)
  1209	{
  1210		struct gsc_dev *gsc = platform_get_drvdata(pdev);
  1211		int i;
  1212	
  1213		gsc_unregister_m2m_device(gsc);
  1214		v4l2_device_unregister(&gsc->v4l2_dev);
  1215	
  1216		vb2_dma_contig_clear_max_seg_size(&pdev->dev);
  1217	
  1218		pm_runtime_disable(&pdev->dev);
  1219	
> 1220		if (!pm_runtime_status_suspended(dev))
  1221			for (i = 0; i < gsc->num_clocks; i++)
  1222				clk_disable_unprepare(gsc->clock[i]);
  1223	
  1224		pm_runtime_set_suspended(dev);
  1225	
  1226		dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
  1227		return 0;
  1228	}
  1229	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210429/f815672c/attachment-0001.gz>

From dmitry.torokhov at gmail.com  Wed Apr 28 20:52:37 2021
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Wed, 28 Apr 2021 12:52:37 -0700
Subject: [PATCH 1/7] Input: mtk-pmic-keys - check for NULL on
 of_match_device()
In-Reply-To: <20210428164219.1115537-2-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
 <20210428164219.1115537-2-mkorpershoek@baylibre.com>
Message-ID: <YIm9Bb3eBjYwY53R@google.com>

Hi Mattijs,

On Wed, Apr 28, 2021 at 06:42:13PM +0200, Mattijs Korpershoek wrote:
> mtk-pmic-keys being a child device of mt6397, it will always get probed
> when mt6397_probe() is called.
> 
> This also happens when we have no device tree node matching
> mediatek,mt6397-keys.

It sounds for me that creating a platform device instance in case where
we know need OF node, but do not have one, is wasteful. Can
mt6397-core.c and/or MFD core be adjusted to not do that.

> 
> In that case, the mfd core warns us:
> 
>   [    0.352175] mtk-pmic-keys: Failed to locate of_node [id: -1]
> 
> Check return value from call to of_match_device()
> in order to prevent a NULL pointer dereference.
> 
> In case of NULL print error message and return -ENODEV
> 
> Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
> ---
>  drivers/input/keyboard/mtk-pmic-keys.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index 62391d6c7da6..12c449eed026 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
> @@ -247,6 +247,9 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
>  	const struct of_device_id *of_id =
>  		of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
>  
> +	if (!of_id)
> +		return -ENODEV;
> +

So if we make MFD/6396 core smarter we would not be needing this. I
guess there is still a possibility of someone stuffing "mtk-pmic-keys"
into "driver_override" attribute of a random platform device but I
wonder if we really need to take care of such scenarios...

>  	keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
>  	if (!keys)
>  		return -ENOMEM;
> -- 
> 2.27.0
> 

Thanks.

-- 
Dmitry


From lkp at intel.com  Wed Apr 28 20:56:25 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 29 Apr 2021 03:56:25 +0800
Subject: [PATCH v4 07/79] media: exynos-gsc: don't resume at remove time
In-Reply-To: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
References: <210a2eee928d2ae7aee65e177f20cfb3f00e29ee.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <202104290355.SleAQ1SX-lkp@intel.com>

Hi Mauro,

I love your patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on rockchip/for-next tegra/for-next v5.12 next-20210428]
[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]

url:    https://github.com/0day-ci/linux/commits/Mauro-Carvalho-Chehab/Address-some-issues-with-PM-runtime-at-media-subsystem/20210428-225742
base:   git://linuxtv.org/media_tree.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/b6dba4aea621c15b0aa6f92e548c74cd6994eb20
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mauro-Carvalho-Chehab/Address-some-issues-with-PM-runtime-at-media-subsystem/20210428-225742
        git checkout b6dba4aea621c15b0aa6f92e548c74cd6994eb20
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=ia64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   drivers/media/platform/exynos-gsc/gsc-core.c: In function 'gsc_remove':
>> drivers/media/platform/exynos-gsc/gsc-core.c:1220:35: error: 'dev' undeclared (first use in this function); did you mean 'pdev'?
    1220 |  if (!pm_runtime_status_suspended(dev))
         |                                   ^~~
         |                                   pdev
   drivers/media/platform/exynos-gsc/gsc-core.c:1220:35: note: each undeclared identifier is reported only once for each function it appears in


vim +1220 drivers/media/platform/exynos-gsc/gsc-core.c

  1207	
  1208	static int gsc_remove(struct platform_device *pdev)
  1209	{
  1210		struct gsc_dev *gsc = platform_get_drvdata(pdev);
  1211		int i;
  1212	
  1213		gsc_unregister_m2m_device(gsc);
  1214		v4l2_device_unregister(&gsc->v4l2_dev);
  1215	
  1216		vb2_dma_contig_clear_max_seg_size(&pdev->dev);
  1217	
  1218		pm_runtime_disable(&pdev->dev);
  1219	
> 1220		if (!pm_runtime_status_suspended(dev))
  1221			for (i = 0; i < gsc->num_clocks; i++)
  1222				clk_disable_unprepare(gsc->clock[i]);
  1223	
  1224		pm_runtime_set_suspended(dev);
  1225	
  1226		dev_dbg(&pdev->dev, "%s driver unloaded\n", pdev->name);
  1227		return 0;
  1228	}
  1229	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 63872 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210429/81cb3b6f/attachment-0001.gz>

From alexandre.belloni at bootlin.com  Wed Apr 28 21:20:06 2021
From: alexandre.belloni at bootlin.com (Alexandre Belloni)
Date: Wed, 28 Apr 2021 22:20:06 +0200
Subject: [PATCH 04/17] rtc: cmos: remove cmos_rtc_ops_no_alarm
In-Reply-To: <20210428184946.23999-1-youling257@gmail.com>
References: <20210110231752.1418816-5-alexandre.belloni@bootlin.com>
 <20210428184946.23999-1-youling257@gmail.com>
Message-ID: <YInDdgd2r1SDdv4k@piout.net>

Hello,

On 29/04/2021 02:49:46+0800, youling257 wrote:
> this patch cause suspend failed on my Bay trail z3735f tablet.
> 
> [  162.038713] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x40 returns -22
> [  162.038760] alarmtimer alarmtimer.0.auto: PM: failed to suspend: error -22

I think I know what is happening, there is one patch I wanted to send
this cycle but didn't, can you test it?

https://github.com/alexandrebelloni/linux/commit/50641a5a19cedf7561410d7db614da46c228bacc

Thanks for the report!

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


From sean at poorly.run  Wed Apr 28 21:20:56 2021
From: sean at poorly.run (Sean Paul)
Date: Wed, 28 Apr 2021 16:20:56 -0400
Subject: [PATCH v5 3/4] drm/i915: init panel orientation property
In-Reply-To: <20210428170416.1027484-3-hsinyi@chromium.org>
References: <20210428170416.1027484-1-hsinyi@chromium.org>
 <20210428170416.1027484-3-hsinyi@chromium.org>
Message-ID: <CAMavQK+RJATzOVfgRhpU5i3kGsYM2-y4whgZMTdwNnK=z63nYA@mail.gmail.com>

On Wed, Apr 28, 2021 at 1:04 PM Hsin-Yi Wang <hsinyi at chromium.org> wrote:
>
> Creating the panel orientation property first since we separate the
> property creating and value setting.

This should probably be included in patch 1 so you don't regress i915
in between patches.

Sean

>
> Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c  | 1 +
>  drivers/gpu/drm/i915/display/intel_dp.c | 1 +
>  drivers/gpu/drm/i915/display/vlv_dsi.c  | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 9282978060b0..162fb3cf0f5a 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1903,6 +1903,7 @@ static void icl_dsi_add_properties(struct intel_connector *connector)
>
>         connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
>
> +       drm_connector_attach_scaling_mode_property(&connector->base);
>         drm_connector_set_panel_orientation_with_quirk(&connector->base,
>                                 intel_dsi_get_panel_orientation(connector),
>                                 connector->panel.fixed_mode->hdisplay,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index a5231ac3443a..f1d664e5abb2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5263,6 +5263,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
>         intel_panel_setup_backlight(connector, pipe);
>
>         if (fixed_mode) {
> +               drm_connector_init_panel_orientation_property(connector);
>                 drm_connector_set_panel_orientation_with_quirk(connector,
>                                 dev_priv->vbt.orientation,
>                                 fixed_mode->hdisplay, fixed_mode->vdisplay);
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index 9bee99fe5495..853855482af1 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -1632,6 +1632,7 @@ static void vlv_dsi_add_properties(struct intel_connector *connector)
>
>                 connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
>
> +               drm_connector_init_panel_orientation_property(&connector->base);
>                 drm_connector_set_panel_orientation_with_quirk(
>                                 &connector->base,
>                                 intel_dsi_get_panel_orientation(connector),
> --
> 2.31.1.498.g6c1eba8ee3d-goog
>


From helgaas at kernel.org  Wed Apr 28 21:53:19 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 28 Apr 2021 15:53:19 -0500
Subject: [PATCH v5 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
In-Reply-To: <CA+-6iNyN4UB3Sb14RJ9Jb2rXn_u-iwHzny1LYXEq3=VddWWxPg@mail.gmail.com>
Message-ID: <20210428205319.GA429792@bjorn-Precision-5520>

[+cc Amjad, Philipp: possible issue with 557acb3d2cd9 ("reset: make
shared pulsed reset controls re-triggerable") below; report at
https://lore.kernel.org/linux-ide/20210428200058.GA366202 at bjorn-Precision-5520/]

On Wed, Apr 28, 2021 at 04:34:00PM -0400, Jim Quinlan wrote:
> On Wed, Apr 28, 2021 at 4:01 PM Bjorn Helgaas <helgaas at kernel.org> wrote:
> > On Fri, Mar 12, 2021 at 03:45:53PM -0500, Jim Quinlan wrote:
> > > v5 -- Improved (I hope) commit description (Bjorn).
> > >    -- Rnamed error labels (Krzyszt).
> > >    -- Fixed typos.
> > >
> > > v4 -- does not rely on a pending commit, unlike v3.
> > >
> > > v3 -- discard commit from v2; instead rely on the new function
> > >       reset_control_rearm provided in a recent commit [1] applied
> > >       to reset/next.
> > >    -- New commit to correct pcie-brcmstb.c usage of a reset controller
> > >       to use reset/rearm verses deassert/assert.
> > >
> > > v2 -- refactor rescal-reset driver to implement assert/deassert rather than
> > >       reset because the reset call only fires once per lifetime and we need
> > >       to reset after every resume from S2 or S3.
> > >    -- Split the use of "ahci" and "rescal" controllers in separate fields
> > >       to keep things simple.
> > >
> > > v1 -- original
> > >
> > > Jim Quinlan (2):
> > >   ata: ahci_brcm: Fix use of BCM7216 reset controller
> > >   PCI: brcmstb: Use reset/rearm instead of deassert/assert
> > >
> > >  drivers/ata/ahci_brcm.c               | 46 +++++++++++++--------------
> > >  drivers/pci/controller/pcie-brcmstb.c | 19 +++++++----
> > >  2 files changed, 36 insertions(+), 29 deletions(-)
> >
> > Tripped over these errors while build testing with the .config below.
> > This is on the pci/brcmstb branch from
> > git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git
> >
> > Dropping the pci/brcmstb branch while we get this figured out.  This will
> > remove the following commits:
> >
> >   a24fd1d6469f ("PCI: brcmstb: Use reset/rearm instead of deassert/assert")
> >   92b9cb55a9b6 ("ata: ahci_brcm: Fix use of BCM7216 reset controller")
> >   b5d9209d5083 ("PCI: brcmstb: Fix error return code in brcm_pcie_probe()")
> 
> Hi Bjorn,
> 
> I believe the problem is that the commit
> 
> 557acb3d2cd9c82de19f944f6cc967a347735385
> "reset: make shared pulsed reset controls re-triggerable"
> 
> defined reset_control_rearm() for the CONFIG_RESET_CONTROLLER=y  case
> but forgot to define  an empty function for the unset case.  Your test
> .config has this CONFIG unset.
> 
> Would you like me to resubmit this with an additional commit that
> fixes this?

The fix could be a patch along those lines, or it could be a Kconfig
change that makes this config impossible.  I didn't look deeper to see
what makes sense.  But I don't think the fix should be "manually avoid
this configuration."

It looks like 557acb3d2cd9 ("reset: make shared pulsed reset controls
re-triggerable") appeared in v5.11, so if a patch is the right thing,
it should probably be marked for stable ("v5.11+").

Bjorn


From kuba at kernel.org  Wed Apr 28 21:54:43 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Wed, 28 Apr 2021 13:54:43 -0700
Subject: [PATCH 1/2] MAINTAINERS: remove Wingman Kwok
In-Reply-To: <20210428085607.32075-1-michael@walle.cc>
References: <20210428085607.32075-1-michael@walle.cc>
Message-ID: <20210428135443.7c1ef0f4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, 28 Apr 2021 10:56:06 +0200 Michael Walle wrote:
> His email bounces with permanent error "550 Invalid recipient". His last
> email on the LKML was from 2015-10-22 on the LKML.
> 
> Signed-off-by: Michael Walle <michael at walle.cc>

FWIW does not apply to any networking tree, whose tree 
are you targeting?


From f.fainelli at gmail.com  Wed Apr 28 22:03:00 2021
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 28 Apr 2021 14:03:00 -0700
Subject: [PATCH v5 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
In-Reply-To: <20210428205319.GA429792@bjorn-Precision-5520>
References: <20210428205319.GA429792@bjorn-Precision-5520>
Message-ID: <cd166f27-119d-a5ac-548e-175d79ddf49c@gmail.com>



On 4/28/2021 1:53 PM, Bjorn Helgaas wrote:
> [+cc Amjad, Philipp: possible issue with 557acb3d2cd9 ("reset: make
> shared pulsed reset controls re-triggerable") below; report at
> https://lore.kernel.org/linux-ide/20210428200058.GA366202 at bjorn-Precision-5520/]
> 
> On Wed, Apr 28, 2021 at 04:34:00PM -0400, Jim Quinlan wrote:
>> On Wed, Apr 28, 2021 at 4:01 PM Bjorn Helgaas <helgaas at kernel.org> wrote:
>>> On Fri, Mar 12, 2021 at 03:45:53PM -0500, Jim Quinlan wrote:
>>>> v5 -- Improved (I hope) commit description (Bjorn).
>>>>    -- Rnamed error labels (Krzyszt).
>>>>    -- Fixed typos.
>>>>
>>>> v4 -- does not rely on a pending commit, unlike v3.
>>>>
>>>> v3 -- discard commit from v2; instead rely on the new function
>>>>       reset_control_rearm provided in a recent commit [1] applied
>>>>       to reset/next.
>>>>    -- New commit to correct pcie-brcmstb.c usage of a reset controller
>>>>       to use reset/rearm verses deassert/assert.
>>>>
>>>> v2 -- refactor rescal-reset driver to implement assert/deassert rather than
>>>>       reset because the reset call only fires once per lifetime and we need
>>>>       to reset after every resume from S2 or S3.
>>>>    -- Split the use of "ahci" and "rescal" controllers in separate fields
>>>>       to keep things simple.
>>>>
>>>> v1 -- original
>>>>
>>>> Jim Quinlan (2):
>>>>   ata: ahci_brcm: Fix use of BCM7216 reset controller
>>>>   PCI: brcmstb: Use reset/rearm instead of deassert/assert
>>>>
>>>>  drivers/ata/ahci_brcm.c               | 46 +++++++++++++--------------
>>>>  drivers/pci/controller/pcie-brcmstb.c | 19 +++++++----
>>>>  2 files changed, 36 insertions(+), 29 deletions(-)
>>>
>>> Tripped over these errors while build testing with the .config below.
>>> This is on the pci/brcmstb branch from
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git
>>>
>>> Dropping the pci/brcmstb branch while we get this figured out.  This will
>>> remove the following commits:
>>>
>>>   a24fd1d6469f ("PCI: brcmstb: Use reset/rearm instead of deassert/assert")
>>>   92b9cb55a9b6 ("ata: ahci_brcm: Fix use of BCM7216 reset controller")
>>>   b5d9209d5083 ("PCI: brcmstb: Fix error return code in brcm_pcie_probe()")
>>
>> Hi Bjorn,
>>
>> I believe the problem is that the commit
>>
>> 557acb3d2cd9c82de19f944f6cc967a347735385
>> "reset: make shared pulsed reset controls re-triggerable"
>>
>> defined reset_control_rearm() for the CONFIG_RESET_CONTROLLER=y  case
>> but forgot to define  an empty function for the unset case.  Your test
>> .config has this CONFIG unset.
>>
>> Would you like me to resubmit this with an additional commit that
>> fixes this?
> 
> The fix could be a patch along those lines, or it could be a Kconfig
> change that makes this config impossible.  I didn't look deeper to see
> what makes sense.  But I don't think the fix should be "manually avoid
> this configuration."
> 
> It looks like 557acb3d2cd9 ("reset: make shared pulsed reset controls
> re-triggerable") appeared in v5.11, so if a patch is the right thing,
> it should probably be marked for stable ("v5.11+").

All of the other reset controller API have inline stubs when
CONFIG_RESET_CONTROLLER is disabled, not having one for
reset_control_rearm() seems like an oversight (easy to make since if you
introduce the API you obviously needed it and did not consider the case
where it may not be available).

I agree this would be stable material.
-- 
Florian


From youling257 at gmail.com  Wed Apr 28 22:07:39 2021
From: youling257 at gmail.com (youling 257)
Date: Thu, 29 Apr 2021 05:07:39 +0800
Subject: [PATCH 04/17] rtc: cmos: remove cmos_rtc_ops_no_alarm
In-Reply-To: <YInDdgd2r1SDdv4k@piout.net>
References: <20210110231752.1418816-5-alexandre.belloni@bootlin.com>
 <20210428184946.23999-1-youling257@gmail.com> <YInDdgd2r1SDdv4k@piout.net>
Message-ID: <CAOzgRdbWKDxAHjUZLemsNBZsctYssyEdfMiF5YpC=nTbjsoSLg@mail.gmail.com>

test this patch can fix my problem.

2021-04-29 4:20 GMT+08:00, Alexandre Belloni <alexandre.belloni at bootlin.com>:
> Hello,
>
> On 29/04/2021 02:49:46+0800, youling257 wrote:
>> this patch cause suspend failed on my Bay trail z3735f tablet.
>>
>> [  162.038713] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x40
>> returns -22
>> [  162.038760] alarmtimer alarmtimer.0.auto: PM: failed to suspend: error
>> -22
>
> I think I know what is happening, there is one patch I wanted to send
> this cycle but didn't, can you test it?
>
> https://github.com/alexandrebelloni/linux/commit/50641a5a19cedf7561410d7db614da46c228bacc
>
> Thanks for the report!
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>


From michael at walle.cc  Wed Apr 28 22:39:00 2021
From: michael at walle.cc (Michael Walle)
Date: Wed, 28 Apr 2021 23:39:00 +0200
Subject: [PATCH 1/2] MAINTAINERS: remove Wingman Kwok
In-Reply-To: <20210428135443.7c1ef0f4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
References: <20210428085607.32075-1-michael@walle.cc>
 <20210428135443.7c1ef0f4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Message-ID: <163af71165cb8a2025026fea8236e4f2@walle.cc>

Am 2021-04-28 22:54, schrieb Jakub Kicinski:
> On Wed, 28 Apr 2021 10:56:06 +0200 Michael Walle wrote:
>> His email bounces with permanent error "550 Invalid recipient". His 
>> last
>> email on the LKML was from 2015-10-22 on the LKML.
>> 
>> Signed-off-by: Michael Walle <michael at walle.cc>
> 
> FWIW does not apply to any networking tree, whose tree
> are you targeting?

This was on linux-next. I'm not sure through what tree
these changes will go. I included all the original "L:"
here.

I can rebase it onto net-next (or wait until after
the merge window closes).

-michael


From robh at kernel.org  Wed Apr 28 23:15:09 2021
From: robh at kernel.org (Rob Herring)
Date: Wed, 28 Apr 2021 17:15:09 -0500
Subject: [PATCH v3 07/10] dt-bindings: soc: rockchip: Convert grf.txt to
 YAML
In-Reply-To: <20210428134938.22383-1-cl@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
 <20210428134938.22383-1-cl@rock-chips.com>
Message-ID: <1619648109.786418.4061032.nullmailer@robh.at.kernel.org>

On Wed, 28 Apr 2021 21:49:38 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> Current dts files with 'grf' nodes are manually verified. In order to
> automate this process grf.txt has to be converted to YAML.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>  .../devicetree/bindings/soc/rockchip/grf.yaml | 61 +++++++++++++++++++
>  2 files changed, 61 insertions(+), 61 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.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/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml: example-0: syscon at ff320000:reg:0: [0, 4281466880, 0, 4096] is too long
	From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml: example-0: syscon at ff770000:reg:0: [0, 4285988864, 0, 65536] is too long
	From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml: syscon at ff320000: compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3399-pmugrf', 'syscon'] is too short
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml: syscon at ff770000: compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3399-grf', 'syscon'] is too short
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.yaml

See https://patchwork.ozlabs.org/patch/1471171

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From kuba at kernel.org  Wed Apr 28 23:22:08 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Wed, 28 Apr 2021 15:22:08 -0700
Subject: [PATCH 1/2] MAINTAINERS: remove Wingman Kwok
In-Reply-To: <163af71165cb8a2025026fea8236e4f2@walle.cc>
References: <20210428085607.32075-1-michael@walle.cc>
 <20210428135443.7c1ef0f4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
 <163af71165cb8a2025026fea8236e4f2@walle.cc>
Message-ID: <20210428152208.4ae31463@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, 28 Apr 2021 23:39:00 +0200 Michael Walle wrote:
> Am 2021-04-28 22:54, schrieb Jakub Kicinski:
> > On Wed, 28 Apr 2021 10:56:06 +0200 Michael Walle wrote:  
> >> His email bounces with permanent error "550 Invalid recipient". His 
> >> last
> >> email on the LKML was from 2015-10-22 on the LKML.
> >> 
> >> Signed-off-by: Michael Walle <michael at walle.cc>  
> > 
> > FWIW does not apply to any networking tree, whose tree
> > are you targeting?  
> 
> This was on linux-next. I'm not sure through what tree
> these changes will go. I included all the original "L:"
> here.
> 
> I can rebase it onto net-next (or wait until after
> the merge window closes).

Rebase on net would be best - would you mind doing that in
around two days? (we're about to send the PR for 5.13)


From kuba at kernel.org  Wed Apr 28 23:25:09 2021
From: kuba at kernel.org (Jakub Kicinski)
Date: Wed, 28 Apr 2021 15:25:09 -0700
Subject: [PATCH net-next v1 1/1] net: selftest: fix build issue if INET
 is disabled
In-Reply-To: <20210428130947.29649-1-o.rempel@pengutronix.de>
References: <20210428130947.29649-1-o.rempel@pengutronix.de>
Message-ID: <20210428152509.61dc25e7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, 28 Apr 2021 15:09:46 +0200 Oleksij Rempel wrote:
> In case ethernet driver is enabled and INET is disabled, selftest will
> fail to build.
> 
> Reported-by: Randy Dunlap <rdunlap at infradead.org>
> Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>

Applied (after fixing a checkpatch warning), thanks.


From sebastian.reichel at collabora.com  Wed Apr 28 23:29:51 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:51 +0200
Subject: [PATCHv2 3/5] dt-bindings: vendor-prefixes: add congatec
In-Reply-To: <20210428222953.235280-1-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
Message-ID: <20210428222953.235280-4-sebastian.reichel@collabora.com>

Document binding for congatec.

Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.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 c88b1cfb52cb..10e3ce8a29c5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -247,6 +247,8 @@ patternProperties:
     description: Colorful GRP, Shenzhen Xueyushi Technology Ltd.
   "^compulab,.*":
     description: CompuLab Ltd.
+  "^congatec,.*":
+    description: congatec GmbH
   "^coreriver,.*":
     description: CORERIVER Semiconductor Co.,Ltd.
   "^corpro,.*":
-- 
2.30.2



From sebastian.reichel at collabora.com  Wed Apr 28 23:29:49 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:49 +0200
Subject: [PATCHv2 1/5] rtc: m41t80: add support for fixed clock
In-Reply-To: <20210428222953.235280-1-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
Message-ID: <20210428222953.235280-2-sebastian.reichel@collabora.com>

Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
modules SQW clock output defaults to 32768 Hz. This behaviour is
used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
the clock is disabled and all i.MX6 functionality depending on
the 32 KHz clock has undefined behaviour. For example when using
the hardware watchdog the system will likely do arbitrary reboots.

Referencing the m41t62 directly results in a deadlock. The kernel
will see, that i.MX6 system clock needs the RTC clock and do probe
deferral. But the i.MX6 I2C module never becomes usable without the
i.MX6 CKIL clock and thus the RTC's clock will not be probed. So
from the kernel's perspective this is a chicken-and-egg problem.

Technically everything is fine by not touching anything, since
the RTC clock correctly enables the clock on reset (i.e. on
battery backup power loss) and also the bootloader enables it
in case an something (e.g. an unpatched kernel) disabled this
incorrectly.

A workaround for this issue is describing the square wave pin
as fixed-clock, which is registered early and basically how
this pin is used on the i.MX6.

Suggested-by: Saravana Kannan <saravanak at google.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.com>
---
 Documentation/devicetree/bindings/rtc/rtc-m41t80.txt |  9 +++++++++
 drivers/rtc/rtc-m41t80.c                             | 12 ++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
index c746cb221210..cdd196b1e9bd 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
@@ -21,10 +21,19 @@ Optional properties:
                       clock name
 - wakeup-source: Enables wake up of host system on alarm
 
+Optional child node:
+- clock: Provide this if the square wave pin is used as boot-enabled fixed clock.
+
 Example:
 	rtc at 68 {
 		compatible = "st,m41t80";
 		reg = <0x68>;
 		interrupt-parent = <&UIC0>;
 		interrupts = <0x9 0x8>;
+
+		clock {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
 	};
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 89128fc29ccc..b3ece42b6f90 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -544,10 +544,22 @@ static struct clk *m41t80_sqw_register_clk(struct m41t80_data *m41t80)
 {
 	struct i2c_client *client = m41t80->client;
 	struct device_node *node = client->dev.of_node;
+	struct device_node *fixed_clock;
 	struct clk *clk;
 	struct clk_init_data init;
 	int ret;
 
+	fixed_clock = of_get_child_by_name(node, "clock");
+	if (fixed_clock) {
+		/*
+		 * skip registering square wave clock when a fixed
+		 * clock has been registered. The fixed clock is
+		 * registered automatically when being referenced.
+		 */
+		of_node_put(fixed_clock);
+		return 0;
+	}
+
 	/* First disable the clock */
 	ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON);
 	if (ret < 0)
-- 
2.30.2



From sebastian.reichel at collabora.com  Wed Apr 28 23:29:52 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:52 +0200
Subject: [PATCHv2 4/5] dt-bindings: arm: fsl: add GE B1x5pv2 boards
In-Reply-To: <20210428222953.235280-1-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
Message-ID: <20210428222953.235280-5-sebastian.reichel@collabora.com>

Document the compatible for GE B1x5pv2 boards.

Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.com>
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index e3c50f231d71..6e5b14c75325 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -400,6 +400,17 @@ properties:
           - const: armadeus,imx6dl-apf6         # APF6 (Solo) SoM
           - const: fsl,imx6dl
 
+      - description: i.MX6DL based congatec QMX6 Boards
+        items:
+          - enum:
+              - ge,imx6dl-b105v2          # General Electric B105v2
+              - ge,imx6dl-b105pv2         # General Electric B105Pv2
+              - ge,imx6dl-b125v2          # General Electric B125v2
+              - ge,imx6dl-b125pv2         # General Electric B125Pv2
+              - ge,imx6dl-b155v2          # General Electric B155v2
+          - const: congatec,qmx6
+          - const: fsl,imx6dl
+
       - description: i.MX6DL based DFI FS700-M60-6DL Board
         items:
           - const: dfi,fs700-m60-6dl
-- 
2.30.2



From sebastian.reichel at collabora.com  Wed Apr 28 23:29:48 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:48 +0200
Subject: [PATCHv2 0/5] Support for GE B1x5v2 and B1x5Pv2
Message-ID: <20210428222953.235280-1-sebastian.reichel@collabora.com>

Hi,

This series adds support for another General Electric patient
monitor series (similar to existing Bx50v3), which is based on
i.MX6DL using Congatec's QMX6 module.

The module uses an I2C RTC to provide the i.MX6 32768 Hz clock,
so it's important to keep it enabled. Not doing so results in
incorrect timings of watchdog and i.MX6 RTC. The bootloader
enables the watchdog, so disabling the clock results in system
reboot. [0]

The second patch is required for B155v2, which uses a 1366x768
G156XTN01 panel. The 1366 width is not supported by the display
pipeline and result in boot hanging without the patch. [1]

Patches 3+4 are updating DT bindings for the new board compatible
values.

Patch 5 adds the board files.

Changes since PATCHv1:
 * https://lore.kernel.org/lkml/20210222171247.97609-1-sebastian.reichel at collabora.com/
 * drop patch 5 (applied)
 * instead of using 'protected-clocks' in RTC node, add fixed-clock
   node as suggested by Saravana Kannan
 * rebased to current master (68a32ba14177)

Thanks,

[0] There has been a discussion for the problem on the mailinglists
last year. The discussion died off, when I told people their ideas
don't work. I hope using protected-clocks is fine for this usecase.

https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reichel at collabora.com/

[1] I've sent this before as a separate patch in September, but
nobody seemed to care. This adds full context for the problem.

https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reichel at collabora.com/

-- Sebastian

Sebastian Reichel (5):
  rtc: m41t80: add support for fixed clock
  drm/imx: Add 8 pixel alignment fix
  dt-bindings: vendor-prefixes: add congatec
  dt-bindings: arm: fsl: add GE B1x5pv2 boards
  ARM: dts: imx6: Add GE B1x5v2

 .../devicetree/bindings/arm/fsl.yaml          |  11 +
 .../devicetree/bindings/rtc/rtc-m41t80.txt    |   9 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm/boot/dts/Makefile                    |   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts          |  35 +
 arch/arm/boot/dts/imx6dl-b105v2.dts           |  35 +
 arch/arm/boot/dts/imx6dl-b125pv2.dts          |  33 +
 arch/arm/boot/dts/imx6dl-b125v2.dts           |  33 +
 arch/arm/boot/dts/imx6dl-b155v2.dts           |  36 +
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi         | 434 ++++++++++++
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi          |  61 ++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi            | 624 ++++++++++++++++++
 drivers/gpu/drm/imx/imx-drm-core.c            |  19 +-
 drivers/gpu/drm/imx/imx-ldb.c                 |   5 +
 drivers/gpu/drm/imx/ipuv3-crtc.c              |  11 +-
 drivers/gpu/drm/imx/ipuv3-plane.c             |  19 +-
 drivers/gpu/ipu-v3/ipu-dc.c                   |   5 +
 drivers/gpu/ipu-v3/ipu-di.c                   |   7 +
 drivers/rtc/rtc-m41t80.c                      |  12 +
 19 files changed, 1390 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

-- 
2.30.2



From sebastian.reichel at collabora.com  Wed Apr 28 23:29:50 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:50 +0200
Subject: [PATCHv2 2/5] drm/imx: Add 8 pixel alignment fix
In-Reply-To: <20210428222953.235280-1-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
Message-ID: <20210428222953.235280-3-sebastian.reichel@collabora.com>

Some standard resolutions like 1366x768 do not work properly with
i.MX6 SoCs, since the horizontal resolution needs to be aligned
to 8 pixels (so 1360x768 or 1368x768 would work).

This patch allocates framebuffers allocated to 8 pixels. The extra
time required to send the extra pixels are removed from the blank
time. In order to expose the correct display size to userspace,
the stride is increased without increasing the width.

Without this patch systems with this display resolution hang
indefinitely during boot up.

Suggested-by: Boris Brezillon <boris.brezillon at collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.com>
---
 drivers/gpu/drm/imx/imx-drm-core.c | 19 ++++++++++++++++++-
 drivers/gpu/drm/imx/imx-ldb.c      |  5 +++++
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 11 ++++++++++-
 drivers/gpu/drm/imx/ipuv3-plane.c  | 19 +++++++++++++++----
 drivers/gpu/ipu-v3/ipu-dc.c        |  5 +++++
 drivers/gpu/ipu-v3/ipu-di.c        |  7 +++++++
 6 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
index e6a88c8cbd69..8457b9788cda 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -145,9 +145,26 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
 	/* none so far */
 };
 
+static int imx_drm_dumb_create(struct drm_file *file_priv,
+			       struct drm_device *drm,
+			       struct drm_mode_create_dumb *args)
+{
+	u32 width = args->width;
+	int ret;
+
+	args->width = ALIGN(width, 8);
+
+	ret = drm_gem_cma_dumb_create(file_priv, drm, args);
+	if (ret)
+		return ret;
+
+	args->width = width;
+	return ret;
+}
+
 static const struct drm_driver imx_drm_driver = {
 	.driver_features	= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
-	DRM_GEM_CMA_DRIVER_OPS,
+	DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(imx_drm_dumb_create),
 	.ioctls			= imx_drm_ioctls,
 	.num_ioctls		= ARRAY_SIZE(imx_drm_ioctls),
 	.fops			= &imx_drm_driver_fops,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index ffdc492c5bc5..53132ddf9587 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -274,6 +274,11 @@ imx_ldb_encoder_atomic_mode_set(struct drm_encoder *encoder,
 			 "%s: mode exceeds 85 MHz pixel clock\n", __func__);
 	}
 
+	if (!IS_ALIGNED(mode->hdisplay, 8)) {
+		dev_warn(ldb->dev,
+			 "%s: hdisplay does not align to 8 byte\n", __func__);
+	}
+
 	if (dual) {
 		serial_clk = 3500UL * mode->clock;
 		imx_ldb_set_clock(ldb, mux, 0, serial_clk, di_clk);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index e6431a227feb..9c8829f945b2 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -305,10 +305,19 @@ static void ipu_crtc_mode_set_nofb(struct drm_crtc *crtc)
 	sig_cfg.vsync_pin = imx_crtc_state->di_vsync_pin;
 
 	drm_display_mode_to_videomode(mode, &sig_cfg.mode);
+	if (!IS_ALIGNED(sig_cfg.mode.hactive, 8)) {
+		unsigned int new_hactive = ALIGN(sig_cfg.mode.hactive, 8);
+
+		dev_warn(ipu_crtc->dev, "8-pixel align hactive %d -> %d\n",
+			 sig_cfg.mode.hactive, new_hactive);
+
+		sig_cfg.mode.hfront_porch = new_hactive - sig_cfg.mode.hactive;
+		sig_cfg.mode.hactive = new_hactive;
+	}
 
 	ipu_dc_init_sync(ipu_crtc->dc, ipu_crtc->di,
 			 mode->flags & DRM_MODE_FLAG_INTERLACE,
-			 imx_crtc_state->bus_format, mode->hdisplay);
+			 imx_crtc_state->bus_format, sig_cfg.mode.hactive);
 	ipu_di_init_sync_panel(ipu_crtc->di, &sig_cfg);
 }
 
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c
index fa5009705365..06ad6dece61f 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -30,6 +30,11 @@ to_ipu_plane_state(struct drm_plane_state *p)
 	return container_of(p, struct ipu_plane_state, base);
 }
 
+static unsigned int ipu_src_rect_width(const struct drm_plane_state *state)
+{
+	return ALIGN(drm_rect_width(&state->src) >> 16, 8);
+}
+
 static inline struct ipu_plane *to_ipu_plane(struct drm_plane *p)
 {
 	return container_of(p, struct ipu_plane, base);
@@ -415,6 +420,12 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 	if (old_fb && fb->pitches[0] != old_fb->pitches[0])
 		crtc_state->mode_changed = true;
 
+	if (ALIGN(fb->width, 8) * fb->format->cpp[0] >
+	    fb->pitches[0] + fb->offsets[0]) {
+		dev_warn(dev, "pitch is not big enough for 8 pixels alignment");
+		return -EINVAL;
+	}
+
 	switch (fb->format->format) {
 	case DRM_FORMAT_YUV420:
 	case DRM_FORMAT_YVU420:
@@ -590,7 +601,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
 	if (ipu_state->use_pre) {
 		axi_id = ipu_chan_assign_axi_id(ipu_plane->dma);
 		ipu_prg_channel_configure(ipu_plane->ipu_ch, axi_id,
-					  drm_rect_width(&new_state->src) >> 16,
+					  ipu_src_rect_width(new_state),
 					  drm_rect_height(&new_state->src) >> 16,
 					  fb->pitches[0], fb->format->format,
 					  fb->modifier, &eba);
@@ -623,9 +634,9 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
 		break;
 	}
 
-	ipu_dmfc_config_wait4eot(ipu_plane->dmfc, drm_rect_width(dst));
+	ipu_dmfc_config_wait4eot(ipu_plane->dmfc, ALIGN(drm_rect_width(dst), 8));
 
-	width = drm_rect_width(&new_state->src) >> 16;
+	width = ipu_src_rect_width(new_state);
 	height = drm_rect_height(&new_state->src) >> 16;
 	info = drm_format_info(fb->format->format);
 	ipu_calculate_bursts(width, info->cpp[0], fb->pitches[0],
@@ -690,7 +701,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
 
 		ipu_cpmem_zero(ipu_plane->alpha_ch);
 		ipu_cpmem_set_resolution(ipu_plane->alpha_ch,
-					 drm_rect_width(&new_state->src) >> 16,
+					 ipu_src_rect_width(new_state),
 					 drm_rect_height(&new_state->src) >> 16);
 		ipu_cpmem_set_format_passthrough(ipu_plane->alpha_ch, 8);
 		ipu_cpmem_set_high_priority(ipu_plane->alpha_ch);
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 34b4075a6a8e..ca96b235491a 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -167,6 +167,11 @@ int ipu_dc_init_sync(struct ipu_dc *dc, struct ipu_di *di, bool interlaced,
 
 	dc->di = ipu_di_get_num(di);
 
+	if (!IS_ALIGNED(width, 8)) {
+		dev_warn(priv->dev,
+			 "%s: hactive does not align to 8 byte\n", __func__);
+	}
+
 	map = ipu_bus_format_to_map(bus_format);
 
 	/*
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index e617f60afeea..666223c6bec4 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -506,6 +506,13 @@ int ipu_di_adjust_videomode(struct ipu_di *di, struct videomode *mode)
 {
 	u32 diff;
 
+	if (!IS_ALIGNED(mode->hactive, 8) &&
+	    mode->hfront_porch < ALIGN(mode->hactive, 8) - mode->hactive) {
+		dev_err(di->ipu->dev, "hactive %d is not aligned to 8 and front porch is too small to compensate\n",
+			mode->hactive);
+		return -EINVAL;
+	}
+
 	if (mode->vfront_porch >= 2)
 		return 0;
 
-- 
2.30.2



From sebastian.reichel at collabora.com  Wed Apr 28 23:29:53 2021
From: sebastian.reichel at collabora.com (Sebastian Reichel)
Date: Thu, 29 Apr 2021 00:29:53 +0200
Subject: [PATCHv2 5/5] ARM: dts: imx6: Add GE B1x5v2
In-Reply-To: <20210428222953.235280-1-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
Message-ID: <20210428222953.235280-6-sebastian.reichel@collabora.com>

This adds device tree files for the General Electric Healthcare
(GEHC) B1x5v2 series. All models make use of Congatec's QMX6 module,
which is described in its own device tree include, so that it can
also be used by other boards.

Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.com>
---
 arch/arm/boot/dts/Makefile            |   5 +
 arch/arm/boot/dts/imx6dl-b105pv2.dts  |  35 ++
 arch/arm/boot/dts/imx6dl-b105v2.dts   |  35 ++
 arch/arm/boot/dts/imx6dl-b125pv2.dts  |  33 ++
 arch/arm/boot/dts/imx6dl-b125v2.dts   |  33 ++
 arch/arm/boot/dts/imx6dl-b155v2.dts   |  36 ++
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++++++++++++++++++
 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi  |  61 +++
 arch/arm/boot/dts/imx6dl-qmx6.dtsi    | 624 ++++++++++++++++++++++++++
 9 files changed, 1296 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
 create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f8f09c5066e7..811f22ed1e37 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -515,6 +515,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-dms-ba16.dtb \
 	imx6q-emcon-avari.dtb \
 	imx6q-evi.dtb \
+	imx6dl-b105v2.dtb \
+	imx6dl-b105pv2.dtb \
+	imx6dl-b125v2.dtb \
+	imx6dl-b125pv2.dtb \
+	imx6dl-b155v2.dtb \
 	imx6q-gk802.dtb \
 	imx6q-gw51xx.dtb \
 	imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-b105pv2.dts b/arch/arm/boot/dts/imx6dl-b105pv2.dts
new file mode 100644
index 000000000000..0d5be2f9471f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105pv2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+	model = "General Electric B105Pv2";
+	compatible = "ge,imx6dl-b105pv2", "congatec,qmx6", "fsl,imx6dl";
+
+	panel {
+		compatible = "auo,g101evn010";
+		status = "okay";
+	};
+};
+
+&i2c3 {
+	touchscreen at 41 {
+		reg = <0x41>;
+		compatible = "ilitek,ili251x";
+
+		pinctrl-names = "default";
+		pinctrl-0 =<&pinctrl_q7_gpio0>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+		touchscreen-size-x = <1280>;
+		touchscreen-size-y = <800>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-b105v2.dts b/arch/arm/boot/dts/imx6dl-b105v2.dts
new file mode 100644
index 000000000000..72a085348304
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b105v2.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B105v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+	model = "General Electric B105v2";
+	compatible = "ge,imx6dl-b105v2", "congatec,qmx6", "fsl,imx6dl";
+
+	panel {
+		compatible = "auo,g101evn010";
+		status = "okay";
+	};
+};
+
+&i2c3 {
+	touchscreen at 41 {
+		reg = <0x41>;
+		compatible = "ilitek,ili251x";
+
+		pinctrl-names = "default";
+		pinctrl-0 =<&pinctrl_q7_gpio0>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+		reset-gpios = <&tca6424a 21 GPIO_ACTIVE_LOW>;
+
+		touchscreen-size-x = <1280>;
+		touchscreen-size-y = <800>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-b125pv2.dts b/arch/arm/boot/dts/imx6dl-b125pv2.dts
new file mode 100644
index 000000000000..8fd6c8ed6750
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b125pv2.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B125Pv2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+	model = "General Electric B125Pv2";
+	compatible = "ge,imx6dl-b125pv2", "congatec,qmx6", "fsl,imx6dl";
+
+	panel {
+		compatible = "auo,g121ean01";
+		status = "okay";
+	};
+};
+
+&i2c3 {
+	touchscreen at 2a {
+		reg = <0x2a>;
+		compatible = "eeti,exc80h60";
+
+		pinctrl-names = "default";
+		pinctrl-0 =<&pinctrl_q7_gpio0>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+		reset-gpios = <&tca6424a 21 GPIO_ACTIVE_HIGH>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-b125v2.dts b/arch/arm/boot/dts/imx6dl-b125v2.dts
new file mode 100644
index 000000000000..eb26ffde9f72
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b125v2.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B125v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+	model = "General Electric B125v2";
+	compatible = "ge,imx6dl-b125v2", "congatec,qmx6", "fsl,imx6dl";
+
+	panel {
+		compatible = "auo,g121ean01";
+		status = "okay";
+	};
+};
+
+&i2c3 {
+	touchscreen at 2a {
+		reg = <0x2a>;
+		compatible = "eeti,exc80h60";
+
+		pinctrl-names = "default";
+		pinctrl-0 =<&pinctrl_q7_gpio0>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+		reset-gpios = <&tca6424a 21 GPIO_ACTIVE_HIGH>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-b155v2.dts b/arch/arm/boot/dts/imx6dl-b155v2.dts
new file mode 100644
index 000000000000..620cd6f9da82
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b155v2.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B155v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+/dts-v1/;
+#include "imx6dl-b1x5v2.dtsi"
+
+/ {
+	model = "General Electric B155v2";
+	compatible = "ge,imx6dl-b155v2", "congatec,qmx6", "fsl,imx6dl";
+
+	panel {
+		compatible = "auo,g156xtn01";
+		status = "okay";
+	};
+};
+
+&i2c3 {
+	touchscreen at 2a {
+		reg = <0x2a>;
+		compatible = "eeti,exc80h84";
+
+		pinctrl-names = "default";
+		pinctrl-0 =<&pinctrl_q7_gpio0>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+		touchscreen-inverted-x;
+		touchscreen-inverted-y;
+
+		reset-gpios = <&tca6424a 21 GPIO_ACTIVE_HIGH>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi b/arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
new file mode 100644
index 000000000000..1f9e66e1afc0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi
@@ -0,0 +1,434 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B1x5v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+#include <dt-bindings/input/input.h>
+#include "imx6dl-qmx6.dtsi"
+
+/ {
+	chosen {
+		stdout-path = &uart3;
+	};
+
+	/* Do not allow frequencies above 800MHz */
+	cpus {
+		cpu at 0 {
+			operating-points = <
+				/* kHz    uV */
+				792000  1175000
+				396000  1150000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz	SOC-PU uV */
+				792000	1175000
+				396000	1175000
+			>;
+		};
+
+		cpu at 1 {
+			operating-points = <
+				/* kHz    uV */
+				792000  1175000
+				396000  1150000
+			>;
+			fsl,soc-operating-points = <
+				/* ARM kHz	SOC-PU uV */
+				792000	1175000
+				396000	1175000
+			>;
+		};
+	};
+
+	reg_syspwr: regulator-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "SYS_PWR";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		regulator-always-on;
+	};
+
+	reg_5v_pmc: regulator-5v-pmc {
+		compatible = "regulator-fixed";
+		regulator-name = "5V PMC";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+		vin-supply = <&reg_syspwr>;
+	};
+
+	reg_5v: regulator-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+		vin-supply = <&reg_syspwr>;
+	};
+
+	reg_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		vin-supply = <&reg_syspwr>;
+	};
+
+	reg_5v0_audio: regulator-5v0-audio {
+		compatible = "regulator-fixed";
+		regulator-name = "5V0_AUDIO";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_5v>;
+
+		gpio = <&tca6424a 16 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		/*
+		 * This must be always-on for da7212, which has some not
+		 * properly documented dependencies for it's speaker supply
+		 * pin. The issue manifests as speaker volume being very low.
+		 */
+		regulator-always-on;
+	};
+
+
+	reg_3v3_audio: regulator-3v3-audio {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3_AUDIO";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&reg_3v3>;
+
+		pinctrl-0 = <&pinctrl_q7_hda_rst>;
+		pinctrl-names = "default";
+		gpio = <&gpio6 8 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_2v5_audio: regulator-2v5-audio {
+		compatible = "regulator-fixed";
+		regulator-name = "2V5_AUDIO";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		regulator-always-on;
+		vin-supply = <&reg_3v3_audio>;
+
+	};
+
+	reg_wlan: regulator-wlan {
+		compatible = "regulator-fixed";
+		regulator-name = "WLAN";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&reg_3v3>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_sdio_pwr>;
+		gpio = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	reg_bl: regulator-backlight {
+		compatible = "regulator-fixed";
+		regulator-name = "LED_VCC";
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+		vin-supply = <&reg_syspwr>;
+
+		pinctrl-0 = <&pinctrl_q7_lcd_power>;
+		pinctrl-names = "default";
+		gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_lcd: regulator-lcd {
+		compatible = "regulator-fixed";
+		regulator-name = "LCD_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_5v>;
+	};
+
+	usb_power: regulator-usb-power {
+		compatible = "regulator-fixed";
+		regulator-name = "USB POWER";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_5v>;
+	};
+
+	charger: battery-charger {
+		compatible = "gpio-charger"; /* ti,bq24172 */
+
+		charger-type = "mains";
+		gpios = <&tca6424a 3 GPIO_ACTIVE_LOW>;
+		charge-current-limit-gpios = <&tca6424a 11 GPIO_ACTIVE_HIGH>,
+					     <&tca6424a 12 GPIO_ACTIVE_HIGH>;
+		charge-current-limit-mapping = <1300000 0x0>,
+					       <700000 0x1>,
+					       <0 0x2>;
+
+		charge-status-gpios = <&tca6424a 6 GPIO_ACTIVE_HIGH>;
+	};
+
+	poweroff {
+		compatible = "gpio-poweroff";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_spi_cs1>;
+		gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;
+	};
+
+	power-button-key {
+		compatible = "gpio-keys";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_slp_btn>;
+
+		power-button {
+			label = "power button";
+			gpios = <&gpio4 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_POWER>;
+		};
+	};
+
+	rotary-encoder-key {
+		compatible = "gpio-keys";
+
+		rotary-encoder-press {
+			label = "rotary-encoder press";
+			gpios = <&tca6424a 0 GPIO_ACTIVE_HIGH>;
+			linux,code = <KEY_ENTER>;
+			linux,can-disable;
+		};
+	};
+
+	rotary-encoder {
+		compatible = "rotary-encoder";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_gpio2 &pinctrl_q7_gpio4>;
+		gpios = <&gpio4 26 GPIO_ACTIVE_LOW>, <&gpio1 0 GPIO_ACTIVE_LOW>;
+		rotary-encoder,relative-axis;
+		rotary-encoder,steps-per-period = <2>;
+		wakeup-source;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_gpio1 &pinctrl_q7_gpio3 &pinctrl_q7_gpio5>;
+
+		alarm1 {
+			label = "alarm:red";
+			gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+		};
+
+		alarm2 {
+			label = "alarm:yellow";
+			gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+		};
+
+		alarm3 {
+			label = "alarm:blue";
+			gpios = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_backlight_enable>;
+		power-supply = <&reg_bl>;
+		pwms = <&pwm4 0 5000000 0>;
+		brightness-levels = <0 255>;
+		num-interpolated-steps = <255>;
+		default-brightness-level = <179>;
+		enable-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+		status = "okay";
+	};
+
+	panel {
+		backlight = <&backlight>;
+		power-supply = <&reg_lcd>;
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,name = "audio-card";
+		simple-audio-card,format = "i2s";
+		simple-audio-card,bitclock-master = <&dailink_master>;
+		simple-audio-card,frame-master = <&dailink_master>;
+
+		simple-audio-card,widgets = "Speaker", "Ext Spk";
+		simple-audio-card,audio-routing = "Ext Spk", "LINE";
+
+		simple-audio-card,cpu {
+			sound-dai = <&ssi1>;
+		};
+
+		dailink_master: simple-audio-card,codec {
+			sound-dai = <&codec>;
+		};
+	};
+
+	clk_ext_audio_codec: clock-codec {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12288000>;
+	};
+};
+
+&i2c1 {
+	battery: battery at b {
+		compatible = "ti,bq20z65", "sbs,sbs-battery";
+		reg = <0x0b>;
+
+		sbs,battery-detect-gpios = <&tca6424a 5 GPIO_ACTIVE_LOW>;
+		sbs,i2c-retry-count = <5>;
+
+		power-supplies = <&charger>;
+	};
+
+	codec: audio-codec at 1a {
+		compatible = "dlg,da7212";
+		reg = <0x1a>;
+		#sound-dai-cells = <0>;
+		VDDA-supply = <&reg_2v5_audio>;
+		VDDSP-supply = <&reg_5v0_audio>;
+		VDDMIC-supply = <&reg_3v3_audio>;
+		VDDIO-supply = <&reg_3v3_audio>;
+		clocks = <&clk_ext_audio_codec>;
+		clock-names = "mclk";
+	};
+};
+
+&i2c5 {
+	tmp75: temperature-sensor at 48 {
+		compatible = "ti,tmp75";
+		reg = <0x48>;
+		vs-supply = <&reg_3v3>;
+		interrupt-parent = <&tca6424a>;
+		interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+	};
+
+	tca6424a: gpio-controller at 22 {
+		compatible = "ti,tca6424";
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		vcc-supply = <&reg_3v3>;
+
+		interrupt-parent = <&gpio7>;
+		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_gpio6>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+
+		gpio-line-names = "GPIO_ROTOR#", "ACM_IO_INT", "TMP_SENSOR_IRQ", "AC_IN",
+				  "TF_S", "BATT_T", "LED_INC_CHAR", "ACM1_OCF",
+				  "ACM2_OCF", "ACM_IO_RST", "USB1_POWER_EN", "EGPIO_CC_CTL0",
+				  "EGPIO_CC_CTL1", "12V_OEMNBP_EN", "CP2105_RST", "",
+				  "SPEAKER_PA_EN", "ARM7_UPI_RESET", "ARM7_PWR_RST", "NURSE_CALL",
+				  "MARKER_EN", "EGPIO_TOUCH_RST", "PRESSURE_INT1", "PRESSURE_INT2";
+
+	};
+};
+
+&fec {
+	status = "okay";
+};
+
+&hdmi {
+	status = "okay";
+};
+
+&audmux {
+	status = "okay";
+};
+
+&ssi1 {
+	fsl,mode = "i2s-slave";
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&usb_power>;
+	disable-over-current;
+	dr_mode = "host";
+	status = "okay";
+
+	/*
+	 * TPS2051BDGN fault-gpio is connected to Q7[86] USB_0_1_OC_N.
+	 * On QMX6 this is not connceted to the i.MX6, but to the USB Hub
+	 * from &usbh1. This means, that we cannot easily detect and handle
+	 * over-current events. Fortunately the regulator limits the current
+	 * automatically, so the hardware is still protected.
+	 */
+};
+
+&pwm4 {
+	status = "okay";
+};
+
+&ldb {
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		status = "okay";
+		fsl,data-mapping = "spwg";
+		fsl,data-width = <24>;
+
+		port at 4 {
+			reg = <4>;
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&usdhc4 {
+	/* WiFi module */
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc4>;
+
+	bus-width = <4>;
+	no-1-8-v;
+	non-removable;
+	wakeup-source;
+	keep-power-in-suspend;
+	cap-power-off-card;
+	max-frequency = <25000000>;
+	vmmc-supply = <&reg_wlan>;
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	wlcore: wlcore at 2 {
+		compatible = "ti,wl1837";
+		reg = <2>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_q7_gpio7>;
+
+		interrupt-parent = <&gpio4>;
+		interrupts = <14 IRQ_TYPE_LEVEL_HIGH>;
+
+		tcxo-clock-frequency = <26000000>;
+	};
+
+};
diff --git a/arch/arm/boot/dts/imx6dl-b1x5v2.dtsi b/arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
new file mode 100644
index 000000000000..b4c6fbd802fb
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-b1x5v2.dtsi
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for General Electric B1x5v2
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+
+#include <dt-bindings/input/input.h>
+#include "imx6dl-b1x5pv2.dtsi"
+
+/ {
+	reg_3v3_acm: regulator-3v3-acm {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3 ACM";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		vin-supply = <&reg_3v3>;
+	};
+};
+
+&i2c1 {
+	tca6416: gpio-controller at 21 {
+		compatible = "ti,tca6416";
+		reg = <0x21>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		vcc-supply = <&reg_3v3_acm>;
+
+		/*
+		 * TCA6424 cannot handle low type interrupts at the moment and
+		 * it cannot be added without quite a few hacks. Since this
+		 * controller does not have any input type GPIOs, pretend that
+		 * the interrupt pin is unconnected.
+		 */
+		//interrupt-parent = <&tca6424a>;
+		//interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+		//interrupt-controller;
+		//#interrupt-cells = <2>;
+
+		reset-gpios = <&tca6424a 9 GPIO_ACTIVE_LOW>;
+
+		gpio-line-names = "ACM1_EN", "ACM1_CL0", "ACM1_CL1", "ACM1_CL2",
+				  "", "ACM2_EN", "ACM2_CL0", "ACM2_CL1",
+				  "ACM2_CL2", "", "", "",
+				  "", "", "", "";
+	};
+};
+
+&i2c5 {
+	mpl3115a2: pressure-sensor at 60 {
+		compatible = "fsl,mpl3115";
+		reg = <0x60>;
+
+		vcc-supply = <&reg_3v3_acm>;
+
+		/* The MPL3115 binding does not yet support interrupts */
+		//interrupt-parent = <&tca6424a>;
+		//interrupts = <22 IRQ_TYPE_EDGE_RISING 23 IRQ_TYPE_EDGE_RISING>;
+	};
+};
diff --git a/arch/arm/boot/dts/imx6dl-qmx6.dtsi b/arch/arm/boot/dts/imx6dl-qmx6.dtsi
new file mode 100644
index 000000000000..575dad47bf72
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-qmx6.dtsi
@@ -0,0 +1,624 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+//
+// Device Tree Source for i.MX6DL based congatec QMX6
+//
+// Copyright 2018-2021 General Electric Company
+// Copyright 2018-2021 Collabora
+// Copyright 2016 congatec AG
+
+#include "imx6dl.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+	memory at 10000000 {
+		reg = <0x10000000 0x40000000>;
+	};
+
+	reg_3p3v: 3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	i2cmux {
+		compatible = "i2c-mux-gpio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		mux-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>;
+		i2c-parent = <&i2c2>;
+
+		i2c5: i2c at 0 {
+			reg = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c6: i2c at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio3 19 0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "okay";
+
+	flash at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "sst,sst25vf032b", "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+
+		partition at 0 {
+			label = "bootloader";
+			reg = <0x0000000 0x100000>;
+		};
+
+		partition at 100000 {
+			label = "user";
+			reg = <0x0100000 0x2fc000>;
+		};
+
+		partition at 3fc000 {
+			label = "reserved";
+			reg = <0x03fc000 0x4000>;
+			read-only;
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet &pinctrl_phy_reset>;
+	phy-mode = "rgmii-id";
+	phy-reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+	fsl,magic-packet;
+	phy-handle = <&phy0>;
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		phy0: ethernet-phy at 6 {
+			reg = <6>;
+			qca,clk-out-frequency = <125000000>;
+		};
+	};
+};
+
+&i2c6 {
+	pmic at 8 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw2_reg: sw2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw3b_reg: sw3b {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			sw4_reg: sw4 {
+				regulator-min-microvolt = <675000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			/*
+			 * keep VGEN3, VGEN4 and VGEN5 enabled in order to
+			 * maintain backward compatibility with hw-rev. A.0
+			 */
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			/* supply voltage for eMMC */
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+};
+
+&pcie {
+	reset-gpio = <&gpio1 20 0>;
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux>;
+
+	audmux_ssi1 {
+		fsl,audmux-port = <MX51_AUDMUX_PORT1_SSI0>;
+		fsl,port-config = <
+			(IMX_AUDMUX_V2_PTCR_TFSDIR |
+			IMX_AUDMUX_V2_PTCR_TFSEL(MX51_AUDMUX_PORT6) |
+			IMX_AUDMUX_V2_PTCR_TCLKDIR |
+			IMX_AUDMUX_V2_PTCR_TCSEL(MX51_AUDMUX_PORT6) |
+			IMX_AUDMUX_V2_PTCR_SYN)
+			IMX_AUDMUX_V2_PDCR_RXDSEL(MX51_AUDMUX_PORT6)
+		>;
+	};
+
+	audmux_aud6 {
+		fsl,audmux-port = <MX51_AUDMUX_PORT6>;
+		fsl,port-config = <
+			IMX_AUDMUX_V2_PTCR_SYN
+			IMX_AUDMUX_V2_PDCR_RXDSEL(MX51_AUDMUX_PORT1_SSI0)
+		>;
+	};
+};
+
+&clks {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL2_PFD0_352M>,
+				 <&clks IMX6QDL_CLK_PLL2_PFD0_352M>;
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	pinctrl-1 = <&pinctrl_i2c1_gpio>;
+	scl-gpios = <&gpio3 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio3 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	pinctrl-1 = <&pinctrl_i2c2_gpio>;
+	scl-gpios = <&gpio4 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio4 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_gpio>;
+	scl-gpios = <&gpio1 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	sda-gpios = <&gpio1 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+	status = "okay";
+
+	rtc: m41t62 at 68 {
+		compatible = "st,m41t62";
+		reg = <0x68>;
+
+		rtc_sqw: clock {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+};
+
+&clks {
+	clocks = <&rtc_sqw>;
+	clock-names = "ckil";
+};
+
+&pwm4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm4>;
+};
+
+&reg_arm {
+	vin-supply = <&sw1a_reg>;
+};
+
+&reg_pu {
+	vin-supply = <&sw1c_reg>;
+};
+
+&reg_soc {
+	vin-supply = <&sw1c_reg>;
+};
+
+&snvs_poweroff {
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3>;
+	status = "okay";
+};
+
+&usdhc2 {
+	/* MicroSD card slot */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
+
+&usdhc3 {
+	/* eMMC module */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	non-removable;
+	bus-width = <8>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	vmmc-supply = <&reg_3p3v>;
+	status = "okay";
+};
+
+&usbh1 {
+	/* Connected to USB-Hub SMSC USB2514, provides P0, P2, P3, P4 on Qseven connector */
+	vbus-supply = <&reg_5v>;
+	status = "okay";
+};
+
+&usbotg {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+};
+
+&wdog1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	qmx6mux: imx6qdl-qmx6 {
+	};
+};
+
+&qmx6mux {
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_2__GPIO1_IO02		0x80000000 /* PCIE_WAKE_B */
+			MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09	0x80000000 /* I2C multiplexer */
+			MX6QDL_PAD_NANDF_D6__GPIO2_IO06		0x80000000 /* SD4_CD# */
+			MX6QDL_PAD_NANDF_D7__GPIO2_IO07		0x80000000 /* SD4_WP */
+			MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1		0x80000000 /* Camera MCLK */
+		>;
+	};
+
+	/* Watchdog output signal */
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT8__WDOG1_B		0x1b0b0
+		>;
+	};
+
+	pinctrl_q7_hda_rst: hdarstgrp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_ALE__GPIO6_IO08	0x1b0b0 /* Q7[61] HDA_RST_N */
+		>;
+	};
+
+	pinctrl_q7_backlight_enable: blengrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_9__GPIO1_IO09		0x1b0b0 /* Q7[112] LVDS_BLEN */
+		>;
+	};
+
+	pinctrl_audmux: audmuxgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DI0_PIN2__AUD6_TXD		0x110b0 /* Q7[67] HDA_SDO */
+			MX6QDL_PAD_DI0_PIN3__AUD6_TXFS		0x130b0 /* Q7[59] HDA_SYNC */
+			MX6QDL_PAD_DI0_PIN4__AUD6_RXD		0x130b0 /* Q7[65] HDA_SDI */
+			MX6QDL_PAD_DI0_PIN15__AUD6_TXC		0x130b0 /* Q7[63] HDA_BITCLK */
+		>;
+	};
+
+	/* SPI bus does not leave System on Module */
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D16__ECSPI1_SCLK		0x100b1
+			MX6QDL_PAD_EIM_D17__ECSPI1_MISO		0x100b1
+			MX6QDL_PAD_EIM_D18__ECSPI1_MOSI		0x100b1
+			MX6QDL_PAD_EIM_D19__GPIO3_IO19		0x1b0b0
+		>;
+	};
+
+	/* PHY is on System on Module, Q7[3-15] have Ethernet lines */
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x1b030
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x1b030
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x1b030
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x1b030
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x1b030
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x1b030
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x1b0b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b030
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b030
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b030
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b030
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b030
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b030
+			MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN	0x1b0b0
+		>;
+	};
+
+	/* RGMII Phy Reset */
+	pinctrl_phy_reset: phyrstgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D23__GPIO3_IO23		0x1b0b0
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D21__I2C1_SCL		0x4001b8b1 /* Q7[66] I2C_CLK */
+			MX6QDL_PAD_EIM_D28__I2C1_SDA		0x4001b8b1 /* Q7[68] I2C_DAT */
+		>;
+	};
+
+	pinctrl_i2c1_gpio: i2c1gpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D21__GPIO3_IO21		0x1b0b0 /* Q7[66] I2C_CLK */
+			MX6QDL_PAD_EIM_D28__GPIO3_IO28		0x1b0b0 /* Q7[68] I2C_DAT */
+		>;
+	};
+
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL		0x4001b8b1 /* Q7[152] SDVO_CTRL_CLK */
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA		0x4001b8b1 /* Q7[150] SDVO_CTRL_DAT */
+		>;
+	};
+
+	pinctrl_i2c2_gpio: i2c2gpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL3__GPIO4_IO12		0x1b0b0 /* Q7[152] SDVO_CTRL_CLK */
+			MX6QDL_PAD_KEY_ROW3__GPIO4_IO13		0x1b0b0 /* Q7[150] SDVO_CTRL_DAT */
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__I2C3_SCL		0x4001b8b1 /* Q7[60] SMB_CLK */
+			MX6QDL_PAD_GPIO_6__I2C3_SDA		0x4001b8b1 /* Q7[62] SMB_DAT */
+		>;
+	};
+
+	pinctrl_i2c3_gpio: i2c3gpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__GPIO1_IO03		0x1b0b0 /* Q7[60] SMB_CLK */
+			MX6QDL_PAD_GPIO_6__GPIO1_IO06		0x1b0b0 /* Q7[62] SMB_DAT */
+		>;
+	};
+
+	pinctrl_pwm4: pwm4grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_CMD__PWM4_OUT		0x1b0b1 /* Q7[123] LVDS_BLT_CTRL */
+		>;
+	};
+
+	/* Debug connector on Q7 module */
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D26__UART2_TX_DATA	0x1b0b1
+			MX6QDL_PAD_EIM_D27__UART2_RX_DATA	0x1b0b1
+		>;
+	};
+
+	pinctrl_uart3: uart3grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D25__UART3_RX_DATA	0x1b0b1 /* Q7[177] UART0_RX */
+			MX6QDL_PAD_EIM_D24__UART3_TX_DATA	0x1b0b1 /* Q7[171] UART0_TX */
+		>;
+	};
+
+	/* ?SD card slot on Q7 module */
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+			MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10059
+			MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+			MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+			MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+			MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+			MX6QDL_PAD_GPIO_4__GPIO1_IO04		0x1b0b0 /* SD2_CD */
+		>;
+	};
+
+	/* eMMC module on Q7 module */
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+			MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10059
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+		>;
+	};
+
+
+	pinctrl_usdhc4: usdhc4grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_CMD__SD4_CMD		0x17059 /* Q7[45] SDIO_CMD */
+			MX6QDL_PAD_SD4_CLK__SD4_CLK		0x17059 /* Q7[42] SDIO_CLK */
+			MX6QDL_PAD_SD4_DAT1__SD4_DATA1		0x17059 /* Q7[48] SDIO_DAT1 */
+			MX6QDL_PAD_SD4_DAT0__SD4_DATA0		0x17059 /* Q7[49] SDIO_DAT0 */
+			MX6QDL_PAD_SD4_DAT3__SD4_DATA3		0x17059 /* Q7[50] SDIO_DAT3 */
+			MX6QDL_PAD_SD4_DAT2__SD4_DATA2		0x17059 /* Q7[51] SDIO_DAT2 */
+		>;
+	};
+
+	pinctrl_q7_slp_btn: q7slpbtngrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW0__GPIO4_IO07		0x1b0b0 /* Q7[21] SLP_BTN# */
+		>;
+	};
+
+	pinctrl_q7_sdio_pwr: q7sdiopwrgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30	0x1b0b0 /* Q7[47] SDIO_PWR# */
+		>;
+	};
+
+	pinctrl_q7_gpio0: q7gpio0grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_A25__GPIO5_IO02		0x1b0b0 /* Q7[185] GPIO0 */
+		>;
+	};
+
+	pinctrl_q7_gpio1: q7gpio1grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_8__GPIO1_IO08		0x1b0b0 /* Q7[186] GPIO1 */
+		>;
+	};
+
+	pinctrl_q7_gpio2: q7gpio2grp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26	0x1b0b0 /* Q7[187] GPIO2 */
+		>;
+	};
+
+	pinctrl_q7_gpio3: q7gpio3grp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27	0x1b0b0 /* Q7[188] GPIO3 */
+		>;
+	};
+
+	pinctrl_q7_gpio4: q7gpio4grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_0__GPIO1_IO00		0x1b0b0 /* Q7[189] GPIO4 */
+		>;
+	};
+
+	pinctrl_q7_gpio5: q7gpio5grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW4__GPIO4_IO15		0x1b0b0 /* Q7[190] GPIO5 */
+		>;
+	};
+
+	pinctrl_q7_gpio6: q7gpio6grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_16__GPIO7_IO11		0x1b0b0 /* Q7[191] GPIO6 */
+		>;
+	};
+
+	pinctrl_q7_gpio7: q7gpio7grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL4__GPIO4_IO14		0x1b0b0 /* Q7[192] GPIO7 */
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__USB_OTG_ID		0x17059 /* Q7[92] USB_ID */
+		>;
+	};
+
+	pinctrl_q7_lcd_power: lcdpwrgrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_7__GPIO1_IO07		0x1b0b0 /* Q7[111] LVDS_PPEN */
+		>;
+	};
+
+	pinctrl_q7_spi_cs1: spics1grp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25	0x1b0b0 /* Q7[202] SPI_CS1# */
+		>;
+	};
+};
-- 
2.30.2



From lkp at intel.com  Wed Apr 28 23:31:05 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 29 Apr 2021 06:31:05 +0800
Subject: [xlnx:xlnx_rebase_v5.4 1296/1755]
 drivers/net/ethernet/cadence/macb_main.c:4573:58: sparse: sparse: incorrect
 type in argument 1 (different base types)
Message-ID: <202104290648.3umDEx1Q-lkp@intel.com>

Hi Vishal,

First bad commit (maybe != root cause):

tree:   https://github.com/Xilinx/linux-xlnx xlnx_rebase_v5.4
head:   77883b257c27f47445381c70c9236ade8f87eeaa
commit: 0b197959bbbdb68e1da974bd013339f08704b178 [1296/1755] staging: xlnxsync: Fix the uapi header license
config: i386-randconfig-s001-20210428 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-341-g8af24329-dirty
        # https://github.com/Xilinx/linux-xlnx/commit/0b197959bbbdb68e1da974bd013339f08704b178
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx xlnx_rebase_v5.4
        git checkout 0b197959bbbdb68e1da974bd013339f08704b178
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/net/ethernet/cadence/macb_main.c:274:16: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] bottom @@     got restricted __le32 [usertype] @@
   drivers/net/ethernet/cadence/macb_main.c:274:16: sparse:     expected unsigned int [usertype] bottom
   drivers/net/ethernet/cadence/macb_main.c:274:16: sparse:     got restricted __le32 [usertype]
   drivers/net/ethernet/cadence/macb_main.c:276:13: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned short [usertype] top @@     got restricted __le16 [usertype] @@
   drivers/net/ethernet/cadence/macb_main.c:276:13: sparse:     expected unsigned short [usertype] top
   drivers/net/ethernet/cadence/macb_main.c:276:13: sparse:     got restricted __le16 [usertype]
   drivers/net/ethernet/cadence/macb_main.c:2970:39: sparse: sparse: restricted __be32 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:2975:39: sparse: sparse: restricted __be32 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:2980:40: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:2980:69: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3002:20: sparse: sparse: restricted __be32 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3006:20: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] w0 @@     got restricted __be32 [usertype] ip4src @@
   drivers/net/ethernet/cadence/macb_main.c:3006:20: sparse:     expected unsigned int [assigned] [usertype] w0
   drivers/net/ethernet/cadence/macb_main.c:3006:20: sparse:     got restricted __be32 [usertype] ip4src
   drivers/net/ethernet/cadence/macb_main.c:3016:20: sparse: sparse: restricted __be32 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3020:20: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [assigned] [usertype] w0 @@     got restricted __be32 [usertype] ip4dst @@
   drivers/net/ethernet/cadence/macb_main.c:3020:20: sparse:     expected unsigned int [assigned] [usertype] w0
   drivers/net/ethernet/cadence/macb_main.c:3020:20: sparse:     got restricted __be32 [usertype] ip4dst
   drivers/net/ethernet/cadence/macb_main.c:3030:21: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3030:50: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3036:30: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3037:30: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3044:36: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3045:38: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3048:38: sparse: sparse: restricted __be16 degrades to integer
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned int [usertype] val @@     got restricted __be32 [usertype] ip4src @@
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     expected unsigned int [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     got restricted __be32 [usertype] ip4src
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned int [usertype] val @@     got restricted __be32 [usertype] ip4dst @@
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     expected unsigned int [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     got restricted __be32 [usertype] ip4dst
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned short [usertype] val @@     got restricted __be16 [usertype] psrc @@
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     expected unsigned short [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     got restricted __be16 [usertype] psrc
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned short [usertype] val @@     got restricted __be16 [usertype] pdst @@
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     expected unsigned short [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse:     got restricted __be16 [usertype] pdst
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3084:9: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned int [usertype] val @@     got restricted __be32 [usertype] ip4src @@
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     expected unsigned int [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     got restricted __be32 [usertype] ip4src
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned int [usertype] val @@     got restricted __be32 [usertype] ip4dst @@
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     expected unsigned int [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     got restricted __be32 [usertype] ip4dst
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be32
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned short [usertype] val @@     got restricted __be16 [usertype] psrc @@
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     expected unsigned short [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     got restricted __be16 [usertype] psrc
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned short [usertype] val @@     got restricted __be16 [usertype] pdst @@
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     expected unsigned short [usertype] val
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse:     got restricted __be16 [usertype] pdst
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
   drivers/net/ethernet/cadence/macb_main.c:3137:25: sparse: sparse: cast from restricted __be16
>> drivers/net/ethernet/cadence/macb_main.c:4573:58: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned int const [usertype] *p @@     got restricted __be32 [noderef] <asn:4> * @@
   drivers/net/ethernet/cadence/macb_main.c:4573:58: sparse:     expected unsigned int const [usertype] *p
   drivers/net/ethernet/cadence/macb_main.c:4573:58: sparse:     got restricted __be32 [noderef] <asn:4> *
   drivers/net/ethernet/cadence/macb_main.c:4573:41: sparse: sparse: restricted __be32 degrades to integer
>> drivers/net/ethernet/cadence/macb_main.c:4573:50: sparse: sparse: dereference of noderef expression
>> drivers/net/ethernet/cadence/macb_main.c:4573:50: sparse: sparse: dereference of noderef expression

vim +4573 drivers/net/ethernet/cadence/macb_main.c

89e5785fc8a6b9 drivers/net/macb.c                       Haavard Skinnemoen 2006-11-09  4527  
d23823dd61516b drivers/net/ethernet/cadence/macb.c      Michal Simek       2015-01-23  4528  static int __maybe_unused macb_suspend(struct device *dev)
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4529  {
ce886a4748aa58 drivers/net/ethernet/cadence/macb_main.c Wolfram Sang       2018-10-21  4530  	struct net_device *netdev = dev_get_drvdata(dev);
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4531  	struct macb *bp = netdev_priv(netdev);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4532  	struct macb_queue *queue = bp->queues;
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4533  	unsigned long flags;
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4534  	unsigned int q;
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4535  	u32 ctrl, arpipmask;
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4536  
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4537  	if (!netif_running(netdev))
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4538  		return 0;
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4539  
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4540  	if (device_may_wakeup(&bp->dev->dev)) {
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4541  		spin_lock_irqsave(&bp->lock, flags);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4542  		ctrl = macb_readl(bp, NCR);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4543  		ctrl &= ~(MACB_BIT(TE) | MACB_BIT(RE));
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4544  		macb_writel(bp, NCR, ctrl);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4545  		/* Tie off RX queues */
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4546  		for (q = 0, queue = bp->queues; q < bp->num_queues;
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4547  		     ++q, ++queue) {
c46aa57aa468c8 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4548  			if (bp->caps & MACB_CAPS_QUEUE_DISABLE)
c46aa57aa468c8 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4549  				queue_writel(queue, RBQP, GEM_RBQP_DISABLE);
c46aa57aa468c8 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4550  			else
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4551  				queue_writel(queue, RBQP,
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4552  					     lower_32_bits(bp->rx_ring_tieoff_dma));
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4553  		}
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4554  		ctrl = macb_readl(bp, NCR);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4555  		ctrl |= MACB_BIT(RE);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4556  		macb_writel(bp, NCR, ctrl);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4557  		gem_writel(bp, NCFGR, gem_readl(bp, NCFGR) & ~MACB_BIT(NBC));
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4558  		macb_writel(bp, TSR, -1);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4559  		macb_writel(bp, RSR, -1);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4560  		macb_readl(bp, ISR);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4561  		if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE)
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4562  			macb_writel(bp, ISR, -1);
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4563  
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4564  		/* Enable WOL (Q0 only) and disable all other interrupts */
3e2a5e15390643 drivers/net/ethernet/cadence/macb.c      Sergio Prado       2016-02-09  4565  		macb_writel(bp, IER, MACB_BIT(WOL));
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4566  		for (q = 1, queue = bp->queues; q < bp->num_queues;
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4567  		     ++q, ++queue) {
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4568  			queue_writel(queue, IDR, bp->rx_intr_mask |
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4569  						 MACB_TX_INT_FLAGS |
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4570  						 MACB_BIT(HRESP));
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4571  		}
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4572  
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31 @4573  		arpipmask = cpu_to_be32p(&bp->dev->ip_ptr->ifa_list->ifa_local)
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4574  					 & 0xFFFF;
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4575  		gem_writel(bp, WOL, MACB_BIT(ARP) | arpipmask);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4576  		spin_unlock_irqrestore(&bp->lock, flags);
3e2a5e15390643 drivers/net/ethernet/cadence/macb.c      Sergio Prado       2016-02-09  4577  		enable_irq_wake(bp->queues[0].irq);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4578  		netif_device_detach(netdev);
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4579  		for (q = 0, queue = bp->queues; q < bp->num_queues;
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4580  		     ++q, ++queue)
085d261535eb72 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2020-01-31  4581  			napi_disable(&queue->napi);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4582  	} else {
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4583  		netif_device_detach(netdev);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4584  		for (q = 0, queue = bp->queues; q < bp->num_queues;
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4585  		     ++q, ++queue)
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4586  			napi_disable(&queue->napi);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4587  		phy_stop(netdev->phydev);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4588  		phy_suspend(netdev->phydev);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4589  		spin_lock_irqsave(&bp->lock, flags);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4590  		macb_reset_hw(bp);
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4591  		spin_unlock_irqrestore(&bp->lock, flags);
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4592  
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4593  		if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4594  			bp->pm_data.usrio = macb_or_gem_readl(bp, USRIO);
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4595  
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4596  		if (netdev->hw_features & NETIF_F_NTUPLE)
c1e85c6ce57ef1 drivers/net/ethernet/cadence/macb_main.c Claudiu Beznea     2019-05-22  4597  			bp->pm_data.scrt2 = gem_readl_n(bp, ETHT, SCRT2_ETHT);
3e2a5e15390643 drivers/net/ethernet/cadence/macb.c      Sergio Prado       2016-02-09  4598  	}
d54f89af6cc4d6 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4599  
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4600  	if (bp->ptp_info)
de991c58b3761e drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4601  		bp->ptp_info->ptp_remove(netdev);
d54f89af6cc4d6 drivers/net/ethernet/cadence/macb_main.c Harini Katakam     2019-03-01  4602  	pm_runtime_force_suspend(dev);
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4603  
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4604  	return 0;
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4605  }
c1f598fd71db6a drivers/net/macb.c                       Haavard Skinnemoen 2008-03-04  4606  

:::::: The code at line 4573 was first introduced by commit
:::::: 085d261535eb72479ec3268db378ed493f1092f2 net: macb: Use WOL via ARP

:::::: TO: Harini Katakam <harini.katakam at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35530 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210429/dc860cac/attachment-0001.gz>

From s-anna at ti.com  Thu Apr 29 00:05:00 2021
From: s-anna at ti.com (Suman Anna)
Date: Wed, 28 Apr 2021 18:05:00 -0500
Subject: [PATCH] dt-bindings: mmc: sdhci-am654: Remove duplicate ti,
 j721e-sdhci-4bit
Message-ID: <20210428230500.19214-1-s-anna@ti.com>

The commit 7c7905df68c5 ("dt-bindings: mmc: sdhci-am654: fix compatible
for j7200") switched the compatible property from a regular enum to an
more appropriate combinatorial oneOf convention, and in the process has
introduced a duplicate ti,j721e-sdhci-4bit.

This generated the following warning on J721E boards that use the
ti,j721e-sdhci-4bit for two nodes:
 "mmc at 4fb0000: compatible: More than one condition true in oneOf schema"
 "mmc at 4f98000: compatible: More than one condition true in oneOf schema"

Remove the duplicate to fix this.

Fixes: 7c7905df68c5 ("dt-bindings: mmc: sdhci-am654: fix compatible for j7200")
Signed-off-by: Suman Anna <s-anna at ti.com>
---
Hi Ulf,

The warning is a bit more verbose, I have minimized the log in above
commit message. You can see the issue with dtbs_check on both latest
master and linux-next using DT_SCHEMA_FILES.

regards
Suman

 Documentation/devicetree/bindings/mmc/sdhci-am654.yaml | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
index 3a79e39253d2..29399e88ac53 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
+++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml
@@ -19,7 +19,6 @@ properties:
       - const: ti,am654-sdhci-5.1
       - const: ti,j721e-sdhci-8bit
       - const: ti,j721e-sdhci-4bit
-      - const: ti,j721e-sdhci-4bit
       - const: ti,am64-sdhci-8bit
       - const: ti,am64-sdhci-4bit
       - items:
-- 
2.30.1



From pr-tracker-bot at kernel.org  Thu Apr 29 00:13:04 2021
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Wed, 28 Apr 2021 23:13:04 +0000
Subject: [GIT PULL] Mailbox changes for v5.13
In-Reply-To: <CABb+yY0j+ENA=z40pCEZxGYJM-hXVxiYK0CU-OB4aA24SmV5nw@mail.gmail.com>
References: <CABb+yY0j+ENA=z40pCEZxGYJM-hXVxiYK0CU-OB4aA24SmV5nw@mail.gmail.com>
Message-ID: <161965158412.11634.6190199962132336537.pr-tracker-bot@kernel.org>

The pull request you sent on Wed, 28 Apr 2021 11:02:24 -0500:

> git://git.linaro.org/landing-teams/working/fujitsu/integration.git tags/mailbox-v5.13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d8201efe75e13146ebde433745c7920e15593baf

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From wangkefeng.wang at huawei.com  Thu Apr 29 01:48:26 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Thu, 29 Apr 2021 08:48:26 +0800
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <YIj5zcbHBHt7CC8B@kernel.org>
References: <9aa68d26-d736-3b75-4828-f148964eb7f0@huawei.com>
 <YIEl8aKr8Ly0Zd3O@kernel.org>
 <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
 <YIj5zcbHBHt7CC8B@kernel.org>
Message-ID: <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>


On 2021/4/28 13:59, Mike Rapoport wrote:
> On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
>> On 2021/4/27 14:23, Mike Rapoport wrote:
>>> On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
>>>> On 2021/4/26 13:20, Mike Rapoport wrote:
>>>>> On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
>>>>>> On 2021/4/25 15:19, Mike Rapoport wrote:
>>>>>>
>>>>>>        On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
>>>>>>
>>>>>>            I tested this patchset(plus arm32 change, like arm64 does)
>>>>>>            based on lts 5.10?add some debug log, the useful info shows
>>>>>>            below, if we enable HOLES_IN_ZONE, no panic, any idea,
>>>>>>            thanks.
>>>>>>
>>>>>>        Are there any changes on top of 5.10 except for pfn_valid() patch?
>>>>>>        Do you see this panic on 5.10 without the changes?
>>>>>>
>>>>>> Yes, there are some BSP support for arm board based on 5.10,
>>> Is it possible to test 5.12?
> Do you use SPARSMEM? If yes, what is your section size?
> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?

Yes,

CONFIG_SPARSEMEM=y

CONFIG_SPARSEMEM_STATIC=y

CONFIG_FORCE_MAX_ZONEORDER = 11

CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
#define SECTION_SIZE_BITS    26
#define MAX_PHYSADDR_BITS    32
#define MAX_PHYSMEM_BITS     32


>


From saravanak at google.com  Thu Apr 29 02:11:10 2021
From: saravanak at google.com (Saravana Kannan)
Date: Wed, 28 Apr 2021 18:11:10 -0700
Subject: [PATCHv2 1/5] rtc: m41t80: add support for fixed clock
In-Reply-To: <20210428222953.235280-2-sebastian.reichel@collabora.com>
References: <20210428222953.235280-1-sebastian.reichel@collabora.com>
 <20210428222953.235280-2-sebastian.reichel@collabora.com>
Message-ID: <CAGETcx_YoYJkOgh=kX7tZf-oAWGMmTDT+Azm1A3thWD1SRy_4A@mail.gmail.com>

On Wed, Apr 28, 2021 at 3:29 PM Sebastian Reichel
<sebastian.reichel at collabora.com> wrote:
>
> Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The
> modules SQW clock output defaults to 32768 Hz. This behaviour is
> used to provide the i.MX6 CKIL clock. Once the RTC driver is probed,
> the clock is disabled and all i.MX6 functionality depending on
> the 32 KHz clock has undefined behaviour. For example when using
> the hardware watchdog the system will likely do arbitrary reboots.
>
> Referencing the m41t62 directly results in a deadlock. The kernel
> will see, that i.MX6 system clock needs the RTC clock and do probe
> deferral. But the i.MX6 I2C module never becomes usable without the
> i.MX6 CKIL clock and thus the RTC's clock will not be probed. So
> from the kernel's perspective this is a chicken-and-egg problem.
>
> Technically everything is fine by not touching anything, since
> the RTC clock correctly enables the clock on reset (i.e. on
> battery backup power loss) and also the bootloader enables it
> in case an something (e.g. an unpatched kernel) disabled this
> incorrectly.
>
> A workaround for this issue is describing the square wave pin
> as fixed-clock, which is registered early and basically how
> this pin is used on the i.MX6.
>
> Suggested-by: Saravana Kannan <saravanak at google.com>
> Signed-off-by: Sebastian Reichel <sebastian.reichel at collabora.com>
> ---
>  Documentation/devicetree/bindings/rtc/rtc-m41t80.txt |  9 +++++++++
>  drivers/rtc/rtc-m41t80.c                             | 12 ++++++++++++
>  2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
> index c746cb221210..cdd196b1e9bd 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc-m41t80.txt
> @@ -21,10 +21,19 @@ Optional properties:
>                        clock name
>  - wakeup-source: Enables wake up of host system on alarm
>
> +Optional child node:
> +- clock: Provide this if the square wave pin is used as boot-enabled fixed clock.
> +
>  Example:
>         rtc at 68 {
>                 compatible = "st,m41t80";
>                 reg = <0x68>;
>                 interrupt-parent = <&UIC0>;
>                 interrupts = <0x9 0x8>;
> +
> +               clock {
> +                       compatible = "fixed-clock";
> +                       #clock-cells = <0>;
> +                       clock-frequency = <32768>;
> +               };
>         };
> diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
> index 89128fc29ccc..b3ece42b6f90 100644
> --- a/drivers/rtc/rtc-m41t80.c
> +++ b/drivers/rtc/rtc-m41t80.c
> @@ -544,10 +544,22 @@ static struct clk *m41t80_sqw_register_clk(struct m41t80_data *m41t80)
>  {
>         struct i2c_client *client = m41t80->client;
>         struct device_node *node = client->dev.of_node;
> +       struct device_node *fixed_clock;
>         struct clk *clk;
>         struct clk_init_data init;
>         int ret;
>
> +       fixed_clock = of_get_child_by_name(node, "clock");
> +       if (fixed_clock) {
> +               /*
> +                * skip registering square wave clock when a fixed
> +                * clock has been registered. The fixed clock is
> +                * registered automatically when being referenced.
> +                */
> +               of_node_put(fixed_clock);
> +               return 0;
> +       }
> +
>         /* First disable the clock */
>         ret = i2c_smbus_read_byte_data(client, M41T80_REG_ALARM_MON);
>         if (ret < 0)

Reviewed-by: Saravana Kannan <saravanak at google.com>

-Saravana


From yang.lee at linux.alibaba.com  Thu Apr 29 02:26:29 2021
From: yang.lee at linux.alibaba.com (Yang Li)
Date: Thu, 29 Apr 2021 09:26:29 +0800
Subject: [PATCH v2] psci: Remove unneeded semicolon
Message-ID: <1619659589-4775-1-git-send-email-yang.lee@linux.alibaba.com>

Eliminate the following coccicheck warning:
./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon

Reported-by: Abaci Robot <abaci at linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee at linux.alibaba.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---

Change in v2:
--subject should read "psci: Remove unneeded semicolon"

 drivers/firmware/psci/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 64344e8..6e7bac6 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -138,7 +138,7 @@ static int psci_to_linux_errno(int errno)
 		return -EINVAL;
 	case PSCI_RET_DENIED:
 		return -EPERM;
-	};
+	}
 
 	return -EINVAL;
 }
-- 
1.8.3.1



From leo.yan at linaro.org  Thu Apr 29 02:43:21 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 09:43:21 +0800
Subject: [PATCH] arm64: stacktrace: Stop unwinding when the PC is zero
Message-ID: <20210429014321.196606-1-leo.yan@linaro.org>

When use ftrace for stack trace, it reports the spurious frame with the
PC value is zero.  This can be reproduced with commands:

  # cd /sys/kernel/debug/tracing/
  # echo "prev_pid == 0" > events/sched/sched_switch/filter
  # echo stacktrace > events/sched/sched_switch/trigger
  # echo 1 > events/sched/sched_switch/enable
  # cat trace

           <idle>-0       [005] d..2   259.621390: sched_switch: ...
           <idle>-0       [005] d..3   259.621394: <stack trace>
  => __schedule
  => schedule_idle
  => do_idle
  => cpu_startup_entry
  => secondary_start_kernel
  => 0

The kernel initializes FP/PC values as zero for swapper threads in
head.S, when walk the stack frame, this patch stops unwinding if detect
the PC value is zero, therefore can avoid the spurious frame.

Below is the stacktrace after applying the change:

  # cat trace

           <idle>-0       [005] d..2   259.621390: sched_switch: ...
           <idle>-0       [005] d..3   259.621394: <stack trace>
  => __schedule
  => schedule_idle
  => do_idle
  => cpu_startup_entry
  => secondary_start_kernel

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/kernel/stacktrace.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 84b676bcf867..02b1e85b2026 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -145,7 +145,11 @@ void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
 		if (!fn(data, frame->pc))
 			break;
 		ret = unwind_frame(tsk, frame);
-		if (ret < 0)
+		/*
+		 * When the frame->pc is zero, it has reached to the initial pc
+		 * and fp values; stop unwinding for this case.
+		 */
+		if (ret < 0 || !frame->pc)
 			break;
 	}
 }
-- 
2.25.1



From laurent.pinchart at ideasonboard.com  Thu Apr 29 02:45:37 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 29 Apr 2021 04:45:37 +0300
Subject: [PATCH 2/6] media: v4l: Add definition for bayered IR formats
In-Reply-To: <20210427120701.21809-3-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-3-m.felsch@pengutronix.de>
Message-ID: <YIoPwYQel0J4qmPs@pendragon.ideasonboard.com>

Hi Marco,

Thank you for the patch.

On Tue, Apr 27, 2021 at 02:06:57PM +0200, Marco Felsch wrote:
> Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> with the interleaved IR pixels looks like:
> 
>         |  G |  R |  G |  B | ...
>         +----+----+----+----+---
>         | IR |  G | IR |  G | ...
>         +----+----+----+----+---
>         |  G |  B |  G |  R | ...
>         +----+----+----+----+---
>         | IR |  G | IR |  G | ...
>         +----+----+----+----+---
>         | .. | .. | .. | .. | ..
> 
> [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> 
> Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
>  include/uapi/linux/videodev2.h | 4 ++++

The documentation is missing.

>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 311a01cc5775..45ffd3867394 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -632,6 +632,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGBRG8  v4l2_fourcc('G', 'B', 'R', 'G') /*  8  GBGB.. RGRG.. */
>  #define V4L2_PIX_FMT_SGRBG8  v4l2_fourcc('G', 'R', 'B', 'G') /*  8  GRGR.. BGBG.. */
>  #define V4L2_PIX_FMT_SRGGB8  v4l2_fourcc('R', 'G', 'G', 'B') /*  8  RGRG.. GBGB.. */
> +	/* 8bit infrared interleaved bayer format */
> +#define V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG8 v4l2_fourcc('I', 'R', '0', '8') /* 8 GRGB.. IGIG.. GBGR.. IGIG.. */
>  #define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10  BGBG.. GRGR.. */
>  #define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10  GBGB.. RGRG.. */
>  #define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10  GRGR.. BGBG.. */
> @@ -673,6 +675,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_SGBRG16 v4l2_fourcc('G', 'B', '1', '6') /* 16  GBGB.. RGRG.. */
>  #define V4L2_PIX_FMT_SGRBG16 v4l2_fourcc('G', 'R', '1', '6') /* 16  GRGR.. BGBG.. */
>  #define V4L2_PIX_FMT_SRGGB16 v4l2_fourcc('R', 'G', '1', '6') /* 16  RGRG.. GBGB.. */
> +	/* 16bit infrared interleaved bayer format */
> +#define V4L2_PIX_FMT_SGRGB_IGIG_GBGR_IGIG16 v4l2_fourcc('I', 'R', '1', '6') /* 16 GRGB.. IGIG.. GBGR.. IGIG.. */
>  
>  /* HSV formats */
>  #define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')

-- 
Regards,

Laurent Pinchart


From laurent.pinchart at ideasonboard.com  Thu Apr 29 02:51:41 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 29 Apr 2021 04:51:41 +0300
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210427120701.21809-2-m.felsch@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
Message-ID: <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>

Hi Marco,

Thank you for the patch.

On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:
> Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> with the interleaved IR pixels looks like:
> 
>         |  G |  R |  G |  B | ...
>         +----+----+----+----+---
>         | IR |  G | IR |  G | ...
>         +----+----+----+----+---
>         |  G |  B |  G |  R | ...
>         +----+----+----+----+---
>         | IR |  G | IR |  G | ...
>         +----+----+----+----+---
>         | .. | .. | .. | .. | ..
> 
> [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf

I think we're reaching a limit of the media bus codes model here, due to
a historical mistake. The four possible Bayer patterns, times the
different number of bits per pixel, creates a lot of media bus codes,
and drivers for CSI-2 receivers and IP cores further down the pipeline
have to support them all. This is already painful, and if we had a
non-Bayer pattern such as this one, we'll open the door to an explosion
of the number of media bus codes (imagine all the different possible
arrangements of this pattern, for instance if you enable horizontal
and/or vertical flipping on the sensor). All drivers would need to be
updated to support these new bus codes, and this really kills the
current model.

The historical mistake was to tie the Bayer pattern with the media bus
code. We should really have specified raw 8/10/12/14/16 media bus codes,
and conveyed the pattern separately. Most IP cores in the pipeline don't
need to care about the pattern at all, and those who do (that's mostly
ISPs) could be programmed explicitly by userspace as long as we have an
API to retrieve the pattern from the sensor. I believe it's time to bite
the bullet and go in that direction. I'm sorry for this case of yak
shaving, but it really wouldn't be manageable anymore :-(

> Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
> ---
>  .../media/v4l/subdev-formats.rst              | 42 +++++++++++++++++++
>  include/uapi/linux/media-bus-format.h         |  4 +-
>  2 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> index bd68588b2683..d774ccd57c1b 100644
> --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
> +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> @@ -2252,6 +2252,27 @@ organization is given as an example for the first pixel only.
>        - g\ :sub:`2`
>        - g\ :sub:`1`
>        - g\ :sub:`0`
> +    * .. _MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8:
> +
> +      - MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8
> +      - 0x3021
> +      -
> +      -
> +      -
> +      -
> +      -
> +      -
> +      -
> +      -
> +      -
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
>      * .. _MEDIA-BUS-FMT-SRGGB8-1X8:
>  
>        - MEDIA_BUS_FMT_SRGGB8_1X8
> @@ -2748,6 +2769,27 @@ organization is given as an example for the first pixel only.
>        - g\ :sub:`2`
>        - g\ :sub:`1`
>        - g\ :sub:`0`
> +    * .. _MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12:
> +
> +      - MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12
> +      - 0x3022
> +      -
> +      -
> +      -
> +      -
> +      -
> +      - g\ :sub:`11`
> +      - g\ :sub:`10`
> +      - g\ :sub:`9`
> +      - g\ :sub:`8`
> +      - g\ :sub:`7`
> +      - g\ :sub:`6`
> +      - g\ :sub:`5`
> +      - g\ :sub:`4`
> +      - g\ :sub:`3`
> +      - g\ :sub:`2`
> +      - g\ :sub:`1`
> +      - g\ :sub:`0`
>      * .. _MEDIA-BUS-FMT-SRGGB12-1X12:
>  
>        - MEDIA_BUS_FMT_SRGGB12_1X12
> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
> index 0dfc11ee243a..cdd995e44926 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -112,10 +112,11 @@
>  #define MEDIA_BUS_FMT_YUV16_1X48		0x202a
>  #define MEDIA_BUS_FMT_UYYVYY16_0_5X48		0x202b
>  
> -/* Bayer - next is	0x3021 */
> +/* Bayer - next is	0x3023 */
>  #define MEDIA_BUS_FMT_SBGGR8_1X8		0x3001
>  #define MEDIA_BUS_FMT_SGBRG8_1X8		0x3013
>  #define MEDIA_BUS_FMT_SGRBG8_1X8		0x3002
> +#define MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG8_1X8	0x3021
>  #define MEDIA_BUS_FMT_SRGGB8_1X8		0x3014
>  #define MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8		0x3015
>  #define MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8		0x3016
> @@ -136,6 +137,7 @@
>  #define MEDIA_BUS_FMT_SBGGR12_1X12		0x3008
>  #define MEDIA_BUS_FMT_SGBRG12_1X12		0x3010
>  #define MEDIA_BUS_FMT_SGRBG12_1X12		0x3011
> +#define MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG12_1X12	0x3022
>  #define MEDIA_BUS_FMT_SRGGB12_1X12		0x3012
>  #define MEDIA_BUS_FMT_SBGGR14_1X14		0x3019
>  #define MEDIA_BUS_FMT_SGBRG14_1X14		0x301a

-- 
Regards,

Laurent Pinchart


From rex-bc.chen at mediatek.com  Thu Apr 29 03:23:46 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 10:23:46 +0800
Subject: [v2,PATCH 1/3] drm/mediatek: dpi dual edge sample mode support
In-Reply-To: <a1ffcce8-621e-7493-22d4-e28ff09c31a4@baylibre.com>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-2-git-send-email-rex-bc.chen@mediatek.com>
 <a1ffcce8-621e-7493-22d4-e28ff09c31a4@baylibre.com>
Message-ID: <21aa84ce0681ebc0682d9b9cad5b6180f3b0ea5b.camel@mediatek.com>

On Mon, 2021-04-19 at 09:36 +0200, Neil Armstrong wrote:
> Hi,
> 
> On 14/04/2021 15:35, Rex-BC Chen wrote:
> > DPI can sample on falling, rising or both edge.
> > When DPI sample the data both rising and falling edge.
> > It can reduce half data io pins.
> > 
> > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dpi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index b05f900d9322..21a3a7b78835 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -83,6 +83,7 @@ struct mtk_dpi {
> >  	struct pinctrl *pinctrl;
> >  	struct pinctrl_state *pins_gpio;
> >  	struct pinctrl_state *pins_dpi;
> > +	bool ddr_edge_sel;
> >  	int refcount;
> >  };
> >  
> > @@ -121,6 +122,7 @@ struct mtk_dpi_conf {
> >  	unsigned int (*cal_factor)(int clock);
> >  	u32 reg_h_fre_con;
> >  	bool edge_sel_en;
> > +	bool dual_edge;
> >  };
> >  
> >  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val,
> > u32 mask)
> > @@ -380,6 +382,15 @@ static void mtk_dpi_config_color_format(struct
> > mtk_dpi *dpi,
> >  	}
> >  }
> >  
> > +static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
> > +{
> > +	if (dpi->conf->dual_edge) {
> > +		mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
> > +			     DDR_EN | DDR_4PHASE);
> > +		mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, dpi->ddr_edge_sel 
> > ? EDGE_SEL : 0, EDGE_SEL);
> > +	}
> > +}
> > +
> 
> By using the downstream code as reference:
> 
> -       clk_set_rate(dpi->pixel_clk, vm.pixelclock);
> +       clk_set_rate(dpi->pixel_clk, vm.pixelclock * (dpi->conf-
> >dual_edge ? 2 : 1));
> 
> is missing in mtk_dpi_set_display_mode()
> 
Hello Neil,

Thanks for helping checking this.
I will add this modification for next patch.

BRs,
Rex-BC Chen
> >  static void mtk_dpi_power_off(struct mtk_dpi *dpi)
> >  {
> >  	if (WARN_ON(dpi->refcount == 0))
> > @@ -518,6 +529,7 @@ static int mtk_dpi_set_display_mode(struct
> > mtk_dpi *dpi,
> >  	mtk_dpi_config_yc_map(dpi, dpi->yc_map);
> >  	mtk_dpi_config_color_format(dpi, dpi->color_format);
> >  	mtk_dpi_config_2n_h_fre(dpi);
> > +	mtk_dpi_dual_edge(dpi);
> >  	mtk_dpi_config_disable_edge(dpi);
> >  	mtk_dpi_sw_reset(dpi, false);
> >  
> > 
> 
> Neil

From rex-bc.chen at mediatek.com  Thu Apr 29 03:27:58 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 10:27:58 +0800
Subject: [SPAM]Re: [SPAM][v2,PATCH 3/3] drm/mediatek: dpi: add bus
 format negotiation
In-Reply-To: <1618907471.11505.2.camel@mtksdaap41>
References: <1618407316-10042-1-git-send-email-rex-bc.chen@mediatek.com>
 <1618407316-10042-4-git-send-email-rex-bc.chen@mediatek.com>
 <1618448968.29238.1.camel@mtksdaap41> <1618467298.4349.3.camel@mtksdccf07>
 <1618907471.11505.2.camel@mtksdaap41>
Message-ID: <737326fb9699de6dcff3e655e8a1127a137f4750.camel@mediatek.com>

On Tue, 2021-04-20 at 16:31 +0800, CK Hu wrote:
> Hi, Rex:
> 
> On Thu, 2021-04-15 at 14:14 +0800, Rex-BC Chen wrote:
> > On Thu, 2021-04-15 at 09:09 +0800, CK Hu wrote:
> > Hello CK,
> > > Hi, Rex:
> > > 
> > > On Wed, 2021-04-14 at 21:35 +0800, Rex-BC Chen wrote:
> > > > Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts
> > > > to negotiate
> > > > the possible output and input formats for the current mode and
> > > > monitor,
> > > > and use the negotiated formats in a basic atomic_check
> > > > callback.
> > > > 
> > > > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > > > Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_dpi.c | 89
> > > > ++++++++++++++++++++++++++++--
> > > >  1 file changed, 84 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > > index 76431fe849b8..b4e9c6c8d706 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > > > @@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct
> > > > mtk_dpi *dpi,
> > > >  	return 0;
> > > >  }
> > > >  
> > > > +#define MAX_OUTPUT_SEL_FORMATS	2
> > > > +
> > > > +static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct
> > > > drm_bridge *bridge,
> > > > +					struct drm_bridge_state
> > > > *bridge_state,
> > > > +					struct drm_crtc_state
> > > > *crtc_state,
> > > > +					struct
> > > > drm_connector_state *conn_state,
> > > > +					unsigned int
> > > > *num_output_fmts)
> > > > +{
> > > > +	struct drm_display_mode *mode = &crtc_state->mode;
> > > > +	u32 *output_fmts;
> > > > +	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > > > +
> > > > +	*num_output_fmts = 0;
> > > > +
> > > > +	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS,
> > > > sizeof(*output_fmts),
> > > > +			      GFP_KERNEL);
> > > > +	if (!output_fmts)
> > > > +		return NULL;
> > > > +
> > > > +	/* Default 8bit RGB fallback */
> > > > +	if (dpi->conf->dual_edge) {
> > > > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
> > > > +		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
> > > 
> > > MT8183 does not support MEDIA_BUS_FMT_RGB888_1X24?
> > > 
> > > Regards,
> > > CK
> > > 
> > 
> > Yes, MT8183 only support MEDIA_BUS_FMT_RGB888_1X24
> 
> I'm confused with this answer. dpi->conf->dual_edge is true only in
> mt8183, but you say 'MT8183 only support MEDIA_BUS_FMT_RGB888_1X24',
> your answer looks conflict with these code.
> 
> Regards,
> CK
> 
Hello CK,

Sorry for my typo.

Input format for DPI in MT8183 only supports MEDIA_BUS_FMT_RGB888_1X24.
Output format for DPI in MT8183 only supports
MEDIA_BUS_FMT_RGB888_2x12.

dpi->conf->dual_edge means output format.
So MT8183 only support
MEDIA_BUS_FMT_RGB888_2x12.

BRs,
Rex-BC
> > 
> > BRs,
> > Rex-BC
> > > > +		*num_output_fmts = 2;
> > > > +	} else {
> > > > +		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
> > > > +		*num_output_fmts = 1;
> > > > +	}
> > > > +
> > > > +	return output_fmts;
> > > > +}
> > > > +
> > > > +#define MAX_INPUT_SEL_FORMATS	1
> > > > +
> > > > +static u32 *mtk_dpi_bridge_atomic_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)
> > > > +{
> > > > +	u32 *input_fmts;
> > > > +
> > > > +	*num_input_fmts = 0;
> > > > +
> > > > +	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS,
> > > > sizeof(*input_fmts),
> > > > +			     GFP_KERNEL);
> > > > +	if (!input_fmts)
> > > > +		return NULL;
> > > > +
> > > > +	*num_input_fmts = 1;
> > > > +	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> > > > +
> > > > +	return input_fmts;
> > > > +}
> > > > +
> > > > +static int mtk_dpi_bridge_atomic_check(struct drm_bridge
> > > > *bridge,
> > > > +				       struct drm_bridge_state
> > > > *bridge_state,
> > > > +				       struct drm_crtc_state
> > > > *crtc_state,
> > > > +				       struct
> > > > drm_connector_state *conn_state)
> > > > +{
> > > > +	struct mtk_dpi *dpi = bridge->driver_private;
> > > > +	unsigned int out_bus_format;
> > > > +
> > > > +	out_bus_format = bridge_state->output_bus_cfg.format;
> > > > +
> > > > +	dev_dbg(dpi->dev, "input format 0x%04x, output format
> > > > 0x%04x\n",
> > > > +		bridge_state->input_bus_cfg.format,
> > > > +		bridge_state->output_bus_cfg.format);
> > > > +
> > > > +	dpi->ddr_edge_sel = (out_bus_format ==
> > > > MEDIA_BUS_FMT_RGB888_2X12_LE) ?
> > > > +		 		true : false;
> > > > +
> > > > +	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > > > +	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > > > +	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > > > +	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +
> > > >  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> > > >  				 enum drm_bridge_attach_flags
> > > > flags)
> > > >  {
> > > > @@ -574,6 +655,9 @@ static const struct drm_bridge_funcs
> > > > mtk_dpi_bridge_funcs = {
> > > >  	.mode_set = mtk_dpi_bridge_mode_set,
> > > >  	.disable = mtk_dpi_bridge_disable,
> > > >  	.enable = mtk_dpi_bridge_enable,
> > > > +	.atomic_check = mtk_dpi_bridge_atomic_check,
> > > > +	.atomic_get_output_bus_fmts =
> > > > mtk_dpi_bridge_atomic_get_output_bus_fmts,
> > > > +	.atomic_get_input_bus_fmts =
> > > > mtk_dpi_bridge_atomic_get_input_bus_fmts,
> > > >  };
> > > >  
> > > >  void mtk_dpi_start(struct device *dev)
> > > > @@ -620,11 +704,6 @@ static int mtk_dpi_bind(struct device
> > > > *dev, struct device *master, void *data)
> > > >  	}
> > > >  	drm_connector_attach_encoder(dpi->connector, &dpi-
> > > > >encoder);
> > > >  
> > > > -	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
> > > > -	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
> > > > -	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
> > > > -	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
> > > > -
> > > >  	return 0;
> > > >  
> > > >  err_cleanup:
> > > 
> > > 
> > 
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek at lists.infradead.org
> > 
https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!wSbSRrRV87zBpi29W3qMJC0hPE5QwMj2oVUgPcq4538Poo-n0KFyM14woxJZbA$
> >  
> 
> 

From michael.kao at mediatek.com  Thu Apr 29 03:39:09 2021
From: michael.kao at mediatek.com (Michael Kao)
Date: Thu, 29 Apr 2021 10:39:09 +0800
Subject: [v7,3/3] thermal: mediatek: add another get_temp ops for
 thermal sensors
In-Reply-To: <dac1f9bc-6caa-9cb7-97d6-882a8bd20fea@linaro.org>
References: <20210316070144.28440-1-michael.kao@mediatek.com>
 <20210316070144.28440-4-michael.kao@mediatek.com>
 <dac1f9bc-6caa-9cb7-97d6-882a8bd20fea@linaro.org>
Message-ID: <91163899840b5009a9e02c3b08a6f4fbe194b40b.camel@mediatek.com>

On Fri, 2021-04-09 at 10:16 +0200, Daniel Lezcano wrote:
> On 16/03/2021 08:01, Michael Kao wrote:
> > Provide thermal zone to read thermal sensor
> > in the SoC. We can read all the thermal sensors
> > value in the SoC by the node /sys/class/thermal/
> > 
> > In mtk_thermal_bank_temperature, return -EAGAIN instead of -EACCESS
> > on the first read of sensor that often are bogus values.
> > This can avoid following warning on boot:
> > 
> >   thermal thermal_zone6: failed to read out thermal zone (-13)
> 
Hi Daniel,

> This patch is changing more things than described in the changelog.
> Is it possible to share some technical details about how the
> sensor(s)
> are working or point to some documentation if any ? and possibly the
> layout ?
=> All these sensors are used in the driver, mtk_thermal.c.
We just register thermal_zone0 for the max value of the sensors in the
SoC before.
Now, the svs module need to read the sensor in the soc separately, so
we register all the sensor in the soc to thermal zone for other module
can read sensor value by get_thermal_zone_by_name.
This patch does not change the logic of read thermal sensor.
We still use auxadc and select bank to read sensors by thermal
controller.


> IIUC there is a fake thermal zone zero with the purpose of
> aggregating
> all the other sensors by taking the max temperature of all the
> sensors.

=> Yes, thermal_zone0 is fake zone that will show the max temperature
of all the sensors. The thermal throttle will reference this thermal
zone.

> This patch adds a thermal zone per sensor, and each sensor is per
> CPU.
> CPU0 being actually the max of all the other sensors, right ?
> 
=> For 8192 [1], we add these thermal sensors in the soc.
cpu_big1 
cpu_big2 
cpu_big3 
cpu_big4 
cci1 
cci2 
cpu_little1 
cpu_little2 
apu 
mlda 
gpu1 
gpu2 
infra 
camsys 

[1] 
https://patchwork.kernel.org/project/linux-mediatek/patch/20201223074944.2061-1-michael.kao at mediatek.com/


> > Signed-off-by: Michael Kao <michael.kao at mediatek.com>
> > Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
> > ---
> >  drivers/thermal/mtk_thermal.c | 100 +++++++++++++++++++++++++-----
> > ----
> >  1 file changed, 75 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/thermal/mtk_thermal.c
> > b/drivers/thermal/mtk_thermal.c
> > index 149c6d7fd5a0..57e4f08a947e 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -245,6 +245,11 @@ enum mtk_thermal_version {
> >  
> >  struct mtk_thermal;
> >  
> > +struct mtk_thermal_zone {
> > +	struct mtk_thermal *mt;
> > +	int id;
> > +};
> > +
> >  struct thermal_bank_cfg {
> >  	unsigned int num_sensors;
> >  	const int *sensors;
> > @@ -637,6 +642,30 @@ static void mtk_thermal_put_bank(struct
> > mtk_thermal_bank *bank)
> >  		mutex_unlock(&mt->lock);
> >  }
> >  
> > +static u32 _get_sensor_temp(struct mtk_thermal *mt, int id)
> > +{
> > +	u32 raw;
> > +	int temp;
> > +
> > +	raw = readl(mt->thermal_base + mt->conf->msr[id]);
> > +
> > +	if (mt->conf->version == MTK_THERMAL_V1)
> > +		temp = raw_to_mcelsius_v1(mt, id, raw);
> > +	else
> > +		temp = raw_to_mcelsius_v2(mt, id, raw);
> > +
> > +	/*
> > +	 * The first read of a sensor often contains very high bogus
> > +	 * temperature value. Filter these out so that the system does
> > +	 * not immediately shut down.
> > +	 */
> > +
> > +	if (temp > 200000)
> > +		return -EAGAIN;
> > +	else
> > +		return temp;
> > +}
> > +
> >  /**
> >   * mtk_thermal_bank_temperature - get the temperature of a bank
> >   * @bank:	The bank
> > @@ -647,28 +676,11 @@ static void mtk_thermal_put_bank(struct
> > mtk_thermal_bank *bank)
> >  static int mtk_thermal_bank_temperature(struct mtk_thermal_bank
> > *bank)
> >  {
> >  	struct mtk_thermal *mt = bank->mt;
> > -	const struct mtk_thermal_data *conf = mt->conf;
> >  	int i, temp = INT_MIN, max = INT_MIN;
> > -	u32 raw;
> > -
> > -	for (i = 0; i < conf->bank_data[bank->id].num_sensors; i++) {
> > -		raw = readl(mt->thermal_base + conf->msr[i]);
> >  
> > -		if (mt->conf->version == MTK_THERMAL_V1) {
> > -			temp = raw_to_mcelsius_v1(
> > -				mt, conf->bank_data[bank-
> > >id].sensors[i], raw);
> > -		} else {
> > -			temp = raw_to_mcelsius_v2(
> > -				mt, conf->bank_data[bank-
> > >id].sensors[i], raw);
> > -		}
> > +	for (i = 0; i < mt->conf->bank_data[bank->id].num_sensors; i++)
> > {
> >  
> > -		/*
> > -		 * The first read of a sensor often contains very high
> > bogus
> > -		 * temperature value. Filter these out so that the
> > system does
> > -		 * not immediately shut down.
> > -		 */
> > -		if (temp > 200000)
> > -			temp = 0;
> > +		temp = _get_sensor_temp(mt, i);
> >  
> >  		if (temp > max)
> >  			max = temp;
> > @@ -679,7 +691,8 @@ static int mtk_thermal_bank_temperature(struct
> > mtk_thermal_bank *bank)
> >  
> >  static int mtk_read_temp(void *data, int *temperature)
> >  {
> > -	struct mtk_thermal *mt = data;
> > +	struct mtk_thermal_zone *tz = data;
> > +	struct mtk_thermal *mt = tz->mt;
> >  	int i;
> >  	int tempmax = INT_MIN;
> >  
> > @@ -698,10 +711,28 @@ static int mtk_read_temp(void *data, int
> > *temperature)
> >  	return 0;
> >  }
> >  
> > +static int mtk_read_sensor_temp(void *data, int *temperature)
> > +{
> > +	struct mtk_thermal_zone *tz = data;
> > +	struct mtk_thermal *mt = tz->mt;
> > +	int id = tz->id - 1;
> > +
> > +	if (id < 0)
> > +		return -EACCES;
> > +
> > +	*temperature = _get_sensor_temp(mt, id);
> > +
> > +	return 0;
> > +}
> > +
> >  static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
> >  	.get_temp = mtk_read_temp,
> >  };
> >  
> > +static const struct thermal_zone_of_device_ops
> > mtk_thermal_sensor_ops = {
> > +	.get_temp = mtk_read_sensor_temp,
> > +};
> > +
> >  static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> >  				  u32 apmixed_phys_base, u32
> > auxadc_phys_base,
> >  				  int ctrl_id)
> > @@ -992,6 +1023,7 @@ static int mtk_thermal_probe(struct
> > platform_device *pdev)
> >  	u64 auxadc_phys_base, apmixed_phys_base;
> >  	struct thermal_zone_device *tzdev;
> >  	void __iomem *apmixed_base, *auxadc_base;
> > +	struct mtk_thermal_zone *tz;
> >  
> >  	mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
> >  	if (!mt)
> > @@ -1080,11 +1112,29 @@ static int mtk_thermal_probe(struct
> > platform_device *pdev)
> >  
> >  	platform_set_drvdata(pdev, mt);
> >  
> > -	tzdev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, mt,
> > -						     &mtk_thermal_ops);
> > -	if (IS_ERR(tzdev)) {
> > -		ret = PTR_ERR(tzdev);
> > -		goto err_disable_clk_peri_therm;
> > +	for (i = 0; i < mt->conf->num_sensors + 1; i++) {
> > +		tz = devm_kmalloc(&pdev->dev, sizeof(*tz), GFP_KERNEL);
> > +		if (!tz)
> > +			return -ENOMEM;
> > +
> > +		tz->mt = mt;
> > +		tz->id = i;
> > +
> > +		tzdev = devm_thermal_zone_of_sensor_register(&pdev-
> > >dev, i, tz, (i == 0) ?
> > +							     &mtk_therm
> > al_ops :
> > +							     &mtk_therm
> > al_sensor_ops);
> > +
> > +		if (IS_ERR(tzdev)) {
> > +			if (PTR_ERR(tzdev) == -ENODEV) {
> > +				dev_warn(&pdev->dev,
> > +					 "sensor %d not registered in
> > thermal zone in dt\n", i);
> > +				continue;
> > +			}
> > +			if (PTR_ERR(tzdev) == -EACCES) {
> > +				ret = PTR_ERR(tzdev);
> > +				goto err_disable_clk_peri_therm;
> > +			}
> > +		}
> >  	}
> >  
> >  	return 0;
> > 
> 
> 

From shengjiu.wang at nxp.com  Thu Apr 29 03:50:27 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 29 Apr 2021 10:50:27 +0800
Subject: [PATCH 2/2] ARM: dts: imx6qdl-sabresd: Configure the gpio for hp
 detect
In-Reply-To: <1619664627-12470-1-git-send-email-shengjiu.wang@nxp.com>
References: <1619664627-12470-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <1619664627-12470-2-git-send-email-shengjiu.wang@nxp.com>

Configure the gpio for hp detect for wm8962 sound card

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index d20eaac6c5d6..4728dc612912 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -97,6 +97,8 @@ sound {
 		compatible = "fsl,imx6q-sabresd-wm8962",
 			   "fsl,imx-audio-wm8962";
 		model = "wm8962-audio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_hp>;
 		ssi-controller = <&ssi2>;
 		audio-codec = <&codec>;
 		audio-asrc = <&asrc>;
@@ -546,6 +548,13 @@ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE	0x1f8b0
 			>;
 		};
 
+		pinctrl_hp: hpgrp {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_RST__GPIO7_IO08          0x80000000
+				MX6QDL_PAD_GPIO_9__GPIO1_IO09           0x80000000
+			>;
+		};
+
 		pinctrl_i2c1: i2c1grp {
 			fsl,pins = <
 				MX6QDL_PAD_CSI0_DAT8__I2C1_SDA		0x4001b8b1
-- 
2.27.0



From shengjiu.wang at nxp.com  Thu Apr 29 03:50:26 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 29 Apr 2021 10:50:26 +0800
Subject: [PATCH 1/2] ARM: dts: imx6qdl-sabresd: Add asrc support for wm8962
 sound card
Message-ID: <1619664627-12470-1-git-send-email-shengjiu.wang@nxp.com>

Add asrc support for wm8962 sound card.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index f824c9abd11a..d20eaac6c5d6 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -99,6 +99,7 @@ sound {
 		model = "wm8962-audio";
 		ssi-controller = <&ssi2>;
 		audio-codec = <&codec>;
+		audio-asrc = <&asrc>;
 		audio-routing =
 			"Headphone Jack", "HPOUTL",
 			"Headphone Jack", "HPOUTR",
-- 
2.27.0



From shengjiu.wang at nxp.com  Thu Apr 29 03:52:19 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 29 Apr 2021 10:52:19 +0800
Subject: [PATCH] ARM: dts: imx6ul: Switch to fsl-asoc-card sound card
Message-ID: <1619664739-12589-1-git-send-email-shengjiu.wang@nxp.com>

There is issue with simple sound card, the simple sound
card can't configure the pll of codec.

[  115.352669] wm8960 1-001a: failed to configure clock
[  115.358843] wm8960 1-001a: ASoC: error at snd_soc_dai_hw_params on wm8960-hifi: -22

So Switch to fsl-asoc-card and the fsl-asoc-card can support
asrc module as front-end component.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 50 +++++++++++--------------
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 5a1e10def6ef..779cc536566d 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -60,38 +60,26 @@ reg_can_3v3: regulator-can-3v3 {
 		gpios = <&gpio_spi 3 GPIO_ACTIVE_LOW>;
 	};
 
-	sound {
-		compatible = "simple-audio-card";
-		simple-audio-card,name = "mx6ul-wm8960";
-		simple-audio-card,format = "i2s";
-		simple-audio-card,bitclock-master = <&dailink_master>;
-		simple-audio-card,frame-master = <&dailink_master>;
-		simple-audio-card,widgets =
-			"Microphone", "Mic Jack",
-			"Line", "Line In",
-			"Line", "Line Out",
-			"Speaker", "Speaker",
-			"Headphone", "Headphone Jack";
-		simple-audio-card,routing =
+	sound-wm8960 {
+		compatible = "fsl,imx-audio-wm8960";
+		model = "wm8960-audio";
+		audio-cpu = <&sai2>;
+		audio-codec = <&codec>;
+		audio-asrc = <&asrc>;
+		hp-det-gpio = <&gpio5 4 0>;
+		audio-routing =
 			"Headphone Jack", "HP_L",
 			"Headphone Jack", "HP_R",
-			"Speaker", "SPK_LP",
-			"Speaker", "SPK_LN",
-			"Speaker", "SPK_RP",
-			"Speaker", "SPK_RN",
-			"LINPUT1", "Mic Jack",
+			"Ext Spk", "SPK_LP",
+			"Ext Spk", "SPK_LN",
+			"Ext Spk", "SPK_RP",
+			"Ext Spk", "SPK_RN",
+			"LINPUT2", "Mic Jack",
 			"LINPUT3", "Mic Jack",
-			"RINPUT1", "Mic Jack",
-			"RINPUT2", "Mic Jack";
-
-		simple-audio-card,cpu {
-			sound-dai = <&sai2>;
-		};
-
-		dailink_master: simple-audio-card,codec {
-			sound-dai = <&codec>;
-			clocks = <&clks IMX6UL_CLK_SAI2>;
-		};
+			"RINPUT1", "AMIC",
+			"RINPUT2", "AMIC",
+			"Mic Jack", "MICB",
+			"AMIC", "MICB";
 	};
 
 	spi4 {
@@ -145,6 +133,10 @@ codec: wm8960 at 1a {
 		compatible = "wlf,wm8960";
 		reg = <0x1a>;
 		wlf,shared-lrclk;
+		wlf,hp-cfg = <3 2 3>;
+		wlf,gpio-cfg = <1 3>;
+		clocks = <&clks IMX6UL_CLK_SAI2>;
+		clock-names = "mclk";
 	};
 
 	camera at 3c {
-- 
2.27.0



From shengjiu.wang at nxp.com  Thu Apr 29 03:52:35 2021
From: shengjiu.wang at nxp.com (Shengjiu Wang)
Date: Thu, 29 Apr 2021 10:52:35 +0800
Subject: [PATCH] ARM: dts: imx7d-sdb: Add HDMI audio sound card
Message-ID: <1619664755-12631-1-git-send-email-shengjiu.wang@nxp.com>

Add HDMI audio sound card, the interface is sii902x.

Signed-off-by: Shengjiu Wang <shengjiu.wang at nxp.com>
---
 arch/arm/boot/dts/imx7d-sdb.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index ac0751bc1177..4a0d83784d7d 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -164,6 +164,13 @@ sound {
 			"LINPUT1", "AMIC",
 			"AMIC", "MICB";
 	};
+
+	sound-hdmi {
+		compatible = "fsl,imx-audio-sii902x";
+		model = "sii902x-audio";
+		audio-cpu = <&sai3>;
+		hdmi-out;
+	};
 };
 
 &adc1 {
-- 
2.27.0



From martin.petersen at oracle.com  Thu Apr 29 04:10:55 2021
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Wed, 28 Apr 2021 23:10:55 -0400
Subject: [PATCH v21 0/2] Enable power management for ufs wlun
In-Reply-To: <cover.1619223249.git.asutoshd@codeaurora.org> (Asutosh Das's
 message of "Fri, 23 Apr 2021 17:20:15 -0700")
References: <cover.1619223249.git.asutoshd@codeaurora.org>
Message-ID: <yq1y2d1lr9m.fsf@ca-mkp.ca.oracle.com>


Asutosh,

> This patch attempts to fix a deadlock in ufs while sending SSU.

Applied to 5.14/scsi-staging, thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering


From rex-bc.chen at mediatek.com  Thu Apr 29 04:45:45 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 11:45:45 +0800
Subject: [v3,PATCH 0/3] mt8183 dpi supports dual edge
Message-ID: <20210429034548.28030-1-rex-bc.chen@mediatek.com>

v3:
Modify clock rate for dual edge setting.
Add more bridge function.

v2:
Modify unused code

v1:
DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Rex-BC Chen (3):
  drm/mediatek: dpi dual edge sample mode support
  drm/mediatek: config mt8183 driver data to support dual edge sample
  drm/mediatek: dpi: add bus format negotiation

 drivers/gpu/drm/mediatek/mtk_dpi.c | 107 +++++++++++++++++++++++++++--
 1 file changed, 101 insertions(+), 6 deletions(-)

-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 04:45:47 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 11:45:47 +0800
Subject: [v3,
 PATCH 2/3] drm/mediatek: config mt8183 driver data to support dual
 edge sample
In-Reply-To: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
References: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429034548.28030-3-rex-bc.chen@mediatek.com>

add dual_edge value for mt8183_conf

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 79f3e83f40ef..c548780dd3a5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -691,6 +691,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
 static const struct mtk_dpi_conf mt8183_conf = {
 	.cal_factor = mt8183_calculate_factor,
 	.reg_h_fre_con = 0xe0,
+	.dual_edge = true,
 };
 
 static int mtk_dpi_probe(struct platform_device *pdev)
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 04:45:46 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 11:45:46 +0800
Subject: [v3,PATCH 1/3] drm/mediatek: dpi dual edge sample mode support
In-Reply-To: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
References: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429034548.28030-2-rex-bc.chen@mediatek.com>

DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index b05f900d9322..79f3e83f40ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -83,6 +83,7 @@ struct mtk_dpi {
 	struct pinctrl *pinctrl;
 	struct pinctrl_state *pins_gpio;
 	struct pinctrl_state *pins_dpi;
+	bool ddr_edge_sel;
 	int refcount;
 };
 
@@ -121,6 +122,7 @@ struct mtk_dpi_conf {
 	unsigned int (*cal_factor)(int clock);
 	u32 reg_h_fre_con;
 	bool edge_sel_en;
+	bool dual_edge;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -380,6 +382,15 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
 	}
 }
 
+static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
+{
+	if (dpi->conf->dual_edge) {
+		mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+			     DDR_EN | DDR_4PHASE);
+		mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, dpi->ddr_edge_sel ? EDGE_SEL : 0, EDGE_SEL);
+	}
+}
+
 static void mtk_dpi_power_off(struct mtk_dpi *dpi)
 {
 	if (WARN_ON(dpi->refcount == 0))
@@ -454,7 +465,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	pll_rate = clk_get_rate(dpi->tvd_clk);
 
 	vm.pixelclock = pll_rate / factor;
-	clk_set_rate(dpi->pixel_clk, vm.pixelclock);
+	clk_set_rate(dpi->pixel_clk, vm.pixelclock * (dpi->conf->dual_edge ? 2 : 1));
 	vm.pixelclock = clk_get_rate(dpi->pixel_clk);
 
 	dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
@@ -518,6 +529,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	mtk_dpi_config_yc_map(dpi, dpi->yc_map);
 	mtk_dpi_config_color_format(dpi, dpi->color_format);
 	mtk_dpi_config_2n_h_fre(dpi);
+	mtk_dpi_dual_edge(dpi);
 	mtk_dpi_config_disable_edge(dpi);
 	mtk_dpi_sw_reset(dpi, false);
 
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 04:45:48 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 11:45:48 +0800
Subject: [v3,PATCH 3/3] drm/mediatek: dpi: add bus format negotiation
In-Reply-To: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
References: <20210429034548.28030-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429034548.28030-4-rex-bc.chen@mediatek.com>

Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 92 ++++++++++++++++++++++++++++--
 1 file changed, 87 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index c548780dd3a5..8822d9448ae8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	return 0;
 }
 
+#define MAX_OUTPUT_SEL_FORMATS	2
+
+static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
+					struct drm_bridge_state *bridge_state,
+					struct drm_crtc_state *crtc_state,
+					struct drm_connector_state *conn_state,
+					unsigned int *num_output_fmts)
+{
+	u32 *output_fmts;
+	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+	*num_output_fmts = 0;
+
+	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
+			      GFP_KERNEL);
+	if (!output_fmts)
+		return NULL;
+
+	/* Default 8bit RGB fallback */
+	if (dpi->conf->dual_edge) {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
+		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
+		*num_output_fmts = 2;
+	} else {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
+		*num_output_fmts = 1;
+	}
+
+	return output_fmts;
+}
+
+#define MAX_INPUT_SEL_FORMATS	1
+
+static u32 *mtk_dpi_bridge_atomic_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)
+{
+	u32 *input_fmts;
+
+	*num_input_fmts = 0;
+
+	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+			     GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	*num_input_fmts = 1;
+	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+
+	return input_fmts;
+}
+
+static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
+				       struct drm_bridge_state *bridge_state,
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
+{
+	struct mtk_dpi *dpi = bridge->driver_private;
+	unsigned int out_bus_format;
+
+	out_bus_format = bridge_state->output_bus_cfg.format;
+
+	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
+		bridge_state->input_bus_cfg.format,
+		bridge_state->output_bus_cfg.format);
+
+	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
+				true : false;
+
+	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
+	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
+	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
+	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
+
+	return 0;
+}
+
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 				 enum drm_bridge_attach_flags flags)
 {
@@ -574,6 +655,12 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
 	.mode_set = mtk_dpi_bridge_mode_set,
 	.disable = mtk_dpi_bridge_disable,
 	.enable = mtk_dpi_bridge_enable,
+	.atomic_check = mtk_dpi_bridge_atomic_check,
+	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
+	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_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,
 };
 
 void mtk_dpi_start(struct device *dev)
@@ -620,11 +707,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
 	}
 	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
 
-	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
-	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
-	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
-	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
-
 	return 0;
 
 err_cleanup:
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 05:16:40 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 12:16:40 +0800
Subject: [v3 RESEND,
 PATCH 2/3] drm/mediatek: config mt8183 driver data to support dual
 edge sample
In-Reply-To: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
References: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429041641.11077-3-rex-bc.chen@mediatek.com>

add dual_edge value for mt8183_conf

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 79f3e83f40ef..c548780dd3a5 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -691,6 +691,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
 static const struct mtk_dpi_conf mt8183_conf = {
 	.cal_factor = mt8183_calculate_factor,
 	.reg_h_fre_con = 0xe0,
+	.dual_edge = true,
 };
 
 static int mtk_dpi_probe(struct platform_device *pdev)
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 05:16:39 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 12:16:39 +0800
Subject: [v3 RESEND, PATCH 1/3] drm/mediatek: dpi dual edge sample mode support
In-Reply-To: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
References: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429041641.11077-2-rex-bc.chen@mediatek.com>

DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index b05f900d9322..79f3e83f40ef 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -83,6 +83,7 @@ struct mtk_dpi {
 	struct pinctrl *pinctrl;
 	struct pinctrl_state *pins_gpio;
 	struct pinctrl_state *pins_dpi;
+	bool ddr_edge_sel;
 	int refcount;
 };
 
@@ -121,6 +122,7 @@ struct mtk_dpi_conf {
 	unsigned int (*cal_factor)(int clock);
 	u32 reg_h_fre_con;
 	bool edge_sel_en;
+	bool dual_edge;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -380,6 +382,15 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
 	}
 }
 
+static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
+{
+	if (dpi->conf->dual_edge) {
+		mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE,
+			     DDR_EN | DDR_4PHASE);
+		mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, dpi->ddr_edge_sel ? EDGE_SEL : 0, EDGE_SEL);
+	}
+}
+
 static void mtk_dpi_power_off(struct mtk_dpi *dpi)
 {
 	if (WARN_ON(dpi->refcount == 0))
@@ -454,7 +465,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	pll_rate = clk_get_rate(dpi->tvd_clk);
 
 	vm.pixelclock = pll_rate / factor;
-	clk_set_rate(dpi->pixel_clk, vm.pixelclock);
+	clk_set_rate(dpi->pixel_clk, vm.pixelclock * (dpi->conf->dual_edge ? 2 : 1));
 	vm.pixelclock = clk_get_rate(dpi->pixel_clk);
 
 	dev_dbg(dpi->dev, "Got  PLL %lu Hz, pixel clock %lu Hz\n",
@@ -518,6 +529,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	mtk_dpi_config_yc_map(dpi, dpi->yc_map);
 	mtk_dpi_config_color_format(dpi, dpi->color_format);
 	mtk_dpi_config_2n_h_fre(dpi);
+	mtk_dpi_dual_edge(dpi);
 	mtk_dpi_config_disable_edge(dpi);
 	mtk_dpi_sw_reset(dpi, false);
 
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 05:16:41 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 12:16:41 +0800
Subject: [v3 RESEND,PATCH 3/3] drm/mediatek: dpi: add bus format negotiation
In-Reply-To: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
References: <20210429041641.11077-1-rex-bc.chen@mediatek.com>
Message-ID: <20210429041641.11077-4-rex-bc.chen@mediatek.com>

Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negotiate
the possible output and input formats for the current mode and monitor,
and use the negotiated formats in a basic atomic_check callback.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Signed-off-by: Rex-BC Chen <rex-bc.chen at mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 92 ++++++++++++++++++++++++++++--
 1 file changed, 87 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index c548780dd3a5..8822d9448ae8 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -536,6 +536,87 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
 	return 0;
 }
 
+#define MAX_OUTPUT_SEL_FORMATS	2
+
+static u32 *mtk_dpi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
+					struct drm_bridge_state *bridge_state,
+					struct drm_crtc_state *crtc_state,
+					struct drm_connector_state *conn_state,
+					unsigned int *num_output_fmts)
+{
+	u32 *output_fmts;
+	struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+	*num_output_fmts = 0;
+
+	output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
+			      GFP_KERNEL);
+	if (!output_fmts)
+		return NULL;
+
+	/* Default 8bit RGB fallback */
+	if (dpi->conf->dual_edge) {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_2X12_LE;
+		output_fmts[1] =  MEDIA_BUS_FMT_RGB888_2X12_BE;
+		*num_output_fmts = 2;
+	} else {
+		output_fmts[0] =  MEDIA_BUS_FMT_RGB888_1X24;
+		*num_output_fmts = 1;
+	}
+
+	return output_fmts;
+}
+
+#define MAX_INPUT_SEL_FORMATS	1
+
+static u32 *mtk_dpi_bridge_atomic_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)
+{
+	u32 *input_fmts;
+
+	*num_input_fmts = 0;
+
+	input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+			     GFP_KERNEL);
+	if (!input_fmts)
+		return NULL;
+
+	*num_input_fmts = 1;
+	input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+
+	return input_fmts;
+}
+
+static int mtk_dpi_bridge_atomic_check(struct drm_bridge *bridge,
+				       struct drm_bridge_state *bridge_state,
+				       struct drm_crtc_state *crtc_state,
+				       struct drm_connector_state *conn_state)
+{
+	struct mtk_dpi *dpi = bridge->driver_private;
+	unsigned int out_bus_format;
+
+	out_bus_format = bridge_state->output_bus_cfg.format;
+
+	dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
+		bridge_state->input_bus_cfg.format,
+		bridge_state->output_bus_cfg.format);
+
+	dpi->ddr_edge_sel = (out_bus_format == MEDIA_BUS_FMT_RGB888_2X12_LE) ?
+				true : false;
+
+	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
+	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
+	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
+	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
+
+	return 0;
+}
+
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 				 enum drm_bridge_attach_flags flags)
 {

@@ -574,6 +655,12 @@ static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
 	.mode_set = mtk_dpi_bridge_mode_set,
 	.disable = mtk_dpi_bridge_disable,
 	.enable = mtk_dpi_bridge_enable,
+	.atomic_check = mtk_dpi_bridge_atomic_check,
+	.atomic_get_output_bus_fmts = mtk_dpi_bridge_atomic_get_output_bus_fmts,
+	.atomic_get_input_bus_fmts = mtk_dpi_bridge_atomic_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,
 };
 
 void mtk_dpi_start(struct device *dev)
@@ -620,11 +707,6 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
 	}
 	drm_connector_attach_encoder(dpi->connector, &dpi->encoder);
 
-	dpi->bit_num = MTK_DPI_OUT_BIT_NUM_8BITS;
-	dpi->channel_swap = MTK_DPI_OUT_CHANNEL_SWAP_RGB;
-	dpi->yc_map = MTK_DPI_OUT_YC_MAP_RGB;
-	dpi->color_format = MTK_DPI_COLOR_FORMAT_RGB;
-
 	return 0;
 
 err_cleanup:
-- 
2.18.0

From rex-bc.chen at mediatek.com  Thu Apr 29 05:16:38 2021
From: rex-bc.chen at mediatek.com (Rex-BC Chen)
Date: Thu, 29 Apr 2021 12:16:38 +0800
Subject: [v3 RESEND,PATCH 0/3] mt8183 dpi supports dual edge
Message-ID: <20210429041641.11077-1-rex-bc.chen@mediatek.com>

v3:
Modify clock rate for dual edge setting.
Add more bridge function.

v2:
Modify unused code

v1:
DPI can sample on falling, rising or both edge.
When DPI sample the data both rising and falling edge.
It can reduce half data io pins.

Rex-BC Chen (3):
  drm/mediatek: dpi dual edge sample mode support
  drm/mediatek: config mt8183 driver data to support dual edge sample
  drm/mediatek: dpi: add bus format negotiation

 drivers/gpu/drm/mediatek/mtk_dpi.c | 107 +++++++++++++++++++++++++++--
 1 file changed, 101 insertions(+), 6 deletions(-)

-- 
2.18.0

From hsinyi at chromium.org  Thu Apr 29 05:28:32 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 12:28:32 +0800
Subject: [PATCH v6 1/3] gpu: drm: separate panel orientation property creating
 and value setting
Message-ID: <20210429042834.1127456-1-hsinyi@chromium.org>

drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.

Add a function to create panel orientation property and set default value
to UNKNOWN, so drivers can call this function to init the property earlier
, and let the panel set the real value later.

[    4.480976] ------------[ cut here ]------------
[    4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc
<snip>
[    4.609772] Call trace:
[    4.612208]  __drm_mode_object_add+0xb4/0xbc
[    4.616466]  drm_mode_object_add+0x20/0x2c
[    4.620552]  drm_property_create+0xdc/0x174
[    4.624723]  drm_property_create_enum+0x34/0x98
[    4.629241]  drm_connector_set_panel_orientation+0x64/0xa0
[    4.634716]  boe_panel_get_modes+0x88/0xd8
[    4.638802]  drm_panel_get_modes+0x2c/0x48
[    4.642887]  panel_bridge_get_modes+0x1c/0x28
[    4.647233]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.652273]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.658266]  drm_mode_getconnector+0x1b4/0x45c
[    4.662699]  drm_ioctl_kernel+0xac/0x128
[    4.666611]  drm_ioctl+0x268/0x410
[    4.670002]  drm_compat_ioctl+0xdc/0xf0
[    4.673829]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.678436]  el0_svc_common+0xf4/0x1c0
[    4.682174]  do_el0_svc_compat+0x28/0x3c
[    4.686088]  el0_svc_compat+0x10/0x1c
[    4.689738]  el0_sync_compat_handler+0xa8/0xcc
[    4.694171]  el0_sync_compat+0x178/0x180
[    4.698082] ---[ end trace b4f2db9d9c88610b ]---
[    4.702721] ------------[ cut here ]------------
[    4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8
<snip>
[    4.833830] Call trace:
[    4.836266]  drm_object_attach_property+0x48/0xb8
[    4.840958]  drm_connector_set_panel_orientation+0x84/0xa0
[    4.846432]  boe_panel_get_modes+0x88/0xd8
[    4.850516]  drm_panel_get_modes+0x2c/0x48
[    4.854600]  panel_bridge_get_modes+0x1c/0x28
[    4.858946]  drm_bridge_connector_get_modes+0xa0/0xd4
[    4.863984]  drm_helper_probe_single_connector_modes+0x218/0x700
[    4.869978]  drm_mode_getconnector+0x1b4/0x45c
[    4.874410]  drm_ioctl_kernel+0xac/0x128
[    4.878320]  drm_ioctl+0x268/0x410
[    4.881711]  drm_compat_ioctl+0xdc/0xf0
[    4.885536]  __arm64_compat_sys_ioctl+0xc8/0x100
[    4.890142]  el0_svc_common+0xf4/0x1c0
[    4.893879]  do_el0_svc_compat+0x28/0x3c
[    4.897791]  el0_svc_compat+0x10/0x1c
[    4.901441]  el0_sync_compat_handler+0xa8/0xcc
[    4.905873]  el0_sync_compat+0x178/0x180
[    4.909783] ---[ end trace b4f2db9d9c88610c ]---

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
v6, v5:
don't create property in set_panel_orientation.

v4, v3:
create property in dsi driver and set value in panel.

v2:
create property in connector init
https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.2600890-1-hsinyi at chromium.org/

v1:
set panel orientation in dsi driver
https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.3420733-1-hsinyi at chromium.org/
---
 drivers/gpu/drm/drm_connector.c         | 58 ++++++++++++++++++-------
 drivers/gpu/drm/i915/display/icl_dsi.c  |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c |  1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c  |  1 +
 include/drm/drm_connector.h             |  2 +
 5 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..7189baaabf41 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
  *	INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
  *	coordinates, so if userspace rotates the picture to adjust for
  *	the orientation it must also apply the same transformation to the
- *	touchscreen input coordinates. This property is initialized by calling
+ *	touchscreen input coordinates. This property value is set by calling
  *	drm_connector_set_panel_orientation() or
  *	drm_connector_set_panel_orientation_with_quirk()
  *
@@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  *
- * This function sets the connector's panel_orientation and attaches
- * a "panel orientation" property to the connector.
+ * This function sets the connector's panel_orientation value. If the property
+ * doesn't exist, it will return an error.
  *
  * Calling this function on a connector where the panel_orientation has
  * already been set is a no-op (e.g. the orientation has been overridden with
@@ -2205,19 +2205,11 @@ int drm_connector_set_panel_orientation(
 	info->panel_orientation = panel_orientation;
 
 	prop = dev->mode_config.panel_orientation_property;
-	if (!prop) {
-		prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
-				"panel orientation",
-				drm_panel_orientation_enum_list,
-				ARRAY_SIZE(drm_panel_orientation_enum_list));
-		if (!prop)
-			return -ENOMEM;
-
-		dev->mode_config.panel_orientation_property = prop;
-	}
+	if (WARN_ON(!prop))
+		return -EINVAL;
 
-	drm_object_attach_property(&connector->base, prop,
-				   info->panel_orientation);
+	drm_object_property_set_value(&connector->base, prop,
+				      info->panel_orientation);
 	return 0;
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation);
@@ -2225,7 +2217,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
 /**
  * drm_connector_set_panel_orientation_with_quirk -
  *	set the connector's panel_orientation after checking for quirks
- * @connector: connector for which to init the panel-orientation property.
+ * @connector: connector for which to set the panel-orientation property.
  * @panel_orientation: drm_panel_orientation value to set
  * @width: width in pixels of the panel, used for panel quirk detection
  * @height: height in pixels of the panel, used for panel quirk detection
@@ -2252,6 +2244,40 @@ int drm_connector_set_panel_orientation_with_quirk(
 }
 EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * 	create the connector's panel orientation property
+ *
+ * This function attaches a "panel orientation" property to the connector
+ * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
+ *
+ * The value of the property can be set by drm_connector_set_panel_orientation()
+ * or drm_connector_set_panel_orientation_with_quirk() later.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_property *prop;
+
+	prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+			"panel orientation",
+			drm_panel_orientation_enum_list,
+			ARRAY_SIZE(drm_panel_orientation_enum_list));
+	if (!prop)
+		return -ENOMEM;
+
+	dev->mode_config.panel_orientation_property = prop;
+	drm_object_attach_property(&connector->base, prop,
+				   DRM_MODE_PANEL_ORIENTATION_UNKNOWN);
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_connector_init_panel_orientation_property);
+
 int drm_connector_set_obj_prop(struct drm_mode_object *obj,
 				    struct drm_property *property,
 				    uint64_t value)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c
index 9282978060b0..5ac4538e4283 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1903,6 +1903,7 @@ static void icl_dsi_add_properties(struct intel_connector *connector)
 
 	connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
 
+	drm_connector_init_panel_orientation_property(&connector->base);
 	drm_connector_set_panel_orientation_with_quirk(&connector->base,
 				intel_dsi_get_panel_orientation(connector),
 				connector->panel.fixed_mode->hdisplay,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index a5231ac3443a..f1d664e5abb2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5263,6 +5263,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
 	intel_panel_setup_backlight(connector, pipe);
 
 	if (fixed_mode) {
+		drm_connector_init_panel_orientation_property(connector);
 		drm_connector_set_panel_orientation_with_quirk(connector,
 				dev_priv->vbt.orientation,
 				fixed_mode->hdisplay, fixed_mode->vdisplay);
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 9bee99fe5495..853855482af1 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1632,6 +1632,7 @@ static void vlv_dsi_add_properties(struct intel_connector *connector)
 
 		connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
 
+		drm_connector_init_panel_orientation_property(&connector->base);
 		drm_connector_set_panel_orientation_with_quirk(
 				&connector->base,
 				intel_dsi_get_panel_orientation(connector),
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..4396c1c4a5db 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk(
 	struct drm_connector *connector,
 	enum drm_panel_orientation panel_orientation,
 	int width, int height);
+int drm_connector_init_panel_orientation_property(
+	struct drm_connector *connector);
 int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
 					  int min, int max);
 
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Thu Apr 29 05:28:33 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 12:28:33 +0800
Subject: [PATCH v6 2/3] drm/mediatek: init panel orientation property
In-Reply-To: <20210429042834.1127456-1-hsinyi@chromium.org>
References: <20210429042834.1127456-1-hsinyi@chromium.org>
Message-ID: <20210429042834.1127456-2-hsinyi@chromium.org>

Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index ae403c67cbd9..9da1fd649131 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -964,6 +964,13 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
 		ret = PTR_ERR(dsi->connector);
 		goto err_cleanup_encoder;
 	}
+
+	ret = drm_connector_init_panel_orientation_property(dsi->connector);
+	if (ret) {
+		DRM_ERROR("Unable to init panel orientation\n");
+		goto err_cleanup_encoder;
+	}
+
 	drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
 
 	return 0;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From hsinyi at chromium.org  Thu Apr 29 05:28:34 2021
From: hsinyi at chromium.org (Hsin-Yi Wang)
Date: Thu, 29 Apr 2021 12:28:34 +0800
Subject: [PATCH v6 3/3] arm64: dts: mt8183: Add panel rotation
In-Reply-To: <20210429042834.1127456-1-hsinyi@chromium.org>
References: <20210429042834.1127456-1-hsinyi@chromium.org>
Message-ID: <20210429042834.1127456-3-hsinyi@chromium.org>

krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang <hsinyi at chromium.org>
---
 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 ff56bcfa3370..793cc9501337 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -263,6 +263,7 @@ panel: panel at 0 {
 		avee-supply = <&ppvarp_lcd>;
 		pp1800-supply = <&pp1800_lcd>;
 		backlight = <&backlight_lcd0>;
+		rotation = <270>;
 		port {
 			panel_in: endpoint {
 				remote-endpoint = <&dsi_out>;
-- 
2.31.1.498.g6c1eba8ee3d-goog



From navam at xilinx.com  Thu Apr 29 05:56:42 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 04:56:42 +0000
Subject: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
 driver
In-Reply-To: <1618927121.480164.3235334.nullmailer@robh.at.kernel.org>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-5-nava.manne@xilinx.com>
 <1618927121.480164.3235334.nullmailer@robh.at.kernel.org>
Message-ID: <MWHPR02MB26235C242818EF48E9026040C25F9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Rob,

	Please find my response inline.

> -----Original Message-----
> From: Rob Herring <robh at kernel.org>
> Sent: Tuesday, April 20, 2021 7:29 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Tejas Patel <tejasp at xlnx.xilinx.com>; Michal Simek
> <michals at xilinx.com>; Rajan Vaja <RAJANV at xilinx.com>; linux-arm-
> kernel at lists.infradead.org; Amit Sunil Dhamne <amitsuni at xilinx.com>;
> Dragan Cvetic <draganc at xilinx.com>; Derek Kiernan <dkiernan at xilinx.com>;
> Jolly Shah <JOLLYS at xilinx.com>; git <git at xilinx.com>;
> chinnikishore369 at gmail.com; arnd at arndb.de;
> gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org
> Subject: Re: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
> driver
> 
> On Tue, 20 Apr 2021 13:41:52 +0530, Nava kishore Manne wrote:
> > This patch adds the binding document for the zynqmp afi config driver.
> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
> >  1 file changed, 136 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.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):
> 

Thanks for the providing the update on the new features

> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-
> fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware: failed to
> match any schema with compatible: ['xlnx,zynqmp-firmware']
> Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-
> fpga.example.dt.yaml:0:0: /example-0/firmware/zynqmp-firmware/afi:
> failed to match any schema with compatible: ['xlnx,afi-fpga']
> 
> See https://patchwork.ozlabs.org/patch/1468230
> 
> This check can fail if there are any dependencies. The base for a patch series
> is generally the most recent rc1.
> 
> 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.

Will fix in v2.


Regards,
Navakishore.


From navam at xilinx.com  Thu Apr 29 06:39:43 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 05:39:43 +0000
Subject: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
 driver
In-Reply-To: <20210420141504.GA3250182@robh.at.kernel.org>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-5-nava.manne@xilinx.com>
 <20210420141504.GA3250182@robh.at.kernel.org>
Message-ID: <MWHPR02MB2623209FE0193119B7054FF2C25F9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Rob,

	Thanks for the review.
Please find my response inline.

> -----Original Message-----
> From: Rob Herring <robh at kernel.org>
> Sent: Tuesday, April 20, 2021 7:45 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; gregkh at linuxfoundation.org; Rajan Vaja
> <RAJANV at xilinx.com>; Jolly Shah <JOLLYS at xilinx.com>; Tejas Patel
> <tejasp at xlnx.xilinx.com>; Amit Sunil Dhamne <amitsuni at xilinx.com>;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 4/5] misc: doc: Add binding doc for the zynqmp afi config
> driver
> 
> On Tue, Apr 20, 2021 at 01:41:52PM +0530, Nava kishore Manne wrote:
> > This patch adds the binding document for the zynqmp afi config driver.
> 
> Bindings are for h/w blocks, not drivers.
> 

This Binding are for h/w blocks (PS-PL bus width configurations)
For more info please refer the below links.
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf (Page No: 54)
https://www.xilinx.com/support/documentation/ip_documentation/zynq_ultra_ps_e/v3_2/pg201-zynq-ultrascale-plus-processing-system.pdf (Page No: 42).

Please let me know if you need more info..

> >
> > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > ---
> >  .../bindings/misc/xlnx,zynqmp-afi-fpga.yaml   | 136 ++++++++++++++++++
> >  1 file changed, 136 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> > b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-fpga.yaml
> > new file mode 100644
> > index 000000000000..3ae22096b22a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/xlnx,zynqmp-afi-
> fpga.yaml
> > @@ -0,0 +1,136 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/misc/xlnx,zynqmp-afi-fpga.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Xilinx ZynqMP AFI interface Manager.
> > +
> > +maintainers:
> > +  - Nava kishore Manne <nava.manne at xilinx.com>
> > +
> > +description: |
> > +  The Zynq UltraScale+ MPSoC Processing System core provides access
> > +from PL
> > +  masters to PS internal peripherals, and memory through AXI FIFO
> > +interface(AFI)
> > +  interfaces.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - xlnx,zynqmp-afi-fpga
> > +
> > +  config-afi:
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    description: |
> > +      Pairs of  <regid value >
> > +      The possible values of regid and values are
> > +      regid - Regids of the register to be written possible values
> 
> If we wanted sequences of register accesses in DT, we'd have a generic
> mechanism to do so.
> 

I will try to find a better way, will get back you on this


Regards,
Navakishore.


From navam at xilinx.com  Thu Apr 29 07:01:28 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 06:01:28 +0000
Subject: [PATCH 5/5] misc: zynqmp: Add afi config driver
In-Reply-To: <YH7zGf3/NrXmMN8/@kroah.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-6-nava.manne@xilinx.com> <YH6V9Im3L/gJJ/CP@kroah.com>
 <MWHPR02MB26233345F140ACA18E55BC15C2489@MWHPR02MB2623.namprd02.prod.outlook.com>
 <YH7zGf3/NrXmMN8/@kroah.com>
Message-ID: <MWHPR02MB26232DBCD6C20C8B5F4B5F2AC25F9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Greg,

	Please find my response inline.

> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Tuesday, April 20, 2021 8:58 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 5/5] misc: zynqmp: Add afi config driver
> 
> On Tue, Apr 20, 2021 at 01:47:17PM +0000, Nava kishore Manne wrote:
> > Hi Greg,
> >
> > 	Please find my response inline.
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh at linuxfoundation.org>
> > > Sent: Tuesday, April 20, 2021 2:21 PM
> > > To: Nava kishore Manne <navam at xilinx.com>
> > > Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek
> > > Kiernan <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> > > arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> > > <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit
> > > Sunil Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org;
> > > linux-arm- kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > chinnikishore369 at gmail.com; git <git at xilinx.com>
> > > Subject: Re: [PATCH 5/5] misc: zynqmp: Add afi config driver
> > >
> > > On Tue, Apr 20, 2021 at 01:41:53PM +0530, Nava kishore Manne wrote:
> > > > This patch adds zynqmp afi config driver.This is useful for the
> > > > configuration of the PS-PL interface on Zynq US+ MPSoC platform.
> > > >
> > > > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > > > ---
> > > >  drivers/misc/Kconfig      | 11 ++++++
> > > >  drivers/misc/Makefile     |  1 +
> > > >  drivers/misc/zynqmp-afi.c | 83
> > > > +++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 95 insertions(+)  create mode 100644
> > > > drivers/misc/zynqmp-afi.c
> > > >
> > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > > > 877b43b3377d..d1ea1eeb3ac1 100644
> > > > --- a/drivers/misc/Kconfig
> > > > +++ b/drivers/misc/Kconfig
> > > > @@ -456,6 +456,17 @@ config ZYNQ_AFI
> > > >  	  between PS and PL, the AXI port data path should be configured
> > > >  	  with the proper Bus-width values
> > > >
> > > > +config ZYNQMP_AFI
> > > > +        tristate "Xilinx ZYNQMP AFI support"
> > > > +        help
> > > > +	  ZynqMP AFI driver support for writing to the AFI registers for
> > > > +	  configuring PS_PL Bus-width. Xilinx Zynq US+ MPSoC connect the
> > > > +	  PS to the programmable logic (PL) through the AXI port. This AXI
> > > > +	  port helps to establish the data path between the PS and PL.
> > > > +	  In-order to establish the proper communication path between
> > > > +	  PS and PL, the AXI port data path should be configured with
> > > > +	  the proper Bus-width values
> > > > +
> > > >  source "drivers/misc/c2port/Kconfig"
> > > >  source "drivers/misc/eeprom/Kconfig"
> > > >  source "drivers/misc/cb710/Kconfig"
> > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > > > e9b03843100f..54bd0edc511e 100644
> > > > --- a/drivers/misc/Makefile
> > > > +++ b/drivers/misc/Makefile
> > > > @@ -57,3 +57,4 @@ obj-$(CONFIG_UACCE)		+= uacce/
> > > >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> > > >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> > > >  obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > > > +obj-$(CONFIG_ZYNQMP_AFI)	+= zynqmp-afi.o
> > > > diff --git a/drivers/misc/zynqmp-afi.c b/drivers/misc/zynqmp-afi.c
> > > > new file mode 100644 index 000000000000..a318652576d2
> > > > --- /dev/null
> > > > +++ b/drivers/misc/zynqmp-afi.c
> > > > @@ -0,0 +1,83 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Xilinx FPGA AFI bridge.
> > > > + * Copyright (c) 2018-2021 Xilinx Inc.
> > > > + */
> > > > +
> > > > +#include <linux/err.h>
> > > > +#include <linux/firmware/xlnx-zynqmp.h> #include <linux/io.h>
> > > > +#include <linux/module.h> #include <linux/of.h> #include
> > > > +<linux/platform_device.h> #include <linux/slab.h>
> > > > +
> > > > +/**
> > > > + * struct zynqmp_afi_fpga - AFI register description
> > > > + * @value: value to be written to the register
> > > > + * @regid: Register id for the register to be written  */ struct
> > > > +zynqmp_afi_fpga {
> > > > +	u32 value;
> > > > +	u32 regid;
> > > > +};
> > > > +
> > > > +static int zynqmp_afi_fpga_probe(struct platform_device *pdev) {
> > > > +	struct zynqmp_afi_fpga *zynqmp_afi_fpga;
> > > > +	struct device_node *np = pdev->dev.of_node;
> > > > +	int i, entries, ret;
> > > > +	u32 reg, val;
> > > > +
> > > > +	zynqmp_afi_fpga = devm_kzalloc(&pdev->dev,
> > > > +				       sizeof(*zynqmp_afi_fpga), GFP_KERNEL);
> > > > +	if (!zynqmp_afi_fpga)
> > > > +		return -ENOMEM;
> > > > +	platform_set_drvdata(pdev, zynqmp_afi_fpga);
> > > > +
> > > > +	entries = of_property_count_u32_elems(np, "config-afi");
> > > > +	if (!entries || (entries % 2)) {
> > > > +		dev_err(&pdev->dev, "Invalid number of registers\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	for (i = 0; i < entries / 2; i++) {
> > > > +		ret = of_property_read_u32_index(np, "config-afi", i * 2,
> > > &reg);
> > > > +		if (ret) {
> > > > +			dev_err(&pdev->dev, "failed to read register\n");
> > > > +			return -EINVAL;
> > > > +		}
> > > > +		ret = of_property_read_u32_index(np, "config-afi", i * 2 + 1,
> > > > +						 &val);
> > > > +		if (ret) {
> > > > +			dev_err(&pdev->dev, "failed to read value\n");
> > > > +			return -EINVAL;
> > > > +		}
> > > > +		ret = zynqmp_pm_afi(reg, val);
> > > > +		if (ret < 0) {
> > > > +			dev_err(&pdev->dev, "AFI register write error
> %d\n",
> > > > +				ret);
> > > > +			return ret;
> > > > +		}
> > > > +	}
> > > > +	return 0;
> > > > +}
> > >
> > > Again, why does this have to be in the kernel?  All it does is make
> > > a single call to the hardware based on some values read from the
> > > device tree.  Can't you do this from userspace?
> > >
> > For every PL design has its own PS-PL configuration.
> 
> What is a "PL design", and what is a "PS-PL configuration"?  :)
> 
> > This driver will be used by the overlay framework for configuring the
> interface after programming the FPGA and before probing the drivers that
> are present in the PL.
> 
> Again, I have no idea what this means at all.
> 
> And again, why does this have to be done in the kernel?  All you are doing is
> sending some random values read in DT down to a hardware
> device.   What requires a kernel driver for this?
> 

The ZynqMP based processing system (PS) that contains ARM cores and Xilinx programmable logic (PL/FPGA) in a single device. The PS and PL can be tightly or loosely coupled using multiple interfaces and other signals.
This enables the designer to effectively integrate user-created hardware accelerators and other functions in the PL logic that are accessible to the processors and can also access memory resources in the PS.
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf  (Page No: 1085)

To Program/Re-Program the PL at runtime in Linux we have a an FPGA Manger Framework and this frame work uses DT-Overlays to programming the FPGA and probing the relevant PL drivers.
For more info please refer this link: https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/fpga/fpga-region.txt  

Every Zynq/ZynqMP PL(FPGA) design has its own PS-PL configuration. So after programming the FPGA and before probing the relevant PL drivers these PS-PL configurations should be set.

Example DT-Overlay file to program the PL(FPGA) from Linux:
/dts-v1/;
/plugin/;
/ {
        fragment at 0 {  /* fragment 0 contains Bitstream info */
                target = <&fpga_full>;
                overlay0: __overlay__ {
                        #address-cells = <2>;
                        #size-cells = <2>;
                        firmware-name = "Base_Zynq_MPSoC_wrapper.bit.bin";
                        resets = <&zynqmp_reset 116>;
                };
        };
        fragment at 1 { /* fragment 1 contains PS-PL configurations */
                target = <&amba>;
                overlay1: __overlay__ {
                        afi0: afi0 {
                                compatible = "xlnx,afi-fpga";
                                config-afi = < 0 0>, <1 0>, <2 0>, <3 0>, <4 0>, <5 0>, <6 0>, <7 0>, <8 0>, <9 0>, <10 0>, <11 0>, <12 0>, <13 0>, <14 0xa00>, <15 0x000>;
                        };
                };
        };
       fragment at 2 { /* Fragment 2 contains the relevant drivers  for the IP's present in the FPGA design*/
                target = <&amba>;
                overlay2: __overlay__ {
                        axi_gpio_0: gpio at a0000000 {
                                #gpio-cells = <2>;
                                clock-names = "s_axi_aclk";
                                clocks = <&zynqmp_clk 71>;
                                compatible = "xlnx,xps-gpio-1.00.a";
                                gpio-controller ;
                                reg = <0x0 0xa0000000 0x0 0x1000>;
                        };
                };
         } ;               
};

In-order to support the PL(FPGA) programming and to configure the interface between PS and PL using FPGA Manager. This Driver is  needed in the kernel space.

@Moritz Fischer: Can you please let us know your thoughts on this.

Regards,
Navakishore.



From wens at kernel.org  Thu Apr 29 07:08:30 2021
From: wens at kernel.org (Chen-Yu Tsai)
Date: Thu, 29 Apr 2021 14:08:30 +0800
Subject: [PATCH] arm64: dts: meson-gxbb: nanopi-k2: Enable Bluetooth
Message-ID: <20210429060830.6266-1-wens@kernel.org>

From: Chen-Yu Tsai <wens at csie.org>

The NanoPi K2 has a AP6212 WiFi+BT combo module. The WiFi portion is
already enabled. The BT part is connected via UART and I2S.

Enable the UART and add a device node describing the Bluetooth portion
of the module.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
index 7273eed5292c..10f48fb1af61 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
@@ -385,9 +385,19 @@ &uart_AO {
 
 /* Bluetooth on AP6212 */
 &uart_A {
-	status = "disabled";
+	status = "okay";
 	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
 	pinctrl-names = "default";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&wifi_32k>;
+		clock-names = "lpo";
+		vbat-supply = <&vddio_ao3v3>;
+		vddio-supply = <&vddio_ao18>;
+		host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>;
+		shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 /* 40-pin CON1 */
-- 
2.31.1



From navam at xilinx.com  Thu Apr 29 07:23:59 2021
From: navam at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 06:23:59 +0000
Subject: [PATCH 2/5] misc: zynq: Add afi config driver
In-Reply-To: <YH7y1Em4bp505DaV@kroah.com>
References: <20210420081153.17020-1-nava.manne@xilinx.com>
 <20210420081153.17020-3-nava.manne@xilinx.com> <YH6U/L4SEtJajusW@kroah.com>
 <MWHPR02MB2623DED0785A05A9C55C20FBC2489@MWHPR02MB2623.namprd02.prod.outlook.com>
 <YH7y1Em4bp505DaV@kroah.com>
Message-ID: <MWHPR02MB262375C50CF76F70F88BB2B6C25F9@MWHPR02MB2623.namprd02.prod.outlook.com>

Hi Greg,

	Please find my response inline.

> -----Original Message-----
> From: Greg KH <gregkh at linuxfoundation.org>
> Sent: Tuesday, April 20, 2021 8:57 PM
> To: Nava kishore Manne <navam at xilinx.com>
> Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek Kiernan
> <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit Sunil
> Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> chinnikishore369 at gmail.com; git <git at xilinx.com>
> Subject: Re: [PATCH 2/5] misc: zynq: Add afi config driver
> 
> On Tue, Apr 20, 2021 at 01:36:51PM +0000, Nava kishore Manne wrote:
> > Hi Greg,
> >
> > 	Please find my response inline.
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh at linuxfoundation.org>
> > > Sent: Tuesday, April 20, 2021 2:17 PM
> > > To: Nava kishore Manne <navam at xilinx.com>
> > > Cc: robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; Derek
> > > Kiernan <dkiernan at xilinx.com>; Dragan Cvetic <draganc at xilinx.com>;
> > > arnd at arndb.de; Rajan Vaja <RAJANV at xilinx.com>; Jolly Shah
> > > <JOLLYS at xilinx.com>; Tejas Patel <tejasp at xlnx.xilinx.com>; Amit
> > > Sunil Dhamne <amitsuni at xilinx.com>; devicetree at vger.kernel.org;
> > > linux-arm- kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > chinnikishore369 at gmail.com; git <git at xilinx.com>
> > > Subject: Re: [PATCH 2/5] misc: zynq: Add afi config driver
> > >
> > > On Tue, Apr 20, 2021 at 01:41:50PM +0530, Nava kishore Manne wrote:
> > > > This patch adds zynq afi config driver. This is useful for the
> > > > configuration of the PS-PL interface on zynq platform.
> > >
> > > What is "PS-PL"?  Can you describe it better please?
> > >
> > PS-PL interface is nothing but the interface between processing system(PS)
> that contains arm cores and Programmable Logic(PL) i.e FPGA.
> > Will update the description in v2.
> >
> > > >
> > > > Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> > > > ---
> > > >  drivers/misc/Kconfig    | 11 ++++++
> > > >  drivers/misc/Makefile   |  1 +
> > > >  drivers/misc/zynq-afi.c | 81
> > > > +++++++++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 93 insertions(+)  create mode 100644
> > > > drivers/misc/zynq-afi.c
> > > >
> > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
> > > > f532c59bb59b..877b43b3377d 100644
> > > > --- a/drivers/misc/Kconfig
> > > > +++ b/drivers/misc/Kconfig
> > > > @@ -445,6 +445,17 @@ config HISI_HIKEY_USB
> > > >  	  switching between the dual-role USB-C port and the USB-A host
> > > ports
> > > >  	  using only one USB controller.
> > > >
> > > > +config ZYNQ_AFI
> > > > +	tristate "Xilinx ZYNQ AFI support"
> > > > +	help
> > > > +	  Zynq AFI driver support for writing to the AFI registers
> > > > +	  for configuring PS_PL Bus-width. Xilinx Zynq SoC connect
> > > > +	  the PS to the programmable logic (PL) through the AXI port.
> > > > +	  This AXI port helps to establish the data path between the
> > > > +	  PS and PL.In-order to establish the proper communication path
> > > > +	  between PS and PL, the AXI port data path should be configured
> > > > +	  with the proper Bus-width values
> > > > +
> > > >  source "drivers/misc/c2port/Kconfig"
> > > >  source "drivers/misc/eeprom/Kconfig"
> > > >  source "drivers/misc/cb710/Kconfig"
> > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > > > 99b6f15a3c70..e9b03843100f 100644
> > > > --- a/drivers/misc/Makefile
> > > > +++ b/drivers/misc/Makefile
> > > > @@ -56,3 +56,4 @@ obj-$(CONFIG_HABANA_AI)		+=
> > > habanalabs/
> > > >  obj-$(CONFIG_UACCE)		+= uacce/
> > > >  obj-$(CONFIG_XILINX_SDFEC)	+= xilinx_sdfec.o
> > > >  obj-$(CONFIG_HISI_HIKEY_USB)	+= hisi_hikey_usb.o
> > > > +obj-$(CONFIG_ZYNQ_AFI)		+= zynq-afi.o
> > > > diff --git a/drivers/misc/zynq-afi.c b/drivers/misc/zynq-afi.c new
> > > > file mode 100644 index 000000000000..04317d1bdb98
> > > > --- /dev/null
> > > > +++ b/drivers/misc/zynq-afi.c
> > > > @@ -0,0 +1,81 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Xilinx ZYNQ AFI driver.
> > > > + * Copyright (c) 2018-2021 Xilinx Inc.
> > > > + */
> > > > +
> > > > +#include <linux/err.h>
> > > > +#include <linux/io.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/platform_device.h>
> > > > +
> > > > +/* Registers and special values for doing register-based operations */
> > > > +#define AFI_RDCHAN_CTRL_OFFSET	0x00
> > > > +#define AFI_WRCHAN_CTRL_OFFSET	0x14
> > > > +
> > > > +#define AFI_BUSWIDTH_MASK	0x01
> > > > +
> > > > +/**
> > > > + * struct afi_fpga - AFI register description
> > > > + * @membase:	pointer to register struct
> > > > + * @afi_width:	AFI bus width to be written
> > > > + */
> > > > +struct zynq_afi_fpga {
> > > > +	void __iomem	*membase;
> > > > +	u32		afi_width;
> > > > +};
> > > > +
> > > > +static int zynq_afi_fpga_probe(struct platform_device *pdev) {
> > > > +	struct zynq_afi_fpga *afi_fpga;
> > > > +	struct resource *res;
> > > > +	u32 reg_val;
> > > > +	u32 val;
> > > > +
> > > > +	afi_fpga = devm_kzalloc(&pdev->dev, sizeof(*afi_fpga),
> > > GFP_KERNEL);
> > > > +	if (!afi_fpga)
> > > > +		return -ENOMEM;
> > > > +
> > > > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > +	afi_fpga->membase = devm_ioremap_resource(&pdev->dev, res);
> > > > +	if (IS_ERR(afi_fpga->membase))
> > > > +		return PTR_ERR(afi_fpga->membase);
> > > > +
> > > > +	val = device_property_read_u32(&pdev->dev, "xlnx,afi-width",
> > > > +				       &afi_fpga->afi_width);
> > > > +	if (val) {
> > > > +		dev_err(&pdev->dev, "failed to get the afi bus width\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	reg_val = readl(afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > > > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > > > +	writel(reg_val | afi_fpga->afi_width,
> > > > +	       afi_fpga->membase + AFI_RDCHAN_CTRL_OFFSET);
> > > > +	reg_val = readl(afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > > > +	reg_val &= ~AFI_BUSWIDTH_MASK;
> > > > +	writel(reg_val | afi_fpga->afi_width,
> > > > +	       afi_fpga->membase + AFI_WRCHAN_CTRL_OFFSET);
> > > > +
> > > > +	return 0;
> > > > +}
> > >
> > > I do not understand, why is this driver needed at all?  Why can't
> > > you do the above from userspace?
> > >
> > > All this does is write some values to the hardware at probe time,
> > > who needs this?
> >
> > This driver will be used by the overlay framework for configuring the
> interface after programming the FPGA and before probing the drivers that
> are present in the PL.
> 
> What is a "overlay framework"?  And why does the kernel have to do this?
> Why can't you write these hardware values from userspace?
> 
> confused,
> 

The Zynq based processing system (PS) that contains ARM cores and Xilinx programmable logic (PL/FPGA) in a single device. The PS and PL can be tightly or loosely coupled using multiple interfaces and other signals.
This enables the designer to effectively integrate user-created hardware accelerators and other functions in the PL logic that are accessible to the processors and can also access memory resources in the PS.
https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf (Page No: 41)

To Program/Re-Program the PL at runtime in Linux we have a an FPGA Manger Framework and this frame work uses DT-Overlays to programming the FPGA and probing the relevant PL drivers.
For more info please refer this link: https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/fpga/fpga-region.txt   

Every Zynq/ZynqMP PL(FPGA) design has its own PS-PL configuration. So after programming the FPGA and before probing the relevant PL drivers these PS-PL configurations should be set.

Example DT-Overlay file to program the PL(FPGA) from Linux:
/dts-v1/;
/plugin/;
/ {
        fragment at 0 {  /* fragment 0 contains Bitstream info */
                target = <&fpga_full>;
                overlay0: __overlay__ {
                        #address-cells = <2>;
                        #size-cells = <2>;
                        firmware-name = "Base_Zynq_MPSoC_wrapper.bit.bin";
                        resets = <&zynqmp_reset 116>;
                };
        };
        fragment at 1 { /* fragment 1 contains PS-PL configurations */
                target = <&amba>;
                overlay1: __overlay__ {
                        afi0: afi at f8008000 {
                                #address-cells = <0x1>;
                                #size-cells = <0x0>;
                                compatible = "xlnx,zynq-afi-fpga";
                                reg = <0xf8008000 0x24>;
                                xlnx,afi-width = <0x1>;
                        };
                 };
        };
       fragment at 2 { /* Fragment 2 contains the relevant drivers  for the IP's present in the FPGA design*/
                target = <&amba>;
                overlay2: __overlay__ {
                        axi_gpio_0: gpio at a0000000 {
                                #gpio-cells = <2>;
                                clock-names = "s_axi_aclk";
                                clocks = <&zynqmp_clk 71>;
                                compatible = "xlnx,xps-gpio-1.00.a";
                                gpio-controller ;
                                reg = <0x0 0xa0000000 0x0 0x1000>;
                        };
                };
         } ;               
};

In-order to support the PL(FPGA) programming and to configure the interface between PS and PL using FPGA Manager. This Driver is  needed in the kernel space.

@Moritz Fischer: Can you please let us know your thoughts on this.

Regards,
Navakishore.


From mkorpershoek at baylibre.com  Thu Apr 29 07:48:53 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Thu, 29 Apr 2021 08:48:53 +0200
Subject: [PATCH 1/7] Input: mtk-pmic-keys - check for NULL on
 of_match_device()
In-Reply-To: <YIm9Bb3eBjYwY53R@google.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
 <20210428164219.1115537-2-mkorpershoek@baylibre.com>
 <YIm9Bb3eBjYwY53R@google.com>
Message-ID: <875z05y4a2.fsf@baylibre.com>

Hi Dmitry,

Dmitry Torokhov <dmitry.torokhov at gmail.com> writes:

> Hi Mattijs,
>
> On Wed, Apr 28, 2021 at 06:42:13PM +0200, Mattijs Korpershoek wrote:
>> mtk-pmic-keys being a child device of mt6397, it will always get probed
>> when mt6397_probe() is called.
>> 
>> This also happens when we have no device tree node matching
>> mediatek,mt6397-keys.
>
> It sounds for me that creating a platform device instance in case where
> we know need OF node, but do not have one, is wasteful. Can
> mt6397-core.c and/or MFD core be adjusted to not do that.

You are right. Maybe I can fix MFD core instead. I will look into it.

Thanks for your review.
>
>> 
>> In that case, the mfd core warns us:
>> 
>>   [    0.352175] mtk-pmic-keys: Failed to locate of_node [id: -1]
>> 
>> Check return value from call to of_match_device()
>> in order to prevent a NULL pointer dereference.
>> 
>> In case of NULL print error message and return -ENODEV
>> 
>> Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
>> ---
>>  drivers/input/keyboard/mtk-pmic-keys.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
>> index 62391d6c7da6..12c449eed026 100644
>> --- a/drivers/input/keyboard/mtk-pmic-keys.c
>> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
>> @@ -247,6 +247,9 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
>>  	const struct of_device_id *of_id =
>>  		of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
>>  
>> +	if (!of_id)
>> +		return -ENODEV;
>> +
>
> So if we make MFD/6396 core smarter we would not be needing this. I
> guess there is still a possibility of someone stuffing "mtk-pmic-keys"
> into "driver_override" attribute of a random platform device but I
> wonder if we really need to take care of such scenarios...
>
>>  	keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
>>  	if (!keys)
>>  		return -ENOMEM;
>> -- 
>> 2.27.0
>> 
>
> Thanks.
>
> -- 
> Dmitry


From rppt at kernel.org  Thu Apr 29 07:57:53 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Thu, 29 Apr 2021 09:57:53 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>
References: <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
 <YIj5zcbHBHt7CC8B@kernel.org>
 <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>
Message-ID: <YIpY8TXCSc7Lfa2Z@kernel.org>

On Thu, Apr 29, 2021 at 08:48:26AM +0800, Kefeng Wang wrote:
> 
> On 2021/4/28 13:59, Mike Rapoport wrote:
> > On Tue, Apr 27, 2021 at 07:08:59PM +0800, Kefeng Wang wrote:
> > > On 2021/4/27 14:23, Mike Rapoport wrote:
> > > > On Mon, Apr 26, 2021 at 11:26:38PM +0800, Kefeng Wang wrote:
> > > > > On 2021/4/26 13:20, Mike Rapoport wrote:
> > > > > > On Sun, Apr 25, 2021 at 03:51:56PM +0800, Kefeng Wang wrote:
> > > > > > > On 2021/4/25 15:19, Mike Rapoport wrote:
> > > > > > > 
> > > > > > >        On Fri, Apr 23, 2021 at 04:11:16PM +0800, Kefeng Wang wrote:
> > > > > > > 
> > > > > > >            I tested this patchset(plus arm32 change, like arm64 does)
> > > > > > >            based on lts 5.10?add some debug log, the useful info shows
> > > > > > >            below, if we enable HOLES_IN_ZONE, no panic, any idea,
> > > > > > >            thanks.
> > > > > > > 
> > > > > > >        Are there any changes on top of 5.10 except for pfn_valid() patch?
> > > > > > >        Do you see this panic on 5.10 without the changes?
> > > > > > > 
> > > > > > > Yes, there are some BSP support for arm board based on 5.10,
> > > > Is it possible to test 5.12?
> > Do you use SPARSMEM? If yes, what is your section size?
> > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> 
> Yes,
> 
> CONFIG_SPARSEMEM=y
> 
> CONFIG_SPARSEMEM_STATIC=y
> 
> CONFIG_FORCE_MAX_ZONEORDER = 11
> 
> CONFIG_PAGE_OFFSET=0xC0000000
> CONFIG_HAVE_ARCH_PFN_VALID=y
> CONFIG_HIGHMEM=y
> #define SECTION_SIZE_BITS    26
> #define MAX_PHYSADDR_BITS    32
> #define MAX_PHYSMEM_BITS     32

It seems that with SPARSEMEM we don't align the freed parts on pageblock
boundaries.

Can you try the patch below:

diff --git a/mm/memblock.c b/mm/memblock.c
index afaefa8fc6ab..1926369b52ec 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
 		 * due to SPARSEMEM sections which aren't present.
 		 */
 		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
-#else
+#endif
 		/*
 		 * Align down here since the VM subsystem insists that the
 		 * memmap entries are valid from the bank start aligned to
 		 * MAX_ORDER_NR_PAGES.
 		 */
 		start = round_down(start, MAX_ORDER_NR_PAGES);
-#endif
 
 		/*
 		 * If we had a previous bank, and there is a space
 

-- 
Sincerely yours,
Mike.


From peng.fan at oss.nxp.com  Thu Apr 29 08:30:34 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:34 +0800
Subject: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
Message-ID: <20210429073050.21039-1-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

This patchset is a pick up Lucas's gpcv2 work for i.MX8MM and several
minor changes from me to make it could work with i.MX BLK-CTL driver.

Thanks for Lucas's work and suggestion, Frieder Schrempf for collecting
all the patches, Jacky Bai on help debug issues.

Lucas Stach (12):
  soc: imx: gpcv2: move to more ideomatic error handling in probe
  soc: imx: gpcv2: move domain mapping to domain driver probe
  soc: imx: gpcv2: switch to clk_bulk_* API
  soc: imx: gpcv2: split power up and power down sequence control
  soc: imx: gpcv2: wait for ADB400 handshake
  soc: imx: gpcv2: add runtime PM support for power-domains
  soc: imx: gpcv2: allow domains without power-sequence control
  dt-bindings: imx: gpcv2: add support for optional resets
  soc: imx: gpcv2: add support for optional resets
  dt-bindings: power: add defines for i.MX8MM power domains
  soc: imx: gpcv2: add support for i.MX8MM power domains
  soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX power
    domains

Peng Fan (4):
  soc: imx: gpcv2: correct pm_runtime_get_sync usage
  soc: imx: gpcv2: move reset assert after requesting domain power up
  soc: imx: gpcv2: support reset defer probe
  soc: imx: gpcv2: remove waiting handshake in power up

 .../bindings/power/fsl,imx-gpcv2.yaml         |   9 +
 drivers/soc/imx/gpcv2.c                       | 534 ++++++++++++++----
 include/dt-bindings/power/imx8mm-power.h      |  22 +
 3 files changed, 450 insertions(+), 115 deletions(-)
 create mode 100644 include/dt-bindings/power/imx8mm-power.h

-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:35 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:35 +0800
Subject: [PATCH 01/16] soc: imx: gpcv2: move to more ideomatic error handling
 in probe
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-2-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

Switch to "goto out..." error handling in domain driver probe to
avoid repeating all the error paths.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
Reviewed-by: Marek Vasut <marex at denx.de>
Tested-by: Adam Ford <aford173 at gmail.com>
---
 drivers/soc/imx/gpcv2.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index db7e7fc321b1..512e6f4acafd 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -502,18 +502,23 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 	ret = pm_genpd_init(&domain->genpd, NULL, true);
 	if (ret) {
 		dev_err(domain->dev, "Failed to init power domain\n");
-		imx_pgc_put_clocks(domain);
-		return ret;
+		goto out_put_clocks;
 	}
 
 	ret = of_genpd_add_provider_simple(domain->dev->of_node,
 					   &domain->genpd);
 	if (ret) {
 		dev_err(domain->dev, "Failed to add genpd provider\n");
-		pm_genpd_remove(&domain->genpd);
-		imx_pgc_put_clocks(domain);
+		goto out_genpd_remove;
 	}
 
+	return 0;
+
+out_genpd_remove:
+	pm_genpd_remove(&domain->genpd);
+out_put_clocks:
+	imx_pgc_put_clocks(domain);
+
 	return ret;
 }
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:36 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:36 +0800
Subject: [PATCH 02/16] soc: imx: gpcv2: move domain mapping to domain driver
 probe
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-3-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

As long as the power domain driver is active we want power control
over the domain (which is what the mapping bit requests), so there
is no point in whacking it for every power control action, simply
set the bit in driver probe and clear it when the driver is removed.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 512e6f4acafd..552d3e6bee52 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -140,14 +140,11 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	int i, ret = 0;
 	u32 pxx_req;
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, domain->bits.map);
-
 	if (has_regulator && on) {
 		ret = regulator_enable(domain->regulator);
 		if (ret) {
 			dev_err(domain->dev, "failed to enable regulator\n");
-			goto unmap;
+			return ret;
 		}
 	}
 
@@ -203,9 +200,7 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 		/* Preserve earlier error code */
 		ret = ret ?: err;
 	}
-unmap:
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
+
 	return ret;
 }
 
@@ -499,10 +494,13 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 	if (ret)
 		return dev_err_probe(domain->dev, ret, "Failed to get domain's clocks\n");
 
+	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+			   domain->bits.map, domain->bits.map);
+
 	ret = pm_genpd_init(&domain->genpd, NULL, true);
 	if (ret) {
 		dev_err(domain->dev, "Failed to init power domain\n");
-		goto out_put_clocks;
+		goto out_domain_unmap;
 	}
 
 	ret = of_genpd_add_provider_simple(domain->dev->of_node,
@@ -516,7 +514,9 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 
 out_genpd_remove:
 	pm_genpd_remove(&domain->genpd);
-out_put_clocks:
+out_domain_unmap:
+	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+			   domain->bits.map, 0);
 	imx_pgc_put_clocks(domain);
 
 	return ret;
@@ -528,6 +528,10 @@ static int imx_pgc_domain_remove(struct platform_device *pdev)
 
 	of_genpd_del_provider(domain->dev->of_node);
 	pm_genpd_remove(&domain->genpd);
+
+	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+			   domain->bits.map, 0);
+
 	imx_pgc_put_clocks(domain);
 
 	return 0;
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:37 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:37 +0800
Subject: [PATCH 03/16] soc: imx: gpcv2: switch to clk_bulk_* API
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-4-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

Use clk_bulk API to simplify the code a bit. Also add some error
checking to the clk_prepare_enable calls.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 60 +++++++++--------------------------------
 1 file changed, 12 insertions(+), 48 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 552d3e6bee52..1d90c7802972 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -100,13 +100,11 @@
 
 #define GPC_PGC_CTRL_PCR		BIT(0)
 
-#define GPC_CLK_MAX		6
-
 struct imx_pgc_domain {
 	struct generic_pm_domain genpd;
 	struct regmap *regmap;
 	struct regulator *regulator;
-	struct clk *clk[GPC_CLK_MAX];
+	struct clk_bulk_data *clks;
 	int num_clks;
 
 	unsigned int pgc;
@@ -149,8 +147,12 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	}
 
 	/* Enable reset clocks for all devices in the domain */
-	for (i = 0; i < domain->num_clks; i++)
-		clk_prepare_enable(domain->clk[i]);
+	clk_bulk_prepare_enable(domain->num_clks, domain->clks);
+	if (ret) {
+		dev_err(domain->dev, "failed to enable reset clocks\n");
+		regulator_disable(domain->regulator);
+		return ret;
+	}
 
 	if (enable_power_control)
 		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
@@ -187,8 +189,7 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 				   GPC_PGC_CTRL_PCR, 0);
 
 	/* Disable reset clocks for all devices in the domain */
-	for (i = 0; i < domain->num_clks; i++)
-		clk_disable_unprepare(domain->clk[i]);
+	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
 
 	if (has_regulator && !on) {
 		int err;
@@ -438,41 +439,6 @@ static const struct imx_pgc_domain_data imx8m_pgc_domain_data = {
 	.reg_access_table = &imx8m_access_table,
 };
 
-static int imx_pgc_get_clocks(struct imx_pgc_domain *domain)
-{
-	int i, ret;
-
-	for (i = 0; ; i++) {
-		struct clk *clk = of_clk_get(domain->dev->of_node, i);
-		if (IS_ERR(clk))
-			break;
-		if (i >= GPC_CLK_MAX) {
-			dev_err(domain->dev, "more than %d clocks\n",
-				GPC_CLK_MAX);
-			ret = -EINVAL;
-			goto clk_err;
-		}
-		domain->clk[i] = clk;
-	}
-	domain->num_clks = i;
-
-	return 0;
-
-clk_err:
-	while (i--)
-		clk_put(domain->clk[i]);
-
-	return ret;
-}
-
-static void imx_pgc_put_clocks(struct imx_pgc_domain *domain)
-{
-	int i;
-
-	for (i = domain->num_clks - 1; i >= 0; i--)
-		clk_put(domain->clk[i]);
-}
-
 static int imx_pgc_domain_probe(struct platform_device *pdev)
 {
 	struct imx_pgc_domain *domain = pdev->dev.platform_data;
@@ -490,9 +456,10 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 				      domain->voltage, domain->voltage);
 	}
 
-	ret = imx_pgc_get_clocks(domain);
-	if (ret)
-		return dev_err_probe(domain->dev, ret, "Failed to get domain's clocks\n");
+	domain->num_clks = devm_clk_bulk_get_all(domain->dev, &domain->clks);
+	if (domain->num_clks < 0)
+		return dev_err_probe(domain->dev, domain->num_clks,
+				     "Failed to get domain's clocks\n");
 
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, domain->bits.map);
@@ -517,7 +484,6 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 out_domain_unmap:
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, 0);
-	imx_pgc_put_clocks(domain);
 
 	return ret;
 }
@@ -532,8 +498,6 @@ static int imx_pgc_domain_remove(struct platform_device *pdev)
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, 0);
 
-	imx_pgc_put_clocks(domain);
-
 	return 0;
 }
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:38 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:38 +0800
Subject: [PATCH 04/16] soc: imx: gpcv2: split power up and power down sequence
 control
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-5-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

The current mixed function to control both power up and power down
sequences is very hard to follow and already contains some sequence
errors like triggering the ADB400 handshake at the wrong time due to
this. Split the function into two, which results in slightly more
code, but is way easier to get right.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 141 ++++++++++++++++++++++++----------------
 1 file changed, 86 insertions(+), 55 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 1d90c7802972..7356e48ebdad 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -125,20 +125,19 @@ struct imx_pgc_domain_data {
 	const struct regmap_access_table *reg_access_table;
 };
 
-static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
-				      bool on)
+static inline struct imx_pgc_domain *
+to_imx_pgc_domain(struct generic_pm_domain *genpd)
 {
-	struct imx_pgc_domain *domain = container_of(genpd,
-						      struct imx_pgc_domain,
-						      genpd);
-	unsigned int offset = on ?
-		GPC_PU_PGC_SW_PUP_REQ : GPC_PU_PGC_SW_PDN_REQ;
-	const bool enable_power_control = !on;
-	const bool has_regulator = !IS_ERR(domain->regulator);
-	int i, ret = 0;
-	u32 pxx_req;
-
-	if (has_regulator && on) {
+	return container_of(genpd, struct imx_pgc_domain, genpd);
+}
+
+static int imx_pgc_power_up(struct generic_pm_domain *genpd)
+{
+	struct imx_pgc_domain *domain = to_imx_pgc_domain(genpd);
+	u32 reg_val;
+	int ret;
+
+	if (!IS_ERR(domain->regulator)) {
 		ret = regulator_enable(domain->regulator);
 		if (ret) {
 			dev_err(domain->dev, "failed to enable regulator\n");
@@ -147,72 +146,104 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct generic_pm_domain *genpd,
 	}
 
 	/* Enable reset clocks for all devices in the domain */
-	clk_bulk_prepare_enable(domain->num_clks, domain->clks);
+	ret = clk_bulk_prepare_enable(domain->num_clks, domain->clks);
 	if (ret) {
 		dev_err(domain->dev, "failed to enable reset clocks\n");
+		goto out_regulator_disable;
+	}
+
+	/* request the domain to power up */
+	regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+			   domain->bits.pxx, domain->bits.pxx);
+	/*
+	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+	 * for PUP_REQ/PDN_REQ bit to be cleared
+	 */
+	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+				       reg_val, !(reg_val & domain->bits.pxx),
+				       0, USEC_PER_MSEC);
+	if (ret) {
+		dev_err(domain->dev, "failed to command PGC\n");
+		goto out_clk_disable;
+	}
+
+	/* disable power control */
+	regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+			   GPC_PGC_CTRL_PCR, 0);
+
+	/* request the ADB400 to power up */
+	if (domain->bits.hsk)
+		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
+				   domain->bits.hsk, domain->bits.hsk);
+
+	/* Disable reset clocks for all devices in the domain */
+	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
+
+	return 0;
+
+out_clk_disable:
+	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
+out_regulator_disable:
+	if (!IS_ERR(domain->regulator))
 		regulator_disable(domain->regulator);
+
+	return ret;
+}
+
+static int imx_pgc_power_down(struct generic_pm_domain *genpd)
+{
+	struct imx_pgc_domain *domain = to_imx_pgc_domain(genpd);
+	u32 reg_val;
+	int ret;
+
+	/* Enable reset clocks for all devices in the domain */
+	ret = clk_bulk_prepare_enable(domain->num_clks, domain->clks);
+	if (ret) {
+		dev_err(domain->dev, "failed to enable reset clocks\n");
 		return ret;
 	}
 
-	if (enable_power_control)
-		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				   GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
-
+	/* request the ADB400 to power down */
 	if (domain->bits.hsk)
 		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
-				   domain->bits.hsk, on ? domain->bits.hsk : 0);
+				   domain->bits.hsk, 0);
 
-	regmap_update_bits(domain->regmap, offset,
-			   domain->bits.pxx, domain->bits.pxx);
+	/* enable power control */
+	regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+			   GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
 
+	/* request the domain to power down */
+	regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+			   domain->bits.pxx, domain->bits.pxx);
 	/*
 	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
 	 * for PUP_REQ/PDN_REQ bit to be cleared
 	 */
-	ret = regmap_read_poll_timeout(domain->regmap, offset, pxx_req,
-				       !(pxx_req & domain->bits.pxx),
+	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+				       reg_val, !(reg_val & domain->bits.pxx),
 				       0, USEC_PER_MSEC);
 	if (ret) {
 		dev_err(domain->dev, "failed to command PGC\n");
-		/*
-		 * If we were in a process of enabling a
-		 * domain and failed we might as well disable
-		 * the regulator we just enabled. And if it
-		 * was the opposite situation and we failed to
-		 * power down -- keep the regulator on
-		 */
-		on = !on;
+		goto out_clk_disable;
 	}
 
-	if (enable_power_control)
-		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-				   GPC_PGC_CTRL_PCR, 0);
-
 	/* Disable reset clocks for all devices in the domain */
 	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
 
-	if (has_regulator && !on) {
-		int err;
-
-		err = regulator_disable(domain->regulator);
-		if (err)
-			dev_err(domain->dev,
-				"failed to disable regulator: %d\n", err);
-		/* Preserve earlier error code */
-		ret = ret ?: err;
+	if (!IS_ERR(domain->regulator)) {
+		ret = regulator_disable(domain->regulator);
+		if (ret) {
+			dev_err(domain->dev, "failed to disable regulator\n");
+			return ret;
+		}
 	}
 
-	return ret;
-}
+	return 0;
 
-static int imx_gpc_pu_pgc_sw_pup_req(struct generic_pm_domain *genpd)
-{
-	return imx_gpc_pu_pgc_sw_pxx_req(genpd, true);
-}
+out_clk_disable:
+	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
 
-static int imx_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
-{
-	return imx_gpc_pu_pgc_sw_pxx_req(genpd, false);
+	return ret;
 }
 
 static const struct imx_pgc_domain imx7_pgc_domains[] = {
@@ -590,8 +621,8 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
 
 		domain = pd_pdev->dev.platform_data;
 		domain->regmap = regmap;
-		domain->genpd.power_on  = imx_gpc_pu_pgc_sw_pup_req;
-		domain->genpd.power_off = imx_gpc_pu_pgc_sw_pdn_req;
+		domain->genpd.power_on  = imx_pgc_power_up;
+		domain->genpd.power_off = imx_pgc_power_down;
 
 		pd_pdev->dev.parent = dev;
 		pd_pdev->dev.of_node = np;
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:39 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:39 +0800
Subject: [PATCH 05/16] soc: imx: gpcv2: wait for ADB400 handshake
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-6-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

New reference manuals show that there is actually a status bit for
the ADB400 handshake. Add a poll loop to wait for the ADB400 to
acknowledge our request.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 43 +++++++++++++++++++++++++++++++++--------
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 7356e48ebdad..d27025e37a9e 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -69,6 +69,9 @@
 
 #define GPC_PU_PWRHSK			0x1fc
 
+#define IMX8M_GPU_HSK_PWRDNACKN			BIT(26)
+#define IMX8M_VPU_HSK_PWRDNACKN			BIT(25)
+#define IMX8M_DISP_HSK_PWRDNACKN		BIT(24)
 #define IMX8M_GPU_HSK_PWRDNREQN			BIT(6)
 #define IMX8M_VPU_HSK_PWRDNREQN			BIT(5)
 #define IMX8M_DISP_HSK_PWRDNREQN		BIT(4)
@@ -112,7 +115,8 @@ struct imx_pgc_domain {
 	const struct {
 		u32 pxx;
 		u32 map;
-		u32 hsk;
+		u32 hskreq;
+		u32 hskack;
 	} bits;
 
 	const int voltage;
@@ -172,9 +176,19 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 			   GPC_PGC_CTRL_PCR, 0);
 
 	/* request the ADB400 to power up */
-	if (domain->bits.hsk)
+	if (domain->bits.hskreq) {
 		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
-				   domain->bits.hsk, domain->bits.hsk);
+				   domain->bits.hskreq, domain->bits.hskreq);
+
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
+					       reg_val,
+					       (reg_val & domain->bits.hskack),
+					       0, USEC_PER_MSEC);
+		if (ret) {
+			dev_err(domain->dev, "failed to power up ADB400\n");
+			goto out_clk_disable;
+		}
+	}
 
 	/* Disable reset clocks for all devices in the domain */
 	clk_bulk_disable_unprepare(domain->num_clks, domain->clks);
@@ -204,9 +218,19 @@ static int imx_pgc_power_down(struct generic_pm_domain *genpd)
 	}
 
 	/* request the ADB400 to power down */
-	if (domain->bits.hsk)
+	if (domain->bits.hskreq) {
 		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
-				   domain->bits.hsk, 0);
+				   domain->bits.hskreq, 0);
+
+		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
+					       reg_val,
+					       !(reg_val & domain->bits.hskack),
+					       0, USEC_PER_MSEC);
+		if (ret) {
+			dev_err(domain->dev, "failed to power down ADB400\n");
+			goto out_clk_disable;
+		}
+	}
 
 	/* enable power control */
 	regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
@@ -369,7 +393,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_GPU_SW_Pxx_REQ,
 			.map = IMX8M_GPU_A53_DOMAIN,
-			.hsk = IMX8M_GPU_HSK_PWRDNREQN,
+			.hskreq = IMX8M_GPU_HSK_PWRDNREQN,
+			.hskack = IMX8M_GPU_HSK_PWRDNACKN,
 		},
 		.pgc   = IMX8M_PGC_GPU,
 	},
@@ -381,7 +406,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_VPU_SW_Pxx_REQ,
 			.map = IMX8M_VPU_A53_DOMAIN,
-			.hsk = IMX8M_VPU_HSK_PWRDNREQN,
+			.hskreq = IMX8M_VPU_HSK_PWRDNREQN,
+			.hskack = IMX8M_VPU_HSK_PWRDNACKN,
 		},
 		.pgc   = IMX8M_PGC_VPU,
 	},
@@ -393,7 +419,8 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
 		.bits  = {
 			.pxx = IMX8M_DISP_SW_Pxx_REQ,
 			.map = IMX8M_DISP_A53_DOMAIN,
-			.hsk = IMX8M_DISP_HSK_PWRDNREQN,
+			.hskreq = IMX8M_DISP_HSK_PWRDNREQN,
+			.hskack = IMX8M_DISP_HSK_PWRDNACKN,
 		},
 		.pgc   = IMX8M_PGC_DISP,
 	},
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:40 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:40 +0800
Subject: [PATCH 06/16] soc: imx: gpcv2: add runtime PM support for
 power-domains
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-7-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

This allows to nest domains into other power domains and have the
parent domain powered up/down as required by the child domains.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index d27025e37a9e..87165619a689 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -12,6 +12,7 @@
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/sizes.h>
@@ -141,11 +142,17 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 	u32 reg_val;
 	int ret;
 
+	ret = pm_runtime_get_sync(domain->dev);
+	if (ret) {
+		pm_runtime_put_noidle(domain->dev);
+		return ret;
+	}
+
 	if (!IS_ERR(domain->regulator)) {
 		ret = regulator_enable(domain->regulator);
 		if (ret) {
 			dev_err(domain->dev, "failed to enable regulator\n");
-			return ret;
+			goto out_put_pm;
 		}
 	}
 
@@ -200,6 +207,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 out_regulator_disable:
 	if (!IS_ERR(domain->regulator))
 		regulator_disable(domain->regulator);
+out_put_pm:
+	pm_runtime_put(domain->dev);
 
 	return ret;
 }
@@ -262,6 +271,8 @@ static int imx_pgc_power_down(struct generic_pm_domain *genpd)
 		}
 	}
 
+	pm_runtime_put(domain->dev);
+
 	return 0;
 
 out_clk_disable:
@@ -519,6 +530,8 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 		return dev_err_probe(domain->dev, domain->num_clks,
 				     "Failed to get domain's clocks\n");
 
+	pm_runtime_enable(domain->dev);
+
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, domain->bits.map);
 
@@ -542,6 +555,7 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 out_domain_unmap:
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, 0);
+	pm_runtime_disable(domain->dev);
 
 	return ret;
 }
@@ -556,6 +570,8 @@ static int imx_pgc_domain_remove(struct platform_device *pdev)
 	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
 			   domain->bits.map, 0);
 
+	pm_runtime_disable(domain->dev);
+
 	return 0;
 }
 
-- 
2.30.0



From quanyang.wang at windriver.com  Thu Apr 29 07:58:21 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Thu, 29 Apr 2021 14:58:21 +0800
Subject: [PATCH] dmaengine: xilinx: dpdma: request_irq after initializing dma
 channels
Message-ID: <20210429065821.3495234-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

In some scenarios (kdump), dpdma hardware irqs has been enabled when
calling request_irq in probe function, and then the dpdma irq handler
xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
this moment xdev->chan[i] hasn't been initialized. So let's call the
request_irq after initializing dma channels to avoid kdump kernel
crash as below:

[    3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c
[    3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed
[    3.704900] Mem abort info:
[    3.704902]   ESR = 0x96000005
[    3.704905]   EC = 0x25: DABT (current EL), IL = 32 bits
[    3.704907]   SET = 0, FnV = 0
[    3.704912]   EA = 0, S1PTW = 0
[    3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator
[    3.715585] Data abort info:
[    3.715587]   ISV = 0, ISS = 0x00000005
[    3.715589]   CM = 0, WnR = 0
[    3.715592] [000000000000012c] user address but active_mm is swapper
[    3.715596] Internal error: Oops: 96000005 [#1] SMP
[    3.715599] Modules linked in:
[    3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77
[    3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
[    3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
[    3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
[    3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
[    3.798089] sp : ffffffc01186bdf0
[    3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
[    3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
[    3.811996] x25: 0000000008000408 x24: 0000000000000003
[    3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
[    3.822604] x21: 0000000000000000 x20: 0000000008000408
[    3.827908] x19: 0000000000000000 x18: 0000000000000010
[    3.833212] x17: 0000000000000000 x16: 0000000000000000
[    3.838516] x15: 0000000000000000 x14: ffffffc011291740
[    3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
[    3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
[    3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
[    3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
[    3.865036] x5 : 0000000000000003 x4 : 0000000000000000
[    3.870340] x3 : 0000000000000001 x2 : 0000000000000000
[    3.875644] x1 : 0000000000000000 x0 : 000000000000012c
[    3.880948] Call trace:
[    3.883382]  xilinx_dpdma_irq_handler+0x418/0x560
[    3.888079]  __handle_irq_event_percpu+0x5c/0x178
[    3.892774]  handle_irq_event_percpu+0x34/0x98
[    3.897210]  handle_irq_event+0x44/0xb8
[    3.901030]  handle_fasteoi_irq+0xd0/0x190
[    3.905117]  generic_handle_irq+0x30/0x48
[    3.909111]  __handle_domain_irq+0x64/0xc0
[    3.913192]  gic_handle_irq+0x78/0xa0
[    3.916846]  el1_irq+0xc4/0x180
[    3.919982]  cpuidle_enter_state+0x134/0x2f8
[    3.924243]  cpuidle_enter+0x38/0x50
[    3.927810]  call_cpuidle+0x1c/0x40
[    3.931290]  do_idle+0x20c/0x270
[    3.934502]  cpu_startup_entry+0x28/0x58
[    3.938410]  rest_init+0xbc/0xcc
[    3.941631]  arch_call_rest_init+0x10/0x1c
[    3.945718]  start_kernel+0x51c/0x558

Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
 drivers/dma/xilinx/xilinx_dpdma.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index 70b29bd079c9..0b599402c53f 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -1622,19 +1622,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
 	if (IS_ERR(xdev->reg))
 		return PTR_ERR(xdev->reg);
 
-	xdev->irq = platform_get_irq(pdev, 0);
-	if (xdev->irq < 0) {
-		dev_err(xdev->dev, "failed to get platform irq\n");
-		return xdev->irq;
-	}
-
-	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
-			  dev_name(xdev->dev), xdev);
-	if (ret) {
-		dev_err(xdev->dev, "failed to request IRQ\n");
-		return ret;
-	}
-
 	ddev = &xdev->common;
 	ddev->dev = &pdev->dev;
 
@@ -1688,6 +1675,19 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
 		goto error_of_dma;
 	}
 
+	xdev->irq = platform_get_irq(pdev, 0);
+	if (xdev->irq < 0) {
+		dev_err(xdev->dev, "failed to get platform irq\n");
+		goto error_irq;
+	}
+
+	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
+			  dev_name(xdev->dev), xdev);
+	if (ret) {
+		dev_err(xdev->dev, "failed to request IRQ\n");
+		goto error_irq;
+	}
+
 	xilinx_dpdma_enable_irq(xdev);
 
 	xilinx_dpdma_debugfs_init(xdev);
@@ -1696,6 +1696,8 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
 
 	return 0;
 
+error_irq:
+	of_dma_controller_free(pdev->dev.of_node);
 error_of_dma:
 	dma_async_device_unregister(ddev);
 error_dma_async:
@@ -1704,8 +1706,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
 	for (i = 0; i < ARRAY_SIZE(xdev->chan); i++)
 		xilinx_dpdma_chan_remove(xdev->chan[i]);
 
-	free_irq(xdev->irq, xdev);
-
 	return ret;
 }
 
-- 
2.25.1



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:41 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:41 +0800
Subject: [PATCH 07/16] soc: imx: gpcv2: allow domains without power-sequence
 control
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-8-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

Some of the PGC domains only control the handshake with the ADB400
and don't have any power sequence controls. Make such domains work
by allowing the pxx and map bits to be empty and skip all actions
using those controls.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 89 +++++++++++++++++++++++------------------
 1 file changed, 49 insertions(+), 40 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 87165619a689..640f4165cfba 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -163,24 +163,27 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 		goto out_regulator_disable;
 	}
 
-	/* request the domain to power up */
-	regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
-			   domain->bits.pxx, domain->bits.pxx);
-	/*
-	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
-	 * for PUP_REQ/PDN_REQ bit to be cleared
-	 */
-	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
-				       reg_val, !(reg_val & domain->bits.pxx),
-				       0, USEC_PER_MSEC);
-	if (ret) {
-		dev_err(domain->dev, "failed to command PGC\n");
-		goto out_clk_disable;
-	}
+	if (domain->bits.pxx) {
+		/* request the domain to power up */
+		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
+				   domain->bits.pxx, domain->bits.pxx);
+		/*
+		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+		 * for PUP_REQ/PDN_REQ bit to be cleared
+		 */
+		ret = regmap_read_poll_timeout(domain->regmap,
+					       GPC_PU_PGC_SW_PUP_REQ, reg_val,
+					       !(reg_val & domain->bits.pxx),
+					       0, USEC_PER_MSEC);
+		if (ret) {
+			dev_err(domain->dev, "failed to command PGC\n");
+			goto out_clk_disable;
+		}
 
-	/* disable power control */
-	regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-			   GPC_PGC_CTRL_PCR, 0);
+		/* disable power control */
+		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+				   GPC_PGC_CTRL_PCR, 0);
+	}
 
 	/* request the ADB400 to power up */
 	if (domain->bits.hskreq) {
@@ -241,23 +244,26 @@ static int imx_pgc_power_down(struct generic_pm_domain *genpd)
 		}
 	}
 
-	/* enable power control */
-	regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
-			   GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
-
-	/* request the domain to power down */
-	regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
-			   domain->bits.pxx, domain->bits.pxx);
-	/*
-	 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
-	 * for PUP_REQ/PDN_REQ bit to be cleared
-	 */
-	ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
-				       reg_val, !(reg_val & domain->bits.pxx),
-				       0, USEC_PER_MSEC);
-	if (ret) {
-		dev_err(domain->dev, "failed to command PGC\n");
-		goto out_clk_disable;
+	if (domain->bits.pxx) {
+		/* enable power control */
+		regmap_update_bits(domain->regmap, GPC_PGC_CTRL(domain->pgc),
+				   GPC_PGC_CTRL_PCR, GPC_PGC_CTRL_PCR);
+
+		/* request the domain to power down */
+		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PDN_REQ,
+				   domain->bits.pxx, domain->bits.pxx);
+		/*
+		 * As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
+		 * for PUP_REQ/PDN_REQ bit to be cleared
+		 */
+		ret = regmap_read_poll_timeout(domain->regmap,
+					       GPC_PU_PGC_SW_PDN_REQ, reg_val,
+					       !(reg_val & domain->bits.pxx),
+					       0, USEC_PER_MSEC);
+		if (ret) {
+			dev_err(domain->dev, "failed to command PGC\n");
+			goto out_clk_disable;
+		}
 	}
 
 	/* Disable reset clocks for all devices in the domain */
@@ -532,8 +538,9 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 
 	pm_runtime_enable(domain->dev);
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, domain->bits.map);
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, domain->bits.map);
 
 	ret = pm_genpd_init(&domain->genpd, NULL, true);
 	if (ret) {
@@ -553,8 +560,9 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 out_genpd_remove:
 	pm_genpd_remove(&domain->genpd);
 out_domain_unmap:
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
 	pm_runtime_disable(domain->dev);
 
 	return ret;
@@ -567,8 +575,9 @@ static int imx_pgc_domain_remove(struct platform_device *pdev)
 	of_genpd_del_provider(domain->dev->of_node);
 	pm_genpd_remove(&domain->genpd);
 
-	regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
-			   domain->bits.map, 0);
+	if (domain->bits.map)
+		regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
+				   domain->bits.map, 0);
 
 	pm_runtime_disable(domain->dev);
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:42 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:42 +0800
Subject: [PATCH 08/16] dt-bindings: imx: gpcv2: add support for optional resets
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-9-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

For some domains the resets of the devices in the domain are not
automatically triggered. Add an optional resets property to allow
the GPC driver to trigger those resets explicitly.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
index a96e6dbf1858..4330c73a2c30 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -66,6 +66,13 @@ properties:
 
           power-supply: true
 
+          resets:
+            description: |
+              A number of phandles to resets that need to be asserted during
+              power-up sequencing of the domain.
+            minItems: 1
+            maxItems: 4
+
         required:
           - '#power-domain-cells'
           - reg
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:43 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:43 +0800
Subject: [PATCH 09/16] soc: imx: gpcv2: add support for optional resets
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-10-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

Normally the reset for the devices inside the power domain is
triggered automatically from the PGC in the power-up sequencing,
however on i.MX8MM this doesn't work for the GPU power domains.

Add support for triggering the reset explicitly during the power
up sequencing.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 640f4165cfba..4a2c2a255d1a 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -15,6 +15,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
+#include <linux/reset.h>
 #include <linux/sizes.h>
 #include <dt-bindings/power/imx7-power.h>
 #include <dt-bindings/power/imx8mq-power.h>
@@ -108,6 +109,7 @@ struct imx_pgc_domain {
 	struct generic_pm_domain genpd;
 	struct regmap *regmap;
 	struct regulator *regulator;
+	struct reset_control *reset;
 	struct clk_bulk_data *clks;
 	int num_clks;
 
@@ -163,6 +165,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 		goto out_regulator_disable;
 	}
 
+	reset_control_assert(domain->reset);
+
 	if (domain->bits.pxx) {
 		/* request the domain to power up */
 		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
@@ -185,6 +189,11 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 				   GPC_PGC_CTRL_PCR, 0);
 	}
 
+	/* delay for reset to propagate */
+	udelay(5);
+
+	reset_control_deassert(domain->reset);
+
 	/* request the ADB400 to power up */
 	if (domain->bits.hskreq) {
 		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
@@ -531,11 +540,17 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 				      domain->voltage, domain->voltage);
 	}
 
+
 	domain->num_clks = devm_clk_bulk_get_all(domain->dev, &domain->clks);
 	if (domain->num_clks < 0)
 		return dev_err_probe(domain->dev, domain->num_clks,
 				     "Failed to get domain's clocks\n");
 
+	domain->reset = devm_reset_control_array_get_optional_exclusive(domain->dev);
+	if (IS_ERR(domain->reset))
+		return dev_err_probe(domain->dev, PTR_ERR(domain->reset),
+				     "Failed to get domain's resets\n");
+
 	pm_runtime_enable(domain->dev);
 
 	if (domain->bits.map)
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:44 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:44 +0800
Subject: [PATCH 10/16] dt-bindings: power: add defines for i.MX8MM power
 domains
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-11-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

Adding defines for i.MX8MM GPC power domains.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 .../bindings/power/fsl,imx-gpcv2.yaml         |  2 ++
 include/dt-bindings/power/imx8mm-power.h      | 22 +++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 include/dt-bindings/power/imx8mm-power.h

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
index 4330c73a2c30..d3539569d45f 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -26,6 +26,7 @@ properties:
     enum:
       - fsl,imx7d-gpc
       - fsl,imx8mq-gpc
+      - fsl,imx8mm-gpc
 
   reg:
     maxItems: 1
@@ -54,6 +55,7 @@ properties:
               Power domain index. Valid values are defined in
               include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and
               include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc
+              include/dt-bindings/power/imx8mm-power.h for fsl,imx8mm-gpc
             maxItems: 1
 
           clocks:
diff --git a/include/dt-bindings/power/imx8mm-power.h b/include/dt-bindings/power/imx8mm-power.h
new file mode 100644
index 000000000000..fc9c2e16aadc
--- /dev/null
+++ b/include/dt-bindings/power/imx8mm-power.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2020 Pengutronix, Lucas Stach <kernel at pengutronix.de>
+ */
+
+#ifndef __DT_BINDINGS_IMX8MM_POWER_H__
+#define __DT_BINDINGS_IMX8MM_POWER_H__
+
+#define IMX8MM_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MM_POWER_DOMAIN_PCIE	1
+#define IMX8MM_POWER_DOMAIN_OTG1	2
+#define IMX8MM_POWER_DOMAIN_OTG2	3
+#define IMX8MM_POWER_DOMAIN_GPUMIX	4
+#define IMX8MM_POWER_DOMAIN_GPU		5
+#define IMX8MM_POWER_DOMAIN_VPUMIX	6
+#define IMX8MM_POWER_DOMAIN_VPUG1	7
+#define IMX8MM_POWER_DOMAIN_VPUG2	8
+#define IMX8MM_POWER_DOMAIN_VPUH1	9
+#define IMX8MM_POWER_DOMAIN_DISPMIX	10
+#define IMX8MM_POWER_DOMAIN_MIPI	11
+
+#endif
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:45 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:45 +0800
Subject: [PATCH 11/16] soc: imx: gpcv2: add support for i.MX8MM power domains
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-12-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

This adds support for the power domains founds on i.MX8MM. The 2D and 3D
GPU domains are abstracted as a single domain in the driver, as they can't
be powered up/down individually due to a shared reset.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
---
 drivers/soc/imx/gpcv2.c | 168 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 168 insertions(+)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 4a2c2a255d1a..5642dd236c10 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -19,6 +19,7 @@
 #include <linux/sizes.h>
 #include <dt-bindings/power/imx7-power.h>
 #include <dt-bindings/power/imx8mq-power.h>
+#include <dt-bindings/power/imx8mm-power.h>
 
 #define GPC_LPCR_A_CORE_BSC			0x000
 
@@ -44,6 +45,19 @@
 #define IMX8M_PCIE1_A53_DOMAIN			BIT(3)
 #define IMX8M_MIPI_A53_DOMAIN			BIT(2)
 
+#define IMX8MM_VPUH1_A53_DOMAIN			BIT(15)
+#define IMX8MM_VPUG2_A53_DOMAIN			BIT(14)
+#define IMX8MM_VPUG1_A53_DOMAIN			BIT(13)
+#define IMX8MM_DISPMIX_A53_DOMAIN		BIT(12)
+#define IMX8MM_VPUMIX_A53_DOMAIN		BIT(10)
+#define IMX8MM_GPUMIX_A53_DOMAIN		BIT(9)
+#define IMX8MM_GPU_A53_DOMAIN			(BIT(8) | BIT(11))
+#define IMX8MM_DDR1_A53_DOMAIN			BIT(7)
+#define IMX8MM_OTG2_A53_DOMAIN			BIT(5)
+#define IMX8MM_OTG1_A53_DOMAIN			BIT(4)
+#define IMX8MM_PCIE_A53_DOMAIN			BIT(3)
+#define IMX8MM_MIPI_A53_DOMAIN			BIT(2)
+
 #define GPC_PU_PGC_SW_PUP_REQ		0x0f8
 #define GPC_PU_PGC_SW_PDN_REQ		0x104
 
@@ -67,6 +81,19 @@
 #define IMX8M_PCIE1_SW_Pxx_REQ			BIT(1)
 #define IMX8M_MIPI_SW_Pxx_REQ			BIT(0)
 
+#define IMX8MM_VPUH1_SW_Pxx_REQ			BIT(13)
+#define IMX8MM_VPUG2_SW_Pxx_REQ			BIT(12)
+#define IMX8MM_VPUG1_SW_Pxx_REQ			BIT(11)
+#define IMX8MM_DISPMIX_SW_Pxx_REQ		BIT(10)
+#define IMX8MM_VPUMIX_SW_Pxx_REQ		BIT(8)
+#define IMX8MM_GPUMIX_SW_Pxx_REQ		BIT(7)
+#define IMX8MM_GPU_SW_Pxx_REQ			(BIT(6) | BIT(9))
+#define IMX8MM_DDR1_SW_Pxx_REQ			BIT(5)
+#define IMX8MM_OTG2_SW_Pxx_REQ			BIT(3)
+#define IMX8MM_OTG1_SW_Pxx_REQ			BIT(2)
+#define IMX8MM_PCIE_SW_Pxx_REQ			BIT(1)
+#define IMX8MM_MIPI_SW_Pxx_REQ			BIT(0)
+
 #define GPC_M4_PU_PDN_FLG		0x1bc
 
 #define GPC_PU_PWRHSK			0x1fc
@@ -78,6 +105,17 @@
 #define IMX8M_VPU_HSK_PWRDNREQN			BIT(5)
 #define IMX8M_DISP_HSK_PWRDNREQN		BIT(4)
 
+
+#define IMX8MM_GPUMIX_HSK_PWRDNACKN		BIT(29)
+#define IMX8MM_GPU_HSK_PWRDNACKN		(BIT(27) | BIT(28))
+#define IMX8MM_VPUMIX_HSK_PWRDNACKN		BIT(26)
+#define IMX8MM_DISPMIX_HSK_PWRDNACKN		BIT(25)
+#define IMX8MM_HSIO_HSK_PWRDNACKN		(BIT(23) | BIT(24))
+#define IMX8MM_GPUMIX_HSK_PWRDNREQN		BIT(11)
+#define IMX8MM_GPU_HSK_PWRDNREQN		(BIT(9) | BIT(10))
+#define IMX8MM_VPUMIX_HSK_PWRDNREQN		BIT(8)
+#define IMX8MM_DISPMIX_HSK_PWRDNREQN		BIT(7)
+#define IMX8MM_HSIO_HSK_PWRDNREQN		(BIT(5) | BIT(6))
 /*
  * The PGC offset values in Reference Manual
  * (Rev. 1, 01/2018 and the older ones) GPC chapter's
@@ -100,6 +138,20 @@
 #define IMX8M_PGC_MIPI_CSI2		28
 #define IMX8M_PGC_PCIE2			29
 
+#define IMX8MM_PGC_MIPI			16
+#define IMX8MM_PGC_PCIE			17
+#define IMX8MM_PGC_OTG1			18
+#define IMX8MM_PGC_OTG2			19
+#define IMX8MM_PGC_DDR1			21
+#define IMX8MM_PGC_GPU2D		22
+#define IMX8MM_PGC_GPUMIX		23
+#define IMX8MM_PGC_VPUMIX		24
+#define IMX8MM_PGC_GPU3D		25
+#define IMX8MM_PGC_DISPMIX		26
+#define IMX8MM_PGC_VPUG1		27
+#define IMX8MM_PGC_VPUG2		28
+#define IMX8MM_PGC_VPUH1		29
+
 #define GPC_PGC_CTRL(n)			(0x800 + (n) * 0x40)
 #define GPC_PGC_SR(n)			(GPC_PGC_CTRL(n) + 0xc)
 
@@ -523,6 +575,121 @@ static const struct imx_pgc_domain_data imx8m_pgc_domain_data = {
 	.reg_access_table = &imx8m_access_table,
 };
 
+static const struct imx_pgc_domain imx8mm_pgc_domains[] = {
+	[IMX8MM_POWER_DOMAIN_HSIOMIX] = {
+		.genpd = {
+			.name = "hsiomix",
+		},
+		.bits  = {
+			.pxx = 0, /* no power sequence control */
+			.map = 0, /* no power sequence control */
+			.hskreq = IMX8MM_HSIO_HSK_PWRDNREQN,
+			.hskack = IMX8MM_HSIO_HSK_PWRDNACKN,
+		},
+	},
+
+	[IMX8MM_POWER_DOMAIN_PCIE] = {
+		.genpd = {
+			.name = "pcie",
+		},
+		.bits  = {
+			.pxx = IMX8MM_PCIE_SW_Pxx_REQ,
+			.map = IMX8MM_PCIE_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_PCIE,
+	},
+
+	[IMX8MM_POWER_DOMAIN_OTG1] = {
+		.genpd = {
+			.name = "usb-otg1",
+		},
+		.bits  = {
+			.pxx = IMX8MM_OTG1_SW_Pxx_REQ,
+			.map = IMX8MM_OTG1_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_OTG1,
+	},
+
+	[IMX8MM_POWER_DOMAIN_OTG2] = {
+		.genpd = {
+			.name = "usb-otg2",
+		},
+		.bits  = {
+			.pxx = IMX8MM_OTG2_SW_Pxx_REQ,
+			.map = IMX8MM_OTG2_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_OTG2,
+	},
+
+	[IMX8MM_POWER_DOMAIN_GPUMIX] = {
+		.genpd = {
+			.name = "gpumix",
+		},
+		.bits  = {
+			.pxx = IMX8MM_GPUMIX_SW_Pxx_REQ,
+			.map = IMX8MM_GPUMIX_A53_DOMAIN,
+			.hskreq = IMX8MM_GPUMIX_HSK_PWRDNREQN,
+			.hskack = IMX8MM_GPUMIX_HSK_PWRDNACKN,
+		},
+		.pgc   = IMX8MM_PGC_GPUMIX,
+	},
+
+	[IMX8MM_POWER_DOMAIN_GPU] = {
+		.genpd = {
+			.name = "gpu",
+		},
+		.bits  = {
+			.pxx = IMX8MM_GPU_SW_Pxx_REQ,
+			.map = IMX8MM_GPU_A53_DOMAIN,
+			.hskreq = IMX8MM_GPU_HSK_PWRDNREQN,
+			.hskack = IMX8MM_GPU_HSK_PWRDNACKN,
+		},
+		.pgc   = IMX8MM_PGC_GPU2D,
+	},
+};
+
+static const struct regmap_range imx8mm_yes_ranges[] = {
+		regmap_reg_range(GPC_LPCR_A_CORE_BSC,
+				 GPC_PU_PWRHSK),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_MIPI),
+				 GPC_PGC_SR(IMX8MM_PGC_MIPI)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_PCIE),
+				 GPC_PGC_SR(IMX8MM_PGC_PCIE)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_OTG1),
+				 GPC_PGC_SR(IMX8MM_PGC_OTG1)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_OTG2),
+				 GPC_PGC_SR(IMX8MM_PGC_OTG2)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_DDR1),
+				 GPC_PGC_SR(IMX8MM_PGC_DDR1)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_GPU2D),
+				 GPC_PGC_SR(IMX8MM_PGC_GPU2D)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_GPUMIX),
+				 GPC_PGC_SR(IMX8MM_PGC_GPUMIX)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_VPUMIX),
+				 GPC_PGC_SR(IMX8MM_PGC_VPUMIX)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_GPU3D),
+				 GPC_PGC_SR(IMX8MM_PGC_GPU3D)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_DISPMIX),
+				 GPC_PGC_SR(IMX8MM_PGC_DISPMIX)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_VPUG1),
+				 GPC_PGC_SR(IMX8MM_PGC_VPUG1)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_VPUG2),
+				 GPC_PGC_SR(IMX8MM_PGC_VPUG2)),
+		regmap_reg_range(GPC_PGC_CTRL(IMX8MM_PGC_VPUH1),
+				 GPC_PGC_SR(IMX8MM_PGC_VPUH1)),
+};
+
+static const struct regmap_access_table imx8mm_access_table = {
+	.yes_ranges	= imx8mm_yes_ranges,
+	.n_yes_ranges	= ARRAY_SIZE(imx8mm_yes_ranges),
+};
+
+static const struct imx_pgc_domain_data imx8mm_pgc_domain_data = {
+	.domains = imx8mm_pgc_domains,
+	.domains_num = ARRAY_SIZE(imx8mm_pgc_domains),
+	.reg_access_table = &imx8mm_access_table,
+};
+
 static int imx_pgc_domain_probe(struct platform_device *pdev)
 {
 	struct imx_pgc_domain *domain = pdev->dev.platform_data;
@@ -707,6 +874,7 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
 
 static const struct of_device_id imx_gpcv2_dt_ids[] = {
 	{ .compatible = "fsl,imx7d-gpc", .data = &imx7_pgc_domain_data, },
+	{ .compatible = "fsl,imx8mm-gpc", .data = &imx8mm_pgc_domain_data, },
 	{ .compatible = "fsl,imx8mq-gpc", .data = &imx8m_pgc_domain_data, },
 	{ }
 };
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:46 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:46 +0800
Subject: [PATCH 12/16] soc: imx: gpcv2: Add support for missing i.MX8MM
 VPU/DISPMIX power domains
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-13-peng.fan@oss.nxp.com>

From: Lucas Stach <l.stach at pengutronix.de>

With the BLK-CTL driver now in place, let's add the missing domains.

Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
Signed-off-by: Frieder Schrempf <frieder.schrempf at kontron.de>
---
 drivers/soc/imx/gpcv2.c | 70 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 5642dd236c10..42b9be05e1f2 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -646,6 +646,76 @@ static const struct imx_pgc_domain imx8mm_pgc_domains[] = {
 		},
 		.pgc   = IMX8MM_PGC_GPU2D,
 	},
+
+	[IMX8MM_POWER_DOMAIN_VPUMIX] = {
+		.genpd = {
+			.name = "vpumix",
+		},
+		.bits  = {
+			.pxx = IMX8MM_VPUMIX_SW_Pxx_REQ,
+			.map = IMX8MM_VPUMIX_A53_DOMAIN,
+			.hskreq = IMX8MM_VPUMIX_HSK_PWRDNREQN,
+			.hskack = IMX8MM_VPUMIX_HSK_PWRDNACKN,
+		},
+		.pgc   = IMX8MM_PGC_VPUMIX,
+	},
+
+	[IMX8MM_POWER_DOMAIN_VPUG1] = {
+		.genpd = {
+			.name = "vpu-g1",
+		},
+		.bits  = {
+			.pxx = IMX8MM_VPUG1_SW_Pxx_REQ,
+			.map = IMX8MM_VPUG1_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_VPUG1,
+	},
+
+	[IMX8MM_POWER_DOMAIN_VPUG2] = {
+		.genpd = {
+			.name = "vpu-g2",
+		},
+		.bits  = {
+			.pxx = IMX8MM_VPUG2_SW_Pxx_REQ,
+			.map = IMX8MM_VPUG2_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_VPUG2,
+	},
+
+	[IMX8MM_POWER_DOMAIN_VPUH1] = {
+		.genpd = {
+			.name = "vpu-h1",
+		},
+		.bits  = {
+			.pxx = IMX8MM_VPUH1_SW_Pxx_REQ,
+			.map = IMX8MM_VPUH1_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_VPUH1,
+	},
+
+	[IMX8MM_POWER_DOMAIN_DISPMIX] = {
+		.genpd = {
+			.name = "dispmix",
+		},
+		.bits  = {
+			.pxx = IMX8MM_DISPMIX_SW_Pxx_REQ,
+			.map = IMX8MM_DISPMIX_A53_DOMAIN,
+			.hskreq = IMX8MM_DISPMIX_HSK_PWRDNREQN,
+			.hskack = IMX8MM_DISPMIX_HSK_PWRDNACKN,
+		},
+		.pgc   = IMX8MM_PGC_DISPMIX,
+	},
+
+	[IMX8MM_POWER_DOMAIN_MIPI] = {
+		.genpd = {
+			.name = "mipi",
+		},
+		.bits  = {
+			.pxx = IMX8MM_MIPI_SW_Pxx_REQ,
+			.map = IMX8MM_MIPI_A53_DOMAIN,
+		},
+		.pgc   = IMX8MM_PGC_MIPI,
+	},
 };
 
 static const struct regmap_range imx8mm_yes_ranges[] = {
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:47 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:47 +0800
Subject: [PATCH 13/16] soc: imx: gpcv2: correct pm_runtime_get_sync usage
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-14-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

When the return value is negative, there is error, otherwise it is
expected.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/gpcv2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 42b9be05e1f2..d2ce47a5ebad 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -197,7 +197,7 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 	int ret;
 
 	ret = pm_runtime_get_sync(domain->dev);
-	if (ret) {
+	if (ret < 0) {
 		pm_runtime_put_noidle(domain->dev);
 		return ret;
 	}
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:48 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:48 +0800
Subject: [PATCH 14/16] soc: imx: gpcv2: move reset assert after requesting
 domain power up
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-15-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

The i.MX8MM VPU power up sequence is a bit special, it must follow:
1. request power up
2. reset assert
3. reset deassert

This change in this patch will not affect other domains, because
the power domain default is in asserted state, unless bootloader
deassert the reset.

[Note: We expect bootloader leave the domain in asserted state,
but this may not always be true, so we might need another solution
to address the VPU domain requirements]

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/gpcv2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index d2ce47a5ebad..072f519462a5 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -217,8 +217,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 		goto out_regulator_disable;
 	}
 
-	reset_control_assert(domain->reset);
-
 	if (domain->bits.pxx) {
 		/* request the domain to power up */
 		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
@@ -241,6 +239,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 				   GPC_PGC_CTRL_PCR, 0);
 	}
 
+	reset_control_assert(domain->reset);
+
 	/* delay for reset to propagate */
 	udelay(5);
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:49 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:49 +0800
Subject: [PATCH 15/16] soc: imx: gpcv2: support reset defer probe
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-16-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

When gpcv2 probe, the reset controller might not be ready, so we need
defer probe

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/gpcv2.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 072f519462a5..49dd137f6b94 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -784,9 +784,12 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
 				     "Failed to get domain's clocks\n");
 
 	domain->reset = devm_reset_control_array_get_optional_exclusive(domain->dev);
-	if (IS_ERR(domain->reset))
+	if (IS_ERR(domain->reset)) {
+		if (PTR_ERR(domain->reset) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		return dev_err_probe(domain->dev, PTR_ERR(domain->reset),
 				     "Failed to get domain's resets\n");
+	}
 
 	pm_runtime_enable(domain->dev);
 
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:30:50 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:30:50 +0800
Subject: [PATCH 16/16] soc: imx: gpcv2: remove waiting handshake in power up
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073050.21039-17-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

i.MX8MM has blk ctl module, the handshake can only finish after setting
blk ctl. The blk ctl driver will set the bus clk bit and the handshake
will finish there. we just add a delay and suppose the handshake will
finish after that.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/gpcv2.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 49dd137f6b94..04564017bfe9 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -251,14 +251,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
 		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
 				   domain->bits.hskreq, domain->bits.hskreq);
 
-		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
-					       reg_val,
-					       (reg_val & domain->bits.hskack),
-					       0, USEC_PER_MSEC);
-		if (ret) {
-			dev_err(domain->dev, "failed to power up ADB400\n");
-			goto out_clk_disable;
-		}
 	}
 
 	/* Disable reset clocks for all devices in the domain */
-- 
2.30.0



From Avri.Altman at wdc.com  Thu Apr 29 08:01:04 2021
From: Avri.Altman at wdc.com (Avri Altman)
Date: Thu, 29 Apr 2021 07:01:04 +0000
Subject: [PATCH v21 0/2] Enable power management for ufs wlun
In-Reply-To: <yq1y2d1lr9m.fsf@ca-mkp.ca.oracle.com>
References: <cover.1619223249.git.asutoshd@codeaurora.org>
 <yq1y2d1lr9m.fsf@ca-mkp.ca.oracle.com>
Message-ID: <DM6PR04MB657549AFA87A8C88058C608AFC5F9@DM6PR04MB6575.namprd04.prod.outlook.com>

> Asutosh,
In several places there is now a reference: "Also check the description of __ufshcd_wl_suspend()"
But no such description is to found.
Might want to add it in a supplementary patch?

Thanks,
Avri

> 
> > This patch attempts to fix a deadlock in ufs while sending SSU.
> 
> Applied to 5.14/scsi-staging, thanks!
> 
> --
> Martin K. Petersen      Oracle Linux Engineering


From peng.fan at oss.nxp.com  Thu Apr 29 08:33:27 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:33:27 +0800
Subject: [PATCH 0/4] soc: imx: add i.MX BLK-CTL support
Message-ID: <20210429073331.21204-1-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Previously there is an effort from Abel that take BLK-CTL as clock
provider, but it turns out that there is A/B lock issue and we are
not able resolve that.

Per discuss with Lucas and Jacky, we made an agreement that take BLK-CTL
as a power domain provider and use GPC's domain as parent, the consumer
node take BLK-CTL as power domain input.

This patchset has been tested on i.MX8MM EVK board, but one hack
is not included in the patchset is that the DISPMIX BLK-CTL MIPI_M/S_RESET
not implemented. Per Lucas, we will finally have a MIPI DPHY driver,
so fine to leave it.

Thanks for Lucas's suggestion, Frieder Schrempf for collecting
all the patches, Abel's previous BLK-CTL work, Jacky Bai on help
debug issues.

Peng Fan (4):
  dt-bindings: power: Add defines for i.MX8MM BLK-CTL power domains
  Documentation: bindings: clk: Add bindings for i.MX BLK_CTL
  soc: imx: Add generic blk-ctl driver
  soc: imx: Add blk-ctl driver for i.MX8MM

 .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     |  73 +++++
 drivers/soc/imx/Makefile                      |   2 +-
 drivers/soc/imx/blk-ctl-imx8mm.c              | 138 ++++++++
 drivers/soc/imx/blk-ctl.c                     | 303 ++++++++++++++++++
 drivers/soc/imx/blk-ctl.h                     |  76 +++++
 include/dt-bindings/power/imx8mm-power.h      |  11 +
 6 files changed, 602 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
 create mode 100644 drivers/soc/imx/blk-ctl-imx8mm.c
 create mode 100644 drivers/soc/imx/blk-ctl.c
 create mode 100644 drivers/soc/imx/blk-ctl.h

-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:33:28 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:33:28 +0800
Subject: [PATCH 1/4] dt-bindings: power: Add defines for i.MX8MM BLK-CTL power
 domains
In-Reply-To: <20210429073331.21204-1-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073331.21204-2-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Adding the defines for i.MX8MM BLK-CTL power domains.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 include/dt-bindings/power/imx8mm-power.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/dt-bindings/power/imx8mm-power.h b/include/dt-bindings/power/imx8mm-power.h
index fc9c2e16aadc..510e383d1953 100644
--- a/include/dt-bindings/power/imx8mm-power.h
+++ b/include/dt-bindings/power/imx8mm-power.h
@@ -19,4 +19,15 @@
 #define IMX8MM_POWER_DOMAIN_DISPMIX	10
 #define IMX8MM_POWER_DOMAIN_MIPI	11
 
+#define IMX8MM_BLK_CTL_G2_PD		0
+#define IMX8MM_BLK_CTL_G1_PD		1
+#define IMX8MM_BLK_CTL_H1_PD		2
+#define IMX8MM_BLK_CTL_MAX_PD		3
+
+#define IMX8MM_BLK_CTL_DISPMIX_CSI_BRIDGE	0
+#define IMX8MM_BLK_CTL_DISPMIX_LCDIF		1
+#define IMX8MM_BLK_CTL_DISPMIX_MIPI_DSI		2
+#define IMX8MM_BLK_CTL_DISPMIX_MIPI_CSI		3
+#define IMX8MM_BLK_CTL_DISPMIX_MAX_PD		4
+
 #endif
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:33:29 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:33:29 +0800
Subject: [PATCH 2/4] Documentation: bindings: clk: Add bindings for i.MX
 BLK_CTL
In-Reply-To: <20210429073331.21204-1-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073331.21204-3-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Document the i.MX BLK_CTL with its devicetree properties.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     | 73 +++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml

diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
new file mode 100644
index 000000000000..8160ce51a8fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/imx/fsl,imx-blk-ctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX BLK_CTL
+
+maintainers:
+  - Peng Fan <peng.fan at nxp.com>
+
+description:
+  i.MX BLK_CTL is a conglomerate of different GPRs that are
+  dedicated to a specific subsystem. It usually contains
+  clocks and resets amongst other things. Here we take the clocks
+  and resets as virtual PDs, the reason we could not take it as
+  clock provider is there is A/B lock issue between power domain
+  and clock.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - fsl,imx8mm-vpumix-blk-ctl
+          - fsl,imx8mp-dispmix-blk-ctl
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  "#power-domain-cells":
+    const: 1
+
+  power-domains:
+    minItems: 1
+    maxItems: 32
+
+  power-domain-names:
+    minItems: 1
+    maxItems: 32
+
+  '#reset-cells':
+    const: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 32
+
+  clock-names:
+    minItems: 1
+    maxItems: 32
+
+required:
+  - compatible
+  - reg
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+
+    dispmix_blk_ctl: blk-ctl at 32e28000 {
+      compatible = "fsl,imx8mm-dispmix-blk-ctl", "syscon";
+      reg = <0x32e28000 0x100>;
+      #power-domain-cells = <1>;
+      power-domains = <&pgc_dispmix>, <&pgc_mipi>;
+      power-domain-names = "dispmix", "mipi";
+      clocks = <&clk IMX8MM_CLK_DISP_ROOT>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>,
+               <&clk IMX8MM_CLK_DISP_APB_ROOT>;
+      clock-names = "disp", "axi", "apb";
+    };
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:33:30 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:33:30 +0800
Subject: [PATCH 3/4] soc: imx: Add generic blk-ctl driver
In-Reply-To: <20210429073331.21204-1-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073331.21204-4-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

The i.MX8MM introduces an IP named BLK_CTL and usually is comprised of
some GPRs.

The GPRs has some clock bits and reset bits, but here we take it
as virtual PDs, because of the clock and power domain A/B lock issue
when taking it as a clock controller.

For some bits, it might be good to also make it as a reset controller,
but to i.MX8MM, we not add that support for now.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/Makefile  |   2 +-
 drivers/soc/imx/blk-ctl.c | 303 ++++++++++++++++++++++++++++++++++++++
 drivers/soc/imx/blk-ctl.h |  76 ++++++++++
 3 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/imx/blk-ctl.c
 create mode 100644 drivers/soc/imx/blk-ctl.h

diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 078dc918f4f3..d3d2b49a386c 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o
 endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
-obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o
+obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o
diff --git a/drivers/soc/imx/blk-ctl.c b/drivers/soc/imx/blk-ctl.c
new file mode 100644
index 000000000000..1f764dfd308d
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021 NXP.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/pm_domain.h>
+#include <linux/reset-controller.h>
+
+#include "blk-ctl.h"
+
+static inline struct imx_blk_ctl_domain *to_imx_blk_ctl_pd(struct generic_pm_domain *genpd)
+{
+	return container_of(genpd, struct imx_blk_ctl_domain, pd);
+}
+
+static int imx_blk_ctl_enable_hsk(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_hw *hw = &blk_ctl->dev_data->hw_hsk;
+	struct regmap *regmap = blk_ctl->regmap;
+	int ret;
+
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, hw->rst_mask);
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
+
+	/* Wait for handshake */
+	udelay(5);
+
+	return ret;
+}
+
+int imx_blk_ctl_power_off(struct generic_pm_domain *domain)
+{
+	struct imx_blk_ctl_domain *pd;
+	struct imx_blk_ctl *blk_ctl;
+	const struct imx_blk_ctl_hw *hw;
+	struct regmap *regmap;
+	int ret;
+
+	pd = to_imx_blk_ctl_pd(domain);
+	blk_ctl = pd->blk_ctl;
+	regmap = blk_ctl->regmap;
+	hw = &blk_ctl->dev_data->pds[pd->id];
+
+	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
+	if (ret)
+		return ret;
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, 0);
+	if (ret)
+		goto hsk_fail;
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, 0);
+
+	if (atomic_dec_and_test(&blk_ctl->power_count)) {
+		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);
+		if (ret) {
+			dev_err(blk_ctl->dev, "Hankshake fail\n");
+			goto hsk_fail;
+		}
+	}
+
+hsk_fail:
+	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
+
+	return ret;
+}
+
+int imx_blk_ctl_power_on(struct generic_pm_domain *domain)
+{
+	struct imx_blk_ctl_domain *pd;
+	struct regmap *regmap;
+	const struct imx_blk_ctl_hw *hw;
+	int ret;
+	struct imx_blk_ctl *blk_ctl;
+
+	pd = to_imx_blk_ctl_pd(domain);
+	blk_ctl = pd->blk_ctl;
+	regmap = blk_ctl->regmap;
+	hw = &blk_ctl->dev_data->pds[pd->id];
+
+	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
+	if (ret)
+		return ret;
+
+	if ((atomic_read(&blk_ctl->power_count) == 0)) {
+		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);
+		if (ret) {
+			dev_err(blk_ctl->dev, "Hankshake fail\n");
+			goto disable_clk;
+		}
+	}
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, 0);
+
+	/* Wait for reset propagate */
+	udelay(5);
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, hw->rst_mask);
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
+	if (ret)
+		goto disable_clk;
+
+	atomic_inc(&blk_ctl->power_count);
+
+disable_clk:
+	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
+
+	return ret;
+}
+
+static int imx_blk_ctl_attach_pd(struct device *dev, struct device **devs, char **pd_names,
+				 u32 num_pds)
+{
+	int i, ret;
+
+	if (!pd_names)
+		return 0;
+
+	if (dev->pm_domain) {
+		devs[0] = dev;
+		pm_runtime_enable(dev);
+		return 0;
+	}
+
+	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 detach_pm;
+		}
+	}
+
+	return 0;
+
+detach_pm:
+	for (i--; i >= 0; i--)
+		dev_pm_domain_detach(devs[i], false);
+
+	return ret;
+}
+
+static int imx_blk_ctl_register_pd(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	int num = dev_data->pds_num;
+	struct imx_blk_ctl_domain *domain;
+	int i, ret;
+
+	blk_ctl->onecell_data.num_domains = num;
+	blk_ctl->onecell_data.domains = devm_kcalloc(dev, num,
+						     sizeof(struct generic_pm_domain *),
+						     GFP_KERNEL);
+
+	if (!blk_ctl->onecell_data.domains)
+		return -ENOMEM;
+
+	for (i = 0; i < num; i++) {
+		domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
+		if (!domain) {
+			ret = -ENOMEM;
+			goto remove_genpd;
+		}
+		domain->pd.name = dev_data->pds[i].name;
+		domain->pd.power_off = imx_blk_ctl_power_off;
+		domain->pd.power_on = imx_blk_ctl_power_on;
+		domain->blk_ctl = blk_ctl;
+		domain->id = i;
+
+		ret = pm_genpd_init(&domain->pd, NULL, true);
+		if (ret)
+			return ret;
+
+		blk_ctl->onecell_data.domains[i] = &domain->pd;
+	}
+
+	return 0;
+
+remove_genpd:
+	for (i = i - 1; i >= 0; i--)
+		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
+
+	return ret;
+}
+
+static int imx_blk_ctl_hook_pd(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	const struct imx_blk_ctl_hw *pds = dev_data->pds;
+	int num_active_pd = dev_data->num_active_pd;
+	int num = dev_data->pds_num;
+	struct generic_pm_domain *genpd, *child_genpd;
+	int ret;
+	int i, j;
+
+	blk_ctl->active_pds = devm_kcalloc(dev, num_active_pd, sizeof(struct device *), GFP_KERNEL);
+	if (!blk_ctl->active_pds)
+		return -ENOMEM;
+
+	ret = imx_blk_ctl_attach_pd(dev, blk_ctl->active_pds, dev_data->active_pd_names,
+				    num_active_pd);
+	if (ret) {
+		if (ret == -EPROBE_DEFER)
+			return ret;
+		dev_err(dev, "Failed to attach active pd: %d\n", ret);
+		return ret;
+	}
+
+	for (i = 0; i < num; i++) {
+		for (j = 0; j < num_active_pd; j++) {
+			genpd = pd_to_genpd(blk_ctl->active_pds[j]->pm_domain);
+			if (!strcmp(genpd->name, pds[i].parent_name))
+				break;
+		}
+
+		child_genpd = blk_ctl->onecell_data.domains[i];
+		if (pm_genpd_add_subdomain(genpd, child_genpd))
+			pr_warn("failed to add subdomain:\n");
+	}
+
+	return 0;
+}
+
+int imx_blk_ctl_register(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	int num = dev_data->pds_num;
+	int i, ret;
+
+	if (!blk_ctl)
+		return -ENODEV;
+
+	ret = imx_blk_ctl_register_pd(dev);
+	if (ret)
+		return ret;
+
+	ret = imx_blk_ctl_hook_pd(dev);
+	if (ret)
+		goto unregister_pd;
+
+	ret = of_genpd_add_provider_onecell(dev->of_node, &blk_ctl->onecell_data);
+	if (ret)
+		goto detach_pd;
+
+	pm_runtime_get_noresume(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	pm_runtime_put(dev);
+
+	return 0;
+
+detach_pd:
+	for (i = blk_ctl->dev_data->num_active_pd; i >= 0; i--)
+		dev_pm_domain_detach(blk_ctl->active_pds[i], false);
+unregister_pd:
+	for (i = num - 1; i >= 0; i--)
+		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(imx_blk_ctl_register);
+
+static int __maybe_unused imx_blk_ctl_runtime_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int __maybe_unused imx_blk_ctl_runtime_resume(struct device *dev)
+{
+	return 0;
+}
+
+const struct dev_pm_ops imx_blk_ctl_pm_ops = {
+	SET_RUNTIME_PM_OPS(imx_blk_ctl_runtime_suspend,
+			   imx_blk_ctl_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+			   pm_runtime_force_resume)
+};
+EXPORT_SYMBOL_GPL(imx_blk_ctl_pm_ops);
diff --git a/drivers/soc/imx/blk-ctl.h b/drivers/soc/imx/blk-ctl.h
new file mode 100644
index 000000000000..e736369406a1
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __SOC_IMX_BLK_CTL_H
+#define __SOC_IMX_BLK_CTL_H
+
+enum imx_blk_ctl_pd_type {
+	BLK_CTL_PD,
+};
+
+struct imx_blk_ctl_hw {
+	int type;
+	char *name;
+	char *parent_name;
+	u32 offset;
+	u32 mask;
+	u32 flags;
+	u32 id;
+	u32 rst_offset;
+	u32 rst_mask;
+};
+
+struct imx_blk_ctl_domain {
+	struct generic_pm_domain pd;
+	struct imx_blk_ctl *blk_ctl;
+	u32 id;
+};
+
+struct imx_blk_ctl_dev_data {
+	struct regmap_config config;
+	struct imx_blk_ctl_hw *pds;
+	struct imx_blk_ctl_hw hw_hsk;
+	u32 pds_num;
+	char **active_pd_names;
+	u32 num_active_pd;
+};
+
+struct imx_blk_ctl {
+	struct device *dev;
+	struct regmap *regmap;
+	struct device **active_pds;
+	u32 pds_num;
+	u32 active_pd_count;
+	struct genpd_onecell_data onecell_data;
+	const struct imx_blk_ctl_dev_data *dev_data;
+	struct clk_bulk_data *clks;
+	u32 num_clks;
+
+	atomic_t power_count;
+};
+
+#define IMX_BLK_CTL(_type, _name, _parent_name, _id, _offset, _mask, _rst_offset, _rst_mask,	\
+		    _flags)								\
+	{										\
+		.type = _type,								\
+		.name = _name,								\
+		.parent_name = _parent_name,						\
+		.id = _id,								\
+		.offset = _offset,							\
+		.mask = _mask,								\
+		.flags = _flags,							\
+		.rst_offset = _rst_offset,						\
+		.rst_mask = _rst_mask,							\
+	}
+
+#define IMX_BLK_CTL_PD(_name, _parent_name, _id, _offset, _mask, _rst_offset, _rst_mask, _flags) \
+	IMX_BLK_CTL(BLK_CTL_PD, _name, _parent_name, _id, _offset, _mask, _rst_offset,		\
+		    _rst_mask, _flags)
+
+int imx_blk_ctl_register(struct device *dev);
+
+#define IMX_BLK_CTL_PD_HANDSHAKE	BIT(0)
+#define IMX_BLK_CTL_PD_RESET		BIT(1)
+#define IMX_BLK_CTL_PD_BUS		BIT(2)
+
+const extern struct dev_pm_ops imx_blk_ctl_pm_ops;
+
+#endif
-- 
2.30.0



From peng.fan at oss.nxp.com  Thu Apr 29 08:33:31 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Thu, 29 Apr 2021 15:33:31 +0800
Subject: [PATCH 4/4] soc: imx: Add blk-ctl driver for i.MX8MM
In-Reply-To: <20210429073331.21204-1-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
Message-ID: <20210429073331.21204-5-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

The i.MX8MM SoC has dispmix BLK-CTL and vpumix BLK-CTL, so we add
that support in this driver.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/Makefile         |   2 +-
 drivers/soc/imx/blk-ctl-imx8mm.c | 138 +++++++++++++++++++++++++++++++
 2 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/imx/blk-ctl-imx8mm.c

diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index d3d2b49a386c..c260b962f495 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o
 endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
-obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o
+obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o blk-ctl-imx8mm.o
diff --git a/drivers/soc/imx/blk-ctl-imx8mm.c b/drivers/soc/imx/blk-ctl-imx8mm.c
new file mode 100644
index 000000000000..77e0a5d3fdac
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl-imx8mm.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021 NXP
+ */
+
+#include <dt-bindings/clock/imx8mm-clock.h>
+#include <dt-bindings/power/imx8mm-power.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/pm_domain.h>
+#include <linux/regmap.h>
+
+#include "blk-ctl.h"
+
+#define MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN			BIT(6)
+#define MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN			BIT(5)
+#define MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN			BIT(4)
+#define MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN			BIT(3)
+#define MEDIA_BLK_CSI_BRIDGE_SFT_EN				GENMASK(2, 0)
+
+#define MEDIA_BLK_BUS_PD_MASK					BIT(12)
+#define MEDIA_BLK_MIPI_CSI_PD_MASK				GENMASK(11, 10)
+#define MEDIA_BLK_MIPI_DSI_PD_MASK				GENMASK(9, 8)
+#define MEDIA_BLK_LCDIF_PD_MASK					GENMASK(7, 6)
+#define MEDIA_BLK_CSI_BRIDGE_PD_MASK				GENMASK(5, 0)
+
+static struct imx_blk_ctl_hw imx8mm_dispmix_blk_ctl_pds[] = {
+	IMX_BLK_CTL_PD("CSI_BRIDGE", "dispmix", IMX8MM_BLK_CTL_DISPMIX_CSI_BRIDGE, 0x4,
+		       MEDIA_BLK_CSI_BRIDGE_PD_MASK, 0, MEDIA_BLK_CSI_BRIDGE_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("LCDIF", "dispmix", IMX8MM_BLK_CTL_DISPMIX_LCDIF, 0x4,
+		       MEDIA_BLK_LCDIF_PD_MASK, -1, -1, 0),
+	IMX_BLK_CTL_PD("MIPI_DSI", "mipi", IMX8MM_BLK_CTL_DISPMIX_MIPI_DSI, 0x4,
+		       MEDIA_BLK_MIPI_DSI_PD_MASK, 0, MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("MIPI_CSI", "mipi", IMX8MM_BLK_CTL_DISPMIX_MIPI_CSI, 0x4,
+		       MEDIA_BLK_MIPI_CSI_PD_MASK, 0,
+		       MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN | MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET)
+};
+
+static struct imx_blk_ctl_hw imx8mm_vpumix_blk_ctl_pds[] = {
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_G2", "vpu-g2", IMX8MM_BLK_CTL_G2_PD, 0x4,
+		       BIT(0), 0, BIT(0), IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_G1", "vpu-g1", IMX8MM_BLK_CTL_G1_PD, 0x4,
+		       BIT(1), 0, BIT(1), IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_H1", "vpu-h1", IMX8MM_BLK_CTL_H1_PD, 0x4,
+		       BIT(2), 0, BIT(2), IMX_BLK_CTL_PD_HANDSHAKE | IMX_BLK_CTL_PD_RESET),
+};
+
+static const struct regmap_config imx8mm_blk_ctl_regmap_config = {
+	.reg_bits		= 32,
+	.reg_stride		= 4,
+	.val_bits		= 32,
+	.max_register		= 0x30,
+	.fast_io		= true,
+};
+
+static const struct imx_blk_ctl_dev_data imx8mm_vpumix_blk_ctl_dev_data = {
+	.pds = imx8mm_vpumix_blk_ctl_pds,
+	.pds_num = ARRAY_SIZE(imx8mm_vpumix_blk_ctl_pds),
+	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, IMX8MM_BLK_CTL_H1_PD, 0x4, BIT(2), 0, BIT(2),
+				 IMX_BLK_CTL_PD_HANDSHAKE),
+	.config = imx8mm_blk_ctl_regmap_config,
+	.active_pd_names = (char*[]){"vpumix", "g1", "g2", "h1"},
+	.num_active_pd = 4,
+};
+
+static const struct imx_blk_ctl_dev_data imx8mm_dispmix_blk_ctl_dev_data = {
+	.pds = imx8mm_dispmix_blk_ctl_pds,
+	.pds_num = ARRAY_SIZE(imx8mm_dispmix_blk_ctl_pds),
+	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, -1, 0x4, MEDIA_BLK_BUS_PD_MASK, 0,
+				 MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN,
+				 IMX_BLK_CTL_PD_HANDSHAKE | IMX_BLK_CTL_PD_RESET),
+	.config = imx8mm_blk_ctl_regmap_config,
+	.active_pd_names = (char*[]){"dispmix", "mipi"},
+	.num_active_pd = 2,
+};
+
+static int imx8mm_blk_ctl_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct imx_blk_ctl_dev_data *dev_data = of_device_get_match_data(dev);
+	struct regmap *regmap;
+	struct resource *res;
+	struct imx_blk_ctl *ctl;
+	void __iomem *base;
+
+	ctl = devm_kzalloc(dev, sizeof(*ctl), GFP_KERNEL);
+	if (!ctl)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	regmap = devm_regmap_init_mmio(dev, base, &dev_data->config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	ctl->regmap = regmap;
+	ctl->dev = dev;
+	atomic_set(&ctl->power_count, 0);
+
+	ctl->num_clks = devm_clk_bulk_get_all(dev, &ctl->clks);
+	if (ctl->num_clks < 0)
+		return ctl->num_clks;
+
+	dev_set_drvdata(dev, ctl);
+	ctl->dev_data = of_device_get_match_data(dev);
+
+	return imx_blk_ctl_register(dev);
+}
+
+static const struct of_device_id imx_blk_ctl_of_match[] = {
+	{ .compatible = "fsl,imx8mm-vpumix-blk-ctl", .data = &imx8mm_vpumix_blk_ctl_dev_data },
+	{ .compatible = "fsl,imx8mm-dispmix-blk-ctl", .data = &imx8mm_dispmix_blk_ctl_dev_data },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_blk_ctl_of_match);
+
+static struct platform_driver imx_blk_ctl_driver = {
+	.probe = imx8mm_blk_ctl_probe,
+	.driver = {
+		.name = "imx8mm-blk-ctl",
+		.of_match_table = of_match_ptr(imx_blk_ctl_of_match),
+		.pm = &imx_blk_ctl_pm_ops,
+	},
+};
+module_platform_driver(imx_blk_ctl_driver);
-- 
2.30.0



From m.felsch at pengutronix.de  Thu Apr 29 08:07:14 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Thu, 29 Apr 2021 09:07:14 +0200
Subject: [PATCH 2/6] media: v4l: Add definition for bayered IR formats
In-Reply-To: <YIoPwYQel0J4qmPs@pendragon.ideasonboard.com>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-3-m.felsch@pengutronix.de>
 <YIoPwYQel0J4qmPs@pendragon.ideasonboard.com>
Message-ID: <20210429070714.d3gy6qkawdiyj2wq@pengutronix.de>

Hi Laurent,

On 21-04-29 04:45, Laurent Pinchart wrote:
> Hi Marco,
> 
> Thank you for the patch.
> 
> On Tue, Apr 27, 2021 at 02:06:57PM +0200, Marco Felsch wrote:
> > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > with the interleaved IR pixels looks like:
> > 
> >         |  G |  R |  G |  B | ...
> >         +----+----+----+----+---
> >         | IR |  G | IR |  G | ...
> >         +----+----+----+----+---
> >         |  G |  B |  G |  R | ...
> >         +----+----+----+----+---
> >         | IR |  G | IR |  G | ...
> >         +----+----+----+----+---
> >         | .. | .. | .. | .. | ..
> > 
> > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> > 
> > Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
> > Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> > ---
> >  include/uapi/linux/videodev2.h | 4 ++++
> 
> The documentation is missing.

I've send a seperate patch for this. Those two could be squashed.

Regards,
  Marco


From narmstrong at baylibre.com  Thu Apr 29 08:09:17 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 09:09:17 +0200
Subject: [PATCH] arm64: dts: meson-gxbb: nanopi-k2: Enable Bluetooth
In-Reply-To: <20210429060830.6266-1-wens@kernel.org>
References: <20210429060830.6266-1-wens@kernel.org>
Message-ID: <509d541c-a91a-a1f0-e37f-b239f1d3219b@baylibre.com>

On 29/04/2021 08:08, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <wens at csie.org>
> 
> The NanoPi K2 has a AP6212 WiFi+BT combo module. The WiFi portion is
> already enabled. The BT part is connected via UART and I2S.
> 
> Enable the UART and add a device node describing the Bluetooth portion
> of the module.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> index 7273eed5292c..10f48fb1af61 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> @@ -385,9 +385,19 @@ &uart_AO {
>  
>  /* Bluetooth on AP6212 */
>  &uart_A {
> -	status = "disabled";
> +	status = "okay";
>  	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
>  	pinctrl-names = "default";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		clocks = <&wifi_32k>;
> +		clock-names = "lpo";
> +		vbat-supply = <&vddio_ao3v3>;
> +		vddio-supply = <&vddio_ao18>;
> +		host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>;
> +		shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>;
> +	};
>  };
>  
>  /* 40-pin CON1 */
> 

Thanks !

Reviewed-by: Neil Armstrong <narmstrong at baylibre.com>


From m.felsch at pengutronix.de  Thu Apr 29 08:09:40 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Thu, 29 Apr 2021 09:09:40 +0200
Subject: [PATCH] ARM: dts: imx6ul: Switch to fsl-asoc-card sound card
In-Reply-To: <1619664739-12589-1-git-send-email-shengjiu.wang@nxp.com>
References: <1619664739-12589-1-git-send-email-shengjiu.wang@nxp.com>
Message-ID: <20210429070940.6hech7hezrpiyzzp@pengutronix.de>

Hi,

thanks for the patch.

On 21-04-29 10:52, Shengjiu Wang wrote:
> There is issue with simple sound card, the simple sound
> card can't configure the pll of codec.

Hm, than we should fix this rather than moving to the 'old'
'fsl,imx-audio-wm8960'. But that only my opinion.

Regards,
  Marco


From rocco.yue at mediatek.com  Thu Apr 29 08:02:36 2021
From: rocco.yue at mediatek.com (Rocco Yue)
Date: Thu, 29 Apr 2021 15:02:36 +0800
Subject: [PATCH] rtnetlink: add rtnl_lock debug log
Message-ID: <20210429070237.3012-1-rocco.yue@mediatek.com>

We often encounter system hangs caused by certain processes
holding rtnl_lock for a long time. Even if there is a lock
detection mechanism in Linux, it is a bit troublesome and
affects the system performance. We hope to add a lightweight
debugging mechanism for detecting rtnl_lock.

Up to now, we have discovered and solved some potential bugs
through such debug information of this lightweight rtnl_lock,
which is helpful for us.

When you say Y for RTNL_LOCK_DEBUG, then the kernel will detect
if any function hold rtnl_lock too long and some key information
will be printed to help identify the issue point.

i.e: from the following logs, we can clear know that the pid=5546
RfxSender_4 process hold rtnl_lock for a long time, causing the
system hang. And we can also speculate that the delay operation
may be performed in devinet_ioctl(), resulting in rtnl_lock was
not released in time.

<6>[  141.151364] ----------- rtnl_print_btrace start -----------
<6>[  141.152079] RfxSender_4[5546][R] hold rtnl_lock more than 2 sec,
start time: 139129481562
<4>[  141.153114]  rtnl_lock+0x88/0xfc
<4>[  141.153523]  devinet_ioctl+0x190/0x1268
<4>[  141.154007]  inet_ioctl+0x108/0x1f4
<4>[  141.154449]  sock_do_ioctl+0x88/0x200
<4>[  141.154911]  sock_ioctl+0x4b0/0x884
<4>[  141.155367]  do_vfs_ioctl+0x6b0/0xcc4
<4>[  141.155830]  __arm64_sys_ioctl+0xc0/0xec
<4>[  141.156326]  el0_svc_common+0x130/0x2c0
<4>[  141.156810]  el0_svc_handler+0xd0/0xe0
<4>[  141.157283]  el0_svc+0x8/0xc
<4>[  141.157646] Call trace:
<4>[  141.157956]  dump_backtrace+0x0/0x240
<4>[  141.158418]  show_stack+0x18/0x24
<4>[  141.158836]  rtnl_print_btrace+0x138/0x1cc
<4>[  141.159362]  call_timer_fn+0x120/0x47c
<4>[  141.159834]  expire_timers+0x28c/0x420
<4>[  141.160306]  __run_timers+0x3d0/0x494
<4>[  141.160768]  run_timer_softirq+0x24/0x48
<4>[  141.161262]  __do_softirq+0x26c/0x968
<4>[  141.161725]  irq_exit+0x1f8/0x2b4
<4>[  141.162145]  __handle_domain_irq+0xdc/0x15c
<4>[  141.162672]  gic_handle_irq+0xe4/0x188
<4>[  141.163144]  el1_irq+0x104/0x200
<4>[  141.163559]  __const_udelay+0x118/0x1b0
<4>[  141.164044]  devinet_ioctl+0x1a0/0x1268
<4>[  141.164527]  inet_ioctl+0x108/0x1f4
<4>[  141.164968]  sock_do_ioctl+0x88/0x200
<4>[  141.165428]  sock_ioctl+0x4b0/0x884
<4>[  141.165868]  do_vfs_ioctl+0x6b0/0xcc4
<4>[  141.166330]  __arm64_sys_ioctl+0xc0/0xec
<4>[  141.166825]  el0_svc_common+0x130/0x2c0
<4>[  141.167308]  el0_svc_handler+0xd0/0xe0
<4>[  141.167786]  el0_svc+0x8/0xc
<6>[  141.168153] ------------ rtnl_print_btrace end -----------

<6>[  147.321389] rtnl_lock is held by [5546] from
[139129481562] to [147321378812]

Signed-off-by: Rocco Yue <rocco.yue at mediatek.com>
---
 lib/Kconfig.debug    |  9 +++++
 net/core/rtnetlink.c | 86 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2c7f46b366f1..d0d7457fa394 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2019,6 +2019,15 @@ config KCOV_IRQ_AREA_SIZE
 	  soft interrupts. This specifies the size of those areas in the
 	  number of unsigned long words.
 
+config RTNL_LOCK_DEBUG
+	bool "rtnl_lock debugging, deadlock detection"
+	select STACKTRACE
+	help
+	  If you say Y here then the kernel will detect whether any process
+	  hold rtnl_lock too long and some key information will be printed
+	  to help identify the issue point.
+	  If unsure, say N.
+
 menuconfig RUNTIME_TESTING_MENU
 	bool "Runtime Testing"
 	def_bool y
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 3485b16a7ff3..ddf374aec6af 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -57,6 +57,86 @@
 #define RTNL_MAX_TYPE		50
 #define RTNL_SLAVE_MAX_TYPE	40
 
+#ifdef CONFIG_RTNL_LOCK_DEBUG
+#include <linux/sched/debug.h>
+#include <linux/stacktrace.h>
+
+/* Debug log and btrace will be printed when the rtnl_lock
+ * is held for more than RTNL_LOCK_MAX_HOLD_TIME seconds
+ */
+#define RTNL_LOCK_MAX_HOLD_TIME 2
+
+#define RTNL_LOCK_MAX_TRACE     10    /* stack trace length */
+
+struct rtnl_debug_btrace_t {
+	struct task_struct *task;
+	int pid;
+	unsigned long long start_time;
+	unsigned long long end_time;
+	unsigned long   addrs[RTNL_LOCK_MAX_TRACE];
+	unsigned int    nr_entries;
+};
+
+static struct rtnl_debug_btrace_t rtnl_instance = {
+	.task		= NULL,
+	.pid		= 0,
+	.start_time	= 0,
+	.end_time	= 0,
+	.nr_entries	= 0,
+};
+
+static void rtnl_print_btrace(struct timer_list *unused);
+static DEFINE_TIMER(rtnl_chk_timer, rtnl_print_btrace);
+
+/* Save stack trace to the given array of RTNL_LOCK_MAX_TRACE size.
+ */
+static int __save_stack_trace(unsigned long *trace)
+{
+	return stack_trace_save(trace, RTNL_LOCK_MAX_TRACE, 0);
+}
+
+static void rtnl_get_btrace(struct task_struct *who)
+{
+	unsigned long expires;
+
+	rtnl_instance.task = who;
+	rtnl_instance.pid = who->pid;
+	rtnl_instance.start_time = sched_clock();
+	rtnl_instance.end_time = 0;
+	rtnl_instance.nr_entries = __save_stack_trace(rtnl_instance.addrs);
+
+	expires = jiffies + RTNL_LOCK_MAX_HOLD_TIME * HZ;
+	mod_timer(&rtnl_chk_timer, expires);
+}
+
+static void rtnl_print_btrace(struct timer_list *unused)
+{
+	pr_info("----------- %s start -----------\n", __func__);
+	pr_info("%s[%d][%c] hold rtnl_lock more than 2 sec, start time: %llu\n",
+		rtnl_instance.task->comm,
+		rtnl_instance.pid,
+		task_state_to_char(rtnl_instance.task),
+		rtnl_instance.start_time);
+	stack_trace_print(rtnl_instance.addrs, rtnl_instance.nr_entries, 0);
+	show_stack(rtnl_instance.task, NULL, KERN_DEBUG);
+	pr_info("------------ %s end -----------\n", __func__);
+}
+
+static void rtnl_relase_btrace(void)
+{
+	rtnl_instance.end_time = sched_clock();
+
+	if (rtnl_instance.end_time - rtnl_instance.start_time > 2000000000ULL) {
+		pr_info("rtnl_lock is held by [%d] from [%llu] to [%llu]\n",
+			rtnl_instance.pid,
+			rtnl_instance.start_time,
+			rtnl_instance.end_time);
+	}
+
+	del_timer(&rtnl_chk_timer);
+}
+#endif
+
 struct rtnl_link {
 	rtnl_doit_func		doit;
 	rtnl_dumpit_func	dumpit;
@@ -70,6 +150,9 @@ static DEFINE_MUTEX(rtnl_mutex);
 void rtnl_lock(void)
 {
 	mutex_lock(&rtnl_mutex);
+#ifdef CONFIG_RTNL_LOCK_DEBUG
+	rtnl_get_btrace(current);
+#endif
 }
 EXPORT_SYMBOL(rtnl_lock);
 
@@ -104,6 +187,9 @@ void __rtnl_unlock(void)
 		cond_resched();
 		head = next;
 	}
+#ifdef CONFIG_RTNL_LOCK_DEBUG
+	rtnl_relase_btrace();
+#endif
 }
 
 void rtnl_unlock(void)
-- 
2.18.0

From maz at kernel.org  Thu Apr 29 08:40:43 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 29 Apr 2021 08:40:43 +0100
Subject: [PATCH v3 09/10] arm64: dts: rockchip: add core dtsi for RK3568
 SoC
In-Reply-To: <3401442c-24a1-e8f8-fc4a-fa44d94b903b@rock-chips.com>
References: <20210428134759.22076-1-cl@rock-chips.com>
 <20210428135002.22528-1-cl@rock-chips.com>
 <87h7jqo3d2.wl-maz@kernel.org>
 <3401442c-24a1-e8f8-fc4a-fa44d94b903b@rock-chips.com>
Message-ID: <87eeeto7wk.wl-maz@kernel.org>

On Thu, 29 Apr 2021 02:13:35 +0100,
?? <cl at rock-chips.com> wrote:
> 
> Hi Marc,
> 
> ? 2021/4/28 ??11:06, Marc Zyngier ??:
> > On Wed, 28 Apr 2021 14:50:02 +0100,
> > <cl at rock-chips.com> wrote:
> >> From: Liang Chen <cl at rock-chips.com>
> >> 
> >> RK3568 is a high-performance and low power quad-core application processor
> >> designed for personal mobile internet device and AIoT equipment. This patch
> >> add basic core dtsi file for it.
> >> 
> >> We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
> >> kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
> >> enalbe a special high-performance PLL when high frequency is required. The
> >> smci_clk code is in ATF, and clkid for cpu is 0, as below:
> >> 
> >>      cpu0: cpu at 0 {
> >>          device_type = "cpu";
> >>          compatible = "arm,cortex-a55";
> >>          reg = <0x0 0x0>;
> >>          clocks = <&scmi_clk 0>;
> >>      };
> >> 
> >> Signed-off-by: Liang Chen <cl at rock-chips.com>
> >> ---
> >>   .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
> >>   arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  779 +++++
> >>   2 files changed, 3890 insertions(+)
> >>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
> >>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > [...]
> > 
> >> +	gic: interrupt-controller at fd400000 {
> >> +		compatible = "arm,gic-v3";
> >> +		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
> >> +		      <0x0 0xfd460000 0 0xc0000>; /* GICR */
> > If this SoC has 4 CPUs, that's 4 redistributors. Given that GIC600
> > doesn't implement VLPIs, that's 128kB per redistributors. Why is GICR
> > large enough for 6 CPUs here? Is that copy-pasted from another SoC?
> Copy from rk3399, sorry.
> >> +		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> >> +		interrupt-controller;
> >> +		#interrupt-cells = <3>;
> >> +		mbi-alias = <0x0 0xfd400000>;
> >> +		mbi-ranges = <296 24>;
> >> +		msi-controller;
> >> +	};
> > Glad to see that you found some spare SPIs to get MSIs going
> > 
> > However, the whole point of mbi-alias (aka GICA in GIC600) is to be
> > different from GICD and provide some isolation via an IOMMU.  If I
> > trust the TRM, if should be at 0xfd10000 in your implementation.
> 
> But in the ./devicetree/bindings/interrupt-controller/arm,gic-v3.yaml, say:
> 
> ? mbi-alias:
> ??? description:
> ????? Address property. Base address of an alias of the *GICD* region
> containing
> ????? only the {SET,CLR}SPI registers to be used if isolation is required,
> ????? and if supported by the HW.


[recurring theme: I happen to know about this section of the binding,
having written the original myself]

How does that contradict my comment? GIC600's GICA page only contains
the four {SET,CLR}_SPI registers, as expected (see section 4.3 in the
TRM[1]), and the address is computed using table 4-1 "Register map
pages" of the same document.

Please either fix the DT or explain why the GICA distributor alias
isn't usable.

	M.

[1] https://documentation-service.arm.com/static/5e7ddddacbfe76649ba53034

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


From tony at atomide.com  Thu Apr 29 08:45:33 2021
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 29 Apr 2021 10:45:33 +0300
Subject: [PATCH] bus: ti-sysc: Fix am335x resume hang for usb otg module
Message-ID: <20210429074533.33355-1-tony@atomide.com>

On am335x, suspend and resume only works once, and the system hangs if
suspend is attempted again. However, turns out suspend and resume works
fine multiple times if the USB OTG driver for musb controller is loaded.

The issue is caused my the interconnect target module losing context
during suspend, and it needs a restore on resume to be reconfigure again
as debugged earlier by Dave Gerlach <d-gerlach at ti.com>.

There are also other modules that need a restore on resume, like gpmc as
noted by Dave. So let's add a common way to restore an interconnect
target module based on a quirk flag. For now, let's enable the quirk for
am335x otg only to fix the suspend and resume issue.

As gpmc is not causing hangs based on tests with BeagleBone, let's patch
gpmc separately. For gpmc, we also need a hardware reset done before
restore according to Dave.

To reinit the modules, we decouple system suspend from PM runtime. We
replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume()
with direct calls to internal functions and rely on the driver internal
state. There no point trying to handle complex system suspend and resume
quirks via PM runtime.

This is issue should have already been noticed with commit 1819ef2e2d12
("bus: ti-sysc: Use swsup quirks also for am335x musb") when quirk
handling was added for am335x otg for swsup. But the issue went unnoticed
as having musb driver loaded hides the issue, and suspend and resume works
once without the driver loaded.

Fixes: 1819ef2e2d12 ("bus: ti-sysc: Use swsup quirks also for am335x musb")
Suggested-by: Dave Gerlach <d-gerlach at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 drivers/bus/ti-sysc.c                 | 29 ++++++++++++++++++++++++---
 include/linux/platform_data/ti-sysc.h |  1 +
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1295,12 +1295,18 @@ static int __maybe_unused sysc_noirq_suspend(struct device *dev)
 	    (SYSC_QUIRK_LEGACY_IDLE | SYSC_QUIRK_NO_IDLE))
 		return 0;
 
-	return pm_runtime_force_suspend(dev);
+	if (!ddata->enabled)
+		return 0;
+
+	ddata->needs_resume = 1;
+
+	return sysc_runtime_suspend(dev);
 }
 
 static int __maybe_unused sysc_noirq_resume(struct device *dev)
 {
 	struct sysc *ddata;
+	int error;
 
 	ddata = dev_get_drvdata(dev);
 
@@ -1308,7 +1314,23 @@ static int __maybe_unused sysc_noirq_resume(struct device *dev)
 	    (SYSC_QUIRK_LEGACY_IDLE | SYSC_QUIRK_NO_IDLE))
 		return 0;
 
-	return pm_runtime_force_resume(dev);
+	/* Only enable module if it was on, or needs to be reinitialized */
+	if (ddata->needs_resume ||
+	    ddata->cfg.quirks & SYSC_QUIRK_REINIT_ON_RESUME) {
+		error = sysc_runtime_resume(dev);
+		if (error)
+			dev_warn(dev, "noirq_resume failed: %i\n", error);
+	}
+
+	/* Idle quirky module again if it was not on before suspend */
+	if (ddata->cfg.quirks & SYSC_QUIRK_REINIT_ON_RESUME &&
+	    !ddata->needs_resume) {
+		error = sysc_runtime_suspend(dev);
+	}
+
+	ddata->needs_resume = 0;
+
+	return error;
 }
 
 static const struct dev_pm_ops sysc_pm_ops = {
@@ -1417,7 +1439,8 @@ static const struct sysc_revision_quirk sysc_revision_quirks[] = {
 	SYSC_QUIRK("usb_otg_hs", 0, 0x400, 0x404, 0x408, 0x00000050,
 		   0xffffffff, SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_SWSUP_MSTANDBY),
 	SYSC_QUIRK("usb_otg_hs", 0, 0, 0x10, -ENODEV, 0x4ea2080d, 0xffffffff,
-		   SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_SWSUP_MSTANDBY),
+		   SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_SWSUP_MSTANDBY |
+		   SYSC_QUIRK_REINIT_ON_RESUME),
 	SYSC_QUIRK("wdt", 0, 0, 0x10, 0x14, 0x502a0500, 0xfffff0f0,
 		   SYSC_MODULE_QUIRK_WDT),
 	/* PRUSS on am3, am4 and am5 */
diff --git a/include/linux/platform_data/ti-sysc.h b/include/linux/platform_data/ti-sysc.h
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -50,6 +50,7 @@ struct sysc_regbits {
 	s8 emufree_shift;
 };
 
+#define SYSC_QUIRK_REINIT_ON_RESUME	BIT(27)
 #define SYSC_QUIRK_GPMC_DEBUG		BIT(26)
 #define SYSC_MODULE_QUIRK_ENA_RESETDONE	BIT(25)
 #define SYSC_MODULE_QUIRK_PRUSS		BIT(24)
-- 
2.31.1


From ping.bai at nxp.com  Thu Apr 29 08:47:35 2021
From: ping.bai at nxp.com (Jacky Bai)
Date: Thu, 29 Apr 2021 07:47:35 +0000
Subject: [PATCH 3/4] soc: imx: Add generic blk-ctl driver
In-Reply-To: <20210429073331.21204-4-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
 <20210429073331.21204-4-peng.fan@oss.nxp.com>
Message-ID: <DBBPR04MB7930DAB66F97B8E60F9B470F875F9@DBBPR04MB7930.eurprd04.prod.outlook.com>

> Subject: [PATCH 3/4] soc: imx: Add generic blk-ctl driver
> 
> From: Peng Fan <peng.fan at nxp.com>
> 
> The i.MX8MM introduces an IP named BLK_CTL and usually is comprised of
> some GPRs.
> 
> The GPRs has some clock bits and reset bits, but here we take it as virtual PDs,
> because of the clock and power domain A/B lock issue when taking it as a
> clock controller.
> 
> For some bits, it might be good to also make it as a reset controller, but to
> i.MX8MM, we not add that support for now.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/soc/imx/Makefile  |   2 +-
>  drivers/soc/imx/blk-ctl.c | 303
> ++++++++++++++++++++++++++++++++++++++
>  drivers/soc/imx/blk-ctl.h |  76 ++++++++++
>  3 files changed, 380 insertions(+), 1 deletion(-)  create mode 100644
> drivers/soc/imx/blk-ctl.c  create mode 100644 drivers/soc/imx/blk-ctl.h
> 
...

> +
> +static inline struct imx_blk_ctl_domain *to_imx_blk_ctl_pd(struct
> +generic_pm_domain *genpd) {
> +	return container_of(genpd, struct imx_blk_ctl_domain, pd); }

Why not use macro define?

> +
> +static int imx_blk_ctl_enable_hsk(struct device *dev) {
> +	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
> +	const struct imx_blk_ctl_hw *hw = &blk_ctl->dev_data->hw_hsk;
> +	struct regmap *regmap = blk_ctl->regmap;
> +	int ret;
> +
> +

Redundant line.

> +	if (hw->flags & IMX_BLK_CTL_PD_RESET)
> +		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask,
> +hw->rst_mask);
> +
> +	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
> +
> +	/* Wait for handshake */
> +	udelay(5);
> +
> +	return ret;
> +}
> +
> +int imx_blk_ctl_power_off(struct generic_pm_domain *domain) {
> +	struct imx_blk_ctl_domain *pd;
> +	struct imx_blk_ctl *blk_ctl;
> +	const struct imx_blk_ctl_hw *hw;
> +	struct regmap *regmap;
> +	int ret;
> +
> +	pd = to_imx_blk_ctl_pd(domain);
> +	blk_ctl = pd->blk_ctl;
> +	regmap = blk_ctl->regmap;
> +	hw = &blk_ctl->dev_data->pds[pd->id];
> +
> +	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_update_bits(regmap, hw->offset, hw->mask, 0);
> +	if (ret)
> +		goto hsk_fail;
> +
> +	if (hw->flags & IMX_BLK_CTL_PD_RESET)
> +		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask,
> 0);
> +
> +	if (atomic_dec_and_test(&blk_ctl->power_count)) {
> +		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);

For the BUS clock EN and RST handling?

> +		if (ret) {
> +			dev_err(blk_ctl->dev, "Hankshake fail\n");
> +			goto hsk_fail;
> +		}
> +	}
> +
> +hsk_fail:
> +	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
> +
> +	return ret;
> +}
> +
> +int imx_blk_ctl_power_on(struct generic_pm_domain *domain) {
> +	struct imx_blk_ctl_domain *pd;
> +	struct regmap *regmap;
> +	const struct imx_blk_ctl_hw *hw;
> +	int ret;
> +	struct imx_blk_ctl *blk_ctl;
> +
> +	pd = to_imx_blk_ctl_pd(domain);
> +	blk_ctl = pd->blk_ctl;
> +	regmap = blk_ctl->regmap;
> +	hw = &blk_ctl->dev_data->pds[pd->id];
> +
> +	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
> +	if (ret)
> +		return ret;
> +
> +	if ((atomic_read(&blk_ctl->power_count) == 0)) {
> +		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);
> +		if (ret) {
> +			dev_err(blk_ctl->dev, "Hankshake fail\n");
> +			goto disable_clk;
> +		}
> +	}
> +
> +	if (hw->flags & IMX_BLK_CTL_PD_RESET)
> +		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask,
> 0);
> +
> +	/* Wait for reset propagate */
> +	udelay(5);
> +
> +	if (hw->flags & IMX_BLK_CTL_PD_RESET)
> +		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask,
> +hw->rst_mask);
> +
> +	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
> +	if (ret)
> +		goto disable_clk;
> +
> +	atomic_inc(&blk_ctl->power_count);
> +
> +disable_clk:
> +	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
> +
> +	return ret;
> +}
> +
> +static int imx_blk_ctl_attach_pd(struct device *dev, struct device **devs,
> char **pd_names,
> +				 u32 num_pds)
> +{
> +	int i, ret;
> +
> +	if (!pd_names)
> +		return 0;

Return success?

BR
Jacky Bai
> +
> +	if (dev->pm_domain) {
> +		devs[0] = dev;
> +		pm_runtime_enable(dev);
> +		return 0;
> +	}
> +
> +	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 detach_pm;
> +		}
> +	}
> +
> +	return 0;
> +
> +detach_pm:
> +	for (i--; i >= 0; i--)
> +		dev_pm_domain_detach(devs[i], false);
> +
> +	return ret;
> +}
> +
> +static int imx_blk_ctl_register_pd(struct device *dev) {
> +	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
> +	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
> +	int num = dev_data->pds_num;
> +	struct imx_blk_ctl_domain *domain;
> +	int i, ret;
> +
> +	blk_ctl->onecell_data.num_domains = num;
> +	blk_ctl->onecell_data.domains = devm_kcalloc(dev, num,
> +						     sizeof(struct generic_pm_domain *),
> +						     GFP_KERNEL);
> +
> +	if (!blk_ctl->onecell_data.domains)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num; i++) {
> +		domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
> +		if (!domain) {
> +			ret = -ENOMEM;
> +			goto remove_genpd;
> +		}
> +		domain->pd.name = dev_data->pds[i].name;
> +		domain->pd.power_off = imx_blk_ctl_power_off;
> +		domain->pd.power_on = imx_blk_ctl_power_on;
> +		domain->blk_ctl = blk_ctl;
> +		domain->id = i;
> +
> +		ret = pm_genpd_init(&domain->pd, NULL, true);
> +		if (ret)
> +			return ret;
> +
> +		blk_ctl->onecell_data.domains[i] = &domain->pd;
> +	}
> +
> +	return 0;
> +
> +remove_genpd:
> +	for (i = i - 1; i >= 0; i--)
> +		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
> +
> +	return ret;
> +}
> +
> +static int imx_blk_ctl_hook_pd(struct device *dev) {
> +	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
> +	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
> +	const struct imx_blk_ctl_hw *pds = dev_data->pds;
> +	int num_active_pd = dev_data->num_active_pd;
> +	int num = dev_data->pds_num;
> +	struct generic_pm_domain *genpd, *child_genpd;
> +	int ret;
> +	int i, j;
> +
> +	blk_ctl->active_pds = devm_kcalloc(dev, num_active_pd, sizeof(struct
> device *), GFP_KERNEL);
> +	if (!blk_ctl->active_pds)
> +		return -ENOMEM;
> +
> +	ret = imx_blk_ctl_attach_pd(dev, blk_ctl->active_pds,
> dev_data->active_pd_names,
> +				    num_active_pd);
> +	if (ret) {
> +		if (ret == -EPROBE_DEFER)
> +			return ret;
> +		dev_err(dev, "Failed to attach active pd: %d\n", ret);
> +		return ret;
> +	}
> +
> +	for (i = 0; i < num; i++) {
> +		for (j = 0; j < num_active_pd; j++) {
> +			genpd = pd_to_genpd(blk_ctl->active_pds[j]->pm_domain);
> +			if (!strcmp(genpd->name, pds[i].parent_name))
> +				break;
> +		}
> +
> +		child_genpd = blk_ctl->onecell_data.domains[i];
> +		if (pm_genpd_add_subdomain(genpd, child_genpd))
> +			pr_warn("failed to add subdomain:\n");
> +	}
> +
> +	return 0;
> +}
> +
> +int imx_blk_ctl_register(struct device *dev) {
> +	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
> +	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
> +	int num = dev_data->pds_num;
> +	int i, ret;
> +
> +	if (!blk_ctl)
> +		return -ENODEV;
> +
> +	ret = imx_blk_ctl_register_pd(dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = imx_blk_ctl_hook_pd(dev);
> +	if (ret)
> +		goto unregister_pd;
> +
> +	ret = of_genpd_add_provider_onecell(dev->of_node,
> &blk_ctl->onecell_data);
> +	if (ret)
> +		goto detach_pd;
> +
> +	pm_runtime_get_noresume(dev);
> +	pm_runtime_set_active(dev);
> +	pm_runtime_enable(dev);
> +
> +	pm_runtime_put(dev);
> +
> +	return 0;
> +
> +detach_pd:
> +	for (i = blk_ctl->dev_data->num_active_pd; i >= 0; i--)
> +		dev_pm_domain_detach(blk_ctl->active_pds[i], false);
> +unregister_pd:
> +	for (i = num - 1; i >= 0; i--)
> +		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(imx_blk_ctl_register);
> +
> +static int __maybe_unused imx_blk_ctl_runtime_suspend(struct device
> +*dev) {
> +	return 0;
> +}
> +
> +static int __maybe_unused imx_blk_ctl_runtime_resume(struct device
> +*dev) {
> +	return 0;
> +}
> +
> +const struct dev_pm_ops imx_blk_ctl_pm_ops = {
> +	SET_RUNTIME_PM_OPS(imx_blk_ctl_runtime_suspend,
> +			   imx_blk_ctl_runtime_resume, NULL)
> +	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +			   pm_runtime_force_resume)
> +};
> +EXPORT_SYMBOL_GPL(imx_blk_ctl_pm_ops);
> diff --git a/drivers/soc/imx/blk-ctl.h b/drivers/soc/imx/blk-ctl.h new file mode
> 100644 index 000000000000..e736369406a1
> --- /dev/null
> +++ b/drivers/soc/imx/blk-ctl.h
> @@ -0,0 +1,76 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __SOC_IMX_BLK_CTL_H
> +#define __SOC_IMX_BLK_CTL_H
> +
> +enum imx_blk_ctl_pd_type {
> +	BLK_CTL_PD,
> +};
> +
> +struct imx_blk_ctl_hw {
> +	int type;
> +	char *name;
> +	char *parent_name;
> +	u32 offset;
> +	u32 mask;
> +	u32 flags;
> +	u32 id;
> +	u32 rst_offset;
> +	u32 rst_mask;
> +};
> +
> +struct imx_blk_ctl_domain {
> +	struct generic_pm_domain pd;
> +	struct imx_blk_ctl *blk_ctl;
> +	u32 id;
> +};
> +
> +struct imx_blk_ctl_dev_data {
> +	struct regmap_config config;
> +	struct imx_blk_ctl_hw *pds;
> +	struct imx_blk_ctl_hw hw_hsk;
> +	u32 pds_num;
> +	char **active_pd_names;
> +	u32 num_active_pd;
> +};
> +
> +struct imx_blk_ctl {
> +	struct device *dev;
> +	struct regmap *regmap;
> +	struct device **active_pds;
> +	u32 pds_num;
> +	u32 active_pd_count;
> +	struct genpd_onecell_data onecell_data;
> +	const struct imx_blk_ctl_dev_data *dev_data;
> +	struct clk_bulk_data *clks;
> +	u32 num_clks;
> +
> +	atomic_t power_count;
> +};
> +
> +#define IMX_BLK_CTL(_type, _name, _parent_name, _id, _offset, _mask,
> _rst_offset, _rst_mask,	\
> +		    _flags)								\
> +	{										\
> +		.type = _type,								\
> +		.name = _name,								\
> +		.parent_name = _parent_name,						\
> +		.id = _id,								\
> +		.offset = _offset,							\
> +		.mask = _mask,								\
> +		.flags = _flags,							\
> +		.rst_offset = _rst_offset,						\
> +		.rst_mask = _rst_mask,							\
> +	}
> +
> +#define IMX_BLK_CTL_PD(_name, _parent_name, _id, _offset, _mask,
> _rst_offset, _rst_mask, _flags) \
> +	IMX_BLK_CTL(BLK_CTL_PD, _name, _parent_name, _id, _offset, _mask,
> _rst_offset,		\
> +		    _rst_mask, _flags)
> +
> +int imx_blk_ctl_register(struct device *dev);
> +
> +#define IMX_BLK_CTL_PD_HANDSHAKE	BIT(0)
> +#define IMX_BLK_CTL_PD_RESET		BIT(1)
> +#define IMX_BLK_CTL_PD_BUS		BIT(2)
> +
> +const extern struct dev_pm_ops imx_blk_ctl_pm_ops;
> +
> +#endif
> --
> 2.30.0


From m.felsch at pengutronix.de  Thu Apr 29 08:49:03 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Thu, 29 Apr 2021 09:49:03 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
Message-ID: <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>

Hi Laurent,

On 21-04-29 04:51, Laurent Pinchart wrote:
> Hi Marco,
> 
> Thank you for the patch.
> 
> On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:
> > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > with the interleaved IR pixels looks like:
> > 
> >         |  G |  R |  G |  B | ...
> >         +----+----+----+----+---
> >         | IR |  G | IR |  G | ...
> >         +----+----+----+----+---
> >         |  G |  B |  G |  R | ...
> >         +----+----+----+----+---
> >         | IR |  G | IR |  G | ...
> >         +----+----+----+----+---
> >         | .. | .. | .. | .. | ..
> > 
> > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> 
> I think we're reaching a limit of the media bus codes model here, due to
> a historical mistake. The four possible Bayer patterns, times the
> different number of bits per pixel, creates a lot of media bus codes,
> and drivers for CSI-2 receivers and IP cores further down the pipeline
> have to support them all.

That's correct but it is not bayer related. Currently it is what it is,
if a new code is added it must be propagated through all the involved
subdevs. On the other hand I wouldn't say that it is better to support
new codes per default for all drivers. Since this would add a lot of
untested code paths.

> This is already painful, and if we had a
> non-Bayer pattern such as this one,

That's not exactly true since it is a bayer pattern but instead of using
4x4 it uses 8x8 and it as some special pixels.

> we'll open the door to an explosion
> of the number of media bus codes (imagine all the different possible
> arrangements of this pattern, for instance if you enable horizontal
> and/or vertical flipping on the sensor). All drivers would need to be
> updated to support these new bus codes, and this really kills the
> current model.

Yep, I know what you mean but as I said above I think that adding it
explicite is the better abbroach since it involves somone who add _and_
test the new code on the particular platform.

> The historical mistake was to tie the Bayer pattern with the media bus
> code. We should really have specified raw 8/10/12/14/16 media bus codes,
> and conveyed the pattern separately. Most IP cores in the pipeline don't
> need to care about the pattern at all, and those who do (that's mostly
> ISPs) could be programmed explicitly by userspace as long as we have an
> API to retrieve the pattern from the sensor. I believe it's time to bite
> the bullet and go in that direction. I'm sorry for this case of yak
> shaving, but it really wouldn't be manageable anymore :-(

I got all your points and would agree but this is not a bayer only
related problem. You will have this problem with all new other formats
as well. I'm with you, most IP cores don't care but I wouldn't
guarantee that.

Regards,
  Marco


From ping.bai at nxp.com  Thu Apr 29 08:50:58 2021
From: ping.bai at nxp.com (Jacky Bai)
Date: Thu, 29 Apr 2021 07:50:58 +0000
Subject: [PATCH 4/4] soc: imx: Add blk-ctl driver for i.MX8MM
In-Reply-To: <20210429073331.21204-5-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
 <20210429073331.21204-5-peng.fan@oss.nxp.com>
Message-ID: <DBBPR04MB79307BD98AABBA70F75BEA06875F9@DBBPR04MB7930.eurprd04.prod.outlook.com>

> Subject: [PATCH 4/4] soc: imx: Add blk-ctl driver for i.MX8MM
> 
> From: Peng Fan <peng.fan at nxp.com>
> 
> The i.MX8MM SoC has dispmix BLK-CTL and vpumix BLK-CTL, so we add that
> support in this driver.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/soc/imx/Makefile         |   2 +-
>  drivers/soc/imx/blk-ctl-imx8mm.c | 138
> +++++++++++++++++++++++++++++++
>  2 files changed, 139 insertions(+), 1 deletion(-)  create mode 100644
> drivers/soc/imx/blk-ctl-imx8mm.c
> 
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile index
> d3d2b49a386c..c260b962f495 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -4,4 +4,4 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o  endif
>  obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
>  obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
> -obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o
> +obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o blk-ctl-imx8mm.o
> diff --git a/drivers/soc/imx/blk-ctl-imx8mm.c
> b/drivers/soc/imx/blk-ctl-imx8mm.c
> new file mode 100644
> index 000000000000..77e0a5d3fdac
> --- /dev/null
> +++ b/drivers/soc/imx/blk-ctl-imx8mm.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2021 NXP
> + */
> +
> +#include <dt-bindings/clock/imx8mm-clock.h>
> +#include <dt-bindings/power/imx8mm-power.h>
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/pm_domain.h>
> +#include <linux/regmap.h>
> +
> +#include "blk-ctl.h"
> +
> +#define MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN			BIT(6)
> +#define MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN			BIT(5)
> +#define MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN			BIT(4)
> +#define MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN			BIT(3)
> +#define MEDIA_BLK_CSI_BRIDGE_SFT_EN				GENMASK(2,
> 0)
> +
> +#define MEDIA_BLK_BUS_PD_MASK					BIT(12)
> +#define MEDIA_BLK_MIPI_CSI_PD_MASK				GENMASK(11, 10)
> +#define MEDIA_BLK_MIPI_DSI_PD_MASK				GENMASK(9, 8)
> +#define MEDIA_BLK_LCDIF_PD_MASK					GENMASK(7,
> 6)
> +#define MEDIA_BLK_CSI_BRIDGE_PD_MASK				GENMASK(5,
> 0)
> +
> +static struct imx_blk_ctl_hw imx8mm_dispmix_blk_ctl_pds[] = {
> +	IMX_BLK_CTL_PD("CSI_BRIDGE", "dispmix",
> IMX8MM_BLK_CTL_DISPMIX_CSI_BRIDGE, 0x4,
> +		       MEDIA_BLK_CSI_BRIDGE_PD_MASK, 0,
> MEDIA_BLK_CSI_BRIDGE_SFT_EN,
> +		       IMX_BLK_CTL_PD_RESET),
> +	IMX_BLK_CTL_PD("LCDIF", "dispmix",
> IMX8MM_BLK_CTL_DISPMIX_LCDIF, 0x4,
> +		       MEDIA_BLK_LCDIF_PD_MASK, -1, -1, 0),
> +	IMX_BLK_CTL_PD("MIPI_DSI", "mipi",
> IMX8MM_BLK_CTL_DISPMIX_MIPI_DSI, 0x4,
> +		       MEDIA_BLK_MIPI_DSI_PD_MASK, 0,
> MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN,
> +		       IMX_BLK_CTL_PD_RESET),
> +	IMX_BLK_CTL_PD("MIPI_CSI", "mipi",
> IMX8MM_BLK_CTL_DISPMIX_MIPI_CSI, 0x4,
> +		       MEDIA_BLK_MIPI_CSI_PD_MASK, 0,
> +		       MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN |
> MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN,
> +		       IMX_BLK_CTL_PD_RESET)
> +};
> +
> +static struct imx_blk_ctl_hw imx8mm_vpumix_blk_ctl_pds[] = {
> +	IMX_BLK_CTL_PD("VPU_BLK_CTL_G2", "vpu-g2",
> IMX8MM_BLK_CTL_G2_PD, 0x4,
> +		       BIT(0), 0, BIT(0), IMX_BLK_CTL_PD_RESET),
> +	IMX_BLK_CTL_PD("VPU_BLK_CTL_G1", "vpu-g1",
> IMX8MM_BLK_CTL_G1_PD, 0x4,
> +		       BIT(1), 0, BIT(1), IMX_BLK_CTL_PD_RESET),
> +	IMX_BLK_CTL_PD("VPU_BLK_CTL_H1", "vpu-h1",
> IMX8MM_BLK_CTL_H1_PD, 0x4,
> +		       BIT(2), 0, BIT(2), IMX_BLK_CTL_PD_HANDSHAKE |
> +IMX_BLK_CTL_PD_RESET), };
> +
> +static const struct regmap_config imx8mm_blk_ctl_regmap_config = {
> +	.reg_bits		= 32,
> +	.reg_stride		= 4,
> +	.val_bits		= 32,
> +	.max_register		= 0x30,
> +	.fast_io		= true,
> +};
> +
> +static const struct imx_blk_ctl_dev_data imx8mm_vpumix_blk_ctl_dev_data
> = {
> +	.pds = imx8mm_vpumix_blk_ctl_pds,
> +	.pds_num = ARRAY_SIZE(imx8mm_vpumix_blk_ctl_pds),
> +	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, IMX8MM_BLK_CTL_H1_PD,
> 0x4, BIT(2), 0, BIT(2),
> +				 IMX_BLK_CTL_PD_HANDSHAKE),
> +	.config = imx8mm_blk_ctl_regmap_config,
> +	.active_pd_names = (char*[]){"vpumix", "g1", "g2", "h1"},
> +	.num_active_pd = 4,
> +};
> +
> +static const struct imx_blk_ctl_dev_data
> imx8mm_dispmix_blk_ctl_dev_data = {
> +	.pds = imx8mm_dispmix_blk_ctl_pds,
> +	.pds_num = ARRAY_SIZE(imx8mm_dispmix_blk_ctl_pds),
> +	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, -1, 0x4,
> MEDIA_BLK_BUS_PD_MASK, 0,
> +				 MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN,
> +				 IMX_BLK_CTL_PD_HANDSHAKE |
> IMX_BLK_CTL_PD_RESET),
> +	.config = imx8mm_blk_ctl_regmap_config,
> +	.active_pd_names = (char*[]){"dispmix", "mipi"},
> +	.num_active_pd = 2,
> +};
> +
> +static int imx8mm_blk_ctl_probe(struct platform_device *pdev) {
> +	struct device *dev = &pdev->dev;
> +	const struct imx_blk_ctl_dev_data *dev_data =
> of_device_get_match_data(dev);
> +	struct regmap *regmap;
> +	struct resource *res;
> +	struct imx_blk_ctl *ctl;
> +	void __iomem *base;
> +
> +	ctl = devm_kzalloc(dev, sizeof(*ctl), GFP_KERNEL);
> +	if (!ctl)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	regmap = devm_regmap_init_mmio(dev, base, &dev_data->config);
> +	if (IS_ERR(regmap))
> +		return PTR_ERR(regmap);
> +

Possible to get the regmap with 'device/syscon_node_to_regmap'?

BR
Jacky Bai
> +	ctl->regmap = regmap;
> +	ctl->dev = dev;
> +	atomic_set(&ctl->power_count, 0);
> +
> +	ctl->num_clks = devm_clk_bulk_get_all(dev, &ctl->clks);
> +	if (ctl->num_clks < 0)
> +		return ctl->num_clks;
> +
> +	dev_set_drvdata(dev, ctl);
> +	ctl->dev_data = of_device_get_match_data(dev);
> +
> +	return imx_blk_ctl_register(dev);
> +}
> +
> +static const struct of_device_id imx_blk_ctl_of_match[] = {
> +	{ .compatible = "fsl,imx8mm-vpumix-blk-ctl", .data =
> &imx8mm_vpumix_blk_ctl_dev_data },
> +	{ .compatible = "fsl,imx8mm-dispmix-blk-ctl", .data =
> &imx8mm_dispmix_blk_ctl_dev_data },
> +	{ /* Sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx_blk_ctl_of_match);
> +
> +static struct platform_driver imx_blk_ctl_driver = {
> +	.probe = imx8mm_blk_ctl_probe,
> +	.driver = {
> +		.name = "imx8mm-blk-ctl",
> +		.of_match_table = of_match_ptr(imx_blk_ctl_of_match),
> +		.pm = &imx_blk_ctl_pm_ops,
> +	},
> +};
> +module_platform_driver(imx_blk_ctl_driver);
> --
> 2.30.0


From szabolcs.nagy at arm.com  Thu Apr 29 08:54:55 2021
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Thu, 29 Apr 2021 08:54:55 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
Message-ID: <20210429075454.GQ9028@arm.com>

The 04/28/2021 12:31, Bill Wendling wrote:
> On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo at google.com> wrote:
> > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> > >
> > > > > Since the note.gnu.property section in the vDSO is not checked by the
> > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> > >
> > > > Can we not instead fix the linker script to preserve the
> > > > .note.gnu.property, correctly aligned? It doesn't take much space and
> > > > while we don't use it now, it has the BTI information about the binary.
> > >
> > > > Cc'ing a few others who were involved in the BTI support.
> > >
> > > Not just BTI, we also flag PAC usage in there too and could add other
> > > extensions going forwards.  While the note isn't actively used by
> > > anything right now due to the kernel mapping the vDSO prior to userspace
> > > starting it is part of the ABI and something could end up wanting to use
> > > it and getting confused if it's not there.  It would be much better to
> > > fix the alignment issue.
> >
> > If there's only one of the 8-byte aligned sections guaranteed, we
> > could place it first in the note. Otherwise, we will have to change
> > the alignment of the note (or somehow merge multiple notes).
> >
> I should have clarified that there's only one *entry* in the
> .note.gnu.properties section, and if not then is it possible to merge
> multiple entries into one. (Excuse my ignorance if this is already the
> case.)

.note.gnu.property should go to PT_GNU_PROPERTY and it
should be merged following rules specified in
https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
and
https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property

it may also be covered by a (8byte aligned) PT_NOTE, but
that's not a requirement on aarch64 (x86 requires it for
compatibility with old dynamic linker, but since the vdso
is handled specially that may not be relevant either).

i don't know how this works in linker scripts.


From cl at rock-chips.com  Thu Apr 29 09:11:41 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:11:41 +0800
Subject: [PATCH v4 00/10] arm64: dts: rockchip: add basic dtsi/dts files for
 RK3568 SoC
Message-ID: <20210429081151.17558-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

v1:
1. add some dt-bindings for RK3568 devices.
2. add core dtsi for RK3568 SoC.
3. add basic dts for RK3568 EVB

v2:
1. sort device nodes by some rules.

v3:
1. make ARCH=arm64 dtbs_check, then fix some errors and add some documents.

v4:
1. make ARCH=arm64 dt_binding_check, then fix grf.yaml.
2. correct gic node.

Liang Chen (10):
  dt-bindings: i2c: i2c-rk3x: add description for rk3568
  dt-bindings: serial: snps-dw-apb-uart: add description for rk3568
  dt-bindings: mmc: rockchip-dw-mshc: add description for rk3568
  dt-bindings: watchdog: dw-wdt: add description for rk3568
  dt-bindings: pwm: rockchip: add description for rk3568
  dt-bindings: gpio: change items restriction of clock for
    rockchip,gpio-bank
  dt-bindings: soc: rockchip: Convert grf.txt to YAML
  arm64: dts: rockchip: add generic pinconfig settings used by most
    Rockchip socs
  arm64: dts: rockchip: add core dtsi for RK3568 SoC
  arm64: dts: rockchip: add basic dts for RK3568 EVB

 .../devicetree/bindings/arm/rockchip.yaml     |    5 +
 .../bindings/gpio/rockchip,gpio-bank.yaml     |    3 +-
 .../devicetree/bindings/i2c/i2c-rk3x.yaml     |    1 +
 .../bindings/mmc/rockchip-dw-mshc.yaml        |    9 +-
 .../devicetree/bindings/pwm/pwm-rockchip.yaml |    1 +
 .../bindings/serial/snps-dw-apb-uart.yaml     |    1 +
 .../devicetree/bindings/soc/rockchip/grf.txt  |   61 -
 .../devicetree/bindings/soc/rockchip/grf.yaml |   60 +
 .../bindings/watchdog/snps,dw-wdt.yaml        |    1 +
 arch/arm64/boot/dts/rockchip/Makefile         |    1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     |   79 +
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  779 +++++
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   |  344 ++
 14 files changed, 4386 insertions(+), 70 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:11:42 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:11:42 +0800
Subject: [PATCH v4 01/10] dt-bindings: i2c: i2c-rk3x: add description for
 rk3568
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081151.17558-2-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on
a rk3568 platform to i2c-rk3x.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
index 7f254d79558c..5339dd4fc370 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml
@@ -36,6 +36,7 @@ properties:
               - rockchip,px30-i2c
               - rockchip,rk3308-i2c
               - rockchip,rk3328-i2c
+              - rockchip,rk3568-i2c
           - const: rockchip,rk3399-i2c
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:11:43 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:11:43 +0800
Subject: [PATCH v4 02/10] dt-bindings: serial: snps-dw-apb-uart: add
 description for rk3568
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081151.17558-3-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
a rk3568 platform to snps-dw-apb-uart.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 87ef1e218152..97debbf68748 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -31,6 +31,7 @@ properties:
               - rockchip,rk3328-uart
               - rockchip,rk3368-uart
               - rockchip,rk3399-uart
+              - rockchip,rk3568-uart
               - rockchip,rv1108-uart
           - const: snps,dw-apb-uart
       - items:
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:11:44 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:11:44 +0800
Subject: [PATCH v4 03/10] dt-bindings: mmc: rockchip-dw-mshc: add description
 for rk3568
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081151.17558-4-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" for mmc nodes on
a rk3568 platform to rockchip-dw-mshc.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/mmc/rockchip-dw-mshc.yaml        | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
index 3762f1c8de96..eaa3b0ef24f6 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
@@ -29,21 +29,14 @@ properties:
       - const: rockchip,rk3288-dw-mshc
       - items:
           - enum:
-            # for Rockchip PX30
               - rockchip,px30-dw-mshc
-            # for Rockchip RK3036
               - rockchip,rk3036-dw-mshc
-            # for Rockchip RK322x
               - rockchip,rk3228-dw-mshc
-            # for Rockchip RK3308
               - rockchip,rk3308-dw-mshc
-            # for Rockchip RK3328
               - rockchip,rk3328-dw-mshc
-            # for Rockchip RK3368
               - rockchip,rk3368-dw-mshc
-            # for Rockchip RK3399
               - rockchip,rk3399-dw-mshc
-            # for Rockchip RV1108
+              - rockchip,rk3568-dw-mshc
               - rockchip,rv1108-dw-mshc
           - const: rockchip,rk3288-dw-mshc
 
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:11:45 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:11:45 +0800
Subject: [PATCH v4 04/10] dt-bindings: watchdog: dw-wdt: add description for
 rk3568
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081151.17558-5-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-wdt", "snps,dw-wdt" for watchdog nodes on
a rk3568 platform to snps,dw-wdt.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index b58596b1831d..6461eb4f4a27 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -27,6 +27,7 @@ properties:
               - rockchip,rk3328-wdt
               - rockchip,rk3368-wdt
               - rockchip,rk3399-wdt
+              - rockchip,rk3568-wdt
               - rockchip,rv1108-wdt
           - const: snps,dw-wdt
 
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:12:52 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:12:52 +0800
Subject: [PATCH v4 05/10] dt-bindings: pwm: rockchip: add description for
 rk3568
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081252.17711-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

add "rockchip,rk3568-pwm", "rockchip,rk3328-pwm" for pwm nodes on
a rk3568 platform to pwm-rockchip.yaml.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
index 5596bee70509..81a54a4e8e3e 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
@@ -29,6 +29,7 @@ properties:
           - enum:
               - rockchip,px30-pwm
               - rockchip,rk3308-pwm
+              - rockchip,rk3568-pwm
           - const: rockchip,rk3328-pwm
 
   reg:
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:13:06 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:13:06 +0800
Subject: [PATCH v4 06/10] dt-bindings: gpio: change items restriction of clock
 for rockchip, gpio-bank
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081306.17784-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

The clock property need 2 items on some rockchip chips.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
index d993e002cebe..7b3fd2975c74 100644
--- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
@@ -22,7 +22,8 @@ properties:
     maxItems: 1
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
 
   gpio-controller: true
 
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:13:21 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:13:21 +0800
Subject: [PATCH v4 07/10] dt-bindings: soc: rockchip: Convert grf.txt to YAML
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081321.17855-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

Current dts files with 'grf' nodes are manually verified. In order to
automate this process grf.txt has to be converted to YAML.

Add new descriptions for:
"rockchip,rk3568-grf", "syscon", "simple-mfd"
"rockchip,rk3568-pmugrf", "syscon", "simple-mfd"

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
 .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
 2 files changed, 60 insertions(+), 61 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
deleted file mode 100644
index f96511aa3897..000000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-* Rockchip General Register Files (GRF)
-
-The general register file will be used to do static set by software, which
-is composed of many registers for system control.
-
-From RK3368 SoCs, the GRF is divided into two sections,
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- PMUGRF, used for always on system
-
-On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
-
-ON RK3308 SoC, the GRF is divided into four sections:
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- DETECTGRF, used for audio codec system,
-- COREGRF, used for pvtm,
-
-Required Properties:
-
-- compatible: GRF should be one of the following:
-   - "rockchip,px30-grf", "syscon": for px30
-   - "rockchip,rk3036-grf", "syscon": for rk3036
-   - "rockchip,rk3066-grf", "syscon": for rk3066
-   - "rockchip,rk3188-grf", "syscon": for rk3188
-   - "rockchip,rk3228-grf", "syscon": for rk3228
-   - "rockchip,rk3288-grf", "syscon": for rk3288
-   - "rockchip,rk3308-grf", "syscon": for rk3308
-   - "rockchip,rk3328-grf", "syscon": for rk3328
-   - "rockchip,rk3368-grf", "syscon": for rk3368
-   - "rockchip,rk3399-grf", "syscon": for rk3399
-   - "rockchip,rv1108-grf", "syscon": for rv1108
-- compatible: DETECTGRF should be one of the following:
-   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
-- compatilbe: COREGRF should be one of the following:
-   - "rockchip,rk3308-core-grf", "syscon": for rk3308
-- compatible: PMUGRF should be one of the following:
-   - "rockchip,px30-pmugrf", "syscon": for px30
-   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
-   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
-- compatible: SGRF should be one of the following:
-   - "rockchip,rk3288-sgrf", "syscon": for rk3288
-- compatible: USB2PHYGRF should be one of the following:
-   - "rockchip,px30-usb2phy-grf", "syscon": for px30
-   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
-- compatible: USBGRF should be one of the following:
-   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
-- reg: physical base address of the controller and length of memory mapped
-  region.
-
-Example: GRF and PMUGRF of RK3399 SoCs
-
-	pmugrf: syscon at ff320000 {
-		compatible = "rockchip,rk3399-pmugrf", "syscon";
-		reg = <0x0 0xff320000 0x0 0x1000>;
-	};
-
-	grf: syscon at ff770000 {
-		compatible = "rockchip,rk3399-grf", "syscon";
-		reg = <0x0 0xff770000 0x0 0x10000>;
-	};
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
new file mode 100644
index 000000000000..93231b95554b
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip General Register Files
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    - items:
+        - enum:
+            - rockchip,px30-grf
+            - rockchip,px30-pmugrf
+            - rockchip,px30-usb2phy-grf
+            - rockchip,rk3036-grf
+            - rockchip,rk3066-grf
+            - rockchip,rk3188-grf
+            - rockchip,rk3228-grf
+            - rockchip,rk3288-grf
+            - rockchip,rk3288-sgrf
+            - rockchip,rk3308-core-grf
+            - rockchip,rk3308-detect-grf
+            - rockchip,rk3308-grf
+            - rockchip,rk3328-grf
+            - rockchip,rk3328-usb2phy-grf
+            - rockchip,rk3368-grf
+            - rockchip,rk3368-pmugrf
+            - rockchip,rk3399-grf
+            - rockchip,rk3399-pmugrf
+            - rockchip,rk3568-grf
+            - rockchip,rk3568-pmugrf
+            - rockchip,rv1108-grf
+            - rockchip,rv1108-usbgrf
+        - const: syscon
+        - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    pmugrf: syscon at ff320000 {
+       compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
+       reg = <0xff320000 0x1000>;
+    };
+
+    grf: syscon at ff770000 {
+       compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
+       reg = <0xff770000 0x10000>;
+    };
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:13:34 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:13:34 +0800
Subject: [PATCH v4 08/10] arm64: dts: rockchip: add generic pinconfig settings
 used by most Rockchip socs
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081334.17920-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

The pinconfig settings for Rockchip SoCs are pretty similar on all socs,
so move them to a shared dtsi to be included, instead of redefining them
for each soc.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rockchip-pinconf.dtsi   | 344 ++++++++++++++++++
 1 file changed, 344 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
new file mode 100644
index 000000000000..5c645437b507
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rockchip-pinconf.dtsi
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+&pinctrl {
+	/omit-if-no-ref/
+	pcfg_pull_up: pcfg-pull-up {
+		bias-pull-up;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down: pcfg-pull-down {
+		bias-pull-down;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none: pcfg-pull-none {
+		bias-disable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0: pcfg-pull-none-drv-level-0 {
+		bias-disable;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_1: pcfg-pull-none-drv-level-1 {
+		bias-disable;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_2: pcfg-pull-none-drv-level-2 {
+		bias-disable;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_3: pcfg-pull-none-drv-level-3 {
+		bias-disable;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_4: pcfg-pull-none-drv-level-4 {
+		bias-disable;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_5: pcfg-pull-none-drv-level-5 {
+		bias-disable;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_6: pcfg-pull-none-drv-level-6 {
+		bias-disable;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_7: pcfg-pull-none-drv-level-7 {
+		bias-disable;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_8: pcfg-pull-none-drv-level-8 {
+		bias-disable;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_9: pcfg-pull-none-drv-level-9 {
+		bias-disable;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_10: pcfg-pull-none-drv-level-10 {
+		bias-disable;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_11: pcfg-pull-none-drv-level-11 {
+		bias-disable;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_12: pcfg-pull-none-drv-level-12 {
+		bias-disable;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_13: pcfg-pull-none-drv-level-13 {
+		bias-disable;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_14: pcfg-pull-none-drv-level-14 {
+		bias-disable;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_15: pcfg-pull-none-drv-level-15 {
+		bias-disable;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_0: pcfg-pull-up-drv-level-0 {
+		bias-pull-up;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_1: pcfg-pull-up-drv-level-1 {
+		bias-pull-up;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_2: pcfg-pull-up-drv-level-2 {
+		bias-pull-up;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_3: pcfg-pull-up-drv-level-3 {
+		bias-pull-up;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_4: pcfg-pull-up-drv-level-4 {
+		bias-pull-up;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_5: pcfg-pull-up-drv-level-5 {
+		bias-pull-up;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_6: pcfg-pull-up-drv-level-6 {
+		bias-pull-up;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_7: pcfg-pull-up-drv-level-7 {
+		bias-pull-up;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_8: pcfg-pull-up-drv-level-8 {
+		bias-pull-up;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_9: pcfg-pull-up-drv-level-9 {
+		bias-pull-up;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_10: pcfg-pull-up-drv-level-10 {
+		bias-pull-up;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_11: pcfg-pull-up-drv-level-11 {
+		bias-pull-up;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_12: pcfg-pull-up-drv-level-12 {
+		bias-pull-up;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_13: pcfg-pull-up-drv-level-13 {
+		bias-pull-up;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_14: pcfg-pull-up-drv-level-14 {
+		bias-pull-up;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_drv_level_15: pcfg-pull-up-drv-level-15 {
+		bias-pull-up;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_0: pcfg-pull-down-drv-level-0 {
+		bias-pull-down;
+		drive-strength = <0>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_1: pcfg-pull-down-drv-level-1 {
+		bias-pull-down;
+		drive-strength = <1>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_2: pcfg-pull-down-drv-level-2 {
+		bias-pull-down;
+		drive-strength = <2>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_3: pcfg-pull-down-drv-level-3 {
+		bias-pull-down;
+		drive-strength = <3>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_4: pcfg-pull-down-drv-level-4 {
+		bias-pull-down;
+		drive-strength = <4>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_5: pcfg-pull-down-drv-level-5 {
+		bias-pull-down;
+		drive-strength = <5>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_6: pcfg-pull-down-drv-level-6 {
+		bias-pull-down;
+		drive-strength = <6>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_7: pcfg-pull-down-drv-level-7 {
+		bias-pull-down;
+		drive-strength = <7>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_8: pcfg-pull-down-drv-level-8 {
+		bias-pull-down;
+		drive-strength = <8>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_9: pcfg-pull-down-drv-level-9 {
+		bias-pull-down;
+		drive-strength = <9>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_10: pcfg-pull-down-drv-level-10 {
+		bias-pull-down;
+		drive-strength = <10>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_11: pcfg-pull-down-drv-level-11 {
+		bias-pull-down;
+		drive-strength = <11>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_12: pcfg-pull-down-drv-level-12 {
+		bias-pull-down;
+		drive-strength = <12>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_13: pcfg-pull-down-drv-level-13 {
+		bias-pull-down;
+		drive-strength = <13>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_14: pcfg-pull-down-drv-level-14 {
+		bias-pull-down;
+		drive-strength = <14>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_drv_level_15: pcfg-pull-down-drv-level-15 {
+		bias-pull-down;
+		drive-strength = <15>;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_up_smt: pcfg-pull-up-smt {
+		bias-pull-up;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_down_smt: pcfg-pull-down-smt {
+		bias-pull-down;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_smt: pcfg-pull-none-smt {
+		bias-disable;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_pull_none_drv_level_0_smt: pcfg-pull-none-drv-level-0-smt {
+		bias-disable;
+		drive-strength = <0>;
+		input-schmitt-enable;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	/omit-if-no-ref/
+	pcfg_output_low: pcfg-output-low {
+		output-low;
+	};
+};
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:13:46 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:13:46 +0800
Subject: [PATCH v4 09/10] arm64: dts: rockchip: add core dtsi for RK3568 SoC
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081346.17986-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

RK3568 is a high-performance and low power quad-core application processor
designed for personal mobile internet device and AIoT equipment. This patch
add basic core dtsi file for it.

We use scmi_clk for cortex-a55 instead of standard ARMCLK, so that
kernel/uboot/rtos can change cpu clk with the same code in ATF, and we will
enalbe a special high-performance PLL when high frequency is required. The
smci_clk code is in ATF, and clkid for cpu is 0, as below:

    cpu0: cpu at 0 {
        device_type = "cpu";
        compatible = "arm,cortex-a55";
        reg = <0x0 0x0>;
        clocks = <&scmi_clk 0>;
    };

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../boot/dts/rockchip/rk3568-pinctrl.dtsi     | 3111 +++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |  779 +++++
 2 files changed, 3890 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
new file mode 100644
index 000000000000..a588ca95ace2
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi
@@ -0,0 +1,3111 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rockchip-pinconf.dtsi"
+
+/*
+ * This file is auto generated by pin2dts tool, please keep these code
+ * by adding changes at end of this file.
+ */
+&pinctrl {
+	acodec {
+		/omit-if-no-ref/
+		acodec_pins: acodec-pins {
+			rockchip,pins =
+				/* acodec_adc_sync */
+				<1 RK_PB1 5 &pcfg_pull_none>,
+				/* acodec_adcclk */
+				<1 RK_PA1 5 &pcfg_pull_none>,
+				/* acodec_adcdata */
+				<1 RK_PA0 5 &pcfg_pull_none>,
+				/* acodec_dac_datal */
+				<1 RK_PA7 5 &pcfg_pull_none>,
+				/* acodec_dac_datar */
+				<1 RK_PB0 5 &pcfg_pull_none>,
+				/* acodec_dacclk */
+				<1 RK_PA3 5 &pcfg_pull_none>,
+				/* acodec_dacsync */
+				<1 RK_PA5 5 &pcfg_pull_none>;
+		};
+	};
+
+	audiopwm {
+		/omit-if-no-ref/
+		audiopwm_lout: audiopwm-lout {
+			rockchip,pins =
+				/* audiopwm_lout */
+				<1 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutn: audiopwm-loutn {
+			rockchip,pins =
+				/* audiopwm_loutn */
+				<1 RK_PA1 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_loutp: audiopwm-loutp {
+			rockchip,pins =
+				/* audiopwm_loutp */
+				<1 RK_PA0 6 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_rout: audiopwm-rout {
+			rockchip,pins =
+				/* audiopwm_rout */
+				<1 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routn: audiopwm-routn {
+			rockchip,pins =
+				/* audiopwm_routn */
+				<1 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		audiopwm_routp: audiopwm-routp {
+			rockchip,pins =
+				/* audiopwm_routp */
+				<1 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	bt656 {
+		/omit-if-no-ref/
+		bt656m0_pins: bt656m0-pins {
+			rockchip,pins =
+				/* bt656_clkm0 */
+				<3 RK_PA0 2 &pcfg_pull_none>,
+				/* bt656_d0m0 */
+				<2 RK_PD0 2 &pcfg_pull_none>,
+				/* bt656_d1m0 */
+				<2 RK_PD1 2 &pcfg_pull_none>,
+				/* bt656_d2m0 */
+				<2 RK_PD2 2 &pcfg_pull_none>,
+				/* bt656_d3m0 */
+				<2 RK_PD3 2 &pcfg_pull_none>,
+				/* bt656_d4m0 */
+				<2 RK_PD4 2 &pcfg_pull_none>,
+				/* bt656_d5m0 */
+				<2 RK_PD5 2 &pcfg_pull_none>,
+				/* bt656_d6m0 */
+				<2 RK_PD6 2 &pcfg_pull_none>,
+				/* bt656_d7m0 */
+				<2 RK_PD7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		bt656m1_pins: bt656m1-pins {
+			rockchip,pins =
+				/* bt656_clkm1 */
+				<4 RK_PB4 5 &pcfg_pull_none>,
+				/* bt656_d0m1 */
+				<3 RK_PC6 5 &pcfg_pull_none>,
+				/* bt656_d1m1 */
+				<3 RK_PC7 5 &pcfg_pull_none>,
+				/* bt656_d2m1 */
+				<3 RK_PD0 5 &pcfg_pull_none>,
+				/* bt656_d3m1 */
+				<3 RK_PD1 5 &pcfg_pull_none>,
+				/* bt656_d4m1 */
+				<3 RK_PD2 5 &pcfg_pull_none>,
+				/* bt656_d5m1 */
+				<3 RK_PD3 5 &pcfg_pull_none>,
+				/* bt656_d6m1 */
+				<3 RK_PD4 5 &pcfg_pull_none>,
+				/* bt656_d7m1 */
+				<3 RK_PD5 5 &pcfg_pull_none>;
+		};
+	};
+
+	bt1120 {
+		/omit-if-no-ref/
+		bt1120_pins: bt1120-pins {
+			rockchip,pins =
+				/* bt1120_clk */
+				<3 RK_PA6 2 &pcfg_pull_none>,
+				/* bt1120_d0 */
+				<3 RK_PA1 2 &pcfg_pull_none>,
+				/* bt1120_d1 */
+				<3 RK_PA2 2 &pcfg_pull_none>,
+				/* bt1120_d2 */
+				<3 RK_PA3 2 &pcfg_pull_none>,
+				/* bt1120_d3 */
+				<3 RK_PA4 2 &pcfg_pull_none>,
+				/* bt1120_d4 */
+				<3 RK_PA5 2 &pcfg_pull_none>,
+				/* bt1120_d5 */
+				<3 RK_PA7 2 &pcfg_pull_none>,
+				/* bt1120_d6 */
+				<3 RK_PB0 2 &pcfg_pull_none>,
+				/* bt1120_d7 */
+				<3 RK_PB1 2 &pcfg_pull_none>,
+				/* bt1120_d8 */
+				<3 RK_PB2 2 &pcfg_pull_none>,
+				/* bt1120_d9 */
+				<3 RK_PB3 2 &pcfg_pull_none>,
+				/* bt1120_d10 */
+				<3 RK_PB4 2 &pcfg_pull_none>,
+				/* bt1120_d11 */
+				<3 RK_PB5 2 &pcfg_pull_none>,
+				/* bt1120_d12 */
+				<3 RK_PB6 2 &pcfg_pull_none>,
+				/* bt1120_d13 */
+				<3 RK_PC1 2 &pcfg_pull_none>,
+				/* bt1120_d14 */
+				<3 RK_PC2 2 &pcfg_pull_none>,
+				/* bt1120_d15 */
+				<3 RK_PC3 2 &pcfg_pull_none>;
+		};
+	};
+
+	cam {
+		/omit-if-no-ref/
+		cam_clkout0: cam-clkout0 {
+			rockchip,pins =
+				/* cam_clkout0 */
+				<4 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cam_clkout1: cam-clkout1 {
+			rockchip,pins =
+				/* cam_clkout1 */
+				<4 RK_PB0 1 &pcfg_pull_none>;
+		};
+	};
+
+	can0 {
+		/omit-if-no-ref/
+		can0m0_pins: can0m0-pins {
+			rockchip,pins =
+				/* can0_rxm0 */
+				<0 RK_PB4 2 &pcfg_pull_none>,
+				/* can0_txm0 */
+				<0 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can0m1_pins: can0m1-pins {
+			rockchip,pins =
+				/* can0_rxm1 */
+				<2 RK_PA2 4 &pcfg_pull_none>,
+				/* can0_txm1 */
+				<2 RK_PA1 4 &pcfg_pull_none>;
+		};
+	};
+
+	can1 {
+		/omit-if-no-ref/
+		can1m0_pins: can1m0-pins {
+			rockchip,pins =
+				/* can1_rxm0 */
+				<1 RK_PA0 3 &pcfg_pull_none>,
+				/* can1_txm0 */
+				<1 RK_PA1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can1m1_pins: can1m1-pins {
+			rockchip,pins =
+				/* can1_rxm1 */
+				<4 RK_PC2 3 &pcfg_pull_none>,
+				/* can1_txm1 */
+				<4 RK_PC3 3 &pcfg_pull_none>;
+		};
+	};
+
+	can2 {
+		/omit-if-no-ref/
+		can2m0_pins: can2m0-pins {
+			rockchip,pins =
+				/* can2_rxm0 */
+				<4 RK_PB4 3 &pcfg_pull_none>,
+				/* can2_txm0 */
+				<4 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		can2m1_pins: can2m1-pins {
+			rockchip,pins =
+				/* can2_rxm1 */
+				<2 RK_PB1 4 &pcfg_pull_none>,
+				/* can2_txm1 */
+				<2 RK_PB2 4 &pcfg_pull_none>;
+		};
+	};
+
+	cif {
+		/omit-if-no-ref/
+		cif_clk: cif-clk {
+			rockchip,pins =
+				/* cif_clkout */
+				<4 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_clk: cif-dvp-clk {
+			rockchip,pins =
+				/* cif_clkin */
+				<4 RK_PC1 1 &pcfg_pull_none>,
+				/* cif_href */
+				<4 RK_PB6 1 &pcfg_pull_none>,
+				/* cif_vsync */
+				<4 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus16: cif-dvp-bus16 {
+			rockchip,pins =
+				/* cif_d8 */
+				<3 RK_PD6 1 &pcfg_pull_none>,
+				/* cif_d9 */
+				<3 RK_PD7 1 &pcfg_pull_none>,
+				/* cif_d10 */
+				<4 RK_PA0 1 &pcfg_pull_none>,
+				/* cif_d11 */
+				<4 RK_PA1 1 &pcfg_pull_none>,
+				/* cif_d12 */
+				<4 RK_PA2 1 &pcfg_pull_none>,
+				/* cif_d13 */
+				<4 RK_PA3 1 &pcfg_pull_none>,
+				/* cif_d14 */
+				<4 RK_PA4 1 &pcfg_pull_none>,
+				/* cif_d15 */
+				<4 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		cif_dvp_bus8: cif-dvp-bus8 {
+			rockchip,pins =
+				/* cif_d0 */
+				<3 RK_PC6 1 &pcfg_pull_none>,
+				/* cif_d1 */
+				<3 RK_PC7 1 &pcfg_pull_none>,
+				/* cif_d2 */
+				<3 RK_PD0 1 &pcfg_pull_none>,
+				/* cif_d3 */
+				<3 RK_PD1 1 &pcfg_pull_none>,
+				/* cif_d4 */
+				<3 RK_PD2 1 &pcfg_pull_none>,
+				/* cif_d5 */
+				<3 RK_PD3 1 &pcfg_pull_none>,
+				/* cif_d6 */
+				<3 RK_PD4 1 &pcfg_pull_none>,
+				/* cif_d7 */
+				<3 RK_PD5 1 &pcfg_pull_none>;
+		};
+	};
+
+	clk32k {
+		/omit-if-no-ref/
+		clk32k_in: clk32k-in {
+			rockchip,pins =
+				/* clk32k_in */
+				<0 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out0: clk32k-out0 {
+			rockchip,pins =
+				/* clk32k_out0 */
+				<0 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		clk32k_out1: clk32k-out1 {
+			rockchip,pins =
+				/* clk32k_out1 */
+				<2 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	cpu {
+		/omit-if-no-ref/
+		cpu_pins: cpu-pins {
+			rockchip,pins =
+				/* cpu_avs */
+				<0 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	ebc {
+		/omit-if-no-ref/
+		ebc_extern: ebc-extern {
+			rockchip,pins =
+				/* ebc_sdce1 */
+				<4 RK_PA7 2 &pcfg_pull_none>,
+				/* ebc_sdce2 */
+				<4 RK_PB0 2 &pcfg_pull_none>,
+				/* ebc_sdce3 */
+				<4 RK_PB1 2 &pcfg_pull_none>,
+				/* ebc_sdshr */
+				<4 RK_PB5 2 &pcfg_pull_none>,
+				/* ebc_vcom */
+				<4 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		ebc_pins: ebc-pins {
+			rockchip,pins =
+				/* ebc_gdclk */
+				<4 RK_PC0 2 &pcfg_pull_none>,
+				/* ebc_gdoe */
+				<4 RK_PB3 2 &pcfg_pull_none>,
+				/* ebc_gdsp */
+				<4 RK_PB4 2 &pcfg_pull_none>,
+				/* ebc_sdce0 */
+				<4 RK_PA6 2 &pcfg_pull_none>,
+				/* ebc_sdclk */
+				<4 RK_PC1 2 &pcfg_pull_none>,
+				/* ebc_sddo0 */
+				<3 RK_PC6 2 &pcfg_pull_none>,
+				/* ebc_sddo1 */
+				<3 RK_PC7 2 &pcfg_pull_none>,
+				/* ebc_sddo2 */
+				<3 RK_PD0 2 &pcfg_pull_none>,
+				/* ebc_sddo3 */
+				<3 RK_PD1 2 &pcfg_pull_none>,
+				/* ebc_sddo4 */
+				<3 RK_PD2 2 &pcfg_pull_none>,
+				/* ebc_sddo5 */
+				<3 RK_PD3 2 &pcfg_pull_none>,
+				/* ebc_sddo6 */
+				<3 RK_PD4 2 &pcfg_pull_none>,
+				/* ebc_sddo7 */
+				<3 RK_PD5 2 &pcfg_pull_none>,
+				/* ebc_sddo8 */
+				<3 RK_PD6 2 &pcfg_pull_none>,
+				/* ebc_sddo9 */
+				<3 RK_PD7 2 &pcfg_pull_none>,
+				/* ebc_sddo10 */
+				<4 RK_PA0 2 &pcfg_pull_none>,
+				/* ebc_sddo11 */
+				<4 RK_PA1 2 &pcfg_pull_none>,
+				/* ebc_sddo12 */
+				<4 RK_PA2 2 &pcfg_pull_none>,
+				/* ebc_sddo13 */
+				<4 RK_PA3 2 &pcfg_pull_none>,
+				/* ebc_sddo14 */
+				<4 RK_PA4 2 &pcfg_pull_none>,
+				/* ebc_sddo15 */
+				<4 RK_PA5 2 &pcfg_pull_none>,
+				/* ebc_sdle */
+				<4 RK_PB6 2 &pcfg_pull_none>,
+				/* ebc_sdoe */
+				<4 RK_PB7 2 &pcfg_pull_none>;
+		};
+	};
+
+	edpdp {
+		/omit-if-no-ref/
+		edpdpm0_pins: edpdpm0-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm0 */
+				<4 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		edpdpm1_pins: edpdpm1-pins {
+			rockchip,pins =
+				/* edpdp_hpdinm1 */
+				<0 RK_PC2 2 &pcfg_pull_none>;
+		};
+	};
+
+	emmc {
+		/omit-if-no-ref/
+		emmc_rstnout: emmc-rstnout {
+			rockchip,pins =
+				/* emmc_rstn */
+				<1 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		emmc_bus8: emmc-bus8 {
+			rockchip,pins =
+				/* emmc_d0 */
+				<1 RK_PB4 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d1 */
+				<1 RK_PB5 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d2 */
+				<1 RK_PB6 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d3 */
+				<1 RK_PB7 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d4 */
+				<1 RK_PC0 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d5 */
+				<1 RK_PC1 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d6 */
+				<1 RK_PC2 1 &pcfg_pull_up_drv_level_2>,
+				/* emmc_d7 */
+				<1 RK_PC3 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_clk: emmc-clk {
+			rockchip,pins =
+				/* emmc_clkout */
+				<1 RK_PC5 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_cmd: emmc-cmd {
+			rockchip,pins =
+				/* emmc_cmd */
+				<1 RK_PC4 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		emmc_datastrobe: emmc-datastrobe {
+			rockchip,pins =
+				/* emmc_datastrobe */
+				<1 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	eth0 {
+		/omit-if-no-ref/
+		eth0_pins: eth0-pins {
+			rockchip,pins =
+				/* eth0_refclko25m */
+				<2 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	eth1 {
+		/omit-if-no-ref/
+		eth1m0_pins: eth1m0-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm0 */
+				<3 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		eth1m1_pins: eth1m1-pins {
+			rockchip,pins =
+				/* eth1_refclko25mm1 */
+				<4 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	flash {
+		/omit-if-no-ref/
+		flash_pins: flash-pins {
+			rockchip,pins =
+				/* flash_ale */
+				<1 RK_PD0 2 &pcfg_pull_none>,
+				/* flash_cle */
+				<1 RK_PC6 3 &pcfg_pull_none>,
+				/* flash_cs0n */
+				<1 RK_PD3 2 &pcfg_pull_none>,
+				/* flash_cs1n */
+				<1 RK_PD4 2 &pcfg_pull_none>,
+				/* flash_d0 */
+				<1 RK_PB4 2 &pcfg_pull_none>,
+				/* flash_d1 */
+				<1 RK_PB5 2 &pcfg_pull_none>,
+				/* flash_d2 */
+				<1 RK_PB6 2 &pcfg_pull_none>,
+				/* flash_d3 */
+				<1 RK_PB7 2 &pcfg_pull_none>,
+				/* flash_d4 */
+				<1 RK_PC0 2 &pcfg_pull_none>,
+				/* flash_d5 */
+				<1 RK_PC1 2 &pcfg_pull_none>,
+				/* flash_d6 */
+				<1 RK_PC2 2 &pcfg_pull_none>,
+				/* flash_d7 */
+				<1 RK_PC3 2 &pcfg_pull_none>,
+				/* flash_dqs */
+				<1 RK_PC5 2 &pcfg_pull_none>,
+				/* flash_rdn */
+				<1 RK_PD2 2 &pcfg_pull_none>,
+				/* flash_rdy */
+				<1 RK_PD1 2 &pcfg_pull_none>,
+				/* flash_volsel */
+				<0 RK_PA7 1 &pcfg_pull_none>,
+				/* flash_wpn */
+				<1 RK_PC7 3 &pcfg_pull_none>,
+				/* flash_wrn */
+				<1 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	fspi {
+		/omit-if-no-ref/
+		fspi_pins: fspi-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>,
+				/* fspi_d2 */
+				<1 RK_PC7 2 &pcfg_pull_none>,
+				/* fspi_d3 */
+				<1 RK_PD4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		fspi_cs1: fspi-cs1 {
+			rockchip,pins =
+				/* fspi_cs1n */
+				<1 RK_PC6 2 &pcfg_pull_up>;
+		};
+	};
+
+	gmac0 {
+		/omit-if-no-ref/
+		gmac0_miim: gmac0-miim {
+			rockchip,pins =
+				/* gmac0_mdc */
+				<2 RK_PC3 2 &pcfg_pull_none>,
+				/* gmac0_mdio */
+				<2 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_clkinout: gmac0-clkinout {
+			rockchip,pins =
+				/* gmac0_mclkinout */
+				<2 RK_PC2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_er: gmac0-rx-er {
+			rockchip,pins =
+				/* gmac0_rxer */
+				<2 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rx_bus2: gmac0-rx-bus2 {
+			rockchip,pins =
+				/* gmac0_rxd0 */
+				<2 RK_PB6 1 &pcfg_pull_none>,
+				/* gmac0_rxd1 */
+				<2 RK_PB7 2 &pcfg_pull_none>,
+				/* gmac0_rxdvcrs */
+				<2 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_tx_bus2: gmac0-tx-bus2 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_clk: gmac0-rgmii-clk {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus: gmac0-rgmii-bus {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_2>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gmac1 {
+		/omit-if-no-ref/
+		gmac1m0_miim: gmac1m0-miim {
+			rockchip,pins =
+				/* gmac1_mdcm0 */
+				<3 RK_PC4 3 &pcfg_pull_none>,
+				/* gmac1_mdiom0 */
+				<3 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_clkinout: gmac1m0-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm0 */
+				<3 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_er: gmac1m0-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm0 */
+				<3 RK_PB4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rx_bus2: gmac1m0-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m0 */
+				<3 RK_PB1 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m0 */
+				<3 RK_PB2 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm0 */
+				<3 RK_PB3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2: gmac1m0-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk: gmac1m0-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus: gmac1m0-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_miim: gmac1m1-miim {
+			rockchip,pins =
+				/* gmac1_mdcm1 */
+				<4 RK_PB6 3 &pcfg_pull_none>,
+				/* gmac1_mdiom1 */
+				<4 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_clkinout: gmac1m1-clkinout {
+			rockchip,pins =
+				/* gmac1_mclkinoutm1 */
+				<4 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_er: gmac1m1-rx-er {
+			rockchip,pins =
+				/* gmac1_rxerm1 */
+				<4 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rx_bus2: gmac1m1-rx-bus2 {
+			rockchip,pins =
+				/* gmac1_rxd0m1 */
+				<4 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_rxd1m1 */
+				<4 RK_PB0 3 &pcfg_pull_none>,
+				/* gmac1_rxdvcrsm1 */
+				<4 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2: gmac1m1-tx-bus2 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk: gmac1m1-rgmii-clk {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus: gmac1m1-rgmii-bus {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_2>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+
+	gpu {
+		/omit-if-no-ref/
+		gpu_pins: gpu-pins {
+			rockchip,pins =
+				/* gpu_avs */
+				<0 RK_PC0 2 &pcfg_pull_none>,
+				/* gpu_pwren */
+				<0 RK_PA6 4 &pcfg_pull_none>;
+		};
+	};
+
+	hdmitx {
+		/omit-if-no-ref/
+		hdmitxm0_cec: hdmitxm0-cec {
+			rockchip,pins =
+				/* hdmitxm0_cec */
+				<4 RK_PD1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitxm1_cec: hdmitxm1-cec {
+			rockchip,pins =
+				/* hdmitxm1_cec */
+				<0 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_scl: hdmitx-scl {
+			rockchip,pins =
+				/* hdmitx_scl */
+				<4 RK_PC7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		hdmitx_sda: hdmitx-sda {
+			rockchip,pins =
+				/* hdmitx_sda */
+				<4 RK_PD0 1 &pcfg_pull_none>;
+		};
+	};
+
+	i2c0 {
+		/omit-if-no-ref/
+		i2c0_xfer: i2c0-xfer {
+			rockchip,pins =
+				/* i2c0_scl */
+				<0 RK_PB1 1 &pcfg_pull_none_smt>,
+				/* i2c0_sda */
+				<0 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c1 {
+		/omit-if-no-ref/
+		i2c1_xfer: i2c1-xfer {
+			rockchip,pins =
+				/* i2c1_scl */
+				<0 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c1_sda */
+				<0 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c2 {
+		/omit-if-no-ref/
+		i2c2m0_xfer: i2c2m0-xfer {
+			rockchip,pins =
+				/* i2c2_sclm0 */
+				<0 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam0 */
+				<0 RK_PB6 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c2m1_xfer: i2c2m1-xfer {
+			rockchip,pins =
+				/* i2c2_sclm1 */
+				<4 RK_PB5 1 &pcfg_pull_none_smt>,
+				/* i2c2_sdam1 */
+				<4 RK_PB4 1 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c3 {
+		/omit-if-no-ref/
+		i2c3m0_xfer: i2c3m0-xfer {
+			rockchip,pins =
+				/* i2c3_sclm0 */
+				<1 RK_PA1 1 &pcfg_pull_none_smt>,
+				/* i2c3_sdam0 */
+				<1 RK_PA0 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c3m1_xfer: i2c3m1-xfer {
+			rockchip,pins =
+				/* i2c3_sclm1 */
+				<3 RK_PB5 4 &pcfg_pull_none_smt>,
+				/* i2c3_sdam1 */
+				<3 RK_PB6 4 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c4 {
+		/omit-if-no-ref/
+		i2c4m0_xfer: i2c4m0-xfer {
+			rockchip,pins =
+				/* i2c4_sclm0 */
+				<4 RK_PB3 1 &pcfg_pull_none_smt>,
+				/* i2c4_sdam0 */
+				<4 RK_PB2 1 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c4m1_xfer: i2c4m1-xfer {
+			rockchip,pins =
+				/* i2c4_sclm1 */
+				<2 RK_PB2 2 &pcfg_pull_none_smt>,
+				/* i2c4_sdam1 */
+				<2 RK_PB1 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2c5 {
+		/omit-if-no-ref/
+		i2c5m0_xfer: i2c5m0-xfer {
+			rockchip,pins =
+				/* i2c5_sclm0 */
+				<3 RK_PB3 4 &pcfg_pull_none_smt>,
+				/* i2c5_sdam0 */
+				<3 RK_PB4 4 &pcfg_pull_none_smt>;
+		};
+
+		/omit-if-no-ref/
+		i2c5m1_xfer: i2c5m1-xfer {
+			rockchip,pins =
+				/* i2c5_sclm1 */
+				<4 RK_PC7 2 &pcfg_pull_none_smt>,
+				/* i2c5_sdam1 */
+				<4 RK_PD0 2 &pcfg_pull_none_smt>;
+		};
+	};
+
+	i2s1 {
+		/omit-if-no-ref/
+		i2s1m0_lrckrx: i2s1m0-lrckrx {
+			rockchip,pins =
+				/* i2s1m0_lrckrx */
+				<1 RK_PA6 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_lrcktx: i2s1m0-lrcktx {
+			rockchip,pins =
+				/* i2s1m0_lrcktx */
+				<1 RK_PA5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_mclk: i2s1m0-mclk {
+			rockchip,pins =
+				/* i2s1m0_mclk */
+				<1 RK_PA2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclkrx: i2s1m0-sclkrx {
+			rockchip,pins =
+				/* i2s1m0_sclkrx */
+				<1 RK_PA4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sclktx: i2s1m0-sclktx {
+			rockchip,pins =
+				/* i2s1m0_sclktx */
+				<1 RK_PA3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi0: i2s1m0-sdi0 {
+			rockchip,pins =
+				/* i2s1m0_sdi0 */
+				<1 RK_PB3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi1: i2s1m0-sdi1 {
+			rockchip,pins =
+				/* i2s1m0_sdi1 */
+				<1 RK_PB2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi2: i2s1m0-sdi2 {
+			rockchip,pins =
+				/* i2s1m0_sdi2 */
+				<1 RK_PB1 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdi3: i2s1m0-sdi3 {
+			rockchip,pins =
+				/* i2s1m0_sdi3 */
+				<1 RK_PB0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo0: i2s1m0-sdo0 {
+			rockchip,pins =
+				/* i2s1m0_sdo0 */
+				<1 RK_PA7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo1: i2s1m0-sdo1 {
+			rockchip,pins =
+				/* i2s1m0_sdo1 */
+				<1 RK_PB0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo2: i2s1m0-sdo2 {
+			rockchip,pins =
+				/* i2s1m0_sdo2 */
+				<1 RK_PB1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m0_sdo3: i2s1m0-sdo3 {
+			rockchip,pins =
+				/* i2s1m0_sdo3 */
+				<1 RK_PB2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrckrx: i2s1m1-lrckrx {
+			rockchip,pins =
+				/* i2s1m1_lrckrx */
+				<4 RK_PA7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_lrcktx: i2s1m1-lrcktx {
+			rockchip,pins =
+				/* i2s1m1_lrcktx */
+				<3 RK_PD0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_mclk: i2s1m1-mclk {
+			rockchip,pins =
+				/* i2s1m1_mclk */
+				<3 RK_PC6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclkrx: i2s1m1-sclkrx {
+			rockchip,pins =
+				/* i2s1m1_sclkrx */
+				<4 RK_PA6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sclktx: i2s1m1-sclktx {
+			rockchip,pins =
+				/* i2s1m1_sclktx */
+				<3 RK_PC7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi0: i2s1m1-sdi0 {
+			rockchip,pins =
+				/* i2s1m1_sdi0 */
+				<3 RK_PD2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi1: i2s1m1-sdi1 {
+			rockchip,pins =
+				/* i2s1m1_sdi1 */
+				<3 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi2: i2s1m1-sdi2 {
+			rockchip,pins =
+				/* i2s1m1_sdi2 */
+				<3 RK_PD4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdi3: i2s1m1-sdi3 {
+			rockchip,pins =
+				/* i2s1m1_sdi3 */
+				<3 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo0: i2s1m1-sdo0 {
+			rockchip,pins =
+				/* i2s1m1_sdo0 */
+				<3 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo1: i2s1m1-sdo1 {
+			rockchip,pins =
+				/* i2s1m1_sdo1 */
+				<4 RK_PB0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo2: i2s1m1-sdo2 {
+			rockchip,pins =
+				/* i2s1m1_sdo2 */
+				<4 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m1_sdo3: i2s1m1-sdo3 {
+			rockchip,pins =
+				/* i2s1m1_sdo3 */
+				<4 RK_PB5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrckrx: i2s1m2-lrckrx {
+			rockchip,pins =
+				/* i2s1m2_lrckrx */
+				<3 RK_PC5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_lrcktx: i2s1m2-lrcktx {
+			rockchip,pins =
+				/* i2s1m2_lrcktx */
+				<2 RK_PD2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_mclk: i2s1m2-mclk {
+			rockchip,pins =
+				/* i2s1m2_mclk */
+				<2 RK_PD0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclkrx: i2s1m2-sclkrx {
+			rockchip,pins =
+				/* i2s1m2_sclkrx */
+				<3 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sclktx: i2s1m2-sclktx {
+			rockchip,pins =
+				/* i2s1m2_sclktx */
+				<2 RK_PD1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi0: i2s1m2-sdi0 {
+			rockchip,pins =
+				/* i2s1m2_sdi0 */
+				<2 RK_PD3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi1: i2s1m2-sdi1 {
+			rockchip,pins =
+				/* i2s1m2_sdi1 */
+				<2 RK_PD4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi2: i2s1m2-sdi2 {
+			rockchip,pins =
+				/* i2s1m2_sdi2 */
+				<2 RK_PD5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdi3: i2s1m2-sdi3 {
+			rockchip,pins =
+				/* i2s1m2_sdi3 */
+				<2 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo0: i2s1m2-sdo0 {
+			rockchip,pins =
+				/* i2s1m2_sdo0 */
+				<2 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo1: i2s1m2-sdo1 {
+			rockchip,pins =
+				/* i2s1m2_sdo1 */
+				<3 RK_PA0 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo2: i2s1m2-sdo2 {
+			rockchip,pins =
+				/* i2s1m2_sdo2 */
+				<3 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s1m2_sdo3: i2s1m2-sdo3 {
+			rockchip,pins =
+				/* i2s1m2_sdo3 */
+				<3 RK_PC2 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s2 {
+		/omit-if-no-ref/
+		i2s2m0_lrckrx: i2s2m0-lrckrx {
+			rockchip,pins =
+				/* i2s2m0_lrckrx */
+				<2 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_lrcktx: i2s2m0-lrcktx {
+			rockchip,pins =
+				/* i2s2m0_lrcktx */
+				<2 RK_PC3 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_mclk: i2s2m0-mclk {
+			rockchip,pins =
+				/* i2s2m0_mclk */
+				<2 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclkrx: i2s2m0-sclkrx {
+			rockchip,pins =
+				/* i2s2m0_sclkrx */
+				<2 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sclktx: i2s2m0-sclktx {
+			rockchip,pins =
+				/* i2s2m0_sclktx */
+				<2 RK_PC2 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdi: i2s2m0-sdi {
+			rockchip,pins =
+				/* i2s2m0_sdi */
+				<2 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m0_sdo: i2s2m0-sdo {
+			rockchip,pins =
+				/* i2s2m0_sdo */
+				<2 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrckrx: i2s2m1-lrckrx {
+			rockchip,pins =
+				/* i2s2m1_lrckrx */
+				<4 RK_PA5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_lrcktx: i2s2m1-lrcktx {
+			rockchip,pins =
+				/* i2s2m1_lrcktx */
+				<4 RK_PA4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_mclk: i2s2m1-mclk {
+			rockchip,pins =
+				/* i2s2m1_mclk */
+				<4 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclkrx: i2s2m1-sclkrx {
+			rockchip,pins =
+				/* i2s2m1_sclkrx */
+				<4 RK_PC1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sclktx: i2s2m1-sclktx {
+			rockchip,pins =
+				/* i2s2m1_sclktx */
+				<4 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdi: i2s2m1-sdi {
+			rockchip,pins =
+				/* i2s2m1_sdi */
+				<4 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s2m1_sdo: i2s2m1-sdo {
+			rockchip,pins =
+				/* i2s2m1_sdo */
+				<4 RK_PB3 5 &pcfg_pull_none>;
+		};
+	};
+
+	i2s3 {
+		/omit-if-no-ref/
+		i2s3m0_lrck: i2s3m0-lrck {
+			rockchip,pins =
+				/* i2s3m0_lrck */
+				<3 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_mclk: i2s3m0-mclk {
+			rockchip,pins =
+				/* i2s3m0_mclk */
+				<3 RK_PA2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sclk: i2s3m0-sclk {
+			rockchip,pins =
+				/* i2s3m0_sclk */
+				<3 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdi: i2s3m0-sdi {
+			rockchip,pins =
+				/* i2s3m0_sdi */
+				<3 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m0_sdo: i2s3m0-sdo {
+			rockchip,pins =
+				/* i2s3m0_sdo */
+				<3 RK_PA5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_lrck: i2s3m1-lrck {
+			rockchip,pins =
+				/* i2s3m1_lrck */
+				<4 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_mclk: i2s3m1-mclk {
+			rockchip,pins =
+				/* i2s3m1_mclk */
+				<4 RK_PC2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sclk: i2s3m1-sclk {
+			rockchip,pins =
+				/* i2s3m1_sclk */
+				<4 RK_PC3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdi: i2s3m1-sdi {
+			rockchip,pins =
+				/* i2s3m1_sdi */
+				<4 RK_PC6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		i2s3m1_sdo: i2s3m1-sdo {
+			rockchip,pins =
+				/* i2s3m1_sdo */
+				<4 RK_PC5 5 &pcfg_pull_none>;
+		};
+	};
+
+	isp {
+		/omit-if-no-ref/
+		isp_pins: isp-pins {
+			rockchip,pins =
+				/* isp_flashtrigin */
+				<4 RK_PB4 4 &pcfg_pull_none>,
+				/* isp_flashtrigout */
+				<4 RK_PA6 1 &pcfg_pull_none>,
+				/* isp_prelighttrig */
+				<4 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	jtag {
+		/omit-if-no-ref/
+		jtag_pins: jtag-pins {
+			rockchip,pins =
+				/* jtag_tck */
+				<1 RK_PD7 2 &pcfg_pull_none>,
+				/* jtag_tms */
+				<2 RK_PA0 2 &pcfg_pull_none>;
+		};
+	};
+
+	lcdc {
+		/omit-if-no-ref/
+		lcdc_ctl: lcdc-ctl {
+			rockchip,pins =
+				/* lcdc_clk */
+				<3 RK_PA0 1 &pcfg_pull_none>,
+				/* lcdc_d0 */
+				<2 RK_PD0 1 &pcfg_pull_none>,
+				/* lcdc_d1 */
+				<2 RK_PD1 1 &pcfg_pull_none>,
+				/* lcdc_d2 */
+				<2 RK_PD2 1 &pcfg_pull_none>,
+				/* lcdc_d3 */
+				<2 RK_PD3 1 &pcfg_pull_none>,
+				/* lcdc_d4 */
+				<2 RK_PD4 1 &pcfg_pull_none>,
+				/* lcdc_d5 */
+				<2 RK_PD5 1 &pcfg_pull_none>,
+				/* lcdc_d6 */
+				<2 RK_PD6 1 &pcfg_pull_none>,
+				/* lcdc_d7 */
+				<2 RK_PD7 1 &pcfg_pull_none>,
+				/* lcdc_d8 */
+				<3 RK_PA1 1 &pcfg_pull_none>,
+				/* lcdc_d9 */
+				<3 RK_PA2 1 &pcfg_pull_none>,
+				/* lcdc_d10 */
+				<3 RK_PA3 1 &pcfg_pull_none>,
+				/* lcdc_d11 */
+				<3 RK_PA4 1 &pcfg_pull_none>,
+				/* lcdc_d12 */
+				<3 RK_PA5 1 &pcfg_pull_none>,
+				/* lcdc_d13 */
+				<3 RK_PA6 1 &pcfg_pull_none>,
+				/* lcdc_d14 */
+				<3 RK_PA7 1 &pcfg_pull_none>,
+				/* lcdc_d15 */
+				<3 RK_PB0 1 &pcfg_pull_none>,
+				/* lcdc_d16 */
+				<3 RK_PB1 1 &pcfg_pull_none>,
+				/* lcdc_d17 */
+				<3 RK_PB2 1 &pcfg_pull_none>,
+				/* lcdc_d18 */
+				<3 RK_PB3 1 &pcfg_pull_none>,
+				/* lcdc_d19 */
+				<3 RK_PB4 1 &pcfg_pull_none>,
+				/* lcdc_d20 */
+				<3 RK_PB5 1 &pcfg_pull_none>,
+				/* lcdc_d21 */
+				<3 RK_PB6 1 &pcfg_pull_none>,
+				/* lcdc_d22 */
+				<3 RK_PB7 1 &pcfg_pull_none>,
+				/* lcdc_d23 */
+				<3 RK_PC0 1 &pcfg_pull_none>,
+				/* lcdc_den */
+				<3 RK_PC3 1 &pcfg_pull_none>,
+				/* lcdc_hsync */
+				<3 RK_PC1 1 &pcfg_pull_none>,
+				/* lcdc_vsync */
+				<3 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	mcu {
+		/omit-if-no-ref/
+		mcu_pins: mcu-pins {
+			rockchip,pins =
+				/* mcu_jtagtck */
+				<0 RK_PB4 4 &pcfg_pull_none>,
+				/* mcu_jtagtdi */
+				<0 RK_PC1 4 &pcfg_pull_none>,
+				/* mcu_jtagtdo */
+				<0 RK_PB3 4 &pcfg_pull_none>,
+				/* mcu_jtagtms */
+				<0 RK_PC2 4 &pcfg_pull_none>,
+				/* mcu_jtagtrstn */
+				<0 RK_PC3 4 &pcfg_pull_none>;
+		};
+	};
+
+	npu {
+		/omit-if-no-ref/
+		npu_pins: npu-pins {
+			rockchip,pins =
+				/* npu_avs */
+				<0 RK_PC1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pcie20 {
+		/omit-if-no-ref/
+		pcie20m0_pins: pcie20m0-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm0 */
+				<0 RK_PA5 3 &pcfg_pull_none>,
+				/* pcie20_perstnm0 */
+				<0 RK_PB6 3 &pcfg_pull_none>,
+				/* pcie20_wakenm0 */
+				<0 RK_PB5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m1_pins: pcie20m1-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm1 */
+				<2 RK_PD0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm1 */
+				<3 RK_PC1 4 &pcfg_pull_none>,
+				/* pcie20_wakenm1 */
+				<2 RK_PD1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20m2_pins: pcie20m2-pins {
+			rockchip,pins =
+				/* pcie20_clkreqnm2 */
+				<1 RK_PB0 4 &pcfg_pull_none>,
+				/* pcie20_perstnm2 */
+				<1 RK_PB2 4 &pcfg_pull_none>,
+				/* pcie20_wakenm2 */
+				<1 RK_PB1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie20_buttonrstn: pcie20-buttonrstn {
+			rockchip,pins =
+				/* pcie20_buttonrstn */
+				<0 RK_PB4 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x1 {
+		/omit-if-no-ref/
+		pcie30x1m0_pins: pcie30x1m0-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm0 */
+				<0 RK_PA4 3 &pcfg_pull_none>,
+				/* pcie30x1_perstnm0 */
+				<0 RK_PC3 3 &pcfg_pull_none>,
+				/* pcie30x1_wakenm0 */
+				<0 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m1_pins: pcie30x1m1-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm1 */
+				<2 RK_PD2 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm1 */
+				<3 RK_PA1 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm1 */
+				<2 RK_PD3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1m2_pins: pcie30x1m2-pins {
+			rockchip,pins =
+				/* pcie30x1_clkreqnm2 */
+				<1 RK_PA5 4 &pcfg_pull_none>,
+				/* pcie30x1_perstnm2 */
+				<1 RK_PA2 4 &pcfg_pull_none>,
+				/* pcie30x1_wakenm2 */
+				<1 RK_PA3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x1_buttonrstn: pcie30x1-buttonrstn {
+			rockchip,pins =
+				/* pcie30x1_buttonrstn */
+				<0 RK_PB3 3 &pcfg_pull_none>;
+		};
+	};
+
+	pcie30x2 {
+		/omit-if-no-ref/
+		pcie30x2m0_pins: pcie30x2m0-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm0 */
+				<0 RK_PA6 2 &pcfg_pull_none>,
+				/* pcie30x2_perstnm0 */
+				<0 RK_PC6 3 &pcfg_pull_none>,
+				/* pcie30x2_wakenm0 */
+				<0 RK_PC5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m1_pins: pcie30x2m1-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm1 */
+				<2 RK_PD4 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm1 */
+				<2 RK_PD6 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm1 */
+				<2 RK_PD5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2m2_pins: pcie30x2m2-pins {
+			rockchip,pins =
+				/* pcie30x2_clkreqnm2 */
+				<4 RK_PC2 4 &pcfg_pull_none>,
+				/* pcie30x2_perstnm2 */
+				<4 RK_PC4 4 &pcfg_pull_none>,
+				/* pcie30x2_wakenm2 */
+				<4 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pcie30x2_buttonrstn: pcie30x2-buttonrstn {
+			rockchip,pins =
+				/* pcie30x2_buttonrstn */
+				<0 RK_PB0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pdm {
+		/omit-if-no-ref/
+		pdmm0_clk: pdmm0-clk {
+			rockchip,pins =
+				/* pdm_clk0m0 */
+				<1 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_clk1: pdmm0-clk1 {
+			rockchip,pins =
+				/* pdmm0_clk1 */
+				<1 RK_PA4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi0: pdmm0-sdi0 {
+			rockchip,pins =
+				/* pdmm0_sdi0 */
+				<1 RK_PB3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi1: pdmm0-sdi1 {
+			rockchip,pins =
+				/* pdmm0_sdi1 */
+				<1 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi2: pdmm0-sdi2 {
+			rockchip,pins =
+				/* pdmm0_sdi2 */
+				<1 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm0_sdi3: pdmm0-sdi3 {
+			rockchip,pins =
+				/* pdmm0_sdi3 */
+				<1 RK_PB0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk: pdmm1-clk {
+			rockchip,pins =
+				/* pdm_clk0m1 */
+				<3 RK_PD6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_clk1: pdmm1-clk1 {
+			rockchip,pins =
+				/* pdmm1_clk1 */
+				<4 RK_PA0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi0: pdmm1-sdi0 {
+			rockchip,pins =
+				/* pdmm1_sdi0 */
+				<3 RK_PD7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi1: pdmm1-sdi1 {
+			rockchip,pins =
+				/* pdmm1_sdi1 */
+				<4 RK_PA1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi2: pdmm1-sdi2 {
+			rockchip,pins =
+				/* pdmm1_sdi2 */
+				<4 RK_PA2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm1_sdi3: pdmm1-sdi3 {
+			rockchip,pins =
+				/* pdmm1_sdi3 */
+				<4 RK_PA3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_clk1: pdmm2-clk1 {
+			rockchip,pins =
+				/* pdmm2_clk1 */
+				<3 RK_PC4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi0: pdmm2-sdi0 {
+			rockchip,pins =
+				/* pdmm2_sdi0 */
+				<3 RK_PB3 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi1: pdmm2-sdi1 {
+			rockchip,pins =
+				/* pdmm2_sdi1 */
+				<3 RK_PB4 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi2: pdmm2-sdi2 {
+			rockchip,pins =
+				/* pdmm2_sdi2 */
+				<3 RK_PB7 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pdmm2_sdi3: pdmm2-sdi3 {
+			rockchip,pins =
+				/* pdmm2_sdi3 */
+				<3 RK_PC0 5 &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		/omit-if-no-ref/
+		pmic_pins: pmic-pins {
+			rockchip,pins =
+				/* pmic_sleep */
+				<0 RK_PA2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pmu {
+		/omit-if-no-ref/
+		pmu_pins: pmu-pins {
+			rockchip,pins =
+				/* pmu_debug0 */
+				<0 RK_PA5 4 &pcfg_pull_none>,
+				/* pmu_debug1 */
+				<0 RK_PA6 3 &pcfg_pull_none>,
+				/* pmu_debug2 */
+				<0 RK_PC4 4 &pcfg_pull_none>,
+				/* pmu_debug3 */
+				<0 RK_PC5 4 &pcfg_pull_none>,
+				/* pmu_debug4 */
+				<0 RK_PC6 4 &pcfg_pull_none>,
+				/* pmu_debug5 */
+				<0 RK_PC7 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm0 {
+		/omit-if-no-ref/
+		pwm0m0_pins: pwm0m0-pins {
+			rockchip,pins =
+				/* pwm0_m0 */
+				<0 RK_PB7 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm0m1_pins: pwm0m1-pins {
+			rockchip,pins =
+				/* pwm0_m1 */
+				<0 RK_PC7 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm1 {
+		/omit-if-no-ref/
+		pwm1m0_pins: pwm1m0-pins {
+			rockchip,pins =
+				/* pwm1_m0 */
+				<0 RK_PC0 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm1m1_pins: pwm1m1-pins {
+			rockchip,pins =
+				/* pwm1_m1 */
+				<0 RK_PB5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm2 {
+		/omit-if-no-ref/
+		pwm2m0_pins: pwm2m0-pins {
+			rockchip,pins =
+				/* pwm2_m0 */
+				<0 RK_PC1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm2m1_pins: pwm2m1-pins {
+			rockchip,pins =
+				/* pwm2_m1 */
+				<0 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm3 {
+		/omit-if-no-ref/
+		pwm3_pins: pwm3-pins {
+			rockchip,pins =
+				/* pwm3_ir */
+				<0 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm4 {
+		/omit-if-no-ref/
+		pwm4_pins: pwm4-pins {
+			rockchip,pins =
+				/* pwm4 */
+				<0 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm5 {
+		/omit-if-no-ref/
+		pwm5_pins: pwm5-pins {
+			rockchip,pins =
+				/* pwm5 */
+				<0 RK_PC4 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm6 {
+		/omit-if-no-ref/
+		pwm6_pins: pwm6-pins {
+			rockchip,pins =
+				/* pwm6 */
+				<0 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm7 {
+		/omit-if-no-ref/
+		pwm7_pins: pwm7-pins {
+			rockchip,pins =
+				/* pwm7_ir */
+				<0 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm8 {
+		/omit-if-no-ref/
+		pwm8m0_pins: pwm8m0-pins {
+			rockchip,pins =
+				/* pwm8_m0 */
+				<3 RK_PB1 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm8m1_pins: pwm8m1-pins {
+			rockchip,pins =
+				/* pwm8_m1 */
+				<1 RK_PD5 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm9 {
+		/omit-if-no-ref/
+		pwm9m0_pins: pwm9m0-pins {
+			rockchip,pins =
+				/* pwm9_m0 */
+				<3 RK_PB2 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm9m1_pins: pwm9m1-pins {
+			rockchip,pins =
+				/* pwm9_m1 */
+				<1 RK_PD6 4 &pcfg_pull_none>;
+		};
+	};
+
+	pwm10 {
+		/omit-if-no-ref/
+		pwm10m0_pins: pwm10m0-pins {
+			rockchip,pins =
+				/* pwm10_m0 */
+				<3 RK_PB5 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm10m1_pins: pwm10m1-pins {
+			rockchip,pins =
+				/* pwm10_m1 */
+				<2 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	pwm11 {
+		/omit-if-no-ref/
+		pwm11m0_pins: pwm11m0-pins {
+			rockchip,pins =
+				/* pwm11_irm0 */
+				<3 RK_PB6 5 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm11m1_pins: pwm11m1-pins {
+			rockchip,pins =
+				/* pwm11_irm1 */
+				<4 RK_PC0 3 &pcfg_pull_none>;
+		};
+	};
+
+	pwm12 {
+		/omit-if-no-ref/
+		pwm12m0_pins: pwm12m0-pins {
+			rockchip,pins =
+				/* pwm12_m0 */
+				<3 RK_PB7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm12m1_pins: pwm12m1-pins {
+			rockchip,pins =
+				/* pwm12_m1 */
+				<4 RK_PC5 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm13 {
+		/omit-if-no-ref/
+		pwm13m0_pins: pwm13m0-pins {
+			rockchip,pins =
+				/* pwm13_m0 */
+				<3 RK_PC0 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm13m1_pins: pwm13m1-pins {
+			rockchip,pins =
+				/* pwm13_m1 */
+				<4 RK_PC6 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm14 {
+		/omit-if-no-ref/
+		pwm14m0_pins: pwm14m0-pins {
+			rockchip,pins =
+				/* pwm14_m0 */
+				<3 RK_PC4 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm14m1_pins: pwm14m1-pins {
+			rockchip,pins =
+				/* pwm14_m1 */
+				<4 RK_PC2 1 &pcfg_pull_none>;
+		};
+	};
+
+	pwm15 {
+		/omit-if-no-ref/
+		pwm15m0_pins: pwm15m0-pins {
+			rockchip,pins =
+				/* pwm15_irm0 */
+				<3 RK_PC5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		pwm15m1_pins: pwm15m1-pins {
+			rockchip,pins =
+				/* pwm15_irm1 */
+				<4 RK_PC3 1 &pcfg_pull_none>;
+		};
+	};
+
+	refclk {
+		/omit-if-no-ref/
+		refclk_pins: refclk-pins {
+			rockchip,pins =
+				/* refclk_ou */
+				<0 RK_PA0 1 &pcfg_pull_none>;
+		};
+	};
+
+	sata {
+		/omit-if-no-ref/
+		sata_pins: sata-pins {
+			rockchip,pins =
+				/* sata_cpdet */
+				<0 RK_PA4 2 &pcfg_pull_none>,
+				/* sata_cppod */
+				<0 RK_PA6 1 &pcfg_pull_none>,
+				/* sata_mpswitch */
+				<0 RK_PA5 2 &pcfg_pull_none>;
+		};
+	};
+
+	sata0 {
+		/omit-if-no-ref/
+		sata0_pins: sata0-pins {
+			rockchip,pins =
+				/* sata0_actled */
+				<4 RK_PC6 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata1 {
+		/omit-if-no-ref/
+		sata1_pins: sata1-pins {
+			rockchip,pins =
+				/* sata1_actled */
+				<4 RK_PC5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sata2 {
+		/omit-if-no-ref/
+		sata2_pins: sata2-pins {
+			rockchip,pins =
+				/* sata2_actled */
+				<4 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	scr {
+		/omit-if-no-ref/
+		scr_pins: scr-pins {
+			rockchip,pins =
+				/* scr_clk */
+				<1 RK_PA2 3 &pcfg_pull_none>,
+				/* scr_det */
+				<1 RK_PA7 3 &pcfg_pull_up>,
+				/* scr_io */
+				<1 RK_PA3 3 &pcfg_pull_up>,
+				/* scr_rst */
+				<1 RK_PA5 3 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc0 {
+		/omit-if-no-ref/
+		sdmmc0_bus4: sdmmc0-bus4 {
+			rockchip,pins =
+				/* sdmmc0_d0 */
+				<1 RK_PD5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d1 */
+				<1 RK_PD6 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d2 */
+				<1 RK_PD7 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc0_d3 */
+				<2 RK_PA0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_clk: sdmmc0-clk {
+			rockchip,pins =
+				/* sdmmc0_clk */
+				<2 RK_PA2 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_cmd: sdmmc0-cmd {
+			rockchip,pins =
+				/* sdmmc0_cmd */
+				<2 RK_PA1 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_det: sdmmc0-det {
+			rockchip,pins =
+				/* sdmmc0_det */
+				<0 RK_PA4 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc0_pwren: sdmmc0-pwren {
+			rockchip,pins =
+				/* sdmmc0_pwren */
+				<0 RK_PA5 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc1 {
+		/omit-if-no-ref/
+		sdmmc1_bus4: sdmmc1-bus4 {
+			rockchip,pins =
+				/* sdmmc1_d0 */
+				<2 RK_PA3 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d1 */
+				<2 RK_PA4 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d2 */
+				<2 RK_PA5 1 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc1_d3 */
+				<2 RK_PA6 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_clk: sdmmc1-clk {
+			rockchip,pins =
+				/* sdmmc1_clk */
+				<2 RK_PB0 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_cmd: sdmmc1-cmd {
+			rockchip,pins =
+				/* sdmmc1_cmd */
+				<2 RK_PA7 1 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_det: sdmmc1-det {
+			rockchip,pins =
+				/* sdmmc1_det */
+				<2 RK_PB2 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc1_pwren: sdmmc1-pwren {
+			rockchip,pins =
+				/* sdmmc1_pwren */
+				<2 RK_PB1 1 &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc2 {
+		/omit-if-no-ref/
+		sdmmc2m0_bus4: sdmmc2m0-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m0 */
+				<3 RK_PC6 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m0 */
+				<3 RK_PC7 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m0 */
+				<3 RK_PD0 3 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m0 */
+				<3 RK_PD1 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_clk: sdmmc2m0-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm0 */
+				<3 RK_PD3 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_cmd: sdmmc2m0-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm0 */
+				<3 RK_PD2 3 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_det: sdmmc2m0-det {
+			rockchip,pins =
+				/* sdmmc2_detm0 */
+				<3 RK_PD4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m0_pwren: sdmmc2m0-pwren {
+			rockchip,pins =
+				/* sdmmc2m0_pwren */
+				<3 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_bus4: sdmmc2m1-bus4 {
+			rockchip,pins =
+				/* sdmmc2_d0m1 */
+				<3 RK_PA1 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d1m1 */
+				<3 RK_PA2 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d2m1 */
+				<3 RK_PA3 5 &pcfg_pull_up_drv_level_2>,
+				/* sdmmc2_d3m1 */
+				<3 RK_PA4 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_clk: sdmmc2m1-clk {
+			rockchip,pins =
+				/* sdmmc2_clkm1 */
+				<3 RK_PA6 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_cmd: sdmmc2m1-cmd {
+			rockchip,pins =
+				/* sdmmc2_cmdm1 */
+				<3 RK_PA5 5 &pcfg_pull_up_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_det: sdmmc2m1-det {
+			rockchip,pins =
+				/* sdmmc2_detm1 */
+				<3 RK_PA7 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		sdmmc2m1_pwren: sdmmc2m1-pwren {
+			rockchip,pins =
+				/* sdmmc2m1_pwren */
+				<3 RK_PB0 4 &pcfg_pull_none>;
+		};
+	};
+
+	spdif {
+		/omit-if-no-ref/
+		spdifm0_tx: spdifm0-tx {
+			rockchip,pins =
+				/* spdifm0_tx */
+				<1 RK_PA4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm1_tx: spdifm1-tx {
+			rockchip,pins =
+				/* spdifm1_tx */
+				<3 RK_PC5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spdifm2_tx: spdifm2-tx {
+			rockchip,pins =
+				/* spdifm2_tx */
+				<4 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+
+	spi0 {
+		/omit-if-no-ref/
+		spi0m0_pins: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_none>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_none>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_none>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_none>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi1 {
+		/omit-if-no-ref/
+		spi1m0_pins: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_none>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_none>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_none>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_none>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi2 {
+		/omit-if-no-ref/
+		spi2m0_pins: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_none>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_none>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_none>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_none>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_none>;
+		};
+	};
+
+	spi3 {
+		/omit-if-no-ref/
+		spi3m0_pins: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_none>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_none>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_none>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_none>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_none>;
+		};
+	};
+
+	tsadc {
+		/omit-if-no-ref/
+		tsadcm0_shut: tsadcm0-shut {
+			rockchip,pins =
+				/* tsadcm0_shut */
+				<0 RK_PA1 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadcm1_shut: tsadcm1-shut {
+			rockchip,pins =
+				/* tsadcm1_shut */
+				<0 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		tsadc_shutorg: tsadc-shutorg {
+			rockchip,pins =
+				/* tsadc_shutorg */
+				<0 RK_PA1 2 &pcfg_pull_none>;
+		};
+	};
+
+	uart0 {
+		/omit-if-no-ref/
+		uart0_xfer: uart0-xfer {
+			rockchip,pins =
+				/* uart0_rx */
+				<0 RK_PC0 3 &pcfg_pull_up>,
+				/* uart0_tx */
+				<0 RK_PC1 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart0_ctsn: uart0-ctsn {
+			rockchip,pins =
+				/* uart0_ctsn */
+				<0 RK_PC7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart0_rtsn: uart0-rtsn {
+			rockchip,pins =
+				/* uart0_rtsn */
+				<0 RK_PC4 3 &pcfg_pull_none>;
+		};
+	};
+
+	uart1 {
+		/omit-if-no-ref/
+		uart1m0_xfer: uart1m0-xfer {
+			rockchip,pins =
+				/* uart1_rxm0 */
+				<2 RK_PB3 2 &pcfg_pull_up>,
+				/* uart1_txm0 */
+				<2 RK_PB4 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_ctsn: uart1m0-ctsn {
+			rockchip,pins =
+				/* uart1m0_ctsn */
+				<2 RK_PB6 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m0_rtsn: uart1m0-rtsn {
+			rockchip,pins =
+				/* uart1m0_rtsn */
+				<2 RK_PB5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_xfer: uart1m1-xfer {
+			rockchip,pins =
+				/* uart1_rxm1 */
+				<3 RK_PD7 4 &pcfg_pull_up>,
+				/* uart1_txm1 */
+				<3 RK_PD6 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_ctsn: uart1m1-ctsn {
+			rockchip,pins =
+				/* uart1m1_ctsn */
+				<4 RK_PC1 4 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart1m1_rtsn: uart1m1-rtsn {
+			rockchip,pins =
+				/* uart1m1_rtsn */
+				<4 RK_PB6 4 &pcfg_pull_none>;
+		};
+	};
+
+	uart2 {
+		/omit-if-no-ref/
+		uart2m0_xfer: uart2m0-xfer {
+			rockchip,pins =
+				/* uart2_rxm0 */
+				<0 RK_PD0 1 &pcfg_pull_up>,
+				/* uart2_txm0 */
+				<0 RK_PD1 1 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart2m1_xfer: uart2m1-xfer {
+			rockchip,pins =
+				/* uart2_rxm1 */
+				<1 RK_PD6 2 &pcfg_pull_up>,
+				/* uart2_txm1 */
+				<1 RK_PD5 2 &pcfg_pull_up>;
+		};
+	};
+
+	uart3 {
+		/omit-if-no-ref/
+		uart3m0_xfer: uart3m0-xfer {
+			rockchip,pins =
+				/* uart3_rxm0 */
+				<1 RK_PA0 2 &pcfg_pull_up>,
+				/* uart3_txm0 */
+				<1 RK_PA1 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_ctsn: uart3m0-ctsn {
+			rockchip,pins =
+				/* uart3m0_ctsn */
+				<1 RK_PA3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m0_rtsn: uart3m0-rtsn {
+			rockchip,pins =
+				/* uart3m0_rtsn */
+				<1 RK_PA2 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart3m1_xfer: uart3m1-xfer {
+			rockchip,pins =
+				/* uart3_rxm1 */
+				<3 RK_PC0 4 &pcfg_pull_up>,
+				/* uart3_txm1 */
+				<3 RK_PB7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart4 {
+		/omit-if-no-ref/
+		uart4m0_xfer: uart4m0-xfer {
+			rockchip,pins =
+				/* uart4_rxm0 */
+				<1 RK_PA4 2 &pcfg_pull_up>,
+				/* uart4_txm0 */
+				<1 RK_PA6 2 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_ctsn: uart4m0-ctsn {
+			rockchip,pins =
+				/* uart4m0_ctsn */
+				<1 RK_PA7 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m0_rtsn: uart4m0-rtsn {
+			rockchip,pins =
+				/* uart4m0_rtsn */
+				<1 RK_PA5 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart4m1_xfer: uart4m1-xfer {
+			rockchip,pins =
+				/* uart4_rxm1 */
+				<3 RK_PB1 4 &pcfg_pull_up>,
+				/* uart4_txm1 */
+				<3 RK_PB2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart5 {
+		/omit-if-no-ref/
+		uart5m0_xfer: uart5m0-xfer {
+			rockchip,pins =
+				/* uart5_rxm0 */
+				<2 RK_PA1 3 &pcfg_pull_up>,
+				/* uart5_txm0 */
+				<2 RK_PA2 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_ctsn: uart5m0-ctsn {
+			rockchip,pins =
+				/* uart5m0_ctsn */
+				<1 RK_PD7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m0_rtsn: uart5m0-rtsn {
+			rockchip,pins =
+				/* uart5m0_rtsn */
+				<2 RK_PA0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart5m1_xfer: uart5m1-xfer {
+			rockchip,pins =
+				/* uart5_rxm1 */
+				<3 RK_PC3 4 &pcfg_pull_up>,
+				/* uart5_txm1 */
+				<3 RK_PC2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart6 {
+		/omit-if-no-ref/
+		uart6m0_xfer: uart6m0-xfer {
+			rockchip,pins =
+				/* uart6_rxm0 */
+				<2 RK_PA3 3 &pcfg_pull_up>,
+				/* uart6_txm0 */
+				<2 RK_PA4 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_ctsn: uart6m0-ctsn {
+			rockchip,pins =
+				/* uart6m0_ctsn */
+				<2 RK_PC0 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m0_rtsn: uart6m0-rtsn {
+			rockchip,pins =
+				/* uart6m0_rtsn */
+				<2 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart6m1_xfer: uart6m1-xfer {
+			rockchip,pins =
+				/* uart6_rxm1 */
+				<1 RK_PD6 3 &pcfg_pull_up>,
+				/* uart6_txm1 */
+				<1 RK_PD5 3 &pcfg_pull_up>;
+		};
+	};
+
+	uart7 {
+		/omit-if-no-ref/
+		uart7m0_xfer: uart7m0-xfer {
+			rockchip,pins =
+				/* uart7_rxm0 */
+				<2 RK_PA5 3 &pcfg_pull_up>,
+				/* uart7_txm0 */
+				<2 RK_PA6 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_ctsn: uart7m0-ctsn {
+			rockchip,pins =
+				/* uart7m0_ctsn */
+				<2 RK_PC2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m0_rtsn: uart7m0-rtsn {
+			rockchip,pins =
+				/* uart7m0_rtsn */
+				<2 RK_PC1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart7m1_xfer: uart7m1-xfer {
+			rockchip,pins =
+				/* uart7_rxm1 */
+				<3 RK_PC5 4 &pcfg_pull_up>,
+				/* uart7_txm1 */
+				<3 RK_PC4 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart7m2_xfer: uart7m2-xfer {
+			rockchip,pins =
+				/* uart7_rxm2 */
+				<4 RK_PA3 4 &pcfg_pull_up>,
+				/* uart7_txm2 */
+				<4 RK_PA2 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart8 {
+		/omit-if-no-ref/
+		uart8m0_xfer: uart8m0-xfer {
+			rockchip,pins =
+				/* uart8_rxm0 */
+				<2 RK_PC6 2 &pcfg_pull_up>,
+				/* uart8_txm0 */
+				<2 RK_PC5 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_ctsn: uart8m0-ctsn {
+			rockchip,pins =
+				/* uart8m0_ctsn */
+				<2 RK_PB2 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m0_rtsn: uart8m0-rtsn {
+			rockchip,pins =
+				/* uart8m0_rtsn */
+				<2 RK_PB1 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart8m1_xfer: uart8m1-xfer {
+			rockchip,pins =
+				/* uart8_rxm1 */
+				<3 RK_PA0 4 &pcfg_pull_up>,
+				/* uart8_txm1 */
+				<2 RK_PD7 4 &pcfg_pull_up>;
+		};
+	};
+
+	uart9 {
+		/omit-if-no-ref/
+		uart9m0_xfer: uart9m0-xfer {
+			rockchip,pins =
+				/* uart9_rxm0 */
+				<2 RK_PA7 3 &pcfg_pull_up>,
+				/* uart9_txm0 */
+				<2 RK_PB0 3 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_ctsn: uart9m0-ctsn {
+			rockchip,pins =
+				/* uart9m0_ctsn */
+				<2 RK_PC4 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m0_rtsn: uart9m0-rtsn {
+			rockchip,pins =
+				/* uart9m0_rtsn */
+				<2 RK_PC3 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		uart9m1_xfer: uart9m1-xfer {
+			rockchip,pins =
+				/* uart9_rxm1 */
+				<4 RK_PC6 4 &pcfg_pull_up>,
+				/* uart9_txm1 */
+				<4 RK_PC5 4 &pcfg_pull_up>;
+		};
+
+		/omit-if-no-ref/
+		uart9m2_xfer: uart9m2-xfer {
+			rockchip,pins =
+				/* uart9_rxm2 */
+				<4 RK_PA5 4 &pcfg_pull_up>,
+				/* uart9_txm2 */
+				<4 RK_PA4 4 &pcfg_pull_up>;
+		};
+	};
+
+	vop {
+		/omit-if-no-ref/
+		vopm0_pins: vopm0-pins {
+			rockchip,pins =
+				/* vop_pwmm0 */
+				<0 RK_PC3 2 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		vopm1_pins: vopm1-pins {
+			rockchip,pins =
+				/* vop_pwmm1 */
+				<3 RK_PC4 2 &pcfg_pull_none>;
+		};
+	};
+};
+
+/*
+ * This part is edited handly.
+ */
+&pinctrl {
+	spi0-hs {
+		/omit-if-no-ref/
+		spi0m0_pins_hs: spi0m0-pins {
+			rockchip,pins =
+				/* spi0_clkm0 */
+				<0 RK_PB5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom0 */
+				<0 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim0 */
+				<0 RK_PB6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs0_hs: spi0m0-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m0 */
+				<0 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m0_cs1_hs: spi0m0-cs1 {
+			rockchip,pins =
+				/* spi0_cs1m0 */
+				<0 RK_PC4 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_pins_hs: spi0m1-pins {
+			rockchip,pins =
+				/* spi0_clkm1 */
+				<2 RK_PD3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_misom1 */
+				<2 RK_PD0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi0_mosim1 */
+				<2 RK_PD1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi0m1_cs0_hs: spi0m1-cs0 {
+			rockchip,pins =
+				/* spi0_cs0m1 */
+				<2 RK_PD2 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi1-hs {
+		/omit-if-no-ref/
+		spi1m0_pins_hs: spi1m0-pins {
+			rockchip,pins =
+				/* spi1_clkm0 */
+				<2 RK_PB5 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom0 */
+				<2 RK_PB6 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim0 */
+				<2 RK_PB7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs0_hs: spi1m0-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m0 */
+				<2 RK_PC0 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m0_cs1_hs: spi1m0-cs1 {
+			rockchip,pins =
+				/* spi1_cs1m0 */
+				<2 RK_PC6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_pins_hs: spi1m1-pins {
+			rockchip,pins =
+				/* spi1_clkm1 */
+				<3 RK_PC3 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_misom1 */
+				<3 RK_PC2 3 &pcfg_pull_up_drv_level_1>,
+				/* spi1_mosim1 */
+				<3 RK_PC1 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi1m1_cs0_hs: spi1m1-cs0 {
+			rockchip,pins =
+				/* spi1_cs0m1 */
+				<3 RK_PA1 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi2-hs {
+		/omit-if-no-ref/
+		spi2m0_pins_hs: spi2m0-pins {
+			rockchip,pins =
+				/* spi2_clkm0 */
+				<2 RK_PC1 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom0 */
+				<2 RK_PC2 4 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim0 */
+				<2 RK_PC3 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs0_hs: spi2m0-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m0 */
+				<2 RK_PC4 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m0_cs1_hs: spi2m0-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m0 */
+				<2 RK_PC5 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_pins_hs: spi2m1-pins {
+			rockchip,pins =
+				/* spi2_clkm1 */
+				<3 RK_PA0 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_misom1 */
+				<2 RK_PD7 3 &pcfg_pull_up_drv_level_1>,
+				/* spi2_mosim1 */
+				<2 RK_PD6 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs0_hs: spi2m1-cs0 {
+			rockchip,pins =
+				/* spi2_cs0m1 */
+				<2 RK_PD5 3 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi2m1_cs1_hs: spi2m1-cs1 {
+			rockchip,pins =
+				/* spi2_cs1m1 */
+				<2 RK_PD4 3 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	spi3-hs {
+		/omit-if-no-ref/
+		spi3m0_pins_hs: spi3m0-pins {
+			rockchip,pins =
+				/* spi3_clkm0 */
+				<4 RK_PB3 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom0 */
+				<4 RK_PB0 4 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim0 */
+				<4 RK_PB2 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs0_hs: spi3m0-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m0 */
+				<4 RK_PA6 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m0_cs1_hs: spi3m0-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m0 */
+				<4 RK_PA7 4 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_pins_hs: spi3m1-pins {
+			rockchip,pins =
+				/* spi3_clkm1 */
+				<4 RK_PC2 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_misom1 */
+				<4 RK_PC5 2 &pcfg_pull_up_drv_level_1>,
+				/* spi3_mosim1 */
+				<4 RK_PC3 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs0_hs: spi3m1-cs0 {
+			rockchip,pins =
+				/* spi3_cs0m1 */
+				<4 RK_PC6 2 &pcfg_pull_up_drv_level_1>;
+		};
+
+		/omit-if-no-ref/
+		spi3m1_cs1_hs: spi3m1-cs1 {
+			rockchip,pins =
+				/* spi3_cs1m1 */
+				<4 RK_PD1 2 &pcfg_pull_up_drv_level_1>;
+		};
+	};
+
+	gmac-txd-level3 {
+		/omit-if-no-ref/
+		gmac0_tx_bus2_level3: gmac0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac0_txd0 */
+				<2 RK_PB3 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd1 */
+				<2 RK_PB4 1 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txen */
+				<2 RK_PB5 1 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac0_rgmii_bus_level3: gmac0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac0_rxd2 */
+				<2 RK_PA3 2 &pcfg_pull_none>,
+				/* gmac0_rxd3 */
+				<2 RK_PA4 2 &pcfg_pull_none>,
+				/* gmac0_txd2 */
+				<2 RK_PA6 2 &pcfg_pull_none_drv_level_3>,
+				/* gmac0_txd3 */
+				<2 RK_PA7 2 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_tx_bus2_level3: gmac1m0-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m0 */
+				<3 RK_PB5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m0 */
+				<3 RK_PB6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm0 */
+				<3 RK_PB7 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_bus_level3: gmac1m0-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m0 */
+				<3 RK_PA4 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m0 */
+				<3 RK_PA5 3 &pcfg_pull_none>,
+				/* gmac1_txd2m0 */
+				<3 RK_PA2 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m0 */
+				<3 RK_PA3 3 &pcfg_pull_none_drv_level_3>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_tx_bus2_level3: gmac1m1-tx-bus2-level3 {
+			rockchip,pins =
+				/* gmac1_txd0m1 */
+				<4 RK_PA4 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd1m1 */
+				<4 RK_PA5 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txenm1 */
+				<4 RK_PA6 3 &pcfg_pull_none>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_bus_level3: gmac1m1-rgmii-bus-level3 {
+			rockchip,pins =
+				/* gmac1_rxd2m1 */
+				<4 RK_PA1 3 &pcfg_pull_none>,
+				/* gmac1_rxd3m1 */
+				<4 RK_PA2 3 &pcfg_pull_none>,
+				/* gmac1_txd2m1 */
+				<3 RK_PD6 3 &pcfg_pull_none_drv_level_3>,
+				/* gmac1_txd3m1 */
+				<3 RK_PD7 3 &pcfg_pull_none_drv_level_3>;
+		};
+	};
+
+	gmac-txc-level2 {
+		/omit-if-no-ref/
+		gmac0_rgmii_clk_level2: gmac0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac0_rxclk */
+				<2 RK_PA5 2 &pcfg_pull_none>,
+				/* gmac0_txclk */
+				<2 RK_PB0 2 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m0_rgmii_clk_level2: gmac1m0-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm0 */
+				<3 RK_PA7 3 &pcfg_pull_none>,
+				/* gmac1_txclkm0 */
+				<3 RK_PA6 3 &pcfg_pull_none_drv_level_2>;
+		};
+
+		/omit-if-no-ref/
+		gmac1m1_rgmii_clk_level2: gmac1m1-rgmii-clk-level2 {
+			rockchip,pins =
+				/* gmac1_rxclkm1 */
+				<4 RK_PA3 3 &pcfg_pull_none>,
+				/* gmac1_txclkm1 */
+				<4 RK_PA0 3 &pcfg_pull_none_drv_level_2>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
new file mode 100644
index 000000000000..12a071e6790e
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -0,0 +1,779 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+#include <dt-bindings/clock/rk3568-cru.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,boot-mode.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+	compatible = "rockchip,rk3568";
+
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		gpio0 = &gpio0;
+		gpio1 = &gpio1;
+		gpio2 = &gpio2;
+		gpio3 = &gpio3;
+		gpio4 = &gpio4;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+		serial5 = &uart5;
+		serial6 = &uart6;
+		serial7 = &uart7;
+		serial8 = &uart8;
+		serial9 = &uart9;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x0>;
+			clocks = <&scmi_clk 0>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu1: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu2: cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+
+		cpu3: cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a55";
+			reg = <0x0 0x300>;
+			enable-method = "psci";
+			operating-points-v2 = <&cpu0_opp_table>;
+		};
+	};
+
+	cpu0_opp_table: cpu0-opp-table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp-408000000 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			clock-latency-ns = <40000>;
+		};
+
+		opp-600000000 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-816000000 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <900000 900000 1150000>;
+			opp-suspend;
+		};
+
+		opp-1104000000 {
+			opp-hz = /bits/ 64 <1104000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-1416000000 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <900000 900000 1150000>;
+		};
+
+		opp-1608000000 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <975000 975000 1150000>;
+		};
+
+		opp-1800000000 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1050000 1050000 1150000>;
+		};
+
+		opp-1992000000 {
+			opp-hz = /bits/ 64 <1992000000>;
+			opp-microvolt = <1150000 1150000 1150000>;
+		};
+	};
+
+	firmware {
+		scmi: scmi {
+			compatible = "arm,scmi-smc";
+			arm,smc-id = <0x82000010>;
+			shmem = <&scmi_shmem>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			scmi_clk: protocol at 14 {
+				reg = <0x14>;
+				#clock-cells = <1>;
+			};
+		};
+
+	};
+
+	pmu {
+		compatible = "arm,cortex-a55-pmu";
+		interrupts = <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+		arm,no-tick-in-suspend;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+		#clock-cells = <0>;
+	};
+
+	xin32k: xin32k {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		clock-output-names = "xin32k";
+		pinctrl-0 = <&clk32k_out0>;
+		pinctrl-names = "default";
+		#clock-cells = <0>;
+	};
+
+	sram at 10f000 {
+		compatible = "mmio-sram";
+		reg = <0x0 0x0010f000 0x0 0x100>;
+
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x0 0x0010f000 0x100>;
+
+		scmi_shmem: sram at 0 {
+			compatible = "arm,scmi-shmem";
+			reg = <0x0 0x100>;
+		};
+	};
+
+	gic: interrupt-controller at fd400000 {
+		compatible = "arm,gic-v3";
+		reg = <0x0 0xfd400000 0 0x10000>, /* GICD */
+		      <0x0 0xfd460000 0 0x80000>; /* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		mbi-alias = <0x0 0xfd100000>;
+		mbi-ranges = <296 24>;
+		msi-controller;
+	};
+
+	pmugrf: syscon at fdc20000 {
+		compatible = "rockchip,rk3568-pmugrf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc20000 0x0 0x10000>;
+	};
+
+	grf: syscon at fdc60000 {
+		compatible = "rockchip,rk3568-grf", "syscon", "simple-mfd";
+		reg = <0x0 0xfdc60000 0x0 0x10000>;
+	};
+
+	pmucru: clock-controller at fdd00000 {
+		compatible = "rockchip,rk3568-pmucru";
+		reg = <0x0 0xfdd00000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at fdd20000 {
+		compatible = "rockchip,rk3568-cru";
+		reg = <0x0 0xfdd20000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	i2c0: i2c at fdd40000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfdd40000 0x0 0x1000>;
+		interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru CLK_I2C0>, <&pmucru PCLK_I2C0>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart0: serial at fdd50000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfdd50000 0x0 0x100>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&pmucru SCLK_UART0>, <&pmucru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 0>, <&dmac0 1>;
+		pinctrl-0 = <&uart0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm0: pwm at fdd70000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70000 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm0m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm1: pwm at fdd70010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70010 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm1m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm2: pwm at fdd70020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70020 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm2m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm3: pwm at fdd70030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfdd70030 0x0 0x10>;
+		clocks = <&pmucru CLK_PWM0>, <&pmucru PCLK_PWM0>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm3_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	sdmmc2: mmc at fe000000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe000000 0x0 0x4000>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC2>, <&cru CLK_SDMMC2>,
+			 <&cru SCLK_SDMMC2_DRV>, <&cru SCLK_SDMMC2_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC2>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc0: mmc at fe2b0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2b0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC0>, <&cru CLK_SDMMC0>,
+			 <&cru SCLK_SDMMC0_DRV>, <&cru SCLK_SDMMC0_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC0>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdmmc1: mmc at fe2c0000 {
+		compatible = "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc";
+		reg = <0x0 0xfe2c0000 0x0 0x4000>;
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru HCLK_SDMMC1>, <&cru CLK_SDMMC1>,
+			 <&cru SCLK_SDMMC1_DRV>, <&cru SCLK_SDMMC1_SAMPLE>;
+		clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
+		fifo-depth = <0x100>;
+		max-frequency = <150000000>;
+		resets = <&cru SRST_SDMMC1>;
+		reset-names = "reset";
+		status = "disabled";
+	};
+
+	sdhci: mmc at fe310000 {
+		compatible = "rockchip,rk3568-dwcmshc";
+		reg = <0x0 0xfe310000 0x0 0x10000>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+		assigned-clocks = <&cru BCLK_EMMC>, <&cru TCLK_EMMC>;
+		assigned-clock-rates = <200000000>, <24000000>;
+		clocks = <&cru CCLK_EMMC>, <&cru HCLK_EMMC>,
+			 <&cru ACLK_EMMC>, <&cru BCLK_EMMC>,
+			 <&cru TCLK_EMMC>;
+		clock-names = "core", "bus", "axi", "block", "timer";
+		status = "disabled";
+	};
+
+	dmac0: dmac at fe530000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe530000 0x0 0x4000>;
+		interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	dmac1: dmac at fe550000 {
+		compatible = "arm,pl330", "arm,primecell";
+		reg = <0x0 0xfe550000 0x0 0x4000>;
+		interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+		arm,pl330-periph-burst;
+		clocks = <&cru ACLK_BUS>;
+		clock-names = "apb_pclk";
+		#dma-cells = <1>;
+	};
+
+	i2c1: i2c at fe5a0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C1>, <&cru PCLK_I2C1>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c1_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at fe5b0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5b0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C2>, <&cru PCLK_I2C2>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c2m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at fe5c0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5c0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C3>, <&cru PCLK_I2C3>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c3m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at fe5d0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5d0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C4>, <&cru PCLK_I2C4>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c4m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at fe5e0000 {
+		compatible = "rockchip,rk3568-i2c", "rockchip,rk3399-i2c";
+		reg = <0x0 0xfe5e0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+		clock-names = "i2c", "pclk";
+		pinctrl-0 = <&i2c5m0_xfer>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	wdt: watchdog at fe600000 {
+		compatible = "rockchip,rk3568-wdt", "snps,dw-wdt";
+		reg = <0x0 0xfe600000 0x0 0x100>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru TCLK_WDT_NS>, <&cru PCLK_WDT_NS>;
+		clock-names = "tclk", "pclk";
+	};
+
+	uart1: serial at fe650000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe650000 0x0 0x100>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 2>, <&dmac0 3>;
+		pinctrl-0 = <&uart1m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart2: serial at fe660000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe660000 0x0 0x100>;
+		interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 4>, <&dmac0 5>;
+		pinctrl-0 = <&uart2m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart3: serial at fe670000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe670000 0x0 0x100>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 6>, <&dmac0 7>;
+		pinctrl-0 = <&uart3m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart4: serial at fe680000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe680000 0x0 0x100>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 8>, <&dmac0 9>;
+		pinctrl-0 = <&uart4m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart5: serial at fe690000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe690000 0x0 0x100>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART5>, <&cru PCLK_UART5>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 10>, <&dmac0 11>;
+		pinctrl-0 = <&uart5m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart6: serial at fe6a0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6a0000 0x0 0x100>;
+		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART6>, <&cru PCLK_UART6>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 12>, <&dmac0 13>;
+		pinctrl-0 = <&uart6m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart7: serial at fe6b0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6b0000 0x0 0x100>;
+		interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART7>, <&cru PCLK_UART7>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 14>, <&dmac0 15>;
+		pinctrl-0 = <&uart7m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart8: serial at fe6c0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6c0000 0x0 0x100>;
+		interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART8>, <&cru PCLK_UART8>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 16>, <&dmac0 17>;
+		pinctrl-0 = <&uart8m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	uart9: serial at fe6d0000 {
+		compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xfe6d0000 0x0 0x100>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_UART9>, <&cru PCLK_UART9>;
+		clock-names = "baudclk", "apb_pclk";
+		dmas = <&dmac0 18>, <&dmac0 19>;
+		pinctrl-0 = <&uart9m0_xfer>;
+		pinctrl-names = "default";
+		reg-io-width = <4>;
+		reg-shift = <2>;
+		status = "disabled";
+	};
+
+	pwm4: pwm at fe6e0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm4_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm5: pwm at fe6e0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm5_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm6: pwm at fe6e0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm6_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm7: pwm at fe6e0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6e0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM1>, <&cru PCLK_PWM1>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm7_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm8: pwm at fe6f0000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0000 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm8m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm9: pwm at fe6f0010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0010 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm9m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm10: pwm at fe6f0020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0020 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm10m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm11: pwm at fe6f0030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe6f0030 0x0 0x10>;
+		clocks = <&cru CLK_PWM2>, <&cru PCLK_PWM2>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm11m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm12: pwm at fe700000 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700000 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm12m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm13: pwm at fe700010 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700010 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm13m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm14: pwm at fe700020 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700020 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm14m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pwm15: pwm at fe700030 {
+		compatible = "rockchip,rk3568-pwm", "rockchip,rk3328-pwm";
+		reg = <0x0 0xfe700030 0x0 0x10>;
+		clocks = <&cru CLK_PWM3>, <&cru PCLK_PWM3>;
+		clock-names = "pwm", "pclk";
+		pinctrl-0 = <&pwm15m0_pins>;
+		pinctrl-names = "active";
+		#pwm-cells = <3>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3568-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		gpio0: gpio at fdd60000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfdd60000 0x0 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pmucru PCLK_GPIO0>, <&pmucru DBCLK_GPIO0>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio1: gpio at fe740000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe740000 0x0 0x100>;
+			interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO1>, <&cru DBCLK_GPIO1>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio2: gpio at fe750000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe750000 0x0 0x100>;
+			interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO2>, <&cru DBCLK_GPIO2>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio3: gpio at fe760000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe760000 0x0 0x100>;
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO3>, <&cru DBCLK_GPIO3>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
+		gpio4: gpio at fe770000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xfe770000 0x0 0x100>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cru PCLK_GPIO4>, <&cru DBCLK_GPIO4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+};
+
+#include "rk3568-pinctrl.dtsi"
-- 
2.17.1





From cl at rock-chips.com  Thu Apr 29 09:13:58 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Thu, 29 Apr 2021 16:13:58 +0800
Subject: [PATCH v4 10/10] arm64: dts: rockchip: add basic dts for RK3568 EVB
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210429081358.18057-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
add uart/emmc/i2c/rk809 node for basic function.

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/arm/rockchip.yaml     |  5 ++
 arch/arm64/boot/dts/rockchip/Makefile         |  1 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 79 +++++++++++++++++++
 3 files changed, 85 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 4a6f772c1043..6546b015fc62 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -600,6 +600,11 @@ properties:
           - const: zkmagic,a95x-z2
           - const: rockchip,rk3318
 
+      - description: Rockchip RK3568 Evaluation board
+        items:
+          - const: rockchip,rk3568-evb1-v10
+          - const: rockchip,rk3568
+
 additionalProperties: true
 
 ...
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index c3e00c0e2db7..7fdb41de01ec 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -51,3 +51,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
new file mode 100644
index 000000000000..69786557093d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3568.dtsi"
+
+/ {
+	model = "Rockchip RK3568 EVB1 DDR4 V10 Board";
+	compatible = "rockchip,rk3568-evb1-v10", "rockchip,rk3568";
+
+	chosen: chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		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>;
+	};
+
+	vcc3v3_lcd0_n: vcc3v3-lcd0-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd0_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vcc3v3_lcd1_n: vcc3v3-lcd1-n {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_lcd1_n";
+		regulator-boot-on;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&sdhci {
+	bus-width = <8>;
+	max-frequency = <200000000>;
+	non-removable;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
-- 
2.17.1





From pali at kernel.org  Thu Apr 29 09:36:31 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:31 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 1/6] firmware: turris-mox-rwtm: fix
 reply status decoding function
In-Reply-To: <20210308153703.23097-1-kabel@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
Message-ID: <20210429083636.22560-1-pali@kernel.org>

From: Marek Beh?n <kabel at kernel.org>

The status decoding function mox_get_status() currently contains a dead
code path: if the error status is not MBOX_STS_SUCCESS, it always
returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and
we don't get the actual error code sent by the firmware.

Fix this.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
 drivers/firmware/turris-mox-rwtm.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index 62f0d1a5dd32..f85acdb3130c 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -147,11 +147,14 @@ MOX_ATTR_RO(pubkey, "%s\n", pubkey);
 
 static int mox_get_status(enum mbox_cmd cmd, u32 retval)
 {
-	if (MBOX_STS_CMD(retval) != cmd ||
-	    MBOX_STS_ERROR(retval) != MBOX_STS_SUCCESS)
+	if (MBOX_STS_CMD(retval) != cmd)
 		return -EIO;
 	else if (MBOX_STS_ERROR(retval) == MBOX_STS_FAIL)
 		return -(int)MBOX_STS_VALUE(retval);
+	else if (MBOX_STS_ERROR(retval) == MBOX_STS_BADCMD)
+		return -ENOSYS;
+	else if (MBOX_STS_ERROR(retval) != MBOX_STS_SUCCESS)
+		return -EIO;
 	else
 		return MBOX_STS_VALUE(retval);
 }
-- 
2.20.1



From pali at kernel.org  Thu Apr 29 09:36:32 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:32 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 2/6] firmware: turris-mox-rwtm: report
 failures better
In-Reply-To: <20210429083636.22560-1-pali@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210429083636.22560-1-pali@kernel.org>
Message-ID: <20210429083636.22560-2-pali@kernel.org>

From: Marek Beh?n <kabel at kernel.org>

Report a notice level message if a command is not supported by the rWTM
firmware.

This should not be an error, merely a notice, because the firmware can
be used on non-CZ.NIC boards that do not have manufacturing information
burned.

Signed-off-by: Marek Beh?n <kabel at kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
 drivers/firmware/turris-mox-rwtm.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index f85acdb3130c..d7e3489e4bf2 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -204,11 +204,14 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)
 		return ret;
 
 	ret = mox_get_status(MBOX_CMD_BOARD_INFO, reply->retval);
-	if (ret < 0 && ret != -ENODATA) {
-		return ret;
-	} else if (ret == -ENODATA) {
+	if (ret == -ENODATA) {
 		dev_warn(rwtm->dev,
 			 "Board does not have manufacturing information burned!\n");
+	} else if (ret == -ENOSYS) {
+		dev_notice(rwtm->dev,
+			   "Firmware does not support the BOARD_INFO command\n");
+	} else if (ret < 0) {
+		return ret;
 	} else {
 		rwtm->serial_number = reply->status[1];
 		rwtm->serial_number <<= 32;
@@ -237,10 +240,13 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)
 		return ret;
 
 	ret = mox_get_status(MBOX_CMD_ECDSA_PUB_KEY, reply->retval);
-	if (ret < 0 && ret != -ENODATA) {
-		return ret;
-	} else if (ret == -ENODATA) {
+	if (ret == -ENODATA) {
 		dev_warn(rwtm->dev, "Board has no public key burned!\n");
+	} else if (ret == -ENOSYS) {
+		dev_notice(rwtm->dev,
+			   "Firmware does not support the ECDSA_PUB_KEY command\n");
+	} else if (ret < 0) {
+		return ret;
 	} else {
 		u32 *s = reply->status;
 
-- 
2.20.1



From pali at kernel.org  Thu Apr 29 09:36:34 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:34 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 4/6] firmware: turris-mox-rwtm: show
 message about HWRNG registration
In-Reply-To: <20210429083636.22560-1-pali@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210429083636.22560-1-pali@kernel.org>
Message-ID: <20210429083636.22560-4-pali@kernel.org>

Currently it is hard to determinate if on Armada 3720 device is HWRNG
by running kernel accessible or not. So print information message into
dmesg when HWRNG is available and registration was successful.

Signed-off-by: Pali Roh?r <pali at kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
 drivers/firmware/turris-mox-rwtm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index 3ef9687dddca..1cf4f1087492 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -542,6 +542,8 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)
 		goto free_channel;
 	}
 
+	dev_info(dev, "HWRNG successfully registered\n");
+
 	return 0;
 
 free_channel:
-- 
2.20.1



From pali at kernel.org  Thu Apr 29 09:36:33 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:33 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 3/6] firmware: turris-mox-rwtm: fail
 probing when firmware does not support hwrng
In-Reply-To: <20210429083636.22560-1-pali@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210429083636.22560-1-pali@kernel.org>
Message-ID: <20210429083636.22560-3-pali@kernel.org>

When Marvell's rWTM firmware, which does not support the GET_RANDOM
command, is used, kernel prints an error message
  hwrng: no data available
every 10 seconds.

Fail probing of this driver if the rWTM firmware does not support the
GET_RANDOM command.

This makes it possible to put this driver's compatible into generic
armada-37xx device tree, to be available for other Armada 3720 devices
besides Turris MOX. If they use the rWTM firmware from CZ.NIC, they will
have HWRNG available, and if not, the driver won't be complaining.

Signed-off-by: Pali Roh?r <pali at kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Marek Beh?n <kabel at kernel.org>
---
 drivers/firmware/turris-mox-rwtm.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index d7e3489e4bf2..3ef9687dddca 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -260,6 +260,27 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)
 	return 0;
 }
 
+static int check_get_random_support(struct mox_rwtm *rwtm)
+{
+	struct armada_37xx_rwtm_tx_msg msg;
+	int ret;
+
+	msg.command = MBOX_CMD_GET_RANDOM;
+	msg.args[0] = 1;
+	msg.args[1] = rwtm->buf_phys;
+	msg.args[2] = 4;
+
+	ret = mbox_send_message(rwtm->mbox, &msg);
+	if (ret < 0)
+		return ret;
+
+	ret = wait_for_completion_timeout(&rwtm->cmd_done, HZ / 2);
+	if (ret < 0)
+		return ret;
+
+	return mox_get_status(MBOX_CMD_GET_RANDOM, rwtm->reply.retval);
+}
+
 static int mox_hwrng_read(struct hwrng *rng, void *data, size_t max, bool wait)
 {
 	struct mox_rwtm *rwtm = (struct mox_rwtm *) rng->priv;
@@ -497,6 +518,13 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)
 	if (ret < 0)
 		dev_warn(dev, "Cannot read board information: %i\n", ret);
 
+	ret = check_get_random_support(rwtm);
+	if (ret < 0) {
+		dev_notice(dev,
+			   "Firmware does not support the GET_RANDOM command\n");
+		goto free_channel;
+	}
+
 	rwtm->hwrng.name = DRIVER_NAME "_hwrng";
 	rwtm->hwrng.read = mox_hwrng_read;
 	rwtm->hwrng.priv = (unsigned long) rwtm;
-- 
2.20.1



From pali at kernel.org  Thu Apr 29 09:36:35 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:35 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 5/6] firmware: turris-mox-rwtm: add
 marvell, armada-3700-rwtm-firmware compatible string
In-Reply-To: <20210429083636.22560-1-pali@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210429083636.22560-1-pali@kernel.org>
Message-ID: <20210429083636.22560-5-pali@kernel.org>

Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for
this driver, since it can also be used on other Armada 3720 devices.

Current compatible string 'cznic,turris-mox-rwtm' is kept for backward
compatibility.

Signed-off-by: Pali Roh?r <pali at kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")

---
We are also planning to work on extending this driver to support
accessing OTP, which will also work with Marvell's default WTMI
firmware.
---
 drivers/firmware/turris-mox-rwtm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/turris-mox-rwtm.c b/drivers/firmware/turris-mox-rwtm.c
index 1cf4f1087492..c2d34dc8ba46 100644
--- a/drivers/firmware/turris-mox-rwtm.c
+++ b/drivers/firmware/turris-mox-rwtm.c
@@ -569,6 +569,7 @@ static int turris_mox_rwtm_remove(struct platform_device *pdev)
 
 static const struct of_device_id turris_mox_rwtm_match[] = {
 	{ .compatible = "cznic,turris-mox-rwtm", },
+	{ .compatible = "marvell,armada-3700-rwtm-firmware", },
 	{ },
 };
 
-- 
2.20.1



From pali at kernel.org  Thu Apr 29 09:36:36 2021
From: pali at kernel.org (=?UTF-8?q?Pali=20Roh=C3=A1r?=)
Date: Thu, 29 Apr 2021 10:36:36 +0200
Subject: [PATCH v2 mvebu + mvebu/dt64 6/6] arm64: dts: marvell: armada-37xx:
 move firmware node to generic dtsi file
In-Reply-To: <20210429083636.22560-1-pali@kernel.org>
References: <20210308153703.23097-1-kabel@kernel.org>
 <20210429083636.22560-1-pali@kernel.org>
Message-ID: <20210429083636.22560-6-pali@kernel.org>

Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.

The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.

This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.

Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.

Signed-off-by: Pali Roh?r <pali at kernel.org>
Signed-off-by: Marek Beh?n <kabel at kernel.org>
Cc: <stable at vger.kernel.org> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
 arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 8 --------
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi           | 8 ++++++++
 2 files changed, 8 insertions(+), 8 deletions(-)

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 0753cc489638..ebb0ddf8d306 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -107,14 +107,6 @@
 		/* enabled by U-Boot if SFP module is present */
 		status = "disabled";
 	};
-
-	firmware {
-		turris-mox-rwtm {
-			compatible = "cznic,turris-mox-rwtm";
-			mboxes = <&rwtm 0>;
-			status = "okay";
-		};
-	};
 };
 
 &i2c0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 1b7f43e27589..847a2d12a4be 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -505,4 +505,12 @@
 			};
 		};
 	};
+
+	firmware {
+		armada-3700-rwtm {
+			compatible = "marvell,armada-3700-rwtm-firmware";
+			mboxes = <&rwtm 0>;
+			status = "okay";
+		};
+	};
 };
-- 
2.20.1



From a.fatoum at pengutronix.de  Thu Apr 29 09:39:14 2021
From: a.fatoum at pengutronix.de (Ahmad Fatoum)
Date: Thu, 29 Apr 2021 10:39:14 +0200
Subject: [PATCH 15/16] soc: imx: gpcv2: support reset defer probe
In-Reply-To: <20210429073050.21039-16-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-16-peng.fan@oss.nxp.com>
Message-ID: <bc5793e4-5d43-1ca9-7a12-9b58806c1856@pengutronix.de>

Hi,

On 29.04.21 09:30, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> When gpcv2 probe, the reset controller might not be ready, so we need
> defer probe
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  drivers/soc/imx/gpcv2.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 072f519462a5..49dd137f6b94 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -784,9 +784,12 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
>  				     "Failed to get domain's clocks\n");
>  
>  	domain->reset = devm_reset_control_array_get_optional_exclusive(domain->dev);
> -	if (IS_ERR(domain->reset))
> +	if (IS_ERR(domain->reset)) {
> +		if (PTR_ERR(domain->reset) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
>  		return dev_err_probe(domain->dev, PTR_ERR(domain->reset),
>  				     "Failed to get domain's resets\n");

dev_err_probe already propagates the error code in its second argument.
Seems to me this patch's only effect is to disable deferred probe reason tracking?

> +	}
>  
>  	pm_runtime_enable(domain->dev);
>  
> 

-- 
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 mchehab at kernel.org  Thu Apr 29 09:44:41 2021
From: mchehab at kernel.org (Mauro Carvalho Chehab)
Date: Thu, 29 Apr 2021 10:44:41 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
Message-ID: <20210429104441.3e85d81b@coco.lan>

Em Thu, 29 Apr 2021 09:49:03 +0200
Marco Felsch <m.felsch at pengutronix.de> escreveu:

> Hi Laurent,
> 
> On 21-04-29 04:51, Laurent Pinchart wrote:
> > Hi Marco,
> > 
> > Thank you for the patch.
> > 
> > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:  
> > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > with the interleaved IR pixels looks like:
> > > 
> > >         |  G |  R |  G |  B | ...
> > >         +----+----+----+----+---
> > >         | IR |  G | IR |  G | ...
> > >         +----+----+----+----+---
> > >         |  G |  B |  G |  R | ...
> > >         +----+----+----+----+---
> > >         | IR |  G | IR |  G | ...
> > >         +----+----+----+----+---
> > >         | .. | .. | .. | .. | ..
> > > 
> > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf  
> > 
> > I think we're reaching a limit of the media bus codes model here, due to
> > a historical mistake. The four possible Bayer patterns, times the
> > different number of bits per pixel, creates a lot of media bus codes,
> > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > have to support them all.  
> 
> That's correct but it is not bayer related.

Err... there are two separate things here:

1) for the uAPI part, we're not even close to the limit of a 4-bytes
   fourcc;

2) the kAPI is currently sharing the same fourcc from the uAPI,
   because it is a lot simpler than doing something different.

Yet, nothing prevents that the kAPI could be improved in order to
better describe each format, provided that:

1. there will be a 1:1 mapping with the uAPI.
   In other words, it would be possible to write a function that
   would convert a "struct foo" from/to a 32-bits fourcc;

2. such new kAPI should be optional, as usually only drivers
   for hardware with ISP (plus the UVC driver) would be flexible
   enough to allow random formats. For the rest, the bridges are
   typically limited to support only a few formats, so it doesn't
   make sense to modify existing drivers to use such new kAPI.

Ok, someone has to come up with a proposal about what a "struct foo"
would contain. On a real quick brainstorm, something like this could
be a start:

enum v4l2_pixformat_type {
	VIDEO_PIXFORMAT_RGB,
	VIDEO_PIXFORMAT_YUV,
	VIDEO_PIXFORMAT_COMPRESSED,
	VIDEO_PIXFORMAT_BAYER_RGB,
	VIDEO_PIXFORMAT_BAYER_RGB_IR,
};

struct v4l2_pixformat_desc {
	enum v4l2_pixformat_type	pixfmt_type;
	bool				is_packed;
	int				bits_per_component;

	union {
		enum v4l2_pixformat_rgb_order		rgb_order;
		enum v4l2_pixformat_yuv_order		yuv_order;
		enum v4l2_pixformat_bayer_rgb_order	bayer_rgb_order;
		enum v4l2_pixformat_bayer_rgb_ir_order	bayer_rgb_ir_order;
		enum v4l2_pixformat_compress_type	compress_type;
	};
	...
};

Btw, I remember someone suggested a model similar to that in the past,
shared with DRM. Well, I don't think it would be easy to share
an internal subsystem-specific kAPI like that with other subsystems,
as this is the kind of thing that people will change from time to time,
and coordinating something like that can be painful, but we can try
to fork the model applied to DRM on media. For instance, I doubt that
Bayer RGB + IR would make any sense for DRM drivers.

Thanks,
Mauro


From michael.wei.hong.sit at intel.com  Thu Apr 29 09:46:34 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu, 29 Apr 2021 16:46:34 +0800
Subject: [PATCH net-next 0/2] Introducing support for DWC xpcs Energy
 Efficient Ethernet
Message-ID: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>

The goal of this patch set is to enable EEE in the xpcs so that when
EEE is enabled, the MAC-->xpcs-->PHY have all the EEE related
configurations enabled.

Patch 1 adds the functions to enable EEE in the xpcs and sets it to
transparent mode.
Patch 2 adds the callbacks to configure the xpcs EEE mode.

The results are tested by checking the lpi counters of the tx and rx
path of the interface. When EEE is enabled, the lpi counters should
increament as it enters and exits lpi states.

host at EHL$ ethtool --show-eee enp0s30f4
EEE Settings for enp0s30f4:
        EEE status: disabled
        Tx LPI: disabled
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  Not reported
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full
host at EHL$ ethtool -S enp0s30f4 | grep lpi
     irq_tx_path_in_lpi_mode_n: 0
     irq_tx_path_exit_lpi_mode_n: 0
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
host at EHL$ ethtool --set-eee enp0s30f4 eee on
host at EHL$ [  110.265154] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Down
[  112.315155] intel-eth-pci 0000:00:1e.4 enp0s30f4: Link is Up - 1Gbps/Full - flow control off
[  112.324612] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s30f4: link becomes ready
host at EHL$ ethtool --show-eee enp0s30f4
EEE Settings for enp0s30f4:
        EEE status: enabled - active
        Tx LPI: 1000000 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full
host at EHL$ ethtool -S enp0s30f4 | grep lpi
     irq_tx_path_in_lpi_mode_n: 6
     irq_tx_path_exit_lpi_mode_n: 5
     irq_rx_path_in_lpi_mode_n: 7
     irq_rx_path_exit_lpi_mode_n: 6
host at EHL$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.510 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.489 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.484 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.504 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.466 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.529 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.519 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.518 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.501 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9216ms
rtt min/avg/max/mdev = 0.466/0.553/1.018/0.155 ms
host at EHL$ ethtool -S enp0s30f4 | grep lpi
     irq_tx_path_in_lpi_mode_n: 22
     irq_tx_path_exit_lpi_mode_n: 21
     irq_rx_path_in_lpi_mode_n: 21
     irq_rx_path_exit_lpi_mode_n: 20

Michael Sit Wei Hong (2):
  net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet
  net: stmmac: Add callbacks for DWC xpcs Energy Efficient Ethernet

 .../net/ethernet/stmicro/stmmac/dwmac-intel.c | 11 ++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h    |  2 +
 .../ethernet/stmicro/stmmac/stmmac_ethtool.c  |  6 +++
 drivers/net/pcs/pcs-xpcs.c                    | 51 +++++++++++++++++++
 include/linux/pcs/pcs-xpcs.h                  |  2 +
 include/linux/stmmac.h                        |  1 +
 6 files changed, 73 insertions(+)

-- 
2.17.1



From michael.wei.hong.sit at intel.com  Thu Apr 29 09:46:35 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu, 29 Apr 2021 16:46:35 +0800
Subject: [PATCH net-next 1/2] net: pcs: Introducing support for DWC xpcs
 Energy Efficient Ethernet
In-Reply-To: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
References: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210429084636.24752-2-michael.wei.hong.sit@intel.com>

Add DWC xpcs EEE support callbacks.The callback function is used to
set EEE registers on xpcs.

xpcs transparent mode is enabled to allow PHY to detect MAC EEE status.

Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 drivers/net/pcs/pcs-xpcs.c   | 51 ++++++++++++++++++++++++++++++++++++
 include/linux/pcs/pcs-xpcs.h |  2 ++
 2 files changed, 53 insertions(+)

diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 944ba105cac1..aa985a5aae8d 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -63,6 +63,9 @@
 #define DW_VR_MII_DIG_CTRL1		0x8000
 #define DW_VR_MII_AN_CTRL		0x8001
 #define DW_VR_MII_AN_INTR_STS		0x8002
+/* EEE Mode Control Register */
+#define DW_VR_MII_EEE_MCTRL0		0x8006
+#define DW_VR_MII_EEE_MCTRL1		0x800b
 
 /* VR_MII_DIG_CTRL1 */
 #define DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW		BIT(9)
@@ -86,6 +89,20 @@
 #define DW_VR_MII_C37_ANSGM_SP_1000		0x2
 #define DW_VR_MII_C37_ANSGM_SP_LNKSTS		BIT(4)
 
+/* VR MII EEE Control 0 defines */
+#define DW_VR_MII_EEE_LTX_EN		BIT(0)  /* LPI Tx Enable */
+#define DW_VR_MII_EEE_LRX_EN		BIT(1)  /* LPI Rx Enable */
+#define DW_VR_MII_EEE_TX_QUIET_EN		BIT(2)  /* Tx Quiet Enable */
+#define DW_VR_MII_EEE_RX_QUIET_EN		BIT(3)  /* Rx Quiet Enable */
+#define DW_VR_MII_EEE_TX_EN_CTRL		BIT(4)  /* Tx Control Enable */
+#define DW_VR_MII_EEE_RX_EN_CTRL		BIT(7)  /* Rx Control Enable */
+
+#define DW_VR_MII_EEE_MULT_FACT_100NS_SHIFT	8
+#define DW_VR_MII_EEE_MULT_FACT_100NS		GENMASK(11, 8)
+
+/* VR MII EEE Control 1 defines */
+#define DW_VR_MII_EEE_TRN_LPI		BIT(0)	/* Transparent Mode Enable */
+
 static const int xpcs_usxgmii_features[] = {
 	ETHTOOL_LINK_MODE_Pause_BIT,
 	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
@@ -650,6 +667,39 @@ static int xpcs_validate(struct mdio_xpcs_args *xpcs,
 	return 0;
 }
 
+static int xpcs_config_eee(struct mdio_xpcs_args *xpcs, int mult_fact_100ns,
+			   int enable)
+{
+	int ret;
+
+	if (enable) {
+	/* Enable EEE */
+		ret = DW_VR_MII_EEE_LTX_EN | DW_VR_MII_EEE_LRX_EN |
+		      DW_VR_MII_EEE_TX_QUIET_EN | DW_VR_MII_EEE_RX_QUIET_EN |
+		      DW_VR_MII_EEE_TX_EN_CTRL | DW_VR_MII_EEE_RX_EN_CTRL |
+		      mult_fact_100ns << DW_VR_MII_EEE_MULT_FACT_100NS_SHIFT;
+	} else {
+		ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_EEE_MCTRL0);
+		if (ret < 0)
+			return ret;
+		ret &= ~(DW_VR_MII_EEE_LTX_EN | DW_VR_MII_EEE_LRX_EN |
+		       DW_VR_MII_EEE_TX_QUIET_EN | DW_VR_MII_EEE_RX_QUIET_EN |
+		       DW_VR_MII_EEE_TX_EN_CTRL | DW_VR_MII_EEE_RX_EN_CTRL |
+		       DW_VR_MII_EEE_MULT_FACT_100NS);
+	}
+
+	ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_EEE_MCTRL0, ret);
+	if (ret < 0)
+		return ret;
+
+	ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_EEE_MCTRL1);
+	if (ret < 0)
+		return ret;
+
+	ret |= DW_VR_MII_EEE_TRN_LPI;
+	return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_EEE_MCTRL1, ret);
+}
+
 static int xpcs_config_aneg_c37_sgmii(struct mdio_xpcs_args *xpcs)
 {
 	int ret;
@@ -908,6 +958,7 @@ static struct mdio_xpcs_ops xpcs_ops = {
 	.get_state = xpcs_get_state,
 	.link_up = xpcs_link_up,
 	.probe = xpcs_probe,
+	.config_eee = xpcs_config_eee,
 };
 
 struct mdio_xpcs_ops *mdio_xpcs_get_ops(void)
diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h
index 2cb5188a7ef1..5938ced805f4 100644
--- a/include/linux/pcs/pcs-xpcs.h
+++ b/include/linux/pcs/pcs-xpcs.h
@@ -32,6 +32,8 @@ struct mdio_xpcs_ops {
 	int (*link_up)(struct mdio_xpcs_args *xpcs, int speed,
 		       phy_interface_t interface);
 	int (*probe)(struct mdio_xpcs_args *xpcs, phy_interface_t interface);
+	int (*config_eee)(struct mdio_xpcs_args *xpcs, int mult_fact_100ns,
+			  int enable);
 };
 
 #if IS_ENABLED(CONFIG_PCS_XPCS)
-- 
2.17.1



From michael.wei.hong.sit at intel.com  Thu Apr 29 09:46:36 2021
From: michael.wei.hong.sit at intel.com (Michael Sit Wei Hong)
Date: Thu, 29 Apr 2021 16:46:36 +0800
Subject: [PATCH net-next 2/2] net: stmmac: Add callbacks for DWC xpcs Energy
 Efficient Ethernet
In-Reply-To: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
References: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210429084636.24752-3-michael.wei.hong.sit@intel.com>

Link xpcs callback functions for MAC to configure the xpcs EEE feature.

The clk_eee frequency is used to calculate the MULT_FACT_100NS. This is
to adjust the clock tic closer to 100ns.

Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c    | 11 +++++++++++
 drivers/net/ethernet/stmicro/stmmac/hwif.h           |  2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c |  6 ++++++
 include/linux/stmmac.h                               |  1 +
 4 files changed, 20 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 80728a4c0e3f..e36a8cc59ad0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -429,6 +429,17 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
 	plat->force_sf_dma_mode = 0;
 	plat->tso_en = 1;
 
+	/* Multiplying factor to the clk_eee_i clock time
+	 * period to make it closer to 100 ns. This value
+	 * should be programmed such that the clk_eee_time_period *
+	 * (MULT_FACT_100NS + 1) should be within 80 ns to 120 ns
+	 * clk_eee frequency is 19.2Mhz
+	 * clk_eee_time_period is 52ns
+	 * 52ns * (1 + 1) = 104ns
+	 * MULT_FACT_100NS = 1
+	 */
+	plat->mult_fact_100ns = 1;
+
 	plat->rx_sched_algorithm = MTL_RX_ALGORITHM_SP;
 
 	for (i = 0; i < plat->rx_queues_to_use; i++) {
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2cc91759b91f..c678d7b826a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -624,6 +624,8 @@ struct stmmac_mmc_ops {
 	stmmac_do_callback(__priv, xpcs, link_up, __args)
 #define stmmac_xpcs_probe(__priv, __args...) \
 	stmmac_do_callback(__priv, xpcs, probe, __args)
+#define stmmac_xpcs_config_eee(__priv, __args...) \
+	stmmac_do_callback(__priv, xpcs, config_eee, __args)
 
 struct stmmac_regs_off {
 	u32 ptp_off;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 61b11639ee0c..1f6d749fd9a3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -720,6 +720,12 @@ static int stmmac_ethtool_op_set_eee(struct net_device *dev,
 		netdev_warn(priv->dev,
 			    "Setting EEE tx-lpi is not supported\n");
 
+	ret = stmmac_xpcs_config_eee(priv, &priv->hw->xpcs_args,
+				     priv->plat->mult_fact_100ns,
+				     edata->eee_enabled);
+	if (ret)
+		return ret;
+
 	if (!edata->eee_enabled)
 		stmmac_disable_eee_mode(priv);
 
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 0db36360ef21..e14a12df381b 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -223,6 +223,7 @@ struct plat_stmmacenet_data {
 	struct clk *clk_ptp_ref;
 	unsigned int clk_ptp_rate;
 	unsigned int clk_ref_rate;
+	unsigned int mult_fact_100ns;
 	s32 ptp_max_adj;
 	struct reset_control *stmmac_rst;
 	struct stmmac_axi *axi;
-- 
2.17.1



From michael at walle.cc  Thu Apr 29 10:05:20 2021
From: michael at walle.cc (Michael Walle)
Date: Thu, 29 Apr 2021 11:05:20 +0200
Subject: [PATCH net v2 1/2] MAINTAINERS: remove Wingman Kwok
Message-ID: <20210429090521.554-1-michael@walle.cc>

His email bounces with permanent error "550 Invalid recipient". His last
email on the LKML was from 2015-10-22 on the LKML.

Signed-off-by: Michael Walle <michael at walle.cc>
---
changes since v1:
 - rebased to net

 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 933a6f3c2369..04f4a2116b35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17975,7 +17975,6 @@ F:	drivers/regulator/lp8788-*.c
 F:	include/linux/mfd/lp8788*.h
 
 TI NETCP ETHERNET DRIVER
-M:	Wingman Kwok <w-kwok2 at ti.com>
 M:	Murali Karicheri <m-karicheri2 at ti.com>
 L:	netdev at vger.kernel.org
 S:	Maintained
-- 
2.20.1



From michael at walle.cc  Thu Apr 29 10:05:21 2021
From: michael at walle.cc (Michael Walle)
Date: Thu, 29 Apr 2021 11:05:21 +0200
Subject: [PATCH net v2 2/2] MAINTAINERS: move Murali Karicheri to credits
In-Reply-To: <20210429090521.554-1-michael@walle.cc>
References: <20210429090521.554-1-michael@walle.cc>
Message-ID: <20210429090521.554-2-michael@walle.cc>

His email bounces with permanent error "550 Invalid recipient". His last
email was from 2020-09-09 on the LKML and he seems to have left TI.

Signed-off-by: Michael Walle <michael at walle.cc>
---
changes since v1:
 - rebased to net

 CREDITS     |  5 +++++
 MAINTAINERS | 13 -------------
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/CREDITS b/CREDITS
index cef83b958cbe..80d096dbf262 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1874,6 +1874,11 @@ S: Krosenska' 543
 S: 181 00 Praha 8
 S: Czech Republic
 
+N: Murali Karicheri
+E: m-karicheri2 at ti.com
+D: Keystone NetCP driver
+D: Keystone PCIe host controller driver
+
 N: Jan "Yenya" Kasprzak
 E: kas at fi.muni.cz
 D: Author of the COSA/SRP sync serial board driver.
diff --git a/MAINTAINERS b/MAINTAINERS
index 04f4a2116b35..e264e63f09c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13780,13 +13780,6 @@ F:	Documentation/devicetree/bindings/pci/ti-pci.txt
 F:	drivers/pci/controller/cadence/pci-j721e.c
 F:	drivers/pci/controller/dwc/pci-dra7xx.c
 
-PCI DRIVER FOR TI KEYSTONE
-M:	Murali Karicheri <m-karicheri2 at ti.com>
-L:	linux-pci at vger.kernel.org
-L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
-S:	Maintained
-F:	drivers/pci/controller/dwc/pci-keystone.c
-
 PCI DRIVER FOR V3 SEMICONDUCTOR V360EPC
 M:	Linus Walleij <linus.walleij at linaro.org>
 L:	linux-pci at vger.kernel.org
@@ -17974,12 +17967,6 @@ F:	drivers/power/supply/lp8788-charger.c
 F:	drivers/regulator/lp8788-*.c
 F:	include/linux/mfd/lp8788*.h
 
-TI NETCP ETHERNET DRIVER
-M:	Murali Karicheri <m-karicheri2 at ti.com>
-L:	netdev at vger.kernel.org
-S:	Maintained
-F:	drivers/net/ethernet/ti/netcp*
-
 TI PCM3060 ASoC CODEC DRIVER
 M:	Kirill Marinushkin <kmarinushkin at birdec.com>
 L:	alsa-devel at alsa-project.org (moderated for non-subscribers)
-- 
2.20.1



From morbo at google.com  Thu Apr 29 10:23:41 2021
From: morbo at google.com (Bill Wendling)
Date: Thu, 29 Apr 2021 02:23:41 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210429075454.GQ9028@arm.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
 <20210429075454.GQ9028@arm.com>
Message-ID: <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>

On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
> The 04/28/2021 12:31, Bill Wendling wrote:
> > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo at google.com> wrote:
> > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> > > >
> > > > > > Since the note.gnu.property section in the vDSO is not checked by the
> > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> > > >
> > > > > Can we not instead fix the linker script to preserve the
> > > > > .note.gnu.property, correctly aligned? It doesn't take much space and
> > > > > while we don't use it now, it has the BTI information about the binary.
> > > >
> > > > > Cc'ing a few others who were involved in the BTI support.
> > > >
> > > > Not just BTI, we also flag PAC usage in there too and could add other
> > > > extensions going forwards.  While the note isn't actively used by
> > > > anything right now due to the kernel mapping the vDSO prior to userspace
> > > > starting it is part of the ABI and something could end up wanting to use
> > > > it and getting confused if it's not there.  It would be much better to
> > > > fix the alignment issue.
> > >
> > > If there's only one of the 8-byte aligned sections guaranteed, we
> > > could place it first in the note. Otherwise, we will have to change
> > > the alignment of the note (or somehow merge multiple notes).
> > >
> > I should have clarified that there's only one *entry* in the
> > .note.gnu.properties section, and if not then is it possible to merge
> > multiple entries into one. (Excuse my ignorance if this is already the
> > case.)
>
> .note.gnu.property should go to PT_GNU_PROPERTY and it
> should be merged following rules specified in
> https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
> and
> https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property
>
> it may also be covered by a (8byte aligned) PT_NOTE, but
> that's not a requirement on aarch64 (x86 requires it for
> compatibility with old dynamic linker, but since the vdso
> is handled specially that may not be relevant either).
>
> i don't know how this works in linker scripts.

This is a potential patch. I haven't had time to test it though.
However, it does appear to format the section in the "expected" way,
so one's able to grab the build IDs. Thoughts?

$ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so

./arch/arm64/kernel/vdso/vdso.so:     file format elf64-little

Contents of section .note:
 0288 04000000 10000000 05000000 474e5500  ............GNU.
 0298 000000c0 04000000 03000000 00000000  ................
 02a8 06000000 04000000 00000000 4c696e75  ............Linu
 02b8 78000000 000a0500 06000000 01000000  x...............
 02c8 00010000 4c696e75 78000000 00000000  ....Linux.......
 02d8 04000000 14000000 03000000 474e5500  ............GNU.
 02e8 958db149 af5156cb 45309896 7a53ae8a  ...I.QV.E0..zS..
 02f8 ef34e95c                             .4.\

diff --git a/arch/arm64/kernel/vdso/vdso.lds.S
b/arch/arm64/kernel/vdso/vdso.lds.S
index d808ad31e01f..d51e886c6223 100644
--- a/arch/arm64/kernel/vdso/vdso.lds.S
+++ b/arch/arm64/kernel/vdso/vdso.lds.S
@@ -31,7 +31,13 @@ SECTIONS
        .gnu.version_d  : { *(.gnu.version_d) }
        .gnu.version_r  : { *(.gnu.version_r) }

-       .note           : { *(.note.*) }                :text   :note
+       /*
+        * Add the .note.gnu.property section first, as it's aligned to
+        * 8-bytes, while other notes are aligned to 4-bytes.
+        */
+       . = ALIGN(8);
+
+       .note           : { *(.note.gnu.property) *(.note.*) }  :text   :note

        . = ALIGN(16);


From andy.shevchenko at gmail.com  Thu Apr 29 10:32:17 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 29 Apr 2021 12:32:17 +0300
Subject: [PATCH] rtnetlink: add rtnl_lock debug log
In-Reply-To: <20210429070237.3012-1-rocco.yue@mediatek.com>
References: <20210429070237.3012-1-rocco.yue@mediatek.com>
Message-ID: <CAHp75Vc=GMv5dJ1dJYr=B3W6c+nuPCfXa4wxLJOYPTuqrMskFg@mail.gmail.com>

On Thu, Apr 29, 2021 at 10:21 AM Rocco Yue <rocco.yue at mediatek.com> wrote:
>
> We often encounter system hangs caused by certain processes
> holding rtnl_lock for a long time. Even if there is a lock
> detection mechanism in Linux, it is a bit troublesome and
> affects the system performance. We hope to add a lightweight
> debugging mechanism for detecting rtnl_lock.
>
> Up to now, we have discovered and solved some potential bugs
> through such debug information of this lightweight rtnl_lock,
> which is helpful for us.
>
> When you say Y for RTNL_LOCK_DEBUG, then the kernel will detect
> if any function hold rtnl_lock too long and some key information
> will be printed to help identify the issue point.
>
> i.e: from the following logs, we can clear know that the pid=5546

clearly

> RfxSender_4 process hold rtnl_lock for a long time, causing the

holds

> system hang. And we can also speculate that the delay operation

to hang

> may be performed in devinet_ioctl(), resulting in rtnl_lock was
> not released in time.
>
> <6>[  141.151364] ----------- rtnl_print_btrace start -----------

Can you, please, shrink this to the point?

> <6>[  141.152079] RfxSender_4[5546][R] hold rtnl_lock more than 2 sec,
> start time: 139129481562
> <4>[  141.153114]  rtnl_lock+0x88/0xfc
> <4>[  141.153523]  devinet_ioctl+0x190/0x1268
> <4>[  141.154007]  inet_ioctl+0x108/0x1f4
> <4>[  141.154449]  sock_do_ioctl+0x88/0x200
> <4>[  141.154911]  sock_ioctl+0x4b0/0x884
> <4>[  141.155367]  do_vfs_ioctl+0x6b0/0xcc4
> <4>[  141.155830]  __arm64_sys_ioctl+0xc0/0xec
> <4>[  141.156326]  el0_svc_common+0x130/0x2c0
> <4>[  141.156810]  el0_svc_handler+0xd0/0xe0
> <4>[  141.157283]  el0_svc+0x8/0xc
> <4>[  141.157646] Call trace:
> <4>[  141.157956]  dump_backtrace+0x0/0x240
> <4>[  141.158418]  show_stack+0x18/0x24
> <4>[  141.158836]  rtnl_print_btrace+0x138/0x1cc
> <4>[  141.159362]  call_timer_fn+0x120/0x47c
> <4>[  141.159834]  expire_timers+0x28c/0x420
> <4>[  141.160306]  __run_timers+0x3d0/0x494
> <4>[  141.160768]  run_timer_softirq+0x24/0x48
> <4>[  141.161262]  __do_softirq+0x26c/0x968
> <4>[  141.161725]  irq_exit+0x1f8/0x2b4
> <4>[  141.162145]  __handle_domain_irq+0xdc/0x15c
> <4>[  141.162672]  gic_handle_irq+0xe4/0x188
> <4>[  141.163144]  el1_irq+0x104/0x200
> <4>[  141.163559]  __const_udelay+0x118/0x1b0
> <4>[  141.164044]  devinet_ioctl+0x1a0/0x1268
> <4>[  141.164527]  inet_ioctl+0x108/0x1f4
> <4>[  141.164968]  sock_do_ioctl+0x88/0x200
> <4>[  141.165428]  sock_ioctl+0x4b0/0x884
> <4>[  141.165868]  do_vfs_ioctl+0x6b0/0xcc4
> <4>[  141.166330]  __arm64_sys_ioctl+0xc0/0xec
> <4>[  141.166825]  el0_svc_common+0x130/0x2c0
> <4>[  141.167308]  el0_svc_handler+0xd0/0xe0
> <4>[  141.167786]  el0_svc+0x8/0xc
> <6>[  141.168153] ------------ rtnl_print_btrace end -----------
>
> <6>[  147.321389] rtnl_lock is held by [5546] from
> [139129481562] to [147321378812]


...

> +static struct rtnl_debug_btrace_t rtnl_instance = {
> +       .task           = NULL,
> +       .pid            = 0,
> +       .start_time     = 0,
> +       .end_time       = 0,
> +       .nr_entries     = 0,

static assumes all 0:s, what's the point?

> +};

...

> +static void rtnl_print_btrace(struct timer_list *unused)
> +{
> +       pr_info("----------- %s start -----------\n", __func__);
> +       pr_info("%s[%d][%c] hold rtnl_lock more than 2 sec, start time: %llu\n",
> +               rtnl_instance.task->comm,
> +               rtnl_instance.pid,
> +               task_state_to_char(rtnl_instance.task),
> +               rtnl_instance.start_time);
> +       stack_trace_print(rtnl_instance.addrs, rtnl_instance.nr_entries, 0);

> +       show_stack(rtnl_instance.task, NULL, KERN_DEBUG);

Unaligned debug level.

> +       pr_info("------------ %s end -----------\n", __func__);

Looking into tons of these, perhaps you need to define pr_fmt(). I
haven't checked if it's already defined, though.

> +}

...

> +       if (rtnl_instance.end_time - rtnl_instance.start_time > 2000000000ULL) {

Perhaps you should use one of the defined constants from time64.h ?

> +               pr_info("rtnl_lock is held by [%d] from [%llu] to [%llu]\n",
> +                       rtnl_instance.pid,
> +                       rtnl_instance.start_time,
> +                       rtnl_instance.end_time);
> +       }

-- 
With Best Regards,
Andy Shevchenko


From dillon.minfei at gmail.com  Thu Apr 29 10:46:45 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Thu, 29 Apr 2021 17:46:45 +0800
Subject: [PATCH v4 3/4] arm: dts: imx: Add i.mx6q DaSheng COM-9XX SBC
 board support
In-Reply-To: <1618976938-20834-4-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
 <1618976938-20834-4-git-send-email-dillon.minfei@gmail.com>
Message-ID: <CAL9mu0LxeQV8w3+EWwOpqNbQsbK31aSpob6mGGBfYoaV3ZWEPQ@mail.gmail.com>

Hi All,

Just a gentle ping.

Thanks

Best Regards
Dillon

On Wed, Apr 21, 2021 at 11:49 AM <dillon.minfei at gmail.com> wrote:
>
> From: dillon min <dillon.minfei at gmail.com>
>
> The DaSheng Com-9xx is and ARM based signle board computer (SBC)
> featuring:
> - i.MX6Q
> - 2GiB LPDDR3 DRAM
> - 8GiB eMMC 5.0 FLASH
> - 4MiB SPI Flash
> - USB 2.0 Host/Device
> - Multiple multi-protocol RS232/RS485 Serial ports
> - microSD socket
> - 5V DC power input
> - HDMI1.4a,1080p at 60
> - RGMIIx1 Gigabit Ethernet
> - CSI0x1, connect with ov2659
>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v4:
> - change 'green' to 'led-0', fix dtbs_check warrning
> - change 'pmic: pfuze100 at 8' to 'pfuze100: pmic at 8', fix dtbs_check warrning
> - use GPIO_ACTIVE_HIGH instead of 0, from Fabio's suggestion, thanks
> - change 'flash: m25p80 at 0' to 'm25p80: flash at 0'
> - move 'MX6QDL_PAD_GPIO_0__CCM_CLKO1' to pinctrl_ov2659{}
> - move 'MX6QDL_PAD_NANDF_D0__GPIO2_IO00, MX6QDL_PAD_NANDF_D1__GPIO2_IO01'
>   to pinctrl_usdhc2_gpioio{}
> - remove unused hoggrp
> - use wdog2, instead of wdog1 for external reset
>
>  arch/arm/boot/dts/Makefile        |   1 +
>  arch/arm/boot/dts/imx6q-ds.dts    |  17 ++
>  arch/arm/boot/dts/imx6qdl-ds.dtsi | 460 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 478 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-ds.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-ds.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a19c5ab9df84..425fe17ef7c1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -510,6 +510,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>         imx6q-display5-tianma-tm070-1280x768.dtb \
>         imx6q-dmo-edmqmx6.dtb \
>         imx6q-dms-ba16.dtb \
> +       imx6q-ds.dtb \
>         imx6q-emcon-avari.dtb \
>         imx6q-evi.dtb \
>         imx6q-gk802.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-ds.dts b/arch/arm/boot/dts/imx6q-ds.dts
> new file mode 100644
> index 000000000000..b0a63a133977
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-ds.dts
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
> +//
> +// Based on imx6qdl-sabresd.dtsi which is:
> +// Copyright 2012 Freescale Semiconductor, Inc.
> +// Copyright 2011 Linaro Ltd.
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-ds.dtsi"
> +
> +/ {
> +       model = "DaSheng i.MX6 Quad Com-9xx Board";
> +       compatible = "ds,imx6q-sbc", "fsl,imx6q";
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-ds.dtsi b/arch/arm/boot/dts/imx6qdl-ds.dtsi
> new file mode 100644
> index 000000000000..a2069caf4ea7
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-ds.dtsi
> @@ -0,0 +1,460 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright 2021 Dillon Min <dillon.minfei at gmail.com>
> +//
> +// Based on imx6qdl-sabresd.dtsi which is:
> +// Copyright 2012 Freescale Semiconductor, Inc.
> +// Copyright 2011 Linaro Ltd.
> +
> +#include <dt-bindings/clock/imx6qdl-clock.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +       chosen {
> +               stdout-path = &uart4;
> +       };
> +
> +       memory at 10000000 {
> +               device_type = "memory";
> +               reg = <0x10000000 0x80000000>;
> +       };
> +
> +       reg_usb_otg_vbus: regulator-usb-otg-vbus {
> +               compatible = "regulator-fixed";
> +               regulator-name = "usb_otg_vbus";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               regulator-always-on;
> +       };
> +
> +       reg_usb_h1_vbus: regulator-usb-h1-vbus {
> +               compatible = "regulator-fixed";
> +               regulator-name = "usb_h1_vbus";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               regulator-always-on;
> +       };
> +
> +       leds {
> +               compatible = "gpio-leds";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> +               led-0 {
> +                       gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> +                       default-state = "on";
> +                       linux,default-trigger = "heartbeat";
> +               };
> +       };
> +};
> +
> +&ipu1_csi0_from_ipu1_csi0_mux {
> +       bus-width = <8>;
> +       data-shift = <12>; /* Lines 19:12 used */
> +       hsync-active = <1>;
> +       vsync-active = <1>;
> +};
> +
> +&ipu1_csi0_mux_from_parallel_sensor {
> +       remote-endpoint = <&ov2659_to_ipu1_csi0_mux>;
> +};
> +
> +&ipu1_csi0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ipu1_csi0>;
> +       status = "okay";
> +};
> +
> +&ecspi1 {
> +       cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ecspi1>, <&pinctrl_ecspi1_gpio>;
> +       status = "okay";
> +
> +       m25p80: flash at 0 {
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               compatible = "st,m25p80", "jedec,spi-nor";
> +               spi-max-frequency = <20000000>;
> +               reg = <0>;
> +       };
> +};
> +
> +&fec {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_enet>;
> +       phy-mode = "rgmii-id";
> +       phy-handle = <&phy>;
> +       fsl,magic-packet;
> +       status = "okay";
> +
> +       mdio {
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               phy: ethernet-phy at 1 {
> +                       reg = <1>;
> +                       qca,clk-out-frequency = <125000000>;
> +                       reset-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
> +                       reset-assert-us = <10000>;
> +               };
> +       };
> +};
> +
> +&hdmi {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_hdmi_cec>;
> +       ddc-i2c-bus = <&i2c3>;
> +       status = "okay";
> +};
> +
> +&i2c2 {
> +       clock-frequency = <100000>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_i2c2>;
> +       status = "okay";
> +
> +       pfuze100: pmic at 8 {
> +               compatible = "fsl,pfuze100";
> +               reg = <0x08>;
> +
> +               regulators {
> +                       sw1a_reg: sw1ab {
> +                               regulator-min-microvolt = <300000>;
> +                               regulator-max-microvolt = <1875000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw1c_reg: sw1c {
> +                               regulator-min-microvolt = <300000>;
> +                               regulator-max-microvolt = <1875000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw2_reg: sw2 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                               regulator-ramp-delay = <6250>;
> +                       };
> +
> +                       sw3a_reg: sw3a {
> +                               regulator-min-microvolt = <400000>;
> +                               regulator-max-microvolt = <1975000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       sw3b_reg: sw3b {
> +                               regulator-min-microvolt = <400000>;
> +                               regulator-max-microvolt = <1975000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       sw4_reg: sw4 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       swbst_reg: swbst {
> +                               regulator-min-microvolt = <5000000>;
> +                               regulator-max-microvolt = <5150000>;
> +                       };
> +
> +                       snvs_reg: vsnvs {
> +                               regulator-min-microvolt = <1000000>;
> +                               regulator-max-microvolt = <3000000>;
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       vref_reg: vrefddr {
> +                               regulator-boot-on;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen1_reg: vgen1 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <1550000>;
> +                       };
> +
> +                       vgen2_reg: vgen2 {
> +                               regulator-min-microvolt = <800000>;
> +                               regulator-max-microvolt = <1550000>;
> +                       };
> +
> +                       vgen3_reg: vgen3 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                       };
> +
> +                       vgen4_reg: vgen4 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen5_reg: vgen5 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +
> +                       vgen6_reg: vgen6 {
> +                               regulator-min-microvolt = <1800000>;
> +                               regulator-max-microvolt = <3300000>;
> +                               regulator-always-on;
> +                       };
> +               };
> +       };
> +};
> +
> +&i2c3 {
> +       clock-frequency = <100000>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_i2c3>;
> +       status = "okay";
> +
> +       ov2659: camera at 30 {
> +               compatible = "ovti,ov2659";
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_ov2659>;
> +               clocks = <&clks IMX6QDL_CLK_CKO>;
> +               clock-names = "xvclk";
> +               reg = <0x30>;
> +               powerdown-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
> +               reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
> +               status = "okay";
> +
> +               port {
> +                       ov2659_to_ipu1_csi0_mux: endpoint {
> +                               remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> +                               link-frequencies = /bits/ 64 <70000000>;
> +                               bus-width = <8>;
> +                               hsync-active = <1>;
> +                               vsync-active = <1>;
> +                       };
> +               };
> +       };
> +};
> +
> +&iomuxc {
> +       pinctrl_ecspi1: ecspi1grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_EIM_D16__ECSPI1_SCLK         0x100b1
> +                       MX6QDL_PAD_EIM_D18__ECSPI1_MOSI         0x100b1
> +                       MX6QDL_PAD_EIM_D17__ECSPI1_MISO         0x100b1
> +               >;
> +       };
> +
> +       pinctrl_ecspi1_gpio: ecspi1grpgpiogrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_KEY_ROW1__GPIO4_IO09         0x1b0b0
> +                       MX6QDL_PAD_ENET_RXD0__GPIO1_IO27        0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_enet: enetgrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_ENET_MDIO__ENET_MDIO         0x1b0b0
> +                       MX6QDL_PAD_ENET_MDC__ENET_MDC           0x1b0b0
> +                       MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b030
> +                       MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b030
> +                       MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b030
> +                       MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b030
> +                       MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b030
> +                       MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b030
> +                       MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x1b0b0
> +                       MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b030
> +                       MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b030
> +                       MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b030
> +                       MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b030
> +                       MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b030
> +                       MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
> +                       MX6QDL_PAD_KEY_COL2__GPIO4_IO10         0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_hdmi_cec: hdmicecgrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE    0x1f8b0
> +               >;
> +       };
> +
> +       pinctrl_i2c2: i2c2grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_EIM_EB2__I2C2_SCL            0x4001b8b1
> +                       MX6QDL_PAD_KEY_ROW3__I2C2_SDA           0x4001b8b1
> +               >;
> +       };
> +
> +       pinctrl_i2c3: i2c3grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_GPIO_5__I2C3_SCL             0x4001b8b1
> +                       MX6QDL_PAD_GPIO_6__I2C3_SDA             0x4001b8b1
> +               >;
> +       };
> +
> +       pinctrl_ipu1_csi0: ipu1csi0grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18    0x1b0b0
> +                       MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19    0x1b0b0
> +                       MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK   0x1b0b0
> +                       MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC      0x1b0b0
> +                       MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC     0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_ov2659: ov2659grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_GPIO_16__GPIO7_IO11          0x1b0b0
> +                       MX6QDL_PAD_GPIO_7__GPIO1_IO07           0x1b0b0
> +                       MX6QDL_PAD_GPIO_0__CCM_CLKO1            0x130b0
> +               >;
> +       };
> +
> +       pinctrl_uart4: uart4grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_KEY_COL0__UART4_TX_DATA      0x1b0b1
> +                       MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA      0x1b0b1
> +               >;
> +       };
> +
> +       pinctrl_usbotg: usbotggrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID       0x17059
> +               >;
> +       };
> +
> +       pinctrl_usdhc1: usdhc1grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_SD1_CMD__SD1_CMD             0x17059
> +                       MX6QDL_PAD_SD1_CLK__SD1_CLK             0x10059
> +                       MX6QDL_PAD_SD1_DAT0__SD1_DATA0          0x17059
> +                       MX6QDL_PAD_SD1_DAT1__SD1_DATA1          0x17059
> +                       MX6QDL_PAD_SD1_DAT2__SD1_DATA2          0x17059
> +                       MX6QDL_PAD_SD1_DAT3__SD1_DATA3          0x17059
> +               >;
> +       };
> +
> +       pinctrl_usdhc1_gpio: usdhc1grpgpiogrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28       0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_usdhc2: usdhc2grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_SD2_CMD__SD2_CMD             0x17059
> +                       MX6QDL_PAD_SD2_CLK__SD2_CLK             0x10059
> +                       MX6QDL_PAD_SD2_DAT0__SD2_DATA0          0x17059
> +                       MX6QDL_PAD_SD2_DAT1__SD2_DATA1          0x17059
> +                       MX6QDL_PAD_SD2_DAT2__SD2_DATA2          0x17059
> +                       MX6QDL_PAD_SD2_DAT3__SD2_DATA3          0x17059
> +               >;
> +       };
> +
> +       pinctrl_usdhc2_gpio: usdhc2grpgpiogrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_NANDF_D0__GPIO2_IO00         0x1b0b0
> +                       MX6QDL_PAD_NANDF_D1__GPIO2_IO01         0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_usdhc3: usdhc3grp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_SD3_CMD__SD3_CMD             0x17059
> +                       MX6QDL_PAD_SD3_CLK__SD3_CLK             0x10059
> +                       MX6QDL_PAD_SD3_DAT0__SD3_DATA0          0x17059
> +                       MX6QDL_PAD_SD3_DAT1__SD3_DATA1          0x17059
> +                       MX6QDL_PAD_SD3_DAT2__SD3_DATA2          0x17059
> +                       MX6QDL_PAD_SD3_DAT3__SD3_DATA3          0x17059
> +                       MX6QDL_PAD_SD3_DAT4__SD3_DATA4          0x17059
> +                       MX6QDL_PAD_SD3_DAT5__SD3_DATA5          0x17059
> +                       MX6QDL_PAD_SD3_DAT6__SD3_DATA6          0x17059
> +                       MX6QDL_PAD_SD3_DAT7__SD3_DATA7          0x17059
> +               >;
> +       };
> +
> +       pinctrl_wdog: wdoggrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_GPIO_1__WDOG2_B              0x1b0b0
> +               >;
> +       };
> +
> +       pinctrl_gpio_leds: gpioledsgrp {
> +               fsl,pins = <
> +                       MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x1b0b0
> +               >;
> +       };
> +};
> +
> +&uart4 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_uart4>;
> +       status = "okay";
> +};
> +
> +&usbh1 {
> +       vbus-supply = <&reg_usb_h1_vbus>;
> +       status = "okay";
> +};
> +
> +&usbotg {
> +       vbus-supply = <&reg_usb_otg_vbus>;
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usbotg>;
> +       disable-over-current;
> +       status = "okay";
> +};
> +
> +&usdhc1 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_usdhc1_gpio>;
> +       bus-width = <4>;
> +       cd-gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
> +       status = "okay";
> +};
> +
> +&usdhc2 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +       bus-width = <4>;
> +       cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
> +       wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +       status = "disabled";
> +};
> +
> +&usdhc3 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc3>;
> +       bus-width = <8>;
> +       non-removable;
> +       no-1-8-v;
> +       status = "okay";
> +};
> +
> +&wdog1 {
> +       status = "disabled";
> +};
> +
> +&wdog2 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_wdog>;
> +       fsl,ext-reset-output;
> +       status = "okay";
> +};
> --
> 2.7.4
>


From dillon.minfei at gmail.com  Thu Apr 29 10:48:11 2021
From: dillon.minfei at gmail.com (dillon min)
Date: Thu, 29 Apr 2021 17:48:11 +0800
Subject: [PATCH v4 4/4] media: i2c: ov2659: Use clk_{prepare_enable,
 disable_unprepare}() to set xvclk on/off
In-Reply-To: <1618976938-20834-5-git-send-email-dillon.minfei@gmail.com>
References: <1618976938-20834-1-git-send-email-dillon.minfei@gmail.com>
 <1618976938-20834-5-git-send-email-dillon.minfei@gmail.com>
Message-ID: <CAL9mu0KKJGxVijqQHmBVWZds9YZmmS4pouP_QO0xNN4DPdrgoA@mail.gmail.com>

Hi All,

Just a gentle ping.

and loop mchehab+huawei at kernel.org

Thanks

Best Regards
Dillon

On Wed, Apr 21, 2021 at 11:49 AM <dillon.minfei at gmail.com> wrote:
>
> From: dillon min <dillon.minfei at gmail.com>
>
> On some platform(imx6q), xvclk might not switch on in advance,
> also for power save purpose, xvclk should not be always on.
> so, add clk_prepare_enable(), clk_disable_unprepare() in driver
> side to set xvclk on/off at proper stage.
>
> Add following changes:
> - add 'struct clk *clk;' in 'struct ov2659 {}'
> - enable xvclk in ov2659_power_on()
> - disable xvclk in ov2659_power_off()
>
> Signed-off-by: dillon min <dillon.minfei at gmail.com>
> ---
> v4: no changes
>
>  drivers/media/i2c/ov2659.c | 24 ++++++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
> index 42f64175a6df..fb78a1cedc03 100644
> --- a/drivers/media/i2c/ov2659.c
> +++ b/drivers/media/i2c/ov2659.c
> @@ -204,6 +204,7 @@ struct ov2659 {
>         struct i2c_client *client;
>         struct v4l2_ctrl_handler ctrls;
>         struct v4l2_ctrl *link_frequency;
> +       struct clk *clk;
>         const struct ov2659_framesize *frame_size;
>         struct sensor_register *format_ctrl_regs;
>         struct ov2659_pll_ctrl pll;
> @@ -1270,6 +1271,8 @@ static int ov2659_power_off(struct device *dev)
>
>         gpiod_set_value(ov2659->pwdn_gpio, 1);
>
> +       clk_disable_unprepare(ov2659->clk);
> +
>         return 0;
>  }
>
> @@ -1278,9 +1281,17 @@ static int ov2659_power_on(struct device *dev)
>         struct i2c_client *client = to_i2c_client(dev);
>         struct v4l2_subdev *sd = i2c_get_clientdata(client);
>         struct ov2659 *ov2659 = to_ov2659(sd);
> +       int ret;
>
>         dev_dbg(&client->dev, "%s:\n", __func__);
>
> +       ret = clk_prepare_enable(ov2659->clk);
> +       if (ret) {
> +               dev_err(&client->dev, "%s: failed to enable clock\n",
> +                       __func__);
> +               return ret;
> +       }
> +
>         gpiod_set_value(ov2659->pwdn_gpio, 0);
>
>         if (ov2659->resetb_gpio) {
> @@ -1425,7 +1436,6 @@ static int ov2659_probe(struct i2c_client *client)
>         const struct ov2659_platform_data *pdata = ov2659_get_pdata(client);
>         struct v4l2_subdev *sd;
>         struct ov2659 *ov2659;
> -       struct clk *clk;
>         int ret;
>
>         if (!pdata) {
> @@ -1440,11 +1450,11 @@ static int ov2659_probe(struct i2c_client *client)
>         ov2659->pdata = pdata;
>         ov2659->client = client;
>
> -       clk = devm_clk_get(&client->dev, "xvclk");
> -       if (IS_ERR(clk))
> -               return PTR_ERR(clk);
> +       ov2659->clk = devm_clk_get(&client->dev, "xvclk");
> +       if (IS_ERR(ov2659->clk))
> +               return PTR_ERR(ov2659->clk);
>
> -       ov2659->xvclk_frequency = clk_get_rate(clk);
> +       ov2659->xvclk_frequency = clk_get_rate(ov2659->clk);
>         if (ov2659->xvclk_frequency < 6000000 ||
>             ov2659->xvclk_frequency > 27000000)
>                 return -EINVAL;
> @@ -1506,7 +1516,9 @@ static int ov2659_probe(struct i2c_client *client)
>         ov2659->frame_size = &ov2659_framesizes[2];
>         ov2659->format_ctrl_regs = ov2659_formats[0].format_ctrl_regs;
>
> -       ov2659_power_on(&client->dev);
> +       ret = ov2659_power_on(&client->dev);
> +       if (ret < 0)
> +               goto error;
>
>         ret = ov2659_detect(sd);
>         if (ret < 0)
> --
> 2.7.4
>


From szabolcs.nagy at arm.com  Thu Apr 29 10:50:28 2021
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Thu, 29 Apr 2021 10:50:28 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
 <20210429075454.GQ9028@arm.com>
 <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>
Message-ID: <20210429095027.GR9028@arm.com>

The 04/29/2021 02:23, Bill Wendling wrote:
> On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
> > The 04/28/2021 12:31, Bill Wendling wrote:
> > > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo at google.com> wrote:
> > > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> > > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> > > > >
> > > > > > > Since the note.gnu.property section in the vDSO is not checked by the
> > > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> > > > >
> > > > > > Can we not instead fix the linker script to preserve the
> > > > > > .note.gnu.property, correctly aligned? It doesn't take much space and
> > > > > > while we don't use it now, it has the BTI information about the binary.
> > > > >
> > > > > > Cc'ing a few others who were involved in the BTI support.
> > > > >
> > > > > Not just BTI, we also flag PAC usage in there too and could add other
> > > > > extensions going forwards.  While the note isn't actively used by
> > > > > anything right now due to the kernel mapping the vDSO prior to userspace
> > > > > starting it is part of the ABI and something could end up wanting to use
> > > > > it and getting confused if it's not there.  It would be much better to
> > > > > fix the alignment issue.
> > > >
> > > > If there's only one of the 8-byte aligned sections guaranteed, we
> > > > could place it first in the note. Otherwise, we will have to change
> > > > the alignment of the note (or somehow merge multiple notes).
> > > >
> > > I should have clarified that there's only one *entry* in the
> > > .note.gnu.properties section, and if not then is it possible to merge
> > > multiple entries into one. (Excuse my ignorance if this is already the
> > > case.)
> >
> > .note.gnu.property should go to PT_GNU_PROPERTY and it
> > should be merged following rules specified in
> > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
> > and
> > https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property
> >
> > it may also be covered by a (8byte aligned) PT_NOTE, but
> > that's not a requirement on aarch64 (x86 requires it for
> > compatibility with old dynamic linker, but since the vdso
> > is handled specially that may not be relevant either).
> >
> > i don't know how this works in linker scripts.
> 
> This is a potential patch. I haven't had time to test it though.
> However, it does appear to format the section in the "expected" way,
> so one's able to grab the build IDs. Thoughts?


please show the program headers.


> 
> $ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so
> 
> ./arch/arm64/kernel/vdso/vdso.so:     file format elf64-little
> 
> Contents of section .note:
>  0288 04000000 10000000 05000000 474e5500  ............GNU.
>  0298 000000c0 04000000 03000000 00000000  ................
>  02a8 06000000 04000000 00000000 4c696e75  ............Linu
>  02b8 78000000 000a0500 06000000 01000000  x...............
>  02c8 00010000 4c696e75 78000000 00000000  ....Linux.......
>  02d8 04000000 14000000 03000000 474e5500  ............GNU.
>  02e8 958db149 af5156cb 45309896 7a53ae8a  ...I.QV.E0..zS..
>  02f8 ef34e95c                             .4.\
> 
> diff --git a/arch/arm64/kernel/vdso/vdso.lds.S
> b/arch/arm64/kernel/vdso/vdso.lds.S
> index d808ad31e01f..d51e886c6223 100644
> --- a/arch/arm64/kernel/vdso/vdso.lds.S
> +++ b/arch/arm64/kernel/vdso/vdso.lds.S
> @@ -31,7 +31,13 @@ SECTIONS
>         .gnu.version_d  : { *(.gnu.version_d) }
>         .gnu.version_r  : { *(.gnu.version_r) }
> 
> -       .note           : { *(.note.*) }                :text   :note
> +       /*
> +        * Add the .note.gnu.property section first, as it's aligned to
> +        * 8-bytes, while other notes are aligned to 4-bytes.
> +        */
> +       . = ALIGN(8);
> +
> +       .note           : { *(.note.gnu.property) *(.note.*) }  :text   :note
> 
>         . = ALIGN(16);

-- 


From shengjiu.wang at gmail.com  Thu Apr 29 11:03:32 2021
From: shengjiu.wang at gmail.com (Shengjiu Wang)
Date: Thu, 29 Apr 2021 18:03:32 +0800
Subject: [PATCH] ARM: dts: imx6ul: Switch to fsl-asoc-card sound card
In-Reply-To: <20210429070940.6hech7hezrpiyzzp@pengutronix.de>
References: <1619664739-12589-1-git-send-email-shengjiu.wang@nxp.com>
 <20210429070940.6hech7hezrpiyzzp@pengutronix.de>
Message-ID: <CAA+D8ANeEbVMJ6QGfyrtqgP9ohHXD6FBFdwXT7rZ7pO+SVTFcw@mail.gmail.com>

On Thu, Apr 29, 2021 at 3:09 PM Marco Felsch <m.felsch at pengutronix.de> wrote:
>
> Hi,
>
> thanks for the patch.
>
> On 21-04-29 10:52, Shengjiu Wang wrote:
> > There is issue with simple sound card, the simple sound
> > card can't configure the pll of codec.
>
> Hm, than we should fix this rather than moving to the 'old'
> 'fsl,imx-audio-wm8960'. But that only my opinion.
>

Thanks for your comments.

But fsl-asoc-card is better than simple sound card, it not only
avoids the pll error but also supports the ASRC module.
And this patch is to use the same machine driver as the imx6qdl
platform.

Best regards
Wang shengjiu


From wangkefeng.wang at huawei.com  Thu Apr 29 11:22:55 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Thu, 29 Apr 2021 18:22:55 +0800
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <YIpY8TXCSc7Lfa2Z@kernel.org>
References: <33fa74c2-f32d-f224-eb30-acdb717179ff@huawei.com>
 <2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com>
 <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
 <YIj5zcbHBHt7CC8B@kernel.org>
 <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>
 <YIpY8TXCSc7Lfa2Z@kernel.org>
Message-ID: <0cb013e4-1157-f2fa-96ec-e69e60833f72@huawei.com>


On 2021/4/29 14:57, Mike Rapoport wrote:

>>> Do you use SPARSMEM? If yes, what is your section size?
>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>> Yes,
>>
>> CONFIG_SPARSEMEM=y
>>
>> CONFIG_SPARSEMEM_STATIC=y
>>
>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>
>> CONFIG_PAGE_OFFSET=0xC0000000
>> CONFIG_HAVE_ARCH_PFN_VALID=y
>> CONFIG_HIGHMEM=y
>> #define SECTION_SIZE_BITS    26
>> #define MAX_PHYSADDR_BITS    32
>> #define MAX_PHYSMEM_BITS     32


With the patch,? the addr is aligned, but the panic still occurred,

new free memory log is below,

memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c

memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
__free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
__free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
__free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
__free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
__free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
__free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
__free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
__free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
__free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
__free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
__free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
__free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
__free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
__free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
__free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
__free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
__free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
__free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
__free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
__free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
__free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
__free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
__free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
__free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
__free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
__free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
__free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
__free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
__free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
__free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
__free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
__free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
__free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
> It seems that with SPARSEMEM we don't align the freed parts on pageblock
> boundaries.
>
> Can you try the patch below:
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index afaefa8fc6ab..1926369b52ec 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
>   		 * due to SPARSEMEM sections which aren't present.
>   		 */
>   		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
> -#else
> +#endif
>   		/*
>   		 * Align down here since the VM subsystem insists that the
>   		 * memmap entries are valid from the bank start aligned to
>   		 * MAX_ORDER_NR_PAGES.
>   		 */
>   		start = round_down(start, MAX_ORDER_NR_PAGES);
> -#endif
>   
>   		/*
>   		 * If we had a previous bank, and there is a space
>   
>


From alexandru.elisei at arm.com  Thu Apr 29 11:32:33 2021
From: alexandru.elisei at arm.com (Alexandru Elisei)
Date: Thu, 29 Apr 2021 11:32:33 +0100
Subject: [PATCH] KVM: arm64: Skip CMOs when updating a PTE pointing to
 non-memory
In-Reply-To: <YIgsbp/hRxM9U+ZN@myrica>
References: <20210426103605.616908-1-maz@kernel.org>
 <e6d955f1-f2a4-9505-19ab-5a770f821386@arm.com> <YIgsbp/hRxM9U+ZN@myrica>
Message-ID: <35d5f174-3814-a019-a6e3-14cffad69763@arm.com>

Hi Jean,

On 4/27/21 4:23 PM, Jean-Philippe Brucker wrote:
> On Tue, Apr 27, 2021 at 03:52:46PM +0100, Alexandru Elisei wrote:
>> The comment [1] suggested that the panic is triggered during page aging.
> I think only with an out-of-tree patch applied
> https://jpbrucker.net/git/linux/commit/?h=sva/2021-03-01&id=d32d8baaf293aaefef8a1c9b8a4508ab2ec46c61
> which probably is not going upstream.

Thanks for that, that explains why I wasn't able to trigger the notification.

I did a grep for all the places where mmu_notifier_change_pte() and
set_pte_at_notify() are used in the kernel, and from what I can tell they are only
called for a new pte which has a struct page. From my investigation, the notifiers
are called from ksm (which deals with physical memory), swap migration (so still
pages in memory) and on copy-on-write.

On Linux v5.12, I tried to trigger the copy-on-write notification by forking
kvmtool right after the BAR region is mapped and then reading from the userspace
BAR address, but the new pte (for which the notifier is called) is valid.

I also looked at what x86 does, but I couldn't find where cache maintenance is
performed (wouldn't surprise me if it's not necessary at all).

So I guess my question is what kind of pfns the MMU notifiers for the secondary
MMUs are required to handle. If the requirement is that they should handle both
device and struct page backed pfns, then the patch looks correct to me
(user_mem_abort() also uses kvm_is_device_pfn() to decide if dcache maintenance is
needed).

Thanks,

Alex

> Thanks,
> Jean
>
>> vfio_pci_mmap() sets the VM_PFNMAP for the VMA and I see in the Documentation that
>> pages with VM_PFNMAP are added to the unevictable LRU list, doesn't that mean it's
>> not subject the page aging? I feel like there's something I'm missing.
>>
>> [1]
>> https://lore.kernel.org/kvm/BY5PR12MB37642B9AC7E5D907F5A664F6B3459 at BY5PR12MB3764.namprd12.prod.outlook.com/
>>
>> Thanks,
>>
>> Alex


From mark.rutland at arm.com  Thu Apr 29 11:48:13 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 29 Apr 2021 11:48:13 +0100
Subject: [PATCH] arm64: stacktrace: Stop unwinding when the PC is zero
In-Reply-To: <20210429014321.196606-1-leo.yan@linaro.org>
References: <20210429014321.196606-1-leo.yan@linaro.org>
Message-ID: <20210429104813.GA33550@C02TD0UTHF1T.local>

Hi Leo,

On Thu, Apr 29, 2021 at 09:43:21AM +0800, Leo Yan wrote:
> When use ftrace for stack trace, it reports the spurious frame with the
> PC value is zero.  This can be reproduced with commands:
> 
>   # cd /sys/kernel/debug/tracing/
>   # echo "prev_pid == 0" > events/sched/sched_switch/filter
>   # echo stacktrace > events/sched/sched_switch/trigger
>   # echo 1 > events/sched/sched_switch/enable
>   # cat trace
> 
>            <idle>-0       [005] d..2   259.621390: sched_switch: ...
>            <idle>-0       [005] d..3   259.621394: <stack trace>
>   => __schedule
>   => schedule_idle
>   => do_idle
>   => cpu_startup_entry
>   => secondary_start_kernel
>   => 0

IIUC, this is my fault, and is an unintended side-effect of commit:

  6106e1112cc69a36 ("arm64: remove EL0 exception frame record")

... since before prior to that, we'd implicitly create a terminal record
in start_kernel and secondary_start_kernel by virtue of entering those
functions with both FP and LR set to NULL. After that commit, we report
the NULL LR before trying to unwind the NULL FP.

> The kernel initializes FP/PC values as zero for swapper threads in
> head.S, when walk the stack frame, this patch stops unwinding if detect
> the PC value is zero, therefore can avoid the spurious frame.
> 
> Below is the stacktrace after applying the change:
> 
>   # cat trace
> 
>            <idle>-0       [005] d..2   259.621390: sched_switch: ...
>            <idle>-0       [005] d..3   259.621394: <stack trace>
>   => __schedule
>   => schedule_idle
>   => do_idle
>   => cpu_startup_entry
>   => secondary_start_kernel
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  arch/arm64/kernel/stacktrace.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 84b676bcf867..02b1e85b2026 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -145,7 +145,11 @@ void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
>  		if (!fn(data, frame->pc))
>  			break;
>  		ret = unwind_frame(tsk, frame);
> -		if (ret < 0)
> +		/*
> +		 * When the frame->pc is zero, it has reached to the initial pc
> +		 * and fp values; stop unwinding for this case.
> +		 */
> +		if (ret < 0 || !frame->pc)
>  			break;

I don't think this is the right place for this, since we intend
unwind_frame() to detect when unwinding is finished; see commit:

  3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack")

I think we have three options for what to do here:

a) Revert 6106e1112cc69a36, and identify these cases as terminal records
   where FP and LR are both NULL.

b) Have __primary_switched and __secondary_switched call start_kernel
   and secondary_start_kernel with BL rather than B. The __*_switched
   functions will show up in the trace, but we won't unwind any further
   as the next record will have a NULL FP.

c) Revert 6106e1112cc69a36, create terminal records in
   __primary_switched and __secondary_switched, and call start_kernel
   and secondary_start_kernel with BL rather than B. The __*_switched
   functions will show up in the trace, but we won't unwind any further
   as the next record will be a terminal record.

For RELIABLE_STACKTRACE, we're going to have to do (c), I think, but for
now we could do (a) so as to have a minimal fix, and we can build (c)
atop that.

How about the patch below? I've tested it with your instructions and
also by inspecting /proc/self/stack.

Thanks,
Mark.

---->8----
>From b99e647b34b74059f3013c09f12fbd542c7679fd Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland at arm.com>
Date: Thu, 29 Apr 2021 11:20:04 +0100
Subject: [PATCH] arm64: stacktrace: restore terminal records

We removed the terminal frame records in commit:

   6106e1112cc69a36 ("arm64: remove EL0 exception frame record")

... on the assumption that as we no longer used them to find the pt_regs
at exception boundaries, they were no longer necessary.

However, Leo reports that as an unintended side-effect, this causes
traces which cross secondary_start_kernel to terminate one entry too
late, with a spurious "0" entry.

There are a few ways we could sovle this, but as we're planning to use
terminal records for RELIABLE_STACKTRACE, let's revert the logic change
for now, keeping the update comments and accounting for the changes in
commit:

  3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack")

This is effectively a partial revert of commit:

  6106e1112cc69a36 ("arm64: remove EL0 exception frame record")

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Fixes: 6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
Reported-by: Leo Yan <leo.yan at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will at kernel.org>
Cc: Mark Brown <broonie at kernel.org>
Cc: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>
---
 arch/arm64/kernel/entry.S      |  6 +++---
 arch/arm64/kernel/stacktrace.c | 10 ++++++----
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 6acfc5e6b5e0..9b205744a233 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -263,16 +263,16 @@ alternative_else_nop_endif
 	stp	lr, x21, [sp, #S_LR]
 
 	/*
-	 * For exceptions from EL0, terminate the callchain here.
+	 * For exceptions from EL0, create a terminal frame record.
 	 * For exceptions from EL1, create a synthetic frame record so the
 	 * interrupted code shows up in the backtrace.
 	 */
 	.if \el == 0
-	mov	x29, xzr
+	stp	xzr, xzr, [sp, #S_STACKFRAME]
 	.else
 	stp	x29, x22, [sp, #S_STACKFRAME]
-	add	x29, sp, #S_STACKFRAME
 	.endif
+	add	x29, sp, #S_STACKFRAME
 
 #ifdef CONFIG_ARM64_SW_TTBR0_PAN
 alternative_if_not ARM64_HAS_PAN
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d55bdfb7789c..7032a5f9e624 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -44,10 +44,6 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 	unsigned long fp = frame->fp;
 	struct stack_info info;
 
-	/* Terminal record; nothing to unwind */
-	if (!fp)
-		return -ENOENT;
-
 	if (fp & 0xf)
 		return -EINVAL;
 
@@ -108,6 +104,12 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 
 	frame->pc = ptrauth_strip_insn_pac(frame->pc);
 
+	/*
+	 * This is a terminal record, so we have finished unwinding.
+	 */
+	if (!frame->fp && !frame->pc)
+		return -ENOENT;
+
 	return 0;
 }
 NOKPROBE_SYMBOL(unwind_frame);
-- 
2.11.0


 


From colin.king at canonical.com  Thu Apr 29 12:00:40 2021
From: colin.king at canonical.com (Colin King)
Date: Thu, 29 Apr 2021 12:00:40 +0100
Subject: [PATCH][next] PCI: mediatek-gen3: Add missing null pointer check
Message-ID: <20210429110040.63119-1-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The call to platform_get_resource_byname can potentially return null, so
add a null pointer check to avoid a null pointer dereference issue.

Addresses-Coverity: ("Dereference null return")
Fixes: 441903d9e8f0 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
index 20165e4a75b2..3c5b97716d40 100644
--- a/drivers/pci/controller/pcie-mediatek-gen3.c
+++ b/drivers/pci/controller/pcie-mediatek-gen3.c
@@ -721,6 +721,8 @@ static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
 	int ret;
 
 	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
+	if (!regs)
+		return -EINVAL;
 	port->base = devm_ioremap_resource(dev, regs);
 	if (IS_ERR(port->base)) {
 		dev_err(dev, "failed to map register base\n");
-- 
2.30.2



From hverkuil-cisco at xs4all.nl  Thu Apr 29 12:15:57 2021
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Thu, 29 Apr 2021 13:15:57 +0200
Subject: [PATCH 1/5] dt-bindings: media: mtk-vcodec: Add dma-ranges
 property
In-Reply-To: <1614581129.14457.0.camel@mhfsdcap03>
References: <20210203083752.12586-1-irui.wang@mediatek.com>
 <20210203083752.12586-2-irui.wang@mediatek.com>
 <20210210225323.GA2961490@robh.at.kernel.org>
 <1614581129.14457.0.camel@mhfsdcap03>
Message-ID: <2b97b41c-d5d8-ac32-a9cf-c7bef09ed8ef@xs4all.nl>

Hi Rob,

On 01/03/2021 07:45, Irui Wang wrote:
> On Wed, 2021-02-10 at 16:53 -0600, Rob Herring wrote:
>> On Wed, Feb 03, 2021 at 04:37:48PM +0800, Irui Wang wrote:
>>> Adds dma-ranges property for DMA addresses translation.
>>>
>>> Signed-off-by: Irui Wang <irui.wang at mediatek.com>
>>> ---
>>>  Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>>> index f85276e629bf..e4644f8caee9 100644
>>> --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>>> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>>> @@ -23,6 +23,8 @@ Required properties:
>>>  - iommus : should point to the respective IOMMU block with master port as
>>>    argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>>>    for details.
>>> +- dma-ranges : describes how the physical address space of the IOMMU maps
>>> +  to memory.
>>
>> dma-ranges is supposed to be in a bus/parent node.
> Dear Rob,
> 
> The mt8192 iommu support 0~16GB iova. We separate it to four banks:
> 0~4G; 4G~8G; 8G~12G; 12G~16G.
> 
> The "dma-ranges" could be used to adjust the bank we locate.
> If we don't set this property. The default range always is 0~4G.
> 
> Here we don't have actual bus/parent concept here.  And the iova
> requirement is for our HW. Thus put the property in our node.
> 
> Is this OK? If this is ok for you, I will put this message in the commit
> message and binding in next version.

Can you answer Irui's question? Just a reminder...

Much appreciated!

Regards,

	Hans

> 
> Regards
>>
>>>  One of the two following nodes:
>>>  - mediatek,vpu : the node of the video processor unit, if using VPU.
>>>  - mediatek,scp : the node of the SCP unit, if using SCP.
>>> -- 
>>> 2.25.1
>>>
> 



From u.kleine-koenig at pengutronix.de  Thu Apr 29 13:04:16 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Thu, 29 Apr 2021 14:04:16 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ@mail.gmail.com>
References: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
 <20210428061357.725m72aikc52n4gg@pengutronix.de>
 <CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ@mail.gmail.com>
Message-ID: <20210429120416.5ba7rq5fvhcfebzz@pengutronix.de>

Hello Roman,

On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Ber?nek wrote:
> Correct, the output may stay in an active state. I only discovered this
> bug as I investigated a report of unreliable screen timeout. The period
> we use the PWM with is 50 us.

What I don't like here is that the delay is quite coarse and might still
be too short. (Maybe I miss something, but consider the current period
is quite long, then you configure a short one and then disable. In this
case the inital long setting might still be active.)

> The PWMx_RDY bit stays 0 well after the last period ends, so if the bit
> has any function at all, this one is certainly not it.

OK.

A way out could be to not disable the clock on .enable = 0. This might
(or might not) have an impact on power consumption, but it improves
correctness and simplifies the driver as the delay just goes away. So
you might consider it a good trade-off, too. Maybe there is also a nice
solution with runtime-PM?!

> Note: my apologies for the previous HTML message

I didn't notice (because the message also contained a txt part). Another
thing to improve is to reply inline instead of top posting :-)

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/20210429/009097b2/attachment.sig>

From leo.yan at linaro.org  Thu Apr 29 13:26:05 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 20:26:05 +0800
Subject: [PATCH] arm64: stacktrace: Stop unwinding when the PC is zero
In-Reply-To: <20210429104813.GA33550@C02TD0UTHF1T.local>
References: <20210429014321.196606-1-leo.yan@linaro.org>
 <20210429104813.GA33550@C02TD0UTHF1T.local>
Message-ID: <20210429122605.GB214041@leoy-ThinkPad-X240s>

Hi Mark,

On Thu, Apr 29, 2021 at 11:48:13AM +0100, Mark Rutland wrote:

[...]

> > --- a/arch/arm64/kernel/stacktrace.c
> > +++ b/arch/arm64/kernel/stacktrace.c
> > @@ -145,7 +145,11 @@ void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
> >  		if (!fn(data, frame->pc))
> >  			break;
> >  		ret = unwind_frame(tsk, frame);
> > -		if (ret < 0)
> > +		/*
> > +		 * When the frame->pc is zero, it has reached to the initial pc
> > +		 * and fp values; stop unwinding for this case.
> > +		 */
> > +		if (ret < 0 || !frame->pc)
> >  			break;
> 
> I don't think this is the right place for this, since we intend
> unwind_frame() to detect when unwinding is finished; see commit:
> 
>   3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack")
> 
> I think we have three options for what to do here:
> 
> a) Revert 6106e1112cc69a36, and identify these cases as terminal records
>    where FP and LR are both NULL.
> 
> b) Have __primary_switched and __secondary_switched call start_kernel
>    and secondary_start_kernel with BL rather than B. The __*_switched
>    functions will show up in the trace, but we won't unwind any further
>    as the next record will have a NULL FP.
> 
> c) Revert 6106e1112cc69a36, create terminal records in
>    __primary_switched and __secondary_switched, and call start_kernel
>    and secondary_start_kernel with BL rather than B. The __*_switched
>    functions will show up in the trace, but we won't unwind any further
>    as the next record will be a terminal record.
> 
> For RELIABLE_STACKTRACE, we're going to have to do (c), I think, but for
> now we could do (a) so as to have a minimal fix, and we can build (c)
> atop that.
> 
> How about the patch below? I've tested it with your instructions and
> also by inspecting /proc/self/stack.

Thanks a lot for the quick fixing, and appreciate for sharing the
background knowledge!

> ---->8----
> From b99e647b34b74059f3013c09f12fbd542c7679fd Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland at arm.com>
> Date: Thu, 29 Apr 2021 11:20:04 +0100
> Subject: [PATCH] arm64: stacktrace: restore terminal records
> 
> We removed the terminal frame records in commit:
> 
>    6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> 
> ... on the assumption that as we no longer used them to find the pt_regs
> at exception boundaries, they were no longer necessary.
> 
> However, Leo reports that as an unintended side-effect, this causes
> traces which cross secondary_start_kernel to terminate one entry too
> late, with a spurious "0" entry.
> 
> There are a few ways we could sovle this, but as we're planning to use
> terminal records for RELIABLE_STACKTRACE, let's revert the logic change
> for now, keeping the update comments and accounting for the changes in
> commit:
> 
>   3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack")
> 
> This is effectively a partial revert of commit:
> 
>   6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Fixes: 6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> Reported-by: Leo Yan <leo.yan at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Mark Brown <broonie at kernel.org>
> Cc: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

For this patch, I tested at my side and it works as expected.  Though I
don't have complete knowledge for reviewing this patch, I went through
the history commits your mentioned and connected with this patch, it
looks good to me:

Tested-by: Leo Yan <leo.yan at linaro.org>

> ---
>  arch/arm64/kernel/entry.S      |  6 +++---
>  arch/arm64/kernel/stacktrace.c | 10 ++++++----
>  2 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 6acfc5e6b5e0..9b205744a233 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -263,16 +263,16 @@ alternative_else_nop_endif
>  	stp	lr, x21, [sp, #S_LR]
>  
>  	/*
> -	 * For exceptions from EL0, terminate the callchain here.
> +	 * For exceptions from EL0, create a terminal frame record.
>  	 * For exceptions from EL1, create a synthetic frame record so the
>  	 * interrupted code shows up in the backtrace.
>  	 */
>  	.if \el == 0
> -	mov	x29, xzr
> +	stp	xzr, xzr, [sp, #S_STACKFRAME]
>  	.else
>  	stp	x29, x22, [sp, #S_STACKFRAME]
> -	add	x29, sp, #S_STACKFRAME
>  	.endif
> +	add	x29, sp, #S_STACKFRAME
>  
>  #ifdef CONFIG_ARM64_SW_TTBR0_PAN
>  alternative_if_not ARM64_HAS_PAN
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index d55bdfb7789c..7032a5f9e624 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -44,10 +44,6 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  	unsigned long fp = frame->fp;
>  	struct stack_info info;
>  
> -	/* Terminal record; nothing to unwind */
> -	if (!fp)
> -		return -ENOENT;
> -
>  	if (fp & 0xf)
>  		return -EINVAL;
>  
> @@ -108,6 +104,12 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  
>  	frame->pc = ptrauth_strip_insn_pac(frame->pc);
>  
> +	/*
> +	 * This is a terminal record, so we have finished unwinding.
> +	 */
> +	if (!frame->fp && !frame->pc)
> +		return -ENOENT;
> +
>  	return 0;
>  }
>  NOKPROBE_SYMBOL(unwind_frame);
> -- 
> 2.11.0
> 
> 
>  


From catalin.marinas at arm.com  Thu Apr 29 13:32:43 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 29 Apr 2021 13:32:43 +0100
Subject: [PATCH] arm64: Generate cpucaps.h
In-Reply-To: <20210428121231.11219-1-broonie@kernel.org>
References: <20210428121231.11219-1-broonie@kernel.org>
Message-ID: <20210429123243.GA15092@arm.com>

On Wed, Apr 28, 2021 at 01:12:31PM +0100, Mark Brown wrote:
> The arm64 code allocates an internal constant to every CPU feature it can
> detect, distinct from the public hwcap numbers we use to expose some
> features to userspace. Currently this is maintained manually which is an
> irritating source of conflicts when working on new features, to avoid this
> replace the header with a simple text file listing the names we've assigned
> and sort it to minimise conflicts.
> 
> As part of doing this we also do the Kbuild hookup required to hook up
> an arch tools directory and to generate header files in there.
> 
> This will result in a renumbering and reordering of the existing constants,
> since they are all internal only the values should not be important. The
> reordering will impact the order in which some steps in enumeration handle
> features but the algorithm is not intended to depend on this and I haven't
> seen any issues when testing. Due to the UAO cpucap having been removed in
> the past we end up with ARM64_NCAPS being 1 smaller than it was before.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/Makefile              |  3 ++
>  arch/arm64/include/asm/Kbuild    |  2 +
>  arch/arm64/include/asm/cpucaps.h | 74 --------------------------------
>  arch/arm64/tools/Makefile        | 22 ++++++++++
>  arch/arm64/tools/cpucaps         | 65 ++++++++++++++++++++++++++++
>  arch/arm64/tools/gen-cpucaps.awk | 40 +++++++++++++++++
>  6 files changed, 132 insertions(+), 74 deletions(-)
>  delete mode 100644 arch/arm64/include/asm/cpucaps.h
>  create mode 100644 arch/arm64/tools/Makefile
>  create mode 100644 arch/arm64/tools/cpucaps
>  create mode 100755 arch/arm64/tools/gen-cpucaps.awk

It's a good cleanup, it saves us from always sorting out conflicts
around ARM64_NCAPS. I'll either take it during the merging window with
the for-next/fixes folded in or push it at -rc1 as there's a change in
cpucaps.h not currently in for-next/core.

Thanks.

-- 
Catalin


From geert+renesas at glider.be  Thu Apr 29 13:39:12 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Thu, 29 Apr 2021 14:39:12 +0200
Subject: [PATCH] arm64: dts: renesas: r8a7796[01]: Fix OPP table entry voltages
Message-ID: <b9e9db907514790574429b83d070c823b36085ef.1619699909.git.geert+renesas@glider.be>

Correct the voltages in the "Power Optimized" (<= 1.5 GHz) Cortex-A57
operating point table entries for the R-Car M3-W and M3-W+ SoCs from
0.82V to 0.83V, as per the R-Car Gen3 EC Manual Errata for Revision
0.53.

Based on a patch for R-Car M3-W in the BSP by Takeshi Kihara
<takeshi.kihara.df at renesas.com>.

Fixes: da7e3113344fda50 ("arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices")
Fixes: f51746ad7d1ff6b4 ("arm64: dts: renesas: Add Renesas R8A77961 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
To be queued in renesas-devel for v5.14.

 arch/arm64/boot/dts/renesas/r8a77960.dtsi | 6 +++---
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 63bb395a6a64499a..2bd8169735d351b2 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -63,17 +63,17 @@ cluster0_opp: opp_table0 {
 
 		opp-500000000 {
 			opp-hz = /bits/ 64 <500000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 		};
 		opp-1000000000 {
 			opp-hz = /bits/ 64 <1000000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 		};
 		opp-1500000000 {
 			opp-hz = /bits/ 64 <1500000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 			opp-suspend;
 		};
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index c8b73108a4c8185d..3c73ee47791542a9 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -52,17 +52,17 @@ cluster0_opp: opp_table0 {
 
 		opp-500000000 {
 			opp-hz = /bits/ 64 <500000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 		};
 		opp-1000000000 {
 			opp-hz = /bits/ 64 <1000000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 		};
 		opp-1500000000 {
 			opp-hz = /bits/ 64 <1500000000>;
-			opp-microvolt = <820000>;
+			opp-microvolt = <830000>;
 			clock-latency-ns = <300000>;
 			opp-suspend;
 		};
-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 13:39:36 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 07:39:36 -0500
Subject: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
In-Reply-To: <20210429073050.21039-1-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
Message-ID: <CAHCN7xL11GUSVB3PThsfhxXPtgu1nm1LWSzkJYqj4MHf-aLbVw@mail.gmail.com>

On Thu, Apr 29, 2021 at 1:59 AM Peng Fan (OSS) <peng.fan at oss.nxp.com> wrote:
>
> From: Peng Fan <peng.fan at nxp.com>
>
> This patchset is a pick up Lucas's gpcv2 work for i.MX8MM and several
> minor changes from me to make it could work with i.MX BLK-CTL driver.
>
> Thanks for Lucas's work and suggestion, Frieder Schrempf for collecting
> all the patches, Jacky Bai on help debug issues.

Thank for you all the work.  I have an i.MX8M Nano that I'll work to
add support for gpcv2 unless NXP has started this already.  At one
time, I posted some patches for Nano based on Lucas' work, but since
that work wasn't accepted, mine wasn't either.

adam
>
> Lucas Stach (12):
>   soc: imx: gpcv2: move to more ideomatic error handling in probe
>   soc: imx: gpcv2: move domain mapping to domain driver probe
>   soc: imx: gpcv2: switch to clk_bulk_* API
>   soc: imx: gpcv2: split power up and power down sequence control
>   soc: imx: gpcv2: wait for ADB400 handshake
>   soc: imx: gpcv2: add runtime PM support for power-domains
>   soc: imx: gpcv2: allow domains without power-sequence control
>   dt-bindings: imx: gpcv2: add support for optional resets
>   soc: imx: gpcv2: add support for optional resets
>   dt-bindings: power: add defines for i.MX8MM power domains
>   soc: imx: gpcv2: add support for i.MX8MM power domains
>   soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX power
>     domains
>
> Peng Fan (4):
>   soc: imx: gpcv2: correct pm_runtime_get_sync usage
>   soc: imx: gpcv2: move reset assert after requesting domain power up
>   soc: imx: gpcv2: support reset defer probe
>   soc: imx: gpcv2: remove waiting handshake in power up
>
>  .../bindings/power/fsl,imx-gpcv2.yaml         |   9 +
>  drivers/soc/imx/gpcv2.c                       | 534 ++++++++++++++----
>  include/dt-bindings/power/imx8mm-power.h      |  22 +
>  3 files changed, 450 insertions(+), 115 deletions(-)
>  create mode 100644 include/dt-bindings/power/imx8mm-power.h
>
> --
> 2.30.0
>


From geert+renesas at glider.be  Thu Apr 29 13:41:15 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Thu, 29 Apr 2021 14:41:15 +0200
Subject: [PATCH] ARM: dts: r8a7779, marzen: Fix DU clock names
Message-ID: <9d5e1b371121883b3b3e10a3df43802a29c6a9da.1619699965.git.geert+renesas@glider.be>

"make dtbs_check" complains:

    arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display at fff80000: clock-names:0: 'du.0' was expected

Change the first clock name to match the DT bindings.
This has no effect on actual operation, as the Display Unit driver in
Linux does not use the first clock name on R-Car H1, but just grabs the
first clock.

Fixes: 665d79aa47cb3983 ("ARM: shmobile: marzen: Add DU external pixel clock to DT")
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
To be queued in renesas-devel for v5.14.

 arch/arm/boot/dts/r8a7779-marzen.dts | 2 +-
 arch/arm/boot/dts/r8a7779.dtsi       | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
index d2240b89ee52929b..46584532349590d1 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -145,7 +145,7 @@ &du {
 	status = "okay";
 
 	clocks = <&mstp1_clks R8A7779_CLK_DU>, <&x3_clk>;
-	clock-names = "du", "dclkin.0";
+	clock-names = "du.0", "dclkin.0";
 
 	ports {
 		port at 0 {
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 74d7e9084eabe173..3c5fcdfe16b87182 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -463,6 +463,7 @@ du: display at fff80000 {
 		reg = <0xfff80000 0x40000>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7779_CLK_DU>;
+		clock-names = "du.0";
 		power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
 		status = "disabled";
 
-- 
2.25.1



From dan.carpenter at oracle.com  Thu Apr 29 14:03:58 2021
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 29 Apr 2021 16:03:58 +0300
Subject: [kbuild] Re: [PATCH] dmaengine: xilinx: dpdma: request_irq after
 initializing dma channels
In-Reply-To: <20210429065821.3495234-1-quanyang.wang@windriver.com>
Message-ID: <202104292042.oDy299s1-lkp@intel.com>

Hi,

url:    https://github.com/0day-ci/linux/commits/quanyang-wang-windriver-com/dmaengine-xilinx-dpdma-request_irq-after-initializing-dma-channels/20210429-150050 
base:   https://github.com/Xilinx/linux-xlnx  master
config: x86_64-randconfig-m001-20210429 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>
Reported-by: Dan Carpenter <dan.carpenter at oracle.com>

smatch warnings:
drivers/dma/xilinx/xilinx_dpdma.c:1778 xilinx_dpdma_probe() warn: missing error code 'ret'

vim +/ret +1778 drivers/dma/xilinx/xilinx_dpdma.c

7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1694  static int xilinx_dpdma_probe(struct platform_device *pdev)
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1695  {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1696  	struct xilinx_dpdma_device *xdev;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1697  	struct dma_device *ddev;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1698  	unsigned int i;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1699  	int ret;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1700  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1701  	xdev = devm_kzalloc(&pdev->dev, sizeof(*xdev), GFP_KERNEL);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1702  	if (!xdev)
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1703  		return -ENOMEM;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1704  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1705  	xdev->dev = &pdev->dev;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1706  	xdev->ext_addr = sizeof(dma_addr_t) > 4;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1707  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1708  	INIT_LIST_HEAD(&xdev->common.channels);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1709  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1710  	platform_set_drvdata(pdev, xdev);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1711  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1712  	xdev->axi_clk = devm_clk_get(xdev->dev, "axi_clk");
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1713  	if (IS_ERR(xdev->axi_clk))
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1714  		return PTR_ERR(xdev->axi_clk);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1715  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1716  	xdev->reg = devm_platform_ioremap_resource(pdev, 0);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1717  	if (IS_ERR(xdev->reg))
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1718  		return PTR_ERR(xdev->reg);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1719  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1720  	ddev = &xdev->common;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1721  	ddev->dev = &pdev->dev;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1722  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1723  	dma_cap_set(DMA_SLAVE, ddev->cap_mask);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1724  	dma_cap_set(DMA_PRIVATE, ddev->cap_mask);
b305dd098dae4f Rohit Visavalia  2021-04-07  1725  	dma_cap_set(DMA_CYCLIC, ddev->cap_mask);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1726  	dma_cap_set(DMA_INTERLEAVE, ddev->cap_mask);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1727  	dma_cap_set(DMA_REPEAT, ddev->cap_mask);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1728  	dma_cap_set(DMA_LOAD_EOT, ddev->cap_mask);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1729  	ddev->copy_align = fls(XILINX_DPDMA_ALIGN_BYTES - 1);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1730  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1731  	ddev->device_alloc_chan_resources = xilinx_dpdma_alloc_chan_resources;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1732  	ddev->device_free_chan_resources = xilinx_dpdma_free_chan_resources;
b305dd098dae4f Rohit Visavalia  2021-04-07  1733  	ddev->device_prep_dma_cyclic = xilinx_dpdma_prep_dma_cyclic;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1734  	ddev->device_prep_interleaved_dma = xilinx_dpdma_prep_interleaved_dma;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1735  	/* TODO: Can we achieve better granularity ? */
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1736  	ddev->device_tx_status = dma_cookie_status;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1737  	ddev->device_issue_pending = xilinx_dpdma_issue_pending;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1738  	ddev->device_config = xilinx_dpdma_config;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1739  	ddev->device_pause = xilinx_dpdma_pause;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1740  	ddev->device_resume = xilinx_dpdma_resume;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1741  	ddev->device_terminate_all = xilinx_dpdma_terminate_all;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1742  	ddev->device_synchronize = xilinx_dpdma_synchronize;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1743  	ddev->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1744  	ddev->directions = BIT(DMA_MEM_TO_DEV);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1745  	ddev->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1746  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1747  	for (i = 0; i < ARRAY_SIZE(xdev->chan); ++i) {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1748  		ret = xilinx_dpdma_chan_init(xdev, i);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1749  		if (ret < 0) {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1750  			dev_err(xdev->dev, "failed to initialize channel %u\n",
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1751  				i);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1752  			goto error;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1753  		}
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1754  	}
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1755  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1756  	ret = clk_prepare_enable(xdev->axi_clk);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1757  	if (ret) {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1758  		dev_err(xdev->dev, "failed to enable the axi clock\n");
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1759  		goto error;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1760  	}
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1761  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1762  	ret = dma_async_device_register(ddev);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1763  	if (ret) {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1764  		dev_err(xdev->dev, "failed to register the dma device\n");
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1765  		goto error_dma_async;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1766  	}
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1767  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1768  	ret = of_dma_controller_register(xdev->dev->of_node,
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1769  					 of_dma_xilinx_xlate, ddev);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1770  	if (ret) {
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1771  		dev_err(xdev->dev, "failed to register DMA to DT DMA helper\n");
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1772  		goto error_of_dma;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1773  	}
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1774  
50d6be0a1d25af Quanyang Wang    2021-04-29  1775  	xdev->irq = platform_get_irq(pdev, 0);
50d6be0a1d25af Quanyang Wang    2021-04-29  1776  	if (xdev->irq < 0) {
50d6be0a1d25af Quanyang Wang    2021-04-29  1777  		dev_err(xdev->dev, "failed to get platform irq\n");
50d6be0a1d25af Quanyang Wang    2021-04-29 @1778  		goto error_irq;

ret = xdev->irq;

50d6be0a1d25af Quanyang Wang    2021-04-29  1779  	}
50d6be0a1d25af Quanyang Wang    2021-04-29  1780  
50d6be0a1d25af Quanyang Wang    2021-04-29  1781  	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
50d6be0a1d25af Quanyang Wang    2021-04-29  1782  			  dev_name(xdev->dev), xdev);
50d6be0a1d25af Quanyang Wang    2021-04-29  1783  	if (ret) {
50d6be0a1d25af Quanyang Wang    2021-04-29  1784  		dev_err(xdev->dev, "failed to request IRQ\n");
50d6be0a1d25af Quanyang Wang    2021-04-29  1785  		goto error_irq;
50d6be0a1d25af Quanyang Wang    2021-04-29  1786  	}
50d6be0a1d25af Quanyang Wang    2021-04-29  1787  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1788  	xilinx_dpdma_enable_irq(xdev);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1789  
1d220435cab3bf Laurent Pinchart 2020-08-12  1790  	xilinx_dpdma_debugfs_init(xdev);
1d220435cab3bf Laurent Pinchart 2020-08-12  1791  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1792  	dev_info(&pdev->dev, "Xilinx DPDMA engine is probed\n");
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1793  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1794  	return 0;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1795  
50d6be0a1d25af Quanyang Wang    2021-04-29  1796  error_irq:
50d6be0a1d25af Quanyang Wang    2021-04-29  1797  	of_dma_controller_free(pdev->dev.of_node);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1798  error_of_dma:
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1799  	dma_async_device_unregister(ddev);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1800  error_dma_async:
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1801  	clk_disable_unprepare(xdev->axi_clk);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1802  error:
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1803  	for (i = 0; i < ARRAY_SIZE(xdev->chan); i++)
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1804  		xilinx_dpdma_chan_remove(xdev->chan[i]);
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1805  
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1806  	return ret;
7cbb0c63de3fc2 Hyun Kwon        2020-07-17  1807  }

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org 

_______________________________________________
kbuild mailing list -- kbuild at lists.01.org
To unsubscribe send an email to kbuild-leave at lists.01.org



From lkp at intel.com  Thu Apr 29 14:24:54 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 29 Apr 2021 21:24:54 +0800
Subject: [xlnx:master 93/407]
 drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:108:4: error: 'struct
 axienet_local' has no member named 'ptp_rx_irq'
Message-ID: <202104292146.yhzkFw1n-lkp@intel.com>

tree:   https://github.com/Xilinx/linux-xlnx master
head:   959c29b000f2d8576c7b56b53e559db140ee3952
commit: b4a6c96f858b3c2598343a5764add8a683dff7ef [93/407] net: xilinx: Refactor TSN functions into xilinx_tsn_ip.c
config: parisc-randconfig-r023-20210429 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/b4a6c96f858b3c2598343a5764add8a683dff7ef
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout b4a6c96f858b3c2598343a5764add8a683dff7ef
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/mm.h:99,
                    from include/linux/bvec.h:13,
                    from include/linux/skbuff.h:17,
                    from include/linux/if_ether.h:19,
                    from include/uapi/linux/ethtool.h:19,
                    from include/linux/ethtool.h:18,
                    from include/linux/netdevice.h:37,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:21:
   include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
   arch/parisc/include/asm/pgtable.h:91:9: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable]
      91 |   pte_t old_pte;     \
         |         ^~~~~~~
   arch/parisc/include/asm/pgtable.h:316:34: note: in expansion of macro 'set_pte_at'
     316 | #define pte_clear(mm, addr, xp)  set_pte_at(mm, addr, xp, __pte(0))
         |                                  ^~~~~~~~~~
   include/asm-generic/pgtable.h:201:2: note: in expansion of macro 'pte_clear'
     201 |  pte_clear(mm, address, ptep);
         |  ^~~~~~~~~
   include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
   arch/parisc/include/asm/pgtable.h:91:9: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable]
      91 |   pte_t old_pte;     \
         |         ^~~~~~~
   include/asm-generic/pgtable.h:629:2: note: in expansion of macro 'set_pte_at'
     629 |  set_pte_at(vma->vm_mm, addr, ptep, pte);
         |  ^~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c: In function 'axienet_tsn_probe':
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:108:4: error: 'struct axienet_local' has no member named 'ptp_rx_irq'
     108 |  lp->ptp_rx_irq = platform_get_irq_byname(pdev, irq_name);
         |    ^~
   In file included from include/linux/kernel.h:15,
                    from include/linux/list.h:9,
                    from include/linux/module.h:9,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:110:35: error: 'struct axienet_local' has no member named 'ptp_rx_irq'
     110 |  pr_info("ptp RX irq: %d %s\n", lp->ptp_rx_irq, irq_name);
         |                                   ^~
   include/linux/printk.h:311:34: note: in definition of macro 'pr_info'
     311 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
         |                                  ^~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:112:4: error: 'struct axienet_local' has no member named 'ptp_tx_irq'
     112 |  lp->ptp_tx_irq = platform_get_irq_byname(pdev, irq_name);
         |    ^~
   In file included from include/linux/kernel.h:15,
                    from include/linux/list.h:9,
                    from include/linux/module.h:9,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:113:35: error: 'struct axienet_local' has no member named 'ptp_tx_irq'
     113 |  pr_info("ptp TX irq: %d %s\n", lp->ptp_tx_irq, irq_name);
         |                                   ^~
   include/linux/printk.h:311:34: note: in definition of macro 'pr_info'
     311 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
         |                                  ^~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:116:4: error: 'struct axienet_local' has no member named 'qbv_irq'
     116 |  lp->qbv_irq = platform_get_irq_byname(pdev, irq_name);
         |    ^~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:119:8: error: 'struct axienet_local' has no member named 'qbv_irq'
     119 |  if (lp->qbv_irq > 0)
         |        ^~
   In file included from include/linux/kernel.h:15,
                    from include/linux/list.h:9,
                    from include/linux/module.h:9,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:120:33: error: 'struct axienet_local' has no member named 'qbv_irq'
     120 |   pr_info("qbv_irq: %d %s\n", lp->qbv_irq, irq_name);
         |                                 ^~
   include/linux/printk.h:311:34: note: in definition of macro 'pr_info'
     311 |  printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
         |                                  ^~~~~~~~~~~
   In file included from include/linux/seqlock.h:36,
                    from include/linux/time.h:6,
                    from include/linux/stat.h:19,
                    from include/linux/module.h:10,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:122:20: error: 'struct axienet_local' has no member named 'ptp_tx_lock'
     122 |  spin_lock_init(&lp->ptp_tx_lock);
         |                    ^~
   include/linux/spinlock.h:332:17: note: in definition of macro 'spin_lock_init'
     332 |  spinlock_check(_lock);    \
         |                 ^~~~~
   In file included from include/linux/seqlock.h:36,
                    from include/linux/time.h:6,
                    from include/linux/stat.h:19,
                    from include/linux/module.h:10,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:122:20: error: 'struct axienet_local' has no member named 'ptp_tx_lock'
     122 |  spin_lock_init(&lp->ptp_tx_lock);
         |                    ^~
   include/linux/spinlock.h:106:9: note: in definition of macro 'raw_spin_lock_init'
     106 |  do { *(lock) = __RAW_SPIN_LOCK_UNLOCKED(lock); } while (0)
         |         ^~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:122:2: note: in expansion of macro 'spin_lock_init'
     122 |  spin_lock_init(&lp->ptp_tx_lock);
         |  ^~~~~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:125:3: error: implicit declaration of function 'axienet_ptp_timer_probe'; did you mean 'axienet_tsn_probe'? [-Werror=implicit-function-declaration]
     125 |   axienet_ptp_timer_probe((lp->regs + XAE_RTC_OFFSET), pdev);
         |   ^~~~~~~~~~~~~~~~~~~~~~~
         |   axienet_tsn_probe
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:125:39: error: 'XAE_RTC_OFFSET' undeclared (first use in this function); did you mean 'XAE_TC_OFFSET'?
     125 |   axienet_ptp_timer_probe((lp->regs + XAE_RTC_OFFSET), pdev);
         |                                       ^~~~~~~~~~~~~~
         |                                       XAE_TC_OFFSET
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:125:39: note: each undeclared identifier is reported only once for each function it appears in
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:93:6: warning: unused variable 'ret' [-Wunused-variable]
      93 |  int ret = 0;
         |      ^~~
   In file included from include/linux/mm_types.h:16,
                    from include/linux/mmzone.h:21,
                    from include/linux/gfp.h:6,
                    from include/linux/umh.h:4,
                    from include/linux/kmod.h:9,
                    from include/linux/module.h:13,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:19:
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c: In function 'axienet_tsn_open':
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:15: error: 'struct axienet_local' has no member named 'tx_tstamp_work'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |               ^~
   include/linux/workqueue.h:242:16: note: in definition of macro '__INIT_WORK'
     242 |   __init_work((_work), _onstack);    \
         |                ^~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:2: note: in expansion of macro 'INIT_WORK'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |  ^~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:15: error: 'struct axienet_local' has no member named 'tx_tstamp_work'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |               ^~
   include/linux/workqueue.h:243:4: note: in definition of macro '__INIT_WORK'
     243 |   (_work)->data = (atomic_long_t) WORK_DATA_INIT(); \
         |    ^~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:2: note: in expansion of macro 'INIT_WORK'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |  ^~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:15: error: 'struct axienet_local' has no member named 'tx_tstamp_work'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |               ^~
   include/linux/workqueue.h:244:20: note: in definition of macro '__INIT_WORK'
     244 |   INIT_LIST_HEAD(&(_work)->entry);   \
         |                    ^~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:2: note: in expansion of macro 'INIT_WORK'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |  ^~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:15: error: 'struct axienet_local' has no member named 'tx_tstamp_work'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |               ^~
   include/linux/workqueue.h:245:4: note: in definition of macro '__INIT_WORK'
     245 |   (_work)->func = (_func);    \
         |    ^~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:2: note: in expansion of macro 'INIT_WORK'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |  ^~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:33: error: 'axienet_tx_tstamp' undeclared (first use in this function); did you mean 'axienet_tx_hwtstamp'?
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |                                 ^~~~~~~~~~~~~~~~~
   include/linux/workqueue.h:245:20: note: in definition of macro '__INIT_WORK'
     245 |   (_work)->func = (_func);    \
         |                    ^~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:279:2: note: in expansion of macro 'INIT_WORK'
     279 |  INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
         |  ^~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:280:25: error: 'struct axienet_local' has no member named 'ptp_txq'
     280 |  skb_queue_head_init(&lp->ptp_txq);
         |                         ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:282:4: error: 'struct axienet_local' has no member named 'ptp_rx_hw_pointer'
     282 |  lp->ptp_rx_hw_pointer = 0;
         |    ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:283:4: error: 'struct axienet_local' has no member named 'ptp_rx_sw_pointer'
     283 |  lp->ptp_rx_sw_pointer = 0xff;
         |    ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:285:18: error: 'PTP_RX_CONTROL_OFFSET' undeclared (first use in this function)
     285 |  axienet_iow(lp, PTP_RX_CONTROL_OFFSET, PTP_RX_PACKET_CLEAR);
         |                  ^~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:285:41: error: 'PTP_RX_PACKET_CLEAR' undeclared (first use in this function); did you mean 'PTR_TO_PACKET_END'?
     285 |  axienet_iow(lp, PTP_RX_CONTROL_OFFSET, PTP_RX_PACKET_CLEAR);
         |                                         ^~~~~~~~~~~~~~~~~~~
         |                                         PTR_TO_PACKET_END
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:287:22: error: 'struct axienet_local' has no member named 'ptp_rx_irq'
     287 |  ret = request_irq(lp->ptp_rx_irq, axienet_ptp_rx_irq,
         |                      ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:287:36: error: 'axienet_ptp_rx_irq' undeclared (first use in this function); did you mean 'axienet_rx_irq'?
     287 |  ret = request_irq(lp->ptp_rx_irq, axienet_ptp_rx_irq,
         |                                    ^~~~~~~~~~~~~~~~~~
         |                                    axienet_rx_irq
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:292:22: error: 'struct axienet_local' has no member named 'ptp_tx_irq'
     292 |  ret = request_irq(lp->ptp_tx_irq, axienet_ptp_tx_irq,
         |                      ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:292:36: error: 'axienet_ptp_tx_irq' undeclared (first use in this function); did you mean 'axienet_tx_irq'?
     292 |  ret = request_irq(lp->ptp_tx_irq, axienet_ptp_tx_irq,
         |                                    ^~~~~~~~~~~~~~~~~~
         |                                    axienet_tx_irq
   drivers/net/ethernet/xilinx/xilinx_tsn_ip.c:302:13: error: 'struct axienet_local' has no member named 'ptp_rx_irq'
     302 |  free_irq(lp->ptp_rx_irq, ndev);
         |             ^~
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for PTP_1588_CLOCK
   Depends on NET && POSIX_TIMERS
   Selected by
   - XILINX_AXI_EMAC_HWTSTAMP && NETDEVICES && ETHERNET && NET_VENDOR_XILINX && XILINX_AXI_EMAC


vim +108 drivers/net/ethernet/xilinx/xilinx_tsn_ip.c

    77	
    78	/**
    79	 * axienet_tsn_probe - TSN mac probe function.
    80	 * @pdev:	Pointer to platform device structure.
    81	 * @lp:		Pointer to axienet local structure
    82	 * @ndev:	Pointer to net_device structure.
    83	 *
    84	 * Return: 0, on success
    85	 *	    Non-zero error value on failure.
    86	 *
    87	 * This is the probe for TSN mac nodes.
    88	 */
    89	int axienet_tsn_probe(struct platform_device *pdev,
    90			      struct axienet_local *lp,
    91			      struct net_device *ndev)
    92	{
    93		int ret = 0;
    94		char irq_name[32];
    95		bool slave = false;
    96		u8     temac_no;
    97		struct device_node *ep_node;
    98		struct axienet_local *ep_lp;
    99	
   100		slave = of_property_read_bool(pdev->dev.of_node,
   101					      "xlnx,tsn-slave");
   102		if (slave)
   103			temac_no = XAE_TEMAC2;
   104		else
   105			temac_no = XAE_TEMAC1;
   106	
   107		sprintf(irq_name, "interrupt_ptp_rx_%d", temac_no + 1);
 > 108		lp->ptp_rx_irq = platform_get_irq_byname(pdev, irq_name);
   109	
   110		pr_info("ptp RX irq: %d %s\n", lp->ptp_rx_irq, irq_name);
   111		sprintf(irq_name, "interrupt_ptp_tx_%d", temac_no + 1);
 > 112		lp->ptp_tx_irq = platform_get_irq_byname(pdev, irq_name);
   113		pr_info("ptp TX irq: %d %s\n", lp->ptp_tx_irq, irq_name);
   114	
   115		sprintf(irq_name, "tsn_switch_scheduler_irq_%d", temac_no + 1);
 > 116		lp->qbv_irq = platform_get_irq_byname(pdev, irq_name);
   117	
   118		/*Ignoring if the qbv_irq is not exist*/
   119		if (lp->qbv_irq > 0)
   120			pr_info("qbv_irq: %d %s\n", lp->qbv_irq, irq_name);
   121	
   122		spin_lock_init(&lp->ptp_tx_lock);
   123	
   124		if (temac_no == XAE_TEMAC1)
 > 125			axienet_ptp_timer_probe((lp->regs + XAE_RTC_OFFSET), pdev);
   126	
   127		/* enable VLAN */
   128		lp->options |= XAE_OPTION_VLAN;
   129		axienet_setoptions(lp->ndev, lp->options);
   130	
   131		/* get the ep device */
   132		ep_node = of_parse_phandle(pdev->dev.of_node, "tsn,endpoint", 0);
   133	
   134		lp->master = of_find_net_device_by_node(ep_node);
   135	#ifdef CONFIG_XILINX_TSN_QBV
   136		ret = axienet_qbv_init(ndev);
   137	#endif
   138		/* EP+Switch */
   139		/* store the slaves to master(ep) */
   140		ep_lp = netdev_priv(lp->master);
   141		ep_lp->slaves[temac_no] = ndev;
   142	
   143		return 0;
   144	}
   145	
   146	/**
   147	 * axienet_device_reset - Reset and initialize the Axi Ethernet hardware.
   148	 * @ndev:	Pointer to the net_device structure
   149	 *
   150	 * This function is called to reset and initialize the Axi Ethernet core. This
   151	 * is typically called during initialization. It does a reset of the Axi DMA
   152	 * Rx/Tx channels and initializes the Axi DMA BDs. Since Axi DMA reset lines
   153	 * areconnected to Axi Ethernet reset lines, this in turn resets the Axi
   154	 * Ethernet core. No separate hardware reset is done for the Axi Ethernet
   155	 * core.
   156	 */
   157	static void axienet_device_reset(struct net_device *ndev)
   158	{
   159		u32 axienet_status;
   160		struct axienet_local *lp = netdev_priv(ndev);
   161	
   162		lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
   163	
   164		lp->options |= XAE_OPTION_VLAN;
   165		lp->options &= (~XAE_OPTION_JUMBO);
   166	
   167		if (ndev->mtu > XAE_MTU && ndev->mtu <= XAE_JUMBO_MTU) {
   168			lp->max_frm_size = ndev->mtu + VLAN_ETH_HLEN +
   169						XAE_TRL_SIZE;
   170			if (lp->max_frm_size <= lp->rxmem)
   171				lp->options |= XAE_OPTION_JUMBO;
   172		}
   173	
   174		axienet_status = axienet_ior(lp, XAE_RCW1_OFFSET);
   175		axienet_status &= ~XAE_RCW1_RX_MASK;
   176		axienet_iow(lp, XAE_RCW1_OFFSET, axienet_status);
   177	
   178		if (lp->axienet_config->mactype == XAXIENET_1G &&
   179		    !lp->eth_hasnobuf) {
   180			axienet_status = axienet_ior(lp, XAE_IP_OFFSET);
   181			if (axienet_status & XAE_INT_RXRJECT_MASK)
   182				axienet_iow(lp, XAE_IS_OFFSET, XAE_INT_RXRJECT_MASK);
   183	
   184			/* Enable Receive errors */
   185			axienet_iow(lp, XAE_IE_OFFSET, XAE_INT_RECV_ERROR_MASK);
   186		}
   187	
   188		axienet_iow(lp, XAE_FCC_OFFSET, XAE_FCC_FCRX_MASK);
   189		lp->axienet_config->setoptions(ndev, lp->options &
   190					       ~(XAE_OPTION_TXEN | XAE_OPTION_RXEN));
   191	
   192		axienet_set_mac_address(ndev, NULL);
   193		axienet_set_multicast_list(ndev);
   194		lp->axienet_config->setoptions(ndev, lp->options);
   195	
   196		netif_trans_update(ndev);
   197	}
   198	
   199	/**
   200	 * axienet_mii_init - MII init routine
   201	 * @ndev:	Pointer to net_device structure.
   202	 *
   203	 * Return: 0, on success
   204	 *	    Non-zero error value on failure.
   205	 *
   206	 * This routine initializes MII.
   207	 */
   208	static int axienet_mii_init(struct net_device *ndev)
   209	{
   210		struct axienet_local *lp = netdev_priv(ndev);
   211		int ret, mdio_mcreg;
   212	
   213		mdio_mcreg = axienet_ior(lp, XAE_MDIO_MC_OFFSET);
   214		ret = axienet_mdio_wait_until_ready(lp);
   215		if (ret < 0)
   216			return ret;
   217	
   218		/* Disable the MDIO interface till Axi Ethernet Reset is completed.
   219		 * When we do an Axi Ethernet reset, it resets the complete core
   220		 * Including the MDIO. If MDIO is not disabled when the reset process is
   221		 * Started, MDIO will be broken afterwards.
   222		 */
   223		axienet_iow(lp, XAE_MDIO_MC_OFFSET,
   224			    (mdio_mcreg & (~XAE_MDIO_MC_MDIOEN_MASK)));
   225		axienet_device_reset(ndev);
   226		/* Enable the MDIO */
   227		axienet_iow(lp, XAE_MDIO_MC_OFFSET, mdio_mcreg);
   228		ret = axienet_mdio_wait_until_ready(lp);
   229		if (ret < 0)
   230			return ret;
   231	
   232		return 0;
   233	}
   234	
   235	/**
   236	 * axienet_tsn_open - TSN driver open routine.
   237	 * @ndev:	Pointer to net_device structure
   238	 *
   239	 * Return: 0, on success.
   240	 *	    non-zero error value on failure
   241	 *
   242	 * This is the driver open routine. It calls phy_start to start the PHY device.
   243	 * It also allocates interrupt service routines, enables the interrupt lines
   244	 * and ISR handling. Axi Ethernet core is reset through Axi DMA core.
   245	 */
   246	int axienet_tsn_open(struct net_device *ndev)
   247	{
   248		int ret;
   249		struct axienet_local *lp = netdev_priv(ndev);
   250		struct phy_device *phydev = NULL;
   251	
   252		ret = axienet_mii_init(ndev);
   253		if (ret < 0)
   254			return ret;
   255	
   256		if (lp->phy_node) {
   257			if (lp->phy_mode == XAE_PHY_TYPE_GMII) {
   258				phydev = of_phy_connect(lp->ndev, lp->phy_node,
   259							axienet_adjust_link, 0,
   260							PHY_INTERFACE_MODE_GMII);
   261			} else if (lp->phy_mode == XAE_PHY_TYPE_RGMII_2_0) {
   262				phydev = of_phy_connect(lp->ndev, lp->phy_node,
   263							axienet_adjust_link, 0,
   264							PHY_INTERFACE_MODE_RGMII_ID);
   265			} else if ((lp->axienet_config->mactype == XAXIENET_1G) ||
   266				     (lp->axienet_config->mactype == XAXIENET_2_5G)) {
   267				phydev = of_phy_connect(lp->ndev, lp->phy_node,
   268							axienet_adjust_link,
   269							lp->phy_flags,
   270							lp->phy_interface);
   271			}
   272	
   273			if (!phydev)
   274				dev_err(lp->dev, "of_phy_connect() failed\n");
   275			else
   276				phy_start(phydev);
   277		}
   278	
 > 279		INIT_WORK(&lp->tx_tstamp_work, axienet_tx_tstamp);
 > 280		skb_queue_head_init(&lp->ptp_txq);
   281	
 > 282		lp->ptp_rx_hw_pointer = 0;
 > 283		lp->ptp_rx_sw_pointer = 0xff;
   284	
 > 285		axienet_iow(lp, PTP_RX_CONTROL_OFFSET, PTP_RX_PACKET_CLEAR);
   286	
 > 287		ret = request_irq(lp->ptp_rx_irq, axienet_ptp_rx_irq,
   288				  0, "ptp_rx", ndev);
   289		if (ret)
   290			goto err_ptp_rx_irq;
   291	
 > 292		ret = request_irq(lp->ptp_tx_irq, axienet_ptp_tx_irq,
   293				  0, "ptp_tx", ndev);
   294		if (ret)
   295			goto err_ptp_tx_irq;
   296	
   297		netif_tx_start_all_queues(ndev);
   298	
   299		return 0;
   300	
   301	err_ptp_tx_irq:
   302		free_irq(lp->ptp_rx_irq, ndev);
   303	err_ptp_rx_irq:
   304		return ret;
   305	}
   306	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 21534 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210429/9c1675ec/attachment-0001.gz>

From maz at kernel.org  Thu Apr 29 14:35:32 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 29 Apr 2021 14:35:32 +0100
Subject: [PATCH 1/2] firmware/efi: Tell memblock about EFI reservations
In-Reply-To: <20210429133533.1750721-1-maz@kernel.org>
References: <20210429133533.1750721-1-maz@kernel.org>
Message-ID: <20210429133533.1750721-2-maz@kernel.org>

kexec_load_file() relies on the memblock infrastructure to avoid
stamping over regions of memory that are essential to the survival
of the system.

However, nobody seems to agree how to flag these regions as reserved,
and (for example) EFI only publishes its reservations in /proc/iomem
for the benefit of the traditional, userspace based kexec tool.

On arm64 platforms with GICv3, this can result in the payload being
placed at the location of the LPI tables. Shock, horror!

Let's augment the EFI reservation code with a memblock_reserve() call,
protecting our dear tables from the secondary kernel invasion.

At some point, someone will have to go and figure out a way to unify
these multiple reservation trees, because sprinkling random reservation
calls is only a temporary workaround.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 drivers/firmware/efi/efi.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4b7ee3fa9224..026b02f5f7d8 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -896,11 +896,25 @@ static int __init efi_memreserve_map_root(void)
 static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size)
 {
 	struct resource *res, *parent;
+	int ret;
 
 	res = kzalloc(sizeof(struct resource), GFP_ATOMIC);
 	if (!res)
 		return -ENOMEM;
 
+	/*
+	 * Given that efi_mem_reserve_iomem() can be called at any
+	 * time, only call memblock_reserve() if the architecture
+	 * keeps the infrastructure around.
+	 */
+	if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
+		ret = memblock_reserve(addr, size);
+		if (ret) {
+			kfree(res);
+			return ret;
+		}
+	}
+
 	res->name	= "reserved";
 	res->flags	= IORESOURCE_MEM;
 	res->start	= addr;
@@ -908,7 +922,14 @@ static int efi_mem_reserve_iomem(phys_addr_t addr, u64 size)
 
 	/* we expect a conflict with a 'System RAM' region */
 	parent = request_resource_conflict(&iomem_resource, res);
-	return parent ? request_resource(parent, res) : 0;
+	ret = parent ? request_resource(parent, res) : 0;
+	if (ret) {
+		kfree(res);
+		if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK))
+			memblock_free(addr, size);
+	}
+
+	return ret;
 }
 
 int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
-- 
2.29.2



From maz at kernel.org  Thu Apr 29 14:35:31 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 29 Apr 2021 14:35:31 +0100
Subject: [PATCH 0/2] arm64: kexec_file_load vs memory reservations
Message-ID: <20210429133533.1750721-1-maz@kernel.org>

It recently became apparent that using kexec with kexec_file_load() on
arm64 is pretty similar to playing Russian roulette.

Depending on the amount of memory, the HW supported and the firmware
interface used, your secondary kernel may overwrite critical memory
regions without which the secondary kernel cannot boot (the GICv3 LPI
tables being a prime example of such reserved regions).

It turns out that there is at least two ways for reserved memory
regions to be described to kexec: /proc/iomem for the userspace
implementation, and memblock.reserved for kexec_file. And of course,
our LPI tables are only reserved using the resource tree, leading to
the aforementioned stamping. Similar things could happen with ACPI
tables as well.

On my 24xA53 system artificially limited to 256MB of RAM (yes, it
boots with that little memory), trying to kexec a secondary kernel
failed every times. I can only presume that this was mostly tested
using kdump, which preserves the entire kernel memory range.

This small series aims at triggering a discussion on what are the
expectations for kexec_file, and whether we should unify the two
reservation mechanisms.

And in the meantime, it gets things going...

Marc Zyngier (2):
  firmware/efi: Tell memblock about EFI reservations
  ACPI: arm64: Reserve the ACPI tables in memblock

 arch/arm64/kernel/acpi.c   |  1 +
 drivers/firmware/efi/efi.c | 23 ++++++++++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)

-- 
2.29.2



From maz at kernel.org  Thu Apr 29 14:35:33 2021
From: maz at kernel.org (Marc Zyngier)
Date: Thu, 29 Apr 2021 14:35:33 +0100
Subject: [PATCH 2/2] ACPI: arm64: Reserve the ACPI tables in memblock
In-Reply-To: <20210429133533.1750721-1-maz@kernel.org>
References: <20210429133533.1750721-1-maz@kernel.org>
Message-ID: <20210429133533.1750721-3-maz@kernel.org>

Just like the EFI reservations, ACPI tables can be stamped over
by kexec_file_load(), and the secondary kernel will be unable to
recover from such corruption.

It looks like our x86 friends have been there before, and have
recently added some infratructure that does what we need since
1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI
tables"), though it appears to exist for different reasons.

Let's call into acpi_reserve_initial_tables() early so that
our tables are protected from the big bad kexec.

Signed-off-by: Marc Zyngier <maz at kernel.org>
---
 arch/arm64/kernel/acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index cada0b816c8a..5b5406c92ee4 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -233,6 +233,7 @@ void __init acpi_boot_table_init(void)
 		if (earlycon_acpi_spcr_enable)
 			early_init_dt_scan_chosen_stdout();
 	} else {
+		acpi_reserve_initial_tables();
 		acpi_parse_spcr(earlycon_acpi_spcr_enable, true);
 		if (IS_ENABLED(CONFIG_ACPI_BGRT))
 			acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
-- 
2.29.2



From ezequiel at collabora.com  Thu Apr 29 14:43:25 2021
From: ezequiel at collabora.com (Ezequiel Garcia)
Date: Thu, 29 Apr 2021 10:43:25 -0300
Subject: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver
In-Reply-To: <20210420121046.181889-7-benjamin.gaignard@collabora.com>
References: <20210420121046.181889-1-benjamin.gaignard@collabora.com>
 <20210420121046.181889-7-benjamin.gaignard@collabora.com>
Message-ID: <47800413ff99225e39f46c841bfb8061aee6d1b6.camel@collabora.com>

On Tue, 2021-04-20 at 14:10 +0200, Benjamin Gaignard wrote:
> The HEVC HANTRO driver needs to know the number of bits to skip at
> the beginning of the slice header.
> That is a hardware specific requirement so create a dedicated control
> for this purpose.
> 
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>

Reviewed-by: Ezequiel Garcia <ezequiel at collabora.com>

> ---
> ?.../userspace-api/media/drivers/hantro.rst??? | 19 +++++++++++++++++++
> ?.../userspace-api/media/drivers/index.rst???? |? 1 +
> ?include/media/hevc-ctrls.h??????????????????? | 13 +++++++++++++
> ?3 files changed, 33 insertions(+)
> ?create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst
> 
> diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst
> new file mode 100644
> index 000000000000..cd9754b4e005
> --- /dev/null
> +++ b/Documentation/userspace-api/media/drivers/hantro.rst
> @@ -0,0 +1,19 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Hantro video decoder driver
> +===========================
> +
> +The Hantro video decoder driver implements the following driver-specific controls:
> +
> +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)``
> +??? Specifies to Hantro HEVC video decoder driver the number of data (in bits) to
> +??? skip in the slice segment header.
> +??? If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
> +??? to before syntax element "slice_temporal_mvp_enabled_flag".
> +??? If IDR, the skipped bits are just "pic_output_flag"
> +??? (separate_colour_plane_flag is not supported).
> +
> +.. note::
> +
> +??????? This control is not yet part of the public kernel API and
> +??????? it is expected to change.
> diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst
> index 1a9038f5f9fa..12e3c512d718 100644
> --- a/Documentation/userspace-api/media/drivers/index.rst
> +++ b/Documentation/userspace-api/media/drivers/index.rst
> @@ -33,6 +33,7 @@ For more details see the file COPYING in the source distribution of Linux.
> ?
> ????????ccs
> ????????cx2341x-uapi
> +??????? hantro
> ????????imx-uapi
> ????????max2175
> ????????meye-uapi
> diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
> index 8e0109eea454..b713eeed1915 100644
> --- a/include/media/hevc-ctrls.h
> +++ b/include/media/hevc-ctrls.h
> @@ -224,4 +224,17 @@ struct v4l2_ctrl_hevc_decode_params {
> ????????__u64???flags;
> ?};
> ?
> +/*? MPEG-class control IDs specific to the Hantro driver as defined by V4L2 */
> +#define V4L2_CID_CODEC_HANTRO_BASE?????????????????????????????(V4L2_CTRL_CLASS_CODEC | 0x1200)
> +/*
> + * V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP -
> + * the number of data (in bits) to skip in the
> + * slice segment header.
> + * If non-IDR, the bits to be skipped go from syntax element "pic_output_flag"
> + * to before syntax element "slice_temporal_mvp_enabled_flag".
> + * If IDR, the skipped bits are just "pic_output_flag"
> + * (separate_colour_plane_flag is not supported).
> + */
> +#define V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP?(V4L2_CID_CODEC_HANTRO_BASE + 0)
> +
> ?#endif




From ameynarkhede03 at gmail.com  Thu Apr 29 14:47:49 2021
From: ameynarkhede03 at gmail.com (Amey Narkhede)
Date: Thu, 29 Apr 2021 19:17:49 +0530
Subject: [PATCH] PCI: mediatek: Verify whether the free_ck clock is ungated or
 not
Message-ID: <20210429134749.75157-1-ameynarkhede03@gmail.com>

Verify that the free_ck clock is ungated on device resume
by checking return value of clk_prepare_enable().

Signed-off-by: Amey Narkhede <ameynarkhede03 at gmail.com>
---
 drivers/pci/controller/pcie-mediatek.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 23548b517..9b13214bf 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1154,11 +1154,14 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
 {
 	struct mtk_pcie *pcie = dev_get_drvdata(dev);
 	struct mtk_pcie_port *port, *tmp;
+	int ret;

 	if (list_empty(&pcie->ports))
 		return 0;

-	clk_prepare_enable(pcie->free_ck);
+	ret = clk_prepare_enable(pcie->free_ck);
+	if (ret)
+		return ret;

 	list_for_each_entry_safe(port, tmp, &pcie->ports, list)
 		mtk_pcie_enable_port(port);
--
2.31.1


From sneeli at xilinx.com  Thu Apr 29 14:59:27 2021
From: sneeli at xilinx.com (Srinivas Neeli)
Date: Thu, 29 Apr 2021 13:59:27 +0000
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
In-Reply-To: <YIP9ltcdf7mNtYRd@smile.fi.intel.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
 <YIP9ltcdf7mNtYRd@smile.fi.intel.com>
Message-ID: <BL0PR02MB537807ED9F079ABF6F34B086AF5F9@BL0PR02MB5378.namprd02.prod.outlook.com>

Hi Bartosz,

> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Sent: Saturday, April 24, 2021 4:45 PM
> To: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> Cc: linux-gpio <linux-gpio at vger.kernel.org>; arm-soc <linux-arm-
> kernel at lists.infradead.org>; LKML <linux-kernel at vger.kernel.org>;
> Shubhrajyoti Datta <shubhraj at xilinx.com>; Srinivas Neeli
> <sneeli at xilinx.com>; Michal Simek <michals at xilinx.com>; Linus Walleij
> <linus.walleij at linaro.org>; Yury Norov <yury.norov at gmail.com>; Rasmus
> Villemoes <linux at rasmusvillemoes.dk>; Syed Nayyar Waris
> <syednwaris at gmail.com>; William Breathitt Gray <vilhelm.gray at gmail.com>
> Subject: Re: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
> 
> On Fri, Apr 23, 2021 at 10:41:26PM +0200, Bartosz Golaszewski wrote:
> > On Thu, Apr 8, 2021 at 4:55 PM Andy Shevchenko
> > <andriy.shevchenko at linux.intel.com> wrote:
> > >
> > > The change in the series has been inspired by [1], which, I think,
> > > can be improved. Here I present the view how it can be done.
> > >
> > > The series marked as RFT since I have no hardware and I perform
> > > compile test only.
> > >
> > > The patches 1 and 2 can be (independently) applied for v5.13, but
> > > I'm not in hurry with the series, due to above (lack of real
> > > testing). So I'm flexible in a way how it can be proceed.
> 
> > >   bitmap: Make bitmap_remap() and bitmap_bitremap() available to
> users
> > >   gpio: xilinx: Correct kernel doc for xgpio_probe()
> 
> Bart, thanks for the warm words, just pointing out that patches 1 and 2 has
> been reviewed and may be applied for v5.13 cycle. Up to you.
> 
> > I usually trust Andy with his work but is there any chance we can get
> > a Tested-by before the merge window?

Patches tested. Functionality working fine.

Tested-by: Neeli Srinivas <sneeli at xilinx.com>

> 
> --
> With Best Regards,
> Andy Shevchenko
> 



From alice.guo at oss.nxp.com  Thu Apr 29 15:02:49 2021
From: alice.guo at oss.nxp.com (Alice Guo (OSS))
Date: Thu, 29 Apr 2021 22:02:49 +0800
Subject: [PATCH v1 1/2] caam: imx8m: fix the built-in caam driver cannot match
 soc_id
Message-ID: <20210429140250.2321-1-alice.guo@oss.nxp.com>

From: Alice Guo <alice.guo at nxp.com>

drivers/soc/imx/soc-imx8m.c is probed later than the caam driver so that
return -EPROBE_DEFER is needed after calling soc_device_match() in
drivers/crypto/caam/ctrl.c. For i.MX8M, soc_device_match returning NULL
can be considered that the SoC device has not been probed yet, so it
returns -EPROBE_DEFER directly.

Fixes: 7d981405d0fd ("soc: imx8m: change to use platform driver")
Signed-off-by: Alice Guo <alice.guo at nxp.com>
---
 drivers/crypto/caam/ctrl.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index ca0361b2dbb0..9bba3b93cf35 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -79,6 +79,14 @@ static void build_deinstantiation_desc(u32 *desc, int handle)
 	append_jump(desc, JUMP_CLASS_CLASS1 | JUMP_TYPE_HALT);
 }

+static const struct of_device_id imx8m_machine_match[] = {
+	{ .compatible = "fsl,imx8mm", },
+	{ .compatible = "fsl,imx8mn", },
+	{ .compatible = "fsl,imx8mp", },
+	{ .compatible = "fsl,imx8mq", },
+	{ }
+};
+
 /*
  * run_descriptor_deco0 - runs a descriptor on DECO0, under direct control of
  *			  the software (no JR/QI used).
@@ -635,6 +643,8 @@ static int caam_probe(struct platform_device *pdev)
 	nprop = pdev->dev.of_node;

 	imx_soc_match = soc_device_match(caam_imx_soc_table);
+	if (!imx_soc_match && of_match_node(imx8m_machine_match, of_root))
+		return -EPROBE_DEFER;
 	caam_imx = (bool)imx_soc_match;

 	if (imx_soc_match) {
--
2.17.1



From alice.guo at oss.nxp.com  Thu Apr 29 15:02:50 2021
From: alice.guo at oss.nxp.com (Alice Guo (OSS))
Date: Thu, 29 Apr 2021 22:02:50 +0800
Subject: [PATCH v1 2/2] caam: imx8m: change to use of_match_node in
 run_descriptor_deco0
In-Reply-To: <20210429140250.2321-1-alice.guo@oss.nxp.com>
References: <20210429140250.2321-1-alice.guo@oss.nxp.com>
Message-ID: <20210429140250.2321-2-alice.guo@oss.nxp.com>

From: Alice Guo <alice.guo at nxp.com>

Patch "fix the built-in caam driver cannot match soc_id" provides
imx8m_machine_match to match i.MX8M{Q,M,N,P}, so change to use to
of_match_node which can simplify the code.

Signed-off-by: Alice Guo <alice.guo at nxp.com>
---
 drivers/crypto/caam/ctrl.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 9bba3b93cf35..7e6a525e0c11 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -113,10 +113,7 @@ static inline int run_descriptor_deco0(struct device *ctrldev, u32 *desc,
 	     * Apparently on i.MX8M{Q,M,N,P} it doesn't matter if virt_en == 1
 	     * and the following steps should be performed regardless
 	     */
-	    of_machine_is_compatible("fsl,imx8mq") ||
-	    of_machine_is_compatible("fsl,imx8mm") ||
-	    of_machine_is_compatible("fsl,imx8mn") ||
-	    of_machine_is_compatible("fsl,imx8mp")) {
+	    of_match_node(imx8m_machine_match, of_root)) {
 		clrsetbits_32(&ctrl->deco_rsr, 0, DECORSR_JR0);

 		while (!(rd_reg32(&ctrl->deco_rsr) & DECORSR_VALID) &&
--
2.17.1



From nava.manne at xilinx.com  Thu Apr 29 15:04:04 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 19:34:04 +0530
Subject: [PATCH v4 0/4] Add Bitstream configuration support for Versal
Message-ID: <20210429140408.23194-1-nava.manne@xilinx.com>

This series Adds FPGA manager driver support for Xilinx Versal SoC.
it uses the firmware interface to configure the programmable logic.

Changes for v4:
		-Rebase the patch series on linux-next.
		https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Appana Durga Kedareswara rao (1):
  dt-bindings: fpga: Add binding doc for versal fpga manager

Nava kishore Manne (3):
  dt-bindings: firmware: Add bindings for xilinx firmware
  drivers: firmware: Add PDI load API support
  fpga: versal-fpga: Add versal fpga manager driver

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml |  63 ++++++++++
 .../bindings/fpga/xlnx,versal-fpga.yaml       |  33 +++++
 drivers/firmware/xilinx/zynqmp.c              |  17 +++
 drivers/fpga/Kconfig                          |   9 ++
 drivers/fpga/Makefile                         |   1 +
 drivers/fpga/versal-fpga.c                    | 117 ++++++++++++++++++
 include/linux/firmware/xlnx-zynqmp.h          |  10 ++
 7 files changed, 250 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
 create mode 100644 drivers/fpga/versal-fpga.c

-- 
2.17.1



From festevam at gmail.com  Thu Apr 29 15:04:58 2021
From: festevam at gmail.com (Fabio Estevam)
Date: Thu, 29 Apr 2021 11:04:58 -0300
Subject: [PATCH v1 2/2] caam: imx8m: change to use of_match_node in
 run_descriptor_deco0
In-Reply-To: <20210429140250.2321-2-alice.guo@oss.nxp.com>
References: <20210429140250.2321-1-alice.guo@oss.nxp.com>
 <20210429140250.2321-2-alice.guo@oss.nxp.com>
Message-ID: <CAOMZO5Cbfh3Aj5-i2y+GDZ=-SZw-wLMbPMew=YTcf9Yr6ohVCw@mail.gmail.com>

Hi Alice

On Thu, Apr 29, 2021 at 11:02 AM Alice Guo (OSS) <alice.guo at oss.nxp.com> wrote:
>
> From: Alice Guo <alice.guo at nxp.com>
>
> Patch "fix the built-in caam driver cannot match soc_id" provides
> imx8m_machine_match to match i.MX8M{Q,M,N,P}, so change to use to
> of_match_node which can simplify the code.

Shouldn't these patches be squashed?


From nava.manne at xilinx.com  Thu Apr 29 15:04:05 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 19:34:05 +0530
Subject: [PATCH v4 1/4] dt-bindings: firmware: Add bindings for xilinx firmware
In-Reply-To: <20210429140408.23194-1-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
Message-ID: <20210429140408.23194-2-nava.manne@xilinx.com>

Add documentation to describe Xilinx firmware driver bindings.
Firmware driver provides an interface to firmware APIs.
Interface APIs can be used by any driver to communicate
to Platform Management Unit.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
Changes for v4:
                -Added new yaml file for xilinx firmware
                 as suggested by Rob.

 .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 63 +++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml

diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
new file mode 100644
index 000000000000..4b97f005bed7
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx firmware driver
+
+maintainers:
+  - Nava kishore Manne <nava.manne at xilinx.com>
+
+description:
+  The zynqmp-firmware node describes the interface to platform firmware.
+  ZynqMP has an interface to communicate with secure firmware. Firmware
+  driver provides an interface to firmware APIs. Interface APIs can be
+  used by any driver to communicate to PMUFW(Platform Management Unit).
+  These requests include clock management, pin control, device control,
+  power management service, FPGA service and other platform management
+  services.
+
+properties:
+  compatible:
+    oneOf:
+      - description:
+          For implementations complying for Zynq Ultrascale+ MPSoC.
+        const: xlnx,zynqmp-firmware
+
+      - description:
+          For implementations complying for Versal.
+        const: xlnx,versal-firmware
+
+  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-array
+    enum:
+      - smc
+      - hvc
+
+patternProperties:
+  "fpga":
+    description: Compatible of the FPGA device.
+    type: object
+
+    required:
+      - compatible
+
+required:
+  - compatible
+
+examples:
+  - |
+    versal-firmware {
+      compatible = "xlnx,versal-firmware";
+      method = "smc";
+      fpga {
+        compatible = "xlnx,versal-fpga";
+      };
+    };
+
+additionalProperties: false
-- 
2.17.1



From nava.manne at xilinx.com  Thu Apr 29 15:04:06 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 19:34:06 +0530
Subject: [PATCH v4 2/4] drivers: firmware: Add PDI load API support
In-Reply-To: <20210429140408.23194-1-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
Message-ID: <20210429140408.23194-3-nava.manne@xilinx.com>

This patch adds load PDI API support to enable full/partial PDI loading
from linux. Programmable Device Image (PDI) is combination of headers,
images and bitstream files to be loaded.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
Changes for v2:
                -Updated API Doc and commit msg.
                 No functional changes.
Changes for v3:
                -None.
Changes for v4:
                -Rebased the changes on linux-next.
                 No functional changes

 drivers/firmware/xilinx/zynqmp.c     | 17 +++++++++++++++++
 include/linux/firmware/xlnx-zynqmp.h | 10 ++++++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 15b138326ecc..2db571da9ad8 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -1011,6 +1011,23 @@ int zynqmp_pm_set_requirement(const u32 node, const u32 capabilities,
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_set_requirement);
 
+/**
+ * zynqmp_pm_load_pdi - Load and process PDI
+ * @src:       Source device where PDI is located
+ * @address:   PDI src address
+ *
+ * This function provides support to load PDI from linux
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_load_pdi(const u32 src, const u64 address)
+{
+	return zynqmp_pm_invoke_fn(PM_LOAD_PDI, src,
+				   lower_32_bits(address),
+				   upper_32_bits(address), 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_load_pdi);
+
 /**
  * zynqmp_pm_aes - Access AES hardware to encrypt/decrypt the data using
  * AES-GCM core.
diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
index 9d1a5c175065..56b426fe020c 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -52,6 +52,10 @@
 #define	ZYNQMP_PM_CAPABILITY_WAKEUP	0x4U
 #define	ZYNQMP_PM_CAPABILITY_UNUSABLE	0x8U
 
+/* Loader commands */
+#define PM_LOAD_PDI	0x701
+#define PDI_SRC_DDR	0xF
+
 /*
  * Firmware FPGA Manager flags
  * XILINX_ZYNQMP_PM_FPGA_FULL:	FPGA full reconfiguration
@@ -411,6 +415,7 @@ int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
 				 u32 *value);
 int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
 				 u32 value);
+int zynqmp_pm_load_pdi(const u32 src, const u64 address);
 #else
 static inline int zynqmp_pm_get_api_version(u32 *version)
 {
@@ -622,6 +627,11 @@ static inline int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
 {
 	return -ENODEV;
 }
+
+static inline int zynqmp_pm_load_pdi(const u32 src, const u64 address)
+{
+	return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1



From nava.manne at xilinx.com  Thu Apr 29 15:04:07 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 19:34:07 +0530
Subject: [PATCH v4 3/4] dt-bindings: fpga: Add binding doc for versal fpga
 manager
In-Reply-To: <20210429140408.23194-1-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
Message-ID: <20210429140408.23194-4-nava.manne@xilinx.com>

From: Appana Durga Kedareswara rao <appana.durga.rao at xilinx.com>

This patch adds binding doc for versal fpga manager driver.

Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao at xilinx.com>
---
Changes for v2:
                -Fixed file format and syntax issues.
Changes for v3:
                -Removed unwated extra spaces.
Changes for v4:
                -Rebased the changes on linux-next.
                 No functional changes

 .../bindings/fpga/xlnx,versal-fpga.yaml       | 33 +++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml

diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
new file mode 100644
index 000000000000..fec6144766fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/fpga/xlnx,versal-fpga.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal FPGA driver.
+
+maintainers:
+  - Nava kishore Manne <nava.manne at xilinx.com>
+
+description: |
+  Device Tree Versal FPGA bindings for the Versal SoC, controlled
+  using firmware interface.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - xlnx,versal-fpga
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+    versal_fpga: fpga {
+         compatible = "xlnx,versal-fpga";
+    };
+
+...
-- 
2.17.1



From nava.manne at xilinx.com  Thu Apr 29 15:04:08 2021
From: nava.manne at xilinx.com (Nava kishore Manne)
Date: Thu, 29 Apr 2021 19:34:08 +0530
Subject: [PATCH v4 4/4] fpga: versal-fpga: Add versal fpga manager driver
In-Reply-To: <20210429140408.23194-1-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
Message-ID: <20210429140408.23194-5-nava.manne@xilinx.com>

Add support for Xilinx Versal FPGA manager.

PDI source type can be DDR, OCM, QSPI flash etc..
But driver allocates memory always from DDR, Since driver supports only
DDR source type.

Signed-off-by: Appana Durga Kedareswara rao <appana.durga.rao at xilinx.com>
Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
---
Changes for v2:
                -Updated the Fpga Mgr registrations call's
                 to 5.11
                -Fixed some minor coding issues as suggested by
                 Moritz.
Changes for v3:
                -Rewritten the Versal fpga Kconfig contents.
Changes for v4:
                -Rebased the changes on linux-next.
                 No functional changes.

 drivers/fpga/Kconfig       |   9 +++
 drivers/fpga/Makefile      |   1 +
 drivers/fpga/versal-fpga.c | 117 +++++++++++++++++++++++++++++++++++++
 3 files changed, 127 insertions(+)
 create mode 100644 drivers/fpga/versal-fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 33e15058d0dc..92c20b92357a 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -234,4 +234,13 @@ config FPGA_MGR_ZYNQMP_FPGA
 	  to configure the programmable logic(PL) through PS
 	  on ZynqMP SoC.
 
+config FPGA_MGR_VERSAL_FPGA
+	tristate "Xilinx Versal FPGA"
+	depends on ARCH_ZYNQMP || COMPILE_TEST
+	help
+	  Select this option to enable FPGA manager driver support for
+	  Xilinx Versal SoC. This driver uses the firmware interface to
+	  configure the programmable logic(PL).
+
+	  To compile this as a module, choose M here.
 endif # FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 18dc9885883a..0bff783d1b61 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_FPGA_MGR_TS73XX)		+= ts73xx-fpga.o
 obj-$(CONFIG_FPGA_MGR_XILINX_SPI)	+= xilinx-spi.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)	+= zynq-fpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA)	+= zynqmp-fpga.o
+obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA)      += versal-fpga.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE)         += altera-pr-ip-core.o
 obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT)    += altera-pr-ip-core-plat.o
 
diff --git a/drivers/fpga/versal-fpga.c b/drivers/fpga/versal-fpga.c
new file mode 100644
index 000000000000..5744e44f981d
--- /dev/null
+++ b/drivers/fpga/versal-fpga.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2021 Xilinx, Inc.
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/string.h>
+#include <linux/firmware/xlnx-zynqmp.h>
+
+/**
+ * struct versal_fpga_priv - Private data structure
+ * @dev:	Device data structure
+ */
+struct versal_fpga_priv {
+	struct device *dev;
+};
+
+static int versal_fpga_ops_write_init(struct fpga_manager *mgr,
+				      struct fpga_image_info *info,
+				      const char *buf, size_t size)
+{
+	return 0;
+}
+
+static int versal_fpga_ops_write(struct fpga_manager *mgr,
+				 const char *buf, size_t size)
+{
+	struct versal_fpga_priv *priv;
+	dma_addr_t dma_addr = 0;
+	char *kbuf;
+	int ret;
+
+	priv = mgr->priv;
+
+	kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL);
+	if (!kbuf)
+		return -ENOMEM;
+
+	memcpy(kbuf, buf, size);
+
+	wmb(); /* ensure all writes are done before initiate FW call */
+
+	ret = zynqmp_pm_load_pdi(PDI_SRC_DDR, dma_addr);
+
+	dma_free_coherent(priv->dev, size, kbuf, dma_addr);
+
+	return ret;
+}
+
+static int versal_fpga_ops_write_complete(struct fpga_manager *mgr,
+					  struct fpga_image_info *info)
+{
+	return 0;
+}
+
+static enum fpga_mgr_states versal_fpga_ops_state(struct fpga_manager *mgr)
+{
+	return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static const struct fpga_manager_ops versal_fpga_ops = {
+	.state = versal_fpga_ops_state,
+	.write_init = versal_fpga_ops_write_init,
+	.write = versal_fpga_ops_write,
+	.write_complete = versal_fpga_ops_write_complete,
+};
+
+static int versal_fpga_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct versal_fpga_priv *priv;
+	struct fpga_manager *mgr;
+	int ret;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->dev = dev;
+	ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+	if (ret < 0) {
+		dev_err(dev, "no usable DMA configuration\n");
+		return ret;
+	}
+
+	mgr = devm_fpga_mgr_create(dev, "Xilinx Versal FPGA Manager",
+				   &versal_fpga_ops, priv);
+	if (!mgr)
+		return -ENOMEM;
+
+	return devm_fpga_mgr_register(dev, mgr);
+}
+
+static const struct of_device_id versal_fpga_of_match[] = {
+	{ .compatible = "xlnx,versal-fpga", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, versal_fpga_of_match);
+
+static struct platform_driver versal_fpga_driver = {
+	.probe = versal_fpga_probe,
+	.driver = {
+		.name = "versal_fpga_manager",
+		.of_match_table = of_match_ptr(versal_fpga_of_match),
+	},
+};
+module_platform_driver(versal_fpga_driver);
+
+MODULE_AUTHOR("Nava kishore Manne <nava.manne at xilinx.com>");
+MODULE_AUTHOR("Appana Durga Kedareswara rao <appanad.durga.rao at xilinx.com>");
+MODULE_DESCRIPTION("Xilinx Versal FPGA Manager");
+MODULE_LICENSE("GPL");
-- 
2.17.1



From linus.walleij at linaro.org  Thu Apr 29 15:21:59 2021
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 29 Apr 2021 16:21:59 +0200
Subject: [PATCH v6 0/3] Add ZynqMP pinctrl driver
In-Reply-To: <CAHp75VfpvPdAAW2JpvdiDtzS3LUF_=Ej7c2LEML_+pOwi6CtWg@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CACRpkdaDP+JnCP+go9hZAObnNgmJyJRDFypX2CZGp-UJBh5wNA@mail.gmail.com>
 <CAHp75VfpvPdAAW2JpvdiDtzS3LUF_=Ej7c2LEML_+pOwi6CtWg@mail.gmail.com>
Message-ID: <CACRpkdaxTxCz=LJuGL_wCNTZESK0opixBzLass0w0n8A6P7mfA@mail.gmail.com>

On Fri, Apr 23, 2021 at 5:55 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Thu, Apr 22, 2021 at 12:14 PM Linus Walleij <linus.walleij at linaro.org> wrote:
> > On Thu, Apr 22, 2021 at 10:30 AM Sai Krishna Potthuri
> > <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> >
> > > changes in v6:
> > > - Rebased the patche series on 'devel' branch in pinctrl tree and no
> > > functional changes.
> >
> > Remaining patches applied! Thanks for working so hard on this!
>
> Hmm... I have had a bunch of comments. Okay, they may be addressed by
> follow up(s).

Sai: can you please address Andy's comments with replies and/or
follow-up patches?

Yours,
Linus Walleij


From l.stach at pengutronix.de  Thu Apr 29 15:25:56 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Thu, 29 Apr 2021 16:25:56 +0200
Subject: [PATCH 13/16] soc: imx: gpcv2: correct pm_runtime_get_sync usage
In-Reply-To: <20210429073050.21039-14-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-14-peng.fan@oss.nxp.com>
Message-ID: <08d8573e7395b341cdec55ee4f92d8cd3da7d0d3.camel@pengutronix.de>

Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan <peng.fan at nxp.com>
> 
> When the return value is negative, there is error, otherwise it is
> expected.

Good catch! As the runtime pm handling is added in this series, this
should be squashed into patch 06/16 to not add broken code and then fix
it in the same series. Change looks good to me.

> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
> ?drivers/soc/imx/gpcv2.c | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 42b9be05e1f2..d2ce47a5ebad 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -197,7 +197,7 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
> ?	int ret;
> ?
> 
> 
> 
> ?	ret = pm_runtime_get_sync(domain->dev);
> -	if (ret) {
> +	if (ret < 0) {
> ?		pm_runtime_put_noidle(domain->dev);
> ?		return ret;
> ?	}




From l.stach at pengutronix.de  Thu Apr 29 15:28:43 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Thu, 29 Apr 2021 16:28:43 +0200
Subject: [PATCH 14/16] soc: imx: gpcv2: move reset assert after
 requesting domain power up
In-Reply-To: <20210429073050.21039-15-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-15-peng.fan@oss.nxp.com>
Message-ID: <43f3fd817b5d0448eeb940b4f3386d3c13680da0.camel@pengutronix.de>

Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan <peng.fan at nxp.com>
> 
> The i.MX8MM VPU power up sequence is a bit special, it must follow:
> 1. request power up
> 2. reset assert
> 3. reset deassert
> 
> This change in this patch will not affect other domains, because
> the power domain default is in asserted state, unless bootloader
> deassert the reset.
> 
> [Note: We expect bootloader leave the domain in asserted state,
> but this may not always be true, so we might need another solution
> to address the VPU domain requirements]

This is only about the VPU and GPU domain, where we need to handle the
SRC reset from the GPC driver right? In that case I think it's a sane
assumption that the bootloader does not touch those resets.

> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
> ?drivers/soc/imx/gpcv2.c | 4 ++--
> ?1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index d2ce47a5ebad..072f519462a5 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -217,8 +217,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
> ?		goto out_regulator_disable;
> ?	}
> ?
> 
> 
> 
> 
> 
> 
> 
> -	reset_control_assert(domain->reset);
> -
> ?	if (domain->bits.pxx) {
> ?		/* request the domain to power up */
> ?		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
> @@ -241,6 +239,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
> ?				   GPC_PGC_CTRL_PCR, 0);
> ?	}
> ?
> 
> 
> 
> 
> 
> 
> 
> +	reset_control_assert(domain->reset);
> +
> ?	/* delay for reset to propagate */
> ?	udelay(5);

As this is a pretty arbitrary delay added by me, can you please check
with the HW team or whoever knows, if this is sufficiently long for
both GPU and VPU domains?

Regards,
Lucas



From l.stach at pengutronix.de  Thu Apr 29 15:30:52 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Thu, 29 Apr 2021 16:30:52 +0200
Subject: [PATCH 15/16] soc: imx: gpcv2: support reset defer probe
In-Reply-To: <20210429073050.21039-16-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-16-peng.fan@oss.nxp.com>
Message-ID: <34b4d1f0a278de7d730f88fd6480acfe5dfae276.camel@pengutronix.de>

Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan <peng.fan at nxp.com>
> 
> When gpcv2 probe, the reset controller might not be ready, so we need
> defer probe

I agree with Ahmad. dev_err_probe properly propagates the PROBE_DEFER
return, so this patch should be dropped.

Regards,
Lucas

> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
> ?drivers/soc/imx/gpcv2.c | 5 ++++-
> ?1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 072f519462a5..49dd137f6b94 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -784,9 +784,12 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
> ?				     "Failed to get domain's clocks\n");
> ?
> 
> 
> 
> ?	domain->reset = devm_reset_control_array_get_optional_exclusive(domain->dev);
> -	if (IS_ERR(domain->reset))
> +	if (IS_ERR(domain->reset)) {
> +		if (PTR_ERR(domain->reset) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> ?		return dev_err_probe(domain->dev, PTR_ERR(domain->reset),
> ?				     "Failed to get domain's resets\n");
> +	}
> ?
> 
> 
> 
> ?	pm_runtime_enable(domain->dev);
> ?
> 
> 
> 




From andy.shevchenko at gmail.com  Thu Apr 29 15:30:44 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Thu, 29 Apr 2021 17:30:44 +0300
Subject: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
In-Reply-To: <BL0PR02MB537807ED9F079ABF6F34B086AF5F9@BL0PR02MB5378.namprd02.prod.outlook.com>
References: <20210408145601.68651-1-andriy.shevchenko@linux.intel.com>
 <CAMpxmJU+K6C_xbQPT=9QKtLLTnajJQbgJH0A2QqbGjCV+b9Z_g@mail.gmail.com>
 <YIP9ltcdf7mNtYRd@smile.fi.intel.com>
 <BL0PR02MB537807ED9F079ABF6F34B086AF5F9@BL0PR02MB5378.namprd02.prod.outlook.com>
Message-ID: <CAHp75VfxzP60fC4v4KeHWROD9uxxtLTKdh9mB+BfYF5VpuM6dg@mail.gmail.com>

On Thu, Apr 29, 2021 at 5:00 PM Srinivas Neeli <sneeli at xilinx.com> wrote:
>
> Hi Bartosz,
>
> > -----Original Message-----
> > From: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> > Sent: Saturday, April 24, 2021 4:45 PM
> > To: Bartosz Golaszewski <bgolaszewski at baylibre.com>
> > Cc: linux-gpio <linux-gpio at vger.kernel.org>; arm-soc <linux-arm-
> > kernel at lists.infradead.org>; LKML <linux-kernel at vger.kernel.org>;
> > Shubhrajyoti Datta <shubhraj at xilinx.com>; Srinivas Neeli
> > <sneeli at xilinx.com>; Michal Simek <michals at xilinx.com>; Linus Walleij
> > <linus.walleij at linaro.org>; Yury Norov <yury.norov at gmail.com>; Rasmus
> > Villemoes <linux at rasmusvillemoes.dk>; Syed Nayyar Waris
> > <syednwaris at gmail.com>; William Breathitt Gray <vilhelm.gray at gmail.com>
> > Subject: Re: [RFT, PATCH v1 0/5] gpio: xilinx: convert to use bitmap API
> >
> > On Fri, Apr 23, 2021 at 10:41:26PM +0200, Bartosz Golaszewski wrote:
> > > On Thu, Apr 8, 2021 at 4:55 PM Andy Shevchenko
> > > <andriy.shevchenko at linux.intel.com> wrote:
> > > >
> > > > The change in the series has been inspired by [1], which, I think,
> > > > can be improved. Here I present the view how it can be done.
> > > >
> > > > The series marked as RFT since I have no hardware and I perform
> > > > compile test only.
> > > >
> > > > The patches 1 and 2 can be (independently) applied for v5.13, but
> > > > I'm not in hurry with the series, due to above (lack of real
> > > > testing). So I'm flexible in a way how it can be proceed.
> >
> > > >   bitmap: Make bitmap_remap() and bitmap_bitremap() available to
> > users
> > > >   gpio: xilinx: Correct kernel doc for xgpio_probe()
> >
> > Bart, thanks for the warm words, just pointing out that patches 1 and 2 has
> > been reviewed and may be applied for v5.13 cycle. Up to you.
> >
> > > I usually trust Andy with his work but is there any chance we can get
> > > a Tested-by before the merge window?
>
> Patches tested. Functionality working fine.
>
> Tested-by: Neeli Srinivas <sneeli at xilinx.com>

Thank you very much! I'll send a v2 with your tags after v5.13-rc1 is out.

-- 
With Best Regards,
Andy Shevchenko


From lakshmis at xilinx.com  Thu Apr 29 15:32:29 2021
From: lakshmis at xilinx.com (Sai Krishna Potthuri)
Date: Thu, 29 Apr 2021 14:32:29 +0000
Subject: [PATCH v6 0/3] Add ZynqMP pinctrl driver
In-Reply-To: <CACRpkdaxTxCz=LJuGL_wCNTZESK0opixBzLass0w0n8A6P7mfA@mail.gmail.com>
References: <1619080202-31924-1-git-send-email-lakshmi.sai.krishna.potthuri@xilinx.com>
 <CACRpkdaDP+JnCP+go9hZAObnNgmJyJRDFypX2CZGp-UJBh5wNA@mail.gmail.com>
 <CAHp75VfpvPdAAW2JpvdiDtzS3LUF_=Ej7c2LEML_+pOwi6CtWg@mail.gmail.com>
 <CACRpkdaxTxCz=LJuGL_wCNTZESK0opixBzLass0w0n8A6P7mfA@mail.gmail.com>
Message-ID: <DM5PR02MB387737FE520F81217EBF4133BD5F9@DM5PR02MB3877.namprd02.prod.outlook.com>

Hi Linus,

> -----Original Message-----
> From: Linus Walleij <linus.walleij at linaro.org>
> Sent: Thursday, April 29, 2021 7:52 PM
> To: Andy Shevchenko <andy.shevchenko at gmail.com>
> Cc: Sai Krishna Potthuri <lakshmis at xilinx.com>; Rob Herring
> <robh+dt at kernel.org>; Michal Simek <michals at xilinx.com>; Greg Kroah-
> Hartman <gregkh at linuxfoundation.org>; Linux ARM <linux-arm-
> kernel at lists.infradead.org>; linux-kernel <linux-kernel at vger.kernel.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree at vger.kernel.org>; open list:GPIO SUBSYSTEM <linux-
> gpio at vger.kernel.org>; git <git at xilinx.com>; saikrishna12468 at gmail.com
> Subject: Re: [PATCH v6 0/3] Add ZynqMP pinctrl driver
> 
> On Fri, Apr 23, 2021 at 5:55 PM Andy Shevchenko
> <andy.shevchenko at gmail.com> wrote:
> > On Thu, Apr 22, 2021 at 12:14 PM Linus Walleij <linus.walleij at linaro.org>
> wrote:
> > > On Thu, Apr 22, 2021 at 10:30 AM Sai Krishna Potthuri
> > > <lakshmi.sai.krishna.potthuri at xilinx.com> wrote:
> > >
> > > > changes in v6:
> > > > - Rebased the patche series on 'devel' branch in pinctrl tree and
> > > > no functional changes.
> > >
> > > Remaining patches applied! Thanks for working so hard on this!
> >
> > Hmm... I have had a bunch of comments. Okay, they may be addressed by
> > follow up(s).
> 
> Sai: can you please address Andy's comments with replies and/or follow-up
> patches?
Sure, discussing with Andy on couple of comments.
I will send the follow-up patch to address his comments.

Regards
Sai Krishna
> 
> Yours,
> Linus Walleij

From l.stach at pengutronix.de  Thu Apr 29 15:34:31 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Thu, 29 Apr 2021 16:34:31 +0200
Subject: [PATCH 16/16] soc: imx: gpcv2: remove waiting handshake in
 power up
In-Reply-To: <20210429073050.21039-17-peng.fan@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-17-peng.fan@oss.nxp.com>
Message-ID: <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>

Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> From: Peng Fan <peng.fan at nxp.com>
> 
> i.MX8MM has blk ctl module, the handshake can only finish after setting
> blk ctl. The blk ctl driver will set the bus clk bit and the handshake
> will finish there. we just add a delay and suppose the handshake will
> finish after that.

Instead of this patch, just drop patch 05/16 from this series. I think
we should leave a comment in the code on why we aren't waiting for the
handshake ack, as this is non-obvious from looking at the driver code.?

Basically add a polished version of the commit log from this patch into
the driver code.

Regards,
Lucas

> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
> ?drivers/soc/imx/gpcv2.c | 8 --------
> ?1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 49dd137f6b94..04564017bfe9 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -251,14 +251,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
> ?		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
> ?				   domain->bits.hskreq, domain->bits.hskreq);
> ?
> 
> 
> 
> -		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
> -					       reg_val,
> -					       (reg_val & domain->bits.hskack),
> -					       0, USEC_PER_MSEC);
> -		if (ret) {
> -			dev_err(domain->dev, "failed to power up ADB400\n");
> -			goto out_clk_disable;
> -		}
> ?	}
> ?
> 
> 
> 
> ?	/* Disable reset clocks for all devices in the domain */




From lkp at intel.com  Thu Apr 29 15:36:09 2021
From: lkp at intel.com (kernel test robot)
Date: Thu, 29 Apr 2021 22:36:09 +0800
Subject: [xlnx:master 197/407]
 drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:370:4: error: 'struct
 axienet_local' has no member named 'qbv_regs'
Message-ID: <202104292201.EcJvuisp-lkp@intel.com>

Hi Pranavi,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx master
head:   959c29b000f2d8576c7b56b53e559db140ee3952
commit: 1a67745a47fc9601447f7d8aff40ddb1023848d5 [197/407] net: xilinx: Access qdv address and associated properties separately
config: parisc-randconfig-r023-20210429 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/Xilinx/linux-xlnx/commit/1a67745a47fc9601447f7d8aff40ddb1023848d5
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx master
        git checkout 1a67745a47fc9601447f7d8aff40ddb1023848d5
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=parisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

   In file included from include/linux/mm.h:99,
                    from include/linux/bvec.h:13,
                    from include/linux/skbuff.h:17,
                    from include/linux/if_ether.h:19,
                    from include/linux/etherdevice.h:20,
                    from drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:18:
   include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
   arch/parisc/include/asm/pgtable.h:91:9: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable]
      91 |   pte_t old_pte;     \
         |         ^~~~~~~
   arch/parisc/include/asm/pgtable.h:316:34: note: in expansion of macro 'set_pte_at'
     316 | #define pte_clear(mm, addr, xp)  set_pte_at(mm, addr, xp, __pte(0))
         |                                  ^~~~~~~~~~
   include/asm-generic/pgtable.h:201:2: note: in expansion of macro 'pte_clear'
     201 |  pte_clear(mm, address, ptep);
         |  ^~~~~~~~~
   include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
   arch/parisc/include/asm/pgtable.h:91:9: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable]
      91 |   pte_t old_pte;     \
         |         ^~~~~~~
   include/asm-generic/pgtable.h:629:2: note: in expansion of macro 'set_pte_at'
     629 |  set_pte_at(vma->vm_mm, addr, ptep, pte);
         |  ^~~~~~~~~~
   drivers/net/ethernet/xilinx/xilinx_tsn_ep.c: In function 'tsn_ep_probe':
>> drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:370:4: error: 'struct axienet_local' has no member named 'qbv_regs'
     370 |  lp->qbv_regs = lp->regs;
         |    ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:373:4: error: 'struct axienet_local' has no member named 'qbv_irq'
     373 |  lp->qbv_irq = platform_get_irq_byname(pdev, irq_name);
         |    ^~
>> drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:374:2: error: implicit declaration of function 'axienet_qbv_init'; did you mean 'axienet_dma_q_init'? [-Werror=implicit-function-declaration]
     374 |  axienet_qbv_init(ndev);
         |  ^~~~~~~~~~~~~~~~
         |  axienet_dma_q_init
   drivers/net/ethernet/xilinx/xilinx_tsn_ep.c: In function 'tsn_ep_remove':
>> drivers/net/ethernet/xilinx/xilinx_tsn_ep.c:392:2: error: implicit declaration of function 'axienet_qbv_remove'; did you mean 'axienet_bd_free'? [-Werror=implicit-function-declaration]
     392 |  axienet_qbv_remove(ndev);
         |  ^~~~~~~~~~~~~~~~~~
         |  axienet_bd_free
   cc1: some warnings being treated as errors

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for PTP_1588_CLOCK
   Depends on NET && POSIX_TIMERS
   Selected by
   - XILINX_AXI_EMAC_HWTSTAMP && NETDEVICES && ETHERNET && NET_VENDOR_XILINX && XILINX_AXI_EMAC


vim +370 drivers/net/ethernet/xilinx/xilinx_tsn_ep.c

   281	
   282	/**
   283	 * tsn_ep_probe - TSN ep pointer probe function.
   284	 * @pdev:	Pointer to platform device structure.
   285	 *
   286	 * Return: 0, on success
   287	 *	    Non-zero error value on failure.
   288	 *
   289	 * This is the probe routine for TSN endpoint driver.
   290	 */
   291	static int tsn_ep_probe(struct platform_device *pdev)
   292	{
   293		int ret = 0;
   294		struct axienet_local *lp;
   295		struct net_device *ndev;
   296		struct resource *ethres;
   297		const void *mac_addr;
   298		u16 num_tc = 0;
   299		char irq_name[32];
   300	
   301		ndev = alloc_netdev(sizeof(*lp), "ep", NET_NAME_UNKNOWN, ether_setup);
   302		if (!ndev)
   303			return -ENOMEM;
   304	
   305		platform_set_drvdata(pdev, ndev);
   306	
   307		SET_NETDEV_DEV(ndev, &pdev->dev);
   308		ndev->flags &= ~IFF_MULTICAST;  /* clear multicast */
   309		ndev->features = NETIF_F_SG;
   310		ndev->netdev_ops = &ep_netdev_ops;
   311	
   312		/* MTU range: 64 - 9000 */
   313		ndev->min_mtu = 64;
   314		ndev->max_mtu = XAE_JUMBO_MTU;
   315	
   316		lp = netdev_priv(ndev);
   317		lp->ndev = ndev;
   318		lp->dev = &pdev->dev;
   319		lp->options = XAE_OPTION_DEFAULTS;
   320		lp->tx_bd_num = TX_BD_NUM_DEFAULT;
   321		lp->rx_bd_num = RX_BD_NUM_DEFAULT;
   322	
   323		/* TODO
   324		 * there are two temacs or two slaves to ep
   325		 * get this infor from design?
   326		 */
   327		lp->slaves[0] = NULL;
   328		lp->slaves[1] = NULL;
   329	
   330		lp->axienet_config = &tsn_endpoint_cfg;
   331	
   332		lp->max_frm_size = XAE_MAX_VLAN_FRAME_SIZE;
   333	
   334		/* Setup checksum offload, but default to off if not specified */
   335		lp->features = 0;
   336	
   337		lp->eth_hasnobuf = of_property_read_bool(pdev->dev.of_node,
   338							 "xlnx,eth-hasnobuf");
   339	
   340		/* Retrieve the MAC address */
   341		mac_addr = of_get_mac_address(pdev->dev.of_node);
   342		if (!mac_addr) {
   343			dev_err(&pdev->dev, "could not find MAC address\n");
   344			goto free_netdev;
   345		}
   346		if (mac_addr)
   347			ether_addr_copy(ndev->dev_addr, mac_addr);
   348		if (!is_valid_ether_addr(ndev->dev_addr))
   349			eth_hw_addr_random(ndev);
   350	
   351		ret = tsn_mcdma_probe(pdev, lp, ndev);
   352		if (ret) {
   353			dev_err(&pdev->dev, "Getting MCDMA resource failed\n");
   354			goto free_netdev;
   355		}
   356	
   357		ret = of_property_read_u16(
   358			pdev->dev.of_node, "xlnx,num-tc", &num_tc);
   359		if (ret || (num_tc != 2 && num_tc != 3))
   360			lp->num_tc = XAE_MAX_TSN_TC;
   361		else
   362			lp->num_tc = num_tc;
   363		/* Map device registers */
   364		ethres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   365		lp->regs = devm_ioremap_resource(&pdev->dev, ethres);
   366		if (IS_ERR(lp->regs)) {
   367			ret = PTR_ERR(lp->regs);
   368			goto free_netdev;
   369		}
 > 370		lp->qbv_regs = lp->regs;
   371	
   372		sprintf(irq_name, "tsn_ep_scheduler_irq");
 > 373		lp->qbv_irq = platform_get_irq_byname(pdev, irq_name);
 > 374		axienet_qbv_init(ndev);
   375	
   376		ret = register_netdev(lp->ndev);
   377		if (ret)
   378			dev_err(lp->dev, "register_netdev() error (%i)\n", ret);
   379	
   380		return ret;
   381	
   382	free_netdev:
   383		free_netdev(ndev);
   384	
   385		return ret;
   386	}
   387	
   388	static int tsn_ep_remove(struct platform_device *pdev)
   389	{
   390		struct net_device *ndev = platform_get_drvdata(pdev);
   391	
 > 392		axienet_qbv_remove(ndev);
   393		unregister_netdev(ndev);
   394	
   395		free_netdev(ndev);
   396	
   397		return 0;
   398	}
   399	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 21534 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210429/a73115c8/attachment-0001.gz>

From frieder.schrempf at kontron.de  Thu Apr 29 15:38:08 2021
From: frieder.schrempf at kontron.de (Frieder Schrempf)
Date: Thu, 29 Apr 2021 16:38:08 +0200
Subject: [PATCH v2 08/13] dt-bindings: imx: gpcv2: add support for
 optional resets
In-Reply-To: <f9400040-0884-81a4-ae76-5cd1db8c195d@kontron.de>
References: <20201105174434.1817539-1-l.stach@pengutronix.de>
 <20201105174434.1817539-9-l.stach@pengutronix.de>
 <20201109201557.GA1690230@bogus>
 <5b6c97dc74ccb38107a50972427d091cdb114209.camel@pengutronix.de>
 <f652344c2c1664d541300dc71cc9ccd8aeaee292.camel@pengutronix.de>
 <928adc851c756f27562b0ae1847f08e2c857504d.camel@pengutronix.de>
 <f9400040-0884-81a4-ae76-5cd1db8c195d@kontron.de>
Message-ID: <ba235ca5-299e-7900-359b-d08b56b73176@kontron.de>

On 26.04.21 11:24, Frieder Schrempf wrote:
> Hi Rob,
> 
> On 10.02.21 15:35, Lucas Stach wrote:
>> Am Montag, dem 30.11.2020 um 10:57 +0100 schrieb Lucas Stach:
>>> Hi Rob,
>>>
>>> Am Dienstag, den 17.11.2020, 15:11 +0100 schrieb Lucas Stach:
>>> Am Montag, den 09.11.2020, 14:15 -0600 schrieb Rob Herring:
>>>> On Thu, Nov 05, 2020 at 06:44:29PM +0100, Lucas Stach wrote:
>>>>> For some domains the resets of the devices in the domain are not
>>>>> automatically triggered. Add an optional resets property to allow
>>>>> the GPC driver to trigger those resets explicitly.
>>>>>
>>>>> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
>>>>> ---
>>>>> ??Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 7
>>>>> +++++++
>>>>> ??1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-
>>>>> gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-
>>>>> gpcv2.yaml
>>>>> index a96e6dbf1858..4330c73a2c30 100644
>>>>> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>>> @@ -66,6 +66,13 @@ properties:
>>>>> ??????????? power-supply: true
>>>>> +????????? resets:
>>>>> +??????????? description: |
>>>>> +????????????? A number of phandles to resets that need to be
>>>>> asserted during
>>>>> +????????????? power-up sequencing of the domain.
>>>>> +??????????? minItems: 1
>>>>> +??????????? maxItems: 4
>>>>
>>>> You need to define what each reset is.
>>>
>>> I can't. The resets belong to devices located inside the power domain,
>>> which need to be held in reset across the power-up sequence. So I
>>> have no means to specify what each reset is in a generic power-domain
>>> binding. Same situation as with the clocks in this binding actually.
>>>
>>> Do you have any guidance on what do here? Is this binding okay with
>>> this explanation, or do we need to do something different here?
>>
>> Any pointers on how we can make some progress with this? It's blocking
>> quite a bit of functionality of the i.MX8MM SoC being enabled upstream.
> 
> One more ping from my side. Can you give us some feedback about whether 
> we can proceed with the bindings proposed by Lucas or not?
> 
> This has been on hold now for over 5 months and it looks like one of the 
> reasons is that we don't know if the bindings will be accepted.

It looks like Rob is fine with the bindings if there is an explanation 
in the bindings for why the resets are not defined.

Quote from Rob on IRC: "Just explain why the resets are unknown and 
variable in the binding".




From mkorpershoek at baylibre.com  Thu Apr 29 15:38:11 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Thu, 29 Apr 2021 16:38:11 +0200
Subject: [PATCH] mfd: mt6397: rename mtk-pmic-keys cells to avoid OOPS
Message-ID: <20210429143811.2030717-1-mkorpershoek@baylibre.com>

When booting with CONFIG_KEYBOARD_MTK_PMIC=y, we have the following oops:

[    0.384359] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
[    0.385471] Mem abort info:
[    0.385826]   ESR = 0x96000004
[    0.386214]   EC = 0x25: DABT (current EL), IL = 32 bits
[    0.386886]   SET = 0, FnV = 0
[    0.387282]   EA = 0, S1PTW = 0
[    0.387681] Data abort info:
[    0.388047]   ISV = 0, ISS = 0x00000004
[    0.388533]   CM = 0, WnR = 0
[    0.388910] [00000000000000c0] user address but active_mm is swapper
[    0.389712] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[    0.390419] Modules linked in:
[    0.390812] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.12.0-mtk-04316-g7f74036c9b47 #58
[    0.391835] Hardware name: Pumpkin MT8183 (DT)
[    0.392399] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
[    0.393160] pc : mtk_pmic_keys_probe+0x8c/0x57c
[    0.393744] lr : mtk_pmic_keys_probe+0x70/0x57c
[    0.394318] sp : ffff80001008bb10
[    0.394738] x29: ffff80001008bb10 x28: 0000000000000000
[    0.395414] x27: ffff8000117f04b0 x26: ffff80001121aa88
[    0.396089] x25: ffff0000031ea400 x24: ffff0000031ea410
[    0.396763] x23: 0000000000000000 x22: ffff00000342ad80
[    0.397438] x21: ffff000003589780 x20: 0000000000000000
[    0.398112] x19: ffff80001129d0d0 x18: 0000000000003ca8
[    0.398786] x17: ffff800010bad620 x16: ffff800010bacc44
[    0.399460] x15: 0000000000000040 x14: ffffffffffffffff
[    0.400134] x13: ffff800011df2728 x12: 0000000000000030
[    0.400808] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[    0.401482] x9 : 0000000000000000 x8 : ffff000003589800
[    0.402155] x7 : 0000000000000000 x6 : 000000000000003f
[    0.402829] x5 : 0000000000000040 x4 : ffff0000031ea610
[    0.403503] x3 : ffff0000031ea6b8 x2 : 0000000000000000
[    0.404176] x1 : ffff000002d8d800 x0 : ffff0000031ea410
[    0.404850] Call trace:
[    0.405162]  mtk_pmic_keys_probe+0x8c/0x57c
[    0.405694]  platform_probe+0x68/0xe0
[    0.406162]  really_probe+0x1c0/0x480
[    0.406631]  driver_probe_device.part.0+0xd8/0x118
[    0.407239]  device_driver_attach+0xcc/0xd4
[    0.407773]  __driver_attach+0x60/0x12c
[    0.408261]  bus_for_each_dev+0x70/0xc4
[    0.408749]  driver_attach+0x24/0x30
[    0.409204]  bus_add_driver+0x118/0x200
[    0.409692]  driver_register+0x78/0x130
[    0.410180]  __platform_driver_register+0x28/0x34
[    0.410779]  pmic_keys_pdrv_init+0x1c/0x28
[    0.411301]  do_one_initcall+0x54/0x1c0
[    0.411791]  kernel_init_freeable+0x1d4/0x23c
[    0.412347]  kernel_init+0x14/0x118
[    0.412792]  ret_from_fork+0x10/0x34
[    0.413251] Code: aa1803e0 f90006b8 f94006c1 f9000aa1 (f9406281)
[    0.414032] ---[ end trace ad605d8d1790625c ]---
[    0.414630] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    0.415600] SMP: stopping secondary CPUs
[    0.416103] Kernel Offset: 0x80000 from 0xffff800010000000
[    0.416796] PHYS_OFFSET: 0x40000000
[    0.417238] CPU features: 0x00240002,2188200c
[    0.417791] Memory Limit: none
[    0.418181] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

This happens when we don't have a matching device-tree entry
(such as mediatek,mt6323-keys) for the driver.
In that case, we dereference of_id->data with of_id == NULL

The mfd core warns us about this:
   [    0.352175] mtk-pmic-keys: Failed to locate of_node [id: -1]

mtk_pmic_keys gets probed() anyways because its mfd_cell->name:
    }, {
            .name = "mtk-pmic-keys",
            .num_resources = ARRAY_SIZE(mt6323_keys_resources),
            .resources = mt6323_keys_resources,
            .of_compatible = "mediatek,mt6323-keys"
    }, {

.name is used by mfd_add_device() and becomes the name of the platform
device:

    pdev = platform_device_alloc(cell->name, platform_id);

Later, in initcall, we do:

[    0.296114] calling  pmic_keys_pdrv_init+0x0/0x28 @ 1
[    0.296142] bus: 'platform': add driver mtk-pmic-keys

Then, to check if we should call mtk_pmic_keys_probe(), we call

      platform_match(drv, dev)

which will return true since drv->name and pdev->name match.

Since both the platform device is named mtk-pmic-keys and the driver is
called mtk-pmic-keys, we call probe(), which triggers the oops.

Fix it by renaming the mtk-pmic-key subdevices to right side of
their compatible.

This way, probe() will only be called when we have a valid dts entry for
mtk-pmic-keys.

Note: this is also more consistent naming with the other subdevices
such as mt6397-rtc and mt6397-codec.

Fixes: 55d1d1547ab5 ("mfd: mt6397: Add PMIC keys support to MT6397 driver")
Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
---

This is a replacement for:
https://patchwork.kernel.org/project/linux-mediatek/patch/20210428164219.1115537-2-mkorpershoek at baylibre.com/

 drivers/mfd/mt6397-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index 7518d74c3b4c..a83fbc486d26 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -72,7 +72,7 @@ static const struct mfd_cell mt6323_devs[] = {
 		.name = "mt6323-led",
 		.of_compatible = "mediatek,mt6323-led"
 	}, {
-		.name = "mtk-pmic-keys",
+		.name = "mt6323-keys",
 		.num_resources = ARRAY_SIZE(mt6323_keys_resources),
 		.resources = mt6323_keys_resources,
 		.of_compatible = "mediatek,mt6323-keys"
@@ -118,7 +118,7 @@ static const struct mfd_cell mt6397_devs[] = {
 		.name = "mt6397-pinctrl",
 		.of_compatible = "mediatek,mt6397-pinctrl",
 	}, {
-		.name = "mtk-pmic-keys",
+		.name = "mt6397-keys",
 		.num_resources = ARRAY_SIZE(mt6397_keys_resources),
 		.resources = mt6397_keys_resources,
 		.of_compatible = "mediatek,mt6397-keys"

base-commit: 4a0225c3d208cfa6e4550f2210ffd9114a952a81
-- 
2.27.0



From mkorpershoek at baylibre.com  Thu Apr 29 15:48:55 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Thu, 29 Apr 2021 16:48:55 +0200
Subject: [PATCH 1/7] Input: mtk-pmic-keys - check for NULL on
 of_match_device()
In-Reply-To: <875z05y4a2.fsf@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
 <20210428164219.1115537-2-mkorpershoek@baylibre.com>
 <YIm9Bb3eBjYwY53R@google.com> <875z05y4a2.fsf@baylibre.com>
Message-ID: <87wnslw3hk.fsf@baylibre.com>

Hi Dmitry,

Mattijs Korpershoek <mkorpershoek at baylibre.com> writes:

> Hi Dmitry,
>
> Dmitry Torokhov <dmitry.torokhov at gmail.com> writes:
>
>> Hi Mattijs,
>>
>> On Wed, Apr 28, 2021 at 06:42:13PM +0200, Mattijs Korpershoek wrote:
>>> mtk-pmic-keys being a child device of mt6397, it will always get probed
>>> when mt6397_probe() is called.
>>> 
>>> This also happens when we have no device tree node matching
>>> mediatek,mt6397-keys.
>>
>> It sounds for me that creating a platform device instance in case where
>> we know need OF node, but do not have one, is wasteful. Can
>> mt6397-core.c and/or MFD core be adjusted to not do that.
>
> You are right. Maybe I can fix MFD core instead. I will look into it.
>
> Thanks for your review.
>>
>>> 
>>> In that case, the mfd core warns us:
>>> 
>>>   [    0.352175] mtk-pmic-keys: Failed to locate of_node [id: -1]
>>> 
>>> Check return value from call to of_match_device()
>>> in order to prevent a NULL pointer dereference.
>>> 
>>> In case of NULL print error message and return -ENODEV
>>> 
>>> Signed-off-by: Mattijs Korpershoek <mkorpershoek at baylibre.com>
>>> ---
>>>  drivers/input/keyboard/mtk-pmic-keys.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>> 
>>> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
>>> index 62391d6c7da6..12c449eed026 100644
>>> --- a/drivers/input/keyboard/mtk-pmic-keys.c
>>> +++ b/drivers/input/keyboard/mtk-pmic-keys.c
>>> @@ -247,6 +247,9 @@ static int mtk_pmic_keys_probe(struct platform_device *pdev)
>>>  	const struct of_device_id *of_id =
>>>  		of_match_device(of_mtk_pmic_keys_match_tbl, &pdev->dev);
>>>  
>>> +	if (!of_id)
>>> +		return -ENODEV;
>>> +
>>
>> So if we make MFD/6396 core smarter we would not be needing this. I
>> guess there is still a possibility of someone stuffing "mtk-pmic-keys"
>> into "driver_override" attribute of a random platform device but I
>> wonder if we really need to take care of such scenarios...
It turns out it was possible to make 6397-core smarter.
I've submitted [1] to replace this patch.

Thanks again for your suggestion. Please let me know if I should add
your Suggested-by: in [1].

[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210429143811.2030717-1-mkorpershoek at baylibre.com/ instead
>>
>>>  	keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
>>>  	if (!keys)
>>>  		return -ENOMEM;
>>> -- 
>>> 2.27.0
>>> 
>>
>> Thanks.
>>
>> -- 
>> Dmitry


From jc at kynesim.co.uk  Thu Apr 29 15:51:00 2021
From: jc at kynesim.co.uk (John Cox)
Date: Thu, 29 Apr 2021 15:51:00 +0100
Subject: [PATCH] media: hevc: Fix dependent slice segment flags
In-Reply-To: <20210427071554.2222625-1-jernej.skrabec@siol.net>
References: <20210427071554.2222625-1-jernej.skrabec@siol.net>
Message-ID: <lrhl8gl392tcpss5rcpkqr1cahujnlqq9k@4ax.com>

>Dependent slice segment flag for PPS control is misnamed. It should have
>"enabled" at the end. It only tells if this flag is present in slice
>header or not and not the actual value.
>
>Fix this by renaming the PPS flag and introduce another flag for slice
>control which tells actual value.
>
>Signed-off-by: Jernej Skrabec <jernej.skrabec at siol.net>
>---
> Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 5 ++++-
> drivers/staging/media/sunxi/cedrus/cedrus_h265.c          | 4 ++--
> include/media/hevc-ctrls.h                                | 3 ++-
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
>diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
>index 7b90cb939e9d..5ed343ddd1ea 100644
>--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
>+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
>@@ -3059,7 +3059,7 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
>     :stub-columns: 0
>     :widths:       1 1 2
> 
>-    * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT``
>+    * - ``V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED``
>       - 0x00000001
>       -
>     * - ``V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT``
>@@ -3274,6 +3274,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field -
>     * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED``
>       - 0x00000100
>       -
>+    * - ``V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT``
>+      - 0x00000200
>+      -
> 
> .. raw:: latex
> 
>diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>index 397a4ba5df4c..6821e3d05d34 100644
>--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>@@ -479,8 +479,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx,
> 				slice_params->flags);
> 
> 	reg |= VE_DEC_H265_FLAG(VE_DEC_H265_DEC_SLICE_HDR_INFO0_FLAG_DEPENDENT_SLICE_SEGMENT,
>-				V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT,
>-				pps->flags);
>+				V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT,
>+				slice_params->flags);
> 
> 	/* FIXME: For multi-slice support. */
> 	reg |= VE_DEC_H265_DEC_SLICE_HDR_INFO0_FLAG_FIRST_SLICE_SEGMENT_IN_PIC;
>diff --git a/include/media/hevc-ctrls.h b/include/media/hevc-ctrls.h
>index b713eeed1915..dc964ff7cd29 100644
>--- a/include/media/hevc-ctrls.h
>+++ b/include/media/hevc-ctrls.h
>@@ -83,7 +83,7 @@ struct v4l2_ctrl_hevc_sps {
> 	__u64	flags;
> };
> 
>-#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT		(1ULL << 0)
>+#define V4L2_HEVC_PPS_FLAG_DEPENDENT_SLICE_SEGMENT_ENABLED	(1ULL << 0)
> #define V4L2_HEVC_PPS_FLAG_OUTPUT_FLAG_PRESENT			(1ULL << 1)
> #define V4L2_HEVC_PPS_FLAG_SIGN_DATA_HIDING_ENABLED		(1ULL << 2)
> #define V4L2_HEVC_PPS_FLAG_CABAC_INIT_PRESENT			(1ULL << 3)
>@@ -166,6 +166,7 @@ struct v4l2_hevc_pred_weight_table {
> #define V4L2_HEVC_SLICE_PARAMS_FLAG_USE_INTEGER_MV		(1ULL << 6)
> #define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_DEBLOCKING_FILTER_DISABLED (1ULL << 7)
> #define V4L2_HEVC_SLICE_PARAMS_FLAG_SLICE_LOOP_FILTER_ACROSS_SLICES_ENABLED (1ULL << 8)
>+#define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT	(1ULL << 9)
> 
> struct v4l2_ctrl_hevc_slice_params {
> 	__u32	bit_size;

Happy to see this flag finally making it

Many thanks

John Cox


From mkorpershoek at baylibre.com  Thu Apr 29 15:57:30 2021
From: mkorpershoek at baylibre.com (Mattijs Korpershoek)
Date: Thu, 29 Apr 2021 16:57:30 +0200
Subject: [PATCH 0/7] Input: mtk-pmic-keys - add support for MT6358
In-Reply-To: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
References: <20210428164219.1115537-1-mkorpershoek@baylibre.com>
Message-ID: <87tunpw339.fsf@baylibre.com>

Hi Matthias, Dmitry, Lee,

Mattijs Korpershoek <mkorpershoek at baylibre.com> writes:

Please ignore this series for now

> The MediaTek MT6358 PMIC has support for two buttons: PWR and HOME.
>
> The interrupt logic is a little different than other PMICs from the
> same family:
> * for MT6323 and MT6397, we have one interrupt source per button
> * for MT6358, we have two interrupts lines per button: the press and
> * release interrupts are distinct sources.
>
> These series:
> * Fix a NULL ptr error when we use mtk-pmic-keys without dts code
I've submitted this as a separate bugfix [1] to ease the review.

[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210429143811.2030717-1-mkorpershoek at baylibre.com/

> * Rework the mt6397 driver to prepare for this different interrupt logic
> * Add support for the MT6358 power buttons
>
> This has been functionally tested (using evtest) on
> the mt8183-pumpkin board on linux/master
>
> It has also been used for a couple of months in a downstream
> tree based on v5.4.
>
> Mattijs Korpershoek (7):
>   Input: mtk-pmic-keys - check for NULL on of_match_device()
>   mfd: mt6397: add mt6358 register definitions for power key
>   mfd: mt6397: keys: use named IRQs instead of index
>   dt-bindings: input: mtk-pmic-keys: add MT6358 binding definition
>   Input: mtk-pmic-keys - add support for MT6358
I'll send a v2 for these

>   mfd: mt6397: Add PMIC keys for MT6358
>   arm64: dts: mt6358: add mt6358-keys node
>
>  .../bindings/input/mtk-pmic-keys.txt          |  5 +-
>  arch/arm64/boot/dts/mediatek/mt6358.dtsi      | 12 ++++
>  drivers/input/keyboard/mtk-pmic-keys.c        | 59 +++++++++++++++++--
>  drivers/mfd/mt6397-core.c                     | 20 +++++--
>  include/linux/mfd/mt6358/registers.h          |  2 +
>  5 files changed, 89 insertions(+), 9 deletions(-)
>
>
> base-commit: 4a0225c3d208cfa6e4550f2210ffd9114a952a81
> -- 
> 2.27.0


From arnd at kernel.org  Thu Apr 29 15:57:26 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 29 Apr 2021 16:57:26 +0200
Subject: [PATCH] [v2] coresight: etm4x: avoid build failure with unrolled loops
Message-ID: <20210429145752.3218324-1-arnd@kernel.org>

From: Arnd Bergmann <arnd at arndb.de>

clang-12 fails to build the etm4x driver with -fsanitize=array-bounds,
where it decides to unroll certain loops in a way that result in a
C variable getting put into an inline assembly

<instantiation>:1:7: error: expected constant expression in '.inst' directive
.inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
      ^
drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
                        etm4x_relaxed_read32(csa, TRCCNTVRn(i));
                        ^
drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
                 read_etm4x_sysreg_offset((offset), false)))
                 ^
drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
                        __val = read_etm4x_sysreg_const_offset((offset));       \
                                ^
drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
        READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
        ^
drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
        read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
        ^
arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
        asm volatile(__mrs_s("%0", r) : "=r" (__val));                  \
                     ^
arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
"       mrs_s " v ", " __stringify(r) "\n"                      \
 ^

This only happened in a few loops in which the array bounds sanitizer
added a special case for an array overflow that clang determined to be
possible, but any compiler is free to unroll any of the loops in the
same way that breaks the sysreg macros.

Introduce helper functions that perform a sysreg access with a
non-constant register number and use them in each call that passes
a loop counter.

Link: https://github.com/ClangBuiltLinux/linux/issues/1310
Link: https://lore.kernel.org/lkml/20210225094324.3542511-1-arnd at kernel.org/
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 .../coresight/coresight-etm4x-core.c          | 78 +++++++++----------
 drivers/hwtracing/coresight/coresight-etm4x.h | 69 ++++++++++++++++
 2 files changed, 108 insertions(+), 39 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index db881993c211..73649d9c89d2 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -381,14 +381,14 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
 	if (drvdata->nr_pe_cmp)
 		etm4x_relaxed_write32(csa, config->vipcssctlr, TRCVIPCSSCTLR);
 	for (i = 0; i < drvdata->nrseqstate - 1; i++)
-		etm4x_relaxed_write32(csa, config->seq_ctrl[i], TRCSEQEVRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->seq_ctrl[i], TRCSEQEVRn(i));
 	etm4x_relaxed_write32(csa, config->seq_rst, TRCSEQRSTEVR);
 	etm4x_relaxed_write32(csa, config->seq_state, TRCSEQSTR);
 	etm4x_relaxed_write32(csa, config->ext_inp, TRCEXTINSELR);
 	for (i = 0; i < drvdata->nr_cntr; i++) {
-		etm4x_relaxed_write32(csa, config->cntrldvr[i], TRCCNTRLDVRn(i));
-		etm4x_relaxed_write32(csa, config->cntr_ctrl[i], TRCCNTCTLRn(i));
-		etm4x_relaxed_write32(csa, config->cntr_val[i], TRCCNTVRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->cntrldvr[i], TRCCNTRLDVRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->cntr_ctrl[i], TRCCNTCTLRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->cntr_val[i], TRCCNTVRn(i));
 	}
 
 	/*
@@ -396,29 +396,29 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
 	 * such start at 2.
 	 */
 	for (i = 2; i < drvdata->nr_resource * 2; i++)
-		etm4x_relaxed_write32(csa, config->res_ctrl[i], TRCRSCTLRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->res_ctrl[i], TRCRSCTLRn(i));
 
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
 		/* always clear status bit on restart if using single-shot */
 		if (config->ss_ctrl[i] || config->ss_pe_cmp[i])
 			config->ss_status[i] &= ~BIT(31);
-		etm4x_relaxed_write32(csa, config->ss_ctrl[i], TRCSSCCRn(i));
-		etm4x_relaxed_write32(csa, config->ss_status[i], TRCSSCSRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->ss_ctrl[i], TRCSSCCRn(i));
+		etm4x_relaxed_write32_varreg(csa, config->ss_status[i], TRCSSCSRn(i));
 		if (etm4x_sspcicrn_present(drvdata, i))
-			etm4x_relaxed_write32(csa, config->ss_pe_cmp[i], TRCSSPCICRn(i));
+			etm4x_relaxed_write32_varreg(csa, config->ss_pe_cmp[i], TRCSSPCICRn(i));
 	}
 	for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-		etm4x_relaxed_write64(csa, config->addr_val[i], TRCACVRn(i));
-		etm4x_relaxed_write64(csa, config->addr_acc[i], TRCACATRn(i));
+		etm4x_relaxed_write64_varreg(csa, config->addr_val[i], TRCACVRn(i));
+		etm4x_relaxed_write64_varreg(csa, config->addr_acc[i], TRCACATRn(i));
 	}
 	for (i = 0; i < drvdata->numcidc; i++)
-		etm4x_relaxed_write64(csa, config->ctxid_pid[i], TRCCIDCVRn(i));
+		etm4x_relaxed_write64_varreg(csa, config->ctxid_pid[i], TRCCIDCVRn(i));
 	etm4x_relaxed_write32(csa, config->ctxid_mask0, TRCCIDCCTLR0);
 	if (drvdata->numcidc > 4)
 		etm4x_relaxed_write32(csa, config->ctxid_mask1, TRCCIDCCTLR1);
 
 	for (i = 0; i < drvdata->numvmidc; i++)
-		etm4x_relaxed_write64(csa, config->vmid_val[i], TRCVMIDCVRn(i));
+		etm4x_relaxed_write64_varreg(csa, config->vmid_val[i], TRCVMIDCVRn(i));
 	etm4x_relaxed_write32(csa, config->vmid_mask0, TRCVMIDCCTLR0);
 	if (drvdata->numvmidc > 4)
 		etm4x_relaxed_write32(csa, config->vmid_mask1, TRCVMIDCCTLR1);
@@ -777,13 +777,13 @@ static void etm4_disable_hw(void *info)
 	/* read the status of the single shot comparators */
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
 		config->ss_status[i] =
-			etm4x_relaxed_read32(csa, TRCSSCSRn(i));
+			etm4x_relaxed_read32_varreg(csa, TRCSSCSRn(i));
 	}
 
 	/* read back the current counter values */
 	for (i = 0; i < drvdata->nr_cntr; i++) {
 		config->cntr_val[i] =
-			etm4x_relaxed_read32(csa, TRCCNTVRn(i));
+			etm4x_relaxed_read32_varreg(csa, TRCCNTVRn(i));
 	}
 
 	coresight_disclaim_device_unlocked(csdev);
@@ -1151,7 +1151,7 @@ static void etm4_init_arch_data(void *info)
 	drvdata->nr_ss_cmp = BMVAL(etmidr4, 20, 23);
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
 		drvdata->config.ss_status[i] =
-			etm4x_relaxed_read32(csa, TRCSSCSRn(i));
+			etm4x_relaxed_read32_varreg(csa, TRCSSCSRn(i));
 	}
 	/* NUMCIDC, bits[27:24] number of Context ID comparators for tracing */
 	drvdata->numcidc = BMVAL(etmidr4, 24, 27);
@@ -1595,31 +1595,31 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
 	state->trcvdarcctlr = etm4x_read32(csa, TRCVDARCCTLR);
 
 	for (i = 0; i < drvdata->nrseqstate - 1; i++)
-		state->trcseqevr[i] = etm4x_read32(csa, TRCSEQEVRn(i));
+		state->trcseqevr[i] = etm4x_read32_varreg(csa, TRCSEQEVRn(i));
 
 	state->trcseqrstevr = etm4x_read32(csa, TRCSEQRSTEVR);
 	state->trcseqstr = etm4x_read32(csa, TRCSEQSTR);
 	state->trcextinselr = etm4x_read32(csa, TRCEXTINSELR);
 
 	for (i = 0; i < drvdata->nr_cntr; i++) {
-		state->trccntrldvr[i] = etm4x_read32(csa, TRCCNTRLDVRn(i));
-		state->trccntctlr[i] = etm4x_read32(csa, TRCCNTCTLRn(i));
-		state->trccntvr[i] = etm4x_read32(csa, TRCCNTVRn(i));
+		state->trccntrldvr[i] = etm4x_read32_varreg(csa, TRCCNTRLDVRn(i));
+		state->trccntctlr[i] = etm4x_read32_varreg(csa, TRCCNTCTLRn(i));
+		state->trccntvr[i] = etm4x_read32_varreg(csa, TRCCNTVRn(i));
 	}
 
 	for (i = 0; i < drvdata->nr_resource * 2; i++)
-		state->trcrsctlr[i] = etm4x_read32(csa, TRCRSCTLRn(i));
+		state->trcrsctlr[i] = etm4x_read32_varreg(csa, TRCRSCTLRn(i));
 
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
-		state->trcssccr[i] = etm4x_read32(csa, TRCSSCCRn(i));
-		state->trcsscsr[i] = etm4x_read32(csa, TRCSSCSRn(i));
+		state->trcssccr[i] = etm4x_read32_varreg(csa, TRCSSCCRn(i));
+		state->trcsscsr[i] = etm4x_read32_varreg(csa, TRCSSCSRn(i));
 		if (etm4x_sspcicrn_present(drvdata, i))
-			state->trcsspcicr[i] = etm4x_read32(csa, TRCSSPCICRn(i));
+			state->trcsspcicr[i] = etm4x_read32_varreg(csa, TRCSSPCICRn(i));
 	}
 
 	for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
-		state->trcacvr[i] = etm4x_read64(csa, TRCACVRn(i));
-		state->trcacatr[i] = etm4x_read64(csa, TRCACATRn(i));
+		state->trcacvr[i] = etm4x_read64_varreg(csa, TRCACVRn(i));
+		state->trcacatr[i] = etm4x_read64_varreg(csa, TRCACATRn(i));
 	}
 
 	/*
@@ -1630,10 +1630,10 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
 	 */
 
 	for (i = 0; i < drvdata->numcidc; i++)
-		state->trccidcvr[i] = etm4x_read64(csa, TRCCIDCVRn(i));
+		state->trccidcvr[i] = etm4x_read64_varreg(csa, TRCCIDCVRn(i));
 
 	for (i = 0; i < drvdata->numvmidc; i++)
-		state->trcvmidcvr[i] = etm4x_read64(csa, TRCVMIDCVRn(i));
+		state->trcvmidcvr[i] = etm4x_read64_varreg(csa, TRCVMIDCVRn(i));
 
 	state->trccidcctlr0 = etm4x_read32(csa, TRCCIDCCTLR0);
 	if (drvdata->numcidc > 4)
@@ -1708,38 +1708,38 @@ static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
 	etm4x_relaxed_write32(csa, state->trcvdarcctlr, TRCVDARCCTLR);
 
 	for (i = 0; i < drvdata->nrseqstate - 1; i++)
-		etm4x_relaxed_write32(csa, state->trcseqevr[i], TRCSEQEVRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trcseqevr[i], TRCSEQEVRn(i));
 
 	etm4x_relaxed_write32(csa, state->trcseqrstevr, TRCSEQRSTEVR);
 	etm4x_relaxed_write32(csa, state->trcseqstr, TRCSEQSTR);
 	etm4x_relaxed_write32(csa, state->trcextinselr, TRCEXTINSELR);
 
 	for (i = 0; i < drvdata->nr_cntr; i++) {
-		etm4x_relaxed_write32(csa, state->trccntrldvr[i], TRCCNTRLDVRn(i));
-		etm4x_relaxed_write32(csa, state->trccntctlr[i], TRCCNTCTLRn(i));
-		etm4x_relaxed_write32(csa, state->trccntvr[i], TRCCNTVRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trccntrldvr[i], TRCCNTRLDVRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trccntctlr[i], TRCCNTCTLRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trccntvr[i], TRCCNTVRn(i));
 	}
 
 	for (i = 0; i < drvdata->nr_resource * 2; i++)
-		etm4x_relaxed_write32(csa, state->trcrsctlr[i], TRCRSCTLRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trcrsctlr[i], TRCRSCTLRn(i));
 
 	for (i = 0; i < drvdata->nr_ss_cmp; i++) {
-		etm4x_relaxed_write32(csa, state->trcssccr[i], TRCSSCCRn(i));
-		etm4x_relaxed_write32(csa, state->trcsscsr[i], TRCSSCSRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trcssccr[i], TRCSSCCRn(i));
+		etm4x_relaxed_write32_varreg(csa, state->trcsscsr[i], TRCSSCSRn(i));
 		if (etm4x_sspcicrn_present(drvdata, i))
-			etm4x_relaxed_write32(csa, state->trcsspcicr[i], TRCSSPCICRn(i));
+			etm4x_relaxed_write32_varreg(csa, state->trcsspcicr[i], TRCSSPCICRn(i));
 	}
 
 	for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
-		etm4x_relaxed_write64(csa, state->trcacvr[i], TRCACVRn(i));
-		etm4x_relaxed_write64(csa, state->trcacatr[i], TRCACATRn(i));
+		etm4x_relaxed_write64_varreg(csa, state->trcacvr[i], TRCACVRn(i));
+		etm4x_relaxed_write64_varreg(csa, state->trcacatr[i], TRCACATRn(i));
 	}
 
 	for (i = 0; i < drvdata->numcidc; i++)
-		etm4x_relaxed_write64(csa, state->trccidcvr[i], TRCCIDCVRn(i));
+		etm4x_relaxed_write64_varreg(csa, state->trccidcvr[i], TRCCIDCVRn(i));
 
 	for (i = 0; i < drvdata->numvmidc; i++)
-		etm4x_relaxed_write64(csa, state->trcvmidcvr[i], TRCVMIDCVRn(i));
+		etm4x_relaxed_write64_varreg(csa, state->trcvmidcvr[i], TRCVMIDCVRn(i));
 
 	etm4x_relaxed_write32(csa, state->trccidcctlr0, TRCCIDCCTLR0);
 	if (drvdata->numcidc > 4)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index e5b79bdb9851..acad1befa207 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -1001,6 +1001,75 @@ void etm4_config_trace_mode(struct etmv4_config *config);
 u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit);
 void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit);
 
+/*
+ * Register accessors for variable register number, use in a loop
+ * when 'reg' is not a constant that can be passed into an inline
+ * assembly.
+ */
+static inline void etm4x_relaxed_write32_varreg(struct csdev_access *csa, u32 val, u32 offset)
+{
+	if (csa->io_mem)
+		writel_relaxed(val, csa->base + offset);
+	else
+		etm4x_sysreg_write(val, offset, true, false);
+}
+
+static inline void etm4x_relaxed_write64_varreg(struct csdev_access *csa, u64 val, u32 offset)
+{
+	if (csa->io_mem)
+		writeq_relaxed(val, csa->base + offset);
+	else
+		etm4x_sysreg_write(val, offset, true, true);
+}
+
+static inline void etm4x_write32_varreg(struct csdev_access *csa, u32 val, u32 offset)
+{
+	if (csa->io_mem)
+		writel(val, csa->base + offset);
+	else
+		etm4x_sysreg_write(val, offset, false, false);
+}
+
+static inline void etm4x_write64_varreg(struct csdev_access *csa, u64 val, u32 offset)
+{
+	if (csa->io_mem)
+		writeq(val, csa->base + offset);
+	else
+		etm4x_sysreg_write(val, offset, false, true);
+}
+
+static inline u32 etm4x_relaxed_read32_varreg(struct csdev_access *csa, u32 offset)
+{
+	if (csa->io_mem)
+		return readl_relaxed(csa->base + offset);
+	else
+		return etm4x_sysreg_read(offset, true, false);
+}
+
+static inline u64 etm4x_relaxed_read64_varreg(struct csdev_access *csa, u32 offset)
+{
+	if (csa->io_mem)
+		return readq(csa->base + offset);
+	else
+		return etm4x_sysreg_read(offset, true, true);
+}
+
+static inline u32 etm4x_read32_varreg(struct csdev_access *csa, u32 offset)
+{
+	if (csa->io_mem)
+		return readl(csa->base + offset);
+	else
+		return etm4x_sysreg_read(offset, false, false);
+}
+
+static inline u64 etm4x_read64_varreg(struct csdev_access *csa, u32 offset)
+{
+	if (csa->io_mem)
+		return readl(csa->base + offset);
+	else
+		return etm4x_sysreg_read(offset, false, true);
+}
+
 static inline bool etm4x_is_ete(struct etmv4_drvdata *drvdata)
 {
 	return drvdata->arch >= ETM_ARCH_ETE;
-- 
2.29.2



From leo.yan at linaro.org  Thu Apr 29 16:00:57 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 23:00:57 +0800
Subject: [PATCH v1 0/3] perf arm-spe: Correct recording configurations
Message-ID: <20210429150100.282180-1-leo.yan@linaro.org>

This patch series is to correct Arm SPE recording configurations.

As found by James Clark, it's not reasonable for the current code for
sample flags CPU/TIME/TID which are hard coded.  For TIME sample flag,
since it's always enabled, then Arm SPE has no chance for timeless
tracing; for CPU sample flag, it's not needed for per-thread mode;
for TID sample flag, it's redundant for AUX and dummy events.

This series corrects the sample flags setting, and it enables
timestamp for per-cpu mode tracing by default.

This patch set has been tested on Arm64 Hisilicon D06 platform.


Leo Yan (3):
  perf arm-spe: Correct sample flags for SPE event
  perf arm-spe: Correct sample flags for dummy event
  perf arm-spe: Enable timestamp for per-cpu mode

 tools/perf/arch/arm64/util/arm-spe.c | 66 +++++++++++++++++++++-------
 1 file changed, 50 insertions(+), 16 deletions(-)

-- 
2.25.1



From leo.yan at linaro.org  Thu Apr 29 16:00:58 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 23:00:58 +0800
Subject: [PATCH v1 1/3] perf arm-spe: Correct sample flags for SPE event
In-Reply-To: <20210429150100.282180-1-leo.yan@linaro.org>
References: <20210429150100.282180-1-leo.yan@linaro.org>
Message-ID: <20210429150100.282180-2-leo.yan@linaro.org>

Now it's hard code to set sample flags for CPU, TIME and TID for SPE
event, which is pointless.

The CPU is useful for sampling only for per-mmap case, it is used to
indicate the AUX trace is associated to which CPU.

The TIME sample is not needed for AUX event, since the time for AUX
event is not really used and this time is a different thing from the
timestamp in Arm SPE trace, the timestamp tracing which is controlled
by Arm SPE's config bit.

The TID sample is not useful for AUX event.

This patch corrects the sample flags for SPE event, it only set CPU
sample bit for per-cpu mmap case.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/arch/arm64/util/arm-spe.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 414c8a5584b1..902e73a64184 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -68,6 +68,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
 			container_of(itr, struct arm_spe_recording, itr);
 	struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
 	struct evsel *evsel, *arm_spe_evsel = NULL;
+	struct perf_cpu_map *cpus = evlist->core.cpus;
 	bool privileged = perf_event_paranoid_check(-1);
 	struct evsel *tracking_evsel;
 	int err;
@@ -120,9 +121,9 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
 	 */
 	evlist__to_front(evlist, arm_spe_evsel);
 
-	evsel__set_sample_bit(arm_spe_evsel, CPU);
-	evsel__set_sample_bit(arm_spe_evsel, TIME);
-	evsel__set_sample_bit(arm_spe_evsel, TID);
+	/* In the case of per-cpu mmaps, sample CPU for AUX event. */
+	if (!perf_cpu_map__empty(cpus))
+		evsel__set_sample_bit(arm_spe_evsel, CPU);
 
 	/* Add dummy event to keep tracking */
 	err = parse_events(evlist, "dummy:u", NULL);
-- 
2.25.1



From leo.yan at linaro.org  Thu Apr 29 16:00:59 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 23:00:59 +0800
Subject: [PATCH v1 2/3] perf arm-spe: Correct sample flags for dummy event
In-Reply-To: <20210429150100.282180-1-leo.yan@linaro.org>
References: <20210429150100.282180-1-leo.yan@linaro.org>
Message-ID: <20210429150100.282180-3-leo.yan@linaro.org>

The dummy event is mainly used for mmap, the TIME sample is only needed
for per-cpu case so that the perf tool can rely on the correct timing
for parsing symbols.  And the CPU sample is useless for mmap.

This patch enables TIME sample for per-cpu mmap and doesn't enable CPU
sample.  For later extension (e.g. support multiple AUX events), it sets
the dummy event when the condition "opts->full_auxtrace" is true.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/arch/arm64/util/arm-spe.c | 30 ++++++++++++++++------------
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 902e73a64184..f6eec0900604 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -70,7 +70,6 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
 	struct evsel *evsel, *arm_spe_evsel = NULL;
 	struct perf_cpu_map *cpus = evlist->core.cpus;
 	bool privileged = perf_event_paranoid_check(-1);
-	struct evsel *tracking_evsel;
 	int err;
 
 	sper->evlist = evlist;
@@ -126,18 +125,23 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
 		evsel__set_sample_bit(arm_spe_evsel, CPU);
 
 	/* Add dummy event to keep tracking */
-	err = parse_events(evlist, "dummy:u", NULL);
-	if (err)
-		return err;
-
-	tracking_evsel = evlist__last(evlist);
-	evlist__set_tracking_event(evlist, tracking_evsel);
-
-	tracking_evsel->core.attr.freq = 0;
-	tracking_evsel->core.attr.sample_period = 1;
-	evsel__set_sample_bit(tracking_evsel, TIME);
-	evsel__set_sample_bit(tracking_evsel, CPU);
-	evsel__reset_sample_bit(tracking_evsel, BRANCH_STACK);
+	if (opts->full_auxtrace) {
+		struct evsel *tracking_evsel;
+
+		err = parse_events(evlist, "dummy:u", NULL);
+		if (err)
+			return err;
+
+		tracking_evsel = evlist__last(evlist);
+		evlist__set_tracking_event(evlist, tracking_evsel);
+
+		tracking_evsel->core.attr.freq = 0;
+		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))
+			evsel__set_sample_bit(tracking_evsel, TIME);
+	}
 
 	return 0;
 }
-- 
2.25.1



From leo.yan at linaro.org  Thu Apr 29 16:01:00 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 23:01:00 +0800
Subject: [PATCH v1 3/3] perf arm-spe: Enable timestamp for per-cpu mode
In-Reply-To: <20210429150100.282180-1-leo.yan@linaro.org>
References: <20210429150100.282180-1-leo.yan@linaro.org>
Message-ID: <20210429150100.282180-4-leo.yan@linaro.org>

For per-cpu mmap, it should enable timestamp tracing for Arm SPE; this
is helpful for samples correlation.

To automatically enable the timestamp, a helper arm_spe_set_timestamp()
is introduced for setting "ts_enable" format bit.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 tools/perf/arch/arm64/util/arm-spe.c | 33 ++++++++++++++++++++++++++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index f6eec0900604..dae115dd458e 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -14,6 +14,7 @@
 #include "../../../util/cpumap.h"
 #include "../../../util/event.h"
 #include "../../../util/evsel.h"
+#include "../../../util/evsel_config.h"
 #include "../../../util/evlist.h"
 #include "../../../util/session.h"
 #include <internal/lib.h> // page_size
@@ -32,6 +33,29 @@ struct arm_spe_recording {
 	struct evlist		*evlist;
 };
 
+static void arm_spe_set_timestamp(struct auxtrace_record *itr,
+				  struct evsel *evsel)
+{
+	struct arm_spe_recording *ptr;
+	struct perf_pmu *arm_spe_pmu;
+	struct evsel_config_term *term = evsel__get_config_term(evsel, CFG_CHG);
+	u64 user_bits = 0, bit;
+
+	ptr = container_of(itr, struct arm_spe_recording, itr);
+	arm_spe_pmu = ptr->arm_spe_pmu;
+
+	if (term)
+		user_bits = term->val.cfg_chg;
+
+	bit = perf_pmu__format_bits(&arm_spe_pmu->format, "ts_enable");
+
+	/* Skip if user has set it */
+	if (bit & user_bits)
+		return;
+
+	evsel->core.attr.config |= bit;
+}
+
 static size_t
 arm_spe_info_priv_size(struct auxtrace_record *itr __maybe_unused,
 		       struct evlist *evlist __maybe_unused)
@@ -120,9 +144,14 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
 	 */
 	evlist__to_front(evlist, arm_spe_evsel);
 
-	/* In the case of per-cpu mmaps, sample CPU for AUX event. */
-	if (!perf_cpu_map__empty(cpus))
+	/*
+	 * 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)) {
 		evsel__set_sample_bit(arm_spe_evsel, CPU);
+		arm_spe_set_timestamp(itr, arm_spe_evsel);
+	}
 
 	/* Add dummy event to keep tracking */
 	if (opts->full_auxtrace) {
-- 
2.25.1



From alice.guo at oss.nxp.com  Thu Apr 29 16:22:51 2021
From: alice.guo at oss.nxp.com (Alice Guo (OSS))
Date: Thu, 29 Apr 2021 15:22:51 +0000
Subject: [PATCH v1 2/2] caam: imx8m: change to use of_match_node in
 run_descriptor_deco0
In-Reply-To: <CAOMZO5Cbfh3Aj5-i2y+GDZ=-SZw-wLMbPMew=YTcf9Yr6ohVCw@mail.gmail.com>
References: <20210429140250.2321-1-alice.guo@oss.nxp.com>
 <20210429140250.2321-2-alice.guo@oss.nxp.com>
 <CAOMZO5Cbfh3Aj5-i2y+GDZ=-SZw-wLMbPMew=YTcf9Yr6ohVCw@mail.gmail.com>
Message-ID: <AM6PR04MB60536DF97D12915D5E5A8663E25F9@AM6PR04MB6053.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Fabio Estevam <festevam at gmail.com>
> Sent: 2021?4?29? 22:05
> Subject: Re: [PATCH v1 2/2] caam: imx8m: change to use of_match_node in
> run_descriptor_deco0
> 
> Hi Alice
> 
> On Thu, Apr 29, 2021 at 11:02 AM Alice Guo (OSS) <alice.guo at oss.nxp.com>
> wrote:
> >
> > From: Alice Guo <alice.guo at nxp.com>
> >
> > Patch "fix the built-in caam driver cannot match soc_id" provides
> > imx8m_machine_match to match i.MX8M{Q,M,N,P}, so change to use to
> > of_match_node which can simplify the code.
> 
> Shouldn't these patches be squashed?

These patches should not be squashed because "fix the built-in caam driver cannot match soc_id"
is mainly used to provide defer probe when soc device has not been probed yet, and is only for
i.MX8M. "change to use of_match_node in run_descriptor_deco0" is just to simplify code.

Best Regards,
Alice Guo

 


From leo.yan at linaro.org  Thu Apr 29 16:23:26 2021
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 29 Apr 2021 23:23:26 +0800
Subject: [PATCH v4 4/6] perf arm-spe: Assign kernel time to synthesized
 event
In-Reply-To: <c9c060d1-0884-b67d-7689-6b45ad10baa9@arm.com>
References: <20210412091006.468557-1-leo.yan@linaro.org>
 <20210412091006.468557-5-leo.yan@linaro.org>
 <9036368a-e824-3d63-da5b-54cf32a86aed@arm.com>
 <20210415152348.GF1011890@leoy-ThinkPad-X240s>
 <c9c060d1-0884-b67d-7689-6b45ad10baa9@arm.com>
Message-ID: <20210429152326.GA282348@leoy-ThinkPad-X240s>

Hi James,

On Fri, Apr 16, 2021 at 03:51:25PM +0300, James Clark wrote:

[...]

> >>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
> >>> index 23714cf0380e..c13a89f06ab8 100644
> >>> --- a/tools/perf/util/arm-spe.c
> >>> +++ b/tools/perf/util/arm-spe.c
> >>> @@ -234,7 +234,7 @@ static void arm_spe_prep_sample(struct arm_spe *spe,
> >>>  	struct arm_spe_record *record = &speq->decoder->record;
> >>>  
> >>>  	if (!spe->timeless_decoding)
> >>> -		sample->time = speq->timestamp;
> >>> +		sample->time = tsc_to_perf_time(record->timestamp, &spe->tc);
> >>
> >>
> >> I noticed that in arm_spe_recording_options() the TIME sample bit is set regardless of any options.
> >> I don't know of a way to remove this, and if there isn't, does that mean that all the code in this
> >> file that looks at spe->timeless_decoding is untested and has never been hit?
> >>
> >> Unless there is a way to get a perf file with only the AUXTRACE event and no others? I think that one
> >> might have no timestamp set. Otherwise other events will always have timestamps so spe->timeless_decoding
> >> is always false.
> > 
> > Good point.  To be honest, I never noticed this issue until you
> > mentioned this.
> > 
> > We should fix for the "timeless" flow; and it's questionable for the
> > function arm_spe_recording_options(), except for setting
> > PERF_SAMPLE_TIME, it also hard codes for setting
> > PERF_SAMPLE_CPU and PERF_SAMPLE_TID.  Might need to carefully go
> > through this function.
> > 
> 
> Yeah, it's not strictly related to your change, which is definitely an improvement.
> But maybe we should have a look at the SPE implementation relating to timestamps as a whole.

Just now I sent another patch series "perf arm-spe: Correct recording
configurations", which is the following up for the issue you found at
here.

After correcting sample flags, and combining with current patch series
"perf arm-spe: Enable timestamp", I verified the Arm SPE decoding
flows for "timeless" decoding, which can work as expected.

So I think we can move forward for this patch series, for easier review,
I have uploaded my testing branch wiht the complete patches [1].  Could
you help confirm if this works for you?  Thanks!

Leo

[1] https://github.com/Leo-Yan/linux/tree/perf_arm_spe_timestamp_v4_with_correcting_sample_flags


From robh at kernel.org  Thu Apr 29 16:25:15 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 29 Apr 2021 10:25:15 -0500
Subject: [PATCH 2/4] Documentation: bindings: clk: Add bindings for i.MX
 BLK_CTL
In-Reply-To: <20210429073331.21204-3-peng.fan@oss.nxp.com>
References: <20210429073331.21204-1-peng.fan@oss.nxp.com>
 <20210429073331.21204-3-peng.fan@oss.nxp.com>
Message-ID: <1619709915.248803.1303433.nullmailer@robh.at.kernel.org>

On Thu, 29 Apr 2021 15:33:29 +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at nxp.com>
> 
> Document the i.MX BLK_CTL with its devicetree properties.
> 
> Signed-off-by: Peng Fan <peng.fan at nxp.com>
> ---
>  .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     | 73 +++++++++++++++++++
>  1 file changed, 73 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.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/soc/imx/fsl,imx-blk-ctl.example.dt.yaml:0:0: /example-0/blk-ctl at 32e28000: failed to match any schema with compatible: ['fsl,imx8mm-dispmix-blk-ctl', 'syscon']

See https://patchwork.ozlabs.org/patch/1471527

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Thu Apr 29 16:25:15 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 29 Apr 2021 10:25:15 -0500
Subject: [PATCH v4 07/10] dt-bindings: soc: rockchip: Convert grf.txt to
 YAML
In-Reply-To: <20210429081321.17855-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081321.17855-1-cl@rock-chips.com>
Message-ID: <1619709915.260424.1303436.nullmailer@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:13:21 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> Current dts files with 'grf' nodes are manually verified. In order to
> automate this process grf.txt has to be converted to YAML.
> 
> Add new descriptions for:
> "rockchip,rk3568-grf", "syscon", "simple-mfd"
> "rockchip,rk3568-pmugrf", "syscon", "simple-mfd"
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>  .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
>  2 files changed, 60 insertions(+), 61 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.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/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.yaml: properties:compatible: [{'items': [{'enum': ['rockchip,px30-grf', 'rockchip,px30-pmugrf', 'rockchip,px30-usb2phy-grf', 'rockchip,rk3036-grf', 'rockchip,rk3066-grf', 'rockchip,rk3188-grf', 'rockchip,rk3228-grf', 'rockchip,rk3288-grf', 'rockchip,rk3288-sgrf', 'rockchip,rk3308-core-grf', 'rockchip,rk3308-detect-grf', 'rockchip,rk3308-grf', 'rockchip,rk3328-grf', 'rockchip,rk3328-usb2phy-grf', 'rockchip,rk3368-grf', 'rockchip,rk3368-pmugrf', 'rockchip,rk3399-grf', 'rockchip,rk3399-pmugrf', 'rockchip,rk3568-grf', 'rockchip,rk3568-pmugrf', 'rockchip,rv1108-grf', 'rockchip,rv1108-usbgrf']}, {'const': 'syscon'}, {'const': 'simple-mfd'}]}] is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/rockchip/grf.yaml: ignoring, error in schema: properties: compatible
warning: no schema found in file: ./Documentation/devicetree/bindings/soc/rockchip/grf.yaml
Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml:0:0: /example-0/syscon at ff320000: failed to match any schema with compatible: ['rockchip,rk3399-pmugrf', 'syscon', 'simple-mfd']
Documentation/devicetree/bindings/soc/rockchip/grf.example.dt.yaml:0:0: /example-0/syscon at ff770000: failed to match any schema with compatible: ['rockchip,rk3399-grf', 'syscon', 'simple-mfd']

See https://patchwork.ozlabs.org/patch/1471595

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From laurent.pinchart at ideasonboard.com  Thu Apr 29 16:34:00 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 29 Apr 2021 18:34:00 +0300
Subject: [PATCH] ARM: dts: r8a7779, marzen: Fix DU clock names
In-Reply-To: <9d5e1b371121883b3b3e10a3df43802a29c6a9da.1619699965.git.geert+renesas@glider.be>
References: <9d5e1b371121883b3b3e10a3df43802a29c6a9da.1619699965.git.geert+renesas@glider.be>
Message-ID: <YIrR6NGTKA6z/wNE@pendragon.ideasonboard.com>

Hi Geert,

Thank you for the patch.

On Thu, Apr 29, 2021 at 02:41:15PM +0200, Geert Uytterhoeven wrote:
> "make dtbs_check" complains:
> 
>     arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display at fff80000: clock-names:0: 'du.0' was expected
> 
> Change the first clock name to match the DT bindings.
> This has no effect on actual operation, as the Display Unit driver in
> Linux does not use the first clock name on R-Car H1, but just grabs the
> first clock.

The driver agrees with that statement. I haven't tested it though.

> Fixes: 665d79aa47cb3983 ("ARM: shmobile: marzen: Add DU external pixel clock to DT")
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
> To be queued in renesas-devel for v5.14.
> 
>  arch/arm/boot/dts/r8a7779-marzen.dts | 2 +-
>  arch/arm/boot/dts/r8a7779.dtsi       | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
> index d2240b89ee52929b..46584532349590d1 100644
> --- a/arch/arm/boot/dts/r8a7779-marzen.dts
> +++ b/arch/arm/boot/dts/r8a7779-marzen.dts
> @@ -145,7 +145,7 @@ &du {
>  	status = "okay";
>  
>  	clocks = <&mstp1_clks R8A7779_CLK_DU>, <&x3_clk>;
> -	clock-names = "du", "dclkin.0";
> +	clock-names = "du.0", "dclkin.0";
>  
>  	ports {
>  		port at 0 {
> diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> index 74d7e9084eabe173..3c5fcdfe16b87182 100644
> --- a/arch/arm/boot/dts/r8a7779.dtsi
> +++ b/arch/arm/boot/dts/r8a7779.dtsi
> @@ -463,6 +463,7 @@ du: display at fff80000 {
>  		reg = <0xfff80000 0x40000>;
>  		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
>  		clocks = <&mstp1_clks R8A7779_CLK_DU>;
> +		clock-names = "du.0";
>  		power-domains = <&sysc R8A7779_PD_ALWAYS_ON>;
>  		status = "disabled";
>  

-- 
Regards,

Laurent Pinchart


From enric.balletbo at collabora.com  Thu Apr 29 16:46:39 2021
From: enric.balletbo at collabora.com (Enric Balletbo i Serra)
Date: Thu, 29 Apr 2021 17:46:39 +0200
Subject: [PATCH v1 4/4] mtk-mdp: soc: mediatek: register mdp from mmsys
In-Reply-To: <20210423155824.v1.4.I558dcbaa17bf00243951a8ceb6d0e98758aacfa4@changeid>
References: <20210423055842.2490679-1-eizan@chromium.org>
 <20210423155824.v1.4.I558dcbaa17bf00243951a8ceb6d0e98758aacfa4@changeid>
Message-ID: <ecf9ab25-779d-01c7-97e3-76aa09b69415@collabora.com>

Hi Eizan,

Thank you for your patch.

On 23/4/21 7:58, Eizan Miyamoto wrote:
> Rather than hanging the MDP master component driver off of the rdma0
> device, create a "virtual" device by the mmsys driver instead which is
> probed by the mtk_mdp_core driver.
> 
> Broadly, four interdependent things are done by this change:
> - A virtual device that is probed by the mtk_mdp_core driver is
>   instantiated by the mtk_mmsys driver.
> - Presence of a mediatek,vpu property in a child node to the mmsys
>   device node is used to determine what device to use when dispatching
>   dma ops from the relevant ioctl.
> - v4l-related setup is moved into from the mtk_mdp_core driver to the
>   mtk_mdp_comp driver.
> 
> Signed-off-by: Eizan Miyamoto <eizan at chromium.org>
> ---
> 
>  drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 47 +++++++++-----
>  drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 62 ++++++-------------
>  drivers/media/platform/mtk-mdp/mtk_mdp_core.h |  2 +
>  drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c  |  4 +-
>  drivers/soc/mediatek/mtk-mmsys.c              | 20 +++++-
>  5 files changed, 75 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index d447bfaadef4..dc5231a1fcfd 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -106,8 +106,41 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
>  {
>  	struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
>  	struct mtk_mdp_dev *mdp = data;
> +	struct device_node *vpu_node;
>  
>  	mtk_mdp_register_component(mdp, comp);
> +
> +	// If this component has a "mediatek-vpu" property, it is responsible for
> +	// notifying the mdp master driver about it so it can be further initialized
> +	// later.

Please use c-style comments here.

> +	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);

That's a bit confusing to me, please correct me if I am wrong, so, the
mediatek,vpu property is used to tell the code that this component should be the
'vpu master', not to point a vpu node in the DT? I understood correctly?


> +	if (vpu_node) {
> +		int ret;
> +
> +		mdp->vpu_dev = of_find_device_by_node(vpu_node);
> +		if (WARN_ON(!mdp->vpu_dev)) {
> +			dev_err(dev, "vpu pdev failed\n");
> +			of_node_put(vpu_node);
> +		}
> +
> +		ret = v4l2_device_register(dev, &mdp->v4l2_dev);
> +		if (ret) {
> +			dev_err(dev, "Failed to register v4l2 device\n");
> +			return -EINVAL;
> +		}
> +
> +		ret = vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +		if (ret) {
> +			dev_err(dev, "Failed to set vb2 dma mag seg size\n");
> +			return -EINVAL;
> +		}
> +
> +		// presence of the "mediatek,vpu" property in a device node
> +		// indicates that it is the primary MDP rdma device and MDP DMA
> +		// ops should be handled by its DMA callbacks.

Isn't rdma0 always the primary MDP device? or there are SoCs or configurations
where this is different? At least I think it is for MT8173 and MT8183.

> +		mdp->rdma_dev = dev;
> +	}
> +
>  	pm_runtime_enable(dev);
>  
>  	return 0;
> @@ -164,23 +197,9 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct device *dev)
>  static int mtk_mdp_comp_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> -	struct device_node *vpu_node;
>  	int status;
>  	struct mtk_mdp_comp *comp;
>  
> -	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
> -	if (vpu_node) {
> -		of_node_put(vpu_node);
> -		/*
> -		 * The device tree node with a mediatek,vpu property is deemed
> -		 * the MDP "master" device, we don't want to add a component
> -		 * for it in this function because the initialization for the
> -		 * master is done elsewhere.
> -		 */
> -		dev_info(dev, "vpu node found, not probing\n");
> -		return -ENODEV;
> -	}
> -
>  	comp = devm_kzalloc(dev, sizeof(*comp), GFP_KERNEL);
>  	if (!comp)
>  		return -ENOMEM;
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index 5e71496e2517..4d7aa4e26be6 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -121,6 +121,17 @@ static int mtk_mdp_master_bind(struct device *dev)
>  		goto err_component_bind_all;
>  	}
>  
> +	if (mdp->vpu_dev) {
> +		int ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> +					  VPU_RST_MDP);
> +		if (ret) {
> +			dev_err(dev, "Failed to register reset handler\n");
> +			goto err_wdt_reg;
> +		}
> +	} else {
> +		dev_err(dev, "no vpu_dev found\n");
> +	}
> +
>  	status = mtk_mdp_register_m2m_device(mdp);
>  	if (status) {
>  		dev_err(dev, "Failed to register m2m device: %d\n", status);
> @@ -133,6 +144,8 @@ static int mtk_mdp_master_bind(struct device *dev)
>  	return 0;
>  
>  err_mtk_mdp_register_m2m_device:
> +
> +err_wdt_reg:
>  	component_unbind_all(dev, mdp);
>  
>  err_component_bind_all:
> @@ -191,8 +204,13 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>  		of_node_put(node);
>  		parent = dev->of_node;
>  		dev_warn(dev, "device tree is out of date\n");
> -	} else {
> +	} else if (dev->of_node) {
>  		parent = dev->of_node->parent;
> +	} else if (dev->parent) {
> +		// maybe we were created from a call to platform_device_register_data()
> +		parent = dev->parent->parent->of_node;
> +	} else {
> +		return -ENODEV;
>  	}
>  
>  	/* Iterate over sibling MDP function blocks */
> @@ -225,16 +243,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	/*
> -	 * Create a component for myself so that clocks can be toggled in
> -	 * clock_on().
> -	 */
> -	ret = mtk_mdp_comp_init(&mdp->comp_self, dev);
> -	if (ret) {
> -		dev_err(dev, "Failed to initialize component\n");
> -		goto err_comp;
> -	}
> -
>  	mdp->job_wq = create_singlethread_workqueue(MTK_MDP_MODULE_NAME);
>  	if (!mdp->job_wq) {
>  		dev_err(&pdev->dev, "unable to alloc job workqueue\n");
> @@ -250,29 +258,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>  	}
>  	INIT_WORK(&mdp->wdt_work, mtk_mdp_wdt_worker);
>  
> -	ret = v4l2_device_register(dev, &mdp->v4l2_dev);
> -	if (ret) {
> -		dev_err(&pdev->dev, "Failed to register v4l2 device\n");
> -		ret = -EINVAL;
> -		goto err_dev_register;
> -	}
> -
> -	mdp->vpu_dev = vpu_get_plat_device(pdev);
> -	ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> -				  VPU_RST_MDP);
> -	if (ret) {
> -		dev_err(&pdev->dev, "Failed to register reset handler\n");
> -		goto err_wdt_reg;
> -	}
> -
>  	platform_set_drvdata(pdev, mdp);
>  
> -	ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> -	if (ret) {
> -		dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
> -		goto err_set_max_seg_size;
> -	}
> -
>  	ret = component_master_add_with_match(dev, &mtk_mdp_com_ops, match);
>  	if (ret) {
>  		dev_err(dev, "Component master add failed\n");
> @@ -284,22 +271,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>  	return 0;
>  
>  err_component_master_add:
> -	vb2_dma_contig_clear_max_seg_size(&pdev->dev);
> -
> -err_set_max_seg_size:
> -
> -err_wdt_reg:
> -	v4l2_device_unregister(&mdp->v4l2_dev);
> -
> -err_dev_register:
>  	destroy_workqueue(mdp->wdt_wq);
>  
>  err_alloc_wdt_wq:
>  	destroy_workqueue(mdp->job_wq);
>  
>  err_alloc_job_wq:
> -
> -err_comp:
>  	dev_dbg(dev, "err %d\n", ret);
>  	return ret;
>  }
> @@ -371,7 +348,6 @@ static struct platform_driver mtk_mdp_driver = {
>  	.driver = {
>  		.name	= MTK_MDP_MODULE_NAME,
>  		.pm	= &mtk_mdp_pm_ops,
> -		.of_match_table = mtk_mdp_of_ids,
>  	}
>  };
>  
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> index 230f531400ca..78c3c77cd226 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> @@ -133,6 +133,7 @@ struct mtk_mdp_variant {
>   * struct mtk_mdp_dev - abstraction for image processor entity
>   * @lock:	the mutex protecting this data structure
>   * @vpulock:	the mutex protecting the communication with VPU
> + * @rdma_dev:  device pointer to rdma device for MDP
>   * @pdev:	pointer to the image processor platform device
>   * @variant:	the IP variant information
>   * @id:		image processor device index (0..MTK_MDP_MAX_DEVS)
> @@ -151,6 +152,7 @@ struct mtk_mdp_variant {
>  struct mtk_mdp_dev {
>  	struct mutex			lock;
>  	struct mutex			vpulock;
> +	struct device			*rdma_dev;
>  	struct platform_device		*pdev;
>  	struct mtk_mdp_variant		*variant;
>  	u16				id;
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index d351e5a44768..c80ad8299c5e 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -932,7 +932,7 @@ static int mtk_mdp_m2m_queue_init(void *priv, struct vb2_queue *src_vq,
>  	src_vq->mem_ops = &vb2_dma_contig_memops;
>  	src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
>  	src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> -	src_vq->dev = &ctx->mdp_dev->pdev->dev;
> +	src_vq->dev = ctx->mdp_dev->rdma_dev;
>  	src_vq->lock = &ctx->mdp_dev->lock;
>  
>  	ret = vb2_queue_init(src_vq);
> @@ -947,7 +947,7 @@ static int mtk_mdp_m2m_queue_init(void *priv, struct vb2_queue *src_vq,
>  	dst_vq->mem_ops = &vb2_dma_contig_memops;
>  	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
>  	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> -	dst_vq->dev = &ctx->mdp_dev->pdev->dev;
> +	dst_vq->dev = ctx->mdp_dev->rdma_dev;
>  	dst_vq->lock = &ctx->mdp_dev->lock;
>  
>  	return vb2_queue_init(dst_vq);
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
> index 18f93979e14a..6f9cf7725529 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -305,6 +305,7 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct platform_device *clks;
>  	struct platform_device *drm;
> +	struct platform_device *mdp;
>  	void __iomem *config_regs;
>  	int ret;
>  
> @@ -328,10 +329,27 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
>  					    PLATFORM_DEVID_AUTO, NULL, 0);
>  	if (IS_ERR(drm)) {
>  		platform_device_unregister(clks);
> -		return PTR_ERR(drm);
> +		ret = PTR_ERR(drm);
> +		goto err_drm;
> +	}
> +
> +	mdp = platform_device_register_data(&pdev->dev, "mtk-mdp",
> +					    PLATFORM_DEVID_AUTO, NULL, 0);
> +	if (IS_ERR(mdp)) {
> +		ret = PTR_ERR(mdp);
> +		dev_err(dev, "Failed to register mdp: %d\n", ret);
> +		goto err_mdp;
>  	}
>  
>  	return 0;
> +
> +err_mdp:
> +	platform_device_unregister(drm);
> +
> +err_drm:
> +	platform_device_unregister(clks);
> +
> +	return ret;
>  }
>  
>  static const struct of_device_id of_match_mtk_mmsys[] = {
> 


From steven.price at arm.com  Thu Apr 29 17:06:05 2021
From: steven.price at arm.com (Steven Price)
Date: Thu, 29 Apr 2021 17:06:05 +0100
Subject: [PATCH v11 1/6] arm64: mte: Sync tags for pages where PTE is
 untagged
In-Reply-To: <20210427174357.GA17872@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-2-steven.price@arm.com>
 <20210427174357.GA17872@arm.com>
Message-ID: <0ab0017c-1eaf-201e-587f-101e03da6b80@arm.com>

On 27/04/2021 18:43, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 04:43:04PM +0100, Steven Price wrote:
>> A KVM guest could store tags in a page even if the VMM hasn't mapped
>> the page with PROT_MTE. So when restoring pages from swap we will
>> need to check to see if there are any saved tags even if !pte_tagged().
>>
>> However don't check pages which are !pte_valid_user() as these will
>> not have been swapped out.
> 
> You should remove the pte_valid_user() mention from the commit log as
> well.

Good spot - sorry about that. I really must get better at reading my own 
commit messages.

>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index e17b96d0e4b5..cf4b52a33b3c 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -312,7 +312,7 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
>>   		__sync_icache_dcache(pte);
>>   
>>   	if (system_supports_mte() &&
>> -	    pte_present(pte) && pte_tagged(pte) && !pte_special(pte))
>> +	    pte_present(pte) && (pte_val(pte) & PTE_USER) && !pte_special(pte))
> 
> I would add a pte_user() macro here or, if we restore the tags only when
> the page is readable, use pte_access_permitted(pte, false). Also add a
> comment why we do this.

pte_access_permitted() looks like it describes what we want (user space 
can access the memory). I'll add the following comment:

  /*
   * If the PTE would provide user space will access to the tags
   * associated with it then ensure that the MTE tags are synchronised.
   * Exec-only mappings don't expose tags (instruction fetches don't
   * check tags).
   */

> There's also the pte_user_exec() case which may not have the PTE_USER
> set (exec-only permission) but I don't think it matters. We don't do tag
> checking on instruction fetches, so if the user adds a PROT_READ to it,
> it would go through set_pte_at() again. I'm not sure KVM does anything
> special with exec-only mappings at stage 2, I suspect they won't be
> accessible by the guest (but needs checking).

It comes down to the behaviour of get_user_pages(). AFAICT that will 
fail if the memory is exec-only, so no stage 2 mapping will be created. 
Which of course means the guest can't do anything with that memory. That 
certainly seems like the only sane behaviour even without MTE.

>>   		mte_sync_tags(ptep, pte);
>>   
>>   	__check_racy_pte_update(mm, ptep, pte);
>> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
>> index b3c70a612c7a..e016ab57ea36 100644
>> --- a/arch/arm64/kernel/mte.c
>> +++ b/arch/arm64/kernel/mte.c
>> @@ -26,17 +26,23 @@ u64 gcr_kernel_excl __ro_after_init;
>>   
>>   static bool report_fault_once = true;
>>   
>> -static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
>> +static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap,
>> +			       bool pte_is_tagged)
>>   {
>>   	pte_t old_pte = READ_ONCE(*ptep);
>>   
>>   	if (check_swap && is_swap_pte(old_pte)) {
>>   		swp_entry_t entry = pte_to_swp_entry(old_pte);
>>   
>> -		if (!non_swap_entry(entry) && mte_restore_tags(entry, page))
>> +		if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) {
>> +			set_bit(PG_mte_tagged, &page->flags);
>>   			return;
>> +		}
>>   	}
>>   
>> +	if (!pte_is_tagged || test_and_set_bit(PG_mte_tagged, &page->flags))
>> +		return;
> 
> I don't think we need another test_bit() here, it was done in the
> caller (bar potential races which need more thought).

Good point - I'll change that to a straight set_bit().

>> +
>>   	page_kasan_tag_reset(page);
>>   	/*
>>   	 * We need smp_wmb() in between setting the flags and clearing the
>> @@ -54,11 +60,13 @@ void mte_sync_tags(pte_t *ptep, pte_t pte)
>>   	struct page *page = pte_page(pte);
>>   	long i, nr_pages = compound_nr(page);
>>   	bool check_swap = nr_pages == 1;
>> +	bool pte_is_tagged = pte_tagged(pte);
>>   
>>   	/* if PG_mte_tagged is set, tags have already been initialised */
>>   	for (i = 0; i < nr_pages; i++, page++) {
>> -		if (!test_and_set_bit(PG_mte_tagged, &page->flags))
>> -			mte_sync_page_tags(page, ptep, check_swap);
>> +		if (!test_bit(PG_mte_tagged, &page->flags))
>> +			mte_sync_page_tags(page, ptep, check_swap,
>> +					   pte_is_tagged);
>>   	}
>>   }
> 
> You were right in the previous thread that if we have a race, it's
> already there even without your patches KVM patches.
> 
> If it's the same pte in a multithreaded app, we should be ok as the core
> code holds the ptl (the arch code also holds the mmap_lock during
> exception handling but only as a reader, so you can have multiple
> holders).
> 
> If there are multiple ptes to the same page, for example mapped with
> MAP_ANONYMOUS | MAP_SHARED, metadata recovery is done via
> arch_swap_restore() before we even set the pte and with the page locked.
> So calling lock_page() again in mte_restore_tags() would deadlock.
> 
> I can see that do_swap_page() also holds the page lock around
> set_pte_at(), so I think we are covered.
> 
> Any other scenario I may have missed? My understanding is that if the
> pte is the same, we have the ptl. Otherwise we have the page lock for
> shared pages.

That is my understanding - either the PTL is held or the page is locked. 
But I am aware I was partly basing that on an assumption that the 
existing code is correct. If there's a way that a new PTE can be created 
which races with the arch_swap_restore() path then there is a problem. 
I'm not aware of how that would happen though.

Steve


From steven.price at arm.com  Thu Apr 29 17:06:07 2021
From: steven.price at arm.com (Steven Price)
Date: Thu, 29 Apr 2021 17:06:07 +0100
Subject: [PATCH v11 5/6] KVM: arm64: ioctl to fetch/store tags in a guest
In-Reply-To: <20210427175844.GB17872@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-6-steven.price@arm.com>
 <20210427175844.GB17872@arm.com>
Message-ID: <340d35c2-46ed-35ea-43fa-e5cb64c27230@arm.com>

On 27/04/2021 18:58, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 04:43:08PM +0100, Steven Price wrote:
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 24223adae150..2b85a047c37d 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -184,6 +184,20 @@ struct kvm_vcpu_events {
>>   	__u32 reserved[12];
>>   };
>>   
>> +struct kvm_arm_copy_mte_tags {
>> +	__u64 guest_ipa;
>> +	__u64 length;
>> +	union {
>> +		void __user *addr;
>> +		__u64 padding;
>> +	};
>> +	__u64 flags;
>> +	__u64 reserved[2];
>> +};
> 
> I know Marc asked for some reserved space in here but I'm not sure it's
> the right place. And what's with the union of a 64-bit pointer and
> 64-bit padding, it doesn't change any layout?

Yes it's unnecessary here - habits die hard. This would ensure that the 
layout is the same for 32 bit and 64 bit. But it's irrelevant here as 
(a) we don't support 32 bit, and (b) flags has 64 bit alignment anyway. 
I'll drop the union (and 'padding').

> Maybe add the two reserved
> values to the union in case we want to store something else in the
> future.

I'm not sure what you mean here. What would the reserved fields be 
unioned with? And surely they are no longer reserved in that case?

> Or maybe I'm missing something, I haven't checked how other KVM ioctls
> work.

KVM ioctls seem to (sometimes) have some reserved space at the end of 
the structure for expansion without the ioctl number changing (since the 
structure size is encoded into the ioctl).

Steve


From steven.price at arm.com  Thu Apr 29 17:06:41 2021
From: steven.price at arm.com (Steven Price)
Date: Thu, 29 Apr 2021 17:06:41 +0100
Subject: [PATCH v11 2/6] arm64: kvm: Introduce MTE VM feature
In-Reply-To: <20210428170705.GB4022@arm.com>
References: <20210416154309.22129-1-steven.price@arm.com>
 <20210416154309.22129-3-steven.price@arm.com> <20210428170705.GB4022@arm.com>
Message-ID: <c3293d47-a5f2-ea4a-6730-f5cae26d8a7e@arm.com>

On 28/04/2021 18:07, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 04:43:05PM +0100, Steven Price wrote:
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index 77cb2d28f2a4..5f8e165ea053 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -879,6 +879,26 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>   	if (vma_pagesize == PAGE_SIZE && !force_pte)
>>   		vma_pagesize = transparent_hugepage_adjust(memslot, hva,
>>   							   &pfn, &fault_ipa);
>> +
>> +	if (fault_status != FSC_PERM && kvm_has_mte(kvm) && !device &&
>> +	    pfn_valid(pfn)) {
> 
> In the current implementation, device == !pfn_valid(), so we could skip
> the latter check.

Thanks, I'll drop that check.

>> +		/*
>> +		 * VM will be able to see the page's tags, so we must ensure
>> +		 * they have been initialised. if PG_mte_tagged is set, tags
>> +		 * have already been initialised.
>> +		 */
>> +		unsigned long i, nr_pages = vma_pagesize >> PAGE_SHIFT;
>> +		struct page *page = pfn_to_online_page(pfn);
>> +
>> +		if (!page)
>> +			return -EFAULT;
> 
> I think that's fine, though maybe adding a comment that otherwise it
> would be mapped at stage 2 as Normal Cacheable and we cannot guarantee
> that the memory supports MTE tags.

That's what I intended by "be able to see the page's tags", but I'll 
reword to be explicit about it being Normal Cacheable.

>> +
>> +		for (i = 0; i < nr_pages; i++, page++) {
>> +			if (!test_and_set_bit(PG_mte_tagged, &page->flags))
>> +				mte_clear_page_tags(page_address(page));
>> +		}
>> +	}
>> +
>>   	if (writable)
>>   		prot |= KVM_PGTABLE_PROT_W;
> 
> I probably asked already but is the only way to map a standard RAM page
> (not device) in stage 2 via the fault handler? One case I had in mind
> was something like get_user_pages() but it looks like that one doesn't
> call set_pte_at_notify(). There are a few other places where
> set_pte_at_notify() is called and these may happen before we got a
> chance to fault on stage 2, effectively populating the entry (IIUC). If
> that's an issue, we could move the above loop and check closer to the
> actual pte setting like kvm_pgtable_stage2_map().

The only call sites of kvm_pgtable_stage2_map() are in mmu.c:

  * kvm_phys_addr_ioremap() - maps as device in stage 2

  * user_mem_abort() - handled above

  * kvm_set_spte_handler() - ultimately called from the .change_pte() 
callback of the MMU notifier

So the last one is potentially a problem. It's called via the MMU 
notifiers in the case of set_pte_at_notify(). The users of that are:

  * uprobe_write_opcode(): Allocates a new page and performs a 
copy_highpage() to copy the data to the new page (which with MTE 
includes the tags and will copy across the PG_mte_tagged flag).

  * write_protect_page() (KSM): Changes the permissions on the PTE but 
it's still the same page, so nothing to do regarding MTE.

  * replace_page() (KSM): If the page has MTE tags then the MTE version 
of memcmp_pages() will return false, so the only caller 
(try_to_merge_one_page()) will never call this on a page with tags.

  * wp_page_copy(): This one is more interesting - if we go down the 
cow_user_page() path with an old page then everything is safe (tags are 
copied over). The is_zero_pfn() case worries me a bit - a new page is 
allocated, but I can't instantly see anything to zero out the tags (and 
set PG_mte_tagged).

  * migrate_vma_insert_page(): I think migration should be safe as the 
tags should be copied.

So wp_page_copy() looks suspicious.

kvm_pgtable_stage2_map() looks like it could be a good place for the 
checks, it looks like it should work and is probably a more obvious 
place for the checks.

> While the set_pte_at() race on the page flags is somewhat clearer, we
> may still have a race here with the VMM's set_pte_at() if the page is
> mapped as tagged. KVM has its own mmu_lock but it wouldn't be held when
> handling the VMM page tables (well, not always, see below).
> 
> gfn_to_pfn_prot() ends up calling get_user_pages*(). At least the slow
> path (hva_to_pfn_slow()) ends up with FOLL_TOUCH in gup and the VMM pte
> would be set, tags cleared (if PROT_MTE) before the stage 2 pte. I'm not
> sure whether get_user_page_fast_only() does the same.
> 
> The race with an mprotect(PROT_MTE) in the VMM is fine I think as the
> KVM mmu notifier is invoked before set_pte_at() and racing with another
> user_mem_abort() is serialised by the KVM mmu_lock. The subsequent
> set_pte_at() would see the PG_mte_tagged set either by the current CPU
> or by the one it was racing with.
> 

Given the changes to set_pte_at() which means that tags are restored 
from swap even if !PROT_MTE, the only race I can see remaining is the 
creation of new PROT_MTE mappings. As you mention an attempt to change 
mappings in the VMM memory space should involve a mmu notifier call 
which I think serialises this. So the remaining issue is doing this in a 
separate address space.

So I guess the potential problem is:

  * allocate memory MAP_SHARED but !PROT_MTE
  * fork()
  * VM causes a fault in parent address space
  * child does a mprotect(PROT_MTE)

With the last two potentially racing. Sadly I can't see a good way of 
handling that.

Steve


From michael at walle.cc  Thu Apr 29 17:23:50 2021
From: michael at walle.cc (Michael Walle)
Date: Thu, 29 Apr 2021 18:23:50 +0200
Subject: [RFC PATCH 1/6] spi: spi-mem: Tell controller when device is
 ready for calibration
In-Reply-To: <20210324080804.x7oemmpt2khi72mp@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-2-p.yadav@ti.com>
 <934c8c6f7bb71729bfdaefd39c63a262@walle.cc>
 <20210324080804.x7oemmpt2khi72mp@ti.com>
Message-ID: <6dfbb3e4107887dc9ee3e19e4940e87c@walle.cc>

Hi Pratyush,

I've had a look at the LS1028A FlexSPI calibration feature. The
reference manual is very sparse on details, though. What you need to
do there is to program a special read command sequence (the whole
controller is made of these lookup table entries, where you can
have a short sequence of operations for read/write/program and so
on). Therefore, for data learning you'll take the read operation
and insert a LEARN op in between and read a specific data pattern.
Then the hardware will automatically figure out the correct sample
phase for the read data pins.

Unfortunately, it does not mention how often you have to do it. It
might be the case that is has to be calibrated more than once.

I'm just mentioning this so it won't be lost. If needed, it can
be added later.

Am 2021-03-24 09:08, schrieb Pratyush Yadav:
> On 24/03/21 12:07AM, Michael Walle wrote:
>> Am 2021-03-11 20:12, schrieb Pratyush Yadav:
>> > Some controllers like the Cadence OSPI controller need to perform a
>> > calibration sequence to operate at high clock speeds. This calibration
>> > should happen after the flash is fully initialized otherwise the
>> > calibration might happen in a different SPI mode from the one the flash
>> > is finally set to. Add a hook that can be used to tell the controller
>> > when the flash is ready for calibration. Whether calibration is needed
>> > depends on the controller.
>> >
>> > Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
>> > ---
>> >  drivers/spi/spi-mem.c       | 12 ++++++++++++
>> >  include/linux/spi/spi-mem.h |  8 ++++++++
>> >  2 files changed, 20 insertions(+)
>> >
>> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
>> > index dc713b0c3c4d..e2f05ad3f4dc 100644
>> > --- a/drivers/spi/spi-mem.c
>> > +++ b/drivers/spi/spi-mem.c
>> > @@ -464,6 +464,18 @@ int spi_mem_adjust_op_size(struct spi_mem *mem,
>> > struct spi_mem_op *op)
>> >  }
>> >  EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
>> >
>> > +int spi_mem_do_calibration(struct spi_mem *mem, struct spi_mem_op *op)
>> > +{
>> > +	struct spi_controller *ctlr = mem->spi->controller;
>> > +
>> > +	if (!ctlr->mem_ops || !ctlr->mem_ops->do_calibration)
>> > +		return -EOPNOTSUPP;
>> > +
>> > +	ctlr->mem_ops->do_calibration(mem, op);
>> 
>> Can't a calibration fail?
> 
> It can. If it does, the controller falls back to lower speed transfers.
> There is not much the upper layer can do about this. That's why it is
> not informed whether it succeeded or not.

Ok, if needed, that should be an easy change.

op is there to decide if we need a calibration at all, correct?
What if there are different factors, like frequency? For example
on the LS1028A its just a matter of the SCK frequency. It seems
that this parameter is tailored to the OPHY.

-michael

>> > +	return 0;
>> > +}
>> > +EXPORT_SYMBOL_GPL(spi_mem_do_calibration);
>> > +
>> >  static ssize_t spi_mem_no_dirmap_read(struct spi_mem_dirmap_desc *desc,
>> >  				      u64 offs, size_t len, void *buf)
>> >  {
>> > diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> > index 2b65c9edc34e..97a2d280f2d0 100644
>> > --- a/include/linux/spi/spi-mem.h
>> > +++ b/include/linux/spi/spi-mem.h
>> > @@ -250,6 +250,12 @@ static inline void *spi_mem_get_drvdata(struct
>> > spi_mem *mem)
>> >   *		  the currently mapped area), and the caller of
>> >   *		  spi_mem_dirmap_write() is responsible for calling it again in
>> >   *		  this case.
>> > + * @do_calibration: perform calibration needed for high SPI clock speed
>> > + *		    operation. Should be called after the SPI memory device has
>> > + *		    been completely initialized. The op passed should contain
>> > + *		    a template for the read operation used for the device so
>> > + *		    the controller can decide what type of calibration is
>> > + *		    required for this type of read.
>> >   *
>> >   * This interface should be implemented by SPI controllers providing an
>> >   * high-level interface to execute SPI memory operation, which is
>> > usually the
>> > @@ -274,6 +280,7 @@ struct spi_controller_mem_ops {
>> >  			       u64 offs, size_t len, void *buf);
>> >  	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
>> >  				u64 offs, size_t len, const void *buf);
>> > +	void (*do_calibration)(struct spi_mem *mem, struct spi_mem_op *op);
>> >  };
>> >
>> >  /**
>> > @@ -346,6 +353,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
>> >  #endif /* CONFIG_SPI_MEM */
>> >
>> >  int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
>> > +int spi_mem_do_calibration(struct spi_mem *mem, struct spi_mem_op *op);
>> >
>> >  bool spi_mem_supports_op(struct spi_mem *mem,
>> >  			 const struct spi_mem_op *op);
>> 



From michael at walle.cc  Thu Apr 29 17:28:13 2021
From: michael at walle.cc (Michael Walle)
Date: Thu, 29 Apr 2021 18:28:13 +0200
Subject: [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if
 possible
In-Reply-To: <20210312101757.sqeyledbwjnpqdoy@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-5-p.yadav@ti.com>
 <2f26456e-59ff-2625-5d65-c1537052839d@microchip.com>
 <20210312101757.sqeyledbwjnpqdoy@ti.com>
Message-ID: <ee2b753b16e76ecbede4c1373b6f2d77@walle.cc>

Am 2021-03-12 11:17, schrieb Pratyush Yadav:
> On 12/03/21 09:13AM, Tudor.Ambarus at microchip.com wrote:
>> On 3/11/21 9:12 PM, Pratyush Yadav wrote:
>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> >
>> > Check if a read is eligible for PHY and if it is, enable PHY and DQS.
>> 
>> DQS as in data strobe? Shouldn't the upper layer inform the QSPI 
>> controller
>> whether DS is required or not?
> 
> Yes, DQS as in data strobe. I need to check this again, but IIRC the
> controller cannot run in PHY mode unless DS is used. Ideally the upper
> layer should indeed inform the controller whether DS is 
> supported/in-use
> or not. That can be used to decide whether PHY mode (and consequently
> the DS line) is to be used or not.
> 
> Currently there are only two flashes that use 8D-8D-8D mode (S28HS512T
> and MT35XU512ABA), and both of them drive the DS line.

The LS1028A datasheet explicitly states that the calibration is only
used for non-DQS flashes. Which makes sense, because it just determine 
at
which point the input data is sampled. And if the flash provides a data
strobe, it already know when to sample it. What I am missing here?

-michael


From sdonthineni at nvidia.com  Thu Apr 29 17:29:04 2021
From: sdonthineni at nvidia.com (Shanker Donthineni)
Date: Thu, 29 Apr 2021 11:29:04 -0500
Subject: [RFC 0/2] [RFC] Honor PCI prefetchable attributes for a virtual
 machine on ARM64
Message-ID: <20210429162906.32742-1-sdonthineni@nvidia.com>

Problem statement: Virtual machine crashes when NVIDIA GPU driver access a prefetchable BAR space due to the unaligned reads/writes for pass-through devices. The same binary works fine as expected in the host kernel. Only one BAR has control & status registers (CSR) and other PCI BARs are marked as prefetchable. NVIDIA GPU driver uses the write-combine feature for mapping the prefetchable BARs to improve performance. This problem applies to all other drivers which want to enable WC.
 
Solution: Honor PCI prefetchable attributes for the guest operating systems.
 
Proposal: ARM64-KVM uses VMA struct for the needed information e.g. region physical address, size, and memory-type (struct page backed mapping or anonymous memory) for setting up a stage-2 page table. Right now memory region either can be mapped as DEVICE (strongly ordered) or NORMAL (write-back cache) depends on the flag VM_PFNMAP in VMA. VFIO-PCI will keep the prefetchable (write-combine) information in vma->vm_page_prot similar to other fields, and KVM will prepare stage-2 entries based on the memory-type attribute that was set in VMA.

Shanker Donthineni (2):
  vfio/pci: keep the prefetchable attribute of a BAR region in VMA
  KVM: arm64: Add write-combine support for stage-2 entries

 arch/arm64/include/asm/kvm_mmu.h     |  3 ++-
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  4 +++-
 arch/arm64/kvm/hyp/pgtable.c         |  9 +++++++--
 arch/arm64/kvm/mmu.c                 | 22 +++++++++++++++++++---
 arch/arm64/kvm/vgic/vgic-v2.c        |  2 +-
 drivers/vfio/pci/vfio_pci.c          |  6 +++++-
 7 files changed, 39 insertions(+), 9 deletions(-)

-- 
2.17.1



From sdonthineni at nvidia.com  Thu Apr 29 17:29:05 2021
From: sdonthineni at nvidia.com (Shanker Donthineni)
Date: Thu, 29 Apr 2021 11:29:05 -0500
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR region
 in VMA
In-Reply-To: <20210429162906.32742-1-sdonthineni@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
Message-ID: <20210429162906.32742-2-sdonthineni@nvidia.com>

For pass-through device assignment, the ARM64 KVM hypervisor retrieves
the memory region properties physical address, size, and whether a
region backed with struct page or not from VMA. The prefetchable
attribute of a BAR region isn't visible to KVM to make an optimal
decision for stage2 attributes.

This patch updates vma->vm_page_prot and maps with write-combine
attribute if the associated BAR is prefetchable. For ARM64
pgprot_writecombine() is mapped to memory-type MT_NORMAL_NC which
has no side effects on reads and multiple writes can be combined.

Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
---
 drivers/vfio/pci/vfio_pci.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 5023e23db3bc..1b734fe1dd51 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1703,7 +1703,11 @@ static int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
 	}
 
 	vma->vm_private_data = vdev;
-	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+	if (IS_ENABLED(CONFIG_ARM64) &&
+	    (pci_resource_flags(pdev, index) & IORESOURCE_PREFETCH))
+		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+	else
+		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 	vma->vm_pgoff = (pci_resource_start(pdev, index) >> PAGE_SHIFT) + pgoff;
 
 	/*
-- 
2.17.1



From sdonthineni at nvidia.com  Thu Apr 29 17:29:06 2021
From: sdonthineni at nvidia.com (Shanker Donthineni)
Date: Thu, 29 Apr 2021 11:29:06 -0500
Subject: [RFC 2/2] KVM: arm64: Add write-combine support for stage-2 entries
In-Reply-To: <20210429162906.32742-1-sdonthineni@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
Message-ID: <20210429162906.32742-3-sdonthineni@nvidia.com>

In the current implementation, the device memory is always mapped as
DEVICE_nGnRE in stage-2. In the host kernel, device drivers have
flexibility whether to choose a memory-type device or write-combine
(Non-cacheable) depends on the use case. PCI specification has a
prefetchable BAR concept where multiple writes can be combined and
no side effects on reads. It provides huge performance improvement
and also allows unaligned access.

NVIDIA GPU PCIe devices have 3 BAR regions. Two regions are mapped to
video/compute memory and marked as prefetchable. The GPU driver takes
advantage of the write-combine feature for higher performance. The
same driver has no issues in the host kernel but crashes inside the
virtual machine because of unaligned accesses.

This patch finds the PTE attributes for device memory in VMA. It
updates the stage-2 attribute to NORMAL_NC for WC regions and
the default type DEVICE_nGnRE for non-WC regions.

Change-Id: Ibaea69c7a301df3c86609e871f6d066728391080
Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
---
 arch/arm64/include/asm/kvm_mmu.h     |  3 ++-
 arch/arm64/include/asm/kvm_pgtable.h |  2 ++
 arch/arm64/include/asm/memory.h      |  4 +++-
 arch/arm64/kvm/hyp/pgtable.c         |  9 +++++++--
 arch/arm64/kvm/mmu.c                 | 21 ++++++++++++++++++---
 arch/arm64/kvm/vgic/vgic-v2.c        |  2 +-
 6 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 90873851f677..dec498a6ba2f 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -160,7 +160,8 @@ void stage2_unmap_vm(struct kvm *kvm);
 int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu);
 void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu);
 int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
-			  phys_addr_t pa, unsigned long size, bool writable);
+			  phys_addr_t pa, unsigned long size, bool writable,
+			  bool writecombine);
 
 int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
index 8886d43cfb11..26f28220f6f3 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -35,6 +35,7 @@ struct kvm_pgtable {
  * @KVM_PGTABLE_PROT_W:		Write permission.
  * @KVM_PGTABLE_PROT_R:		Read permission.
  * @KVM_PGTABLE_PROT_DEVICE:	Device attributes.
+ * @KVM_PGTABLE_PROT_WC:	Normal non-cacheable (WC).
  */
 enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_X			= BIT(0),
@@ -42,6 +43,7 @@ enum kvm_pgtable_prot {
 	KVM_PGTABLE_PROT_R			= BIT(2),
 
 	KVM_PGTABLE_PROT_DEVICE			= BIT(3),
+	KVM_PGTABLE_PROT_WC			= BIT(4),
 };
 
 #define PAGE_HYP		(KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..04a812b59437 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -144,13 +144,15 @@
  * Memory types for Stage-2 translation
  */
 #define MT_S2_NORMAL		0xf
+#define MT_S2_WRITE_COMBINE	5
 #define MT_S2_DEVICE_nGnRE	0x1
 
 /*
  * Memory types for Stage-2 translation when ID_AA64MMFR2_EL1.FWB is 0001
- * Stage-2 enforces Normal-WB and Device-nGnRE
+ * Stage-2 enforces Normal-WB, Normal-NC and Device-nGnRE
  */
 #define MT_S2_FWB_NORMAL	6
+#define MT_S2_FWB_WRITE_COMBINE	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 926fc07074f5..bdfed559eae2 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -444,9 +444,14 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot prot,
 				    struct stage2_map_data *data)
 {
 	bool device = prot & KVM_PGTABLE_PROT_DEVICE;
-	kvm_pte_t attr = device ? PAGE_S2_MEMATTR(DEVICE_nGnRE) :
-			    PAGE_S2_MEMATTR(NORMAL);
 	u32 sh = KVM_PTE_LEAF_ATTR_LO_S2_SH_IS;
+	kvm_pte_t attr = PAGE_S2_MEMATTR(NORMAL);
+
+	if (device) {
+		attr = (prot & KVM_PGTABLE_PROT_WC) ?
+			PAGE_S2_MEMATTR(WRITE_COMBINE) :
+			PAGE_S2_MEMATTR(DEVICE_nGnRE);
+	}
 
 	if (!(prot & KVM_PGTABLE_PROT_X))
 		attr |= KVM_PTE_LEAF_ATTR_HI_S2_XN;
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 8711894db8c2..5b8ec1ab12e2 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -487,6 +487,16 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
 	}
 }
 
+/**
+ * is_vma_write_combine - check if VMA is mapped with writecombine or not
+ * Return true if VMA mapped with MT_NORMAL_NC otherwise fasle
+ */
+static bool inline is_vma_write_combine(struct vm_area_struct *vma)
+{
+	pteval_t pteval = pgprot_val(vma->vm_page_prot);
+	return ((pteval & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_NC));
+}
+
 /**
  * kvm_phys_addr_ioremap - map a device range to guest IPA
  *
@@ -495,9 +505,11 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
  * @pa:		The physical address of the device
  * @size:	The size of the mapping
  * @writable:   Whether or not to create a writable mapping
+ * @writecombine: Whether or not to create a writecombine mapping
  */
 int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
-			  phys_addr_t pa, unsigned long size, bool writable)
+			  phys_addr_t pa, unsigned long size, bool writable,
+			  bool writecombine)
 {
 	phys_addr_t addr;
 	int ret = 0;
@@ -505,6 +517,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
 	struct kvm_pgtable *pgt = kvm->arch.mmu.pgt;
 	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_DEVICE |
 				     KVM_PGTABLE_PROT_R |
+				     (writecombine ? KVM_PGTABLE_PROT_WC : 0) |
 				     (writable ? KVM_PGTABLE_PROT_W : 0);
 
 	size += offset_in_page(guest_ipa);
@@ -891,7 +904,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	}
 
 	if (device)
-		prot |= KVM_PGTABLE_PROT_DEVICE;
+		prot |= KVM_PGTABLE_PROT_DEVICE |
+			(is_vma_write_combine(vma) ? KVM_PGTABLE_PROT_WC : 0);
 	else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
 		prot |= KVM_PGTABLE_PROT_X;
 
@@ -1357,7 +1371,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
 
 			ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
 						    vm_end - vm_start,
-						    writable);
+						    writable,
+						    is_vma_write_combine(vma));
 			if (ret)
 				break;
 		}
diff --git a/arch/arm64/kvm/vgic/vgic-v2.c b/arch/arm64/kvm/vgic/vgic-v2.c
index 11934c2af2f4..6f921efea6c0 100644
--- a/arch/arm64/kvm/vgic/vgic-v2.c
+++ b/arch/arm64/kvm/vgic/vgic-v2.c
@@ -336,7 +336,7 @@ int vgic_v2_map_resources(struct kvm *kvm)
 	if (!static_branch_unlikely(&vgic_v2_cpuif_trap)) {
 		ret = kvm_phys_addr_ioremap(kvm, dist->vgic_cpu_base,
 					    kvm_vgic_global_state.vcpu_base,
-					    KVM_VGIC_V2_CPU_SIZE, true);
+					    KVM_VGIC_V2_CPU_SIZE, true, false);
 		if (ret) {
 			kvm_err("Unable to remap VGIC CPU to VCPU\n");
 			return ret;
-- 
2.17.1



From laurent.pinchart at ideasonboard.com  Thu Apr 29 17:53:33 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 29 Apr 2021 19:53:33 +0300
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210429104441.3e85d81b@coco.lan>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <20210429104441.3e85d81b@coco.lan>
Message-ID: <YIrkjcuF/+huMotl@pendragon.ideasonboard.com>

Hi Mauro,

On Thu, Apr 29, 2021 at 10:44:41AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu:
> > On 21-04-29 04:51, Laurent Pinchart wrote:
> > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:  
> > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > with the interleaved IR pixels looks like:
> > > > 
> > > >         |  G |  R |  G |  B | ...
> > > >         +----+----+----+----+---
> > > >         | IR |  G | IR |  G | ...
> > > >         +----+----+----+----+---
> > > >         |  G |  B |  G |  R | ...
> > > >         +----+----+----+----+---
> > > >         | IR |  G | IR |  G | ...
> > > >         +----+----+----+----+---
> > > >         | .. | .. | .. | .. | ..
> > > > 
> > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf  
> > > 
> > > I think we're reaching a limit of the media bus codes model here, due to
> > > a historical mistake. The four possible Bayer patterns, times the
> > > different number of bits per pixel, creates a lot of media bus codes,
> > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > have to support them all.  
> > 
> > That's correct but it is not bayer related.
> 
> Err... there are two separate things here:
> 
> 1) for the uAPI part, we're not even close to the limit of a 4-bytes
>    fourcc;
> 
> 2) the kAPI is currently sharing the same fourcc from the uAPI,
>    because it is a lot simpler than doing something different.

Please note that we're talking about media bus codes here, not pixel
formats. Both are part of the UAPI though, and pixel formats suffer from
a similar issue, but I'd like to focus on the media bus codes first.

> Yet, nothing prevents that the kAPI could be improved in order to
> better describe each format, provided that:
> 
> 1. there will be a 1:1 mapping with the uAPI.
>    In other words, it would be possible to write a function that
>    would convert a "struct foo" from/to a 32-bits fourcc;
> 
> 2. such new kAPI should be optional, as usually only drivers
>    for hardware with ISP (plus the UVC driver) would be flexible
>    enough to allow random formats. For the rest, the bridges are
>    typically limited to support only a few formats, so it doesn't
>    make sense to modify existing drivers to use such new kAPI.
> 
> Ok, someone has to come up with a proposal about what a "struct foo"
> would contain. On a real quick brainstorm, something like this could
> be a start:
> 
> enum v4l2_pixformat_type {
> 	VIDEO_PIXFORMAT_RGB,
> 	VIDEO_PIXFORMAT_YUV,
> 	VIDEO_PIXFORMAT_COMPRESSED,
> 	VIDEO_PIXFORMAT_BAYER_RGB,
> 	VIDEO_PIXFORMAT_BAYER_RGB_IR,
> };
> 
> struct v4l2_pixformat_desc {
> 	enum v4l2_pixformat_type	pixfmt_type;
> 	bool				is_packed;
> 	int				bits_per_component;
> 
> 	union {
> 		enum v4l2_pixformat_rgb_order		rgb_order;
> 		enum v4l2_pixformat_yuv_order		yuv_order;
> 		enum v4l2_pixformat_bayer_rgb_order	bayer_rgb_order;
> 		enum v4l2_pixformat_bayer_rgb_ir_order	bayer_rgb_ir_order;
> 		enum v4l2_pixformat_compress_type	compress_type;
> 	};
> 	...
> };
> 
> Btw, I remember someone suggested a model similar to that in the past,
> shared with DRM. Well, I don't think it would be easy to share
> an internal subsystem-specific kAPI like that with other subsystems,
> as this is the kind of thing that people will change from time to time,
> and coordinating something like that can be painful, but we can try
> to fork the model applied to DRM on media. For instance, I doubt that
> Bayer RGB + IR would make any sense for DRM drivers.

-- 
Regards,

Laurent Pinchart


From narmstrong at baylibre.com  Thu Apr 29 18:01:47 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 19:01:47 +0200
Subject: [PATCH] ASoC: meson: g12a-toacodec: add support for SM1 TOACODEC
Message-ID: <20210429170147.3615883-1-narmstrong@baylibre.com>

This adds support for the TOACODEC found in Amlogic SM1 SoCs.

The bits are shifted for more selection of clock sources, so this only
maps the same support for G12A to the SM1 bits.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 sound/soc/meson/g12a-toacodec.c | 126 +++++++++++++++++++++++++++++++-
 1 file changed, 124 insertions(+), 2 deletions(-)

diff --git a/sound/soc/meson/g12a-toacodec.c b/sound/soc/meson/g12a-toacodec.c
index 9339fabccb79..9c1c6b65baad 100644
--- a/sound/soc/meson/g12a-toacodec.c
+++ b/sound/soc/meson/g12a-toacodec.c
@@ -23,15 +23,27 @@
 #define  CTRL0_ENABLE_SHIFT		31
 #define  CTRL0_DAT_SEL_SHIFT		14
 #define  CTRL0_DAT_SEL			(0x3 << CTRL0_DAT_SEL_SHIFT)
+#define  CTRL0_DAT_SEL_SHIFT_SM1	18
+#define  CTRL0_DAT_SEL_SM1		(0x3 << CTRL0_DAT_SEL_SHIFT_SM1)
 #define  CTRL0_LANE_SEL			12
+#define  CTRL0_LANE_SEL_SM1		16
 #define  CTRL0_LRCLK_SEL		GENMASK(9, 8)
+#define  CTRL0_LRCLK_INV_SM1		BIT(10)
+#define  CTRL0_LRCLK_SEL_SM1		GENMASK(14, 12)
 #define  CTRL0_BLK_CAP_INV		BIT(7)
+#define  CTRL0_BLK_CAP_INV_SM1		BIT(9)
 #define  CTRL0_BCLK_O_INV		BIT(6)
+#define  CTRL0_BCLK_O_INV_SM1		BIT(8)
 #define  CTRL0_BCLK_SEL			GENMASK(5, 4)
+#define  CTRL0_BCLK_SEL_SM1		GENMASK(6, 4)
 #define  CTRL0_MCLK_SEL			GENMASK(2, 0)
 
 #define TOACODEC_OUT_CHMAX		2
 
+struct g12a_toacodec_match_data {
+	const struct snd_soc_component_driver *component_drv;
+};
+
 static const char * const g12a_toacodec_mux_texts[] = {
 	"I2S A", "I2S B", "I2S C",
 };
@@ -85,15 +97,73 @@ static int g12a_toacodec_mux_put_enum(struct snd_kcontrol *kcontrol,
 	return 0;
 }
 
+static int sm1_toacodec_mux_put_enum(struct snd_kcontrol *kcontrol,
+				     struct snd_ctl_elem_value *ucontrol)
+{
+	struct snd_soc_component *component =
+		snd_soc_dapm_kcontrol_component(kcontrol);
+	struct snd_soc_dapm_context *dapm =
+		snd_soc_dapm_kcontrol_dapm(kcontrol);
+	struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
+	unsigned int mux, changed;
+
+	mux = snd_soc_enum_item_to_val(e, ucontrol->value.enumerated.item[0]);
+	changed = snd_soc_component_test_bits(component, e->reg,
+					      CTRL0_DAT_SEL_SM1,
+					      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux));
+
+	if (!changed)
+		return 0;
+
+	/* Force disconnect of the mux while updating */
+	snd_soc_dapm_mux_update_power(dapm, kcontrol, 0, NULL, NULL);
+
+	snd_soc_component_update_bits(component, e->reg,
+				      CTRL0_DAT_SEL_SM1 |
+				      CTRL0_LRCLK_SEL_SM1 |
+				      CTRL0_BCLK_SEL_SM1,
+				      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux) |
+				      FIELD_PREP(CTRL0_LRCLK_SEL_SM1, mux) |
+				      FIELD_PREP(CTRL0_BCLK_SEL_SM1, mux));
+
+	/*
+	 * FIXME:
+	 * On this soc, the glue gets the MCLK directly from the clock
+	 * controller instead of going the through the TDM interface.
+	 *
+	 * Here we assume interface A uses clock A, etc ... While it is
+	 * true for now, it could be different. Instead the glue should
+	 * find out the clock used by the interface and select the same
+	 * source. For that, we will need regmap backed clock mux which
+	 * is a work in progress
+	 */
+	snd_soc_component_update_bits(component, e->reg,
+				      CTRL0_MCLK_SEL,
+				      FIELD_PREP(CTRL0_MCLK_SEL, mux));
+
+	snd_soc_dapm_mux_update_power(dapm, kcontrol, mux, e, NULL);
+
+	return 0;
+}
+
 static SOC_ENUM_SINGLE_DECL(g12a_toacodec_mux_enum, TOACODEC_CTRL0,
 			    CTRL0_DAT_SEL_SHIFT,
 			    g12a_toacodec_mux_texts);
 
+static SOC_ENUM_SINGLE_DECL(sm1_toacodec_mux_enum, TOACODEC_CTRL0,
+			    CTRL0_DAT_SEL_SHIFT_SM1,
+			    g12a_toacodec_mux_texts);
+
 static const struct snd_kcontrol_new g12a_toacodec_mux =
 	SOC_DAPM_ENUM_EXT("Source", g12a_toacodec_mux_enum,
 			  snd_soc_dapm_get_enum_double,
 			  g12a_toacodec_mux_put_enum);
 
+static const struct snd_kcontrol_new sm1_toacodec_mux =
+	SOC_DAPM_ENUM_EXT("Source", sm1_toacodec_mux_enum,
+			  snd_soc_dapm_get_enum_double,
+			  sm1_toacodec_mux_put_enum);
+
 static const struct snd_kcontrol_new g12a_toacodec_out_enable =
 	SOC_DAPM_SINGLE_AUTODISABLE("Switch", TOACODEC_CTRL0,
 				    CTRL0_ENABLE_SHIFT, 1, 0);
@@ -105,6 +175,13 @@ static const struct snd_soc_dapm_widget g12a_toacodec_widgets[] = {
 			    &g12a_toacodec_out_enable),
 };
 
+static const struct snd_soc_dapm_widget sm1_toacodec_widgets[] = {
+	SND_SOC_DAPM_MUX("SRC", SND_SOC_NOPM, 0, 0,
+			 &sm1_toacodec_mux),
+	SND_SOC_DAPM_SWITCH("OUT EN", SND_SOC_NOPM, 0, 0,
+			    &g12a_toacodec_out_enable),
+};
+
 static int g12a_toacodec_input_hw_params(struct snd_pcm_substream *substream,
 					 struct snd_pcm_hw_params *params,
 					 struct snd_soc_dai *dai)
@@ -175,6 +252,13 @@ static int g12a_toacodec_component_probe(struct snd_soc_component *c)
 				       CTRL0_BLK_CAP_INV);
 }
 
+static int sm1_toacodec_component_probe(struct snd_soc_component *c)
+{
+	/* Initialize the static clock parameters */
+	return snd_soc_component_write(c, TOACODEC_CTRL0,
+				       CTRL0_BLK_CAP_INV_SM1);
+}
+
 static const struct snd_soc_dapm_route g12a_toacodec_routes[] = {
 	{ "SRC", "I2S A", "IN A Playback" },
 	{ "SRC", "I2S B", "IN B Playback" },
@@ -187,6 +271,10 @@ static const struct snd_kcontrol_new g12a_toacodec_controls[] = {
 	SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL, 3, 0),
 };
 
+static const struct snd_kcontrol_new sm1_toacodec_controls[] = {
+	SOC_SINGLE("Lane Select", TOACODEC_CTRL0, CTRL0_LANE_SEL_SM1, 3, 0),
+};
+
 static const struct snd_soc_component_driver g12a_toacodec_component_drv = {
 	.probe			= g12a_toacodec_component_probe,
 	.controls		= g12a_toacodec_controls,
@@ -199,25 +287,59 @@ static const struct snd_soc_component_driver g12a_toacodec_component_drv = {
 	.non_legacy_dai_naming	= 1,
 };
 
+static const struct snd_soc_component_driver sm1_toacodec_component_drv = {
+	.probe			= sm1_toacodec_component_probe,
+	.controls		= sm1_toacodec_controls,
+	.num_controls		= ARRAY_SIZE(sm1_toacodec_controls),
+	.dapm_widgets		= sm1_toacodec_widgets,
+	.num_dapm_widgets	= ARRAY_SIZE(sm1_toacodec_widgets),
+	.dapm_routes		= g12a_toacodec_routes,
+	.num_dapm_routes	= ARRAY_SIZE(g12a_toacodec_routes),
+	.endianness		= 1,
+	.non_legacy_dai_naming	= 1,
+};
+
 static const struct regmap_config g12a_toacodec_regmap_cfg = {
 	.reg_bits	= 32,
 	.val_bits	= 32,
 	.reg_stride	= 4,
 };
 
+static const struct g12a_toacodec_match_data g12a_toacodec_match_data = {
+	.component_drv          = &g12a_toacodec_component_drv,
+};
+
+static const struct g12a_toacodec_match_data sm1_toacodec_match_data = {
+	.component_drv          = &sm1_toacodec_component_drv,
+};
+
 static const struct of_device_id g12a_toacodec_of_match[] = {
-	{ .compatible = "amlogic,g12a-toacodec", },
+	{
+		.compatible = "amlogic,g12a-toacodec",
+		.data = &g12a_toacodec_match_data,
+	},
+	{
+		.compatible = "amlogic,sm1-toacodec",
+		.data = &sm1_toacodec_match_data,
+	},
 	{}
 };
 MODULE_DEVICE_TABLE(of, g12a_toacodec_of_match);
 
 static int g12a_toacodec_probe(struct platform_device *pdev)
 {
+	const struct g12a_toacodec_match_data *data;
 	struct device *dev = &pdev->dev;
 	void __iomem *regs;
 	struct regmap *map;
 	int ret;
 
+	data = device_get_match_data(dev);
+	if (!data) {
+		dev_err(dev, "failed to match device\n");
+		return -ENODEV;
+	}
+
 	ret = device_reset(dev);
 	if (ret)
 		return ret;
@@ -234,7 +356,7 @@ static int g12a_toacodec_probe(struct platform_device *pdev)
 	}
 
 	return devm_snd_soc_register_component(dev,
-			&g12a_toacodec_component_drv, g12a_toacodec_dai_drv,
+			data->component_drv, g12a_toacodec_dai_drv,
 			ARRAY_SIZE(g12a_toacodec_dai_drv));
 }
 
-- 
2.25.1



From narmstrong at baylibre.com  Thu Apr 29 18:04:01 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 19:04:01 +0200
Subject: [PATCH 0/3] arm64: meson-sm1: add support for Banana PI BPI-M5
Message-ID: <20210429170404.3616111-1-narmstrong@baylibre.com>

Banana Pi BPI-M5 is a credit card format SBC with the following features:
- Amlogic S905X3 quad core Cortex-A55
- Mali-G31 GPU
- 4GB LPDDR4
- 16GB eMMC flash
- 4 USB 3.0
- 1 GbE ethernet
- HDMI output
- 2x LEDS
- SDCard
- 2.5mm Jack with Stereo Audio + CVBS
- Infrared Received
- ADC Button
- GPIO Button
- 40 pins header + 3pins debug header

This also adds the missing toacodec node to enable internal audio codec.

Neil Armstrong (3):
  arm64: dts: meson-sm1: add toacodec node
  dt-bindings: arm: amlogic: add Banana PI M5 bindings
  arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts

 .../devicetree/bindings/arm/amlogic.yaml      |   1 +
 arch/arm64/boot/dts/amlogic/Makefile          |   1 +
 .../dts/amlogic/meson-sm1-bananapi-m5.dts     | 606 ++++++++++++++++++
 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi    |  11 +
 4 files changed, 619 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts

-- 
2.25.1



From narmstrong at baylibre.com  Thu Apr 29 18:04:02 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 19:04:02 +0200
Subject: [PATCH 1/3] arm64: dts: meson-sm1: add toacodec node
In-Reply-To: <20210429170404.3616111-1-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
Message-ID: <20210429170404.3616111-2-narmstrong@baylibre.com>

Add toacodec node for Amlogic SM1 SoCs.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index c309517abae3..2d3a81a188a9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -401,6 +401,17 @@ tdmout_c: audio-controller at 580 {
 			status = "disabled";
 		};
 
+
+		toacodec: audio-controller at 740 {
+			compatible = "amlogic,sm1-toacodec",
+				     "amlogic,g12a-tohdmitx";
+			reg = <0x0 0x740 0x0 0x4>;
+			#sound-dai-cells = <1>;
+			sound-name-prefix = "TOACODEC";
+			resets = <&clkc_audio AUD_RESET_TOACODEC>;
+			status = "disabled";
+		};
+
 		tohdmitx: audio-controller at 744 {
 			compatible = "amlogic,sm1-tohdmitx",
 				     "amlogic,g12a-tohdmitx";
-- 
2.25.1



From narmstrong at baylibre.com  Thu Apr 29 18:04:04 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 19:04:04 +0200
Subject: [PATCH 3/3] arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts
In-Reply-To: <20210429170404.3616111-1-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
Message-ID: <20210429170404.3616111-4-narmstrong@baylibre.com>

Banana Pi BPI-M5 is a credit card format SBC with the following features:
- Amlogic S905X3 quad core Cortex-A55
- Mali-G31 GPU
- 4GB LPDDR4
- 16GB eMMC flash
- 4 USB 3.0
- 1 GbE ethernet
- HDMI output
- 2x LEDS
- SDCard
- 2.5mm Jack with Stereo Audio + CVBS
- Infrared Received
- ADC Button
- GPIO Button
- 40 pins header + 3pins debug header

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 arch/arm64/boot/dts/amlogic/Makefile          |   1 +
 .../dts/amlogic/meson-sm1-bananapi-m5.dts     | 606 ++++++++++++++++++
 2 files changed, 607 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts

diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 78a569d7fa20..3cf6699b4f30 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -45,6 +45,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-libretech-pc.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m5.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
new file mode 100644
index 000000000000..e5fc9d320577
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 BayLibre SAS
+ * Author: Neil Armstrong <narmstrong at baylibre.com>
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+#include <dt-bindings/sound/meson-g12a-toacodec.h>
+#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
+
+/ {
+	compatible = "bananapi,bpi-m5", "amlogic,sm1";
+	model = "Banana Pi BPI-M5";
+
+	adc_keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 2>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+
+		button-onoff {
+			label = "SW3";
+			linux,code = <BTN_3>;
+			press-threshold-microvolt = <1700000>;
+		};
+	};
+
+	aliases {
+		serial0 = &uart_AO;
+		ethernet0 = &ethmac;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* TOFIX: handle CVBS_DET on SARADC channel 0 */
+	cvbs-connector {
+		compatible = "composite-video-connector";
+
+		port {
+			cvbs_connector_in: endpoint {
+				remote-endpoint = <&cvbs_vdac_out>;
+			};
+		};
+	};
+
+	emmc_pwrseq: emmc-pwrseq {
+		compatible = "mmc-pwrseq-emmc";
+		reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key {
+			label = "SW1";
+			linux,code = <BTN_1>;
+			gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
+			interrupt-parent = <&gpio_intc>;
+			interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
+		};
+	};
+
+	hdmi-connector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_connector_in: endpoint {
+				remote-endpoint = <&hdmi_tx_tmds_out>;
+			};
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		green {
+			color = <LED_COLOR_ID_GREEN>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+		};
+
+		blue {
+			color = <LED_COLOR_ID_BLUE>;
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio_ao GPIOAO_11 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	memory at 0 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x40000000>;
+	};
+
+	flash_1v8: regulator-flash_1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "FLASH_1V8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vddao_3v3>;
+		regulator-always-on;
+	};
+
+	dc_in: regulator-dc_in {
+		compatible = "regulator-fixed";
+		regulator-name = "5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+
+	vddio_c: regulator-vddio_c {
+		compatible = "regulator-gpio";
+		regulator-name = "VDDIO_C";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+
+		enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+
+		gpios = <&gpio_ao GPIOAO_6 GPIO_OPEN_DRAIN>;
+		gpios-states = <1>;
+
+		states = <1800000 0>,
+			 <3300000 1>;
+	};
+
+	tflash_vdd: regulator-tflash_vdd {
+		compatible = "regulator-fixed";
+		regulator-name = "TFLASH_VDD";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_in>;
+		gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	vddao_1v8: regulator-vddao_1v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDDAO_1V8";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vddao_3v3>;
+		regulator-always-on;
+	};
+
+	vddao_3v3: regulator-vddao_3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VDDAO_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&dc_in>;
+		regulator-always-on;
+	};
+
+	vddcpu: regulator-vddcpu {
+		/*
+		 * SY8120B1ABC DC/DC Regulator.
+		 */
+		compatible = "pwm-regulator";
+
+		regulator-name = "VDDCPU";
+		regulator-min-microvolt = <721000>;
+		regulator-max-microvolt = <1022000>;
+
+		vin-supply = <&dc_in>;
+
+		pwms = <&pwm_AO_cd 1 1250 0>;
+		pwm-dutycycle-range = <100 0>;
+
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	/* USB Hub Power Enable */
+	vl_pwr_en: regulator-vl_pwr_en {
+		compatible = "regulator-fixed";
+		regulator-name = "VL_PWR_EN";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_in>;
+
+		gpio = <&gpio GPIOH_6 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	sound {
+		compatible = "amlogic,axg-sound-card";
+		model = "BPI-M5";
+		audio-widgets = "Line", "Lineout";
+		audio-aux-devs = <&tdmout_b>, <&tdmout_c>,
+				 <&tdmin_a>, <&tdmin_b>, <&tdmin_c>;
+		audio-routing = "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+				"TDMOUT_B IN 1", "FRDDR_B OUT 1",
+				"TDMOUT_B IN 2", "FRDDR_C OUT 1",
+				"TDM_B Playback", "TDMOUT_B OUT",
+				"TDMOUT_C IN 0", "FRDDR_A OUT 2",
+				"TDMOUT_C IN 1", "FRDDR_B OUT 2",
+				"TDMOUT_C IN 2", "FRDDR_C OUT 2",
+				"TDM_C Playback", "TDMOUT_C OUT",
+				"TDMIN_A IN 4", "TDM_B Loopback",
+				"TDMIN_B IN 4", "TDM_B Loopback",
+				"TDMIN_C IN 4", "TDM_B Loopback",
+				"TDMIN_A IN 5", "TDM_C Loopback",
+				"TDMIN_B IN 5", "TDM_C Loopback",
+				"TDMIN_C IN 5", "TDM_C Loopback",
+				"TODDR_A IN 0", "TDMIN_A OUT",
+				"TODDR_B IN 0", "TDMIN_A OUT",
+				"TODDR_C IN 0", "TDMIN_A OUT",
+				"TODDR_A IN 1", "TDMIN_B OUT",
+				"TODDR_B IN 1", "TDMIN_B OUT",
+				"TODDR_C IN 1", "TDMIN_B OUT",
+				"TODDR_A IN 2", "TDMIN_C OUT",
+				"TODDR_B IN 2", "TDMIN_C OUT",
+				"TODDR_C IN 2", "TDMIN_C OUT",
+				"Lineout", "ACODEC LOLP",
+				"Lineout", "ACODEC LORP";
+
+		assigned-clocks = <&clkc CLKID_MPLL2>,
+				  <&clkc CLKID_MPLL0>,
+				  <&clkc CLKID_MPLL1>;
+		assigned-clock-parents = <0>, <0>, <0>;
+		assigned-clock-rates = <294912000>,
+				       <270950400>,
+				       <393216000>;
+		status = "okay";
+
+		dai-link-0 {
+			sound-dai = <&frddr_a>;
+		};
+
+		dai-link-1 {
+			sound-dai = <&frddr_b>;
+		};
+
+		dai-link-2 {
+			sound-dai = <&frddr_c>;
+		};
+
+		dai-link-3 {
+			sound-dai = <&toddr_a>;
+		};
+
+		dai-link-4 {
+			sound-dai = <&toddr_b>;
+		};
+
+		dai-link-5 {
+			sound-dai = <&toddr_c>;
+		};
+
+		/* 8ch hdmi interface */
+		dai-link-6 {
+			sound-dai = <&tdmif_b>;
+			dai-format = "i2s";
+			dai-tdm-slot-tx-mask-0 = <1 1>;
+			dai-tdm-slot-tx-mask-1 = <1 1>;
+			dai-tdm-slot-tx-mask-2 = <1 1>;
+			dai-tdm-slot-tx-mask-3 = <1 1>;
+			mclk-fs = <256>;
+
+			codec-0 {
+				sound-dai = <&tohdmitx TOHDMITX_I2S_IN_B>;
+			};
+
+			codec-1 {
+				sound-dai = <&toacodec TOACODEC_IN_B>;
+			};
+		};
+
+		/* i2s jack output interface */
+		dai-link-7 {
+			sound-dai = <&tdmif_c>;
+			dai-format = "i2s";
+			dai-tdm-slot-tx-mask-0 = <1 1>;
+			mclk-fs = <256>;
+
+			codec-0 {
+				sound-dai = <&tohdmitx TOHDMITX_I2S_IN_C>;
+			};
+
+			codec-1 {
+				sound-dai = <&toacodec TOACODEC_IN_C>;
+			};
+		};
+
+		/* hdmi glue */
+		dai-link-8 {
+			sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
+
+			codec {
+				sound-dai = <&hdmi_tx>;
+			};
+		};
+
+		/* acodec glue */
+		dai-link-9 {
+			sound-dai = <&toacodec TOACODEC_OUT>;
+
+			codec {
+				sound-dai = <&acodec>;
+			};
+		};
+	};
+};
+
+&acodec {
+	AVDD-supply = <&vddao_1v8>;
+	status = "okay";
+};
+
+&arb {
+	status = "okay";
+};
+
+&clkc_audio {
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&vddcpu>;
+	operating-points-v2 = <&cpu_opp_table>;
+	clocks = <&clkc CLKID_CPU_CLK>;
+	clock-latency = <50000>;
+};
+
+&cpu1 {
+	cpu-supply = <&vddcpu>;
+	operating-points-v2 = <&cpu_opp_table>;
+	clocks = <&clkc CLKID_CPU1_CLK>;
+	clock-latency = <50000>;
+};
+
+&cpu2 {
+	cpu-supply = <&vddcpu>;
+	operating-points-v2 = <&cpu_opp_table>;
+	clocks = <&clkc CLKID_CPU2_CLK>;
+	clock-latency = <50000>;
+};
+
+&cpu3 {
+	cpu-supply = <&vddcpu>;
+	operating-points-v2 = <&cpu_opp_table>;
+	clocks = <&clkc CLKID_CPU3_CLK>;
+	clock-latency = <50000>;
+};
+
+&cvbs_vdac_port {
+	cvbs_vdac_out: endpoint {
+		remote-endpoint = <&cvbs_connector_in>;
+	};
+};
+
+&ext_mdio {
+	external_phy: ethernet-phy at 0 {
+		/* Realtek RTL8211F (0x001cc916) */
+		reg = <0>;
+		max-speed = <1000>;
+
+		interrupt-parent = <&gpio_intc>;
+		/* MAC_INTR on GPIOZ_14 */
+		interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&ethmac {
+	pinctrl-0 = <&eth_pins>, <&eth_rgmii_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+	phy-mode = "rgmii";
+	phy-handle = <&external_phy>;
+	amlogic,tx-delay-ns = <2>;
+};
+
+&frddr_a {
+	status = "okay";
+};
+
+&frddr_b {
+	status = "okay";
+};
+
+&frddr_c {
+	status = "okay";
+};
+
+&gpio {
+	gpio-line-names =
+		/* GPIOZ */
+		"", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "",
+		/* GPIOH */
+		"", "", "", "", "",
+		"CON1-P36", /* GPIOH_5 */
+		"", "", "",
+		/* BOOT */
+		"", "", "", "", "", "", "", "",
+		"", "", "", "", "", "", "", "",
+		/* GPIOC */
+		"", "", "", "", "", "", "", "",
+		/* GPIOA */
+		"", "", "", "", "", "", "", "",
+		"", "", "", "", "", "",
+		"CON1-P27", /* GPIOA_14 */
+		"CON1-P28", /* GPIOA_15 */
+		/* GPIOX */
+		"CON1-P16", /* GPIOX_0 */
+		"CON1-P18", /* GPIOX_1 */
+		"CON1-P22", /* GPIOX_2 */
+		"CON1-P11", /* GPIOX_3 */
+		"CON1-P13", /* GPIOX_4 */
+		"CON1-P07", /* GPIOX_5 */
+		"CON1-P33", /* GPIOX_6 */
+		"CON1-P15", /* GPIOX_7 */
+		"CON1-P19", /* GPIOX_8 */
+		"CON1-P21", /* GPIOX_9 */
+		"CON1-P24", /* GPIOX_10 */
+		"CON1-P23", /* GPIOX_11 */
+		"CON1-P08", /* GPIOX_12 */
+		"CON1-P10", /* GPIOX_13 */
+		"CON1-P29", /* GPIOX_14 */
+		"CON1-P31", /* GPIOX_15 */
+		"CON1-P26", /* GPIOX_16 */
+		"CON1-P03", /* GPIOX_17 */
+		"CON1-P05", /* GPIOX_18 */
+		"CON1-P32"; /* GPIOX_19 */
+
+	/*
+	 * WARNING: The USB Hub on the BPI-M54 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 {
+		gpio-hog;
+		gpios = <GPIOH_4 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "usb-hub-reset";
+	};
+};
+
+&gpio_ao {
+	gpio-line-names =
+		/* GPIOAO */
+		"DEBUG TX", /* GPIOAO_0 */
+		"DEBUG RX", /* GPIOAO_1 */
+		"SYS_LED2", /* GPIOAO_2 */
+		"UPDATE_KEY", /* GPIOAO_3 */
+		"CON1-P40", /* GPIOAO_4 */
+		"",
+		"TF_3V3N_1V8_EN", /* GPIOAO_6 */
+		"CON1-P35", /* GPIOAO_7 */
+		"CON1-P12", /* GPIOAO_8 */
+		"CON1-P37", /* GPIOAO_9 */
+		"CON1-P38", /* GPIOAO_10 */
+		"SYS_LED", /* GPIOAO_11 */
+		/* GPIOE */
+		"", "", "";
+};
+
+&hdmi_tx {
+	status = "okay";
+	pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
+	pinctrl-names = "default";
+	hdmi-supply = <&dc_in>;
+};
+
+&hdmi_tx_tmds_port {
+	hdmi_tx_tmds_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
+
+&ir {
+	status = "okay";
+	pinctrl-0 = <&remote_input_ao_pins>;
+	pinctrl-names = "default";
+};
+
+&pwm_AO_cd {
+	pinctrl-0 = <&pwm_ao_d_e_pins>;
+	pinctrl-names = "default";
+	clocks = <&xtal>;
+	clock-names = "clkin1";
+	status = "okay";
+};
+
+&saradc {
+	status = "okay";
+	vref-supply = <&vddao_1v8>;
+};
+
+/* SD card */
+&sd_emmc_b {
+	status = "okay";
+	pinctrl-0 = <&sdcard_c_pins>;
+	pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+	pinctrl-names = "default", "clk-gate";
+
+	bus-width = <4>;
+	cap-sd-highspeed;
+	max-frequency = <50000000>;
+	disable-wp;
+
+	/* TOFIX: SD card is barely usable in SDR modes */
+
+	cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&tflash_vdd>;
+	vqmmc-supply = <&vddio_c>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+	status = "okay";
+	pinctrl-0 = <&emmc_ctrl_pins>, <&emmc_data_8b_pins>, <&emmc_ds_pins>;
+	pinctrl-1 = <&emmc_clk_gate_pins>;
+	pinctrl-names = "default", "clk-gate";
+
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-ddr-1_8v;
+	mmc-hs200-1_8v;
+	max-frequency = <200000000>;
+	disable-wp;
+
+	mmc-pwrseq = <&emmc_pwrseq>;
+	vmmc-supply = <&vddao_3v3>;
+	vqmmc-supply = <&flash_1v8>;
+};
+
+&tdmif_b {
+	status = "okay";
+};
+
+&tdmif_c {
+	status = "okay";
+};
+
+&tdmin_a {
+	status = "okay";
+};
+
+&tdmin_b {
+	status = "okay";
+};
+
+&tdmin_c {
+	status = "okay";
+};
+
+&tdmout_b {
+	status = "okay";
+};
+
+&tdmout_c {
+	status = "okay";
+};
+
+&toacodec {
+	status = "okay";
+};
+
+&tohdmitx {
+	status = "okay";
+};
+
+&toddr_a {
+	status = "okay";
+};
+
+&toddr_b {
+	status = "okay";
+};
+
+&toddr_c {
+	status = "okay";
+};
+
+&uart_AO {
+	status = "okay";
+	pinctrl-0 = <&uart_ao_a_pins>;
+	pinctrl-names = "default";
+};
+
+&usb {
+	status = "okay";
+};
+
+&usb2_phy0 {
+	phy-supply = <&dc_in>;
+};
+
+&usb2_phy1 {
+	/* Enable the hub which is connected to this port */
+	phy-supply = <&vl_pwr_en>;
+};
-- 
2.25.1



From narmstrong at baylibre.com  Thu Apr 29 18:04:03 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Thu, 29 Apr 2021 19:04:03 +0200
Subject: [PATCH 2/3] dt-bindings: arm: amlogic: add Banana PI M5 bindings
In-Reply-To: <20210429170404.3616111-1-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
Message-ID: <20210429170404.3616111-3-narmstrong@baylibre.com>

Add bindings for the Banana PI M5 board.

Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 5f6769bf45bd..4eaf400c3522 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -164,6 +164,7 @@ properties:
       - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
         items:
           - enum:
+	      - bananapi,bpi-m5
               - hardkernel,odroid-c4
               - hardkernel,odroid-hc4
               - khadas,vim3l
-- 
2.25.1



From broonie at kernel.org  Thu Apr 29 18:15:49 2021
From: broonie at kernel.org (Mark Brown)
Date: Thu, 29 Apr 2021 18:15:49 +0100
Subject: [PATCH 0/2]spi: spi-zynq-qspi: Fix stack violation bug
In-Reply-To: <20210318102446.25142-1-amit.kumar-mahapatra@xilinx.com>
References: <20210318102446.25142-1-amit.kumar-mahapatra@xilinx.com>
Message-ID: <161970928183.41765.11956133765398420405.b4-ty@kernel.org>

On Thu, 18 Mar 2021 04:24:44 -0600, Amit Kumar Mahapatra wrote:
> This patch series fixes kernel-doc warnings and stack violation
> issues in Zynq qspi driver file

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/2] spi: spi-zynq-qspi: Fix kernel-doc warning
      commit: 121271f08809e5dc01d15d3e529988ac5d740af6
[2/2] spi: spi-zynq-qspi: Fix stack violation bug
      commit: 6d5ff8e632a4f2389c331e5554cd1c2a9a28c7aa

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 suzuki.poulose at arm.com  Thu Apr 29 18:37:38 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 29 Apr 2021 18:37:38 +0100
Subject: [PATCH] [v2] coresight: etm4x: avoid build failure with unrolled
 loops
In-Reply-To: <20210429145752.3218324-1-arnd@kernel.org>
References: <20210429145752.3218324-1-arnd@kernel.org>
Message-ID: <dff8cbd8-8c56-ae6e-ecc2-9ca183113ab2@arm.com>

Hi Arnd

On 29/04/2021 15:57, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd at arndb.de>
> 
> clang-12 fails to build the etm4x driver with -fsanitize=array-bounds,
> where it decides to unroll certain loops in a way that result in a
> C variable getting put into an inline assembly
> 
> <instantiation>:1:7: error: expected constant expression in '.inst' directive
> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
>        ^
> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
>                          etm4x_relaxed_read32(csa, TRCCNTVRn(i));
>                          ^
> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
>                   read_etm4x_sysreg_offset((offset), false)))
>                   ^
> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
>                          __val = read_etm4x_sysreg_const_offset((offset));       \
>                                  ^
> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
>          READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
>          ^
> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
>          read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
>          ^
> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
>          asm volatile(__mrs_s("%0", r) : "=r" (__val));                  \
>                       ^
> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> "       mrs_s " v ", " __stringify(r) "\n"                      \
>   ^
> 
> This only happened in a few loops in which the array bounds sanitizer
> added a special case for an array overflow that clang determined to be
> possible, but any compiler is free to unroll any of the loops in the
> same way that breaks the sysreg macros.
> 
> Introduce helper functions that perform a sysreg access with a
> non-constant register number and use them in each call that passes
> a loop counter.

You don't need to add this special helper. We have the exact 
infrastructure already. So these could simply be replaced with:

csdev_access_xxx(csa, ...)

see :

include/linux/coresight.h

Cheers
Suzuki


From reinette.chatre at intel.com  Thu Apr 29 18:42:19 2021
From: reinette.chatre at intel.com (Reinette Chatre)
Date: Thu, 29 Apr 2021 10:42:19 -0700
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <OSAPR01MB2146D42FC04779268BA231878B409@OSAPR01MB2146.jpnprd01.prod.outlook.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
 <OSAPR01MB2146D42FC04779268BA231878B409@OSAPR01MB2146.jpnprd01.prod.outlook.com>
Message-ID: <14ddf86b-89e1-ba26-b684-f3d5d5f8ade7@intel.com>

Hi Tan Shaopeng,

On 4/28/2021 1:16 AM, tan.shaopeng at fujitsu.com wrote:
> Hi Reinette,
> 
>> On 4/21/2021 1:37 AM, tan.shaopeng at fujitsu.com wrote:
>>> Hi,
>>>
>>> Ping... any comments&advice about add an A64FX cache control function
>> into resctrl?
>>
>> My apologies for the delay.
>>
>>>
>>> Best regards
>>> Tan Shaopeng
>>>
>>>> Hello
>>>>
>>>>
>>>> I'm Tan Shaopeng from Fujitsu Limited.
>>>>
>>>> I?m trying to implement Fujitsu A64FX?s cache related features.
>>>> It is a cache partitioning function we called sector cache function
>>>> that using the value of the tag that is upper 8 bits of the 64bit
>>>> address and the value of the sector cache register to control virtual cache
>> capacity of the L1D&L2 cache.
>>>>
>>>> A few days ago, when I sent a driver that realizes this function to
>>>> ARM64 kernel community, Will Deacon and Arnd Bergmann suggested an
>>>> idea to add the sector cache function of A64FX into resctrl.
>>>>
>> https://lore.kernel.org/linux-arm-kernel/CAK8P3a2pFcNTw9NpRtQfYr7A5Oc
>>>> Z=As2kM0D_sbfFcGQ_J2Q+Q at mail.gmail.com/
>>>>
>>>> Based on my study, I think the sector cache function of A64FX can be
>>>> added into the allocation features of resctrl after James' resctrl rework has
>> finished.
>>>> But, in order to implement this function, more interfaces for resctrl are
>> need.
>>>> The details are as follow, and could you give me some advice?
>>>>
>>>> [Sector cache function]
>>>> The sector cache function split cache into multiple sectors and
>>>> control them separately. It is implemented on the L1D cache and
>>>> L2 cache in the A64FX processor and can be controlled individually
>>>> for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache and
>>>> L2 cache has 4 sectors. Which L1D sector is used is specified by the
>>>> value of [57:56] bits of address, how many ways of sector are
>>>> specified by the value of register (IMP_SCCR_L1_EL0).
>>>> Which L2 sector is used is specified by the value of [56] bits of
>>>> address, and how many ways of sector are specified by value of
>>>> register (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
>>>> IMP_SCCR_SET1_L2_EL1).
>>>>
>>>> For more details of sector cache function, see A64FX HPC extension
>>>> specification (1.2. Sector cache) in https://github.com/fujitsu/A64FX
>>
>> The overview in section 12 was informative but very high level.
> 
> I'm considering how to answer your questions from your email which
> I received before, when I check the email again, I am sorry that
> the information I provided before are insufficient.
> 
> To understand the sector cache function of A64FX, could you please see
> A64FX_Microarchitecture_Manual - section 12. Sector Cache
> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.4.pdf
> and,
> A64FX_Specification_HPC_Extension ? section 1.2. Sector Cache
> https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Specification_HPC_Extension_v1_EN.pdf

Thank you for the direct links - I missed that there are two documents  
available.

After reading the spec portion it does seem to me even more as though  
"sectors" could be considered the same as the resctrl "classes of  
service". The Fujitsu hardware supports four sectors that can be  
configured with different number of ways using the registers you mention  
above. In resctrl this could be considered as hardware that supports  
four classes of service and each class of service can be allocated a  
different number of ways.

The other part is how hardware knows which sector is being used at any  
moment in time. In resctrl that is programmed by writing the active  
class of service into needed register at the time the application is  
context switched (resctrl_sched_in()). This seems different here since  
as you describe the sector is chosen by bits in the address. Even so,  
which bits to set in the address needs to be programmed also and I also  
understand that there is a "default" sector that can be programmed via  
register. Could these be equivalent to what is done currently in resctrl?

(Could you please also consider my original questions?)

> 
> In addition, Japan will be on a long holiday about one week from
> April 29th, I will answer your other questions after the holidays.
> 
>> I was not able to find any instance of "IMP_SCCR" in this document to explore
>> how this cache allocation works.
>>
>> Are these cache sectors exposed to the OS in any way? For example, when the
>> OS discovers the cache, does it learn about these sectors and expose the
>> details to user space (/sys/devices/system/cpuX/cache)?
>>
>> The overview of Sector Cache in that document provides details of how the size
>> of the sector itself is dynamically adjusted to usage. That description is quite
>> cryptic but it seems like a sector, since the number of ways associated with it
>> can dynamically change, is more equivalent to a class of service or resource
>> group in the resctrl environment.
>>
>> I really may be interpreting things wrong here, could you perhaps point me to
>> where I can obtain more details?
>>
>>
>>>> [Difference between resctrl(CAT) and this sector cache function]
>>>> L2/L3 CAT (Cache Allocation Technology) enables the user to specify
>>>> some physical partition of cache space that an application can fill.
>>>> A64FX's L1D/L2 cache has 4 sectors and 16ways. This sector function
>>>> enables a user to specify number of ways each sector uses.
>>>> Therefore, for CAT it is enough to specify a cache portion for each
>>>> cache_id (socket). On the other hand, sector cache needs to specify
>>>> cache portion of each sector for each cache_id, and following
>>>> extension to resctrl interface is needed to support sector cache.
>>>>
>>>> [Idear for A64FX sector cache function control interface (schemata
>>>> file details)]
>>>>
>> L1:<cache_id0>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=<cw
>>>> bm>,<cwbm>,<cwbm>,<cwbm>;?
>>>>
>> L2:<cache_id0>=>=<cwbm>,<cwbm>,<cwbm>,<cwbm>;<cache_id1>=
>>>> <cwbm>,<cwbm>,<cwbm>,<cwbm>;?
>>>>
>>>> ?L1: Add a new interface to control the L1D cache.
>>>> ?<cwbm>,<cwbm>,<cwbm>,<cwbm>?Specify the number of ways for
>> each
>>>> sector.
>>>> ?cwbm?Specify the number of ways in each sector as a bitmap
>> (percentage),
>>>>     but the bitmap does not indicate the location of the cache.
>>>> * In the sector cache function, L2 sector cache way setting register is
>>>>     shared among PEs (Processor Element) in shared domain. If two PEs
>>>>     which share L2 cache belongs to different resource groups, one
>> resource
>>>>     group's L2 setting will affect to other resource group's L2 setting.
>>
>> In resctrl a "resource group" can be viewed as a class of service.
>>
>>>> * Since A64FX does not support MPAM, it is not necessary to consider
>>>>     how to switch between MPAM and sector cache function now.
>>>>
>>>> Some questions:
>>>> 1.I'm still studying about RDT, could you tell me whether RDT has
>>>>     the similar mechanism with sector cache function?
>>
>> This is not clear to me yet. One thing to keep in mind is that a bit in the capacity
>> bitmask could correspond to some number of ways in a cache, but it does not
>> have to. It is essentially a hint to hardware on how much cache space needs to
>> be allocated while also indicating overlap and isolation from other allocations.
>>
>> resctrl already supports the bitmask being interpreted differently between
>> architectures and with the MPAM support there will be even more support for
>> different interpretations.
>>
>>>> 2.In RDT, L3 cache is shared among cores in socket. If two cores which
>>>>     share L3 cache belongs to different resource groups, one resource
>>>>     group's L3 setting will affect to other resource group's L3 setting?
>>
>> This question is not entirely clear to me. Are you referring to the hardware layout
>> or configuration changes via the resctrl "cpus" file?
>>
>> Each resource group is a class of service (CLOS) that is supported by all cache
>> instances. By default each resource group would thus contain all cache
>> instances on the system (even if some cache instances do not support the
>> same number of CLOS resctrl would only support the CLOS supported by all
>> resources).
> 

Reinette


From jbrunet at baylibre.com  Thu Apr 29 18:43:06 2021
From: jbrunet at baylibre.com (Jerome Brunet)
Date: Thu, 29 Apr 2021 19:43:06 +0200
Subject: [PATCH] ASoC: meson: g12a-toacodec: add support for SM1 TOACODEC
In-Reply-To: <20210429170147.3615883-1-narmstrong@baylibre.com>
References: <20210429170147.3615883-1-narmstrong@baylibre.com>
Message-ID: <1jo8dx9ec5.fsf@starbuckisacylon.baylibre.com>


On Thu 29 Apr 2021 at 19:01, Neil Armstrong <narmstrong at baylibre.com> wrote:


>  
> +static int sm1_toacodec_mux_put_enum(struct snd_kcontrol *kcontrol,
> +				     struct snd_ctl_elem_value *ucontrol)
> +{
> +	struct snd_soc_component *component =
> +		snd_soc_dapm_kcontrol_component(kcontrol);
> +	struct snd_soc_dapm_context *dapm =
> +		snd_soc_dapm_kcontrol_dapm(kcontrol);
> +	struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
> +	unsigned int mux, changed;
> +
> +	mux = snd_soc_enum_item_to_val(e, ucontrol->value.enumerated.item[0]);
> +	changed = snd_soc_component_test_bits(component, e->reg,
> +					      CTRL0_DAT_SEL_SM1,
> +					      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux));
> +
> +	if (!changed)
> +		return 0;
> +
> +	/* Force disconnect of the mux while updating */
> +	snd_soc_dapm_mux_update_power(dapm, kcontrol, 0, NULL, NULL);
> +
> +	snd_soc_component_update_bits(component, e->reg,
> +				      CTRL0_DAT_SEL_SM1 |
> +				      CTRL0_LRCLK_SEL_SM1 |
> +				      CTRL0_BCLK_SEL_SM1,
> +				      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux) |
> +				      FIELD_PREP(CTRL0_LRCLK_SEL_SM1, mux) |
> +				      FIELD_PREP(CTRL0_BCLK_SEL_SM1, mux));
> +
> +	/*
> +	 * FIXME:
> +	 * On this soc, the glue gets the MCLK directly from the clock
> +	 * controller instead of going the through the TDM interface.
> +	 *
> +	 * Here we assume interface A uses clock A, etc ... While it is
> +	 * true for now, it could be different. Instead the glue should
> +	 * find out the clock used by the interface and select the same
> +	 * source. For that, we will need regmap backed clock mux which
> +	 * is a work in progress
> +	 */
> +	snd_soc_component_update_bits(component, e->reg,
> +				      CTRL0_MCLK_SEL,
> +				      FIELD_PREP(CTRL0_MCLK_SEL, mux));
> +
> +	snd_soc_dapm_mux_update_power(dapm, kcontrol, mux, e, NULL);
> +
> +	return 0;
> +}

Instead of duplicating this function, I'd prefer if you could use regmap fields




From tony.luck at intel.com  Thu Apr 29 18:50:20 2021
From: tony.luck at intel.com (Luck, Tony)
Date: Thu, 29 Apr 2021 17:50:20 +0000
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <14ddf86b-89e1-ba26-b684-f3d5d5f8ade7@intel.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
 <OSAPR01MB2146D42FC04779268BA231878B409@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <14ddf86b-89e1-ba26-b684-f3d5d5f8ade7@intel.com>
Message-ID: <49cdd0b707194148915e2efe2ab5d707@intel.com>

>>>> [Sector cache function]
>>>> The sector cache function split cache into multiple sectors and
>>>> control them separately. It is implemented on the L1D cache and
>>>> L2 cache in the A64FX processor and can be controlled individually
>>>> for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache and
>>>> L2 cache has 4 sectors. Which L1D sector is used is specified by the
>>>> value of [57:56] bits of address, how many ways of sector are
>>>> specified by the value of register (IMP_SCCR_L1_EL0).
>>>> Which L2 sector is used is specified by the value of [56] bits of
>>>> address, and how many ways of sector are specified by value of
>>>> register (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
>>>> IMP_SCCR_SET1_L2_EL1).

Are A64FX binaries position independent?  I.e. could the OS reassign
a running task to a different sector by remapping it to different virtual
addresses during a context switch?

Or is this a static property at task launch?

-Tony


From mike.kravetz at oracle.com  Thu Apr 29 18:50:49 2021
From: mike.kravetz at oracle.com (Mike Kravetz)
Date: Thu, 29 Apr 2021 10:50:49 -0700
Subject: [RFC PATCH v1 2/4] mm/hugetlb: Change parameters of
 arch_make_huge_pte()
In-Reply-To: <e111d0d90231ae63e4b89da8efa87cde31daeeee.1619628001.git.christophe.leroy@csgroup.eu>
References: <cover.1619628001.git.christophe.leroy@csgroup.eu>
 <e111d0d90231ae63e4b89da8efa87cde31daeeee.1619628001.git.christophe.leroy@csgroup.eu>
Message-ID: <d7c516b7-4fec-dc1c-c931-e7b17272372e@oracle.com>

On 4/28/21 9:46 AM, Christophe Leroy wrote:
> At the time being, arch_make_huge_pte() has the following prototype:
> 
> 	pte_t arch_make_huge_pte(pte_t entry, struct vm_area_struct *vma,
> 				 struct page *page, int writable);
> 
> vma is used to get the pages shift or size.
> vma is also used on Sparc to get vm_flags.
> page is not used.
> writable is not used.
> 
> In order to use this function without a vma, and replace vma by shift
> and flags. Also remove the used parameters.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> ---
>  arch/arm64/include/asm/hugetlb.h                 | 3 +--
>  arch/arm64/mm/hugetlbpage.c                      | 5 ++---
>  arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 5 ++---
>  arch/sparc/include/asm/pgtable_64.h              | 3 +--
>  arch/sparc/mm/hugetlbpage.c                      | 6 ++----
>  include/linux/hugetlb.h                          | 4 ++--
>  mm/hugetlb.c                                     | 6 ++++--
>  mm/migrate.c                                     | 4 +++-
>  8 files changed, 17 insertions(+), 19 deletions(-)

Hi Christophe,

Sorry, no suggestion for how to make a beautiful generic implementation.

This patch is straight forward.
Acked-by: Mike Kravetz <mike.kravetz at oracle.com>
-- 
Mike Kravetz


From arnd at kernel.org  Thu Apr 29 18:50:46 2021
From: arnd at kernel.org (Arnd Bergmann)
Date: Thu, 29 Apr 2021 19:50:46 +0200
Subject: [PATCH] [v2] coresight: etm4x: avoid build failure with unrolled
 loops
In-Reply-To: <dff8cbd8-8c56-ae6e-ecc2-9ca183113ab2@arm.com>
References: <20210429145752.3218324-1-arnd@kernel.org>
 <dff8cbd8-8c56-ae6e-ecc2-9ca183113ab2@arm.com>
Message-ID: <CAK8P3a3-XoDQ6BfTBUof5ST2H1_6JOL+rK-BQqWXAV0H5jMm9Q@mail.gmail.com>

On Thu, Apr 29, 2021 at 7:37 PM Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
> On 29/04/2021 15:57, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd at arndb.de>
> >
> > clang-12 fails to build the etm4x driver with -fsanitize=array-bounds,
> > where it decides to unroll certain loops in a way that result in a
> > C variable getting put into an inline assembly
> >
> > <instantiation>:1:7: error: expected constant expression in '.inst' directive
> > .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
> >        ^
> > drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
> >                          etm4x_relaxed_read32(csa, TRCCNTVRn(i));
> >                          ^
> > drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
> >                   read_etm4x_sysreg_offset((offset), false)))
> >                   ^
> > drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
> >                          __val = read_etm4x_sysreg_const_offset((offset));       \
> >                                  ^
> > drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
> >          READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
> >          ^
> > drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
> >          read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
> >          ^
> > arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
> >          asm volatile(__mrs_s("%0", r) : "=r" (__val));                  \
> >                       ^
> > arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
> > "       mrs_s " v ", " __stringify(r) "\n"                      \
> >   ^
> >
> > This only happened in a few loops in which the array bounds sanitizer
> > added a special case for an array overflow that clang determined to be
> > possible, but any compiler is free to unroll any of the loops in the
> > same way that breaks the sysreg macros.
> >
> > Introduce helper functions that perform a sysreg access with a
> > non-constant register number and use them in each call that passes
> > a loop counter.
>
> You don't need to add this special helper. We have the exact
> infrastructure already. So these could simply be replaced with:
>
> csdev_access_xxx(csa, ...)
>
> see :
>
> include/linux/coresight.h

Ah, nice!

Do you mean replacing only the ones that use a nonconstant
offset, or all of them? I guess changing all would avoid some
really ugly magic macros, but the indirect function call and the
switch() adds a few cycles of overhead every time and the code
looks like it is micro-optimized for fast register access here.

      Arnd


From ebiederm at xmission.com  Thu Apr 29 18:52:31 2021
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 29 Apr 2021 12:52:31 -0500
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <20210423200126.otleormmjh22joj3@revolver> (Liam Howlett's
 message of "Fri, 23 Apr 2021 20:03:17 +0000")
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck>
 <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver>
 <m1y2d8dfx8.fsf@fess.ebiederm.org>
 <20210423200126.otleormmjh22joj3@revolver>
Message-ID: <m1czud6krk.fsf@fess.ebiederm.org>


This entire discussion seems to come down to what are the expected
semantics of arm64_notify_segfault.  The use of this helper in
swp_handler and user_cache_main_handler is clearly for the purposes of
instruction emulation.  With instruction emulation it is a bug if the
emulated instruction behaves differently than a real instruction in
the same circumstances.

To properly fix the instruction emulation in arm64_notify_segfault it
looks to me that the proper solution is to call __do_page_fault or
handle_mm_fault the way do_page_fault does and them parse the VM_FAULT
code for which signal to generate.

I would probably rename arm64_notify_segfault to arm64_emulate_fault, or
possibly arm64_notify_fault while fixing the emulation so that it
can return different signals and so that people don't have to guess
what the function is supposed to do.

For the specific case of sigreturn and rt_sigreturn it looks sufficient
to use the fixed arm64_notify_segfault.  As it appears the that the code
is attempting to act like it is emulating an instruction that does not
exist.


There is an argument that sigreturn and rt_sigreturn do a poor enough
job of acting like the fault was caused by an instruction, as well
as failing for other reasons it might make more sense to just have
sigreturn and rt_sigreturn call "force_sig(SIGSEGV);"  But that seems
out of scope of what you are trying to fix right now so I would not
worry about it.

Eric


From p.yadav at ti.com  Thu Apr 29 19:19:10 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Thu, 29 Apr 2021 23:49:10 +0530
Subject: [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if
 possible
In-Reply-To: <ee2b753b16e76ecbede4c1373b6f2d77@walle.cc>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-5-p.yadav@ti.com>
 <2f26456e-59ff-2625-5d65-c1537052839d@microchip.com>
 <20210312101757.sqeyledbwjnpqdoy@ti.com>
 <ee2b753b16e76ecbede4c1373b6f2d77@walle.cc>
Message-ID: <20210429181908.bwb45eljn5nxscf6@ti.com>

On 29/04/21 06:28PM, Michael Walle wrote:
> Am 2021-03-12 11:17, schrieb Pratyush Yadav:
> > On 12/03/21 09:13AM, Tudor.Ambarus at microchip.com wrote:
> > > On 3/11/21 9:12 PM, Pratyush Yadav wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > > >
> > > > Check if a read is eligible for PHY and if it is, enable PHY and DQS.
> > > 
> > > DQS as in data strobe? Shouldn't the upper layer inform the QSPI
> > > controller
> > > whether DS is required or not?
> > 
> > Yes, DQS as in data strobe. I need to check this again, but IIRC the
> > controller cannot run in PHY mode unless DS is used. Ideally the upper
> > layer should indeed inform the controller whether DS is supported/in-use
> > or not. That can be used to decide whether PHY mode (and consequently
> > the DS line) is to be used or not.
> > 
> > Currently there are only two flashes that use 8D-8D-8D mode (S28HS512T
> > and MT35XU512ABA), and both of them drive the DS line.
> 
> The LS1028A datasheet explicitly states that the calibration is only
> used for non-DQS flashes. Which makes sense, because it just determine at
> which point the input data is sampled. And if the flash provides a data
> strobe, it already know when to sample it. What I am missing here?

If there was 0 delay in transferring the signals from flash to 
SoC/controller, you would be right. But in practice there is a small but 
noticeable delay from when the flash launches the signal and when it is 
received by the device. So by the time the DQS signal reaches the SoC it 
might already be too late and the data lines might not be valid any 
more. The calibration accounts for these (and some others) delays.

See [0] for a somewhat similar discussion I had with Tudor.

[0] https://lore.kernel.org/linux-mtd/20210312181447.dlecnw2oed7jtxe7 at ti.com/

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From alex.williamson at redhat.com  Thu Apr 29 19:28:40 2021
From: alex.williamson at redhat.com (Alex Williamson)
Date: Thu, 29 Apr 2021 12:28:40 -0600
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210429162906.32742-2-sdonthineni@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
Message-ID: <20210429122840.4f98f78e@redhat.com>

On Thu, 29 Apr 2021 11:29:05 -0500
Shanker Donthineni <sdonthineni at nvidia.com> wrote:

> For pass-through device assignment, the ARM64 KVM hypervisor retrieves
> the memory region properties physical address, size, and whether a
> region backed with struct page or not from VMA. The prefetchable
> attribute of a BAR region isn't visible to KVM to make an optimal
> decision for stage2 attributes.
> 
> This patch updates vma->vm_page_prot and maps with write-combine
> attribute if the associated BAR is prefetchable. For ARM64
> pgprot_writecombine() is mapped to memory-type MT_NORMAL_NC which
> has no side effects on reads and multiple writes can be combined.
> 
> Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
> ---
>  drivers/vfio/pci/vfio_pci.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 5023e23db3bc..1b734fe1dd51 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -1703,7 +1703,11 @@ static int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
>  	}
>  
>  	vma->vm_private_data = vdev;
> -	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +	if (IS_ENABLED(CONFIG_ARM64) &&
> +	    (pci_resource_flags(pdev, index) & IORESOURCE_PREFETCH))
> +		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> +	else
> +		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);

If this were a valid thing to do, it should be done for all
architectures, not just ARM64.  However, a prefetchable range only
necessarily allows merged writes, which seems like a subset of the
semantics implied by a WC attribute, therefore this doesn't seem
universally valid.

I'm also a bit confused by your problem statement that indicates that
without WC you're seeing unaligned accesses, does this suggest that
your driver is actually relying on WC semantics to perform merging to
achieve alignment?  That seems rather like a driver bug, I'd expect UC
vs WC is largely a difference in performance, not a means to enforce
proper driver access patterns.  Per the PCI spec, the bridge itself can
merge writes to prefetchable areas, presumably regardless of this
processor attribute, perhaps that's the feature your driver is relying
on that might be missing here.  Thanks,

Alex



From p.yadav at ti.com  Thu Apr 29 19:41:11 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Fri, 30 Apr 2021 00:11:11 +0530
Subject: [RFC PATCH 1/6] spi: spi-mem: Tell controller when device is
 ready for calibration
In-Reply-To: <6dfbb3e4107887dc9ee3e19e4940e87c@walle.cc>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-2-p.yadav@ti.com>
 <934c8c6f7bb71729bfdaefd39c63a262@walle.cc>
 <20210324080804.x7oemmpt2khi72mp@ti.com>
 <6dfbb3e4107887dc9ee3e19e4940e87c@walle.cc>
Message-ID: <20210429184109.f2pf3iyaiylumoyp@ti.com>

On 29/04/21 06:23PM, Michael Walle wrote:
> Hi Pratyush,
> 
> I've had a look at the LS1028A FlexSPI calibration feature. The
> reference manual is very sparse on details, though. What you need to
> do there is to program a special read command sequence (the whole
> controller is made of these lookup table entries, where you can
> have a short sequence of operations for read/write/program and so
> on). Therefore, for data learning you'll take the read operation
> and insert a LEARN op in between and read a specific data pattern.
> Then the hardware will automatically figure out the correct sample
> phase for the read data pins.
> 
> Unfortunately, it does not mention how often you have to do it. It
> might be the case that is has to be calibrated more than once.

I haven't read the datasheet, I wonder how long this calibration takes. 
If it is too long then the overhead might not even be worth the extra 
read throughput. Especially when using a file system on top which 
generally don't do very large reads in one go.

Anyway, when the do_calibration() is called the controller can save the 
calibration op and use it later as needed. It knows when an exec_op() 
will result in a read since it has access to the whole op.

> 
> I'm just mentioning this so it won't be lost. If needed, it can
> be added later.
> 
> Am 2021-03-24 09:08, schrieb Pratyush Yadav:
> > On 24/03/21 12:07AM, Michael Walle wrote:
> > > Am 2021-03-11 20:12, schrieb Pratyush Yadav:
> > > > Some controllers like the Cadence OSPI controller need to perform a
> > > > calibration sequence to operate at high clock speeds. This calibration
> > > > should happen after the flash is fully initialized otherwise the
> > > > calibration might happen in a different SPI mode from the one the flash
> > > > is finally set to. Add a hook that can be used to tell the controller
> > > > when the flash is ready for calibration. Whether calibration is needed
> > > > depends on the controller.
> > > >
> > > > Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
> > > > ---
> > > >  drivers/spi/spi-mem.c       | 12 ++++++++++++
> > > >  include/linux/spi/spi-mem.h |  8 ++++++++
> > > >  2 files changed, 20 insertions(+)
> > > >
> > > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> > > > index dc713b0c3c4d..e2f05ad3f4dc 100644
> > > > --- a/drivers/spi/spi-mem.c
> > > > +++ b/drivers/spi/spi-mem.c
> > > > @@ -464,6 +464,18 @@ int spi_mem_adjust_op_size(struct spi_mem *mem,
> > > > struct spi_mem_op *op)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
> > > >
> > > > +int spi_mem_do_calibration(struct spi_mem *mem, struct spi_mem_op *op)
> > > > +{
> > > > +	struct spi_controller *ctlr = mem->spi->controller;
> > > > +
> > > > +	if (!ctlr->mem_ops || !ctlr->mem_ops->do_calibration)
> > > > +		return -EOPNOTSUPP;
> > > > +
> > > > +	ctlr->mem_ops->do_calibration(mem, op);
> > > 
> > > Can't a calibration fail?
> > 
> > It can. If it does, the controller falls back to lower speed transfers.
> > There is not much the upper layer can do about this. That's why it is
> > not informed whether it succeeded or not.
> 
> Ok, if needed, that should be an easy change.
> 
> op is there to decide if we need a calibration at all, correct?

Yes. It can also be used to choose which calibration algorithm to use. 
For example on the Cadence controller, there are different algorithms 
for 8S and 8D operations.

> What if there are different factors, like frequency? For example
> on the LS1028A its just a matter of the SCK frequency. It seems
> that this parameter is tailored to the OPHY.

As of now there is no way in SPI MEM to tell the controller the expected 
speed of the operation. AFAIK most controllers get the speed via device 
tree. So in the current case, the controller already knows the speed it 
should run at, and can decide if calibration is needed or not.

But if operation speed is eventually added to SPI MEM, I would assume it 
would be part of struct spi_mem_op. The op passed in would have this 
information filled, and the controller can use that information to 
decide if it needs to perform the calibration or not.

I am all for making this API flexible, but with very few controllers 
supporting this feature in the wild, it is difficult to predict all the 
information that might be needed. In the current state, I think the API 
provides a fair bit of information to the controller about how a read 
operation would look like.

> 
> -michael
> 
> > > > +	return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(spi_mem_do_calibration);
> > > > +
> > > >  static ssize_t spi_mem_no_dirmap_read(struct spi_mem_dirmap_desc *desc,
> > > >  				      u64 offs, size_t len, void *buf)
> > > >  {
> > > > diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> > > > index 2b65c9edc34e..97a2d280f2d0 100644
> > > > --- a/include/linux/spi/spi-mem.h
> > > > +++ b/include/linux/spi/spi-mem.h
> > > > @@ -250,6 +250,12 @@ static inline void *spi_mem_get_drvdata(struct
> > > > spi_mem *mem)
> > > >   *		  the currently mapped area), and the caller of
> > > >   *		  spi_mem_dirmap_write() is responsible for calling it again in
> > > >   *		  this case.
> > > > + * @do_calibration: perform calibration needed for high SPI clock speed
> > > > + *		    operation. Should be called after the SPI memory device has
> > > > + *		    been completely initialized. The op passed should contain
> > > > + *		    a template for the read operation used for the device so
> > > > + *		    the controller can decide what type of calibration is
> > > > + *		    required for this type of read.
> > > >   *
> > > >   * This interface should be implemented by SPI controllers providing an
> > > >   * high-level interface to execute SPI memory operation, which is
> > > > usually the
> > > > @@ -274,6 +280,7 @@ struct spi_controller_mem_ops {
> > > >  			       u64 offs, size_t len, void *buf);
> > > >  	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
> > > >  				u64 offs, size_t len, const void *buf);
> > > > +	void (*do_calibration)(struct spi_mem *mem, struct spi_mem_op *op);
> > > >  };
> > > >
> > > >  /**
> > > > @@ -346,6 +353,7 @@ bool spi_mem_dtr_supports_op(struct spi_mem *mem,
> > > >  #endif /* CONFIG_SPI_MEM */
> > > >
> > > >  int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op);
> > > > +int spi_mem_do_calibration(struct spi_mem *mem, struct spi_mem_op *op);
> > > >
> > > >  bool spi_mem_supports_op(struct spi_mem *mem,
> > > >  			 const struct spi_mem_op *op);
> > > 
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From morbo at google.com  Thu Apr 29 19:52:26 2021
From: morbo at google.com (Bill Wendling)
Date: Thu, 29 Apr 2021 11:52:26 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210429095027.GR9028@arm.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
 <20210429075454.GQ9028@arm.com>
 <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>
 <20210429095027.GR9028@arm.com>
Message-ID: <CAGG=3QW9t2zUPYLt_La=qQTZeHzfLBCXgZRbiia8T6K7n=YrdQ@mail.gmail.com>

On Thu, Apr 29, 2021 at 2:50 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
> The 04/29/2021 02:23, Bill Wendling wrote:
> > On Thu, Apr 29, 2021 at 12:55 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
> > > The 04/28/2021 12:31, Bill Wendling wrote:
> > > > On Wed, Apr 28, 2021 at 12:21 PM Bill Wendling <morbo at google.com> wrote:
> > > > > On Wed, Apr 28, 2021 at 10:40 AM Mark Brown <broonie at kernel.org> wrote:
> > > > > > On Wed, Apr 28, 2021 at 06:28:47PM +0100, Catalin Marinas wrote:
> > > > > > > On Fri, Apr 23, 2021 at 01:51:59PM -0700, Bill Wendling wrote:
> > > > > >
> > > > > > > > Since the note.gnu.property section in the vDSO is not checked by the
> > > > > > > > dynamic linker, discard the .note.gnu.property sections in the vDSO.
> > > > > >
> > > > > > > Can we not instead fix the linker script to preserve the
> > > > > > > .note.gnu.property, correctly aligned? It doesn't take much space and
> > > > > > > while we don't use it now, it has the BTI information about the binary.
> > > > > >
> > > > > > > Cc'ing a few others who were involved in the BTI support.
> > > > > >
> > > > > > Not just BTI, we also flag PAC usage in there too and could add other
> > > > > > extensions going forwards.  While the note isn't actively used by
> > > > > > anything right now due to the kernel mapping the vDSO prior to userspace
> > > > > > starting it is part of the ABI and something could end up wanting to use
> > > > > > it and getting confused if it's not there.  It would be much better to
> > > > > > fix the alignment issue.
> > > > >
> > > > > If there's only one of the 8-byte aligned sections guaranteed, we
> > > > > could place it first in the note. Otherwise, we will have to change
> > > > > the alignment of the note (or somehow merge multiple notes).
> > > > >
> > > > I should have clarified that there's only one *entry* in the
> > > > .note.gnu.properties section, and if not then is it possible to merge
> > > > multiple entries into one. (Excuse my ignorance if this is already the
> > > > case.)
> > >
> > > .note.gnu.property should go to PT_GNU_PROPERTY and it
> > > should be merged following rules specified in
> > > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
> > > and
> > > https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#program-property
> > >
> > > it may also be covered by a (8byte aligned) PT_NOTE, but
> > > that's not a requirement on aarch64 (x86 requires it for
> > > compatibility with old dynamic linker, but since the vdso
> > > is handled specially that may not be relevant either).
> > >
> > > i don't know how this works in linker scripts.
> >
> > This is a potential patch. I haven't had time to test it though.
> > However, it does appear to format the section in the "expected" way,
> > so one's able to grab the build IDs. Thoughts?
>
>
> please show the program headers.
>

$ readelf -lW arch/arm64/kernel/vdso/vdso.so

Elf file type is DYN (Shared object file)
Entry point 0x300
There are 4 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr
FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000000000 0x0000000000000000
0x000968 0x000968 R E 0x8
  DYNAMIC        0x0008a8 0x00000000000008a8 0x00000000000008a8
0x0000c0 0x0000c0 R   0x8
  NOTE           0x000288 0x0000000000000288 0x0000000000000288
0x000074 0x000074 R   0x8
  GNU_EH_FRAME   0x0008a4 0x00000000000008a4 0x00000000000008a4
0x000000 0x000000 R E 0x1

 Section to Segment mapping:
  Segment Sections...
   00     .hash .dynsym .dynstr .gnu.version .gnu.version_d .note
.text .eh_frame_hdr .eh_frame .dynamic
   01     .dynamic
   02     .note
   03     .eh_frame_hdr .eh_frame

> >
> > $ objdump -s -j .note ./arch/arm64/kernel/vdso/vdso.so
> >
> > ./arch/arm64/kernel/vdso/vdso.so:     file format elf64-little
> >
> > Contents of section .note:
> >  0288 04000000 10000000 05000000 474e5500  ............GNU.
> >  0298 000000c0 04000000 03000000 00000000  ................
> >  02a8 06000000 04000000 00000000 4c696e75  ............Linu
> >  02b8 78000000 000a0500 06000000 01000000  x...............
> >  02c8 00010000 4c696e75 78000000 00000000  ....Linux.......
> >  02d8 04000000 14000000 03000000 474e5500  ............GNU.
> >  02e8 958db149 af5156cb 45309896 7a53ae8a  ...I.QV.E0..zS..
> >  02f8 ef34e95c                             .4.\
> >
> > diff --git a/arch/arm64/kernel/vdso/vdso.lds.S
> > b/arch/arm64/kernel/vdso/vdso.lds.S
> > index d808ad31e01f..d51e886c6223 100644
> > --- a/arch/arm64/kernel/vdso/vdso.lds.S
> > +++ b/arch/arm64/kernel/vdso/vdso.lds.S
> > @@ -31,7 +31,13 @@ SECTIONS
> >         .gnu.version_d  : { *(.gnu.version_d) }
> >         .gnu.version_r  : { *(.gnu.version_r) }
> >
> > -       .note           : { *(.note.*) }                :text   :note
> > +       /*
> > +        * Add the .note.gnu.property section first, as it's aligned to
> > +        * 8-bytes, while other notes are aligned to 4-bytes.
> > +        */
> > +       . = ALIGN(8);
> > +
> > +       .note           : { *(.note.gnu.property) *(.note.*) }  :text   :note
> >
> >         . = ALIGN(16);
>
> --


From elver at google.com  Thu Apr 29 20:07:33 2021
From: elver at google.com (Marco Elver)
Date: Thu, 29 Apr 2021 21:07:33 +0200
Subject: [PATCH 2/3] arm: Add compile-time asserts for siginfo_t offsets
In-Reply-To: <20210429190734.624918-1-elver@google.com>
References: <20210429190734.624918-1-elver@google.com>
Message-ID: <20210429190734.624918-2-elver@google.com>

To help catch ABI breaks at compile-time, add compile-time assertions to
verify the siginfo_t layout.

This could have caught that we cannot portably add 64-bit integers to
siginfo_t on 32-bit architectures like Arm before reaching -next:
https://lkml.kernel.org/r/20210422191823.79012-1-elver at google.com

Signed-off-by: Marco Elver <elver at google.com>
---
 arch/arm/kernel/signal.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index a3a38d0a4c85..2dac5d2c5cf6 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -725,3 +725,39 @@ asmlinkage void do_rseq_syscall(struct pt_regs *regs)
 	rseq_syscall(regs);
 }
 #endif
+
+/*
+ * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
+ * changes likely come with new fields that should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(siginfo_t, si_pid)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_uid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_tid)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_overrun)	== 0x10);
+static_assert(offsetof(siginfo_t, si_status)	== 0x14);
+static_assert(offsetof(siginfo_t, si_utime)	== 0x18);
+static_assert(offsetof(siginfo_t, si_stime)	== 0x1c);
+static_assert(offsetof(siginfo_t, si_value)	== 0x14);
+static_assert(offsetof(siginfo_t, si_int)	== 0x14);
+static_assert(offsetof(siginfo_t, si_ptr)	== 0x14);
+static_assert(offsetof(siginfo_t, si_addr)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_addr_lsb)	== 0x10);
+static_assert(offsetof(siginfo_t, si_lower)	== 0x14);
+static_assert(offsetof(siginfo_t, si_upper)	== 0x18);
+static_assert(offsetof(siginfo_t, si_pkey)	== 0x14);
+static_assert(offsetof(siginfo_t, si_perf)	== 0x10);
+static_assert(offsetof(siginfo_t, si_band)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_fd)	== 0x10);
+static_assert(offsetof(siginfo_t, si_call_addr)	== 0x0c);
+static_assert(offsetof(siginfo_t, si_syscall)	== 0x10);
+static_assert(offsetof(siginfo_t, si_arch)	== 0x14);
-- 
2.31.1.527.g47e6f16901-goog



From elver at google.com  Thu Apr 29 20:07:32 2021
From: elver at google.com (Marco Elver)
Date: Thu, 29 Apr 2021 21:07:32 +0200
Subject: [PATCH 1/3] sparc64: Add compile-time asserts for siginfo_t offsets
Message-ID: <20210429190734.624918-1-elver@google.com>

To help catch ABI breaks at compile-time, add compile-time assertions to
verify the siginfo_t layout. Unlike other architectures, sparc64 is
special, because it is one of few architectures requiring si_trapno.
ABI breaks around that field would only be caught here.

Link: https://lkml.kernel.org/r/m11rat9f85.fsf at fess.ebiederm.org
Suggested-by: Eric W. Biederman <ebiederm at xmission.com>
Signed-off-by: Marco Elver <elver at google.com>
---
 arch/sparc/kernel/signal32.c  | 34 ++++++++++++++++++++++++++++++++++
 arch/sparc/kernel/signal_64.c | 33 +++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/arch/sparc/kernel/signal32.c b/arch/sparc/kernel/signal32.c
index e9695a06492f..778ed5c26d4a 100644
--- a/arch/sparc/kernel/signal32.c
+++ b/arch/sparc/kernel/signal32.c
@@ -745,3 +745,37 @@ asmlinkage int do_sys32_sigstack(u32 u_ssptr, u32 u_ossptr, unsigned long sp)
 out:
 	return ret;
 }
+
+/*
+ * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
+ * changes likely come with new fields that should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(compat_siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(compat_siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(compat_siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(compat_siginfo_t, si_pid)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_uid)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_tid)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_overrun)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_status)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_utime)	== 0x18);
+static_assert(offsetof(compat_siginfo_t, si_stime)	== 0x1c);
+static_assert(offsetof(compat_siginfo_t, si_value)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_int)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_ptr)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_addr)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_trapno)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_addr_lsb)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_lower)	== 0x18);
+static_assert(offsetof(compat_siginfo_t, si_upper)	== 0x1c);
+static_assert(offsetof(compat_siginfo_t, si_pkey)	== 0x18);
+static_assert(offsetof(compat_siginfo_t, si_perf)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_band)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_fd)		== 0x10);
diff --git a/arch/sparc/kernel/signal_64.c b/arch/sparc/kernel/signal_64.c
index a0eec62c825d..c9bbf5f29078 100644
--- a/arch/sparc/kernel/signal_64.c
+++ b/arch/sparc/kernel/signal_64.c
@@ -556,3 +556,36 @@ void do_notify_resume(struct pt_regs *regs, unsigned long orig_i0, unsigned long
 	user_enter();
 }
 
+/*
+ * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
+ * changes likely come with new fields that should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(siginfo_t, si_pid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_uid)	== 0x14);
+static_assert(offsetof(siginfo_t, si_tid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_overrun)	== 0x14);
+static_assert(offsetof(siginfo_t, si_status)	== 0x18);
+static_assert(offsetof(siginfo_t, si_utime)	== 0x20);
+static_assert(offsetof(siginfo_t, si_stime)	== 0x28);
+static_assert(offsetof(siginfo_t, si_value)	== 0x18);
+static_assert(offsetof(siginfo_t, si_int)	== 0x18);
+static_assert(offsetof(siginfo_t, si_ptr)	== 0x18);
+static_assert(offsetof(siginfo_t, si_addr)	== 0x10);
+static_assert(offsetof(siginfo_t, si_trapno)	== 0x18);
+static_assert(offsetof(siginfo_t, si_addr_lsb)	== 0x20);
+static_assert(offsetof(siginfo_t, si_lower)	== 0x28);
+static_assert(offsetof(siginfo_t, si_upper)	== 0x30);
+static_assert(offsetof(siginfo_t, si_pkey)	== 0x28);
+static_assert(offsetof(siginfo_t, si_perf)	== 0x20);
+static_assert(offsetof(siginfo_t, si_band)	== 0x10);
+static_assert(offsetof(siginfo_t, si_fd)	== 0x14);
-- 
2.31.1.527.g47e6f16901-goog



From elver at google.com  Thu Apr 29 20:07:34 2021
From: elver at google.com (Marco Elver)
Date: Thu, 29 Apr 2021 21:07:34 +0200
Subject: [PATCH 3/3] arm64: Add compile-time asserts for siginfo_t offsets
In-Reply-To: <20210429190734.624918-1-elver@google.com>
References: <20210429190734.624918-1-elver@google.com>
Message-ID: <20210429190734.624918-3-elver@google.com>

To help catch ABI breaks at compile-time, add compile-time assertions to
verify the siginfo_t layout.

Signed-off-by: Marco Elver <elver at google.com>
---
 arch/arm64/kernel/signal.c   | 36 ++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/signal32.c | 36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 72 insertions(+)

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 6237486ff6bb..af8bd2af1298 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -973,3 +973,39 @@ void __init minsigstksz_setup(void)
 		round_up(sizeof(struct frame_record), 16) +
 		16; /* max alignment padding */
 }
+
+/*
+ * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
+ * changes likely come with new fields that should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(siginfo_t, si_pid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_uid)	== 0x14);
+static_assert(offsetof(siginfo_t, si_tid)	== 0x10);
+static_assert(offsetof(siginfo_t, si_overrun)	== 0x14);
+static_assert(offsetof(siginfo_t, si_status)	== 0x18);
+static_assert(offsetof(siginfo_t, si_utime)	== 0x20);
+static_assert(offsetof(siginfo_t, si_stime)	== 0x28);
+static_assert(offsetof(siginfo_t, si_value)	== 0x18);
+static_assert(offsetof(siginfo_t, si_int)	== 0x18);
+static_assert(offsetof(siginfo_t, si_ptr)	== 0x18);
+static_assert(offsetof(siginfo_t, si_addr)	== 0x10);
+static_assert(offsetof(siginfo_t, si_addr_lsb)	== 0x18);
+static_assert(offsetof(siginfo_t, si_lower)	== 0x20);
+static_assert(offsetof(siginfo_t, si_upper)	== 0x28);
+static_assert(offsetof(siginfo_t, si_pkey)	== 0x20);
+static_assert(offsetof(siginfo_t, si_perf)	== 0x18);
+static_assert(offsetof(siginfo_t, si_band)	== 0x10);
+static_assert(offsetof(siginfo_t, si_fd)	== 0x18);
+static_assert(offsetof(siginfo_t, si_call_addr)	== 0x10);
+static_assert(offsetof(siginfo_t, si_syscall)	== 0x18);
+static_assert(offsetof(siginfo_t, si_arch)	== 0x1c);
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 2f507f565c48..b6afb646515f 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -457,3 +457,39 @@ void compat_setup_restart_syscall(struct pt_regs *regs)
 {
        regs->regs[7] = __NR_compat_restart_syscall;
 }
+
+/*
+ * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
+ * changes likely come with new fields that should be added below.
+ */
+static_assert(NSIGILL	== 11);
+static_assert(NSIGFPE	== 15);
+static_assert(NSIGSEGV	== 9);
+static_assert(NSIGBUS	== 5);
+static_assert(NSIGTRAP	== 6);
+static_assert(NSIGCHLD	== 6);
+static_assert(NSIGSYS	== 2);
+static_assert(offsetof(compat_siginfo_t, si_signo)	== 0x00);
+static_assert(offsetof(compat_siginfo_t, si_errno)	== 0x04);
+static_assert(offsetof(compat_siginfo_t, si_code)	== 0x08);
+static_assert(offsetof(compat_siginfo_t, si_pid)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_uid)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_tid)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_overrun)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_status)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_utime)	== 0x18);
+static_assert(offsetof(compat_siginfo_t, si_stime)	== 0x1c);
+static_assert(offsetof(compat_siginfo_t, si_value)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_int)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_ptr)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_addr)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_addr_lsb)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_lower)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_upper)	== 0x18);
+static_assert(offsetof(compat_siginfo_t, si_pkey)	== 0x14);
+static_assert(offsetof(compat_siginfo_t, si_perf)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_band)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_fd)		== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_call_addr)	== 0x0c);
+static_assert(offsetof(compat_siginfo_t, si_syscall)	== 0x10);
+static_assert(offsetof(compat_siginfo_t, si_arch)	== 0x14);
-- 
2.31.1.527.g47e6f16901-goog



From sdonthineni at nvidia.com  Thu Apr 29 20:14:50 2021
From: sdonthineni at nvidia.com (Shanker R Donthineni)
Date: Thu, 29 Apr 2021 14:14:50 -0500
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210429122840.4f98f78e@redhat.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
Message-ID: <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>

Thanks Alex for quick reply.

On 4/29/21 1:28 PM, Alex Williamson wrote:
> If this were a valid thing to do, it should be done for all
> architectures, not just ARM64.  However, a prefetchable range only
> necessarily allows merged writes, which seems like a subset of the
> semantics implied by a WC attribute, therefore this doesn't seem
> universally valid.
>
> I'm also a bit confused by your problem statement that indicates that
> without WC you're seeing unaligned accesses, does this suggest that
> your driver is actually relying on WC semantics to perform merging to
> achieve alignment?  That seems rather like a driver bug, I'd expect UC
> vs WC is largely a difference in performance, not a means to enforce
> proper driver access patterns.  Per the PCI spec, the bridge itself can
> merge writes to prefetchable areas, presumably regardless of this
> processor attribute, perhaps that's the feature your driver is relying
> on that might be missing here.  Thanks,
The driver uses WC semantics, It's mapping PCI prefetchable BARS using ioremap_wc().? We don't see any issue for x86 architecture,? driver works fine in the host and guest kernel. The same driver works on ARM64 kernel but crashes inside VM.
GPU driver uses the architecture agnostic function ioremap_wc() like other drivers. This limitation applies to all the drivers if they use WC memory and follow ARM64 NORMAL-NC access rules.

On ARM64, ioremap_wc() is mapped to non-cacheable memory-type, no side effects on reads and unaligned accesses are allowed as per ARM-ARM architecture. The driver behavior is different in host vs guest on ARM64.?

ARM CPU generating alignment faults before transaction reaches the PCI-RC/switch/end-point-device.

We've two concerns here:
?? - Performance impacts for pass-through devices.
?? - The definition of ioremap_wc() function doesn't match the host kernel on ARM64

?
> Alex
>



From philippe.cornu at foss.st.com  Thu Apr 29 20:35:30 2021
From: philippe.cornu at foss.st.com (Philippe CORNU - foss)
Date: Thu, 29 Apr 2021 19:35:30 +0000
Subject: [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly
In-Reply-To: <20210427092018.832258-7-daniel.vetter@ffwll.ch>
References: <20210427092018.832258-1-daniel.vetter@ffwll.ch>,
 <20210427092018.832258-7-daniel.vetter@ffwll.ch>
Message-ID: <1619724930873.72167@foss.st.com>

Hi Daniel,
Many thanks for your patch,
Acked-by: Philippe Cornu <philippe.cornu at st.com>
Philippe :-)

________________________________________
De : Daniel Vetter <daniel.vetter at ffwll.ch>
Envoy? : mardi 27 avril 2021 11:20
? : DRI Development
Cc : Intel Graphics Development; Daniel Vetter; Daniel Vetter; Yannick FERTRE - foss; Philippe CORNU - foss; Benjamin Gaignard; Maxime Coquelin; Alexandre TORGUE - foss; linux-stm32 at st-md-mailman.stormreply.com; linux-arm-kernel at lists.infradead.org
Objet : [PATCH 7/8] drm/stm: Don't set allow_fb_modifiers explicitly

Since

commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Cc: Yannick Fertre <yannick.fertre at foss.st.com>
Cc: Philippe Cornu <philippe.cornu at foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard at linaro.org>
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/gpu/drm/stm/ltdc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 65c3c79ad1d5..e99771b947b6 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1326,8 +1326,6 @@ int ltdc_load(struct drm_device *ddev)
                goto err;
        }

-       ddev->mode_config.allow_fb_modifiers = true;
-
        ret = ltdc_crtc_init(ddev, crtc);
        if (ret) {
                DRM_ERROR("Failed to init crtc\n");
--
2.31.0



From alex.williamson at redhat.com  Thu Apr 29 20:46:59 2021
From: alex.williamson at redhat.com (Alex Williamson)
Date: Thu, 29 Apr 2021 13:46:59 -0600
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
Message-ID: <20210429134659.321a5c3c@redhat.com>

On Thu, 29 Apr 2021 14:14:50 -0500
Shanker R Donthineni <sdonthineni at nvidia.com> wrote:

> Thanks Alex for quick reply.
> 
> On 4/29/21 1:28 PM, Alex Williamson wrote:
> > If this were a valid thing to do, it should be done for all
> > architectures, not just ARM64.  However, a prefetchable range only
> > necessarily allows merged writes, which seems like a subset of the
> > semantics implied by a WC attribute, therefore this doesn't seem
> > universally valid.
> >
> > I'm also a bit confused by your problem statement that indicates that
> > without WC you're seeing unaligned accesses, does this suggest that
> > your driver is actually relying on WC semantics to perform merging to
> > achieve alignment?  That seems rather like a driver bug, I'd expect UC
> > vs WC is largely a difference in performance, not a means to enforce
> > proper driver access patterns.  Per the PCI spec, the bridge itself can
> > merge writes to prefetchable areas, presumably regardless of this
> > processor attribute, perhaps that's the feature your driver is relying
> > on that might be missing here.  Thanks,  
> The driver uses WC semantics, It's mapping PCI prefetchable BARS
> using ioremap_wc().? We don't see any issue for x86 architecture,
> driver works fine in the host and guest kernel. The same driver works
> on ARM64 kernel but crashes inside VM. GPU driver uses the
> architecture agnostic function ioremap_wc() like other drivers. This
> limitation applies to all the drivers if they use WC memory and
> follow ARM64 NORMAL-NC access rules.

x86 KVM works for other reasons, KVM will trust the vCPU attributes for
the memory range rather than relying only on the host mapping.

> On ARM64, ioremap_wc() is mapped to non-cacheable memory-type, no
> side effects on reads and unaligned accesses are allowed as per
> ARM-ARM architecture. The driver behavior is different in host vs
> guest on ARM64.?

Per the PCI spec, prefetchable memory only necessarily allows the bridge
to merge writes.  I believe this is only a subset of what WC mappings
allow, therefore I expect this is incompatible with drivers that do not
use WC mappings.
 
> ARM CPU generating alignment faults before transaction reaches the
> PCI-RC/switch/end-point-device.

If an alignment fault is fixed by configuring a WC mapping, doesn't
that suggest that the driver performed an unaligned access itself and
is relying on write combining by the processor to correct that error?
That's wrong.  Fix the driver or please offer another explanation of
how the WC mapping resolves this.  I suspect you could enable tracing
in QEMU, disable MMIO mmaps on the vfio-pci device and find the invalid
access.

> We've two concerns here:
> ?? - Performance impacts for pass-through devices.
> ?? - The definition of ioremap_wc() function doesn't match the host
> kernel on ARM64

Performance I can understand, but I think you're also using it to mask
a driver bug which should be resolved first.  Thanks,

Alex



From martin.blumenstingl at googlemail.com  Thu Apr 29 21:37:23 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 29 Apr 2021 22:37:23 +0200
Subject: [PATCH RFC] soc: amlogic: meson-ee-pwrc: Drop the .shutdown callback
 from the driver
Message-ID: <20210429203723.1177082-1-martin.blumenstingl@googlemail.com>

Stefan reports that rebooting his ODROID-N2+ (using a G12B SoC) results
in the board hanging. His kernel config uses:
  CONFIG_MESON_EE_PM_DOMAINS=y
  CONFIG_DRM_MESON=m

He reports that his kernel config results in the DRM driver's .shutdown
callback to be executed after the power domain driver's .shutdown
callback. That's problematic because meson_ee_pwrc_shutdown disables the
clock which are used by the VPU IP. This causes the board to hang.

Further he reports that changing from CONFIG_DRM_MESON=m to
CONFIG_DRM_MESON=y reverses the order in which the DRM and power domain
driver's shutdown functions are executed, making the reboot successful.

The reason why we use meson_ee_pwrc_shutdown is because of the VPU power
domain (which is causing the problem described above). It can be left
enabled by u-boot. According to the original TOFIX comment in
meson_ee_pwrc_init_domain we need to be careful because disabling the
power domain could "cause system errors". As a workaround the clocks
are manually enabled in meson_ee_pwrc_init_domain and the power domain
is marked as GENPD_FLAG_ALWAYS_ON (so it can never be turned off).

Experimenting has shown that the power domain itself can be disabled as
long as we keep the clocks enabled if u-boot enabled the power domain
but we don't have any driver enabled for the VPU (CONFIG_DRM_MESON=n).

Keeping the clocks enabled is the responsibility of the CCF drivers, not
the power domain driver. Even better: this is already covered as all
gates in the VPU and VAPB tree on GX an G12 SoCs have the
CLK_IGNORE_UNUSED flag set, meaning: if the bootloader has previously
enabled the clock we're not touching it until a driver explicitly asks
to enable (and then disable) it. In case of CONFIG_DRM_MESON=n we're
never calling meson_ee_pwrc_on, meaning that we always keep the state of
the clocks as set by u-boot.

The original TOFIX comment also mentioned that we need to make sure not
to mess up the clock's prepare/enable ref-counters. This is the only
requirement that's left for the meson-ee-pwrc driver that needs to be
managed for the VPU power domain.

Three steps can improve this situation:
- Don't prepare and enable the clocks (just to fix the ref-counting) in
  meson_ee_pwrc_init_domain if u-boot left that power domain enabled.
  Instead, remember if the clocks are enabled in meson_ee_pwrc_{on,off}
  and only disable them if we have previously turned them on ourselves.
- Drop GENPD_FLAG_ALWAYS_ON as we can always manage the state of the VPU
  power domain if both the power domain controller and DRM driver are
  enabled (=m or =y). If the power domain driver is enabled but the DRM
  driver is disabled we can still use meson_ee_pwrc_off because it's not
  trying to disable the clocks anymore
- Drop meson_ee_pwrc_shutdown as it's the responsibility of the genpd
  framework to call meson_ee_pwrc_off when needed (either when a power
  domain is being disabled - regardless of whether it's was used by a
  driver before or not). Now there's also no more shutdown callback
  ordering dependency between the power domain driver and other drivers
  anymore.

Fixes: eef3c2ba0a42a6 ("soc: amlogic: Add support for Everything-Else power domains controller")
Reported-by: Stefan Agner <stefan at agner.ch>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
---
Neil, I would like you to specifically review (and re-test) the original
TOFIX part. I *believe* that I understand the original problem and hope
that my approach also works in that scenario, but I am not 100% sure.

Kevin, as you're my go-to genpd expert I am also asking you to review
this to point out any issues you see.


 drivers/soc/amlogic/meson-ee-pwrc.c | 76 ++++++++++++-----------------
 1 file changed, 31 insertions(+), 45 deletions(-)

diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c b/drivers/soc/amlogic/meson-ee-pwrc.c
index 50bf5d2b828b..534c33ba31ce 100644
--- a/drivers/soc/amlogic/meson-ee-pwrc.c
+++ b/drivers/soc/amlogic/meson-ee-pwrc.c
@@ -353,10 +353,26 @@ static int meson_ee_pwrc_off(struct generic_pm_domain *domain)
 
 	if (pwrc_domain->num_clks) {
 		msleep(20);
-		clk_bulk_disable_unprepare(pwrc_domain->num_clks,
-					   pwrc_domain->clks);
+
+		/*
+		 * We are only allowed to turn off the clocks here if we
+		 * have previously enabled them ourselves. In other words:
+		 * for an "unused" power domain (which is not used by any
+		 * power domain consumer) we have not enabled the clocks
+		 * previously so we keep them in the state they are.
+		 * This is relevant for the VPU power domain which may
+		 * have been enabled by u-boot. If the display driver in
+		 * Linux is disabled then we need to keep the clocks in
+		 * the state as u-boot set them, otherwise the board will
+		 * hang.
+		 */
+		if (pwrc_domain->enabled)
+			clk_bulk_disable_unprepare(pwrc_domain->num_clks,
+						   pwrc_domain->clks);
 	}
 
+	pwrc_domain->enabled = false;
+
 	return 0;
 }
 
@@ -392,8 +408,14 @@ static int meson_ee_pwrc_on(struct generic_pm_domain *domain)
 	if (ret)
 		return ret;
 
-	return clk_bulk_prepare_enable(pwrc_domain->num_clks,
-				       pwrc_domain->clks);
+	ret = clk_bulk_prepare_enable(pwrc_domain->num_clks,
+				      pwrc_domain->clks);
+	if (ret)
+		return ret;
+
+	pwrc_domain->enabled = true;
+
+	return 0;
 }
 
 static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
@@ -434,33 +456,11 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
 	dom->base.power_on = meson_ee_pwrc_on;
 	dom->base.power_off = meson_ee_pwrc_off;
 
-	/*
-         * TOFIX: This is a special case for the VPU power domain, which can
-	 * be enabled previously by the bootloader. In this case the VPU
-         * pipeline may be functional but no driver maybe never attach
-         * to this power domain, and if the domain is disabled it could
-         * cause system errors. This is why the pm_domain_always_on_gov
-         * is used here.
-         * For the same reason, the clocks should be enabled in case
-         * we need to power the domain off, otherwise the internal clocks
-         * prepare/enable counters won't be in sync.
-         */
-	if (dom->num_clks && dom->desc.get_power && !dom->desc.get_power(dom)) {
-		ret = clk_bulk_prepare_enable(dom->num_clks, dom->clks);
-		if (ret)
-			return ret;
-
-		dom->base.flags = GENPD_FLAG_ALWAYS_ON;
-		ret = pm_genpd_init(&dom->base, NULL, false);
-		if (ret)
-			return ret;
-	} else {
-		ret = pm_genpd_init(&dom->base, NULL,
-				    (dom->desc.get_power ?
-				     dom->desc.get_power(dom) : true));
-		if (ret)
-			return ret;
-	}
+	ret = pm_genpd_init(&dom->base, NULL,
+			    (dom->desc.get_power ?
+			     dom->desc.get_power(dom) : true));
+	if (ret)
+		return ret;
 
 	return 0;
 }
@@ -528,19 +528,6 @@ static int meson_ee_pwrc_probe(struct platform_device *pdev)
 	return of_genpd_add_provider_onecell(pdev->dev.of_node, &pwrc->xlate);
 }
 
-static void meson_ee_pwrc_shutdown(struct platform_device *pdev)
-{
-	struct meson_ee_pwrc *pwrc = platform_get_drvdata(pdev);
-	int i;
-
-	for (i = 0 ; i < pwrc->xlate.num_domains ; ++i) {
-		struct meson_ee_pwrc_domain *dom = &pwrc->domains[i];
-
-		if (dom->desc.get_power && !dom->desc.get_power(dom))
-			meson_ee_pwrc_off(&dom->base);
-	}
-}
-
 static struct meson_ee_pwrc_domain_data meson_ee_g12a_pwrc_data = {
 	.count = ARRAY_SIZE(g12a_pwrc_domains),
 	.domains = g12a_pwrc_domains,
@@ -606,7 +593,6 @@ MODULE_DEVICE_TABLE(of, meson_ee_pwrc_match_table);
 
 static struct platform_driver meson_ee_pwrc_driver = {
 	.probe = meson_ee_pwrc_probe,
-	.shutdown = meson_ee_pwrc_shutdown,
 	.driver = {
 		.name		= "meson_ee_pwrc",
 		.of_match_table	= meson_ee_pwrc_match_table,
-- 
2.31.1



From martin.blumenstingl at googlemail.com  Thu Apr 29 21:50:31 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 29 Apr 2021 22:50:31 +0200
Subject: [PATCH 2/3] dt-bindings: arm: amlogic: add Banana PI M5 bindings
In-Reply-To: <20210429170404.3616111-3-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
 <20210429170404.3616111-3-narmstrong@baylibre.com>
Message-ID: <CAFBinCBJvW2i2P98d_0d-ZJq2=Koh4vaQXUW=Sb94mEq_KWt2g@mail.gmail.com>

On Thu, Apr 29, 2021 at 7:04 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
>
> Add bindings for the Banana PI M5 board.
>
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>


From julia.lawall at inria.fr  Thu Apr 29 21:50:46 2021
From: julia.lawall at inria.fr (Julia Lawall)
Date: Thu, 29 Apr 2021 22:50:46 +0200 (CEST)
Subject: [PATCH] arm64: cpufeatures: use min and max
Message-ID: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>

From: kernel test robot <lkp at intel.com>

Use min and max to make the effect more clear.

Generated by: scripts/coccinelle/misc/minmax.cocci

Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
CC: Denis Efremov <efremov at linux.com>
Reported-by: kernel test robot <lkp at intel.com>
Signed-off-by: kernel test robot <lkp at intel.com>
Signed-off-by: Julia Lawall <julia.lawall at inria.fr>
---

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git for-5.12
head:   44e793b89bcfe586730f4c6ce3c66174dc07cb37
commit: 8636e3295ce33515c50ef728f0ff3800d97f9f44 [1/5] coccinelle: misc: add minmax script
:::::: branch date: 6 days ago
:::::: commit date: 6 weeks ago

 cpufeature.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -695,14 +695,14 @@ static s64 arm64_ftr_safe_value(const st
 		ret = ftrp->safe_val;
 		break;
 	case FTR_LOWER_SAFE:
-		ret = new < cur ? new : cur;
+		ret = min(new, cur);
 		break;
 	case FTR_HIGHER_OR_ZERO_SAFE:
 		if (!cur || !new)
 			break;
 		fallthrough;
 	case FTR_HIGHER_SAFE:
-		ret = new > cur ? new : cur;
+		ret = max(new, cur);
 		break;
 	default:
 		BUG();


From stefan at agner.ch  Thu Apr 29 22:08:56 2021
From: stefan at agner.ch (Stefan Agner)
Date: Thu, 29 Apr 2021 23:08:56 +0200
Subject: [PATCH RFC] soc: amlogic: meson-ee-pwrc: Drop the .shutdown
 callback from the driver
In-Reply-To: <20210429203723.1177082-1-martin.blumenstingl@googlemail.com>
References: <20210429203723.1177082-1-martin.blumenstingl@googlemail.com>
Message-ID: <d8c3d21b679fd8e6e1bedafc7406c42e@agner.ch>

On 2021-04-29 22:37, Martin Blumenstingl wrote:
> Stefan reports that rebooting his ODROID-N2+ (using a G12B SoC) results
> in the board hanging. His kernel config uses:
>   CONFIG_MESON_EE_PM_DOMAINS=y
>   CONFIG_DRM_MESON=m
> 
> He reports that his kernel config results in the DRM driver's .shutdown
> callback to be executed after the power domain driver's .shutdown
> callback. That's problematic because meson_ee_pwrc_shutdown disables the
> clock which are used by the VPU IP. This causes the board to hang.
> 
> Further he reports that changing from CONFIG_DRM_MESON=m to
> CONFIG_DRM_MESON=y reverses the order in which the DRM and power domain
> driver's shutdown functions are executed, making the reboot successful.
> 
> The reason why we use meson_ee_pwrc_shutdown is because of the VPU power
> domain (which is causing the problem described above). It can be left
> enabled by u-boot. According to the original TOFIX comment in
> meson_ee_pwrc_init_domain we need to be careful because disabling the
> power domain could "cause system errors". As a workaround the clocks
> are manually enabled in meson_ee_pwrc_init_domain and the power domain
> is marked as GENPD_FLAG_ALWAYS_ON (so it can never be turned off).
> 
> Experimenting has shown that the power domain itself can be disabled as
> long as we keep the clocks enabled if u-boot enabled the power domain
> but we don't have any driver enabled for the VPU (CONFIG_DRM_MESON=n).
> 
> Keeping the clocks enabled is the responsibility of the CCF drivers, not
> the power domain driver. Even better: this is already covered as all
> gates in the VPU and VAPB tree on GX an G12 SoCs have the
> CLK_IGNORE_UNUSED flag set, meaning: if the bootloader has previously
> enabled the clock we're not touching it until a driver explicitly asks
> to enable (and then disable) it. In case of CONFIG_DRM_MESON=n we're
> never calling meson_ee_pwrc_on, meaning that we always keep the state of
> the clocks as set by u-boot.
> 
> The original TOFIX comment also mentioned that we need to make sure not
> to mess up the clock's prepare/enable ref-counters. This is the only
> requirement that's left for the meson-ee-pwrc driver that needs to be
> managed for the VPU power domain.
> 
> Three steps can improve this situation:
> - Don't prepare and enable the clocks (just to fix the ref-counting) in
>   meson_ee_pwrc_init_domain if u-boot left that power domain enabled.
>   Instead, remember if the clocks are enabled in meson_ee_pwrc_{on,off}
>   and only disable them if we have previously turned them on ourselves.
> - Drop GENPD_FLAG_ALWAYS_ON as we can always manage the state of the VPU
>   power domain if both the power domain controller and DRM driver are
>   enabled (=m or =y). If the power domain driver is enabled but the DRM
>   driver is disabled we can still use meson_ee_pwrc_off because it's not
>   trying to disable the clocks anymore
> - Drop meson_ee_pwrc_shutdown as it's the responsibility of the genpd
>   framework to call meson_ee_pwrc_off when needed (either when a power
>   domain is being disabled - regardless of whether it's was used by a
>   driver before or not). Now there's also no more shutdown callback
>   ordering dependency between the power domain driver and other drivers
>   anymore.
> 
> Fixes: eef3c2ba0a42a6 ("soc: amlogic: Add support for Everything-Else
> power domains controller")
> Reported-by: Stefan Agner <stefan at agner.ch>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>

FWIW, I successfully tested this change with CONFIG_DRM_MESON=m and
CONFIG_DRM_MESON=y each with a couple of reboots without any hang.

Tested-by: Stefan Agner <stefan at agner.ch>

Thanks Martin for help debugging and working on this patch!

--
Stefan

> ---
> Neil, I would like you to specifically review (and re-test) the original
> TOFIX part. I *believe* that I understand the original problem and hope
> that my approach also works in that scenario, but I am not 100% sure.
> 
> Kevin, as you're my go-to genpd expert I am also asking you to review
> this to point out any issues you see.
> 
> 
>  drivers/soc/amlogic/meson-ee-pwrc.c | 76 ++++++++++++-----------------
>  1 file changed, 31 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c
> b/drivers/soc/amlogic/meson-ee-pwrc.c
> index 50bf5d2b828b..534c33ba31ce 100644
> --- a/drivers/soc/amlogic/meson-ee-pwrc.c
> +++ b/drivers/soc/amlogic/meson-ee-pwrc.c
> @@ -353,10 +353,26 @@ static int meson_ee_pwrc_off(struct
> generic_pm_domain *domain)
>  
>  	if (pwrc_domain->num_clks) {
>  		msleep(20);
> -		clk_bulk_disable_unprepare(pwrc_domain->num_clks,
> -					   pwrc_domain->clks);
> +
> +		/*
> +		 * We are only allowed to turn off the clocks here if we
> +		 * have previously enabled them ourselves. In other words:
> +		 * for an "unused" power domain (which is not used by any
> +		 * power domain consumer) we have not enabled the clocks
> +		 * previously so we keep them in the state they are.
> +		 * This is relevant for the VPU power domain which may
> +		 * have been enabled by u-boot. If the display driver in
> +		 * Linux is disabled then we need to keep the clocks in
> +		 * the state as u-boot set them, otherwise the board will
> +		 * hang.
> +		 */
> +		if (pwrc_domain->enabled)
> +			clk_bulk_disable_unprepare(pwrc_domain->num_clks,
> +						   pwrc_domain->clks);
>  	}
>  
> +	pwrc_domain->enabled = false;
> +
>  	return 0;
>  }
>  
> @@ -392,8 +408,14 @@ static int meson_ee_pwrc_on(struct
> generic_pm_domain *domain)
>  	if (ret)
>  		return ret;
>  
> -	return clk_bulk_prepare_enable(pwrc_domain->num_clks,
> -				       pwrc_domain->clks);
> +	ret = clk_bulk_prepare_enable(pwrc_domain->num_clks,
> +				      pwrc_domain->clks);
> +	if (ret)
> +		return ret;
> +
> +	pwrc_domain->enabled = true;
> +
> +	return 0;
>  }
>  
>  static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
> @@ -434,33 +456,11 @@ static int meson_ee_pwrc_init_domain(struct
> platform_device *pdev,
>  	dom->base.power_on = meson_ee_pwrc_on;
>  	dom->base.power_off = meson_ee_pwrc_off;
>  
> -	/*
> -         * TOFIX: This is a special case for the VPU power domain, which can
> -	 * be enabled previously by the bootloader. In this case the VPU
> -         * pipeline may be functional but no driver maybe never attach
> -         * to this power domain, and if the domain is disabled it could
> -         * cause system errors. This is why the pm_domain_always_on_gov
> -         * is used here.
> -         * For the same reason, the clocks should be enabled in case
> -         * we need to power the domain off, otherwise the internal clocks
> -         * prepare/enable counters won't be in sync.
> -         */
> -	if (dom->num_clks && dom->desc.get_power && !dom->desc.get_power(dom)) {
> -		ret = clk_bulk_prepare_enable(dom->num_clks, dom->clks);
> -		if (ret)
> -			return ret;
> -
> -		dom->base.flags = GENPD_FLAG_ALWAYS_ON;
> -		ret = pm_genpd_init(&dom->base, NULL, false);
> -		if (ret)
> -			return ret;
> -	} else {
> -		ret = pm_genpd_init(&dom->base, NULL,
> -				    (dom->desc.get_power ?
> -				     dom->desc.get_power(dom) : true));
> -		if (ret)
> -			return ret;
> -	}
> +	ret = pm_genpd_init(&dom->base, NULL,
> +			    (dom->desc.get_power ?
> +			     dom->desc.get_power(dom) : true));
> +	if (ret)
> +		return ret;
>  
>  	return 0;
>  }
> @@ -528,19 +528,6 @@ static int meson_ee_pwrc_probe(struct
> platform_device *pdev)
>  	return of_genpd_add_provider_onecell(pdev->dev.of_node, &pwrc->xlate);
>  }
>  
> -static void meson_ee_pwrc_shutdown(struct platform_device *pdev)
> -{
> -	struct meson_ee_pwrc *pwrc = platform_get_drvdata(pdev);
> -	int i;
> -
> -	for (i = 0 ; i < pwrc->xlate.num_domains ; ++i) {
> -		struct meson_ee_pwrc_domain *dom = &pwrc->domains[i];
> -
> -		if (dom->desc.get_power && !dom->desc.get_power(dom))
> -			meson_ee_pwrc_off(&dom->base);
> -	}
> -}
> -
>  static struct meson_ee_pwrc_domain_data meson_ee_g12a_pwrc_data = {
>  	.count = ARRAY_SIZE(g12a_pwrc_domains),
>  	.domains = g12a_pwrc_domains,
> @@ -606,7 +593,6 @@ MODULE_DEVICE_TABLE(of, meson_ee_pwrc_match_table);
>  
>  static struct platform_driver meson_ee_pwrc_driver = {
>  	.probe = meson_ee_pwrc_probe,
> -	.shutdown = meson_ee_pwrc_shutdown,
>  	.driver = {
>  		.name		= "meson_ee_pwrc",
>  		.of_match_table	= meson_ee_pwrc_match_table,


From aford173 at gmail.com  Thu Apr 29 22:16:19 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:19 -0500
Subject: [PATCH V3 0/5] soc: imx8mn:  Add gpcv2, USB and GPU 
Message-ID: <20210429211625.1835702-1-aford173@gmail.com>

With the updates to the GPCv2 driver for i.MX8M Mini [1], much of this
can be applied to work with the i.MX8M Nano.  With the added
GPCv2 domains, additional functions like USB and GPU are available.
This series does not utilize any power domains requiring the blk-ctl.

[1] -  https://lkml.org/lkml/2021/4/29/72

Adam Ford (5):
  dt-bindings: add defines for i.MX8MN power domains
  soc: imx: gpcv2: add support for i.MX8MN power domains
  arm64: dts: imx8mn: add GPC node and power domains
  arm64: dts: imx8mn: Add power-domain reference in USB controller
  arm64: dts: imx8mn: Add GPU node

 .../bindings/power/fsl,imx-gpcv2.yaml         |  1 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi     | 62 +++++++++++++
 drivers/soc/imx/gpcv2.c                       | 93 +++++++++++++++++++
 include/dt-bindings/power/imx8mn-power.h      | 15 +++
 4 files changed, 171 insertions(+)
 create mode 100644 include/dt-bindings/power/imx8mn-power.h

-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 22:16:22 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:22 -0500
Subject: [PATCH V3 3/5] arm64: dts: imx8mn: add GPC node and power domains
In-Reply-To: <20210429211625.1835702-1-aford173@gmail.com>
References: <20210429211625.1835702-1-aford173@gmail.com>
Message-ID: <20210429211625.1835702-4-aford173@gmail.com>

This adds the DT nodes to describe the power domains available on the
i.MX8MN. There are more power domains, but the displaymix and mipi
power domains need a separate clock block controller which not yet
available, so this limits it to the HSIO, OTG and GPU domains.

Signed-off-by: Adam Ford <aford173 at gmail.com>
---
V3:  Rebase on series starting https://lkml.org/lkml/2021/4/29/72
V2:  Fix missing includes
     Remove interrupt controller flag
     Remove domains which interact with blk-ctl

Signed-off-by: Adam Ford <aford173 at gmail.com>

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 16ea50089567..609294329c7b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -4,6 +4,8 @@
  */
 
 #include <dt-bindings/clock/imx8mn-clock.h>
+#include <dt-bindings/power/imx8mn-power.h>
+#include <dt-bindings/reset/imx8mq-reset.h>
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -612,6 +614,40 @@ src: reset-controller at 30390000 {
 				interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 				#reset-cells = <1>;
 			};
+
+			gpc: gpc at 303a0000 {
+				compatible = "fsl,imx8mn-gpc";
+				reg = <0x303a0000 0x10000>;
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+
+				pgc {
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					pgc_hsiomix: power-domain at 0 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MN_POWER_DOMAIN_HSIOMIX>;
+						clocks = <&clk IMX8MN_CLK_USB_BUS>;
+					};
+
+					pgc_otg1: power-domain at 1 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MN_POWER_DOMAIN_OTG1>;
+						power-domains = <&pgc_hsiomix>;
+					};
+
+					pgc_gpumix: power-domain at 2 {
+						#power-domain-cells = <0>;
+						reg = <IMX8MN_POWER_DOMAIN_GPUMIX>;
+						clocks = <&clk IMX8MN_CLK_GPU_CORE_ROOT>,
+							 <&clk IMX8MN_CLK_GPU_SHADER_DIV>,
+							 <&clk IMX8MN_CLK_GPU_BUS_ROOT>,
+							 <&clk IMX8MN_CLK_GPU_AHB>;
+						resets = <&src IMX8MQ_RESET_GPU_RESET>;
+					};
+				};
+			};
 		};
 
 		aips2: bus at 30400000 {
-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 22:16:23 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:23 -0500
Subject: [PATCH V3 4/5] arm64: dts: imx8mn: Add power-domain reference in USB
 controller
In-Reply-To: <20210429211625.1835702-1-aford173@gmail.com>
References: <20210429211625.1835702-1-aford173@gmail.com>
Message-ID: <20210429211625.1835702-5-aford173@gmail.com>

The USB OTG controller cannot be used until the power-domain is enabled
unless it was started in the bootloader.

Adding the power-domain reference to the OTG node allows the OTG
controller to operate.

Signed-off-by: Adam Ford <aford173 at gmail.com>
---
V3:  Rebase on series starting https://lkml.org/lkml/2021/4/29/72
V2:  No change

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 609294329c7b..a2ca25aa8eb6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -1000,6 +1000,7 @@ usbotg1: usb at 32e40000 {
 				assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_500M>;
 				fsl,usbphy = <&usbphynop1>;
 				fsl,usbmisc = <&usbmisc1 0>;
+				power-domains = <&pgc_otg1>;
 				status = "disabled";
 			};
 
-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 22:16:21 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:21 -0500
Subject: [PATCH V3 2/5] soc: imx: gpcv2: add support for i.MX8MN power domains
In-Reply-To: <20210429211625.1835702-1-aford173@gmail.com>
References: <20210429211625.1835702-1-aford173@gmail.com>
Message-ID: <20210429211625.1835702-3-aford173@gmail.com>

This adds support for the power domains founds on i.MX8MN. The Nano
has fewer domains than the Mini, and the access to some of these domains
is different than that of the Mini, the Mini power domains cannot be
reused.

Signed-off-by: Adam Ford <aford173 at gmail.com>
Acked-by: Krzysztof Kozlowski <krzk at kernel.org>
---
V3:  Rebase on series starting https://lkml.org/lkml/2021/4/29/72
V2: No change

diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index 04564017bfe9..6c93551b8729 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -20,6 +20,7 @@
 #include <dt-bindings/power/imx7-power.h>
 #include <dt-bindings/power/imx8mq-power.h>
 #include <dt-bindings/power/imx8mm-power.h>
+#include <dt-bindings/power/imx8mn-power.h>
 
 #define GPC_LPCR_A_CORE_BSC			0x000
 
@@ -58,6 +59,12 @@
 #define IMX8MM_PCIE_A53_DOMAIN			BIT(3)
 #define IMX8MM_MIPI_A53_DOMAIN			BIT(2)
 
+#define IMX8MN_DISPMIX_A53_DOMAIN		BIT(12)
+#define IMX8MN_GPUMIX_A53_DOMAIN		BIT(9)
+#define IMX8MN_DDR1_A53_DOMAIN		BIT(7)
+#define IMX8MN_OTG1_A53_DOMAIN		BIT(4)
+#define IMX8MN_MIPI_A53_DOMAIN		BIT(2)
+
 #define GPC_PU_PGC_SW_PUP_REQ		0x0f8
 #define GPC_PU_PGC_SW_PDN_REQ		0x104
 
@@ -94,6 +101,12 @@
 #define IMX8MM_PCIE_SW_Pxx_REQ			BIT(1)
 #define IMX8MM_MIPI_SW_Pxx_REQ			BIT(0)
 
+#define IMX8MN_DISPMIX_SW_Pxx_REQ		BIT(10)
+#define IMX8MN_GPUMIX_SW_Pxx_REQ		BIT(7)
+#define IMX8MN_DDR1_SW_Pxx_REQ		BIT(5)
+#define IMX8MN_OTG1_SW_Pxx_REQ		BIT(2)
+#define IMX8MN_MIPI_SW_Pxx_REQ		BIT(0)
+
 #define GPC_M4_PU_PDN_FLG		0x1bc
 
 #define GPC_PU_PWRHSK			0x1fc
@@ -116,6 +129,14 @@
 #define IMX8MM_VPUMIX_HSK_PWRDNREQN		BIT(8)
 #define IMX8MM_DISPMIX_HSK_PWRDNREQN		BIT(7)
 #define IMX8MM_HSIO_HSK_PWRDNREQN		(BIT(5) | BIT(6))
+
+#define IMX8MN_GPUMIX_HSK_PWRDNACKN		(BIT(29) | BIT(27))
+#define IMX8MN_DISPMIX_HSK_PWRDNACKN		BIT(25)
+#define IMX8MN_HSIO_HSK_PWRDNACKN		BIT(23)
+#define IMX8MN_GPUMIX_HSK_PWRDNREQN		(BIT(11) | BIT(9))
+#define IMX8MN_DISPMIX_HSK_PWRDNREQN		BIT(7)
+#define IMX8MN_HSIO_HSK_PWRDNREQN		BIT(5)
+
 /*
  * The PGC offset values in Reference Manual
  * (Rev. 1, 01/2018 and the older ones) GPC chapter's
@@ -152,6 +173,12 @@
 #define IMX8MM_PGC_VPUG2		28
 #define IMX8MM_PGC_VPUH1		29
 
+#define IMX8MN_PGC_MIPI		16
+#define IMX8MN_PGC_OTG1		18
+#define IMX8MN_PGC_DDR1		21
+#define IMX8MN_PGC_GPUMIX		23
+#define IMX8MN_PGC_DISPMIX		26
+
 #define GPC_PGC_CTRL(n)			(0x800 + (n) * 0x40)
 #define GPC_PGC_SR(n)			(GPC_PGC_CTRL(n) + 0xc)
 
@@ -752,6 +779,71 @@ static const struct imx_pgc_domain_data imx8mm_pgc_domain_data = {
 	.reg_access_table = &imx8mm_access_table,
 };
 
+static const struct imx_pgc_domain imx8mn_pgc_domains[] = {
+	[IMX8MN_POWER_DOMAIN_HSIOMIX] = {
+		.genpd = {
+			.name = "hsiomix",
+		},
+		.bits  = {
+			.pxx = 0, /* no power sequence control */
+			.map = 0, /* no power sequence control */
+			.hskreq = IMX8MN_HSIO_HSK_PWRDNREQN,
+			.hskack = IMX8MN_HSIO_HSK_PWRDNACKN,
+		},
+	},
+
+	[IMX8MN_POWER_DOMAIN_OTG1] = {
+		.genpd = {
+			.name = "usb-otg1",
+		},
+		.bits  = {
+			.pxx = IMX8MN_OTG1_SW_Pxx_REQ,
+			.map = IMX8MN_OTG1_A53_DOMAIN,
+		},
+		.pgc   = IMX8MN_PGC_OTG1,
+	},
+
+	[IMX8MN_POWER_DOMAIN_GPUMIX] = {
+		.genpd = {
+			.name = "gpumix",
+		},
+		.bits  = {
+			.pxx = IMX8MN_GPUMIX_SW_Pxx_REQ,
+			.map = IMX8MN_GPUMIX_A53_DOMAIN,
+			.hskreq = IMX8MN_GPUMIX_HSK_PWRDNREQN,
+			.hskack = IMX8MN_GPUMIX_HSK_PWRDNACKN,
+		},
+		.pgc   = IMX8MN_PGC_GPUMIX,
+	},
+};
+
+static const struct regmap_range imx8mn_yes_ranges[] = {
+	regmap_reg_range(GPC_LPCR_A_CORE_BSC,
+			 GPC_PU_PWRHSK),
+	regmap_reg_range(GPC_PGC_CTRL(IMX8MN_PGC_MIPI),
+			 GPC_PGC_SR(IMX8MN_PGC_MIPI)),
+	regmap_reg_range(GPC_PGC_CTRL(IMX8MN_PGC_OTG1),
+			 GPC_PGC_SR(IMX8MN_PGC_OTG1)),
+	regmap_reg_range(GPC_PGC_CTRL(IMX8MN_PGC_DDR1),
+			 GPC_PGC_SR(IMX8MN_PGC_DDR1)),
+	regmap_reg_range(GPC_PGC_CTRL(IMX8MN_PGC_GPUMIX),
+			 GPC_PGC_SR(IMX8MN_PGC_GPUMIX)),
+	regmap_reg_range(GPC_PGC_CTRL(IMX8MN_PGC_DISPMIX),
+			 GPC_PGC_SR(IMX8MN_PGC_DISPMIX)),
+};
+
+static const struct regmap_access_table imx8mn_access_table = {
+	.yes_ranges	= imx8mn_yes_ranges,
+	.n_yes_ranges	= ARRAY_SIZE(imx8mn_yes_ranges),
+};
+
+static const struct imx_pgc_domain_data imx8mn_pgc_domain_data = {
+	.domains = imx8mn_pgc_domains,
+	.domains_num = ARRAY_SIZE(imx8mn_pgc_domains),
+	.reg_access_table = &imx8mn_access_table,
+};
+
+
 static int imx_pgc_domain_probe(struct platform_device *pdev)
 {
 	struct imx_pgc_domain *domain = pdev->dev.platform_data;
@@ -940,6 +1032,7 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
 static const struct of_device_id imx_gpcv2_dt_ids[] = {
 	{ .compatible = "fsl,imx7d-gpc", .data = &imx7_pgc_domain_data, },
 	{ .compatible = "fsl,imx8mm-gpc", .data = &imx8mm_pgc_domain_data, },
+	{ .compatible = "fsl,imx8mn-gpc", .data = &imx8mn_pgc_domain_data, },
 	{ .compatible = "fsl,imx8mq-gpc", .data = &imx8m_pgc_domain_data, },
 	{ }
 };
-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 22:16:20 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:20 -0500
Subject: [PATCH V3 1/5] dt-bindings: add defines for i.MX8MN power domains
In-Reply-To: <20210429211625.1835702-1-aford173@gmail.com>
References: <20210429211625.1835702-1-aford173@gmail.com>
Message-ID: <20210429211625.1835702-2-aford173@gmail.com>

The i.MX8M Nano has a similar power domain controller to that of the
mini, but it isn't fully compatible, so it needs a separate binding
and power domain tables.

Add the bindings and tables.

Signed-off-by: Adam Ford <aford173 at gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk at kernel.org>
Acked-by: Rob Herring <robh at kernel.org>
---
V3:  Rebase on series starting https://lkml.org/lkml/2021/4/29/72
V2:  No change

diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
index d3539569d45f..a87c44c15ace 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -25,6 +25,7 @@ properties:
   compatible:
     enum:
       - fsl,imx7d-gpc
+      - fsl,imx8mn-gpc
       - fsl,imx8mq-gpc
       - fsl,imx8mm-gpc
 
diff --git a/include/dt-bindings/power/imx8mn-power.h b/include/dt-bindings/power/imx8mn-power.h
new file mode 100644
index 000000000000..102ee85a9b62
--- /dev/null
+++ b/include/dt-bindings/power/imx8mn-power.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ *  Copyright (C) 2020 Compass Electronics Group, LLC
+ */
+
+#ifndef __DT_BINDINGS_IMX8MN_POWER_H__
+#define __DT_BINDINGS_IMX8MN_POWER_H__
+
+#define IMX8MN_POWER_DOMAIN_HSIOMIX	0
+#define IMX8MN_POWER_DOMAIN_OTG1	1
+#define IMX8MN_POWER_DOMAIN_GPUMIX	2
+#define IMX8MN_POWER_DOMAIN_DISPMIX	3
+#define IMX8MN_POWER_DOMAIN_MIPI	4
+
+#endif
-- 
2.25.1



From aford173 at gmail.com  Thu Apr 29 22:16:24 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 16:16:24 -0500
Subject: [PATCH V3 5/5] arm64: dts: imx8mn: Add GPU node
In-Reply-To: <20210429211625.1835702-1-aford173@gmail.com>
References: <20210429211625.1835702-1-aford173@gmail.com>
Message-ID: <20210429211625.1835702-6-aford173@gmail.com>

According to the documentation from NXP, the i.MX8M Nano has a
Vivante GC7000 Ultra Lite as its GPU core.

With this patch, the Etnaviv driver presents the GPU as:
   etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6203

The stock operating voltage for the i.MX8M Nano is .85V which means
the GPU needs to run at 400MHz.  For boards where the operating
voltage is higher, this can be increased.

Signed-off-by: Adam Ford <aford173 at gmail.com>
---
V3:  Rebase on series starting https://lkml.org/lkml/2021/4/29/72
V2:  Move into this series
     Update clocking description

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index a2ca25aa8eb6..07a8ff58d44c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -1040,6 +1040,31 @@ gpmi: nand-controller at 33002000 {
 			status = "disabled";
 		};
 
+		gpu: gpu at 38000000 {
+			compatible = "vivante,gc";
+			reg = <0x38000000 0x8000>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk IMX8MN_CLK_GPU_AHB>,
+				<&clk IMX8MN_CLK_GPU_BUS_ROOT>,
+				<&clk IMX8MN_CLK_GPU_CORE_ROOT>,
+				<&clk IMX8MN_CLK_GPU_SHADER_DIV>;
+			clock-names = "reg", "bus", "core", "shader";
+			assigned-clocks = <&clk IMX8MN_CLK_GPU_CORE_SRC>,
+					  <&clk IMX8MN_CLK_GPU_SHADER_SRC>,
+					  <&clk IMX8MN_CLK_GPU_AXI>,
+					  <&clk IMX8MN_CLK_GPU_AHB>,
+					  <&clk IMX8MN_GPU_PLL>,
+					  <&clk IMX8MN_CLK_GPU_CORE_DIV>,
+					  <&clk IMX8MN_CLK_GPU_SHADER_DIV>;
+			assigned-clock-parents = <&clk IMX8MN_GPU_PLL_OUT>,
+						  <&clk IMX8MN_GPU_PLL_OUT>,
+						  <&clk IMX8MN_SYS_PLL1_800M>,
+						  <&clk IMX8MN_SYS_PLL1_800M>;
+			assigned-clock-rates = <0>, <0>, <800000000>, <400000000>, <1200000000>,
+				<400000000>, <400000000>;
+			power-domains = <&pgc_gpumix>;
+		};
+
 		gic: interrupt-controller at 38800000 {
 			compatible = "arm,gic-v3";
 			reg = <0x38800000 0x10000>,
-- 
2.25.1



From robh at kernel.org  Thu Apr 29 22:24:13 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 29 Apr 2021 16:24:13 -0500
Subject: [PATCH v4 07/10] dt-bindings: soc: rockchip: Convert grf.txt to
 YAML
In-Reply-To: <20210429081321.17855-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081321.17855-1-cl@rock-chips.com>
Message-ID: <20210429212413.GA1794356@robh.at.kernel.org>

On Thu, Apr 29, 2021 at 04:13:21PM +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> Current dts files with 'grf' nodes are manually verified. In order to
> automate this process grf.txt has to be converted to YAML.
> 
> Add new descriptions for:
> "rockchip,rk3568-grf", "syscon", "simple-mfd"
> "rockchip,rk3568-pmugrf", "syscon", "simple-mfd"
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>  .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
>  2 files changed, 60 insertions(+), 61 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> deleted file mode 100644
> index f96511aa3897..000000000000
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -* Rockchip General Register Files (GRF)
> -
> -The general register file will be used to do static set by software, which
> -is composed of many registers for system control.
> -
> -From RK3368 SoCs, the GRF is divided into two sections,
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- PMUGRF, used for always on system
> -
> -On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
> -
> -ON RK3308 SoC, the GRF is divided into four sections:
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- DETECTGRF, used for audio codec system,
> -- COREGRF, used for pvtm,
> -
> -Required Properties:
> -
> -- compatible: GRF should be one of the following:
> -   - "rockchip,px30-grf", "syscon": for px30
> -   - "rockchip,rk3036-grf", "syscon": for rk3036
> -   - "rockchip,rk3066-grf", "syscon": for rk3066
> -   - "rockchip,rk3188-grf", "syscon": for rk3188
> -   - "rockchip,rk3228-grf", "syscon": for rk3228
> -   - "rockchip,rk3288-grf", "syscon": for rk3288
> -   - "rockchip,rk3308-grf", "syscon": for rk3308
> -   - "rockchip,rk3328-grf", "syscon": for rk3328
> -   - "rockchip,rk3368-grf", "syscon": for rk3368
> -   - "rockchip,rk3399-grf", "syscon": for rk3399
> -   - "rockchip,rv1108-grf", "syscon": for rv1108
> -- compatible: DETECTGRF should be one of the following:
> -   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
> -- compatilbe: COREGRF should be one of the following:
> -   - "rockchip,rk3308-core-grf", "syscon": for rk3308
> -- compatible: PMUGRF should be one of the following:
> -   - "rockchip,px30-pmugrf", "syscon": for px30
> -   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> -   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> -- compatible: SGRF should be one of the following:
> -   - "rockchip,rk3288-sgrf", "syscon": for rk3288
> -- compatible: USB2PHYGRF should be one of the following:
> -   - "rockchip,px30-usb2phy-grf", "syscon": for px30
> -   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> -- compatible: USBGRF should be one of the following:
> -   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> -
> -Example: GRF and PMUGRF of RK3399 SoCs
> -
> -	pmugrf: syscon at ff320000 {
> -		compatible = "rockchip,rk3399-pmugrf", "syscon";
> -		reg = <0x0 0xff320000 0x0 0x1000>;
> -	};
> -
> -	grf: syscon at ff770000 {
> -		compatible = "rockchip,rk3399-grf", "syscon";
> -		reg = <0x0 0xff770000 0x0 0x10000>;
> -	};
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> new file mode 100644
> index 000000000000..93231b95554b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip General Register Files
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +
> +properties:
> +  compatible:
> +    - items:

The '-' is the source of your error.

> +        - enum:
> +            - rockchip,px30-grf
> +            - rockchip,px30-pmugrf
> +            - rockchip,px30-usb2phy-grf
> +            - rockchip,rk3036-grf
> +            - rockchip,rk3066-grf
> +            - rockchip,rk3188-grf
> +            - rockchip,rk3228-grf
> +            - rockchip,rk3288-grf
> +            - rockchip,rk3288-sgrf
> +            - rockchip,rk3308-core-grf
> +            - rockchip,rk3308-detect-grf
> +            - rockchip,rk3308-grf
> +            - rockchip,rk3328-grf
> +            - rockchip,rk3328-usb2phy-grf
> +            - rockchip,rk3368-grf
> +            - rockchip,rk3368-pmugrf
> +            - rockchip,rk3399-grf
> +            - rockchip,rk3399-pmugrf
> +            - rockchip,rk3568-grf
> +            - rockchip,rk3568-pmugrf
> +            - rockchip,rv1108-grf
> +            - rockchip,rv1108-usbgrf
> +        - const: syscon
> +        - const: simple-mfd

'simple-mfd' was not in the old binding. That implies you have child 
nodes, and if so, they need to be documented. I imagine that will mean 
splitting this into multiple schemas if that's the case.

> +
> +  reg:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    pmugrf: syscon at ff320000 {
> +       compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
> +       reg = <0xff320000 0x1000>;
> +    };
> +
> +    grf: syscon at ff770000 {
> +       compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> +       reg = <0xff770000 0x10000>;
> +    };
> -- 
> 2.17.1
> 
> 
> 


From martin.blumenstingl at googlemail.com  Thu Apr 29 22:30:58 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 29 Apr 2021 23:30:58 +0200
Subject: [PATCH 3/3] arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts
In-Reply-To: <20210429170404.3616111-4-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
 <20210429170404.3616111-4-narmstrong@baylibre.com>
Message-ID: <CAFBinCDQeTU0ss=oNmjX78MPyNZmmCt-haojNNcQqkjJUmJYKQ@mail.gmail.com>

Hi Neil,

thanks for adding support for the BPI-M5!
I had this on my TODO-list for a long time but didn't have enough time
so far. so it's great to see this patch now :-)

On Thu, Apr 29, 2021 at 7:04 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
[...]
> +       adc_keys {
> +               compatible = "adc-keys";
> +               io-channels = <&saradc 2>;
> +               io-channel-names = "buttons";
> +               keyup-threshold-microvolt = <1800000>;
> +
> +               button-onoff {
maybe just "key" (as you used below for SW1)?

> +                       label = "SW3";
> +                       linux,code = <BTN_3>;
> +                       press-threshold-microvolt = <1700000>;
> +               };
> +       };

> +       /* TOFIX: handle CVBS_DET on SARADC channel 0 */
it's great to see that after many years at least some boards finally
can detect whether the CVBS connector is plugged it

> +       memory at 0 {
> +               device_type = "memory";
> +               reg = <0x0 0x0 0x0 0x40000000>;
> +       };
note to self: u-boot will update this from 1GiB to 4GiB

> +       flash_1v8: regulator-flash_1v8 {
> +               compatible = "regulator-fixed";
> +               regulator-name = "FLASH_1V8";
BPI-M5-SCH-V10-Release.pdf schematics are calling this EMMC_1V8. I
suggest to use that name so it's easier to compare this with the
schematics in the future

> +               regulator-min-microvolt = <1800000>;
> +               regulator-max-microvolt = <1800000>;
> +               vin-supply = <&vddao_3v3>;
> +               regulator-always-on;
> +       };
> +
> +       dc_in: regulator-dc_in {
> +               compatible = "regulator-fixed";
> +               regulator-name = "5V";
maybe use "DC_IN" here as well so the node-name matches what we see in
userspace/kernel logs?

> +       vddcpu: regulator-vddcpu {
> +               /*
> +                * SY8120B1ABC DC/DC Regulator.
> +                */
> +               compatible = "pwm-regulator";
> +
> +               regulator-name = "VDDCPU";
> +               regulator-min-microvolt = <721000>;
> +               regulator-max-microvolt = <1022000>;
the vendor .dts has:
  regulator-min-microvolt = <690000>;
  regulator-max-microvolt = <1050000>;
which also matches meson-sm1-sei610.dts (which uses the same regulator IC)

[...]
> +&ethmac {
> +       pinctrl-0 = <&eth_pins>, <&eth_rgmii_pins>;
> +       pinctrl-names = "default";
> +       status = "okay";
> +       phy-mode = "rgmii";
> +       phy-handle = <&external_phy>;
> +       amlogic,tx-delay-ns = <2>;
I haven't checked their u-boot code but some of the newer Amlogic BSPs
seem to let the PHY add the TX delay (which is also what the netdev
maintainers recommend)
that can be achieved by setting:
  phy-mode = "rgmii-txid";
and deleting the "amlogic,tx-delay-ns" property

> +&gpio {
> +       gpio-line-names =
> +               /* GPIOZ */
> +               "", "", "", "", "", "", "", "",
GPIOZ_0 to GPIOZ_15:
- ETH_MDIO
- ETH_MDC
- ETH_RXCLK
- ETH_RX_DV
- ETH_RXD0
- ETH_RXD1
- ETH_RXD2
- ETH_RXD3
- ETH_TXCLK
- ETH_TXEN
- ETH_TXD0
- ETH_TXD1
- ETH_TXD2
- ETH_TXD3
- ETH_INTR
- ETH_NRST

> +               /* GPIOH */
> +               "", "", "", "", "",
GPIOH_0 to GPIOH_4:
- HDMI_SDA
- HDMI_SCL
- HDMI_HPD
- HDMI_CEC
- VL-RST_N

> +               "CON1-P36", /* GPIOH_5 */
GPIOH_6 to GPIOH_8:
- VL-PWREN
- WiFi_3V3_1V8
- TFLASH_VDD_EN

> +               /* BOOT */
> +               "", "", "", "", "", "", "", "",
> +               "", "", "", "", "", "", "", "",
BOOT_0 to BOOT_13:
- eMMC_D0
- eMMC_D1
- eMMC_D2
- eMMC_D3
- eMMC_D4
- eMMC_D5
- eMMC_D6
- eMMC_D7
- eMMC_CLK
- (BOOT_9 is unused)
- eMMC_CMD
- (BOOT_11 is unused)
- eMMC_RST#
- eMMC_DS

> +               /* GPIOC */
> +               "", "", "", "", "", "", "", "",
GPIOC_0 to GPIOC_7:
- SD_D0_B
- SD_D1_B
- SD_D2_B
- SD_D3_B
- SD_CLK_B
- SD_CMD_B
- CARD_EN_DET
- (GPIOC_7 is unused)


> +&gpio_ao {
> +       gpio-line-names =
> +               /* GPIOAO */
> +               "DEBUG TX", /* GPIOAO_0 */
> +               "DEBUG RX", /* GPIOAO_1 */
> +               "SYS_LED2", /* GPIOAO_2 */
> +               "UPDATE_KEY", /* GPIOAO_3 */
> +               "CON1-P40", /* GPIOAO_4 */
> +               "",
GPIOAO_5 is IR_IN

> +               "TF_3V3N_1V8_EN", /* GPIOAO_6 */
> +               "CON1-P35", /* GPIOAO_7 */
> +               "CON1-P12", /* GPIOAO_8 */
> +               "CON1-P37", /* GPIOAO_9 */
> +               "CON1-P38", /* GPIOAO_10 */
> +               "SYS_LED", /* GPIOAO_11 */
> +               /* GPIOE */
> +               "", "", "";
GPIOE_0 to GPIOOE_2:
- VDDEE_PWM
- VDDCPU_PWM
- TF_PWR_EN

> +&usb2_phy0 {
> +       phy-supply = <&dc_in>;
> +};
> +
> +&usb2_phy1 {
> +       /* Enable the hub which is connected to this port */
> +       phy-supply = <&vl_pwr_en>;
> +};
I think technically we'd need to use AVDD18_USB here (that said, I
chose the same approach as you are using here before..)
USB bus devices (AFAIK) still need to be detected before any
device-tree properties can be applied and there's (again AFAIK) still
no pwrseq concept.
so I guess for now this is the way to go as there's enough comments
about it in your patch


Best regards,
Martin


From martin.blumenstingl at googlemail.com  Thu Apr 29 22:34:00 2021
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 29 Apr 2021 23:34:00 +0200
Subject: [PATCH] arm64: dts: meson-gxbb: nanopi-k2: Enable Bluetooth
In-Reply-To: <20210429060830.6266-1-wens@kernel.org>
References: <20210429060830.6266-1-wens@kernel.org>
Message-ID: <CAFBinCBrx8tCiWMf+p1k7Mn91yQ5JFGFgSw5fYvGtn6zjwxPJw@mail.gmail.com>

On Thu, Apr 29, 2021 at 8:08 AM Chen-Yu Tsai <wens at kernel.org> wrote:
>
> From: Chen-Yu Tsai <wens at csie.org>
>
> The NanoPi K2 has a AP6212 WiFi+BT combo module. The WiFi portion is
> already enabled. The BT part is connected via UART and I2S.
>
> Enable the UART and add a device node describing the Bluetooth portion
> of the module.
>
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
one nit-pick below - with that you can add my:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>

> ---
>  arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> index 7273eed5292c..10f48fb1af61 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
> @@ -385,9 +385,19 @@ &uart_AO {
>
>  /* Bluetooth on AP6212 */
>  &uart_A {
> -       status = "disabled";
> +       status = "okay";
>         pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
>         pinctrl-names = "default";
based on Documentation/devicetree/bindings/serial/serial.yaml please add:
  uart-has-rtscts;


Thank you!
Martin


From robh at kernel.org  Thu Apr 29 22:46:43 2021
From: robh at kernel.org (Rob Herring)
Date: Thu, 29 Apr 2021 16:46:43 -0500
Subject: [PATCH V9 2/2] doc: mtk-wdt: support pre-timeout when the bark
 irq is available
In-Reply-To: <1619315527-8171-3-git-send-email-wangqing@vivo.com>
References: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
 <1619315527-8171-3-git-send-email-wangqing@vivo.com>
Message-ID: <20210429214643.GA1833375@robh.at.kernel.org>

On Sun, 25 Apr 2021 09:52:07 +0800, Wang Qing wrote:
> Add description of pre-timeout in mtk-wdt.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>
> ---
>  Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.



From vsethi at nvidia.com  Thu Apr 29 23:08:26 2021
From: vsethi at nvidia.com (Vikram Sethi)
Date: Thu, 29 Apr 2021 22:08:26 +0000
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210429134659.321a5c3c@redhat.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
Message-ID: <BL0PR12MB2532C10511989BE9EAD2A032BD5F9@BL0PR12MB2532.namprd12.prod.outlook.com>

Hi Alex,

> From: Alex Williamson <alex.williamson at redhat.com>
> Subject: Re: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR region
> in VMA
> On Thu, 29 Apr 2021 14:14:50 -0500
> Shanker R Donthineni <sdonthineni at nvidia.com> wrote:
> 
> > Thanks Alex for quick reply.
> >
> > On 4/29/21 1:28 PM, Alex Williamson wrote:
> > > If this were a valid thing to do, it should be done for all
> > > architectures, not just ARM64.  However, a prefetchable range only
> > > necessarily allows merged writes, which seems like a subset of the
> > > semantics implied by a WC attribute, therefore this doesn't seem
> > > universally valid.
> > >
I didn't get your exact concern. If we removed the check for ARM arch
and simply stored that this is a prefetchable region in VMA, then each arch KVM
port could decide which PTE mappings are OK for prefetchable BAR.
KVM doesn't want to go through PCIe enumeration, and would rather
have the properties stored in VMA.
Beyond that, on arm64 specifically there is no WC Memtype, but we use
Normal Non Cacheable mapping for ioremap_wc which can be prefetched 
and can be write combined. What semantics break for a device if
its prefetchable BAR is marked as Normal Noncacheable on arm64?

We need a way for write combining to work in a KVM-ARM guest, as it is
an important usecase for GPUs and NICs and also NVMe CMB IIRC. So
*some* way is needed of letting KVM know to map as write combine 
(Normal NC) at stage2. Do you have a better solution in mind? 

> > > I'm also a bit confused by your problem statement that indicates
> > > that without WC you're seeing unaligned accesses, does this suggest
> > > that your driver is actually relying on WC semantics to perform
> > > merging to achieve alignment?  That seems rather like a driver bug,
> > > I'd expect UC vs WC is largely a difference in performance, not a
> > > means to enforce proper driver access patterns.  Per the PCI spec,
> > > the bridge itself can merge writes to prefetchable areas, presumably
> > > regardless of this processor attribute, perhaps that's the feature
> > > your driver is relying on that might be missing here.  Thanks,
> > The driver uses WC semantics, It's mapping PCI prefetchable BARS using
> > ioremap_wc().  We don't see any issue for x86 architecture, driver
> > works fine in the host and guest kernel. The same driver works on
> > ARM64 kernel but crashes inside VM. GPU driver uses the architecture
> > agnostic function ioremap_wc() like other drivers. This limitation
> > applies to all the drivers if they use WC memory and follow ARM64
> > NORMAL-NC access rules.
> 
> x86 KVM works for other reasons, KVM will trust the vCPU attributes for the
> memory range rather than relying only on the host mapping.
> 
> > On ARM64, ioremap_wc() is mapped to non-cacheable memory-type, no
> side
> > effects on reads and unaligned accesses are allowed as per ARM-ARM
> > architecture. The driver behavior is different in host vs guest on
> > ARM64.
> 
> Per the PCI spec, prefetchable memory only necessarily allows the bridge to
> merge writes.  I believe this is only a subset of what WC mappings allow,
> therefore I expect this is incompatible with drivers that do not use WC
> mappings.
> 
> > ARM CPU generating alignment faults before transaction reaches the
> > PCI-RC/switch/end-point-device.
> 
> If an alignment fault is fixed by configuring a WC mapping, doesn't that
> suggest that the driver performed an unaligned access itself and is relying on
> write combining by the processor to correct that error?
> That's wrong.  Fix the driver or please offer another explanation of how the
> WC mapping resolves this.  I suspect you could enable tracing in QEMU,
> disable MMIO mmaps on the vfio-pci device and find the invalid access.
> 
> > We've two concerns here:
> >    - Performance impacts for pass-through devices.
> >    - The definition of ioremap_wc() function doesn't match the host
> > kernel on ARM64
> 
> Performance I can understand, but I think you're also using it to mask a driver
> bug which should be resolved first.  Thanks,
> 
> Alex


From laurent.pinchart at ideasonboard.com  Thu Apr 29 23:14:35 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 30 Apr 2021 01:14:35 +0300
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
Message-ID: <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>

Hi Marco,

On Thu, Apr 29, 2021 at 09:49:03AM +0200, Marco Felsch wrote:
> On 21-04-29 04:51, Laurent Pinchart wrote:
> > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:
> > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > with the interleaved IR pixels looks like:
> > > 
> > >         |  G |  R |  G |  B | ...
> > >         +----+----+----+----+---
> > >         | IR |  G | IR |  G | ...
> > >         +----+----+----+----+---
> > >         |  G |  B |  G |  R | ...
> > >         +----+----+----+----+---
> > >         | IR |  G | IR |  G | ...
> > >         +----+----+----+----+---
> > >         | .. | .. | .. | .. | ..
> > > 
> > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> > 
> > I think we're reaching a limit of the media bus codes model here, due to
> > a historical mistake. The four possible Bayer patterns, times the
> > different number of bits per pixel, creates a lot of media bus codes,
> > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > have to support them all.
> 
> That's correct but it is not bayer related. Currently it is what it is,
> if a new code is added it must be propagated through all the involved
> subdevs. On the other hand I wouldn't say that it is better to support
> new codes per default for all drivers. Since this would add a lot of
> untested code paths.

It's not an issue limited to Bayer patterns, but they make the issue
worse given the number of possible combinations (think about adding DPCM
and ALAW compression on top of that...).

> > This is already painful, and if we had a
> > non-Bayer pattern such as this one,
> 
> That's not exactly true since it is a bayer pattern but instead of using
> 4x4 it uses 8x8 and it as some special pixels.
> 
> > we'll open the door to an explosion
> > of the number of media bus codes (imagine all the different possible
> > arrangements of this pattern, for instance if you enable horizontal
> > and/or vertical flipping on the sensor). All drivers would need to be
> > updated to support these new bus codes, and this really kills the
> > current model.
> 
> Yep, I know what you mean but as I said above I think that adding it
> explicite is the better abbroach since it involves somone who add _and_
> test the new code on the particular platform.
> 
> > The historical mistake was to tie the Bayer pattern with the media bus
> > code. We should really have specified raw 8/10/12/14/16 media bus codes,
> > and conveyed the pattern separately. Most IP cores in the pipeline don't
> > need to care about the pattern at all, and those who do (that's mostly
> > ISPs) could be programmed explicitly by userspace as long as we have an
> > API to retrieve the pattern from the sensor. I believe it's time to bite
> > the bullet and go in that direction. I'm sorry for this case of yak
> > shaving, but it really wouldn't be manageable anymore :-(
> 
> I got all your points and would agree but this is not a bayer only
> related problem. You will have this problem with all new other formats
> as well. I'm with you, most IP cores don't care but I wouldn't
> guarantee that.

Sorry, but adding new media bus formats like this one will just not
scale. We have two options, either fixing the issue, or considering that
V4L2 is a barely alive API with no future, and merging this without
caring anymore.

-- 
Regards,

Laurent Pinchart


From michael at walle.cc  Thu Apr 29 23:20:13 2021
From: michael at walle.cc (Michael Walle)
Date: Fri, 30 Apr 2021 00:20:13 +0200
Subject: [RFC PATCH 4/6] spi: cadence-qspi: Use PHY for DAC reads if
 possible
In-Reply-To: <20210429181908.bwb45eljn5nxscf6@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-5-p.yadav@ti.com>
 <2f26456e-59ff-2625-5d65-c1537052839d@microchip.com>
 <20210312101757.sqeyledbwjnpqdoy@ti.com>
 <ee2b753b16e76ecbede4c1373b6f2d77@walle.cc>
 <20210429181908.bwb45eljn5nxscf6@ti.com>
Message-ID: <e17722c30deb7f2dcb94a9aa43bbc6dd@walle.cc>

Am 2021-04-29 20:19, schrieb Pratyush Yadav:
> On 29/04/21 06:28PM, Michael Walle wrote:
>> Am 2021-03-12 11:17, schrieb Pratyush Yadav:
>> > On 12/03/21 09:13AM, Tudor.Ambarus at microchip.com wrote:
>> > > On 3/11/21 9:12 PM, Pratyush Yadav wrote:
>> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> > > >
>> > > > Check if a read is eligible for PHY and if it is, enable PHY and DQS.
>> > >
>> > > DQS as in data strobe? Shouldn't the upper layer inform the QSPI
>> > > controller
>> > > whether DS is required or not?
>> >
>> > Yes, DQS as in data strobe. I need to check this again, but IIRC the
>> > controller cannot run in PHY mode unless DS is used. Ideally the upper
>> > layer should indeed inform the controller whether DS is supported/in-use
>> > or not. That can be used to decide whether PHY mode (and consequently
>> > the DS line) is to be used or not.
>> >
>> > Currently there are only two flashes that use 8D-8D-8D mode (S28HS512T
>> > and MT35XU512ABA), and both of them drive the DS line.
>> 
>> The LS1028A datasheet explicitly states that the calibration is only
>> used for non-DQS flashes. Which makes sense, because it just determine 
>> at
>> which point the input data is sampled. And if the flash provides a 
>> data
>> strobe, it already know when to sample it. What I am missing here?
> 
> If there was 0 delay in transferring the signals from flash to
> SoC/controller, you would be right. But in practice there is a small 
> but
> noticeable delay from when the flash launches the signal and when it is
> received by the device. So by the time the DQS signal reaches the SoC 
> it
> might already be too late and the data lines might not be valid any
> more. The calibration accounts for these (and some others) delays.

DQS and the data signals are trace length matched, so for data reads
they will end up on the IO pad of the SoC at the same time. This is
also mentioned in [1] (Fig 1.1, point 4 and 5). So while there needs
to be a delay on the clock line for the receiving FF, the best value
for this should be half the SCK clock period.

Does this work without DQS? That should be the main purpose for a
calibration, no? Because in this case, you'll have to determine
the delay between SCK and the data signals (for reads).

Btw. I can't get my head around how the TX delay search would work.
Basically you shift the SCK to the command / data to the flash. So
the flash will either recognize a valid read command or if the delay
is too short/too long the flash will (hopefully) ignore the wrong
command, correct? Might there be any misinterpreted commands which
might be harmful? Are there any flashes which actually need a delay
between data out and SCK?

Of course, the calibration might help with broken hardware where the
SCK/DQ/DQS traces are not length matched.

-michael

> 
> See [0] for a somewhat similar discussion I had with Tudor.
> 
> [0] 
> https://lore.kernel.org/linux-mtd/20210312181447.dlecnw2oed7jtxe7 at ti.com/

[1] https://www.ti.com/lit/an/spract2/spract2.pdf


From linux at roeck-us.net  Thu Apr 29 23:22:57 2021
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 29 Apr 2021 15:22:57 -0700
Subject: [PATCH V9 1/2] watchdog: mtk: support pre-timeout when the bark
 irq is available
In-Reply-To: <1619315527-8171-2-git-send-email-wangqing@vivo.com>
References: <1619315527-8171-1-git-send-email-wangqing@vivo.com>
 <1619315527-8171-2-git-send-email-wangqing@vivo.com>
Message-ID: <45ff044d-80ff-9001-1d4f-d39d0ae63060@roeck-us.net>

On 4/24/21 6:52 PM, Wang Qing wrote:
> Use the bark interrupt as the pretimeout notifier if available.
> 
> When the watchdog timer expires in dual mode, an interrupt will be
> triggered first, then the timing restarts. The reset signal will be
> initiated when the timer expires again.
> 
> The pretimeout notification shall occur at timeout-sec/2.
> 
> V2:
> - panic() by default if WATCHDOG_PRETIMEOUT_GOV is not enabled.
> 
> V3:
> - Modify the pretimeout behavior, manually reset after the pretimeout
> - is processed and wait until timeout.
> 
> V4:
> - Remove pretimeout related processing. 
> - Add dual mode control separately.
> 
> V5:
> - Fix some formatting and printing problems.
> 
> V6:
> - Realize pretimeout processing through dualmode.
> 
> V7:
> - Add set_pretimeout().
> 
> V8/V9:
> - Fix some formatting problems.
> 
> Signed-off-by: Wang Qing <wangqing at vivo.com>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

Note that the version history should be after "---".

Guenter

> ---
>  drivers/watchdog/mtk_wdt.c | 77 +++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 72 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 97ca993..7bb0774
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -25,9 +25,10 @@
>  #include <linux/reset-controller.h>
>  #include <linux/types.h>
>  #include <linux/watchdog.h>
> +#include <linux/interrupt.h>
>  
>  #define WDT_MAX_TIMEOUT		31
> -#define WDT_MIN_TIMEOUT		1
> +#define WDT_MIN_TIMEOUT		2
>  #define WDT_LENGTH_TIMEOUT(n)	((n) << 5)
>  
>  #define WDT_LENGTH		0x04
> @@ -187,12 +188,19 @@ static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
>  	u32 reg;
>  
>  	wdt_dev->timeout = timeout;
> +	/*
> +	 * In dual mode, irq will be triggered at timeout / 2
> +	 * the real timeout occurs at timeout
> +	 */
> +	if (wdt_dev->pretimeout)
> +		wdt_dev->pretimeout = timeout / 2;
>  
>  	/*
>  	 * One bit is the value of 512 ticks
>  	 * The clock has 32 KHz
>  	 */
> -	reg = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
> +	reg = WDT_LENGTH_TIMEOUT((timeout - wdt_dev->pretimeout) << 6)
> +			| WDT_LENGTH_KEY;
>  	iowrite32(reg, wdt_base + WDT_LENGTH);
>  
>  	mtk_wdt_ping(wdt_dev);
> @@ -239,13 +247,48 @@ static int mtk_wdt_start(struct watchdog_device *wdt_dev)
>  		return ret;
>  
>  	reg = ioread32(wdt_base + WDT_MODE);
> -	reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	if (wdt_dev->pretimeout)
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	else
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
>  	reg |= (WDT_MODE_EN | WDT_MODE_KEY);
>  	iowrite32(reg, wdt_base + WDT_MODE);
>  
>  	return 0;
>  }
>  
> +static int mtk_wdt_set_pretimeout(struct watchdog_device *wdd,
> +				  unsigned int timeout)
> +{
> +	struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdd);
> +	void __iomem *wdt_base = mtk_wdt->wdt_base;
> +	u32 reg = ioread32(wdt_base + WDT_MODE);
> +
> +	if (timeout && !wdd->pretimeout) {
> +		wdd->pretimeout = wdd->timeout / 2;
> +		reg |= (WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	} else if (!timeout && wdd->pretimeout) {
> +		wdd->pretimeout = 0;
> +		reg &= ~(WDT_MODE_IRQ_EN | WDT_MODE_DUAL_EN);
> +	} else {
> +		return 0;
> +	}
> +
> +	reg |= WDT_MODE_KEY;
> +	iowrite32(reg, wdt_base + WDT_MODE);
> +
> +	return mtk_wdt_set_timeout(wdd, wdd->timeout);
> +}
> +
> +static irqreturn_t mtk_wdt_isr(int irq, void *arg)
> +{
> +	struct watchdog_device *wdd = arg;
> +
> +	watchdog_notify_pretimeout(wdd);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static const struct watchdog_info mtk_wdt_info = {
>  	.identity	= DRV_NAME,
>  	.options	= WDIOF_SETTIMEOUT |
> @@ -253,12 +296,21 @@ static const struct watchdog_info mtk_wdt_info = {
>  			  WDIOF_MAGICCLOSE,
>  };
>  
> +static const struct watchdog_info mtk_wdt_pt_info = {
> +	.identity	= DRV_NAME,
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_PRETIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE,
> +};
> +
>  static const struct watchdog_ops mtk_wdt_ops = {
>  	.owner		= THIS_MODULE,
>  	.start		= mtk_wdt_start,
>  	.stop		= mtk_wdt_stop,
>  	.ping		= mtk_wdt_ping,
>  	.set_timeout	= mtk_wdt_set_timeout,
> +	.set_pretimeout	= mtk_wdt_set_pretimeout,
>  	.restart	= mtk_wdt_restart,
>  };
>  
> @@ -267,7 +319,7 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct mtk_wdt_dev *mtk_wdt;
>  	const struct mtk_wdt_data *wdt_data;
> -	int err;
> +	int err, irq;
>  
>  	mtk_wdt = devm_kzalloc(dev, sizeof(*mtk_wdt), GFP_KERNEL);
>  	if (!mtk_wdt)
> @@ -279,7 +331,22 @@ static int mtk_wdt_probe(struct platform_device *pdev)
>  	if (IS_ERR(mtk_wdt->wdt_base))
>  		return PTR_ERR(mtk_wdt->wdt_base);
>  
> -	mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq > 0) {
> +		err = devm_request_irq(&pdev->dev, irq, mtk_wdt_isr, 0, "wdt_bark",
> +				       &mtk_wdt->wdt_dev);
> +		if (err)
> +			return err;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_pt_info;
> +		mtk_wdt->wdt_dev.pretimeout = WDT_MAX_TIMEOUT / 2;
> +	} else {
> +		if (irq == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		mtk_wdt->wdt_dev.info = &mtk_wdt_info;
> +	}
> +
>  	mtk_wdt->wdt_dev.ops = &mtk_wdt_ops;
>  	mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
>  	mtk_wdt->wdt_dev.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT * 1000;
> 



From helgaas at kernel.org  Thu Apr 29 23:38:38 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 29 Apr 2021 17:38:38 -0500
Subject: [PATCH] PCI: mediatek: Verify whether the free_ck clock is
 ungated or not
In-Reply-To: <20210429134749.75157-1-ameynarkhede03@gmail.com>
Message-ID: <20210429223838.GA588275@bjorn-Precision-5520>

Can you make the subject say something at a higher level instead of
just paraphrasing the C code?  I'm guessing this means resume will now
fail if the clock isn't turned on?

On Thu, Apr 29, 2021 at 07:17:49PM +0530, Amey Narkhede wrote:
> Verify that the free_ck clock is ungated on device resume
> by checking return value of clk_prepare_enable().

Also the commit log -- this doesn't say anything more than the code
itself.  Did you find this by tripping over it?  Or just by code
inspection?  I guess without the check, we continue on and try to
resume, but accesses to PCI devices fail and maybe return ~0 data or
cause machine checks or something?

> Signed-off-by: Amey Narkhede <ameynarkhede03 at gmail.com>
> ---
>  drivers/pci/controller/pcie-mediatek.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 23548b517..9b13214bf 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -1154,11 +1154,14 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
>  {
>  	struct mtk_pcie *pcie = dev_get_drvdata(dev);
>  	struct mtk_pcie_port *port, *tmp;
> +	int ret;
> 
>  	if (list_empty(&pcie->ports))
>  		return 0;
> 
> -	clk_prepare_enable(pcie->free_ck);
> +	ret = clk_prepare_enable(pcie->free_ck);
> +	if (ret)
> +		return ret;

Most callers print an error message when clk_prepare_enable() fails.

>  	list_for_each_entry_safe(port, tmp, &pcie->ports, list)
>  		mtk_pcie_enable_port(port);
> --
> 2.31.1


From michael at walle.cc  Thu Apr 29 23:46:10 2021
From: michael at walle.cc (Michael Walle)
Date: Fri, 30 Apr 2021 00:46:10 +0200
Subject: [RFC PATCH 1/6] spi: spi-mem: Tell controller when device is
 ready for calibration
In-Reply-To: <20210429184109.f2pf3iyaiylumoyp@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-2-p.yadav@ti.com>
 <934c8c6f7bb71729bfdaefd39c63a262@walle.cc>
 <20210324080804.x7oemmpt2khi72mp@ti.com>
 <6dfbb3e4107887dc9ee3e19e4940e87c@walle.cc>
 <20210429184109.f2pf3iyaiylumoyp@ti.com>
Message-ID: <2c3461f38c93871fbc715a19aeecdd2a@walle.cc>

Am 2021-04-29 20:41, schrieb Pratyush Yadav:
> On 29/04/21 06:23PM, Michael Walle wrote:
>> I've had a look at the LS1028A FlexSPI calibration feature. The
>> reference manual is very sparse on details, though. What you need to
>> do there is to program a special read command sequence (the whole
>> controller is made of these lookup table entries, where you can
>> have a short sequence of operations for read/write/program and so
>> on). Therefore, for data learning you'll take the read operation
>> and insert a LEARN op in between and read a specific data pattern.
>> Then the hardware will automatically figure out the correct sample
>> phase for the read data pins.
>> 
>> Unfortunately, it does not mention how often you have to do it. It
>> might be the case that is has to be calibrated more than once.
> 
> I haven't read the datasheet, I wonder how long this calibration takes.
> If it is too long then the overhead might not even be worth the extra
> read throughput. Especially when using a file system on top which
> generally don't do very large reads in one go.

I was just thinking of compensating a possible temperature drift. You
wouldn't have to do it on every read.

There is a second mode, where it is actually done on every read. But
that will be used where the flash supports a read preamble, where
dummy bytes after the read opcode are replaced by a calibration pattern.
If the pattern has the same length as the dummy bytes there is no 
penalty.
IIRC the controller just supports a pattern of max 32 bits.

Oh I forgot to mention, this doesn't need to be repeated. I guess
the hardware already captures all possible phases (there are only
16) and compares each one with a predefined pattern.

> Anyway, when the do_calibration() is called the controller can save the
> calibration op and use it later as needed. It knows when an exec_op()
> will result in a read since it has access to the whole op.
> 
>> 
>> I'm just mentioning this so it won't be lost. If needed, it can
>> be added later.
>> 
>> Am 2021-03-24 09:08, schrieb Pratyush Yadav:
>> > On 24/03/21 12:07AM, Michael Walle wrote:
>> > > Am 2021-03-11 20:12, schrieb Pratyush Yadav:
>> > > > Some controllers like the Cadence OSPI controller need to perform a
>> > > > calibration sequence to operate at high clock speeds. This calibration
>> > > > should happen after the flash is fully initialized otherwise the
>> > > > calibration might happen in a different SPI mode from the one the flash
>> > > > is finally set to. Add a hook that can be used to tell the controller
>> > > > when the flash is ready for calibration. Whether calibration is needed
>> > > > depends on the controller.
>> > > >
>> > > > Signed-off-by: Pratyush Yadav <p.yadav at ti.com>
>> > > > ---
>> > > >  drivers/spi/spi-mem.c       | 12 ++++++++++++
>> > > >  include/linux/spi/spi-mem.h |  8 ++++++++
>> > > >  2 files changed, 20 insertions(+)
>> > > >
>> > > > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
>> > > > index dc713b0c3c4d..e2f05ad3f4dc 100644
>> > > > --- a/drivers/spi/spi-mem.c
>> > > > +++ b/drivers/spi/spi-mem.c
>> > > > @@ -464,6 +464,18 @@ int spi_mem_adjust_op_size(struct spi_mem *mem,
>> > > > struct spi_mem_op *op)
>> > > >  }
>> > > >  EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
>> > > >
>> > > > +int spi_mem_do_calibration(struct spi_mem *mem, struct spi_mem_op *op)
>> > > > +{
>> > > > +	struct spi_controller *ctlr = mem->spi->controller;
>> > > > +
>> > > > +	if (!ctlr->mem_ops || !ctlr->mem_ops->do_calibration)
>> > > > +		return -EOPNOTSUPP;
>> > > > +
>> > > > +	ctlr->mem_ops->do_calibration(mem, op);
>> > >
>> > > Can't a calibration fail?
>> >
>> > It can. If it does, the controller falls back to lower speed transfers.
>> > There is not much the upper layer can do about this. That's why it is
>> > not informed whether it succeeded or not.
>> 
>> Ok, if needed, that should be an easy change.
>> 
>> op is there to decide if we need a calibration at all, correct?
> 
> Yes. It can also be used to choose which calibration algorithm to use.
> For example on the Cadence controller, there are different algorithms
> for 8S and 8D operations.
> 
>> What if there are different factors, like frequency? For example
>> on the LS1028A its just a matter of the SCK frequency. It seems
>> that this parameter is tailored to the OPHY.
> 
> As of now there is no way in SPI MEM to tell the controller the 
> expected
> speed of the operation. AFAIK most controllers get the speed via device
> tree. So in the current case, the controller already knows the speed it
> should run at, and can decide if calibration is needed or not.
> 
> But if operation speed is eventually added to SPI MEM, I would assume 
> it
> would be part of struct spi_mem_op. The op passed in would have this
> information filled, and the controller can use that information to
> decide if it needs to perform the calibration or not.
> 
> I am all for making this API flexible, but with very few controllers
> supporting this feature in the wild, it is difficult to predict all the
> information that might be needed. In the current state, I think the API
> provides a fair bit of information to the controller about how a read
> operation would look like.

Sure, and its also quite hard to review without any other hardware
which supports that ;) I was thinking about letting the spi driver
call into spi-mem to retrieve the information it needs instead of
having that second argument. Anyway, if we need any changes in the
future this isn't set in stone.

-michael


From michael at walle.cc  Thu Apr 29 23:48:21 2021
From: michael at walle.cc (Michael Walle)
Date: Fri, 30 Apr 2021 00:48:21 +0200
Subject: [RFC PATCH 5/6] spi: cadence-qspi: Tune PHY to allow running at
 higher frequencies
In-Reply-To: <20210311191216.7363-6-p.yadav@ti.com>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-6-p.yadav@ti.com>
Message-ID: <143b24c61109823f6e616cf91d28d16c@walle.cc>

Am 2021-03-11 20:12, schrieb Pratyush Yadav:
> +	if (of_property_read_u32(np, "cdns,phy-tx-start", 
> &f_pdata->phy_tx_start))
> +		f_pdata->phy_tx_start = 16;
> +
> +	if (of_property_read_u32(np, "cdns,phy-tx-end", 
> &f_pdata->phy_tx_end))
> +		f_pdata->phy_tx_end = 48;
> +

I didn't see a dt-bindings patch for these.

-michael


From suzuki.poulose at arm.com  Thu Apr 29 23:49:53 2021
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 29 Apr 2021 23:49:53 +0100
Subject: [PATCH] [v2] coresight: etm4x: avoid build failure with unrolled
 loops
In-Reply-To: <CAK8P3a3-XoDQ6BfTBUof5ST2H1_6JOL+rK-BQqWXAV0H5jMm9Q@mail.gmail.com>
References: <20210429145752.3218324-1-arnd@kernel.org>
 <dff8cbd8-8c56-ae6e-ecc2-9ca183113ab2@arm.com>
 <CAK8P3a3-XoDQ6BfTBUof5ST2H1_6JOL+rK-BQqWXAV0H5jMm9Q@mail.gmail.com>
Message-ID: <81b8a4ff-4d5d-1c2a-8ff1-7cd320460e57@arm.com>

On 29/04/2021 18:50, Arnd Bergmann wrote:
> On Thu, Apr 29, 2021 at 7:37 PM Suzuki K Poulose <suzuki.poulose at arm.com> wrote:
>> On 29/04/2021 15:57, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd at arndb.de>
>>>
>>> clang-12 fails to build the etm4x driver with -fsanitize=array-bounds,
>>> where it decides to unroll certain loops in a way that result in a
>>> C variable getting put into an inline assembly
>>>
>>> <instantiation>:1:7: error: expected constant expression in '.inst' directive
>>> .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
>>>         ^
>>> drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation
>>>                           etm4x_relaxed_read32(csa, TRCCNTVRn(i));
>>>                           ^
>>> drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32'
>>>                    read_etm4x_sysreg_offset((offset), false)))
>>>                    ^
>>> drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset'
>>>                           __val = read_etm4x_sysreg_const_offset((offset));       \
>>>                                   ^
>>> drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset'
>>>           READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
>>>           ^
>>> drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG'
>>>           read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
>>>           ^
>>> arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s'
>>>           asm volatile(__mrs_s("%0", r) : "=r" (__val));                  \
>>>                        ^
>>> arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
>>> "       mrs_s " v ", " __stringify(r) "\n"                      \
>>>    ^
>>>
>>> This only happened in a few loops in which the array bounds sanitizer
>>> added a special case for an array overflow that clang determined to be
>>> possible, but any compiler is free to unroll any of the loops in the
>>> same way that breaks the sysreg macros.
>>>
>>> Introduce helper functions that perform a sysreg access with a
>>> non-constant register number and use them in each call that passes
>>> a loop counter.
>>
>> You don't need to add this special helper. We have the exact
>> infrastructure already. So these could simply be replaced with:
>>
>> csdev_access_xxx(csa, ...)
>>
>> see :
>>
>> include/linux/coresight.h
> 
> Ah, nice!
> 
> Do you mean replacing only the ones that use a nonconstant
> offset, or all of them? I guess changing all would avoid some

Only the CLANG "nonconstant" please. Going through an indirect
function call and large "switch..case" for every single register
access is painful. Which is why I decided to add those ugly macros.

So, please leave the rest as they are.

Suzuki


> really ugly magic macros, but the indirect function call and the
> switch() adds a few cycles of overhead every time and the code
> looks like it is micro-optimized for fast register access here.
> 
>        Arnd
> 



From mohammad.athari.ismail at intel.com  Fri Apr 30 00:01:04 2021
From: mohammad.athari.ismail at intel.com (mohammad.athari.ismail at intel.com)
Date: Fri, 30 Apr 2021 07:01:04 +0800
Subject: [PATCH net] net: stmmac: cleared __FPE_REMOVING bit in
 stmmac_fpe_start_wq()
Message-ID: <20210429230104.16977-1-mohammad.athari.ismail@intel.com>

From: Mohammad Athari Bin Ismail <mohammad.athari.ismail at intel.com>

An issue found when network interface is down and up again, FPE handshake
fails to trigger. This is due to __FPE_REMOVING bit remains being set in
stmmac_fpe_stop_wq() but not cleared in stmmac_fpe_start_wq(). This
cause FPE workqueue task, stmmac_fpe_lp_task() not able to be executed.

To fix this, add clearing __FPE_REMOVING bit in stmmac_fpe_start_wq().

Fixes: 5a5586112b92 ("net: stmmac: support FPE link partner hand-shaking procedure")
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail at intel.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a9a984c57d78..e0b7eebcb512 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3180,6 +3180,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
 	char *name;
 
 	clear_bit(__FPE_TASK_SCHED, &priv->fpe_task_state);
+	clear_bit(__FPE_REMOVING,  &priv->fpe_task_state);
 
 	name = priv->wq_name;
 	sprintf(name, "%s-fpe", priv->dev->name);
-- 
2.17.1



From helgaas at kernel.org  Fri Apr 30 00:10:40 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 29 Apr 2021 18:10:40 -0500
Subject: [PATCH v2 2/3] PCI: dwc: Visconti: PCIe RC controller driver
In-Reply-To: <20210419063513.1947003-3-nobuhiro1.iwamatsu@toshiba.co.jp>
Message-ID: <20210429231040.GA589969@bjorn-Precision-5520>

Please use something like this as the subject to match existing
convention:

  PCI: visconti: Add Toshiba Visconti PCIe host controller driver

(You can use "git log --oneline drivers/pci/controller/dwc" to learn
this.)

On Mon, Apr 19, 2021 at 03:35:12PM +0900, Nobuhiro Iwamatsu wrote:
> Add support to PCIe RC controller on Toshiba Visconti ARM SoCs. PCIe controller is based of Synopsys
> DesignWare PCIe core.
> 
> This patch does not yet use the clock framework to control the clock. This will be replaced in the
> future.

Wrap this text to fit nicely in 75 columns.

> Signed-off-by: Yuji Ishikawa <yuji2.ishikawa at toshiba.co.jp>
> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> ---
>  drivers/pci/controller/dwc/Kconfig         |   9 +
>  drivers/pci/controller/dwc/Makefile        |   1 +
>  drivers/pci/controller/dwc/pcie-visconti.c | 333 +++++++++++++++++++++
>  3 files changed, 343 insertions(+)
>  create mode 100644 drivers/pci/controller/dwc/pcie-visconti.c
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index b9aaa84452c4..043c2c70d566 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -286,6 +286,15 @@ config PCIE_TEGRA194_EP
>  	  in order to enable device-specific features PCIE_TEGRA194_EP must be
>  	  selected. This uses the DesignWare core.
>  
> +config PCIE_VISCONTI

Consider using PCIE_VISCONTI_HOST in case you ever adapt this hardware
to work in endpoint mode.

> +	bool "Toshiba VISCONTI PCIe controllers"

s/VISCONTI/Visconti/ to match usage below.

> +	depends on ARCH_VISCONTI || COMPILE_TEST
> +	depends on PCI_MSI_IRQ_DOMAIN
> +	select PCIE_DW_HOST
> +	help
> +	  Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
> +	  This driver supports TMPV77xx.

What is "TMPV77xx"?  A SoC?  A reference platform?

>  config PCIE_UNIPHIER
>  	bool "Socionext UniPhier PCIe host controllers"
>  	depends on ARCH_UNIPHIER || COMPILE_TEST
> diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
> index ba7c42f6df6f..46ac5d49dc75 100644
> --- a/drivers/pci/controller/dwc/Makefile
> +++ b/drivers/pci/controller/dwc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
>  obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
>  obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
>  obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
> +obj-$(CONFIG_PCIE_VISCONTI) += pcie-visconti.o
>  
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/controller/dwc/pcie-visconti.c b/drivers/pci/controller/dwc/pcie-visconti.c
> new file mode 100644
> index 000000000000..a4739e7187f0
> --- /dev/null
> +++ b/drivers/pci/controller/dwc/pcie-visconti.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DWC PCIe RC driver for Toshiba Visconti ARM SoC
> + *
> + * Copyright (C) 2019, 2020 Toshiba Electronic Device & Storage Corporation
> + * Copyright (C) 2020, TOSHIBA CORPORATION
> + *
> + * Nobuhiro Iwamatsu <nobuhiro1.iwamatsu at toshiba.co.jp>
> + *

Remove spurious blank line.

> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/gpio.h>
> +#include <linux/interrupt.h>
> +#include <linux/init.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/resource.h>
> +#include <linux/types.h>
> +
> +#include "pcie-designware.h"
> +#include "../../pci.h"
> +
> +struct visconti_pcie {
> +	struct dw_pcie pci;
> +	void __iomem *ulreg_base;
> +	void __iomem *smu_base;
> +	void __iomem *mpu_base;
> +	struct clk *refclk;
> +	struct clk *sysclk;
> +	struct clk *auxclk;
> +};
> +
> +#define PCIE_UL_REG_S_PCIE_MODE		0x00F4
> +#define  PCIE_UL_REG_S_PCIE_MODE_EP	0x00
> +#define  PCIE_UL_REG_S_PCIE_MODE_RC	0x04
> +
> +#define PCIE_UL_REG_S_PERSTN_CTRL	0x00F8
> +#define  PCIE_UL_IOM_PCIE_PERSTN_I_EN	BIT(3)
> +#define  PCIE_UL_DIRECT_PERSTN_EN	BIT(2)
> +#define  PCIE_UL_PERSTN_OUT		BIT(1)
> +#define  PCIE_UL_DIRECT_PERSTN		BIT(0)
> +
> +#define PCIE_UL_REG_S_PHY_INIT_02	0x0104
> +#define  PCIE_UL_PHY0_SRAM_EXT_LD_DONE	BIT(0)
> +
> +#define PCIE_UL_REG_S_PHY_INIT_03	0x0108
> +#define  PCIE_UL_PHY0_SRAM_INIT_DONE	BIT(0)
> +
> +#define PCIE_UL_REG_S_INT_EVENT_MASK1	0x0138
> +#define  PCIE_UL_CFG_PME_INT		BIT(0)
> +#define  PCIE_UL_CFG_LINK_EQ_REQ_INT	BIT(1)
> +#define  PCIE_UL_EDMA_INT0		BIT(2)
> +#define  PCIE_UL_EDMA_INT1		BIT(3)
> +#define  PCIE_UL_EDMA_INT2		BIT(4)
> +#define  PCIE_UL_EDMA_INT3		BIT(5)
> +#define  PCIE_UL_S_INT_EVENT_MASK1_ALL  (PCIE_UL_CFG_PME_INT | PCIE_UL_CFG_LINK_EQ_REQ_INT | \
> +					 PCIE_UL_EDMA_INT0 | PCIE_UL_EDMA_INT1 | \
> +					 PCIE_UL_EDMA_INT2 | PCIE_UL_EDMA_INT3)
> +

Please wrap the code here and below so it fits nicely in 80 columns.

> +#define PCIE_UL_REG_S_SB_MON		0x0198
> +#define PCIE_UL_REG_S_SIG_MON		0x019C
> +#define  PCIE_UL_CORE_RST_N_MON		BIT(0)
> +
> +#define PCIE_UL_REG_V_SII_DBG_00	0x0844
> +#define PCIE_UL_REG_V_SII_GEN_CTRL_01	0x0860
> +#define  PCIE_UL_APP_LTSSM_ENABLE	BIT(0)
> +
> +#define PCIE_UL_REG_V_PHY_ST_00		0x0864
> +#define  PCIE_UL_SMLH_LINK_UP		BIT(0)
> +
> +#define PCIE_UL_REG_V_PHY_ST_02		0x0868
> +#define  PCIE_UL_S_DETECT_ACT		0x01
> +#define  PCIE_UL_S_L0			0x11
> +
> +#define PISMU_CKON_PCIE			0x0038
> +#define  PISMU_CKON_PCIE_AUX_CLK	BIT(1)
> +#define  PISMU_CKON_PCIE_MSTR_ACLK	BIT(0)
> +
> +#define PISMU_RSOFF_PCIE		0x0538
> +#define  PISMU_RSOFF_PCIE_ULREG_RST_N	BIT(1)
> +#define  PISMU_RSOFF_PCIE_PWR_UP_RST_N	BIT(0)
> +
> +#define PCIE_MPU_REG_MP_EN		0x0
> +#define  MPU_MP_EN_DISABLE		BIT(0)
> +
> +#define PCIE_BUS_OFFSET			0x40000000
> +
> +/* Access registers in PCIe ulreg */
> +static inline void visconti_ulreg_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel_relaxed(val, pcie->ulreg_base + reg);
> +}
> +
> +/* Access registers in PCIe smu */
> +static inline void visconti_smu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel_relaxed(val, pcie->smu_base + reg);
> +}
> +
> +/* Access registers in PCIe mpu */
> +static inline void visconti_mpu_writel(struct visconti_pcie *pcie, u32 val, u32 reg)
> +{
> +	writel_relaxed(val, pcie->mpu_base + reg);
> +}
> +
> +static inline u32 visconti_mpu_readl(struct visconti_pcie *pcie, u32 reg)

Don't bother with "inline" above and the signature will fit better in
the line.  The compiler will inline these even if you don't specify
it.

> +{
> +	return readl_relaxed(pcie->mpu_base + reg);
> +}
> +
> +static int visconti_pcie_check_link_status(struct visconti_pcie *pcie)

"check_link_status" gives no hint about what the return value means.
This looks like it might be similar to what other drivers do in
*_pcie_link_up().

Can you hook things up so this generic code in dw_pcie_host_init()
works for you?

        if (!dw_pcie_link_up(pci) && pci->ops && pci->ops->start_link) {
                ret = pci->ops->start_link(pci);
                if (ret)
                        goto err_free_msi;
        }

> +{
> +	int err;
> +	u32 val;
> +
> +	/* wait for linkup of phy link layer */
> +	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_00, val,
> +				 (val & PCIE_UL_SMLH_LINK_UP), 1000, 10000);
> +	if (err)
> +		return err;
> +
> +	/* wait for linkup of data link layer */
> +	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> +				 (val & PCIE_UL_S_DETECT_ACT), 1000, 10000);
> +	if (err)
> +		return err;
> +
> +	/* wait for LTSSM Status */
> +	return readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_V_PHY_ST_02, val,
> +				  (val & PCIE_UL_S_L0), 1000, 10000);
> +}
> +
> +static int visconti_pcie_establish_link(struct pcie_port *pp)
> +{
> +	int ret;
> +	u32 val;
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct visconti_pcie *pcie = dev_get_drvdata(pci->dev);

Reorder these in the order of use (as you did below).

> +	visconti_ulreg_writel(pcie, PCIE_UL_APP_LTSSM_ENABLE, PCIE_UL_REG_V_SII_GEN_CTRL_01);
> +
> +	ret = visconti_pcie_check_link_status(pcie);
> +	if (ret < 0) {
> +		dev_info(pci->dev, "Link failure\n");
> +		return ret;
> +	}
> +
> +	val = visconti_mpu_readl(pcie, PCIE_MPU_REG_MP_EN);
> +	visconti_mpu_writel(pcie, val & ~MPU_MP_EN_DISABLE, PCIE_MPU_REG_MP_EN);
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_S_INT_EVENT_MASK1_ALL, PCIE_UL_REG_S_INT_EVENT_MASK1);
> +
> +	return 0;
> +}
> +
> +static int visconti_pcie_host_init(struct pcie_port *pp)
> +{
> +	dw_pcie_setup_rc(pp);
> +	return visconti_pcie_establish_link(pp);

This doesn't look like correct usage of the dwc infrastructure.  No
other *_pcie_host_init() functions call dw_pcie_setup_rc().  It'd be
nice if the dwc infrastructure had a little more of a user's guide.
In the meantime, try to copy the structure and style of existing
drivers.

> +}
> +
> +static const struct dw_pcie_host_ops visconti_pcie_host_ops = {
> +	.host_init = visconti_pcie_host_init,
> +};
> +
> +static u64 visconti_pcie_cpu_addr_fixup(struct dw_pcie *pci, u64 pci_addr)
> +{
> +	return pci_addr - PCIE_BUS_OFFSET;
> +}
> +
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +	.cpu_addr_fixup = visconti_pcie_cpu_addr_fixup,
> +};
> +
> +static int visconti_get_resources(struct platform_device *pdev,
> +				  struct visconti_pcie *pcie)
> +{
> +	struct device *dev = &pdev->dev;
> +
> +	pcie->ulreg_base = devm_platform_ioremap_resource_byname(pdev, "ulreg");
> +	if (IS_ERR(pcie->ulreg_base))
> +		return PTR_ERR(pcie->ulreg_base);
> +
> +	pcie->smu_base = devm_platform_ioremap_resource_byname(pdev, "smu");
> +	if (IS_ERR(pcie->smu_base))
> +		return PTR_ERR(pcie->smu_base);
> +
> +	pcie->mpu_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
> +	if (IS_ERR(pcie->mpu_base))
> +		return PTR_ERR(pcie->mpu_base);
> +
> +	pcie->refclk = devm_clk_get(dev, "pcie_refclk");
> +	if (IS_ERR(pcie->refclk)) {
> +		dev_err(dev, "Failed to get refclk clock: %ld\n", PTR_ERR(pcie->refclk));
> +		return PTR_ERR(pcie->refclk);
> +	}
> +
> +	pcie->sysclk = devm_clk_get(dev, "sysclk");
> +	if (IS_ERR(pcie->sysclk)) {
> +		dev_err(dev, "Failed to get sysclk clock: %ld\n", PTR_ERR(pcie->sysclk));
> +		return PTR_ERR(pcie->sysclk);
> +	}
> +
> +	pcie->auxclk = devm_clk_get(dev, "auxclk");
> +	if (IS_ERR(pcie->auxclk)) {
> +		dev_err(dev, "Failed to get auxclk clock: %ld\n", PTR_ERR(pcie->auxclk));
> +		return PTR_ERR(pcie->auxclk);
> +	}
> +
> +	return 0;
> +}
> +
> +static int visconti_device_turnon(struct visconti_pcie *pcie)

There are no other drivers with a *_turnon() function.  Can you copy
a name used in other drivers for similar functionality?  Maybe this
is similar to kirin_pcie_power_on(), meson_pcie_power_on(), etc?

> +{
> +	int err;
> +	u32 val;
> +
> +	visconti_smu_writel(pcie, PISMU_CKON_PCIE_AUX_CLK | PISMU_CKON_PCIE_MSTR_ACLK,
> +			    PISMU_CKON_PCIE);
> +	ndelay(250);
> +
> +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_ULREG_RST_N, PISMU_RSOFF_PCIE);
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_REG_S_PCIE_MODE_RC, PCIE_UL_REG_S_PCIE_MODE);
> +
> +	val = PCIE_UL_IOM_PCIE_PERSTN_I_EN | PCIE_UL_DIRECT_PERSTN_EN | PCIE_UL_DIRECT_PERSTN;
> +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> +	udelay(100);
> +
> +	val |= PCIE_UL_PERSTN_OUT;
> +	visconti_ulreg_writel(pcie, val, PCIE_UL_REG_S_PERSTN_CTRL);
> +	udelay(100);
> +
> +	visconti_smu_writel(pcie, PISMU_RSOFF_PCIE_PWR_UP_RST_N, PISMU_RSOFF_PCIE);
> +
> +	err = readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_PHY_INIT_03, val,
> +				 (val & PCIE_UL_PHY0_SRAM_INIT_DONE), 100, 1000);
> +	if (err)
> +		return err;
> +
> +	visconti_ulreg_writel(pcie, PCIE_UL_PHY0_SRAM_EXT_LD_DONE, PCIE_UL_REG_S_PHY_INIT_02);
> +
> +	return readl_relaxed_poll_timeout(pcie->ulreg_base + PCIE_UL_REG_S_SIG_MON, val,
> +				 (val & PCIE_UL_CORE_RST_N_MON), 100, 1000);
> +}
> +
> +static int visconti_add_pcie_port(struct visconti_pcie *pcie, struct platform_device *pdev)
> +{
> +	struct dw_pcie *pci = &pcie->pci;
> +	struct pcie_port *pp = &pci->pp;
> +	struct device *dev = &pdev->dev;
> +	int ret;
> +
> +	pp->irq = platform_get_irq_byname(pdev, "intr");
> +	if (pp->irq < 0) {
> +		dev_err(dev, "interrupt intr is missing");

Make your error messages consistently capitalized (or consistently not
capitalized).

> +		return pp->irq;
> +	}
> +
> +	pp->ops = &visconti_pcie_host_ops;
> +
> +	pci->link_gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> +	if (pci->link_gen < 0 || pci->link_gen > 3) {
> +		pci->link_gen = 3;
> +		dev_dbg(dev, "Applied default link speed\n");
> +	}
> +
> +	dev_dbg(dev, "link speed Gen %d", pci->link_gen);
> +
> +	ret = visconti_device_turnon(pcie);
> +	if (ret)
> +		goto error;

There's no cleanup, so just "return ret;" here and omit the "error:"
label.

> +	ret = dw_pcie_host_init(pp);
> +	if (ret)
> +		dev_err(dev, "Failed to initialize host\n");
> +
> +error:
> +	return ret;
> +}
> +
> +static int visconti_pcie_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct visconti_pcie *pcie;
> +	struct pcie_port *pp;
> +	struct dw_pcie *pci;
> +	int ret;
> +
> +	ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(36));
> +	if (ret)
> +		return ret;
> +
> +	pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
> +	if (!pcie)
> +		return -ENOMEM;
> +
> +	pci = &pcie->pci;
> +	pp = &pci->pp;
> +	pp->num_vectors = MAX_MSI_IRQS;
> +
> +	pci->dev = dev;
> +	pci->ops = &dw_pcie_ops;
> +
> +	ret = visconti_get_resources(pdev, pcie);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, pcie);
> +
> +	return visconti_add_pcie_port(pcie, pdev);
> +}
> +
> +static const struct of_device_id visconti_pcie_match[] = {
> +	{ .compatible = "toshiba,visconti-pcie" },
> +	{},
> +};
> +
> +static struct platform_driver visconti_pcie_driver = {
> +	.probe = visconti_pcie_probe,
> +	.driver = {
> +		.name = "visconti-pcie",
> +		.of_match_table = visconti_pcie_match,
> +		.suppress_bind_attrs = true,
> +	},
> +};
> +
> +builtin_platform_driver(visconti_pcie_driver);
> -- 
> 2.30.0.rc2
> 


From laurent.pinchart at ideasonboard.com  Fri Apr 30 01:36:23 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 30 Apr 2021 03:36:23 +0300
Subject: [PATCH] dmaengine: xilinx: dpdma: request_irq after initializing
 dma channels
In-Reply-To: <20210429065821.3495234-1-quanyang.wang@windriver.com>
References: <20210429065821.3495234-1-quanyang.wang@windriver.com>
Message-ID: <YItRB7SBhiilzDLk@pendragon.ideasonboard.com>

Hi Quanyang,

Thank you for the patch.

On Thu, Apr 29, 2021 at 02:58:21PM +0800, quanyang.wang at windriver.com wrote:
> From: Quanyang Wang <quanyang.wang at windriver.com>
> 
> In some scenarios (kdump), dpdma hardware irqs has been enabled when
> calling request_irq in probe function, and then the dpdma irq handler
> xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
> this moment xdev->chan[i] hasn't been initialized. So let's call the
> request_irq after initializing dma channels to avoid kdump kernel
> crash as below:
> 
> [    3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c
> [    3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed
> [    3.704900] Mem abort info:
> [    3.704902]   ESR = 0x96000005
> [    3.704905]   EC = 0x25: DABT (current EL), IL = 32 bits
> [    3.704907]   SET = 0, FnV = 0
> [    3.704912]   EA = 0, S1PTW = 0
> [    3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator
> [    3.715585] Data abort info:
> [    3.715587]   ISV = 0, ISS = 0x00000005
> [    3.715589]   CM = 0, WnR = 0
> [    3.715592] [000000000000012c] user address but active_mm is swapper
> [    3.715596] Internal error: Oops: 96000005 [#1] SMP
> [    3.715599] Modules linked in:
> [    3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77
> [    3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
> [    3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
> [    3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
> [    3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
> [    3.798089] sp : ffffffc01186bdf0
> [    3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
> [    3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
> [    3.811996] x25: 0000000008000408 x24: 0000000000000003
> [    3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
> [    3.822604] x21: 0000000000000000 x20: 0000000008000408
> [    3.827908] x19: 0000000000000000 x18: 0000000000000010
> [    3.833212] x17: 0000000000000000 x16: 0000000000000000
> [    3.838516] x15: 0000000000000000 x14: ffffffc011291740
> [    3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
> [    3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
> [    3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
> [    3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
> [    3.865036] x5 : 0000000000000003 x4 : 0000000000000000
> [    3.870340] x3 : 0000000000000001 x2 : 0000000000000000
> [    3.875644] x1 : 0000000000000000 x0 : 000000000000012c
> [    3.880948] Call trace:
> [    3.883382]  xilinx_dpdma_irq_handler+0x418/0x560
> [    3.888079]  __handle_irq_event_percpu+0x5c/0x178
> [    3.892774]  handle_irq_event_percpu+0x34/0x98
> [    3.897210]  handle_irq_event+0x44/0xb8
> [    3.901030]  handle_fasteoi_irq+0xd0/0x190
> [    3.905117]  generic_handle_irq+0x30/0x48
> [    3.909111]  __handle_domain_irq+0x64/0xc0
> [    3.913192]  gic_handle_irq+0x78/0xa0
> [    3.916846]  el1_irq+0xc4/0x180
> [    3.919982]  cpuidle_enter_state+0x134/0x2f8
> [    3.924243]  cpuidle_enter+0x38/0x50
> [    3.927810]  call_cpuidle+0x1c/0x40
> [    3.931290]  do_idle+0x20c/0x270
> [    3.934502]  cpu_startup_entry+0x28/0x58
> [    3.938410]  rest_init+0xbc/0xcc
> [    3.941631]  arch_call_rest_init+0x10/0x1c
> [    3.945718]  start_kernel+0x51c/0x558
> 
> Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver")
> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
> ---
>  drivers/dma/xilinx/xilinx_dpdma.c | 30 +++++++++++++++---------------
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
> index 70b29bd079c9..0b599402c53f 100644
> --- a/drivers/dma/xilinx/xilinx_dpdma.c
> +++ b/drivers/dma/xilinx/xilinx_dpdma.c
> @@ -1622,19 +1622,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>  	if (IS_ERR(xdev->reg))
>  		return PTR_ERR(xdev->reg);
>  
> -	xdev->irq = platform_get_irq(pdev, 0);
> -	if (xdev->irq < 0) {
> -		dev_err(xdev->dev, "failed to get platform irq\n");
> -		return xdev->irq;
> -	}
> -
> -	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
> -			  dev_name(xdev->dev), xdev);
> -	if (ret) {
> -		dev_err(xdev->dev, "failed to request IRQ\n");
> -		return ret;
> -	}
> -
>  	ddev = &xdev->common;
>  	ddev->dev = &pdev->dev;
>  
> @@ -1688,6 +1675,19 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>  		goto error_of_dma;
>  	}
>  
> +	xdev->irq = platform_get_irq(pdev, 0);
> +	if (xdev->irq < 0) {
> +		dev_err(xdev->dev, "failed to get platform irq\n");

As reported by the kbuild bot, ret isn't initialized here.

> +		goto error_irq;
> +	}

This part could stay where it was, just after
devm_platform_ioremap_resource().

> +
> +	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
> +			  dev_name(xdev->dev), xdev);
> +	if (ret) {
> +		dev_err(xdev->dev, "failed to request IRQ\n");
> +		goto error_irq;
> +	}

Ideally we should reset the device before requesting the IRQ, to ensure
we start in a consistent state. There doesn't seem to be any global
reset unfortunately. Shouldn't we at least disable interrupts ? It may
be a bit pointless though as we reenable them right below, so I suppose
this would be OK.

> +
>  	xilinx_dpdma_enable_irq(xdev);
>  
>  	xilinx_dpdma_debugfs_init(xdev);
> @@ -1696,6 +1696,8 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>  
>  	return 0;
>  
> +error_irq:
> +	of_dma_controller_free(pdev->dev.of_node);

Why not free_irq() ? This change isn't described in the commit message.

>  error_of_dma:
>  	dma_async_device_unregister(ddev);
>  error_dma_async:
> @@ -1704,8 +1706,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>  	for (i = 0; i < ARRAY_SIZE(xdev->chan); i++)
>  		xilinx_dpdma_chan_remove(xdev->chan[i]);
>  
> -	free_irq(xdev->irq, xdev);
> -
>  	return ret;
>  }
>  

-- 
Regards,

Laurent Pinchart


From cl at rock-chips.com  Fri Apr 30 01:47:18 2021
From: cl at rock-chips.com (=?UTF-8?B?6ZmI5Lqu?=)
Date: Fri, 30 Apr 2021 08:47:18 +0800
Subject: =?UTF-8?Q?Re=3a_=5bPATCH_v4_07/10=5d_dt-bindings=3a_soc=3a_rockchip?=
 =?UTF-8?B?OiBDb252ZXJ0IGdyZi50eHQgdG8gWUFNTOOAkOivt+azqOaEj++8jOmCruS7tg==?=
 =?UTF-8?B?55Sxcm9iaGVycmluZzJAZ21haWwuY29t5Luj5Y+R44CR?=
In-Reply-To: <20210429212413.GA1794356@robh.at.kernel.org>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081321.17855-1-cl@rock-chips.com>
 <20210429212413.GA1794356@robh.at.kernel.org>
Message-ID: <24118cb2-dc11-eef1-b0e3-26318c2615ab@rock-chips.com>


? 2021/4/30 ??5:24, Rob Herring ??:
> On Thu, Apr 29, 2021 at 04:13:21PM +0800, cl at rock-chips.com wrote:
>> From: Liang Chen <cl at rock-chips.com>
>>
>> Current dts files with 'grf' nodes are manually verified. In order to
>> automate this process grf.txt has to be converted to YAML.
>>
>> Add new descriptions for:
>> "rockchip,rk3568-grf", "syscon", "simple-mfd"
>> "rockchip,rk3568-pmugrf", "syscon", "simple-mfd"
>>
>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> ---
>>   .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>>   .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
>>   2 files changed, 60 insertions(+), 61 deletions(-)
>>   delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>>   create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
>> deleted file mode 100644
>> index f96511aa3897..000000000000
>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
>> +++ /dev/null
>> @@ -1,61 +0,0 @@
>> -* Rockchip General Register Files (GRF)
>> -
>> -The general register file will be used to do static set by software, which
>> -is composed of many registers for system control.
>> -
>> -From RK3368 SoCs, the GRF is divided into two sections,
>> -- GRF, used for general non-secure system,
>> -- SGRF, used for general secure system,
>> -- PMUGRF, used for always on system
>> -
>> -On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
>> -
>> -ON RK3308 SoC, the GRF is divided into four sections:
>> -- GRF, used for general non-secure system,
>> -- SGRF, used for general secure system,
>> -- DETECTGRF, used for audio codec system,
>> -- COREGRF, used for pvtm,
>> -
>> -Required Properties:
>> -
>> -- compatible: GRF should be one of the following:
>> -   - "rockchip,px30-grf", "syscon": for px30
>> -   - "rockchip,rk3036-grf", "syscon": for rk3036
>> -   - "rockchip,rk3066-grf", "syscon": for rk3066
>> -   - "rockchip,rk3188-grf", "syscon": for rk3188
>> -   - "rockchip,rk3228-grf", "syscon": for rk3228
>> -   - "rockchip,rk3288-grf", "syscon": for rk3288
>> -   - "rockchip,rk3308-grf", "syscon": for rk3308
>> -   - "rockchip,rk3328-grf", "syscon": for rk3328
>> -   - "rockchip,rk3368-grf", "syscon": for rk3368
>> -   - "rockchip,rk3399-grf", "syscon": for rk3399
>> -   - "rockchip,rv1108-grf", "syscon": for rv1108
>> -- compatible: DETECTGRF should be one of the following:
>> -   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
>> -- compatilbe: COREGRF should be one of the following:
>> -   - "rockchip,rk3308-core-grf", "syscon": for rk3308
>> -- compatible: PMUGRF should be one of the following:
>> -   - "rockchip,px30-pmugrf", "syscon": for px30
>> -   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
>> -   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
>> -- compatible: SGRF should be one of the following:
>> -   - "rockchip,rk3288-sgrf", "syscon": for rk3288
>> -- compatible: USB2PHYGRF should be one of the following:
>> -   - "rockchip,px30-usb2phy-grf", "syscon": for px30
>> -   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
>> -- compatible: USBGRF should be one of the following:
>> -   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
>> -- reg: physical base address of the controller and length of memory mapped
>> -  region.
>> -
>> -Example: GRF and PMUGRF of RK3399 SoCs
>> -
>> -	pmugrf: syscon at ff320000 {
>> -		compatible = "rockchip,rk3399-pmugrf", "syscon";
>> -		reg = <0x0 0xff320000 0x0 0x1000>;
>> -	};
>> -
>> -	grf: syscon at ff770000 {
>> -		compatible = "rockchip,rk3399-grf", "syscon";
>> -		reg = <0x0 0xff770000 0x0 0x10000>;
>> -	};
>> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>> new file mode 100644
>> index 000000000000..93231b95554b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>> @@ -0,0 +1,60 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Rockchip General Register Files
>> +
>> +maintainers:
>> +  - Heiko Stuebner <heiko at sntech.de>
>> +
>> +properties:
>> +  compatible:
>> +    - items:
> The '-' is the source of your error.
Thanks.
>
>> +        - enum:
>> +            - rockchip,px30-grf
>> +            - rockchip,px30-pmugrf
>> +            - rockchip,px30-usb2phy-grf
>> +            - rockchip,rk3036-grf
>> +            - rockchip,rk3066-grf
>> +            - rockchip,rk3188-grf
>> +            - rockchip,rk3228-grf
>> +            - rockchip,rk3288-grf
>> +            - rockchip,rk3288-sgrf
>> +            - rockchip,rk3308-core-grf
>> +            - rockchip,rk3308-detect-grf
>> +            - rockchip,rk3308-grf
>> +            - rockchip,rk3328-grf
>> +            - rockchip,rk3328-usb2phy-grf
>> +            - rockchip,rk3368-grf
>> +            - rockchip,rk3368-pmugrf
>> +            - rockchip,rk3399-grf
>> +            - rockchip,rk3399-pmugrf
>> +            - rockchip,rk3568-grf
>> +            - rockchip,rk3568-pmugrf
>> +            - rockchip,rv1108-grf
>> +            - rockchip,rv1108-usbgrf
>> +        - const: syscon
>> +        - const: simple-mfd
> 'simple-mfd' was not in the old binding. That implies you have child
> nodes, and if so, they need to be documented. I imagine that will mean
> splitting this into multiple schemas if that's the case.
Maybe add the child nodes and document in a new submit.
>> documented
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    pmugrf: syscon at ff320000 {
>> +       compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
>> +       reg = <0xff320000 0x1000>;
>> +    };
>> +
>> +    grf: syscon at ff770000 {
>> +       compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
>> +       reg = <0xff770000 0x10000>;
>> +    };
>> -- 
>> 2.17.1
>>
>>
>>
>
>




From cl at rock-chips.com  Fri Apr 30 01:57:08 2021
From: cl at rock-chips.com (cl at rock-chips.com)
Date: Fri, 30 Apr 2021 08:57:08 +0800
Subject: [RESEND PATCH v4 07/10] dt-bindings: soc: rockchip: Convert grf.txt
 to YAML
In-Reply-To: <20210429081151.17558-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
Message-ID: <20210430005708.1821-1-cl@rock-chips.com>

From: Liang Chen <cl at rock-chips.com>

Current dts files with 'grf' nodes are manually verified. In order to
automate this process grf.txt has to be converted to YAML.

Add new descriptions for:
"rockchip,rk3568-grf", "syscon", "simple-mfd"
"rockchip,rk3568-pmugrf", "syscon", "simple-mfd"

Signed-off-by: Liang Chen <cl at rock-chips.com>
---
 .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
 .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
 2 files changed, 60 insertions(+), 61 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
deleted file mode 100644
index f96511aa3897..000000000000
--- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-* Rockchip General Register Files (GRF)
-
-The general register file will be used to do static set by software, which
-is composed of many registers for system control.
-
-From RK3368 SoCs, the GRF is divided into two sections,
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- PMUGRF, used for always on system
-
-On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
-
-ON RK3308 SoC, the GRF is divided into four sections:
-- GRF, used for general non-secure system,
-- SGRF, used for general secure system,
-- DETECTGRF, used for audio codec system,
-- COREGRF, used for pvtm,
-
-Required Properties:
-
-- compatible: GRF should be one of the following:
-   - "rockchip,px30-grf", "syscon": for px30
-   - "rockchip,rk3036-grf", "syscon": for rk3036
-   - "rockchip,rk3066-grf", "syscon": for rk3066
-   - "rockchip,rk3188-grf", "syscon": for rk3188
-   - "rockchip,rk3228-grf", "syscon": for rk3228
-   - "rockchip,rk3288-grf", "syscon": for rk3288
-   - "rockchip,rk3308-grf", "syscon": for rk3308
-   - "rockchip,rk3328-grf", "syscon": for rk3328
-   - "rockchip,rk3368-grf", "syscon": for rk3368
-   - "rockchip,rk3399-grf", "syscon": for rk3399
-   - "rockchip,rv1108-grf", "syscon": for rv1108
-- compatible: DETECTGRF should be one of the following:
-   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
-- compatilbe: COREGRF should be one of the following:
-   - "rockchip,rk3308-core-grf", "syscon": for rk3308
-- compatible: PMUGRF should be one of the following:
-   - "rockchip,px30-pmugrf", "syscon": for px30
-   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
-   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
-- compatible: SGRF should be one of the following:
-   - "rockchip,rk3288-sgrf", "syscon": for rk3288
-- compatible: USB2PHYGRF should be one of the following:
-   - "rockchip,px30-usb2phy-grf", "syscon": for px30
-   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
-- compatible: USBGRF should be one of the following:
-   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
-- reg: physical base address of the controller and length of memory mapped
-  region.
-
-Example: GRF and PMUGRF of RK3399 SoCs
-
-	pmugrf: syscon at ff320000 {
-		compatible = "rockchip,rk3399-pmugrf", "syscon";
-		reg = <0x0 0xff320000 0x0 0x1000>;
-	};
-
-	grf: syscon at ff770000 {
-		compatible = "rockchip,rk3399-grf", "syscon";
-		reg = <0x0 0xff770000 0x0 0x10000>;
-	};
diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
new file mode 100644
index 000000000000..21a67b9ae59c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip General Register Files
+
+maintainers:
+  - Heiko Stuebner <heiko at sntech.de>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - rockchip,px30-grf
+          - rockchip,px30-pmugrf
+          - rockchip,px30-usb2phy-grf
+          - rockchip,rk3036-grf
+          - rockchip,rk3066-grf
+          - rockchip,rk3188-grf
+          - rockchip,rk3228-grf
+          - rockchip,rk3288-grf
+          - rockchip,rk3288-sgrf
+          - rockchip,rk3308-core-grf
+          - rockchip,rk3308-detect-grf
+          - rockchip,rk3308-grf
+          - rockchip,rk3328-grf
+          - rockchip,rk3328-usb2phy-grf
+          - rockchip,rk3368-grf
+          - rockchip,rk3368-pmugrf
+          - rockchip,rk3399-grf
+          - rockchip,rk3399-pmugrf
+          - rockchip,rk3568-grf
+          - rockchip,rk3568-pmugrf
+          - rockchip,rv1108-grf
+          - rockchip,rv1108-usbgrf
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    pmugrf: syscon at ff320000 {
+       compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
+       reg = <0xff320000 0x1000>;
+    };
+
+    grf: syscon at ff770000 {
+       compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
+       reg = <0xff770000 0x10000>;
+    };
-- 
2.17.1





From yangjihong1 at huawei.com  Fri Apr 30 02:26:59 2021
From: yangjihong1 at huawei.com (Yang Jihong)
Date: Fri, 30 Apr 2021 09:26:59 +0800
Subject: [PATCH] arm_pmu: Fix write counter incorrect in ARMv7 big-endian mode
Message-ID: <20210430012659.232110-1-yangjihong1@huawei.com>

Commit 3a95200d3f89a ("arm_pmu: Change API to support 64bit counter values")
changes the input "value" type from 32-bit to 64-bit,
which introduces the following problem:
ARMv7 PMU counters is 32-bit width, in big-endian mode, write counter uses
high 32-bit, which writes an incorrect value.

Before:

 Performance counter stats for 'ls':

              2.22 msec task-clock                #    0.675 CPUs utilized
                 0      context-switches          #    0.000 K/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.022 M/sec
        2150476593      cycles                    #  966.663 GHz
        2148588788      instructions              #    1.00  insn per cycle
        2147745484      branches                  # 965435.074 M/sec
        2147508540      branch-misses             #   99.99% of all branches

None of the above hw event counters are correct.

Solution:

"value" forcibly converted to 32-bit type before being written to PMU register.

After:

 Performance counter stats for 'ls':

              2.09 msec task-clock                #    0.681 CPUs utilized
                 0      context-switches          #    0.000 K/sec
                 0      cpu-migrations            #    0.000 K/sec
                46      page-faults               #    0.022 M/sec
           2807301      cycles                    #    1.344 GHz
           1060159      instructions              #    0.38  insn per cycle
            250496      branches                  #  119.914 M/sec
             23192      branch-misses             #    9.26% of all branches

Fixes: 3a95200d3f89a ("arm_pmu: Change API to support 64bit counter values")
Signed-off-by: Yang Jihong <yangjihong1 at huawei.com>
---
 arch/arm/kernel/perf_event_v7.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 2924d7910b10..eb2190477da1 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -773,10 +773,10 @@ static inline void armv7pmu_write_counter(struct perf_event *event, u64 value)
 		pr_err("CPU%u writing wrong counter %d\n",
 			smp_processor_id(), idx);
 	} else if (idx == ARMV7_IDX_CYCLE_COUNTER) {
-		asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (value));
+		asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" ((u32)value));
 	} else {
 		armv7_pmnc_select_counter(idx);
-		asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" (value));
+		asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" ((u32)value));
 	}
 }
 
-- 
2.30.GIT



From peng.fan at nxp.com  Fri Apr 30 02:33:59 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Fri, 30 Apr 2021 01:33:59 +0000
Subject: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
In-Reply-To: <CAHCN7xL11GUSVB3PThsfhxXPtgu1nm1LWSzkJYqj4MHf-aLbVw@mail.gmail.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <CAHCN7xL11GUSVB3PThsfhxXPtgu1nm1LWSzkJYqj4MHf-aLbVw@mail.gmail.com>
Message-ID: <DB6PR0402MB276065DF476EBEDABF312CF9885E9@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> Subject: Re: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
> 
> On Thu, Apr 29, 2021 at 1:59 AM Peng Fan (OSS) <peng.fan at oss.nxp.com>
> wrote:
> >
> > From: Peng Fan <peng.fan at nxp.com>
> >
> > This patchset is a pick up Lucas's gpcv2 work for i.MX8MM and several
> > minor changes from me to make it could work with i.MX BLK-CTL driver.
> >
> > Thanks for Lucas's work and suggestion, Frieder Schrempf for
> > collecting all the patches, Jacky Bai on help debug issues.
> 
> Thank for you all the work.  I have an i.MX8M Nano that I'll work to add
> support for gpcv2 unless NXP has started this already.  At one time, I posted
> some patches for Nano based on Lucas' work, but since that work wasn't
> accepted, mine wasn't either.

Please continue your work on i.MX8MN, I not work on this. The following
work from me is i.MX8MP.

Thanks,
Peng.

> 
> adam
> >
> > Lucas Stach (12):
> >   soc: imx: gpcv2: move to more ideomatic error handling in probe
> >   soc: imx: gpcv2: move domain mapping to domain driver probe
> >   soc: imx: gpcv2: switch to clk_bulk_* API
> >   soc: imx: gpcv2: split power up and power down sequence control
> >   soc: imx: gpcv2: wait for ADB400 handshake
> >   soc: imx: gpcv2: add runtime PM support for power-domains
> >   soc: imx: gpcv2: allow domains without power-sequence control
> >   dt-bindings: imx: gpcv2: add support for optional resets
> >   soc: imx: gpcv2: add support for optional resets
> >   dt-bindings: power: add defines for i.MX8MM power domains
> >   soc: imx: gpcv2: add support for i.MX8MM power domains
> >   soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX power
> >     domains
> >
> > Peng Fan (4):
> >   soc: imx: gpcv2: correct pm_runtime_get_sync usage
> >   soc: imx: gpcv2: move reset assert after requesting domain power up
> >   soc: imx: gpcv2: support reset defer probe
> >   soc: imx: gpcv2: remove waiting handshake in power up
> >
> >  .../bindings/power/fsl,imx-gpcv2.yaml         |   9 +
> >  drivers/soc/imx/gpcv2.c                       | 534
> ++++++++++++++----
> >  include/dt-bindings/power/imx8mm-power.h      |  22 +
> >  3 files changed, 450 insertions(+), 115 deletions(-)  create mode
> > 100644 include/dt-bindings/power/imx8mm-power.h
> >
> > --
> > 2.30.0
> >

From sboyd at kernel.org  Fri Apr 30 02:42:07 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Thu, 29 Apr 2021 18:42:07 -0700
Subject: [RESEND PATCH v7 01/22] dt-bindings: ARM: Mediatek: Add new
 document bindings of imp i2c wrapper controller
In-Reply-To: <20210324104110.13383-2-chun-jie.chen@mediatek.com>
References: <20210324104110.13383-1-chun-jie.chen@mediatek.com>
 <20210324104110.13383-2-chun-jie.chen@mediatek.com>
Message-ID: <161974692707.177949.4882672793905809142@swboyd.mtv.corp.google.com>

Please Cc devicetree at vger.kernel.org and use robh+dt at kernel.org for DT
bindings. This was waiting for DT review but because the right lists
weren't Cced it fell off the queue.

Quoting chun-jie.chen (2021-03-24 03:40:49)
> This patch adds the new binding documentation of imp i2c wrapper controller
> for Mediatek MT8192.
> 
> Signed-off-by: Weiyi Lu <weiyi.lu at mediatek.com>
> Signed-off-by: chun-jie.chen <chun-jie.chen at mediatek.com>
> ---
>  .../arm/mediatek/mediatek,imp_iic_wrap.yaml   | 80 +++++++++++++++++++
>  1 file changed, 80 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
> new file mode 100644
> index 000000000000..fb6cb9e60ee2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,imp_iic_wrap.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek IMP I2C Wrapper Controller
> +
> +maintainers:
> +  - Chun-Jie Chen <chun-jie.chen at mediatek.com>
> +
> +description:
> +  The Mediatek imp i2c wrapper controller provides functional configurations and clocks to the system.
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - mediatek,mt8192-imp_iic_wrap_c
> +          - mediatek,mt8192-imp_iic_wrap_e
> +          - mediatek,mt8192-imp_iic_wrap_s
> +          - mediatek,mt8192-imp_iic_wrap_ws
> +          - mediatek,mt8192-imp_iic_wrap_w
> +          - mediatek,mt8192-imp_iic_wrap_n
> +      - const: syscon
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#clock-cells':
> +    const: 1
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    imp_iic_wrap_c: syscon at 11007000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_c", "syscon";
> +        reg = <0x11007000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    imp_iic_wrap_e: syscon at 11cb1000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_e", "syscon";
> +        reg = <0x11cb1000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    imp_iic_wrap_s: syscon at 11d03000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_s", "syscon";
> +        reg = <0x11d03000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    imp_iic_wrap_ws: syscon at 11d23000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_ws", "syscon";
> +        reg = <0x11d23000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    imp_iic_wrap_w: syscon at 11e01000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_w", "syscon";
> +        reg = <0x11e01000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> +
> +  - |
> +    imp_iic_wrap_n: syscon at 11f02000 {
> +        compatible = "mediatek,mt8192-imp_iic_wrap_n", "syscon";
> +        reg = <0x11f02000 0x1000>;
> +        #clock-cells = <1>;
> +    };
> -- 
> 2.18.0
>


From quanyang.wang at windriver.com  Fri Apr 30 02:45:25 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Fri, 30 Apr 2021 09:45:25 +0800
Subject: [PATCH] dmaengine: xilinx: dpdma: request_irq after initializing
 dma channels
In-Reply-To: <YItRB7SBhiilzDLk@pendragon.ideasonboard.com>
References: <20210429065821.3495234-1-quanyang.wang@windriver.com>
 <YItRB7SBhiilzDLk@pendragon.ideasonboard.com>
Message-ID: <1d88d67b-aaf5-823d-0cf6-c9422c01918c@windriver.com>

Hi Laurent,

On 4/30/21 8:36 AM, Laurent Pinchart wrote:
> Hi Quanyang,
>
> Thank you for the patch.
>
> On Thu, Apr 29, 2021 at 02:58:21PM +0800, quanyang.wang at windriver.com wrote:
>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>
>> In some scenarios (kdump), dpdma hardware irqs has been enabled when
>> calling request_irq in probe function, and then the dpdma irq handler
>> xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
>> this moment xdev->chan[i] hasn't been initialized. So let's call the
>> request_irq after initializing dma channels to avoid kdump kernel
>> crash as below:
>>
>> [    3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c
>> [    3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed
>> [    3.704900] Mem abort info:
>> [    3.704902]   ESR = 0x96000005
>> [    3.704905]   EC = 0x25: DABT (current EL), IL = 32 bits
>> [    3.704907]   SET = 0, FnV = 0
>> [    3.704912]   EA = 0, S1PTW = 0
>> [    3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator
>> [    3.715585] Data abort info:
>> [    3.715587]   ISV = 0, ISS = 0x00000005
>> [    3.715589]   CM = 0, WnR = 0
>> [    3.715592] [000000000000012c] user address but active_mm is swapper
>> [    3.715596] Internal error: Oops: 96000005 [#1] SMP
>> [    3.715599] Modules linked in:
>> [    3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77
>> [    3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
>> [    3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
>> [    3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
>> [    3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
>> [    3.798089] sp : ffffffc01186bdf0
>> [    3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
>> [    3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
>> [    3.811996] x25: 0000000008000408 x24: 0000000000000003
>> [    3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
>> [    3.822604] x21: 0000000000000000 x20: 0000000008000408
>> [    3.827908] x19: 0000000000000000 x18: 0000000000000010
>> [    3.833212] x17: 0000000000000000 x16: 0000000000000000
>> [    3.838516] x15: 0000000000000000 x14: ffffffc011291740
>> [    3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
>> [    3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
>> [    3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
>> [    3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
>> [    3.865036] x5 : 0000000000000003 x4 : 0000000000000000
>> [    3.870340] x3 : 0000000000000001 x2 : 0000000000000000
>> [    3.875644] x1 : 0000000000000000 x0 : 000000000000012c
>> [    3.880948] Call trace:
>> [    3.883382]  xilinx_dpdma_irq_handler+0x418/0x560
>> [    3.888079]  __handle_irq_event_percpu+0x5c/0x178
>> [    3.892774]  handle_irq_event_percpu+0x34/0x98
>> [    3.897210]  handle_irq_event+0x44/0xb8
>> [    3.901030]  handle_fasteoi_irq+0xd0/0x190
>> [    3.905117]  generic_handle_irq+0x30/0x48
>> [    3.909111]  __handle_domain_irq+0x64/0xc0
>> [    3.913192]  gic_handle_irq+0x78/0xa0
>> [    3.916846]  el1_irq+0xc4/0x180
>> [    3.919982]  cpuidle_enter_state+0x134/0x2f8
>> [    3.924243]  cpuidle_enter+0x38/0x50
>> [    3.927810]  call_cpuidle+0x1c/0x40
>> [    3.931290]  do_idle+0x20c/0x270
>> [    3.934502]  cpu_startup_entry+0x28/0x58
>> [    3.938410]  rest_init+0xbc/0xcc
>> [    3.941631]  arch_call_rest_init+0x10/0x1c
>> [    3.945718]  start_kernel+0x51c/0x558
>>
>> Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver")
>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>> ---
>>   drivers/dma/xilinx/xilinx_dpdma.c | 30 +++++++++++++++---------------
>>   1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
>> index 70b29bd079c9..0b599402c53f 100644
>> --- a/drivers/dma/xilinx/xilinx_dpdma.c
>> +++ b/drivers/dma/xilinx/xilinx_dpdma.c
>> @@ -1622,19 +1622,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>>   	if (IS_ERR(xdev->reg))
>>   		return PTR_ERR(xdev->reg);
>>   
>> -	xdev->irq = platform_get_irq(pdev, 0);
>> -	if (xdev->irq < 0) {
>> -		dev_err(xdev->dev, "failed to get platform irq\n");
>> -		return xdev->irq;
>> -	}
>> -
>> -	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>> -			  dev_name(xdev->dev), xdev);
>> -	if (ret) {
>> -		dev_err(xdev->dev, "failed to request IRQ\n");
>> -		return ret;
>> -	}
>> -
>>   	ddev = &xdev->common;
>>   	ddev->dev = &pdev->dev;
>>   
>> @@ -1688,6 +1675,19 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>>   		goto error_of_dma;
>>   	}
>>   
>> +	xdev->irq = platform_get_irq(pdev, 0);
>> +	if (xdev->irq < 0) {
>> +		dev_err(xdev->dev, "failed to get platform irq\n");
> As reported by the kbuild bot, ret isn't initialized here.
I will fix this in V2.
>
>> +		goto error_irq;
>> +	}
> This part could stay where it was, just after
> devm_platform_ioremap_resource().
OK?I will move it back.
>
>> +
>> +	ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>> +			  dev_name(xdev->dev), xdev);
>> +	if (ret) {
>> +		dev_err(xdev->dev, "failed to request IRQ\n");
>> +		goto error_irq;
>> +	}
> Ideally we should reset the device before requesting the IRQ, to ensure
> we start in a consistent state. There doesn't seem to be any global
> reset unfortunately. Shouldn't we at least disable interrupts ? It may
> be a bit pointless though as we reenable them right below, so I suppose
> this would be OK.

Yes, we should start in a consistent and clean state. I will disable 
interrupts

and clean up registers state in V2.

>
>> +
>>   	xilinx_dpdma_enable_irq(xdev);
>>   
>>   	xilinx_dpdma_debugfs_init(xdev);
>> @@ -1696,6 +1696,8 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>>   
>>   	return 0;
>>   
>> +error_irq:
>> +	of_dma_controller_free(pdev->dev.of_node);
> Why not free_irq() ? This change isn't described in the commit message.

I will add it in V2.

Thanks,

Quanyang

>
>>   error_of_dma:
>>   	dma_async_device_unregister(ddev);
>>   error_dma_async:
>> @@ -1704,8 +1706,6 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
>>   	for (i = 0; i < ARRAY_SIZE(xdev->chan); i++)
>>   		xilinx_dpdma_chan_remove(xdev->chan[i]);
>>   
>> -	free_irq(xdev->irq, xdev);
>> -
>>   	return ret;
>>   }
>>   


From sboyd at kernel.org  Fri Apr 30 03:17:14 2021
From: sboyd at kernel.org (Stephen Boyd)
Date: Thu, 29 Apr 2021 19:17:14 -0700
Subject: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE
In-Reply-To: <87v98dqzfe.fsf@kokedama.swc.toshiba.co.jp>
References: <20210421134844.3297838-1-arnd@kernel.org>
 <871rb2swd9.fsf@kokedama.swc.toshiba.co.jp>
 <01e78b64-8ad1-dfc8-9fc0-6afff4841492@xilinx.com>
 <87v98dqzfe.fsf@kokedama.swc.toshiba.co.jp>
Message-ID: <161974903429.177949.6659170601321970979@swboyd.mtv.corp.google.com>

Quoting Punit Agrawal (2021-04-22 23:37:25)
> Michal Simek <michal.simek at xilinx.com> writes:
> >
> >
> >>>  
> >>>     rate =  parent_rate * fbdiv;
> >>>     if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
> >> 
> >> The changes make sense in that the functions error out sensibly when the
> >> zynqmp firmware driver is not enabled.
> >> 
> >> Acked-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>
> >
> > I think code should be checked that these error values are handled how
> > they should be handled.
> 
> I only looked at it from the point of view of getting rid of the
> warnings - based on the commit log, Arnd's patch is only taking care of
> the compiler warnings when the driver is built with
> CONFIG_COMPILE_TEST=y and likely CONFIG_ZYNQMP_FIRMWARE=n.

The subject line basically says this.

> 
> In practice, the code should not be hit at runtime due to the dependency
> on the firmware driver. Even then, a better fix would indeed be taking
> the returned values at call sites into account.

Still needs to be fixed. If a better patch is sent I would apply it, but
if that isn't going to happen I'll apply this one.


From roman.beranek at prusa3d.cz  Fri Apr 30 03:19:32 2021
From: roman.beranek at prusa3d.cz (=?UTF-8?Q?Roman_Ber=C3=A1nek?=)
Date: Fri, 30 Apr 2021 04:19:32 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <20210429120416.5ba7rq5fvhcfebzz@pengutronix.de>
References: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
 <20210428061357.725m72aikc52n4gg@pengutronix.de>
 <CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ@mail.gmail.com>
 <20210429120416.5ba7rq5fvhcfebzz@pengutronix.de>
Message-ID: <CAL8eAtqBzUt6fP2nr-Ppg+qwhvKWk13A0P3+hoe07F+9VXCvmA@mail.gmail.com>

Hello Uwe,

On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:
>
> Hello Roman,
>
> On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Ber?nek wrote:
> > Correct, the output may stay in an active state. I only discovered this
> > bug as I investigated a report of unreliable screen timeout. The period
> > we use the PWM with is 50 us.
>
> What I don't like here is that the delay is quite coarse and might still
> be too short. (Maybe I miss something, but consider the current period
> is quite long, then you configure a short one and then disable. In this
> case the inital long setting might still be active.)

The delay is calculated from the original period (cstate.period),
not the one that was just written into PWM_CHx_PRD 2 lines above.

> > Note: my apologies for the previous HTML message
>
> I didn't notice (because the message also contained a txt part). Another
> thing to improve is to reply inline instead of top posting :-)

Yeah, learning the conventions one reply at a time :-)

Cheers,
Roman


From mdf at kernel.org  Fri Apr 30 03:28:55 2021
From: mdf at kernel.org (Moritz Fischer)
Date: Thu, 29 Apr 2021 19:28:55 -0700
Subject: [PATCH v4 0/4] Add Bitstream configuration support for Versal
In-Reply-To: <20210429140408.23194-1-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
Message-ID: <YItrZ/XTk8Ha0pAZ@epycbox.lan>

Hi,

On Thu, Apr 29, 2021 at 07:34:04PM +0530, Nava kishore Manne wrote:
> This series Adds FPGA manager driver support for Xilinx Versal SoC.
> it uses the firmware interface to configure the programmable logic.
> 
> Changes for v4:
> 		-Rebase the patch series on linux-next.
> 		https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 
> Appana Durga Kedareswara rao (1):
>   dt-bindings: fpga: Add binding doc for versal fpga manager
> 
> Nava kishore Manne (3):
>   dt-bindings: firmware: Add bindings for xilinx firmware
>   drivers: firmware: Add PDI load API support
>   fpga: versal-fpga: Add versal fpga manager driver
> 
>  .../firmware/xilinx/xlnx,zynqmp-firmware.yaml |  63 ++++++++++
>  .../bindings/fpga/xlnx,versal-fpga.yaml       |  33 +++++
>  drivers/firmware/xilinx/zynqmp.c              |  17 +++
>  drivers/fpga/Kconfig                          |   9 ++
>  drivers/fpga/Makefile                         |   1 +
>  drivers/fpga/versal-fpga.c                    | 117 ++++++++++++++++++
>  include/linux/firmware/xlnx-zynqmp.h          |  10 ++
>  7 files changed, 250 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
>  create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml
>  create mode 100644 drivers/fpga/versal-fpga.c
> 
> -- 
> 2.17.1
> 
Series looks good, will wait for Rob's Acks on the DT part.

Thanks,
Moritz


From aford173 at gmail.com  Fri Apr 30 04:05:34 2021
From: aford173 at gmail.com (Adam Ford)
Date: Thu, 29 Apr 2021 22:05:34 -0500
Subject: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
In-Reply-To: <DB6PR0402MB276065DF476EBEDABF312CF9885E9@DB6PR0402MB2760.eurprd04.prod.outlook.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <CAHCN7xL11GUSVB3PThsfhxXPtgu1nm1LWSzkJYqj4MHf-aLbVw@mail.gmail.com>
 <DB6PR0402MB276065DF476EBEDABF312CF9885E9@DB6PR0402MB2760.eurprd04.prod.outlook.com>
Message-ID: <CAHCN7x+zauc-8knQCGsvFB=YDrBB3T7bEHisdNEvQYgVnFsNGA@mail.gmail.com>

On Thu, Apr 29, 2021 at 8:34 PM Peng Fan <peng.fan at nxp.com> wrote:
>
> > Subject: Re: [PATCH 00/16] soc: imx: gpcv2: support i.MX8MM
> >
> > On Thu, Apr 29, 2021 at 1:59 AM Peng Fan (OSS) <peng.fan at oss.nxp.com>
> > wrote:
> > >
> > > From: Peng Fan <peng.fan at nxp.com>
> > >
> > > This patchset is a pick up Lucas's gpcv2 work for i.MX8MM and several
> > > minor changes from me to make it could work with i.MX BLK-CTL driver.
> > >
> > > Thanks for Lucas's work and suggestion, Frieder Schrempf for
> > > collecting all the patches, Jacky Bai on help debug issues.
> >
> > Thank for you all the work.  I have an i.MX8M Nano that I'll work to add
> > support for gpcv2 unless NXP has started this already.  At one time, I posted
> > some patches for Nano based on Lucas' work, but since that work wasn't
> > accepted, mine wasn't either.
>
> Please continue your work on i.MX8MN, I not work on this. The following
> work from me is i.MX8MP.

No problem.  I thought the focus would be on the 8MP,m so I went ahead
and posted a series [1] for enabling the gpcv2 for the Nano and the
power domains which don't require blk-ctl for now which include the
USB OTG, and the GPU.

If you and/or your colleagues have time to review it, it would be
appreciated.  I was able to suspend and resume with USB attached, and
it continued to operate.  I didn't do extensive testing yet.
I'm starting on the blk-ctl stuff now.  It seems to have changed quite
a bit since the initial submission from Abel, so I'll have to spend a
bit more time porting what I had before.

Thanks again for this series.  It will be nice to have the Mini, Nano
and Plus domains functional.

adam

[1] - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210429211625.1835702-2-aford173 at gmail.com/

>
> Thanks,
> Peng.
>
> >
> > adam
> > >
> > > Lucas Stach (12):
> > >   soc: imx: gpcv2: move to more ideomatic error handling in probe
> > >   soc: imx: gpcv2: move domain mapping to domain driver probe
> > >   soc: imx: gpcv2: switch to clk_bulk_* API
> > >   soc: imx: gpcv2: split power up and power down sequence control
> > >   soc: imx: gpcv2: wait for ADB400 handshake
> > >   soc: imx: gpcv2: add runtime PM support for power-domains
> > >   soc: imx: gpcv2: allow domains without power-sequence control
> > >   dt-bindings: imx: gpcv2: add support for optional resets
> > >   soc: imx: gpcv2: add support for optional resets
> > >   dt-bindings: power: add defines for i.MX8MM power domains
> > >   soc: imx: gpcv2: add support for i.MX8MM power domains
> > >   soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX power
> > >     domains
> > >
> > > Peng Fan (4):
> > >   soc: imx: gpcv2: correct pm_runtime_get_sync usage
> > >   soc: imx: gpcv2: move reset assert after requesting domain power up
> > >   soc: imx: gpcv2: support reset defer probe
> > >   soc: imx: gpcv2: remove waiting handshake in power up
> > >
> > >  .../bindings/power/fsl,imx-gpcv2.yaml         |   9 +
> > >  drivers/soc/imx/gpcv2.c                       | 534
> > ++++++++++++++----
> > >  include/dt-bindings/power/imx8mm-power.h      |  22 +
> > >  3 files changed, 450 insertions(+), 115 deletions(-)  create mode
> > > 100644 include/dt-bindings/power/imx8mm-power.h
> > >
> > > --
> > > 2.30.0
> > >


From wanjiabing at vivo.com  Fri Apr 30 04:10:47 2021
From: wanjiabing at vivo.com (Wan Jiabing)
Date: Fri, 30 Apr 2021 11:10:47 +0800
Subject: [PATCH] net: stmmac: Remove duplicate declaration of stmmac_priv
Message-ID: <20210430031047.34888-1-wanjiabing@vivo.com>

In commit f4da56529da60 ("net: stmmac: Add support for external
trigger timestamping"), struct stmmac_priv was declared at line 507
which caused duplicate struct declarations.
Remove later duplicate declaration here.

Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
---
 drivers/net/ethernet/stmicro/stmmac/hwif.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 2cc91759b91f..6d5e0f2b03ce 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -564,7 +564,6 @@ struct stmmac_mode_ops {
 #define stmmac_clean_desc3(__priv, __args...) \
 	stmmac_do_void_callback(__priv, mode, clean_desc3, __args)
 
-struct stmmac_priv;
 struct tc_cls_u32_offload;
 struct tc_cbs_qopt_offload;
 struct flow_cls_offload;
-- 
2.25.1



From samuel at sholland.org  Fri Apr 30 04:19:11 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:19:11 -0500
Subject: [PATCH v2 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3 glue
In-Reply-To: <20210430031912.42252-1-samuel@sholland.org>
References: <20210430031912.42252-1-samuel@sholland.org>
Message-ID: <20210430031912.42252-2-samuel@sholland.org>

The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
Represent this by attaching the reset line to a glue layer device.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
new file mode 100644
index 000000000000..936b5c74043f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/allwinner,sun50i-h6-dwc3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner H6 DWC3 USB controller
+
+maintainers:
+  - Chen-Yu Tsai <wens at csie.org>
+  - Maxime Ripard <mripard at kernel.org>
+
+properties:
+  compatible:
+    const: allwinner,sun50i-h6-dwc3
+
+  "#address-cells": true
+
+  "#size-cells": true
+
+  ranges: true
+
+  resets:
+    maxItems: 1
+
+# Required child node:
+
+patternProperties:
+  "^phy@[0-9a-f]+$":
+    $ref: ../phy/allwinner,sun50i-h6-usb3-phy.yaml#
+
+  "^usb@[0-9a-f]+$":
+    $ref: snps,dwc3.yaml#
+
+required:
+  - compatible
+  - ranges
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/clock/sun50i-h6-ccu.h>
+    #include <dt-bindings/reset/sun50i-h6-ccu.h>
+
+    usb3: usb at 5200000 {
+        compatible = "allwinner,sun50i-h6-dwc3";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        resets = <&ccu RST_BUS_XHCI>;
+
+        dwc3: usb at 5200000 {
+            compatible = "snps,dwc3";
+            reg = <0x05200000 0x10000>;
+            interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+            clocks = <&ccu CLK_BUS_XHCI>,
+                     <&ccu CLK_BUS_XHCI>,
+                     <&rtc 0>;
+            clock-names = "ref", "bus_early", "suspend";
+            dr_mode = "host";
+            phys = <&usb3phy>;
+            phy-names = "usb3-phy";
+        };
+
+        usb3phy: phy at 5210000 {
+            compatible = "allwinner,sun50i-h6-usb3-phy";
+            reg = <0x5210000 0x10000>;
+            clocks = <&ccu CLK_USB_PHY1>;
+            resets = <&ccu RST_USB_PHY1>;
+            #phy-cells = <0>;
+        };
+    };
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:19:10 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:19:10 -0500
Subject: [PATCH v2 0/2] Allwinner H6 USB3 device tree updates
Message-ID: <20210430031912.42252-1-samuel@sholland.org>

While implementing support for this USB controller in U-Boot, I noticed
that the reset line alsp affects they PHY. It looks like most platforms
use a separate glue node to represent this, and in fact there is already
a compatible for the H6 listed in drivers/usb/dwc3/dwc3-of-simple.c.

Since this layout matches the usual way of modeling this hardware, it
allows using the existing drivers without adding platform-specific code.


I tried to follow the existing DWC3 glue bindings (most of which are
still .txt). With this version, `make dt_binding_check` still raises a
couple of issues, which I do not know how best to fix:

  - Warning (unit_address_vs_reg): /example-0/usb at 5200000: node has a
    unit name, but no reg or ranges property
    => Since there is no MMIO translation, an empty `ranges;` seemed
       appropriate, but it causes this warning.

  - usb at 5200000: usb at 5200000:phy-names:0: 'usb2-phy' was expected
    => This may be an issue with the snps,dwc3 binding, where the
       `items` list overrides `minItems`. I believe the intention is
       that both PHY references are optional. This implementation has
       only one PHY.

Changes from v1 to v2:
  - Updated the binding to reference the PHY binding by path correctly
  - Dropped DT updates for Pine H64

Samuel Holland (2):
  dt-bindings: usb: Document the Allwinner H6 DWC3 glue
  arm64: dts: allwinner: h6: Wrap DWC3 and PHY in glue layer

 .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |  6 +-
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    |  6 +-
 .../dts/allwinner/sun50i-h6-tanix-tx6.dts     |  6 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 60 ++++++++-------
 5 files changed, 111 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml

-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:19:12 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:19:12 -0500
Subject: [PATCH v2 2/2] arm64: dts: allwinner: h6: Wrap DWC3 and PHY in glue
 layer
In-Reply-To: <20210430031912.42252-1-samuel@sholland.org>
References: <20210430031912.42252-1-samuel@sholland.org>
Message-ID: <20210430031912.42252-3-samuel@sholland.org>

The USB3 IP in the H6 is organized such that the reset line affects both
the DWC3 core and the PHY. To model that, following the example of
several other platforms, wrap those nodes in a glue layer node.

The inner nodes no longer need to be disabled, since the glue layer is
disabled by default to keep it in reset.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |  6 +-
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    |  6 +-
 .../dts/allwinner/sun50i-h6-tanix-tx6.dts     |  6 +-
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 60 ++++++++++---------
 4 files changed, 36 insertions(+), 42 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index b5808047d6e4..5f6292db808c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -86,10 +86,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -309,6 +305,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
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 7e83f6146f8a..ae3c24584f65 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -101,10 +101,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -340,6 +336,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
index be81330db14f..8cb06df231ab 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts
@@ -55,10 +55,6 @@ &de {
 	status = "okay";
 };
 
-&dwc3 {
-	status = "okay";
-};
-
 &ehci0 {
 	status = "okay";
 };
@@ -119,6 +115,6 @@ &usb2phy {
 	status = "okay";
 };
 
-&usb3phy {
+&usb3 {
 	status = "okay";
 };
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index af8b7d0ef750..b4ce5eff2822 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -700,36 +700,42 @@ ohci0: usb at 5101400 {
 			status = "disabled";
 		};
 
-		dwc3: usb at 5200000 {
-			compatible = "snps,dwc3";
-			reg = <0x05200000 0x10000>;
-			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&ccu CLK_BUS_XHCI>,
-				 <&ccu CLK_BUS_XHCI>,
-				 <&rtc 0>;
-			clock-names = "ref", "bus_early", "suspend";
+		usb3: usb at 5200000 {
+			compatible = "allwinner,sun50i-h6-dwc3";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
 			resets = <&ccu RST_BUS_XHCI>;
-			/*
-			 * The datasheet of the chip doesn't declare the
-			 * peripheral function, and there's no boards known
-			 * to have a USB Type-B port routed to the port.
-			 * In addition, no one has tested the peripheral
-			 * function yet.
-			 * So set the dr_mode to "host" in the DTSI file.
-			 */
-			dr_mode = "host";
-			phys = <&usb3phy>;
-			phy-names = "usb3-phy";
 			status = "disabled";
-		};
 
-		usb3phy: phy at 5210000 {
-			compatible = "allwinner,sun50i-h6-usb3-phy";
-			reg = <0x5210000 0x10000>;
-			clocks = <&ccu CLK_USB_PHY1>;
-			resets = <&ccu RST_USB_PHY1>;
-			#phy-cells = <0>;
-			status = "disabled";
+			dwc3: usb at 5200000 {
+				compatible = "snps,dwc3";
+				reg = <0x05200000 0x10000>;
+				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ccu CLK_BUS_XHCI>,
+					 <&ccu CLK_BUS_XHCI>,
+					 <&rtc 0>;
+				clock-names = "ref", "bus_early", "suspend";
+				/*
+				 * The datasheet of the chip doesn't declare the
+				 * peripheral function, and there's no boards known
+				 * to have a USB Type-B port routed to the port.
+				 * In addition, no one has tested the peripheral
+				 * function yet.
+				 * So set the dr_mode to "host" in the DTSI file.
+				 */
+				dr_mode = "host";
+				phys = <&usb3phy>;
+				phy-names = "usb3-phy";
+			};
+
+			usb3phy: phy at 5210000 {
+				compatible = "allwinner,sun50i-h6-usb3-phy";
+				reg = <0x5210000 0x10000>;
+				clocks = <&ccu CLK_USB_PHY1>;
+				resets = <&ccu RST_USB_PHY1>;
+				#phy-cells = <0>;
+			};
 		};
 
 		ehci3: usb at 5311000 {
-- 
2.26.3



From song.bao.hua at hisilicon.com  Fri Apr 30 04:46:04 2021
From: song.bao.hua at hisilicon.com (Song Bao Hua (Barry Song))
Date: Fri, 30 Apr 2021 03:46:04 +0000
Subject: [RFC PATCH v6 1/4] topology: Represent clusters of CPUs within a
 die
In-Reply-To: <20210428094811.159245-1-drjones@redhat.com>
References: <20210420001844.9116-2-song.bao.hua@hisilicon.com>
 <20210428094811.159245-1-drjones@redhat.com>
Message-ID: <2fcccd7430f945e9badf693627298fdd@hisilicon.com>



> -----Original Message-----
> From: Andrew Jones [mailto:drjones at redhat.com]
> Sent: Wednesday, April 28, 2021 9:48 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua at hisilicon.com>
> Cc: aubrey.li at linux.intel.com; bp at alien8.de; bsegall at google.com;
> catalin.marinas at arm.com; dietmar.eggemann at arm.com;
> gregkh at linuxfoundation.org; guodong.xu at linaro.org; hpa at zytor.com; Jonathan
> Cameron <jonathan.cameron at huawei.com>; juri.lelli at redhat.com;
> lenb at kernel.org; Liguozhu (Kenneth) <liguozhu at hisilicon.com>;
> linux-acpi at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; linuxarm at openeuler.org; mark.rutland at arm.com;
> mgorman at suse.de; mingo at redhat.com; msys.mizuma at gmail.com;
> peterz at infradead.org; Zengtao (B) <prime.zeng at hisilicon.com>;
> rjw at rjwysocki.net; rostedt at goodmis.org; sudeep.holla at arm.com;
> tglx at linutronix.de; tim.c.chen at linux.intel.com; valentin.schneider at arm.com;
> vincent.guittot at linaro.org; will at kernel.org; x86 at kernel.org; xuwei (O)
> <xuwei5 at huawei.com>; yangyicong <yangyicong at huawei.com>
> Subject: Re: [RFC PATCH v6 1/4] topology: Represent clusters of CPUs within
> a die
> 
> On 20/04/2021 12:18, Barry Song wrote:
> ...
> > Currently the ID provided is the offset of the Processor
> > Hierarchy Nodes Structure within PPTT.  Whilst this is unique
> > it is not terribly elegant so alternative suggestions welcome.
> >
> 
> The ACPI table offsets are consistent with how other topology IDs are
> generated. I once tried to make them a little more human friendly with
> [1], but it was nacked.
> 
> [1] https://lore.kernel.org/lkml/20180629132934.GA16282 at e107155-lin/t/
> 

Ideally, we are going to check if cluster node has a valid UID,
if yes, read this ID; otherwise, fall back to use offset.

Will move to that way in next version.

> Thanks,
> drew

Thanks
Barry


From samuel at sholland.org  Fri Apr 30 04:58:52 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:52 -0500
Subject: [PATCH v3 0/7] PinePhone BT audio bringup
Message-ID: <20210430035859.3487-1-samuel@sholland.org>

This series uses the additional DAIs added to the sun8i-codec driver to
add hardware routing for BT SCO (headset) audio on the PinePhone.

The BT audio connection is represented by the "dummy" bt-sco codec. The
connection to the Quectel EG-25G modem via AIF2 works as well, but I do
not include it here because there is no appropriate codec driver in
tree. We have been using an out-of-tree "dummy" codec driver for the
modem similar to bt-sco, and I'm not sure if such a driver would be
desired upstream.

Changes from v2:
  - Also accept #sound-dai-cells in the binding. Since dt-core.yaml
    already sets the type of this property, it is not possible to use
    oneOf, nor make a specific value deprecated.

Changes from v1:
  - Fixed DT binding example to follow new binding

Arnaud Ferraris (1):
  arm64: dts: allwinner: pinephone: Set audio card name

Samuel Holland (6):
  ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells
  ARM: dts: sun8i-a33: Allow using multiple codec DAIs
  arm64: dts: allwinner: a64: Allow using multiple codec DAIs
  arm64: dts: allwinner: a64: Add pinmux nodes for AIF2/AIF3
  arm64: dts: allwinner: a64: Allow multiple DAI links
  arm64: dts: allwinner: pinephone: Add support for Bluetooth audio

 .../sound/allwinner,sun8i-a33-codec.yaml      |  8 +++-
 arch/arm/boot/dts/sun8i-a33.dtsi              |  4 +-
 .../dts/allwinner/sun50i-a64-pinephone.dtsi   | 25 +++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 ++++++++++++++-----
 4 files changed, 60 insertions(+), 14 deletions(-)

-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:53 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:53 -0500
Subject: [PATCH v3 1/7] ASoC: dt-bindings: sun8i-codec: Increase
 #sound-dai-cells
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-2-samuel@sholland.org>

Increase sound-dai-cells to 1 to allow using the DAIs in the codec
corresponding to AIF2 and AIF3.

The generic ASoC OF code supports a #sound-dai-cells value of 0 or 1
with no impact to the driver, so this is a backward-compatible change.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../bindings/sound/allwinner,sun8i-a33-codec.yaml         | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
index 67405e6d8168..19f111f40225 100644
--- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
+++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml
@@ -12,7 +12,11 @@ maintainers:
 
 properties:
   "#sound-dai-cells":
-    const: 0
+    minimum: 0
+    maximum: 1
+    description:
+      A value of 0 is deprecated. When used, it only allows access to
+      the ADC/DAC and AIF1 (the CPU DAI), not the other two AIFs/DAIs.
 
   compatible:
     oneOf:
@@ -50,7 +54,7 @@ additionalProperties: false
 examples:
   - |
     audio-codec at 1c22e00 {
-      #sound-dai-cells = <0>;
+      #sound-dai-cells = <1>;
       compatible = "allwinner,sun8i-a33-codec";
       reg = <0x01c22e00 0x400>;
       interrupts = <0 29 4>;
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:54 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:54 -0500
Subject: [PATCH v3 2/7] ARM: dts: sun8i-a33: Allow using multiple codec DAIs
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-3-samuel@sholland.org>

Increase #sound-dai-cells on the digital codec to allow using the other
DAIs provided by the codec for AIF2 and AIF3.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 7344c37107c6..2beddbb3c518 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -198,7 +198,7 @@ simple-audio-card,cpu {
 		};
 
 		link_codec: simple-audio-card,codec {
-			sound-dai = <&codec>;
+			sound-dai = <&codec 0>;
 		};
 	};
 
@@ -238,7 +238,7 @@ dai: dai at 1c22c00 {
 		};
 
 		codec: codec at 1c22e00 {
-			#sound-dai-cells = <0>;
+			#sound-dai-cells = <1>;
 			compatible = "allwinner,sun8i-a33-codec";
 			reg = <0x01c22e00 0x400>;
 			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:55 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:55 -0500
Subject: [PATCH v3 3/7] arm64: dts: allwinner: a64: Allow using multiple codec
 DAIs
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-4-samuel@sholland.org>

Increase #sound-dai-cells on the digital codec to allow using the other
DAIs provided by the codec for AIF2 and AIF3.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 57786fc120c3..3061031780de 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -150,7 +150,7 @@ cpudai: simple-audio-card,cpu {
 		};
 
 		link_codec: simple-audio-card,codec {
-			sound-dai = <&codec>;
+			sound-dai = <&codec 0>;
 		};
 	};
 
@@ -878,7 +878,7 @@ dai: dai at 1c22c00 {
 		};
 
 		codec: codec at 1c22e00 {
-			#sound-dai-cells = <0>;
+			#sound-dai-cells = <1>;
 			compatible = "allwinner,sun50i-a64-codec",
 				     "allwinner,sun8i-a33-codec";
 			reg = <0x01c22e00 0x600>;
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:56 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:56 -0500
Subject: [PATCH v3 4/7] arm64: dts: allwinner: a64: Add pinmux nodes for
 AIF2/AIF3
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-5-samuel@sholland.org>

Now that the sun8i-codec driver supports AIF2 and AIF3, boards can use
them in DAI links. Add the necessary pinmux nodes.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 3061031780de..a583355a3128 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -658,6 +658,18 @@ pio: pinctrl at 1c20800 {
 			interrupt-controller;
 			#interrupt-cells = <3>;
 
+			/omit-if-no-ref/
+			aif2_pins: aif2-pins {
+				pins = "PB4", "PB5", "PB6", "PB7";
+				function = "aif2";
+			};
+
+			/omit-if-no-ref/
+			aif3_pins: aif3-pins {
+				pins = "PG10", "PG11", "PG12", "PG13";
+				function = "aif3";
+			};
+
 			csi_pins: csi-pins {
 				pins = "PE0", "PE2", "PE3", "PE4", "PE5", "PE6",
 				       "PE7", "PE8", "PE9", "PE10", "PE11";
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:57 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:57 -0500
Subject: [PATCH v3 5/7] arm64: dts: allwinner: a64: Allow multiple DAI links
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-6-samuel@sholland.org>

simple-audio-card supports either a single DAI link at the top level, or
subnodes with one or more DAI links. To use the secondary AIFs on the
codec, we need to add additional DAI links to the same sound card, so we
need to use the other binding.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++--------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index a583355a3128..5734b4825f64 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -131,12 +131,10 @@ psci {
 	};
 
 	sound: sound {
+		#address-cells = <1>;
+		#size-cells = <0>;
 		compatible = "simple-audio-card";
 		simple-audio-card,name = "sun50i-a64-audio";
-		simple-audio-card,format = "i2s";
-		simple-audio-card,frame-master = <&cpudai>;
-		simple-audio-card,bitclock-master = <&cpudai>;
-		simple-audio-card,mclk-fs = <128>;
 		simple-audio-card,aux-devs = <&codec_analog>;
 		simple-audio-card,routing =
 				"Left DAC", "DACL",
@@ -145,12 +143,19 @@ sound: sound {
 				"ADCR", "Right ADC";
 		status = "disabled";
 
-		cpudai: simple-audio-card,cpu {
-			sound-dai = <&dai>;
-		};
+		simple-audio-card,dai-link at 0 {
+			format = "i2s";
+			frame-master = <&link0_cpu>;
+			bitclock-master = <&link0_cpu>;
+			mclk-fs = <128>;
 
-		link_codec: simple-audio-card,codec {
-			sound-dai = <&codec 0>;
+			link0_cpu: cpu {
+				sound-dai = <&dai>;
+			};
+
+			link0_codec: codec {
+				sound-dai = <&codec 0>;
+			};
 		};
 	};
 
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:58 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:58 -0500
Subject: [PATCH v3 6/7] arm64: dts: allwinner: pinephone: Add support for
 Bluetooth audio
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-7-samuel@sholland.org>

The PinePhone has a Bluetooth chip with its PCM interface connected to
AIF3. Add the DAI link so headeset audio can be routed in hardware.

Even though the link is 16 bit PCM, configuring the link a 32-bit slot
is required for compatibility with AIF2, which also uses a 32-bit slot,
and which shares clock dividers with AIF3. Using equal clock frequencies
allows the modem and headset to be used at the same time.

Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 .../dts/allwinner/sun50i-a64-pinephone.dtsi   | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 9f69d489a81d..51cbfdc12936 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -25,6 +25,11 @@ backlight: backlight {
 		/* Backlight configuration differs per PinePhone revision. */
 	};
 
+	bt_sco_codec: bt-sco-codec {
+		#sound-dai-cells = <1>;
+		compatible = "linux,bt-sco";
+	};
+
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
@@ -91,6 +96,8 @@ vibrator {
 };
 
 &codec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&aif3_pins>;
 	status = "okay";
 };
 
@@ -447,6 +454,23 @@ &sound {
 			"MIC1", "Internal Microphone",
 			"Headset Microphone", "HBIAS",
 			"MIC2", "Headset Microphone";
+
+	simple-audio-card,dai-link at 2 {
+		format = "dsp_a";
+		frame-master = <&link2_codec>;
+		bitclock-master = <&link2_codec>;
+		bitclock-inversion;
+
+		link2_cpu: cpu {
+			sound-dai = <&bt_sco_codec 0>;
+		};
+
+		link2_codec: codec {
+			sound-dai = <&codec 2>;
+			dai-tdm-slot-num = <1>;
+			dai-tdm-slot-width = <32>;
+		};
+	};
 };
 
 &uart0 {
-- 
2.26.3



From samuel at sholland.org  Fri Apr 30 04:58:59 2021
From: samuel at sholland.org (Samuel Holland)
Date: Thu, 29 Apr 2021 22:58:59 -0500
Subject: [PATCH v3 7/7] arm64: dts: allwinner: pinephone: Set audio card name
In-Reply-To: <20210430035859.3487-1-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
Message-ID: <20210430035859.3487-8-samuel@sholland.org>

From: Arnaud Ferraris <arnaud.ferraris at collabora.com>

Add the "PinePhone" name to the sound card: this will make
upstreaming an ALSA UCM config easier as we can use a unique name.

It also avoids an issue where the default card name is truncated.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris at collabora.com>
[Samuel: Split out change, updated commit message]
Signed-off-by: Samuel Holland <samuel at sholland.org>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 51cbfdc12936..02712f85f6bd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -433,6 +433,7 @@ &reg_rtc_ldo {
 
 &sound {
 	status = "okay";
+	simple-audio-card,name = "PinePhone";
 	simple-audio-card,aux-devs = <&codec_analog>, <&speaker_amp>;
 	simple-audio-card,widgets = "Microphone", "Headset Microphone",
 				    "Microphone", "Internal Microphone",
-- 
2.26.3



From vee.khee.wong at linux.intel.com  Fri Apr 30 05:29:44 2021
From: vee.khee.wong at linux.intel.com (Wong Vee Khee)
Date: Fri, 30 Apr 2021 12:29:44 +0800
Subject: [PATCH] net: stmmac: Remove duplicate declaration of stmmac_priv
In-Reply-To: <20210430031047.34888-1-wanjiabing@vivo.com>
References: <20210430031047.34888-1-wanjiabing@vivo.com>
Message-ID: <20210430042944.GA5444@linux.intel.com>

On Fri, Apr 30, 2021 at 11:10:47AM +0800, Wan Jiabing wrote:
> In commit f4da56529da60 ("net: stmmac: Add support for external
> trigger timestamping"), struct stmmac_priv was declared at line 507
> which caused duplicate struct declarations.
> Remove later duplicate declaration here.
> 
> Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>

Reviewed-by: Wong Vee Khee <vee.khee.wong at linux.intel.com>



From peng.fan at oss.nxp.com  Fri Apr 30 05:43:54 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 12:43:54 +0800
Subject: [PATCH 13/16] soc: imx: gpcv2: correct pm_runtime_get_sync usage
In-Reply-To: <08d8573e7395b341cdec55ee4f92d8cd3da7d0d3.camel@pengutronix.de>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-14-peng.fan@oss.nxp.com>
 <08d8573e7395b341cdec55ee4f92d8cd3da7d0d3.camel@pengutronix.de>
Message-ID: <90148b7c-a375-bc1e-1000-7452b702bc42@oss.nxp.com>

On 2021/4/29 22:25, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> When the return value is negative, there is error, otherwise it is
>> expected.
> 
> Good catch! As the runtime pm handling is added in this series, this
> should be squashed into patch 06/16 to not add broken code and then fix
> it in the same series. Change looks good to me.

Sure. This will be squashed into patch 06/16 in V2.

Thanks,
Peng.

> 
>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>> ---
>>  ?drivers/soc/imx/gpcv2.c | 2 +-
>>  ?1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
>> index 42b9be05e1f2..d2ce47a5ebad 100644
>> --- a/drivers/soc/imx/gpcv2.c
>> +++ b/drivers/soc/imx/gpcv2.c
>> @@ -197,7 +197,7 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
>>  ?	int ret;
>>   
>>
>>
>>
>>  ?	ret = pm_runtime_get_sync(domain->dev);
>> -	if (ret) {
>> +	if (ret < 0) {
>>  ?		pm_runtime_put_noidle(domain->dev);
>>  ?		return ret;
>>  ?	}
> 
> 


From peng.fan at oss.nxp.com  Fri Apr 30 05:51:40 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 12:51:40 +0800
Subject: [PATCH 15/16] soc: imx: gpcv2: support reset defer probe
In-Reply-To: <34b4d1f0a278de7d730f88fd6480acfe5dfae276.camel@pengutronix.de>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-16-peng.fan@oss.nxp.com>
 <34b4d1f0a278de7d730f88fd6480acfe5dfae276.camel@pengutronix.de>
Message-ID: <ea6bcab5-e31f-87a4-0de1-05c53c53df3a@oss.nxp.com>



On 2021/4/29 22:30, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> When gpcv2 probe, the reset controller might not be ready, so we need
>> defer probe
> 
> I agree with Ahmad. dev_err_probe properly propagates the PROBE_DEFER
> return, so this patch should be dropped.

Sure. Drop in V2.

Thanks,
Peng.

> 
> Regards,
> Lucas
> 
>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>> ---
>>  ?drivers/soc/imx/gpcv2.c | 5 ++++-
>>  ?1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
>> index 072f519462a5..49dd137f6b94 100644
>> --- a/drivers/soc/imx/gpcv2.c
>> +++ b/drivers/soc/imx/gpcv2.c
>> @@ -784,9 +784,12 @@ static int imx_pgc_domain_probe(struct platform_device *pdev)
>>  ?				     "Failed to get domain's clocks\n");
>>   
>>
>>
>>
>>  ?	domain->reset = devm_reset_control_array_get_optional_exclusive(domain->dev);
>> -	if (IS_ERR(domain->reset))
>> +	if (IS_ERR(domain->reset)) {
>> +		if (PTR_ERR(domain->reset) == -EPROBE_DEFER)
>> +			return -EPROBE_DEFER;
>>  ?		return dev_err_probe(domain->dev, PTR_ERR(domain->reset),
>>  ?				     "Failed to get domain's resets\n");
>> +	}
>>   
>>
>>
>>
>>  ?	pm_runtime_enable(domain->dev);
>>   
>>
>>
>>
> 
> 


From peng.fan at oss.nxp.com  Fri Apr 30 05:52:33 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 12:52:33 +0800
Subject: [PATCH 16/16] soc: imx: gpcv2: remove waiting handshake in power
 up
In-Reply-To: <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-17-peng.fan@oss.nxp.com>
 <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>
Message-ID: <cd88adf8-8d85-0a7a-6a5d-fd1d616a35ae@oss.nxp.com>



On 2021/4/29 22:34, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> i.MX8MM has blk ctl module, the handshake can only finish after setting
>> blk ctl. The blk ctl driver will set the bus clk bit and the handshake
>> will finish there. we just add a delay and suppose the handshake will
>> finish after that.
> 
> Instead of this patch, just drop patch 05/16 from this series. I think
> we should leave a comment in the code on why we aren't waiting for the
> handshake ack, as this is non-obvious from looking at the driver code.
> 
> Basically add a polished version of the commit log from this patch into
> the driver code.

I see. Will do it in V2.

Thanks,
Peng.

> 
> Regards,
> Lucas
> 
>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>> ---
>>  ?drivers/soc/imx/gpcv2.c | 8 --------
>>  ?1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
>> index 49dd137f6b94..04564017bfe9 100644
>> --- a/drivers/soc/imx/gpcv2.c
>> +++ b/drivers/soc/imx/gpcv2.c
>> @@ -251,14 +251,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
>>  ?		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
>>  ?				   domain->bits.hskreq, domain->bits.hskreq);
>>   
>>
>>
>>
>> -		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
>> -					       reg_val,
>> -					       (reg_val & domain->bits.hskack),
>> -					       0, USEC_PER_MSEC);
>> -		if (ret) {
>> -			dev_err(domain->dev, "failed to power up ADB400\n");
>> -			goto out_clk_disable;
>> -		}
>>  ?	}
>>   
>>
>>
>>
>>  ?	/* Disable reset clocks for all devices in the domain */
> 
> 


From peng.fan at oss.nxp.com  Fri Apr 30 06:27:42 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 13:27:42 +0800
Subject: [PATCH V2 0/4] soc: imx: add i.MX BLK-CTL support
Message-ID: <20210430052746.10815-1-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

V2:
 Fix yaml check failure

Previously there is an effort from Abel that take BLK-CTL as clock
provider, but it turns out that there is A/B lock issue and we are
not able resolve that.

Per discuss with Lucas and Jacky, we made an agreement that take BLK-CTL
as a power domain provider and use GPC's domain as parent, the consumer
node take BLK-CTL as power domain input.

This patchset has been tested on i.MX8MM EVK board, but one hack
is not included in the patchset is that the DISPMIX BLK-CTL MIPI_M/S_RESET
not implemented. Per Lucas, we will finally have a MIPI DPHY driver,
so fine to leave it.

Thanks for Lucas's suggestion, Frieder Schrempf for collecting
all the patches, Abel's previous BLK-CTL work, Jacky Bai on help
debug issues.

Peng Fan (4):
  dt-bindings: power: Add defines for i.MX8MM BLK-CTL power domains
  Documentation: bindings: clk: Add bindings for i.MX BLK_CTL
  soc: imx: Add generic blk-ctl driver
  soc: imx: Add blk-ctl driver for i.MX8MM

 .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     |  73 +++++
 drivers/soc/imx/Makefile                      |   2 +-
 drivers/soc/imx/blk-ctl-imx8mm.c              | 138 ++++++++
 drivers/soc/imx/blk-ctl.c                     | 303 ++++++++++++++++++
 drivers/soc/imx/blk-ctl.h                     |  76 +++++
 include/dt-bindings/power/imx8mm-power.h      |  11 +
 6 files changed, 602 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
 create mode 100644 drivers/soc/imx/blk-ctl-imx8mm.c
 create mode 100644 drivers/soc/imx/blk-ctl.c
 create mode 100644 drivers/soc/imx/blk-ctl.h

-- 
2.30.0



From peng.fan at oss.nxp.com  Fri Apr 30 06:27:43 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 13:27:43 +0800
Subject: [PATCH V2 1/4] dt-bindings: power: Add defines for i.MX8MM BLK-CTL
 power domains
In-Reply-To: <20210430052746.10815-1-peng.fan@oss.nxp.com>
References: <20210430052746.10815-1-peng.fan@oss.nxp.com>
Message-ID: <20210430052746.10815-2-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Adding the defines for i.MX8MM BLK-CTL power domains.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 include/dt-bindings/power/imx8mm-power.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/dt-bindings/power/imx8mm-power.h b/include/dt-bindings/power/imx8mm-power.h
index fc9c2e16aadc..510e383d1953 100644
--- a/include/dt-bindings/power/imx8mm-power.h
+++ b/include/dt-bindings/power/imx8mm-power.h
@@ -19,4 +19,15 @@
 #define IMX8MM_POWER_DOMAIN_DISPMIX	10
 #define IMX8MM_POWER_DOMAIN_MIPI	11
 
+#define IMX8MM_BLK_CTL_G2_PD		0
+#define IMX8MM_BLK_CTL_G1_PD		1
+#define IMX8MM_BLK_CTL_H1_PD		2
+#define IMX8MM_BLK_CTL_MAX_PD		3
+
+#define IMX8MM_BLK_CTL_DISPMIX_CSI_BRIDGE	0
+#define IMX8MM_BLK_CTL_DISPMIX_LCDIF		1
+#define IMX8MM_BLK_CTL_DISPMIX_MIPI_DSI		2
+#define IMX8MM_BLK_CTL_DISPMIX_MIPI_CSI		3
+#define IMX8MM_BLK_CTL_DISPMIX_MAX_PD		4
+
 #endif
-- 
2.30.0



From peng.fan at oss.nxp.com  Fri Apr 30 06:27:44 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 13:27:44 +0800
Subject: [PATCH V2 2/4] Documentation: bindings: clk: Add bindings for i.MX
 BLK_CTL
In-Reply-To: <20210430052746.10815-1-peng.fan@oss.nxp.com>
References: <20210430052746.10815-1-peng.fan@oss.nxp.com>
Message-ID: <20210430052746.10815-3-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

Document the i.MX BLK_CTL with its devicetree properties.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     | 73 +++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml

diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
new file mode 100644
index 000000000000..a491b63de50c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/imx/fsl,imx-blk-ctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX BLK_CTL
+
+maintainers:
+  - Peng Fan <peng.fan at nxp.com>
+
+description:
+  i.MX BLK_CTL is a conglomerate of different GPRs that are
+  dedicated to a specific subsystem. It usually contains
+  clocks and resets amongst other things. Here we take the clocks
+  and resets as virtual PDs, the reason we could not take it as
+  clock provider is there is A/B lock issue between power domain
+  and clock.
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - fsl,imx8mm-dispmix-blk-ctl
+          - fsl,imx8mm-vpumix-blk-ctl
+      - const: syscon
+
+  reg:
+    maxItems: 1
+
+  "#power-domain-cells":
+    const: 1
+
+  power-domains:
+    minItems: 1
+    maxItems: 32
+
+  power-domain-names:
+    minItems: 1
+    maxItems: 32
+
+  '#reset-cells':
+    const: 1
+
+  clocks:
+    minItems: 1
+    maxItems: 32
+
+  clock-names:
+    minItems: 1
+    maxItems: 32
+
+required:
+  - compatible
+  - reg
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/imx8mm-clock.h>
+
+    dispmix_blk_ctl: blk-ctl at 32e28000 {
+      compatible = "fsl,imx8mm-dispmix-blk-ctl", "syscon";
+      reg = <0x32e28000 0x100>;
+      #power-domain-cells = <1>;
+      power-domains = <&pgc_dispmix>, <&pgc_mipi>;
+      power-domain-names = "dispmix", "mipi";
+      clocks = <&clk IMX8MM_CLK_DISP_ROOT>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>,
+               <&clk IMX8MM_CLK_DISP_APB_ROOT>;
+      clock-names = "disp", "axi", "apb";
+    };
-- 
2.30.0



From peng.fan at oss.nxp.com  Fri Apr 30 06:27:45 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 13:27:45 +0800
Subject: [PATCH V2 3/4] soc: imx: Add generic blk-ctl driver
In-Reply-To: <20210430052746.10815-1-peng.fan@oss.nxp.com>
References: <20210430052746.10815-1-peng.fan@oss.nxp.com>
Message-ID: <20210430052746.10815-4-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

The i.MX8MM introduces an IP named BLK_CTL and usually is comprised of
some GPRs.

The GPRs has some clock bits and reset bits, but here we take it
as virtual PDs, because of the clock and power domain A/B lock issue
when taking it as a clock controller.

For some bits, it might be good to also make it as a reset controller,
but to i.MX8MM, we not add that support for now.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/Makefile  |   2 +-
 drivers/soc/imx/blk-ctl.c | 303 ++++++++++++++++++++++++++++++++++++++
 drivers/soc/imx/blk-ctl.h |  76 ++++++++++
 3 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/imx/blk-ctl.c
 create mode 100644 drivers/soc/imx/blk-ctl.h

diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 078dc918f4f3..d3d2b49a386c 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o
 endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
-obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o
+obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o
diff --git a/drivers/soc/imx/blk-ctl.c b/drivers/soc/imx/blk-ctl.c
new file mode 100644
index 000000000000..1f764dfd308d
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021 NXP.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/pm_domain.h>
+#include <linux/reset-controller.h>
+
+#include "blk-ctl.h"
+
+static inline struct imx_blk_ctl_domain *to_imx_blk_ctl_pd(struct generic_pm_domain *genpd)
+{
+	return container_of(genpd, struct imx_blk_ctl_domain, pd);
+}
+
+static int imx_blk_ctl_enable_hsk(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_hw *hw = &blk_ctl->dev_data->hw_hsk;
+	struct regmap *regmap = blk_ctl->regmap;
+	int ret;
+
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, hw->rst_mask);
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
+
+	/* Wait for handshake */
+	udelay(5);
+
+	return ret;
+}
+
+int imx_blk_ctl_power_off(struct generic_pm_domain *domain)
+{
+	struct imx_blk_ctl_domain *pd;
+	struct imx_blk_ctl *blk_ctl;
+	const struct imx_blk_ctl_hw *hw;
+	struct regmap *regmap;
+	int ret;
+
+	pd = to_imx_blk_ctl_pd(domain);
+	blk_ctl = pd->blk_ctl;
+	regmap = blk_ctl->regmap;
+	hw = &blk_ctl->dev_data->pds[pd->id];
+
+	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
+	if (ret)
+		return ret;
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, 0);
+	if (ret)
+		goto hsk_fail;
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, 0);
+
+	if (atomic_dec_and_test(&blk_ctl->power_count)) {
+		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);
+		if (ret) {
+			dev_err(blk_ctl->dev, "Hankshake fail\n");
+			goto hsk_fail;
+		}
+	}
+
+hsk_fail:
+	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
+
+	return ret;
+}
+
+int imx_blk_ctl_power_on(struct generic_pm_domain *domain)
+{
+	struct imx_blk_ctl_domain *pd;
+	struct regmap *regmap;
+	const struct imx_blk_ctl_hw *hw;
+	int ret;
+	struct imx_blk_ctl *blk_ctl;
+
+	pd = to_imx_blk_ctl_pd(domain);
+	blk_ctl = pd->blk_ctl;
+	regmap = blk_ctl->regmap;
+	hw = &blk_ctl->dev_data->pds[pd->id];
+
+	ret = clk_bulk_prepare_enable(blk_ctl->num_clks, blk_ctl->clks);
+	if (ret)
+		return ret;
+
+	if ((atomic_read(&blk_ctl->power_count) == 0)) {
+		ret = imx_blk_ctl_enable_hsk(blk_ctl->dev);
+		if (ret) {
+			dev_err(blk_ctl->dev, "Hankshake fail\n");
+			goto disable_clk;
+		}
+	}
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, 0);
+
+	/* Wait for reset propagate */
+	udelay(5);
+
+	if (hw->flags & IMX_BLK_CTL_PD_RESET)
+		ret = regmap_update_bits(regmap, hw->rst_offset, hw->rst_mask, hw->rst_mask);
+
+	ret = regmap_update_bits(regmap, hw->offset, hw->mask, hw->mask);
+	if (ret)
+		goto disable_clk;
+
+	atomic_inc(&blk_ctl->power_count);
+
+disable_clk:
+	clk_bulk_disable_unprepare(blk_ctl->num_clks, blk_ctl->clks);
+
+	return ret;
+}
+
+static int imx_blk_ctl_attach_pd(struct device *dev, struct device **devs, char **pd_names,
+				 u32 num_pds)
+{
+	int i, ret;
+
+	if (!pd_names)
+		return 0;
+
+	if (dev->pm_domain) {
+		devs[0] = dev;
+		pm_runtime_enable(dev);
+		return 0;
+	}
+
+	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 detach_pm;
+		}
+	}
+
+	return 0;
+
+detach_pm:
+	for (i--; i >= 0; i--)
+		dev_pm_domain_detach(devs[i], false);
+
+	return ret;
+}
+
+static int imx_blk_ctl_register_pd(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	int num = dev_data->pds_num;
+	struct imx_blk_ctl_domain *domain;
+	int i, ret;
+
+	blk_ctl->onecell_data.num_domains = num;
+	blk_ctl->onecell_data.domains = devm_kcalloc(dev, num,
+						     sizeof(struct generic_pm_domain *),
+						     GFP_KERNEL);
+
+	if (!blk_ctl->onecell_data.domains)
+		return -ENOMEM;
+
+	for (i = 0; i < num; i++) {
+		domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
+		if (!domain) {
+			ret = -ENOMEM;
+			goto remove_genpd;
+		}
+		domain->pd.name = dev_data->pds[i].name;
+		domain->pd.power_off = imx_blk_ctl_power_off;
+		domain->pd.power_on = imx_blk_ctl_power_on;
+		domain->blk_ctl = blk_ctl;
+		domain->id = i;
+
+		ret = pm_genpd_init(&domain->pd, NULL, true);
+		if (ret)
+			return ret;
+
+		blk_ctl->onecell_data.domains[i] = &domain->pd;
+	}
+
+	return 0;
+
+remove_genpd:
+	for (i = i - 1; i >= 0; i--)
+		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
+
+	return ret;
+}
+
+static int imx_blk_ctl_hook_pd(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	const struct imx_blk_ctl_hw *pds = dev_data->pds;
+	int num_active_pd = dev_data->num_active_pd;
+	int num = dev_data->pds_num;
+	struct generic_pm_domain *genpd, *child_genpd;
+	int ret;
+	int i, j;
+
+	blk_ctl->active_pds = devm_kcalloc(dev, num_active_pd, sizeof(struct device *), GFP_KERNEL);
+	if (!blk_ctl->active_pds)
+		return -ENOMEM;
+
+	ret = imx_blk_ctl_attach_pd(dev, blk_ctl->active_pds, dev_data->active_pd_names,
+				    num_active_pd);
+	if (ret) {
+		if (ret == -EPROBE_DEFER)
+			return ret;
+		dev_err(dev, "Failed to attach active pd: %d\n", ret);
+		return ret;
+	}
+
+	for (i = 0; i < num; i++) {
+		for (j = 0; j < num_active_pd; j++) {
+			genpd = pd_to_genpd(blk_ctl->active_pds[j]->pm_domain);
+			if (!strcmp(genpd->name, pds[i].parent_name))
+				break;
+		}
+
+		child_genpd = blk_ctl->onecell_data.domains[i];
+		if (pm_genpd_add_subdomain(genpd, child_genpd))
+			pr_warn("failed to add subdomain:\n");
+	}
+
+	return 0;
+}
+
+int imx_blk_ctl_register(struct device *dev)
+{
+	struct imx_blk_ctl *blk_ctl = dev_get_drvdata(dev);
+	const struct imx_blk_ctl_dev_data *dev_data = blk_ctl->dev_data;
+	int num = dev_data->pds_num;
+	int i, ret;
+
+	if (!blk_ctl)
+		return -ENODEV;
+
+	ret = imx_blk_ctl_register_pd(dev);
+	if (ret)
+		return ret;
+
+	ret = imx_blk_ctl_hook_pd(dev);
+	if (ret)
+		goto unregister_pd;
+
+	ret = of_genpd_add_provider_onecell(dev->of_node, &blk_ctl->onecell_data);
+	if (ret)
+		goto detach_pd;
+
+	pm_runtime_get_noresume(dev);
+	pm_runtime_set_active(dev);
+	pm_runtime_enable(dev);
+
+	pm_runtime_put(dev);
+
+	return 0;
+
+detach_pd:
+	for (i = blk_ctl->dev_data->num_active_pd; i >= 0; i--)
+		dev_pm_domain_detach(blk_ctl->active_pds[i], false);
+unregister_pd:
+	for (i = num - 1; i >= 0; i--)
+		pm_genpd_remove(blk_ctl->onecell_data.domains[i]);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(imx_blk_ctl_register);
+
+static int __maybe_unused imx_blk_ctl_runtime_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int __maybe_unused imx_blk_ctl_runtime_resume(struct device *dev)
+{
+	return 0;
+}
+
+const struct dev_pm_ops imx_blk_ctl_pm_ops = {
+	SET_RUNTIME_PM_OPS(imx_blk_ctl_runtime_suspend,
+			   imx_blk_ctl_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+			   pm_runtime_force_resume)
+};
+EXPORT_SYMBOL_GPL(imx_blk_ctl_pm_ops);
diff --git a/drivers/soc/imx/blk-ctl.h b/drivers/soc/imx/blk-ctl.h
new file mode 100644
index 000000000000..e736369406a1
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl.h
@@ -0,0 +1,76 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __SOC_IMX_BLK_CTL_H
+#define __SOC_IMX_BLK_CTL_H
+
+enum imx_blk_ctl_pd_type {
+	BLK_CTL_PD,
+};
+
+struct imx_blk_ctl_hw {
+	int type;
+	char *name;
+	char *parent_name;
+	u32 offset;
+	u32 mask;
+	u32 flags;
+	u32 id;
+	u32 rst_offset;
+	u32 rst_mask;
+};
+
+struct imx_blk_ctl_domain {
+	struct generic_pm_domain pd;
+	struct imx_blk_ctl *blk_ctl;
+	u32 id;
+};
+
+struct imx_blk_ctl_dev_data {
+	struct regmap_config config;
+	struct imx_blk_ctl_hw *pds;
+	struct imx_blk_ctl_hw hw_hsk;
+	u32 pds_num;
+	char **active_pd_names;
+	u32 num_active_pd;
+};
+
+struct imx_blk_ctl {
+	struct device *dev;
+	struct regmap *regmap;
+	struct device **active_pds;
+	u32 pds_num;
+	u32 active_pd_count;
+	struct genpd_onecell_data onecell_data;
+	const struct imx_blk_ctl_dev_data *dev_data;
+	struct clk_bulk_data *clks;
+	u32 num_clks;
+
+	atomic_t power_count;
+};
+
+#define IMX_BLK_CTL(_type, _name, _parent_name, _id, _offset, _mask, _rst_offset, _rst_mask,	\
+		    _flags)								\
+	{										\
+		.type = _type,								\
+		.name = _name,								\
+		.parent_name = _parent_name,						\
+		.id = _id,								\
+		.offset = _offset,							\
+		.mask = _mask,								\
+		.flags = _flags,							\
+		.rst_offset = _rst_offset,						\
+		.rst_mask = _rst_mask,							\
+	}
+
+#define IMX_BLK_CTL_PD(_name, _parent_name, _id, _offset, _mask, _rst_offset, _rst_mask, _flags) \
+	IMX_BLK_CTL(BLK_CTL_PD, _name, _parent_name, _id, _offset, _mask, _rst_offset,		\
+		    _rst_mask, _flags)
+
+int imx_blk_ctl_register(struct device *dev);
+
+#define IMX_BLK_CTL_PD_HANDSHAKE	BIT(0)
+#define IMX_BLK_CTL_PD_RESET		BIT(1)
+#define IMX_BLK_CTL_PD_BUS		BIT(2)
+
+const extern struct dev_pm_ops imx_blk_ctl_pm_ops;
+
+#endif
-- 
2.30.0



From peng.fan at oss.nxp.com  Fri Apr 30 06:27:46 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 13:27:46 +0800
Subject: [PATCH V2 4/4] soc: imx: Add blk-ctl driver for i.MX8MM
In-Reply-To: <20210430052746.10815-1-peng.fan@oss.nxp.com>
References: <20210430052746.10815-1-peng.fan@oss.nxp.com>
Message-ID: <20210430052746.10815-5-peng.fan@oss.nxp.com>

From: Peng Fan <peng.fan at nxp.com>

The i.MX8MM SoC has dispmix BLK-CTL and vpumix BLK-CTL, so we add
that support in this driver.

Signed-off-by: Peng Fan <peng.fan at nxp.com>
---
 drivers/soc/imx/Makefile         |   2 +-
 drivers/soc/imx/blk-ctl-imx8mm.c | 138 +++++++++++++++++++++++++++++++
 2 files changed, 139 insertions(+), 1 deletion(-)
 create mode 100644 drivers/soc/imx/blk-ctl-imx8mm.c

diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index d3d2b49a386c..c260b962f495 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_ARCH_MXC) += soc-imx.o
 endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
-obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o
+obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o blk-ctl.o blk-ctl-imx8mm.o
diff --git a/drivers/soc/imx/blk-ctl-imx8mm.c b/drivers/soc/imx/blk-ctl-imx8mm.c
new file mode 100644
index 000000000000..77e0a5d3fdac
--- /dev/null
+++ b/drivers/soc/imx/blk-ctl-imx8mm.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021 NXP
+ */
+
+#include <dt-bindings/clock/imx8mm-clock.h>
+#include <dt-bindings/power/imx8mm-power.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/pm_domain.h>
+#include <linux/regmap.h>
+
+#include "blk-ctl.h"
+
+#define MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN			BIT(6)
+#define MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN			BIT(5)
+#define MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN			BIT(4)
+#define MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN			BIT(3)
+#define MEDIA_BLK_CSI_BRIDGE_SFT_EN				GENMASK(2, 0)
+
+#define MEDIA_BLK_BUS_PD_MASK					BIT(12)
+#define MEDIA_BLK_MIPI_CSI_PD_MASK				GENMASK(11, 10)
+#define MEDIA_BLK_MIPI_DSI_PD_MASK				GENMASK(9, 8)
+#define MEDIA_BLK_LCDIF_PD_MASK					GENMASK(7, 6)
+#define MEDIA_BLK_CSI_BRIDGE_PD_MASK				GENMASK(5, 0)
+
+static struct imx_blk_ctl_hw imx8mm_dispmix_blk_ctl_pds[] = {
+	IMX_BLK_CTL_PD("CSI_BRIDGE", "dispmix", IMX8MM_BLK_CTL_DISPMIX_CSI_BRIDGE, 0x4,
+		       MEDIA_BLK_CSI_BRIDGE_PD_MASK, 0, MEDIA_BLK_CSI_BRIDGE_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("LCDIF", "dispmix", IMX8MM_BLK_CTL_DISPMIX_LCDIF, 0x4,
+		       MEDIA_BLK_LCDIF_PD_MASK, -1, -1, 0),
+	IMX_BLK_CTL_PD("MIPI_DSI", "mipi", IMX8MM_BLK_CTL_DISPMIX_MIPI_DSI, 0x4,
+		       MEDIA_BLK_MIPI_DSI_PD_MASK, 0, MEDIA_BLK_MIPI_DSI_I_PRESETN_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("MIPI_CSI", "mipi", IMX8MM_BLK_CTL_DISPMIX_MIPI_CSI, 0x4,
+		       MEDIA_BLK_MIPI_CSI_PD_MASK, 0,
+		       MEDIA_BLK_MIPI_CSI_I_PRESETN_SFT_EN | MEDIA_BLK_CAMERA_PIXEL_RESET_N_SFT_EN,
+		       IMX_BLK_CTL_PD_RESET)
+};
+
+static struct imx_blk_ctl_hw imx8mm_vpumix_blk_ctl_pds[] = {
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_G2", "vpu-g2", IMX8MM_BLK_CTL_G2_PD, 0x4,
+		       BIT(0), 0, BIT(0), IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_G1", "vpu-g1", IMX8MM_BLK_CTL_G1_PD, 0x4,
+		       BIT(1), 0, BIT(1), IMX_BLK_CTL_PD_RESET),
+	IMX_BLK_CTL_PD("VPU_BLK_CTL_H1", "vpu-h1", IMX8MM_BLK_CTL_H1_PD, 0x4,
+		       BIT(2), 0, BIT(2), IMX_BLK_CTL_PD_HANDSHAKE | IMX_BLK_CTL_PD_RESET),
+};
+
+static const struct regmap_config imx8mm_blk_ctl_regmap_config = {
+	.reg_bits		= 32,
+	.reg_stride		= 4,
+	.val_bits		= 32,
+	.max_register		= 0x30,
+	.fast_io		= true,
+};
+
+static const struct imx_blk_ctl_dev_data imx8mm_vpumix_blk_ctl_dev_data = {
+	.pds = imx8mm_vpumix_blk_ctl_pds,
+	.pds_num = ARRAY_SIZE(imx8mm_vpumix_blk_ctl_pds),
+	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, IMX8MM_BLK_CTL_H1_PD, 0x4, BIT(2), 0, BIT(2),
+				 IMX_BLK_CTL_PD_HANDSHAKE),
+	.config = imx8mm_blk_ctl_regmap_config,
+	.active_pd_names = (char*[]){"vpumix", "g1", "g2", "h1"},
+	.num_active_pd = 4,
+};
+
+static const struct imx_blk_ctl_dev_data imx8mm_dispmix_blk_ctl_dev_data = {
+	.pds = imx8mm_dispmix_blk_ctl_pds,
+	.pds_num = ARRAY_SIZE(imx8mm_dispmix_blk_ctl_pds),
+	.hw_hsk = IMX_BLK_CTL_PD(NULL, NULL, -1, 0x4, MEDIA_BLK_BUS_PD_MASK, 0,
+				 MEDIA_BLK_BUS_RSTN_BLK_SYNC_SFT_EN,
+				 IMX_BLK_CTL_PD_HANDSHAKE | IMX_BLK_CTL_PD_RESET),
+	.config = imx8mm_blk_ctl_regmap_config,
+	.active_pd_names = (char*[]){"dispmix", "mipi"},
+	.num_active_pd = 2,
+};
+
+static int imx8mm_blk_ctl_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct imx_blk_ctl_dev_data *dev_data = of_device_get_match_data(dev);
+	struct regmap *regmap;
+	struct resource *res;
+	struct imx_blk_ctl *ctl;
+	void __iomem *base;
+
+	ctl = devm_kzalloc(dev, sizeof(*ctl), GFP_KERNEL);
+	if (!ctl)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	regmap = devm_regmap_init_mmio(dev, base, &dev_data->config);
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	ctl->regmap = regmap;
+	ctl->dev = dev;
+	atomic_set(&ctl->power_count, 0);
+
+	ctl->num_clks = devm_clk_bulk_get_all(dev, &ctl->clks);
+	if (ctl->num_clks < 0)
+		return ctl->num_clks;
+
+	dev_set_drvdata(dev, ctl);
+	ctl->dev_data = of_device_get_match_data(dev);
+
+	return imx_blk_ctl_register(dev);
+}
+
+static const struct of_device_id imx_blk_ctl_of_match[] = {
+	{ .compatible = "fsl,imx8mm-vpumix-blk-ctl", .data = &imx8mm_vpumix_blk_ctl_dev_data },
+	{ .compatible = "fsl,imx8mm-dispmix-blk-ctl", .data = &imx8mm_dispmix_blk_ctl_dev_data },
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_blk_ctl_of_match);
+
+static struct platform_driver imx_blk_ctl_driver = {
+	.probe = imx8mm_blk_ctl_probe,
+	.driver = {
+		.name = "imx8mm-blk-ctl",
+		.of_match_table = of_match_ptr(imx_blk_ctl_of_match),
+		.pm = &imx_blk_ctl_pm_ops,
+	},
+};
+module_platform_driver(imx_blk_ctl_driver);
-- 
2.30.0



From peng.fan at oss.nxp.com  Fri Apr 30 05:51:09 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 12:51:09 +0800
Subject: [PATCH 14/16] soc: imx: gpcv2: move reset assert after requesting
 domain power up
In-Reply-To: <43f3fd817b5d0448eeb940b4f3386d3c13680da0.camel@pengutronix.de>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-15-peng.fan@oss.nxp.com>
 <43f3fd817b5d0448eeb940b4f3386d3c13680da0.camel@pengutronix.de>
Message-ID: <51aa179a-e644-e8b4-a055-087ffb555589@oss.nxp.com>



On 2021/4/29 22:28, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> The i.MX8MM VPU power up sequence is a bit special, it must follow:
>> 1. request power up
>> 2. reset assert
>> 3. reset deassert
>>
>> This change in this patch will not affect other domains, because
>> the power domain default is in asserted state, unless bootloader
>> deassert the reset.
>>
>> [Note: We expect bootloader leave the domain in asserted state,
>> but this may not always be true, so we might need another solution
>> to address the VPU domain requirements]
> 
> This is only about the VPU and GPU domain, where we need to handle the
> SRC reset from the GPC driver right?

For GPU, I have not tried. From current ATF implementation, I think yes.

  In that case I think it's a sane
> assumption that the bootloader does not touch those resets.
> 
>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>> ---
>>  ?drivers/soc/imx/gpcv2.c | 4 ++--
>>  ?1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
>> index d2ce47a5ebad..072f519462a5 100644
>> --- a/drivers/soc/imx/gpcv2.c
>> +++ b/drivers/soc/imx/gpcv2.c
>> @@ -217,8 +217,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
>>  ?		goto out_regulator_disable;
>>  ?	}
>>   
>>
>>
>>
>>
>>
>>
>>
>> -	reset_control_assert(domain->reset);
>> -
>>  ?	if (domain->bits.pxx) {
>>  ?		/* request the domain to power up */
>>  ?		regmap_update_bits(domain->regmap, GPC_PU_PGC_SW_PUP_REQ,
>> @@ -241,6 +239,8 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
>>  ?				   GPC_PGC_CTRL_PCR, 0);
>>  ?	}
>>   
>>
>>
>>
>>
>>
>>
>>
>> +	reset_control_assert(domain->reset);
>> +
>>  ?	/* delay for reset to propagate */
>>  ?	udelay(5);
> 
> As this is a pretty arbitrary delay added by me, can you please check
> with the HW team or whoever knows, if this is sufficiently long for
> both GPU and VPU domains?

For VPU, from my test, it is enough. For GPU, ATF code use 10us, let me
try to enable GPU and do some test, I think 5us is long enough here.

Thanks,
Peng.

> 
> Regards,
> Lucas
> 


From p.yadav at ti.com  Fri Apr 30 06:42:09 2021
From: p.yadav at ti.com (Pratyush Yadav)
Date: Fri, 30 Apr 2021 11:12:09 +0530
Subject: [RFC PATCH 5/6] spi: cadence-qspi: Tune PHY to allow running at
 higher frequencies
In-Reply-To: <143b24c61109823f6e616cf91d28d16c@walle.cc>
References: <20210311191216.7363-1-p.yadav@ti.com>
 <20210311191216.7363-6-p.yadav@ti.com>
 <143b24c61109823f6e616cf91d28d16c@walle.cc>
Message-ID: <20210430054207.gakq7evf47igzcm4@ti.com>

On 30/04/21 12:48AM, Michael Walle wrote:
> Am 2021-03-11 20:12, schrieb Pratyush Yadav:
> > +	if (of_property_read_u32(np, "cdns,phy-tx-start",
> > &f_pdata->phy_tx_start))
> > +		f_pdata->phy_tx_start = 16;
> > +
> > +	if (of_property_read_u32(np, "cdns,phy-tx-end", &f_pdata->phy_tx_end))
> > +		f_pdata->phy_tx_end = 48;
> > +
> 
> I didn't see a dt-bindings patch for these.

Right. Will add them in the next re-roll.
 
> -michael

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.


From lkp at intel.com  Fri Apr 30 07:01:40 2021
From: lkp at intel.com (kernel test robot)
Date: Fri, 30 Apr 2021 14:01:40 +0800
Subject: [xlnx:pr/142 11850/12170]
 drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of
 function 'regulator_lock'
Message-ID: <202104301434.hPIcGVZ4-lkp@intel.com>

Hi Raviteja,

FYI, the error/warning still remains.

tree:   https://github.com/Xilinx/linux-xlnx pr/142
head:   d7991de841c2c41ac347bf1f519941fcaa15df04
commit: a6aea4afc0f41390d36b593f455902b6fdd75685 [11850/12170] regulator: da9121: Use core regulator lock
config: x86_64-randconfig-a015-20210429 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/Xilinx/linux-xlnx/commit/a6aea4afc0f41390d36b593f455902b6fdd75685
        git remote add xlnx https://github.com/Xilinx/linux-xlnx
        git fetch --no-tags xlnx pr/142
        git checkout a6aea4afc0f41390d36b593f455902b6fdd75685
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp at intel.com>

All errors (new ones prefixed by >>):

>> drivers/regulator/da9121-regulator.c:748:3: error: implicit declaration of function 'regulator_lock' [-Werror,-Wimplicit-function-declaration]
                   regulator_lock(rdev);
                   ^
>> drivers/regulator/da9121-regulator.c:750:3: error: implicit declaration of function 'regulator_unlock' [-Werror,-Wimplicit-function-declaration]
                   regulator_unlock(rdev);
                   ^
   drivers/regulator/da9121-regulator.c:750:3: note: did you mean 'regulator_lock'?
   drivers/regulator/da9121-regulator.c:748:3: note: 'regulator_lock' declared here
                   regulator_lock(rdev);
                   ^
   2 errors generated.


vim +/regulator_lock +748 drivers/regulator/da9121-regulator.c

   676	
   677	static inline int da9121_handle_notifier(
   678			struct da9121 *chip, struct regulator_dev *rdev,
   679			unsigned int event_bank, unsigned int event, unsigned int ebit)
   680	{
   681		enum { R0 = 0, R1, R2, REG_MAX_NUM };
   682		unsigned long notification = 0;
   683		int ret = 0;
   684	
   685		if (event & ebit) {
   686			switch (event_bank) {
   687			case DA9121_REG_SYS_EVENT_0:
   688				switch (event & ebit) {
   689				case DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT:
   690					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_CRIT;
   691					notification |= REGULATOR_EVENT_OVER_TEMP |
   692							REGULATOR_EVENT_DISABLE;
   693					break;
   694				case DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN:
   695					chip->persistent[R0] |= DA9121_MASK_SYS_EVENT_0_E_TEMP_WARN;
   696					notification |= REGULATOR_EVENT_OVER_TEMP;
   697					break;
   698				default:
   699					dev_warn(chip->dev,
   700						 "Unhandled event in bank0 0x%02x\n",
   701						 event & ebit);
   702					ret = -EINVAL;
   703					break;
   704				}
   705				break;
   706			case DA9121_REG_SYS_EVENT_1:
   707				switch (event & ebit) {
   708				case DA9121_MASK_SYS_EVENT_1_E_OV1:
   709					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OV1;
   710					notification |= REGULATOR_EVENT_REGULATION_OUT;
   711					break;
   712				case DA9121_MASK_SYS_EVENT_1_E_UV1:
   713					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_UV1;
   714					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   715					break;
   716				case DA9121_MASK_SYS_EVENT_1_E_OC1:
   717					chip->persistent[R1] |= DA9121_MASK_SYS_EVENT_1_E_OC1;
   718					notification |= REGULATOR_EVENT_OVER_CURRENT;
   719					break;
   720				case DA9xxx_MASK_SYS_EVENT_1_E_OV2:
   721					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OV2;
   722					notification |= REGULATOR_EVENT_REGULATION_OUT;
   723					break;
   724				case DA9xxx_MASK_SYS_EVENT_1_E_UV2:
   725					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_UV2;
   726					notification |= REGULATOR_EVENT_UNDER_VOLTAGE;
   727					break;
   728				case DA9xxx_MASK_SYS_EVENT_1_E_OC2:
   729					chip->persistent[R1] |= DA9xxx_MASK_SYS_EVENT_1_E_OC2;
   730					notification |= REGULATOR_EVENT_OVER_CURRENT;
   731					break;
   732				default:
   733					dev_warn(chip->dev,
   734						 "Unhandled event in bank1 0x%02x\n",
   735						 event & ebit);
   736					ret = -EINVAL;
   737					break;
   738				}
   739				break;
   740			default:
   741				dev_warn(chip->dev,
   742					 "Unhandled event bank 0x%02x\n", event_bank);
   743				ret = -EINVAL;
   744				goto error;
   745				break;
   746			}
   747	
 > 748			regulator_lock(rdev);
   749			regulator_notifier_call_chain(rdev, notification, NULL);
 > 750			regulator_unlock(rdev);
   751		}
   752	
   753	error:
   754		return ret;
   755	}
   756	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all at lists.01.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 32891 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210430/ebddc44c/attachment-0001.gz>

From dominique.martinet at atmark-techno.com  Fri Apr 30 07:10:52 2021
From: dominique.martinet at atmark-techno.com (Dominique Martinet)
Date: Fri, 30 Apr 2021 15:10:52 +0900
Subject: [PATCH v1 1/2] caam: imx8m: fix the built-in caam driver cannot
 match soc_id
In-Reply-To: <20210429140250.2321-1-alice.guo@oss.nxp.com>
References: <20210429140250.2321-1-alice.guo@oss.nxp.com>
Message-ID: <YIufbNaWeLgYxQGZ@atmark-techno.com>

Alice Guo (OSS) wrote on Thu, Apr 29, 2021 at 10:02:49PM +0800:
> From: Alice Guo <alice.guo at nxp.com>
> 
> drivers/soc/imx/soc-imx8m.c is probed later than the caam driver so that
> return -EPROBE_DEFER is needed after calling soc_device_match() in
> drivers/crypto/caam/ctrl.c. For i.MX8M, soc_device_match returning NULL
> can be considered that the SoC device has not been probed yet, so it
> returns -EPROBE_DEFER directly.

So basically you're saying if the soc is imx8m then soc_device_match()
has to find a match -- if for some reason there is rightfully no match
the caam driver will forever loop on EPROBE_DEFER (not sure how that is
handled by the driver stack?); but in this particular case we don't
actually need soc_device_match() to work: it's just there to pick the
appropriate clock data from caam_imx_soc_table[], and we already know we
should use &caam_imx7_data if imx8m_machine_match got a hit.

If we're going this way (making the caam driver only handle soc init
being late as that was noticeable), then I'd tend to agree with arnd's
comment[1] and not rely on soc_device_match at all in this case -- just
keeping it as a fallback if direct of_match_node didn't work for
compabitility with other devices.

[1] https://lore.kernel.org/r/CAK8P3a1GjeHyMCworQYVtp5U0uu2B9VBHmf9y0hGn-o8aKSJZw at mail.gmail.com/



Note I haven't had time to play with device_link_add or other ways to
make the soc init successfully early, but it's probably better to not
wait for me on this so I'm quite happy with this for now.


> Fixes: 7d981405d0fd ("soc: imx8m: change to use platform driver")
> Signed-off-by: Alice Guo <alice.guo at nxp.com>

And philosophical questions aside, this works for me:
Tested-by: Dominique Martinet <dominique.martinet at atmark-techno.com>

-- 
Dominique


From peng.fan at nxp.com  Fri Apr 30 07:19:25 2021
From: peng.fan at nxp.com (Peng Fan)
Date: Fri, 30 Apr 2021 06:19:25 +0000
Subject: [PATCH V2 0/4] soc: imx: add i.MX BLK-CTL support
In-Reply-To: <20210430052746.10815-1-peng.fan@oss.nxp.com>
References: <20210430052746.10815-1-peng.fan@oss.nxp.com>
Message-ID: <DB6PR0402MB27605E6DAECE069C12391FDD885E9@DB6PR0402MB2760.eurprd04.prod.outlook.com>

> Subject: [PATCH V2 0/4] soc: imx: add i.MX BLK-CTL support
> 
> From: Peng Fan <peng.fan at nxp.com>
> 
> V2:
>  Fix yaml check failure

Forget the address Jacky's comments on patch 3,4 in V1.
Will send V3 to add fix.

Thanks,
Peng.

> 
> Previously there is an effort from Abel that take BLK-CTL as clock provider, but
> it turns out that there is A/B lock issue and we are not able resolve that.
> 
> Per discuss with Lucas and Jacky, we made an agreement that take BLK-CTL
> as a power domain provider and use GPC's domain as parent, the consumer
> node take BLK-CTL as power domain input.
> 
> This patchset has been tested on i.MX8MM EVK board, but one hack is not
> included in the patchset is that the DISPMIX BLK-CTL MIPI_M/S_RESET not
> implemented. Per Lucas, we will finally have a MIPI DPHY driver, so fine to
> leave it.
> 
> Thanks for Lucas's suggestion, Frieder Schrempf for collecting all the patches,
> Abel's previous BLK-CTL work, Jacky Bai on help debug issues.
> 
> Peng Fan (4):
>   dt-bindings: power: Add defines for i.MX8MM BLK-CTL power domains
>   Documentation: bindings: clk: Add bindings for i.MX BLK_CTL
>   soc: imx: Add generic blk-ctl driver
>   soc: imx: Add blk-ctl driver for i.MX8MM
> 
>  .../bindings/soc/imx/fsl,imx-blk-ctl.yaml     |  73 +++++
>  drivers/soc/imx/Makefile                      |   2 +-
>  drivers/soc/imx/blk-ctl-imx8mm.c              | 138 ++++++++
>  drivers/soc/imx/blk-ctl.c                     | 303
> ++++++++++++++++++
>  drivers/soc/imx/blk-ctl.h                     |  76 +++++
>  include/dt-bindings/power/imx8mm-power.h      |  11 +
>  6 files changed, 602 insertions(+), 1 deletion(-)  create mode 100644
> Documentation/devicetree/bindings/soc/imx/fsl,imx-blk-ctl.yaml
>  create mode 100644 drivers/soc/imx/blk-ctl-imx8mm.c  create mode
> 100644 drivers/soc/imx/blk-ctl.c  create mode 100644
> drivers/soc/imx/blk-ctl.h
> 
> --
> 2.30.0



From u.kleine-koenig at pengutronix.de  Fri Apr 30 07:41:45 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 30 Apr 2021 08:41:45 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <CAL8eAtqBzUt6fP2nr-Ppg+qwhvKWk13A0P3+hoe07F+9VXCvmA@mail.gmail.com>
References: <20210428001946.1059426-1-roman.beranek@prusa3d.com>
 <20210428061357.725m72aikc52n4gg@pengutronix.de>
 <CAL8eAtpuAQUiesC-gxSQENDXrw44qQQvp5UqEjdfz1hX5CLHnQ@mail.gmail.com>
 <20210429120416.5ba7rq5fvhcfebzz@pengutronix.de>
 <CAL8eAtqBzUt6fP2nr-Ppg+qwhvKWk13A0P3+hoe07F+9VXCvmA@mail.gmail.com>
Message-ID: <20210430064145.nzlcw3lpayzapnbx@pengutronix.de>

Hello Roman,

On Fri, Apr 30, 2021 at 04:19:32AM +0200, Roman Ber?nek wrote:
> On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> > On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Ber?nek wrote:
> > > Correct, the output may stay in an active state. I only discovered this
> > > bug as I investigated a report of unreliable screen timeout. The period
> > > we use the PWM with is 50 us.
> >
> > What I don't like here is that the delay is quite coarse and might still
> > be too short. (Maybe I miss something, but consider the current period
> > is quite long, then you configure a short one and then disable. In this
> > case the inital long setting might still be active.)
> 
> The delay is calculated from the original period (cstate.period),
> not the one that was just written into PWM_CHx_PRD 2 lines above.

Yes, but that's not good enough. Consider the PWM is running with a
period of 4s and the period just started. Then you call

	pwm_apply_state(mypwm, &(struct pwm_state){
			.period = 20,
			.enabled = 1,
			...
			})

This doesn't result into the waiting code being run, because
.enabled = 1. Then immidiately after that call:

	pwm_apply_state(mypwm, &(struct pwm_state){
			.period = 20,
			.enabled = 0,
			...
			})

which triggers the waiting but only based on a period of 20 ns while the
4s period is still active.

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/20210430/cfef57c5/attachment.sig>

From quanyang.wang at windriver.com  Fri Apr 30 07:40:41 2021
From: quanyang.wang at windriver.com (quanyang.wang at windriver.com)
Date: Fri, 30 Apr 2021 14:40:41 +0800
Subject: [V2][PATCH] dmaengine: xilinx: dpdma: initialize registers before
 request_irq
Message-ID: <20210430064041.4058180-1-quanyang.wang@windriver.com>

From: Quanyang Wang <quanyang.wang at windriver.com>

In some scenarios (kdump), dpdma hardware irqs has been enabled when
calling request_irq in probe function, and then the dpdma irq handler
xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
this moment xdev->chan[i] hasn't been initialized.

We should ensure the dpdma controller to be in a consistent and
clean state before further initialization. So add dpdma_hw_init()
to do this.

Furthermore, in xilinx_dpdma_disable_irq, disable all interrupts
instead of error interrupts.

This patch is to fix the kdump kernel crash as below:

[    3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c
[    3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed
[    3.704900] Mem abort info:
[    3.704902]   ESR = 0x96000005
[    3.704905]   EC = 0x25: DABT (current EL), IL = 32 bits
[    3.704907]   SET = 0, FnV = 0
[    3.704912]   EA = 0, S1PTW = 0
[    3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator
[    3.715585] Data abort info:
[    3.715587]   ISV = 0, ISS = 0x00000005
[    3.715589]   CM = 0, WnR = 0
[    3.715592] [000000000000012c] user address but active_mm is swapper
[    3.715596] Internal error: Oops: 96000005 [#1] SMP
[    3.715599] Modules linked in:
[    3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77
[    3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
[    3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
[    3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
[    3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
[    3.798089] sp : ffffffc01186bdf0
[    3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
[    3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
[    3.811996] x25: 0000000008000408 x24: 0000000000000003
[    3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
[    3.822604] x21: 0000000000000000 x20: 0000000008000408
[    3.827908] x19: 0000000000000000 x18: 0000000000000010
[    3.833212] x17: 0000000000000000 x16: 0000000000000000
[    3.838516] x15: 0000000000000000 x14: ffffffc011291740
[    3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
[    3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
[    3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
[    3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
[    3.865036] x5 : 0000000000000003 x4 : 0000000000000000
[    3.870340] x3 : 0000000000000001 x2 : 0000000000000000
[    3.875644] x1 : 0000000000000000 x0 : 000000000000012c
[    3.880948] Call trace:
[    3.883382]  xilinx_dpdma_irq_handler+0x418/0x560
[    3.888079]  __handle_irq_event_percpu+0x5c/0x178
[    3.892774]  handle_irq_event_percpu+0x34/0x98
[    3.897210]  handle_irq_event+0x44/0xb8
[    3.901030]  handle_fasteoi_irq+0xd0/0x190
[    3.905117]  generic_handle_irq+0x30/0x48
[    3.909111]  __handle_domain_irq+0x64/0xc0
[    3.913192]  gic_handle_irq+0x78/0xa0
[    3.916846]  el1_irq+0xc4/0x180
[    3.919982]  cpuidle_enter_state+0x134/0x2f8
[    3.924243]  cpuidle_enter+0x38/0x50
[    3.927810]  call_cpuidle+0x1c/0x40
[    3.931290]  do_idle+0x20c/0x270
[    3.934502]  cpu_startup_entry+0x28/0x58
[    3.938410]  rest_init+0xbc/0xcc
[    3.941631]  arch_call_rest_init+0x10/0x1c
[    3.945718]  start_kernel+0x51c/0x558

Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver")
Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
---
V2:
 - As per Laurent's comments, add a new hw_init function to disable interrupts
   and clear register states.
 - Abandon all modifications in V1 since the new hw_init function can
   fix this issue

---
 drivers/dma/xilinx/xilinx_dpdma.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
index d8426f915c3e..60dee30a4930 100644
--- a/drivers/dma/xilinx/xilinx_dpdma.c
+++ b/drivers/dma/xilinx/xilinx_dpdma.c
@@ -1554,7 +1554,7 @@ static void xilinx_dpdma_enable_irq(struct xilinx_dpdma_device *xdev)
  */
 static void xilinx_dpdma_disable_irq(struct xilinx_dpdma_device *xdev)
 {
-	dpdma_write(xdev->reg, XILINX_DPDMA_IDS, XILINX_DPDMA_INTR_ERR_ALL);
+	dpdma_write(xdev->reg, XILINX_DPDMA_IDS, XILINX_DPDMA_INTR_ALL);
 	dpdma_write(xdev->reg, XILINX_DPDMA_EIDS, XILINX_DPDMA_EINTR_ALL);
 }
 
@@ -1691,6 +1691,26 @@ static struct dma_chan *of_dma_xilinx_xlate(struct of_phandle_args *dma_spec,
 	return dma_get_slave_channel(&xdev->chan[chan_id]->vchan.chan);
 }
 
+static void dpdma_hw_init(struct xilinx_dpdma_device *xdev)
+{
+	unsigned int i;
+	void __iomem *reg;
+
+	/* Disable all interrupts */
+	xilinx_dpdma_disable_irq(xdev);
+
+	/* Stop all channels */
+	for (i = 0; i < ARRAY_SIZE(xdev->chan); i++) {
+		reg = xdev->reg + XILINX_DPDMA_CH_BASE
+				+ XILINX_DPDMA_CH_OFFSET * i;
+		dpdma_clr(reg, XILINX_DPDMA_CH_CNTL, XILINX_DPDMA_CH_CNTL_ENABLE);
+	}
+
+	/* Clear the interrupt status registers */
+	dpdma_write(xdev->reg, XILINX_DPDMA_ISR, XILINX_DPDMA_INTR_ALL);
+	dpdma_write(xdev->reg, XILINX_DPDMA_EISR, XILINX_DPDMA_EINTR_ALL);
+}
+
 static int xilinx_dpdma_probe(struct platform_device *pdev)
 {
 	struct xilinx_dpdma_device *xdev;
@@ -1717,6 +1737,8 @@ static int xilinx_dpdma_probe(struct platform_device *pdev)
 	if (IS_ERR(xdev->reg))
 		return PTR_ERR(xdev->reg);
 
+	dpdma_hw_init(xdev);
+
 	xdev->irq = platform_get_irq(pdev, 0);
 	if (xdev->irq < 0) {
 		dev_err(xdev->dev, "failed to get platform irq\n");
-- 
2.25.1



From ameynarkhede03 at gmail.com  Fri Apr 30 07:43:20 2021
From: ameynarkhede03 at gmail.com (Amey Narkhede)
Date: Fri, 30 Apr 2021 12:13:20 +0530
Subject: [PATCH] PCI: mediatek: Verify whether the free_ck clock is
 ungated or not
In-Reply-To: <20210429223838.GA588275@bjorn-Precision-5520>
References: <20210429134749.75157-1-ameynarkhede03@gmail.com>
 <20210429223838.GA588275@bjorn-Precision-5520>
Message-ID: <20210430064320.ktnr2wjhza4p44dk@archlinux>

On 21/04/29 05:38PM, Bjorn Helgaas wrote:
> Can you make the subject say something at a higher level instead of
> just paraphrasing the C code?  I'm guessing this means resume will now
> fail if the clock isn't turned on?
>
> On Thu, Apr 29, 2021 at 07:17:49PM +0530, Amey Narkhede wrote:
> > Verify that the free_ck clock is ungated on device resume
> > by checking return value of clk_prepare_enable().
>
> Also the commit log -- this doesn't say anything more than the code
> itself.  Did you find this by tripping over it?  Or just by code
> inspection?  I guess without the check, we continue on and try to
> resume, but accesses to PCI devices fail and maybe return ~0 data or
> cause machine checks or something?
>
I found this with code inspection. Sorry for the unclear commit
messsage. I'll try to clarify it in v2.
> > Signed-off-by: Amey Narkhede <ameynarkhede03 at gmail.com>
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > index 23548b517..9b13214bf 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -1154,11 +1154,14 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
> >  {
> >  	struct mtk_pcie *pcie = dev_get_drvdata(dev);
> >  	struct mtk_pcie_port *port, *tmp;
> > +	int ret;
> >
> >  	if (list_empty(&pcie->ports))
> >  		return 0;
> >
> > -	clk_prepare_enable(pcie->free_ck);
> > +	ret = clk_prepare_enable(pcie->free_ck);
> > +	if (ret)
> > +		return ret;
>
> Most callers print an error message when clk_prepare_enable() fails.
>
[...]
I'll update this in v2.

Thanks,
Amey


From geert at linux-m68k.org  Fri Apr 30 07:45:05 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 08:45:05 +0200
Subject: [PATCH net-next v3 3/6] net: add generic selftest support
In-Reply-To: <20210419130106.6707-4-o.rempel@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <20210419130106.6707-4-o.rempel@pengutronix.de>
Message-ID: <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>

Hi Oleksij,

On Mon, Apr 19, 2021 at 3:13 PM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> Port some parts of the stmmac selftest and reuse it as basic generic selftest
> library. This patch was tested with following combinations:
> - iMX6DL FEC -> AT8035
> - iMX6DL FEC -> SJA1105Q switch -> KSZ8081
> - iMX6DL FEC -> SJA1105Q switch -> KSZ9031
> - AR9331 ag71xx -> AR9331 PHY
> - AR9331 ag71xx -> AR9331 switch -> AR9331 PHY
>
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>

Thanks for your patch, which is now commit 3e1e58d64c3d0a67 ("net: add
generic selftest support") upstream.

> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -429,6 +429,10 @@ config GRO_CELLS
>  config SOCK_VALIDATE_XMIT
>         bool
>
> +config NET_SELFTESTS
> +       def_tristate PHYLIB

Why does this default to enabled if PHYLIB=y?
Usually we allow the user to make selftests modular, independent of the
feature under test, but I may misunderstand the purpose of this test.

Thanks for your clarification!

> +       depends on PHYLIB
> +

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 michal.simek at xilinx.com  Fri Apr 30 07:51:04 2021
From: michal.simek at xilinx.com (Michal Simek)
Date: Fri, 30 Apr 2021 08:51:04 +0200
Subject: [PATCH] dmaengine: xilinx: dpdma: request_irq after initializing
 dma channels
In-Reply-To: <1d88d67b-aaf5-823d-0cf6-c9422c01918c@windriver.com>
References: <20210429065821.3495234-1-quanyang.wang@windriver.com>
 <YItRB7SBhiilzDLk@pendragon.ideasonboard.com>
 <1d88d67b-aaf5-823d-0cf6-c9422c01918c@windriver.com>
Message-ID: <e8a245ac-e326-0e10-728b-b0ded7c03a71@xilinx.com>

Hi,

On 4/30/21 3:45 AM, quanyang.wang wrote:
> Hi Laurent,
> 
> On 4/30/21 8:36 AM, Laurent Pinchart wrote:
>> Hi Quanyang,
>>
>> Thank you for the patch.
>>
>> On Thu, Apr 29, 2021 at 02:58:21PM +0800, quanyang.wang at windriver.com
>> wrote:
>>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>>
>>> In some scenarios (kdump), dpdma hardware irqs has been enabled when
>>> calling request_irq in probe function, and then the dpdma irq handler
>>> xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
>>> this moment xdev->chan[i] hasn't been initialized. So let's call the
>>> request_irq after initializing dma channels to avoid kdump kernel
>>> crash as below:
>>>
>>> [??? 3.696128] Unable to handle kernel NULL pointer dereference at
>>> virtual address 000000000000012c
>>> [??? 3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx
>>> DPDMA engine is probed
>>> [??? 3.704900] Mem abort info:
>>> [??? 3.704902]?? ESR = 0x96000005
>>> [??? 3.704905]?? EC = 0x25: DABT (current EL), IL = 32 bits
>>> [??? 3.704907]?? SET = 0, FnV = 0
>>> [??? 3.704912]?? EA = 0, S1PTW = 0
>>> [??? 3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using
>>> dummy regulator
>>> [??? 3.715585] Data abort info:
>>> [??? 3.715587]?? ISV = 0, ISS = 0x00000005
>>> [??? 3.715589]?? CM = 0, WnR = 0
>>> [??? 3.715592] [000000000000012c] user address but active_mm is swapper
>>> [??? 3.715596] Internal error: Oops: 96000005 [#1] SMP
>>> [??? 3.715599] Modules linked in:
>>> [??? 3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 5.10.0-12170-g60894882155f-dirty #77
>>> [??? 3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
>>> [??? 3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
>>> [??? 3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
>>> [??? 3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
>>> [??? 3.798089] sp : ffffffc01186bdf0
>>> [??? 3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
>>> [??? 3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
>>> [??? 3.811996] x25: 0000000008000408 x24: 0000000000000003
>>> [??? 3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
>>> [??? 3.822604] x21: 0000000000000000 x20: 0000000008000408
>>> [??? 3.827908] x19: 0000000000000000 x18: 0000000000000010
>>> [??? 3.833212] x17: 0000000000000000 x16: 0000000000000000
>>> [??? 3.838516] x15: 0000000000000000 x14: ffffffc011291740
>>> [??? 3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
>>> [??? 3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
>>> [??? 3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
>>> [??? 3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
>>> [??? 3.865036] x5 : 0000000000000003 x4 : 0000000000000000
>>> [??? 3.870340] x3 : 0000000000000001 x2 : 0000000000000000
>>> [??? 3.875644] x1 : 0000000000000000 x0 : 000000000000012c
>>> [??? 3.880948] Call trace:
>>> [??? 3.883382]? xilinx_dpdma_irq_handler+0x418/0x560
>>> [??? 3.888079]? __handle_irq_event_percpu+0x5c/0x178
>>> [??? 3.892774]? handle_irq_event_percpu+0x34/0x98
>>> [??? 3.897210]? handle_irq_event+0x44/0xb8
>>> [??? 3.901030]? handle_fasteoi_irq+0xd0/0x190
>>> [??? 3.905117]? generic_handle_irq+0x30/0x48
>>> [??? 3.909111]? __handle_domain_irq+0x64/0xc0
>>> [??? 3.913192]? gic_handle_irq+0x78/0xa0
>>> [??? 3.916846]? el1_irq+0xc4/0x180
>>> [??? 3.919982]? cpuidle_enter_state+0x134/0x2f8
>>> [??? 3.924243]? cpuidle_enter+0x38/0x50
>>> [??? 3.927810]? call_cpuidle+0x1c/0x40
>>> [??? 3.931290]? do_idle+0x20c/0x270
>>> [??? 3.934502]? cpu_startup_entry+0x28/0x58
>>> [??? 3.938410]? rest_init+0xbc/0xcc
>>> [??? 3.941631]? arch_call_rest_init+0x10/0x1c
>>> [??? 3.945718]? start_kernel+0x51c/0x558
>>>
>>> Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx
>>> DisplayPort DMA engine driver")
>>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>>> ---
>>> ? drivers/dma/xilinx/xilinx_dpdma.c | 30 +++++++++++++++---------------
>>> ? 1 file changed, 15 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c
>>> b/drivers/dma/xilinx/xilinx_dpdma.c
>>> index 70b29bd079c9..0b599402c53f 100644
>>> --- a/drivers/dma/xilinx/xilinx_dpdma.c
>>> +++ b/drivers/dma/xilinx/xilinx_dpdma.c
>>> @@ -1622,19 +1622,6 @@ static int xilinx_dpdma_probe(struct
>>> platform_device *pdev)
>>> ????? if (IS_ERR(xdev->reg))
>>> ????????? return PTR_ERR(xdev->reg);
>>> ? -??? xdev->irq = platform_get_irq(pdev, 0);
>>> -??? if (xdev->irq < 0) {
>>> -??????? dev_err(xdev->dev, "failed to get platform irq\n");
>>> -??????? return xdev->irq;
>>> -??? }
>>> -
>>> -??? ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>>> -????????????? dev_name(xdev->dev), xdev);
>>> -??? if (ret) {
>>> -??????? dev_err(xdev->dev, "failed to request IRQ\n");
>>> -??????? return ret;
>>> -??? }
>>> -
>>> ????? ddev = &xdev->common;
>>> ????? ddev->dev = &pdev->dev;
>>> ? @@ -1688,6 +1675,19 @@ static int xilinx_dpdma_probe(struct
>>> platform_device *pdev)
>>> ????????? goto error_of_dma;
>>> ????? }
>>> ? +??? xdev->irq = platform_get_irq(pdev, 0);
>>> +??? if (xdev->irq < 0) {
>>> +??????? dev_err(xdev->dev, "failed to get platform irq\n");
>> As reported by the kbuild bot, ret isn't initialized here.
> I will fix this in V2.
>>
>>> +??????? goto error_irq;
>>> +??? }
>> This part could stay where it was, just after
>> devm_platform_ioremap_resource().
> OK?I will move it back.
>>
>>> +
>>> +??? ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>>> +????????????? dev_name(xdev->dev), xdev);
>>> +??? if (ret) {
>>> +??????? dev_err(xdev->dev, "failed to request IRQ\n");
>>> +??????? goto error_irq;
>>> +??? }
>> Ideally we should reset the device before requesting the IRQ, to ensure
>> we start in a consistent state. There doesn't seem to be any global
>> reset unfortunately. Shouldn't we at least disable interrupts ? It may
>> be a bit pointless though as we reenable them right below, so I suppose
>> this would be OK.
> 
> Yes, we should start in a consistent and clean state. I will disable
> interrupts
> 
> and clean up registers state in V2.
> 
>>
>>> +
>>> ????? xilinx_dpdma_enable_irq(xdev);
>>> ? ????? xilinx_dpdma_debugfs_init(xdev);
>>> @@ -1696,6 +1696,8 @@ static int xilinx_dpdma_probe(struct
>>> platform_device *pdev)
>>> ? ????? return 0;
>>> ? +error_irq:
>>> +??? of_dma_controller_free(pdev->dev.of_node);
>> Why not free_irq() ? This change isn't described in the commit message.
> 
> I will add it in V2.

When I was checking it that request_irq was called last. It means it
wasn't necessary to free irq in error path. But double check it.

M



From m.felsch at pengutronix.de  Fri Apr 30 07:51:34 2021
From: m.felsch at pengutronix.de (Marco Felsch)
Date: Fri, 30 Apr 2021 08:51:34 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>
Message-ID: <20210430065134.jwscxlv3sydo4zgy@pengutronix.de>

Hi Laurent,

On 21-04-30 01:14, Laurent Pinchart wrote:
> Hi Marco,
> 
> On Thu, Apr 29, 2021 at 09:49:03AM +0200, Marco Felsch wrote:
> > On 21-04-29 04:51, Laurent Pinchart wrote:
> > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:
> > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > with the interleaved IR pixels looks like:
> > > > 
> > > >         |  G |  R |  G |  B | ...
> > > >         +----+----+----+----+---
> > > >         | IR |  G | IR |  G | ...
> > > >         +----+----+----+----+---
> > > >         |  G |  B |  G |  R | ...
> > > >         +----+----+----+----+---
> > > >         | IR |  G | IR |  G | ...
> > > >         +----+----+----+----+---
> > > >         | .. | .. | .. | .. | ..
> > > > 
> > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> > > 
> > > I think we're reaching a limit of the media bus codes model here, due to
> > > a historical mistake. The four possible Bayer patterns, times the
> > > different number of bits per pixel, creates a lot of media bus codes,
> > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > have to support them all.
> > 
> > That's correct but it is not bayer related. Currently it is what it is,
> > if a new code is added it must be propagated through all the involved
> > subdevs. On the other hand I wouldn't say that it is better to support
> > new codes per default for all drivers. Since this would add a lot of
> > untested code paths.
> 
> It's not an issue limited to Bayer patterns, but they make the issue
> worse given the number of possible combinations (think about adding DPCM
> and ALAW compression on top of that...).

You're right and again this will apply to all mbus formats...

> > > This is already painful, and if we had a
> > > non-Bayer pattern such as this one,
> > 
> > That's not exactly true since it is a bayer pattern but instead of using
> > 4x4 it uses 8x8 and it as some special pixels.
> > 
> > > we'll open the door to an explosion
> > > of the number of media bus codes (imagine all the different possible
> > > arrangements of this pattern, for instance if you enable horizontal
> > > and/or vertical flipping on the sensor). All drivers would need to be
> > > updated to support these new bus codes, and this really kills the
> > > current model.
> > 
> > Yep, I know what you mean but as I said above I think that adding it
> > explicite is the better abbroach since it involves somone who add _and_
> > test the new code on the particular platform.
> > 
> > > The historical mistake was to tie the Bayer pattern with the media bus
> > > code. We should really have specified raw 8/10/12/14/16 media bus codes,
> > > and conveyed the pattern separately. Most IP cores in the pipeline don't
> > > need to care about the pattern at all, and those who do (that's mostly
> > > ISPs) could be programmed explicitly by userspace as long as we have an
> > > API to retrieve the pattern from the sensor. I believe it's time to bite
> > > the bullet and go in that direction. I'm sorry for this case of yak
> > > shaving, but it really wouldn't be manageable anymore :-(
> > 
> > I got all your points and would agree but this is not a bayer only
> > related problem. You will have this problem with all new other formats
> > as well. I'm with you, most IP cores don't care but I wouldn't
> > guarantee that.
> 
> Sorry, but adding new media bus formats like this one will just not
> scale. We have two options, either fixing the issue, or considering that
> V4L2 is a barely alive API with no future, and merging this without
> caring anymore.

Hm.. you're right that it doesn't scale, as I said I'm absolute on your
side. So let us consider a new approach @Mauro, @Hans, @Sailus what do
you think about?

BTW: IMHO videobuf2 interface isn't that good as well, since you are
blaming ;)

Regards,
  Marco

> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
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 quanyang.wang at windriver.com  Fri Apr 30 07:56:46 2021
From: quanyang.wang at windriver.com (quanyang.wang)
Date: Fri, 30 Apr 2021 14:56:46 +0800
Subject: [PATCH] dmaengine: xilinx: dpdma: request_irq after initializing
 dma channels
In-Reply-To: <e8a245ac-e326-0e10-728b-b0ded7c03a71@xilinx.com>
References: <20210429065821.3495234-1-quanyang.wang@windriver.com>
 <YItRB7SBhiilzDLk@pendragon.ideasonboard.com>
 <1d88d67b-aaf5-823d-0cf6-c9422c01918c@windriver.com>
 <e8a245ac-e326-0e10-728b-b0ded7c03a71@xilinx.com>
Message-ID: <a0a471fa-c9ea-a838-95f2-3b688fe10505@windriver.com>

Hi Michal,

On 4/30/21 2:51 PM, Michal Simek wrote:
> Hi,
>
> On 4/30/21 3:45 AM, quanyang.wang wrote:
>> Hi Laurent,
>>
>> On 4/30/21 8:36 AM, Laurent Pinchart wrote:
>>> Hi Quanyang,
>>>
>>> Thank you for the patch.
>>>
>>> On Thu, Apr 29, 2021 at 02:58:21PM +0800, quanyang.wang at windriver.com
>>> wrote:
>>>> From: Quanyang Wang <quanyang.wang at windriver.com>
>>>>
>>>> In some scenarios (kdump), dpdma hardware irqs has been enabled when
>>>> calling request_irq in probe function, and then the dpdma irq handler
>>>> xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at
>>>> this moment xdev->chan[i] hasn't been initialized. So let's call the
>>>> request_irq after initializing dma channels to avoid kdump kernel
>>>> crash as below:
>>>>
>>>> [??? 3.696128] Unable to handle kernel NULL pointer dereference at
>>>> virtual address 000000000000012c
>>>> [??? 3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx
>>>> DPDMA engine is probed
>>>> [??? 3.704900] Mem abort info:
>>>> [??? 3.704902]?? ESR = 0x96000005
>>>> [??? 3.704905]?? EC = 0x25: DABT (current EL), IL = 32 bits
>>>> [??? 3.704907]?? SET = 0, FnV = 0
>>>> [??? 3.704912]?? EA = 0, S1PTW = 0
>>>> [??? 3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using
>>>> dummy regulator
>>>> [??? 3.715585] Data abort info:
>>>> [??? 3.715587]?? ISV = 0, ISS = 0x00000005
>>>> [??? 3.715589]?? CM = 0, WnR = 0
>>>> [??? 3.715592] [000000000000012c] user address but active_mm is swapper
>>>> [??? 3.715596] Internal error: Oops: 96000005 [#1] SMP
>>>> [??? 3.715599] Modules linked in:
>>>> [??? 3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>>> 5.10.0-12170-g60894882155f-dirty #77
>>>> [??? 3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
>>>> [??? 3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
>>>> [??? 3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560
>>>> [??? 3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560
>>>> [??? 3.798089] sp : ffffffc01186bdf0
>>>> [??? 3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28
>>>> [??? 3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080
>>>> [??? 3.811996] x25: 0000000008000408 x24: 0000000000000003
>>>> [??? 3.817300] x23: ffffffc01186be70 x22: ffffffc011291740
>>>> [??? 3.822604] x21: 0000000000000000 x20: 0000000008000408
>>>> [??? 3.827908] x19: 0000000000000000 x18: 0000000000000010
>>>> [??? 3.833212] x17: 0000000000000000 x16: 0000000000000000
>>>> [??? 3.838516] x15: 0000000000000000 x14: ffffffc011291740
>>>> [??? 3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d
>>>> [??? 3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48
>>>> [??? 3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268
>>>> [??? 3.859732] x7 : 0000000000000000 x6 : ffffffc011836000
>>>> [??? 3.865036] x5 : 0000000000000003 x4 : 0000000000000000
>>>> [??? 3.870340] x3 : 0000000000000001 x2 : 0000000000000000
>>>> [??? 3.875644] x1 : 0000000000000000 x0 : 000000000000012c
>>>> [??? 3.880948] Call trace:
>>>> [??? 3.883382]? xilinx_dpdma_irq_handler+0x418/0x560
>>>> [??? 3.888079]? __handle_irq_event_percpu+0x5c/0x178
>>>> [??? 3.892774]? handle_irq_event_percpu+0x34/0x98
>>>> [??? 3.897210]? handle_irq_event+0x44/0xb8
>>>> [??? 3.901030]? handle_fasteoi_irq+0xd0/0x190
>>>> [??? 3.905117]? generic_handle_irq+0x30/0x48
>>>> [??? 3.909111]? __handle_domain_irq+0x64/0xc0
>>>> [??? 3.913192]? gic_handle_irq+0x78/0xa0
>>>> [??? 3.916846]? el1_irq+0xc4/0x180
>>>> [??? 3.919982]? cpuidle_enter_state+0x134/0x2f8
>>>> [??? 3.924243]? cpuidle_enter+0x38/0x50
>>>> [??? 3.927810]? call_cpuidle+0x1c/0x40
>>>> [??? 3.931290]? do_idle+0x20c/0x270
>>>> [??? 3.934502]? cpu_startup_entry+0x28/0x58
>>>> [??? 3.938410]? rest_init+0xbc/0xcc
>>>> [??? 3.941631]? arch_call_rest_init+0x10/0x1c
>>>> [??? 3.945718]? start_kernel+0x51c/0x558
>>>>
>>>> Fixes: 7cbb0c63de3f ("dmaengine: xilinx: dpdma: Add the Xilinx
>>>> DisplayPort DMA engine driver")
>>>> Signed-off-by: Quanyang Wang <quanyang.wang at windriver.com>
>>>> ---
>>>>  ? drivers/dma/xilinx/xilinx_dpdma.c | 30 +++++++++++++++---------------
>>>>  ? 1 file changed, 15 insertions(+), 15 deletions(-)
>>>>
>>>> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c
>>>> b/drivers/dma/xilinx/xilinx_dpdma.c
>>>> index 70b29bd079c9..0b599402c53f 100644
>>>> --- a/drivers/dma/xilinx/xilinx_dpdma.c
>>>> +++ b/drivers/dma/xilinx/xilinx_dpdma.c
>>>> @@ -1622,19 +1622,6 @@ static int xilinx_dpdma_probe(struct
>>>> platform_device *pdev)
>>>>  ????? if (IS_ERR(xdev->reg))
>>>>  ????????? return PTR_ERR(xdev->reg);
>>>>  ? -??? xdev->irq = platform_get_irq(pdev, 0);
>>>> -??? if (xdev->irq < 0) {
>>>> -??????? dev_err(xdev->dev, "failed to get platform irq\n");
>>>> -??????? return xdev->irq;
>>>> -??? }
>>>> -
>>>> -??? ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>>>> -????????????? dev_name(xdev->dev), xdev);
>>>> -??? if (ret) {
>>>> -??????? dev_err(xdev->dev, "failed to request IRQ\n");
>>>> -??????? return ret;
>>>> -??? }
>>>> -
>>>>  ????? ddev = &xdev->common;
>>>>  ????? ddev->dev = &pdev->dev;
>>>>  ? @@ -1688,6 +1675,19 @@ static int xilinx_dpdma_probe(struct
>>>> platform_device *pdev)
>>>>  ????????? goto error_of_dma;
>>>>  ????? }
>>>>  ? +??? xdev->irq = platform_get_irq(pdev, 0);
>>>> +??? if (xdev->irq < 0) {
>>>> +??????? dev_err(xdev->dev, "failed to get platform irq\n");
>>> As reported by the kbuild bot, ret isn't initialized here.
>> I will fix this in V2.
>>>> +??????? goto error_irq;
>>>> +??? }
>>> This part could stay where it was, just after
>>> devm_platform_ioremap_resource().
>> OK?I will move it back.
>>>> +
>>>> +??? ret = request_irq(xdev->irq, xilinx_dpdma_irq_handler, IRQF_SHARED,
>>>> +????????????? dev_name(xdev->dev), xdev);
>>>> +??? if (ret) {
>>>> +??????? dev_err(xdev->dev, "failed to request IRQ\n");
>>>> +??????? goto error_irq;
>>>> +??? }
>>> Ideally we should reset the device before requesting the IRQ, to ensure
>>> we start in a consistent state. There doesn't seem to be any global
>>> reset unfortunately. Shouldn't we at least disable interrupts ? It may
>>> be a bit pointless though as we reenable them right below, so I suppose
>>> this would be OK.
>> Yes, we should start in a consistent and clean state. I will disable
>> interrupts
>>
>> and clean up registers state in V2.
>>
>>>> +
>>>>  ????? xilinx_dpdma_enable_irq(xdev);
>>>>  ? ????? xilinx_dpdma_debugfs_init(xdev);
>>>> @@ -1696,6 +1696,8 @@ static int xilinx_dpdma_probe(struct
>>>> platform_device *pdev)
>>>>  ? ????? return 0;
>>>>  ? +error_irq:
>>>> +??? of_dma_controller_free(pdev->dev.of_node);
>>> Why not free_irq() ? This change isn't described in the commit message.
>> I will add it in V2.
> When I was checking it that request_irq was called last. It means it
> wasn't necessary to free irq in error path. But double check it.

Thank you very much for your reminder.

Yes, free_irq is not necessary, and I have abandoned all modifications 
of V1 and

make a new V2 patch.

Thanks,

Quanyang

>
> M
>


From peng.fan at oss.nxp.com  Fri Apr 30 08:14:34 2021
From: peng.fan at oss.nxp.com (Peng Fan (OSS))
Date: Fri, 30 Apr 2021 15:14:34 +0800
Subject: [PATCH 16/16] soc: imx: gpcv2: remove waiting handshake in power
 up
In-Reply-To: <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-17-peng.fan@oss.nxp.com>
 <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>
Message-ID: <e5a94506-7bd3-93b6-b331-1cf04672a459@oss.nxp.com>



On 2021/4/29 22:34, Lucas Stach wrote:
> Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
>> From: Peng Fan <peng.fan at nxp.com>
>>
>> i.MX8MM has blk ctl module, the handshake can only finish after setting
>> blk ctl. The blk ctl driver will set the bus clk bit and the handshake
>> will finish there. we just add a delay and suppose the handshake will
>> finish after that.
> 
> Instead of this patch, just drop patch 05/16 from this series. I think
> we should leave a comment in the code on why we aren't waiting for the
> handshake ack, as this is non-obvious from looking at the driver code.
> 
> Basically add a polished version of the commit log from this patch into
> the driver code.

After thinking more, for power down, we need wait handshake. For power 
up, we could ignore handshake, because BLK-CTL setting bus clk en
will auto trigger handshake.

For power down, the bus clk en already set, and we need wait, otherwise
we need add delay there.

So I would only drop the power up waiting and add some comments there.

Thanks,
Peng.

> 
> Regards,
> Lucas
> 
>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>> ---
>>  ?drivers/soc/imx/gpcv2.c | 8 --------
>>  ?1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
>> index 49dd137f6b94..04564017bfe9 100644
>> --- a/drivers/soc/imx/gpcv2.c
>> +++ b/drivers/soc/imx/gpcv2.c
>> @@ -251,14 +251,6 @@ static int imx_pgc_power_up(struct generic_pm_domain *genpd)
>>  ?		regmap_update_bits(domain->regmap, GPC_PU_PWRHSK,
>>  ?				   domain->bits.hskreq, domain->bits.hskreq);
>>   
>>
>>
>>
>> -		ret = regmap_read_poll_timeout(domain->regmap, GPC_PU_PWRHSK,
>> -					       reg_val,
>> -					       (reg_val & domain->bits.hskack),
>> -					       0, USEC_PER_MSEC);
>> -		if (ret) {
>> -			dev_err(domain->dev, "failed to power up ADB400\n");
>> -			goto out_clk_disable;
>> -		}
>>  ?	}
>>   
>>
>>
>>
>>  ?	/* Disable reset clocks for all devices in the domain */
> 
> 


From chunfeng.yun at mediatek.com  Fri Apr 30 08:15:31 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 30 Apr 2021 15:15:31 +0800
Subject: [PATCH 2/3] usb: xhci-mtk: remove unnecessary assignments in periodic
 TT scheduler
In-Reply-To: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
References: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
Message-ID: <20210430071532.51794-2-chunfeng.yun@mediatek.com>

From: Ikjoon Jang <ikjn at chromium.org>

Remove unnecessary variables in check_sch_bw().
No functional changes, just for better readability.

Signed-off-by: Ikjoon Jang <ikjn at chromium.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk-sch.c | 37 +++++++++++++--------------------
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index 8b90da5a6ed1..9fb75085e40f 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -476,6 +476,9 @@ static int check_sch_tt(struct mu3h_sch_ep_info *sch_ep, u32 offset)
 	u32 start_cs, last_cs;
 	int i;
 
+	if (!sch_ep->sch_tt)
+		return 0;
+
 	start_ss = offset % 8;
 
 	if (sch_ep->ep_type == ISOC_OUT_EP) {
@@ -603,54 +606,42 @@ static u32 get_esit_boundary(struct mu3h_sch_ep_info *sch_ep)
 static int check_sch_bw(struct mu3h_sch_bw_info *sch_bw,
 			struct mu3h_sch_ep_info *sch_ep)
 {
+	const u32 esit_boundary = get_esit_boundary(sch_ep);
+	const u32 bw_boundary = get_bw_boundary(sch_ep->speed);
 	u32 offset;
-	u32 min_bw;
-	u32 min_index;
 	u32 worst_bw;
-	u32 bw_boundary;
-	u32 esit_boundary;
-	u32 min_num_budget;
-	u32 min_cs_count;
+	u32 min_bw = ~0;
+	int min_index = -1;
 	int ret = 0;
 
 	/*
 	 * Search through all possible schedule microframes.
 	 * and find a microframe where its worst bandwidth is minimum.
 	 */
-	min_bw = ~0;
-	min_index = 0;
-	min_cs_count = sch_ep->cs_count;
-	min_num_budget = sch_ep->num_budget_microframes;
-	esit_boundary = get_esit_boundary(sch_ep);
 	for (offset = 0; offset < sch_ep->esit; offset++) {
-		if (sch_ep->sch_tt) {
-			ret = check_sch_tt(sch_ep, offset);
-			if (ret)
-				continue;
-		}
+		ret = check_sch_tt(sch_ep, offset);
+		if (ret)
+			continue;
 
 		if ((offset + sch_ep->num_budget_microframes) > esit_boundary)
 			break;
 
 		worst_bw = get_max_bw(sch_bw, sch_ep, offset);
+		if (worst_bw > bw_boundary)
+			continue;
+
 		if (min_bw > worst_bw) {
 			min_bw = worst_bw;
 			min_index = offset;
-			min_cs_count = sch_ep->cs_count;
-			min_num_budget = sch_ep->num_budget_microframes;
 		}
 		if (min_bw == 0)
 			break;
 	}
 
-	bw_boundary = get_bw_boundary(sch_ep->speed);
-	/* check bandwidth */
-	if (min_bw > bw_boundary)
+	if (min_index < 0)
 		return ret ? ret : -ESCH_BW_OVERFLOW;
 
 	sch_ep->offset = min_index;
-	sch_ep->cs_count = min_cs_count;
-	sch_ep->num_budget_microframes = min_num_budget;
 
 	return load_ep_bw(sch_bw, sch_ep, true);
 }
-- 
2.18.0

From chunfeng.yun at mediatek.com  Fri Apr 30 08:15:32 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 30 Apr 2021 15:15:32 +0800
Subject: [PATCH 3/3] usb: xhci-mtk: use first-fit for LS/FS
In-Reply-To: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
References: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
Message-ID: <20210430071532.51794-3-chunfeng.yun@mediatek.com>

Use first-fit instead of best-fit for LS/FS devices under TT,
we found that best-fit will consume more bandwidth for some
cases.

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk-sch.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
index 9fb75085e40f..c07411d9b16f 100644
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -634,6 +634,11 @@ static int check_sch_bw(struct mu3h_sch_bw_info *sch_bw,
 			min_bw = worst_bw;
 			min_index = offset;
 		}
+
+		/* use first-fit for LS/FS */
+		if (sch_ep->sch_tt && min_index >= 0)
+			break;
+
 		if (min_bw == 0)
 			break;
 	}
-- 
2.18.0

From jbx6244 at gmail.com  Fri Apr 30 08:21:38 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 30 Apr 2021 09:21:38 +0200
Subject: [RFC PATCH v1] dt-bindings: mmc: snps, dwcmshc-sdhci: fix rockchip,
 txclk-tapnum
Message-ID: <20210430072138.6537-1-jbx6244@gmail.com>

A test with the command below gives this error:
mmc at fe310000: rockchip,txclk-tapnum: missing size tag in [[8]]

With this added to a dts file:
rockchip,txclk-tapnum = <0x8>;

A look at the driver shows that:
DLL_TXCLK_TAPNUM_DEFAULT	0x8

Adding the default value to the dts files is not needed.
Every clock is divided into 32 taps equally and
the max value is 31.

Fix rockchip,txclk-tapnum property in snps,dwcmshc-sdhci.yaml by
adding a minimum, maximum and default.

In the driver the function of_property_read_u8() is used,
but with dtbs_check the notifications only disappear in YAML
by changing uint8 to uint32.
The driver has no limit check for rockchip,txclk-tapnum.

make ARCH=arm64 dtbs_check

Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
---
 Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
index e6c9a2f77..f43d8d829 100644
--- a/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
@@ -48,7 +48,10 @@ properties:
 
   rockchip,txclk-tapnum:
     description: Specify the number of delay for tx sampling.
-    $ref: /schemas/types.yaml#/definitions/uint8
+    $ref: /schemas/types.yaml#/definitions/uint32
+    minimum: 0
+    maximum: 31
+    default: 8
 
 
 required:
-- 
2.11.0



From chunfeng.yun at mediatek.com  Fri Apr 30 08:15:30 2021
From: chunfeng.yun at mediatek.com (Chunfeng Yun)
Date: Fri, 30 Apr 2021 15:15:30 +0800
Subject: [PATCH 1/3] usb: xhci-mtk: use bitfield instead of bool
Message-ID: <20210430071532.51794-1-chunfeng.yun@mediatek.com>

Use bitfield instead of bool in struct

Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
---
 drivers/usb/host/xhci-mtk.c | 2 --
 drivers/usb/host/xhci-mtk.h | 8 ++++----
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b2058b3bc834..2548976bcf05 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -495,8 +495,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 			goto put_usb2_hcd;
 		}
 		mtk->has_ippc = true;
-	} else {
-		mtk->has_ippc = false;
 	}
 
 	device_init_wakeup(dev, true);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index cd3a37bb73e6..94a59b3d178f 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -138,17 +138,17 @@ struct xhci_hcd_mtk {
 	struct mu3h_sch_bw_info *sch_array;
 	struct list_head bw_ep_chk_list;
 	struct mu3c_ippc_regs __iomem *ippc_regs;
-	bool has_ippc;
 	int num_u2_ports;
 	int num_u3_ports;
 	int u3p_dis_msk;
 	struct regulator *vusb33;
 	struct regulator *vbus;
 	struct clk_bulk_data clks[BULK_CLKS_NUM];
-	bool lpm_support;
-	bool u2_lpm_disable;
+	unsigned int has_ippc:1;
+	unsigned int lpm_support:1;
+	unsigned int u2_lpm_disable:1;
 	/* usb remote wakeup */
-	bool uwk_en;
+	unsigned int uwk_en:1;
 	struct regmap *uwk;
 	u32 uwk_reg_base;
 	u32 uwk_vers;
-- 
2.18.0

From o.rempel at pengutronix.de  Fri Apr 30 08:26:09 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Fri, 30 Apr 2021 09:26:09 +0200
Subject: [PATCH net-next v3 3/6] net: add generic selftest support
In-Reply-To: <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <20210419130106.6707-4-o.rempel@pengutronix.de>
 <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>
Message-ID: <20210430072609.GA6711@pengutronix.de>

Hi Geert,

On Fri, Apr 30, 2021 at 08:45:05AM +0200, Geert Uytterhoeven wrote:
> Hi Oleksij,
> 
> On Mon, Apr 19, 2021 at 3:13 PM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> > Port some parts of the stmmac selftest and reuse it as basic generic selftest
> > library. This patch was tested with following combinations:
> > - iMX6DL FEC -> AT8035
> > - iMX6DL FEC -> SJA1105Q switch -> KSZ8081
> > - iMX6DL FEC -> SJA1105Q switch -> KSZ9031
> > - AR9331 ag71xx -> AR9331 PHY
> > - AR9331 ag71xx -> AR9331 switch -> AR9331 PHY
> >
> > Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> 
> Thanks for your patch, which is now commit 3e1e58d64c3d0a67 ("net: add
> generic selftest support") upstream.
>
> > --- a/net/Kconfig
> > +++ b/net/Kconfig
> > @@ -429,6 +429,10 @@ config GRO_CELLS
> >  config SOCK_VALIDATE_XMIT
> >         bool
> >
> > +config NET_SELFTESTS
> > +       def_tristate PHYLIB
> 
> Why does this default to enabled if PHYLIB=y?
> Usually we allow the user to make selftests modular, independent of the
> feature under test, but I may misunderstand the purpose of this test.
> 
> Thanks for your clarification!

There is nothing against making optional. Should I do it?

Regards,
Oleksij
-- 
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 gregkh at linuxfoundation.org  Fri Apr 30 08:29:15 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 30 Apr 2021 09:29:15 +0200
Subject: [PATCH 1/3] usb: xhci-mtk: use bitfield instead of bool
In-Reply-To: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
References: <20210430071532.51794-1-chunfeng.yun@mediatek.com>
Message-ID: <YIuxy9OtlNzq7zwM@kroah.com>

On Fri, Apr 30, 2021 at 03:15:30PM +0800, Chunfeng Yun wrote:
> Use bitfield instead of bool in struct

That says what you did, but not why you did it.

Why?

> 
> Signed-off-by: Chunfeng Yun <chunfeng.yun at mediatek.com>
> ---
>  drivers/usb/host/xhci-mtk.c | 2 --
>  drivers/usb/host/xhci-mtk.h | 8 ++++----
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index b2058b3bc834..2548976bcf05 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -495,8 +495,6 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>  			goto put_usb2_hcd;
>  		}
>  		mtk->has_ippc = true;
> -	} else {
> -		mtk->has_ippc = false;

Why did you remove this chunk?  That is not described in the changelog
at all.

thanks,

greg k-h


From jianjun.wang at mediatek.com  Fri Apr 30 08:24:54 2021
From: jianjun.wang at mediatek.com (Jianjun Wang)
Date: Fri, 30 Apr 2021 15:24:54 +0800
Subject: [PATCH][next] PCI: mediatek-gen3: Add missing null pointer check
In-Reply-To: <20210429110040.63119-1-colin.king@canonical.com>
References: <20210429110040.63119-1-colin.king@canonical.com>
Message-ID: <1619767494.1027.3.camel@mhfsdcap03>

Hi Colin,

On Thu, 2021-04-29 at 12:00 +0100, Colin King wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> The call to platform_get_resource_byname can potentially return null, so
> add a null pointer check to avoid a null pointer dereference issue.
> 
> Addresses-Coverity: ("Dereference null return")
> Fixes: 441903d9e8f0 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> index 20165e4a75b2..3c5b97716d40 100644
> --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -721,6 +721,8 @@ static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
>  	int ret;
>  
>  	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
> +	if (!regs)
> +		return -EINVAL;

Thanks for your patch.

devm_ioremap_resource() will check and decode this null pointer
dereference error, so I don't think we need to check here.

Thanks.

>  	port->base = devm_ioremap_resource(dev, regs);
>  	if (IS_ERR(port->base)) {
>  		dev_err(dev, "failed to map register base\n");



From geert at linux-m68k.org  Fri Apr 30 08:49:30 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 09:49:30 +0200
Subject: [PATCH net-next v3 3/6] net: add generic selftest support
In-Reply-To: <20210430072609.GA6711@pengutronix.de>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <20210419130106.6707-4-o.rempel@pengutronix.de>
 <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>
 <20210430072609.GA6711@pengutronix.de>
Message-ID: <CAMuHMdUjU1KEg1PTcDHJKJNXPeGsacHNjiCBy_obA7MNAWJ2QA@mail.gmail.com>

Hi Oleksij,

On Fri, Apr 30, 2021 at 9:26 AM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> On Fri, Apr 30, 2021 at 08:45:05AM +0200, Geert Uytterhoeven wrote:
> > On Mon, Apr 19, 2021 at 3:13 PM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> > > Port some parts of the stmmac selftest and reuse it as basic generic selftest
> > > library. This patch was tested with following combinations:
> > > - iMX6DL FEC -> AT8035
> > > - iMX6DL FEC -> SJA1105Q switch -> KSZ8081
> > > - iMX6DL FEC -> SJA1105Q switch -> KSZ9031
> > > - AR9331 ag71xx -> AR9331 PHY
> > > - AR9331 ag71xx -> AR9331 switch -> AR9331 PHY
> > >
> > > Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> >
> > Thanks for your patch, which is now commit 3e1e58d64c3d0a67 ("net: add
> > generic selftest support") upstream.
> >
> > > --- a/net/Kconfig
> > > +++ b/net/Kconfig
> > > @@ -429,6 +429,10 @@ config GRO_CELLS
> > >  config SOCK_VALIDATE_XMIT
> > >         bool
> > >
> > > +config NET_SELFTESTS
> > > +       def_tristate PHYLIB
> >
> > Why does this default to enabled if PHYLIB=y?
> > Usually we allow the user to make selftests modular, independent of the
> > feature under test, but I may misunderstand the purpose of this test.
> >
> > Thanks for your clarification!
>
> There is nothing against making optional. Should I do it?

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 christophe.jaillet at wanadoo.fr  Fri Apr 30 08:47:06 2021
From: christophe.jaillet at wanadoo.fr (Christophe JAILLET)
Date: Fri, 30 Apr 2021 09:47:06 +0200
Subject: [PATCH][next] PCI: mediatek-gen3: Add missing null pointer check
In-Reply-To: <20210429110040.63119-1-colin.king@canonical.com>
References: <20210429110040.63119-1-colin.king@canonical.com>
Message-ID: <7a512e3a-2897-ac12-ac6e-06be28735279@wanadoo.fr>

Le 29/04/2021 ? 13:00, Colin King a ?crit?:
> From: Colin Ian King <colin.king at canonical.com>
> 
> The call to platform_get_resource_byname can potentially return null, so
> add a null pointer check to avoid a null pointer dereference issue.
> 
> Addresses-Coverity: ("Dereference null return")
> Fixes: 441903d9e8f0 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>   drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> index 20165e4a75b2..3c5b97716d40 100644
> --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -721,6 +721,8 @@ static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
>   	int ret;
>   
>   	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
> +	if (!regs)
> +		return -EINVAL;
>   	port->base = devm_ioremap_resource(dev, regs);
>   	if (IS_ERR(port->base)) {
>   		dev_err(dev, "failed to map register base\n");
> 

Nitpick:
    Using 'devm_platform_ioremap_resource_byname' is slightly less 
verbose and should please Coverity.


Also, which git repo are you using? On linux-next ([1)], your proposed 
patch is already part of "PCI: mediatek-gen3: Add MediaTek Gen3 driver 
for MT8192".

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/pci/controller/pcie-mediatek-gen3.c

CJ


From narmstrong at baylibre.com  Fri Apr 30 09:16:48 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 30 Apr 2021 10:16:48 +0200
Subject: [PATCH 3/3] arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts
In-Reply-To: <CAFBinCDQeTU0ss=oNmjX78MPyNZmmCt-haojNNcQqkjJUmJYKQ@mail.gmail.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
 <20210429170404.3616111-4-narmstrong@baylibre.com>
 <CAFBinCDQeTU0ss=oNmjX78MPyNZmmCt-haojNNcQqkjJUmJYKQ@mail.gmail.com>
Message-ID: <cafdf662-6f15-8e16-7752-5740f28b6682@baylibre.com>

Hi Martin,

On 29/04/2021 23:30, Martin Blumenstingl wrote:
> Hi Neil,
> 
> thanks for adding support for the BPI-M5!
> I had this on my TODO-list for a long time but didn't have enough time
> so far. so it's great to see this patch now :-)
Same, so it's nearly done now !

> 
> On Thu, Apr 29, 2021 at 7:04 PM Neil Armstrong <narmstrong at baylibre.com> wrote:
> [...]
>> +       adc_keys {
>> +               compatible = "adc-keys";
>> +               io-channels = <&saradc 2>;
>> +               io-channel-names = "buttons";
>> +               keyup-threshold-microvolt = <1800000>;
>> +
>> +               button-onoff {
> maybe just "key" (as you used below for SW1)?

Fixed

> 
>> +                       label = "SW3";
>> +                       linux,code = <BTN_3>;
>> +                       press-threshold-microvolt = <1700000>;
>> +               };
>> +       };
> 
>> +       /* TOFIX: handle CVBS_DET on SARADC channel 0 */
> it's great to see that after many years at least some boards finally
> can detect whether the CVBS connector is plugged it

Yes, it's also available on Odroid-N2(+), so now no excuse for not supporting it !

> 
>> +       memory at 0 {
>> +               device_type = "memory";
>> +               reg = <0x0 0x0 0x0 0x40000000>;
>> +       };
> note to self: u-boot will update this from 1GiB to 4GiB
> 
>> +       flash_1v8: regulator-flash_1v8 {
>> +               compatible = "regulator-fixed";
>> +               regulator-name = "FLASH_1V8";
> BPI-M5-SCH-V10-Release.pdf schematics are calling this EMMC_1V8. I
> suggest to use that name so it's easier to compare this with the
> schematics in the future

Done

> 
>> +               regulator-min-microvolt = <1800000>;
>> +               regulator-max-microvolt = <1800000>;
>> +               vin-supply = <&vddao_3v3>;
>> +               regulator-always-on;
>> +       };
>> +
>> +       dc_in: regulator-dc_in {
>> +               compatible = "regulator-fixed";
>> +               regulator-name = "5V";
> maybe use "DC_IN" here as well so the node-name matches what we see in
> userspace/kernel logs?

Done

> 
>> +       vddcpu: regulator-vddcpu {
>> +               /*
>> +                * SY8120B1ABC DC/DC Regulator.
>> +                */
>> +               compatible = "pwm-regulator";
>> +
>> +               regulator-name = "VDDCPU";
>> +               regulator-min-microvolt = <721000>;
>> +               regulator-max-microvolt = <1022000>;
> the vendor .dts has:
>   regulator-min-microvolt = <690000>;
>   regulator-max-microvolt = <1050000>;
> which also matches meson-sm1-sei610.dts (which uses the same regulator IC)

Done, thanks

> 
> [...]
>> +&ethmac {
>> +       pinctrl-0 = <&eth_pins>, <&eth_rgmii_pins>;
>> +       pinctrl-names = "default";
>> +       status = "okay";
>> +       phy-mode = "rgmii";
>> +       phy-handle = <&external_phy>;
>> +       amlogic,tx-delay-ns = <2>;
> I haven't checked their u-boot code but some of the newer Amlogic BSPs
> seem to let the PHY add the TX delay (which is also what the netdev
> maintainers recommend)
> that can be achieved by setting:
>   phy-mode = "rgmii-txid";
> and deleting the "amlogic,tx-delay-ns" property

Done, but what about when we use mainline U-boot here ?

> 
>> +&gpio {
>> +       gpio-line-names =
>> +               /* GPIOZ */
>> +               "", "", "", "", "", "", "", "",
> GPIOZ_0 to GPIOZ_15:
> - ETH_MDIO
> - ETH_MDC
> - ETH_RXCLK
> - ETH_RX_DV
> - ETH_RXD0
> - ETH_RXD1
> - ETH_RXD2
> - ETH_RXD3
> - ETH_TXCLK
> - ETH_TXEN
> - ETH_TXD0
> - ETH_TXD1
> - ETH_TXD2
> - ETH_TXD3
> - ETH_INTR
> - ETH_NRST
> 
>> +               /* GPIOH */
>> +               "", "", "", "", "",
> GPIOH_0 to GPIOH_4:
> - HDMI_SDA
> - HDMI_SCL
> - HDMI_HPD
> - HDMI_CEC
> - VL-RST_N
> 
>> +               "CON1-P36", /* GPIOH_5 */
> GPIOH_6 to GPIOH_8:
> - VL-PWREN
> - WiFi_3V3_1V8
> - TFLASH_VDD_EN
> 
>> +               /* BOOT */
>> +               "", "", "", "", "", "", "", "",
>> +               "", "", "", "", "", "", "", "",
> BOOT_0 to BOOT_13:
> - eMMC_D0
> - eMMC_D1
> - eMMC_D2
> - eMMC_D3
> - eMMC_D4
> - eMMC_D5
> - eMMC_D6
> - eMMC_D7
> - eMMC_CLK
> - (BOOT_9 is unused)
> - eMMC_CMD
> - (BOOT_11 is unused)
> - eMMC_RST#
> - eMMC_DS
> 
>> +               /* GPIOC */
>> +               "", "", "", "", "", "", "", "",
> GPIOC_0 to GPIOC_7:
> - SD_D0_B
> - SD_D1_B
> - SD_D2_B
> - SD_D3_B
> - SD_CLK_B
> - SD_CMD_B
> - CARD_EN_DET
> - (GPIOC_7 is unused)
> 
> 
>> +&gpio_ao {
>> +       gpio-line-names =
>> +               /* GPIOAO */
>> +               "DEBUG TX", /* GPIOAO_0 */
>> +               "DEBUG RX", /* GPIOAO_1 */
>> +               "SYS_LED2", /* GPIOAO_2 */
>> +               "UPDATE_KEY", /* GPIOAO_3 */
>> +               "CON1-P40", /* GPIOAO_4 */
>> +               "",
> GPIOAO_5 is IR_IN
> 
>> +               "TF_3V3N_1V8_EN", /* GPIOAO_6 */
>> +               "CON1-P35", /* GPIOAO_7 */
>> +               "CON1-P12", /* GPIOAO_8 */
>> +               "CON1-P37", /* GPIOAO_9 */
>> +               "CON1-P38", /* GPIOAO_10 */
>> +               "SYS_LED", /* GPIOAO_11 */
>> +               /* GPIOE */
>> +               "", "", "";
> GPIOE_0 to GPIOOE_2:
> - VDDEE_PWM
> - VDDCPU_PWM
> - TF_PWR_EN

I was to lazy to do that, so thanks !

> 
>> +&usb2_phy0 {
>> +       phy-supply = <&dc_in>;
>> +};
>> +
>> +&usb2_phy1 {
>> +       /* Enable the hub which is connected to this port */
>> +       phy-supply = <&vl_pwr_en>;
>> +};
> I think technically we'd need to use AVDD18_USB here (that said, I
> chose the same approach as you are using here before..)
> USB bus devices (AFAIK) still need to be detected before any
> device-tree properties can be applied and there's (again AFAIK) still
> no pwrseq concept.
> so I guess for now this is the way to go as there's enough comments
> about it in your patch

yeah we'll see if there is proper pwrseq method to fix that (and the hub reset)

Thanks for the review,

Neil

> 
> 
> Best regards,
> Martin
> 



From szabolcs.nagy at arm.com  Fri Apr 30 09:16:33 2021
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Fri, 30 Apr 2021 09:16:33 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <CAGG=3QW9t2zUPYLt_La=qQTZeHzfLBCXgZRbiia8T6K7n=YrdQ@mail.gmail.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
 <20210429075454.GQ9028@arm.com>
 <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>
 <20210429095027.GR9028@arm.com>
 <CAGG=3QW9t2zUPYLt_La=qQTZeHzfLBCXgZRbiia8T6K7n=YrdQ@mail.gmail.com>
Message-ID: <20210430081632.GS9028@arm.com>

The 04/29/2021 11:52, Bill Wendling wrote:
> $ readelf -lW arch/arm64/kernel/vdso/vdso.so
> 
> Elf file type is DYN (Shared object file)
> Entry point 0x300
> There are 4 program headers, starting at offset 64
> 
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr
> FileSiz  MemSiz   Flg Align
>   LOAD           0x000000 0x0000000000000000 0x0000000000000000
> 0x000968 0x000968 R E 0x8
>   DYNAMIC        0x0008a8 0x00000000000008a8 0x00000000000008a8
> 0x0000c0 0x0000c0 R   0x8
>   NOTE           0x000288 0x0000000000000288 0x0000000000000288
> 0x000074 0x000074 R   0x8
>   GNU_EH_FRAME   0x0008a4 0x00000000000008a4 0x00000000000008a4
> 0x000000 0x000000 R E 0x1

this is wrong because the abi specifically says properties
are in PT_GNU_PROPERTY, not in PT_NOTE.

so the original patch that removes them from notes is fine,
but ideally they should be readded under PT_GNU_PROPERTY.

(x86 needs it there too, but also needs it under PT_NOTE for
historical reasons. ideally the section would have been named
other than .note and was not marked as SHF_NOTE, because
properties are merged completely differently by the linker
than notes, so now linkers have to special case it by section
name. properties should have been designed like the
 .ARM.attributes section except that is not in a load segment
and thus has no runtime semantics while the key feature of
properties is the runtime semantics. however accessing the
program headers of the vdso is not trivial at runtime from
user code so dropping the properties might work too, but can
bite us in the future depending on how they evolve: the ld.so
can look at vdso program headers.)


From narmstrong at baylibre.com  Fri Apr 30 09:27:44 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 30 Apr 2021 10:27:44 +0200
Subject: [PATCH] drm/meson: fix shutdown crash when component not probed
Message-ID: <20210430082744.3638743-1-narmstrong@baylibre.com>

When main component is not probed, by example when the dw-hdmi module is
not loaded yet or in probe defer, the following crash appears on shutdown:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
...
pc : meson_drv_shutdown+0x24/0x50
lr : platform_drv_shutdown+0x20/0x30
...
Call trace:
meson_drv_shutdown+0x24/0x50
platform_drv_shutdown+0x20/0x30
device_shutdown+0x158/0x360
kernel_restart_prepare+0x38/0x48
kernel_restart+0x18/0x68
__do_sys_reboot+0x224/0x250
__arm64_sys_reboot+0x24/0x30
...

Simply check if the priv struct has been allocated before using it.

Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function")
Reported-by: Stefan Agner <stefan at agner.ch>
Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
---
 drivers/gpu/drm/meson/meson_drv.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 453d8b4c5763..07fcd12dca16 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -485,11 +485,12 @@ static int meson_probe_remote(struct platform_device *pdev,
 static void meson_drv_shutdown(struct platform_device *pdev)
 {
 	struct meson_drm *priv = dev_get_drvdata(&pdev->dev);
-	struct drm_device *drm = priv->drm;
 
-	DRM_DEBUG_DRIVER("\n");
-	drm_kms_helper_poll_fini(drm);
-	drm_atomic_helper_shutdown(drm);
+	if (!priv)
+		return;
+
+	drm_kms_helper_poll_fini(priv->drm);
+	drm_atomic_helper_shutdown(priv->drm);
 }
 
 static int meson_drv_probe(struct platform_device *pdev)
-- 
2.25.1



From morbo at google.com  Fri Apr 30 09:29:12 2021
From: morbo at google.com (Bill Wendling)
Date: Fri, 30 Apr 2021 01:29:12 -0700
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210430081632.GS9028@arm.com>
References: <20210423205159.830854-1-morbo@google.com>
 <20210428172847.GC4022@arm.com>
 <20210428174010.GA4593@sirena.org.uk>
 <CAGG=3QUATefn9AG+HvnCfEOBv3iRu4fzFwfmA7Djrh2CmP_weA@mail.gmail.com>
 <CAGG=3QUNykCfkS22g+HRWb0Goa8DJ72TUueLtMe5v1YfnStojw@mail.gmail.com>
 <20210429075454.GQ9028@arm.com>
 <CAGG=3QV0kR__23yEmwwXBpcE1gvjLqRNmF667hhVeY0B3urTqQ@mail.gmail.com>
 <20210429095027.GR9028@arm.com>
 <CAGG=3QW9t2zUPYLt_La=qQTZeHzfLBCXgZRbiia8T6K7n=YrdQ@mail.gmail.com>
 <20210430081632.GS9028@arm.com>
Message-ID: <CAGG=3QWX+7aiF6okY0ybsaa1bK4pJn4YPGUhnGZotiz+cN8Xrg@mail.gmail.com>

On Fri, Apr 30, 2021 at 1:17 AM Szabolcs Nagy <szabolcs.nagy at arm.com> wrote:
> The 04/29/2021 11:52, Bill Wendling wrote:
> > $ readelf -lW arch/arm64/kernel/vdso/vdso.so
> >
> > Elf file type is DYN (Shared object file)
> > Entry point 0x300
> > There are 4 program headers, starting at offset 64
> >
> > Program Headers:
> >   Type           Offset   VirtAddr           PhysAddr
> > FileSiz  MemSiz   Flg Align
> >   LOAD           0x000000 0x0000000000000000 0x0000000000000000
> > 0x000968 0x000968 R E 0x8
> >   DYNAMIC        0x0008a8 0x00000000000008a8 0x00000000000008a8
> > 0x0000c0 0x0000c0 R   0x8
> >   NOTE           0x000288 0x0000000000000288 0x0000000000000288
> > 0x000074 0x000074 R   0x8
> >   GNU_EH_FRAME   0x0008a4 0x00000000000008a4 0x00000000000008a4
> > 0x000000 0x000000 R E 0x1
>
> this is wrong because the abi specifically says properties
> are in PT_GNU_PROPERTY, not in PT_NOTE.
>
Right. The issue is more complex than this fix is meant for, to be
honest. That is, it seems that there needs to be a generalized way of
handling the different .note sections.

-bw

> so the original patch that removes them from notes is fine,
> but ideally they should be readded under PT_GNU_PROPERTY.
>
> (x86 needs it there too, but also needs it under PT_NOTE for
> historical reasons. ideally the section would have been named
> other than .note and was not marked as SHF_NOTE, because
> properties are merged completely differently by the linker
> than notes, so now linkers have to special case it by section
> name. properties should have been designed like the
>  .ARM.attributes section except that is not in a load segment
> and thus has no runtime semantics while the key feature of
> properties is the runtime semantics. however accessing the
> program headers of the vdso is not trivial at runtime from
> user code so dropping the properties might work too, but can
> bite us in the future depending on how they evolve: the ld.so
> can look at vdso program headers.)


From narmstrong at baylibre.com  Fri Apr 30 09:31:13 2021
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Fri, 30 Apr 2021 10:31:13 +0200
Subject: [PATCH] ASoC: meson: g12a-toacodec: add support for SM1 TOACODEC
In-Reply-To: <1jo8dx9ec5.fsf@starbuckisacylon.baylibre.com>
References: <20210429170147.3615883-1-narmstrong@baylibre.com>
 <1jo8dx9ec5.fsf@starbuckisacylon.baylibre.com>
Message-ID: <d2e9fc82-1483-e4d0-db10-6c11d9fdbba9@baylibre.com>

On 29/04/2021 19:43, Jerome Brunet wrote:
> 
> On Thu 29 Apr 2021 at 19:01, Neil Armstrong <narmstrong at baylibre.com> wrote:
> 
> 
>>  
>> +static int sm1_toacodec_mux_put_enum(struct snd_kcontrol *kcontrol,
>> +				     struct snd_ctl_elem_value *ucontrol)
>> +{
>> +	struct snd_soc_component *component =
>> +		snd_soc_dapm_kcontrol_component(kcontrol);
>> +	struct snd_soc_dapm_context *dapm =
>> +		snd_soc_dapm_kcontrol_dapm(kcontrol);
>> +	struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;
>> +	unsigned int mux, changed;
>> +
>> +	mux = snd_soc_enum_item_to_val(e, ucontrol->value.enumerated.item[0]);
>> +	changed = snd_soc_component_test_bits(component, e->reg,
>> +					      CTRL0_DAT_SEL_SM1,
>> +					      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux));
>> +
>> +	if (!changed)
>> +		return 0;
>> +
>> +	/* Force disconnect of the mux while updating */
>> +	snd_soc_dapm_mux_update_power(dapm, kcontrol, 0, NULL, NULL);
>> +
>> +	snd_soc_component_update_bits(component, e->reg,
>> +				      CTRL0_DAT_SEL_SM1 |
>> +				      CTRL0_LRCLK_SEL_SM1 |
>> +				      CTRL0_BCLK_SEL_SM1,
>> +				      FIELD_PREP(CTRL0_DAT_SEL_SM1, mux) |
>> +				      FIELD_PREP(CTRL0_LRCLK_SEL_SM1, mux) |
>> +				      FIELD_PREP(CTRL0_BCLK_SEL_SM1, mux));
>> +
>> +	/*
>> +	 * FIXME:
>> +	 * On this soc, the glue gets the MCLK directly from the clock
>> +	 * controller instead of going the through the TDM interface.
>> +	 *
>> +	 * Here we assume interface A uses clock A, etc ... While it is
>> +	 * true for now, it could be different. Instead the glue should
>> +	 * find out the clock used by the interface and select the same
>> +	 * source. For that, we will need regmap backed clock mux which
>> +	 * is a work in progress
>> +	 */
>> +	snd_soc_component_update_bits(component, e->reg,
>> +				      CTRL0_MCLK_SEL,
>> +				      FIELD_PREP(CTRL0_MCLK_SEL, mux));
>> +
>> +	snd_soc_dapm_mux_update_power(dapm, kcontrol, mux, e, NULL);
>> +
>> +	return 0;
>> +}
> 
> Instead of duplicating this function, I'd prefer if you could use regmap fields
> 
> 

Sure, will do


From lorenzo.pieralisi at arm.com  Fri Apr 30 09:40:01 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 30 Apr 2021 09:40:01 +0100
Subject: [PATCH][next] PCI: mediatek-gen3: Add missing null pointer check
In-Reply-To: <20210429110040.63119-1-colin.king@canonical.com>
References: <20210429110040.63119-1-colin.king@canonical.com>
Message-ID: <20210430084001.GA12388@lpieralisi>

On Thu, Apr 29, 2021 at 12:00:40PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king at canonical.com>
> 
> The call to platform_get_resource_byname can potentially return null, so
> add a null pointer check to avoid a null pointer dereference issue.
> 
> Addresses-Coverity: ("Dereference null return")
> Fixes: 441903d9e8f0 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
>  1 file changed, 2 insertions(+)

Squashed into the commit it is fixing, in my pci/mediatek branch.

Thanks,
Lorenzo

> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> index 20165e4a75b2..3c5b97716d40 100644
> --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -721,6 +721,8 @@ static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
>  	int ret;
>  
>  	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
> +	if (!regs)
> +		return -EINVAL;
>  	port->base = devm_ioremap_resource(dev, regs);
>  	if (IS_ERR(port->base)) {
>  		dev_err(dev, "failed to map register base\n");
> -- 
> 2.30.2
> 


From l.stach at pengutronix.de  Fri Apr 30 09:47:08 2021
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 30 Apr 2021 10:47:08 +0200
Subject: [PATCH 16/16] soc: imx: gpcv2: remove waiting handshake in
 power up
In-Reply-To: <e5a94506-7bd3-93b6-b331-1cf04672a459@oss.nxp.com>
References: <20210429073050.21039-1-peng.fan@oss.nxp.com>
 <20210429073050.21039-17-peng.fan@oss.nxp.com>
 <abde5337ac265287f8e1225846e140e8df370f47.camel@pengutronix.de>
 <e5a94506-7bd3-93b6-b331-1cf04672a459@oss.nxp.com>
Message-ID: <914b4e28b1313fc3b0293faa60a21cb6afb83e40.camel@pengutronix.de>

Am Freitag, dem 30.04.2021 um 15:14 +0800 schrieb Peng Fan (OSS):
> 
> On 2021/4/29 22:34, Lucas Stach wrote:
> > Am Donnerstag, dem 29.04.2021 um 15:30 +0800 schrieb Peng Fan (OSS):
> > > From: Peng Fan <peng.fan at nxp.com>
> > > 
> > > i.MX8MM has blk ctl module, the handshake can only finish after setting
> > > blk ctl. The blk ctl driver will set the bus clk bit and the handshake
> > > will finish there. we just add a delay and suppose the handshake will
> > > finish after that.
> > 
> > Instead of this patch, just drop patch 05/16 from this series. I think
> > we should leave a comment in the code on why we aren't waiting for the
> > handshake ack, as this is non-obvious from looking at the driver code.
> > 
> > Basically add a polished version of the commit log from this patch into
> > the driver code.
> 
> After thinking more, for power down, we need wait handshake. For power 
> up, we could ignore handshake, because BLK-CTL setting bus clk en
> will auto trigger handshake.
> 
> For power down, the bus clk en already set, and we need wait, otherwise
> we need add delay there.
> 
> So I would only drop the power up waiting and add some comments there.

Ah, right. This way makes a lot of sense.

Regards,
Lucas



From roman.beranek at prusa3d.cz  Fri Apr 30 08:17:49 2021
From: roman.beranek at prusa3d.cz (Roman Beranek)
Date: Fri, 30 Apr 2021 09:17:49 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <20210430064145.nzlcw3lpayzapnbx@pengutronix.de>
Message-ID: <CB0VI785HYEE.3PXPB7BDOUPFC@zen.local>

Hello Uwe,

On Fri Apr 30, 2021 at 8:41 AM CEST, Uwe Kleine-K?nig wrote:
> On Fri, Apr 30, 2021 at 04:19:32AM +0200, Roman Ber?nek wrote:
> > On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-K?nig wrote:
> > > On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Ber?nek wrote:
> > > > Correct, the output may stay in an active state. I only discovered this
> > > > bug as I investigated a report of unreliable screen timeout. The period
> > > > we use the PWM with is 50 us.
> > >
> > > What I don't like here is that the delay is quite coarse and might still
> > > be too short. (Maybe I miss something, but consider the current period
> > > is quite long, then you configure a short one and then disable. In this
> > > case the inital long setting might still be active.)
> > 
> > The delay is calculated from the original period (cstate.period),
> > not the one that was just written into PWM_CHx_PRD 2 lines above.
>
> Yes, but that's not good enough. Consider the PWM is running with a
> period of 4s and the period just started. Then you call
>
> pwm_apply_state(mypwm, &(struct pwm_state){
> .period = 20,
> .enabled = 1,
> ...
> })
>
> This doesn't result into the waiting code being run, because
> .enabled = 1. Then immidiately after that call:
>
> pwm_apply_state(mypwm, &(struct pwm_state){
> .period = 20,
> .enabled = 0,
> ...
> })
>
> which triggers the waiting but only based on a period of 20 ns while the
> 4s period is still active.

OK, now I see what you mean. To remedy this, the delay shall occur
regardless of state->enabled.

In my view, this lies beneath the scope of the patch though and would be
better served as a follow-up.

Cheers,
Roman


From email2tema at gmail.com  Fri Apr 30 09:49:35 2021
From: email2tema at gmail.com (Art Nikpal)
Date: Fri, 30 Apr 2021 16:49:35 +0800
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
In-Reply-To: <20210426115645.GB4590@sirena.org.uk>
References: <20210423034247.992052-1-art@khadas.com>
 <20210423114735.GA5507@sirena.org.uk>
 <CAKaHn9+d5crmmG-aKyLuvyxk+A7aC9qqfX_3wuMXm50pg+pZ4w@mail.gmail.com>
 <20210426115645.GB4590@sirena.org.uk>
Message-ID: <CAKaHn9JM-KEiz3_Btsz8_fr7hcZ2Sm8B64VyLvgpvKK-NKco3w@mail.gmail.com>

Yep! but

if i try call spi_master_put(master) or spi_unregister_controller(master);
it's made Segmentation fault for me

what's wrong - may be somebody can help me


On Mon, Apr 26, 2021 at 7:57 PM Mark Brown <broonie at kernel.org> wrote:
>
> On Sat, Apr 24, 2021 at 07:57:19AM +0800, Art Nikpal wrote:
>
> > > I would expect the driver to unregister the controller at the start of
> > > the remove function, suspend doesn't really make sense here
>
> > It's strange - But without spi_master_suspend i have randomly stucks when i
> > try unload this module - as was written before
> > i was test it (load/unload module in loop) and for me suspend make sense
> > here
>
> > If anybody has another solution - or real problem not here - please write
> > to me the right way!
>
> As I said above unregister the controller at the start of the remove
> function.


From maxime at cerno.tech  Fri Apr 30 10:02:06 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Fri, 30 Apr 2021 11:02:06 +0200
Subject: [PATCH] rtc: sun6i: Add NVMEM provider
In-Reply-To: <20210419014549.26900-1-samuel@sholland.org>
References: <20210419014549.26900-1-samuel@sholland.org>
Message-ID: <20210430090206.lybmygrt636nysoc@gilmour>

Hi,

On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote:
> The sun6i RTC provides 32 bytes of general-purpose data registers.
> They can be used to save data in the always-on RTC power domain.
> The registers are writable via 32-bit MMIO accesses only.
> 
> Expose the region as a NVMEM provider so it can be used by userspace and
> other drivers.
> 
> Signed-off-by: Samuel Holland <samuel at sholland.org>

As far as I understood, you want to use those registers to implement
super-standby? If so, while it makes sense for the kernel to be able to
be able to write to those registers, I guess it would be a bit unwise to
allow the userspace to access 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/20210430/e8fcf1f3/attachment.sig>

From maxime at cerno.tech  Fri Apr 30 10:10:35 2021
From: maxime at cerno.tech (Maxime Ripard)
Date: Fri, 30 Apr 2021 11:10:35 +0200
Subject: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
In-Reply-To: <20210419095443.1548432e@slackpad.fritz.box>
References: <20210419025246.21722-1-samuel@sholland.org>
 <CAGb2v642Z3iH7fUWa31Rb5j+nWdZ=sXn2BYw3_dyE9P6iuL0Cg@mail.gmail.com>
 <20210419095443.1548432e@slackpad.fritz.box>
Message-ID: <20210430091035.i4zoyzb4c2l22msb@gilmour>

On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote:
> On Mon, 19 Apr 2021 11:17:19 +0800
> Chen-Yu Tsai <wens at csie.org> wrote:
> 
> Hi,
> 
> > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland <samuel at sholland.org> wrote:
> > >
> > > Dealing with the inconsistent numbering has been a major pain, and
> > > there is a solution with (as far as I can tell) no tangible downsides.
> > > So let's use it.
> 
> Thanks Samuel for sending this!
> 
> > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help
> > > when referencing the whole, unpartitioned device, like is needed for
> > > updating the bootloader and firmware. So for the use case of "write a
> > > bootloader to the SD card, regardless of where the board is currently
> > > booted from", I know of two options:
> > >   - Dig around in sysfs to find the mmc number from the MMIO address,
> > >     which means I have to know the MMIO addresses for every SoC, or
> > >   - Apply patches like these.
> > >
> > > Samuel Holland (2):
> > >   ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
> > >   arm64: dts: allwinner: Enforce consistent MMC numbering
> > >
> > >  arch/arm/boot/dts/sunxi-h3-h5.dtsi            | 6 ++++++
> > >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
> > >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++  
> > 
> > At least with Rockchip this is now done at the board level. IIRC it was
> > a request from other people to not do it at the SoC level. I don't recall
> > exactly who though.
> 
> FWIW, I am very much in favour of these patches, at a SoC level:
> The *SoC* BootROM imposes an order, by probing the first (by MMIO
> address order) MMC controller first for boot devices. IIRC that's a
> different story for Rockchip?
> And if people really don't care about the order, then having a certain
> order doesn't hurt, so we could as well use the "natural" order, as it
> was before.

This doesn't have anything to do with the BootRom though but what we
provide to the userspace? The userspace has no guarantee about the
kernel enumeration order for any bus (but UART for some reason), I'm not
really sure why MMC would be an exception. Especially since the kernel
will not try to catch up, this will be bound to be broken on a regular
basis.

And that aside, assuming that a device only has an eMMC this would
create the mmc2 device, which is completely weird and inconsistent with
how any other bus behaves.

> Also UUIDs only help if you boot with an initramfs to resolve them,
> which proves to be extra pain if you don't compile kernels on the
> device, or not inside a distribution environment.

I'm not sure what you mean? The kernel is perfectly able to resolve
them. You can also use PARTLABEL if you want something more user
friendly.

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/20210430/11d6b4ae/attachment.sig>

From hs at denx.de  Fri Apr 30 10:15:12 2021
From: hs at denx.de (Heiko Schocher)
Date: Fri, 30 Apr 2021 11:15:12 +0200
Subject: [PATCH] usb: dwc3: imx8mp: detect dwc3 child nodes with name "usb*"
Message-ID: <20210430091512.1026996-1-hs@denx.de>

commit:
d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")

renamed "dwc3 at 3*" nodes in imx8mp.dtsi to "usb at 3*"

glue layer dwc3-imx8mp.c searches for "dwc3" and so drop failure
on boot:
imx8mp-dwc3 32f10100.usb: failed to find dwc3 core child
imx8mp-dwc3: probe of 32f10100.usb failed with error 1
imx8mp-dwc3 32f10108.usb: failed to find dwc3 core child
imx8mp-dwc3: probe of 32f10108.usb failed with error 1

now. Fix this (and allow old style too)

Tested on "PHYTEC phyBOARD-Pollux i.MX8MP" board.

fixes: d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")
Signed-off-by: Heiko Schocher <hs at denx.de>
---

 drivers/usb/dwc3/dwc3-imx8mp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-imx8mp.c b/drivers/usb/dwc3/dwc3-imx8mp.c
index b13cfab89d532..eb85ddc50f7c7 100644
--- a/drivers/usb/dwc3/dwc3-imx8mp.c
+++ b/drivers/usb/dwc3/dwc3-imx8mp.c
@@ -165,7 +165,8 @@ static int dwc3_imx8mp_probe(struct platform_device *pdev)
 	if (err < 0)
 		goto disable_rpm;
 
-	dwc3_np = of_get_child_by_name(node, "dwc3");
+	dwc3_np = of_get_child_by_name(node, "usb") ? :
+		  of_get_child_by_name(node, "dwc3");
 	if (!dwc3_np) {
 		dev_err(dev, "failed to find dwc3 core child\n");
 		goto disable_rpm;
-- 
2.30.2



From u.kleine-koenig at pengutronix.de  Fri Apr 30 10:51:01 2021
From: u.kleine-koenig at pengutronix.de (Uwe =?utf-8?Q?Kleine-K=C3=B6nig?=)
Date: Fri, 30 Apr 2021 11:51:01 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <CB0VI785HYEE.3PXPB7BDOUPFC@zen.local>
References: <20210430064145.nzlcw3lpayzapnbx@pengutronix.de>
 <CB0VI785HYEE.3PXPB7BDOUPFC@zen.local>
Message-ID: <20210430095101.rjkdukf67h2k4iea@pengutronix.de>

Hello Roman,

On Fri, Apr 30, 2021 at 09:17:49AM +0200, Roman Beranek wrote:
> On Fri Apr 30, 2021 at 8:41 AM CEST, Uwe Kleine-K?nig wrote:
> > Consider the PWM is running with a period of 4s and the period just
> > started. Then you call
> >
> > pwm_apply_state(mypwm, &(struct pwm_state){
> > .period = 20,
> > .enabled = 1,
> > ...
> > })
> >
> > This doesn't result into the waiting code being run, because
> > .enabled = 1. Then immidiately after that call:
> >
> > pwm_apply_state(mypwm, &(struct pwm_state){
> > .period = 20,
> > .enabled = 0,
> > ...
> > })
> >
> > which triggers the waiting but only based on a period of 20 ns while the
> > 4s period is still active.
> 
> OK, now I see what you mean. To remedy this, the delay shall occur
> regardless of state->enabled.
> 
> In my view, this lies beneath the scope of the patch though and would be
> better served as a follow-up.

If you agree that dropping both delay and clk_disable completely is the
right thing, you address both problems and going forward with your patch
isn't sensible.

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/20210430/34e4bb9a/attachment-0001.sig>

From rppt at kernel.org  Fri Apr 30 10:51:47 2021
From: rppt at kernel.org (Mike Rapoport)
Date: Fri, 30 Apr 2021 12:51:47 +0300
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <0cb013e4-1157-f2fa-96ec-e69e60833f72@huawei.com>
References: <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
 <YIj5zcbHBHt7CC8B@kernel.org>
 <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>
 <YIpY8TXCSc7Lfa2Z@kernel.org>
 <0cb013e4-1157-f2fa-96ec-e69e60833f72@huawei.com>
Message-ID: <YIvTM5Yqit8AB4W8@kernel.org>

On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
> 
> On 2021/4/29 14:57, Mike Rapoport wrote:
> 
> > > > Do you use SPARSMEM? If yes, what is your section size?
> > > > What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
> > > Yes,
> > > 
> > > CONFIG_SPARSEMEM=y
> > > 
> > > CONFIG_SPARSEMEM_STATIC=y
> > > 
> > > CONFIG_FORCE_MAX_ZONEORDER = 11
> > > 
> > > CONFIG_PAGE_OFFSET=0xC0000000
> > > CONFIG_HAVE_ARCH_PFN_VALID=y
> > > CONFIG_HIGHMEM=y
> > > #define SECTION_SIZE_BITS    26
> > > #define MAX_PHYSADDR_BITS    32
> > > #define MAX_PHYSMEM_BITS     32
> 
> 
> With the patch,? the addr is aligned, but the panic still occurred,

Is this the same panic at move_freepages() for range [de600, de7ff]?

Do you enable CONFIG_ARM_LPAE?

> new free memory log is below,
> 
> memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c
> 
> memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
> memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
> memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
> memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
> memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
> memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
> __free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
> __free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
> __free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
> __free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
> __free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
> __free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
> __free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
> __free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
> __free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
> __free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
> __free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
> __free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
> __free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
> __free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
> __free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
> __free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
> __free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
> __free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
> __free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
> __free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
> __free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
> __free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
> __free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
> __free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
> __free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
> __free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
> __free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200

The range [de600, de7ff] 

> __free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
> __free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
> __free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
> > It seems that with SPARSEMEM we don't align the freed parts on pageblock
> > boundaries.
> > 
> > Can you try the patch below:
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index afaefa8fc6ab..1926369b52ec 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
> >   		 * due to SPARSEMEM sections which aren't present.
> >   		 */
> >   		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
> > -#else
> > +#endif
> >   		/*
> >   		 * Align down here since the VM subsystem insists that the
> >   		 * memmap entries are valid from the bank start aligned to
> >   		 * MAX_ORDER_NR_PAGES.
> >   		 */
> >   		start = round_down(start, MAX_ORDER_NR_PAGES);
> > -#endif
> >   		/*
> >   		 * If we had a previous bank, and there is a space
> > 

-- 
Sincerely yours,
Mike.


From o.rempel at pengutronix.de  Fri Apr 30 10:53:08 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Fri, 30 Apr 2021 11:53:08 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
Message-ID: <20210430095308.14465-1-o.rempel@pengutronix.de>

Some systems may need to disable selftests to reduce kernel size or for
some policy reasons. This patch provide option to disable generic selftests.

Reported-by: Geert Uytterhoeven <geert at linux-m68k.org>
Fixes: 3e1e58d64c3d ("net: add generic selftest support")
Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
---
 net/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/Kconfig b/net/Kconfig
index f5ee7c65e6b4..dac98c73fcd8 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -431,7 +431,12 @@ config SOCK_VALIDATE_XMIT
 
 config NET_SELFTESTS
 	def_tristate PHYLIB
+	prompt "Support for generic selftests"
 	depends on PHYLIB && INET
+	help
+	  These selftests are build automatically if any driver with generic
+	  selftests support is enabled. This option can be used to disable
+	  selftests to reduce kernel size.
 
 config NET_SOCK_MSG
 	bool
-- 
2.29.2



From lorenzo.pieralisi at arm.com  Fri Apr 30 10:54:17 2021
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 30 Apr 2021 10:54:17 +0100
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210429162906.32742-2-sdonthineni@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
Message-ID: <20210430095417.GA13686@lpieralisi>

[+Jason, Ben]

On Thu, Apr 29, 2021 at 11:29:05AM -0500, Shanker Donthineni wrote:
> For pass-through device assignment, the ARM64 KVM hypervisor retrieves
> the memory region properties physical address, size, and whether a
> region backed with struct page or not from VMA. The prefetchable
> attribute of a BAR region isn't visible to KVM to make an optimal
> decision for stage2 attributes.
> 
> This patch updates vma->vm_page_prot and maps with write-combine
> attribute if the associated BAR is prefetchable. For ARM64
> pgprot_writecombine() is mapped to memory-type MT_NORMAL_NC which
> has no side effects on reads and multiple writes can be combined.
> 
> Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
> ---
>  drivers/vfio/pci/vfio_pci.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

A bit of background information that may be useful:

https://lore.kernel.org/linux-pci/2b539df4c9ec703458e46da2fc879ee3b310b31c.camel at kernel.crashing.org

Lorenzo

> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 5023e23db3bc..1b734fe1dd51 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -1703,7 +1703,11 @@ static int vfio_pci_mmap(void *device_data, struct vm_area_struct *vma)
>  	}
>  
>  	vma->vm_private_data = vdev;
> -	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +	if (IS_ENABLED(CONFIG_ARM64) &&
> +	    (pci_resource_flags(pdev, index) & IORESOURCE_PREFETCH))
> +		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> +	else
> +		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>  	vma->vm_pgoff = (pci_resource_start(pdev, index) >> PAGE_SHIFT) + pgoff;
>  
>  	/*
> -- 
> 2.17.1
> 


From balbi at kernel.org  Fri Apr 30 11:03:45 2021
From: balbi at kernel.org (Felipe Balbi)
Date: Fri, 30 Apr 2021 13:03:45 +0300
Subject: [PATCH] usb: dwc3: imx8mp: detect dwc3 child nodes with name
 "usb*"
In-Reply-To: <20210430091512.1026996-1-hs@denx.de>
References: <20210430091512.1026996-1-hs@denx.de>
Message-ID: <87o8dwhywu.fsf@kernel.org>

Heiko Schocher <hs at denx.de> writes:

> commit:
> d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")
>
> renamed "dwc3 at 3*" nodes in imx8mp.dtsi to "usb at 3*"
>
> glue layer dwc3-imx8mp.c searches for "dwc3" and so drop failure
> on boot:
> imx8mp-dwc3 32f10100.usb: failed to find dwc3 core child
> imx8mp-dwc3: probe of 32f10100.usb failed with error 1
> imx8mp-dwc3 32f10108.usb: failed to find dwc3 core child
> imx8mp-dwc3: probe of 32f10108.usb failed with error 1
>
> now. Fix this (and allow old style too)
>
> Tested on "PHYTEC phyBOARD-Pollux i.MX8MP" board.
>
> fixes: d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")
> Signed-off-by: Heiko Schocher <hs at denx.de>

already sent, see https://lore.kernel.org/r/1619765836-20387-1-git-send-email-jun.li at nxp.com

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

From hs at denx.de  Fri Apr 30 11:15:00 2021
From: hs at denx.de (Heiko Schocher)
Date: Fri, 30 Apr 2021 12:15:00 +0200
Subject: [PATCH] usb: dwc3: imx8mp: detect dwc3 child nodes with name
 "usb*"
In-Reply-To: <87o8dwhywu.fsf@kernel.org>
References: <20210430091512.1026996-1-hs@denx.de> <87o8dwhywu.fsf@kernel.org>
Message-ID: <94d4d4ca-4910-99fa-18cf-478daeccc3b4@denx.de>

Hi Felipe,

On 30.04.21 12:03, Felipe Balbi wrote:
> Heiko Schocher <hs at denx.de> writes:
> 
>> commit:
>> d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")
>>
>> renamed "dwc3 at 3*" nodes in imx8mp.dtsi to "usb at 3*"
>>
>> glue layer dwc3-imx8mp.c searches for "dwc3" and so drop failure
>> on boot:
>> imx8mp-dwc3 32f10100.usb: failed to find dwc3 core child
>> imx8mp-dwc3: probe of 32f10100.usb failed with error 1
>> imx8mp-dwc3 32f10108.usb: failed to find dwc3 core child
>> imx8mp-dwc3: probe of 32f10108.usb failed with error 1
>>
>> now. Fix this (and allow old style too)
>>
>> Tested on "PHYTEC phyBOARD-Pollux i.MX8MP" board.
>>
>> fixes: d1689cd3c0f4: ("arm64: dts: imx8mp: Use the correct name for child node "snps, dwc3")
>> Signed-off-by: Heiko Schocher <hs at denx.de>
> 
> already sent, see https://lore.kernel.org/r/1619765836-20387-1-git-send-email-jun.li at nxp.com

Ah, great. Missed this patch, thanks!

So, please forget this patch.

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de


From dietmar.eggemann at arm.com  Fri Apr 30 11:42:56 2021
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Fri, 30 Apr 2021 12:42:56 +0200
Subject: [RFC PATCH v6 3/4] scheduler: scan idle cpu in cluster for tasks
 within one LLC
In-Reply-To: <185746c4d02a485ca8f3509439328b26@hisilicon.com>
References: <20210420001844.9116-1-song.bao.hua@hisilicon.com>
 <20210420001844.9116-4-song.bao.hua@hisilicon.com>
 <80f489f9-8c88-95d8-8241-f0cfd2c2ac66@arm.com>
 <b42c762a287b4360bfa3179a5c7c3e8c@hisilicon.com>
 <CAKfTPtC51eO2mAuW6mHQ-SdznAtfDL3D4UOs4HmnXaPOOCN_cA@mail.gmail.com>
 <8b5277d9-e367-566d-6bd1-44ac78d21d3f@arm.com>
 <185746c4d02a485ca8f3509439328b26@hisilicon.com>
Message-ID: <d31a65af-d1d5-5fd1-276c-d2318cdba078@arm.com>

On 29/04/2021 00:41, Song Bao Hua (Barry Song) wrote:
> 
> 
>> -----Original Message-----
>> From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]

[...]

>>>>> From: Dietmar Eggemann [mailto:dietmar.eggemann at arm.com]
>>
>> [...]
>>
>>>>> On 20/04/2021 02:18, Barry Song wrote:

[...]

> Though we will never go to slow path, wake_wide() will affect want_affine,
> so eventually affect the "new_cpu"?

yes.

> 
> 	for_each_domain(cpu, tmp) {
> 		/*
> 		 * If both 'cpu' and 'prev_cpu' are part of this domain,
> 		 * cpu is a valid SD_WAKE_AFFINE target.
> 		 */
> 		if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
> 		    cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
> 			if (cpu != prev_cpu)
> 				new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
> 
> 			sd = NULL; /* Prefer wake_affine over balance flags */
> 			break;
> 		}
> 
> 		if (tmp->flags & sd_flag)
> 			sd = tmp;
> 		else if (!want_affine)
> 			break;
> 	}
> 
> If wake_affine is false, the above won't execute, new_cpu(target) will
> always be "prev_cpu"? so when task size > cluster size in wake_wide(),
> this means we won't pull the wakee to the cluster of waker? It seems
> sensible.

What is `task size` here?

The criterion is `!(slave < factor || master < slave * factor)` or
`slave >= factor && master >= slave * factor` to wake wide.

I see that since you effectively change the sched domain size from LLC
to CLUSTER (e.g. 24->6) for wakeups with cpu and prev_cpu sharing LLC
(hence the `numactl -N 0` in your workload), wake_wide() has to take
CLUSTER size into consideration.

I was wondering if you saw wake_wide() returning 1 with your use cases:

numactl -N 0 /usr/lib/lmbench/bin/stream -P [6,12] -M 1024M -N 5


From andre.przywara at arm.com  Fri Apr 30 11:55:45 2021
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 30 Apr 2021 11:55:45 +0100
Subject: [PATCH 0/2] sunxi: Enforce consistent MMC numbering
In-Reply-To: <20210430091035.i4zoyzb4c2l22msb@gilmour>
References: <20210419025246.21722-1-samuel@sholland.org>
 <CAGb2v642Z3iH7fUWa31Rb5j+nWdZ=sXn2BYw3_dyE9P6iuL0Cg@mail.gmail.com>
 <20210419095443.1548432e@slackpad.fritz.box>
 <20210430091035.i4zoyzb4c2l22msb@gilmour>
Message-ID: <20210430115545.6a45d1dc@slackpad.fritz.box>

On Fri, 30 Apr 2021 11:10:35 +0200
Maxime Ripard <maxime at cerno.tech> wrote:

Hi Maxime,

> On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote:
> > On Mon, 19 Apr 2021 11:17:19 +0800
> > Chen-Yu Tsai <wens at csie.org> wrote:
> > 
> > Hi,
> >   
> > > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland <samuel at sholland.org> wrote:  
> > > >
> > > > Dealing with the inconsistent numbering has been a major pain, and
> > > > there is a solution with (as far as I can tell) no tangible downsides.
> > > > So let's use it.  
> > 
> > Thanks Samuel for sending this!
> >   
> > > > Yes, I know the kernel supports UUIDs for root=. But UUIDs do not help
> > > > when referencing the whole, unpartitioned device, like is needed for
> > > > updating the bootloader and firmware. So for the use case of "write a
> > > > bootloader to the SD card, regardless of where the board is currently
> > > > booted from", I know of two options:
> > > >   - Dig around in sysfs to find the mmc number from the MMIO address,
> > > >     which means I have to know the MMIO addresses for every SoC, or
> > > >   - Apply patches like these.
> > > >
> > > > Samuel Holland (2):
> > > >   ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering
> > > >   arm64: dts: allwinner: Enforce consistent MMC numbering
> > > >
> > > >  arch/arm/boot/dts/sunxi-h3-h5.dtsi            | 6 ++++++
> > > >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
> > > >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 6 ++++++    
> > > 
> > > At least with Rockchip this is now done at the board level. IIRC it was
> > > a request from other people to not do it at the SoC level. I don't recall
> > > exactly who though.  
> > 
> > FWIW, I am very much in favour of these patches, at a SoC level:
> > The *SoC* BootROM imposes an order, by probing the first (by MMIO
> > address order) MMC controller first for boot devices. IIRC that's a
> > different story for Rockchip?
> > And if people really don't care about the order, then having a certain
> > order doesn't hurt, so we could as well use the "natural" order, as it
> > was before.  
> 
> This doesn't have anything to do with the BootRom though but what we
> provide to the userspace?

My argument was that there is a "natural" order, not only by the
location in the MMIO space, but on a more logical level: the "first" SD
controller is first checked by the BootROM, so the SoC puts a "number
0" tag on this particular one. This is just because I heard the
(reasonable) argument that location in MMIO space should not be
significant, and deriving an order from that is arbitrary.

> The userspace has no guarantee about the
> kernel enumeration order for any bus (but UART for some reason), I'm not
> really sure why MMC would be an exception.

Userspace is one thing, but arguably there are ways to find the
partition you are looking for, because you have all the kernel *and*
userlevel tools at hand. The question is whether this needs to be overly
complicated and harder for the user.
But the other, more pressing problem is the kernel-only code in
init/do_mounts.c, which has very limited means to find a
certain partition (see below).

> Especially since the kernel will not try to catch up, this will be
> bound to be broken on a regular basis.

What do you mean with "will not try to catch up"? Do you mean there
might be other kernel changes that spoil the numbering again, in the
future?

> And that aside, assuming that a device only has an eMMC this would
> create the mmc2 device, which is completely weird and inconsistent
> with how any other bus behaves.

You have a point there, but I don't see how this would be a problem. I
think one advantage is *consistent* numbering across reboots, so it
will always be mmc2, even if you add a WiFi chip later (some boards
have that as an option). Also those SD-card less system could surely
override the labels in their board .dts files?

> > Also UUIDs only help if you boot with an initramfs to resolve them,
> > which proves to be extra pain if you don't compile kernels on the
> > device, or not inside a distribution environment.  
> 
> I'm not sure what you mean? The kernel is perfectly able to resolve
> them. You can also use PARTLABEL if you want something more user
> friendly.

init/do_mounts.c supports PARTUUID only, but most people/distributions
use UUID, which is filesystem metadata, so not easily accessible for
the kernel early and on a partition level only. And IIRC PARTLABEL is
only available on GPT partitioned disks.
Also PARTUUID is set at partition time, so a user formatting her own SD
card (or just changing the partition table) will have a unique PARTUUID,
and it cannot be used from within a filesystem image or
prefabricated boot script to reference its own partition
(in /etc/fstab).
And in general UUIDs are not very human friendly, so their main domain
is to be handled by code. I definitely don't memorise a single one of
them, but I do remember root=/dev/mmcblk0p2.

I find it *very* annoying to load my development kernel over TFTP, then
booting them with the rootfs from SD card or eMMC, and seeing it fail
about 50% of the time, because the numbering is off.
 
Cheers,
Andre


From jbx6244 at gmail.com  Fri Apr 30 11:58:30 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 30 Apr 2021 12:58:30 +0200
Subject: [RESEND PATCH v4 07/10] dt-bindings: soc: rockchip: Convert
 grf.txt to YAML
In-Reply-To: <20210430005708.1821-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210430005708.1821-1-cl@rock-chips.com>
Message-ID: <953e4240-77ea-ce1c-00a5-0625111ab2cd@gmail.com>

Hi Liang,

On 4/30/21 2:57 AM, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> Current dts files with 'grf' nodes are manually verified. In order to
> automate this process grf.txt has to be converted to YAML.
> 
> Add new descriptions for:
> "rockchip,rk3568-grf", "syscon", "simple-mfd"
> "rockchip,rk3568-pmugrf", "syscon", "simple-mfd"

"rockchip,rv1108-pmugrf", "syscon"

> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/soc/rockchip/grf.txt  | 61 -------------------
>  .../devicetree/bindings/soc/rockchip/grf.yaml | 60 ++++++++++++++++++
>  2 files changed, 60 insertions(+), 61 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> deleted file mode 100644
> index f96511aa3897..000000000000
> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> +++ /dev/null
> @@ -1,61 +0,0 @@
> -* Rockchip General Register Files (GRF)
> -
> -The general register file will be used to do static set by software, which
> -is composed of many registers for system control.
> -
> -From RK3368 SoCs, the GRF is divided into two sections,
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- PMUGRF, used for always on system
> -
> -On RK3328 SoCs, the GRF adds a section for USB2PHYGRF,
> -
> -ON RK3308 SoC, the GRF is divided into four sections:
> -- GRF, used for general non-secure system,
> -- SGRF, used for general secure system,
> -- DETECTGRF, used for audio codec system,
> -- COREGRF, used for pvtm,
> -
> -Required Properties:
> -
> -- compatible: GRF should be one of the following:
> -   - "rockchip,px30-grf", "syscon": for px30
> -   - "rockchip,rk3036-grf", "syscon": for rk3036
> -   - "rockchip,rk3066-grf", "syscon": for rk3066
> -   - "rockchip,rk3188-grf", "syscon": for rk3188
> -   - "rockchip,rk3228-grf", "syscon": for rk3228
> -   - "rockchip,rk3288-grf", "syscon": for rk3288
> -   - "rockchip,rk3308-grf", "syscon": for rk3308
> -   - "rockchip,rk3328-grf", "syscon": for rk3328
> -   - "rockchip,rk3368-grf", "syscon": for rk3368
> -   - "rockchip,rk3399-grf", "syscon": for rk3399
> -   - "rockchip,rv1108-grf", "syscon": for rv1108
> -- compatible: DETECTGRF should be one of the following:
> -   - "rockchip,rk3308-detect-grf", "syscon": for rk3308
> -- compatilbe: COREGRF should be one of the following:
> -   - "rockchip,rk3308-core-grf", "syscon": for rk3308
> -- compatible: PMUGRF should be one of the following:
> -   - "rockchip,px30-pmugrf", "syscon": for px30
> -   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> -   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> -- compatible: SGRF should be one of the following:
> -   - "rockchip,rk3288-sgrf", "syscon": for rk3288
> -- compatible: USB2PHYGRF should be one of the following:
> -   - "rockchip,px30-usb2phy-grf", "syscon": for px30
> -   - "rockchip,rk3328-usb2phy-grf", "syscon": for rk3328
> -- compatible: USBGRF should be one of the following:
> -   - "rockchip,rv1108-usbgrf", "syscon": for rv1108
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> -
> -Example: GRF and PMUGRF of RK3399 SoCs
> -
> -	pmugrf: syscon at ff320000 {
> -		compatible = "rockchip,rk3399-pmugrf", "syscon";
> -		reg = <0x0 0xff320000 0x0 0x1000>;
> -	};
> -
> -	grf: syscon at ff770000 {
> -		compatible = "rockchip,rk3399-grf", "syscon";
> -		reg = <0x0 0xff770000 0x0 0x10000>;
> -	};
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> new file mode 100644
> index 000000000000..21a67b9ae59c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/rockchip/grf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rockchip General Register Files
> +
> +maintainers:
> +  - Heiko Stuebner <heiko at sntech.de>
> +

syscon.yaml uses select if compatible contains "syscon", so use select
here too ??

> +properties:

> +  compatible:
> +    items:

When there are no other combinations then with syscon and simple-mfd
then there's no need for "oneOf", but a look in the build log shows
there are 2 (3) exceptions:

#cat build-dtbs-1471909.log | grep short
rv1108-elgin-r1.dt.yaml: syscon at 202a0000: compatible:
['rockchip,rv1108-usbgrf', 'syscon'] is too short
rk3288-evb-act8846.dt.yaml: syscon at ff740000: compatible:
['rockchip,rk3288-sgrf', 'syscon'] is too short

https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210430005708.1821-1-cl at rock-chips.com/

===


	pmugrf: syscon at 20060000 {

		compatible = "rockchip,rv1108-pmugrf", "syscon";

rockchip,rv1108-pmugrf was never added to a document.

		reg = <0x20060000 0x1000>;
	};

	usbgrf: syscon at 202a0000 {
		compatible = "rockchip,rv1108-usbgrf", "syscon";
		reg = <0x202a0000 0x1000>;
	};
===

  compatible:
    oneOf:
      - items:
          - enum:
              - rockchip,rk3288-sgrf
===
              - rockchip,rv1108-pmugrf
===
              - rockchip,rv1108-usbgrf
          - const: syscon
      - items:
          - enum:
              - rockchip,px30-grf
              - rockchip,px30-pmugrf
              - rockchip,px30-usb2phy-grf
              - rockchip,rk3036-grf
              - rockchip,rk3066-grf
              - rockchip,rk3188-grf
              - rockchip,rk3228-grf
              - rockchip,rk3288-grf
              - rockchip,rk3308-core-grf
              - rockchip,rk3308-detect-grf
              - rockchip,rk3308-grf
              - rockchip,rk3328-grf
              - rockchip,rk3328-usb2phy-grf
              - rockchip,rk3368-grf
              - rockchip,rk3368-pmugrf
              - rockchip,rk3399-grf
              - rockchip,rk3399-pmugrf
              - rockchip,rk3568-grf
              - rockchip,rk3568-pmugrf
              - rockchip,rv1108-grf
          - const: syscon
          - const: simple-mfd

> +      - enum:
> +          - rockchip,px30-grf
> +          - rockchip,px30-pmugrf
> +          - rockchip,px30-usb2phy-grf
> +          - rockchip,rk3036-grf
> +          - rockchip,rk3066-grf
> +          - rockchip,rk3188-grf
> +          - rockchip,rk3228-grf
> +          - rockchip,rk3288-grf
> +          - rockchip,rk3288-sgrf
> +          - rockchip,rk3308-core-grf
> +          - rockchip,rk3308-detect-grf
> +          - rockchip,rk3308-grf
> +          - rockchip,rk3328-grf
> +          - rockchip,rk3328-usb2phy-grf
> +          - rockchip,rk3368-grf
> +          - rockchip,rk3368-pmugrf
> +          - rockchip,rk3399-grf
> +          - rockchip,rk3399-pmugrf
> +          - rockchip,rk3568-grf
> +          - rockchip,rk3568-pmugrf
> +          - rockchip,rv1108-grf
> +          - rockchip,rv1108-usbgrf
> +      - const: syscon
> +      - const: simple-mfd

> +
> +  reg:> +    maxItems: 1

"#address-cells":
  const: 1

"#size-cells":
  const: 1

rk3228-evb.dt.yaml: syscon at 11000000: '#address-cells', '#size-cells',
'io-domains', 'usb2-phy at 760', 'usb2-phy at 800' do not match any of the
regexes: 'pinctrl-[0-9]+'

> +
> +required:
> +  - compatible
> +  - reg
> +

> +additionalProperties: false

additionalProperties: true

> +
> +examples:
> +  - |
> +    pmugrf: syscon at ff320000 {
> +       compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
> +       reg = <0xff320000 0x1000>;
> +    };
> +
> +    grf: syscon at ff770000 {
> +       compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> +       reg = <0xff770000 0x10000>;
> +    };
> 


From broonie at kernel.org  Fri Apr 30 11:59:10 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 30 Apr 2021 11:59:10 +0100
Subject: [PATCH] SPI: meson-spifc add missed calls to remove function
In-Reply-To: <CAKaHn9JM-KEiz3_Btsz8_fr7hcZ2Sm8B64VyLvgpvKK-NKco3w@mail.gmail.com>
References: <20210423034247.992052-1-art@khadas.com>
 <20210423114735.GA5507@sirena.org.uk>
 <CAKaHn9+d5crmmG-aKyLuvyxk+A7aC9qqfX_3wuMXm50pg+pZ4w@mail.gmail.com>
 <20210426115645.GB4590@sirena.org.uk>
 <CAKaHn9JM-KEiz3_Btsz8_fr7hcZ2Sm8B64VyLvgpvKK-NKco3w@mail.gmail.com>
Message-ID: <20210430105910.GA5981@sirena.org.uk>

On Fri, Apr 30, 2021 at 04:49:35PM +0800, Art Nikpal wrote:

> Yep! but

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> if i try call spi_master_put(master) or spi_unregister_controller(master);
> it's made Segmentation fault for me
> 
> what's wrong - may be somebody can help me

Probably something is referencing the controller afer it was freed, I do
notice that the current version of the driver uses devm_ to register the
controller so you'd end up with a double free unless you either use devm_
when freeing or change to a normal registration.
-------------- 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/20210430/d4b84f0e/attachment.sig>

From wangkefeng.wang at huawei.com  Fri Apr 30 12:24:37 2021
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Fri, 30 Apr 2021 19:24:37 +0800
Subject: arm32: panic in move_freepages (Was [PATCH v2 0/4] arm64: drop
 pfn_valid_within() and simplify pfn_valid())
In-Reply-To: <YIvTM5Yqit8AB4W8@kernel.org>
References: <YIUYG8N9T3/C/tSG@kernel.org>
 <52f7d03b-7219-46bc-c62d-b976bc31ebd5@huawei.com>
 <YIZNq5HMfJ1rWytv@kernel.org>
 <2d879629-3059-fd42-428f-4b7c2a73d698@huawei.com>
 <YIet5X7lgygD9rpZ@kernel.org>
 <259d14df-a713-72e7-4ccb-c06a8ee31e13@huawei.com>
 <YIj5zcbHBHt7CC8B@kernel.org>
 <6ad2956c-70ae-c423-ed7d-88e94c88060f@huawei.com>
 <YIpY8TXCSc7Lfa2Z@kernel.org>
 <0cb013e4-1157-f2fa-96ec-e69e60833f72@huawei.com>
 <YIvTM5Yqit8AB4W8@kernel.org>
Message-ID: <ca5b00bd-1312-0c69-ab69-a1bd749f51b6@huawei.com>



On 2021/4/30 17:51, Mike Rapoport wrote:
> On Thu, Apr 29, 2021 at 06:22:55PM +0800, Kefeng Wang wrote:
>>
>> On 2021/4/29 14:57, Mike Rapoport wrote:
>>
>>>>> Do you use SPARSMEM? If yes, what is your section size?
>>>>> What is the value if CONFIG_FORCE_MAX_ZONEORDER in your configuration?
>>>> Yes,
>>>>
>>>> CONFIG_SPARSEMEM=y
>>>>
>>>> CONFIG_SPARSEMEM_STATIC=y
>>>>
>>>> CONFIG_FORCE_MAX_ZONEORDER = 11
>>>>
>>>> CONFIG_PAGE_OFFSET=0xC0000000
>>>> CONFIG_HAVE_ARCH_PFN_VALID=y
>>>> CONFIG_HIGHMEM=y
>>>> #define SECTION_SIZE_BITS    26
>>>> #define MAX_PHYSADDR_BITS    32
>>>> #define MAX_PHYSMEM_BITS     32
>>
>>
>> With the patch,? the addr is aligned, but the panic still occurred,
> 
> Is this the same panic at move_freepages() for range [de600, de7ff]?
> 
> Do you enable CONFIG_ARM_LPAE?

no, the CONFIG_ARM_LPAE is not set, and yes with same panic at 
move_freepages at

start_pfn/end_pfn [de600, de7ff], [de600000, de7ff000] :  pfn =de600, 
page =ef3cc000, page-flags = ffffffff,  pfn2phy = de600000



> 
>> new free memory log is below,
>>
>> memblock_free: [0xaf430000-0xaf44ffff] mem_init+0x158/0x23c
>>
>> memblock_free: [0xaf510000-0xaf53ffff] mem_init+0x158/0x23c
>> memblock_free: [0xaf560000-0xaf57ffff] mem_init+0x158/0x23c
>> memblock_free: [0xafd98000-0xafdc7fff] mem_init+0x158/0x23c
>> memblock_free: [0xafdd8000-0xafdfffff] mem_init+0x158/0x23c
>> memblock_free: [0xafe18000-0xafe7ffff] mem_init+0x158/0x23c
>> memblock_free: [0xafee0000-0xafefffff] mem_init+0x158/0x23c
>> __free_memory_core, range: 0x80a03000 - 0x80a04000, pfn: 80a03 - 80a04
>> __free_memory_core, range: 0x80a08000 - 0x80b00000, pfn: 80a08 - 80b00
>> __free_memory_core, range: 0x812e8058 - 0x83000000, pfn: 812e9 - 83000
>> __free_memory_core, range: 0x85000000 - 0x85600000, pfn: 85000 - 85600
>> __free_memory_core, range: 0x86a00000 - 0x87e00000, pfn: 86a00 - 87e00
>> __free_memory_core, range: 0x8bd00000 - 0x8c500000, pfn: 8bd00 - 8c500
>> __free_memory_core, range: 0x8e300000 - 0x8ed00000, pfn: 8e300 - 8ed00
>> __free_memory_core, range: 0x90d00000 - 0xaf2c0000, pfn: 90d00 - af2c0
>> __free_memory_core, range: 0xaf430000 - 0xaf450000, pfn: af430 - af450
>> __free_memory_core, range: 0xaf510000 - 0xaf540000, pfn: af510 - af540
>> __free_memory_core, range: 0xaf560000 - 0xaf580000, pfn: af560 - af580
>> __free_memory_core, range: 0xafd98000 - 0xafdc8000, pfn: afd98 - afdc8
>> __free_memory_core, range: 0xafdd8000 - 0xafe00000, pfn: afdd8 - afe00
>> __free_memory_core, range: 0xafe18000 - 0xafe80000, pfn: afe18 - afe80
>> __free_memory_core, range: 0xafee0000 - 0xaff00000, pfn: afee0 - aff00
>> __free_memory_core, range: 0xaff80000 - 0xaff8d000, pfn: aff80 - aff8d
>> __free_memory_core, range: 0xafff2000 - 0xafff4580, pfn: afff2 - afff4
>> __free_memory_core, range: 0xafffe000 - 0xafffe0e0, pfn: afffe - afffe
>> __free_memory_core, range: 0xafffe4fc - 0xafffe500, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe6e4 - 0xafffe700, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe8dc - 0xafffe8e0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe970 - 0xafffe980, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe990 - 0xafffe9a0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffe9a4 - 0xafffe9c0, pfn: affff - afffe
>> __free_memory_core, range: 0xafffeb54 - 0xafffeb60, pfn: affff - afffe
>> __free_memory_core, range: 0xafffecf4 - 0xafffed00, pfn: affff - afffe
>> __free_memory_core, range: 0xafffefc4 - 0xafffefd8, pfn: affff - afffe
>> __free_memory_core, range: 0xb0200000 - 0xc0000000, pfn: b0200 - b0200
>> __free_memory_core, range: 0xcc000000 - 0xdca00000, pfn: cc000 - b0200
>> __free_memory_core, range: 0xde700000 - 0xdea00000, pfn: de700 - b0200
> 
> The range [de600, de7ff]
the __free_memory_core will check the start pfn and end pfn,

  if (start_pfn >= end_pfn)
          return 0;

  __free_pages_memory(start_pfn, end_pfn);
so the memory will not be freed to buddy, confused...
> 
>> __free_memory_core, range: 0xe0800000 - 0xe0c00000, pfn: e0800 - b0200
>> __free_memory_core, range: 0xf4b00000 - 0xf7000000, pfn: f4b00 - b0200
>> __free_memory_core, range: 0xfda00000 - 0xffffffff, pfn: fda00 - b0200
>>> It seems that with SPARSEMEM we don't align the freed parts on pageblock
>>> boundaries.
>>>
>>> Can you try the patch below:
>>>
>>> diff --git a/mm/memblock.c b/mm/memblock.c
>>> index afaefa8fc6ab..1926369b52ec 100644
>>> --- a/mm/memblock.c
>>> +++ b/mm/memblock.c
>>> @@ -1941,14 +1941,13 @@ static void __init free_unused_memmap(void)
>>>    		 * due to SPARSEMEM sections which aren't present.
>>>    		 */
>>>    		start = min(start, ALIGN(prev_end, PAGES_PER_SECTION));
>>> -#else
>>> +#endif
>>>    		/*
>>>    		 * Align down here since the VM subsystem insists that the
>>>    		 * memmap entries are valid from the bank start aligned to
>>>    		 * MAX_ORDER_NR_PAGES.
>>>    		 */
>>>    		start = round_down(start, MAX_ORDER_NR_PAGES);
>>> -#endif
>>>    		/*
>>>    		 * If we had a previous bank, and there is a space
>>>
> 


From sdonthineni at nvidia.com  Fri Apr 30 12:25:08 2021
From: sdonthineni at nvidia.com (Shanker R Donthineni)
Date: Fri, 30 Apr 2021 06:25:08 -0500
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210429134659.321a5c3c@redhat.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
Message-ID: <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>

Hi Alex

On 4/29/21 2:46 PM, Alex Williamson wrote:
> If an alignment fault is fixed by configuring a WC mapping, doesn't
> that suggest that the driver performed an unaligned access itself and
> is relying on write combining by the processor to correct that error?
> That's wrong.  Fix the driver or please offer another explanation of
> how the WC mapping resolves this.  I suspect you could enable tracing
> in QEMU, disable MMIO mmaps on the vfio-pci device and find the invalid
> access.
>
>> We've two concerns here:
>>    - Performance impacts for pass-through devices.
>>    - The definition of ioremap_wc() function doesn't match the host
>> kernel on ARM64
> Performance I can understand, but I think you're also using it to mask
> a driver bug which should be resolved first.  Thank

We?ve already instrumented the driver code and found the code path for the unaligned
accesses. We?ll fix this issue if it?s not following WC semantics.

Fixing the performance concern will be under KVM stage-2 page-table control. We're
looking for a guidance/solution for updating stage-2? PTE based on PCI-BAR attribute.




From catalin.marinas at arm.com  Fri Apr 30 12:46:32 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 12:46:32 +0100
Subject: About add an A64FX cache control function into resctrl
In-Reply-To: <49cdd0b707194148915e2efe2ab5d707@intel.com>
References: <OSAPR01MB214600C7923AEF7C35B02E648B739@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <OSAPR01MB214657641D532FB8D112DD528B479@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <bb0967c0-5b88-c6c2-0242-1e3928189a04@intel.com>
 <OSAPR01MB2146D42FC04779268BA231878B409@OSAPR01MB2146.jpnprd01.prod.outlook.com>
 <14ddf86b-89e1-ba26-b684-f3d5d5f8ade7@intel.com>
 <49cdd0b707194148915e2efe2ab5d707@intel.com>
Message-ID: <YIvuGLmcJcw2jLT7@arm.com>

On Thu, Apr 29, 2021 at 05:50:20PM +0000, Luck, Tony wrote:
> >>>> [Sector cache function]
> >>>> The sector cache function split cache into multiple sectors and
> >>>> control them separately. It is implemented on the L1D cache and
> >>>> L2 cache in the A64FX processor and can be controlled individually
> >>>> for L1D cache and L2 cache. A64FX has no L3 cache. Each L1D cache and
> >>>> L2 cache has 4 sectors. Which L1D sector is used is specified by the
> >>>> value of [57:56] bits of address, how many ways of sector are
> >>>> specified by the value of register (IMP_SCCR_L1_EL0).
> >>>> Which L2 sector is used is specified by the value of [56] bits of
> >>>> address, and how many ways of sector are specified by value of
> >>>> register (IMP_SCCR_ASSIGN_EL1, IMP_SCCR_SET0_L2_EL1,
> >>>> IMP_SCCR_SET1_L2_EL1).
> 
> Are A64FX binaries position independent?  I.e. could the OS reassign
> a running task to a different sector by remapping it to different virtual
> addresses during a context switch?

Arm64 supports a maximum of 52-bit of virtual or physical addresses. The
maximum the MMU would produce would be a 52-bit output address. I
presume bits 56, 57 of the address bus are used for some cache affinity
(sector selection) but they don't influence the memory addressing, nor
could the MMU set them.

-- 
Catalin


From maz at kernel.org  Fri Apr 30 12:47:43 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 30 Apr 2021 12:47:43 +0100
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
Message-ID: <87czucngdc.wl-maz@kernel.org>

Hi Shanker,

On Fri, 30 Apr 2021 12:25:08 +0100,
Shanker R Donthineni <sdonthineni at nvidia.com> wrote:
> 
> Hi Alex
> 
> On 4/29/21 2:46 PM, Alex Williamson wrote:
> > If an alignment fault is fixed by configuring a WC mapping, doesn't
> > that suggest that the driver performed an unaligned access itself and
> > is relying on write combining by the processor to correct that error?
> > That's wrong.  Fix the driver or please offer another explanation of
> > how the WC mapping resolves this.  I suspect you could enable tracing
> > in QEMU, disable MMIO mmaps on the vfio-pci device and find the invalid
> > access.
> >
> >> We've two concerns here:
> >>    - Performance impacts for pass-through devices.
> >>    - The definition of ioremap_wc() function doesn't match the host
> >> kernel on ARM64
> > Performance I can understand, but I think you're also using it to mask
> > a driver bug which should be resolved first.  Thank
> 
> We?ve already instrumented the driver code and found the code path
> for the unaligned accesses. We?ll fix this issue if it?s not
> following WC semantics.
> 
> Fixing the performance concern will be under KVM stage-2 page-table
> control. We're looking for a guidance/solution for updating stage-2?
> PTE based on PCI-BAR attribute.

Before we start discussing the *how*, I'd like to clearly understand
what *arm64* memory attributes you are relying on. We already have
established that the unaligned access was a bug, which was the biggest
argument in favour of NORMAL_NC. What are the other requirements?

Thanks,

	M.

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


From penguin-kernel at i-love.sakura.ne.jp  Fri Apr 30 12:48:02 2021
From: penguin-kernel at i-love.sakura.ne.jp (Tetsuo Handa)
Date: Fri, 30 Apr 2021 20:48:02 +0900
Subject: [PATCH] rtnetlink: add rtnl_lock debug log
In-Reply-To: <20210429070237.3012-1-rocco.yue@mediatek.com>
References: <20210429070237.3012-1-rocco.yue@mediatek.com>
Message-ID: <27fa19c9-81b2-3604-033c-b7fe5d14b620@i-love.sakura.ne.jp>

On 2021/04/29 16:02, Rocco Yue wrote:
> +static void rtnl_print_btrace(struct timer_list *unused)
> +{
> +	pr_info("----------- %s start -----------\n", __func__);
> +	pr_info("%s[%d][%c] hold rtnl_lock more than 2 sec, start time: %llu\n",
> +		rtnl_instance.task->comm,
> +		rtnl_instance.pid,
> +		task_state_to_char(rtnl_instance.task),
> +		rtnl_instance.start_time);
> +	stack_trace_print(rtnl_instance.addrs, rtnl_instance.nr_entries, 0);

Do we want to print same traces every 2 seconds? 

Since it is possible to stall for e.g. 30 seconds, printing either only upon
first call to rtnl_print_btrace() for each stalling duration or only upon
end of stalling duration (i.e. from rtnl_relase_btrace()) is better?

> +	show_stack(rtnl_instance.task, NULL, KERN_DEBUG);

Why KERN_DEBUG ?

If you retrieve the output via dmesg, KERN_DEBUG would be fine.
But for syzkaller (which counts on printk() messages being printed to
consoles), KERN_INFO (or default) is expected.

> +	pr_info("------------ %s end -----------\n", __func__);
> +}
> +
> +static void rtnl_relase_btrace(void)
> +{
> +	rtnl_instance.end_time = sched_clock();
> +

You should del_timer_sync() here than

> +	if (rtnl_instance.end_time - rtnl_instance.start_time > 2000000000ULL) {
> +		pr_info("rtnl_lock is held by [%d] from [%llu] to [%llu]\n",
> +			rtnl_instance.pid,
> +			rtnl_instance.start_time,
> +			rtnl_instance.end_time);
> +	}
> +
> +	del_timer(&rtnl_chk_timer);

here in order to make sure that end message is printed only after
rtnl_print_btrace() messages are printed.

> +}
> +#endif
> +



From mark.rutland at arm.com  Fri Apr 30 12:49:35 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 30 Apr 2021 12:49:35 +0100
Subject: [PATCH] arm64: cpufeatures: use min and max
In-Reply-To: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
References: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
Message-ID: <20210430114935.GB53304@C02TD0UTHF1T.local>

On Thu, Apr 29, 2021 at 10:50:46PM +0200, Julia Lawall wrote:
> From: kernel test robot <lkp at intel.com>
> 
> Use min and max to make the effect more clear.
> 
> Generated by: scripts/coccinelle/misc/minmax.cocci
> 
> Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
> CC: Denis Efremov <efremov at linux.com>
> Reported-by: kernel test robot <lkp at intel.com>
> Signed-off-by: kernel test robot <lkp at intel.com>
> Signed-off-by: Julia Lawall <julia.lawall at inria.fr>

This looks like a nice cleanup, but it's not clear to me what the
intended inclusion path for this is, and to avoid fragility I think we
must include <linux/minmax.h> explicitly.

With that:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Thanks,
Mark.

> ---
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux.git for-5.12
> head:   44e793b89bcfe586730f4c6ce3c66174dc07cb37
> commit: 8636e3295ce33515c50ef728f0ff3800d97f9f44 [1/5] coccinelle: misc: add minmax script
> :::::: branch date: 6 days ago
> :::::: commit date: 6 weeks ago
> 
>  cpufeature.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -695,14 +695,14 @@ static s64 arm64_ftr_safe_value(const st
>  		ret = ftrp->safe_val;
>  		break;
>  	case FTR_LOWER_SAFE:
> -		ret = new < cur ? new : cur;
> +		ret = min(new, cur);
>  		break;
>  	case FTR_HIGHER_OR_ZERO_SAFE:
>  		if (!cur || !new)
>  			break;
>  		fallthrough;
>  	case FTR_HIGHER_SAFE:
> -		ret = new > cur ? new : cur;
> +		ret = max(new, cur);
>  		break;
>  	default:
>  		BUG();


From laurent.pinchart at ideasonboard.com  Fri Apr 30 13:18:52 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 30 Apr 2021 15:18:52 +0300
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210430065134.jwscxlv3sydo4zgy@pengutronix.de>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>
 <20210430065134.jwscxlv3sydo4zgy@pengutronix.de>
Message-ID: <YIv1rMFZuv7z4R8a@pendragon.ideasonboard.com>

Hi Marco,

On Fri, Apr 30, 2021 at 08:51:34AM +0200, Marco Felsch wrote:
> On 21-04-30 01:14, Laurent Pinchart wrote:
> > On Thu, Apr 29, 2021 at 09:49:03AM +0200, Marco Felsch wrote:
> > > On 21-04-29 04:51, Laurent Pinchart wrote:
> > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:
> > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > > with the interleaved IR pixels looks like:
> > > > > 
> > > > >         |  G |  R |  G |  B | ...
> > > > >         +----+----+----+----+---
> > > > >         | IR |  G | IR |  G | ...
> > > > >         +----+----+----+----+---
> > > > >         |  G |  B |  G |  R | ...
> > > > >         +----+----+----+----+---
> > > > >         | IR |  G | IR |  G | ...
> > > > >         +----+----+----+----+---
> > > > >         | .. | .. | .. | .. | ..
> > > > > 
> > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf
> > > > 
> > > > I think we're reaching a limit of the media bus codes model here, due to
> > > > a historical mistake. The four possible Bayer patterns, times the
> > > > different number of bits per pixel, creates a lot of media bus codes,
> > > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > > have to support them all.
> > > 
> > > That's correct but it is not bayer related. Currently it is what it is,
> > > if a new code is added it must be propagated through all the involved
> > > subdevs. On the other hand I wouldn't say that it is better to support
> > > new codes per default for all drivers. Since this would add a lot of
> > > untested code paths.
> > 
> > It's not an issue limited to Bayer patterns, but they make the issue
> > worse given the number of possible combinations (think about adding DPCM
> > and ALAW compression on top of that...).
> 
> You're right and again this will apply to all mbus formats...
> 
> > > > This is already painful, and if we had a
> > > > non-Bayer pattern such as this one,
> > > 
> > > That's not exactly true since it is a bayer pattern but instead of using
> > > 4x4 it uses 8x8 and it as some special pixels.
> > > 
> > > > we'll open the door to an explosion
> > > > of the number of media bus codes (imagine all the different possible
> > > > arrangements of this pattern, for instance if you enable horizontal
> > > > and/or vertical flipping on the sensor). All drivers would need to be
> > > > updated to support these new bus codes, and this really kills the
> > > > current model.
> > > 
> > > Yep, I know what you mean but as I said above I think that adding it
> > > explicite is the better abbroach since it involves somone who add _and_
> > > test the new code on the particular platform.
> > > 
> > > > The historical mistake was to tie the Bayer pattern with the media bus
> > > > code. We should really have specified raw 8/10/12/14/16 media bus codes,
> > > > and conveyed the pattern separately. Most IP cores in the pipeline don't
> > > > need to care about the pattern at all, and those who do (that's mostly
> > > > ISPs) could be programmed explicitly by userspace as long as we have an
> > > > API to retrieve the pattern from the sensor. I believe it's time to bite
> > > > the bullet and go in that direction. I'm sorry for this case of yak
> > > > shaving, but it really wouldn't be manageable anymore :-(
> > > 
> > > I got all your points and would agree but this is not a bayer only
> > > related problem. You will have this problem with all new other formats
> > > as well. I'm with you, most IP cores don't care but I wouldn't
> > > guarantee that.
> > 
> > Sorry, but adding new media bus formats like this one will just not
> > scale. We have two options, either fixing the issue, or considering that
> > V4L2 is a barely alive API with no future, and merging this without
> > caring anymore.
> 
> Hm.. you're right that it doesn't scale, as I said I'm absolute on your
> side. So let us consider a new approach @Mauro, @Hans, @Sailus what do
> you think about?

Starting brainstorming, how about new media bus codes for
raw{8,10,12,14,16}, and a read-only CFA pattern control to retrieve the
pattern from the sensor subdev ? We could use the same control to set
the pattern on subdevs that require it, which would mostly be ISPs. As
ISPs are configured using parameter buffers these days, it may be better
to pass the pattern in the parameter buffer instead though.

This shouldn't be too hard to implement, but the devil is of course in
the details, and we should consider how to handle the pattern control
when flipping and/or cropping is configured on the sensor.

> BTW: IMHO videobuf2 interface isn't that good as well, since you are
> blaming ;)

Have you looked at videobuf1 ? ;-) Jokes aside, there's certainly room
for improvement, but it hasn't struck me as a particularly bad part of
the framework. Is there anything in particular you think is painful ?

-- 
Regards,

Laurent Pinchart


From andrew at lunn.ch  Fri Apr 30 13:31:31 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 30 Apr 2021 14:31:31 +0200
Subject: [PATCH net-next v3 3/6] net: add generic selftest support
In-Reply-To: <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>
References: <20210419130106.6707-1-o.rempel@pengutronix.de>
 <20210419130106.6707-4-o.rempel@pengutronix.de>
 <CAMuHMdW+cX=vsZg2MyBOM+6Akp-nRQ0QrU=2XSiegFhHNA+jVg@mail.gmail.com>
Message-ID: <YIv4owS5VxkadjoL@lunn.ch>

> Thanks for your patch, which is now commit 3e1e58d64c3d0a67 ("net: add
> generic selftest support") upstream.
> 
> > --- a/net/Kconfig
> > +++ b/net/Kconfig
> > @@ -429,6 +429,10 @@ config GRO_CELLS
> >  config SOCK_VALIDATE_XMIT
> >         bool
> >
> > +config NET_SELFTESTS
> > +       def_tristate PHYLIB
> 
> Why does this default to enabled if PHYLIB=y?
> Usually we allow the user to make selftests modular, independent of the
> feature under test, but I may misunderstand the purpose of this test.

Maybe there is a misunderstanding here with 'selftest'. The name page
for ethtool(1) says:

       -t --test
              Executes adapter selftest on the specified network device.  Pos?
              sible test modes are:

           offline
                  Perform  full set of tests, possibly interrupting normal op?
                  eration during the tests,

           online Perform limited set of tests, not interrupting normal opera?
                  tion,

           external_lb
                  Perform  full set of tests, as for offline, and additionally
                  an external-loopback test.

This feature has nothing to do with tools/testing/selftests. It
predates that by decades.

     Andrew


From mark.rutland at arm.com  Fri Apr 30 13:34:08 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 30 Apr 2021 13:34:08 +0100
Subject: [PATCH] arm_pmu: Fix write counter incorrect in ARMv7 big-endian
 mode
In-Reply-To: <20210430012659.232110-1-yangjihong1@huawei.com>
References: <20210430012659.232110-1-yangjihong1@huawei.com>
Message-ID: <20210430123408.GD53304@C02TD0UTHF1T.local>

On Fri, Apr 30, 2021 at 09:26:59AM +0800, Yang Jihong wrote:
> Commit 3a95200d3f89a ("arm_pmu: Change API to support 64bit counter values")
> changes the input "value" type from 32-bit to 64-bit,
> which introduces the following problem:
> ARMv7 PMU counters is 32-bit width, in big-endian mode, write counter uses
> high 32-bit, which writes an incorrect value.

It might be worth noting that the reason for this is that when a 64-bit
value is split across two 32-bit registers, the high/low halves are
split to match how LDRD would load a 64-bit quantity (and so differs
across big/little endian), but the "r" constraint consistently uses the
first of the two regiseters.

Given that, this patch makes sense to me (and I didn't spot any related
issues), so:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Will, I assume you'll pick this up.

Mark.

> 
> Before:
> 
>  Performance counter stats for 'ls':
> 
>               2.22 msec task-clock                #    0.675 CPUs utilized
>                  0      context-switches          #    0.000 K/sec
>                  0      cpu-migrations            #    0.000 K/sec
>                 49      page-faults               #    0.022 M/sec
>         2150476593      cycles                    #  966.663 GHz
>         2148588788      instructions              #    1.00  insn per cycle
>         2147745484      branches                  # 965435.074 M/sec
>         2147508540      branch-misses             #   99.99% of all branches
> 
> None of the above hw event counters are correct.
> 
> Solution:
> 
> "value" forcibly converted to 32-bit type before being written to PMU register.
> 
> After:
> 
>  Performance counter stats for 'ls':
> 
>               2.09 msec task-clock                #    0.681 CPUs utilized
>                  0      context-switches          #    0.000 K/sec
>                  0      cpu-migrations            #    0.000 K/sec
>                 46      page-faults               #    0.022 M/sec
>            2807301      cycles                    #    1.344 GHz
>            1060159      instructions              #    0.38  insn per cycle
>             250496      branches                  #  119.914 M/sec
>              23192      branch-misses             #    9.26% of all branches
> 
> Fixes: 3a95200d3f89a ("arm_pmu: Change API to support 64bit counter values")
> Signed-off-by: Yang Jihong <yangjihong1 at huawei.com>
> ---
>  arch/arm/kernel/perf_event_v7.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index 2924d7910b10..eb2190477da1 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -773,10 +773,10 @@ static inline void armv7pmu_write_counter(struct perf_event *event, u64 value)
>  		pr_err("CPU%u writing wrong counter %d\n",
>  			smp_processor_id(), idx);
>  	} else if (idx == ARMV7_IDX_CYCLE_COUNTER) {
> -		asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" (value));
> +		asm volatile("mcr p15, 0, %0, c9, c13, 0" : : "r" ((u32)value));
>  	} else {
>  		armv7_pmnc_select_counter(idx);
> -		asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" (value));
> +		asm volatile("mcr p15, 0, %0, c9, c13, 2" : : "r" ((u32)value));
>  	}
>  }
>  
> -- 
> 2.30.GIT
> 


From jgg at nvidia.com  Fri Apr 30 13:38:07 2021
From: jgg at nvidia.com (Jason Gunthorpe)
Date: Fri, 30 Apr 2021 09:38:07 -0300
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <20210430095417.GA13686@lpieralisi>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210430095417.GA13686@lpieralisi>
Message-ID: <20210430123807.GB1370958@nvidia.com>

On Fri, Apr 30, 2021 at 10:54:17AM +0100, Lorenzo Pieralisi wrote:
> [+Jason, Ben]
> 
> On Thu, Apr 29, 2021 at 11:29:05AM -0500, Shanker Donthineni wrote:
> > For pass-through device assignment, the ARM64 KVM hypervisor retrieves
> > the memory region properties physical address, size, and whether a
> > region backed with struct page or not from VMA. The prefetchable
> > attribute of a BAR region isn't visible to KVM to make an optimal
> > decision for stage2 attributes.
> > 
> > This patch updates vma->vm_page_prot and maps with write-combine
> > attribute if the associated BAR is prefetchable. For ARM64
> > pgprot_writecombine() is mapped to memory-type MT_NORMAL_NC which
> > has no side effects on reads and multiple writes can be combined.
> > 
> > Signed-off-by: Shanker Donthineni <sdonthineni at nvidia.com>
> >  drivers/vfio/pci/vfio_pci.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> A bit of background information that may be useful:
> 
> https://lore.kernel.org/linux-pci/2b539df4c9ec703458e46da2fc879ee3b310b31c.camel at kernel.crashing.org

This can't happen automatically.

writecombining or not is a uABI visible change. Userspace needs to
explicitly request and know that the mmap it gets back is
writecombining.

Jason


From linux at fw-web.de  Fri Apr 30 13:43:17 2021
From: linux at fw-web.de (Frank Wunderlich)
Date: Fri, 30 Apr 2021 14:43:17 +0200
Subject: [PATCH] musb: mediatek: rename driver
Message-ID: <20210430124317.97376-1-linux@fw-web.de>

From: Frank Wunderlich <frank-w at public-files.de>

currently unspecific mediatek.ko is built,
change this by adding subsystem

Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
---
 drivers/usb/musb/Makefile                   | 2 +-
 drivers/usb/musb/{mediatek.c => musb_mtk.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/usb/musb/{mediatek.c => musb_mtk.c} (100%)

diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 932247360a9f..82928d4fd42a 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)			+= da8xx.o
 obj-$(CONFIG_USB_MUSB_UX500)			+= ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)			+= jz4740.o
 obj-$(CONFIG_USB_MUSB_SUNXI)			+= sunxi.o
-obj-$(CONFIG_USB_MUSB_MEDIATEK)      		+= mediatek.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)      		+= musb_mtk.o
 
 # the kconfig must guarantee that only one of the
 # possible I/O schemes will be enabled at a time ...
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/musb_mtk.c
similarity index 100%
rename from drivers/usb/musb/mediatek.c
rename to drivers/usb/musb/musb_mtk.c
-- 
2.25.1



From mchehab at kernel.org  Fri Apr 30 13:44:36 2021
From: mchehab at kernel.org (Mauro Carvalho Chehab)
Date: Fri, 30 Apr 2021 14:44:36 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <YIrkjcuF/+huMotl@pendragon.ideasonboard.com>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <20210429104441.3e85d81b@coco.lan>
 <YIrkjcuF/+huMotl@pendragon.ideasonboard.com>
Message-ID: <20210430144436.2c09c99a@coco.lan>

Em Thu, 29 Apr 2021 19:53:33 +0300
Laurent Pinchart <laurent.pinchart at ideasonboard.com> escreveu:

> Hi Mauro,
> 
> On Thu, Apr 29, 2021 at 10:44:41AM +0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 29 Apr 2021 09:49:03 +0200 Marco Felsch escreveu:  
> > > On 21-04-29 04:51, Laurent Pinchart wrote:  
> > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:    
> > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > > with the interleaved IR pixels looks like:
> > > > > 
> > > > >         |  G |  R |  G |  B | ...
> > > > >         +----+----+----+----+---
> > > > >         | IR |  G | IR |  G | ...
> > > > >         +----+----+----+----+---
> > > > >         |  G |  B |  G |  R | ...
> > > > >         +----+----+----+----+---
> > > > >         | IR |  G | IR |  G | ...
> > > > >         +----+----+----+----+---
> > > > >         | .. | .. | .. | .. | ..
> > > > > 
> > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf    
> > > > 
> > > > I think we're reaching a limit of the media bus codes model here, due to
> > > > a historical mistake. The four possible Bayer patterns, times the
> > > > different number of bits per pixel, creates a lot of media bus codes,
> > > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > > have to support them all.    
> > > 
> > > That's correct but it is not bayer related.  
> > 
> > Err... there are two separate things here:
> > 
> > 1) for the uAPI part, we're not even close to the limit of a 4-bytes
> >    fourcc;
> > 
> > 2) the kAPI is currently sharing the same fourcc from the uAPI,
> >    because it is a lot simpler than doing something different.  
> 
> Please note that we're talking about media bus codes here, not pixel
> formats. Both are part of the UAPI though, and pixel formats suffer from
> a similar issue, but I'd like to focus on the media bus codes first.

Yes, I'm aware of that, but the same principle used by fourcc pixel
formats can also be applied to media bus codes and vice versa[1].

[1] IMO, a kAPI change like that should consider the big picture, 
    and allow using the same process for both, even if we start
    implementing it for media bus (where it makes more sense).

On both cases, we're talking about a 32-bit code (either encoded
as fourcc or via MEDIA_BUS_FMT_* codespace).

Both can be 1:1 mapped to some structure similar to:

enum v4l2_pixformat_type {
	VIDEO_PIXFORMAT_RGB,
	VIDEO_PIXFORMAT_YUV,
	VIDEO_PIXFORMAT_COMPRESSED,
	VIDEO_PIXFORMAT_BAYER_RGB,
	VIDEO_PIXFORMAT_BAYER_RGB_IR,
};
 
struct v4l2_pixformat_desc {
	enum v4l2_pixformat_type	pixfmt_type;
	bool				is_packed;
 	int				bits_per_component;
 
	union {
		enum v4l2_pixformat_rgb_order		rgb_order;
		enum v4l2_pixformat_yuv_order		yuv_order;
		enum v4l2_pixformat_bayer_rgb_order	bayer_rgb_order;
		enum v4l2_pixformat_bayer_rgb_ir_order	bayer_rgb_ir_order;
		enum v4l2_pixformat_compress_type	compress_type;
	};
	...
};

And new drivers can use such struct, instead of handling the
fourcc/mbus code directly.

Also, this can be gradually implemented, in order to avoid the
need of touching at the existing drivers.

Thanks,
Mauro


From mchehab at kernel.org  Fri Apr 30 13:51:46 2021
From: mchehab at kernel.org (Mauro Carvalho Chehab)
Date: Fri, 30 Apr 2021 14:51:46 +0200
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <YIv1rMFZuv7z4R8a@pendragon.ideasonboard.com>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>
 <20210430065134.jwscxlv3sydo4zgy@pengutronix.de>
 <YIv1rMFZuv7z4R8a@pendragon.ideasonboard.com>
Message-ID: <20210430145146.359a9b90@coco.lan>

Em Fri, 30 Apr 2021 15:18:52 +0300
Laurent Pinchart <laurent.pinchart at ideasonboard.com> escreveu:

> Hi Marco,
> 
> On Fri, Apr 30, 2021 at 08:51:34AM +0200, Marco Felsch wrote:
> > On 21-04-30 01:14, Laurent Pinchart wrote:  
> > > On Thu, Apr 29, 2021 at 09:49:03AM +0200, Marco Felsch wrote:  
> > > > On 21-04-29 04:51, Laurent Pinchart wrote:  
> > > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:  
> > > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > > > with the interleaved IR pixels looks like:
> > > > > > 
> > > > > >         |  G |  R |  G |  B | ...
> > > > > >         +----+----+----+----+---
> > > > > >         | IR |  G | IR |  G | ...
> > > > > >         +----+----+----+----+---
> > > > > >         |  G |  B |  G |  R | ...
> > > > > >         +----+----+----+----+---
> > > > > >         | IR |  G | IR |  G | ...
> > > > > >         +----+----+----+----+---
> > > > > >         | .. | .. | .. | .. | ..
> > > > > > 
> > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf  
> > > > > 
> > > > > I think we're reaching a limit of the media bus codes model here, due to
> > > > > a historical mistake. The four possible Bayer patterns, times the
> > > > > different number of bits per pixel, creates a lot of media bus codes,
> > > > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > > > have to support them all.  
> > > > 
> > > > That's correct but it is not bayer related. Currently it is what it is,
> > > > if a new code is added it must be propagated through all the involved
> > > > subdevs. On the other hand I wouldn't say that it is better to support
> > > > new codes per default for all drivers. Since this would add a lot of
> > > > untested code paths.  
> > > 
> > > It's not an issue limited to Bayer patterns, but they make the issue
> > > worse given the number of possible combinations (think about adding DPCM
> > > and ALAW compression on top of that...).  
> > 
> > You're right and again this will apply to all mbus formats...
> >   
> > > > > This is already painful, and if we had a
> > > > > non-Bayer pattern such as this one,  
> > > > 
> > > > That's not exactly true since it is a bayer pattern but instead of using
> > > > 4x4 it uses 8x8 and it as some special pixels.
> > > >   
> > > > > we'll open the door to an explosion
> > > > > of the number of media bus codes (imagine all the different possible
> > > > > arrangements of this pattern, for instance if you enable horizontal
> > > > > and/or vertical flipping on the sensor). All drivers would need to be
> > > > > updated to support these new bus codes, and this really kills the
> > > > > current model.  
> > > > 
> > > > Yep, I know what you mean but as I said above I think that adding it
> > > > explicite is the better abbroach since it involves somone who add _and_
> > > > test the new code on the particular platform.
> > > >   
> > > > > The historical mistake was to tie the Bayer pattern with the media bus
> > > > > code. We should really have specified raw 8/10/12/14/16 media bus codes,
> > > > > and conveyed the pattern separately. Most IP cores in the pipeline don't
> > > > > need to care about the pattern at all, and those who do (that's mostly
> > > > > ISPs) could be programmed explicitly by userspace as long as we have an
> > > > > API to retrieve the pattern from the sensor. I believe it's time to bite
> > > > > the bullet and go in that direction. I'm sorry for this case of yak
> > > > > shaving, but it really wouldn't be manageable anymore :-(  
> > > > 
> > > > I got all your points and would agree but this is not a bayer only
> > > > related problem. You will have this problem with all new other formats
> > > > as well. I'm with you, most IP cores don't care but I wouldn't
> > > > guarantee that.  
> > > 
> > > Sorry, but adding new media bus formats like this one will just not
> > > scale. We have two options, either fixing the issue, or considering that
> > > V4L2 is a barely alive API with no future, and merging this without
> > > caring anymore.  
> > 
> > Hm.. you're right that it doesn't scale, as I said I'm absolute on your
> > side. So let us consider a new approach @Mauro, @Hans, @Sailus what do
> > you think about?  
> 
> Starting brainstorming, how about new media bus codes for
> raw{8,10,12,14,16}, 

By "raw", are you meaning vendor-specific formats? If so, that sounds 
a bad idea. Different vendor-specific formats should use different
media bus codes (and fourccs) as otherwise there won't be an easy way
to distinguish them and to describe the raw formats at the media specs.

Thanks,
Mauro


From gregkh at linuxfoundation.org  Fri Apr 30 13:54:03 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 30 Apr 2021 14:54:03 +0200
Subject: [PATCH] musb: mediatek: rename driver
In-Reply-To: <20210430124317.97376-1-linux@fw-web.de>
References: <20210430124317.97376-1-linux@fw-web.de>
Message-ID: <YIv969BCnPgXzrcg@kroah.com>

On Fri, Apr 30, 2021 at 02:43:17PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w at public-files.de>
> 
> currently unspecific mediatek.ko is built,
> change this by adding subsystem

I am sorry, I do not understand this changelog text.  What are you doing
here and why?

> Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> ---
>  drivers/usb/musb/Makefile                   | 2 +-
>  drivers/usb/musb/{mediatek.c => musb_mtk.c} | 0

Why rename this file, will that not break existing setups that expect
the module to be named this?

thanks,

greg k-h


From laurent.pinchart at ideasonboard.com  Fri Apr 30 13:58:54 2021
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 30 Apr 2021 15:58:54 +0300
Subject: [PATCH 1/6] media: uapi: Add MEDIA_BUS_FMT_SGRGB_IGIG_GBGR_IGIG
 media bus formats
In-Reply-To: <20210430145146.359a9b90@coco.lan>
References: <20210427120701.21809-1-m.felsch@pengutronix.de>
 <20210427120701.21809-2-m.felsch@pengutronix.de>
 <YIoRLQfoNm0GJGsY@pendragon.ideasonboard.com>
 <20210429074903.cc5gohn52cgv4i5z@pengutronix.de>
 <YIsvyz49KvZK6Wg5@pendragon.ideasonboard.com>
 <20210430065134.jwscxlv3sydo4zgy@pengutronix.de>
 <YIv1rMFZuv7z4R8a@pendragon.ideasonboard.com>
 <20210430145146.359a9b90@coco.lan>
Message-ID: <YIv/DuLdrs3NEDoB@pendragon.ideasonboard.com>

On Fri, Apr 30, 2021 at 02:51:46PM +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 30 Apr 2021 15:18:52 +0300
> Laurent Pinchart <laurent.pinchart at ideasonboard.com> escreveu:
> 
> > Hi Marco,
> > 
> > On Fri, Apr 30, 2021 at 08:51:34AM +0200, Marco Felsch wrote:
> > > On 21-04-30 01:14, Laurent Pinchart wrote:  
> > > > On Thu, Apr 29, 2021 at 09:49:03AM +0200, Marco Felsch wrote:  
> > > > > On 21-04-29 04:51, Laurent Pinchart wrote:  
> > > > > > On Tue, Apr 27, 2021 at 02:06:56PM +0200, Marco Felsch wrote:  
> > > > > > > Add special 8/12bit bayer media bus format for the OnSemi AR0237IR
> > > > > > > camera sensor [1]. OnSemi calls this format RGB-IR, the pixel array
> > > > > > > with the interleaved IR pixels looks like:
> > > > > > > 
> > > > > > >         |  G |  R |  G |  B | ...
> > > > > > >         +----+----+----+----+---
> > > > > > >         | IR |  G | IR |  G | ...
> > > > > > >         +----+----+----+----+---
> > > > > > >         |  G |  B |  G |  R | ...
> > > > > > >         +----+----+----+----+---
> > > > > > >         | IR |  G | IR |  G | ...
> > > > > > >         +----+----+----+----+---
> > > > > > >         | .. | .. | .. | .. | ..
> > > > > > > 
> > > > > > > [1] https://www.framos.com/media/pdf/96/ac/8f/AR0237CS-D-PDF-framos.pdf  
> > > > > > 
> > > > > > I think we're reaching a limit of the media bus codes model here, due to
> > > > > > a historical mistake. The four possible Bayer patterns, times the
> > > > > > different number of bits per pixel, creates a lot of media bus codes,
> > > > > > and drivers for CSI-2 receivers and IP cores further down the pipeline
> > > > > > have to support them all.  
> > > > > 
> > > > > That's correct but it is not bayer related. Currently it is what it is,
> > > > > if a new code is added it must be propagated through all the involved
> > > > > subdevs. On the other hand I wouldn't say that it is better to support
> > > > > new codes per default for all drivers. Since this would add a lot of
> > > > > untested code paths.  
> > > > 
> > > > It's not an issue limited to Bayer patterns, but they make the issue
> > > > worse given the number of possible combinations (think about adding DPCM
> > > > and ALAW compression on top of that...).  
> > > 
> > > You're right and again this will apply to all mbus formats...
> > >   
> > > > > > This is already painful, and if we had a
> > > > > > non-Bayer pattern such as this one,  
> > > > > 
> > > > > That's not exactly true since it is a bayer pattern but instead of using
> > > > > 4x4 it uses 8x8 and it as some special pixels.
> > > > >   
> > > > > > we'll open the door to an explosion
> > > > > > of the number of media bus codes (imagine all the different possible
> > > > > > arrangements of this pattern, for instance if you enable horizontal
> > > > > > and/or vertical flipping on the sensor). All drivers would need to be
> > > > > > updated to support these new bus codes, and this really kills the
> > > > > > current model.  
> > > > > 
> > > > > Yep, I know what you mean but as I said above I think that adding it
> > > > > explicite is the better abbroach since it involves somone who add _and_
> > > > > test the new code on the particular platform.
> > > > >   
> > > > > > The historical mistake was to tie the Bayer pattern with the media bus
> > > > > > code. We should really have specified raw 8/10/12/14/16 media bus codes,
> > > > > > and conveyed the pattern separately. Most IP cores in the pipeline don't
> > > > > > need to care about the pattern at all, and those who do (that's mostly
> > > > > > ISPs) could be programmed explicitly by userspace as long as we have an
> > > > > > API to retrieve the pattern from the sensor. I believe it's time to bite
> > > > > > the bullet and go in that direction. I'm sorry for this case of yak
> > > > > > shaving, but it really wouldn't be manageable anymore :-(  
> > > > > 
> > > > > I got all your points and would agree but this is not a bayer only
> > > > > related problem. You will have this problem with all new other formats
> > > > > as well. I'm with you, most IP cores don't care but I wouldn't
> > > > > guarantee that.  
> > > > 
> > > > Sorry, but adding new media bus formats like this one will just not
> > > > scale. We have two options, either fixing the issue, or considering that
> > > > V4L2 is a barely alive API with no future, and merging this without
> > > > caring anymore.  
> > > 
> > > Hm.. you're right that it doesn't scale, as I said I'm absolute on your
> > > side. So let us consider a new approach @Mauro, @Hans, @Sailus what do
> > > you think about?  
> > 
> > Starting brainstorming, how about new media bus codes for
> > raw{8,10,12,14,16}, 
> 
> By "raw", are you meaning vendor-specific formats? If so, that sounds 
> a bad idea. Different vendor-specific formats should use different
> media bus codes (and fourccs) as otherwise there won't be an easy way
> to distinguish them and to describe the raw formats at the media specs.

I mean what the CSI-2 spec means. The exact interpretation of the format
will be a combination of the media bus code and the CFA pattern control.
The whole point of this discussion is to not have different media bus
codes for all possible combinations of formats, as that clearly doesn't
scale.

-- 
Regards,

Laurent Pinchart


From sdonthineni at nvidia.com  Fri Apr 30 14:07:46 2021
From: sdonthineni at nvidia.com (Shanker R Donthineni)
Date: Fri, 30 Apr 2021 08:07:46 -0500
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <87czucngdc.wl-maz@kernel.org>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
Message-ID: <7c685ae6-938b-9d99-20e6-f51398543441@nvidia.com>


Hi Marc,

On 4/30/21 6:47 AM, Marc Zyngi
>>>> We've two concerns here:
>>>>    - Performance impacts for pass-through devices.
>>>>    - The definition of ioremap_wc() function doesn't match the host
>>>> kernel on ARM64
>>> Performance I can understand, but I think you're also using it to mask
>>> a driver bug which should be resolved first.  Thank
>> We?ve already instrumented the driver code and found the code path
>> for the unaligned accesses. We?ll fix this issue if it?s not
>> following WC semantics.
>>
>> Fixing the performance concern will be under KVM stage-2 page-table
>> control. We're looking for a guidance/solution for updating stage-2
>> PTE based on PCI-BAR attribute.
> Before we start discussing the *how*, I'd like to clearly understand
> what *arm64* memory attributes you are relying on. We already have
> established that the unaligned access was a bug, which was the biggest
> argument in favour of NORMAL_NC. What are the other requirements?
>
We are? relying? on NORMAL_NC mapping for PCI prefetchable BARs instead of DEVICE_nGnRE in baremetal and VM.
No other requirement other than this.

-Shanker



From geert+renesas at glider.be  Fri Apr 30 14:10:55 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:55 +0200
Subject: [PATCH 5/5] ARM: dts: silk: Configure pull-up for SOFT_SW GPIO keys
In-Reply-To: <cover.1619785905.git.geert+renesas@glider.be>
References: <cover.1619785905.git.geert+renesas@glider.be>
Message-ID: <45f38a5333feba9bea80efeb5a41a6c3f60deda2.1619785905.git.geert+renesas@glider.be>

The GPIO pins connected to the 4 Software Switches ("SOFT_SW", SW12) do
not have external pull-up resistors, but rely on internal pull-ups being
enabled.  Fortunately this is satisfied by the initial state of these
pins.

Make this explicit by enabling bias-pull-up, to remove the dependency on
initial state and/or boot loader configuration.

While at it, rename the surrounding device node from "gpio-keys" to
"keyboard", to comply with generic node name recommendations.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794-silk.dts | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index eb89a27a6ed0c9aa..cafa3046daa4baf4 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -45,9 +45,12 @@ memory at 40000000 {
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
-	gpio-keys {
+	keyboard {
 		compatible = "gpio-keys";
 
+		pinctrl-0 = <&keyboard_pins>;
+		pinctrl-names = "default";
+
 		key-3 {
 			gpios = <&gpio5 10 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_3>;
@@ -358,6 +361,11 @@ du1_pins: du1 {
 		function = "du1";
 	};
 
+	keyboard_pins: keyboard {
+		pins = "GP_3_9", "GP_3_10", "GP_3_11", "GP_3_12";
+		bias-pull-up;
+	};
+
 	ssi_pins: sound {
 		groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
 		function = "ssi";
-- 
2.25.1



From geert+renesas at glider.be  Fri Apr 30 14:10:53 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:53 +0200
Subject: [PATCH 3/5] ARM: dts: blanche: Configure pull-up for SOFT_SW and SW25
 GPIO keys
In-Reply-To: <cover.1619785905.git.geert+renesas@glider.be>
References: <cover.1619785905.git.geert+renesas@glider.be>
Message-ID: <011e4c461767f2dd690b655b3dd501eb554184c1.1619785905.git.geert+renesas@glider.be>

The GPIO pins connected to the 4 Software Switches (SW2) and the second
Tact Switch (SW25) do not have external pull-up resistors, but rely on
internal pull-ups being enabled.  Fortunately this is satisfied by the
initial state of these pins.

Make this explicit by enabling bias-pull-up, to remove the dependency on
initial state and/or boot loader configuration.

Note that the GPIO pin connected to the first Tact Switch (SW24) does
have an external pull-up resistor.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7792-blanche.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7792-blanche.dts b/arch/arm/boot/dts/r8a7792-blanche.dts
index c100ae903a46bb1c..62aa9f61321bea74 100644
--- a/arch/arm/boot/dts/r8a7792-blanche.dts
+++ b/arch/arm/boot/dts/r8a7792-blanche.dts
@@ -112,6 +112,9 @@ x2_clk: x2 {
 	keyboard {
 		compatible = "gpio-keys";
 
+		pinctrl-0 = <&keyboard_pins>;
+		pinctrl-names = "default";
+
 		key-1 {
 			linux,code = <KEY_1>;
 			label = "SW2-1";
@@ -235,6 +238,11 @@ du1_pins: du1 {
 		function = "du1";
 	};
 
+	keyboard_pins: keyboard {
+		pins = "GP_3_10", "GP_3_11", "GP_3_12", "GP_3_15", "GP_11_02";
+		bias-pull-up;
+	};
+
 	pmic_irq_pins: pmicirq {
 		groups = "intc_irq2";
 		function = "intc";
-- 
2.25.1



From geert+renesas at glider.be  Fri Apr 30 14:10:51 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:51 +0200
Subject: [PATCH 1/5] ARM: dts: koelsch: Rename sw2 to keyboard
In-Reply-To: <cover.1619785905.git.geert+renesas@glider.be>
References: <cover.1619785905.git.geert+renesas@glider.be>
Message-ID: <3d718cf69e21b1ceea0c29c0e841b9bdda44533d.1619785905.git.geert+renesas@glider.be>

Rename "sw2_pins" and "sw2" to "keyboard_pins" resp. "keyboard", to
comply with generic name recommendations.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 61e881bbbf6ee5aa..2a8b6fd9095cceba 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -81,7 +81,7 @@ lbsc {
 	keyboard {
 		compatible = "gpio-keys";
 
-		pinctrl-0 = <&sw2_pins>;
+		pinctrl-0 = <&keyboard_pins>;
 		pinctrl-names = "default";
 
 		key-1 {
@@ -622,7 +622,7 @@ sound_clk_pins: sound_clk {
 		function = "audio_clk";
 	};
 
-	sw2_pins: sw2 {
+	keyboard_pins: keyboard {
 		pins = "GP_5_0", "GP_5_1", "GP_5_2", "GP_5_3";
 		bias-pull-up;
 	};
-- 
2.25.1



From geert+renesas at glider.be  Fri Apr 30 14:10:54 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:54 +0200
Subject: [PATCH 4/5] ARM: dts: gose: Configure pull-up for SOFT_SW GPIO keys
In-Reply-To: <cover.1619785905.git.geert+renesas@glider.be>
References: <cover.1619785905.git.geert+renesas@glider.be>
Message-ID: <1cdec892b1491309b12bdaf7bc8428b3a19b1ed5.1619785905.git.geert+renesas@glider.be>

The GPIO pins connected to the 4 Software Switches ("SOFT_SW", SW2) do
not have external pull-up resistors, but rely on internal pull-ups being
enabled.  Fortunately this is satisfied by the initial state of these
pins.

Make this explicit by enabling bias-pull-up, to remove the dependency on
initial state and/or boot loader configuration.

While at it, rename the surrounding device node from "gpio-keys" to
"keyboard", to comply with generic node name recommendations.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 87fa57a99399b73d..479e0fdf0c37311e 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -64,9 +64,12 @@ memory at 40000000 {
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
-	gpio-keys {
+	keyboard {
 		compatible = "gpio-keys";
 
+		pinctrl-0 = <&keyboard_pins>;
+		pinctrl-names = "default";
+
 		key-1 {
 			gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_1>;
@@ -567,6 +570,11 @@ sound_clk_pins: sound_clk {
 		function = "audio_clk";
 	};
 
+	keyboard_pins: keyboard {
+		pins = "GP_5_0", "GP_5_1", "GP_5_2", "GP_5_3";
+		bias-pull-up;
+	};
+
 	vin0_pins: vin0 {
 		groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
 		function = "vin0";
-- 
2.25.1



From geert+renesas at glider.be  Fri Apr 30 14:10:52 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:52 +0200
Subject: [PATCH 2/5] ARM: dts: lager: Configure pull-up for SOFT_SW GPIO keys
In-Reply-To: <cover.1619785905.git.geert+renesas@glider.be>
References: <cover.1619785905.git.geert+renesas@glider.be>
Message-ID: <9fae3c0c2c0000f6b43c9ce87fe64a594b30a7da.1619785905.git.geert+renesas@glider.be>

The GPIO pins connected to the 4 Software Switches (SW2) do not have
external pull-up resistors, but rely on internal pull-ups being enabled.
Fortunately this is satisfied by the initial state of these pins.

Make this explicit by enabling bias-pull-up, to remove the dependency on
initial state and/or boot loader configuration.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7790-lager.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 2dad0742d2ba159b..fa6d986b5d4632cf 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -81,6 +81,9 @@ lbsc {
 	keyboard {
 		compatible = "gpio-keys";
 
+		pinctrl-0 = <&keyboard_pins>;
+		pinctrl-names = "default";
+
 		one {
 			linux,code = <KEY_1>;
 			label = "SW2-1";
@@ -659,6 +662,11 @@ sound_clk_pins: sound_clk {
 		groups = "audio_clk_a";
 		function = "audio_clk";
 	};
+
+	keyboard_pins: keyboard {
+		pins = "GP_1_14", "GP_1_24", "GP_1_26", "GP_1_28";
+		bias-pull-up;
+	};
 };
 
 &ether {
-- 
2.25.1



From geert+renesas at glider.be  Fri Apr 30 14:10:50 2021
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 15:10:50 +0200
Subject: [PATCH 0/5] ARM: dts: rcar2: Configure pull up for GPIO keys
Message-ID: <cover.1619785905.git.geert+renesas@glider.be>

	Hi all,

This patches series follows up on the work started with "[PATCH] ARM:
dts: koelsch: Configure pull-up for SOFT_SW GPIO keys"[1], and
explicitly configures pull-ups for pins used for GPIO keys without
external pull-up resistors on R-Car Gen2 boards, preceded by a small
cleanup.  Currently GPIO keys rely on the initial states of these pins,
which fortunately match the expectations, but it is better to be
explicit.

To actually make a difference, this depends on "[PATCH 00/12] pinctrl:
renesas: Add more bias pinconf support"[2].  Note that it is safe to
apply this series before [2] has landed, as pinctrl_bind_pins() does not
consider -ENOTSUPP a fatal error.

It would be great if people with access to the hardware could do similar
tests like I did on Koelsch[3].

I hope to queue this in renesas-devel for v5.14.

Thanks for your comments!

[1] https://lore.kernel.org/r/20210303132941.3938516-1-geert+renesas at glider.be/
[2] https://lore.kernel.org/r/cover.1619785375.git.geert+renesas at glider.be/	
[3] https://lore.kernel.org/r/20210303132619.3938128-1-geert+renesas at glider.be

Geert Uytterhoeven (5):
  ARM: dts: koelsch: Rename sw2 to keyboard
  ARM: dts: lager: Configure pull-up for SOFT_SW GPIO keys
  ARM: dts: blanche: Configure pull-up for SOFT_SW and SW25 GPIO keys
  ARM: dts: gose: Configure pull-up for SOFT_SW GPIO keys
  ARM: dts: silk: Configure pull-up for SOFT_SW GPIO keys

 arch/arm/boot/dts/r8a7790-lager.dts   |  8 ++++++++
 arch/arm/boot/dts/r8a7791-koelsch.dts |  4 ++--
 arch/arm/boot/dts/r8a7792-blanche.dts |  8 ++++++++
 arch/arm/boot/dts/r8a7793-gose.dts    | 10 +++++++++-
 arch/arm/boot/dts/r8a7794-silk.dts    | 10 +++++++++-
 5 files changed, 36 insertions(+), 4 deletions(-)

-- 
2.25.1

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 frank-w at public-files.de  Fri Apr 30 14:30:39 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Fri, 30 Apr 2021 15:30:39 +0200
Subject: Aw: Re: [PATCH] musb: mediatek: rename driver
In-Reply-To: <YIv969BCnPgXzrcg@kroah.com>
References: <20210430124317.97376-1-linux@fw-web.de>
 <YIv969BCnPgXzrcg@kroah.com>
Message-ID: <trinity-5166e76d-779d-4b05-870b-59971bd1571c-1619789439850@3c-app-gmx-bap03>

Hi Grek

the problem is that the name mediatek.ko does not point to musb-subsystem. I had discussed with Min Gao (author of this driver) some time ago about this as the name may conflict with other modules (don't remember which was that).
We have searched issue using the driver on my board (not yet resolved).

if the module is loaded it shows (based on name) only "mediatek" and user does not know that is the mediatek musb driver, not very good in my eyes as mediatek is a vendor designing many different hardware and so drivers. Imho the module-name should at least give a clue to the subsystem to avoid confusion/conflicts

Now the discussion comes up again here for a new driver:
https://patchwork.kernel.org/project/linux-mediatek/cover/20210429062130.29403-1-dqfext at gmail.com/#24148777

so i decided to rebase and post my patch created in past to clean this up.

and yes this can result in user-space issues depending on the name...because of this i have not added stable-tag ;)

regards Frank


> Gesendet: Freitag, 30. April 2021 um 14:54 Uhr
> Von: "Greg Kroah-Hartman" <gregkh at linuxfoundation.org>

> On Fri, Apr 30, 2021 at 02:43:17PM +0200, Frank Wunderlich wrote:
> > From: Frank Wunderlich <frank-w at public-files.de>
> >
> > currently unspecific mediatek.ko is built,
> > change this by adding subsystem
>
> I am sorry, I do not understand this changelog text.  What are you doing
> here and why?
>
> > Signed-off-by: Frank Wunderlich <frank-w at public-files.de>
> > ---
> >  drivers/usb/musb/Makefile                   | 2 +-
> >  drivers/usb/musb/{mediatek.c => musb_mtk.c} | 0
>
> Why rename this file, will that not break existing setups that expect
> the module to be named this?
>
> thanks,
>
> greg k-h



From gregkh at linuxfoundation.org  Fri Apr 30 14:57:17 2021
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 30 Apr 2021 15:57:17 +0200
Subject: [PATCH] musb: mediatek: rename driver
In-Reply-To: <trinity-5166e76d-779d-4b05-870b-59971bd1571c-1619789439850@3c-app-gmx-bap03>
References: <20210430124317.97376-1-linux@fw-web.de>
 <YIv969BCnPgXzrcg@kroah.com>
 <trinity-5166e76d-779d-4b05-870b-59971bd1571c-1619789439850@3c-app-gmx-bap03>
Message-ID: <YIwMvUVmeeYT1aph@kroah.com>

Please do not top-post :)

On Fri, Apr 30, 2021 at 03:30:39PM +0200, Frank Wunderlich wrote:
> Hi Grek
> 
> the problem is that the name mediatek.ko does not point to musb-subsystem. I had discussed with Min Gao (author of this driver) some time ago about this as the name may conflict with other modules (don't remember which was that).
> We have searched issue using the driver on my board (not yet resolved).
> 
> if the module is loaded it shows (based on name) only "mediatek" and user does not know that is the mediatek musb driver, not very good in my eyes as mediatek is a vendor designing many different hardware and so drivers. Imho the module-name should at least give a clue to the subsystem to avoid confusion/conflicts
> 
> Now the discussion comes up again here for a new driver:
> https://patchwork.kernel.org/project/linux-mediatek/cover/20210429062130.29403-1-dqfext at gmail.com/#24148777
> 
> so i decided to rebase and post my patch created in past to clean this up.

All of this information needs to go into the changelog text, what you
wrote there does not explain all of the above.

> and yes this can result in user-space issues depending on the name...because of this i have not added stable-tag ;)

Why does stable matter?  If this could result in a userspace breakage,
that's not ok for any kernel change.

Why not just have any new driver not use this name, as it is, it's not
hurting anything.  Until you can guarantee that renaming this is not
going to break anything, I can not take it.

thanks,

greg k-h


From patrice.chotard at foss.st.com  Fri Apr 30 15:16:51 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Fri, 30 Apr 2021 16:16:51 +0200
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426162610.erpt5ubeddx7paeq@ti.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
 <20210426162610.erpt5ubeddx7paeq@ti.com>
Message-ID: <0ccafbbf-194d-d523-34b0-a5c7c9bc95c1@foss.st.com>

Hi Pratyush

On 4/26/21 6:26 PM, Pratyush Yadav wrote:
> Hi,
> 
> On 26/04/21 04:39PM, patrice.chotard at foss.st.com wrote:
>> From: Christophe Kerello <christophe.kerello at foss.st.com>
>>
>> With STM32 QSPI, it is possible to poll the status register of the device.
>> This could be done to offload the CPU during an operation (erase or
>> program a SPI NAND for example).
>>
>> spi_mem_poll_status API has been added to handle this feature.
>>
>> Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
>> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
>> ---
>>  drivers/spi/spi-mem.c       | 34 ++++++++++++++++++++++++++++++++++
>>  include/linux/spi/spi-mem.h |  8 ++++++++
>>  2 files changed, 42 insertions(+)
>>
>> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
>> index 1513553e4080..43dce4b0efa4 100644
>> --- a/drivers/spi/spi-mem.c
>> +++ b/drivers/spi/spi-mem.c
>> @@ -743,6 +743,40 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>>  	return container_of(drv, struct spi_mem_driver, spidrv.driver);
>>  }
>>  
>> +/**
>> + * spi_mem_poll_status() - Poll memory device status
>> + * @mem: SPI memory device
>> + * @op: the memory operation to execute
>> + * @mask: status bitmask to ckeck
>> + * @match: status expected value
> 
> Technically, (status & mask) expected value. Dunno if that is obvious 
> enough to not spell out explicitly.

Yes, match = (status & mask)
I will update the comment accordingly.

> 
>> + * @timeout: timeout
>> + *
>> + * This function send a polling status request to the controller driver
>> + *
>> + * Return: 0 in case of success, -ETIMEDOUT in case of error,
>> + *         -EOPNOTSUPP if not supported.
>> + */
>> +int spi_mem_poll_status(struct spi_mem *mem,
>> +			const struct spi_mem_op *op,
>> +			u8 mask, u8 match, u16 timeout)
>> +{
>> +	struct spi_controller *ctlr = mem->spi->controller;
>> +	int ret = -EOPNOTSUPP;
>> +
>> +	if (ctlr->mem_ops && ctlr->mem_ops->poll_status) {
> 
> You should call spi_mem_supports_op() before sending any ops to the 
> controller. Invalid/unsupported ops can cause unexpected behavior.

Ok i will add it.

Thanks
Patrice

> 
>> +		ret = spi_mem_access_start(mem);
>> +		if (ret)
>> +			return ret;
>> +
>> +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);
> 
> I wonder if it is better to let spi-mem core take care of the timeout 
> part. On one hand it reduces code duplication on the driver side a 
> little bit. Plus it makes sure drivers don't mess anything up with bad 
> (or no) handling of the timeout. But on the other hand the interface 
> becomes a bit awkward since you'd have to pass a struct completion 
> around, and it isn't something particularly hard to get right either. 
> What do you think?
> 
>> +
>> +		spi_mem_access_end(mem);
>> +	}
>> +
>> +	return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_mem_poll_status);
>> +
>>  static int spi_mem_probe(struct spi_device *spi)
>>  {
>>  	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> index 2b65c9edc34e..5f78917c0f68 100644
>> --- a/include/linux/spi/spi-mem.h
>> +++ b/include/linux/spi/spi-mem.h
>> @@ -250,6 +250,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
>>   *		  the currently mapped area), and the caller of
>>   *		  spi_mem_dirmap_write() is responsible for calling it again in
>>   *		  this case.
>> + * @poll_status: poll memory device status
>>   *
>>   * This interface should be implemented by SPI controllers providing an
>>   * high-level interface to execute SPI memory operation, which is usually the
>> @@ -274,6 +275,9 @@ struct spi_controller_mem_ops {
>>  			       u64 offs, size_t len, void *buf);
>>  	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
>>  				u64 offs, size_t len, const void *buf);
>> +	int (*poll_status)(struct spi_mem *mem,
>> +			   const struct spi_mem_op *op,
>> +			   u8 mask, u8 match, u16 timeout);
>>  };
>>  
>>  /**
>> @@ -369,6 +373,10 @@ devm_spi_mem_dirmap_create(struct device *dev, struct spi_mem *mem,
>>  void devm_spi_mem_dirmap_destroy(struct device *dev,
>>  				 struct spi_mem_dirmap_desc *desc);
>>  
>> +int spi_mem_poll_status(struct spi_mem *mem,
>> +			const struct spi_mem_op *op,
>> +			u8 mask, u8 match, u16 timeout);
>> +
>>  int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>>  				       struct module *owner);
> 


From patrice.chotard at foss.st.com  Fri Apr 30 15:22:34 2021
From: patrice.chotard at foss.st.com (Patrice CHOTARD)
Date: Fri, 30 Apr 2021 16:22:34 +0200
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426165118.GH4590@sirena.org.uk>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
 <20210426162610.erpt5ubeddx7paeq@ti.com>
 <20210426165118.GH4590@sirena.org.uk>
Message-ID: <28acedfd-6cd5-a8ad-0182-e61c3c30c27d@foss.st.com>

Hi Mark, Pratyush

On 4/26/21 6:51 PM, Mark Brown wrote:
> On Mon, Apr 26, 2021 at 09:56:12PM +0530, Pratyush Yadav wrote:
>> On 26/04/21 04:39PM, patrice.chotard at foss.st.com wrote:
> 
>>> + * spi_mem_poll_status() - Poll memory device status
>>> + * @mem: SPI memory device
>>> + * @op: the memory operation to execute
>>> + * @mask: status bitmask to ckeck
>>> + * @match: status expected value
> 
>> Technically, (status & mask) expected value. Dunno if that is obvious 
>> enough to not spell out explicitly.
> 
> Is it possible there's some situation where you're waiting for some bits
> to clear as well?
> 
Yes, we are waiting STATUS_BUSY bit to be cleared, see patch 2 which is making 
usage of this API.

>>> +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);
> 
> I'm not sure I like this name since it makes me think the driver is
> going to poll when really it's offloaded to the hardware, but I can't
> think of any better ideas either and it *is* what the hardware is going
> to be doing so meh.
> 
>> I wonder if it is better to let spi-mem core take care of the timeout 
>> part. On one hand it reduces code duplication on the driver side a 
>> little bit. Plus it makes sure drivers don't mess anything up with bad 
>> (or no) handling of the timeout. But on the other hand the interface 
>> becomes a bit awkward since you'd have to pass a struct completion 
>> around, and it isn't something particularly hard to get right either. 
>> What do you think?
> 
> We already have the core handling other timeouts.  We don't pass around
> completions but rather have an API function that the driver has to call
> when the operation completes, a similar pattern might work here.  Part

So, if i correctly understood, you make allusion to what is already done
in SPI core framework with spi_finalize_current_transfer() right ?

> of the thing with those APIs which I'm missing here is that this will
> just return -EOPNOTSUPP if the driver can't do the delay in hardware, I
> think it would be cleaner if this API were similar and the core dealt
> with doing the delay/poll on the CPU.  That way the users don't need to
> repeat the handling for the offload/non-offload cases.

Sorry, i didn't catch what you mean here. In PATCH 2, that's the case,
if spi_mem_poll_status() is not supported, the core is dealing with 
the delay/poll on the CPU in spinand_wait().

Patrice
Thanks


> 



From frank-w at public-files.de  Fri Apr 30 15:38:03 2021
From: frank-w at public-files.de (Frank Wunderlich)
Date: Fri, 30 Apr 2021 16:38:03 +0200
Subject: [PATCH] musb: mediatek: rename driver
In-Reply-To: <YIwMvUVmeeYT1aph@kroah.com>
References: <20210430124317.97376-1-linux@fw-web.de>
 <YIv969BCnPgXzrcg@kroah.com>
 <trinity-5166e76d-779d-4b05-870b-59971bd1571c-1619789439850@3c-app-gmx-bap03>
 <YIwMvUVmeeYT1aph@kroah.com>
Message-ID: <16ABF577-4EE1-4BB3-A801-A4498CBFCFCE@public-files.de>

Am 30. April 2021 15:57:17 MESZ schrieb Greg Kroah-Hartman <gregkh at linuxfoundation.org>:

>Why not just have any new driver not use this name, as it is, it's not
>hurting anything.

I just want to make it clean for users/admins for what kind of device this module is for (vendor.ko is imho not good at least for vendors manufacturing such different devices).
And avoid such conflicts like the phy (which had reintroduced the unclear module name).
The new module will be renamed in next version..there is only discussion about the new name...and so i tried to fix the "other end".

>Until you can guarantee that renaming this is not
>going to break anything, I can not take it.

If a user/administrator installs a new major kernel version he needs to check if all is still working. Then the new module can be loaded...i don't see a real breakage or much work for "fix" this,but it's ok if you do not take it up.

This driver is afair available since 5.4 so i guess not much spreading in large productive environments mostly still using 4.14 or 4.4

I can repost with better description,but this is not needed if change itself will be rejected. So maybe anyone else can comment too.

regards Frank


From derrick.mckee at gmail.com  Fri Apr 30 15:40:04 2021
From: derrick.mckee at gmail.com (Derrick McKee)
Date: Fri, 30 Apr 2021 10:40:04 -0400
Subject: PAC key changes when kernel code is preempted
Message-ID: <CAJoBWHxHqUY427-62=YtGDtnGrcSyOXiKTF=A+Vswbt0K_7c+w@mail.gmail.com>

Hi,

I am noticing that when kernel code is preempted, PAC keys seem to
change when resuming execution.  For instance, when I read
APDAKeyHi_EL1 and APDAKeyLo_EL1, sleep, and read them again, the
values are different.  Is this the intended behavior?  If so, how can
I ensure that the keys do not change?  The different keys are causing
PAC authentication to fail on pointers signed using the stale key.
Thanks.

--
Derrick McKee
Email: derrick.mckee at gmail.com


From sdonthineni at nvidia.com  Fri Apr 30 15:58:14 2021
From: sdonthineni at nvidia.com (Shanker R Donthineni)
Date: Fri, 30 Apr 2021 09:58:14 -0500
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <87czucngdc.wl-maz@kernel.org>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
Message-ID: <1edb2c4e-23f0-5730-245b-fc6d289951e1@nvidia.com>

Hi Marc,

On 4/30/21 6:47 AM, Marc Zyngier wrote:
>
>>>> We've two concerns here:
>>>>    - Performance impacts for pass-through devices.
>>>>    - The definition of ioremap_wc() function doesn't match the host
>>>> kernel on ARM64
>>> Performance I can understand, but I think you're also using it to mask
>>> a driver bug which should be resolved first.  Thank
>> We?ve already instrumented the driver code and found the code path
>> for the unaligned accesses. We?ll fix this issue if it?s not
>> following WC semantics.
>>
>> Fixing the performance concern will be under KVM stage-2 page-table
>> control. We're looking for a guidance/solution for updating stage-2
>> PTE based on PCI-BAR attribute.
> Before we start discussing the *how*, I'd like to clearly understand
> what *arm64* memory attributes you are relying on. We already have
> established that the unaligned access was a bug, which was the biggest
> argument in favour of NORMAL_NC. What are the other requirements?
Sorry, my earlier response was not complete...

ARMv8 architecture has two features Gathering and Reorder transactions, very
important from a performance point of view. Small inline packets for NIC cards
and accesses to GPU's frame buffer are CPU-bound operations. We want to take
advantages of GRE features to achieve higher performance.

Both these features are disabled for prefetchable BARs in VM because memory-type
MT_DEVICE_nGnRE enforced in stage-2.
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.



From robh at kernel.org  Fri Apr 30 16:04:22 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 10:04:22 -0500
Subject: [PATCH 4/5] dt-bindings: phy: qcom, qmp: Add IPQ60xx PCIe PHY
 bindings
In-Reply-To: <f787ca496eae2a0d5ff4f17655eaff9f39a14321.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
 <f787ca496eae2a0d5ff4f17655eaff9f39a14321.1618916235.git.baruch@tkos.co.il>
Message-ID: <20210430150422.GA3321286@robh.at.kernel.org>

On Tue, 20 Apr 2021 14:21:39 +0300, Baruch Siach wrote:
> Add ipq6018 qmp phy device for the single PCIe serdes lane on IPQ60xx
> SoCs.
> 
> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> ---
>  .../devicetree/bindings/phy/qcom,qmp-phy.yaml | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From mark.rutland at arm.com  Fri Apr 30 16:04:38 2021
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 30 Apr 2021 16:04:38 +0100
Subject: PAC key changes when kernel code is preempted
In-Reply-To: <CAJoBWHxHqUY427-62=YtGDtnGrcSyOXiKTF=A+Vswbt0K_7c+w@mail.gmail.com>
References: <CAJoBWHxHqUY427-62=YtGDtnGrcSyOXiKTF=A+Vswbt0K_7c+w@mail.gmail.com>
Message-ID: <20210430150438.GA57205@C02TD0UTHF1T.local>

On Fri, Apr 30, 2021 at 10:40:04AM -0400, Derrick McKee wrote:
> Hi,
> 
> I am noticing that when kernel code is preempted, PAC keys seem to
> change when resuming execution.  For instance, when I read
> APDAKeyHi_EL1 and APDAKeyLo_EL1, sleep, and read them again, the
> values are different.  Is this the intended behavior? 

This is expected; kernel-side we only use the IA keys (which should stay
the same from a kernel task's PoV), and the other keys (IB, DA, DB, GA)
are not supposed to be used within the kernel.

Up to and including v5.12, the other keys are switched at entry to/from
userspace, and so may change from the PoV of a kernel thread across
preemption.

With the patches merged for v5.13, the other keys will be
switched with the task, but userspace can reset these at any time, and
they are still not supposed to be used within the kernel.

> If so, how can I ensure that the keys do not change?  The different
> keys are causing PAC authentication to fail on pointers signed using
> the stale key.  Thanks.

I take it this is non-mainline code? We shouldn't be using the other
keys today.

If you want to use the other keys, you'll need to alter the
context-switch and userspace entry/exit logic to have kernel versions of
the other keys, and switch them at the same points we switch the IA
keys. 

For reference, see commit:

  b90e483938ce387c ("arm64: pac: Optimize kernel entry/exit key installation code paths")

Thank,
Mark.


From robh at kernel.org  Fri Apr 30 16:05:25 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 10:05:25 -0500
Subject: [PATCH 5/5] dt-bindings: pci: qcom: Document PCIe bindings for
 IPQ6018 SoC
In-Reply-To: <e285d5041b8c19d4a7fab4d1a3ce9dd2b487cbad.1618916235.git.baruch@tkos.co.il>
References: <cover.1618916235.git.baruch@tkos.co.il>
 <e285d5041b8c19d4a7fab4d1a3ce9dd2b487cbad.1618916235.git.baruch@tkos.co.il>
Message-ID: <20210430150525.GA3323075@robh.at.kernel.org>

On Tue, 20 Apr 2021 14:21:40 +0300, Baruch Siach wrote:
> Document qcom,pcie-ipq6018. This is similar to the ipq8074 with a few
> different clock sources, and one additional reset.
> 
> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> ---
>  .../devicetree/bindings/pci/qcom,pcie.txt     | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From maz at kernel.org  Fri Apr 30 16:07:22 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 30 Apr 2021 16:07:22 +0100
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <7c685ae6-938b-9d99-20e6-f51398543441@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
 <7c685ae6-938b-9d99-20e6-f51398543441@nvidia.com>
Message-ID: <87a6pfolp1.wl-maz@kernel.org>

On Fri, 30 Apr 2021 14:07:46 +0100,
Shanker R Donthineni <sdonthineni at nvidia.com> wrote:
> 
> 
> Hi Marc,
> 
> On 4/30/21 6:47 AM, Marc Zyngi
> >>>> We've two concerns here:
> >>>>    - Performance impacts for pass-through devices.
> >>>>    - The definition of ioremap_wc() function doesn't match the host
> >>>> kernel on ARM64
> >>> Performance I can understand, but I think you're also using it to mask
> >>> a driver bug which should be resolved first.  Thank
> >> We?ve already instrumented the driver code and found the code path
> >> for the unaligned accesses. We?ll fix this issue if it?s not
> >> following WC semantics.
> >>
> >> Fixing the performance concern will be under KVM stage-2 page-table
> >> control. We're looking for a guidance/solution for updating stage-2
> >> PTE based on PCI-BAR attribute.
> > Before we start discussing the *how*, I'd like to clearly understand
> > what *arm64* memory attributes you are relying on. We already have
> > established that the unaligned access was a bug, which was the biggest
> > argument in favour of NORMAL_NC. What are the other requirements?
> >
> We are? relying? on NORMAL_NC mapping for PCI prefetchable BARs
> instead of DEVICE_nGnRE in baremetal and VM.  No other requirement
> other than this.

That wasn't really my question. What properties do you require for
this assigned MMIO window outside of unaligned accesses? Or to put it
another way, what goes wrong with any of the other device types?

	M.

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


From rdunlap at infradead.org  Fri Apr 30 16:13:12 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 30 Apr 2021 08:13:12 -0700
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <20210430095308.14465-1-o.rempel@pengutronix.de>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
Message-ID: <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>

On 4/30/21 2:53 AM, Oleksij Rempel wrote:
> Some systems may need to disable selftests to reduce kernel size or for
> some policy reasons. This patch provide option to disable generic selftests.
> 
> Reported-by: Geert Uytterhoeven <geert at linux-m68k.org>
> Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> ---
>  net/Kconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/net/Kconfig b/net/Kconfig
> index f5ee7c65e6b4..dac98c73fcd8 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -431,7 +431,12 @@ config SOCK_VALIDATE_XMIT
>  
>  config NET_SELFTESTS
>  	def_tristate PHYLIB
> +	prompt "Support for generic selftests"
>  	depends on PHYLIB && INET
> +	help
> +	  These selftests are build automatically if any driver with generic

	                      built

> +	  selftests support is enabled. This option can be used to disable
> +	  selftests to reduce kernel size.
>  
>  config NET_SOCK_MSG
>  	bool
> 

Thanks for the patch/option. But I think it should just default to n,
not PHYLIB.

-- 
~Randy



From jim2101024 at gmail.com  Fri Apr 30 16:21:53 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Fri, 30 Apr 2021 11:21:53 -0400
Subject: [PATCH v6 0/3] ata: ahci_brcm: Fix use of BCM7216 reset controller
Message-ID: <20210430152156.21162-1-jim2101024@gmail.com>

v6 -- Added new commit which adds a missing function to the reset API.
      This fixes 557acb3d2cd9 and should be destined for linux stable.

v5 -- Improved (I hope) commit description (Bjorn).
   -- Rnamed error labels (Krzyszt).
   -- Fixed typos.

v4 -- does not rely on a pending commit, unlike v3.

v3 -- discard commit from v2; instead rely on the new function
      reset_control_rearm provided in a recent commit [1] applied
      to reset/next.
   -- New commit to correct pcie-brcmstb.c usage of a reset controller
      to use reset/rearm verses deassert/assert.

v2 -- refactor rescal-reset driver to implement assert/deassert rather than
      reset because the reset call only fires once per lifetime and we need
      to reset after every resume from S2 or S3.
   -- Split the use of "ahci" and "rescal" controllers in separate fields
      to keep things simple.

v1 -- original

Jim Quinlan (3):
  reset: add missing empty function reset_control_rearm()
  ata: ahci_brcm: Fix use of BCM7216 reset controller
  PCI: brcmstb: Use reset/rearm instead of deassert/assert

 drivers/ata/ahci_brcm.c               | 46 +++++++++++++--------------
 drivers/pci/controller/pcie-brcmstb.c | 19 +++++++----
 include/linux/reset.h                 |  5 +++
 3 files changed, 41 insertions(+), 29 deletions(-)

-- 
2.17.1



From jim2101024 at gmail.com  Fri Apr 30 16:21:56 2021
From: jim2101024 at gmail.com (Jim Quinlan)
Date: Fri, 30 Apr 2021 11:21:56 -0400
Subject: [PATCH v6 3/3] PCI: brcmstb: Use reset/rearm instead of
 deassert/assert
In-Reply-To: <20210430152156.21162-1-jim2101024@gmail.com>
References: <20210430152156.21162-1-jim2101024@gmail.com>
Message-ID: <20210430152156.21162-4-jim2101024@gmail.com>

The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips.
The "rescal" implements a "pulse reset" so using assert/deassert is wrong
for this device.  Instead, we use reset/rearm.  We need to use rearm so
that we can reset it after a suspend/resume cycle; w/o using "rearm", the
"rescal" device will only ever fire once.

Of course for suspend/resume to work we also need to put the reset/rearm
calls in the suspend and resume routines.

Fixes: 740d6c3708a9 ("PCI: brcmstb: Add control of rescal reset")
Signed-off-by: Jim Quinlan <jim2101024 at gmail.com>
Acked-by: Florian Fainelli <f.fainelli at gmail.com>
---
 drivers/pci/controller/pcie-brcmstb.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index e330e6811f0b..3b35d629035e 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1148,6 +1148,7 @@ static int brcm_pcie_suspend(struct device *dev)
 
 	brcm_pcie_turn_off(pcie);
 	ret = brcm_phy_stop(pcie);
+	reset_control_rearm(pcie->rescal);
 	clk_disable_unprepare(pcie->clk);
 
 	return ret;
@@ -1163,9 +1164,13 @@ static int brcm_pcie_resume(struct device *dev)
 	base = pcie->base;
 	clk_prepare_enable(pcie->clk);
 
+	ret = reset_control_reset(pcie->rescal);
+	if (ret)
+		goto err_disable_clk;
+
 	ret = brcm_phy_start(pcie);
 	if (ret)
-		goto err;
+		goto err_reset;
 
 	/* Take bridge out of reset so we can access the SERDES reg */
 	pcie->bridge_sw_init_set(pcie, 0);
@@ -1180,14 +1185,16 @@ static int brcm_pcie_resume(struct device *dev)
 
 	ret = brcm_pcie_setup(pcie);
 	if (ret)
-		goto err;
+		goto err_reset;
 
 	if (pcie->msi)
 		brcm_msi_set_regs(pcie->msi);
 
 	return 0;
 
-err:
+err_reset:
+	reset_control_rearm(pcie->rescal);
+err_disable_clk:
 	clk_disable_unprepare(pcie->clk);
 	return ret;
 }
@@ -1197,7 +1204,7 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
 	brcm_msi_remove(pcie);
 	brcm_pcie_turn_off(pcie);
 	brcm_phy_stop(pcie);
-	reset_control_assert(pcie->rescal);
+	reset_control_rearm(pcie->rescal);
 	clk_disable_unprepare(pcie->clk);
 }
 
@@ -1278,13 +1285,13 @@ static int brcm_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(pcie->perst_reset);
 	}
 
-	ret = reset_control_deassert(pcie->rescal);
+	ret = reset_control_reset(pcie->rescal);
 	if (ret)
 		dev_err(&pdev->dev, "failed to deassert 'rescal'\n");
 
 	ret = brcm_phy_start(pcie);
 	if (ret) {
-		reset_control_assert(pcie->rescal);
+		reset_control_rearm(pcie->rescal);
 		clk_disable_unprepare(pcie->clk);
 		return ret;
 	}
-- 
2.17.1



From robh at kernel.org  Fri Apr 30 16:24:53 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 10:24:53 -0500
Subject: [PATCH v4 1/4] dt-bindings: firmware: Add bindings for xilinx
 firmware
In-Reply-To: <20210429140408.23194-2-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
 <20210429140408.23194-2-nava.manne@xilinx.com>
Message-ID: <1619796293.713078.3353969.nullmailer@robh.at.kernel.org>

On Thu, 29 Apr 2021 19:34:05 +0530, Nava kishore Manne wrote:
> Add documentation to describe Xilinx firmware driver bindings.
> Firmware driver provides an interface to firmware APIs.
> Interface APIs can be used by any driver to communicate
> to Platform Management Unit.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
> Changes for v4:
>                 -Added new yaml file for xilinx firmware
>                  as suggested by Rob.
> 
>  .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 63 +++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.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/linux-dt-review/Documentation/devicetree/bindings/clock/xlnx,versal-clk.example.dt.yaml: zynqmp-firmware: 'clock-controller' does not match any of the regexes: 'fpga', 'pinctrl-[0-9]+'
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/crypto/xlnx,zynqmp-aes.example.dt.yaml: zynqmp-firmware: 'zynqmp-aes' does not match any of the regexes: 'fpga', 'pinctrl-[0-9]+'
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.example.dt.yaml:0:0: /example-0/versal-firmware/fpga: failed to match any schema with compatible: ['xlnx,versal-fpga']

See https://patchwork.ozlabs.org/patch/1471741

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Fri Apr 30 16:24:53 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 10:24:53 -0500
Subject: [PATCH 2/3] dt-bindings: arm: amlogic: add Banana PI M5 bindings
In-Reply-To: <20210429170404.3616111-3-narmstrong@baylibre.com>
References: <20210429170404.3616111-1-narmstrong@baylibre.com>
 <20210429170404.3616111-3-narmstrong@baylibre.com>
Message-ID: <1619796293.730307.3353972.nullmailer@robh.at.kernel.org>

On Thu, 29 Apr 2021 19:04:03 +0200, Neil Armstrong wrote:
> Add bindings for the Banana PI M5 board.
> 
> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

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/amlogic.yaml:167:1: [error] syntax error: found character '\t' that cannot start any token (syntax)

dtschema/dtc warnings/errors:
make[1]: *** Deleting file 'Documentation/devicetree/bindings/arm/amlogic.example.dts'
Traceback (most recent call last):
  File "/usr/local/bin/dt-extract-example", line 45, in <module>
    binding = yaml.load(open(args.yamlfile, encoding='utf-8').read())
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 421, in load
    return constructor.get_single_data()
  File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 109, in get_single_data
    node = self.composer.get_single_node()
  File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node
  File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 773, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 850, in _ruamel_yaml.CParser._compose_sequence_node
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 773, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 850, in _ruamel_yaml.CParser._compose_sequence_node
  File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 889, in _ruamel_yaml.CParser._compose_mapping_node
  File "_ruamel_yaml.pyx", line 731, in _ruamel_yaml.CParser._compose_node
  File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event
ruamel.yaml.scanner.ScannerError: while scanning for the next token
found character that cannot start any token
  in "<unicode string>", line 167, column 1
make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/arm/amlogic.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
./Documentation/devicetree/bindings/arm/amlogic.yaml:  while scanning for the next token
found character that cannot start any token
  in "<unicode string>", line 167, column 1
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/arm/amlogic.yaml: ignoring, error parsing file
warning: no schema found in file: ./Documentation/devicetree/bindings/arm/amlogic.yaml
make: *** [Makefile:1414: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1471788

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From robh at kernel.org  Fri Apr 30 16:24:53 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 10:24:53 -0500
Subject: [PATCH v2 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3
 glue
In-Reply-To: <20210430031912.42252-2-samuel@sholland.org>
References: <20210430031912.42252-1-samuel@sholland.org>
 <20210430031912.42252-2-samuel@sholland.org>
Message-ID: <1619796293.743748.3353974.nullmailer@robh.at.kernel.org>

On Thu, 29 Apr 2021 22:19:11 -0500, Samuel Holland wrote:
> The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
> USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
> Represent this by attaching the reset line to a glue layer device.
> 
> Signed-off-by: Samuel Holland <samuel at sholland.org>
> ---
>  .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
>  1 file changed, 75 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.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/usb/allwinner,sun50i-h6-dwc3.example.dts:23.27-50.11: Warning (unit_address_vs_reg): /example-0/usb at 5200000: node has a unit name, but no reg or ranges property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.example.dt.yaml: usb at 5200000: usb at 5200000:phy-names:0: 'usb2-phy' was expected
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.example.dt.yaml: usb at 5200000: phy-names:0: 'usb2-phy' was expected
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml

See https://patchwork.ozlabs.org/patch/1471948

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

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.



From roman.beranek at prusa3d.cz  Fri Apr 30 16:10:03 2021
From: roman.beranek at prusa3d.cz (Roman Beranek)
Date: Fri, 30 Apr 2021 17:10:03 +0200
Subject: [PATCH] pwm: sun4i: Round delay time up to a nearest jiffy
In-Reply-To: <20210430095101.rjkdukf67h2k4iea@pengutronix.de>
Message-ID: <CB15JRQIWROB.2MRNYCPGI20C6@zen.local>

Hello Uwe,

On Fri Apr 30, 2021 at 11:51 AM CEST, Uwe Kleine-K?nig wrote:
> If you agree that dropping both delay and clk_disable completely is the
> right thing, you address both problems and going forward with your patch
> isn't sensible.

I had my doubts whether simply clearing the PWMx_EN bit would be enough
to turn the PWM off but I stand corrected. It does work.

The added bonusu is that once without the invocations of {u,m}sleep and
clk_{enable_,disable_un}prepare, the sun4i_pwm_apply function finally
becomes safe for running in an atomic context.

I will therefore prepare a new patch and come back some time next week.

Have a great weekend,
Roman


From maz at kernel.org  Fri Apr 30 16:31:02 2021
From: maz at kernel.org (Marc Zyngier)
Date: Fri, 30 Apr 2021 16:31:02 +0100
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <1edb2c4e-23f0-5730-245b-fc6d289951e1@nvidia.com>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
 <1edb2c4e-23f0-5730-245b-fc6d289951e1@nvidia.com>
Message-ID: <878s4zokll.wl-maz@kernel.org>

On Fri, 30 Apr 2021 15:58:14 +0100,
Shanker R Donthineni <sdonthineni at nvidia.com> wrote:
> 
> Hi Marc,
> 
> On 4/30/21 6:47 AM, Marc Zyngier wrote:
> >
> >>>> We've two concerns here:
> >>>>    - Performance impacts for pass-through devices.
> >>>>    - The definition of ioremap_wc() function doesn't match the host
> >>>> kernel on ARM64
> >>> Performance I can understand, but I think you're also using it to mask
> >>> a driver bug which should be resolved first.  Thank
> >> We?ve already instrumented the driver code and found the code path
> >> for the unaligned accesses. We?ll fix this issue if it?s not
> >> following WC semantics.
> >>
> >> Fixing the performance concern will be under KVM stage-2 page-table
> >> control. We're looking for a guidance/solution for updating stage-2
> >> PTE based on PCI-BAR attribute.
> > Before we start discussing the *how*, I'd like to clearly understand
> > what *arm64* memory attributes you are relying on. We already have
> > established that the unaligned access was a bug, which was the biggest
> > argument in favour of NORMAL_NC. What are the other requirements?
> Sorry, my earlier response was not complete...
> 
> ARMv8 architecture has two features Gathering and Reorder
> transactions, very important from a performance point of view. Small
> inline packets for NIC cards and accesses to GPU's frame buffer are
> CPU-bound operations. We want to take advantages of GRE features to
> achieve higher performance.
> 
> Both these features are disabled for prefetchable BARs in VM because
> memory-type MT_DEVICE_nGnRE enforced in stage-2.

Right, so Normal_NC is a red herring, and it is Device_GRE that you
really are after, right?

Now, I'm not convinced that we can do that directly from vfio in a
device-agnostic manner. It is userspace that places the device in the
guest's memory, and I have the ugly feeling that userspace needs to be
in control of memory attributes.

Otherwise, we change the behaviour for all existing devices that have
prefetchable BARs, and I don't think that's an acceptable move
(userspace ABI change).

	M.

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


From o.rempel at pengutronix.de  Fri Apr 30 16:41:53 2021
From: o.rempel at pengutronix.de (Oleksij Rempel)
Date: Fri, 30 Apr 2021 17:41:53 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
 <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
Message-ID: <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>

On Fri, Apr 30, 2021 at 08:13:12AM -0700, Randy Dunlap wrote:
> On 4/30/21 2:53 AM, Oleksij Rempel wrote:
> > Some systems may need to disable selftests to reduce kernel size or for
> > some policy reasons. This patch provide option to disable generic selftests.
> > 
> > Reported-by: Geert Uytterhoeven <geert at linux-m68k.org>
> > Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> > Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> > ---
> >  net/Kconfig | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/net/Kconfig b/net/Kconfig
> > index f5ee7c65e6b4..dac98c73fcd8 100644
> > --- a/net/Kconfig
> > +++ b/net/Kconfig
> > @@ -431,7 +431,12 @@ config SOCK_VALIDATE_XMIT
> >  
> >  config NET_SELFTESTS
> >  	def_tristate PHYLIB
> > +	prompt "Support for generic selftests"
> >  	depends on PHYLIB && INET
> > +	help
> > +	  These selftests are build automatically if any driver with generic
> 
> 	                      built
> 
> > +	  selftests support is enabled. This option can be used to disable
> > +	  selftests to reduce kernel size.
> >  
> >  config NET_SOCK_MSG
> >  	bool
> > 
> 
> Thanks for the patch/option. But I think it should just default to n,
> not PHYLIB.

It should be enabled by default for every device supporting this kind of
selftests. This tests extend functionality of cable tests, which are not
optional. Disabling it by default makes even less sense, at least for
me.

It depends on PHYLIB, if PHYLIB is build as module, this
this part should be build as module too. And since Geert asking to make
it optional, I provided this patch.

Regards,
Oleksij
-- 
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 ameynarkhede03 at gmail.com  Fri Apr 30 16:54:29 2021
From: ameynarkhede03 at gmail.com (Amey Narkhede)
Date: Fri, 30 Apr 2021 21:24:29 +0530
Subject: [PATCH v2] PCI: mediatek: Check return value of clk_prepare_enable
Message-ID: <20210430155429.35034-1-ameynarkhede03@gmail.com>

In case when free_ck clock is not enabled during device resume
check the return value of clk_prepare_enable() and return the
error after printing it.

Signed-off-by: Amey Narkhede <ameynarkhede03 at gmail.com>
---
Changes in v2:
	- Print the error before returning
	- Clarify commit log
 drivers/pci/controller/pcie-mediatek.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 23548b517..9bdae34cc 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -1154,11 +1154,16 @@ static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
 {
 	struct mtk_pcie *pcie = dev_get_drvdata(dev);
 	struct mtk_pcie_port *port, *tmp;
+	int ret;

 	if (list_empty(&pcie->ports))
 		return 0;

-	clk_prepare_enable(pcie->free_ck);
+	ret = clk_prepare_enable(pcie->free_ck);
+	if (ret) {
+		dev_err(dev, "Failed to enable free_ck clock\n");
+		return ret;
+	}

 	list_for_each_entry_safe(port, tmp, &pcie->ports, list)
 		mtk_pcie_enable_port(port);
--
2.31.1


From broonie at kernel.org  Fri Apr 30 16:56:23 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 30 Apr 2021 16:56:23 +0100
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <28acedfd-6cd5-a8ad-0182-e61c3c30c27d@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
 <20210426162610.erpt5ubeddx7paeq@ti.com>
 <20210426165118.GH4590@sirena.org.uk>
 <28acedfd-6cd5-a8ad-0182-e61c3c30c27d@foss.st.com>
Message-ID: <20210430155623.GD5981@sirena.org.uk>

On Fri, Apr 30, 2021 at 04:22:34PM +0200, Patrice CHOTARD wrote:
> On 4/26/21 6:51 PM, Mark Brown wrote:
> > On Mon, Apr 26, 2021 at 09:56:12PM +0530, Pratyush Yadav wrote:

> > Is it possible there's some situation where you're waiting for some bits
> > to clear as well?

> Yes, we are waiting STATUS_BUSY bit to be cleared, see patch 2 which is making 
> usage of this API.

Then the inverse question applies - is there no circumstance where we
might be waiting for a bit to be set?

> > We already have the core handling other timeouts.  We don't pass around
> > completions but rather have an API function that the driver has to call
> > when the operation completes, a similar pattern might work here.  Part

> So, if i correctly understood, you make allusion to what is already done
> in SPI core framework with spi_finalize_current_transfer() right ?

Yes, and _current_message().

> > of the thing with those APIs which I'm missing here is that this will
> > just return -EOPNOTSUPP if the driver can't do the delay in hardware, I
> > think it would be cleaner if this API were similar and the core dealt
> > with doing the delay/poll on the CPU.  That way the users don't need to
> > repeat the handling for the offload/non-offload cases.

> Sorry, i didn't catch what you mean here. In PATCH 2, that's the case,
> if spi_mem_poll_status() is not supported, the core is dealing with 
> the delay/poll on the CPU in spinand_wait().

That's in the NAND core, not in spi-mem.  Any other users of spi-mem
will also need to open code stuff.
-------------- 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/20210430/8793587d/attachment.sig>

From Jonathan.Cameron at Huawei.com  Fri Apr 30 17:13:47 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 17:13:47 +0100
Subject: [PATCH v4 08/79] media: atmel: properly get pm_runtime
In-Reply-To: <3150349be99187c4f9290ac35d6227bb6a83519b.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <3150349be99187c4f9290ac35d6227bb6a83519b.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430171347.00004e7b@Huawei.com>

On Wed, 28 Apr 2021 16:51:29 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> There are several issues in the way the atmel driver handles
> pm_runtime_get_sync():
> 
> - it doesn't check return codes;
> - it doesn't properly decrement the usage_count on all places;
> - it starts streaming even if pm_runtime_get_sync() fails.
> - while it tries to get pm_runtime at the clock enable logic,
>   it doesn't check if the operation was suceeded.
> 
> Replace all occurrences of it to use the new kAPI:
> pm_runtime_resume_and_get(), which ensures that, if the
> return code is not negative, the usage_count was incremented.
> 
> With that, add additional checks when this is called, in order
> to ensure that errors will be properly addressed.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/atmel/atmel-isc-base.c | 27 ++++++++++++++-----
>  drivers/media/platform/atmel/atmel-isi.c      | 19 ++++++++++---
>  2 files changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c
> index fe3ec8d0eaee..02543fe42e9d 100644
> --- a/drivers/media/platform/atmel/atmel-isc-base.c
> +++ b/drivers/media/platform/atmel/atmel-isc-base.c
> @@ -294,9 +294,13 @@ static int isc_wait_clk_stable(struct clk_hw *hw)
>  static int isc_clk_prepare(struct clk_hw *hw)
>  {
>  	struct isc_clk *isc_clk = to_isc_clk(hw);
> +	int ret;
>  
> -	if (isc_clk->id == ISC_ISPCK)
> -		pm_runtime_get_sync(isc_clk->dev);
> +	if (isc_clk->id == ISC_ISPCK) {
> +		ret = pm_runtime_resume_and_get(isc_clk->dev);
> +		if (ret < 0)
> +			return 0;

Why not the error?  isc_wait_clk_stable() is happy to return -ETIMEDOUT so I
assume the callers should fine with errors.

> +	}
>  
>  	return isc_wait_clk_stable(hw);
>  }
> @@ -353,9 +357,13 @@ static int isc_clk_is_enabled(struct clk_hw *hw)
>  {
>  	struct isc_clk *isc_clk = to_isc_clk(hw);
>  	u32 status;
> +	int ret;
>  
> -	if (isc_clk->id == ISC_ISPCK)
> -		pm_runtime_get_sync(isc_clk->dev);
> +	if (isc_clk->id == ISC_ISPCK) {
> +		ret = pm_runtime_resume_and_get(isc_clk->dev);
> +		if (ret < 0)
> +			return 0;
> +	}
>  
>  	regmap_read(isc_clk->regmap, ISC_CLKSR, &status);
>  
> @@ -807,7 +815,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>  		goto err_start_stream;
>  	}
>  
> -	pm_runtime_get_sync(isc->dev);
> +	ret = pm_runtime_resume_and_get(isc->dev);
> +	if (ret < 0)
> +		goto err_pm_get;
>  
>  	ret = isc_configure(isc);
>  	if (unlikely(ret))
> @@ -838,7 +848,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>  
>  err_configure:
>  	pm_runtime_put_sync(isc->dev);
> -
> +err_pm_get:
>  	v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
>  
>  err_start_stream:
> @@ -1809,6 +1819,7 @@ static void isc_awb_work(struct work_struct *w)
>  	u32 baysel;
>  	unsigned long flags;
>  	u32 min, max;
> +	int ret;
>  
>  	/* streaming is not active anymore */
>  	if (isc->stop)
> @@ -1831,7 +1842,9 @@ static void isc_awb_work(struct work_struct *w)
>  	ctrls->hist_id = hist_id;
>  	baysel = isc->config.sd_format->cfa_baycfg << ISC_HIS_CFG_BAYSEL_SHIFT;
>  
> -	pm_runtime_get_sync(isc->dev);
> +	ret = pm_runtime_resume_and_get(isc->dev);
> +	if (ret < 0)

Maybe warn or similar?

> +		return;
>  
>  	/*
>  	 * only update if we have all the required histograms and controls
> diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
> index 0514be6153df..6a433926726d 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -422,7 +422,9 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
>  	struct frame_buffer *buf, *node;
>  	int ret;
>  
> -	pm_runtime_get_sync(isi->dev);
> +	ret = pm_runtime_resume_and_get(isi->dev);
> +	if (ret < 0)
> +		return ret;
>  
>  	/* Enable stream on the sub device */
>  	ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
> @@ -782,9 +784,10 @@ static int isi_enum_frameintervals(struct file *file, void *fh,
>  	return 0;
>  }
>  
> -static void isi_camera_set_bus_param(struct atmel_isi *isi)
> +static int isi_camera_set_bus_param(struct atmel_isi *isi)
>  {
>  	u32 cfg1 = 0;
> +	int ret;
>  
>  	/* set bus param for ISI */
>  	if (isi->pdata.hsync_act_low)
> @@ -801,12 +804,16 @@ static void isi_camera_set_bus_param(struct atmel_isi *isi)
>  	cfg1 |= ISI_CFG1_THMASK_BEATS_16;
>  
>  	/* Enable PM and peripheral clock before operate isi registers */
> -	pm_runtime_get_sync(isi->dev);
> +	ret = pm_runtime_resume_and_get(isi->dev);
> +	if (ret < 0)
> +		return ret;
>  
>  	isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
>  	isi_writel(isi, ISI_CFG1, cfg1);
>  
>  	pm_runtime_put(isi->dev);
> +
> +	return 0;
>  }
>  
>  /* -----------------------------------------------------------------------*/
> @@ -1085,7 +1092,11 @@ static int isi_graph_notify_complete(struct v4l2_async_notifier *notifier)
>  		dev_err(isi->dev, "No supported mediabus format found\n");
>  		return ret;
>  	}
> -	isi_camera_set_bus_param(isi);
> +	ret = isi_camera_set_bus_param(isi);
> +	if (ret) {
> +		dev_err(isi->dev, "Can't wake up device\n");
> +		return ret;
> +	}
>  
>  	ret = isi_set_default_fmt(isi);
>  	if (ret) {



From dev at pascalroeleven.nl  Fri Apr 30 17:18:27 2021
From: dev at pascalroeleven.nl (dev at pascalroeleven.nl)
Date: Fri, 30 Apr 2021 18:18:27 +0200
Subject: [linux-sunxi] Re: [PATCH] pwm: sun4i: Round delay time up to a
 nearest jiffy
In-Reply-To: <CB15JRQIWROB.2MRNYCPGI20C6@zen.local>
References: <CB15JRQIWROB.2MRNYCPGI20C6@zen.local>
Message-ID: <6f65c35761a96443532347586494471c@pascalroeleven.nl>

On 2021-04-30 17:10, Roman Beranek wrote:
> Hello Uwe,
> 
> On Fri Apr 30, 2021 at 11:51 AM CEST, Uwe Kleine-K?nig wrote:
>> If you agree that dropping both delay and clk_disable completely is the
>> right thing, you address both problems and going forward with your patch
>> isn't sensible.
> 
> I had my doubts whether simply clearing the PWMx_EN bit would be enough
> to turn the PWM off but I stand corrected. It does work.
> 
> The added bonusu is that once without the invocations of {u,m}sleep and
> clk_{enable_,disable_un}prepare, the sun4i_pwm_apply function finally
> becomes safe for running in an atomic context.
> 
> I will therefore prepare a new patch and come back some time next week.
> 
> Have a great weekend,
> Roman

Hi Roman,

A while ago others and I have made an attempt at fixing this as well.
Before you continue, I'd like to draw your attention to these previous
attempts. Maybe in the mean time things have changed, maybe they
haven't, but I can definitely tell you that just clearing the enable bit
isn't enough. There is some precise timing involved, hence the delays
are there. Unfortunately to my knowledge, this hasn't been documented
anywhere so it's just trial and error.

Please take a look at this post: https://lkml.org/lkml/2020/3/17/1158

Good luck!

Regards,
Pascal



From andrew at lunn.ch  Fri Apr 30 17:23:23 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 30 Apr 2021 18:23:23 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
 <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
 <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>
Message-ID: <YIwu+4ywaTI4+eUq@lunn.ch>

> > Thanks for the patch/option. But I think it should just default to n,
> > not PHYLIB.
> 
> It should be enabled by default for every device supporting this kind of
> selftests.

I agree.

I still wonder if there is confusion about self test here. Maybe
putting ethtool into the description will help people understand it
has nothing to do with the kernel self test infrastructure and kernel
self testing.

	Andrew


From geert at linux-m68k.org  Fri Apr 30 17:25:35 2021
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Fri, 30 Apr 2021 18:25:35 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
 <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
 <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>
Message-ID: <CAMuHMdWmuCZMCsd8NZqzVaWWP59ZFZpFYds-OpHmEC7OjERLTg@mail.gmail.com>

Hi Oleksij,

On Fri, Apr 30, 2021 at 5:42 PM Oleksij Rempel <o.rempel at pengutronix.de> wrote:
> On Fri, Apr 30, 2021 at 08:13:12AM -0700, Randy Dunlap wrote:
> > On 4/30/21 2:53 AM, Oleksij Rempel wrote:
> > > Some systems may need to disable selftests to reduce kernel size or for
> > > some policy reasons. This patch provide option to disable generic selftests.
> > >
> > > Reported-by: Geert Uytterhoeven <geert at linux-m68k.org>
> > > Fixes: 3e1e58d64c3d ("net: add generic selftest support")
> > > Signed-off-by: Oleksij Rempel <o.rempel at pengutronix.de>
> > > ---
> > >  net/Kconfig | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/net/Kconfig b/net/Kconfig
> > > index f5ee7c65e6b4..dac98c73fcd8 100644
> > > --- a/net/Kconfig
> > > +++ b/net/Kconfig
> > > @@ -431,7 +431,12 @@ config SOCK_VALIDATE_XMIT
> > >
> > >  config NET_SELFTESTS
> > >     def_tristate PHYLIB
> > > +   prompt "Support for generic selftests"
> > >     depends on PHYLIB && INET
> > > +   help
> > > +     These selftests are build automatically if any driver with generic
> >
> >                             built
> >
> > > +     selftests support is enabled. This option can be used to disable
> > > +     selftests to reduce kernel size.
> > >
> > >  config NET_SOCK_MSG
> > >     bool
> > >
> >
> > Thanks for the patch/option. But I think it should just default to n,
> > not PHYLIB.
>
> It should be enabled by default for every device supporting this kind of
> selftests. This tests extend functionality of cable tests, which are not
> optional. Disabling it by default makes even less sense, at least for
> me.

Drivers using it ( AG71XX, FEC, NET_DSA) already select it, right?
Or better, imply it, which assumes it's optional.

> It depends on PHYLIB, if PHYLIB is build as module, this
> this part should be build as module too. And since Geert asking to make
> it optional, I provided this patch.

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 andy.shevchenko at gmail.com  Fri Apr 30 17:29:48 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 30 Apr 2021 19:29:48 +0300
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <YIglWpz8lSidXmDd@smile.fi.intel.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
 <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
 <20210427143457.GI4605@sirena.org.uk> <YIglWpz8lSidXmDd@smile.fi.intel.com>
Message-ID: <CAHp75VfBSjHP1LJZJTdwXzGuE2YjxdW6r7Zf6ofHsquJBPMyWA@mail.gmail.com>

On Tue, Apr 27, 2021 at 5:54 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Tue, Apr 27, 2021 at 03:34:57PM +0100, Mark Brown wrote:
> > On Tue, Apr 27, 2021 at 02:46:02PM +0300, Andy Shevchenko wrote:
> >
> > > Mark, are you accepting patches for v5.14 now, or should I resend
> > > after v5.13-rc1 is out?
> >
> > > (I have few more in my queue :-)
> >
> > Send them now if you like.
>
> Got it!
>
> I think I prefer to produce a less noise in case this series for some reason
> needs to be changed / amended. I'll wait till this series lands in your queue.
>
> P.S. basically my question was about this series.

One item is still unclear to me. I noticed that you started already
applying patches for-next release cycle (if I understood it
correctly). Hence the question should or shouldn't I resend this
series after rc1 is out?
If I shouldn't, do you have any comments on it? If no, can it be applied now?

-- 
With Best Regards,
Andy Shevchenko


From Jonathan.Cameron at Huawei.com  Fri Apr 30 17:30:25 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 17:30:25 +0100
Subject: [PATCH v4 10/79] media: mdk-mdp: fix pm_runtime_get_sync()
 usage count
In-Reply-To: <39851c54046fa0d63f34549803df3388361828b7.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <39851c54046fa0d63f34549803df3388361828b7.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430173025.0000359f@Huawei.com>

On Wed, 28 Apr 2021 16:51:31 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> Replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
> 
> While here, fix the return contition of mtk_mdp_m2m_start_streaming(),
> as it doesn't make any sense to return 0 if the PM runtime failed
> to resume.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

> ---
>  drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index ace4528cdc5e..f14779e7596e 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -391,12 +391,12 @@ static int mtk_mdp_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
>  	struct mtk_mdp_ctx *ctx = q->drv_priv;
>  	int ret;
>  
> -	ret = pm_runtime_get_sync(&ctx->mdp_dev->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&ctx->mdp_dev->pdev->dev);
>  	if (ret < 0)
> -		mtk_mdp_dbg(1, "[%d] pm_runtime_get_sync failed:%d",
> +		mtk_mdp_dbg(1, "[%d] pm_runtime_resume_and_get failed:%d",
>  			    ctx->id, ret);
>  
> -	return 0;
> +	return ret;
>  }
>  
>  static void *mtk_mdp_m2m_buf_remove(struct mtk_mdp_ctx *ctx,



From rdunlap at infradead.org  Fri Apr 30 17:33:42 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 30 Apr 2021 09:33:42 -0700
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <YIwu+4ywaTI4+eUq@lunn.ch>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
 <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
 <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de> <YIwu+4ywaTI4+eUq@lunn.ch>
Message-ID: <6865cd7a-7f2e-13f5-a588-8877d771b834@infradead.org>

On 4/30/21 9:23 AM, Andrew Lunn wrote:
>>> Thanks for the patch/option. But I think it should just default to n,
>>> not PHYLIB.
>>
>> It should be enabled by default for every device supporting this kind of
>> selftests.
> 
> I agree.
> 
> I still wonder if there is confusion about self test here. Maybe

Probably.

> putting ethtool into the description will help people understand it
> has nothing to do with the kernel self test infrastructure and kernel
> self testing.

So it's a hardware check that is required to be run if it's implemented
in a driver?

Required by who/what?

thanks.
-- 
~Randy



From helgaas at kernel.org  Fri Apr 30 17:34:50 2021
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 30 Apr 2021 11:34:50 -0500
Subject: [PATCH][next] PCI: mediatek-gen3: Add missing null pointer check
In-Reply-To: <7a512e3a-2897-ac12-ac6e-06be28735279@wanadoo.fr>
Message-ID: <20210430163450.GA657994@bjorn-Precision-5520>

On Fri, Apr 30, 2021 at 09:47:06AM +0200, Christophe JAILLET wrote:
> Le 29/04/2021 ? 13:00, Colin King a ?crit?:
> > From: Colin Ian King <colin.king at canonical.com>
> > 
> > The call to platform_get_resource_byname can potentially return null, so
> > add a null pointer check to avoid a null pointer dereference issue.
> > 
> > Addresses-Coverity: ("Dereference null return")
> > Fixes: 441903d9e8f0 ("PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192")
> > Signed-off-by: Colin Ian King <colin.king at canonical.com>
> > ---
> >   drivers/pci/controller/pcie-mediatek-gen3.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> > index 20165e4a75b2..3c5b97716d40 100644
> > --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -721,6 +721,8 @@ static int mtk_pcie_parse_port(struct mtk_pcie_port *port)
> >   	int ret;
> >   	regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pcie-mac");
> > +	if (!regs)
> > +		return -EINVAL;
> >   	port->base = devm_ioremap_resource(dev, regs);
> >   	if (IS_ERR(port->base)) {
> >   		dev_err(dev, "failed to map register base\n");
> > 
> 
> Nitpick:
>    Using 'devm_platform_ioremap_resource_byname' is slightly less verbose
> and should please Coverity.

Not a nitpick at all.  Jianjun is correct that devm_ioremap_resource()
does check "regs" for NULL and it fails gracefully before trying to
dereference it, so the extra check shouldn't be needed.  And most
cases in drivers/pci/ look like this, without the extra check:

  res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
  base = devm_ioremap_resource(dev, res);
  if (IS_ERR(base))
    ...

If devm_platform_ioremap_resource_byname() keeps Coverity happy, I
think that's what we should be doing across drivers/pci/.  Coverity
false positives are a hassle.

Seems like something for next cycle since we're in the middle of the
merge window.

> Also, which git repo are you using? On linux-next ([1)], your proposed patch
> is already part of "PCI: mediatek-gen3: Add MediaTek Gen3 driver for
> MT8192".
> 
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/drivers/pci/controller/pcie-mediatek-gen3.c

I think this is because Lorenzo already squashed Colin's change in.

Bjorn


From alain.volmat at foss.st.com  Fri Apr 30 17:44:13 2021
From: alain.volmat at foss.st.com (Alain Volmat)
Date: Fri, 30 Apr 2021 18:44:13 +0200
Subject: [PATCH v3 0/2] i2c: stm32f7: add SMBus-Alert support
In-Reply-To: <1616998145-28278-1-git-send-email-alain.volmat@foss.st.com>
References: <1616998145-28278-1-git-send-email-alain.volmat@foss.st.com>
Message-ID: <20210430164413.GA3426@gnbcxd0016.gnb.st.com>

Hi Wolfram,

Gentle reminder about this serie about SMBus-Alert. Could you have
a look at it ?

Thanks
Alain

On Mon, Mar 29, 2021 at 08:09:03AM +0200, Alain Volmat wrote:
> This serie adds support for SMBus Alert on the STM32F7.
> A new binding st,smbus-alert is added in order to differenciate
> with the existing smbus binding.
> 
> SMBA alert control and status logic must be enabled along with
> SMBALERT# pin configured via pinctrl in the device tree. This is the
> rational for adding "st,smbus-alert" property.
> 
> ---
> v3:
> use lore.kernel.org links instead of marc.info
> 
> v2:
> When SMBUS alert isn't available on the board (SMBA unused), this
> logic musn't be enabled. Enabling it unconditionally wrongly lead to get
> SMBA interrupts.
> So, add "st,smbus-alert" dedicated binding to have a smbus alert with a
> consistent pin configuration in DT.
> 
> Alain Volmat (2):
>   dt-bindings: i2c: stm32f7: add st,smbus-alert binding for SMBus Alert
>   i2c: stm32f7: add SMBus-Alert support
> 
>  .../devicetree/bindings/i2c/st,stm32-i2c.yaml |  5 ++
>  drivers/i2c/busses/i2c-stm32f7.c              | 73 +++++++++++++++++++
>  2 files changed, 78 insertions(+)
> 
> -- 
> 2.17.1
> 


From Jonathan.Cameron at Huawei.com  Fri Apr 30 17:44:13 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 17:44:13 +0100
Subject: [PATCH v4 16/79] media: mtk-vcodec: fix pm_runtime_get_sync()
 usage count
In-Reply-To: <b2f5f6e6287d4b56530dcf51b25b5a1c009381f8.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <b2f5f6e6287d4b56530dcf51b25b5a1c009381f8.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430174413.0000452c@Huawei.com>

On Wed, 28 Apr 2021 16:51:37 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> Replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
Without a return value, this seems like it's not complete as driver
will carry on and eventually call mtk_vcode_dec_pw_off() which will assume
it needs to decrement the count.


> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> index ddee7046ce42..fe096fe61c9d 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> @@ -92,9 +92,9 @@ void mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
>  {
>  	int ret;
>  
> -	ret = pm_runtime_get_sync(pm->dev);
> +	ret = pm_runtime_resume_and_get(pm->dev);
>  	if (ret)
> -		mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
> +		mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
>  }
>  
>  void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)



From msys.mizuma at gmail.com  Fri Apr 30 17:46:16 2021
From: msys.mizuma at gmail.com (Masayoshi Mizuma)
Date: Fri, 30 Apr 2021 12:46:16 -0400
Subject: [PATCH v7 7/9] perf: arm64: Add test for userspace counter
 access on heterogeneous systems
In-Reply-To: <20210420031511.2348977-8-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
 <20210420031511.2348977-8-robh@kernel.org>
Message-ID: <20210430164616.pzb7yxrsugexso25@gabell>

On Mon, Apr 19, 2021 at 10:15:09PM -0500, Rob Herring wrote:
> Userspace counter access only works on heterogeneous systems with some
> restrictions. The userspace process must be pinned to a homogeneous
> subset of CPUs and must open the corresponding PMU for those CPUs. This
> commit adds a test implementing these requirements.
> 
> Signed-off-by: Rob Herring <robh at kernel.org>
> ---
> v6:
>  - Add a check on cap_user_rdpmc
> v5:
>  - Adapt to libperf mmap API changes
> v4:
>  - Update perf_evsel__mmap params
> v2:
>  - Drop all but heterogeneous test as others covered by libperf tests
>  - Rework to use libperf
> ---
>  tools/perf/arch/arm64/include/arch-tests.h |   7 +
>  tools/perf/arch/arm64/tests/Build          |   1 +
>  tools/perf/arch/arm64/tests/arch-tests.c   |   4 +
>  tools/perf/arch/arm64/tests/user-events.c  | 177 +++++++++++++++++++++
>  4 files changed, 189 insertions(+)
>  create mode 100644 tools/perf/arch/arm64/tests/user-events.c
> 
> diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> index 90ec4c8cb880..380ad34a3f09 100644
> --- a/tools/perf/arch/arm64/include/arch-tests.h
> +++ b/tools/perf/arch/arm64/include/arch-tests.h
> @@ -2,11 +2,18 @@
>  #ifndef ARCH_TESTS_H
>  #define ARCH_TESTS_H
>  
> +#include <linux/compiler.h>
> +
>  #ifdef HAVE_DWARF_UNWIND_SUPPORT
>  struct thread;
>  struct perf_sample;
> +int test__arch_unwind_sample(struct perf_sample *sample,
> +			     struct thread *thread);
>  #endif

Hello,

I got the following compile error with aarch64 on Fedora33.

    # make tools/perf
    ...
    In file included from arch/arm64/tests/arch-tests.c:4:
    /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
       10 | int test__arch_unwind_sample(struct perf_sample *sample,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~
    In file included from arch/arm64/tests/arch-tests.c:3:
    /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
      140 | int test__arch_unwind_sample(struct perf_sample *sample,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    make[8]: *** [/root//libperf_v7/tools/build/Makefile.build:97: /root/libperf_v7/tools/perf/arch/arm64/tests/arch-tests.o] Error 1
    make[8]: *** Waiting for unfinished jobs....
    In file included from arch/arm64/tests/user-events.c:13:
    /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
       10 | int test__arch_unwind_sample(struct perf_sample *sample,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~
    In file included from arch/arm64/tests/user-events.c:12:
    /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
      140 | int test__arch_unwind_sample(struct perf_sample *sample,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    ...

The error is gone after the following patch is applied.

---
 tools/perf/arch/arm64/include/arch-tests.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
index ddfa7460e..7ff2e29bd 100644
--- a/tools/perf/arch/arm64/include/arch-tests.h
+++ b/tools/perf/arch/arm64/include/arch-tests.h
@@ -4,13 +4,6 @@
 
 #include <linux/compiler.h>
 
-#ifdef HAVE_DWARF_UNWIND_SUPPORT
-struct thread;
-struct perf_sample;
-int test__arch_unwind_sample(struct perf_sample *sample,
-			     struct thread *thread);
-#endif
-
 extern struct test arch_tests[];
 int test__rd_pinned(struct test __maybe_unused *test,
 		       int __maybe_unused subtest);
-- 

Thanks!
Masa

>  
>  extern struct test arch_tests[];
> +int test__rd_pinned(struct test __maybe_unused *test,
> +		       int __maybe_unused subtest);
> +
>  
>  #endif
> diff --git a/tools/perf/arch/arm64/tests/Build b/tools/perf/arch/arm64/tests/Build
> index a61c06bdb757..3f9a20c17fc6 100644
> --- a/tools/perf/arch/arm64/tests/Build
> +++ b/tools/perf/arch/arm64/tests/Build
> @@ -1,4 +1,5 @@
>  perf-y += regs_load.o
>  perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
>  
> +perf-y += user-events.o
>  perf-y += arch-tests.o
> diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
> index 5b1543c98022..80ce7bd3c16d 100644
> --- a/tools/perf/arch/arm64/tests/arch-tests.c
> +++ b/tools/perf/arch/arm64/tests/arch-tests.c
> @@ -10,6 +10,10 @@ struct test arch_tests[] = {
>  		.func = test__dwarf_unwind,
>  	},
>  #endif
> +	{
> +		.desc = "Pinned CPU user counter access",
> +		.func = test__rd_pinned,
> +	},
>  	{
>  		.func = NULL,
>  	},
> diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
> new file mode 100644
> index 000000000000..c8efc6b369e6
> --- /dev/null
> +++ b/tools/perf/arch/arm64/tests/user-events.c
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <unistd.h>
> +#include <sched.h>
> +#include <cpumap.h>
> +
> +#include <perf/core.h>
> +#include <perf/threadmap.h>
> +#include <perf/evsel.h>
> +
> +#include "pmu.h"
> +#include "debug.h"
> +#include "tests/tests.h"
> +#include "arch-tests.h"
> +
> +static int run_test(struct perf_evsel *evsel)
> +{
> +	int n;
> +	volatile int tmp = 0;
> +	u64 delta, i, loops = 1000;
> +	struct perf_counts_values counts = { .val = 0 };
> +
> +	for (n = 0; n < 6; n++) {
> +		u64 stamp, now;
> +
> +		perf_evsel__read(evsel, 0, 0, &counts);
> +		stamp = counts.val;
> +
> +		for (i = 0; i < loops; i++)
> +			tmp++;
> +
> +		perf_evsel__read(evsel, 0, 0, &counts);
> +		now = counts.val;
> +		loops *= 10;
> +
> +		delta = now - stamp;
> +		pr_debug("%14d: %14llu\n", n, (long long)delta);
> +
> +		if (!delta)
> +			break;
> +	}
> +	return delta ? 0 : -1;
> +}
> +
> +static struct perf_pmu *pmu_for_cpu(int cpu)
> +{
> +	int acpu, idx;
> +	struct perf_pmu *pmu = NULL;
> +
> +	while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> +		if (pmu->is_uncore)
> +			continue;
> +		perf_cpu_map__for_each_cpu(acpu, idx, pmu->cpus)
> +			if (acpu == cpu)
> +				return pmu;
> +	}
> +	return NULL;
> +}
> +
> +static bool pmu_is_homogeneous(void)
> +{
> +	int core_cnt = 0;
> +	struct perf_pmu *pmu = NULL;
> +
> +	while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> +		if (!pmu->is_uncore && !perf_cpu_map__empty(pmu->cpus))
> +			core_cnt++;
> +	}
> +	return core_cnt == 1;
> +}
> +
> +static int libperf_print(enum libperf_print_level level,
> +			 const char *fmt, va_list ap)
> +{
> +	(void)level;
> +	return vfprintf(stderr, fmt, ap);
> +}
> +
> +static struct perf_evsel *perf_init(struct perf_event_attr *attr)
> +{
> +	int err;
> +	struct perf_thread_map *threads;
> +	struct perf_evsel *evsel;
> +	struct perf_event_mmap_page *pc;
> +
> +	libperf_init(libperf_print);
> +
> +	threads = perf_thread_map__new_dummy();
> +	if (!threads) {
> +		pr_err("failed to create threads\n");
> +		return NULL;
> +	}
> +
> +	perf_thread_map__set_pid(threads, 0, 0);
> +
> +	evsel = perf_evsel__new(attr);
> +	if (!evsel) {
> +		pr_err("failed to create evsel\n");
> +		goto out_thread;
> +	}
> +
> +	err = perf_evsel__open(evsel, NULL, threads);
> +	if (err) {
> +		pr_err("failed to open evsel\n");
> +		goto out_open;
> +	}
> +
> +	if (perf_evsel__mmap(evsel, 0)) {
> +		pr_err("failed to mmap evsel\n");
> +		goto out_mmap;
> +	}
> +
> +	pc = perf_evsel__mmap_base(evsel, 0, 0);
> +	if (!pc->cap_user_rdpmc) {
> +		pr_err("userspace access not enabled\n");
> +		goto out_mmap;
> +	}
> +
> +	return evsel;
> +
> +out_mmap:
> +	perf_evsel__close(evsel);
> +out_open:
> +	perf_evsel__delete(evsel);
> +out_thread:
> +	perf_thread_map__put(threads);
> +	return NULL;
> +}
> +
> +int test__rd_pinned(struct test __maybe_unused *test,
> +		    int __maybe_unused subtest)
> +{
> +	int cpu, cputmp, ret = -1;
> +	struct perf_evsel *evsel;
> +	struct perf_event_attr attr = {
> +		.config = 0x8, /* Instruction count */
> +		.config1 = 0, /* 32-bit counter */
> +		.exclude_kernel = 1,
> +	};
> +	cpu_set_t cpu_set;
> +	struct perf_pmu *pmu;
> +
> +	if (pmu_is_homogeneous())
> +		return TEST_SKIP;
> +
> +	cpu = sched_getcpu();
> +	pmu = pmu_for_cpu(cpu);
> +	if (!pmu)
> +		return -1;
> +	attr.type = pmu->type;
> +
> +	CPU_ZERO(&cpu_set);
> +	perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus)
> +		CPU_SET(cpu, &cpu_set);
> +	if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
> +		pr_err("Could not set affinity\n");
> +
> +	evsel = perf_init(&attr);
> +	if (!evsel)
> +		return -1;
> +
> +	perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus) {
> +		CPU_ZERO(&cpu_set);
> +		CPU_SET(cpu, &cpu_set);
> +		if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
> +			pr_err("Could not set affinity\n");
> +
> +		pr_debug("Running on CPU %d\n", cpu);
> +
> +		ret = run_test(evsel);
> +		if (ret)
> +			break;
> +	}
> +
> +	perf_evsel__close(evsel);
> +	perf_evsel__delete(evsel);
> +	return ret;
> +}
> -- 
> 2.27.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From avolmat at me.com  Fri Apr 30 17:48:31 2021
From: avolmat at me.com (Alain Volmat)
Date: Fri, 30 Apr 2021 18:48:31 +0200
Subject: [PATCH v4 0/7] clk: st: embed clock outputs within drivers
In-Reply-To: <20210331201632.24530-1-avolmat@me.com>
References: <20210331201632.24530-1-avolmat@me.com>
Message-ID: <20210430164830.GA6248@gnbcxl0029.gnb.st.com>

Hi,

Gentle reminder about this serie concerning STi platform clock drivers.
Could you have a look at them ?

Thanks.
Alain

On Wed, Mar 31, 2021 at 10:16:25PM +0200, Alain Volmat wrote:
> Most of ST clock drivers used by STi platform are updated in
> order to introduce clock outputs informations within each drivers
> and thus allow to avoid having to rely on clock-output-names properties
> within DT clock nodes.
> For that purpose, drivers are updated to allow handling both modes
> (with or without clock-output-names).
> Once all DT will have been updated, the legacy mode could be removed
> from the drivers.
> This will also allow, once all STi DT will be corrected, to remove the
> of_clk_detect_critical API from clk core code since STi clock drivers
> are the only drivers using this API.
> 
> Alain Volmat (7):
>   clk: st: clkgen-pll: remove unused variable of struct clkgen_pll
>   clk: st: flexgen: embed soc clock outputs within compatible data
>   dt-bindings: clock: st: flexgen: add new introduced compatible
>   clk: st: clkgen-pll: embed soc clock outputs within compatible data
>   dt-bindings: clock: st: clkgen-pll: add new introduced compatible
>   clk: st: clkgen-fsyn: embed soc clock outputs within compatible data
>   dt-bindings: clock: st: clkgen-fsyn: add new introduced compatible
> 
>  .../bindings/clock/st/st,clkgen-pll.txt       |   3 +
>  .../bindings/clock/st/st,flexgen.txt          |  10 +
>  .../bindings/clock/st/st,quadfs.txt           |   3 +
>  drivers/clk/st/clk-flexgen.c                  | 367 +++++++++++++++++-
>  drivers/clk/st/clkgen-fsyn.c                  | 113 +++++-
>  drivers/clk/st/clkgen-pll.c                   | 121 +++++-
>  6 files changed, 576 insertions(+), 41 deletions(-)
> 
> ---
> v4: - add an additional CLK_IS_CRITICAL within flexgen driver
> v3: - removal some useless CLK_IS_CRITICAL and add some comments
>     - only keep clk drivers/binding patches within the serie
> 
> -- 
> 2.17.1
> 


From Jonathan.Cameron at Huawei.com  Fri Apr 30 17:48:38 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 17:48:38 +0100
Subject: [PATCH v4 19/79] media: sunxi: fix pm_runtime_get_sync() usage
 count
In-Reply-To: <17cf60c9e5190ff83de40284bb858581bb0ec4a6.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <17cf60c9e5190ff83de40284bb858581bb0ec4a6.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430174838.00000412@Huawei.com>

On Wed, 28 Apr 2021 16:51:40 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> The pm_runtime_get_sync() internally increments the
> dev->power.usage_count without decrementing it, even on errors.
> Replace it by the new pm_runtime_resume_and_get(), introduced by:
> commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> in order to properly decrement the usage counter and avoid memory
> leaks.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

> ---
>  drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
> index 3f81dd17755c..fbcca59a0517 100644
> --- a/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
> +++ b/drivers/media/platform/sunxi/sun8i-rotate/sun8i_rotate.c
> @@ -494,7 +494,7 @@ static int rotate_start_streaming(struct vb2_queue *vq, unsigned int count)
>  		struct device *dev = ctx->dev->dev;
>  		int ret;
>  
> -		ret = pm_runtime_get_sync(dev);
> +		ret = pm_runtime_resume_and_get(dev);
>  		if (ret < 0) {
>  			dev_err(dev, "Failed to enable module\n");
>  



From boris.brezillon at collabora.com  Fri Apr 30 17:51:04 2021
From: boris.brezillon at collabora.com (Boris Brezillon)
Date: Fri, 30 Apr 2021 18:51:04 +0200
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426143934.25275-2-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
Message-ID: <20210430185104.377d1bc6@collabora.com>

On Mon, 26 Apr 2021 16:39:32 +0200
<patrice.chotard at foss.st.com> wrote:

> From: Christophe Kerello <christophe.kerello at foss.st.com>
> 
> With STM32 QSPI, it is possible to poll the status register of the device.
> This could be done to offload the CPU during an operation (erase or
> program a SPI NAND for example).
> 
> spi_mem_poll_status API has been added to handle this feature.
> 
> Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
> ---
>  drivers/spi/spi-mem.c       | 34 ++++++++++++++++++++++++++++++++++
>  include/linux/spi/spi-mem.h |  8 ++++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index 1513553e4080..43dce4b0efa4 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -743,6 +743,40 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>  	return container_of(drv, struct spi_mem_driver, spidrv.driver);
>  }
>  
> +/**
> + * spi_mem_poll_status() - Poll memory device status
> + * @mem: SPI memory device
> + * @op: the memory operation to execute
> + * @mask: status bitmask to ckeck
> + * @match: status expected value
> + * @timeout: timeout
> + *
> + * This function send a polling status request to the controller driver
> + *
> + * Return: 0 in case of success, -ETIMEDOUT in case of error,
> + *         -EOPNOTSUPP if not supported.
> + */
> +int spi_mem_poll_status(struct spi_mem *mem,
> +			const struct spi_mem_op *op,
> +			u8 mask, u8 match, u16 timeout)
> +{
> +	struct spi_controller *ctlr = mem->spi->controller;
> +	int ret = -EOPNOTSUPP;
> +
> +	if (ctlr->mem_ops && ctlr->mem_ops->poll_status) {
> +		ret = spi_mem_access_start(mem);

You should probably check that op is a single byte read before
accepting the command.

> +		if (ret)
> +			return ret;
> +
> +		ret = ctlr->mem_ops->poll_status(mem, op, mask, match, timeout);

You also need some sort of ->poll_status_is_supported() to validate
that the controller supports the status polling for this specific op (I
can imagine some controllers having a limit on the number of dummy
cycles/address bytes). I guess you could just fall back on SW-based
status polling if ctlr->mem_ops->poll_status() returns -ENOTSUPP.

> +
> +		spi_mem_access_end(mem);
> +	}
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(spi_mem_poll_status);
> +
>  static int spi_mem_probe(struct spi_device *spi)
>  {
>  	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index 2b65c9edc34e..5f78917c0f68 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -250,6 +250,7 @@ static inline void *spi_mem_get_drvdata(struct spi_mem *mem)
>   *		  the currently mapped area), and the caller of
>   *		  spi_mem_dirmap_write() is responsible for calling it again in
>   *		  this case.
> + * @poll_status: poll memory device status
>   *
>   * This interface should be implemented by SPI controllers providing an
>   * high-level interface to execute SPI memory operation, which is usually the
> @@ -274,6 +275,9 @@ struct spi_controller_mem_ops {
>  			       u64 offs, size_t len, void *buf);
>  	ssize_t (*dirmap_write)(struct spi_mem_dirmap_desc *desc,
>  				u64 offs, size_t len, const void *buf);
> +	int (*poll_status)(struct spi_mem *mem,
> +			   const struct spi_mem_op *op,
> +			   u8 mask, u8 match, u16 timeout);
>  };
>  
>  /**
> @@ -369,6 +373,10 @@ devm_spi_mem_dirmap_create(struct device *dev, struct spi_mem *mem,
>  void devm_spi_mem_dirmap_destroy(struct device *dev,
>  				 struct spi_mem_dirmap_desc *desc);
>  
> +int spi_mem_poll_status(struct spi_mem *mem,
> +			const struct spi_mem_op *op,
> +			u8 mask, u8 match, u16 timeout);
> +
>  int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>  				       struct module *owner);
>  



From boris.brezillon at collabora.com  Fri Apr 30 17:52:01 2021
From: boris.brezillon at collabora.com (Boris Brezillon)
Date: Fri, 30 Apr 2021 18:52:01 +0200
Subject: [PATCH 1/3] spi: spi-mem: add automatic poll status functions
In-Reply-To: <20210426143934.25275-2-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-2-patrice.chotard@foss.st.com>
Message-ID: <20210430185201.0b79bb62@collabora.com>

On Mon, 26 Apr 2021 16:39:32 +0200
<patrice.chotard at foss.st.com> wrote:

> +/**
> + * spi_mem_poll_status() - Poll memory device status
> + * @mem: SPI memory device
> + * @op: the memory operation to execute
> + * @mask: status bitmask to ckeck
> + * @match: status expected value
> + * @timeout: timeout

What's the unit?


From boris.brezillon at collabora.com  Fri Apr 30 17:53:58 2021
From: boris.brezillon at collabora.com (Boris Brezillon)
Date: Fri, 30 Apr 2021 18:53:58 +0200
Subject: [PATCH 3/3] spi: stm32-qspi: add automatic poll status feature
In-Reply-To: <20210426143934.25275-4-patrice.chotard@foss.st.com>
References: <20210426143934.25275-1-patrice.chotard@foss.st.com>
 <20210426143934.25275-4-patrice.chotard@foss.st.com>
Message-ID: <20210430185358.137c85ab@collabora.com>

On Mon, 26 Apr 2021 16:39:34 +0200
<patrice.chotard at foss.st.com> wrote:

> From: Christophe Kerello <christophe.kerello at foss.st.com>
> 
> STM32 QSPI is able to automatically poll a specified register inside the
> memory and relieve the CPU from this task.
> 
> As example, when erasing a large memory area, we got cpu load
> equal to 50%.

Ouch! I feel like this should be fixed at the core level too so we
don't poll the status so frequently, or at least wait a bit before
polling the status (especially for erase/write operations).

> This patch allows to perform the same operation
> with a cpu load around 2%.
> 
> Signed-off-by: Christophe Kerello <christophe.kerello at foss.st.com>
> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
> ---
>  drivers/spi/spi-stm32-qspi.c | 80 ++++++++++++++++++++++++++++++++----
>  1 file changed, 72 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c
> index 7e640ccc7e77..2f9e5941f14f 100644
> --- a/drivers/spi/spi-stm32-qspi.c
> +++ b/drivers/spi/spi-stm32-qspi.c
> @@ -36,6 +36,7 @@
>  #define CR_FTIE			BIT(18)
>  #define CR_SMIE			BIT(19)
>  #define CR_TOIE			BIT(20)
> +#define CR_APMS			BIT(22)
>  #define CR_PRESC_MASK		GENMASK(31, 24)
>  
>  #define QSPI_DCR		0x04
> @@ -53,6 +54,7 @@
>  #define QSPI_FCR		0x0c
>  #define FCR_CTEF		BIT(0)
>  #define FCR_CTCF		BIT(1)
> +#define FCR_CSMF		BIT(3)
>  
>  #define QSPI_DLR		0x10
>  
> @@ -107,6 +109,7 @@ struct stm32_qspi {
>  	u32 clk_rate;
>  	struct stm32_qspi_flash flash[STM32_QSPI_MAX_NORCHIP];
>  	struct completion data_completion;
> +	struct completion match_completion;
>  	u32 fmode;
>  
>  	struct dma_chan *dma_chtx;
> @@ -115,6 +118,7 @@ struct stm32_qspi {
>  
>  	u32 cr_reg;
>  	u32 dcr_reg;
> +	u16 status_timeout;
>  
>  	/*
>  	 * to protect device configuration, could be different between
> @@ -128,11 +132,20 @@ static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
>  	struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
>  	u32 cr, sr;
>  
> +	cr = readl_relaxed(qspi->io_base + QSPI_CR);
>  	sr = readl_relaxed(qspi->io_base + QSPI_SR);
>  
> +	if (cr & CR_SMIE && sr & SR_SMF) {
> +		/* disable irq */
> +		cr &= ~CR_SMIE;
> +		writel_relaxed(cr, qspi->io_base + QSPI_CR);
> +		complete(&qspi->match_completion);
> +
> +		return IRQ_HANDLED;
> +	}
> +
>  	if (sr & (SR_TEF | SR_TCF)) {
>  		/* disable irq */
> -		cr = readl_relaxed(qspi->io_base + QSPI_CR);
>  		cr &= ~CR_TCIE & ~CR_TEIE;
>  		writel_relaxed(cr, qspi->io_base + QSPI_CR);
>  		complete(&qspi->data_completion);
> @@ -319,6 +332,24 @@ static int stm32_qspi_wait_cmd(struct stm32_qspi *qspi,
>  	return err;
>  }
>  
> +static int stm32_qspi_wait_poll_status(struct stm32_qspi *qspi,
> +				       const struct spi_mem_op *op)
> +{
> +	u32 cr;
> +
> +	reinit_completion(&qspi->match_completion);
> +	cr = readl_relaxed(qspi->io_base + QSPI_CR);
> +	writel_relaxed(cr | CR_SMIE, qspi->io_base + QSPI_CR);
> +
> +	if (!wait_for_completion_timeout(&qspi->match_completion,
> +				msecs_to_jiffies(qspi->status_timeout)))
> +		return -ETIMEDOUT;
> +
> +	writel_relaxed(FCR_CSMF, qspi->io_base + QSPI_FCR);
> +
> +	return 0;
> +}
> +
>  static int stm32_qspi_get_mode(struct stm32_qspi *qspi, u8 buswidth)
>  {
>  	if (buswidth == 4)
> @@ -332,7 +363,7 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
>  	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
>  	struct stm32_qspi_flash *flash = &qspi->flash[mem->spi->chip_select];
>  	u32 ccr, cr;
> -	int timeout, err = 0;
> +	int timeout, err = 0, err_poll_status = 0;
>  
>  	dev_dbg(qspi->dev, "cmd:%#x mode:%d.%d.%d.%d addr:%#llx len:%#x\n",
>  		op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> @@ -378,6 +409,9 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
>  	if (op->addr.nbytes && qspi->fmode != CCR_FMODE_MM)
>  		writel_relaxed(op->addr.val, qspi->io_base + QSPI_AR);
>  
> +	if (qspi->fmode == CCR_FMODE_APM)
> +		err_poll_status = stm32_qspi_wait_poll_status(qspi, op);
> +
>  	err = stm32_qspi_tx(qspi, op);
>  
>  	/*
> @@ -387,7 +421,7 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
>  	 *  byte of device (device size - fifo size). like device size is not
>  	 *  knows, the prefetching is always stop.
>  	 */
> -	if (err || qspi->fmode == CCR_FMODE_MM)
> +	if (err || err_poll_status || qspi->fmode == CCR_FMODE_MM)
>  		goto abort;
>  
>  	/* wait end of tx in indirect mode */
> @@ -406,15 +440,43 @@ static int stm32_qspi_send(struct spi_mem *mem, const struct spi_mem_op *op)
>  						    cr, !(cr & CR_ABORT), 1,
>  						    STM32_ABT_TIMEOUT_US);
>  
> -	writel_relaxed(FCR_CTCF, qspi->io_base + QSPI_FCR);
> +	writel_relaxed(FCR_CTCF | FCR_CSMF, qspi->io_base + QSPI_FCR);
>  
> -	if (err || timeout)
> -		dev_err(qspi->dev, "%s err:%d abort timeout:%d\n",
> -			__func__, err, timeout);
> +	if (err || err_poll_status || timeout)
> +		dev_err(qspi->dev, "%s err:%d err_poll_status:%d abort timeout:%d\n",
> +			__func__, err, err_poll_status, timeout);
>  
>  	return err;
>  }
>  
> +static int stm32_qspi_poll_status(struct spi_mem *mem, const struct spi_mem_op *op,
> +				  u8 mask, u8 match, u16 timeout_ms)
> +{
> +	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
> +	int ret;
> +
> +	ret = pm_runtime_get_sync(qspi->dev);
> +	if (ret < 0) {
> +		pm_runtime_put_noidle(qspi->dev);
> +		return ret;
> +	}
> +
> +	mutex_lock(&qspi->lock);
> +
> +	writel_relaxed(mask, qspi->io_base + QSPI_PSMKR);
> +	writel_relaxed(match, qspi->io_base + QSPI_PSMAR);
> +	qspi->fmode = CCR_FMODE_APM;
> +	qspi->status_timeout = timeout_ms;
> +
> +	ret = stm32_qspi_send(mem, op);
> +	mutex_unlock(&qspi->lock);
> +
> +	pm_runtime_mark_last_busy(qspi->dev);
> +	pm_runtime_put_autosuspend(qspi->dev);
> +
> +	return ret;
> +}
> +
>  static int stm32_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
>  {
>  	struct stm32_qspi *qspi = spi_controller_get_devdata(mem->spi->master);
> @@ -527,7 +589,7 @@ static int stm32_qspi_setup(struct spi_device *spi)
>  	flash->presc = presc;
>  
>  	mutex_lock(&qspi->lock);
> -	qspi->cr_reg = 3 << CR_FTHRES_SHIFT | CR_SSHIFT | CR_EN;
> +	qspi->cr_reg = CR_APMS | 3 << CR_FTHRES_SHIFT | CR_SSHIFT | CR_EN;
>  	writel_relaxed(qspi->cr_reg, qspi->io_base + QSPI_CR);
>  
>  	/* set dcr fsize to max address */
> @@ -607,6 +669,7 @@ static const struct spi_controller_mem_ops stm32_qspi_mem_ops = {
>  	.exec_op	= stm32_qspi_exec_op,
>  	.dirmap_create	= stm32_qspi_dirmap_create,
>  	.dirmap_read	= stm32_qspi_dirmap_read,
> +	.poll_status	= stm32_qspi_poll_status,
>  };
>  
>  static int stm32_qspi_probe(struct platform_device *pdev)
> @@ -661,6 +724,7 @@ static int stm32_qspi_probe(struct platform_device *pdev)
>  	}
>  
>  	init_completion(&qspi->data_completion);
> +	init_completion(&qspi->match_completion);
>  
>  	qspi->clk = devm_clk_get(dev, NULL);
>  	if (IS_ERR(qspi->clk)) {



From andrew at lunn.ch  Fri Apr 30 17:56:06 2021
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 30 Apr 2021 18:56:06 +0200
Subject: [PATCH net-next v1 1/1] net: selftest: provide option to disable
 generic selftests
In-Reply-To: <6865cd7a-7f2e-13f5-a588-8877d771b834@infradead.org>
References: <20210430095308.14465-1-o.rempel@pengutronix.de>
 <f0905c84-6bb2-702f-9ae7-614dcd85c458@infradead.org>
 <20210430154153.zhdnxzkm2fhcuogo@pengutronix.de>
 <YIwu+4ywaTI4+eUq@lunn.ch>
 <6865cd7a-7f2e-13f5-a588-8877d771b834@infradead.org>
Message-ID: <YIw2pkVPb69f3rsm@lunn.ch>

On Fri, Apr 30, 2021 at 09:33:42AM -0700, Randy Dunlap wrote:
> On 4/30/21 9:23 AM, Andrew Lunn wrote:
> >>> Thanks for the patch/option. But I think it should just default to n,
> >>> not PHYLIB.
> >>
> >> It should be enabled by default for every device supporting this kind of
> >> selftests.
> > 
> > I agree.
> > 
> > I still wonder if there is confusion about self test here. Maybe
> 
> Probably.
> 
> > putting ethtool into the description will help people understand it
> > has nothing to do with the kernel self test infrastructure and kernel
> > self testing.
> 
> So it's a hardware check that is required to be run if it's implemented
> in a driver?
> 
> Required by who/what?

It is not required, but it is a useful debug tool for the educated
user. Root can run the self tests on the network interface. If the
self test pass, but the interface does not work, you probably have a
cabling or configuration issue. Networking is complex and being able
to eliminate the interface hardware lets you concentrate on some other
part of the problem. You can then maybe next use the cable test option
of ethtool to see if the cable has a problem.

   Andrew


From vsethi at nvidia.com  Fri Apr 30 17:57:14 2021
From: vsethi at nvidia.com (Vikram Sethi)
Date: Fri, 30 Apr 2021 16:57:14 +0000
Subject: [RFC 1/2] vfio/pci: keep the prefetchable attribute of a BAR
 region in VMA
In-Reply-To: <878s4zokll.wl-maz@kernel.org>
References: <20210429162906.32742-1-sdonthineni@nvidia.com>
 <20210429162906.32742-2-sdonthineni@nvidia.com>
 <20210429122840.4f98f78e@redhat.com>
 <470360a7-0242-9ae5-816f-13608f957bf6@nvidia.com>
 <20210429134659.321a5c3c@redhat.com>
 <e3d7fda8-5263-211c-3686-f699765ab715@nvidia.com>
 <87czucngdc.wl-maz@kernel.org>
 <1edb2c4e-23f0-5730-245b-fc6d289951e1@nvidia.com>
 <878s4zokll.wl-maz@kernel.org>
Message-ID: <BL0PR12MB2532CC436EBF626966B15994BD5E9@BL0PR12MB2532.namprd12.prod.outlook.com>

Hi Marc, 

> -----Original Message-----
> From: Marc Zyngier <maz at kernel.org>
> Sent: Friday, April 30, 2021 10:31 AM
> On Fri, 30 Apr 2021 15:58:14 +0100,
> Shanker R Donthineni <sdonthineni at nvidia.com> wrote:
> >
> > Hi Marc,
> >
> > On 4/30/21 6:47 AM, Marc Zyngier wrote:
> > >
> > >>>> We've two concerns here:
> > >>>>    - Performance impacts for pass-through devices.
> > >>>>    - The definition of ioremap_wc() function doesn't match the
> > >>>> host kernel on ARM64
> > >>> Performance I can understand, but I think you're also using it to
> > >>> mask a driver bug which should be resolved first.  Thank
> > >> We?ve already instrumented the driver code and found the code path
> > >> for the unaligned accesses. We?ll fix this issue if it?s not
> > >> following WC semantics.
> > >>
> > >> Fixing the performance concern will be under KVM stage-2 page-table
> > >> control. We're looking for a guidance/solution for updating stage-2
> > >> PTE based on PCI-BAR attribute.
> > > Before we start discussing the *how*, I'd like to clearly understand
> > > what *arm64* memory attributes you are relying on. We already have
> > > established that the unaligned access was a bug, which was the
> > > biggest argument in favour of NORMAL_NC. What are the other
> requirements?
> > Sorry, my earlier response was not complete...
> >
> > ARMv8 architecture has two features Gathering and Reorder
> > transactions, very important from a performance point of view. Small
> > inline packets for NIC cards and accesses to GPU's frame buffer are
> > CPU-bound operations. We want to take advantages of GRE features to
> > achieve higher performance.
> >
> > Both these features are disabled for prefetchable BARs in VM because
> > memory-type MT_DEVICE_nGnRE enforced in stage-2.
> 
> Right, so Normal_NC is a red herring, and it is Device_GRE that you really are
> after, right?
> 
I think Device GRE has some practical problems. 
1. A lot of userspace code which is used to getting write combined mappings
to GPU memory from kernel drivers does memcpy/memset on it which 
can insert ldp/stp which can crash on Device Memory Type. From a quick search
I didn't find a memcpy_io or memset_io in glibc. Perhaps there are some 
other functions available, but a lot of userspace applications that work on x86 and
ARM baremetal won't work on ARM VMs without such changes. Changes to all of 
userspace may not always be practical, specially if linking to binaries

2. Sometimes even if application is not using memset/memcpy directly, 
gcc may insert a builtin memcpy/memset. 

3. Recompiling all applications with gcc -m strict-align has performance issues. 
In our experiments that resulted in an increase in code size, and also 3-5% 
performance decrease reliably.
Also, it is not always practical to recompile all of userspace, depending on
who owns the code/linked binaries etc.

From KVM-ARM point of view, what is it about Normal NC at stage 2 for
Prefetchable BAR (however KVM gets the hint, whether from userspace or VMA)
that is undesirable vs Device GRE? I couldn't think of a difference to devices
whether the combining or prefetching or reordering happened because of one or
the other. 

> Now, I'm not convinced that we can do that directly from vfio in a device-
> agnostic manner. It is userspace that places the device in the guest's
> memory, and I have the ugly feeling that userspace needs to be in control of
> memory attributes.
> 
> Otherwise, we change the behaviour for all existing devices that have
> prefetchable BARs, and I don't think that's an acceptable move (userspace
> ABI change).
> 
>         M.
> 
> --
> Without deviation from the norm, progress is not possible.

From Jonathan.Cameron at Huawei.com  Fri Apr 30 18:05:15 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 18:05:15 +0100
Subject: [PATCH v4 24/79] staging: media: cedrus_video: use
 pm_runtime_resume_and_get()
In-Reply-To: <cc0761dc51d021a4295cce298834afb9be0211c6.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <cc0761dc51d021a4295cce298834afb9be0211c6.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430180515.0000134f@Huawei.com>

On Wed, 28 Apr 2021 16:51:45 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron at huawei.com>

> ---
>  drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index b62eb8e84057..9ddd789d0b1f 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq, unsigned int count)
>  	}
>  
>  	if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
> -		ret = pm_runtime_get_sync(dev->dev);
> -		if (ret < 0) {
> -			pm_runtime_put_noidle(dev->dev);
> +		ret = pm_runtime_resume_and_get(dev->dev);
> +		if (ret < 0)
>  			goto err_cleanup;
> -		}
>  
>  		if (dev->dec_ops[ctx->current_codec]->start) {
>  			ret = dev->dec_ops[ctx->current_codec]->start(ctx);



From catalin.marinas at arm.com  Fri Apr 30 18:32:55 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:32:55 +0100
Subject: [PATCH] arm64: stacktrace: Stop unwinding when the PC is zero
In-Reply-To: <20210429104813.GA33550@C02TD0UTHF1T.local>
References: <20210429014321.196606-1-leo.yan@linaro.org>
 <20210429104813.GA33550@C02TD0UTHF1T.local>
Message-ID: <20210430173255.GE18574@arm.com>

On Thu, Apr 29, 2021 at 11:48:13AM +0100, Mark Rutland wrote:
> From b99e647b34b74059f3013c09f12fbd542c7679fd Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland at arm.com>
> Date: Thu, 29 Apr 2021 11:20:04 +0100
> Subject: [PATCH] arm64: stacktrace: restore terminal records
> 
> We removed the terminal frame records in commit:
> 
>    6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> 
> ... on the assumption that as we no longer used them to find the pt_regs
> at exception boundaries, they were no longer necessary.
> 
> However, Leo reports that as an unintended side-effect, this causes
> traces which cross secondary_start_kernel to terminate one entry too
> late, with a spurious "0" entry.
> 
> There are a few ways we could sovle this, but as we're planning to use
> terminal records for RELIABLE_STACKTRACE, let's revert the logic change
> for now, keeping the update comments and accounting for the changes in
> commit:
> 
>   3c02600144bdb0a1 ("arm64: stacktrace: Report when we reach the end of the stack")
> 
> This is effectively a partial revert of commit:
> 
>   6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Fixes: 6106e1112cc69a36 ("arm64: remove EL0 exception frame record")
> Reported-by: Leo Yan <leo.yan at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> Cc: Mark Brown <broonie at kernel.org>
> Cc: "Madhavan T. Venkataraman" <madvenka at linux.microsoft.com>

Thanks Mark. I applied it to for-next/core (couldn't figure out the
combination of b4 and git am + the scissors and not replying to the top
message).

-- 
Catalin


From catalin.marinas at arm.com  Fri Apr 30 18:38:19 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:38:19 +0100
Subject: [PATCH] arm64: cpufeatures: use min and max
In-Reply-To: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
References: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
Message-ID: <20210430173818.GF18574@arm.com>

Hi Julia,

On Thu, Apr 29, 2021 at 10:50:46PM +0200, Julia Lawall wrote:
> From: kernel test robot <lkp at intel.com>
> 
> Use min and max to make the effect more clear.
> 
> Generated by: scripts/coccinelle/misc/minmax.cocci
> 
> Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")

What's with this Fixes tag? I can't find it anywhere and I don't think
it warrants such a tag anyway, it's not a bug.

I'll apply it without the tag and include minmax.h as per Mark's
comment.

Thanks.

-- 
Catalin


From julia.lawall at inria.fr  Fri Apr 30 18:40:06 2021
From: julia.lawall at inria.fr (Julia Lawall)
Date: Fri, 30 Apr 2021 19:40:06 +0200 (CEST)
Subject: [kbuild-all] Re: [PATCH] arm64: cpufeatures: use min and max
In-Reply-To: <20210430173818.GF18574@arm.com>
References: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
 <20210430173818.GF18574@arm.com>
Message-ID: <alpine.DEB.2.22.394.2104301939120.13185@hadrien>



On Fri, 30 Apr 2021, Catalin Marinas wrote:

> Hi Julia,
>
> On Thu, Apr 29, 2021 at 10:50:46PM +0200, Julia Lawall wrote:
> > From: kernel test robot <lkp at intel.com>
> >
> > Use min and max to make the effect more clear.
> >
> > Generated by: scripts/coccinelle/misc/minmax.cocci
> >
> > Fixes: 8636e3295ce3 ("coccinelle: misc: add minmax script")
>
> What's with this Fixes tag? I can't find it anywhere and I don't think
> it warrants such a tag anyway, it's not a bug.
>
> I'll apply it without the tag and include minmax.h as per Mark's
> comment.

Oops, sorry about that.  It's something that 0-day adds, but I think it is
always incorrect for new semantic patches.  Please remove it.

thanks,
julia


From ebiederm at xmission.com  Fri Apr 30 18:42:15 2021
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 30 Apr 2021 12:42:15 -0500
Subject: [PATCH 1/3] sparc64: Add compile-time asserts for siginfo_t
 offsets
In-Reply-To: <20210429190734.624918-1-elver@google.com> (Marco Elver's message
 of "Thu, 29 Apr 2021 21:07:32 +0200")
References: <20210429190734.624918-1-elver@google.com>
Message-ID: <m1im43zn2g.fsf@fess.ebiederm.org>

Marco Elver <elver at google.com> writes:

> To help catch ABI breaks at compile-time, add compile-time assertions to
> verify the siginfo_t layout. Unlike other architectures, sparc64 is
> special, because it is one of few architectures requiring si_trapno.
> ABI breaks around that field would only be caught here.

Arnd Bergman recently pointed out that we can move si_trapno into the
union and make it specific to a handful of signals.  Like we do other
items in the union.

Given that the code of perf_sigtrap is pretty much broken if si_trapno
needs to be filled out.  I think we should make that change before
we set this ABI in stone like this.

Otherwise this looks good.

Eric

> Link: https://lkml.kernel.org/r/m11rat9f85.fsf at fess.ebiederm.org
> Suggested-by: Eric W. Biederman <ebiederm at xmission.com>
> Signed-off-by: Marco Elver <elver at google.com>
> ---
>  arch/sparc/kernel/signal32.c  | 34 ++++++++++++++++++++++++++++++++++
>  arch/sparc/kernel/signal_64.c | 33 +++++++++++++++++++++++++++++++++
>  2 files changed, 67 insertions(+)
>
> diff --git a/arch/sparc/kernel/signal32.c b/arch/sparc/kernel/signal32.c
> index e9695a06492f..778ed5c26d4a 100644
> --- a/arch/sparc/kernel/signal32.c
> +++ b/arch/sparc/kernel/signal32.c
> @@ -745,3 +745,37 @@ asmlinkage int do_sys32_sigstack(u32 u_ssptr, u32 u_ossptr, unsigned long sp)
>  out:
>  	return ret;
>  }
> +
> +/*
> + * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
> + * changes likely come with new fields that should be added below.
> + */
> +static_assert(NSIGILL	== 11);
> +static_assert(NSIGFPE	== 15);
> +static_assert(NSIGSEGV	== 9);
> +static_assert(NSIGBUS	== 5);
> +static_assert(NSIGTRAP	== 6);
> +static_assert(NSIGCHLD	== 6);
> +static_assert(NSIGSYS	== 2);
> +static_assert(offsetof(compat_siginfo_t, si_signo)	== 0x00);
> +static_assert(offsetof(compat_siginfo_t, si_errno)	== 0x04);
> +static_assert(offsetof(compat_siginfo_t, si_code)	== 0x08);
> +static_assert(offsetof(compat_siginfo_t, si_pid)	== 0x0c);
> +static_assert(offsetof(compat_siginfo_t, si_uid)	== 0x10);
> +static_assert(offsetof(compat_siginfo_t, si_tid)	== 0x0c);
> +static_assert(offsetof(compat_siginfo_t, si_overrun)	== 0x10);
> +static_assert(offsetof(compat_siginfo_t, si_status)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_utime)	== 0x18);
> +static_assert(offsetof(compat_siginfo_t, si_stime)	== 0x1c);
> +static_assert(offsetof(compat_siginfo_t, si_value)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_int)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_ptr)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_addr)	== 0x0c);
> +static_assert(offsetof(compat_siginfo_t, si_trapno)	== 0x10);
> +static_assert(offsetof(compat_siginfo_t, si_addr_lsb)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_lower)	== 0x18);
> +static_assert(offsetof(compat_siginfo_t, si_upper)	== 0x1c);
> +static_assert(offsetof(compat_siginfo_t, si_pkey)	== 0x18);
> +static_assert(offsetof(compat_siginfo_t, si_perf)	== 0x14);
> +static_assert(offsetof(compat_siginfo_t, si_band)	== 0x0c);
> +static_assert(offsetof(compat_siginfo_t, si_fd)		== 0x10);
> diff --git a/arch/sparc/kernel/signal_64.c b/arch/sparc/kernel/signal_64.c
> index a0eec62c825d..c9bbf5f29078 100644
> --- a/arch/sparc/kernel/signal_64.c
> +++ b/arch/sparc/kernel/signal_64.c
> @@ -556,3 +556,36 @@ void do_notify_resume(struct pt_regs *regs, unsigned long orig_i0, unsigned long
>  	user_enter();
>  }
>  
> +/*
> + * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
> + * changes likely come with new fields that should be added below.
> + */
> +static_assert(NSIGILL	== 11);
> +static_assert(NSIGFPE	== 15);
> +static_assert(NSIGSEGV	== 9);
> +static_assert(NSIGBUS	== 5);
> +static_assert(NSIGTRAP	== 6);
> +static_assert(NSIGCHLD	== 6);
> +static_assert(NSIGSYS	== 2);
> +static_assert(offsetof(siginfo_t, si_signo)	== 0x00);
> +static_assert(offsetof(siginfo_t, si_errno)	== 0x04);
> +static_assert(offsetof(siginfo_t, si_code)	== 0x08);
> +static_assert(offsetof(siginfo_t, si_pid)	== 0x10);
> +static_assert(offsetof(siginfo_t, si_uid)	== 0x14);
> +static_assert(offsetof(siginfo_t, si_tid)	== 0x10);
> +static_assert(offsetof(siginfo_t, si_overrun)	== 0x14);
> +static_assert(offsetof(siginfo_t, si_status)	== 0x18);
> +static_assert(offsetof(siginfo_t, si_utime)	== 0x20);
> +static_assert(offsetof(siginfo_t, si_stime)	== 0x28);
> +static_assert(offsetof(siginfo_t, si_value)	== 0x18);
> +static_assert(offsetof(siginfo_t, si_int)	== 0x18);
> +static_assert(offsetof(siginfo_t, si_ptr)	== 0x18);
> +static_assert(offsetof(siginfo_t, si_addr)	== 0x10);
> +static_assert(offsetof(siginfo_t, si_trapno)	== 0x18);
> +static_assert(offsetof(siginfo_t, si_addr_lsb)	== 0x20);
> +static_assert(offsetof(siginfo_t, si_lower)	== 0x28);
> +static_assert(offsetof(siginfo_t, si_upper)	== 0x30);
> +static_assert(offsetof(siginfo_t, si_pkey)	== 0x28);
> +static_assert(offsetof(siginfo_t, si_perf)	== 0x20);
> +static_assert(offsetof(siginfo_t, si_band)	== 0x10);
> +static_assert(offsetof(siginfo_t, si_fd)	== 0x14);


From Jonathan.Cameron at Huawei.com  Fri Apr 30 18:49:11 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 18:49:11 +0100
Subject: [PATCH v4 62/79] media: exynos4-is: use
 pm_runtime_resume_and_get()
In-Reply-To: <31eadd61972541bf1e27706f9ff7be66a21e23e6.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <31eadd61972541bf1e27706f9ff7be66a21e23e6.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430184911.000075e1@Huawei.com>

On Wed, 28 Apr 2021 16:52:23 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/exynos4-is/fimc-capture.c   | 6 ++----
>  drivers/media/platform/exynos4-is/fimc-is.c        | 4 ++--
>  drivers/media/platform/exynos4-is/fimc-isp-video.c | 3 +--
>  drivers/media/platform/exynos4-is/fimc-isp.c       | 7 +++----
>  drivers/media/platform/exynos4-is/fimc-lite.c      | 5 +++--
>  drivers/media/platform/exynos4-is/fimc-m2m.c       | 2 +-
>  drivers/media/platform/exynos4-is/media-dev.c      | 8 +++-----
>  drivers/media/platform/exynos4-is/mipi-csis.c      | 8 +++-----
>  8 files changed, 18 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
> index 13c838d3f947..0da36443173c 100644
> --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> @@ -478,11 +478,9 @@ static int fimc_capture_open(struct file *file)
>  		goto unlock;
>  
>  	set_bit(ST_CAPT_BUSY, &fimc->state);
> -	ret = pm_runtime_get_sync(&fimc->pdev->dev);
> -	if (ret < 0) {
> -		pm_runtime_put_sync(&fimc->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
> +	if (ret < 0)
>  		goto unlock;
> -	}
>  
>  	ret = v4l2_fh_open(file);
>  	if (ret) {
> diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c
> index 972d9601d236..1b24f5bfc4af 100644
> --- a/drivers/media/platform/exynos4-is/fimc-is.c
> +++ b/drivers/media/platform/exynos4-is/fimc-is.c
> @@ -828,9 +828,9 @@ static int fimc_is_probe(struct platform_device *pdev)
>  			goto err_irq;
>  	}
>  
> -	ret = pm_runtime_get_sync(dev);
> +	ret = pm_runtime_resume_and_get(dev);
>  	if (ret < 0)
> -		goto err_pm;
> +		goto err_irq;
>  

I think the pm_runtime_put_noidle() below err_pm: should become
a pm_runtime_put() because otherwise we won't call fimc_is_runtime_suspend()
if runtime pm is enabled (either directly or via runtime pm count becoming zero.

(not I'm not 100% sure of my argument here...)

>  	vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>  
> diff --git a/drivers/media/platform/exynos4-is/fimc-isp-video.c b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> index 612b9872afc8..8d9dc597deaa 100644
> --- a/drivers/media/platform/exynos4-is/fimc-isp-video.c
> +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c
> @@ -275,7 +275,7 @@ static int isp_video_open(struct file *file)
>  	if (ret < 0)
>  		goto unlock;
>  
> -	ret = pm_runtime_get_sync(&isp->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&isp->pdev->dev);
>  	if (ret < 0)
>  		goto rel_fh;
>  
> @@ -293,7 +293,6 @@ static int isp_video_open(struct file *file)
>  	if (!ret)
>  		goto unlock;

So the good path is to jump over the block.  I'd just unlock and return here
to make it more readable but unrelated to this patch.

>  rel_fh:
> -	pm_runtime_put_noidle(&isp->pdev->dev);

Logic flow here isn't very standard, but with this change, you'll not
call anything to unwind a successful call to pm_runtime_resume_and_get if
fmic_pipeline_call() returns and error.
My guess is pm_runtime_put_sync() is needed before rel_fh; to balance this.
 
>  	v4l2_fh_release(file);
>  unlock:
>  	mutex_unlock(&isp->video_lock);
> diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
> index a77c49b18511..74b49d30901e 100644
> --- a/drivers/media/platform/exynos4-is/fimc-isp.c
> +++ b/drivers/media/platform/exynos4-is/fimc-isp.c
> @@ -304,11 +304,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
>  	pr_debug("on: %d\n", on);
>  
>  	if (on) {
> -		ret = pm_runtime_get_sync(&is->pdev->dev);
> -		if (ret < 0) {
> -			pm_runtime_put(&is->pdev->dev);
> +		ret = pm_runtime_resume_and_get(&is->pdev->dev);
> +		if (ret < 0)
>  			return ret;
> -		}
> +
>  		set_bit(IS_ST_PWR_ON, &is->state);
>  
>  		ret = fimc_is_start_firmware(is);
> diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
> index fe20af3a7178..4d8b18078ff3 100644
> --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> @@ -469,9 +469,9 @@ static int fimc_lite_open(struct file *file)
>  	}
>  
>  	set_bit(ST_FLITE_IN_USE, &fimc->state);
> -	ret = pm_runtime_get_sync(&fimc->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&fimc->pdev->dev);
>  	if (ret < 0)
> -		goto err_pm;
> +		goto err_in_use;
>  
>  	ret = v4l2_fh_open(file);
>  	if (ret < 0)
> @@ -499,6 +499,7 @@ static int fimc_lite_open(struct file *file)
>  	v4l2_fh_release(file);
>  err_pm:
>  	pm_runtime_put_sync(&fimc->pdev->dev);
> +err_in_use:
>  	clear_bit(ST_FLITE_IN_USE, &fimc->state);
>  unlock:
>  	mutex_unlock(&fimc->lock);
> diff --git a/drivers/media/platform/exynos4-is/fimc-m2m.c b/drivers/media/platform/exynos4-is/fimc-m2m.c
> index c9704a147e5c..7c1eb05c508f 100644
> --- a/drivers/media/platform/exynos4-is/fimc-m2m.c
> +++ b/drivers/media/platform/exynos4-is/fimc-m2m.c
> @@ -75,7 +75,7 @@ static int start_streaming(struct vb2_queue *q, unsigned int count)
>  	struct fimc_ctx *ctx = q->drv_priv;
>  	int ret;
>  
> -	ret = pm_runtime_get_sync(&ctx->fimc_dev->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&ctx->fimc_dev->pdev->dev);
Use the fact pm_runtime_resume_and_get only returns 0 or < 0 to
make this
return pm_runtime_resume_and_get()

>  	return ret > 0 ? 0 : ret;
>  }
>  
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
> index 13d192ba4aa6..9346d44a06c2 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -512,11 +512,9 @@ static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
>  	if (!fmd->pmf)
>  		return -ENXIO;
>  
> -	ret = pm_runtime_get_sync(fmd->pmf);
> -	if (ret < 0) {
> -		pm_runtime_put(fmd->pmf);
> +	ret = pm_runtime_resume_and_get(fmd->pmf);
> +	if (ret < 0)
>  		return ret;
> -	}
>  
>  	fmd->num_sensors = 0;
>  
> @@ -1291,7 +1289,7 @@ static int cam_clk_prepare(struct clk_hw *hw)
>  	if (camclk->fmd->pmf == NULL)
>  		return -ENODEV;
>  
> -	ret = pm_runtime_get_sync(camclk->fmd->pmf);
> +	ret = pm_runtime_resume_and_get(camclk->fmd->pmf);
return pm_...

>  	return ret < 0 ? ret : 0;
>  }
>  
> diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
> index 1aac167abb17..2a6afb78a049 100644
> --- a/drivers/media/platform/exynos4-is/mipi-csis.c
> +++ b/drivers/media/platform/exynos4-is/mipi-csis.c
> @@ -494,7 +494,7 @@ static int s5pcsis_s_power(struct v4l2_subdev *sd, int on)
>  	struct device *dev = &state->pdev->dev;
>  
>  	if (on)
> -		return pm_runtime_get_sync(dev);
> +		return pm_runtime_resume_and_get(dev);
>  
>  	return pm_runtime_put_sync(dev);
>  }
> @@ -509,11 +509,9 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
>  
>  	if (enable) {
>  		s5pcsis_clear_counters(state);
> -		ret = pm_runtime_get_sync(&state->pdev->dev);
> -		if (ret && ret != 1) {
> -			pm_runtime_put_noidle(&state->pdev->dev);
> +		ret = pm_runtime_resume_and_get(&state->pdev->dev);
> +		if (ret && ret != 1)

It won't be equal to 1 as pm_runtime_resume_and_get only returns <= 0

>  			return ret;
> -		}
>  	}
>  
>  	mutex_lock(&state->lock);



From Jonathan.Cameron at Huawei.com  Fri Apr 30 18:50:01 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 18:50:01 +0100
Subject: [PATCH v4 63/79] media: exynos-gsc: use
 pm_runtime_resume_and_get()
In-Reply-To: <31bdadf2f59e86c6a315ec390b44c6c681af6647.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <31bdadf2f59e86c6a315ec390b44c6c681af6647.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430185001.00005e76@Huawei.com>

On Wed, 28 Apr 2021 16:52:24 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Reviewed-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> index 27a3c92c73bc..09551e96ac15 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
> @@ -58,7 +58,7 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
>  	struct gsc_ctx *ctx = q->drv_priv;
>  	int ret;
>  
> -	ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
> +	ret = pm_runtime_resume_and_get(&ctx->gsc_dev->pdev->dev);
>  	return ret > 0 ? 0 : ret;
return pm_runtime_resume_and_get()

as
static inline int pm_runtime_resume_and_get(struct device *dev)
{
	int ret;

	ret = __pm_runtime_resume(dev, RPM_GET_PUT);
	if (ret < 0) {
		pm_runtime_put_noidle(dev);
		return ret;
	}

	return 0;
}

Can't return >= 0

>  }
>  



From catalin.marinas at arm.com  Fri Apr 30 18:55:39 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:55:39 +0100
Subject: [PATCH v1 0/3] arm64: Boot requirements clarifications
In-Reply-To: <20210412151955.16078-1-broonie@kernel.org>
References: <20210412151955.16078-1-broonie@kernel.org>
Message-ID: <161980533328.3085.7321949668037792734.b4-ty@arm.com>

On Mon, 12 Apr 2021 16:19:52 +0100, Mark Brown wrote:
> This series makes explicit our booting requirements in a number of
> areas, mainly the initialisation of optional floating point features.
> While no issues have been encountered it seems better to be explict,
> particularly given that new extensions frequently require setup from
> higher exception levels to be functional so our list of explicit
> requirement is tending to become more and more exhaustive creating some
> expecation that requirements will be stated clearly.
> 
> [...]

Applied to arm64 (for-next/core), thanks!

[1/3] arm64: Relax booting requirements for configuration of traps
      https://git.kernel.org/arm64/c/ee61f36d3e46
[2/3] arm64: Explicitly require that FPSIMD instructions do not trap
      https://git.kernel.org/arm64/c/b30dbf4d9362
[3/3] arm64: Explicitly document boot requirements for SVE
      https://git.kernel.org/arm64/c/ff1c42cdfbcf

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 30 18:56:04 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:56:04 +0100
Subject: [PATCH] arm64: doc: Add brk/mmap/mremap() to the Tagged Address
 ABI Exceptions
In-Reply-To: <20210423175134.14838-1-catalin.marinas@arm.com>
References: <20210423175134.14838-1-catalin.marinas@arm.com>
Message-ID: <161980533328.3085.2858598378430820999.b4-ty@arm.com>

On Fri, 23 Apr 2021 18:51:34 +0100, Catalin Marinas wrote:
> Prior to commit dcde237319e6 ("mm: Avoid creating virtual address
> aliases in brk()/mmap()/mremap()"), the kernel allowed tagged addresses
> to be passed to the brk/mmap/mremap() syscalls. This relaxation was
> tightened in 5.6 (backported to stable 5.4) but the
> tagged-address-abi.rst document was only partially updated.

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: doc: Add brk/mmap/mremap() to the Tagged Address ABI Exceptions
      https://git.kernel.org/arm64/c/75516c75a72b

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 30 18:56:22 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:56:22 +0100
Subject: [PATCH] arm64: cpufeatures: use min and max
In-Reply-To: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
References: <alpine.DEB.2.22.394.2104292246300.16899@hadrien>
Message-ID: <161980533328.3085.14514073323541286599.b4-ty@arm.com>

On Thu, 29 Apr 2021 22:50:46 +0200 (CEST), Julia Lawall wrote:
> Use min and max to make the effect more clear.
> 
> Generated by: scripts/coccinelle/misc/minmax.cocci

Applied to arm64 (for-next/core), thanks!

[1/1] arm64: cpufeatures: use min and max
      https://git.kernel.org/arm64/c/f6334b1798c1

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 30 18:57:53 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:57:53 +0100
Subject: [PATCH] arm64/vdso: Discard .note.gnu.property sections in vDSO
In-Reply-To: <20210423205159.830854-1-morbo@google.com>
References: <20210423205159.830854-1-morbo@google.com>
Message-ID: <161980533328.3085.7369684692351119549.b4-ty@arm.com>

On Fri, 23 Apr 2021 13:51:59 -0700, Bill Wendling wrote:
> The arm64 assembler in binutils 2.32 and above generates a program
> property note in a note section, .note.gnu.property, to encode used x86
> ISAs and features. But the kernel linker script only contains a single
> NOTE segment:
> 
>   PHDRS
>   {
>     text    PT_LOAD    FLAGS(5) FILEHDR PHDRS; /* PF_R|PF_X */
>     dynamic PT_DYNAMIC FLAGS(4);               /* PF_R */
>     note    PT_NOTE    FLAGS(4);               /* PF_R */
>   }
> 
> [...]

Applied to arm64 (for-next/core). Thanks Bill and Szabolcs for
clarifying the need for this patch.

[1/1] arm64/vdso: Discard .note.gnu.property sections in vDSO
      https://git.kernel.org/arm64/c/388708028e69

-- 
Catalin



From catalin.marinas at arm.com  Fri Apr 30 18:58:06 2021
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 30 Apr 2021 18:58:06 +0100
Subject: [PATCH v2] psci: Remove unneeded semicolon
In-Reply-To: <1619659589-4775-1-git-send-email-yang.lee@linux.alibaba.com>
References: <1619659589-4775-1-git-send-email-yang.lee@linux.alibaba.com>
Message-ID: <161980533328.3085.13894440622093726768.b4-ty@arm.com>

On Thu, 29 Apr 2021 09:26:29 +0800, Yang Li wrote:
> Eliminate the following coccicheck warning:
> ./drivers/firmware/psci/psci.c:141:2-3: Unneeded semicolon

Applied to arm64 (for-next/core), thanks!

[1/1] psci: Remove unneeded semicolon
      https://git.kernel.org/arm64/c/9b924f4f0d8f

-- 
Catalin



From Jonathan.Cameron at Huawei.com  Fri Apr 30 18:58:16 2021
From: Jonathan.Cameron at Huawei.com (Jonathan Cameron)
Date: Fri, 30 Apr 2021 18:58:16 +0100
Subject: [PATCH v4 73/79] media: stm32: use pm_runtime_resume_and_get()
In-Reply-To: <cd918677e36e89196670cacd7027569e741f7d98.1619621413.git.mchehab+huawei@kernel.org>
References: <cover.1619621413.git.mchehab+huawei@kernel.org>
 <cd918677e36e89196670cacd7027569e741f7d98.1619621413.git.mchehab+huawei@kernel.org>
Message-ID: <20210430185816.00000ef5@Huawei.com>

On Wed, 28 Apr 2021 16:52:34 +0200
Mauro Carvalho Chehab <mchehab+huawei at kernel.org> wrote:

> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
> 
> Use the new API, in order to cleanup the error check logic.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei at kernel.org>
> ---
>  drivers/media/platform/stm32/stm32-dcmi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index bbcc2254fa2e..5f4e1db8cfcd 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -723,11 +723,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
>  	u32 val = 0;
>  	int ret;
>  
> -	ret = pm_runtime_get_sync(dcmi->dev);
> +	ret = pm_runtime_resume_and_get(dcmi->dev);
>  	if (ret < 0) {
>  		dev_err(dcmi->dev, "%s: Failed to start streaming, cannot get sync (%d)\n",
>  			__func__, ret);
> -		goto err_pm_put;
> +		goto err_unlock;

maybe err_unlocked; to indicate the lock isn't held.  This briefly confused me.

>  	}
>  
>  	ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
> @@ -848,6 +848,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
>  
>  err_pm_put:
>  	pm_runtime_put(dcmi->dev);
> +err_unlock:
>  	spin_lock_irq(&dcmi->irqlock);
>  	/*
>  	 * Return all buffers to vb2 in QUEUED state.



From broonie at kernel.org  Fri Apr 30 19:01:14 2021
From: broonie at kernel.org (Mark Brown)
Date: Fri, 30 Apr 2021 19:01:14 +0100
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <CAHp75VfBSjHP1LJZJTdwXzGuE2YjxdW6r7Zf6ofHsquJBPMyWA@mail.gmail.com>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
 <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
 <20210427143457.GI4605@sirena.org.uk>
 <YIglWpz8lSidXmDd@smile.fi.intel.com>
 <CAHp75VfBSjHP1LJZJTdwXzGuE2YjxdW6r7Zf6ofHsquJBPMyWA@mail.gmail.com>
Message-ID: <20210430180114.GF5981@sirena.org.uk>

On Fri, Apr 30, 2021 at 07:29:48PM +0300, Andy Shevchenko wrote:

> One item is still unclear to me. I noticed that you started already
> applying patches for-next release cycle (if I understood it
> correctly). Hence the question should or shouldn't I resend this

No I haven't, I'm only applying things to for-5.13.  I've not even
created for-5.14 yet, that will only get created once -rc1 is out and
nothing for it is fixed yet.  If I look at it and find an issue I will
tell you, if I've not said anything and I've got through my first batch
of v5.14 stuff it's gone AWOL and you should 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/20210430/db948cd0/attachment.sig>

From elver at google.com  Fri Apr 30 19:11:26 2021
From: elver at google.com (Marco Elver)
Date: Fri, 30 Apr 2021 20:11:26 +0200
Subject: [PATCH 1/3] sparc64: Add compile-time asserts for siginfo_t
 offsets
In-Reply-To: <m1im43zn2g.fsf@fess.ebiederm.org>
References: <20210429190734.624918-1-elver@google.com>
 <m1im43zn2g.fsf@fess.ebiederm.org>
Message-ID: <CANpmjNMxehkR+NHyJpqfSBYo9Ru7Hbs8j7c=G0Q5+966orQunw@mail.gmail.com>

On Fri, 30 Apr 2021 at 19:42, Eric W. Biederman <ebiederm at xmission.com> wrote:
>
> Marco Elver <elver at google.com> writes:
>
> > To help catch ABI breaks at compile-time, add compile-time assertions to
> > verify the siginfo_t layout. Unlike other architectures, sparc64 is
> > special, because it is one of few architectures requiring si_trapno.
> > ABI breaks around that field would only be caught here.
>
> Arnd Bergman recently pointed out that we can move si_trapno into the
> union and make it specific to a handful of signals.  Like we do other
> items in the union.
>
> Given that the code of perf_sigtrap is pretty much broken if si_trapno
> needs to be filled out.  I think we should make that change before
> we set this ABI in stone like this.
>
> Otherwise this looks good.

Thanks, that's reasonable -- I'll reply to the other thread in a few minutes.

-- Marco

> Eric
>
> > Link: https://lkml.kernel.org/r/m11rat9f85.fsf at fess.ebiederm.org
> > Suggested-by: Eric W. Biederman <ebiederm at xmission.com>
> > Signed-off-by: Marco Elver <elver at google.com>
> > ---
> >  arch/sparc/kernel/signal32.c  | 34 ++++++++++++++++++++++++++++++++++
> >  arch/sparc/kernel/signal_64.c | 33 +++++++++++++++++++++++++++++++++
> >  2 files changed, 67 insertions(+)
> >
> > diff --git a/arch/sparc/kernel/signal32.c b/arch/sparc/kernel/signal32.c
> > index e9695a06492f..778ed5c26d4a 100644
> > --- a/arch/sparc/kernel/signal32.c
> > +++ b/arch/sparc/kernel/signal32.c
> > @@ -745,3 +745,37 @@ asmlinkage int do_sys32_sigstack(u32 u_ssptr, u32 u_ossptr, unsigned long sp)
> >  out:
> >       return ret;
> >  }
> > +
> > +/*
> > + * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
> > + * changes likely come with new fields that should be added below.
> > + */
> > +static_assert(NSIGILL        == 11);
> > +static_assert(NSIGFPE        == 15);
> > +static_assert(NSIGSEGV       == 9);
> > +static_assert(NSIGBUS        == 5);
> > +static_assert(NSIGTRAP       == 6);
> > +static_assert(NSIGCHLD       == 6);
> > +static_assert(NSIGSYS        == 2);
> > +static_assert(offsetof(compat_siginfo_t, si_signo)   == 0x00);
> > +static_assert(offsetof(compat_siginfo_t, si_errno)   == 0x04);
> > +static_assert(offsetof(compat_siginfo_t, si_code)    == 0x08);
> > +static_assert(offsetof(compat_siginfo_t, si_pid)     == 0x0c);
> > +static_assert(offsetof(compat_siginfo_t, si_uid)     == 0x10);
> > +static_assert(offsetof(compat_siginfo_t, si_tid)     == 0x0c);
> > +static_assert(offsetof(compat_siginfo_t, si_overrun) == 0x10);
> > +static_assert(offsetof(compat_siginfo_t, si_status)  == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_utime)   == 0x18);
> > +static_assert(offsetof(compat_siginfo_t, si_stime)   == 0x1c);
> > +static_assert(offsetof(compat_siginfo_t, si_value)   == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_int)     == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_ptr)     == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_addr)    == 0x0c);
> > +static_assert(offsetof(compat_siginfo_t, si_trapno)  == 0x10);
> > +static_assert(offsetof(compat_siginfo_t, si_addr_lsb)        == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_lower)   == 0x18);
> > +static_assert(offsetof(compat_siginfo_t, si_upper)   == 0x1c);
> > +static_assert(offsetof(compat_siginfo_t, si_pkey)    == 0x18);
> > +static_assert(offsetof(compat_siginfo_t, si_perf)    == 0x14);
> > +static_assert(offsetof(compat_siginfo_t, si_band)    == 0x0c);
> > +static_assert(offsetof(compat_siginfo_t, si_fd)              == 0x10);
> > diff --git a/arch/sparc/kernel/signal_64.c b/arch/sparc/kernel/signal_64.c
> > index a0eec62c825d..c9bbf5f29078 100644
> > --- a/arch/sparc/kernel/signal_64.c
> > +++ b/arch/sparc/kernel/signal_64.c
> > @@ -556,3 +556,36 @@ void do_notify_resume(struct pt_regs *regs, unsigned long orig_i0, unsigned long
> >       user_enter();
> >  }
> >
> > +/*
> > + * Compile-time assertions for siginfo_t offsets. Check NSIG* as well, as
> > + * changes likely come with new fields that should be added below.
> > + */
> > +static_assert(NSIGILL        == 11);
> > +static_assert(NSIGFPE        == 15);
> > +static_assert(NSIGSEGV       == 9);
> > +static_assert(NSIGBUS        == 5);
> > +static_assert(NSIGTRAP       == 6);
> > +static_assert(NSIGCHLD       == 6);
> > +static_assert(NSIGSYS        == 2);
> > +static_assert(offsetof(siginfo_t, si_signo)  == 0x00);
> > +static_assert(offsetof(siginfo_t, si_errno)  == 0x04);
> > +static_assert(offsetof(siginfo_t, si_code)   == 0x08);
> > +static_assert(offsetof(siginfo_t, si_pid)    == 0x10);
> > +static_assert(offsetof(siginfo_t, si_uid)    == 0x14);
> > +static_assert(offsetof(siginfo_t, si_tid)    == 0x10);
> > +static_assert(offsetof(siginfo_t, si_overrun)        == 0x14);
> > +static_assert(offsetof(siginfo_t, si_status) == 0x18);
> > +static_assert(offsetof(siginfo_t, si_utime)  == 0x20);
> > +static_assert(offsetof(siginfo_t, si_stime)  == 0x28);
> > +static_assert(offsetof(siginfo_t, si_value)  == 0x18);
> > +static_assert(offsetof(siginfo_t, si_int)    == 0x18);
> > +static_assert(offsetof(siginfo_t, si_ptr)    == 0x18);
> > +static_assert(offsetof(siginfo_t, si_addr)   == 0x10);
> > +static_assert(offsetof(siginfo_t, si_trapno) == 0x18);
> > +static_assert(offsetof(siginfo_t, si_addr_lsb)       == 0x20);
> > +static_assert(offsetof(siginfo_t, si_lower)  == 0x28);
> > +static_assert(offsetof(siginfo_t, si_upper)  == 0x30);
> > +static_assert(offsetof(siginfo_t, si_pkey)   == 0x28);
> > +static_assert(offsetof(siginfo_t, si_perf)   == 0x20);
> > +static_assert(offsetof(siginfo_t, si_band)   == 0x10);
> > +static_assert(offsetof(siginfo_t, si_fd)     == 0x14);


From robh at kernel.org  Fri Apr 30 19:17:01 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 13:17:01 -0500
Subject: [PATCH v7 7/9] perf: arm64: Add test for userspace counter access
 on heterogeneous systems
In-Reply-To: <20210430164616.pzb7yxrsugexso25@gabell>
References: <20210420031511.2348977-1-robh@kernel.org>
 <20210420031511.2348977-8-robh@kernel.org>
 <20210430164616.pzb7yxrsugexso25@gabell>
Message-ID: <CAL_JsqLtkik656hjHMqvPc3Ta6qR+nWx1BxPcj8GvzYypTUVWQ@mail.gmail.com>

On Fri, Apr 30, 2021 at 11:46 AM Masayoshi Mizuma <msys.mizuma at gmail.com> wrote:
>
> On Mon, Apr 19, 2021 at 10:15:09PM -0500, Rob Herring wrote:
> > Userspace counter access only works on heterogeneous systems with some
> > restrictions. The userspace process must be pinned to a homogeneous
> > subset of CPUs and must open the corresponding PMU for those CPUs. This
> > commit adds a test implementing these requirements.
> >
> > Signed-off-by: Rob Herring <robh at kernel.org>
> > ---
> > v6:
> >  - Add a check on cap_user_rdpmc
> > v5:
> >  - Adapt to libperf mmap API changes
> > v4:
> >  - Update perf_evsel__mmap params
> > v2:
> >  - Drop all but heterogeneous test as others covered by libperf tests
> >  - Rework to use libperf
> > ---
> >  tools/perf/arch/arm64/include/arch-tests.h |   7 +
> >  tools/perf/arch/arm64/tests/Build          |   1 +
> >  tools/perf/arch/arm64/tests/arch-tests.c   |   4 +
> >  tools/perf/arch/arm64/tests/user-events.c  | 177 +++++++++++++++++++++
> >  4 files changed, 189 insertions(+)
> >  create mode 100644 tools/perf/arch/arm64/tests/user-events.c
> >
> > diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> > index 90ec4c8cb880..380ad34a3f09 100644
> > --- a/tools/perf/arch/arm64/include/arch-tests.h
> > +++ b/tools/perf/arch/arm64/include/arch-tests.h
> > @@ -2,11 +2,18 @@
> >  #ifndef ARCH_TESTS_H
> >  #define ARCH_TESTS_H
> >
> > +#include <linux/compiler.h>
> > +
> >  #ifdef HAVE_DWARF_UNWIND_SUPPORT
> >  struct thread;
> >  struct perf_sample;
> > +int test__arch_unwind_sample(struct perf_sample *sample,
> > +                          struct thread *thread);
> >  #endif
>
> Hello,
>
> I got the following compile error with aarch64 on Fedora33.
>
>     # make tools/perf
>     ...
>     In file included from arch/arm64/tests/arch-tests.c:4:
>     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
>        10 | int test__arch_unwind_sample(struct perf_sample *sample,
>           |     ^~~~~~~~~~~~~~~~~~~~~~~~
>     In file included from arch/arm64/tests/arch-tests.c:3:
>     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
>       140 | int test__arch_unwind_sample(struct perf_sample *sample,
>           |     ^~~~~~~~~~~~~~~~~~~~~~~~
>     cc1: all warnings being treated as errors
>     make[8]: *** [/root//libperf_v7/tools/build/Makefile.build:97: /root/libperf_v7/tools/perf/arch/arm64/tests/arch-tests.o] Error 1
>     make[8]: *** Waiting for unfinished jobs....
>     In file included from arch/arm64/tests/user-events.c:13:
>     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
>        10 | int test__arch_unwind_sample(struct perf_sample *sample,
>           |     ^~~~~~~~~~~~~~~~~~~~~~~~
>     In file included from arch/arm64/tests/user-events.c:12:
>     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
>       140 | int test__arch_unwind_sample(struct perf_sample *sample,
>           |     ^~~~~~~~~~~~~~~~~~~~~~~~
>     cc1: all warnings being treated as errors
>     ...
>
> The error is gone after the following patch is applied.

Thanks. Honestly, I'm not sure why it was there in the first place.
Looking at the git history and this series history doesn't give any
clues.

> ---
>  tools/perf/arch/arm64/include/arch-tests.h | 7 -------
>  1 file changed, 7 deletions(-)
>
> diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> index ddfa7460e..7ff2e29bd 100644
> --- a/tools/perf/arch/arm64/include/arch-tests.h
> +++ b/tools/perf/arch/arm64/include/arch-tests.h
> @@ -4,13 +4,6 @@
>
>  #include <linux/compiler.h>
>
> -#ifdef HAVE_DWARF_UNWIND_SUPPORT
> -struct thread;
> -struct perf_sample;
> -int test__arch_unwind_sample(struct perf_sample *sample,
> -                            struct thread *thread);
> -#endif
> -
>  extern struct test arch_tests[];
>  int test__rd_pinned(struct test __maybe_unused *test,
>                        int __maybe_unused subtest);
> --
>
> Thanks!
> Masa
>
> >
> >  extern struct test arch_tests[];
> > +int test__rd_pinned(struct test __maybe_unused *test,
> > +                    int __maybe_unused subtest);
> > +
> >
> >  #endif
> > diff --git a/tools/perf/arch/arm64/tests/Build b/tools/perf/arch/arm64/tests/Build
> > index a61c06bdb757..3f9a20c17fc6 100644
> > --- a/tools/perf/arch/arm64/tests/Build
> > +++ b/tools/perf/arch/arm64/tests/Build
> > @@ -1,4 +1,5 @@
> >  perf-y += regs_load.o
> >  perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
> >
> > +perf-y += user-events.o
> >  perf-y += arch-tests.o
> > diff --git a/tools/perf/arch/arm64/tests/arch-tests.c b/tools/perf/arch/arm64/tests/arch-tests.c
> > index 5b1543c98022..80ce7bd3c16d 100644
> > --- a/tools/perf/arch/arm64/tests/arch-tests.c
> > +++ b/tools/perf/arch/arm64/tests/arch-tests.c
> > @@ -10,6 +10,10 @@ struct test arch_tests[] = {
> >               .func = test__dwarf_unwind,
> >       },
> >  #endif
> > +     {
> > +             .desc = "Pinned CPU user counter access",
> > +             .func = test__rd_pinned,
> > +     },
> >       {
> >               .func = NULL,
> >       },
> > diff --git a/tools/perf/arch/arm64/tests/user-events.c b/tools/perf/arch/arm64/tests/user-events.c
> > new file mode 100644
> > index 000000000000..c8efc6b369e6
> > --- /dev/null
> > +++ b/tools/perf/arch/arm64/tests/user-events.c
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#include <unistd.h>
> > +#include <sched.h>
> > +#include <cpumap.h>
> > +
> > +#include <perf/core.h>
> > +#include <perf/threadmap.h>
> > +#include <perf/evsel.h>
> > +
> > +#include "pmu.h"
> > +#include "debug.h"
> > +#include "tests/tests.h"
> > +#include "arch-tests.h"
> > +
> > +static int run_test(struct perf_evsel *evsel)
> > +{
> > +     int n;
> > +     volatile int tmp = 0;
> > +     u64 delta, i, loops = 1000;
> > +     struct perf_counts_values counts = { .val = 0 };
> > +
> > +     for (n = 0; n < 6; n++) {
> > +             u64 stamp, now;
> > +
> > +             perf_evsel__read(evsel, 0, 0, &counts);
> > +             stamp = counts.val;
> > +
> > +             for (i = 0; i < loops; i++)
> > +                     tmp++;
> > +
> > +             perf_evsel__read(evsel, 0, 0, &counts);
> > +             now = counts.val;
> > +             loops *= 10;
> > +
> > +             delta = now - stamp;
> > +             pr_debug("%14d: %14llu\n", n, (long long)delta);
> > +
> > +             if (!delta)
> > +                     break;
> > +     }
> > +     return delta ? 0 : -1;
> > +}
> > +
> > +static struct perf_pmu *pmu_for_cpu(int cpu)
> > +{
> > +     int acpu, idx;
> > +     struct perf_pmu *pmu = NULL;
> > +
> > +     while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> > +             if (pmu->is_uncore)
> > +                     continue;
> > +             perf_cpu_map__for_each_cpu(acpu, idx, pmu->cpus)
> > +                     if (acpu == cpu)
> > +                             return pmu;
> > +     }
> > +     return NULL;
> > +}
> > +
> > +static bool pmu_is_homogeneous(void)
> > +{
> > +     int core_cnt = 0;
> > +     struct perf_pmu *pmu = NULL;
> > +
> > +     while ((pmu = perf_pmu__scan(pmu)) != NULL) {
> > +             if (!pmu->is_uncore && !perf_cpu_map__empty(pmu->cpus))
> > +                     core_cnt++;
> > +     }
> > +     return core_cnt == 1;
> > +}
> > +
> > +static int libperf_print(enum libperf_print_level level,
> > +                      const char *fmt, va_list ap)
> > +{
> > +     (void)level;
> > +     return vfprintf(stderr, fmt, ap);
> > +}
> > +
> > +static struct perf_evsel *perf_init(struct perf_event_attr *attr)
> > +{
> > +     int err;
> > +     struct perf_thread_map *threads;
> > +     struct perf_evsel *evsel;
> > +     struct perf_event_mmap_page *pc;
> > +
> > +     libperf_init(libperf_print);
> > +
> > +     threads = perf_thread_map__new_dummy();
> > +     if (!threads) {
> > +             pr_err("failed to create threads\n");
> > +             return NULL;
> > +     }
> > +
> > +     perf_thread_map__set_pid(threads, 0, 0);
> > +
> > +     evsel = perf_evsel__new(attr);
> > +     if (!evsel) {
> > +             pr_err("failed to create evsel\n");
> > +             goto out_thread;
> > +     }
> > +
> > +     err = perf_evsel__open(evsel, NULL, threads);
> > +     if (err) {
> > +             pr_err("failed to open evsel\n");
> > +             goto out_open;
> > +     }
> > +
> > +     if (perf_evsel__mmap(evsel, 0)) {
> > +             pr_err("failed to mmap evsel\n");
> > +             goto out_mmap;
> > +     }
> > +
> > +     pc = perf_evsel__mmap_base(evsel, 0, 0);
> > +     if (!pc->cap_user_rdpmc) {
> > +             pr_err("userspace access not enabled\n");
> > +             goto out_mmap;
> > +     }
> > +
> > +     return evsel;
> > +
> > +out_mmap:
> > +     perf_evsel__close(evsel);
> > +out_open:
> > +     perf_evsel__delete(evsel);
> > +out_thread:
> > +     perf_thread_map__put(threads);
> > +     return NULL;
> > +}
> > +
> > +int test__rd_pinned(struct test __maybe_unused *test,
> > +                 int __maybe_unused subtest)
> > +{
> > +     int cpu, cputmp, ret = -1;
> > +     struct perf_evsel *evsel;
> > +     struct perf_event_attr attr = {
> > +             .config = 0x8, /* Instruction count */
> > +             .config1 = 0, /* 32-bit counter */
> > +             .exclude_kernel = 1,
> > +     };
> > +     cpu_set_t cpu_set;
> > +     struct perf_pmu *pmu;
> > +
> > +     if (pmu_is_homogeneous())
> > +             return TEST_SKIP;
> > +
> > +     cpu = sched_getcpu();
> > +     pmu = pmu_for_cpu(cpu);
> > +     if (!pmu)
> > +             return -1;
> > +     attr.type = pmu->type;
> > +
> > +     CPU_ZERO(&cpu_set);
> > +     perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus)
> > +             CPU_SET(cpu, &cpu_set);
> > +     if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
> > +             pr_err("Could not set affinity\n");
> > +
> > +     evsel = perf_init(&attr);
> > +     if (!evsel)
> > +             return -1;
> > +
> > +     perf_cpu_map__for_each_cpu(cpu, cputmp, pmu->cpus) {
> > +             CPU_ZERO(&cpu_set);
> > +             CPU_SET(cpu, &cpu_set);
> > +             if (sched_setaffinity(0, sizeof(cpu_set), &cpu_set) < 0)
> > +                     pr_err("Could not set affinity\n");
> > +
> > +             pr_debug("Running on CPU %d\n", cpu);
> > +
> > +             ret = run_test(evsel);
> > +             if (ret)
> > +                     break;
> > +     }
> > +
> > +     perf_evsel__close(evsel);
> > +     perf_evsel__delete(evsel);
> > +     return ret;
> > +}
> > --
> > 2.27.0
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From robh at kernel.org  Fri Apr 30 19:20:58 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 13:20:58 -0500
Subject: [PATCH v7 7/9] perf: arm64: Add test for userspace counter access
 on heterogeneous systems
In-Reply-To: <CAL_JsqLtkik656hjHMqvPc3Ta6qR+nWx1BxPcj8GvzYypTUVWQ@mail.gmail.com>
References: <20210420031511.2348977-1-robh@kernel.org>
 <20210420031511.2348977-8-robh@kernel.org>
 <20210430164616.pzb7yxrsugexso25@gabell>
 <CAL_JsqLtkik656hjHMqvPc3Ta6qR+nWx1BxPcj8GvzYypTUVWQ@mail.gmail.com>
Message-ID: <CAL_JsqLvHh5Ekpmb_au8Y9a7zF4w_izgaVnhzi9255XuqQUjrQ@mail.gmail.com>

On Fri, Apr 30, 2021 at 1:17 PM Rob Herring <robh at kernel.org> wrote:
>
> On Fri, Apr 30, 2021 at 11:46 AM Masayoshi Mizuma <msys.mizuma at gmail.com> wrote:
> >
> > On Mon, Apr 19, 2021 at 10:15:09PM -0500, Rob Herring wrote:
> > > Userspace counter access only works on heterogeneous systems with some
> > > restrictions. The userspace process must be pinned to a homogeneous
> > > subset of CPUs and must open the corresponding PMU for those CPUs. This
> > > commit adds a test implementing these requirements.
> > >
> > > Signed-off-by: Rob Herring <robh at kernel.org>
> > > ---
> > > v6:
> > >  - Add a check on cap_user_rdpmc
> > > v5:
> > >  - Adapt to libperf mmap API changes
> > > v4:
> > >  - Update perf_evsel__mmap params
> > > v2:
> > >  - Drop all but heterogeneous test as others covered by libperf tests
> > >  - Rework to use libperf
> > > ---
> > >  tools/perf/arch/arm64/include/arch-tests.h |   7 +
> > >  tools/perf/arch/arm64/tests/Build          |   1 +
> > >  tools/perf/arch/arm64/tests/arch-tests.c   |   4 +
> > >  tools/perf/arch/arm64/tests/user-events.c  | 177 +++++++++++++++++++++
> > >  4 files changed, 189 insertions(+)
> > >  create mode 100644 tools/perf/arch/arm64/tests/user-events.c
> > >
> > > diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> > > index 90ec4c8cb880..380ad34a3f09 100644
> > > --- a/tools/perf/arch/arm64/include/arch-tests.h
> > > +++ b/tools/perf/arch/arm64/include/arch-tests.h
> > > @@ -2,11 +2,18 @@
> > >  #ifndef ARCH_TESTS_H
> > >  #define ARCH_TESTS_H
> > >
> > > +#include <linux/compiler.h>
> > > +
> > >  #ifdef HAVE_DWARF_UNWIND_SUPPORT
> > >  struct thread;
> > >  struct perf_sample;
> > > +int test__arch_unwind_sample(struct perf_sample *sample,
> > > +                          struct thread *thread);
> > >  #endif
> >
> > Hello,
> >
> > I got the following compile error with aarch64 on Fedora33.
> >
> >     # make tools/perf
> >     ...
> >     In file included from arch/arm64/tests/arch-tests.c:4:
> >     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
> >        10 | int test__arch_unwind_sample(struct perf_sample *sample,
> >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> >     In file included from arch/arm64/tests/arch-tests.c:3:
> >     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
> >       140 | int test__arch_unwind_sample(struct perf_sample *sample,
> >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> >     cc1: all warnings being treated as errors
> >     make[8]: *** [/root//libperf_v7/tools/build/Makefile.build:97: /root/libperf_v7/tools/perf/arch/arm64/tests/arch-tests.o] Error 1
> >     make[8]: *** Waiting for unfinished jobs....
> >     In file included from arch/arm64/tests/user-events.c:13:
> >     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
> >        10 | int test__arch_unwind_sample(struct perf_sample *sample,
> >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> >     In file included from arch/arm64/tests/user-events.c:12:
> >     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
> >       140 | int test__arch_unwind_sample(struct perf_sample *sample,
> >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> >     cc1: all warnings being treated as errors
> >     ...
> >
> > The error is gone after the following patch is applied.
>
> Thanks. Honestly, I'm not sure why it was there in the first place.
> Looking at the git history and this series history doesn't give any
> clues.

Well, except that both x86 and powerpc have the same hunk in their
arch-tests.h. Do you see errors on those arches?

Rob


From andy.shevchenko at gmail.com  Fri Apr 30 19:43:19 2021
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 30 Apr 2021 21:43:19 +0300
Subject: [PATCH v2 00/14] spi: pxa2xx: Set of cleanups
In-Reply-To: <20210430180114.GF5981@sirena.org.uk>
References: <20210423182441.50272-1-andriy.shevchenko@linux.intel.com>
 <CAHp75VeiHsk15QoG3X-OV8V8jqzCNeKkif9V=cx4nvKVHaKbKA@mail.gmail.com>
 <20210427143457.GI4605@sirena.org.uk> <YIglWpz8lSidXmDd@smile.fi.intel.com>
 <CAHp75VfBSjHP1LJZJTdwXzGuE2YjxdW6r7Zf6ofHsquJBPMyWA@mail.gmail.com>
 <20210430180114.GF5981@sirena.org.uk>
Message-ID: <CAHp75Vd0MKSZJpw0=qKtORmHRijw0HZLGz+W=sG_cyhLr1JPoQ@mail.gmail.com>

On Fri, Apr 30, 2021 at 9:01 PM Mark Brown <broonie at kernel.org> wrote:
> On Fri, Apr 30, 2021 at 07:29:48PM +0300, Andy Shevchenko wrote:
>
> > One item is still unclear to me. I noticed that you started already
> > applying patches for-next release cycle (if I understood it
> > correctly). Hence the question should or shouldn't I resend this
>
> No I haven't, I'm only applying things to for-5.13.  I've not even
> created for-5.14 yet, that will only get created once -rc1 is out and
> nothing for it is fixed yet.  If I look at it and find an issue I will
> tell you, if I've not said anything and I've got through my first batch
> of v5.14 stuff it's gone AWOL and you should resend.

Ah, okay, it means I misread the idea of applied patches.
Thanks for clarifying this for me!

-- 
With Best Regards,
Andy Shevchenko


From liam.howlett at oracle.com  Fri Apr 30 19:48:08 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Fri, 30 Apr 2021 18:48:08 +0000
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <m1czud6krk.fsf@fess.ebiederm.org>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck> <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver> <m1y2d8dfx8.fsf@fess.ebiederm.org>
 <20210423200126.otleormmjh22joj3@revolver> <m1czud6krk.fsf@fess.ebiederm.org>
Message-ID: <20210430184757.mez7ujmyzm43g6z2@revolver>

This is way out of scope for what I'm doing.  I'm trying to fix a call
to the wrong mm API.  I was trying to clean up any obvious errors in
calling functions which were exposed by fixing that error.  If you want
this fixed differently, then please go ahead and tackle the problems you
see.

Thank you,
Liam


* Eric W. Biederman <ebiederm at xmission.com> [210429 13:52]:
> 
> This entire discussion seems to come down to what are the expected
> semantics of arm64_notify_segfault.  The use of this helper in
> swp_handler and user_cache_main_handler is clearly for the purposes of
> instruction emulation.  With instruction emulation it is a bug if the
> emulated instruction behaves differently than a real instruction in
> the same circumstances.
> 
> To properly fix the instruction emulation in arm64_notify_segfault it
> looks to me that the proper solution is to call __do_page_fault or
> handle_mm_fault the way do_page_fault does and them parse the VM_FAULT
> code for which signal to generate.
> 
> I would probably rename arm64_notify_segfault to arm64_emulate_fault, or
> possibly arm64_notify_fault while fixing the emulation so that it
> can return different signals and so that people don't have to guess
> what the function is supposed to do.
> 
> For the specific case of sigreturn and rt_sigreturn it looks sufficient
> to use the fixed arm64_notify_segfault.  As it appears the that the code
> is attempting to act like it is emulating an instruction that does not
> exist.
> 
> 
> There is an argument that sigreturn and rt_sigreturn do a poor enough
> job of acting like the fault was caused by an instruction, as well
> as failing for other reasons it might make more sense to just have
> sigreturn and rt_sigreturn call "force_sig(SIGSEGV);"  But that seems
> out of scope of what you are trying to fix right now so I would not
> worry about it.
> 
> Eric

From acme at kernel.org  Fri Apr 30 19:59:08 2021
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Fri, 30 Apr 2021 15:59:08 -0300
Subject: [PATCH v7 0/9] arm64 userspace counter access support
In-Reply-To: <20210420031511.2348977-1-robh@kernel.org>
References: <20210420031511.2348977-1-robh@kernel.org>
Message-ID: <YIxTfKh6/uxvd0Fu@kernel.org>

Em Mon, Apr 19, 2021 at 10:15:02PM -0500, Rob Herring escreveu:
> Hi all,
> 
> Another version of arm64 userspace counter access support. I sent out
> the libperf bits separately and those are now applied (Thanks!), so this
> is just the arm64 bits.
> 
> 
> This originally resurrected Raphael's series[1] to enable userspace counter
> access on arm64. My previous versions are here[2][3][4][5][6][7]. A git
> branch is here[8].

Rob, please don't mix kernel patches with tools patches. The kernel
bits, if arch specific should go via the arch maintainer, core stuff to
PeterZ/Ingo/bpetkov/tglx, and tooling stuff I'll collect.

We did it on purpose to avoid any semblance of kernel/tool lockstep.

The kernel changes should not prevent the tooling from working and the
tooling changes shouldn't require the kernel changes.

Preexisting kernels should work with new tools and vice versa.

Thanks,

- Arnaldo
 
> 
> Changes in v7:
>  - Handling of dirty counter leakage and reworking of context switch and
>    user access enabling. The .sched_task hook and undef instruction handler
>    are now utilized. (Patch 3)
>  - Add a userspace disable switch like x86. (Patch 5)
> 
> Changes in v6:
>  - Reworking of the handling of 64-bit counters and user access. There's
>    a new config1 flag to request user access. This takes priority over
>    the 64-bit flag and the user will get the maximum size the h/w
>    supports without chaining.
>  - The libperf evsel mmap struct is stored in its own xyarray
>  - New tests for user 64-bit and 32-bit counters
>  - Rebase to v5.12-rc2
> 
> Changes in v5:
>  - Limit enabling/disabling access to CPUs associated with the PMU
>    (supported_cpus) and with the mm_struct matching current->active_mm.
>    The x86 method of using mm_cpumask doesn't work for arm64 as it is not
>    updated.
>  - Only set cap_user_rdpmc if event is on current cpu. See patch 2.
>  - Create an mmap for every event in an evsel. This results in some changes
>    to the libperf mmap API from the last version.
>  - Rebase to v5.11-rc2
> 
> Changes in v4:
>  - Dropped 'arm64: pmu: Add hook to handle pmu-related undefined instructions'.
>    The onus is on userspace to pin itself to a homogeneous subset of CPUs
>    and avoid any aborts on heterogeneous systems, so the hook is not needed.
>  - Make perf_evsel__mmap() take pages rather than bytes for size
>  - Fix building arm64 heterogeneous test.
> 
> Changes in v3:
>  - Dropped removing x86 rdpmc test until libperf tests can run via 'perf test'
>  - Added verbose prints for tests
>  - Split adding perf_evsel__mmap() to separate patch
> 
> The following changes to the arm64 support have been made compared to
> Raphael's last version:
> 
> The major change is support for heterogeneous systems with some
> restrictions. Specifically, userspace must pin itself to like CPUs, open
> a specific PMU by type, and use h/w specific events. The tests have been
> reworked to demonstrate this.
> 
> Chained events are not supported. The problem with supporting chained
> events was there's no way to distinguish between a chained event and a
> native 64-bit counter. We could add some flag, but do self monitoring
> processes really need that? Native 64-bit counters are supported if the
> PMU h/w has support. As there's already an explicit ABI to request 64-bit
> counters, userspace can request 64-bit counters and if user
> access is not enabled, then it must retry with 32-bit counters.
> 
> Prior versions broke the build on arm32 (surprisingly never caught by
> 0-day). As a result, event_mapped and event_unmapped implementations have
> been moved into the arm64 code.
> 
> There was a bug in that pmc_width was not set in the user page. The tests
> now check for this.
> 
> The documentation has been converted to rST. I've added sections on
> chained events and heterogeneous.
> 
> The tests have been expanded to test the cycle counter access.
> 
> Rob
> 
> [1] https://lore.kernel.org/r/20190822144220.27860-1-raphael.gault at arm.com/
> [2] https://lore.kernel.org/r/20200707205333.624938-1-robh at kernel.org/
> [3] https://lore.kernel.org/r/20200828205614.3391252-1-robh at kernel.org/
> [4] https://lore.kernel.org/r/20200911215118.2887710-1-robh at kernel.org/
> [5] https://lore.kernel.org/r/20201001140116.651970-1-robh at kernel.org/
> [6] https://lore.kernel.org/r/20210114020605.3943992-1-robh at kernel.org/
> [7] https://lore.kernel.org/r/20210311000837.3630499-1-robh at kernel.org/
> [8] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git user-perf-event-v7
> 
> Raphael Gault (4):
>   arm64: Restrict undef hook for cpufeature registers
>   arm64: pmu: Add function implementation to update event index in
>     userpage
>   arm64: perf: Enable PMU counter direct access for perf event
>   Documentation: arm64: Document PMU counters access from userspace
> 
> Rob Herring (5):
>   drivers/perf: arm_pmu: Export the per_cpu cpu_armpmu
>   arm64: perf: Add userspace counter access disable switch
>   libperf: Add arm64 support to perf_mmap__read_self()
>   perf: arm64: Add test for userspace counter access on heterogeneous
>     systems
>   perf: arm64: Add tests for 32-bit and 64-bit counter size userspace
>     access
> 
>  Documentation/arm64/perf.rst               |  67 +++++-
>  arch/arm64/include/asm/mmu.h               |   5 +
>  arch/arm64/kernel/cpufeature.c             |   4 +-
>  arch/arm64/kernel/perf_event.c             | 254 ++++++++++++++++++++-
>  drivers/perf/arm_pmu.c                     |   2 +-
>  include/linux/perf/arm_pmu.h               |  14 +-
>  tools/lib/perf/mmap.c                      |  98 ++++++++
>  tools/lib/perf/tests/test-evsel.c          |   2 +-
>  tools/perf/arch/arm64/include/arch-tests.h |  12 +
>  tools/perf/arch/arm64/tests/Build          |   1 +
>  tools/perf/arch/arm64/tests/arch-tests.c   |  12 +
>  tools/perf/arch/arm64/tests/user-events.c  | 215 +++++++++++++++++
>  12 files changed, 672 insertions(+), 14 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/tests/user-events.c
> 
> --
> 2.27.0

-- 

- Arnaldo


From robh at kernel.org  Fri Apr 30 20:40:00 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 14:40:00 -0500
Subject: [PATCH v4 1/4] dt-bindings: firmware: Add bindings for xilinx
 firmware
In-Reply-To: <20210429140408.23194-2-nava.manne@xilinx.com>
References: <20210429140408.23194-1-nava.manne@xilinx.com>
 <20210429140408.23194-2-nava.manne@xilinx.com>
Message-ID: <20210430194000.GA3742101@robh.at.kernel.org>

On Thu, Apr 29, 2021 at 07:34:05PM +0530, Nava kishore Manne wrote:
> Add documentation to describe Xilinx firmware driver bindings.
> Firmware driver provides an interface to firmware APIs.
> Interface APIs can be used by any driver to communicate
> to Platform Management Unit.
> 
> Signed-off-by: Nava kishore Manne <nava.manne at xilinx.com>
> ---
> Changes for v4:
>                 -Added new yaml file for xilinx firmware
>                  as suggested by Rob.
> 
>  .../firmware/xilinx/xlnx,zynqmp-firmware.yaml | 63 +++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml

What about the old doc?:

Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt

> 
> diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> new file mode 100644
> index 000000000000..4b97f005bed7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml
> @@ -0,0 +1,63 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx firmware driver
> +
> +maintainers:
> +  - Nava kishore Manne <nava.manne at xilinx.com>
> +
> +description:
> +  The zynqmp-firmware node describes the interface to platform firmware.
> +  ZynqMP has an interface to communicate with secure firmware. Firmware
> +  driver provides an interface to firmware APIs. Interface APIs can be
> +  used by any driver to communicate to PMUFW(Platform Management Unit).
> +  These requests include clock management, pin control, device control,
> +  power management service, FPGA service and other platform management
> +  services.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - description:
> +          For implementations complying for Zynq Ultrascale+ MPSoC.
> +        const: xlnx,zynqmp-firmware
> +
> +      - description:
> +          For implementations complying for Versal.
> +        const: xlnx,versal-firmware
> +
> +  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

Drop the '#'. If you want to maintain the formatting, then use '|' after 
'description:' for a literal block.

> +    $ref: /schemas/types.yaml#/definitions/string-array
> +    enum:
> +      - smc
> +      - hvc
> +
> +patternProperties:
> +  "fpga":

So 'foofpgabar' is valid?

> +    description: Compatible of the FPGA device.
> +    type: object
> +
> +    required:
> +      - compatible

This belongs in the fpga schema which should have a $ref here. (Which 
means this patch needs to come 2nd.)

> +
> +required:
> +  - compatible
> +
> +examples:
> +  - |
> +    versal-firmware {
> +      compatible = "xlnx,versal-firmware";
> +      method = "smc";
> +      fpga {
> +        compatible = "xlnx,versal-fpga";
> +      };
> +    };
> +
> +additionalProperties: false
> -- 
> 2.17.1
> 


From robh at kernel.org  Fri Apr 30 20:44:37 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 14:44:37 -0500
Subject: [PATCH v2 1/2] dt-bindings: usb: Document the Allwinner H6 DWC3
 glue
In-Reply-To: <20210430031912.42252-2-samuel@sholland.org>
References: <20210430031912.42252-1-samuel@sholland.org>
 <20210430031912.42252-2-samuel@sholland.org>
Message-ID: <20210430194437.GA3755541@robh.at.kernel.org>

On Thu, Apr 29, 2021 at 10:19:11PM -0500, Samuel Holland wrote:
> The RST_BUS_XHCI reset line in the H6 affects both the DWC3 core and the
> USB3 PHY. This suggests the reset line controls the USB3 IP as a whole.
> Represent this by attaching the reset line to a glue layer device.

Does that really mean anything more than a shared reset? Doesn't the 
reset code support shared resets?

> 
> Signed-off-by: Samuel Holland <samuel at sholland.org>
> ---
>  .../usb/allwinner,sun50i-h6-dwc3.yaml         | 75 +++++++++++++++++++
>  1 file changed, 75 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
> 
> diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
> new file mode 100644
> index 000000000000..936b5c74043f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/allwinner,sun50i-h6-dwc3.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/allwinner,sun50i-h6-dwc3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner H6 DWC3 USB controller
> +
> +maintainers:
> +  - Chen-Yu Tsai <wens at csie.org>
> +  - Maxime Ripard <mripard at kernel.org>
> +
> +properties:
> +  compatible:
> +    const: allwinner,sun50i-h6-dwc3
> +
> +  "#address-cells": true
> +
> +  "#size-cells": true
> +
> +  ranges: true
> +
> +  resets:
> +    maxItems: 1
> +
> +# Required child node:
> +
> +patternProperties:
> +  "^phy@[0-9a-f]+$":
> +    $ref: ../phy/allwinner,sun50i-h6-usb3-phy.yaml#
> +
> +  "^usb@[0-9a-f]+$":
> +    $ref: snps,dwc3.yaml#
> +
> +required:
> +  - compatible
> +  - ranges
> +  - resets
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/clock/sun50i-h6-ccu.h>
> +    #include <dt-bindings/reset/sun50i-h6-ccu.h>
> +
> +    usb3: usb at 5200000 {
> +        compatible = "allwinner,sun50i-h6-dwc3";
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        ranges;
> +        resets = <&ccu RST_BUS_XHCI>;
> +
> +        dwc3: usb at 5200000 {
> +            compatible = "snps,dwc3";
> +            reg = <0x05200000 0x10000>;
> +            interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
> +            clocks = <&ccu CLK_BUS_XHCI>,
> +                     <&ccu CLK_BUS_XHCI>,
> +                     <&rtc 0>;
> +            clock-names = "ref", "bus_early", "suspend";
> +            dr_mode = "host";
> +            phys = <&usb3phy>;
> +            phy-names = "usb3-phy";
> +        };
> +
> +        usb3phy: phy at 5210000 {
> +            compatible = "allwinner,sun50i-h6-usb3-phy";
> +            reg = <0x5210000 0x10000>;
> +            clocks = <&ccu CLK_USB_PHY1>;
> +            resets = <&ccu RST_USB_PHY1>;
> +            #phy-cells = <0>;
> +        };
> +    };
> -- 
> 2.26.3
> 


From ebiederm at xmission.com  Fri Apr 30 20:57:43 2021
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 30 Apr 2021 14:57:43 -0500
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <20210430184757.mez7ujmyzm43g6z2@revolver> (Liam Howlett's
 message of "Fri, 30 Apr 2021 18:48:08 +0000")
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck>
 <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver>
 <m1y2d8dfx8.fsf@fess.ebiederm.org>
 <20210423200126.otleormmjh22joj3@revolver>
 <m1czud6krk.fsf@fess.ebiederm.org>
 <20210430184757.mez7ujmyzm43g6z2@revolver>
Message-ID: <m1y2cztuiw.fsf@fess.ebiederm.org>

Liam Howlett <liam.howlett at oracle.com> writes:

> This is way out of scope for what I'm doing.  I'm trying to fix a call
> to the wrong mm API.  I was trying to clean up any obvious errors in
> calling functions which were exposed by fixing that error.  If you want
> this fixed differently, then please go ahead and tackle the problems you
> see.

I was asked by the arm maintainers to describe what the code should be
doing here.  I hope I have done that.

What is very interesting is that the code in __do_page_fault does not
use find_vma_intersection it uses find_vma.  Which suggests that
find_vma_intersection may not be the proper mm api.

The logic is:

>From __do_page_fault:
	struct vm_area_struct *vma = find_vma(mm, addr);

	if (unlikely(!vma))
		return VM_FAULT_BADMAP;

	/*
	 * Ok, we have a good vm_area for this memory access, so we can handle
	 * it.
	 */
	if (unlikely(vma->vm_start > addr)) {
		if (!(vma->vm_flags & VM_GROWSDOWN))
			return VM_FAULT_BADMAP;
		if (expand_stack(vma, addr))
			return VM_FAULT_BADMAP;
	}

	/*
	 * Check that the permissions on the VMA allow for the fault which
	 * occurred.
	 */
	if (!(vma->vm_flags & vm_flags))
		return VM_FAULT_BADACCESS;

>From do_page_fault:

	arm64_force_sig_fault(SIGSEGV,
			      fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
			      far, inf->name);


Hmm.  If the expand_stack step is skipped. Does is the logic equivalent
to find_vma_intersection?

	static inline struct vm_area_struct *find_vma_intersection(
        	struct mm_struct * mm,
                unsigned long start_addr,
                unsigned long end_addr)
	{
		struct vm_area_struct * vma = find_vma(mm,start_addr);
	
		if (vma && end_addr <= vma->vm_start)
			vma = NULL;
		return vma;
	}

Yes. It does look that way.  VM_FAULT_BADMAP is returned when a vma
covering the specified address is not found.  And VM_FAULT_BADACCESS is
returned when there is a vma and there is a permission problem.

There are also two SIGBUS cases that arm64_notify_segfault does not
handle.

So it appears changing arm64_notify_segfault to use
find_vma_intersection instead of find_vma would be a correct but
incomplete fix.

I don't see a point in changing sigerturn or rt_sigreturn.

Eric


From msys.mizuma at gmail.com  Fri Apr 30 21:16:25 2021
From: msys.mizuma at gmail.com (Masayoshi Mizuma)
Date: Fri, 30 Apr 2021 16:16:25 -0400
Subject: [PATCH v7 7/9] perf: arm64: Add test for userspace counter
 access on heterogeneous systems
In-Reply-To: <CAL_JsqLvHh5Ekpmb_au8Y9a7zF4w_izgaVnhzi9255XuqQUjrQ@mail.gmail.com>
References: <20210420031511.2348977-1-robh@kernel.org>
 <20210420031511.2348977-8-robh@kernel.org>
 <20210430164616.pzb7yxrsugexso25@gabell>
 <CAL_JsqLtkik656hjHMqvPc3Ta6qR+nWx1BxPcj8GvzYypTUVWQ@mail.gmail.com>
 <CAL_JsqLvHh5Ekpmb_au8Y9a7zF4w_izgaVnhzi9255XuqQUjrQ@mail.gmail.com>
Message-ID: <20210430201625.mpxeop6niyxnnvbk@gabell>

On Fri, Apr 30, 2021 at 01:20:58PM -0500, Rob Herring wrote:
> On Fri, Apr 30, 2021 at 1:17 PM Rob Herring <robh at kernel.org> wrote:
> >
> > On Fri, Apr 30, 2021 at 11:46 AM Masayoshi Mizuma <msys.mizuma at gmail.com> wrote:
> > >
> > > On Mon, Apr 19, 2021 at 10:15:09PM -0500, Rob Herring wrote:
> > > > Userspace counter access only works on heterogeneous systems with some
> > > > restrictions. The userspace process must be pinned to a homogeneous
> > > > subset of CPUs and must open the corresponding PMU for those CPUs. This
> > > > commit adds a test implementing these requirements.
> > > >
> > > > Signed-off-by: Rob Herring <robh at kernel.org>
> > > > ---
> > > > v6:
> > > >  - Add a check on cap_user_rdpmc
> > > > v5:
> > > >  - Adapt to libperf mmap API changes
> > > > v4:
> > > >  - Update perf_evsel__mmap params
> > > > v2:
> > > >  - Drop all but heterogeneous test as others covered by libperf tests
> > > >  - Rework to use libperf
> > > > ---
> > > >  tools/perf/arch/arm64/include/arch-tests.h |   7 +
> > > >  tools/perf/arch/arm64/tests/Build          |   1 +
> > > >  tools/perf/arch/arm64/tests/arch-tests.c   |   4 +
> > > >  tools/perf/arch/arm64/tests/user-events.c  | 177 +++++++++++++++++++++
> > > >  4 files changed, 189 insertions(+)
> > > >  create mode 100644 tools/perf/arch/arm64/tests/user-events.c
> > > >
> > > > diff --git a/tools/perf/arch/arm64/include/arch-tests.h b/tools/perf/arch/arm64/include/arch-tests.h
> > > > index 90ec4c8cb880..380ad34a3f09 100644
> > > > --- a/tools/perf/arch/arm64/include/arch-tests.h
> > > > +++ b/tools/perf/arch/arm64/include/arch-tests.h
> > > > @@ -2,11 +2,18 @@
> > > >  #ifndef ARCH_TESTS_H
> > > >  #define ARCH_TESTS_H
> > > >
> > > > +#include <linux/compiler.h>
> > > > +
> > > >  #ifdef HAVE_DWARF_UNWIND_SUPPORT
> > > >  struct thread;
> > > >  struct perf_sample;
> > > > +int test__arch_unwind_sample(struct perf_sample *sample,
> > > > +                          struct thread *thread);
> > > >  #endif
> > >
> > > Hello,
> > >
> > > I got the following compile error with aarch64 on Fedora33.
> > >
> > >     # make tools/perf
> > >     ...
> > >     In file included from arch/arm64/tests/arch-tests.c:4:
> > >     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
> > >        10 | int test__arch_unwind_sample(struct perf_sample *sample,
> > >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> > >     In file included from arch/arm64/tests/arch-tests.c:3:
> > >     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
> > >       140 | int test__arch_unwind_sample(struct perf_sample *sample,
> > >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> > >     cc1: all warnings being treated as errors
> > >     make[8]: *** [/root//libperf_v7/tools/build/Makefile.build:97: /root/libperf_v7/tools/perf/arch/arm64/tests/arch-tests.o] Error 1
> > >     make[8]: *** Waiting for unfinished jobs....
> > >     In file included from arch/arm64/tests/user-events.c:13:
> > >     /root//libperf_v7/tools/perf/arch/arm64/include/arch-tests.h:10:5: error: redundant redeclaration of ?test__arch_unwind_sample? [-Werror=redundant-decls]
> > >        10 | int test__arch_unwind_sample(struct perf_sample *sample,
> > >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> > >     In file included from arch/arm64/tests/user-events.c:12:
> > >     /root//libperf_v7/tools/perf/tests/tests.h:140:5: note: previous declaration of ?test__arch_unwind_sample? was here
> > >       140 | int test__arch_unwind_sample(struct perf_sample *sample,
> > >           |     ^~~~~~~~~~~~~~~~~~~~~~~~
> > >     cc1: all warnings being treated as errors
> > >     ...
> > >
> > > The error is gone after the following patch is applied.
> >
> > Thanks. Honestly, I'm not sure why it was there in the first place.
> > Looking at the git history and this series history doesn't give any
> > clues.
> 
> Well, except that both x86 and powerpc have the same hunk in their
> arch-tests.h. Do you see errors on those arches?

I didn't see the errors on x86_64.
It seems that the errors happen on aarch64 because 
test__arch_unwind_sample() is defined only if the arch
is arm or arm64 in tools/perf/tests/tests.h:

    #if defined(__arm__) || defined(__aarch64__)
    #ifdef HAVE_DWARF_UNWIND_SUPPORT
    struct thread;
    struct perf_sample;
    int test__arch_unwind_sample(struct perf_sample *sample,
                                 struct thread *thread);
    #endif
    #endif

The following patch may be another solution which is same way as
commit d8b167f9d8af ("perf tests: Move x86 tests into arch directory").

---
 tools/perf/arch/arm64/tests/dwarf-unwind.c | 1 +
 tools/perf/tests/dwarf-unwind.c            | 2 +-
 tools/perf/tests/tests.h                   | 2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/arm64/tests/dwarf-unwind.c b/tools/perf/arch/arm64/tests/dwarf-unwind.c
index 46147a483..02ba87f2b 100644
--- a/tools/perf/arch/arm64/tests/dwarf-unwind.c
+++ b/tools/perf/arch/arm64/tests/dwarf-unwind.c
@@ -7,6 +7,7 @@
 #include "event.h"
 #include "debug.h"
 #include "tests/tests.h"
+#include "arch-tests.h"
 
 #define STACK_SIZE 8192
 
diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 83638097c..daffe2d66 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -17,7 +17,7 @@
 #include "callchain.h"
 #include "util/synthetic-events.h"
 
-#if defined (__x86_64__) || defined (__i386__) || defined (__powerpc__)
+#if defined (__x86_64__) || defined (__i386__) || defined (__powerpc__) || defined(__aarch64__)
 #include "arch-tests.h"
 #endif
 
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index b85f00530..40cbdfa46 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -133,7 +133,7 @@ bool test__bp_account_is_supported(void);
 bool test__wp_is_supported(void);
 bool test__tsc_is_supported(void);
 
-#if defined(__arm__) || defined(__aarch64__)
+#if defined(__arm__)
 #ifdef HAVE_DWARF_UNWIND_SUPPORT
 struct thread;
 struct perf_sample;
-- 

Thanks,
Masa


From rdunlap at infradead.org  Fri Apr 30 21:19:55 2021
From: rdunlap at infradead.org (Randy Dunlap)
Date: Fri, 30 Apr 2021 13:19:55 -0700
Subject: [PATCH] media: I2C: change 'RST' to "RSET" to fix multiple build
 errors
Message-ID: <20210430201955.21309-1-rdunlap@infradead.org>

The use of an enum named 'RST' conflicts with a #define macro
named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h.

The MIPS use of RST was there first (AFAICT), so change the
media/i2c/ uses of RST to be named 'RSET'.
'git grep -w RSET' does not report any naming conflicts with the
new name.

This fixes multiple build errors:

arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 << 15)
      |              ^
drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST'
  356 |  RST,
      |  ^~~

../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 << 15)
      |              ^
../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST'
  180 |  RST,
      |  ^~~

../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
   15 | #define RST  (1 << 15)
      |              ^
../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST'
  238 |  RST,
      |  ^~~

and some others that I have trimmed.

Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver")
Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor")
Signed-off-by: Randy Dunlap <rdunlap at infradead.org>
Reported-by: kernel test robot <lkp at intel.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
Cc: Pengutronix Kernel Team <kernel at pengutronix.de>
Cc: Fabio Estevam <festevam at gmail.com>
Cc: NXP Linux Team <linux-imx at nxp.com>
Cc: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
Cc: Andrzej Hajda <a.hajda at samsung.com>
Cc: linux-media at vger.kernel.org
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Cc: Sangwook Lee <sangwook.lee at linaro.org>
---
 drivers/media/i2c/s5c73m3/s5c73m3-core.c |    6 +++---
 drivers/media/i2c/s5c73m3/s5c73m3.h      |    2 +-
 drivers/media/i2c/s5k4ecgx.c             |   10 +++++-----
 drivers/media/i2c/s5k5baf.c              |    6 +++---
 drivers/media/i2c/s5k6aa.c               |   10 +++++-----
 5 files changed, 17 insertions(+), 17 deletions(-)

--- linux-next-20210430.orig/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ linux-next-20210430/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -1386,7 +1386,7 @@ static int __s5c73m3_power_on(struct s5c
 	s5c73m3_gpio_deassert(state, STBY);
 	usleep_range(100, 200);
 
-	s5c73m3_gpio_deassert(state, RST);
+	s5c73m3_gpio_deassert(state, RSET);
 	usleep_range(50, 100);
 
 	return 0;
@@ -1401,7 +1401,7 @@ static int __s5c73m3_power_off(struct s5
 {
 	int i, ret;
 
-	if (s5c73m3_gpio_assert(state, RST))
+	if (s5c73m3_gpio_assert(state, RSET))
 		usleep_range(10, 50);
 
 	if (s5c73m3_gpio_assert(state, STBY))
@@ -1606,7 +1606,7 @@ static int s5c73m3_get_platform_data(str
 
 		state->mclk_frequency = pdata->mclk_frequency;
 		state->gpio[STBY] = pdata->gpio_stby;
-		state->gpio[RST] = pdata->gpio_reset;
+		state->gpio[RSET] = pdata->gpio_reset;
 		return 0;
 	}
 
--- linux-next-20210430.orig/drivers/media/i2c/s5c73m3/s5c73m3.h
+++ linux-next-20210430/drivers/media/i2c/s5c73m3/s5c73m3.h
@@ -353,7 +353,7 @@ struct s5c73m3_ctrls {
 
 enum s5c73m3_gpio_id {
 	STBY,
-	RST,
+	RSET,
 	GPIO_NUM,
 };
 
--- linux-next-20210430.orig/drivers/media/i2c/s5k4ecgx.c
+++ linux-next-20210430/drivers/media/i2c/s5k4ecgx.c
@@ -173,7 +173,7 @@ static const char * const s5k4ecgx_suppl
 
 enum s5k4ecgx_gpio_id {
 	STBY,
-	RST,
+	RSET,
 	GPIO_NUM,
 };
 
@@ -476,7 +476,7 @@ static int __s5k4ecgx_power_on(struct s5
 	if (s5k4ecgx_gpio_set_value(priv, STBY, priv->gpio[STBY].level))
 		usleep_range(30, 50);
 
-	if (s5k4ecgx_gpio_set_value(priv, RST, priv->gpio[RST].level))
+	if (s5k4ecgx_gpio_set_value(priv, RSET, priv->gpio[RSET].level))
 		usleep_range(30, 50);
 
 	return 0;
@@ -484,7 +484,7 @@ static int __s5k4ecgx_power_on(struct s5
 
 static int __s5k4ecgx_power_off(struct s5k4ecgx *priv)
 {
-	if (s5k4ecgx_gpio_set_value(priv, RST, !priv->gpio[RST].level))
+	if (s5k4ecgx_gpio_set_value(priv, RSET, !priv->gpio[RSET].level))
 		usleep_range(30, 50);
 
 	if (s5k4ecgx_gpio_set_value(priv, STBY, !priv->gpio[STBY].level))
@@ -872,7 +872,7 @@ static int s5k4ecgx_config_gpios(struct
 	int ret;
 
 	priv->gpio[STBY].gpio = -EINVAL;
-	priv->gpio[RST].gpio  = -EINVAL;
+	priv->gpio[RSET].gpio  = -EINVAL;
 
 	ret = s5k4ecgx_config_gpio(gpio->gpio, gpio->level, "S5K4ECGX_STBY");
 
@@ -891,7 +891,7 @@ static int s5k4ecgx_config_gpios(struct
 		s5k4ecgx_free_gpios(priv);
 		return ret;
 	}
-	priv->gpio[RST] = *gpio;
+	priv->gpio[RSET] = *gpio;
 	if (gpio_is_valid(gpio->gpio))
 		gpio_set_value(gpio->gpio, 0);
 
--- linux-next-20210430.orig/drivers/media/i2c/s5k5baf.c
+++ linux-next-20210430/drivers/media/i2c/s5k5baf.c
@@ -235,7 +235,7 @@ struct s5k5baf_gpio {
 
 enum s5k5baf_gpio_id {
 	STBY,
-	RST,
+	RSET,
 	NUM_GPIOS,
 };
 
@@ -969,7 +969,7 @@ static int s5k5baf_power_on(struct s5k5b
 
 	s5k5baf_gpio_deassert(state, STBY);
 	usleep_range(50, 100);
-	s5k5baf_gpio_deassert(state, RST);
+	s5k5baf_gpio_deassert(state, RSET);
 	return 0;
 
 err_reg_dis:
@@ -987,7 +987,7 @@ static int s5k5baf_power_off(struct s5k5
 	state->apply_cfg = 0;
 	state->apply_crop = 0;
 
-	s5k5baf_gpio_assert(state, RST);
+	s5k5baf_gpio_assert(state, RSET);
 	s5k5baf_gpio_assert(state, STBY);
 
 	if (!IS_ERR(state->clock))
--- linux-next-20210430.orig/drivers/media/i2c/s5k6aa.c
+++ linux-next-20210430/drivers/media/i2c/s5k6aa.c
@@ -177,7 +177,7 @@ static const char * const s5k6aa_supply_
 
 enum s5k6aa_gpio_id {
 	STBY,
-	RST,
+	RSET,
 	GPIO_NUM,
 };
 
@@ -841,7 +841,7 @@ static int __s5k6aa_power_on(struct s5k6
 		ret = s5k6aa->s_power(1);
 	usleep_range(4000, 5000);
 
-	if (s5k6aa_gpio_deassert(s5k6aa, RST))
+	if (s5k6aa_gpio_deassert(s5k6aa, RSET))
 		msleep(20);
 
 	return ret;
@@ -851,7 +851,7 @@ static int __s5k6aa_power_off(struct s5k
 {
 	int ret;
 
-	if (s5k6aa_gpio_assert(s5k6aa, RST))
+	if (s5k6aa_gpio_assert(s5k6aa, RSET))
 		usleep_range(100, 150);
 
 	if (s5k6aa->s_power) {
@@ -1510,7 +1510,7 @@ static int s5k6aa_configure_gpios(struct
 	int ret;
 
 	s5k6aa->gpio[STBY].gpio = -EINVAL;
-	s5k6aa->gpio[RST].gpio  = -EINVAL;
+	s5k6aa->gpio[RSET].gpio  = -EINVAL;
 
 	gpio = &pdata->gpio_stby;
 	if (gpio_is_valid(gpio->gpio)) {
@@ -1533,7 +1533,7 @@ static int s5k6aa_configure_gpios(struct
 		if (ret < 0)
 			return ret;
 
-		s5k6aa->gpio[RST] = *gpio;
+		s5k6aa->gpio[RSET] = *gpio;
 	}
 
 	return 0;


From amanieu at gmail.com  Fri Apr 30 21:28:02 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:28:02 +0100
Subject: [PATCH v4 0/8] arm64: Allow 64-bit tasks to invoke compat syscalls
Message-ID: <20210430202810.44092-1-amanieu@gmail.com>

This series allows AArch64 tasks to perform 32-bit syscalls by setting
the top bit of x8 and using AArch32 compat syscall numbers:

    syscall(0x80000000 | __ARM_NR_write, 1, "foo\n", 4);

Internally, setting this bit does the following:
- The remainder of x8 is treated as a compat syscall number and is used
  to index the compat syscall table.
- in_compat_syscall will return true for the duration of the syscall.
- VM allocations performed by the syscall will be located in the lower
  4G of the address space. A separate compat_mmap_base is used so that
  these allocations are still properly randomized.
- Interrupted compat syscalls are properly restarted as compat syscalls.
- Seccomp will treats the syscall as having AUDIT_ARCH_ARM instead of
  AUDIT_ARCH_AARCH64. This affects the arch value seen by seccomp
  filters and reported by SIGSYS.
- PTRACE_GET_SYSCALL_INFO also treats the syscall as having
  AUDIT_ARCH_ARM. Recent versions of strace will correctly report the
  syscall name and parameters when an AArch64 task mixes 32-bit and
  64-bit syscalls.

This feature is intended for use in software compatibility layers which
emulate a 32-bit program on AArch64. This patch has been tested on two
such emulators:
- Tango [1], which enables AArch32 binaries to run on AArch64 CPUs which
  do not have hardware support for AArch32. Tango is used to run virtual
  Android devices on AArch64 servers.
- FEX [2], an emulator for running x86 and x86_64 binaries on AArch64.
  FEX can already run many x86_64 programs including 3D games, but
  requires kernel support for running 32-bit x86 binaries.

Both FEX and Tango have previously attempted to translate 32-bit
syscalls purely in user mode like QEMU does for its user mode
emulation. While this works for simple programs, there are many
limitations which cannot be solved without kernel support, for example:
- There are a huge number of ioctls which behave differently in 32-bit
  mode. It is impractical and error prone to manually emulate them all
  in user mode. Specifically, the kernel already has a well-tested and
  reliable compatibility layer and it makes sense to reuse this. QEMU
  supports emulating some ioctls in userspace but this still does not
  cover devices like GPUs which are needed for accelerated rendering.
- The 64-bit set_robust_list is not compatible with the 32-bit ABI. The
  compat version of set_robust_list must be used. Emulating this in user
  mode is not reliable since SIGKILL cannot be caught.
- io_uring uses iovec structures as part of its API, which have
  different sizes on 32-bit and 64-bit.
- ext4 represents positions in directories as 64-bit hashes, which break
  if they are truncated to 32 bits. There is special support for 32-bit
  off_t in the ext4 driver but this is only used when in_compat_syscall
  is true: https://bugzilla.kernel.org/show_bug.cgi?id=205957
- The io_setup syscall allocates a VM area for the AIO context and
  returns it. But there is no way to control where this context is
  allocated so it will almost always end up above the 4GB limit.
- Some ioctls will also perform VM allocations, with the same issues as
  io_setup. Search for "vm_mmap" in drivers/.
- Some file descriptors have alignment requirements which are not known
  to userspace. For example, a hugetlbfs file can only be mmaped at a
  huge page alignment but there is no way for userspace to know this
  when it needs to manually select an address below 4GB for the mapping.

All of these issues are solved in FEX and Tango by invoking compat
syscalls directly. In the case of FEX, there remain some differences
between the arm and x86 ABIs due to alignment issues, but these are few
enough to be individually handled in userspace.

There is a precedent for exposing this functionality to userspace:
x86_64 has 2 ways to invoke 32-bit syscalls. The first is to use int
0x80 with a 32-bit syscall number and the second is to use
__X32_SYSCALL_BIT with a 64-bit syscall number. As such, the generic
kernel code is already able to properly handle tasks that invoke both
32-bit and 64-bit syscalls.

[1] https://www.amanieusystems.com/
[2] https://github.com/FEX-Emu/FEX

Changelog since v3:
- Renamed aarch64_compat_syscall to use_compat_syscall and enable it
  permanently for AArch32 tasks.

Changelog since v2:
- Complete rewrite, based on the patch that was previously posted as:
  [PATCH v2] [RFC] arm64: Exposes support for 32-bit syscalls

Amanieu d'Antras (8):
  mm: Add arch_get_mmap_base_topdown macro
  hugetlbfs: Use arch_get_mmap_* macros
  mm: Support mmap_compat_base with the generic layout
  arm64: Separate in_compat_syscall from is_compat_task
  arm64: mm: Use HAVE_ARCH_COMPAT_MMAP_BASES
  arm64: Add a compat syscall flag to thread_info
  arm64: Forbid calling compat sigreturn from 64-bit tasks
  arm64: Allow 64-bit tasks to invoke compat syscalls

 arch/arm64/Kconfig                   |  1 +
 arch/arm64/include/asm/compat.h      | 24 ++++++++++++---
 arch/arm64/include/asm/elf.h         | 21 ++++++++++---
 arch/arm64/include/asm/ftrace.h      |  2 +-
 arch/arm64/include/asm/processor.h   | 32 +++++++++++--------
 arch/arm64/include/asm/syscall.h     |  6 ++--
 arch/arm64/include/asm/thread_info.h |  6 ++++
 arch/arm64/include/uapi/asm/unistd.h |  2 ++
 arch/arm64/kernel/ptrace.c           |  2 +-
 arch/arm64/kernel/signal.c           |  5 +++
 arch/arm64/kernel/signal32.c         |  8 +++++
 arch/arm64/kernel/syscall.c          | 23 ++++++++++++--
 arch/arm64/mm/mmap.c                 | 33 ++++++++++++++++++++
 fs/hugetlbfs/inode.c                 | 22 ++++++++++---
 mm/mmap.c                            | 14 ++++++---
 mm/util.c                            | 46 +++++++++++++++++++++++-----
 16 files changed, 202 insertions(+), 45 deletions(-)

-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:28:03 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:28:03 +0100
Subject: [PATCH v4 1/8] mm: Add arch_get_mmap_base_topdown macro
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430202810.44092-2-amanieu@gmail.com>

This allows architectures to customize the mmap base to use depending on
the direction of allocation.

The base argument is also removed from arch_get_mmap_base[_topdown] in
prepartion for future changes.

arm64 is currently the only user of the arch_get_mmap_* macros and is
adjusted accordingly. Specifically it only needs to limit the upper
bound of VM allocations and therefore only needs to customize
arch_get_mmap_base_topdown but not arch_get_mmap_base.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/processor.h |  7 ++++---
 mm/mmap.c                          | 14 +++++++++-----
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index efc10e9041a0..f47528aae321 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -88,9 +88,10 @@
 #define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
 				DEFAULT_MAP_WINDOW)
 
-#define arch_get_mmap_base(addr, base) ((addr > DEFAULT_MAP_WINDOW) ? \
-					base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
-					base)
+#define arch_get_mmap_base_topdown(addr) \
+	((addr > DEFAULT_MAP_WINDOW) ? \
+	current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
+	current->mm->mmap_base)
 #endif /* CONFIG_ARM64_FORCE_52BIT */
 
 extern phys_addr_t arm64_dma_phys_limit;
diff --git a/mm/mmap.c b/mm/mmap.c
index 3f287599a7a3..4937b34085cb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2139,11 +2139,15 @@ unsigned long vm_unmapped_area(struct vm_unmapped_area_info *info)
 }
 
 #ifndef arch_get_mmap_end
-#define arch_get_mmap_end(addr)	(TASK_SIZE)
+#define arch_get_mmap_end(addr)			(TASK_SIZE)
 #endif
 
 #ifndef arch_get_mmap_base
-#define arch_get_mmap_base(addr, base) (base)
+#define arch_get_mmap_base(addr)		(current->mm->mmap_base)
+#endif
+
+#ifndef arch_get_mmap_base_topdown
+#define arch_get_mmap_base_topdown(addr)	(current->mm->mmap_base)
 #endif
 
 /* Get an address range which is currently unmapped.
@@ -2184,7 +2188,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
 	info.flags = 0;
 	info.length = len;
-	info.low_limit = mm->mmap_base;
+	info.low_limit = arch_get_mmap_base(addr);
 	info.high_limit = mmap_end;
 	info.align_mask = 0;
 	info.align_offset = 0;
@@ -2227,7 +2231,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
 	info.low_limit = max(PAGE_SIZE, mmap_min_addr);
-	info.high_limit = arch_get_mmap_base(addr, mm->mmap_base);
+	info.high_limit = arch_get_mmap_base_topdown(addr);
 	info.align_mask = 0;
 	info.align_offset = 0;
 	addr = vm_unmapped_area(&info);
@@ -2241,7 +2245,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
 	if (offset_in_page(addr)) {
 		VM_BUG_ON(addr != -ENOMEM);
 		info.flags = 0;
-		info.low_limit = TASK_UNMAPPED_BASE;
+		info.low_limit = arch_get_mmap_base(addr);
 		info.high_limit = mmap_end;
 		addr = vm_unmapped_area(&info);
 	}
-- 
2.31.1



From jbx6244 at gmail.com  Fri Apr 30 21:29:05 2021
From: jbx6244 at gmail.com (Johan Jonker)
Date: Fri, 30 Apr 2021 22:29:05 +0200
Subject: [PATCH v4 07/10] dt-bindings: soc: rockchip: Convert grf.txt to
 YAML
In-Reply-To: <20210429212413.GA1794356@robh.at.kernel.org>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081321.17855-1-cl@rock-chips.com>
 <20210429212413.GA1794356@robh.at.kernel.org>
Message-ID: <c4130ba7-5f28-57e9-f391-89b6539fb29c@gmail.com>

On 4/29/21 11:24 PM, Rob Herring wrote:
> On Thu, Apr 29, 2021 at 04:13:21PM +0800, cl at rock-chips.com wrote:
>> From: Liang Chen <cl at rock-chips.com>
>>
>> Current dts files with 'grf' nodes are manually verified. In order to
>> automate this process grf.txt has to be converted to YAML.
>>
>> Add new descriptions for:
>> "rockchip,rk3568-grf", "syscon", "simple-mfd"
>> "rockchip,rk3568-pmugrf", "syscon", "simple-mfd"
>>
>> Signed-off-by: Liang Chen <cl at rock-chips.com>
>> ---

[..]

>> +properties:
>> +  compatible:
>> +    - items:
> 
> The '-' is the source of your error.
> 
>> +        - enum:
>> +            - rockchip,px30-grf
>> +            - rockchip,px30-pmugrf
>> +            - rockchip,px30-usb2phy-grf
>> +            - rockchip,rk3036-grf
>> +            - rockchip,rk3066-grf
>> +            - rockchip,rk3188-grf
>> +            - rockchip,rk3228-grf
>> +            - rockchip,rk3288-grf
>> +            - rockchip,rk3288-sgrf
>> +            - rockchip,rk3308-core-grf
>> +            - rockchip,rk3308-detect-grf
>> +            - rockchip,rk3308-grf
>> +            - rockchip,rk3328-grf
>> +            - rockchip,rk3328-usb2phy-grf
>> +            - rockchip,rk3368-grf
>> +            - rockchip,rk3368-pmugrf
>> +            - rockchip,rk3399-grf
>> +            - rockchip,rk3399-pmugrf
>> +            - rockchip,rk3568-grf
>> +            - rockchip,rk3568-pmugrf
>> +            - rockchip,rv1108-grf
>> +            - rockchip,rv1108-usbgrf
>> +        - const: syscon
>> +        - const: simple-mfd
> 

> 'simple-mfd' was not in the old binding. That implies you have child 
> nodes, and if so, they need to be documented. I imagine that will mean 
> splitting this into multiple schemas if that's the case.
> 

Hi,

Question for rob+dt:

Given that a number of txt documents still are in need for YAML
conversion. Which is a bit beyond the author of this serie.
The core rk3568.dtsi is needed for other series to base on.

To speed things up a bit and reduce the work load:
Is it possible to add the grf compatibles in use first and do the rest
of the subnodes for various SoCs later?

Is it possible to add for now to reduce notification output:

additionalProperties: true

and then later:

additionalProperties: false


===

>From build log:

#address-cells
#size-cells
reboot-mode
io-domains
usb2-phy at 100
mipi-dphy-rx0
pcie-phy
phy at f780
edp-phy
usbphy
lvds
power-controller
grf-gpio

===

Example for rk3399:

	grf: syscon at ff770000 {
		compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";

		io_domains: io-domains {
			compatible = "rockchip,rk3399-io-voltage-domain"; //
rockchip-io-domain.txt
		};

		mipi_dphy_rx0: mipi-dphy-rx0 {
			compatible = "rockchip,rk3399-mipi-dphy-rx0"; //
rockchip-mipi-dphy-rx0.yaml
		};

		u2phy0: usb2-phy at e450 {
			compatible = "rockchip,rk3399-usb2phy"; // phy-rockchip-inno-usb2.yaml
		};

		u2phy1: usb2-phy at e460 {
			compatible = "rockchip,rk3399-usb2phy"; // phy-rockchip-inno-usb2.yaml
		};

		emmc_phy: phy at f780 {
			compatible = "rockchip,rk3399-emmc-phy"; // rockchip-emmc-phy.txt
		};

		pcie_phy: pcie-phy {
			compatible = "rockchip,rk3399-pcie-phy"; // rockchip-pcie-phy.txt
		};
	};


From liam.howlett at oracle.com  Fri Apr 30 21:31:42 2021
From: liam.howlett at oracle.com (Liam Howlett)
Date: Fri, 30 Apr 2021 20:31:42 +0000
Subject: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
In-Reply-To: <m1y2cztuiw.fsf@fess.ebiederm.org>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck> <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver> <m1y2d8dfx8.fsf@fess.ebiederm.org>
 <20210423200126.otleormmjh22joj3@revolver> <m1czud6krk.fsf@fess.ebiederm.org>
 <20210430184757.mez7ujmyzm43g6z2@revolver> <m1y2cztuiw.fsf@fess.ebiederm.org>
Message-ID: <20210430203136.lnzqt7vuninh5v4t@revolver>

* Eric W. Biederman <ebiederm at xmission.com> [210430 15:57]:
> Liam Howlett <liam.howlett at oracle.com> writes:
> 
> > This is way out of scope for what I'm doing.  I'm trying to fix a call
> > to the wrong mm API.  I was trying to clean up any obvious errors in
> > calling functions which were exposed by fixing that error.  If you want
> > this fixed differently, then please go ahead and tackle the problems you
> > see.
> 
> I was asked by the arm maintainers to describe what the code should be
> doing here.  I hope I have done that.
> 
> What is very interesting is that the code in __do_page_fault does not
> use find_vma_intersection it uses find_vma.  Which suggests that
> find_vma_intersection may not be the proper mm api.
> 
> The logic is:
> 
> From __do_page_fault:
> 	struct vm_area_struct *vma = find_vma(mm, addr);
> 
> 	if (unlikely(!vma))
> 		return VM_FAULT_BADMAP;
> 
> 	/*
> 	 * Ok, we have a good vm_area for this memory access, so we can handle
> 	 * it.
> 	 */
> 	if (unlikely(vma->vm_start > addr)) {
> 		if (!(vma->vm_flags & VM_GROWSDOWN))
> 			return VM_FAULT_BADMAP;
> 		if (expand_stack(vma, addr))
> 			return VM_FAULT_BADMAP;
> 	}
> 
> 	/*
> 	 * Check that the permissions on the VMA allow for the fault which
> 	 * occurred.
> 	 */
> 	if (!(vma->vm_flags & vm_flags))
> 		return VM_FAULT_BADACCESS;
> 
> From do_page_fault:
> 
> 	arm64_force_sig_fault(SIGSEGV,
> 			      fault == VM_FAULT_BADACCESS ? SEGV_ACCERR : SEGV_MAPERR,
> 			      far, inf->name);
> 
> 
> Hmm.  If the expand_stack step is skipped. Does is the logic equivalent
> to find_vma_intersection?
> 
> 	static inline struct vm_area_struct *find_vma_intersection(
>         	struct mm_struct * mm,
>                 unsigned long start_addr,
>                 unsigned long end_addr)
> 	{
> 		struct vm_area_struct * vma = find_vma(mm,start_addr);
> 	
> 		if (vma && end_addr <= vma->vm_start)
> 			vma = NULL;
> 		return vma;
> 	}
> 
> Yes. It does look that way.  VM_FAULT_BADMAP is returned when a vma
> covering the specified address is not found.  And VM_FAULT_BADACCESS is
> returned when there is a vma and there is a permission problem.
> 
> There are also two SIGBUS cases that arm64_notify_segfault does not
> handle.
> 
> So it appears changing arm64_notify_segfault to use
> find_vma_intersection instead of find_vma would be a correct but
> incomplete fix.

The reason VM_GROWSDOWN is checked here is to see if the stack should be
attempted to be expanded, which happens above.  If VM_GROWSDOWN is true,
then wouldn't the do_page_fault() and __do_page_fault() calls already be
done and be handling this case?

> 
> I don't see a point in changing sigerturn or rt_sigreturn.

Both functions call arm64_notify_segfault() on !access_ok() which I've
increased the potential for returning SEGV_MAPERR.  It is also not
necessary to walk the VMAs when !access_ok(), so it seemed a decent
thing to do.

Thanks,
Liam

From amanieu at gmail.com  Fri Apr 30 21:37:51 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:51 +0100
Subject: [PATCH v4 2/8] hugetlbfs: Use arch_get_mmap_* macros
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-1-amanieu@gmail.com>

hugetlb_get_unmapped_area should obey the same arch-specific constraints
as mmap when selecting an address.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 fs/hugetlbfs/inode.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 701c82c36138..526ccb524329 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -191,6 +191,18 @@ static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
  */
 
 #ifndef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
+#ifndef arch_get_mmap_end
+#define arch_get_mmap_end(addr)			(TASK_SIZE)
+#endif
+
+#ifndef arch_get_mmap_base
+#define arch_get_mmap_base(addr)		(current->mm->mmap_base)
+#endif
+
+#ifndef arch_get_mmap_base_topdown
+#define arch_get_mmap_base_topdown(addr)	(current->mm->mmap_base)
+#endif
+
 static unsigned long
 hugetlb_get_unmapped_area_bottomup(struct file *file, unsigned long addr,
 		unsigned long len, unsigned long pgoff, unsigned long flags)
@@ -200,8 +212,8 @@ hugetlb_get_unmapped_area_bottomup(struct file *file, unsigned long addr,
 
 	info.flags = 0;
 	info.length = len;
-	info.low_limit = current->mm->mmap_base;
-	info.high_limit = TASK_SIZE;
+	info.low_limit = arch_get_mmap_base(addr);
+	info.high_limit = arch_get_mmap_end(addr);
 	info.align_mask = PAGE_MASK & ~huge_page_mask(h);
 	info.align_offset = 0;
 	return vm_unmapped_area(&info);
@@ -217,7 +229,7 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr,
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
 	info.low_limit = max(PAGE_SIZE, mmap_min_addr);
-	info.high_limit = current->mm->mmap_base;
+	info.high_limit = arch_get_mmap_base_topdown(addr);
 	info.align_mask = PAGE_MASK & ~huge_page_mask(h);
 	info.align_offset = 0;
 	addr = vm_unmapped_area(&info);
@@ -231,8 +243,8 @@ hugetlb_get_unmapped_area_topdown(struct file *file, unsigned long addr,
 	if (unlikely(offset_in_page(addr))) {
 		VM_BUG_ON(addr != -ENOMEM);
 		info.flags = 0;
-		info.low_limit = current->mm->mmap_base;
-		info.high_limit = TASK_SIZE;
+		info.low_limit = arch_get_mmap_base(addr);
+		info.high_limit = arch_get_mmap_end(addr);
 		addr = vm_unmapped_area(&info);
 	}
 
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:52 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:52 +0100
Subject: [PATCH v4 3/8] mm: Support mmap_compat_base with the generic layout
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-2-amanieu@gmail.com>

This enables architectures using the generic mmap layout to support
32-bit mmap calls from 64-bit processes and vice-versa.

Architectures using this must define separate 32-bit and 64-bit versions
of STACK_TOP, TASK_UNMAPPED_BASE and STACK_RND_MASK.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 mm/util.c | 46 ++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/mm/util.c b/mm/util.c
index 54870226cea6..37bd764174b5 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -353,12 +353,12 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 	return randomize_page(mm->brk, SZ_1G);
 }
 
-unsigned long arch_mmap_rnd(void)
+static unsigned long mmap_rnd(bool compat)
 {
 	unsigned long rnd;
 
 #ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
-	if (is_compat_task())
+	if (compat)
 		rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
 	else
 #endif /* CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS */
@@ -367,6 +367,11 @@ unsigned long arch_mmap_rnd(void)
 	return rnd << PAGE_SHIFT;
 }
 
+unsigned long arch_mmap_rnd(void)
+{
+	return mmap_rnd(is_compat_task());
+}
+
 static int mmap_is_legacy(struct rlimit *rlim_stack)
 {
 	if (current->personality & ADDR_COMPAT_LAYOUT)
@@ -383,16 +388,17 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
  * the face of randomisation.
  */
 #define MIN_GAP		(SZ_128M)
-#define MAX_GAP		(STACK_TOP / 6 * 5)
+#define MAX_GAP		(stack_top / 6 * 5)
 
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
+static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack,
+	unsigned long stack_top, unsigned long stack_rnd_mask)
 {
 	unsigned long gap = rlim_stack->rlim_cur;
 	unsigned long pad = stack_guard_gap;
 
 	/* Account for stack randomization if necessary */
 	if (current->flags & PF_RANDOMIZE)
-		pad += (STACK_RND_MASK << PAGE_SHIFT);
+		pad += (stack_rnd_mask << PAGE_SHIFT);
 
 	/* Values close to RLIM_INFINITY can overflow. */
 	if (gap + pad > gap)
@@ -403,21 +409,45 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
 	else if (gap > MAX_GAP)
 		gap = MAX_GAP;
 
-	return PAGE_ALIGN(STACK_TOP - gap - rnd);
+	return PAGE_ALIGN(stack_top - gap - rnd);
 }
 
 void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
 {
 	unsigned long random_factor = 0UL;
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+	unsigned long compat_random_factor = 0UL;
+#endif
 
-	if (current->flags & PF_RANDOMIZE)
+	if (current->flags & PF_RANDOMIZE) {
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		random_factor = mmap_rnd(false);
+		compat_random_factor = mmap_rnd(true);
+#else
 		random_factor = arch_mmap_rnd();
+#endif
+	}
 
 	if (mmap_is_legacy(rlim_stack)) {
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		mm->mmap_base = TASK_UNMAPPED_BASE_64 + random_factor;
+		mm->mmap_compat_base =
+			TASK_UNMAPPED_BASE_32 + compat_random_factor;
+#else
 		mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
+#endif
 		mm->get_unmapped_area = arch_get_unmapped_area;
 	} else {
-		mm->mmap_base = mmap_base(random_factor, rlim_stack);
+#ifdef CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
+		mm->mmap_base = mmap_base(random_factor, rlim_stack,
+					  STACK_TOP_64, STACK_RND_MASK_64);
+		mm->mmap_compat_base = mmap_base(compat_random_factor,
+						 rlim_stack, STACK_TOP_32,
+						 STACK_RND_MASK_32);
+#else
+		mm->mmap_base = mmap_base(random_factor, rlim_stack, STACK_TOP,
+					  STACK_RND_MASK);
+#endif
 		mm->get_unmapped_area = arch_get_unmapped_area_topdown;
 	}
 }
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:53 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:53 +0100
Subject: [PATCH v4 4/8] arm64: Separate in_compat_syscall from is_compat_task
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-3-amanieu@gmail.com>

This is preliminary work for allowing 64-bit processes to invoke compat
syscalls.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/compat.h  | 24 ++++++++++++++++++++----
 arch/arm64/include/asm/ftrace.h  |  2 +-
 arch/arm64/include/asm/syscall.h |  6 +++---
 arch/arm64/kernel/ptrace.c       |  2 +-
 arch/arm64/kernel/syscall.c      |  2 +-
 5 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 23a9fb73c04f..a2f5001f7793 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -178,21 +178,37 @@ struct compat_shmid64_ds {
 	compat_ulong_t __unused5;
 };
 
-static inline int is_compat_task(void)
+static inline bool is_compat_task(void)
 {
 	return test_thread_flag(TIF_32BIT);
 }
 
-static inline int is_compat_thread(struct thread_info *thread)
+static inline bool is_compat_thread(struct thread_info *thread)
 {
 	return test_ti_thread_flag(thread, TIF_32BIT);
 }
 
+static inline bool in_compat_syscall(void)
+{
+	return is_compat_task();
+}
+#define in_compat_syscall in_compat_syscall	/* override the generic impl */
+
+static inline bool thread_in_compat_syscall(struct thread_info *thread)
+{
+	return is_compat_thread(thread);
+}
+
 #else /* !CONFIG_COMPAT */
 
-static inline int is_compat_thread(struct thread_info *thread)
+static inline bool is_compat_thread(struct thread_info *thread)
+{
+	return false;
+}
+
+static inline bool thread_in_compat_syscall(struct thread_info *thread)
 {
-	return 0;
+	return false;
 }
 
 #endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 91fa4baa1a93..f41aad92c67a 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -88,7 +88,7 @@ int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec);
 #define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
 static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
 {
-	return is_compat_task();
+	return in_compat_syscall();
 }
 
 #define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/asm/syscall.h
index cfc0672013f6..0dfc01ea386c 100644
--- a/arch/arm64/include/asm/syscall.h
+++ b/arch/arm64/include/asm/syscall.h
@@ -35,7 +35,7 @@ static inline long syscall_get_error(struct task_struct *task,
 {
 	unsigned long error = regs->regs[0];
 
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		error = sign_extend64(error, 31);
 
 	return IS_ERR_VALUE(error) ? error : 0;
@@ -54,7 +54,7 @@ static inline void syscall_set_return_value(struct task_struct *task,
 	if (error)
 		val = error;
 
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		val = lower_32_bits(val);
 
 	regs->regs[0] = val;
@@ -88,7 +88,7 @@ static inline void syscall_set_arguments(struct task_struct *task,
  */
 static inline int syscall_get_arch(struct task_struct *task)
 {
-	if (is_compat_thread(task_thread_info(task)))
+	if (thread_in_compat_syscall(task_thread_info(task)))
 		return AUDIT_ARCH_ARM;
 
 	return AUDIT_ARCH_AARCH64;
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 170f42fd6101..017a82b24f49 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1721,7 +1721,7 @@ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 	 * 32-bit children use an extended user_aarch32_ptrace_view to allow
 	 * access to the TLS register.
 	 */
-	if (is_compat_task())
+	if (in_compat_syscall())
 		return &user_aarch32_view;
 	else if (is_compat_thread(task_thread_info(task)))
 		return &user_aarch32_ptrace_view;
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index b9cf12b271d7..e0e9d54de0a2 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -51,7 +51,7 @@ static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
 		ret = do_ni_syscall(regs, scno);
 	}
 
-	if (is_compat_task())
+	if (in_compat_syscall())
 		ret = lower_32_bits(ret);
 
 	regs->regs[0] = ret;
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:54 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:54 +0100
Subject: [PATCH v4 5/8] arm64: mm: Use HAVE_ARCH_COMPAT_MMAP_BASES
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-4-amanieu@gmail.com>

This patch switches arm64 to use separate mmap_base for 32-bit and
64-bit mmaps. This is needed to ensure that compat syscalls
invoked by 64-bit tasks perform VM allocations in the low 4G of the
address space.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/Kconfig                 |  1 +
 arch/arm64/include/asm/elf.h       |  8 +++++---
 arch/arm64/include/asm/processor.h | 33 ++++++++++++++++++------------
 arch/arm64/mm/mmap.c               | 33 ++++++++++++++++++++++++++++++
 4 files changed, 59 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dfdc3e0af5e1..d57b7bcbd758 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -133,6 +133,7 @@ config ARM64
 	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
+	select HAVE_ARCH_COMPAT_MMAP_BASES if COMPAT
 	select HAVE_ARCH_COMPILER_H
 	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 8d1c8dcb87fd..e21964898d06 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -187,12 +187,14 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 				       int uses_interp);
 
 /* 1GB of VA */
+#define STACK_RND_MASK_64		(0x3ffff >> (PAGE_SHIFT - 12))
 #ifdef CONFIG_COMPAT
+#define STACK_RND_MASK_32		(0x7ff >> (PAGE_SHIFT - 12))
 #define STACK_RND_MASK			(test_thread_flag(TIF_32BIT) ? \
-						0x7ff >> (PAGE_SHIFT - 12) : \
-						0x3ffff >> (PAGE_SHIFT - 12))
+						STACK_RND_MASK_32 : \
+						STACK_RND_MASK_64)
 #else
-#define STACK_RND_MASK			(0x3ffff >> (PAGE_SHIFT - 12))
+#define STACK_RND_MASK			STACK_RND_MASK_64
 #endif
 
 #ifdef __AARCH64EB__
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index f47528aae321..f8309f8d0ece 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -70,29 +70,36 @@
 
 #ifdef CONFIG_ARM64_FORCE_52BIT
 #define STACK_TOP_MAX		TASK_SIZE_64
-#define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
+#define TASK_UNMAPPED_BASE_64	(PAGE_ALIGN(TASK_SIZE_64 / 4))
 #else
 #define STACK_TOP_MAX		DEFAULT_MAP_WINDOW_64
-#define TASK_UNMAPPED_BASE	(PAGE_ALIGN(DEFAULT_MAP_WINDOW / 4))
+#define TASK_UNMAPPED_BASE_64	(PAGE_ALIGN(DEFAULT_MAP_WINDOW_64 / 4))
 #endif /* CONFIG_ARM64_FORCE_52BIT */
 
+#ifdef CONFIG_COMPAT
+#define TASK_UNMAPPED_BASE_32	(PAGE_ALIGN(TASK_SIZE_32 / 4))
+#define TASK_UNMAPPED_BASE	(test_thread_flag(TIF_32BIT) ? \
+				TASK_UNMAPPED_BASE_32 : TASK_UNMAPPED_BASE_64)
+#else
+#define TASK_UNMAPPED_BASE	TASK_UNMAPPED_BASE_64
+#endif /* CONFIG_COMPAT */
+
+#define STACK_TOP_64		STACK_TOP_MAX
 #ifdef CONFIG_COMPAT
 #define AARCH32_VECTORS_BASE	0xffff0000
+#define STACK_TOP_32		AARCH32_VECTORS_BASE
 #define STACK_TOP		(test_thread_flag(TIF_32BIT) ? \
-				AARCH32_VECTORS_BASE : STACK_TOP_MAX)
+				STACK_TOP_32 : STACK_TOP_64)
 #else
-#define STACK_TOP		STACK_TOP_MAX
+#define STACK_TOP		STACK_TOP_64
 #endif /* CONFIG_COMPAT */
 
-#ifndef CONFIG_ARM64_FORCE_52BIT
-#define arch_get_mmap_end(addr) ((addr > DEFAULT_MAP_WINDOW) ? TASK_SIZE :\
-				DEFAULT_MAP_WINDOW)
-
-#define arch_get_mmap_base_topdown(addr) \
-	((addr > DEFAULT_MAP_WINDOW) ? \
-	current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW :\
-	current->mm->mmap_base)
-#endif /* CONFIG_ARM64_FORCE_52BIT */
+#define arch_get_mmap_end arch_get_mmap_end
+#define arch_get_mmap_base arch_get_mmap_base
+#define arch_get_mmap_base_topdown arch_get_mmap_base_topdown
+unsigned long arch_get_mmap_end(unsigned long addr);
+unsigned long arch_get_mmap_base(unsigned long addr);
+unsigned long arch_get_mmap_base_topdown(unsigned long addr);
 
 extern phys_addr_t arm64_dma_phys_limit;
 #define ARCH_LOW_ADDRESS_LIMIT	(arm64_dma_phys_limit - 1)
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index a38f54cd638c..956cab3ade11 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -38,3 +38,36 @@ int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
 {
 	return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);
 }
+
+unsigned long arch_get_mmap_end(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return TASK_SIZE_32;
+#endif /* CONFIG_COMPAT */
+#ifndef CONFIG_ARM64_FORCE_52BIT
+	if (addr > DEFAULT_MAP_WINDOW_64)
+		return TASK_SIZE_64;
+#endif /* CONFIG_ARM64_FORCE_52BIT */
+	return DEFAULT_MAP_WINDOW_64;
+}
+unsigned long arch_get_mmap_base(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return current->mm->mmap_compat_base;
+#endif /* CONFIG_COMPAT */
+	return current->mm->mmap_base;
+}
+unsigned long arch_get_mmap_base_topdown(unsigned long addr)
+{
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return current->mm->mmap_compat_base;
+#endif /* CONFIG_COMPAT */
+#ifndef CONFIG_ARM64_FORCE_52BIT
+	if (addr > DEFAULT_MAP_WINDOW_64)
+		return current->mm->mmap_base + TASK_SIZE - DEFAULT_MAP_WINDOW_64;
+#endif /* CONFIG_ARM64_FORCE_52BIT */
+	return current->mm->mmap_base;
+}
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:56 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:56 +0100
Subject: [PATCH v4 7/8] arm64: Forbid calling compat sigreturn from 64-bit
 tasks
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-6-amanieu@gmail.com>

It's impossible for this syscall to do anything sensible in this
context.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/kernel/signal32.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 2f507f565c48..e2bdd1eaefd8 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -237,6 +237,10 @@ COMPAT_SYSCALL_DEFINE0(sigreturn)
 	/* Always make any pending restarted system calls return -EINTR */
 	current->restart_block.fn = do_no_restart_syscall;
 
+	/* Reject attempts to call this from a 64-bit process. */
+	if (!is_compat_task())
+		goto badframe;
+
 	/*
 	 * Since we stacked the signal on a 64-bit boundary,
 	 * then 'sp' should be word aligned here.  If it's
@@ -268,6 +272,10 @@ COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 	/* Always make any pending restarted system calls return -EINTR */
 	current->restart_block.fn = do_no_restart_syscall;
 
+	/* Reject attempts to call this from a 64-bit process. */
+	if (!is_compat_task())
+		goto badframe;
+
 	/*
 	 * Since we stacked the signal on a 64-bit boundary,
 	 * then 'sp' should be word aligned here.  If it's
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:55 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:55 +0100
Subject: [PATCH v4 6/8] arm64: Add a compat syscall flag to thread_info
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-5-amanieu@gmail.com>

This flag is used by in_compat_syscall to handle compat syscalls coming
from 64-bit tasks.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/asm/compat.h      |  4 ++--
 arch/arm64/include/asm/elf.h         | 13 ++++++++++++-
 arch/arm64/include/asm/thread_info.h |  6 ++++++
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index a2f5001f7793..124f4487dfee 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -190,13 +190,13 @@ static inline bool is_compat_thread(struct thread_info *thread)
 
 static inline bool in_compat_syscall(void)
 {
-	return is_compat_task();
+	return current_thread_info()->use_compat_syscall;
 }
 #define in_compat_syscall in_compat_syscall	/* override the generic impl */
 
 static inline bool thread_in_compat_syscall(struct thread_info *thread)
 {
-	return is_compat_thread(thread);
+	return thread->use_compat_syscall;
 }
 
 #else /* !CONFIG_COMPAT */
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index e21964898d06..49a9a9db612c 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -158,10 +158,20 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 #define ELF_PLAT_INIT(_r, load_addr)	(_r)->regs[0] = 0
 
+#ifdef CONFIG_COMPAT
+#define CLEAR_COMPAT_SYSCALL()						\
+({									\
+	current_thread_info()->use_compat_syscall = false;		\
+})
+#else
+#define CLEAR_COMPAT_SYSCALL()	((void)0)
+#endif
+
 #define SET_PERSONALITY(ex)						\
 ({									\
 	clear_thread_flag(TIF_32BIT);					\
 	current->personality &= ~READ_IMPLIES_EXEC;			\
+	CLEAR_COMPAT_SYSCALL();						\
 })
 
 /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
@@ -228,7 +238,8 @@ typedef compat_elf_greg_t		compat_elf_gregset_t[COMPAT_ELF_NGREG];
 #define COMPAT_SET_PERSONALITY(ex)					\
 ({									\
 	set_thread_flag(TIF_32BIT);					\
- })
+	current_thread_info()->use_compat_syscall = true;		\
+})
 #ifdef CONFIG_COMPAT_VDSO
 #define COMPAT_ARCH_DLINFO						\
 do {									\
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 6623c99f0984..02310b45900d 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -42,6 +42,12 @@ struct thread_info {
 	void			*scs_base;
 	void			*scs_sp;
 #endif
+#ifdef CONFIG_COMPAT
+	/*
+	 * compat task or inside a compat syscall from a 64-bit task
+	 */
+	bool			use_compat_syscall;
+#endif
 };
 
 #define thread_saved_pc(tsk)	\
-- 
2.31.1



From amanieu at gmail.com  Fri Apr 30 21:37:57 2021
From: amanieu at gmail.com (Amanieu d'Antras)
Date: Fri, 30 Apr 2021 21:37:57 +0100
Subject: [PATCH v4 8/8] arm64: Allow 64-bit tasks to invoke compat syscalls
In-Reply-To: <20210430202810.44092-1-amanieu@gmail.com>
References: <20210430202810.44092-1-amanieu@gmail.com>
Message-ID: <20210430203757.47653-7-amanieu@gmail.com>

Setting bit 31 in x8 when performing a syscall will do the following:
- The remainder of x8 is treated as a compat syscall number and is used
  to index the compat syscall table.
- in_compat_syscall will return true for the duration of the syscall.
- VM allocations performed by the syscall will be located in the lower
  4G of the address space.
- Interrupted syscalls are properly restarted as compat syscalls.
- Seccomp will treats the syscall as having AUDIT_ARCH_ARM instead of
  AUDIT_ARCH_AARCH64. This affects the arch value seen by seccomp
  filters and reported by SIGSYS.
- PTRACE_GET_SYSCALL_INFO also treats the syscall as having
  AUDIT_ARCH_ARM. Recent versions of strace will correctly report the
  system call name and parameters when an AArch64 task mixes 32-bit and
  64-bit syscalls.

Previously, setting bit 31 of the syscall number would always cause the
sygscall to return ENOSYS. This allows user programs to reliably detect
kernel support for compat syscall by trying a simple syscall such as
getpid.

The AArch32-private compat syscalls (__ARM_NR_compat_*) are not exposed
through this interface. These syscalls do not make sense in the context
of an AArch64 task.

Signed-off-by: Amanieu d'Antras <amanieu at gmail.com>
Co-developed-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
Signed-off-by: Ryan Houdek <Houdek.Ryan at fex-emu.org>
---
 arch/arm64/include/uapi/asm/unistd.h |  2 ++
 arch/arm64/kernel/signal.c           |  5 +++++
 arch/arm64/kernel/syscall.c          | 21 ++++++++++++++++++++-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h
index f83a70e07df8..5574bc6ab0a3 100644
--- a/arch/arm64/include/uapi/asm/unistd.h
+++ b/arch/arm64/include/uapi/asm/unistd.h
@@ -15,6 +15,8 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#define __ARM64_COMPAT_SYSCALL_BIT 0x80000000
+
 #define __ARCH_WANT_RENAMEAT
 #define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SET_GET_RLIMIT
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 6237486ff6bb..463c8a82050e 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -795,6 +795,11 @@ static void setup_restart_syscall(struct pt_regs *regs)
 {
 	if (is_compat_task())
 		compat_setup_restart_syscall(regs);
+#ifdef COMPAT
+	else if (in_compat_syscall())
+		regs->regs[8] = __ARM64_COMPAT_SYSCALL_BIT |
+				__NR_compat_restart_syscall;
+#endif
 	else
 		regs->regs[8] = __NR_restart_syscall;
 }
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index e0e9d54de0a2..83747cf4b5b7 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -118,6 +118,11 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
 		 * user-issued syscall(-1). However, requesting a skip and not
 		 * setting the return value is unlikely to do anything sensible
 		 * anyway.
+		 *
+		 * This edge case goes away with CONFIG_COMPAT since a
+		 * user-issued syscall(-1) is interpreted as a
+		 * compat_syscall(0x7fffffff) which still ends up returning
+		 * -ENOSYS in x0.
 		 */
 		if (scno == NO_SYSCALL)
 			regs->regs[0] = -ENOSYS;
@@ -165,7 +170,21 @@ static inline void sve_user_discard(void)
 void do_el0_svc(struct pt_regs *regs)
 {
 	sve_user_discard();
-	el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
+
+#ifdef CONFIG_COMPAT
+	/*
+	 * Setting bit 31 of x8 allows a 64-bit processe to perform compat
+	 * syscalls.
+	 */
+	if (regs->regs[8] & __ARM64_COMPAT_SYSCALL_BIT) {
+		current_thread_info()->use_compat_syscall = true;
+		el0_svc_common(regs,
+			       regs->regs[8] & ~__ARM64_COMPAT_SYSCALL_BIT,
+			       __NR_compat_syscalls, compat_sys_call_table);
+		current_thread_info()->use_compat_syscall = false;
+	} else
+#endif
+		el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
 }
 
 #ifdef CONFIG_COMPAT
-- 
2.31.1



From robh at kernel.org  Fri Apr 30 22:11:15 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:11:15 -0500
Subject: [PATCH v4 02/10] dt-bindings: serial: snps-dw-apb-uart: add
 description for rk3568
In-Reply-To: <20210429081151.17558-3-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081151.17558-3-cl@rock-chips.com>
Message-ID: <20210430211115.GA3900619@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:11:43 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-uart", "snps,dw-apb-uart" for uart nodes on
> a rk3568 platform to snps-dw-apb-uart.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 30 22:13:43 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:13:43 -0500
Subject: [PATCH v4 03/10] dt-bindings: mmc: rockchip-dw-mshc: add
 description for rk3568
In-Reply-To: <20210429081151.17558-4-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081151.17558-4-cl@rock-chips.com>
Message-ID: <20210430211343.GA3900779@robh.at.kernel.org>

On Thu, Apr 29, 2021 at 04:11:44PM +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-dw-mshc", "rockchip,rk3288-dw-mshc" for mmc nodes on
> a rk3568 platform to rockchip-dw-mshc.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/mmc/rockchip-dw-mshc.yaml        | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> index 3762f1c8de96..eaa3b0ef24f6 100644
> --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
> @@ -29,21 +29,14 @@ properties:
>        - const: rockchip,rk3288-dw-mshc
>        - items:
>            - enum:
> -            # for Rockchip PX30
>                - rockchip,px30-dw-mshc
> -            # for Rockchip RK3036
>                - rockchip,rk3036-dw-mshc
> -            # for Rockchip RK322x
>                - rockchip,rk3228-dw-mshc
> -            # for Rockchip RK3308
>                - rockchip,rk3308-dw-mshc
> -            # for Rockchip RK3328
>                - rockchip,rk3328-dw-mshc
> -            # for Rockchip RK3368
>                - rockchip,rk3368-dw-mshc
> -            # for Rockchip RK3399
>                - rockchip,rk3399-dw-mshc
> -            # for Rockchip RV1108

I find these comments redundant, so I'm fine with the change. But please 
state why you are removing them in the commit msg.

Acked-by: Rob Herring <robh at kernel.org>

> +              - rockchip,rk3568-dw-mshc
>                - rockchip,rv1108-dw-mshc
>            - const: rockchip,rk3288-dw-mshc
>  
> -- 
> 2.17.1
> 
> 
> 


From robh at kernel.org  Fri Apr 30 22:14:03 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:14:03 -0500
Subject: [PATCH v4 04/10] dt-bindings: watchdog: dw-wdt: add description
 for rk3568
In-Reply-To: <20210429081151.17558-5-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081151.17558-5-cl@rock-chips.com>
Message-ID: <20210430211403.GA3905172@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:11:45 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-wdt", "snps,dw-wdt" for watchdog nodes on
> a rk3568 platform to snps,dw-wdt.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 30 22:10:41 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:10:41 -0500
Subject: [PATCH v4 01/10] dt-bindings: i2c: i2c-rk3x: add description for
 rk3568
In-Reply-To: <20210429081151.17558-2-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081151.17558-2-cl@rock-chips.com>
Message-ID: <20210430211041.GA3899631@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:11:42 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-i2c", "rockchip,rk3399-i2c" for i2c nodes on
> a rk3568 platform to i2c-rk3x.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 30 22:14:21 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:14:21 -0500
Subject: [PATCH v4 05/10] dt-bindings: pwm: rockchip: add description for
 rk3568
In-Reply-To: <20210429081252.17711-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081252.17711-1-cl@rock-chips.com>
Message-ID: <20210430211421.GA3905741@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:12:52 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> add "rockchip,rk3568-pwm", "rockchip,rk3328-pwm" for pwm nodes on
> a rk3568 platform to pwm-rockchip.yaml.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 30 22:15:14 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:15:14 -0500
Subject: [PATCH v4 06/10] dt-bindings: gpio: change items restriction of
 clock for rockchip,gpio-bank
In-Reply-To: <20210429081306.17784-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081306.17784-1-cl@rock-chips.com>
Message-ID: <20210430211514.GA3905898@robh.at.kernel.org>

On Thu, Apr 29, 2021 at 04:13:06PM +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> The clock property need 2 items on some rockchip chips.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> index d993e002cebe..7b3fd2975c74 100644
> --- a/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
> @@ -22,7 +22,8 @@ properties:
>      maxItems: 1
>  
>    clocks:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2

Need to define what they are:

minItems: 1
items:
  - description: ...
  - description: ...

>  
>    gpio-controller: true
>  
> -- 
> 2.17.1
> 
> 
> 


From robh at kernel.org  Fri Apr 30 22:40:19 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:40:19 -0500
Subject: [PATCH v4 10/10] arm64: dts: rockchip: add basic dts for RK3568
 EVB
In-Reply-To: <20210429081358.18057-1-cl@rock-chips.com>
References: <20210429081151.17558-1-cl@rock-chips.com>
 <20210429081358.18057-1-cl@rock-chips.com>
Message-ID: <20210430214019.GA3946409@robh.at.kernel.org>

On Thu, 29 Apr 2021 16:13:58 +0800, cl at rock-chips.com wrote:
> From: Liang Chen <cl at rock-chips.com>
> 
> This patch add rk3568-evb1-v10.dts for RK3568 evaluation board.
> add uart/emmc/i2c/rk809 node for basic function.
> 
> Signed-off-by: Liang Chen <cl at rock-chips.com>
> ---
>  .../devicetree/bindings/arm/rockchip.yaml     |  5 ++
>  arch/arm64/boot/dts/rockchip/Makefile         |  1 +
>  .../boot/dts/rockchip/rk3568-evb1-v10.dts     | 79 +++++++++++++++++++
>  3 files changed, 85 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
> 

Reviewed-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Apr 30 22:46:09 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 16:46:09 -0500
Subject: [PATCH v3 1/7] ASoC: dt-bindings: sun8i-codec: Increase
 #sound-dai-cells
In-Reply-To: <20210430035859.3487-2-samuel@sholland.org>
References: <20210430035859.3487-1-samuel@sholland.org>
 <20210430035859.3487-2-samuel@sholland.org>
Message-ID: <20210430214609.GA3955996@robh.at.kernel.org>

On Thu, 29 Apr 2021 22:58:53 -0500, Samuel Holland wrote:
> Increase sound-dai-cells to 1 to allow using the DAIs in the codec
> corresponding to AIF2 and AIF3.
> 
> The generic ASoC OF code supports a #sound-dai-cells value of 0 or 1
> with no impact to the driver, so this is a backward-compatible change.
> 
> Signed-off-by: Samuel Holland <samuel at sholland.org>
> ---
>  .../bindings/sound/allwinner,sun8i-a33-codec.yaml         | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From patchwork-bot+netdevbpf at kernel.org  Fri Apr 30 22:50:09 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Fri, 30 Apr 2021 21:50:09 +0000
Subject: [PATCH net] net: stmmac: cleared __FPE_REMOVING bit in
 stmmac_fpe_start_wq()
In-Reply-To: <20210429230104.16977-1-mohammad.athari.ismail@intel.com>
References: <20210429230104.16977-1-mohammad.athari.ismail@intel.com>
Message-ID: <161981940922.13877.7364921069521536310.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Fri, 30 Apr 2021 07:01:04 +0800 you wrote:
> From: Mohammad Athari Bin Ismail <mohammad.athari.ismail at intel.com>
> 
> An issue found when network interface is down and up again, FPE handshake
> fails to trigger. This is due to __FPE_REMOVING bit remains being set in
> stmmac_fpe_stop_wq() but not cleared in stmmac_fpe_start_wq(). This
> cause FPE workqueue task, stmmac_fpe_lp_task() not able to be executed.
> 
> [...]

Here is the summary with links:
  - [net] net: stmmac: cleared __FPE_REMOVING bit in stmmac_fpe_start_wq()
    https://git.kernel.org/netdev/net/c/db7c691d7f4d

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From robh at kernel.org  Fri Apr 30 23:14:42 2021
From: robh at kernel.org (Rob Herring)
Date: Fri, 30 Apr 2021 17:14:42 -0500
Subject: [PATCH v2 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to DT
 schema
In-Reply-To: <7557bc8aaaa1924ad39676b32ba6a3f6474a3722.camel@collabora.com>
References: <20210422141602.350746-1-benjamin.gaignard@collabora.com>
 <20210422141602.350746-2-benjamin.gaignard@collabora.com>
 <7557bc8aaaa1924ad39676b32ba6a3f6474a3722.camel@collabora.com>
Message-ID: <20210430221442.GA3970483@robh.at.kernel.org>

On Thu, Apr 22, 2021 at 02:16:53PM -0300, Ezequiel Garcia wrote:
> (Adding Kever)
> 
> Hi Benjamin,
> 
> Thanks a lot for working on this, it looks amazing. Together with the great work
> that Rockchip is doing, it seems RK3566/RK3568 will have decent support very soon.
> 
> One comment here:
> 
> On Thu, 2021-04-22 at 16:15 +0200, Benjamin Gaignard wrote:
> > Convert Rockchip IOMMU to DT schema
> > 
> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
> > ---
> > version 2:
> > ?- Change maintainer
> > ?- Change reg maxItems
> > ?- Change interrupt maxItems
> > 
> > ?.../bindings/iommu/rockchip,iommu.txt???????? | 38 ---------
> > ?.../bindings/iommu/rockchip,iommu.yaml??????? | 79 +++++++++++++++++++
> > ?2 files changed, 79 insertions(+), 38 deletions(-)
> > ?delete mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> > ?create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> > deleted file mode 100644
> > index 6ecefea1c6f9..000000000000
> > --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
> > +++ /dev/null
> > @@ -1,38 +0,0 @@
> > -Rockchip IOMMU
> > -==============
> > -
> > -A Rockchip DRM iommu translates io virtual addresses to physical addresses for
> > -its master device.? Each slave device is bound to a single master device, and
> > -shares its clocks, power domain and irq.
> > -
> > -Required properties:
> > -- compatible????? : Should be "rockchip,iommu"
> > -- reg???????????? : Address space for the configuration registers
> > -- interrupts????? : Interrupt specifier for the IOMMU instance
> > -- interrupt-names : Interrupt name for the IOMMU instance
> > -- #iommu-cells??? : Should be <0>.? This indicates the iommu is a
> > -??????????????????? "single-master" device, and needs no additional information
> > -??????????????????? to associate with its master device.? See:
> > -??????????????????? Documentation/devicetree/bindings/iommu/iommu.txt
> > -- clocks????????? : A list of clocks required for the IOMMU to be accessible by
> > -??????????????????? the host CPU.
> > -- clock-names???? : Should contain the following:
> > -???????"iface" - Main peripheral bus clock (PCLK/HCL) (required)
> > -???????"aclk"? - AXI bus clock (required)
> > -
> > -Optional properties:
> > -- rockchip,disable-mmu-reset : Don't use the mmu reset operation.
> > -????????????????????????????? Some mmu instances may produce unexpected results
> > -????????????????????????????? when the reset operation is used.
> > -
> > -Example:
> > -
> > -???????vopl_mmu: iommu at ff940300 {
> > -???????????????compatible = "rockchip,iommu";
> > -???????????????reg = <0xff940300 0x100>;
> > -???????????????interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
> > -???????????????interrupt-names = "vopl_mmu";
> > -???????????????clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>;
> > -???????????????clock-names = "aclk", "iface";
> > -???????????????#iommu-cells = <0>;
> > -???????};
> > diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > new file mode 100644
> > index 000000000000..0db208cf724a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml
> > @@ -0,0 +1,79 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip IOMMU
> > +
> > +maintainers:
> > +? - Heiko Stuebner <heiko at sntech.de>
> > +
> > +description: |+
> > +? A Rockchip DRM iommu translates io virtual addresses to physical addresses for
> > +? its master device. Each slave device is bound to a single master device and
> > +? shares its clocks, power domain and irq.
> > +
> > +? For information on assigning IOMMU controller to its peripheral devices,
> > +? see generic IOMMU bindings.
> > +
> > +properties:
> > +? compatible:
> > +??? const: rockchip,iommu
> > +
> > +? reg:
> > +??? minItems: 1
> > +??? maxItems: 2
> > +
> > +? interrupts:
> > +??? minItems: 1
> > +??? maxItems: 2
> > +
> > +? interrupt-names:
> > +??? minItems: 1
> > +??? maxItems: 2
> > +
> 
> AFAICS, the driver supports handling multiple MMUs, and there's one reg and
> interrupt cell for each MMU. IOW, there's no requirement that maxItems is 2.
> 
> Is there any way we can describe that? Or maybe just allow a bigger maximum?

With #iommu-cells == 0, how would one distinguish which IOMMU is 
associated with a device? IOW, is more that 1 really usable?

If you need more just pick a maxItems value that's either the most seen 
or 'should be enough'TM. If the entries are just multiple instances of 
the same thing, please note that here.

Rob


From davem at davemloft.net  Fri Apr 30 23:22:58 2021
From: davem at davemloft.net (David Miller)
Date: Fri, 30 Apr 2021 15:22:58 -0700 (PDT)
Subject: [PATCH 1/3] sparc64: Add compile-time asserts for siginfo_t
 offsets
In-Reply-To: <20210429190734.624918-1-elver@google.com>
References: <20210429190734.624918-1-elver@google.com>
Message-ID: <20210430.152258.729887124786441756.davem@davemloft.net>

From: Marco Elver <elver at google.com>
Date: Thu, 29 Apr 2021 21:07:32 +0200

> To help catch ABI breaks at compile-time, add compile-time assertions to
> verify the siginfo_t layout. Unlike other architectures, sparc64 is
> special, because it is one of few architectures requiring si_trapno.
> ABI breaks around that field would only be caught here.
> 
> Link: https://lkml.kernel.org/r/m11rat9f85.fsf at fess.ebiederm.org
> Suggested-by: Eric W. Biederman <ebiederm at xmission.com>
> Signed-off-by: Marco Elver <elver at google.com>

Acked-by: David S. Miller <davem at davemloft.net>


From davem at davemloft.net  Fri Apr 30 23:28:01 2021
From: davem at davemloft.net (David Miller)
Date: Fri, 30 Apr 2021 15:28:01 -0700 (PDT)
Subject: [PATCH net-next 0/2] Introducing support for DWC xpcs Energy
 Efficient Ethernet
In-Reply-To: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
References: <20210429084636.24752-1-michael.wei.hong.sit@intel.com>
Message-ID: <20210430.152801.713225083548143754.davem@davemloft.net>

From: Michael Sit Wei Hong <michael.wei.hong.sit at intel.com>
Date: Thu, 29 Apr 2021 16:46:34 +0800

> The goal of this patch set is to enable EEE in the xpcs so that when
> EEE is enabled, the MAC-->xpcs-->PHY have all the EEE related
> configurations enabled.
> 
> Patch 1 adds the functions to enable EEE in the xpcs and sets it to
> transparent mode.
> Patch 2 adds the callbacks to configure the xpcs EEE mode.

net-next is closed, please resubit this when it opensd back up.

Thank you.


From patchwork-bot+netdevbpf at kernel.org  Fri Apr 30 23:30:11 2021
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Fri, 30 Apr 2021 22:30:11 +0000
Subject: [PATCH] net: stmmac: Remove duplicate declaration of stmmac_priv
In-Reply-To: <20210430031047.34888-1-wanjiabing@vivo.com>
References: <20210430031047.34888-1-wanjiabing@vivo.com>
Message-ID: <161982181111.1234.7541800919565959093.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Fri, 30 Apr 2021 11:10:47 +0800 you wrote:
> In commit f4da56529da60 ("net: stmmac: Add support for external
> trigger timestamping"), struct stmmac_priv was declared at line 507
> which caused duplicate struct declarations.
> Remove later duplicate declaration here.
> 
> Signed-off-by: Wan Jiabing <wanjiabing at vivo.com>
> 
> [...]

Here is the summary with links:
  - net: stmmac: Remove duplicate declaration of stmmac_priv
    https://git.kernel.org/netdev/net/c/f18c51b6513c

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




